linux-kernel - Re: Fix preempt-rt on AT91

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]

Message-ID: <569D4B55.10103@linutronix.de>
Date:	Mon, 18 Jan 2016 21:30:13 +0100
From:	Sebastian Andrzej Siewior <bigeasy@...utronix.de>
To:	Alexandre Belloni <alexandre.belloni@...e-electrons.com>
Cc:	Thomas Gleixner <tglx@...utronix.de>,
	Boris Brezillon <boris.brezillon@...e-electrons.com>,
	linux-arm-kernel@...ts.infradead.org, linux-kernel@...r.kernel.org,
	linux-rt-users@...r.kernel.org,
	Nicolas Ferre <nicolas.ferre@...el.com>
Subject: Re: Fix preempt-rt on AT91

On 01/18/2016 08:23 PM, Alexandre Belloni wrote:
> Hi,
Hi,

>>> I'd say that the proper solution would still be to implement the virtual
>>> irqchip because this would still hit people not wanting to use the TCB as
>>> their clock source.
>>
>> why wouldn't people not want that?
> 
> Because they may be using the TCBs for something else: PWM, frequency
> measure, quadrature decoder...

Oh okay.

>> For a virtual irqchip you would need a mask/unmask register in order to
>> individual disable/enable the irq and you need something to figure out
>> which one of the three is active. You don't have all those things, do
>> you?
>>
> 
> The proposed solution was software only. It mainly consisted in a simple
> irq demuxer.

Well, if it works properly and does not lead to any new bugs or
anything else then nobody will mind I guess.

>> All in all, care to forwarded the working pieces from -RT patch set
>> upstream? I problem I have here is mostly that I can't the patches on
>> actual hardware. Disabling the PIT and running on the other clocksource
>> isn't that -RT specific after all :)
> 
> I'd say that the only remaining part is the IRQ freeing/requesting but
> as I said, this can't land in mainline as is. I still plan to work on
> that later.
> I'd say that most people running linux on at91 are already using the tcb
> as the clocksource, this is already available in the mainline and is the
> default unless the TCBs are used for something else.

Wasn't there one of the patches to increase the frequency of the TCB
clocksource from the default to something higher?

Sebastian