[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20251230104909.3236ce13@kemnade.info>
Date: Tue, 30 Dec 2025 10:49:09 +0100
From: Andreas Kemnade <andreas@...nade.info>
To: Krzysztof Kozlowski <krzk@...nel.org>
Cc: Liam Girdwood <lgirdwood@...il.com>, Mark Brown <broonie@...nel.org>,
Rob Herring <robh@...nel.org>, Krzysztof Kozlowski <krzk+dt@...nel.org>,
Conor Dooley <conor+dt@...nel.org>, Guenter Roeck <linux@...ck-us.net>,
linux-kernel@...r.kernel.org, devicetree@...r.kernel.org,
linux-hwmon@...r.kernel.org
Subject: Re: [PATCH v2 1/2] dt-bindings: regulator: Document TI TPS65185
On Tue, 30 Dec 2025 10:08:57 +0100
Krzysztof Kozlowski <krzk@...nel.org> wrote:
> On Sat, Dec 27, 2025 at 11:20:36AM +0100, Andreas Kemnade wrote:
> > Document the TPS65185. GPIO names are same as in the datasheet except for
> > the PWRUP pad which is described as "enable". That pin is optional because
> > the rising edge corresponds to setting one register bit and falling edge
> > to another register bit.
>
> Nothing improved in the subject. Mark asked for proper prefix and you
> used exactly the same prefix, so the same problem stays.
>
Quoting:
The Documentation/ and include/dt-bindings/ portion of the patch should be a separate patch. The preferred subject prefix for binding patches is:
"dt-bindings: <binding dir>: ..."
That looks like what I am using.
> Please use subject prefixes matching the subsystem. You can get them for
> example with 'git log --oneline -- DIRECTORY_OR_FILE' on the directory
> your patch is touching. For bindings, the preferred subjects are
> explained here:
> https://www.kernel.org/doc/html/latest/devicetree/bindings/submitting-patches.html#i-for-patch-submitters
besides merge commits, patches with subjects doing the same seems to be:
d0f9f5b7a335 dt-bindings: regulator: Document MediaTek MT6363 PMIC Regulators
0f1010284076 dt-bindings: regulator: document max77838 pmic
That looks like mine. So no idea what to improve...
[...]
> > + vin-supply:
> > + description:
> > + Supply for the whole chip. Some vendor kernels and devicetrees
> > + declare this as a non-existing GPIO named "pwrall".
>
> GPIO cannot be non-existing. Anyway, use name matching the datasheet.
>
That is correct, GPIO cannot be non-existing. That comment was just
meant as a help for people trying to convert the dirty devicetree mess
out there into proper, submittable material. But I will remove that help
as you request.
Regards,
Andreas
Powered by blists - more mailing lists