mbox series

[0/2] regulator: vctrl: Avoid lockdep warning in enable/disable ops

Message ID 20210825033704.3307263-1-wenst@chromium.org (mailing list archive)
Headers show
Series regulator: vctrl: Avoid lockdep warning in enable/disable ops | expand

Message

Chen-Yu Tsai Aug. 25, 2021, 3:37 a.m. UTC
Hi,

Here are a couple fixes for vctrl-regulator. This driver is only used
RK3399-based Chromebooks.

Patch one fixes a misuse of the regulator API, which was found while
tracing the code to fix the lockdep warning.

Patch two fixes a lockdep warning and actual (not easy to reproduce)
deadlock.

Please have a look. The are no dependencies between the two patches.


Additionally, I believe it would make sense to implement the voltage
stepping feature for all regulators in the core. Then we could move
away from vctrl-regulator. Right now it is only done for coupled
regulators.


Regards
ChenYu


Chen-Yu Tsai (2):
  regulator: vctrl: Use locked regulator_get_voltage in probe path
  regulator: vctrl: Avoid lockdep warning in enable/disable ops

 drivers/regulator/vctrl-regulator.c | 73 +++++++++++++++++------------
 1 file changed, 43 insertions(+), 30 deletions(-)

Comments

Mark Brown Aug. 25, 2021, 3:18 p.m. UTC | #1
On Wed, 25 Aug 2021 11:37:02 +0800, Chen-Yu Tsai wrote:
> Here are a couple fixes for vctrl-regulator. This driver is only used
> RK3399-based Chromebooks.
> 
> Patch one fixes a misuse of the regulator API, which was found while
> tracing the code to fix the lockdep warning.
> 
> Patch two fixes a lockdep warning and actual (not easy to reproduce)
> deadlock.
> 
> [...]

Applied to

   https://git.kernel.org/pub/scm/linux/kernel/git/broonie/regulator.git for-next

Thanks!

[1/2] regulator: vctrl: Use locked regulator_get_voltage in probe path
      commit: 98e47570ba985f2310586c80409238200fa3170f
[2/2] regulator: vctrl: Avoid lockdep warning in enable/disable ops
      commit: 21e39809fd7c4b8ff3662f23e0168e87594c8ca8

All being well this means that it will be integrated into the linux-next
tree (usually sometime in the next 24 hours) and sent to Linus during
the next merge window (or sooner if it is a bug fix), however if
problems are discovered then the patch may be dropped or reverted.

You may get further e-mails resulting from automated or manual testing
and review of the tree, please engage with people reporting problems and
send followup patches addressing any issues that are reported if needed.

If any updates are required or you are submitting further changes they
should be sent as incremental updates against current git, existing
patches will not be replaced.

Please add any relevant lists and maintainers to the CCs when replying
to this mail.

Thanks,
Mark