[OpenWrt-Devel] Migration in ath79 for swapped ethernet

Mon Jan 27 13:21:41 EST 2020

Hi Adrian,

On 21.01.2020 15:10, Adrian Schmutzler wrote:

[...]

>> I'm in the middle of migrating some devices from soon-to-be-obsolete
>> ar71xx to ath79 target and was wondering about status of the eth0/eth1
>> vs. LAN/WAN assignment issue.
> 
> To start with the end: I've decided to stop working on this.
> 
> The two major problems are obvious:
> 1. How to make sure we find every possible location of eth0/eth1 in user code
> 
> This is a problem which can be solved, and if it does not cover every single special case I could live with it.
> 
> 2. How to find out whether we are updating from ar71xx or not.
> 
> This is a hard one: We cannot rely on the ethernet setup itself, as the user might have changed it for whatever reason. We could rely on some other parameters as suggested (wmac path etc.), but that would not be generally applicable and still would impose some boundary conditions (e.g. start before the wmac migration, as then config would be "old" and paths on the device would already be "new", making identification of the update possible).
> 
> An alternative way would be to exploit /etc/board.json for that, given that it is not updated during sysupgrade (I'm not sure what's happening here). If it is not updated, it would give us access to the configuration when the user installed the device, and without the changes the user would have made to /etc/config/network. One could then parse and compare /etc/board.json to some (device-specific) reference (e.g. wan=eth0) and base the decision to apply migration on that. Afterwards, a new /etc/board.json is generated, so the condition is not met anymore. Despite for the device-specific condition, this would also be a generally applicable concept.

IMHO, that would never look like a clean and nice solution and we would 
need to carry it in code for who knows how long (imagine some ar71xx 
board will get migrated after 20.x release).

> All in all, this second problem (when to migrate) is the bigger problem. We also have a similar case in https://github.com/openwrt/openwrt/pull/2649
> 
> So far for the technical aspects. From the organizational point of view, for a long time I thought I'm the only one caring about this topic. Since there was not much interest in bringing this to 19.07 before the release, I do not see much use of adding it afterwards now.

As the 19.07 was released with ar71xx I didn't consider that important 
at the time. Now it's time to consider it as a problem and prepare 
solution _before_ the next release which won't include ar71xx.

> In any case, the migration script will be a complicated task and will certainly introduce cornercases as well. All in all, I do not think it's worth it, and we should keep to advise people to flash with "-n" that single time when upgrading from ar71xx to ath79. For the pros that will change their Ethernet setup by hand later without using "-n", I'd still provide the "easy" migrations like e.g. LED names.

At the very beginning, ath79 was considered as a brand new target 
without _any_ concerns about migration path from ar71xx. But then, 
things got complicated (broken).

Either we support seamless ar71xx -> ath79 migration for _all_ devices 
supported in both targets or we just... don't. There shouldn't be cases 
where user has to check or ask whether owned device can be upgraded with 
preserving settings.

And I really don't consider LED naming migration as important as network 
interfaces naming swap (LED naming convention in upstream got changed 
anyway so we are expecting another change/migration at some point in 
future). Also, LEDs names isn't the only problem, in some cases type of 
trigger has to be changed (e.g. netdev vs. switch).
>> I'm aware of the 8dde11d521 ("ath79: dts: drop "simple-mfd" for gmacs in
>> SoC dtsi") [0] and following changes but that "fixed" the problem only
>> for devices which were following already reversed (I wouldn't call it
>> wrong or incorrect, I also prefer to have LAN on eth0 interface) SOC's
>> GMACx <> ethx assignment/register under ar71xx target - e.g. LAN on eth0
>> which is in fact SOC's GMAC1 and WAN on eth1 which is SOC's GMAC0. Good
>> explanation of that inverted assignment can be found in Jeff's patch
>> here: [1].
> 
> Well, effectively a lot of devices match ar71xx order again, but also several do not match anymore after that.
> 
> For the underlying logic, I think Chuanhong will be the best person to discuss with.

Chuanhong, could you join the discussion?

> I've tried to start a list of devices where eth0/eth1 are swapped compared to ar71xx _now_ here:
> https://openwrt.org/docs/guide-user/installation/ar71xx.to.ath79#devices_with_known_config_changes_without_migration_available

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

> With the first device where I observed the swapped eth0/eth1, the GLinet AR150, Chuanhong explained me that the setup in ath79 would be more correct than the one in ar71xx.
> After all, if we advise to flash with -n anyway, I would prefer to have the "more correct" setup in ath79 compared to having to stick to the setup from ar71xx where that applies.

It's just semantics. I don't think there is a "more correct" setup here. 
And what's more, there is no single "correct" setup in ar71xx either as 
you could register GMACs in two different orders (see above comment 
about mach-*.c files).

> So, no matter what we do, there is no easy way forward.

We could remove all ar71xx -> ath79 migration helper scripts, ar71xx 
board names from supported devices lists in ath79 images and make the 
target a brand new, without any concerns about soon-to-be obsolete ar71xx ;)

-- 
Cheers,
Piotr

> 
> Best
> 
> Adrian
> 
>> 
>> [0] https://github.com/openwrt/openwrt/commit/8dde11d521
>> [1]
>> https://www.mail-archive.com/openwrt-
>> devel at lists.openwrt.org/msg48526.html
>> 
>> --
>> Cheers,
>> Piotr
>> 
>> 
>> _______________________________________________
>> openwrt-devel mailing list
>> openwrt-devel at lists.openwrt.org
>> https://lists.openwrt.org/mailman/listinfo/openwrt-devel
> 

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