On Wed, 6 Mar 2024 at 13:15, Kalle Valo <kvalo@xxxxxxxxxx> wrote: > > Dmitry Baryshkov <dmitry.baryshkov@xxxxxxxxxx> writes: > > > On Wed, 6 Mar 2024 at 11:04, Kalle Valo <kvalo@xxxxxxxxxx> wrote: > > > >> > >> Dmitry Baryshkov <dmitry.baryshkov@xxxxxxxxxx> writes: > >> > >> > On WCN3990 platforms actual firmware, wlanmdsp.mbn, is sideloaded to the > >> > modem DSP via the TQFTPserv. These MBN files are signed by the device > >> > vendor, can only be used with the particular SoC or device. > >> > > >> > Unfortunately different firmware versions come with different features. > >> > For example firmware for SDM845 doesn't use single-chan-info-per-channel > >> > feature, while firmware for QRB2210 / QRB4210 requires that feature. > >> > > >> > Allow board DT files to override the subdir of the fw dir used to lookup > >> > the firmware-N.bin file decribing corresponding WiFi firmware. > >> > For example, adding firmware-name = "qrb4210" property will make the > >> > driver look for the firmware-N.bin first in ath10k/WCN3990/hw1.0/qrb4210 > >> > directory and then fallback to the default ath10k/WCN3990/hw1.0 dir. > >> > > >> > Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@xxxxxxxxxx> > >> > --- > >> > Changes in v2: > >> > - Fixed the comment about the default board name being NULL (Kalle) > >> > - Expanded commit message to provide examples for firmware paths (Kalle) > >> > - Added a note regarding board-2.bin to the commit message (Kalle) > >> > - Link to v1: > >> > https://lore.kernel.org/r/20240130-wcn3990-firmware-path-v1-0-826b93202964@xxxxxxxxxx > >> > >> From my point of view this looks good now but let's see what others say. > >> Is there a specific reason why you marked this as RFC still? > > > > No, I just forgot to remove it from the series settings, so you can > > consider it as final. > > Good, so let's ignore the RFC label for this v2. > > > I had one minor question in my head (but that's mostly for patches 3 > > and 4): in linux-firmware we will have ath10k/WCN3990/hw1.0/qcm2290 > > and make qrb4210 as a symlink to it. Is that fine from your POV? > > Yes, I think using a symlink is a good idea. > > > Or should we use sensible device names (e.g. qcom-rb1)? > > I guess 'qcom-rb1' refers to 'Qualcomm Robotics RB1' board? In other > words, the question is that should we use chipset specific names like > 'qcm2290' or product based names like 'qcom-rb1'? > > That's a good question for which I don't have a good answer :) I'm not > very familiar with WCN3990 hardware and SoCs to have a full picture of > all this, especially how the firmware images are signed or what > different firmware branches there are etc. I checked Pixel-3 data, it has wlanmdsp.mbn signed by Google. > > To be on the safe side using 'qcom-rb1' makes sense but on the other > hand that means we need to update linux-firmware (basically add a new > symlink) everytime a new product is added. But are there going to be > that many new ath10k based products? > > Using 'qcm2290' is easier because for a new product then there only > needs to be a change in DTS and no need to change anything > linux-firmware. But here the risk is that if there's actually two > different ath10k firmware branches for 'qcm2290'. If that ever happens > (I hope not) I guess we could solve that by adding new 'qcm2290-foo' > directory? > > But I don't really know, thoughts? After some thought, I'd suggest to follow approach taken by the rest of qcom firmware: put a default (accepted by non-secured hardware) firmware to SoC dir and then put a vendor-specific firmware into subdir. If any of such vendors appear, we might even implement structural fallback: first look into sdm845/Google/blueline, then in sdm845/Google, sdm845/ and finally just under hw1.0. > > -- > https://patchwork.kernel.org/project/linux-wireless/list/ > > https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches -- With best wishes Dmitry
