public inbox for linux-hwmon@vger.kernel.org
 help / color / mirror / Atom feed
From: Zev Weiss <zev@bewilderbeest.net>
To: Mark Brown <broonie@kernel.org>
Cc: Guenter Roeck <linux@roeck-us.net>,
	Jean Delvare <jdelvare@suse.com>,
	linux-hwmon@vger.kernel.org, Andrew Jeffery <andrew@aj.id.au>,
	Liam Girdwood <lgirdwood@gmail.com>,
	linux-kernel@vger.kernel.org, openbmc@lists.ozlabs.org
Subject: Re: Enabling pmbus power control
Date: Tue, 20 Apr 2021 13:54:10 -0500	[thread overview]
Message-ID: <YH8jUuOEJKDDDoMb@hatter.bewilderbeest.net> (raw)
In-Reply-To: <20210420171540.GG6073@sirena.org.uk>

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


  reply	other threads:[~2021-04-20 18:54 UTC|newest]

Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-03-30  8:17 Enabling pmbus power control Zev Weiss
2021-03-30 10:34 ` Guenter Roeck
2021-03-30 11:22   ` Mark Brown
2021-03-30 17:19     ` Zev Weiss
2021-03-30 17:42       ` Mark Brown
2021-03-30 17:56         ` Zev Weiss
2021-03-30 18:02           ` Mark Brown
2021-03-30 19:38             ` Guenter Roeck
2021-04-20  1:29               ` Zev Weiss
2021-04-20  3:36                 ` Guenter Roeck
2021-04-20  5:50                   ` Zev Weiss
2021-04-20  6:00                     ` Guenter Roeck
2021-04-20  7:06                       ` Zev Weiss
2021-04-20 10:52                         ` Guenter Roeck
2021-04-20 15:19                           ` Zev Weiss
2021-04-20 16:13                             ` Mark Brown
2021-04-20 16:40                               ` Zev Weiss
2021-04-20 17:15                                 ` Mark Brown
2021-04-20 18:54                                   ` Zev Weiss [this message]
2021-04-21 11:05                                     ` Mark Brown
2021-04-21 18:29                                       ` Zev Weiss

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=YH8jUuOEJKDDDoMb@hatter.bewilderbeest.net \
    --to=zev@bewilderbeest.net \
    --cc=andrew@aj.id.au \
    --cc=broonie@kernel.org \
    --cc=jdelvare@suse.com \
    --cc=lgirdwood@gmail.com \
    --cc=linux-hwmon@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux@roeck-us.net \
    --cc=openbmc@lists.ozlabs.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox