linux-kernel - Re: [PATCH 4/4] ACPI PCI slot detection driver

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: <47D75749.5060203@jp.fujitsu.com>
Date:	Wed, 12 Mar 2008 13:08:41 +0900
From:	Kenji Kaneshige <kaneshige.kenji@...fujitsu.com>
To:	Matthew Wilcox <matthew@....cx>
CC:	Alex Chiang <achiang@...com>, Greg KH <gregkh@...e.de>,
	Jesse Barnes <jbarnes@...tuousgeek.org>,
	Gary Hade <garyhade@...ibm.com>, warthog19@...lescrag.net,
	kristen.c.accardi@...el.com, rick.jones2@...com,
	linux-kernel@...r.kernel.org, linux-pci@...ey.karlin.mff.cuni.cz,
	linux-acpi@...r.kernel.org
Subject: Re: [PATCH 4/4] ACPI PCI slot detection driver

Hi,

Matthew Wilcox wrote:
> On Tue, Mar 11, 2008 at 10:10:40PM +0900, Kenji Kaneshige wrote:
>> 1) I checked ACPI spec again and again, but I could not find any
>>    reason to add Fujitsu servers to quirks list. So I'd like you to
>>    add HP servers to the quirks list. I'll send the following patches
>>    followed by this e-mail.
> 
> Alex pointed out that IBM interprets the spec the same way that HP does.
> Are there any other machines that follow the spec the same way that
> Fujitsu does?
> 

I don't know.

>> 2) The ACPI PCI slot detection driver would change the slot names of
>>    some hotplug drivers (at least I checked shpchp and pciehp). And
>>    the name of slots are depending on the order of driver loading.
>>    For example, on my system which has several SHPCHP slots and
>>    PCIEHP slots, the name of PCIEHP slots are changed as
>>    follows. Please note that PCIEHP based slots are 0034_0027 and
>>    0032_0026, and others are SHPCHP based slots.
>>
>>    - Without ACPI PCI slot detection driver
>>      # ls /sys/bus/pci/slots/
>>      0009_0016  0014_0018  0019_0020  0021_0022  0034_0027
>>      0011_0017  0016_0019  0021_0021  0032_0026
>>
>>    - With ACPI PCI slot detection driver
>>      # ls /sys/bus/pci/slots/
>>      0009_0016  0014_0018  0019_0020  0021_0022  27
>>      0011_0017  0016_0019  0021_0021  26
> 
> I hadn't realised that patch got in to put the bus name in as a
> uniquifier.  I thought we'd rejected it because the problem only
> occurred on one box with bad firmware.
>

Maybe I've told you before :-)

I also don't like to put bus into the names of those directories,
because I think the names of those directories are used as physical
slot identifier, not logical identifier, and neither PCI-to-PCI
Bridge Architecture spec, PCI Hot-Plug spec, SHPC spec nor PCI
Express spec allow putting bus number into physical slot identifier.

Removing bus number from the names of those directories would fix
the problem in a short term. But I think it is only a band-aid
because all of those specifications allow using chassis number
in the physical slot identifier. If any hotplug driver will put
chassis number into slot names, the same problem will happen.

I think it's the right direction to use combination of chassis and
slot number as a slot name if we try to unify slot names among
drivers, though there will be some challenges as follows.

- how to handle the names of vendor specific hotplug drivers?
- SHPC spec allows vendor specific names, IIRC. how to handle it?
- and so on.

>>    - Unify slot names among all hotplug drivers
> 
> That is the plan.  I'm not sure why the shpc slots aren't renamed in
> this revision of the patch -- maybe Alex dropped that part?
> 

Maybe the reason is very simple. The SHPCHP driver was loaded first,
and then ACPI PCI slot detection driver was loaded. Both are loaded
automatically at boot time. If we changed the order, we would get
another result.

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/