This platform_driver does not need to set an owner, it will be populated by the
driver core.
Signed-off-by: Wolfram Sang w...@the-dreams.de
---
Generated with coccinelle. SmPL file is in the introductory msg. The big
cleanup was pulled in this merge window. This series catches the bits fallen
From a glimpse, looks like proper refactoring. Thanks!
For the I2C part:
Acked-by: Wolfram Sang <w...@the-dreams.de>
signature.asc
Description: PGP signature
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
Can you please update your CC list? There is nothing i2c related in this
patch series, so you could drop the i2c-list.
signature.asc
Description: PGP signature
___
iommu mailing list
iommu@lists.linux-foundation.org
Hi Robin,
> > od = devm_kzalloc(>dev, sizeof(*od), GFP_KERNEL);
> > if (!od)
> > return -ENOMEM;
> >
> > pdev->dev.dma_parms = >dma_parms;
> > dma_set_max_seg_size(>dev, 0x3FFF);
> >
> > And that's all about handling dma_parms. So, on unbind, the memory for
> >
On Tue, Apr 17, 2018 at 07:49:07PM +0200, Geert Uytterhoeven wrote:
> Remove dependencies on HAS_DMA where a Kconfig symbol depends on another
> symbol that implies HAS_DMA, and, optionally, on "|| COMPILE_TEST".
> In most cases this other symbol is an architecture or platform specific
> symbol,
We should get drvdata from struct device directly. Going via
platform_device is an unneeded step back and forth.
Signed-off-by: Wolfram Sang <wsa+rene...@sang-engineering.com>
---
Build tested only. buildbot is happy. Please apply individually.
drivers/iommu/qcom_iommu.c | 6 ++
t_drvdata(pdev)
+ dev_get_drvdata(d)
<... when != pdev
- >dev
+ d
...>
Kind regards,
Wolfram
Wolfram Sang (61):
ARM: plat-samsung: simplify getting .drvdata
ata: simplify getting .drvdata
auxdisplay: simplify getting .drvdata
bus: simplif
> To avoid allmodconfig/allyesconfig regressions on NO_DMA=y platforms,
> this (drivers) series should be applied after the previous (core)
> series (but not many people may notice/care ;-)
I still don't get if there is a dependency on the core patches. I.e.
shall I apply the subsystem patch now
> To play it safe, you want to postpone the subsystem patches until the core
> part has landed upstream. I will rebase and resubmit after v4.17-rc1.
Thanks for the heads up. I'll wait for the rebased patch then and apply
it after rc1 for 4.17.
signature.asc
Description: PGP signature
, this results in boilerplate code.
So, this patch adds a devm_* style helper which is easy to use and make
sure the allocation and the pointer are always handled at the same time.
Signed-off-by: Wolfram Sang
---
include/linux/dma-mapping.h | 5
kernel/dma/mapping.c| 50
We have our own DMA provider, so we should set the dma_parms properly.
Signed-off-by: Wolfram Sang
---
drivers/mmc/host/renesas_sdhi_internal_dmac.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/mmc/host/renesas_sdhi_internal_dmac.c
b/drivers/mmc/host
with it, too.
Thanks and happy hacking,
Wolfram
Wolfram Sang (2):
dma-mapping: introduce helper for setting dma_parms
mmc: sdhi: internal_dmac: set dma_parms
drivers/mmc/host/renesas_sdhi_internal_dmac.c | 2 +
include/linux/dma-mapping.h | 5 ++
kernel/dma
On Fri, Sep 14, 2018 at 02:23:51PM +0100, Robin Murphy wrote:
> On 13/09/18 16:17, Wolfram Sang wrote:
> > While sanitizig the pointer for dma_ops on teardown, do the same for
> > dma_parms, too. Rename the function to have a more generic name.
>
> Upon closer insp
On Fri, Sep 14, 2018 at 02:15:01PM +0200, Geert Uytterhoeven wrote:
> On Thu, Sep 13, 2018 at 5:18 PM Wolfram Sang
> wrote:
> > Update the comment because we don't set the pointer to NULL anymore.
> > Also use the correct pointer name 'dma_ops' instead of 'dma_map_o
/kernel/git/wsa/linux.git
renesas/sdhi/set_max_seg
Looking forward to opinions.
Regards,
Wolfram
Wolfram Sang (3):
ARM: dma-mapping: update comment about handling dma_ops when detaching
from IOMMU
dma-mapping: clear dma_ops pointer also on ARM
dma-mapping: clear dma_parms on teardown
The generic fallback of arch_teardown_dma_ops() clears the dma_ops
pointer but the ARM specific version does not. Rename the generic one,
so it can be called from ARM specific one, too. This will ensure
consistent behaviour.
Signed-off-by: Wolfram Sang
---
arch/arm/mm/dma-mapping.c | 6
While sanitizig the pointer for dma_ops on teardown, do the same for
dma_parms, too. Rename the function to have a more generic name.
Signed-off-by: Wolfram Sang
---
arch/arm/mm/dma-mapping.c | 2 +-
include/linux/dma-mapping.h | 5 +++--
2 files changed, 4 insertions(+), 3 deletions(-)
diff
On Thu, Jun 13, 2019 at 07:20:12PM +0900, Yoshihiro Shimoda wrote:
> This patch sorts the headers in alphabetic order to ease
> the maintenance for this part.
>
> Signed-off-by: Yoshihiro Shimoda
Yup, I got the same result :)
Reviewed-by: Wolfram Sang
signature.asc
Desc
> - blk_queue_max_segments(mq->queue, host->max_segs);
> + /* blk_queue_can_use_iommu_merging() should succeed if can_merge = 1 */
> + if (host->can_merge &&
> + !blk_queue_can_use_iommu_merging(mq->queue, mmc_dev(host)))
> + WARN_ON(1);
> +
On Thu, Jun 13, 2019 at 07:20:10PM +0900, Yoshihiro Shimoda wrote:
> This patch series is based on iommu.git / next branch.
>
> Since SDHI host internal DMAC of the R-Car Gen3 cannot handle two or
> more segments, the performance rate (especially, eMMC HS400 reading)
> is not good. However, if
On Thu, Jun 13, 2019 at 07:20:11PM +0900, Yoshihiro Shimoda wrote:
> This patch adds an exported function to get minimum page size for
> a domain. This patch also modifies similar codes on the iommu.c.
>
> Signed-off-by: Yoshihiro Shimoda
> ---
> drivers/iommu/iommu.c | 18 +++---
>
Signed-off-by: Yoshihiro Shimoda
I love it! I'd really like to see this code go away. Do I get this right
that this patch is kinda independent of the reset of the series? Anyway:
Acked-by: Wolfram Sang
signature.asc
Description: PGP signature
On Fri, Jul 26, 2019 at 05:31:13PM +0900, Yoshihiro Shimoda wrote:
> This patch adds a new dma_map_ops of get_merge_boundary() to
> expose the DMA merge boundary if the domain type is IOMMU_DOMAIN_DMA.
>
> Signed-off-by: Yoshihiro Shimoda
> Reviewed-by: Simon Horman
Joerg, can we have your ack
On Fri, Jul 26, 2019 at 05:31:14PM +0900, Yoshihiro Shimoda wrote:
> This patch sorts the headers in alphabetic order to ease
> the maintenance for this part.
>
> Signed-off-by: Yoshihiro Shimoda
> Reviewed-by: Wolfram Sang
> Reviewed-by: Simon Horman
> ---
Jens,
Hi Jens,
thanks for the feedback.
> Please just drop this patch.
OK, we will do. And patch 4/5? Is it OK or do you need some more time to
think about it?
Regards,
Wolfram
signature.asc
Description: PGP signature
___
iommu mailing list
> > + host->can_merge = 1;
> > + else
> > + host->can_merge = 0;
> > +
>
> can_merge seems a little too generic a name to me. Maybe can_iommu_merge?
Ack.
signature.asc
Description: PGP signature
> diff --git a/drivers/i2c/busses/i2c-i801.c b/drivers/i2c/busses/i2c-i801.c
> index e32ef3f01fe8..b13b1cbcac29 100644
> --- a/drivers/i2c/busses/i2c-i801.c
> +++ b/drivers/i2c/busses/i2c-i801.c
> @@ -1785,7 +1785,7 @@ static int i801_probe(struct pci_dev *dev, const struct
> pci_device_id *id)
- unlikely(dma_mapping_error(dev, dma_addr))
> + dma_mapping_error(dev, dma_addr)
>
> Signed-off-by: Heiner Kallweit
Acked-by: Wolfram Sang # for I2C
signature.asc
Description: PGP signature
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
mo
> Cc: Alexandre Belloni
> Cc: Greg Kroah-Hartman
> Cc: Mark Brown
> Cc: Zhang Rui
> Cc: Daniel Lezcano
> Cc: Wim Van Sebroeck
> Cc: Guenter Roeck
> Signed-off-by: Rob Herring
Acked-by: Wolfram Sang # for I2C
signature.asc
Description: PGP signature
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
anley
> Cc: Wim Van Sebroeck
> Cc: Guenter Roeck
> Cc: Yoshihiro Shimoda
> Cc: Vincent Cheng
> Cc: linux-...@vger.kernel.org
> Cc: linux-cry...@vger.kernel.org
> Cc: linux-g...@vger.kernel.org
> Cc: linux-...@vger.kernel.org
> Cc: iommu@lists.linux-foundation.
abled.
>
> Signed-off-by: Michael S. Tsirkin
Acked-by: Wolfram Sang # for I2C changes
signature.asc
Description: PGP signature
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
On Mon, May 02, 2022 at 03:34:58PM +0200, Geert Uytterhoeven wrote:
> Despite the name, R-Car V3U is the first member of the R-Car Gen4
> family. Hence move its compatible value to the R-Car Gen4 section.
>
> Signed-off-by: Geert Uytterhoeven
Reviewed-by: Wolfram Sang
s
On Mon, May 02, 2022 at 03:34:59PM +0200, Geert Uytterhoeven wrote:
> Despite the name, R-Car V3U is the first member of the R-Car Gen4
> family. Hence move its compatible value to the R-Car Gen4 section.
>
> Signed-off-by: Geert Uytterhoeven
Reviewed-by: Wolfram Sang
s
On Mon, May 02, 2022 at 03:34:57PM +0200, Geert Uytterhoeven wrote:
> Despite the name, R-Car V3U is the first member of the R-Car Gen4
> family. Hence move its compatible value to the R-Car Gen4 section.
>
> Signed-off-by: Geert Uytterhoeven
Reviewed-by: Wolfram Sang
s
; not by any other R-Car Gen3 SoC.
>
> Hence move its compatible value to the R-Car Gen4 section.
>
> Signed-off-by: Geert Uytterhoeven
Reviewed-by: Wolfram Sang
signature.asc
Description: PGP signature
___
iommu mailing list
iommu@li
On Mon, May 02, 2022 at 03:34:55PM +0200, Geert Uytterhoeven wrote:
> Despite the name, R-Car V3U is the first member of the R-Car Gen4
> family. Hence move its compatible value to the R-Car Gen4 section.
>
> Signed-off-by: Geert Uytterhoeven
Reviewed-by: Wolfram Sang
s
On Mon, May 02, 2022 at 03:34:53PM +0200, Geert Uytterhoeven wrote:
> Despite the name, R-Car V3U is the first member of the R-Car Gen4
> family. Hence move its compatible value to the R-Car Gen4 section.
>
> Signed-off-by: Geert Uytterhoeven
> ---
Reviewed-by: Wolfram Sang
On Mon, May 02, 2022 at 03:34:54PM +0200, Geert Uytterhoeven wrote:
> Despite the name, R-Car V3U is the first member of the R-Car Gen4
> family. I2C on R-Car V3U also supports some extra features (e.g. Slave
> Clock Stretch Select), which are supported by other R-Car Gen4 SoCs, but
> not by any
38 matches
Mail list logo
