[Top][All Lists]

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

Re: [Qemu-devel] [PATCH v2 0/7] Misc sm501 improvements

From: BALATON Zoltan
Subject: Re: [Qemu-devel] [PATCH v2 0/7] Misc sm501 improvements
Date: Wed, 4 Jul 2018 12:12:09 +0200 (CEST)
User-agent: Alpine 2.03 (LMD 1266 2009-07-14)

On Wed, 4 Jul 2018, Philippe Mathieu-Daudé wrote:
Hi David, I'll reply to you using Peter mail :)

Thanks a lot for this summary and your review spotting an error. I forgot about Gerd's OK as he did not send formal Reviewed or Acked but you're right that's also counts to show that the series should be sane.

I did not want to become maintainer of sm501 for at least two reasons:

1. Because it was part of SH and thus it should already have a maintainer or if it doesn't any more then I can't take that either as I don't know SH

2. I'm not familiar with the tasks a maintainer has to do and don't have enough time now to do that

But if it's only a question of responsibility I don't ask you to take that, only ask David or Peter to help in merging this. I take responsibility for problems it causes and will try to fix it or I'm OK to have it removed if I fail to do that. Hope that's acceptable at least for now, then we can discuss about what to do with the sam460ex and related parts for the future.

Thank you,

On 07/03/2018 06:13 AM, Peter Maydell wrote:
On 3 July 2018 at 01:28, David Gibson <address@hidden> wrote:
On Mon, Jul 02, 2018 at 10:42:07AM +0100, Peter Maydell wrote:
I can have a look, but really I think these should go via the
ppc tree -- the device is used in a ppc machine and an sh4 one,
and the ppc tree is much more active than sh4.

Hm, well, if you like.  Although the gradual creep of my
maintainership scope into things I know less and less about makes me
rather nervous.  I tried to convince Balaton Zoltan to become sm501
maintainer, but he didn't bite.

It's not like I know anything more about the sm501 than you do :-)

The arm parts of the tree have a lot of board and device code
I'm not familiar with either. Generally the approach I use is:
 * eyeball the code to see if it's doing anything that looks
   "obviously wrong", failing to use correct QEMU APIs, etc

Gerd Hoffmann did a review for the graphic code,
then commented "all look sane":

I don't have a serious understanding of QEMU graphic internals, but
looked at those patches and didn't find anything "obviously wrong".

 * anything that touches 'core' code or code common to multiple
   machines gets closer scrutiny

The only SH4 tests I run are using Aurelien Debian:

 * I might check the data sheet if I'm feeling enthusastic or
   if the code looks like it's doing weird things, but often
   not, especially if the code has had review from somebody else

I did a review of the I2C/DDC patch with the specs at hand.

 * if I have a test image to hand I'll do a smoke test, but often
   I don't have a test image

Neither do I.

Basically I think the important thing is to make sure the
codebase stays maintainable and generally the quality bar
in terms of using the right APIs and design approaches
tends to ratchet up rather than down. If our implementation
of an obscure device isn't actually right, that doesn't
really affect very many users, so I worry less about that
side of things.

Zoltan used few deprecated API but said updating "could be done in
separate clean up", which I agree :)

FWIW and using Peter's criteria I think this series is good to go.



reply via email to

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