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