linux-hwmon.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Matti Vaittinen <mazziesaccount@gmail.com>
To: Mark Brown <broonie@kernel.org>
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: Wed, 12 Apr 2023 11:12:42 +0300	[thread overview]
Message-ID: <f80f8929-c256-71b5-3a67-ad27800a40a9@gmail.com> (raw)
In-Reply-To: <74f9ebff-3e6f-496f-a776-5bd4650c566c@sirena.org.uk>

On 4/11/23 15:07, Mark Brown wrote:
> 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.

In this case, sorry folks. I thought consumers could be more 'intrusive' 
with the handling of these notifications - which apparently is not true 
then. Guenter, I hope the statement from Mark cleared confusion I 
caused. I have no further questions about this series.

>>> 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.

No longer related to this patch series - I am still trying to gather 
information where the "detection" level PMIC warning IRQs are used in 
real-world systems. This might give me some insight how these 
notifications are (or could be) used.

Yours,
	-- Matti

-- 
Matti Vaittinen
Linux kernel developer at ROHM Semiconductors
Oulu Finland

~~ When things go utterly wrong vim users can always type :help! ~~


  reply	other threads:[~2023-04-12  8:12 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
2023-04-12  8:12                     ` Matti Vaittinen [this message]
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=f80f8929-c256-71b5-3a67-ad27800a40a9@gmail.com \
    --to=mazziesaccount@gmail.com \
    --cc=Mikko.Mutanen@fi.rohmeurope.com \
    --cc=broonie@kernel.org \
    --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=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).