On Tue, Apr 20, 2021 at 11:40:24AM -0500, Zev Weiss wrote: > On Tue, Apr 20, 2021 at 11:13:18AM CDT, Mark Brown wrote: > > I already suggested writing a driver or drivers that represent the > > hardware you have, that advice remains. It's hard to follow what you > > were trying to say with your long mail earlier today but it seems like > That email was an attempt to explain why writing a driver for the specific > hardware devices we're powering seems like a poor fit to me. To summarize: > - There's a wide variety of different devices potentially behind an > LM25066. This is true for lots of hardware, we still integrate things into frameworks. > - A hypothetical driver for any one of them would be completely > non-specific to that device and functionally identical to a driver for > any other, because the only hardware it would actually be touching is the > LM25066, and in ways that are again completely non-specific to anything > but the LM25066 itself. I don't see why that would be the case at all. Even within the indended application as a power controller for a hotpluggable bus there's plenty of potential for integration into a wider representation of the socket things get inserted into - for example I've worked with buses that had support for operator signalling of hotplug (buttons to press to initiate hot removal, with lights to signal when a clean shutdown of the card had been completed), you might also want to have additional environment monitoring and of course the labelling that I mentioned in an earlier post. I can imagine you probably have some other connection of some kind to the host too (eg, network ports) to join up and perhaps sync hotplug for. > I'm not at all opposed to using a abstractions or frameworks (I'd very much > like to do so in fact). The problem is that I've thus far been unable to > determine exactly what the appropriate one is. Perhaps you need to write some kind of generic system for hotplugging modules if you can't find one.
Attachment:
signature.asc
Description: PGP signature
