From: Herbert Xu <herbert@gondor.apana.org.au>
To: Ard Biesheuvel <ardb@kernel.org>
Cc: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>,
"David S. Miller" <davem@davemloft.net>,
Nicolas Ferre <nicolas.ferre@microchip.com>,
Alexandre Belloni <alexandre.belloni@bootlin.com>,
Claudiu Beznea <claudiu.beznea@microchip.com>,
linux-crypto@vger.kernel.org,
linux-arm-kernel@lists.infradead.org,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH 2/2] crypto - img-hash: Drop of_match_ptr for ID table
Date: Fri, 24 Mar 2023 18:03:58 +0800 [thread overview]
Message-ID: <ZB11jq3qnZUpmMrm@gondor.apana.org.au> (raw)
In-Reply-To: <CAMj1kXH3oZhO=dMBmLzNO_nScJBjcjwUqy2sZbCJwmMS1XtLKg@mail.gmail.com>
On Thu, Mar 23, 2023 at 09:43:58AM +0100, Ard Biesheuvel wrote:
>
> No. PRP0001 support in ACPI does not depend on OF, so drivers that may
> be bound to such devices should not either.
>
> If you are concerned about the memory used by such tables, you can
> always propose making PRP0001 support configurable in the ACPI core,
> but making individual devices depend on OF for PRP0001 matching seems
> wrong to me.
What I am against is removing of_match_ptr by doing a million
tiny patches. Either we should keep it, in which case the
of_match_table field should be made conditional on OF or perhaps
a new Kconfig option if there is no way to reconcile this with
ACPI, or we decide to get rid of it and you should do one giant
patch to remove of_match_ptr across the kernel tree.
We should not be doing a patch for every single driver that has
of_match_table based on whether it can or cannot be used through
ACPI.
Cheers,
--
Email: Herbert Xu <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
next prev parent reply other threads:[~2023-03-24 10:04 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-03-10 22:30 [PATCH 1/2] crypto - atmel-sha204a: Mark OF related data as maybe unused Krzysztof Kozlowski
2023-03-10 22:30 ` [PATCH 2/2] crypto - img-hash: Drop of_match_ptr for ID table Krzysztof Kozlowski
2023-03-17 3:04 ` Herbert Xu
2023-03-17 8:12 ` Krzysztof Kozlowski
2023-03-17 8:30 ` Herbert Xu
2023-03-17 9:01 ` Krzysztof Kozlowski
2023-03-17 9:15 ` Herbert Xu
2023-03-17 9:22 ` Krzysztof Kozlowski
2023-03-23 8:43 ` Ard Biesheuvel
2023-03-24 10:03 ` Herbert Xu [this message]
2023-03-17 3:28 ` [PATCH 1/2] crypto - atmel-sha204a: Mark OF related data as maybe unused Herbert Xu
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=ZB11jq3qnZUpmMrm@gondor.apana.org.au \
--to=herbert@gondor.apana.org.au \
--cc=alexandre.belloni@bootlin.com \
--cc=ardb@kernel.org \
--cc=claudiu.beznea@microchip.com \
--cc=davem@davemloft.net \
--cc=krzysztof.kozlowski@linaro.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-crypto@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=nicolas.ferre@microchip.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox