linux-arm-kernel.lists.infradead.org archive mirror
 help / color / mirror / Atom feed
From: Cristian Marussi <cristian.marussi@arm.com>
To: guomin_chen@sina.com
Cc: Sudeep Holla <sudeep.holla@arm.com>,
	Cristian Marussi <cristian.marussi@arm.com>,
	Xinqi Zhang <quic_xinqzhan@quicinc.com>,
	guomin chen <gchen.guomin@gmail.com>,
	arm-scmi@vger.kernel.org, linux-arm-kernel@lists.infradead.org,
	dan.carpenter@linaro.org
Subject: Re: [PATCH v2] firmware: arm_scmi: Delete the meaningless scmi_bus_id.
Date: Mon, 16 Dec 2024 09:45:19 +0000	[thread overview]
Message-ID: <Z1_2rxJ7TOEIOMp7@pluto> (raw)
In-Reply-To: <Z1_p0nU93PHJ4Sg_@pluto>

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


  reply	other threads:[~2024-12-16  9:47 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
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 [this message]
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

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=Z1_2rxJ7TOEIOMp7@pluto \
    --to=cristian.marussi@arm.com \
    --cc=arm-scmi@vger.kernel.org \
    --cc=dan.carpenter@linaro.org \
    --cc=gchen.guomin@gmail.com \
    --cc=guomin_chen@sina.com \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=quic_xinqzhan@quicinc.com \
    --cc=sudeep.holla@arm.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
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).