* [PATCH v2] firmware: arm_scmi: Delete the meaningless scmi_bus_id.
@ 2024-12-16 7:37 guomin_chen
2024-12-16 8:31 ` Dan Carpenter
2024-12-16 8:50 ` Cristian Marussi
0 siblings, 2 replies; 10+ messages in thread
From: guomin_chen @ 2024-12-16 7:37 UTC (permalink / raw)
To: Sudeep Holla, Cristian Marussi, Xinqi Zhang, guomin chen
Cc: arm-scmi, linux-arm-kernel, guomin chen
From: guomin chen <guomin_chen@sina.com>
Currently, scmi_bus_id is only used to set scmi_dev.id,
which in turn sets the SCMI device name. After removing
scmi_bus_id, it is clearer and more meaningful to directly
use the unique tuple [Parent name,device name, protocol] to
set the SCMI device name.
Signed-off-by: guomin chen <guomin_chen@sina.com>
---
drivers/firmware/arm_scmi/bus.c | 17 +++--------------
drivers/firmware/arm_scmi/driver.c | 4 ++--
2 files changed, 5 insertions(+), 16 deletions(-)
diff --git a/drivers/firmware/arm_scmi/bus.c b/drivers/firmware/arm_scmi/bus.c
index 157172a5f2b5..800e8ec9357c 100644
--- a/drivers/firmware/arm_scmi/bus.c
+++ b/drivers/firmware/arm_scmi/bus.c
@@ -20,7 +20,6 @@
BLOCKING_NOTIFIER_HEAD(scmi_requested_devices_nh);
EXPORT_SYMBOL_GPL(scmi_requested_devices_nh);
-static DEFINE_IDA(scmi_bus_id);
static DEFINE_IDR(scmi_requested_devices);
/* Protect access to scmi_requested_devices */
@@ -341,7 +340,6 @@ static void __scmi_device_destroy(struct scmi_device *scmi_dev)
if (scmi_dev->protocol_id == SCMI_PROTOCOL_SYSTEM)
atomic_set(&scmi_syspower_registered, 0);
- ida_free(&scmi_bus_id, scmi_dev->id);
device_unregister(&scmi_dev->dev);
}
@@ -349,7 +347,7 @@ static struct scmi_device *
__scmi_device_create(struct device_node *np, struct device *parent,
int protocol, const char *name)
{
- int id, retval;
+ int retval;
struct scmi_device *scmi_dev;
/*
@@ -387,20 +385,13 @@ __scmi_device_create(struct device_node *np, struct device *parent,
return NULL;
}
- id = ida_alloc_min(&scmi_bus_id, 1, GFP_KERNEL);
- if (id < 0) {
- kfree_const(scmi_dev->name);
- kfree(scmi_dev);
- return NULL;
- }
-
- scmi_dev->id = id;
scmi_dev->protocol_id = protocol;
scmi_dev->dev.parent = parent;
device_set_node(&scmi_dev->dev, of_fwnode_handle(np));
scmi_dev->dev.bus = &scmi_bus_type;
scmi_dev->dev.release = scmi_device_release;
- dev_set_name(&scmi_dev->dev, "scmi_dev.%d", id);
+ dev_set_name(&scmi_dev->dev, "scmi_dev.%s.%s.%d", dev_name(parent),
+ scmi_dev->name, protocol);
retval = device_register(&scmi_dev->dev);
if (retval)
@@ -413,7 +404,6 @@ __scmi_device_create(struct device_node *np, struct device *parent,
return scmi_dev;
put_dev:
put_device(&scmi_dev->dev);
- ida_free(&scmi_bus_id, id);
return NULL;
}
@@ -526,7 +516,6 @@ static void __exit scmi_bus_exit(void)
*/
scmi_devices_unregister();
bus_unregister(&scmi_bus_type);
- ida_destroy(&scmi_bus_id);
}
module_exit(scmi_bus_exit);
diff --git a/drivers/firmware/arm_scmi/driver.c b/drivers/firmware/arm_scmi/driver.c
index 1b5fb2c4ce86..bbf1f05f2be3 100644
--- a/drivers/firmware/arm_scmi/driver.c
+++ b/drivers/firmware/arm_scmi/driver.c
@@ -2641,8 +2641,8 @@ static int scmi_chan_setup(struct scmi_info *info, struct device_node *of_node,
cinfo->max_msg_size = info->desc->max_msg_size;
/* Create a unique name for this transport device */
- snprintf(name, 32, "__scmi_transport_device_%s_%02X",
- idx ? "rx" : "tx", prot_id);
+ snprintf(name, 32, "__scmi_transport_device_%s",
+ idx ? "rx" : "tx");
/* Create a uniquely named, dedicated transport device for this chan */
tdev = scmi_device_create(of_node, info->dev, prot_id, name);
if (!tdev) {
--
2.47.1
^ permalink raw reply related [flat|nested] 10+ messages in thread
* Re: [PATCH v2] firmware: arm_scmi: Delete the meaningless scmi_bus_id.
2024-12-16 7:37 [PATCH v2] firmware: arm_scmi: Delete the meaningless scmi_bus_id guomin_chen
@ 2024-12-16 8:31 ` Dan Carpenter
2024-12-16 8:50 ` Cristian Marussi
1 sibling, 0 replies; 10+ messages in thread
From: Dan Carpenter @ 2024-12-16 8:31 UTC (permalink / raw)
To: guomin_chen
Cc: Sudeep Holla, Cristian Marussi, Xinqi Zhang, guomin chen,
arm-scmi, linux-arm-kernel
On Mon, Dec 16, 2024 at 03:37:45PM +0800, guomin_chen@sina.com wrote:
> From: guomin chen <guomin_chen@sina.com>
>
> Currently, scmi_bus_id is only used to set scmi_dev.id,
> which in turn sets the SCMI device name. After removing
> scmi_bus_id, it is clearer and more meaningful to directly
> use the unique tuple [Parent name,device name, protocol] to
> set the SCMI device name.
>
> Signed-off-by: guomin chen <guomin_chen@sina.com>
> ---
> drivers/firmware/arm_scmi/bus.c | 17 +++--------------
> drivers/firmware/arm_scmi/driver.c | 4 ++--
> 2 files changed, 5 insertions(+), 16 deletions(-)
>
> diff --git a/drivers/firmware/arm_scmi/bus.c b/drivers/firmware/arm_scmi/bus.c
> index 157172a5f2b5..800e8ec9357c 100644
> --- a/drivers/firmware/arm_scmi/bus.c
> +++ b/drivers/firmware/arm_scmi/bus.c
> @@ -20,7 +20,6 @@
> BLOCKING_NOTIFIER_HEAD(scmi_requested_devices_nh);
> EXPORT_SYMBOL_GPL(scmi_requested_devices_nh);
>
> -static DEFINE_IDA(scmi_bus_id);
>
You'll want to delet the blank line to avoid a checkpatch warning.
(checkpatch doesn't warn about the patch, but if you re-run it on
the file later, it will warn).
> static DEFINE_IDR(scmi_requested_devices);
> /* Protect access to scmi_requested_devices */
> @@ -341,7 +340,6 @@ static void __scmi_device_destroy(struct scmi_device *scmi_dev)
> if (scmi_dev->protocol_id == SCMI_PROTOCOL_SYSTEM)
> atomic_set(&scmi_syspower_registered, 0);
>
> - ida_free(&scmi_bus_id, scmi_dev->id);
> device_unregister(&scmi_dev->dev);
> }
>
> @@ -349,7 +347,7 @@ static struct scmi_device *
> __scmi_device_create(struct device_node *np, struct device *parent,
> int protocol, const char *name)
> {
> - int id, retval;
> + int retval;
> struct scmi_device *scmi_dev;
>
> /*
> @@ -387,20 +385,13 @@ __scmi_device_create(struct device_node *np, struct device *parent,
> return NULL;
> }
>
> - id = ida_alloc_min(&scmi_bus_id, 1, GFP_KERNEL);
> - if (id < 0) {
> - kfree_const(scmi_dev->name);
> - kfree(scmi_dev);
> - return NULL;
> - }
> -
> - scmi_dev->id = id;
> scmi_dev->protocol_id = protocol;
> scmi_dev->dev.parent = parent;
> device_set_node(&scmi_dev->dev, of_fwnode_handle(np));
> scmi_dev->dev.bus = &scmi_bus_type;
> scmi_dev->dev.release = scmi_device_release;
> - dev_set_name(&scmi_dev->dev, "scmi_dev.%d", id);
> + dev_set_name(&scmi_dev->dev, "scmi_dev.%s.%s.%d", dev_name(parent),
> + scmi_dev->name, protocol);
>
> retval = device_register(&scmi_dev->dev);
> if (retval)
> @@ -413,7 +404,6 @@ __scmi_device_create(struct device_node *np, struct device *parent,
> return scmi_dev;
> put_dev:
> put_device(&scmi_dev->dev);
> - ida_free(&scmi_bus_id, id);
> return NULL;
> }
>
> @@ -526,7 +516,6 @@ static void __exit scmi_bus_exit(void)
> */
> scmi_devices_unregister();
> bus_unregister(&scmi_bus_type);
> - ida_destroy(&scmi_bus_id);
> }
> module_exit(scmi_bus_exit);
>
> diff --git a/drivers/firmware/arm_scmi/driver.c b/drivers/firmware/arm_scmi/driver.c
> index 1b5fb2c4ce86..bbf1f05f2be3 100644
> --- a/drivers/firmware/arm_scmi/driver.c
> +++ b/drivers/firmware/arm_scmi/driver.c
> @@ -2641,8 +2641,8 @@ static int scmi_chan_setup(struct scmi_info *info, struct device_node *of_node,
> cinfo->max_msg_size = info->desc->max_msg_size;
>
> /* Create a unique name for this transport device */
This comment should be updated.
> - snprintf(name, 32, "__scmi_transport_device_%s_%02X",
> - idx ? "rx" : "tx", prot_id);
> + snprintf(name, 32, "__scmi_transport_device_%s",
> + idx ? "rx" : "tx");
We used to create new transport devices for each port, but now we
only we only create one for recieve and one for transmit. This is
unrelated to the commit message and needs to be done in separate commit
if at all.
regards,
dan carpenter
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [PATCH v2] firmware: arm_scmi: Delete the meaningless scmi_bus_id.
2024-12-16 7:37 [PATCH v2] firmware: arm_scmi: Delete the meaningless scmi_bus_id guomin_chen
2024-12-16 8:31 ` Dan Carpenter
@ 2024-12-16 8:50 ` Cristian Marussi
2024-12-16 9:45 ` Cristian Marussi
1 sibling, 1 reply; 10+ messages in thread
From: Cristian Marussi @ 2024-12-16 8:50 UTC (permalink / raw)
To: guomin_chen
Cc: Sudeep Holla, Cristian Marussi, Xinqi Zhang, guomin chen,
arm-scmi, linux-arm-kernel, dan.carpenter
On Mon, Dec 16, 2024 at 03:37:45PM +0800, guomin_chen@sina.com wrote:
> From: guomin chen <guomin_chen@sina.com>
>
> Currently, scmi_bus_id is only used to set scmi_dev.id,
> which in turn sets the SCMI device name. After removing
> scmi_bus_id, it is clearer and more meaningful to directly
> use the unique tuple [Parent name,device name, protocol] to
> set the SCMI device name.
>
Hi Guomin,
this same pTCH was NACKed(Rejected) a few days ago:
https://lore.kernel.org/arm-scmi/20241211134505.2218386-1-guomin_chen@sina.com/T/#u
...and you agreed that is not a simplification we can do (not to break
multuple instances...)...
..so why you are posting V2 now ?
Thanks,
Cristian
> Signed-off-by: guomin chen <guomin_chen@sina.com>
> ---
> drivers/firmware/arm_scmi/bus.c | 17 +++--------------
> drivers/firmware/arm_scmi/driver.c | 4 ++--
> 2 files changed, 5 insertions(+), 16 deletions(-)
>
> diff --git a/drivers/firmware/arm_scmi/bus.c b/drivers/firmware/arm_scmi/bus.c
> index 157172a5f2b5..800e8ec9357c 100644
> --- a/drivers/firmware/arm_scmi/bus.c
> +++ b/drivers/firmware/arm_scmi/bus.c
> @@ -20,7 +20,6 @@
> BLOCKING_NOTIFIER_HEAD(scmi_requested_devices_nh);
> EXPORT_SYMBOL_GPL(scmi_requested_devices_nh);
>
> -static DEFINE_IDA(scmi_bus_id);
>
> static DEFINE_IDR(scmi_requested_devices);
> /* Protect access to scmi_requested_devices */
> @@ -341,7 +340,6 @@ static void __scmi_device_destroy(struct scmi_device *scmi_dev)
> if (scmi_dev->protocol_id == SCMI_PROTOCOL_SYSTEM)
> atomic_set(&scmi_syspower_registered, 0);
>
> - ida_free(&scmi_bus_id, scmi_dev->id);
> device_unregister(&scmi_dev->dev);
> }
>
> @@ -349,7 +347,7 @@ static struct scmi_device *
> __scmi_device_create(struct device_node *np, struct device *parent,
> int protocol, const char *name)
> {
> - int id, retval;
> + int retval;
> struct scmi_device *scmi_dev;
>
> /*
> @@ -387,20 +385,13 @@ __scmi_device_create(struct device_node *np, struct device *parent,
> return NULL;
> }
>
> - id = ida_alloc_min(&scmi_bus_id, 1, GFP_KERNEL);
> - if (id < 0) {
> - kfree_const(scmi_dev->name);
> - kfree(scmi_dev);
> - return NULL;
> - }
> -
> - scmi_dev->id = id;
> scmi_dev->protocol_id = protocol;
> scmi_dev->dev.parent = parent;
> device_set_node(&scmi_dev->dev, of_fwnode_handle(np));
> scmi_dev->dev.bus = &scmi_bus_type;
> scmi_dev->dev.release = scmi_device_release;
> - dev_set_name(&scmi_dev->dev, "scmi_dev.%d", id);
> + dev_set_name(&scmi_dev->dev, "scmi_dev.%s.%s.%d", dev_name(parent),
> + scmi_dev->name, protocol);
>
> retval = device_register(&scmi_dev->dev);
> if (retval)
> @@ -413,7 +404,6 @@ __scmi_device_create(struct device_node *np, struct device *parent,
> return scmi_dev;
> put_dev:
> put_device(&scmi_dev->dev);
> - ida_free(&scmi_bus_id, id);
> return NULL;
> }
>
> @@ -526,7 +516,6 @@ static void __exit scmi_bus_exit(void)
> */
> scmi_devices_unregister();
> bus_unregister(&scmi_bus_type);
> - ida_destroy(&scmi_bus_id);
> }
> module_exit(scmi_bus_exit);
>
> diff --git a/drivers/firmware/arm_scmi/driver.c b/drivers/firmware/arm_scmi/driver.c
> index 1b5fb2c4ce86..bbf1f05f2be3 100644
> --- a/drivers/firmware/arm_scmi/driver.c
> +++ b/drivers/firmware/arm_scmi/driver.c
> @@ -2641,8 +2641,8 @@ static int scmi_chan_setup(struct scmi_info *info, struct device_node *of_node,
> cinfo->max_msg_size = info->desc->max_msg_size;
>
> /* Create a unique name for this transport device */
> - snprintf(name, 32, "__scmi_transport_device_%s_%02X",
> - idx ? "rx" : "tx", prot_id);
> + snprintf(name, 32, "__scmi_transport_device_%s",
> + idx ? "rx" : "tx");
> /* Create a uniquely named, dedicated transport device for this chan */
> tdev = scmi_device_create(of_node, info->dev, prot_id, name);
> if (!tdev) {
> --
> 2.47.1
>
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [PATCH v2] firmware: arm_scmi: Delete the meaningless scmi_bus_id.
2024-12-16 8:50 ` Cristian Marussi
@ 2024-12-16 9:45 ` Cristian Marussi
2024-12-16 10:37 ` gchen chen
0 siblings, 1 reply; 10+ messages in thread
From: Cristian Marussi @ 2024-12-16 9:45 UTC (permalink / raw)
To: guomin_chen
Cc: Sudeep Holla, Cristian Marussi, Xinqi Zhang, guomin chen,
arm-scmi, linux-arm-kernel, dan.carpenter
On Mon, Dec 16, 2024 at 08:50:26AM +0000, Cristian Marussi wrote:
> On Mon, Dec 16, 2024 at 03:37:45PM +0800, guomin_chen@sina.com wrote:
> > From: guomin chen <guomin_chen@sina.com>
> >
> > Currently, scmi_bus_id is only used to set scmi_dev.id,
> > which in turn sets the SCMI device name. After removing
> > scmi_bus_id, it is clearer and more meaningful to directly
> > use the unique tuple [Parent name,device name, protocol] to
> > set the SCMI device name.
> >
>
> Hi Guomin,
>
> this same pTCH was NACKed(Rejected) a few days ago:
>
> https://lore.kernel.org/arm-scmi/20241211134505.2218386-1-guomin_chen@sina.com/T/#u
>
> ...and you agreed that is not a simplification we can do (not to break
> multuple instances...)...
>
> ..so why you are posting V2 now ?
Wait...you changed slightly this indeed....you are using dev_parent...my
bad...but please when you post new version of a patch add a summary of
changes between versions...
>
> Thanks,
> Cristian
>
> > Signed-off-by: guomin chen <guomin_chen@sina.com>
> > ---
> > drivers/firmware/arm_scmi/bus.c | 17 +++--------------
> > drivers/firmware/arm_scmi/driver.c | 4 ++--
> > 2 files changed, 5 insertions(+), 16 deletions(-)
> >
> > diff --git a/drivers/firmware/arm_scmi/bus.c b/drivers/firmware/arm_scmi/bus.c
> > index 157172a5f2b5..800e8ec9357c 100644
> > --- a/drivers/firmware/arm_scmi/bus.c
> > +++ b/drivers/firmware/arm_scmi/bus.c
> > @@ -20,7 +20,6 @@
> > BLOCKING_NOTIFIER_HEAD(scmi_requested_devices_nh);
> > EXPORT_SYMBOL_GPL(scmi_requested_devices_nh);
> >
> > -static DEFINE_IDA(scmi_bus_id);
> >
> > static DEFINE_IDR(scmi_requested_devices);
> > /* Protect access to scmi_requested_devices */
> > @@ -341,7 +340,6 @@ static void __scmi_device_destroy(struct scmi_device *scmi_dev)
> > if (scmi_dev->protocol_id == SCMI_PROTOCOL_SYSTEM)
> > atomic_set(&scmi_syspower_registered, 0);
> >
> > - ida_free(&scmi_bus_id, scmi_dev->id);
> > device_unregister(&scmi_dev->dev);
> > }
> >
> > @@ -349,7 +347,7 @@ static struct scmi_device *
> > __scmi_device_create(struct device_node *np, struct device *parent,
> > int protocol, const char *name)
> > {
> > - int id, retval;
> > + int retval;
> > struct scmi_device *scmi_dev;
> >
> > /*
> > @@ -387,20 +385,13 @@ __scmi_device_create(struct device_node *np, struct device *parent,
> > return NULL;
> > }
> >
> > - id = ida_alloc_min(&scmi_bus_id, 1, GFP_KERNEL);
> > - if (id < 0) {
> > - kfree_const(scmi_dev->name);
> > - kfree(scmi_dev);
> > - return NULL;
> > - }
> > -
> > - scmi_dev->id = id;
> > scmi_dev->protocol_id = protocol;
> > scmi_dev->dev.parent = parent;
> > device_set_node(&scmi_dev->dev, of_fwnode_handle(np));
> > scmi_dev->dev.bus = &scmi_bus_type;
> > scmi_dev->dev.release = scmi_device_release;
> > - dev_set_name(&scmi_dev->dev, "scmi_dev.%d", id);
> > + dev_set_name(&scmi_dev->dev, "scmi_dev.%s.%s.%d", dev_name(parent),
> > + scmi_dev->name, protocol);
> >
So now you are using the parent top node SCMI device to create a unique
device...and it probably endup in a name like:
scmi-dev.arm-scmi.0.auto.genpd.13
scmi-dev.arm-scmi.1.auto.genpd.13
...that certainly is more readable but is bulky and anyway giving unique
IDs to devices is pretty common and you lookup which device is which by
simply looking at the drivers/ link....not suure what's the benefit of
all of this...just to avoid an IDA table ?
> > retval = device_register(&scmi_dev->dev);
> > if (retval)
> > @@ -413,7 +404,6 @@ __scmi_device_create(struct device_node *np, struct device *parent,
> > return scmi_dev;
> > put_dev:
> > put_device(&scmi_dev->dev);
> > - ida_free(&scmi_bus_id, id);
> > return NULL;
> > }
> >
> > @@ -526,7 +516,6 @@ static void __exit scmi_bus_exit(void)
> > */
> > scmi_devices_unregister();
> > bus_unregister(&scmi_bus_type);
> > - ida_destroy(&scmi_bus_id);
> > }
> > module_exit(scmi_bus_exit);
> >
> > diff --git a/drivers/firmware/arm_scmi/driver.c b/drivers/firmware/arm_scmi/driver.c
> > index 1b5fb2c4ce86..bbf1f05f2be3 100644
> > --- a/drivers/firmware/arm_scmi/driver.c
> > +++ b/drivers/firmware/arm_scmi/driver.c
> > @@ -2641,8 +2641,8 @@ static int scmi_chan_setup(struct scmi_info *info, struct device_node *of_node,
> > cinfo->max_msg_size = info->desc->max_msg_size;
> >
> > /* Create a unique name for this transport device */
> > - snprintf(name, 32, "__scmi_transport_device_%s_%02X",
> > - idx ? "rx" : "tx", prot_id);
> > + snprintf(name, 32, "__scmi_transport_device_%s",
> > + idx ? "rx" : "tx");
I agree on what Dan said AND also this results in having the same name for different
devices across 2 instances if you have a per-protocol channel because you havent anymore
the protocol_id bit.
All in all, I would drop this patch and keep naming as it is because I dont see a real benefit
here....up to Sudeep decide.
Thanks,
Cristian
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [PATCH v2] firmware: arm_scmi: Delete the meaningless scmi_bus_id.
2024-12-16 9:45 ` Cristian Marussi
@ 2024-12-16 10:37 ` gchen chen
2024-12-16 10:45 ` Sudeep Holla
2024-12-16 15:03 ` Dan Carpenter
0 siblings, 2 replies; 10+ messages in thread
From: gchen chen @ 2024-12-16 10:37 UTC (permalink / raw)
To: Cristian Marussi
Cc: guomin_chen, Sudeep Holla, Xinqi Zhang, arm-scmi,
linux-arm-kernel, dan.carpenter
Cristian Marussi <cristian.marussi@arm.com> 于2024年12月16日周一 17:45写道:
>
> On Mon, Dec 16, 2024 at 08:50:26AM +0000, Cristian Marussi wrote:
> > On Mon, Dec 16, 2024 at 03:37:45PM +0800, guomin_chen@sina.com wrote:
> > > From: guomin chen <guomin_chen@sina.com>
> > >
> > > Currently, scmi_bus_id is only used to set scmi_dev.id,
> > > which in turn sets the SCMI device name. After removing
> > > scmi_bus_id, it is clearer and more meaningful to directly
> > > use the unique tuple [Parent name,device name, protocol] to
> > > set the SCMI device name.
> > >
> >
> > Hi Guomin,
> >
> > this same pTCH was NACKed(Rejected) a few days ago:
> >
> > https://lore.kernel.org/arm-scmi/20241211134505.2218386-1-guomin_chen@sina.com/T/#u
> >
> > ...and you agreed that is not a simplification we can do (not to break
> > multuple instances...)...
> >
> > ..so why you are posting V2 now ?
>
> Wait...you changed slightly this indeed....you are using dev_parent...my
> bad...but please when you post new version of a patch add a summary of
> changes between versions...
>
> >
> > Thanks,
> > Cristian
> >
> > > Signed-off-by: guomin chen <guomin_chen@sina.com>
> > > ---
> > > drivers/firmware/arm_scmi/bus.c | 17 +++--------------
> > > drivers/firmware/arm_scmi/driver.c | 4 ++--
> > > 2 files changed, 5 insertions(+), 16 deletions(-)
> > >
> > > diff --git a/drivers/firmware/arm_scmi/bus.c b/drivers/firmware/arm_scmi/bus.c
> > > index 157172a5f2b5..800e8ec9357c 100644
> > > --- a/drivers/firmware/arm_scmi/bus.c
> > > +++ b/drivers/firmware/arm_scmi/bus.c
> > > @@ -20,7 +20,6 @@
> > > BLOCKING_NOTIFIER_HEAD(scmi_requested_devices_nh);
> > > EXPORT_SYMBOL_GPL(scmi_requested_devices_nh);
> > >
> > > -static DEFINE_IDA(scmi_bus_id);
> > >
> > > static DEFINE_IDR(scmi_requested_devices);
> > > /* Protect access to scmi_requested_devices */
> > > @@ -341,7 +340,6 @@ static void __scmi_device_destroy(struct scmi_device *scmi_dev)
> > > if (scmi_dev->protocol_id == SCMI_PROTOCOL_SYSTEM)
> > > atomic_set(&scmi_syspower_registered, 0);
> > >
> > > - ida_free(&scmi_bus_id, scmi_dev->id);
> > > device_unregister(&scmi_dev->dev);
> > > }
> > >
> > > @@ -349,7 +347,7 @@ static struct scmi_device *
> > > __scmi_device_create(struct device_node *np, struct device *parent,
> > > int protocol, const char *name)
> > > {
> > > - int id, retval;
> > > + int retval;
> > > struct scmi_device *scmi_dev;
> > >
> > > /*
> > > @@ -387,20 +385,13 @@ __scmi_device_create(struct device_node *np, struct device *parent,
> > > return NULL;
> > > }
> > >
> > > - id = ida_alloc_min(&scmi_bus_id, 1, GFP_KERNEL);
> > > - if (id < 0) {
> > > - kfree_const(scmi_dev->name);
> > > - kfree(scmi_dev);
> > > - return NULL;
> > > - }
> > > -
> > > - scmi_dev->id = id;
> > > scmi_dev->protocol_id = protocol;
> > > scmi_dev->dev.parent = parent;
> > > device_set_node(&scmi_dev->dev, of_fwnode_handle(np));
> > > scmi_dev->dev.bus = &scmi_bus_type;
> > > scmi_dev->dev.release = scmi_device_release;
> > > - dev_set_name(&scmi_dev->dev, "scmi_dev.%d", id);
> > > + dev_set_name(&scmi_dev->dev, "scmi_dev.%s.%s.%d", dev_name(parent),
> > > + scmi_dev->name, protocol);
> > >
>
> So now you are using the parent top node SCMI device to create a unique
> device...and it probably endup in a name like:
>
> scmi-dev.arm-scmi.0.auto.genpd.13
>
> scmi-dev.arm-scmi.1.auto.genpd.13
>
> ...that certainly is more readable but is bulky and anyway giving unique
> IDs to devices is pretty common and you lookup which device is which by
> simply looking at the drivers/ link....not suure what's the benefit of
> all of this...just to avoid an IDA table ?
>
> > > retval = device_register(&scmi_dev->dev);
> > > if (retval)
> > > @@ -413,7 +404,6 @@ __scmi_device_create(struct device_node *np, struct device *parent,
> > > return scmi_dev;
> > > put_dev:
> > > put_device(&scmi_dev->dev);
> > > - ida_free(&scmi_bus_id, id);
> > > return NULL;
> > > }
> > >
> > > @@ -526,7 +516,6 @@ static void __exit scmi_bus_exit(void)
> > > */
> > > scmi_devices_unregister();
> > > bus_unregister(&scmi_bus_type);
> > > - ida_destroy(&scmi_bus_id);
> > > }
> > > module_exit(scmi_bus_exit);
> > >
> > > diff --git a/drivers/firmware/arm_scmi/driver.c b/drivers/firmware/arm_scmi/driver.c
> > > index 1b5fb2c4ce86..bbf1f05f2be3 100644
> > > --- a/drivers/firmware/arm_scmi/driver.c
> > > +++ b/drivers/firmware/arm_scmi/driver.c
> > > @@ -2641,8 +2641,8 @@ static int scmi_chan_setup(struct scmi_info *info, struct device_node *of_node,
> > > cinfo->max_msg_size = info->desc->max_msg_size;
> > >
> > > /* Create a unique name for this transport device */
> > > - snprintf(name, 32, "__scmi_transport_device_%s_%02X",
> > > - idx ? "rx" : "tx", prot_id);
> > > + snprintf(name, 32, "__scmi_transport_device_%s",
> > > + idx ? "rx" : "tx");
>
> I agree on what Dan said AND also this results in having the same name for different
> devices across 2 instances if you have a per-protocol channel because you havent anymore
> the protocol_id bit.
hi Cristian,and dan
Because I used a 3-tuple [parent name, name, protocol] when
creating the SCMI device name, I removed the prot_id from the
parameter ‘name’ when creating transport devices. This way, it avoids
the repetition of protocol ID in the SCMI device name.
> All in all, I would drop this patch and keep naming as it is because I dont see a real benefit
> here....up to Sudeep decide.
Yes, it does not have real benefits, but from the perspective of
the device name, this change will be clearer and more meaningful. And
the code is more concise.
Thanks
guomin.chen
>
> Thanks,
> Cristian
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [PATCH v2] firmware: arm_scmi: Delete the meaningless scmi_bus_id.
2024-12-16 10:37 ` gchen chen
@ 2024-12-16 10:45 ` Sudeep Holla
2024-12-16 14:10 ` gchen chen
2024-12-16 15:03 ` Dan Carpenter
1 sibling, 1 reply; 10+ messages in thread
From: Sudeep Holla @ 2024-12-16 10:45 UTC (permalink / raw)
To: gchen chen
Cc: Cristian Marussi, guomin_chen, Xinqi Zhang, arm-scmi,
Sudeep Holla, linux-arm-kernel, dan.carpenter
On Mon, Dec 16, 2024 at 06:37:01PM +0800, gchen chen wrote:
> Cristian Marussi <cristian.marussi@arm.com> 于2024年12月16日周一 17:45写道:
> >
> > On Mon, Dec 16, 2024 at 08:50:26AM +0000, Cristian Marussi wrote:
> > > On Mon, Dec 16, 2024 at 03:37:45PM +0800, guomin_chen@sina.com wrote:
> > > > From: guomin chen <guomin_chen@sina.com>
> > > >
> > > > Currently, scmi_bus_id is only used to set scmi_dev.id,
> > > > which in turn sets the SCMI device name. After removing
> > > > scmi_bus_id, it is clearer and more meaningful to directly
> > > > use the unique tuple [Parent name,device name, protocol] to
> > > > set the SCMI device name.
> > > >
> > >
> > > Hi Guomin,
> > >
> > > this same pTCH was NACKed(Rejected) a few days ago:
> > >
> > > https://lore.kernel.org/arm-scmi/20241211134505.2218386-1-guomin_chen@sina.com/T/#u
> > >
> > > ...and you agreed that is not a simplification we can do (not to break
> > > multuple instances...)...
> > >
> > > ..so why you are posting V2 now ?
> >
> > Wait...you changed slightly this indeed....you are using dev_parent...my
> > bad...but please when you post new version of a patch add a summary of
> > changes between versions...
> >
> > >
> > > Thanks,
> > > Cristian
> > >
> > > > Signed-off-by: guomin chen <guomin_chen@sina.com>
> > > > ---
> > > > drivers/firmware/arm_scmi/bus.c | 17 +++--------------
> > > > drivers/firmware/arm_scmi/driver.c | 4 ++--
> > > > 2 files changed, 5 insertions(+), 16 deletions(-)
> > > >
> > > > diff --git a/drivers/firmware/arm_scmi/bus.c b/drivers/firmware/arm_scmi/bus.c
> > > > index 157172a5f2b5..800e8ec9357c 100644
> > > > --- a/drivers/firmware/arm_scmi/bus.c
> > > > +++ b/drivers/firmware/arm_scmi/bus.c
> > > > @@ -20,7 +20,6 @@
> > > > BLOCKING_NOTIFIER_HEAD(scmi_requested_devices_nh);
> > > > EXPORT_SYMBOL_GPL(scmi_requested_devices_nh);
> > > >
> > > > -static DEFINE_IDA(scmi_bus_id);
> > > >
> > > > static DEFINE_IDR(scmi_requested_devices);
> > > > /* Protect access to scmi_requested_devices */
> > > > @@ -341,7 +340,6 @@ static void __scmi_device_destroy(struct scmi_device *scmi_dev)
> > > > if (scmi_dev->protocol_id == SCMI_PROTOCOL_SYSTEM)
> > > > atomic_set(&scmi_syspower_registered, 0);
> > > >
> > > > - ida_free(&scmi_bus_id, scmi_dev->id);
> > > > device_unregister(&scmi_dev->dev);
> > > > }
> > > >
> > > > @@ -349,7 +347,7 @@ static struct scmi_device *
> > > > __scmi_device_create(struct device_node *np, struct device *parent,
> > > > int protocol, const char *name)
> > > > {
> > > > - int id, retval;
> > > > + int retval;
> > > > struct scmi_device *scmi_dev;
> > > >
> > > > /*
> > > > @@ -387,20 +385,13 @@ __scmi_device_create(struct device_node *np, struct device *parent,
> > > > return NULL;
> > > > }
> > > >
> > > > - id = ida_alloc_min(&scmi_bus_id, 1, GFP_KERNEL);
> > > > - if (id < 0) {
> > > > - kfree_const(scmi_dev->name);
> > > > - kfree(scmi_dev);
> > > > - return NULL;
> > > > - }
> > > > -
> > > > - scmi_dev->id = id;
> > > > scmi_dev->protocol_id = protocol;
> > > > scmi_dev->dev.parent = parent;
> > > > device_set_node(&scmi_dev->dev, of_fwnode_handle(np));
> > > > scmi_dev->dev.bus = &scmi_bus_type;
> > > > scmi_dev->dev.release = scmi_device_release;
> > > > - dev_set_name(&scmi_dev->dev, "scmi_dev.%d", id);
> > > > + dev_set_name(&scmi_dev->dev, "scmi_dev.%s.%s.%d", dev_name(parent),
> > > > + scmi_dev->name, protocol);
> > > >
> >
> > So now you are using the parent top node SCMI device to create a unique
> > device...and it probably endup in a name like:
> >
> > scmi-dev.arm-scmi.0.auto.genpd.13
> >
> > scmi-dev.arm-scmi.1.auto.genpd.13
> >
> > ...that certainly is more readable but is bulky and anyway giving unique
> > IDs to devices is pretty common and you lookup which device is which by
> > simply looking at the drivers/ link....not suure what's the benefit of
> > all of this...just to avoid an IDA table ?
> >
> > > > retval = device_register(&scmi_dev->dev);
> > > > if (retval)
> > > > @@ -413,7 +404,6 @@ __scmi_device_create(struct device_node *np, struct device *parent,
> > > > return scmi_dev;
> > > > put_dev:
> > > > put_device(&scmi_dev->dev);
> > > > - ida_free(&scmi_bus_id, id);
> > > > return NULL;
> > > > }
> > > >
> > > > @@ -526,7 +516,6 @@ static void __exit scmi_bus_exit(void)
> > > > */
> > > > scmi_devices_unregister();
> > > > bus_unregister(&scmi_bus_type);
> > > > - ida_destroy(&scmi_bus_id);
> > > > }
> > > > module_exit(scmi_bus_exit);
> > > >
> > > > diff --git a/drivers/firmware/arm_scmi/driver.c b/drivers/firmware/arm_scmi/driver.c
> > > > index 1b5fb2c4ce86..bbf1f05f2be3 100644
> > > > --- a/drivers/firmware/arm_scmi/driver.c
> > > > +++ b/drivers/firmware/arm_scmi/driver.c
> > > > @@ -2641,8 +2641,8 @@ static int scmi_chan_setup(struct scmi_info *info, struct device_node *of_node,
> > > > cinfo->max_msg_size = info->desc->max_msg_size;
> > > >
> > > > /* Create a unique name for this transport device */
> > > > - snprintf(name, 32, "__scmi_transport_device_%s_%02X",
> > > > - idx ? "rx" : "tx", prot_id);
> > > > + snprintf(name, 32, "__scmi_transport_device_%s",
> > > > + idx ? "rx" : "tx");
> >
> > I agree on what Dan said AND also this results in having the same name for different
> > devices across 2 instances if you have a per-protocol channel because you havent anymore
> > the protocol_id bit.
> hi Cristian,and dan
> Because I used a 3-tuple [parent name, name, protocol] when
> creating the SCMI device name, I removed the prot_id from the
> parameter ‘name’ when creating transport devices. This way, it avoids
> the repetition of protocol ID in the SCMI device name.
>
> > All in all, I would drop this patch and keep naming as it is because I dont see a real benefit
> > here....up to Sudeep decide.
> Yes, it does not have real benefits, but from the perspective of
> the device name, this change will be clearer and more meaningful. And
> the code is more concise.
>
I would like to understand the motivation behind this change. What is the
goal ? Do you prefer to fetch the name and protocol id from the device
name itself ? Is that your requirement.
From the commit log, I get a sense that you looked at the code and thought
of possible improvement but when we mentioned the limitation you just
improvised by adding parent name. Do you expect any userspace to parse
the name as that will end up being ABI and we can't break it. I need
real motive to be explained here in detail.
--
Regards,
Sudeep
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [PATCH v2] firmware: arm_scmi: Delete the meaningless scmi_bus_id.
2024-12-16 10:45 ` Sudeep Holla
@ 2024-12-16 14:10 ` gchen chen
2024-12-16 16:08 ` Sudeep Holla
0 siblings, 1 reply; 10+ messages in thread
From: gchen chen @ 2024-12-16 14:10 UTC (permalink / raw)
To: Sudeep Holla
Cc: Cristian Marussi, guomin_chen, Xinqi Zhang, arm-scmi,
linux-arm-kernel, dan.carpenter
Sudeep Holla <sudeep.holla@arm.com> 于2024年12月16日周一 18:45写道:
>
> On Mon, Dec 16, 2024 at 06:37:01PM +0800, gchen chen wrote:
> > Cristian Marussi <cristian.marussi@arm.com> 于2024年12月16日周一 17:45写道:
> > >
> > > On Mon, Dec 16, 2024 at 08:50:26AM +0000, Cristian Marussi wrote:
> > > > On Mon, Dec 16, 2024 at 03:37:45PM +0800, guomin_chen@sina.com wrote:
> > > > > From: guomin chen <guomin_chen@sina.com>
> > > > >
> > > > > Currently, scmi_bus_id is only used to set scmi_dev.id,
> > > > > which in turn sets the SCMI device name. After removing
> > > > > scmi_bus_id, it is clearer and more meaningful to directly
> > > > > use the unique tuple [Parent name,device name, protocol] to
> > > > > set the SCMI device name.
> > > > >
> > > >
> > > > Hi Guomin,
> > > >
> > > > this same pTCH was NACKed(Rejected) a few days ago:
> > > >
> > > > https://lore.kernel.org/arm-scmi/20241211134505.2218386-1-guomin_chen@sina.com/T/#u
> > > >
> > > > ...and you agreed that is not a simplification we can do (not to break
> > > > multuple instances...)...
> > > >
> > > > ..so why you are posting V2 now ?
> > >
> > > Wait...you changed slightly this indeed....you are using dev_parent...my
> > > bad...but please when you post new version of a patch add a summary of
> > > changes between versions...
> > >
> > > >
> > > > Thanks,
> > > > Cristian
> > > >
> > > > > Signed-off-by: guomin chen <guomin_chen@sina.com>
> > > > > ---
> > > > > drivers/firmware/arm_scmi/bus.c | 17 +++--------------
> > > > > drivers/firmware/arm_scmi/driver.c | 4 ++--
> > > > > 2 files changed, 5 insertions(+), 16 deletions(-)
> > > > >
> > > > > diff --git a/drivers/firmware/arm_scmi/bus.c b/drivers/firmware/arm_scmi/bus.c
> > > > > index 157172a5f2b5..800e8ec9357c 100644
> > > > > --- a/drivers/firmware/arm_scmi/bus.c
> > > > > +++ b/drivers/firmware/arm_scmi/bus.c
> > > > > @@ -20,7 +20,6 @@
> > > > > BLOCKING_NOTIFIER_HEAD(scmi_requested_devices_nh);
> > > > > EXPORT_SYMBOL_GPL(scmi_requested_devices_nh);
> > > > >
> > > > > -static DEFINE_IDA(scmi_bus_id);
> > > > >
> > > > > static DEFINE_IDR(scmi_requested_devices);
> > > > > /* Protect access to scmi_requested_devices */
> > > > > @@ -341,7 +340,6 @@ static void __scmi_device_destroy(struct scmi_device *scmi_dev)
> > > > > if (scmi_dev->protocol_id == SCMI_PROTOCOL_SYSTEM)
> > > > > atomic_set(&scmi_syspower_registered, 0);
> > > > >
> > > > > - ida_free(&scmi_bus_id, scmi_dev->id);
> > > > > device_unregister(&scmi_dev->dev);
> > > > > }
> > > > >
> > > > > @@ -349,7 +347,7 @@ static struct scmi_device *
> > > > > __scmi_device_create(struct device_node *np, struct device *parent,
> > > > > int protocol, const char *name)
> > > > > {
> > > > > - int id, retval;
> > > > > + int retval;
> > > > > struct scmi_device *scmi_dev;
> > > > >
> > > > > /*
> > > > > @@ -387,20 +385,13 @@ __scmi_device_create(struct device_node *np, struct device *parent,
> > > > > return NULL;
> > > > > }
> > > > >
> > > > > - id = ida_alloc_min(&scmi_bus_id, 1, GFP_KERNEL);
> > > > > - if (id < 0) {
> > > > > - kfree_const(scmi_dev->name);
> > > > > - kfree(scmi_dev);
> > > > > - return NULL;
> > > > > - }
> > > > > -
> > > > > - scmi_dev->id = id;
> > > > > scmi_dev->protocol_id = protocol;
> > > > > scmi_dev->dev.parent = parent;
> > > > > device_set_node(&scmi_dev->dev, of_fwnode_handle(np));
> > > > > scmi_dev->dev.bus = &scmi_bus_type;
> > > > > scmi_dev->dev.release = scmi_device_release;
> > > > > - dev_set_name(&scmi_dev->dev, "scmi_dev.%d", id);
> > > > > + dev_set_name(&scmi_dev->dev, "scmi_dev.%s.%s.%d", dev_name(parent),
> > > > > + scmi_dev->name, protocol);
> > > > >
> > >
> > > So now you are using the parent top node SCMI device to create a unique
> > > device...and it probably endup in a name like:
> > >
> > > scmi-dev.arm-scmi.0.auto.genpd.13
> > >
> > > scmi-dev.arm-scmi.1.auto.genpd.13
> > >
> > > ...that certainly is more readable but is bulky and anyway giving unique
> > > IDs to devices is pretty common and you lookup which device is which by
> > > simply looking at the drivers/ link....not suure what's the benefit of
> > > all of this...just to avoid an IDA table ?
> > >
> > > > > retval = device_register(&scmi_dev->dev);
> > > > > if (retval)
> > > > > @@ -413,7 +404,6 @@ __scmi_device_create(struct device_node *np, struct device *parent,
> > > > > return scmi_dev;
> > > > > put_dev:
> > > > > put_device(&scmi_dev->dev);
> > > > > - ida_free(&scmi_bus_id, id);
> > > > > return NULL;
> > > > > }
> > > > >
> > > > > @@ -526,7 +516,6 @@ static void __exit scmi_bus_exit(void)
> > > > > */
> > > > > scmi_devices_unregister();
> > > > > bus_unregister(&scmi_bus_type);
> > > > > - ida_destroy(&scmi_bus_id);
> > > > > }
> > > > > module_exit(scmi_bus_exit);
> > > > >
> > > > > diff --git a/drivers/firmware/arm_scmi/driver.c b/drivers/firmware/arm_scmi/driver.c
> > > > > index 1b5fb2c4ce86..bbf1f05f2be3 100644
> > > > > --- a/drivers/firmware/arm_scmi/driver.c
> > > > > +++ b/drivers/firmware/arm_scmi/driver.c
> > > > > @@ -2641,8 +2641,8 @@ static int scmi_chan_setup(struct scmi_info *info, struct device_node *of_node,
> > > > > cinfo->max_msg_size = info->desc->max_msg_size;
> > > > >
> > > > > /* Create a unique name for this transport device */
> > > > > - snprintf(name, 32, "__scmi_transport_device_%s_%02X",
> > > > > - idx ? "rx" : "tx", prot_id);
> > > > > + snprintf(name, 32, "__scmi_transport_device_%s",
> > > > > + idx ? "rx" : "tx");
> > >
> > > I agree on what Dan said AND also this results in having the same name for different
> > > devices across 2 instances if you have a per-protocol channel because you havent anymore
> > > the protocol_id bit.
> > hi Cristian,and dan
> > Because I used a 3-tuple [parent name, name, protocol] when
> > creating the SCMI device name, I removed the prot_id from the
> > parameter ‘name’ when creating transport devices. This way, it avoids
> > the repetition of protocol ID in the SCMI device name.
> >
> > > All in all, I would drop this patch and keep naming as it is because I dont see a real benefit
> > > here....up to Sudeep decide.
> > Yes, it does not have real benefits, but from the perspective of
> > the device name, this change will be clearer and more meaningful. And
> > the code is more concise.
> >
>
> I would like to understand the motivation behind this change. What is the
> goal ? Do you prefer to fetch the name and protocol id from the device
> name itself ? Is that your requirement.
>
hi Sudeep
Okay, the reason I want to change names like 'scmi_dev.3' to
'scmi_dev.firmware:scmi.perf.19' is because when I was migrating the
SOC's kernel from v6.1 to v6.6, I found that the context for creating
SCMI devices had changed (commit d3cd7c525fd2: firmware: arm_scmi:
Refactor protocol device creation). This change meant that device
creation shifted from being directly created through
scmi_protocol_device_request during SCMI driver registration to being
created via scmi_device_request_notifier. This shift results in
changes to the order in which devices are created, causing the ID in
scmi_dev.id to drift.
Additionally, I encountered some cpufreq errors here—because both
scmi_cpufreq_drv and scmi_perf_domain_driver use the same
SCMI_PROTOCOL_PERF, this results in two SCMI devices corresponding to
the same device node. However, device_node.fwnode.dev only points to
the first registered scmi_device, causing other consumer devices to
find the wrong scmi device as the supplier. So I would find a
multitude of other consumer devices waiting for meaningless device
names like "scmi_dev.4" instead of meaningful names such as
"scmi_dev.firmware:scmi.perf.19" or
"scmi_dev.firmware:scmi.cpufreq.19".
Although I could further determine which specific driver it was by
looking at the driver links under the scmi_protocol bus directory, I
thought that if the logs directly displayed device names like
'scmi_dev.firmware:scmi.perf.19' instead of meaningless progressive
IDs, it would be more convenient and logical, and thus more
meaningful.
> From the commit log, I get a sense that you looked at the code and thought
> of possible improvement but when we mentioned the limitation you just
> improvised by adding parent name. Do you expect any userspace to parse
> the name as that will end up being ABI and we can't break it. I need
> real motive to be explained here in detail.
>
I did not use userspace tools to parse this SCMI device name; I simply
wanted the name to reflect the possible logic of the device.
I did not remove scmi_dev.id (This scmi_device structure has not
changed.); I just no longer assign values to it using scmi_bus_id, so
it should not affect the kernel ABI (kABI).
Thanks
guomin.chen
> --
> Regards,
> Sudeep
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [PATCH v2] firmware: arm_scmi: Delete the meaningless scmi_bus_id.
2024-12-16 10:37 ` gchen chen
2024-12-16 10:45 ` Sudeep Holla
@ 2024-12-16 15:03 ` Dan Carpenter
1 sibling, 0 replies; 10+ messages in thread
From: Dan Carpenter @ 2024-12-16 15:03 UTC (permalink / raw)
To: gchen chen
Cc: Cristian Marussi, guomin_chen, Sudeep Holla, Xinqi Zhang,
arm-scmi, linux-arm-kernel
On Mon, Dec 16, 2024 at 06:37:01PM +0800, gchen chen wrote:
> > > > diff --git a/drivers/firmware/arm_scmi/driver.c b/drivers/firmware/arm_scmi/driver.c
> > > > index 1b5fb2c4ce86..bbf1f05f2be3 100644
> > > > --- a/drivers/firmware/arm_scmi/driver.c
> > > > +++ b/drivers/firmware/arm_scmi/driver.c
> > > > @@ -2641,8 +2641,8 @@ static int scmi_chan_setup(struct scmi_info *info, struct device_node *of_node,
> > > > cinfo->max_msg_size = info->desc->max_msg_size;
> > > >
> > > > /* Create a unique name for this transport device */
> > > > - snprintf(name, 32, "__scmi_transport_device_%s_%02X",
> > > > - idx ? "rx" : "tx", prot_id);
> > > > + snprintf(name, 32, "__scmi_transport_device_%s",
> > > > + idx ? "rx" : "tx");
> >
> > I agree on what Dan said AND also this results in having the same name for different
> > devices across 2 instances if you have a per-protocol channel because you havent anymore
> > the protocol_id bit.
> hi Cristian,and dan
> Because I used a 3-tuple [parent name, name, protocol] when
> creating the SCMI device name, I removed the prot_id from the
> parameter ‘name’ when creating transport devices. This way, it avoids
> the repetition of protocol ID in the SCMI device name.
>
I haven't actually tested this code, I'm just going by reviewing.
scmi_channels_setup() calls scmi_txrx_setup() in a loop with a different
port_id each time. The info->dev is the same on each iteration. Since
the name is the same except for the rx/tx then __scmi_device_create() will
find the existing device on the first line and return success instead of
allocating a new device:
scmi_dev = scmi_child_dev_find(parent, protocol, name);
if (scmi_dev)
return scmi_dev;
regards,
dan carpenter
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [PATCH v2] firmware: arm_scmi: Delete the meaningless scmi_bus_id.
2024-12-16 14:10 ` gchen chen
@ 2024-12-16 16:08 ` Sudeep Holla
2024-12-17 2:06 ` gchen chen
0 siblings, 1 reply; 10+ messages in thread
From: Sudeep Holla @ 2024-12-16 16:08 UTC (permalink / raw)
To: gchen chen
Cc: Cristian Marussi, guomin_chen, Sudeep Holla, Xinqi Zhang,
arm-scmi, linux-arm-kernel, dan.carpenter
On Mon, Dec 16, 2024 at 10:10:40PM +0800, gchen chen wrote:
> Sudeep Holla <sudeep.holla@arm.com> 于2024年12月16日周一 18:45写道:
[...]
> >
> > I would like to understand the motivation behind this change. What is the
> > goal ? Do you prefer to fetch the name and protocol id from the device
> > name itself ? Is that your requirement.
> >
> hi Sudeep
> Okay, the reason I want to change names like 'scmi_dev.3' to
> 'scmi_dev.firmware:scmi.perf.19' is because when I was migrating the
> SOC's kernel from v6.1 to v6.6, I found that the context for creating
> SCMI devices had changed (commit d3cd7c525fd2: firmware: arm_scmi:
> Refactor protocol device creation).
Correct. That's the beauty of Linux we can adjust the internals to enhance
the features without breaking the user-space.
> This change meant that device creation shifted from being directly
> created through scmi_protocol_device_request during SCMI driver
> registration to being created via scmi_device_request_notifier.
> This shift results in changes to the order in which devices are created,
> causing the ID in scmi_dev.id to drift.
>
What issue does this drift cause exactly ? I mean the order in which
the devices are created should not impact on anything if the dependency
on the order was not created. What was that dependency ?
> Additionally, I encountered some cpufreq errors here—because both
> scmi_cpufreq_drv and scmi_perf_domain_driver use the same
> SCMI_PROTOCOL_PERF, this results in two SCMI devices corresponding to
> the same device node. However, device_node.fwnode.dev only points to
> the first registered scmi_device, causing other consumer devices to
> find the wrong scmi device as the supplier. So I would find a
> multitude of other consumer devices waiting for meaningless device
> names like "scmi_dev.4" instead of meaningful names such as
> "scmi_dev.firmware:scmi.perf.19" or
> "scmi_dev.firmware:scmi.cpufreq.19".
>
Yes this was reported. I think most of the std protocol may not use that
node and need not be assigned. But I think vendor extensions are adding
info to the DT that may need this.
> Although I could further determine which specific driver it was by
> looking at the driver links under the scmi_protocol bus directory, I
> thought that if the logs directly displayed device names like
> 'scmi_dev.firmware:scmi.perf.19' instead of meaningless progressive
> IDs, it would be more convenient and logical, and thus more
> meaningful.
>
If the issue you encountered render your platform into boot issues ?
If so I would like to know what exactly happened. If not, I can think of
alternate solution if possible.
> > From the commit log, I get a sense that you looked at the code and thought
> > of possible improvement but when we mentioned the limitation you just
> > improvised by adding parent name. Do you expect any userspace to parse
> > the name as that will end up being ABI and we can't break it. I need
> > real motive to be explained here in detail.
> >
> I did not use userspace tools to parse this SCMI device name; I simply
> wanted the name to reflect the possible logic of the device.
> I did not remove scmi_dev.id (This scmi_device structure has not
> changed.); I just no longer assign values to it using scmi_bus_id, so
> it should not affect the kernel ABI (kABI).
I understand the change, just not the possible impact w.r.t user-space.
--
Regards,
Sudeep
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [PATCH v2] firmware: arm_scmi: Delete the meaningless scmi_bus_id.
2024-12-16 16:08 ` Sudeep Holla
@ 2024-12-17 2:06 ` gchen chen
0 siblings, 0 replies; 10+ messages in thread
From: gchen chen @ 2024-12-17 2:06 UTC (permalink / raw)
To: Sudeep Holla
Cc: Cristian Marussi, guomin_chen, Xinqi Zhang, arm-scmi,
linux-arm-kernel, dan.carpenter
Sudeep Holla <sudeep.holla@arm.com> 于2024年12月17日周二 00:08写道:
>
> On Mon, Dec 16, 2024 at 10:10:40PM +0800, gchen chen wrote:
> > Sudeep Holla <sudeep.holla@arm.com> 于2024年12月16日周一 18:45写道:
>
> [...]
>
> > >
> > > I would like to understand the motivation behind this change. What is the
> > > goal ? Do you prefer to fetch the name and protocol id from the device
> > > name itself ? Is that your requirement.
> > >
> > hi Sudeep
> > Okay, the reason I want to change names like 'scmi_dev.3' to
> > 'scmi_dev.firmware:scmi.perf.19' is because when I was migrating the
> > SOC's kernel from v6.1 to v6.6, I found that the context for creating
> > SCMI devices had changed (commit d3cd7c525fd2: firmware: arm_scmi:
> > Refactor protocol device creation).
>
> Correct. That's the beauty of Linux we can adjust the internals to enhance
> the features without breaking the user-space.
>
> > This change meant that device creation shifted from being directly
> > created through scmi_protocol_device_request during SCMI driver
> > registration to being created via scmi_device_request_notifier.
> > This shift results in changes to the order in which devices are created,
> > causing the ID in scmi_dev.id to drift.
> >
>
> What issue does this drift cause exactly ? I mean the order in which
> the devices are created should not impact on anything if the dependency
> on the order was not created. What was that dependency ?
>
Yes, my issue is that the loading order of the scmi_cpufreq_drv and
scmi_perf_domain_driver drivers causes other consumer devices to find
the wrong SCMI device as the supplier. Since both the scmi_cpufreq_drv
and scmi_perf_domain_driver drivers use the same device node (the same
SCMI_PROTOCOL_PERF), device_node.fwnode.dev will only point to the
SCMI device that was registered first.
Thanks
> > Additionally, I encountered some cpufreq errors here—because both
> > scmi_cpufreq_drv and scmi_perf_domain_driver use the same
> > SCMI_PROTOCOL_PERF, this results in two SCMI devices corresponding to
> > the same device node. However, device_node.fwnode.dev only points to
> > the first registered scmi_device, causing other consumer devices to
> > find the wrong scmi device as the supplier. So I would find a
> > multitude of other consumer devices waiting for meaningless device
> > names like "scmi_dev.4" instead of meaningful names such as
> > "scmi_dev.firmware:scmi.perf.19" or
> > "scmi_dev.firmware:scmi.cpufreq.19".
> >
>
> Yes this was reported. I think most of the std protocol may not use that
> node and need not be assigned. But I think vendor extensions are adding
> info to the DT that may need this.
>
> > Although I could further determine which specific driver it was by
> > looking at the driver links under the scmi_protocol bus directory, I
> > thought that if the logs directly displayed device names like
> > 'scmi_dev.firmware:scmi.perf.19' instead of meaningless progressive
> > IDs, it would be more convenient and logical, and thus more
> > meaningful.
> >
>
> If the issue you encountered render your platform into boot issues ?
> If so I would like to know what exactly happened. If not, I can think of
> alternate solution if possible.
>
> > > From the commit log, I get a sense that you looked at the code and thought
> > > of possible improvement but when we mentioned the limitation you just
> > > improvised by adding parent name. Do you expect any userspace to parse
> > > the name as that will end up being ABI and we can't break it. I need
> > > real motive to be explained here in detail.
> > >
> > I did not use userspace tools to parse this SCMI device name; I simply
> > wanted the name to reflect the possible logic of the device.
> > I did not remove scmi_dev.id (This scmi_device structure has not
> > changed.); I just no longer assign values to it using scmi_bus_id, so
> > it should not affect the kernel ABI (kABI).
>
> I understand the change, just not the possible impact w.r.t user-space.
>
> --
> Regards,
> Sudeep
^ permalink raw reply [flat|nested] 10+ messages in thread
end of thread, other threads:[~2024-12-17 2:08 UTC | newest]
Thread overview: 10+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2024-12-16 7:37 [PATCH v2] firmware: arm_scmi: Delete the meaningless scmi_bus_id guomin_chen
2024-12-16 8:31 ` Dan Carpenter
2024-12-16 8:50 ` Cristian Marussi
2024-12-16 9:45 ` Cristian Marussi
2024-12-16 10:37 ` gchen chen
2024-12-16 10:45 ` Sudeep Holla
2024-12-16 14:10 ` gchen chen
2024-12-16 16:08 ` Sudeep Holla
2024-12-17 2:06 ` gchen chen
2024-12-16 15:03 ` Dan Carpenter
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).