On Sat, 31 May 2008 13:59:02 +0400
Evgeniy Polyakov [EMAIL PROTECTED] wrote:
Hi.
On Fri, May 30, 2008 at 05:19:30PM -0500, Kim Phillips ([EMAIL PROTECTED])
wrote:
ok, I see what you are saying now; if a channel gets done during
talitos_done processing, it'll trigger an interrupt and
On Mon, Jun 02, 2008 at 09:27:01AM -0500, Kim Phillips ([EMAIL PROTECTED])
wrote:
I meant descriptor hdr value accessed via it - can it be checked in
tasklet under the lock and in submit path without? Can they correlate
somehow?
I believe the check for a non-null request-desc (under
On Mon, 2 Jun 2008 20:00:12 +0400
Evgeniy Polyakov [EMAIL PROTECTED] wrote:
On Mon, Jun 02, 2008 at 09:27:01AM -0500, Kim Phillips ([EMAIL PROTECTED])
wrote:
I meant descriptor hdr value accessed via it - can it be checked in
tasklet under the lock and in submit path without? Can they
On Mon, Jun 02, 2008 at 11:50:21AM -0500, Kim Phillips ([EMAIL PROTECTED])
wrote:
But can it be changed? You write to it without lock, but read under the
one (different for each channel though), so it attracted attention.
can you point where in the code your concern is?
talitos_submit()
On Mon, 2 Jun 2008 21:57:51 +0400
Evgeniy Polyakov [EMAIL PROTECTED] wrote:
On Mon, Jun 02, 2008 at 11:50:21AM -0500, Kim Phillips ([EMAIL PROTECTED])
wrote:
But can it be changed? You write to it without lock, but read under the
one (different for each channel though), so it attracted
Hi.
On Mon, Jun 02, 2008 at 02:06:03PM -0500, Kim Phillips ([EMAIL PROTECTED])
wrote:
it would be an issue if flush_cannel didn't save off the data required
to call the callback with in saved_req. flush_channel does this on
purpose to be able to call the callback outside of lock (as is
Hi.
On Fri, May 30, 2008 at 05:19:30PM -0500, Kim Phillips ([EMAIL PROTECTED])
wrote:
ok, I see what you are saying now; if a channel gets done during
talitos_done processing, it'll trigger an interrupt and reset
priv-status, leaving the tasklet in the dark as to which channel has
done
Hi.
On Thu, May 29, 2008 at 02:12:50PM -0500, Kim Phillips ([EMAIL PROTECTED])
wrote:
+static irqreturn_t talitos_interrupt(int irq, void *data)
+{
+ struct device *dev = data;
+ struct talitos_private *priv = dev_get_drvdata(dev);
+
+ priv-status = in_be32(priv-reg +
On Fri, 30 May 2008 22:09:04 +0400
Evgeniy Polyakov [EMAIL PROTECTED] wrote:
Hi.
On Thu, May 29, 2008 at 02:12:50PM -0500, Kim Phillips ([EMAIL PROTECTED])
wrote:
+static irqreturn_t talitos_interrupt(int irq, void *data)
+{
+ struct device *dev = data;
+ struct
Kim Phillips wrote:
On Fri, 30 May 2008 22:09:04 +0400
Evgeniy Polyakov [EMAIL PROTECTED] wrote:
Don't you want to protect against simultaneous access to register space
from different CPUs? Or it is single processor board only?
Doesn't linux mask the IRQ line for the interrupt currently being
On Fri, May 30, 2008 at 02:41:17PM -0500, Scott Wood ([EMAIL PROTECTED]) wrote:
Don't you want to protect against simultaneous access to register space
from different CPUs? Or it is single processor board only?
Doesn't linux mask the IRQ line for the interrupt currently being
serviced, and
On Fri, 30 May 2008 14:41:17 -0500
Scott Wood [EMAIL PROTECTED] wrote:
Kim Phillips wrote:
On Fri, 30 May 2008 22:09:04 +0400
Evgeniy Polyakov [EMAIL PROTECTED] wrote:
Don't you want to protect against simultaneous access to register space
from different CPUs? Or it is single processor
Kim Phillips wrote:
On Fri, 30 May 2008 14:41:17 -0500
Scott Wood [EMAIL PROTECTED] wrote:
Kim Phillips wrote:
On Fri, 30 May 2008 22:09:04 +0400
Evgeniy Polyakov [EMAIL PROTECTED] wrote:
Don't you want to protect against simultaneous access to register space
from different CPUs? Or it is
Kim Phillips wrote:
On Fri, 30 May 2008 15:19:43 -0500
Scott Wood [EMAIL PROTECTED] wrote:
Kim Phillips wrote:
On Fri, 30 May 2008 14:41:17 -0500
Scott Wood [EMAIL PROTECTED] wrote:
Kim Phillips wrote:
On Fri, 30 May 2008 22:09:04 +0400
Evgeniy Polyakov [EMAIL PROTECTED] wrote:
Don't you
On Fri, 30 May 2008 15:19:43 -0500
Scott Wood [EMAIL PROTECTED] wrote:
Kim Phillips wrote:
On Fri, 30 May 2008 14:41:17 -0500
Scott Wood [EMAIL PROTECTED] wrote:
Kim Phillips wrote:
On Fri, 30 May 2008 22:09:04 +0400
Evgeniy Polyakov [EMAIL PROTECTED] wrote:
Don't you want to
On Fri, 30 May 2008 15:36:50 -0500
Scott Wood [EMAIL PROTECTED] wrote:
Kim Phillips wrote:
On Fri, 30 May 2008 15:19:43 -0500
Scott Wood [EMAIL PROTECTED] wrote:
Kim Phillips wrote:
On Fri, 30 May 2008 14:41:17 -0500
Scott Wood [EMAIL PROTECTED] wrote:
Kim Phillips wrote:
On
On Fri, May 30, 2008 at 03:48:20PM -0500, Kim Phillips ([EMAIL PROTECTED])
wrote:
sorry, by ISR I meant interrupt status registers. but I can't tell
where the suspected simultaneous accesses are. Evgeniy, can you point
out the register accesses you're talking about?
priv-status is accessed
On Sat, 31 May 2008 01:12:08 +0400
Evgeniy Polyakov [EMAIL PROTECTED] wrote:
On Fri, May 30, 2008 at 03:48:20PM -0500, Kim Phillips ([EMAIL PROTECTED])
wrote:
sorry, by ISR I meant interrupt status registers. but I can't tell
where the suspected simultaneous accesses are. Evgeniy, can
Add support for the SEC available on a wide range of PowerQUICC devices,
e.g. MPC8349E, MPC8548E.
this initial version supports authenc(hmac(sha1),cbc(aes)) for use with IPsec.
Signed-off-by: Kim Phillips [EMAIL PROTECTED]
---
drivers/crypto/Kconfig | 15 +
drivers/crypto/Makefile |1 +
19 matches
Mail list logo
