Re: [PATCH 4/5] driver core: inhibit automatic driver binding on reserved devices
From: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Date: 2021-10-23 08:56:55
Also in:
kvm, linux-devicetree, lkml, openbmc
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:quoted
On Fri, Oct 22, 2021 at 01:32:32AM -0700, Zev Weiss wrote:quoted
On Thu, Oct 21, 2021 at 11:46:56PM PDT, Greg Kroah-Hartman wrote:quoted
On Thu, Oct 21, 2021 at 07:00:31PM -0700, Zev Weiss wrote:quoted
quoted
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.) thanks, greg k-h