Allow retrieval of the Caching mode page

The statement of the comment removed by this patch, "A number of devices have problems with MODE SENSE for page x08, so we will skip it" is certainly too general to apply for *all* devices. This patch removes the unconditional retrieval constraint of the Caching mode page.

---
 drivers/usb/storage/scsiglue.c |    4 ----
 1 files changed, 0 insertions(+), 4 deletions(-)

index d8d98cf..c3cb60d 100644
@@ -193,10 +193,6 @@ static int slave_configure(struct scsi_device *sdev)
 		if (us->fflags & US_FL_NO_WP_DETECT)
 			sdev->skip_ms_page_3f = 1;
 
-		/* A number of devices have problems with MODE SENSE for
-		 * page x08, so we will skip it. */
-		sdev->skip_ms_page_8 = 1;
-
 		/* Some disks return the total number of blocks in response
 		 * to READ CAPACITY rather than the highest block number.
 		 * If this device makes that mistake, tell the sd driver. */

1.7.0.1

If you remove this, there are several devices which will stop working. They will simply go out-to-lunch when the sd_mod driver sends a request for Mode Page 8.

Matt

Matthew Dharm                              Home: [email protected] 
Maintainer, Linux USB Mass Storage Driver

I want my GPFs!!!
					-- Stef
User Friendly, 11/9/1998

That's true. But it seems unfair to punish good devices which do support the Caching mode page.

sd_revalidate_disk() calls in succession sd_read_write_protect_flag(), sd_read_cache_type() and sd_read_app_tag_own(). The first, asks for all pages by setting the page code to 0x3F. Surely if the device server supports the Caching mode page, it will be returned. The second call, asks only for the Caching mode page, and here is where some (few?) broken devices fail.

If the skip_ms_page_8 is set, why not request all pages, and see if the Caching mode page is part of the parameter data.

Anyone willing to code that up in sd_read_cache_type()?