Speaker
Description
Driver Core Microconference focuses on general problems of the linux kernel driver model.
The goal is to discuss the various aspects and problems of device driver core, platform and auxiliary devices, subsystem architecture, firmware description, fw_devlink, API design and object life-time issues.
Current problems:
Object life-time issues and proposed solutions
Decades-long problem. There have been several attempts at addressing the multiple issues and a few previous talks at LPC and other conferences.
a) Revocable: there's an ongoing effort to provide a unified API for protecting resources against sudden removal of their dependencies. Example: unbinding a resource provider driver to which consumers still hold references. (current revision on the list)
b) I2C bus unbind path: Bartosz Golaszewski proposed a way for a gradual rework of I2C core in order to remove the wait_for_completion() call blocking the kernel thread removing the bus driver until all consumers put their references. Johan Hovold argued the rework can be more in-depth and result in a better outcome. It would be useful to discuss the current state. Work on this seems to be ongoing.. Previous email from Wolfram
Provider/consumer/device API best practices
When discussing the i2c changes, Johan and Bartosz argued about the approach to linux subsystem API design. It would make sense to discuss if there's an "idiomatic" way to design driver interfaces and what it should be. Discussion.
Firmware devlinks
a) Should fw_devlink be enforced for everyone? (Saravana Kannan floated the idea during the Devicetree MC at LPC 25).
b) Adding support for fw_devlink to software nodes. Bartosz Golaszewski is working on this to decrease the number of probe deferrals for software node GPIO lookups which are used extensively on some older but still maintained platforms as well as on x86 platform drivers for which devices are not well described in ACPI.
c) Ulf Hansson proposed a talk titled: "Evolving sync state support to other subsystems beyond genpd".
Device/subsystem API abuse
a) When documentation says one thing and users do another. How to deal with API abuse.
b) Patches using legacy APIs that can't always be spotted by relevant maintainers in time. How to better deprecate APIs.
Platform/auxiliary/faux buses
Let's discuss using dynamically instantiated, "virtual" devices for handling of various corner-cases. There have been several such changes in recent months, for example: in reset and GPIO subsystems.
Firmware node API and its implementations
a) There's an ongoing effort in the GPIO subsystem to remove the string-matching behavior of software node lookup. Let's discuss why attaching software nodes to target devices and enforcing real firmware node links when setting up references is better.
b) Dynamically referencing "real" firmware nodes (OF-nodes, ACPI nodes) from software nodes.
c) Using software nodes as primary firmware nodes for certain devices. This is already done for MFD cells and some auxiliary devices. Is allowing to match devices to drivers by software nodes something worth considering?
d) Converting subsystems to be "fwnode-agnostic". (Example rework)
Devres
It still appears that quite frequently developers seem to misunderstand how devres interfaces work and when exactly the unwinding of resources will happen. Patches are being sent where drivers try to schedule devres actions on devices they don't control or on ones that aren't even bound to drivers. This has led people to blame devres for life-time issues the culprit of which lies with incorrect usage of the API. Can we replicate the Bound context from rust in C?
Key attendees:
Confirmed: Geert Uytterhoeven, Laurent Pinchart, Ulf Hansson, Chen-Yu Tsai, Neil Armstrong, Krzysztof Kozlowski, Hans de Goede, Kevin Hilman, Greg Kroah-Hartman, Marek Vasut, Abel Vesa, Manivannan Sadhasivam, Herve Codina, Danilo Krummrich, Rafael J. Wysocki, Dmitry Baryshkov, Vinod Koul, Srinivas Kandagatla
Likely: Wolfram Sang, Conor Dooley, Dmitry Torokhov, Andy Shevchenko, Drew Fustini