From: Robin Murphy <robin.murphy@arm.com>
To: Rob Herring <robh@kernel.org>, Oza Pawandeep <oza.oza@broadcom.com>
Cc: Joerg Roedel <joro@8bytes.org>,
Linux IOMMU <iommu@lists.linux-foundation.org>,
"linux-pci@vger.kernel.org" <linux-pci@vger.kernel.org>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
"linux-arm-kernel@lists.infradead.org"
<linux-arm-kernel@lists.infradead.org>,
"devicetree@vger.kernel.org" <devicetree@vger.kernel.org>,
"bcm-kernel-feedback-list@broadcom.com"
<bcm-kernel-feedback-list@broadcom.com>
Subject: Re: [RFC PATCH 3/3] of: fix node traversing in of_dma_get_range
Date: Mon, 27 Mar 2017 15:45:05 +0100 [thread overview]
Message-ID: <3aec823d-d3c7-03d3-68f7-963d3649c184@arm.com> (raw)
In-Reply-To: <CAL_Jsq+1f2pHEy7=2Q7xGYYJjuQk3rLHH4pPTKRVN4QTtSr4Kw@mail.gmail.com>
Hi Rob,
On 27/03/17 15:34, Rob Herring wrote:
> On Sat, Mar 25, 2017 at 12:31 AM, Oza Pawandeep <oza.oza@broadcom.com> wrote:
>> it jumps to the parent node without examining the child node.
>> also with that, it throws "no dma-ranges found for node"
>> for pci dma-ranges.
>>
>> this patch fixes device node traversing for dma-ranges.
>
> What's the DT look like that doesn't work?
The problem is the bodge in pci_dma_configure() where we don't have an
OF node for the actual device itself, so pass in the host bridge's OF
node instead. This happens to work well enough for dma-coherent, but I
don't think dma-ranges was even considered at the time.
As it happens I'm currently halfway through writing an experiment
wherein pci_dma_configure() creates a temporary child node for the
of_dma_configure() call if no other suitable alternative (e.g. some
intermediate bridge node) exists. How hard are you likely to NAK that
approach? ;)
> dma-ranges is supposed to be a bus property, not a device's property.
> So looking at the parent is correct behavior generally.
Indeed, this patch as-is will break currently correct DTs (because we
won't find dma-ranges on the device, so will bail before even looking at
the parent as we should).
Robin.
>
> Rob
>
WARNING: multiple messages have this Message-ID (diff)
From: Robin Murphy <robin.murphy-5wv7dgnIgG8@public.gmane.org>
To: Rob Herring <robh-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>,
Oza Pawandeep <oza.oza-dY08KVG/lbpWk0Htik3J/w@public.gmane.org>
Cc: "devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org"
<devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>,
"linux-pci-u79uwXL29TY76Z2rM5mHXA@public.gmane.org"
<linux-pci-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>,
"linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org"
<linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>,
Linux IOMMU
<iommu-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org>,
"bcm-kernel-feedback-list-dY08KVG/lbpWk0Htik3J/w@public.gmane.org"
<bcm-kernel-feedback-list-dY08KVG/lbpWk0Htik3J/w@public.gmane.org>,
"linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org"
<linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org>
Subject: Re: [RFC PATCH 3/3] of: fix node traversing in of_dma_get_range
Date: Mon, 27 Mar 2017 15:45:05 +0100 [thread overview]
Message-ID: <3aec823d-d3c7-03d3-68f7-963d3649c184@arm.com> (raw)
In-Reply-To: <CAL_Jsq+1f2pHEy7=2Q7xGYYJjuQk3rLHH4pPTKRVN4QTtSr4Kw-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
Hi Rob,
On 27/03/17 15:34, Rob Herring wrote:
> On Sat, Mar 25, 2017 at 12:31 AM, Oza Pawandeep <oza.oza-dY08KVG/lbpWk0Htik3J/w@public.gmane.org> wrote:
>> it jumps to the parent node without examining the child node.
>> also with that, it throws "no dma-ranges found for node"
>> for pci dma-ranges.
>>
>> this patch fixes device node traversing for dma-ranges.
>
> What's the DT look like that doesn't work?
The problem is the bodge in pci_dma_configure() where we don't have an
OF node for the actual device itself, so pass in the host bridge's OF
node instead. This happens to work well enough for dma-coherent, but I
don't think dma-ranges was even considered at the time.
As it happens I'm currently halfway through writing an experiment
wherein pci_dma_configure() creates a temporary child node for the
of_dma_configure() call if no other suitable alternative (e.g. some
intermediate bridge node) exists. How hard are you likely to NAK that
approach? ;)
> dma-ranges is supposed to be a bus property, not a device's property.
> So looking at the parent is correct behavior generally.
Indeed, this patch as-is will break currently correct DTs (because we
won't find dma-ranges on the device, so will bail before even looking at
the parent as we should).
Robin.
>
> Rob
>
WARNING: multiple messages have this Message-ID (diff)
From: Robin Murphy <robin.murphy@arm.com>
To: Rob Herring <robh@kernel.org>, Oza Pawandeep <oza.oza@broadcom.com>
Cc: "devicetree@vger.kernel.org" <devicetree@vger.kernel.org>,
"linux-pci@vger.kernel.org" <linux-pci@vger.kernel.org>,
Joerg Roedel <joro@8bytes.org>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
Linux IOMMU <iommu@lists.linux-foundation.org>,
"bcm-kernel-feedback-list@broadcom.com"
<bcm-kernel-feedback-list@broadcom.com>,
"linux-arm-kernel@lists.infradead.org"
<linux-arm-kernel@lists.infradead.org>
Subject: Re: [RFC PATCH 3/3] of: fix node traversing in of_dma_get_range
Date: Mon, 27 Mar 2017 15:45:05 +0100 [thread overview]
Message-ID: <3aec823d-d3c7-03d3-68f7-963d3649c184@arm.com> (raw)
In-Reply-To: <CAL_Jsq+1f2pHEy7=2Q7xGYYJjuQk3rLHH4pPTKRVN4QTtSr4Kw@mail.gmail.com>
Hi Rob,
On 27/03/17 15:34, Rob Herring wrote:
> On Sat, Mar 25, 2017 at 12:31 AM, Oza Pawandeep <oza.oza@broadcom.com> wrote:
>> it jumps to the parent node without examining the child node.
>> also with that, it throws "no dma-ranges found for node"
>> for pci dma-ranges.
>>
>> this patch fixes device node traversing for dma-ranges.
>
> What's the DT look like that doesn't work?
The problem is the bodge in pci_dma_configure() where we don't have an
OF node for the actual device itself, so pass in the host bridge's OF
node instead. This happens to work well enough for dma-coherent, but I
don't think dma-ranges was even considered at the time.
As it happens I'm currently halfway through writing an experiment
wherein pci_dma_configure() creates a temporary child node for the
of_dma_configure() call if no other suitable alternative (e.g. some
intermediate bridge node) exists. How hard are you likely to NAK that
approach? ;)
> dma-ranges is supposed to be a bus property, not a device's property.
> So looking at the parent is correct behavior generally.
Indeed, this patch as-is will break currently correct DTs (because we
won't find dma-ranges on the device, so will bail before even looking at
the parent as we should).
Robin.
>
> Rob
>
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
WARNING: multiple messages have this Message-ID (diff)
From: robin.murphy@arm.com (Robin Murphy)
To: linux-arm-kernel@lists.infradead.org
Subject: [RFC PATCH 3/3] of: fix node traversing in of_dma_get_range
Date: Mon, 27 Mar 2017 15:45:05 +0100 [thread overview]
Message-ID: <3aec823d-d3c7-03d3-68f7-963d3649c184@arm.com> (raw)
In-Reply-To: <CAL_Jsq+1f2pHEy7=2Q7xGYYJjuQk3rLHH4pPTKRVN4QTtSr4Kw@mail.gmail.com>
Hi Rob,
On 27/03/17 15:34, Rob Herring wrote:
> On Sat, Mar 25, 2017 at 12:31 AM, Oza Pawandeep <oza.oza@broadcom.com> wrote:
>> it jumps to the parent node without examining the child node.
>> also with that, it throws "no dma-ranges found for node"
>> for pci dma-ranges.
>>
>> this patch fixes device node traversing for dma-ranges.
>
> What's the DT look like that doesn't work?
The problem is the bodge in pci_dma_configure() where we don't have an
OF node for the actual device itself, so pass in the host bridge's OF
node instead. This happens to work well enough for dma-coherent, but I
don't think dma-ranges was even considered at the time.
As it happens I'm currently halfway through writing an experiment
wherein pci_dma_configure() creates a temporary child node for the
of_dma_configure() call if no other suitable alternative (e.g. some
intermediate bridge node) exists. How hard are you likely to NAK that
approach? ;)
> dma-ranges is supposed to be a bus property, not a device's property.
> So looking at the parent is correct behavior generally.
Indeed, this patch as-is will break currently correct DTs (because we
won't find dma-ranges on the device, so will bail before even looking at
the parent as we should).
Robin.
>
> Rob
>
next prev parent reply other threads:[~2017-03-27 14:45 UTC|newest]
Thread overview: 52+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-03-25 5:31 [RFC PATCH 1/3] of/pci: dma-ranges to account highest possible host bridge dma_mask Oza Pawandeep
2017-03-25 5:31 ` Oza Pawandeep
2017-03-25 5:31 ` Oza Pawandeep
2017-03-25 5:31 ` Oza Pawandeep via iommu
2017-03-25 5:31 ` [RFC PATCH 2/3] iommu/dma: account pci host bridge dma_mask for IOVA allocation Oza Pawandeep
2017-03-25 5:31 ` Oza Pawandeep
2017-03-25 5:31 ` Oza Pawandeep
2017-03-25 5:31 ` Oza Pawandeep via iommu
2017-03-25 5:31 ` [RFC PATCH 3/3] of: fix node traversing in of_dma_get_range Oza Pawandeep
2017-03-25 5:31 ` Oza Pawandeep
2017-03-25 5:31 ` Oza Pawandeep
2017-03-25 5:31 ` Oza Pawandeep via iommu
2017-03-27 14:34 ` Rob Herring
2017-03-27 14:34 ` Rob Herring
2017-03-27 14:34 ` Rob Herring
2017-03-27 14:34 ` Rob Herring
2017-03-27 14:45 ` Robin Murphy [this message]
2017-03-27 14:45 ` Robin Murphy
2017-03-27 14:45 ` Robin Murphy
2017-03-27 14:45 ` Robin Murphy
2017-03-28 4:50 ` Oza Oza
2017-03-28 4:50 ` Oza Oza
2017-03-28 4:50 ` Oza Oza
2017-03-28 4:50 ` Oza Oza via iommu
2017-03-27 14:46 ` [RFC PATCH 1/3] of/pci: dma-ranges to account highest possible host bridge dma_mask Rob Herring
2017-03-27 14:46 ` Rob Herring
2017-03-27 14:46 ` Rob Herring
2017-03-27 14:46 ` Rob Herring
2017-03-28 5:27 ` Oza Oza
2017-03-28 5:27 ` Oza Oza
2017-03-28 5:27 ` Oza Oza
2017-03-28 5:27 ` Oza Oza via iommu
2017-03-28 14:13 ` Rob Herring
2017-03-28 14:13 ` Rob Herring
2017-03-28 14:13 ` Rob Herring
2017-03-28 14:13 ` Rob Herring
2017-03-30 10:14 ` Oza Oza
2017-03-30 10:14 ` Oza Oza
2017-03-30 10:14 ` Oza Oza
2017-03-30 10:14 ` Oza Oza
2017-03-28 14:29 ` Robin Murphy
2017-03-28 14:29 ` Robin Murphy
2017-03-28 14:29 ` Robin Murphy
2017-03-28 14:29 ` Robin Murphy
2017-03-29 4:43 ` Oza Oza
2017-03-29 4:43 ` Oza Oza
2017-03-29 4:43 ` Oza Oza
2017-03-29 4:43 ` Oza Oza
2017-03-30 3:26 ` Oza Oza
2017-03-30 3:26 ` Oza Oza
2017-03-30 3:26 ` Oza Oza
2017-03-30 3:26 ` Oza Oza via iommu
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=3aec823d-d3c7-03d3-68f7-963d3649c184@arm.com \
--to=robin.murphy@arm.com \
--cc=bcm-kernel-feedback-list@broadcom.com \
--cc=devicetree@vger.kernel.org \
--cc=iommu@lists.linux-foundation.org \
--cc=joro@8bytes.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-pci@vger.kernel.org \
--cc=oza.oza@broadcom.com \
--cc=robh@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.