06:37 <pivi> it's jsut me, or this looks like a bad idea? https://lore.kernel.org/all/20240404161914.1655305-1-Frank.Li@nxp.com/ ? krzk ?

06:42 <krzk> pivi: it's downstream idea, what else to expect from NXP?

07:39 <pivi> krzk: I always try to have an optimistic mindset ... not that it always works ...

08:05 <krzk> yeah, to be honest, idea is quite creative and probably works fine... but it does not look like correct hardware description :)

08:06 <krzk> DT is for non-discoverable hardware so to solve the "non-discoverable" they added such mux and auto-discovery via dt :)

08:13 <javierm> pivi: the correct solution for this case would be for them to use DT overlays I think

08:17 <pivi> javierm: I do not know the specific hardware, but another alternative would be to have the nodes disabled and have a fixup in the firmware (U-Boot in their case). In my mind overlays work better for stuff you can plug into a board, not for soldered-down differences. Or even better, 2 dts file (with a common dtsi) and some runtime selection in the firmware

08:18 <pivi> This last proposal I wrote would probably be the most correct one.

08:20 <javierm> pivi: u-boot can apply dtbo and pass a single DTB to the kernel (https://docs.u-boot.org/en/latest/usage/fdt_overlays.html), IMO that's better than custom fixup code in the FW

08:20 <javierm> pivi: it seemed that they wanted to avoid the multiple dts with a shared dtsi, and I can understand why because in the long term I found that's a maintanance burden

08:22 <javierm> specially if one has other different IP blocks between board revisions. But is just my opinion

08:22 <pivi> javierm: yes, but thinking at it once more it is really the correct solution. two dts, with just this change on the audio codec, and everything else in a shared dtsi. You can implemente the file selection in U-Boot, but you are not creating any coupling with the firmware (you can always select the file you want, no matter you use barebox or anything else)

08:23 <javierm> pivi: but isn't the same for dtbo ? Barebox also supports it https://www.barebox.org/doc/latest/user/devicetree.html#device-tree-overlays

08:23 <javierm> after all the DTB should really be part of the FW since is as krzk mentioned just a HW description

08:24 <javierm> IOW, should be coupled with the FW and not the kernel

08:24 <javierm> but agreed that there are trade offs for each option

08:25 <javierm> pivi: btw, Android is also moving towards dtbo AFAIU https://source.android.com/docs/core/architecture/dto/partitions

08:26 <javierm> so while it was originally conceived for expansion boards, I believe that is a more general solution for this problem than having a bunch of dts files with shared dtsi

08:29 <pivi> javierm: IF your firmware supports dtbo yes. With that said probably for "soldered-down" variants it's just a matter of taste. If the firmware can load the correct dtbo, can with the same logic select the correct dtb

08:30 <javierm> pivi: agreed, as said there are different trade offs with both approaches

15:27 <cambrian_invader> yeah, but is there really any reason for this to be in the "firmware"

15:27 <cambrian_invader> linux is just as capable of determining what hardware is present as the bootloader is

15:53 <krzk> cambrian_invader: by combining multiple DTS into one and then probing GPIOs :)

15:53 <robmur01> hardly - it's not uncommon for board variants to be encoded by resistors or links, wherein it's dead easy for a platform-specific bootloader to hard-code reading a set of GPIOs or ADC value to determine which DTB to offer; a generic multiplatform kernel cannot do that

15:53 <robmur01> snap!

15:53 <cambrian_invader> of course a generic kernel can do that

15:53 <cambrian_invader> just write a driver to read the GPIOs and instantiate the appropriate drivers

15:54 <robmur01> OK, and how does it know it needs to loads *that* driver before it has a DT?

15:54 <cambrian_invader> you put that device in the devicetree

15:54 <cambrian_invader> and the rest is done with swnodes

15:57 <robmur01> OK, so we have two board variants with different PMICs, how do we turn on the right PMIC regulator to power the ADC to determine which PMIC we have? ;)

15:58 <krzk> cambrian_invader: to some level your idea is very good and it follows usual recommendation for devices with version register etc: if you can autodetect in the driver, use it.

15:58 <krzk> cambrian_invader: but if devices are different and you need different supplies or different pins, what to do?

15:58 <krzk> cambrian_invader: basically you embed DTS inside driver and keep it as C code?

15:59 <krzk> I mean, indirectly, via instantiating swnodes?

15:59 <cambrian_invader> it's up to the board integrator to make the decision here; if you have such different devices that they need completely different power supplies and sequencing, then you're going to need some GPIOs or EEPROM etc. to determine the present hardware

15:59 <krzk> This reminds me some concept... how was it... board files? :)

15:59 <cambrian_invader> yes :)

16:00 <cambrian_invader> and of course, people hate having to carry patches to add board support when they could just use a devicetree

16:00 <cambrian_invader> so this is why we have these sort of things crop up so often

16:00 <cambrian_invader> if you tell them "just detect things in the bootloader" it doesn't help because they still have to maintain patches

16:00 <krzk> I still like the idea that U-boot should do the board detection and just load appropriate DTS + overlay

16:01 <krzk> but I agree that we could do something similar in the kernel, if we really needed/wanted

16:01 <pivi> cambrian_invader: why should I mantain patches for this bootloader code?

16:01 <cambrian_invader> I mean you can always just "get off" the update schedule

16:02 <cambrian_invader> but you had better have all the features you want in your bootloader when you fork

16:02 <cambrian_invader> or otherwise you have to start backporting

16:03 <pivi> cambrian_invader: I'm not following your reasoning for the bootloader patches. Either you have your own firmware that you mantain, or you use some code that is maintained (u-boot? barebox?) and you just send you patches upstream

16:03 <pivi> cambrian_invader: no patches to carry

16:03 <cambrian_invader> but until these get upstream, you have to carry them

16:03 <cambrian_invader> if you are someone like NXP, you have years and years of patches to upstream

16:04 <cambrian_invader> and they do work on this, but it takes a long time

16:04 <cambrian_invader> limited reviewer eyeballs and so forth

16:04 <pivi> cambrian_invader: you cannot take a bad actor and use it as an example to say that cinema sucks

16:04 <cambrian_invader> they are not a bad actor?

16:04 <cambrian_invader> they are pretty average IMO

16:05 <cambrian_invader> and this is how every board vendor works

16:05 <pivi> ok, let me rephrase. if you decide to not upstream patches and to carry those in your downstream branch for years is your decision.

16:05 <pivi> cambrian_invader: well, I am a board vendor and no, we are not like that

16:08 <pivi> (yes, I agree NXP is an average actor, not a bad one)