kernel/linux.git/drivers/misc/enclosure.c, branch v6.1.168

misc: enclosure: replace snprintf in show functions with sysfs_emit

2021-10-22T09:25:39+00:00

coccicheck complains about the use of snprintf() in sysfs show functions: WARNING use scnprintf or sprintf Use sysfs_emit instead of scnprintf or sprintf makes more sense. Reported-by: Zeal Robot Signed-off-by: Ye Guojin Link: https://lore.kernel.org/r/20211022090604.1065367-1-ye.guojin@zte.com.cn Signed-off-by: Greg Kroah-Hartman

misc: enclosure: Update enclosure_remove_device() documentation to match reality

2020-07-01T13:05:37+00:00

enclosure_remove_device() hasn't taken an 'int component for over a decade. Instead use kerneldoc to describe the 'struct device' actually passed in. Fixes the following W=1 kernel build warning(s): drivers/misc/enclosure.c:400: warning: Function parameter or member 'dev' not described in 'enclosure_remove_device' drivers/misc/enclosure.c:400: warning: Excess function parameter 'num' description in 'enclosure_remove_device' Cc: James Bottomley Signed-off-by: Lee Jones Link: https://lore.kernel.org/r/20200701085853.164358-16-lee.jones@linaro.org Signed-off-by: Greg Kroah-Hartman

misc: enclosure: Fix some kerneldoc anomalies

2020-07-01T13:05:37+00:00

Firstly some missing function argument documentation, then some whch are present, but are incorrectly named. Fixes the following W=1 kernel build warnings: drivers/misc/enclosure.c:115: warning: Function parameter or member 'name' not described in 'enclosure_register' drivers/misc/enclosure.c:115: warning: Function parameter or member 'cb' not described in 'enclosure_register' drivers/misc/enclosure.c:283: warning: Function parameter or member 'number' not described in 'enclosure_component_alloc' drivers/misc/enclosure.c:283: warning: Excess function parameter 'num' description in 'enclosure_component_alloc' drivers/misc/enclosure.c:363: warning: Function parameter or member 'component' not described in 'enclosure_add_device' drivers/misc/enclosure.c:363: warning: Excess function parameter 'num' description in 'enclosure_add_device' drivers/misc/enclosure.c:398: warning: Function parameter or member 'dev' not described in 'enclosure_remove_device' drivers/misc/enclosure.c:398: warning: Excess function parameter 'num' description in 'enclosure_remove_device' Cc: James Bottomley Signed-off-by: Lee Jones Link: https://lore.kernel.org/r/20200701085853.164358-12-lee.jones@linaro.org Signed-off-by: Greg Kroah-Hartman

scsi: enclosure: Fix stale device oops with hot replug

2020-01-10T06:38:40+00:00

Doing an add/remove/add on a SCSI device in an enclosure leads to an oops caused by poisoned values in the enclosure device list pointers. The reason is because we are keeping the enclosure device across the enclosed device add/remove/add but the current code is doing a device_add/device_del/device_add on it. This is the wrong thing to do in sysfs, so fix it by not doing a device_del on the enclosure device simply because of a hot remove of the drive in the slot. [mkp: added missing email addresses] Fixes: 43d8eb9cfd0a ("[SCSI] ses: add support for enclosure component hot removal") Link: https://lore.kernel.org/r/1578532892.3852.10.camel@HansenPartnership.com Signed-off-by: James Bottomley Reported-by: Luo Jiaxing Tested-by: John Garry Signed-off-by: Martin K. Petersen

treewide: Replace GPLv2 boilerplate/reference with SPDX - rule 176

2019-05-30T18:29:19+00:00

Based on 1 normalized pattern(s): this program is free software you can redistribute it and or modify it under the terms of the gnu general public license version 2 as published by the free software foundation this program is distributed in the hope that it will be useful but without any warranty without even the implied warranty of merchantability or fitness for a particular purpose see the gnu general public license for more details you should have received a copy of the gnu general public license along with this program if not write to the free software foundation inc 675 mass ave cambridge ma 02139 usa extracted by the scancode license scanner the SPDX license identifier GPL-2.0-only has been chosen to replace the boilerplate/reference in 44 file(s). Signed-off-by: Thomas Gleixner Reviewed-by: Allison Randal Reviewed-by: Steve Winslow Reviewed-by: Alexios Zavras Cc: linux-spdx@vger.kernel.org Link: https://lkml.kernel.org/r/20190528170025.980374610@linutronix.de Signed-off-by: Greg Kroah-Hartman

misc: enclosure: Use struct_size() in kzalloc()

2019-01-18T15:34:06+00:00

One of the more common cases of allocation size calculations is finding the size of a structure that has a zero-sized array at the end, along with memory for some number of elements for that array. For example: struct foo { int stuff; void *entry[]; }; instance = kzalloc(sizeof(struct foo) + sizeof(void *) * count, GFP_KERNEL); Instead of leaving these open-coded and prone to type mistakes, we can now use the new struct_size() helper: instance = kzalloc(struct_size(instance, entry, count), GFP_KERNEL); This code was detected with the help of Coccinelle. Signed-off-by: Gustavo A. R. Silva Signed-off-by: Greg Kroah-Hartman

misc: enclosure: Remove unnecessary error check

2017-12-07T17:45:31+00:00

It is not necessary to check return value of class_register. enclosure_init returns both successful and error value. Signed-off-by: Arvind Yadav Signed-off-by: Greg Kroah-Hartman

misc: enclosure: Fix space before '[' error

2017-12-07T17:45:31+00:00

Fix checkpatch.pl error: ERROR: space prohibited before open square bracket '['. Signed-off-by: Arvind Yadav Signed-off-by: Greg Kroah-Hartman

scsi: ses: do not add a device to an enclosure if enclosure_add_links() fails.

2017-07-01T20:52:38+00:00

The enclosure_add_device() function should fail if it can't create the relevant sysfs links. Cc: Signed-off-by: Maurizio Lombardi Tested-by: Douglas Miller Acked-by: James Bottomley Signed-off-by: Martin K. Petersen

scsi: ses: don't get power status of SES device slot on probe

2017-04-06T16:48:05+00:00

The commit 08024885a2a3 ("ses: Add power_status to SES device slot") introduced the 'power_status' attribute to enclosure components and the associated callbacks. There are 2 callbacks available to get the power status of a device: 1) ses_get_power_status() for 'struct enclosure_component_callbacks' 2) get_component_power_status() for the sysfs device attribute (these are available for kernel-space and user-space, respectively.) However, despite both methods being available to get power status on demand, that commit also introduced a call to get power status in ses_enclosure_data_process(). This dramatically increased the total probe time for SCSI devices on larger configurations, because ses_enclosure_data_process() is called several times during the SCSI devices probe and loops over the component devices (but that is another problem, another patch). That results in a tremendous continuous hammering of SCSI Receive Diagnostics commands to the enclosure-services device, which does delay the total probe time for the SCSI devices __significantly__: Originally, ~34 minutes on a system attached to ~170 disks: [ 9214.490703] mpt3sas version 13.100.00.00 loaded ... [11256.580231] scsi 17:0:177:0: qdepth(16), tagged(1), simple(0), ordered(0), scsi_level(6), cmd_que(1) With this patch, it decreased to ~2.5 minutes -- a 13.6x faster [ 1002.992533] mpt3sas version 13.100.00.00 loaded ... [ 1151.978831] scsi 11:0:177:0: qdepth(16), tagged(1), simple(0), ordered(0), scsi_level(6), cmd_que(1) Back to the commit discussion.. on the ses_get_power_status() call introduced in ses_enclosure_data_process(): impact of removing it. That may possibly be in place to initialize the power status value on device probe. However, those 2 functions available to retrieve that value _do_ automatically refresh/update it. So the potential benefit would be a direct access of the 'power_status' field which does not use the callbacks... But the only reader of 'struct enclosure_component::power_status' is the get_component_power_status() callback for sysfs attribute, and it _does_ check for and call the .get_power_status callback, (which indeed is defined and implemented by that commit), so the power status value is, again, automatically updated. So, the remaining potential for a direct/non-callback access to the power_status attribute would be out-of-tree modules -- well, for those, if they are for whatever reason interested in values that are set during device probe and not up-to-date by the time they need it.. well, that would be curious. Well, to handle that more properly, set the initial power state value to '-1' (i.e., uninitialized) instead of '1' (power 'on'), and check for it in that callback which may do an direct access to the field value _if_ a callback function is not defined. Signed-off-by: Mauricio Faria de Oliveira Fixes: 08024885a2a3 ("ses: Add power_status to SES device slot") Reviewed-by: Dan Williams Reviewed-by: Song Liu Signed-off-by: Martin K. Petersen