[PATCH] soc: qcom: pmic_glink_altmode: Print error when retimer setup fails

[PATCH] soc: qcom: pmic_glink_altmode: Print error when retimer setup fails

[Luca Weiss]

It can be useful to know with which return value the retimer_set call
failed, so include this info in the dev_err print.

Signed-off-by: Luca Weiss <luca.weiss@fairphone.com>
---
 drivers/soc/qcom/pmic_glink_altmode.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/soc/qcom/pmic_glink_altmode.c b/drivers/soc/qcom/pmic_glink_altmode.c
index 9569d999391d..136713e1155e 100644
--- a/drivers/soc/qcom/pmic_glink_altmode.c
+++ b/drivers/soc/qcom/pmic_glink_altmode.c
@@ -168,7 +168,7 @@ static void pmic_glink_altmode_enable_dp(struct pmic_glink_altmode *altmode,
 
 	ret = typec_retimer_set(port->typec_retimer, &port->retimer_state);
 	if (ret)
-		dev_err(altmode->dev, "failed to setup retimer to DP\n");
+		dev_err(altmode->dev, "failed to setup retimer to DP: %d\n", ret);
 }
 
 static void pmic_glink_altmode_enable_usb(struct pmic_glink_altmode *altmode,

---
base-commit: e3b18f7200f45d66f7141136c25554ac1e82009b
change-id: 20231013-glink-altmode-ret-3911e6c1eab5

Best regards,
-- 
Luca Weiss <luca.weiss@fairphone.com>

Re: [PATCH] soc: qcom: pmic_glink_altmode: Print error when retimer setup fails

[Konrad Dybcio]

On 13.10.2023 15:56, Luca Weiss wrote:
> It can be useful to know with which return value the retimer_set call
> failed, so include this info in the dev_err print.
> 
> Signed-off-by: Luca Weiss <luca.weiss@fairphone.com>
> ---
Reviewed-by: Konrad Dybcio <konrad.dybcio@linaro.org>

Konrad

Re: [PATCH] soc: qcom: pmic_glink_altmode: Print error when retimer setup fails

[Bjorn Andersson]

On Fri, Oct 13, 2023 at 03:56:40PM +0200, Luca Weiss wrote:
> It can be useful to know with which return value the retimer_set call
> failed, so include this info in the dev_err print.
> 

Is this useful during development, or during normal execution etc. How
about using kretprobe or similar tools?


If you insist, could you please make sure that the style matches across
the various typec_*_set() calls in the driver?

Regards,
Bjorn

> Signed-off-by: Luca Weiss <luca.weiss@fairphone.com>
> ---
>  drivers/soc/qcom/pmic_glink_altmode.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/soc/qcom/pmic_glink_altmode.c b/drivers/soc/qcom/pmic_glink_altmode.c
> index 9569d999391d..136713e1155e 100644
> --- a/drivers/soc/qcom/pmic_glink_altmode.c
> +++ b/drivers/soc/qcom/pmic_glink_altmode.c
> @@ -168,7 +168,7 @@ static void pmic_glink_altmode_enable_dp(struct pmic_glink_altmode *altmode,
>  
>  	ret = typec_retimer_set(port->typec_retimer, &port->retimer_state);
>  	if (ret)
> -		dev_err(altmode->dev, "failed to setup retimer to DP\n");
> +		dev_err(altmode->dev, "failed to setup retimer to DP: %d\n", ret);
>  }
>  
>  static void pmic_glink_altmode_enable_usb(struct pmic_glink_altmode *altmode,
> 
> ---
> base-commit: e3b18f7200f45d66f7141136c25554ac1e82009b
> change-id: 20231013-glink-altmode-ret-3911e6c1eab5
> 
> Best regards,
> -- 
> Luca Weiss <luca.weiss@fairphone.com>
> 

Re: [PATCH] soc: qcom: pmic_glink_altmode: Print error when retimer setup fails

[Luca Weiss]

On Mon Oct 16, 2023 at 5:18 AM CEST, Bjorn Andersson wrote:
> On Fri, Oct 13, 2023 at 03:56:40PM +0200, Luca Weiss wrote:
> > It can be useful to know with which return value the retimer_set call
> > failed, so include this info in the dev_err print.
> > 
>
> Is this useful during development, or during normal execution etc. How
> about using kretprobe or similar tools?

Hi Bjorn,

IIRC I encountered this during development of my retimer driver, where
the op in that driver failed for some reason and it was very useful to
get the return value to debug that.

And sure, I guess kretprobe might be also useful here but I think it's
very common to include the return value in the error message when
something fails, no?

> If you insist, could you please make sure that the style matches across
> the various typec_*_set() calls in the driver?

Do you mean adding the return value to the other dev_err prints after
typec_*_set() calls also?

Regards
Luca

>
> Regards,
> Bjorn
>
> > Signed-off-by: Luca Weiss <luca.weiss@fairphone.com>
> > ---
> >  drivers/soc/qcom/pmic_glink_altmode.c | 2 +-
> >  1 file changed, 1 insertion(+), 1 deletion(-)
> > 
> > diff --git a/drivers/soc/qcom/pmic_glink_altmode.c b/drivers/soc/qcom/pmic_glink_altmode.c
> > index 9569d999391d..136713e1155e 100644
> > --- a/drivers/soc/qcom/pmic_glink_altmode.c
> > +++ b/drivers/soc/qcom/pmic_glink_altmode.c
> > @@ -168,7 +168,7 @@ static void pmic_glink_altmode_enable_dp(struct pmic_glink_altmode *altmode,
> >  
> >  	ret = typec_retimer_set(port->typec_retimer, &port->retimer_state);
> >  	if (ret)
> > -		dev_err(altmode->dev, "failed to setup retimer to DP\n");
> > +		dev_err(altmode->dev, "failed to setup retimer to DP: %d\n", ret);
> >  }
> >  
> >  static void pmic_glink_altmode_enable_usb(struct pmic_glink_altmode *altmode,
> > 
> > ---
> > base-commit: e3b18f7200f45d66f7141136c25554ac1e82009b
> > change-id: 20231013-glink-altmode-ret-3911e6c1eab5
> > 
> > Best regards,
> > -- 
> > Luca Weiss <luca.weiss@fairphone.com>
> > 

Re: [PATCH] soc: qcom: pmic_glink_altmode: Print error when retimer setup fails

[Bjorn Andersson]

On Mon, Oct 16, 2023 at 08:56:31AM +0200, Luca Weiss wrote:
> On Mon Oct 16, 2023 at 5:18 AM CEST, Bjorn Andersson wrote:
> > On Fri, Oct 13, 2023 at 03:56:40PM +0200, Luca Weiss wrote:
> > > It can be useful to know with which return value the retimer_set call
> > > failed, so include this info in the dev_err print.
> > > 
> >
> > Is this useful during development, or during normal execution etc. How
> > about using kretprobe or similar tools?
> 
> Hi Bjorn,
> 
> IIRC I encountered this during development of my retimer driver, where
> the op in that driver failed for some reason and it was very useful to
> get the return value to debug that.
> 
> And sure, I guess kretprobe might be also useful here but I think it's
> very common to include the return value in the error message when
> something fails, no?
> 

The problem with the error message is that you often get some generic
error code, but don't know where it came from anyway. So, I typically
use function_graph and set_graph_function to capture the path through
the called function(s)...

But that said, it is fairly common to include the error value, so I am
not against it.

> > If you insist, could you please make sure that the style matches across
> > the various typec_*_set() calls in the driver?
> 
> Do you mean adding the return value to the other dev_err prints after
> typec_*_set() calls also?
> 

I mean that we should be consistent across the error prints, and either
include the error value in all or none of the typec error prints.

Regards,
Bjorn