Re: [Qemu-devel] [PATCH v2 4/5] acpi: arm: add fw_cfg device node to dsdt

[Gabriel L. Somlo]

On Tue, Sep 15, 2015 at 02:51:31PM +0100, Peter Maydell wrote:
> On 15 September 2015 at 14:42, Gabriel L. Somlo <address@hidden> wrote:
> > On Tue, Sep 15, 2015 at 10:06:45AM +0800, Shannon Zhao wrote:
> >> This looks fine to me. But from what you said, the kernel driver is not
> >> in upstream kernel yet, so this would be applied after the kernel patch
> >> applied in case of unexpected change.
> >
> > I guess that's ok if you're only talking about the arm side of things
> > -- although I can't imagine how any of the above would need to change
> > depending on what happens with the guest-side kernel sysfs driver...
> > We're talking a node name ("FWCF"), a _HID ("QEMU0002"), and a mmio
> > region (given to us by memmap[VIRT_FW_CFG]), and that's all there is
> > to it...
> 
> The underlying requirement here is "we don't want patches until
> the ABI is fixed". For ACPI and DTB on ARM the final arbiter of
> the ABI seems to be the kernel (partly because the reviewers there
> are better informed with the overall ACPI/DTB requirements).
> I don't know who the final arbiter of the ACPI ABI for x86 is.
> 
> We've already had a couple of issues with problems with the ACPI
> ABI for what appear to be very simple "just some registers and
> an interrupt" type devices, including "is this the correct HID?".

OK, assuming part of upstreaming a potential fw_cfg sysfs driver
includes bickering over whether "QEMU0002" should or shouldn't be the
correct _HID, then yeah, keeping this stuff out-of-tree until that's
settled feels like the right thing to do...
 
> > However, on the i386 side, this needs to go in *before* I can continue
> > working on the guest-side kernel sysfs drivers. One of the
> > requirements I got was not to probe IOports or MMIO registers blindly,
> > but rather to use DT on arm and ACPI on i386 to first make sure fw_cfg
> > is expected to be there, before tickling its registers :)
> 
> > So I need (at least the i386 part of) this series in qemu before I can
> > move ahead with the (guest) kernel driver...
> 
> Why can't you work on your guest kernel driver using a set of
> out-of-tree QEMU patches to test it with?

As long as I don't get "convince the qemu guys first, then come back
and talk to us" from the kernel people as well, that should be OK with
me :) :)

I'd still appreciate feedback here in the mean time (e.g. once I do v3
to conditionally include fw_cfg only on >= 2.5, per Eduardo's
suggestion), and whatever else it would take to get the series ready
for acceptance (modulo the kernel naming convention negotiations
you're anticipating).

Thanks a ton,
--Gabriel