lkml.org 
[lkml]   [2008]   [Jul]   [28]   [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
On Thu, Jul 24, 2008 at 10:42:34PM -0600, Alex Chiang wrote:
> * 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.

Then don't register kobjects with the same name of an already existing
one :)

It's pretty simple, you already have a list of all kobjects associated
with this parent kobject (or driver or class), so search them all before
registering them if you think you might end up with a duplicate.

thanks,

greg k-h


\
 
 \ /
  Last update: 2008-07-28 20:11    [W:0.142 / U:0.088 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site