mbox series

[0/3] rtc: pcf8563: Fix unhandled interrupt storm

Message ID 20190604042337.26129-1-wens@kernel.org (mailing list archive)
Headers show
Series rtc: pcf8563: Fix unhandled interrupt storm | expand

Message

Chen-Yu Tsai June 4, 2019, 4:23 a.m. UTC
From: Chen-Yu Tsai <wens@csie.org>

Hi everyone,

While bringing up my Pine H64, I encountered an interrupt storm from the
pcf8563 RTC. The RTC chip's interrupt line is shared with the PMIC, and
was not properly added to the device tree. Also, the driver was using an
trigger method incompatible with the PMIC, preventing the interrupt line
from being shared. Last, the driver only clears and masks the alarm
interrupt, while leaving the timer interrupt untouched. This is a
problem if previous systems left the timer interrupt enabled, and there
was an interrupt pending.

This patch set fixes all three issues, one per patch.

Please have a look.

Chen-Yu Tsai (3):
  rtc: pcf8563: Fix interrupt trigger method
  rtc: pcf8563: Clear event flags and disable interrupts before
    requesting irq
  arm64: dts: allwinner: h6: Pine H64: Add interrupt line for RTC

 .../arm64/boot/dts/allwinner/sun50i-h6-pine-h64.dts |  2 ++
 drivers/rtc/rtc-pcf8563.c                           | 13 ++++++-------
 2 files changed, 8 insertions(+), 7 deletions(-)

Comments

Alexandre Belloni June 20, 2019, 4:22 p.m. UTC | #1
On 04/06/2019 12:23:34+0800, Chen-Yu Tsai wrote:
> From: Chen-Yu Tsai <wens@csie.org>
> 
> Hi everyone,
> 
> While bringing up my Pine H64, I encountered an interrupt storm from the
> pcf8563 RTC. The RTC chip's interrupt line is shared with the PMIC, and
> was not properly added to the device tree. Also, the driver was using an
> trigger method incompatible with the PMIC, preventing the interrupt line
> from being shared. Last, the driver only clears and masks the alarm
> interrupt, while leaving the timer interrupt untouched. This is a
> problem if previous systems left the timer interrupt enabled, and there
> was an interrupt pending.
> 
> This patch set fixes all three issues, one per patch.
> 
> Please have a look.
> 

I don't have that particular RTC so I can't test but the interrupt
handling in pcf8563_irq seems problematic too. I guess the RTC will only
trigger once per second because the call to pcf8563_set_alarm_mode will
explicitely leave the alarm enabled. The core doesn't really care but it
doesn't really expect the alarm to stay enabled. i.e. It will ensure the
alarm is enabled again after setting it when necessary. I think it would
be safer to simply clear both AIE and AF here. Could you test?

> Chen-Yu Tsai (3):
>   rtc: pcf8563: Fix interrupt trigger method
>   rtc: pcf8563: Clear event flags and disable interrupts before
>     requesting irq
>   arm64: dts: allwinner: h6: Pine H64: Add interrupt line for RTC
> 
>  .../arm64/boot/dts/allwinner/sun50i-h6-pine-h64.dts |  2 ++
>  drivers/rtc/rtc-pcf8563.c                           | 13 ++++++-------
>  2 files changed, 8 insertions(+), 7 deletions(-)
> 
> -- 
> 2.20.1
>
Chen-Yu Tsai June 24, 2019, 10:34 a.m. UTC | #2
On Fri, Jun 21, 2019 at 12:22 AM Alexandre Belloni
<alexandre.belloni@bootlin.com> wrote:
>
> On 04/06/2019 12:23:34+0800, Chen-Yu Tsai wrote:
> > From: Chen-Yu Tsai <wens@csie.org>
> >
> > Hi everyone,
> >
> > While bringing up my Pine H64, I encountered an interrupt storm from the
> > pcf8563 RTC. The RTC chip's interrupt line is shared with the PMIC, and
> > was not properly added to the device tree. Also, the driver was using an
> > trigger method incompatible with the PMIC, preventing the interrupt line
> > from being shared. Last, the driver only clears and masks the alarm
> > interrupt, while leaving the timer interrupt untouched. This is a
> > problem if previous systems left the timer interrupt enabled, and there
> > was an interrupt pending.
> >
> > This patch set fixes all three issues, one per patch.
> >
> > Please have a look.
> >
>
> I don't have that particular RTC so I can't test but the interrupt
> handling in pcf8563_irq seems problematic too. I guess the RTC will only
> trigger once per second because the call to pcf8563_set_alarm_mode will
> explicitely leave the alarm enabled. The core doesn't really care but it
> doesn't really expect the alarm to stay enabled. i.e. It will ensure the
> alarm is enabled again after setting it when necessary. I think it would
> be safer to simply clear both AIE and AF here. Could you test?

Yeah, that bit looked weird to me as well. And actually the alarm doesn't
go down to the second, only the minute.

Is there a test program I can use to test the alarms?

Thanks
ChenYu

> > Chen-Yu Tsai (3):
> >   rtc: pcf8563: Fix interrupt trigger method
> >   rtc: pcf8563: Clear event flags and disable interrupts before
> >     requesting irq
> >   arm64: dts: allwinner: h6: Pine H64: Add interrupt line for RTC
> >
> >  .../arm64/boot/dts/allwinner/sun50i-h6-pine-h64.dts |  2 ++
> >  drivers/rtc/rtc-pcf8563.c                           | 13 ++++++-------
> >  2 files changed, 8 insertions(+), 7 deletions(-)
> >
> > --
> > 2.20.1
> >
>
> --
> Alexandre Belloni, Bootlin
> Embedded Linux and Kernel engineering
> https://bootlin.com
Alexandre Belloni June 24, 2019, 10:42 a.m. UTC | #3
On 24/06/2019 18:34:29+0800, Chen-Yu Tsai wrote:
> On Fri, Jun 21, 2019 at 12:22 AM Alexandre Belloni
> <alexandre.belloni@bootlin.com> wrote:
> >
> > On 04/06/2019 12:23:34+0800, Chen-Yu Tsai wrote:
> > > From: Chen-Yu Tsai <wens@csie.org>
> > >
> > > Hi everyone,
> > >
> > > While bringing up my Pine H64, I encountered an interrupt storm from the
> > > pcf8563 RTC. The RTC chip's interrupt line is shared with the PMIC, and
> > > was not properly added to the device tree. Also, the driver was using an
> > > trigger method incompatible with the PMIC, preventing the interrupt line
> > > from being shared. Last, the driver only clears and masks the alarm
> > > interrupt, while leaving the timer interrupt untouched. This is a
> > > problem if previous systems left the timer interrupt enabled, and there
> > > was an interrupt pending.
> > >
> > > This patch set fixes all three issues, one per patch.
> > >
> > > Please have a look.
> > >
> >
> > I don't have that particular RTC so I can't test but the interrupt
> > handling in pcf8563_irq seems problematic too. I guess the RTC will only
> > trigger once per second because the call to pcf8563_set_alarm_mode will
> > explicitely leave the alarm enabled. The core doesn't really care but it
> > doesn't really expect the alarm to stay enabled. i.e. It will ensure the
> > alarm is enabled again after setting it when necessary. I think it would
> > be safer to simply clear both AIE and AF here. Could you test?
> 
> Yeah, that bit looked weird to me as well. And actually the alarm doesn't
> go down to the second, only the minute.
> 
> Is there a test program I can use to test the alarms?
> 

Sure, tools/testing/selftests/rtc/rtctest.c if you use a recent enough
version, it will test minute boundaries.