Reorder phy name after update

Hi Guys, this is my first topic, so sorry if i'm not posting on the right category, but let me try to explain my problem.

I' am currently updating my (dual radio) hardware from a custom OpenWrt CC build to LEDE Project, but for some reason this build reordered my phy names number,

On the CC the 802.11G interface used to be phy0 and now it is phy1. Is there any way i can force the ordering of the phy? I've saw that the 802.11G interface is using IRQ 47 and 802.11A using IRQ 40, can this caused the reorder?

I have a lot of scripts on my access point that point to specific phy/ifname, is there anyway i can force the reordering/renaming of the phy?

Thanks in advance

You could use the iw command to permanently rename the phys upon boot, something like:

wifi down
iw phy phy0 set name phy_tmp
iw phy phy1 set name phy0
iw phy phy_tmp set name phy1
wifi up
1 Like

This works, and the interface doesn't even need to be down for that.

Is there a standardized way to do this in /etc/config/wireless (by now) for each radio?
It would be useful (to me) to have names like phy2soc, phy5pci, phyUsb.

Alternatively, can I set "pre-up" lines in the radio stanzas like in Debian/etc.?

Or is the only to add some lines to /etc/rc.local such as:

iw phy $(basename /sys/devices/platform/soc/a000000.wifi/ieee80211/*) set name phy2soc
iw phy $(basename /sys/devices/platform/soc/a800000.wifi/ieee80211/*) set name phy5soc

? Thanks

The natural place for that would be a custom script in /etc/hotplug.d/ieee80211/. Whenever a wiphy is detected by the kernel, it'll emit an ieee80211 uevent which will trigger the scripts in this directory.

I have just updated from 19.07.2 to 20.02.2 and have the same phy reordering.

[   18.626595] ath9k 0000:00:12.0: enabling device (0000 -> 0002)
[   18.673679] ieee80211 phy0: Atheros AR9280 Rev:2 mem=0xb0010000, irq=23
[   18.680528] ath9k 0000:00:11.0: enabling device (0000 -> 0002)
[   18.806511] ieee80211 phy1: Atheros AR9280 Rev:2 mem=0xb0000000, irq=22

but in /etc/config/wireless, it is the opposite, PCI ID 11.0 is radio0 and 2.4ghz band:

config wifi-device 'radio0'
	option type 'mac80211'
	option path 'pci0000:00/0000:00:11.0'
	option band '2g'

Note this is the autodetected wifi configuration on fresh install! (no config save)

so what is the purpose of PCI ID (path) in /etc/config/wireless? It doesn't seem to rename any devices and even the ssid configuration doesn't stay with the radio number (radio0) it's on.

[edit:]

dmesg before (4.14.171):

[    2.846927] pci 0000:00:11.0: [168c:ff1d] type 00 class 0x020000
[    2.846938] pci 0000:00:11.0: fixup device configuration
[    2.853457] pci 0000:00:11.0: reg 0x10: [mem 0x00000000-0x0000ffff]
[    2.853513] pci 0000:00:11.0: PME# supported from D0 D3hot
[    2.853683] pci 0000:00:12.0: [168c:ff1d] type 00 class 0x020000
[    2.853691] pci 0000:00:12.0: fixup device configuration
[    2.860247] pci 0000:00:12.0: reg 0x10: [mem 0x00000000-0x0000ffff]
[    2.860299] pci 0000:00:12.0: PME# supported from D0 D3hot
[    2.860458] pci_bus 0000:00: busn_res: [bus 00-ff] end is updated to 00
[    2.860483] pci 0000:00:11.0: BAR 0: assigned [mem 0x10000000-0x1000ffff]
[    2.867261] pci 0000:00:12.0: BAR 0: assigned [mem 0x10010000-0x1001ffff]
[   17.417223] pci 0000:00:11.0: using irq 40 for pin 1
[   17.422197] PCI: Enabling device 0000:00:11.0 (0000 -> 0002)
[   17.432741] ath: phy0: Ignoring endianness difference in EEPROM magic bytes.
[   17.441338] ath: EEPROM regdomain: 0x0
[   17.441342] ath: EEPROM indicates default country code should be used
[   17.441345] ath: doing EEPROM country->regdmn map search
[   17.441356] ath: country maps to regdmn code: 0x3a
[   17.441361] ath: Country alpha2 being used: US
[   17.441364] ath: Regpair used: 0x3a
[   17.455738] ieee80211 phy0: Selected rate control algorithm 'minstrel_ht'
[   17.457609] ieee80211 phy0: Atheros AR9280 Rev:2 mem=0xb0000000, irq=40
[   17.464307] pci 0000:00:12.0: using irq 41 for pin 1
[   17.469331] PCI: Enabling device 0000:00:12.0 (0000 -> 0002)
[   17.479824] ath: phy1: Ignoring endianness difference in EEPROM magic bytes.
[   17.488413] ath: EEPROM regdomain: 0x0
[   17.488418] ath: EEPROM indicates default country code should be used
[   17.488421] ath: doing EEPROM country->regdmn map search
[   17.488431] ath: country maps to regdmn code: 0x3a
[   17.488435] ath: Country alpha2 being used: US
[   17.488439] ath: Regpair used: 0x3a
[   17.504878] ieee80211 phy1: Selected rate control algorithm 'minstrel_ht'
[   17.506762] ieee80211 phy1: Atheros AR9280 Rev:2 mem=0xb0010000, irq=41

dmesg after (5.4.179):

[    0.463978] pci 0000:00:11.0: [168c:ff1d] type 00 class 0x020000
[    0.470005] pci 0000:00:11.0: reg 0x10: [mem 0x00000000-0x0000ffff]
[    0.476568] pci 0000:00:12.0: [168c:ff1d] type 00 class 0x020000
[    0.482619] pci 0000:00:12.0: reg 0x10: [mem 0x00000000-0x0000ffff]
[    0.489522] pci_bus 0000:00: busn_res: [bus 00-ff] end is updated to 00
[    0.496177] pci 0000:00:11.0: BAR 0: assigned [mem 0x10000000-0x1000ffff]
[    0.502966] pci 0000:00:12.0: BAR 0: assigned [mem 0x10010000-0x1001ffff]
[   18.062225] ath9k_pci_owl_loader 0000:00:11.0: enabling device (0000 -> 0002)
[   18.069639] ath9k_pci_owl_loader 0000:00:12.0: enabling device (0000 -> 0002)
[   18.089590] ath9k_pci_owl_loader 0000:00:12.0: fixup device configuration
[   18.097526] ath9k_pci_owl_loader 0000:00:11.0: fixup device configuration
[   18.115781] pci 0000:00:12.0: [168c:0029] type 00 class 0x028000
[   18.121864] pci 0000:00:12.0: reg 0x10: [mem 0x10010000-0x1001ffff]
[   18.128179] pci 0000:00:12.0: PME# supported from D0 D3hot
[   18.134307] pci 0000:00:12.0: BAR 0: assigned [mem 0x10010000-0x1001ffff]
[   18.142908] pci 0000:00:11.0: [168c:0029] type 00 class 0x028000
[   18.148994] pci 0000:00:11.0: reg 0x10: [mem 0x10000000-0x1000ffff]
[   18.155308] pci 0000:00:11.0: PME# supported from D0 D3hot
[   18.161492] pci 0000:00:11.0: BAR 0: assigned [mem 0x10000000-0x1000ffff]
[   18.626595] ath9k 0000:00:12.0: enabling device (0000 -> 0002)
[   18.647203] ath: phy0: Ignoring endianness difference in EEPROM magic bytes.
[   18.655790] ath: EEPROM regdomain sanitized
[   18.655795] ath: EEPROM regdomain: 0x64
[   18.655798] ath: EEPROM indicates we should expect a direct regpair map
[   18.655814] ath: Country alpha2 being used: 00
[   18.655817] ath: Regpair used: 0x64
[   18.671501] ieee80211 phy0: Selected rate control algorithm 'minstrel_ht'
[   18.673679] ieee80211 phy0: Atheros AR9280 Rev:2 mem=0xb0010000, irq=23
[   18.680528] ath9k 0000:00:11.0: enabling device (0000 -> 0002)
[   18.746718] crng init done
[   18.782040] ath: phy1: Ignoring endianness difference in EEPROM magic bytes.
[   18.790625] ath: EEPROM regdomain sanitized
[   18.790630] ath: EEPROM regdomain: 0x64
[   18.790633] ath: EEPROM indicates we should expect a direct regpair map
[   18.790648] ath: Country alpha2 being used: 00
[   18.790651] ath: Regpair used: 0x64
[   18.804330] ieee80211 phy1: Selected rate control algorithm 'minstrel_ht'
[   18.806511] ieee80211 phy1: Atheros AR9280 Rev:2 mem=0xb0000000, irq=22

maybe this ath9k_pci_owl_loader thing is affecting PCI probe order..

Ok, so we have https://github.com/torvalds/linux/commit/5a4f2040fd07a9ec1dcd9d2601150da99565815f which introduces the owl loader to provide ath9k eeprom data.

But the question is, how did this work before?

I think there was some arch/board level fixup,

[edit] Here it is (for my board)! https://sourcegraph.com/github.com/openwrt/openwrt@refs/heads/openwrt-19.07/-/blob/target/linux/ar71xx/files/arch/mips/ath79/dev-ap9x-pci.c?L171&subtree=true

but what's new is that owl-loader triggers a full PCI rescan, which opens the opportunity for phy0/phy1 scanning in a different order. (I guess in reverse order - maybe there's a "stack" (LIFO) order of PCI rescan)

In fact here's an example ieee80211 script (from a different arch) to rename devices:

http://git.nixtux.ru/dumalogiya/openwrt/commit/38167cb7f41b316fcc6d6bbcab993a2f42f30c0e?style=unified&whitespace=ignore-all

[edit] except I can't really see how that actually works. It seems if phy0 and phy1 are both already created, then it's not possible to rename from the hotplug script directly:

# cat /tmp/09-fix-phy-name.txt
ACTION=add DEVPATH=/devices/pci0000:00/0000:00:12.0/ieee80211/phy0
renaming phy0 to phy1
command failed: Invalid argument (-22)
ACTION=add DEVPATH=/devices/pci0000:00/0000:00:11.0/ieee80211/phy1
renaming phy1 to phy0
command failed: Invalid argument (-22)

so jow's suggestion of 3-step rename to temp, then final names, seems the only option.
which does not fit very well into the model of a hotplug script which runs exactly once per device...

[edit] hmmm, I'm not sure that works at all:

# cat  /tmp/09-fix-phy-name.txt
ACTION=add DEVPATH=/devices/pci0000:00/0000:00:12.0/ieee80211/phy0
+ '[' add '=' add -a /devices/pci0000:00/0000:00:12.0/ieee80211/phy0 '=' /devices/pci0000:00/0000:00:12.0/ieee80211/phy0 ]
+ iw phy phy0 set name phy_tmp
+ iw phy phy1 set name phy0
command failed: Invalid argument (-22)
+ iw phy phy_tmp set name phy1
command failed: Invalid argument (-22)
+ exit

[edit] seems manually setting name phy%d is prohibited:

[edit] one workaround I can think of is using names like "phy00" and "phy01". ugly, but might work