[Skiboot] [PATCH 006/110] doc: Make OPAL_RTC_READ docs pretty

Stewart Smith stewart at linux.ibm.com
Fri May 31 16:12:07 AEST 2019


Signed-off-by: Stewart Smith <stewart at linux.ibm.com>
---
 doc/opal-api/opal-rtc-read-3.rst | 32 ++++++++++++++++++--------------
 1 file changed, 18 insertions(+), 14 deletions(-)

diff --git a/doc/opal-api/opal-rtc-read-3.rst b/doc/opal-api/opal-rtc-read-3.rst
index f56cb2c96c5a..e2d492f2e0bf 100644
--- a/doc/opal-api/opal-rtc-read-3.rst
+++ b/doc/opal-api/opal-rtc-read-3.rst
@@ -1,3 +1,5 @@
+.. _OPAL_RTC_READ:
+
 OPAL_RTC_READ
 =============
 
@@ -24,15 +26,17 @@ Parameters
 
 Calling
 -------
-Since RTC calls can be pretty slow, OPAL_RTC_READ is likely to first return
-OPAL_BUSY_EVENT, requiring the caller to wait until the OPAL_EVENT_RTC event
+Since RTC calls can be pretty slow, :ref:`OPAL_RTC_READ` is likely to first return
+:ref:`OPAL_BUSY_EVENT`, requiring the caller to wait until the :ref:`OPAL_EVENT_RTC` event
 has been signaled. Once the event has been signaled, a subsequent
-OPAL_RTC_READ call will retrieve the time. Since the OPAL_EVENT_RTC event is
+:ref:`OPAL_RTC_READ` call will retrieve the time. Since the :ref:`OPAL_EVENT_RTC` event is
 used for both reading and writing the RTC, callers must be able to handle
-the event being signaled for a concurrent in flight OPAL_RTC_WRITE rather
+the event being signaled for a concurrent in flight :ref:`OPAL_RTC_WRITE` rather
 than this read request.
 
-The following code is one way to correctly issue and then wait for a response: ::
+The following code is one way to correctly issue and then wait for a response:
+
+.. code-block:: c
 
     int rc = OPAL_BUSY_EVENT;
     while (rc == OPAL_BUSY_EVENT) {
@@ -41,31 +45,31 @@ The following code is one way to correctly issue and then wait for a response: :
 	     opal_poll_events(NULL);
     }
 
-Although as of writing all OPAL_RTC_READ backends are asynchronous, there is
-no requirement for them to be - it is valid for OPAL_RTC_READ to immediately
-return the retreived value rather than OPAL_BUSY_EVENT.
+Although as of writing all :ref:`OPAL_RTC_READ` backends are asynchronous, there is
+no requirement for them to be - it is valid for :ref:`OPAL_RTC_READ` to immediately
+return the retreived value rather than :ref:`OPAL_BUSY_EVENT`.
 
 **TODO**: describe/document format of arguments.
 
 Return codes
 ------------
 
-OPAL_SUCCESS
+:ref:`OPAL_SUCCESS`
   parameters now contain the current time, or one read from cache.
 
-OPAL_HARDWARE
+:ref:`OPAL_HARDWARE`
   error in retrieving the time. May be transient error,
   may be permanent.
 
-OPAL_PARAMETER
+:ref:`OPAL_PARAMETER`
   year_month_day or hour_minute_second_millisecond parameters are NULL
 
-OPAL_INTERNAL_ERROR
+:ref:`OPAL_INTERNAL_ERROR`
   something went wrong, Possibly reported in error log.
   This can be a transient error
 
-OPAL_BUSY_EVENT
+:ref:`OPAL_BUSY_EVENT`
   request is in flight
 
-OPAL_BUSY
+:ref:`OPAL_BUSY`
   request may be in flight
-- 
2.21.0



More information about the Skiboot mailing list