linux-kernel - Re: [PATCH 4/4] of/pci: Add of_pci_parse_bus

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Thu, 14 Feb 2013 07:52:03 +0100
From:	Thierry Reding <thierry.reding@...onic-design.de>
To:	Grant Likely <grant.likely@...retlab.ca>
Cc:	Rob Herring <rob.herring@...xeda.com>,
	Andrew Murray <andrew.murray@....com>,
	Thomas Petazzoni <thomas.petazzoni@...e-electrons.com>,
	devicetree-discuss@...ts.ozlabs.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH 4/4] of/pci: Add of_pci_parse_bus_range() function

On Wed, Feb 13, 2013 at 10:58:44PM +0000, Grant Likely wrote:
> On Mon, 11 Feb 2013 09:22:20 +0100, Thierry Reding <thierry.reding@...onic-design.de> wrote:
> > This function can be used to parse a bus-range property as specified by
> > device nodes representing PCI bridges.
> > 
> > Signed-off-by: Thierry Reding <thierry.reding@...onic-design.de>
> 
> Ditto for this one. We can wait on it until there is a user.

This is used by the Tegra driver and as I've explained the reason for
sending these patches separately was to get them merged beforehand to
reduce the number of dependencies that need to be tracked once the
driver is merged (possibly in 3.10, maybe later given the amount of
extra work you want done).

The patch used to be part of the Tegra series, but since Thomas started
using them for his Marvell work I thought it might be a good idea to
make them available separately.

But I can take it back into the Tegra series since that's where we seem
to be headed.

> > +/**
> > + * of_pci_parse_bus_range() - parse the bus-range property of a PCI device
> > + * @node: device node
> > + * @res: address to a struct resource to return the bus-range
> > + *
> > + * Returns 0 on success or a negative error-code on failure.
> > + */
> > +int of_pci_parse_bus_range(struct device_node *node, struct resource *res)
> > +{
> > +	const __be32 *values;
> > +	int len;
> > +
> > +	values = of_get_property(node, "bus-range", &len);
> > +	if (!values || len < sizeof(*values) * 2)
> > +		return -EINVAL;
> > +
> > +	res->name = node->name;
> > +	res->start = be32_to_cpup(values++);
> > +	res->end = be32_to_cpup(values);
> > +	res->flags = IORESOURCE_BUS;
> 
> Is there precedence for using struct resource for passing around the PCI
> bus range values? Who will be the user of this function?

The PCI core code actually keeps track of bus-ranges this way. See
drivers/pci/probe.c for instance which uses the global the busn_resource
variable and keeps a list of struct resource:s for each domain as well.

Thierry

Content of type "application/pgp-signature" skipped