- 30 Jul, 2020 1 commit
-
-
Paul Cercueil authored
Register a power supply charger, whose online state depends on whether the USB role is set to device or not. This is useful when the USB role is the only way to know if the device is charging from USB. The API is the standard power supply charger API, you get a /sys/class/power_supply/xxx/online node which tells you the state of the charger. The sole purpose of this is to give userspace applications a way to know whether or not the charger is plugged. Signed-off-by:
Paul Cercueil <paul@crapouillou.net> Link: https://lore.kernel.org/r/20200727170413.23131-1-paul@crapouillou.netSigned-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
- 29 Jul, 2020 28 commits
-
-
Chunfeng Yun authored
Use argument req directly instead of mreq->request, they are the same usb request. Signed-off-by:
Chunfeng Yun <chunfeng.yun@mediatek.com> Link: https://lore.kernel.org/r/1595834101-13094-11-git-send-email-chunfeng.yun@mediatek.comSigned-off-by:
-
Chunfeng Yun authored
If not clear u3port's dual mode when disable device, the IP will fail to enter sleep mode when suspend. Signed-off-by:
-
Chunfeng Yun authored
Use MTU3_EP_WEDGE flag instead of the member @wedged in mtu3_ep struct, then @wedged can be removed. Signed-off-by:
-
Chunfeng Yun authored
The member @busy in mtu3_ep struct is unnecessary, so remove it. Signed-off-by:
-
Chunfeng Yun authored
The caller already print error log. Signed-off-by:
-
Chunfeng Yun authored
Make use of the method to make sure connect on speeds supported by the gadget driver. Signed-off-by:
-
Chunfeng Yun authored
The max_speed got from DTS may be not supported by the hardware, so need check it, and assign a proper default value. And make it clear by introducing a funtion. Signed-off-by:
-
Chunfeng Yun authored
When disable interrupts, will also want to clear their status, ensure it by calling mtu3_intr_status_clear() in mtu3_intr_disable(). Signed-off-by:
-
Chunfeng Yun authored
The CSR registers will be reset as default value if the ports are disabled, so reinitialize them when the ports are enabled again. Signed-off-by:
-
Chunfeng Yun authored
The bits field for maximum number of packets is 8 bits. Signed-off-by:
-
Chunfeng Yun authored
The class driver will ensure the parameters are valid pointers before call the hook function of usb_ep_ops, so no need check them again. Signed-off-by:
-
Forest Crossman authored
I've confirmed that the ASMedia ASM1142 has the same problem as the ASM2142/ASM3142, in that it too reports that it supports 64-bit DMA addresses when in fact it does not. As with the ASM2142/ASM3142, this can cause problems on systems where the upper bits matter, and adding the XHCI_NO_64BIT_SUPPORT quirk completely fixes the issue. Acked-by:
Mathias Nyman <mathias.nyman@linux.intel.com> Signed-off-by:
Forest Crossman <cyrozap@gmail.com> Cc: stable <stable@vger.kernel.org> Link: https://lore.kernel.org/r/20200728042408.180529-3-cyrozap@gmail.comSigned-off-by:
-
Forest Crossman authored
Not all ASMedia host controllers have a device ID that matches its part number. #define some of these IDs to make it clearer at a glance which chips require what quirks. Acked-by:
-
Chunfeng Yun authored
Use devm_platform_ioremap_resource_byname() to simplify code Cc: Bin Liu <b-liu@ti.com> Signed-off-by:
-
Chunfeng Yun authored
Use devm_platform_ioremap_resource_byname() to simplify code Cc: Nagarjuna Kristam <nkristam@nvidia.com> Signed-off-by:
-
Chunfeng Yun authored
Use devm_platform_ioremap_resource_byname() to simplify code Signed-off-by:
-
Chunfeng Yun authored
Use devm_platform_ioremap_resource_byname() to simplify code Cc: Patrice Chotard <patrice.chotard@st.com> Reviewed-by:
Patrice Chotard <patrice.chotard@st.com> Signed-off-by:
-
Chunfeng Yun authored
Use devm_platform_ioremap_resource_byname() to simplify code Cc: Peter Chen <peter.chen@nxp.com> Reviewed-by:
Peter Chen <peter.chen@nxp.com> Signed-off-by:
-
Chunfeng Yun authored
Use devm_platform_ioremap_resource_byname() to simplify code Signed-off-by:
-
Chunfeng Yun authored
Use devm_platform_ioremap_resource_byname() to simplify code Signed-off-by:
-
Bastien Nocera authored
usb_device_match_id() supports being passed NULL tables, so no need to check for it. Signed-off-by:
Bastien Nocera <hadess@hadess.net> Link: https://lore.kernel.org/r/20200727104644.149873-1-hadess@hadess.netSigned-off-by:
-
Hans de Goede authored
The tcpm.c code for sending VDMs assumes that there will only be one VDM in flight at the time. The "queue" used by tcpm_queue_vdm is only 1 entry deep. This assumes that the higher layers (tcpm state-machine and alt-mode drivers) ensure that queuing a new VDM before the old one has been completely send (or it timed out) add a WARN_ON to check for this. Reviewed-by:
Heikki Krogerus <heikki.krogerus@linux.intel.com> Reviewed-by:
Guenter Roeck <linux@roeck-us.net> Signed-off-by:
Hans de Goede <hdegoede@redhat.com> Link: https://lore.kernel.org/r/20200724174702.61754-6-hdegoede@redhat.comSigned-off-by:
-
Hans de Goede authored
When we receive a PD data packet which ends up being for the alt-mode driver we have the following lock order: 1. tcpm_pd_rx_handler take the tcpm-port lock 2. We call into the alt-mode driver which takes the alt-mode's lock And when the alt-mode driver initiates communication we have the following lock order: 3. alt-mode driver takes the alt-mode's lock 4. alt-mode driver calls tcpm_altmode_enter which takes the tcpm-port lock This is a classic AB BA lock inversion issue. With the refactoring of tcpm_handle_vdm_request() done before this patch, we don't rely on, or need to make changes to the tcpm-port data by the time we make call 2. from above. All data to be passed to the alt-mode driver sits on our stack at this point, and thus does not need locking. So after the refactoring we can simply fix this by releasing the tcpm-port lock before calling into the alt-mode driver. This fixes the following lockdep warning: [ 191.454238] ====================================================== [ 191.454240] WARNING: possible circular locking dependency detected [ 191.454244] 5.8.0-rc5+ #1 Not tainted [ 191.454246] ------------------------------------------------------ [ 191.454248] kworker/u8:5/794 is trying to acquire lock: [ 191.454251] ffff9bac8e30d4a8 (&dp->lock){+.+.}-{3:3}, at: dp_altmode_vdm+0x30/0xf0 [typec_displayport] [ 191.454263] but task is already holding lock: [ 191.454264] ffff9bac9dc240a0 (&port->lock#2){+.+.}-{3:3}, at: tcpm_pd_rx_handler+0x43/0x12c0 [tcpm] [ 191.454273] which lock already depends on the new lock. [ 191.454275] the existing dependency chain (in reverse order) is: [ 191.454277] -> #1 (&port->lock#2){+.+.}-{3:3}: [ 191.454286] __mutex_lock+0x7b/0x820 [ 191.454290] tcpm_altmode_enter+0x23/0x90 [tcpm] [ 191.454293] dp_altmode_work+0xca/0xe0 [typec_displayport] [ 191.454299] process_one_work+0x23f/0x570 [ 191.454302] worker_thread+0x55/0x3c0 [ 191.454305] kthread+0x138/0x160 [ 191.454309] ret_from_fork+0x22/0x30 [ 191.454311] -> #0 (&dp->lock){+.+.}-{3:3}: [ 191.454317] __lock_acquire+0x1241/0x2090 [ 191.454320] lock_acquire+0xa4/0x3d0 [ 191.454323] __mutex_lock+0x7b/0x820 [ 191.454326] dp_altmode_vdm+0x30/0xf0 [typec_displayport] [ 191.454330] tcpm_pd_rx_handler+0x11ae/0x12c0 [tcpm] [ 191.454333] process_one_work+0x23f/0x570 [ 191.454336] worker_thread+0x55/0x3c0 [ 191.454338] kthread+0x138/0x160 [ 191.454341] ret_from_fork+0x22/0x30 [ 191.454343] other info that might help us debug this: [ 191.454345] Possible unsafe locking scenario: [ 191.454347] CPU0 CPU1 [ 191.454348] ---- ---- [ 191.454350] lock(&port->lock#2); [ 191.454353] lock(&dp->lock); [ 191.454355] lock(&port->lock#2); [ 191.454357] lock(&dp->lock); [ 191.454360] *** DEADLOCK *** Reviewed-by: -
Hans de Goede authored
Refactor tcpm_handle_vdm_request and its tcpm_pd_svdm helper function so that reporting the results of the vdm to the altmode-driver is separated out into a clear separate step inside tcpm_handle_vdm_request, instead of being scattered over various places inside the tcpm_pd_svdm helper. This is a preparation patch for fixing an AB BA lock inversion between the tcpm code and some altmode drivers. Reviewed-by:
-
Hans de Goede authored
Refactor the tcpm_handle_vdm_request payload handling by doing the endianness conversion only once directly inside tcpm_handle_vdm_request itself instead of doing it multiple times inside various helper functions called by tcpm_handle_vdm_request. This is a preparation patch for some further refactoring to fix an AB BA lock inversion between the tcpm code and some altmode drivers. Reviewed-by:
-
Hans de Goede authored
Various callers (all the typec_altmode_ops) take the port-lock just for the tcpm_queue_vdm() call. Add a new tcpm_queue_vdm_unlocked() helper which takes the lock, so that its callers don't have to do this themselves. This is a preparation patch for fixing an AB BA lock inversion between the tcpm code and some altmode drivers. Reviewed-by:
-
Hans de Goede authored
All callers of tcpm_queue_vdm() immediately follow the tcpm_queue_vdm() vdm call with a: mod_delayed_work(port->wq, &port->vdm_state_machine, 0); Call, fold this into tcpm_queue_vdm() itself. Reviewed-by:
-
Greg Kroah-Hartman authored
Merge tag 'usb-ci-v5.9-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/peter.chen/usb into usb-next Peter writes: ENDIAN issue fix and one query controller role API is introduced. * tag 'usb-ci-v5.9-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/peter.chen/usb: usb: chipidea: imx: get available runtime dr mode for wakeup setting usb: chipidea: add query_available_role interface Documentation: ABI: usb: chipidea: Update Li Jun's e-mail usb: chipidea: udc: fix the ENDIAN issue
-
- 28 Jul, 2020 5 commits
-
-
Greg Kroah-Hartman authored
Merge tag 'usb-serial-5.9-rc1' of https://git.kernel.org/pub/scm/linux/kernel/git/johan/usb-serial into usb-next Johan writes: USB-serial updates for 5.9-rc1 Here are the USB-serial updates for 5.9-rc1, including: - console flow-control support - simulated line-breaks on some ch341 - hardware flow-control fixes for cp210x - break-detection and sysrq fixes for ftdi_sio - sysrq optimisations - input parity checking for cp210x Included are also some new device ids and various clean ups. All have been in linux-next with no reported issues. * tag 'usb-serial-5.9-rc1' of https://git.kernel.org/pub/scm/linux/kernel/git/johan/usb-serial: (31 commits) USB: serial: qcserial: add EM7305 QDL product ID USB: serial: iuu_phoenix: fix led-activity helpers USB: serial: sierra: clean up special-interface handling USB: serial: cp210x: use in-kernel types in port data USB: serial: cp210x: drop unnecessary packed attributes USB: serial: cp210x: add support for TIOCGICOUNT USB: serial: cp210x: add support for line-status events USB: serial: cp210x: disable interface on errors in open USB: serial: drop redundant transfer-buffer casts USB: serial: drop extern keyword from function declarations USB: serial: drop unnecessary sysrq include USB: serial: add sysrq break-handler dummy USB: serial: inline sysrq dummy function USB: serial: only process sysrq when enabled USB: serial: only set sysrq timestamp for consoles USB: serial: ftdi_sio: fix break and sysrq handling USB: serial: ftdi_sio: clean up receive processing USB: serial: ftdi_sio: make process-packet buffer unsigned USB: serial: use fallthrough pseudo-keyword USB: serial: ch341: fix missing simulated-break margin ...
-
Wei Yongjun authored
The sparse tool complains as follows: drivers/usb/host/xhci-dbgtty.c:401:5: warning: symbol 'xhci_dbc_tty_register_device' was not declared. Should it be static? drivers/usb/host/xhci-dbgtty.c:452:6: warning: symbol 'xhci_dbc_tty_unregister_device' was not declared. Should it be static? After commit 6ae6470b ("xhci: dbc: Add a operations structure to access driver functions"), those functions are not used outside of xhci-dbgtty.c, so this commit marks them static. Fixes: 6ae6470b ("xhci: dbc: Add a operations structure to access driver functions") Reported-by:
Hulk Robot <hulkci@huawei.com> Signed-off-by:
Wei Yongjun <weiyongjun1@huawei.com> Link: https://lore.kernel.org/r/20200727171149.3011-1-weiyongjun1@huawei.comSigned-off-by:
-
Wei Yongjun authored
The sparse tool complains as follows: drivers/usb/host/xhci-dbgcap.c:422:18: warning: symbol 'xhci_dbc_ring_alloc' was not declared. Should it be static? This function is not used outside ofxhci-dbgcap.c, so this commit marks it static. Fixes: ac286428 ("xhci: dbc: don't use generic xhci ring allocation functions for dbc.") Reported-by:
-
Peter Chen authored
If runtime dr_mode is not dual-role, it doesn't need to enable ID wakeup interrupt. If runtime dr_mode is host, it doesn't need to enable VBUS wakeup interrupt. With these changes, the user will not get the unexpected wakeup for single role use case. For example, the host-only use case at Micro-AB port, the controller should not be waken up by only plug in Micro-AB cable or the Micro-B cable with host. Signed-off-by: -
Peter Chen authored
The glue layer may need to know current available role to do some setting, eg, the wakeup setting. So we add ci_hdrc_query_available_role for that. Signed-off-by:
-
- 27 Jul, 2020 5 commits
-
-
Greg Kroah-Hartman authored
This reverts commit bc0f0d4a. It was not meant to be applied yet. Cc: Minas Harutyunyan <hminas@synopsys.com> Cc: Amelie Delaunay <amelie.delaunay@st.com> Cc: Felipe Balbi <balbi@kernel.org> Signed-off-by:
-
Greg Kroah-Hartman authored
This reverts commit 916f8b62. This was not meant to be applied as-is at the moment. Cc: Minas Harutyunyan <hminas@synopsys.com> Cc: Amelie Delaunay <amelie.delaunay@st.com> Cc: Felipe Balbi <balbi@kernel.org> Signed-off-by:
-
Greg Kroah-Hartman authored
In previous patches that added support for new iowarrior devices, the handling of the report size was not done correct. Fix that up and update the copyright date for the driver Reworked from an original patch written by Christoph Jung. Fixes: bab5417f ("USB: misc: iowarrior: add support for the 100 device") Fixes: 5f6f8da2 ("USB: misc: iowarrior: add support for the 28 and 28L devices") Fixes: 461d8deb ("USB: misc: iowarrior: add support for 2 OEMed devices") Cc: stable <stable@kernel.org> Reported-by:
Christoph Jung <jung@codemercs.com> Link: https://lore.kernel.org/r/20200726094939.1268978-1-gregkh@linuxfoundation.orgSigned-off-by:
-
git://git.kernel.org/pub/scm/linux/kernel/git/balbi/usbGreg Kroah-Hartman authored
Felipe writes: USB: changes for v5.9 merge window CDNS3 got several improvements, most of which are non-critical fixes. DWC3 has a reset fix for the meson platform, while dwc2 has improvements for role switch on STM32MP15 SoCs. Apart from these, we have the usual set of non-critical fixes all over the place and support for new Ingenic SoC to their PHY driver. * tag 'usb-for-v5.9' of git://git.kernel.org/pub/scm/linux/kernel/git/balbi/usb: (38 commits) usb: dwc3: gadget: when the started list is empty stop the active xfer usb: dwc3: gadget: make starting isoc transfers more robust usb: dwc3: gadget: add frame number mask usb: gadget: function: printer: Interface is disabled and returns error usb: gadget: f_uac2: fix AC Interface Header Descriptor wTotalLength dt-bindings: usb: ti,keystone-dwc3.yaml: Improve schema usb: bdc: Use devm_clk_get_optional() usb: bdc: Halt controller on suspend usb: bdc: driver runs out of buffer descriptors on large ADB transfers usb: bdc: Adb shows offline after resuming from S2 bdc: Fix bug causing crash after multiple disconnects usb: bdc: Add compatible string for new style USB DT nodes dt-bindings: usb: bdc: Update compatible strings USB: PHY: JZ4770: Reformat the code to align it. USB: PHY: JZ4770: Add support for new Ingenic SoCs. USB: PHY: JZ4770: Unify code style and simplify code. dt-bindings: USB: Add bindings for new Ingenic SoCs. usb: gadget: net2280: fix memory leak on probe error handling paths usb: cdns3: drd: simplify *switch_gadet and *switch_host usb: cdns3: core: removed overwriting some error code ...
-
Greg Kroah-Hartman authored
We want the USB fixes in here as well. Signed-off-by:
-
- 26 Jul, 2020 1 commit
-
-
Linus Torvalds authored
-
