| 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: <1464748013-31309-22-git-send-email-david.kershner@unisys.com> Date: Tue, 31 May 2016 22:26:47 -0400 From: David Kershner <david.kershner@...sys.com> To: <corbet@....net>, <tglx@...utronix.de>, <mingo@...hat.com>, <hpa@...or.com>, <david.kershner@...sys.com>, <gregkh@...uxfoundation.org>, <erik.arfvidson@...sys.com>, <timothy.sell@...sys.com>, <hofrat@...dl.org>, <dzickus@...hat.com>, <jes.sorensen@...hat.com>, <alexander.curtin@...sys.com>, <janani.rvchndrn@...il.com>, <sudipm.mukherjee@...il.com>, <prarit@...hat.com>, <david.binder@...sys.com>, <nhorman@...hat.com>, <dan.j.williams@...el.com>, <linux-kernel@...r.kernel.org>, <linux-doc@...r.kernel.org>, <driverdev-devel@...uxdriverproject.org>, <sparmaintainer@...sys.com> Subject: [PATCH v2 21/27] staging: unisys: visorbus: make visorchipset function descriptions more kerneldoc-like From: David Binder <david.binder@...sys.com> Per audit feedback from Thomas Gleixner, function descriptions in visorchipset.c now utilize a more kerneldoc-like formatting. The affected comments do not implement other kerneldoc requirements. Signed-off-by: David Binder <david.binder@...sys.com> Signed-off-by: David Kershner <david.kershner@...sys.com> Reviewed-by: Tim Sell <Timothy.Sell@...sys.com> --- drivers/staging/unisys/visorbus/visorchipset.c | 41 +++++++++++++++----------- 1 file changed, 24 insertions(+), 17 deletions(-) diff --git a/drivers/staging/unisys/visorbus/visorchipset.c b/drivers/staging/unisys/visorbus/visorchipset.c index 1da980f..189ba40 100644 --- a/drivers/staging/unisys/visorbus/visorchipset.c +++ b/drivers/staging/unisys/visorbus/visorchipset.c @@ -1300,7 +1300,8 @@ my_device_destroy(struct controlvm_message *inmsg) inmsg->hdr.flags.response_expected == 1, 1); } -/* When provided with the physical address of the controlvm channel +/** + * When provided with the physical address of the controlvm channel * (phys_addr), the offset to the payload area we need to manage * (offset), and the size of this payload area (bytes), fills in the * controlvm_payload_info struct. Returns true for success or false @@ -1368,8 +1369,9 @@ initialize_controlvm_payload(void) &controlvm_payload_info); } -/* Send ACTION=online for DEVPATH=/sys/devices/platform/visorchipset. - * Returns CONTROLVM_RESP_xxx code. +/** + * Send ACTION=online for DEVPATH=/sys/devices/platform/visorchipset. + * Returns CONTROLVM_RESP_xxx code. */ static int visorchipset_chipset_ready(void) @@ -1390,8 +1392,9 @@ visorchipset_chipset_selftest(void) return CONTROLVM_RESP_SUCCESS; } -/* Send ACTION=offline for DEVPATH=/sys/devices/platform/visorchipset. - * Returns CONTROLVM_RESP_xxx code. +/** + * Send ACTION=offline for DEVPATH=/sys/devices/platform/visorchipset. + * Returns CONTROLVM_RESP_xxx code. */ static int visorchipset_chipset_notready(void) @@ -1433,7 +1436,8 @@ chipset_notready(struct controlvm_message_header *msg_hdr) controlvm_respond(msg_hdr, rc); } -/* This is your "one-stop" shop for grabbing the next message from the +/** + * This is your "one-stop" shop for grabbing the next message from the * CONTROLVM_QUEUE_EVENT queue in the controlvm channel. */ static bool @@ -1464,7 +1468,7 @@ read_controlvm_event(struct controlvm_message *msg) #define PARAHOTPLUG_TIMEOUT_MS 2000 -/* +/** * Generate unique int to match an outstanding CONTROLVM message with a * udev script /proc response */ @@ -1476,7 +1480,7 @@ parahotplug_next_id(void) return atomic_inc_return(&id); } -/* +/** * Returns the time (in jiffies) when a CONTROLVM message on the list * should expire -- PARAHOTPLUG_TIMEOUT_MS in the future */ @@ -1486,7 +1490,7 @@ parahotplug_next_expiration(void) return jiffies + msecs_to_jiffies(PARAHOTPLUG_TIMEOUT_MS); } -/* +/** * Create a parahotplug_request, which is basically a wrapper for a * CONTROLVM_MESSAGE that we can stick on a list */ @@ -1506,7 +1510,7 @@ parahotplug_request_create(struct controlvm_message *msg) return req; } -/* +/** * Free a parahotplug_request. */ static void @@ -1515,7 +1519,7 @@ parahotplug_request_destroy(struct parahotplug_request *req) kfree(req); } -/* +/** * Cause uevent to run the user level script to do the disable/enable * specified in (the CONTROLVM message in) the specified * parahotplug_request @@ -1545,7 +1549,7 @@ parahotplug_request_kickoff(struct parahotplug_request *req) envp); } -/* +/** * Remove any request from the list that's been on there too long and * respond with an error. */ @@ -1576,7 +1580,7 @@ parahotplug_process_list(void) spin_unlock(¶hotplug_request_list_lock); } -/* +/** * Called from the /proc handler, which means the user script has * finished the enable/disable. Find the matching identifier, and * respond to the CONTROLVM message with success. @@ -1613,7 +1617,7 @@ parahotplug_request_complete(int id, u16 active) return -EINVAL; } -/* +/** * Enables or disables a PCI device by kicking off a udev script */ static void @@ -1656,7 +1660,8 @@ parahotplug_process_message(struct controlvm_message *inmsg) } } -/* Process a controlvm message. +/** + * Process a controlvm message. * Return result: * false - this function will return false only in the case where the * controlvm message was NOT processed, but processing must be @@ -2024,7 +2029,8 @@ device_resume_response(struct visor_device *dev_info, int response) dev_info->pending_msg_hdr = NULL; } -/* The parahotplug/devicedisabled interface gets called by our support script +/** + * The parahotplug/devicedisabled interface gets called by our support script * when an SR-IOV device has been shut down. The ID is passed to the script * and then passed back when the device has been removed. */ @@ -2041,7 +2047,8 @@ static ssize_t devicedisabled_store(struct device *dev, return count; } -/* The parahotplug/deviceenabled interface gets called by our support script +/** + * The parahotplug/deviceenabled interface gets called by our support script * when an SR-IOV device has been recovered. The ID is passed to the script * and then passed back when the device has been brought back up. */ -- 1.9.1
Powered by blists - more mailing lists