All of lore.kernel.org
 help / color / mirror / Atom feed
From: Matias Ezequiel Vara Larsen <mvaralar@redhat.com>
To: Marc Kleine-Budde <mkl@pengutronix.de>
Cc: Mikhail Golubev-Ciuchea <mikhail.golubev-ciuchea@opensynergy.com>,
	virtio-comment@lists.oasis-open.org,
	virtio-dev@lists.oasis-open.org, linux-can@vger.kernel.org,
	Harald Mommer <harald.mommer@opensynergy.com>
Subject: Re: [virtio-dev] Re: [virtio-comment] [RFC PATCH v3] virtio-can: Device specification.
Date: Wed, 21 Feb 2024 14:16:54 +0100	[thread overview]
Message-ID: <ZdX3xgM36iOVhr3V@fedora> (raw)
In-Reply-To: <20240221-acts-decade-76d3d69e8e4d-mkl@pengutronix.de>

On Wed, Feb 21, 2024 at 01:49:31PM +0100, Marc Kleine-Budde wrote:
> On 21.02.2024 11:37:58, Matias Ezequiel Vara Larsen wrote:
> > > > +The length of the \field{sdu} is determined by the \field{length}.
> > > > +
> > > > +The type of a CAN message identifier is determined by \field{flags}. The
> > > > +3 most significant bits of \field{can_id} do not bear the information
> > > > +about the type of the CAN message identifier and are 0.
> > > > +
> > > > +The device MUST reject any CAN frame type for which support has not been
> > > > +negotiated with VIRTIO_CAN_RESULT_NOT_OK in \field{result} and MUST NOT
> > > > +schedule the message for transmission. A CAN frame with an undefined bit
> > > > +set in \field{flags} is treated like a CAN frame for which support has
> > > > +not been negotiated.
> > > > +
> > > > +The device MUST reject any CAN frame for which \field{can_id} or
> > > > +\field{sdu} length are out of range or the CAN controller is in an
> > > > +invalid state with VIRTIO_CAN_RESULT_NOT_OK in \field{result} and MUST
> > > > +NOT schedule the message for transmission.
> > > > +
> > I am not very familiar with CAN but how does the device figure out that
> > the can_id is out of range?
> 
> In classical CAN we have the standard CAN frames, which have an 11 bit
> ID, and there are extended CAN frames, which have 29 bits ID. Extended
> frames are signaled with VIRTIO_CAN_FLAGS_EXTENDED set.
> 
> So if a standard frame uses more than 11 Bits of CAN-ID, it's considered
> out of range.
> 
Thanks Marc for the explanation. Do you think that it would be
worthwhile to add that to the spec at some point?

Matias.


WARNING: multiple messages have this Message-ID (diff)
From: Matias Ezequiel Vara Larsen <mvaralar@redhat.com>
To: Marc Kleine-Budde <mkl@pengutronix.de>
Cc: Mikhail Golubev-Ciuchea <mikhail.golubev-ciuchea@opensynergy.com>,
	virtio-comment@lists.oasis-open.org,
	virtio-dev@lists.oasis-open.org, linux-can@vger.kernel.org,
	Harald Mommer <harald.mommer@opensynergy.com>
Subject: [virtio-comment] Re: [virtio-dev] Re: [virtio-comment] [RFC PATCH v3] virtio-can: Device specification.
Date: Wed, 21 Feb 2024 14:16:54 +0100	[thread overview]
Message-ID: <ZdX3xgM36iOVhr3V@fedora> (raw)
In-Reply-To: <20240221-acts-decade-76d3d69e8e4d-mkl@pengutronix.de>

On Wed, Feb 21, 2024 at 01:49:31PM +0100, Marc Kleine-Budde wrote:
> On 21.02.2024 11:37:58, Matias Ezequiel Vara Larsen wrote:
> > > > +The length of the \field{sdu} is determined by the \field{length}.
> > > > +
> > > > +The type of a CAN message identifier is determined by \field{flags}. The
> > > > +3 most significant bits of \field{can_id} do not bear the information
> > > > +about the type of the CAN message identifier and are 0.
> > > > +
> > > > +The device MUST reject any CAN frame type for which support has not been
> > > > +negotiated with VIRTIO_CAN_RESULT_NOT_OK in \field{result} and MUST NOT
> > > > +schedule the message for transmission. A CAN frame with an undefined bit
> > > > +set in \field{flags} is treated like a CAN frame for which support has
> > > > +not been negotiated.
> > > > +
> > > > +The device MUST reject any CAN frame for which \field{can_id} or
> > > > +\field{sdu} length are out of range or the CAN controller is in an
> > > > +invalid state with VIRTIO_CAN_RESULT_NOT_OK in \field{result} and MUST
> > > > +NOT schedule the message for transmission.
> > > > +
> > I am not very familiar with CAN but how does the device figure out that
> > the can_id is out of range?
> 
> In classical CAN we have the standard CAN frames, which have an 11 bit
> ID, and there are extended CAN frames, which have 29 bits ID. Extended
> frames are signaled with VIRTIO_CAN_FLAGS_EXTENDED set.
> 
> So if a standard frame uses more than 11 Bits of CAN-ID, it's considered
> out of range.
> 
Thanks Marc for the explanation. Do you think that it would be
worthwhile to add that to the spec at some point?

Matias.


This publicly archived list offers a means to provide input to the
OASIS Virtual I/O Device (VIRTIO) TC.

In order to verify user consent to the Feedback License terms and
to minimize spam in the list archive, subscription is required
before posting.

Subscribe: virtio-comment-subscribe@lists.oasis-open.org
Unsubscribe: virtio-comment-unsubscribe@lists.oasis-open.org
List help: virtio-comment-help@lists.oasis-open.org
List archive: https://lists.oasis-open.org/archives/virtio-comment/
Feedback License: https://www.oasis-open.org/who/ipr/feedback_license.pdf
List Guidelines: https://www.oasis-open.org/policies-guidelines/mailing-lists
Committee: https://www.oasis-open.org/committees/virtio/
Join OASIS: https://www.oasis-open.org/join/


WARNING: multiple messages have this Message-ID (diff)
From: Matias Ezequiel Vara Larsen <mvaralar@redhat.com>
To: Marc Kleine-Budde <mkl@pengutronix.de>
Cc: Mikhail Golubev-Ciuchea <mikhail.golubev-ciuchea@opensynergy.com>,
	virtio-comment@lists.oasis-open.org,
	virtio-dev@lists.oasis-open.org, linux-can@vger.kernel.org,
	Harald Mommer <harald.mommer@opensynergy.com>
Subject: Re: [virtio-dev] Re: [virtio-comment] [RFC PATCH v3] virtio-can: Device specification.
Date: Wed, 21 Feb 2024 14:16:54 +0100	[thread overview]
Message-ID: <ZdX3xgM36iOVhr3V@fedora> (raw)
In-Reply-To: <20240221-acts-decade-76d3d69e8e4d-mkl@pengutronix.de>

On Wed, Feb 21, 2024 at 01:49:31PM +0100, Marc Kleine-Budde wrote:
> On 21.02.2024 11:37:58, Matias Ezequiel Vara Larsen wrote:
> > > > +The length of the \field{sdu} is determined by the \field{length}.
> > > > +
> > > > +The type of a CAN message identifier is determined by \field{flags}. The
> > > > +3 most significant bits of \field{can_id} do not bear the information
> > > > +about the type of the CAN message identifier and are 0.
> > > > +
> > > > +The device MUST reject any CAN frame type for which support has not been
> > > > +negotiated with VIRTIO_CAN_RESULT_NOT_OK in \field{result} and MUST NOT
> > > > +schedule the message for transmission. A CAN frame with an undefined bit
> > > > +set in \field{flags} is treated like a CAN frame for which support has
> > > > +not been negotiated.
> > > > +
> > > > +The device MUST reject any CAN frame for which \field{can_id} or
> > > > +\field{sdu} length are out of range or the CAN controller is in an
> > > > +invalid state with VIRTIO_CAN_RESULT_NOT_OK in \field{result} and MUST
> > > > +NOT schedule the message for transmission.
> > > > +
> > I am not very familiar with CAN but how does the device figure out that
> > the can_id is out of range?
> 
> In classical CAN we have the standard CAN frames, which have an 11 bit
> ID, and there are extended CAN frames, which have 29 bits ID. Extended
> frames are signaled with VIRTIO_CAN_FLAGS_EXTENDED set.
> 
> So if a standard frame uses more than 11 Bits of CAN-ID, it's considered
> out of range.
> 
Thanks Marc for the explanation. Do you think that it would be
worthwhile to add that to the spec at some point?

Matias.


---------------------------------------------------------------------
To unsubscribe, e-mail: virtio-dev-unsubscribe@lists.oasis-open.org
For additional commands, e-mail: virtio-dev-help@lists.oasis-open.org


  reply	other threads:[~2024-02-21 13:17 UTC|newest]

Thread overview: 43+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-06-09 14:22 [RFC PATCH v3] virtio-can: Device specification Mikhail Golubev-Ciuchea
2023-06-09 14:22 ` [virtio-dev] " Mikhail Golubev-Ciuchea
2023-06-09 14:22 ` [virtio-comment] " Mikhail Golubev-Ciuchea
2024-01-08 17:18 ` Mikhail Golubev-Ciuchea
2024-01-08 17:18   ` [virtio-dev] " Mikhail Golubev-Ciuchea
2024-01-08 17:18   ` Mikhail Golubev-Ciuchea
2024-01-15 16:24   ` Cornelia Huck
2024-01-15 16:24     ` [virtio-dev] " Cornelia Huck
2024-01-15 16:24     ` Cornelia Huck
2024-02-02 12:45     ` Cornelia Huck
2024-02-02 12:45       ` [virtio-dev] " Cornelia Huck
2024-02-02 12:45       ` Cornelia Huck
2024-02-20 12:19   ` Matias Ezequiel Vara Larsen
2024-02-20 12:19     ` [virtio-dev] " Matias Ezequiel Vara Larsen
2024-02-20 12:19     ` Matias Ezequiel Vara Larsen
2024-02-21 15:42     ` Mikhail Golubev-Ciuchea
2024-02-21 15:42       ` [virtio-dev] " Mikhail Golubev-Ciuchea
2024-02-21 15:42       ` Mikhail Golubev-Ciuchea
2024-02-22 11:30       ` Matias Ezequiel Vara Larsen
2024-02-22 11:30         ` [virtio-dev] " Matias Ezequiel Vara Larsen
2024-02-22 11:30         ` Matias Ezequiel Vara Larsen
2024-02-21 10:37   ` Matias Ezequiel Vara Larsen
2024-02-21 10:37     ` [virtio-dev] " Matias Ezequiel Vara Larsen
2024-02-21 10:37     ` Matias Ezequiel Vara Larsen
2024-02-21 12:49     ` Marc Kleine-Budde
2024-02-21 12:49       ` [virtio-dev] " Marc Kleine-Budde
2024-02-21 13:16       ` Matias Ezequiel Vara Larsen [this message]
2024-02-21 13:16         ` Matias Ezequiel Vara Larsen
2024-02-21 13:16         ` [virtio-comment] " Matias Ezequiel Vara Larsen
2024-02-21 13:28         ` Marc Kleine-Budde
2024-02-26 12:36           ` Cornelia Huck
2024-02-26 12:36             ` Cornelia Huck
2024-02-26 12:36             ` [virtio-comment] " Cornelia Huck
2024-02-27  9:02             ` Matias Ezequiel Vara Larsen
2024-02-27  9:02               ` Matias Ezequiel Vara Larsen
2024-02-27  9:02               ` [virtio-comment] " Matias Ezequiel Vara Larsen
2024-03-06 14:12   ` Matias Ezequiel Vara Larsen
2024-02-13 14:57 ` [virtio-dev] " Cornelia Huck
2024-02-13 14:57   ` Cornelia Huck
2024-02-13 14:57   ` [virtio-comment] " Cornelia Huck
2024-02-16 11:08 ` Cornelia Huck
2024-02-16 11:08   ` Cornelia Huck
2024-02-16 11:08   ` [virtio-comment] " Cornelia Huck

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=ZdX3xgM36iOVhr3V@fedora \
    --to=mvaralar@redhat.com \
    --cc=harald.mommer@opensynergy.com \
    --cc=linux-can@vger.kernel.org \
    --cc=mikhail.golubev-ciuchea@opensynergy.com \
    --cc=mkl@pengutronix.de \
    --cc=virtio-comment@lists.oasis-open.org \
    --cc=virtio-dev@lists.oasis-open.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.