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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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) { >

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) { >

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

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(>dev, "rtc_src"); if (IS_ERR(info->rtc_src_clk)) { -

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

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(>dev, "rtc_src"); if (IS_ERR(info->rtc_src_clk)) { -

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

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

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

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

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

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

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

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

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

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

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

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

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

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