linux-kernel - Re: [PATCH] atmel_serial: Split the interrupt handler

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] [day] [month] [year] [list]

Message-ID: <20071219142451.1e72f68c@dhcp-252-066.norway.atmel.com>
Date:	Wed, 19 Dec 2007 14:24:51 +0100
From:	Haavard Skinnemoen <hskinnemoen@...el.com>
To:	"Remy Bohmer" <linux@...mer.net>
Cc:	"Andrew Victor" <linux@...im.org.za>,
	"ARM Linux Mailing List" <linux-arm-kernel@...ts.arm.linux.org.uk>,
	"Russell King - ARM Linux" <linux@....linux.org.uk>,
	linux-kernel@...r.kernel.org
Subject: Re: [PATCH] atmel_serial: Split the interrupt handler

On Wed, 19 Dec 2007 14:18:18 +0100
"Remy Bohmer" <linux@...mer.net> wrote:

> Hello Haavard,
> 
> > Hrm. We probably need to lock while updating icount. That's a problem
> > since we do that from the tx interrupt handler...and I don't suppose we
> > want to move most of the atmel_tx_chars() code into the tasklet too...?
> 
> I do not see a reason why not moving transmit to a tasklet. It is only
> time critical to read in time. If the transmit is postponed for a
> while, it will only slow down transmission, while not reading in time
> results in lost data.

Ok, let's try that. But I'm afraid this means that we can't move the
sysrq processing back into hardirq context since if we're going to do
break handling, we need to update icount.brk as well.

Haavard
--
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/