[RFC PATCH 1/2] PM: EM: Export em_table_alloc/free

[RFC PATCH 1/2] PM: EM: Export em_table_alloc/free

[Xuewen Yan]

When drivers wants to alloc a new em_perf_table to update
their em_perf_table, they need to use em_table_alloc and
em_table_free.
So export the two func.

Signed-off-by: Xuewen Yan <xuewen.yan@unisoc.com>
---
 kernel/power/energy_model.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/kernel/power/energy_model.c b/kernel/power/energy_model.c
index e610cf8e9a06..277aaf1b19da 100644
--- a/kernel/power/energy_model.c
+++ b/kernel/power/energy_model.c
@@ -201,6 +201,7 @@ void em_table_free(struct em_perf_table *table)
 {
 	kref_put(&table->kref, em_release_table_kref);
 }
+EXPORT_SYMBOL_GPL(em_table_free);
 
 /**
  * em_table_alloc() - Allocate a new EM table
@@ -225,6 +226,7 @@ struct em_perf_table *em_table_alloc(struct em_perf_domain *pd)
 
 	return table;
 }
+EXPORT_SYMBOL_GPL(em_table_alloc);
 
 static void em_init_performance(struct device *dev, struct em_perf_domain *pd,
 				struct em_perf_state *table, int nr_states)
-- 
2.25.1

[RFC PATCH 2/2] PM: EM: Validate new_table in em_dev_update_perf_domain()

[Xuewen Yan]

Add an explicit check for the new_table parameter in
em_dev_update_perf_domain() to ensure it is not NULL or an
ERR_PTR before proceeding with the update.

Signed-off-by: Xuewen Yan <xuewen.yan@unisoc.com>
---
 kernel/power/energy_model.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/kernel/power/energy_model.c b/kernel/power/energy_model.c
index 277aaf1b19da..4d75e1b3c20e 100644
--- a/kernel/power/energy_model.c
+++ b/kernel/power/energy_model.c
@@ -331,7 +331,7 @@ int em_dev_update_perf_domain(struct device *dev,
 	struct em_perf_table *old_table;
 	struct em_perf_domain *pd;
 
-	if (!dev)
+	if (!dev || IS_ERR_OR_NULL(new_table))
 		return -EINVAL;
 
 	/* Serialize update/unregister or concurrent updates */
-- 
2.25.1

Re: [RFC PATCH 1/2] PM: EM: Export em_table_alloc/free

[Lukasz Luba]

On 7/10/26 09:24, Xuewen Yan wrote:
> When drivers wants to alloc a new em_perf_table to update
> their em_perf_table, they need to use em_table_alloc and
> em_table_free.
> So export the two func.
> 
> Signed-off-by: Xuewen Yan <xuewen.yan@unisoc.com>
> ---
>   kernel/power/energy_model.c | 2 ++
>   1 file changed, 2 insertions(+)
> 
> diff --git a/kernel/power/energy_model.c b/kernel/power/energy_model.c
> index e610cf8e9a06..277aaf1b19da 100644
> --- a/kernel/power/energy_model.c
> +++ b/kernel/power/energy_model.c
> @@ -201,6 +201,7 @@ void em_table_free(struct em_perf_table *table)
>   {
>   	kref_put(&table->kref, em_release_table_kref);
>   }
> +EXPORT_SYMBOL_GPL(em_table_free);
>   
>   /**
>    * em_table_alloc() - Allocate a new EM table
> @@ -225,6 +226,7 @@ struct em_perf_table *em_table_alloc(struct em_perf_domain *pd)
>   
>   	return table;
>   }
> +EXPORT_SYMBOL_GPL(em_table_alloc);
>   
>   static void em_init_performance(struct device *dev, struct em_perf_domain *pd,
>   				struct em_perf_state *table, int nr_states)

LGTM,

Reviewed-by: Lukasz Luba <lukasz.luba@arm.com>

Re: [RFC PATCH 2/2] PM: EM: Validate new_table in em_dev_update_perf_domain()

[Lukasz Luba]

On 7/10/26 09:24, Xuewen Yan wrote:
> Add an explicit check for the new_table parameter in
> em_dev_update_perf_domain() to ensure it is not NULL or an
> ERR_PTR before proceeding with the update.
> 
> Signed-off-by: Xuewen Yan <xuewen.yan@unisoc.com>
> ---
>   kernel/power/energy_model.c | 2 +-
>   1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/kernel/power/energy_model.c b/kernel/power/energy_model.c
> index 277aaf1b19da..4d75e1b3c20e 100644
> --- a/kernel/power/energy_model.c
> +++ b/kernel/power/energy_model.c
> @@ -331,7 +331,7 @@ int em_dev_update_perf_domain(struct device *dev,
>   	struct em_perf_table *old_table;
>   	struct em_perf_domain *pd;
>   
> -	if (!dev)
> +	if (!dev || IS_ERR_OR_NULL(new_table))
>   		return -EINVAL;
>   
>   	/* Serialize update/unregister or concurrent updates */


Make sense to check that and catch possible issue this way.

Reviewed-by: Lukasz Luba <lukasz.luba@arm.com>

Re: [RFC PATCH 1/2] PM: EM: Export em_table_alloc/free

[Christoph Hellwig]

On Fri, Jul 10, 2026 at 04:24:46PM +0800, Xuewen Yan wrote:
> When drivers wants to alloc a new em_perf_table to update
> their em_perf_table, they need to use em_table_alloc and
> em_table_free.
> So export the two func.

Please send this along with the driver actually using it.

Re: [RFC PATCH 1/2] PM: EM: Export em_table_alloc/free

[Xuewen Yan]

Hi Christoph,

On Mon, Jul 13, 2026 at 3:34 PM Christoph Hellwig <hch@infradead.org> wrote:
>
> On Fri, Jul 10, 2026 at 04:24:46PM +0800, Xuewen Yan wrote:
> > When drivers wants to alloc a new em_perf_table to update
> > their em_perf_table, they need to use em_table_alloc and
> > em_table_free.
> > So export the two func.
>
> Please send this along with the driver actually using it.
>

Sorry for the late reply.
we use it in android vendor specific ko, and the ko is not upstream.
We use them with em_dev_update_perf_domain(), Just like
em_dev_update_perf_domain() was exported, export the
em_table_alloc/free.

Thanks!

BR
---
xuewen

Re: [RFC PATCH 1/2] PM: EM: Export em_table_alloc/free

[Christoph Hellwig]

On Tue, Jul 21, 2026 at 07:10:38PM +0800, Xuewen Yan wrote:
> we use it in android vendor specific ko, and the ko is not upstream.
> We use them with em_dev_update_perf_domain(), Just like
> em_dev_update_perf_domain() was exported, export the
> em_table_alloc/free.

As you've probably been told many times exporting symbols without
in-tree users that are in the same series or at least directly
references is a no-go, and continuing to post them is considered
extremely offensive.  Don't do this.

Re: [RFC PATCH 1/2] PM: EM: Export em_table_alloc/free

[Lukasz Luba]

On 7/22/26 10:01, Christoph Hellwig wrote:
> On Tue, Jul 21, 2026 at 07:10:38PM +0800, Xuewen Yan wrote:
>> we use it in android vendor specific ko, and the ko is not upstream.
>> We use them with em_dev_update_perf_domain(), Just like
>> em_dev_update_perf_domain() was exported, export the
>> em_table_alloc/free.
> 
> As you've probably been told many times exporting symbols without
> in-tree users that are in the same series or at least directly
> references is a no-go, and continuing to post them is considered
> extremely offensive.  Don't do this.
> 

It's a bit more complex situation IMHO. We have been always
struggling to involve kernel folks from Android world to contribute
into the mainline Linux. The thing is they have to apply some hacks
in order to make the plumbing for the new devices. This is
an example where they struggle. They ask work vendor hooks to workaround
which complicates even more the maintenance of stable Android kernel.
I have seen those good examples where finally the drivers are pushed
upstream, since downstream maintenance complexity is too high. Something
has to break this circle.

Re: [RFC PATCH 1/2] PM: EM: Export em_table_alloc/free

[Christoph Hellwig]

On Mon, Jul 27, 2026 at 09:03:04AM +0100, Lukasz Luba wrote:
> It's a bit more complex situation IMHO.

It's not.  And if you think stupid Android decisions that are 100%
contrary to upstream policies should in any way relevant, you should
spend your time on RTOS BSPs and not argue on Linux mailing lists.

Re: [RFC PATCH 1/2] PM: EM: Export em_table_alloc/free

[Lukasz Luba]

On 7/28/26 04:36, Christoph Hellwig wrote:
> On Mon, Jul 27, 2026 at 09:03:04AM +0100, Lukasz Luba wrote:
>> It's a bit more complex situation IMHO.
> 
> It's not.  And if you think stupid Android decisions that are 100%
> contrary to upstream policies should in any way relevant, you should
> spend your time on RTOS BSPs and not argue on Linux mailing lists.
> 

We will make a driver using that and the export would be attached to
the series. I won't recommend you to spend your time on RTOS BSPs
but I would to spend on your sub-system. It would benefit more from
your experience than this EAS+EM complex world.

Re: [RFC PATCH 1/2] PM: EM: Export em_table_alloc/free

[Christoph Hellwig]

On Tue, Jul 28, 2026 at 09:07:43AM +0100, Lukasz Luba wrote:
> 
> 
> On 7/28/26 04:36, Christoph Hellwig wrote:
> > On Mon, Jul 27, 2026 at 09:03:04AM +0100, Lukasz Luba wrote:
> > > It's a bit more complex situation IMHO.
> > 
> > It's not.  And if you think stupid Android decisions that are 100%
> > contrary to upstream policies should in any way relevant, you should
> > spend your time on RTOS BSPs and not argue on Linux mailing lists.
> > 
> 
> We will make a driver using that and the export would be attached to
> the series.

And that is the way to do it.

> I won't recommend you to spend your time on RTOS BSPs
> but I would to spend on your sub-system. It would benefit more from
> your experience than this EAS+EM complex world.

And this still shows that you're in the wrong place here..

>