From: Jiri Slaby <jirislaby@gmail.com>
To: ath9k-devel@lists.ath9k.org
Subject: [ath9k-devel] [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...
WARNING: multiple messages have this Message-ID (diff)
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: 34+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-09-11 1:34 [ath9k-devel] [PATCH 0/4] atheros: implement common read/write ops Luis R. Rodriguez
2009-09-11 1:34 ` Luis R. Rodriguez
2009-09-11 1:34 ` [ath9k-devel] [PATCH 1/4] atheros/ath9k: add common read/write ops and port ath9k to use it Luis R. Rodriguez
2009-09-11 1:34 ` Luis R. Rodriguez
2009-09-11 1:34 ` [ath9k-devel] [PATCH 2/4] ath5k: allocate ath5k_hw prior to initializing hw Luis R. Rodriguez
2009-09-11 1:34 ` Luis R. Rodriguez
2009-09-11 1:34 ` [ath9k-devel] [PATCH 3/4] ath5k: define ath_common ops Luis R. Rodriguez
2009-09-11 1:34 ` Luis R. Rodriguez
2009-09-11 1:42 ` [ath9k-devel] " Bob Copeland
2009-09-11 1:42 ` Bob Copeland
2009-09-11 1:46 ` [ath9k-devel] " Luis R. Rodriguez
2009-09-11 1:46 ` Luis R. Rodriguez
2009-09-11 6:16 ` [ath9k-devel] " Nick Kossifidis
2009-09-11 6:16 ` Nick Kossifidis
2009-09-11 6:46 ` Jiri Slaby [this message]
2009-09-11 6:46 ` Jiri Slaby
2009-09-11 7:23 ` [ath9k-devel] " Luis R. Rodriguez
2009-09-11 7:23 ` Luis R. Rodriguez
2009-09-11 11:35 ` [ath9k-devel] " Bob Copeland
2009-09-11 11:35 ` Bob Copeland
2009-09-11 17:53 ` [ath9k-devel] " Luis R. Rodriguez
2009-09-11 17:53 ` Luis R. Rodriguez
2009-09-11 14:24 ` [ath9k-devel] " Linus Torvalds
2009-09-11 14:24 ` Linus Torvalds
2009-09-11 17:43 ` [ath9k-devel] " Luis R. Rodriguez
2009-09-11 17:43 ` Luis R. Rodriguez
2009-09-11 20:11 ` [ath9k-devel] " Linus Torvalds
2009-09-11 20:11 ` Linus Torvalds
2009-09-12 11:53 ` [ath9k-devel] " Jiri Slaby
2009-09-12 11:53 ` Jiri Slaby
2009-09-13 0:56 ` [ath9k-devel] " Luis R. Rodriguez
2009-09-13 0:56 ` Luis R. Rodriguez
2009-09-11 1:34 ` [ath9k-devel] [PATCH 4/4] atheros: define shared bssidmask setting Luis R. Rodriguez
2009-09-11 1:34 ` 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 \
/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.