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.
ð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.
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-
de...@lists.openwrt.org/msg48526.html
--
Cheers,
Piotr
_______________________________________________
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
_______________________________________________
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
