Skip to content

L
linux
Switch branch/tag
  1. 09 Sep, 2004 18 commits
  3. 08 Sep, 2004 6 commits
  5. 05 Sep, 2004 8 commits
  7. 03 Sep, 2004 8 commits
    • Al Borchers's avatar
      [PATCH] USB: close waits for drain in pl2303 · 66d2dc06
      Al Borchers authored 
      Here is an additional patch for pl2303 in 2.6.9-rc1,
to be applied after my previous circular buffer patch.
This patch waits for the buffer to drain on close and
then clears the buffer.  In addition to the obvious
features, this also fixes a bug where closing a port
with a full buffer would accidentally disable writes
when the port was re-opened.

The original pl2303 could lose data that was still going
out the port on close, and even this patch only solves
the problem completely for data rates of 1200 bps and
above.

Waiting for data to drain from the circular buffer is
easy, but the problem is waiting for data to drain from
the 256 byte hardware buffer on the device.  I don't know
how much data is in the hardware buffer, so I just wait
long enough for a potentially full hardware buffer to
drain, but I don't want to wait that long for low data
rates if the buffer isn't full.  There is probably some
way to query the pl2303 to find out how much data is in
its hardware buffer, maybe snooping would reveal that.

- Added a wait for data to drain from the driver
  write buffer when closing.

- Added a wait for the data to drain from the
  device hardware buffer when closing.

- Cleared the driver write buffer when closing.
Signed-off-by: default avatarAl Borchers <alborchers@steinerpoint.com>
Signed-off-by: default avatarGreg Kroah-Hartman <greg@kroah.com>
      66d2dc06
    • Al Borchers's avatar
      [PATCH] USB: circular buffer for pl2303 · cf59b853
      Al Borchers authored 
      Here is the patch adding a circular buffer to pl2303
updated to 2.6.9-rc1.  Phil and I both tested this.
(Phil tested a slightly different earlier version.)

This fixes the carriage return newline problem Olaf
Hering reported and helps Phil with hotsyncing his
phone.  This patch also fixes a problem that would
sometimes leave a pl2303 port unable to send data,
reporting "already writing", after closing the port
while writing was in progress.  This happened about
1/3 of the time in my tests with the stock 2.6.9-rc1
pl2303 driver.


- Added a circular write buffer, protected by the
  existing spin lock.

- Write_room and chars_in_buffer now report room and
  chars in the circular buffer.

- Added a "bounce buffer" when transfering data from
  user space to the circular buffer--needed for locking.

- Replaced (urb->status != -EINPROGRESS) with a private
  write_urb_in_use flag protected by the existing spin
  lock.  Clear this flag when the urb is unlinked.

- Free memory on failed startup.

- These changes make ONLCR mapping work and fix a bug
  that would sometimes leave the port unable to write,
  reporting "already writing", after closing the port
  while writing was in progress.
Signed-off-by: default avatarAl Borchers <alborchers@steinerpoint.com>
Signed-off-by: default avatarGreg Kroah-Hartman <greg@kroah.com>
      cf59b853
    • Alan Stern's avatar
      [PATCH] USB: Nag message for usb_kill_urb · 6e145314
      Alan Stern authored 
      This patch is only for nuisance value.  It puts a nag message in the
system log every time usb_unlink_urb() is called for synchronous
unlinking.  My hope is this will speed the process of converting drivers
to use usb_kill_urb().

Don't apply this if it generates too much noise, but otherwise go ahead.
A little prodding never hurt anyone.
Signed-off-by: default avatarAlan Stern <stern@rowland.harvard.edu>
Signed-off-by: default avatarGreg Kroah-Hartman <greg@kroah.com>
      6e145314
    • Maximilian Attems's avatar
      [PATCH] usb/dabusb: insert set_current_state() before schedule_timeout() · c7c58cf3
      Maximilian Attems authored 
      After discussing this patch with Mark Hollomon, I think it is much safer
/ better to leave the conditional check within the while loop. This way
the mutex state is as expected and maintainability is not compromised.
The previous patch should not be applied.


Description: Inserts appropriate set_current_state() call so that
schedule_timeout() functions as expected.
Signed-off-by: default avatarNishanth Aravamudan <nacc@us.ibm.com>
Signed-off-by: default avatarMaximilian Attems <janitor@sternwelten.at>
Signed-off-by: default avatarGreg Kroah-Hartman <greg@kroah.com>
      c7c58cf3
    • Maximilian Attems's avatar
      [PATCH] usb/tiglusb: insert set_current_state() before schedule_timeout() · cbed817c
      Maximilian Attems authored 
      Insert set_current_state() so schedule_timeout() functions as expected.
Signed-off-by: default avatarNishanth Aravamudan <nacc@us.ibm.com>
Signed-off-by: default avatarMaximilian Attems <janitor@sternwelten.at>
Signed-off-by: default avatarGreg Kroah-Hartman <greg@kroah.com>
      cbed817c
    • Bjorn Helgaas's avatar
      [PATCH] HCD PCI probe: print actual, not ioremapped, address · e3c4c5cd
      Bjorn Helgaas authored 
      I think the USB HCD should print the actual PCI memory address, not the
ioremapped address.  AFAIK, there's no reason the ioremapped address has
to have any fixed relationship to the actual address.  Also, this makes
it match what's in /proc/iomem.  I also added a leading "0x".  Example
from ia64:

    - ehci_hcd 0000:00:01.2: irq 52, pci mem c000000080021000
    + ehci_hcd 0000:00:01.2: irq 52, pci mem 0x80021000



USB HCD: print actual PCI mem address, not the ioremapped value.
Signed-off-by: default avatarBjorn Helgaas <bjorn.helgaas@hp.com>
Signed-off-by: default avatarGreg Kroah-Hartman <greg@kroah.com>
      e3c4c5cd
    • Alan Stern's avatar
      [PATCH] USB: Remove inappropriate unusual_devs.h entry · b374dfa1
      Alan Stern authored 
      A couple of months ago you applied a patch from Torsten Scherer to create
a new unusual_devs.h entry.  In further discussions with him I learned
that the entry wasn't needed to access the device; the only reason for it
was as a workaround for some old, buggy hotplug program on his system.

Now Evan Fletcher reports that the entry actively prevents him from using
his device.  For me that's the last straw, so here's a patch to remove the
entry.  Torsten should be okay if he simply upgrades his hotplug package
or removes the buggy program.

On Mon, 30 Aug 2004, Evan Fletcher wrote:
> Hi list,
>
> I have a Bytecc 5.25" External Enclosure, model ME-320U2F, that has
> both USB 2.0 and Firewire connections
> (http://www.byteccusa.com/product/enclosure/ME-320.htm).  It used to
> work fine on earlier Linux 2.6 kernels, but stopped working a few
> revisions ago.
>
> I tracked the problem down to an entry in unusual_devs.h:
>
> /* <torsten.scherer@uni-bielefeld.de>: I don't know the name of the bridge
>  * manufacturer, but I've got an external USB drive by the Revoltec company
>  * that needs this. otherwise the drive is recognized as /dev/sda, but any
>  * access to it blocks indefinitely.
>  */
> UNUSUAL_DEV(  0x0402, 0x5621, 0x0103, 0x0103,
>                 "Revoltec",
>                 "USB/IDE Bridge (ATA/ATAPI)",
>                 US_SC_DEVICE, US_PR_DEVICE, NULL, US_FL_FIX_INQUIRY),

<...>
> So, is there some way that this entry can be modified so that my DVD+R
> works properly, and Mr. Scherer can still use his Revoltec external
> disk?
>
> Thank you,
> Evan Fletcher
Signed-off-by: default avatarAlan Stern <stern@rowland.harvard.edu>
Signed-off-by: default avatarGreg Kroah-Hartman <greg@kroah.com>
      b374dfa1
    • Andrew Morton's avatar
      [PATCH] USB: "Lost sync on frames" error in konicawc module · 2894dd88
      Andrew Morton authored 
      From: <fgalea@prism.uvsq.fr>

http://bugme.osdl.org/show_bug.cgi?id=3286

The kernel keeps printing "Lost sync on frames" error messages as soon as a
program tries to access the webcam.  No video data can be retrieved from
the webcam.

The following patch seems enough to solve the problem.  (just inverting the
order at which the old and new data blocks are sent to the user).
Signed-off-by: default avatarAndrew Morton <akpm@osdl.org>
Signed-off-by: default avatarGreg Kroah-Hartman <greg@kroah.com>
      2894dd88
GitLab Nexedi Edition | About GitLab | About Nexedi | 沪ICP备2021021310号-2 | 沪ICP备2021021310号-7