lkml.org 
[lkml]   [2008]   [Jul]   [25]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: post 2.6.26 requires pciehp_slot_with_bus
    * Matthew Wilcox <matthew@wil.cx>:
    > On Fri, Jul 25, 2008 at 01:29:16AM +0200, Pierre Ossman wrote:
    > > On Thu, 24 Jul 2008 17:08:27 -0600
    > > Alex Chiang <achiang@hp.com> wrote:
    > >
    > > > Sorry for one more round-trip, but could you turn on debugging
    > > > for pciehp as well?
    > > >
    > >
    > > Same thing, with debugging:
    >
    > I have a laptop with a similar problem (though I don't have pciehp
    > enabled, so I didn't notice it). Obviously, we need to fix this.
    >
    > There is no question in my mind that firmware has programmed the slot
    > numbers incorrectly. Here's the evidence from lspci -vvv:
    >
    > 00:1c.0 PCI bridge: Intel Corporation 82801H (ICH8 Family) PCI Express Port 1 (rev 03)
    > Capabilities: [40] Express (v1) Root Port (Slot+), MSI 00
    > SltCap: AttnBtn- PwrCtrl- MRL- AttnInd- PwrInd- HotPlug+ Surpise+
    > Slot # 2, PowerLimit 6.500000; Interlock- NoCompl-
    > 00:1c.4 PCI bridge: Intel Corporation 82801H (ICH8 Family) PCI Express Port 5 (rev 03)
    > Capabilities: [40] Express (v1) Root Port (Slot+), MSI 00
    > SltCap: AttnBtn- PwrCtrl- MRL- AttnInd- PwrInd- HotPlug+ Surpise+
    > Slot # 2, PowerLimit 6.500000; Interlock- NoCompl-
    >
    > I don't think anyone can credibly argue that this is correct. They're
    > both PCIe devices, they're both both indicating that they have a slot
    > (maybe if I get my screwdriver out, I can see if there's really a slot
    > ...), they're on the same bus (so I don't know how the with_bus
    > parameter makes any difference).
    >
    > I've always hated that with_bus parameter. I don't like it being a
    > parameter and I don't like the names it produces.
    >
    > Part of the problem is the kobject API. It really hates you trying to
    > register a duplicate name and won't just return -EEXIST and let you try
    > a new name. Instead it prints an ugly warning and dumps stack. See
    > kobject_add_internal() in lib/kobject.c.

    Yeah, I don't really like that part of the kobject API either.

    > So we need a way to find if there's already a slot of this name. I
    > don't see a kobject routine to do that. Maybe we can do it internally
    > to the pci slot code.

    Well, we have this code in pci_hp_register:

    /* Check if we have already registered a slot with the same name. */
    if (get_slot_from_name(slot->name))
    return -EEXIST;

    > Then we need to pick a new name for the kobject if it does collide.
    > My suggestion is that the second time we find an object named "2", we
    > call it "2dup1" (the third time "2dup2", etc.) Other opinions I've
    > seen include "2a", "2b", ... or "2-1", "2-2", ... or "2-brokenfw1",
    > "2-brokenfw2".
    >
    > I'm at OLS this week, so no patch from me.

    It should be pretty easy for pci_hp_register() to fix up the name
    in the event of a collision.

    The hard part is figuring out a convention that we can all agree
    on. ;) I've no strong feelings here, but of the options
    presented, I lean towards "2a", "2b" or "2-1", "2-2".

    /ac



    \
     
     \ /
      Last update: 2008-07-25 06:51    [W:0.024 / U:43.008 seconds]
    ©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site