Re: [PATCH 1/3] dt-bindings: display: ti,tpd12s015: Convert to DT schema

[Rob Herring <robh@kernel.org>]

On Fri, Oct 09, 2026 at 04:42:01PM +0100, Conor Dooley wrote:
> On Fri, Oct 09, 2026 at 04:44:34PM +0200, Laurent Pinchart wrote:
> > On Fri, Oct 09, 2026 at 03:25:49PM +0100, Conor Dooley wrote:
> > > On Fri, Oct 09, 2026 at 06:55:59PM +0800, Quchaosheng wrote:
> > > > From: Chaosheng Qu <quchaosheng000406@163.com>
> > > > 
> > > > Convert the TPD12S015 HDMI level shifter binding to DT schema.
> > > > 
> > > > The TI TPD12S015 is an HDMI companion chip that combines a level shifter
> > > > and ESD protection circuitry. Document the two ports it exposes between
> > > > the HDMI transmitter and the connector.
> > > > 
> > > > The tpd12s016 is software compatible with the tpd12s015 and is listed as
> > > > a fallback compatible by am57xx-idk-common.dtsi, so accept it as a
> > > > fallback of "ti,tpd12s015". The driver matches on "ti,tpd12s015" only, so
> > > > a board using the tpd12s016 must list both compatibles.
> > > > 
> > > > Assisted-by: LLM
> > > > Signed-off-by: Chaosheng Qu <quchaosheng000406@163.com>
> > > 
> > > No idea if the sashiko reply is valid, because I have no clue if
> > > providing a subset of the gpios is functional. Really this should have
> > > multiple different gpios properties,

The minItems one is not valid. sashiko struggles on our quirks against 
normal json-schema. Generally, if either minItems or maxItems is not 
specified, we make them equal. I think I documented that, so we need to 
get sashiko to read it...

> > 
> > Definitely.
> > 
> > > but this binding is really old and
> > > not worth changing IMO.
> > > Acked-by: Conor Dooley <conor.dooley@microchip.com>
> > > pw-bot: not-applicable
> > 
> > I'm getting annoyed be the LLM-assisted individual conversions. Can we
> > start requiring people who convert text bindings to YAML to at least
> > handle whole groups in one go ? If they're going to do a bad job, I'd
> > rather have to review it once only.

I have a branch of ~600 questionable patches. :) It does make arm64 
warning free (and some of the warning fixes are valid).

What's left is really stuff that's old, not getting new platforms and no 
one cares about. I don't think we need perfection. We should probably 
just ignore sashiko.

> 
> Or do one, and take the learnings into all the remaining patches - but
> with LLM conversions I don't think there's really much learning going on
> at all.
> 
> I guess bunching them is fine, provided it is for one subsystem. I
> definitely don't want to see a set of 15 patches across 9 subsystems,
> at least with one subsystem it's likely to be the same common problems
> across the bunch.

I've tried expressing my preferences in priority, but it hasn't worked. 
It was mainly GSoC or other programs, but now it's?

My priority is:

- Fix arm64 warnings
- Fix arm warnings
- Convert subsystem bindings
- Fix other $arch warnings (no one cares AFAICT)

We're actually pretty close to arm64 being warning free. krzk's LPC 
slides inflate the numbers as N boards for a SoC give N copies of 
warnings. next is currently sitting at 218 warnings in my deduped count. 
About half of those are HiSilicon and Mediatek. The rest of the 
platforms (by subdir) are around ~20 or less.

arm32 is still a long way off. The recent platform removals should help 
though.

Rob