Re: [virtio-dev] Re: [virtio-comment] [RFC PATCH v3] virtio-can: Device specification.

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: [email protected]
For additional commands, e-mail: [email protected]