25 Sep, 2014
1 commit
-
…it/johan/usb-serial into usb-next
Johan writes:
USB-serial fixes for v3.17
Here are two more device IDs for v3.17.
Signed-off-by: Johan Hovold <johan@kernel.org>
24 Sep, 2014
39 commits
-
It seems that only choose_devnum() was not ready to process more hub
events at the same time.All should be fine if we take bus->usb_address0_mutex there. It will
make sure that more devnums will not be chosen for the given bus and
the related devices at the same time.Signed-off-by: Petr Mladek
Acked-by: Alan Stern
Signed-off-by: Greg Kroah-Hartman -
USB hub has started to use a workqueue instead of kthread. Let's update
the documentation and comments here and there.This patch mostly just replaces "khubd" with "hub_wq". There are only few
exceptions where the whole sentence was updated. These more complicated
changes can be found in the following files:Documentation/usb/hotplug.txt
drivers/net/usb/usbnet.c
drivers/usb/core/hcd.c
drivers/usb/host/ohci-hcd.c
drivers/usb/host/xhci.cSigned-off-by: Petr Mladek
Acked-by: Alan Stern
Signed-off-by: Greg Kroah-Hartman -
USB hub started to use a workqueue instead of kthread. Let's make it clear from
the function names.Signed-off-by: Petr Mladek
Acked-by: Alan Stern
Signed-off-by: Greg Kroah-Hartman -
There is no need to have separate kthread for handling USB hub events.
It is more elegant to use the workqueue framework.The workqueue is allocated as freezable because the original thread was
freezable as well.Also it is allocated as ordered because the code is not ready for parallel
processing of hub events, see choose_devnum().struct usb_hub is passed via the work item. Therefore we do not need
hub_event_list.Also hub_thread() is not longer needed. It would call only hub_event().
The rest of the code did manipulate the kthread and it is handled by the
workqueue framework now.kick_khubd is renamed to kick_hub_wq() to make the function clear. And the
protection against races is done another way, see below.hub_event_lock has been removed. It cannot longer be used to protect struct
usb_hub between hub_event() and hub_disconnect(). Instead we need to get
hub->kref already in kick_hub_wq().The lock is not really needed for the other scenarios as well. queue_work()
returns whether it succeeded. We could revert the needed operations
accordingly. This is enough to avoid duplicity and inconsistencies.Yes, the removed lock causes that there is not longer such a strong
synchronization between scheduling the work and manipulating
hub->disconnected.But kick_hub_wq() must never be called together with hub_disconnect()
otherwise even the original code would have failed. Any callers are
responsible for this.Therefore the only problem is that hub_disconnect() could be called in parallel
with hub_event(). But this was possible even in the past. struct usb_hub is
still guarded by hub->kref and released in hub_events() when needed.Note that the source file is still full of the obsolete "khubd" strings.
Let's remove them in a follow up patch. This patch already is complex enough.Thanks a lot Alan Stern for code review, many useful
tips and guidance. Also thanks to Tejun Heo for hints how to
allocate the workqueue.Signed-off-by: Petr Mladek
Acked-by: Alan Stern
Signed-off-by: Greg Kroah-Hartman -
We would like to convert khubd kthread to a workqueue. As a result hub_events()
will handle only one event per call.In fact, we could do this already now because there is another cycle in
hub_thread(). It calls hub_events() until hub_event_list is empty.This patch renames the function to hub_event(), removes the while cycle, and
renames the goto targets from loop* to out*.When touching the code, it fixes also formatting of dev_err() and dev_dbg()
calls to make checkpatch.pl happy :-)Signed-off-by: Petr Mladek
Acked-by: Alan Stern
Signed-off-by: Greg Kroah-Hartman -
This is just a small optimization of the fix from the commit c605f3cdff53a743f6
("usb: hub: take hub->hdev reference when processing from eventlist).We do not need to take the reference for each event. Instead we could get it
when struct usb_hub is allocated and put it when it is released. By other words,
we could handle it the same way as the reference for hub->intfdev.The motivation is that it will make the life easier when switching from khubd
kthread to a workqueue.Suggested-by: Alan Stern
Signed-off-by: Petr Mladek
Acked-by: Alan Stern
Signed-off-by: Greg Kroah-Hartman -
There is apparently another SCM USB-SCSI converter with ID 04E6:000F. It
is listed along with 04E6:000B in the Windows INF file for the Startech
ICUSBSCSI2 as "eUSB SCSI Adapter (Bus Powered)". The quirk allows
devices with SCSI ID other than 0 to be accessed.Also make a couple of existing SCM product IDs lower case to be
consistent with other entries.Signed-off-by: Mark Knibbs
Signed-off-by: Greg Kroah-Hartman -
Castlewood Systems supplied various models of USB-SCSI converter with their
ORB external removable-media drive. The ORB Windows and Macintosh drivers
support six USB IDs:
084B:A001 [VID 084B is Castlewood Systems]
04E6:0002 (*) ORB USB Smart Cable P/N 88205-001 (generic SCM ID)
2027:A001 Double-H Technology DH-2000SC
1822:0001 (*) Ariston iConnect/iSCSI
07AF:0004 (*) Microtech XpressSCSI (25-pin)
07AF:0005 (*) Microtech XpressSCSI (50-pin)*: quirk already in unusual-devs.h
[Apparently the official VID for Double-H Technology is 0x07EB = 2027
decimal. That's another hex/decimal mix-up with these SCM-based products
(in addition to the Ariston and Entrega ones). Perhaps the USB-IF informed
companies of their allocated VID in decimal, but they assumed it was hex?
It seems all Entrega products used VID 0x1645, not just the USB-SCSI
converter.]Double-H Technology Co., Ltd. produced a USB-SCSI converter, model
DH-2000SC, which is probably the one supported by the ORB drivers. Perhaps
the Castlewood-bundled product had a different label or PID though?
Castlewood mentioned Conmate as being one type of USB-SCSI converter.
Conmate and Double-H seem related somehow; both company addresses in the
same road, and at one point the Conmate web site mentioned DH-2000H4,
DH-200D4/DH-2000C4 as models of USB hub (DH short for Double-H presumably).
Conmate did show a USB-SCSI converter model CM-660 on their web site at one
point. My guess is that was identical to the DH-2000SC.Mention of the Double-H product:
http://web.archive.org/web/20010221010141/http://www.doubleh.com.tw/dh-2000sc.htm
The only picture I could find is at
http://jp.acesuppliers.com/catalog/j64/component/page03.html
The casing design looks the same as my ORB USB Smart Cable which has ID
04E6:0002.Anyway, that's enough rambling. Here's the patch.
storage: Add quirks for Castlewood and Double-H USB-SCSI converters
Add quirks for two SCM-based USB-SCSI converters which were bundled with
some Castlewood ORB removable drives. Without the quirk only the (single)
drive with SCSI ID 0 can be accessed.Signed-off-by: Mark Knibbs
Signed-off-by: Greg Kroah-Hartman -
usb_stor_euscsi_init() calls usb_stor_control_msg() with timeout
argument 5000. USB_CTRL_SET_TIMEOUT is defined to be 5000 in usb.h, so
would it make sense to use that instead? Patch below if it would.Signed-off-by: Mark Knibbs
Signed-off-by: Greg Kroah-Hartman -
Use the BIT macro instead of "open coding" bit fields. This makes it
easier to actually see that the bits are not conflicting/overlapping.Signed-off-by: Greg Kroah-Hartman
-
This full-speed USB device generates spurious remote wakeup event
as soon as USB_DEVICE_REMOTE_WAKEUP feature is set. As the result,
Linux can't enter system suspend and S0ix power saving modes once
this keyboard is used.This patch tries to introduce USB_QUIRK_IGNORE_REMOTE_WAKEUP quirk.
With this quirk set, wakeup capability will be ignored during
device configure.This patch could be back-ported to kernels as old as 2.6.39.
Signed-off-by: Lu Baolu
Acked-by: Alan Stern
Cc: stable
Signed-off-by: Greg Kroah-Hartman -
The current comment sounds like you have to disable some of
the ports to be able to use self-powered mode. This is
misleading, so change the wording to reflect this.Signed-off-by: Tobias Jakobi
Signed-off-by: Greg Kroah-Hartman -
'availe' to 'available'
'desribed' to 'described'Signed-off-by: Tobias Jakobi
Signed-off-by: Greg Kroah-Hartman -
intn is obviously the interrupt pin.
Signed-off-by: Tobias Jakobi
Signed-off-by: Greg Kroah-Hartman -
Fixed typos in comments of various drivers/usb files
Signed-off-by: Mickael Maison
Acked-by: Felipe Balbi
Signed-off-by: Greg Kroah-Hartman -
Instead of dereference each byte let's use %*ph specifier in the printk()
calls.Signed-off-by: Andy Shevchenko
Signed-off-by: Greg Kroah-Hartman -
Need include it for irq_of_parse_and_map(), the related error with
allmodconfig under microblaze:drivers/usb/host/ehci-xilinx-of.c: In function ‘ehci_hcd_xilinx_of_probe’:
drivers/usb/host/ehci-xilinx-of.c:156:2: error: implicit declaration of function ‘irq_of_parse_and_map’ [-Werror=implicit-function-declaration]
irq = irq_of_parse_and_map(dn, 0);
^Signed-off-by: Chen Gang
Acked-by: Michal Simek
Signed-off-by: Greg Kroah-Hartman -
If three or more wireless devices are connected and two of them
disconnect between 1-3 seconds apart, it can cause the HWA to disconnect
the remaining devices due to failing to see a DN_Alive message from
them. This happens because when the HWA detects that the first device
is gone, it will attempt to rekey the remaining devices. If one of the
devices is not responding because it has also been disconnected but not
yet timed out, the synchronous rekey operation running on the wusbd
workqueue can block for up to 5 seconds. This will prevent the
KEEPALIVE timer from running and DN_Alive messages from being processed
because they are processed by the same workqueue. This patch moves the
rekey operation to a separate workqueue since it is the only wusb work
item that needs to communicate directly with wireless devices. The rest
of the WUSB work items either perform no device IO or communicate
directly with the host controller and should not be blocked out by a
non-responding wireless device.Signed-off-by: Thomas Pugliese
Signed-off-by: Greg Kroah-Hartman -
When completing an aborted transfer, skip done segs before calling
wa_complete_remaining_xfer_segs to avoid a runtime warning. The warning
is harmless in this case but avoiding it prevents false error reports.Signed-off-by: Thomas Pugliese
Signed-off-by: Greg Kroah-Hartman -
Add USB build dependency for USB_WUSB_CBAF.
Signed-off-by: Thomas Pugliese
Signed-off-by: Greg Kroah-Hartman -
Wireless USB does not require PCI so remove USB_WUSB build dependency on
PCI.Signed-off-by: Thomas Pugliese
Signed-off-by: Greg Kroah-Hartman -
An HWA is a USB device so it depends on USB.
Signed-off-by: Thomas Pugliese
Signed-off-by: Greg Kroah-Hartman -
Document the /sys/class/uwb_rc/uwbN/ASIE sysfs attribute
Signed-off-by: Thomas Pugliese
Signed-off-by: Greg Kroah-Hartman -
Allow user mode to add and remove application specific information
elements (ASIEs) to the beacon of a uwb_rc device.Signed-off-by: Thomas Pugliese
Signed-off-by: Greg Kroah-Hartman -
The existing UWB documentation states that UWB devices show up in
/sys/class/uwb and /sys/bus/uwb/devices. Up until the most recent
changes to add uwb devices to their own bus, neither of these statements
were actually true. Now, UWB devices do show up in /sys/bus/uwb/devices
so the documentation has been updated to reflect that and removed
references to /sys/class/uwb.The existing documentation also states that local UWB radio controller
(RC) devices also show up as UWB devices along with their wireless peer
UWB devices under /sys/class/uwb. This is not true so that statement
has been removed.Signed-off-by: Thomas Pugliese
Signed-off-by: Greg Kroah-Hartman -
Documentation/usb/WUSB-Design-overview.txt states that UWB devices seen
by a UWB radio controller are added to /sys/bus/uwb/devices, but this
was not actually being done. This functionality is needed in order for
UWB peer devices to be enumerated by user mode tools. This patch
creates a uwb bus type and adds UWB peer devices to it as they are
discovered by the radio controller.Signed-off-by: Thomas Pugliese
Signed-off-by: Greg Kroah-Hartman -
UWB does not require PCI to be enabled so remove build dependency.
Signed-off-by: Thomas Pugliese
Signed-off-by: Greg Kroah-Hartman -
Print info about the radio controller device instead of the its parent
when UWB devices connect and disconnect.Signed-off-by: Thomas Pugliese
Signed-off-by: Greg Kroah-Hartman -
Fix line length in uwb-internal.h
Signed-off-by: Thomas Pugliese
Signed-off-by: Greg Kroah-Hartman -
Delete successive assignments to the same location.
A simplified version of the semantic match that finds this problem is as
follows: (http://coccinelle.lip6.fr/)//
@@
expression i;
@@*i = ...;
i = ...;
//Signed-off-by: Julia Lawall
Signed-off-by: Greg Kroah-Hartman -
Renesas USBHS controller support should be available only on
Renesas ARM SoCs and SuperH architecture.Signed-off-by: Bartlomiej Zolnierkiewicz
Acked-by: Kyungmin Park
Cc: Magnus Damm
Acked-by: Geert Uytterhoeven
Acked-by: Simon Horman
Acked-by: Yoshihiro Shimoda
Signed-off-by: Greg Kroah-Hartman -
Now that we have completely moved from older USB-PHY drivers
to newer GENERIC-PHY drivers for PHYs available with USB controllers
on Exynos series of SoCs, we can remove the support for the same
in our host drivers too.We also defer the probe for our host in case we end up getting
EPROBE_DEFER error when getting PHYs.Signed-off-by: Vivek Gautam
Acked-by: Jingoo Han
Acked-by: Alan Stern
Signed-off-by: Greg Kroah-Hartman -
Signed-off-by: Arjun Sreedharan
Signed-off-by: Greg Kroah-Hartman -
Lately (with the use of uas / bulk-streams) we have been seeing several
cases where this error triggers (which should never happen).Add some extra logging to make debugging these errors easier.
Signed-off-by: Hans de Goede
Signed-off-by: Mathias Nyman
Signed-off-by: Greg Kroah-Hartman -
Even though a Set TR deq ptr command operates on a ring, and an endpoint
can have multiple rings, we can have only one Set TR deq ptr command pending.When an endpoint with streams halts or is stopped to unlink urbs, there
will only be at most one ring active / one td being executed (the td
stopped_td points to).So when we reset the endpoint (for a halt), or the stop command completes, we
will queue one Set TR deq ptr command at most, cancelled urbs on other stream
rings then the one being executed will have there trbs turned to nops, and
once the hcd gets around to execute that stream ring they will be simply
skipped.So the SET_DEQ_PENDING flag in the endpoint is sufficient protection against
starting the endpoing before all stream rings are cleaned up.Signed-off-by: Hans de Goede
Acked-by: Mathias Nyman
Signed-off-by: Mathias Nyman
Signed-off-by: Greg Kroah-Hartman -
Even if the stream for which the command was intended has been freed in the
mean time. This ensures that things start rolling again after an unlink / halt.Signed-off-by: Hans de Goede
Acked-by: Mathias Nyman
Signed-off-by: Mathias Nyman
Signed-off-by: Greg Kroah-Hartman -
xhci_queue_new_dequeue_state is the only caller of queue_set_tr_deq
and queue_set_tr_deq checks for SET_DEQ_PENDING, where as
xhci_queue_new_dequeue_state sets it which is inconsistent.Simply fold the 2 into one is a nice cleanup and fixes the inconsistency.
Signed-off-by: Hans de Goede
Signed-off-by: Mathias Nyman
Signed-off-by: Greg Kroah-Hartman -
Signed-off-by: Hans de Goede
Signed-off-by: Mathias Nyman
Signed-off-by: Greg Kroah-Hartman -
V2 - Restart polling (which will restart the timer) for the shared
HCD in xhci_resume().xhci_suspend() will stop the primary HCD's root hub timer, but leaves
the shared HCD's timer running. This change adds stopping of the
shared HCD timer.Signed-off-by: Al Cooper
Signed-off-by: Mathias Nyman
Signed-off-by: Greg Kroah-Hartman
