kernel/linux.git/drivers/misc/enclosure.c, branch linux-4.20.y

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

enclosure: fix WARN_ON removing an adapter in multi-path devices

2015-03-31T05:53:36+00:00

We have peculiar problems with multi-path and enclosures: physically, we know each bay can only be occupied by a single disk device. However in multi-path, it appears we have many (because each path to the device appears in Linux as a different kernel device). We try to fix this by only having the last seen device show up in the bay. Sysfs gets very annoyed if we try to manipulate links when the kobject sysfs directory (kobj.sd) doesn't exist and drops a huge WARN_ON which most users panic and report an oops for. This happens on a few path removal situations and IBM reports seeing it when one of their multi-path adapters is removed. Add a check to enclosure device removal for the existence the sysfs directory containing both the forward and back links so that the remnants (if any) get removed in either direction but no scary warnings are dumped. Reported-by: Wen Xiong Tested-by: Wen Xiong Signed-off-by: James Bottomley

ses: Add power_status to SES device slot

2015-01-09T14:44:19+00:00

Add power_status to SES device slot, so we can power on/off the HDDs behind the enclosure. Check firmware status in ses_set_* before sending control pages to firmware. Signed-off-by: Song Liu Acked-by: Dan Williams Reviewed-by: Jens Axboe Cc: Hannes Reinecke Signed-off-by: Christoph Hellwig

ses: add reliable slot attribute

2015-01-09T14:44:19+00:00

The name provided by firmware is in a vendor specific format, publish the slot number to have a reliable mechanism for identifying slots across firmware implementations. If the enclosure does not provide a slot number fallback to the component number which is guaranteed unique, and usually mirrors the slot number. Cleaned up the unused ses_component.desc in the process. Signed-off-by: Dan Williams Signed-off-by: Song Liu Reviewed-by: Jens Axboe Reviewed-by: Hannes Reinecke Signed-off-by: Christoph Hellwig

ses: add enclosure logical id

2015-01-09T14:44:18+00:00

Export the NAA logical id for the enclosure. This is optionally available from the sas_transport_class, but it is really a property of the enclosure. Signed-off-by: Dan Williams Signed-off-by: Song Liu Reviewed-by: Jens Axboe Cc: Hannes Reinecke Signed-off-by: Christoph Hellwig

ses: close potential registration race

2015-01-09T14:44:17+00:00

The slot and address fields have a small window of instability when userspace can read them before initialization. Separate enclosure_component allocation from registration. Signed-off-by: Dan Williams Signed-off-by: Song Liu Reviewed-by: Jens Axboe Cc: Hannes Reinecke Signed-off-by: Christoph Hellwig

enclosure: handle non-unique element descriptors

2014-11-12T10:15:55+00:00

Some SES devices give non-unique Element Descriptors as part of the Element Descriptor diag page. Since we use these for creating sysfs entries, they need to be unique. The specification doesn't require these to be unique. Eg: $ sg_ses -p 7 /dev/sg0 FTS CORP TXS6_SAS20BPX12 0500 enclosure services device Element descriptor In diagnostic page: generation code: 0x0 element descriptor by type list Element type: Array device, subenclosure id: 0 Overall descriptor: ArrayDevicesInSubEnclsr0 Element 1 descriptor: ArrayDevice00 Element 2 descriptor: ArrayDevice01 Element 3 descriptor: ArrayDevice02 Element 4 descriptor: ArrayDevice03 Element 5 descriptor: ArrayDevice03 Element 6 descriptor: ArrayDevice03 Element 7 descriptor: ArrayDevice03 Element 8 descriptor: ArrayDevice03 Element 9 descriptor: ArrayDevice03 Element 10 descriptor: ArrayDevice03 Element 11 descriptor: ArrayDevice03 Element 12 descriptor: ArrayDevice03 Based on http://thread.gmane.org/gmane.linux.scsi/69289. This version implements James' ideas about the naming convention Signed-off-by: Markus Stockhausen Acked-by: James Bottomley Signed-off-by: Christoph Hellwig