hello
anybody has siemens i-surf usb isdn modem working with linux?
i poked inside the device and found 4 chip and other active/passive
componets. flash memory, mcu, usb device controller and somekind isdn chip.
i belive this modem is not yet supported by linux, so i was hoping if
some one
Am Mittwoch, 23. Oktober 2002 11:24 schrieb Joe Burks:
At 10:34 AM 10/23/2002 +0200, Oliver Neukum wrote:
Why should shutter speed setting be different from, eg. frame size?
They should be settable by the same method.
Agreed. And in V4L2 they can be. Technically it could be set through a
The following one line patch (against 2.5.44) fixes an index problem when
connecting a new hiddev
device, when kernel isn't compiled with CONFIG_USB_DYNAMIC_MINORS. Previous
attempt to open
hiddev device terminated with an ENODEV error. Note that this fix works with
either dynamic minors
flag
Ok, here is the 2.4.19-17um version of the user mode linux host controller.
This version works ok for me :), I have just tested with a usb smart card
reader.
When using it be sure that /proc/bus/usb/* files on the host have R/W access
for the user, that the user mode linux is being run as.
Also
And here is the patch for 2.5.44-1, which is against vanilla linux-2.5.44 +
uml-patch-2.5.44-1
This one enumerates the devices in the host's /proc/bus/usb and builds up
the device bus structures seemingly ok, but none of the indiviual devices
seem to appear on the UML side /proc/bus/usb, I think
On Wed, 23 Oct 2002, Oliver Neukum wrote:
Am Mittwoch, 23. Oktober 2002 01:25 schrieb David Brownell:
IMHO usb_stor_clear_halt and usb_stor_reset_common should take
dev_semaphore.
What's the race?
usb_stor_clear_halt uses a synchronous control message.
It will not be unlinked
Am Mittwoch, 23. Oktober 2002 15:41 schrieb Alan Stern:
Adding a semaphore is definitely the wrong solution.
The problem of immediately cancelling all URBs when a disconnect occurs
exists throughout the usb-storage driver, not just in usb_stor_clear_halt
and usb_stor_reset_common. It needs
On Wed, 23 Oct 2002, Oliver Neukum wrote:
Am Mittwoch, 23. Oktober 2002 15:41 schrieb Alan Stern:
The problem of immediately cancelling all URBs when a disconnect occurs
exists throughout the usb-storage driver, not just in usb_stor_clear_halt
and usb_stor_reset_common. It needs to be
I'm going to guess that you will object to the race condition that exists
between the time the flag is tested and the URB is submitted. Yes,
there's a race. But it is unavoidable, unless you want to surround every
call to the usb core with a spinlock_irq or the equivalent. And in any
On Wed, Oct 23, 2002 at 09:20:08AM +0100, Alan Cox wrote:
On Wed, 2002-10-23 at 07:12, Greg KH wrote:
On Tue, Oct 22, 2002 at 11:04:54PM -0700, John Tyner wrote:
Please don't remove the proc interface. This is a V4L issue. It's in
there because this is a V4L driver.
I saw that
Duncan Sands wrote:
On Tuesday 22 October 2002 22:15, Greg KH wrote:
...
usbfs: usb_submit_urb returned -90
Ah, if you get rid of the usbmodules binary on your system those will go
away :)
They did!
(I don't like usbmodules, but it's necessary for loading drivers for
devices plugged in
Ok, one of my original questions was if any V4L applications used the
current /proc interface. If they do, as you say, then moving them to
driverfs would not be a simple thing to do at this time.
The driverfs API is not without problems. In fact, it's close to
opening Pandora's box.
It
On Wed, Oct 23, 2002 at 06:37:19PM +0200, Oliver Neukum wrote:
Ok, one of my original questions was if any V4L applications used the
current /proc interface. If they do, as you say, then moving them to
driverfs would not be a simple thing to do at this time.
The driverfs API is not
Am Mittwoch, 23. Oktober 2002 18:45 schrieb Greg KH:
On Wed, Oct 23, 2002 at 06:37:19PM +0200, Oliver Neukum wrote:
Ok, one of my original questions was if any V4L applications used the
current /proc interface. If they do, as you say, then moving them to
driverfs would not be a simple
On Wed, Oct 23, 2002 at 05:34:53PM +0200, Oliver Neukum wrote:
I'm going to guess that you will object to the race condition that exists
between the time the flag is tested and the URB is submitted. Yes,
there's a race. But it is unavoidable, unless you want to surround every
call to
On Wed, Oct 23, 2002 at 01:28:00PM -0400, Alan Stern wrote:
Actually, I was sort of hoping to drag Matt Dharm into this discussion.
He certainly understands the issues involved and the storage driver,
probably better than anyone.
And some days, I wish I didn't
BTW, in case anyone is
Of course, drivers don't _need_ usbcore to protect them from this
race, they can handle it themselves.
But here's a case where I think it'd be wrong to use a semaphore.
Some sort of shared lock for routine use, with unbind driver from
interface processing always getting it in exclusive mode, is
On Wed, Oct 23, 2002 at 01:03:01PM +0200, [EMAIL PROTECTED] wrote:
The following one line patch (against 2.5.44) fixes an index problem when
connecting a new hiddev device, when kernel isn't compiled with
CONFIG_USB_DYNAMIC_MINORS. Previous attempt to open hiddev device
terminated with an
On Wed, Oct 23, 2002 at 06:42:44PM +0200, Duncan Sands wrote:
On Wednesday 23 October 2002 16:33, jeanseb wrote:
Duncan Sands wrote:
On Tuesday 22 October 2002 22:15, Greg KH wrote:
...
usbfs: usb_submit_urb returned -90
Ah, if you get rid of the usbmodules binary on your system
Here's a suggestion that would help all existing usb drivers. Add an
additional parameter to usb_control_msg (and the other synchronous message
subroutines as well) that takes a struct urb **. The subroutines can use
it to store a pointer to the dynamically allocated URB, so that the driver
You might recall that I am working on a user-space API to an HID device,
a digital radio. The radio is a developer's release of the product,
available to OEMs, researchers, etc. who would like to experiment with
it (that's us, experimentors). Prying information about the device's
usb
On Tue, Oct 22, 2002 at 09:22:14PM -0700, David Brownell wrote:
The EHCI driver was never adjusting the full speed maximum packet size up
(when enumerating through a transaction translating hub). This broke the
enumeration of some devices (maxpacket != 8) pretty early.
This patch updates
On Wed, Oct 23, 2002 at 01:03:01PM +0200, [EMAIL PROTECTED] wrote:
The following one line patch (against 2.5.44) fixes an index problem when
connecting a new hiddev
device, when kernel isn't compiled with CONFIG_USB_DYNAMIC_MINORS. Previous
attempt to open
hiddev device terminated with an
Yes it does. But completion routines get called at interrupt time.
However, this is not really relevant to the problem at hand.
For these cases we need a spinlock, yes.
case it doesn't matter, since we only want to guarantee that no URB
will be submitted after disconnect() _returns_.
Perhaps the real question is: Do we need to guarantee that no URBs will
remain outstanding after disconnect() returns? This seems to be what you
are getting at. Unfortunately, I haven't seen written down anywhere
exactly what conditions the driver needs to satisfy. It would be nice if
this
This could also be entirely solved by making the requirements that:
(1) The core or HCD will unlink all URBs for a removed device when
it's removed
I've wanted to see this for some time. It's now easy enough to do
for anything using the hcd.c code, since it has a list of those urbs.
In fact
On Wed, 23 Oct 2002, David Brownell wrote:
What I'd thought about was instead to just provide the URB to unlink
if the timeout failed, device was disconnected, or whatever. Why ask
for some new api notion? In fact I think I have code sitting somewhere
around here that does exactly that,
dev-some_urb = ... alloc+save, locked against disconnect ...
sync_control_message (urb, bRequest, bRequestType, ...,
INTERRUPTIBLE or maybe not, TIMEOUT or zero)
switch (urb-status) {
...
}
free dev-some_urb
and the disconnect code could just unlink all active/submitted urbs.
Is this
Ah, but re-submission of an interrupt URB from within the completion
handler will run in interrupt context.
That we'll have to deal with later.
This could also be entirely solved by making the requirements that:
(1) The core or HCD will unlink all URBs for a removed device when
(1) The core or HCD will unlink all URBs for a removed device when
it's removed
To do so you need to add the urb to a per device list, which has to be
locked. The problems arise if you loose the race. Where do you put the
lock ?
The hcd.c code which maintains that list is protected by
What I'd thought about was instead to just provide the URB to unlink
if the timeout failed, device was disconnected, or whatever. Why ask
for some new api notion? In fact I think I have code sitting somewhere
around here that does exactly that, maybe I should dig it up...
That means
Am Mittwoch, 23. Oktober 2002 20:47 schrieb David Brownell:
This could also be entirely solved by making the requirements that:
(1) The core or HCD will unlink all URBs for a removed device when
it's removed
I've wanted to see this for some time. It's now easy enough to do
for
Pete Zaitcev wrote:
Out of the blue an ALi engineer contacted me and offered a fix for
lockups in IBM i-series laptops (RH Bugzilla #50225). I would
really appreciate if someone ran it on their _regular_ ohci
to ensure that it does not break non-ALi silicon. Both 2.4 and 2.5
are the same
Dear all
I own new device: an Argosy HD530 Harddisk-enclosure with a Note-book ide disk
inside. The device works under Windows98 on the same machine, so physics should work.
When I connect the drive I can see activities in /var/log/messages,
sending an INQUIRY message to the disk.
This seems
Hi,
hcd_data_lock is taken too late.
static int hcd_submit_urb (struct urb *urb, int mem_flags)
{
int status;
struct usb_hcd *hcd = urb-dev-bus-hcpriv;
You've just followed a pointer that you haven't validated.
If the driver has improper locking,
Date: Wed, 23 Oct 2002 13:57:49 -0700
From: David Brownell [EMAIL PROTECTED]
Out of the blue an ALi engineer contacted me and offered a fix for
lockups in IBM i-series laptops (RH Bugzilla #50225). I would
really appreciate if someone ran it on their _regular_ ohci
to ensure that it
I own new device: an Argosy HD530 Harddisk-enclosure with a Note-book ide disk
inside. The device works under Windows98 on the same machine, so physics should work.
You need to say what kernel you were using, and what EHCI hardware.
Physics will always work -- it's the law! -- but that doesn't
Haven't tried that patch yet, do you have a 2.5 version?
I am wondering if the 2.5 might work as it is on i1200/i1300.
It preserves the HCFS field.
I'll get back to it when Red Hat ships a 2.6 based release.
-- Pete
---
This sf.net email is
At 11:57 AM 10/23/2002 +0200, Oliver Neukum wrote:
Why would teaching applications your ioctl be harder than
teaching them your customs procfs or driverfs file?
From a coding point of view an ioctl on a file you do a lot of
ioctls on anyway is far simpler than deducing a path to another file,
I'll reply later in detail. We could check to see if infact the
video decoder is really a SAA7113. It could
be SAA7111A.
Dwaine
Fabio Yasusi Yamamoto [EMAIL PROTECTED]@lists.sourceforge.net on
08/29/2002 07:09:20 PM
Sent by: [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
cc:
David,
Sorry I forgot to name the
kernel2.4.19-pre11
and the USB port:
NEC corporation USB 2.0
/proc/bus/usb/devices says (with no devices plugged)
cat devices
T: Bus=03 Lev=00 Prnt=00 Port=00 Cnt=00 Dev#= 1 Spd=480 MxCh= 5
B: Alloc= 0/800 us ( 0%), #Int= 0,
Am Mittwoch, 23. Oktober 2002 23:29 schrieb David Brownell:
hcd_data_lock is taken too late.
That'll go away in the final core patch to remove automagic
resubmit for interrupt ... which will no longer zero urb-dev.
That's good news, but where do you want to take it?
I don't see any
On Wed, Oct 23, 2002 at 07:24:34PM +0200, Oliver Neukum wrote:
In short, I am not sure whether writing to driverfs is a good idea
for simple everyday drivers. You've made something that's inherently
hard easy to abuse. In a way, you worked too well.
Heh, glad we succeeded :)
A model of one
Sorry I forgot to name the
kernel2.4.19-pre11
and the USB port:
NEC corporation USB 2.0
In that case upgrade your kernel and try this patch:
http://www.kernel.org/pub/linux/kernel/people/gregkh/usb/2.4/usb-ehci-2.4.20-pre11.patch
It might very well solve your
On Thu, Oct 24, 2002 at 12:06:33AM +0200, Oliver Neukum wrote:
A model of one simple file to be opened per device _is_ simpler
than a number of files to control various settings.
Plus, how do you control permissions on that thing ?
The driver controls the initial permissions. I
On Wed, 2002-10-23 at 23:11, Joe Burks wrote:
I'm fairly new to Linux kernel development. What is the proper locking
mechanism to ensure that if two processes are potentially simultaneously
executing a disconnect and proc read that no accesses to freed memory
occurs? As soon as the proc
On Wed, Oct 23, 2002 at 11:47:43AM -0700, David Brownell wrote:
If we could set usb_device-dev.state to DEVICE_GONE before we start
to disconect(), we could do even better: we could guarantee that any
new urb submissions would fail, so even a driver _trying_ to do the
wrong thing wouldn't
On Wed, Oct 23, 2002 at 10:23:02PM +0200, Oliver Neukum wrote:
This could also be entirely solved by making the requirements that:
(1) The core or HCD will unlink all URBs for a removed device when
it's removed
To do so you need to add the urb to a per device list, which has to be
On Wed, Oct 23, 2002 at 01:28:00PM -0400, Alan Stern wrote:
That shouldn't pose a problem. Greg KH can correct me if I'm wrong, but
the freeze means only that no new features are to be added. Existing ones
can still be fixed or removed.
That is true. It's also true that the freeze is for
On Thu, Oct 24, 2002 at 12:46:12AM +0200, Oliver Neukum wrote:
Seriously, this is a userspace issue. The driver can set some initial
values that it things is good, but in the end, root can change them to
whatever it wants to, nothing new there.
Most definitely not true.
1. You make it
Am Donnerstag, 24. Oktober 2002 00:45 schrieb Matthew Dharm:
On Wed, Oct 23, 2002 at 10:23:02PM +0200, Oliver Neukum wrote:
This could also be entirely solved by making the requirements that:
(1) The core or HCD will unlink all URBs for a removed device when
it's removed
To do so
Am Donnerstag, 24. Oktober 2002 00:24 schrieb Greg KH:
On Thu, Oct 24, 2002 at 12:06:33AM +0200, Oliver Neukum wrote:
A model of one simple file to be opened per device _is_ simpler
than a number of files to control various settings.
Plus, how do you control permissions on that thing
Am Donnerstag, 24. Oktober 2002 00:53 schrieb Greg KH:
On Thu, Oct 24, 2002 at 12:46:12AM +0200, Oliver Neukum wrote:
Seriously, this is a userspace issue. The driver can set some initial
values that it things is good, but in the end, root can change them to
whatever it wants to,
I wonder if he'd comment on what it'd mean to call device_unregister()
earlier in usb_disconnect() ... like right at the top, not the last
thing. The docs imply that'd be OK.
Which device_unregister? For the interfaces or the device?
Well the whole device is DEVICE_GONE, including
On Wed, Oct 23, 2002 at 05:32:50PM -0700, David Brownell wrote:
I wonder if he'd comment on what it'd mean to call device_unregister()
earlier in usb_disconnect() ... like right at the top, not the last
thing. The docs imply that'd be OK.
Which device_unregister? For the interfaces or
Certainly the device itself, since
that's what currently drives the submit logic ... so that's what
would need to know that it's GONE, to let the submit logic reject
new urb submissions.
Yes, usb_submit_urb() can just check the device state. But what's to
keep the device from being removed
Mahlzeit
On Tue, Oct 22, 2002 at 11:25:14PM -0700, Greg KH wrote:
I agree, nice to see that many devices working that well. Are they all
on the same USB bus, or do you have different host controllers running
at the same time?
They are at the same host controller. One directly and the other
On Wed, 2002-10-23 at 07:12, Greg KH wrote:
On Tue, Oct 22, 2002 at 11:04:54PM -0700, John Tyner wrote:
Please don't remove the proc interface. This is a V4L issue. It's in
there because this is a V4L driver.
I saw that you were going to raise the issue on that list. I said the patch
On Wed, 2002-10-23 at 06:53, John Tyner wrote:
1. Who can write these settings? How do you control that?
I set permissions to rw-r--r--. Don't these files get owned by root when
created?
Yes, which is probably wrong for the proc file. It should precisely
mirror the current permissions of
Am Mittwoch, 23. Oktober 2002 07:53 schrieb John Tyner:
1. Who can write these settings? How do you control that?
I set permissions to rw-r--r--. Don't these files get owned by root when
created?
Yes, that's the problem. Consequently device permissions themselves would
have to be 644, which
At 10:34 AM 10/23/2002 +0200, Oliver Neukum wrote:
Why should shutter speed setting be different from, eg. frame size?
They should be settable by the same method.
Agreed. And in V4L2 they can be. Technically it could be set through a
vicam-specific ioctl, but if that were the only way to set
61 matches
Mail list logo
