Skip to content

R
raspberrypi-kernel

openeuler / raspberrypi-kernel

通知 13
Star 1
Fork 0
R
raspberrypi-kernel
切换分支/标签
  1. 04 5月, 2012 3 次提交
  3. 03 5月, 2012 1 次提交
  5. 30 4月, 2012 1 次提交
  7. 26 4月, 2012 7 次提交
  9. 24 4月, 2012 1 次提交
  11. 21 4月, 2012 3 次提交
  13. 20 4月, 2012 5 次提交
  15. 19 4月, 2012 1 次提交
  17. 18 4月, 2012 1 次提交
  19. 11 4月, 2012 11 次提交
  21. 10 4月, 2012 6 次提交
    • A
      USB: sierra: add support for Sierra Wireless MC7710 · c5d703dc
      由 Anton Samokhvalov 提交于 
      Just add new device id. 3G works fine, LTE not tested.
Signed-off-by: NAnton Samokhvalov <pg83@yandex.ru>
Cc: stable <stable@vger.kernel.org>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      c5d703dc
    • S
      USB: ftdi_sio: fix race condition in TIOCMIWAIT, and abort of TIOCMIWAIT when the device is removed · 876ae50d
      由 Simon Arlott 提交于 
      There are two issues here, one is that the device is generating
spurious very fast modem status line changes somewhere:

CTS becomes high then low 18µs later:
[121226.924373] ftdi_process_packet: prev rng=0 dsr=10 dcd=0 cts=6
[121226.924378] ftdi_process_packet: status=10 prev=00 diff=10
[121226.924382] ftdi_process_packet: now rng=0 dsr=10 dcd=0 cts=7
(wake_up_interruptible is called)
[121226.924391] ftdi_process_packet: prev rng=0 dsr=10 dcd=0 cts=7
[121226.924394] ftdi_process_packet: status=00 prev=10 diff=10
[121226.924397] ftdi_process_packet: now rng=0 dsr=10 dcd=0 cts=8
(wake_up_interruptible is called)

This wakes up the task in TIOCMIWAIT:
[121226.924405] ftdi_ioctl: 19451 rng=0->0 dsr=10->10 dcd=0->0 cts=6->8
(wait from 20:51:46 returns and observes both changes)

Which then calls TIOCMIWAIT again:
20:51:46.400239 ioctl(3, TIOCMIWAIT, 0x20) = 0
22:11:09.441818 ioctl(3, TIOCMGET, [TIOCM_DTR|TIOCM_RTS]) = 0
22:11:09.442812 ioctl(3, TIOCMIWAIT, 0x20) = -1 EIO (Input/output error)
(the second wake_up_interruptible takes effect and an I/O error occurs)

The other issue is that TIOCMIWAIT will wait forever (unless the task is
interrupted) if the device is removed.

This change removes the -EIO return that occurs if the counts don't
appear to have changed. Multiple counts may have been processed as
one or the waiting task may have started waiting after recording the
current count.

It adds a bool to indicate that the device has been removed so that
TIOCMIWAIT doesn't wait forever, and wakes up any tasks so that they can
return -EIO.
Signed-off-by: NSimon Arlott <simon@fire.lp0.eu>
Cc: stable <stable@vger.kernel.org>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      876ae50d
    • S
      USB: ftdi_sio: fix status line change handling for TIOCMIWAIT and TIOCGICOUNT · fca5430d
      由 Simon Arlott 提交于 
      Handling of TIOCMIWAIT was changed by commit 1d749f9a
 USB: ftdi_sio.c: Use ftdi async_icount structure for TIOCMIWAIT, as in other drivers

FTDI_STATUS_B0_MASK does not indicate the changed modem status lines,
it indicates the value of the current modem status lines. An xor is
still required to determine which lines have changed.

The count was only being incremented if the line was high. The only
reason TIOCMIWAIT still worked was because the status packet is
repeated every 1ms, so the count was always changing. The wakeup
itself still ran based on the status lines changing.

This change fixes handling of updates to the modem status lines and
allows multiple processes to use TIOCMIWAIT concurrently.

Tested with two processes waiting on different status lines being
toggled independently.
Signed-off-by: NSimon Arlott <simon@fire.lp0.eu>
Cc: Uwe Bonnes <bon@elektron.ikp.physik.tu-darmstadt.de>
Cc: stable <stable@vger.kernel.org>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      fca5430d
    • A
      USB: fix bug in serial driver unregistration · 891a3b1f
      由 Alan Stern 提交于 
      This patch (as1536) fixes a bug in the USB serial core.  Unloading and
reloading a serial driver while a serial device is plugged in causes
errors because of the code in usb_serial_disconnect() that tries to
make sure the port_remove method is called.  With the new order of
driver registration introduced in the 3.4 kernel, this is definitely
not the right thing to do (if indeed it ever was).

The patch removes that whole section code, along with the mechanism
for keeping track of each port's registration state, which is no
longer needed.  The driver core can handle all that stuff for us.

Note: This has been tested only with one or two USB serial drivers.
In theory, other drivers might still run into trouble.  But if they
do, it will be the fault of the drivers, not of this patch -- that is,
the drivers will need to be fixed.
Signed-off-by: NAlan Stern <stern@rowland.harvard.edu>
Reported-and-tested-by: NJohan Hovold <jhovold@gmail.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      891a3b1f
    • A
      USB: serial: metro-usb: Fix idProduct for Uni-Directional mode. · 3a450850
      由 Aleksey Babahin 提交于 
      The right idProduct for Metrologic Bar Code Scanner
in Uni-Directional Serial Emulation mode is 0x0700.

Also rename idProduct for Bi-Directional mode to be a bit more informative.
Signed-off-by: NAleksey Babahin <tamerlan311@gmail.com>
Cc: stable <stable@vger.kernel.org>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      3a450850
    • S
      USB: option: re-add NOVATELWIRELESS_PRODUCT_HSPA_HIGHSPEED to option_id array · 9ac2feb2
      由 Santiago Garcia Mantinan 提交于 
      Re-add NOVATELWIRELESS_PRODUCT_HSPA_HIGHSPEED to option_id array
Signed-off-by: NSantiago Garcia Mantinan <manty@debian.org>
Cc: stable <stable@vger.kernel.org>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      9ac2feb2