IPQ5018: Potential future support for Linksys MX2000 Atlas 6 & MX5500 Atlas 6 Pro

They only publish BDF-s for reference boards so we cannot use them

Yes, just put it there, but you need the ath11-bdencoder to unpack the board-2.bin

And yes, .supports_regdb needs to be set to true

I meant regdb, not BDFs :slight_smile:
Can we use them to replace in BDF files?

It looks like the binary format of external and internal (inside BDF) regdb is different...

Thanks for your help. Will try and revert

that worked, had to extract the regdb from the upstream board-2.bin file and embed it in the stock board file using ath11k-bdencoder AND setting .supports_regdb to true.
I also see the frequencies match the stock FW. Awesome and thanks for your help!

Now back to troubleshooting ipq5018 wifi.

Pushed the latest code to my repo on github,

On 23.05/5.15, I've got the switch working in the initramfs image, but when I flash the factory image, it doesn't.
Seems again a reset issue. In initramfs, when 'phy-reset-gpio' in the DTS is set in the mdio1 node which the qca8337 switch is under, the traffic flows and the switch works. When reset-gpios is set instead, the switch still initializes but traffic doesn't flow.
When flashing to nand, both methods don't work. The switch is probed, initializes, but there's no traffic.
Any help/guidance would be highly appreciated!

On main/6.1, the switch comes up and there's traffic briefly, until the device crashes. SSDK/NSS-DP use some old DMA APIs that apparently don't work under 6.1, so we'll rely on @hzyitc's ongoing efforts to complete the mainline drivers for the phy, uniphy, and stmmac.

On the MX5500, the QCN9074 wifi radio comes up and works, though I haven't thoroughly tested.
I'm still unable to bring up IPQ5018 (2.4G) radio, it still crashes.

Drivers for (PWM) LEDs, PCIE, USB2/USB3 all work on both 23.05/5.15 and main/6.1.

Could it be that when the image is loaded from RAM, the clocks are set by uboot and, hence, traffic is flowing between the ipq5018 and qca8337 switches over the uniphy?

I looked at the yaml bindings definition of the GCC, and found that the clocks for gephy and uniphy are explicitly set (and perhaps must be?):

  clocks:
    items:
      - description: Board XO source
      - description: Sleep clock source
      - description: PCIE20 PHY0 pipe clock source
      - description: PCIE20 PHY1 pipe clock source
      - description: USB3 PHY pipe clock source
      - description: GEPHY RX clock source
      - description: GEPHY TX clock source
      - description: UNIPHY RX clock source
      - description: UNIPHY TX clk source

<-- cut -->

 clock-controller@1800000 {
      compatible = "qcom,gcc-ipq5018";
      reg = <0x01800000 0x80000>;
      clocks = <&xo_board_clk>,
               <&sleep_clk>,
               <&pcie20_phy0_pipe_clk>,
               <&pcie20_phy1_pipe_clk>,
               <&usb3_phy0_pipe_clk>,
               <&gephy_rx_clk>,
               <&gephy_tx_clk>,
               <&uniphy_rx_clk>,
               <&uniphy_tx_clk>;

my current dtsi looks as follows and is missing the gephy and uniphy clocks:

gcc: clock-controller@1800000 {
			compatible = "qcom,gcc-ipq5018";
			reg = <0x01800000 0x80000>;
			clocks = <&xo_board_clk>,
				 <&sleep_clk>,
				 <&pcie_x2phy>,
				 <&pcie_x1phy>,
				 <&usbphy1>,
				 <0>,
				 <0>,
				 <0>,
				 <0>;
			#clock-cells = <1>;
			#reset-cells = <1>;
			#power-domain-cells = <1>;

the clocks set point to nodes in the dtsi, for ex, the usbphy1 is the phy node for USB3.
If they need to be set, where do I point them to? The ess-switch (as that's the one that refers to the gephy and uniphy clocks)?
Or can I point directly to clocks in the GCC driver? such as:

gcc: clock-controller@1800000 {
			compatible = "qcom,gcc-ipq5018";
			reg = <0x01800000 0x80000>;
			clocks = <&xo_board_clk>,
				 <&sleep_clk>,
				 <&pcie_x2phy>,
				 <&pcie_x1phy>,
				 <&usbphy1>,
				 <&gcc GCC_GEPHY_RX_CLK>,
				 <&gcc GCC_GEPHY_TX_CLK>,
				 <&gcc GCC_UNIPHY_RX_CLK>,
				 <&gcc GCC_UNIPHY_TX_CLK>;

@robimarko, @hzyitc, @kirdes: any clue?

To me its only logical to include them in the ess-switch node, but look into whether SSDK is even parsing for them