From: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
To: Herbert Xu <herbert@gondor.apana.org.au>
Cc: "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, 17 Mar 2023 10:01:44 +0100 [thread overview]
Message-ID: <e7cd7252-9cc6-0970-b0e2-35fccde45e86@linaro.org> (raw)
In-Reply-To: <ZBQlKMTcTm1yjete@gondor.apana.org.au>
On 17/03/2023 09:30, Herbert Xu wrote:
> On Fri, Mar 17, 2023 at 09:12:05AM +0100, Krzysztof Kozlowski wrote:
>>
>> The missing dependency on OF is not a problem. The OF code is prepare
>> and will work fine if the driver is built with !OF. The point is that
>> with !OF after dropping of_match_ptr(), the driver could match via ACPI
>> (PRP0001). If we make it depending on OF, the driver won't be able to
>> use it, unless kernel is built with OF which is unlikely for ACPI systems.
>
> I know it works now, but what I'm saying is that if struct device_driver
> actually had of_match_table as conditional on OF, which ideally it
> should, then removing of_match_ptr will break the build.
>
> I know that it's currently unconditionally defined, but that's
> just wasting memory on non-OF machines such as x86.
That's not true. There is no waste because having it on x86 allows to
match via ACPI PRP0001. It's on purpose there.
> So either this driver is OF-only, in which case you can drop
> the of_match_ptr but must add a dependency on OF. Or it's not
> OF-only, in which case you should use of_match_ptr.
There are OF-drivers used on ACPI and x86/arm64.
The true question is whether this device will be ever used on ACPI via
PRP0001, but you are not referring to this?
Best regards,
Krzysztof
next prev parent reply other threads:[~2023-03-17 9:03 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 [this message]
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
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=e7cd7252-9cc6-0970-b0e2-35fccde45e86@linaro.org \
--to=krzysztof.kozlowski@linaro.org \
--cc=alexandre.belloni@bootlin.com \
--cc=claudiu.beznea@microchip.com \
--cc=davem@davemloft.net \
--cc=herbert@gondor.apana.org.au \
--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