kernel/linux.git/drivers/regulator/core.c, branch linux-5.11.y

regulator: core: Avoid debugfs: Directory ... already present! error

2021-03-04T11:14:44+00:00

[ Upstream commit dbe954d8f1635f949a1d9a5d6e6fb749ae022b47 ] Sometimes regulator_get() gets called twice for the same supply on the same device. This may happen e.g. when a framework / library is used which uses the regulator; and the driver itself also needs to enable the regulator in some cases where the framework will not enable it. Commit ff268b56ce8c ("regulator: core: Don't spew backtraces on duplicate sysfs") already takes care of the backtrace which would trigger when creating a duplicate consumer symlink under /sys/class/regulator/regulator.%d in this scenario. Commit c33d442328f5 ("debugfs: make error message a bit more verbose") causes a new error to get logged in this scenario: [ 26.938425] debugfs: Directory 'wm5102-codec-MICVDD' with parent 'spi-WM510204:00-MICVDD' already present! There is no _nowarn variant of debugfs_create_dir(), but we can detect and avoid this problem by checking the return value of the earlier sysfs_create_link_nowarn() call. Add a check for the earlier sysfs_create_link_nowarn() failing with -EEXIST and skip the debugfs_create_dir() call in that case, avoiding this error getting logged. Fixes: c33d442328f5 ("debugfs: make error message a bit more verbose") Cc: Charles Keepax Signed-off-by: Hans de Goede Reviewed-by: Charles Keepax Link: https://lore.kernel.org/r/20210122183250.370571-1-hdegoede@redhat.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin

regulator: Fix lockdep warning resolving supplies

2021-01-22T14:03:07+00:00

With commit eaa7995c529b54 (regulator: core: avoid regulator_resolve_supply() race condition) we started holding the rdev lock while resolving supplies, an operation that requires holding the regulator_list_mutex. This results in lockdep warnings since in other places we take the list mutex then the mutex on an individual rdev. Since the goal is to make sure that we don't call set_supply() twice rather than a concern about the cost of resolution pull the rdev lock and check for duplicate resolution down to immediately before we do the set_supply() and drop it again once the allocation is done. Fixes: eaa7995c529b54 (regulator: core: avoid regulator_resolve_supply() race condition) Reported-by: Marek Szyprowski Tested-by: Marek Szyprowski Signed-off-by: Mark Brown Link: https://lore.kernel.org/r/20210122132042.10306-1-broonie@kernel.org Signed-off-by: Mark Brown

regulator: core: avoid regulator_resolve_supply() race condition

2021-01-08T18:22:59+00:00

The final step in regulator_register() is to call regulator_resolve_supply() for each registered regulator (including the one in the process of being registered). The regulator_resolve_supply() function first checks if rdev->supply is NULL, then it performs various steps to try to find the supply. If successful, rdev->supply is set inside of set_supply(). This procedure can encounter a race condition if two concurrent tasks call regulator_register() near to each other on separate CPUs and one of the regulators has rdev->supply_name specified. There is currently nothing guaranteeing atomicity between the rdev->supply check and set steps. Thus, both tasks can observe rdev->supply==NULL in their regulator_resolve_supply() calls. This then results in both creating a struct regulator for the supply. One ends up actually stored in rdev->supply and the other is lost (though still present in the supply's consumer_list). Here is a kernel log snippet showing the issue: [ 12.421768] gpu_cc_gx_gdsc: supplied by pm8350_s5_level [ 12.425854] gpu_cc_gx_gdsc: supplied by pm8350_s5_level [ 12.429064] debugfs: Directory 'regulator.4-SUPPLY' with parent '17a00000.rsc:rpmh-regulator-gfxlvl-pm8350_s5_level' already present! Avoid this race condition by holding the rdev->mutex lock inside of regulator_resolve_supply() while checking and setting rdev->supply. Signed-off-by: David Collins Link: https://lore.kernel.org/r/1610068562-4410-1-git-send-email-collinsd@codeaurora.org Signed-off-by: Mark Brown

Merge remote-tracking branch 'regulator/for-5.11' into regulator-next

2020-12-11T17:48:32+00:00

regulator: core: return zero for selectors lower than linear_min_sel

2020-11-26T13:08:15+00:00

Selectors lower than linear_min_sel should not be considered invalid. Thus return zero in case _regulator_list_voltage(), regulator_list_hardware_vsel() or regulator_list_voltage_table() receives such selectors as argument. Fixes: bdcd1177578c ("regulator: core: validate selector against linear_min_sel") Reported-by: Jon Hunter Signed-off-by: Claudiu Beznea Link: https://lore.kernel.org/r/1606325147-606-1-git-send-email-claudiu.beznea@microchip.com Signed-off-by: Mark Brown

regulator: core: do not continue if selector match

2020-11-13T18:02:07+00:00

Do not continue if selector has already been located. Signed-off-by: Claudiu Beznea Link: https://lore.kernel.org/r/1605290164-11556-1-git-send-email-claudiu.beznea@microchip.com Signed-off-by: Mark Brown

Merge series "regulator: mcp16502: add support for ramp delay" from Claudiu Beznea :

2020-11-13T17:09:18+00:00

Hi, This series adds support for ramp delay on mcp16502. It also adds some cleanup on mcp16502. Apart from that patches 1/6 fixes the selector validation in case the regulator::desc::linear_min_sel is not zero. Thank you, Claudiu Beznea Changes in v3: - fix compilation error in patch 5/6 Reported-by: kernel test robot Changes in v2: - rebase on top of regulator/for-next - checked 1/6 and 3/6 applies on top of regulator/for-5.10 Claudiu Beznea (6): regulator: core: validate selector against linear_min_sel regulator: core: do not continue if selector match regulator: mcp16502: add linear_min_sel regulator: mcp16502: adapt for get/set on other registers regulator: mcp16502: add support for ramp delay regulator: mcp16502: remove void documentation of struct mcp16502 drivers/regulator/core.c | 12 +++- drivers/regulator/helpers.c | 3 +- drivers/regulator/mcp16502.c | 135 ++++++++++++++++++++++++++++++++++++------- 3 files changed, 127 insertions(+), 23 deletions(-) -- 2.7.4 _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

regulator: core: validate selector against linear_min_sel

2020-11-13T16:13:11+00:00

There are regulators who's min selector is not zero. Selectors loops (looping b/w zero and regulator::desc::n_voltages) might throw errors because invalid selectors are used (lower than regulator::desc::linear_min_sel). For this situations validate selectors against regulator::desc::linear_min_sel. Signed-off-by: Claudiu Beznea Link: https://lore.kernel.org/r/1605280870-32432-2-git-send-email-claudiu.beznea@microchip.com Signed-off-by: Mark Brown

regulator: debug early supply resolving

2020-11-13T16:10:05+00:00

Help debugging the case when set_machine_constraints() needs to be repeated. Signed-off-by: Michał Mirosław Tested-by: Ahmad Fatoum # stpmic1 Link: https://lore.kernel.org/r/f9cba575580369e46661a9278ee6c6a8d8564c2a.1605226675.git.mirq-linux@rere.qmqm.pl Signed-off-by: Mark Brown

regulator: workaround self-referent regulators

2020-11-13T14:21:26+00:00

Workaround regulators whose supply name happens to be the same as its own name. This fixes boards that used to work before the early supply resolving was removed. The error message is left in place so that offending drivers can be detected. Fixes: aea6cb99703e ("regulator: resolve supply after creating regulator") Cc: stable@vger.kernel.org Reported-by: Ahmad Fatoum Signed-off-by: Michał Mirosław Tested-by: Ahmad Fatoum # stpmic1 Link: https://lore.kernel.org/r/d703acde2a93100c3c7a81059d716c50ad1b1f52.1605226675.git.mirq-linux@rere.qmqm.pl Signed-off-by: Mark Brown