catspeed-cc/openwrt
1
1
Fork 0
Code

update to inline thinking...

Browse Source
This commit is contained in:
mooleshacat 2026-06-15 18:21:02 -04:00
parent e6031426e1
commit 5fb1bb5969
Signed by: mooleshacat
GPG Key ID: 6F42FE1A481818C2
1 changed files with 5 additions and 5 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

10
target/linux/ipq40xx/files-6.12/arch/arm/boot/dts/qcom/qcom-ipq4019-tew-829dru.dts
View File

@ -530,21 +530,21 @@ edma {
### ADDRESS SPACE CONFLICTS ###
qcom-ipq4019.dtsi (upstream) stock-fixed.dts (mfr)
gmac: ethernet@c080000 -> edma@c080000 Delete nodes, redefine as per mfr.
gmac: ethernet@c080000 -> edma@c080000 Delete upstream nodes, redefine as per mfr.
In the case of upstream, this is "gmac" and no other gmac's are defined. In the case of mfr, this defines an edma-encapsulated gmac0-2
These gmac0-2 aka eth0-2 are suspected to be eth0/wan1, eth1/lan (with two side by side switches), and eth2/wan2
the mfr has defined gmac0 and gmac2 to have extra configuration (speed, duplex, etc.) whereas gmac1 is rather simple with less configuration
due to gmac1 having unique, minimal configuration, I suspect this to be the two switches QCA8337 & QCA8075 (4+4 LAN ports = 8 LAN ports)
due to gmac0 & gmac2 having extra configuration (speed, duplex, etc.) I suspect these to be wan1 and wan2
switch: switch@c000000 -> ess-switch@c000000 Delete nodes, do not redefine. Not needed.
upstream: switch@c000000 is a switch / mfr: ess-switch@c000000 is a proprietary LED controller
ess-switch from mfr is not needed. I believe this is how the mfr connects LED's to their source. It contains led_source@0-4 a total of 5 LED's (pwr,wps,2.4g,5g1,5g2)
switch: switch@c000000 -> ess-switch@c000000 Delete upstream nodes, do not redefine. Not needed.
upstream: switch@c000000 is a switch (QCA8337) we will define elsewhere / mfr: ess-switch@c000000 is a proprietary LED controller
ess-switch from mfr is not needed. I believe this is how the mfr connects LED's to their source. It contains led_source@0-4 a total of 5 LED's (presumably pwr,wps,2.4g,5g1,5g2)
I believe this is the proprietary LED controller that abstracts and hides gpio information FOR LEDS from the developer attempting to port the device.
this combined with lack of GPIO mapping information prevents successful port of devices without advanced/risky technique (probing GPIO and possibly damaging hardware)
how juvenile to prevent access to LEDS FFS!
mdio: mdio@90000 -> mdio@90000 Delete nodes, redefine as per mfr.
mdio: mdio@90000 -> mdio@90000 Delete upstream nodes, redefine as per mfr.
upstream: 5 phy, switches daisy chained / mfr: 4 ports, not possible to be daisychained...
mfr DTS does not indicate whether this is QCA8337 or QCA8075 - it must be one, and the other which is missing must be configured elsewhere (outside DTS?)
mfr defines ethernet-phy@0-4 in this block, it must be 4 of 8 LAN ports (one of the two switches)