linux-kernel - Re: Re: [PATCHv1 2/2] Input: EXC3000: Add support to query model and fw

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] [thread-next>] [day] [month] [year] [list]

Message-ID: <eb7f29f9-673d-6e37-0846-226e21b95766@flowbird.group>
Date:   Wed, 20 Nov 2019 12:47:55 +0100
From:   Martin Fuzzey <martin.fuzzey@...wbird.group>
To:     Dmitry Torokhov <dmitry.torokhov@...il.com>,
        Sebastian Reichel <sebastian.reichel@...labora.com>
Cc:     Ahmet Inan <inan@...tec.de>, linux-input@...r.kernel.org,
        linux-kernel@...r.kernel.org, kernel@...labora.com
Subject: Re: Re: [PATCHv1 2/2] Input: EXC3000: Add support to query model and
 fw_version

Hi Dmitry,

On 13/11/2019 01:23, Dmitry Torokhov wrote:
> Do we really need to re-fetch model (and firmware ID) on each access?
> Can we query it as probe time and cache? This I think would simplify the
> driver, as you probably would not need to hook it into the ISR. Can you
> just post a read/write transaction to fetch it without waiting for
> interrupt? Or, if single transaction does not work and you need to wait
> for certain time for response - just add msleep() and maybe mark driver
> for async probe...

Having the sysfs access actually read the data from the device can be 
useful to check that the I2C link is still working (in a test scenario).

The documentation does say that one should wait for an interrupt after 
issuing the commands.

The msleep() could work but the value would have to be empirical and 
could be fragile.

Furthermore what happens if a touch event occurs just after sending the 
query request?

Having the interrupt handler be the single read() point and dispatching 
solves that problem, even if it does complicate the driver to some extent.

One further thing is that there are other commands that may be added in 
the future that cannot be cached (commands to do tests or fimware 
updates for example).

Regards,

Martin