On 10/23/21 3:56 AM, Greg Kroah-Hartman wrote: > On Fri, Oct 22, 2021 at 10:18:11AM -0500, Patrick Williams wrote: >> Hi Greg, >> >> On Fri, Oct 22, 2021 at 10:57:21AM +0200, Greg Kroah-Hartman wrote: >>> On Fri, Oct 22, 2021 at 01:32:32AM -0700, Zev Weiss wrote: >>>> On Thu, Oct 21, 2021 at 11:46:56PM PDT, Greg Kroah-Hartman wrote: >>>>> On Thu, Oct 21, 2021 at 07:00:31PM -0700, Zev Weiss wrote: >> >>>> So we want the kernel to be aware of the device's existence (so that we >>>> *can* bind a driver to it when needed), but we don't want it touching the >>>> device unless we really ask for it. >>>> >>>> Does that help clarify the motivation for wanting this functionality? >>> >>> Sure, then just do this type of thing in the driver itself. Do not have >>> any matching "ids" for this hardware it so that the bus will never call >>> the probe function for this hardware _until_ a manual write happens to >>> the driver's "bind" sysfs file. >> >> It sounds like you're suggesting a change to one particular driver to satisfy >> this one particular case (and maybe I'm just not understanding your suggestion). >> For a BMC, this is a pretty regular situation and not just as one-off as Zev's >> example. >> >> Another good example is where a system can have optional riser cards with a >> whole tree of devices that might be on that riser card (and there might be >> different variants of a riser card that could go in the same slot). Usually >> there is an EEPROM of some sort at a well-known address that can be parsed to >> identify which kind of riser card it is and then the appropriate sub-devices can >> be enumerated. That EEPROM parsing is something that is currently done in >> userspace due to the complexity and often vendor-specific nature of it. >> >> Many of these devices require quite a bit more configuration information than >> can be passed along a `bind` call. I believe it has been suggested previously >> that this riser-card scenario could also be solved with dynamic loading of DT >> snippets, but that support seems simple pretty far from being merged. > > Then work to get the DT code merged! Do not try to create > yet-another-way of doing things here if DT overlays is the correct > solution here (and it seems like it is.) I don't think this is a case that fits the overlay model. We know what the description of the device is (which is what devicetree is all about), but the device is to be shared between the Linux kernel and some other entity, such as the firmware or another OS. The issue to be resolved is how to describe that the device is to be shared (in this case exclusively by the kernel _or_ by the other entity at any given moment), and how to move ownership of the device between the Linux kernel and the other entity. In the scenario presented by Zev, it is suggested that a user space agent will be involved in deciding which entity owns the device and to tell the Linux kernel when to take ownership of the device (and presumably when to relinquish ownership, although we haven't seen the implementation of relinquishing ownership yet). One could imagine direct communication between the driver and the other entity to mediate ownership. That seems like a driver specific defined choice to me, though if there are enough different drivers facing this situation then eventually a shared framework would make sense. So to step back and think architecture, it seems to me that the devicetree needs to specify in the node describing the shared device that the device must be (1) owned exclusively by either the Linux kernel or some other entity, with a signalling method between the Linux kernel and the other entity being defined (possibly by information in the node or possibly by the definition of the driver) or (2) actively shared by both the Linux kernel and the other entity. Actively shared may or may not be possible, based on the specific hardware. For example, if a single contains some bits controlled by the Linux kernel and other bits controlled by the other entity, then it can be difficult for one of the two entities to atomically modify the register in coordination with the other entity. Obviously case 1 is much simpler than case 2, I'm just trying to create a picture of the potential cases. In a simpler version of case 2, each entity would have control of their own set of registers. Diverging away from the overlay question, to comment on the "status" property mentioned elsewhere in this thread, I do not think that a status value of "reserved" is an adequate method of conveying all of the information needed by the above range of scenarios. -Frank > > thanks, > > greg k-h >
