linux-kernel - Re: [PATCH v2] PCI: allow acpiphp to handle PCIe ports w/o native PCIe hotplug capability

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] [day] [month] [year] [list]

Date:	Tue, 25 Sep 2012 23:16:06 +0800
From:	Jiang Liu <liuj97@...il.com>
To:	Bjorn Helgaas <bhelgaas@...gle.com>
CC:	Jiang Liu <jiang.liu@...wei.com>,
	"Rafael J . Wysocki" <rjw@...k.pl>,
	Yijing Wang <wangyijing@...wei.com>,
	linux-kernel@...r.kernel.org, linux-pci@...r.kernel.org,
	Kenji Kaneshige <kaneshige.kenji@...fujitsu.com>
Subject: Re: [PATCH v2] PCI: allow acpiphp to handle PCIe ports w/o native
 PCIe hotplug capability

On 09/25/2012 06:10 AM, Bjorn Helgaas wrote:
> On Wed, Aug 22, 2012 at 9:16 AM, Jiang Liu <liuj97@...il.com> wrote:
>> From: Jiang Liu <jiang.liu@...wei.com>
>>
>> Commit 0d52f54e2ef64c189dedc332e680b2eb4a34590a (PCI / ACPI: Make acpiphp
>> ignore root bridges using PCIe native hotplug) added code that made the
>> acpiphp driver completely ignore PCIe root complexes for which the kernel
>> had been granted control of the native PCIe hotplug feature by the BIOS
>> through _OSC. Later commit 619a5182d1f38a3d629ee48e04fa182ef9170052
>> "PCI hotplug: Always allow acpiphp to handle non-PCIe bridges" relaxed
>> the constraints to allow acpiphp driver handle non-PCIe bridges under
>> such a complex. The constraint needs to be relaxed further to allow
>> acpiphp driver to hanlde PCIe ports without native PCIe hotplug capability.
>>
>> Some MR-IOV switch chipsets, such PLX8696, support multiple virtual PCIe
>> switches and may migrate downstream ports among virtual switches.
>> To migrate a downstream port from the source virtual switch to the target,
>> the port needs to be hot-removed from the source and hot-added into the
>> target. pciehp driver can't be used here because there's no slots within
>> the virtual PCIe switch. So acpiphp driver is used to support downstream
>> port migration. A typical configuration is as below:
>> [Root w/o native PCIe HP]
>>         [Upstream port of vswitch w/o native PCIe HP]
>>                 [Downstream port of vswitch w/ native PCIe HP]
>>                         [PCIe enpoint]
>>
>> Here acpiphp driver will be used to handle root ports and upstream port
>> in the virtual switch, and pciehp driver will be used to handle downstream
>> ports in the virtual switch.
>>
>> v1->v2: use PCIe capability accessors to read PCI_EXP_SLTCAP register
>>
>> Acked-by: Rafael J. Wysocki <rjw@...k.pl>
>> Signed-off-by: Jiang Liu <liuj97@...il.com>
> 
> I tweaked the changelog (typos, indentation) and applied this to my
> "pci/jiang-acpiphp" branch.  Kenji acked a previous version, but I
> didn't add it here because this is slightly updated.
> 
> If the PLX8696 supports moving downstream ports between upstream
> ports, it seems like a deficiency if the upstream port doesn't support
> native hotplug.  If I understand correctly, this patch allows the use
> of acpiphp for "hotplug" of the downstream ports, but that is only an
> option if the PLX8696 is in the ACPI namespace.
> 
> It seems like the lack of PLX8696 native hotplug for upstream ports
> mean this virtual switch migration can only be done if the PLX8696 is
> soldered into the system -- for instance, we don't have any way to
> deal with an 8696 on a plug-in card because ACPI won't know anything
> about that device.
Hi Bjorn,
	That's true, we can't deal with 8696 on add-in cards yet. The platform
we are working with is:
	The motherboard has a specially designed slot for a root port, which
could only be used to connect an IO-extension box with 8696. So the BIOS could
build ACPI objects for the 8696 chipset.
	Thanks!
	Gerry

--
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/