[PATCH] firmware: arm_scmi: Delete the meaningless scmi_bus_id.

[gchen chen]

Cristian Marussi <cristian.marussi at arm.com> 于2024年12月12日周四 02:28写道：
>
> On Wed, Dec 11, 2024 at 09:45:05PM +0800, guomin_chen at sina.com wrote:
> > From: guomin chen <guomin_chen at 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 at 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.

Okay, it is true that if two SCMI instances are defined in DT using
the same protocol,
it will result in devices with the same name. Thank you for pointing this out!

Thanks

> 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