linux-toradex.git/drivers/regulator/max8907-regulator.c, branch v7.0-rc2 Linux kernel for Apalis and Colibri modules regulator: Set PROBE_PREFER_ASYNCHRONOUS for drivers that existed in 4.14 2023-03-20T13:11:25+00:00 Douglas Anderson dianders@chromium.org 2023-03-16T19:54:38+00:00 259b93b21a9ffe5117af4dfb5505437e463c6a5a Probing of regulators can be a slow operation and can contribute to slower boot times. This is especially true if a regulator is turned on at probe time (with regulator-boot-on or regulator-always-on) and the regulator requires delays (off-on-time, ramp time, etc). While the overall kernel is not ready to switch to async probe by default, as per the discussion on the mailing lists [1] it is believed that the regulator subsystem is in good shape and we can move regulator drivers over wholesale. There is no way to just magically opt in all regulators (regulators are just normal drivers like platform_driver), so we set PROBE_PREFER_ASYNCHRONOUS for all regulators found in 'drivers/regulator' individually. Given the number of drivers touched and the impossibility to test this ahead of time, it wouldn't be shocking at all if this caused a regression for someone. If there is a regression caused by this patch, it's likely to be one of the cases talked about in [1]. As a "quick fix", drivers involved in the regression could be fixed by changing them to PROBE_FORCE_SYNCHRONOUS. That being said, the correct fix would be to directly fix the problem that caused the issue with async probe. The approach here follows a similar approach that was used for the mmc subsystem several years ago [2]. In fact, I ran nearly the same python script to auto-generate the changes. The only thing I changed was to search for "i2c_driver", "spmi_driver", and "spi_driver" in addition to "platform_driver". [1] https://lore.kernel.org/r/06db017f-e985-4434-8d1d-02ca2100cca0@sirena.org.uk [2] https://lore.kernel.org/r/20200903232441.2694866-1-dianders@chromium.org/ Signed-off-by: Douglas Anderson <dianders@chromium.org> Link: https://lore.kernel.org/r/20230316125351.1.I2a4677392a38db5758dee0788b2cea5872562a82@changeid Signed-off-by: Mark Brown <broonie@kernel.org> 
Probing of regulators can be a slow operation and can contribute to
slower boot times. This is especially true if a regulator is turned on
at probe time (with regulator-boot-on or regulator-always-on) and the
regulator requires delays (off-on-time, ramp time, etc).

While the overall kernel is not ready to switch to async probe by
default, as per the discussion on the mailing lists [1] it is believed
that the regulator subsystem is in good shape and we can move
regulator drivers over wholesale. There is no way to just magically
opt in all regulators (regulators are just normal drivers like
platform_driver), so we set PROBE_PREFER_ASYNCHRONOUS for all
regulators found in 'drivers/regulator' individually.

Given the number of drivers touched and the impossibility to test this
ahead of time, it wouldn't be shocking at all if this caused a
regression for someone. If there is a regression caused by this patch,
it's likely to be one of the cases talked about in [1]. As a "quick
fix", drivers involved in the regression could be fixed by changing
them to PROBE_FORCE_SYNCHRONOUS. That being said, the correct fix
would be to directly fix the problem that caused the issue with async
probe.

The approach here follows a similar approach that was used for the mmc
subsystem several years ago [2]. In fact, I ran nearly the same python
script to auto-generate the changes. The only thing I changed was to
search for "i2c_driver", "spmi_driver", and "spi_driver" in addition
to "platform_driver".

[1] https://lore.kernel.org/r/06db017f-e985-4434-8d1d-02ca2100cca0@sirena.org.uk
[2] https://lore.kernel.org/r/20200903232441.2694866-1-dianders@chromium.org/

Signed-off-by: Douglas Anderson <dianders@chromium.org>
Link: https://lore.kernel.org/r/20230316125351.1.I2a4677392a38db5758dee0788b2cea5872562a82@changeid
Signed-off-by: Mark Brown <broonie@kernel.org>
regulator: max8907: Constify static structs 2020-06-18T12:47:34+00:00 Rikard Falkeborn rikard.falkeborn@gmail.com 2020-06-17T22:32:46+00:00 b08af72d6e5319e96527816c4b3b08d0b1a6f242 These are not modified so make them const to allow the compiler to put them in read-only memory. Before: text data bss dec hex filename 2753 7328 0 10081 2761 drivers/regulator/max8907-regulator.o After: text data bss dec hex filename 9405 684 0 10089 2769 drivers/regulator/max8907-regulator.o Signed-off-by: Rikard Falkeborn <rikard.falkeborn@gmail.com> Link: https://lore.kernel.org/r/20200617223247.25566-5-rikard.falkeborn@gmail.com Signed-off-by: Mark Brown <broonie@kernel.org> 
These are not modified so make them const to allow the compiler to put
them in read-only memory.

Before:
   text    data     bss     dec     hex filename
   2753    7328       0   10081    2761 drivers/regulator/max8907-regulator.o

After:
   text    data     bss     dec     hex filename
   9405     684       0   10089    2769 drivers/regulator/max8907-regulator.o

Signed-off-by: Rikard Falkeborn <rikard.falkeborn@gmail.com>
Link: https://lore.kernel.org/r/20200617223247.25566-5-rikard.falkeborn@gmail.com
Signed-off-by: Mark Brown <broonie@kernel.org>
regulator: max8907: Fix the usage of uninitialized variable in max8907_regulator_probe() 2019-10-04T17:45:43+00:00 Yizhuo yzhai003@ucr.edu 2019-10-03T17:58:13+00:00 472b39c3d1bba0616eb0e9a8fa3ad0f56927c7d7 Inside function max8907_regulator_probe(), variable val could be uninitialized if regmap_read() fails. However, val is used later in the if statement to decide the content written to "pmic", which is potentially unsafe. Signed-off-by: Yizhuo <yzhai003@ucr.edu> Link: https://lore.kernel.org/r/20191003175813.16415-1-yzhai003@ucr.edu Signed-off-by: Mark Brown <broonie@kernel.org> 
Inside function max8907_regulator_probe(), variable val could
be uninitialized if regmap_read() fails. However, val is used
later in the if statement to decide the content written to
"pmic", which is potentially unsafe.

Signed-off-by: Yizhuo <yzhai003@ucr.edu>
Link: https://lore.kernel.org/r/20191003175813.16415-1-yzhai003@ucr.edu
Signed-off-by: Mark Brown <broonie@kernel.org>
treewide: Replace GPLv2 boilerplate/reference with SPDX - rule 500 2019-06-19T15:09:55+00:00 Thomas Gleixner tglx@linutronix.de 2019-06-04T08:11:33+00:00 d2912cb15bdda8ba4a5dd73396ad62641af2f520 Based on 2 normalized pattern(s): this program is free software you can redistribute it and or modify it under the terms of the gnu general public license version 2 as published by the free software foundation this program is free software you can redistribute it and or modify it under the terms of the gnu general public license version 2 as published by the free software foundation # extracted by the scancode license scanner the SPDX license identifier GPL-2.0-only has been chosen to replace the boilerplate/reference in 4122 file(s). Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Reviewed-by: Enrico Weigelt <info@metux.net> Reviewed-by: Kate Stewart <kstewart@linuxfoundation.org> Reviewed-by: Allison Randal <allison@lohutok.net> Cc: linux-spdx@vger.kernel.org Link: https://lkml.kernel.org/r/20190604081206.933168790@linutronix.de Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> 
Based on 2 normalized pattern(s):

  this program is free software you can redistribute it and or modify
  it under the terms of the gnu general public license version 2 as
  published by the free software foundation

  this program is free software you can redistribute it and or modify
  it under the terms of the gnu general public license version 2 as
  published by the free software foundation #

extracted by the scancode license scanner the SPDX license identifier

  GPL-2.0-only

has been chosen to replace the boilerplate/reference in 4122 file(s).

Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Reviewed-by: Enrico Weigelt <info@metux.net>
Reviewed-by: Kate Stewart <kstewart@linuxfoundation.org>
Reviewed-by: Allison Randal <allison@lohutok.net>
Cc: linux-spdx@vger.kernel.org
Link: https://lkml.kernel.org/r/20190604081206.933168790@linutronix.de
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
regulator: max8907-regulator: constify regulator_ops structure 2017-01-31T20:54:26+00:00 Bhumika Goyal bhumirks@gmail.com 2017-01-28T14:32:32+00:00 88c9d47aa4f7ee9f086f6fcb7e7b6a59e3380462 Declare regulator_ops structure as const as it is only stored in the ops field of a regulator_desc structure. This field is of type const, so regulator_ops structures having this property can be made const too. File size before: drivers/regulator/max8907-regulator.o text data bss dec hex filename 1384 9424 256 11064 2b38 regulator/max8907-regulator.o File size after: drivers/regulator/max8907-regulator.o text data bss dec hex filename 2664 8400 0 11064 2b38 regulator/max8907-regulator.o Signed-off-by: Bhumika Goyal <bhumirks@gmail.com> Signed-off-by: Mark Brown <broonie@kernel.org> 
Declare regulator_ops structure as const as it is only stored in the ops
field of a regulator_desc structure. This field is of type const, so
regulator_ops structures having this property can be made const too.

File size before: drivers/regulator/max8907-regulator.o
   text	   data	    bss	    dec	    hex	filename
   1384	   9424	    256	  11064	   2b38 regulator/max8907-regulator.o

File size after: drivers/regulator/max8907-regulator.o
   text	   data	    bss	    dec	    hex	filename
   2664	   8400	      0	  11064	   2b38 regulator/max8907-regulator.o

Signed-off-by: Bhumika Goyal <bhumirks@gmail.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
regulator: drop owner assignment from platform_drivers 2014-10-20T14:21:29+00:00 Wolfram Sang wsa@the-dreams.de 2014-10-20T14:21:29+00:00 6c794b2654555d6af7572e3a8f13b2b39126df0c A platform_driver does not need to set an owner, it will be populated by the driver core. Signed-off-by: Wolfram Sang <wsa@the-dreams.de> 
A platform_driver does not need to set an owner, it will be populated by the
driver core.

Signed-off-by: Wolfram Sang <wsa@the-dreams.de>
regulator: remove unnecessary of_node_get() to parent 2014-09-10T10:35:02+00:00 Guodong Xu guodong.xu@linaro.org 2014-09-10T03:50:39+00:00 b8b27a44ddf1987e9bae84b99741b0a61192e017 These of_node_get() were added to balance refcount decrements inside of of_find_node_by_name(). See: commit c92f5dd2c42f ("regulator: Add missing of_node_put()") However of_find_node_by_name() was then replaced by of_get_child_by_name(), which doesn't call of_node_put() against its input parameter. So, need to remove these unnecessary of_node_get() calls. Signed-off-by: Guodong Xu <guodong.xu@linaro.org> Reviewed-by: Axel Lin <axel.lin@ingics.com> Signed-off-by: Mark Brown <broonie@kernel.org> 
These of_node_get() were added to balance refcount decrements inside of
of_find_node_by_name().
See: commit c92f5dd2c42f ("regulator: Add missing of_node_put()")

However of_find_node_by_name() was then replaced by of_get_child_by_name(),
which doesn't call of_node_put() against its input parameter.

So, need to remove these unnecessary of_node_get() calls.

Signed-off-by: Guodong Xu <guodong.xu@linaro.org>
Reviewed-by: Axel Lin <axel.lin@ingics.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
regulator: max8907: Remove regulator_dev array from state container 2014-03-10T09:34:59+00:00 Krzysztof Kozlowski k.kozlowski@samsung.com 2014-03-10T08:32:48+00:00 f991525a1acc641a21ece236649ceebfdf2c294d Don't store array of regulator_dev returned by devm_regulator_register() in state container. It isn't used anywhere outside of max8907_regulator_probe() function. Signed-off-by: Krzysztof Kozlowski <k.kozlowski@samsung.com> Signed-off-by: Mark Brown <broonie@linaro.org> 
Don't store array of regulator_dev returned by devm_regulator_register()
in state container. It isn't used anywhere outside of
max8907_regulator_probe() function.

Signed-off-by: Krzysztof Kozlowski <k.kozlowski@samsung.com>
Signed-off-by: Mark Brown <broonie@linaro.org>
regulator: max8907: Remove redundant error message 2014-02-20T11:23:18+00:00 Sachin Kamat sachin.kamat@linaro.org 2014-02-20T08:53:07+00:00 d016bdc7f4e8b2848d8992f99e226f03abe53716 kzalloc prints its own OOM message upon failure. Signed-off-by: Sachin Kamat <sachin.kamat@linaro.org> Signed-off-by: Mark Brown <broonie@linaro.org> 
kzalloc prints its own OOM message upon failure.

Signed-off-by: Sachin Kamat <sachin.kamat@linaro.org>
Signed-off-by: Mark Brown <broonie@linaro.org>
regulator: max8907: Use of_get_child_by_name 2014-02-14T21:10:05+00:00 Sachin Kamat sachin.kamat@linaro.org 2014-02-14T11:49:50+00:00 c61f1401391c4735490ebc04a07d1386787bbf49 of_find_node_by_name walks the allnodes list, and can thus walk outside of the parent node. Use of_get_child_by_name instead. Signed-off-by: Sachin Kamat <sachin.kamat@linaro.org> Signed-off-by: Mark Brown <broonie@linaro.org> 
of_find_node_by_name walks the allnodes list, and can thus walk
outside of the parent node. Use of_get_child_by_name instead.

Signed-off-by: Sachin Kamat <sachin.kamat@linaro.org>
Signed-off-by: Mark Brown <broonie@linaro.org>