diff mbox

dmaengine: shdma: fix a build failure on platforms with no DMA support

Message ID Pine.LNX.4.64.1305301650290.29171@axis700.grange (mailing list archive)
State New, archived
Headers show

Commit Message

Guennadi Liakhovetski May 30, 2013, 4:02 p.m. UTC
On platforms with no support for the shdma dmaengine driver build is
currently failing with

drivers/built-in.o: In function `sh_mobile_sdhi_probe':
drivers/mmc/host/sh_mobile_sdhi.c:170: undefined reference to`shdma_chan_filter'

Fix the breakage by defining shdma_chan_filter to NULL in such
configurations.

Signed-off-by: Guennadi Liakhovetski <g.liakhovetski+renesas@gmail.com>
---

This is for "next." Compile-tested only. I'll test it on hardware next 
week, but I don't think it shall break anything.

 include/linux/sh_dma.h |    4 ++++
 1 files changed, 4 insertions(+), 0 deletions(-)

Comments

Dan Murphy May 30, 2013, 4:23 p.m. UTC | #1
On 05/30/2013 11:02 AM, Guennadi Liakhovetski wrote:
> On platforms with no support for the shdma dmaengine driver build is
> currently failing with
>
> drivers/built-in.o: In function `sh_mobile_sdhi_probe':
> drivers/mmc/host/sh_mobile_sdhi.c:170: undefined reference to`shdma_chan_filter'
>
> Fix the breakage by defining shdma_chan_filter to NULL in such
> configurations.
>
> Signed-off-by: Guennadi Liakhovetski <g.liakhovetski+renesas@gmail.com>
> ---
>
> This is for "next." Compile-tested only. I'll test it on hardware next 
> week, but I don't think it shall break anything.
>
>  include/linux/sh_dma.h |    4 ++++
>  1 files changed, 4 insertions(+), 0 deletions(-)
>
> diff --git a/include/linux/sh_dma.h b/include/linux/sh_dma.h
> index b64d6be..1fd8a20 100644
> --- a/include/linux/sh_dma.h
> +++ b/include/linux/sh_dma.h
> @@ -99,6 +99,10 @@ struct sh_dmae_pdata {
>  #define CHCR_TE	0x00000002
>  #define CHCR_IE	0x00000004
>  
> +#if IS_ENABLED(CONFIG_SH_DMAE)
>  bool shdma_chan_filter(struct dma_chan *chan, void *arg);
> +#else
> +#define shdma_chan_filter NULL
Would this not be better as a
#else
static inline bool shdma_chan_filter(struct dma_chan *chan, void *arg)
{
    return false;
}
#endif

Otherwise runtime will call a NULL pointer

> +#endif
>  
>  #endif
Simon Horman May 31, 2013, 2:44 a.m. UTC | #2
On Thu, May 30, 2013 at 11:23:13AM -0500, Dan Murphy wrote:
> On 05/30/2013 11:02 AM, Guennadi Liakhovetski wrote:
> > On platforms with no support for the shdma dmaengine driver build is
> > currently failing with
> >
> > drivers/built-in.o: In function `sh_mobile_sdhi_probe':
> > drivers/mmc/host/sh_mobile_sdhi.c:170: undefined reference to`shdma_chan_filter'
> >
> > Fix the breakage by defining shdma_chan_filter to NULL in such
> > configurations.
> >
> > Signed-off-by: Guennadi Liakhovetski <g.liakhovetski+renesas@gmail.com>
> > ---
> >
> > This is for "next." Compile-tested only. I'll test it on hardware next 
> > week, but I don't think it shall break anything.
> >
> >  include/linux/sh_dma.h |    4 ++++
> >  1 files changed, 4 insertions(+), 0 deletions(-)
> >
> > diff --git a/include/linux/sh_dma.h b/include/linux/sh_dma.h
> > index b64d6be..1fd8a20 100644
> > --- a/include/linux/sh_dma.h
> > +++ b/include/linux/sh_dma.h
> > @@ -99,6 +99,10 @@ struct sh_dmae_pdata {
> >  #define CHCR_TE	0x00000002
> >  #define CHCR_IE	0x00000004
> >  
> > +#if IS_ENABLED(CONFIG_SH_DMAE)
> >  bool shdma_chan_filter(struct dma_chan *chan, void *arg);
> > +#else
> > +#define shdma_chan_filter NULL
> Would this not be better as a
> #else
> static inline bool shdma_chan_filter(struct dma_chan *chan, void *arg)
> {
>     return false;
> }
> #endif
> 
> Otherwise runtime will call a NULL pointer
> 
> > +#endif
> >  
> >  #endif

Hi Guennadi,

thanks for this. I will wait for a refresh (as we discussed earlier today).
Can I confirm that this is a fix for v3.10? If so, could ou note
that when you post your revised patch?

Thanks
--
To unsubscribe from this list: send the line "unsubscribe linux-mmc" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Kevin Hilman June 19, 2013, 7 p.m. UTC | #3
On Thu, May 30, 2013 at 7:44 PM, Simon Horman <horms@verge.net.au> wrote:

[...]

> thanks for this. I will wait for a refresh (as we discussed earlier today).
> Can I confirm that this is a fix for v3.10? If so, could ou note
> that when you post your revised patch?

Any progress on this patch?

The SH-mobile defconfigs are still all failing in linux-next.

Kevin
--
To unsubscribe from this list: send the line "unsubscribe linux-mmc" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Guennadi Liakhovetski June 19, 2013, 7:32 p.m. UTC | #4
Hi Vinod

On Wed, 19 Jun 2013, Kevin Hilman wrote:

> On Thu, May 30, 2013 at 7:44 PM, Simon Horman <horms@verge.net.au> wrote:
> 
> [...]
> 
> > thanks for this. I will wait for a refresh (as we discussed earlier today).
> > Can I confirm that this is a fix for v3.10? If so, could ou note
> > that when you post your revised patch?
> 
> Any progress on this patch?
> 
> The SH-mobile defconfigs are still all failing in linux-next.

In

https://patchwork.kernel.org/patch/2640061/

I proposed a simple immediate fix for this problem. Arnd at the same time 
developed an alternative solution:

https://patchwork.kernel.org/patch/2644121/
https://patchwork.kernel.org/patch/2644111/

Which, I think, is a much larger change and isn't suitable as a bug-fix 
this late in the release cycle. Instead those patches address other issues 
with the shdma drivers, which might need to be carefully studied and 
solutions have to be found, which, however, would require more work and 
need a longer time. What is your opinion on this? Would you agree to apply 
v2 of this patch, as referenced above or would you prefer a different 
solution?

Thanks
Guennadi
---
Guennadi Liakhovetski, Ph.D.
Freelance Open-Source Software Developer
http://www.open-technology.de/
--
To unsubscribe from this list: send the line "unsubscribe linux-mmc" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Vinod Koul July 5, 2013, 4:53 a.m. UTC | #5
On Wed, Jun 19, 2013 at 09:32:18PM +0200, Guennadi Liakhovetski wrote:
> Hi Vinod
> 
> On Wed, 19 Jun 2013, Kevin Hilman wrote:
> 
> > On Thu, May 30, 2013 at 7:44 PM, Simon Horman <horms@verge.net.au> wrote:
> > 
> > [...]
> > 
> > > thanks for this. I will wait for a refresh (as we discussed earlier today).
> > > Can I confirm that this is a fix for v3.10? If so, could ou note
> > > that when you post your revised patch?
> > 
> > Any progress on this patch?
> > 
> > The SH-mobile defconfigs are still all failing in linux-next.
> 
> In
> 
> https://patchwork.kernel.org/patch/2640061/
And you havent CC maintainers on this patch, so I dont have it!
> 
> I proposed a simple immediate fix for this problem. Arnd at the same time 
> developed an alternative solution:
> 
> https://patchwork.kernel.org/patch/2644121/
> https://patchwork.kernel.org/patch/2644111/
Reading these patches I agree with Arnd that client drivers should not depend on
dma slave drivers. Existing issue need to be fixed

Arnd, Have you merged these changes?

--
~Vinod
> 
> Which, I think, is a much larger change and isn't suitable as a bug-fix 
> this late in the release cycle. Instead those patches address other issues 
> with the shdma drivers, which might need to be carefully studied and 
> solutions have to be found, which, however, would require more work and 
> need a longer time. What is your opinion on this? Would you agree to apply 
> v2 of this patch, as referenced above or would you prefer a different 
> solution?
> 
> Thanks
> Guennadi
> ---
> Guennadi Liakhovetski, Ph.D.
> Freelance Open-Source Software Developer
> http://www.open-technology.de/
Vinod Koul July 8, 2013, 7:21 a.m. UTC | #6
On Mon, Jul 08, 2013 at 12:52:16AM -0700, Olof Johansson wrote:
> On Thu, Jul 4, 2013 at 9:53 PM, Vinod Koul <vinod.koul@intel.com> wrote:
> > On Wed, Jun 19, 2013 at 09:32:18PM +0200, Guennadi Liakhovetski wrote:
> >> Hi Vinod
> >>
> >> On Wed, 19 Jun 2013, Kevin Hilman wrote:
> >>
> >> > On Thu, May 30, 2013 at 7:44 PM, Simon Horman <horms@verge.net.au> wrote:
> >> >
> >> > [...]
> >> >
> >> > > thanks for this. I will wait for a refresh (as we discussed earlier today).
> >> > > Can I confirm that this is a fix for v3.10? If so, could ou note
> >> > > that when you post your revised patch?
> >> >
> >> > Any progress on this patch?
> >> >
> >> > The SH-mobile defconfigs are still all failing in linux-next.
> >>
> >> In
> >>
> >> https://patchwork.kernel.org/patch/2640061/
> > And you havent CC maintainers on this patch, so I dont have it!
> >>
> >> I proposed a simple immediate fix for this problem. Arnd at the same time
> >> developed an alternative solution:
> >>
> >> https://patchwork.kernel.org/patch/2644121/
> >> https://patchwork.kernel.org/patch/2644111/
> > Reading these patches I agree with Arnd that client drivers should not depend on
> > dma slave drivers. Existing issue need to be fixed
> >
> > Arnd, Have you merged these changes?
> 
> Looks like we now have breakage in linux-next for this again (new
> breakage due to the header file move being applied by you on Friday,
> Vinod? Are you planning on sending the code in for 3.11? If not, you
> shouldn't apply patches right now).
Well they were already in my tree since 18th June. (tree was rebased to fixup for
pull on friday) and now these are in Linus's tree.

Can we have a fix for breakage for now sent to linus for now and then address the
proper way to do this?

~Vinod
--
To unsubscribe from this list: send the line "unsubscribe linux-mmc" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Olof Johansson July 8, 2013, 7:52 a.m. UTC | #7
On Thu, Jul 4, 2013 at 9:53 PM, Vinod Koul <vinod.koul@intel.com> wrote:
> On Wed, Jun 19, 2013 at 09:32:18PM +0200, Guennadi Liakhovetski wrote:
>> Hi Vinod
>>
>> On Wed, 19 Jun 2013, Kevin Hilman wrote:
>>
>> > On Thu, May 30, 2013 at 7:44 PM, Simon Horman <horms@verge.net.au> wrote:
>> >
>> > [...]
>> >
>> > > thanks for this. I will wait for a refresh (as we discussed earlier today).
>> > > Can I confirm that this is a fix for v3.10? If so, could ou note
>> > > that when you post your revised patch?
>> >
>> > Any progress on this patch?
>> >
>> > The SH-mobile defconfigs are still all failing in linux-next.
>>
>> In
>>
>> https://patchwork.kernel.org/patch/2640061/
> And you havent CC maintainers on this patch, so I dont have it!
>>
>> I proposed a simple immediate fix for this problem. Arnd at the same time
>> developed an alternative solution:
>>
>> https://patchwork.kernel.org/patch/2644121/
>> https://patchwork.kernel.org/patch/2644111/
> Reading these patches I agree with Arnd that client drivers should not depend on
> dma slave drivers. Existing issue need to be fixed
>
> Arnd, Have you merged these changes?

Looks like we now have breakage in linux-next for this again (new
breakage due to the header file move being applied by you on Friday,
Vinod? Are you planning on sending the code in for 3.11? If not, you
shouldn't apply patches right now).

bockw_defconfig, kota2_defconfig, marzen_defconfig and others are
currently broken.

-Olof
--
To unsubscribe from this list: send the line "unsubscribe linux-mmc" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Guennadi Liakhovetski July 8, 2013, 8:13 a.m. UTC | #8
On Fri, 5 Jul 2013, Vinod Koul wrote:

> On Wed, Jun 19, 2013 at 09:32:18PM +0200, Guennadi Liakhovetski wrote:
> > Hi Vinod
> > 
> > On Wed, 19 Jun 2013, Kevin Hilman wrote:
> > 
> > > On Thu, May 30, 2013 at 7:44 PM, Simon Horman <horms@verge.net.au> wrote:
> > > 
> > > [...]
> > > 
> > > > thanks for this. I will wait for a refresh (as we discussed earlier today).
> > > > Can I confirm that this is a fix for v3.10? If so, could ou note
> > > > that when you post your revised patch?
> > > 
> > > Any progress on this patch?
> > > 
> > > The SH-mobile defconfigs are still all failing in linux-next.
> > 
> > In
> > 
> > https://patchwork.kernel.org/patch/2640061/
> And you havent CC maintainers on this patch, so I dont have it!

Ouch, sorry, no idea how I managed not to CC you, my apologies!

> > I proposed a simple immediate fix for this problem. Arnd at the same time 
> > developed an alternative solution:
> > 
> > https://patchwork.kernel.org/patch/2644121/
> > https://patchwork.kernel.org/patch/2644111/
> Reading these patches I agree with Arnd that client drivers should not depend on
> dma slave drivers. Existing issue need to be fixed

I'm not arguing against that. My point is the following: also Arnd's 
patches have to deal with the fact, that the filter function has to be in 
files, which will be compiled with SHDMA enabled or disabled in .config. 
He solves this problem by adding #ifdef's to each .c file. Whereas I think 
it's better to add just one such #ifdef to the header. The actual issue of 
DMA client driver dependency on a specific dmaengine controller driver is 
a different (though related) problem and should be addressed separately.

Thanks
Guennadi
---
Guennadi Liakhovetski, Ph.D.
Freelance Open-Source Software Developer
http://www.open-technology.de/
--
To unsubscribe from this list: send the line "unsubscribe linux-mmc" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Simon Horman July 10, 2013, 2:09 a.m. UTC | #9
On Mon, Jul 08, 2013 at 12:51:14PM +0530, Vinod Koul wrote:
> On Mon, Jul 08, 2013 at 12:52:16AM -0700, Olof Johansson wrote:
> > On Thu, Jul 4, 2013 at 9:53 PM, Vinod Koul <vinod.koul@intel.com> wrote:
> > > On Wed, Jun 19, 2013 at 09:32:18PM +0200, Guennadi Liakhovetski wrote:
> > >> Hi Vinod
> > >>
> > >> On Wed, 19 Jun 2013, Kevin Hilman wrote:
> > >>
> > >> > On Thu, May 30, 2013 at 7:44 PM, Simon Horman <horms@verge.net.au> wrote:
> > >> >
> > >> > [...]
> > >> >
> > >> > > thanks for this. I will wait for a refresh (as we discussed earlier today).
> > >> > > Can I confirm that this is a fix for v3.10? If so, could ou note
> > >> > > that when you post your revised patch?
> > >> >
> > >> > Any progress on this patch?
> > >> >
> > >> > The SH-mobile defconfigs are still all failing in linux-next.
> > >>
> > >> In
> > >>
> > >> https://patchwork.kernel.org/patch/2640061/
> > > And you havent CC maintainers on this patch, so I dont have it!
> > >>
> > >> I proposed a simple immediate fix for this problem. Arnd at the same time
> > >> developed an alternative solution:
> > >>
> > >> https://patchwork.kernel.org/patch/2644121/
> > >> https://patchwork.kernel.org/patch/2644111/
> > > Reading these patches I agree with Arnd that client drivers should not depend on
> > > dma slave drivers. Existing issue need to be fixed
> > >
> > > Arnd, Have you merged these changes?
> > 
> > Looks like we now have breakage in linux-next for this again (new
> > breakage due to the header file move being applied by you on Friday,
> > Vinod? Are you planning on sending the code in for 3.11? If not, you
> > shouldn't apply patches right now).
> Well they were already in my tree since 18th June. (tree was rebased to fixup for
> pull on friday) and now these are in Linus's tree.
> 
> Can we have a fix for breakage for now sent to linus for now and then address the
> proper way to do this?

That is my preferred approach.

I will repost the patch at the link
https://patchwork.kernel.org/patch/2640061/ above, rebased for the header
file rename.

Vinod, can you take things from there?
--
To unsubscribe from this list: send the line "unsubscribe linux-mmc" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
diff mbox

Patch

diff --git a/include/linux/sh_dma.h b/include/linux/sh_dma.h
index b64d6be..1fd8a20 100644
--- a/include/linux/sh_dma.h
+++ b/include/linux/sh_dma.h
@@ -99,6 +99,10 @@  struct sh_dmae_pdata {
 #define CHCR_TE	0x00000002
 #define CHCR_IE	0x00000004
 
+#if IS_ENABLED(CONFIG_SH_DMAE)
 bool shdma_chan_filter(struct dma_chan *chan, void *arg);
+#else
+#define shdma_chan_filter NULL
+#endif
 
 #endif