On Wed, Sep 10, 2014 at 1:50 PM, Andreas Noever <andreas.noever@xxxxxxxxx> wrote: > On Wed, Sep 10, 2014 at 8:08 PM, Bjorn Helgaas <bhelgaas@xxxxxxxxxx> wrote: >> [+cc Andreas] >> >> On Fri, Aug 29, 2014 at 11:36 AM, Bjorn Helgaas <bhelgaas@xxxxxxxxxx> wrote: >>> On Fri, Aug 29, 2014 at 8:44 AM, David Henningsson >>> <david.henningsson@xxxxxxxxxxxxx> wrote: >>>> >>>> >>>> On 2014-08-29 16:22, Bjorn Helgaas wrote: >>>>> >>>>> On Fri, Aug 29, 2014 at 3:10 AM, David Henningsson >>>>> <david.henningsson@xxxxxxxxxxxxx> 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 <david.henningsson@xxxxxxxxxxxxx> >>>>>> --- >>>>>> 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 -- To unsubscribe from this list: send the line "unsubscribe linux-pci" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html