Re: [PATCH v5] arm64: dts: qcom: glymur-crd: Enable keyboard, trackpad and touchscreen

[Abel Vesa]

On 26-03-20 01:52:06, Dmitry Baryshkov wrote:
> On Thu, Mar 19, 2026 at 11:11:18PM +0200, Abel Vesa wrote:
> > On 26-03-19 21:49:07, Dmitry Baryshkov wrote:
> > > On Thu, Mar 19, 2026 at 05:30:48PM +0200, Abel Vesa wrote:
> > > > On CRD, the keyboard, trackpad and touchscreen are connected over I2C
> > > > and all share a 3.3V regulator.
> > > > 
> > > > So describe the regulator and each input device along with their
> > > > pinctrl states.
> > > > 
> > > > Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@xxxxxxxxxxxxxxxx>
> > > > Reviewed-by: Konrad Dybcio <konrad.dybcio@xxxxxxxxxxxxxxxx>
> > > > Signed-off-by: Abel Vesa <abel.vesa@xxxxxxxxxxxxxxxx>
> > > > ---
> > > > Changes in v5:
> > > > - Since this depends on Displat DT patchset and since that one
> > > >   had to be respun in order to drop the non-merging phy patch
> > > >   dependency, this one had to be respun as well so that the dependency
> > > >   tree is correct.
> > > 
> > > Where do the dependencies come from? Would it be easier to merge this
> > > one first? Or are there overlapping supplies?
> > 
> > The USB and DT patchsets were on the list first, so it makes sense to be
> > merged first. If this one was to be merged first, the other two would
> > have to be reworked due to conflicts. Also this is the order in which the
> > support was brought up. Also, keyboard, trackpad and touchscreen don't
> > really make sense without display.
> 
> Well, up to you. Let's hope that there are no additional delays with USB
> and display

The latest version of those two patchsets are ready to be merged and
have no other dependency (anymore) than between them, that is Display
depends on USB.

> 
> > 
> > > > +
> > > > +	ts0_default: ts0-default-state {
> > > > +		int-n-pins {
> > > > +			pins = "gpio51";
> > > 
> > > What was the sorting order here? I assume you had one.
> > 
> > The way I see it, it should be based on state subnode name.
> > Which currently it is.
> > 
> > Do you suggest some other sorting order though ?
> > 
> > Thanks for reviewing!
> 
> Then ts0-default-state > pcie0

Oh, right. Will fix that.

> 
> I think the recent recommendation was to sort on the pin number, but I
> didn't switch myself to it too.

Doing that looks odd to me. When you review DT, it seems more logical
that sorting by node name should take precedence over the node properties 
or even worse, their values. Not to mention that that would become just
another weird exception.

But maybe it's just my OCD that is unwilling to accept such an exception...

So unless someone NACKs it, I intend to respin with the sorting done by
the node/subnode name.