kernel/git/next/linux-next.git/drivers/regulator, branch master

Merge branch 'for-mfd-next' of https://git.kernel.org/pub/scm/linux/kernel/git/lee/mfd.git

2026-08-20T12:40:44+00:00

Merge remote-tracking branch 'regulator/for-7.2' into regulator-linus

2026-08-18T11:32:05+00:00

regulator: tps65185: wait for the IC to wake before the first I2C access

2026-08-17T16:58:29+00:00

The probe drives WAKEUP high with GPIOD_OUT_HIGH, enables the input supply, and then issues a regmap_update_bits() on INT_EN2 with no wait anywhere in between. The TPS65185 data sheet (TI SLVSAQ8G, February 2011, revised September 2017), section 7.6 "Timing Requirements: Data Transmission", Figure 2 "Power-Up and Power-Down Timing Diagram", footnote 1, requires 1.8 ms minimum between the WAKEUP rising edge and the IC being ready to accept an I2C transaction. The driver calls no delay function anywhere, and nothing on that path is guaranteed to take that long. On an RK3026 board the first transfer was NAKed: tps65185 0-0068: error -ENXIO: failed to enable temp irq -ENXIO here is rk3x_i2c reporting REG_INT_NAKRCV. Probe failed, so vposneg never registered and its consumer deferred indefinitely. Wait after the supply rather than at the gpiod_get(). Figure 2 times that 1.8 ms from a WAKEUP edge with VIN already up, whereas this driver asserts WAKEUP before enabling vin-supply; the data sheet does not describe that order, so on a board whose vin-supply is a switched regulator that was off, a wait placed at the gpiod_get() could elapse before the part had power. Waiting from whichever of the two comes last satisfies the specified case and is the conservative choice in the other. It also goes above the interrupt request rather than immediately before the INT_EN2 write, because that write is not necessarily the first transfer: tps65185_irq_thread() reads INT1 and INT2, and it is requested with IRQF_TRIGGER_LOW, so it can run as soon as the handler is installed. Tested on an ONYX BOOX C67ML (RK3026): the chip now probes, all three regulators register and the EPD controller comes up. Fixes: b0fc1e770194 ("regulator: Add TPS65185 driver") Signed-off-by: Mario Rugiero Link: https://patch.msgid.link/20260815232229.68474-1-mrugiero@gmail.com Signed-off-by: Mark Brown

regulator: fan53555: Add support for FAN53555BUC23X type

2026-08-12T16:48:37+00:00

FAN53555BUC23X has the ID 0 and REV 0xc, starts at 600mV and increments in 12.5mV steps. Per the datasheet, the FAN53555BUC23X (23 option) is grouped with the 00 and 13 options for soft-start timing (t_SS = 300us typ.), so the existing enable_time = 400 is reused here as well. This variant is found on the ASUS Tinker Edge R (RK3399Pro) as the supply regulator for both vdd_gpu and vdd_cpu_b. Verified across the full GPU OPP table with the userspace devfreq governor. Signed-off-by: Arash Golgol Link: https://patch.msgid.link/20260812125054.19111-1-arash.golgol@gmail.com Signed-off-by: Mark Brown

regulator: qcom-rpmh: Support RPMH address reads and use it for rpmh-regulators

2026-08-07T14:19:44+00:00

Kamal Wadhwa says: This patch series adds a new `rpmh_read()` API to allow reading RPMH addresses. Using this API enhances the RPMH regulator driver by adding readback of the voltage/bypass/mode settings as they have been applied by APPS during the bootloader stage, so regulator framework can get them via `get_mode`, `get_bypass` & `get_voltage_selector` callbacks during regulator registration. This is needed because currently regulator framework does a unnecessary write with `min-microvolt` DT setting for all the RPMH regulators during regulator registration, because the first time after boot the value is seen as -ENOTRECOVERABLE, as there is no option to read these regulator settings. With this change this unnecessary write can be avoided and regulator framework gets a sense of the initial state set during the bootloader stage for all regulator settings. NOTE - During discussion on the v2 series - PATCH 3/4, reviewer had inquired about possible need for the use of the sync_state() to handle the "multiple" client case - for maintaining the regulator settings till all the clients are probed. This case was not covered in my previous series and had originally planned to do that series separately. But after the discussion decided to merge the 2 series as it seemed this would be a better approach. But after working on sync_state change. I realized a basic issue with using sync_state() for regulators - that its per-driver and not per-regulator resource. But we needed a sync_state callback for each regulator separately. I had been experimenting with few ideas but seems its going to need more time for me to close on the equivalent solution that has per-regulator sync_state or something to that effect. So I thought to close on this series and attend to that separately. Link: https://patch.msgid.link/20260801-b4-read-rpmh-v5-v6-0-9fcb54928523@oss.qualcomm.com

regulator: qcom-rpmh: Fix coding style issues

2026-08-07T14:19:42+00:00

Fix the code style/format issues reported by checkpatch.pl script. Reviewed-by: Dmitry Baryshkov Signed-off-by: Kamal Wadhwa Link: https://patch.msgid.link/20260801-b4-read-rpmh-v5-v6-4-9fcb54928523@oss.qualcomm.com Signed-off-by: Mark Brown

regulator: qcom-rpmh: readback voltage/bypass/mode set during bootup

2026-08-07T14:19:41+00:00

Currently, during regulator registration, regulator framework sends an unnecessary `min-microvolts` request for the rpmh-regulator device. This happens because in current design, we do not have a way to readback the voltage settings that was set during the bootloader stage. Fix this by using the rpmh_read() API to read the regulator voltage settings done during boot and make it available to regulator framework from the very first read after the bootup. Also use this API to read the mode/bypass settings as well. This will provide the regulator framework a sense of the initial settings done by bootloader and thus preventing any redundant writes for any setting post bootup incase the same setting was already applied during bootup. Signed-off-by: Kamal Wadhwa Link: https://patch.msgid.link/20260801-b4-read-rpmh-v5-v6-3-9fcb54928523@oss.qualcomm.com Signed-off-by: Mark Brown

regulator: qcom-rpmh: Fix PMIC5 BOB bypass mode handling

2026-08-07T14:19:40+00:00

Currently, when `rpmh_regulator_set_mode_bypass()` helper function is called to set bypass mode, it sends PMIC4's BOB bypass mode value for even if its a PMIC5 BOB. To fix this, introduce new hw_data parameter`pmic_bypass_mode` to store bypass mode value. Use it to send correct PMIC bypass mode value that corresponds to PMIC4/5 BOB regulators from the helper function. Fixes: 610f29e5cc0e8d58 ("regulator: qcom-rpmh: Update PMIC modes for PMIC5") Reviewed-by: Dmitry Baryshkov Reviewed-by: Konrad Dybcio Signed-off-by: Kamal Wadhwa Link: https://patch.msgid.link/20260801-b4-read-rpmh-v5-v6-2-9fcb54928523@oss.qualcomm.com Signed-off-by: Mark Brown

regulator: ab8500: Remove stale expand_register kernel-doc entry

2026-08-03T15:39:01+00:00

Commit aeee55b76bfd ("regulator: ab8500: Remove unused embedded struct expand_register") deleted the expand_register member from struct ab8500_regulator_info and, in the same hunk, added an empty "@expand_register:" line to the kernel-doc block. That traded one W=1 warning for another: drivers/regulator/ab8500.c:196 Excess struct member 'expand_register' description in 'ab8500_regulator_info' Drop the leftover line; the remaining @member entries all match the struct. No functional changes. Reported-by: kernel test robot Closes: https://lore.kernel.org/r/202605160857.ZIE3nO9J-lkp@intel.com/ Assisted-by: Claude:claude-opus-5 [kernel-doc] Signed-off-by: Babanpreet Singh Link: https://patch.msgid.link/20260802013304.7-1-bbnpreetsingh@gmail.com Signed-off-by: Mark Brown

regulator: fp9931: Fix VPOS/VNEG voltage selector table

2026-07-31T17:40:28+00:00

The VPOSNEG_table[] mapping does not match the FP9931 datasheet. The datasheet defines the VPOS/VNEG voltage mapping as: 00h-04h -> 7.04V (-7.04V) 05h -> 7.26V (-7.26V) 06h -> 7.49V (-7.49V) ... 28h-3Fh -> 15.06V (-15.06V) However, VPOSNEG_table[] has two issues: 1. Selector 0x00~0x04 should all map to 7.04V (5 entries), but the table has 6 entries of 7.04V, causing all subsequent entries to be shifted by one position. 2. Selectors 0x29~0x3F should all clamp to 15.06V (23 entries), but the table has only 41 entries. Any selector value above 0x28 would result in an out-of-bounds table access. Fix both issues by removing the duplicate 7.04V entry and appending the missing 23 clamped 15.06V entries, bringing the table to the correct size of 64 entries (0x00~0x3F). Fixes: 12d821bd13d4 ("regulator: Add FP9931/JD9930 driver") Signed-off-by: Robby Cai Link: https://patch.msgid.link/20260724103441.800522-2-robby.cai@oss.nxp.com Signed-off-by: Mark Brown