29 Sep, 2014
1 commit
-
Commit 0cce2eda19923e5e5ccc8b042dec5af87b3ffad0
USB: fix LANGID=0 regressiondefaults to a langid of 0x0409 if it's not properly implemented by the
device. Explain with a higher level error message what this means.Signed-off-by: Scot Doyle
Signed-off-by: Greg Kroah-Hartman
25 Sep, 2014
7 commits
-
With this patch, USB activity can be signaled by blinking a LED. There
are two triggers, one for activity on USB host and one for USB gadget.Both triggers should work with all host/device controllers. Tested only
with musb.Performace: I measured performance overheads on ARM Cortex-A8 (TI
AM335x) running on 600 MHz.Duration of usb_led_activity():
- with no LED attached to the trigger: 2 ± 1 µs
- with one GPIO LED attached to the trigger: 2 ± 1 µs or 8 ± 2 µs (two peaks in histogram)Duration of functions calling usb_led_activity() (with this patch
applied and no LED attached to the trigger):
- __usb_hcd_giveback_urb(): 10 - 25 µs
- usb_gadget_giveback_request(): 2 - 6 µsSigned-off-by: Michal Sojka
Acked-by: Felipe Balbi
Tested-by: Felipe Balbi
Signed-off-by: Greg Kroah-Hartman -
In the next commit, we will want the usb-common module to be composed of
two object files. Since Kbuild cannot "append" another object to an
existing one, we need to rename usb-common.c to something
else (common.c) and create usb-common.o by linking the wanted objects
together. Currently, usb-common.o comprises only common.o.Signed-off-by: Michal Sojka
Acked-by: Felipe Balbi
Tested-by: Felipe Balbi
Signed-off-by: Greg Kroah-Hartman -
Use the recently introduced usb_gadget_giveback_request() in favor of
direct invocation of the completion routine.All places in drivers/usb/ matching "[-.]complete(" were replaced with a
call to usb_gadget_giveback_request(). This was compile-tested with all
ARM drivers enabled and runtime-tested for musb.Signed-off-by: Michal Sojka
Acked-by: Felipe Balbi
Tested-by: Felipe Balbi
Signed-off-by: Greg Kroah-Hartman -
All USB peripheral controller drivers call completion routines directly.
This patch adds usb_gadget_giveback_request() which will be used instead
of direct invocation in the next patch. The goal here is to have a place
where common functionality can be added.Signed-off-by: Michal Sojka
Acked-by: Felipe Balbi
Tested-by: Felipe Balbi
Signed-off-by: Greg Kroah-Hartman -
This patch moves the part of code that initializes the PHY bus width.
This results in simpler code and removes the need to check whether
the Generic PHY Framework is used.Signed-off-by: Kamil Debski
Signed-off-by: Marek Szyprowski
Signed-off-by: Robert Baldyga
Signed-off-by: Greg Kroah-Hartman -
…/linux-phy into usb-next
Kishon writes:
Adds 3 new PHY drivers stih407, stih41x and rcar gen2 PHY. It also
includes miscellaneous cleanup of other PHY drivers.Conflicts:
MAINTAINERS -
…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
32 commits
-
This patch removes the superflous .owner field for drivers which
use the module_platform_driver or platform_driver_register api,
as this is overriden in __platform_driver_register.Signed-off-by: Peter Griffin
Signed-off-by: Kishon Vijay Abraham I -
Currently the DP_PHY_ENABLE register is mapped in the driver,
and accessed to control power to the PHY.
With mfd-syscon and regmap interface available at our disposal,
it's wise to use that instead of using a 'reg' property for the
controller and allocating a memory resource for that.To facilitate this, we have added another compatible string
for Exynso5420 SoC to acquire driver data which contains
different DP-PHY-CONTROL register offset.Signed-off-by: Vivek Gautam
Cc: Jingoo Han
Cc: Kishon Vijay Abraham I
Signed-off-by: Kishon Vijay Abraham I -
This patch adds the new phy-sti41x-usb.c PHY driver found on
STMicroelectronics stih41x consumer electronics SoC's into the STI
arch section of the maintainers file.Signed-off-by: Peter Griffin
Signed-off-by: Kishon Vijay Abraham I -
This patch adds dt documentation bindings for the usb phy found
on STiH415/5 SoC's from STMicroelectronics, which support USB 1.1 and 2.0.Signed-off-by: Maxime Coquelin
Signed-off-by: Peter Griffin
Signed-off-by: Kishon Vijay Abraham I -
This driver adds support for USB (1.1 and 2.0) phy for STiH415 and
STiH416 System-On-Chips from STMicroelectronics.Signed-off-by: Maxime Coquelin
Signed-off-by: Peter Griffin
Signed-off-by: Kishon Vijay Abraham I -
This patch adds the new phy-stih407-usb.c usb phy driver found on
STMicroelectronics stih407 consumer electronics SoC's into the STI
arch section of the maintainers file.Signed-off-by: Peter Griffin
Signed-off-by: Kishon Vijay Abraham I -
This patch adds the dt documentation for the usb picophy found on stih407 SoC family
available from STMicroelectronics.Signed-off-by: Giuseppe Cavallaro
Signed-off-by: Peter Griffin
Signed-off-by: Kishon Vijay Abraham I -
This is the generic phy driver for the picoPHY ports used by the
USB2 and USB3 Host controllers when controlling usb2/1.1 devices. It
is found on STiH407 SoC family from STMicroelectronics.Signed-off-by: Giuseppe Cavallaro
Signed-off-by: Peter Griffin
Signed-off-by: Kishon Vijay Abraham I -
We're using threaded irq on a I2C bus and we're sleeping in
twl4030_usb_irq() as it calls twl4030_usb_linkstat() which
calls the i2c functions. If we ever need to lock for longer
I2C transaction sequences a mutex will allow us to do that
easily.Signed-off-by: Tony Lindgren
Signed-off-by: Kishon Vijay Abraham I -
There's no longer need for tracking the phy state in the driver
with asleep, we can now rely on runtime PM.Signed-off-by: Tony Lindgren
Signed-off-by: Kishon Vijay Abraham I -
We don't need twl4030_phy_power() any longer now that we have
the runtime PM calls. Let's get rid of it as it's confusing.
No functional changes, just move the code and use res instead
of ret as we are not returning that value.Signed-off-by: Tony Lindgren
Signed-off-by: Kishon Vijay Abraham I -
We can now let the interrupt and delayed work do all that's
needed with runtime PM.Signed-off-by: Tony Lindgren
Signed-off-by: Kishon Vijay Abraham I -
It's not being used any longer.
Signed-off-by: Tony Lindgren
Signed-off-by: Kishon Vijay Abraham I -
Using the module_platform_driver macro to register the driver as this gets
rid of a lot of the boilerplate code.Also remove .owner field as this gets overridden in __platform_driver_register.
Signed-off-by: Peter Griffin
Signed-off-by: Kishon Vijay Abraham I -
Use the module_platform_driver macro to register the driver as this gets
rid of a lot of the boilerplate code.Also remove .owner field as this gets overridden in __platform_driver_register.
Signed-off-by: Peter Griffin
Signed-off-by: Kishon Vijay Abraham I -
The site specific OOM messages are unncessary, because they duplicate
messages from the memory subsystem which include dump_stack().Removing these superflous messages makes the kernel smaller. A discussion
here http://patchwork.ozlabs.org/patch/324158/ found that all error paths
from kzalloc will print a error message, and that any error path which maybe
found which doesn't would be considered a bug in kzalloc.Signed-off-by: Peter Griffin
Signed-off-by: Kishon Vijay Abraham I -
The site specific OOM messages are unncessary, because they duplicate
messages from the memory subsystem which include dump_stack().Removing these superflous messages makes the kernel smaller. A discussion
here http://patchwork.ozlabs.org/patch/324158/ found that all error paths
from kzalloc will print a error message, and that any error path which maybe
found which doesn't would be considered a bug in kzalloc.Signed-off-by: Peter Griffin
Signed-off-by: Kishon Vijay Abraham I -
The site specific OOM messages are unncessary, because they duplicate
messages from the memory subsystem which include dump_stack().Removing these superflous messages makes the kernel smaller. A discussion
here http://patchwork.ozlabs.org/patch/324158/ found that all error paths
from kzalloc will print a error message, and that any error path which maybe
found which doesn't would be considered a bug in kzalloc.Signed-off-by: Peter Griffin
Signed-off-by: Kishon Vijay Abraham I -
The site specific OOM messages are unncessary, because they duplicate
messages from the memory subsystem which include dump_stack().Removing these superflous messages makes the kernel smaller. A discussion
here http://patchwork.ozlabs.org/patch/324158/ found that all error paths
from kzalloc will print a error message, and that any error path which maybe
found which doesn't would be considered a bug in kzalloc.Signed-off-by: Peter Griffin
Signed-off-by: Kishon Vijay Abraham I -
Currently this driver is missing a check on the return value of devm_kzalloc,
which would cause a NULL pointer dereference in a OOM situation.This patch adds the aformentioned missing check.
Signed-off-by: Peter Griffin
Acked-by: Andrew Lunn
Signed-off-by: Kishon Vijay Abraham I -
The site specific OOM messages are unncessary, because they duplicate
messages from the memory subsystem which include dump_stack().Removing these superflous messages makes the kernel smaller. A discussion
here http://patchwork.ozlabs.org/patch/324158/ found that all error paths
from kzalloc will print a error message, and that any error path which maybe
found which doesn't would be considered a bug in kzalloc.Signed-off-by: Peter Griffin
Signed-off-by: Kishon Vijay Abraham I -
This PHY, though formally being a part of Renesas USBHS controller, contains the
UGCTRL2 register that controls multiplexing of the USB ports (Renesas calls them
channels) to the different USB controllers: channel 0 can be connected to either
PCI EHCI/OHCI or USBHS controllers, channel 2 can be connected to PCI EHCI/OHCI
or xHCI controllers.This is a new driver for this USB PHY currently already supported under drivers/
usb/phy/. The reason for writing the new driver was the requirement that the
multiplexing of USB channels to the controller be dynamic, depending on what
USB drivers are loaded, rather than static as provided by the old driver. The
infrastructure provided by drivers/phy/phy-core.c seems to fit that purpose
ideally. The new driver only supports device tree probing for now.Signed-off-by: Sergei Shtylyov
Signed-off-by: Kishon Vijay Abraham I -
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
