public inbox for linux-acpi@vger.kernel.org
 help / color / mirror / Atom feed
From: Kenji Kaneshige <kaneshige.kenji@jp.fujitsu.com>
To: Bjorn Helgaas <bjorn.helgaas@hp.com>
Cc: Len Brown <lenb@kernel.org>,
	linux-acpi@vger.kernel.org, linux-ia64@vger.kernel.org,
	linux-pci@vger.kernel.org
Subject: Re: [PATCH v3 1/2] ACPI: pci_root: save downstream bus range
Date: Wed, 10 Mar 2010 18:50:01 +0900	[thread overview]
Message-ID: <4B976B49.9090502@jp.fujitsu.com> (raw)
In-Reply-To: <20100309225325.27167.60539.stgit@bob.kio>

Looks good to me. But one nitpicking.

> +	root->secondary.flags = IORESOURCE_BUS;
> +	root->secondary.start = 0;
> +	root->secondary.end = 0xFF;
> +	status = try_get_root_bridge_busnr(device->handle, &root->secondary);
>  	if (ACPI_FAILURE(status)) {

I feel a little strange about initializing 'start' and 'end' fields
here because those are changed in try_get_root_bridge_busnr().
What about the below?

	root->secondary.flags = IORESOURCE_BUS;
	status = try_get_root_bridge_busnr(device->handle, &root->secondary);
	if (ACPI_FAILURE(status)) {
		root->secondary = 0xFF;
		...

Reviewed-by: Kenji Kaneshige <kaneshige.kenji@jp.fujitsu.com>

Thanks,
Kenji Kaneshige


Bjorn Helgaas wrote:
> Previously, we only saved the root bus number, i.e., the beginning of the
> downstream bus range.  We now support IORESOURCE_BUS resources, so this
> patch uses that to keep track of both the beginning and the end of the
> downstream bus range.
> 
> It's important to know both the beginning and the end for supporting _CBA
> (see PCI Firmware spec, rev 3.0, sec 4.1.3) and so we know the limits for
> any possible PCI bus renumbering (we can't renumber downstream buses to be
> outside the bus number range claimed by the host bridge).
> 
> It's clear from the spec that the bus range is supposed to be in _CRS, but
> if we don't find it there, we'll assume [_BBN - 0xFF].
> 
> Signed-off-by: Bjorn Helgaas <bjorn.helgaas@hp.com>
> ---
> 
>  drivers/acpi/pci_root.c |   67 ++++++++++++++++++++++++++++-------------------
>  include/acpi/acpi_bus.h |    2 +
>  2 files changed, 41 insertions(+), 28 deletions(-)
> 
> 
> diff --git a/drivers/acpi/pci_root.c b/drivers/acpi/pci_root.c
> index d724736..e309f56 100644
> --- a/drivers/acpi/pci_root.c
> +++ b/drivers/acpi/pci_root.c
> @@ -119,7 +119,8 @@ acpi_handle acpi_get_pci_rootbridge_handle(unsigned int seg, unsigned int bus)
>  	struct acpi_pci_root *root;
>  	
>  	list_for_each_entry(root, &acpi_pci_roots, node)
> -		if ((root->segment == (u16) seg) && (root->bus_nr == (u16) bus))
> +		if ((root->segment == (u16) seg) &&
> +		    (root->secondary.start == (u16) bus))
>  			return root->device->handle;
>  	return NULL;		
>  }
> @@ -153,7 +154,7 @@ EXPORT_SYMBOL_GPL(acpi_is_root_bridge);
>  static acpi_status
>  get_root_bridge_busnr_callback(struct acpi_resource *resource, void *data)
>  {
> -	int *busnr = data;
> +	struct resource *res = data;
>  	struct acpi_resource_address64 address;
>  
>  	if (resource->type != ACPI_RESOURCE_TYPE_ADDRESS16 &&
> @@ -163,28 +164,27 @@ get_root_bridge_busnr_callback(struct acpi_resource *resource, void *data)
>  
>  	acpi_resource_to_address64(resource, &address);
>  	if ((address.address_length > 0) &&
> -	    (address.resource_type == ACPI_BUS_NUMBER_RANGE))
> -		*busnr = address.minimum;
> +	    (address.resource_type == ACPI_BUS_NUMBER_RANGE)) {
> +		res->start = address.minimum;
> +		res->end = address.minimum + address.address_length - 1;
> +	}
>  
>  	return AE_OK;
>  }
>  
>  static acpi_status try_get_root_bridge_busnr(acpi_handle handle,
> -					     unsigned long long *bus)
> +					     struct resource *res)
>  {
>  	acpi_status status;
> -	int busnum;
>  
> -	busnum = -1;
> +	res->start = -1;
>  	status =
>  	    acpi_walk_resources(handle, METHOD_NAME__CRS,
> -				get_root_bridge_busnr_callback, &busnum);
> +				get_root_bridge_busnr_callback, res);
>  	if (ACPI_FAILURE(status))
>  		return status;
> -	/* Check if we really get a bus number from _CRS */
> -	if (busnum == -1)
> +	if (res->start == -1)
>  		return AE_ERROR;
> -	*bus = busnum;
>  	return AE_OK;
>  }
>  
> @@ -428,34 +428,47 @@ static int __devinit acpi_pci_root_add(struct acpi_device *device)
>  	struct acpi_device *child;
>  	u32 flags, base_flags;
>  
> +	root = kzalloc(sizeof(struct acpi_pci_root), GFP_KERNEL);
> +	if (!root)
> +		return -ENOMEM;
> +
>  	segment = 0;
>  	status = acpi_evaluate_integer(device->handle, METHOD_NAME__SEG, NULL,
>  				       &segment);
>  	if (ACPI_FAILURE(status) && status != AE_NOT_FOUND) {
>  		printk(KERN_ERR PREFIX "can't evaluate _SEG\n");
> -		return -ENODEV;
> +		result = -ENODEV;
> +		goto end;
>  	}
>  
>  	/* Check _CRS first, then _BBN.  If no _BBN, default to zero. */
> -	bus = 0;
> -	status = try_get_root_bridge_busnr(device->handle, &bus);
> +	root->secondary.flags = IORESOURCE_BUS;
> +	root->secondary.start = 0;
> +	root->secondary.end = 0xFF;
> +	status = try_get_root_bridge_busnr(device->handle, &root->secondary);
>  	if (ACPI_FAILURE(status)) {
> +		/*
> +		 * We need both the start and end of the downstream bus range
> +		 * to interpret _CBA (MMCONFIG base address), so it really is
> +		 * supposed to be in _CRS.
> +		 */
> +		printk(KERN_WARNING FW_BUG PREFIX
> +		       "no secondary bus range in _CRS\n");
>  		status = acpi_evaluate_integer(device->handle, METHOD_NAME__BBN,					       NULL, &bus);
> -		if (ACPI_FAILURE(status) && status != AE_NOT_FOUND) {
> -			printk(KERN_ERR PREFIX
> -			     "no bus number in _CRS and can't evaluate _BBN\n");
> -			return -ENODEV;
> +		if (ACPI_SUCCESS(status))
> +			root->secondary.start = bus;
> +		else if (status == AE_NOT_FOUND)
> +			root->secondary.start = 0;
> +		else {
> +			printk(KERN_ERR PREFIX "can't evaluate _BBN\n");
> +			result = -ENODEV;
> +			goto end;
>  		}
>  	}
>  
> -	root = kzalloc(sizeof(struct acpi_pci_root), GFP_KERNEL);
> -	if (!root)
> -		return -ENOMEM;
> -
>  	INIT_LIST_HEAD(&root->node);
>  	root->device = device;
>  	root->segment = segment & 0xFFFF;
> -	root->bus_nr = bus & 0xFF;
>  	strcpy(acpi_device_name(device), ACPI_PCI_ROOT_DEVICE_NAME);
>  	strcpy(acpi_device_class(device), ACPI_PCI_ROOT_CLASS);
>  	device->driver_data = root;
> @@ -474,9 +487,9 @@ static int __devinit acpi_pci_root_add(struct acpi_device *device)
>  	/* TBD: Locking */
>  	list_add_tail(&root->node, &acpi_pci_roots);
>  
> -	printk(KERN_INFO PREFIX "%s [%s] (%04x:%02x)\n",
> +	printk(KERN_INFO PREFIX "%s [%s] (domain %04x %pR)\n",
>  	       acpi_device_name(device), acpi_device_bid(device),
> -	       root->segment, root->bus_nr);
> +	       root->segment, &root->secondary);
>  
>  	/*
>  	 * Scan the Root Bridge
> @@ -485,11 +498,11 @@ static int __devinit acpi_pci_root_add(struct acpi_device *device)
>  	 * PCI namespace does not get created until this call is made (and 
>  	 * thus the root bridge's pci_dev does not exist).
>  	 */
> -	root->bus = pci_acpi_scan_root(device, segment, bus);
> +	root->bus = pci_acpi_scan_root(device, segment, root->secondary.start);
>  	if (!root->bus) {
>  		printk(KERN_ERR PREFIX
>  			    "Bus %04x:%02x not present in PCI namespace\n",
> -			    root->segment, root->bus_nr);
> +			    root->segment, (unsigned int)root->secondary.start);
>  		result = -ENODEV;
>  		goto end;
>  	}
> diff --git a/include/acpi/acpi_bus.h b/include/acpi/acpi_bus.h
> index 7bf83dd..baacd98 100644
> --- a/include/acpi/acpi_bus.h
> +++ b/include/acpi/acpi_bus.h
> @@ -373,7 +373,7 @@ struct acpi_pci_root {
>  	struct acpi_pci_id id;
>  	struct pci_bus *bus;
>  	u16 segment;
> -	u8 bus_nr;
> +	struct resource secondary;	/* downstream bus range */
>  
>  	u32 osc_support_set;	/* _OSC state of support bits */
>  	u32 osc_control_set;	/* _OSC state of control bits */
> 
> --
> To unsubscribe from this list: send the line "unsubscribe linux-pci" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> 
> 

  reply	other threads:[~2010-03-10  9:50 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-03-09 22:53 [PATCH v3 0/2] pci_root: track downstream bus range Bjorn Helgaas
2010-03-09 22:53 ` [PATCH v3 1/2] ACPI: pci_root: save " Bjorn Helgaas
2010-03-10  9:50   ` Kenji Kaneshige [this message]
2010-03-10 16:15     ` Bjorn Helgaas
2010-03-09 22:53 ` [PATCH v3 2/2] ACPI: pci_root: pass acpi_pci_root to arch-specific scan Bjorn Helgaas
2010-03-10  9:51   ` Kenji Kaneshige

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=4B976B49.9090502@jp.fujitsu.com \
    --to=kaneshige.kenji@jp.fujitsu.com \
    --cc=bjorn.helgaas@hp.com \
    --cc=lenb@kernel.org \
    --cc=linux-acpi@vger.kernel.org \
    --cc=linux-ia64@vger.kernel.org \
    --cc=linux-pci@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox