All of lore.kernel.org
 help / color / mirror / Atom feed
From: Andrew Murray <amurray@embedded-bits.co.uk>
To: Liviu Dudau <Liviu.Dudau@arm.com>
Cc: linux-pci <linux-pci@vger.kernel.org>,
	Bjorn Helgaas <bhelgaas@google.com>,
	Catalin Marinas <Catalin.Marinas@arm.com>,
	Will Deacon <Will.Deacon@arm.com>,
	linaro-kernel <linaro-kernel@lists.linaro.org>,
	LKML <linux-kernel@vger.kernel.org>,
	"devicetree@vger.kernel.org" <devicetree@vger.kernel.org>,
	LAKML <linux-arm-kernel@lists.infradead.org>
Subject: Re: [PATCH v2 1/4] pci: OF: Fix the conversion of IO ranges into IO resources.
Date: Thu, 27 Feb 2014 13:22:19 +0000	[thread overview]
Message-ID: <CAPcvp5EqcKEWoH_--azp+sMykmEWtY5whHG=c9t3sZVXZyAPUg@mail.gmail.com> (raw)
In-Reply-To: <1393506402-11474-2-git-send-email-Liviu.Dudau@arm.com>

On 27 February 2014 13:06, Liviu Dudau <Liviu.Dudau@arm.com> wrote:
>
> The ranges property for a host bridge controller in DT describes
> the mapping between the PCI bus address and the CPU physical address.
> The resources framework however expects that the IO resources start
> at a pseudo "port" address 0 (zero) and have a maximum size of 64kb.

Is this just in the case of ARM? (I've tried to keep up with the
conversation, but apologies if I've misunderstood).

> The conversion from pci ranges to resources failed to take that into
> account.
>
> In the process move the function into drivers/of/address.c as it
> now depends on pci_address_to_pio() code.
>
> Signed-off-by: Liviu Dudau <Liviu.Dudau@arm.com>
>
> diff --git a/drivers/of/address.c b/drivers/of/address.c
> index 1a54f1f..7cf2b16 100644
> --- a/drivers/of/address.c
> +++ b/drivers/of/address.c
> @@ -719,3 +719,34 @@ void __iomem *of_iomap(struct device_node *np, int index)
>         return ioremap(res.start, resource_size(&res));
>  }
>  EXPORT_SYMBOL(of_iomap);
> +
> +/**
> + * of_pci_range_to_resource - Create a resource from an of_pci_range
> + * @range:     the PCI range that describes the resource
> + * @np:                device node where the range belongs to
> + * @res:       pointer to a valid resource that will be updated to
> + *              reflect the values contained in the range.
> + * Note that if the range is an IO range, the resource will be converted
> + * using pci_address_to_pio() which can fail if it is called to early or
> + * if the range cannot be matched to any host bridge IO space.
> + */
> +void of_pci_range_to_resource(struct of_pci_range *range,
> +       struct device_node *np, struct resource *res)
> +{
> +       res->flags = range->flags;
> +       if (res->flags & IORESOURCE_IO) {
> +               unsigned long port;
> +               port = pci_address_to_pio(range->pci_addr);

Is this likely to break existing users of of_pci_range_to_resource?

For example arch/mips: IO_SPACE_LIMIT defaults to 0xffff and there is
no overridden implementation for pci_address_to_pio, therefore this
will set res->start to OF_BAD_ADDR whereas previously it would have
been the CPU address for I/O (assuming the cpu_addr was previously >
64K).

I have no idea if I/O previously worked for mips, but this patch seems
to change that behavior. It may be a similar story for microblaze and
powerpc.

Andrew Murray

> +               if (port == (unsigned long)-1) {
> +                       res->start = (resource_size_t)OF_BAD_ADDR;
> +                       res->end = (resource_size_t)OF_BAD_ADDR;
> +                       return;
> +               }
> +               res->start = port;
> +       } else {
> +               res->start = range->cpu_addr;
> +       }
> +       res->end = res->start + range->size - 1;
> +       res->parent = res->child = res->sibling = NULL;
> +       res->name = np->full_name;
> +}
> diff --git a/include/linux/of_address.h b/include/linux/of_address.h
> index 5f6ed6b..a667762 100644
> --- a/include/linux/of_address.h
> +++ b/include/linux/of_address.h
> @@ -23,17 +23,8 @@ struct of_pci_range {
>  #define for_each_of_pci_range(parser, range) \
>         for (; of_pci_range_parser_one(parser, range);)
>
> -static inline void of_pci_range_to_resource(struct of_pci_range *range,
> -                                           struct device_node *np,
> -                                           struct resource *res)
> -{
> -       res->flags = range->flags;
> -       res->start = range->cpu_addr;
> -       res->end = range->cpu_addr + range->size - 1;
> -       res->parent = res->child = res->sibling = NULL;
> -       res->name = np->full_name;
> -}
> -
> +extern void of_pci_range_to_resource(struct of_pci_range *range,
> +               struct device_node *np, struct resource *res);
>  /* Translate a DMA address from device space to CPU space */
>  extern u64 of_translate_dma_address(struct device_node *dev,
>                                     const __be32 *in_addr);
> --
> 1.9.0
>
> --
> 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

WARNING: multiple messages have this Message-ID (diff)
From: amurray@embedded-bits.co.uk (Andrew Murray)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH v2 1/4] pci: OF: Fix the conversion of IO ranges into IO resources.
Date: Thu, 27 Feb 2014 13:22:19 +0000	[thread overview]
Message-ID: <CAPcvp5EqcKEWoH_--azp+sMykmEWtY5whHG=c9t3sZVXZyAPUg@mail.gmail.com> (raw)
In-Reply-To: <1393506402-11474-2-git-send-email-Liviu.Dudau@arm.com>

On 27 February 2014 13:06, Liviu Dudau <Liviu.Dudau@arm.com> wrote:
>
> The ranges property for a host bridge controller in DT describes
> the mapping between the PCI bus address and the CPU physical address.
> The resources framework however expects that the IO resources start
> at a pseudo "port" address 0 (zero) and have a maximum size of 64kb.

Is this just in the case of ARM? (I've tried to keep up with the
conversation, but apologies if I've misunderstood).

> The conversion from pci ranges to resources failed to take that into
> account.
>
> In the process move the function into drivers/of/address.c as it
> now depends on pci_address_to_pio() code.
>
> Signed-off-by: Liviu Dudau <Liviu.Dudau@arm.com>
>
> diff --git a/drivers/of/address.c b/drivers/of/address.c
> index 1a54f1f..7cf2b16 100644
> --- a/drivers/of/address.c
> +++ b/drivers/of/address.c
> @@ -719,3 +719,34 @@ void __iomem *of_iomap(struct device_node *np, int index)
>         return ioremap(res.start, resource_size(&res));
>  }
>  EXPORT_SYMBOL(of_iomap);
> +
> +/**
> + * of_pci_range_to_resource - Create a resource from an of_pci_range
> + * @range:     the PCI range that describes the resource
> + * @np:                device node where the range belongs to
> + * @res:       pointer to a valid resource that will be updated to
> + *              reflect the values contained in the range.
> + * Note that if the range is an IO range, the resource will be converted
> + * using pci_address_to_pio() which can fail if it is called to early or
> + * if the range cannot be matched to any host bridge IO space.
> + */
> +void of_pci_range_to_resource(struct of_pci_range *range,
> +       struct device_node *np, struct resource *res)
> +{
> +       res->flags = range->flags;
> +       if (res->flags & IORESOURCE_IO) {
> +               unsigned long port;
> +               port = pci_address_to_pio(range->pci_addr);

Is this likely to break existing users of of_pci_range_to_resource?

For example arch/mips: IO_SPACE_LIMIT defaults to 0xffff and there is
no overridden implementation for pci_address_to_pio, therefore this
will set res->start to OF_BAD_ADDR whereas previously it would have
been the CPU address for I/O (assuming the cpu_addr was previously >
64K).

I have no idea if I/O previously worked for mips, but this patch seems
to change that behavior. It may be a similar story for microblaze and
powerpc.

Andrew Murray

> +               if (port == (unsigned long)-1) {
> +                       res->start = (resource_size_t)OF_BAD_ADDR;
> +                       res->end = (resource_size_t)OF_BAD_ADDR;
> +                       return;
> +               }
> +               res->start = port;
> +       } else {
> +               res->start = range->cpu_addr;
> +       }
> +       res->end = res->start + range->size - 1;
> +       res->parent = res->child = res->sibling = NULL;
> +       res->name = np->full_name;
> +}
> diff --git a/include/linux/of_address.h b/include/linux/of_address.h
> index 5f6ed6b..a667762 100644
> --- a/include/linux/of_address.h
> +++ b/include/linux/of_address.h
> @@ -23,17 +23,8 @@ struct of_pci_range {
>  #define for_each_of_pci_range(parser, range) \
>         for (; of_pci_range_parser_one(parser, range);)
>
> -static inline void of_pci_range_to_resource(struct of_pci_range *range,
> -                                           struct device_node *np,
> -                                           struct resource *res)
> -{
> -       res->flags = range->flags;
> -       res->start = range->cpu_addr;
> -       res->end = range->cpu_addr + range->size - 1;
> -       res->parent = res->child = res->sibling = NULL;
> -       res->name = np->full_name;
> -}
> -
> +extern void of_pci_range_to_resource(struct of_pci_range *range,
> +               struct device_node *np, struct resource *res);
>  /* Translate a DMA address from device space to CPU space */
>  extern u64 of_translate_dma_address(struct device_node *dev,
>                                     const __be32 *in_addr);
> --
> 1.9.0
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-pci" in
> the body of a message to majordomo at vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

  parent reply	other threads:[~2014-02-27 13:22 UTC|newest]

Thread overview: 74+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-02-27 13:06 [PATCH v2 0/4] [RFC] Support for creating generic host_bridge from device tree Liviu Dudau
2014-02-27 13:06 ` Liviu Dudau
     [not found] ` < 1393506402-11474-5-git-send-email-Liviu.Dudau@arm.com>
2014-02-27 13:06 ` [PATCH v2 1/4] pci: OF: Fix the conversion of IO ranges into IO resources Liviu Dudau
2014-02-27 13:06   ` Liviu Dudau
2014-02-27 13:20   ` Arnd Bergmann
2014-02-27 13:20     ` Arnd Bergmann
2014-02-27 13:20     ` Arnd Bergmann
2014-02-27 13:45     ` Liviu Dudau
2014-02-27 13:22   ` Andrew Murray [this message]
2014-02-27 13:22     ` Andrew Murray
2014-02-27 13:56     ` Liviu Dudau
2014-02-27 14:08       ` Arnd Bergmann
2014-02-27 14:21         ` Liviu Dudau
2014-02-27 16:00           ` Arnd Bergmann
2014-02-27 14:30         ` Liviu Dudau
2014-02-27 13:58     ` Arnd Bergmann
2014-02-27 13:58       ` Arnd Bergmann
2014-02-27 18:19   ` Jason Gunthorpe
2014-02-27 18:19     ` Jason Gunthorpe
2014-02-27 19:12     ` Liviu Dudau
2014-02-27 19:12       ` Liviu Dudau
2014-02-27 19:12       ` Liviu Dudau
2014-02-27 19:36       ` Jason Gunthorpe
2014-02-27 19:36         ` Jason Gunthorpe
2014-02-27 19:36         ` Jason Gunthorpe
2014-02-27 19:48         ` Arnd Bergmann
2014-02-27 19:48           ` Arnd Bergmann
2014-02-27 20:07           ` Jason Gunthorpe
2014-02-27 20:07             ` Jason Gunthorpe
2014-02-27 20:22             ` Arnd Bergmann
2014-02-27 20:22               ` Arnd Bergmann
2014-02-27 20:22               ` Arnd Bergmann
2014-02-28 12:50               ` Liviu Dudau
2014-02-28 12:50                 ` Liviu Dudau
2014-02-28 12:50                 ` Liviu Dudau
2014-02-27 13:06 ` [PATCH v2 2/4] pci: Create pci_host_bridge before its associated bus in pci_create_root_bus Liviu Dudau
2014-02-27 13:06   ` Liviu Dudau
2014-02-27 13:06   ` Liviu Dudau
2014-02-27 13:22   ` Arnd Bergmann
2014-02-27 13:22     ` Arnd Bergmann
2014-02-27 13:06 ` [PATCH v2 3/4] pci: Introduce a domain number for pci_host_bridge Liviu Dudau
2014-02-27 13:06   ` Liviu Dudau
2014-02-27 13:06   ` Liviu Dudau
2014-02-27 13:22   ` Arnd Bergmann
2014-02-27 13:22     ` Arnd Bergmann
2014-02-27 13:06 ` [PATCH v2 4/4] pci: Add support for creating a generic host_bridge from device tree Liviu Dudau
2014-02-27 13:06   ` Liviu Dudau
2014-02-27 13:06   ` Liviu Dudau
2014-02-27 13:38   ` Arnd Bergmann
2014-02-27 13:38     ` Arnd Bergmann
2014-02-27 13:48     ` Arnd Bergmann
2014-02-27 13:48       ` Arnd Bergmann
2014-02-27 13:48       ` Arnd Bergmann
2014-02-27 14:13     ` Liviu Dudau
2014-02-27 15:58       ` Arnd Bergmann
2014-02-27 16:20         ` Liviu Dudau
2014-02-27 16:45           ` Arnd Bergmann
2014-02-27 16:54             ` Liviu Dudau
2014-02-27 18:42               ` Arnd Bergmann
2014-02-27 23:32     ` Benjamin Herrenschmidt
2014-02-27 23:32       ` Benjamin Herrenschmidt
2014-02-27 23:32       ` Benjamin Herrenschmidt
2014-02-28  8:46       ` Arnd Bergmann
2014-02-28  8:46         ` Arnd Bergmann
2014-02-28  9:55       ` Liviu Dudau
2014-02-28  9:55         ` Liviu Dudau
2014-03-02  1:23         ` Benjamin Herrenschmidt
2014-03-02  1:23           ` Benjamin Herrenschmidt
2014-03-02  1:23           ` Benjamin Herrenschmidt
2014-03-02  1:25           ` Benjamin Herrenschmidt
2014-03-02  1:25             ` Benjamin Herrenschmidt
2014-03-07 18:58     ` Grant Likely
2014-03-07 18:58       ` Grant Likely
2014-03-07 18:58       ` Grant Likely

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='CAPcvp5EqcKEWoH_--azp+sMykmEWtY5whHG=c9t3sZVXZyAPUg@mail.gmail.com' \
    --to=amurray@embedded-bits.co.uk \
    --cc=Catalin.Marinas@arm.com \
    --cc=Liviu.Dudau@arm.com \
    --cc=Will.Deacon@arm.com \
    --cc=bhelgaas@google.com \
    --cc=devicetree@vger.kernel.org \
    --cc=linaro-kernel@lists.linaro.org \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@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 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.