| 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
| ||
|
Date: Tue, 9 Sep 2014 14:35:46 +0100
From: Lorenzo Pieralisi <lorenzo.pieralisi@....com>
To: Liviu Dudau <Liviu.Dudau@....com>
Cc: Bjorn Helgaas <bhelgaas@...gle.com>, Arnd Bergmann <arnd@...db.de>,
Rob Herring <robh+dt@...nel.org>,
Jason Gunthorpe <jgunthorpe@...idianresearch.com>,
Benjamin Herrenschmidt <benh@...nel.crashing.org>,
Catalin Marinas <Catalin.Marinas@....com>,
Will Deacon <Will.Deacon@....com>,
Russell King <linux@....linux.org.uk>,
linux-pci <linux-pci@...r.kernel.org>,
Linus Walleij <linus.walleij@...aro.org>,
Tanmay Inamdar <tinamdar@....com>,
Grant Likely <grant.likely@...retlab.ca>,
Sinan Kaya <okaya@...eaurora.org>,
Jingoo Han <jg1.han@...sung.com>,
Kukjin Kim <kgene.kim@...sung.com>,
Suravee Suthikulanit <suravee.suthikulpanit@....com>,
linux-arch <linux-arch@...r.kernel.org>,
LKML <linux-kernel@...r.kernel.org>,
Device Tree ML <devicetree@...r.kernel.org>,
LAKML <linux-arm-kernel@...ts.infradead.org>,
"grant.likely@...aro.org" <grant.likely@...aro.org>
Subject: Re: [PATCH v10 08/10] OF: PCI: Add support for parsing PCI host
bridge resources from DT
On Mon, Sep 08, 2014 at 02:54:30PM +0100, Liviu Dudau wrote:
> Provide a function to parse the PCI DT ranges that can be used to
> create a pci_host_bridge structure together with its associated
> bus.
>
> Cc: Bjorn Helgaas <bhelgaas@...gle.com>
> Cc: Arnd Bergmann <arnd@...db.de>
> Cc: Grant Likely <grant.likely@...aro.org>
> Cc: Rob Herring <robh+dt@...nel.org>
> Cc: Catalin Marinas <catalin.marinas@....com>
> Signed-off-by: Liviu Dudau <Liviu.Dudau@....com>
> ---
> drivers/of/of_pci.c | 102 +++++++++++++++++++++++++++++++++++++++++++++++++
> include/linux/of_pci.h | 11 ++++++
> 2 files changed, 113 insertions(+)
>
> diff --git a/drivers/of/of_pci.c b/drivers/of/of_pci.c
> index a107edb..36701da 100644
> --- a/drivers/of/of_pci.c
> +++ b/drivers/of/of_pci.c
> @@ -1,7 +1,9 @@
> #include <linux/kernel.h>
> #include <linux/export.h>
> #include <linux/of.h>
> +#include <linux/of_address.h>
> #include <linux/of_pci.h>
> +#include <linux/slab.h>
>
> static inline int __of_pci_pci_compare(struct device_node *node,
> unsigned int data)
> @@ -123,6 +125,106 @@ int of_pci_get_domain_nr(struct device_node *node, bool allocate_if_missing)
> }
> EXPORT_SYMBOL_GPL(of_pci_get_domain_nr);
>
> +/**
> + * of_pci_get_host_bridge_resources - Parse PCI host bridge resources from DT
> + * @dev: device node of the host bridge having the range property
> + * @busno: bus number associated with the bridge root bus
> + * @bus_max: maximum number of busses for this bridge
> + * @resources: list where the range of resources will be added after DT parsing
> + * @io_base: pointer to a variable that will contain on return the physical
> + * address for the start of the I/O range.
> + *
> + * It is the callers job to free the @resources list.
> + *
> + * This function will parse the "ranges" property of a PCI host bridge device
> + * node and setup the resource mapping based on its content. It is expected
> + * that the property conforms with the Power ePAPR document.
You should also define what it returns and when.
> + *
> + */
> +int of_pci_get_host_bridge_resources(struct device_node *dev,
> + unsigned char busno, unsigned char bus_max,
> + struct list_head *resources, resource_size_t *io_base)
> +{
> + struct resource *res;
> + struct resource *bus_range;
> + struct of_pci_range range;
> + struct of_pci_range_parser parser;
> + char range_type[4];
> + int err;
> +
> + bus_range = kzalloc(sizeof(*bus_range), GFP_KERNEL);
> + if (!bus_range)
> + return -ENOMEM;
> +
> + pr_info("PCI host bridge %s ranges:\n", dev->full_name);
> +
> + err = of_pci_parse_bus_range(dev, bus_range);
> + if (err) {
> + bus_range->start = busno;
> + bus_range->end = bus_max;
> + bus_range->flags = IORESOURCE_BUS;
> + pr_info(" No bus range found for %s, using %pR\n",
> + dev->full_name, &bus_range);
> + } else {
> + if (bus_range->end > bus_range->start + bus_max)
> + bus_range->end = bus_range->start + bus_max;
> + }
> + pci_add_resource(resources, bus_range);
This means that eg in the PCI generic host controller I cannot "filter"
the bus resource, unless I remove it, "filter" it, and add it again.
I certainly can't filter a resource that has been already added without
removing it first.
Thoughts ?
> +
> + /* Check for ranges property */
> + err = of_pci_range_parser_init(&parser, dev);
> + if (err)
> + goto parse_failed;
> +
> + pr_debug("Parsing ranges property...\n");
> + for_each_of_pci_range(&parser, &range) {
> + /* Read next ranges element */
> + if ((range.flags & IORESOURCE_TYPE_BITS) == IORESOURCE_IO)
> + snprintf(range_type, 4, " IO");
> + else if ((range.flags & IORESOURCE_TYPE_BITS) == IORESOURCE_MEM)
> + snprintf(range_type, 4, "MEM");
> + else
> + snprintf(range_type, 4, "err");
> + pr_info(" %s %#010llx..%#010llx -> %#010llx\n", range_type,
> + range.cpu_addr, range.cpu_addr + range.size - 1,
> + range.pci_addr);
> +
> + /*
> + * If we failed translation or got a zero-sized region
> + * then skip this range
> + */
> + if (range.cpu_addr == OF_BAD_ADDR || range.size == 0)
> + continue;
> +
> + res = kzalloc(sizeof(struct resource), GFP_KERNEL);
> + if (!res) {
> + err = -ENOMEM;
> + goto parse_failed;
> + }
> +
> + err = of_pci_range_to_resource(&range, dev, res);
> + if (err) {
> + kfree(res);
You might want to add a label to free res to make things more uniform.
> + goto parse_failed;
> + }
> +
> + if (resource_type(res) == IORESOURCE_IO) {
> + if (*io_base)
You do not zero io_base in the first place so you should ask the API
user to do that. Is 0 a valid value BTW ? If it is you've got to resort
to something else to detect multiple IO resources.
Lorenzo
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists