On Thu, Nov 15, 2001 at 07:51:42PM -0800, David Brownell wrote:
>
> I almost submitted a patch like that this summer, but didn't
> because I ran across some followon problems. I forget
> the details, but in principle it should be safe to guard against
> such problems like this.
>
> Clearly it's
Ta. Just confused I guess.
On Thu, 15 Nov 2001, Greg KH wrote:
> On Thu, Nov 15, 2001 at 06:33:29PM -0800, Stephen J. Gowdy wrote:
> > I thought the precedence was the other way round (if there is the chance
> > of NULL pointers)?
>
> Nope, left to right is the order.
>
> thanks,
>
> greg k-
On Thu, Nov 15, 2001 at 06:33:29PM -0800, Stephen J. Gowdy wrote:
> I thought the precedence was the other way round (if there is the chance
> of NULL pointers)?
Nope, left to right is the order.
thanks,
greg k-h
___
[EMAIL PROTECTED]
To unsubscribe
At 11:34 AM 11/15/01 -0800, Greg KH wrote:
>On Thu, Nov 15, 2001 at 04:09:59PM +0530, Praveen Madhavan wrote:
> > Would you send me the patch or link for latest bluetooth.c.
It's available in the latest kernel source tree at kernel.org.
Thanks Greg..
> > I mean, ttydriver write funct
> Here's a tiny patch that fixes a potential oops that drivers could
> cause in usb_unlink_urb() and usb_submit_urb(). I traced down a race
> condition that the visor driver was ending up calling usb_unlink_urb()
> after it had been removed, and the urb->dev->bus was removed.
>
> What do people
I thought the precedence was the other way round (if there is the chance
of NULL pointers)?
On Thu, 15 Nov 2001, Greg KH wrote:
> Hi all,
>
> Here's a tiny patch that fixes a potential oops that drivers could
> cause in usb_unlink_urb() and usb_submit_urb(). I traced down a race
> condition t
Hrm
I thought that when a device was removed, the data structure wasn't freed
until after the disconnect() routine returned. If that's the case, then it
would seem to make sense that none of the sub-structures (ie. the bus
structure) would be freed either until after the device structure was
Hi all,
Here's a tiny patch that fixes a potential oops that drivers could
cause in usb_unlink_urb() and usb_submit_urb(). I traced down a race
condition that the visor driver was ending up calling usb_unlink_urb()
after it had been removed, and the urb->dev->bus was removed.
What do people thi
On Thursday, 15. November 2001 16:08, Ken Hahn wrote:
> Brad Hards wrote:
> Yeah, it's about what you are describing.
>
> Something to the effect of:
> usb.c: USB device no accepting new address=6
> usb.c: USB device no accepting new address=7
>
> You get to see the same thing with the retry's in
Orjan Friberg wrote:
>
> The thing that puzzles me is how iso_frame_desc is set up in
> usbout_start and usbout_prepare_desc. transfer_buffer_length is set to
> 50, and number_of_packets is 5. But iso_frame_desc[i].length is set to
> 8 for 0 <= i <= 4 (and iso_frame_desc[i].offset is i * 8), fo
On Thu, Nov 15, 2001 at 04:09:59PM +0530, Praveen Madhavan wrote:
> Would you send me the patch or link for latest bluetooth.c.
It's available in the latest kernel source tree at kernel.org.
> I think bluetooth_write( tty->ttydriver->write) function need not to be
> a blocking call always.
Hi all,
can anybody help me develop a driver for my Samsung YP-20S MP3 Player ?
I tried it with usb-robot but i failed badly :-(
Thanks
Martin
--
NO ONE WANTS TO HEAR ABOUT MY SCIATICA
NO ONE WANTS TO HEAR ABOUT MY SCIATICA
NO ONE WANTS TO HEAR ABOUT MY SCIATICA
NO ONE WANTS TO HEAR ABOUT MY SC
Hi list,
I'm adding support for isoc out traffic to the CRIS host usb driver.
More specifically, I'm trying to make a couple of Philips DSS350/17 usb
speakers to work. They worked fine on my Linux host machine (running a
2.2.19 kernel) which uses the same generic usb audio framework. My
method
Brad Hards wrote:
> Just a thought: the place where HUB_PROBE_TRIES is used is
> usb_hub_port_connect_change(), which calls usb_hub_port_reset(), which in
turn
> is the source of the "USB device not accepting new address" error. Could
we be
> falling foul of some marginal condition that is masked
Hi Greg !
At 10:10 AM 11/8/01 -0800, Greg KH wrote:
>What kernel version are you looking at? That check has been removed
>from the code for a few months now.
Kernel version: 2.4.2
Would you send me the patch or link for latest bluetooth.c.
> >Seriously, the bluetooth_write() function can
benoit walter wrote:
>Hello,
>
>I found why it did not work. The problem is that my device was not listed
>in the header file.
>
Could I possibly get the VendorID and ProductID from you. Also the
description of the product from
the box. I like to get the exact product name.
>I don't k
Ken Hahn wrote:
>
> Cool, I had wondered if that kinda thing could be/was done (makes much more
> sense), but there remains one thing to be resolved. The device still isn't
> recognized as I described in the last e-mail unless we up the retrys to 3.
> Is it possible to get that changed?
I just h
17 matches
Mail list logo
