On 18.03.19 23:35, Tom Psyborg wrote: > On 18/03/2019, Tim Schumacher <timschumi@xxxxxx> wrote: >> 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. >> > > you are still passing it all the way from ath9k_hw_init > I meant the actual error code (i.e. -EIO) there, which gets checked for right after the REG_READ() call in ath9k_hw_read_revisions(). If it's present, it immediately prints the "SREV register" message and returns false instead of true. >> 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. >> > > I don't think this is required. Mac Chip Rev 0x0f.3 at least prints > what the problem is instead of generic SREV read failure. The point of this patch is that the "Mac Chip Rev" (in this case) is a false message and that it actually _doesn't_ show what the problem is. There is no Rev that is 0x0f.3. It just falsely takes the -EIO from ath9k_regread() as a valid return value (since it is never caught earlier) and tries to extract a revision from it, which results in 0x0f.3. The case in where the revision succeeded to read, but it simply isn't supported by the driver, is untouched and it still prints the original message. > Either wrong > define in driver or address overlap caused by large/bad firmware in > ath9k_htc case. > I don't know why it fails to read the SREV register in my specific case (I tracked it down to a WMI command timeout, which seems to only happen on a Raspberry Pi 3), but having the SREV error message (which points to the actual issue) instead of the false-positive "Rev not supported" message would have saved me quite some time that I spent with debugging the issue, searching for the source of the wrong value.
