Re: [ACPI] Re: [PATCH] PNPACPI: fix types when decoding ACPI resources [resend]

matthieu castet
2005-08-03T21:21:06Z

Hi,

Bjorn Helgaas wrote:
> On Tuesday 02 August 2005 7:01 pm, Shaohua Li wrote:
>

>
>>Did you have plan to remove other
>>legacy acpi drivers?
>
>
> No, I didn't -- which ones are you thinking about? Looking at
> the callers of acpi_bus_register_driver(), I see:
looking for METHOD_NAME__CRS is more acurate.
>
> arch/ia64/hp/common/sba_iommu.c
> Probably can't be converted because it needs the
> ACPI handle to extract a vendor-specific data
> item from _CRS.
>
> drivers/char/hpet.c
> This probably should be converted to PNP. I'll
> look into doing this.
IIRC, I am not sure that the pnp layer was able to pass the 64 bits
memory adress for hpet correctly. But it would be nice if it works.

There are drivers/acpi/motherboard.c that done some stuff already handle
by pnp/system.c.

There was an extention of a floppy driver in order to use acpi in -mm,
but it seems to have been dropped.

>
> Then of course, there are a bunch of things in drivers/acpi/
> (battery, button, fan, ec, etc). I expect the reason they are
> in drivers/acpi/ is because they need ACPI-specific functionality,
> so they probably couldn't be converted to PNP.
yes.

Matthieu

PS : I saw in acpi ols paper that you plan once all dupe acpi drivers
will be removed to register again the pnp device in acpi layer. Do you
plan to add more check and for example add only device that have a CRS
in pnp layer ?

PPS : is there any plan to integrate
http://marc.theaimsgroup.com/?l=linux-kernel&m=111827568001255&w=2 that
seem to fix some init problem ?