devicetree.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Javier Carrasco <javier.carrasco.cruz@gmail.com>
To: Mark Brown <broonie@kernel.org>
Cc: Rob Herring <robh+dt@kernel.org>,
	Krzysztof Kozlowski <krzysztof.kozlowski+dt@linaro.org>,
	Conor Dooley <conor+dt@kernel.org>,
	Jean Delvare <jdelvare@suse.com>,
	Guenter Roeck <linux@roeck-us.net>,
	Jonathan Corbet <corbet@lwn.net>,
	Liam Girdwood <lgirdwood@gmail.com>,
	Rob Herring <robh@kernel.org>,
	devicetree@vger.kernel.org, linux-kernel@vger.kernel.org,
	linux-hwmon@vger.kernel.org, linux-doc@vger.kernel.org
Subject: Re: [PATCH v3 5/5] hwmon: Add support for Amphenol ChipCap 2
Date: Fri, 8 Dec 2023 16:09:29 +0100	[thread overview]
Message-ID: <79a9bb81-4488-47d1-a24e-f4abde097d43@gmail.com> (raw)
In-Reply-To: <6cce1b87-a9a9-4554-9dae-c24d1d276fb5@sirena.org.uk>

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

      reply	other threads:[~2023-12-08 15:09 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-12-07 19:44 [PATCH v3 0/5] hwmon: Add support for Amphenol ChipCap 2 Javier Carrasco
2023-12-07 19:44 ` [PATCH v3 1/5] dt-bindings: vendor-prefixes: add Amphenol Javier Carrasco
2023-12-07 19:44 ` [PATCH v3 2/5] hwmon: (core) Add support for humidity min/max alarm Javier Carrasco
2023-12-07 19:44 ` [PATCH v3 3/5] ABI: sysfs-class-hwmon: add descriptions for humidity min/max alarms Javier Carrasco
2023-12-07 19:44 ` [PATCH v3 4/5] dt-bindings: hwmon: Add Amphenol ChipCap 2 Javier Carrasco
2023-12-08 15:06   ` Conor Dooley
2023-12-07 19:44 ` [PATCH v3 5/5] hwmon: Add support for " Javier Carrasco
2023-12-07 20:05   ` Mark Brown
2023-12-07 20:34     ` Javier Carrasco
2023-12-07 20:44       ` Mark Brown
2023-12-08 15:09         ` Javier Carrasco [this message]

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=79a9bb81-4488-47d1-a24e-f4abde097d43@gmail.com \
    --to=javier.carrasco.cruz@gmail.com \
    --cc=broonie@kernel.org \
    --cc=conor+dt@kernel.org \
    --cc=corbet@lwn.net \
    --cc=devicetree@vger.kernel.org \
    --cc=jdelvare@suse.com \
    --cc=krzysztof.kozlowski+dt@linaro.org \
    --cc=lgirdwood@gmail.com \
    --cc=linux-doc@vger.kernel.org \
    --cc=linux-hwmon@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux@roeck-us.net \
    --cc=robh+dt@kernel.org \
    --cc=robh@kernel.org \
    /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).