All of lore.kernel.org
 help / color / mirror / Atom feed
From: Rob Herring <robh+dt@kernel.org>
To: Jim Quinlan <james.quinlan@broadcom.com>
Cc: Rich Felker <dalias@libc.org>,
	"open list:SUPERH" <linux-sh@vger.kernel.org>,
	David Airlie <airlied@linux.ie>, PCI <linux-pci@vger.kernel.org>,
	Hanjun Guo <guohanjun@huawei.com>,
	"open list:REMOTE PROCESSOR \(REMOTEPROC\) SUBSYSTEM"
	<linux-remoteproc@vger.kernel.org>,
	Andy Shevchenko <andriy.shevchenko@linux.intel.com>,
	Bjorn Andersson <bjorn.andersson@linaro.org>,
	Julien Grall <julien.grall@arm.com>,
	Heikki Krogerus <heikki.krogerus@linux.intel.com>,
	"H. Peter Anvin" <hpa@zytor.com>, Will Deacon <will@kernel.org>,
	Christoph Hellwig <hch@lst.de>,
	Marek Szyprowski <m.szyprowski@samsung.com>,
	"open list:STAGING SUBSYSTEM" <devel@driverdev.osuosl.org>,
	Jean-Philippe Brucker <jean-philippe@linaro.org>,
	Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>,
	Yoshinori Sato <ysato@users.sourceforge.jp>,
	Frank Rowand <frowand.list@gmail.com>,
	Joerg Roedel <joro@8bytes.org>,
	"maintainer:X86 ARCHITECTURE \(32-BIT AND 64-BIT\)"
	<x86@kernel.org>, Russell King <linux@armlinux.org.uk>,
	"open list:ACPI FOR ARM64 \(ACPI/arm64\)"
	<linux-acpi@vger.kernel.org>, Chen-Yu Tsai <wens@csie.org>,
	Ingo Molnar <mingo@redhat.com>,
	"maintainer:BROADCOM BCM7XXX ARM ARCHITECTURE"
	<bcm-kernel-feedback-list@broadcom.com>,
	Alan Stern <stern@rowland.harvard.edu>,
	Len Brown <lenb@kernel.org>, Ohad Ben-Cohen <ohad@wizery.com>,
	"open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE"
	<devicetree@vger.kernel.org>,
	Philipp Zabel <p.zabel@pengutronix.de>,
	Arnd Bergmann <arnd@arndb.de>,
	Suzuki K Poulose <suzuki.poulose@arm.com>,
	Maxime Ripard <mripard@kernel.org>,
	Florian Fainelli <f.fainelli@gmail.com>,
	Borislav Petkov <bp@alien8.de>,
	"open list:DRM DRIVERS FOR ALLWINNER A10"
	<dri-devel@lists.freedesktop.org>,
	Yong Deng <yong.deng@magewell.com>,
	Santosh Shilimkar <ssantosh@kernel.org>,
	Bjorn Helgaas <bhelgaas@google.com>,
	Thomas Gleixner <tglx@linutronix.de>,
	Mauro Carvalho Chehab <mchehab@kernel.org>,
	"moderated list:ARM PORT" <linux-arm-kernel@lists.infradead.org>,
	Saravana Kannan <saravanak@google.com>,
	Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
	Oliver Neukum <oneukum@suse.com>,
	"Rafael J. Wysocki" <rjw@rjwysocki.net>,
	open list <linux-kernel@vger.kernel.org>,
	Paul Kocialkowski <paul.kocialkowski@bootlin.com>,
	"open list:IOMMU DRIVERS" <iommu@lists.linux-foundation.org>,
	"open list:USB SUBSYSTEM" <linux-usb@vger.kernel.org>,
	Stefano Stabellini <sstabellini@kernel.org>,
	Daniel Vetter <daniel@ffwll.ch>,
	Sudeep Holla <sudeep.holla@arm.com>,
	"open list:ALLWINNER A10 CSI DRIVER"
	<linux-media@vger.kernel.org>,
	Robin Murphy <robin.murphy@arm.com>,
	Nicolas Saenz Julienne <nsaenzjulienne@suse.de>,
	"moderated list:BROADCOM BCM2711/BCM2835 ARM ARCHITECTURE"
	<linux-rpi-kernel@lists.infradead.org>
Subject: Re: [PATCH v9 08/12] device core: Introduce DMA range map, supplanting dma_pfn_offset
Date: Tue, 28 Jul 2020 09:04:59 -0600	[thread overview]
Message-ID: <CAL_Jsq+9QE_uz+81O-Bm3xycSrJptx0xmwpPdP3x65KG00ugDQ@mail.gmail.com> (raw)
In-Reply-To: <20200724203407.16972-9-james.quinlan@broadcom.com>

On Fri, Jul 24, 2020 at 2:45 PM Jim Quinlan <james.quinlan@broadcom.com> wrote:
>
> The new field 'dma_range_map' in struct device is used to facilitate the
> use of single or multiple offsets between mapping regions of cpu addrs and
> dma addrs.  It subsumes the role of "dev->dma_pfn_offset" which was only
> capable of holding a single uniform offset and had no region bounds
> checking.
>
> The function of_dma_get_range() has been modified so that it takes a single
> argument -- the device node -- and returns a map, NULL, or an error code.
> The map is an array that holds the information regarding the DMA regions.
> Each range entry contains the address offset, the cpu_start address, the
> dma_start address, and the size of the region.
>
> of_dma_configure() is the typical manner to set range offsets but there are
> a number of ad hoc assignments to "dev->dma_pfn_offset" in the kernel
> driver code.  These cases now invoke the function
> dma_attach_offset_range(dev, cpu_addr, dma_addr, size).
>
> Signed-off-by: Jim Quinlan <james.quinlan@broadcom.com>
> ---

[...]

> diff --git a/drivers/of/address.c b/drivers/of/address.c
> index 8eea3f6e29a4..4b718d199efe 100644
> --- a/drivers/of/address.c
> +++ b/drivers/of/address.c
> @@ -918,33 +918,33 @@ void __iomem *of_io_request_and_map(struct device_node *np, int index,
>  }
>  EXPORT_SYMBOL(of_io_request_and_map);
>
> +#ifdef CONFIG_HAS_DMA
>  /**
> - * of_dma_get_range - Get DMA range info
> + * of_dma_get_range - Get DMA range info and put it into a map array
>   * @np:                device node to get DMA range info
> - * @dma_addr:  pointer to store initial DMA address of DMA range
> - * @paddr:     pointer to store initial CPU address of DMA range
> - * @size:      pointer to store size of DMA range
> + * @map:       dma range structure to return
>   *
>   * Look in bottom up direction for the first "dma-ranges" property
> - * and parse it.
> - *  dma-ranges format:
> + * and parse it.  Put the information into a DMA offset map array.
> + *
> + * dma-ranges format:
>   *     DMA addr (dma_addr)     : naddr cells
>   *     CPU addr (phys_addr_t)  : pna cells
>   *     size                    : nsize cells
>   *
> - * It returns -ENODEV if "dma-ranges" property was not found
> - * for this device in DT.
> + * It returns -ENODEV if "dma-ranges" property was not found for this
> + * device in the DT.
>   */
> -int of_dma_get_range(struct device_node *np, u64 *dma_addr, u64 *paddr, u64 *size)
> +int of_dma_get_range(struct device_node *np, const struct bus_dma_region **map)
>  {
>         struct device_node *node = of_node_get(np);
>         const __be32 *ranges = NULL;
> -       int len;
> -       int ret = 0;
>         bool found_dma_ranges = false;
>         struct of_range_parser parser;
>         struct of_range range;
> -       u64 dma_start = U64_MAX, dma_end = 0, dma_offset = 0;
> +       struct bus_dma_region *r;
> +       int len, num_ranges = 0;
> +       int ret;
>
>         while (node) {
>                 ranges = of_get_property(node, "dma-ranges", &len);
> @@ -970,44 +970,35 @@ int of_dma_get_range(struct device_node *np, u64 *dma_addr, u64 *paddr, u64 *siz
>         }
>
>         of_dma_range_parser_init(&parser, node);
> +       for_each_of_range(&parser, &range)
> +               num_ranges++;
> +
> +       of_dma_range_parser_init(&parser, node);
> +
> +       ret = -ENOMEM;
> +       r = kcalloc(num_ranges + 1, sizeof(*r), GFP_KERNEL);
> +       if (!r)
> +               goto out;

AFAICT, you have the error cases covered, but you are leaking memory
if the device is removed.

[...]

> diff --git a/drivers/remoteproc/remoteproc_core.c b/drivers/remoteproc/remoteproc_core.c
> index 9f04c30c4aaf..49242dd6176e 100644
> --- a/drivers/remoteproc/remoteproc_core.c
> +++ b/drivers/remoteproc/remoteproc_core.c
> @@ -519,7 +519,7 @@ static int rproc_handle_vdev(struct rproc *rproc, struct fw_rsc_vdev *rsc,
>         /* Initialise vdev subdevice */
>         snprintf(name, sizeof(name), "vdev%dbuffer", rvdev->index);
>         rvdev->dev.parent = &rproc->dev;
> -       rvdev->dev.dma_pfn_offset = rproc->dev.parent->dma_pfn_offset;
> +       rvdev->dev.dma_range_map = rproc->dev.parent->dma_range_map;

But doing this means you can't just free the dma_range_map. You need
to do a copy here or you'd have to refcount it. Or I suppose you could
check if it the child has a different dma_range_map ptr than the
parent.

Rob
_______________________________________________
devel mailing list
devel@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

WARNING: multiple messages have this Message-ID (diff)
From: Rob Herring <robh+dt@kernel.org>
To: Jim Quinlan <james.quinlan@broadcom.com>
Cc: Rich Felker <dalias@libc.org>,
	"open list:SUPERH" <linux-sh@vger.kernel.org>,
	David Airlie <airlied@linux.ie>, PCI <linux-pci@vger.kernel.org>,
	Hanjun Guo <guohanjun@huawei.com>,
	"open list:REMOTE PROCESSOR \(REMOTEPROC\) SUBSYSTEM"
	<linux-remoteproc@vger.kernel.org>,
	Andy Shevchenko <andriy.shevchenko@linux.intel.com>,
	Julien Grall <julien.grall@arm.com>,
	Heikki Krogerus <heikki.krogerus@linux.intel.com>,
	"H. Peter Anvin" <hpa@zytor.com>, Will Deacon <will@kernel.org>,
	Christoph Hellwig <hch@lst.de>,
	"open list:STAGING SUBSYSTEM" <devel@driverdev.osuosl.org>,
	Jean-Philippe Brucker <jean-philippe@linaro.org>,
	Yoshinori Sato <ysato@users.sourceforge.jp>,
	Frank Rowand <frowand.list@gmail.com>,
	"maintainer:X86 ARCHITECTURE \(32-BIT AND 64-BIT\)"
	<x86@kernel.org>, Russell King <linux@armlinux.org.uk>,
	"open list:ACPI FOR ARM64 \(ACPI/arm64\)"
	<linux-acpi@vger.kernel.org>, Chen-Yu Tsai <wens@csie.org>,
	Ingo Molnar <mingo@redhat.com>,
	"maintainer:BROADCOM BCM7XXX ARM ARCHITECTURE"
	<bcm-kernel-feedback-list@broadcom.com>,
	Alan Stern <stern@rowland.harvard.edu>,
	Len Brown <lenb@kernel.org>, Ohad Ben-Cohen <ohad@wizery.com>,
	"open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE"
	<devicetree@vger.kernel.org>,
	Philipp Zabel <p.zabel@pengutronix.de>,
	Arnd Bergmann <arnd@arndb.de>,
	Suzuki K Poulose <suzuki.poulose@arm.com>,
	Maxime Ripard <mripard@kernel.org>,
	Florian Fainelli <f.fainelli@gmail.com>,
	Borislav Petkov <bp@alien8.de>,
	"open list:DRM DRIVERS FOR ALLWINNER A10"
	<dri-devel@lists.freedesktop.org>,
	Yong Deng <yong.deng@magewell.com>,
	Santosh Shilimkar <ssantosh@kernel.org>,
	Bjorn Helgaas <bhelgaas@google.com>,
	Thomas Gleixner <tglx@linutronix.de>,
	Mauro Carvalho Chehab <mchehab@kernel.org>,
	"moderated list:ARM PORT" <linux-arm-kernel@lists.infradead.org>,
	Saravana Kannan <saravanak@google.com>,
	Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
	Oliver Neukum <oneukum@suse.com>,
	"Rafael J. Wysocki" <rjw@rjwysocki.net>,
	open list <linux-kernel@vger.kernel.org>,
	Paul Kocialkowski <paul.kocialkowski@bootlin.com>,
	"open list:IOMMU DRIVERS" <iommu@lists.linux-foundation.org>,
	"open list:USB SUBSYSTEM" <linux-usb@vger.kernel.org>,
	Stefano Stabellini <sstabellini@kernel.org>,
	Daniel Vetter <daniel@ffwll.ch>,
	Sudeep Holla <sudeep.holla@arm.com>,
	"open list:ALLWINNER A10 CSI DRIVER"
	<linux-media@vger.kernel.org>,
	Robin Murphy <robin.murphy@arm.com>,
	"moderated list:BROADCOM BCM2711/BCM2835 ARM ARCHITECTURE"
	<linux-rpi-kernel@lists.infradead.org>
Subject: Re: [PATCH v9 08/12] device core: Introduce DMA range map, supplanting dma_pfn_offset
Date: Tue, 28 Jul 2020 09:04:59 -0600	[thread overview]
Message-ID: <CAL_Jsq+9QE_uz+81O-Bm3xycSrJptx0xmwpPdP3x65KG00ugDQ@mail.gmail.com> (raw)
In-Reply-To: <20200724203407.16972-9-james.quinlan@broadcom.com>

On Fri, Jul 24, 2020 at 2:45 PM Jim Quinlan <james.quinlan@broadcom.com> wrote:
>
> The new field 'dma_range_map' in struct device is used to facilitate the
> use of single or multiple offsets between mapping regions of cpu addrs and
> dma addrs.  It subsumes the role of "dev->dma_pfn_offset" which was only
> capable of holding a single uniform offset and had no region bounds
> checking.
>
> The function of_dma_get_range() has been modified so that it takes a single
> argument -- the device node -- and returns a map, NULL, or an error code.
> The map is an array that holds the information regarding the DMA regions.
> Each range entry contains the address offset, the cpu_start address, the
> dma_start address, and the size of the region.
>
> of_dma_configure() is the typical manner to set range offsets but there are
> a number of ad hoc assignments to "dev->dma_pfn_offset" in the kernel
> driver code.  These cases now invoke the function
> dma_attach_offset_range(dev, cpu_addr, dma_addr, size).
>
> Signed-off-by: Jim Quinlan <james.quinlan@broadcom.com>
> ---

[...]

> diff --git a/drivers/of/address.c b/drivers/of/address.c
> index 8eea3f6e29a4..4b718d199efe 100644
> --- a/drivers/of/address.c
> +++ b/drivers/of/address.c
> @@ -918,33 +918,33 @@ void __iomem *of_io_request_and_map(struct device_node *np, int index,
>  }
>  EXPORT_SYMBOL(of_io_request_and_map);
>
> +#ifdef CONFIG_HAS_DMA
>  /**
> - * of_dma_get_range - Get DMA range info
> + * of_dma_get_range - Get DMA range info and put it into a map array
>   * @np:                device node to get DMA range info
> - * @dma_addr:  pointer to store initial DMA address of DMA range
> - * @paddr:     pointer to store initial CPU address of DMA range
> - * @size:      pointer to store size of DMA range
> + * @map:       dma range structure to return
>   *
>   * Look in bottom up direction for the first "dma-ranges" property
> - * and parse it.
> - *  dma-ranges format:
> + * and parse it.  Put the information into a DMA offset map array.
> + *
> + * dma-ranges format:
>   *     DMA addr (dma_addr)     : naddr cells
>   *     CPU addr (phys_addr_t)  : pna cells
>   *     size                    : nsize cells
>   *
> - * It returns -ENODEV if "dma-ranges" property was not found
> - * for this device in DT.
> + * It returns -ENODEV if "dma-ranges" property was not found for this
> + * device in the DT.
>   */
> -int of_dma_get_range(struct device_node *np, u64 *dma_addr, u64 *paddr, u64 *size)
> +int of_dma_get_range(struct device_node *np, const struct bus_dma_region **map)
>  {
>         struct device_node *node = of_node_get(np);
>         const __be32 *ranges = NULL;
> -       int len;
> -       int ret = 0;
>         bool found_dma_ranges = false;
>         struct of_range_parser parser;
>         struct of_range range;
> -       u64 dma_start = U64_MAX, dma_end = 0, dma_offset = 0;
> +       struct bus_dma_region *r;
> +       int len, num_ranges = 0;
> +       int ret;
>
>         while (node) {
>                 ranges = of_get_property(node, "dma-ranges", &len);
> @@ -970,44 +970,35 @@ int of_dma_get_range(struct device_node *np, u64 *dma_addr, u64 *paddr, u64 *siz
>         }
>
>         of_dma_range_parser_init(&parser, node);
> +       for_each_of_range(&parser, &range)
> +               num_ranges++;
> +
> +       of_dma_range_parser_init(&parser, node);
> +
> +       ret = -ENOMEM;
> +       r = kcalloc(num_ranges + 1, sizeof(*r), GFP_KERNEL);
> +       if (!r)
> +               goto out;

AFAICT, you have the error cases covered, but you are leaking memory
if the device is removed.

[...]

> diff --git a/drivers/remoteproc/remoteproc_core.c b/drivers/remoteproc/remoteproc_core.c
> index 9f04c30c4aaf..49242dd6176e 100644
> --- a/drivers/remoteproc/remoteproc_core.c
> +++ b/drivers/remoteproc/remoteproc_core.c
> @@ -519,7 +519,7 @@ static int rproc_handle_vdev(struct rproc *rproc, struct fw_rsc_vdev *rsc,
>         /* Initialise vdev subdevice */
>         snprintf(name, sizeof(name), "vdev%dbuffer", rvdev->index);
>         rvdev->dev.parent = &rproc->dev;
> -       rvdev->dev.dma_pfn_offset = rproc->dev.parent->dma_pfn_offset;
> +       rvdev->dev.dma_range_map = rproc->dev.parent->dma_range_map;

But doing this means you can't just free the dma_range_map. You need
to do a copy here or you'd have to refcount it. Or I suppose you could
check if it the child has a different dma_range_map ptr than the
parent.

Rob
_______________________________________________
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu

WARNING: multiple messages have this Message-ID (diff)
From: Rob Herring <robh+dt@kernel.org>
To: Jim Quinlan <james.quinlan@broadcom.com>
Cc: Rich Felker <dalias@libc.org>,
	"open list:SUPERH" <linux-sh@vger.kernel.org>,
	David Airlie <airlied@linux.ie>, PCI <linux-pci@vger.kernel.org>,
	Hanjun Guo <guohanjun@huawei.com>,
	"open list:REMOTE PROCESSOR \(REMOTEPROC\) SUBSYSTEM"
	<linux-remoteproc@vger.kernel.org>,
	Andy Shevchenko <andriy.shevchenko@linux.intel.com>,
	Bjorn Andersson <bjorn.andersson@linaro.org>,
	Julien Grall <julien.grall@arm.com>,
	Heikki Krogerus <heikki.krogerus@linux.intel.com>,
	"H. Peter Anvin" <hpa@zytor.com>, Will Deacon <will@kernel.org>,
	Christoph Hellwig <hch@lst.de>,
	Marek Szyprowski <m.szyprowski@samsung.com>,
	"open list:STAGING SUBSYSTEM" <devel@driverdev.osuosl.org>,
	Jean-Philippe Brucker <jean-philippe@linaro.org>,
	Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>,
	Yoshinori Sato <ysato@users.sourceforge.jp>,
	Frank Rowand <frowand.list@gmail.com>,
	Joerg Roedel <joro@8bytes.org>,
	"maintainer:X86 ARCHITECTURE \(32-BIT AND 64-BIT\)"
	<x86@kernel.org>, Russell King <linux@armlinux.org.uk>,
	"open list:ACPI FOR ARM64 \(ACPI/arm64\)"
	<linux-acpi@vger.kernel.org>, Chen-Yu Tsai <wens@csie.org>,
	Ingo Molnar <mingo@redhat.com>,
	"maintainer:BROADCOM BCM7XXX ARM ARCHITECTURE"
	<bcm-kernel-feedback-list@broadcom.com>,
	Alan Stern <stern@rowland.harvard.edu>,
	Len Brown <lenb@kernel.org>, Ohad Ben-Cohen <ohad@wizery.com>,
	"open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE"
	<devicetree@vger.kernel.org>, Arnd Bergmann <arnd@arndb.de>,
	Suzuki K Poulose <suzuki.poulose@arm.com>,
	Florian Fainelli <f.fainelli@gmail.com>,
	Borislav Petkov <bp@alien8.de>,
	"open list:DRM DRIVERS FOR ALLWINNER A10"
	<dri-devel@lists.freedesktop.org>,
	Yong Deng <yong.deng@magewell.com>,
	Santosh Shilimkar <ssantosh@kernel.org>,
	Bjorn Helgaas <bhelgaas@google.com>,
	Thomas Gleixner <tglx@linutronix.de>,
	Mauro Carvalho Chehab <mchehab@kernel.org>,
	"moderated list:ARM PORT" <linux-arm-kernel@lists.infradead.org>,
	Saravana Kannan <saravanak@google.com>,
	Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
	Oliver Neukum <oneukum@suse.com>,
	"Rafael J. Wysocki" <rjw@rjwysocki.net>,
	open list <linux-kernel@vger.kernel.org>,
	Paul Kocialkowski <paul.kocialkowski@bootlin.com>,
	"open list:IOMMU DRIVERS" <iommu@lists.linux-foundation.org>,
	"open list:USB SUBSYSTEM" <linux-usb@vger.kernel.org>,
	Stefano Stabellini <sstabellini@kernel.org>,
	Sudeep Holla <sudeep.holla@arm.com>,
	"open list:ALLWINNER A10 CSI DRIVER"
	<linux-media@vger.kernel.org>,
	Robin Murphy <robin.murphy@arm.com>,
	Nicolas Saenz Julienne <nsaenzjulienne@suse.de>,
	"moderated list:BROADCOM BCM2711/BCM2835 ARM ARCHITECTURE"
	<linux-rpi-kernel@lists.infradead.org>
Subject: Re: [PATCH v9 08/12] device core: Introduce DMA range map, supplanting dma_pfn_offset
Date: Tue, 28 Jul 2020 09:04:59 -0600	[thread overview]
Message-ID: <CAL_Jsq+9QE_uz+81O-Bm3xycSrJptx0xmwpPdP3x65KG00ugDQ@mail.gmail.com> (raw)
In-Reply-To: <20200724203407.16972-9-james.quinlan@broadcom.com>

On Fri, Jul 24, 2020 at 2:45 PM Jim Quinlan <james.quinlan@broadcom.com> wrote:
>
> The new field 'dma_range_map' in struct device is used to facilitate the
> use of single or multiple offsets between mapping regions of cpu addrs and
> dma addrs.  It subsumes the role of "dev->dma_pfn_offset" which was only
> capable of holding a single uniform offset and had no region bounds
> checking.
>
> The function of_dma_get_range() has been modified so that it takes a single
> argument -- the device node -- and returns a map, NULL, or an error code.
> The map is an array that holds the information regarding the DMA regions.
> Each range entry contains the address offset, the cpu_start address, the
> dma_start address, and the size of the region.
>
> of_dma_configure() is the typical manner to set range offsets but there are
> a number of ad hoc assignments to "dev->dma_pfn_offset" in the kernel
> driver code.  These cases now invoke the function
> dma_attach_offset_range(dev, cpu_addr, dma_addr, size).
>
> Signed-off-by: Jim Quinlan <james.quinlan@broadcom.com>
> ---

[...]

> diff --git a/drivers/of/address.c b/drivers/of/address.c
> index 8eea3f6e29a4..4b718d199efe 100644
> --- a/drivers/of/address.c
> +++ b/drivers/of/address.c
> @@ -918,33 +918,33 @@ void __iomem *of_io_request_and_map(struct device_node *np, int index,
>  }
>  EXPORT_SYMBOL(of_io_request_and_map);
>
> +#ifdef CONFIG_HAS_DMA
>  /**
> - * of_dma_get_range - Get DMA range info
> + * of_dma_get_range - Get DMA range info and put it into a map array
>   * @np:                device node to get DMA range info
> - * @dma_addr:  pointer to store initial DMA address of DMA range
> - * @paddr:     pointer to store initial CPU address of DMA range
> - * @size:      pointer to store size of DMA range
> + * @map:       dma range structure to return
>   *
>   * Look in bottom up direction for the first "dma-ranges" property
> - * and parse it.
> - *  dma-ranges format:
> + * and parse it.  Put the information into a DMA offset map array.
> + *
> + * dma-ranges format:
>   *     DMA addr (dma_addr)     : naddr cells
>   *     CPU addr (phys_addr_t)  : pna cells
>   *     size                    : nsize cells
>   *
> - * It returns -ENODEV if "dma-ranges" property was not found
> - * for this device in DT.
> + * It returns -ENODEV if "dma-ranges" property was not found for this
> + * device in the DT.
>   */
> -int of_dma_get_range(struct device_node *np, u64 *dma_addr, u64 *paddr, u64 *size)
> +int of_dma_get_range(struct device_node *np, const struct bus_dma_region **map)
>  {
>         struct device_node *node = of_node_get(np);
>         const __be32 *ranges = NULL;
> -       int len;
> -       int ret = 0;
>         bool found_dma_ranges = false;
>         struct of_range_parser parser;
>         struct of_range range;
> -       u64 dma_start = U64_MAX, dma_end = 0, dma_offset = 0;
> +       struct bus_dma_region *r;
> +       int len, num_ranges = 0;
> +       int ret;
>
>         while (node) {
>                 ranges = of_get_property(node, "dma-ranges", &len);
> @@ -970,44 +970,35 @@ int of_dma_get_range(struct device_node *np, u64 *dma_addr, u64 *paddr, u64 *siz
>         }
>
>         of_dma_range_parser_init(&parser, node);
> +       for_each_of_range(&parser, &range)
> +               num_ranges++;
> +
> +       of_dma_range_parser_init(&parser, node);
> +
> +       ret = -ENOMEM;
> +       r = kcalloc(num_ranges + 1, sizeof(*r), GFP_KERNEL);
> +       if (!r)
> +               goto out;

AFAICT, you have the error cases covered, but you are leaking memory
if the device is removed.

[...]

> diff --git a/drivers/remoteproc/remoteproc_core.c b/drivers/remoteproc/remoteproc_core.c
> index 9f04c30c4aaf..49242dd6176e 100644
> --- a/drivers/remoteproc/remoteproc_core.c
> +++ b/drivers/remoteproc/remoteproc_core.c
> @@ -519,7 +519,7 @@ static int rproc_handle_vdev(struct rproc *rproc, struct fw_rsc_vdev *rsc,
>         /* Initialise vdev subdevice */
>         snprintf(name, sizeof(name), "vdev%dbuffer", rvdev->index);
>         rvdev->dev.parent = &rproc->dev;
> -       rvdev->dev.dma_pfn_offset = rproc->dev.parent->dma_pfn_offset;
> +       rvdev->dev.dma_range_map = rproc->dev.parent->dma_range_map;

But doing this means you can't just free the dma_range_map. You need
to do a copy here or you'd have to refcount it. Or I suppose you could
check if it the child has a different dma_range_map ptr than the
parent.

Rob
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

  parent reply	other threads:[~2020-07-28 15:05 UTC|newest]

Thread overview: 79+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-07-24 20:33 [PATCH v9 00/12] PCI: brcmstb: enable PCIe for STB chips Jim Quinlan
2020-07-24 20:33 ` Jim Quinlan
2020-07-24 20:33 ` Jim Quinlan
2020-07-24 20:33 ` Jim Quinlan via iommu
2020-07-24 20:33 ` Jim Quinlan
2020-07-24 20:33 ` Jim Quinlan
2020-07-24 20:33 ` [PATCH v9 01/12] PCI: brcmstb: PCIE_BRCMSTB depends on ARCH_BRCMSTB Jim Quinlan
2020-07-24 20:33 ` [PATCH v9 02/12] ata: ahci_brcm: Fix use of BCM7216 reset controller Jim Quinlan
2020-07-24 21:02   ` Florian Fainelli
2020-07-25  9:18   ` Sergei Shtylyov
2020-07-27  6:58   ` Philipp Zabel
2020-07-24 20:33 ` [PATCH v9 03/12] dt-bindings: PCI: Add bindings for more Brcmstb chips Jim Quinlan
2020-07-24 20:33   ` Jim Quinlan
2020-07-24 20:33 ` [PATCH v9 04/12] PCI: brcmstb: Add bcm7278 register info Jim Quinlan
2020-07-24 20:33   ` Jim Quinlan
2020-07-24 20:33 ` [PATCH v9 05/12] PCI: brcmstb: Add suspend and resume pm_ops Jim Quinlan
2020-07-24 20:33   ` Jim Quinlan
2020-07-24 20:33 ` [PATCH v9 06/12] PCI: brcmstb: Add bcm7278 PERST# support Jim Quinlan
2020-07-24 20:33   ` Jim Quinlan
2020-07-24 20:33 ` [PATCH v9 07/12] PCI: brcmstb: Add control of rescal reset Jim Quinlan
2020-07-24 20:33   ` Jim Quinlan
2020-07-24 20:33 ` [PATCH v9 08/12] device core: Introduce DMA range map, supplanting dma_pfn_offset Jim Quinlan
2020-07-24 20:33   ` Jim Quinlan
2020-07-24 20:33   ` Jim Quinlan via iommu
2020-07-28 12:33   ` Christoph Hellwig
2020-07-28 12:33     ` Christoph Hellwig
2020-07-28 18:36     ` Jim Quinlan
2020-07-28 18:36       ` Jim Quinlan
2020-07-28 18:36       ` Jim Quinlan via iommu
2020-07-28 15:04   ` Rob Herring [this message]
2020-07-28 15:04     ` Rob Herring
2020-07-28 15:04     ` Rob Herring
2020-07-28 18:24     ` Jim Quinlan
2020-07-28 18:24       ` Jim Quinlan
2020-07-28 18:24       ` Jim Quinlan via iommu
2020-07-29  6:19       ` Christoph Hellwig
2020-07-29  6:19         ` Christoph Hellwig
2020-07-29 14:26         ` Jim Quinlan
2020-07-29 14:26           ` Jim Quinlan
2020-07-29 14:26           ` Jim Quinlan via iommu
2020-07-29 14:27         ` Rob Herring
2020-07-29 14:27           ` Rob Herring
2020-07-29 14:27           ` Rob Herring
2020-07-30 16:44           ` Jim Quinlan
2020-07-30 16:44             ` Jim Quinlan
2020-07-30 16:44             ` Jim Quinlan via iommu
2020-07-30 17:02             ` Nicolas Saenz Julienne
2020-07-30 17:02               ` Nicolas Saenz Julienne
2020-07-30 17:02               ` Nicolas Saenz Julienne
2020-07-31 14:23             ` Rob Herring
2020-07-31 14:23               ` Rob Herring
2020-07-31 14:23               ` Rob Herring
2020-07-30 17:05   ` Nicolas Saenz Julienne
2020-07-30 17:05     ` Nicolas Saenz Julienne
2020-07-30 17:05     ` Nicolas Saenz Julienne
2020-07-30 17:25     ` Jim Quinlan
2020-07-30 17:25       ` Jim Quinlan
2020-07-30 17:25       ` Jim Quinlan via iommu
2020-07-30 17:29       ` Nicolas Saenz Julienne
2020-07-30 17:29         ` Nicolas Saenz Julienne
2020-07-30 17:29         ` Nicolas Saenz Julienne
2020-08-01 17:17   ` Nicolas Saenz Julienne
2020-08-01 17:17     ` Nicolas Saenz Julienne
2020-08-01 17:17     ` Nicolas Saenz Julienne
2020-08-03 12:49     ` Jim Quinlan
2020-08-03 12:49       ` Jim Quinlan
2020-08-03 12:49       ` Jim Quinlan via iommu
2020-07-24 20:33 ` [PATCH v9 09/12] PCI: brcmstb: Set additional internal memory DMA viewport sizes Jim Quinlan
2020-07-24 20:33   ` Jim Quinlan
2020-08-01 17:39   ` Nicolas Saenz Julienne
2020-08-01 17:39     ` Nicolas Saenz Julienne
2020-08-03 12:40     ` Jim Quinlan
2020-08-03 12:40       ` Jim Quinlan
2020-07-24 20:33 ` [PATCH v9 10/12] PCI: brcmstb: Accommodate MSI for older chips Jim Quinlan
2020-07-24 20:33   ` Jim Quinlan
2020-07-24 20:33 ` [PATCH v9 11/12] PCI: brcmstb: Set bus max burst size by chip type Jim Quinlan
2020-07-24 20:33   ` Jim Quinlan
2020-07-24 20:33 ` [PATCH v9 12/12] PCI: brcmstb: Add bcm7211, bcm7216, bcm7445, bcm7278 to match list Jim Quinlan
2020-07-24 20:33   ` Jim Quinlan

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=CAL_Jsq+9QE_uz+81O-Bm3xycSrJptx0xmwpPdP3x65KG00ugDQ@mail.gmail.com \
    --to=robh+dt@kernel.org \
    --cc=airlied@linux.ie \
    --cc=andriy.shevchenko@linux.intel.com \
    --cc=arnd@arndb.de \
    --cc=bcm-kernel-feedback-list@broadcom.com \
    --cc=bhelgaas@google.com \
    --cc=bjorn.andersson@linaro.org \
    --cc=bp@alien8.de \
    --cc=dalias@libc.org \
    --cc=daniel@ffwll.ch \
    --cc=devel@driverdev.osuosl.org \
    --cc=devicetree@vger.kernel.org \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=f.fainelli@gmail.com \
    --cc=frowand.list@gmail.com \
    --cc=gregkh@linuxfoundation.org \
    --cc=guohanjun@huawei.com \
    --cc=hch@lst.de \
    --cc=heikki.krogerus@linux.intel.com \
    --cc=hpa@zytor.com \
    --cc=iommu@lists.linux-foundation.org \
    --cc=james.quinlan@broadcom.com \
    --cc=jean-philippe@linaro.org \
    --cc=joro@8bytes.org \
    --cc=julien.grall@arm.com \
    --cc=lenb@kernel.org \
    --cc=linux-acpi@vger.kernel.org \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-media@vger.kernel.org \
    --cc=linux-pci@vger.kernel.org \
    --cc=linux-remoteproc@vger.kernel.org \
    --cc=linux-rpi-kernel@lists.infradead.org \
    --cc=linux-sh@vger.kernel.org \
    --cc=linux-usb@vger.kernel.org \
    --cc=linux@armlinux.org.uk \
    --cc=lorenzo.pieralisi@arm.com \
    --cc=m.szyprowski@samsung.com \
    --cc=mchehab@kernel.org \
    --cc=mingo@redhat.com \
    --cc=mripard@kernel.org \
    --cc=nsaenzjulienne@suse.de \
    --cc=ohad@wizery.com \
    --cc=oneukum@suse.com \
    --cc=p.zabel@pengutronix.de \
    --cc=paul.kocialkowski@bootlin.com \
    --cc=rjw@rjwysocki.net \
    --cc=robin.murphy@arm.com \
    --cc=saravanak@google.com \
    --cc=ssantosh@kernel.org \
    --cc=sstabellini@kernel.org \
    --cc=stern@rowland.harvard.edu \
    --cc=sudeep.holla@arm.com \
    --cc=suzuki.poulose@arm.com \
    --cc=tglx@linutronix.de \
    --cc=wens@csie.org \
    --cc=will@kernel.org \
    --cc=x86@kernel.org \
    --cc=yong.deng@magewell.com \
    --cc=ysato@users.sourceforge.jp \
    /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.