On Thu, Oct 01, 2020 at 07:54:26PM +0000, Ertman, David M wrote: > > This means that every device has to reinvent the wheel for common > > resources like interrupts, including things like looking them up by name > > and so on. That doesn't seem ideal. > It's a shared header file between the device and driver implementer. If they > want to share a "struct irq_data *irq" as an element in the shared data, that is > fine, but not everyone will need to include that. This is why we left what is shared > up to the implementer, so that we don't impose a debt on some other > implementation that doesn't need it. Realistically I think you're saying this because this has taken so long already and you're being asked for more changes rather than because it's a good design decision. That is entirely understandable and reasonable but I'm not sure it's the best decision when we have so many common patterns between devices, one of the things that the current situtation handles well is allowing lots of common stuff to just be data definitions rather than code - there used to be a lot more open coding of resource sharing. One thing we should agree here is that we don't actually have to implement everything right now, we just need to understand what the design and direction of travel are. That means that at this point it's probably just a fairly quick documentation update rather than substantial code changes. > I suppose it is not the end of the world adding elements to the definition of > struct ancillary_device, but what would be a "universal" element to add? > Where do you draw the line on what you allow into the bus internals? The > overriding goal was to make a subsystem agnostic bus that doesn't impose > implementation specific details from any single subsystem. I think that this needs to grow everything that platform and MFD have so that we can avoid using platform devices to represent things that are not in the very strictest sense platform devices (which I interpret to be memory mapped devices that can't be enumerated in some fashion). My understanding here is that the goal is an abstraction cleanup, it's possible I've misunderstood though.
Attachment:
signature.asc
Description: PGP signature
