2018-01-26 20:45:16 +03:00
// SPDX-License-Identifier: GPL-2.0
2005-04-17 02:20:36 +04:00
/*
2018-03-10 01:36:33 +03:00
* Support routines for initializing a PCI subsystem
2005-04-17 02:20:36 +04:00
*
* Extruded from code written by
* Dave Rusling ( david . rusling @ reo . mts . dec . com )
* David Mosberger ( davidm @ cs . arizona . edu )
* David Miller ( davem @ redhat . com )
*
* Nov 2000 , Ivan Kokshaysky < ink @ jurassic . park . msu . ru >
* PCI - PCI bridges cleanup , sorted resource allocation .
* Feb 2002 , Ivan Kokshaysky < ink @ jurassic . park . msu . ru >
* Converted to allocation in 3 passes , which gives
* tighter packing . Prefetchable range support .
*/
# include <linux/init.h>
# include <linux/kernel.h>
# include <linux/module.h>
# include <linux/pci.h>
# include <linux/errno.h>
# include <linux/ioport.h>
# include <linux/cache.h>
# include <linux/slab.h>
2016-08-17 11:00:34 +03:00
# include <linux/acpi.h>
2009-08-29 00:00:06 +04:00
# include "pci.h"
2005-04-17 02:20:36 +04:00
2012-02-24 07:18:59 +04:00
unsigned int pci_flags ;
2020-04-10 02:49:22 +03:00
EXPORT_SYMBOL_GPL ( pci_flags ) ;
2012-02-24 01:29:23 +04:00
2012-01-21 14:08:27 +04:00
struct pci_dev_resource {
struct list_head list ;
2012-01-21 14:08:26 +04:00
struct resource * res ;
struct pci_dev * dev ;
2010-01-22 12:02:21 +03:00
resource_size_t start ;
resource_size_t end ;
2011-02-15 04:43:20 +03:00
resource_size_t add_size ;
2011-07-26 00:08:39 +04:00
resource_size_t min_align ;
2010-01-22 12:02:21 +03:00
unsigned long flags ;
} ;
2012-01-21 14:08:30 +04:00
static void free_list ( struct list_head * head )
{
struct pci_dev_resource * dev_res , * tmp ;
list_for_each_entry_safe ( dev_res , tmp , head , list ) {
list_del ( & dev_res - > list ) ;
kfree ( dev_res ) ;
}
}
2011-02-15 04:43:18 +03:00
2011-02-15 04:43:20 +03:00
/**
2019-05-07 22:51:24 +03:00
* add_to_list ( ) - Add a new resource tracker to the list
2011-02-15 04:43:20 +03:00
* @ head : Head of the list
2019-05-07 22:51:24 +03:00
* @ dev : Device to which the resource belongs
* @ res : Resource to be tracked
* @ add_size : Additional size to be optionally added to the resource
2020-07-29 23:12:19 +03:00
* @ min_align : Minimum memory window alignment
2011-02-15 04:43:20 +03:00
*/
2019-05-07 22:51:24 +03:00
static int add_to_list ( struct list_head * head , struct pci_dev * dev ,
struct resource * res , resource_size_t add_size ,
resource_size_t min_align )
2010-01-22 12:02:21 +03:00
{
2012-01-21 14:08:28 +04:00
struct pci_dev_resource * tmp ;
2010-01-22 12:02:21 +03:00
2012-01-21 14:08:27 +04:00
tmp = kzalloc ( sizeof ( * tmp ) , GFP_KERNEL ) ;
PCI: Remove unnecessary messages for memory allocation failures
Per ebfdc40969f2 ("checkpatch: attempt to find unnecessary 'out of memory'
messages"), when a memory allocation fails, the memory subsystem emits
generic "out of memory" messages (see slab_out_of_memory() for some of this
logging). Therefore, additional error messages in the caller don't add
much value.
Remove messages that merely report "out of memory".
This preserves some messages that report additional information, e.g.,
allocation failures that mean we drop hotplug events.
This issue was detected by using the Coccinelle software.
Signed-off-by: Markus Elfring <elfring@users.sourceforge.net>
[bhelgaas: changelog, squash patches, make similar changes to acpiphp,
cpqphp, ibmphp, keep warning when dropping hotplug event]
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
2017-12-29 14:15:16 +03:00
if ( ! tmp )
2012-01-21 14:08:18 +04:00
return - ENOMEM ;
2010-01-22 12:02:21 +03:00
tmp - > res = res ;
tmp - > dev = dev ;
tmp - > start = res - > start ;
tmp - > end = res - > end ;
tmp - > flags = res - > flags ;
2011-02-15 04:43:20 +03:00
tmp - > add_size = add_size ;
2011-07-26 00:08:39 +04:00
tmp - > min_align = min_align ;
2012-01-21 14:08:27 +04:00
list_add ( & tmp - > list , head ) ;
2012-01-21 14:08:18 +04:00
return 0 ;
2010-01-22 12:02:21 +03:00
}
2019-05-07 22:51:24 +03:00
static void remove_from_list ( struct list_head * head , struct resource * res )
2012-01-21 14:08:20 +04:00
{
2012-01-21 14:08:29 +04:00
struct pci_dev_resource * dev_res , * tmp ;
2012-01-21 14:08:20 +04:00
2012-01-21 14:08:29 +04:00
list_for_each_entry_safe ( dev_res , tmp , head , list ) {
if ( dev_res - > res = = res ) {
list_del ( & dev_res - > list ) ;
kfree ( dev_res ) ;
2012-01-21 14:08:27 +04:00
break ;
2012-01-21 14:08:20 +04:00
}
}
}
2015-03-25 11:23:51 +03:00
static struct pci_dev_resource * res_to_dev_res ( struct list_head * head ,
struct resource * res )
2012-01-21 14:08:19 +04:00
{
2012-01-21 14:08:29 +04:00
struct pci_dev_resource * dev_res ;
2012-01-21 14:08:27 +04:00
2012-01-21 14:08:29 +04:00
list_for_each_entry ( dev_res , head , list ) {
2016-12-29 20:27:52 +03:00
if ( dev_res - > res = = res )
2015-03-25 11:23:51 +03:00
return dev_res ;
2012-01-21 14:08:20 +04:00
}
2012-01-21 14:08:19 +04:00
2015-03-25 11:23:51 +03:00
return NULL ;
2012-01-21 14:08:19 +04:00
}
2015-03-25 11:23:51 +03:00
static resource_size_t get_res_add_size ( struct list_head * head ,
struct resource * res )
{
struct pci_dev_resource * dev_res ;
dev_res = res_to_dev_res ( head , res ) ;
return dev_res ? dev_res - > add_size : 0 ;
}
static resource_size_t get_res_add_align ( struct list_head * head ,
struct resource * res )
{
struct pci_dev_resource * dev_res ;
dev_res = res_to_dev_res ( head , res ) ;
return dev_res ? dev_res - > min_align : 0 ;
}
2012-01-21 14:08:25 +04:00
/* Sort resources by alignment */
2012-01-21 14:08:27 +04:00
static void pdev_sort_resources ( struct pci_dev * dev , struct list_head * head )
2012-01-21 14:08:25 +04:00
{
int i ;
for ( i = 0 ; i < PCI_NUM_RESOURCES ; i + + ) {
struct resource * r ;
2012-01-21 14:08:27 +04:00
struct pci_dev_resource * dev_res , * tmp ;
2012-01-21 14:08:25 +04:00
resource_size_t r_align ;
2012-01-21 14:08:27 +04:00
struct list_head * n ;
2012-01-21 14:08:25 +04:00
r = & dev - > resource [ i ] ;
if ( r - > flags & IORESOURCE_PCI_FIXED )
continue ;
if ( ! ( r - > flags ) | | r - > parent )
continue ;
r_align = pci_resource_alignment ( dev , r ) ;
if ( ! r_align ) {
2018-01-18 21:55:24 +03:00
pci_warn ( dev , " BAR %d: %pR has bogus alignment \n " ,
2012-01-21 14:08:25 +04:00
i , r ) ;
continue ;
}
2012-01-21 14:08:27 +04:00
tmp = kzalloc ( sizeof ( * tmp ) , GFP_KERNEL ) ;
if ( ! tmp )
2020-07-09 10:28:28 +03:00
panic ( " %s: kzalloc() failed! \n " , __func__ ) ;
2012-01-21 14:08:27 +04:00
tmp - > res = r ;
tmp - > dev = dev ;
2019-05-07 22:51:24 +03:00
/* Fallback is smallest one or list is empty */
2012-01-21 14:08:27 +04:00
n = head ;
list_for_each_entry ( dev_res , head , list ) {
resource_size_t align ;
align = pci_resource_alignment ( dev_res - > dev ,
dev_res - > res ) ;
2012-01-21 14:08:25 +04:00
if ( r_align > align ) {
2012-01-21 14:08:27 +04:00
n = & dev_res - > list ;
2012-01-21 14:08:25 +04:00
break ;
}
}
2019-05-07 22:51:24 +03:00
/* Insert it just before n */
2012-01-21 14:08:27 +04:00
list_add_tail ( & tmp - > list , n ) ;
2012-01-21 14:08:25 +04:00
}
}
2019-05-07 22:51:24 +03:00
static void __dev_sort_resources ( struct pci_dev * dev , struct list_head * head )
2005-04-17 02:20:36 +04:00
{
2010-01-22 12:02:25 +03:00
u16 class = dev - > class > > 8 ;
2005-04-17 02:20:36 +04:00
2019-05-07 22:51:24 +03:00
/* Don't touch classless devices or host bridges or IOAPICs */
2010-01-22 12:02:25 +03:00
if ( class = = PCI_CLASS_NOT_DEFINED | | class = = PCI_CLASS_BRIDGE_HOST )
return ;
2005-04-17 02:20:36 +04:00
2019-05-07 22:51:24 +03:00
/* Don't touch IOAPIC devices already enabled by firmware */
2010-01-22 12:02:25 +03:00
if ( class = = PCI_CLASS_SYSTEM_PIC ) {
u16 command ;
pci_read_config_word ( dev , PCI_COMMAND , & command ) ;
if ( command & ( PCI_COMMAND_IO | PCI_COMMAND_MEMORY ) )
return ;
}
2005-04-17 02:20:36 +04:00
2010-01-22 12:02:25 +03:00
pdev_sort_resources ( dev , head ) ;
}
2006-09-12 21:21:44 +04:00
2011-02-15 04:43:19 +03:00
static inline void reset_resource ( struct resource * res )
{
res - > start = 0 ;
res - > end = 0 ;
res - > flags = 0 ;
}
2011-02-15 04:43:20 +03:00
/**
2019-05-07 22:51:24 +03:00
* reassign_resources_sorted ( ) - Satisfy any additional resource requests
2011-02-15 04:43:20 +03:00
*
2019-05-07 22:51:24 +03:00
* @ realloc_head : Head of the list tracking requests requiring
* additional resources
* @ head : Head of the list tracking requests with allocated
* resources
2011-02-15 04:43:20 +03:00
*
2019-05-07 22:51:24 +03:00
* Walk through each element of the realloc_head and try to procure additional
* resources for the element , provided the element is in the head list .
2011-02-15 04:43:20 +03:00
*/
2012-01-21 14:08:27 +04:00
static void reassign_resources_sorted ( struct list_head * realloc_head ,
2019-05-07 22:51:24 +03:00
struct list_head * head )
2010-01-22 12:02:25 +03:00
{
struct resource * res ;
2012-01-21 14:08:29 +04:00
struct pci_dev_resource * add_res , * tmp ;
2012-01-21 14:08:27 +04:00
struct pci_dev_resource * dev_res ;
2015-03-25 11:23:51 +03:00
resource_size_t add_size , align ;
2010-01-22 12:02:25 +03:00
int idx ;
2005-04-17 02:20:36 +04:00
2012-01-21 14:08:29 +04:00
list_for_each_entry_safe ( add_res , tmp , realloc_head , list ) {
2012-01-21 14:08:27 +04:00
bool found_match = false ;
2012-01-21 14:08:29 +04:00
res = add_res - > res ;
2019-05-07 22:51:24 +03:00
/* Skip resource that has been reset */
2011-02-15 04:43:20 +03:00
if ( ! res - > flags )
goto out ;
2019-05-07 22:51:24 +03:00
/* Skip this resource if not found in head list */
2012-01-21 14:08:27 +04:00
list_for_each_entry ( dev_res , head , list ) {
if ( dev_res - > res = = res ) {
found_match = true ;
break ;
}
2011-02-15 04:43:20 +03:00
}
2019-05-07 22:51:24 +03:00
if ( ! found_match ) /* Just skip */
2012-01-21 14:08:27 +04:00
continue ;
2011-02-15 04:43:20 +03:00
2012-01-21 14:08:29 +04:00
idx = res - & add_res - > dev - > resource [ 0 ] ;
add_size = add_res - > add_size ;
2015-03-25 11:23:51 +03:00
align = add_res - > min_align ;
2011-07-26 00:08:39 +04:00
if ( ! resource_size ( res ) ) {
2015-03-25 11:23:51 +03:00
res - > start = align ;
2011-07-26 00:08:39 +04:00
res - > end = res - > start + add_size - 1 ;
2012-01-21 14:08:29 +04:00
if ( pci_assign_resource ( add_res - > dev , idx ) )
2011-02-15 04:43:20 +03:00
reset_resource ( res ) ;
2011-07-26 00:08:39 +04:00
} else {
2012-01-21 14:08:29 +04:00
res - > flags | = add_res - > flags &
2012-01-21 14:08:27 +04:00
( IORESOURCE_STARTALIGN | IORESOURCE_SIZEALIGN ) ;
2012-01-21 14:08:29 +04:00
if ( pci_reassign_resource ( add_res - > dev , idx ,
2012-01-21 14:08:27 +04:00
add_size , align ) )
2019-04-20 07:07:20 +03:00
pci_info ( add_res - > dev , " failed to add %llx res[%d]=%pR \n " ,
( unsigned long long ) add_size , idx ,
res ) ;
2011-02-15 04:43:20 +03:00
}
out :
2012-01-21 14:08:29 +04:00
list_del ( & add_res - > list ) ;
kfree ( add_res ) ;
2011-02-15 04:43:20 +03:00
}
}
/**
2019-05-07 22:51:24 +03:00
* assign_requested_resources_sorted ( ) - Satisfy resource requests
2011-02-15 04:43:20 +03:00
*
2019-05-07 22:51:24 +03:00
* @ head : Head of the list tracking requests for resources
* @ fail_head : Head of the list tracking requests that could not be
* allocated
2011-02-15 04:43:20 +03:00
*
2019-05-07 22:51:24 +03:00
* Satisfy resource requests of each element in the list . Add requests that
* could not be satisfied to the failed_list .
2011-02-15 04:43:20 +03:00
*/
2012-01-21 14:08:27 +04:00
static void assign_requested_resources_sorted ( struct list_head * head ,
struct list_head * fail_head )
2011-02-15 04:43:20 +03:00
{
struct resource * res ;
2012-01-21 14:08:27 +04:00
struct pci_dev_resource * dev_res ;
2011-02-15 04:43:20 +03:00
int idx ;
2010-03-01 02:49:39 +03:00
2012-01-21 14:08:27 +04:00
list_for_each_entry ( dev_res , head , list ) {
res = dev_res - > res ;
idx = res - & dev_res - > dev - > resource [ 0 ] ;
if ( resource_size ( res ) & &
pci_assign_resource ( dev_res - > dev , idx ) ) {
2013-01-22 01:20:43 +04:00
if ( fail_head ) {
2010-03-01 02:49:39 +03:00
/*
2019-05-07 22:51:24 +03:00
* If the failed resource is a ROM BAR and
* it will be enabled later , don ' t add it
* to the list .
2010-03-01 02:49:39 +03:00
*/
if ( ! ( ( idx = = PCI_ROM_RESOURCE ) & &
( ! ( res - > flags & IORESOURCE_ROM_ENABLE ) ) ) )
2012-01-21 14:08:32 +04:00
add_to_list ( fail_head ,
dev_res - > dev , res ,
2013-11-14 22:28:18 +04:00
0 /* don't care */ ,
0 /* don't care */ ) ;
2010-03-01 02:49:39 +03:00
}
2011-02-15 04:43:19 +03:00
reset_resource ( res ) ;
2005-04-28 11:25:50 +04:00
}
2005-04-17 02:20:36 +04:00
}
}
2013-07-25 17:31:38 +04:00
static unsigned long pci_fail_res_type_mask ( struct list_head * fail_head )
{
struct pci_dev_resource * fail_res ;
unsigned long mask = 0 ;
2019-05-07 22:51:24 +03:00
/* Check failed type */
2013-07-25 17:31:38 +04:00
list_for_each_entry ( fail_res , fail_head , list )
mask | = fail_res - > flags ;
/*
2019-05-07 22:51:24 +03:00
* One pref failed resource will set IORESOURCE_MEM , as we can
* allocate pref in non - pref range . Will release all assigned
* non - pref sibling resources according to that bit .
2013-07-25 17:31:38 +04:00
*/
return mask & ( IORESOURCE_IO | IORESOURCE_MEM | IORESOURCE_PREFETCH ) ;
}
static bool pci_need_to_release ( unsigned long mask , struct resource * res )
{
if ( res - > flags & IORESOURCE_IO )
return ! ! ( mask & IORESOURCE_IO ) ;
2019-05-07 22:51:24 +03:00
/* Check pref at first */
2013-07-25 17:31:38 +04:00
if ( res - > flags & IORESOURCE_PREFETCH ) {
if ( mask & IORESOURCE_PREFETCH )
return true ;
2019-05-07 22:51:24 +03:00
/* Count pref if its parent is non-pref */
2013-07-25 17:31:38 +04:00
else if ( ( mask & IORESOURCE_MEM ) & &
! ( res - > parent - > flags & IORESOURCE_PREFETCH ) )
return true ;
else
return false ;
}
if ( res - > flags & IORESOURCE_MEM )
return ! ! ( mask & IORESOURCE_MEM ) ;
2019-05-07 22:51:24 +03:00
return false ; /* Should not get here */
2013-07-25 17:31:38 +04:00
}
2012-01-21 14:08:27 +04:00
static void __assign_resources_sorted ( struct list_head * head ,
2019-05-07 22:51:24 +03:00
struct list_head * realloc_head ,
struct list_head * fail_head )
2011-02-15 04:43:20 +03:00
{
2012-01-21 14:08:20 +04:00
/*
2019-05-07 22:51:24 +03:00
* Should not assign requested resources at first . They could be
* adjacent , so later reassign can not reallocate them one by one in
* parent resource window .
*
* Try to assign requested + add_size at beginning . If could do that ,
* could get out early . If could not do that , we still try to assign
* requested at first , then try to reassign add_size for some resources .
2013-07-25 17:31:38 +04:00
*
* Separate three resource type checking if we need to release
* assigned resource after requested + add_size try .
2019-05-07 22:51:24 +03:00
*
* 1. If IO port assignment fails , will release assigned IO
* port .
* 2. If pref MMIO assignment fails , release assigned pref
* MMIO . If assigned pref MMIO ' s parent is non - pref MMIO
* and non - pref MMIO assignment fails , will release that
* assigned pref MMIO .
* 3. If non - pref MMIO assignment fails or pref MMIO
* assignment fails , will release assigned non - pref MMIO .
2012-01-21 14:08:20 +04:00
*/
2012-01-21 14:08:27 +04:00
LIST_HEAD ( save_head ) ;
LIST_HEAD ( local_fail_head ) ;
2012-01-21 14:08:29 +04:00
struct pci_dev_resource * save_res ;
2015-03-25 11:23:51 +03:00
struct pci_dev_resource * dev_res , * tmp_res , * dev_res2 ;
2013-07-25 17:31:38 +04:00
unsigned long fail_type ;
2015-03-25 11:23:51 +03:00
resource_size_t add_align , align ;
2012-01-21 14:08:20 +04:00
/* Check if optional add_size is there */
2012-01-21 14:08:27 +04:00
if ( ! realloc_head | | list_empty ( realloc_head ) )
2012-01-21 14:08:20 +04:00
goto requested_and_reassign ;
/* Save original start, end, flags etc at first */
2012-01-21 14:08:27 +04:00
list_for_each_entry ( dev_res , head , list ) {
if ( add_to_list ( & save_head , dev_res - > dev , dev_res - > res , 0 , 0 ) ) {
2012-01-21 14:08:30 +04:00
free_list ( & save_head ) ;
2012-01-21 14:08:20 +04:00
goto requested_and_reassign ;
}
2012-01-21 14:08:27 +04:00
}
2012-01-21 14:08:20 +04:00
/* Update res in head list with add_size in realloc_head list */
2015-03-25 11:23:51 +03:00
list_for_each_entry_safe ( dev_res , tmp_res , head , list ) {
2012-01-21 14:08:27 +04:00
dev_res - > res - > end + = get_res_add_size ( realloc_head ,
dev_res - > res ) ;
2012-01-21 14:08:20 +04:00
2015-03-25 11:23:51 +03:00
/*
* There are two kinds of additional resources in the list :
* 1. bridge resource - - IORESOURCE_STARTALIGN
2019-05-07 22:51:24 +03:00
* 2. SR - IOV resource - - IORESOURCE_SIZEALIGN
2015-03-25 11:23:51 +03:00
* Here just fix the additional alignment for bridge
*/
if ( ! ( dev_res - > res - > flags & IORESOURCE_STARTALIGN ) )
continue ;
add_align = get_res_add_align ( realloc_head , dev_res - > res ) ;
/*
2019-05-07 22:51:24 +03:00
* The " head " list is sorted by alignment so resources with
* bigger alignment will be assigned first . After we
* change the alignment of a dev_res in " head " list , we
* need to reorder the list by alignment to make it
2015-03-25 11:23:51 +03:00
* consistent .
*/
if ( add_align > dev_res - > res - > start ) {
2015-05-29 08:40:00 +03:00
resource_size_t r_size = resource_size ( dev_res - > res ) ;
2015-03-25 11:23:51 +03:00
dev_res - > res - > start = add_align ;
2015-05-29 08:40:00 +03:00
dev_res - > res - > end = add_align + r_size - 1 ;
2015-03-25 11:23:51 +03:00
list_for_each_entry ( dev_res2 , head , list ) {
align = pci_resource_alignment ( dev_res2 - > dev ,
dev_res2 - > res ) ;
2015-05-19 09:24:17 +03:00
if ( add_align > align ) {
2015-03-25 11:23:51 +03:00
list_move_tail ( & dev_res - > list ,
& dev_res2 - > list ) ;
2015-05-19 09:24:17 +03:00
break ;
}
2015-03-25 11:23:51 +03:00
}
2015-12-28 00:21:11 +03:00
}
2015-03-25 11:23:51 +03:00
}
2012-01-21 14:08:20 +04:00
/* Try updated head list with add_size added */
assign_requested_resources_sorted ( head , & local_fail_head ) ;
2019-05-07 22:51:24 +03:00
/* All assigned with add_size? */
2012-01-21 14:08:27 +04:00
if ( list_empty ( & local_fail_head ) ) {
2012-01-21 14:08:20 +04:00
/* Remove head list from realloc_head list */
2012-01-21 14:08:27 +04:00
list_for_each_entry ( dev_res , head , list )
remove_from_list ( realloc_head , dev_res - > res ) ;
2012-01-21 14:08:30 +04:00
free_list ( & save_head ) ;
free_list ( head ) ;
2012-01-21 14:08:20 +04:00
return ;
}
2019-05-07 22:51:24 +03:00
/* Check failed type */
2013-07-25 17:31:38 +04:00
fail_type = pci_fail_res_type_mask ( & local_fail_head ) ;
2019-05-07 22:51:24 +03:00
/* Remove not need to be released assigned res from head list etc */
2013-07-25 17:31:38 +04:00
list_for_each_entry_safe ( dev_res , tmp_res , head , list )
if ( dev_res - > res - > parent & &
! pci_need_to_release ( fail_type , dev_res - > res ) ) {
2019-05-07 22:51:24 +03:00
/* Remove it from realloc_head list */
2013-07-25 17:31:38 +04:00
remove_from_list ( realloc_head , dev_res - > res ) ;
remove_from_list ( & save_head , dev_res - > res ) ;
list_del ( & dev_res - > list ) ;
kfree ( dev_res ) ;
}
2012-01-21 14:08:30 +04:00
free_list ( & local_fail_head ) ;
2012-01-21 14:08:20 +04:00
/* Release assigned resource */
2012-01-21 14:08:27 +04:00
list_for_each_entry ( dev_res , head , list )
if ( dev_res - > res - > parent )
release_resource ( dev_res - > res ) ;
2012-01-21 14:08:20 +04:00
/* Restore start/end/flags from saved list */
2012-01-21 14:08:29 +04:00
list_for_each_entry ( save_res , & save_head , list ) {
struct resource * res = save_res - > res ;
2012-01-21 14:08:20 +04:00
2012-01-21 14:08:29 +04:00
res - > start = save_res - > start ;
res - > end = save_res - > end ;
res - > flags = save_res - > flags ;
2012-01-21 14:08:20 +04:00
}
2012-01-21 14:08:30 +04:00
free_list ( & save_head ) ;
2012-01-21 14:08:20 +04:00
requested_and_reassign :
2011-02-15 04:43:20 +03:00
/* Satisfy the must-have resource requests */
assign_requested_resources_sorted ( head , fail_head ) ;
2019-05-07 22:51:24 +03:00
/* Try to satisfy any additional optional resource requests */
2011-07-26 00:08:42 +04:00
if ( realloc_head )
reassign_resources_sorted ( realloc_head , head ) ;
2012-01-21 14:08:30 +04:00
free_list ( head ) ;
2011-02-15 04:43:20 +03:00
}
2010-01-22 12:02:25 +03:00
static void pdev_assign_resources_sorted ( struct pci_dev * dev ,
2019-05-07 22:51:24 +03:00
struct list_head * add_head ,
struct list_head * fail_head )
2010-01-22 12:02:25 +03:00
{
2012-01-21 14:08:27 +04:00
LIST_HEAD ( head ) ;
2010-01-22 12:02:25 +03:00
__dev_sort_resources ( dev , & head ) ;
2012-01-21 14:08:21 +04:00
__assign_resources_sorted ( & head , add_head , fail_head ) ;
2010-01-22 12:02:25 +03:00
}
static void pbus_assign_resources_sorted ( const struct pci_bus * bus ,
2012-01-21 14:08:27 +04:00
struct list_head * realloc_head ,
struct list_head * fail_head )
2010-01-22 12:02:25 +03:00
{
struct pci_dev * dev ;
2012-01-21 14:08:27 +04:00
LIST_HEAD ( head ) ;
2010-01-22 12:02:25 +03:00
list_for_each_entry ( dev , & bus - > devices , bus_list )
__dev_sort_resources ( dev , & head ) ;
2011-07-26 00:08:42 +04:00
__assign_resources_sorted ( & head , realloc_head , fail_head ) ;
2010-01-22 12:02:25 +03:00
}
2005-09-10 00:03:23 +04:00
void pci_setup_cardbus ( struct pci_bus * bus )
2005-04-17 02:20:36 +04:00
{
struct pci_dev * bridge = bus - > self ;
2009-10-27 22:26:47 +03:00
struct resource * res ;
2005-04-17 02:20:36 +04:00
struct pci_bus_region region ;
2018-01-18 21:55:24 +03:00
pci_info ( bridge , " CardBus bridge to %pR \n " ,
2012-05-18 05:51:11 +04:00
& bus - > busn_res ) ;
2005-04-17 02:20:36 +04:00
2009-10-27 22:26:47 +03:00
res = bus - > resource [ 0 ] ;
PCI: Convert pcibios_resource_to_bus() to take a pci_bus, not a pci_dev
These interfaces:
pcibios_resource_to_bus(struct pci_dev *dev, *bus_region, *resource)
pcibios_bus_to_resource(struct pci_dev *dev, *resource, *bus_region)
took a pci_dev, but they really depend only on the pci_bus. And we want to
use them in resource allocation paths where we have the bus but not a
device, so this patch converts them to take the pci_bus instead of the
pci_dev:
pcibios_resource_to_bus(struct pci_bus *bus, *bus_region, *resource)
pcibios_bus_to_resource(struct pci_bus *bus, *resource, *bus_region)
In fact, with standard PCI-PCI bridges, they only depend on the host
bridge, because that's the only place address translation occurs, but
we aren't going that far yet.
[bhelgaas: changelog]
Signed-off-by: Yinghai Lu <yinghai@kernel.org>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
2013-12-10 10:54:40 +04:00
pcibios_resource_to_bus ( bridge - > bus , & region , res ) ;
2009-10-27 22:26:47 +03:00
if ( res - > flags & IORESOURCE_IO ) {
2005-04-17 02:20:36 +04:00
/*
* The IO resource is allocated a range twice as large as it
* would normally need . This allows us to set both IO regs .
*/
2018-01-18 21:55:24 +03:00
pci_info ( bridge , " bridge window %pR \n " , res ) ;
2005-04-17 02:20:36 +04:00
pci_write_config_dword ( bridge , PCI_CB_IO_BASE_0 ,
region . start ) ;
pci_write_config_dword ( bridge , PCI_CB_IO_LIMIT_0 ,
region . end ) ;
}
2009-10-27 22:26:47 +03:00
res = bus - > resource [ 1 ] ;
PCI: Convert pcibios_resource_to_bus() to take a pci_bus, not a pci_dev
These interfaces:
pcibios_resource_to_bus(struct pci_dev *dev, *bus_region, *resource)
pcibios_bus_to_resource(struct pci_dev *dev, *resource, *bus_region)
took a pci_dev, but they really depend only on the pci_bus. And we want to
use them in resource allocation paths where we have the bus but not a
device, so this patch converts them to take the pci_bus instead of the
pci_dev:
pcibios_resource_to_bus(struct pci_bus *bus, *bus_region, *resource)
pcibios_bus_to_resource(struct pci_bus *bus, *resource, *bus_region)
In fact, with standard PCI-PCI bridges, they only depend on the host
bridge, because that's the only place address translation occurs, but
we aren't going that far yet.
[bhelgaas: changelog]
Signed-off-by: Yinghai Lu <yinghai@kernel.org>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
2013-12-10 10:54:40 +04:00
pcibios_resource_to_bus ( bridge - > bus , & region , res ) ;
2009-10-27 22:26:47 +03:00
if ( res - > flags & IORESOURCE_IO ) {
2018-01-18 21:55:24 +03:00
pci_info ( bridge , " bridge window %pR \n " , res ) ;
2005-04-17 02:20:36 +04:00
pci_write_config_dword ( bridge , PCI_CB_IO_BASE_1 ,
region . start ) ;
pci_write_config_dword ( bridge , PCI_CB_IO_LIMIT_1 ,
region . end ) ;
}
2009-10-27 22:26:47 +03:00
res = bus - > resource [ 2 ] ;
PCI: Convert pcibios_resource_to_bus() to take a pci_bus, not a pci_dev
These interfaces:
pcibios_resource_to_bus(struct pci_dev *dev, *bus_region, *resource)
pcibios_bus_to_resource(struct pci_dev *dev, *resource, *bus_region)
took a pci_dev, but they really depend only on the pci_bus. And we want to
use them in resource allocation paths where we have the bus but not a
device, so this patch converts them to take the pci_bus instead of the
pci_dev:
pcibios_resource_to_bus(struct pci_bus *bus, *bus_region, *resource)
pcibios_bus_to_resource(struct pci_bus *bus, *resource, *bus_region)
In fact, with standard PCI-PCI bridges, they only depend on the host
bridge, because that's the only place address translation occurs, but
we aren't going that far yet.
[bhelgaas: changelog]
Signed-off-by: Yinghai Lu <yinghai@kernel.org>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
2013-12-10 10:54:40 +04:00
pcibios_resource_to_bus ( bridge - > bus , & region , res ) ;
2009-10-27 22:26:47 +03:00
if ( res - > flags & IORESOURCE_MEM ) {
2018-01-18 21:55:24 +03:00
pci_info ( bridge , " bridge window %pR \n " , res ) ;
2005-04-17 02:20:36 +04:00
pci_write_config_dword ( bridge , PCI_CB_MEMORY_BASE_0 ,
region . start ) ;
pci_write_config_dword ( bridge , PCI_CB_MEMORY_LIMIT_0 ,
region . end ) ;
}
2009-10-27 22:26:47 +03:00
res = bus - > resource [ 3 ] ;
PCI: Convert pcibios_resource_to_bus() to take a pci_bus, not a pci_dev
These interfaces:
pcibios_resource_to_bus(struct pci_dev *dev, *bus_region, *resource)
pcibios_bus_to_resource(struct pci_dev *dev, *resource, *bus_region)
took a pci_dev, but they really depend only on the pci_bus. And we want to
use them in resource allocation paths where we have the bus but not a
device, so this patch converts them to take the pci_bus instead of the
pci_dev:
pcibios_resource_to_bus(struct pci_bus *bus, *bus_region, *resource)
pcibios_bus_to_resource(struct pci_bus *bus, *resource, *bus_region)
In fact, with standard PCI-PCI bridges, they only depend on the host
bridge, because that's the only place address translation occurs, but
we aren't going that far yet.
[bhelgaas: changelog]
Signed-off-by: Yinghai Lu <yinghai@kernel.org>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
2013-12-10 10:54:40 +04:00
pcibios_resource_to_bus ( bridge - > bus , & region , res ) ;
2009-10-27 22:26:47 +03:00
if ( res - > flags & IORESOURCE_MEM ) {
2018-01-18 21:55:24 +03:00
pci_info ( bridge , " bridge window %pR \n " , res ) ;
2005-04-17 02:20:36 +04:00
pci_write_config_dword ( bridge , PCI_CB_MEMORY_BASE_1 ,
region . start ) ;
pci_write_config_dword ( bridge , PCI_CB_MEMORY_LIMIT_1 ,
region . end ) ;
}
}
2005-09-10 00:03:23 +04:00
EXPORT_SYMBOL ( pci_setup_cardbus ) ;
2005-04-17 02:20:36 +04:00
2019-05-07 22:51:24 +03:00
/*
* Initialize bridges with base / limit values we have collected . PCI - to - PCI
* Bridge Architecture Specification rev . 1.1 ( 1998 ) requires that if there
* are no I / O ports or memory behind the bridge , the corresponding range
* must be turned off by writing base value greater than limit to the
* bridge ' s base / limit registers .
*
* Note : care must be taken when updating I / O base / limit registers of
* bridges which support 32 - bit I / O . This update requires two config space
* writes , so it ' s quite possible that an I / O window of the bridge will
* have some undesirable address ( e . g . 0 ) after the first write . Ditto
* 64 - bit prefetchable MMIO .
*/
2015-01-15 19:22:31 +03:00
static void pci_setup_bridge_io ( struct pci_dev * bridge )
2005-04-17 02:20:36 +04:00
{
2009-10-27 22:26:47 +03:00
struct resource * res ;
2005-04-17 02:20:36 +04:00
struct pci_bus_region region ;
2012-07-09 23:38:57 +04:00
unsigned long io_mask ;
u8 io_base_lo , io_limit_lo ;
2013-11-28 04:24:50 +04:00
u16 l ;
u32 io_upper16 ;
2005-04-17 02:20:36 +04:00
2012-07-09 23:38:57 +04:00
io_mask = PCI_IO_RANGE_MASK ;
if ( bridge - > io_window_1k )
io_mask = PCI_IO_1K_RANGE_MASK ;
2019-05-07 22:51:24 +03:00
/* Set up the top and bottom of the PCI I/O segment for this bus */
2020-05-20 21:34:10 +03:00
res = & bridge - > resource [ PCI_BRIDGE_IO_WINDOW ] ;
PCI: Convert pcibios_resource_to_bus() to take a pci_bus, not a pci_dev
These interfaces:
pcibios_resource_to_bus(struct pci_dev *dev, *bus_region, *resource)
pcibios_bus_to_resource(struct pci_dev *dev, *resource, *bus_region)
took a pci_dev, but they really depend only on the pci_bus. And we want to
use them in resource allocation paths where we have the bus but not a
device, so this patch converts them to take the pci_bus instead of the
pci_dev:
pcibios_resource_to_bus(struct pci_bus *bus, *bus_region, *resource)
pcibios_bus_to_resource(struct pci_bus *bus, *resource, *bus_region)
In fact, with standard PCI-PCI bridges, they only depend on the host
bridge, because that's the only place address translation occurs, but
we aren't going that far yet.
[bhelgaas: changelog]
Signed-off-by: Yinghai Lu <yinghai@kernel.org>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
2013-12-10 10:54:40 +04:00
pcibios_resource_to_bus ( bridge - > bus , & region , res ) ;
2009-10-27 22:26:47 +03:00
if ( res - > flags & IORESOURCE_IO ) {
2013-11-28 04:24:50 +04:00
pci_read_config_word ( bridge , PCI_IO_BASE , & l ) ;
2012-07-09 23:38:57 +04:00
io_base_lo = ( region . start > > 8 ) & io_mask ;
io_limit_lo = ( region . end > > 8 ) & io_mask ;
2013-11-28 04:24:50 +04:00
l = ( ( u16 ) io_limit_lo < < 8 ) | io_base_lo ;
2019-05-07 22:51:24 +03:00
/* Set up upper 16 bits of I/O base/limit */
2005-04-17 02:20:36 +04:00
io_upper16 = ( region . end & 0xffff0000 ) | ( region . start > > 16 ) ;
2018-01-18 21:55:24 +03:00
pci_info ( bridge , " bridge window %pR \n " , res ) ;
2009-12-23 02:02:21 +03:00
} else {
2019-05-07 22:51:24 +03:00
/* Clear upper 16 bits of I/O base/limit */
2005-04-17 02:20:36 +04:00
io_upper16 = 0 ;
l = 0x00f0 ;
}
2019-05-07 22:51:24 +03:00
/* Temporarily disable the I/O range before updating PCI_IO_BASE */
2005-04-17 02:20:36 +04:00
pci_write_config_dword ( bridge , PCI_IO_BASE_UPPER16 , 0x0000ffff ) ;
2019-05-07 22:51:24 +03:00
/* Update lower 16 bits of I/O base/limit */
2013-11-28 04:24:50 +04:00
pci_write_config_word ( bridge , PCI_IO_BASE , l ) ;
2019-05-07 22:51:24 +03:00
/* Update upper 16 bits of I/O base/limit */
2005-04-17 02:20:36 +04:00
pci_write_config_dword ( bridge , PCI_IO_BASE_UPPER16 , io_upper16 ) ;
2009-12-23 02:02:21 +03:00
}
2015-01-15 19:22:31 +03:00
static void pci_setup_bridge_mmio ( struct pci_dev * bridge )
2009-12-23 02:02:21 +03:00
{
struct resource * res ;
struct pci_bus_region region ;
u32 l ;
2005-04-17 02:20:36 +04:00
2019-05-07 22:51:24 +03:00
/* Set up the top and bottom of the PCI Memory segment for this bus */
2020-05-20 21:34:10 +03:00
res = & bridge - > resource [ PCI_BRIDGE_MEM_WINDOW ] ;
PCI: Convert pcibios_resource_to_bus() to take a pci_bus, not a pci_dev
These interfaces:
pcibios_resource_to_bus(struct pci_dev *dev, *bus_region, *resource)
pcibios_bus_to_resource(struct pci_dev *dev, *resource, *bus_region)
took a pci_dev, but they really depend only on the pci_bus. And we want to
use them in resource allocation paths where we have the bus but not a
device, so this patch converts them to take the pci_bus instead of the
pci_dev:
pcibios_resource_to_bus(struct pci_bus *bus, *bus_region, *resource)
pcibios_bus_to_resource(struct pci_bus *bus, *resource, *bus_region)
In fact, with standard PCI-PCI bridges, they only depend on the host
bridge, because that's the only place address translation occurs, but
we aren't going that far yet.
[bhelgaas: changelog]
Signed-off-by: Yinghai Lu <yinghai@kernel.org>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
2013-12-10 10:54:40 +04:00
pcibios_resource_to_bus ( bridge - > bus , & region , res ) ;
2009-10-27 22:26:47 +03:00
if ( res - > flags & IORESOURCE_MEM ) {
2005-04-17 02:20:36 +04:00
l = ( region . start > > 16 ) & 0xfff0 ;
l | = region . end & 0xfff00000 ;
2018-01-18 21:55:24 +03:00
pci_info ( bridge , " bridge window %pR \n " , res ) ;
2009-12-23 02:02:21 +03:00
} else {
2005-04-17 02:20:36 +04:00
l = 0x0000fff0 ;
}
pci_write_config_dword ( bridge , PCI_MEMORY_BASE , l ) ;
2009-12-23 02:02:21 +03:00
}
2015-01-15 19:22:31 +03:00
static void pci_setup_bridge_mmio_pref ( struct pci_dev * bridge )
2009-12-23 02:02:21 +03:00
{
struct resource * res ;
struct pci_bus_region region ;
u32 l , bu , lu ;
2005-04-17 02:20:36 +04:00
2019-05-07 22:51:24 +03:00
/*
* Clear out the upper 32 bits of PREF limit . If
* PCI_PREF_BASE_UPPER32 was non - zero , this temporarily disables
* PREF range , which is ok .
*/
2005-04-17 02:20:36 +04:00
pci_write_config_dword ( bridge , PCI_PREF_LIMIT_UPPER32 , 0 ) ;
2019-05-07 22:51:24 +03:00
/* Set up PREF base/limit */
2007-12-10 09:32:15 +03:00
bu = lu = 0 ;
2020-05-20 21:34:10 +03:00
res = & bridge - > resource [ PCI_BRIDGE_PREF_MEM_WINDOW ] ;
PCI: Convert pcibios_resource_to_bus() to take a pci_bus, not a pci_dev
These interfaces:
pcibios_resource_to_bus(struct pci_dev *dev, *bus_region, *resource)
pcibios_bus_to_resource(struct pci_dev *dev, *resource, *bus_region)
took a pci_dev, but they really depend only on the pci_bus. And we want to
use them in resource allocation paths where we have the bus but not a
device, so this patch converts them to take the pci_bus instead of the
pci_dev:
pcibios_resource_to_bus(struct pci_bus *bus, *bus_region, *resource)
pcibios_bus_to_resource(struct pci_bus *bus, *resource, *bus_region)
In fact, with standard PCI-PCI bridges, they only depend on the host
bridge, because that's the only place address translation occurs, but
we aren't going that far yet.
[bhelgaas: changelog]
Signed-off-by: Yinghai Lu <yinghai@kernel.org>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
2013-12-10 10:54:40 +04:00
pcibios_resource_to_bus ( bridge - > bus , & region , res ) ;
2009-10-27 22:26:47 +03:00
if ( res - > flags & IORESOURCE_PREFETCH ) {
2005-04-17 02:20:36 +04:00
l = ( region . start > > 16 ) & 0xfff0 ;
l | = region . end & 0xfff00000 ;
2009-10-27 22:26:47 +03:00
if ( res - > flags & IORESOURCE_MEM_64 ) {
2009-04-24 07:48:32 +04:00
bu = upper_32_bits ( region . start ) ;
lu = upper_32_bits ( region . end ) ;
}
2018-01-18 21:55:24 +03:00
pci_info ( bridge , " bridge window %pR \n " , res ) ;
2009-12-23 02:02:21 +03:00
} else {
2005-04-17 02:20:36 +04:00
l = 0x0000fff0 ;
}
pci_write_config_dword ( bridge , PCI_PREF_MEMORY_BASE , l ) ;
2019-05-07 22:51:24 +03:00
/* Set the upper 32 bits of PREF base & limit */
2009-12-01 00:51:44 +03:00
pci_write_config_dword ( bridge , PCI_PREF_BASE_UPPER32 , bu ) ;
pci_write_config_dword ( bridge , PCI_PREF_LIMIT_UPPER32 , lu ) ;
2009-12-23 02:02:21 +03:00
}
static void __pci_setup_bridge ( struct pci_bus * bus , unsigned long type )
{
struct pci_dev * bridge = bus - > self ;
2018-01-18 21:55:24 +03:00
pci_info ( bridge , " PCI bridge to %pR \n " ,
2012-05-18 05:51:11 +04:00
& bus - > busn_res ) ;
2009-12-23 02:02:21 +03:00
if ( type & IORESOURCE_IO )
2015-01-15 19:22:31 +03:00
pci_setup_bridge_io ( bridge ) ;
2009-12-23 02:02:21 +03:00
if ( type & IORESOURCE_MEM )
2015-01-15 19:22:31 +03:00
pci_setup_bridge_mmio ( bridge ) ;
2009-12-23 02:02:21 +03:00
if ( type & IORESOURCE_PREFETCH )
2015-01-15 19:22:31 +03:00
pci_setup_bridge_mmio_pref ( bridge ) ;
2005-04-17 02:20:36 +04:00
pci_write_config_word ( bridge , PCI_BRIDGE_CONTROL , bus - > bridge_ctl ) ;
}
2016-05-20 09:41:25 +03:00
void __weak pcibios_setup_bridge ( struct pci_bus * bus , unsigned long type )
{
}
2011-09-11 21:08:38 +04:00
void pci_setup_bridge ( struct pci_bus * bus )
2009-12-23 02:02:21 +03:00
{
unsigned long type = IORESOURCE_IO | IORESOURCE_MEM |
IORESOURCE_PREFETCH ;
2016-05-20 09:41:25 +03:00
pcibios_setup_bridge ( bus , type ) ;
2009-12-23 02:02:21 +03:00
__pci_setup_bridge ( bus , type ) ;
}
PCI: Add pci_claim_bridge_resource() to clip window if necessary
Add pci_claim_bridge_resource() to claim a PCI-PCI bridge window. This is
like regular pci_claim_resource(), except that if we fail to claim the
window, we check to see if we can reduce the size of the window and try
again.
This is for scenarios like this:
pci_bus 0000:00: root bus resource [mem 0xc0000000-0xffffffff]
pci 0000:00:01.0: bridge window [mem 0xbdf00000-0xddefffff 64bit pref]
pci 0000:01:00.0: reg 0x10: [mem 0xc0000000-0xcfffffff pref]
The 00:01.0 window is illegal: it starts before the host bridge window, so
we have to assume the [0xbdf00000-0xbfffffff] region is inaccessible. We
can make it legal by clipping it to [mem 0xc0000000-0xddefffff 64bit pref].
Previously we discarded the 00:01.0 window and tried to reassign that part
of the hierarchy from scratch. That is a problem because Linux doesn't
always assign things optimally. For example, in this case, BIOS put the
01:00.0 device in a prefetchable window below 4GB, but after 5b28541552ef,
Linux puts the prefetchable window above 4GB where the 32-bit 01:00.0
device can't use it.
Clipping the 00:01.0 window is less intrusive than completely reassigning
things and is sufficient to let us use most of the BIOS configuration. Of
course, it's possible that devices below 00:01.0 will no longer fit. If
that's the case, we'll have to reassign things. But that's a separate
problem.
[bhelgaas: changelog, split into separate patch]
Link: https://bugzilla.kernel.org/show_bug.cgi?id=85491
Reported-by: Marek Kordik <kordikmarek@gmail.com>
Fixes: 5b28541552ef ("PCI: Restrict 64-bit prefetchable bridge windows to 64-bit resources")
Signed-off-by: Yinghai Lu <yinghai@kernel.org>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
CC: stable@vger.kernel.org # v3.16+
2015-01-16 01:21:49 +03:00
int pci_claim_bridge_resource ( struct pci_dev * bridge , int i )
{
if ( i < PCI_BRIDGE_RESOURCES | | i > PCI_BRIDGE_RESOURCE_END )
return 0 ;
if ( pci_claim_resource ( bridge , i ) = = 0 )
2019-05-07 22:51:24 +03:00
return 0 ; /* Claimed the window */
PCI: Add pci_claim_bridge_resource() to clip window if necessary
Add pci_claim_bridge_resource() to claim a PCI-PCI bridge window. This is
like regular pci_claim_resource(), except that if we fail to claim the
window, we check to see if we can reduce the size of the window and try
again.
This is for scenarios like this:
pci_bus 0000:00: root bus resource [mem 0xc0000000-0xffffffff]
pci 0000:00:01.0: bridge window [mem 0xbdf00000-0xddefffff 64bit pref]
pci 0000:01:00.0: reg 0x10: [mem 0xc0000000-0xcfffffff pref]
The 00:01.0 window is illegal: it starts before the host bridge window, so
we have to assume the [0xbdf00000-0xbfffffff] region is inaccessible. We
can make it legal by clipping it to [mem 0xc0000000-0xddefffff 64bit pref].
Previously we discarded the 00:01.0 window and tried to reassign that part
of the hierarchy from scratch. That is a problem because Linux doesn't
always assign things optimally. For example, in this case, BIOS put the
01:00.0 device in a prefetchable window below 4GB, but after 5b28541552ef,
Linux puts the prefetchable window above 4GB where the 32-bit 01:00.0
device can't use it.
Clipping the 00:01.0 window is less intrusive than completely reassigning
things and is sufficient to let us use most of the BIOS configuration. Of
course, it's possible that devices below 00:01.0 will no longer fit. If
that's the case, we'll have to reassign things. But that's a separate
problem.
[bhelgaas: changelog, split into separate patch]
Link: https://bugzilla.kernel.org/show_bug.cgi?id=85491
Reported-by: Marek Kordik <kordikmarek@gmail.com>
Fixes: 5b28541552ef ("PCI: Restrict 64-bit prefetchable bridge windows to 64-bit resources")
Signed-off-by: Yinghai Lu <yinghai@kernel.org>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
CC: stable@vger.kernel.org # v3.16+
2015-01-16 01:21:49 +03:00
if ( ( bridge - > class > > 8 ) ! = PCI_CLASS_BRIDGE_PCI )
return 0 ;
if ( ! pci_bus_clip_resource ( bridge , i ) )
2019-05-07 22:51:24 +03:00
return - EINVAL ; /* Clipping didn't change anything */
PCI: Add pci_claim_bridge_resource() to clip window if necessary
Add pci_claim_bridge_resource() to claim a PCI-PCI bridge window. This is
like regular pci_claim_resource(), except that if we fail to claim the
window, we check to see if we can reduce the size of the window and try
again.
This is for scenarios like this:
pci_bus 0000:00: root bus resource [mem 0xc0000000-0xffffffff]
pci 0000:00:01.0: bridge window [mem 0xbdf00000-0xddefffff 64bit pref]
pci 0000:01:00.0: reg 0x10: [mem 0xc0000000-0xcfffffff pref]
The 00:01.0 window is illegal: it starts before the host bridge window, so
we have to assume the [0xbdf00000-0xbfffffff] region is inaccessible. We
can make it legal by clipping it to [mem 0xc0000000-0xddefffff 64bit pref].
Previously we discarded the 00:01.0 window and tried to reassign that part
of the hierarchy from scratch. That is a problem because Linux doesn't
always assign things optimally. For example, in this case, BIOS put the
01:00.0 device in a prefetchable window below 4GB, but after 5b28541552ef,
Linux puts the prefetchable window above 4GB where the 32-bit 01:00.0
device can't use it.
Clipping the 00:01.0 window is less intrusive than completely reassigning
things and is sufficient to let us use most of the BIOS configuration. Of
course, it's possible that devices below 00:01.0 will no longer fit. If
that's the case, we'll have to reassign things. But that's a separate
problem.
[bhelgaas: changelog, split into separate patch]
Link: https://bugzilla.kernel.org/show_bug.cgi?id=85491
Reported-by: Marek Kordik <kordikmarek@gmail.com>
Fixes: 5b28541552ef ("PCI: Restrict 64-bit prefetchable bridge windows to 64-bit resources")
Signed-off-by: Yinghai Lu <yinghai@kernel.org>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
CC: stable@vger.kernel.org # v3.16+
2015-01-16 01:21:49 +03:00
2020-05-20 21:34:10 +03:00
switch ( i ) {
case PCI_BRIDGE_IO_WINDOW :
PCI: Add pci_claim_bridge_resource() to clip window if necessary
Add pci_claim_bridge_resource() to claim a PCI-PCI bridge window. This is
like regular pci_claim_resource(), except that if we fail to claim the
window, we check to see if we can reduce the size of the window and try
again.
This is for scenarios like this:
pci_bus 0000:00: root bus resource [mem 0xc0000000-0xffffffff]
pci 0000:00:01.0: bridge window [mem 0xbdf00000-0xddefffff 64bit pref]
pci 0000:01:00.0: reg 0x10: [mem 0xc0000000-0xcfffffff pref]
The 00:01.0 window is illegal: it starts before the host bridge window, so
we have to assume the [0xbdf00000-0xbfffffff] region is inaccessible. We
can make it legal by clipping it to [mem 0xc0000000-0xddefffff 64bit pref].
Previously we discarded the 00:01.0 window and tried to reassign that part
of the hierarchy from scratch. That is a problem because Linux doesn't
always assign things optimally. For example, in this case, BIOS put the
01:00.0 device in a prefetchable window below 4GB, but after 5b28541552ef,
Linux puts the prefetchable window above 4GB where the 32-bit 01:00.0
device can't use it.
Clipping the 00:01.0 window is less intrusive than completely reassigning
things and is sufficient to let us use most of the BIOS configuration. Of
course, it's possible that devices below 00:01.0 will no longer fit. If
that's the case, we'll have to reassign things. But that's a separate
problem.
[bhelgaas: changelog, split into separate patch]
Link: https://bugzilla.kernel.org/show_bug.cgi?id=85491
Reported-by: Marek Kordik <kordikmarek@gmail.com>
Fixes: 5b28541552ef ("PCI: Restrict 64-bit prefetchable bridge windows to 64-bit resources")
Signed-off-by: Yinghai Lu <yinghai@kernel.org>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
CC: stable@vger.kernel.org # v3.16+
2015-01-16 01:21:49 +03:00
pci_setup_bridge_io ( bridge ) ;
break ;
2020-05-20 21:34:10 +03:00
case PCI_BRIDGE_MEM_WINDOW :
PCI: Add pci_claim_bridge_resource() to clip window if necessary
Add pci_claim_bridge_resource() to claim a PCI-PCI bridge window. This is
like regular pci_claim_resource(), except that if we fail to claim the
window, we check to see if we can reduce the size of the window and try
again.
This is for scenarios like this:
pci_bus 0000:00: root bus resource [mem 0xc0000000-0xffffffff]
pci 0000:00:01.0: bridge window [mem 0xbdf00000-0xddefffff 64bit pref]
pci 0000:01:00.0: reg 0x10: [mem 0xc0000000-0xcfffffff pref]
The 00:01.0 window is illegal: it starts before the host bridge window, so
we have to assume the [0xbdf00000-0xbfffffff] region is inaccessible. We
can make it legal by clipping it to [mem 0xc0000000-0xddefffff 64bit pref].
Previously we discarded the 00:01.0 window and tried to reassign that part
of the hierarchy from scratch. That is a problem because Linux doesn't
always assign things optimally. For example, in this case, BIOS put the
01:00.0 device in a prefetchable window below 4GB, but after 5b28541552ef,
Linux puts the prefetchable window above 4GB where the 32-bit 01:00.0
device can't use it.
Clipping the 00:01.0 window is less intrusive than completely reassigning
things and is sufficient to let us use most of the BIOS configuration. Of
course, it's possible that devices below 00:01.0 will no longer fit. If
that's the case, we'll have to reassign things. But that's a separate
problem.
[bhelgaas: changelog, split into separate patch]
Link: https://bugzilla.kernel.org/show_bug.cgi?id=85491
Reported-by: Marek Kordik <kordikmarek@gmail.com>
Fixes: 5b28541552ef ("PCI: Restrict 64-bit prefetchable bridge windows to 64-bit resources")
Signed-off-by: Yinghai Lu <yinghai@kernel.org>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
CC: stable@vger.kernel.org # v3.16+
2015-01-16 01:21:49 +03:00
pci_setup_bridge_mmio ( bridge ) ;
break ;
2020-05-20 21:34:10 +03:00
case PCI_BRIDGE_PREF_MEM_WINDOW :
PCI: Add pci_claim_bridge_resource() to clip window if necessary
Add pci_claim_bridge_resource() to claim a PCI-PCI bridge window. This is
like regular pci_claim_resource(), except that if we fail to claim the
window, we check to see if we can reduce the size of the window and try
again.
This is for scenarios like this:
pci_bus 0000:00: root bus resource [mem 0xc0000000-0xffffffff]
pci 0000:00:01.0: bridge window [mem 0xbdf00000-0xddefffff 64bit pref]
pci 0000:01:00.0: reg 0x10: [mem 0xc0000000-0xcfffffff pref]
The 00:01.0 window is illegal: it starts before the host bridge window, so
we have to assume the [0xbdf00000-0xbfffffff] region is inaccessible. We
can make it legal by clipping it to [mem 0xc0000000-0xddefffff 64bit pref].
Previously we discarded the 00:01.0 window and tried to reassign that part
of the hierarchy from scratch. That is a problem because Linux doesn't
always assign things optimally. For example, in this case, BIOS put the
01:00.0 device in a prefetchable window below 4GB, but after 5b28541552ef,
Linux puts the prefetchable window above 4GB where the 32-bit 01:00.0
device can't use it.
Clipping the 00:01.0 window is less intrusive than completely reassigning
things and is sufficient to let us use most of the BIOS configuration. Of
course, it's possible that devices below 00:01.0 will no longer fit. If
that's the case, we'll have to reassign things. But that's a separate
problem.
[bhelgaas: changelog, split into separate patch]
Link: https://bugzilla.kernel.org/show_bug.cgi?id=85491
Reported-by: Marek Kordik <kordikmarek@gmail.com>
Fixes: 5b28541552ef ("PCI: Restrict 64-bit prefetchable bridge windows to 64-bit resources")
Signed-off-by: Yinghai Lu <yinghai@kernel.org>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
CC: stable@vger.kernel.org # v3.16+
2015-01-16 01:21:49 +03:00
pci_setup_bridge_mmio_pref ( bridge ) ;
break ;
default :
return - EINVAL ;
}
if ( pci_claim_resource ( bridge , i ) = = 0 )
2019-05-07 22:51:24 +03:00
return 0 ; /* Claimed a smaller window */
PCI: Add pci_claim_bridge_resource() to clip window if necessary
Add pci_claim_bridge_resource() to claim a PCI-PCI bridge window. This is
like regular pci_claim_resource(), except that if we fail to claim the
window, we check to see if we can reduce the size of the window and try
again.
This is for scenarios like this:
pci_bus 0000:00: root bus resource [mem 0xc0000000-0xffffffff]
pci 0000:00:01.0: bridge window [mem 0xbdf00000-0xddefffff 64bit pref]
pci 0000:01:00.0: reg 0x10: [mem 0xc0000000-0xcfffffff pref]
The 00:01.0 window is illegal: it starts before the host bridge window, so
we have to assume the [0xbdf00000-0xbfffffff] region is inaccessible. We
can make it legal by clipping it to [mem 0xc0000000-0xddefffff 64bit pref].
Previously we discarded the 00:01.0 window and tried to reassign that part
of the hierarchy from scratch. That is a problem because Linux doesn't
always assign things optimally. For example, in this case, BIOS put the
01:00.0 device in a prefetchable window below 4GB, but after 5b28541552ef,
Linux puts the prefetchable window above 4GB where the 32-bit 01:00.0
device can't use it.
Clipping the 00:01.0 window is less intrusive than completely reassigning
things and is sufficient to let us use most of the BIOS configuration. Of
course, it's possible that devices below 00:01.0 will no longer fit. If
that's the case, we'll have to reassign things. But that's a separate
problem.
[bhelgaas: changelog, split into separate patch]
Link: https://bugzilla.kernel.org/show_bug.cgi?id=85491
Reported-by: Marek Kordik <kordikmarek@gmail.com>
Fixes: 5b28541552ef ("PCI: Restrict 64-bit prefetchable bridge windows to 64-bit resources")
Signed-off-by: Yinghai Lu <yinghai@kernel.org>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
CC: stable@vger.kernel.org # v3.16+
2015-01-16 01:21:49 +03:00
return - EINVAL ;
}
2019-05-07 22:51:24 +03:00
/*
* Check whether the bridge supports optional I / O and prefetchable memory
* ranges . If not , the respective base / limit registers must be read - only
* and read as 0.
*/
2007-03-27 09:53:30 +04:00
static void pci_bridge_check_ranges ( struct pci_bus * bus )
2005-04-17 02:20:36 +04:00
{
struct pci_dev * bridge = bus - > self ;
2020-05-20 21:34:10 +03:00
struct resource * b_res ;
2005-04-17 02:20:36 +04:00
2020-05-20 21:34:10 +03:00
b_res = & bridge - > resource [ PCI_BRIDGE_MEM_WINDOW ] ;
b_res - > flags | = IORESOURCE_MEM ;
2005-04-17 02:20:36 +04:00
2020-05-20 21:34:10 +03:00
if ( bridge - > io_window ) {
b_res = & bridge - > resource [ PCI_BRIDGE_IO_WINDOW ] ;
b_res - > flags | = IORESOURCE_IO ;
}
PCI: Prevent bus conflicts while checking for bridge apertures
pci_bridge_check_ranges() determines whether the bridge supports an I/O
aperture and a prefetchable memory aperture.
Previously, if the I/O aperture was unsupported, disabled, or configured at
[io 0x0000-0x0fff], we wrote 0xf0 to PCI_IO_BASE and PCI_IO_LIMIT, which,
if the bridge supports it, enables the I/O aperture at [io 0xf000-0xffff].
The enabled aperture may conflict with other devices in the system.
Similarly, we wrote 0xfff0 to PCI_PREF_MEMORY_BASE and
PCI_PREF_MEMORY_LIMIT, which enables the prefetchable memory aperture at
[mem 0xfff00000-0xffffffff], and that may also conflict with other devices.
All we need to know is whether the base and limit registers are writable,
so we can use values that leave the apertures disabled, e.g., PCI_IO_BASE =
0xf0, PCI_IO_LIMIT = 0xe0, PCI_PREF_MEMORY_BASE = 0xfff0,
PCI_PREF_MEMORY_LIMIT = 0xffe0.
Writing non-zero values to both the base and limit registers means we
detect whether either or both are writable, as we did before.
Reported-by: Jason Gunthorpe <jgunthorpe@obsidianresearch.com>
Based-on-patch-by: Jason Gunthorpe <jgunthorpe@obsidianresearch.com>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
2013-11-28 02:31:07 +04:00
2019-01-19 20:35:04 +03:00
if ( bridge - > pref_window ) {
2020-05-20 21:34:10 +03:00
b_res = & bridge - > resource [ PCI_BRIDGE_PREF_MEM_WINDOW ] ;
b_res - > flags | = IORESOURCE_MEM | IORESOURCE_PREFETCH ;
2019-01-19 20:35:04 +03:00
if ( bridge - > pref_64_window ) {
2020-05-20 21:34:10 +03:00
b_res - > flags | = IORESOURCE_MEM_64 |
PCI_PREF_RANGE_TYPE_64 ;
2010-01-22 12:02:28 +03:00
}
2009-04-24 07:48:32 +04:00
}
2005-04-17 02:20:36 +04:00
}
2019-05-07 22:51:24 +03:00
/*
PCI: Avoid double hpmemsize MMIO window assignment
Previously, the kernel sometimes assigned more MMIO or MMIO_PREF space than
desired. For example, if the user requested 128M of space with
"pci=realloc,hpmemsize=128M", we sometimes assigned 256M:
pci 0000:06:01.0: BAR 14: assigned [mem 0x90100000-0xa00fffff] = 256M
pci 0000:06:04.0: BAR 14: assigned [mem 0xa0200000-0xb01fffff] = 256M
With this patch applied:
pci 0000:06:01.0: BAR 14: assigned [mem 0x90100000-0x980fffff] = 128M
pci 0000:06:04.0: BAR 14: assigned [mem 0x98200000-0xa01fffff] = 128M
This happened when in the first pass, the MMIO_PREF succeeded but the MMIO
failed. In the next pass, because MMIO_PREF was already assigned, the
attempt to assign MMIO_PREF returned an error code instead of success
(nothing more to do, already allocated). Hence, the size which was actually
allocated, but thought to have failed, was placed in the MMIO window.
The bug resulted in the MMIO_PREF being added to the MMIO window, which
meant doubling if MMIO_PREF size = MMIO size. With a large MMIO_PREF, the
MMIO window would likely fail to be assigned altogether due to lack of
32-bit address space.
Change find_free_bus_resource() to do the following:
- Return first unassigned resource of the correct type.
- If there is none, return first assigned resource of the correct type.
- If none of the above, return NULL.
Returning an assigned resource of the correct type allows the caller to
distinguish between already assigned and no resource of the correct type.
Add checks in pbus_size_io() and pbus_size_mem() to return success if
resource returned from find_free_bus_resource() is already allocated.
This avoids pbus_size_io() and pbus_size_mem() returning error code to
__pci_bus_size_bridges() when a resource has been successfully assigned in
a previous pass. This fixes the existing behaviour where space for a
resource could be reserved multiple times in different parent bridge
windows.
Link: https://lore.kernel.org/lkml/20190531171216.20532-2-logang@deltatee.com/T/#u
Link: https://bugzilla.kernel.org/show_bug.cgi?id=203243
Link: https://lore.kernel.org/r/PS2P216MB075563AA6AD242AA666EDC6A80760@PS2P216MB0755.KORP216.PROD.OUTLOOK.COM
Reported-by: Kit Chow <kchow@gigaio.com>
Reported-by: Nicholas Johnson <nicholas.johnson-opensource@outlook.com.au>
Signed-off-by: Nicholas Johnson <nicholas.johnson-opensource@outlook.com.au>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Reviewed-by: Mika Westerberg <mika.westerberg@linux.intel.com>
Reviewed-by: Logan Gunthorpe <logang@deltatee.com>
2019-11-13 18:25:28 +03:00
* Helper function for sizing routines . Assigned resources have non - NULL
* parent resource .
*
* Return first unassigned resource of the correct type . If there is none ,
* return first assigned resource of the correct type . If none of the
* above , return NULL .
*
* Returning an assigned resource of the correct type allows the caller to
* distinguish between already assigned and no resource of the correct type .
2019-05-07 22:51:24 +03:00
*/
PCI: Avoid double hpmemsize MMIO window assignment
Previously, the kernel sometimes assigned more MMIO or MMIO_PREF space than
desired. For example, if the user requested 128M of space with
"pci=realloc,hpmemsize=128M", we sometimes assigned 256M:
pci 0000:06:01.0: BAR 14: assigned [mem 0x90100000-0xa00fffff] = 256M
pci 0000:06:04.0: BAR 14: assigned [mem 0xa0200000-0xb01fffff] = 256M
With this patch applied:
pci 0000:06:01.0: BAR 14: assigned [mem 0x90100000-0x980fffff] = 128M
pci 0000:06:04.0: BAR 14: assigned [mem 0x98200000-0xa01fffff] = 128M
This happened when in the first pass, the MMIO_PREF succeeded but the MMIO
failed. In the next pass, because MMIO_PREF was already assigned, the
attempt to assign MMIO_PREF returned an error code instead of success
(nothing more to do, already allocated). Hence, the size which was actually
allocated, but thought to have failed, was placed in the MMIO window.
The bug resulted in the MMIO_PREF being added to the MMIO window, which
meant doubling if MMIO_PREF size = MMIO size. With a large MMIO_PREF, the
MMIO window would likely fail to be assigned altogether due to lack of
32-bit address space.
Change find_free_bus_resource() to do the following:
- Return first unassigned resource of the correct type.
- If there is none, return first assigned resource of the correct type.
- If none of the above, return NULL.
Returning an assigned resource of the correct type allows the caller to
distinguish between already assigned and no resource of the correct type.
Add checks in pbus_size_io() and pbus_size_mem() to return success if
resource returned from find_free_bus_resource() is already allocated.
This avoids pbus_size_io() and pbus_size_mem() returning error code to
__pci_bus_size_bridges() when a resource has been successfully assigned in
a previous pass. This fixes the existing behaviour where space for a
resource could be reserved multiple times in different parent bridge
windows.
Link: https://lore.kernel.org/lkml/20190531171216.20532-2-logang@deltatee.com/T/#u
Link: https://bugzilla.kernel.org/show_bug.cgi?id=203243
Link: https://lore.kernel.org/r/PS2P216MB075563AA6AD242AA666EDC6A80760@PS2P216MB0755.KORP216.PROD.OUTLOOK.COM
Reported-by: Kit Chow <kchow@gigaio.com>
Reported-by: Nicholas Johnson <nicholas.johnson-opensource@outlook.com.au>
Signed-off-by: Nicholas Johnson <nicholas.johnson-opensource@outlook.com.au>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Reviewed-by: Mika Westerberg <mika.westerberg@linux.intel.com>
Reviewed-by: Logan Gunthorpe <logang@deltatee.com>
2019-11-13 18:25:28 +03:00
static struct resource * find_bus_resource_of_type ( struct pci_bus * bus ,
unsigned long type_mask ,
unsigned long type )
2005-04-17 02:20:36 +04:00
{
PCI: Avoid double hpmemsize MMIO window assignment
Previously, the kernel sometimes assigned more MMIO or MMIO_PREF space than
desired. For example, if the user requested 128M of space with
"pci=realloc,hpmemsize=128M", we sometimes assigned 256M:
pci 0000:06:01.0: BAR 14: assigned [mem 0x90100000-0xa00fffff] = 256M
pci 0000:06:04.0: BAR 14: assigned [mem 0xa0200000-0xb01fffff] = 256M
With this patch applied:
pci 0000:06:01.0: BAR 14: assigned [mem 0x90100000-0x980fffff] = 128M
pci 0000:06:04.0: BAR 14: assigned [mem 0x98200000-0xa01fffff] = 128M
This happened when in the first pass, the MMIO_PREF succeeded but the MMIO
failed. In the next pass, because MMIO_PREF was already assigned, the
attempt to assign MMIO_PREF returned an error code instead of success
(nothing more to do, already allocated). Hence, the size which was actually
allocated, but thought to have failed, was placed in the MMIO window.
The bug resulted in the MMIO_PREF being added to the MMIO window, which
meant doubling if MMIO_PREF size = MMIO size. With a large MMIO_PREF, the
MMIO window would likely fail to be assigned altogether due to lack of
32-bit address space.
Change find_free_bus_resource() to do the following:
- Return first unassigned resource of the correct type.
- If there is none, return first assigned resource of the correct type.
- If none of the above, return NULL.
Returning an assigned resource of the correct type allows the caller to
distinguish between already assigned and no resource of the correct type.
Add checks in pbus_size_io() and pbus_size_mem() to return success if
resource returned from find_free_bus_resource() is already allocated.
This avoids pbus_size_io() and pbus_size_mem() returning error code to
__pci_bus_size_bridges() when a resource has been successfully assigned in
a previous pass. This fixes the existing behaviour where space for a
resource could be reserved multiple times in different parent bridge
windows.
Link: https://lore.kernel.org/lkml/20190531171216.20532-2-logang@deltatee.com/T/#u
Link: https://bugzilla.kernel.org/show_bug.cgi?id=203243
Link: https://lore.kernel.org/r/PS2P216MB075563AA6AD242AA666EDC6A80760@PS2P216MB0755.KORP216.PROD.OUTLOOK.COM
Reported-by: Kit Chow <kchow@gigaio.com>
Reported-by: Nicholas Johnson <nicholas.johnson-opensource@outlook.com.au>
Signed-off-by: Nicholas Johnson <nicholas.johnson-opensource@outlook.com.au>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Reviewed-by: Mika Westerberg <mika.westerberg@linux.intel.com>
Reviewed-by: Logan Gunthorpe <logang@deltatee.com>
2019-11-13 18:25:28 +03:00
struct resource * r , * r_assigned = NULL ;
2005-04-17 02:20:36 +04:00
int i ;
2010-02-23 20:24:31 +03:00
pci_bus_for_each_resource ( bus , r , i ) {
2005-06-15 18:59:27 +04:00
if ( r = = & ioport_resource | | r = = & iomem_resource )
continue ;
2009-10-27 19:39:18 +03:00
if ( r & & ( r - > flags & type_mask ) = = type & & ! r - > parent )
return r ;
PCI: Avoid double hpmemsize MMIO window assignment
Previously, the kernel sometimes assigned more MMIO or MMIO_PREF space than
desired. For example, if the user requested 128M of space with
"pci=realloc,hpmemsize=128M", we sometimes assigned 256M:
pci 0000:06:01.0: BAR 14: assigned [mem 0x90100000-0xa00fffff] = 256M
pci 0000:06:04.0: BAR 14: assigned [mem 0xa0200000-0xb01fffff] = 256M
With this patch applied:
pci 0000:06:01.0: BAR 14: assigned [mem 0x90100000-0x980fffff] = 128M
pci 0000:06:04.0: BAR 14: assigned [mem 0x98200000-0xa01fffff] = 128M
This happened when in the first pass, the MMIO_PREF succeeded but the MMIO
failed. In the next pass, because MMIO_PREF was already assigned, the
attempt to assign MMIO_PREF returned an error code instead of success
(nothing more to do, already allocated). Hence, the size which was actually
allocated, but thought to have failed, was placed in the MMIO window.
The bug resulted in the MMIO_PREF being added to the MMIO window, which
meant doubling if MMIO_PREF size = MMIO size. With a large MMIO_PREF, the
MMIO window would likely fail to be assigned altogether due to lack of
32-bit address space.
Change find_free_bus_resource() to do the following:
- Return first unassigned resource of the correct type.
- If there is none, return first assigned resource of the correct type.
- If none of the above, return NULL.
Returning an assigned resource of the correct type allows the caller to
distinguish between already assigned and no resource of the correct type.
Add checks in pbus_size_io() and pbus_size_mem() to return success if
resource returned from find_free_bus_resource() is already allocated.
This avoids pbus_size_io() and pbus_size_mem() returning error code to
__pci_bus_size_bridges() when a resource has been successfully assigned in
a previous pass. This fixes the existing behaviour where space for a
resource could be reserved multiple times in different parent bridge
windows.
Link: https://lore.kernel.org/lkml/20190531171216.20532-2-logang@deltatee.com/T/#u
Link: https://bugzilla.kernel.org/show_bug.cgi?id=203243
Link: https://lore.kernel.org/r/PS2P216MB075563AA6AD242AA666EDC6A80760@PS2P216MB0755.KORP216.PROD.OUTLOOK.COM
Reported-by: Kit Chow <kchow@gigaio.com>
Reported-by: Nicholas Johnson <nicholas.johnson-opensource@outlook.com.au>
Signed-off-by: Nicholas Johnson <nicholas.johnson-opensource@outlook.com.au>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Reviewed-by: Mika Westerberg <mika.westerberg@linux.intel.com>
Reviewed-by: Logan Gunthorpe <logang@deltatee.com>
2019-11-13 18:25:28 +03:00
if ( r & & ( r - > flags & type_mask ) = = type & & ! r_assigned )
r_assigned = r ;
2005-04-17 02:20:36 +04:00
}
PCI: Avoid double hpmemsize MMIO window assignment
Previously, the kernel sometimes assigned more MMIO or MMIO_PREF space than
desired. For example, if the user requested 128M of space with
"pci=realloc,hpmemsize=128M", we sometimes assigned 256M:
pci 0000:06:01.0: BAR 14: assigned [mem 0x90100000-0xa00fffff] = 256M
pci 0000:06:04.0: BAR 14: assigned [mem 0xa0200000-0xb01fffff] = 256M
With this patch applied:
pci 0000:06:01.0: BAR 14: assigned [mem 0x90100000-0x980fffff] = 128M
pci 0000:06:04.0: BAR 14: assigned [mem 0x98200000-0xa01fffff] = 128M
This happened when in the first pass, the MMIO_PREF succeeded but the MMIO
failed. In the next pass, because MMIO_PREF was already assigned, the
attempt to assign MMIO_PREF returned an error code instead of success
(nothing more to do, already allocated). Hence, the size which was actually
allocated, but thought to have failed, was placed in the MMIO window.
The bug resulted in the MMIO_PREF being added to the MMIO window, which
meant doubling if MMIO_PREF size = MMIO size. With a large MMIO_PREF, the
MMIO window would likely fail to be assigned altogether due to lack of
32-bit address space.
Change find_free_bus_resource() to do the following:
- Return first unassigned resource of the correct type.
- If there is none, return first assigned resource of the correct type.
- If none of the above, return NULL.
Returning an assigned resource of the correct type allows the caller to
distinguish between already assigned and no resource of the correct type.
Add checks in pbus_size_io() and pbus_size_mem() to return success if
resource returned from find_free_bus_resource() is already allocated.
This avoids pbus_size_io() and pbus_size_mem() returning error code to
__pci_bus_size_bridges() when a resource has been successfully assigned in
a previous pass. This fixes the existing behaviour where space for a
resource could be reserved multiple times in different parent bridge
windows.
Link: https://lore.kernel.org/lkml/20190531171216.20532-2-logang@deltatee.com/T/#u
Link: https://bugzilla.kernel.org/show_bug.cgi?id=203243
Link: https://lore.kernel.org/r/PS2P216MB075563AA6AD242AA666EDC6A80760@PS2P216MB0755.KORP216.PROD.OUTLOOK.COM
Reported-by: Kit Chow <kchow@gigaio.com>
Reported-by: Nicholas Johnson <nicholas.johnson-opensource@outlook.com.au>
Signed-off-by: Nicholas Johnson <nicholas.johnson-opensource@outlook.com.au>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Reviewed-by: Mika Westerberg <mika.westerberg@linux.intel.com>
Reviewed-by: Logan Gunthorpe <logang@deltatee.com>
2019-11-13 18:25:28 +03:00
return r_assigned ;
2005-04-17 02:20:36 +04:00
}
2011-02-15 04:43:17 +03:00
static resource_size_t calculate_iosize ( resource_size_t size ,
2019-05-07 22:51:24 +03:00
resource_size_t min_size ,
resource_size_t size1 ,
resource_size_t add_size ,
resource_size_t children_add_size ,
resource_size_t old_size ,
resource_size_t align )
2011-02-15 04:43:17 +03:00
{
if ( size < min_size )
size = min_size ;
2014-04-19 04:13:49 +04:00
if ( old_size = = 1 )
2011-02-15 04:43:17 +03:00
old_size = 0 ;
2019-05-07 22:51:24 +03:00
/*
* To be fixed in 2.5 : we should have sort of HAVE_ISA flag in the
* struct pci_bus .
*/
2011-02-15 04:43:17 +03:00
# if defined(CONFIG_ISA) || defined(CONFIG_EISA)
size = ( size & 0xff ) + ( ( size & ~ 0xffUL ) < < 2 ) ;
# endif
2018-09-25 21:39:06 +03:00
size = size + size1 ;
2011-02-15 04:43:17 +03:00
if ( size < old_size )
size = old_size ;
2018-09-25 21:39:06 +03:00
size = ALIGN ( max ( size , add_size ) + children_add_size , align ) ;
2011-02-15 04:43:17 +03:00
return size ;
}
static resource_size_t calculate_memsize ( resource_size_t size ,
2019-05-07 22:51:24 +03:00
resource_size_t min_size ,
resource_size_t add_size ,
resource_size_t children_add_size ,
resource_size_t old_size ,
resource_size_t align )
2011-02-15 04:43:17 +03:00
{
if ( size < min_size )
size = min_size ;
2014-04-19 04:13:49 +04:00
if ( old_size = = 1 )
2011-02-15 04:43:17 +03:00
old_size = 0 ;
if ( size < old_size )
size = old_size ;
2018-09-25 21:39:06 +03:00
size = ALIGN ( max ( size , add_size ) + children_add_size , align ) ;
2011-02-15 04:43:17 +03:00
return size ;
}
2012-09-12 02:59:45 +04:00
resource_size_t __weak pcibios_window_alignment ( struct pci_bus * bus ,
unsigned long type )
{
return 1 ;
}
# define PCI_P2P_DEFAULT_MEM_ALIGN 0x100000 /* 1MiB */
# define PCI_P2P_DEFAULT_IO_ALIGN 0x1000 /* 4KiB */
# define PCI_P2P_DEFAULT_IO_ALIGN_1K 0x400 /* 1KiB */
2019-05-07 22:51:24 +03:00
static resource_size_t window_alignment ( struct pci_bus * bus , unsigned long type )
2012-09-12 02:59:45 +04:00
{
resource_size_t align = 1 , arch_align ;
if ( type & IORESOURCE_MEM )
align = PCI_P2P_DEFAULT_MEM_ALIGN ;
else if ( type & IORESOURCE_IO ) {
/*
2019-05-07 22:51:24 +03:00
* Per spec , I / O windows are 4 K - aligned , but some bridges have
* an extension to support 1 K alignment .
2012-09-12 02:59:45 +04:00
*/
2020-03-14 22:43:55 +03:00
if ( bus - > self & & bus - > self - > io_window_1k )
2012-09-12 02:59:45 +04:00
align = PCI_P2P_DEFAULT_IO_ALIGN_1K ;
else
align = PCI_P2P_DEFAULT_IO_ALIGN ;
}
arch_align = pcibios_window_alignment ( bus , type ) ;
return max ( align , arch_align ) ;
}
2011-02-15 04:43:20 +03:00
/**
2019-05-07 22:51:24 +03:00
* pbus_size_io ( ) - Size the I / O window of a given bus
2011-02-15 04:43:20 +03:00
*
2019-05-07 22:51:24 +03:00
* @ bus : The bus
* @ min_size : The minimum I / O window that must be allocated
* @ add_size : Additional optional I / O window
* @ realloc_head : Track the additional I / O window on this list
2011-02-15 04:43:20 +03:00
*
2019-05-07 22:51:24 +03:00
* Sizing the I / O windows of the PCI - PCI bridge is trivial , since these
* windows have 1 K or 4 K granularity and the I / O ranges of non - bridge PCI
* devices are limited to 256 bytes . We must be careful with the ISA
* aliasing though .
2011-02-15 04:43:20 +03:00
*/
static void pbus_size_io ( struct pci_bus * bus , resource_size_t min_size ,
2019-05-07 22:51:24 +03:00
resource_size_t add_size ,
struct list_head * realloc_head )
2005-04-17 02:20:36 +04:00
{
struct pci_dev * dev ;
PCI: Avoid double hpmemsize MMIO window assignment
Previously, the kernel sometimes assigned more MMIO or MMIO_PREF space than
desired. For example, if the user requested 128M of space with
"pci=realloc,hpmemsize=128M", we sometimes assigned 256M:
pci 0000:06:01.0: BAR 14: assigned [mem 0x90100000-0xa00fffff] = 256M
pci 0000:06:04.0: BAR 14: assigned [mem 0xa0200000-0xb01fffff] = 256M
With this patch applied:
pci 0000:06:01.0: BAR 14: assigned [mem 0x90100000-0x980fffff] = 128M
pci 0000:06:04.0: BAR 14: assigned [mem 0x98200000-0xa01fffff] = 128M
This happened when in the first pass, the MMIO_PREF succeeded but the MMIO
failed. In the next pass, because MMIO_PREF was already assigned, the
attempt to assign MMIO_PREF returned an error code instead of success
(nothing more to do, already allocated). Hence, the size which was actually
allocated, but thought to have failed, was placed in the MMIO window.
The bug resulted in the MMIO_PREF being added to the MMIO window, which
meant doubling if MMIO_PREF size = MMIO size. With a large MMIO_PREF, the
MMIO window would likely fail to be assigned altogether due to lack of
32-bit address space.
Change find_free_bus_resource() to do the following:
- Return first unassigned resource of the correct type.
- If there is none, return first assigned resource of the correct type.
- If none of the above, return NULL.
Returning an assigned resource of the correct type allows the caller to
distinguish between already assigned and no resource of the correct type.
Add checks in pbus_size_io() and pbus_size_mem() to return success if
resource returned from find_free_bus_resource() is already allocated.
This avoids pbus_size_io() and pbus_size_mem() returning error code to
__pci_bus_size_bridges() when a resource has been successfully assigned in
a previous pass. This fixes the existing behaviour where space for a
resource could be reserved multiple times in different parent bridge
windows.
Link: https://lore.kernel.org/lkml/20190531171216.20532-2-logang@deltatee.com/T/#u
Link: https://bugzilla.kernel.org/show_bug.cgi?id=203243
Link: https://lore.kernel.org/r/PS2P216MB075563AA6AD242AA666EDC6A80760@PS2P216MB0755.KORP216.PROD.OUTLOOK.COM
Reported-by: Kit Chow <kchow@gigaio.com>
Reported-by: Nicholas Johnson <nicholas.johnson-opensource@outlook.com.au>
Signed-off-by: Nicholas Johnson <nicholas.johnson-opensource@outlook.com.au>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Reviewed-by: Mika Westerberg <mika.westerberg@linux.intel.com>
Reviewed-by: Logan Gunthorpe <logang@deltatee.com>
2019-11-13 18:25:28 +03:00
struct resource * b_res = find_bus_resource_of_type ( bus , IORESOURCE_IO ,
IORESOURCE_IO ) ;
2013-08-02 13:31:05 +04:00
resource_size_t size = 0 , size0 = 0 , size1 = 0 ;
2011-07-26 00:08:38 +04:00
resource_size_t children_add_size = 0 ;
2013-08-06 02:15:10 +04:00
resource_size_t min_align , align ;
2005-04-17 02:20:36 +04:00
if ( ! b_res )
2013-11-14 22:28:18 +04:00
return ;
2005-04-17 02:20:36 +04:00
PCI: Avoid double hpmemsize MMIO window assignment
Previously, the kernel sometimes assigned more MMIO or MMIO_PREF space than
desired. For example, if the user requested 128M of space with
"pci=realloc,hpmemsize=128M", we sometimes assigned 256M:
pci 0000:06:01.0: BAR 14: assigned [mem 0x90100000-0xa00fffff] = 256M
pci 0000:06:04.0: BAR 14: assigned [mem 0xa0200000-0xb01fffff] = 256M
With this patch applied:
pci 0000:06:01.0: BAR 14: assigned [mem 0x90100000-0x980fffff] = 128M
pci 0000:06:04.0: BAR 14: assigned [mem 0x98200000-0xa01fffff] = 128M
This happened when in the first pass, the MMIO_PREF succeeded but the MMIO
failed. In the next pass, because MMIO_PREF was already assigned, the
attempt to assign MMIO_PREF returned an error code instead of success
(nothing more to do, already allocated). Hence, the size which was actually
allocated, but thought to have failed, was placed in the MMIO window.
The bug resulted in the MMIO_PREF being added to the MMIO window, which
meant doubling if MMIO_PREF size = MMIO size. With a large MMIO_PREF, the
MMIO window would likely fail to be assigned altogether due to lack of
32-bit address space.
Change find_free_bus_resource() to do the following:
- Return first unassigned resource of the correct type.
- If there is none, return first assigned resource of the correct type.
- If none of the above, return NULL.
Returning an assigned resource of the correct type allows the caller to
distinguish between already assigned and no resource of the correct type.
Add checks in pbus_size_io() and pbus_size_mem() to return success if
resource returned from find_free_bus_resource() is already allocated.
This avoids pbus_size_io() and pbus_size_mem() returning error code to
__pci_bus_size_bridges() when a resource has been successfully assigned in
a previous pass. This fixes the existing behaviour where space for a
resource could be reserved multiple times in different parent bridge
windows.
Link: https://lore.kernel.org/lkml/20190531171216.20532-2-logang@deltatee.com/T/#u
Link: https://bugzilla.kernel.org/show_bug.cgi?id=203243
Link: https://lore.kernel.org/r/PS2P216MB075563AA6AD242AA666EDC6A80760@PS2P216MB0755.KORP216.PROD.OUTLOOK.COM
Reported-by: Kit Chow <kchow@gigaio.com>
Reported-by: Nicholas Johnson <nicholas.johnson-opensource@outlook.com.au>
Signed-off-by: Nicholas Johnson <nicholas.johnson-opensource@outlook.com.au>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Reviewed-by: Mika Westerberg <mika.westerberg@linux.intel.com>
Reviewed-by: Logan Gunthorpe <logang@deltatee.com>
2019-11-13 18:25:28 +03:00
/* If resource is already assigned, nothing more to do */
if ( b_res - > parent )
return ;
2013-08-06 02:15:10 +04:00
min_align = window_alignment ( bus , IORESOURCE_IO ) ;
2005-04-17 02:20:36 +04:00
list_for_each_entry ( dev , & bus - > devices , bus_list ) {
int i ;
for ( i = 0 ; i < PCI_NUM_RESOURCES ; i + + ) {
struct resource * r = & dev - > resource [ i ] ;
unsigned long r_size ;
if ( r - > parent | | ! ( r - > flags & IORESOURCE_IO ) )
continue ;
2008-10-13 15:24:28 +04:00
r_size = resource_size ( r ) ;
2005-04-17 02:20:36 +04:00
if ( r_size < 0x400 )
/* Might be re-aligned for ISA */
size + = r_size ;
else
size1 + = r_size ;
2011-07-26 00:08:38 +04:00
2012-07-10 05:55:29 +04:00
align = pci_resource_alignment ( dev , r ) ;
if ( align > min_align )
min_align = align ;
2011-07-26 00:08:42 +04:00
if ( realloc_head )
children_add_size + = get_res_add_size ( realloc_head , r ) ;
2005-04-17 02:20:36 +04:00
}
}
2012-07-10 05:55:29 +04:00
2018-09-25 21:39:06 +03:00
size0 = calculate_iosize ( size , min_size , size1 , 0 , 0 ,
2012-07-10 05:55:29 +04:00
resource_size ( b_res ) , min_align ) ;
2018-09-25 21:39:06 +03:00
size1 = ( ! realloc_head | | ( realloc_head & & ! add_size & & ! children_add_size ) ) ? size0 :
calculate_iosize ( size , min_size , size1 , add_size , children_add_size ,
2012-07-10 05:55:29 +04:00
resource_size ( b_res ) , min_align ) ;
2011-02-15 04:43:20 +03:00
if ( ! size0 & & ! size1 ) {
2020-03-14 22:43:55 +03:00
if ( bus - > self & & ( b_res - > start | | b_res - > end ) )
2018-01-18 21:55:24 +03:00
pci_info ( bus - > self , " disabling bridge window %pR to %pR (unused) \n " ,
2014-04-19 04:13:50 +04:00
b_res , & bus - > busn_res ) ;
2005-04-17 02:20:36 +04:00
b_res - > flags = 0 ;
return ;
}
2012-07-10 05:55:29 +04:00
b_res - > start = min_align ;
2011-02-15 04:43:20 +03:00
b_res - > end = b_res - > start + size0 - 1 ;
PCI: clean up resource alignment management
Done per Linus' request and suggestions. Linus has explained that
better than I'll be able to explain:
On Thu, Mar 27, 2008 at 10:12:10AM -0700, Linus Torvalds wrote:
> Actually, before we go any further, there might be a less intrusive
> alternative: add just a couple of flags to the resource flags field (we
> still have something like 8 unused bits on 32-bit), and use those to
> implement a generic "resource_alignment()" routine.
>
> Two flags would do it:
>
> - IORESOURCE_SIZEALIGN: size indicates alignment (regular PCI device
> resources)
>
> - IORESOURCE_STARTALIGN: start field is alignment (PCI bus resources
> during probing)
>
> and then the case of both flags zero (or both bits set) would actually be
> "invalid", and we would also clear the IORESOURCE_STARTALIGN flag when we
> actually allocate the resource (so that we don't use the "start" field as
> alignment incorrectly when it no longer indicates alignment).
>
> That wouldn't be totally generic, but it would have the nice property of
> automatically at least add sanity checking for that whole "res->start has
> the odd meaning of 'alignment' during probing" and remove the need for a
> new field, and it would allow us to have a generic "resource_alignment()"
> routine that just gets a resource pointer.
Besides, I removed IORESOURCE_BUS_HAS_VGA flag which was unused for ages.
Signed-off-by: Ivan Kokshaysky <ink@jurassic.park.msu.ru>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Gary Hade <garyhade@us.ibm.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2008-03-30 19:50:14 +04:00
b_res - > flags | = IORESOURCE_STARTALIGN ;
2020-03-14 22:43:55 +03:00
if ( bus - > self & & size1 > size0 & & realloc_head ) {
2012-07-10 05:55:29 +04:00
add_to_list ( realloc_head , bus - > self , b_res , size1 - size0 ,
min_align ) ;
2019-04-20 07:07:20 +03:00
pci_info ( bus - > self , " bridge window %pR to %pR add_size %llx \n " ,
b_res , & bus - > busn_res ,
( unsigned long long ) size1 - size0 ) ;
2012-01-21 14:08:31 +04:00
}
2005-04-17 02:20:36 +04:00
}
2012-09-12 02:59:46 +04:00
static inline resource_size_t calculate_mem_align ( resource_size_t * aligns ,
int max_order )
{
resource_size_t align = 0 ;
resource_size_t min_align = 0 ;
int order ;
for ( order = 0 ; order < = max_order ; order + + ) {
resource_size_t align1 = 1 ;
align1 < < = ( order + 20 ) ;
if ( ! align )
min_align = align1 ;
else if ( ALIGN ( align + min_align , min_align ) < align1 )
min_align = align1 > > 1 ;
align + = aligns [ order ] ;
}
return min_align ;
}
2011-02-15 04:43:20 +03:00
/**
2019-05-07 22:51:24 +03:00
* pbus_size_mem ( ) - Size the memory window of a given bus
2011-02-15 04:43:20 +03:00
*
2019-05-07 22:51:24 +03:00
* @ bus : The bus
* @ mask : Mask the resource flag , then compare it with type
* @ type : The type of free resource from bridge
* @ type2 : Second match type
* @ type3 : Third match type
* @ min_size : The minimum memory window that must be allocated
* @ add_size : Additional optional memory window
* @ realloc_head : Track the additional memory window on this list
2011-02-15 04:43:20 +03:00
*
2019-05-07 22:51:24 +03:00
* Calculate the size of the bus and minimal alignment which guarantees
* that all child resources fit in this size .
2014-05-20 04:28:37 +04:00
*
2019-05-07 22:51:24 +03:00
* Return - ENOSPC if there ' s no available bus resource of the desired
* type . Otherwise , set the bus resource start / end to indicate the
* required size , add things to realloc_head ( if supplied ) , and return 0.
2011-02-15 04:43:20 +03:00
*/
2009-09-10 01:09:24 +04:00
static int pbus_size_mem ( struct pci_bus * bus , unsigned long mask ,
PCI: Restrict 64-bit prefetchable bridge windows to 64-bit resources
This patch changes the way we handle 64-bit prefetchable bridge windows to
make it more likely that we can assign space to all devices.
Previously we put all prefetchable resources in the prefetchable bridge
window. If any of those resources was 32-bit only, we restricted the
window to be below 4GB.
After this patch, we only put 64-bit prefetchable resources in a 64-bit
prefetchable window. We put all 32-bit prefetchable resources in the
non-prefetchable window, even if there are no 64-bit prefetchable
resources.
With the previous approach, if there was a 32-bit prefetchable resource
behind a bridge, we forced the bridge's prefetchable window below 4GB,
which meant that even if there was plenty of space above 4GB available, we
couldn't use it, and assignment of large 64-bit resources could fail, as
in the bugzilla below.
The new strategy is:
1) If the prefetchable window is 64 bits wide, we put only 64-bit
prefetchable resources in it. Any 32-bit prefetchable resources go in
the non-prefetchable window.
2) If the prefetchable window is 32 bits wide, we put both 32- and 64-bit
prefetchable resources in it.
3) If there is no prefetchable window, all MMIO resources go in the
non-prefetchable window.
This reduces performance for 32-bit prefetchable resources below a bridge
with a 64-bit prefetchable window. We previously assigned prefetchable
space, but now we'll assign non-prefetchable space. This is the case even
if there are no 64-bit prefetchable resources, or if they would all fit
below 4GB. In those cases, the old strategy would work and would have
better performance.
[bhelgaas: write changelog, add bugzilla link, fold in mem64_mask removal]
Link: https://bugzilla.kernel.org/show_bug.cgi?id=74151
Tested-by: Guo Chao <yan@linux.vnet.ibm.com>
Tested-by: Wei Yang <weiyang@linux.vnet.ibm.com>
Signed-off-by: Yinghai Lu <yinghai@kernel.org>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
2014-05-20 03:01:55 +04:00
unsigned long type , unsigned long type2 ,
2019-05-07 22:51:24 +03:00
unsigned long type3 , resource_size_t min_size ,
resource_size_t add_size ,
PCI: Restrict 64-bit prefetchable bridge windows to 64-bit resources
This patch changes the way we handle 64-bit prefetchable bridge windows to
make it more likely that we can assign space to all devices.
Previously we put all prefetchable resources in the prefetchable bridge
window. If any of those resources was 32-bit only, we restricted the
window to be below 4GB.
After this patch, we only put 64-bit prefetchable resources in a 64-bit
prefetchable window. We put all 32-bit prefetchable resources in the
non-prefetchable window, even if there are no 64-bit prefetchable
resources.
With the previous approach, if there was a 32-bit prefetchable resource
behind a bridge, we forced the bridge's prefetchable window below 4GB,
which meant that even if there was plenty of space above 4GB available, we
couldn't use it, and assignment of large 64-bit resources could fail, as
in the bugzilla below.
The new strategy is:
1) If the prefetchable window is 64 bits wide, we put only 64-bit
prefetchable resources in it. Any 32-bit prefetchable resources go in
the non-prefetchable window.
2) If the prefetchable window is 32 bits wide, we put both 32- and 64-bit
prefetchable resources in it.
3) If there is no prefetchable window, all MMIO resources go in the
non-prefetchable window.
This reduces performance for 32-bit prefetchable resources below a bridge
with a 64-bit prefetchable window. We previously assigned prefetchable
space, but now we'll assign non-prefetchable space. This is the case even
if there are no 64-bit prefetchable resources, or if they would all fit
below 4GB. In those cases, the old strategy would work and would have
better performance.
[bhelgaas: write changelog, add bugzilla link, fold in mem64_mask removal]
Link: https://bugzilla.kernel.org/show_bug.cgi?id=74151
Tested-by: Guo Chao <yan@linux.vnet.ibm.com>
Tested-by: Wei Yang <weiyang@linux.vnet.ibm.com>
Signed-off-by: Yinghai Lu <yinghai@kernel.org>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
2014-05-20 03:01:55 +04:00
struct list_head * realloc_head )
2005-04-17 02:20:36 +04:00
{
struct pci_dev * dev ;
2011-02-15 04:43:20 +03:00
resource_size_t min_align , align , size , size0 , size1 ;
2022-01-18 12:21:17 +03:00
resource_size_t aligns [ 24 ] ; /* Alignments from 1MB to 8TB */
2005-04-17 02:20:36 +04:00
int order , max_order ;
PCI: Avoid double hpmemsize MMIO window assignment
Previously, the kernel sometimes assigned more MMIO or MMIO_PREF space than
desired. For example, if the user requested 128M of space with
"pci=realloc,hpmemsize=128M", we sometimes assigned 256M:
pci 0000:06:01.0: BAR 14: assigned [mem 0x90100000-0xa00fffff] = 256M
pci 0000:06:04.0: BAR 14: assigned [mem 0xa0200000-0xb01fffff] = 256M
With this patch applied:
pci 0000:06:01.0: BAR 14: assigned [mem 0x90100000-0x980fffff] = 128M
pci 0000:06:04.0: BAR 14: assigned [mem 0x98200000-0xa01fffff] = 128M
This happened when in the first pass, the MMIO_PREF succeeded but the MMIO
failed. In the next pass, because MMIO_PREF was already assigned, the
attempt to assign MMIO_PREF returned an error code instead of success
(nothing more to do, already allocated). Hence, the size which was actually
allocated, but thought to have failed, was placed in the MMIO window.
The bug resulted in the MMIO_PREF being added to the MMIO window, which
meant doubling if MMIO_PREF size = MMIO size. With a large MMIO_PREF, the
MMIO window would likely fail to be assigned altogether due to lack of
32-bit address space.
Change find_free_bus_resource() to do the following:
- Return first unassigned resource of the correct type.
- If there is none, return first assigned resource of the correct type.
- If none of the above, return NULL.
Returning an assigned resource of the correct type allows the caller to
distinguish between already assigned and no resource of the correct type.
Add checks in pbus_size_io() and pbus_size_mem() to return success if
resource returned from find_free_bus_resource() is already allocated.
This avoids pbus_size_io() and pbus_size_mem() returning error code to
__pci_bus_size_bridges() when a resource has been successfully assigned in
a previous pass. This fixes the existing behaviour where space for a
resource could be reserved multiple times in different parent bridge
windows.
Link: https://lore.kernel.org/lkml/20190531171216.20532-2-logang@deltatee.com/T/#u
Link: https://bugzilla.kernel.org/show_bug.cgi?id=203243
Link: https://lore.kernel.org/r/PS2P216MB075563AA6AD242AA666EDC6A80760@PS2P216MB0755.KORP216.PROD.OUTLOOK.COM
Reported-by: Kit Chow <kchow@gigaio.com>
Reported-by: Nicholas Johnson <nicholas.johnson-opensource@outlook.com.au>
Signed-off-by: Nicholas Johnson <nicholas.johnson-opensource@outlook.com.au>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Reviewed-by: Mika Westerberg <mika.westerberg@linux.intel.com>
Reviewed-by: Logan Gunthorpe <logang@deltatee.com>
2019-11-13 18:25:28 +03:00
struct resource * b_res = find_bus_resource_of_type ( bus ,
PCI: Restrict 64-bit prefetchable bridge windows to 64-bit resources
This patch changes the way we handle 64-bit prefetchable bridge windows to
make it more likely that we can assign space to all devices.
Previously we put all prefetchable resources in the prefetchable bridge
window. If any of those resources was 32-bit only, we restricted the
window to be below 4GB.
After this patch, we only put 64-bit prefetchable resources in a 64-bit
prefetchable window. We put all 32-bit prefetchable resources in the
non-prefetchable window, even if there are no 64-bit prefetchable
resources.
With the previous approach, if there was a 32-bit prefetchable resource
behind a bridge, we forced the bridge's prefetchable window below 4GB,
which meant that even if there was plenty of space above 4GB available, we
couldn't use it, and assignment of large 64-bit resources could fail, as
in the bugzilla below.
The new strategy is:
1) If the prefetchable window is 64 bits wide, we put only 64-bit
prefetchable resources in it. Any 32-bit prefetchable resources go in
the non-prefetchable window.
2) If the prefetchable window is 32 bits wide, we put both 32- and 64-bit
prefetchable resources in it.
3) If there is no prefetchable window, all MMIO resources go in the
non-prefetchable window.
This reduces performance for 32-bit prefetchable resources below a bridge
with a 64-bit prefetchable window. We previously assigned prefetchable
space, but now we'll assign non-prefetchable space. This is the case even
if there are no 64-bit prefetchable resources, or if they would all fit
below 4GB. In those cases, the old strategy would work and would have
better performance.
[bhelgaas: write changelog, add bugzilla link, fold in mem64_mask removal]
Link: https://bugzilla.kernel.org/show_bug.cgi?id=74151
Tested-by: Guo Chao <yan@linux.vnet.ibm.com>
Tested-by: Wei Yang <weiyang@linux.vnet.ibm.com>
Signed-off-by: Yinghai Lu <yinghai@kernel.org>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
2014-05-20 03:01:55 +04:00
mask | IORESOURCE_PREFETCH , type ) ;
2011-07-26 00:08:38 +04:00
resource_size_t children_add_size = 0 ;
2015-03-25 11:23:51 +03:00
resource_size_t children_add_align = 0 ;
resource_size_t add_align = 0 ;
2005-04-17 02:20:36 +04:00
if ( ! b_res )
2014-05-20 04:28:37 +04:00
return - ENOSPC ;
2005-04-17 02:20:36 +04:00
PCI: Avoid double hpmemsize MMIO window assignment
Previously, the kernel sometimes assigned more MMIO or MMIO_PREF space than
desired. For example, if the user requested 128M of space with
"pci=realloc,hpmemsize=128M", we sometimes assigned 256M:
pci 0000:06:01.0: BAR 14: assigned [mem 0x90100000-0xa00fffff] = 256M
pci 0000:06:04.0: BAR 14: assigned [mem 0xa0200000-0xb01fffff] = 256M
With this patch applied:
pci 0000:06:01.0: BAR 14: assigned [mem 0x90100000-0x980fffff] = 128M
pci 0000:06:04.0: BAR 14: assigned [mem 0x98200000-0xa01fffff] = 128M
This happened when in the first pass, the MMIO_PREF succeeded but the MMIO
failed. In the next pass, because MMIO_PREF was already assigned, the
attempt to assign MMIO_PREF returned an error code instead of success
(nothing more to do, already allocated). Hence, the size which was actually
allocated, but thought to have failed, was placed in the MMIO window.
The bug resulted in the MMIO_PREF being added to the MMIO window, which
meant doubling if MMIO_PREF size = MMIO size. With a large MMIO_PREF, the
MMIO window would likely fail to be assigned altogether due to lack of
32-bit address space.
Change find_free_bus_resource() to do the following:
- Return first unassigned resource of the correct type.
- If there is none, return first assigned resource of the correct type.
- If none of the above, return NULL.
Returning an assigned resource of the correct type allows the caller to
distinguish between already assigned and no resource of the correct type.
Add checks in pbus_size_io() and pbus_size_mem() to return success if
resource returned from find_free_bus_resource() is already allocated.
This avoids pbus_size_io() and pbus_size_mem() returning error code to
__pci_bus_size_bridges() when a resource has been successfully assigned in
a previous pass. This fixes the existing behaviour where space for a
resource could be reserved multiple times in different parent bridge
windows.
Link: https://lore.kernel.org/lkml/20190531171216.20532-2-logang@deltatee.com/T/#u
Link: https://bugzilla.kernel.org/show_bug.cgi?id=203243
Link: https://lore.kernel.org/r/PS2P216MB075563AA6AD242AA666EDC6A80760@PS2P216MB0755.KORP216.PROD.OUTLOOK.COM
Reported-by: Kit Chow <kchow@gigaio.com>
Reported-by: Nicholas Johnson <nicholas.johnson-opensource@outlook.com.au>
Signed-off-by: Nicholas Johnson <nicholas.johnson-opensource@outlook.com.au>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Reviewed-by: Mika Westerberg <mika.westerberg@linux.intel.com>
Reviewed-by: Logan Gunthorpe <logang@deltatee.com>
2019-11-13 18:25:28 +03:00
/* If resource is already assigned, nothing more to do */
if ( b_res - > parent )
return 0 ;
2005-04-17 02:20:36 +04:00
memset ( aligns , 0 , sizeof ( aligns ) ) ;
max_order = 0 ;
size = 0 ;
list_for_each_entry ( dev , & bus - > devices , bus_list ) {
int i ;
2009-04-24 07:48:32 +04:00
2005-04-17 02:20:36 +04:00
for ( i = 0 ; i < PCI_NUM_RESOURCES ; i + + ) {
struct resource * r = & dev - > resource [ i ] ;
2007-12-10 09:32:15 +03:00
resource_size_t r_size ;
2005-04-17 02:20:36 +04:00
2015-10-30 01:35:39 +03:00
if ( r - > parent | | ( r - > flags & IORESOURCE_PCI_FIXED ) | |
( ( r - > flags & mask ) ! = type & &
( r - > flags & mask ) ! = type2 & &
( r - > flags & mask ) ! = type3 ) )
2005-04-17 02:20:36 +04:00
continue ;
2008-10-13 15:24:28 +04:00
r_size = resource_size ( r ) ;
2011-07-26 00:08:40 +04:00
# ifdef CONFIG_PCI_IOV
2019-05-07 22:51:24 +03:00
/* Put SRIOV requested res to the optional list */
2011-07-26 00:08:42 +04:00
if ( realloc_head & & i > = PCI_IOV_RESOURCES & &
2011-07-26 00:08:40 +04:00
i < = PCI_IOV_RESOURCE_END ) {
2015-03-25 11:23:51 +03:00
add_align = max ( pci_resource_alignment ( dev , r ) , add_align ) ;
2011-07-26 00:08:40 +04:00
r - > end = r - > start - 1 ;
2019-05-07 22:51:24 +03:00
add_to_list ( realloc_head , dev , r , r_size , 0 /* Don't care */ ) ;
2011-07-26 00:08:40 +04:00
children_add_size + = r_size ;
continue ;
}
# endif
2014-05-19 17:03:14 +04:00
/*
* aligns [ 0 ] is for 1 MB ( since bridge memory
* windows are always at least 1 MB aligned ) , so
* keep " order " from being negative for smaller
* resources .
*/
2009-08-29 00:00:06 +04:00
align = pci_resource_alignment ( dev , r ) ;
2005-04-17 02:20:36 +04:00
order = __ffs ( align ) - 20 ;
2014-05-19 17:03:14 +04:00
if ( order < 0 )
order = 0 ;
if ( order > = ARRAY_SIZE ( aligns ) ) {
2018-01-18 21:55:24 +03:00
pci_warn ( dev , " disabling BAR %d: %pR (bad alignment %#llx) \n " ,
2014-04-19 04:13:50 +04:00
i , r , ( unsigned long long ) align ) ;
2005-04-17 02:20:36 +04:00
r - > flags = 0 ;
continue ;
}
2017-04-10 14:58:11 +03:00
size + = max ( r_size , align ) ;
2019-05-07 22:51:24 +03:00
/*
* Exclude ranges with size > align from calculation of
* the alignment .
*/
2017-04-10 14:58:11 +03:00
if ( r_size < = align )
2005-04-17 02:20:36 +04:00
aligns [ order ] + = align ;
if ( order > max_order )
max_order = order ;
2011-07-26 00:08:38 +04:00
2015-03-25 11:23:51 +03:00
if ( realloc_head ) {
2011-07-26 00:08:42 +04:00
children_add_size + = get_res_add_size ( realloc_head , r ) ;
2015-03-25 11:23:51 +03:00
children_add_align = get_res_add_align ( realloc_head , r ) ;
add_align = max ( add_align , children_add_align ) ;
}
2005-04-17 02:20:36 +04:00
}
}
2012-09-12 02:59:46 +04:00
2012-09-12 02:59:46 +04:00
min_align = calculate_mem_align ( aligns , max_order ) ;
2013-09-06 05:45:58 +04:00
min_align = max ( min_align , window_alignment ( bus , b_res - > flags ) ) ;
2018-09-25 21:39:06 +03:00
size0 = calculate_memsize ( size , min_size , 0 , 0 , resource_size ( b_res ) , min_align ) ;
2015-03-25 11:23:51 +03:00
add_align = max ( min_align , add_align ) ;
2018-09-25 21:39:06 +03:00
size1 = ( ! realloc_head | | ( realloc_head & & ! add_size & & ! children_add_size ) ) ? size0 :
calculate_memsize ( size , min_size , add_size , children_add_size ,
2015-03-25 11:23:51 +03:00
resource_size ( b_res ) , add_align ) ;
2011-02-15 04:43:20 +03:00
if ( ! size0 & & ! size1 ) {
2020-03-14 22:43:55 +03:00
if ( bus - > self & & ( b_res - > start | | b_res - > end ) )
2018-01-18 21:55:24 +03:00
pci_info ( bus - > self , " disabling bridge window %pR to %pR (unused) \n " ,
2014-04-19 04:13:50 +04:00
b_res , & bus - > busn_res ) ;
2005-04-17 02:20:36 +04:00
b_res - > flags = 0 ;
2014-05-20 04:28:37 +04:00
return 0 ;
2005-04-17 02:20:36 +04:00
}
b_res - > start = min_align ;
2011-02-15 04:43:20 +03:00
b_res - > end = size0 + min_align - 1 ;
PCI: Restrict 64-bit prefetchable bridge windows to 64-bit resources
This patch changes the way we handle 64-bit prefetchable bridge windows to
make it more likely that we can assign space to all devices.
Previously we put all prefetchable resources in the prefetchable bridge
window. If any of those resources was 32-bit only, we restricted the
window to be below 4GB.
After this patch, we only put 64-bit prefetchable resources in a 64-bit
prefetchable window. We put all 32-bit prefetchable resources in the
non-prefetchable window, even if there are no 64-bit prefetchable
resources.
With the previous approach, if there was a 32-bit prefetchable resource
behind a bridge, we forced the bridge's prefetchable window below 4GB,
which meant that even if there was plenty of space above 4GB available, we
couldn't use it, and assignment of large 64-bit resources could fail, as
in the bugzilla below.
The new strategy is:
1) If the prefetchable window is 64 bits wide, we put only 64-bit
prefetchable resources in it. Any 32-bit prefetchable resources go in
the non-prefetchable window.
2) If the prefetchable window is 32 bits wide, we put both 32- and 64-bit
prefetchable resources in it.
3) If there is no prefetchable window, all MMIO resources go in the
non-prefetchable window.
This reduces performance for 32-bit prefetchable resources below a bridge
with a 64-bit prefetchable window. We previously assigned prefetchable
space, but now we'll assign non-prefetchable space. This is the case even
if there are no 64-bit prefetchable resources, or if they would all fit
below 4GB. In those cases, the old strategy would work and would have
better performance.
[bhelgaas: write changelog, add bugzilla link, fold in mem64_mask removal]
Link: https://bugzilla.kernel.org/show_bug.cgi?id=74151
Tested-by: Guo Chao <yan@linux.vnet.ibm.com>
Tested-by: Wei Yang <weiyang@linux.vnet.ibm.com>
Signed-off-by: Yinghai Lu <yinghai@kernel.org>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
2014-05-20 03:01:55 +04:00
b_res - > flags | = IORESOURCE_STARTALIGN ;
2020-03-14 22:43:55 +03:00
if ( bus - > self & & size1 > size0 & & realloc_head ) {
2015-03-25 11:23:51 +03:00
add_to_list ( realloc_head , bus - > self , b_res , size1 - size0 , add_align ) ;
2019-04-20 07:07:20 +03:00
pci_info ( bus - > self , " bridge window %pR to %pR add_size %llx add_align %llx \n " ,
2014-04-19 04:13:50 +04:00
b_res , & bus - > busn_res ,
2015-03-25 11:23:51 +03:00
( unsigned long long ) ( size1 - size0 ) ,
( unsigned long long ) add_align ) ;
2012-01-21 14:08:31 +04:00
}
2014-05-20 04:28:37 +04:00
return 0 ;
2005-04-17 02:20:36 +04:00
}
2011-07-26 00:08:41 +04:00
unsigned long pci_cardbus_resource_alignment ( struct resource * res )
{
if ( res - > flags & IORESOURCE_IO )
return pci_cardbus_io_size ;
if ( res - > flags & IORESOURCE_MEM )
return pci_cardbus_mem_size ;
return 0 ;
}
static void pci_bus_size_cardbus ( struct pci_bus * bus ,
2019-05-07 22:51:24 +03:00
struct list_head * realloc_head )
2005-04-17 02:20:36 +04:00
{
struct pci_dev * bridge = bus - > self ;
2020-05-20 21:34:10 +03:00
struct resource * b_res ;
2012-02-11 03:33:47 +04:00
resource_size_t b_res_3_size = pci_cardbus_mem_size * 2 ;
2005-04-17 02:20:36 +04:00
u16 ctrl ;
2020-05-20 21:34:10 +03:00
b_res = & bridge - > resource [ PCI_CB_BRIDGE_IO_0_WINDOW ] ;
if ( b_res - > parent )
2012-02-11 03:33:48 +04:00
goto handle_b_res_1 ;
2005-04-17 02:20:36 +04:00
/*
2019-05-07 22:51:24 +03:00
* Reserve some resources for CardBus . We reserve a fixed amount
* of bus space for CardBus bridges .
2005-04-17 02:20:36 +04:00
*/
2020-05-20 21:34:10 +03:00
b_res - > start = pci_cardbus_io_size ;
b_res - > end = b_res - > start + pci_cardbus_io_size - 1 ;
b_res - > flags | = IORESOURCE_IO | IORESOURCE_STARTALIGN ;
2012-02-11 03:33:47 +04:00
if ( realloc_head ) {
2020-05-20 21:34:10 +03:00
b_res - > end - = pci_cardbus_io_size ;
2012-02-11 03:33:47 +04:00
add_to_list ( realloc_head , bridge , b_res , pci_cardbus_io_size ,
2020-05-20 21:34:10 +03:00
pci_cardbus_io_size ) ;
2012-02-11 03:33:47 +04:00
}
2005-04-17 02:20:36 +04:00
2012-02-11 03:33:48 +04:00
handle_b_res_1 :
2020-05-20 21:34:10 +03:00
b_res = & bridge - > resource [ PCI_CB_BRIDGE_IO_1_WINDOW ] ;
if ( b_res - > parent )
2012-02-11 03:33:48 +04:00
goto handle_b_res_2 ;
2020-05-20 21:34:10 +03:00
b_res - > start = pci_cardbus_io_size ;
b_res - > end = b_res - > start + pci_cardbus_io_size - 1 ;
b_res - > flags | = IORESOURCE_IO | IORESOURCE_STARTALIGN ;
2012-02-11 03:33:47 +04:00
if ( realloc_head ) {
2020-05-20 21:34:10 +03:00
b_res - > end - = pci_cardbus_io_size ;
add_to_list ( realloc_head , bridge , b_res , pci_cardbus_io_size ,
pci_cardbus_io_size ) ;
2012-02-11 03:33:47 +04:00
}
2005-04-17 02:20:36 +04:00
2012-02-11 03:33:48 +04:00
handle_b_res_2 :
2019-05-07 22:51:24 +03:00
/* MEM1 must not be pref MMIO */
2012-02-11 03:33:46 +04:00
pci_read_config_word ( bridge , PCI_CB_BRIDGE_CONTROL , & ctrl ) ;
if ( ctrl & PCI_CB_BRIDGE_CTL_PREFETCH_MEM1 ) {
ctrl & = ~ PCI_CB_BRIDGE_CTL_PREFETCH_MEM1 ;
pci_write_config_word ( bridge , PCI_CB_BRIDGE_CONTROL , ctrl ) ;
pci_read_config_word ( bridge , PCI_CB_BRIDGE_CONTROL , & ctrl ) ;
}
2019-05-07 22:51:24 +03:00
/* Check whether prefetchable memory is supported by this bridge. */
2005-04-17 02:20:36 +04:00
pci_read_config_word ( bridge , PCI_CB_BRIDGE_CONTROL , & ctrl ) ;
if ( ! ( ctrl & PCI_CB_BRIDGE_CTL_PREFETCH_MEM0 ) ) {
ctrl | = PCI_CB_BRIDGE_CTL_PREFETCH_MEM0 ;
pci_write_config_word ( bridge , PCI_CB_BRIDGE_CONTROL , ctrl ) ;
pci_read_config_word ( bridge , PCI_CB_BRIDGE_CONTROL , & ctrl ) ;
}
2020-05-20 21:34:10 +03:00
b_res = & bridge - > resource [ PCI_CB_BRIDGE_MEM_0_WINDOW ] ;
if ( b_res - > parent )
2012-02-11 03:33:48 +04:00
goto handle_b_res_3 ;
2005-04-17 02:20:36 +04:00
/*
2019-05-07 22:51:24 +03:00
* If we have prefetchable memory support , allocate two regions .
* Otherwise , allocate one region of twice the size .
2005-04-17 02:20:36 +04:00
*/
if ( ctrl & PCI_CB_BRIDGE_CTL_PREFETCH_MEM0 ) {
2020-05-20 21:34:10 +03:00
b_res - > start = pci_cardbus_mem_size ;
b_res - > end = b_res - > start + pci_cardbus_mem_size - 1 ;
b_res - > flags | = IORESOURCE_MEM | IORESOURCE_PREFETCH |
IORESOURCE_STARTALIGN ;
2012-02-11 03:33:47 +04:00
if ( realloc_head ) {
2020-05-20 21:34:10 +03:00
b_res - > end - = pci_cardbus_mem_size ;
add_to_list ( realloc_head , bridge , b_res ,
pci_cardbus_mem_size , pci_cardbus_mem_size ) ;
2012-02-11 03:33:47 +04:00
}
2019-05-07 22:51:24 +03:00
/* Reduce that to half */
2012-02-11 03:33:47 +04:00
b_res_3_size = pci_cardbus_mem_size ;
}
2012-02-11 03:33:48 +04:00
handle_b_res_3 :
2020-05-20 21:34:10 +03:00
b_res = & bridge - > resource [ PCI_CB_BRIDGE_MEM_1_WINDOW ] ;
if ( b_res - > parent )
2012-02-11 03:33:48 +04:00
goto handle_done ;
2020-05-20 21:34:10 +03:00
b_res - > start = pci_cardbus_mem_size ;
b_res - > end = b_res - > start + b_res_3_size - 1 ;
b_res - > flags | = IORESOURCE_MEM | IORESOURCE_STARTALIGN ;
2012-02-11 03:33:47 +04:00
if ( realloc_head ) {
2020-05-20 21:34:10 +03:00
b_res - > end - = b_res_3_size ;
add_to_list ( realloc_head , bridge , b_res , b_res_3_size ,
pci_cardbus_mem_size ) ;
2012-02-11 03:33:47 +04:00
}
2012-02-11 03:33:48 +04:00
handle_done :
;
2005-04-17 02:20:36 +04:00
}
2014-04-15 02:11:40 +04:00
void __pci_bus_size_bridges ( struct pci_bus * bus , struct list_head * realloc_head )
2005-04-17 02:20:36 +04:00
{
struct pci_dev * dev ;
PCI: Restrict 64-bit prefetchable bridge windows to 64-bit resources
This patch changes the way we handle 64-bit prefetchable bridge windows to
make it more likely that we can assign space to all devices.
Previously we put all prefetchable resources in the prefetchable bridge
window. If any of those resources was 32-bit only, we restricted the
window to be below 4GB.
After this patch, we only put 64-bit prefetchable resources in a 64-bit
prefetchable window. We put all 32-bit prefetchable resources in the
non-prefetchable window, even if there are no 64-bit prefetchable
resources.
With the previous approach, if there was a 32-bit prefetchable resource
behind a bridge, we forced the bridge's prefetchable window below 4GB,
which meant that even if there was plenty of space above 4GB available, we
couldn't use it, and assignment of large 64-bit resources could fail, as
in the bugzilla below.
The new strategy is:
1) If the prefetchable window is 64 bits wide, we put only 64-bit
prefetchable resources in it. Any 32-bit prefetchable resources go in
the non-prefetchable window.
2) If the prefetchable window is 32 bits wide, we put both 32- and 64-bit
prefetchable resources in it.
3) If there is no prefetchable window, all MMIO resources go in the
non-prefetchable window.
This reduces performance for 32-bit prefetchable resources below a bridge
with a 64-bit prefetchable window. We previously assigned prefetchable
space, but now we'll assign non-prefetchable space. This is the case even
if there are no 64-bit prefetchable resources, or if they would all fit
below 4GB. In those cases, the old strategy would work and would have
better performance.
[bhelgaas: write changelog, add bugzilla link, fold in mem64_mask removal]
Link: https://bugzilla.kernel.org/show_bug.cgi?id=74151
Tested-by: Guo Chao <yan@linux.vnet.ibm.com>
Tested-by: Wei Yang <weiyang@linux.vnet.ibm.com>
Signed-off-by: Yinghai Lu <yinghai@kernel.org>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
2014-05-20 03:01:55 +04:00
unsigned long mask , prefmask , type2 = 0 , type3 = 0 ;
2019-10-23 15:12:29 +03:00
resource_size_t additional_io_size = 0 , additional_mmio_size = 0 ,
additional_mmio_pref_size = 0 ;
2020-03-14 22:43:55 +03:00
struct resource * pref ;
struct pci_host_bridge * host ;
int hdr_type , i , ret ;
2005-04-17 02:20:36 +04:00
list_for_each_entry ( dev , & bus - > devices , bus_list ) {
struct pci_bus * b = dev - > subordinate ;
if ( ! b )
continue ;
PCI: Rely on config space header type, not class code
The PCI configuration space header type tells us whether the device is a
bridge, a CardBus bridge, or a normal device, and defines the layout of the
rest of the header (PCI r3.0 sec 6.1, PCIe r4.0 sec 7.5.1.1.9).
When we rely on the header format, e.g., when we're dealing with bridge
windows, we should check the header type, not the class code. The class
code is loosely related to the header type, but is often incorrect and the
spec doesn't actually require it to be related to the header format.
Suggested-by: Bjorn Helgaas <bhelgaas@google.com>
Signed-off-by: Honghui Zhang <honghui.zhang@mediatek.com>
[bhelgaas: changelog, keep the PCI_CLASS_BRIDGE_HOST check]
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
2018-10-16 13:44:43 +03:00
switch ( dev - > hdr_type ) {
case PCI_HEADER_TYPE_CARDBUS :
2011-07-26 00:08:42 +04:00
pci_bus_size_cardbus ( b , realloc_head ) ;
2005-04-17 02:20:36 +04:00
break ;
PCI: Rely on config space header type, not class code
The PCI configuration space header type tells us whether the device is a
bridge, a CardBus bridge, or a normal device, and defines the layout of the
rest of the header (PCI r3.0 sec 6.1, PCIe r4.0 sec 7.5.1.1.9).
When we rely on the header format, e.g., when we're dealing with bridge
windows, we should check the header type, not the class code. The class
code is loosely related to the header type, but is often incorrect and the
spec doesn't actually require it to be related to the header format.
Suggested-by: Bjorn Helgaas <bhelgaas@google.com>
Signed-off-by: Honghui Zhang <honghui.zhang@mediatek.com>
[bhelgaas: changelog, keep the PCI_CLASS_BRIDGE_HOST check]
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
2018-10-16 13:44:43 +03:00
case PCI_HEADER_TYPE_BRIDGE :
2005-04-17 02:20:36 +04:00
default :
2011-07-26 00:08:42 +04:00
__pci_bus_size_bridges ( b , realloc_head ) ;
2005-04-17 02:20:36 +04:00
break ;
}
}
/* The root bus? */
2020-03-14 22:43:55 +03:00
if ( pci_is_root_bus ( bus ) ) {
host = to_pci_host_bridge ( bus - > bridge ) ;
if ( ! host - > size_windows )
return ;
pci_bus_for_each_resource ( bus , pref , i )
if ( pref & & ( pref - > flags & IORESOURCE_PREFETCH ) )
break ;
hdr_type = - 1 ; /* Intentionally invalid - not a PCI device. */
} else {
2020-05-20 21:34:10 +03:00
pref = & bus - > self - > resource [ PCI_BRIDGE_PREF_MEM_WINDOW ] ;
2020-03-14 22:43:55 +03:00
hdr_type = bus - > self - > hdr_type ;
}
2005-04-17 02:20:36 +04:00
2020-03-14 22:43:55 +03:00
switch ( hdr_type ) {
PCI: Rely on config space header type, not class code
The PCI configuration space header type tells us whether the device is a
bridge, a CardBus bridge, or a normal device, and defines the layout of the
rest of the header (PCI r3.0 sec 6.1, PCIe r4.0 sec 7.5.1.1.9).
When we rely on the header format, e.g., when we're dealing with bridge
windows, we should check the header type, not the class code. The class
code is loosely related to the header type, but is often incorrect and the
spec doesn't actually require it to be related to the header format.
Suggested-by: Bjorn Helgaas <bhelgaas@google.com>
Signed-off-by: Honghui Zhang <honghui.zhang@mediatek.com>
[bhelgaas: changelog, keep the PCI_CLASS_BRIDGE_HOST check]
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
2018-10-16 13:44:43 +03:00
case PCI_HEADER_TYPE_CARDBUS :
2019-05-07 22:51:24 +03:00
/* Don't size CardBuses yet */
2005-04-17 02:20:36 +04:00
break ;
PCI: Rely on config space header type, not class code
The PCI configuration space header type tells us whether the device is a
bridge, a CardBus bridge, or a normal device, and defines the layout of the
rest of the header (PCI r3.0 sec 6.1, PCIe r4.0 sec 7.5.1.1.9).
When we rely on the header format, e.g., when we're dealing with bridge
windows, we should check the header type, not the class code. The class
code is loosely related to the header type, but is often incorrect and the
spec doesn't actually require it to be related to the header format.
Suggested-by: Bjorn Helgaas <bhelgaas@google.com>
Signed-off-by: Honghui Zhang <honghui.zhang@mediatek.com>
[bhelgaas: changelog, keep the PCI_CLASS_BRIDGE_HOST check]
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
2018-10-16 13:44:43 +03:00
case PCI_HEADER_TYPE_BRIDGE :
2005-04-17 02:20:36 +04:00
pci_bridge_check_ranges ( bus ) ;
2009-09-10 01:09:24 +04:00
if ( bus - > self - > is_hotplug_bridge ) {
2011-02-15 04:43:20 +03:00
additional_io_size = pci_hotplug_io_size ;
2019-10-23 15:12:29 +03:00
additional_mmio_size = pci_hotplug_mmio_size ;
additional_mmio_pref_size = pci_hotplug_mmio_pref_size ;
2009-09-10 01:09:24 +04:00
}
2020-08-24 01:36:59 +03:00
fallthrough ;
2005-04-17 02:20:36 +04:00
default :
2012-01-21 14:08:24 +04:00
pbus_size_io ( bus , realloc_head ? 0 : additional_io_size ,
additional_io_size , realloc_head ) ;
2014-05-20 04:32:18 +04:00
/*
* If there ' s a 64 - bit prefetchable MMIO window , compute
* the size required to put all 64 - bit prefetchable
* resources in it .
*/
2005-04-17 02:20:36 +04:00
mask = IORESOURCE_MEM ;
prefmask = IORESOURCE_MEM | IORESOURCE_PREFETCH ;
2020-03-14 22:43:55 +03:00
if ( pref & & ( pref - > flags & IORESOURCE_MEM_64 ) ) {
PCI: Restrict 64-bit prefetchable bridge windows to 64-bit resources
This patch changes the way we handle 64-bit prefetchable bridge windows to
make it more likely that we can assign space to all devices.
Previously we put all prefetchable resources in the prefetchable bridge
window. If any of those resources was 32-bit only, we restricted the
window to be below 4GB.
After this patch, we only put 64-bit prefetchable resources in a 64-bit
prefetchable window. We put all 32-bit prefetchable resources in the
non-prefetchable window, even if there are no 64-bit prefetchable
resources.
With the previous approach, if there was a 32-bit prefetchable resource
behind a bridge, we forced the bridge's prefetchable window below 4GB,
which meant that even if there was plenty of space above 4GB available, we
couldn't use it, and assignment of large 64-bit resources could fail, as
in the bugzilla below.
The new strategy is:
1) If the prefetchable window is 64 bits wide, we put only 64-bit
prefetchable resources in it. Any 32-bit prefetchable resources go in
the non-prefetchable window.
2) If the prefetchable window is 32 bits wide, we put both 32- and 64-bit
prefetchable resources in it.
3) If there is no prefetchable window, all MMIO resources go in the
non-prefetchable window.
This reduces performance for 32-bit prefetchable resources below a bridge
with a 64-bit prefetchable window. We previously assigned prefetchable
space, but now we'll assign non-prefetchable space. This is the case even
if there are no 64-bit prefetchable resources, or if they would all fit
below 4GB. In those cases, the old strategy would work and would have
better performance.
[bhelgaas: write changelog, add bugzilla link, fold in mem64_mask removal]
Link: https://bugzilla.kernel.org/show_bug.cgi?id=74151
Tested-by: Guo Chao <yan@linux.vnet.ibm.com>
Tested-by: Wei Yang <weiyang@linux.vnet.ibm.com>
Signed-off-by: Yinghai Lu <yinghai@kernel.org>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
2014-05-20 03:01:55 +04:00
prefmask | = IORESOURCE_MEM_64 ;
2014-05-20 04:28:37 +04:00
ret = pbus_size_mem ( bus , prefmask , prefmask ,
2019-10-23 15:12:29 +03:00
prefmask , prefmask ,
realloc_head ? 0 : additional_mmio_pref_size ,
additional_mmio_pref_size , realloc_head ) ;
2014-05-20 04:32:18 +04:00
/*
* If successful , all non - prefetchable resources
* and any 32 - bit prefetchable resources will go in
* the non - prefetchable window .
*/
2014-05-20 04:28:37 +04:00
if ( ret = = 0 ) {
mask = prefmask ;
type2 = prefmask & ~ IORESOURCE_MEM_64 ;
type3 = prefmask & ~ IORESOURCE_PREFETCH ;
PCI: Restrict 64-bit prefetchable bridge windows to 64-bit resources
This patch changes the way we handle 64-bit prefetchable bridge windows to
make it more likely that we can assign space to all devices.
Previously we put all prefetchable resources in the prefetchable bridge
window. If any of those resources was 32-bit only, we restricted the
window to be below 4GB.
After this patch, we only put 64-bit prefetchable resources in a 64-bit
prefetchable window. We put all 32-bit prefetchable resources in the
non-prefetchable window, even if there are no 64-bit prefetchable
resources.
With the previous approach, if there was a 32-bit prefetchable resource
behind a bridge, we forced the bridge's prefetchable window below 4GB,
which meant that even if there was plenty of space above 4GB available, we
couldn't use it, and assignment of large 64-bit resources could fail, as
in the bugzilla below.
The new strategy is:
1) If the prefetchable window is 64 bits wide, we put only 64-bit
prefetchable resources in it. Any 32-bit prefetchable resources go in
the non-prefetchable window.
2) If the prefetchable window is 32 bits wide, we put both 32- and 64-bit
prefetchable resources in it.
3) If there is no prefetchable window, all MMIO resources go in the
non-prefetchable window.
This reduces performance for 32-bit prefetchable resources below a bridge
with a 64-bit prefetchable window. We previously assigned prefetchable
space, but now we'll assign non-prefetchable space. This is the case even
if there are no 64-bit prefetchable resources, or if they would all fit
below 4GB. In those cases, the old strategy would work and would have
better performance.
[bhelgaas: write changelog, add bugzilla link, fold in mem64_mask removal]
Link: https://bugzilla.kernel.org/show_bug.cgi?id=74151
Tested-by: Guo Chao <yan@linux.vnet.ibm.com>
Tested-by: Wei Yang <weiyang@linux.vnet.ibm.com>
Signed-off-by: Yinghai Lu <yinghai@kernel.org>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
2014-05-20 03:01:55 +04:00
}
}
2014-05-20 04:32:18 +04:00
/*
* If there is no 64 - bit prefetchable window , compute the
* size required to put all prefetchable resources in the
* 32 - bit prefetchable window ( if there is one ) .
*/
PCI: Restrict 64-bit prefetchable bridge windows to 64-bit resources
This patch changes the way we handle 64-bit prefetchable bridge windows to
make it more likely that we can assign space to all devices.
Previously we put all prefetchable resources in the prefetchable bridge
window. If any of those resources was 32-bit only, we restricted the
window to be below 4GB.
After this patch, we only put 64-bit prefetchable resources in a 64-bit
prefetchable window. We put all 32-bit prefetchable resources in the
non-prefetchable window, even if there are no 64-bit prefetchable
resources.
With the previous approach, if there was a 32-bit prefetchable resource
behind a bridge, we forced the bridge's prefetchable window below 4GB,
which meant that even if there was plenty of space above 4GB available, we
couldn't use it, and assignment of large 64-bit resources could fail, as
in the bugzilla below.
The new strategy is:
1) If the prefetchable window is 64 bits wide, we put only 64-bit
prefetchable resources in it. Any 32-bit prefetchable resources go in
the non-prefetchable window.
2) If the prefetchable window is 32 bits wide, we put both 32- and 64-bit
prefetchable resources in it.
3) If there is no prefetchable window, all MMIO resources go in the
non-prefetchable window.
This reduces performance for 32-bit prefetchable resources below a bridge
with a 64-bit prefetchable window. We previously assigned prefetchable
space, but now we'll assign non-prefetchable space. This is the case even
if there are no 64-bit prefetchable resources, or if they would all fit
below 4GB. In those cases, the old strategy would work and would have
better performance.
[bhelgaas: write changelog, add bugzilla link, fold in mem64_mask removal]
Link: https://bugzilla.kernel.org/show_bug.cgi?id=74151
Tested-by: Guo Chao <yan@linux.vnet.ibm.com>
Tested-by: Wei Yang <weiyang@linux.vnet.ibm.com>
Signed-off-by: Yinghai Lu <yinghai@kernel.org>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
2014-05-20 03:01:55 +04:00
if ( ! type2 ) {
prefmask & = ~ IORESOURCE_MEM_64 ;
2014-05-20 04:28:37 +04:00
ret = pbus_size_mem ( bus , prefmask , prefmask ,
2019-10-23 15:12:29 +03:00
prefmask , prefmask ,
realloc_head ? 0 : additional_mmio_pref_size ,
additional_mmio_pref_size , realloc_head ) ;
2014-05-20 04:32:18 +04:00
/*
* If successful , only non - prefetchable resources
* will go in the non - prefetchable window .
*/
if ( ret = = 0 )
PCI: Restrict 64-bit prefetchable bridge windows to 64-bit resources
This patch changes the way we handle 64-bit prefetchable bridge windows to
make it more likely that we can assign space to all devices.
Previously we put all prefetchable resources in the prefetchable bridge
window. If any of those resources was 32-bit only, we restricted the
window to be below 4GB.
After this patch, we only put 64-bit prefetchable resources in a 64-bit
prefetchable window. We put all 32-bit prefetchable resources in the
non-prefetchable window, even if there are no 64-bit prefetchable
resources.
With the previous approach, if there was a 32-bit prefetchable resource
behind a bridge, we forced the bridge's prefetchable window below 4GB,
which meant that even if there was plenty of space above 4GB available, we
couldn't use it, and assignment of large 64-bit resources could fail, as
in the bugzilla below.
The new strategy is:
1) If the prefetchable window is 64 bits wide, we put only 64-bit
prefetchable resources in it. Any 32-bit prefetchable resources go in
the non-prefetchable window.
2) If the prefetchable window is 32 bits wide, we put both 32- and 64-bit
prefetchable resources in it.
3) If there is no prefetchable window, all MMIO resources go in the
non-prefetchable window.
This reduces performance for 32-bit prefetchable resources below a bridge
with a 64-bit prefetchable window. We previously assigned prefetchable
space, but now we'll assign non-prefetchable space. This is the case even
if there are no 64-bit prefetchable resources, or if they would all fit
below 4GB. In those cases, the old strategy would work and would have
better performance.
[bhelgaas: write changelog, add bugzilla link, fold in mem64_mask removal]
Link: https://bugzilla.kernel.org/show_bug.cgi?id=74151
Tested-by: Guo Chao <yan@linux.vnet.ibm.com>
Tested-by: Wei Yang <weiyang@linux.vnet.ibm.com>
Signed-off-by: Yinghai Lu <yinghai@kernel.org>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
2014-05-20 03:01:55 +04:00
mask = prefmask ;
2014-05-20 04:32:18 +04:00
else
2019-10-23 15:12:29 +03:00
additional_mmio_size + = additional_mmio_pref_size ;
2014-05-20 04:32:18 +04:00
PCI: Restrict 64-bit prefetchable bridge windows to 64-bit resources
This patch changes the way we handle 64-bit prefetchable bridge windows to
make it more likely that we can assign space to all devices.
Previously we put all prefetchable resources in the prefetchable bridge
window. If any of those resources was 32-bit only, we restricted the
window to be below 4GB.
After this patch, we only put 64-bit prefetchable resources in a 64-bit
prefetchable window. We put all 32-bit prefetchable resources in the
non-prefetchable window, even if there are no 64-bit prefetchable
resources.
With the previous approach, if there was a 32-bit prefetchable resource
behind a bridge, we forced the bridge's prefetchable window below 4GB,
which meant that even if there was plenty of space above 4GB available, we
couldn't use it, and assignment of large 64-bit resources could fail, as
in the bugzilla below.
The new strategy is:
1) If the prefetchable window is 64 bits wide, we put only 64-bit
prefetchable resources in it. Any 32-bit prefetchable resources go in
the non-prefetchable window.
2) If the prefetchable window is 32 bits wide, we put both 32- and 64-bit
prefetchable resources in it.
3) If there is no prefetchable window, all MMIO resources go in the
non-prefetchable window.
This reduces performance for 32-bit prefetchable resources below a bridge
with a 64-bit prefetchable window. We previously assigned prefetchable
space, but now we'll assign non-prefetchable space. This is the case even
if there are no 64-bit prefetchable resources, or if they would all fit
below 4GB. In those cases, the old strategy would work and would have
better performance.
[bhelgaas: write changelog, add bugzilla link, fold in mem64_mask removal]
Link: https://bugzilla.kernel.org/show_bug.cgi?id=74151
Tested-by: Guo Chao <yan@linux.vnet.ibm.com>
Tested-by: Wei Yang <weiyang@linux.vnet.ibm.com>
Signed-off-by: Yinghai Lu <yinghai@kernel.org>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
2014-05-20 03:01:55 +04:00
type2 = type3 = IORESOURCE_MEM ;
}
2014-05-20 04:32:18 +04:00
/*
* Compute the size required to put everything else in the
2019-05-07 22:51:24 +03:00
* non - prefetchable window . This includes :
2014-05-20 04:32:18 +04:00
*
* - all non - prefetchable resources
* - 32 - bit prefetchable resources if there ' s a 64 - bit
* prefetchable window or no prefetchable window at all
2019-05-07 22:51:24 +03:00
* - 64 - bit prefetchable resources if there ' s no prefetchable
* window at all
2014-05-20 04:32:18 +04:00
*
2019-05-07 22:51:24 +03:00
* Note that the strategy in __pci_assign_resource ( ) must match
* that used here . Specifically , we cannot put a 32 - bit
* prefetchable resource in a 64 - bit prefetchable window .
2014-05-20 04:32:18 +04:00
*/
PCI: Restrict 64-bit prefetchable bridge windows to 64-bit resources
This patch changes the way we handle 64-bit prefetchable bridge windows to
make it more likely that we can assign space to all devices.
Previously we put all prefetchable resources in the prefetchable bridge
window. If any of those resources was 32-bit only, we restricted the
window to be below 4GB.
After this patch, we only put 64-bit prefetchable resources in a 64-bit
prefetchable window. We put all 32-bit prefetchable resources in the
non-prefetchable window, even if there are no 64-bit prefetchable
resources.
With the previous approach, if there was a 32-bit prefetchable resource
behind a bridge, we forced the bridge's prefetchable window below 4GB,
which meant that even if there was plenty of space above 4GB available, we
couldn't use it, and assignment of large 64-bit resources could fail, as
in the bugzilla below.
The new strategy is:
1) If the prefetchable window is 64 bits wide, we put only 64-bit
prefetchable resources in it. Any 32-bit prefetchable resources go in
the non-prefetchable window.
2) If the prefetchable window is 32 bits wide, we put both 32- and 64-bit
prefetchable resources in it.
3) If there is no prefetchable window, all MMIO resources go in the
non-prefetchable window.
This reduces performance for 32-bit prefetchable resources below a bridge
with a 64-bit prefetchable window. We previously assigned prefetchable
space, but now we'll assign non-prefetchable space. This is the case even
if there are no 64-bit prefetchable resources, or if they would all fit
below 4GB. In those cases, the old strategy would work and would have
better performance.
[bhelgaas: write changelog, add bugzilla link, fold in mem64_mask removal]
Link: https://bugzilla.kernel.org/show_bug.cgi?id=74151
Tested-by: Guo Chao <yan@linux.vnet.ibm.com>
Tested-by: Wei Yang <weiyang@linux.vnet.ibm.com>
Signed-off-by: Yinghai Lu <yinghai@kernel.org>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
2014-05-20 03:01:55 +04:00
pbus_size_mem ( bus , mask , IORESOURCE_MEM , type2 , type3 ,
2019-10-23 15:12:29 +03:00
realloc_head ? 0 : additional_mmio_size ,
additional_mmio_size , realloc_head ) ;
2005-04-17 02:20:36 +04:00
break ;
}
}
2011-02-15 04:43:20 +03:00
2014-04-15 02:11:40 +04:00
void pci_bus_size_bridges ( struct pci_bus * bus )
2011-02-15 04:43:20 +03:00
{
__pci_bus_size_bridges ( bus , NULL ) ;
}
2005-04-17 02:20:36 +04:00
EXPORT_SYMBOL ( pci_bus_size_bridges ) ;
2015-10-30 01:35:39 +03:00
static void assign_fixed_resource_on_bus ( struct pci_bus * b , struct resource * r )
{
int i ;
struct resource * parent_r ;
unsigned long mask = IORESOURCE_IO | IORESOURCE_MEM |
IORESOURCE_PREFETCH ;
pci_bus_for_each_resource ( b , parent_r , i ) {
if ( ! parent_r )
continue ;
if ( ( r - > flags & mask ) = = ( parent_r - > flags & mask ) & &
resource_contains ( parent_r , r ) )
request_resource ( parent_r , r ) ;
}
}
/*
2019-05-07 22:51:24 +03:00
* Try to assign any resources marked as IORESOURCE_PCI_FIXED , as they are
* skipped by pbus_assign_resources_sorted ( ) .
2015-10-30 01:35:39 +03:00
*/
static void pdev_assign_fixed_resources ( struct pci_dev * dev )
{
int i ;
for ( i = 0 ; i < PCI_NUM_RESOURCES ; i + + ) {
struct pci_bus * b ;
struct resource * r = & dev - > resource [ i ] ;
if ( r - > parent | | ! ( r - > flags & IORESOURCE_PCI_FIXED ) | |
! ( r - > flags & ( IORESOURCE_IO | IORESOURCE_MEM ) ) )
continue ;
b = dev - > bus ;
while ( b & & ! r - > parent ) {
assign_fixed_resource_on_bus ( b , r ) ;
b = b - > parent ;
}
}
}
2014-04-15 02:11:40 +04:00
void __pci_bus_assign_resources ( const struct pci_bus * bus ,
struct list_head * realloc_head ,
struct list_head * fail_head )
2005-04-17 02:20:36 +04:00
{
struct pci_bus * b ;
struct pci_dev * dev ;
2011-07-26 00:08:42 +04:00
pbus_assign_resources_sorted ( bus , realloc_head , fail_head ) ;
2005-04-17 02:20:36 +04:00
list_for_each_entry ( dev , & bus - > devices , bus_list ) {
2015-10-30 01:35:39 +03:00
pdev_assign_fixed_resources ( dev ) ;
2005-04-17 02:20:36 +04:00
b = dev - > subordinate ;
if ( ! b )
continue ;
2011-07-26 00:08:42 +04:00
__pci_bus_assign_resources ( b , realloc_head , fail_head ) ;
2005-04-17 02:20:36 +04:00
PCI: Rely on config space header type, not class code
The PCI configuration space header type tells us whether the device is a
bridge, a CardBus bridge, or a normal device, and defines the layout of the
rest of the header (PCI r3.0 sec 6.1, PCIe r4.0 sec 7.5.1.1.9).
When we rely on the header format, e.g., when we're dealing with bridge
windows, we should check the header type, not the class code. The class
code is loosely related to the header type, but is often incorrect and the
spec doesn't actually require it to be related to the header format.
Suggested-by: Bjorn Helgaas <bhelgaas@google.com>
Signed-off-by: Honghui Zhang <honghui.zhang@mediatek.com>
[bhelgaas: changelog, keep the PCI_CLASS_BRIDGE_HOST check]
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
2018-10-16 13:44:43 +03:00
switch ( dev - > hdr_type ) {
case PCI_HEADER_TYPE_BRIDGE :
2010-01-22 12:02:25 +03:00
if ( ! pci_is_enabled ( dev ) )
pci_setup_bridge ( b ) ;
2005-04-17 02:20:36 +04:00
break ;
PCI: Rely on config space header type, not class code
The PCI configuration space header type tells us whether the device is a
bridge, a CardBus bridge, or a normal device, and defines the layout of the
rest of the header (PCI r3.0 sec 6.1, PCIe r4.0 sec 7.5.1.1.9).
When we rely on the header format, e.g., when we're dealing with bridge
windows, we should check the header type, not the class code. The class
code is loosely related to the header type, but is often incorrect and the
spec doesn't actually require it to be related to the header format.
Suggested-by: Bjorn Helgaas <bhelgaas@google.com>
Signed-off-by: Honghui Zhang <honghui.zhang@mediatek.com>
[bhelgaas: changelog, keep the PCI_CLASS_BRIDGE_HOST check]
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
2018-10-16 13:44:43 +03:00
case PCI_HEADER_TYPE_CARDBUS :
2005-04-17 02:20:36 +04:00
pci_setup_cardbus ( b ) ;
break ;
default :
2018-01-18 21:55:24 +03:00
pci_info ( dev , " not setting up bridge for bus %04x:%02x \n " ,
2014-04-19 04:13:50 +04:00
pci_domain_nr ( b ) , b - > number ) ;
2005-04-17 02:20:36 +04:00
break ;
}
}
}
2010-01-22 12:02:21 +03:00
2014-04-15 02:11:40 +04:00
void pci_bus_assign_resources ( const struct pci_bus * bus )
2010-01-22 12:02:21 +03:00
{
2011-02-15 04:43:20 +03:00
__pci_bus_assign_resources ( bus , NULL , NULL ) ;
2010-01-22 12:02:21 +03:00
}
2005-04-17 02:20:36 +04:00
EXPORT_SYMBOL ( pci_bus_assign_resources ) ;
2016-06-08 14:04:47 +03:00
static void pci_claim_device_resources ( struct pci_dev * dev )
{
int i ;
for ( i = 0 ; i < PCI_BRIDGE_RESOURCES ; i + + ) {
struct resource * r = & dev - > resource [ i ] ;
if ( ! r - > flags | | r - > parent )
continue ;
pci_claim_resource ( dev , i ) ;
}
}
static void pci_claim_bridge_resources ( struct pci_dev * dev )
{
int i ;
for ( i = PCI_BRIDGE_RESOURCES ; i < PCI_NUM_RESOURCES ; i + + ) {
struct resource * r = & dev - > resource [ i ] ;
if ( ! r - > flags | | r - > parent )
continue ;
pci_claim_bridge_resource ( dev , i ) ;
}
}
static void pci_bus_allocate_dev_resources ( struct pci_bus * b )
{
struct pci_dev * dev ;
struct pci_bus * child ;
list_for_each_entry ( dev , & b - > devices , bus_list ) {
pci_claim_device_resources ( dev ) ;
child = dev - > subordinate ;
if ( child )
pci_bus_allocate_dev_resources ( child ) ;
}
}
static void pci_bus_allocate_resources ( struct pci_bus * b )
{
struct pci_bus * child ;
/*
2019-05-07 22:51:24 +03:00
* Carry out a depth - first search on the PCI bus tree to allocate
* bridge apertures . Read the programmed bridge bases and
* recursively claim the respective bridge resources .
2016-06-08 14:04:47 +03:00
*/
if ( b - > self ) {
pci_read_bridge_bases ( b ) ;
pci_claim_bridge_resources ( b - > self ) ;
}
list_for_each_entry ( child , & b - > children , node )
pci_bus_allocate_resources ( child ) ;
}
void pci_bus_claim_resources ( struct pci_bus * b )
{
pci_bus_allocate_resources ( b ) ;
pci_bus_allocate_dev_resources ( b ) ;
}
EXPORT_SYMBOL ( pci_bus_claim_resources ) ;
2014-04-15 02:11:40 +04:00
static void __pci_bridge_assign_resources ( const struct pci_dev * bridge ,
struct list_head * add_head ,
struct list_head * fail_head )
2010-01-22 12:02:25 +03:00
{
struct pci_bus * b ;
2012-01-21 14:08:21 +04:00
pdev_assign_resources_sorted ( ( struct pci_dev * ) bridge ,
add_head , fail_head ) ;
2010-01-22 12:02:25 +03:00
b = bridge - > subordinate ;
if ( ! b )
return ;
2012-01-21 14:08:21 +04:00
__pci_bus_assign_resources ( b , add_head , fail_head ) ;
2010-01-22 12:02:25 +03:00
switch ( bridge - > class > > 8 ) {
case PCI_CLASS_BRIDGE_PCI :
pci_setup_bridge ( b ) ;
break ;
case PCI_CLASS_BRIDGE_CARDBUS :
pci_setup_cardbus ( b ) ;
break ;
default :
2018-01-18 21:55:24 +03:00
pci_info ( bridge , " not setting up bridge for bus %04x:%02x \n " ,
2014-04-19 04:13:50 +04:00
pci_domain_nr ( b ) , b - > number ) ;
2010-01-22 12:02:25 +03:00
break ;
}
}
2017-10-18 16:58:17 +03:00
# define PCI_RES_TYPE_MASK \
( IORESOURCE_IO | IORESOURCE_MEM | IORESOURCE_PREFETCH | \
IORESOURCE_MEM_64 )
2010-01-22 12:02:20 +03:00
static void pci_bridge_release_resources ( struct pci_bus * bus ,
2019-05-07 22:51:24 +03:00
unsigned long type )
2010-01-22 12:02:20 +03:00
{
PCI: Restrict 64-bit prefetchable bridge windows to 64-bit resources
This patch changes the way we handle 64-bit prefetchable bridge windows to
make it more likely that we can assign space to all devices.
Previously we put all prefetchable resources in the prefetchable bridge
window. If any of those resources was 32-bit only, we restricted the
window to be below 4GB.
After this patch, we only put 64-bit prefetchable resources in a 64-bit
prefetchable window. We put all 32-bit prefetchable resources in the
non-prefetchable window, even if there are no 64-bit prefetchable
resources.
With the previous approach, if there was a 32-bit prefetchable resource
behind a bridge, we forced the bridge's prefetchable window below 4GB,
which meant that even if there was plenty of space above 4GB available, we
couldn't use it, and assignment of large 64-bit resources could fail, as
in the bugzilla below.
The new strategy is:
1) If the prefetchable window is 64 bits wide, we put only 64-bit
prefetchable resources in it. Any 32-bit prefetchable resources go in
the non-prefetchable window.
2) If the prefetchable window is 32 bits wide, we put both 32- and 64-bit
prefetchable resources in it.
3) If there is no prefetchable window, all MMIO resources go in the
non-prefetchable window.
This reduces performance for 32-bit prefetchable resources below a bridge
with a 64-bit prefetchable window. We previously assigned prefetchable
space, but now we'll assign non-prefetchable space. This is the case even
if there are no 64-bit prefetchable resources, or if they would all fit
below 4GB. In those cases, the old strategy would work and would have
better performance.
[bhelgaas: write changelog, add bugzilla link, fold in mem64_mask removal]
Link: https://bugzilla.kernel.org/show_bug.cgi?id=74151
Tested-by: Guo Chao <yan@linux.vnet.ibm.com>
Tested-by: Wei Yang <weiyang@linux.vnet.ibm.com>
Signed-off-by: Yinghai Lu <yinghai@kernel.org>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
2014-05-20 03:01:55 +04:00
struct pci_dev * dev = bus - > self ;
2010-01-22 12:02:20 +03:00
struct resource * r ;
2022-03-13 22:29:29 +03:00
unsigned int old_flags ;
PCI: Restrict 64-bit prefetchable bridge windows to 64-bit resources
This patch changes the way we handle 64-bit prefetchable bridge windows to
make it more likely that we can assign space to all devices.
Previously we put all prefetchable resources in the prefetchable bridge
window. If any of those resources was 32-bit only, we restricted the
window to be below 4GB.
After this patch, we only put 64-bit prefetchable resources in a 64-bit
prefetchable window. We put all 32-bit prefetchable resources in the
non-prefetchable window, even if there are no 64-bit prefetchable
resources.
With the previous approach, if there was a 32-bit prefetchable resource
behind a bridge, we forced the bridge's prefetchable window below 4GB,
which meant that even if there was plenty of space above 4GB available, we
couldn't use it, and assignment of large 64-bit resources could fail, as
in the bugzilla below.
The new strategy is:
1) If the prefetchable window is 64 bits wide, we put only 64-bit
prefetchable resources in it. Any 32-bit prefetchable resources go in
the non-prefetchable window.
2) If the prefetchable window is 32 bits wide, we put both 32- and 64-bit
prefetchable resources in it.
3) If there is no prefetchable window, all MMIO resources go in the
non-prefetchable window.
This reduces performance for 32-bit prefetchable resources below a bridge
with a 64-bit prefetchable window. We previously assigned prefetchable
space, but now we'll assign non-prefetchable space. This is the case even
if there are no 64-bit prefetchable resources, or if they would all fit
below 4GB. In those cases, the old strategy would work and would have
better performance.
[bhelgaas: write changelog, add bugzilla link, fold in mem64_mask removal]
Link: https://bugzilla.kernel.org/show_bug.cgi?id=74151
Tested-by: Guo Chao <yan@linux.vnet.ibm.com>
Tested-by: Wei Yang <weiyang@linux.vnet.ibm.com>
Signed-off-by: Yinghai Lu <yinghai@kernel.org>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
2014-05-20 03:01:55 +04:00
struct resource * b_res ;
int idx = 1 ;
2010-01-22 12:02:20 +03:00
PCI: Restrict 64-bit prefetchable bridge windows to 64-bit resources
This patch changes the way we handle 64-bit prefetchable bridge windows to
make it more likely that we can assign space to all devices.
Previously we put all prefetchable resources in the prefetchable bridge
window. If any of those resources was 32-bit only, we restricted the
window to be below 4GB.
After this patch, we only put 64-bit prefetchable resources in a 64-bit
prefetchable window. We put all 32-bit prefetchable resources in the
non-prefetchable window, even if there are no 64-bit prefetchable
resources.
With the previous approach, if there was a 32-bit prefetchable resource
behind a bridge, we forced the bridge's prefetchable window below 4GB,
which meant that even if there was plenty of space above 4GB available, we
couldn't use it, and assignment of large 64-bit resources could fail, as
in the bugzilla below.
The new strategy is:
1) If the prefetchable window is 64 bits wide, we put only 64-bit
prefetchable resources in it. Any 32-bit prefetchable resources go in
the non-prefetchable window.
2) If the prefetchable window is 32 bits wide, we put both 32- and 64-bit
prefetchable resources in it.
3) If there is no prefetchable window, all MMIO resources go in the
non-prefetchable window.
This reduces performance for 32-bit prefetchable resources below a bridge
with a 64-bit prefetchable window. We previously assigned prefetchable
space, but now we'll assign non-prefetchable space. This is the case even
if there are no 64-bit prefetchable resources, or if they would all fit
below 4GB. In those cases, the old strategy would work and would have
better performance.
[bhelgaas: write changelog, add bugzilla link, fold in mem64_mask removal]
Link: https://bugzilla.kernel.org/show_bug.cgi?id=74151
Tested-by: Guo Chao <yan@linux.vnet.ibm.com>
Tested-by: Wei Yang <weiyang@linux.vnet.ibm.com>
Signed-off-by: Yinghai Lu <yinghai@kernel.org>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
2014-05-20 03:01:55 +04:00
b_res = & dev - > resource [ PCI_BRIDGE_RESOURCES ] ;
/*
2019-05-07 22:51:24 +03:00
* 1. If IO port assignment fails , release bridge IO port .
* 2. If non pref MMIO assignment fails , release bridge nonpref MMIO .
* 3. If 64 bit pref MMIO assignment fails , and bridge pref is 64 bit ,
* release bridge pref MMIO .
* 4. If pref MMIO assignment fails , and bridge pref is 32 bit ,
* release bridge pref MMIO .
* 5. If pref MMIO assignment fails , and bridge pref is not
* assigned , release bridge nonpref MMIO .
PCI: Restrict 64-bit prefetchable bridge windows to 64-bit resources
This patch changes the way we handle 64-bit prefetchable bridge windows to
make it more likely that we can assign space to all devices.
Previously we put all prefetchable resources in the prefetchable bridge
window. If any of those resources was 32-bit only, we restricted the
window to be below 4GB.
After this patch, we only put 64-bit prefetchable resources in a 64-bit
prefetchable window. We put all 32-bit prefetchable resources in the
non-prefetchable window, even if there are no 64-bit prefetchable
resources.
With the previous approach, if there was a 32-bit prefetchable resource
behind a bridge, we forced the bridge's prefetchable window below 4GB,
which meant that even if there was plenty of space above 4GB available, we
couldn't use it, and assignment of large 64-bit resources could fail, as
in the bugzilla below.
The new strategy is:
1) If the prefetchable window is 64 bits wide, we put only 64-bit
prefetchable resources in it. Any 32-bit prefetchable resources go in
the non-prefetchable window.
2) If the prefetchable window is 32 bits wide, we put both 32- and 64-bit
prefetchable resources in it.
3) If there is no prefetchable window, all MMIO resources go in the
non-prefetchable window.
This reduces performance for 32-bit prefetchable resources below a bridge
with a 64-bit prefetchable window. We previously assigned prefetchable
space, but now we'll assign non-prefetchable space. This is the case even
if there are no 64-bit prefetchable resources, or if they would all fit
below 4GB. In those cases, the old strategy would work and would have
better performance.
[bhelgaas: write changelog, add bugzilla link, fold in mem64_mask removal]
Link: https://bugzilla.kernel.org/show_bug.cgi?id=74151
Tested-by: Guo Chao <yan@linux.vnet.ibm.com>
Tested-by: Wei Yang <weiyang@linux.vnet.ibm.com>
Signed-off-by: Yinghai Lu <yinghai@kernel.org>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
2014-05-20 03:01:55 +04:00
*/
if ( type & IORESOURCE_IO )
idx = 0 ;
else if ( ! ( type & IORESOURCE_PREFETCH ) )
idx = 1 ;
else if ( ( type & IORESOURCE_MEM_64 ) & &
( b_res [ 2 ] . flags & IORESOURCE_MEM_64 ) )
idx = 2 ;
else if ( ! ( b_res [ 2 ] . flags & IORESOURCE_MEM_64 ) & &
( b_res [ 2 ] . flags & IORESOURCE_PREFETCH ) )
idx = 2 ;
else
idx = 1 ;
r = & b_res [ idx ] ;
if ( ! r - > parent )
return ;
2019-05-07 22:51:24 +03:00
/* If there are children, release them all */
PCI: Restrict 64-bit prefetchable bridge windows to 64-bit resources
This patch changes the way we handle 64-bit prefetchable bridge windows to
make it more likely that we can assign space to all devices.
Previously we put all prefetchable resources in the prefetchable bridge
window. If any of those resources was 32-bit only, we restricted the
window to be below 4GB.
After this patch, we only put 64-bit prefetchable resources in a 64-bit
prefetchable window. We put all 32-bit prefetchable resources in the
non-prefetchable window, even if there are no 64-bit prefetchable
resources.
With the previous approach, if there was a 32-bit prefetchable resource
behind a bridge, we forced the bridge's prefetchable window below 4GB,
which meant that even if there was plenty of space above 4GB available, we
couldn't use it, and assignment of large 64-bit resources could fail, as
in the bugzilla below.
The new strategy is:
1) If the prefetchable window is 64 bits wide, we put only 64-bit
prefetchable resources in it. Any 32-bit prefetchable resources go in
the non-prefetchable window.
2) If the prefetchable window is 32 bits wide, we put both 32- and 64-bit
prefetchable resources in it.
3) If there is no prefetchable window, all MMIO resources go in the
non-prefetchable window.
This reduces performance for 32-bit prefetchable resources below a bridge
with a 64-bit prefetchable window. We previously assigned prefetchable
space, but now we'll assign non-prefetchable space. This is the case even
if there are no 64-bit prefetchable resources, or if they would all fit
below 4GB. In those cases, the old strategy would work and would have
better performance.
[bhelgaas: write changelog, add bugzilla link, fold in mem64_mask removal]
Link: https://bugzilla.kernel.org/show_bug.cgi?id=74151
Tested-by: Guo Chao <yan@linux.vnet.ibm.com>
Tested-by: Wei Yang <weiyang@linux.vnet.ibm.com>
Signed-off-by: Yinghai Lu <yinghai@kernel.org>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
2014-05-20 03:01:55 +04:00
release_child_resources ( r ) ;
if ( ! release_resource ( r ) ) {
2017-10-18 16:58:17 +03:00
type = old_flags = r - > flags & PCI_RES_TYPE_MASK ;
2019-04-20 07:07:20 +03:00
pci_info ( dev , " resource %d %pR released \n " ,
PCI_BRIDGE_RESOURCES + idx , r ) ;
2019-05-07 22:51:24 +03:00
/* Keep the old size */
PCI: Restrict 64-bit prefetchable bridge windows to 64-bit resources
This patch changes the way we handle 64-bit prefetchable bridge windows to
make it more likely that we can assign space to all devices.
Previously we put all prefetchable resources in the prefetchable bridge
window. If any of those resources was 32-bit only, we restricted the
window to be below 4GB.
After this patch, we only put 64-bit prefetchable resources in a 64-bit
prefetchable window. We put all 32-bit prefetchable resources in the
non-prefetchable window, even if there are no 64-bit prefetchable
resources.
With the previous approach, if there was a 32-bit prefetchable resource
behind a bridge, we forced the bridge's prefetchable window below 4GB,
which meant that even if there was plenty of space above 4GB available, we
couldn't use it, and assignment of large 64-bit resources could fail, as
in the bugzilla below.
The new strategy is:
1) If the prefetchable window is 64 bits wide, we put only 64-bit
prefetchable resources in it. Any 32-bit prefetchable resources go in
the non-prefetchable window.
2) If the prefetchable window is 32 bits wide, we put both 32- and 64-bit
prefetchable resources in it.
3) If there is no prefetchable window, all MMIO resources go in the
non-prefetchable window.
This reduces performance for 32-bit prefetchable resources below a bridge
with a 64-bit prefetchable window. We previously assigned prefetchable
space, but now we'll assign non-prefetchable space. This is the case even
if there are no 64-bit prefetchable resources, or if they would all fit
below 4GB. In those cases, the old strategy would work and would have
better performance.
[bhelgaas: write changelog, add bugzilla link, fold in mem64_mask removal]
Link: https://bugzilla.kernel.org/show_bug.cgi?id=74151
Tested-by: Guo Chao <yan@linux.vnet.ibm.com>
Tested-by: Wei Yang <weiyang@linux.vnet.ibm.com>
Signed-off-by: Yinghai Lu <yinghai@kernel.org>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
2014-05-20 03:01:55 +04:00
r - > end = resource_size ( r ) - 1 ;
r - > start = 0 ;
r - > flags = 0 ;
2010-01-22 12:02:20 +03:00
2019-05-07 22:51:24 +03:00
/* Avoiding touch the one without PREF */
2010-01-22 12:02:20 +03:00
if ( type & IORESOURCE_PREFETCH )
type = IORESOURCE_PREFETCH ;
__pci_setup_bridge ( bus , type ) ;
2019-05-07 22:51:24 +03:00
/* For next child res under same bridge */
PCI: Restrict 64-bit prefetchable bridge windows to 64-bit resources
This patch changes the way we handle 64-bit prefetchable bridge windows to
make it more likely that we can assign space to all devices.
Previously we put all prefetchable resources in the prefetchable bridge
window. If any of those resources was 32-bit only, we restricted the
window to be below 4GB.
After this patch, we only put 64-bit prefetchable resources in a 64-bit
prefetchable window. We put all 32-bit prefetchable resources in the
non-prefetchable window, even if there are no 64-bit prefetchable
resources.
With the previous approach, if there was a 32-bit prefetchable resource
behind a bridge, we forced the bridge's prefetchable window below 4GB,
which meant that even if there was plenty of space above 4GB available, we
couldn't use it, and assignment of large 64-bit resources could fail, as
in the bugzilla below.
The new strategy is:
1) If the prefetchable window is 64 bits wide, we put only 64-bit
prefetchable resources in it. Any 32-bit prefetchable resources go in
the non-prefetchable window.
2) If the prefetchable window is 32 bits wide, we put both 32- and 64-bit
prefetchable resources in it.
3) If there is no prefetchable window, all MMIO resources go in the
non-prefetchable window.
This reduces performance for 32-bit prefetchable resources below a bridge
with a 64-bit prefetchable window. We previously assigned prefetchable
space, but now we'll assign non-prefetchable space. This is the case even
if there are no 64-bit prefetchable resources, or if they would all fit
below 4GB. In those cases, the old strategy would work and would have
better performance.
[bhelgaas: write changelog, add bugzilla link, fold in mem64_mask removal]
Link: https://bugzilla.kernel.org/show_bug.cgi?id=74151
Tested-by: Guo Chao <yan@linux.vnet.ibm.com>
Tested-by: Wei Yang <weiyang@linux.vnet.ibm.com>
Signed-off-by: Yinghai Lu <yinghai@kernel.org>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
2014-05-20 03:01:55 +04:00
r - > flags = old_flags ;
2010-01-22 12:02:20 +03:00
}
}
enum release_type {
leaf_only ,
whole_subtree ,
} ;
2019-05-07 22:51:24 +03:00
2010-01-22 12:02:20 +03:00
/*
2019-05-07 22:51:24 +03:00
* Try to release PCI bridge resources from leaf bridge , so we can allocate
* a larger window later .
2010-01-22 12:02:20 +03:00
*/
2014-04-15 02:11:40 +04:00
static void pci_bus_release_bridge_resources ( struct pci_bus * bus ,
unsigned long type ,
enum release_type rel_type )
2010-01-22 12:02:20 +03:00
{
struct pci_dev * dev ;
bool is_leaf_bridge = true ;
list_for_each_entry ( dev , & bus - > devices , bus_list ) {
struct pci_bus * b = dev - > subordinate ;
if ( ! b )
continue ;
is_leaf_bridge = false ;
if ( ( dev - > class > > 8 ) ! = PCI_CLASS_BRIDGE_PCI )
continue ;
if ( rel_type = = whole_subtree )
pci_bus_release_bridge_resources ( b , type ,
whole_subtree ) ;
}
if ( pci_is_root_bus ( bus ) )
return ;
if ( ( bus - > self - > class > > 8 ) ! = PCI_CLASS_BRIDGE_PCI )
return ;
if ( ( rel_type = = whole_subtree ) | | is_leaf_bridge )
pci_bridge_release_resources ( bus , type ) ;
}
2008-06-23 22:33:06 +04:00
static void pci_bus_dump_res ( struct pci_bus * bus )
{
2010-02-23 20:24:31 +03:00
struct resource * res ;
int i ;
2009-12-23 02:02:24 +03:00
2010-02-23 20:24:31 +03:00
pci_bus_for_each_resource ( bus , res , i ) {
2009-12-23 02:02:24 +03:00
if ( ! res | | ! res - > end | | ! res - > flags )
2014-04-19 04:13:49 +04:00
continue ;
2008-06-23 22:33:06 +04:00
2019-04-20 07:07:20 +03:00
dev_info ( & bus - > dev , " resource %d %pR \n " , i , res ) ;
2014-04-19 04:13:49 +04:00
}
2008-06-23 22:33:06 +04:00
}
static void pci_bus_dump_resources ( struct pci_bus * bus )
{
struct pci_bus * b ;
struct pci_dev * dev ;
pci_bus_dump_res ( bus ) ;
list_for_each_entry ( dev , & bus - > devices , bus_list ) {
b = dev - > subordinate ;
if ( ! b )
continue ;
pci_bus_dump_resources ( b ) ;
}
}
2013-07-25 01:37:13 +04:00
static int pci_bus_get_depth ( struct pci_bus * bus )
2011-05-13 04:11:37 +04:00
{
int depth = 0 ;
2013-08-02 13:31:03 +04:00
struct pci_bus * child_bus ;
2011-05-13 04:11:37 +04:00
2014-04-19 04:13:49 +04:00
list_for_each_entry ( child_bus , & bus - > children , node ) {
2011-05-13 04:11:37 +04:00
int ret ;
2013-08-02 13:31:03 +04:00
ret = pci_bus_get_depth ( child_bus ) ;
2011-05-13 04:11:37 +04:00
if ( ret + 1 > depth )
depth = ret + 1 ;
}
return depth ;
}
2012-02-24 07:23:30 +04:00
/*
* - 1 : undefined , will auto detect later
* 0 : disabled by user
* 1 : disabled by auto detect
* 2 : enabled by user
* 3 : enabled by auto detect
*/
enum enable_type {
undefined = - 1 ,
user_disabled ,
auto_disabled ,
user_enabled ,
auto_enabled ,
} ;
2013-07-25 01:37:13 +04:00
static enum enable_type pci_realloc_enable = undefined ;
2012-02-24 07:23:30 +04:00
void __init pci_realloc_get_opt ( char * str )
{
if ( ! strncmp ( str , " off " , 3 ) )
pci_realloc_enable = user_disabled ;
else if ( ! strncmp ( str , " on " , 2 ) )
pci_realloc_enable = user_enabled ;
}
2013-07-25 01:37:13 +04:00
static bool pci_realloc_enabled ( enum enable_type enable )
2012-02-24 07:23:30 +04:00
{
2013-07-23 01:37:15 +04:00
return enable > = user_enabled ;
2012-02-24 07:23:30 +04:00
}
2011-07-07 22:19:10 +04:00
2012-02-24 07:23:32 +04:00
# if defined(CONFIG_PCI_IOV) && defined(CONFIG_PCI_REALLOC_ENABLE_AUTO)
2013-07-25 01:37:13 +04:00
static int iov_resources_unassigned ( struct pci_dev * dev , void * data )
2013-07-23 01:37:13 +04:00
{
int i ;
bool * unassigned = data ;
2012-02-24 07:23:32 +04:00
2019-08-06 17:07:15 +03:00
for ( i = 0 ; i < PCI_SRIOV_NUM_BARS ; i + + ) {
struct resource * r = & dev - > resource [ i + PCI_IOV_RESOURCES ] ;
2013-07-23 01:37:14 +04:00
struct pci_bus_region region ;
2012-02-24 07:23:32 +04:00
2013-07-23 01:37:13 +04:00
/* Not assigned or rejected by kernel? */
2013-07-23 01:37:14 +04:00
if ( ! r - > flags )
continue ;
2012-02-24 07:23:32 +04:00
PCI: Convert pcibios_resource_to_bus() to take a pci_bus, not a pci_dev
These interfaces:
pcibios_resource_to_bus(struct pci_dev *dev, *bus_region, *resource)
pcibios_bus_to_resource(struct pci_dev *dev, *resource, *bus_region)
took a pci_dev, but they really depend only on the pci_bus. And we want to
use them in resource allocation paths where we have the bus but not a
device, so this patch converts them to take the pci_bus instead of the
pci_dev:
pcibios_resource_to_bus(struct pci_bus *bus, *bus_region, *resource)
pcibios_bus_to_resource(struct pci_bus *bus, *resource, *bus_region)
In fact, with standard PCI-PCI bridges, they only depend on the host
bridge, because that's the only place address translation occurs, but
we aren't going that far yet.
[bhelgaas: changelog]
Signed-off-by: Yinghai Lu <yinghai@kernel.org>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
2013-12-10 10:54:40 +04:00
pcibios_resource_to_bus ( dev - > bus , & region , r ) ;
2013-07-23 01:37:14 +04:00
if ( ! region . start ) {
2013-07-23 01:37:13 +04:00
* unassigned = true ;
2019-05-07 22:51:24 +03:00
return 1 ; /* Return early from pci_walk_bus() */
2012-02-24 07:23:32 +04:00
}
}
2013-07-23 01:37:13 +04:00
return 0 ;
2012-02-24 07:23:32 +04:00
}
2013-07-25 01:37:13 +04:00
static enum enable_type pci_realloc_detect ( struct pci_bus * bus ,
2019-05-07 22:51:24 +03:00
enum enable_type enable_local )
2013-07-23 01:37:13 +04:00
{
bool unassigned = false ;
2019-06-15 03:23:58 +03:00
struct pci_host_bridge * host ;
2012-02-24 07:23:32 +04:00
2013-07-23 01:37:15 +04:00
if ( enable_local ! = undefined )
return enable_local ;
2013-07-23 01:37:13 +04:00
2019-06-15 03:23:58 +03:00
host = pci_find_host_bridge ( bus ) ;
if ( host - > preserve_config )
return auto_disabled ;
2013-07-23 01:37:15 +04:00
pci_walk_bus ( bus , iov_resources_unassigned , & unassigned ) ;
if ( unassigned )
return auto_enabled ;
return enable_local ;
2012-02-24 07:23:32 +04:00
}
2013-07-23 01:37:13 +04:00
# else
2013-07-25 01:37:13 +04:00
static enum enable_type pci_realloc_detect ( struct pci_bus * bus ,
2019-05-07 22:51:24 +03:00
enum enable_type enable_local )
2013-07-23 01:37:15 +04:00
{
return enable_local ;
2012-02-24 07:23:32 +04:00
}
2013-07-23 01:37:13 +04:00
# endif
2012-02-24 07:23:32 +04:00
2020-01-06 18:47:26 +03:00
static void adjust_bridge_window ( struct pci_dev * bridge , struct resource * res ,
2019-05-07 22:51:24 +03:00
struct list_head * add_list ,
2020-01-06 18:47:05 +03:00
resource_size_t new_size )
2017-10-13 21:35:45 +03:00
{
2020-01-06 18:48:06 +03:00
resource_size_t add_size , size = resource_size ( res ) ;
2017-10-13 21:35:45 +03:00
if ( res - > parent )
return ;
2020-01-06 18:48:06 +03:00
if ( ! new_size )
2017-10-13 21:35:45 +03:00
return ;
2020-01-06 18:48:06 +03:00
if ( new_size > size ) {
add_size = new_size - size ;
pci_dbg ( bridge , " bridge window %pR extended by %pa \n " , res ,
& add_size ) ;
} else if ( new_size < size ) {
add_size = size - new_size ;
pci_dbg ( bridge , " bridge window %pR shrunken by %pa \n " , res ,
& add_size ) ;
PCI: Take other bus devices into account when distributing resources
A PCI bridge may reside on a bus with other devices as well. The resource
distribution code does not take this into account and therefore it expands
the bridge resource windows too much, not leaving space for the other
devices (or functions of a multifunction device). This leads to an issue
that Jonathan reported when running QEMU with the following topology (QEMU
parameters):
-device pcie-root-port,port=0,id=root_port13,chassis=0,slot=2 \
-device x3130-upstream,id=sw1,bus=root_port13,multifunction=on \
-device e1000,bus=root_port13,addr=0.1 \
-device xio3130-downstream,id=fun1,bus=sw1,chassis=0,slot=3 \
-device e1000,bus=fun1
The first e1000 NIC here is another function in the switch upstream port.
This leads to following errors:
pci 0000:00:04.0: bridge window [mem 0x10200000-0x103fffff] to [bus 02-04]
pci 0000:02:00.0: bridge window [mem 0x10200000-0x103fffff] to [bus 03-04]
pci 0000:02:00.1: BAR 0: failed to assign [mem size 0x00020000]
e1000 0000:02:00.1: can't ioremap BAR 0: [??? 0x00000000 flags 0x0]
Fix this by taking into account bridge windows, device BARs and SR-IOV PF
BARs on the bus (PF BARs include space for VF BARS so only account PF
BARs), including the ones belonging to bridges themselves if it has any.
Link: https://lore.kernel.org/linux-pci/20221014124553.0000696f@huawei.com/
Link: https://lore.kernel.org/linux-pci/6053736d-1923-41e7-def9-7585ce1772d9@ixsystems.com/
Link: https://lore.kernel.org/r/20230131092405.29121-3-mika.westerberg@linux.intel.com
Reported-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Reported-by: Alexander Motin <mav@ixsystems.com>
Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
2023-01-31 12:24:04 +03:00
} else {
return ;
2020-01-06 18:48:06 +03:00
}
2020-01-06 18:47:46 +03:00
res - > end = res - > start + new_size - 1 ;
2023-01-31 12:24:05 +03:00
/* If the resource is part of the add_list, remove it now */
if ( add_list )
remove_from_list ( add_list , res ) ;
2017-10-13 21:35:45 +03:00
}
PCI: Take other bus devices into account when distributing resources
A PCI bridge may reside on a bus with other devices as well. The resource
distribution code does not take this into account and therefore it expands
the bridge resource windows too much, not leaving space for the other
devices (or functions of a multifunction device). This leads to an issue
that Jonathan reported when running QEMU with the following topology (QEMU
parameters):
-device pcie-root-port,port=0,id=root_port13,chassis=0,slot=2 \
-device x3130-upstream,id=sw1,bus=root_port13,multifunction=on \
-device e1000,bus=root_port13,addr=0.1 \
-device xio3130-downstream,id=fun1,bus=sw1,chassis=0,slot=3 \
-device e1000,bus=fun1
The first e1000 NIC here is another function in the switch upstream port.
This leads to following errors:
pci 0000:00:04.0: bridge window [mem 0x10200000-0x103fffff] to [bus 02-04]
pci 0000:02:00.0: bridge window [mem 0x10200000-0x103fffff] to [bus 03-04]
pci 0000:02:00.1: BAR 0: failed to assign [mem size 0x00020000]
e1000 0000:02:00.1: can't ioremap BAR 0: [??? 0x00000000 flags 0x0]
Fix this by taking into account bridge windows, device BARs and SR-IOV PF
BARs on the bus (PF BARs include space for VF BARS so only account PF
BARs), including the ones belonging to bridges themselves if it has any.
Link: https://lore.kernel.org/linux-pci/20221014124553.0000696f@huawei.com/
Link: https://lore.kernel.org/linux-pci/6053736d-1923-41e7-def9-7585ce1772d9@ixsystems.com/
Link: https://lore.kernel.org/r/20230131092405.29121-3-mika.westerberg@linux.intel.com
Reported-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Reported-by: Alexander Motin <mav@ixsystems.com>
Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
2023-01-31 12:24:04 +03:00
static void remove_dev_resource ( struct resource * avail , struct pci_dev * dev ,
struct resource * res )
{
resource_size_t size , align , tmp ;
size = resource_size ( res ) ;
if ( ! size )
return ;
align = pci_resource_alignment ( dev , res ) ;
align = align ? ALIGN ( avail - > start , align ) - avail - > start : 0 ;
tmp = align + size ;
avail - > start = min ( avail - > start + tmp , avail - > end + 1 ) ;
}
static void remove_dev_resources ( struct pci_dev * dev , struct resource * io ,
struct resource * mmio ,
struct resource * mmio_pref )
{
int i ;
for ( i = 0 ; i < PCI_NUM_RESOURCES ; i + + ) {
struct resource * res = & dev - > resource [ i ] ;
if ( resource_type ( res ) = = IORESOURCE_IO ) {
remove_dev_resource ( io , dev , res ) ;
} else if ( resource_type ( res ) = = IORESOURCE_MEM ) {
/*
* Make sure prefetchable memory is reduced from
* the correct resource . Specifically we put 32 - bit
* prefetchable memory in non - prefetchable window
* if there is an 64 - bit pretchable window .
*
* See comments in __pci_bus_size_bridges ( ) for
* more information .
*/
if ( ( res - > flags & IORESOURCE_PREFETCH ) & &
( ( res - > flags & IORESOURCE_MEM_64 ) = =
( mmio_pref - > flags & IORESOURCE_MEM_64 ) ) )
remove_dev_resource ( mmio_pref , dev , res ) ;
else
remove_dev_resource ( mmio , dev , res ) ;
}
}
}
/*
* io , mmio and mmio_pref contain the total amount of bridge window space
* available . This includes the minimal space needed to cover all the
* existing devices on the bus and the possible extra space that can be
* shared with the bridges .
*/
2017-10-13 21:35:45 +03:00
static void pci_bus_distribute_available_resources ( struct pci_bus * bus ,
2019-05-07 22:51:24 +03:00
struct list_head * add_list ,
2020-01-06 18:45:52 +03:00
struct resource io ,
struct resource mmio ,
struct resource mmio_pref )
2017-10-13 21:35:45 +03:00
{
unsigned int normal_bridges = 0 , hotplug_bridges = 0 ;
struct resource * io_res , * mmio_res , * mmio_pref_res ;
struct pci_dev * dev , * bridge = bus - > self ;
PCI: Take other bus devices into account when distributing resources
A PCI bridge may reside on a bus with other devices as well. The resource
distribution code does not take this into account and therefore it expands
the bridge resource windows too much, not leaving space for the other
devices (or functions of a multifunction device). This leads to an issue
that Jonathan reported when running QEMU with the following topology (QEMU
parameters):
-device pcie-root-port,port=0,id=root_port13,chassis=0,slot=2 \
-device x3130-upstream,id=sw1,bus=root_port13,multifunction=on \
-device e1000,bus=root_port13,addr=0.1 \
-device xio3130-downstream,id=fun1,bus=sw1,chassis=0,slot=3 \
-device e1000,bus=fun1
The first e1000 NIC here is another function in the switch upstream port.
This leads to following errors:
pci 0000:00:04.0: bridge window [mem 0x10200000-0x103fffff] to [bus 02-04]
pci 0000:02:00.0: bridge window [mem 0x10200000-0x103fffff] to [bus 03-04]
pci 0000:02:00.1: BAR 0: failed to assign [mem size 0x00020000]
e1000 0000:02:00.1: can't ioremap BAR 0: [??? 0x00000000 flags 0x0]
Fix this by taking into account bridge windows, device BARs and SR-IOV PF
BARs on the bus (PF BARs include space for VF BARS so only account PF
BARs), including the ones belonging to bridges themselves if it has any.
Link: https://lore.kernel.org/linux-pci/20221014124553.0000696f@huawei.com/
Link: https://lore.kernel.org/linux-pci/6053736d-1923-41e7-def9-7585ce1772d9@ixsystems.com/
Link: https://lore.kernel.org/r/20230131092405.29121-3-mika.westerberg@linux.intel.com
Reported-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Reported-by: Alexander Motin <mav@ixsystems.com>
Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
2023-01-31 12:24:04 +03:00
resource_size_t io_per_b , mmio_per_b , mmio_pref_per_b , align ;
2017-10-13 21:35:45 +03:00
2020-05-20 21:34:10 +03:00
io_res = & bridge - > resource [ PCI_BRIDGE_IO_WINDOW ] ;
mmio_res = & bridge - > resource [ PCI_BRIDGE_MEM_WINDOW ] ;
mmio_pref_res = & bridge - > resource [ PCI_BRIDGE_PREF_MEM_WINDOW ] ;
2017-10-13 21:35:45 +03:00
PCI: Consider alignment of hot-added bridges when assigning resources
Change pci_bus_distribute_available_resources() to better handle bridges
with different resource alignment requirements.
The arguments io, mmio and mmio_pref represent the start and end
addresses of resource, into which we must fit the current bridge window.
The steps taken by pci_bus_distribute_available_resources():
- For io, mmio and mmio_pref, increase .start to align with the alignment
of the current bridge window (otherwise the current bridge window may
not fit within the available range).
- For io, mmio and mmio_pref, adjust the current bridge window to the
size after the above.
- Count the number of hotplug bridges and normal bridges on this bus.
- If the total number of bridges is one, give that bridge all of the
resources and return.
- If there are no hotplug bridges, return.
- For io, mmio and mmio_pref, increase .start by the amount required for
each bridge resource on the bus for non hotplug bridges, giving extra
room to make up for alignment of those resources.
- For io, mmio and mmio_pref, calculate the resource size per hotplug
bridge which is available after the previous steps.
- For io, mmio and mmio_pref, distribute the resources to each hotplug
bridge, with the sizes calculated above.
The motivation for fixing this is enabling devices that require greater
than 1MB alignment. This fixes the case where the user hot-adds devices
with BAR alignment >1MB and Linux fails to assign resources to it.
Link: https://bugzilla.kernel.org/show_bug.cgi?id=199581
Link: https://lore.kernel.org/r/PSXP216MB0438C2BFD0FD3691ED9C83F4803C0@PSXP216MB0438.KORP216.PROD.OUTLOOK.COM
Reported-by: Mika Westerberg <mika.westerberg@linux.intel.com>
Signed-off-by: Nicholas Johnson <nicholas.johnson-opensource@outlook.com.au>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Reviewed-by: Mika Westerberg <mika.westerberg@linux.intel.com>
2020-01-06 18:46:13 +03:00
/*
* The alignment of this bridge is yet to be considered , hence it must
* be done now before extending its bridge window .
*/
align = pci_resource_alignment ( bridge , io_res ) ;
if ( ! io_res - > parent & & align )
io . start = min ( ALIGN ( io . start , align ) , io . end + 1 ) ;
align = pci_resource_alignment ( bridge , mmio_res ) ;
if ( ! mmio_res - > parent & & align )
mmio . start = min ( ALIGN ( mmio . start , align ) , mmio . end + 1 ) ;
align = pci_resource_alignment ( bridge , mmio_pref_res ) ;
if ( ! mmio_pref_res - > parent & & align )
mmio_pref . start = min ( ALIGN ( mmio_pref . start , align ) ,
mmio_pref . end + 1 ) ;
2017-10-13 21:35:45 +03:00
/*
2020-01-06 18:47:46 +03:00
* Now that we have adjusted for alignment , update the bridge window
* resources to fill as much remaining resource space as possible .
2017-10-13 21:35:45 +03:00
*/
2020-01-06 18:47:26 +03:00
adjust_bridge_window ( bridge , io_res , add_list , resource_size ( & io ) ) ;
adjust_bridge_window ( bridge , mmio_res , add_list , resource_size ( & mmio ) ) ;
adjust_bridge_window ( bridge , mmio_pref_res , add_list ,
2020-01-29 00:57:09 +03:00
resource_size ( & mmio_pref ) ) ;
2017-10-13 21:35:45 +03:00
/*
* Calculate how many hotplug bridges and normal bridges there
2019-05-07 22:51:24 +03:00
* are on this bus . We will distribute the additional available
2017-10-13 21:35:45 +03:00
* resources between hotplug bridges .
*/
for_each_pci_bridge ( dev , bus ) {
if ( dev - > is_hotplug_bridge )
hotplug_bridges + + ;
else
normal_bridges + + ;
}
PCI: Take other bus devices into account when distributing resources
A PCI bridge may reside on a bus with other devices as well. The resource
distribution code does not take this into account and therefore it expands
the bridge resource windows too much, not leaving space for the other
devices (or functions of a multifunction device). This leads to an issue
that Jonathan reported when running QEMU with the following topology (QEMU
parameters):
-device pcie-root-port,port=0,id=root_port13,chassis=0,slot=2 \
-device x3130-upstream,id=sw1,bus=root_port13,multifunction=on \
-device e1000,bus=root_port13,addr=0.1 \
-device xio3130-downstream,id=fun1,bus=sw1,chassis=0,slot=3 \
-device e1000,bus=fun1
The first e1000 NIC here is another function in the switch upstream port.
This leads to following errors:
pci 0000:00:04.0: bridge window [mem 0x10200000-0x103fffff] to [bus 02-04]
pci 0000:02:00.0: bridge window [mem 0x10200000-0x103fffff] to [bus 03-04]
pci 0000:02:00.1: BAR 0: failed to assign [mem size 0x00020000]
e1000 0000:02:00.1: can't ioremap BAR 0: [??? 0x00000000 flags 0x0]
Fix this by taking into account bridge windows, device BARs and SR-IOV PF
BARs on the bus (PF BARs include space for VF BARS so only account PF
BARs), including the ones belonging to bridges themselves if it has any.
Link: https://lore.kernel.org/linux-pci/20221014124553.0000696f@huawei.com/
Link: https://lore.kernel.org/linux-pci/6053736d-1923-41e7-def9-7585ce1772d9@ixsystems.com/
Link: https://lore.kernel.org/r/20230131092405.29121-3-mika.westerberg@linux.intel.com
Reported-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Reported-by: Alexander Motin <mav@ixsystems.com>
Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
2023-01-31 12:24:04 +03:00
if ( ! ( hotplug_bridges + normal_bridges ) )
2019-06-22 20:13:50 +03:00
return ;
2019-06-22 19:43:46 +03:00
/*
PCI: Take other bus devices into account when distributing resources
A PCI bridge may reside on a bus with other devices as well. The resource
distribution code does not take this into account and therefore it expands
the bridge resource windows too much, not leaving space for the other
devices (or functions of a multifunction device). This leads to an issue
that Jonathan reported when running QEMU with the following topology (QEMU
parameters):
-device pcie-root-port,port=0,id=root_port13,chassis=0,slot=2 \
-device x3130-upstream,id=sw1,bus=root_port13,multifunction=on \
-device e1000,bus=root_port13,addr=0.1 \
-device xio3130-downstream,id=fun1,bus=sw1,chassis=0,slot=3 \
-device e1000,bus=fun1
The first e1000 NIC here is another function in the switch upstream port.
This leads to following errors:
pci 0000:00:04.0: bridge window [mem 0x10200000-0x103fffff] to [bus 02-04]
pci 0000:02:00.0: bridge window [mem 0x10200000-0x103fffff] to [bus 03-04]
pci 0000:02:00.1: BAR 0: failed to assign [mem size 0x00020000]
e1000 0000:02:00.1: can't ioremap BAR 0: [??? 0x00000000 flags 0x0]
Fix this by taking into account bridge windows, device BARs and SR-IOV PF
BARs on the bus (PF BARs include space for VF BARS so only account PF
BARs), including the ones belonging to bridges themselves if it has any.
Link: https://lore.kernel.org/linux-pci/20221014124553.0000696f@huawei.com/
Link: https://lore.kernel.org/linux-pci/6053736d-1923-41e7-def9-7585ce1772d9@ixsystems.com/
Link: https://lore.kernel.org/r/20230131092405.29121-3-mika.westerberg@linux.intel.com
Reported-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Reported-by: Alexander Motin <mav@ixsystems.com>
Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
2023-01-31 12:24:04 +03:00
* Calculate the amount of space we can forward from " bus " to any
* downstream buses , i . e . , the space left over after assigning the
* BARs and windows on " bus " .
2019-06-22 19:43:46 +03:00
*/
PCI: Take other bus devices into account when distributing resources
A PCI bridge may reside on a bus with other devices as well. The resource
distribution code does not take this into account and therefore it expands
the bridge resource windows too much, not leaving space for the other
devices (or functions of a multifunction device). This leads to an issue
that Jonathan reported when running QEMU with the following topology (QEMU
parameters):
-device pcie-root-port,port=0,id=root_port13,chassis=0,slot=2 \
-device x3130-upstream,id=sw1,bus=root_port13,multifunction=on \
-device e1000,bus=root_port13,addr=0.1 \
-device xio3130-downstream,id=fun1,bus=sw1,chassis=0,slot=3 \
-device e1000,bus=fun1
The first e1000 NIC here is another function in the switch upstream port.
This leads to following errors:
pci 0000:00:04.0: bridge window [mem 0x10200000-0x103fffff] to [bus 02-04]
pci 0000:02:00.0: bridge window [mem 0x10200000-0x103fffff] to [bus 03-04]
pci 0000:02:00.1: BAR 0: failed to assign [mem size 0x00020000]
e1000 0000:02:00.1: can't ioremap BAR 0: [??? 0x00000000 flags 0x0]
Fix this by taking into account bridge windows, device BARs and SR-IOV PF
BARs on the bus (PF BARs include space for VF BARS so only account PF
BARs), including the ones belonging to bridges themselves if it has any.
Link: https://lore.kernel.org/linux-pci/20221014124553.0000696f@huawei.com/
Link: https://lore.kernel.org/linux-pci/6053736d-1923-41e7-def9-7585ce1772d9@ixsystems.com/
Link: https://lore.kernel.org/r/20230131092405.29121-3-mika.westerberg@linux.intel.com
Reported-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Reported-by: Alexander Motin <mav@ixsystems.com>
Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
2023-01-31 12:24:04 +03:00
list_for_each_entry ( dev , & bus - > devices , bus_list ) {
if ( ! dev - > is_virtfn )
remove_dev_resources ( dev , & io , & mmio , & mmio_pref ) ;
2017-10-13 21:35:45 +03:00
}
/*
PCI: Take other bus devices into account when distributing resources
A PCI bridge may reside on a bus with other devices as well. The resource
distribution code does not take this into account and therefore it expands
the bridge resource windows too much, not leaving space for the other
devices (or functions of a multifunction device). This leads to an issue
that Jonathan reported when running QEMU with the following topology (QEMU
parameters):
-device pcie-root-port,port=0,id=root_port13,chassis=0,slot=2 \
-device x3130-upstream,id=sw1,bus=root_port13,multifunction=on \
-device e1000,bus=root_port13,addr=0.1 \
-device xio3130-downstream,id=fun1,bus=sw1,chassis=0,slot=3 \
-device e1000,bus=fun1
The first e1000 NIC here is another function in the switch upstream port.
This leads to following errors:
pci 0000:00:04.0: bridge window [mem 0x10200000-0x103fffff] to [bus 02-04]
pci 0000:02:00.0: bridge window [mem 0x10200000-0x103fffff] to [bus 03-04]
pci 0000:02:00.1: BAR 0: failed to assign [mem size 0x00020000]
e1000 0000:02:00.1: can't ioremap BAR 0: [??? 0x00000000 flags 0x0]
Fix this by taking into account bridge windows, device BARs and SR-IOV PF
BARs on the bus (PF BARs include space for VF BARS so only account PF
BARs), including the ones belonging to bridges themselves if it has any.
Link: https://lore.kernel.org/linux-pci/20221014124553.0000696f@huawei.com/
Link: https://lore.kernel.org/linux-pci/6053736d-1923-41e7-def9-7585ce1772d9@ixsystems.com/
Link: https://lore.kernel.org/r/20230131092405.29121-3-mika.westerberg@linux.intel.com
Reported-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Reported-by: Alexander Motin <mav@ixsystems.com>
Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
2023-01-31 12:24:04 +03:00
* If there is at least one hotplug bridge on this bus it gets all
* the extra resource space that was left after the reductions
* above .
*
* If there are no hotplug bridges the extra resource space is
* split between non - hotplug bridges . This is to allow possible
* hotplug bridges below them to get the extra space as well .
2017-10-13 21:35:45 +03:00
*/
PCI: Take other bus devices into account when distributing resources
A PCI bridge may reside on a bus with other devices as well. The resource
distribution code does not take this into account and therefore it expands
the bridge resource windows too much, not leaving space for the other
devices (or functions of a multifunction device). This leads to an issue
that Jonathan reported when running QEMU with the following topology (QEMU
parameters):
-device pcie-root-port,port=0,id=root_port13,chassis=0,slot=2 \
-device x3130-upstream,id=sw1,bus=root_port13,multifunction=on \
-device e1000,bus=root_port13,addr=0.1 \
-device xio3130-downstream,id=fun1,bus=sw1,chassis=0,slot=3 \
-device e1000,bus=fun1
The first e1000 NIC here is another function in the switch upstream port.
This leads to following errors:
pci 0000:00:04.0: bridge window [mem 0x10200000-0x103fffff] to [bus 02-04]
pci 0000:02:00.0: bridge window [mem 0x10200000-0x103fffff] to [bus 03-04]
pci 0000:02:00.1: BAR 0: failed to assign [mem size 0x00020000]
e1000 0000:02:00.1: can't ioremap BAR 0: [??? 0x00000000 flags 0x0]
Fix this by taking into account bridge windows, device BARs and SR-IOV PF
BARs on the bus (PF BARs include space for VF BARS so only account PF
BARs), including the ones belonging to bridges themselves if it has any.
Link: https://lore.kernel.org/linux-pci/20221014124553.0000696f@huawei.com/
Link: https://lore.kernel.org/linux-pci/6053736d-1923-41e7-def9-7585ce1772d9@ixsystems.com/
Link: https://lore.kernel.org/r/20230131092405.29121-3-mika.westerberg@linux.intel.com
Reported-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Reported-by: Alexander Motin <mav@ixsystems.com>
Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
2023-01-31 12:24:04 +03:00
if ( hotplug_bridges ) {
io_per_b = div64_ul ( resource_size ( & io ) , hotplug_bridges ) ;
mmio_per_b = div64_ul ( resource_size ( & mmio ) , hotplug_bridges ) ;
mmio_pref_per_b = div64_ul ( resource_size ( & mmio_pref ) ,
hotplug_bridges ) ;
} else {
io_per_b = div64_ul ( resource_size ( & io ) , normal_bridges ) ;
mmio_per_b = div64_ul ( resource_size ( & mmio ) , normal_bridges ) ;
mmio_pref_per_b = div64_ul ( resource_size ( & mmio_pref ) ,
normal_bridges ) ;
}
2017-10-13 21:35:45 +03:00
for_each_pci_bridge ( dev , bus ) {
2023-01-31 12:24:03 +03:00
struct resource * res ;
2017-10-13 21:35:45 +03:00
struct pci_bus * b ;
b = dev - > subordinate ;
PCI: Take other bus devices into account when distributing resources
A PCI bridge may reside on a bus with other devices as well. The resource
distribution code does not take this into account and therefore it expands
the bridge resource windows too much, not leaving space for the other
devices (or functions of a multifunction device). This leads to an issue
that Jonathan reported when running QEMU with the following topology (QEMU
parameters):
-device pcie-root-port,port=0,id=root_port13,chassis=0,slot=2 \
-device x3130-upstream,id=sw1,bus=root_port13,multifunction=on \
-device e1000,bus=root_port13,addr=0.1 \
-device xio3130-downstream,id=fun1,bus=sw1,chassis=0,slot=3 \
-device e1000,bus=fun1
The first e1000 NIC here is another function in the switch upstream port.
This leads to following errors:
pci 0000:00:04.0: bridge window [mem 0x10200000-0x103fffff] to [bus 02-04]
pci 0000:02:00.0: bridge window [mem 0x10200000-0x103fffff] to [bus 03-04]
pci 0000:02:00.1: BAR 0: failed to assign [mem size 0x00020000]
e1000 0000:02:00.1: can't ioremap BAR 0: [??? 0x00000000 flags 0x0]
Fix this by taking into account bridge windows, device BARs and SR-IOV PF
BARs on the bus (PF BARs include space for VF BARS so only account PF
BARs), including the ones belonging to bridges themselves if it has any.
Link: https://lore.kernel.org/linux-pci/20221014124553.0000696f@huawei.com/
Link: https://lore.kernel.org/linux-pci/6053736d-1923-41e7-def9-7585ce1772d9@ixsystems.com/
Link: https://lore.kernel.org/r/20230131092405.29121-3-mika.westerberg@linux.intel.com
Reported-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Reported-by: Alexander Motin <mav@ixsystems.com>
Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
2023-01-31 12:24:04 +03:00
if ( ! b )
2017-10-13 21:35:45 +03:00
continue ;
PCI: Take other bus devices into account when distributing resources
A PCI bridge may reside on a bus with other devices as well. The resource
distribution code does not take this into account and therefore it expands
the bridge resource windows too much, not leaving space for the other
devices (or functions of a multifunction device). This leads to an issue
that Jonathan reported when running QEMU with the following topology (QEMU
parameters):
-device pcie-root-port,port=0,id=root_port13,chassis=0,slot=2 \
-device x3130-upstream,id=sw1,bus=root_port13,multifunction=on \
-device e1000,bus=root_port13,addr=0.1 \
-device xio3130-downstream,id=fun1,bus=sw1,chassis=0,slot=3 \
-device e1000,bus=fun1
The first e1000 NIC here is another function in the switch upstream port.
This leads to following errors:
pci 0000:00:04.0: bridge window [mem 0x10200000-0x103fffff] to [bus 02-04]
pci 0000:02:00.0: bridge window [mem 0x10200000-0x103fffff] to [bus 03-04]
pci 0000:02:00.1: BAR 0: failed to assign [mem size 0x00020000]
e1000 0000:02:00.1: can't ioremap BAR 0: [??? 0x00000000 flags 0x0]
Fix this by taking into account bridge windows, device BARs and SR-IOV PF
BARs on the bus (PF BARs include space for VF BARS so only account PF
BARs), including the ones belonging to bridges themselves if it has any.
Link: https://lore.kernel.org/linux-pci/20221014124553.0000696f@huawei.com/
Link: https://lore.kernel.org/linux-pci/6053736d-1923-41e7-def9-7585ce1772d9@ixsystems.com/
Link: https://lore.kernel.org/r/20230131092405.29121-3-mika.westerberg@linux.intel.com
Reported-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Reported-by: Alexander Motin <mav@ixsystems.com>
Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
2023-01-31 12:24:04 +03:00
if ( hotplug_bridges & & ! dev - > is_hotplug_bridge )
continue ;
res = & dev - > resource [ PCI_BRIDGE_IO_WINDOW ] ;
2017-10-13 21:35:45 +03:00
2018-05-28 15:47:55 +03:00
/*
PCI: Take other bus devices into account when distributing resources
A PCI bridge may reside on a bus with other devices as well. The resource
distribution code does not take this into account and therefore it expands
the bridge resource windows too much, not leaving space for the other
devices (or functions of a multifunction device). This leads to an issue
that Jonathan reported when running QEMU with the following topology (QEMU
parameters):
-device pcie-root-port,port=0,id=root_port13,chassis=0,slot=2 \
-device x3130-upstream,id=sw1,bus=root_port13,multifunction=on \
-device e1000,bus=root_port13,addr=0.1 \
-device xio3130-downstream,id=fun1,bus=sw1,chassis=0,slot=3 \
-device e1000,bus=fun1
The first e1000 NIC here is another function in the switch upstream port.
This leads to following errors:
pci 0000:00:04.0: bridge window [mem 0x10200000-0x103fffff] to [bus 02-04]
pci 0000:02:00.0: bridge window [mem 0x10200000-0x103fffff] to [bus 03-04]
pci 0000:02:00.1: BAR 0: failed to assign [mem size 0x00020000]
e1000 0000:02:00.1: can't ioremap BAR 0: [??? 0x00000000 flags 0x0]
Fix this by taking into account bridge windows, device BARs and SR-IOV PF
BARs on the bus (PF BARs include space for VF BARS so only account PF
BARs), including the ones belonging to bridges themselves if it has any.
Link: https://lore.kernel.org/linux-pci/20221014124553.0000696f@huawei.com/
Link: https://lore.kernel.org/linux-pci/6053736d-1923-41e7-def9-7585ce1772d9@ixsystems.com/
Link: https://lore.kernel.org/r/20230131092405.29121-3-mika.westerberg@linux.intel.com
Reported-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Reported-by: Alexander Motin <mav@ixsystems.com>
Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
2023-01-31 12:24:04 +03:00
* Make sure the split resource space is properly aligned
* for bridge windows ( align it down to avoid going above
* what is available ) .
2018-05-28 15:47:55 +03:00
*/
2023-01-31 12:24:03 +03:00
align = pci_resource_alignment ( dev , res ) ;
PCI: Take other bus devices into account when distributing resources
A PCI bridge may reside on a bus with other devices as well. The resource
distribution code does not take this into account and therefore it expands
the bridge resource windows too much, not leaving space for the other
devices (or functions of a multifunction device). This leads to an issue
that Jonathan reported when running QEMU with the following topology (QEMU
parameters):
-device pcie-root-port,port=0,id=root_port13,chassis=0,slot=2 \
-device x3130-upstream,id=sw1,bus=root_port13,multifunction=on \
-device e1000,bus=root_port13,addr=0.1 \
-device xio3130-downstream,id=fun1,bus=sw1,chassis=0,slot=3 \
-device e1000,bus=fun1
The first e1000 NIC here is another function in the switch upstream port.
This leads to following errors:
pci 0000:00:04.0: bridge window [mem 0x10200000-0x103fffff] to [bus 02-04]
pci 0000:02:00.0: bridge window [mem 0x10200000-0x103fffff] to [bus 03-04]
pci 0000:02:00.1: BAR 0: failed to assign [mem size 0x00020000]
e1000 0000:02:00.1: can't ioremap BAR 0: [??? 0x00000000 flags 0x0]
Fix this by taking into account bridge windows, device BARs and SR-IOV PF
BARs on the bus (PF BARs include space for VF BARS so only account PF
BARs), including the ones belonging to bridges themselves if it has any.
Link: https://lore.kernel.org/linux-pci/20221014124553.0000696f@huawei.com/
Link: https://lore.kernel.org/linux-pci/6053736d-1923-41e7-def9-7585ce1772d9@ixsystems.com/
Link: https://lore.kernel.org/r/20230131092405.29121-3-mika.westerberg@linux.intel.com
Reported-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Reported-by: Alexander Motin <mav@ixsystems.com>
Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
2023-01-31 12:24:04 +03:00
io . end = align ? io . start + ALIGN_DOWN ( io_per_b , align ) - 1
: io . start + io_per_b - 1 ;
/*
* The x_per_b holds the extra resource space that can be
* added for each bridge but there is the minimal already
* reserved as well so adjust x . start down accordingly to
* cover the whole space .
*/
io . start - = resource_size ( res ) ;
2023-01-31 12:24:03 +03:00
res = & dev - > resource [ PCI_BRIDGE_MEM_WINDOW ] ;
align = pci_resource_alignment ( dev , res ) ;
PCI: Take other bus devices into account when distributing resources
A PCI bridge may reside on a bus with other devices as well. The resource
distribution code does not take this into account and therefore it expands
the bridge resource windows too much, not leaving space for the other
devices (or functions of a multifunction device). This leads to an issue
that Jonathan reported when running QEMU with the following topology (QEMU
parameters):
-device pcie-root-port,port=0,id=root_port13,chassis=0,slot=2 \
-device x3130-upstream,id=sw1,bus=root_port13,multifunction=on \
-device e1000,bus=root_port13,addr=0.1 \
-device xio3130-downstream,id=fun1,bus=sw1,chassis=0,slot=3 \
-device e1000,bus=fun1
The first e1000 NIC here is another function in the switch upstream port.
This leads to following errors:
pci 0000:00:04.0: bridge window [mem 0x10200000-0x103fffff] to [bus 02-04]
pci 0000:02:00.0: bridge window [mem 0x10200000-0x103fffff] to [bus 03-04]
pci 0000:02:00.1: BAR 0: failed to assign [mem size 0x00020000]
e1000 0000:02:00.1: can't ioremap BAR 0: [??? 0x00000000 flags 0x0]
Fix this by taking into account bridge windows, device BARs and SR-IOV PF
BARs on the bus (PF BARs include space for VF BARS so only account PF
BARs), including the ones belonging to bridges themselves if it has any.
Link: https://lore.kernel.org/linux-pci/20221014124553.0000696f@huawei.com/
Link: https://lore.kernel.org/linux-pci/6053736d-1923-41e7-def9-7585ce1772d9@ixsystems.com/
Link: https://lore.kernel.org/r/20230131092405.29121-3-mika.westerberg@linux.intel.com
Reported-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Reported-by: Alexander Motin <mav@ixsystems.com>
Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
2023-01-31 12:24:04 +03:00
mmio . end = align ? mmio . start + ALIGN_DOWN ( mmio_per_b , align ) - 1
: mmio . start + mmio_per_b - 1 ;
mmio . start - = resource_size ( res ) ;
2023-01-31 12:24:03 +03:00
res = & dev - > resource [ PCI_BRIDGE_PREF_MEM_WINDOW ] ;
align = pci_resource_alignment ( dev , res ) ;
mmio_pref . end = align ? mmio_pref . start +
PCI: Take other bus devices into account when distributing resources
A PCI bridge may reside on a bus with other devices as well. The resource
distribution code does not take this into account and therefore it expands
the bridge resource windows too much, not leaving space for the other
devices (or functions of a multifunction device). This leads to an issue
that Jonathan reported when running QEMU with the following topology (QEMU
parameters):
-device pcie-root-port,port=0,id=root_port13,chassis=0,slot=2 \
-device x3130-upstream,id=sw1,bus=root_port13,multifunction=on \
-device e1000,bus=root_port13,addr=0.1 \
-device xio3130-downstream,id=fun1,bus=sw1,chassis=0,slot=3 \
-device e1000,bus=fun1
The first e1000 NIC here is another function in the switch upstream port.
This leads to following errors:
pci 0000:00:04.0: bridge window [mem 0x10200000-0x103fffff] to [bus 02-04]
pci 0000:02:00.0: bridge window [mem 0x10200000-0x103fffff] to [bus 03-04]
pci 0000:02:00.1: BAR 0: failed to assign [mem size 0x00020000]
e1000 0000:02:00.1: can't ioremap BAR 0: [??? 0x00000000 flags 0x0]
Fix this by taking into account bridge windows, device BARs and SR-IOV PF
BARs on the bus (PF BARs include space for VF BARS so only account PF
BARs), including the ones belonging to bridges themselves if it has any.
Link: https://lore.kernel.org/linux-pci/20221014124553.0000696f@huawei.com/
Link: https://lore.kernel.org/linux-pci/6053736d-1923-41e7-def9-7585ce1772d9@ixsystems.com/
Link: https://lore.kernel.org/r/20230131092405.29121-3-mika.westerberg@linux.intel.com
Reported-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Reported-by: Alexander Motin <mav@ixsystems.com>
Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
2023-01-31 12:24:04 +03:00
ALIGN_DOWN ( mmio_pref_per_b , align ) - 1
: mmio_pref . start + mmio_pref_per_b - 1 ;
mmio_pref . start - = resource_size ( res ) ;
2020-01-06 18:45:52 +03:00
pci_bus_distribute_available_resources ( b , add_list , io , mmio ,
mmio_pref ) ;
PCI: Consider alignment of hot-added bridges when assigning resources
Change pci_bus_distribute_available_resources() to better handle bridges
with different resource alignment requirements.
The arguments io, mmio and mmio_pref represent the start and end
addresses of resource, into which we must fit the current bridge window.
The steps taken by pci_bus_distribute_available_resources():
- For io, mmio and mmio_pref, increase .start to align with the alignment
of the current bridge window (otherwise the current bridge window may
not fit within the available range).
- For io, mmio and mmio_pref, adjust the current bridge window to the
size after the above.
- Count the number of hotplug bridges and normal bridges on this bus.
- If the total number of bridges is one, give that bridge all of the
resources and return.
- If there are no hotplug bridges, return.
- For io, mmio and mmio_pref, increase .start by the amount required for
each bridge resource on the bus for non hotplug bridges, giving extra
room to make up for alignment of those resources.
- For io, mmio and mmio_pref, calculate the resource size per hotplug
bridge which is available after the previous steps.
- For io, mmio and mmio_pref, distribute the resources to each hotplug
bridge, with the sizes calculated above.
The motivation for fixing this is enabling devices that require greater
than 1MB alignment. This fixes the case where the user hot-adds devices
with BAR alignment >1MB and Linux fails to assign resources to it.
Link: https://bugzilla.kernel.org/show_bug.cgi?id=199581
Link: https://lore.kernel.org/r/PSXP216MB0438C2BFD0FD3691ED9C83F4803C0@PSXP216MB0438.KORP216.PROD.OUTLOOK.COM
Reported-by: Mika Westerberg <mika.westerberg@linux.intel.com>
Signed-off-by: Nicholas Johnson <nicholas.johnson-opensource@outlook.com.au>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Reviewed-by: Mika Westerberg <mika.westerberg@linux.intel.com>
2020-01-06 18:46:13 +03:00
2023-01-31 12:24:03 +03:00
io . start + = io . end + 1 ;
mmio . start + = mmio . end + 1 ;
mmio_pref . start + = mmio_pref . end + 1 ;
2017-10-13 21:35:45 +03:00
}
}
2019-05-07 22:51:24 +03:00
static void pci_bridge_distribute_available_resources ( struct pci_dev * bridge ,
2022-09-05 11:02:31 +03:00
struct list_head * add_list )
2017-10-13 21:35:45 +03:00
{
2020-01-06 18:45:52 +03:00
struct resource available_io , available_mmio , available_mmio_pref ;
2017-10-13 21:35:45 +03:00
if ( ! bridge - > is_hotplug_bridge )
return ;
2023-01-31 12:24:05 +03:00
pci_dbg ( bridge , " distributing available resources \n " ) ;
2017-10-13 21:35:45 +03:00
/* Take the initial extra resources from the hotplug port */
2020-05-20 21:34:10 +03:00
available_io = bridge - > resource [ PCI_BRIDGE_IO_WINDOW ] ;
available_mmio = bridge - > resource [ PCI_BRIDGE_MEM_WINDOW ] ;
available_mmio_pref = bridge - > resource [ PCI_BRIDGE_PREF_MEM_WINDOW ] ;
2017-10-13 21:35:45 +03:00
pci_bus_distribute_available_resources ( bridge - > subordinate ,
2019-05-07 22:51:24 +03:00
add_list , available_io ,
available_mmio ,
available_mmio_pref ) ;
2017-10-13 21:35:45 +03:00
}
2023-01-31 12:24:05 +03:00
static bool pci_bridge_resources_not_assigned ( struct pci_dev * dev )
{
const struct resource * r ;
/*
* If the child device ' s resources are not yet assigned it means we
* are configuring them ( not the boot firmware ) , so we should be
* able to extend the upstream bridge resources in the same way we
* do with the normal hotplug case .
*/
r = & dev - > resource [ PCI_BRIDGE_IO_WINDOW ] ;
if ( r - > flags & & ! ( r - > flags & IORESOURCE_STARTALIGN ) )
return false ;
r = & dev - > resource [ PCI_BRIDGE_MEM_WINDOW ] ;
if ( r - > flags & & ! ( r - > flags & IORESOURCE_STARTALIGN ) )
return false ;
r = & dev - > resource [ PCI_BRIDGE_PREF_MEM_WINDOW ] ;
if ( r - > flags & & ! ( r - > flags & IORESOURCE_STARTALIGN ) )
return false ;
return true ;
}
static void
pci_root_bus_distribute_available_resources ( struct pci_bus * bus ,
struct list_head * add_list )
{
struct pci_dev * dev , * bridge = bus - > self ;
for_each_pci_bridge ( dev , bus ) {
struct pci_bus * b ;
b = dev - > subordinate ;
if ( ! b )
continue ;
/*
* Need to check " bridge " here too because it is NULL
* in case of root bus .
*/
if ( bridge & & pci_bridge_resources_not_assigned ( dev ) )
pci_bridge_distribute_available_resources ( bridge ,
add_list ) ;
else
pci_root_bus_distribute_available_resources ( b , add_list ) ;
}
}
2022-09-05 11:02:29 +03:00
/*
* First try will not touch PCI bridge res .
* Second and later try will clear small leaf bridge res .
* Will stop till to the max depth if can not find good one .
*/
void pci_assign_unassigned_root_bus_resources ( struct pci_bus * bus )
{
LIST_HEAD ( realloc_head ) ;
/* List of resources that want additional resources */
struct list_head * add_list = NULL ;
int tried_times = 0 ;
enum release_type rel_type = leaf_only ;
LIST_HEAD ( fail_head ) ;
struct pci_dev_resource * fail_res ;
int pci_try_num = 1 ;
enum enable_type enable_local ;
/* Don't realloc if asked to do so */
enable_local = pci_realloc_detect ( bus , pci_realloc_enable ) ;
if ( pci_realloc_enabled ( enable_local ) ) {
int max_depth = pci_bus_get_depth ( bus ) ;
pci_try_num = max_depth + 1 ;
dev_info ( & bus - > dev , " max bus depth: %d pci_try_num: %d \n " ,
max_depth , pci_try_num ) ;
}
again :
/*
* Last try will use add_list , otherwise will try good to have as must
* have , so can realloc parent bridge resource
*/
if ( tried_times + 1 = = pci_try_num )
add_list = & realloc_head ;
/*
* Depth first , calculate sizes and alignments of all subordinate buses .
*/
__pci_bus_size_bridges ( bus , add_list ) ;
2023-01-31 12:24:05 +03:00
pci_root_bus_distribute_available_resources ( bus , add_list ) ;
2022-09-05 11:02:29 +03:00
/* Depth last, allocate resources and update the hardware. */
__pci_bus_assign_resources ( bus , add_list , & fail_head ) ;
if ( add_list )
BUG_ON ( ! list_empty ( add_list ) ) ;
tried_times + + ;
/* Any device complain? */
if ( list_empty ( & fail_head ) )
goto dump ;
if ( tried_times > = pci_try_num ) {
if ( enable_local = = undefined )
dev_info ( & bus - > dev , " Some PCI device resources are unassigned, try booting with pci=realloc \n " ) ;
else if ( enable_local = = auto_enabled )
dev_info ( & bus - > dev , " Automatically enabled pci realloc, if you have problem, try booting with pci=realloc=off \n " ) ;
free_list ( & fail_head ) ;
goto dump ;
}
dev_info ( & bus - > dev , " No. %d try to assign unassigned res \n " ,
tried_times + 1 ) ;
/* Third times and later will not check if it is leaf */
if ( ( tried_times + 1 ) > 2 )
rel_type = whole_subtree ;
/*
* Try to release leaf bridge ' s resources that doesn ' t fit resource of
* child device under that bridge .
*/
list_for_each_entry ( fail_res , & fail_head , list )
pci_bus_release_bridge_resources ( fail_res - > dev - > bus ,
fail_res - > flags & PCI_RES_TYPE_MASK ,
rel_type ) ;
/* Restore size and flags */
list_for_each_entry ( fail_res , & fail_head , list ) {
struct resource * res = fail_res - > res ;
int idx ;
res - > start = fail_res - > start ;
res - > end = fail_res - > end ;
res - > flags = fail_res - > flags ;
if ( pci_is_bridge ( fail_res - > dev ) ) {
idx = res - & fail_res - > dev - > resource [ 0 ] ;
if ( idx > = PCI_BRIDGE_RESOURCES & &
idx < = PCI_BRIDGE_RESOURCE_END )
res - > flags = 0 ;
}
}
free_list ( & fail_head ) ;
goto again ;
dump :
/* Dump the resource on buses */
pci_bus_dump_resources ( bus ) ;
}
void __init pci_assign_unassigned_resources ( void )
{
struct pci_bus * root_bus ;
list_for_each_entry ( root_bus , & pci_root_buses , node ) {
pci_assign_unassigned_root_bus_resources ( root_bus ) ;
/* Make sure the root bridge has a companion ACPI device */
if ( ACPI_HANDLE ( root_bus - > bridge ) )
acpi_ioapic_add ( ACPI_HANDLE ( root_bus - > bridge ) ) ;
}
}
2010-01-22 12:02:25 +03:00
void pci_assign_unassigned_bridge_resources ( struct pci_dev * bridge )
{
struct pci_bus * parent = bridge - > subordinate ;
2019-05-07 22:51:24 +03:00
/* List of resources that want additional resources */
LIST_HEAD ( add_list ) ;
2010-01-22 12:02:27 +03:00
int tried_times = 0 ;
2012-01-21 14:08:27 +04:00
LIST_HEAD ( fail_head ) ;
2012-01-21 14:08:29 +04:00
struct pci_dev_resource * fail_res ;
2010-01-22 12:02:25 +03:00
int retval ;
2010-01-22 12:02:27 +03:00
again :
2012-01-21 14:08:21 +04:00
__pci_bus_size_bridges ( parent , & add_list ) ;
2017-10-13 21:35:45 +03:00
/*
2019-05-07 22:51:24 +03:00
* Distribute remaining resources ( if any ) equally between hotplug
* bridges below . This makes it possible to extend the hierarchy
* later without running out of resources .
2017-10-13 21:35:45 +03:00
*/
pci_bridge_distribute_available_resources ( bridge , & add_list ) ;
2012-01-21 14:08:27 +04:00
__pci_bridge_assign_resources ( bridge , & add_list , & fail_head ) ;
BUG_ON ( ! list_empty ( & add_list ) ) ;
2010-01-22 12:02:27 +03:00
tried_times + + ;
2012-01-21 14:08:27 +04:00
if ( list_empty ( & fail_head ) )
2010-05-22 01:35:06 +04:00
goto enable_all ;
2010-01-22 12:02:27 +03:00
if ( tried_times > = 2 ) {
2019-05-07 22:51:24 +03:00
/* Still fail, don't need to try more */
2012-01-21 14:08:30 +04:00
free_list ( & fail_head ) ;
2010-05-22 01:35:06 +04:00
goto enable_all ;
2010-01-22 12:02:27 +03:00
}
printk ( KERN_DEBUG " PCI: No. %d try to assign unassigned res \n " ,
tried_times + 1 ) ;
/*
2019-05-07 22:51:24 +03:00
* Try to release leaf bridge ' s resources that aren ' t big enough
* to contain child device resources .
2010-01-22 12:02:27 +03:00
*/
2013-07-23 01:37:12 +04:00
list_for_each_entry ( fail_res , & fail_head , list )
pci_bus_release_bridge_resources ( fail_res - > dev - > bus ,
2017-10-18 16:58:17 +03:00
fail_res - > flags & PCI_RES_TYPE_MASK ,
2010-01-22 12:02:27 +03:00
whole_subtree ) ;
2013-07-23 01:37:12 +04:00
2019-05-07 22:51:24 +03:00
/* Restore size and flags */
2012-01-21 14:08:29 +04:00
list_for_each_entry ( fail_res , & fail_head , list ) {
struct resource * res = fail_res - > res ;
PCI: Don't disable bridge BARs when assigning bus resources
Some PCI bridges implement BARs in addition to bridge windows. For
example, here's a PLX switch:
04:00.0 PCI bridge: PLX Technology, Inc. PEX 8724 24-Lane, 6-Port PCI
Express Gen 3 (8 GT/s) Switch, 19 x 19mm FCBGA (rev ca)
(prog-if 00 [Normal decode])
Flags: bus master, fast devsel, latency 0, IRQ 30, NUMA node 0
Memory at 90a00000 (32-bit, non-prefetchable) [size=256K]
Bus: primary=04, secondary=05, subordinate=0a, sec-latency=0
I/O behind bridge: 00002000-00003fff
Memory behind bridge: 90000000-909fffff
Prefetchable memory behind bridge: 0000380000800000-0000380000bfffff
Previously, when the kernel assigned resource addresses (with the
pci=realloc command line parameter, for example) it could clear the struct
resource corresponding to the BAR. When this happened, lspci would report
this BAR as "ignored":
Region 0: Memory at <ignored> (32-bit, non-prefetchable) [size=256K]
This is because the kernel reports a zero start address and zero flags
in the corresponding sysfs resource file and in /proc/bus/pci/devices.
Investigation with 'lspci -x', however, shows the BIOS-assigned address
will still be programmed in the device's BAR registers.
It's clearly a bug that the kernel lost track of the BAR value, but in most
cases, this still won't result in a visible issue because nothing uses the
memory, so nothing is affected. However, when an IOMMU is in use, it will
not reserve this space in the IOVA because the kernel no longer thinks the
range is valid. (See dmar_init_reserved_ranges() for the Intel
implementation of this.)
Without the proper reserved range, a DMA mapping may allocate an IOVA that
matches a bridge BAR, which results in DMA accesses going to the BAR
instead of the intended RAM.
The problem was in pci_assign_unassigned_root_bus_resources(). When any
resource from a bridge device fails to get assigned, the code set the
resource's flags to zero. This makes sense for bridge windows, as they
will be re-enabled later, but for regular BARs, it makes the kernel
permanently lose track of the fact that they decode address space.
Change pci_assign_unassigned_root_bus_resources() and
pci_assign_unassigned_bridge_resources() so they only clear "res->flags"
for bridge *windows*, not bridge BARs.
Fixes: da7822e5ad71 ("PCI: update bridge resources to get more big ranges when allocating space (again)")
Link: https://lore.kernel.org/r/20200108213208.4612-1-logang@deltatee.com
[bhelgaas: commit log, check for pci_is_bridge()]
Reported-by: Kit Chow <kchow@gigaio.com>
Signed-off-by: Logan Gunthorpe <logang@deltatee.com>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
2020-01-09 00:32:08 +03:00
int idx ;
2010-01-22 12:02:27 +03:00
2012-01-21 14:08:29 +04:00
res - > start = fail_res - > start ;
res - > end = fail_res - > end ;
res - > flags = fail_res - > flags ;
PCI: Don't disable bridge BARs when assigning bus resources
Some PCI bridges implement BARs in addition to bridge windows. For
example, here's a PLX switch:
04:00.0 PCI bridge: PLX Technology, Inc. PEX 8724 24-Lane, 6-Port PCI
Express Gen 3 (8 GT/s) Switch, 19 x 19mm FCBGA (rev ca)
(prog-if 00 [Normal decode])
Flags: bus master, fast devsel, latency 0, IRQ 30, NUMA node 0
Memory at 90a00000 (32-bit, non-prefetchable) [size=256K]
Bus: primary=04, secondary=05, subordinate=0a, sec-latency=0
I/O behind bridge: 00002000-00003fff
Memory behind bridge: 90000000-909fffff
Prefetchable memory behind bridge: 0000380000800000-0000380000bfffff
Previously, when the kernel assigned resource addresses (with the
pci=realloc command line parameter, for example) it could clear the struct
resource corresponding to the BAR. When this happened, lspci would report
this BAR as "ignored":
Region 0: Memory at <ignored> (32-bit, non-prefetchable) [size=256K]
This is because the kernel reports a zero start address and zero flags
in the corresponding sysfs resource file and in /proc/bus/pci/devices.
Investigation with 'lspci -x', however, shows the BIOS-assigned address
will still be programmed in the device's BAR registers.
It's clearly a bug that the kernel lost track of the BAR value, but in most
cases, this still won't result in a visible issue because nothing uses the
memory, so nothing is affected. However, when an IOMMU is in use, it will
not reserve this space in the IOVA because the kernel no longer thinks the
range is valid. (See dmar_init_reserved_ranges() for the Intel
implementation of this.)
Without the proper reserved range, a DMA mapping may allocate an IOVA that
matches a bridge BAR, which results in DMA accesses going to the BAR
instead of the intended RAM.
The problem was in pci_assign_unassigned_root_bus_resources(). When any
resource from a bridge device fails to get assigned, the code set the
resource's flags to zero. This makes sense for bridge windows, as they
will be re-enabled later, but for regular BARs, it makes the kernel
permanently lose track of the fact that they decode address space.
Change pci_assign_unassigned_root_bus_resources() and
pci_assign_unassigned_bridge_resources() so they only clear "res->flags"
for bridge *windows*, not bridge BARs.
Fixes: da7822e5ad71 ("PCI: update bridge resources to get more big ranges when allocating space (again)")
Link: https://lore.kernel.org/r/20200108213208.4612-1-logang@deltatee.com
[bhelgaas: commit log, check for pci_is_bridge()]
Reported-by: Kit Chow <kchow@gigaio.com>
Signed-off-by: Logan Gunthorpe <logang@deltatee.com>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
2020-01-09 00:32:08 +03:00
if ( pci_is_bridge ( fail_res - > dev ) ) {
idx = res - & fail_res - > dev - > resource [ 0 ] ;
if ( idx > = PCI_BRIDGE_RESOURCES & &
idx < = PCI_BRIDGE_RESOURCE_END )
res - > flags = 0 ;
}
2010-01-22 12:02:27 +03:00
}
2012-01-21 14:08:30 +04:00
free_list ( & fail_head ) ;
2010-01-22 12:02:27 +03:00
goto again ;
2010-05-22 01:35:06 +04:00
enable_all :
retval = pci_reenable_device ( bridge ) ;
2013-04-12 21:35:40 +04:00
if ( retval )
2018-01-18 21:55:24 +03:00
pci_err ( bridge , " Error reenabling bridge (%d) \n " , retval ) ;
2010-05-22 01:35:06 +04:00
pci_set_master ( bridge ) ;
2010-01-22 12:02:25 +03:00
}
EXPORT_SYMBOL_GPL ( pci_assign_unassigned_bridge_resources ) ;
2012-01-21 14:08:23 +04:00
2017-10-24 22:40:26 +03:00
int pci_reassign_bridge_resources ( struct pci_dev * bridge , unsigned long type )
{
struct pci_dev_resource * dev_res ;
struct pci_dev * next ;
LIST_HEAD ( saved ) ;
LIST_HEAD ( added ) ;
LIST_HEAD ( failed ) ;
unsigned int i ;
int ret ;
2019-09-25 04:16:55 +03:00
down_read ( & pci_bus_sem ) ;
2017-10-24 22:40:26 +03:00
/* Walk to the root hub, releasing bridge BARs when possible */
next = bridge ;
do {
bridge = next ;
for ( i = PCI_BRIDGE_RESOURCES ; i < PCI_BRIDGE_RESOURCE_END ;
i + + ) {
struct resource * res = & bridge - > resource [ i ] ;
if ( ( res - > flags ^ type ) & PCI_RES_TYPE_MASK )
continue ;
/* Ignore BARs which are still in use */
if ( res - > child )
continue ;
ret = add_to_list ( & saved , bridge , res , 0 , 0 ) ;
if ( ret )
goto cleanup ;
2018-01-18 21:55:24 +03:00
pci_info ( bridge , " BAR %d: releasing %pR \n " ,
2017-10-24 22:40:26 +03:00
i , res ) ;
if ( res - > parent )
release_resource ( res ) ;
res - > start = 0 ;
res - > end = 0 ;
break ;
}
if ( i = = PCI_BRIDGE_RESOURCE_END )
break ;
next = bridge - > bus ? bridge - > bus - > self : NULL ;
} while ( next ) ;
2019-09-25 04:16:55 +03:00
if ( list_empty ( & saved ) ) {
up_read ( & pci_bus_sem ) ;
2017-10-24 22:40:26 +03:00
return - ENOENT ;
2019-09-25 04:16:55 +03:00
}
2017-10-24 22:40:26 +03:00
__pci_bus_size_bridges ( bridge - > subordinate , & added ) ;
__pci_bridge_assign_resources ( bridge , & added , & failed ) ;
BUG_ON ( ! list_empty ( & added ) ) ;
if ( ! list_empty ( & failed ) ) {
ret = - ENOSPC ;
goto cleanup ;
}
list_for_each_entry ( dev_res , & saved , list ) {
2019-05-07 22:51:24 +03:00
/* Skip the bridge we just assigned resources for */
2017-10-24 22:40:26 +03:00
if ( bridge = = dev_res - > dev )
continue ;
bridge = dev_res - > dev ;
pci_setup_bridge ( bridge - > subordinate ) ;
}
free_list ( & saved ) ;
2019-09-25 04:16:55 +03:00
up_read ( & pci_bus_sem ) ;
2017-10-24 22:40:26 +03:00
return 0 ;
cleanup :
2019-05-07 22:51:24 +03:00
/* Restore size and flags */
2017-10-24 22:40:26 +03:00
list_for_each_entry ( dev_res , & failed , list ) {
struct resource * res = dev_res - > res ;
res - > start = dev_res - > start ;
res - > end = dev_res - > end ;
res - > flags = dev_res - > flags ;
}
free_list ( & failed ) ;
/* Revert to the old configuration */
list_for_each_entry ( dev_res , & saved , list ) {
struct resource * res = dev_res - > res ;
bridge = dev_res - > dev ;
i = res - bridge - > resource ;
res - > start = dev_res - > start ;
res - > end = dev_res - > end ;
res - > flags = dev_res - > flags ;
pci_claim_resource ( bridge , i ) ;
pci_setup_bridge ( bridge - > subordinate ) ;
}
free_list ( & saved ) ;
2019-09-25 04:16:55 +03:00
up_read ( & pci_bus_sem ) ;
2017-10-24 22:40:26 +03:00
return ret ;
}
2012-10-31 00:31:10 +04:00
void pci_assign_unassigned_bus_resources ( struct pci_bus * bus )
2012-01-21 14:08:23 +04:00
{
struct pci_dev * dev ;
2019-05-07 22:51:24 +03:00
/* List of resources that want additional resources */
LIST_HEAD ( add_list ) ;
2012-01-21 14:08:23 +04:00
down_read ( & pci_bus_sem ) ;
2017-10-20 23:38:54 +03:00
for_each_pci_bridge ( dev , bus )
if ( pci_has_subordinate ( dev ) )
__pci_bus_size_bridges ( dev - > subordinate , & add_list ) ;
2012-01-21 14:08:23 +04:00
up_read ( & pci_bus_sem ) ;
__pci_bus_assign_resources ( bus , & add_list , NULL ) ;
2012-01-21 14:08:27 +04:00
BUG_ON ( ! list_empty ( & add_list ) ) ;
2012-10-31 00:31:10 +04:00
}
2015-04-08 21:21:33 +03:00
EXPORT_SYMBOL_GPL ( pci_assign_unassigned_bus_resources ) ;