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.
>>
>> ð1 {
>> 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@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
