All of lore.kernel.org
 help / color / mirror / Atom feed
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

WARNING: multiple messages have this Message-ID (diff)
From: Sudeep Holla <sudeep.holla@arm.com>
To: Florian Fainelli <f.fainelli@gmail.com>
Cc: linux-arm-kernel@lists.infradead.org,
	Jonathan Cameron <Jonathan.Cameron@huawei.com>,
	Cristian Marussi <cristian.marussi@arm.com>,
	Sudeep Holla <sudeep.holla@arm.com>,
	linux-kernel@vger.kernel.org
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

  reply	other threads:[~2020-10-14 17:36 UTC|newest]

Thread overview: 24+ 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  2:17 ` Florian Fainelli
2020-10-14  9:18 ` Sudeep Holla
2020-10-14  9:18   ` Sudeep Holla
2020-10-14 13:05   ` Sudeep Holla
2020-10-14 13:05     ` Sudeep Holla
2020-10-14 13:48     ` Cristian Marussi
2020-10-14 13:48       ` Cristian Marussi
2020-10-14 16:18       ` Sudeep Holla
2020-10-14 16:18         ` Sudeep Holla
2020-10-14 17:13         ` Florian Fainelli
2020-10-14 17:13           ` Florian Fainelli
2020-10-14 17:39           ` Sudeep Holla
2020-10-14 17:39             ` Sudeep Holla
2020-10-14 18:11             ` Florian Fainelli
2020-10-14 18:11               ` Florian Fainelli
2020-10-14 17:08   ` Florian Fainelli
2020-10-14 17:08     ` Florian Fainelli
2020-10-14 17:32     ` Sudeep Holla
2020-10-14 17:32       ` Sudeep Holla
2020-10-14 17:35       ` Sudeep Holla [this message]
2020-10-14 17:35         ` Sudeep Holla
2020-10-14 20:29 ` Sudeep Holla
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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.