[PATCH v10 0/2] regulator: add the Will Semiconductor WL2868C camera PMIC

[Qianhui Xu]

*** AI-assistance disclosure ***
This cover letter and the two patches below were prepared with the help
of an LLM coding assistant.  The author reviewed every line, ran every
gate quoted in this letter himself, and takes full responsibility for
the content.

This is v10 of the WL2868C binding+driver series.  It supersedes v9
(<20261107015014.22374-1-xiaqinghuan@xxxxxxxxxxxxxxxx>).

What changed in v10
===================

v10 addresses the three Medium findings sashiko posted on v9 2/2
(<sashiko-outbox-205554@xxxxxxxxxx>, 2026-11-09) and the two Low binding
points from the v7 review (<sashiko-outbox-201357@xxxxxxxxxx>) that v9
did not carry forward.  Sorry for the round trip: v9 2/2 is
byte-identical to v8 and v8 2/2 to v7, so those reports predate v9, and
v9 only carried Rob's binding points.  v10 fixes all five.

2/2 regulator: willsemi,wl2868c: add the WL2868C camera PMIC driver

1) [Medium] "reset released before enabling vsys in wl2868c_probe()".
   Accepted; all three sub-points were real.  v9 got the GPIO, registered
   the reset action and waited 1 ms before enabling the control supply,
   so the deassertion and the delay ran while the chip could be
   unpowered, the device ID read followed the supply turn-on with no
   startup delay, and the reverse-order devres teardown disabled the
   supply before asserting reset.  In v10 (drivers/regulator/
   wl2868c-regulator.c, wl2868c_probe()) the reset GPIO is taken with
   GPIOD_OUT_HIGH (RST_N asserted), the control supply is enabled first
   (wl2868c_enable_control_supply(), new), and only then is RST_N
   explicitly released with gpiod_set_value_cansleep(reset, 0) followed
   by a startup delay before the device ID is read.  The reset action
   (wl2868c_reset_assert(), renamed from wl2868c_reset()) is registered
   after the supply action on purpose: devres unwinds in reverse order,
   so on unbind RST_N is asserted again before the supply is disabled,
   not after.  The 1 ms values are now WL2868C_RESET_RELEASE_US /
   WL2868C_STARTUP_US; I could not quote a datasheet page (see the note
   at the end), so the letter keeps the same conservative 1 ms as v9.

2) [Medium] "vin7-supply not enabled for I2C in wl2868c_probe()".
   Accepted.  The binding allows either supply, but v9 only asked for
   "vsys" with devm_regulator_get_enable(), so a vin7-only board got a
   dummy regulator and the control logic never came up.  v10 adds
   wl2868c_enable_control_supply() (drivers/regulator/
   wl2868c-regulator.c): it uses devm_regulator_get_enable_optional()
   for "vsys" first and falls back to "vin7" only on -ENODEV, keeping
   whichever is present enabled for as long as the driver is bound.
   The -ENODEV check (not IS_ERR) matters: -EPROBE_DEFER for a vsys
   provider that has not probed yet is returned as-is instead of being
   misread as "no vsys described".  On boards that describe both, only
   VSYS is enabled as the control supply and VIN7 stays available to
   the regulator core as LDO7's input, unchanged from v9 behaviour.

3) [Medium] "preset LDOs enabled by wl2868c_probe() when SYS_EN is 0".
   Accepted; this is a real bug on a board whose firmware presets LDO
   bits with SYS_EN clear.  v9 seeded chip->enabled from the whole
   LDO_ENABLE byte, so the first enable() of any single output wrote
   SYS_EN | (preset bits | own bit) and switched on outputs no consumer
   asked for.  v10 seeds the tracked set only when the register already
   has SYS_EN set (wl2868c_probe(), right after reading
   WL2868C_LDO_ENABLE); with SYS_EN clear chip->enabled stays 0, which
   matches what is_enabled() reports, and the first enable() writes
   SYS_EN | <that one output>.  The comment in wl2868c_enable() was
   updated accordingly.

1/2 regulator: dt-bindings: willsemi,wl2868c: add the WL2868C camera PMIC

4) [Low] example enables ldo1 without describing its input.
   The provider node is already gone since v9 (Rob's point); the
   remaining half is fixed here: the example now also describes
   vin12-supply = <&vreg_vin12> next to vsys-supply, since the binding
   says an input may only be left out when the outputs it feeds are
   unused on a given board (willsemi,wl2868c.yaml, examples).

5) [Low] MAINTAINERS driver pattern dangling in the dt-bindings patch.
   The "F: drivers/regulator/wl2868c-regulator.c" line moved from 1/2
   into 2/2, where the file is actually created, so
   scripts/get_maintainer.pl --self-test=patterns has no dangling
   pattern at any commit of the series.

Gates run on v10 (on the 7.2 pristine base, commit 25f7927e6ccb)
===============================================================

  git am of 1/2 + 2/2 on a pristine checkout: clean, git status clean
  scripts/checkpatch.pl --strict --no-tree v10-0001 -> 0 errors, 0 warnings, 0 checks
  scripts/checkpatch.pl --strict --no-tree v10-0002 -> 0 errors, 0 warnings, 0 checks
  make ARCH=arm64 W=1 drivers/regulator/wl2868c-regulator.o
    -> rc=0, no warning
  make ARCH=arm64 DT_SCHEMA_FILES=.../willsemi,wl2868c.yaml dt_binding_check
    -> rc=0 (CHKDT/LINT/STYLE/DTEX/DTC all pass)
  scripts/get_maintainer.pl --self-test=patterns at both commits
    -> no new warnings (pre-existing unrelated upstream warnings only)

The 1 ms reset/startup delays and the 150 us enable_time come from the
WL2868C datasheet; I do not have a citable document revision to link,
so I kept the same conservative values v9 already used.

Qianhui Xu (2):
  regulator: dt-bindings: willsemi,wl2868c: add the WL2868C camera PMIC
  regulator: willsemi,wl2868c: add the WL2868C camera PMIC driver

 .../bindings/regulator/willsemi,wl2868c.yaml  |  99 +++++++
 MAINTAINERS                                   |   7 +
 drivers/regulator/Kconfig                     |  11 +
 drivers/regulator/Makefile                    |   1 +
 drivers/regulator/wl2868c-regulator.c         | 280 ++++++++++++++++++
 5 files changed, 398 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/regulator/willsemi,wl2868c.yaml
 create mode 100644 drivers/regulator/wl2868c-regulator.c

base-commit: 25f7927e6ccb6f4d8652b2b474d4c935faf580f6
--
2.53.0