Re: [PATCH] thermal: change thermal_class to a const struct

Re: [PATCH] thermal: change thermal_class to a const struct

[Rafael J. Wysocki (Intel)]

On Tue, Aug 11, 2026 at 8:17 AM Jori Koolstra <jkoolstra@xs4all.nl> wrote:
>
> The class_create() call has been deprecated in favor of class_register()
> as the driver core now allows for a struct class to be in read-only
> memory. Change thermal_class to be a const struct class and drop the
> class_create() call.

This has been deliberately changed the other way around not too long
ago, in commit

34f54003643e thermal/core: Allocate the thermal class dynamically

and it was then argued that it would be better to allocate the class
dynamically.

You seem to have a differing opinion.

Is there any plan to remove class_create() from the kernel?  If there
isn't, I'd rather stop this back-and-forth dance and leave the code
as-is.

> Compile tested only.

That is, not tested.

> Suggested-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
> Signed-off-by: Jori Koolstra <jkoolstra@xs4all.nl>
> ---
>  drivers/thermal/thermal_core.c | 24 +++++++++++-------------
>  1 file changed, 11 insertions(+), 13 deletions(-)
>
> diff --git a/drivers/thermal/thermal_core.c b/drivers/thermal/thermal_core.c
> index 28a20d4b475c..36220113ca8e 100644
> --- a/drivers/thermal/thermal_core.c
> +++ b/drivers/thermal/thermal_core.c
> @@ -889,7 +889,9 @@ static void thermal_unbind_cdev_from_trip(struct thermal_zone_device *tz,
>         kfree(pos);
>  }
>
> -static struct class *thermal_class __ro_after_init;
> +static const struct class thermal_class = {
> +       .name   = "thermal"
> +};
>
>  static inline
>  void print_bind_err_msg(struct thermal_zone_device *tz,
> @@ -973,7 +975,7 @@ thermal_cooling_device_alloc(const char *type, const struct thermal_cooling_devi
>             !ops->set_cur_state)
>                 return ERR_PTR(-EINVAL);
>
> -       if (!thermal_class)
> +       if (!class_is_registered(&thermal_class))

Any chance to reduce the overhead of this check (in all places where
it is done)?

>                 return ERR_PTR(-ENODEV);
>
>         cdev = kzalloc_obj(*cdev);
> @@ -1010,7 +1012,7 @@ int thermal_cooling_device_add(struct thermal_cooling_device *cdev, void *devdat
>         mutex_init(&cdev->lock);
>         INIT_LIST_HEAD(&cdev->thermal_instances);
>         cdev->updated = false;
> -       cdev->device.class = thermal_class;
> +       cdev->device.class = &thermal_class;
>         cdev->device.release = thermal_cdev_release;
>         device_initialize(&cdev->device);
>         cdev->devdata = devdata;
> @@ -1447,7 +1449,7 @@ thermal_zone_device_register_with_trips(const char *type,
>         if (polling_delay && passive_delay > polling_delay)
>                 return ERR_PTR(-EINVAL);
>
> -       if (!thermal_class)
> +       if (!class_is_registered(&thermal_class))
>                 return ERR_PTR(-ENODEV);
>
>         tz = kzalloc_flex(*tz, trips, num_trips);
> @@ -1483,7 +1485,7 @@ thermal_zone_device_register_with_trips(const char *type,
>         if (!tz->ops.critical)
>                 tz->ops.critical = thermal_zone_device_critical;
>
> -       tz->device.class = thermal_class;
> +       tz->device.class = &thermal_class;
>         tz->device.release = thermal_zone_device_release;
>         tz->devdata = devdata;
>         tz->num_trips = num_trips;
> @@ -1745,7 +1747,7 @@ static void __thermal_pm_prepare(void)
>
>  void thermal_pm_prepare(void)
>  {
> -       if (!thermal_class)
> +       if (!class_is_registered(&thermal_class))
>                 return;
>
>         __thermal_pm_prepare();
> @@ -1776,7 +1778,7 @@ void thermal_pm_complete(void)
>  {
>         struct thermal_zone_device *tz;
>
> -       if (!thermal_class)
> +       if (!class_is_registered(&thermal_class))
>                 return;
>
>         guard(mutex)(&thermal_list_lock);
> @@ -1789,7 +1791,6 @@ void thermal_pm_complete(void)
>
>  static int __init thermal_init(void)
>  {
> -       struct class *tc;
>         int result;
>
>         thermal_debug_init();
> @@ -1808,13 +1809,10 @@ static int __init thermal_init(void)
>         if (result)
>                 goto unregister_governors;
>
> -       tc = class_create("thermal");
> -       if (IS_ERR(tc)) {
> -               result = PTR_ERR(tc);
> +       result = class_register(&thermal_class);
> +       if (result)
>                 goto unregister_governors;
> -       }
>
> -       thermal_class = tc;
>         return 0;
>
>  unregister_governors:
> --

Re: [PATCH] thermal: change thermal_class to a const struct

[Greg Kroah-Hartman]

On Mon, Aug 24, 2026 at 06:09:33PM +0200, Rafael J. Wysocki (Intel) wrote:
> On Tue, Aug 11, 2026 at 8:17 AM Jori Koolstra <jkoolstra@xs4all.nl> wrote:
> >
> > The class_create() call has been deprecated in favor of class_register()
> > as the driver core now allows for a struct class to be in read-only
> > memory. Change thermal_class to be a const struct class and drop the
> > class_create() call.
> 
> This has been deliberately changed the other way around not too long
> ago, in commit
> 
> 34f54003643e thermal/core: Allocate the thermal class dynamically
> 
> and it was then argued that it would be better to allocate the class
> dynamically.
> 
> You seem to have a differing opinion.
> 
> Is there any plan to remove class_create() from the kernel?  If there
> isn't, I'd rather stop this back-and-forth dance and leave the code
> as-is.

Yes, class_create() is going away.  I didn't notice commit 34f54003643e,
but that's the wrong thing to do here.  We should just revert that
instead.

thanks,

greg k-h

Re: [PATCH] thermal: change thermal_class to a const struct

[Greg Kroah-Hartman]

On Mon, Aug 24, 2026 at 06:56:05PM +0200, Greg Kroah-Hartman wrote:
> On Mon, Aug 24, 2026 at 06:09:33PM +0200, Rafael J. Wysocki (Intel) wrote:
> > On Tue, Aug 11, 2026 at 8:17 AM Jori Koolstra <jkoolstra@xs4all.nl> wrote:
> > >
> > > The class_create() call has been deprecated in favor of class_register()
> > > as the driver core now allows for a struct class to be in read-only
> > > memory. Change thermal_class to be a const struct class and drop the
> > > class_create() call.
> > 
> > This has been deliberately changed the other way around not too long
> > ago, in commit
> > 
> > 34f54003643e thermal/core: Allocate the thermal class dynamically
> > 
> > and it was then argued that it would be better to allocate the class
> > dynamically.
> > 
> > You seem to have a differing opinion.
> > 
> > Is there any plan to remove class_create() from the kernel?  If there
> > isn't, I'd rather stop this back-and-forth dance and leave the code
> > as-is.
> 
> Yes, class_create() is going away.  I didn't notice commit 34f54003643e,
> but that's the wrong thing to do here.  We should just revert that
> instead.

And we are down to only a very few callers of that function.  I'll sweep
the tree again after -rc1 is out, apply any pending patches, and drop
the function entirely then.

thanks,

greg k-h

Re: [PATCH] thermal: change thermal_class to a const struct

[Rafael J. Wysocki (Intel)]

On Mon, Aug 24, 2026 at 6:56 PM Greg Kroah-Hartman
<gregkh@linuxfoundation.org> wrote:
>
> On Mon, Aug 24, 2026 at 06:09:33PM +0200, Rafael J. Wysocki (Intel) wrote:
> > On Tue, Aug 11, 2026 at 8:17 AM Jori Koolstra <jkoolstra@xs4all.nl> wrote:
> > >
> > > The class_create() call has been deprecated in favor of class_register()
> > > as the driver core now allows for a struct class to be in read-only
> > > memory. Change thermal_class to be a const struct class and drop the
> > > class_create() call.
> >
> > This has been deliberately changed the other way around not too long
> > ago, in commit
> >
> > 34f54003643e thermal/core: Allocate the thermal class dynamically
> >
> > and it was then argued that it would be better to allocate the class
> > dynamically.
> >
> > You seem to have a differing opinion.
> >
> > Is there any plan to remove class_create() from the kernel?  If there
> > isn't, I'd rather stop this back-and-forth dance and leave the code
> > as-is.
>
> Yes, class_create() is going away.

Fair enough.

> I didn't notice commit 34f54003643e, but that's the wrong thing to do here.
> We should just revert that instead.

OK, let me send a revert of it.

Thanks!