|
From: | Damien Hedde |
Subject: | Re: [RFC PATCH v5 0/3] Sysbus device generic QAPI plug support |
Date: | Mon, 30 May 2022 16:05:30 +0200 |
User-agent: | Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.9.0 |
On 5/30/22 12:25, Peter Maydell wrote:
On Mon, 30 May 2022 at 10:50, Damien Hedde <damien.hedde@greensocs.com> wrote:TYPE_SYS_BUS_DEVICE also comes with reset support. If a device is on not on any bus it is not reached by the root sysbus reset which propagates to every device (and other sub-buses). Even if we move all the mmio/sysbus-irq logic into TYPE_DEVICE, we will still miss that. The bus is needed to handle the reset. For devices created in machine init code, we have the option to do it in the machine reset handler. But for user created device, this is an issue.Yes, the missing reset support in TYPE_DEVICE is a design flaw that we really should try to address.If we end up putting in TYPE_DEVICE support for mmios, interrupts and some way to do the bus reset. What would be the difference between the current TYPE_SYS_BUS_DEVICE ?There would be none, and the idea would be to get rid of TYPE_SYS_BUS_DEVICE entirely...
Do you expect the bus object to disappear in the process (bus-less system) or transforming the sysbus into a ~TYPE_BUS thing ?
Assuming we manage to sort out this does cold plugging using the following scenario looks ok ? (regarding having to issue one command to create the device AND some commands to handle memory-region and interrupt lines)
> device_add driver=ibex-uart id=uart chardev=serial0 > sysbus-mmio-map device=uart addr=1073741824 > qom-set path=uart property=sysbus-irq[0] value=plic/unnamed-gpio-in[1]TYPE_DEVICE or TYPE_SYS_BUS_DEVICE, my goal is still to be able to cold-plug a "ibex-uart" define its memory map and choose which irq I wire where.
Thanks, Damien
[Prev in Thread] | Current Thread | [Next in Thread] |