mbox series

[v2,0/5] ACPI: sysfs: manage sysfs attributes through device core

Message ID 20240709-acpi-sysfs-groups-v2-0-058ab0667fa8@weissschuh.net (mailing list archive)
Headers show
Series ACPI: sysfs: manage sysfs attributes through device core | expand

Message

Thomas Weißschuh July 9, 2024, 8:37 p.m. UTC
Simplify the lifecycle of the sysfs attributes by letting the device
core manage them.

Signed-off-by: Thomas Weißschuh <linux@weissschuh.net>
---
Changes in v2:
- Add fix to validate buffer type validation (patch 1)
- Drop usage of devm-APIs as these are unusable for unbound devices
- Evaluate _STR on each sysfs access
- Link to v1: https://lore.kernel.org/r/20240613-acpi-sysfs-groups-v1-0-665e0deb052a@weissschuh.net

---
Thomas Weißschuh (5):
      ACPI: sysfs: validate return type of _STR method
      ACPI: sysfs: evaluate _STR on each sysfs access
      ACPI: sysfs: manage attributes as attribute_group
      ACPI: sysfs: manage sysfs attributes through device core
      ACPI: sysfs: remove return value of acpi_device_setup_files()

 drivers/acpi/device_sysfs.c | 196 +++++++++++++++++++-------------------------
 drivers/acpi/internal.h     |   3 +-
 drivers/acpi/scan.c         |   6 +-
 include/acpi/acpi_bus.h     |   1 -
 4 files changed, 89 insertions(+), 117 deletions(-)
---
base-commit: 34afb82a3c67f869267a26f593b6f8fc6bf35905
change-id: 20240609-acpi-sysfs-groups-cfa756d16752

Best regards,

Comments

Rafael J. Wysocki July 10, 2024, 11:43 a.m. UTC | #1
On Tue, Jul 9, 2024 at 10:38 PM Thomas Weißschuh <linux@weissschuh.net> wrote:
>
> Simplify the lifecycle of the sysfs attributes by letting the device
> core manage them.
>
> Signed-off-by: Thomas Weißschuh <linux@weissschuh.net>
> ---
> Changes in v2:
> - Add fix to validate buffer type validation (patch 1)
> - Drop usage of devm-APIs as these are unusable for unbound devices
> - Evaluate _STR on each sysfs access
> - Link to v1: https://lore.kernel.org/r/20240613-acpi-sysfs-groups-v1-0-665e0deb052a@weissschuh.net
>
> ---
> Thomas Weißschuh (5):
>       ACPI: sysfs: validate return type of _STR method
>       ACPI: sysfs: evaluate _STR on each sysfs access
>       ACPI: sysfs: manage attributes as attribute_group
>       ACPI: sysfs: manage sysfs attributes through device core
>       ACPI: sysfs: remove return value of acpi_device_setup_files()
>
>  drivers/acpi/device_sysfs.c | 196 +++++++++++++++++++-------------------------
>  drivers/acpi/internal.h     |   3 +-
>  drivers/acpi/scan.c         |   6 +-
>  include/acpi/acpi_bus.h     |   1 -
>  4 files changed, 89 insertions(+), 117 deletions(-)
> ---

If this is not urgent, and I don't think it is, I'd rather defer it to
the 6.12 cycle (that is, I'd apply it after the upcoming 6.11 merge
window).

Thanks!
Thomas Weißschuh July 10, 2024, 11:49 a.m. UTC | #2
On 2024-07-10 13:43:57+0000, Rafael J. Wysocki wrote:
> On Tue, Jul 9, 2024 at 10:38 PM Thomas Weißschuh <linux@weissschuh.net> wrote:
> >
> > Simplify the lifecycle of the sysfs attributes by letting the device
> > core manage them.
> >
> > Signed-off-by: Thomas Weißschuh <linux@weissschuh.net>
> > ---
> > Changes in v2:
> > - Add fix to validate buffer type validation (patch 1)
> > - Drop usage of devm-APIs as these are unusable for unbound devices
> > - Evaluate _STR on each sysfs access
> > - Link to v1: https://lore.kernel.org/r/20240613-acpi-sysfs-groups-v1-0-665e0deb052a@weissschuh.net
> >
> > ---
> > Thomas Weißschuh (5):
> >       ACPI: sysfs: validate return type of _STR method
> >       ACPI: sysfs: evaluate _STR on each sysfs access
> >       ACPI: sysfs: manage attributes as attribute_group
> >       ACPI: sysfs: manage sysfs attributes through device core
> >       ACPI: sysfs: remove return value of acpi_device_setup_files()
> >
> >  drivers/acpi/device_sysfs.c | 196 +++++++++++++++++++-------------------------
> >  drivers/acpi/internal.h     |   3 +-
> >  drivers/acpi/scan.c         |   6 +-
> >  include/acpi/acpi_bus.h     |   1 -
> >  4 files changed, 89 insertions(+), 117 deletions(-)
> > ---
> 
> If this is not urgent, and I don't think it is, I'd rather defer it to
> the 6.12 cycle (that is, I'd apply it after the upcoming 6.11 merge
> window).

Sounds good to me.


Thanks,
Thomas