i love u ----- Original Message ----- From: <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Monday, July 15, 2002 3:03 AM Subject: linux-usb-devel digest, Vol 1 #1441 - 10 msgs > Send linux-usb-devel mailing list submissions to > [EMAIL PROTECTED] > > To subscribe or unsubscribe via the World Wide Web, visit > https://lists.sourceforge.net/lists/listinfo/linux-usb-devel > or, via email, send a message with subject or body 'help' to > [EMAIL PROTECTED] > > You can reach the person managing the list at > [EMAIL PROTECTED] > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of linux-usb-devel digest..." > > > Today's Topics: > > 1. BK PATCH: usb-storage: catch bad commands (Matthew Dharm) > 2. Re: [bk patch] Updates for hiddev by Paul Stewart (Brad Hards) > 3. Re: [bk patch] Updates for hiddev by Paul Stewart (Vojtech Pavlik) > 4. Vendor ID Conflict. CX 1 (Grahame Jordan) > 5. Re: Vendor ID Conflict. CX 1 (Brad Hards) > 6. Re: Vendor ID Conflict. CX 1 (Grahame Jordan) > 7. Re: Vendor ID Conflict. CX 1 (Brad Hards) > 8. Re: Vendor ID Conflict. CX 1 (Grahame Jordan) > 9. Re: Vendor ID Conflict. CX 1 (Brad Hards) > 10. [bk patch] A cleanup of Paul's 2.5 hiddev update. (Vojtech Pavlik) > > --__--__-- > > Message: 1 > Date: Sat, 13 Jul 2002 17:34:11 -0700 > From: Matthew Dharm <[EMAIL PROTECTED]> > To: USB Developers <[EMAIL PROTECTED]>, > Greg KH <[EMAIL PROTECTED]>, > USB Storage List <[EMAIL PROTECTED]> > Organization: One Eyed Alien Networks > Subject: [linux-usb-devel] BK PATCH: usb-storage: catch bad commands > > > --St7VIuEGZ6dlpu13 > Content-Type: text/plain; charset=us-ascii > Content-Disposition: inline > Content-Transfer-Encoding: quoted-printable > > This is a patch against the 2.5 usb-storage tree. Greg, please apply. > > The purpose of this patch is to trap all commands which have a bogus > request_bufflen. Much logic is devoted to calculating the proper length of > the transfer, but according to discussions I've had on linux-scsi, this is > really a bug in whatever is originating the bad command. > > Hopefully, after people use this patch for a while, we'll eliminate all the > offending sources and can remove quite a bit of logic from the driver. > > Matt > > # This is a BitKeeper generated patch for the following project: > # Project Name: greg k-h's linux 2.5 USB kernel tree > # This patch format is intended for GNU patch command version 2.5 or higher. > # This patch includes the following deltas: > # ChangeSet 1.592 -> 1.593 =20 > # drivers/usb/storage/transport.c 1.34 -> 1.35 =20 > # > # The following is the BitKeeper ChangeSet Log > # -------------------------------------------- > # 02/07/13 [EMAIL PROTECTED] 1.593 > # Catch all cases of commands which have bad request_bufflen fields. > # Bad is defined, in this case, to mean the command requests a different > # (usually smaller) amount of data. > # -------------------------------------------- > # > diff -Nru a/drivers/usb/storage/transport.c b/drivers/usb/storage/transport= > .c > --- a/drivers/usb/storage/transport.c Sat Jul 13 17:28:34 2002 > +++ b/drivers/usb/storage/transport.c Sat Jul 13 17:28:34 2002 > @@ -344,6 +344,12 @@ > len =3D srb->request_bufflen; > } > =20 > + /* According to the linux-scsi people, any command sent which > + * violates this invariant is a bug. In the hopes of removing > + * all the complex logic above, let's find them and eliminate them. > + */ > + BUG_ON(len !=3D srb->request_bufflen); > + > return len; > } > =20 > > --=20 > Matthew Dharm Home: mdharm-usb@one-eyed-alien.= > net=20 > Maintainer, Linux USB Mass Storage Driver > > G: Money isn't everything, A.J. > AJ: Who convinced you of that? > G: The Chief, at my last salary review. > -- Mike and Greg > User Friendly, 11/3/1998 > > --St7VIuEGZ6dlpu13 > Content-Type: application/pgp-signature > Content-Disposition: inline > > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.0.6 (GNU/Linux) > Comment: For info see http://www.gnupg.org > > iD8DBQE9MMcCIjReC7bSPZARAkz5AJwOyVbRJYErA6s1qe3GlgCBgDr+kACggczq > zp0Nkh1IagtLL4YkVCbQw/U= > =hT+x > -----END PGP SIGNATURE----- > > --St7VIuEGZ6dlpu13-- > > > --__--__-- > > Message: 2 > From: Brad Hards <[EMAIL PROTECTED]> > To: Vojtech Pavlik <[EMAIL PROTECTED]>, > [EMAIL PROTECTED], > [EMAIL PROTECTED] > Subject: Re: [linux-usb-devel] [bk patch] Updates for hiddev by Paul Stewart > Date: Sun, 14 Jul 2002 11:01:39 +1000 > > On Sat, 13 Jul 2002 22:33, Vojtech Pavlik wrote: > > Hi! > > > > I've merged a patch Paul Stewart sent me some time ago, which should make > > life easier for the guys writing UPS daemons. > 2.5 only? What about 2.4? > > Brad > > -- > http://conf.linux.org.au. 22-25Jan2003. Perth, Australia. Birds in Black. > > > --__--__-- > > Message: 3 > Date: Sun, 14 Jul 2002 10:05:59 +0200 > From: Vojtech Pavlik <[EMAIL PROTECTED]> > To: Brad Hards <[EMAIL PROTECTED]> > Cc: [EMAIL PROTECTED], [EMAIL PROTECTED] > Subject: Re: [linux-usb-devel] [bk patch] Updates for hiddev by Paul Stewart > > On Sun, Jul 14, 2002 at 11:01:39AM +1000, Brad Hards wrote: > > > > I've merged a patch Paul Stewart sent me some time ago, which should make > > > life easier for the guys writing UPS daemons. > > > 2.5 only? What about 2.4? > > It'll follow shortly, after Paul sends me a patch that applies to a > recent 2.4 kernel. > > -- > Vojtech Pavlik > SuSE Labs > > > --__--__-- > > Message: 4 > Date: Sun, 14 Jul 2002 22:29:37 +1000 > From: Grahame Jordan <[EMAIL PROTECTED]> > To: [EMAIL PROTECTED] > CC: [EMAIL PROTECTED] > Subject: [linux-usb-devel] Vendor ID Conflict. CX 1 > > Hi, > > A couple of us have Momobay CX 1 USB/iee1394 external HDD. We have > managed to get it working by adding an enttry to unusual_devs.h. > However there is an entry with identacal VendorID and Product ID. > > If the CX1 is first in unusual_devs.h the CX 1 works just great. If it > is second it then picks up the other. > > It looks like either, Momobay or SIIG have hijacked the VendorID and the > productID without going through the correct channels and hence we have a > conflict. > > How can this conflict be handled without having to recompile the module > every time I get a new kernel? > > +UNUSUAL_DEV( 0x05e3, 0x0700, 0x0000, 0xffff, > + "SIIG", > + "CompactFlash Card Reader", > + US_SC_SCSI, US_PR_BULK, NULL, > + US_FL_FIX_INQUIRY ), > > Thanks to Christophe Theron we have for the CX 1: > > UNUSUAL_DEV( 0x05e3, 0x0700, 0x0001, 0xffff, > "DViCO", > "Momobay CX-1 hard disk", > US_SC_SCSI, US_PR_BULK, NULL, > US_FL_FIX_INQUIRY | US_FL_START_STOP | US_FL_MODE_XLATE ), > > > Thanks > > Grahame Jordan > > > > > > > --__--__-- > > Message: 5 > From: Brad Hards <[EMAIL PROTECTED]> > To: Grahame Jordan <[EMAIL PROTECTED]>, > [EMAIL PROTECTED] > Subject: Re: [linux-usb-devel] Vendor ID Conflict. CX 1 > Date: Sun, 14 Jul 2002 22:38:30 +1000 > Cc: [EMAIL PROTECTED] > > On Sun, 14 Jul 2002 22:29, Grahame Jordan wrote: > > It looks like either, Momobay or SIIG have hijacked the VendorID and the > > productID without going through the correct channels and hence we have a > > conflict. > They are both likely just using a Genesys part (who own the Vendor ID). GL811 > might be it. > > > How can this conflict be handled without having to recompile the module > > every time I get a new kernel? > > > > +UNUSUAL_DEV( 0x05e3, 0x0700, 0x0000, 0xffff, > > + "SIIG", > > + "CompactFlash Card Reader", > > + US_SC_SCSI, US_PR_BULK, NULL, > > + US_FL_FIX_INQUIRY ), > > > > Thanks to Christophe Theron we have for the CX 1: > > > > UNUSUAL_DEV( 0x05e3, 0x0700, 0x0001, 0xffff, > > "DViCO", > > "Momobay CX-1 hard disk", > > US_SC_SCSI, US_PR_BULK, NULL, > > US_FL_FIX_INQUIRY | US_FL_START_STOP | US_FL_MODE_XLATE ), > There are two cases: > 1. They are both really the same part, and we should just use the same special > case options. > 2. They are really two versions, and the revision numbers might have been > selected better (which I have harped on before, and people shouldn't write > these entries if they don't understand them). What do the descriptors show? > > Brad > > -- > http://conf.linux.org.au. 22-25Jan2003. Perth, Australia. Birds in Black. > > > --__--__-- > > Message: 6 > Date: Sun, 14 Jul 2002 22:56:02 +1000 > From: Grahame Jordan <[EMAIL PROTECTED]> > To: Brad Hards <[EMAIL PROTECTED]> > CC: [EMAIL PROTECTED], [EMAIL PROTECTED] > Subject: Re: [linux-usb-devel] Vendor ID Conflict. CX 1 > > > > > > >There are two cases: > >1. They are both really the same part, and we should just use the same special > >case options. > >2. They are really two versions, and the revision numbers might have been > >selected better (which I have harped on before, and people shouldn't write > >these entries if they don't understand them). What do the descriptors show? > > > I guess you mean these: > > T: Bus=01 Lev=01 Prnt=01 Port=00 Cnt=01 Dev#= 4 Spd=12 MxCh= 0 > D: Ver= 1.10 Cls=00(>ifc ) Sub=00 Prot=00 MxPS= 8 #Cfgs= 1 > P: Vendor=05e3 ProdID=0700 Rev= 1.13 > S: Manufacturer=DViCO Inc. > S: Product=MOMOBAY CX-1 > C:* #Ifs= 1 Cfg#= 1 Atr=80 MxPwr= 70mA > I: If#= 0 Alt= 0 #EPs= 2 Cls=08(stor.) Sub=06 Prot=50 Driver=usb-storage > E: Ad=81(I) Atr=02(Bulk) MxPS= 64 Ivl=0ms > E: Ad=02(O) Atr=02(Bulk) MxPS= 64 Ivl=0ms > > Thanks > > Grahaem Jrodan > > > > --__--__-- > > Message: 7 > From: Brad Hards <[EMAIL PROTECTED]> > To: Grahame Jordan <[EMAIL PROTECTED]> > Subject: Re: [linux-usb-devel] Vendor ID Conflict. CX 1 > Date: Sun, 14 Jul 2002 23:01:45 +1000 > Cc: [EMAIL PROTECTED], > [EMAIL PROTECTED] > > On Sun, 14 Jul 2002 22:56, Grahame Jordan wrote: > > >There are two cases: > > >1. They are both really the same part, and we should just use the same > > > special case options. > > >2. They are really two versions, and the revision numbers might have been > > >selected better (which I have harped on before, and people shouldn't write > > >these entries if they don't understand them). What do the descriptors > > > show? > > > > I guess you mean these: > > > > T: Bus=01 Lev=01 Prnt=01 Port=00 Cnt=01 Dev#= 4 Spd=12 MxCh= 0 > > D: Ver= 1.10 Cls=00(>ifc ) Sub=00 Prot=00 MxPS= 8 #Cfgs= 1 > > P: Vendor=05e3 ProdID=0700 Rev= 1.13 > Is the "Rev=" field the same on the card reader? > If not, we have the solution. > > Brad > -- > http://conf.linux.org.au. 22-25Jan2003. Perth, Australia. Birds in Black. > > > --__--__-- > > Message: 8 > Date: Sun, 14 Jul 2002 23:10:55 +1000 > From: Grahame Jordan <[EMAIL PROTECTED]> > To: Brad Hards <[EMAIL PROTECTED]> > CC: [EMAIL PROTECTED], [EMAIL PROTECTED] > Subject: Re: [linux-usb-devel] Vendor ID Conflict. CX 1 > > Brad, > > [root@falcon ~]# cat /proc/scsi/scsi > Attached devices: > Host: scsi0 Channel: 00 Id: 00 Lun: 00 > Vendor: DViCO Model: Momobay CX-1 har Rev: 0113 > Type: Direct-Access ANSI SCSI revision: 02 > > > [root@falcon ~]# cat /proc/scsi/scsi > Attached devices: > Host: scsi0 Channel: 00 Id: 00 Lun: 00 > Vendor: DViCO Model: Momobay CX-1 har Rev: 0113 > Type: Direct-Access ANSI SCSI revision: 02 > [root@falcon ~]# cat /proc/scsi/usb-storage-0/0 > Host scsi0: usb-storage > Vendor: DViCO Inc. > Product: MOMOBAY CX-1 > Serial Number: None > Protocol: Transparent SCSI > Transport: Bulk > GUID: 05e307000000000000000000 > Attached: Yes > > Thanks > > Grahame Jordan > > Brad Hards wrote: > > >On Sun, 14 Jul 2002 22:56, Grahame Jordan wrote: > > > >>>There are two cases: > >>>1. They are both really the same part, and we should just use the same > >>>special case options. > >>>2. They are really two versions, and the revision numbers might have been > >>>selected better (which I have harped on before, and people shouldn't write > >>>these entries if they don't understand them). What do the descriptors > >>>show? > >>> > >>I guess you mean these: > >> > >>T: Bus=01 Lev=01 Prnt=01 Port=00 Cnt=01 Dev#= 4 Spd=12 MxCh= 0 > >>D: Ver= 1.10 Cls=00(>ifc ) Sub=00 Prot=00 MxPS= 8 #Cfgs= 1 > >>P: Vendor=05e3 ProdID=0700 Rev= 1.13 > >> > >Is the "Rev=" field the same on the card reader? > >If not, we have the solution. > > > >Brad > > > > > > > --__--__-- > > Message: 9 > From: Brad Hards <[EMAIL PROTECTED]> > To: Grahame Jordan <[EMAIL PROTECTED]> > Subject: Re: [linux-usb-devel] Vendor ID Conflict. CX 1 > Date: Sun, 14 Jul 2002 23:12:10 +1000 > Cc: [EMAIL PROTECTED], > [EMAIL PROTECTED] > > On Sun, 14 Jul 2002 23:10, Grahame Jordan wrote: > > Brad, > > > > [root@falcon ~]# cat /proc/scsi/scsi > > Attached devices: > > Host: scsi0 Channel: 00 Id: 00 Lun: 00 > > Vendor: DViCO Model: Momobay CX-1 har Rev: 0113 > > Type: Direct-Access ANSI SCSI revision: 02 > > > > > > [root@falcon ~]# cat /proc/scsi/scsi > > Attached devices: > > Host: scsi0 Channel: 00 Id: 00 Lun: 00 > > Vendor: DViCO Model: Momobay CX-1 har Rev: 0113 > > Type: Direct-Access ANSI SCSI revision: 02 > > [root@falcon ~]# cat /proc/scsi/usb-storage-0/0 > > Host scsi0: usb-storage > > Vendor: DViCO Inc. > > Product: MOMOBAY CX-1 > > Serial Number: None > > Protocol: Transparent SCSI > > Transport: Bulk > > GUID: 05e307000000000000000000 > > Attached: Yes > What has this got to do with anything? > > I need the descriptors for the _CARD READER_ version. Just as you > previously provided for the CX-1, I need the contents of > /proc/bus/usb/devices for the SIIG card reader. > > Brad > > -- > http://conf.linux.org.au. 22-25Jan2003. Perth, Australia. Birds in Black. > > > --__--__-- > > Message: 10 > Date: Sun, 14 Jul 2002 20:18:17 +0200 > From: Vojtech Pavlik <[EMAIL PROTECTED]> > To: [EMAIL PROTECTED], [EMAIL PROTECTED] > Subject: [linux-usb-devel] [bk patch] A cleanup of Paul's 2.5 hiddev update. > > > You can import this changeset into BK by piping this whole message to: > '| bk receive [path to repository]' or apply the patch as usual. > > =================================================================== > > > [EMAIL PROTECTED], 2002-07-14 20:15:59+02:00, [EMAIL PROTECTED] > Get rid of #ifdefs in hid-core again. (For you, Greg.) > Move the uref generation code from hid-core to hiddev to make things cleaner. > > > drivers/usb/input/hid-core.c | 36 ++++------------------------------ > drivers/usb/input/hiddev.c | 45 ++++++++++++++++++++++++++++++++++++++----- > include/linux/hiddev.h | 8 +++++-- > 3 files changed, 51 insertions(+), 38 deletions(-) > > > diff -Nru a/drivers/usb/input/hid-core.c b/drivers/usb/input/hid-core.c > --- a/drivers/usb/input/hid-core.c Sun Jul 14 20:17:56 2002 > +++ b/drivers/usb/input/hid-core.c Sun Jul 14 20:17:56 2002 > @@ -740,22 +740,8 @@ > hid_dump_input(usage, value); > if (hid->claimed & HID_CLAIMED_INPUT) > hidinput_hid_event(hid, field, usage, value); > -#ifdef CONFIG_USB_HIDDEV > - if (hid->claimed & HID_CLAIMED_HIDDEV) { > - struct hiddev_usage_ref uref; > - unsigned type = field->report_type; > - uref.report_type = > - (type == HID_INPUT_REPORT) ? HID_REPORT_TYPE_INPUT : > - ((type == HID_OUTPUT_REPORT) ? HID_REPORT_TYPE_OUTPUT : > - ((type == HID_FEATURE_REPORT) ? HID_REPORT_TYPE_FEATURE:0)); > - uref.report_id = field->report->id; > - uref.field_index = field->index; > - uref.usage_index = (usage - field->usage); > - uref.usage_code = usage->hid; > - uref.value = value; > - hiddev_hid_event(hid, &uref); > - } > -#endif > + if (hid->claimed & HID_CLAIMED_HIDDEV) > + hiddev_hid_event(hid, field, usage, value); > } > > /* > @@ -851,27 +837,15 @@ > return -1; > } > > -#ifdef CONFIG_USB_HIDDEV > - /* Notify listeners that a report has been received */ > - if (hid->claimed & HID_CLAIMED_HIDDEV) { > - struct hiddev_usage_ref uref; > - memset(&uref, 0, sizeof(uref)); > - uref.report_type = > - (type == HID_INPUT_REPORT) ? HID_REPORT_TYPE_INPUT : > - ((type == HID_OUTPUT_REPORT) ? HID_REPORT_TYPE_OUTPUT : > - ((type == HID_FEATURE_REPORT) ? HID_REPORT_TYPE_FEATURE:0)); > - uref.report_id = report->id; > - uref.field_index = HID_FIELD_INDEX_NONE; > - hiddev_hid_event(hid, &uref); > - } > -#endif > - > size = ((report->size - 1) >> 3) + 1; > > if (len < size) { > dbg("report %d is too short, (%d < %d)", report->id, len, size); > return -1; > } > + > + if (hid->claimed & HID_CLAIMED_HIDDEV) > + hiddev_report_event(hid, report); > > for (n = 0; n < report->maxfield; n++) > hid_input_field(hid, report->field[n], data); > diff -Nru a/drivers/usb/input/hiddev.c b/drivers/usb/input/hiddev.c > --- a/drivers/usb/input/hiddev.c Sun Jul 14 20:17:56 2002 > +++ b/drivers/usb/input/hiddev.c Sun Jul 14 20:17:56 2002 > @@ -152,11 +152,8 @@ > return NULL; > } > > -/* > - * This is where hid.c calls into hiddev to pass an event that occurred over > - * the interrupt pipe > - */ > -void hiddev_hid_event(struct hid_device *hid, struct hiddev_usage_ref *uref) > +static void hiddev_send_event(struct hid_device *hid, > + struct hiddev_usage_ref *uref) > { > struct hiddev *hiddev = hid->hiddev; > struct hiddev_list *list = hiddev->list; > @@ -176,6 +173,44 @@ > wake_up_interruptible(&hiddev->wait); > } > > +/* > + * This is where hid.c calls into hiddev to pass an event that occurred over > + * the interrupt pipe > + */ > +void hiddev_hid_event(struct hid_device *hid, struct hid_field *field, > + struct hid_usage *usage, __s32 value) > +{ > + unsigned type = field->report_type; > + struct hiddev_usage_ref uref; > + > + uref.report_type = > + (type == HID_INPUT_REPORT) ? HID_REPORT_TYPE_INPUT : > + ((type == HID_OUTPUT_REPORT) ? HID_REPORT_TYPE_OUTPUT : > + ((type == HID_FEATURE_REPORT) ? HID_REPORT_TYPE_FEATURE:0)); > + uref.report_id = field->report->id; > + uref.field_index = field->index; > + uref.usage_index = (usage - field->usage); > + uref.usage_code = usage->hid; > + uref.value = value; > + > + hiddev_send_event(hid, &uref); > +} > + > + > +void hiddev_report_event(struct hid_device *hid, struct hid_report *report) > +{ > + unsigned type = report->type; > + struct hiddev_usage_ref uref; > + > + memset(&uref, 0, sizeof(uref)); > + uref.report_type = > + (type == HID_INPUT_REPORT) ? HID_REPORT_TYPE_INPUT : > + ((type == HID_OUTPUT_REPORT) ? HID_REPORT_TYPE_OUTPUT : > + ((type == HID_FEATURE_REPORT) ? HID_REPORT_TYPE_FEATURE:0)); > + uref.report_id = report->id; > + > + hiddev_send_event(hid, &uref); > +} > /* > * fasync file op > */ > diff -Nru a/include/linux/hiddev.h b/include/linux/hiddev.h > --- a/include/linux/hiddev.h Sun Jul 14 20:17:56 2002 > +++ b/include/linux/hiddev.h Sun Jul 14 20:17:56 2002 > @@ -193,13 +193,17 @@ > #ifdef CONFIG_USB_HIDDEV > int hiddev_connect(struct hid_device *); > void hiddev_disconnect(struct hid_device *); > -void hiddev_hid_event(struct hid_device *, struct hiddev_usage_ref *ref); > +void hiddev_hid_event(struct hid_device *hid, struct hid_field *field, > + struct hid_usage *usage, __s32 value); > +void hiddev_report_event(struct hid_device *hid, struct hid_report *report); > int __init hiddev_init(void); > void __exit hiddev_exit(void); > #else > static inline void *hiddev_connect(struct hid_device *hid) { return NULL; } > static inline void hiddev_disconnect(struct hid_device *hid) { } > -static inline void hiddev_event(struct hid_device *hid, unsigned int usage, int >value) { } > +static inline void hiddev_hid_event(struct hid_device *hid, struct hid_field >*field, > + struct hid_usage *usage, __s32 value) { } > +static inline void hiddev_report_event(struct hid_device *hid, struct hid_report >*report) { } > static inline int hiddev_init(void) { return 0; } > static inline void hiddev_exit(void) { } > #endif > > =================================================================== > > > This BitKeeper patch contains the following changesets: > + > ## Wrapped with gzip_uu ## > > > -------------------------------------------------------------------------------- > -- > Vojtech Pavlik > SuSE Labs > > > > --__--__-- > > _______________________________________________ > [EMAIL PROTECTED] > To unsubscribe, use the last form field at: > https://lists.sourceforge.net/lists/listinfo/linux-usb-devel > > > End of linux-usb-devel Digest > �� ��^�����)�{(��[�8b�A�zE���&z� y�!y�ޞm���)��r����b��n��^��e��l���q���z��{.n�+�����azV���+����֭��i����l���q���z���l�X��)ߣ�b��n��^��
