[Linux-parport] [PATCH 5/6] sparc32: Do not select GENERIC_ISA_DMA

Sam Ravnborg sam at ravnborg.org
Fri Feb 23 23:59:18 PST 2024


Hi Marciej,

On Sat, Feb 24, 2024 at 05:29:43AM +0000, Maciej W. Rozycki wrote:
> On Sat, 24 Feb 2024, Maciej W. Rozycki wrote:
> 
> > > sparc32 do not support generic isa dma, so do not select the symbol.
> > > Without this fix, the following patch would break the build with a
> > > missing prototype.
> > 
> >  Not according to my observations, kernel/dma.c is always built for 
> > GENERIC_ISA_DMA configurations, so:
> > 
> > kernel/dma.c:70:5: error: no previous prototype for 'request_dma' [-Werror=missing-prototypes]
> >    70 | int request_dma(unsigned int dmanr, const char * device_id)
> >       |     ^~~~~~~~~~~
> > kernel/dma.c:88:6: error: no previous prototype for 'free_dma' [-Werror=missing-prototypes]
> >    88 | void free_dma(unsigned int dmanr)
> >       |      ^~~~~~~~
> > 
> > are issued regardless (and FAOD with PARPORT_PC unset).
> > 
> >  I can't speak for SPARC support for ISA DMA, but it seems to me like the 
> > second sentence would best be removed, as would the Fixes: tag (in favour 
> > to:
> > 
> > Fixes: 0fcb70851fbf ("Makefile.extrawarn: turn on missing-prototypes globally")
> > 
> > I presume), and possibly the messages quoted above included instead.

Thanks, I will update in v2.

> 
>  Actually I think ZONE_DMA should go too (it's linked to GENERIC_ISA_DMA, 
> isn't it? -- cf. commit 5ac6da669e24 ("[PATCH] Set CONFIG_ZONE_DMA for 
> arches with GENERIC_ISA_DMA")), and the whole thing use:
> 
> Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2")
> 
> The GENERIC_ISA_DMA option itself was added to arch/sparc/config.in with 
> 2.5.31 as:
> 
> define_bool CONFIG_GENERIC_ISA_DMA y
> 
> despite of:
> 
> define_bool CONFIG_ISA n
> 
> for a reason not clear to me (BLK_DEV_FD? -- but on SPARC that uses some 
> hacks to work in the absence of ISA DMA anyway).
> 
>  Am I missing anything here?
Nice find - the code below conforms you are right:

	max_zone_pfn[ZONE_DMA] = max_low_pfn;
	max_zone_pfn[ZONE_NORMAL] = max_low_pfn;

As they are set to the same value there is no smaller ZONE_DMA area.
I will add an extra patch for this in v2.

	Sam



More information about the Linux-parport mailing list