[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <6778765.lOV4Wx5bFT@workhorse>
Date: Wed, 17 Dec 2025 13:57:46 +0100
From: Nicolas Frattaroli <nicolas.frattaroli@...labora.com>
To: Krzysztof Kozlowski <krzk@...nel.org>
Cc: Dmitry Torokhov <dmitry.torokhov@...il.com>,
Rob Herring <robh@...nel.org>, Krzysztof Kozlowski <krzk+dt@...nel.org>,
Conor Dooley <conor+dt@...nel.org>,
Alexandre Belloni <alexandre.belloni@...tlin.com>,
Heiko Stuebner <heiko@...ech.de>, kernel@...labora.com,
linux-input@...r.kernel.org, devicetree@...r.kernel.org,
linux-kernel@...r.kernel.org, linux-arm-kernel@...ts.infradead.org,
linux-rockchip@...ts.infradead.org
Subject:
Re: [PATCH v2 1/4] dt-bindings: input: adc-keys: allow linux,input-type
property
On Wednesday, 17 December 2025 09:31:15 Central European Standard Time Krzysztof Kozlowski wrote:
> On Mon, Dec 15, 2025 at 01:29:29PM +0100, Nicolas Frattaroli wrote:
> > adc-keys, unlike gpio-keys, does not allow linux,input-type as a valid
> > property. This makes it impossible to model devices that have ADC inputs
> > that should generate switch events.
>
> The solution is to use unevaluatedProps instead, which also allows
> dropping other properties.
>
> Best regards,
> Krzysztof
>
>
Hi Krzysztof,
to understand the motivation behind this suggestion correctly:
are the "linux," vendor prefixed properties, especially with regards
to key codes, generally a bit of a thorn in the side of DT bindings
maintainers?
I'd imagine so since they technically tie the DT to a specific OS
kernel (though of course, others are free to translate those key
codes). And the whole idea of configuring which code is emitted
from something is basically abusing DT for configuring software
rather than describing hardware.
I'm mainly interested because this is a thought that has been in
the back of my mind for a while now, and I'm curious if the DT
binding maintainers happen to have arrived at the same impassé,
where linux,input-type et al abuse the DT model for something we
would tell any other vendor not to abuse it for, but no better
solution exists right now to achieve the same thing.
Kind regards,
Nicolas Frattaroli
Powered by blists - more mailing lists