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