2007/12/13, Pavel Roskin <[EMAIL PROTECTED]>:
> Hello!
>
> On Thu, 2007-12-13 at 19:36 +0200, Nick Kossifidis wrote:
>
> > So what we really have to rev.engineer is ani_control function.
>
> Can we somehow counteract whatever the new HAL is doing with ANI without
> reverse engineering, just by writing to the registers what the old HAL
> would do at the strategic points in the driver?
>
> The would allow us to make a release from the MadWifi trunk and possibly
> to spare some frustration to the users of the recent cards not supported
> by the old HAL.
>
> There are already precedents when MadWifi accesses the chipset registers
> directly, e.g. in ath_set_ack_bitrate().
>
> We don't have to skip 0.9.4, but we could release 0.9.5 from the trunk
> shortly thereafter.
>
Hmm...
Take a look at this ;-)
2565 /*
2566 * At this point we can't really do anything
2567 * except turn off collecting phy error stats
2568 * to reduce CPU load.
2569 */
2570 DPRINTF(("%s: ANI not working; disabling stats\n", __func__));
2571 c->phyErrStatsDisabled = AH_TRUE;
2572 ath_hal_setrxfilter(ah,
2573 ath_hal_getrxfilter(ah) &~ HAL_RX_FILTER_PHYERR);
it's from
http://madwifi.org/browser/cvs-import/trunk/driver/if_ath.c?rev=135#L2565
Can you try it in the new HAL and see if it works ??? This way even if
ANI works it won't get any phy errors from hw ;-)
--
GPG ID: 0xD21DB2DB
As you read this post global entropy rises. Have Fun ;-)
Nick
_______________________________________________
ath5k-devel mailing list
ath5k-devel@lists.ath5k.org
https://lists.ath5k.org/mailman/listinfo/ath5k-devel
