On Mon, Sep 21, 2015 at 11:21:14AM -0400, Dan Streetman wrote: > > As far as the hw and sw drivers producing the exact same output, I > don't think that's possible with the current hw and sw drivers, > because the hw driver may have to add a header to the actual byte > stream that the hw creates, depending on buffer alignment and size > (the hw has specific restrictions). Currently, the sw driver doesn't > understand that header that the 842 hw driver creates, although that > could be added to the sw driver. And, the hw driver skips adding the > header if the buffers are correctly aligned/sized, which would result > in a test vector failure if it doesn't align the buffer the same way > each time. I guess they don't have to be exactly the same. As long as each can take the output of the other and compress/decompress them it should be fine. > Also, it might be a good time to add what we talked about a while ago, > to push the alignment/size restrictions into the crypto compression > layer, by adding cra_alignmask and cra_blocksize support to > crypto/compress.c. Since the 842 hw has requirements not only for > specific alignment and min/max sizes, but also a requirement for > specific length multiple (i.e. must be !(len % 8)) it might be > worthwhile to also add a cra_sizemodulo or something like that. > However, if the common crypto alignment/size handling code allows any > alignment/size buffers (instead of just returning error for mis-sized > buffers), I think a common crypto header would need to be added in > cases of mis-sizing, which may not be appropriate for common code. > Alternately, the common crypto code could just return error for > mis-sized buffers; users of the crypto comp api would just have to > check crypto_tfm_alg_blocksize() before calling. I'd like to see another hardware implementation before we start moving this into the API. > In case I haven't said it before, I really hate how the 842 hw > requires specific alignment and sizing. How hard is it to add support > for any alignment/size in the hw?!? Another option is to use a software fallback for the cases that the hardware can't handle. Cheers, -- Email: Herbert Xu <herbert@xxxxxxxxxxxxxxxxxxx> Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt -- 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
