svn commit: r207472 - in head/sys: conf dev/ath/ath_hal/ar5212

John Baldwin jhb at freebsd.org
Mon May 3 14:40:22 UTC 2010


On Saturday 01 May 2010 9:47:58 pm M. Warner Losh wrote:
> In message: <9624CC6A-EEB1-4492-9E62-7ACD0BF6F39C at gsoft.com.au>
>             "Daniel O'Connor" <doconnor at gsoft.com.au> writes:
> : 
> : On 02/05/2010, at 2:06 AM, Warner Losh wrote:
> : >  Unfortunately, this condition is impossible to detect at runtime
> : >  without MIPS specific ifdefs.  Rather than cast an overly-broad net
> : >  like Linux/OpenWRT dues (which enables this workaround all the time on
> : >  MIPS32 platforms), we put this option in the kernel for just the
> : >  affected machines.  Sam didn't like this aspect of the patch when he
> : >  reviewed it, and I'd love to hear sane proposals on how to fix it :)
> : 
> : Could you do TUNABLE_INT in the MIPS code and TUNABLE_INT_FETCH in 
ath_hal?
> 
> How is that better than a kernel option?  The only place this would
> ever happen is atheros AR71xx SoC.  It isn't like some of the Atheros
> 71xx SoCs would have it and some wouldn't.
> 
> And besides, kenv has to be compiled into the kernel on MIPS these
> days...
> 
> The only thing close to an idea I've had is to add:
> 
> __weak int
> ath_needs_dma_war()
> {
> 	return 0;
> }
> 
> and have this in the mips:
> 
> int needs_ath_dma_war = 0;
> __weak int ath_needs_dma_war()
> {
> 	return needs_ath_dma_war;
> }
> 
> and set it to 1 in the AR71xx CPU initialization.  But that seemed
> kind of lame...

I think a kernel option is fine for this case.

-- 
John Baldwin


More information about the svn-src-all mailing list