On Fri, Jun 14, 2013 at 3:48 PM, Matthew Garrett
wrote:
> On Fri, 2013-06-14 at 15:40 -0700, Yinghai Lu wrote:
>> On Fri, Jun 14, 2013 at 3:27 PM, Matthew Garrett
>> wrote:
>> > On Fri, 2013-06-14 at 15:17 -0700, Yinghai Lu wrote:
>> >
>> >> after those two patches, it aspm_disabled is set, via _
On Fri, 2013-06-14 at 15:40 -0700, Yinghai Lu wrote:
> On Fri, Jun 14, 2013 at 3:27 PM, Matthew Garrett
> wrote:
> > On Fri, 2013-06-14 at 15:17 -0700, Yinghai Lu wrote:
> >
> >> after those two patches, it aspm_disabled is set, via _osc early,
> >> pre-1.1 devices aspm register will be touched ev
On Fri, Jun 14, 2013 at 3:27 PM, Matthew Garrett
wrote:
> On Fri, 2013-06-14 at 15:17 -0700, Yinghai Lu wrote:
>
>> after those two patches, it aspm_disabled is set, via _osc early,
>> pre-1.1 devices aspm register will be touched even aspm_force is not
>> specified.
>
> I don't follow. We were p
On Fri, 2013-06-14 at 15:17 -0700, Yinghai Lu wrote:
> after those two patches, it aspm_disabled is set, via _osc early,
> pre-1.1 devices aspm register will be touched even aspm_force is not
> specified.
I don't follow. We were previously automatically disabling ASPM on
pre-1.1 devices even if
On Fri, Jun 14, 2013 at 2:26 PM, Bjorn Helgaas wrote:
> [+cc Maxim, Jussi]
>
> Yeah, this is a huge mess. It makes my head hurt. I don't think it's
> reasonable to add more flags because that will make my head hurt even
> more.
>
> If I understand correctly, on Roman's system (the Acer Aspire On
On Fri, 2013-06-14 at 15:26 -0600, Bjorn Helgaas wrote:
> I did find the Atheros Windows driver for the AOA150 on the Acer
> website [3], and the .INF file has several interesting mentions of
> ASPM, but I don't know what they mean.
They're not the standard functions, so it's possible that the Wi
[+cc Maxim, Jussi]
On Fri, Jun 14, 2013 at 12:26 PM, Yinghai Lu wrote:
> On Fri, Jun 14, 2013 at 10:44 AM, Bjorn Helgaas wrote:
>> On Fri, Jun 14, 2013 at 10:57 AM, Yinghai Lu wrote:
>>> On Fri, Jun 14, 2013 at 9:33 AM, Bjorn Helgaas wrote:
On Fri, Jun 14, 2013 at 10:17 AM, Yinghai Lu wr
On Fri, Jun 14, 2013 at 10:44 AM, Bjorn Helgaas wrote:
> On Fri, Jun 14, 2013 at 10:57 AM, Yinghai Lu wrote:
>> On Fri, Jun 14, 2013 at 9:33 AM, Bjorn Helgaas wrote:
>>> On Fri, Jun 14, 2013 at 10:17 AM, Yinghai Lu wrote:
>>>
>>> Can you please refer to specific function names? I can't read yo
On Fri, Jun 14, 2013 at 10:57 AM, Yinghai Lu wrote:
> On Fri, Jun 14, 2013 at 9:33 AM, Bjorn Helgaas wrote:
>> On Fri, Jun 14, 2013 at 10:17 AM, Yinghai Lu wrote:
>>
>> Can you please refer to specific function names? I can't read your mind.
>>
>> You might be referring to quirk_disable_aspm_l0
On Fri, Jun 14, 2013 at 9:33 AM, Bjorn Helgaas wrote:
> On Fri, Jun 14, 2013 at 10:17 AM, Yinghai Lu wrote:
>
> Can you please refer to specific function names? I can't read your mind.
>
> You might be referring to quirk_disable_aspm_l0s(). This is a
> pci_fixup_final quirk that calls pci_disab
On Fri, Jun 14, 2013 at 10:17 AM, Yinghai Lu wrote:
> On Fri, Jun 14, 2013 at 7:11 AM, Bjorn Helgaas wrote:
>> Here are some of my notes from trying to sort this out, in chronological
>> order:
>>
>> 29594404 v3.7
>> Bus scanned before requesting _OSC control
>> pre-1.1 ath5k has
On Fri, Jun 14, 2013 at 7:11 AM, Bjorn Helgaas wrote:
> Here are some of my notes from trying to sort this out, in chronological
> order:
>
> 29594404 v3.7
> Bus scanned before requesting _OSC control
> pre-1.1 ath5k has ASPM disabled (works fine)
>
> 8c33f51d "request _OSC con
On Wed, Jun 12, 2013 at 12:41:42PM -0700, Yinghai Lu wrote:
> On Wed, Jun 12, 2013 at 10:05 AM, Bjorn Helgaas wrote:
> >> current code from acpi_pci_root_add we have
> >> 1. pci_acpi_scan_root
> >> ==> pci devices enumeration and bus scanning.
> >> ==> pci_alloc_child_bus
>
On Wed, Jun 12, 2013 at 10:11 PM, Jiang Liu (Gerry)
wrote:
> Hi Bjorn,
> I'm working on several acpiphp related bugfixes, and feel some
> are materials for 3.10 too. Actually we have identified four bugs
> related to dock station support on Sony VAIO VPCZ23A4R laptop.
> I will try to send out
On Wednesday, June 12, 2013 10:47:08 PM Yinghai Lu wrote:
> On Wed, Jun 12, 2013 at 8:50 PM, Bjorn Helgaas wrote:
> > On Wed, Jun 12, 2013 at 1:41 PM, Yinghai Lu wrote:
> >
> > I think you're saying that in systems that support both acpiphp and
> > pciehp, we should be using pciehp, but we curren
On Wed, Jun 12, 2013 at 8:50 PM, Bjorn Helgaas wrote:
> On Wed, Jun 12, 2013 at 1:41 PM, Yinghai Lu wrote:
>
> I think you're saying that in systems that support both acpiphp and
> pciehp, we should be using pciehp, but we currently use acpiphp. If
> so, that's certainly a bug. How serious is i
Hi Bjorn,
I'm working on several acpiphp related bugfixes, and feel some
are materials for 3.10 too. Actually we have identified four bugs
related to dock station support on Sony VAIO VPCZ23A4R laptop.
I will try to send out patchset to address these bugs tonight.
Seems we really need to rethi
On Wed, Jun 12, 2013 at 1:41 PM, Yinghai Lu wrote:
> On Wed, Jun 12, 2013 at 10:05 AM, Bjorn Helgaas wrote:
>>> current code from acpi_pci_root_add we have
>>> 1. pci_acpi_scan_root
>>> ==> pci devices enumeration and bus scanning.
>>> ==> pci_alloc_child_bus
>>>
On Wed, Jun 12, 2013 at 10:05 AM, Bjorn Helgaas wrote:
>> current code from acpi_pci_root_add we have
>> 1. pci_acpi_scan_root
>> ==> pci devices enumeration and bus scanning.
>> ==> pci_alloc_child_bus
>> ==> pcibios_add_bus
>> ==> acp
On Wed, Jun 12, 2013 at 12:20 AM, Yinghai Lu wrote:
> On Tue, Apr 2, 2013 at 1:10 PM, Bjorn Helgaas wrote:
>> On Mon, Apr 1, 2013 at 6:03 PM, Yinghai Lu wrote:
commit 96e5d01cd536458435ef0678d9fa3dc542afb41f
Author: Bjorn Helgaas
Date: Mon Apr 1 15:47:39 2013 -0600
On Tue, Apr 2, 2013 at 1:10 PM, Bjorn Helgaas wrote:
> On Mon, Apr 1, 2013 at 6:03 PM, Yinghai Lu wrote:
>>> commit 96e5d01cd536458435ef0678d9fa3dc542afb41f
>>> Author: Bjorn Helgaas
>>> Date: Mon Apr 1 15:47:39 2013 -0600
>>>
>>> Revert "PCI/ACPI: Request _OSC control before scanning PCI
On Mon, Apr 1, 2013 at 6:03 PM, Yinghai Lu wrote:
> On Mon, Apr 1, 2013 at 4:52 PM, Bjorn Helgaas wrote:
>> On Fri, Mar 29, 2013 at 11:04:48AM -0700, Yinghai Lu wrote:
>>> attatched -v3 again
>>>
>>> > Please check attached -v3.
>>
>> It's getting late in the v3.9 cycle already, and while your v3
On Mon, Apr 1, 2013 at 4:52 PM, Bjorn Helgaas wrote:
> On Fri, Mar 29, 2013 at 11:04:48AM -0700, Yinghai Lu wrote:
>> attatched -v3 again
>>
>> > Please check attached -v3.
>
> It's getting late in the v3.9 cycle already, and while your v3 patch
> probably fixes Roman's problem, I can't convince m
On Monday, April 01, 2013 05:52:56 PM Bjorn Helgaas wrote:
> On Fri, Mar 29, 2013 at 11:04:48AM -0700, Yinghai Lu wrote:
> > attatched -v3 again
> >
> > On Fri, Mar 29, 2013 at 11:02 AM, Yinghai Lu wrote:
> > > On Fri, Mar 29, 2013 at 5:24 AM, Bjorn Helgaas
> > > wrote:
> > >>
> > >> Half of yo
On Fri, Mar 29, 2013 at 11:04:48AM -0700, Yinghai Lu wrote:
> attatched -v3 again
>
> On Fri, Mar 29, 2013 at 11:02 AM, Yinghai Lu wrote:
> > On Fri, Mar 29, 2013 at 5:24 AM, Bjorn Helgaas wrote:
> >>
> >> Half of your v1 patch (removing the pcie_aspm_sanity_check() test)
> >> *might* be the rig
On Fri, Mar 29, 2013 at 5:22 AM, Bjorn Helgaas wrote:
> [+cc Matthew]
> [+cc e1000-de...@lists.sourceforge.net for suspected 82575/82598 regression]
>
> I think this regression has nothing to do with pci_disable_link_state().
>
> ...
>
> There are also PCI_FIXUP_FINAL quirks for 82575 and 82598 NI
attatched -v3 again
On Fri, Mar 29, 2013 at 11:02 AM, Yinghai Lu wrote:
> On Fri, Mar 29, 2013 at 5:24 AM, Bjorn Helgaas wrote:
>>
>> Half of your v1 patch (removing the pcie_aspm_sanity_check() test)
>> *might* be the right thing, but only if you can clearly explain why
>> that will not reintro
On Fri, Mar 29, 2013 at 5:24 AM, Bjorn Helgaas wrote:
>
> Half of your v1 patch (removing the pcie_aspm_sanity_check() test)
> *might* be the right thing, but only if you can clearly explain why
> that will not reintroduce the bug Matthew fixed with c9651e70.
>
> I think we also need to fix the PC
the changelog, and it's a huge waste of time
>> > >> to everybody who tries to understand the history later. That's why I
>> > >> think it's worth spending some time to make a good patch now.
>> > >
>> > > Ple
rt of the changelog, and it's a huge waste of time
> >> to everybody who tries to understand the history later. That's why I
> >> think it's worth spending some time to make a good patch now.
> >
> > Please check if attached patch is doing what
patch for Roman
On Thu, Mar 28, 2013 at 1:24 PM, Yinghai Lu wrote:
> resending with adding To Roman.
>
> On Thu, Mar 28, 2013 at 5:46 AM, Bjorn Helgaas wrote:
>> This patch might be *safe*, but it (and the changelog) are completely
>> unintelligible.
>>
>> The problem with applying an unintellig
resending with adding To Roman.
On Thu, Mar 28, 2013 at 5:46 AM, Bjorn Helgaas wrote:
> This patch might be *safe*, but it (and the changelog) are completely
> unintelligible.
>
> The problem with applying an unintelligible stop-gap patch is that it
> becomes forever part of the changelog, and it
On Thu, Mar 28, 2013 at 5:46 AM, Bjorn Helgaas wrote:
> This patch might be *safe*, but it (and the changelog) are completely
> unintelligible.
>
> The problem with applying an unintelligible stop-gap patch is that it
> becomes forever part of the changelog, and it's a huge waste of time
> to eve
On Thu, Mar 28, 2013 at 1:41 AM, Yinghai Lu wrote:
> On Wed, Mar 27, 2013 at 3:56 PM, Bjorn Helgaas wrote:
>>
>> Why can't we set all the ASPM flags *first*, before calling
>> pci_acpi_scan_root()? That way we could just do the correct ASPM
>> setup as we discover devices during enumeration, rat
On Wed, Mar 27, 2013 at 3:56 PM, Bjorn Helgaas wrote:
>
> Why can't we set all the ASPM flags *first*, before calling
> pci_acpi_scan_root()? That way we could just do the correct ASPM
> setup as we discover devices during enumeration, rather than trying to
> fix things up afterwards. I suspect
On Mon, Mar 18, 2013 at 11:37 AM, Yinghai Lu wrote:
> Roman reported ath5k does not work anymore on 3.8.
> Bisected to
> | commit 8c33f51df406e1a1f7fa4e9b244845b7ebd61fa6
> | Author: Taku Izumi
> | Date: Tue Oct 30 15:27:13 2012 +0900
> |
> |PCI/ACPI: Request _OSC control before scanning PC
Roman reported ath5k does not work anymore on 3.8.
Bisected to
| commit 8c33f51df406e1a1f7fa4e9b244845b7ebd61fa6
| Author: Taku Izumi
| Date: Tue Oct 30 15:27:13 2012 +0900
|
|PCI/ACPI: Request _OSC control before scanning PCI root bus
|
|This patch moves up the code block to request _OS
37 matches
Mail list logo
