Skip to content

L
linux
Switch branch/tag
  1. 09 Sep, 2022 1 commit
  3. 08 Sep, 2022 1 commit
  5. 05 Sep, 2022 2 commits
  7. 29 Aug, 2022 1 commit
  9. 28 Aug, 2022 1 commit
  11. 25 Aug, 2022 3 commits
    • Douglas Anderson's avatar
      regulator: core: Don't err if allow-set-load but no allowed-modes · 57919f4a
      Douglas Anderson authored 
      Apparently the device trees of some boards have the property
"regulator-allow-set-load" for some of their regulators but then they
don't specify anything for "regulator-allowed-modes". That's not
really legit, but...

...before commit efb0cb50 ("regulator: qcom-rpmh: Implement
get_optimum_mode(), not set_load()") they used to get away with it, at
least on boards using RPMH regulators. That's because when a regulator
driver implements set_load() then the core doesn't look at
"regulator-allowed-modes" when trying to automatically adjust things
in response to the regulator's load. The core doesn't know what mode
we'll end up in, so how could it validate it?

Said another way: before commit efb0cb50 ("regulator: qcom-rpmh:
Implement get_optimum_mode(), not set_load()") some boards _were_
having the regulator mode adjusted despite listing no allowed
modes. After commit efb0cb50 ("regulator: qcom-rpmh: Implement
get_optimum_mode(), not set_load()") these same boards were now
getting an error returned when trying to use their regulators, since
simply enabling a regulator tries to update its load and that was
failing.

We don't really want to go back to the behavior from before commit
efb0cb50 ("regulator: qcom-rpmh: Implement get_optimum_mode(), not
set_load()"). Boards shouldn't have been changing modes if no allowed
modes were listed. However, the behavior after commit efb0cb50
("regulator: qcom-rpmh: Implement get_optimum_mode(), not set_load()")
isn't the best because now boards can't even turn their regulators on.

Let's choose to detect this case and return "no error" from
drms_uA_update(). The net-result will be _different_ behavior than we
had before commit efb0cb50 ("regulator: qcom-rpmh: Implement
get_optimum_mode(), not set_load()"), but this new behavior seems more
correct. If a board truly needed the mode switched then its device
tree should be updated to list the allowed modes.
Reported-by: default avatarAndrew Halaney <ahalaney@redhat.com>
Fixes: efb0cb50 ("regulator: qcom-rpmh: Implement get_optimum_mode(), not set_load()")
Signed-off-by: default avatarDouglas Anderson <dianders@chromium.org>
Tested-by: default avatarAndrew Halaney <ahalaney@redhat.com>
Link: https://lore.kernel.org/r/20220824142229.RFT.v2.2.I6f77860e5cd98bf5c67208fa9edda4a08847c304@changeidSigned-off-by: default avatarMark Brown <broonie@kernel.org>
      57919f4a
    • Douglas Anderson's avatar
      regulator: core: Require regulator drivers to check uV for get_optimum_mode() · 55841199
      Douglas Anderson authored 
      The get_optimum_mode() for regulator drivers is passed the input
voltage and output voltage as well as the current. This is because, in
theory, the optimum mode can depend on all three things.

It turns out that for all regulator drivers in mainline only the
current is looked at when implementing get_optimum_mode(). None of the
drivers take the input or output voltage into account. Despite the
fact that none of the drivers take the input or output voltage into
account, though, the regulator framework will error out before calling
into get_optimum_mode() if it doesn't know the input or output
voltage.

The above behavior turned out to be a probelm for some boards when we
landed commit efb0cb50 ("regulator: qcom-rpmh: Implement
get_optimum_mode(), not set_load()"). Before that change we'd have no
problems running drms_uA_update() for RPMH regulators even if a
regulator's input or output voltage was unknown. After that change
drms_uA_update() started to fail. This is because typically boards
using RPMH regulators don't model the input supplies of RPMH
regulators. Input supplies for RPMH regulators nearly always come from
the output of other RPMH regulators (or always-on regulators) and RPMH
firmware is initialized with this knowledge and handles enabling (and
adjusting the voltage of) input supplies. While we could model the
parent/child relationship of the regulators in Linux, many boards
don't bother since it adds extra overhead.

Let's change the regulator core to make things work again. Now if we
fail to get the input or output voltage we'll still call into
get_optimum_mode() and we'll just pass error codes in for input_uV
and/or output_uV parameters.

Since no existing regulator drivers even look at input_uV and
output_uV we don't need to add this error handling anywhere right
now. We'll add some comments in the core so that it's obvious that (if
regulator drivers care) it's up to them to add the checks.
Reported-by: default avatarAndrew Halaney <ahalaney@redhat.com>
Fixes: efb0cb50 ("regulator: qcom-rpmh: Implement get_optimum_mode(), not set_load()")
Signed-off-by: default avatarDouglas Anderson <dianders@chromium.org>
Tested-by: default avatarAndrew Halaney <ahalaney@redhat.com>
Link: https://lore.kernel.org/r/20220824142229.RFT.v2.1.I137e6bef4f6d517be7b081be926059321102fd3d@changeidSigned-off-by: default avatarMark Brown <broonie@kernel.org>
      55841199
    • Yang Li's avatar
      regulator: drivers: Remove unnecessary print function dev_err() · d46f7372
      Yang Li authored 
      The print function dev_err() is redundant because
platform_get_irq_byname() already prints an error.

Link: https://bugzilla.openanolis.cn/show_bug.cgi?id=1986Reported-by: default avatarAbaci Robot <abaci@linux.alibaba.com>
Signed-off-by: default avatarYang Li <yang.lee@linux.alibaba.com>
Link: https://lore.kernel.org/r/20220825070438.128093-1-yang.lee@linux.alibaba.comSigned-off-by: default avatarMark Brown <broonie@kernel.org>
      d46f7372
  13. 24 Aug, 2022 1 commit
  15. 23 Aug, 2022 20 commits
  17. 22 Aug, 2022 1 commit
  19. 18 Aug, 2022 3 commits
    • Christian Kohlschütter's avatar
      regulator: core: Resolve supply name earlier to prevent double-init · 8a866d52
      Christian Kohlschütter authored 
      Previously, an unresolved regulator supply reference upon calling
regulator_register on an always-on or boot-on regulator caused
set_machine_constraints to be called twice.

This in turn may initialize the regulator twice, leading to voltage
glitches that are timing-dependent. A simple, unrelated configuration
change may be enough to hide this problem, only to be surfaced by
chance.

One such example is the SD-Card voltage regulator in a NanoPI R4S that
would not initialize reliably unless the registration flow was just
complex enough to allow the regulator to properly reset between calls.

Fix this by re-arranging regulator_register, trying resolve the
regulator's supply early enough that set_machine_constraints does not
need to be called twice.
Signed-off-by: default avatarChristian Kohlschütter <christian@kohlschutter.com>
Link: https://lore.kernel.org/r/20220818124646.6005-1-christian@kohlschutter.comSigned-off-by: default avatarMark Brown <broonie@kernel.org>
      8a866d52
    • Mark Brown's avatar
      Devm helpers for regulator get and enable · ee94aff2
      Mark Brown authored 
      Merge series from Matti Vaittinen <mazziesaccount@gmail.com>:

A few* drivers seem to use pattern demonstrated by pseudocode:

- devm_regulator_get()
- regulator_enable()
- devm_add_action_or_reset(regulator_disable())

Introducing devm helpers for this pattern would remove bunch of code from
drivers. Typically following:

- replace 3 calls (devm_regulator_get[_optional](), regulator_enable(),
  devm_add_action_or_reset()) with just one
  (devm_regulator_get_enable[_optional]()).
- drop disable callback.
- remove stored pointer to struct regulator - which can lead to problem
  when an devm action for regulator_disable is used.

I believe this simplifies things by removing some dublicated code.

The suggested managed 'get_enable' APIs do not return the pointer to
regulators for user because any call to regulator_disable()
(or regulator_enable()) may easily lead to regulator enable count imbalance
upon device detach. (Eg, if someone calls regulator_disable() and the
device is then detached before user has re-enabled the regulator). Not
returning the pointer to obtained regulator to caller is a good hint that
the enable/disable should not be manually handled when these APIs are used.

OTOH, not returning the pointer reduces the use-cases by not allowing
the consumers to perform other regulator actions. For example request the
voltages. A few drivers which used the "get, enable,
devm_action_to_disable" did also query the voltages. The API does not suit
needs of such users.
      ee94aff2
    • Matti Vaittinen's avatar
      regulator: Add devm helpers for get and enable · da279e69
      Matti Vaittinen authored 
      A few regulator consumer drivers seem to be just getting a regulator,
enabling it and registering a devm-action to disable the regulator at
the driver detach and then forget about it.

We can simplify this a bit by adding a devm-helper for this pattern.
Add devm_regulator_get_enable() and devm_regulator_get_enable_optional()
Signed-off-by: default avatarMatti Vaittinen <mazziesaccount@gmail.com>
Link: https://lore.kernel.org/r/ed7b8841193bb9749d426f3cb3b199c9460794cd.1660292316.git.mazziesaccount@gmail.comSigned-off-by: default avatarMark Brown <broonie@kernel.org>
      da279e69
  21. 15 Aug, 2022 2 commits
  23. 14 Aug, 2022 4 commits
GitLab Nexedi Edition | About GitLab | About Nexedi | 沪ICP备2021021310号-2 | 沪ICP备2021021310号-7