[1/2,RESEND] dmaengine: omap-dma: make omap_dma_filter_fn private
diff mbox series

Message ID 20190722081705.2084961-1-arnd@arndb.de
State New
Headers show
Series
  • [1/2,RESEND] dmaengine: omap-dma: make omap_dma_filter_fn private
Related show

Commit Message

Arnd Bergmann July 22, 2019, 8:16 a.m. UTC
With the audio driver no longer referring to this function, it
can be made private to the dmaengine driver itself, and the
header file removed.

Acked-by: Peter Ujfalusi <peter.ujfalusi@ti.com>
Link: https://lore.kernel.org/lkml/20190307151646.1016966-1-arnd@arndb.de/
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
---
Sent originally in March, but had some dependency problems
back then, please apply these now.
---
 drivers/dma/ti/omap-dma.c      |  3 ++-
 include/linux/omap-dma.h       |  2 --
 include/linux/omap-dmaengine.h | 21 ---------------------
 3 files changed, 2 insertions(+), 24 deletions(-)
 delete mode 100644 include/linux/omap-dmaengine.h

Comments

Arnd Bergmann July 22, 2019, 8:31 a.m. UTC | #1
On Mon, Jul 22, 2019 at 10:17 AM Arnd Bergmann <arnd@arndb.de> wrote:
> +++ /dev/null
> @@ -1,21 +0,0 @@
> -/*
> - * OMAP DMA Engine support
> - *


I noticed this causes a trivial merge conflict (the file change but still
needs to get removed), let me know if you need me to resend the patch.

      Arnd
Vinod Koul July 22, 2019, 2:10 p.m. UTC | #2
On 22-07-19, 10:31, Arnd Bergmann wrote:
> On Mon, Jul 22, 2019 at 10:17 AM Arnd Bergmann <arnd@arndb.de> wrote:
> > +++ /dev/null
> > @@ -1,21 +0,0 @@
> > -/*
> > - * OMAP DMA Engine support
> > - *
> 
> 
> I noticed this causes a trivial merge conflict (the file change but still
> needs to get removed), let me know if you need me to resend the patch.

thats okay, it was trivial to fix, updated now
Vinod Koul July 22, 2019, 2:12 p.m. UTC | #3
On 22-07-19, 10:16, Arnd Bergmann wrote:
> With the audio driver no longer referring to this function, it
> can be made private to the dmaengine driver itself, and the
> header file removed.
> 
> Acked-by: Peter Ujfalusi <peter.ujfalusi@ti.com>
> Link: https://lore.kernel.org/lkml/20190307151646.1016966-1-arnd@arndb.de/

This seems to point to older rev, my script updated it to latest one.

Applied both, thanks
Arnd Bergmann July 22, 2019, 2:22 p.m. UTC | #4
On Mon, Jul 22, 2019 at 4:13 PM Vinod Koul <vkoul@kernel.org> wrote:
>
> On 22-07-19, 10:16, Arnd Bergmann wrote:
> > With the audio driver no longer referring to this function, it
> > can be made private to the dmaengine driver itself, and the
> > header file removed.
> >
> > Acked-by: Peter Ujfalusi <peter.ujfalusi@ti.com>
> > Link: https://lore.kernel.org/lkml/20190307151646.1016966-1-arnd@arndb.de/
>
> This seems to point to older rev, my script updated it to latest one.

That was intentional, to see the replies to the last time it got
posted. I'm not sure if that's the best way to do it, would you
rather not have that included?

       Arnd
Vinod Koul July 22, 2019, 2:35 p.m. UTC | #5
On 22-07-19, 16:22, Arnd Bergmann wrote:
> On Mon, Jul 22, 2019 at 4:13 PM Vinod Koul <vkoul@kernel.org> wrote:
> >
> > On 22-07-19, 10:16, Arnd Bergmann wrote:
> > > With the audio driver no longer referring to this function, it
> > > can be made private to the dmaengine driver itself, and the
> > > header file removed.
> > >
> > > Acked-by: Peter Ujfalusi <peter.ujfalusi@ti.com>
> > > Link: https://lore.kernel.org/lkml/20190307151646.1016966-1-arnd@arndb.de/
> >
> > This seems to point to older rev, my script updated it to latest one.
> 
> That was intentional, to see the replies to the last time it got
> posted. I'm not sure if that's the best way to do it, would you
> rather not have that included?

That's a valid point, but should we add both the links or just relevant
one, common sense says former, scripting tends to add so keep both...?

I am thinking of not changing the one submitted and let my
script append. Is that fine?

Thanks
Arnd Bergmann July 22, 2019, 2:44 p.m. UTC | #6
On Mon, Jul 22, 2019 at 4:36 PM Vinod Koul <vkoul@kernel.org> wrote:
> On 22-07-19, 16:22, Arnd Bergmann wrote:
> > On Mon, Jul 22, 2019 at 4:13 PM Vinod Koul <vkoul@kernel.org> wrote:
> > >
> > > On 22-07-19, 10:16, Arnd Bergmann wrote:
> > > > With the audio driver no longer referring to this function, it
> > > > can be made private to the dmaengine driver itself, and the
> > > > header file removed.
> > > >
> > > > Acked-by: Peter Ujfalusi <peter.ujfalusi@ti.com>
> > > > Link: https://lore.kernel.org/lkml/20190307151646.1016966-1-arnd@arndb.de/
> > >
> > > This seems to point to older rev, my script updated it to latest one.
> >
> > That was intentional, to see the replies to the last time it got
> > posted. I'm not sure if that's the best way to do it, would you
> > rather not have that included?
>
> That's a valid point, but should we add both the links or just relevant
> one, common sense says former, scripting tends to add so keep both...?
>
> I am thinking of not changing the one submitted and let my
> script append. Is that fine?

I think adding both is best then.

       Arnd
Vinod Koul July 22, 2019, 3:23 p.m. UTC | #7
On 22-07-19, 16:44, Arnd Bergmann wrote:
> On Mon, Jul 22, 2019 at 4:36 PM Vinod Koul <vkoul@kernel.org> wrote:
> > On 22-07-19, 16:22, Arnd Bergmann wrote:
> > > On Mon, Jul 22, 2019 at 4:13 PM Vinod Koul <vkoul@kernel.org> wrote:
> > > >
> > > > On 22-07-19, 10:16, Arnd Bergmann wrote:
> > > > > With the audio driver no longer referring to this function, it
> > > > > can be made private to the dmaengine driver itself, and the
> > > > > header file removed.
> > > > >
> > > > > Acked-by: Peter Ujfalusi <peter.ujfalusi@ti.com>
> > > > > Link: https://lore.kernel.org/lkml/20190307151646.1016966-1-arnd@arndb.de/
> > > >
> > > > This seems to point to older rev, my script updated it to latest one.
> > >
> > > That was intentional, to see the replies to the last time it got
> > > posted. I'm not sure if that's the best way to do it, would you
> > > rather not have that included?
> >
> > That's a valid point, but should we add both the links or just relevant
> > one, common sense says former, scripting tends to add so keep both...?
> >
> > I am thinking of not changing the one submitted and let my
> > script append. Is that fine?
> 
> I think adding both is best then.

Ok, updated!

Patch
diff mbox series

diff --git a/drivers/dma/ti/omap-dma.c b/drivers/dma/ti/omap-dma.c
index ba2489d4ea24..49da402a1927 100644
--- a/drivers/dma/ti/omap-dma.c
+++ b/drivers/dma/ti/omap-dma.c
@@ -202,6 +202,7 @@  static const unsigned es_bytes[] = {
 	[CSDP_DATA_TYPE_32] = 4,
 };
 
+static bool omap_dma_filter_fn(struct dma_chan *chan, void *param);
 static struct of_dma_filter_info omap_dma_info = {
 	.filter_fn = omap_dma_filter_fn,
 };
@@ -1637,7 +1638,7 @@  static struct platform_driver omap_dma_driver = {
 	},
 };
 
-bool omap_dma_filter_fn(struct dma_chan *chan, void *param)
+static bool omap_dma_filter_fn(struct dma_chan *chan, void *param)
 {
 	if (chan->device->dev->driver == &omap_dma_driver.driver) {
 		struct omap_dmadev *od = to_omap_dma_dev(chan->device);
diff --git a/include/linux/omap-dma.h b/include/linux/omap-dma.h
index 840ce551e773..ba3cfbb52312 100644
--- a/include/linux/omap-dma.h
+++ b/include/linux/omap-dma.h
@@ -1,8 +1,6 @@ 
 /* SPDX-License-Identifier: GPL-2.0 */
 #ifndef __LINUX_OMAP_DMA_H
 #define __LINUX_OMAP_DMA_H
-#include <linux/omap-dmaengine.h>
-
 /*
  *  Legacy OMAP DMA handling defines and functions
  *
diff --git a/include/linux/omap-dmaengine.h b/include/linux/omap-dmaengine.h
deleted file mode 100644
index 8e6906c72e90..000000000000
--- a/include/linux/omap-dmaengine.h
+++ /dev/null
@@ -1,21 +0,0 @@ 
-/*
- * OMAP DMA Engine support
- *
- * This program is free software; you can redistribute it and/or modify
- * it under the terms of the GNU General Public License version 2 as
- * published by the Free Software Foundation.
- */
-#ifndef __LINUX_OMAP_DMAENGINE_H
-#define __LINUX_OMAP_DMAENGINE_H
-
-struct dma_chan;
-
-#if defined(CONFIG_DMA_OMAP) || (defined(CONFIG_DMA_OMAP_MODULE) && defined(MODULE))
-bool omap_dma_filter_fn(struct dma_chan *, void *);
-#else
-static inline bool omap_dma_filter_fn(struct dma_chan *c, void *d)
-{
-	return false;
-}
-#endif
-#endif /* __LINUX_OMAP_DMAENGINE_H */