mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: "Arnd Bergmann" <arnd@arndb.de>
To: "Jijie Shao" <shaojijie@huawei.com>,
	"Arnd Bergmann" <arnd@kernel.org>,
	"Jian Shen" <shenjian15@huawei.com>,
	"Salil Mehta" <salil.mehta@huawei.com>,
	"Andrew Lunn" <andrew+netdev@lunn.ch>,
	"David S . Miller" <davem@davemloft.net>,
	"Eric Dumazet" <edumazet@google.com>,
	"Jakub Kicinski" <kuba@kernel.org>,
	"Paolo Abeni" <pabeni@redhat.com>
Cc: "Simon Horman" <horms@kernel.org>,
	"Uwe Kleine-König" <u.kleine-koenig@baylibre.com>,
	"Krzysztof Kozlowski" <krzysztof.kozlowski@linaro.org>,
	Netdev <netdev@vger.kernel.org>,
	linux-kernel@vger.kernel.org
Subject: Re: [PATCH 1/2] net: hisilicon: hns_mdio: remove incorrect ACPI_PTR annotation
Date: Thu, 27 Feb 2025 13:03:05 +0100	[thread overview]
Message-ID: <c28e16ce-d535-4af4-972b-e19376833235@app.fastmail.com> (raw)
In-Reply-To: <3e477135-981f-49bd-8e54-0c3ecdcc8a19@huawei.com>

On Thu, Feb 27, 2025, at 12:53, Jijie Shao wrote:
>
> if CONFIG_ACPI is disabled, ACPI_PTR() will return NULL, so
> hns_mdio_acpi_match is unused variable.
>
>
> So use #ifdef is possible and has no side effects, and many drivers do so.

Those should be cleaned up eventually, but that is separate from
the build warning.

> Of course, it also seems possible to remove ACPI_PTR(),
> But I'm not sure if it's okay to set a value to acpi_match_table if 
> CONFIG_ACPI is disabled.

Setting .acpi_match_table and .of_match_table unconditionally
is the normal case. Historically we had some drivers that
used of_match_ptr() to assign the .of_match_table in order
to allow drivers to #ifdef out the CONFIG_OF portion of the
driver for platforms that did not already use devicetree
based probing.

There are basically no platforms left that have not been
converted to devicetree yet, so there is no point in
micro-optimizing the kernel size for that case, but the
(mis)use of of_match_ptr() has been copied into drivers
after that, and most of the ACPI_PTR() users unfortunately
copied from that when drivers started supporting both.

     Arnd

  reply	other threads:[~2025-02-27 12:05 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-02-25 16:33 Arnd Bergmann
2025-02-25 16:33 ` [PATCH 2/2] net: xgene-v2: " Arnd Bergmann
2025-02-26  3:21 ` [PATCH 1/2] net: hisilicon: hns_mdio: " Jijie Shao
2025-02-26  6:49   ` Arnd Bergmann
2025-02-27 11:53     ` Jijie Shao
2025-02-27 12:03       ` Arnd Bergmann [this message]
2025-02-27 12:41         ` Paolo Abeni
2025-02-27 12:50 ` patchwork-bot+netdevbpf

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=c28e16ce-d535-4af4-972b-e19376833235@app.fastmail.com \
    --to=arnd@arndb.de \
    --cc=andrew+netdev@lunn.ch \
    --cc=arnd@kernel.org \
    --cc=davem@davemloft.net \
    --cc=edumazet@google.com \
    --cc=horms@kernel.org \
    --cc=krzysztof.kozlowski@linaro.org \
    --cc=kuba@kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=netdev@vger.kernel.org \
    --cc=pabeni@redhat.com \
    --cc=salil.mehta@huawei.com \
    --cc=shaojijie@huawei.com \
    --cc=shenjian15@huawei.com \
    --cc=u.kleine-koenig@baylibre.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

all inboxes | Powered by JetHome®