On Tue, Apr 20, 2021 at 12:15:40PM CDT, Mark Brown wrote:
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.
Consider the power shelf I mentioned earlier -- it's a rackmount power
supply and that's about it. It provides DC power to arbitrary devices
that it has no other connection to, just ground and +12V. Those devices
might be servers, or cooling fans, or vacuum cleaners or floodlights --
the power shelf doesn't know, or care. It's a lot like a switchable
network PDU in that it just provides a way for an operator to remotely
cut power to a thing that's plugged into it. There's no other bus or
anything in the picture. (And pragmatically, given that its most common
usage is likely to be to provide a cold power cycle as a last-ditch
recovery option when things are wedged in some unresponsive state,
attempting any sort of coordination with the downstream device would
probably be a dead end anyway.)
Zev
