linux-kernel - RE: input: Device Tree Properties for Captouch Button Device Registers

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <BL0PR07MB41150BF0740C6F7E63FF4E11ADE70@BL0PR07MB4115.namprd07.prod.outlook.com>
Date:   Fri, 21 Jun 2019 14:11:33 +0000
From:   Ken Sloat <KSloat@...pglobal.com>
To:     "dmitry.torokhov@...il.com" <dmitry.torokhov@...il.com>
CC:     Kasun Beddewela <KBeddewela@...pglobal.com>,
        "linux-input@...r.kernel.org" <linux-input@...r.kernel.org>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        Ken Sloat <KSloat@...pglobal.com>,
        "robh+dt@...nel.org" <robh+dt@...nel.org>,
        "mark.rutland@....com" <mark.rutland@....com>,
        "devicetree@...r.kernel.org" <devicetree@...r.kernel.org>
Subject: RE: input: Device Tree Properties for Captouch Button Device
 Registers

> -----Original Message-----
> From: Ken Sloat
> Sent: Wednesday, June 19, 2019 8:55 AM
> To: dmitry.torokhov@...il.com
> Cc: Kasun Beddewela <KBeddewela@...pglobal.com>; linux-
> input@...r.kernel.org; linux-kernel@...r.kernel.org; Ken Sloat
> <KSloat@...pglobal.com>
> Subject: input: Device Tree Properties for Captouch Button Device Registers
> 
> Hello Dmitry,
> 
> We have a new input driver we are currently working on and would like to
> submit
> to the Linux kernel when we finish it. Specifically, this is a cap touch IC which
> implements potentially multiple individual proximity and cap touch buttons
> (which
> would be reported like key events as seems to be the standard). A couple of
> questions:
> 
> 1. What is the preferred/proper method to expose the many registers that
> these devices have via device tree?
> 
> These devices have dozens of registers, many of which might be needed
> depending
> on the individual application. It wouldn't be useful in the majority of cases to
> provide
> default values in the driver as the registers are custom tuned to the
> individual application.
> 
> 2. Where should this device live? I am guessing in input/misc?
> 
> Thanks,
> Ken Sloat

CC'ing people from device tree mailing list since this discussion would be relevant there as well, so the more generic question would be: For any device which requires multiple unique register configuration values per target application - what is the preferred method to expose all these via devicetree? Maybe there are some good examples of this already somewhere in the kernel drivers?

Thanks,
Ken Sloat