From: Sudeep Holla <sudeep.holla@arm.com>
To: Florian Fainelli <f.fainelli@gmail.com>
Cc: linux-kernel@vger.kernel.org, Sudeep Holla <sudeep.holla@arm.com>,
Cristian Marussi <cristian.marussi@arm.com>,
linux-arm-kernel@lists.infradead.org,
Jonathan Cameron <Jonathan.Cameron@huawei.com>
Subject: Re: [PATCH] firmware: arm_scmi: Fix duplicate workqueue name
Date: Wed, 14 Oct 2020 18:35:22 +0100 [thread overview]
Message-ID: <20201014173522.ugrdswnkrmrnmudv@bogus> (raw)
In-Reply-To: <20201014173109.dxi2asvkojkxdtwd@bogus>
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
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
next prev parent reply other threads:[~2020-10-14 17:36 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-10-14 2:17 [PATCH] firmware: arm_scmi: Fix duplicate workqueue name Florian Fainelli
2020-10-14 9:18 ` Sudeep Holla
2020-10-14 13:05 ` Sudeep Holla
2020-10-14 13:48 ` Cristian Marussi
2020-10-14 16:18 ` Sudeep Holla
2020-10-14 17:13 ` Florian Fainelli
2020-10-14 17:39 ` Sudeep Holla
2020-10-14 18:11 ` Florian Fainelli
2020-10-14 17:08 ` Florian Fainelli
2020-10-14 17:32 ` Sudeep Holla
2020-10-14 17:35 ` Sudeep Holla [this message]
2020-10-14 20:29 ` Sudeep Holla
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=20201014173522.ugrdswnkrmrnmudv@bogus \
--to=sudeep.holla@arm.com \
--cc=Jonathan.Cameron@huawei.com \
--cc=cristian.marussi@arm.com \
--cc=f.fainelli@gmail.com \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox