2007/12/17, Nick Kossifidis <[EMAIL PROTECTED]>:
> 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 ;-)
>
Has anyone tried this on madwifi ???
--
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
