MIME-Version: 1.0
References: <20190315040239.24705-1-vakul.garg@nxp.com> <20190315040239.24705-2-vakul.garg@nxp.com>
In-Reply-To: <20190315040239.24705-2-vakul.garg@nxp.com>
From:   Chris Spencer <spencercw@gmail.com>
Date:   Fri, 15 Mar 2019 08:08:42 +0000
Message-ID: <CAGUNXRRPMwQJ4Zx_1z0k52Ri2sZQTsYVTZztkVrdbrSvRm9AHg@mail.gmail.com>
Subject: Re: [PATCH 1/3] crypto: caam/jr - Remove spinlock for output job ring
To:     Vakul Garg <vakul.garg@nxp.com>
Cc:     "linux-crypto@vger.kernel.org" <linux-crypto@vger.kernel.org>,
        "herbert@gondor.apana.org.au" <herbert@gondor.apana.org.au>,
        Horia Geanta <horia.geanta@nxp.com>,
        Aymen Sghaier <aymen.sghaier@nxp.com>
Content-Type: text/plain; charset="UTF-8"
Sender: linux-crypto-owner@vger.kernel.org
Precedence: bulk

Hi Vakul,

On Fri, 15 Mar 2019 at 04:05, Vakul Garg <vakul.garg@nxp.com> wrote:
> For each job ring pair, the output ring is processed exactly by one cpu
> at a time under a tasklet context (one per ring). Therefore, there is no
> need to protect a job ring's access & its private data structure using a
> lock. Hence the lock can be removed.
>
> Signed-off-by: Vakul Garg <vakul.garg@nxp.com>

This comment in caam_jr_dequeue doesn't really make sense anymore:
/* Stash callback params for use outside of lock */

Since the lock has been removed you could probably get away with just
invoking the user callback immediately which would simplify the code a
little.

Thanks,
Chris