Re: [virtio-dev] Re: [virtio-comment] [RFC PATCH v3] virtio-can: Device specification.
On Mon, Feb 26, 2024 at 01:36:40PM +0100, Cornelia Huck wrote:
> On Wed, Feb 21 2024, Marc Kleine-Budde 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
-
To unsubscribe, e-mail: virtio-dev-unsubscr...@lists.oasis-open.org
For additional commands, e-mail: virtio-dev-h...@lists.oasis-open.org
Re: [virtio-dev] Re: [virtio-comment] [RFC PATCH v3] virtio-can: Device specification.
On Wed, Feb 21 2024, Marc Kleine-Budde 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-unsubscr...@lists.oasis-open.org
For additional commands, e-mail: virtio-dev-h...@lists.oasis-open.org
[virtio-dev] Re: [virtio-comment] [RFC PATCH v3] virtio-can: Device specification.
On Wed, Feb 21, 2024 at 04:42:18PM +0100, Mikhail Golubev-Ciuchea wrote:
> Hi Matias,
>
> On 2/20/24 13:19, Matias Ezequiel Vara Larsen wrote:
> > Hello Mikail,
> >
> > On Mon, Jan 08, 2024 at 06:18:50PM +0100, Mikhail Golubev-Ciuchea wrote:
> > > Hi all!
> > >
> > > I kindly request a vote.
> > >
> > > Fixes: https://github.com/oasis-tcs/virtio-spec/issues/186
> > >
> > >
> > > Best wishes,
> > > Mikhail Golubev-Ciuchea
> > >
> > >
> > >
> > > On 6/9/23 16:22, Mikhail Golubev-Ciuchea wrote:
> > > > From: Harald Mommer
> > > >
> > > > virtio-can is a virtual CAN device. It provides a way to give access to
> > > > a CAN controller from a driver guest. The device is aimed to be used by
> > > > driver guests running a HLOS as well as by driver guests running a
> > > > typical RTOS as used in controller environments.
> > > >
> > > > Signed-off-by: Harald Mommer
> > > > Signed-off-by: Mikhail Golubev-Ciuchea
> > > >
> > > > ---
> > > >
> > > > RFC v3:
> > > > * Add length fields in CAN RX and TX messages.
> > > > * Replace bus off indication queue with a config space bit.
> > > > * Clarify handling of unknown flag bits set in CAN frame.
> > > > * Remove MISRA C suffixes in constants.
> > > > * Reserve 16 bits in RX/TX messages for CAN XL priority.
> > > > * Reserve 8 bits in RX/TX messages for CAN classic DLC.
> > > > * Rework according to general virtio spec POV.
> > > > * Implementation:
> > > > driver:
> > > > https://lore.kernel.org/all/20230607145613.133203-1-mikhail.golubev-ciuc...@opensynergy.com/
> > > > QEmu device:
> > > > https://github.com/OpenSynergy/qemu/tree/virtio-can-spec-rfc-v3
> > > >
> > > > RFC v2:
> > > > * Add CAN classic feature flag.
> > > > * Add feature flag VIRTIO_CAN_F_LATE_TX_ACK.
> > > > * Add feature flag VIRTIO_CAN_F_RTR_FRAMES.
> > > > * Reserve 32 bits in RX/TX messages.
> > > > * Remove priorities of messages.
> > > >
> > > >conformance.tex | 12 +-
> > > >content.tex | 1 +
> > > >device-types/can/description.tex| 249
> > > >
> > > >device-types/can/device-conformance.tex | 8 +
> > > >device-types/can/driver-conformance.tex | 7 +
> > > >introduction.tex| 2 +
> > > >6 files changed, 275 insertions(+), 4 deletions(-)
> > > >create mode 100644 device-types/can/description.tex
> > > >create mode 100644 device-types/can/device-conformance.tex
> > > >create mode 100644 device-types/can/driver-conformance.tex
> > > >
> > > > diff --git a/conformance.tex b/conformance.tex
> > > > index 01ccd69..a07ef02 100644
> > > > --- a/conformance.tex
> > > > +++ b/conformance.tex
> > > > @@ -32,8 +32,9 @@ \section{Conformance Targets}\label{sec:Conformance /
> > > > Conformance Targets}
> > > >\ref{sec:Conformance / Driver Conformance / Memory Driver
> > > > Conformance},
> > > >\ref{sec:Conformance / Driver Conformance / I2C Adapter Driver
> > > > Conformance},
> > > >\ref{sec:Conformance / Driver Conformance / SCMI Driver Conformance},
> > > > -\ref{sec:Conformance / Driver Conformance / GPIO Driver Conformance} or
> > > > -\ref{sec:Conformance / Driver Conformance / PMEM Driver Conformance}.
> > > > +\ref{sec:Conformance / Driver Conformance / GPIO Driver Conformance},
> > > > +\ref{sec:Conformance / Driver Conformance / PMEM Driver Conformance} or
> > > > +\ref{sec:Conformance / Driver Conformance / CAN Driver Conformance}.
> > > >\item Clause \ref{sec:Conformance / Legacy Interface:
> > > > Transitional Device and Transitional Driver Conformance}.
> > > > \end{itemize}
> > > > @@ -59,8 +60,9 @@ \section{Conformance Targets}\label{sec:Conformance /
> > > > Conformance Targets}
> > > >\ref{sec:Conformance / Device Conformance / Memory Device
> > > > Conformance},
> > > >\ref{sec:Conformance / Device Conformance / I2C Adapter Device
> > > > Conformance},
> > > >\ref{sec:Conformance / Device Conformance / SCMI Device Conformance},
> > > > -\ref{sec:Conformance / Device Conformance / GPIO Device Conformance} or
> > > > -\ref{sec:Conformance / Device Conformance / PMEM Device Conformance}.
> > > > +\ref{sec:Conformance / Device Conformance / GPIO Device Conformance},
> > > > +\ref{sec:Conformance / Device Conformance / PMEM Device Conformance} or
> > > > +\ref{sec:Conformance / Device Conformance / CAN Device Conformance}.
> > > >\item Clause \ref{sec:Conformance / Legacy Interface:
> > > > Transitional Device and Transitional Driver Conformance}.
> > > > \end{itemize}
> > > > @@ -152,6 +154,7 @@ \section{Conformance Targets}\label{sec:Conformance
> > > > / Conformance Targets}
> > > >\input{device-types/scmi/driver-conformance.tex}
> > > >\input{device-types/gpio/driver-conformance.tex}
> > > >\input{device-types/pmem/driver-conformance.tex}
> > > > +\input{device-types/can/driver-conformance.tex}
> > > >\conformance{\section}{Device
[virtio-dev] Re: [virtio-comment] [RFC PATCH v3] virtio-can: Device specification.
Hi Matias,
On 2/20/24 13:19, Matias Ezequiel Vara Larsen wrote:
Hello Mikail,
On Mon, Jan 08, 2024 at 06:18:50PM +0100, Mikhail Golubev-Ciuchea wrote:
Hi all!
I kindly request a vote.
Fixes: https://github.com/oasis-tcs/virtio-spec/issues/186
Best wishes,
Mikhail Golubev-Ciuchea
On 6/9/23 16:22, Mikhail Golubev-Ciuchea wrote:
From: Harald Mommer
virtio-can is a virtual CAN device. It provides a way to give access to
a CAN controller from a driver guest. The device is aimed to be used by
driver guests running a HLOS as well as by driver guests running a
typical RTOS as used in controller environments.
Signed-off-by: Harald Mommer
Signed-off-by: Mikhail Golubev-Ciuchea
---
RFC v3:
* Add length fields in CAN RX and TX messages.
* Replace bus off indication queue with a config space bit.
* Clarify handling of unknown flag bits set in CAN frame.
* Remove MISRA C suffixes in constants.
* Reserve 16 bits in RX/TX messages for CAN XL priority.
* Reserve 8 bits in RX/TX messages for CAN classic DLC.
* Rework according to general virtio spec POV.
* Implementation:
driver:
https://lore.kernel.org/all/20230607145613.133203-1-mikhail.golubev-ciuc...@opensynergy.com/
QEmu device: https://github.com/OpenSynergy/qemu/tree/virtio-can-spec-rfc-v3
RFC v2:
* Add CAN classic feature flag.
* Add feature flag VIRTIO_CAN_F_LATE_TX_ACK.
* Add feature flag VIRTIO_CAN_F_RTR_FRAMES.
* Reserve 32 bits in RX/TX messages.
* Remove priorities of messages.
conformance.tex | 12 +-
content.tex | 1 +
device-types/can/description.tex| 249
device-types/can/device-conformance.tex | 8 +
device-types/can/driver-conformance.tex | 7 +
introduction.tex| 2 +
6 files changed, 275 insertions(+), 4 deletions(-)
create mode 100644 device-types/can/description.tex
create mode 100644 device-types/can/device-conformance.tex
create mode 100644 device-types/can/driver-conformance.tex
diff --git a/conformance.tex b/conformance.tex
index 01ccd69..a07ef02 100644
--- a/conformance.tex
+++ b/conformance.tex
@@ -32,8 +32,9 @@ \section{Conformance Targets}\label{sec:Conformance /
Conformance Targets}
\ref{sec:Conformance / Driver Conformance / Memory Driver Conformance},
\ref{sec:Conformance / Driver Conformance / I2C Adapter Driver Conformance},
\ref{sec:Conformance / Driver Conformance / SCMI Driver Conformance},
-\ref{sec:Conformance / Driver Conformance / GPIO Driver Conformance} or
-\ref{sec:Conformance / Driver Conformance / PMEM Driver Conformance}.
+\ref{sec:Conformance / Driver Conformance / GPIO Driver Conformance},
+\ref{sec:Conformance / Driver Conformance / PMEM Driver Conformance} or
+\ref{sec:Conformance / Driver Conformance / CAN Driver Conformance}.
\item Clause \ref{sec:Conformance / Legacy Interface: Transitional
Device and Transitional Driver Conformance}.
\end{itemize}
@@ -59,8 +60,9 @@ \section{Conformance Targets}\label{sec:Conformance /
Conformance Targets}
\ref{sec:Conformance / Device Conformance / Memory Device Conformance},
\ref{sec:Conformance / Device Conformance / I2C Adapter Device Conformance},
\ref{sec:Conformance / Device Conformance / SCMI Device Conformance},
-\ref{sec:Conformance / Device Conformance / GPIO Device Conformance} or
-\ref{sec:Conformance / Device Conformance / PMEM Device Conformance}.
+\ref{sec:Conformance / Device Conformance / GPIO Device Conformance},
+\ref{sec:Conformance / Device Conformance / PMEM Device Conformance} or
+\ref{sec:Conformance / Device Conformance / CAN Device Conformance}.
\item Clause \ref{sec:Conformance / Legacy Interface: Transitional
Device and Transitional Driver Conformance}.
\end{itemize}
@@ -152,6 +154,7 @@ \section{Conformance Targets}\label{sec:Conformance /
Conformance Targets}
\input{device-types/scmi/driver-conformance.tex}
\input{device-types/gpio/driver-conformance.tex}
\input{device-types/pmem/driver-conformance.tex}
+\input{device-types/can/driver-conformance.tex}
\conformance{\section}{Device Conformance}\label{sec:Conformance / Device
Conformance}
@@ -238,6 +241,7 @@ \section{Conformance Targets}\label{sec:Conformance /
Conformance Targets}
\input{device-types/scmi/device-conformance.tex}
\input{device-types/gpio/device-conformance.tex}
\input{device-types/pmem/device-conformance.tex}
+\input{device-types/can/device-conformance.tex}
\conformance{\section}{Legacy Interface: Transitional Device and
Transitional Driver Conformance}\label{sec:Conformance / Legacy Interface:
Transitional Device and Transitional Driver Conformance}
A conformant implementation MUST be either transitional or
diff --git a/content.tex b/content.tex
index d2ab9eb..8806b57 100644
--- a/content.tex
+++ b/content.tex
@@ -765,6 +765,7 @@ \chapter{Device Types}\label{sec:Device Types}
\input{device-types/scmi/description.tex}
Re: [virtio-dev] Re: [virtio-comment] [RFC PATCH v3] virtio-can: Device specification.
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.
regards,
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 |
signature.asc
Description: PGP signature
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: virtio-dev-unsubscr...@lists.oasis-open.org
For additional commands, e-mail: virtio-dev-h...@lists.oasis-open.org
[virtio-dev] Re: [virtio-comment] [RFC PATCH v3] virtio-can: Device specification.
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 |
signature.asc
Description: PGP signature
[virtio-dev] Re: [virtio-comment] [RFC PATCH v3] virtio-can: Device specification.
On Mon, Jan 08, 2024 at 06:18:50PM +0100, Mikhail Golubev-Ciuchea wrote:
> Hi all!
>
> I kindly request a vote.
>
> Fixes: https://github.com/oasis-tcs/virtio-spec/issues/186
>
>
> Best wishes,
> Mikhail Golubev-Ciuchea
>
>
>
> On 6/9/23 16:22, Mikhail Golubev-Ciuchea wrote:
> > From: Harald Mommer
> >
> > virtio-can is a virtual CAN device. It provides a way to give access to
> > a CAN controller from a driver guest. The device is aimed to be used by
> > driver guests running a HLOS as well as by driver guests running a
> > typical RTOS as used in controller environments.
> >
> > Signed-off-by: Harald Mommer
> > Signed-off-by: Mikhail Golubev-Ciuchea
> >
> > ---
> >
> > RFC v3:
> > * Add length fields in CAN RX and TX messages.
> > * Replace bus off indication queue with a config space bit.
> > * Clarify handling of unknown flag bits set in CAN frame.
> > * Remove MISRA C suffixes in constants.
> > * Reserve 16 bits in RX/TX messages for CAN XL priority.
> > * Reserve 8 bits in RX/TX messages for CAN classic DLC.
> > * Rework according to general virtio spec POV.
> > * Implementation:
> >driver:
> > https://lore.kernel.org/all/20230607145613.133203-1-mikhail.golubev-ciuc...@opensynergy.com/
> >QEmu device:
> > https://github.com/OpenSynergy/qemu/tree/virtio-can-spec-rfc-v3
> >
> > RFC v2:
> > * Add CAN classic feature flag.
> > * Add feature flag VIRTIO_CAN_F_LATE_TX_ACK.
> > * Add feature flag VIRTIO_CAN_F_RTR_FRAMES.
> > * Reserve 32 bits in RX/TX messages.
> > * Remove priorities of messages.
> >
> > conformance.tex | 12 +-
> > content.tex | 1 +
> > device-types/can/description.tex| 249
> > device-types/can/device-conformance.tex | 8 +
> > device-types/can/driver-conformance.tex | 7 +
> > introduction.tex| 2 +
> > 6 files changed, 275 insertions(+), 4 deletions(-)
> > create mode 100644 device-types/can/description.tex
> > create mode 100644 device-types/can/device-conformance.tex
> > create mode 100644 device-types/can/driver-conformance.tex
> >
> > diff --git a/conformance.tex b/conformance.tex
> > index 01ccd69..a07ef02 100644
> > --- a/conformance.tex
> > +++ b/conformance.tex
> > @@ -32,8 +32,9 @@ \section{Conformance Targets}\label{sec:Conformance /
> > Conformance Targets}
> > \ref{sec:Conformance / Driver Conformance / Memory Driver Conformance},
> > \ref{sec:Conformance / Driver Conformance / I2C Adapter Driver
> > Conformance},
> > \ref{sec:Conformance / Driver Conformance / SCMI Driver Conformance},
> > -\ref{sec:Conformance / Driver Conformance / GPIO Driver Conformance} or
> > -\ref{sec:Conformance / Driver Conformance / PMEM Driver Conformance}.
> > +\ref{sec:Conformance / Driver Conformance / GPIO Driver Conformance},
> > +\ref{sec:Conformance / Driver Conformance / PMEM Driver Conformance} or
> > +\ref{sec:Conformance / Driver Conformance / CAN Driver Conformance}.
> > \item Clause \ref{sec:Conformance / Legacy Interface: Transitional
> > Device and Transitional Driver Conformance}.
> > \end{itemize}
> > @@ -59,8 +60,9 @@ \section{Conformance Targets}\label{sec:Conformance /
> > Conformance Targets}
> > \ref{sec:Conformance / Device Conformance / Memory Device Conformance},
> > \ref{sec:Conformance / Device Conformance / I2C Adapter Device
> > Conformance},
> > \ref{sec:Conformance / Device Conformance / SCMI Device Conformance},
> > -\ref{sec:Conformance / Device Conformance / GPIO Device Conformance} or
> > -\ref{sec:Conformance / Device Conformance / PMEM Device Conformance}.
> > +\ref{sec:Conformance / Device Conformance / GPIO Device Conformance},
> > +\ref{sec:Conformance / Device Conformance / PMEM Device Conformance} or
> > +\ref{sec:Conformance / Device Conformance / CAN Device Conformance}.
> > \item Clause \ref{sec:Conformance / Legacy Interface: Transitional
> > Device and Transitional Driver Conformance}.
> > \end{itemize}
> > @@ -152,6 +154,7 @@ \section{Conformance Targets}\label{sec:Conformance /
> > Conformance Targets}
> > \input{device-types/scmi/driver-conformance.tex}
> > \input{device-types/gpio/driver-conformance.tex}
> > \input{device-types/pmem/driver-conformance.tex}
> > +\input{device-types/can/driver-conformance.tex}
> > \conformance{\section}{Device Conformance}\label{sec:Conformance / Device
> > Conformance}
> > @@ -238,6 +241,7 @@ \section{Conformance Targets}\label{sec:Conformance /
> > Conformance Targets}
> > \input{device-types/scmi/device-conformance.tex}
> > \input{device-types/gpio/device-conformance.tex}
> > \input{device-types/pmem/device-conformance.tex}
> > +\input{device-types/can/device-conformance.tex}
> > \conformance{\section}{Legacy Interface: Transitional Device and
> > Transitional Driver Conformance}\label{sec:Conformance / Legacy Interface:
> > Transitional Device and Transitional Driver Conformance}
> > A
[virtio-dev] Re: [virtio-comment] [RFC PATCH v3] virtio-can: Device specification.
Hello Mikail,
On Mon, Jan 08, 2024 at 06:18:50PM +0100, Mikhail Golubev-Ciuchea wrote:
> Hi all!
>
> I kindly request a vote.
>
> Fixes: https://github.com/oasis-tcs/virtio-spec/issues/186
>
>
> Best wishes,
> Mikhail Golubev-Ciuchea
>
>
>
> On 6/9/23 16:22, Mikhail Golubev-Ciuchea wrote:
> > From: Harald Mommer
> >
> > virtio-can is a virtual CAN device. It provides a way to give access to
> > a CAN controller from a driver guest. The device is aimed to be used by
> > driver guests running a HLOS as well as by driver guests running a
> > typical RTOS as used in controller environments.
> >
> > Signed-off-by: Harald Mommer
> > Signed-off-by: Mikhail Golubev-Ciuchea
> >
> > ---
> >
> > RFC v3:
> > * Add length fields in CAN RX and TX messages.
> > * Replace bus off indication queue with a config space bit.
> > * Clarify handling of unknown flag bits set in CAN frame.
> > * Remove MISRA C suffixes in constants.
> > * Reserve 16 bits in RX/TX messages for CAN XL priority.
> > * Reserve 8 bits in RX/TX messages for CAN classic DLC.
> > * Rework according to general virtio spec POV.
> > * Implementation:
> >driver:
> > https://lore.kernel.org/all/20230607145613.133203-1-mikhail.golubev-ciuc...@opensynergy.com/
> >QEmu device:
> > https://github.com/OpenSynergy/qemu/tree/virtio-can-spec-rfc-v3
> >
> > RFC v2:
> > * Add CAN classic feature flag.
> > * Add feature flag VIRTIO_CAN_F_LATE_TX_ACK.
> > * Add feature flag VIRTIO_CAN_F_RTR_FRAMES.
> > * Reserve 32 bits in RX/TX messages.
> > * Remove priorities of messages.
> >
> > conformance.tex | 12 +-
> > content.tex | 1 +
> > device-types/can/description.tex| 249
> > device-types/can/device-conformance.tex | 8 +
> > device-types/can/driver-conformance.tex | 7 +
> > introduction.tex| 2 +
> > 6 files changed, 275 insertions(+), 4 deletions(-)
> > create mode 100644 device-types/can/description.tex
> > create mode 100644 device-types/can/device-conformance.tex
> > create mode 100644 device-types/can/driver-conformance.tex
> >
> > diff --git a/conformance.tex b/conformance.tex
> > index 01ccd69..a07ef02 100644
> > --- a/conformance.tex
> > +++ b/conformance.tex
> > @@ -32,8 +32,9 @@ \section{Conformance Targets}\label{sec:Conformance /
> > Conformance Targets}
> > \ref{sec:Conformance / Driver Conformance / Memory Driver Conformance},
> > \ref{sec:Conformance / Driver Conformance / I2C Adapter Driver
> > Conformance},
> > \ref{sec:Conformance / Driver Conformance / SCMI Driver Conformance},
> > -\ref{sec:Conformance / Driver Conformance / GPIO Driver Conformance} or
> > -\ref{sec:Conformance / Driver Conformance / PMEM Driver Conformance}.
> > +\ref{sec:Conformance / Driver Conformance / GPIO Driver Conformance},
> > +\ref{sec:Conformance / Driver Conformance / PMEM Driver Conformance} or
> > +\ref{sec:Conformance / Driver Conformance / CAN Driver Conformance}.
> > \item Clause \ref{sec:Conformance / Legacy Interface: Transitional
> > Device and Transitional Driver Conformance}.
> > \end{itemize}
> > @@ -59,8 +60,9 @@ \section{Conformance Targets}\label{sec:Conformance /
> > Conformance Targets}
> > \ref{sec:Conformance / Device Conformance / Memory Device Conformance},
> > \ref{sec:Conformance / Device Conformance / I2C Adapter Device
> > Conformance},
> > \ref{sec:Conformance / Device Conformance / SCMI Device Conformance},
> > -\ref{sec:Conformance / Device Conformance / GPIO Device Conformance} or
> > -\ref{sec:Conformance / Device Conformance / PMEM Device Conformance}.
> > +\ref{sec:Conformance / Device Conformance / GPIO Device Conformance},
> > +\ref{sec:Conformance / Device Conformance / PMEM Device Conformance} or
> > +\ref{sec:Conformance / Device Conformance / CAN Device Conformance}.
> > \item Clause \ref{sec:Conformance / Legacy Interface: Transitional
> > Device and Transitional Driver Conformance}.
> > \end{itemize}
> > @@ -152,6 +154,7 @@ \section{Conformance Targets}\label{sec:Conformance /
> > Conformance Targets}
> > \input{device-types/scmi/driver-conformance.tex}
> > \input{device-types/gpio/driver-conformance.tex}
> > \input{device-types/pmem/driver-conformance.tex}
> > +\input{device-types/can/driver-conformance.tex}
> > \conformance{\section}{Device Conformance}\label{sec:Conformance / Device
> > Conformance}
> > @@ -238,6 +241,7 @@ \section{Conformance Targets}\label{sec:Conformance /
> > Conformance Targets}
> > \input{device-types/scmi/device-conformance.tex}
> > \input{device-types/gpio/device-conformance.tex}
> > \input{device-types/pmem/device-conformance.tex}
> > +\input{device-types/can/device-conformance.tex}
> > \conformance{\section}{Legacy Interface: Transitional Device and
> > Transitional Driver Conformance}\label{sec:Conformance / Legacy Interface:
> > Transitional Device and Transitional Driver Conformance}
[virtio-dev] Re: [virtio-comment] [RFC PATCH v3] virtio-can: Device specification.
On Mon, Jan 15 2024, Cornelia Huck wrote: > On Mon, Jan 08 2024, Mikhail Golubev-Ciuchea > wrote: > >> Hi all! >> >> I kindly request a vote. >> >> Fixes: https://github.com/oasis-tcs/virtio-spec/issues/186 > > Oh, that has been a while... I believe that this still fits on top, > although it has conflicts with virtio-spi, but nothing that a bit of > fiddling can't sort out. > > The main problem is that we're currently in a bit of an unfortunate > situation regarding voting: There's still a twice-postponed migration of > the OASIS infrastructure coming up, and I don't want to risk the voting > period being affected by an outage... hopefully we'll get a new schedule > soon. > > In the meanwhile, if anyone could spare a few cycles looking at this, > it'd be appreciated. Nothing jumped out at me, but I'm not a CAN expert; > I'd be happy to open voting but for the looming migration issue. OK, I'll just go ahead and open a vote, no reason to drag this out further, and hopefully we're done by the time the migration _really_ happens... - To unsubscribe, e-mail: virtio-dev-unsubscr...@lists.oasis-open.org For additional commands, e-mail: virtio-dev-h...@lists.oasis-open.org
[virtio-dev] Re: [virtio-comment] [RFC PATCH v3] virtio-can: Device specification.
On Mon, Jan 08 2024, Mikhail Golubev-Ciuchea wrote: > Hi all! > > I kindly request a vote. > > Fixes: https://github.com/oasis-tcs/virtio-spec/issues/186 Oh, that has been a while... I believe that this still fits on top, although it has conflicts with virtio-spi, but nothing that a bit of fiddling can't sort out. The main problem is that we're currently in a bit of an unfortunate situation regarding voting: There's still a twice-postponed migration of the OASIS infrastructure coming up, and I don't want to risk the voting period being affected by an outage... hopefully we'll get a new schedule soon. In the meanwhile, if anyone could spare a few cycles looking at this, it'd be appreciated. Nothing jumped out at me, but I'm not a CAN expert; I'd be happy to open voting but for the looming migration issue. - To unsubscribe, e-mail: virtio-dev-unsubscr...@lists.oasis-open.org For additional commands, e-mail: virtio-dev-h...@lists.oasis-open.org
[virtio-dev] Re: [virtio-comment] [RFC PATCH v3] virtio-can: Device specification.
Hi all!
I kindly request a vote.
Fixes: https://github.com/oasis-tcs/virtio-spec/issues/186
Best wishes,
Mikhail Golubev-Ciuchea
On 6/9/23 16:22, Mikhail Golubev-Ciuchea wrote:
From: Harald Mommer
virtio-can is a virtual CAN device. It provides a way to give access to
a CAN controller from a driver guest. The device is aimed to be used by
driver guests running a HLOS as well as by driver guests running a
typical RTOS as used in controller environments.
Signed-off-by: Harald Mommer
Signed-off-by: Mikhail Golubev-Ciuchea
---
RFC v3:
* Add length fields in CAN RX and TX messages.
* Replace bus off indication queue with a config space bit.
* Clarify handling of unknown flag bits set in CAN frame.
* Remove MISRA C suffixes in constants.
* Reserve 16 bits in RX/TX messages for CAN XL priority.
* Reserve 8 bits in RX/TX messages for CAN classic DLC.
* Rework according to general virtio spec POV.
* Implementation:
driver:
https://lore.kernel.org/all/20230607145613.133203-1-mikhail.golubev-ciuc...@opensynergy.com/
QEmu device: https://github.com/OpenSynergy/qemu/tree/virtio-can-spec-rfc-v3
RFC v2:
* Add CAN classic feature flag.
* Add feature flag VIRTIO_CAN_F_LATE_TX_ACK.
* Add feature flag VIRTIO_CAN_F_RTR_FRAMES.
* Reserve 32 bits in RX/TX messages.
* Remove priorities of messages.
conformance.tex | 12 +-
content.tex | 1 +
device-types/can/description.tex| 249
device-types/can/device-conformance.tex | 8 +
device-types/can/driver-conformance.tex | 7 +
introduction.tex| 2 +
6 files changed, 275 insertions(+), 4 deletions(-)
create mode 100644 device-types/can/description.tex
create mode 100644 device-types/can/device-conformance.tex
create mode 100644 device-types/can/driver-conformance.tex
diff --git a/conformance.tex b/conformance.tex
index 01ccd69..a07ef02 100644
--- a/conformance.tex
+++ b/conformance.tex
@@ -32,8 +32,9 @@ \section{Conformance Targets}\label{sec:Conformance /
Conformance Targets}
\ref{sec:Conformance / Driver Conformance / Memory Driver Conformance},
\ref{sec:Conformance / Driver Conformance / I2C Adapter Driver Conformance},
\ref{sec:Conformance / Driver Conformance / SCMI Driver Conformance},
-\ref{sec:Conformance / Driver Conformance / GPIO Driver Conformance} or
-\ref{sec:Conformance / Driver Conformance / PMEM Driver Conformance}.
+\ref{sec:Conformance / Driver Conformance / GPIO Driver Conformance},
+\ref{sec:Conformance / Driver Conformance / PMEM Driver Conformance} or
+\ref{sec:Conformance / Driver Conformance / CAN Driver Conformance}.
\item Clause \ref{sec:Conformance / Legacy Interface: Transitional Device and Transitional Driver Conformance}.
\end{itemize}
@@ -59,8 +60,9 @@ \section{Conformance Targets}\label{sec:Conformance /
Conformance Targets}
\ref{sec:Conformance / Device Conformance / Memory Device Conformance},
\ref{sec:Conformance / Device Conformance / I2C Adapter Device Conformance},
\ref{sec:Conformance / Device Conformance / SCMI Device Conformance},
-\ref{sec:Conformance / Device Conformance / GPIO Device Conformance} or
-\ref{sec:Conformance / Device Conformance / PMEM Device Conformance}.
+\ref{sec:Conformance / Device Conformance / GPIO Device Conformance},
+\ref{sec:Conformance / Device Conformance / PMEM Device Conformance} or
+\ref{sec:Conformance / Device Conformance / CAN Device Conformance}.
\item Clause \ref{sec:Conformance / Legacy Interface: Transitional Device and Transitional Driver Conformance}.
\end{itemize}
@@ -152,6 +154,7 @@ \section{Conformance Targets}\label{sec:Conformance /
Conformance Targets}
\input{device-types/scmi/driver-conformance.tex}
\input{device-types/gpio/driver-conformance.tex}
\input{device-types/pmem/driver-conformance.tex}
+\input{device-types/can/driver-conformance.tex}
\conformance{\section}{Device Conformance}\label{sec:Conformance / Device Conformance}
@@ -238,6 +241,7 @@ \section{Conformance Targets}\label{sec:Conformance / Conformance Targets}
\input{device-types/scmi/device-conformance.tex}
\input{device-types/gpio/device-conformance.tex}
\input{device-types/pmem/device-conformance.tex}
+\input{device-types/can/device-conformance.tex}
\conformance{\section}{Legacy Interface: Transitional Device and Transitional Driver Conformance}\label{sec:Conformance / Legacy Interface: Transitional Device and Transitional Driver Conformance}
A conformant implementation MUST be either transitional or
diff --git a/content.tex b/content.tex
index d2ab9eb..8806b57 100644
--- a/content.tex
+++ b/content.tex
@@ -765,6 +765,7 @@ \chapter{Device Types}\label{sec:Device Types}
\input{device-types/scmi/description.tex}
\input{device-types/gpio/description.tex}
\input{device-types/pmem/description.tex}
+\input{device-types/can/description.tex}
\chapter{Reserved Feature Bits}\label{sec:Reserved Feature
