From: Rafael J. Wysocki <[email protected]>
The ACPI_MODULE_NAME() definition is only used by the message
printing macros from ACPICA that are not used by the code in
question, so it is redundant. Drop it.
No functional impact.
Signed-off-by: Rafael J. Wysocki <[email protected]>
---
drivers/i2c/busses/i2c-scmi.c | 2 --
1 file changed, 2 deletions(-)
Index: linux-pm/drivers/i2c/busses/i2c-scmi.c
===================================================================
--- linux-pm.orig/drivers/i2c/busses/i2c-scmi.c
+++ linux-pm/drivers/i2c/busses/i2c-scmi.c
@@ -18,8 +18,6 @@
/* SMBUS HID definition as supported by Microsoft Windows */
#define ACPI_SMBUS_MS_HID "SMB0001"
-ACPI_MODULE_NAME("smbus_cmi");
-
struct smbus_methods_t {
char *mt_info;
char *mt_sbr;
On Fri, Mar 5, 2021 at 7:29 PM Rafael J. Wysocki <[email protected]> wrote:
>
> From: Rafael J. Wysocki <[email protected]>
>
> The ACPI_MODULE_NAME() definition is only used by the message
> printing macros from ACPICA that are not used by the code in
> question, so it is redundant. Drop it.
>
> No functional impact.
>
> Signed-off-by: Rafael J. Wysocki <[email protected]>
If there are no concerns regarding this, I'll queue it up for 5.13 in
the ACPI tree, thanks!
> ---
> drivers/i2c/busses/i2c-scmi.c | 2 --
> 1 file changed, 2 deletions(-)
>
> Index: linux-pm/drivers/i2c/busses/i2c-scmi.c
> ===================================================================
> --- linux-pm.orig/drivers/i2c/busses/i2c-scmi.c
> +++ linux-pm/drivers/i2c/busses/i2c-scmi.c
> @@ -18,8 +18,6 @@
> /* SMBUS HID definition as supported by Microsoft Windows */
> #define ACPI_SMBUS_MS_HID "SMB0001"
>
> -ACPI_MODULE_NAME("smbus_cmi");
> -
> struct smbus_methods_t {
> char *mt_info;
> char *mt_sbr;
>
>
>
On Wed, Mar 10, 2021 at 03:47:10PM +0100, Rafael J. Wysocki wrote:
> On Fri, Mar 5, 2021 at 7:29 PM Rafael J. Wysocki <[email protected]> wrote:
> >
> > From: Rafael J. Wysocki <[email protected]>
> >
> > The ACPI_MODULE_NAME() definition is only used by the message
> > printing macros from ACPICA that are not used by the code in
> > question, so it is redundant. Drop it.
> >
> > No functional impact.
> >
> > Signed-off-by: Rafael J. Wysocki <[email protected]>
>
> If there are no concerns regarding this, I'll queue it up for 5.13 in
> the ACPI tree, thanks!
I'd prefer the I2C tree a tad to avoid conflicts. Any reason for the
ACPI tree?
On Wed, Mar 10, 2021 at 5:08 PM Wolfram Sang <[email protected]> wrote:
>
> On Wed, Mar 10, 2021 at 03:47:10PM +0100, Rafael J. Wysocki wrote:
> > On Fri, Mar 5, 2021 at 7:29 PM Rafael J. Wysocki <[email protected]> wrote:
> > >
> > > From: Rafael J. Wysocki <[email protected]>
> > >
> > > The ACPI_MODULE_NAME() definition is only used by the message
> > > printing macros from ACPICA that are not used by the code in
> > > question, so it is redundant. Drop it.
> > >
> > > No functional impact.
> > >
> > > Signed-off-by: Rafael J. Wysocki <[email protected]>
> >
> > If there are no concerns regarding this, I'll queue it up for 5.13 in
> > the ACPI tree, thanks!
>
> I'd prefer the I2C tree a tad to avoid conflicts. Any reason for the
> ACPI tree?
There are some patches doing this type of a cleanup in the ACPI tree,
but this is the only reason, so please route it through the i2c tree
if that is preferred.
On Fri, Mar 05, 2021 at 07:28:30PM +0100, Rafael J. Wysocki wrote:
> From: Rafael J. Wysocki <[email protected]>
>
> The ACPI_MODULE_NAME() definition is only used by the message
> printing macros from ACPICA that are not used by the code in
> question, so it is redundant. Drop it.
>
> No functional impact.
>
> Signed-off-by: Rafael J. Wysocki <[email protected]>
Applied to for-next, thanks!