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  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]
Date:	Wed, 28 Oct 2009 10:44:37 -0700
From:	Yinghai Lu <>
To:	Kenji Kaneshige <>
CC:	Jesse Barnes <>,
	"" <>,
	"" <>,
	Alex Chiang <>,
	Ivan Kokshaysky <>,
	Bjorn Helgaas <>,
	"Eric W. Biederman" <>
Subject: Re: [PATCH] pci: pciehp update the slot bridge res to get big range
 for pcie devices

Kenji Kaneshige wrote:
> Yinghai Lu wrote:
>> Yinghai Lu wrote:
>>> Kenji Kaneshige wrote:
>>>> I understand you need to touch I/O base/limit and Mem base/limit. But
>>>> I don't understand why you also need to update bridge's BARs. Could
>>>> you please explain a little more about it?
>>>> Just in case, my terminology "bridge's BARs" is Base Address Register
>>>> 0 (offset 0x10) and Base Address Register 1 (offset 0x14) in the
>>>> (type 1) configuration space header of the bridge.
>>> i mean 0x1c, 0x20, 0x28
>>> did not notice that bridge device's 0x10, 0x14 are used...
>>> if port service need to use 0x10, 0x14, and the device is enabled, we
>>> should touch 0x10, and 0x14.
>> after check the code, if
>> pci_bridge_assign_resources ==> pdev_assign_resources_sorted ==> 
>> pdev_sort_resources
>> will not touch 0x10 and 0x14, if those resource is claimed by port
>> service.
>> /* Sort resources by alignment */
>> void pdev_sort_resources(struct pci_dev *dev, struct resource_list *head)
>> {               int i;
>>                         for (i = 0; i < PCI_NUM_RESOURCES; i++) {
>>                 struct resource *r;
>>                 struct resource_list *list, *tmp;
>>                 resource_size_t r_align;
>>                                 r = &dev->resource[i];
>>                                         if (r->flags &
>>                         continue;
>>                         if (!(r->flags) || r->parent)
>>                         continue;
>> r->parent != NULL, will make it skip those two.
>> So -v3 should be safe.
> Thank you for the clarification.
> But I still don't understand the whole picture of your set of
> changes. Let me ask some questions.
> In my understanding of your set of changes, if there is a PCIe
> switch with some hot-plug slots and all of those slots are empty,
> I/O and Memory resources assigned by BIOS are all released at
> the boot time. For example, suppose the following case.
>                bridge(A)
>                   |
>        -----------------------
>        |                     |
>     bridge(B)             bridge(C)
>        |                     |
>      slot(1)               slot(2)
>      (empty)               (empty)
>   bridge(A): P2P bridge for switch upstream port
>   bridge(B): P2P bridge for switch downstream port
>   bridge(C): P2P bridge for switch downstream port
> In the above example, I/O and Mem resource assigned to bridge(A),
> bridge(B) and bridge(C) are all released at the boot time. Correct?
> Then, when a adapter card is hot-added to slot(1), I/O and Mem
> resources enough for enabling the hot-added adapter card is assigned
> to bridge(A), bridge(B) and the adapter card. Correct?
> Then, when an another adpater card is hot-added to slot(2), we
> need to assign enough resource to bridge(C) and the new card.
> But bridge(A) doesn't have enough resource for bridge(C) and
> the new card. In addition, all bridge(A) and bridge(B) and the
> adapter card on slot(1) are already working. How do you assign
> resource to bridge(C) and the card on slot(2)?

thanks, will update the patches to only handle leaf bridge, and don't touch min_size etc.

To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
More majordomo info at
Please read the FAQ at

Powered by blists - more mailing lists