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

[Dmitry Torokhov <dmitry.torokhov@gmail.com>]

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.

-- 
Dmitry