On Tuesday 05 February 2002 06:13, Mark McClelland wrote:
> Oliver Neukum wrote:
> >b) you are holding a spinlock or rwlock (does not apply to semaphores)
>
> I'm assuming that applies to the Big Kernel Lock too. If so, the V4L
> drivers need GFP_ATOMIC for the URBs they submit on open(), since
>
On Tuesday 05 February 2002 02:44, Matthew Dharm wrote:
> Is this a 2.4 or 2.5 change? Or both?
Strictly 2.5.
Regards
Oliver
___
[EMAIL PROTECTED]
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists
On Sat, Feb 02, 2002 at 11:13:26AM -0800, David Brownell wrote:
> > No, I'll say that we need to stay one physical device per device in the
> > tree.
>
> But we aren't that way today. Examples:
Ok, you're right. We want to tell the drivers to shut down (remember,
the original goal of driver
Hi all,
Here's all of the usb_submit_urb() changes in one patch:
http://www.kernel.org/pub/linux/kernel/people/gregkh/usb/2.5/usb-submit_urb-2.5.3.patch
I took Oliver's original HCD, usb.c and usb.h patch, and the rest of his
patches, converted all of the other drivers to just pass GFP_KERNEL
Oliver Neukum wrote:
>b) you are holding a spinlock or rwlock (does not apply to semaphores)
>
I'm assuming that applies to the Big Kernel Lock too. If so, the V4L
drivers need GFP_ATOMIC for the URBs they submit on open(), since
videodev.c grabs the BKL before calling the open(), release(), o
On Mon, Feb 04, 2002 at 05:44:35PM -0800, Matthew Dharm wrote:
> Is this a 2.4 or 2.5 change? Or both?
2.5 change only for now. Once things get a bit stable, we might
backport to 2.4.
thanks,
greg k-h
___
[EMAIL PROTECTED]
To unsubscribe, use the l
Is this a 2.4 or 2.5 change? Or both?
Matt
On Mon, Feb 04, 2002 at 04:43:38PM -0800, Greg KH wrote:
> On Tue, Feb 05, 2002 at 01:40:11AM +0100, Oliver Neukum wrote:
> > Explanation:
> > bus_reset may sleep but must not allocate memory as
> > it is potentially in the block io path, hence GFP_NOI
With respect to new API entries to distinguish the synchronous
and unsynchronous unlink cases:
> An asynchronous unlink due to being asynchronous allows other
> things to happen while it is underway.
Same thing for a synchronous unlink -- except the initiating
thread can't cause them, it'll be
> Specific uses (or rules of thumb ;-) ):
> -start_xmit and timeout methods of network drivers must use GFP_ATOMIC (spinlock)
You can add receive routines here as well.
Petko
___
[EMAIL PROTECTED]
To unsubscribe, use the last form
On Tuesday 05 February 2002 01:49, David Brownell wrote:
> And in fact, shouldn't all of those use GFP_NOIO?
One is in the open() code path. The other should and in
the corrected version in fact are GFP_NOIO.
Regards
Oliver
___
> > Should I write a short summary on how to decide what a driver needs ?
>
> That would be great, I'll put that in the usb_submit_urb()
> documentation.
How to decide which mem_flags to pass to usb_submit_urb
Basically the rules are the same as for kmalloc ;-)
Now let me go to the details.
Th
And in fact, shouldn't all of those use GFP_NOIO?
- Dave
- Original Message -
From: "Greg KH" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Cc: <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]>
Sent: Monday, February 04, 2002 4:32 PM
Subject: [linux-usb-devel] Re: new usb_submit_urb for storage
On Mon, 4 Feb 2002 [EMAIL PROTECTED] wrote:
> On the shelf with linux support.And get the packing that the products
> are wrapped up in with print.
The devices which will conform to standard USB classes will have
Linux support out of box.
The example is newer Phison/AVL 5in1 SmartMedia/CF/
On Tue, Feb 05, 2002 at 01:40:11AM +0100, Oliver Neukum wrote:
> Explanation:
> bus_reset may sleep but must not allocate memory as
> it is potentially in the block io path, hence GFP_NOIO not GFP_KERNEL
Thanks, applied.
greg k-h
___
[EMAIL PROTECTED]
Explanation:
bus_reset may sleep but must not allocate memory as
it is potentially in the block io path, hence GFP_NOIO not GFP_KERNEL
Regards
Oliver
--- scsiglue.c.alt Tue Feb 5 01:24:42 2002
+++ scsiglue.c Tue Feb 5 01:27:56 2002
@@ -278,7 +278,7 @@
if
Thanks. Matt, is the GFP_NOIO flag correct for transport.c?
Applied to my tree.
greg k-h
___
[EMAIL PROTECTED]
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
--- scsiglue.c.alt Tue Feb 5 01:24:42 2002
+++ scsiglue.c Tue Feb 5 01:27:56 2002
@@ -278,7 +278,7 @@
if (us->protocol == US_PR_CBI) {
down(&(us->irq_urb_sem));
us->irq_urb->dev = us->pusb_dev;
- result = usb_submit_urb(us->irq_urb);
+
On Tue, Feb 05, 2002 at 01:23:47AM +0100, Oliver Neukum wrote:
> On Tuesday 05 February 2002 01:13, Greg KH wrote:
> > Applied, thanks.
> >
> > Ok, I have everything converted, except for usb-storage. If you know of
> > any driver that should not just use GFP_KERNEL for this call, please let
> >
Got it.
thanks,
greg k-h
___
[EMAIL PROTECTED]
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
On Tuesday 05 February 2002 01:13, Greg KH wrote:
> Applied, thanks.
>
> Ok, I have everything converted, except for usb-storage. If you know of
> any driver that should not just use GFP_KERNEL for this call, please let
> me know.
Have you gone through the drivers with a chainsaw ;-) ?
I'll have
Accepted. Thanks for reminding me that submitting urbs in the callback
need GFP_ATOMIC :)
greg k-h
___
[EMAIL PROTECTED]
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
--- vicam.c.alt Tue Feb 5 01:11:47 2002
+++ vicam.c Tue Feb 5 01:14:56 2002
@@ -344,7 +344,7 @@
synchronize(vicam);
mdelay(10);
vicam_parameters(vicam);
- printk("Submiting urb: %d\n", usb_submit_urb(vicam->readurb));
+ printk("Submiting urb: %d\n", usb_su
Applied, thanks.
Ok, I have everything converted, except for usb-storage. If you know of
any driver that should not just use GFP_KERNEL for this call, please let
me know.
thanks,
greg k-h
___
[EMAIL PROTECTED]
To unsubscribe, use the last form field
--- printer.c.alt Tue Feb 5 00:55:10 2002
+++ printer.c Tue Feb 5 00:56:41 2002
@@ -242,7 +242,7 @@
if (usblp->bidir) {
usblp->readcount = 0;
usblp->readurb.dev = usblp->dev;
- if (usb_submit_urb(&usblp->readurb) < 0) {
+
Applied.
thanks,
greg k-h
___
[EMAIL PROTECTED]
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
--- pegasus.c.alt Tue Feb 5 00:48:13 2002
+++ pegasus.c Tue Feb 5 00:52:17 2002
@@ -157,7 +157,8 @@
add_wait_queue( &pegasus->ctrl_wait, &wait );
set_current_state( TASK_UNINTERRUPTIBLE );
- if ( (ret = usb_submit_urb( pegasus->ctrl_urb )) ) {
+ /* using ATO
Applied.
thanks,
greg k-h
___
[EMAIL PROTECTED]
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
--- usb-skeleton.c.alt Tue Feb 5 00:44:29 2002
+++ usb-skeleton.c Tue Feb 5 00:46:06 2002
@@ -431,7 +431,9 @@
skel_write_bulk_callback, dev);
/* send the data out the bulk port */
- retval = usb_submit_urb(dev->write_urb);
+ /* a character device
usb_submit_urb() portion applied.
thanks,
greg k-h
___
[EMAIL PROTECTED]
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
--- kaweth.c.altTue Feb 5 00:34:20 2002
+++ kaweth.cTue Feb 5 00:40:54 2002
@@ -447,7 +447,8 @@
/
* kaweth_resubmit_rx_urb
/
-static inline void ka
On Tue, Feb 05, 2002 at 12:13:19AM +0100, Oliver Neukum wrote:
> On Monday 04 February 2002 21:29, Ken Hahn wrote:
> > On Dec 19, 2001 Greg KH wrote:
> > > I'd accept a patch for a driver that has the firmware _within_ the
> > > driver, just like the current usb-serial drivers do.
> > >
> > > This
On Monday 04 February 2002 21:29, Ken Hahn wrote:
> On Dec 19, 2001 Greg KH wrote:
> > I'd accept a patch for a driver that has the firmware _within_ the
> > driver, just like the current usb-serial drivers do.
> >
> > This will let people use the driver today, and when we finally get the
> > firm
On Sun, Feb 03, 2002 at 03:53:53PM +0100, Oliver Neukum wrote:
> Here it is.
I've applied the usb_submit_urb() portion of this patch, thanks.
greg k-h
___
[EMAIL PROTECTED]
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/list
On Sun, Feb 03, 2002 at 03:47:23PM +0100, Oliver Neukum wrote:
> Hi,
>
> this makes the changes to the hid driver.
Applied.
greg k-h
___
[EMAIL PROTECTED]
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-
On Sun, 3 Feb 2002, David Brownell wrote:
> > saying USB_QUEUE_BULK does not only deal with urbs being queued to the
> > schedule (in submission order, of course), but the _same_ queueing is used
> > for the corresponding completion callback? Would be very nice to know for
> > sure. This would be
On Mon, Feb 04, 2002 at 01:54:42PM +0100, Oliver Neukum wrote:
>
> > So can you send this again, for just usb_submit_urb() with the sum of
> > the changes that you and David agreed on?
>
> Sure. Here's the most basic patch.
> Much thanks to Dave who had prepared the hcd layer already.
> Dave, do
On Mon, Feb 04, 2002 at 04:52:54PM -0500, [EMAIL PROTECTED] wrote:
>
> It would be nice to work with hardware vendors now, before they release
> their products for sale.
I don't think you will find anyone on this mailing list who disagree
with this :)
Tough part is finding those hardware vendor
It would be nice to work with hardware vendors now, before they release
their products for sale.
On the shelf with linux support.And get the packing that the products
are wrapped up in with print.
I'm just wondering if there are a lot of vendors interested in getting
their USB v2.0 devices
> Sure. Here's the most basic patch.
> Much thanks to Dave who had prepared the hcd layer already.
> Dave, do you like it ?
Looks right, except for omitting kerneldoc for the new
usb_submit_urb() parameter. Thanks for switching to
use a more meaningful name ... :)
- Dave
> Of course, it'll bre
The In-System/Cypress ISD-300 USB Mass Storage bridge is not only 2.0
compliant, it works with the current usb-storage driver in Linux at 2.0
speeds.
Matt
On Mon, Feb 04, 2002 at 09:54:42AM -0800, Chris Ahna wrote:
> Hi,
>
> I'm getting ready to test the new USB 2.0 support on a few of my
> sys
The usb-storage driver works with USB 2.0 devices as-is,
though not as fast as one might like (it doesn't queue its
requests, and thus wastes about half the bandwidth it could
use). Most folk prefer even just 12 MByte/sec transfer rates
to the USB 1.1 rates (about 1 MByte/sec), even so.
The hub
Hi,
I'm getting ready to test the new USB 2.0 support on a few of my
systems. I see that the EHCI HCD is in 2.5 but I don't see any drivers
for USB 2.0 devices. Are there Linux drivers for any USB 2.0 devices?
Thanks a lot,
Chris
___
[EMAIL PROTECTE
Hi,
I got Sharp Zaurus SL-5000D(Linux PDA), and try to connect
via docking station. It is USB Ether devices but it doesn't
be recognized by linux-2.4.17 kernel.
I'm not sure how to fix is correct. Anyway, this docking station says
it has bInterface Class:SubClass:Protocol = 02:06:00 with bNumEn
darrell wrote:
>
> I have a (Canadian) hauppauge wintv-fm 0573 4d30
>
> As a test to get it working I replaced the usbvision table entry
> for the German version, though all the entries seem to have the
> same setup values.
>
> In usbvision_probe I had to comment out
>
> if(dev->descriptor.bNu
> So can you send this again, for just usb_submit_urb() with the sum of
> the changes that you and David agreed on?
Sure. Here's the most basic patch.
Much thanks to Dave who had prepared the hcd layer already.
Dave, do you like it ?
Of course, it'll break all drivers except hub and all hcds not
On Monday 04 February 2002 01:18, David Brownell wrote:
> GFP_* is excessively cryptic, and it doesn't account for
> the slightly more meaningful SLAB_* synonyms ... :)
OK, I'll change.
> Actually, since td_alloc() is always SLAB_ATOMIC
> (artifact of locking structure) it won't need to change
>
> > It avoids a lot of effort in the disconnect methods of the network
> > drivers which would have to check and wait for an ongoing asynchronous
> > unlinking.
>
> Now I'm really not following you -- at all.
>
> Are you implying that there's some difference in the synchronous
> and asynchronous c
47 matches
Mail list logo
