[PATCH 2/2] talitos: Freescale integrated security engine (SEC) driver

[Kim Phillips]

On Sat, 31 May 2008 01:12:08 +0400
Evgeniy Polyakov <johnpol at 2ka.mipt.ru> wrote:

> On Fri, May 30, 2008 at 03:48:20PM -0500, Kim Phillips (kim.phillips at freescale.com) 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 from tasklets, although readonly, but that rises
> a red flag... Also callback invocation tasklet drops the lock around

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 status, depending on how many channel dones it has already
processed.  I think the only solution here is to call flush_channel on
each channel, regardless of the bits in the interrupt status - I'll
send out a patch shortly.

> callback, during that time cached status and priv itself (and tail like
> in two simultaneous flushes) could change (or not?)

I think you're talking about a different 'status' here; flush_channel's
local 'status' doesn't resemble priv->status bits in any way, it looks
at the descriptor header writeback bits for done status, on a per
descriptor basis.  It forwards this descriptor done vs. error status to
the callback.

priv itself won't change; it's uniquely associated to the device.

Kim