Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67;
Subject: Re: Re: [PATCHv1 2/2] Input: EXC3000: Add support to query model and
 fw_version
To:     Dmitry Torokhov <dmitry.torokhov@gmail.com>,
        Sebastian Reichel <sebastian.reichel@collabora.com>
Cc:     Ahmet Inan <inan@distec.de>, linux-input@vger.kernel.org,
        linux-kernel@vger.kernel.org, kernel@collabora.com
References: <20191107181010.17211-1-sebastian.reichel@collabora.com>
 <20191107181010.17211-2-sebastian.reichel@collabora.com>
 <20191113002339.GJ13374@dtor-ws>
From:   Martin Fuzzey <martin.fuzzey@flowbird.group>
Message-ID: <eb7f29f9-673d-6e37-0846-226e21b95766@flowbird.group>
Date:   Wed, 20 Nov 2019 12:47:55 +0100
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101
 Thunderbird/60.6.1
MIME-Version: 1.0
In-Reply-To: <20191113002339.GJ13374@dtor-ws>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit
Content-Language: fr
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk

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