While testing our host system using Microsoft's usb stack against our
gadget for various BESL values, we found an issue with their usb stack
when the recommended baseline BESL value is 0 (125us) or when the deep
BESL is 1 or less. The Windows host will issue a usb reset immediately
after it receives the extended BOS descriptor and the enumeration will
fail after a few attempts.
To keep compatibility with Microsoft's host usb stack, let's workaround
this issue by using the recommended baseline BESL of 1 (or 150us)
and clamp the deep BESL value within 2 to 15.
This was tested against Windows 10 build 18956.
Signed-off-by: Thinh Nguyen <thinhn@synopsys.com>
Signed-off-by: Felipe Balbi <felipe.balbi@linux.intel.com>
Controller for OUT endpoints has shared on-chip buffers for all incoming
packets, including ep0out. It's FIFO buffer, so packets must be handled
by DMA in correct order. If the first packet in the buffer will not be
handled, then the following packets directed for other endpoints and
functions will be blocked.
Additionally the packets directed to one endpoint can block entire on-chip
buffers. In this case transfer to other endpoints also will blocked.
To resolve this issue after raising the descriptor missing interrupt
driver prepares internal usb_request object and use it to arm DMA
transfer.
The problematic situation was observed in case when endpoint has
been enabled but no usb_request were queued. Driver try detects
such endpoints and will use this workaround only for these endpoint.
Driver use limited number of buffer. This number can be set by macro
CDNS_WA2_NUM_BUFFERS.
Such blocking situation was observed on ACM gadget. For this function
host send OUT data packet but ACM function is not prepared for
this packet. It's cause that buffer placed in on chip memory block
transfer to other endpoints.
Issue has been fixed for DEV_VER_V2 version of controller.
Signed-off-by: Pawel Laszczak <pawell@cadence.com>
Signed-off-by: Felipe Balbi <felipe.balbi@linux.intel.com>
This patch introduce new Cadence USBSS DRD driver to Linux kernel.
The Cadence USBSS DRD Controller is a highly configurable IP Core which
can be instantiated as Dual-Role Device (DRD), Peripheral Only and
Host Only (XHCI)configurations.
The current driver has been validated with FPGA platform. We have
support for PCIe bus, which is used on FPGA prototyping.
The host side of USBSS-DRD controller is compliant with XHCI
specification, so it works with standard XHCI Linux driver.
Signed-off-by: Pawel Laszczak <pawell@cadence.com>
Signed-off-by: Felipe Balbi <felipe.balbi@linux.intel.com>
Patch moves switch responsible for decoding descriptor type
outside snprintf. It improves code readability a little.
Signed-off-by: Pawel Laszczak <pawell@cadence.com>
Signed-off-by: Felipe Balbi <felipe.balbi@linux.intel.com>
Patch adds usb_decode_test_mode and usb_decode_device_feature functions,
which allow to make more readable and simplify the
usb_decode_set_clear_feature function.
Signed-off-by: Pawel Laszczak <pawell@cadence.com>
Signed-off-by: Felipe Balbi <felipe.balbi@linux.intel.com>
Patch moves some decoding functions from driver/usb/dwc3/debug.h driver
to driver/usb/common/debug.c file. These moved functions include:
dwc3_decode_get_status
dwc3_decode_set_clear_feature
dwc3_decode_set_address
dwc3_decode_get_set_descriptor
dwc3_decode_get_configuration
dwc3_decode_set_configuration
dwc3_decode_get_intf
dwc3_decode_set_intf
dwc3_decode_synch_frame
dwc3_decode_set_sel
dwc3_decode_set_isoch_delay
dwc3_decode_ctrl
These functions are used also in inroduced cdns3 driver.
All functions prefixes were changed from dwc3 to usb.
Also, function's parameters has been extended according to the name
of fields in standard SETUP packet.
Additionally, patch adds usb_decode_ctrl function to
include/linux/usb/ch9.h file.
Signed-off-by: Pawel Laszczak <pawell@cadence.com>
Signed-off-by: Felipe Balbi <felipe.balbi@linux.intel.com>
Some SoCs may have an optional clock xhci_ck (125M or 200M), it
usually uses the same PLL as sys_ck, so support it.
Signed-off-by: Chunfeng Yun <chunfeng.yun@mediatek.com>
Acked-by: Mathias Nyman <mathias.nyman@linux.intel.com>
Reviewed-by: Matthias Brugger <matthias.bgg@gmail.com>
Link: https://lore.kernel.org/r/1566542425-20082-2-git-send-email-chunfeng.yun@mediatek.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
In case of a disconnect an ongoing flush() has to be made fail.
Nevertheless we cannot be sure that any pending URB has already
finished, so although they will never succeed, they still must
not be touched.
The clean solution for this is to check for WDM_IN_USE
and WDM_DISCONNECTED in flush(). There is no point in ever
clearing WDM_IN_USE, as no further writes make sense.
The issue is as old as the driver.
Fixes: afba937e540c9 ("USB: CDC WDM driver")
Reported-by: syzbot+d232cca6ec42c2edb3fc@syzkaller.appspotmail.com
Signed-off-by: Oliver Neukum <oneukum@suse.com>
Cc: stable <stable@vger.kernel.org>
Link: https://lore.kernel.org/r/20190827103436.21143-1-oneukum@suse.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
It's spelled "renesas", not "renensas".
Due to this typo, RZ/G1M and RZ/G1N were not covered by the check.
Fixes: 2dc240a3308b ("usb: host: xhci: rcar: retire use of xhci_plat_type_is()")
Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
Cc: stable <stable@vger.kernel.org>
Reviewed-by: Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com>
Link: https://lore.kernel.org/r/20190827125112.12192-1-geert+renesas@glider.be
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
The Falcon microcontroller that runs the XUSB firmware and which is
responsible for exposing the XHCI interface can address only 40 bits of
memory. Typically that's not a problem because Tegra devices don't have
enough system memory to exceed those 40 bits.
However, if the ARM SMMU is enable on Tegra186 and later, the addresses
passed to the XUSB controller can be anywhere in the 48-bit IOV address
space of the ARM SMMU. Since the DMA/IOMMU API starts allocating from
the top of the IOVA space, the Falcon microcontroller is not able to
load the firmware successfully.
Fix this by setting the DMA mask to 40 bits, which will force the DMA
API to map the buffer for the firmware to an IOVA that is addressable by
the Falcon.
Signed-off-by: Nagarjuna Kristam <nkristam@nvidia.com>
Signed-off-by: Thierry Reding <treding@nvidia.com>
Link: https://lore.kernel.org/r/1566989697-13049-1-git-send-email-nkristam@nvidia.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Auto-delink requires writing special registers to ums-realtek devices.
Unconditionally enable auto-delink may break newer devices.
So only enable auto-delink by default for the original three IDs,
0x0138, 0x0158 and 0x0159.
Realtek is working on a patch to properly support auto-delink for other
IDs.
BugLink: https://bugs.launchpad.net/bugs/1838886
Signed-off-by: Kai-Heng Feng <kai.heng.feng@canonical.com>
Acked-by: Alan Stern <stern@rowland.harvard.edu>
Cc: stable <stable@vger.kernel.org>
Link: https://lore.kernel.org/r/20190827173450.13572-2-kai.heng.feng@canonical.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
The option named "auto_delink_en" is a bit misleading, as setting it to
false doesn't really disable auto-delink but let auto-delink be firmware
controlled.
Update the description to reflect the real usage of this parameter.
Signed-off-by: Kai-Heng Feng <kai.heng.feng@canonical.com>
Cc: stable <stable@vger.kernel.org>
Link: https://lore.kernel.org/r/20190827173450.13572-1-kai.heng.feng@canonical.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
This patch fixes an issue that the following error is
possible to happen when ohci hardware causes an interruption
and the system is shutting down at the same time.
[ 34.851754] usb 2-1: USB disconnect, device number 2
[ 35.166658] irq 156: nobody cared (try booting with the "irqpoll" option)
[ 35.173445] CPU: 0 PID: 22 Comm: kworker/0:1 Not tainted 5.3.0-rc5 #85
[ 35.179964] Hardware name: Renesas Salvator-X 2nd version board based on r8a77965 (DT)
[ 35.187886] Workqueue: usb_hub_wq hub_event
[ 35.192063] Call trace:
[ 35.194509] dump_backtrace+0x0/0x150
[ 35.198165] show_stack+0x14/0x20
[ 35.201475] dump_stack+0xa0/0xc4
[ 35.204785] __report_bad_irq+0x34/0xe8
[ 35.208614] note_interrupt+0x2cc/0x318
[ 35.212446] handle_irq_event_percpu+0x5c/0x88
[ 35.216883] handle_irq_event+0x48/0x78
[ 35.220712] handle_fasteoi_irq+0xb4/0x188
[ 35.224802] generic_handle_irq+0x24/0x38
[ 35.228804] __handle_domain_irq+0x5c/0xb0
[ 35.232893] gic_handle_irq+0x58/0xa8
[ 35.236548] el1_irq+0xb8/0x180
[ 35.239681] __do_softirq+0x94/0x23c
[ 35.243253] irq_exit+0xd0/0xd8
[ 35.246387] __handle_domain_irq+0x60/0xb0
[ 35.250475] gic_handle_irq+0x58/0xa8
[ 35.254130] el1_irq+0xb8/0x180
[ 35.257268] kernfs_find_ns+0x5c/0x120
[ 35.261010] kernfs_find_and_get_ns+0x3c/0x60
[ 35.265361] sysfs_unmerge_group+0x20/0x68
[ 35.269454] dpm_sysfs_remove+0x2c/0x68
[ 35.273284] device_del+0x80/0x370
[ 35.276683] hid_destroy_device+0x28/0x60
[ 35.280686] usbhid_disconnect+0x4c/0x80
[ 35.284602] usb_unbind_interface+0x6c/0x268
[ 35.288867] device_release_driver_internal+0xe4/0x1b0
[ 35.293998] device_release_driver+0x14/0x20
[ 35.298261] bus_remove_device+0x110/0x128
[ 35.302350] device_del+0x148/0x370
[ 35.305832] usb_disable_device+0x8c/0x1d0
[ 35.309921] usb_disconnect+0xc8/0x2d0
[ 35.313663] hub_event+0x6e0/0x1128
[ 35.317146] process_one_work+0x1e0/0x320
[ 35.321148] worker_thread+0x40/0x450
[ 35.324805] kthread+0x124/0x128
[ 35.328027] ret_from_fork+0x10/0x18
[ 35.331594] handlers:
[ 35.333862] [<0000000079300c1d>] usb_hcd_irq
[ 35.338126] [<0000000079300c1d>] usb_hcd_irq
[ 35.342389] Disabling IRQ #156
ohci_shutdown() disables all the interrupt and rh_state is set to
OHCI_RH_HALTED. In other hand, ohci_irq() is possible to enable
OHCI_INTR_SF and OHCI_INTR_MIE on ohci_irq(). Note that OHCI_INTR_SF
is possible to be set by start_ed_unlink() which is called:
ohci_irq()
-> process_done_list()
-> takeback_td()
-> start_ed_unlink()
So, ohci_irq() has the following condition, the issue happens by
&ohci->regs->intrenable = OHCI_INTR_MIE | OHCI_INTR_SF and
ohci->rh_state = OHCI_RH_HALTED:
/* interrupt for some other device? */
if (ints == 0 || unlikely(ohci->rh_state == OHCI_RH_HALTED))
return IRQ_NOTMINE;
To fix the issue, ohci_shutdown() holds the spin lock while disabling
the interruption and changing the rh_state flag to prevent reenable
the OHCI_INTR_MIE unexpectedly. Note that io_watchdog_func() also
calls the ohci_shutdown() and it already held the spin lock, so that
the patch makes a new function as _ohci_shutdown().
This patch is inspired by a Renesas R-Car Gen3 BSP patch
from Tho Vu.
Signed-off-by: Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com>
Cc: stable <stable@vger.kernel.org>
Acked-by: Alan Stern <stern@rowland.harvard.edu>
Link: https://lore.kernel.org/r/1566877910-6020-1-git-send-email-yoshihiro.shimoda.uh@renesas.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Using managed device resources in usb_hcd_pci_probe() allows devm usage for
resource subranges, such as the mmio resource for the platform device
created to control host/device mode mux, which is a xhci extended
capability, and sits inside the xhci mmio region.
If managed device resources are not used then "parent" resource
is released before subrange at driver removal as .remove callback is
called before the devres list of resources for this device is walked
and released.
This has been observed with the xhci extended capability driver causing a
use-after-free which is now fixed.
An additional nice benefit is that error handling on driver initialisation
is simplified much.
Signed-off-by: Carsten Schmid <carsten_schmid@mentor.com>
Tested-by: Carsten Schmid <carsten_schmid@mentor.com>
Reviewed-by: Mathias Nyman <mathias.nyman@linux.intel.com>
Fixes: fa31b3cb2ae1 ("xhci: Add Intel extended cap / otg phy mux handling")
Cc: <stable@vger.kernel.org> # v4.19+
Link: https://lore.kernel.org/r/1566569488679.31808@mentor.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
There appears to be a typo in the comparison of pdo_max_voltage[i]
with the previous value, currently it is checking against the
array pdo_min_voltage rather than pdo_max_voltage. I believe this
is a typo. Fix this.
Addresses-Coverity: ("Copy-paste error")
Fixes: 5007e1b5db73 ("typec: tcpm: Validate source and sink caps")
Cc: stable <stable@vger.kernel.org>
Signed-off-by: Colin Ian King <colin.king@canonical.com>
Reviewed-by: Guenter Roeck <linux@roeck-us.net>
Reviewed-by: Heikki Krogerus <heikki.krogerus@linux.intel.com>
Link: https://lore.kernel.org/r/20190822135212.10195-1-colin.king@canonical.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Enable support for cbus gpios on FT232H. The cbus configuration is
stored in two words in the EEPROM at byte-offset 0x1a with the mux
config for ACBUS5, ACBUS6, ACBUS8 and ACBUS9 (only pins that can be
configured as I/O mode).
Tested using FT232H by configuring one ACBUS pin at a time.
Reviewed-by: Tim Harvey <tharvey@gateworks.com>
Signed-off-by: Matthew Michilot <matthew.michilot@gmail.com>
[ johan: fix copy-paste error in commit message ]
Signed-off-by: Johan Hovold <johan@kernel.org>
Set the recommended BESL deep and baseline values based on the gadget's
configuration parameters to the extended BOS descriptor. This feature
helps to optimize power savings by maximizing the opportunity for longer
L1 residency time.
Signed-off-by: Thinh Nguyen <thinhn@synopsys.com>
Signed-off-by: Felipe Balbi <felipe.balbi@linux.intel.com>
When operating with LPM signals, the controller asserts the deep
low-power signal (utmi_l1_suspend_n) to the phy when the BESL value of
the LPM token is equal to or greater than DCTL.HIRD_Thres[3:0] (and
with DCTL.HIRD_Thres[4] set). Otherwise, the shallow low-power signal
(utmi_sleep_n) is asserted. Set the recommended deep BESL equal to the
controller's DCTL.HIRD_Thres[3:0] setting, and set the baseline BESL
to 0 for the shallow low-power signal. This maximizes the opportunity
for L1 residency and optimizes power savings.
Signed-off-by: Thinh Nguyen <thinhn@synopsys.com>
Signed-off-by: Felipe Balbi <felipe.balbi@linux.intel.com>
dwc->hird_threshold field should store "snps,hird_threshold" property
only and not a combination of multiple properties. Remove the value of
"snps,is-utmi-l1-suspend" property from the field dwc->hird_threshold.
Signed-off-by: Thinh Nguyen <thinhn@synopsys.com>
Signed-off-by: Felipe Balbi <felipe.balbi@linux.intel.com>
Static structure fsl_otg_initdata, of type fsl_otg_config, is used only
once, when the value of its field otg_port is assigned to another
variable. As fsl_otg_initdata.otg_port is of type u8, any changes to
its copy do not affect the original, and fsl_otg_initdata itself is
never modified. Hence make fsl_otg_initdata constant to protect it from
unintended modification.
Issue found with Coccinelle.
Signed-off-by: Nishka Dasgupta <nishkadg.linux@gmail.com>
Signed-off-by: Felipe Balbi <felipe.balbi@linux.intel.com>
Silence the following fall-through warning by adding a break statement:
drivers/usb/gadget/udc/lpc32xx_udc.c:2230:3: warning: this statement may
fall through [-Wimplicit-fallthrough=]
Signed-off-by: Gustavo A. R. Silva <gustavo@embeddedor.com>
Signed-off-by: Felipe Balbi <felipe.balbi@linux.intel.com>
When going in suspend, in Device mode, then resuming back leads
to the following:
unbalanced disables for USB_PWR_EN
WARNING: CPU: 0 PID: 163 at ../drivers/regulator/core.c:2590 _regulator_disable+0x104/0x180
Hardware name: Amlogic Meson G12A U200 Development Board (DT)
[...]
pc : _regulator_disable+0x104/0x180
lr : _regulator_disable+0x104/0x180
[...]
Call trace:
_regulator_disable+0x104/0x180
regulator_disable+0x40/0x78
dwc3_meson_g12a_otg_mode_set+0x84/0xb0
dwc3_meson_g12a_irq_thread+0x58/0xb8
irq_thread_fn+0x28/0x80
irq_thread+0x118/0x1b8
kthread+0xf4/0x120
ret_from_fork+0x10/0x18
This disables the regulator if enabled on suspend, and the reverse on
resume.
Fixes: c99993376f72 ("usb: dwc3: Add Amlogic G12A DWC3 glue")
Tested-by: Kevin Hilman <khilman@baylibre.com>
Reported-by: Kevin Hilman <khilman@baylibre.com>
Signed-off-by: Neil Armstrong <narmstrong@baylibre.com>
Signed-off-by: Felipe Balbi <felipe.balbi@linux.intel.com>
Fixes gcc '-Wunused-but-set-variable' warning:
drivers/usb/gadget/udc/lpc32xx_udc.c: In function ‘udc_protocol_cmd_r’:
drivers/usb/gadget/udc/lpc32xx_udc.c:744:6: warning: variable ‘tmp’ set but not used [-Wunused-but-set-variable]
drivers/usb/gadget/udc/lpc32xx_udc.c: In function ‘udc_handle_dma_ep’:
drivers/usb/gadget/udc/lpc32xx_udc.c:1994:14: warning: variable ‘epstatus’ set but not used [-Wunused-but-set-variable]
drivers/usb/gadget/udc/lpc32xx_udc.c: In function ‘udc_handle_ep0_setup’:
drivers/usb/gadget/udc/lpc32xx_udc.c:2200:22: warning: variable ‘wLength’ set but not used [-Wunused-but-set-variable]
It is not used since commit 90fccb529d24 ("usb: gadget: Gadget directory cleanup - group UDC drivers")
Signed-off-by: Mao Wenan <maowenan@huawei.com>
Signed-off-by: Felipe Balbi <felipe.balbi@linux.intel.com>
In function st_dwc3_probe, variable child_pdev takes the value returned
by of_find_device_by_node, which gets a device pointer but does not put
it. If child_pdev is not put before the probe function returns, it may
cause a reference leak. Hence put child_pdev after its last usage.
Issue found with Coccinelle.
Reviewed-by: Patrice Chotard <patrice.chotard@st.com>
Signed-off-by: Nishka Dasgupta <nishkadg.linux@gmail.com>
Signed-off-by: Felipe Balbi <felipe.balbi@linux.intel.com>
The local variable child in the function st_dwc3_probe takes the return
value of of_get_child_by_name, which gets a node and does not put it. If
the function returns without releasing child, this could cause a memory
error. Hence put child as soon as there is no more use for it. Also
create a new label, err_node_put, just before label undo_softreset; so
that err_node_put puts child. In between initialisation of child and its
first put, modify all statements that go to undo_softreset to now go to
err_node_put instead, from where they can fall through to
undo_softreset.
Issue found with Coccinelle.
Reviewed-by: Patrice Chotard <patrice.chotard@st.com>
Signed-off-by: Nishka Dasgupta <nishkadg.linux@gmail.com>
Signed-off-by: Felipe Balbi <felipe.balbi@linux.intel.com>
This reverts
commit 6a4290cc28be1 ("usb: dwc3: gadget: set the OTG flag in dwc3 gadget driver.")
We don't yet support any of the OTG mechanisms (HNP/SRP/ADP)
and are not setting gadget->otg_caps, so don't set gadget->is_otg
flag.
If we do then we end up publishing a OTG1.0 descriptor in
the gadget descriptor which causes device enumeration to fail
if we are connected to a host with CONFIG_USB_OTG enabled.
Host side log without this patch
[ 96.720453] usb 1-1: new high-speed USB device number 2 using xhci-hcd
[ 96.901391] usb 1-1: Dual-Role OTG device on non-HNP port
[ 96.907552] usb 1-1: set a_alt_hnp_support failed: -32
[ 97.060447] usb 1-1: new high-speed USB device number 3 using xhci-hcd
[ 97.241378] usb 1-1: Dual-Role OTG device on non-HNP port
[ 97.247536] usb 1-1: set a_alt_hnp_support failed: -32
[ 97.253606] usb usb1-port1: attempt power cycle
[ 97.960449] usb 1-1: new high-speed USB device number 4 using xhci-hcd
[ 98.141383] usb 1-1: Dual-Role OTG device on non-HNP port
[ 98.147540] usb 1-1: set a_alt_hnp_support failed: -32
[ 98.300453] usb 1-1: new high-speed USB device number 5 using xhci-hcd
[ 98.481391] usb 1-1: Dual-Role OTG device on non-HNP port
[ 98.487545] usb 1-1: set a_alt_hnp_support failed: -32
[ 98.493532] usb usb1-port1: unable to enumerate USB device
Signed-off-by: Roger Quadros <rogerq@ti.com>
Signed-off-by: Felipe Balbi <felipe.balbi@linux.intel.com>
USB role is fully controlled by usb role switch consumer(e.g. typec),
usb port can be at host mode(USB_ROLE_HOST), device mode connected to
host(USB_ROLE_DEVICE), or not connecting any partner(USB_ROLE_NONE).
Signed-off-by: Li Jun <jun.li@nxp.com>
Signed-off-by: Peter Chen <peter.chen@nxp.com>
The primary purpose for this node will be to allow linking
the users of the switch to it. The users will be for example
USB Type-C connectors. By supplying a reference to this
node in the software nodes representing the USB Type-C
controllers or connectors, the drivers for those devices can
access the switch.
Signed-off-by: Heikki Krogerus <heikki.krogerus@linux.intel.com>
Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Now that we have an explicit HCD_DMA flag, there is not need to override
these methods.
Signed-off-by: Christoph Hellwig <hch@lst.de>
Link: https://lore.kernel.org/r/20190816062435.881-5-hch@lst.de
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
The usb core is the only major place in the kernel that checks for
a non-NULL device dma_mask to see if a device is DMA capable. This
is generally a bad idea, as all major busses always set up a DMA mask,
even if the device is not DMA capable - in fact bus layers like PCI
can't even know if a device is DMA capable at enumeration time. This
leads to lots of workaround in HCD drivers, and also prevented us from
setting up a DMA mask for platform devices by default last time we
tried.
Replace this guess with an explicit HCD_DMA that is set by drivers that
appear to have DMA support.
Signed-off-by: Christoph Hellwig <hch@lst.de>
Link: https://lore.kernel.org/r/20190816062435.881-4-hch@lst.de
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
The code is supposed to clear the RH_A_NPS and RH_A_PSM bits, but it's
a no-op because of the & vs | typo. This bug predates git and it was
only discovered using static analysis so it must not affect too many
people in real life.
Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
Acked-by: Alan Stern <stern@rowland.harvard.edu>
Link: https://lore.kernel.org/r/20190817065520.GA29951@mwanda
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Memory usage for USB memory allocated via mmap() is already accounted
for at mmap() time; no need to account for it again at submiturb time.
Signed-off-by: Gavin Li <git@thegavinli.com>
Acked-by: Alan Stern <stern@rowland.harvard.edu>
Link: https://lore.kernel.org/r/20190814212924.10381-1-gavinli@thegavinli.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Comment block was not in accordance with coding style.
Fixes two checkpatch warnings:
WARNING: Block comments use * on subsequent lines
WARNING: Block comments use a trailing */ on a separate line
Signed-off-by: Jacob Huisman <jacobhuisman@kernelthusiast.com>
Link: https://lore.kernel.org/r/20190815174210.580-1-jacobhuisman@kernelthusiast.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Revision 0x0117 suffers from an identical issue to earlier revisions,
therefore it should be added to the quirks list.
Signed-off-by: Henk van der Laan <opensource@henkvdlaan.com>
Cc: stable <stable@vger.kernel.org>
Link: https://lore.kernel.org/r/20190816200847.21366-1-opensource@henkvdlaan.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
After _gadget_stop_activity is executed, we can consider the hardware
operation for gadget has finished, and the udc can be stopped and enter
low power mode. So, any later hardware operations (from usb_ep_ops APIs
or usb_gadget_ops APIs) should be considered invalid, any deinitializatons
has been covered at _gadget_stop_activity.
I meet this problem when I plug out usb cable from PC using mass_storage
gadget, my callstack like: vbus interrupt->.vbus_session->
composite_disconnect ->pm_runtime_put_sync(&_gadget->dev),
the composite_disconnect will call fsg_disable, but fsg_disable calls
usb_ep_disable using async way, there are register accesses for
usb_ep_disable. So sometimes, I get system hang due to visit register
without clock, sometimes not.
The Linux Kernel USB maintainer Alan Stern suggests this kinds of solution.
See: http://marc.info/?l=linux-usb&m=138541769810983&w=2.
Cc: <stable@vger.kernel.org> #v4.9+
Signed-off-by: Peter Chen <peter.chen@nxp.com>
Link: https://lore.kernel.org/r/20190820020503.27080-2-peter.chen@nxp.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
A malicious device can make the driver divide ny zero
with a nonsense maximum packet size.
Signed-off-by: Oliver Neukum <oneukum@suse.com>
Cc: stable <stable@vger.kernel.org>
Link: https://lore.kernel.org/r/20190820092826.17694-1-oneukum@suse.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Silence the following fall-through warning by adding a break statement:
drivers/usb/gadget/udc/lpc32xx_udc.c:2230:3: warning: this statement may
fall through [-Wimplicit-fallthrough=]
Signed-off-by: Gustavo A. R. Silva <gustavo@embeddedor.com>
Link: https://lore.kernel.org/r/20190821021627.GA2679@embeddedor
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Use usb_debug_root as root for our debugfs entry instead of creating our
own subdirectory under the debugfs root.
Reviewed-by: Guenter Roeck <linux@roeck-us.net>
Reviewed-by: Heikki Krogerus <heikki.krogerus@linux.intel.com>
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Link: https://lore.kernel.org/r/20190817184340.64086-2-hdegoede@redhat.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Use usb_debug_root as root for our debugfs entry instead of creating our
own subdirectory under the debugfs root.
Another patch in this series will make the same change to the fusb302
driver, which also uses dev_name() (on the same device) for the debugfs
entry name. So we also prefix dev_name() with "tcpm-" here to avoid a
name conflict.
Reviewed-by: Guenter Roeck <linux@roeck-us.net>
Reviewed-by: Heikki Krogerus <heikki.krogerus@linux.intel.com>
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Link: https://lore.kernel.org/r/20190817184340.64086-1-hdegoede@redhat.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Here are some new modem device ids.
All have been in linux-next with no reported issues.
Signed-off-by: Johan Hovold <johan@kernel.org>
-----BEGIN PGP SIGNATURE-----
iHUEABYIAB0WIQQHbPq+cpGvN/peuzMLxc3C7H1lCAUCXVe4uwAKCRALxc3C7H1l
CAEzAP4y40hA9kURiWO9uraTS03LPYc/uswVhIp5+4fyfnt/PwD+JtqGzpBAt8c9
vkXbLOLHxreIrjkN0EUj/jFaAMHT/AQ=
=0zL4
-----END PGP SIGNATURE-----
Merge tag 'usb-serial-5.3-rc5' of https://git.kernel.org/pub/scm/linux/kernel/git/johan/usb-serial into usb-linus
Johan writes:
USB-serial fixes for 5.3-rc5
Here are some new modem device ids.
All have been in linux-next with no reported issues.
Signed-off-by: Johan Hovold <johan@kernel.org>
* tag 'usb-serial-5.3-rc5' of https://git.kernel.org/pub/scm/linux/kernel/git/johan/usb-serial:
USB: serial: option: add the BroadMobi BM818 card
USB: serial: option: Add Motorola modem UARTs
USB: serial: option: add D-Link DWM-222 device ID
USB: serial: option: Add support for ZTE MF871A
Platform drivers now have the option to have the platform core create
and remove any needed sysfs attribute files. So take advantage of that
and do not register "by hand" any sysfs files.
Acked-by: Felipe Balbi <felipe.balbi@linux.intel.com>
Link: https://lore.kernel.org/r/20190815125903.GA17065@kroah.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
The only thing that prevents building this driver on other
platforms is the mach/hardware.h include, which is not actually
used here at all, so remove the line and allow CONFIG_COMPILE_TEST.
Link: https://lore.kernel.org/r/20190809144043.476786-3-arnd@arndb.de
Acked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Acked-by: Sylvain Lemieux <slemieux.tyco@gmail.com>
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
The driver hardcodes a hardware I/O address the way one should
generally not do, and this prevents both compile-testing, and
moving the platform to CONFIG_ARCH_MULTIPLATFORM.
Change the code to be independent of the machine headers
to allow those two. Removing the hardcoded address would
be hard and is not necessary, so leave that in place for now.
Link: https://lore.kernel.org/r/20190809144043.476786-2-arnd@arndb.de
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Reviewed-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
The variable sendToTransport is being initialized with a value that is
never read and is being re-assigned a little later on. The assignment
is redundant and hence can be removed.
Addresses-Coverity: ("Unused value")
Signed-off-by: Colin Ian King <colin.king@canonical.com>
Acked-by: Alan Stern <stern@rowland.harvard.edu>
Link: https://lore.kernel.org/r/20190809173314.4623-1-colin.king@canonical.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
By registering a software fwnode for the port when the
firmware does not supply one, we can always provide tcpm the
connector capabilities by using the common USB connector
device properties instead of using tcpc_config platform data.
Signed-off-by: Heikki Krogerus <heikki.krogerus@linux.intel.com>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
Reviewed-by: Guenter Roeck <linux@roeck-us.net>
Link: https://lore.kernel.org/r/20190814132419.39759-4-heikki.krogerus@linux.intel.com
Tested-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Removing the deprecated fusb302 specific properties. There
are no more platforms using them.
Signed-off-by: Heikki Krogerus <heikki.krogerus@linux.intel.com>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
Reviewed-by: Guenter Roeck <linux@roeck-us.net>
Link: https://lore.kernel.org/r/20190814132419.39759-2-heikki.krogerus@linux.intel.com
Tested-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
The USB buffer allocation code is the only place in the usb core (and in
fact the whole kernel) that uses is_device_dma_capable, while the URB
mapping code uses the uses_dma flag in struct usb_bus. Switch the buffer
allocation to use the uses_dma flag used by the rest of the USB code,
and create a helper in hcd.h that checks this flag as well as the
CONFIG_HAS_DMA to simplify the caller a bit.
Signed-off-by: Christoph Hellwig <hch@lst.de>
Link: https://lore.kernel.org/r/20190811080520.21712-3-hch@lst.de
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
