| Message ID | 20240306-wcn3990-firmware-path-v2-0-f89e98e71a57@linaro.org |
|---|---|
| Headers | show |
| Series | wifi: ath10k: support board-specific firmware overrides | expand |
On 3/6/2024 6:23 AM, Dmitry Baryshkov wrote: > 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. are there existing examples in linux-firmware? or is the whole point being only the default firmware is in linux-firmware and vendors would follow this pattern if they add their own firmware?
Dmitry Baryshkov <dmitry.baryshkov@linaro.org> writes: >> 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: Can you provide pointers to those cases? > 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. Honestly that looks quite compilicated compared to having just one sub-directory. How will ath10k find the directory names (or I vendor and model names) like 'Google' or 'blueline' in this example?
On Fri, 8 Mar 2024 at 17:19, Kalle Valo <kvalo@kernel.org> wrote: > > Dmitry Baryshkov <dmitry.baryshkov@linaro.org> writes: > > >> 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: > > Can you provide pointers to those cases? https://gitlab.com/kernel-firmware/linux-firmware/-/tree/main/qcom/sc8280xp/LENOVO/21BX > > > 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. > > Honestly that looks quite compilicated compared to having just one > sub-directory. How will ath10k find the directory names (or I vendor and > model names) like 'Google' or 'blueline' in this example? I was thinking about the firmware-name = "sdm845/Google/blueline". But this can be really simpler, firmware-name = "blueline" or "sdm845/blueline" with no need for fallbacks. My point is that the firmware-name provides the possibility to handle that in different ways.
On 3/29/2024 9:47 PM, Dmitry Baryshkov wrote: > On Wed, 6 Mar 2024 at 10:16, Dmitry Baryshkov > <dmitry.baryshkov@linaro.org> wrote: >> >> 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@linaro.org> >> --- >> 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@linaro.org >> >> --- >> Dmitry Baryshkov (4): >> dt-bindings: net: wireless: ath10k: describe firmware-name property >> wifi: ath10k: support board-specific firmware overrides >> arm64: dts: qcom: qrb2210-rb1: add firmware-name qualifier to WiFi node >> arm64: dts: qcom: qrb4210-rb1: add firmware-name qualifier to WiFi node > > Kalle, Jeff, is there anything pending on me on this series? > Nothing from me -- this is outside my area of expertise so I'm deferring to Kalle. Kalle?
Jeff Johnson <quic_jjohnson@quicinc.com> writes: > On 3/29/2024 9:47 PM, Dmitry Baryshkov wrote: > >> On Wed, 6 Mar 2024 at 10:16, Dmitry Baryshkov >> <dmitry.baryshkov@linaro.org> wrote: >>> >>> 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@linaro.org> >>> --- >>> 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@linaro.org >>> >>> --- >>> Dmitry Baryshkov (4): >>> dt-bindings: net: wireless: ath10k: describe firmware-name property >>> wifi: ath10k: support board-specific firmware overrides >>> arm64: dts: qcom: qrb2210-rb1: add firmware-name qualifier to WiFi node >>> arm64: dts: qcom: qrb4210-rb1: add firmware-name qualifier to WiFi node >> >> Kalle, Jeff, is there anything pending on me on this series? >> > Nothing from me -- this is outside my area of expertise so I'm deferring to Kalle. I was on Easter vacation and now catching up, that's why the delay.
Dmitry Baryshkov <dmitry.baryshkov@linaro.org> writes: > On Fri, 8 Mar 2024 at 17:19, Kalle Valo <kvalo@kernel.org> wrote: >> >> Dmitry Baryshkov <dmitry.baryshkov@linaro.org> writes: >> >> >> 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: >> >> Can you provide pointers to those cases? > > https://gitlab.com/kernel-firmware/linux-firmware/-/tree/main/qcom/sc8280xp/LENOVO/21BX > >> >> > 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. >> >> Honestly that looks quite compilicated compared to having just one >> sub-directory. How will ath10k find the directory names (or I vendor and >> model names) like 'Google' or 'blueline' in this example? > > I was thinking about the firmware-name = "sdm845/Google/blueline". But > this can be really simpler, firmware-name = "blueline" or > "sdm845/blueline" with no need for fallbacks. I have been also thinking about this and I would prefer not to have the fallbacks. But good if you agree with that. IMHO just "sdm845-blueline" would be the most simple. I don't see the point of having a directory structure when there are not that many directories really. But this is just cosmetics. > My point is that the firmware-name provides the possibility to handle > that in different ways. Very good, thanks.
On Fri, 5 Apr 2024 at 15:01, Kalle Valo <kvalo@kernel.org> wrote: > > Dmitry Baryshkov <dmitry.baryshkov@linaro.org> writes: > > > On Fri, 8 Mar 2024 at 17:19, Kalle Valo <kvalo@kernel.org> wrote: > >> > >> Dmitry Baryshkov <dmitry.baryshkov@linaro.org> writes: > >> > >> >> 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: > >> > >> Can you provide pointers to those cases? > > > > https://gitlab.com/kernel-firmware/linux-firmware/-/tree/main/qcom/sc8280xp/LENOVO/21BX > > > >> > >> > 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. > >> > >> Honestly that looks quite compilicated compared to having just one > >> sub-directory. How will ath10k find the directory names (or I vendor and > >> model names) like 'Google' or 'blueline' in this example? > > > > I was thinking about the firmware-name = "sdm845/Google/blueline". But > > this can be really simpler, firmware-name = "blueline" or > > "sdm845/blueline" with no need for fallbacks. > > I have been also thinking about this and I would prefer not to have the > fallbacks. But good if you agree with that. > > IMHO just "sdm845-blueline" would be the most simple. I don't see the > point of having a directory structure when there are not that many > directories really. But this is just cosmetics. It is "not many directories" if we are thinking about the linux-firmware or open devices. But once embedded distros start picking this up for the supported devices, this can quickly become a nuisance. We have been there for Qualcomm DSP firmware and we ended up adopting the SoC/vendor/device structure, because otherwise it becomes a bedlam. > > My point is that the firmware-name provides the possibility to handle > > that in different ways. > > Very good, thanks. Thanks for your suggestions and for picking the patches. Bjorn, could you please pick up the DT patches now?
Dmitry Baryshkov <dmitry.baryshkov@linaro.org> writes: > On Fri, 5 Apr 2024 at 15:01, Kalle Valo <kvalo@kernel.org> wrote: > >> >> Dmitry Baryshkov <dmitry.baryshkov@linaro.org> writes: >> >> > On Fri, 8 Mar 2024 at 17:19, Kalle Valo <kvalo@kernel.org> wrote: >> >> >> >> Dmitry Baryshkov <dmitry.baryshkov@linaro.org> writes: >> >> >> >> >> 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: >> >> >> >> Can you provide pointers to those cases? >> > >> > https://gitlab.com/kernel-firmware/linux-firmware/-/tree/main/qcom/sc8280xp/LENOVO/21BX >> > >> >> >> >> > 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. >> >> >> >> Honestly that looks quite compilicated compared to having just one >> >> sub-directory. How will ath10k find the directory names (or I vendor and >> >> model names) like 'Google' or 'blueline' in this example? >> > >> > I was thinking about the firmware-name = "sdm845/Google/blueline". But >> > this can be really simpler, firmware-name = "blueline" or >> > "sdm845/blueline" with no need for fallbacks. >> >> I have been also thinking about this and I would prefer not to have the >> fallbacks. But good if you agree with that. >> >> IMHO just "sdm845-blueline" would be the most simple. I don't see the >> point of having a directory structure when there are not that many >> directories really. But this is just cosmetics. > > It is "not many directories" if we are thinking about the > linux-firmware or open devices. But once embedded distros start > picking this up for the supported devices, this can quickly become a > nuisance. Ok. Just out of curiosity, any ideas how many devices/products are there with wcn3990 who want to use ath10k?
On Fri, 5 Apr 2024 at 15:41, Kalle Valo <kvalo@kernel.org> wrote: > > Dmitry Baryshkov <dmitry.baryshkov@linaro.org> writes: > > > On Fri, 5 Apr 2024 at 15:01, Kalle Valo <kvalo@kernel.org> wrote: > > > >> > >> Dmitry Baryshkov <dmitry.baryshkov@linaro.org> writes: > >> > >> > On Fri, 8 Mar 2024 at 17:19, Kalle Valo <kvalo@kernel.org> wrote: > >> >> > >> >> Dmitry Baryshkov <dmitry.baryshkov@linaro.org> writes: > >> >> > >> >> >> 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: > >> >> > >> >> Can you provide pointers to those cases? > >> > > >> > https://gitlab.com/kernel-firmware/linux-firmware/-/tree/main/qcom/sc8280xp/LENOVO/21BX > >> > > >> >> > >> >> > 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. > >> >> > >> >> Honestly that looks quite compilicated compared to having just one > >> >> sub-directory. How will ath10k find the directory names (or I vendor and > >> >> model names) like 'Google' or 'blueline' in this example? > >> > > >> > I was thinking about the firmware-name = "sdm845/Google/blueline". But > >> > this can be really simpler, firmware-name = "blueline" or > >> > "sdm845/blueline" with no need for fallbacks. > >> > >> I have been also thinking about this and I would prefer not to have the > >> fallbacks. But good if you agree with that. > >> > >> IMHO just "sdm845-blueline" would be the most simple. I don't see the > >> point of having a directory structure when there are not that many > >> directories really. But this is just cosmetics. > > > > It is "not many directories" if we are thinking about the > > linux-firmware or open devices. But once embedded distros start > > picking this up for the supported devices, this can quickly become a > > nuisance. > > Ok. Just out of curiosity, any ideas how many devices/products are there > with wcn3990 who want to use ath10k? Just for the DT in mainline I can count about 30 devices that have ath10k WiFi node: arch/arm64/boot/dts/qcom/msm8998-clamshell.dtsi:&wifi { arch/arm64/boot/dts/qcom/msm8998-fxtec-pro1.dts:&wifi { arch/arm64/boot/dts/qcom/msm8998-mtp.dts:&wifi { arch/arm64/boot/dts/qcom/msm8998-oneplus-common.dtsi:&wifi { arch/arm64/boot/dts/qcom/msm8998-xiaomi-sagit.dts:&wifi { arch/arm64/boot/dts/qcom/qcs404-evb.dtsi:&wifi { arch/arm64/boot/dts/qcom/sc7180-acer-aspire1.dts:&wifi { arch/arm64/boot/dts/qcom/sc7180-idp.dts:&wifi { arch/arm64/boot/dts/qcom/sc7180-trogdor.dtsi:&wifi { arch/arm64/boot/dts/qcom/sc7180-trogdor-homestar.dtsi:&wifi { arch/arm64/boot/dts/qcom/sc7180-trogdor-kingoftown.dts:&wifi { arch/arm64/boot/dts/qcom/sc7180-trogdor-lazor.dtsi:&wifi { arch/arm64/boot/dts/qcom/sc7180-trogdor-pazquel360.dtsi:&wifi { arch/arm64/boot/dts/qcom/sc7180-trogdor-pompom.dtsi:&wifi { arch/arm64/boot/dts/qcom/sc7180-trogdor-wormdingler.dtsi:&wifi { arch/arm64/boot/dts/qcom/sc8180x-lenovo-flex-5g.dts:&wifi { arch/arm64/boot/dts/qcom/sc8180x-primus.dts:&wifi { arch/arm64/boot/dts/qcom/sdm845-cheza.dtsi:&wifi { arch/arm64/boot/dts/qcom/sdm845-db845c.dts:&wifi { arch/arm64/boot/dts/qcom/sdm845-mtp.dts:&wifi { arch/arm64/boot/dts/qcom/sdm845-oneplus-common.dtsi:&wifi { arch/arm64/boot/dts/qcom/sdm845-samsung-starqltechn.dts:&wifi { arch/arm64/boot/dts/qcom/sdm845-shift-axolotl.dts:&wifi { arch/arm64/boot/dts/qcom/sdm845-xiaomi-beryllium-common.dtsi:&wifi { arch/arm64/boot/dts/qcom/sdm845-xiaomi-polaris.dts:&wifi { arch/arm64/boot/dts/qcom/sm6375-sony-xperia-murray-pdx225.dts:&wifi { arch/arm64/boot/dts/qcom/sm8150-microsoft-surface-duo.dts:&wifi { arch/arm64/boot/dts/qcom/sm8150-mtp.dts:&wifi { arch/arm64/boot/dts/qcom/qrb2210-rb1.dts:&wifi { arch/arm64/boot/dts/qcom/qrb4210-rb2.dts:&wifi { The list doesn't include e.g. PIxel 2-3-4-5 or some other phones which are still on their way for the proper mainline support. -- With best wishes Dmitry
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@linaro.org> --- 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@linaro.org --- Dmitry Baryshkov (4): dt-bindings: net: wireless: ath10k: describe firmware-name property wifi: ath10k: support board-specific firmware overrides arm64: dts: qcom: qrb2210-rb1: add firmware-name qualifier to WiFi node arm64: dts: qcom: qrb4210-rb1: add firmware-name qualifier to WiFi node .../devicetree/bindings/net/wireless/qcom,ath10k.yaml | 6 ++++++ arch/arm64/boot/dts/qcom/qrb2210-rb1.dts | 1 + arch/arm64/boot/dts/qcom/qrb4210-rb2.dts | 1 + drivers/net/wireless/ath/ath10k/core.c | 11 ++++++++++- drivers/net/wireless/ath/ath10k/core.h | 2 ++ drivers/net/wireless/ath/ath10k/snoc.c | 3 +++ 6 files changed, 23 insertions(+), 1 deletion(-) --- base-commit: 596764183be8ebb13352b281a442a1f1151c9b06 change-id: 20240130-wcn3990-firmware-path-7a05a0cf8107 Best regards,