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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-id: <56E772F2.2030507@samsung.com>
Date:	Tue, 15 Mar 2016 11:26:58 +0900
From:	Krzysztof Kozlowski <k.kozlowski@...sung.com>
To:	Javier Martinez Canillas <javier@....samsung.com>,
	linux-kernel@...r.kernel.org
Cc:	Joe Perches <joe@...ches.com>,
	Alexandre Belloni <alexandre.belloni@...e-electrons.com>,
	linux-samsung-soc@...r.kernel.org, rtc-linux@...glegroups.com
Subject: Re: [PATCH v3] rtc: s3c: Don't print an error on probe deferral

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