From: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
To: Jim Quinlan <james.quinlan@broadcom.com>
Cc: "open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE"
<devicetree@vger.kernel.org>,
Heikki Krogerus <heikki.krogerus@linux.intel.com>,
Saravana Kannan <saravanak@google.com>,
Suzuki K Poulose <suzuki.poulose@arm.com>,
Frank Rowand <frowand.list@gmail.com>,
"Rafael J. Wysocki" <rafael.j.wysocki@intel.com>,
open list <linux-kernel@vger.kernel.org>,
"open list:DMA MAPPING HELPERS"
<iommu@lists.linux-foundation.org>,
Rob Herring <robh+dt@kernel.org>,
Dan Williams <dan.j.williams@intel.com>,
Robin Murphy <robin.murphy@arm.com>,
Christoph Hellwig <hch@lst.de>,
Nicolas Saenz Julienne <nsaenzjulienne@suse.de>
Subject: Re: [PATCH 09/15] device core: Add ability to handle multiple dma offsets
Date: Wed, 20 May 2020 16:03:20 +0200 [thread overview]
Message-ID: <20200520140320.GA3624154@kroah.com> (raw)
In-Reply-To: <CA+-6iNyQFauYc0ZNbzRmao_oOZD8XM+1D0XE133HP_-zgMLzuA@mail.gmail.com>
On Wed, May 20, 2020 at 09:50:36AM -0400, Jim Quinlan wrote:
> On Wed, May 20, 2020 at 1:43 AM Greg Kroah-Hartman
> <gregkh@linuxfoundation.org> wrote:
> >
> > On Tue, May 19, 2020 at 04:34:07PM -0400, Jim Quinlan wrote:
> > > diff --git a/include/linux/device.h b/include/linux/device.h
> > > index ac8e37cd716a..6cd916860b5f 100644
> > > --- a/include/linux/device.h
> > > +++ b/include/linux/device.h
> > > @@ -493,6 +493,8 @@ struct dev_links_info {
> > > * @bus_dma_limit: Limit of an upstream bridge or bus which imposes a smaller
> > > * DMA limit than the device itself supports.
> > > * @dma_pfn_offset: offset of DMA memory range relatively of RAM
> > > + * @dma_map: Like dma_pfn_offset but used when there are multiple
> > > + * pfn offsets for multiple dma-ranges.
> > > * @dma_parms: A low level driver may set these to teach IOMMU code about
> > > * segment limitations.
> > > * @dma_pools: Dma pools (if dma'ble device).
> > > @@ -578,7 +580,12 @@ struct device {
> > > allocations such descriptors. */
> > > u64 bus_dma_limit; /* upstream dma constraint */
> > > unsigned long dma_pfn_offset;
> > > -
> > > +#ifdef CONFIG_DMA_PFN_OFFSET_MAP
> > > + const void *dma_offset_map; /* Like dma_pfn_offset, but for
> > > + * the unlikely case of multiple
> > > + * offsets. If non-null, dma_pfn_offset
> > > + * will be 0. */
> > > +#endif
> > > struct device_dma_parameters *dma_parms;
> > >
> > > struct list_head dma_pools; /* dma pools (if dma'ble) */
> >
> > I'll defer to Christoph here, but I thought we were trying to get rid of
> > stuff like this from struct device, not add new things to it for dma
> Hi Greg,
>
> I wasn't aware of this policy. I put it in 'struct device' because
> just like the existing dma_pfn_offset; it seemed to be the only way to
> pull this off. I'll certainly follow any ideas on alternative
> strategies from Christoph et al.
>
> > apis. And why is it a void *?
> Just wanted to minimize the number of lines I've added to device.h, no
> other reason.
How would using a real type make this more lines? Never use a void *
unless you have to, we want the compiler to check our errors for us :)
thanks,
greg k-h
_______________________________________________
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
WARNING: multiple messages have this Message-ID (diff)
From: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
To: Jim Quinlan <james.quinlan@broadcom.com>
Cc: Nicolas Saenz Julienne <nsaenzjulienne@suse.de>,
Rob Herring <robh+dt@kernel.org>,
Frank Rowand <frowand.list@gmail.com>,
Christoph Hellwig <hch@lst.de>,
Marek Szyprowski <m.szyprowski@samsung.com>,
Robin Murphy <robin.murphy@arm.com>,
Suzuki K Poulose <suzuki.poulose@arm.com>,
Saravana Kannan <saravanak@google.com>,
Heikki Krogerus <heikki.krogerus@linux.intel.com>,
"Rafael J. Wysocki" <rafael.j.wysocki@intel.com>,
Dan Williams <dan.j.williams@intel.com>,
"open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE"
<devicetree@vger.kernel.org>,
open list <linux-kernel@vger.kernel.org>,
"open list:DMA MAPPING HELPERS"
<iommu@lists.linux-foundation.org>
Subject: Re: [PATCH 09/15] device core: Add ability to handle multiple dma offsets
Date: Wed, 20 May 2020 16:03:20 +0200 [thread overview]
Message-ID: <20200520140320.GA3624154@kroah.com> (raw)
In-Reply-To: <CA+-6iNyQFauYc0ZNbzRmao_oOZD8XM+1D0XE133HP_-zgMLzuA@mail.gmail.com>
On Wed, May 20, 2020 at 09:50:36AM -0400, Jim Quinlan wrote:
> On Wed, May 20, 2020 at 1:43 AM Greg Kroah-Hartman
> <gregkh@linuxfoundation.org> wrote:
> >
> > On Tue, May 19, 2020 at 04:34:07PM -0400, Jim Quinlan wrote:
> > > diff --git a/include/linux/device.h b/include/linux/device.h
> > > index ac8e37cd716a..6cd916860b5f 100644
> > > --- a/include/linux/device.h
> > > +++ b/include/linux/device.h
> > > @@ -493,6 +493,8 @@ struct dev_links_info {
> > > * @bus_dma_limit: Limit of an upstream bridge or bus which imposes a smaller
> > > * DMA limit than the device itself supports.
> > > * @dma_pfn_offset: offset of DMA memory range relatively of RAM
> > > + * @dma_map: Like dma_pfn_offset but used when there are multiple
> > > + * pfn offsets for multiple dma-ranges.
> > > * @dma_parms: A low level driver may set these to teach IOMMU code about
> > > * segment limitations.
> > > * @dma_pools: Dma pools (if dma'ble device).
> > > @@ -578,7 +580,12 @@ struct device {
> > > allocations such descriptors. */
> > > u64 bus_dma_limit; /* upstream dma constraint */
> > > unsigned long dma_pfn_offset;
> > > -
> > > +#ifdef CONFIG_DMA_PFN_OFFSET_MAP
> > > + const void *dma_offset_map; /* Like dma_pfn_offset, but for
> > > + * the unlikely case of multiple
> > > + * offsets. If non-null, dma_pfn_offset
> > > + * will be 0. */
> > > +#endif
> > > struct device_dma_parameters *dma_parms;
> > >
> > > struct list_head dma_pools; /* dma pools (if dma'ble) */
> >
> > I'll defer to Christoph here, but I thought we were trying to get rid of
> > stuff like this from struct device, not add new things to it for dma
> Hi Greg,
>
> I wasn't aware of this policy. I put it in 'struct device' because
> just like the existing dma_pfn_offset; it seemed to be the only way to
> pull this off. I'll certainly follow any ideas on alternative
> strategies from Christoph et al.
>
> > apis. And why is it a void *?
> Just wanted to minimize the number of lines I've added to device.h, no
> other reason.
How would using a real type make this more lines? Never use a void *
unless you have to, we want the compiler to check our errors for us :)
thanks,
greg k-h
next prev parent reply other threads:[~2020-05-20 14:03 UTC|newest]
Thread overview: 74+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-05-19 20:33 [PATCH 00/15] PCI: brcmstb: enable PCIe for STB chips Jim Quinlan
2020-05-19 20:33 ` Jim Quinlan
2020-05-19 20:33 ` Jim Quinlan via iommu
2020-05-19 20:33 ` [PATCH 01/15] PCI: brcmstb: PCIE_BRCMSTB depends on ARCH_BRCMSTB Jim Quinlan
2020-05-19 20:48 ` Florian Fainelli
2020-05-19 20:34 ` [PATCH 02/15] ahci_brcm: fix use of BCM7216 reset controller Jim Quinlan
2020-05-20 7:14 ` Philipp Zabel
2020-05-19 20:34 ` [PATCH 03/15] dt-bindings: PCI: Add bindings for more Brcmstb chips Jim Quinlan
2020-05-19 20:34 ` Jim Quinlan
2020-05-19 20:34 ` [PATCH 04/15] PCI: brcmstb: Add compatibily of other chips Jim Quinlan
2020-05-19 20:34 ` Jim Quinlan
2020-05-20 11:51 ` Nicolas Saenz Julienne
2020-05-20 11:51 ` Nicolas Saenz Julienne
2020-05-20 14:30 ` Jim Quinlan
2020-05-20 14:30 ` Jim Quinlan
2020-05-20 14:41 ` Nicolas Saenz Julienne
2020-05-20 14:41 ` Nicolas Saenz Julienne
2020-05-21 19:35 ` Jim Quinlan
2020-05-21 19:35 ` Jim Quinlan
2020-05-22 9:17 ` Nicolas Saenz Julienne
2020-05-22 9:17 ` Nicolas Saenz Julienne
2020-05-19 20:34 ` [PATCH 05/15] PCI: brcmstb: Add suspend and resume pm_ops Jim Quinlan
2020-05-19 20:34 ` Jim Quinlan
2020-05-19 20:34 ` [PATCH 06/15] PCI: brcmstb: Asserting PERST is different for 7278 Jim Quinlan
2020-05-19 20:34 ` Jim Quinlan
2020-05-19 20:34 ` [PATCH 07/15] PCI: brcmstb: Add control of rescal reset Jim Quinlan
2020-05-19 20:34 ` Jim Quinlan
2020-05-20 7:27 ` Philipp Zabel
2020-05-20 7:27 ` Philipp Zabel
2020-05-21 21:48 ` Jim Quinlan
2020-05-21 21:48 ` Jim Quinlan
2020-05-25 16:58 ` Florian Fainelli
2020-05-25 16:58 ` Florian Fainelli
2020-05-19 20:34 ` [PATCH 08/15] of: Include a dev param in of_dma_get_range() Jim Quinlan
2020-05-19 20:34 ` [PATCH 09/15] device core: Add ability to handle multiple dma offsets Jim Quinlan via iommu
2020-05-19 20:34 ` Jim Quinlan
2020-05-20 5:43 ` Greg Kroah-Hartman
2020-05-20 5:43 ` Greg Kroah-Hartman
2020-05-20 13:50 ` Jim Quinlan via iommu
2020-05-20 13:50 ` Jim Quinlan
2020-05-20 14:03 ` Greg Kroah-Hartman [this message]
2020-05-20 14:03 ` Greg Kroah-Hartman
2020-05-20 14:08 ` Jim Quinlan via iommu
2020-05-20 11:28 ` Nicolas Saenz Julienne
2020-05-20 11:28 ` Nicolas Saenz Julienne
2020-05-22 14:31 ` Jim Quinlan via iommu
2020-05-22 14:31 ` Jim Quinlan
2020-05-20 17:42 ` Christoph Hellwig
2020-05-20 17:42 ` Christoph Hellwig
2020-05-20 18:26 ` Jim Quinlan via iommu
2020-05-20 18:26 ` Jim Quinlan
2020-05-20 22:36 ` Dan Williams
2020-05-20 22:36 ` Dan Williams
2020-05-21 8:19 ` Christoph Hellwig
2020-05-21 8:19 ` Christoph Hellwig
2020-05-19 20:34 ` [PATCH 10/15] dma-direct: Invoke dma offset func if needed Jim Quinlan via iommu
2020-05-19 20:34 ` Jim Quinlan
2020-05-19 20:34 ` [PATCH 11/15] arm: dma-mapping: " Jim Quinlan
2020-05-19 20:34 ` Jim Quinlan
2020-05-19 20:34 ` [PATCH 12/15] PCI: brcmstb: Set internal memory viewport sizes Jim Quinlan
2020-05-19 20:34 ` Jim Quinlan
2020-05-19 20:34 ` [PATCH 13/15] PCI: brcmstb: Accommodate MSI for older chips Jim Quinlan
2020-05-19 20:34 ` Jim Quinlan
2020-05-19 20:34 ` [PATCH 14/15] PCI: brcmstb: Set bus max burst side by chip type Jim Quinlan
2020-05-19 20:34 ` Jim Quinlan
2020-05-20 13:44 ` Nicolas Saenz Julienne
2020-05-20 13:44 ` Nicolas Saenz Julienne
2020-05-20 14:27 ` Jim Quinlan
2020-05-20 14:27 ` Jim Quinlan
2020-05-19 20:34 ` [PATCH 15/15] PCI: brcmstb: add compatilbe chips to match list Jim Quinlan
2020-05-19 20:34 ` Jim Quinlan
2020-05-20 16:15 ` [PATCH 00/15] PCI: brcmstb: enable PCIe for STB chips Bjorn Helgaas
2020-05-20 16:15 ` Bjorn Helgaas
2020-05-20 16:15 ` Bjorn Helgaas
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=20200520140320.GA3624154@kroah.com \
--to=gregkh@linuxfoundation.org \
--cc=dan.j.williams@intel.com \
--cc=devicetree@vger.kernel.org \
--cc=frowand.list@gmail.com \
--cc=hch@lst.de \
--cc=heikki.krogerus@linux.intel.com \
--cc=iommu@lists.linux-foundation.org \
--cc=james.quinlan@broadcom.com \
--cc=linux-kernel@vger.kernel.org \
--cc=nsaenzjulienne@suse.de \
--cc=rafael.j.wysocki@intel.com \
--cc=robh+dt@kernel.org \
--cc=robin.murphy@arm.com \
--cc=saravanak@google.com \
--cc=suzuki.poulose@arm.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: 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.