Re: [PATCH 00/12] hw/mips/fuloong2e: PoC to fix hang after reboot

[Aleksandar Markovic]

уто, 26. мај 2020. у 09:47 Philippe Mathieu-Daudé <address@hidden>
је написао/ла:
>
> On 5/10/20 11:01 PM, Philippe Mathieu-Daudé wrote:
> > The PMON firmware behave differently regarding it is run
> > after a cold/warm reset. A simple bit flip fix the issue,
> > however we need to know the type of reset to set it.
> > Currently QEMU only supports COLD reset.
> >
> > This series contains various of my current Fuloong queue,
> > - Welcome Huacai Chen as co-maintainer,
> > - Fix typo in machine name,
> > - Few cleanups in Bonito64,
> > - Report various Bonito64 accesses as UNIMP,
> > - Proof-of-concept fix for the reset bit.
> >
> > The last patch is not for merging, but is included to see
> > if the Multi-phase reset mechanism can fix the problem.
> >
> > Regards,
> >
> > Phil.
> >
> > Huacai Chen (1):
> >   MAINTAINERS: Add Huacai Chen as fuloong2e co-maintainer
> >
> > Philippe Mathieu-Daudé (11):
> >   hw/mips/fuloong2e: Rename PMON BIOS name
> >   hw/mips/fuloong2e: Move code and update a comment
> >   hw/mips/fuloong2e: Fix typo in Fuloong machine name
> >   hw/pci-host: Use CONFIG_PCI_BONITO to select the Bonito North Bridge
> >   hw/pci-host/bonito: Fix DPRINTF() format strings
> >   hw/pci-host/bonito: Map peripheral using physical address
> >   hw/pci-host/bonito: Map all the Bonito64 I/O range
> >   hw/pci-host/bonito: Map the different PCI ranges more detailled
> >   hw/pci-host/bonito: Better describe the I/O CS regions
> >   hw/pci-host/bonito: Set the Config register reset value with
> >     FIELD_DP32
> >   POC hw/pci-host/bonito: Fix BONGENCFG value after a warm-reset
>
> Thanks, patches 1, 3-11 queued to mips-next after addressing Aleksandar
> comments.
>

Over all, I think you should have sent a new version of the series
rather than starting applying to the queueu.
Philippe, I think you should "unqueue" everything, and start from
scratch you queue.
In future, I think you should coordinate better queuing, possibly in
some separate off-list messages.
Patch 4/12 - does it have r-b?

Patch 9/12 - I don't want to block you r work, but you are making some
missteps that are not good here:

- i did not see how you addressed mu comments
- I didnt give the patch R-b, neither I remember anyone else
- I am against pull request with patches without r-b, if that is the
case with 9/12, and insist on applying the same principle to hw/mips