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

[matthieu castet <castet.matthieu@free.fr>]

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 ?