| lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
|
Open Source and information security mailing list archives
| ||
|
Message-Id: <782cd7c67056b1085c968b465cdbbdbdc2a5f7d3.1606823973.git.mchehab+huawei@kernel.org>
Date: Tue, 1 Dec 2020 13:09:01 +0100
From: Mauro Carvalho Chehab <mchehab+huawei@...nel.org>
To: Linux Doc Mailing List <linux-doc@...r.kernel.org>,
Jonathan Corbet <corbet@....net>
Cc: Mauro Carvalho Chehab <mchehab+huawei@...nel.org>,
Richard Gong <richard.gong@...ux.intel.com>,
linux-kernel@...r.kernel.org
Subject: [PATCH v5 08/16] firmware: stratix10-svc: fix kernel-doc markups
There are some common comments marked, instead, with kernel-doc
notation, which won't work.
While here, rename an identifier, in order to match the
function prototype below kernel-doc markup.
Acked-by: Richard Gong <richard.gong@...ux.intel.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@...nel.org>
---
include/linux/firmware/intel/stratix10-svc-client.h | 10 +++++-----
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git a/include/linux/firmware/intel/stratix10-svc-client.h b/include/linux/firmware/intel/stratix10-svc-client.h
index a93d85932eb9..ebc295647581 100644
--- a/include/linux/firmware/intel/stratix10-svc-client.h
+++ b/include/linux/firmware/intel/stratix10-svc-client.h
@@ -1,93 +1,93 @@
/* SPDX-License-Identifier: GPL-2.0 */
/*
* Copyright (C) 2017-2018, Intel Corporation
*/
#ifndef __STRATIX10_SVC_CLIENT_H
#define __STRATIX10_SVC_CLIENT_H
-/**
+/*
* Service layer driver supports client names
*
* fpga: for FPGA configuration
* rsu: for remote status update
*/
#define SVC_CLIENT_FPGA "fpga"
#define SVC_CLIENT_RSU "rsu"
-/**
+/*
* Status of the sent command, in bit number
*
* SVC_STATUS_OK:
* Secure firmware accepts the request issued by one of service clients.
*
* SVC_STATUS_BUFFER_SUBMITTED:
* Service client successfully submits data buffer to secure firmware.
*
* SVC_STATUS_BUFFER_DONE:
* Secure firmware completes data process, ready to accept the
* next WRITE transaction.
*
* SVC_STATUS_COMPLETED:
* Secure firmware completes service request successfully. In case of
* FPGA configuration, FPGA should be in user mode.
*
* SVC_COMMAND_STATUS_BUSY:
* Service request is still in process.
*
* SVC_COMMAND_STATUS_ERROR:
* Error encountered during the process of the service request.
*
* SVC_STATUS_NO_SUPPORT:
* Secure firmware doesn't support requested features such as RSU retry
* or RSU notify.
*/
#define SVC_STATUS_OK 0
#define SVC_STATUS_BUFFER_SUBMITTED 1
#define SVC_STATUS_BUFFER_DONE 2
#define SVC_STATUS_COMPLETED 3
#define SVC_STATUS_BUSY 4
#define SVC_STATUS_ERROR 5
#define SVC_STATUS_NO_SUPPORT 6
-/**
+/*
* Flag bit for COMMAND_RECONFIG
*
* COMMAND_RECONFIG_FLAG_PARTIAL:
* Set to FPGA configuration type (full or partial).
*/
#define COMMAND_RECONFIG_FLAG_PARTIAL 1
-/**
+/*
* Timeout settings for service clients:
* timeout value used in Stratix10 FPGA manager driver.
* timeout value used in RSU driver
*/
#define SVC_RECONFIG_REQUEST_TIMEOUT_MS 300
#define SVC_RECONFIG_BUFFER_TIMEOUT_MS 720
#define SVC_RSU_REQUEST_TIMEOUT_MS 300
struct stratix10_svc_chan;
/**
* enum stratix10_svc_command_code - supported service commands
*
* @COMMAND_NOOP: do 'dummy' request for integration/debug/trouble-shooting
*
* @COMMAND_RECONFIG: ask for FPGA configuration preparation, return status
* is SVC_STATUS_OK
*
* @COMMAND_RECONFIG_DATA_SUBMIT: submit buffer(s) of bit-stream data for the
* FPGA configuration, return status is SVC_STATUS_SUBMITTED or SVC_STATUS_ERROR
*
* @COMMAND_RECONFIG_DATA_CLAIM: check the status of the configuration, return
* status is SVC_STATUS_COMPLETED, or SVC_STATUS_BUSY, or SVC_STATUS_ERROR
*
* @COMMAND_RECONFIG_STATUS: check the status of the configuration, return
* status is SVC_STATUS_COMPLETED, or SVC_STATUS_BUSY, or SVC_STATUS_ERROR
*
* @COMMAND_RSU_STATUS: request remote system update boot log, return status
* is log data or SVC_STATUS_RSU_ERROR
*
* @COMMAND_RSU_UPDATE: set the offset of the bitstream to boot after reboot,
* return status is SVC_STATUS_OK or SVC_STATUS_ERROR
@@ -189,42 +189,42 @@ void stratix10_svc_free_channel(struct stratix10_svc_chan *chan);
/**
* stratix10_svc_allocate_memory() - allocate the momory
* @chan: service channel assigned to the client
* @size: number of bytes client requests
*
* Service layer allocates the requested number of bytes from the memory
* pool for the client.
*
* Return: the starting address of allocated memory on success, or
* ERR_PTR() on error.
*/
void *stratix10_svc_allocate_memory(struct stratix10_svc_chan *chan,
size_t size);
/**
* stratix10_svc_free_memory() - free allocated memory
* @chan: service channel assigned to the client
* @kaddr: starting address of memory to be free back to pool
*/
void stratix10_svc_free_memory(struct stratix10_svc_chan *chan, void *kaddr);
/**
* stratix10_svc_send() - send a message to the remote
* @chan: service channel assigned to the client
* @msg: message data to be sent, in the format of
* struct stratix10_svc_client_msg
*
* Return: 0 for success, -ENOMEM or -ENOBUFS on error.
*/
int stratix10_svc_send(struct stratix10_svc_chan *chan, void *msg);
/**
- * intel_svc_done() - complete service request
+ * stratix10_svc_done() - complete service request
* @chan: service channel assigned to the client
*
* This function is used by service client to inform service layer that
* client's service requests are completed, or there is an error in the
* request process.
*/
void stratix10_svc_done(struct stratix10_svc_chan *chan);
#endif
--
2.28.0
Powered by blists - more mailing lists