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

[Tim Schumacher]

On 21.03.19 11:02, Kalle Valo wrote:
> Tim Schumacher <timschumi@xxxxxx> writes:
>
>> Right now, if an error is encountered during the SREV register
>> read (i.e. an EIO in ath9k_regread()), that error code gets
>> passed all the way to __ath9k_hw_init(), where it is visible
>> during the "Chip rev not supported" message.
>>
>>     ath9k_htc 1-1.4:1.0: ath9k_htc: HTC initialized with 33 credits
>>     ath: phy2: Mac Chip Rev 0x0f.3 is not supported by this driver
>>     ath: phy2: Unable to initialize hardware; initialization status: -95
>>     ath: phy2: Unable to initialize hardware; initialization status: -95
>>     ath9k_htc: Failed to initialize the device
>>
>> Check for -EIO explicitly in ath9k_hw_read_revisions() and return
>> a boolean based on the success of the operation. Check for that in
>> __ath9k_hw_init() and abort with a more debugging-friendly message
>> if reading the revisions wasn't successful.
>>
>>     ath9k_htc 1-1.4:1.0: ath9k_htc: HTC initialized with 33 credits
>>     ath: phy2: Failed to read SREV register
>>     ath: phy2: Could not read hardware revision
>>     ath: phy2: Unable to initialize hardware; initialization status: -95
>>     ath: phy2: Unable to initialize hardware; initialization status: -95
>>     ath9k_htc: Failed to initialize the device
>>
>> This helps when debugging by directly showing the first point of
>> failure and it could prevent possible errors if a 0x0f.3 revision
>> is ever supported.
>>
>> Signed-off-by: Tim Schumacher <timschumi@xxxxxx>
>
> [...]
>
>> -	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.

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.