[PATCH v3] rtc: s3c: Don't print an error on probe deferral

[PATCH v3] rtc: s3c: Don't print an error on probe deferral

[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 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);
 	}
-- 
2.5.0

Re: [PATCH v3] rtc: s3c: Don't print an error on probe deferral

[Krzysztof Kozlowski]

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

Re: [PATCH v3] rtc: s3c: Don't print an error on probe deferral

[Javier Martinez Canillas]

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,
-- 
Javier Martinez Canillas
Open Source Group
Samsung Research America

Re: [PATCH v3] rtc: s3c: Don't print an error on probe deferral

[Krzysztof Kozlowski]

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

Re: [PATCH v3] rtc: s3c: Don't print an error on probe deferral

[Javier Martinez Canillas]

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,
-- 
Javier Martinez Canillas
Open Source Group
Samsung Research America

Re: [PATCH v3] rtc: s3c: Don't print an error on probe deferral

[Javier Martinez Canillas]

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,
-- 
Javier Martinez Canillas
Open Source Group
Samsung Research America

Re: [PATCH v3] rtc: s3c: Don't print an error on probe deferral

[Alexandre Belloni]

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.

-- 
Alexandre Belloni, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com

Re: [rtc-linux] Re: [PATCH v3] rtc: s3c: Don't print an error on probe deferral

[Krzysztof Kozlowski]

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

Re: [rtc-linux] Re: [PATCH v3] rtc: s3c: Don't print an error on probe deferral

[Javier Martinez Canillas]

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,
-- 
Javier Martinez Canillas
Open Source Group
Samsung Research America

Re: [PATCH v3] rtc: s3c: Don't print an error on probe deferral

[Alexandre Belloni]

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.


-- 
Alexandre Belloni, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com

Re: [PATCH v3] rtc: s3c: Don't print an error on probe deferral

[Javier Martinez Canillas]

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,
-- 
Javier Martinez Canillas
Open Source Group
Samsung Research America

Re: [PATCH v3] rtc: s3c: Don't print an error on probe deferral

[Alexandre Belloni]

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.

-- 
Alexandre Belloni, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com