linux-kernel - Re: [PATCH 2/2]: Be stric clocksource/drivers/fttmr010 on IRQs

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, 30 Aug 2021 08:24:12 -0700
From:   Guenter Roeck <linux@...ck-us.net>
To:     Cédric Le Goater <clg@...d.org>,
        Andrew Jeffery <andrew@...id.au>,
        Linus Walleij <linus.walleij@...aro.org>
Cc:     Daniel Lezcano <daniel.lezcano@...aro.org>,
        Thomas Gleixner <tglx@...utronix.de>,
        linux-kernel <linux-kernel@...r.kernel.org>,
        Joel Stanley <joel@....id.au>
Subject: Re: [PATCH 2/2]: Be stric clocksource/drivers/fttmr010 on IRQs

On 8/30/21 12:47 AM, Cédric Le Goater wrote:
> On 8/30/21 6:58 AM, Guenter Roeck wrote:
>> On 8/29/21 9:16 PM, Andrew Jeffery wrote:
>> [ ... ]
>>>>
>>>>> I don't have the manuals, so I can't say what the correct behavior is,
>>>>> but at least there is some evidence that TIMER_INTR_STATE may not exist
>>>>> on ast2400 and ast2500 SOCs.
>>>>
>>>> On Aspeed SoCs AST2400 and AST2500, the TMC[34] register is a
>>>> "control register #2" whereas on the AST2600 it is an "interruptarch/arm/boot/dts/ast2600-facebook-netbmc-common.dtsi:#include
>>>> status register" with bits [0-7] holding the timers status.
>>>>
>>>> I would say that the patch simply should handle the "is_aspeed" case.
>>>
>>> Well, is_aspeed is set true in the driver for all of the 2400, 2500 and
>>> 2600. 0x34 behaves the way this patch expects on the 2600. So I think
>>> we need something less coarse than is_aspeed?
>>>
>>
>> If I understand the code correctly, ast2400 and ast2500 execute
>> fttmr010_timer_interrupt(), while ast2600 has its own interrupt handler.
>> To make this work, it would probably be necessary to check for is_aspeed
>> in fttmr010_timer_interrupt(), and only execute the new code if the flag
>> is false. The existing flag in struct fttmr010 should be good enough
>> for that.
> 
> yes.
> 
> I wonder why we have ast2600 support in fttmr010. The AST2600 boards use
> the arm_arch_timer AFAICT.
> 

It was introduced and enabled, but later disabled with commit c998f40f2ae6a4
("ARM: dts: aspeed: ast2600: Set arch timer always-on"):

"According to ASPEED, FTTMR010 is not intended to be used in the AST2600.
  The arch timer should be used, but Linux doesn't enable high-res timers
  without being assured that the arch timer is always on, so set that
  property in the devicetree."

That commit also disables the FTTMR010 timer, but doesn't remove the devicetree
node. Maybe it would make sense to remove the ast2600 code from the fttmr010
driver, including the devicetree node. After all, it looks like it is dead.

Guenter