Suspend scenario in case of ohci-s3c2410 glue was not
properly handled as it was not suspending generic part
of ohci controller. Alan Stern suggested, properly handle
ohci-s3c2410 suspend scenario.
Calling explicitly the ohci_suspend()
routine in ohci_hcd_s3c2410_drv_suspend() will ensure
proper handling of suspend scenario.
Signed-off-by: Manjunath Goudar <manjunath.goudar@linaro.org>
Signed-off-by: Manjunath Goudar <csmanjuvijay@gmail.com>
Acked-by: Alan Stern <stern@rowland.harvard.edu>
Cc: Arnd Bergmann <arnd@arndb.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Suspend scenario in case of ohci-at91 glue was not properly handled
as it was not suspending generic part of ohci controller. Alan Stern
suggested, properly handle ohci-at91 suspend scenario.
Calling explicitly the ohci_suspend() routine in ohci_hcd_at91_drv_suspend()
will ensure proper handling of suspend scenario. This task is sugested
by Alan Stern.
Signed-off-by: Manjunath Goudar <manjunath.goudar@linaro.org>
Signed-off-by: Manjunath Goudar <csmanjuvijay@gmail.com>
Acked-by: Alan Stern <stern@rowland.harvard.edu>
Cc: Arnd Bergmann <arnd@arndb.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Suspend scenario in case of OHCI was not properly
handled in ochi_suspend()routine. Alan Stern
suggested, properly handle OHCI suspend scenario.
This does generic proper handling of suspend
scenario to all OHCI SOC.
Signed-off-by: Manjunath Goudar <manjunath.goudar@linaro.org>
Signed-off-by: Manjunath Goudar <csmanjuvijay@gmail.com>
Acked-by: Alan Stern <stern@rowland.harvard.edu>
Cc: Arnd Bergmann <arnd@arndb.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
If USB_FUNCTIONFS is selected without USB_FUNCTIONFS_ETH and
USB_FUNCTIONFS_RNIS, u_ether.h won't be included and then
USB_ETHERNET_MODULE_PARAMAETERS macro won't be available causing the
following warning compilation:
drivers/usb/gadget/g_ffs.c:81:1: warning: data definition has no type or
storage class [enabled by default]
drivers/usb/gadget/g_ffs.c:81:1: warning: type defaults to ‘int’ in
declaration of ‘USB_ETHERNET_MODULE_PARAMETERS’ [-Wimplicit-int]
drivers/usb/gadget/g_ffs.c:81:1: warning: function declaration isn’t a
prototype [-Wstrict-prototypes]
This patch fixes the warning by making USB_ETHERNET_MODULE_PARAMETERS to
be used iff u_ether.h is included, otherwise it is not needed.
Signed-off-by: David Cohen <david.a.cohen@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
This patch adds support for isochronous out transfers to the HWA. The
primary changes are:
1. Add a isoc_pack_desc_urb field to struct wa_seg. This urb is used
to send the isochronous packet info message to the HWA which describes
the isoc data segment(s) that will be sent as the payload of the
transfer request.
2. Use the URB iso_frame_desc field to populate the isochronous packet
info message and data segments sent to the HWA.
3. After the data is sent and transfer result is returned from the
HWA, read the isoc packet status message from the HWA. The contents of
the isoc packet status message are used to set the iso_frame_desc
status and actual_length fields in the original isoc URB. This feature
required the addition of a some state tracking variables in struct wahc
so the dti_urb knows what type of packet it expects to receive next.
Signed-off-by: Thomas Pugliese <thomas.pugliese@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
This function was preventing us from supporting multiple
instances. Get rid of it. Since we support DT boots only,
users can get the control device phandle from the DT node.
Signed-off-by: Roger Quadros <rogerq@ti.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
omap_get_control_dev() is being deprecated as it doesn't support
multiple instances. As control device is present only from OMAP4
onwards which supports DT only, we use phandles to get the
reference to the control device.
Also get rid of "ti,has-mailbox" property as it is redundant and
we can determine that from whether "ctrl-module" property is present
or not. Get rid of has_mailbox from musb_hdrc_platform_data as well.
Signed-off-by: Roger Quadros <rogerq@ti.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
omap_get_control_dev() is being deprecated as it doesn't support
multiple instances. As control device is present only from OMAP4
onwards which supports DT only, we use phandles to get the
reference to the control device.
As we don't support non-DT boot, we just bail out on probe
if device node is not present.
Signed-off-by: Roger Quadros <rogerq@ti.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Add support for new device types and in the process rid of "ti,type"
device tree property. The correct type of device will be determined
from the compatible string instead.
Introduce a compatible string for each device type. At the moment
we support 4 types OTGHS, USB2, PIPE3 (e.g. USB3) and DRA7USB2.
Update DT binding information to reflect these changes.
Also get rid of omap_control_usb3_phy_power(). Just one function
i.e. omap_control_usb_phy_power() will now take care of all PHY types.
Signed-off-by: Roger Quadros <rogerq@ti.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
omap-control device is present from OMAP4 onwards which
support device tree boots only. So get rid of platform data.
Signed-off-by: Roger Quadros <rogerq@ti.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
This patch sets the RPIPE bOverTheAirInterval field for RPIPES which
refer to isochronous endpoints.
Signed-off-by: Thomas Pugliese <thomas.pugliese@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
This patch adds an implementation for hwahc_op_get_frame_number. The
request is fulfulled by forwarding it to the lower hcd. This was done
because the GET_TIME request on the HWA requires sending an URB to the
HWA and waiting for the results which cannot be done in atomic context.
Signed-off-by: Thomas Pugliese <thomas.pugliese@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
This patch modifies wa_urb_enqueue to return an error and not call the
urb completion routine if it failed to enqueue the urb because the HWA
device is gone. This prevents a stack overflow due to infinite
submit/complete recursion when unplugging the HWA while connected to a
HID device.
Signed-off-by: Thomas Pugliese <thomas.pugliese@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Commit "usb: pci-quirks: refactor AMD quirk to abstract AMD chipset types"
introduced a new AMD chipset type to filter AMD platforms with different
chipsets.
According to a recent thread [1], this patch updates SB800 prefetch routine
in AMD PLL quirk. And make it use the new chipset type to represent SB800
generation.
[1] http://marc.info/?l=linux-usb&m=138012321616452&w=2
Signed-off-by: Huang Rui <ray.huang@amd.com>
Acked-by: Alan Stern <stern@rowland.harvard.edu>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Commit "usb: pci-quirks: refactor AMD quirk to abstract AMD chipset types"
introduced a new AMD chipset type to filter AMD platforms with different
chipsets.
According to a recent thread [1], this patch updates USB subsystem hang
symptom quirk which is observed on AMD all SB600 and SB700 revision
0x3a/0x3b. And make it use the new chipset type to represent.
[1] http://marc.info/?l=linux-usb&m=138012321616452&w=2
Signed-off-by: Huang Rui <ray.huang@amd.com>
Acked-by: Alan Stern <stern@rowland.harvard.edu>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Also clean up the last item of the pci id list to be "cleaner".
Signed-off-by: David Cohen <david.a.cohen@linux.intel.com>
Cc: stable <stable@vger.kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Here are some more fixes to musb's OTG support and a regression
caused on latest merge window; pxa25x_udc and gpio-vbus learned
to cope with deferred probe; s3c-hsotg got a fix for non-periodic
endpoints write size and f_fs got an error handling fix for cases
where ffs_do_descs() fail.
Signed-of-by: Felipe Balbi <balbi@ti.com>
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)
iQIcBAABAgAGBQJSStwTAAoJEIaOsuA1yqREpMgP/2BbaC0hCO3wA6NPul2drke2
lb1yKU9bKhk3R0McRWhV9iJGjStpIBYLlbE66sjAvu2r53JktMysb6xPwnPwgNPK
RabFpQnNiS/voyaAKyLq69WIPC9dfT/LwUXS4NouwTgEjPJuYs3La69NJRZlHx8A
iFXsQtgS2h6gIKm2r71TYamgO/jYmwZsetpwOrjCz1AlTt/6wjy5ilQthHs+F0de
iNFRsvRYyuMO2BEmqI286U7FWPK4FAO3bsqwP4EWZ7VqTLBBHqxFA3jscbeidbB4
U6qRbekMfYCrYjYkKwuQAsFpvt6WHh8peCsWLxJ9SnyugwcXG4UwimP4qqkS6GhC
VJpyYhE8AAHiPnXSigEFUPo3uwcylXdwg3viybezlSI/7X/NlQvhGWJZBDdSESS2
ThieH2sFuqtk5XkG8lXySCeab/qp3NUNVVJf81G0sIjsgU2kmkTkE9913ird0kN8
k+fkggtrK5YqbPoEIhhIdhwloyM6dxL3pLe3LHCwkyZ8Aeze8Wv1nd31OHWU1uVh
ZjHA202MzpkHnj2gykzKS808h12S8czzIe5jTyiPPAwOz87DIxx64MqG2OGM8Rtv
+/N+E3K/b0//Fg/GGFN2du+7SrRW4U8cAhBX9mh9j9eI2X9Yd3HclviSNM9lVTcN
iCIY3ivMFg29aTVFIYFC
=BQeb
-----END PGP SIGNATURE-----
Merge tag 'fixes-for-v3.12-rc4' of git://git.kernel.org/pub/scm/linux/kernel/git/balbi/usb into usb-linus
Felipe writes:
usb: fixes for v3.12-rc4
Here are some more fixes to musb's OTG support and a regression
caused on latest merge window; pxa25x_udc and gpio-vbus learned
to cope with deferred probe; s3c-hsotg got a fix for non-periodic
endpoints write size and f_fs got an error handling fix for cases
where ffs_do_descs() fail.
Signed-of-by: Felipe Balbi <balbi@ti.com>
Value of can_write variable in s3c_hsotg_write_fifo function should be limited
to 512 only for non-periodic endpoints. There was some discrepancy between
comment and code, because comment suggests correct behavior, but in the code
limit was applied to periodic endpoints too. So there is additional check
causing the limitation concerns only non-periodic endpoints.
Signed-off-by: Robert Baldyga <r.baldyga@samsung.com>
Signed-off-by: Kyungmin Park <kyungmin.park@samsung.com>
Signed-off-by: Felipe Balbi <balbi@ti.com>
This patch add missing error check in ffs_func_bind() function, after
ffs_do_descs() function call for high speed descriptors. Without this
check it's possible that the module will try dereference incorrect
pointer.
[ balbi@ti.com : removed trailing empty line ]
Acked-by: Michal Nazarewicz <mina86@mina86.com>
Signed-off-by: Robert Baldyga <r.baldyga@samsung.com>
Signed-off-by: Felipe Balbi <balbi@ti.com>
This went unnoticed in durin the merge window:
The dsps driver creates a child device for the musb core driver _and_
attaches the of_node to it so devm_usb_get_phy_by_phandle() grabs the
correct phy and attaches the devm resources to the proper device. We
could also use the parent device but then devm would attach the
resource to the wrong device and it would be destroyed once the parent
device is gone - not the device that is used by the musb core driver.
If the phy is now not available then dsps_musb_init() /
devm_usb_get_phy_by_phandle() returns with EPROBE_DEFER. Since the
of_node is attached it tries OF drivers as well and matches the driver
against DSPS. That one creates a new child device for the musb core
driver which gets probed immediately.
The whole thing repeats itself until the stack overflows.
I belive the same problem exists in ux500 glue code (since 313bdb11
("usb: musb: ux500: add device tree probing support") but the drivers are
now probed in the right order so they don't see it.
The problem is that the dsps driver gets bound to the musb-child device
due to the same of_node / matching binding. I don't really agree with
having yet another child node in DT to fix this. Ideally we would have
musb core driver with DT bindings and according to the binding we would
select the few extra hacks / gleue layer.
Therefore I suggest the driver to reject the musb-core device.
Cc: Lee Jones <lee.jones@linaro.org>
Tested-by: Tom Rini <trini@ti.com>
Signed-off-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
Signed-off-by: Felipe Balbi <balbi@ti.com>
Fix a build warning found by the kbuild test robot in the most recent
wusbcore patches.
Signed-off-by: Thomas Pugliese <thomas.pugliese@gmail.com>
Reported-by: kbuild test robot <fengguang.wu@intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Hi,
my Huawei 3G modem has an embedded Smart Card reader which causes
trouble when the modem is being detected (a bunch of "<warn> (ttyUSBx):
open blocked by driver for more than 7 seconds!" in messages.log). This
trivial patch corrects the problem for me. The modem identifies itself
as "12d1:1406 Huawei Technologies Co., Ltd. E1750" in lsusb although the
description on the body says "Model E173u-1"
Signed-off-by: Michal Malý <madcatxster@prifuk.cz>
Cc: Bjørn Mork <bjorn@mork.no>
Cc: stable <stable@vger.kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
devm_clk_get() is used so there is no reason to explicitly
call clk_put() in probe or remove functions.
Signed-off-by: Wei Yongjun <yongjun_wei@trendmicro.com.cn>
Signed-off-by: Sachin Kamat <sachin.kamat@linaro.org>
Acked-by: Stephen Warren <swarren@nvidia.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Check for non-NULL overrides before dereferencing since platforms may
pass in NULL overrides.
Signed-off-by: Kevin Hilman <khilman@linaro.org>
Acked-by: Alan Stern <stern@rowland.harvard.edu>
Signed-off-by: Tomasz Figa <tomasz.figa@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
This patch updates URB dequeue handling in wusbcore to make it more
reliable when a URB has been broken up into multiple WUSB transfer
request segments.
In wa_urb_dequeue, don't mark segments in the WA_SEG_SUBMITTED,
WA_SEG_PENDING or WA_SEG_DTI_PENDING states as completed if an ABORT
TRANSFER request was sent to the HWA to clean them up. Wait for the
HWA to return a transfer result indicating that it has aborted the
request before cleaning it up. This prevents the DTI state machine
from losing track of transfers and avoids confusion in the case where a
read transfer segment is dequeued after the driver has received the
transfer result but before the data is received.
Signed-off-by: Thomas Pugliese <thomas.pugliese@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Include the xfer_id in debug prints for transfers and transfer segments.
This makes it much easier to correlate debug logs to USB analyzer logs.
Signed-off-by: Thomas Pugliese <thomas.pugliese@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Add a new function to get the xfer ID in little endian format
(wa_xfer_id_le32), and use it instead of wa_xfer_id where appropriate.
Signed-off-by: Thomas Pugliese <thomas.pugliese@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
This API is used to let the PHY enter/leave low power mode.
Before the controller going to work(at probe/resume), it needs to let
the PHY leave low power mode.
After the controller stopping working(at remove/suspend), it needs to
let the PHY enter low power mode to save power consumption.
Signed-off-by: Peter Chen <peter.chen@freescale.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Since the PHY operations are moved to core, delete the related
code at glue layer.
Signed-off-by: Peter Chen <peter.chen@freescale.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
PHY operations are common, so move them to core.
Signed-off-by: Peter Chen <peter.chen@freescale.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Use the generic PHY framework API to get the PHY. The usb_phy_set_resume
and usb_phy_set_suspend is replaced with power_on and
power_off to align with the new PHY framework.
musb->xceiv can't be removed as of now because musb core uses xceiv.state and
xceiv.otg. Once there is a separate state machine to handle otg, these can be
moved out of xceiv and then we can start using the generic PHY framework.
Signed-off-by: Kishon Vijay Abraham I <kishon@ti.com>
Reviewed-by: Sylwester Nawrocki <s.nawrocki@samsung.com>
Acked-by: Felipe Balbi <balbi@ti.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Used the generic PHY framework API to create the PHY. For powering on
and powering off the PHY, power_on and power_off ops are used. Once the
MUSB OMAP glue is adapted to the new framework, the suspend and resume
ops of usb phy library will be removed. Also twl4030-usb driver is moved
to drivers/phy/.
However using the old usb phy library cannot be completely removed
because otg is intertwined with phy and moving to the new
framework completely will break otg. Once we have a separate otg state machine,
we can get rid of the usb phy library.
Signed-off-by: Kishon Vijay Abraham I <kishon@ti.com>
Acked-by: Felipe Balbi <balbi@ti.com>
Reviewed-by: Sylwester Nawrocki <s.nawrocki@samsung.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Used the generic PHY framework API to create the PHY. Now the power off and
power on are done in omap_usb_power_off and omap_usb_power_on respectively.
The omap-usb2 driver is also moved to driver/phy.
However using the old USB PHY library cannot be completely removed
because OTG is intertwined with PHY and moving to the new framework
will break OTG. Once we have a separate OTG state machine, we
can get rid of the USB PHY library.
Signed-off-by: Kishon Vijay Abraham I <kishon@ti.com>
Reviewed-by: Sylwester Nawrocki <s.nawrocki@samsung.com>
Acked-by: Felipe Balbi <balbi@ti.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
This patch fixes two cases where error handling code was freeing memory
but not setting the pointer to NULL. This could lead to a double free
in the HWA shutdown code.
Signed-off-by: Thomas Pugliese <thomas.pugliese@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Clean up the SG list after transfer completetion for out transfers if one
was created by the HWA.
Signed-off-by: Thomas Pugliese <thomas.pugliese@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
This patch updates __wa_xfer_setup_segs error path to only clean up the
xfer->seg entry that it failed to create and then set that entry to
NULL. wa_xfer_destroy will clean up the remaining xfer->segs that were
fully created. It also moves the code to create the dto sg list to an
out of line function to make __wa_xfer_setup_segs easier to read. Prior
to this change, __wa_xfer_setup_segs would clean up all entries in the
xfer->seg array in case of an error but it did not set them to NULL.
This resulted in a double free when wa_xfer_destroy was eventually
called by the higher level error handler.
Signed-off-by: Thomas Pugliese <thomas.pugliese@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
If __wa_xfer_setup fails, it can leave a partially constructed wa_xfer
object. The error handling code eventually calls wa_xfer_destroy which
does not check for NULL before dereferencing xfer->seg which could cause
a kernel panic. This change also makes sure to free xfer->seg which was
being leaked for all transfers before this change.
Signed-off-by: Thomas Pugliese <thomas.pugliese@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Rename xfer_result to dti_buf and xfer_result_size to dti_buf_size in
struct wahc. The dti buffer will also be used for isochronous status
packets once isochronous transfers are supported.
Signed-off-by: Thomas Pugliese <thomas.pugliese@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Rename urb to tr_urb in struct wa_seg to make it clear that the urb is
used for the transfer request.
Signed-off-by: Thomas Pugliese <thomas.pugliese@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
We can only reach this spot by breaking out of the scan loop,
so by construction ret > 0.
Found by Coverity, in a copy of this file in the Xen sources.
Signed-off-by: Tim Deegan <tim@xen.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
In case of usb phy reinitialization:
e.g. insmod usb-module(usb works well) -> rmmod usb-module -> insmod usb-module
It found the PHY_CLK_VALID bit didn't work if it's not with the power-on reset.
So we just check PHY_CLK_VALID bit during the stage with POR, this can be met
by the tricky of checking FSL_SOC_USB_PRICTRL register.
Signed-off-by: Shengzhou Liu <Shengzhou.Liu@freescale.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
There's a bunch of failure exits in ffs_fs_mount() with
seriously broken recovery logics. Most of that appears to stem
from misunderstanding of the ->kill_sb() semantics; unlike
->put_super() it is called for *all* superblocks of given type,
no matter how (in)complete the setup had been. ->put_super()
is called only if ->s_root is not NULL; any failure prior to
setting ->s_root will have the call of ->put_super() skipped.
->kill_sb(), OTOH, awaits every superblock that has come from
sget().
Current behaviour of ffs_fs_mount():
We have struct ffs_sb_fill_data data on stack there. We do
ffs_dev = functionfs_acquire_dev_callback(dev_name);
and store that in data.private_data. Then we call mount_nodev(),
passing it ffs_sb_fill() as a callback. That will either fail
outright, or manage to call ffs_sb_fill(). There we allocate an
instance of struct ffs_data, slap the value of ffs_dev (picked
from data.private_data) into ffs->private_data and overwrite
data.private_data by storing ffs into an overlapping member
(data.ffs_data). Then we store ffs into sb->s_fs_info and attempt
to set the rest of the things up (root inode, root dentry, then
create /ep0 there). Any of those might fail. Should that
happen, we get ffs_fs_kill_sb() called before mount_nodev()
returns. If mount_nodev() fails for any reason whatsoever,
we proceed to
functionfs_release_dev_callback(data.ffs_data);
That's broken in a lot of ways. Suppose the thing has failed in
allocation of e.g. root inode or dentry. We have
functionfs_release_dev_callback(ffs);
ffs_data_put(ffs);
done by ffs_fs_kill_sb() (ffs accessed via sb->s_fs_info), followed by
functionfs_release_dev_callback(ffs);
from ffs_fs_mount() (via data.ffs_data). Note that the second
functionfs_release_dev_callback() has every chance to be done to freed memory.
Suppose we fail *before* root inode allocation. What happens then?
ffs_fs_kill_sb() doesn't do anything to ffs (it's either not called at all,
or it doesn't have a pointer to ffs stored in sb->s_fs_info). And
functionfs_release_dev_callback(data.ffs_data);
is called by ffs_fs_mount(), but here we are in nasal daemon country - we
are reading from a member of union we'd never stored into. In practice,
we'll get what we used to store into the overlapping field, i.e. ffs_dev.
And then we get screwed, since we treat it (struct gfs_ffs_obj * in
disguise, returned by functionfs_acquire_dev_callback()) as struct
ffs_data *, pick what would've been ffs_data ->private_data from it
(*well* past the actual end of the struct gfs_ffs_obj - struct ffs_data
is much bigger) and poke in whatever it points to.
FWIW, there's a minor leak on top of all that in case if ffs_sb_fill()
fails on kstrdup() - ffs is obviously forgotten.
The thing is, there is no point in playing all those games with union.
Just allocate and initialize ffs_data *before* calling mount_nodev() and
pass a pointer to it via data.ffs_data. And once it's stored in
sb->s_fs_info, clear data.ffs_data, so that ffs_fs_mount() knows that
it doesn't need to kill the sucker manually - from that point on
we'll have it done by ->kill_sb().
Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
Acked-by: Michal Nazarewicz <mina86@mina86.com>
Cc: stable <stable@vger.kernel.org> # 3.3+
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
For controller versions greater than 1.6, setting ULPI_PHY_CLK_SEL
bit when USB_EN bit is already set causes instability issues with
PHY_CLK_VLD bit. So USB_EN is set only for IP controller version
below 1.6 before setting ULPI_PHY_CLK_SEL bit
Signed-off-by: Ramneek Mehresh <ramneek.mehresh@freescale.com>
Cc: stable <stable@vger.kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Separate the OHCI pxa27x/pxa3xx host controller driver from
ohci-hcd host code so that it can be built as a separate driver
module. This work is part of enabling multi-platform kernels on
ARM.
Signed-off-by: Manjunath Goudar <manjunath.goudar@linaro.org>
Signed-off-by: Deepak Saxena <dsaxena@linaro.org>
Acked-by: Alan Stern <stern@rowland.harvard.edu>
Cc: Arnd Bergmann <arnd@arndb.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Separate the OHCI EP93XX host controller driver from ohci-hcd
host code so that it can be built as a separate driver module.
This work is part of enabling multi-platform kernels on ARM.
Signed-off-by: Manjunath Goudar <manjunath.goudar@linaro.org>
Signed-off-by: Deepak Saxena <dsaxena@linaro.org>
Acked-by: Alan Stern <stern@rowland.harvard.edu>
Cc: Arnd Bergmann <arnd@arndb.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Separate the OHCI NXP host controller driver from ohci-hcd
host code so that it can be built as a separate driver module.
This work is part of enabling multi-platform kernels on ARM.
Many place function name and struct name started with usb,
current scenario replaced usb with ohci for proper naming.
Signed-off-by: Manjunath Goudar <manjunath.goudar@linaro.org>
Signed-off-by: Deepak Saxena <dsaxena@linaro.org>
Acked-by: Alan Stern <stern@rowland.harvard.edu>
Cc: Arnd Bergmann <arnd@arndb.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Separate the Samsung OHCI S3C24xx/S3C64xx host controller driver
from ohci-hcd host code so that it can be built as a separate
driver module.This work is part of enabling multi-platform.
Signed-off-by: Manjunath Goudar <manjunath.goudar@linaro.org>
Signed-off-by: Deepak Saxena <dsaxena@linaro.org>
Acked-by: Alan Stern <stern@rowland.harvard.edu>
Reviewed-by: Tomasz Figa <t.figa@samsung.com>
Cc: Arnd Bergmann <arnd@arndb.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Separate the TI OHCI Atmel host controller driver from ohci-hcd
host code so that it can be built as a separate driver module.
This work is part of enabling multi-platform kernels on ARM.
Signed-off-by: Manjunath Goudar <manjunath.goudar@linaro.org>
Signed-off-by: Deepak Saxena <dsaxena@linaro.org>
Acked-by: Alan Stern <stern@rowland.harvard.edu>
Acked-by: Nicolas Ferre <nicolas.ferre@atmel.com>
Cc: Arnd Bergmann <arnd@arndb.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Separate the ST OHCI SPEAr host controller driver from ohci-hcd
host code so that it can be built as a separate driver module.
This work is part of enabling multi-platform kernels on ARM.
Signed-off-by: Manjunath Goudar <manjunath.goudar@linaro.org>
Signed-off-by: Deepak Saxena <dsaxena@linaro.org>
Acked-by: Alan Stern <stern@rowland.harvard.edu>
Cc: Viresh Kumar <viresh.linux@gmail.com>
Cc: Arnd Bergmann <arnd@arndb.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Separate the TI OHCI OMAP3 host controller driver from ohci-hcd
host code so that it can be built as a separate driver module.
This work is part of enabling multi-platform kernels on ARM.
Signed-off-by: Manjunath Goudar <manjunath.goudar@linaro.org>
Signed-off-by: Deepak Saxena <dsaxena@linaro.org>
Acked-by: Alan Stern <stern@rowland.harvard.edu>
Cc: Anand Gadiyar <gadiyar@ti.com>
Cc: Felipe Balbi <balbi@ti.com>
Cc: Arnd Bergmann <arnd@arndb.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Separate the TI OHCI OMAP1/2 host controller driver from ohci-hcd
host code so that it can be built as a separate driver module.
This work is part of enabling multi-platform kernels on ARM.
Signed-off-by: Manjunath Goudar <manjunath.goudar@linaro.org>
Signed-off-by: Deepak Saxena <dsaxena@linaro.org>
Acked-by: Alan Stern <stern@rowland.harvard.edu>
Cc: Felipe Balbi <balbi@ti.com>
Cc: Arnd Bergmann <arnd@arndb.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Separate the Samsung OHCI EXYNOS host controller driver from ohci-hcd
host code so that it can be built as a separate driver module.
This work is part of enabling multi-platform kernels on ARM.
Signed-off-by: Manjunath Goudar <manjunath.goudar@linaro.org>
Signed-off-by: Deepak Saxena <dsaxena@linaro.org>
Acked-by: Alan Stern <stern@rowland.harvard.edu>
Acked-by: Jingoo Han <jg1.han@samsung.com>
Cc: Vivek Gautam <gautam.vivek@samsung.com>
Cc: Arnd Bergmann <arnd@arndb.de>
Cc: Kukjin Kim <kgene.kim@samsung.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Separate the W90X900(W90P910) on-chip host controller driver from
ehci-hcd host code so that it can be built as a separate driver module.
This work is part of enabling multi-platform kernels on ARM;
however, note that other changes are still needed before W90X900(W90P910)
can be booted with a multi-platform kernel
and an ehci driver that only works on one of them.
With the infrastructure added by Alan Stern in patch 3e0232039
"USB: EHCI: prepare to make ehci-hcd a library module", we can
avoid this problem by turning a bus glue into a separate
module, as we do here for the w90X900 bus glue.
This patch is rebased on greghk/usb-next 3.12 rc1.
Signed-off-by: Manjunath Goudar <manjunath.goudar@linaro.org>
Signed-off-by: Deepak Saxena <dsaxena@linaro.org>
Acked-by: Arnd Bergmann <arnd@arndb.de>
Acked-by: Wan ZongShun <mcuos.com@gmail.com>
Acked-by: Alan Stern <stern@rowland.harvard.edu>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
The DCD pin of the serial port can receive a PPS signal. By calling
the port line discipline dcd handle, this patch allow to monitor PPS
through USB serial devices.
However the performance aren't as good as the uart drivers, so
document this point too.
Signed-off-by: Paul Chavent <paul.chavent@onera.fr>
Acked-by: Rodolfo Giometti <giometti@enneenne.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
When the device receive a DCD status change, forward the signal to the
USB serial system. This way, we can detect, for instance, PPS pulses.
Signed-off-by: Paul Chavent <paul.chavent@onera.fr>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
usb_disconnect() no longer acquires usb_bus_list_lock, so update its
comment to that effect.
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Signed-off-by: Alan Stern <stern@rowland.harvard.edu>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Trying to read data from the Pegasus Technologies NoteTaker (0e20:0101)
[1] with the Windows App (EasyNote) works natively but fails when
Windows is running under KVM (and the USB device handed to KVM).
The reason is a USB control message
usb 4-2.2: control urb: bRequestType=22 bRequest=09 wValue=0200 wIndex=0001 wLength=0008
This goes to endpoint address 0x01 (wIndex); however, endpoint address
0x01 does not exist. There is an endpoint 0x81 though (same number,
but other direction); the app may have meant that endpoint instead.
The kernel thus rejects the IO and thus we see the failure.
Apparently, Linux is more strict here than Windows ... we can't change
the Win app easily, so that's a problem.
It seems that the Win app/driver is buggy here and the driver does not
behave fully according to the USB HID class spec that it claims to
belong to. The device seems to happily deal with that though (and
seems to not really care about this value much).
So the question is whether the Linux kernel should filter here.
Rejecting has the risk that somewhat non-compliant userspace apps/
drivers (most likely in a virtual machine) are prevented from working.
Not rejecting has the risk of confusing an overly sensitive device with
such a transfer. Given the fact that Windows does not filter it makes
this risk rather small though.
The patch makes the kernel more tolerant: If the endpoint address in
wIndex does not exist, but an endpoint with toggled direction bit does,
it will let the transfer through. (It does NOT change the message.)
With attached patch, the app in Windows in KVM works.
usb 4-2.2: check_ctrlrecip: process 13073 (qemu-kvm) requesting ep 01 but needs 81
I suspect this will mostly affect apps in virtual environments; as on
Linux the apps would have been adapted to the stricter handling of the
kernel. I have done that for mine[2].
[1] http://www.pegatech.com/
[2] https://sourceforge.net/projects/notetakerpen/
Signed-off-by: Kurt Garloff <kurt@garloff.de>
Acked-by: Alan Stern <stern@rowland.harvard.edu>
Cc: stable <stable@vger.kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
If NO_DMA=y:
drivers/built-in.o: In function `dma_set_coherent_mask':
include/linux/dma-mapping.h:93: undefined reference to `dma_supported'
Reviewed-and-tested-by: Peter Chen <peter.chen@freescale.com>
Signed-off-by: Geert Uytterhoeven <geert@linux-m68k.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
There is a pending TD which is not freed after request finishes,
we do this due to a controller bug. This TD needs to be freed when
the driver is removed. It prints below error message when unload
chipidea driver at current code:
"ci_hdrc ci_hdrc.0: dma_pool_destroy ci_hw_td, b0001000 busy"
It indicates the buffer at dma pool are still in use.
This commit will free the pending TD at driver's removal procedure,
it can fix the problem described above.
Acked-by: Michael Grzeschik <m.grzeschik@pengutronix.de>
Signed-off-by: Peter Chen <peter.chen@freescale.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
If not, the PHY will be active even the controller is not in use.
We find this issue due to the PHY's clock refcount is not correct
due to -EPROBE_DEFER return after phy's init.
Signed-off-by: Peter Chen <peter.chen@freescale.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
It needs to free ci->hw_bank.regmap explicitly since it is not managed
resource.
Signed-off-by: Peter Chen <peter.chen@freescale.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
This patch straightens out some locking issues in the USB sysfs
interface:
Deauthorization will destroy existing configurations.
Attributes that read from udev->actconfig need to lock the
device to prevent races. Likewise for the rawdescriptor
values.
Attributes that access an interface's current alternate
setting should use ACCESS_ONCE() to obtain the cur_altsetting
pointer, to protect against concurrent altsetting changes.
The supports_autosuspend() attribute routine accesses values
from an interface's driver, so it should lock the interface
(rather than the usb_device) to protect against concurrent
unbinds. Once this is done, the routine can be simplified
considerably.
Scalar values that are stored directly in the usb_device structure are
always available. They do not require any locking. The same is true
of the cached interface string descriptor, because it is not
deallocated until the usb_host_interface structure is destroyed.
Signed-off-by: Alan Stern <stern@rowland.harvard.edu>
CC: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
When transfer type is isochronous, the other bits (bits 5..2) of
bmAttributes in endpoint descriptor might not be set zero. So it's better
to use usb_endpoint_type routine to mask bmAttributes with
USB_ENDPOINT_XFERTYPE_MASK to judge the transfter type later.
Signed-off-by: Huang Rui <ray.huang@amd.com>
Acked-by: Alan Stern <stern@rowland.harvard.edu>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
The following patch is required to resolve remote wake issues with
certain devices.
Issue description:
If the remote wake is issued from the device in a specific timing
condition while the system is entering sleep state then it may cause
system to auto wake on subsequent sleep cycle.
Root cause:
Host controller rebroadcasts the Resume signal > 100 µseconds after
receiving the original resume event from the device. For proper
function, some devices may require the rebroadcast of resume event
within the USB spec of 100µS.
Workaroud:
1. Filter the AMD platforms with Yangtze chipset, then judge of all the usb
devices are mouse or not. And get out the port id which attached a mouse
with Pixart controller.
2. Then reset the port which attached issue device during system resume
from S3.
[Q] Why the special devices are only mice? Would high speed devices
such as 3G modem or USB Bluetooth adapter trigger this issue?
- Current this sensitivity is only confined to devices that use Pixart
controllers. This controller is designed for use with LS mouse
devices only. We have not observed any other devices failing. There
may be a small risk for other devices also but this patch (reset
device in resume phase) will cover the cases if required.
[Q] Shouldn’t the resume signal be sent within 100 us for every
device?
- The Host controller may not send the resume signal within 100us,
this our host controller specification change. This is why we
require the patch to prevent side effects on certain known devices.
[Q] Why would clicking mouse INTENSELY to wake the system up trigger
this issue?
- This behavior is specific to the devices that use Pixart controller.
It is timing dependent on when the resume event is triggered during
the sleep state.
[Q] Is it a host controller issue or mouse?
- It is the host controller behavior during resume that triggers the
device incorrect behavior on the next resume.
This patch sets USB_QUIRK_RESET_RESUME flag for these Pixart-based mice
when they attached to platforms with AMD Yangtze chipset.
Signed-off-by: Huang Rui <ray.huang@amd.com>
Suggested-by: Alan Stern <stern@rowland.harvard.edu>
Acked-by: Alan Stern <stern@rowland.harvard.edu>
Acked-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
This patch abstracts out a AMD chipset type which includes southbridge
generation and its revision. When os excutes usb_amd_find_chipset_info
routine to initialize AMD chipset type, driver will know which kind of
chipset is used.
This update has below benifits:
- Driver is able to confirm which southbridge generations and their
revision are used, with chipset detection once.
- To describe chipset generations with enumeration types brings better
readability.
- It's flexible to filter AMD platforms to implement new quirks in future.
Signed-off-by: Huang Rui <ray.huang@amd.com>
Cc: Andiry Xu <andiry.xu@gmail.com>
Acked-by: Alan Stern <stern@rowland.harvard.edu>
Acked-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Driver core sets driver data to NULL upon failure or remove.
Signed-off-by: Sachin Kamat <sachin.kamat@linaro.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Driver core sets driver data to NULL upon failure or remove.
Signed-off-by: Sachin Kamat <sachin.kamat@linaro.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Like vbus, the dr_mode and phy_mode are also got from glue layer's
platform data or device node.
Signed-off-by: Peter Chen <peter.chen@freescale.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
The udc-core will call gadget's driver->disconnect, so we should avoid
calling gadget's disconnect again at ci_udc_stop in case the gadget's
unbind free some structs which is still used at gadget's disconnect.
Tested-by: Marek Vasut <marex@denx.de>
Signed-off-by: Peter Chen <peter.chen@freescale.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Now, chipidea host has already depended on USB_EHCI_HCD
Acked-by: Alan Stern <stern@rowland.harvard.edu>
Signed-off-by: Peter Chen <peter.chen@freescale.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
There is a pending TD which is not freed after request finishes,
we do this due to a controller bug. This TD needs to be freed when
the driver is removed. It prints below error message when unload
chipidea driver at current code:
"ci_hdrc ci_hdrc.0: dma_pool_destroy ci_hw_td, b0001000 busy"
It indicates the buffer at dma pool are still in use.
This commit will free the pending TD at driver's removal procedure,
it can fix the problem described above.
Signed-off-by: Peter Chen <peter.chen@freescale.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Support for specifying soft dependencies in the modules themselves was
introduced in commit 7cb14ba.
In Arch we have always been shipping a module.d(5) fragment ordering ohci/uhci
after ehci. If this ordering is really necessary, it would be great to move it
to the kernel and getting the correct fragment generated by depmod.
Signed-off-by: Tom Gundersen <teg@jklm.no>
Cc: Alan Stern <stern@rowland.harvard.edu>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Since uhci-hcd, ehci-hcd, and xhci-hcd support runtime PM, the .pm
field in their pci_driver structures should be protected by CONFIG_PM
rather than CONFIG_PM_SLEEP. The corresponding change has already
been made for ohci-hcd.
Without this change, controllers won't do runtime suspend if system
suspend or hibernation isn't enabled.
Signed-off-by: Alan Stern <stern@rowland.harvard.edu>
CC: Sarah Sharp <sarah.a.sharp@linux.intel.com>
CC: <stable@vger.kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Commit 24f531371d (USB: EHCI: accept very late isochronous URBs)
changed the isochronous API provided by ehci-hcd. URBs submitted too
late, so that the time slots for all their packets have already
expired, are no longer rejected outright. Instead the submission is
accepted, and the URB completes normally with a -EXDEV error for each
packet. This is what client drivers expect.
This patch implements the same policy in ohci-hcd. The change is more
complicated than it was in ehci-hcd, because ohci-hcd doesn't scan for
isochronous completions in the same way as ehci-hcd does. Rather, it
depends on the hardware adding completed TDs to a "done queue". Some
OHCI controller don't handle this properly when a TD's time slot has
already expired, so we have to avoid adding such TDs to the schedule
in the first place. As a result, if the URB was submitted too late
then none of its TDs will get put on the schedule, so none of them
will end up on the done queue, so the driver will never realize that
the URB should be completed.
To solve this problem, the patch adds one to urb_priv->td_cnt for such
URBs, making it larger than urb_priv->length (td_cnt already gets set
to the number of TD's that had to be skipped because their slots have
expired). Each time an URB is given back, the finish_urb() routine
looks to see if urb_priv->td_cnt for the next URB on the same endpoint
is marked in this way. If so, it gives back the next URB right away.
This should be applied to all kernels containing commit 815fa7b917
(USB: OHCI: fix logic for scheduling isochronous URBs).
Signed-off-by: Alan Stern <stern@rowland.harvard.edu>
CC: <stable@vger.kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Commit 24f531371d (USB: EHCI: accept very late isochronous URBs)
changed the isochronous API provided by ehci-hcd. URBs submitted too
late, so that the time slots for all their packets have already
expired, are no longer rejected outright. Instead the submission is
accepted, and the URB completes normally with a -EXDEV error for each
packet. This is what client drivers expect.
This patch implements the same policy in uhci-hcd. It should be
applied to all kernels containing commit c44b225077 (UHCI: implement
new semantics for URB_ISO_ASAP).
Signed-off-by: Alan Stern <stern@rowland.harvard.edu>
CC: <stable@vger.kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Commit 24f531371d (USB: EHCI: accept very late isochronous URBs)
changed the isochronous API provided by ehci-hcd. URBs submitted too
late, so that the time slots for all their packets have already
expired, are no longer rejected outright. Instead the submission is
accepted, and the URB completes normally with a -EXDEV error for each
packet. This is what client drivers expect.
The same policy should be implemented in imx21-hcd, but I don't know
enough about the hardware to do it. As a second-best substitute, this
patch treats very late isochronous submissions as though the
URB_ISO_ASAP flag were set. I don't have any way to test this change,
unfortunately.
Signed-off-by: Alan Stern <stern@rowland.harvard.edu>
CC: Sascha Hauer <kernel@pengutronix.de>
CC: Martin Fuzzey <mfuzzey@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
In gadget mode, musb->is_active should be set only when connected to the
host. musb_g_reset() already takes care of it.
Signed-off-by: Bin Liu <b-liu@ti.com>
Signed-off-by: Felipe Balbi <balbi@ti.com>
Set SEL control urbs cannot be sent to a device in unconfigured state.
This patch adds a check in usb_req_set_sel() to ensure the usb device's
state is USB_STATE_CONFIGURED.
Signed-off-by: Xenia Ragiadakou <burzalodowa@gmail.com>
Reported-by: Martin MOKREJS <mmokrejs@gmail.com>
Suggested-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
The halted state of a endpoint cannot be cleared over CLEAR_HALT from a
user process, because the stopped_td variable was overwritten in the
handle_stopped_endpoint() function. So the xhci_endpoint_reset() function will
refuse the reset and communication with device can not run over this endpoint.
https://bugzilla.kernel.org/show_bug.cgi?id=60699
Signed-off-by: Florian Wolter <wolly84@web.de>
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
When a device signals remote wakeup on a roothub, and the suspend change
bit is set, the host controller driver must not give control back to the
USB core until the port goes back into the active state.
EHCI accomplishes this by waiting in the get port status function until
the PORT_RESUME bit is cleared:
/* stop resume signaling */
temp &= ~(PORT_RWC_BITS | PORT_SUSPEND | PORT_RESUME);
ehci_writel(ehci, temp, status_reg);
clear_bit(wIndex, &ehci->resuming_ports);
retval = ehci_handshake(ehci, status_reg,
PORT_RESUME, 0, 2000 /* 2msec */);
Similarly, the xHCI host should wait until the port goes into U0, before
passing control up to the USB core. When the port transitions from the
RExit state to U0, the xHCI driver will get a port status change event.
We need to wait for that event before passing control up to the USB
core.
After the port transitions to the active state, the USB core should time
a recovery interval before it talks to the device. The length of that
recovery interval is TRSMRCY, 10 ms, mentioned in the USB 2.0 spec,
section 7.1.7.7. The previous xHCI code (which did not wait for the
port to go into U0) would cause the USB core to violate that recovery
interval.
This bug caused numerous USB device disconnects on remote wakeup under
ChromeOS and a Lynx Point LP xHCI host that takes up to 20 ms to move
from RExit to U0. ChromeOS is very aggressive about power savings, and
sets the autosuspend_delay to 100 ms, and disables USB persist.
I attempted to replicate this bug with Ubuntu 12.04, but could not. I
used Ubuntu 12.04 on the same platform, with the same BIOS that the bug
was triggered on ChromeOS with. I also changed the USB sysfs settings
as described above, but still could not reproduce the bug under Ubuntu.
It may be that ChromeOS userspace triggers this bug through additional
settings.
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
If a command on the command ring needs to be cancelled before it is handled
it can be turned to a no-op operation when the ring is stopped.
We want to store the command ring enqueue pointer in the command structure
when the command in enqueued for the cancellation case.
Some commands used to store the command ring dequeue pointers instead of enqueue
(these often worked because enqueue happends to equal dequeue quite often)
Other commands correctly used the enqueue pointer but did not check if it pointed
to a valid trb or a link trb, this caused for example stop endpoint command to timeout in
xhci_stop_device() in about 2% of suspend/resume cases.
This should also solve some weird behavior happening in command cancellation cases.
This patch is based on a patch submitted by Sarah Sharp to linux-usb, but
then forgotten:
http://marc.info/?l=linux-usb&m=136269803207465&w=2
This patch should be backported to kernels as old as 3.7, that contain
the commit b92cc66c04 "xHCI: add aborting
command ring function"
Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com>
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Cc: stable@vger.kernel.org
When a command times out, the command ring is first aborted,
and then stopped. If the command ring is empty when it is stopped
the stop event will point to next command which is not yet set.
xHCI tries to handle this next event often causing an oops.
Don't handle command completion events on stopped cmd ring if ring is
empty.
This patch should be backported to kernels as old as 3.7, that contain
the commit b92cc66c04 "xHCI: add aborting
command ring function"
Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com>
Reported-by: Giovanni <giovanni.nervi@yahoo.com>
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Cc: stable@vger.kernel.org
This reverts commit 3b8d7321ed, which
brings back commit 428aac8a81 as it should
be working for the 3.13-rc1 merge window now that Alan's other fixes are
here in the tree already.
Cc: Alan Stern <stern@rowland.harvard.edu>
Cc: Ming Lei <ming.lei@canonical.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
We have USB fixes now in Linus's tree that we need to properly sort out
with reverts and the like in the usb-next branch, so merge them together
and do it by hand.
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Move probe out of __init section and don't use platform_driver_probe
which cannot be used with deferred probing.
Since commit e9354576 ("gpiolib: Defer failed gpio requests by default")
and 04bf3011 ("regulator: Support driver probe deferral") this driver
might return -EPROBE_DEFER if a gpio_request or regulator_get fails.
Cc: Felipe Balbi <balbi@ti.com>
Signed-off-by: Johan Hovold <jhovold@gmail.com>
Signed-off-by: Felipe Balbi <balbi@ti.com>
Move probe out of __init section and don't use platform_driver_probe
which cannot be used with deferred probing.
Since commit e9354576 ("gpiolib: Defer failed gpio requests by default")
this driver might return -EPROBE_DEFER if a gpio_request fails.
Cc: Eric Miao <eric.y.miao@gmail.com>
Cc: Russell King <linux@arm.linux.org.uk>
Cc: Haojian Zhuang <haojian.zhuang@gmail.com>
Cc: Felipe Balbi <balbi@ti.com>
Signed-off-by: Johan Hovold <jhovold@gmail.com>
Signed-off-by: Felipe Balbi <balbi@ti.com>
Here's first set of fixes for v3.12-rc series, patches have
been soaking in linux-usb for a while now.
We have the usual sparse and build warnings, a Kconfig fix
to a mismerge on dwc3 Kconfig, fix for a possible memory leak
in dwc3, s3c-hsotg won't disconnect when bus goes idle, locking
fix in mv_u3d_core, endpoint disable fix in f_mass_storage.
We also have one device ID added to dwc3's PCI glue layer in order
to support Intel's BayTrail devices.
Signed-of-by: Felipe Balbi <balbi@ti.com>
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)
iQIcBAABAgAGBQJSOH9nAAoJEIaOsuA1yqRElTcQALIZuTv00Lg4Sts4tHHVO3KB
qvQEcv9cBZFtQkD053ufAkJ7uRMkl7Ew5jzJj3AFhLwQ8d0eOY6O9lARG2mZdJf1
99mCw/BgLAs9q9xgAQvuVOnmXNsi/+A5LQrbcfUG5hoecVZZhfPKZydkUGRE4+be
UG7T0D72saa3GfnvuHGv1Z5i4IEijx6amzPaFuDQzsRNjpdEn28lqvp5nN/amKuw
Bda++9o5DPEu/I+MseTx8eSUfrvqR7khFOxJeNlhJxkgoDQiEXaOQEbgIj1bLcEx
bs7RF28r0Rs75seImD+0TiXlGJVr/kv2EJ5RI4qgZ+MRxu8lrfeUWHNCdIiAI62d
rqwqnxL0AZiHuQdN2AEle9VJsoBaDw2sB8GiDQ3ZHms3InEVaVtAIpd+E0gXdf0y
W713iZqf/9zcfuoTA0y8G/foCaWuUXr89kpv5mpGejAJBLbHRk/0hEQzW4Y/eeMb
RbKjWFseD2bEWGlRqIcd2E73AKM8TccjmEc+khj/9kZzbrF+uoUbUrULhkKHp190
4fBKVT/0y4s63zadmkebN91vUBpLtnYIykXU4sDm79GlImMXJA/RLmkbfCtaDyAQ
7rEknrLEpvMVe6VbSMiitgmZb8qwy2kemhGCGbJ6e4jU7BKThUTE1gt8SlJhQm1M
W2SoxhxQRKxXtQT/xkxt
=51X+
-----END PGP SIGNATURE-----
Merge tag 'fixes-for-v3.12-rc2' of git://git.kernel.org/pub/scm/linux/kernel/git/balbi/usb into usb-linus
Felipe writes:
usb: fixes for v3.12-rc2
Here's first set of fixes for v3.12-rc series, patches have
been soaking in linux-usb for a while now.
We have the usual sparse and build warnings, a Kconfig fix
to a mismerge on dwc3 Kconfig, fix for a possible memory leak
in dwc3, s3c-hsotg won't disconnect when bus goes idle, locking
fix in mv_u3d_core, endpoint disable fix in f_mass_storage.
We also have one device ID added to dwc3's PCI glue layer in order
to support Intel's BayTrail devices.
Signed-of-by: Felipe Balbi <balbi@ti.com>
Right after the musb_hdrc driver is loaded, the otg default state
is a_idle, and Mode=Host, which are set by musb_host_setup().
This causes the following kernel message during musb gadget
enumeration.
CAUTION: musb: Babble Interrupt Occurred
This patch sets the otg default state to b_idle, and its Mode to
Peripheral.
It has been validated on TI AM335x GP EVM USB0 port with g_zero.
Signed-off-by: Bin Liu <b-liu@ti.com>
Signed-off-by: Felipe Balbi <balbi@ti.com>
Urb fields are stored in struct usbdevfs_ctrltransfer in CPU byteorder
and not in little endian, so there is no need to be converted.
This bug was reported by sparse.
Signed-off-by: Xenia Ragiadakou <burzalodowa@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
In the bos usb_ss_cap_descriptor structure, bU2DevExitLat is of type __le16.
This value is used as it is, without being first converted to the CPU
byteorder, for the setup of usb device's usb3_lpm_parameters.
This patch fixes that by converting bU2DevExitLat field to the CPU byteorder
before the assignmenment to [udev/hub]_u2_del variables.
Signed-off-by: Xenia Ragiadakou <burzalodowa@gmail.com>
Reported-by: kbuild test robot <fengguang.wu@intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
This patch sets the lpm_capable field for root hubs with LPM capabilities.
Signed-off-by: Xenia Ragiadakou <burzalodowa@gmail.com>
Reported-by: Martin MOKREJS <mmokrejs@gmail.com>
Suggested-by: Alan Stern <stern@rowland.harvard.edu>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
The hcd-driver free_streams method can return an error, so lets properly
propagate that.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Casting the return value which is a void pointer is redundant.
The conversion from void pointer to any other pointer type is
guaranteed by the C programming language.
Signed-off-by: Jingoo Han <jg1.han@samsung.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
