Date: Sun, 2 May 2010 12:48:52 +0930 From: "Daniel O'Connor" <doconnor@gsoft.com.au> To: "M. Warner Losh" <imp@bsdimp.com> Cc: svn-src-head@FreeBSD.org, svn-src-all@FreeBSD.org, src-committers@FreeBSD.org Subject: Re: svn commit: r207472 - in head/sys: conf dev/ath/ath_hal/ar5212 Message-ID: <383911EE-5844-4673-BAA8-796DDEBC5D5C@gsoft.com.au> In-Reply-To: <20100501.194758.49280345204940330.imp@bsdimp.com> References: <201005011636.o41GaFsK084343@svn.freebsd.org> <9624CC6A-EEB1-4492-9E62-7ACD0BF6F39C@gsoft.com.au> <20100501.194758.49280345204940330.imp@bsdimp.com>
index | next in thread | previous in thread | raw e-mail
On 02/05/2010, at 11:17 AM, M. Warner Losh wrote:
> : 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.
OK.
> And besides, kenv has to be compiled into the kernel on MIPS these
> days...
Ahh that makes a tunable fairly useless then :)
> 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...
It does have the advantage of not requiring the user to do anything which is nice even if it's clunky looking.
--
Daniel O'Connor software and network engineer
for Genesis Software - http://www.gsoft.com.au
"The nice thing about standards is that there
are so many of them to choose from."
-- Andrew Tanenbaum
GPG Fingerprint - 5596 B766 97C0 0E94 4347 295E E593 DC20 7B3F CE8C
help
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?383911EE-5844-4673-BAA8-796DDEBC5D5C>