Re: pchb@acpi again

[Chuck Silvers <chuq%chuq.com@localhost>]

On Mon, Apr 15, 2013 at 09:14:51PM +0900, KIYOHARA Takashi wrote:
> > > > in acpi_pci.c, why do you need to skip the check for ACPI_VALID_ADR?
> > > > does the ACPI info on ia64 not have that flag set when it should?
> > > 
> > > In my memory, YES.  :-<
> > > But I can't access to my ia64 now.  I will try and check at next weekend.
> > 
> > In my ia64(zx6000), it looked that AcpiNsSearchAndEnter() returned
> > AE_NOT_FOUND.
> > How enable ACPI_DEBUG_PRINT or others many print?
> 
> I look this messages on my ia64. (e.g. PCI0)
> 
> _ADR Not found in 0xe00000003f9dd1e8 [Not adding]
> Name [_ADR] not found in scope [PCI0] 0xe00000003f9dd1e8
> 
> 
> I think that no this problem crops up by all ia64 machines.  Do you know
> the better evasion method?
> # Can I fixup by acpi_md_callback()?  I look and find that now.

I was thinking that acpi_md_callback() was called before the code where you
removed the check for ACPI_VALID_ADR, so you could have acpi_md_callback()
walk through the device tree constructed by acpi_build_tree() and set
ACPI_VALID_ADR on any devices where it was missing, as well as initializing
ad->ad_devinfo->Address.  but the check for ACPI_VALID_ADR in question is in
acpi_pcidev_scan(), which is called at the end of acpi_build_tree(),
so it's actually called before acpi_md_callback() is called.

it happens that ad->ad_devinfo->Address will be zero if ACPI_VALID_ADR
isn't set, I guess that value is actually correct on your system?

it looks like the existing MD callback isn't the right place to be useful
for this, and we can't move it to a useful place because of the change
that I made last year where I made x86/mpacpi.c use the PCI info that's
set up by acpi_pcidev_scan().

so I guess the easiest thing for now would be to add another MD callback
that is called from acpi_build_tree() just before the call to
acpi_pcidev_scan().  in that callback you could adjust ACPI_VALID_ADR
and ad->ad_devinfo->Address as I was originally thinking.
once we eventually migrate more of the logic from x86/mpacpi.c
to dev/acpi/*.c, maybe we'll find that we can merge some of these
callbacks.

-Chuck