| Message ID | 1458005918-7893-1-git-send-email-javier@osg.samsung.com (mailing list archive) |
|---|---|
| State | Not Applicable, archived |
| Headers | show |
On 15.03.2016 10:38, Javier Martinez Canillas wrote: > The clock and source clock looked up by the driver may not be available > just because the clock controller driver was not probed yet so printing > an error in this case is not correct and only adds confusion to users. > > However, knowing that a driver's probe was deferred may be useful so it > can be printed as a debug information. > > Signed-off-by: Javier Martinez Canillas <javier@osg.samsung.com> > > --- > > Changes in v3: > - Change debug messages again as suggested by Joe Perches. > > Changes in v2: > - Improve debug messages as suggested by Joe Perches. > > drivers/rtc/rtc-s3c.c | 19 ++++++++++++++----- > 1 file changed, 14 insertions(+), 5 deletions(-) > > diff --git a/drivers/rtc/rtc-s3c.c b/drivers/rtc/rtc-s3c.c > index ffb860d18701..d01ad7e8078e 100644 > --- a/drivers/rtc/rtc-s3c.c > +++ b/drivers/rtc/rtc-s3c.c > @@ -501,18 +501,27 @@ static int s3c_rtc_probe(struct platform_device *pdev) > > info->rtc_clk = devm_clk_get(&pdev->dev, "rtc"); > if (IS_ERR(info->rtc_clk)) { > - dev_err(&pdev->dev, "failed to find rtc clock\n"); > - return PTR_ERR(info->rtc_clk); > + ret = PTR_ERR(info->rtc_clk); > + if (ret != -EPROBE_DEFER) > + dev_err(&pdev->dev, "failed to find rtc clock\n"); > + else > + dev_dbg(&pdev->dev, "probe deferred due to missing rtc clk\n"); > + return ret; > } > clk_prepare_enable(info->rtc_clk); > > if (info->data->needs_src_clk) { > info->rtc_src_clk = devm_clk_get(&pdev->dev, "rtc_src"); > if (IS_ERR(info->rtc_src_clk)) { > - dev_err(&pdev->dev, > - "failed to find rtc source clock\n"); > + ret = PTR_ERR(info->rtc_src_clk); > + if (ret != -EPROBE_DEFER) > + dev_err(&pdev->dev, > + "failed to find rtc source clock\n"); > + else > + dev_dbg(&pdev->dev, > + "probe deferred due to missing rtc src clk\n"); > clk_disable_unprepare(info->rtc_clk); > - return PTR_ERR(info->rtc_src_clk); > + return ret; > } > clk_prepare_enable(info->rtc_src_clk); > } > The error path starts looking complicated. This has now 4 indentation levels... I agree for removal of error in case of probe deferral because it might be misleading but I don't see much benefit of a debug message. Best regards, Krzysztof -- To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Hello Krzysztof, On 03/14/2016 10:50 PM, Krzysztof Kozlowski wrote: > On 15.03.2016 10:38, Javier Martinez Canillas wrote: >> The clock and source clock looked up by the driver may not be available >> just because the clock controller driver was not probed yet so printing >> an error in this case is not correct and only adds confusion to users. >> >> However, knowing that a driver's probe was deferred may be useful so it >> can be printed as a debug information. >> >> Signed-off-by: Javier Martinez Canillas <javier@osg.samsung.com> >> >> --- >> >> Changes in v3: >> - Change debug messages again as suggested by Joe Perches. >> >> Changes in v2: >> - Improve debug messages as suggested by Joe Perches. >> >> drivers/rtc/rtc-s3c.c | 19 ++++++++++++++----- >> 1 file changed, 14 insertions(+), 5 deletions(-) >> >> diff --git a/drivers/rtc/rtc-s3c.c b/drivers/rtc/rtc-s3c.c >> index ffb860d18701..d01ad7e8078e 100644 >> --- a/drivers/rtc/rtc-s3c.c >> +++ b/drivers/rtc/rtc-s3c.c >> @@ -501,18 +501,27 @@ static int s3c_rtc_probe(struct platform_device *pdev) >> >> info->rtc_clk = devm_clk_get(&pdev->dev, "rtc"); >> if (IS_ERR(info->rtc_clk)) { >> - dev_err(&pdev->dev, "failed to find rtc clock\n"); >> - return PTR_ERR(info->rtc_clk); >> + ret = PTR_ERR(info->rtc_clk); >> + if (ret != -EPROBE_DEFER) >> + dev_err(&pdev->dev, "failed to find rtc clock\n"); >> + else >> + dev_dbg(&pdev->dev, "probe deferred due to missing rtc clk\n"); >> + return ret; >> } >> clk_prepare_enable(info->rtc_clk); >> >> if (info->data->needs_src_clk) { >> info->rtc_src_clk = devm_clk_get(&pdev->dev, "rtc_src"); >> if (IS_ERR(info->rtc_src_clk)) { >> - dev_err(&pdev->dev, >> - "failed to find rtc source clock\n"); >> + ret = PTR_ERR(info->rtc_src_clk); >> + if (ret != -EPROBE_DEFER) >> + dev_err(&pdev->dev, >> + "failed to find rtc source clock\n"); >> + else >> + dev_dbg(&pdev->dev, >> + "probe deferred due to missing rtc src clk\n"); >> clk_disable_unprepare(info->rtc_clk); >> - return PTR_ERR(info->rtc_src_clk); >> + return ret; >> } >> clk_prepare_enable(info->rtc_src_clk); >> } >> > > The error path starts looking complicated. This has now 4 indentation > levels... > Yeah, I don't think we can get rid of the 4 indentation levels since the function already has 3 and a check for the errno code is needed. > I agree for removal of error in case of probe deferral because it might > be misleading but I don't see much benefit of a debug message. > But yes, we can at least get rid of the else statement. I don't have a strong opinion about the debug information, I left it to avoid someone to tell me that I was removing a useful log. > Best regards, > Krzysztof > Best regards,
On 15.03.2016 10:59, Javier Martinez Canillas wrote: > Hello Krzysztof, > > On 03/14/2016 10:50 PM, Krzysztof Kozlowski wrote: >> On 15.03.2016 10:38, Javier Martinez Canillas wrote: >>> The clock and source clock looked up by the driver may not be available >>> just because the clock controller driver was not probed yet so printing >>> an error in this case is not correct and only adds confusion to users. >>> >>> However, knowing that a driver's probe was deferred may be useful so it >>> can be printed as a debug information. >>> >>> Signed-off-by: Javier Martinez Canillas <javier@osg.samsung.com> >>> >>> --- >>> >>> Changes in v3: >>> - Change debug messages again as suggested by Joe Perches. >>> >>> Changes in v2: >>> - Improve debug messages as suggested by Joe Perches. >>> >>> drivers/rtc/rtc-s3c.c | 19 ++++++++++++++----- >>> 1 file changed, 14 insertions(+), 5 deletions(-) >>> >>> diff --git a/drivers/rtc/rtc-s3c.c b/drivers/rtc/rtc-s3c.c >>> index ffb860d18701..d01ad7e8078e 100644 >>> --- a/drivers/rtc/rtc-s3c.c >>> +++ b/drivers/rtc/rtc-s3c.c >>> @@ -501,18 +501,27 @@ static int s3c_rtc_probe(struct platform_device *pdev) >>> >>> info->rtc_clk = devm_clk_get(&pdev->dev, "rtc"); >>> if (IS_ERR(info->rtc_clk)) { >>> - dev_err(&pdev->dev, "failed to find rtc clock\n"); >>> - return PTR_ERR(info->rtc_clk); >>> + ret = PTR_ERR(info->rtc_clk); >>> + if (ret != -EPROBE_DEFER) >>> + dev_err(&pdev->dev, "failed to find rtc clock\n"); >>> + else >>> + dev_dbg(&pdev->dev, "probe deferred due to missing rtc clk\n"); >>> + return ret; >>> } >>> clk_prepare_enable(info->rtc_clk); >>> >>> if (info->data->needs_src_clk) { >>> info->rtc_src_clk = devm_clk_get(&pdev->dev, "rtc_src"); >>> if (IS_ERR(info->rtc_src_clk)) { >>> - dev_err(&pdev->dev, >>> - "failed to find rtc source clock\n"); >>> + ret = PTR_ERR(info->rtc_src_clk); >>> + if (ret != -EPROBE_DEFER) >>> + dev_err(&pdev->dev, >>> + "failed to find rtc source clock\n"); >>> + else >>> + dev_dbg(&pdev->dev, >>> + "probe deferred due to missing rtc src clk\n"); >>> clk_disable_unprepare(info->rtc_clk); >>> - return PTR_ERR(info->rtc_src_clk); >>> + return ret; >>> } >>> clk_prepare_enable(info->rtc_src_clk); >>> } >>> >> >> The error path starts looking complicated. This has now 4 indentation >> levels... >> > > Yeah, I don't think we can get rid of the 4 indentation levels since > the function already has 3 and a check for the errno code is needed. Probably handling of the clocks in the driver could be simplified a little bit (the if(needs_src_clk) appears in few places)... but this is out of scope for this patch. > >> I agree for removal of error in case of probe deferral because it might >> be misleading but I don't see much benefit of a debug message. >> > > But yes, we can at least get rid of the else statement. I don't have a > strong opinion about the debug information, I left it to avoid someone > to tell me that I was removing a useful log. Although dev_dbg doesn't harm... but isn't driver core printing debug message already? BR, Krzysztof -- To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Hello Krzysztof, On 03/14/2016 11:26 PM, Krzysztof Kozlowski wrote: > On 15.03.2016 10:59, Javier Martinez Canillas wrote: >>>> >>>> if (info->data->needs_src_clk) { >>>> info->rtc_src_clk = devm_clk_get(&pdev->dev, "rtc_src"); >>>> if (IS_ERR(info->rtc_src_clk)) { >>>> - dev_err(&pdev->dev, >>>> - "failed to find rtc source clock\n"); >>>> + ret = PTR_ERR(info->rtc_src_clk); >>>> + if (ret != -EPROBE_DEFER) >>>> + dev_err(&pdev->dev, >>>> + "failed to find rtc source clock\n"); >>>> + else >>>> + dev_dbg(&pdev->dev, >>>> + "probe deferred due to missing rtc src clk\n"); >>>> clk_disable_unprepare(info->rtc_clk); >>>> - return PTR_ERR(info->rtc_src_clk); >>>> + return ret; >>>> } >>>> clk_prepare_enable(info->rtc_src_clk); >>>> } >>>> >>> >>> The error path starts looking complicated. This has now 4 indentation >>> levels... >>> >> >> Yeah, I don't think we can get rid of the 4 indentation levels since >> the function already has 3 and a check for the errno code is needed. > > Probably handling of the clocks in the driver could be simplified a > little bit (the if(needs_src_clk) appears in few places)... but this is > out of scope for this patch. > Agreed, I meant without introducing an unrelated change. >> >>> I agree for removal of error in case of probe deferral because it might >>> be misleading but I don't see much benefit of a debug message. >>> >> >> But yes, we can at least get rid of the else statement. I don't have a >> strong opinion about the debug information, I left it to avoid someone >> to tell me that I was removing a useful log. > > Although dev_dbg doesn't harm... but isn't driver core printing debug > message already? > I don't think it does or at least I didn't find it when looking at the devm_clk_get() call chain. > BR, > Krzysztof > Best regards,
Hello Krzysztof and Alexandre, On 03/14/2016 11:58 PM, Javier Martinez Canillas wrote: > Hello Krzysztof, > > On 03/14/2016 11:26 PM, Krzysztof Kozlowski wrote: >> On 15.03.2016 10:59, Javier Martinez Canillas wrote: >>>>> >>>>> if (info->data->needs_src_clk) { >>>>> info->rtc_src_clk = devm_clk_get(&pdev->dev, "rtc_src"); >>>>> if (IS_ERR(info->rtc_src_clk)) { >>>>> - dev_err(&pdev->dev, >>>>> - "failed to find rtc source clock\n"); >>>>> + ret = PTR_ERR(info->rtc_src_clk); >>>>> + if (ret != -EPROBE_DEFER) >>>>> + dev_err(&pdev->dev, >>>>> + "failed to find rtc source clock\n"); >>>>> + else >>>>> + dev_dbg(&pdev->dev, >>>>> + "probe deferred due to missing rtc src clk\n"); >>>>> clk_disable_unprepare(info->rtc_clk); >>>>> - return PTR_ERR(info->rtc_src_clk); >>>>> + return ret; >>>>> } >>>>> clk_prepare_enable(info->rtc_src_clk); >>>>> } >>>>> >>>> >>>> The error path starts looking complicated. This has now 4 indentation >>>> levels... >>>> >>> >>> Yeah, I don't think we can get rid of the 4 indentation levels since >>> the function already has 3 and a check for the errno code is needed. >> >> Probably handling of the clocks in the driver could be simplified a >> little bit (the if(needs_src_clk) appears in few places)... but this is >> out of scope for this patch. >> > > Agreed, I meant without introducing an unrelated change. > >>> >>>> I agree for removal of error in case of probe deferral because it might >>>> be misleading but I don't see much benefit of a debug message. >>>> >>> >>> But yes, we can at least get rid of the else statement. I don't have a >>> strong opinion about the debug information, I left it to avoid someone >>> to tell me that I was removing a useful log. >> >> Although dev_dbg doesn't harm... but isn't driver core printing debug >> message already? >> > > I don't think it does or at least I didn't find it when looking > at the devm_clk_get() call chain. > >> BR, >> Krzysztof >> Just to make sure that I understood correctly, there's no action I should take in order for this patch to be picked right? IOW, the current version is OK? Best regards,
On 18/03/2016 at 08:57:57 -0300, Javier Martinez Canillas wrote : > >>> But yes, we can at least get rid of the else statement. I don't have a > >>> strong opinion about the debug information, I left it to avoid someone > >>> to tell me that I was removing a useful log. > >> > >> Although dev_dbg doesn't harm... but isn't driver core printing debug > >> message already? > >> > > > > I don't think it does or at least I didn't find it when looking > > at the devm_clk_get() call chain. > > > >> BR, > >> Krzysztof > >> > > Just to make sure that I understood correctly, there's no action I > should take in order for this patch to be picked right? IOW, the > current version is OK? > I was kind of waiting an answer on the question whether the core already prints a message when probe dereferral happens because in that case, there is no need for a debug message and we can indeed simplify the whole block.
On Fri, Mar 18, 2016 at 9:07 PM, Alexandre Belloni <alexandre.belloni@free-electrons.com> wrote: > On 18/03/2016 at 08:57:57 -0300, Javier Martinez Canillas wrote : >> >>> But yes, we can at least get rid of the else statement. I don't have a >> >>> strong opinion about the debug information, I left it to avoid someone >> >>> to tell me that I was removing a useful log. >> >> >> >> Although dev_dbg doesn't harm... but isn't driver core printing debug >> >> message already? >> >> >> > >> > I don't think it does or at least I didn't find it when looking >> > at the devm_clk_get() call chain. >> > >> >> BR, >> >> Krzysztof >> >> >> >> Just to make sure that I understood correctly, there's no action I >> should take in order for this patch to be picked right? IOW, the >> current version is OK? >> > > I was kind of waiting an answer on the question whether the core already > prints a message when probe dereferral happens because in that case, > there is no need for a debug message and we can indeed simplify the > whole block. Although I did not test it, I think the core will print generic defer message. See really_probe() around line 400: http://lxr.free-electrons.com/source/drivers/base/dd.c?v=4.4#L347 However the cause of deferring will not be printed... so I find some use of debug message in driver... On the other hand, not many drivers are doing this. Ehh, I guess I am just really picky. :) BR, Krzysztof -- To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On 18/03/2016 at 13:07:17 +0100, Alexandre Belloni wrote : > On 18/03/2016 at 08:57:57 -0300, Javier Martinez Canillas wrote : > > >>> But yes, we can at least get rid of the else statement. I don't have a > > >>> strong opinion about the debug information, I left it to avoid someone > > >>> to tell me that I was removing a useful log. > > >> > > >> Although dev_dbg doesn't harm... but isn't driver core printing debug > > >> message already? > > >> > > > > > > I don't think it does or at least I didn't find it when looking > > > at the devm_clk_get() call chain. > > > > > >> BR, > > >> Krzysztof > > >> > > > > Just to make sure that I understood correctly, there's no action I > > should take in order for this patch to be picked right? IOW, the > > current version is OK? > > > > I was kind of waiting an answer on the question whether the core already > prints a message when probe dereferral happens because in that case, > there is no need for a debug message and we can indeed simplify the > whole block. Ok, I've found the recent commit 13fcffbbdec4e4863a9a9c7792b821cd6d363a8f I'll take the patch as is.
Hello Alexandre, On 03/18/2016 10:03 AM, Alexandre Belloni wrote: > On 18/03/2016 at 13:07:17 +0100, Alexandre Belloni wrote : >> On 18/03/2016 at 08:57:57 -0300, Javier Martinez Canillas wrote : >>>>>> But yes, we can at least get rid of the else statement. I don't have a >>>>>> strong opinion about the debug information, I left it to avoid someone >>>>>> to tell me that I was removing a useful log. >>>>> >>>>> Although dev_dbg doesn't harm... but isn't driver core printing debug >>>>> message already? >>>>> >>>> >>>> I don't think it does or at least I didn't find it when looking >>>> at the devm_clk_get() call chain. >>>> >>>>> BR, >>>>> Krzysztof >>>>> >>> >>> Just to make sure that I understood correctly, there's no action I >>> should take in order for this patch to be picked right? IOW, the >>> current version is OK? >>> >> >> I was kind of waiting an answer on the question whether the core already >> prints a message when probe dereferral happens because in that case, >> there is no need for a debug message and we can indeed simplify the >> whole block. > > Ok, I've found the recent commit 13fcffbbdec4e4863a9a9c7792b821cd6d363a8f > > I'll take the patch as is. > > Great, thanks! Best regards,
Hello Krzysztof, On 03/18/2016 09:20 AM, Krzysztof Kozlowski wrote: > On Fri, Mar 18, 2016 at 9:07 PM, Alexandre Belloni >> On 18/03/2016 at 08:57:57 -0300, Javier Martinez Canillas wrote : [snip] >>> >>> Just to make sure that I understood correctly, there's no action I >>> should take in order for this patch to be picked right? IOW, the >>> current version is OK? >>> >> >> I was kind of waiting an answer on the question whether the core already >> prints a message when probe dereferral happens because in that case, >> there is no need for a debug message and we can indeed simplify the >> whole block. > > Although I did not test it, I think the core will print generic defer > message. See really_probe() around line 400: > http://lxr.free-electrons.com/source/drivers/base/dd.c?v=4.4#L347 > > However the cause of deferring will not be printed... so I find some > use of debug message in driver... On the other hand, not many drivers > are doing this. Ehh, I guess I am just really picky. :) > It's Ok, I also have doubts about which direction to take even when writing trivial patches like $SUBJECT, so I understand the feeling :) > BR, > Krzysztof > Best regards,
On 14/03/2016 at 22:38:38 -0300, Javier Martinez Canillas wrote : > The clock and source clock looked up by the driver may not be available > just because the clock controller driver was not probed yet so printing > an error in this case is not correct and only adds confusion to users. > > However, knowing that a driver's probe was deferred may be useful so it > can be printed as a debug information. > > Signed-off-by: Javier Martinez Canillas <javier@osg.samsung.com> > > --- > > Changes in v3: > - Change debug messages again as suggested by Joe Perches. > > Changes in v2: > - Improve debug messages as suggested by Joe Perches. > > drivers/rtc/rtc-s3c.c | 19 ++++++++++++++----- > 1 file changed, 14 insertions(+), 5 deletions(-) > Applied, thanks.
diff --git a/drivers/rtc/rtc-s3c.c b/drivers/rtc/rtc-s3c.c index ffb860d18701..d01ad7e8078e 100644 --- a/drivers/rtc/rtc-s3c.c +++ b/drivers/rtc/rtc-s3c.c @@ -501,18 +501,27 @@ static int s3c_rtc_probe(struct platform_device *pdev) info->rtc_clk = devm_clk_get(&pdev->dev, "rtc"); if (IS_ERR(info->rtc_clk)) { - dev_err(&pdev->dev, "failed to find rtc clock\n"); - return PTR_ERR(info->rtc_clk); + ret = PTR_ERR(info->rtc_clk); + if (ret != -EPROBE_DEFER) + dev_err(&pdev->dev, "failed to find rtc clock\n"); + else + dev_dbg(&pdev->dev, "probe deferred due to missing rtc clk\n"); + return ret; } clk_prepare_enable(info->rtc_clk); if (info->data->needs_src_clk) { info->rtc_src_clk = devm_clk_get(&pdev->dev, "rtc_src"); if (IS_ERR(info->rtc_src_clk)) { - dev_err(&pdev->dev, - "failed to find rtc source clock\n"); + ret = PTR_ERR(info->rtc_src_clk); + if (ret != -EPROBE_DEFER) + dev_err(&pdev->dev, + "failed to find rtc source clock\n"); + else + dev_dbg(&pdev->dev, + "probe deferred due to missing rtc src clk\n"); clk_disable_unprepare(info->rtc_clk); - return PTR_ERR(info->rtc_src_clk); + return ret; } clk_prepare_enable(info->rtc_src_clk); }
The clock and source clock looked up by the driver may not be available just because the clock controller driver was not probed yet so printing an error in this case is not correct and only adds confusion to users. However, knowing that a driver's probe was deferred may be useful so it can be printed as a debug information. Signed-off-by: Javier Martinez Canillas <javier@osg.samsung.com> --- Changes in v3: - Change debug messages again as suggested by Joe Perches. Changes in v2: - Improve debug messages as suggested by Joe Perches. drivers/rtc/rtc-s3c.c | 19 ++++++++++++++----- 1 file changed, 14 insertions(+), 5 deletions(-)