[10:25] apw, how does linux kernel platform device enumeration happen using ACPI? [10:25] https://www.kernel.org/doc/Documentation/acpi/enumeration.txt [10:25] xnox, magic ? what are you asking ? [10:25] i mean, is it done in order / serially, or in parallel|randomly. [10:25] acpi things are found on buses which support things with ids [10:26] in the code for hns_enet.c there is MODULE_DEVICE_TABLE (acpi, match) and that's it really and a probe. [10:26] it is done in bus discovery order [10:26] usually, yes. but this is without a bus, as far as I understand. [10:26] because it is a platform device that is simply defined in ACPI because they can. [10:26] it is being done against the dtb isn't it in that driver ? [10:27] oh hmm, no it has both so who knows which i used [10:27] hm. i think it does both. [10:27] it _does_ both but which was used on this platform [10:28] HISI00C? appears in your ids i believe yes ? [10:28] good question. /me is n00b; yes, and I see ACPI paths in the sysfs. [10:33] xnox, ok acpi is your bus in the kernels mid [10:33] nmind [10:34] ok. so is there such a thing as the ACPI "bus" "id" aka order? =) [10:34] * xnox feels like these abstractions make no sense at all [10:35] that is because you are a userspace engineer :) [10:35] i think you caring which order i probe them is stupid [10:35] well, that is because the probe in my device driver allocates devno for the driver, and that is what is exposed in sysfs, and i am pondering to use that for stable device names [10:36] the devices have unique identifiers so you can tell them apart [10:36] and yet you refuse to use them [10:36] because vendor came back and said that ae-handle and ae-pidx-in-ae or whatever it was, together do identify unique ports [10:36] but do not have any correspondence with the physical board layout. [10:37] the physical board layout corresponds to the ACPI order of those devices. [10:37] which likely means it is in the order they are in the acpi tables, whcih come from teh firmware [10:37] and i do want enh2p0 enh2p1 be the first and second ethernet ports. rather than enh2p4, enh2p3 be the first/second ports. [10:38] correct, and if kernel loads the acpi table, does a match, and then fires to create handles in parallel, my devno's will no longer be in acpi order =/ or so i am imagining things. [10:38] so are they in reverse order or something [10:38] let me share the bug with you, one second. [10:39] xnox, you already did [10:39] there are more comments from the vendor about hte acpi [10:39] https://bugs.launchpad.net/pearl/+bug/1681651 [10:39] Error: ubuntu bug 1681651 not found [10:40] firmware node path.... [10:42] are you now able to find the Device (...) bit when you are probed ? [10:42] * xnox is afraid that i will get this wrong, and then my stable device names will be unstable. [10:43] xnox, which series kernel are we using again ? [10:43] xnox, i want to talk line numbers at you [10:44] 4.4 [10:44] no [10:44] 4.10 [10:45] wait no. [10:45] the yakkety hwe kernel [10:45] in xenial. [10:45] * apw stops talking to you [10:45] i have a branch of that checkout. [10:45] ok at line 1914 of hns_enet.c ... is where it is handling a probe [10:45] note that there we have a dev->fwnode which is an acpi thing [10:47] yeap. [10:50] you look to be able to call acpi_device_data_of_node() on that, and that has a name element which i think is the string in the Device() stanza in the table [10:50] but is that not available in the acpi information ? [10:50] already exposed in sysfs ? [10:54] .... to be continued. The truth is out there. [10:55] i am suspecting that yes, it is all exposed in /sys/bus/acpi/devices [10:56] xnox, probabally as a part of the path [10:56] yeah, or symlink targets or some such. but need to login to confirm =/ [10:57] as in in cat /sys/bus/acpi/devices/PNP0C14\:02/path [10:57] ls -latr view of /sys/bus/acpi/ is nice too. [10:58] ubuntu@ubuntu:~$ cat /sys/class/net/*/device/firmware_node/path [10:58] \_SB_.ETH4 [10:58] \_SB_.ETH5 [10:58] \_SB_.ETH0 [10:58] \_SB_.ETH1 [10:58] that [10:58] horum, so we do have that. "firmware_node" =) [10:58] there you go, that matches where i would expect it to be in the kernel data structures too [10:59] and that is telling youu which acpi table it came from, and which object within it [10:59] that is what they call them, and likley what we should call them [10:59] right. and somehow my wish is to translate 4 -> 0; 5 -> 1; 0 -> 2; 1 -> 3. [10:59] true. [10:59] (what you say) [10:59] and people will have to learn that they are 4501 [10:59] they may wish to not call them that, and change teh ACPI tables [11:00] i think acpi tables are fixed. [11:00] but i can ask. [11:01] right, but they have picked these rather random names for a reason, what is that reason [11:02] * apw wonders how the bios affected names work, ... [11:03] i think it is difficult to do anything other than use the names as they are, as as that says that dump is for a specific board [11:03] another board will have different layouts of connectors [11:04] and looking at that, the ports are in order of attachement to the internal device [11:04] as in eth0 is port 0 [11:04] it really has 6 ports per device [11:41] ack. [11:41] apw, what about this stuff: [11:41] 0 ./devices/LNXSYSTM:00/LNXSYBUS:00/HISI00C2:02 [11:41] 0 ./devices/LNXSYSTM:00/LNXSYBUS:00/HISI00C2:00 [11:41] 0 ./devices/LNXSYSTM:00/LNXSYBUS:00/HISI00C2:03 [11:41] 0 ./devices/LNXSYSTM:00/LNXSYBUS:00/HISI00C2:01 [11:41] is this platform bus, and is there any guidance as to how things are named on LNXSYBUS? =) [11:42] i don't think you can rely on it, as that is in the order the current kernel decides [11:42] http://paste.ubuntu.com/24548405/ [11:42] right, and kernel is free to change that. [11:42] they are _likley_ to be in the order of the ACPI table [11:43] and current driver does HISI00C2 and HISI00C1, and my guess is that one cannot have two HISI00C2 things defined in the acpi table.... [11:43] you can and they do [11:43] look at ETH6 in the table [11:45] i see. [11:46] but the order of teh HISI00C2:nn is in the order of teh acpi table [11:46] if that order has meaning, and it may in thie case and not otheres [11:46] but the ETH* names are unique, and have one-to-one mapping with ae-handle + port-idx-in-ae [11:47] i wish networking was actual files in /dev/ such that i would be able to have symlinks to name the same thing in multiple ways, just like we do for hard drivers. [11:48] and then create symlinks by-acpi-name, by-acpi-order, by-ae-hand-port-idx-in-ae [11:48] et.c [11:49] ok. here comes a patch. [11:51] xnox, but none of the fact they are 1:1 mappings tels you the intent of the table writer, they may have chosen the numbers randomly because "noone uses those" [11:51] xnox, and just because teh writer of this table did one thing, the writer of the next may have done another [11:52] xnox, which is why i don't think you can generically map them for any other table than this one [11:52] ..... it will be annoying if they randomly change those names. [11:53] does the driver make up the HISI00C2:01 name? [11:53] i thought it did. In that case if driver breaks ordering, i can blame them =) [11:54] that is acpi i believe, it is the first one of those it found and allocated [11:54] which i believe means they are in table order, assuming we do not ever [11:54] parallelise that [11:54] change to doing that in another order or parallel or ... [11:55] you have no information which is reliable full stop [11:55] either you believe the table or you don't [11:55] or acpi should export order in sysfs somehow, which is bonkers. [11:55] right, so. i will go with using 4501 names [11:55] but the table order is just as likely to change as the names in teh Device(NNN) stanza [11:56] in the sense they could change it. [11:56] i care that (a) systems with the same firmware (b) across reboots (c) get the same names [11:56] so you have to pick one, either you enumerate them in order they appear in the table, or by the names they use in the table [11:56] ack. [11:56] and if they randomly change those they will piss off their users [11:56] if there is different SKU, i don't chagne. [11:56] if there is different SKU, i don't care. [11:57] but the same firmware does not mean the same device for all time [11:57] as they can change that table and reboot, so ... you have to hope [11:57] and if kernel parallelises ACPI probing, it better give order hints when it calls and/or executes probes; or i will complain to the vendor to expose the acpi table order as a sysfs attribute. [11:57] they will not change whichever key you chose [12:32] apw, digging into code. Udev already does ID_PATH and ID_PATH_TAG which are [12:32] E: ID_PATH=platform-HISI00C2:00 [12:32] E: ID_PATH_TAG=platform-HISI00C2_00 [12:32] but these are not set as ID_NET_NAME_PATH [12:33] i wonder if I can somehow enumerate _all_ platform nics, and have a table in udev to shortify the HISI00C things. === dasjoe_ is now known as dasjoe === klebers_ is now known as klebers [15:21] apw, in the /devices/LNXSYSTM:00/LNXSYBUS:00/HISI00C2:01 what does the :01 mean? acpi probe order number, or the hns-net driver sequence number? cause hns-net driver handlees both HISI00C1 and HISI00C2 [15:21] and i am wondering if i will get: [15:21] HISI00C1:0 [15:21] HISI00C2:0 [15:21] or if i will get [15:22] HISI00C1:0 [15:22] HISI00C2:1 [15:22] etc. [15:23] cause in former case my names will get uglier: enahc1d0 [15:27] xnox, do you have a dmesg ? or can i get on that box ... [15:33] apw, cause i want to name all of these using this scheme http://paste.ubuntu.com/24549370/ [15:34] [15:34] enahc20 [15:34] enahc21 [15:34] enahc22 [15:34] enahc23 [15:35] for our case. [15:36] xnox, from what i can see we are using instance numbers within that HISI00C2 bus_id [15:36] which means you will get HISI00C2:0 and HISI00C1:0 [15:36] ack. [15:37] so i should use "instance" variable name as well. if that makes sense. [15:39] =( if system is booted without ACPI and with device tree, my interface names will not work anymore. [15:39] i wish i could generate the same names for these, irrespective if it was booted with devicetree or the ACPI [15:41] ... [15:41] i am wondering if i am in fact on the platform bus: [15:41] /sys/bus/platform/devices/HISI00C2 [15:42] there is the concept of companion devices in acpi so you may be on both [15:42] on acpi and on whereever you are actuall [15:43] right. i wonder what syspath udev will return me, and i will go from there. [15:59] xnox, variously all of them probabally === ejat_ is now known as ejat === cachio is now known as cachio_afk === cachio_afk is now known as cachio === henrix_ is now known as henrix