Re: [Patch v5 4/6] PCI/ACPI: Consolidate common PCI host bridge code into ACPI core

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On 2015/6/10 0:12, Lorenzo Pieralisi wrote:
> On Mon, Jun 08, 2015 at 05:20:46PM +0100, Jiang Liu wrote:
> 
> [...]
> 
>> +static int acpi_pci_probe_root_resources(struct acpi_pci_root_info *info)
>> +{
>> +	int ret;
>> +	struct list_head *list = &info->resources;
>> +	struct acpi_device *device = info->bridge;
>> +	struct resource_entry *entry, *tmp;
>> +	unsigned long flags;
>> +
>> +	flags = IORESOURCE_IO | IORESOURCE_MEM | IORESOURCE_MEM_8AND16BIT;
> 
> Is IORESOURCE_MEM_8AND16BIT required because of some pending patches
> that will change ACPI resource filtering ? It does not seem to make
> a difference in the mainline code, AFAICT.
Hi Lorenzo,
	Sorry, the 'IORESOURCE_MEM_8AND16BIT' is leaked into this patch
from another bugfix patch. It should be removed.

>> +static void acpi_pci_root_release_info(struct pci_host_bridge *bridge)
>> +{
>> +	struct resource *res;
>> +	struct resource_entry *entry;
>> +
>> +	resource_list_for_each_entry(entry, &bridge->windows) {
>> +		res = entry->res;
>> +		if (res->parent &&
>> +		    (res->flags & (IORESOURCE_MEM | IORESOURCE_IO)))
>> +			release_resource(res);
>> +	}
> 
> It is a question: is this loop necessary given that we are already
> releasing resources in __acpi_pci_root_release_info() ?
Function pci_create_root_bus() moves resources from info->resources list
onto bridge->windows list, so an ACPI resource will be either on
info->resources or bridge->windows. Thus we need to deal with both
info->resources and bridge->windows.

> 
>> +	__acpi_pci_root_release_info(bridge->release_data);
>> +}
>> +
>> +struct pci_bus *acpi_pci_root_create(struct acpi_pci_root *root,
>> +				     struct acpi_pci_root_ops *ops,
>> +				     struct acpi_pci_root_info *info,
>> +				     void *sysdata, int segment, int node)
> 
> I do not think you need to pass segment and node, they clutter the
> function signature when you can retrieve them from root, I would
> make them local variables and use root->segment and acpi_get_node
> in the function body to retrieve them.
On x86, node and segment may be overridden under certain conditions.
For example, segment will always be 0 if 'pci_ignore_seg' is set.

>> +{
>> +	int ret, busnum = root->secondary.start;
>> +	struct acpi_device *device = root->device;
>> +	struct pci_bus *bus;
>> +
>> +	info->root = root;
>> +	info->bridge = device;
>> +	info->ops = ops;
>> +	INIT_LIST_HEAD(&info->resources);
>> +	snprintf(info->name, sizeof(info->name), "PCI Bus %04x:%02x",
>> +		 segment, busnum);
>> +
>> +	if (ops->init_info && ops->init_info(info))
>> +		goto out_release_info;
>> +	ret = acpi_pci_probe_root_resources(info);
>> +	if (ops->prepare_resources)
>> +		ret = ops->prepare_resources(info, ret);
> 
> You go through this ret passing song and dance because we may want to
> call prepare_resources even if acpi_pci_probe_root_resource failed (on
> x86), correct ? I will have a further look at x86 and ia64 if we
> can consolidate these ops function hooks even further.
Yes. X86 uses flag 'pci_use_crs' to choose ACPI parsed resources or
other method parsed resources. This provides user a way to work
around some bios issues.
Thanks!
Gerry

--
To unsubscribe from this list: send the line "unsubscribe linux-pci" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html




[Index of Archives]     [DMA Engine]     [Linux Coverity]     [Linux USB]     [Video for Linux]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]     [Greybus]

  Powered by Linux