The WCNSS needs firmware which differs between platforms, and possibly
boards. Add a new property "firmware-name" to allow the DT to specify
the platform/board specific path to this firmware file.
Signed-off-by: Bjorn Andersson <redacted>
---
Documentation/devicetree/bindings/soc/qcom/qcom,wcnss.txt | 7 +++++++
1 file changed, 7 insertions(+)
@@ -24,6 +24,13 @@ block and a BT, WiFi and FM radio block, all using SMD as command channels. "qcom,riva", "qcom,pronto"+- firmware-name:+ Usage: optional+ Value type: <string>+ Definition: specifies the relative firmware image path for the WLAN NV+ blob. Defaults to "wlan/prima/WCNSS_qcom_wlan_nv.bin" if+ not specified.+ = SUBNODES The subnodes of the wcnss node are optional and describe the individual blocks in the WCNSS.
Introduce a local variable to carry the struct device *, to reduce the
line lengths in the next patch.
Signed-off-by: Bjorn Andersson <redacted>
---
drivers/soc/qcom/wcnss_ctrl.c | 9 +++++----
1 file changed, 5 insertions(+), 4 deletions(-)
The WLAN NV firmware blob differs between platforms, and possibly
devices, so add support in the wcnss_ctrl driver for reading the path of
this file from DT in order to allow these files to live in a generic
file system (or linux-firmware).
The new property is optional and the code falls back to the old filename
if the property isn't specified.
Signed-off-by: Bjorn Andersson <redacted>
---
drivers/soc/qcom/wcnss_ctrl.c | 10 +++++++---
1 file changed, 7 insertions(+), 3 deletions(-)
The WLAN NV firmware blob differs between platforms, and possibly
devices, so add support in the wcn36xx driver for reading the path of
this file from DT in order to allow these files to live in a generic
file system (or linux-firmware).
For some reason the parent (wcnss_ctrl) also needs to upload this blob,
so rather than specifying the same information in both nodes wcn36xx
reads the string from the parent's of_node.
Signed-off-by: Bjorn Andersson <redacted>
---
This patch can be applied independently of the others, but relates to the
acceptance of the addition to the DT binding (in patch 1/5). So my suggestion
is that this one goes through the ath tree and the others through the Qualcomm
SoC tree.
drivers/net/wireless/ath/wcn36xx/main.c | 7 +++++++
drivers/net/wireless/ath/wcn36xx/smd.c | 4 ++--
drivers/net/wireless/ath/wcn36xx/wcn36xx.h | 1 +
3 files changed, 10 insertions(+), 2 deletions(-)
@@ -1407,6 +1407,13 @@ static int wcn36xx_probe(struct platform_device *pdev)gotoout_wq;}+wcn->nv_file=WLAN_NV_FILE;+ret=of_property_read_string(wcn->dev->parent->of_node,"firmware-name",&wcn->nv_file);+if(ret<0&&ret!=-EINVAL){+wcn36xx_err("failed to read \"firmware-name\" property\n");+gotoout_wq;+}+wcn->smd_channel=qcom_wcnss_open_channel(wcnss,"WLAN_CTRL",wcn36xx_smd_rsp_process,hw);if(IS_ERR(wcn->smd_channel)){wcn36xx_err("failed to open WLAN_CTRL channel\n");
Enable the modem and WiFi subsystems and specify msm8916 specific
firmware path for these and the WCNSS control service.
Signed-off-by: Bjorn Andersson <redacted>
---
arch/arm64/boot/dts/qcom/apq8016-sbc.dtsi | 12 ++++++++++++
arch/arm64/boot/dts/qcom/msm8916.dtsi | 2 +-
2 files changed, 13 insertions(+), 1 deletion(-)
The WLAN NV firmware blob differs between platforms, and possibly
devices, so add support in the wcnss_ctrl driver for reading the path of
this file from DT in order to allow these files to live in a generic
file system (or linux-firmware).
The new property is optional and the code falls back to the old filename
if the property isn't specified.
Signed-off-by: Bjorn Andersson <redacted>
---
drivers/soc/qcom/wcnss_ctrl.c | 10 +++++++---
1 file changed, 7 insertions(+), 3 deletions(-)
The WLAN NV firmware blob differs between platforms, and possibly
devices, so add support in the wcn36xx driver for reading the path of
this file from DT in order to allow these files to live in a generic
file system (or linux-firmware).
For some reason the parent (wcnss_ctrl) also needs to upload this blob,
so rather than specifying the same information in both nodes wcn36xx
reads the string from the parent's of_node.
Signed-off-by: Bjorn Andersson <redacted>
---
This patch can be applied independently of the others, but relates to the
acceptance of the addition to the DT binding (in patch 1/5). So my suggestion
is that this one goes through the ath tree and the others through the Qualcomm
SoC tree.
drivers/net/wireless/ath/wcn36xx/main.c | 7 +++++++
drivers/net/wireless/ath/wcn36xx/smd.c | 4 ++--
drivers/net/wireless/ath/wcn36xx/wcn36xx.h | 1 +
3 files changed, 10 insertions(+), 2 deletions(-)
@@ -1407,6 +1407,13 @@ static int wcn36xx_probe(struct platform_device *pdev)gotoout_wq;}+wcn->nv_file=WLAN_NV_FILE;+ret=of_property_read_string(wcn->dev->parent->of_node,"firmware-name",&wcn->nv_file);+if(ret<0&&ret!=-EINVAL){+wcn36xx_err("failed to read \"firmware-name\" property\n");+gotoout_wq;+}+wcn->smd_channel=qcom_wcnss_open_channel(wcnss,"WLAN_CTRL",wcn36xx_smd_rsp_process,hw);if(IS_ERR(wcn->smd_channel)){wcn36xx_err("failed to open WLAN_CTRL channel\n");
Enable the modem and WiFi subsystems and specify msm8916 specific
firmware path for these and the WCNSS control service.
Signed-off-by: Bjorn Andersson <redacted>
---
arch/arm64/boot/dts/qcom/apq8016-sbc.dtsi | 12 ++++++++++++
arch/arm64/boot/dts/qcom/msm8916.dtsi | 2 +-
2 files changed, 13 insertions(+), 1 deletion(-)
On Mon 15 Mar 07:01 CDT 2021, Bryan O'Donoghue wrote:
quoted hunk
On 12/03/2021 00:33, Bjorn Andersson wrote:
quoted
Enable the modem and WiFi subsystems and specify msm8916 specific
firmware path for these and the WCNSS control service.
Signed-off-by: Bjorn Andersson <redacted>
---
arch/arm64/boot/dts/qcom/apq8016-sbc.dtsi | 12 ++++++++++++
arch/arm64/boot/dts/qcom/msm8916.dtsi | 2 +-
2 files changed, 13 insertions(+), 1 deletion(-)
The wireless subsystem found in Qualcomm MSM8974 and MSM8916 among others needs
platform-, and perhaps even board-, specific firmware. Add support for
providing this in devicetree.
From: Jeffrey Hugo <hidden> Date: 2021-03-18 16:57:07
form -> from in the subject?
On Thu, Mar 11, 2021 at 5:34 PM Bjorn Andersson
[off-list ref] wrote:
The wireless subsystem found in Qualcomm MSM8974 and MSM8916 among others needs
platform-, and perhaps even board-, specific firmware. Add support for
providing this in devicetree.
Seems like I only failed in the cover letter, right?
Regards,
Bjorn
On Thu, Mar 11, 2021 at 5:34 PM Bjorn Andersson
[off-list ref] wrote:
quoted
The wireless subsystem found in Qualcomm MSM8974 and MSM8916 among others needs
platform-, and perhaps even board-, specific firmware. Add support for
providing this in devicetree.
On Mon 15 Mar 07:01 CDT 2021, Bryan O'Donoghue wrote:
quoted
On 12/03/2021 00:33, Bjorn Andersson wrote:
quoted
Enable the modem and WiFi subsystems and specify msm8916 specific
firmware path for these and the WCNSS control service.
Signed-off-by: Bjorn Andersson <redacted>
---
arch/arm64/boot/dts/qcom/apq8016-sbc.dtsi | 12 ++++++++++++
arch/arm64/boot/dts/qcom/msm8916.dtsi | 2 +-
2 files changed, 13 insertions(+), 1 deletion(-)
From: Stephan Gerhold <stephan@gerhold.net> Date: 2021-03-19 15:23:20
Hi Bjorn,
On Thu, Mar 11, 2021 at 04:33:18PM -0800, Bjorn Andersson wrote:
Enable the modem and WiFi subsystems and specify msm8916 specific
firmware path for these and the WCNSS control service.
Signed-off-by: Bjorn Andersson <redacted>
The changes itself look good to me, but the commit message is really
misleading. It does not mention anywhere that the change actually just
enables "modem" on apq8016-sbc instead of "msm8916". :)
Also, WCNSS was actually enabled before already (with the default
firmware path). In my opinion, it would be clearer to change the
firmware-name for it in an extra patch.
How do I get a .mbn from the wcnss.{mdt,.b??} files provided in the
DB410c firmware package? I guess I should just run them through
https://github.com/andersson/pil-squasher?
Also, is the single file format (mbn) preferred now? Not sure if there
is any significant difference except having less files laying around.
Thanks,
Stephan
From: Rob Herring <robh@kernel.org> Date: 2021-03-24 15:22:53
On Thu, 11 Mar 2021 16:33:14 -0800, Bjorn Andersson wrote:
The WCNSS needs firmware which differs between platforms, and possibly
boards. Add a new property "firmware-name" to allow the DT to specify
the platform/board specific path to this firmware file.
Signed-off-by: Bjorn Andersson <redacted>
---
Documentation/devicetree/bindings/soc/qcom/qcom,wcnss.txt | 7 +++++++
1 file changed, 7 insertions(+)
On Fri 19 Mar 10:19 CDT 2021, Stephan Gerhold wrote:
Hi Bjorn,
Hi Stephan,
I thought I wrote you a reply, but I don't see it on lore or in my
mailbox...
On Thu, Mar 11, 2021 at 04:33:18PM -0800, Bjorn Andersson wrote:
quoted
Enable the modem and WiFi subsystems and specify msm8916 specific
firmware path for these and the WCNSS control service.
Signed-off-by: Bjorn Andersson <redacted>
The changes itself look good to me, but the commit message is really
misleading. It does not mention anywhere that the change actually just
enables "modem" on apq8016-sbc instead of "msm8916". :)
Also, WCNSS was actually enabled before already (with the default
firmware path). In my opinion, it would be clearer to change the
firmware-name for it in an extra patch.
How do I get a .mbn from the wcnss.{mdt,.b??} files provided in the
DB410c firmware package? I guess I should just run them through
https://github.com/andersson/pil-squasher?
Yes, .mdt + .bNN files can be put back together as a .mbn by running
them through the pil-squasher.
It's worth mentioning that the suffix doesn't matter for the loader, so
symlinking the .mdt to .mbn (in either way) will keep the kernel
happy - if that simplifies transitions in either way.
Also, is the single file format (mbn) preferred now? Not sure if there
is any significant difference except having less files laying around.
We've had numerous cases where people has managed to mix the parts from
different versions of the firmware, sometimes with the nice result of
the loader complaining that some particular .bNN file is missing
other times just with the signature check (mysteriously) failing.
Lumping the parts into a single .mbn resolves all these issues and
hence I prefer this. It is however not a requirement.
Regards,
Bjorn