> -----Original Message----- > From: Kalle Valo <[email protected]> > Sent: Monday, September 7, 2020 9:48 PM > To: Rakesh Pillai <[email protected]> > Cc: [email protected]; [email protected]; > [email protected] > Subject: Re: [PATCH] ath10k: Use bdf calibration variant for snoc targets > > "Rakesh Pillai" <[email protected]> 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? Yes that's correct. Chip id is already being used in case of qca6174 (pci bus) We are bringing this to snoc bus chipset (WCN3990) > > -- > https://wireless.wiki.kernel.org/en/developers/documentation/submittingp > atches
