[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <YtqabjVY1vRgjZlM@sirena.org.uk>
Date: Fri, 22 Jul 2022 13:39:10 +0100
From: Mark Brown <broonie@...nel.org>
To: jerome Neanne <jneanne@...libre.com>
Cc: lgirdwood@...il.com, robh+dt@...nel.org, nm@...com,
kristo@...nel.org, khilman@...libre.com, narmstrong@...libre.com,
msp@...libre.com, j-keerthy@...c, lee.jones@...aro.org,
linux-kernel@...r.kernel.org, devicetree@...r.kernel.org,
linux-arm-kernel@...ts.infradead.org
Subject: Re: [PATCH v1 08/14] regulator: drivers: Add TI TPS65219 PMIC
regulators support
On Fri, Jul 22, 2022 at 12:12:05PM +0200, jerome Neanne wrote:
> On 19/07/2022 15:32, Mark Brown wrote:
> > On Tue, Jul 19, 2022 at 11:17:36AM +0200, Jerome Neanne wrote:
> Refactoring the code with regulator_notifier_call_chain, I realized that
> some of the events in TPS65219 are not listed as standard REGULATOR_EVENT in
> consumer.h
>
> This is the case for below event list:
> REGULATOR_EVENT_SCG (ShortCut to Gnd)
>
> REGULATOR_EVENT_RV (Residual Voltage)
>
> REGULATOR_EVENT_RV_SD (Residual Voltage ShutDown)
>
> Should I add those events to the list of standard regulator events and
> assign a code? (if yes, any rule for the values?)
> Would it fit with some other predefined standard macro defined elsewhere?
> (if yes, could you point me to the right location?)
Map them onto the existing values, the exact mapping will depend on what
those events mean, force disable or out of regulation look like likely
candidates for example. If there's anything that's just not covered
then perhaps a new event type is needed.
Please delete unneeded context from mails when replying. Doing this
makes it much easier to find your reply in the message, helping ensure
it won't be missed by people scrolling through the irrelevant quoted
material.
Download attachment "signature.asc" of type "application/pgp-signature" (489 bytes)
Powered by blists - more mailing lists