00:02 <dsimic> true, and it also stems from the naming changes resulting from PCI(e) cards being moved around between the slots on a typical x86_64 motherboard

00:03 <dsimic> there's no such possibility with the fixed on-board devices, so a much simpler, fixed naming scheme for them would/should make sense

00:04 <dsimic> I still need to think a lot about it, i.e. how to actually introduce back what's been erradicated long time ago -- stable and simple numbering :)

00:04 <dsimic> and not to cause a lot of frowning upon

00:06 <CounterPillow> that won't help you when your PCIe controllers probe in a different order

00:07 <dsimic> good point, which is why I need to put more thinking into it

00:08 <dsimic> for example, the layout of the PCIe "tree" is known for each board, so in theory the "known nodes" could be referenced for the numbering

00:09 <dsimic> though, that's far from simple, so... more thinking is needed :)

00:09 <CounterPillow> why waste time on this at all? the problem is solved

00:10 <dsimic> how?

00:10 <CounterPillow> with the stable interface naming scheme. If people want them renamed to something numbered, they can with udev rules for their specific setup and preference.

00:10 <dsimic> i.e. how to link on-board network interfaces with the per-interface on-board LEDs?

00:11 <dsimic> that's true for the userspace, but I'm not sure that can work for the DTs

00:12 <CounterPillow> DTs don't depend on probe order at all and can just reference whatever node they mean, no?

00:12 <dsimic> e.g. there are devices with the RJ-45 network ports in the back and per-interface LEDs on the front, which are supposed to be linked with the corresponding network interfaces

00:13 <dsimic> but there are no DT nodes needed for the on-board PCIe devices that are network interfaces, they're enumerated dynamically

00:14 <dsimic> i.e. there's (currently) nothing to link to

00:16 <dsimic> there are already DT examples that add such nodes for the purpose of defining static MAC addresses by the boot loader, but frankly, they look really wrong by trying to define statically that's dynamic by nature

00:17 <CounterPillow> there can be nodes for devices in pcie controllers iirc, and it's for purposes like this where a device is hard-wired and its hard-wiredness depends on something else

00:18 <dsimic> true, there are e.g. soldered PCIe WiFi nodes that require some additional "out of band" resets and whatnot to actually work

00:19 <CounterPillow> https://github.com/devicetree-org/dt-schema/blob/main/dtschema/schemas/pci/pci-device.yaml

00:19 <dsimic> such additions to the DTs have already been frowned upon a lot, and the only reason why they were accepted was that such soldered PCIe modules/devices couldn't work wthout the additional handling performed that way

00:21 <dsimic> all that is something to think more about

00:23 <dsimic> adding a whole lot of kludge to a DT, which actually isn't needed for the devices to work, just to be able to reference the node somewhere else in the DT, seems like a suboptimal approach to me, while all that's needed is some kind of simple and stable ordering for the soldered on-board devices

01:36 <CounterPillow> "just to be able to reference the node somewhere else in the DT" is the reason why phandles exists though. A non-enumerable part needs to know about the enumerable part, and in that case I think having a node for the enumerable part that specifies which PCIe bus address it describes is quite a reasonable way to have the non-enumerable DT refer to this device that's expected to be there for its functionality.

01:41 <naoki> dsimic: CounterPillow: Hmm. Thanks for the info.

03:24 <dsimic> CounterPillow: I'll think more about it for sure

03:26 <dsimic> the rather large argument against defining parts of the DT that describe automatically enumerable parts, just to reference them elsewhere, is the amount of data that needs to be addeed; maybe I forgot some of details so the amount of data added that way actually isn't that large, it's been a while simce I looked into in closely

03:28 <dsimic> the amounf of added data in the example that I mentioned earlier, which serves for the boot loader to define a fixed MAC address for a PCIe Ethernet interface and pass it to the Linux kernel driver, is simply ridiculously large

03:29 <dsimic> if I were a maintainer of the respective platform/architecture, I'd ask the contributor to seek another solution :)

03:30 <dsimic> s/for a PCIe/for a soldered on-board PCIe/

08:09 <diederik> Context/concrete example: I was (very) surprised I couldn't connect the LAN1/LAN2 LEDS to their NICs because they are connected via PCIe on NanoPi R5S

08:16 <wens> isn't it just one node?

08:17 <diederik> what do you mean?

12:14 <wens> I meant for adding pcie devices

12:17 <diederik> Can you give or point to an example? I still don't get it

13:26 <wens> diederik: I was responding to dsimic's comments, not yours

13:27 <diederik> wens: oh, that explains it. Thanks :)

18:39 <dsimic> diederik: yes, the NanoPi R5S is a very good example

18:40 <dsimic> wens: of course, it ends up in a single DT node, but it's so deep down inside other nodes that also need to be added for that purpose

18:58 <wens> your pcie controller node is always going to be present

18:58 <wens> maybe there's a root bridge node

18:58 <wens> then the network controller

19:02 <wens> same goes for actual slots I think

19:02 <wens> there's nothing enumerable about hardware slots. so if you want them nicely numbered you probably have to describe them in DT

19:03 <wens> on x86 they are described in dmi / smbios. you're not getting away with no description

19:08 <dsimic> here's the example for setting a fixed MAC address by the boot loader

19:08 <dsimic> less +147 arch/arm64/boot/dts/freescale/imx8mm-venice-gw72xx.dtsi

19:08 <dsimic> (that's how I make such "bookmarks" internally :)

19:09 <dsimic> that's really a lot to add, IMHO

19:10 <dsimic> though, maybe it actually isn't that horrible, now that I'm thinking about it again... hmm

19:13 <dsimic> hmm, maybe it would be possible to link to the PCIe network interfaces using the current userspace interface naming nomenclature

19:13 <dsimic> the names generated that way are already guaranteed to be persistent, and that's all we need

19:16 <wens> there's one _stable_ interface naming scheme based on slot names

19:17 <dsimic> hmm, true, and we've got no slots for the on-board interfaces

19:17 <wens> for example I get enP3p49s0 and enP4p65s0 on my orange pi 5 plus

19:17 <dsimic> thus, something more to think about

19:18 <wens> the kernel doesn't really know that there are no slots :p

19:18 <dsimic> the first step should be to make it aware of that :)

19:18 <wens> I think if you add aliases it then allows following a different scheme?

19:19 <dsimic> but what to add aliases for?

19:19 <wens> there are also other options, like based on mac address

19:19 <dsimic> I'd be happy to add ethX aliases for the on-board PCIe interfaces, but they need to point to something

19:20 <wens> then you will need to add device nodes for them

19:20 <wens> no way around it; as you said, they need to point to something

19:20 <dsimic> ah, MAC addresses are often not saved anywhere, such as into some flash, so we can't hinge on them either :/

19:21 <dsimic> let me reasearch the current userspace naming scheme in detail first, please, regarding the lack of slots

19:21 <dsimic> s/reasearch/research/

19:22 <wens> I think in my example the slot number is just randomly carved out

19:22 <dsimic> perhaps, which is quite wrong and should be fixed first

19:23 <wens> probably 16 slots per domain, and index 0 is left to the root complex

19:27 <wens> dsimic: https://www.freedesktop.org/software/systemd/man/latest/systemd.net-naming-scheme.html

19:27 <wens> not sure what the lowercase 'p' is for in my example. but s0 indicates slot 0 under that particular domain / controller

20:15 <dsimic> wens: thanks for the link! O'll research it all in detail, including going through the systemd source code

20:16 <dsimic> I already had to go through it, while fixing some pacman-related bug a while ago

20:18 <dsimic> sometimes I really wish systemd documentation is available as a large, single PDF file... IMHO, a lot of context gets lost by splitting it into multiple pages available online or as man pages

20:23 <dsimic> s/O'll/I'll/

21:56 <Dex2x> this is interesting lm-sensors shows my fan on my opi5 ultra, but says the control is manual

22:22 <dsimic> Dex2x: I just had a quick look at the board dts and dtsi files, and it's got some pieces missing

22:23 <dsimic> I can fix that and send the patch(es) to the ML, but I can't test anything, because I've got no OrangePi boards

22:23 <dsimic> would you be willing to test the patches? :)

22:53 <Dex2x> yeah I can test

23:31 <dsimic> thanks! may I have your full name and email address, for the Reported-by tag(s)?

23:32 <CounterPillow> only give that out if you're okay with being in a public git log

23:32 <CounterPillow> i.e. that address will get a lot of spam

23:32 <CounterPillow> dsimic: please do not ask people this without explaining to them the consequences of it first.

23:33 <dsimic> yeah, I should've explained it a bit

23:33 <dsimic> though, regarding the spam, I'd disagree, because I get virtually no spam