Could the problem with setting gpio44 be that the PHY has id 0x00000000:
root@OpenWrt:~# mdio 9*
DEV PHY-ID LINK
0x00 0x004dd0b1 down
0x01 0x004dd0b1 down
0x02 0x004dd0b1 down
0x03 0x004dd0b1 up
0x04 0x004dd0b1 down
0x05 0x04820a05 down
0x08 0x00000000 down
?
AQR-s are C45 only PHY-s so they dont have a C22 address at all and that is probably confusing the probe code completely.
As far as the 6GHz support goes, I am not sure if the 6E power/regulatory commits for ath11k have been backported, have newer tried it as I dont have any boards that support 6E
Can this be patched easily?
This id should be added somewhere:
root@OpenWrt:/# mdio 9* mmd 8:1 3
0x1c22
?
The same PHY ids are reported in QHora-301W: Adding OpenWrt support for QNAP QHora-301W - #503 by rmandrad
So how the gpio is toggled in the case of QHora-301W?
I can read id this way:
root@OpenWrt:/# mdio 9* mmd 8:1
CTRL1(0x00): 0x2040
flags: -reset -low-power -remote-loopback -local-loopback
speed: 10g
STAT1(0x01): 0x0082
capabilities: -pias -peas +low-power
flags: +fault -link
DEVID(0x02/0x03): 0x31c31c22
SPEED(0x04): 0x6031
capabilities: -400g +5g +2.5g -200g -25g -10g-xr -100g -40g -10g/1g -10 +100
+1000 -10-ts -2-tl +10g
DEVS(0x06/0x05): 0xe000009a
devices: +vendor2 +vendor1 +c22-ext -power-unit -ofdm -pma4 -pma3 -pma2 -pma1
+aneg -tc -dte-xs +phy-xs +pcs -wis +pma/pmd -c22
CTRL2(0x07): 0x0009
flags: -pias -peas
type: 10g-t
STAT2(0x08): 0xb701
capabilities: +tx-fault +rx-fault +ext-register +tx-disable +local-loopback
-10g-sr -10g-lr -10g-er -10g-lx4 -10g-sw -10g-lw -10g-ew
flags: +present -tx-fault +rx-fault
EXTABLE(0x0B): 0x40fc
capabilities: -10g-cx4 -10g-lrm +10g-t +10g-kx4 +10g-kr +1000-t +1000-kx
+100-tx -10-t -p2mp -40g/100g -1000/100-t1 -25g -200g/400g
+2.5g/5g -1000-h
PKGID(0x0E/0x0F): 0x31c31c22
Its not simple, as compatible pretty much accounts only for C22 ID-s and not for C45 ID-s which are not located in the usual registers 0x2 and 0x3 and those are empty on C45 only devices.
I managed to reproduce it on my 301W.
Fun thing is that reset-gpios "work" on 301W simply because bootloader will deassert the reset so they are already out of reset before booting, manually changing the reset before booting exposes the same issue.
I plan to poke around the core to see where the check is failling to see if we can add fixup it at least for our usage.
I've checked bootlogs for other AQR equped boards and all of them have initialization in u-boot:
NAND read: device 0 offset 0x7e00000, size 0x80000
524288 bytes read: OK
bad magic on ETHPHYFW partition
PHY ID1: 0x3a1
PHY ID2: 0xb612
device 0 offset 0x650000, size 0x80000
SF: 524288 bytes @ 0x650000 Read: OK
CRC check good on phy fw file (0x4B33)
PHYFW:Loading IRAM...........done.
PHYFW:Loading DRAM..............done.
phy fw image load good CRC-16 matches (0x6FFA)
PHY ID1: 0x31c3
PHY ID2: 0x1c12
NAND read: Offset exceeds device limit
PHY ID1: 0x31c3
PHY ID2: 0x1c12
NAND read: Offset exceeds device limit
PHY ID1: 0x31c3
PHY ID2: 0x1c12
NBG was moved to load firmware via kernel as well, but it seems that all of them are at least deasserting the reset in the bootloader.
I would suggest using the pinctrl to deassert the reset for now, until a more proper solution was find
GPIO support in u-boot for MX5300 is not configured. I'm not able to toggle gpio44 manually.
There is no command, but it can be done by manually poking at the register.
There is a gpio command but not working:
IPQ807x# help
? - alias for 'help'
aes_256 - AES 256 CBC/ECB encryption/decryption
aq_load_fw- LOAD aq-fw-binary
aq_phy_restart- Restart Aquantia phy
base - print or set address offset
bdinfo - print Board Info structure
bootipq - bootipq from flash device
bootm - boot application image from memory
bootp - boot image via network using BOOTP/TFTP protocol
bootz - boot Linux zImage image from memory
canary - test stack canary
chpart - change active partition
cmp - memory compare
cp - memory copy
crc32 - checksum calculation
dcache - enable or disable data cache
devinfo - devinfo - devinfo handling commands
dhcp - boot image via network using DHCP/TFTP protocol
dm - Driver model low level access
echo - echo args to console
env - environment handling commands
erase - erase FLASH memory
exectzt - execute TZT
exit - exit script
false - do nothing, unsuccessfully
fdt - flattened device tree utility commands
flash - flash part_name
flash part_name load_addr file_size
flasherase- flerase part_name
flinfo - print FLASH memory information
fuseipq - fuse QFPROM registers from memory
go - start application at address 'addr'
gpio - control gpio pin
help - print command description/usage
i2c - I2C sub-system
icache - enable or disable instruction cache
imxtract- extract a part of a multi-image
ipq_mdio- IPQ mdio utility commands
is_sec_boot_enabled- check secure boot fuse is enabled or not
itest - return true/false on integer compare
loop - infinite loop on address range
md - memory display
mfg - Diagnostic tools for MFG (mfg gpio/led/btn/badblk/usb/rtc)
mii - MII utility commands
mm - memory modify (auto-incrementing address)
mmc - MMC sub system
mmcinfo - display MMC info
mtdparts- define flash/nand partitions
mtest - simple RAM read/write test
mw - memory write (fill)
nand - NAND sub-system
nboot - boot from NAND device
nm - memory modify (constant address)
pci - list and access PCI Configuration Space
ping - send ICMP ECHO_REQUEST to network host
printenv- print environment variables
protect - enable or disable FLASH write protection
reset - Perform RESET of the CPU
run - run commands in an environment variable
runmulticore- Enable and schedule secondary cores
saveenv - save environment variables to persistent storage
secure_authenticate- authenticate the signed image
senv - senv handling commands
setenv - set environment variables
sf - SPI flash sub-system
showvar - print local hushshell variables
sleep - delay execution for some time
smeminfo- print SMEM FLASH information
source - run script from memory
test - minimal test like /bin/sh
tftpboot- boot image via network using TFTP protocol
tftpput - TFTP put command, for uploading files to a server
true - do nothing, successfully
uart - UART sub-system
ubi - ubi commands
usb - USB sub-system
usbboot - boot from USB device
version - print monitor, compiler and linker version
Yes, as QCA doesnt register a proper GPIO driver at all
This move was made so that newer firmware could be loaded from a file?
Should a firmware package for AQR be created?
It can be loaded from file or more preferably via NVMEM from storage.
AQR FW licensing is unclear so it cannot be redistributed for now
Can be qcom,smem-part used with nvmem-layout?
I was trying this configuration but it's not working:
&qpic_nand {
status = "okay";
pinctrl-0 = <&qpic_pins_new>;
nand@0 {
reg = <0>;
nand-ecc-strength = <4>;
nand-ecc-step-size = <512>;
nand-bus-width = <8>;
partitions {
compatible = "qcom,smem-part";
partition-0-ethphyfw {
compatible = "fixed-partitions";
label = "0:ethphyfw";
read-only;
#address-cells = <1>;
#size-cells = <1>;
nvmem-layout {
compatible = "fixed-layout";
#address-cells = <1>;
#size-cells = <1>;
aqr_fw: firmware@0 {
/* Skip the QCOM MBN Header of 40 bytes */
reg = <0x28 0x5f82a>;
};
};
};
};
};
};
NVMEM should work with SMEM partitions, there should be an example already.
Funny thing, if I stop bootloader I can see:
PHY ID1: 0x4d
PHY ID2: 0xd0b1
PHY ID1: 0x31c3
PHY ID2: 0x1c22
and after run boot command AQR PHY is working 
Yes, because if you interrupt boot then it will initialize networking, but it will not do it if just autobooting
What could be wrong that there is no transmission on QCA8075 ports? After removing the AQR port from dts, the ports work.
After modify bootcmd and use aq_load_fw all ports work.
Is some additional configuration needed like in this script: OpenWrt support for Linksys MX8500 - #24 by lytr ?
If we define firmware-name for AQR PHY in dts and file is missing, then there is no failback to nvmem-cells firmware:
[ 2.786270] Aquantia AQR114C 90000.mdio-1:08: bad firmware CRC: file 0xffff calculated 0xe266
[ 2.786320] Aquantia AQR114C 90000.mdio-1:08: firmware loading failed: -22
[ 2.793901] Aquantia AQR114C 90000.mdio-1:08: Direct firmware load for marvell/AQR-G4_v5.6.5-AQR_WNC_SAQA-L2_GT_ID45287_VER24005.cld failed with error -2
[ 2.800626] Aquantia AQR114C 90000.mdio-1:08: Falling back to sysfs fallback for: marvell/AQR-G4_v5.6.5-AQR_WNC_SAQA-L2_GT_ID45287_VER24005.cld
[ 64.475846] Aquantia AQR114C 90000.mdio-1:08: failed to find FW file marvell/AQR-G4_v5.6.5-AQR_WNC_SAQA-L2_GT_ID45287_VER24005.cld (-110)
[ 64.475913] Aquantia AQR114C: probe of 90000.mdio-1:08 failed with error -110
?
Its the other way around, first NVMEM is tried and if that fails it will try to load the file from rootfs
OK, so something is wrong with my nvmem-cells definition - bad firmware CRC: file 0xffff calculated 0xe266.
Loading from u-boot:
NAND read: device 0 offset 0x13e80000, size 0x100000
1048576 bytes read: OK
CRC check good on AQR phy fw file (0xCC87)
AQR PHYFW:Loading IRAM...........done.
AQR PHYFW:Loading DRAM..............done.
phy fw image load good CRC-16 matches (0x704)