Re: [PATCH v2] regulator: dt-bindings: willsemi,wl2868c: add the WL2868C camera PMIC

[Qianhui Xu]

Hi Krzysztof,

two corrections to what I sent you this morning, both measured after v3
went out, plus one thing I got wrong in the first reply.

First, how this mail is written: I draft with an AI assistant and edit it
myself; the content, the measurements and the decisions are mine.  You
asked for that explicitly and it is a fair thing to ask.

1) v3 has a defect that makes the "users" argument weaker than I claimed.

sashiko's review of v3 3/3 is right: that patch enables i2c10 but never
enables its parents, so geni_se_probe() never runs on qupv3_2, i2c10 is
never populated, and the eight "*-supply = <&camera_ldoN>" phandles in the
same patch point at regulators that cannot register.  So in the upstream
board file as posted, the consumers exist on paper only.  v4 enables both
parents in the same patch:

	&qupv3_2 { status = "okay"; };
	&gpi_dma2 { status = "okay"; };

2) What I can show for the hardware today, stated precisely.

On our own downstream board DTS (a much larger file than the upstream
submission, which also enables the QUP) the driver does probe and the
regulators do appear, measured on the board running 7.3-rc7:

  geni_i2c 888000.i2c: Bus frequency not specified, default to 100kHz.
  [camera] loaded wl2868c-regulator
  /sys/kernel/debug/regulator/: camera_ldo1 camera_ldo2 camera_ldo3
                                 camera_ldo4 camera_ldo5 camera_ldo7

with camera_ldo1/2/3/4/5/7 at 1128/1288/2816/2824/2808/1800 mV (LDO6 has
no consumer on this board).  That is the same wiring the upstream file
describes, just carried in the vendor-shaped file.  It shows the chip
works and the supplies are real; it does not show that the two hundred
lines I am asking you to take bind, because they are not the same file.

3) On "I still see no users", the honest answer rather than the
   convenient one.

The users are the camera stack: s5kjns, gc08a8, gt9764 and the CSIPHY
rails, eight supplies in total.  Their bindings are not in this series -
the two sensor bindings were posted separately on 2026-10-27 and are still
in review, and gc08a8 has no binding posted at all.  So the board file
cannot be complete, and dtbs_check cannot pass on those nodes, until those
land.  My reading was that this is exactly why the regulator binding
should go in first, but I accept that from your side it reads as a binding
with no user, and I would rather say that plainly than keep shipping
sensor nodes that cannot bind.

What v4 will be, if you want to sanity check the shape before I post it:

 - 1/3: arm/qcom.yaml registration plus the binding, unchanged in
   behaviour from v3 apart from review comments.
 - 2/3: sm8750.dtsi, the three DTSs split out as you and checkpatch both
   asked (this one was mixed into the board patch in v3).
 - 3/3: board DTS with qupv3_2, gpi_dma2, i2c10 and the WL2868C node, and
   the eight supply references, but without the sensor and lens nodes.
 - the sensor and lens nodes move into the patches that add those bindings,
   each arriving with its own binding and its own CSI endpoints.

If you would rather not see the regulator series again until the sensor
bindings are in, say so and I will park it - that is a legitimate call and
I do not want to burn your review time on a series whose consumer side is
not ready.

Thanks,
Qianhui Xu