linux-kernel - Re: [PATCH v2 2/3] hwmon: (pmbus/core): Add regulator event support

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <f80f8929-c256-71b5-3a67-ad27800a40a9@gmail.com>
Date:   Wed, 12 Apr 2023 11:12:42 +0300
From:   Matti Vaittinen <mazziesaccount@...il.com>
To:     Mark Brown <broonie@...nel.org>
Cc:     Guenter Roeck <linux@...ck-us.net>,
        Naresh Solanki <naresh.solanki@...ements.com>,
        linux-hwmon@...r.kernel.org, Jean Delvare <jdelvare@...e.com>,
        Patrick Rudolph <patrick.rudolph@...ements.com>,
        linux-kernel@...r.kernel.org, Sascha Hauer <sha@...gutronix.de>,
        jerome Neanne <jneanne@...libre.com>,
        "Mutanen, Mikko" <Mikko.Mutanen@...rohmeurope.com>
Subject: Re: [PATCH v2 2/3] hwmon: (pmbus/core): Add regulator event support

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@...nel.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! ~~