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

[Bjorn Helgaas <bjorn.helgaas-VXdhtT5mjnY@public.gmane.org>]

On Wednesday 03 August 2005 3:16 pm, matthieu castet wrote:
> 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.

I didn't see any new ones when I looked for METHOD_NAME__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.

You're right, this was broken.  But I've been pushing a PNPACPI
patch to fix this.

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

Yeah, I did that, and it was a huge mistake.  The point was to avoid
blind probing for the device, but my concern was for ia64, and no ia64
boxes have floppy, so it's much easier to just not build the driver.

> 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 ?

If you mean the last paragraph of section 6, I don't really understand
it.  But it mentions 8250_acpi.c as an obstacle, and I do know that we
are very close to being able to remove that.  I've already posted two
patches (one to PNPACPI to fix the 64-bit address problem, and one to
8250_pnp to add support for MMIO UARTs).  Once those are accepted, we
should be able to remove 8250_acpi.c.  I think only ia64 really relies
on it anyway.

> PPS : is there any plan to integrate 
> http://marc.theaimsgroup.com/?l=linux-kernel&m=111827568001255&w=2

I'm afraid I don't know anything about this one.


-------------------------------------------------------
SF.Net email is Sponsored by the Better Software Conference & EXPO
September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices
Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA
Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf