From: Bruno Randolf <br1@einfach.org>
To: Nick Kossifidis <mickflemm@gmail.com>
Cc: "Luis R. Rodriguez" <lrodriguez@atheros.com>,
ath5k-devel@lists.ath5k.org, linux-wireless@vger.kernel.org,
linville@tuxdriver.com, me@bobcopeland.com, mcgrof@gmail.com,
jirislaby@gmail.com, nbd@openwrt.org
Subject: Re: [ath5k-devel] [PATCH 12/30] ath5k: Increase PHY settling parameters for turo mode
Date: Wed, 24 Nov 2010 10:34:37 +0900 [thread overview]
Message-ID: <201011241034.37429.br1@einfach.org> (raw)
In-Reply-To: <AANLkTi=XpQ1anhSHSoHFFsWPB73zhdqevL7hVvgADOK6@mail.gmail.com>
On Wed November 24 2010 05:11:57 Nick Kossifidis wrote:
> 2010/11/23 Luis R. Rodriguez <lrodriguez@atheros.com>:
> > On Tue, Nov 23, 2010 at 11:04:43AM -0800, Nick Kossifidis wrote:
> >
> > Are you willing to deal with *all* bug reports for this?
> >
> > Luis
>
> I don't enable 5/10/40MHz operation anywhere for now, it's just there
> for testing/debug. I tested it and it seems to work fine (also with a
> spectrum analyzer) but until we come up with the proper way to set
> this from user-space I'll wait. Also have in mind I just do what
> Atheros does on initvals, nothing new, I just diffed initvals/rfbuffer
> settings between turbo/non-turbo modes, found what's changing and how
> (i had 5/10MHz code from HAL for that -as i wrote on another mail
> 5/10/40MHz work mostly the same way-) and implemented it on code. Now
> it's much cleaner + it actually works so i don't see a problem with
> that. Before we had code for turbo that didn't work and duplicated
> arrays of initvals/rfbuffer settings for no reason.
>
> Have in mind that there are people out there that want 5/10MHz support
> badly to implement 802.11p on top of it (or for research) and people
> who want to get rid of MadWiFi on OpenWRT and use turbo mode with
> ath5k. We had to do this sometime, it's not a dirty hack, i think the
> implementation is clean and simple.
>
> As for bug reports we already have bug reports about cards that fail
> to wake up that we are unable to debug because we have no idea what's
> going on, you can't choose what you 'll do based on possible bug
> reports, bugs are part of the process...
Hey Nick!
It's great to see that patch series! Glad you're back...
I'll look at the individual patches later, but it's a lot - as you know ;)
bruno
prev parent reply other threads:[~2010-11-24 1:34 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-11-23 19:04 [PATCH 12/30] ath5k: Increase PHY settling parameters for turo mode Nick Kossifidis
2010-11-23 19:21 ` [ath5k-devel] " Luis R. Rodriguez
2010-11-23 20:11 ` Nick Kossifidis
2010-11-24 1:34 ` Bruno Randolf [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=201011241034.37429.br1@einfach.org \
--to=br1@einfach.org \
--cc=ath5k-devel@lists.ath5k.org \
--cc=jirislaby@gmail.com \
--cc=linux-wireless@vger.kernel.org \
--cc=linville@tuxdriver.com \
--cc=lrodriguez@atheros.com \
--cc=mcgrof@gmail.com \
--cc=me@bobcopeland.com \
--cc=mickflemm@gmail.com \
--cc=nbd@openwrt.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.