From: Jiri Slaby <jirislaby@gmail.com>
To: Nick Kossifidis <mickflemm@gmail.com>
Cc: "Luis R. Rodriguez" <lrodriguez@atheros.com>,
devel@linuxdriverproject.org, ath9k-devel@lists.ath9k.org,
linux-wireless@vger.kernel.org
Subject: Re: [PATCH 3/4] ath5k: define ath_common ops
Date: Fri, 11 Sep 2009 08:46:04 +0200 [thread overview]
Message-ID: <4AA9F22C.3090007@gmail.com> (raw)
In-Reply-To: <40f31dec0909102316q7902098jbee7fd8d17c3f622@mail.gmail.com>
On 09/11/2009 08:16 AM, Nick Kossifidis wrote:
>> static inline u32 ath5k_hw_reg_read(struct ath5k_hw *ah, u16 reg)
>> {
>> - return ioread32(ah->ah_iobase + reg);
>> + return ath5k_hw_common(ah)->ops->read(ah, reg);
>> }
>>
>> -/*
>> - * Write to a register
>> - */
>> static inline void ath5k_hw_reg_write(struct ath5k_hw *ah, u32 val, u16 reg)
>> {
>> - iowrite32(val, ah->ah_iobase + reg);
>> + ath5k_hw_common(ah)->ops->write(ah, reg, val);
...
> Since each driver will use it's own reg read/write functions (ath5k hw
> code still uses ath5k_hw_reg_read/write), why do we need to have
> common reg read/write functions like that used in the driver code ?
> This makes the code more complex that it needs to be and i don't see a
> reason why we need it. I understand why we need a way to handle
> read/write functions from common ath code but i don't see a reason to
> use these functions on ath5k, we can just fill ath_ops struct so that
> common code can use them and leave ath5k_hw_read/write untouched.
I definitely agree with Nick here. Althought whole ath_ops will be hot
cache after the first operation, there is no need to prolong hot paths
by computing the op address and a call. Ok, read/write on PCI is pretty
slow, but still...
next prev parent reply other threads:[~2009-09-11 6:46 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-09-11 1:34 [PATCH 0/4] atheros: implement common read/write ops Luis R. Rodriguez
2009-09-11 1:34 ` [PATCH 1/4] atheros/ath9k: add common read/write ops and port ath9k to use it Luis R. Rodriguez
2009-09-11 1:34 ` [PATCH 2/4] ath5k: allocate ath5k_hw prior to initializing hw Luis R. Rodriguez
2009-09-11 1:34 ` [PATCH 3/4] ath5k: define ath_common ops Luis R. Rodriguez
2009-09-11 1:42 ` Bob Copeland
2009-09-11 1:46 ` Luis R. Rodriguez
2009-09-11 6:16 ` Nick Kossifidis
2009-09-11 6:46 ` Jiri Slaby [this message]
2009-09-11 7:23 ` Luis R. Rodriguez
2009-09-11 11:35 ` Bob Copeland
2009-09-11 17:53 ` Luis R. Rodriguez
2009-09-11 14:24 ` Linus Torvalds
2009-09-11 17:43 ` Luis R. Rodriguez
2009-09-11 20:11 ` Linus Torvalds
2009-09-12 11:53 ` Jiri Slaby
2009-09-13 0:56 ` Luis R. Rodriguez
2009-09-11 1:34 ` [PATCH 4/4] atheros: define shared bssidmask setting Luis R. Rodriguez
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=4AA9F22C.3090007@gmail.com \
--to=jirislaby@gmail.com \
--cc=ath9k-devel@lists.ath9k.org \
--cc=devel@linuxdriverproject.org \
--cc=linux-wireless@vger.kernel.org \
--cc=lrodriguez@atheros.com \
--cc=mickflemm@gmail.com \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).