From: Grygorii Strashko via iommu <iommu-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org> To: Robin Murphy <robin.murphy-5wv7dgnIgG8@public.gmane.org>, hch-jcswGhMUV9g@public.gmane.org, m.szyprowski-Sze3O3UU22JBDgjK7y7TUQ@public.gmane.org Cc: gregkh-hQyY1W1yCW8ekmWlsbkhG0B+6BGkLq7r@public.gmane.org, x86-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org, linux-acpi-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, iommu-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org, robh+dt-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org, sudeep.holla-5wv7dgnIgG8@public.gmane.org, frowand.list-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org, linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org Subject: Re: [PATCH v2 2/7] dma-mapping: Generalise dma_32bit_limit flag Date: Fri, 27 Jul 2018 15:41:32 -0500 [thread overview] Message-ID: <5a7ed608-73dd-e515-3a22-0870fd6064be@ti.com> (raw) In-Reply-To: <5354ef69-c54e-170b-62d4-5110dc60aa8f-5wv7dgnIgG8@public.gmane.org> On 07/27/2018 03:11 PM, Robin Murphy wrote: > On 2018-07-27 6:45 PM, Grygorii Strashko wrote: >> On 07/23/2018 05:16 PM, Robin Murphy wrote: >>> Whilst the notion of an upstream DMA restriction is most commonly seen >>> in PCI host bridges saddled with a 32-bit native interface, a more >>> general version of the same issue can exist on complex SoCs where a bus >>> or point-to-point interconnect link from a device's DMA master interface >>> to another component along the path to memory (often an IOMMU) may carry >>> fewer address bits than the interfaces at both ends nominally support. >>> In order to properly deal with this, the first step is to expand the >>> dma_32bit_limit flag into an arbitrary mask. >>> >>> To minimise the impact on existing code, we'll make sure to only >>> consider this new mask valid if set. That makes sense anyway, since a >>> mask of zero would represent DMA not being wired up at all, and that >>> would be better handled by not providing valid ops in the first place. >>> >>> Signed-off-by: Robin Murphy <robin.murphy@arm.com> >> >> I'd like to note about some possible issue related to this change. >> >> There are some places in kernel where parent DMA configuration is >> copied to the manually created child devices, like: >> mfd-core.c >> mfd_add_device() >> pdev->dev.parent = parent; >> pdev->dev.type = &mfd_dev_type; >> pdev->dev.dma_mask = parent->dma_mask; >> pdev->dev.dma_parms = parent->dma_parms; >> pdev->dev.coherent_dma_mask = parent->coherent_dma_mask; >> >> Adding or changing generic DMA device properties might affect on such >> subsystems/drivers. Have you considered such cases? > > Yes, that's a lovely example of what I class as "bus code" creating a > child device and initialising its DMA parameters appropriately. The > subdevice goes on to get associated with an OF node or ACPI companion, > so when the subdriver for that function binds it should go through its > own dma_configure() process and pick up any further properties accordingly. Ideally ;), but in reality - dev->of_node not always initialized for child devices :( > > Code which just tries to copy the DMA configuration from an existing > device to a new one has never worked properly, because there is often > additional DMA configuration in archdata and other places it cannot > possibly know about. Last time I looked there were still some specific > hacks in the USB layer in order to interact correctly with the block > layer bounce limit, but I think anything truly wrong has been more or > less flushed out by now (the DMA ops changes for arm64 ACPI support > caught a fair few IIRC). Yep. For usb I wouldn't call it hack (dma controller device was introduced to avoid DMA props copying). Thanks for your comments. -- regards, -grygorii _______________________________________________ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
WARNING: multiple messages have this Message-ID (diff)
From: grygorii.strashko@ti.com (Grygorii Strashko) To: linux-arm-kernel@lists.infradead.org Subject: [PATCH v2 2/7] dma-mapping: Generalise dma_32bit_limit flag Date: Fri, 27 Jul 2018 15:41:32 -0500 [thread overview] Message-ID: <5a7ed608-73dd-e515-3a22-0870fd6064be@ti.com> (raw) In-Reply-To: <5354ef69-c54e-170b-62d4-5110dc60aa8f@arm.com> On 07/27/2018 03:11 PM, Robin Murphy wrote: > On 2018-07-27 6:45 PM, Grygorii Strashko wrote: >> On 07/23/2018 05:16 PM, Robin Murphy wrote: >>> Whilst the notion of an upstream DMA restriction is most commonly seen >>> in PCI host bridges saddled with a 32-bit native interface, a more >>> general version of the same issue can exist on complex SoCs where a bus >>> or point-to-point interconnect link from a device's DMA master interface >>> to another component along the path to memory (often an IOMMU) may carry >>> fewer address bits than the interfaces at both ends nominally support. >>> In order to properly deal with this, the first step is to expand the >>> dma_32bit_limit flag into an arbitrary mask. >>> >>> To minimise the impact on existing code, we'll make sure to only >>> consider this new mask valid if set. That makes sense anyway, since a >>> mask of zero would represent DMA not being wired up at all, and that >>> would be better handled by not providing valid ops in the first place. >>> >>> Signed-off-by: Robin Murphy <robin.murphy@arm.com> >> >> I'd like to note about some possible issue related to this change. >> >> There are some places in kernel where parent DMA configuration is >> copied to the manually created child devices, like: >> mfd-core.c >> mfd_add_device() >> ?????pdev->dev.parent = parent; >> ?????pdev->dev.type = &mfd_dev_type; >> ?????pdev->dev.dma_mask = parent->dma_mask; >> ?????pdev->dev.dma_parms = parent->dma_parms; >> ?????pdev->dev.coherent_dma_mask = parent->coherent_dma_mask; >> >> Adding or changing generic DMA device properties might affect on such >> subsystems/drivers. Have you considered such cases? > > Yes, that's a lovely example of what I class as "bus code" creating a > child device and initialising its DMA parameters appropriately. The > subdevice goes on to get associated with an OF node or ACPI companion, > so when the subdriver for that function binds it should go through its > own dma_configure() process and pick up any further properties accordingly. Ideally ;), but in reality - dev->of_node not always initialized for child devices :( > > Code which just tries to copy the DMA configuration from an existing > device to a new one has never worked properly, because there is often > additional DMA configuration in archdata and other places it cannot > possibly know about. Last time I looked there were still some specific > hacks in the USB layer in order to interact correctly with the block > layer bounce limit, but I think anything truly wrong has been more or > less flushed out by now (the DMA ops changes for arm64 ACPI support > caught a fair few IIRC). Yep. For usb I wouldn't call it hack (dma controller device was introduced to avoid DMA props copying). Thanks for your comments. -- regards, -grygorii
next prev parent reply other threads:[~2018-07-27 20:41 UTC|newest] Thread overview: 82+ messages / expand[flat|nested] mbox.gz Atom feed top 2018-07-23 22:16 [PATCH v2 0/7] Stop losing firmware-set DMA masks Robin Murphy 2018-07-23 22:16 ` Robin Murphy 2018-07-23 22:16 ` [PATCH v2 1/7] ACPI/IORT: Support address size limit for root complexes Robin Murphy 2018-07-23 22:16 ` Robin Murphy 2018-07-23 22:16 ` [PATCH v2 2/7] dma-mapping: Generalise dma_32bit_limit flag Robin Murphy 2018-07-23 22:16 ` Robin Murphy [not found] ` <c1720f0181b66f711e4097d85149757b16a7b0a7.1532382222.git.robin.murphy-5wv7dgnIgG8@public.gmane.org> 2018-07-25 11:29 ` Christoph Hellwig 2018-07-25 11:29 ` Christoph Hellwig 2018-07-27 17:45 ` Grygorii Strashko via iommu 2018-07-27 17:45 ` Grygorii Strashko [not found] ` <7872d914-8ea7-06e4-4a0c-489023e098d6-l0cyMroinI0@public.gmane.org> 2018-07-27 20:11 ` Robin Murphy 2018-07-27 20:11 ` Robin Murphy [not found] ` <5354ef69-c54e-170b-62d4-5110dc60aa8f-5wv7dgnIgG8@public.gmane.org> 2018-07-27 20:41 ` Grygorii Strashko via iommu [this message] 2018-07-27 20:41 ` Grygorii Strashko 2018-07-23 22:16 ` [PATCH v2 3/7] ACPI/IORT: Set bus DMA mask as appropriate Robin Murphy 2018-07-23 22:16 ` Robin Murphy [not found] ` <07cbf8f77fac552dca9b4c85a9d3bd8ed5a4cd29.1532382222.git.robin.murphy-5wv7dgnIgG8@public.gmane.org> 2018-07-25 11:29 ` Christoph Hellwig 2018-07-25 11:29 ` Christoph Hellwig 2018-07-25 13:16 ` Lorenzo Pieralisi 2018-07-25 13:16 ` Lorenzo Pieralisi 2018-07-23 22:16 ` [PATCH v2 4/7] of/device: " Robin Murphy 2018-07-23 22:16 ` Robin Murphy [not found] ` <cc56f074b8da7e03a187b2363b1f2c2955d62c1c.1532382222.git.robin.murphy-5wv7dgnIgG8@public.gmane.org> 2018-07-25 11:30 ` Christoph Hellwig 2018-07-25 11:30 ` Christoph Hellwig 2018-07-23 22:16 ` [PATCH v2 5/7] iommu/dma: Respect bus DMA limit for IOVAs Robin Murphy 2018-07-23 22:16 ` Robin Murphy [not found] ` <d370670edae9c9c537a5280c5e7c96bf3ec7ed8f.1532382222.git.robin.murphy-5wv7dgnIgG8@public.gmane.org> 2018-07-26 8:58 ` Christoph Hellwig 2018-07-26 8:58 ` Christoph Hellwig 2018-07-23 22:16 ` [PATCH v2 6/7] ACPI/IORT: Don't set default coherent DMA mask Robin Murphy 2018-07-23 22:16 ` Robin Murphy [not found] ` <3525869e8e7530128bf9718ae8af7d7564b3c684.1532382222.git.robin.murphy-5wv7dgnIgG8@public.gmane.org> 2018-07-25 15:27 ` Lorenzo Pieralisi 2018-07-25 15:27 ` Lorenzo Pieralisi 2018-07-25 15:43 ` Robin Murphy 2018-07-25 15:43 ` Robin Murphy 2018-07-23 22:16 ` [PATCH v2 7/7] OF: " Robin Murphy 2018-07-23 22:16 ` Robin Murphy [not found] ` <66c08e4df2032fde82a2f97544f41fd3a2f24a94.1532382222.git.robin.murphy-5wv7dgnIgG8@public.gmane.org> 2018-07-26 23:52 ` Grygorii Strashko via iommu 2018-07-26 23:52 ` Grygorii Strashko 2018-07-27 0:22 ` Grygorii Strashko 2018-07-27 0:22 ` Grygorii Strashko [not found] ` <92d6b010-b5c0-fc59-0668-5b455e26c912-l0cyMroinI0@public.gmane.org> 2018-07-27 11:36 ` Robin Murphy 2018-07-27 11:36 ` Robin Murphy 2018-07-27 17:34 ` Grygorii Strashko 2018-07-27 17:34 ` Grygorii Strashko [not found] ` <108a6254-1257-5daf-deaa-69bc4db2ec77-l0cyMroinI0@public.gmane.org> 2018-07-27 19:46 ` Robin Murphy 2018-07-27 19:46 ` Robin Murphy [not found] ` <c7a9c7ae-1f4a-af9d-df78-1f48bb5c28a5-5wv7dgnIgG8@public.gmane.org> 2018-07-27 18:13 ` Russell King - ARM Linux 2018-07-27 18:13 ` Russell King - ARM Linux [not found] ` <20180727181302.GC17271-l+eeeJia6m9URfEZ8mYm6t73F7V6hmMc@public.gmane.org> 2018-07-27 18:45 ` Grygorii Strashko via iommu 2018-07-27 18:45 ` Grygorii Strashko [not found] ` <affa2718-5f3a-7439-db25-ce171a99414a-l0cyMroinI0@public.gmane.org> 2018-07-27 20:42 ` Robin Murphy 2018-07-27 20:42 ` Robin Murphy 2018-07-27 19:29 ` Robin Murphy 2018-07-27 19:29 ` Robin Murphy 2018-07-26 23:45 ` [PATCH v2 0/7] Stop losing firmware-set DMA masks Grygorii Strashko 2018-07-26 23:45 ` Grygorii Strashko [not found] ` <c73bc8d2-b745-ff31-1949-7a59ab04ede6-l0cyMroinI0@public.gmane.org> 2018-07-27 10:55 ` Robin Murphy 2018-07-27 10:55 ` Robin Murphy [not found] ` <8b8ac841-5c4c-ae27-21d5-d7aaaf4c277c-5wv7dgnIgG8@public.gmane.org> 2018-07-27 17:22 ` Grygorii Strashko via iommu 2018-07-27 17:22 ` Grygorii Strashko [not found] ` <cover.1532382222.git.robin.murphy-5wv7dgnIgG8@public.gmane.org> 2018-07-25 11:31 ` Christoph Hellwig 2018-07-25 11:31 ` Christoph Hellwig [not found] ` <20180725113122.GD24736-jcswGhMUV9g@public.gmane.org> 2018-07-25 12:11 ` Joerg Roedel 2018-07-25 12:11 ` Joerg Roedel 2018-07-25 12:12 ` Robin Murphy 2018-07-25 12:12 ` Robin Murphy [not found] ` <5e036ade-db0b-f628-a4a0-6d014d1d76c8-5wv7dgnIgG8@public.gmane.org> 2018-07-25 12:17 ` Will Deacon 2018-07-25 12:17 ` Will Deacon 2018-07-25 13:58 ` Ard Biesheuvel 2018-07-25 13:58 ` Ard Biesheuvel 2018-07-26 9:00 ` Christoph Hellwig 2018-07-26 9:00 ` Christoph Hellwig 2018-07-29 12:32 ` Arnd Bergmann 2018-07-29 12:32 ` Arnd Bergmann [not found] ` <CAK8P3a3HDJ6svNN_cwvegxu20yNv8+tvc0D1A6Ooeq8agawbFg-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org> 2018-07-31 11:24 ` Robin Murphy 2018-07-31 11:24 ` Robin Murphy [not found] ` <1ccccc4b-7d4c-a3ee-23a2-f108916705e9-5wv7dgnIgG8@public.gmane.org> 2018-08-06 10:01 ` Arnd Bergmann 2018-08-06 10:01 ` Arnd Bergmann [not found] ` <CAK8P3a3ZcOeHMR_qFnsBdXED+2X8_AEMKoS5MeAQhbapbGmm9w-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org> 2018-08-06 12:13 ` Christoph Hellwig 2018-08-06 12:13 ` Christoph Hellwig [not found] ` <20180806121334.GA5340-jcswGhMUV9g@public.gmane.org> 2018-08-06 12:13 ` Arnd Bergmann 2018-08-06 12:13 ` Arnd Bergmann
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=5a7ed608-73dd-e515-3a22-0870fd6064be@ti.com \ --to=iommu-cuntk1mwbs9qetfly7kem3xjstq8ys+chz5vsktnxna@public.gmane.org \ --cc=frowand.list-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org \ --cc=gregkh-hQyY1W1yCW8ekmWlsbkhG0B+6BGkLq7r@public.gmane.org \ --cc=grygorii.strashko-l0cyMroinI0@public.gmane.org \ --cc=hch-jcswGhMUV9g@public.gmane.org \ --cc=linux-acpi-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \ --cc=linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org \ --cc=m.szyprowski-Sze3O3UU22JBDgjK7y7TUQ@public.gmane.org \ --cc=robh+dt-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org \ --cc=robin.murphy-5wv7dgnIgG8@public.gmane.org \ --cc=sudeep.holla-5wv7dgnIgG8@public.gmane.org \ --cc=x86-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.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: 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.