linux-kernel - Re: [PATCH v2 22/44] metag: Time keeping

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: <50E6CF87.4070802@synopsys.com>
Date:	Fri, 4 Jan 2013 18:18:07 +0530
From:	Vineet Gupta <Vineet.Gupta1@...opsys.com>
To:	James Hogan <james.hogan@...tec.com>
CC:	<linux-arch@...r.kernel.org>, <linux-kernel@...r.kernel.org>,
	"Arnd Bergmann" <arnd@...db.de>,
	Thomas Gleixner <tglx@...utronix.de>
Subject: Re: [PATCH v2 22/44] metag: Time keeping

On Friday 04 January 2013 05:51 PM, James Hogan wrote:
> On 04/01/13 10:05, Vineet Gupta wrote:
>>
>> I have a kludge in ARC port in this subsystem - which I hope you could help clear.
>>
>> ARC also has a local timer device used for clockevent on each CPU. A one-time
>> setup_irq() with IRQF_PERCPU - would indeed setup the generic IRQ subsystem - for
>> making registration effective for all CPUs. However don't you need some per-cpu
>> magic - say enabling the IRQ at cpu or embedded interrupt controller level -
>> assuming you starts off with all IRQs disabled (which ARC Linux does).
> Hi Vineet,
>
> For Meta this is done in secondary_start_kernel in
> arch/metag/kernel/smp.c (see
> https://github.com/jahogan/metag-linux/blob/metag-core/arch/metag/kernel/smp.c#L276).
> It uses tbi_startup_interrupt which is also called by the irq_startup
> callback for the root irq_chip.

Aha, I see. Actually even that way is not bad - although doing that in
local_timer_setup ( ) makes it much cleaner/obvious. So I can do the same and get
rid of the obscure request/enable API and their dependency API - and it's
workaround API .... which are used in only one more arch inexactly 1 place in the
whole kernel.

Another question if you don't mind. In our setup we have a UART (non-standard ARC
specific) which is wired up to the boot CPU (only). Now if the init/rcS happens to
run on non-boot CPU, the setup/request_irq( ) and hence consequential low level
cpu irq unmasking will only happen on *that* cpu. Now if user were to type a
key-stroke, the interrupt will be asserted on boot-cpu, which has interrupt
masked. How is this handled.

Many thx for your quick response.
-Vineet
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/