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]
Date:   Fri, 22 Mar 2019 10:37:27 +0200
From:   Kalle Valo <>
To:     Tim Schumacher <>
Cc:     QCA ath9k Development <>,
        "David S. Miller" <>,,,
Subject: Re: [PATCH] ath9k: Check for errors when reading SREV register

Tim Schumacher <> writes:

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

Powered by blists - more mailing lists