Re: [PATCH 2/7] dt-bindings: i2c: renesas,rcar-i2c: R-Car V3U is R-Car Gen4

[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 other R-Car Gen3 SoC.
> 
> Hence move its compatible value to the R-Car Gen4 section.
> 
> Signed-off-by: Geert Uytterhoeven 

Applied to for-next, thanks!



signature.asc
Description: PGP signature
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu

Re: [PATCH 7/7] dt-bindings: watchdog: renesas,wdt: R-Car V3U is R-Car Gen4

[Wolfram Sang]

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 



signature.asc
Description: PGP signature
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu

Re: [PATCH 6/7] dt-bindings: serial: renesas,scif: R-Car V3U is R-Car Gen4

[Wolfram Sang]

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 



signature.asc
Description: PGP signature
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu

Re: [PATCH 5/7] dt-bindings: serial: renesas,hscif: R-Car V3U is R-Car Gen4

[Wolfram Sang]

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 



signature.asc
Description: PGP signature
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu

Re: [PATCH 3/7] dt-bindings: iommu: renesas, ipmmu-vmsa: R-Car V3U is R-Car Gen4

[Wolfram Sang]

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 



signature.asc
Description: PGP signature
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu

Re: [PATCH 2/7] dt-bindings: i2c: renesas,rcar-i2c: R-Car V3U is R-Car Gen4

[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 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@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu

Re: [PATCH 1/7] dt-bindings: gpio: renesas,rcar-gpio: R-Car V3U is R-Car Gen4

[Wolfram Sang]

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 



signature.asc
Description: PGP signature
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu

Re: [PATCH RFC] virtio: wrap config->reset calls

[Wolfram Sang]

On Wed, Oct 13, 2021 at 06:55:31AM -0400, Michael S. Tsirkin wrote:
> This will enable cleanups down the road.
> The idea is to disable cbs, then add "flush_queued_cbs" callback
> as a parameter, this way drivers can flush any work
> queued after callbacks have been disabled.
> 
> 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

Re: [PATCH] dt-bindings: Drop redundant minItems/maxItems

[Wolfram Sang]

On Tue, Jun 15, 2021 at 01:15:43PM -0600, Rob Herring wrote:
> If a property has an 'items' list, then a 'minItems' or 'maxItems' with the
> same size as the list is redundant and can be dropped. Note that is DT
> schema specific behavior and not standard json-schema behavior. The tooling
> will fixup the final schema adding any unspecified minItems/maxItems.
> 
> This condition is partially checked with the meta-schema already, but
> only if both 'minItems' and 'maxItems' are equal to the 'items' length.
> An improved meta-schema is pending.
> 
> Cc: Jens Axboe 
> Cc: Stephen Boyd 
> Cc: Herbert Xu 
> Cc: "David S. Miller" 
> Cc: David Airlie 
> Cc: Daniel Vetter 
> Cc: Vinod Koul 
> Cc: Bartosz Golaszewski 
> Cc: Kamal Dasu 
> Cc: Jonathan Cameron 
> Cc: Lars-Peter Clausen 
> Cc: Thomas Gleixner 
> Cc: Marc Zyngier 
> Cc: Joerg Roedel 
> Cc: Jassi Brar 
> Cc: Mauro Carvalho Chehab 
> Cc: Krzysztof Kozlowski 
> Cc: Ulf Hansson 
> Cc: Jakub Kicinski 
> Cc: Wolfgang Grandegger 
> Cc: Marc Kleine-Budde 
> Cc: Andrew Lunn 
> Cc: Vivien Didelot 
> Cc: Vladimir Oltean 
> Cc: Bjorn Helgaas 
> Cc: Kishon Vijay Abraham I 
> Cc: Linus Walleij 
> Cc: "Uwe Kleine-König" 
> Cc: Lee Jones 
> Cc: Ohad Ben-Cohen 
> Cc: Mathieu Poirier 
> Cc: Philipp Zabel 
> Cc: Paul Walmsley 
> Cc: Palmer Dabbelt 
> Cc: Albert Ou 
> Cc: Alessandro Zummo 
> 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

Re: [PATCH 1/3] dt-bindings: Fix undocumented compatible strings in examples

[Wolfram Sang]

On Tue, Feb 02, 2021 at 02:55:42PM -0600, Rob Herring wrote:
> Running 'dt-validate -m' will flag any compatible strings missing a schema.
> Fix all the errors found in DT binding examples. Most of these are just
> typos.
> 
> Cc: Stephen Boyd 
> Cc: Maxime Ripard 
> Cc: Chen-Yu Tsai 
> Cc: Linus Walleij 
> Cc: Herbert Xu 
> Cc: "David S. Miller" 
> Cc: Daniel Palmer 
> Cc: Bartosz Golaszewski 
> Cc: Avi Fishman 
> Cc: Tomer Maimon 
> Cc: Tali Perry 
> Cc: Joerg Roedel 
> Cc: Will Deacon 
> Cc: Andrew Jeffery 
> Cc: Joel Stanley 
> 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.org
> Cc: linux-watch...@vger.kernel.org
> 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

Re: [PATCH] dma-mapping: move hint unlikely for dma_mapping_error from drivers to core

[Wolfram Sang]

On Thu, Dec 10, 2020 at 03:47:50PM +0100, Heiner Kallweit wrote:
> Zillions of drivers use the unlikely() hint when checking the result of
> dma_mapping_error(). This is an inline function anyway, so we can move
> the hint into the function and remove it from drivers.
> From time to time discussions pop up how effective unlikely() is,
> and that it should be used only if something is really very unlikely.
> I think that's the case here.
> 
> Patch was created with some help from coccinelle.
> 
> @@
> expression dev, dma_addr;
> @@
> 
> - 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

Re: [trivial PATCH] treewide: Convert switch/case fallthrough; to break;

[Wolfram Sang]

> 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)
>   fallthrough;
>   case PCI_DEVICE_ID_INTEL_82801CA_3:
>   priv->features |= FEATURE_HOST_NOTIFY;
> - fallthrough;
> + break;
>   case PCI_DEVICE_ID_INTEL_82801BA_2:
>   case PCI_DEVICE_ID_INTEL_82801AB_3:
>   case PCI_DEVICE_ID_INTEL_82801AA_3:

I am not the maintainer (Jean is) but I suggest to drop this hunk. The
code is more complex with multiple 'fallthrough', so this change alone
actually makes the code inconsistent. A rework would need a seperate
patch.



signature.asc
Description: PGP signature
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu

Re: [PATCH v9 3/5] block: sort headers on blk-setting.c

[Wolfram Sang]

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
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu

Re: [PATCH v9 3/5] block: sort headers on blk-setting.c

[Wolfram Sang]

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, can we have your ack for this patch so Christoph can take this
series via his tree (also for patch 4/5)?

Thanks,

   Wolfram

>  block/blk-settings.c | 12 ++--
>  1 file changed, 6 insertions(+), 6 deletions(-)
> 
> diff --git a/block/blk-settings.c b/block/blk-settings.c
> index 2ae348c..45f2c52 100644
> --- a/block/blk-settings.c
> +++ b/block/blk-settings.c
> @@ -2,16 +2,16 @@
>  /*
>   * Functions related to setting various queue properties from drivers
>   */
> -#include 
> -#include 
> -#include 
>  #include 
>  #include 
> -#include   /* for max_pfn/max_low_pfn */
>  #include 
> -#include 
> -#include 
>  #include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include  /* for max_pfn/max_low_pfn */
> +#include 
>  
>  #include "blk.h"
>  #include "blk-wbt.h"
> -- 
> 2.7.4
> 


signature.asc
Description: PGP signature
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu

Re: [PATCH v9 2/5] iommu/dma: Add a new dma_map_ops of get_merge_boundary()

[Wolfram Sang]

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 for this patch so Christoph can take this
series via his tree?

Thanks,

   Wolfram

> ---
>  drivers/iommu/dma-iommu.c | 11 +++
>  1 file changed, 11 insertions(+)
> 
> diff --git a/drivers/iommu/dma-iommu.c b/drivers/iommu/dma-iommu.c
> index a7f9c3e..2992ce4 100644
> --- a/drivers/iommu/dma-iommu.c
> +++ b/drivers/iommu/dma-iommu.c
> @@ -1085,6 +1085,16 @@ static int iommu_dma_get_sgtable(struct device *dev, 
> struct sg_table *sgt,
>   return ret;
>  }
>  
> +static unsigned long iommu_dma_get_merge_boundary(struct device *dev)
> +{
> + struct iommu_domain *domain = iommu_get_dma_domain(dev);
> +
> + if (domain->type != IOMMU_DOMAIN_DMA)
> + return 0;   /* can't merge */
> +
> + return (1UL << __ffs(domain->pgsize_bitmap)) - 1;
> +}
> +
>  static const struct dma_map_ops iommu_dma_ops = {
>   .alloc  = iommu_dma_alloc,
>   .free   = iommu_dma_free,
> @@ -1100,6 +1110,7 @@ static const struct dma_map_ops iommu_dma_ops = {
>   .sync_sg_for_device = iommu_dma_sync_sg_for_device,
>   .map_resource   = iommu_dma_map_resource,
>   .unmap_resource = iommu_dma_unmap_resource,
> + .get_merge_boundary = iommu_dma_get_merge_boundary,
>  };
>  
>  /*
> -- 
> 2.7.4
> 


signature.asc
Description: PGP signature
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu

Re: [RFC PATCH v6 5/5] mmc: queue: Use bigger segments if IOMMU can merge the segments

[Wolfram Sang]

> > +   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

Re: [RFC PATCH v6 5/5] mmc: queue: Use bigger segments if IOMMU can merge the segments

[Wolfram Sang]

> - 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);
> + blk_queue_max_segments(mq->queue, mmc_get_max_segments(host));

Maybe we could use WARN here to save the comment and move the info to
the printout?

-   blk_queue_max_segments(mq->queue, host->max_segs);
+   if (host->can_merge)
+   WARN(!blk_queue_can_use_iommu_merging(mq->queue, mmc_dev(host)),
+"merging was advertised but not possible\n");
+   blk_queue_max_segments(mq->queue, mmc_get_max_segments(host));



signature.asc
Description: PGP signature

Re: [RFC PATCH v6 4/5] mmc: tmio: Use dma_max_mapping_size() instead of a workaround

[Wolfram Sang]

On Thu, Jun 13, 2019 at 07:20:14PM +0900, Yoshihiro Shimoda wrote:
> Since the commit 133d624b1cee ("dma: Introduce dma_max_mapping_size()")
> provides a helper function to get the max mapping size, we can use
> the function instead of the workaround code for swiotlb.
> 
> 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

Re: [RFC PATCH v6 2/5] block: sort headers on blk-setting.c

[Wolfram Sang]

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
Description: PGP signature

Re: [RFC PATCH v6 1/5] iommu: add an exported function to get minimum page size for a domain

[Wolfram Sang]

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 +++---
>  include/linux/iommu.h |  1 +
>  2 files changed, 16 insertions(+), 3 deletions(-)
> 
> diff --git a/drivers/iommu/iommu.c b/drivers/iommu/iommu.c
> index 2a90638..7ed16af 100644
> --- a/drivers/iommu/iommu.c
> +++ b/drivers/iommu/iommu.c
> @@ -280,6 +280,18 @@ iommu_insert_device_resv_regions(struct list_head 
> *dev_resv_regions,
>   return ret;
>  }
>  
> +/**
> + * iommu_get_minimum_page_size - get minimum page size for a domain
> + * @domain: the domain
> + *
> + * Allow iommu driver to get a minimum page size for a domain.
> + */
> +unsigned long iommu_get_minimum_page_size(struct iommu_domain *domain)
> +{
> + return 1UL << __ffs(domain->pgsize_bitmap);
> +}
> +EXPORT_SYMBOL_GPL(iommu_get_minimum_page_size);

What about making this a 'static inline' in the iommu header file? I'd
think it is simple enough and would save us the EXPORT symbol.



signature.asc
Description: PGP signature

Re: [RFC PATCH v6 0/5] treewide: improve R-Car SDHI performance

[Wolfram Sang]

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 IOMMU is enabled on the DMAC, since IOMMU will
> map multiple scatter gather buffers as one contignous iova, the DMAC can
> handle the iova as well and then the performance rate is possible to
> improve. In fact, I have measured the performance by using bonnie++,
> "Sequential Input - block" rate was improved on r8a7795.
> 
> To achieve this, this patch series modifies IOMMU and Block subsystem
> at first. Since I'd like to get any feedback from each subsystem whether
> this way is acceptable for upstream, I submit it to treewide with RFC.
> 
> Changes from v5:
>  - Almost all patches are new code.
>  - [4/5 for MMC] This is a refactor patch so that I don't add any
>{Tested,Reviewed}-by tags.
>  - [5/5 for MMC] Modify MMC subsystem to use bigger segments instead of
>the renesas_sdhi driver.
>  - [5/5 for MMC] Use BLK_MAX_SEGMENTS (128) instead of local value
>SDHI_MAX_SEGS_IN_IOMMU (512). Even if we use BLK_MAX_SEGMENTS,
>the performance is still good.

Thanks for your hard work, Shimoda-san!

I may not be the biggest DMA, IOMMU, and block layer expert, but I
really like how this simplifies the SDHI driver and enhances the MMC
core. So, I'll add my two cents to the patches although I can't really
comment on the main functionality.



signature.asc
Description: PGP signature

Re: [RFC PATCH 1/3] ARM: dma-mapping: update comment about handling dma_ops when detaching from IOMMU

[Wolfram Sang]

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_ops'.
> >
> > Fixes: 1874619a7df4 ("ARM: dma-mapping: Set proper DMA ops in 
> > arm_iommu_detach_device()")
> > Signed-off-by: Wolfram Sang 
> 
> Nice catch!
> 
> Reviewed-by: Geert Uytterhoeven 

Thanks, so I sent this seperately via ALKML now.



signature.asc
Description: PGP signature
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu

Re: [RFC PATCH 3/3] dma-mapping: clear dma_parms on teardown, too

[Wolfram Sang]

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 inspection, it looks like there are some cases (at least PCI and
> MFD) where dma_parms is installed by the parent/bus at device creation, and
> therefore remains valid and *would* be expected to persist across the child
> device's driver unbinding and rebinding - seems this is more complex than I
> first thought, sorry.

No problem. I am thankful I understand more details. So, the life cycle
of dma_parms is truly that of the device. Which means that the drivers
using devm_kzalloc in their probe, should ideally clear the pointer on
unbind. Otherwise, it is not possible to say if the non-NULL dma_parms
is intended or dangling. Which makes my initial dmam_set_dma_parms()
approach look not too bad, I'd think?

However, I don't want to push hard with this one. If you think this is
too academic, I'll just leave it for now...



signature.asc
Description: PGP signature
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu

[RFC PATCH 2/3] dma-mapping: clear dma_ops pointer also on ARM

[Wolfram Sang]

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 +++---
 include/linux/dma-mapping.h | 5 +++--
 2 files changed, 6 insertions(+), 5 deletions(-)

diff --git a/arch/arm/mm/dma-mapping.c b/arch/arm/mm/dma-mapping.c
index e3b04786838f..466b0242e8af 100644
--- a/arch/arm/mm/dma-mapping.c
+++ b/arch/arm/mm/dma-mapping.c
@@ -2396,8 +2396,8 @@ void arch_setup_dma_ops(struct device *dev, u64 dma_base, 
u64 size,
 
 void arch_teardown_dma_ops(struct device *dev)
 {
-   if (!dev->archdata.dma_ops_setup)
-   return;
+   if (dev->archdata.dma_ops_setup)
+   arm_teardown_iommu_dma_ops(dev);
 
-   arm_teardown_iommu_dma_ops(dev);
+   generic_teardown_dma_ops(dev);
 }
diff --git a/include/linux/dma-mapping.h b/include/linux/dma-mapping.h
index eafd6f318e78..020512cb7f0e 100644
--- a/include/linux/dma-mapping.h
+++ b/include/linux/dma-mapping.h
@@ -663,11 +663,12 @@ static inline void arch_setup_dma_ops(struct device *dev, 
u64 dma_base,
  bool coherent) { }
 #endif
 
-#ifndef arch_teardown_dma_ops
-static inline void arch_teardown_dma_ops(struct device *dev)
+static inline void generic_teardown_dma_ops(struct device *dev)
 {
dev->dma_ops = NULL;
 }
+#ifndef arch_teardown_dma_ops
+#define arch_teardown_dma_ops generic_teardown_dma_ops
 #endif
 
 static inline unsigned int dma_get_max_seg_size(struct device *dev)
-- 
2.18.0

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

[RFC PATCH 3/3] dma-mapping: clear dma_parms on teardown, too

[Wolfram Sang]

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 --git a/arch/arm/mm/dma-mapping.c b/arch/arm/mm/dma-mapping.c
index 466b0242e8af..bcf77bc0423f 100644
--- a/arch/arm/mm/dma-mapping.c
+++ b/arch/arm/mm/dma-mapping.c
@@ -2399,5 +2399,5 @@ void arch_teardown_dma_ops(struct device *dev)
if (dev->archdata.dma_ops_setup)
arm_teardown_iommu_dma_ops(dev);
 
-   generic_teardown_dma_ops(dev);
+   generic_teardown_dma(dev);
 }
diff --git a/include/linux/dma-mapping.h b/include/linux/dma-mapping.h
index 020512cb7f0e..6a2d8779b1d8 100644
--- a/include/linux/dma-mapping.h
+++ b/include/linux/dma-mapping.h
@@ -663,12 +663,13 @@ static inline void arch_setup_dma_ops(struct device *dev, 
u64 dma_base,
  bool coherent) { }
 #endif
 
-static inline void generic_teardown_dma_ops(struct device *dev)
+static inline void generic_teardown_dma(struct device *dev)
 {
dev->dma_ops = NULL;
+   dev->dma_parms = NULL;
 }
 #ifndef arch_teardown_dma_ops
-#define arch_teardown_dma_ops generic_teardown_dma_ops
+#define arch_teardown_dma_ops generic_teardown_dma
 #endif
 
 static inline unsigned int dma_get_max_seg_size(struct device *dev)
-- 
2.18.0

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

[RFC PATCH 0/3] dma-mapping: clear dangling pointers consistently

[Wolfram Sang]

When working with dma_set_max_seg_size(), I noticed issues with a
dangling dma_parms pointer. I saw Christoph just worked on handling
something similar for the dma_ops pointer, too. I came up with three
patches on top of Christoph's work which I send out for discussion here:

Patch 1 fixes a meanwhile stale comment.

Patch 2 makes clearing the dma_ops pointer more consistent because it
was missed on the custom ARM implementation to the best of my knowledge.

Patch 3 generalizes teardown_dma_ops to teardown_dma, so that clearing
dma_parms can be added there.

All these patches are based on the dma-mapping for-next branch. They are
build tested and runtime tested on a Renesas Salvator-XS board (R-Car
M3-N, ARM64) and Renesas Lager board (R-Car H2, ARM32).

A branch containing these (and dma_parms additions for the above boards)
can be found here:

git://git.kernel.org/pub/scm/linux/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, too

 arch/arm/mm/dma-mapping.c   | 8 
 include/linux/dma-mapping.h | 6 --
 2 files changed, 8 insertions(+), 6 deletions(-)

-- 
2.18.0

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

Re: [RFC PATCH 0/2] dma-mapping: introduce helper for setting dma_parms

[Wolfram Sang]

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
> > 'od' gets freed and dma_params is a dangling pointer.
> 
> That's the typical case - the dma_parms structure is simply embedded in some
> other private data which tends to have the appropriate lifetime anyway. I
> can't see that the dangling pointer is an issue when it's set
> unconditionally on probe and valid until remove, because anyone
> dereferencing dev->dma_parms when dev has no driver bound is doing something
> very very wrong anyway. I suppose we could zero it in
> __device_release_driver() for good measure though - shame we've found
> something dma_deconfigure() could have been useful for just after we killed
> it ;)

I see. Yes, I was aware that the misuse of this dangling pointer is
somewhat academical. Yet, it was easy to fix and clearing this pointer
is good programming practice, I'd say. I agree that clearing the pointer
in __device_release_driver is a good option, too, if documentation about
its expected life cycle (== get's cleared on unbind) is clear about
that. Probably that life cycle confusion led to the more complicated
code in the exynos_drm driver. I will look into all of that tomorrow.

> Note that ultimately we'd like to have a single structure to hold all the
> masks and other gubbins (per the very original intent of dma_parms), so

I was wondering about that, yes.

> there's a fair chance of this getting fundamentally rejigged at some point
> anyway.

Makes sense. Yet, as this change is gonna be small, I think it's still
nice to have.

Thanks for the input!

   Wolfram



signature.asc
Description: PGP signature
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu

[RFC PATCH 1/2] dma-mapping: introduce helper for setting dma_parms

[Wolfram Sang]

Setting up dma_parms seems not so trivial because it is easy to miss
that its pointer has the life cycle of its containing 'struct device'
while the allocation of dma_parms usually happens during the bind/unbind
life cycle. Which can lead to dangling pointers.
If coding this correctly in drivers, 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 +
 2 files changed, 55 insertions(+)

diff --git a/include/linux/dma-mapping.h b/include/linux/dma-mapping.h
index 1db6a6b46d0d..05a525b4639b 100644
--- a/include/linux/dma-mapping.h
+++ b/include/linux/dma-mapping.h
@@ -700,6 +700,11 @@ static inline int dma_set_seg_boundary(struct device *dev, 
unsigned long mask)
return -EIO;
 }
 
+extern int dmam_set_dma_parms(struct device *dev, unsigned int max_seg_size,
+ unsigned long seg_bound_mask);
+
+extern void dmam_free_dma_parms(struct device *dev);
+
 #ifndef dma_max_pfn
 static inline unsigned long dma_max_pfn(struct device *dev)
 {
diff --git a/kernel/dma/mapping.c b/kernel/dma/mapping.c
index d2a92ddaac4d..082cc651513b 100644
--- a/kernel/dma/mapping.c
+++ b/kernel/dma/mapping.c
@@ -198,6 +198,56 @@ EXPORT_SYMBOL(dmam_release_declared_memory);
 
 #endif
 
+static void dmam_release_dma_parms(struct device *dev, void *res)
+{
+   dev->dma_parms = NULL;
+}
+
+static int dmam_match_dma_parms(struct device *dev, void *res, void *data)
+{
+   return res == data;
+}
+
+/**
+ * dmam_set_dma_parms - Managed setting of dma_parms
+ * @dev: device to set dma_parms for
+ * @max_seg_size: the maximum segment size for this device
+ * @seg_bound_mask: the segment boundary mask for this device
+ *
+ * RETURNS:
+ * 0 on success, errno on failure.
+ */
+int dmam_set_dma_parms(struct device *dev, unsigned int max_seg_size,
+  unsigned long seg_bound_mask)
+{
+   struct device_dma_parameters *parms;
+
+   parms = devres_alloc(dmam_release_dma_parms,
+sizeof(struct device_dma_parameters), GFP_KERNEL);
+   if (!parms)
+   return -ENOMEM;
+
+   dev->dma_parms = parms;
+   dma_set_max_seg_size(dev, max_seg_size);
+   dma_set_seg_boundary(dev, seg_bound_mask);
+
+   devres_add(dev, parms);
+   return 0;
+}
+EXPORT_SYMBOL_GPL(dmam_set_dma_parms);
+
+/**
+ * dmam_free_dma_parms - free dma_parms allocated with dmam_set_dma_parms
+ * @dev: device with dma_parms allocated by dmam_set_dma_parms()
+ */
+void dmam_free_dma_parms(struct device *dev)
+{
+   int rc = devres_destroy(dev, dmam_release_dma_parms, 
dmam_match_dma_parms,
+   dev->dma_parms);
+   WARN_ON(rc);
+}
+EXPORT_SYMBOL_GPL(dmam_free_dma_parms);
+
 /*
  * Create scatter-list for the already allocated DMA buffer.
  */
-- 
2.18.0

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

[RFC PATCH 2/2] mmc: sdhi: internal_dmac: set dma_parms

[Wolfram Sang]

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/renesas_sdhi_internal_dmac.c
index ca0b43973769..00116e4ec6c4 100644
--- a/drivers/mmc/host/renesas_sdhi_internal_dmac.c
+++ b/drivers/mmc/host/renesas_sdhi_internal_dmac.c
@@ -315,6 +315,8 @@ static int renesas_sdhi_internal_dmac_probe(struct 
platform_device *pdev)
 
global_flags |= (unsigned long)soc->data;
 
+   dmam_set_dma_parms(>dev, 0x, 0);
+
return renesas_sdhi_probe(pdev, _sdhi_internal_dmac_dma_ops);
 }
 
-- 
2.18.0

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

[RFC PATCH 0/2] dma-mapping: introduce helper for setting dma_parms

[Wolfram Sang]

Hi all,

commit 78c47830a5cb ("dma-debug: check scatterlist segments") triggers
for Renesas hardware I look after, so thanks for pointing out we should
have proper dma_parms for our DMA providers.

When trying to fix it, I became a bit puzzled about the life cycle of
the pointer to dma_parms. AFAIU most drivers leave the pointer dangling
on driver unbind. Check drivers/dma/bcm2835-dma.c, for example:

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
'od' gets freed and dma_params is a dangling pointer.

drivers/gpu/drm/exynos/exynos_drm_iommu.c seems to do it correctly:

static inline int configure_dma_max_seg_size(struct device *dev)
{
if (!dev->dma_parms)
dev->dma_parms = kzalloc(sizeof(*dev->dma_parms), GFP_KERNEL);
if (!dev->dma_parms)
return -ENOMEM;

dma_set_max_seg_size(dev, DMA_BIT_MASK(32));
return 0;
}

static inline void clear_dma_max_seg_size(struct device *dev)
{
kfree(dev->dma_parms);
dev->dma_parms = NULL;
}

But this seems error prone and quite some code to add for every DMA
provider. So, I wondered if we couldn't have a helper for that. After
some brainstorming, I favour a dmam_-type of function. It will ensure
the memory gets freed and the pointer cleared on unbind. And it should
be easy to use.

I attached an RFC which I tested on a Renesas R-Car H3 SoC with the internal
DMAC of the SD controller. A branch can be found here (still waiting for
buildbot results):

git://git.kernel.org/pub/scm/linux/kernel/git/wsa/linux.git 
renesas/sdhi/set_max_seg

I added the companion function dmam_free_dma_parms() for completeness
although there is no user yet. I'd be totally open to drop it until
someone needs it.

Please let me know what you think. If this is the right track, I'll be
willing to fix the dangling pointers 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/mapping.c  | 50 +++
 3 files changed, 57 insertions(+)

-- 
2.18.0

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

[PATCH 00/61] tree-wide: simplify getting .drvdata

[Wolfram Sang]

I got tired of fixing this in Renesas drivers manually, so I took the big
hammer. Remove this cumbersome code pattern which got copy-pasted too much
already:

-   struct platform_device *pdev = to_platform_device(dev);
-   struct ep93xx_keypad *keypad = platform_get_drvdata(pdev);
+   struct ep93xx_keypad *keypad = dev_get_drvdata(dev);

I send this out as one patch per directory per subsystem. I think they should
be applied individually. If you prefer a broken out series per subsystem, I can
provide this as well. Just mail me.

A branch (tested by buildbot; only with all commits squashed into one commit
before) can be found here:

git://git.kernel.org/pub/scm/linux/kernel/git/wsa/linux.git 
coccinelle/get_drvdata

Open for other comments, suggestions, too, of course.

Here is the cocci-script I created (after  iterations by manually checking
samples):

@@
struct device* d;
identifier pdev;
expression *ptr;
@@
(
-   struct platform_device *pdev = to_platform_device(d);
|
-   struct platform_device *pdev;
...
-   pdev = to_platform_device(d);
)
<... when != pdev
-   >dev
+   d
...>

ptr =
-   platform_get_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: simplify getting .drvdata
  clk: samsung: simplify getting .drvdata
  crypto: simplify getting .drvdata
  dma: simplify getting .drvdata
  dmaengine: dw: simplify getting .drvdata
  dmaengine: qcom: simplify getting .drvdata
  gpio: simplify getting .drvdata
  gpu: drm: msm: simplify getting .drvdata
  gpu: drm: msm: adreno: simplify getting .drvdata
  gpu: drm: msm: disp: mdp5: simplify getting .drvdata
  gpu: drm: msm: dsi: simplify getting .drvdata
  gpu: drm: omapdrm: displays: simplify getting .drvdata
  gpu: drm: vc4: simplify getting .drvdata
  hid: simplify getting .drvdata
  iio: common: cros_ec_sensors: simplify getting .drvdata
  iio: common: hid-sensors: simplify getting .drvdata
  input: keyboard: simplify getting .drvdata
  input: misc: simplify getting .drvdata
  input: mouse: simplify getting .drvdata
  input: touchscreen: simplify getting .drvdata
  iommu: simplify getting .drvdata
  media: platform: am437x: simplify getting .drvdata
  media: platform: exynos4-is: simplify getting .drvdata
  media: platform: s5p-mfc: simplify getting .drvdata
  mmc: host: simplify getting .drvdata
  mtd: devices: simplify getting .drvdata
  mtd: nand: onenand: simplify getting .drvdata
  net: dsa: simplify getting .drvdata
  net: ethernet: cadence: simplify getting .drvdata
  net: ethernet: davicom: simplify getting .drvdata
  net: ethernet: smsc: simplify getting .drvdata
  net: ethernet: ti: simplify getting .drvdata
  net: ethernet: wiznet: simplify getting .drvdata
  perf: simplify getting .drvdata
  pinctrl: simplify getting .drvdata
  pinctrl: intel: simplify getting .drvdata
  platform: x86: simplify getting .drvdata
  power: supply: simplify getting .drvdata
  ptp: simplify getting .drvdata
  pwm: simplify getting .drvdata
  rtc: simplify getting .drvdata
  slimbus: simplify getting .drvdata
  spi: simplify getting .drvdata
  staging: greybus: simplify getting .drvdata
  staging: iio: adc: simplify getting .drvdata
  staging: nvec: simplify getting .drvdata
  thermal: simplify getting .drvdata
  thermal: int340x_thermal: simplify getting .drvdata
  thermal: st: simplify getting .drvdata
  tty: serial: simplify getting .drvdata
  uio: simplify getting .drvdata
  usb: mtu3: simplify getting .drvdata
  usb: phy: simplify getting .drvdata
  video: fbdev: simplify getting .drvdata
  video: fbdev: omap2: omapfb: displays: simplify getting .drvdata
  watchdog: simplify getting .drvdata
  net: dsa: simplify getting .drvdata
  ASoC: atmel: simplify getting .drvdata

 arch/arm/plat-samsung/adc.c|  3 +-
 drivers/ata/pata_samsung_cf.c  |  8 ++---
 drivers/auxdisplay/arm-charlcd.c   |  6 ++--
 drivers/bus/brcmstb_gisb.c | 12 +++
 drivers/clk/samsung/clk-s3c2410-dclk.c |  6 ++--
 drivers/crypto/exynos-rng.c|  6 ++--
 drivers/crypto/picoxcell_crypto.c  |  6 ++--
 drivers/dma/at_hdmac.c |  9 ++---
 drivers/dma/at_xdmac.c |  9 ++---
 drivers/dma/dw/platform.c  |  6 ++--
 drivers/dma/fsldma.c   |  6 ++--
 drivers/dma/idma64.c   |  6 ++--
 drivers/dma/qcom/hidma.c   |  3 +-
 drivers/dma/qcom/hidma_mgmt_sys.c  |  6 ++--
 drivers/dma/ste_dma40.c| 12 +++
 drivers/dma/txx9dmac.c |  8 ++---

[PATCH 24/61] iommu: simplify getting .drvdata

[Wolfram Sang]

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 ++
 1 file changed, 2 insertions(+), 4 deletions(-)

diff --git a/drivers/iommu/qcom_iommu.c b/drivers/iommu/qcom_iommu.c
index 65b9c99707f8..fe88a4880d3a 100644
--- a/drivers/iommu/qcom_iommu.c
+++ b/drivers/iommu/qcom_iommu.c
@@ -885,16 +885,14 @@ static int qcom_iommu_device_remove(struct 
platform_device *pdev)
 
 static int __maybe_unused qcom_iommu_resume(struct device *dev)
 {
-   struct platform_device *pdev = to_platform_device(dev);
-   struct qcom_iommu_dev *qcom_iommu = platform_get_drvdata(pdev);
+   struct qcom_iommu_dev *qcom_iommu = dev_get_drvdata(dev);
 
return qcom_iommu_enable_clocks(qcom_iommu);
 }
 
 static int __maybe_unused qcom_iommu_suspend(struct device *dev)
 {
-   struct platform_device *pdev = to_platform_device(dev);
-   struct qcom_iommu_dev *qcom_iommu = platform_get_drvdata(pdev);
+   struct qcom_iommu_dev *qcom_iommu = dev_get_drvdata(dev);
 
qcom_iommu_disable_clocks(qcom_iommu);
 
-- 
2.11.0

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

Re: [PATCH v3 07/20] i2c: Remove depends on HAS_DMA in case of platform dependency

[Wolfram Sang]

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, or PCI.
> 
> Generic symbols and drivers without platform dependencies keep their
> dependencies on HAS_DMA, to prevent compiling subsystems or drivers that
> cannot work anyway.
> 
> This simplifies the dependencies, and allows to improve compile-testing.
> 
> Signed-off-by: Geert Uytterhoeven 
> Reviewed-by: Mark Brown 
> Acked-by: Robin Murphy 

Applied to for-current, thanks!



signature.asc
Description: PGP signature
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu

Re: [PATCH v2 00/21] Allow compile-testing NO_DMA (drivers)

[Wolfram Sang]

> 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
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu

Re: [PATCH v2 00/21] Allow compile-testing NO_DMA (drivers)

[Wolfram Sang]

> 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 by myself or do you want to push
the series after the core patch and need my ack here?



signature.asc
Description: PGP signature
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu

Re: [v16, 0/7] Fix eSDHC host version register bug

[Wolfram Sang]

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
https://lists.linuxfoundation.org/mailman/listinfo/iommu

Re: [v6, 4/5] powerpc/fsl: move mpc85xx.h to include/linux/fsl

[Wolfram Sang]

On Wed, Mar 09, 2016 at 06:08:50PM +0800, Yangbo Lu wrote:
> Move mpc85xx.h to include/linux/fsl and rename it to svr.h as
> a common header file. It has been used for mpc85xx and it will
> be used for ARM-based SoC as well.
> 
> Signed-off-by: Yangbo Lu <yangbo...@nxp.com>

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

[PATCH 09/28] iommu: drop owner assignment from platform_drivers

[Wolfram Sang]

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
through. The patches shall go in via the subsystem trees.

 drivers/iommu/rockchip-iommu.c | 1 -
 1 file changed, 1 deletion(-)

diff --git a/drivers/iommu/rockchip-iommu.c b/drivers/iommu/rockchip-iommu.c
index b2023af384b9..6a8b1ec4a48a 100644
--- a/drivers/iommu/rockchip-iommu.c
+++ b/drivers/iommu/rockchip-iommu.c
@@ -1009,7 +1009,6 @@ static struct platform_driver rk_iommu_driver = {
.remove = rk_iommu_remove,
.driver = {
   .name = rk_iommu,
-  .owner = THIS_MODULE,
   .of_match_table = of_match_ptr(rk_iommu_dt_ids),
},
 };
-- 
2.1.3

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