Re: [PATCH 0/4] acpi: fix up EJ0 in DSDT

["Michael S. Tsirkin" <mst@redhat.com>]

On Thu, Sep 22, 2011 at 12:35:13AM -0400, Kevin O'Connor wrote:
> On Wed, Sep 21, 2011 at 03:44:13PM +0300, Michael S. Tsirkin wrote:
> > The reason is that our acpi tables declare both _RMV with value 0,
> > and _EJ0 method for these slots. What happens in this case
> > is undocumented by ACPI spec, so linux ignores _RMV,
> > and windows seems to ignore _EJ0.
> 
> Could the DSDT just not define _EJ0 for device 1 & 2 instead of
> dynamically patching them?  (Would there ever be a case where we
> wouldn't know at compile time which devices need _EJ0?)

Yes. in qemu we can make any slot non hotpluggable on command
line by requesting a non hotpluggable device be put there.

> > The correct way to suppress hotplug is not to have _EJ0,
> > so this is what this patch does: it probes PIIX and
> > modifies DSDT to match.
> 
> The code to generate basic SSDT code isn't that difficult (see
> build_ssdt and src/ssdt-proc.dsl).  Is there a compelling reason to
> patch the DSDT versus just generating the necessary blocks in an SSDT?
> 
> -Kevin

I don't really care whether the code is in DSDT or SSDT,
IMO there isn't much difference between build_ssdt and patching:
main reason is build_ssdt uses offsets hardcoded to a specific binary
(ssdt_proc and SD_OFFSET_* ) while I used
a script to extract offsets.

I think we should avoid relying on copy-pasted binary 
because I see the related ASL code changing in the near future
(with multifunction and bridge support among others).

I can generalize the approach though, so that
it can work for finding arbitrary names
without writing more scripts, hopefully with the
potential to address the hard-coded offsets in acpi.c
as well. Does that sound interesting?

-- 
MST