All of lore.kernel.org
 help / color / mirror / Atom feed
From: Matthew Garrett <mjg59@srcf.ucam.org>
To: Adrian Huang12 <ahuang12@lenovo.com>
Cc: "Rafael J. Wysocki" <rjw@rjwysocki.net>,
	Len Brown <lenb@kernel.org>,
	"linux-acpi@vger.kernel.org" <linux-acpi@vger.kernel.org>
Subject: Re: [PATCH 1/1] ACPI: Fix the incorrect behavior of the disabled ASPM on Haswell CPU
Date: Mon, 10 Mar 2014 16:24:10 +0000	[thread overview]
Message-ID: <20140310162410.GA30930@srcf.ucam.org> (raw)
In-Reply-To: <6366A95FCFBB78419E783DDD020ED2ECB2F179@APMAILMBX03.lenovo.com>

On Mon, Mar 10, 2014 at 04:17:05PM +0000, Adrian Huang12 wrote:
> On Mon, 2014-03-10 at 15:45 +0000, Matthew Garrett wrote:
> > On Mon, Mar 10, 2014 at 09:56:25AM +0000, Adrian Huang12 wrote:
> > > +		if (status == AE_NOT_FOUND &&
> > 
> > Why limit it to not found? 
> 
> Just for the undefined _OSC object in order to follow ACPI5.0.
> Looks like another approach should be implemented to address
> this issue. Is this what you were thinking of: we should never
> evaluate the _OSC object if it is the PCI root bridge?

No, I meant we should never set no_aspm because _OSC fails for any 
reason on a non-PCIe root bridge. But thinking about it, I suspect that 
the whole way we handle _OSC in this case is wrong. If a PCI host bridge 
does implement _OSC then there's still a good chance that it'll refuse 
to grant us control over ASPM, and so we may still end up with failure 
cases.

> > I suspect that we should never be basing our 
> > ASPM policy on the behaviour of PCI (rather than PCIe) bridges.
> 
> Yes, agree since the ASPM functionality is supported only for PCIe.
> Do you agree we should never evaluate the _OSC object if it is
> the PCI root bridge? 

Just skipping _OSC entirely in that case would certainly fix the issue, 
but it doesn't sound like the best fix. I think we need to revisit some 
assumptions in this code.

-- 
Matthew Garrett | mjg59@srcf.ucam.org

  reply	other threads:[~2014-03-10 16:24 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-03-10  9:56 [PATCH 1/1] ACPI: Fix the incorrect behavior of the disabled ASPM on Haswell CPU Adrian Huang12
2014-03-10 15:45 ` Matthew Garrett
2014-03-10 16:17   ` Adrian Huang12
2014-03-10 16:24     ` Matthew Garrett [this message]
2014-03-13 12:22       ` Adrian Huang12

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=20140310162410.GA30930@srcf.ucam.org \
    --to=mjg59@srcf.ucam.org \
    --cc=ahuang12@lenovo.com \
    --cc=lenb@kernel.org \
    --cc=linux-acpi@vger.kernel.org \
    --cc=rjw@rjwysocki.net \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.