On Wed, Oct 23, 2002 at 09:25:05PM -0700, David Brownell wrote:
>
> Think of it as a proof-by-induction that shutdown will work. When
> there's a point past which no more activities can be started (like
> when device state becomes GONE), and existing activities all get
> canceled, shutdown will c
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 _rig
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
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 interfac
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 t
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
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
> >
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. Y
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 ha
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 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 wo
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 pro
Am Donnerstag, 24. Oktober 2002 00:19 schrieb David Brownell:
> > The problem is not NULL but a pointer to freed memory.
> > The correct sequence in the driver is:
> > down(mutex_with_disconnect);
> > if (privat->device_is_still_present)
> > usb_submit_urb(urb);
> > up(mutex_with_disconnect);
>
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 permis
The problem is not NULL but a pointer to freed memory.
The correct sequence in the driver is:
down(mutex_with_disconnect);
if (privat->device_is_still_present)
usb_submit_urb(urb);
up(mutex_with_disconnect);
More like:
submit (even in completion callbacks) by
grabbing driver lock
if devi
At 11:57 AM 10/23/2002 +0200, Oliver Neukum wrote:
> The risk being run here (root might change camuser's shutter speed on him /
> disconnect at just the wrong time) is less than the benefit (the shutter
> speed can be changed).
No, most emphatically not. Risking data corruption due to accessing
> > 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 think it will be up to
> userspace to control them after that.
Y
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 prob
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
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 sign
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, #
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:
Subj
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,
open
> 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
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'
> 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
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.
I've been running that patch without seeing any problems
attributed to it, so I suspect I'll submit it soon to Greg.
- Dave
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, y
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
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 (approxim
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
> 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
(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 hcd_
> 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
>
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 th
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,
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
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 sor
> 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() _retu
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 w
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 update
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 interfac
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
wou
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 usbmodul
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 wit
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, i
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 int
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
> > c
On Wed, 23 Oct 2002, 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 the usb core wit
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
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
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 those will go
> >>away :)
> >
> > They did!
> >
> >>(
> 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 tu
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
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'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
T
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
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 ne
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.
> >
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 w
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 in
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 ena
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 throug
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 co
On Fri, Oct 18, 2002 at 11:29:54PM +0200, Pavel Machek wrote:
> This is zaurus support for usbnet. Unlike usbdnet, it should not eat
> disks. Diff against 2.5.42; please apply.
> Pavel
Hi,
I have the new zaurus from Sharp lauch in July
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
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, wh
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 o
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
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 othe
70 matches
Mail list logo
