Files
rockchip-kernel/include/linux
Martin K. Petersen ca369d51b3 block/sd: Fix device-imposed transfer length limits
Commit 4f258a4634 ("sd: Fix maximum I/O size for BLOCK_PC requests")
had the unfortunate side-effect of removing an implicit clamp to
BLK_DEF_MAX_SECTORS for REQ_TYPE_FS requests in the block layer
code. This caused problems for some SMR drives.

Debugging this issue revealed a few problems with the existing
infrastructure since the block layer didn't know how to deal with
device-imposed limits, only limits set by the I/O controller.

 - Introduce a new queue limit, max_dev_sectors, which is used by the
   ULD to signal the maximum sectors for a REQ_TYPE_FS request.

 - Ensure that max_dev_sectors is correctly stacked and taken into
   account when overriding max_sectors through sysfs.

 - Rework sd_read_block_limits() so it saves the max_xfer and opt_xfer
   values for later processing.

 - In sd_revalidate() set the queue's max_dev_sectors based on the
   MAXIMUM TRANSFER LENGTH value in the Block Limits VPD. If this value
   is not reported, fall back to a cap based on the CDB TRANSFER LENGTH
   field size.

 - In sd_revalidate(), use OPTIMAL TRANSFER LENGTH from the Block Limits
   VPD--if reported and sane--to signal the preferred device transfer
   size for FS requests. Otherwise use BLK_DEF_MAX_SECTORS.

 - blk_limits_max_hw_sectors() is no longer used and can be removed.

Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=93581
Reviewed-by: Christoph Hellwig <hch@lst.de>
Tested-by: sweeneygj@gmx.com
Tested-by: Arzeets <anatol.pomozov@gmail.com>
Tested-by: David Eisner <david.eisner@oriel.oxon.org>
Tested-by: Mario Kicherer <dev@kicherer.org>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
2015-11-25 21:38:58 -05:00
..
2015-06-25 11:49:31 +03:00
2015-05-13 12:04:55 -05:00
2015-03-25 20:28:11 -04:00
2015-08-03 12:01:54 -04:00
2015-08-06 16:17:25 -04:00
2015-06-01 14:35:56 -06:00
2015-09-01 15:52:41 +02:00
2015-09-04 16:54:41 -07:00
2015-09-08 15:35:28 -07:00
2015-08-20 10:20:11 +03:00
2015-06-24 17:49:45 -07:00
2015-07-17 08:41:53 -06:00
2015-05-12 10:46:53 +02:00
2015-06-01 14:33:35 +02:00
2015-06-19 15:18:28 +02:00
2015-09-08 15:35:28 -07:00
2015-09-08 15:35:28 -07:00
2015-05-05 13:40:42 -06:00
2015-08-27 19:40:58 -04:00
2015-08-06 00:14:59 +02:00
2015-06-25 12:06:45 +02:00
2015-08-18 15:49:15 -07:00
2015-07-28 08:50:42 +01:00
2015-09-06 16:27:10 +02:00
2015-04-29 17:17:17 -05:00
2015-04-14 16:49:05 -07:00
2015-06-24 17:49:41 -07:00
2015-07-21 10:39:05 -07:00
2015-06-25 04:20:04 -04:00
2015-08-17 13:32:56 -05:00
2015-08-18 11:56:13 -06:00
2015-09-10 13:29:01 -07:00
2015-09-10 13:29:01 -07:00
2015-09-10 13:29:01 -07:00
2015-09-08 15:35:28 -07:00
2015-04-12 21:03:31 +02:00
2015-06-19 01:18:14 +02:00
2015-08-17 15:40:20 +02:00
2015-06-10 19:14:04 +08:00
2015-05-27 12:58:04 -07:00
2015-05-26 15:23:23 +02:00
2015-06-25 01:13:43 +02:00
2015-04-11 15:53:35 -04:00
2015-06-25 17:00:40 -07:00
2015-06-25 17:00:39 -07:00
2015-08-17 11:25:28 -07:00
2015-07-22 15:27:29 -07:00
2015-08-28 16:27:27 -07:00
2015-04-11 22:29:44 -04:00
2015-06-12 17:26:57 -07:00
2015-09-08 15:35:28 -07:00
2015-09-10 13:29:01 -07:00