But I think it can be changed to:
+ #ifdef CONFIG_ACPI
static const struct acpi_device_id hns_mdio_acpi_match[] = {
{ "HISI0141", 0 },
{ },
};
MODULE_DEVICE_TABLE(acpi, hns_mdio_acpi_match);
+ #endif
That would of course avoid the build warning, but otherwise
would be worse: the only reason ACPI_PTR()/of_match_ptr() exist
is to work around drivers that have to put their device ID
table inside of an #ifdef for some other reason. Adding the
#ifdef to work around an incorrect ACPI_PTR() makes no sense.
Arnd
But I think it can be changed to:
+ #ifdef CONFIG_ACPI
static const struct acpi_device_id hns_mdio_acpi_match[] = {
{ "HISI0141", 0 },
{ },
};
MODULE_DEVICE_TABLE(acpi, hns_mdio_acpi_match);
+ #endif
That would of course avoid the build warning, but otherwise
would be worse: the only reason ACPI_PTR()/of_match_ptr() exist
is to work around drivers that have to put their device ID
table inside of an #ifdef for some other reason. Adding the
#ifdef to work around an incorrect ACPI_PTR() makes no sense.
Arnd
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.
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.
It need maintainer to look at this.
Thanks,
Jijie Shao
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
From: Paolo Abeni <pabeni@redhat.com> Date: 2025-02-27 12:41:09
On 2/27/25 1:03 PM, Arnd Bergmann wrote:
On Thu, Feb 27, 2025, at 12:53, Jijie Shao wrote:
quoted
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.
quoted
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.
Hello:
This series was applied to netdev/net-next.git (main)
by Paolo Abeni [off-list ref]:
On Tue, 25 Feb 2025 17:33:32 +0100 you wrote:
From: Arnd Bergmann <arnd@arndb.de>
Building with W=1 shows a warning about hns_mdio_acpi_match being unused when
CONFIG_ACPI is disabled:
drivers/net/ethernet/hisilicon/hns_mdio.c:631:36: error: unused variable 'hns_mdio_acpi_match' [-Werror,-Wunused-const-variable]
[...]