From: Cornelia Huck <cohuck@redhat.com>
To: Marc Kleine-Budde <mkl@pengutronix.de>,
Matias Ezequiel Vara Larsen <mvaralar@redhat.com>
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: Mon, 26 Feb 2024 13:36:40 +0100 [thread overview]
Message-ID: <877circsh3.fsf@redhat.com> (raw)
In-Reply-To: <20240221-juggling-uproar-9518b4901f41-mkl@pengutronix.de>
On Wed, Feb 21 2024, Marc Kleine-Budde <mkl@pengutronix.de> wrote:
> On 21.02.2024 14:16:54, Matias Ezequiel Vara Larsen wrote:
>> 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.
>
> Another option would be an extended frame (VIRTIO_CAN_FLAGS_EXTENDED
> set) and using more than 29 bits.
>
>> Thanks Marc for the explanation. Do you think that it would be
>> worthwhile to add that to the spec at some point?
>
> Yes that makes sense as it clarifies what's meant by out of range for
> CAN-IDs, for the valid length a reference to
> \item[VIRTIO_CAN_F_CAN_CLASSIC (0)] and \item[VIRTIO_CAN_F_CAN_FD (1)]
> might be added.
[virtio mailing lists are supposedly down for migration right now, I
hope there's some kind of backfill happening later...]
If the question comes up, it does make sense to add a
clarification... as the virtio-can spec is already voted upon and
merged, we'd need a patch on top. Not sure if it would qualify as an
editorial update or a vote would be needed, best to see it first :)
WARNING: multiple messages have this Message-ID (diff)
From: Cornelia Huck <cohuck@redhat.com>
To: Marc Kleine-Budde <mkl@pengutronix.de>,
Matias Ezequiel Vara Larsen <mvaralar@redhat.com>
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: Mon, 26 Feb 2024 13:36:40 +0100 [thread overview]
Message-ID: <877circsh3.fsf@redhat.com> (raw)
In-Reply-To: <20240221-juggling-uproar-9518b4901f41-mkl@pengutronix.de>
On Wed, Feb 21 2024, Marc Kleine-Budde <mkl@pengutronix.de> wrote:
> On 21.02.2024 14:16:54, Matias Ezequiel Vara Larsen wrote:
>> 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.
>
> Another option would be an extended frame (VIRTIO_CAN_FLAGS_EXTENDED
> set) and using more than 29 bits.
>
>> Thanks Marc for the explanation. Do you think that it would be
>> worthwhile to add that to the spec at some point?
>
> Yes that makes sense as it clarifies what's meant by out of range for
> CAN-IDs, for the valid length a reference to
> \item[VIRTIO_CAN_F_CAN_CLASSIC (0)] and \item[VIRTIO_CAN_F_CAN_FD (1)]
> might be added.
[virtio mailing lists are supposedly down for migration right now, I
hope there's some kind of backfill happening later...]
If the question comes up, it does make sense to add a
clarification... as the virtio-can spec is already voted upon and
merged, we'd need a patch on top. Not sure if it would qualify as an
editorial update or a vote would be needed, best to see it first :)
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: Cornelia Huck <cohuck@redhat.com>
To: Marc Kleine-Budde <mkl@pengutronix.de>,
Matias Ezequiel Vara Larsen <mvaralar@redhat.com>
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: Mon, 26 Feb 2024 13:36:40 +0100 [thread overview]
Message-ID: <877circsh3.fsf@redhat.com> (raw)
In-Reply-To: <20240221-juggling-uproar-9518b4901f41-mkl@pengutronix.de>
On Wed, Feb 21 2024, Marc Kleine-Budde <mkl@pengutronix.de> wrote:
> On 21.02.2024 14:16:54, Matias Ezequiel Vara Larsen wrote:
>> 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.
>
> Another option would be an extended frame (VIRTIO_CAN_FLAGS_EXTENDED
> set) and using more than 29 bits.
>
>> Thanks Marc for the explanation. Do you think that it would be
>> worthwhile to add that to the spec at some point?
>
> Yes that makes sense as it clarifies what's meant by out of range for
> CAN-IDs, for the valid length a reference to
> \item[VIRTIO_CAN_F_CAN_CLASSIC (0)] and \item[VIRTIO_CAN_F_CAN_FD (1)]
> might be added.
[virtio mailing lists are supposedly down for migration right now, I
hope there's some kind of backfill happening later...]
If the question comes up, it does make sense to add a
clarification... as the virtio-can spec is already voted upon and
merged, we'd need a patch on top. Not sure if it would qualify as an
editorial update or a vote would be needed, best to see it first :)
---------------------------------------------------------------------
To unsubscribe, e-mail: virtio-dev-unsubscribe@lists.oasis-open.org
For additional commands, e-mail: virtio-dev-help@lists.oasis-open.org
next prev parent reply other threads:[~2024-02-26 12:36 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
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 [this message]
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=877circsh3.fsf@redhat.com \
--to=cohuck@redhat.com \
--cc=harald.mommer@opensynergy.com \
--cc=linux-can@vger.kernel.org \
--cc=mikhail.golubev-ciuchea@opensynergy.com \
--cc=mkl@pengutronix.de \
--cc=mvaralar@redhat.com \
--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.