All of lore.kernel.org
 help / color / mirror / Atom feed
From: Yinghai Lu <yinghai@kernel.org>
To: Jesse Barnes <jbarnes@virtuousgeek.org>
Cc: Ingo Molnar <mingo@elte.hu>,
	Linus Torvalds <torvalds@linux-foundation.org>,
	Ivan Kokshaysky <ink@jurassic.park.msu.ru>,
	Kenji Kaneshige <kaneshige.kenji@jp.fujitsu.com>,
	Alex Chiang <achiang@hp.com>,
	Bjorn Helgaas <bjorn.helgaas@hp.com>,
	linux-kernel@vger.kernel.org, linux-pci@vger.kernel.org
Subject: Re: [PATCH 03/14] pci: add pci_bridge_release_unused_res and pci_bus_release_unused_bridge_res
Date: Fri, 15 Jan 2010 16:20:14 -0800	[thread overview]
Message-ID: <4B51063E.5070206@kernel.org> (raw)
In-Reply-To: <20100115105305.400cda90@jbarnes-piketon>

On 01/15/2010 10:53 AM, Jesse Barnes wrote:
> On Tue, 22 Dec 2009 15:02:23 -0800
> Yinghai Lu <yinghai@kernel.org> wrote:
>> +static void pci_bridge_release_unused_res(struct pci_bus *bus,
>> +					  unsigned long type)
>> +{
>> +	int idx;
>> +	bool changed = false;
>> +	struct pci_dev *dev;
>> +	struct resource *r;
>> +	unsigned long type_mask = IORESOURCE_IO | IORESOURCE_MEM |
>> +				  IORESOURCE_PREFETCH;
>> +
>> +	dev = bus->self;
>> +	for (idx = PCI_BRIDGE_RESOURCES; idx <=
>> PCI_BRIDGE_RESOURCE_END;
>> +	     idx++) {
>> +		r = &dev->resource[idx];
>> +		if ((r->flags & type_mask) != type)
>> +			continue;
>> +		if (!r->parent)
>> +			continue;
>> +		/*
>> +		 * if there are children under that, we should
>> release them
>> +		 *  all
>> +		 */
>> +		release_child_resources(r);
>> +		if (!release_resource(r)) {
>> +			dev_printk(KERN_DEBUG, &dev->dev,
>> +				 "resource %d %pR released\n", idx,
>> r);
>> +			/* keep the old size */
>> +			r->end = resource_size(r) - 1;
>> +			r->start = 0;
>> +			r->flags = 0;
>> +			changed = true;
>> +		}
>> +	}
>> +
>> +	if (changed) {
>> +		if (type & IORESOURCE_PREFETCH) {
>> +			/* avoiding touch the one without PREF */
>> +			type = IORESOURCE_PREFETCH;
>> +		}
>> +		__pci_setup_bridge(bus, type);
>> +	}
>> +}
> 
> Isn't this freeing resources regardless of whether there are children?
> If so, shouldn't it just be called pci_bridge_release_resources?
> 
ok
>> +
>> +/*
>> + * try to release pci bridge resources that is from leaf bridge,
>> + * so we can allocate big new one later
>> + * check:
>> + *    0: only release the bridge and only the bridge is leaf
>> + *    1: release all down side bridge for third shoot
>> + */
>> +static void __ref pci_bus_release_unused_bridge_res(struct pci_bus
>> *bus,
>> +						    unsigned long
>> type,
>> +						    int check_leaf)
>> +{
>> +	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;
>> +
>> +		switch (dev->class >> 8) {
>> +		case PCI_CLASS_BRIDGE_CARDBUS:
>> +			is_leaf_bridge = false;
>> +			break;
>> +
>> +		case PCI_CLASS_BRIDGE_PCI:
>> +		default:
>> +			is_leaf_bridge = false;
>> +			if (!check_leaf)
>> +				pci_bus_release_unused_bridge_res(b,
>> type,
>> +							 check_leaf);
>> +			break;
>> +		}
>> +	}
>> +
>> +	/* The root bus? */
>> +	if (!bus->self)
>> +		return;
>> +
>> +	switch (bus->self->class >> 8) {
>> +	case PCI_CLASS_BRIDGE_CARDBUS:
>> +		break;
>> +
>> +	case PCI_CLASS_BRIDGE_PCI:
>> +	default:
>> +		if ((check_leaf && is_leaf_bridge) || !check_leaf)
>> +			pci_bridge_release_unused_res(bus, type);
>> +		break;
>> +	}
>> +}
> 
> Naming comment applies here too.  I'd also rather see the "check_leaf"
> flag be an enum, that makes the callers more self documenting.  The
> enums should probably be called "leaf_only" and "whole_subtree" or
> similar , since the function will only release the resources of a leaf
> bridge when the former is passed, while the whole bridge and its
> subtree will be released in the latter case.
ok

YH

  reply	other threads:[~2010-01-16  0:21 UTC|newest]

Thread overview: 42+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-12-22 23:02 [PATCH 00/14] pci: update pci bridge resources Yinghai Lu
2009-12-22 23:02 ` [PATCH 01/14] pci: separate pci_setup_bridge to small functions Yinghai Lu
2010-01-15 18:54   ` Jesse Barnes
2009-12-22 23:02 ` [PATCH 02/14] resource: add release_child_resources Yinghai Lu
2010-01-15 18:54   ` Jesse Barnes
2009-12-22 23:02 ` [PATCH 03/14] pci: add pci_bridge_release_unused_res and pci_bus_release_unused_bridge_res Yinghai Lu
2010-01-15 18:53   ` Jesse Barnes
2010-01-16  0:20     ` Yinghai Lu [this message]
2009-12-22 23:02 ` [PATCH 04/14] pci: don't dump it when bus resource flags is not used Yinghai Lu
2010-01-15 18:54   ` Jesse Barnes
2009-12-22 23:02 ` [PATCH 05/14] pci: add failed_list to record failed one for pci_bus_assign_resources Yinghai Lu
2010-01-15 18:56   ` Jesse Barnes
2010-01-15 21:13     ` Yinghai Lu
2010-01-15 21:41   ` Bjorn Helgaas
2009-12-22 23:02 ` [PATCH 06/14] pci: reject mmio range start from 0 on pci_bridge read Yinghai Lu
2010-01-15 19:19   ` Jesse Barnes
2010-01-15 21:15     ` Yinghai Lu
2009-12-22 23:02 ` [PATCH 07/14] pci: don't shrink bridge resources Yinghai Lu
2010-01-15 19:04   ` Jesse Barnes
2010-01-15 21:09     ` Yinghai Lu
2010-01-15 21:31       ` Jesse Barnes
2010-01-16  0:32         ` Yinghai Lu
2009-12-22 23:02 ` [PATCH 08/14] pci: update bridge res to get more big range in pci assign unssign Yinghai Lu
2010-01-15 19:12   ` Jesse Barnes
2010-01-15 21:12     ` Yinghai Lu
2010-01-15 21:34       ` Bjorn Helgaas
2010-01-15 21:34       ` Jesse Barnes
2009-12-22 23:02 ` [PATCH 09/14] pci: introduce pci_assign_unassigned_bridge_resources Yinghai Lu
2010-01-13  0:50   ` Kenji Kaneshige
2010-01-13  1:58     ` Yinghai Lu
2010-01-13  7:31       ` Kenji Kaneshige
2010-01-13  7:52         ` Yinghai Lu
2009-12-22 23:02 ` [PATCH 10/14] pci: pciehp clean flow in pciehp_configure_device Yinghai Lu
2010-01-15 19:14   ` Jesse Barnes
2010-01-15 21:14     ` Yinghai Lu
2009-12-22 23:02 ` [PATCH 11/14] pci: pciehp second try to get big range for pcie devices Yinghai Lu
2009-12-22 23:02 ` [PATCH 12/14] pci: pci_bridge_release_res Yinghai Lu
2009-12-22 23:02 ` [PATCH 13/14] pciehp: add support for bridge resource reallocation Yinghai Lu
2009-12-22 23:02 ` [PATCH 14/14] pci: set PCI_PREF_RANGE_TYPE_64 in pci_bridge_check_ranges Yinghai Lu
2010-01-08 21:33 ` [PATCH 00/14] pci: update pci bridge resources Patrick Keller
2010-01-11 21:57 ` Patrick Keller
2010-01-12 18:18   ` Jesse Barnes

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=4B51063E.5070206@kernel.org \
    --to=yinghai@kernel.org \
    --cc=achiang@hp.com \
    --cc=bjorn.helgaas@hp.com \
    --cc=ink@jurassic.park.msu.ru \
    --cc=jbarnes@virtuousgeek.org \
    --cc=kaneshige.kenji@jp.fujitsu.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-pci@vger.kernel.org \
    --cc=mingo@elte.hu \
    --cc=torvalds@linux-foundation.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.