[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <ZPAoRvMYbsoNfnLk@gondor.apana.org.au>
Date: Thu, 31 Aug 2023 13:42:30 +0800
From: Herbert Xu <herbert@...dor.apana.org.au>
To: Yang Shen <shenyang39@...wei.com>
Cc: Linus Torvalds <torvalds@...ux-foundation.org>, ardb@...nel.org,
kees@...nel.org, linux-kernel@...r.kernel.org, enlin.mu@...soc.com,
ebiggers@...gle.com, gpiccoli@...lia.com, willy@...radead.org,
yunlong.xing@...soc.com, yuxiaozhang@...gle.com,
Giovanni Cabiddu <giovanni.cabiddu@...el.com>,
qat-linux@...el.com,
Linux Crypto Mailing List <linux-crypto@...r.kernel.org>,
Zhou Wang <wangzhou1@...ilicon.com>
Subject: Re: [PATCH 1/4] crypto: hisilicon/zip - Remove driver
On Thu, Aug 31, 2023 at 10:21:52AM +0800, Yang Shen wrote:
>
> It's a pity to see that there is no user in the kernel of zlib-deflate.
> However, there may still be hidden
> users in the current kernel who may be using the zlib-deflate algorithm.
> Such as zswap, it can use
> user-specified algorithm. So there are still some benefits to be gained from
> zlib hardware.
Perhaps you should try reconstructing the zlib header in your
driver so that it becomes capable of handling "deflate" data as
is rather than adding the non-standard "zlib-deflate" algorithm?
There is no way of getting the checksum without decompressing
the data first but perhaps your hardware could ignore checksum
errors?
> What's more, hisilicon zip driver also does other work besides supporting
> the zlib-deflate:
> 1.Support gzip algorithm.
We don't even have a generic "gzip" implementation so this should
never have gone into the kernel.
> 2.Support a user space cdev hisi-zip which can accelerate user space process
> via uacce subsystem.
Feel free to resubmit this as a new driver but it doesn't belong
in drivers/crypto.
Cheers,
--
Email: Herbert Xu <herbert@...dor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
Powered by blists - more mailing lists