[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <38c8d070-5328-4a61-bca4-5b80e5a3abbe@kernel.org>
Date: Thu, 5 Feb 2026 20:25:47 +0100
From: Krzysztof Kozlowski <krzk@...nel.org>
To: Conor Dooley <conor@...nel.org>, Guodong Xu <guodong@...cstar.com>
Cc: Rob Herring <robh@...nel.org>, Liam Girdwood <lgirdwood@...il.com>,
Mark Brown <broonie@...nel.org>, Yixun Lan <dlan@...too.org>,
Alex Elder <elder@...cstar.com>, Lee Jones <lee@...nel.org>,
Krzysztof Kozlowski <krzk+dt@...nel.org>, Conor Dooley
<conor+dt@...nel.org>, Troy Mitchell <troy.mitchell@...ux.spacemit.com>,
Paul Walmsley <pjw@...nel.org>, Palmer Dabbelt <palmer@...belt.com>,
Albert Ou <aou@...s.berkeley.edu>, Alexandre Ghiti <alex@...ti.fr>,
linux-kernel@...r.kernel.org, linux-riscv@...ts.infradead.org,
spacemit@...ts.linux.dev, devicetree@...r.kernel.org
Subject: Re: [PATCH v3 1/3] dt-bindings: mfd: spacemit,p1: Add individual
regulator supply properties
On 05/02/2026 20:15, Conor Dooley wrote:
>>>>
>>>> vin-supply:
>>>> - description: Input supply phandle.
>>>> + deprecated: true
>>>> + description:
>>>> + Main power input (deprecated). Use individual vin1-6, aldoin,
>>>> + dldoin1, and dldoin2 supply properties instead.
>>>
>>> What's the point documenting the deprecated version if it doesn't work
>>> anymore?
>>
>> Keeping "vin-supply" in the binding with "deprecated: true" avoids a cross-tree
>> warning. Since dts and dt-bindings go via different trees, the new binding +
>> old dts triggers:
>>
>> pmic@41 (spacemit,p1): Unevaluated properties are not allowed
>> ('vin-supply' was unexpected)
>>
>> Rob flagged this in [1] as 'intermittent warnings'.
>>
>> I'm open to dropping the deprecated markup, maybe just accepting the
>> transient warning is fine?
>
> I'd rather have the warning in linux-next or for a short period of time
> in Linus' tree during the merge window, than have the binding document
> something that no longer works. To me, the deprecated tag in a binding
> means "this used to be how things were done, and still works, but we
> don't want you to use it because of xyz reason". Things that don't work
I agree, deprecated still should mean the interface is supported.
Otherwise, after applying the DTS patches, what is the point of keeping
such deprecated property? Very little benefits.
> should produce warnings to stop people using them. You provided a fairly
> good justification for breaking the ABI, just commit to that and remove
> the old/incorrect way of doing things.
>
Best regards,
Krzysztof
Powered by blists - more mailing lists