Re: [PATCH RESEND v4] rtc: pcf2127: handle timestamp interrupts

[Mian Yousaf Kaukab <ykaukab@suse.de>]

On Thu, Jun 24, 2021 at 08:31:00AM +0200, Bruno Thomsen wrote:
> Hi Mian,
> 
> Den ons. 2. jun. 2021 kl. 17.19 skrev Mian Yousaf Kaukab <ykaukab@suse.de>:
> >
> > commit 03623b4b041c ("rtc: pcf2127: add tamper detection support")
> > added support for timestamp interrupts. However they are not being
> > handled in the irq handler. If a timestamp interrupt occurs it
> > results in kernel disabling the interrupt and displaying the call
> > trace:
> >
> > [  121.145580] irq 78: nobody cared (try booting with the "irqpoll" option)
> > ...
> > [  121.238087] [<00000000c4d69393>] irq_default_primary_handler threaded [<000000000a90d25b>] pcf2127_rtc_irq [rtc_pcf2127]
> > [  121.248971] Disabling IRQ #78
> 
> This must have been introduced when alarm IRQ was added, as
> I always thought that tamper IRQ should be handled in user space
> with gpiomon. [...]
Correct.
> I can see that it looks like I only added a cover letter
> to the first 2 versions of patch series[1] and not the 3rd that got applied[2].
> It contains a link to how the tamper timestamp feature was tested[3].
> The script is a simple version of what is running in the product, but
> missing D-Bus call with busctl and hardware init when booted for the
> first time.
With the addition of alarm IRQ a IRQ handler (pcf2127_rtc_irq) has
been added in the driver. This handler must handle the tamper
interrupt when alarm IRQ is configured. Otherwise an IRQ storm happens
as described above.
> 
> I have just tested your patch with an upstream device tree[4] that uses
> the tamper feature, and that does not work. Probably caused by the
> fact that it does not use RTC alarm IRQ.
Make sense.
> 
> What device tree did you see the error on? If it's not upstream can you
> share how you configured the pcf2127 chip?
https://elixir.bootlin.com/linux/latest/source/arch/arm64/boot/dts/freescale/fsl-ls1046a-rdb.dts#L75
> 
> I am not against changing how the tamper feature works, but I would like
> to see the upstream device tree[4] work before merging this patch.
If you agree to handle tamper detection via an interrupt, I can send
another revision to move initialization of tamper detection within
'if (alarm_irq > 0)'. tamper.sh can then just poll timestamp0 and check
return value. Rest of this patch stays the same.

Second option is to provide support for both cases. Let me know what
do you prefer.
> 
> /Bruno
> 
> [1] https://patchwork.ozlabs.org/project/rtc-linux/cover/20190813153600.12406-1-bruno.thomsen@gmail.com/
> [2] https://patchwork.ozlabs.org/project/rtc-linux/patch/20190822131936.18772-5-bruno.thomsen@gmail.com/
> [3] https://github.com/baxeno/linux-emc-test/blob/master/tamper/tamper.sh
> [4] https://elixir.bootlin.com/linux/latest/source/arch/arm/boot/dts/imx7d-flex-concentrator.dts

BR,
Yousaf