Are you saying that the device will not function properly if sent a max_lun query?
Matt
On Sun, Mar 02, 2003 at 03:46:27AM +0900, Go Taniguchi wrote:
> Hi,
>
> This is status and patch of Panasonic compact USB CDROMs on 2.4.21pre4.
> * KXL-840(CD-ROM11): usb_stor_Bulk_max_lun() is danger, need US_FL_SINGLE_LUN
> * KXL-RW11(CDRRW02): usb_stor_Bulk_max_lun() is danger, need US_FL_SINGLE_LUN
> * KXL-RW20(CDRRW03): original IClass is 0xFF, use US_PR_CB and need init reset
> * KXL-RW21(CDRRW06): original IClass is 0xFF, use US_PR_CB and need init reset
> * KXL-RW31(CDRRW05): work fine with current code
> * KXL-RW32(CDRRW09): work fine with current code
>
> -- GO!
> diff -urN linux/drivers/usb/storage.orig/unusual_devs.h
> linux/drivers/usb/storage/unusual_devs.h
> --- linux/drivers/usb/storage.orig/unusual_devs.h 2003-02-07 10:16:07.000000000
> +0900
> +++ linux/drivers/usb/storage/unusual_devs.h 2003-02-09 11:28:46.000000000 +0900
> @@ -579,3 +579,31 @@
> US_SC_SCSI, US_PR_SDDR55, NULL,
> US_FL_SINGLE_LUN),
> #endif
> +
> +/*
> + * Panasonic/OEMs compact USB CDROMs status
> + * KXL-840(CD-ROM11): usb_stor_Bulk_max_lun() is danger, need US_FL_SINGLE_LUN
> + * KXL-RW11(CDRRW02): usb_stor_Bulk_max_lun() is danger, need US_FL_SINGLE_LUN
> + * KXL-RW20(CDRRW03): original IClass is 0xFF, use US_PR_CB and need init reset
> + * KXL-RW21(CDRRW06): original IClass is 0xFF, use US_PR_CB and need init reset
> + * KXL-RW31(CDRRW05): work fine with current code
> + * KXL-RW32(CDRRW09): work fine with current code
> + * Checked: Sun Feb 9 JST 2003 Go Taniguchi <[EMAIL PROTECTED]>
> + */
> +UNUSUAL_DEV( 0x04da, 0x0d01, 0x0000, 0xffff,
> + "MATSHITA",
> + "CD-ROM11",
> + US_SC_8020, US_PR_BULK, NULL, US_FL_SINGLE_LUN),
> +UNUSUAL_DEV( 0x04da, 0x0d02, 0x0000, 0xffff,
> + "MATSHITA",
> + "CDRRW02",
> + US_SC_8020, US_PR_BULK, NULL, US_FL_SINGLE_LUN),
> +UNUSUAL_DEV( 0x04da, 0x0d03, 0x0000, 0xffff,
> + "MATSHITA",
> + "CDRRW03",
> + US_SC_8020, US_PR_CB, NULL, US_FL_INIT_RESET),
> +UNUSUAL_DEV( 0x04da, 0x0d06, 0x0000, 0xffff,
> + "MATSHITA",
> + "CDRRW06",
> + US_SC_8020, US_PR_CB, NULL, US_FL_INIT_RESET),
> +
> diff -urN linux/drivers/usb/storage.orig/usb.c linux/drivers/usb/storage/usb.c
> --- linux/drivers/usb/storage.orig/usb.c 2002-11-29 08:53:15.000000000 +0900
> +++ linux/drivers/usb/storage/usb.c 2003-02-09 11:31:21.000000000 +0900
> @@ -846,7 +846,8 @@
> ss->transport_name = "Bulk";
> ss->transport = usb_stor_Bulk_transport;
> ss->transport_reset = usb_stor_Bulk_reset;
> - ss->max_lun = usb_stor_Bulk_max_lun(ss);
> + if (!(ss->flags & US_FL_SINGLE_LUN))
> + ss->max_lun = usb_stor_Bulk_max_lun(ss);
> break;
>
> #ifdef CONFIG_USB_STORAGE_HP8200e
> @@ -1025,6 +1026,11 @@
>
> /* now register - our detect function will be called */
> ss->htmplt.module = THIS_MODULE;
> +
> + /* some device need reset process */
> + if (ss->flags & US_FL_INIT_RESET)
> + ss->transport_reset(ss);
> +
> scsi_register_module(MODULE_SCSI_HA, &(ss->htmplt));
>
> /* lock access to the data structures */
> diff -urN linux/drivers/usb/storage.orig/usb.h linux/drivers/usb/storage/usb.h
> --- linux/drivers/usb/storage.orig/usb.h 2003-02-07 10:16:07.000000000 +0900
> +++ linux/drivers/usb/storage/usb.h 2003-02-09 11:29:08.000000000 +0900
> @@ -101,6 +101,7 @@
> #define US_FL_IGNORE_SER 0x00000010 /* Ignore the serial number given */
> #define US_FL_SCM_MULT_TARG 0x00000020 /* supports multiple targets */
> #define US_FL_FIX_INQUIRY 0x00000040 /* INQUIRY response needs fixing */
> +#define US_FL_INIT_RESET 0x00000080 /* reset process when initialize */
>
> #define USB_STOR_STRING_LEN 32
>
--
Matthew Dharm Home: [EMAIL PROTECTED]
Maintainer, Linux USB Mass Storage Driver
S: Another stupid question?
G: There's no such thing as a stupid question, only stupid people.
-- Stef and Greg
User Friendly, 7/15/1998
pgp00000.pgp
Description: PGP signature
