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

[gchen chen]

Sudeep Holla <sudeep.holla at arm.com> 于2024年12月17日周二 00:08写道：
>
> On Mon, Dec 16, 2024 at 10:10:40PM +0800, gchen chen wrote:
> > Sudeep Holla <sudeep.holla at 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