From: Kalle Valo <kvalo@codeaurora.org>
To: Tim Schumacher <timschumi@gmx.de>
Cc: QCA ath9k Development <ath9k-devel@qca.qualcomm.com>,
"David S. Miller" <davem@davemloft.net>,
linux-wireless@vger.kernel.org, netdev@vger.kernel.org,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH] ath9k: Check for errors when reading SREV register
Date: Fri, 22 Mar 2019 10:37:27 +0200 [thread overview]
Message-ID: <87d0mjnw3c.fsf@codeaurora.org> (raw)
In-Reply-To: <95ca6443-a3ad-1eda-db6a-c684cc358fc9@gmx.de> (Tim Schumacher's message of "Fri, 22 Mar 2019 02:47:59 +0100")
Tim Schumacher <timschumi@gmx.de> writes:
> On 21.03.19 11:02, Kalle Valo wrote:
>> Tim Schumacher <timschumi@gmx.de> writes:
>>
>>> - val = REG_READ(ah, AR_SREV) & AR_SREV_ID;
>>> + srev = REG_READ(ah, AR_SREV);
>>> +
>>> + if (srev == -EIO) {
>>> + ath_err(ath9k_hw_common(ah),
>>> + "Failed to read SREV register");
>>> + return false;
>>> + }
>>
>> I really don't like how the error handling is implemented in REG_READ().
>> If the register has value 0xfffffffb (= -EIO ==-5) won't this interpret
>> that as an error?
>>
>
> If the register had that value, it would indeed report an error. However
> (at least if I read the current code and the data sheet correctly), to make
> use of the higher 24 bits of the register, the "small"/old version of the
> SREV_ID (i.e. the rightmost 8 bit) need to be set to 0xFF. Therefore, a
> register read of 0xfffffffb should never happen in this register.
Good, thanks for checking.
> But the error handling is indeed a bit weird. Making the return value a pure
> status indicator and saving the value from the register by passing a
> reference would probably be the best solution to fixing this up.
Yeah, that would be so much better. But that can fixed in another patch,
no need to do that here.
--
Kalle Valo
next prev parent reply other threads:[~2019-03-22 8:37 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-03-18 19:05 [PATCH] ath9k: Check for errors when reading SREV register Tim Schumacher
2019-03-18 22:35 ` Tom Psyborg
2019-03-19 6:41 ` Tim Schumacher
2019-03-19 23:38 ` Tom Psyborg
2019-03-20 5:35 ` Tim Schumacher
2019-03-21 10:02 ` Kalle Valo
2019-03-22 1:47 ` Tim Schumacher
2019-03-22 8:37 ` Kalle Valo [this message]
2019-04-29 14:53 ` Kalle Valo
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=87d0mjnw3c.fsf@codeaurora.org \
--to=kvalo@codeaurora.org \
--cc=ath9k-devel@qca.qualcomm.com \
--cc=davem@davemloft.net \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-wireless@vger.kernel.org \
--cc=netdev@vger.kernel.org \
--cc=timschumi@gmx.de \
/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).