Re: updated ACPI patch against 2.6.13-rc1

[Pavel Machek <pavel-+ZI9xUNit7I@public.gmane.org>]

Hi!

> > > This patch includes all the dusty patches that have been
> > > waiting in BK me for 2.6.13 to open.
> > > It applies against 2.6.13-rc1.
> > >
> > >
> > ftp://ftp.kernel.org/pub/linux/kernel/people/lenb/acpi/patches/release/2.6.13/acpi-20050408-2.6.13-rc1.diff.gz
> > >
> > > Please give it a go, and if nothing explodes I'll git it to Linus
> > for
> > > 2.6.13-rc2 and we'll move onto the batch that is waiting in line
> > behind
> > > this one:-)
> > 
> > 
> > >  drivers/pci/pci.c                                 |   18
> > 
> > Does it still do ugly stuff with placing pci_power_t into u32?
> 
> pci/pci.c doesn't manipulate pci_power_t -- just passes it along.
> 
> drivers/pci/pci-acpi.c uses it as an index to convert it into
> and acpi_state:

Aha, so it is better than I remembered.

> +static int acpi_pci_set_power_state(struct pci_dev *dev, pci_power_t
> state)
> +{
> +       acpi_handle handle = DEVICE_ACPI_HANDLE(&dev->dev);
> +       static int state_conv[] = {
> +               [0] = 0,
> +               [1] = 1,
> +               [2] = 2,
> +               [3] = 3,
> +               [4] = 3
> +       };
> +       int acpi_state = state_conv[(int __force) state];

Could we get rid of the __force, and use PCI_* constants above?

Also we probably need acpi_power_t, or great confusion is almost
guaranteed.

> +       if (!handle)
> +               return -ENODEV;
> +       return acpi_bus_set_power(handle, acpi_state);
> +}
							Pavel

-- 
teflon -- maybe it is a trademark, but it should not be.


-------------------------------------------------------
SF.Net email is sponsored by: Discover Easy Linux Migration Strategies
from IBM. Find simple to follow Roadmaps, straightforward articles,
informative Webcasts and more! Get everything you need to get up to
speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click