Re: [PATCH v3 06/13] hw/i2c/ppc4xx_i2c: Replace i2c_send_recv() by i2c_recv() & i2c_send()

[BALATON Zoltan <balaton@eik.bme.hu>]

[-- Attachment #1: Type: text/plain, Size: 4835 bytes --]

On Wed, 16 Jun 2021, Philippe Mathieu-Daudé wrote:
> On 6/16/21 10:01 PM, BALATON Zoltan wrote:
>> On Wed, 16 Jun 2021, Philippe Mathieu-Daudé wrote:
>>> On 6/16/21 9:16 PM, Corey Minyard wrote:
>>>> On Wed, Jun 16, 2021 at 06:14:11PM +0200, Philippe Mathieu-Daudé wrote:
>>>>> Instead of using the confuse i2c_send_recv(), rewrite to directly
>>>>> call i2c_recv() & i2c_send(), resulting in code easire to review.
>>>>>
>>>>> Signed-off-by: Philippe Mathieu-Daudé <f4bug@amsat.org>
>>>>> ---
>>>>>  hw/i2c/ppc4xx_i2c.c | 13 ++++++++-----
>>>>>  1 file changed, 8 insertions(+), 5 deletions(-)
>>>>>
>>>>> diff --git a/hw/i2c/ppc4xx_i2c.c b/hw/i2c/ppc4xx_i2c.c
>>>>> index f4c5bc12d36..b3d3da56e38 100644
>>>>> --- a/hw/i2c/ppc4xx_i2c.c
>>>>> +++ b/hw/i2c/ppc4xx_i2c.c
>>>>> @@ -240,11 +240,14 @@ static void ppc4xx_i2c_writeb(void *opaque,
>>>>> hwaddr addr, uint64_t value,
>>>>>                          i2c->sts &= ~IIC_STS_ERR;
>>>>>                      }
>>>>>                  }
>>>>> -                if (!(i2c->sts & IIC_STS_ERR) &&
>>>>> -                    i2c_send_recv(i2c->bus, &i2c->mdata[i], !recv)) {
>>>>> -                    i2c->sts |= IIC_STS_ERR;
>>>>> -                    i2c->extsts |= IIC_EXTSTS_XFRA;
>>>>> -                    break;
>>>>> +                if (!(i2c->sts & IIC_STS_ERR)) {
>>>>> +                    if (recv) {
>>>>> +                        i2c->mdata[i] = i2c_recv(i2c->bus);
>>>>> +                    } else if (i2c_send(i2c->bus, i2c->mdata[i])) {
>>>>
>>>> In the previous patch you checked < 0, it would be nice to be
>>>> consistent.
>>>
>>> I did that first but thought Zoltan wouldn't be happy, then went back :)
>>>
>>> I'll fix for the next iteration, thanks.
>>
>> I generally had no problem with i2c_send_recv only that its argument
>> that decides which operation to do was inverted compared to other
>> similar i2c functions so my original patch just corrected that for
>> consistency and I was happy with that.
>
> But we have to make the maintainer happy too to get patch merged ;)

Getting this series in actually means more work for me as I have to 
rewrite my unfinfshed patch to not use send_recv so just leaving it as it 
is would be less work. I mean this patch:

https://lists.nongnu.org/archive/html/qemu-ppc/2020-06/msg00682.html

Where having send_recv is actually nice as I can write it without too much 
if-else clauses but having send_recv and start_transfer with opposite 
sense recv argument is confusing. This is where the orignal patch comes 
from and the point was to just correct this inconsistency between 
start_transfer and send_recv because I got it wrong first but it went 
overboard now removing the whole function instead of just correcting it so 
I'll have to rewrite this patch and make it longer and also have to 
rethink what can fail and how. I also have to review and test all other 
places I've used send_recv before so at this point I would not mind if it 
was left as it is now, then I could just drop my original patch and 
reverse the last argument of send_recv in the above WIP patch and be done 
with it. Much less work than going through this series so I almost regret 
bringing this up again. But if it makes you happy so be it.

>> Having a send_recv in one func
>> allowed to avoid if-else in some places like these but if you think it's
>> better without this function at all I can work with that too. I'll have
>> to check if these changes could break anything. At first sight I'm not
>> sure errors are handled as before if recv fails but it was years ago I
>> did the sm501 and ati parts and I forgot how they work so I need to
>> check again. I'll wait for the final version of the series then and test
>> that.
>
> Thanks, that would be great!
>
>> I remember I had to tweak these a lot because each guest OS had
>> drivers that did things slightly differently so if I've fixed one,
>> another broke until I've found a way that worked for all.
>
> I wish Avocado (or any other testing framework) could help you with
> your testing, and you could contribute your tests even if you can not
> contribute your firmware blob due to incompatible license.
> That would help us understand how you use your firmware, and save you
> time while testing.

Unfortunately it's not only firmware but there's also AmigaOS which is not 
freely available so that would be hard to automate. Other than that 
testing sam460ex and pegasos2 with Linux and MorphOS could be done but I'm 
more comfortable with running a few commands that I already have than 
setting up and learning a testing framework for this so it won't be me who 
makes these test cases. It's not that many boards and OSes that I care 
about to need it automated but I've shared the commands before, they are 
on my web pages about these boards.

Regards,
BALATON Zoltan