Re: [PATCH 10/17] driver core: Expose device trust authorization through sysfs

[Andrew Lunn]

> Yup, and that's true even in the PCI TDISP case - there's a major amount of
> "communication" and "configuration" involved in that. The principle which
> should (hopefully) generalise is that a bus/host controller driver can
> always interrogate its child device to perform whatever attestation and
> general configuration is appropriate, but we won't hand off any _control_ of
> that device to a specific device driver (nor enable potentially-impactful
> bus-level features like DMA, interrupts, etc. if relevant) without the
> requisite agreement between the bus code and the user.

Maybe it would be good to list subsystems which the bus driver can
use, and cannot use.

You list interrupts as potentially being dangerous. What about reset
controllers, GPIOs, regulators? At least in the embedded world, the
bus driver might need to enable power, set a clock ticking, and take
the device out of reset via a GPIO, before the device pops into
existence and will enumerate on the bus.

I don't see why interrupts are dangerous, which makes it hard for me
to determine if GPIOs and clocks, and regulators are also dangerous?

   Andrew