From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-qg0-f44.google.com ([209.85.192.44]:63234 "EHLO mail-qg0-f44.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753189AbaIJUhl (ORCPT ); Wed, 10 Sep 2014 16:37:41 -0400 Received: by mail-qg0-f44.google.com with SMTP id f51so7826046qge.31 for ; Wed, 10 Sep 2014 13:37:40 -0700 (PDT) MIME-Version: 1.0 In-Reply-To: References: <1409303414-5196-1-git-send-email-david.henningsson@canonical.com> <540091D1.1040902@canonical.com> From: Bjorn Helgaas Date: Wed, 10 Sep 2014 14:37:20 -0600 Message-ID: Subject: Re: [PATCH] Add pci=assign-busses quirk to Dell Latitude D505 To: Andreas Noever Cc: David Henningsson , "linux-pci@vger.kernel.org" Content-Type: text/plain; charset=UTF-8 Sender: linux-pci-owner@vger.kernel.org List-ID: On Wed, Sep 10, 2014 at 1:50 PM, Andreas Noever wrote: > On Wed, Sep 10, 2014 at 8:08 PM, Bjorn Helgaas wrote: >> [+cc Andreas] >> >> On Fri, Aug 29, 2014 at 11:36 AM, Bjorn Helgaas wrote: >>> On Fri, Aug 29, 2014 at 8:44 AM, David Henningsson >>> wrote: >>>> >>>> >>>> On 2014-08-29 16:22, Bjorn Helgaas wrote: >>>>> >>>>> On Fri, Aug 29, 2014 at 3:10 AM, David Henningsson >>>>> wrote: >>>>>> >>>>>> Under a 3.16 based kernel (Ubuntu 3.16.0-031600-lowlatency), >>>>>> CardBus is not working unless pci=assign-buses is added to the >>>>>> kernel boot parameters. >>>>>> >>>>>> Signed-off-by: David Henningsson >>>>>> --- >>>>>> arch/x86/pci/common.c | 8 ++++++++ >>>>>> 1 file changed, 8 insertions(+) >>>>>> >>>>>> It was working OOTB on a 3.2 based kernel (Ubuntu 3.2.0-67-generic), >>>>>> and I have not thoroughly bisected what made it stop working. >>>>>> Still I'm suggesting to just a quirk to make it work regardless of >>>>>> kernel - it's a ~8 year old laptop, so being a bit lazy about it is >>>>>> probably okay, I hope. :-) >>>>> >>>>> >>>>> Please open a bugzilla and attach complete "lspci -vv" output and >>>>> dmesg logs from the working 3.2 kernel and a non-working current >>>>> kernel. >>>>> >>>>> The quirk might be OK, but it would be better if we could make a >>>>> generic fix that would work on more machines than just this one. >>>> >>>> >>>> All right, you can now find the requested information in this bug: >>>> >>>> https://bugzilla.kernel.org/show_bug.cgi?id=83441 >>> >>> Thanks very much. >>> >>> I'm going to resist adding a quirk as long as I can, because quirks >>> tend to paper over issues on individual systems without actually >>> fixing the underlying problem. Unfortunately, I'm swamped at the >>> moment and won't be able to work on this for a while. It would be >>> ideal if we could bisect this and pinpoint where the problem started. >>> Bisecting changes to drivers/pci would be sufficient. >>> >>>>>> Extract from dmidecode: >>>>>> >>>>>> Handle 0x0100, DMI type 1, 25 bytes >>>>>> System Information >>>>>> Manufacturer: Dell Inc. >>>>>> Product Name: Latitude D505 >>>>>> >>>>>> diff --git a/arch/x86/pci/common.c b/arch/x86/pci/common.c >>>>>> index 059a76c..1849e39 100644 >>>>>> --- a/arch/x86/pci/common.c >>>>>> +++ b/arch/x86/pci/common.c >>>>>> @@ -262,6 +262,14 @@ static const struct dmi_system_id >>>>>> pciprobe_dmi_table[] = { >>>>>> DMI_MATCH(DMI_PRODUCT_NAME, "SX20S"), >>>>>> }, >>>>>> }, >>>>>> + { >>>>>> + .callback = assign_all_busses, >>>>>> + .ident = "Dell Latitude D505 Laptop", >>>>>> + .matches = { >>>>>> + DMI_MATCH(DMI_SYS_VENDOR, "Dell Inc."), >>>>>> + DMI_MATCH(DMI_PRODUCT_NAME, "Latitude D505"), >>>>>> + }, >>>>>> + }, >>>>>> #endif /* __i386__ */ >>>>>> { >>>>>> .callback = set_bf_sort, >> >> v3.16 fails with: >> >> pci 0000:01:01.0: can't allocate child bus 01 from [bus 01] >> >> which Andreas added with fc1b253141b3 ("PCI: Don't scan random busses >> in pci_scan_bridge()"). But I don't understand that code well enough >> to know whether this commit is actually the cause of the problem. > Looks like my commit is at fault. The parent bridge 00:1e has > secondary=subordinate=1 assigned by the BIOS. My commit then refuses > to assign a secondary bus to 01:01 because the parent's bus window has > been exhausted. > > Before fc1b253141b3, we ignored the parent's bus window and simply > created a new bus #2. If bus #2 had already existed elsewhere then we > would have rescanned it, which was the (potential) problem patch was > trying to address. Much later yenta_socket fixes the parent bridge. > See http://lxr.free-electrons.com/source/drivers/pcmcia/yenta_socket.c#L1077 > > Could move the yenta quirk to pci_scan_bridge or trigger a rescan from > the yenta driver after the fixup is done? I vote for somehow integrating yenta_fixup_parent_bridge() into pci_scan_bridge(). The code in yenta_fixup_parent_bridge() looks pretty generic; I don't see anything that seems yenta-specific. So it'd be nice to have the fixup in the generic code. Bjorn