linux-kernel - Re: [PATCH 1/1] Input: atmel_mxt_ts

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]

Date:   Thu, 3 Sep 2020 18:06:14 +0300
From:   Dmitry Osipenko <digetx@...il.com>
To:     "Wang, Jiada" <jiada_wang@...tor.com>, nick@...anahar.org,
        dmitry.torokhov@...il.com
Cc:     linux-input@...r.kernel.org, linux-kernel@...r.kernel.org,
        erosca@...adit-jv.com, Andrew_Gabbasov@...tor.com
Subject: Re: [PATCH 1/1] Input: atmel_mxt_ts - implement I2C retries

03.09.2020 17:44, Wang, Jiada пишет:
> Hi Dmitry
> 
...
>> Is it really possible to get a positive ret != 2 from i2c_transfer()?
>>
>> Maybe it's better to keep the old code behaviour by returning the "ret"
>> value directly if it's not equal to ARRAY_SIZE(xfer)?
>>
> I think, theoretically i2c_transfer() may return positive value but !=
> number to transfer,
> original behavior is,
> when ret >= 0, it returns -EIO, when ret < 0, it just returns ret,
> 
> current behavior is, when ret != 2, it returns -EIO, after retry.
> 
> I am OK to change the behavior exactly as same original one.

The comment to i2c_transfer() says that it either returns a error code
or number of executed messages. But it's not clear to me what I2C driver
could return 0 or 1 here and why.

I think it indeed should be better to keep the original behaviour by
propagating the actual error code whenever possible. It's probably not
critical for this particular case, but in general it's always better to
preserve the original error code.