Hardware detection & quirking through the device tree

As part of hardware-desktop-n-xorg-configuration-the-final-ten-percent, we'd like to explore the potential of using the device tree to provide run-time information about the hardware that the kernel is running on.

We don't want to use this functionality for general hardware detection; the proposal here aims to provide a method of debugging and temporary work-arounds for known issues.

Use cases

• Overriding autodetected EDIDs with developer-supplied data
• Setting quirks for specific devices, without rebuilding the kernel

For both of these cases, we're aiming at situations where a developer can supply a temporary workaround to a specific issue. We're not looking for away for users to fix their own bugs, or long-term solutions for quirking.

Proposal

• Assess the state of x86 device tree support. A few patchsets have been posted recently, but may need some work. This will provide the infrastructure required for the device tree query functions.
• Add hooks to driver code to check for properties in the device tree representing probe-able data (eg EDID, presence of quirks)
  • Need to define a mapping between device nodes and devices; with existing device-tree usage, we're probing directly from the device tree, and so already have a reference to the specific device tree node to parse from. In this case though, we'll need to do a post-probe match instead. The semantics of this match will need to be clearly defined.
    • We'll need mappings at the each "component" (eg, card, output, connector) of device representation.
• Provide a user-visible interface to add or update device tree data that will persist between boots, allowing the device tree data to be specified before video driver probing occurs. For now, we could use the embedded dtb, which has recently been ported to x86. This will require the infrastructure for dtb loading to be enabled in the standard kernel.

Recommendation

While adding device tree query code to the drivers is fairly straightforward, but requires a couple of prerequisites before being feasible:

• solid platform support for device tree infrastructure, which is not yet present on x86.
• mechanisms to provide a device tree for early driver initialisation, and safely alter this non-volatile data from userspace.
• defined semantics for looking up already-probed devices in the device tree.

These prerequisites would form the majority of the work involved, and would probably make the work too complex. A simpler interface for updating quirk data may be more suitable, as it's unlikely that we'll need the full device-tree semantics to represent this hardware data.