diff options
author | Daniel Kestrel <kestrel1974@t-online.de> | 2021-06-05 23:46:58 +0200 |
---|---|---|
committer | Hauke Mehrtens <hauke@hauke-m.de> | 2022-01-06 00:22:50 +0100 |
commit | 34a3eaf07f6a814d77cbdaa6c8a14604a37f7784 (patch) | |
tree | 2409d0dd9c716ea234f88f6eff6eaff98716799c /BSDmakefile | |
parent | 87a19c9345db7554441dbd10f8c4460f6629c10a (diff) | |
download | upstream-34a3eaf07f6a814d77cbdaa6c8a14604a37f7784.tar.gz upstream-34a3eaf07f6a814d77cbdaa6c8a14604a37f7784.tar.bz2 upstream-34a3eaf07f6a814d77cbdaa6c8a14604a37f7784.zip |
ltq-deu: changes for hash multithread callers and md5 endianess
The algorithms sha1, sha1_hmac and md5_hmac all use ENDI=1. The md5
algorithm uses ENDI=0 and the endian_swap methods to reverse the
endianess switch by using user CPU time, which is unnecessary overhead.
Danube and AR9 devices do not set endianess for SHA1, so is done for
MD5.
Furthermore the patch replaces endian_swap with le32_to_cpu for md5 and
md5 hmac algorithms and removes endian_swap for them.
The init functions initialize the algorithm in the hardware. The lock is
not used to write to the control register. If another thread calls
another hash algo before update or final, the result will be wrong.
Therefore move the algorithm init to the lock protected sections in the
transform or final methods.
Setting the hw key for the hmac algorithms is now done from within the
lock protected sections in their final methods. The lock protecting is
removed from the _hmac_setkey_hw functions.
In final for md5 and sha1 the lock section is removed, because all the
work was already done in transform (which is called from final). As such
only copying the hash to the output is required.
MD5 and MD5_HMAC produce 16 byte hashes (4 DWORDS) only, therefor
writing register D5R to the hash output is removed for MD5_HMAC.
Signed-off-by: Daniel Kestrel <kestrel1974@t-online.de>
Diffstat (limited to 'BSDmakefile')
0 files changed, 0 insertions, 0 deletions