summaryrefslogtreecommitdiff
path: root/Documentation/driver-api/driver-model/binding.rst
AgeCommit message (Collapse)Author
2026-03-17docs: driver-model: document driver_overrideDanilo Krummrich
Now that we support driver_override as a driver-core feature through struct device and struct bus_type, add some documentation in the context of how a device / driver binding is established. Reviewed-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Link: https://patch.msgid.link/20260303115720.48783-3-dakr@kernel.org Signed-off-by: Danilo Krummrich <dakr@kernel.org>
2026-01-16driver-core: improve driver binding documentationDanilo Krummrich
The driver binding documentation (still) mentions that "When a driver is attached to a device, the device is inserted into the driver's list of devices.". While it is true that the driver-core keeps track of all the devices that are attached to a driver, this is purely for internal purposes (i.e. it is an implementation detail) and has no relevance for user facing documentation. In fact, it is even misleading, since it could be read as if it were valid for driver implementations to keep track of all the devices bound to it. Instead, drivers operate on a per-device basis, with a separate per-device instance created when the driver is bound to a device. Hence, remove the mention of a driver's list of devices and instead add some documentation of the relationship between drivers and devices. Signed-off-by: Danilo Krummrich <dakr@kernel.org> Reviewed-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Jonathan Corbet <corbet@lwn.net> Message-ID: <20260115215718.6405-1-dakr@kernel.org>
2019-07-15docs: driver-model: move it to the driver-api bookMauro Carvalho Chehab
The audience for the Kernel driver-model is clearly Kernel hackers. Signed-off-by: Mauro Carvalho Chehab <mchehab+samsung@kernel.org> Acked-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com> # ice driver changes