headers
Shaohua Li | 1 Nov 2007 03:50
Picon
Favicon

Re: [PATCH]libata-acpi: add ACPI _PSx method

On Wed, 2007-10-31 at 14:26 +0100, Rafael J. Wysocki wrote:
> On Wednesday, 31 October 2007 03:27, Len Brown wrote:
> > It would be interseting if any of the folks having power consumption
> > problems when suspended see an improvement with this patch.
> > 
> > Are there plans to refresh this patch and get it upstream?
> > 
> > Acked-by: Len Brown <len.brown <at> intel.com>
> 
> There was a discussion regarding this patch, IIRC, and it was argued that
> _PSx are only applicable to IDE/PATA devices.
> 
> I wonder if this has been addressed.
Sure, there is a check for PATA. I refreshed the patch to against latest
git tree.

ACPI spec (ver 3.0a, p289) requires IDE power on/off executes ACPI _PSx
methods. As recently most PATA drivers use libata, this patch adds _PSx
method support in libata. ACPI spec doesn't mention if SATA requires the
same _PSx method.

Signed-off-by: Shaohua Li <shaohua.li <at> intel.com>
Acked-by: Len Brown <len.brown <at> intel.com>
---
 drivers/ata/libata-acpi.c |   33 +++++++++++++++++++++++++++++++++
 drivers/ata/libata-eh.c   |    3 +++
 drivers/ata/libata.h      |    2 ++
 3 files changed, 38 insertions(+)

Index: linux/drivers/ata/libata-acpi.c
(Continue reading)

Permalink | Reply | 12 comments |
headers
Perry G | 1 Nov 2007 06:05
Picon

dmidecode

Thank you.
Attachment (dmidecode_toshibaA135-s2276): application/octet-stream, 7591 bytes
Permalink | Reply | 1 comment |
headers
Andrew Morton | 1 Nov 2007 09:32

Re: [PATCH] x86: check boundary in count/setup_resource called by get_current_resources

On Thu, 01 Nov 2007 01:20:29 -0700 Yinghai Lu <Yinghai.Lu <at> Sun.COM> wrote:

> [PATCH] x86: check boundary in count/setup_resource called by get_current_resources
> 
> need to check info->res_num less than PCI_BUS_NUM_RESOURCES, so
> info->bus->resource[info->res_num] = res will not beyond of bus resource array
> when acpi resutrn too many resource entries.
> 

Isn't this a bit of a problem?  It sounds like PCI_BUS_NUM_RESOURCES is to
small for that system?  If so, some sort of dynamic allocation might be
needed.

> 
> Index: linux-2.6/arch/x86/pci/acpi.c
> ===================================================================
> --- linux-2.6.orig/arch/x86/pci/acpi.c
> +++ linux-2.6/arch/x86/pci/acpi.c
>  <at>  <at>  -77,9 +77,13  <at>  <at>  count_resource(struct acpi_resource *acp
>  	struct acpi_resource_address64 addr;
>  	acpi_status status;
>  
> +	if (info->res_num >= PCI_BUS_NUM_RESOURCES)
> +		return AE_OK;
> +
>  	status = resource_to_addr(acpi_res, &addr);
>  	if (ACPI_SUCCESS(status))
>  		info->res_num++;
> +
>  	return AE_OK;
(Continue reading)

Permalink | Reply | 6 comments |
headers
Alan Cox | 1 Nov 2007 11:04
Picon

Re: [PATCH]libata-acpi: add ACPI _PSx method


> +	max_devices = ata_link_max_devices(&ap->link);
> +
> +	for (i = 0; i < max_devices; ++i) {
> +		struct ata_device *dev = &ap->link.device[i];

Better to use:

	ata_link_for_each_dev(dev, &ap->link) {		

> +
> +		if (dev->acpi_handle)
> +			acpi_bus_set_power(dev->acpi_handle,
> +				state.event == PM_EVENT_ON ?
> +				ACPI_STATE_D0: ACPI_STATE_D3);
> +	}

Also should you not check ata_dev_enabled(dev) ?

Alan
-
To unsubscribe from this list: send the line "unsubscribe linux-acpi" in
the body of a message to majordomo <at> vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Permalink | Reply | 10 comments |
headers
Brown, Len | 1 Nov 2007 16:50
Picon
Favicon
Gravatar

ACPI home page updates

Yu-Ling,

Now that the new Linux/ACPI project home page is up at
http://www.lesswatts.org/projects/acpi/, and MAINTAINERS
points to it, it is time to update the legacy home page.

The principle of "two copies of the truth" tells us that
we should delete the redundant info from the old page
and refer to the (properly maintained) new one.

However, we should retain (and properly label) the
content on the old page that will continue to live there.

http://acpi.sourceforge.net/index.html

replace all content with this text:

"The Linux/ACPI project home page has moved to
http://www.lesswatts.org/projects/acpi/.
This legacy home page contains only legacy information
that is useful for historical reference."

maybe "Documentation" should be re-named "Legacy Documentation"...

http://acpi.sourceforge.net/documentation/index.html
Warn again that this is legacy documentation.

http://acpi.sourceforge.net/documentation/alarm.html
retain, but warn that /proc/acpi is being replaced
by interfaces in /sys and new software should not
(Continue reading)

Permalink | Reply | 5 comments |
headers
Bjorn Helgaas | 1 Nov 2007 18:13
Picon
Favicon

PNP: request ioport and iomem resources used by active devices

[1] Posting as RFC (one positive response): http://lkml.org/lkml/2007/10/29/412
[2] This should go after rtc-fallback-to-requesting-only-the-ports-we-actually-use.patch
    because the RTC driver was one that requested more resources than it needs and fails
    if PNP reports a smaller region.

Reserve resources used by active PNP devices to prevent those resources
from being assigned to other devices.

This can be turned off with the "pnp=no_reservations" flag.  If you need to
use it, please report it, because it indicates a potential problem, like a
driver that requests more resources than it needs.

This is similar to request_standard_resources().  That function requests
resources for a compiled-in list of standard PC devices such as DMA
controllers, PICs, timers, and keyboard, and marks them "busy."  This
patch requests resources for devices that are actually present but does
not mark them "busy."

Sometimes the built-in standard resources are larger than what PNP reports,
or they combine things that PNP reports separately, which makes things look
a little strange, e.g.,

    0000-001f : dma1		<-- built-in resource includes 2 controllers
      0000-000f : 00:02		<-- PNP reports only one DMA controller
    0020-0021 : pic1
    002e-002f : 00:06
    0040-0043 : timer0
    0050-0053 : timer1
    0060-006f : keyboard	<-- built-in resource groups several things
      0060-0060 : 00:04		<-- PNP reports 8042 controller data register
(Continue reading)

Permalink | Reply | 0 comments |
headers
Yinghai Lu | 1 Nov 2007 19:06
Picon

Re: [PATCH] x86: check boundary in count/setup_resource called by get_current_resources

Andrew Morton wrote:
> On Thu, 01 Nov 2007 01:20:29 -0700 Yinghai Lu <Yinghai.Lu <at> Sun.COM> wrote:
> 
>> [PATCH] x86: check boundary in count/setup_resource called by get_current_resources
>>
>> need to check info->res_num less than PCI_BUS_NUM_RESOURCES, so
>> info->bus->resource[info->res_num] = res will not beyond of bus resource array
>> when acpi resutrn too many resource entries.
>>
> 
> Isn't this a bit of a problem?  It sounds like PCI_BUS_NUM_RESOURCES is to
> small for that system?  If so, some sort of dynamic allocation might be
> needed.

sound reasonable...
i have one local patch for amd64 that will get resources from pci conf. and it will use all 8 slots for bus 0.
and transparent bus under it only can copy 5 of them.

YH
Permalink | Reply | 2 comments |
headers
Andrey Borzenkov | 1 Nov 2007 19:44
Picon

Re: [2.6.24-rc1 regression] AC adapter state does not change after resume

On Wednesday 31 October 2007, Alexey Starikovskiy wrote:
> Andrey Borzenkov wrote:
> > On Wednesday 31 October 2007, Alexey Starikovskiy wrote:
> >> Andrey Borzenkov wrote:
> >>> I suspect new ACPI AC adapter code but have to add some printk's to be
> >>> sure.
> >>>
> >>> To reproduce - plug in AC cord, suspend, unplug, resume - kpowersave
> >>> and sysfs still show AC adapter online. Or other way round.
> >>>
> >>> -andrey
> >>
> >> Please check if this patch helps.
> >
> > It does not even compile :)
> >
> > On serious note (after adding forward declaration) - patch half works. It
> > does make "online" return true value (which confirms that underlying ACPI
> > works correctly) but HAL still does not notice it.
> >
> > The problem is, with power_supply interface HAL does not use polling, it
> > relies on CHANGE event. This event is apparently never generated if AC
> > adapter state changes on resume. So the obvious fix is to compare AC
> > state before and after suspend in ->resume function and generate
> > synthetic CHANGE event if something has changed.
> >
> > This will also make superfluous polling redundant.
>
> Ok, here. This one compiles :)
>
(Continue reading)

Permalink | Reply | 0 comments |
headers
Gary Hade | 1 Nov 2007 19:45
Picon
Favicon

Re: [PATCH] x86: check boundary in count/setup_resource called by get_current_resources

On Thu, Nov 01, 2007 at 01:32:39AM -0700, Andrew Morton wrote:
> On Thu, 01 Nov 2007 01:20:29 -0700 Yinghai Lu <Yinghai.Lu <at> Sun.COM> wrote:
> 
> > [PATCH] x86: check boundary in count/setup_resource called by get_current_resources
> > 
> > need to check info->res_num less than PCI_BUS_NUM_RESOURCES, so
> > info->bus->resource[info->res_num] = res will not beyond of bus resource array
> > when acpi resutrn too many resource entries.
> > 
> 
> Isn't this a bit of a problem?  It sounds like PCI_BUS_NUM_RESOURCES is to
> small for that system?  If so, some sort of dynamic allocation might be
> needed.

I should have considered the possible resource array overrun
when I created these functions.  I had assumed (apparently
incorrectly) that the old PCI_BUS_NUM_RESOURCES value of 4
was based on a spec defined limit on the maximum number of 
resources that _CRS can return.

I recently noticed the potential overrun myself while backporting
the code to kernel source where PCI_BUS_NUM_RESOURCES was initially
defined as 4.  This happened on a system where the _CRS associated
with one of the root bridges returned 5 resources with the 5th causing
a write beyond the end of the array.  Increasing PCI_BUS_NUM_RESOURCES
to the current value of 8 eliminated the overrun that I experienced 
but after discovering that there is apparently no limit on the
number of resources that _CRS can return I had intended to post
a change similar to what Yinghai Lu is proposing.
(Continue reading)

Permalink | Reply | 0 comments |
headers
Gary Hade | 1 Nov 2007 21:10
Picon
Favicon

Re: [PATCH] x86: check boundary in count/setup_resource called by get_current_resources

On Thu, Nov 01, 2007 at 11:06:18AM -0700, Yinghai Lu wrote:
> Andrew Morton wrote:
> >On Thu, 01 Nov 2007 01:20:29 -0700 Yinghai Lu <Yinghai.Lu <at> Sun.COM> wrote:
> >
> >>[PATCH] x86: check boundary in count/setup_resource called by 
> >>get_current_resources
> >>
> >>need to check info->res_num less than PCI_BUS_NUM_RESOURCES, so
> >>info->bus->resource[info->res_num] = res will not beyond of bus resource 
> >>array
> >>when acpi resutrn too many resource entries.
> >>
> >
> >Isn't this a bit of a problem?  It sounds like PCI_BUS_NUM_RESOURCES is to
> >small for that system?  If so, some sort of dynamic allocation might be
> >needed.
> 
> sound reasonable...
> i have one local patch for amd64 that will get resources from pci conf. and 
> it will use all 8 slots for bus 0.
> and transparent bus under it only can copy 5 of them.

Yea, with the current fixed size pci_bus resource array
I believe you would need to increase PCI_BUS_NUM_RESOURCES
from 8 to 11 for the transparent bridge child bus to get
all 8 _CRS returned resources.

Gary

--

--
(Continue reading)

Permalink | Reply | 0 comments |

Gmane