Hi Adrian, David, Chuanhong,
On 07.09.2019 12:15, m...@adrianschmutzler.de wrote:
Hi,
> However, this will obviously swap eth0/eth1 on EVERY upgrade, not just
when coming from ar71xx.
> So, does anyone have an idea how to limit this to run only when updated
from ar71xx?
I was thinking about the same. As we have no information about the
previously installed platform, i was thinking about abusing the wmac path we
already use to migrate the WiFi configuration.
However, i think this is not the most elegant way to solve this issue.
I have to think about that. I recently thought one could just check whether the
lan/wan assignment matches the one expected for ar71xx, but that would
obviously also catch cases were the user modified it to be like this.
> Despite, while having the abstraction of "rename_all_eth", I wonder
whether it would be possible and desirable to do all renames in one step:
> sed -i -e 's/eth0/ethX/' -e 's/eth1/eth0/' -e 's/ethX/eth1/' $file or
> even sed -i -e 's/eth0/eth1/' -e 's/eth0/eth1/' $file depending on
> how sed handles this internally. These options would mean less flash writes
(although this might not be too important here).
A rewrite with sed is not sufficient, as we will possible rewrite uci section
names, possibly referenced elsewhere. We have to loop thru all interface
values and lists, rewriting each occurrence.
Actually, I could well live with that. What kind of references are you
referring to?
If just someone really named a section with ethX, it will be renamed
consistently throught all uci files (unless they are stored in another
location).
Only in case someone uses a section name with ethX and refers to it e.g. in a
custom script, this will be a problem.
And this is where I think we do not have to account for every tiny possibility.
If someone upgrades to another architecture, I think it's fair to expect him to
check whether his custom scripts still work. We do not have to overdo it.
But that's just my point of view at the moment.
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.
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].
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?
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?
[0] https://github.com/openwrt/openwrt/commit/8dde11d521
[1]
https://www.mail-archive.com/openwrt-devel@lists.openwrt.org/msg48526.html
--
Cheers,
Piotr
_______________________________________________
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
