Re: [PATCH v3 3/3] arm64: dts: qcom: sm8750-lenovo-elden: describe the WL2868C regulators

[Qianhui Xu]

One note on how this mail was written, since it matters for how you read
it: I work on this board alone and my English is not good enough to
write upstream mail unaided, so I draft with an AI assistant and edit it
myself. The content, the measurements and every decision in it are mine.

Four findings, and three of them are real. Taking them in your order.

[High] i2c10 enabled while qupv3_2 and gpi_dma2 are still disabled.

Confirmed, and it is the worst of the four: nothing in the patch enables the
parent, so geni_se_probe() never runs on qupv3_2, i2c10 is never populated,
wl2868c_probe() never runs, and none of camera_ldo1..camera_ldo7 exists at
runtime. That also means the twelve "*-supply = <&camera_ldoN>" references in
this same patch point at regulators that cannot be registered. v4 enables
both parents in the board DTS:

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

I have not measured this on the board yet - it is a DTS-only change and I
will not claim it works until I have booted it and seen wl2868c probe.

[Medium] undocumented sensor/lens compatibles, missing CSI endpoints, and
power-domains on external sensors.

Partly accepted, and the parts that are not accepted need a different answer
than "fix it here":

 - "giantec,gt9764" and "samsung,s5kjns" are documented, just not in this
   series: the bindings were posted separately on 2026-10-27
   (<20261027051048.213177-1-xiaqinghuan@xxxxxxxxxxxxxxxx>) and are still in
   review. "galaxycore,gc08a8" has no binding posted at all. So the nodes
   here reference one reviewed-pending and one non-existent binding, and
   dtbs_check cannot pass for either in this series.
 - the missing port/endpoint nodes are a real omission. Sensors without a
   CSI endpoint cannot be connected to the CSID, which makes them decorative
   in the current form.
 - power-domains = <&camcc CAM_CC_TITAN_TOP_GDSC> on an I2C sensor is wrong:
   the GDSC belongs to the camera controller that owns the CCI bus, not to
   the sensor, which is powered through its supplies and its reset GPIO.

Where I disagree is only about sequencing, not about the facts: the reason the
sensor and lens nodes are in this patch is that they are the consumers of the
regulators, and the binding reviewer asked for the users of the binding to be
shown. Dropping them makes the regulator series a binding with no consumer
again. So my plan for v4 is:

 - keep this patch to qcom.yaml + the WL2868C node on i2c10 + the regulator
   supplies that are genuinely wired on this board, and drop the sensor and
   lens nodes until their bindings are in;
 - carry the -supply wiring in the patch that adds each sensor, so every
   consumer arrives with its own binding and its own endpoints;
 - drop the sensor power-domains either way.

If you think that leaves the regulator series without a user, the honest
statement is that the user is the board DTS as a whole and it will land in
pieces; I would rather say that in the cover letter than ship nodes that
cannot bind.

[Low] cci0_i2c1 and cci1_i2c1 disabled while the bus0 siblings are enabled,
bus1 pinctrl omitted, node ordering, and "two CCI controllers" in the commit
message while the SoC has three.

Accepted on all four. v4 leaves both i2c-bus@0 and i2c-bus@1 available (as
sm8550.dtsi and sm8650.dtsi do), adds the cci0_1 / cci1_1 pinctrl states on
gpio115/116 and gpio119/120, moves the cci nodes to unit-address order after
videocc@aaf0000 with the pinctrl nodes alphabetical inside &tlmm, and the
commit message will say three controllers exist of which two are described.

[Low] binding schema, SoC dtsi and board DTS mixed in one patch.

Accepted, and checkpatch already told me the same thing in the same run (one
of the five warnings on 3/3 is "DT binding docs and includes should be a
separate patch"). v4 is qcom.yaml one patch, sm8750.dtsi one patch, board DTS
one patch.

Nothing above is measured except the DTS content itself; the probe of i2c10
and the runtime existence of the regulators are still unverified on hardware,
and I will report them as such in the v4 cover letter.

Thanks,
Qianhui Xu