diff mbox series

firmware: qcom: scm: Disable SDI and write no dump to download mode register

Message ID 20240705120623.1424931-1-quic_mojha@quicinc.com
State Superseded
Headers show
Series firmware: qcom: scm: Disable SDI and write no dump to download mode register | expand

Commit Message

Mukesh Ojha July 5, 2024, 12:06 p.m. UTC
SDI is enabled for most of the Qualcomm SoCs and as per commit
ff4aa3bc9825 ("firmware: qcom_scm: disable SDI if required")
it was recommended to disable SDI by mentioning it in device tree

However, for some cases download mode tcsr register already configured
from boot firmware to collect dumps and in such cases if download
mode is set to zero(nodump mode) from kernel side and SDI is disabled
via means of mentioning it in device tree we could end up with dump
collection.

To disable complete dump collection mode, SDI and dload mode register
need to be set no dump mode.

Signed-off-by: Mukesh Ojha <quic_mojha@quicinc.com>
---
 drivers/firmware/qcom/qcom_scm.c | 6 ++----
 1 file changed, 2 insertions(+), 4 deletions(-)

Comments

Elliot Berman July 5, 2024, 6:55 p.m. UTC | #1
On Fri, Jul 05, 2024 at 05:36:23PM +0530, Mukesh Ojha wrote:
> SDI is enabled for most of the Qualcomm SoCs and as per commit
> ff4aa3bc9825 ("firmware: qcom_scm: disable SDI if required")
> it was recommended to disable SDI by mentioning it in device tree
> 
> However, for some cases download mode tcsr register already configured
> from boot firmware to collect dumps and in such cases if download
> mode is set to zero(nodump mode) from kernel side and SDI is disabled
                     ^^^^^^^^^^^^^
that's not what download_mode=0 does currently, but it's what you're
proposing it should be doing. I think that proposal is reasonable, but
can you call out in the commit text that the current behavior of
download_mode=0 is nop.

> via means of mentioning it in device tree we could end up with dump
> collection.
> 
> To disable complete dump collection mode, SDI and dload mode register
> need to be set no dump mode.
> 
> Signed-off-by: Mukesh Ojha <quic_mojha@quicinc.com>

Should this be?

Fixes: ff4aa3bc9825 ("firmware: qcom_scm: disable SDI if required")

> ---
>  drivers/firmware/qcom/qcom_scm.c | 6 ++----
>  1 file changed, 2 insertions(+), 4 deletions(-)
> 
> diff --git a/drivers/firmware/qcom/qcom_scm.c b/drivers/firmware/qcom/qcom_scm.c
> index 00c379a3cceb..2e10f75a9cfd 100644
> --- a/drivers/firmware/qcom/qcom_scm.c
> +++ b/drivers/firmware/qcom/qcom_scm.c
> @@ -1954,14 +1954,12 @@ static int qcom_scm_probe(struct platform_device *pdev)
>  	 * will cause the boot stages to enter download mode, unless
>  	 * disabled below by a clean shutdown/reboot.
>  	 */
> -	if (download_mode)
> -		qcom_scm_set_download_mode(true);
> -
> +	qcom_scm_set_download_mode(download_mode ? true : false);

Just: qcom_scm_set_download_mode(download_mode);

>  
>  	/*
>  	 * Disable SDI if indicated by DT that it is enabled by default.
>  	 */
> -	if (of_property_read_bool(pdev->dev.of_node, "qcom,sdi-enabled"))
> +	if (of_property_read_bool(pdev->dev.of_node, "qcom,sdi-enabled") || !download_mode)


>  		qcom_scm_disable_sdi();
>  
>  	ret = of_reserved_mem_device_init(__scm->dev);
> -- 
> 2.34.1
> 
>
Mukesh Ojha July 8, 2024, 12:51 p.m. UTC | #2
On Fri, Jul 05, 2024 at 11:55:52AM -0700, Elliot Berman wrote:
> On Fri, Jul 05, 2024 at 05:36:23PM +0530, Mukesh Ojha wrote:
> > SDI is enabled for most of the Qualcomm SoCs and as per commit
> > ff4aa3bc9825 ("firmware: qcom_scm: disable SDI if required")
> > it was recommended to disable SDI by mentioning it in device tree
> > 
> > However, for some cases download mode tcsr register already configured
> > from boot firmware to collect dumps and in such cases if download
> > mode is set to zero(nodump mode) from kernel side and SDI is disabled
>                      ^^^^^^^^^^^^^
> that's not what download_mode=0 does currently, but it's what you're
> proposing it should be doing. I think that proposal is reasonable, but
> can you call out in the commit text that the current behavior of
> download_mode=0 is nop.

Correct..

> 
> > via means of mentioning it in device tree we could end up with dump
> > collection.
> > 
> > To disable complete dump collection mode, SDI and dload mode register
> > need to be set no dump mode.
> > 
> > Signed-off-by: Mukesh Ojha <quic_mojha@quicinc.com>
> 
> Should this be?
> 
> Fixes: ff4aa3bc9825 ("firmware: qcom_scm: disable SDI if required")

Yes, SDI disablement can still result in dump collection and can cause
a hang.

> 
> > ---
> >  drivers/firmware/qcom/qcom_scm.c | 6 ++----
> >  1 file changed, 2 insertions(+), 4 deletions(-)
> > 
> > diff --git a/drivers/firmware/qcom/qcom_scm.c b/drivers/firmware/qcom/qcom_scm.c
> > index 00c379a3cceb..2e10f75a9cfd 100644
> > --- a/drivers/firmware/qcom/qcom_scm.c
> > +++ b/drivers/firmware/qcom/qcom_scm.c
> > @@ -1954,14 +1954,12 @@ static int qcom_scm_probe(struct platform_device *pdev)
> >  	 * will cause the boot stages to enter download mode, unless
> >  	 * disabled below by a clean shutdown/reboot.
> >  	 */
> > -	if (download_mode)
> > -		qcom_scm_set_download_mode(true);
> > -
> > +	qcom_scm_set_download_mode(download_mode ? true : false);
> 
> Just: qcom_scm_set_download_mode(download_mode);

Sure.

-Mukesh
diff mbox series

Patch

diff --git a/drivers/firmware/qcom/qcom_scm.c b/drivers/firmware/qcom/qcom_scm.c
index 00c379a3cceb..2e10f75a9cfd 100644
--- a/drivers/firmware/qcom/qcom_scm.c
+++ b/drivers/firmware/qcom/qcom_scm.c
@@ -1954,14 +1954,12 @@  static int qcom_scm_probe(struct platform_device *pdev)
 	 * will cause the boot stages to enter download mode, unless
 	 * disabled below by a clean shutdown/reboot.
 	 */
-	if (download_mode)
-		qcom_scm_set_download_mode(true);
-
+	qcom_scm_set_download_mode(download_mode ? true : false);
 
 	/*
 	 * Disable SDI if indicated by DT that it is enabled by default.
 	 */
-	if (of_property_read_bool(pdev->dev.of_node, "qcom,sdi-enabled"))
+	if (of_property_read_bool(pdev->dev.of_node, "qcom,sdi-enabled") || !download_mode)
 		qcom_scm_disable_sdi();
 
 	ret = of_reserved_mem_device_init(__scm->dev);