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

[Evgeniy Polyakov <johnpol@2ka.mipt.ru>]

Hi.

On Fri, May 30, 2008 at 05:19:30PM -0500, Kim Phillips (kim.phillips@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
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.

> > 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?

-- 
	Evgeniy Polyakov