On Thursday 20 December 2007 02:36:46 Nick Kossifidis wrote:
> 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 ???
not yet... i'll try it asap, but that might be during the next week.
bruno
_______________________________________________
ath5k-devel mailing list
ath5k-devel@lists.ath5k.org
https://lists.ath5k.org/mailman/listinfo/ath5k-devel
