On Mon, 23 Sept 2024 at 11:16, Bernhard Beschow <shen...@gmail.com> wrote: > > This series is part of a bigger series exploring data-driven machine creation > using device tree blobs on top of the e500 machines [1]. The idea is to > instantiate a QEMU device model for each device tree node containing a > compatible property. [1] achieves feature-parity with the hardcoded machines > when supplied the same device tree blob that the hardcoded machine would > generate.
FWIW, on Arm I have generally pushed back against the idea of "create a QEMU machine from a device tree", because the device tree does not in general contain sufficient information to create a QEMU machine. It only has the information that Linux needs to use the devices, which is a subset of the total "how do all these devices exist and get wired together". (There are some special cases like some Xilinx FPGA systems, where both the device tree and the hardware were autogenerated from a common source definition, and so there's enough of a constraint on what the hardware can be to make it workable.) > Just like the ARM virt machine, the ppce500 machine implements a > "gpio-poweroff"-compatible device tree node. Unfortunately, the implementation > isn't shared which this series fixes. In order to reflect device tree which > has > separate bindings for gpio-poweroff and gpio-reset, and to prepare for the > above, the gpio-pwr device model is split. > > Note: If the split seems too fine-grained, the existing gpio-pwr device model > could probably be reused in ppce500, too. I definitely like getting rid of the hand-coded qemu_allocate_irq() in e500.c. But I don't really see the benefit of splitting gpio_pwr into two devices. If you only need the power-off behaviour, you can leave the restart gpio input not connected to anything. thanks -- PMM
