* Nicolas Pitre | 2009-06-11 17:19:22 [-0400]:
>> >What is your plan for this driver? Submit it now and add incremental
>> >improvements afterward or wait until it is more functional?
>> I would like to get it squeezed into this merge window unless there are
>> any objections and improve it afterwards.
>> If you thing it is too early I can keep hacking in my own git tree until
>> I get the dmac_flush_range() hack out or so.
>
>I have no problem with you submitting it now. It is not complete yet
>but what is there is plenty functional. However I'd prefer if you used
>the API based on sg_copy_buffer() which includes a call to
>flush_kernel_dcache_page() already for mainline inclusion, so to have
>good style up front. ( a patch to fix flush_kernel_dcache_page() on ARM
>is already queued).
sg_copy_from_buffer() since the other one is static. I'm little unhappy
with it because this forces me to have the entire buffer "ready". This
is not a problem for dm-crypt because I get just one scatterlist entry
with 512 bytes. I don't know about others but this will put a
limitation / break them.
It looks like sg_miter_start() which is exported doesn't provide the
the required flush interface. What about:
--- a/drivers/crypto/mv_cesa.c
+++ b/drivers/crypto/mv_cesa.c
@@ -259,12 +259,6 @@ static void dequeue_complete_req(void)
dst_copy = min(cpg->p.crypt_len, cpg->p.sg_dst_left);
memcpy(buf, cpg->sram + SRAM_DATA_OUT_START, dst_copy);
- /*
- * XXX This is a temporary hack to flush data from cache back
- * into phys ram so user space sees correct data. This goes
- * away as soon as DMA support is added to this driver
- */
- dmac_flush_range(buf, buf + dst_copy);
cpg->p.sg_dst_left -= dst_copy;
cpg->p.crypt_len -= dst_copy;
@@ -309,7 +303,7 @@ static void mv_enqueue_new_req(struct ablkcipher_request
*req)
sg_miter_start(&cpg->p.src_sg_it, req->src, num_sgs, 0);
num_sgs = count_sgs(req->dst, req->nbytes);
- sg_miter_start(&cpg->p.dst_sg_it, req->dst, num_sgs, 0);
+ sg_miter_start(&cpg->p.dst_sg_it, req->dst, num_sgs,
SG_MITER_FLUSH_CACHE);
mv_process_current_q(1);
}
diff --git a/include/linux/scatterlist.h b/include/linux/scatterlist.h
index e599698..8f98450 100644
--- a/include/linux/scatterlist.h
+++ b/include/linux/scatterlist.h
@@ -242,6 +242,7 @@ size_t sg_copy_to_buffer(struct scatterlist *sgl, unsigned
int nents,
*/
#define SG_MITER_ATOMIC (1 << 0) /* use kmap_atomic */
+#define SG_MITER_FLUSH_CACHE (1 << 1) /* flash cache on unmap */
struct sg_mapping_iter {
/* the following three fields can be accessed directly */
diff --git a/lib/scatterlist.c b/lib/scatterlist.c
index a295e40..4b07f7a 100644
--- a/lib/scatterlist.c
+++ b/lib/scatterlist.c
@@ -394,6 +394,9 @@ void sg_miter_stop(struct sg_mapping_iter *miter)
if (miter->addr) {
miter->__offset += miter->consumed;
+ if (miter->__flags & SG_MITER_FLUSH_CACHE)
+ flush_kernel_dcache_page(miter->page);
+
if (miter->__flags & SG_MITER_ATOMIC) {
WARN_ON(!irqs_disabled());
kunmap_atomic(miter->addr, KM_BIO_SRC_IRQ);
--
1.6.0.6
>
>
>Nicolas
Sebastian
--
To unsubscribe from this list: send the line "unsubscribe linux-crypto" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html