| 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:25 |
| 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:26 |
| 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:27 |
| 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:28 |
| apw | xnox, ok acpi is your bus in the kernels mid | 10:33 |
| apw | nmind | 10:33 |
| 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:34 | |
| 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:35 |
| 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:36 |
| 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:37 |
| 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:38 |
| 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:39 |
| ubot5 | Error: ubuntu bug 1681651 not found | 10:39 |
| xnox | firmware node path.... | 10:40 |
| 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:42 | |
| apw | xnox, which series kernel are we using again ? | 10:43 |
| apw | xnox, i want to talk line numbers at you | 10:43 |
| xnox | 4.4 | 10:44 |
| xnox | no | 10:44 |
| xnox | 4.10 | 10:44 |
| 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:45 |
| xnox | yeap. | 10:47 |
| 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:50 |
| xnox | .... to be continued. The truth is out there. | 10:54 |
| xnox | i am suspecting that yes, it is all exposed in /sys/bus/acpi/devices | 10:55 |
| 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:56 |
| 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:57 |
| 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:58 |
| 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 | 10:59 |
| xnox | i think acpi tables are fixed. | 11:00 |
| xnox | but i can ask. | 11:00 |
| apw | right, but they have picked these rather random names for a reason, what is that reason | 11:01 |
| * apw wonders how the bios affected names work, ... | 11:02 | |
| 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:03 |
| 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:04 |
| 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:41 |
| 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:42 |
| 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:43 |
| xnox | i see. | 11:45 |
| 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:46 |
| 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:47 |
| xnox | and then create symlinks by-acpi-name, by-acpi-order, by-ae-hand-port-idx-in-ae | 11:48 |
| xnox | et.c | 11:48 |
| xnox | ok. here comes a patch. | 11:49 |
| 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:51 |
| 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:52 |
| 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:53 |
| 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:54 |
| 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:55 |
| 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:56 |
| 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 | 11:57 |
| 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:32 |
| xnox | i wonder if I can somehow enumerate _all_ platform nics, and have a table in udev to shortify the HISI00C things. | 12:33 |
| === dasjoe_ is now known as dasjoe | ||
| === klebers_ is now known as klebers | ||
| 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:21 |
| xnox | HISI00C1:0 | 15:22 |
| xnox | HISI00C2:1 | 15:22 |
| xnox | etc. | 15:22 |
| xnox | cause in former case my names will get uglier: enahc1d0 | 15:23 |
| apw | xnox, do you have a dmesg ? or can i get on that box ... | 15:27 |
| xnox | apw, cause i want to name all of these using this scheme http://paste.ubuntu.com/24549370/ | 15:33 |
| xnox | <en> <a> <short vendor> <short product> <probe number> | 15:34 |
| xnox | enahc20 | 15:34 |
| xnox | enahc21 | 15:34 |
| xnox | enahc22 | 15:34 |
| xnox | enahc23 | 15:34 |
| xnox | for our case. | 15:35 |
| 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:36 |
| xnox | so i should use "instance" variable name as well. if that makes sense. | 15:37 |
| 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:39 |
| 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:41 |
| 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:42 |
| xnox | right. i wonder what syspath udev will return me, and i will go from there. | 15:43 |
| apw | xnox, variously all of them probabally | 15:59 |
| === 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 | ||
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!