LKML Archive on
help / color / mirror / Atom feed
From: Andreas Kemnade <>
Cc: Andreas Kemnade <>
Subject: [PATCH RFC] regulator: core: fix handling negative voltages e.g. in EPD PMICs
Date: Sun, 23 Feb 2020 16:35:01 +0100	[thread overview]
Message-ID: <> (raw)

Basically regulator_get_voltage() returns the voltage and
 -Esomething on error. If the voltage is negative, results of
regulator_ops->get_voltage() are interpreted as error in the core,
so even if a consumer can handle negative voltages, it won't
get access to the regulator because the regulator will not be
registered at all due to a failing set_machine_constraints() call.

An alternative would be to handle voltages as absolute values.
There are probably no regulators with support both negative
and positive output.

The patch solves only the registration problem and does not fix
everything involved.

It has to be checked whether there is anything in mainline kernel
which uses negative voltages.

There are several regulator drivers found in the wild (often with
kernel version <= 4.1.15) for EPD PMICs which use negative
voltages for their VCOM regulator:
- sy7636
- fp9928
- tps6518x
- max17135

consumer is e.g. the EPDC of imx6 SoCs which is not in mainline.
Typical out-of-tree devicetrees contain snippets like this:
 VCOM_reg: VCOM {
      regulator-name = "VCOM";
      /* 2's-compliment, -4325000 */
      regulator-min-microvolt = <0xffbe0178>;
      /* 2's-compliment, -500000 */
      regulator-max-microvolt = <0xfff85ee0>;

This kind of description will cause trouble as soon as these
uint32_t are casted to an int64_t (now they are casted to int
on 32bit architectures).

For the following devices which contain the tps6518x there are
partial devicetrees in mainline:
- Kobo Aura (N514)
- Kobo Clara HD
- Tolino Shine 3

No idea about the "Amazon Kindle Fire (first generation)"
which also has a partial devicetree in mainline.

Before cleaning up these drivers for upstreaming it would be
good to know which road to go in regards of negative voltages.

If we go the road with absolute voltages, there is a risk of
accidential booting a vendor devicetree with mainline kernel
this kind of negative voltages, which might cause bogous setups
so maybe voltages with bit 31 set should be filtered by the core,
besides of additional checking in the drivers itself.
Lukily form my experience, these out-of-tree devicetrees for
imx6 systems are incompatible enough to not boot even to a serial

Signed-off-by: Andreas Kemnade <>
 drivers/regulator/core.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/drivers/regulator/core.c b/drivers/regulator/core.c
index d015d99cb59d..2f2f31c3b9f1 100644
--- a/drivers/regulator/core.c
+++ b/drivers/regulator/core.c
@@ -1129,7 +1129,7 @@ static int machine_constraints_voltage(struct regulator_dev *rdev,
 			current_uV = regulator_get_voltage_rdev(rdev);
-		if (current_uV < 0) {
+		if ((current_uV < 0) && (current_uV > -MAX_ERRNO)) {
 				 "failed to get the current voltage(%d)\n",
@@ -3022,7 +3022,7 @@ int regulator_is_supported_voltage(struct regulator *regulator,
 	/* If we can't change voltage check the current voltage */
 	if (!regulator_ops_is_valid(rdev, REGULATOR_CHANGE_VOLTAGE)) {
 		ret = regulator_get_voltage(regulator);
-		if (ret >= 0)
+		if ((ret >= 0) || (ret < -MAX_ERRNO))
 			return min_uV <= ret && ret <= max_uV;
 			return ret;
@@ -4031,7 +4031,7 @@ int regulator_get_voltage_rdev(struct regulator_dev *rdev)
 		return -EINVAL;
-	if (ret < 0)
+	if ((ret < 0) && (ret > -MAX_ERRNO))
 		return ret;
 	return ret - rdev->constraints->uV_offset;

             reply	other threads:[~2020-02-23 15:35 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-02-23 15:35 Andreas Kemnade [this message]
2020-02-24 12:05 ` Mark Brown
2020-02-24 12:22   ` H. Nikolaus Schaller
2020-02-24 12:31     ` Mark Brown
2020-02-24 18:46   ` Andreas Kemnade
2020-02-24 15:21 ` Denis 'GNUtoo' Carikli
2020-02-24 17:00   ` Mark Brown

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:

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \ \ \ \ \ \ \ \ \ \ \
    --subject='Re: [PATCH RFC] regulator: core: fix handling negative voltages e.g. in EPD PMICs' \

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link

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