linux-kernel - Re: post 2.6.26 requires pciehp_slot_with

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <48895D3C.7040100@jp.fujitsu.com>
Date:	Fri, 25 Jul 2008 13:57:32 +0900
From:	Kenji Kaneshige <kaneshige.kenji@...fujitsu.com>
To:	Matthew Wilcox <matthew@....cx>
CC:	Pierre Ossman <drzeus-list@...eus.cx>,
	Alex Chiang <achiang@...com>,
	Jesse Barnes <jbarnes@...tuousgeek.org>,
	LKML <linux-kernel@...r.kernel.org>, linux-pci@...r.kernel.org
Subject: Re: post 2.6.26 requires pciehp_slot_with_bus

Matthew Wilcox wrote:
> 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@...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.
> 

I'm thinking the same idea.
(I just sent that before reading this mail)

> 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.
> 
> 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".
> 

That looks quite better than using bus number.

Thanks,
Kenji Kaneshige


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/