All of lore.kernel.org
 help / color / mirror / Atom feed
From: Cristian Marussi <cristian.marussi@arm.com>
To: Peter Hilber <peter.hilber@opensynergy.com>
Cc: linux-kernel@vger.kernel.org,
	linux-arm-kernel@lists.infradead.org,
	virtualization@lists.linux-foundation.org,
	virtio-dev@lists.oasis-open.org, sudeep.holla@arm.com,
	james.quinlan@broadcom.com, Jonathan.Cameron@Huawei.com,
	f.fainelli@gmail.com, etienne.carriere@linaro.org,
	vincent.guittot@linaro.org, souvik.chakravarty@arm.com,
	igor.skalkin@opensynergy.com, alex.bennee@linaro.org,
	jean-philippe@linaro.org, mikhail.golubev@opensynergy.com,
	anton.yakovlev@opensynergy.com, Vasyl.Vavrychuk@opensynergy.com,
	Andriy.Tryshnivskyy@opensynergy.com
Subject: Re: [PATCH v4 01/16] firmware: arm_scmi: Fix max pending messages boundary check
Date: Thu, 1 Jul 2021 11:04:19 +0100	[thread overview]
Message-ID: <20210701100258.GB50227@e120937-lin> (raw)
In-Reply-To: <cb24778e-60fd-4582-c855-238d71319067@opensynergy.com>

Hi Peter,

On Thu, Jul 01, 2021 at 10:42:40AM +0200, Peter Hilber wrote:
> Hi Cristian,
> 
> please find some remarks to the patch series in this email and the
> following.
> 

Thanks for your comments, very much appreciated. I'll reply inline.

Just to let you know, I have ready a V5 series where, beside some
general cleanup and further simplification, I addressed in the SCMI core
the issue that you pointed out about the possible concurrent and out-of-order
response/delayed_response delivery by the transport.

I've refrained from posting that on the list still, due to the merge window
being open. I'll post most probably next week. (still have to see if I
can also simplify probing sequence in V5...which is the last point in my
list)

> On 11.06.21 18:59, Cristian Marussi wrote:
> > SCMI message headers carry a sequence number and such field is sized to
> > allow for MSG_TOKEN_MAX distinct numbers; moreover zero is not really an
> > acceptable maximum number of pending in-flight messages.
> > 
> > Fix accordignly the checks performed on the value exported by transports
> > in scmi_desc.max_msg.
> > 
> > Reported-by: Vincent Guittot <vincent.guittot@linaro.org>
> > Fixes: aa4f886f3893 ("firmware: arm_scmi: add basic driver infrastructure for SCMI")
> > Signed-off-by: Cristian Marussi <cristian.marussi@arm.com>
> > ---
> >  drivers/firmware/arm_scmi/driver.c | 5 +++--
> >  1 file changed, 3 insertions(+), 2 deletions(-)
> > 
> > diff --git a/drivers/firmware/arm_scmi/driver.c b/drivers/firmware/arm_scmi/driver.c
> > index 66e5e694be7d..6713b259f1e6 100644
> > --- a/drivers/firmware/arm_scmi/driver.c
> > +++ b/drivers/firmware/arm_scmi/driver.c
> > @@ -1025,8 +1025,9 @@ static int __scmi_xfer_info_init(struct scmi_info *sinfo,
> >  	const struct scmi_desc *desc = sinfo->desc;
> >  	/* Pre-allocated messages, no more than what hdr.seq can support */
> > -	if (WARN_ON(desc->max_msg >= MSG_TOKEN_MAX)) {
> > -		dev_err(dev, "Maximum message of %d exceeds supported %ld\n",
> > +	if (WARN_ON(!desc->max_msg || desc->max_msg > MSG_TOKEN_MAX)) {
> > +		dev_err(dev,
> > +			"Invalid max_msg %d. Maximum messages supported %ld.\n",
> 
> %ld -> %lu
> 

Right, I'll fix.

> >  			desc->max_msg, MSG_TOKEN_MAX);
> >  		return -EINVAL;
> >  	}
> > 

Thanks,
Cristian


WARNING: multiple messages have this Message-ID (diff)
From: Cristian Marussi <cristian.marussi@arm.com>
To: Peter Hilber <peter.hilber@opensynergy.com>
Cc: linux-kernel@vger.kernel.org,
	linux-arm-kernel@lists.infradead.org,
	virtualization@lists.linux-foundation.org,
	virtio-dev@lists.oasis-open.org, sudeep.holla@arm.com,
	james.quinlan@broadcom.com, Jonathan.Cameron@Huawei.com,
	f.fainelli@gmail.com, etienne.carriere@linaro.org,
	vincent.guittot@linaro.org, souvik.chakravarty@arm.com,
	igor.skalkin@opensynergy.com, alex.bennee@linaro.org,
	jean-philippe@linaro.org, mikhail.golubev@opensynergy.com,
	anton.yakovlev@opensynergy.com, Vasyl.Vavrychuk@opensynergy.com,
	Andriy.Tryshnivskyy@opensynergy.com
Subject: Re: [PATCH v4 01/16] firmware: arm_scmi: Fix max pending messages boundary check
Date: Thu, 1 Jul 2021 11:04:19 +0100	[thread overview]
Message-ID: <20210701100258.GB50227@e120937-lin> (raw)
In-Reply-To: <cb24778e-60fd-4582-c855-238d71319067@opensynergy.com>

Hi Peter,

On Thu, Jul 01, 2021 at 10:42:40AM +0200, Peter Hilber wrote:
> Hi Cristian,
> 
> please find some remarks to the patch series in this email and the
> following.
> 

Thanks for your comments, very much appreciated. I'll reply inline.

Just to let you know, I have ready a V5 series where, beside some
general cleanup and further simplification, I addressed in the SCMI core
the issue that you pointed out about the possible concurrent and out-of-order
response/delayed_response delivery by the transport.

I've refrained from posting that on the list still, due to the merge window
being open. I'll post most probably next week. (still have to see if I
can also simplify probing sequence in V5...which is the last point in my
list)

> On 11.06.21 18:59, Cristian Marussi wrote:
> > SCMI message headers carry a sequence number and such field is sized to
> > allow for MSG_TOKEN_MAX distinct numbers; moreover zero is not really an
> > acceptable maximum number of pending in-flight messages.
> > 
> > Fix accordignly the checks performed on the value exported by transports
> > in scmi_desc.max_msg.
> > 
> > Reported-by: Vincent Guittot <vincent.guittot@linaro.org>
> > Fixes: aa4f886f3893 ("firmware: arm_scmi: add basic driver infrastructure for SCMI")
> > Signed-off-by: Cristian Marussi <cristian.marussi@arm.com>
> > ---
> >  drivers/firmware/arm_scmi/driver.c | 5 +++--
> >  1 file changed, 3 insertions(+), 2 deletions(-)
> > 
> > diff --git a/drivers/firmware/arm_scmi/driver.c b/drivers/firmware/arm_scmi/driver.c
> > index 66e5e694be7d..6713b259f1e6 100644
> > --- a/drivers/firmware/arm_scmi/driver.c
> > +++ b/drivers/firmware/arm_scmi/driver.c
> > @@ -1025,8 +1025,9 @@ static int __scmi_xfer_info_init(struct scmi_info *sinfo,
> >  	const struct scmi_desc *desc = sinfo->desc;
> >  	/* Pre-allocated messages, no more than what hdr.seq can support */
> > -	if (WARN_ON(desc->max_msg >= MSG_TOKEN_MAX)) {
> > -		dev_err(dev, "Maximum message of %d exceeds supported %ld\n",
> > +	if (WARN_ON(!desc->max_msg || desc->max_msg > MSG_TOKEN_MAX)) {
> > +		dev_err(dev,
> > +			"Invalid max_msg %d. Maximum messages supported %ld.\n",
> 
> %ld -> %lu
> 

Right, I'll fix.

> >  			desc->max_msg, MSG_TOKEN_MAX);
> >  		return -EINVAL;
> >  	}
> > 

Thanks,
Cristian


_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

  reply	other threads:[~2021-07-01 10:04 UTC|newest]

Thread overview: 97+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-06-11 16:59 [PATCH v4 00/16] Introduce SCMI VirtIO transport Cristian Marussi
2021-06-11 16:59 ` Cristian Marussi
2021-06-11 16:59 ` [PATCH v4 01/16] firmware: arm_scmi: Fix max pending messages boundary check Cristian Marussi
2021-06-11 16:59   ` Cristian Marussi
2021-07-01  8:42   ` Peter Hilber
2021-07-01  8:42     ` [virtio-dev] " Peter Hilber
2021-07-01  8:42     ` Peter Hilber
2021-07-01 10:04     ` Cristian Marussi [this message]
2021-07-01 10:04       ` Cristian Marussi
2021-06-11 16:59 ` [PATCH v4 02/16] firmware: arm_scmi: Add support for type handling in common functions Cristian Marussi
2021-06-11 16:59   ` Cristian Marussi
2021-06-11 16:59 ` [PATCH v4 03/16] firmware: arm_scmi: Add transport optional init/exit support Cristian Marussi
2021-06-11 16:59   ` Cristian Marussi
2021-06-14 13:29   ` Jonathan Cameron
2021-06-14 13:29     ` Jonathan Cameron
2021-06-16  9:04     ` Cristian Marussi
2021-06-16  9:04       ` Cristian Marussi
2021-06-11 16:59 ` [PATCH v4 04/16] firmware: arm_scmi: Introduce monotonically increasing tokens Cristian Marussi
2021-06-11 16:59   ` Cristian Marussi
2021-06-14 13:53   ` Jonathan Cameron
2021-06-14 13:53     ` Jonathan Cameron
2021-06-16  9:11     ` Cristian Marussi
2021-06-16  9:11       ` Cristian Marussi
2021-07-01  8:42   ` Peter Hilber
2021-07-01  8:42     ` [virtio-dev] " Peter Hilber
2021-07-01  8:42     ` Peter Hilber
2021-07-01 10:16     ` Cristian Marussi
2021-07-01 10:16       ` Cristian Marussi
2021-06-11 16:59 ` [PATCH v4 05/16] firmware: arm_scmi: Introduce delegated xfers support Cristian Marussi
2021-06-11 16:59   ` Cristian Marussi
2021-07-01  8:42   ` Peter Hilber
2021-07-01  8:42     ` [virtio-dev] " Peter Hilber
2021-07-01  8:42     ` Peter Hilber
2021-07-01 10:24     ` Cristian Marussi
2021-07-01 10:24       ` Cristian Marussi
2021-06-11 16:59 ` [PATCH v4 06/16] firmware: arm_scmi, smccc, mailbox: Make shmem based transports optional Cristian Marussi
2021-06-11 16:59   ` Cristian Marussi
2021-07-01  8:42   ` Peter Hilber
2021-07-01  8:42     ` [virtio-dev] " Peter Hilber
2021-07-01  8:42     ` Peter Hilber
2021-07-01 10:27     ` Cristian Marussi
2021-07-01 10:27       ` Cristian Marussi
2021-06-11 16:59 ` [PATCH v4 07/16] firmware: arm_scmi: Add op to override max message # Cristian Marussi
2021-06-11 16:59   ` Cristian Marussi
2021-06-14 14:04   ` Jonathan Cameron
2021-06-14 14:04     ` Jonathan Cameron
2021-06-16  9:13     ` Cristian Marussi
2021-06-16  9:13       ` Cristian Marussi
2021-06-11 16:59 ` [PATCH v4 08/16] [RFC][REWORK] " Cristian Marussi
2021-06-11 16:59   ` Cristian Marussi
2021-06-11 16:59 ` [PATCH v4 09/16] firmware: arm_scmi: Add optional link_supplier() transport op Cristian Marussi
2021-06-11 16:59   ` Cristian Marussi
2021-06-11 16:59 ` [PATCH v4 10/16] firmware: arm_scmi: Add per-device transport private info Cristian Marussi
2021-06-11 16:59   ` Cristian Marussi
2021-06-11 16:59 ` [PATCH v4 11/16] firmware: arm_scmi: Add is_scmi_protocol_device() Cristian Marussi
2021-06-11 16:59   ` Cristian Marussi
2021-06-11 16:59 ` [PATCH v4 12/16] firmware: arm_scmi: Add message passing abstractions for transports Cristian Marussi
2021-06-11 16:59   ` Cristian Marussi
2021-06-14 14:10   ` Jonathan Cameron
2021-06-14 14:10     ` Jonathan Cameron
2021-06-16  9:14     ` Cristian Marussi
2021-06-16  9:14       ` Cristian Marussi
2021-06-11 16:59 ` [PATCH v4 13/16] dt-bindings: arm: Add virtio transport for SCMI Cristian Marussi
2021-06-11 16:59   ` Cristian Marussi
2021-06-24 19:22   ` Rob Herring
2021-06-24 19:22     ` Rob Herring
2021-06-24 19:22     ` Rob Herring
2021-07-01  8:43   ` Peter Hilber
2021-07-01  8:43     ` [virtio-dev] " Peter Hilber
2021-07-01  8:43     ` Peter Hilber
2021-07-01 10:31     ` Cristian Marussi
2021-07-01 10:31       ` Cristian Marussi
2021-06-11 16:59 ` [PATCH v4 14/16] firmware: arm_scmi: Add virtio transport Cristian Marussi
2021-06-11 16:59   ` Cristian Marussi
2021-06-14 14:23   ` Jonathan Cameron
2021-06-14 14:23     ` Jonathan Cameron
2021-06-16 10:18     ` Cristian Marussi
2021-06-16 10:18       ` Cristian Marussi
2021-07-01  8:43   ` Peter Hilber
2021-07-01  8:43     ` [virtio-dev] " Peter Hilber
2021-07-01  8:43     ` Peter Hilber
2021-07-01 10:34     ` Cristian Marussi
2021-07-01 10:34       ` Cristian Marussi
2021-06-11 16:59 ` [PATCH v4 15/16] [RFC][REWORK] firmware: arm_scmi: make virtio-scmi use delegated xfers Cristian Marussi
2021-06-11 16:59   ` Cristian Marussi
2021-07-01  8:43   ` Peter Hilber
2021-07-01  8:43     ` [virtio-dev] " Peter Hilber
2021-07-01  8:43     ` Peter Hilber
2021-07-01 11:26     ` Cristian Marussi
2021-07-01 11:26       ` Cristian Marussi
2021-06-11 16:59 ` [PATCH v4 16/16] firmware: arm_scmi: Add polling mode to virtio transport Cristian Marussi
2021-06-11 16:59   ` Cristian Marussi
2021-06-14 11:43 ` [PATCH v4 00/16] Introduce SCMI VirtIO transport Christoph Hellwig
2021-06-14 11:43   ` Christoph Hellwig
2021-06-14 11:43   ` Christoph Hellwig
2021-06-14 14:03   ` Cristian Marussi
2021-06-14 14:03     ` Cristian Marussi

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=20210701100258.GB50227@e120937-lin \
    --to=cristian.marussi@arm.com \
    --cc=Andriy.Tryshnivskyy@opensynergy.com \
    --cc=Jonathan.Cameron@Huawei.com \
    --cc=Vasyl.Vavrychuk@opensynergy.com \
    --cc=alex.bennee@linaro.org \
    --cc=anton.yakovlev@opensynergy.com \
    --cc=etienne.carriere@linaro.org \
    --cc=f.fainelli@gmail.com \
    --cc=igor.skalkin@opensynergy.com \
    --cc=james.quinlan@broadcom.com \
    --cc=jean-philippe@linaro.org \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mikhail.golubev@opensynergy.com \
    --cc=peter.hilber@opensynergy.com \
    --cc=souvik.chakravarty@arm.com \
    --cc=sudeep.holla@arm.com \
    --cc=vincent.guittot@linaro.org \
    --cc=virtio-dev@lists.oasis-open.org \
    --cc=virtualization@lists.linux-foundation.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.