| Message ID | Pine.LNX.4.64.1305301650290.29171@axis700.grange (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
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
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
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
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/
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/
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
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
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/
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?
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
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(-)