[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: BALATON Zoltan
Subject: Re: [PATCH v3 06/13] hw/i2c/ppc4xx_i2c: Replace i2c_send_recv() by i2c_recv() & i2c_send()
Date: Thu, 17 Jun 2021 01:09:05 +0200 (CEST)

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

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:


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

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.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]