Hi, On Mon, May 28, 2012 at 09:58:32AM +0800, cloudy.linux wrote: > On 2012-5-25 21:54, Phil Sutter wrote: > > Also drop the whole definition, since it's unused otherwise. > > > > Signed-off-by: Phil Sutter<phil.sutter@xxxxxxxxxxxx> > > --- > > drivers/crypto/mv_cesa.c | 1 - > > drivers/crypto/mv_cesa.h | 7 ------- > > 2 files changed, 0 insertions(+), 8 deletions(-) > > > > diff --git a/drivers/crypto/mv_cesa.c b/drivers/crypto/mv_cesa.c > > index 8327bed..4a1f872 100644 > > --- a/drivers/crypto/mv_cesa.c > > +++ b/drivers/crypto/mv_cesa.c > > @@ -908,7 +908,6 @@ irqreturn_t crypto_int(int irq, void *priv) > > "got an interrupt but no pending timer?\n"); > > } > > val&= ~SEC_INT_ACCEL0_DONE; > > - writel(val, cpg->reg + FPGA_INT_STATUS); > > writel(val, cpg->reg + SEC_ACCEL_INT_STATUS); > > BUG_ON(cpg->eng_st != ENGINE_BUSY); > > cpg->eng_st = ENGINE_W_DEQUEUE; > > diff --git a/drivers/crypto/mv_cesa.h b/drivers/crypto/mv_cesa.h > > index 08fcb11..81ce109 100644 > > --- a/drivers/crypto/mv_cesa.h > > +++ b/drivers/crypto/mv_cesa.h > > @@ -29,13 +29,6 @@ > > #define SEC_ST_ACT_0 (1<< 0) > > #define SEC_ST_ACT_1 (1<< 1) > > > > -/* > > - * FPGA_INT_STATUS looks like a FPGA leftover and is documented only in Errata > > - * 4.12. It looks like that it was part of an IRQ-controller in FPGA and > > - * someone forgot to remove it while switching to the core and moving to > > - * SEC_ACCEL_INT_STATUS. > > - */ > > -#define FPGA_INT_STATUS 0xdd68 > > #define SEC_ACCEL_INT_STATUS 0xde20 > > #define SEC_INT_AUTH_DONE (1<< 0) > > #define SEC_INT_DES_E_DONE (1<< 1) > > According to the functional errata of 88F5182, the FPGA_INT_STATUS is > needed (at least for 88F5182-A1/A2). Here is the quote from that errata: > > 4.12 Clearing the Cryptographic Engines and Security Accelerator > Interrupt Cause Register > Type: Guideline > Ref#: GL-CESA-100 > Relevant for: 88F5182-A1/A2 > > Description: > Writing 0 to bits[6:0] of the Crytographic Engines ... Interrupt Cause > register (offset 0x9DE20) has no effect. > > Steps to be performed by the designer > Before writing 0 to any of the bits[6:0] of the Cryptographic Engines .. > Interrupt Cause register, the software must write 0 to the corresponding > bit of the internal register at offset 0x9DD68. > Writing to offset 0x9DD68 is not possible when any of the Security > Accelerators' sessions are active. Therefore, the software must verify > that no channel is active before clearing any of those interrupts. Oh, that explains why it's not needed on Kirkwood but still left there. I could make it compile-time optional, depending on ARCH_ORION5X e.g. or simply drop the patch and leave it alone since it really doesn't hurt that much. Anyway, thanks a lot for your kind review! Greetings, Phil Phil Sutter Software Engineer -- Viprinet GmbH Mainzer Str. 43 55411 Bingen am Rhein Germany Phone/Zentrale: +49-6721-49030-0 Direct line/Durchwahl: +49-6721-49030-134 Fax: +49-6721-49030-209 phil.sutter@xxxxxxxxxxxx http://www.viprinet.com Registered office/Sitz der Gesellschaft: Bingen am Rhein Commercial register/Handelsregister: Amtsgericht Mainz HRB40380 CEO/Geschäftsführer: Simon Kissel -- To unsubscribe from this list: send the line "unsubscribe linux-crypto" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
