On Mon, Feb 22, 2016 at 10:14:50PM +0200, Michael S. Tsirkin wrote:
> On Sun, Feb 21, 2016 at 08:06:17AM -0500, Gabriel L. Somlo wrote:
> > > > +static void fw_cfg_io_cleanup(void)
> > > > +{
> > > > + if (fw_cfg_is_mmio) {
> > > > + iounmap(fw_cfg_dev_base);
> > > > + release_mem_region(fw_cfg_p_base, fw_cfg_p_size);
> > > > + } else {
> > > > + ioport_unmap(fw_cfg_dev_base);
> > > > + release_region(fw_cfg_p_base, fw_cfg_p_size);
> > > > + }
> > > > +}
> > > > +
> > > > +/* arch-specific ctrl & data register offsets are not available in ACPI, DT */
> > >
> > > So for all arches which support ACPI, I think this driver
> > > should just rely on ACPI.
> >
> > There was a discussion about that a few versions ago, and IIRC the
> > conclusion was not to expect the firmware to contend for fw_cfg access
> > after the guest kernel boots:
> >
> > https://lkml.org/lkml/2015/10/5/283
> >
>
> So it looks like NVDIMM at least wants to pass label data to guest -
> for which fw cfg might be a reasonable choice.
>
> I suspect things changed - fw cfg used to be very slow but we now have
> DMA interface which makes it useful for a range of applications.
>
> > (I even had a prototype version doing what you suggested, but per the above
> > reference decided to drop it -- which IMHO is for the better, since otherwise
> > I'd have had to ifdef between ACPI and non-ACPI versions of the driver --
> > see https://lkml.org/lkml/2015/11/4/534 )
>
> I'm not sure why you have these ifdefs - they are on the host, are they
> not?
Think of those as "pseudocode" ifdefs, they're there to distinguish
between AML that would be generated on MMIO vs. IOPORT systems
(specifically, arm vs. x86, respectively)
Some of the AML is the same, but obviously the _CRS, and
OperationRegion + Field are different, and I wanted to point that out
somehow :)
Cheers,
--Gabriel
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
