linux-kernel - Re: [PATCH 1/2] clocksource/drivers/timer-ti-dm: Prepare to handle dra7 timer wrap issue

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]

Date:   Mon, 22 Mar 2021 18:33:40 +0200
From:   Tony Lindgren <tony@...mide.com>
To:     Daniel Lezcano <daniel.lezcano@...aro.org>
Cc:     Thomas Gleixner <tglx@...utronix.de>, Keerthy <j-keerthy@...com>,
        linux-kernel@...r.kernel.org, linux-omap@...r.kernel.org,
        linux-arm-kernel@...ts.infradead.org,
        Tero Kristo <kristo@...nel.org>
Subject: Re: [PATCH 1/2] clocksource/drivers/timer-ti-dm: Prepare to handle
 dra7 timer wrap issue

Hi,

* Daniel Lezcano <daniel.lezcano@...aro.org> [210322 15:56]:
> On 04/03/2021 08:37, Tony Lindgren wrote:
> > There is a timer wrap issue on dra7 for the ARM architected timer.
> > In a typical clock configuration the timer fails to wrap after 388 days.
> > 
> > To work around the issue, we need to use timer-ti-dm timers instead.
> > 
> > Let's prepare for adding support for percpu timers by adding a common
> > dmtimer_clkevt_init_common() and call it from dmtimer_clockevent_init().
> > This patch makes no intentional functional changes.
> > 
> > Signed-off-by: Tony Lindgren <tony@...mide.com>
> > ---
> 
> [ ... ]
> 
> > @@ -575,33 +574,60 @@ static int __init dmtimer_clockevent_init(struct device_node *np)
> >  	 */
> >  	writel_relaxed(OMAP_TIMER_CTRL_POSTED, t->base + t->ifctrl);
> >  
> > +	if (dev->cpumask == cpu_possible_mask)
> > +		irqflags = IRQF_TIMER;
> > +	else
> > +		irqflags = IRQF_TIMER | IRQF_NOBALANCING;
> 
> Can you explain the reasoning behind the test above ?

In the per cpu case we assign one dmtimer per cpu, and we want the
interrupt handling on the assigned CPU. In the per cpu case we have
the cpu specified with dev->cpumask unlike for the normal clockevent
case.

In the per cpu dmtimer case the interrupt line is not wired per cpu
though, so I don't think we want to add IRQF_PERCPU here.

Or do you have some better suggestion for the flags to use here? :)

Regards,

Tony