* [PATCH v1 0/2] driver core/thermal: Fail registration of thermal object when thermal_class is not registered @ 2023-01-20 19:45 Rafael J. Wysocki 2023-01-20 19:46 ` [PATCH v1 1/2] driver core: class: Clear private pointer on registration failures Rafael J. Wysocki 2023-01-20 19:48 ` [PATCH v1 2/2] thermal: Fail object registration if thermal class is not registered Rafael J. Wysocki 0 siblings, 2 replies; 10+ messages in thread From: Rafael J. Wysocki @ 2023-01-20 19:45 UTC (permalink / raw) To: Linux PM, Greg Kroah-Hartman Cc: LKML, Daniel Lezcano, Srinivas Pandruvada, Zhang Rui Hi All, If thermal_class is not registered, the whole thermal framework is basically unusable, because the governors are not there and its sysfs interface is not present. In that case it doesn't make sense to register thermal zones and cooling devices, because they cannot be used as expected anyway, so make it possible to fail the registration of these things if the registration of thermal_class has failed. To that end, make sure that the private pointer of a class is NULL when that class is not registered with the driver core (patch [1/2]). Next, make the thermal framework check the value of the thermal_class' private pointer against NULL and fail the registration of thermal zones and cooling devices when it is NULL (patch [2/2]). Thanks! ^ permalink raw reply [flat|nested] 10+ messages in thread
* [PATCH v1 1/2] driver core: class: Clear private pointer on registration failures 2023-01-20 19:45 [PATCH v1 0/2] driver core/thermal: Fail registration of thermal object when thermal_class is not registered Rafael J. Wysocki @ 2023-01-20 19:46 ` Rafael J. Wysocki 2023-01-20 22:43 ` Daniel Lezcano 2023-01-20 19:48 ` [PATCH v1 2/2] thermal: Fail object registration if thermal class is not registered Rafael J. Wysocki 1 sibling, 1 reply; 10+ messages in thread From: Rafael J. Wysocki @ 2023-01-20 19:46 UTC (permalink / raw) To: Linux PM, Greg Kroah-Hartman Cc: LKML, Daniel Lezcano, Srinivas Pandruvada, Zhang Rui From: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Clear the class private pointer if __class_register() fails for it, so as to allow its users to verify that the class is usable by checking the value of that pointer. For consistency, clear that pointer before freeing the object pointed to by it in class_release(). Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> --- drivers/base/class.c | 16 +++++++++++----- 1 file changed, 11 insertions(+), 5 deletions(-) Index: linux-pm/drivers/base/class.c =================================================================== --- linux-pm.orig/drivers/base/class.c +++ linux-pm/drivers/base/class.c @@ -53,6 +53,8 @@ static void class_release(struct kobject pr_debug("class '%s': release.\n", class->name); + class->p = NULL; + if (class->class_release) class->class_release(class); else @@ -186,17 +188,21 @@ int __class_register(struct class *cls, cls->p = cp; error = kset_register(&cp->subsys); - if (error) { - kfree(cp); - return error; - } + if (error) + goto err_out; + error = class_add_groups(class_get(cls), cls->class_groups); class_put(cls); if (error) { kobject_del(&cp->subsys.kobj); kfree_const(cp->subsys.kobj.name); - kfree(cp); + goto err_out; } + return 0; + +err_out: + kfree(cp); + cls->p = NULL; return error; } EXPORT_SYMBOL_GPL(__class_register); ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [PATCH v1 1/2] driver core: class: Clear private pointer on registration failures 2023-01-20 19:46 ` [PATCH v1 1/2] driver core: class: Clear private pointer on registration failures Rafael J. Wysocki @ 2023-01-20 22:43 ` Daniel Lezcano 0 siblings, 0 replies; 10+ messages in thread From: Daniel Lezcano @ 2023-01-20 22:43 UTC (permalink / raw) To: Rafael J. Wysocki, Linux PM, Greg Kroah-Hartman Cc: LKML, Srinivas Pandruvada, Zhang Rui On 20/01/2023 20:46, Rafael J. Wysocki wrote: > From: Rafael J. Wysocki <rafael.j.wysocki@intel.com> > > Clear the class private pointer if __class_register() fails for it, so > as to allow its users to verify that the class is usable by checking > the value of that pointer. > > For consistency, clear that pointer before freeing the object pointed > to by it in class_release(). > > Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> > --- Acked-by: Daniel Lezcano <daniel.lezcano@linaro.org> -- <http://www.linaro.org/> Linaro.org │ Open source software for ARM SoCs Follow Linaro: <http://www.facebook.com/pages/Linaro> Facebook | <http://twitter.com/#!/linaroorg> Twitter | <http://www.linaro.org/linaro-blog/> Blog ^ permalink raw reply [flat|nested] 10+ messages in thread
* [PATCH v1 2/2] thermal: Fail object registration if thermal class is not registered 2023-01-20 19:45 [PATCH v1 0/2] driver core/thermal: Fail registration of thermal object when thermal_class is not registered Rafael J. Wysocki 2023-01-20 19:46 ` [PATCH v1 1/2] driver core: class: Clear private pointer on registration failures Rafael J. Wysocki @ 2023-01-20 19:48 ` Rafael J. Wysocki 2023-01-20 22:43 ` Daniel Lezcano 2023-01-21 7:40 ` Greg Kroah-Hartman 1 sibling, 2 replies; 10+ messages in thread From: Rafael J. Wysocki @ 2023-01-20 19:48 UTC (permalink / raw) To: Linux PM, Greg Kroah-Hartman Cc: LKML, Daniel Lezcano, Srinivas Pandruvada, Zhang Rui From: Rafael J. Wysocki <rafael.j.wysocki@intel.com> If thermal_class is not registered with the driver core, there is no way to expose the interfaces used by the thermal control framework, so prevent thermal zones and cooling devices from being registered in that case by returning an error from object registration functions. For this purpose, introduce class_is_registered() that checks the private pointer of the given class and returns 'false' if it is NULL, which means that the class has not been registered, and use it in the thermal framework. Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> --- drivers/thermal/thermal_core.c | 6 ++++++ include/linux/device/class.h | 5 +++++ 2 files changed, 11 insertions(+) Index: linux-pm/include/linux/device/class.h =================================================================== --- linux-pm.orig/include/linux/device/class.h +++ linux-pm/include/linux/device/class.h @@ -82,6 +82,11 @@ struct class_dev_iter { const struct device_type *type; }; +static inline bool class_is_registered(struct class *class) +{ + return !!class->p; +} + extern struct kobject *sysfs_dev_block_kobj; extern struct kobject *sysfs_dev_char_kobj; extern int __must_check __class_register(struct class *class, Index: linux-pm/drivers/thermal/thermal_core.c =================================================================== --- linux-pm.orig/drivers/thermal/thermal_core.c +++ linux-pm/drivers/thermal/thermal_core.c @@ -880,6 +880,9 @@ __thermal_cooling_device_register(struct !ops->set_cur_state) return ERR_PTR(-EINVAL); + if (!class_is_registered(&thermal_class)) + return ERR_PTR(-ENODEV); + cdev = kzalloc(sizeof(*cdev), GFP_KERNEL); if (!cdev) return ERR_PTR(-ENOMEM); @@ -1342,6 +1345,9 @@ thermal_zone_device_register_with_trips( if (num_trips > 0 && (!ops->get_trip_type || !ops->get_trip_temp) && !trips) return ERR_PTR(-EINVAL); + if (!class_is_registered(&thermal_class)) + return ERR_PTR(-ENODEV); + tz = kzalloc(sizeof(*tz), GFP_KERNEL); if (!tz) return ERR_PTR(-ENOMEM); ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [PATCH v1 2/2] thermal: Fail object registration if thermal class is not registered 2023-01-20 19:48 ` [PATCH v1 2/2] thermal: Fail object registration if thermal class is not registered Rafael J. Wysocki @ 2023-01-20 22:43 ` Daniel Lezcano 2023-01-21 7:40 ` Greg Kroah-Hartman 1 sibling, 0 replies; 10+ messages in thread From: Daniel Lezcano @ 2023-01-20 22:43 UTC (permalink / raw) To: Rafael J. Wysocki, Linux PM, Greg Kroah-Hartman Cc: LKML, Srinivas Pandruvada, Zhang Rui On 20/01/2023 20:48, Rafael J. Wysocki wrote: > From: Rafael J. Wysocki <rafael.j.wysocki@intel.com> > > If thermal_class is not registered with the driver core, there is no way > to expose the interfaces used by the thermal control framework, so > prevent thermal zones and cooling devices from being registered in > that case by returning an error from object registration functions. > > For this purpose, introduce class_is_registered() that checks the > private pointer of the given class and returns 'false' if it is NULL, > which means that the class has not been registered, and use it in the > thermal framework. > > Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Acked-by: Daniel Lezcano <daniel.lezcano@linaro.org> -- <http://www.linaro.org/> Linaro.org │ Open source software for ARM SoCs Follow Linaro: <http://www.facebook.com/pages/Linaro> Facebook | <http://twitter.com/#!/linaroorg> Twitter | <http://www.linaro.org/linaro-blog/> Blog ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [PATCH v1 2/2] thermal: Fail object registration if thermal class is not registered 2023-01-20 19:48 ` [PATCH v1 2/2] thermal: Fail object registration if thermal class is not registered Rafael J. Wysocki 2023-01-20 22:43 ` Daniel Lezcano @ 2023-01-21 7:40 ` Greg Kroah-Hartman 2023-01-23 20:16 ` Rafael J. Wysocki 1 sibling, 1 reply; 10+ messages in thread From: Greg Kroah-Hartman @ 2023-01-21 7:40 UTC (permalink / raw) To: Rafael J. Wysocki Cc: Linux PM, LKML, Daniel Lezcano, Srinivas Pandruvada, Zhang Rui On Fri, Jan 20, 2023 at 08:48:07PM +0100, Rafael J. Wysocki wrote: > From: Rafael J. Wysocki <rafael.j.wysocki@intel.com> > > If thermal_class is not registered with the driver core, there is no way > to expose the interfaces used by the thermal control framework, so > prevent thermal zones and cooling devices from being registered in > that case by returning an error from object registration functions. > > For this purpose, introduce class_is_registered() that checks the > private pointer of the given class and returns 'false' if it is NULL, > which means that the class has not been registered, and use it in the > thermal framework. > > Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> > --- > drivers/thermal/thermal_core.c | 6 ++++++ > include/linux/device/class.h | 5 +++++ > 2 files changed, 11 insertions(+) > > Index: linux-pm/include/linux/device/class.h > =================================================================== > --- linux-pm.orig/include/linux/device/class.h > +++ linux-pm/include/linux/device/class.h > @@ -82,6 +82,11 @@ struct class_dev_iter { > const struct device_type *type; > }; > > +static inline bool class_is_registered(struct class *class) > +{ > + return !!class->p; I really do not like this as it is exposing internals to drivers and whenever we do that, it gets abused and we have to unwind the mess in a few years. Overall, I'm trying to remove the ->p usage, but that's a longterm goal of mine (to allow class and bus structures to be in read-only memory), which isn't your issue here, but it's good to think about why you want to know this information (more below.) > +} > + > extern struct kobject *sysfs_dev_block_kobj; > extern struct kobject *sysfs_dev_char_kobj; > extern int __must_check __class_register(struct class *class, > Index: linux-pm/drivers/thermal/thermal_core.c > =================================================================== > --- linux-pm.orig/drivers/thermal/thermal_core.c > +++ linux-pm/drivers/thermal/thermal_core.c > @@ -880,6 +880,9 @@ __thermal_cooling_device_register(struct > !ops->set_cur_state) > return ERR_PTR(-EINVAL); > > + if (!class_is_registered(&thermal_class)) > + return ERR_PTR(-ENODEV); If the class isn't registered, then sommething went wrong with the thermal core code, right? So why isn't the thermal core keeping a local variable of "class was registered" and relying on the driver core to know this? The number of individual users that should be doing one thing or another if a class is not registered feels very very slim. How come this code is being called at all if the thermal class was not registered in the first place? What would have prevented that from happening? Is it an ordering issue, or a kernel configuration issue? thanks, greg k-h ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [PATCH v1 2/2] thermal: Fail object registration if thermal class is not registered 2023-01-21 7:40 ` Greg Kroah-Hartman @ 2023-01-23 20:16 ` Rafael J. Wysocki 2023-01-24 6:03 ` Greg Kroah-Hartman 0 siblings, 1 reply; 10+ messages in thread From: Rafael J. Wysocki @ 2023-01-23 20:16 UTC (permalink / raw) To: Greg Kroah-Hartman Cc: Rafael J. Wysocki, Linux PM, LKML, Daniel Lezcano, Srinivas Pandruvada, Zhang Rui On Sat, Jan 21, 2023 at 8:40 AM Greg Kroah-Hartman <gregkh@linuxfoundation.org> wrote: > > On Fri, Jan 20, 2023 at 08:48:07PM +0100, Rafael J. Wysocki wrote: > > From: Rafael J. Wysocki <rafael.j.wysocki@intel.com> > > > > If thermal_class is not registered with the driver core, there is no way > > to expose the interfaces used by the thermal control framework, so > > prevent thermal zones and cooling devices from being registered in > > that case by returning an error from object registration functions. > > > > For this purpose, introduce class_is_registered() that checks the > > private pointer of the given class and returns 'false' if it is NULL, > > which means that the class has not been registered, and use it in the > > thermal framework. > > > > Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> > > --- > > drivers/thermal/thermal_core.c | 6 ++++++ > > include/linux/device/class.h | 5 +++++ > > 2 files changed, 11 insertions(+) > > > > Index: linux-pm/include/linux/device/class.h > > =================================================================== > > --- linux-pm.orig/include/linux/device/class.h > > +++ linux-pm/include/linux/device/class.h > > @@ -82,6 +82,11 @@ struct class_dev_iter { > > const struct device_type *type; > > }; > > > > +static inline bool class_is_registered(struct class *class) > > +{ > > + return !!class->p; > > I really do not like this as it is exposing internals to drivers and > whenever we do that, it gets abused and we have to unwind the mess in a > few years. > > Overall, I'm trying to remove the ->p usage, but that's a longterm goal > of mine (to allow class and bus structures to be in read-only memory), > which isn't your issue here, but it's good to think about why you want > to know this information (more below.) > > > +} > > + > > extern struct kobject *sysfs_dev_block_kobj; > > extern struct kobject *sysfs_dev_char_kobj; > > extern int __must_check __class_register(struct class *class, > > Index: linux-pm/drivers/thermal/thermal_core.c > > =================================================================== > > --- linux-pm.orig/drivers/thermal/thermal_core.c > > +++ linux-pm/drivers/thermal/thermal_core.c > > @@ -880,6 +880,9 @@ __thermal_cooling_device_register(struct > > !ops->set_cur_state) > > return ERR_PTR(-EINVAL); > > > > + if (!class_is_registered(&thermal_class)) > > + return ERR_PTR(-ENODEV); > > If the class isn't registered, then sommething went wrong with the > thermal core code, right? So why isn't the thermal core keeping a local > variable of "class was registered" and relying on the driver core to > know this? > > The number of individual users that should be doing one thing or another > if a class is not registered feels very very slim. How come this code > is being called at all if the thermal class was not registered in the > first place? What would have prevented that from happening? Is it an > ordering issue, or a kernel configuration issue? It's basically a matter of class_register() returning an error. Yes, we could use an extra variable for this purpose, but that would be a bit wasteful, because thermal_class will then sit unused and occupy memory in vain. Oh well, we may as well just allocate it dynamically. ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [PATCH v1 2/2] thermal: Fail object registration if thermal class is not registered 2023-01-23 20:16 ` Rafael J. Wysocki @ 2023-01-24 6:03 ` Greg Kroah-Hartman 2023-01-24 13:57 ` Rafael J. Wysocki 0 siblings, 1 reply; 10+ messages in thread From: Greg Kroah-Hartman @ 2023-01-24 6:03 UTC (permalink / raw) To: Rafael J. Wysocki Cc: Rafael J. Wysocki, Linux PM, LKML, Daniel Lezcano, Srinivas Pandruvada, Zhang Rui On Mon, Jan 23, 2023 at 09:16:33PM +0100, Rafael J. Wysocki wrote: > On Sat, Jan 21, 2023 at 8:40 AM Greg Kroah-Hartman > <gregkh@linuxfoundation.org> wrote: > > > > On Fri, Jan 20, 2023 at 08:48:07PM +0100, Rafael J. Wysocki wrote: > > > From: Rafael J. Wysocki <rafael.j.wysocki@intel.com> > > > > > > If thermal_class is not registered with the driver core, there is no way > > > to expose the interfaces used by the thermal control framework, so > > > prevent thermal zones and cooling devices from being registered in > > > that case by returning an error from object registration functions. > > > > > > For this purpose, introduce class_is_registered() that checks the > > > private pointer of the given class and returns 'false' if it is NULL, > > > which means that the class has not been registered, and use it in the > > > thermal framework. > > > > > > Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> > > > --- > > > drivers/thermal/thermal_core.c | 6 ++++++ > > > include/linux/device/class.h | 5 +++++ > > > 2 files changed, 11 insertions(+) > > > > > > Index: linux-pm/include/linux/device/class.h > > > =================================================================== > > > --- linux-pm.orig/include/linux/device/class.h > > > +++ linux-pm/include/linux/device/class.h > > > @@ -82,6 +82,11 @@ struct class_dev_iter { > > > const struct device_type *type; > > > }; > > > > > > +static inline bool class_is_registered(struct class *class) > > > +{ > > > + return !!class->p; > > > > I really do not like this as it is exposing internals to drivers and > > whenever we do that, it gets abused and we have to unwind the mess in a > > few years. > > > > Overall, I'm trying to remove the ->p usage, but that's a longterm goal > > of mine (to allow class and bus structures to be in read-only memory), > > which isn't your issue here, but it's good to think about why you want > > to know this information (more below.) > > > > > +} > > > + > > > extern struct kobject *sysfs_dev_block_kobj; > > > extern struct kobject *sysfs_dev_char_kobj; > > > extern int __must_check __class_register(struct class *class, > > > Index: linux-pm/drivers/thermal/thermal_core.c > > > =================================================================== > > > --- linux-pm.orig/drivers/thermal/thermal_core.c > > > +++ linux-pm/drivers/thermal/thermal_core.c > > > @@ -880,6 +880,9 @@ __thermal_cooling_device_register(struct > > > !ops->set_cur_state) > > > return ERR_PTR(-EINVAL); > > > > > > + if (!class_is_registered(&thermal_class)) > > > + return ERR_PTR(-ENODEV); > > > > If the class isn't registered, then sommething went wrong with the > > thermal core code, right? So why isn't the thermal core keeping a local > > variable of "class was registered" and relying on the driver core to > > know this? > > > > The number of individual users that should be doing one thing or another > > if a class is not registered feels very very slim. How come this code > > is being called at all if the thermal class was not registered in the > > first place? What would have prevented that from happening? Is it an > > ordering issue, or a kernel configuration issue? > > It's basically a matter of class_register() returning an error. Ok, so not a real problem then :) > Yes, we could use an extra variable for this purpose, but that would > be a bit wasteful, because thermal_class will then sit unused and > occupy memory in vain. How would it retain memory if class_register() failed? > Oh well, we may as well just allocate it dynamically. Allocate what? confused, greg k-h ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [PATCH v1 2/2] thermal: Fail object registration if thermal class is not registered 2023-01-24 6:03 ` Greg Kroah-Hartman @ 2023-01-24 13:57 ` Rafael J. Wysocki 2023-01-24 17:03 ` Greg Kroah-Hartman 0 siblings, 1 reply; 10+ messages in thread From: Rafael J. Wysocki @ 2023-01-24 13:57 UTC (permalink / raw) To: Greg Kroah-Hartman Cc: Rafael J. Wysocki, Rafael J. Wysocki, Linux PM, LKML, Daniel Lezcano, Srinivas Pandruvada, Zhang Rui On Tue, Jan 24, 2023 at 7:03 AM Greg Kroah-Hartman <gregkh@linuxfoundation.org> wrote: > > On Mon, Jan 23, 2023 at 09:16:33PM +0100, Rafael J. Wysocki wrote: > > On Sat, Jan 21, 2023 at 8:40 AM Greg Kroah-Hartman > > <gregkh@linuxfoundation.org> wrote: > > > > > > On Fri, Jan 20, 2023 at 08:48:07PM +0100, Rafael J. Wysocki wrote: > > > > From: Rafael J. Wysocki <rafael.j.wysocki@intel.com> > > > > > > > > If thermal_class is not registered with the driver core, there is no way > > > > to expose the interfaces used by the thermal control framework, so > > > > prevent thermal zones and cooling devices from being registered in > > > > that case by returning an error from object registration functions. > > > > > > > > For this purpose, introduce class_is_registered() that checks the > > > > private pointer of the given class and returns 'false' if it is NULL, > > > > which means that the class has not been registered, and use it in the > > > > thermal framework. > > > > > > > > Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> > > > > --- > > > > drivers/thermal/thermal_core.c | 6 ++++++ > > > > include/linux/device/class.h | 5 +++++ > > > > 2 files changed, 11 insertions(+) > > > > > > > > Index: linux-pm/include/linux/device/class.h > > > > =================================================================== > > > > --- linux-pm.orig/include/linux/device/class.h > > > > +++ linux-pm/include/linux/device/class.h > > > > @@ -82,6 +82,11 @@ struct class_dev_iter { > > > > const struct device_type *type; > > > > }; > > > > > > > > +static inline bool class_is_registered(struct class *class) > > > > +{ > > > > + return !!class->p; > > > > > > I really do not like this as it is exposing internals to drivers and > > > whenever we do that, it gets abused and we have to unwind the mess in a > > > few years. > > > > > > Overall, I'm trying to remove the ->p usage, but that's a longterm goal > > > of mine (to allow class and bus structures to be in read-only memory), > > > which isn't your issue here, but it's good to think about why you want > > > to know this information (more below.) > > > > > > > +} > > > > + > > > > extern struct kobject *sysfs_dev_block_kobj; > > > > extern struct kobject *sysfs_dev_char_kobj; > > > > extern int __must_check __class_register(struct class *class, > > > > Index: linux-pm/drivers/thermal/thermal_core.c > > > > =================================================================== > > > > --- linux-pm.orig/drivers/thermal/thermal_core.c > > > > +++ linux-pm/drivers/thermal/thermal_core.c > > > > @@ -880,6 +880,9 @@ __thermal_cooling_device_register(struct > > > > !ops->set_cur_state) > > > > return ERR_PTR(-EINVAL); > > > > > > > > + if (!class_is_registered(&thermal_class)) > > > > + return ERR_PTR(-ENODEV); > > > > > > If the class isn't registered, then sommething went wrong with the > > > thermal core code, right? So why isn't the thermal core keeping a local > > > variable of "class was registered" and relying on the driver core to > > > know this? > > > > > > The number of individual users that should be doing one thing or another > > > if a class is not registered feels very very slim. How come this code > > > is being called at all if the thermal class was not registered in the > > > first place? What would have prevented that from happening? Is it an > > > ordering issue, or a kernel configuration issue? > > > > It's basically a matter of class_register() returning an error. > > Ok, so not a real problem then :) > > > Yes, we could use an extra variable for this purpose, but that would > > be a bit wasteful, because thermal_class will then sit unused and > > occupy memory in vain. > > How would it retain memory if class_register() failed? The point was that we might use the existing (but not registered) class object to "flag" the fact that the class could not be used without adding extra variables. > > Oh well, we may as well just allocate it dynamically. > > Allocate what? Well, that was a bit terse, sorry. This patch implements what I meant: https://patchwork.kernel.org/project/linux-pm/patch/5660360.DvuYhMxLoT@kreacher/ ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [PATCH v1 2/2] thermal: Fail object registration if thermal class is not registered 2023-01-24 13:57 ` Rafael J. Wysocki @ 2023-01-24 17:03 ` Greg Kroah-Hartman 0 siblings, 0 replies; 10+ messages in thread From: Greg Kroah-Hartman @ 2023-01-24 17:03 UTC (permalink / raw) To: Rafael J. Wysocki Cc: Rafael J. Wysocki, Linux PM, LKML, Daniel Lezcano, Srinivas Pandruvada, Zhang Rui On Tue, Jan 24, 2023 at 02:57:55PM +0100, Rafael J. Wysocki wrote: > On Tue, Jan 24, 2023 at 7:03 AM Greg Kroah-Hartman <gregkh@linuxfoundation.org> wrote: > > > > Oh well, we may as well just allocate it dynamically. > > > > Allocate what? > > Well, that was a bit terse, sorry. > > This patch implements what I meant: > https://patchwork.kernel.org/project/linux-pm/patch/5660360.DvuYhMxLoT@kreacher/ That looks good, I like that change, it's much simpler overall. greg k-h ^ permalink raw reply [flat|nested] 10+ messages in thread
end of thread, other threads:[~2023-01-24 17:04 UTC | newest] Thread overview: 10+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2023-01-20 19:45 [PATCH v1 0/2] driver core/thermal: Fail registration of thermal object when thermal_class is not registered Rafael J. Wysocki 2023-01-20 19:46 ` [PATCH v1 1/2] driver core: class: Clear private pointer on registration failures Rafael J. Wysocki 2023-01-20 22:43 ` Daniel Lezcano 2023-01-20 19:48 ` [PATCH v1 2/2] thermal: Fail object registration if thermal class is not registered Rafael J. Wysocki 2023-01-20 22:43 ` Daniel Lezcano 2023-01-21 7:40 ` Greg Kroah-Hartman 2023-01-23 20:16 ` Rafael J. Wysocki 2023-01-24 6:03 ` Greg Kroah-Hartman 2023-01-24 13:57 ` Rafael J. Wysocki 2023-01-24 17:03 ` Greg Kroah-Hartman
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).