16:44 <rfs613> everyone is probably tired of talking about it... but I'm still puzzled what is the benefit of havint a (potential large) list of compatible strings in spidev.c, for "devices" which exist only in userspace-code.

16:49 <rfs613> I know the "DT should describe hardware" argument... but much like the "Device tree as stable ABI" discussion from years back, I think the long-term reality ends up trumping ideals in some cases.

16:56 <mripard> rfs613: one of the issue is the DT is also used by other OSes, and the driver set can be different

16:57 <mripard> and this is also true with future version of Linux, where a device that used to be dealt with by a userspace driver has now a kernel space driver

16:58 <mripard> broonie also mentioned something important yesterday: how to you identify the device from the userspace side in the first place?

16:59 <mripard> sure, having a spidev compatible would be convenient, hacks can be convenient

16:59 <rfs613> for the case of future driver being in kernel, the compatible string would need to change at that point. To me at least that seems reasonable expectation, it's a differnet driver.

17:00 <mripard> not really?

17:00 <jn> (to which the lazy answer is: pick the first of /dev/spi*)

17:00 <jn> how does userspace find a spi device with a specific compatible string?

17:01 <mripard> rfs613: there's plenty of unsupported devices in U-Boot or FreeBSD that are listed in the DT, should we expect a different compatible as soon as they support it?

17:01 <rfs613> for broonie's point, yes, userspace tends to hardcode the /dev/spi* values (sometimes it has a config file, but usually only after getting burned by changes like spidev32768 -> spi0

17:04 <broonie> mripard: you should be able to figure things out from the compatible information in sysfs (though it’s a bunch of hassle).

17:06 <rfs613> mripard: does uboot actually need to talk to the hardware behind spidev? It's rather unlikely, there's no real way to run userspace code in u-boot.

17:07 <mripard> rfs613: I mean, why not? It's still a device that needs to be driven. There's no userspace, so it can

17:07 <rfs613> mripard: for other OSes... maybe... but with the current proposal, the potentiall larger list of compat strings now needs to get synchronised with FreeBSD and whatever else...

17:08 <rfs613> mripard: hrm, without userspace code, spidev doesn't do much (other than occupy kernel pages...)

17:10 <mripard> rfs613: it's not really what I'm talking about. where the driver is also depends on the OS/firmware state, right? So why a device handled by a userspace driver through spidev in Linux couldn't be handled by an actual firmware/kernel-space driver in other projects such as U-Boot?

17:10 <mripard> and similarly, why wouldn't a device supported through spidev in linux 5.16 couldn't be supported by a kernel space driver in Linux 6.12 ?

17:11 <rfs613> mripard: yes, that totally could be the case - and to distinguish these, something needs to change, andI would argue that you use "spidev" as the compat string in one case, and a real name (vendor,device) for a real driver.

17:12 <mripard> if you used a proper binding from the beginning, nothing would have to change

17:12 <mripard> and it could be shared across all projects, no matter what devices they actually support

17:12 <mripard> which is the entire point of the DT?

17:15 <rfs613> let me ponder it over lunch...

19:19 <rfs613> to me, there is value in being able to distinguish whether the driver is in-kernel nor not (eg. userspace). They are different drivers, so they should have differnet compatible strings.

19:20 <rfs613> if Linux 6.12 gets a built-in driver, it will almost certainly not be drop-in compatible with the userspace one. The kernel one might have sysfs interface, or something else - in any case very different from userspace C code that talks the "spidev API"

19:20 <rfs613> and whatever userspace code would need to be change to talk to the in-kernel driver.

19:23 <rfs613> stepping back one level, I think the issue is that spidev (and UIO) are both more of an "interface" or "conduit" rather than an actual driver in the kernel sense. But we do fit them into the regular kernel driver framework, and so they must have some kind of device tree / platform / ACPI hook.

20:28 <rfs613> having "proper" names is a laudible goal, and I like the idea of having one DT, and letting the whatever linux/freebsd/etc find a driver for the hardware based on the compatible string.

20:30 <rfs613> but it is also quite common, esp during development, to only have the SPI controller, and "some" device(s) attached, it might change during board spins, the exact way the device needs to be setup evolves. Often it is just a matter of poking a few magic registers at startup, and doing this from userspace is far easier and simpler than writing a full kernel driver.

20:33 <rfs613> so having a simple way to support the latter case is useful, just like writing userspace code to talk to some hardware via UIO is often a safer choice (you've seen the kind of code that gets written by hardware-folks?!?)

23:25 <broonie> rfs613: the whole point with not putting spidev in the DT is that you can just do whatever makes sense at runtime, you’ve not baked in decisions that are specific to what you’re doing right now.

23:26 <broonie> You can change for a completely different software stack and not have to adjust the board description at all.

23:44 <javierm> rfs613: the user-space driver could just bind to spidev using the driver_override and bind sysfs entries

23:45 <javierm> as long as it uses whatever device is driving in the compatible string. That's a sensible thing to ask