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.
Marc
--
Pengutronix e.K. | Marc Kleine-Budde |
Embedded Linux | https://www.pengutronix.de |
Vertretung Nürnberg | Phone: +49-5121-206917-129 |
Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-9 |
Attachment:
signature.asc
Description: PGP signature
