Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.kernel > #1360552 > unrolled thread

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

Back to article view | Back to linux.kernel

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  Re: [PATCH v3] rtc: s3c: Don't print an error on probe deferral Javier Martinez Canillas <javier@osg.samsung.com> - 2016-03-18 13:00 +0100
    Re: [PATCH v3] rtc: s3c: Don't print an error on probe deferral Alexandre Belloni <alexandre.belloni@free-electrons.com> - 2016-03-18 13:10 +0100
      Re: [rtc-linux] Re: [PATCH v3] rtc: s3c: Don't print an error on  probe deferral Krzysztof Kozlowski <k.kozlowski@samsung.com> - 2016-03-18 13:30 +0100
        Re: [rtc-linux] Re: [PATCH v3] rtc: s3c: Don't print an error on  probe deferral Javier Martinez Canillas <javier@osg.samsung.com> - 2016-03-18 15:00 +0100
      Re: [PATCH v3] rtc: s3c: Don't print an error on probe deferral Alexandre Belloni <alexandre.belloni@free-electrons.com> - 2016-03-18 14:10 +0100
        Re: [PATCH v3] rtc: s3c: Don't print an error on probe deferral Javier Martinez Canillas <javier@osg.samsung.com> - 2016-03-18 14:50 +0100

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

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

[toc] | [next] | [standalone]

#1360555

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

[toc] | [prev] | [next] | [standalone]

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

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

[toc] | [prev] | [next] | [standalone]

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

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

[toc] | [prev] | [next] | [standalone]

#1360603

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

[toc] | [prev] | [next] | [standalone]

#1360634

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

[toc] | [prev] | [standalone]

Back to top | Article view | linux.kernel

csiph-web