On Thu, Oct 6, 2022 at 10:58 AM Patrick Venture <vent...@google.com> wrote:
> > > On Tue, Sep 20, 2022 at 12:00 AM Thomas Huth <th...@redhat.com> wrote: > >> On 20/09/2022 00.37, Patrick Venture wrote: >> > >> > >> > On Mon, Sep 19, 2022 at 5:44 AM Thomas Huth <th...@redhat.com >> > <mailto:th...@redhat.com>> wrote: >> > >> > On 06/09/2022 18.31, Patrick Venture wrote: >> > > The register tests walks all the registers to verify they are >> initially >> > > 0 when appropriate. However, if the MAC address is set in the >> register >> > > space, this should not be checked against 0. >> > > >> > > Reviewed-by: Hao Wu <wuhao...@google.com <mailto: >> wuhao...@google.com>> >> > > Change-Id: I02426e39bdab33ceedd42c49d233e8680d4ec058 >> > >> > What's that change-id good for? >> > >> > >> > Oops, sorry about that. I can send out a v2 without it, or during >> > application someone can nicely trim it? :) >> >> I can take the patch through my qtest branch - I'll drop the line there. >> >> > Basically ack, but one question: Where should that non-zero MAC >> address >> > come >> > from / when did you hit a problem here? If QEMU is started without >> any mac >> > settings at all (like it is done here), the register never contains >> a >> > non-zero value, does it? >> > >> > >> > So, there's a bug in the emc device presently where that value isn't >> set >> > when it should be. I have that bug fixed, but for whatever reason, >> probably >> > not enough caffeine, I didn't bundle the two patches together. >> >> OK, makes sense now, thanks for the explanation! >> > > The follow-on patch was just applied to arm.next, so I wanted to check if > this was applied to your .next or if you wanted a v2. > Nevermind, sorry for the spam - I already saw it in a PULL but forgot to update my internal tracking. Thanks! > > >> >> Thomas >> >> >>
