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

[Kim Phillips]

On Sat, 31 May 2008 13:59:02 +0400
Evgeniy Polyakov <johnpol at 2ka.mipt.ru> wrote:

> Hi.
> 
> On Fri, May 30, 2008 at 05:19:30PM -0500, Kim Phillips (kim.phillips at freescale.com) 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 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.
> 
> Out of curiosity, what is number of channels? I had simialar issue with

typically four but some parts only have one.

> HIFN crypto driver and limited number of descriptor to 80 iirc, since
> with that number HIFN traversal did not show perfromance degradataion on
> Ghz x86.

ok, I've been focusing on correctness for the time being.

> > > 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.
> 
> 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 lock) before
the hdr value is accessed ensures this doesn't happen.

Kim