Jan Kiszka <jan.kis...@siemens.com> writes: > On 2011-06-08 13:33, Peter Maydell wrote: >> At the moment you can't really implement one sysbus device by saying >> that it's composed of a set of other sysbus devices. This patch adds >> new functions sysbus_pass_mmio() and sysbus_pass_one_irq() which >> allow a sysbus device to delegate an MMIO or IRQ to another sysbus >> device (The approach is inspired by the existing sysbus_pass_irq() >> which lets a sysbus device delegate all its IRQs at once). >> >> This works; the most obvious deficiency is that the subcomponent >> device will still appear as its own device on the bus. >> >> So: is this a reasonable solution to the problem, or an unacceptable >> hack? Comments welcome :-) > > Sounds more like a little hack. :) > > The relationships should be expressed via qdev, not yet another > sysbus-specific extension. Generally, many services of sysbus should > rather be generic qdev things.
Examples? > Is there anything that today prevents creating a local bus and attaching > the component devices to that? If it's multi-bus support, that should to > be added anyway. Passing-through of MMIO and IRQs is still a worthwhile > generic service, then probably qbus associated. Do you mean making the container device a sysbus-sysbus-bridge, then hanging the component devices off the inner sysbus?