Re: [RESEND] rtc: snvs: Fix usage of snvs_rtc_enable

2018-04-03 Thread Alexandre Belloni
Hi, On 02/04/2018 at 23:51:12 +0100, Bryan O'Donoghue wrote: > On 30/03/18 23:59, Trent Piepho wrote: > > However, I think that even if the driver fails to probe if there is a > > timeout at probe time, it's still possible to hang later if there are > > not limits to the hardware polling loops,

Re: [RESEND] rtc: snvs: Fix usage of snvs_rtc_enable

2018-04-03 Thread Alexandre Belloni
Hi, On 02/04/2018 at 23:51:12 +0100, Bryan O'Donoghue wrote: > On 30/03/18 23:59, Trent Piepho wrote: > > However, I think that even if the driver fails to probe if there is a > > timeout at probe time, it's still possible to hang later if there are > > not limits to the hardware polling loops,

Re: [RESEND] rtc: snvs: Fix usage of snvs_rtc_enable

2018-04-02 Thread Bryan O'Donoghue
On 30/03/18 23:59, Trent Piepho wrote: However, I think that even if the driver fails to probe if there is a timeout at probe time, it's still possible to hang later if there are not limits to the hardware polling loops, such as the ones I added. I agree with your patch in principle for this

Re: [RESEND] rtc: snvs: Fix usage of snvs_rtc_enable

2018-04-02 Thread Bryan O'Donoghue
On 30/03/18 23:59, Trent Piepho wrote: However, I think that even if the driver fails to probe if there is a timeout at probe time, it's still possible to hang later if there are not limits to the hardware polling loops, such as the ones I added. I agree with your patch in principle for this

Re: [RESEND] rtc: snvs: Fix usage of snvs_rtc_enable

2018-03-30 Thread Trent Piepho
On Thu, 2018-03-29 at 02:53 +0100, Bryan O'Donoghue wrote: > On 29/03/18 01:12, Trent Piepho wrote: > > > I sent a patch a couple weeks ago that addressed a similar issue, see > >

Re: [RESEND] rtc: snvs: Fix usage of snvs_rtc_enable

2018-03-30 Thread Trent Piepho
On Thu, 2018-03-29 at 02:53 +0100, Bryan O'Donoghue wrote: > On 29/03/18 01:12, Trent Piepho wrote: > > > I sent a patch a couple weeks ago that addressed a similar issue, see > >

Re: [RESEND] rtc: snvs: Fix usage of snvs_rtc_enable

2018-03-28 Thread Bryan O'Donoghue
On 29/03/18 01:12, Trent Piepho wrote: I sent a patch a couple weeks ago that addressed a similar issue, see https://patchwork.ozlabs.org/patch/887090/ Does this also fix the problem you see? It breaks the endless loop that happens later on in the RTC read path. This patch though is about

Re: [RESEND] rtc: snvs: Fix usage of snvs_rtc_enable

2018-03-28 Thread Bryan O'Donoghue
On 29/03/18 01:12, Trent Piepho wrote: I sent a patch a couple weeks ago that addressed a similar issue, see https://patchwork.ozlabs.org/patch/887090/ Does this also fix the problem you see? It breaks the endless loop that happens later on in the RTC read path. This patch though is about

Re: [RESEND] rtc: snvs: Fix usage of snvs_rtc_enable

2018-03-28 Thread Trent Piepho
On Wed, 2018-03-28 at 20:14 +0100, Bryan O'Donoghue wrote: > commit 179a502f8c46 ("rtc: snvs: add Freescale rtc-snvs driver") introduces > the SNVS RTC driver with a function snvs_rtc_enable(). > > snvs_rtc_enable() can return an error on the enable path however this > driver does not currently

Re: [RESEND] rtc: snvs: Fix usage of snvs_rtc_enable

2018-03-28 Thread Trent Piepho
On Wed, 2018-03-28 at 20:14 +0100, Bryan O'Donoghue wrote: > commit 179a502f8c46 ("rtc: snvs: add Freescale rtc-snvs driver") introduces > the SNVS RTC driver with a function snvs_rtc_enable(). > > snvs_rtc_enable() can return an error on the enable path however this > driver does not currently