[OpenWrt-Devel] Migration in ath79 for swapped ethernet

[Piotr Dymacz]

Hi Adrian,

On 28.01.2020 16:59, Adrian Schmutzler wrote:
> 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.)

There are two things here:
1. Mapping of physical ports to kernel interface naming.
2. Mapping of kernel interfaces to 'our' LAN/WAN system interfaces.

AFAIK, there wasn't any official or general rule about what should be 
LAN and WAN (in terms of mapping ethX to 'our' LAN/WAN), so it was 
always up to the device support author (personally I preferred to have 
LAN on eth0). And as you can see above, ar71xx allowed two different 
orders in which ethX interfaces where registered in kernel.

> 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.

More or less, yes.

>> >> 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.

Lets forget about migration scripts now and try to find a way to keep 
old interfaces mapping in ar71xx the same in ath79, using DTS only.
As I wrote already, it's just semantics.

-- 
Cheers,
Piotr

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