Messages in this thread | | | Date | Wed, 14 Oct 2020 18:35:22 +0100 | From | Sudeep Holla <> | Subject | Re: [PATCH] firmware: arm_scmi: Fix duplicate workqueue name |
| |
On Wed, Oct 14, 2020 at 06:32:42PM +0100, Sudeep Holla wrote: > On Wed, Oct 14, 2020 at 10:08:32AM -0700, Florian Fainelli wrote: > > On 10/14/20 2:18 AM, Sudeep Holla wrote: > > > Hi Florian, > > > > > > Thanks for the patch, it shows someone else is also using this and > > > testing 😉. > > > > > > On Tue, Oct 13, 2020 at 07:17:37PM -0700, Florian Fainelli wrote: > > >> When more than a single SCMI device are present in the system, the > > >> creation of the notification workqueue with the WQ_SYSFS flag will lead > > >> to the following sysfs duplicate node warning: > > >> > > > > > > Please trim the calltrace next time without timestamp and register raw > > > hex values. > > > > Will do, thanks! > > > > Thanks! > > > > > > > You using this on 32-bit platform ? If so, thanks for additional test > > > coverage. > > > > We have a mix of ARMv7/LPAE (Brahma-B15) and ARMv8 (Brahma-B53, > > Cortex-A72) devices that we regularly test with 32-bit and 64-bit kernels. > > > > Ah OK, good to know. > > [...] > > > >> Fix this by using dev_name(handle->dev) which guarantees that the name is > > >> unique and this also helps correlate which notification workqueue corresponds > > >> to which SCMI device instance. > > >> > > > > > > I am curious as how multiple SCMI instances are used. We know few limitations > > > in the code to handle that yet, so interested to know if you are carrying > > > more patches/fixes. > > > > We currently have two SCMI device nodes in Device Tree: > > > > - the first one is responsible for all of the base, performance, sensors > > protocols and is present on all of the chips listed above > > > > - the second one is responsible for a proprietary protocol through which > > we encapsulate a variety of operations towards a secure agent in the > > system, this is only present in a subset of devices. > > > > And any particular reasons it can't exist in the same node. And also are > they talking to different SCMI firmware implementation meaning different > location in the system. The reason I ask is we have notion of one platform > with agent id = 0 as per the specification. It can be split in terms > of implementation and can have some side band communication amongst > themselves but can't have agent ID other than 0. It violates specification. > > I don't have issues split it into 2 or more SCMI device as long as it > doesn't provide notion of existence of multiple SCMI platform firmware > implementations with different agent ID. > > Also Cristian has posted patches to support custom protocols[1]. It would > be good if you can take a look/review/test/comment... >
Pressed enter too early, link added now.
-- Regards, Sudeep
[1] https://lore.kernel.org/lkml/20201014150545.44807-1-cristian.marussi@arm.com
| |