[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: [RFC PATCH] virtio-rtc: Add device specification.
This is a partial draft for a Real-Time Clock (RTC) device. The
virtio-rtc device provides information about current time through one or
more clocks.
It is planned to add a timer/alarm feature as part of a draft spec
update.
The draft uses the "Timer/Clock" device id which is already part of the
specification. This device id was registered a long time ago and should
be unused according to the author's information. The name "RTC" was
determined to be the best for a device which focuses on current time,
but is up to discussion.
For this device, there is a prototypical Linux kernel driver for which
upstreaming is planned, and a proprietary device implementation.
In the spec text, there is some redundancy between the informative and
the normative text. The intent is that the informative text already
gives all the essential information about the device.
In the spec, clock ids are 64 bit wide to have unique ids when
supporting clock hot-plugging in the future.
Any feedback is appreciated very much.
Signed-off-by: Peter Hilber <peter.hilber@opensynergy.com>
---
conformance.tex | 2 +
content.tex | 3 +-
device-types/rtc/description.tex | 523 ++++++++++++++++++++++++
device-types/rtc/device-conformance.tex | 10 +
device-types/rtc/driver-conformance.tex | 9 +
5 files changed, 546 insertions(+), 1 deletion(-)
create mode 100644 device-types/rtc/description.tex
create mode 100644 device-types/rtc/device-conformance.tex
create mode 100644 device-types/rtc/driver-conformance.tex
diff --git a/conformance.tex b/conformance.tex
index 01ccd69..423dc7a 100644
--- a/conformance.tex
+++ b/conformance.tex
@@ -152,6 +152,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/rtc/driver-conformance.tex}
\conformance{\section}{Device Conformance}\label{sec:Conformance / Device Conformance}
@@ -238,6 +239,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/rtc/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 cff548a..7c2aefe 100644
--- a/content.tex
+++ b/content.tex
@@ -628,7 +628,7 @@ \chapter{Device Types}\label{sec:Device Types}
\hline
16 & GPU device \\
\hline
-17 & Timer/Clock device \\
+17 & RTC (Timer/Clock) device \\
\hline
18 & Input device \\
\hline
@@ -710,6 +710,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/rtc/description.tex}
\chapter{Reserved Feature Bits}\label{sec:Reserved Feature Bits}
diff --git a/device-types/rtc/description.tex b/device-types/rtc/description.tex
new file mode 100644
index 0000000..061f108
--- /dev/null
+++ b/device-types/rtc/description.tex
@@ -0,0 +1,523 @@
+\section{RTC Device}\label{sec:Device Types / RTC Device}
+
+The RTC (Real Time Clock) device provides information about current
+time. The device can provide different clocks, e.g.\ for the UTC or TAI
+time standards, or for physical time elapsed since some past epoch.
+Drivers can read the clocks with simple or more accurate methods.
+
+\subsection{Device ID}\label{sec:Device Types / RTC Device / Device ID}
+
+17
+
+\subsection{Virtqueues}\label{sec:Device Types / RTC Device / Virtqueues}
+
+\begin{description}
+\item[0] readq
+\item[1] controlq
+\end{description}
+
+The driver initiates clock readings through requests to the
+readq.\footnote{The readq is a dedicated virtqueue to facilitate
+reducing latency for clock readings, which may be more
+performance-sensitive than other requests.} The driver uses the controlq
+for other requests to the device.
+
+\subsection{Feature bits}\label{sec:Device Types / RTC Device / Feature bits}
+
+\begin{description}
+\item[VIRTIO_RTC_F_READ_CROSS (0)] Device supports cross-timestamping.
+\end{description}
+
+VIRTIO_RTC_F_READ_CROSS determines whether the device supports clock
+reading with cross-timestamping. Without this feature, the device does
+not support cross-timestamping. Even when this feature was negotiated,
+the device may still not support cross-timestamping for some clocks, or
+for particular requests.
+
+\devicenormative{\subsubsection}{Feature bits}{Device Types / RTC Device / Feature bits}
+
+The device SHOULD offer VIRTIO_RTC_F_READ_CROSS if the device can
+support cross-timestamping for any of its clocks.
+
+\subsection{Device configuration layout}\label{sec:Device Types / RTC Device / Device configuration layout}
+
+There is no configuration data for the device.
+
+\subsection{Device Initialization}\label{sec:Device Types / RTC Device / Device Initialization}
+
+The device determines the set of clocks. The device can provide zero or
+more clocks.
+
+\subsection{Device Operation}\label{sec:Device Types / RTC Device / Device Operation}
+
+For the readq and the controlq, the driver sends a message with a
+request, and receives the response in the device-writable part of the
+message. readq and controlq messages use common request and response
+headers.
+
+\begin{lstlisting}
+/* common request header */
+struct virtio_rtc_req_head {
+ __le16 msg_type;
+ __u8 reserved[2];
+};
+
+/* common response header */
+struct virtio_rtc_resp_head {
+ __u8 status;
+ __u8 reserved[3];
+};
+\end{lstlisting}
+
+The \field{msg_type} field identifies the message type.
+
+The \field{status} field indicates whether the device successfully
+executed the request. The device sets the \field{status} field to one of
+the following values:
+
+\begin{lstlisting}
+#define VIRTIO_RTC_S_OK 0
+#define VIRTIO_RTC_S_UNSUPP 1
+#define VIRTIO_RTC_S_NODEV 2
+#define VIRTIO_RTC_S_INVAL 3
+#define VIRTIO_RTC_S_DEVERR 4
+\end{lstlisting}
+
+VIRTIO_RTC_S_OK indicates that the device successfully executed the
+request.
+
+If \field{status} is not VIRTIO_RTC_S_OK, the value of the
+message-specific response fields is undefined.
+
+VIRTIO_RTC_S_UNSUPP indicates that the device could not execute the
+specific request due to an implementation limitation. The device also
+returns status VIRTIO_RTC_S_UNSUPP for message requests with unknown
+values in the message-specific \field{message_type} or
+\field{hw_counter} fields.
+
+VIRTIO_RTC_S_NODEV indicates that the \field{clock_id} field value
+supplied with the message request does not identify a clock.
+
+VIRTIO_RTC_S_INVAL indicates that
+
+\begin{itemize}
+\item the driver request values are not allowed by the specification or
+\item the device read-only part of the message, or device write-only
+ part of the message, is too small.
+\end{itemize}
+
+VIRTIO_RTC_S_DEVERR indicates that the device encountered an error while
+executing the request, which could not be attributed to invalid input
+from the driver.
+
+All \field{reserved} fields are written as zero, and their value is
+ignored.
+
+The set of clocks does not change after feature negotiation completion,
+until device reset. The set of clocks should not change on device reset
+either (similar to negotiated features). Clock identifiers are
+zero-based, dense indices. All fields named \field{clock_id} contain
+clock identifiers.
+
+\devicenormative{\subsubsection}{Device Operation}{Device Types / RTC Device / Device Operation}
+
+For \field{struct virtio_rtc_resp_head}, the device MUST set the
+\field{status} field to VIRTIO_RTC_S_OK if the device successfully
+executed the request.
+
+For \field{struct virtio_rtc_resp_head}, the device MUST set the
+\field{status} field to VIRTIO_RTC_S_UNSUPP if the device could not
+execute the specific request due to an implementation limitation.
+
+For \field{struct virtio_rtc_resp_head}, the device MUST set the
+\field{status} field to VIRTIO_RTC_S_UNSUPP for a request with a value
+of the \field{message_type} field which is neither described in this
+specification nor otherwise known to the implementation.
+
+For \field{struct virtio_rtc_resp_head}, the device MUST set the
+\field{status} field to VIRTIO_RTC_S_UNSUPP for a request with a value
+of the \field{hw_counter} field which is neither described in this
+specification nor otherwise known to the implementation.
+
+For \field{struct virtio_rtc_resp_head}, the device MUST set the
+\field{status} field to VIRTIO_RTC_S_NODEV if the \field{clock_id} field
+value supplied with the message request does not identify a clock.
+
+For \field{struct virtio_rtc_resp_head}, the device MUST set the
+\field{status} field to VIRTIO_RTC_S_INVAL if the request values are not
+allowed by the specification and none of the previous requirements in
+this document stipulated another \field{status}.
+
+For \field{struct virtio_rtc_resp_head}, the device MUST set the
+\field{status} field to VIRTIO_RTC_S_INVAL if the device read-only part
+of the message is too small.
+
+For \field{struct virtio_rtc_resp_head}, the device MUST set the
+\field{status} field to VIRTIO_RTC_S_INVAL if the device write-only part
+of the message is too small, unless the \field{status} field does not
+fit into the device write-only part.
+
+For \field{struct virtio_rtc_resp_head}, the device MUST set the
+\field{status} field to VIRTIO_RTC_S_DEVERR if none of the previous
+requirements in this document stipulated another \field{status}.
+
+If the device read-only part of a message M is bigger than the size of
+the request specified for message M, the device MUST ignore the
+additional space.
+
+If the device write-only part of a message M is bigger than the size of
+the response specified for message M, the device MUST ignore the
+additional space.
+
+The device MUST NOT interpret \emph{reserved} fields in the
+device-readable part of the message.
+
+The device MUST set \emph{reserved} fields in the device-writable part
+of the message to zero.
+
+After feature negotiation completion the device MUST NOT change the set
+of clocks until device reset.
+
+The device SHOULD NOT change the set of clocks on a device reset after
+the first device reset.
+
+The device MUST use non-negative integers, which are smaller than the
+number of clocks, as clock identifiers.
+
+\drivernormative{\subsubsection}{Device Operation}{Device Types / RTC Device / Device Operation}
+
+If the \field{struct virtio_rtc_resp_head} field \field{status} is not
+VIRTIO_RTC_S_OK, the driver MUST NOT interpret response fields other
+than \field{status}.
+
+The driver MUST set \emph{reserved} fields in the device-readable part
+of the message to zero.
+
+The driver MUST NOT interpret \emph{reserved} fields in the
+device-writable part of the message.
+
+\subsubsection{controlq Operation}\label{sec:Device Types / RTC Device / Device Operation / controlq Operation}
+
+The driver uses the controlq for all requests to the device, other than
+clock readings.
+
+\begin{description}
+
+\item[VIRTIO_RTC_M_CFG] discovers the number of clocks.
+
+\begin{lstlisting}
+#define VIRTIO_RTC_M_CFG 0x1000 /* message type */
+
+struct virtio_rtc_req_cfg {
+ struct virtio_rtc_req_head head;
+ /* no request params */
+ __u8 reserved[4];
+};
+
+struct virtio_rtc_resp_cfg {
+ struct virtio_rtc_resp_head head;
+ __le16 num_clocks;
+ __u8 reserved[10];
+};
+\end{lstlisting}
+
+Field \field{num_clocks} contains the number of clocks. A device
+provides zero or more clocks. Valid clock ids are those smaller than
+\field{num_clocks}.
+
+\item[VIRTIO_RTC_M_CLOCK_CAP] discovers the capabilities of the clock
+identified by the \field{clock_id} field.
+
+\begin{lstlisting}
+#define VIRTIO_RTC_M_CLOCK_CAP 0x1001 /* message type */
+
+struct virtio_rtc_req_clock_cap {
+ struct virtio_rtc_req_head head;
+ __u8 reserved[4];
+ __le64 clock_id;
+};
+
+struct virtio_rtc_resp_clock_cap {
+ struct virtio_rtc_resp_head head;
+ __le16 type;
+ __u8 reserved[10];
+};
+\end{lstlisting}
+
+The \field{type} field identifies the clock type. A device provides
+zero or more clocks for a clock type. The following clock types are
+defined:
+
+\begin{lstlisting}
+#define VIRTIO_RTC_CLOCK_UTC 0
+#define VIRTIO_RTC_CLOCK_TAI 1
+#define VIRTIO_RTC_CLOCK_MONO 2
+\end{lstlisting}
+
+VIRTIO_RTC_CLOCK_UTC uses the UTC (Coordinated Universal Time) time
+standard. The device uses the time epoch of January 1, 1970, 00:00
+UTC. This is the same epoch as \emph{Unix time}.
+
+VIRTIO_RTC_CLOCK_TAI uses the TAI (International Atomic Time) time
+standard. The device uses the time epoch of January 1, 1970, 00:00
+TAI.
+
+VIRTIO_RTC_CLOCK_MONO uses monotonic physical time (SI seconds
+subdivisions) since some unspecified epoch. The VIRTIO_RTC_CLOCK_MONO
+epoch is before or during device reset.
+
+Additional clock types may be standardized in the future.
+Implementation-specific clock type definitions are not recommended and
+use a clock type id greater than or equal to 0xF000.
+
+\end{description}
+
+\devicenormative{\paragraph}{controlq Operation}{Device Types / RTC Device / Device Operation / controlq Operation}
+
+For a fixed controlq message request value V, the device SHOULD either,
+for every request with value V, always execute successfully, or, for
+every request with value V, always set a fixed \field{status} other than
+VIRTIO_RTC_S_OK.
+
+For any clock of type VIRTIO_RTC_CLOCK_UTC, the device MUST use the UTC
+time standard (Coordinated Universal Time).
+
+For any clock of type VIRTIO_RTC_CLOCK_UTC, the device MUST use the time
+epoch of January 1, 1970, 00:00 UTC.
+
+For any clock of type VIRTIO_RTC_CLOCK_TAI, the device MUST use the TAI
+time standard (International Atomic Time).
+
+For any clock of type VIRTIO_RTC_CLOCK_TAI, the device MUST use the time
+epoch of January 1, 1970, 00:00 TAI.
+
+For any clock of type VIRTIO_RTC_CLOCK_MONO, the device MUST use SI
+seconds subdivisions.
+
+For any clock of type VIRTIO_RTC_CLOCK_MONO, the device MUST use an
+epoch at a time instant before or during device reset.
+
+For message VIRTIO_RTC_M_CLOCK_CAP, the device MUST set \field{type} to
+one of the clock types defined in this specification, or to a value
+greater than or equal to 0xF000.
+
+\drivernormative{\paragraph}{controlq Operation}{Device Types / RTC Device / Device Operation / controlq Operation}
+
+The driver MUST put the request into the device-readable part of the
+controlq message.
+
+The driver MUST allocate enough space for the response in the
+device-writable part of the controlq message.
+
+\subsubsection{readq Operation}\label{sec:Device Types / RTC Device / Device Operation / readq Operation}
+
+The driver requests clock readings through readq messages. The device
+obtains device-side clock readings and forwards these clock readings to
+the driver. The driver may enhance and interpret the clock readings
+through methods which are beyond the scope of this specification.
+
+Once DRIVER_OK has been set, the device should continuously support
+reading every clock, even when a clock may yet have to be aligned to
+reference time sources.
+
+In general,
+
+\begin{itemize}
+\item clocks may jump backwards or forward, and
+\item the clock frequency may change. Clocks may be \emph{slewed},
+ i.e.\ clocks may run at a frequency other than their current
+ best frequency estimate.
+\end{itemize}
+
+E.g., a clock of type VIRTIO_RTC_CLOCK_UTC can insert UTC leap seconds.
+
+As long as a clock does not jump backwards, the driver clock readings
+increase monotonically:
+
+\begin{itemize}
+\item As long as a clock does not jump backwards in-between device-side
+ clock readings, the driver-side readings for that clock increase
+ monotonically as well, in the order in which the driver
+ marks readq messages as available.
+
+\item The device marks readq messages for the same clock as used in
+ the order in which the messages were marked as available.
+\end{itemize}
+
+For a clock of type VIRTIO_RTC_CLOCK_MONO, the device always returns
+monotonically increasing clock readings.
+
+The unit of all \field{clock_reading} fields is 1 nanosecond for all
+clock types which are part of the device specification so
+far.\footnote{For time epochs in year 1970 or later, this means that
+time until at least year 2553 can be represented in the \field{__le64
+clock_reading} fields.}
+
+\begin{description}
+
+\item[VIRTIO_RTC_M_READ] reads the clock identified by the
+\field{clock_id} field. The device supports this message for every
+clock.
+
+\begin{lstlisting}
+#define VIRTIO_RTC_M_READ 0x0001 /* message type */
+
+struct virtio_rtc_req_read {
+ struct virtio_rtc_req_head head;
+ __u8 reserved[4];
+ __le64 clock_id;
+};
+
+struct virtio_rtc_resp_read {
+ struct virtio_rtc_resp_head head;
+ __u8 reserved[4];
+ __le64 clock_reading;
+};
+\end{lstlisting}
+
+\field{clock_reading} is a device-side clock reading obtained after the
+message was marked as available.
+
+\item[VIRTIO_RTC_M_READ_CROSS] returns a cross-timestamp for the clock
+identified by the \field{clock_id} field.\footnote{Cross-timestamping
+is similar to the ptp_kvm mechanism in the Linux kernel.} This message
+may yield better performance than using VIRTIO_RTC_M_READ. If the
+VIRTIO_RTC_F_READ_CROSS feature has been negotiated, the driver can send
+the VIRTIO_RTC_M_READ_CROSS message.
+
+\begin{lstlisting}
+#define VIRTIO_RTC_M_READ_CROSS 0x0002 /* message type */
+
+struct virtio_rtc_req_read_cross {
+ struct virtio_rtc_req_head head;
+ __le16 hw_counter;
+ __u8 reserved[2];
+ __le64 clock_id;
+};
+
+struct virtio_rtc_resp_read_cross {
+ struct virtio_rtc_resp_head head;
+ __u8 reserved[4];
+ __le64 clock_reading;
+ __le64 counter_cycles;
+};
+\end{lstlisting}
+
+The \field{hw_counter} field specifies the hardware counter for which
+the driver requests a cross-timestamp.
+
+Cross-timestamping returns a \field{clock_reading}, and an associated
+hardware counter value, \field{counter_cycles}. The
+\field{counter_cycles} field is the approximate or precise value which
+the driver would have read at the \field{clock_reading} time instant
+from the hardware counter identified by \field{hw_counter}. How the
+device determines the value which the driver would have seen is beyond
+the scope of this specification.
+
+The following hardware counter identifiers are specified:
+
+\begin{lstlisting}
+/* Arm Generic Timer CNTVCT_EL0, Counter-timer Virtual Count register */
+#define VIRTIO_RTC_COUNTER_ARM_VIRT 0
+/* Arm Generic Timer CNTPCT_EL0, Counter-timer Physical Count register */
+#define VIRTIO_RTC_COUNTER_ARM_PHYS 1
+/* x86 Time-Stamp Counter */
+#define VIRTIO_RTC_COUNTER_X86_TSC 2
+\end{lstlisting}
+
+Additional hardware counter identifiers may be standardized in the
+future. Implementation-specific hardware counter identifiers are not
+recommended and are greater than or equal to 0xF000.
+
+Even if VIRTIO_RTC_F_READ_CROSS has been negotiated, the device may not
+support VIRTIO_RTC_M_READ_CROSS for a particular clock or for particular
+hardware counters.
+
+The driver determines whether VIRTIO_RTC_M_READ_CROSS is supported for a
+specific clock and \field{hw_counter} by requesting the message and
+testing that the status is VIRTIO_RTC_S_OK.
+
+\end{description}
+
+\devicenormative{\paragraph}{readq Operation}{Device Types / RTC Device / Device Operation / readq Operation}
+
+For a fixed readq message request value V, the device SHOULD either, for
+every request with value V, always execute successfully, or, for every
+request with value V, always set a fixed \field{status} other than
+VIRTIO_RTC_S_OK.
+
+The device SHOULD continuously support reading of all clocks once
+DRIVER_OK has been set.
+
+For any clock of type VIRTIO_RTC_CLOCK_UTC, the device MAY insert UTC
+leap seconds.
+
+For any clock of type VIRTIO_RTC_CLOCK_UTC, the device MAY smear UTC
+leap seconds through clock slewing.
+
+For any clock C and readq messages \emph{A} and \emph{B} which read C,
+\emph{A} being the message which the driver marks as available before
+\emph{B}, the device MUST obtain the \field{clock_reading} value for the
+message \emph{A} response before the \field{clock_reading} value for the
+message \emph{B} response, or the device MUST obtain the same
+\field{clock_reading} value for both \emph{A} and \emph{B}.
+
+For any clock C, the device MUST mark all readq messages reading C as
+used in the total order in which the driver marked the readq messages as
+available.
+
+For any clock C of type VIRTIO_RTC_CLOCK_MONO and readq messages
+\emph{A} and \emph{B} which read C, \emph{A} being the message which the
+driver marks as available before \emph{B}, the device MUST set the
+\field{clock_reading} value for the message \emph{B} response to a value
+greater than or equal to the \field{clock_reading} value for the message
+\emph{A} response.
+
+The device MUST support VIRTIO_RTC_M_READ for every clock.
+
+For message VIRTIO_RTC_M_READ and for any clock type listed in this
+specification, the device MUST use the nanosecond as unit for field
+\field{clock_reading}.
+
+For readq messages, the device MUST obtain the \field{clock_reading}
+response value after the message is marked as available.
+
+For message VIRTIO_RTC_M_READ_CROSS, the device MUST set
+\field{counter_cycles} to a value which approximates the value which the
+driver would have read from the hardware counter identified by
+\field{hw_counter} at the time instant when the device read the
+\field{clock_reading} value.
+
+For message VIRTIO_RTC_M_READ_CROSS, the device MUST set \field{status}
+to a value other than \field{VIRTIO_RTC_S_OK} if the device cannot
+determine the approximate value which the driver would have read from
+the hardware counter identified by \field{hw_counter} at the time
+instant when the device read the \field{clock_reading} value.
+
+For any clock C, and VIRTIO_RTC_M_READ_CROSS messages \emph{A} and
+\emph{B} which read C and which specify the same hardware counter
+\emph{H} through field \field{hw_counter}, \emph{A} being the message
+which the driver marks as available before \emph{B}, the device MUST set
+the \field{counter_cycles} value for \emph{B} to a value which \emph{H}
+shows after the \field{counter_cycles} value of \emph{A}, or the device
+MUST set the same \field{counter_cycles} value for \emph{A} and
+\emph{B}.
+
+For message VIRTIO_RTC_M_READ_CROSS and for any clock type listed in
+this specification, the device MUST use the nanosecond as unit for
+field \field{clock_reading}.
+
+\drivernormative{\paragraph}{readq Operation}{Device Types / RTC Device / Device Operation / readq Operation}
+
+The driver MUST put the request into the device-readable part of the
+readq message.
+
+The driver MUST allocate enough space for the response in the
+device-writable part of the readq message.
+
+If VIRTIO_RTC_F_READ_CROSS was not negotiated, the driver MUST NOT send
+the VIRTIO_RTC_M_READ_CROSS message.
+
+For VIRTIO_RTC_M_READ_CROSS, the driver MUST set \field{hw_counter} to
+one of the hardware counter identifiers defined in this specification,
+or to a value greater than or equal to 0xF000.
diff --git a/device-types/rtc/device-conformance.tex b/device-types/rtc/device-conformance.tex
new file mode 100644
index 0000000..85fdcd3
--- /dev/null
+++ b/device-types/rtc/device-conformance.tex
@@ -0,0 +1,10 @@
+\conformance{\subsection}{RTC Device Conformance}\label{sec:Conformance / Device Conformance / RTC Device Conformance}
+
+An RTC device MUST conform to the following normative statements:
+
+\begin{itemize}
+\item \ref{devicenormative:Device Types / RTC Device / Feature bits}
+\item \ref{devicenormative:Device Types / RTC Device / Device Operation}
+\item \ref{devicenormative:Device Types / RTC Device / Device Operation / controlq Operation}
+\item \ref{devicenormative:Device Types / RTC Device / Device Operation / readq Operation}
+\end{itemize}
diff --git a/device-types/rtc/driver-conformance.tex b/device-types/rtc/driver-conformance.tex
new file mode 100644
index 0000000..1894884
--- /dev/null
+++ b/device-types/rtc/driver-conformance.tex
@@ -0,0 +1,9 @@
+\conformance{\subsection}{RTC Driver Conformance}\label{sec:Conformance / Driver Conformance / RTC Driver Conformance}
+
+An RTC driver MUST conform to the following normative statements:
+
+\begin{itemize}
+\item \ref{drivernormative:Device Types / RTC Device / Device Operation}
+\item \ref{drivernormative:Device Types / RTC Device / Device Operation / controlq Operation}
+\item \ref{drivernormative:Device Types / RTC Device / Device Operation / readq Operation}
+\end{itemize}
base-commit: 8797f4d4e41032cea86b1a3a93df1bb5a9fd9a9b
--
2.37.2
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]