On Sun, Nov 28, 2004 at 11:03:11PM +0100, Manfred Spraul wrote:
> Hi pavel,
My name is Vojtech. ;)
> CHECK_OWNERSHIP in drivers/usb/input/hid-tmff.c tests for
> current->pid==0. The same code is used in several files (hid-lgff.c,
> usb/input/pid.c, drivers/input/joystick/iforce/iforce.h)
> Do
Am Montag, 29. November 2004 06:35 schrieb Pete Zaitcev:
> On Sun, 28 Nov 2004 22:12:29 +, Sergey Udaltsov <[EMAIL PROTECTED]> wrote:
>
> > ghm... chmod really helped (most of the time I am real idiot:) - but I
> > am not sure how to combine it with hotplug... AFAIK udev can easily be
> > tune
Oh, and FYI: this diffstat shows why I broke it
up into more focussed chunks.
drivers/usb/core/config.c |1
drivers/usb/core/devio.c| 39 ++
drivers/usb/core/hcd-pci.c |2
drivers/usb/core/hcd.c | 149 +---
driver
so u're saying there's no way to come up with a driver to wrestle
control away from the hid code, unless the kernel does not have the
support for the hid?
Look in hid-core.c or equivalent source files, there should be a hid
blacklist you can add the PID/VID of your usb mouse to. Recompile and the
On Sun, 28 Nov 2004 22:12:29 +, Sergey Udaltsov <[EMAIL PROTECTED]> wrote:
> ghm... chmod really helped (most of the time I am real idiot:) - but I
> am not sure how to combine it with hotplug... AFAIK udev can easily be
> tuned to fix /udev/* permissions - but this is /proc filesystem, so
> t
On Sat, 27 Nov 2004 19:17:20 -0800, Randy.Dunlap <[EMAIL PROTECTED]> wrote:
> >
> > i've tried unloading hid, but u know what? It always loads itself (by
> > modprobe, i suppose) in the end when i plug in my mouse.
> > /proc/bus/usb/devices tells me that. My custom module (hacked from
> > usbmouse.
On Fri, 26 Nov 2004, Lothar Wassmann wrote:
> > I'm not sure that I'm using virtual addresses for any of these.
> > I didn't change that aspect, at any rate.
> >
> So your architecture has virtual == real addresses for main memory?
Yes, this holds for lh7a400, which Michael uses.
Olav
---
Hi Alan,
On Sunday 28 November 2004 08:30, Alan Stern wrote:
>
> I suspect that root-hub polling shouldn't be controlled by flags within
> the hcd structure. The state transitions are under the control of the
> driver, so it would be wrong to make the core responsible for following
> those trans
Hi everybody,
as always i'm a little bit behind everyone (...) with my work on the
ISP1160 driver :-/
I've managed to incorporate Olav's code (especially the one used in
ohci-isp1xxx-emu.c) in mine, but there still is something not going
well, that keeps me from reaching your status. I'll describe
Much like the EHCI changes.
Updates the OHCI HCD to match API updates. This includes both new
changes (struct hcd_dev gone) and older ones (endpoints now properly
enabled/disabled, so "re"init paths aren't needed).
Signed-off-by: David Brownell <[EMAIL PROTECTED]>
--- epmax/drivers/usb/host/ohci
Slightly simpler than the EHCI and OHCI changes, since
this driver doesn't yet have an endpoint queue.
UHCI changes to match the updated HCD glue calls. Since it's handed the
relevant endpoint queue on a silver platter, the driver no longer needs
to search anything to find the queue entries.
Sign
HCDs always needed a per-endpoint queue; this makes
usbcore implement it.
This patch changes the HCD glue code to use the URB queue now kept in
usb_host_endpoint, and matching HCD API changes.
Signed-off-by: David Brownell <[EMAIL PROTECTED]>
--- epmax/drivers/usb/core/config.c 2004-11-27 23:06:0
This is just a minor annoyance, most folk seem to have
one or more of ACPI, APIC, and PCI.
Please merge.
- Dave
This changes the usbcore message about HCD IRQ problems so it makes
sense on systems without ACPI or an APIC. It also updates the comments;
the issue doesn't appiear only with PCI, and
With hcd_dev gone, the HCDs need to change a bit.
Please merge.
- Dave
Updates the EHCI HCD to match API updates. This includes both new
changes (struct hcd_dev gone) and older ones (endpoints now properly
enabled/disabled, so "re"init paths aren't needed). Hmm, the ISO
stuff could avoid that l
Every little bit of code shrinkage helps ... :)
This removes the code supporting usb_device->hcpriv allocation/deallocation,
and hcd_dev-dev_list, from usbcore and the HCDs.
Signed-off-by: David Brownell <[EMAIL PROTECTED]>
--- epmax/drivers/usb/core/hcd.c 2004-11-27 23:29:53.0 -0800
+++
This is the second set of interface changes, affecting
the HCDs.
- Dave
This changes the usbcore interfaces provided to HCDs:
- Remove usb_device->hcpriv and it allocation/deallocation hooks
- Replace struct hcd_dev with more appropriate per-endpoint state
- Update HCD apis to use usb_hos
This patch doesn't actually depend on the preceding ones.
Makes usbtest stop referencing the udev->epmaxpacket[] arrays.
Signed-off-by: David Brownell <[EMAIL PROTECTED]>
--- 1.41/drivers/usb/misc/usbtest.c Mon Nov 15 14:28:16 2004
+++ edited/drivers/usb/misc/usbtest.c Sat Nov 27 23:14:58 2004
@@
Please merge.
- Dave
Makes the CRIS HCD stop referencing the udev->epmaxpacket[] arrays.
Also makes it stop providing device allocate/deallocate routines;
this HCD doesn't need them, and a later patch will remove that API.
Signed-off-by: David Brownell <[EMAIL PROTECTED]>
--- 1.2/drivers/usb/hos
Removes another reference to this now-gone state.
- Dave
Makes EHCI stop referencing the udev->epmaxpacket[] arrays.
Signed-off-by: David Brownell <[EMAIL PROTECTED]>
--- 1.51/drivers/usb/host/ehci-sched.c Mon Nov 15 14:28:15 2004
+++ edited/drivers/usb/host/ehci-sched.c Sat Nov 27 23:14:57 2004
usb_epnum_to_ep_desc() is no longer needed (or available) ...
Please merge.
- Dave
Updates usbfs to stop using usb_epnum_to_ep_desc(). In the process,
it acquires better error detection on its urb submit path.
Signed-off-by: David Brownell <[EMAIL PROTECTED]>
--- 1.70/drivers/usb/core/devio.c
This fully resolves a FIXME to remove an awkward API.
Please merge.
- Dave
Update the auerswald driver to stop using the now-vanished
usb_epnum_to_ep_desc() function.
Signed-off-by: David Brownell <[EMAIL PROTECTED]>
--- 1.47/drivers/usb/misc/auerswald.c Wed Oct 6 14:35:09 2004
+++ edited/drive
It can't use that API any more. Please merge.
- Dave
Makes an ALSA audio driver stop referencing the udev->epmaxpacket[] arrays.
Signed-off-by: David Brownell <[EMAIL PROTECTED]>
--- 1.4/sound/usb/usx2y/usbusx2yaudio.c Fri Sep 24 01:50:04 2004
+++ edited/sound/usb/usx2y/usbusx2yaudio.c Sat Nov
These are the usbcore changes matching the previous patch;
straightforward. It's the single largest patch in this set.
Please merge.
- Dave
This patch updates usbcore to match interface changes in the previous patch.
- udev->ep[] arrays are updated during config change events and
as needed d
This is the first set of interface changes, affecting a handful
of device drivers; please merge.
This starts updating the usbcore interface to use endpoints in places it
previously used pipes or other representations of the endpoint.
- add new arrays of "struct usb_host_endpoint" pointers, mat
Hi Greg,
As promised for 2.6.11, here are patches to change how HCDs manage
per-device state. Basically, we've had per-device state hooks since
2.2.9 or so (!) but that's never matched what HCDs really needed:
per-endpoint state, tied to each endpoint's DMA queue. Now that the
2.6 USB stack mana
ghm... chmod really helped (most of the time I am real idiot:) - but I
am not sure how to combine it with hotplug... AFAIK udev can easily be
tuned to fix /udev/* permissions - but this is /proc filesystem, so
this is a bit tricky. Also, the biggest question is still about
security - could this be
Hi pavel,
CHECK_OWNERSHIP in drivers/usb/input/hid-tmff.c tests for
current->pid==0. The same code is used in several files (hid-lgff.c,
usb/input/pid.c, drivers/input/joystick/iforce/iforce.h)
Do you know why? I don't understand the reason for the test.
There are two cases where current->pid is
Am Sonntag, 28. November 2004 22:53 schrieb Sergey Udaltsov:
> Here it is:
>
> open("/proc/bus/usb/002/002", O_RDWR) = -1 EACCES (Permission denied)
> open("/proc/bus/usb/002/002", O_RDONLY) = 3
> ioctl(3, USBDEVFS_CONTROL, 0xfef9e390) = -1 EPERM (Operation not permitted)
> dup(2)
Here it is:
open("/proc/bus/usb/002/002", O_RDWR) = -1 EACCES (Permission denied)
open("/proc/bus/usb/002/002", O_RDONLY) = 3
ioctl(3, USBDEVFS_CONTROL, 0xfef9e390) = -1 EPERM (Operation not permitted)
dup(2) = 4
fcntl64(4, F_GETFL) = 0x2 (fl
Am Sonntag, 28. November 2004 20:04 schrieb Sergey Udaltsov:
> > Looking at the code it seems like libusb is used.
> > Which error exactly does it fail? How is usbfs mounted?
> $ mount | grep usb
> usbfs on /proc/bus/usb type usbfs (rw)
> $ lmctl -i
> 003.003: 046d:c50e Receiver for MX1000 Laser (C
> Looking at the code it seems like libusb is used.
> Which error exactly does it fail? How is usbfs mounted?
$ mount | grep usb
usbfs on /proc/bus/usb type usbfs (rw)
$ lmctl -i
003.003: 046d:c50e Receiver for MX1000 Laser (C-BN34) Caps: CSR SMS
Writing to USB device: Operation not permitted
Rega
On Sun, 2004-11-28 at 08:20 -0600, Paul Fulghum wrote:
> Pete Zaitcev wrote:
> > Not done #1: I asked Paul Fulghum to experiment with dropping a private
> > implementation of write callback from pl2303 and have Oleksy to test it.
Below is a patch that implements Pete's suggested fix for
the pl2303
David:
I suspect that root-hub polling shouldn't be controlled by flags within
the hcd structure. The state transitions are under the control of the
driver, so it would be wrong to make the core responsible for following
those transitions and adjusting the polling to match. Instead we can add
so
Am Sonntag, 28. November 2004 14:26 schrieb Sergey Udaltsov:
> Ghm. The author or lmctl probably did not know about it:). He just
> used this function in user-level code. So I really do not know which
> was of dealing with kernel-level usb service it is using.
>
> Actually, in the code I just see
Pete Zaitcev wrote:
Not done #1: I asked Paul Fulghum to experiment with dropping a private
implementation of write callback from pl2303 and have Oleksy to test it.
I guess I have to do it myself some time.
When you originally did not respond to my last post of 11/2
(which you did yesterday) I assu
Ghm. The author or lmctl probably did not know about it:). He just
used this function in user-level code. So I really do not know which
was of dealing with kernel-level usb service it is using.
Actually, in the code I just see
#define __KERNEL__
#include
I do not really understand the question r
Am Sonntag, 28. November 2004 12:01 schrieb Sergey Udaltsov:
> Hi all
>
> I got logitech mx1000 wireless mouse. There is utility lmctl which
> allows to read some mouse parameters - including the battery status.
> The problem is that this utility uses usb_control_msg - which fails
> beeing called
Hi,
FWIW, the attached patch gets my usb-serial toys working behind a USB 2.0
Hub under 2.4.26.
- sda
> You could work around that with this driver, making it use
> 2msec and 4msec periods.
It didn't work out, at least in 2.6 it still fails with 2 & 4. It's not a
big deal, just FYI.
Unfortunate
Hi all
I got logitech mx1000 wireless mouse. There is utility lmctl which
allows to read some mouse parameters - including the battery status.
The problem is that this utility uses usb_control_msg - which fails
beeing called from non-root (Fedora Core 3). Is there any workaround?
Any non-protected
On Fri, 26 Nov 2004 09:00:20 -0800, David Brownell <[EMAIL PROTECTED]> wrote:
> You could work around that with this driver, making it use
> 2msec and 4msec periods.
It didn't work out, at least in 2.6 it still fails with 2 & 4. It's not a
big deal, just FYI.
Unfortunately in my case, the hub is
I would like to clean up mct_u232 a little bit, although primarily to make
my fixes to 2.4 branch look better. The attached patch does this:
- zeroes whole private structure
- zaps dangling pointer (or why do we check it then)
- removes unused code for FIX_WRITE_RETURN_CODE_PROBLEM
- changes ve
Hi folks,
Being able to set the event character and latency timer can greatly
improve performance for some applications which use the ftdi_sio module
(a serial->USB converter). The following patch adds sysfs attributes,
allowing easy run-time configuration.
This is my first ever submitted patch
42 matches
Mail list logo
