Hi Peter and Philippe!
Thank you for the review and feedback! OK, I'll fix PCIE-relarted comments and the overlapping issue BR, Sergey Kambalin Software Developer, Auriga Inc. ________________________________ От: Peter Maydell <peter.mayd...@linaro.org> Отправлено: 26 февраля 2024 г. 10:41:31 Кому: Philippe Mathieu-Daudé Копия: Sergey Kambalin; qemu-...@nongnu.org; qemu-devel@nongnu.org; Kambalin, Sergey Тема: Re: [PATCH v6 11/41] Temporarily disable unimplemented rpi4b devices On Mon, 26 Feb 2024 at 16:06, Philippe Mathieu-Daudé <phi...@linaro.org> wrote: > > On 26/2/24 14:39, Peter Maydell wrote: > > On Mon, 26 Feb 2024 at 13:35, Philippe Mathieu-Daudé <phi...@linaro.org> > > wrote: > >> > >> On 26/2/24 01:02, Sergey Kambalin wrote: > >>> +static void raspi4_modify_dtb(const struct arm_boot_info *info, void > >>> *fdt) > >>> +{ > >>> + uint64_t ram_size; > >>> + > >>> + /* Temporarily disable following devices until they are implemented > >>> */ > >>> + const char *nodes_to_remove[] = { > >>> + "brcm,bcm2711-pcie", > >>> + "brcm,bcm2711-rng200", > >>> + "brcm,bcm2711-thermal", > >>> + "brcm,bcm2711-genet-v5", > >>> + }; > >>> + > >>> + for (int i = 0; i < ARRAY_SIZE(nodes_to_remove); i++) { > >>> + const char *dev_str = nodes_to_remove[i]; > >>> + > >>> + int offset = fdt_node_offset_by_compatible(fdt, -1, dev_str); > >>> + if (offset >= 0) { > >>> + if (!fdt_nop_node(fdt, offset)) { > >> > >> Peter, I remember a discussion where you wre not keen on altering DTB > >> for non-Virt machines. > >> > >> Since these devices are all implemented at the end of the series, why > >> not add the devices then the raspi4 board at the end, so this patch is > >> not even required? > > > > I'm not super-keen on it, but as you say it goes away once all > > the devices are implemented, so I'm not too worried. > > > > Doing it this way around would let us take the first 11 patches > > in the series into git now (they've all been reviewed), which > > gives us (I think) a functional raspi4 with some missing devices, > > which seems useful in the interim until the rest of the series > > gets reviewed and committed. > > Fine by me! Sergey, don't we also need patch #39 (Add missed BCM2835 > properties) to have a happy Linux boot? > > Patch #17 "Implement BCM2838 thermal sensor" could also go in but it > doesn't apply cleanly on top of 1-12); maybe Sergey can send a series > of "patches already reviewed" on top so they get in for v9, postponing > pcie/network for after release. I'll put together a pullreq tomorrow (see my other email for details of which patches plus the necessary changes to the avocado tests). Sergey -- I suggest you wait til that gets upstream, and then rebase on that. -- PMM