release/src/router/apcupsd/examples/linux-usb-patch-email.txt

   1 From vsu@altlinux.ru Tue Apr 22 16:39:58 2003
   2 Return-Path: <vsu@altlinux.ru>
   3 Received: from mail.mivlgu.ru (mivlgu.ru [81.18.140.87]) by
   4         matou.sibbald.com (8.11.6/8.11.6) with ESMTP id h3MEdw615608 for
   5         <kern@sibbald.com>; Tue, 22 Apr 2003 16:39:58 +0200
   6 Received: by mail.mivlgu.ru (Postfix, from userid 112) id 5667E817DD; Tue,
   7         22 Apr 2003 18:39:53 +0400 (MSD)
   8 Received: from vcserver.mivlgu.local (vcserver.mivlgu.local
   9         [192.168.1.251]) by mail.mivlgu.ru (Postfix) with SMTP id 0D7B5817DD; Tue,
  10         22 Apr 2003 18:39:44 +0400 (MSD)
  11 Date: Tue, 22 Apr 2003 18:39:39 +0400
  12 From: Sergey Vlasov <vsu@altlinux.ru>
  13 To: stewart@wetlogic.net
  14 Cc: stewart@inverse.wetlogic.net, kern@sibbald.com, vojtech@ucw.cz
  15 Subject: Re: [Fwd: [Apcupsd-users] Success - APC BackUPS CS 500 shutdown
  16         over USB]
  17 Message-Id: <20030422183939.08cd1c13.vsu@altlinux.ru>
  18 In-Reply-To: <E194m2k-0005jB-00@inverse.wetlogic.net>
  19 References: <1050086110.13768.163.camel@rufus>
  20          <E194m2k-0005jB-00@inverse.wetlogic.net>
  21 X-Mailer: Sylpheed version 0.8.11 (GTK+ 1.2.10; i586-alt-linux-gnu)
  22 Mime-Version: 1.0
  23 Content-Type: multipart/signed; protocol="application/pgp-signature"; micalg="pgp-sha1"; boundary="=.rPW3CATQ/UTztX"
  24 X-Annoyance-Filter-Junk-Probability: 0.5
  25 X-Annoyance-Filter-Classification: Mail
  26
  27 --=.rPW3CATQ/UTztX
  28 Content-Type: multipart/mixed;
  29  boundary="Multipart_Tue__22_Apr_2003_18:39:39_+0400_083029a8"
  30
  31
  32 --Multipart_Tue__22_Apr_2003_18:39:39_+0400_083029a8
  33 Content-Type: text/plain; charset=US-ASCII
  34 Content-Transfer-Encoding: 7bit
  35
  36 On Sun, 13 Apr 2003 11:17:30 -0700
  37 Paul Stewart <stewart@inverse.wetlogic.net> wrote:
  38
  39 > I think it is definitely worth putting this in as a quirk.  I know for a
  40 > fact that the MGE UPSes work fine without this patch, but works only after
  41 > a long delay (4 seconds or so) with this patch.  I'm guessing that this
  42 > may be a more substantial problem with other HID devices -- note that
  43 > this function is used with all sorts of devices.
  44 >
  45 > I agree -- from reading the spec, that the current code is wrong -- there
  46 > is a hard-coded "report->id | 0x200" there that should really be 0x200 for
  47 > Output and 0x300 for feature reports (now that we realize that Feature
  48 > reports are settable too).  However, the mode of access in the patch
  49 > looks nothing at all like the spec, and more like a mirror image of the
  50 > interrupt transfer.  The prepended report ID byte looks to be a
  51 > requirement specific to APC UPSes and could easily wreak havoc with other
  52 > devices.  This is why I suggest the patch be re-submitted as a quirk:
  53 >
  54 >    - Add a new HID_QUIRK_ to hid.h
  55 >    - Add the vendor and device IDs to hid_blacklist, with this new
  56 >      quirk.
  57 >    - Make the changes in the patch conditional on
  58 >       (hid->quirks & HID_QUIRK_WEIRD_SETREPORT) != 0
  59 >
  60 > It would be nice to fix the 0x200 issue while you're in that part of the
  61 > code.  I'd have written the patch myself, but I don't have the vendor/device
  62 > IDs in question.  This patch should appply cleanly on top of the other
  63 > changes (I think) I have in the queue WRT HID collections.  Thanks for the
  64 > good work.
  65
  66 (Sorry for the delay - I was busy with other things)
  67
  68 OK, I did this (added a quirk and fixed the report type problem); it
  69 works here, but I have only one USB device - the UPS (APC Back-UPS CS
  70 500).
  71
  72 I have named the device ID USB_DEVICE_ID_APC_UPS_0002, because this
  73 identifier seems to be used for most of the APC USB UPSes (in fact,
  74 all hid-ups report files from apcupsd have this ID). Hope they all
  75 behave the same way (otherwise the code in hid-core.c will need to be
  76 extended to use more fields for matching).
  77
  78 --Multipart_Tue__22_Apr_2003_18:39:39_+0400_083029a8
  79 Content-Type: application/octet-stream;
  80  name="linux-2.4.20-alt-apc_usb_ups.patch"
  81 Content-Disposition: attachment;
  82  filename="linux-2.4.20-alt-apc_usb_ups.patch"
  83 Content-Transfer-Encoding: base64
  84
  85 LS0tIGxpbnV4LTIuNC4yMC9kcml2ZXJzL3VzYi9oaWQtY29yZS5jLmFsdC1hcGNfdXNiX3Vwcwky
  86 MDAzLTA0LTIxIDE5OjM5OjI3ICswNDAwCisrKyBsaW51eC0yLjQuMjAvZHJpdmVycy91c2IvaGlk
  87 LWNvcmUuYwkyMDAzLTA0LTIxIDE5OjU0OjIxICswNDAwCkBAIC0xMDE2LDEwICsxMDE2LDE4IEBA
  88 CiAKIHZvaWQgaGlkX3dyaXRlX3JlcG9ydChzdHJ1Y3QgaGlkX2RldmljZSAqaGlkLCBzdHJ1Y3Qg
  89 aGlkX3JlcG9ydCAqcmVwb3J0KQogewotCWhpZF9vdXRwdXRfcmVwb3J0KHJlcG9ydCwgaGlkLT5v
  90 dXRbaGlkLT5vdXRoZWFkXS5idWZmZXIpOwotCi0JaGlkLT5vdXRbaGlkLT5vdXRoZWFkXS5kci53
  91 VmFsdWUgPSBjcHVfdG9fbGUxNigweDIwMCB8IHJlcG9ydC0+aWQpOwotCWhpZC0+b3V0W2hpZC0+
  92 b3V0aGVhZF0uZHIud0xlbmd0aCA9IGNwdV90b19sZTE2KChyZXBvcnQtPnNpemUgKyA3KSA+PiAz
  93 KTsKKwlpZiAoKGhpZC0+cXVpcmtzICYgSElEX1FVSVJLX1NFVFJFUE9SVF9ORUVEU19JRCkgJiYg
  94 cmVwb3J0LT5pZCkgeworCQloaWQtPm91dFtoaWQtPm91dGhlYWRdLmJ1ZmZlclswXSA9IHJlcG9y
  95 dC0+aWQ7CisJCWhpZF9vdXRwdXRfcmVwb3J0KHJlcG9ydCwgaGlkLT5vdXRbaGlkLT5vdXRoZWFk
  96 XS5idWZmZXIgKyAxKTsKKwkJaGlkLT5vdXRbaGlkLT5vdXRoZWFkXS5kci53TGVuZ3RoID0KKwkJ
  97 CWNwdV90b19sZTE2KCgocmVwb3J0LT5zaXplICsgNykgPj4gMykgKyAxKTsKKwl9IGVsc2Ugewor
  98 CQloaWRfb3V0cHV0X3JlcG9ydChyZXBvcnQsIGhpZC0+b3V0W2hpZC0+b3V0aGVhZF0uYnVmZmVy
  99 KTsKKwkJaGlkLT5vdXRbaGlkLT5vdXRoZWFkXS5kci53TGVuZ3RoID0KKwkJCWNwdV90b19sZTE2
 100 KChyZXBvcnQtPnNpemUgKyA3KSA+PiAzKTsKKwl9CisJaGlkLT5vdXRbaGlkLT5vdXRoZWFkXS5k
 101 ci53VmFsdWUgPQorCQljcHVfdG9fbGUxNigoKHJlcG9ydC0+dHlwZSArIDEpIDw8IDgpIHwgcmVw
 102 b3J0LT5pZCk7CiAKIAloaWQtPm91dGhlYWQgPSAoaGlkLT5vdXRoZWFkICsgMSkgJiAoSElEX0NP
 103 TlRST0xfRklGT19TSVpFIC0gMSk7CiAKQEAgLTEwOTAsNiArMTA5OCw5IEBACiAjZGVmaW5lIFVT
 104 Ql9ERVZJQ0VfSURfUE9XRVJNQVRFCQkweDA0MTAgLyogR3JpZmZpbiBQb3dlck1hdGUgKi8KICNk
 105 ZWZpbmUgVVNCX0RFVklDRV9JRF9TT1VOREtOT0IJCTB4MDRBQSAvKiBHcmlmZmluIFNvdW5kS25v
 106 YiAqLwogCisjZGVmaW5lIFVTQl9WRU5ET1JfSURfQVBDCQkweDA1MWQKKyNkZWZpbmUgVVNCX0RF
 107 VklDRV9JRF9BUENfVVBTXzAwMDIJMHgwMDAyIC8qIEFQQyBVUFMgLSBtYW55IG1vZGVscyAqLwor
 108 CiBzdHJ1Y3QgaGlkX2JsYWNrbGlzdCB7CiAJX191MTYgaWRWZW5kb3I7CiAJX191MTYgaWRQcm9k
 109 dWN0OwpAQCAtMTEyMSw2ICsxMTMyLDcgQEAKIAl7IFVTQl9WRU5ET1JfSURfQVRFTiwgVVNCX0RF
 110 VklDRV9JRF9BVEVOXzRQT1JUS1ZNLCBISURfUVVJUktfTk9HRVQgfSwKIAl7IFVTQl9WRU5ET1Jf
 111 SURfR1JJRkZJTiwgVVNCX0RFVklDRV9JRF9QT1dFUk1BVEUsIEhJRF9RVUlSS19JR05PUkUgfSwK
 112 IAl7IFVTQl9WRU5ET1JfSURfR1JJRkZJTiwgVVNCX0RFVklDRV9JRF9TT1VOREtOT0IsIEhJRF9R
 113 VUlSS19JR05PUkUgfSwKKwl7IFVTQl9WRU5ET1JfSURfQVBDLCBVU0JfREVWSUNFX0lEX0FQQ19V
 114 UFNfMDAwMiwgSElEX1FVSVJLX1NFVFJFUE9SVF9ORUVEU19JRCB9LAogCXsgMCwgMCB9CiB9Owog
 115 Ci0tLSBsaW51eC0yLjQuMjAvZHJpdmVycy91c2IvaGlkLmguYWx0LWFwY191c2JfdXBzCTIwMDIt
 116 MTEtMjkgMDI6NTM6MTQgKzAzMDAKKysrIGxpbnV4LTIuNC4yMC9kcml2ZXJzL3VzYi9oaWQuaAky
 117 MDAzLTA0LTIxIDE5OjQyOjMyICswNDAwCkBAIC0xODYsNiArMTg2LDcgQEAKICNkZWZpbmUgSElE
 118 X1FVSVJLX05PVE9VQ0gJMHgwMgogI2RlZmluZSBISURfUVVJUktfSUdOT1JFCTB4MDQKICNkZWZp
 119 bmUgSElEX1FVSVJLX05PR0VUCQkweDA4CisjZGVmaW5lIEhJRF9RVUlSS19TRVRSRVBPUlRfTkVF
 120 RFNfSUQJMHgxMAogCiAvKgogICogVGhpcyBpcyB0aGUgZ2xvYmFsIGVudmlyb21lbnQgb2YgdGhl
 121 IHBhcnNlci4gVGhpcyBpbmZvcm1hdGlvbiBpcwo=
 122
 123 --Multipart_Tue__22_Apr_2003_18:39:39_+0400_083029a8--
 124
 125 --=.rPW3CATQ/UTztX
 126 Content-Type: application/pgp-signature
 127
 128 -----BEGIN PGP SIGNATURE-----
 129 Version: GnuPG v1.2.1 (GNU/Linux)
 130
 131 iD8DBQE+pVQvW82GfkQfsqIRAsFoAJ4hQtrQVfe97ZioFF8d7HAvp++ZHwCfUztJ
 132 lguft7SZDdYYOrN2tfaDTZE=
 133 =mIxq
 134 -----END PGP SIGNATURE-----
 135
 136 --=.rPW3CATQ/UTztX--