linux-hwmon.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Mark Brown <broonie@kernel.org>
To: Matti Vaittinen <mazziesaccount@gmail.com>
Cc: Guenter Roeck <linux@roeck-us.net>,
	Naresh Solanki <naresh.solanki@9elements.com>,
	linux-hwmon@vger.kernel.org, Jean Delvare <jdelvare@suse.com>,
	Patrick Rudolph <patrick.rudolph@9elements.com>,
	linux-kernel@vger.kernel.org, Sascha Hauer <sha@pengutronix.de>,
	jerome Neanne <jneanne@baylibre.com>,
	"Mutanen, Mikko" <Mikko.Mutanen@fi.rohmeurope.com>
Subject: Re: [PATCH v2 2/3] hwmon: (pmbus/core): Add regulator event support
Date: Tue, 11 Apr 2023 13:07:49 +0100	[thread overview]
Message-ID: <74f9ebff-3e6f-496f-a776-5bd4650c566c@sirena.org.uk> (raw)
In-Reply-To: <CANhJrGMkwi1TVW_wGw=Boj1vRO_wGrd9=atOxKfbbdM4cwPGsw@mail.gmail.com>

[-- Attachment #1: Type: text/plain, Size: 1696 bytes --]

On Mon, Apr 10, 2023 at 11:19:41AM +0300, Matti Vaittinen wrote:
> to 6. huhtik. 2023 klo 16.43 Mark Brown (broonie@kernel.org) kirjoitti:

> > I'm not sure what you're expecting there?  A device working with itself
> > shouldn't disrupt any other users.

> I have no concrete idea, just a vague uneasy feeling knowing that
> devices tend to interact with each other. I guess it is more about the
> amount of uncertainty caused by my lack of knowledge regarding what
> could be done by these handlers. So, as I already said - if no one
> else is bothered by this then I definitely don't want to block the
> series. Still, if the error handling should be kept internal to PMBus
> - then we should probably either say that consumer drivers must not
> (forcibly) turn off the supply when receiving these notifications - or
> not send these notifications from PMBus and allow PMBus to decide
> error handling internally. (Again, I don't know if any in-tree
> consumer drivers do turn off the supply regulator in error handlers -
> but I don't think it is actually forbidden). Or am I just making  a
> problem that does not exist?

I think you are making a problem that doesn't exist.

> > Like I say I'm not sure how much practical difference it makes to think
> > too hard about differentiating the errors.

> I would do at least two classes.

> 1) critical class - it is Ok for the consumer to forcibly shut down
> the regulator, or maybe the whole system.
> 2) warning class - it is not Ok to forcibly shut down the regulator.

How severe an issue bad power is will be partly determined by what the
consumer is doing with the power, it's going to be in a fairly narrow
range but there is a range.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

  parent reply	other threads:[~2023-04-11 12:08 UTC|newest]

Thread overview: 22+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-03-28 15:03 [PATCH v2 1/3] hwmon: (pmbus/core): Add rdev in pmbus_data struct Naresh Solanki
2023-03-28 15:03 ` [PATCH v2 2/3] hwmon: (pmbus/core): Add regulator event support Naresh Solanki
2023-03-29  6:48   ` Matti Vaittinen
2023-04-05 13:15     ` Guenter Roeck
2023-04-05 13:57       ` Matti Vaittinen
2023-04-05 14:18         ` Guenter Roeck
2023-04-05 15:19           ` Mark Brown
2023-04-06  8:00             ` Matti Vaittinen
2023-04-06 13:43               ` Mark Brown
2023-04-10  8:19                 ` Matti Vaittinen
2023-04-10 14:40                   ` Guenter Roeck
2023-04-10 16:53                     ` Matti Vaittinen
2023-04-10 17:47                       ` Guenter Roeck
2023-04-11  6:10                         ` Matti Vaittinen
2023-04-11 11:08                         ` Mark Brown
2023-04-11 12:07                   ` Mark Brown [this message]
2023-04-12  8:12                     ` Matti Vaittinen
2023-04-11  9:12                 ` Matti Vaittinen
2023-04-12 15:13   ` Guenter Roeck
2023-03-28 15:03 ` [PATCH v2 3/3] hwmon: (pmbus/core): Notify regulator events Naresh Solanki
2023-04-12 15:16   ` Guenter Roeck
2023-04-12 15:12 ` [PATCH v2 1/3] hwmon: (pmbus/core): Add rdev in pmbus_data struct Guenter Roeck

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=74f9ebff-3e6f-496f-a776-5bd4650c566c@sirena.org.uk \
    --to=broonie@kernel.org \
    --cc=Mikko.Mutanen@fi.rohmeurope.com \
    --cc=jdelvare@suse.com \
    --cc=jneanne@baylibre.com \
    --cc=linux-hwmon@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux@roeck-us.net \
    --cc=mazziesaccount@gmail.com \
    --cc=naresh.solanki@9elements.com \
    --cc=patrick.rudolph@9elements.com \
    --cc=sha@pengutronix.de \
    /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;
as well as URLs for NNTP newsgroup(s).