Pull regulator updates from Mark Brown:
 "This is a relatively quiet release for the regulator API, we've had no
  major core work and not really that much driver work either. There's a
  bunch of activity, including several new devices, but nothing hugely
  remarkable here.

   - Reworking of the mode handling in the max14577 driver to fix issues
     with collisions with enables

   - Support for onsemi FAN53555BUC23X, Qualcomm IPQ9650, PM4125 VBUS
     and PM8150B and Unisoc SC2730"

* tag 'regulator-v7.3' of git://git.kernel.org/pub/scm/linux/kernel/git/broonie/regulator: (36 commits)
  regulator: fan53555: Add support for FAN53555BUC23X type
  regulator: qcom-rpmh: Fix coding style issues
  regulator: qcom-rpmh: readback voltage/bypass/mode set during bootup
  regulator: qcom-rpmh: Fix PMIC5 BOB bypass mode handling
  soc: qcom: rpmh: Add support to read back resource settings
  regulator: dt-bindings: ti,pbias-omap: Convert to DT schema
  regulator: ab8500: Remove stale expand_register kernel-doc entry
  regulator: dt-bindings: Correct white-space style
  regulator: pfuze100: add set_suspend_disable for LDO ops
  regulator: core: use system_freezable_wq for init complete work
  regulator: rt6245: Restore state on enable failure
  regulator: tps65185: handle gpiod_get_value_cansleep() error returns
  regulator: fan53555: Add support for mode operations on Silergy devices
  regulator: dt-bindings: Add fan53555 allowed modes
  regulator: wm831x-isink: remove conditional return with no effect
  regulator: dt-bindings: Convert ltc3589.txt to yaml format
  regulator: dt-bindings: tps51632: Convert to DT schema
  regulator: mcp16502: Convert to dev_err_probe() in mcp16502_probe()
  regulator: adp5055: Fix error code in adp5055_of_parse_cb()
  regulator: qcom_usb_vbus: add support for qcom,pm4125-vbus-reg
  ...

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 <arash.golgol@gmail.com>
Link: https://patch.msgid.link/20260812125054.19111-1-arash.golgol@gmail.com
Signed-off-by: Mark Brown <broonie@kernel.org>

Kamal Wadhwa <kamal.wadhwa@oss.qualcomm.com> 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

Fix the code style/format issues reported by checkpatch.pl
script.

Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
Signed-off-by: Kamal Wadhwa <kamal.wadhwa@oss.qualcomm.com>
Link: https://patch.msgid.link/20260801-b4-read-rpmh-v5-v6-4-9fcb54928523@oss.qualcomm.com
Signed-off-by: Mark Brown <broonie@kernel.org>

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 <kamal.wadhwa@oss.qualcomm.com>
Link: https://patch.msgid.link/20260801-b4-read-rpmh-v5-v6-3-9fcb54928523@oss.qualcomm.com
Signed-off-by: Mark Brown <broonie@kernel.org>

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 <dmitry.baryshkov@oss.qualcomm.com>
Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
Signed-off-by: Kamal Wadhwa <kamal.wadhwa@oss.qualcomm.com>
Link: https://patch.msgid.link/20260801-b4-read-rpmh-v5-v6-2-9fcb54928523@oss.qualcomm.com
Signed-off-by: Mark Brown <broonie@kernel.org>

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 <lkp@intel.com>
Closes: https://lore.kernel.org/r/202605160857.ZIE3nO9J-lkp@intel.com/
Assisted-by: Claude:claude-opus-5 [kernel-doc]
Signed-off-by: Babanpreet Singh <bbnpreetsingh@gmail.com>
Link: https://patch.msgid.link/20260802013304.7-1-bbnpreetsingh@gmail.com
Signed-off-by: Mark Brown <broonie@kernel.org>

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 <robby.cai@nxp.com>
Link: https://patch.msgid.link/20260724103441.800522-2-robby.cai@oss.nxp.com
Signed-off-by: Mark Brown <broonie@kernel.org>

Joy Zou <joy.zou@oss.nxp.com> says:

The regulator_init_complete_work fires ~30s after boot to disable
unused regulators via I2C. When this work races with PM suspend, the
I2C adapter may already be suspended, causing a -ESHUTDOWN warning
dump.

This series addresses the race and adds proper suspend power
management for unused LDO regulators.

Link: https://patch.msgid.link/20260731-b4-regulator-pf01-v2-0-a406c8737fdb@oss.nxp.com

Add a set_suspend_disable callback to pfuze100_ldo_regulator_ops to
support the regulator-off-in-suspend DTS property for the VGEN LDO
regulators. This allows unused LDO regulators to be properly disabled
during system suspend, reducing power consumption.

The callback is only used by the LDO ops, so name it accordingly:
pfuze100_ldo_set_suspend_disable. It uses the per-regulator
stby_reg/stby_mask that already describe the standby control for
each LDO, so it works for every LDO covered by these ops.

Signed-off-by: Joy Zou <joy.zou@oss.nxp.com>
Reviewed-by: Frank Li <Frank.Li@nxp.com>
Link: https://patch.msgid.link/20260731-b4-regulator-pf01-v2-2-a406c8737fdb@oss.nxp.com
Signed-off-by: Mark Brown <broonie@kernel.org>