Thread (18 messages) 18 messages, 5 authors, 2021-10-25

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
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help