| Message ID | 20240805040131.450412-4-felix@kaechele.ca |
|---|---|
| State | New |
| Headers | show |
| Series | Add support for QCA9379 hw1.0 SDIO WiFi/BT | expand |
Thanks for taking a look, Krzysztof. In this case I think it would be easiest to just use the existing qca9377 fallback and drop his part of the patchset. As for the supplies: For the particular module I am working with the supplies are mostly shared with the WiFi side. So it "just works" without taking care of supplies on the BT side. But I agree it would be more correct to add and handle these as well. The documentation I have access to through the FCC filing of this module is not really conclusive of how to correctly name them in this context. I would rather avoid submitting a patch with incorrect supply names. Thanks again, Felix On 2024-08-05 01:31, Krzysztof Kozlowski wrote: > On 05/08/2024 06:01, Felix Kaechele wrote: >> Document that the QCA9379, as a member of the QCA6174 family, is >> supported by the existing driver. >> >> Signed-off-by: Felix Kaechele <felix@kaechele.ca> >> --- >> .../devicetree/bindings/net/bluetooth/qualcomm-bluetooth.yaml | 2 ++ >> 1 file changed, 2 insertions(+) >> >> diff --git a/Documentation/devicetree/bindings/net/bluetooth/qualcomm-bluetooth.yaml b/Documentation/devicetree/bindings/net/bluetooth/qualcomm-bluetooth.yaml >> index 68c5ed111417..f968b0d236e0 100644 >> --- a/Documentation/devicetree/bindings/net/bluetooth/qualcomm-bluetooth.yaml >> +++ b/Documentation/devicetree/bindings/net/bluetooth/qualcomm-bluetooth.yaml >> @@ -19,6 +19,7 @@ properties: >> - qcom,qca2066-bt >> - qcom,qca6174-bt >> - qcom,qca9377-bt >> + - qcom,qca9379-bt > > Then use fallback of 9377 or any other device. I still wonder why you do > not require any supplies. > > Best regards, > Krzysztof > >
On 14/08/2024 00:11, Felix Kaechele wrote: > Thanks for taking a look, Krzysztof. > > In this case I think it would be easiest to just use the existing > qca9377 fallback and drop his part of the patchset. You need then other patchset documenting new compatible with fallback. Compatibles are always specific. https://elixir.bootlin.com/linux/v6.10-rc1/source/Documentation/devicetree/bindings/writing-bindings.rst > > As for the supplies: For the particular module I am working with the > supplies are mostly shared with the WiFi side. So it "just works" > without taking care of supplies on the BT side. You still should describe the hardware. > > But I agree it would be more correct to add and handle these as well. > The documentation I have access to through the FCC filing of this module > is not really conclusive of how to correctly name them in this context. > I would rather avoid submitting a patch with incorrect supply names. OK Best regards, Krzysztof
diff --git a/Documentation/devicetree/bindings/net/bluetooth/qualcomm-bluetooth.yaml b/Documentation/devicetree/bindings/net/bluetooth/qualcomm-bluetooth.yaml index 68c5ed111417..f968b0d236e0 100644 --- a/Documentation/devicetree/bindings/net/bluetooth/qualcomm-bluetooth.yaml +++ b/Documentation/devicetree/bindings/net/bluetooth/qualcomm-bluetooth.yaml @@ -19,6 +19,7 @@ properties: - qcom,qca2066-bt - qcom,qca6174-bt - qcom,qca9377-bt + - qcom,qca9379-bt - qcom,wcn3988-bt - qcom,wcn3990-bt - qcom,wcn3991-bt @@ -125,6 +126,7 @@ allOf: enum: - qcom,qca2066-bt - qcom,qca6174-bt + - qcom,qca9379-bt then: required: - enable-gpios
Document that the QCA9379, as a member of the QCA6174 family, is supported by the existing driver. Signed-off-by: Felix Kaechele <felix@kaechele.ca> --- .../devicetree/bindings/net/bluetooth/qualcomm-bluetooth.yaml | 2 ++ 1 file changed, 2 insertions(+)