Re: [PATCH] dt-bindings: regulator: add Will Semiconductor WL2868C PMIC

[Krzysztof Kozlowski <krzk@kernel.org>]

On 28/10/2026 13:04, Qianhui Xu wrote:
> On Tue, Oct 27, 2026 at 07:04:55PM +0100, Krzysztof Kozlowski wrote:
>> Looks like broken patch. Please use git or b4 to generate patches.
> 
> You are right, and I found what happened.  The patch was not produced by
> git format-patch on a commit: the diffstat was typed into the commit
> message body, so the mail carried two of them - one pasted directly under
> the Signed-off-by (no blank line), and one appended by format-patch.  I
> reproduced it locally by git am'ing the sent patch onto pristine 7.3-rc7
> and reading back the resulting commit message, which contains the pasted
> stat.
> 
> The v2 I am sending right after this mail is a real commit in a pristine
> 7.3-rc7 worktree exported with git format-patch, so the body has exactly
> one diffstat.  The diff itself was never the problem - git apply --check
> passed all along, which is why my local checkpatch run did not catch it.
> 
>> Anyway, where is any user of this? Why do we want this binding?
> 
> The user is the camera stack on the Lenovo Legion Tab (TB322FC), an SM8750
> tablet.  The WL2868C sits on i2c10 at 0x2f and feeds both camera sensors:
> 
>   - rear sensor:  dovdd <- ldo7, dvdd <- ldo1, avdd <- ldo4
>   - front sensor: dovdd <- ldo7, dvdd <- ldo2, avdd <- ldo3
> 
> and ldo5 supplies the VCM actuator.  These are the *-supply references
> in the board DTS; without a binding for the PMIC they dangle, so the
> camera nodes cannot be described at all.  The regulator driver itself is a
> separate patch I will send to the regulator list - I held it back so this
> binding could be reviewed on its own, but that left the binding looking
> like it had no consumer, which is a fair objection and I have now put the
> consumer information into the commit message.
> 


Reply looks like it was generated by a poor LLM or poorly managed one.

Such poor LLM produces text difficult to read and understand, very
unnatural for upstream kernel discussion. Discussing with such LLM is an
excessive use of maintainer's resources. It also brings doubts that
actual human is involved in discussion, which, if that is true, would be
a total waste of time.

Best regards,
Krzysztof