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
Subject: Re: [PATCH] firmware: arm_scmi: Delete the meaningless scmi_bus_id.
Date: Wed, 11 Dec 2024 18:28:43 +0000 [thread overview]
Message-ID: <Z1nZPmB7nW7HUdYL@pluto> (raw)
In-Reply-To: <20241211134505.2218386-1-guomin_chen@sina.com_quarantine>
On Wed, Dec 11, 2024 at 09:45:05PM +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 input parameters name and protocol to set the SCMI
> device name.
Hi,
even though using progressive IDs in devices is less readable, I agree,
we need ID in the name to keep the device unique.
It is true that we can have only one protocol/name unique pair amongst
the *requested* devices BUT it is also true that the SCMI stack as it
stands can be instantiated multiple times if you define multiple DT SCMI
top-nodes: this is already used in the wild to sort of represent
multiple virtual/physical SCMI Server backend (all anyway identified by
ID-0 as from the spec...)
So if you have defind in the DT 2 SCMI instance with both a protocol@15/HWMON,
as an example, the arm_scmi/driver.c will probe twice and it will try to
create 2 instances of 'requested' devices for 15/hwmon and both of these
will be attached to the same *unique* SCMI bus...so we need the uniqe ID
to differentiate them....same for the transport devices.
Sorry but NACK for me: regarding the readability, I could agree, but you
can anyway easily understand which device is which by looking at the
drivers/ links generated in the scmi_protocol bus directory.
Thanks,
Cristian
next parent reply other threads:[~2024-12-11 18:28 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <20241211134505.2218386-1-guomin_chen@sina.com_quarantine>
2024-12-11 18:28 ` Cristian Marussi [this message]
2024-12-12 2:12 ` [PATCH] firmware: arm_scmi: Delete the meaningless scmi_bus_id gchen chen
2024-12-11 13:45 guomin_chen
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=Z1nZPmB7nW7HUdYL@pluto \
--to=cristian.marussi@arm.com \
--cc=arm-scmi@vger.kernel.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.