Driver name is part of the ABI, so it should be hard-coded, as ABI
should be always kept backward compatible. Prevent ABI from changing
accidentally in case KBUILD_MODNAME change.
Suggested-by: Andy Shevchenko <[email protected]>
Signed-off-by: Michal Wilczynski <[email protected]>
---
drivers/acpi/nfit/core.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/acpi/nfit/core.c b/drivers/acpi/nfit/core.c
index f09530d2520a..987eb5567036 100644
--- a/drivers/acpi/nfit/core.c
+++ b/drivers/acpi/nfit/core.c
@@ -3478,7 +3478,7 @@ MODULE_DEVICE_TABLE(acpi, acpi_nfit_ids);
static struct platform_driver acpi_nfit_driver = {
.probe = acpi_nfit_probe,
.driver = {
- .name = KBUILD_MODNAME,
+ .name = "nfit",
.acpi_match_table = acpi_nfit_ids,
},
};
--
2.41.0
On Mon, Sep 25, 2023 at 05:48:42PM +0300, Michal Wilczynski wrote:
> Driver name is part of the ABI, so it should be hard-coded, as ABI
> should be always kept backward compatible. Prevent ABI from changing
> accidentally in case KBUILD_MODNAME change.
This is up to maintainers, probably we won't have any users outside of existing
model (instantiating via ACPI ID). All the above is "strictly speaking"...
--
With Best Regards,
Andy Shevchenko
Andy Shevchenko wrote:
> On Mon, Sep 25, 2023 at 05:48:42PM +0300, Michal Wilczynski wrote:
> > Driver name is part of the ABI, so it should be hard-coded, as ABI
> > should be always kept backward compatible. Prevent ABI from changing
> > accidentally in case KBUILD_MODNAME change.
>
> This is up to maintainers, probably we won't have any users outside of existing
> model (instantiating via ACPI ID). All the above is "strictly speaking"...
...right, more than 8 years for this "risk" to materialize indicates
it's a non-issue to me.