- 24 2月, 2012 3 次提交
-
-
由 Yinghai Lu 提交于
Otherwise when rescan is used for cardbus, assigned resources will get cleared. Signed-off-by: NYinghai Lu <yinghai@kernel.org> Tested-by: NDominik Brodowski <linux@dominikbrodowski.net> Signed-off-by: NJesse Barnes <jbarnes@virtuousgeek.org>
-
由 Yinghai Lu 提交于
We should not set the requested size to -2; that will confuse the resource list sorting with align when SIZEALIGN is used. Change to STARTALIGN and pass align from start; we are safe to do that just as we do that regular pci bridge. In the long run, we should just treat cardbus like a regular pci bridge. Also fix the case when realloc_head is not passed: we should keep the requested size. Signed-off-by: NYinghai Lu <yinghai@kernel.org> Tested-by: NDominik Brodowski <linux@dominikbrodowski.net> Acked-by: NRam Pai <linuxram@us.ibm.com> Signed-off-by: NJesse Barnes <jbarnes@virtuousgeek.org>
-
由 Yinghai Lu 提交于
Some BIOSes enable prefetch on both MEM0 and MEM1. But the cardbus code assumes MEM1 is non-pref... Discussion could be found at: https://lkml.org/lkml/2012/1/12/1 https://bugzilla.kernel.org/show_bug.cgi?id=41622#c23Signed-off-by: NYinghai Lu <yinghai@kernel.org> Tested-by: NDominik Brodowski <linux@dominikbrodowski.net> Signed-off-by: NJesse Barnes <jbarnes@virtuousgeek.org>
-
- 15 2月, 2012 15 次提交
-
-
由 Yinghai Lu 提交于
Only one user; just use add_to_list instead. Signed-off-by: NYinghai Lu <yinghai@kernel.org> Signed-off-by: NJesse Barnes <jbarnes@virtuousgeek.org>
-
由 Yinghai Lu 提交于
For use in debugging resource reallocation. Signed-off-by: NYinghai Lu <yinghai@kernel.org> Signed-off-by: NJesse Barnes <jbarnes@virtuousgeek.org>
-
由 Yinghai Lu 提交于
After merging struct pci_dev_resource_x and pci_dev_resource, We can use a function instead of macro now. Signed-off-by: NYinghai Lu <yinghai@kernel.org> Signed-off-by: NJesse Barnes <jbarnes@virtuousgeek.org>
-
由 Yinghai Lu 提交于
Linus says don't use dev_res_x because it doesn't communicate anything about usage. Rename them to add_res or fail_res etc according to context. Suggested-by: NLinus Torvalds <torvalds@linux-foundation.org> Signed-off-by: NYinghai Lu <yinghai@kernel.org> Signed-off-by: NJesse Barnes <jbarnes@virtuousgeek.org>
-
由 Yinghai Lu 提交于
pci_dev_resource_x is a superset of pci_dev_resource and they're just temp structs used during resource reallocation. pci_dev_resource usage is quite limted. So just use pci_dev_resource_x, and rename it as new pci_dev_resource. -v2: According to Linus, Separate free_list change to another patch Suggested-by: NLinus Torvalds <torvalds@linux-foundation.org> Signed-off-by: NYinghai Lu <yinghai@kernel.org> Signed-off-by: NJesse Barnes <jbarnes@virtuousgeek.org>
-
由 Yinghai Lu 提交于
So we can use helper functions for generic list. This makes the resource re-allocation code much more readable. -v2: Use list_add_tail instead of adding list_insert_before, Pointed out by Linus. Suggested-by: NLinus Torvalds <torvalds@linux-foundation.org> Signed-off-by: NYinghai Lu <yinghai@kernel.org> Signed-off-by: NJesse Barnes <jbarnes@virtuousgeek.org>
-
由 Yinghai Lu 提交于
No user outside of setup-bus.c now. Later patches will convert resource_list to a regular list. Suggested-by: NLinus Torvalds <torvalds@linux-foundation.org> Signed-off-by: NYinghai Lu <yinghai@kernel.org> Signed-off-by: NJesse Barnes <jbarnes@virtuousgeek.org>
-
由 Yinghai Lu 提交于
This allows us to move the definition of struct resource_list to setup_bus.c and later convert resource_list to a regular list. Suggested-by: NLinus Torvalds <torvalds@linux-foundation.org> Signed-off-by: NYinghai Lu <yinghai@kernel.org> Signed-off-by: NJesse Barnes <jbarnes@virtuousgeek.org>
-
由 Yinghai Lu 提交于
On a system with devices that support SRIOV connected to a pcie switch to pcie root port: +-[0000:80]-+-00.0-[81-8f]-- | +-01.0-[90-9f]-- | +-02.0-[a0-af]----00.0-[a1-a3]--+-02.0-[a2]--+-00.0 Oracle Corporation Device 207a | | \-03.0-[a3]--+-00.0 Oracle Corporation Device 207a | +-02.2-[b0-bf]----00.0-[b1-b3]--+-02.0-[b2]--+-00.0 Oracle Corporation Device 207a | | \-03.0-[b3]--+-00.0 Oracle Corporation Device 207a When the BIOS does not assign resources for SRIOV BARs, kernel pci reallocation only goes up one bridge and then gives up, failing to to get resources for all sSRIOV BARs, even though the range is large enough in the peer root bus. Specifically, only the bridge at the a1:02.0 level has its resources cleared and reallocated. The kernel does not go up to clear the bridge at the 80:02.0 level. To make it go to upper levels, during retry, we need to treat "good to have" resources as "must have". Only on the last try will we treat good to have resources as optional. At that time, parent bridge resources will already have been released so we'll have a chance to get everything assigned with must_have plus good_to_have for all child devices. Signed-off-by: NYinghai Lu <yinghai@kernel.org> Signed-off-by: NJesse Barnes <jbarnes@virtuousgeek.org>
-
由 Yinghai Lu 提交于
This allows us to allocate resources to hotplug bridges during remove/rescan. We need to move the function to setup-bus.c so it can use __pci_bus_size_bridges and __pci_bus_assign_resources directly to take the add_list resource tracking list. Signed-off-by: NYinghai Lu <yinghai@kernel.org> Signed-off-by: NJesse Barnes <jbarnes@virtuousgeek.org>
-
由 Yinghai Lu 提交于
We need add size for hot plug path when pluging in hotplug chassis without cards. -v2: change descriptions. make it applicable after "pci: Check bridge resources after resource allocation." Signed-off-by: NYinghai Lu <yinghai@kernel.org> Signed-off-by: NJesse Barnes <jbarnes@virtuousgeek.org>
-
由 Yinghai Lu 提交于
We found reassignment can not find a range for one resource, even if the total available range is large enough. bridge b1:02.0 will need 2M+3M bridge b1:03.0 will need 2M+3M so bridge b0:00.0 will get assigned: 4M : [f8000000-f83fffff] later is reassigned to 10M : [f8000000-f9ffffff] b1:02.0 is assigned to 2M : [f8000000-f81fffff] b1:03.0 is assigned to 2M : [f8200000-f83fffff] After that b1:03.0 get chance to be reassigned to [f8200000-f86fffff], but b1:02.0 will not have chance to expand, because b1:03.0 is using in middle one. [ 187.911401] pci 0000:b1:02.0: bridge window [mem 0x00100000-0x002fffff] to [bus b2-b2] add_size 300000 [ 187.920764] pci 0000:b1:03.0: bridge window [mem 0x00100000-0x002fffff] to [bus b3-b3] add_size 300000 [ 187.930129] pci 0000:b1:02.0: [mem 0x00100000-0x002fffff] get_res_add_size add_size 300000 [ 187.938500] pci 0000:b1:03.0: [mem 0x00100000-0x002fffff] get_res_add_size add_size 300000 [ 187.946857] pci 0000:b0:00.0: bridge window [mem 0x00100000-0x004fffff] to [bus b1-b3] add_size 600000 [ 187.956206] pci 0000:b0:00.0: BAR 14: assigned [mem 0xf8000000-0xf83fffff] [ 187.963102] pci 0000:b0:00.0: BAR 15: assigned [mem 0xf5000000-0xf51fffff pref] [ 187.970434] pci 0000:b0:00.0: BAR 14: reassigned [mem 0xf8000000-0xf89fffff] [ 187.977497] pci 0000:b1:02.0: BAR 14: assigned [mem 0xf8000000-0xf81fffff] [ 187.984383] pci 0000:b1:02.0: BAR 15: assigned [mem 0xf5000000-0xf50fffff pref] [ 187.991695] pci 0000:b1:03.0: BAR 14: assigned [mem 0xf8200000-0xf83fffff] [ 187.998576] pci 0000:b1:03.0: BAR 15: assigned [mem 0xf5100000-0xf51fffff pref] [ 188.005888] pci 0000:b1:03.0: BAR 14: reassigned [mem 0xf8200000-0xf86fffff] [ 188.012939] pci 0000:b1:02.0: BAR 14: can't assign mem (size 0x200000) [ 188.019471] pci 0000:b1:02.0: failed to add 300000 to res=[mem 0xf8000000-0xf81fffff] [ 188.027326] pci 0000:b2:00.0: reg 184: [mem 0x00000000-0x00003fff 64bit] [ 188.034071] pci 0000:b2:00.0: reg 18c: [mem 0x00000000-0x000fffff 64bit] [ 188.040795] pci 0000:b2:00.0: BAR 2: assigned [mem 0xf8000000-0xf80fffff 64bit] [ 188.048119] pci 0000:b2:00.0: BAR 2: set to [mem 0xf8000000-0xf80fffff 64bit] (PCI address [0xf8000000-0xf80fffff]) [ 188.058550] pci 0000:b2:00.0: BAR 6: assigned [mem 0xf5000000-0xf50fffff pref] [ 188.065802] pci 0000:b2:00.0: BAR 0: assigned [mem 0xf8100000-0xf8103fff 64bit] [ 188.073125] pci 0000:b2:00.0: BAR 0: set to [mem 0xf8100000-0xf8103fff 64bit] (PCI address [0xf8100000-0xf8103fff]) [ 188.083596] pci 0000:b2:00.0: reg 18c: [mem 0x00000000-0x000fffff 64bit] [ 188.090310] pci 0000:b2:00.0: BAR 9: can't assign mem (size 0x300000) [ 188.096773] pci 0000:b2:00.0: reg 184: [mem 0x00000000-0x00003fff 64bit] [ 188.103479] pci 0000:b2:00.0: BAR 7: assigned [mem 0xf8104000-0xf810ffff 64bit] [ 188.110801] pci 0000:b2:00.0: BAR 7: set to [mem 0xf8104000-0xf810ffff 64bit] (PCI address [0xf8104000-0xf810ffff]) [ 188.121256] pci 0000:b1:02.0: PCI bridge to [bus b2-b2] [ 188.126512] pci 0000:b1:02.0: bridge window [mem 0xf8000000-0xf81fffff] [ 188.133328] pci 0000:b1:02.0: bridge window [mem 0xf5000000-0xf50fffff pref] [ 188.140608] pci 0000:b3:00.0: reg 184: [mem 0x00000000-0x00003fff 64bit] [ 188.147341] pci 0000:b3:00.0: reg 18c: [mem 0x00000000-0x000fffff 64bit] [ 188.154076] pci 0000:b3:00.0: BAR 2: assigned [mem 0xf8200000-0xf82fffff 64bit] [ 188.161417] pci 0000:b3:00.0: BAR 2: set to [mem 0xf8200000-0xf82fffff 64bit] (PCI address [0xf8200000-0xf82fffff]) [ 188.171865] pci 0000:b3:00.0: BAR 6: assigned [mem 0xf5100000-0xf51fffff pref] [ 188.179090] pci 0000:b3:00.0: BAR 0: assigned [mem 0xf8300000-0xf8303fff 64bit] [ 188.186431] pci 0000:b3:00.0: BAR 0: set to [mem 0xf8300000-0xf8303fff 64bit] (PCI address [0xf8300000-0xf8303fff]) [ 188.196884] pci 0000:b3:00.0: reg 18c: [mem 0x00000000-0x000fffff 64bit] [ 188.203591] pci 0000:b3:00.0: BAR 9: assigned [mem 0xf8400000-0xf86fffff 64bit] [ 188.210909] pci 0000:b3:00.0: BAR 9: set to [mem 0xf8400000-0xf86fffff 64bit] (PCI address [0xf8400000-0xf86fffff]) [ 188.221379] pci 0000:b3:00.0: reg 184: [mem 0x00000000-0x00003fff 64bit] [ 188.228089] pci 0000:b3:00.0: BAR 7: assigned [mem 0xf8304000-0xf830ffff 64bit] [ 188.235407] pci 0000:b3:00.0: BAR 7: set to [mem 0xf8304000-0xf830ffff 64bit] (PCI address [0xf8304000-0xf830ffff]) [ 188.245843] pci 0000:b1:03.0: PCI bridge to [bus b3-b3] [ 188.251107] pci 0000:b1:03.0: bridge window [mem 0xf8200000-0xf86fffff] [ 188.257922] pci 0000:b1:03.0: bridge window [mem 0xf5100000-0xf51fffff pref] [ 188.265180] pci 0000:b0:00.0: PCI bridge to [bus b1-b3] [ 188.270443] pci 0000:b0:00.0: bridge window [mem 0xf8000000-0xf89fffff] [ 188.277250] pci 0000:b0:00.0: bridge window [mem 0xf5000000-0xf51fffff pref] [ 188.284512] pcieport 0000:80:02.2: PCI bridge to [bus b0-bf] [ 188.290184] pcieport 0000:80:02.2: bridge window [io 0xa000-0xbfff] [ 188.296735] pcieport 0000:80:02.2: bridge window [mem 0xf8000000-0xf8ffffff] [ 188.303963] pcieport 0000:80:02.2: bridge window [mem 0xf5000000-0xf5ffffff 64bit pref] Thus b2:00.0 BAR 9 does not get assigned... root cause: b1:02.0 can not be added more range, because b1:03.0 is just after it; no space between the required ranges. Solution: Try to assign required + optional all together at first, and if that fails, try again with just the required resources. -v2: seperate add_to_list change() to another patch according to Jesse. seperate get_res_add_size() moving to another patch according to Jesse. add !realloc_head->next check if the list is empty to bail early according to Jesse. Signed-off-by: NYinghai Lu <yinghai@kernel.org> Signed-off-by: NJesse Barnes <jbarnes@virtuousgeek.org>
-
由 Yinghai Lu 提交于
Need to call it from __assign_resources_sorted() later and we'd like to avoid a forward declaraion. Signed-off-by: NYinghai Lu <yinghai@kernel.org> Signed-off-by: NJesse Barnes <jbarnes@virtuousgeek.org>
-
由 Yinghai Lu 提交于
Will be used for resource_list_x duplication when trying requested+optional at first. Signed-off-by: NYinghai Lu <yinghai@kernel.org> Signed-off-by: NJesse Barnes <jbarnes@virtuousgeek.org>
-
由 Yinghai Lu 提交于
During debug of one SRIOV enabled hotplug device, we found found that add_size is not passed properly. The device has devices under two level bridges: +-[0000:80]-+-00.0-[81-8f]-- | +-01.0-[90-9f]-- | +-02.0-[a0-af]----00.0-[a1-a3]--+-02.0-[a2]--+-00.0 Oracle Corporation Device | | \-03.0-[a3]--+-00.0 Oracle Corporation Device Which means later the parent bridge will not try to add a big enough range: [ 557.455077] pci 0000:a0:00.0: BAR 14: assigned [mem 0xf9000000-0xf93fffff] [ 557.461974] pci 0000:a0:00.0: BAR 15: assigned [mem 0xf6000000-0xf61fffff pref] [ 557.469340] pci 0000:a1:02.0: BAR 14: assigned [mem 0xf9000000-0xf91fffff] [ 557.476231] pci 0000:a1:02.0: BAR 15: assigned [mem 0xf6000000-0xf60fffff pref] [ 557.483582] pci 0000:a1:03.0: BAR 14: assigned [mem 0xf9200000-0xf93fffff] [ 557.490468] pci 0000:a1:03.0: BAR 15: assigned [mem 0xf6100000-0xf61fffff pref] [ 557.497833] pci 0000:a1:03.0: BAR 14: can't assign mem (size 0x200000) [ 557.504378] pci 0000:a1:03.0: failed to add optional resources res=[mem 0xf9200000-0xf93fffff] [ 557.513026] pci 0000:a1:02.0: BAR 14: can't assign mem (size 0x200000) [ 557.519578] pci 0000:a1:02.0: failed to add optional resources res=[mem 0xf9000000-0xf91fffff] It turns out we did not calculate size1 properly. static resource_size_t calculate_memsize(resource_size_t size, resource_size_t min_size, resource_size_t size1, resource_size_t old_size, resource_size_t align) { if (size < min_size) size = min_size; if (old_size == 1 ) old_size = 0; if (size < old_size) size = old_size; size = ALIGN(size + size1, align); return size; } We should not pass add_size with min_size in calculate_memsize since that will make add_size not contribute final add_size. So just pass add_size with size1 to calculate_memsize(). With this change, we should have chance to remove extra addon in pci_reassign_resource. Signed-off-by: NYinghai Lu <yinghai@kernel.org> Signed-off-by: NJesse Barnes <jbarnes@virtuousgeek.org>
-
- 15 10月, 2011 1 次提交
-
-
由 Benjamin Herrenschmidt 提交于
The "powernv" platform of the powerpc architecture needs to assign PCI resources using a specific algorithm to fit some HW constraints of the IBM "IODA" architecture (related to the ability to create error handling domains that encompass specific segments of MMIO space). For doing so, it wants to call pci_setup_bridge() from architecture specific resource management in order to configure bridges after all resources have been assigned. So make it non-static. Signed-off-by: NBenjamin Herrenschmidt <benh@kernel.crashing.org> Signed-off-by: NJesse Barnes <jbarnes@virtuousgeek.org>
-
- 02 8月, 2011 5 次提交
-
-
由 Ram Pai 提交于
a) adjust_resource_sorted() is now called reassign_resource_sorted() b) nice-to-have is now called optional c) add_list is now called realloc_list. Signed-off-by: NRam Pai <linuxram@us.ibm.com> Signed-off-by: NJesse Barnes <jbarnes@virtuousgeek.org>
-
由 Ram Pai 提交于
Allocate resources to cardbus bridge only after all other genuine resources requests are satisfied. Dont retry if resource allocation for cardbus-bridges fail. Signed-off-by: NRam Pai <linuxram@us.ibm.com> Signed-off-by: NJesse Barnes <jbarnes@virtuousgeek.org>
-
由 Yinghai Lu 提交于
From: Yinghai Lu <yinghai@kernel.org> Allocate resources to SRIOV BARs only after all other required resource-requests are satisfied. Dont retry if resource allocation for SRIOV BARs fail. Signed-off-by: NRam Pai <linuxram@us.ibm.com> Signed-off-by: NYinghai Lu <yinghai@kernel.org> Signed-off-by: NJesse Barnes <jbarnes@virtuousgeek.org>
-
由 Ram Pai 提交于
Currently pci-bridges are allocated enough resources to satisfy their immediate requirements. Any additional resource-requests fail if additional free space, contiguous to the one already allocated, is not available. This behavior is not reasonable since sufficient contiguous resources, that can satisfy the request, are available at a different location. This patch provides the ability to expand and relocate a allocated resource. v2: Changelog: Fixed size calculation in pci_reassign_resource() v3: Changelog : Split this patch. The resource.c changes are already upstream. All the pci driver changes are in here. Signed-off-by: NRam Pai <linuxram@us.ibm.com> Signed-off-by: NJesse Barnes <jbarnes@virtuousgeek.org>
-
由 Yinghai Lu 提交于
git commit c8adf9a3 "PCI: pre-allocate additional resources to devices only after successful allocation of essential resources." fails to take into consideration the optional-resources needed by children devices while calculating the optional-resource needed by the bridge. This can be a problem on some setup. For example, if a hotplug bridge has 8 children hotplug bridges, the bridge should have enough resources to accomodate the hotplug requirements for each of its children hotplug bridges. Currently this is not the case. This patch fixes the problem. Signed-off-by: NYinghai Lu <yinghai@kernel.org> Reviewed-by: NRam Pai <linuxram@us.ibm.com> Signed-off-by: NJesse Barnes <jbarnes@virtuousgeek.org>
-
- 23 7月, 2011 1 次提交
-
-
由 Bjorn Helgaas 提交于
I don't think there's enough value in the fact of a bridge window being disabled to justify cluttering the dmesg log with it. Signed-off-by: NBjorn Helgaas <bhelgaas@google.com> Signed-off-by: NJesse Barnes <jbarnes@virtuousgeek.org>
-
- 09 7月, 2011 1 次提交
-
-
由 Ram Pai 提交于
Multiple attempts to dynamically reallocate pci resources have unfortunately lead to regressions. Though we continue to fix the regressions and fine tune the dynamic-reallocation behavior, we have not reached a acceptable state yet. This patch provides a interim solution. It disables dynamic reallocation by default, but adds the ability to enable it through pci=realloc kernel command line parameter. Tested-by: NOliver Hartkopp <socketcan@hartkopp.net> Signed-off-by: NRam Pai <linuxram@us.ibm.com> Signed-off-by: NJesse Barnes <jbarnes@virtuousgeek.org>
-
- 22 5月, 2011 1 次提交
-
-
由 Yinghai Lu 提交于
With Ram's fixes, this should be safe to do again. So let's give it another try. BIOS separates IO ranges between several IOHs, and on some slots, BIOS assigns resources to a bridge, but stops assigning resources to the device under that bridge, because the device needs a big resource. So: 1. allocate resources and record the failed device resources 2. clear the BIOS assigned resources of the parent bridge of failing device 3. go back and call pci assign unassigned 4. if it still fails, go up the tree, clear more bridges. and try again Now Ram's allocate requested resource already got into mainline. could put this one again. Reviewed-by: NRam Pai <linuxram@us.ibm.com> Signed-off-by: NYinghai Lu <yinghai@kernel.org> Signed-off-by: NJesse Barnes <jbarnes@virtuousgeek.org>
-
- 17 5月, 2011 1 次提交
-
-
由 Yinghai Lu 提交于
During pci remove/rescan testing found: pci 0000:c0:03.0: PCI bridge to [bus c4-c9] pci 0000:c0:03.0: bridge window [io 0x1000-0x0fff] pci 0000:c0:03.0: bridge window [mem 0xf0000000-0xf00fffff] pci 0000:c0:03.0: bridge window [mem 0xfc180000000-0xfc197ffffff 64bit pref] pci 0000:c0:03.0: device not available (can't reserve [io 0x1000-0x0fff]) pci 0000:c0:03.0: Error enabling bridge (-22), continuing pci 0000:c0:03.0: enabling bus mastering pci 0000:c0:03.0: setting latency timer to 64 pcieport 0000:c0:03.0: device not available (can't reserve [io 0x1000-0x0fff]) pcieport: probe of 0000:c0:03.0 failed with error -22 This bug was caused by commit c8adf9a3 ("PCI: pre-allocate additional resources to devices only after successful allocation of essential resources.") After that commit, pci_hotplug_io_size is changed to additional_io_size from minium size. So it will not go through resource_size(res) != 0 path, and will not be reset. The root cause is: pci_bridge_check_ranges will set RESOURCE_IO flag for pci bridge, and later if children do not need IO resource. those bridge resources will not need to be allocated. but flags is still there. that will confuse the the pci_enable_bridges later. related code: static void assign_requested_resources_sorted(struct resource_list *head, struct resource_list_x *fail_head) { struct resource *res; struct resource_list *list; int idx; for (list = head->next; list; list = list->next) { res = list->res; idx = res - &list->dev->resource[0]; if (resource_size(res) && pci_assign_resource(list->dev, idx)) { ... reset_resource(res); } } } At last, We have to clear the flags in pbus_size_mem/io when requested size == 0 and !add_head. becasue this case it will not go through adjust_resources_sorted(). Just make size1 = size0 when !add_head. it will make flags get cleared. At the same time when requested size == 0, add_size != 0, will still have in head and add_list. because we do not clear the flags for it. After this, we will get right result: pci 0000:c0:03.0: PCI bridge to [bus c4-c9] pci 0000:c0:03.0: bridge window [io disabled] pci 0000:c0:03.0: bridge window [mem 0xf0000000-0xf00fffff] pci 0000:c0:03.0: bridge window [mem 0xfc180000000-0xfc197ffffff 64bit pref] pci 0000:c0:03.0: enabling bus mastering pci 0000:c0:03.0: setting latency timer to 64 pcieport 0000:c0:03.0: setting latency timer to 64 pcieport 0000:c0:03.0: irq 160 for MSI/MSI-X pcieport 0000:c0:03.0: Signaling PME through PCIe PME interrupt pci 0000:c4:00.0: Signaling PME through PCIe PME interrupt pcie_pme 0000:c0:03.0:pcie01: service driver pcie_pme loaded aer 0000:c0:03.0:pcie02: service driver aer loaded pciehp 0000:c0:03.0:pcie04: Hotplug Controller: v3: more simple fix. also fix one typo in pbus_size_mem Signed-off-by: NYinghai Lu <yinghai@kernel.org> Reviewed-by: NRam Pai <linuxram@us.ibm.com> Cc: Jesse Barnes <jbarnes@virtuousgeek.org> Cc: Bjorn Helgaas <bhelgaas@google.com> Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
-
- 12 4月, 2011 1 次提交
-
-
由 Linus Torvalds 提交于
In commit 13583b16 ("PCI: refactor io size calculation code") Ram had a thinko in the refactorization of the code: the end result used the variable 'align' for the bus alignment, but the original code used 'min_align'. Since then, another use of that 'align' variable got introduced by commit c8adf9a3 ("PCI: pre-allocate additional resources to devices only after successful allocation of essential resources.") Fix both of those uses to use 'min_align' as they should. Daniel Hellstrom <daniel@gaisler.com> Acked-by: NRam Pai <linuxram@us.ibm.com> Acked-by: NJesse Barnes <jbarnes@virtuousgeek.org> Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
-
- 05 3月, 2011 4 次提交
-
-
由 Ram Pai 提交于
PCI: pre-allocate additional resources to devices only after successful allocation of essential resources. Linux tries to pre-allocate minimal resources to hotplug bridges. This works fine as long as there are enough resources to satisfy all other genuine resource requirements. However if enough resources are not available to satisfy any of these nice-to-have pre-allocations, the resource-allocator reports errors and returns failure. This patch distinguishes between must-have resource from nice-to-have resource. Any failure to allocate nice-to-have resources are ignored. This behavior can be particularly useful to trigger automatic reallocation when the OS discovers genuine allocation-conflicts or genuine unallocated-requests caused by buggy allocation behavior of the native BIOS/uEFI. https://bugzilla.kernel.org/show_bug.cgi?id=15960 captures the movitation behind the patch. This patch is verified to resolve the above bug. changelog v2: o fixed a bug where pci_assign_resource() was called on a resource of zero resource size. changelog v3: addressed Bjorn's comment o "Please don't indent and right-justify the changelog". o removed add_size from struct resource. The additional size is now tracked using a linked list. changelog v4: o moved freeing up of elements in head list from assign_requested_resources_sorted() to __assign_resources_sorted(). o removed a wrong reference to 'add_size' in pbus_size_mem(). o some code optimizations in adjust_resources_sorted() and assign_requested_resources_sorted() changelog v5: o moved freeing up of elements in head list from assign_requested_resources_sorted() to __assign_resources_sorted(). o removed a wrong reference to 'add_size' in pbus_size_mem(). o some code optimizations in adjust_resources_sorted() and assign_requested_resources_sorted() changelog v5: o factored out common code and made them into separate independent patches o added comments in kdoc format o added a BUG_ON in pci_assign_unassigned_resources() to catch for memory leak. Signed-off-by: NRam Pai <linuxram@us.ibm.com> Signed-off-by: NJesse Barnes <jbarnes@virtuousgeek.org>
-
由 Ram Pai 提交于
Introduce reset_resource() which factors out resource reset logic. Signed-off-by: NRam Pai <linuxram@us.ibm.com> Signed-off-by: NJesse Barnes <jbarnes@virtuousgeek.org>
-
由 Ram Pai 提交于
Replace free_failed_list() with a free_list() call. free_list() can handle 'resource_list_x', 'resource_list' and any linked list linked through ->next Signed-off-by: NRam Pai <linuxram@us.ibm.com> Signed-off-by: NJesse Barnes <jbarnes@virtuousgeek.org>
-
由 Ram Pai 提交于
Refactor code that calculates the io size in pbus_size_io() and pbus_mem_io() into separate functions. Signed-off-by: NRam Pai <linuxram@us.ibm.com> Signed-off-by: NJesse Barnes <jbarnes@virtuousgeek.org>
-
- 31 7月, 2010 1 次提交
-
-
由 Yinghai Lu 提交于
Found one PCIe Module with several bridges built-in where a "cold" hotadd doesn't work. If we end up reassigning bridge windows at hotadd time, and have to loop through assigning new ranges, we won't end up enabling the child bridges because the first assignment pass already tried to enable them, which prevents __pci_bridge_assign_resource from updating the windows. So try to move enabling of child bridges to the end, and only do it once. Signed-off-by: NYinghai Lu <yinghai@kernel.org> Signed-off-by: NJesse Barnes <jbarnes@virtuousgeek.org>
-
- 13 5月, 2010 1 次提交
-
-
由 Linus Torvalds 提交于
This reverts commit 977d17bb, because it can cause problems with some devices not getting any resources at all when the resource tree is re-allocated. For an example of this, see https://bugzilla.kernel.org/show_bug.cgi?id=15960 (originally https://bugtrack.alsa-project.org/alsa-bug/view.php?id=4982) (lkml thread: http://lkml.org/lkml/2010/4/19/20) where Peter Henriksson reported his Xonar DX sound card gone, because the IO port region was no longer allocated. Reported-bisected-and-tested-by: NPeter Henriksson <peter.henriksson@gmail.com> Requested-by: NAndrew Morton <akpm@linux-foundation.org> Requested-by: NClemens Ladisch <clemens@ladisch.de> Acked-by: NJesse Barnes <jbarnes@virtuousgeek.org> Cc: Yinghai Lu <yinghai@kernel.org> Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
-
- 01 3月, 2010 1 次提交
-
-
由 Yinghai Lu 提交于
A ROM resource that doesn't fit should not cause us to try to re-assign all the bus resources. Nobody generally cares, and re-assigning is going to just cause way more troubles than it tries to solve. Signed-off-by: NYinghai Lu <yinghai@kernel.org> Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
-
- 24 2月, 2010 1 次提交
-
-
由 Bjorn Helgaas 提交于
No functional change; this converts loops that iterate from 0 to PCI_BUS_NUM_RESOURCES through pci_bus resource[] table to use the pci_bus_for_each_resource() iterator instead. This doesn't change the way resources are stored; it merely removes dependencies on the fact that they're in a table. Signed-off-by: NBjorn Helgaas <bjorn.helgaas@hp.com> Signed-off-by: NJesse Barnes <jbarnes@virtuousgeek.org>
-
- 23 2月, 2010 3 次提交
-
-
由 Yinghai Lu 提交于
Make pci_bridge_check_ranges() store the PCI_PREF_RANGE_TYPE_64 in addition to IORESOURCE_MEM_64. Just like pci_read_bridge_bases(). Signed-off-by: NYinghai Lu <yinghai@kernel.org> Signed-off-by: NJesse Barnes <jbarnes@virtuousgeek.org>
-
由 Yinghai Lu 提交于
Handle the case where the slot bridge that doesn't get a pre-allocated resource big enough to handle its child resources.. For example pcie devices need 256M, but the bridge only gets 2M preallocated. Signed-off-by: NYinghai Lu <yinghai@kernel.org> Signed-off-by: NJesse Barnes <jbarnes@virtuousgeek.org>
-
由 Yinghai Lu 提交于
For use by pciehp. pci_setup_bridge() will not check enabled for the slot bridge, otherwise update res is not updated to bridge BAR. That is, bridge is already enabled for port service. Signed-off-by: NYinghai Lu <yinghai@kernel.org> Reviewed-by: NAlex Chiang <achiang@hp.com> Signed-off-by: NJesse Barnes <jbarnes@virtuousgeek.org>
-