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>] [day] [month] [year] [list]
Date:   Mon, 7 Sep 2020 16:17:57 +0000
From:   Kalle Valo <kvalo@...eaurora.org>
To:     "Rakesh Pillai" <pillair@...eaurora.org>
Cc:     linux-wireless@...r.kernel.org, linux-kernel@...r.kernel.org,
        ath10k@...ts.infradead.org
Subject: Re: [PATCH] ath10k: Use bdf calibration variant for snoc targets

"Rakesh Pillai" <pillair@...eaurora.org> writes:

>> > --- a/drivers/net/wireless/ath/ath10k/qmi.c
>> > +++ b/drivers/net/wireless/ath/ath10k/qmi.c
>> > @@ -576,6 +576,8 @@ static int ath10k_qmi_cap_send_sync_msg(struct
>> ath10k_qmi *qmi)
>> >  	if (resp->chip_info_valid) {
>> >  		qmi->chip_info.chip_id = resp->chip_info.chip_id;
>> >  		qmi->chip_info.chip_family = resp->chip_info.chip_family;
>> > +	} else {
>> > +		qmi->chip_info.chip_id = 0xFF;
>> >  	}
>> 
>> So you hard code chip_id to 0xff if it's not valid. Is it 100%
>> guaranteed that there never will be a chip id with 0xff?
>
> 0x0 and 0xff are invalid chip id and are are not used.
> If the chip_id read fails, we fallback to the default board data.
> 0xff is used to go to the default board data (Also this is in alignment with
> the current implementation of board_id)
>
> Does that make sense ?

I'm a bit hesitant, over the years I have seen cases so many cases where
"foo is not used anywhere" and later that foo is actually used
somewhere. 0xff means that there's only 254 different values, but I
guess there are not that many chip ids? So a chip id is very different
from a board id, right?

-- 
https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ