| Message ID | 20241205102213.1281865-2-quic_chejiang@quicinc.com |
|---|---|
| State | New |
| Headers | show |
| Series | Expand firmware-name property to load specific | expand |
This is an automated email and please do not reply to this email. Dear Submitter, Thank you for submitting the patches to the linux bluetooth mailing list. While preparing the CI tests, the patches you submitted couldn't be applied to the current HEAD of the repository. ----- Output ----- error: patch failed: arch/arm64/boot/dts/qcom/sa8775p-ride.dtsi:857 error: arch/arm64/boot/dts/qcom/sa8775p-ride.dtsi: patch does not apply hint: Use 'git am --show-current-patch' to see the failed patch Please resolve the issue and submit the patches again. --- Regards, Linux Bluetooth
On Thu, 05 Dec 2024 18:22:11 +0800, Cheng Jiang wrote: > Expand the firmware-name property to specify the names of NVM and > rampatch firmware to load. This update will support loading specific > firmware (nvm and rampatch) for certain chips, like the QCA6698 > Bluetooth chip, which shares the same IP core as the WCN6855 but has > different RF components and RAM sizes, requiring new firmware files. > > We might use different connectivity boards on the same platform. For > example, QCA6698-based boards can support either a two-antenna or > three-antenna solution, both of which work on the sa8775p-ride platform. > Due to differences in connectivity boards and variations in RF > performance from different foundries, different NVM configurations are > used based on the board ID. > > So In firmware-name, if the NVM file has an extension, the NVM file will > be used. Otherwise, the system will first try the .bNN (board ID) file, > and if that fails, it will fall back to the .bin file. > > Possible configurations: > firmware-name = "QCA6698/hpnv21.bin", "QCA6698/hpbtfw21.tlv"; > firmware-name = "QCA6698/hpnv21", "QCA6698/hpbtfw21.tlv"; > firmware-name = "QCA6698/hpnv21.bin"; > > Signed-off-by: Cheng Jiang <quic_chejiang@quicinc.com> > --- > .../devicetree/bindings/net/bluetooth/qualcomm-bluetooth.yaml | 2 ++ > 1 file changed, 2 insertions(+) > My bot found errors running 'make dt_binding_check' on your patch: yamllint warnings/errors: ./Documentation/devicetree/bindings/net/bluetooth/qualcomm-bluetooth.yaml:106:5: [error] duplication of key "description" in mapping (key-duplicates) dtschema/dtc warnings/errors: /builds/robherring/dt-review-ci/linux/Documentation/devicetree/bindings/net/bluetooth/qualcomm-bluetooth.yaml: ignoring, error parsing file ./Documentation/devicetree/bindings/net/bluetooth/qualcomm-bluetooth.yaml:106:5: found duplicate key "description" with value "specify the name of rampatch firmware to load" (original value: "specify the name of nvm firmware to load") make[2]: *** Deleting file 'Documentation/devicetree/bindings/net/bluetooth/qualcomm-bluetooth.example.dts' Documentation/devicetree/bindings/net/bluetooth/qualcomm-bluetooth.yaml:106:5: found duplicate key "description" with value "specify the name of rampatch firmware to load" (original value: "specify the name of nvm firmware to load") make[2]: *** [Documentation/devicetree/bindings/Makefile:26: Documentation/devicetree/bindings/net/bluetooth/qualcomm-bluetooth.example.dts] Error 1 make[2]: *** Waiting for unfinished jobs.... make[1]: *** [/builds/robherring/dt-review-ci/linux/Makefile:1506: dt_binding_check] Error 2 make: *** [Makefile:251: __sub-make] Error 2 doc reference errors (make refcheckdocs): See https://patchwork.ozlabs.org/project/devicetree-bindings/patch/20241205102213.1281865-2-quic_chejiang@quicinc.com The base for the series is generally the latest rc1. A different dependency should be noted in *this* patch. If you already ran 'make dt_binding_check' and didn't see the above error(s), then make sure 'yamllint' is installed and dt-schema is up to date: pip3 install dtschema --upgrade Please check and re-submit after running the above command yourself. Note that DT_SCHEMA_FILES can be set to your schema file to speed up checking your schema. However, it must be unset to test all examples with your schema.
Hi Krzysztof, On 12/5/2024 10:36 PM, Krzysztof Kozlowski wrote: > On 05/12/2024 11:22, Cheng Jiang wrote: >> Expand the firmware-name property to specify the names of NVM and >> rampatch firmware to load. This update will support loading specific >> firmware (nvm and rampatch) for certain chips, like the QCA6698 >> Bluetooth chip, which shares the same IP core as the WCN6855 but has >> different RF components and RAM sizes, requiring new firmware files. >> >> We might use different connectivity boards on the same platform. For >> example, QCA6698-based boards can support either a two-antenna or >> three-antenna solution, both of which work on the sa8775p-ride platform. >> Due to differences in connectivity boards and variations in RF >> performance from different foundries, different NVM configurations are >> used based on the board ID. >> >> So In firmware-name, if the NVM file has an extension, the NVM file will >> be used. Otherwise, the system will first try the .bNN (board ID) file, >> and if that fails, it will fall back to the .bin file. >> >> Possible configurations: >> firmware-name = "QCA6698/hpnv21.bin", "QCA6698/hpbtfw21.tlv"; >> firmware-name = "QCA6698/hpnv21", "QCA6698/hpbtfw21.tlv"; >> firmware-name = "QCA6698/hpnv21.bin"; > This configuration will fail tests. Please test the binding and DTS > before v4. > Ack. > Best regards, > Krzysztof
Hi Rob, On 12/5/2024 7:18 PM, Rob Herring (Arm) wrote: > > On Thu, 05 Dec 2024 18:22:11 +0800, Cheng Jiang wrote: >> Expand the firmware-name property to specify the names of NVM and >> rampatch firmware to load. This update will support loading specific >> firmware (nvm and rampatch) for certain chips, like the QCA6698 >> Bluetooth chip, which shares the same IP core as the WCN6855 but has >> different RF components and RAM sizes, requiring new firmware files. >> >> We might use different connectivity boards on the same platform. For >> example, QCA6698-based boards can support either a two-antenna or >> three-antenna solution, both of which work on the sa8775p-ride platform. >> Due to differences in connectivity boards and variations in RF >> performance from different foundries, different NVM configurations are >> used based on the board ID. >> >> So In firmware-name, if the NVM file has an extension, the NVM file will >> be used. Otherwise, the system will first try the .bNN (board ID) file, >> and if that fails, it will fall back to the .bin file. >> >> Possible configurations: >> firmware-name = "QCA6698/hpnv21.bin", "QCA6698/hpbtfw21.tlv"; >> firmware-name = "QCA6698/hpnv21", "QCA6698/hpbtfw21.tlv"; >> firmware-name = "QCA6698/hpnv21.bin"; >> >> Signed-off-by: Cheng Jiang <quic_chejiang@quicinc.com> >> --- >> .../devicetree/bindings/net/bluetooth/qualcomm-bluetooth.yaml | 2 ++ >> 1 file changed, 2 insertions(+) >> > > My bot found errors running 'make dt_binding_check' on your patch: > > yamllint warnings/errors: > ./Documentation/devicetree/bindings/net/bluetooth/qualcomm-bluetooth.yaml:106:5: [error] duplication of key "description" in mapping (key-duplicates) > > dtschema/dtc warnings/errors: > /builds/robherring/dt-review-ci/linux/Documentation/devicetree/bindings/net/bluetooth/qualcomm-bluetooth.yaml: ignoring, error parsing file > ./Documentation/devicetree/bindings/net/bluetooth/qualcomm-bluetooth.yaml:106:5: found duplicate key "description" with value "specify the name of rampatch firmware to load" (original value: "specify the name of nvm firmware to load") > make[2]: *** Deleting file 'Documentation/devicetree/bindings/net/bluetooth/qualcomm-bluetooth.example.dts' > Documentation/devicetree/bindings/net/bluetooth/qualcomm-bluetooth.yaml:106:5: found duplicate key "description" with value "specify the name of rampatch firmware to load" (original value: "specify the name of nvm firmware to load") > make[2]: *** [Documentation/devicetree/bindings/Makefile:26: Documentation/devicetree/bindings/net/bluetooth/qualcomm-bluetooth.example.dts] Error 1 > make[2]: *** Waiting for unfinished jobs.... > make[1]: *** [/builds/robherring/dt-review-ci/linux/Makefile:1506: dt_binding_check] Error 2 > make: *** [Makefile:251: __sub-make] Error 2 > > doc reference errors (make refcheckdocs): > > See https://patchwork.ozlabs.org/project/devicetree-bindings/patch/20241205102213.1281865-2-quic_chejiang@quicinc.com > > The base for the series is generally the latest rc1. A different dependency > should be noted in *this* patch. > > If you already ran 'make dt_binding_check' and didn't see the above > error(s), then make sure 'yamllint' is installed and dt-schema is up to > date: > > pip3 install dtschema --upgrade > > Please check and re-submit after running the above command yourself. Note > that DT_SCHEMA_FILES can be set to your schema file to speed up checking > your schema. However, it must be unset to test all examples with your schema. > Thank you for the info. I will run the dt_binding_check before next patch.
diff --git a/Documentation/devicetree/bindings/net/bluetooth/qualcomm-bluetooth.yaml b/Documentation/devicetree/bindings/net/bluetooth/qualcomm-bluetooth.yaml index 7bb68311c..6d73de9cd 100644 --- a/Documentation/devicetree/bindings/net/bluetooth/qualcomm-bluetooth.yaml +++ b/Documentation/devicetree/bindings/net/bluetooth/qualcomm-bluetooth.yaml @@ -101,7 +101,9 @@ properties: max-speed: true firmware-name: + maxItems: 2 description: specify the name of nvm firmware to load + description: specify the name of rampatch firmware to load local-bd-address: true
Expand the firmware-name property to specify the names of NVM and rampatch firmware to load. This update will support loading specific firmware (nvm and rampatch) for certain chips, like the QCA6698 Bluetooth chip, which shares the same IP core as the WCN6855 but has different RF components and RAM sizes, requiring new firmware files. We might use different connectivity boards on the same platform. For example, QCA6698-based boards can support either a two-antenna or three-antenna solution, both of which work on the sa8775p-ride platform. Due to differences in connectivity boards and variations in RF performance from different foundries, different NVM configurations are used based on the board ID. So In firmware-name, if the NVM file has an extension, the NVM file will be used. Otherwise, the system will first try the .bNN (board ID) file, and if that fails, it will fall back to the .bin file. Possible configurations: firmware-name = "QCA6698/hpnv21.bin", "QCA6698/hpbtfw21.tlv"; firmware-name = "QCA6698/hpnv21", "QCA6698/hpbtfw21.tlv"; firmware-name = "QCA6698/hpnv21.bin"; Signed-off-by: Cheng Jiang <quic_chejiang@quicinc.com> --- .../devicetree/bindings/net/bluetooth/qualcomm-bluetooth.yaml | 2 ++ 1 file changed, 2 insertions(+)