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

[Sudeep Holla <sudeep.holla@arm.com>]

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