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@xxxxxxxxxxxxx> > > --- > > 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@xxxxxxxxxxxxx> > >
