[OpenWrt-Devel] Migration in ath79 for swapped ethernet

Adrian Schmutzler mail at adrianschmutzler.de
Tue Jan 28 10:59:29 EST 2020


Hi,

> There is easy way to check GMACx <> ethX assignment order in mach-*.c
> files. Just check order of ath79_register_eth() calls:
> 
> ath79_register_eth(0);
> ath79_register_eth(1);
> 
> Will register GMAC0 as eth0, GMAC1 as eth1
> 
> ath79_register_eth(1);
> ath79_register_eth(0);
> 
> Will register GMAC1 as eth0, GMAC0 as eth1 (current ath79 "order")

I thought that once as well, but then found several cases where I couldn't rely
on it for eth0/eth1 order on running device. (But it's too long ago for me to be
more specific.)

Despite, from what I understand our current problem is the driver implementation
in ath79, which needs to skip/delay initialization in certain cases.
So, it's not so much about finding out the situation on ar71xx, but
understanding the situation in ath79 as well. All-in-all, I think this will come
down to having to check each device manually.

> 
> >> I have a feeling that the idea with migration script got abandoned
> >> (Adrian?), so I was wondering if there is any other way we could
> >> preserve ar71xx LAN/WAN <> ethX assignment in ath79?
> >
> > See above, yes, I effectively abandoned that.
> 
> Got it, so alternative solution is required.
> 
> >> For example, I have a QCA9531 based device with PHY4 (connected directly
> >> to GMAC0) labeled as LAN (and registered as eth0 in kernel) and PHY3
> >> (connected to GMAC1 over internal switch) labeled as WAN. On ath79, due
> >> to change introduced in 8dde11d521, LAN and WAN order gets swapped (as
> >> expected) but partially reverting above change (adding back "simple-mfd"
> >> to eth1 in device's DTS, see below) brings back the "old" order of
> >> interfaces.
> >>
> >> &eth1 {
> >> 	compatible = "qca,ar9330-eth", "syscon", "simple-mfd";
> >> 	mtd-mac-address = <&art 0x6>;
> >> };
> >>
> >> But it doesn't seem as a proper fix to me (maybe I'm wrong?) thus the
> >> question about any other, better approach?
> >
> > That's how I feel. For me, this always looked like a hack to me (based on my
> shallow level of understanding, though).
> > There might be special cases where this is necessary (e.g. force a device to
be
> eth0 due to failsafe), but I still do not like it.
> 
> I was considering also aliases in DTSes.

One could use that for failsafe (actually quite an interesting idea) and for
specifying the corresponding ethX in ar71xx. However, this still won't help us
with the migration script itself.

Best

Adrian 


_______________________________________________
openwrt-devel mailing list
openwrt-devel at lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel



More information about the openwrt-devel mailing list