File: linux-usb-patch-email.txt

package info (click to toggle)
apcupsd 3.12.4-2
  • links: PTS
  • area: main
  • in suites: etch, etch-m68k
  • size: 41,116 kB
  • ctags: 6,199
  • sloc: ansic: 42,488; sh: 8,031; cpp: 3,740; makefile: 1,897; perl: 1,723; tcl: 368; php: 107; sed: 93
file content (136 lines) | stat: -rw-r--r-- 7,002 bytes parent folder | download | duplicates (6)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
From vsu@altlinux.ru Tue Apr 22 16:39:58 2003
Return-Path: <vsu@altlinux.ru>
Received: from mail.mivlgu.ru (mivlgu.ru [81.18.140.87]) by
	matou.sibbald.com (8.11.6/8.11.6) with ESMTP id h3MEdw615608 for
	<kern@sibbald.com>; Tue, 22 Apr 2003 16:39:58 +0200
Received: by mail.mivlgu.ru (Postfix, from userid 112) id 5667E817DD; Tue,
	22 Apr 2003 18:39:53 +0400 (MSD)
Received: from vcserver.mivlgu.local (vcserver.mivlgu.local
	[192.168.1.251]) by mail.mivlgu.ru (Postfix) with SMTP id 0D7B5817DD; Tue,
	22 Apr 2003 18:39:44 +0400 (MSD)
Date: Tue, 22 Apr 2003 18:39:39 +0400
From: Sergey Vlasov <vsu@altlinux.ru>
To: stewart@wetlogic.net
Cc: stewart@inverse.wetlogic.net, kern@sibbald.com, vojtech@ucw.cz
Subject: Re: [Fwd: [Apcupsd-users] Success - APC BackUPS CS 500 shutdown
	over USB]
Message-Id: <20030422183939.08cd1c13.vsu@altlinux.ru>
In-Reply-To: <E194m2k-0005jB-00@inverse.wetlogic.net>
References: <1050086110.13768.163.camel@rufus>
	 <E194m2k-0005jB-00@inverse.wetlogic.net>
X-Mailer: Sylpheed version 0.8.11 (GTK+ 1.2.10; i586-alt-linux-gnu)
Mime-Version: 1.0
Content-Type: multipart/signed; protocol="application/pgp-signature"; micalg="pgp-sha1"; boundary="=.rPW3CATQ/UTztX"
X-Annoyance-Filter-Junk-Probability: 0.5
X-Annoyance-Filter-Classification: Mail

--=.rPW3CATQ/UTztX
Content-Type: multipart/mixed;
 boundary="Multipart_Tue__22_Apr_2003_18:39:39_+0400_083029a8"


--Multipart_Tue__22_Apr_2003_18:39:39_+0400_083029a8
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit

On Sun, 13 Apr 2003 11:17:30 -0700
Paul Stewart <stewart@inverse.wetlogic.net> wrote:

> I think it is definitely worth putting this in as a quirk.  I know for a
> fact that the MGE UPSes work fine without this patch, but works only after
> a long delay (4 seconds or so) with this patch.  I'm guessing that this
> may be a more substantial problem with other HID devices -- note that
> this function is used with all sorts of devices.
> 
> I agree -- from reading the spec, that the current code is wrong -- there
> is a hard-coded "report->id | 0x200" there that should really be 0x200 for 
> Output and 0x300 for feature reports (now that we realize that Feature 
> reports are settable too).  However, the mode of access in the patch  
> looks nothing at all like the spec, and more like a mirror image of the 
> interrupt transfer.  The prepended report ID byte looks to be a 
> requirement specific to APC UPSes and could easily wreak havoc with other
> devices.  This is why I suggest the patch be re-submitted as a quirk:
> 
>    - Add a new HID_QUIRK_ to hid.h
>    - Add the vendor and device IDs to hid_blacklist, with this new
>      quirk.
>    - Make the changes in the patch conditional on 
> 	(hid->quirks & HID_QUIRK_WEIRD_SETREPORT) != 0
> 
> It would be nice to fix the 0x200 issue while you're in that part of the
> code.  I'd have written the patch myself, but I don't have the vendor/device 
> IDs in question.  This patch should appply cleanly on top of the other 
> changes (I think) I have in the queue WRT HID collections.  Thanks for the
> good work.

(Sorry for the delay - I was busy with other things)

OK, I did this (added a quirk and fixed the report type problem); it
works here, but I have only one USB device - the UPS (APC Back-UPS CS
500).

I have named the device ID USB_DEVICE_ID_APC_UPS_0002, because this
identifier seems to be used for most of the APC USB UPSes (in fact,
all hid-ups report files from apcupsd have this ID). Hope they all
behave the same way (otherwise the code in hid-core.c will need to be
extended to use more fields for matching).

--Multipart_Tue__22_Apr_2003_18:39:39_+0400_083029a8
Content-Type: application/octet-stream;
 name="linux-2.4.20-alt-apc_usb_ups.patch"
Content-Disposition: attachment;
 filename="linux-2.4.20-alt-apc_usb_ups.patch"
Content-Transfer-Encoding: base64

LS0tIGxpbnV4LTIuNC4yMC9kcml2ZXJzL3VzYi9oaWQtY29yZS5jLmFsdC1hcGNfdXNiX3Vwcwky
MDAzLTA0LTIxIDE5OjM5OjI3ICswNDAwCisrKyBsaW51eC0yLjQuMjAvZHJpdmVycy91c2IvaGlk
LWNvcmUuYwkyMDAzLTA0LTIxIDE5OjU0OjIxICswNDAwCkBAIC0xMDE2LDEwICsxMDE2LDE4IEBA
CiAKIHZvaWQgaGlkX3dyaXRlX3JlcG9ydChzdHJ1Y3QgaGlkX2RldmljZSAqaGlkLCBzdHJ1Y3Qg
aGlkX3JlcG9ydCAqcmVwb3J0KQogewotCWhpZF9vdXRwdXRfcmVwb3J0KHJlcG9ydCwgaGlkLT5v
dXRbaGlkLT5vdXRoZWFkXS5idWZmZXIpOwotCi0JaGlkLT5vdXRbaGlkLT5vdXRoZWFkXS5kci53
VmFsdWUgPSBjcHVfdG9fbGUxNigweDIwMCB8IHJlcG9ydC0+aWQpOwotCWhpZC0+b3V0W2hpZC0+
b3V0aGVhZF0uZHIud0xlbmd0aCA9IGNwdV90b19sZTE2KChyZXBvcnQtPnNpemUgKyA3KSA+PiAz
KTsKKwlpZiAoKGhpZC0+cXVpcmtzICYgSElEX1FVSVJLX1NFVFJFUE9SVF9ORUVEU19JRCkgJiYg
cmVwb3J0LT5pZCkgeworCQloaWQtPm91dFtoaWQtPm91dGhlYWRdLmJ1ZmZlclswXSA9IHJlcG9y
dC0+aWQ7CisJCWhpZF9vdXRwdXRfcmVwb3J0KHJlcG9ydCwgaGlkLT5vdXRbaGlkLT5vdXRoZWFk
XS5idWZmZXIgKyAxKTsKKwkJaGlkLT5vdXRbaGlkLT5vdXRoZWFkXS5kci53TGVuZ3RoID0KKwkJ
CWNwdV90b19sZTE2KCgocmVwb3J0LT5zaXplICsgNykgPj4gMykgKyAxKTsKKwl9IGVsc2Ugewor
CQloaWRfb3V0cHV0X3JlcG9ydChyZXBvcnQsIGhpZC0+b3V0W2hpZC0+b3V0aGVhZF0uYnVmZmVy
KTsKKwkJaGlkLT5vdXRbaGlkLT5vdXRoZWFkXS5kci53TGVuZ3RoID0KKwkJCWNwdV90b19sZTE2
KChyZXBvcnQtPnNpemUgKyA3KSA+PiAzKTsKKwl9CisJaGlkLT5vdXRbaGlkLT5vdXRoZWFkXS5k
ci53VmFsdWUgPQorCQljcHVfdG9fbGUxNigoKHJlcG9ydC0+dHlwZSArIDEpIDw8IDgpIHwgcmVw
b3J0LT5pZCk7CiAKIAloaWQtPm91dGhlYWQgPSAoaGlkLT5vdXRoZWFkICsgMSkgJiAoSElEX0NP
TlRST0xfRklGT19TSVpFIC0gMSk7CiAKQEAgLTEwOTAsNiArMTA5OCw5IEBACiAjZGVmaW5lIFVT
Ql9ERVZJQ0VfSURfUE9XRVJNQVRFCQkweDA0MTAgLyogR3JpZmZpbiBQb3dlck1hdGUgKi8KICNk
ZWZpbmUgVVNCX0RFVklDRV9JRF9TT1VOREtOT0IJCTB4MDRBQSAvKiBHcmlmZmluIFNvdW5kS25v
YiAqLwogCisjZGVmaW5lIFVTQl9WRU5ET1JfSURfQVBDCQkweDA1MWQKKyNkZWZpbmUgVVNCX0RF
VklDRV9JRF9BUENfVVBTXzAwMDIJMHgwMDAyIC8qIEFQQyBVUFMgLSBtYW55IG1vZGVscyAqLwor
CiBzdHJ1Y3QgaGlkX2JsYWNrbGlzdCB7CiAJX191MTYgaWRWZW5kb3I7CiAJX191MTYgaWRQcm9k
dWN0OwpAQCAtMTEyMSw2ICsxMTMyLDcgQEAKIAl7IFVTQl9WRU5ET1JfSURfQVRFTiwgVVNCX0RF
VklDRV9JRF9BVEVOXzRQT1JUS1ZNLCBISURfUVVJUktfTk9HRVQgfSwKIAl7IFVTQl9WRU5ET1Jf
SURfR1JJRkZJTiwgVVNCX0RFVklDRV9JRF9QT1dFUk1BVEUsIEhJRF9RVUlSS19JR05PUkUgfSwK
IAl7IFVTQl9WRU5ET1JfSURfR1JJRkZJTiwgVVNCX0RFVklDRV9JRF9TT1VOREtOT0IsIEhJRF9R
VUlSS19JR05PUkUgfSwKKwl7IFVTQl9WRU5ET1JfSURfQVBDLCBVU0JfREVWSUNFX0lEX0FQQ19V
UFNfMDAwMiwgSElEX1FVSVJLX1NFVFJFUE9SVF9ORUVEU19JRCB9LAogCXsgMCwgMCB9CiB9Owog
Ci0tLSBsaW51eC0yLjQuMjAvZHJpdmVycy91c2IvaGlkLmguYWx0LWFwY191c2JfdXBzCTIwMDIt
MTEtMjkgMDI6NTM6MTQgKzAzMDAKKysrIGxpbnV4LTIuNC4yMC9kcml2ZXJzL3VzYi9oaWQuaAky
MDAzLTA0LTIxIDE5OjQyOjMyICswNDAwCkBAIC0xODYsNiArMTg2LDcgQEAKICNkZWZpbmUgSElE
X1FVSVJLX05PVE9VQ0gJMHgwMgogI2RlZmluZSBISURfUVVJUktfSUdOT1JFCTB4MDQKICNkZWZp
bmUgSElEX1FVSVJLX05PR0VUCQkweDA4CisjZGVmaW5lIEhJRF9RVUlSS19TRVRSRVBPUlRfTkVF
RFNfSUQJMHgxMAogCiAvKgogICogVGhpcyBpcyB0aGUgZ2xvYmFsIGVudmlyb21lbnQgb2YgdGhl
IHBhcnNlci4gVGhpcyBpbmZvcm1hdGlvbiBpcwo=

--Multipart_Tue__22_Apr_2003_18:39:39_+0400_083029a8--

--=.rPW3CATQ/UTztX
Content-Type: application/pgp-signature

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.1 (GNU/Linux)

iD8DBQE+pVQvW82GfkQfsqIRAsFoAJ4hQtrQVfe97ZioFF8d7HAvp++ZHwCfUztJ
lguft7SZDdYYOrN2tfaDTZE=
=mIxq
-----END PGP SIGNATURE-----

--=.rPW3CATQ/UTztX--