public inbox for linux-acpi@vger.kernel.org
 help / color / mirror / Atom feed
From: David Brownell <david-b@pacbell.net>
To: Bjorn Helgaas <bjorn.helgaas@hp.com>
Cc: linux-pm@lists.linux-foundation.org, linux-acpi@vger.kernel.org
Subject: Re: [patch 2.6.21-git] pci_choose_state() works, does ACPI magic
Date: Mon, 21 May 2007 10:55:54 -0700	[thread overview]
Message-ID: <200705211055.55090.david-b@pacbell.net> (raw)
In-Reply-To: <200705211134.36578.bjorn.helgaas@hp.com>

On Monday 21 May 2007, Bjorn Helgaas wrote:
> On Wednesday 09 May 2007 01:22:29 pm David Brownell wrote:
> >  static int acpi_pci_set_power_state(struct pci_dev *dev, pci_power_t state)
> >  {
> > ...
> > +	switch (state) {
> > +	case PCI_D0:
> > +	case PCI_D1:
> > +	case PCI_D2:
> > +	case PCI_D3hot:
> > +	case PCI_D3cold:
> > +		return acpi_bus_set_power(handle, state_conv[state]);
> > +	}
> > +
> > +	return -EINVAL;

... i.e. a cleaned-up version of the existing code ...

> >  }
> 
> Did you account for the fact that PCI works on a per-function basis,
> but ACPI power management works on a per-slot basis?

This is a per-function method though.  The ACPI code should
be able to keep that straight ... simple refcounting on the
power resources would suffice, assuming it goes the route of
managing power resources rather than just invoking the methods
associated with each device.


> We had a bug[1] a while back where e1000 would suspend a device and
> call pci_power_state(), which used ACPI to turn off the slot.  The
> only problem was that this was a dual-port card and the other port
> was still active when the lights went out.

Sounds like an ACPI bug to me:  not properly tracking the users
of a given PCI power resource.  I can't see that bug without
getting a Novell login -- you might want post the report rather
than its URL.

 
> Maybe you deal with this already; it just wasn't obvious to me from
> a quick glance through your patch.

Didn't touch it ... pre-existing bugs shouldn't have been affected.

The only behavioral change in that particular method should have been
safer handling of an out-of-range parameter.

- Dave
 

> Bjorn
> 
> 
> [1] https://bugzilla.novell.com/show_bug.cgi?id=162320
> 



  reply	other threads:[~2007-05-21 17:56 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-05-09 19:22 [patch 2.6.21-git] pci_choose_state() works, does ACPI magic David Brownell
2007-05-10 20:23 ` Rafael J. Wysocki
2007-05-10 20:35   ` David Brownell
2007-05-14  9:39 ` [linux-pm] " Pavel Machek
2007-05-14 15:01   ` David Brownell
2007-05-21 17:34 ` Bjorn Helgaas
2007-05-21 17:55   ` David Brownell [this message]
2007-05-21 18:21     ` Bjorn Helgaas
2007-05-21 18:58       ` David Brownell

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=200705211055.55090.david-b@pacbell.net \
    --to=david-b@pacbell.net \
    --cc=bjorn.helgaas@hp.com \
    --cc=linux-acpi@vger.kernel.org \
    --cc=linux-pm@lists.linux-foundation.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox