[PATCH v1 00/10] platform/x86: Stop using acpi_device_name/class()

[PATCH v1 00/10] platform/x86: Stop using acpi_device_name/class()

[Rafael J. Wysocki]

Hi All,

There are two fields in struct acpi_device_pnp, device_name and device_class,
that were supposed to be populated and used by device drivers, but they have
never been used consistently and some drivers just populate them and don't
access them later, and some drivers use them uninitialized.

All of that is confusing and messy, so the drivers for core ACPI devices
have been updated to stop using those fields which are now slated for
removal, but they are still accessed in some places.

This series updates platform x86 drivers accessing those fields to stop
doing that.

Thanks!

[PATCH v1 01/10] platform/x86: asus-laptop: Stop setting acpi_device_name/class()

[Rafael J. Wysocki]

From: "Rafael J. Wysocki" <rafael.j.wysocki@intel.com>

The driver sets acpi_device_name() which is never read afterward,
so make it stop doing that and drop the symbol defined specifically
for this purpose.

Likewise, acpi_device_class() set by the driver is only used for
generating ACPI netlink events, but the "hotkey" string literal may
as well be used directly for that, so make the driver do so and stop
setting acpi_device_class(), and drop the symbol defined specifically
for this purpose.

No intentional functional impact.

Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
---
 drivers/platform/x86/asus-laptop.c | 9 ++-------
 1 file changed, 2 insertions(+), 7 deletions(-)

diff --git a/drivers/platform/x86/asus-laptop.c b/drivers/platform/x86/asus-laptop.c
index 140ac8a10537..449addd1ac7a 100644
--- a/drivers/platform/x86/asus-laptop.c
+++ b/drivers/platform/x86/asus-laptop.c
@@ -42,8 +42,6 @@
 #define ASUS_LAPTOP_VERSION	"0.42"
 
 #define ASUS_LAPTOP_NAME	"Asus Laptop Support"
-#define ASUS_LAPTOP_CLASS	"hotkey"
-#define ASUS_LAPTOP_DEVICE_NAME	"Hotkey"
 #define ASUS_LAPTOP_FILE	KBUILD_MODNAME
 #define ASUS_LAPTOP_PREFIX	"\\_SB.ATKD."
 
@@ -1524,9 +1522,8 @@ static void asus_acpi_notify(acpi_handle handle, u32 event, void *data)
 
 	/* TODO Find a better way to handle events count. */
 	count = asus->event_count[event % 128]++;
-	acpi_bus_generate_netlink_event(asus->device->pnp.device_class,
-					dev_name(&asus->device->dev), event,
-					count);
+	acpi_bus_generate_netlink_event("hotkey", dev_name(&asus->device->dev),
+					event, count);
 
 	if (event >= ATKD_BRNUP_MIN && event <= ATKD_BRNUP_MAX)
 		event = ATKD_BRNUP;
@@ -1840,8 +1837,6 @@ static int asus_acpi_probe(struct platform_device *pdev)
 	if (!asus)
 		return -ENOMEM;
 	asus->handle = device->handle;
-	strscpy(acpi_device_name(device), ASUS_LAPTOP_DEVICE_NAME);
-	strscpy(acpi_device_class(device), ASUS_LAPTOP_CLASS);
 	asus->device = device;
 
 	asus_dmi_check();
-- 
2.51.0

[PATCH v1 02/10] platform/x86: eeepc-laptop: Stop setting acpi_device_name/class()

[Rafael J. Wysocki]

From: "Rafael J. Wysocki" <rafael.j.wysocki@intel.com>

The driver sets acpi_device_name() which is never read afterward,
so make it stop doing that and drop the symbol defined specifically
for this purpose.

Likewise, acpi_device_class() set by the driver is only used for
generating ACPI netlink events, but the "hotkey" string literal may
as well be used directly for that, so make the driver do so and stop
setting acpi_device_class(), and drop the symbol defined specifically
for this purpose.

No intentional functional impact.

Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
---
 drivers/platform/x86/eeepc-laptop.c | 7 +------
 1 file changed, 1 insertion(+), 6 deletions(-)

diff --git a/drivers/platform/x86/eeepc-laptop.c b/drivers/platform/x86/eeepc-laptop.c
index d18a80907611..8a640c25830a 100644
--- a/drivers/platform/x86/eeepc-laptop.c
+++ b/drivers/platform/x86/eeepc-laptop.c
@@ -34,8 +34,6 @@
 #define EEEPC_LAPTOP_NAME	"Eee PC Hotkey Driver"
 #define EEEPC_LAPTOP_FILE	"eeepc"
 
-#define EEEPC_ACPI_CLASS	"hotkey"
-#define EEEPC_ACPI_DEVICE_NAME	"Hotkey"
 #define EEEPC_ACPI_HID		"ASUS010"
 
 MODULE_AUTHOR("Corentin Chary, Eric Cooper");
@@ -1214,8 +1212,7 @@ static void eeepc_acpi_notify(acpi_handle handle, u32 event, void *data)
 	if (event > ACPI_MAX_SYS_NOTIFY)
 		return;
 	count = eeepc->event_count[event % 128]++;
-	acpi_bus_generate_netlink_event(device->pnp.device_class,
-					dev_name(&device->dev), event,
+	acpi_bus_generate_netlink_event("hotkey", dev_name(&device->dev), event,
 					count);
 
 	/* Brightness events are special */
@@ -1376,8 +1373,6 @@ static int eeepc_acpi_probe(struct platform_device *pdev)
 	if (!eeepc)
 		return -ENOMEM;
 	eeepc->handle = device->handle;
-	strscpy(acpi_device_name(device), EEEPC_ACPI_DEVICE_NAME);
-	strscpy(acpi_device_class(device), EEEPC_ACPI_CLASS);
 	eeepc->device = device;
 
 	platform_set_drvdata(pdev, eeepc);
-- 
2.51.0

[PATCH v1 03/10] platform/x86: fujitsu-laptop: Stop setting acpi_device_name/class()

[Rafael J. Wysocki]

From: "Rafael J. Wysocki" <rafael.j.wysocki@intel.com>

The driver sets acpi_device_name() that are only used for printing
messages and initializing input class device names.  Since
ACPI_FUJITSU_BL_DEVICE_NAME and ACPI_FUJITSU_LAPTOP_DEVICE_NAME can
be used directly in all of those cases, make the driver do so and
stop setting acpi_device_name() in it.

Likewise, acpi_device_class() set by the driver are never read
afterward, so make the driver stop setting it and drop the symbol
defined specifically for this purpose.

No intentional functional impact.

Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
---
 drivers/platform/x86/fujitsu-laptop.c | 18 ++++++------------
 1 file changed, 6 insertions(+), 12 deletions(-)

diff --git a/drivers/platform/x86/fujitsu-laptop.c b/drivers/platform/x86/fujitsu-laptop.c
index 54d0b9cec4d3..ea543deef68f 100644
--- a/drivers/platform/x86/fujitsu-laptop.c
+++ b/drivers/platform/x86/fujitsu-laptop.c
@@ -56,7 +56,6 @@
 
 #define FUJITSU_LCD_N_LEVELS		8
 
-#define ACPI_FUJITSU_CLASS		"fujitsu"
 #define ACPI_FUJITSU_BL_HID		"FUJ02B1"
 #define ACPI_FUJITSU_BL_DRIVER_NAME	"Fujitsu laptop FUJ02B1 ACPI brightness driver"
 #define ACPI_FUJITSU_BL_DEVICE_NAME	"Fujitsu FUJ02B1"
@@ -466,7 +465,7 @@ static int acpi_fujitsu_bl_input_setup(struct device *dev)
 	snprintf(priv->phys, sizeof(priv->phys), "%s/video/input0",
 		 acpi_device_hid(device));
 
-	priv->input->name = acpi_device_name(device);
+	priv->input->name = ACPI_FUJITSU_BL_DEVICE_NAME;
 	priv->input->phys = priv->phys;
 	priv->input->id.bustype = BUS_HOST;
 	priv->input->id.product = 0x06;
@@ -546,13 +545,11 @@ static int acpi_fujitsu_bl_probe(struct platform_device *pdev)
 		return -ENOMEM;
 
 	fujitsu_bl = priv;
-	strscpy(acpi_device_name(device), ACPI_FUJITSU_BL_DEVICE_NAME);
-	strscpy(acpi_device_class(device), ACPI_FUJITSU_CLASS);
 
 	platform_set_drvdata(pdev, priv);
 
-	pr_info("ACPI: %s [%s]\n",
-		acpi_device_name(device), acpi_device_bid(device));
+	pr_info("ACPI: %s [%s]\n", ACPI_FUJITSU_BL_DEVICE_NAME,
+		acpi_device_bid(device));
 
 	if (get_max_brightness(&pdev->dev) <= 0)
 		priv->max_brightness = FUJITSU_LCD_N_LEVELS;
@@ -681,7 +678,7 @@ static int acpi_fujitsu_laptop_input_setup(struct device *dev)
 	snprintf(priv->phys, sizeof(priv->phys), "%s/input0",
 		 acpi_device_hid(device));
 
-	priv->input->name = acpi_device_name(device);
+	priv->input->name = ACPI_FUJITSU_LAPTOP_DEVICE_NAME;
 	priv->input->phys = priv->phys;
 	priv->input->id.bustype = BUS_HOST;
 
@@ -1012,9 +1009,6 @@ static int acpi_fujitsu_laptop_probe(struct platform_device *pdev)
 	WARN_ONCE(fext, "More than one FUJ02E3 ACPI device was found.  Driver may not work as intended.");
 	fext = &pdev->dev;
 
-	strscpy(acpi_device_name(device), ACPI_FUJITSU_LAPTOP_DEVICE_NAME);
-	strscpy(acpi_device_class(device), ACPI_FUJITSU_CLASS);
-
 	platform_set_drvdata(pdev, priv);
 
 	/* kfifo */
@@ -1024,8 +1018,8 @@ static int acpi_fujitsu_laptop_probe(struct platform_device *pdev)
 	if (ret)
 		return ret;
 
-	pr_info("ACPI: %s [%s]\n",
-		acpi_device_name(device), acpi_device_bid(device));
+	pr_info("ACPI: %s [%s]\n", ACPI_FUJITSU_LAPTOP_DEVICE_NAME,
+		acpi_device_bid(device));
 
 	while (call_fext_func(fext, FUNC_BUTTONS, 0x1, 0x0, 0x0) != 0 &&
 	       i++ < MAX_HOTKEY_RINGBUFFER_SIZE)
-- 
2.51.0

Re: [PATCH v1 03/10] platform/x86: fujitsu-laptop: Stop setting acpi_device_name/class()

[Jonathan Woithe]

On Fri, Jul 03, 2026 at 01:23:31PM +0200, Rafael J.  Wysocki wrote:
> From: "Rafael J. Wysocki" <rafael.j.wysocki@intel.com>
> 
> The driver sets acpi_device_name() that are only used for printing
> messages and initializing input class device names.  Since
> ACPI_FUJITSU_BL_DEVICE_NAME and ACPI_FUJITSU_LAPTOP_DEVICE_NAME can
> be used directly in all of those cases, make the driver do so and
> stop setting acpi_device_name() in it.
> 
> Likewise, acpi_device_class() set by the driver are never read
> afterward, so make the driver stop setting it and drop the symbol
> defined specifically for this purpose.
> 
> No intentional functional impact.
> 
> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>

Looks good to me for fujitsu-laptop.

Acked-by: Jonathan Woithe <jwoithe@just42.net>


> ---
>  drivers/platform/x86/fujitsu-laptop.c | 18 ++++++------------
>  1 file changed, 6 insertions(+), 12 deletions(-)
> 
> diff --git a/drivers/platform/x86/fujitsu-laptop.c b/drivers/platform/x86/fujitsu-laptop.c
> index 54d0b9cec4d3..ea543deef68f 100644
> --- a/drivers/platform/x86/fujitsu-laptop.c
> +++ b/drivers/platform/x86/fujitsu-laptop.c
> @@ -56,7 +56,6 @@
>  
>  #define FUJITSU_LCD_N_LEVELS		8
>  
> -#define ACPI_FUJITSU_CLASS		"fujitsu"
>  #define ACPI_FUJITSU_BL_HID		"FUJ02B1"
>  #define ACPI_FUJITSU_BL_DRIVER_NAME	"Fujitsu laptop FUJ02B1 ACPI brightness driver"
>  #define ACPI_FUJITSU_BL_DEVICE_NAME	"Fujitsu FUJ02B1"
> @@ -466,7 +465,7 @@ static int acpi_fujitsu_bl_input_setup(struct device *dev)
>  	snprintf(priv->phys, sizeof(priv->phys), "%s/video/input0",
>  		 acpi_device_hid(device));
>  
> -	priv->input->name = acpi_device_name(device);
> +	priv->input->name = ACPI_FUJITSU_BL_DEVICE_NAME;
>  	priv->input->phys = priv->phys;
>  	priv->input->id.bustype = BUS_HOST;
>  	priv->input->id.product = 0x06;
> @@ -546,13 +545,11 @@ static int acpi_fujitsu_bl_probe(struct platform_device *pdev)
>  		return -ENOMEM;
>  
>  	fujitsu_bl = priv;
> -	strscpy(acpi_device_name(device), ACPI_FUJITSU_BL_DEVICE_NAME);
> -	strscpy(acpi_device_class(device), ACPI_FUJITSU_CLASS);
>  
>  	platform_set_drvdata(pdev, priv);
>  
> -	pr_info("ACPI: %s [%s]\n",
> -		acpi_device_name(device), acpi_device_bid(device));
> +	pr_info("ACPI: %s [%s]\n", ACPI_FUJITSU_BL_DEVICE_NAME,
> +		acpi_device_bid(device));
>  
>  	if (get_max_brightness(&pdev->dev) <= 0)
>  		priv->max_brightness = FUJITSU_LCD_N_LEVELS;
> @@ -681,7 +678,7 @@ static int acpi_fujitsu_laptop_input_setup(struct device *dev)
>  	snprintf(priv->phys, sizeof(priv->phys), "%s/input0",
>  		 acpi_device_hid(device));
>  
> -	priv->input->name = acpi_device_name(device);
> +	priv->input->name = ACPI_FUJITSU_LAPTOP_DEVICE_NAME;
>  	priv->input->phys = priv->phys;
>  	priv->input->id.bustype = BUS_HOST;
>  
> @@ -1012,9 +1009,6 @@ static int acpi_fujitsu_laptop_probe(struct platform_device *pdev)
>  	WARN_ONCE(fext, "More than one FUJ02E3 ACPI device was found.  Driver may not work as intended.");
>  	fext = &pdev->dev;
>  
> -	strscpy(acpi_device_name(device), ACPI_FUJITSU_LAPTOP_DEVICE_NAME);
> -	strscpy(acpi_device_class(device), ACPI_FUJITSU_CLASS);
> -
>  	platform_set_drvdata(pdev, priv);
>  
>  	/* kfifo */
> @@ -1024,8 +1018,8 @@ static int acpi_fujitsu_laptop_probe(struct platform_device *pdev)
>  	if (ret)
>  		return ret;
>  
> -	pr_info("ACPI: %s [%s]\n",
> -		acpi_device_name(device), acpi_device_bid(device));
> +	pr_info("ACPI: %s [%s]\n", ACPI_FUJITSU_LAPTOP_DEVICE_NAME,
> +		acpi_device_bid(device));
>  
>  	while (call_fext_func(fext, FUNC_BUTTONS, 0x1, 0x0, 0x0) != 0 &&
>  	       i++ < MAX_HOTKEY_RINGBUFFER_SIZE)
> -- 
> 2.51.0
> 
> 
> 

-- 

[PATCH v1 04/10] platform/x86: fujitsu-tablet: Stop setting acpi_device_name/class()

[Rafael J. Wysocki]

From: "Rafael J. Wysocki" <rafael.j.wysocki@intel.com>

The driver sets acpi_device_class() which is never read afterward,
so make it stop doing that and drop the symbol defined specifically
for this purpose.

For consistency, also make it stop setting acpi_device_name() and add
a name field to the "fujitsu" structure for storing the name string
used during input class device initialization.

While at it, use scnprintf() instead of snprintf() for populating the
name and phys fields of the "fujitsu" structure.

No intentional functional impact.

Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
---
 drivers/platform/x86/fujitsu-tablet.c | 13 ++++---------
 1 file changed, 4 insertions(+), 9 deletions(-)

diff --git a/drivers/platform/x86/fujitsu-tablet.c b/drivers/platform/x86/fujitsu-tablet.c
index 2f8c1b89cbca..386ad3aaace8 100644
--- a/drivers/platform/x86/fujitsu-tablet.c
+++ b/drivers/platform/x86/fujitsu-tablet.c
@@ -22,8 +22,6 @@
 
 #define MODULENAME "fujitsu-tablet"
 
-#define ACPI_FUJITSU_CLASS "fujitsu"
-
 #define INVERT_TABLET_MODE_BIT      0x01
 #define INVERT_DOCK_STATE_BIT       0x02
 #define FORCE_TABLET_MODE_IF_UNDOCK 0x04
@@ -160,6 +158,7 @@ static struct {
 	struct fujitsu_config config;
 	unsigned long prev_keymask;
 
+	char name[17];
 	char phys[21];
 
 	int irq;
@@ -458,14 +457,10 @@ static int acpi_fujitsu_probe(struct platform_device *pdev)
 	if (ACPI_FAILURE(status) || !fujitsu.irq || !fujitsu.io_base)
 		return -ENODEV;
 
-	sprintf(acpi_device_name(adev), "Fujitsu %s", acpi_device_hid(adev));
-	sprintf(acpi_device_class(adev), "%s", ACPI_FUJITSU_CLASS);
-
-	snprintf(fujitsu.phys, sizeof(fujitsu.phys),
-			"%s/input0", acpi_device_hid(adev));
+	scnprintf(fujitsu.name, sizeof(fujitsu.name), "Fujitsu %s", acpi_device_hid(adev));
+	scnprintf(fujitsu.phys, sizeof(fujitsu.phys), "%s/input0", acpi_device_hid(adev));
 
-	error = input_fujitsu_setup(&pdev->dev,
-		acpi_device_name(adev), fujitsu.phys);
+	error = input_fujitsu_setup(&pdev->dev, fujitsu.name, fujitsu.phys);
 	if (error)
 		return error;
 
-- 
2.51.0

[PATCH v1 05/10] platform/x86: thinkpad_acpi: Stop setting acpi_device_class()

[Rafael J. Wysocki]

From: "Rafael J. Wysocki" <rafael.j.wysocki@intel.com>

To facilitate the removal of device_class from struct acpi_device_pnp
in the future, make the driver store the device class string used for
generating ACPI netlink events in a new device_class field in struct
ibm_struct.

No intentional functional impact.

Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
---
 drivers/platform/x86/lenovo/thinkpad_acpi.c | 10 +++++-----
 1 file changed, 5 insertions(+), 5 deletions(-)

diff --git a/drivers/platform/x86/lenovo/thinkpad_acpi.c b/drivers/platform/x86/lenovo/thinkpad_acpi.c
index 445e1403308e..f614b2701d48 100644
--- a/drivers/platform/x86/lenovo/thinkpad_acpi.c
+++ b/drivers/platform/x86/lenovo/thinkpad_acpi.c
@@ -309,6 +309,7 @@ struct tp_acpi_drv_struct {
 
 struct ibm_struct {
 	char *name;
+	acpi_device_class device_class;
 
 	int (*read) (struct seq_file *);
 	int (*write) (char *);
@@ -838,9 +839,8 @@ static int __init setup_acpi_notify(struct ibm_struct *ibm)
 	}
 
 	ibm->acpi->device->driver_data = ibm;
-	scnprintf(acpi_device_class(ibm->acpi->device),
-		  sizeof(acpi_device_class(ibm->acpi->device)),
-		  "%s/%s", TPACPI_ACPI_EVENT_PREFIX, ibm->name);
+	scnprintf(ibm->device_class, sizeof(ibm->device_class), "%s/%s",
+		  TPACPI_ACPI_EVENT_PREFIX, ibm->name);
 
 	status = acpi_install_notify_handler(*ibm->acpi->handle,
 			ibm->acpi->type, dispatch_acpi_notify, ibm);
@@ -3869,7 +3869,7 @@ static void hotkey_notify(struct ibm_struct *ibm, u32 event)
 		pr_err("unknown HKEY notification event %d\n", event);
 		/* forward it to userspace, maybe it knows how to handle it */
 		acpi_bus_generate_netlink_event(
-					ibm->acpi->device->pnp.device_class,
+					ibm->device_class,
 					dev_name(&ibm->acpi->device->dev),
 					event, 0);
 		return;
@@ -3949,7 +3949,7 @@ static void hotkey_notify(struct ibm_struct *ibm, u32 event)
 		/* netlink events */
 		if (send_acpi_ev) {
 			acpi_bus_generate_netlink_event(
-					ibm->acpi->device->pnp.device_class,
+					ibm->device_class,
 					dev_name(&ibm->acpi->device->dev),
 					event, hkey);
 		}
-- 
2.51.0

Re: [PATCH v1 05/10] platform/x86: thinkpad_acpi: Stop setting acpi_device_class()

[Andy Shevchenko]

On Fri, Jul 03, 2026 at 01:30:00PM +0200, Rafael J.  Wysocki wrote:

> To facilitate the removal of device_class from struct acpi_device_pnp
> in the future, make the driver store the device class string used for
> generating ACPI netlink events in a new device_class field in struct
> ibm_struct.
> 
> No intentional functional impact.

...

>  		acpi_bus_generate_netlink_event(
> -					ibm->acpi->device->pnp.device_class,
> +					ibm->device_class,
>  					dev_name(&ibm->acpi->device->dev),
>  					event, 0);

In other cases you condensed the code a bit, not sure if you want to do the
similar here

		acpi_bus_generate_netlink_event(ibm->device_class,
						dev_name(&ibm->acpi->device->dev),
						event, 0);

>  		return;

...

>  		if (send_acpi_ev) {
>  			acpi_bus_generate_netlink_event(
> -					ibm->acpi->device->pnp.device_class,
> +					ibm->device_class,
>  					dev_name(&ibm->acpi->device->dev),
>  					event, hkey);
>  		}

Ditto.

-- 
With Best Regards,
Andy Shevchenko

Re: [PATCH v1 05/10] platform/x86: thinkpad_acpi: Stop setting acpi_device_class()

[Rafael J. Wysocki (Intel)]

On Fri, Jul 3, 2026 at 2:18 PM Andy Shevchenko
<andriy.shevchenko@linux.intel.com> wrote:
>
> On Fri, Jul 03, 2026 at 01:30:00PM +0200, Rafael J.  Wysocki wrote:
>
> > To facilitate the removal of device_class from struct acpi_device_pnp
> > in the future, make the driver store the device class string used for
> > generating ACPI netlink events in a new device_class field in struct
> > ibm_struct.
> >
> > No intentional functional impact.
>
> ...
>
> >               acpi_bus_generate_netlink_event(
> > -                                     ibm->acpi->device->pnp.device_class,
> > +                                     ibm->device_class,
> >                                       dev_name(&ibm->acpi->device->dev),
> >                                       event, 0);
>
> In other cases you condensed the code a bit, not sure if you want to do the
> similar here
>
>                 acpi_bus_generate_netlink_event(ibm->device_class,
>                                                 dev_name(&ibm->acpi->device->dev),
>                                                 event, 0);
>
> >               return;
>
> ...
>
> >               if (send_acpi_ev) {
> >                       acpi_bus_generate_netlink_event(
> > -                                     ibm->acpi->device->pnp.device_class,
> > +                                     ibm->device_class,
> >                                       dev_name(&ibm->acpi->device->dev),
> >                                       event, hkey);
> >               }
>
> Ditto.

It can go both ways and I settled for changing fewer code lines.

Re: [PATCH v1 05/10] platform/x86: thinkpad_acpi: Stop setting acpi_device_class()

[Mark Pearson]

On Fri, Jul 3, 2026, at 7:30 AM, Rafael J.  Wysocki wrote:
> From: "Rafael J. Wysocki" <rafael.j.wysocki@intel.com>
>
> To facilitate the removal of device_class from struct acpi_device_pnp
> in the future, make the driver store the device class string used for
> generating ACPI netlink events in a new device_class field in struct
> ibm_struct.
>
> No intentional functional impact.
>
> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
> ---
>  drivers/platform/x86/lenovo/thinkpad_acpi.c | 10 +++++-----
>  1 file changed, 5 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/platform/x86/lenovo/thinkpad_acpi.c 
> b/drivers/platform/x86/lenovo/thinkpad_acpi.c
> index 445e1403308e..f614b2701d48 100644
> --- a/drivers/platform/x86/lenovo/thinkpad_acpi.c
> +++ b/drivers/platform/x86/lenovo/thinkpad_acpi.c
> @@ -309,6 +309,7 @@ struct tp_acpi_drv_struct {
> 
>  struct ibm_struct {
>  	char *name;
> +	acpi_device_class device_class;
> 
>  	int (*read) (struct seq_file *);
>  	int (*write) (char *);
> @@ -838,9 +839,8 @@ static int __init setup_acpi_notify(struct ibm_struct *ibm)
>  	}
> 
>  	ibm->acpi->device->driver_data = ibm;
> -	scnprintf(acpi_device_class(ibm->acpi->device),
> -		  sizeof(acpi_device_class(ibm->acpi->device)),
> -		  "%s/%s", TPACPI_ACPI_EVENT_PREFIX, ibm->name);
> +	scnprintf(ibm->device_class, sizeof(ibm->device_class), "%s/%s",
> +		  TPACPI_ACPI_EVENT_PREFIX, ibm->name);
> 
>  	status = acpi_install_notify_handler(*ibm->acpi->handle,
>  			ibm->acpi->type, dispatch_acpi_notify, ibm);
> @@ -3869,7 +3869,7 @@ static void hotkey_notify(struct ibm_struct *ibm, 
> u32 event)
>  		pr_err("unknown HKEY notification event %d\n", event);
>  		/* forward it to userspace, maybe it knows how to handle it */
>  		acpi_bus_generate_netlink_event(
> -					ibm->acpi->device->pnp.device_class,
> +					ibm->device_class,
>  					dev_name(&ibm->acpi->device->dev),
>  					event, 0);
>  		return;
> @@ -3949,7 +3949,7 @@ static void hotkey_notify(struct ibm_struct *ibm, 
> u32 event)
>  		/* netlink events */
>  		if (send_acpi_ev) {
>  			acpi_bus_generate_netlink_event(
> -					ibm->acpi->device->pnp.device_class,
> +					ibm->device_class,
>  					dev_name(&ibm->acpi->device->dev),
>  					event, hkey);
>  		}
> -- 
> 2.51.0

Looks good to me.
Reviewed-by: Mark Pearson <mpearson-lenovo@squebb.ca>

[PATCH v1 06/10] platform/x86: panasonic-laptop: Stop setting acpi_device_name/class()

[Rafael J. Wysocki (Intel)]

From: "Rafael J. Wysocki" <rafael.j.wysocki@intel.com>

The driver sets acpi_device_name() and acpi_device_class() which are
never read afterward, so make it stop doing that and drop the symbols
defined specifically for this purpose.

No intentional functional impact.

Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
---
 drivers/platform/x86/panasonic-laptop.c | 4 ----
 1 file changed, 4 deletions(-)

diff --git a/drivers/platform/x86/panasonic-laptop.c b/drivers/platform/x86/panasonic-laptop.c
index 719add753cb3..3effb11c4153 100644
--- a/drivers/platform/x86/panasonic-laptop.c
+++ b/drivers/platform/x86/panasonic-laptop.c
@@ -159,8 +159,6 @@ MODULE_LICENSE("GPL");
 #define ECO_MODE_ON		0x80
 
 #define ACPI_PCC_DRIVER_NAME	"Panasonic Laptop Support"
-#define ACPI_PCC_DEVICE_NAME	"Hotkey"
-#define ACPI_PCC_CLASS		"pcc"
 
 #define ACPI_PCC_INPUT_PHYS	"panasonic/hkey0"
 
@@ -1017,8 +1015,6 @@ static int acpi_pcc_hotkey_probe(struct platform_device *pdev)
 	pcc->device = device;
 	pcc->handle = device->handle;
 	device->driver_data = pcc;
-	strscpy(acpi_device_name(device), ACPI_PCC_DEVICE_NAME);
-	strscpy(acpi_device_class(device), ACPI_PCC_CLASS);
 
 	result = acpi_pcc_init_input(pcc);
 	if (result) {
-- 
2.51.0

[PATCH v1 07/10] platform/x86: sony-laptop: Stop setting acpi_device_class()

[Rafael J. Wysocki]

From: "Rafael J. Wysocki" <rafael.j.wysocki@intel.com>

Since acpi_device_class() set by the driver is only used for generating
ACPI netlink events and the "sony/hotkey" string literal may as well be
used directly for this purpose, make the driver do so and stop setting
acpi_device_class() in it.

No intentional functional impact.

Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
---
 drivers/platform/x86/sony-laptop.c | 5 +----
 1 file changed, 1 insertion(+), 4 deletions(-)

diff --git a/drivers/platform/x86/sony-laptop.c b/drivers/platform/x86/sony-laptop.c
index 67370967df6f..0bf4d3054e37 100644
--- a/drivers/platform/x86/sony-laptop.c
+++ b/drivers/platform/x86/sony-laptop.c
@@ -1264,7 +1264,7 @@ static void sony_nc_notify(acpi_handle ah, u32 event, void *data)
 		ev_type = HOTKEY;
 		sony_laptop_report_input_event(real_ev);
 	}
-	acpi_bus_generate_netlink_event(sony_nc_acpi_device->pnp.device_class,
+	acpi_bus_generate_netlink_event("sony/hotkey",
 			dev_name(&sony_nc_acpi_device->dev), ev_type, real_ev);
 }
 
@@ -3157,8 +3157,6 @@ static int sony_nc_probe(struct platform_device *pdev)
 		return -ENODEV;
 
 	sony_nc_acpi_device = device;
-	strscpy(acpi_device_class(device), "sony/hotkey");
-
 	sony_nc_acpi_handle = device->handle;
 
 	/* read device status */
@@ -4523,7 +4521,6 @@ static int sony_pic_probe(struct platform_device *pdev)
 		return -ENODEV;
 
 	spic_dev.acpi_dev = device;
-	strscpy(acpi_device_class(device), "sony/hotkey");
 	sony_pic_detect_device_type(&spic_dev);
 	mutex_init(&spic_dev.lock);
 
-- 
2.51.0

[PATCH v1 08/10] platform/x86: toshiba_acpi: Do not use uninitialized device_class

[Rafael J. Wysocki]

From: "Rafael J. Wysocki" <rafael.j.wysocki@intel.com>

The pnp.device_class string in the ACPI companion of the platform
device used for binding the driver is never initialized, so passing
it to acpi_bus_generate_netlink_event() is effectively equivalent to
passing an empty string literal to that function.

Accordingly, make the driver do the latter instead of doing the former.

No intentional functional impact.

Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
---
 drivers/platform/x86/toshiba_acpi.c | 6 ++----
 1 file changed, 2 insertions(+), 4 deletions(-)

diff --git a/drivers/platform/x86/toshiba_acpi.c b/drivers/platform/x86/toshiba_acpi.c
index 7cecb3a70b9c..a0b8060836d0 100644
--- a/drivers/platform/x86/toshiba_acpi.c
+++ b/drivers/platform/x86/toshiba_acpi.c
@@ -2505,8 +2505,7 @@ static void toshiba_acpi_kbd_bl_work(struct work_struct *work)
 				LED_FULL : LED_OFF);
 
 	/* Emulate the keyboard backlight event */
-	acpi_bus_generate_netlink_event(toshiba_acpi->acpi_dev->pnp.device_class,
-					dev_name(&toshiba_acpi->acpi_dev->dev),
+	acpi_bus_generate_netlink_event("", dev_name(&toshiba_acpi->acpi_dev->dev),
 					0x92, 0);
 }
 
@@ -3250,8 +3249,7 @@ static void toshiba_acpi_notify(acpi_handle handle, u32 event, void *data)
 		break;
 	}
 
-	acpi_bus_generate_netlink_event(acpi_dev->pnp.device_class,
-					dev_name(&acpi_dev->dev),
+	acpi_bus_generate_netlink_event("", dev_name(&acpi_dev->dev),
 					event, (event == 0x80) ?
 					dev->last_key_event : 0);
 }
-- 
2.51.0

[PATCH v1 09/10] platform/x86: toshiba_haps: Do not use uninitialized device_class

[Rafael J. Wysocki]

From: "Rafael J. Wysocki" <rafael.j.wysocki@intel.com>

The pnp.device_class string in the ACPI companion of the platform
device used for binding the driver is never initialized, so passing
it to acpi_bus_generate_netlink_event() is effectively equivalent to
passing an empty string literal to that function.

Accordingly, make the driver do the latter instead of doing the former.

No intentional functional impact.

Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
---
 drivers/platform/x86/toshiba_haps.c | 4 +---
 1 file changed, 1 insertion(+), 3 deletions(-)

diff --git a/drivers/platform/x86/toshiba_haps.c b/drivers/platform/x86/toshiba_haps.c
index 8d12241924df..c6633b74029f 100644
--- a/drivers/platform/x86/toshiba_haps.c
+++ b/drivers/platform/x86/toshiba_haps.c
@@ -136,9 +136,7 @@ static void toshiba_haps_notify(acpi_handle handle, u32 event, void *data)
 
 	pr_debug("Received event: 0x%x\n", event);
 
-	acpi_bus_generate_netlink_event(device->pnp.device_class,
-					dev_name(&device->dev),
-					event, 0);
+	acpi_bus_generate_netlink_event("", dev_name(&device->dev), event, 0);
 }
 
 static void toshiba_haps_remove(struct platform_device *pdev)
-- 
2.51.0

[PATCH v1 10/10] platform/x86: xo15-ebook: Stop setting acpi_device_name/class()

[Rafael J. Wysocki]

From: "Rafael J. Wysocki" <rafael.j.wysocki@intel.com>

The driver sets acpi_device_class() which is never read afterward, so
make it stop doing that and drop the two symbols defined specifically
for this purpose.

Likewise, acpi_device_name() set by the driver is only used for input
class device name initialization and the "EBook Switch" string literal
may as well be used directly for that, so make the driver do so and
stop setting acpi_device_name(), which allows the symbol defined
specifically for this purpose to be dropped.

No intentional functional impact.

Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
---
 drivers/platform/x86/xo15-ebook.c | 8 +-------
 1 file changed, 1 insertion(+), 7 deletions(-)

diff --git a/drivers/platform/x86/xo15-ebook.c b/drivers/platform/x86/xo15-ebook.c
index e40e385c52bd..4c3185e2ceec 100644
--- a/drivers/platform/x86/xo15-ebook.c
+++ b/drivers/platform/x86/xo15-ebook.c
@@ -19,13 +19,10 @@
 
 #define MODULE_NAME "xo15-ebook"
 
-#define XO15_EBOOK_CLASS		MODULE_NAME
 #define XO15_EBOOK_TYPE_UNKNOWN	0x00
 #define XO15_EBOOK_NOTIFY_STATUS	0x80
 
-#define XO15_EBOOK_SUBCLASS		"ebook"
 #define XO15_EBOOK_HID			"XO15EBK"
-#define XO15_EBOOK_DEVICE_NAME		"EBook Switch"
 
 MODULE_DESCRIPTION("OLPC XO-1.5 ebook switch driver");
 MODULE_LICENSE("GPL");
@@ -105,12 +102,9 @@ static int ebook_switch_probe(struct platform_device *pdev)
 	if (!id)
 		return dev_err_probe(dev, -ENODEV, "Unsupported hid\n");
 
-	strscpy(acpi_device_name(device), XO15_EBOOK_DEVICE_NAME);
-	strscpy(acpi_device_class(device), XO15_EBOOK_CLASS "/" XO15_EBOOK_SUBCLASS);
-
 	snprintf(button->phys, sizeof(button->phys), "%s/button/input0", id->id);
 
-	input->name = acpi_device_name(device);
+	input->name = "EBook Switch";
 	input->phys = button->phys;
 	input->id.bustype = BUS_HOST;
 
-- 
2.51.0

Re: [PATCH v1 00/10] platform/x86: Stop using acpi_device_name/class()

[Andy Shevchenko]

On Fri, Jul 03, 2026 at 01:15:01PM +0200, Rafael J. Wysocki wrote:
> Hi All,
> 
> There are two fields in struct acpi_device_pnp, device_name and device_class,
> that were supposed to be populated and used by device drivers, but they have
> never been used consistently and some drivers just populate them and don't
> access them later, and some drivers use them uninitialized.
> 
> All of that is confusing and messy, so the drivers for core ACPI devices
> have been updated to stop using those fields which are now slated for
> removal, but they are still accessed in some places.
> 
> This series updates platform x86 drivers accessing those fields to stop
> doing that.

In most of the patches you have double space in your name in From. Can we have
some consistency here? Or is it deliberate (in which case I'm wondering why)?

-- 
With Best Regards,
Andy Shevchenko

Re: [PATCH v1 00/10] platform/x86: Stop using acpi_device_name/class()

[Rafael J. Wysocki (Intel)]

On Fri, Jul 3, 2026 at 2:10 PM Andy Shevchenko
<andriy.shevchenko@linux.intel.com> wrote:
>
> On Fri, Jul 03, 2026 at 01:15:01PM +0200, Rafael J. Wysocki wrote:
> > Hi All,
> >
> > There are two fields in struct acpi_device_pnp, device_name and device_class,
> > that were supposed to be populated and used by device drivers, but they have
> > never been used consistently and some drivers just populate them and don't
> > access them later, and some drivers use them uninitialized.
> >
> > All of that is confusing and messy, so the drivers for core ACPI devices
> > have been updated to stop using those fields which are now slated for
> > removal, but they are still accessed in some places.
> >
> > This series updates platform x86 drivers accessing those fields to stop
> > doing that.
>
> In most of the patches you have double space in your name in From.

Do you mean the From header in the patch body or the From header in
the SMTP headers?

> Can we have some consistency here? Or is it deliberate (in which case I'm wondering why)?

Not deliberate, probably an e-mail client mess-up.

Re: [PATCH v1 00/10] platform/x86: Stop using acpi_device_name/class()

[Andy Shevchenko]

On Fri, Jul 03, 2026 at 02:15:13PM +0200, Rafael J. Wysocki (Intel) wrote:
> On Fri, Jul 3, 2026 at 2:10 PM Andy Shevchenko
> <andriy.shevchenko@linux.intel.com> wrote:
> > On Fri, Jul 03, 2026 at 01:15:01PM +0200, Rafael J. Wysocki wrote:
> > >
> > > There are two fields in struct acpi_device_pnp, device_name and device_class,
> > > that were supposed to be populated and used by device drivers, but they have
> > > never been used consistently and some drivers just populate them and don't
> > > access them later, and some drivers use them uninitialized.
> > >
> > > All of that is confusing and messy, so the drivers for core ACPI devices
> > > have been updated to stop using those fields which are now slated for
> > > removal, but they are still accessed in some places.
> > >
> > > This series updates platform x86 drivers accessing those fields to stop
> > > doing that.
> >
> > In most of the patches you have double space in your name in From.
> 
> Do you mean the From header in the patch body or the From header in
> the SMTP headers?

At least SMTP. TBH, I haven't paid attention to the From lines in the bodies.

> > Can we have some consistency here? Or is it deliberate (in which case I'm
> > wondering why)?
> 
> Not deliberate, probably an e-mail client mess-up.

-- 
With Best Regards,
Andy Shevchenko

Re: [PATCH v1 00/10] platform/x86: Stop using acpi_device_name/class()

[Rafael J. Wysocki (Intel)]

On Fri, Jul 3, 2026 at 2:41 PM Andy Shevchenko
<andriy.shevchenko@linux.intel.com> wrote:
>
> On Fri, Jul 03, 2026 at 02:15:13PM +0200, Rafael J. Wysocki (Intel) wrote:
> > On Fri, Jul 3, 2026 at 2:10 PM Andy Shevchenko
> > <andriy.shevchenko@linux.intel.com> wrote:
> > > On Fri, Jul 03, 2026 at 01:15:01PM +0200, Rafael J. Wysocki wrote:
> > > >
> > > > There are two fields in struct acpi_device_pnp, device_name and device_class,
> > > > that were supposed to be populated and used by device drivers, but they have
> > > > never been used consistently and some drivers just populate them and don't
> > > > access them later, and some drivers use them uninitialized.
> > > >
> > > > All of that is confusing and messy, so the drivers for core ACPI devices
> > > > have been updated to stop using those fields which are now slated for
> > > > removal, but they are still accessed in some places.
> > > >
> > > > This series updates platform x86 drivers accessing those fields to stop
> > > > doing that.
> > >
> > > In most of the patches you have double space in your name in From.
> >
> > Do you mean the From header in the patch body or the From header in
> > the SMTP headers?
>
> At least SMTP. TBH, I haven't paid attention to the From lines in the bodies.

Well, those are the ones that matter though because git will use them
to override the SMTP From header (and so they need to match the S-o-b,
not the SMTP From).

Re: [PATCH v1 00/10] platform/x86: Stop using acpi_device_name/class()

[Andy Shevchenko]

On Fri, Jul 03, 2026 at 02:44:38PM +0200, Rafael J. Wysocki (Intel) wrote:
> On Fri, Jul 3, 2026 at 2:41 PM Andy Shevchenko
> <andriy.shevchenko@linux.intel.com> wrote:
> > On Fri, Jul 03, 2026 at 02:15:13PM +0200, Rafael J. Wysocki (Intel) wrote:
> > > On Fri, Jul 3, 2026 at 2:10 PM Andy Shevchenko
> > > <andriy.shevchenko@linux.intel.com> wrote:
> > > > On Fri, Jul 03, 2026 at 01:15:01PM +0200, Rafael J. Wysocki wrote:

...

> > > > In most of the patches you have double space in your name in From.
> > >
> > > Do you mean the From header in the patch body or the From header in
> > > the SMTP headers?
> >
> > At least SMTP. TBH, I haven't paid attention to the From lines in the bodies.
> 
> Well, those are the ones that matter though because git will use them
> to override the SMTP From header (and so they need to match the S-o-b,
> not the SMTP From).

Yeah, right. So the issue is minor after all (and I gave my tag already).

-- 
With Best Regards,
Andy Shevchenko

Re: [PATCH v1 00/10] platform/x86: Stop using acpi_device_name/class()

[Andy Shevchenko]

On Fri, Jul 03, 2026 at 03:10:26PM +0300, Andy Shevchenko wrote:
> On Fri, Jul 03, 2026 at 01:15:01PM +0200, Rafael J. Wysocki wrote:
> > Hi All,
> > 
> > There are two fields in struct acpi_device_pnp, device_name and device_class,
> > that were supposed to be populated and used by device drivers, but they have
> > never been used consistently and some drivers just populate them and don't
> > access them later, and some drivers use them uninitialized.
> > 
> > All of that is confusing and messy, so the drivers for core ACPI devices
> > have been updated to stop using those fields which are now slated for
> > removal, but they are still accessed in some places.
> > 
> > This series updates platform x86 drivers accessing those fields to stop
> > doing that.
> 
> In most of the patches you have double space in your name in From. Can we have
> some consistency here? Or is it deliberate (in which case I'm wondering why)?

I looked into all patches and I see them good.
Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
(with preferably used same From field across the patches).

-- 
With Best Regards,
Andy Shevchenko

Re: [PATCH v1 00/10] platform/x86: Stop using acpi_device_name/class()

[Rafael J. Wysocki (Intel)]

On Fri, Jul 3, 2026 at 2:19 PM Andy Shevchenko
<andriy.shevchenko@linux.intel.com> wrote:
>
> On Fri, Jul 03, 2026 at 03:10:26PM +0300, Andy Shevchenko wrote:
> > On Fri, Jul 03, 2026 at 01:15:01PM +0200, Rafael J. Wysocki wrote:
> > > Hi All,
> > >
> > > There are two fields in struct acpi_device_pnp, device_name and device_class,
> > > that were supposed to be populated and used by device drivers, but they have
> > > never been used consistently and some drivers just populate them and don't
> > > access them later, and some drivers use them uninitialized.
> > >
> > > All of that is confusing and messy, so the drivers for core ACPI devices
> > > have been updated to stop using those fields which are now slated for
> > > removal, but they are still accessed in some places.
> > >
> > > This series updates platform x86 drivers accessing those fields to stop
> > > doing that.
> >
> > In most of the patches you have double space in your name in From. Can we have
> > some consistency here? Or is it deliberate (in which case I'm wondering why)?
>
> I looked into all patches and I see them good.
> Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>

Thanks!

> (with preferably used same From field across the patches).

What goes into commits is the one in the patch body (which overrides
the one in the SMTP headers), so it is the same.

The one in the SMTP headers has indeed been messed up by the email
client, but it doesn't really matter.