kernel/drivers/regulator, branch linux-6.8.y

regulator: vqmmc-ipq4019: fix module autoloading

2024-05-30T07:48:51Z

[ Upstream commit 68adb581a39ae63a0ed082c47f01fbbe515efa0e ] Add MODULE_DEVICE_TABLE(), so the module could be properly autoloaded based on the alias from of_device_id table. Signed-off-by: Krzysztof Kozlowski Reviewed-by: Konrad Dybcio Link: https://msgid.link/r/20240410172615.255424-2-krzk@kernel.org Signed-off-by: Mark Brown Signed-off-by: Sasha Levin

regulator: qcom-refgen: fix module autoloading

2024-05-30T07:48:50Z

[ Upstream commit ddd3f34c10002e41ed3cd89c9bd8f1d05a22506a ] Add MODULE_DEVICE_TABLE(), so the module could be properly autoloaded based on the alias from of_device_id table. Signed-off-by: Krzysztof Kozlowski Reviewed-by: Konrad Dybcio Link: https://msgid.link/r/20240410172615.255424-1-krzk@kernel.org Signed-off-by: Mark Brown Signed-off-by: Sasha Levin

regulator: irq_helpers: duplicate IRQ name

2024-05-30T07:48:49Z

[ Upstream commit 7ab681ddedd4b6dd2b047c74af95221c5f827e1d ] The regulator IRQ helper requires caller to provide pointer to IRQ name which is kept in memory by caller. All other data passed to the helper in the regulator_irq_desc structure is copied. This can cause some confusion and unnecessary complexity. Make the regulator_irq_helper() to copy also the provided IRQ name information so caller can discard the name after the call to regulator_irq_helper() completes. Signed-off-by: Matti Vaittinen Link: https://msgid.link/r/ZhJMuUYwaZbBXFGP@drtxq0yyyyyyyyyyyyydy-3.rev.dnainternet.fi Signed-off-by: Mark Brown Signed-off-by: Sasha Levin

regulator: core: fix debugfs creation regression

2024-05-17T10:15:09Z

commit 2a4b49bb58123bad6ec0e07b02845f74c23d5e04 upstream. regulator_get() may sometimes be called more than once for the same consumer device, something which before commit dbe954d8f163 ("regulator: core: Avoid debugfs: Directory ... already present! error") resulted in errors being logged. A couple of recent commits broke the handling of such cases so that attributes are now erroneously created in the debugfs root directory the second time a regulator is requested and the log is filled with errors like: debugfs: File 'uA_load' in directory '/' already present! debugfs: File 'min_uV' in directory '/' already present! debugfs: File 'max_uV' in directory '/' already present! debugfs: File 'constraint_flags' in directory '/' already present! on any further calls. Fixes: 2715bb11cfff ("regulator: core: Fix more error checking for debugfs_create_dir()") Fixes: 08880713ceec ("regulator: core: Streamline debugfs operations") Cc: stable@vger.kernel.org Cc: Geert Uytterhoeven Signed-off-by: Johan Hovold Link: https://lore.kernel.org/r/20240509133304.8883-1-johan+linaro@kernel.org Signed-off-by: Mark Brown Signed-off-by: Greg Kroah-Hartman

regulator: tps65132: Add of_match table

2024-05-17T10:14:40Z

[ Upstream commit a469158eaf8f4b10263b417856d923dfa38ae96d ] Add of_match table for "ti,tps65132" compatible string. This fixes automatic driver loading when using device-tree, and if built as a module like major linux distributions do. Signed-off-by: André Apitzsch Link: https://msgid.link/r/20240325-of_tps65132-v1-1-86a5f7ef4ede@apitzsch.eu Signed-off-by: Mark Brown Signed-off-by: Sasha Levin

regulator: mt6360: De-capitalize devicetree regulator subnodes

2024-05-17T10:14:25Z

[ Upstream commit d3cf8a17498dd9104c04ad28eeac3ef3339f9f9f ] The MT6360 regulator binding, the example in the MT6360 mfd binding, and the devicetree users of those bindings are rightfully declaring MT6360 regulator subnodes with non-capital names, and luckily without using the deprecated regulator-compatible property. With this driver declaring capitalized BUCKx/LDOx as of_match string for the node names, obviously no regulator gets probed: fix that by changing the MT6360_REGULATOR_DESC macro to add a "match" parameter which gets assigned to the of_match. Fixes: d321571d5e4c ("regulator: mt6360: Add support for MT6360 regulator") Signed-off-by: AngeloGioacchino Del Regno Link: https://msgid.link/r/20240409144438.410060-1-angelogioacchino.delregno@collabora.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin

regulator: userspace-consumer: add module device table

2024-03-26T22:16:50Z

[ Upstream commit 531a0c0cdbff9cecf41073220a826f8b1132f9ab ] The userspace consumer can be built as a module but it cannot be automatically probed as there is no device table to match it up with device tree nodes. Add the missing macro so that the module can load automatically. Fixes: 5c51d4afcf3fd ("regulator: userspace-consumer: Handle regulator-output DT nodes") Signed-off-by: John Keeping Link: https://msgid.link/r/20240226160554.1453283-1-jkeeping@inmusicbrands.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin

regulator: rk808: fix LDO range on RK806

2024-03-04T14:54:32Z

The linear ranges aren't really matching what they should be. Indeed, the range is inclusive of the min value, so it makes sense the previous range does NOT include the max step value representing the min value of the range in question. Since 3.4V is represented by the decimal value 232, the previous range max step value should be 231 and not 232. No expected change in behavior since 3.4V was mapped with step 232 from the first range but is now mapped with step 232 from the second range. While at it, remove the incorrect comment from the second range. Fixes: f991a220a447 ("regulator: rk808: add rk806 support") Cc: Quentin Schulz Signed-off-by: Quentin Schulz Link: https://msgid.link/r/20240223-rk806-regulator-ranges-v1-2-3904ab70d250@theobroma-systems.com Signed-off-by: Mark Brown

regulator: rk808: fix buck range on RK806

2024-03-04T14:54:31Z

The linear ranges aren't really matching what they should be. Indeed, the range is inclusive of the min value, so it makes sense the previous range does NOT include the max step value representing the min value of the range in question. Since 1.5V is represented by the decimal value 160, the previous range max step value should be 159 and not 160. Similarly, 3.4V is represented by the decimal value 236, so the previous range max value should be 235 and not 237. The only change in behavior this makes is that this actually modeled the ranges to map step with decimal value 237 with 3.65V instead of 3.4V (the max supported by the HW). Fixes: f991a220a447 ("regulator: rk808: add rk806 support") Cc: Quentin Schulz Signed-off-by: Quentin Schulz Link: https://msgid.link/r/20240223-rk806-regulator-ranges-v1-1-3904ab70d250@theobroma-systems.com Signed-off-by: Mark Brown

regulator: max5970: Fix regulator child node name

2024-02-13T15:38:23Z

Update regulator child node name to lower case i.e., sw0 & sw1 as descibed in max5970 dt binding. Signed-off-by: Naresh Solanki Link: https://msgid.link/r/20240213145801.2564518-1-naresh.solanki@9elements.com Signed-off-by: Mark Brown