* [rtc-linux] [PATCH] rtc: s3c: Don't print an error on probe deferral @ 2016-03-14 19:05 ` Javier Martinez Canillas 0 siblings, 0 replies; 20+ messages in thread From: Javier Martinez Canillas @ 2016-03-14 19:05 UTC (permalink / raw) To: linux-kernel Cc: Alexandre Belloni, linux-samsung-soc, Krzysztof Kozlowski, rtc-linux, Javier Martinez Canillas 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 debug information. Signed-off-by: Javier Martinez Canillas <javier@osg.samsung.com> --- 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..789ac8715038 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 rtc clock\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 rtc source clock\n"); clk_disable_unprepare(info->rtc_clk); - return PTR_ERR(info->rtc_src_clk); + return ret; } clk_prepare_enable(info->rtc_src_clk); } -- 2.5.0 -- -- You received this message because you are subscribed to "rtc-linux". Membership options at http://groups.google.com/group/rtc-linux . Please read http://groups.google.com/group/rtc-linux/web/checklist before submitting a driver. --- You received this message because you are subscribed to the Google Groups "rtc-linux" group. To unsubscribe from this group and stop receiving emails from it, send an email to rtc-linux+unsubscribe@googlegroups.com. For more options, visit https://groups.google.com/d/optout. ^ permalink raw reply related [flat|nested] 20+ messages in thread
* [PATCH] rtc: s3c: Don't print an error on probe deferral @ 2016-03-14 19:05 ` Javier Martinez Canillas 0 siblings, 0 replies; 20+ messages in thread From: Javier Martinez Canillas @ 2016-03-14 19:05 UTC (permalink / raw) To: linux-kernel Cc: Alexandre Belloni, linux-samsung-soc, Krzysztof Kozlowski, rtc-linux, Javier Martinez Canillas 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 debug information. Signed-off-by: Javier Martinez Canillas <javier@osg.samsung.com> --- 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..789ac8715038 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 rtc clock\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 rtc source clock\n"); clk_disable_unprepare(info->rtc_clk); - return PTR_ERR(info->rtc_src_clk); + return ret; } clk_prepare_enable(info->rtc_src_clk); } -- 2.5.0 ^ permalink raw reply related [flat|nested] 20+ messages in thread
* [rtc-linux] Re: [PATCH] rtc: s3c: Don't print an error on probe deferral 2016-03-14 19:05 ` Javier Martinez Canillas @ 2016-03-14 19:11 ` Joe Perches -1 siblings, 0 replies; 20+ messages in thread From: Joe Perches @ 2016-03-14 19:11 UTC (permalink / raw) To: Javier Martinez Canillas, linux-kernel Cc: Alexandre Belloni, linux-samsung-soc, Krzysztof Kozlowski, rtc-linux On Mon, 2016-03-14 at 16:05 -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. >=20 > However, knowing that a driver's probe was deferred may be useful so it > can be printed as debug information. [] > diff --git a/drivers/rtc/rtc-s3c.c b/drivers/rtc/rtc-s3c.c [] > @@ -501,18 +501,27 @@ static int s3c_rtc_probe(struct platform_device *pd= ev) > =C2=A0 > =C2=A0 info->rtc_clk =3D devm_clk_get(&pdev->dev, "rtc"); > =C2=A0 if (IS_ERR(info->rtc_clk)) { > - dev_err(&pdev->dev, "failed to find rtc clock\n"); > - return PTR_ERR(info->rtc_clk); > + ret =3D PTR_ERR(info->rtc_clk); > + if (ret !=3D -EPROBE_DEFER) > + dev_err(&pdev->dev, "failed to find rtc clock\n"); > + else > + dev_dbg(&pdev->dev, "probe deferred due rtc clock\n"); > + return ret; > =C2=A0 } > =C2=A0 clk_prepare_enable(info->rtc_clk); > =C2=A0 > =C2=A0 if (info->data->needs_src_clk) { > =C2=A0 info->rtc_src_clk =3D devm_clk_get(&pdev->dev, "rtc_src"); > =C2=A0 if (IS_ERR(info->rtc_src_clk)) { > - dev_err(&pdev->dev, > - "failed to find rtc source clock\n"); > + ret =3D PTR_ERR(info->rtc_src_clk); > + if (ret !=3D -EPROBE_DEFER) > + dev_err(&pdev->dev, > + "failed to find rtc source clock\n"); > + else > + dev_dbg(&pdev->dev, > + "probe deferred due rtc source clock\n"); > =C2=A0 clk_disable_unprepare(info->rtc_clk); > - return PTR_ERR(info->rtc_src_clk); > + return ret; > =C2=A0 } > =C2=A0 clk_prepare_enable(info->rtc_src_clk); > =C2=A0 } Maybe the debug logging messages could be object->action like: rtc clock probe deferred rtc source clock probe deferred --=20 --=20 You received this message because you are subscribed to "rtc-linux". Membership options at http://groups.google.com/group/rtc-linux . Please read http://groups.google.com/group/rtc-linux/web/checklist before submitting a driver. ---=20 You received this message because you are subscribed to the Google Groups "= rtc-linux" group. To unsubscribe from this group and stop receiving emails from it, send an e= mail to rtc-linux+unsubscribe@googlegroups.com. For more options, visit https://groups.google.com/d/optout. ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: [PATCH] rtc: s3c: Don't print an error on probe deferral @ 2016-03-14 19:11 ` Joe Perches 0 siblings, 0 replies; 20+ messages in thread From: Joe Perches @ 2016-03-14 19:11 UTC (permalink / raw) To: Javier Martinez Canillas, linux-kernel Cc: Alexandre Belloni, linux-samsung-soc, Krzysztof Kozlowski, rtc-linux On Mon, 2016-03-14 at 16:05 -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 debug information. [] > diff --git 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 rtc clock\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 rtc source clock\n"); > clk_disable_unprepare(info->rtc_clk); > - return PTR_ERR(info->rtc_src_clk); > + return ret; > } > clk_prepare_enable(info->rtc_src_clk); > } Maybe the debug logging messages could be object->action like: rtc clock probe deferred rtc source clock probe deferred ^ permalink raw reply [flat|nested] 20+ messages in thread
* [rtc-linux] Re: [PATCH] rtc: s3c: Don't print an error on probe deferral 2016-03-14 19:11 ` Joe Perches @ 2016-03-14 19:31 ` Javier Martinez Canillas -1 siblings, 0 replies; 20+ messages in thread From: Javier Martinez Canillas @ 2016-03-14 19:31 UTC (permalink / raw) To: Joe Perches, linux-kernel Cc: Alexandre Belloni, linux-samsung-soc, Krzysztof Kozlowski, rtc-linux Hello Joe, Thanks a lot for your feedback. On 03/14/2016 04:11 PM, Joe Perches wrote: > On Mon, 2016-03-14 at 16:05 -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 debug information. > [] >> diff --git 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 rtc clock\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 rtc source clock\n"); >> clk_disable_unprepare(info->rtc_clk); >> - return PTR_ERR(info->rtc_src_clk); >> + return ret; >> } >> clk_prepare_enable(info->rtc_src_clk); >> } > > Maybe the debug logging messages could be object->action like: > > rtc clock probe deferred > rtc source clock probe deferred > I found your suggested messages harder to read and more confusing. The action that happens is a probe function deferral and that is caused by a missing resource needed by the driver (clocks in this case). But your messages seems to imply that the probe deferred action happens to a clock, it sounds like "rtc clock disabled" and that's not correct. Best regards, -- Javier Martinez Canillas Open Source Group Samsung Research America -- -- You received this message because you are subscribed to "rtc-linux". Membership options at http://groups.google.com/group/rtc-linux . Please read http://groups.google.com/group/rtc-linux/web/checklist before submitting a driver. --- You received this message because you are subscribed to the Google Groups "rtc-linux" group. To unsubscribe from this group and stop receiving emails from it, send an email to rtc-linux+unsubscribe@googlegroups.com. For more options, visit https://groups.google.com/d/optout. ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: [PATCH] rtc: s3c: Don't print an error on probe deferral @ 2016-03-14 19:31 ` Javier Martinez Canillas 0 siblings, 0 replies; 20+ messages in thread From: Javier Martinez Canillas @ 2016-03-14 19:31 UTC (permalink / raw) To: Joe Perches, linux-kernel Cc: Alexandre Belloni, linux-samsung-soc, Krzysztof Kozlowski, rtc-linux Hello Joe, Thanks a lot for your feedback. On 03/14/2016 04:11 PM, Joe Perches wrote: > On Mon, 2016-03-14 at 16:05 -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 debug information. > [] >> diff --git 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 rtc clock\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 rtc source clock\n"); >> clk_disable_unprepare(info->rtc_clk); >> - return PTR_ERR(info->rtc_src_clk); >> + return ret; >> } >> clk_prepare_enable(info->rtc_src_clk); >> } > > Maybe the debug logging messages could be object->action like: > > rtc clock probe deferred > rtc source clock probe deferred > I found your suggested messages harder to read and more confusing. The action that happens is a probe function deferral and that is caused by a missing resource needed by the driver (clocks in this case). But your messages seems to imply that the probe deferred action happens to a clock, it sounds like "rtc clock disabled" and that's not correct. Best regards, -- Javier Martinez Canillas Open Source Group Samsung Research America ^ permalink raw reply [flat|nested] 20+ messages in thread
* [rtc-linux] Re: [PATCH] rtc: s3c: Don't print an error on probe deferral 2016-03-14 19:31 ` Javier Martinez Canillas @ 2016-03-14 19:38 ` Joe Perches -1 siblings, 0 replies; 20+ messages in thread From: Joe Perches @ 2016-03-14 19:38 UTC (permalink / raw) To: Javier Martinez Canillas, linux-kernel Cc: Alexandre Belloni, linux-samsung-soc, Krzysztof Kozlowski, rtc-linux On Mon, 2016-03-14 at 16:31 -0300, Javier Martinez Canillas wrote: > On 03/14/2016 04:11 PM, Joe Perches wrote:> > On Mon, 2016-03-14 at 16:05= -0300, Javier Martinez Canillas wrote: > > >=20 > > > The clock and source clock looked up by the driver may not be availab= le > > > just because the clock controller driver was not probed yet so printi= ng > > > an error in this case is not correct and only adds confusion to users= . > > >=20 > > > However, knowing that a driver's probe was deferred may be useful so = it > > > can be printed as debug information. > > [] > > >=20 > > > diff --git a/drivers/rtc/rtc-s3c.c b/drivers/rtc/rtc-s3c.c > > [] > > >=20 > > > @@ -501,18 +501,27 @@ static int s3c_rtc_probe(struct platform_device= *pdev) > > > =C2=A0 > > > =C2=A0 info->rtc_clk =3D devm_clk_get(&pdev->dev, "rtc"); > > > =C2=A0 if (IS_ERR(info->rtc_clk)) { > > > - dev_err(&pdev->dev, "failed to find rtc clock\n"); > > > - return PTR_ERR(info->rtc_clk); > > > + ret =3D PTR_ERR(info->rtc_clk); > > > + if (ret !=3D -EPROBE_DEFER) > > > + dev_err(&pdev->dev, "failed to find rtc clock\n"); > > > + else > > > + dev_dbg(&pdev->dev, "probe deferred due rtc clock\n"); > > > + return ret; > > > =C2=A0 } > > > =C2=A0 clk_prepare_enable(info->rtc_clk); > > > =C2=A0 > > > =C2=A0 if (info->data->needs_src_clk) { > > > =C2=A0 info->rtc_src_clk =3D devm_clk_get(&pdev->dev, "rtc_src"); > > > =C2=A0 if (IS_ERR(info->rtc_src_clk)) { > > > - dev_err(&pdev->dev, > > > - "failed to find rtc source clock\n"); > > > + ret =3D PTR_ERR(info->rtc_src_clk); > > > + if (ret !=3D -EPROBE_DEFER) > > > + dev_err(&pdev->dev, > > > + "failed to find rtc source clock\n"); > > > + else > > > + dev_dbg(&pdev->dev, > > > + "probe deferred due rtc source clock\n"); > > > =C2=A0 clk_disable_unprepare(info->rtc_clk); > > > - return PTR_ERR(info->rtc_src_clk); > > > + return ret; > > > =C2=A0 } > > > =C2=A0 clk_prepare_enable(info->rtc_src_clk); > > > =C2=A0 } > > Maybe the debug logging messages could be object->action like: > >=20 > > rtc clock probe deferred > > rtc source clock probe deferred > >=20 > I found your suggested messages harder to read and more confusing. The > action that happens is a probe function deferral and that is caused by > a missing resource needed by the driver (clocks in this case). >=20 > But your messages seems to imply that the probe deferred action happens > to a clock, it sounds like "rtc clock disabled" and that's not correct. OK, then please change "due" to "due to" or "for" in your messages because they make little sense now. --=20 --=20 You received this message because you are subscribed to "rtc-linux". Membership options at http://groups.google.com/group/rtc-linux . Please read http://groups.google.com/group/rtc-linux/web/checklist before submitting a driver. ---=20 You received this message because you are subscribed to the Google Groups "= rtc-linux" group. To unsubscribe from this group and stop receiving emails from it, send an e= mail to rtc-linux+unsubscribe@googlegroups.com. For more options, visit https://groups.google.com/d/optout. ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: [PATCH] rtc: s3c: Don't print an error on probe deferral @ 2016-03-14 19:38 ` Joe Perches 0 siblings, 0 replies; 20+ messages in thread From: Joe Perches @ 2016-03-14 19:38 UTC (permalink / raw) To: Javier Martinez Canillas, linux-kernel Cc: Alexandre Belloni, linux-samsung-soc, Krzysztof Kozlowski, rtc-linux On Mon, 2016-03-14 at 16:31 -0300, Javier Martinez Canillas wrote: > On 03/14/2016 04:11 PM, Joe Perches wrote:> > On Mon, 2016-03-14 at 16:05 -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 debug information. > > [] > > > > > > diff --git 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 rtc clock\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 rtc source clock\n"); > > > clk_disable_unprepare(info->rtc_clk); > > > - return PTR_ERR(info->rtc_src_clk); > > > + return ret; > > > } > > > clk_prepare_enable(info->rtc_src_clk); > > > } > > Maybe the debug logging messages could be object->action like: > > > > rtc clock probe deferred > > rtc source clock probe deferred > > > I found your suggested messages harder to read and more confusing. The > action that happens is a probe function deferral and that is caused by > a missing resource needed by the driver (clocks in this case). > > But your messages seems to imply that the probe deferred action happens > to a clock, it sounds like "rtc clock disabled" and that's not correct. OK, then please change "due" to "due to" or "for" in your messages because they make little sense now. ^ permalink raw reply [flat|nested] 20+ messages in thread
* [rtc-linux] Re: [PATCH] rtc: s3c: Don't print an error on probe deferral 2016-03-14 19:38 ` Joe Perches @ 2016-03-14 19:59 ` Javier Martinez Canillas -1 siblings, 0 replies; 20+ messages in thread From: Javier Martinez Canillas @ 2016-03-14 19:59 UTC (permalink / raw) To: Joe Perches, linux-kernel Cc: Alexandre Belloni, linux-samsung-soc, Krzysztof Kozlowski, rtc-linux Hello Joe, On 03/14/2016 04:38 PM, Joe Perches wrote: > On Mon, 2016-03-14 at 16:31 -0300, Javier Martinez Canillas wrote: >> On 03/14/2016 04:11 PM, Joe Perches wrote:> > On Mon, 2016-03-14 at 16:05 -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 debug information. >>> [] >>>> >>>> diff --git 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 rtc clock\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 rtc source clock\n"); >>>> clk_disable_unprepare(info->rtc_clk); >>>> - return PTR_ERR(info->rtc_src_clk); >>>> + return ret; >>>> } >>>> clk_prepare_enable(info->rtc_src_clk); >>>> } >>> Maybe the debug logging messages could be object->action like: >>> >>> rtc clock probe deferred >>> rtc source clock probe deferred >>> >> I found your suggested messages harder to read and more confusing. The >> action that happens is a probe function deferral and that is caused by >> a missing resource needed by the driver (clocks in this case). >> >> But your messages seems to imply that the probe deferred action happens >> to a clock, it sounds like "rtc clock disabled" and that's not correct. > > OK, then please change "due" to "due to" or "for" in your messages > because they make little sense now. > I don't think they make little sense now since even a non-native english speaker like me can understand it :) But yes, it's cryptic at the very least. That's the problem with long text and the 80 char limit to make checkpatch.pl happy. I guess I can just move the message a little bit even if that will make to not be properly aligned. I'll wait a couple of days to see if there's any other feedback and repost. Best regards, -- Javier Martinez Canillas Open Source Group Samsung Research America -- -- You received this message because you are subscribed to "rtc-linux". Membership options at http://groups.google.com/group/rtc-linux . Please read http://groups.google.com/group/rtc-linux/web/checklist before submitting a driver. --- You received this message because you are subscribed to the Google Groups "rtc-linux" group. To unsubscribe from this group and stop receiving emails from it, send an email to rtc-linux+unsubscribe@googlegroups.com. For more options, visit https://groups.google.com/d/optout. ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: [PATCH] rtc: s3c: Don't print an error on probe deferral @ 2016-03-14 19:59 ` Javier Martinez Canillas 0 siblings, 0 replies; 20+ messages in thread From: Javier Martinez Canillas @ 2016-03-14 19:59 UTC (permalink / raw) To: Joe Perches, linux-kernel Cc: Alexandre Belloni, linux-samsung-soc, Krzysztof Kozlowski, rtc-linux Hello Joe, On 03/14/2016 04:38 PM, Joe Perches wrote: > On Mon, 2016-03-14 at 16:31 -0300, Javier Martinez Canillas wrote: >> On 03/14/2016 04:11 PM, Joe Perches wrote:> > On Mon, 2016-03-14 at 16:05 -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 debug information. >>> [] >>>> >>>> diff --git 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 rtc clock\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 rtc source clock\n"); >>>> clk_disable_unprepare(info->rtc_clk); >>>> - return PTR_ERR(info->rtc_src_clk); >>>> + return ret; >>>> } >>>> clk_prepare_enable(info->rtc_src_clk); >>>> } >>> Maybe the debug logging messages could be object->action like: >>> >>> rtc clock probe deferred >>> rtc source clock probe deferred >>> >> I found your suggested messages harder to read and more confusing. The >> action that happens is a probe function deferral and that is caused by >> a missing resource needed by the driver (clocks in this case). >> >> But your messages seems to imply that the probe deferred action happens >> to a clock, it sounds like "rtc clock disabled" and that's not correct. > > OK, then please change "due" to "due to" or "for" in your messages > because they make little sense now. > I don't think they make little sense now since even a non-native english speaker like me can understand it :) But yes, it's cryptic at the very least. That's the problem with long text and the 80 char limit to make checkpatch.pl happy. I guess I can just move the message a little bit even if that will make to not be properly aligned. I'll wait a couple of days to see if there's any other feedback and repost. Best regards, -- Javier Martinez Canillas Open Source Group Samsung Research America ^ permalink raw reply [flat|nested] 20+ messages in thread
* [rtc-linux] Re: [PATCH] rtc: s3c: Don't print an error on probe deferral 2016-03-14 19:59 ` Javier Martinez Canillas @ 2016-03-14 20:03 ` Joe Perches -1 siblings, 0 replies; 20+ messages in thread From: Joe Perches @ 2016-03-14 20:03 UTC (permalink / raw) To: Javier Martinez Canillas, linux-kernel Cc: Alexandre Belloni, linux-samsung-soc, Krzysztof Kozlowski, rtc-linux On Mon, 2016-03-14 at 16:59 -0300, Javier Martinez Canillas wrote: > I don't think they make little sense now since even a non-native english > speaker like me can understand it :) That's a non sequitur if ever I read one. > But yes, it's cryptic at the very least. That's the problem with long tex= t > and the 80 char limit to make checkpatch.pl happy. I guess I can just mov= e > the message a little bit even if that will make to not be properly aligne= d. There's no issue with longer than 80 column lines for these messages. =C2=A0checkpatch wouldn't complain. --=20 --=20 You received this message because you are subscribed to "rtc-linux". Membership options at http://groups.google.com/group/rtc-linux . Please read http://groups.google.com/group/rtc-linux/web/checklist before submitting a driver. ---=20 You received this message because you are subscribed to the Google Groups "= rtc-linux" group. To unsubscribe from this group and stop receiving emails from it, send an e= mail to rtc-linux+unsubscribe@googlegroups.com. For more options, visit https://groups.google.com/d/optout. ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: [PATCH] rtc: s3c: Don't print an error on probe deferral @ 2016-03-14 20:03 ` Joe Perches 0 siblings, 0 replies; 20+ messages in thread From: Joe Perches @ 2016-03-14 20:03 UTC (permalink / raw) To: Javier Martinez Canillas, linux-kernel Cc: Alexandre Belloni, linux-samsung-soc, Krzysztof Kozlowski, rtc-linux On Mon, 2016-03-14 at 16:59 -0300, Javier Martinez Canillas wrote: > I don't think they make little sense now since even a non-native english > speaker like me can understand it :) That's a non sequitur if ever I read one. > But yes, it's cryptic at the very least. That's the problem with long text > and the 80 char limit to make checkpatch.pl happy. I guess I can just move > the message a little bit even if that will make to not be properly aligned. There's no issue with longer than 80 column lines for these messages. checkpatch wouldn't complain. ^ permalink raw reply [flat|nested] 20+ messages in thread
* [rtc-linux] Re: [PATCH] rtc: s3c: Don't print an error on probe deferral 2016-03-14 20:03 ` Joe Perches @ 2016-03-14 20:23 ` Javier Martinez Canillas -1 siblings, 0 replies; 20+ messages in thread From: Javier Martinez Canillas @ 2016-03-14 20:23 UTC (permalink / raw) To: Joe Perches, linux-kernel Cc: Alexandre Belloni, linux-samsung-soc, Krzysztof Kozlowski, rtc-linux Hello Joe, On 03/14/2016 05:03 PM, Joe Perches wrote: > On Mon, 2016-03-14 at 16:59 -0300, Javier Martinez Canillas wrote: >> I don't think they make little sense now since even a non-native english >> speaker like me can understand it :) > > That's a non sequitur if ever I read one. > I was trying to be funny but it seems that I failed. >> But yes, it's cryptic at the very least. That's the problem with long text >> and the 80 char limit to make checkpatch.pl happy. I guess I can just move >> the message a little bit even if that will make to not be properly aligned. > > There's no issue with longer than 80 column lines > for these messages. checkpatch wouldn't complain. > Great, I didn't know that checkpatch had an exception for the 80 column rule. I'll post a v2 then. Best regards, -- Javier Martinez Canillas Open Source Group Samsung Research America -- -- You received this message because you are subscribed to "rtc-linux". Membership options at http://groups.google.com/group/rtc-linux . Please read http://groups.google.com/group/rtc-linux/web/checklist before submitting a driver. --- You received this message because you are subscribed to the Google Groups "rtc-linux" group. To unsubscribe from this group and stop receiving emails from it, send an email to rtc-linux+unsubscribe@googlegroups.com. For more options, visit https://groups.google.com/d/optout. ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: [PATCH] rtc: s3c: Don't print an error on probe deferral @ 2016-03-14 20:23 ` Javier Martinez Canillas 0 siblings, 0 replies; 20+ messages in thread From: Javier Martinez Canillas @ 2016-03-14 20:23 UTC (permalink / raw) To: Joe Perches, linux-kernel Cc: Alexandre Belloni, linux-samsung-soc, Krzysztof Kozlowski, rtc-linux Hello Joe, On 03/14/2016 05:03 PM, Joe Perches wrote: > On Mon, 2016-03-14 at 16:59 -0300, Javier Martinez Canillas wrote: >> I don't think they make little sense now since even a non-native english >> speaker like me can understand it :) > > That's a non sequitur if ever I read one. > I was trying to be funny but it seems that I failed. >> But yes, it's cryptic at the very least. That's the problem with long text >> and the 80 char limit to make checkpatch.pl happy. I guess I can just move >> the message a little bit even if that will make to not be properly aligned. > > There's no issue with longer than 80 column lines > for these messages. checkpatch wouldn't complain. > Great, I didn't know that checkpatch had an exception for the 80 column rule. I'll post a v2 then. Best regards, -- Javier Martinez Canillas Open Source Group Samsung Research America ^ permalink raw reply [flat|nested] 20+ messages in thread
* [rtc-linux] Re: [PATCH] rtc: s3c: Don't print an error on probe deferral 2016-03-14 19:59 ` Javier Martinez Canillas @ 2016-03-14 20:19 ` Alexandre Belloni -1 siblings, 0 replies; 20+ messages in thread From: Alexandre Belloni @ 2016-03-14 20:19 UTC (permalink / raw) To: Javier Martinez Canillas Cc: Joe Perches, linux-kernel, linux-samsung-soc, Krzysztof Kozlowski, rtc-linux On 14/03/2016 at 16:59:33 -0300, Javier Martinez Canillas wrote : > Hello Joe, > > On 03/14/2016 04:38 PM, Joe Perches wrote: > > On Mon, 2016-03-14 at 16:31 -0300, Javier Martinez Canillas wrote: > >> On 03/14/2016 04:11 PM, Joe Perches wrote:> > On Mon, 2016-03-14 at 16:05 -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 debug information. > >>> [] > >>>> > >>>> diff --git 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 rtc clock\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 rtc source clock\n"); > >>>> clk_disable_unprepare(info->rtc_clk); > >>>> - return PTR_ERR(info->rtc_src_clk); > >>>> + return ret; > >>>> } > >>>> clk_prepare_enable(info->rtc_src_clk); > >>>> } > >>> Maybe the debug logging messages could be object->action like: > >>> > >>> rtc clock probe deferred > >>> rtc source clock probe deferred > >>> > >> I found your suggested messages harder to read and more confusing. The > >> action that happens is a probe function deferral and that is caused by > >> a missing resource needed by the driver (clocks in this case). > >> > >> But your messages seems to imply that the probe deferred action happens > >> to a clock, it sounds like "rtc clock disabled" and that's not correct. > > > > OK, then please change "due" to "due to" or "for" in your messages > > because they make little sense now. > > > > I don't think they make little sense now since even a non-native english > speaker like me can understand it :) > > But yes, it's cryptic at the very least. That's the problem with long text > and the 80 char limit to make checkpatch.pl happy. I guess I can just move > the message a little bit even if that will make to not be properly aligned. > checkpatch will not complain for messages but it will definitively complain if they are not properly aligned:) -- Alexandre Belloni, Free Electrons Embedded Linux, Kernel and Android engineering http://free-electrons.com -- -- You received this message because you are subscribed to "rtc-linux". Membership options at http://groups.google.com/group/rtc-linux . Please read http://groups.google.com/group/rtc-linux/web/checklist before submitting a driver. --- You received this message because you are subscribed to the Google Groups "rtc-linux" group. To unsubscribe from this group and stop receiving emails from it, send an email to rtc-linux+unsubscribe@googlegroups.com. For more options, visit https://groups.google.com/d/optout. ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: [PATCH] rtc: s3c: Don't print an error on probe deferral @ 2016-03-14 20:19 ` Alexandre Belloni 0 siblings, 0 replies; 20+ messages in thread From: Alexandre Belloni @ 2016-03-14 20:19 UTC (permalink / raw) To: Javier Martinez Canillas Cc: Joe Perches, linux-kernel, linux-samsung-soc, Krzysztof Kozlowski, rtc-linux On 14/03/2016 at 16:59:33 -0300, Javier Martinez Canillas wrote : > Hello Joe, > > On 03/14/2016 04:38 PM, Joe Perches wrote: > > On Mon, 2016-03-14 at 16:31 -0300, Javier Martinez Canillas wrote: > >> On 03/14/2016 04:11 PM, Joe Perches wrote:> > On Mon, 2016-03-14 at 16:05 -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 debug information. > >>> [] > >>>> > >>>> diff --git 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 rtc clock\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 rtc source clock\n"); > >>>> clk_disable_unprepare(info->rtc_clk); > >>>> - return PTR_ERR(info->rtc_src_clk); > >>>> + return ret; > >>>> } > >>>> clk_prepare_enable(info->rtc_src_clk); > >>>> } > >>> Maybe the debug logging messages could be object->action like: > >>> > >>> rtc clock probe deferred > >>> rtc source clock probe deferred > >>> > >> I found your suggested messages harder to read and more confusing. The > >> action that happens is a probe function deferral and that is caused by > >> a missing resource needed by the driver (clocks in this case). > >> > >> But your messages seems to imply that the probe deferred action happens > >> to a clock, it sounds like "rtc clock disabled" and that's not correct. > > > > OK, then please change "due" to "due to" or "for" in your messages > > because they make little sense now. > > > > I don't think they make little sense now since even a non-native english > speaker like me can understand it :) > > But yes, it's cryptic at the very least. That's the problem with long text > and the 80 char limit to make checkpatch.pl happy. I guess I can just move > the message a little bit even if that will make to not be properly aligned. > checkpatch will not complain for messages but it will definitively complain if they are not properly aligned:) -- Alexandre Belloni, Free Electrons Embedded Linux, Kernel and Android engineering http://free-electrons.com ^ permalink raw reply [flat|nested] 20+ messages in thread
* [rtc-linux] Re: [PATCH] rtc: s3c: Don't print an error on probe deferral 2016-03-14 20:19 ` Alexandre Belloni @ 2016-03-14 20:33 ` Joe Perches -1 siblings, 0 replies; 20+ messages in thread From: Joe Perches @ 2016-03-14 20:33 UTC (permalink / raw) To: Alexandre Belloni, Javier Martinez Canillas Cc: linux-kernel, linux-samsung-soc, Krzysztof Kozlowski, rtc-linux On Mon, 2016-03-14 at 21:19 +0100, Alexandre Belloni wrote: > checkpatch will not complain for messages but it will definitively > complain if they are not properly aligned:) checkpatch wouldn't actually complain unless the --strict option was used or these files were in drivers/net or drivers/staging. -- -- You received this message because you are subscribed to "rtc-linux". Membership options at http://groups.google.com/group/rtc-linux . Please read http://groups.google.com/group/rtc-linux/web/checklist before submitting a driver. --- You received this message because you are subscribed to the Google Groups "rtc-linux" group. To unsubscribe from this group and stop receiving emails from it, send an email to rtc-linux+unsubscribe@googlegroups.com. For more options, visit https://groups.google.com/d/optout. ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: [PATCH] rtc: s3c: Don't print an error on probe deferral @ 2016-03-14 20:33 ` Joe Perches 0 siblings, 0 replies; 20+ messages in thread From: Joe Perches @ 2016-03-14 20:33 UTC (permalink / raw) To: Alexandre Belloni, Javier Martinez Canillas Cc: linux-kernel, linux-samsung-soc, Krzysztof Kozlowski, rtc-linux On Mon, 2016-03-14 at 21:19 +0100, Alexandre Belloni wrote: > checkpatch will not complain for messages but it will definitively > complain if they are not properly aligned:) checkpatch wouldn't actually complain unless the --strict option was used or these files were in drivers/net or drivers/staging. ^ permalink raw reply [flat|nested] 20+ messages in thread
* [rtc-linux] Re: [PATCH] rtc: s3c: Don't print an error on probe deferral 2016-03-14 20:33 ` Joe Perches @ 2016-03-14 20:51 ` Alexandre Belloni -1 siblings, 0 replies; 20+ messages in thread From: Alexandre Belloni @ 2016-03-14 20:51 UTC (permalink / raw) To: Joe Perches Cc: Javier Martinez Canillas, linux-kernel, linux-samsung-soc, Krzysztof Kozlowski, rtc-linux On 14/03/2016 at 13:33:08 -0700, Joe Perches wrote : > On Mon, 2016-03-14 at 21:19 +0100, Alexandre Belloni wrote: > > checkpatch will not complain for messages but it will definitively > > complain if they are not properly aligned:) > > checkpatch wouldn't actually complain unless the --strict option > was used or these files were in drivers/net or drivers/staging. > yeah, I'm using --strict on all the patches I receive. -- Alexandre Belloni, Free Electrons Embedded Linux, Kernel and Android engineering http://free-electrons.com -- -- You received this message because you are subscribed to "rtc-linux". Membership options at http://groups.google.com/group/rtc-linux . Please read http://groups.google.com/group/rtc-linux/web/checklist before submitting a driver. --- You received this message because you are subscribed to the Google Groups "rtc-linux" group. To unsubscribe from this group and stop receiving emails from it, send an email to rtc-linux+unsubscribe@googlegroups.com. For more options, visit https://groups.google.com/d/optout. ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: [PATCH] rtc: s3c: Don't print an error on probe deferral @ 2016-03-14 20:51 ` Alexandre Belloni 0 siblings, 0 replies; 20+ messages in thread From: Alexandre Belloni @ 2016-03-14 20:51 UTC (permalink / raw) To: Joe Perches Cc: Javier Martinez Canillas, linux-kernel, linux-samsung-soc, Krzysztof Kozlowski, rtc-linux On 14/03/2016 at 13:33:08 -0700, Joe Perches wrote : > On Mon, 2016-03-14 at 21:19 +0100, Alexandre Belloni wrote: > > checkpatch will not complain for messages but it will definitively > > complain if they are not properly aligned:) > > checkpatch wouldn't actually complain unless the --strict option > was used or these files were in drivers/net or drivers/staging. > yeah, I'm using --strict on all the patches I receive. -- Alexandre Belloni, Free Electrons Embedded Linux, Kernel and Android engineering http://free-electrons.com ^ permalink raw reply [flat|nested] 20+ messages in thread
end of thread, other threads:[~2016-03-14 20:51 UTC | newest] Thread overview: 20+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2016-03-14 19:05 [rtc-linux] [PATCH] rtc: s3c: Don't print an error on probe deferral Javier Martinez Canillas 2016-03-14 19:05 ` Javier Martinez Canillas 2016-03-14 19:11 ` [rtc-linux] " Joe Perches 2016-03-14 19:11 ` Joe Perches 2016-03-14 19:31 ` [rtc-linux] " Javier Martinez Canillas 2016-03-14 19:31 ` Javier Martinez Canillas 2016-03-14 19:38 ` [rtc-linux] " Joe Perches 2016-03-14 19:38 ` Joe Perches 2016-03-14 19:59 ` [rtc-linux] " Javier Martinez Canillas 2016-03-14 19:59 ` Javier Martinez Canillas 2016-03-14 20:03 ` [rtc-linux] " Joe Perches 2016-03-14 20:03 ` Joe Perches 2016-03-14 20:23 ` [rtc-linux] " Javier Martinez Canillas 2016-03-14 20:23 ` Javier Martinez Canillas 2016-03-14 20:19 ` [rtc-linux] " Alexandre Belloni 2016-03-14 20:19 ` Alexandre Belloni 2016-03-14 20:33 ` [rtc-linux] " Joe Perches 2016-03-14 20:33 ` Joe Perches 2016-03-14 20:51 ` [rtc-linux] " Alexandre Belloni 2016-03-14 20:51 ` Alexandre Belloni
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.