linux-kernel - Re: [PATCH v3 5/5] hwmon: Add support for Amphenol ChipCap 2

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] [day] [month] [year] [list]

Message-ID: <79a9bb81-4488-47d1-a24e-f4abde097d43@gmail.com>
Date:   Fri, 8 Dec 2023 16:09:29 +0100
From:   Javier Carrasco <javier.carrasco.cruz@...il.com>
To:     Mark Brown <broonie@...nel.org>
Cc:     Rob Herring <robh+dt@...nel.org>,
        Krzysztof Kozlowski <krzysztof.kozlowski+dt@...aro.org>,
        Conor Dooley <conor+dt@...nel.org>,
        Jean Delvare <jdelvare@...e.com>,
        Guenter Roeck <linux@...ck-us.net>,
        Jonathan Corbet <corbet@....net>,
        Liam Girdwood <lgirdwood@...il.com>,
        Rob Herring <robh@...nel.org>, devicetree@...r.kernel.org,
        linux-kernel@...r.kernel.org, linux-hwmon@...r.kernel.org,
        linux-doc@...r.kernel.org
Subject: Re: [PATCH v3 5/5] hwmon: Add support for Amphenol ChipCap 2

On 07.12.23 21:44, Mark Brown wrote:

> There is a specific API for exclusive regulators which the driver is not
> using, and it's unconditionally doing the disable/enable cycle here.
> 

That is right, I will call regulator_get_exclusive() instead.

> The driver needs to be explicitly configured for this and have separate
> code paths for normal operation and operation where the supply can be
> bounced like this.  In neither code path should the supply be optional.
> Right now we don't have a mechanism for discovering optionally exclusive
> and enable/disablable supplies which is what the device needs, we could
> potentially add that since this does seem like a viable use case and we
> already have enough information in the DT to say if the supply matches
> the constraints.  Probably the two properties queryable separately.  If
> that API were added then the driver would do a normal regulator_get()
> then check if it has the capabilities it needs and either keep the
> supply on all the time (or possibly just during measurements?) or enable
> the alarm functionality.
In that case I will split the driver development into two steps. First I
will stick to the existing API and implement only the code path where an
exclusive regulator is required i.e. not optional, which will simplify
the review process considerably.

When the driver makes it through and all other issues are also solved, I
will work on the optional exclusive regulator. This is probably an edge
case and it will increase complexity to actually use half of the device
capabilities to save the exclusive regulator, but at some point I would
like to offer that as well.

Thank you again and best regards,
Javier Carrasco