Re: [PATCH v2 1/4] dt-bindings: input: adc-keys: allow linux,input-type property

[Nicolas Frattaroli]

On Wednesday, 8 April 2026 18:59:08 Central European Summer Time Dmitry Torokhov wrote:
> On Wed, Dec 17, 2025 at 07:34:40AM -0600, Rob Herring wrote:
> > On Wed, Dec 17, 2025 at 01:57:46PM +0100, Nicolas Frattaroli wrote:
> > > 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?
> > 
> > Not really. Most have existed for decades. New ones get extra scrutiny 
> > and often end up dropping the linux prefix.
> > 
> > > 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.
> > 
> > Not sure what the BSDs do here. It's never come up that I remember. Best 
> > I can tell is they just make it a userspace problem. So every possible 
> > keyboard needs a keymap file. Though I'm not sure how that would work 
> > with GPIO keys as you don't really have a scan code.
> 
> Is there an update for this binding or should I apply the current
> version? I am OK with the driver changes...
> 
> Thanks.
> 
> 

I will send a new version that doesn't add the property but allows
unevaluatedProps instead. Thanks for reminding me.

Kind regards,
Nicolas Frattaroli