From: Arnd Bergmann <arnd@kernel.org> To: Ray Jui <ray.jui@broadcom.com> Cc: Florian Fainelli <f.fainelli@gmail.com>, devicetree <devicetree@vger.kernel.org>, linux-kernel <linux-kernel@vger.kernel.org>, Arnd Bergmann <arnd@arndb.de>, Scott Branden <sbranden@broadcom.com>, Ray Jui <rjui@broadcom.com>, linux-arm-msm <linux-arm-msm@vger.kernel.org>, Andy Gross <agross@kernel.org>, Bjorn Andersson <bjorn.andersson@linaro.org>, Rob Herring <robh+dt@kernel.org>, bcm-kernel-feedback-list <bcm-kernel-feedback-list@broadcom.com>, Zhen Lei <thunder.leizhen@huawei.com>, linux-arm-kernel <linux-arm-kernel@lists.infradead.org>, Bharat Gooty <bharat.gooty@broadcom.com> Subject: Re: [PATCH v2 1/2] arm64: dts: broadcom: clear the warnings caused by empty dma-ranges Date: Mon, 14 Dec 2020 20:46:33 +0100 [thread overview] Message-ID: <CAK8P3a2XYk8D80XARrpUSBHk1yye3KHXOdaQge4HNSZZOC=xKw@mail.gmail.com> (raw) In-Reply-To: <9c6c6b7e-8c39-8c49-5c87-9b560c027841@broadcom.com> On Mon, Dec 14, 2020 at 8:09 PM Ray Jui <ray.jui@broadcom.com> wrote: > On 11/28/2020 1:58 AM, Arnd Bergmann wrote: > > On Sat, Nov 28, 2020 at 5:53 AM Florian Fainelli <f.fainelli@gmail.com> wrote: > >> > >> On Fri, 16 Oct 2020 17:08:32 +0800, Zhen Lei <thunder.leizhen@huawei.com> wrote: > >>> The scripts/dtc/checks.c requires that the node have empty "dma-ranges" > >>> property must have the same "#address-cells" and "#size-cells" values as > >>> the parent node. Otherwise, the following warnings is reported: > >>> > >>> arch/arm64/boot/dts/broadcom/stingray/stingray-usb.dtsi:7.3-14: Warning \ > >>> (dma_ranges_format): /usb:dma-ranges: empty "dma-ranges" property but \ > >>> its #address-cells (1) differs from / (2) > >>> arch/arm64/boot/dts/broadcom/stingray/stingray-usb.dtsi:7.3-14: Warning \ > >>> (dma_ranges_format): /usb:dma-ranges: empty "dma-ranges" property but \ > >>> its #size-cells (1) differs from / (2) > >>> > >>> Arnd Bergmann figured out why it's necessary: > >>> Also note that the #address-cells=<1> means that any device under > >>> this bus is assumed to only support 32-bit addressing, and DMA will > >>> have to go through a slow swiotlb in the absence of an IOMMU. > >>> > >>> Suggested-by: Arnd Bergmann <arnd@arndb.de> > >>> Signed-off-by: Zhen Lei <thunder.leizhen@huawei.com> > >>> --- > >> > >> Applied to devicetree-arm64/next, thanks! > > > > The notification may have gone missing, but I had merged it into v5.10-fixes > > already, and as of today, it's in mainline, so you can drop it from your > > next branch, or just leave it in if you want to avoid taking things out of > > your tree. > > It looks like this patch might have caused a regression on Stingray USB. > Bharat, could you please confirm? Well, this is what I had asked about originally, I assumed that Florian had asked someone with access to the datasheet. > The fix would be to properly define the dma-ranges to be 32-bit (0x0 ~ > 0xffffffff) since IOMMU is disabled on this device and the device's DMA > engine is on a 32-bit bus. That's not how dma-ranges work, they tell you what the capabilities of the bus are, while the capabilities of the device are identified by the properties of that device. The device claims to be compatible with "generic-xhci", so the driver asks for a 64-bit mask to be set according to the xhci specification. If this device is not xhci compliant, then it should not ask for a 64-bit mask. However, if this is a 64-bit capable bus master on a 32-bit bus, then the dma-ranges property should list the capabilities of the bus, so the kernel can force the driver to fall back to 32-bit addressing. Arnd
WARNING: multiple messages have this Message-ID (diff)
From: Arnd Bergmann <arnd@kernel.org> To: Ray Jui <ray.jui@broadcom.com> Cc: devicetree <devicetree@vger.kernel.org>, Florian Fainelli <f.fainelli@gmail.com>, Scott Branden <sbranden@broadcom.com>, Arnd Bergmann <arnd@arndb.de>, Ray Jui <rjui@broadcom.com>, Zhen Lei <thunder.leizhen@huawei.com>, linux-kernel <linux-kernel@vger.kernel.org>, Rob Herring <robh+dt@kernel.org>, Bjorn Andersson <bjorn.andersson@linaro.org>, Andy Gross <agross@kernel.org>, bcm-kernel-feedback-list <bcm-kernel-feedback-list@broadcom.com>, linux-arm-msm <linux-arm-msm@vger.kernel.org>, linux-arm-kernel <linux-arm-kernel@lists.infradead.org>, Bharat Gooty <bharat.gooty@broadcom.com> Subject: Re: [PATCH v2 1/2] arm64: dts: broadcom: clear the warnings caused by empty dma-ranges Date: Mon, 14 Dec 2020 20:46:33 +0100 [thread overview] Message-ID: <CAK8P3a2XYk8D80XARrpUSBHk1yye3KHXOdaQge4HNSZZOC=xKw@mail.gmail.com> (raw) In-Reply-To: <9c6c6b7e-8c39-8c49-5c87-9b560c027841@broadcom.com> On Mon, Dec 14, 2020 at 8:09 PM Ray Jui <ray.jui@broadcom.com> wrote: > On 11/28/2020 1:58 AM, Arnd Bergmann wrote: > > On Sat, Nov 28, 2020 at 5:53 AM Florian Fainelli <f.fainelli@gmail.com> wrote: > >> > >> On Fri, 16 Oct 2020 17:08:32 +0800, Zhen Lei <thunder.leizhen@huawei.com> wrote: > >>> The scripts/dtc/checks.c requires that the node have empty "dma-ranges" > >>> property must have the same "#address-cells" and "#size-cells" values as > >>> the parent node. Otherwise, the following warnings is reported: > >>> > >>> arch/arm64/boot/dts/broadcom/stingray/stingray-usb.dtsi:7.3-14: Warning \ > >>> (dma_ranges_format): /usb:dma-ranges: empty "dma-ranges" property but \ > >>> its #address-cells (1) differs from / (2) > >>> arch/arm64/boot/dts/broadcom/stingray/stingray-usb.dtsi:7.3-14: Warning \ > >>> (dma_ranges_format): /usb:dma-ranges: empty "dma-ranges" property but \ > >>> its #size-cells (1) differs from / (2) > >>> > >>> Arnd Bergmann figured out why it's necessary: > >>> Also note that the #address-cells=<1> means that any device under > >>> this bus is assumed to only support 32-bit addressing, and DMA will > >>> have to go through a slow swiotlb in the absence of an IOMMU. > >>> > >>> Suggested-by: Arnd Bergmann <arnd@arndb.de> > >>> Signed-off-by: Zhen Lei <thunder.leizhen@huawei.com> > >>> --- > >> > >> Applied to devicetree-arm64/next, thanks! > > > > The notification may have gone missing, but I had merged it into v5.10-fixes > > already, and as of today, it's in mainline, so you can drop it from your > > next branch, or just leave it in if you want to avoid taking things out of > > your tree. > > It looks like this patch might have caused a regression on Stingray USB. > Bharat, could you please confirm? Well, this is what I had asked about originally, I assumed that Florian had asked someone with access to the datasheet. > The fix would be to properly define the dma-ranges to be 32-bit (0x0 ~ > 0xffffffff) since IOMMU is disabled on this device and the device's DMA > engine is on a 32-bit bus. That's not how dma-ranges work, they tell you what the capabilities of the bus are, while the capabilities of the device are identified by the properties of that device. The device claims to be compatible with "generic-xhci", so the driver asks for a 64-bit mask to be set according to the xhci specification. If this device is not xhci compliant, then it should not ask for a 64-bit mask. However, if this is a 64-bit capable bus master on a 32-bit bus, then the dma-ranges property should list the capabilities of the bus, so the kernel can force the driver to fall back to 32-bit addressing. Arnd _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
next prev parent reply other threads:[~2020-12-14 19:49 UTC|newest] Thread overview: 54+ messages / expand[flat|nested] mbox.gz Atom feed top 2020-10-16 9:08 [PATCH v2 0/2] eliminate two common errors reported by any yaml on arm64 Zhen Lei 2020-10-16 9:08 ` Zhen Lei 2020-10-16 9:08 ` [PATCH v2 1/2] arm64: dts: broadcom: clear the warnings caused by empty dma-ranges Zhen Lei 2020-10-16 9:08 ` Zhen Lei [not found] ` <CAK8P3a2TSmsNSi-XFpT6AQ3jvVxJ1AW7Uf5tAo477wtwXZwUzg@mail.gmail.com> 2020-10-16 16:48 ` Florian Fainelli 2020-10-16 16:48 ` Florian Fainelli [not found] ` <CAK8P3a13ywHh7igdfDSPQz9Bw8YAnKWFLKARkk2NL5u6=6yb=w@mail.gmail.com> 2020-10-16 19:27 ` Florian Fainelli 2020-10-16 19:27 ` Florian Fainelli 2020-10-18 2:10 ` Leizhen (ThunderTown) 2020-10-18 2:10 ` Leizhen (ThunderTown) 2020-10-23 7:17 ` Arnd Bergmann 2020-10-26 2:21 ` Leizhen (ThunderTown) 2020-10-26 2:21 ` Leizhen (ThunderTown) 2020-11-09 6:18 ` Leizhen (ThunderTown) 2020-11-09 6:18 ` Leizhen (ThunderTown) 2020-11-09 17:28 ` Florian Fainelli 2020-11-09 17:28 ` Florian Fainelli 2020-11-09 17:56 ` Arnd Bergmann 2020-11-09 17:56 ` Arnd Bergmann 2020-11-09 18:00 ` Florian Fainelli 2020-11-09 18:00 ` Florian Fainelli 2020-11-28 4:53 ` Florian Fainelli 2020-11-28 4:53 ` Florian Fainelli 2020-11-28 9:58 ` Arnd Bergmann 2020-11-28 9:58 ` Arnd Bergmann 2020-12-14 19:09 ` Ray Jui 2020-12-14 19:09 ` Ray Jui 2020-12-14 19:46 ` Arnd Bergmann [this message] 2020-12-14 19:46 ` Arnd Bergmann 2020-12-15 15:40 ` Florian Fainelli 2020-12-15 15:40 ` Florian Fainelli [not found] ` <CACvutz9v+TBUbrCo3X-u5ebbs04nR0y0yQN3qWfSAyZVy9RM2g@mail.gmail.com> 2020-12-15 15:41 ` Florian Fainelli 2020-12-15 15:41 ` Florian Fainelli 2020-12-15 15:49 ` Arnd Bergmann 2020-12-15 15:49 ` Arnd Bergmann 2021-01-12 18:28 ` Ray Jui 2021-01-12 18:28 ` Ray Jui 2021-01-12 20:40 ` Arnd Bergmann 2021-01-12 20:40 ` Arnd Bergmann 2021-01-12 20:57 ` Ray Jui 2021-01-12 20:57 ` Ray Jui 2021-01-13 3:42 ` Bharat Gooty 2021-01-13 3:42 ` Bharat Gooty 2021-01-13 8:05 ` Arnd Bergmann 2021-01-13 8:05 ` Arnd Bergmann 2021-01-13 16:55 ` Florian Fainelli 2021-01-13 16:55 ` Florian Fainelli 2021-01-13 17:45 ` Ray Jui 2021-01-13 17:45 ` Ray Jui 2020-10-16 9:08 ` [PATCH v2 2/2] arm64: dts: qcom: " Zhen Lei 2020-10-16 9:08 ` Zhen Lei 2020-11-11 4:44 ` Bjorn Andersson 2020-11-11 4:44 ` Bjorn Andersson 2020-12-29 20:15 ` [PATCH v2 0/2] eliminate two common errors reported by any yaml on arm64 patchwork-bot+linux-arm-msm
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='CAK8P3a2XYk8D80XARrpUSBHk1yye3KHXOdaQge4HNSZZOC=xKw@mail.gmail.com' \ --to=arnd@kernel.org \ --cc=agross@kernel.org \ --cc=arnd@arndb.de \ --cc=bcm-kernel-feedback-list@broadcom.com \ --cc=bharat.gooty@broadcom.com \ --cc=bjorn.andersson@linaro.org \ --cc=devicetree@vger.kernel.org \ --cc=f.fainelli@gmail.com \ --cc=linux-arm-kernel@lists.infradead.org \ --cc=linux-arm-msm@vger.kernel.org \ --cc=linux-kernel@vger.kernel.org \ --cc=ray.jui@broadcom.com \ --cc=rjui@broadcom.com \ --cc=robh+dt@kernel.org \ --cc=sbranden@broadcom.com \ --cc=thunder.leizhen@huawei.com \ /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: linkBe 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.