smbios.ko probes successfully if i disable acpi sysresource, fails if i do not

[John Baldwin]

On Thursday 26 October 2006 17:14, Nate Lawson wrote:
> John Baldwin wrote:
> > On Thursday 26 October 2006 12:28, Nate Lawson wrote:
> >> John Utz wrote:
> >>> Hello;
> >>>
> >>> as you may know i am attempting to use fbsd's smbios functionality to 
> >>> support porting the linux i8k-utils dell smbios keyboard and fan stuff.
> >>>
> >>> i just discovered today that disabling sysresource allows the module to 
> >>> attach.
> >>>
> >>> so, here's the part that i'd love some help with understanding:
> >>>
> >>> 1. with acpi enabled, is smbios.ko supposed to be asking acpi for a 
> >>> resource handle or something?
> >>>
> >>> 2. is acpi_resource.c behaving in error? should it not be consuming the 
> >>> smbios startaddr?
> >>>
> >>> note that startaddr for smbios is 0xf000, bios.c looks for pnpbios and 
> >>> pcibios starting at 0xe000 and completely ignores smbios.
> >>>
> >>> it seems to me that either statement 1 or 2 is correct, but not both.
> >>>
> >>> of course, i could be totally wrong, can anybody enlighten me?
> >> ACPI reserves sysresource objects for downstream devices.  Then, those 
> >> devices get the resources they request via ACPI.  Anyway, all this 
> >> should be transparent to the downstream devices.  They shouldn't care if 
> >> they're getting their resources from nexus (top, pseudo-device) or acpi.
> >>
> >> Are you using bus_alloc_resource() or the equivalent to get the 
> >> resources in your driver?  It transparently maps resource requests to 
> >> upstream devices.  Please send the output of devinfo -rv with your 
> >> driver installed, both with and without sysresource enabled in ACPI.
> > 
> > smbios is attached to nexus though, so acpi isn't upstream.
> > 
> 
> Why is smbios on nexus?  It seems desirable to have it under the 
> top-level bus, which would be acpi if it is not disabled.  Also, npx 
> should be there too (additional rationale: npx devices are defined in 
> the acpi Device namespace).

Because they aren't ACPI specific, and if we go that route we'll have to make 
several drivers attach to both acpi and legacy.  This would work if acpi and 
legacy were named differently (platform0 maybe, and you have two 'platform' 
drivers, nexus adds a platform device, and legacy and acpi both get to probe 
it, but acpi returns higher probe value on success).

-- 
John Baldwin