On Thu, Jun 17, 2021 at 01:09:05AM +0200, BALATON Zoltan wrote:
> 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é <f4...@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.
I understand your concern, but these sorts of interfaces are really just
asking for trouble, as you experienced and as seen by the other patch
that fixed an error using the same interface. It's better to have a
clear interface that takes a little more code than one that is easy to
make a mistake with. That's my opinion, anyway.
I'm also not a big fan of i2c_start_transfer(); it's confused me more
than once. But that would be harder to fix :-(.
-corey
>
> > > 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
