On Mon, Feb 26, 2024 at 01:36:40PM +0100, Cornelia Huck wrote:
> On Wed, Feb 21 2024, Marc Kleine-Budde <mkl@xxxxxxxxxxxxxx> 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 :)
>
I will submit two patches regarding the changes proposed in this thread.
Matias
