On Sat, 27 May 2006, Paul Giblock wrote:
> Wolfgang -
>
> > Aaah... the user should not be able to send the second command, if the
> > first command is not finished. So you basicly have 2 choices:
> > a) let the user write() function sleep (=blocking) until the first
> > command is finished.
>
>
On Sun, 28 May 2006, Norbert Preining wrote:
> > Try reverting all the patches you have made except the one that adds
> > msleep() after the line setting srb->result. Instead of calling msleep,
> > have it goto Handle_Errors.
>
> Yup done. Nice ... I still get a lot of resets, but the copying
Hi Alan!
On Sam, 27 Mai 2006, Alan Stern wrote:
> > - the usb control interface works, lsusb -v does work all the time
> > and the stuff is seen in usbmon
>
> It's not uncommon for one part of a USB interface (the part that handles
It was only for your info, someone asked me about this.
> >
On Sat, May 27, 2006 at 01:03:58AM +0400, Vitja Makarov wrote:
> Hi, all!
>
> I've recently found that ftdi_sio driver could cause some problems:
>
> * kernel panic: write much more data than device can transimt at once
> and disconnect device, system hangs((
> * ftdi_sio could ran out of memory
Wolfgang -
Aaah... the user should not be able to send the second command, if the
first command is not finished. So you basicly have 2 choices:
a) let the user write() function sleep (=blocking) until the first
command is finished.
This _would_ be ideal except I would need a way to signal the
On Fri, 26 May 2006, Norbert Preining wrote:
> Dear Alan!
>
> On Fre, 26 Mai 2006, Alan Stern wrote:
> > UNUSUAL_DEV( 0x1006, 0x3003, 0x0100, 0x0100,
> > "iRiver",
> > "H300 Series",
> > US_SC_DEVICE, US_PR_DEVICE, NULL,
> > US_FL_GO_SLOW ),
>
> O
On Fri, May 26, 2006 at 01:34:10PM -0700, Pete Zaitcev wrote:
> On Fri, 26 May 2006 20:22:17 +0200, Frank Gevaerts <[EMAIL PROTECTED]> wrote:
>
> > usb 1-4.5.7: USB disconnect, address 79
> > [ cut here ]
> > kernel BUG at kernel/workqueue.c:110!
>
> Please let me know if
On Saturday 27 May 2006 13:36, Christian Iversen wrote:
> On Saturday 27 May 2006 13:30, Michael Hanselmann wrote:
> > Hello Andrew
> >
> > On Fri, May 26, 2006 at 01:16:30PM -0700, Andrew Morton wrote:
> > > > + up(&pdata->bd->sem);
> > > > + retval = appledisplay_bl_get_brightness(pda
On Saturday 27 May 2006 13:30, Michael Hanselmann wrote:
> Hello Andrew
>
> On Fri, May 26, 2006 at 01:16:30PM -0700, Andrew Morton wrote:
> > > + up(&pdata->bd->sem);
> > > + retval = appledisplay_bl_get_brightness(pdata->bd);
> > > + if (retval >= 0)
> > > + pdata->bd->props->brightness =
Hello Andrew
On Fri, May 26, 2006 at 01:16:30PM -0700, Andrew Morton wrote:
> > + up(&pdata->bd->sem);
> > + retval = appledisplay_bl_get_brightness(pdata->bd);
> > + if (retval >= 0)
> > + pdata->bd->props->brightness = retval;
> > + down(&pdata->bd->sem);
> Gee it's odd to go
Hello Paul,
On Saturday 27 May 2006 11:27, Paul Giblock wrote:
> Another problem is the way the radio seeks. To increase the
> frequency I must send two messages, in sequence, with a delay in
> between them. Then, I must wait for the next report sent from the
> device.
Why don't you use kernel t
Do all these URBs get created when the user writes to your driver's device
file? If they do, then a simple approach needs only a mutex (so that only
one write can happen at a time) and the value of "jiffies" as of the last
URB. If the current transfer is too soon after the last one, do an
inter
12 matches
Mail list logo
