linux-kernel - Re: [PATCH v10 43/55] dt-bindings: input: atmel: support to set max bytes transferred

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: <5abe310f-094c-9355-d533-fb64efcbf726@mentor.com>
Date:   Thu, 9 Apr 2020 15:25:15 +0900
From:   "Wang, Jiada" <jiada_wang@...tor.com>
To:     Dmitry Osipenko <digetx@...il.com>, <nick@...anahar.org>,
        <dmitry.torokhov@...il.com>, <jikos@...nel.org>,
        <benjamin.tissoires@...hat.com>, <bsz@...ihalf.com>
CC:     <linux-input@...r.kernel.org>, <linux-kernel@...r.kernel.org>,
        <erosca@...adit-jv.com>, <Andrew_Gabbasov@...tor.com>,
        <Balasubramani_Vivekanandan@...tor.com>
Subject: Re: [PATCH v10 43/55] dt-bindings: input: atmel: support to set max
 bytes transferred

Hi Dmitry

On 2020/04/07 23:47, Dmitry Osipenko wrote:
> 07.04.2020 12:27, Wang, Jiada пишет:
> ..
>>> Is this a software (firmware) limitation which varies from version to
>>> version?
>>>
>>
>> the timeout issue trying to be addressed in this patch is from software,
>> one of our board a Serializer/Deserializer bridge exists between the SoC
>> (imx6) and the Atmel touch controller.
>> imx6 i2c controller driver has a timeout value(100ms) for each i2c
>> transaction,
>> Large i2c read transaction failed to complete within this timeout value
>> and therefore imx6 i2c controller driver aborts the transaction
>> and returns failure.
>>
>> Therefore this patch was created to split the large i2c transaction into
>> smaller chunks which can complete
>> within the timeout defined by i2c controller driver.
> 
> Isn't it possible to use the max_read/write_len of the generic struct
> i2c_adapter_quirks for limiting the transfer size?
> 
> BTW, it looks like the i.MX I2C driver doesn't specify the
> i2c_adapter_quirks, which probably needs to be fixed.
> 
yes, i.MX I2C driver can specify i2c_adapter_quirks to limit the size be 
transferred in one transaction.

But even in this case, mxt_process_messages_t44() fails when it tries to 
transfer data count larger than max_read/write_len set in i.MX I2C 
driver, which we would like to avoid.


Thanks,
Jiada