Re: [PATCH v4 1/1] Input: atmel_mxt_ts - implement I2C retries

[Dmitry Osipenko <digetx@gmail.com>]

14.09.2020 16:49, Andy Shevchenko пишет:
> On Sun, Sep 13, 2020 at 3:57 PM Dmitry Osipenko <digetx@gmail.com> wrote:
>>
>> 13.09.2020 11:43, Andy Shevchenko пишет:
>>> ...
>>>
>>>> +       bool retried = false;
>>
>>> I thought Dmitry wants that to be retry
>>
>> In the comment to v2 you suggested to negate the condition,
> 
> Where? I just checked a few messages before and I found that I asked
> the same question: why is negative conditional used instead of
> positive.

I'm reading this as imperative "make it positive", and thus, assumed
that you asked to do so because the "retry" implies a positive
condition, while "retried" implies the negative.

If you've added "Could you please explain why", then I'd read it as a
question.

>> hence I
>> thought it's YOU who wants it to be retried.
> 
> I see. Let's see how it goes with positive conditionals first.
> 
> 
>> The "retried" is a very common form among kernel drivers, so it's good
>> to me.
>>
>>>>         u8 buf[2];
>>>>         int ret;
>>>
>>>> -       ret = i2c_transfer(client->adapter, xfer, 2);
>>>> -       if (ret == 2) {
>>>> -               ret = 0;
>>>> -       } else {
>>>> -               if (ret >= 0)
>>>> -                       ret = -EIO;
>>>> +retry_read:
>>>
>>>> +       ret = i2c_transfer(client->adapter, xfer, ARRAY_SIZE(xfer));
>>>> +       if (ret != ARRAY_SIZE(xfer)) {
>> ...> Also why switch from positive to negative conditional?
>>
>> This will make code less readable because of the goto, and thus, there
>> will be two branches for handling of the returned value instead of one +
>> goto. Hence this part is good to me as-is.
> 
> But it's not the purpose of this patch, right?
> Style changes should be really separated from the fix.

This should be up to a particular maintainer to decide. Usually nobody
requires patches to be overly pedantic, this may turn away contributors
because it feels like an unnecessary bikeshedding. It's more preferred
to accept patch as-is if it does right thing and then maintainer could
modify the patch, making cosmetic changes.

> And since it's a fix it should have a Fixes tag.

It shouldn't be a fix, but a new feature because apparently the 1386
controller wasn't ever intended to be properly supported before this patch.