From: Arnd Bergmann <arnd@kernel.org>
To: Randy Dunlap <rdunlap@infradead.org>
Cc: Jason Gunthorpe <jgg@ziepe.ca>, Leon Romanovsky <leon@kernel.org>,
Arnd Bergmann <arnd@arndb.de>, Zhu Yanjun <zyjzyj2000@gmail.com>,
Julian Braha <julianbraha@gmail.com>,
Doug Ledford <dledford@redhat.com>,
RDMA mailing list <linux-rdma@vger.kernel.org>,
LKML <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH] drivers: infiniband: sw: rxe: fix kconfig dependency on CRYPTO
Date: Tue, 23 Feb 2021 21:40:29 +0100 [thread overview]
Message-ID: <CAK8P3a194XrKArryJbL+FQoza08xB3FOepyXxBxZAF7ChYkLZQ@mail.gmail.com> (raw)
In-Reply-To: <CAK8P3a3z0_TNWP7TAVcZC8+MDJKhAZMbQoEH8tgfLQy2MJmG0Q@mail.gmail.com>
On Tue, Feb 23, 2021 at 9:36 PM Arnd Bergmann <arnd@kernel.org> wrote:
>
> For the specific case of CRC32, it might actually a good idea to change
> the code to call into the CRC32 code directly instead of the CRYPTO_CRC32
> abstraction. Would that work for RDMA_RXE?
On the more general question of whether a driver should 'select CRYPTO',
this is how it's currently done for the other users, but I don't
actually like this,
and in general recommend against force-enabling another subsystem when
a particular driver is enabled.
My preference would be to change all drivers that require crypto services
of some kind to use 'depends on CRYPTO' in combination with 'select CRYPTO_*',
as this is what we do for other cross-subsystem dependencies. However,
it seems unlikely that we can change it anytime soon, as the current method
is widespread and changing the dependencies would break users that do
'make oldconfig' on an old configuration.
Arnd
next prev parent reply other threads:[~2021-02-23 20:41 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-02-19 23:32 [PATCH] drivers: infiniband: sw: rxe: fix kconfig dependency on CRYPTO Julian Braha
2021-02-21 6:48 ` Leon Romanovsky
2021-02-22 2:39 ` Zhu Yanjun
2021-02-22 13:00 ` Leon Romanovsky
2021-02-22 15:58 ` Jason Gunthorpe
2021-02-22 16:26 ` Randy Dunlap
2021-02-22 16:46 ` Jason Gunthorpe
2021-02-22 16:50 ` Leon Romanovsky
2021-02-22 16:53 ` Randy Dunlap
2021-02-23 20:36 ` Arnd Bergmann
2021-02-23 20:40 ` Arnd Bergmann [this message]
[not found] ` <CAJ-ZY99xZEsS5pCbZ7evi_ohozQBpHcNHDcXxfoeaLzuWRzyzw@mail.gmail.com>
2021-02-23 21:26 ` Arnd Bergmann
2021-02-23 21:54 ` Julian Braha
2021-02-23 22:05 ` Arnd Bergmann
2021-02-24 10:04 ` Leon Romanovsky
2021-03-01 18:48 ` Jason Gunthorpe
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=CAK8P3a194XrKArryJbL+FQoza08xB3FOepyXxBxZAF7ChYkLZQ@mail.gmail.com \
--to=arnd@kernel.org \
--cc=arnd@arndb.de \
--cc=dledford@redhat.com \
--cc=jgg@ziepe.ca \
--cc=julianbraha@gmail.com \
--cc=leon@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-rdma@vger.kernel.org \
--cc=rdunlap@infradead.org \
--cc=zyjzyj2000@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.