linux-kernel - Re: [PATCH] ath9k: Check for errors when reading SREV register

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <87d0mjnw3c.fsf@codeaurora.org>
Date:   Fri, 22 Mar 2019 10:37:27 +0200
From:   Kalle Valo <kvalo@...eaurora.org>
To:     Tim Schumacher <timschumi@....de>
Cc:     QCA ath9k Development <ath9k-devel@....qualcomm.com>,
        "David S. Miller" <davem@...emloft.net>,
        linux-wireless@...r.kernel.org, netdev@...r.kernel.org,
        linux-kernel@...r.kernel.org
Subject: Re: [PATCH] ath9k: Check for errors when reading SREV register

Tim Schumacher <timschumi@....de> writes:

> On 21.03.19 11:02, Kalle Valo wrote:
>> Tim Schumacher <timschumi@....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