Am 30. September 2024 12:57:17 UTC schrieb Peter Maydell 
<peter.mayd...@linaro.org>:
>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.

New series sent which removes qemu_allocate_irq() usage in e500.c: 
https://lore.kernel.org/qemu-devel/20241005100228.28094-1-shen...@gmail.com/

Best regards,
Bernhard

>
>thanks
>-- PMM

Reply via email to