aboutsummaryrefslogtreecommitdiff
path: root/drivers/usb
AgeCommit message (Collapse)AuthorFilesLines
2021-06-10usb: typec: ucsi: Clear PPM capability data in ucsi_init() error pathMayank Rana1-0/+1
If ucsi_init() fails for some reason (e.g. ucsi_register_port() fails or general communication failure to the PPM), particularly at any point after the GET_CAPABILITY command had been issued, this results in unwinding the initialization and returning an error. However the ucsi structure's ucsi_capability member retains its current value, including likely a non-zero num_connectors. And because ucsi_init() itself is done in a workqueue a UCSI interface driver will be unaware that it failed and may think the ucsi_register() call was completely successful. Later, if ucsi_unregister() is called, due to this stale ucsi->cap value it would try to access the items in the ucsi->connector array which might not be in a proper state or not even allocated at all and results in NULL or invalid pointer dereference. Fix this by clearing the ucsi->cap value to 0 during the error path of ucsi_init() in order to prevent a later ucsi_unregister() from entering the connector cleanup loop. Fixes: c1b0bc2dabfa ("usb: typec: Add support for UCSI interface") Cc: [email protected] Acked-by: Heikki Krogerus <[email protected]> Signed-off-by: Mayank Rana <[email protected]> Signed-off-by: Jack Pham <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]>
2021-06-10usb: gadget: fsl: Re-enable driver for ARM SoCsJoel Stanley1-1/+1
The commit a390bef7db1f ("usb: gadget: fsl_mxc_udc: Remove the driver") dropped the ARCH_MXC dependency from USB_FSL_USB2, leaving it depending solely on FSL_SOC. FSL_SOC is powerpc only; it was briefly available on ARM in 2014 but was removed by commit cfd074ad8600 ("ARM: imx: temporarily remove CONFIG_SOC_FSL from LS1021A"). Therefore the driver can no longer be enabled on ARM platforms. This appears to be a mistake as arm64's ARCH_LAYERSCAPE and arm32 SOC_LS1021A SoCs use this symbol. It's enabled in these defconfigs: arch/arm/configs/imx_v6_v7_defconfig:CONFIG_USB_FSL_USB2=y arch/arm/configs/multi_v7_defconfig:CONFIG_USB_FSL_USB2=y arch/powerpc/configs/mgcoge_defconfig:CONFIG_USB_FSL_USB2=y arch/powerpc/configs/mpc512x_defconfig:CONFIG_USB_FSL_USB2=y To fix, expand the dependencies so USB_FSL_USB2 can be enabled on the ARM platforms, and with COMPILE_TEST. Fixes: a390bef7db1f ("usb: gadget: fsl_mxc_udc: Remove the driver") Signed-off-by: Joel Stanley <[email protected]> Link: https://lore.kernel.org/r/[email protected] Cc: stable <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
2021-06-10usb: typec: wcove: Use LE to CPU conversion when accessing msg->headerAndy Shevchenko1-1/+1
As LKP noticed the Sparse is not happy about strict type handling: .../typec/tcpm/wcove.c:380:50: sparse: expected unsigned short [usertype] header .../typec/tcpm/wcove.c:380:50: sparse: got restricted __le16 const [usertype] header Fix this by switching to use pd_header_cnt_le() instead of pd_header_cnt() in the affected code. Fixes: ae8a2ca8a221 ("usb: typec: Group all TCPCI/TCPM code together") Fixes: 3c4fb9f16921 ("usb: typec: wcove: start using tcpm for USB PD support") Reported-by: kernel test robot <[email protected]> Reviewed-by: Heikki Krogerus <[email protected]> Reviewed-by: Guenter Roeck <[email protected]> Signed-off-by: Andy Shevchenko <[email protected]> Link: https://lore.kernel.org/r/[email protected] Cc: stable <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
2021-06-10usb: typec: ucsi: Fix a comment in ucsi_init()Subbaraman Narayanamurthy1-1/+1
ucsi_unregister_ppm() got replaced with ucsi_unregister(). Fix the comment in ucsi_init() as well. Reviewed-by: Heikki Krogerus <[email protected]> Signed-off-by: Subbaraman Narayanamurthy <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]>
2021-06-10USB: dwc3: remove debugfs root dentry storageGreg Kroah-Hartman3-7/+7
There is no need to keep around the debugfs "root" directory for the dwc3 device. Instead, look it up anytime we need to find it. This will help when callers get out-of-order and we had the potential to have a "stale" pointer around for the root dentry, as has happened in the past. Tested-by: Jack Pham <[email protected]> Reviewed-by: Peter Chen <[email protected]> Acked-by: Felipe Balbi <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]>
2021-06-10usb: ehci: do not initialise static variablesJason Wang1-2/+2
Global static variables dont need to be initialised manully. Signed-off-by: Jason Wang <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]>
2021-06-10USB: serial: cp210x: fix CP2102N-A01 modem controlJohan Hovold1-5/+59
CP2102N revision A01 (firmware version <= 1.0.4) has a buggy flow-control implementation that uses the ulXonLimit instead of ulFlowReplace field of the flow-control settings structure (erratum CP2102N_E104). A recent change that set the input software flow-control limits incidentally broke RTS control for these devices when CRTSCTS is not set as the new limits would always enable hardware flow control. Fix this by explicitly disabling flow control for the buggy firmware versions and only updating the input software flow-control limits when IXOFF is requested. This makes sure that the terminal settings matches the default zero ulXonLimit (ulFlowReplace) for these devices. Link: https://lore.kernel.org/r/[email protected] Reported-by: David Frey <[email protected]> Reported-by: Alex Villacís Lasso <[email protected]> Tested-by: Alex Villacís Lasso <[email protected]> Fixes: f61309d9c96a ("USB: serial: cp210x: set IXOFF thresholds") Cc: [email protected] # 5.12 Signed-off-by: Johan Hovold <[email protected]>
2021-06-10usb: cdns3: cdns3-gadget: Use list_move_tail instead of list_del/list_add_tailBaokun Li1-3/+1
Using list_move_tail() instead of list_del() + list_add_tail(). Reported-by: Hulk Robot <[email protected]> Signed-off-by: Baokun Li <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Peter Chen <[email protected]>
2021-06-10USB: serial: cp210x: fix alternate function for CP2102N QFN20Stefan Agner1-1/+19
The QFN20 part has a different GPIO/port function assignment. The configuration struct bit field ordered as TX/RX/RS485/WAKEUP/CLK which exactly matches GPIO0-3 for QFN24/28. However, QFN20 has a different GPIO to primary function assignment. Special case QFN20 to follow to properly detect which GPIOs are available. Signed-off-by: Stefan Agner <[email protected]> Link: https://lore.kernel.org/r/51830b2b24118eb0f77c5c9ac64ffb2f519dbb1d.1622218300.git.stefan@agner.ch Fixes: c8acfe0aadbe ("USB: serial: cp210x: implement GPIO support for CP2102N") Cc: [email protected] # 4.19 Signed-off-by: Johan Hovold <[email protected]>
2021-06-09usb: gadget: u_audio: add real feedback implementationRuslan Bilovol4-10/+134
This adds interface between userspace and feedback endpoint to report real feedback frequency to the Host. Current implementation adds new userspace interface ALSA mixer control "Capture Pitch 1000000" (similar to aloop driver's "PCM Rate Shift 100000" mixer control) Value in PPM is chosen to have correction value agnostic of the actual HW rate, which the application is not necessarily dealing with, while still retaining a good enough precision to allow smooth clock correction on the playback side, if necessary. Similar to sound/usb/endpoint.c, a slow down is allowed up to 25%. This has no impact on the required bandwidth. Speedup correction has an impact on the bandwidth reserved for the isochronous endpoint. The default allowed speedup is 500ppm. This seems to be more than enough but, if necessary, this is configurable through a module parameter. The reserved bandwidth is rounded up to the next packet size. Usage of this new control is easy to implement in existing userspace tools like alsaloop from alsa-utils. Signed-off-by: Ruslan Bilovol <[email protected]> Signed-off-by: Jerome Brunet <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]>
2021-06-09usb: gadget: f_uac2: add adaptive sync support for captureRuslan Bilovol2-9/+93
Current f_uac2 USB OUT (aka 'capture') synchronization implements 'ASYNC' scenario which means USB Gadget has it's own freerunning clock and can update Host about real clock frequency through feedback endpoint so Host can align number of samples sent to the USB gadget to prevent overruns/underruns In case if Gadget can has no it's internal clock and can consume audio samples at any rate (for example, on the Gadget side someone records audio directly to a file, or audio samples are played through an external DAC as soon as they arrive), UAC2 spec suggests 'ADAPTIVE' synchronization type. Change UAC2 driver to make it configurable through additional 'c_sync' configfs file. Default remains 'asynchronous' with possibility to switch it to 'adaptive' Signed-off-by: Ruslan Bilovol <[email protected]> Signed-off-by: Jerome Brunet <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]>
2021-06-09usb: gadget: f_uac2/u_audio: add feedback endpoint supportRuslan Bilovol3-3/+168
As per USB and UAC2 specs, asynchronous audio sink endpoint requires explicit synchronization mechanism (Isochronous Feedback Endpoint) Implement feedback companion endpoint for ISO OUT endpoint This patch adds all required infrastructure and USB requests handling for feedback endpoint. Syncrhonization itself is still dummy (feedback ep always reports 'nomimal frequency' e.g. no adjustement is needed). This satisfies hosts that require feedback endpoint (like Win10) and poll it periodically Actual synchronization mechanism should be implemented separately Signed-off-by: Ruslan Bilovol <[email protected]> Signed-off-by: Jerome Brunet <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]>
2021-06-09usb: dwc2: Don't reset the core after setting turnaround timeClément Lassieur1-9/+21
Every time the hub signals a reset while we (device) are hsotg->connected, dwc2_hsotg_core_init_disconnected() is called, which in turn calls dwc2_hs_phy_init(). GUSBCFG.USBTrdTim is cleared upon Core Soft Reset, so if hsotg->params.phy_utmi_width is 8-bit, the value of GUSBCFG.USBTrdTim (the default one: 0x5, corresponding to 16-bit) is always different from hsotg->params.phy_utmi_width, thus dwc2_core_reset() is called every time (usbcfg != usbcfg_old), which causes 2 issues: 1) The call to dwc2_core_reset() does another reset 300us after the initial Chirp K of the first reset (which should last at least Tuch = 1ms), and messes up the High-speed Detection Handshake: both hub and device drive current into the D+ and D- lines at the same time. 2) GUSBCFG.USBTrdTim is cleared by the second reset, so its value is always the default one (0x5). Setting GUSBCFG.USBTrdTim after the potential call to dwc2_core_reset() fixes both issues. It is now set even when select_phy is false because the cost of the Core Soft Reset is removed. Fixes: 1e868545f2bb ("usb: dwc2: gadget: Move gadget phy init into core phy init") Signed-off-by: Clément Lassieur <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]>
2021-06-09usb: gadget: f_fs: Fix setting of device and driver data cross-referencesAndrew Gabbasov1-33/+32
FunctionFS device structure 'struct ffs_dev' and driver data structure 'struct ffs_data' are bound to each other with cross-reference pointers 'ffs_data->private_data' and 'ffs_dev->ffs_data'. While the first one is supposed to be valid through the whole life of 'struct ffs_data' (and while 'struct ffs_dev' exists non-freed), the second one is cleared in 'ffs_closed()' (called from 'ffs_data_reset()' or the last 'ffs_data_put()'). This can be called several times, alternating in different order with 'ffs_free_inst()', that, if possible, clears the other cross-reference. As a result, different cases of these calls order may leave stale cross-reference pointers, used when the pointed structure is already freed. Even if it occasionally doesn't cause kernel crash, this error is reported by KASAN-enabled kernel configuration. For example, the case [last 'ffs_data_put()' - 'ffs_free_inst()'] was fixed by commit cdafb6d8b8da ("usb: gadget: f_fs: Fix use-after-free in ffs_free_inst"). The other case ['ffs_data_reset()' - 'ffs_free_inst()' - 'ffs_data_put()'] now causes KASAN reported error [1], when 'ffs_data_reset()' clears 'ffs_dev->ffs_data', then 'ffs_free_inst()' frees the 'struct ffs_dev', but can't clear 'ffs_data->private_data', which is then accessed in 'ffs_closed()' called from 'ffs_data_put()'. This happens since 'ffs_dev->ffs_data' reference is cleared too early. Moreover, one more use case, when 'ffs_free_inst()' is called immediately after mounting FunctionFS device (that is before the descriptors are written and 'ffs_ready()' is called), and then 'ffs_data_reset()' or 'ffs_data_put()' is called from accessing "ep0" file or unmounting the device. This causes KASAN error report like [2], since 'ffs_dev->ffs_data' is not yet set when 'ffs_free_inst()' can't properly clear 'ffs_data->private_data', that is later accessed to freed structure. Fix these (and may be other) cases of stale pointers access by moving setting and clearing of the mentioned cross-references to the single places, setting both of them when 'struct ffs_data' is created and bound to 'struct ffs_dev', and clearing both of them when one of the structures is destroyed. It seems convenient to make this pointer initialization and structures binding in 'ffs_acquire_dev()' and make pointers clearing in 'ffs_release_dev()'. This required some changes in these functions parameters and return types. Also, 'ffs_release_dev()' calling requires some cleanup, fixing minor issues, like (1) 'ffs_release_dev()' is not called if 'ffs_free_inst()' is called without unmounting the device, and "release_dev" callback is not called at all, or (2) "release_dev" callback is called before "ffs_closed" callback on unmounting, which seems to be not correctly nested with "acquire_dev" and "ffs_ready" callbacks. Make this cleanup togther with other mentioned 'ffs_release_dev()' changes. [1] ================================================================== root@rcar-gen3:~# mkdir /dev/cfs root@rcar-gen3:~# mkdir /dev/ffs root@rcar-gen3:~# modprobe libcomposite root@rcar-gen3:~# mount -t configfs none /dev/cfs root@rcar-gen3:~# mkdir /dev/cfs/usb_gadget/g1 root@rcar-gen3:~# mkdir /dev/cfs/usb_gadget/g1/functions/ffs.ffs [ 64.340664] file system registered root@rcar-gen3:~# mount -t functionfs ffs /dev/ffs root@rcar-gen3:~# cd /dev/ffs root@rcar-gen3:/dev/ffs# /home/root/ffs-test ffs-test: info: ep0: writing descriptors (in v2 format) [ 83.181442] read descriptors [ 83.186085] read strings ffs-test: info: ep0: writing strings ffs-test: dbg: ep1: starting ffs-test: dbg: ep2: starting ffs-test: info: ep1: starts ffs-test: info: ep2: starts ffs-test: info: ep0: starts ^C root@rcar-gen3:/dev/ffs# cd /home/root/ root@rcar-gen3:~# rmdir /dev/cfs/usb_gadget/g1/functions/ffs.ffs [ 98.935061] unloading root@rcar-gen3:~# umount /dev/ffs [ 102.734301] ================================================================== [ 102.742059] BUG: KASAN: use-after-free in ffs_release_dev+0x64/0xa8 [usb_f_fs] [ 102.749683] Write of size 1 at addr ffff0004d46ff549 by task umount/2997 [ 102.756709] [ 102.758311] CPU: 0 PID: 2997 Comm: umount Not tainted 5.13.0-rc4+ #8 [ 102.764971] Hardware name: Renesas Salvator-X board based on r8a77951 (DT) [ 102.772179] Call trace: [ 102.774779] dump_backtrace+0x0/0x330 [ 102.778653] show_stack+0x20/0x2c [ 102.782152] dump_stack+0x11c/0x1ac [ 102.785833] print_address_description.constprop.0+0x30/0x274 [ 102.791862] kasan_report+0x14c/0x1c8 [ 102.795719] __asan_report_store1_noabort+0x34/0x58 [ 102.800840] ffs_release_dev+0x64/0xa8 [usb_f_fs] [ 102.805801] ffs_fs_kill_sb+0x50/0x84 [usb_f_fs] [ 102.810663] deactivate_locked_super+0xa0/0xf0 [ 102.815339] deactivate_super+0x98/0xac [ 102.819378] cleanup_mnt+0xd0/0x1b0 [ 102.823057] __cleanup_mnt+0x1c/0x28 [ 102.826823] task_work_run+0x104/0x180 [ 102.830774] do_notify_resume+0x458/0x14e0 [ 102.835083] work_pending+0xc/0x5f8 [ 102.838762] [ 102.840357] Allocated by task 2988: [ 102.844032] kasan_save_stack+0x28/0x58 [ 102.848071] kasan_set_track+0x28/0x3c [ 102.852016] ____kasan_kmalloc+0x84/0x9c [ 102.856142] __kasan_kmalloc+0x10/0x1c [ 102.860088] __kmalloc+0x214/0x2f8 [ 102.863678] kzalloc.constprop.0+0x14/0x20 [usb_f_fs] [ 102.868990] ffs_alloc_inst+0x8c/0x208 [usb_f_fs] [ 102.873942] try_get_usb_function_instance+0xf0/0x164 [libcomposite] [ 102.880629] usb_get_function_instance+0x64/0x68 [libcomposite] [ 102.886858] function_make+0x128/0x1ec [libcomposite] [ 102.892185] configfs_mkdir+0x330/0x590 [configfs] [ 102.897245] vfs_mkdir+0x12c/0x1bc [ 102.900835] do_mkdirat+0x180/0x1d0 [ 102.904513] __arm64_sys_mkdirat+0x80/0x94 [ 102.908822] invoke_syscall+0xf8/0x25c [ 102.912772] el0_svc_common.constprop.0+0x150/0x1a0 [ 102.917891] do_el0_svc+0xa0/0xd4 [ 102.921386] el0_svc+0x24/0x34 [ 102.924613] el0_sync_handler+0xcc/0x154 [ 102.928743] el0_sync+0x198/0x1c0 [ 102.932238] [ 102.933832] Freed by task 2996: [ 102.937144] kasan_save_stack+0x28/0x58 [ 102.941181] kasan_set_track+0x28/0x3c [ 102.945128] kasan_set_free_info+0x28/0x4c [ 102.949435] ____kasan_slab_free+0x104/0x118 [ 102.953921] __kasan_slab_free+0x18/0x24 [ 102.958047] slab_free_freelist_hook+0x148/0x1f0 [ 102.962897] kfree+0x318/0x440 [ 102.966123] ffs_free_inst+0x164/0x2d8 [usb_f_fs] [ 102.971075] usb_put_function_instance+0x84/0xa4 [libcomposite] [ 102.977302] ffs_attr_release+0x18/0x24 [usb_f_fs] [ 102.982344] config_item_put+0x140/0x1a4 [configfs] [ 102.987486] configfs_rmdir+0x3fc/0x518 [configfs] [ 102.992535] vfs_rmdir+0x114/0x234 [ 102.996122] do_rmdir+0x274/0x2b0 [ 102.999617] __arm64_sys_unlinkat+0x94/0xc8 [ 103.004015] invoke_syscall+0xf8/0x25c [ 103.007961] el0_svc_common.constprop.0+0x150/0x1a0 [ 103.013080] do_el0_svc+0xa0/0xd4 [ 103.016575] el0_svc+0x24/0x34 [ 103.019801] el0_sync_handler+0xcc/0x154 [ 103.023930] el0_sync+0x198/0x1c0 [ 103.027426] [ 103.029020] The buggy address belongs to the object at ffff0004d46ff500 [ 103.029020] which belongs to the cache kmalloc-128 of size 128 [ 103.042079] The buggy address is located 73 bytes inside of [ 103.042079] 128-byte region [ffff0004d46ff500, ffff0004d46ff580) [ 103.054236] The buggy address belongs to the page: [ 103.059262] page:0000000021aa849b refcount:1 mapcount:0 mapping:0000000000000000 index:0xffff0004d46fee00 pfn:0x5146fe [ 103.070437] head:0000000021aa849b order:1 compound_mapcount:0 [ 103.076456] flags: 0x8000000000010200(slab|head|zone=2) [ 103.081948] raw: 8000000000010200 fffffc0013521a80 0000000d0000000d ffff0004c0002300 [ 103.090052] raw: ffff0004d46fee00 000000008020001e 00000001ffffffff 0000000000000000 [ 103.098150] page dumped because: kasan: bad access detected [ 103.103985] [ 103.105578] Memory state around the buggy address: [ 103.110602] ffff0004d46ff400: fa fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb [ 103.118161] ffff0004d46ff480: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc [ 103.125726] >ffff0004d46ff500: fa fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb [ 103.133284] ^ [ 103.139120] ffff0004d46ff580: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc [ 103.146679] ffff0004d46ff600: fa fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb [ 103.154238] ================================================================== [ 103.161792] Disabling lock debugging due to kernel taint [ 103.167319] Unable to handle kernel paging request at virtual address 0037801d6000018e [ 103.175406] Mem abort info: [ 103.178457] ESR = 0x96000004 [ 103.181609] EC = 0x25: DABT (current EL), IL = 32 bits [ 103.187020] SET = 0, FnV = 0 [ 103.190185] EA = 0, S1PTW = 0 [ 103.193417] Data abort info: [ 103.196385] ISV = 0, ISS = 0x00000004 [ 103.200315] CM = 0, WnR = 0 [ 103.203366] [0037801d6000018e] address between user and kernel address ranges [ 103.210611] Internal error: Oops: 96000004 [#1] PREEMPT SMP [ 103.216231] Modules linked in: usb_f_fs libcomposite configfs ath9k_htc led_class mac80211 libarc4 ath9k_common ath9k_hw ath cfg80211 aes_ce_blk sata_rc4 [ 103.259233] CPU: 0 PID: 2997 Comm: umount Tainted: G B 5.13.0-rc4+ #8 [ 103.267031] Hardware name: Renesas Salvator-X board based on r8a77951 (DT) [ 103.273951] pstate: 00000005 (nzcv daif -PAN -UAO -TCO BTYPE=--) [ 103.280001] pc : ffs_data_clear+0x138/0x370 [usb_f_fs] [ 103.285197] lr : ffs_data_clear+0x124/0x370 [usb_f_fs] [ 103.290385] sp : ffff800014777a80 [ 103.293725] x29: ffff800014777a80 x28: ffff0004d7649c80 x27: 0000000000000000 [ 103.300931] x26: ffff800014777fb0 x25: ffff60009aec9394 x24: ffff0004d7649ca4 [ 103.308136] x23: 1fffe0009a3d063a x22: dfff800000000000 x21: ffff0004d1e831d0 [ 103.315340] x20: e1c000eb00000bb4 x19: ffff0004d1e83000 x18: 0000000000000000 [ 103.322545] x17: 0000000000000000 x16: 0000000000000000 x15: 0000000000000000 [ 103.329748] x14: 0720072007200720 x13: 0720072007200720 x12: 1ffff000012ef658 [ 103.336952] x11: ffff7000012ef658 x10: 0720072007200720 x9 : ffff800011322648 [ 103.344157] x8 : ffff800014777818 x7 : ffff80000977b2c7 x6 : 0000000000000000 [ 103.351359] x5 : 0000000000000001 x4 : ffff7000012ef659 x3 : 0000000000000001 [ 103.358562] x2 : 0000000000000000 x1 : 1c38001d6000018e x0 : e1c000eb00000c70 [ 103.365766] Call trace: [ 103.368235] ffs_data_clear+0x138/0x370 [usb_f_fs] [ 103.373076] ffs_data_reset+0x20/0x304 [usb_f_fs] [ 103.377829] ffs_data_closed+0x1ec/0x244 [usb_f_fs] [ 103.382755] ffs_fs_kill_sb+0x70/0x84 [usb_f_fs] [ 103.387420] deactivate_locked_super+0xa0/0xf0 [ 103.391905] deactivate_super+0x98/0xac [ 103.395776] cleanup_mnt+0xd0/0x1b0 [ 103.399299] __cleanup_mnt+0x1c/0x28 [ 103.402906] task_work_run+0x104/0x180 [ 103.406691] do_notify_resume+0x458/0x14e0 [ 103.410823] work_pending+0xc/0x5f8 [ 103.414351] Code: b4000a54 9102f280 12000802 d343fc01 (38f66821) [ 103.420490] ---[ end trace 57b43a50e8244f57 ]--- Segmentation fault root@rcar-gen3:~# ================================================================== [2] ================================================================== root@rcar-gen3:~# mkdir /dev/ffs root@rcar-gen3:~# modprobe libcomposite root@rcar-gen3:~# root@rcar-gen3:~# mount -t configfs none /dev/cfs root@rcar-gen3:~# mkdir /dev/cfs/usb_gadget/g1 root@rcar-gen3:~# mkdir /dev/cfs/usb_gadget/g1/functions/ffs.ffs [ 54.766480] file system registered root@rcar-gen3:~# mount -t functionfs ffs /dev/ffs root@rcar-gen3:~# rmdir /dev/cfs/usb_gadget/g1/functions/ffs.ffs [ 63.197597] unloading root@rcar-gen3:~# cat /dev/ffs/ep0 cat: read error:[ 67.213506] ================================================================== [ 67.222095] BUG: KASAN: use-after-free in ffs_data_clear+0x70/0x370 [usb_f_fs] [ 67.229699] Write of size 1 at addr ffff0004c26e974a by task cat/2994 [ 67.236446] [ 67.238045] CPU: 0 PID: 2994 Comm: cat Not tainted 5.13.0-rc4+ #8 [ 67.244431] Hardware name: Renesas Salvator-X board based on r8a77951 (DT) [ 67.251624] Call trace: [ 67.254212] dump_backtrace+0x0/0x330 [ 67.258081] show_stack+0x20/0x2c [ 67.261579] dump_stack+0x11c/0x1ac [ 67.265260] print_address_description.constprop.0+0x30/0x274 [ 67.271286] kasan_report+0x14c/0x1c8 [ 67.275143] __asan_report_store1_noabort+0x34/0x58 [ 67.280265] ffs_data_clear+0x70/0x370 [usb_f_fs] [ 67.285220] ffs_data_reset+0x20/0x304 [usb_f_fs] [ 67.290172] ffs_data_closed+0x240/0x244 [usb_f_fs] [ 67.295305] ffs_ep0_release+0x40/0x54 [usb_f_fs] [ 67.300256] __fput+0x304/0x580 [ 67.303576] ____fput+0x18/0x24 [ 67.306893] task_work_run+0x104/0x180 [ 67.310846] do_notify_resume+0x458/0x14e0 [ 67.315154] work_pending+0xc/0x5f8 [ 67.318834] [ 67.320429] Allocated by task 2988: [ 67.324105] kasan_save_stack+0x28/0x58 [ 67.328144] kasan_set_track+0x28/0x3c [ 67.332090] ____kasan_kmalloc+0x84/0x9c [ 67.336217] __kasan_kmalloc+0x10/0x1c [ 67.340163] __kmalloc+0x214/0x2f8 [ 67.343754] kzalloc.constprop.0+0x14/0x20 [usb_f_fs] [ 67.349066] ffs_alloc_inst+0x8c/0x208 [usb_f_fs] [ 67.354017] try_get_usb_function_instance+0xf0/0x164 [libcomposite] [ 67.360705] usb_get_function_instance+0x64/0x68 [libcomposite] [ 67.366934] function_make+0x128/0x1ec [libcomposite] [ 67.372260] configfs_mkdir+0x330/0x590 [configfs] [ 67.377320] vfs_mkdir+0x12c/0x1bc [ 67.380911] do_mkdirat+0x180/0x1d0 [ 67.384589] __arm64_sys_mkdirat+0x80/0x94 [ 67.388899] invoke_syscall+0xf8/0x25c [ 67.392850] el0_svc_common.constprop.0+0x150/0x1a0 [ 67.397969] do_el0_svc+0xa0/0xd4 [ 67.401464] el0_svc+0x24/0x34 [ 67.404691] el0_sync_handler+0xcc/0x154 [ 67.408819] el0_sync+0x198/0x1c0 [ 67.412315] [ 67.413909] Freed by task 2993: [ 67.417220] kasan_save_stack+0x28/0x58 [ 67.421257] kasan_set_track+0x28/0x3c [ 67.425204] kasan_set_free_info+0x28/0x4c [ 67.429513] ____kasan_slab_free+0x104/0x118 [ 67.434001] __kasan_slab_free+0x18/0x24 [ 67.438128] slab_free_freelist_hook+0x148/0x1f0 [ 67.442978] kfree+0x318/0x440 [ 67.446205] ffs_free_inst+0x164/0x2d8 [usb_f_fs] [ 67.451156] usb_put_function_instance+0x84/0xa4 [libcomposite] [ 67.457385] ffs_attr_release+0x18/0x24 [usb_f_fs] [ 67.462428] config_item_put+0x140/0x1a4 [configfs] [ 67.467570] configfs_rmdir+0x3fc/0x518 [configfs] [ 67.472626] vfs_rmdir+0x114/0x234 [ 67.476215] do_rmdir+0x274/0x2b0 [ 67.479710] __arm64_sys_unlinkat+0x94/0xc8 [ 67.484108] invoke_syscall+0xf8/0x25c [ 67.488055] el0_svc_common.constprop.0+0x150/0x1a0 [ 67.493175] do_el0_svc+0xa0/0xd4 [ 67.496671] el0_svc+0x24/0x34 [ 67.499896] el0_sync_handler+0xcc/0x154 [ 67.504024] el0_sync+0x198/0x1c0 [ 67.507520] [ 67.509114] The buggy address belongs to the object at ffff0004c26e9700 [ 67.509114] which belongs to the cache kmalloc-128 of size 128 [ 67.522171] The buggy address is located 74 bytes inside of [ 67.522171] 128-byte region [ffff0004c26e9700, ffff0004c26e9780) [ 67.534328] The buggy address belongs to the page: [ 67.539355] page:000000003177a217 refcount:1 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0x5026e8 [ 67.549175] head:000000003177a217 order:1 compound_mapcount:0 [ 67.555195] flags: 0x8000000000010200(slab|head|zone=2) [ 67.560687] raw: 8000000000010200 fffffc0013037100 0000000c00000002 ffff0004c0002300 [ 67.568791] raw: 0000000000000000 0000000080200020 00000001ffffffff 0000000000000000 [ 67.576890] page dumped because: kasan: bad access detected [ 67.582725] [ 67.584318] Memory state around the buggy address: [ 67.589343] ffff0004c26e9600: fa fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb [ 67.596903] ffff0004c26e9680: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc [ 67.604463] >ffff0004c26e9700: fa fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb [ 67.612022] ^ [ 67.617860] ffff0004c26e9780: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc [ 67.625421] ffff0004c26e9800: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [ 67.632981] ================================================================== [ 67.640535] Disabling lock debugging due to kernel taint File descriptor[ 67.646100] Unable to handle kernel paging request at virtual address fabb801d4000018d in bad state [ 67.655456] Mem abort info: [ 67.659619] ESR = 0x96000004 [ 67.662801] EC = 0x25: DABT (current EL), IL = 32 bits [ 67.668225] SET = 0, FnV = 0 [ 67.671375] EA = 0, S1PTW = 0 [ 67.674613] Data abort info: [ 67.677587] ISV = 0, ISS = 0x00000004 [ 67.681522] CM = 0, WnR = 0 [ 67.684588] [fabb801d4000018d] address between user and kernel address ranges [ 67.691849] Internal error: Oops: 96000004 [#1] PREEMPT SMP [ 67.697470] Modules linked in: usb_f_fs libcomposite configfs ath9k_htc led_class mac80211 libarc4 ath9k_common ath9k_hw ath cfg80211 aes_ce_blk crypto_simd cryptd aes_ce_cipher ghash_ce gf128mul sha2_ce sha1_ce evdev sata_rcar libata xhci_plat_hcd scsi_mod xhci_hcd rene4 [ 67.740467] CPU: 0 PID: 2994 Comm: cat Tainted: G B 5.13.0-rc4+ #8 [ 67.748005] Hardware name: Renesas Salvator-X board based on r8a77951 (DT) [ 67.754924] pstate: 00000005 (nzcv daif -PAN -UAO -TCO BTYPE=--) [ 67.760974] pc : ffs_data_clear+0x138/0x370 [usb_f_fs] [ 67.766178] lr : ffs_data_clear+0x124/0x370 [usb_f_fs] [ 67.771365] sp : ffff800014767ad0 [ 67.774706] x29: ffff800014767ad0 x28: ffff800009cf91c0 x27: ffff0004c54861a0 [ 67.781913] x26: ffff0004dc90b288 x25: 1fffe00099ec10f5 x24: 00000000000a801d [ 67.789118] x23: 1fffe00099f6953a x22: dfff800000000000 x21: ffff0004cfb4a9d0 [ 67.796322] x20: d5e000ea00000bb1 x19: ffff0004cfb4a800 x18: 0000000000000000 [ 67.803526] x17: 0000000000000000 x16: 0000000000000000 x15: 0000000000000000 [ 67.810730] x14: 0720072007200720 x13: 0720072007200720 x12: 1ffff000028ecefa [ 67.817934] x11: ffff7000028ecefa x10: 0720072007200720 x9 : ffff80001132c014 [ 67.825137] x8 : ffff8000147677d8 x7 : ffff8000147677d7 x6 : 0000000000000000 [ 67.832341] x5 : 0000000000000001 x4 : ffff7000028ecefb x3 : 0000000000000001 [ 67.839544] x2 : 0000000000000005 x1 : 1abc001d4000018d x0 : d5e000ea00000c6d [ 67.846748] Call trace: [ 67.849218] ffs_data_clear+0x138/0x370 [usb_f_fs] [ 67.854058] ffs_data_reset+0x20/0x304 [usb_f_fs] [ 67.858810] ffs_data_closed+0x240/0x244 [usb_f_fs] [ 67.863736] ffs_ep0_release+0x40/0x54 [usb_f_fs] [ 67.868488] __fput+0x304/0x580 [ 67.871665] ____fput+0x18/0x24 [ 67.874837] task_work_run+0x104/0x180 [ 67.878622] do_notify_resume+0x458/0x14e0 [ 67.882754] work_pending+0xc/0x5f8 [ 67.886282] Code: b4000a54 9102f280 12000802 d343fc01 (38f66821) [ 67.892422] ---[ end trace 6d7cedf53d7abbea ]--- Segmentation fault root@rcar-gen3:~# ================================================================== Fixes: 4b187fceec3c ("usb: gadget: FunctionFS: add devices management code") Fixes: 3262ad824307 ("usb: gadget: f_fs: Stop ffs_closed NULL pointer dereference") Fixes: cdafb6d8b8da ("usb: gadget: f_fs: Fix use-after-free in ffs_free_inst") Reported-by: Bhuvanesh Surachari <[email protected]> Tested-by: Eugeniu Rosca <[email protected]> Reviewed-by: Eugeniu Rosca <[email protected]> Signed-off-by: Andrew Gabbasov <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]>
2021-06-09usb: dwc3: support 64 bit DMA in platform driverSven Peter1-0/+4
Currently, the dwc3 platform driver does not explicitly ask for a DMA mask. This makes it fall back to the default 32-bit mask which breaks the driver on systems that only have RAM starting above the first 4G like the Apple M1 SoC. Fix this by calling dma_set_mask_and_coherent with a 64bit mask. Reviewed-by: Arnd Bergmann <[email protected]> Reviewed-by: Christoph Hellwig <[email protected]> Signed-off-by: Sven Peter <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]>
2021-06-09USB: core: Avoid WARNings for 0-length descriptor requestsAlan Stern1-0/+6
The USB core has utility routines to retrieve various types of descriptors. These routines will now provoke a WARN if they are asked to retrieve 0 bytes (USB "receive" requests must not have zero length), so avert this by checking the size argument at the start. CC: Johan Hovold <[email protected]> Reported-and-tested-by: [email protected] Reviewed-by: Johan Hovold <[email protected]> Signed-off-by: Alan Stern <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]>
2021-06-09usb: gadget: function: printer: use list_move instead of list_del/list_addBaokun Li1-2/+1
Using list_move() instead of list_del() + list_add(). Reported-by: Hulk Robot <[email protected]> Signed-off-by: Baokun Li <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]>
2021-06-09usb: dwc3: core: fix kernel panic when do rebootPeter Chen1-1/+1
When do system reboot, it calls dwc3_shutdown and the whole debugfs for dwc3 has removed first, when the gadget tries to do deinit, and remove debugfs for its endpoints, it meets NULL pointer dereference issue when call debugfs_lookup. Fix it by removing the whole dwc3 debugfs later than dwc3_drd_exit. [ 2924.958838] Unable to handle kernel NULL pointer dereference at virtual address 0000000000000002 .... [ 2925.030994] pstate: 60000005 (nZCv daif -PAN -UAO -TCO BTYPE=--) [ 2925.037005] pc : inode_permission+0x2c/0x198 [ 2925.041281] lr : lookup_one_len_common+0xb0/0xf8 [ 2925.045903] sp : ffff80001276ba70 [ 2925.049218] x29: ffff80001276ba70 x28: ffff0000c01f0000 x27: 0000000000000000 [ 2925.056364] x26: ffff800011791e70 x25: 0000000000000008 x24: dead000000000100 [ 2925.063510] x23: dead000000000122 x22: 0000000000000000 x21: 0000000000000001 [ 2925.070652] x20: ffff8000122c6188 x19: 0000000000000000 x18: 0000000000000000 [ 2925.077797] x17: 0000000000000000 x16: 0000000000000000 x15: 0000000000000004 [ 2925.084943] x14: ffffffffffffffff x13: 0000000000000000 x12: 0000000000000030 [ 2925.092087] x11: 0101010101010101 x10: 7f7f7f7f7f7f7f7f x9 : ffff8000102b2420 [ 2925.099232] x8 : 7f7f7f7f7f7f7f7f x7 : feff73746e2f6f64 x6 : 0000000000008080 [ 2925.106378] x5 : 61c8864680b583eb x4 : 209e6ec2d263dbb7 x3 : 000074756f307065 [ 2925.113523] x2 : 0000000000000001 x1 : 0000000000000000 x0 : ffff8000122c6188 [ 2925.120671] Call trace: [ 2925.123119] inode_permission+0x2c/0x198 [ 2925.127042] lookup_one_len_common+0xb0/0xf8 [ 2925.131315] lookup_one_len_unlocked+0x34/0xb0 [ 2925.135764] lookup_positive_unlocked+0x14/0x50 [ 2925.140296] debugfs_lookup+0x68/0xa0 [ 2925.143964] dwc3_gadget_free_endpoints+0x84/0xb0 [ 2925.148675] dwc3_gadget_exit+0x28/0x78 [ 2925.152518] dwc3_drd_exit+0x100/0x1f8 [ 2925.156267] dwc3_remove+0x11c/0x120 [ 2925.159851] dwc3_shutdown+0x14/0x20 [ 2925.163432] platform_shutdown+0x28/0x38 [ 2925.167360] device_shutdown+0x15c/0x378 [ 2925.171291] kernel_restart_prepare+0x3c/0x48 [ 2925.175650] kernel_restart+0x1c/0x68 [ 2925.179316] __do_sys_reboot+0x218/0x240 [ 2925.183247] __arm64_sys_reboot+0x28/0x30 [ 2925.187262] invoke_syscall+0x48/0x100 [ 2925.191017] el0_svc_common.constprop.0+0x48/0xc8 [ 2925.195726] do_el0_svc+0x28/0x88 [ 2925.199045] el0_svc+0x20/0x30 [ 2925.202104] el0_sync_handler+0xa8/0xb0 [ 2925.205942] el0_sync+0x148/0x180 [ 2925.209270] Code: a9025bf5 2a0203f5 121f0056 370802b5 (79400660) [ 2925.215372] ---[ end trace 124254d8e485a58b ]--- [ 2925.220012] Kernel panic - not syncing: Attempted to kill init! exitcode=0x0000000b [ 2925.227676] Kernel Offset: disabled [ 2925.231164] CPU features: 0x00001001,20000846 [ 2925.235521] Memory Limit: none [ 2925.238580] ---[ end Kernel panic - not syncing: Attempted to kill init! exitcode=0x0000000b ]--- Fixes: 5ff90af9da8f ("usb: dwc3: debugfs: Add and remove endpoint dirs dynamically") Cc: Jack Pham <[email protected]> Tested-by: Jack Pham <[email protected]> Signed-off-by: Peter Chen <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]>
2021-06-09usb: misc: brcmstb-usb-pinmap: check return value after calling ↵Yang Yingliang1-0/+2
platform_get_resource() It will cause null-ptr-deref if platform_get_resource() returns NULL, we need check the return value. Fixes: 517c4c44b323 ("usb: Add driver to allow any GPIO to be used for 7211 USB signals") Cc: stable <[email protected]> Signed-off-by: Yang Yingliang <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]>
2021-06-09usb: dwc3: ep0: fix NULL pointer exceptionMarian-Cristian Rotariu1-0/+3
There is no validation of the index from dwc3_wIndex_to_dep() and we might be referring a non-existing ep and trigger a NULL pointer exception. In certain configurations we might use fewer eps and the index might wrongly indicate a larger ep index than existing. By adding this validation from the patch we can actually report a wrong index back to the caller. In our usecase we are using a composite device on an older kernel, but upstream might use this fix also. Unfortunately, I cannot describe the hardware for others to reproduce the issue as it is a proprietary implementation. [ 82.958261] Unable to handle kernel NULL pointer dereference at virtual address 00000000000000a4 [ 82.966891] Mem abort info: [ 82.969663] ESR = 0x96000006 [ 82.972703] Exception class = DABT (current EL), IL = 32 bits [ 82.978603] SET = 0, FnV = 0 [ 82.981642] EA = 0, S1PTW = 0 [ 82.984765] Data abort info: [ 82.987631] ISV = 0, ISS = 0x00000006 [ 82.991449] CM = 0, WnR = 0 [ 82.994409] user pgtable: 4k pages, 39-bit VAs, pgdp = 00000000c6210ccc [ 83.000999] [00000000000000a4] pgd=0000000053aa5003, pud=0000000053aa5003, pmd=0000000000000000 [ 83.009685] Internal error: Oops: 96000006 [#1] PREEMPT SMP [ 83.026433] Process irq/62-dwc3 (pid: 303, stack limit = 0x000000003985154c) [ 83.033470] CPU: 0 PID: 303 Comm: irq/62-dwc3 Not tainted 4.19.124 #1 [ 83.044836] pstate: 60000085 (nZCv daIf -PAN -UAO) [ 83.049628] pc : dwc3_ep0_handle_feature+0x414/0x43c [ 83.054558] lr : dwc3_ep0_interrupt+0x3b4/0xc94 ... [ 83.141788] Call trace: [ 83.144227] dwc3_ep0_handle_feature+0x414/0x43c [ 83.148823] dwc3_ep0_interrupt+0x3b4/0xc94 [ 83.181546] ---[ end trace aac6b5267d84c32f ]--- Signed-off-by: Marian-Cristian Rotariu <[email protected]> Cc: stable <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]>
2021-06-09usb: gadget: eem: fix wrong eem header operationLinyu Yuan1-2/+2
when skb_clone() or skb_copy_expand() fail, it should pull skb with lengh indicated by header, or not it will read network data and check it as header. Cc: <[email protected]> Signed-off-by: Linyu Yuan <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]>
2021-06-09usb: typec: intel_pmc_mux: Put ACPI device using acpi_dev_put()Andy Shevchenko1-4/+4
For ACPI devices we have a symmetric API to put them, so use it in the driver. Reviewed-by: Heikki Krogerus <[email protected]> Signed-off-by: Andy Shevchenko <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]>
2021-06-09usb: typec: intel_pmc_mux: Add missed error check for devm_ioremap_resource()Andy Shevchenko1-0/+5
devm_ioremap_resource() can return an error, add missed check for it. Fixes: 43d596e32276 ("usb: typec: intel_pmc_mux: Check the port status before connect") Reviewed-by: Heikki Krogerus <[email protected]> Signed-off-by: Andy Shevchenko <[email protected]> Cc: stable <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]>
2021-06-09usb: typec: intel_pmc_mux: Put fwnode in error case during ->probe()Andy Shevchenko1-1/+3
device_get_next_child_node() bumps a reference counting of a returned variable. We have to balance it whenever we return to the caller. Fixes: 6701adfa9693 ("usb: typec: driver for Intel PMC mux control") Cc: Heikki Krogerus <[email protected]> Reviewed-by: Heikki Krogerus <[email protected]> Signed-off-by: Andy Shevchenko <[email protected]> Cc: stable <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]>
2021-06-09usb: typec: tcpm: Do not finish VDM AMS for retrying ResponsesKyle Tso1-0/+3
If the VDM responses couldn't be sent successfully, it doesn't need to finish the AMS until the retry count reaches the limit. Fixes: 0908c5aca31e ("usb: typec: tcpm: AMS and Collision Avoidance") Reviewed-by: Guenter Roeck <[email protected]> Cc: stable <[email protected]> Acked-by: Heikki Krogerus <[email protected]> Signed-off-by: Kyle Tso <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]>
2021-06-09usb: fix various gadget panics on 10gbps cablingMaciej Żenczykowski1-0/+8
usb_assign_descriptors() is called with 5 parameters, the last 4 of which are the usb_descriptor_header for: full-speed (USB1.1 - 12Mbps [including USB1.0 low-speed @ 1.5Mbps), high-speed (USB2.0 - 480Mbps), super-speed (USB3.0 - 5Gbps), super-speed-plus (USB3.1 - 10Gbps). The differences between full/high/super-speed descriptors are usually substantial (due to changes in the maximum usb block size from 64 to 512 to 1024 bytes and other differences in the specs), while the difference between 5 and 10Gbps descriptors may be as little as nothing (in many cases the same tuning is simply good enough). However if a gadget driver calls usb_assign_descriptors() with a NULL descriptor for super-speed-plus and is then used on a max 10gbps configuration, the kernel will crash with a null pointer dereference, when a 10gbps capable device port + cable + host port combination shows up. (This wouldn't happen if the gadget max-speed was set to 5gbps, but it of course defaults to the maximum, and there's no real reason to artificially limit it) The fix is to simply use the 5gbps descriptor as the 10gbps descriptor, if a 10gbps descriptor wasn't provided. Obviously this won't fix the problem if the 5gbps descriptor is also NULL, but such cases can't be so trivially solved (and any such gadgets are unlikely to be used with USB3 ports any way). Cc: Felipe Balbi <[email protected]> Cc: Greg Kroah-Hartman <[email protected]> Signed-off-by: Maciej Żenczykowski <[email protected]> Cc: stable <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]>
2021-06-09usb: fix various gadgets null ptr deref on 10gbps cabling.Maciej Żenczykowski10-10/+14
This avoids a null pointer dereference in f_{ecm,eem,hid,loopback,printer,rndis,serial,sourcesink,subset,tcm} by simply reusing the 5gbps config for 10gbps. Fixes: eaef50c76057 ("usb: gadget: Update usb_assign_descriptors for SuperSpeedPlus") Cc: Christophe JAILLET <[email protected]> Cc: Felipe Balbi <[email protected]> Cc: Gustavo A. R. Silva <[email protected]> Cc: Lorenzo Colitti <[email protected]> Cc: Martin K. Petersen <[email protected]> Cc: Michael R Sweet <[email protected]> Cc: Mike Christie <[email protected]> Cc: Pawel Laszczak <[email protected]> Cc: Peter Chen <[email protected]> Cc: Sudhakar Panneerselvam <[email protected]> Cc: Wei Ming Chen <[email protected]> Cc: Will McVicker <[email protected]> Cc: Zqiang <[email protected]> Reviewed-By: Lorenzo Colitti <[email protected]> Cc: stable <[email protected]> Signed-off-by: Maciej Żenczykowski <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]>
2021-06-09usb: pci-quirks: disable D3cold on xhci suspend for s2idle on AMD RenoirMario Limonciello2-1/+7
The XHCI controller is required to enter D3hot rather than D3cold for AMD s2idle on this hardware generation. Otherwise, the 'Controller Not Ready' (CNR) bit is not being cleared by host in resume and eventually this results in xhci resume failures during the s2idle wakeup. Link: https://lore.kernel.org/linux-usb/[email protected]/ Suggested-by: Prike Liang <[email protected]> Signed-off-by: Mario Limonciello <[email protected]> Cc: stable <[email protected]> # 5.11+ Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]>
2021-06-09usb: f_ncm: only first packet of aggregate needs to start timerMaciej Żenczykowski1-4/+4
The reasoning for this change is that if we already had a packet pending, then we also already had a pending timer, and as such there is no need to reschedule it. This also prevents packets getting delayed 60 ms worst case under a tiny packet every 290us transmit load, by keeping the timeout always relative to the first queued up packet. (300us delay * 16KB max aggregation / 80 byte packet =~ 60 ms) As such the first packet is now at most delayed by 300us. Under low transmit load, this will simply result in us sending a shorter aggregate, as originally intended. This patch has the benefit of greatly reducing (by ~10 factor with 1500 byte frames aggregated into 16 kiB) the number of (potentially pretty costly) updates to the hrtimer. Cc: Brooke Basile <[email protected]> Cc: Bryan O'Donoghue <[email protected]> Cc: Felipe Balbi <[email protected]> Cc: Lorenzo Colitti <[email protected]> Signed-off-by: Maciej Żenczykowski <[email protected]> Link: https://lore.kernel.org/r/[email protected] Cc: stable <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
2021-06-09USB: f_ncm: ncm_bitrate (speed) is unsignedMaciej Żenczykowski1-1/+1
[ 190.544755] configfs-gadget gadget: notify speed -44967296 This is because 4250000000 - 2**32 is -44967296. Fixes: 9f6ce4240a2b ("usb: gadget: f_ncm.c added") Cc: Brooke Basile <[email protected]> Cc: Bryan O'Donoghue <[email protected]> Cc: Felipe Balbi <[email protected]> Cc: Lorenzo Colitti <[email protected]> Cc: Yauheni Kaliuta <[email protected]> Cc: Linux USB Mailing List <[email protected]> Acked-By: Lorenzo Colitti <[email protected]> Signed-off-by: Maciej Żenczykowski <[email protected]> Cc: stable <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]>
2021-06-09Merge tag 'usb-v5.13-rc6' of ↵Greg Kroah-Hartman2-8/+7
git://git.kernel.org/pub/scm/linux/kernel/git/peter.chen/usb into usb-linus Peter writes: Two bug fixes for cdns3 and cdnsp * tag 'usb-v5.13-rc6' of git://git.kernel.org/pub/scm/linux/kernel/git/peter.chen/usb: usb: cdnsp: Fix deadlock issue in cdnsp_thread_irq_handler usb: cdns3: Enable TDL_CHK only for OUT ep
2021-06-09Merge tag 'usb-serial-5.13-rc5' of ↵Greg Kroah-Hartman4-6/+10
https://git.kernel.org/pub/scm/linux/kernel/git/johan/usb-serial into usb-linus Jonah writes: USB-serial fixes for 5.13-rc5 Here's a fix for some pipe-direction mismatches in the quatech2 driver, and a couple of new device ids for ftdi_sio and omninet (and a related trivial cleanup). All but the ftdi_sio commit have been in linux-next, and with no reported issues. * tag 'usb-serial-5.13-rc5' of https://git.kernel.org/pub/scm/linux/kernel/git/johan/usb-serial: USB: serial: ftdi_sio: add NovaTech OrionMX product ID USB: serial: omninet: update driver description USB: serial: omninet: add device id for Zyxel Omni 56K Plus USB: serial: quatech2: fix control-request directions
2021-06-05USB: serial: ftdi_sio: add NovaTech OrionMX product IDGeorge McCollister2-0/+2
Add PID for the NovaTech OrionMX so it can be automatically detected. Signed-off-by: George McCollister <[email protected]> Cc: [email protected] Signed-off-by: Johan Hovold <[email protected]>
2021-06-04USB: UDC: Implement udc_async_callbacks in net2272Alan Stern2-14/+28
This patch adds a udc_async_callbacks handler to the net2272 UDC driver, which will prevent a theoretical race during gadget unbinding. The net2272 driver is sufficiently complicated that I didn't want to mess around with IRQ settings. Instead, the patch simply adds a new flag to control async callbacks, and checks the flag before issuing any of them. Acked-by: Felipe Balbi <[email protected]> Signed-off-by: Alan Stern <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]>
2021-06-04USB: UDC: Implement udc_async_callbacks in net2280Alan Stern2-17/+33
This patch adds a udc_async_callbacks handler to the net2280 UDC driver, which will prevent a theoretical race during gadget unbinding. The net2280 driver is sufficiently complicated that I didn't want to mess around with IRQ settings. Instead, the patch simply adds a new flag to control async callbacks, and checks the flag before issuing any of them. Acked-by: Felipe Balbi <[email protected]> Signed-off-by: Alan Stern <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]>
2021-06-04USB: UDC: Implement udc_async_callbacks in dummy-hcdAlan Stern1-1/+10
This patch adds a udc_async_callbacks handler to the dummy-hcd UDC driver, which will prevent a theoretical race during gadget unbinding. The implementation is simple, since dummy-hcd already has a flag to keep track of whether emulated IRQs are enabled. All the handler has to do is store the enable value in the flag, and avoid setting the flag prematurely. Acked-by: Felipe Balbi <[email protected]> Signed-off-by: Alan Stern <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]>
2021-06-04USB: UDC core: Add udc_async_callbacks gadget opAlan Stern1-0/+49
The Gadget API has a theoretical race when a gadget driver is unbound. Although the pull-up is turned off before the driver's ->unbind callback runs, if the USB cable were to be unplugged at just the wrong moment there would be nothing to prevent the UDC driver from invoking the ->disconnect callback after the unbind has finished. In theory, other asynchronous callbacks could also happen during the time before the UDC driver's udc_stop routine is called, and the gadget driver would not be prepared to handle any of them. We need a way to tell UDC drivers to stop issuing asynchronous (that is, ->suspend, ->resume, ->disconnect, ->reset, or ->setup) callbacks at some point after the pull-up has been turned off and before the ->unbind callback runs. This patch adds a new ->udc_async_callbacks callback to the usb_gadget_ops structure for precisely this purpose, and it adds the corresponding support to the UDC core. Later patches in this series add support for udc_async_callbacks to several UDC drivers. Acked-by: Felipe Balbi <[email protected]> Signed-off-by: Alan Stern <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]>
2021-06-04usb: gadget: f_fs: Ensure io_completion_wq is idle during unbindWesley Cheng1-0/+3
During unbind, ffs_func_eps_disable() will be executed, resulting in completion callbacks for any pending USB requests. When using AIO, irrespective of the completion status, io_data work is queued to io_completion_wq to evaluate and handle the completed requests. Since work runs asynchronously to the unbind() routine, there can be a scenario where the work runs after the USB gadget has been fully removed, resulting in accessing of a resource which has been already freed. (i.e. usb_ep_free_request() accessing the USB ep structure) Explicitly drain the io_completion_wq, instead of relying on the destroy_workqueue() (in ffs_data_put()) to make sure no pending completion work items are running. Signed-off-by: Wesley Cheng <[email protected]> Cc: stable <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]>
2021-06-04usb: typec: tcpm: cancel send discover hrtimer when unregister tcpm portLi Jun1-0/+1
Like the state_machine_timer, we should also cancel possible pending send discover identity hrtimer when unregister tcpm port. Fixes: c34e85fa69b9 ("usb: typec: tcpm: Send DISCOVER_IDENTITY from dedicated work") Reviewed-by: Guenter Roeck <[email protected]> Cc: stable <[email protected]> Signed-off-by: Li Jun <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]>
2021-06-04usb: typec: tcpm: cancel frs hrtimer when unregister tcpm portLi Jun1-0/+1
Like the state_machine_timer, we should also cancel possible pending frs hrtimer when unregister tcpm port. Fixes: 8dc4bd073663 ("usb: typec: tcpm: Add support for Sink Fast Role SWAP(FRS)") Cc: stable <[email protected]> Reviewed-by: Guenter Roeck <[email protected]> Signed-off-by: Li Jun <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]>
2021-06-04usb: typec: tcpm: cancel vdm and state machine hrtimer when unregister tcpm portLi Jun1-0/+3
A pending hrtimer may expire after the kthread_worker of tcpm port is destroyed, see below kernel dump when do module unload, fix it by cancel the 2 hrtimers. [ 111.517018] Unable to handle kernel paging request at virtual address ffff8000118cb880 [ 111.518786] blk_update_request: I/O error, dev sda, sector 60061185 op 0x0:(READ) flags 0x0 phys_seg 1 prio class 0 [ 111.526594] Mem abort info: [ 111.526597] ESR = 0x96000047 [ 111.526600] EC = 0x25: DABT (current EL), IL = 32 bits [ 111.526604] SET = 0, FnV = 0 [ 111.526607] EA = 0, S1PTW = 0 [ 111.526610] Data abort info: [ 111.526612] ISV = 0, ISS = 0x00000047 [ 111.526615] CM = 0, WnR = 1 [ 111.526619] swapper pgtable: 4k pages, 48-bit VAs, pgdp=0000000041d75000 [ 111.526623] [ffff8000118cb880] pgd=10000001bffff003, p4d=10000001bffff003, pud=10000001bfffe003, pmd=10000001bfffa003, pte=0000000000000000 [ 111.526642] Internal error: Oops: 96000047 [#1] PREEMPT SMP [ 111.526647] Modules linked in: dwc3_imx8mp dwc3 phy_fsl_imx8mq_usb [last unloaded: tcpci] [ 111.526663] CPU: 0 PID: 0 Comm: swapper/0 Not tainted 5.13.0-rc4-00927-gebbe9dbd802c-dirty #36 [ 111.526670] Hardware name: NXP i.MX8MPlus EVK board (DT) [ 111.526674] pstate: 800000c5 (Nzcv daIF -PAN -UAO -TCO BTYPE=--) [ 111.526681] pc : queued_spin_lock_slowpath+0x1a0/0x390 [ 111.526695] lr : _raw_spin_lock_irqsave+0x88/0xb4 [ 111.526703] sp : ffff800010003e20 [ 111.526706] x29: ffff800010003e20 x28: ffff00017f380180 [ 111.537156] buffer_io_error: 6 callbacks suppressed [ 111.537162] Buffer I/O error on dev sda1, logical block 60040704, async page read [ 111.539932] x27: ffff00017f3801c0 [ 111.539938] x26: ffff800010ba2490 x25: 0000000000000000 x24: 0000000000000001 [ 111.543025] blk_update_request: I/O error, dev sda, sector 60061186 op 0x0:(READ) flags 0x0 phys_seg 7 prio class 0 [ 111.548304] [ 111.548306] x23: 00000000000000c0 x22: ffff0000c2a9f184 x21: ffff00017f380180 [ 111.551374] Buffer I/O error on dev sda1, logical block 60040705, async page read [ 111.554499] [ 111.554503] x20: ffff0000c5f14210 x19: 00000000000000c0 x18: 0000000000000000 [ 111.557391] Buffer I/O error on dev sda1, logical block 60040706, async page read [ 111.561218] [ 111.561222] x17: 0000000000000000 x16: 0000000000000000 x15: 0000000000000000 [ 111.564205] Buffer I/O error on dev sda1, logical block 60040707, async page read [ 111.570887] x14: 00000000000000f5 x13: 0000000000000001 x12: 0000000000000040 [ 111.570902] x11: ffff0000c05ac6d8 [ 111.583420] Buffer I/O error on dev sda1, logical block 60040708, async page read [ 111.588978] x10: 0000000000000000 x9 : 0000000000040000 [ 111.588988] x8 : 0000000000000000 [ 111.597173] Buffer I/O error on dev sda1, logical block 60040709, async page read [ 111.605766] x7 : ffff00017f384880 x6 : ffff8000118cb880 [ 111.605777] x5 : ffff00017f384880 [ 111.611094] Buffer I/O error on dev sda1, logical block 60040710, async page read [ 111.617086] x4 : 0000000000000000 x3 : ffff0000c2a9f184 [ 111.617096] x2 : ffff8000118cb880 [ 111.622242] Buffer I/O error on dev sda1, logical block 60040711, async page read [ 111.626927] x1 : ffff8000118cb880 x0 : ffff00017f384888 [ 111.626938] Call trace: [ 111.626942] queued_spin_lock_slowpath+0x1a0/0x390 [ 111.795809] kthread_queue_work+0x30/0xc0 [ 111.799828] state_machine_timer_handler+0x20/0x30 [ 111.804624] __hrtimer_run_queues+0x140/0x1e0 [ 111.808990] hrtimer_interrupt+0xec/0x2c0 [ 111.813004] arch_timer_handler_phys+0x38/0x50 [ 111.817456] handle_percpu_devid_irq+0x88/0x150 [ 111.821991] __handle_domain_irq+0x80/0xe0 [ 111.826093] gic_handle_irq+0xc0/0x140 [ 111.829848] el1_irq+0xbc/0x154 [ 111.832991] arch_cpu_idle+0x1c/0x2c [ 111.836572] default_idle_call+0x24/0x6c [ 111.840497] do_idle+0x238/0x2ac [ 111.843729] cpu_startup_entry+0x2c/0x70 [ 111.847657] rest_init+0xdc/0xec [ 111.850890] arch_call_rest_init+0x14/0x20 [ 111.854988] start_kernel+0x508/0x540 [ 111.858659] Code: 910020e0 8b0200c2 f861d884 aa0203e1 (f8246827) [ 111.864760] ---[ end trace 308b9a4a3dcb73ac ]--- [ 111.869381] Kernel panic - not syncing: Oops: Fatal exception in interrupt [ 111.876258] SMP: stopping secondary CPUs [ 111.880185] Kernel Offset: disabled [ 111.883673] CPU features: 0x00001001,20000846 [ 111.888031] Memory Limit: none [ 111.891090] ---[ end Kernel panic - not syncing: Oops: Fatal exception in interrupt ]--- Fixes: 3ed8e1c2ac99 ("usb: typec: tcpm: Migrate workqueue to RT priority for processing events") Cc: stable <[email protected]> Reviewed-by: Guenter Roeck <[email protected]> Signed-off-by: Li Jun <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]>
2021-06-04usb: typec: tcpm: Properly handle Alert and Status MessagesKyle Tso1-25/+27
When receiving Alert Message, if it is not unexpected but is unsupported for some reason, the port should return Not_Supported Message response. Also, according to PD3.0 Spec 6.5.2.1.4 Event Flags Field, the OTP/OVP/OCP flags in the Event Flags field in Status Message no longer require Get_PPS_Status Message to clear them. Thus remove it when receiving Status Message with those flags being set. In addition, add the missing AMS operations for Status Message. Fixes: 64f7c494a3c0 ("typec: tcpm: Add support for sink PPS related messages") Fixes: 0908c5aca31e ("usb: typec: tcpm: AMS and Collision Avoidance") Signed-off-by: Kyle Tso <[email protected]> Link: https://lore.kernel.org/r/[email protected] Cc: stable <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
2021-06-04usb: dwc3-meson-g12a: fix usb2 PHY glue init when phy0 is disabledNeil Armstrong1-1/+4
When only PHY1 is used (for example on Odroid-HC4), the regmap init code uses the usb2 ports when doesn't initialize the PHY1 regmap entry. This fixes: Unable to handle kernel NULL pointer dereference at virtual address 0000000000000020 ... pc : regmap_update_bits_base+0x40/0xa0 lr : dwc3_meson_g12a_usb2_init_phy+0x4c/0xf8 ... Call trace: regmap_update_bits_base+0x40/0xa0 dwc3_meson_g12a_usb2_init_phy+0x4c/0xf8 dwc3_meson_g12a_usb2_init+0x7c/0xc8 dwc3_meson_g12a_usb_init+0x28/0x48 dwc3_meson_g12a_probe+0x298/0x540 platform_probe+0x70/0xe0 really_probe+0xf0/0x4d8 driver_probe_device+0xfc/0x168 ... Fixes: 013af227f58a97 ("usb: dwc3: meson-g12a: handle the phy and glue registers separately") Reviewed-by: Martin Blumenstingl <[email protected]> Signed-off-by: Neil Armstrong <[email protected]> Cc: stable <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]>
2021-06-04usb: dwc3: meson-g12a: Disable the regulator in the error handling path of ↵Christophe JAILLET1-2/+6
the probe If an error occurs after a successful 'regulator_enable()' call, 'regulator_disable()' must be called. Fix the error handling path of the probe accordingly. The remove function doesn't need to be fixed, because the 'regulator_disable()' call is already hidden in 'dwc3_meson_g12a_suspend()' which is called via 'pm_runtime_set_suspended()' in the remove function. Fixes: c99993376f72 ("usb: dwc3: Add Amlogic G12A DWC3 glue") Reviewed-by: Martin Blumenstingl <[email protected]> Acked-by: Neil Armstrong <[email protected]> Signed-off-by: Christophe JAILLET <[email protected]> Link: https://lore.kernel.org/r/79df054046224bbb0716a8c5c2082650290eec86.1621616013.git.christophe.jaillet@wanadoo.fr Cc: stable <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
2021-06-04usb: typec: tcpm: Fix misuses of AMS invocationKyle Tso1-6/+5
tcpm_ams_start is used to initiate an AMS as well as checking Collision Avoidance conditions but not for flagging passive AMS (initiated by the port partner). Fix the misuses of tcpm_ams_start in tcpm_pd_svdm. ATTENTION doesn't need responses so the AMS flag is not needed here. Fixes: 0bc3ee92880d ("usb: typec: tcpm: Properly interrupt VDM AMS") Signed-off-by: Kyle Tso <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]>
2021-06-04usb: typec: tcpm: Introduce snk_vdo_v1 for SVDM version 1.0Kyle Tso1-12/+28
The ID Header VDO and Product VDOs defined in USB PD Spec rev 2.0 and rev 3.1 are quite different. Add an additional array snk_vdo_v1 and send it as the response to the port partner if it only supports SVDM version 1.0. Acked-by: Heikki Krogerus <[email protected]> Signed-off-by: Kyle Tso <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]>
2021-06-04usb: typec: tcpm: Correct the responses in SVDM Version 2.0 DFPKyle Tso1-4/+10
In USB PD Spec Rev 3.1 Ver 1.0, section "6.12.5 Applicability of Structured VDM Commands", DFP is allowed and recommended to respond to Discovery Identity with ACK. And in section "6.4.4.2.5.1 Commands other than Attention", NAK should be returned only when receiving Messages with invalid fields, Messages in wrong situation, or unrecognize Messages. Still keep the original design for SVDM Version 1.0 for backward compatibilities. Fixes: 193a68011fdc ("staging: typec: tcpm: Respond to Discover Identity commands") Acked-by: Heikki Krogerus <[email protected]> Signed-off-by: Kyle Tso <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]>
2021-06-04Revert "usb: dwc3: core: Add shutdown callback for dwc3"Alexandru Elisei1-6/+0
This reverts commit 568262bf5492a9bb2fcc4c204b8d38fd6be64e28. The commit causes the following panic when shutting down a rockpro64-v2 board: [..] [ 41.684569] xhci-hcd xhci-hcd.2.auto: USB bus 1 deregistered [ 41.686301] Unable to handle kernel NULL pointer dereference at virtual address 00000000000000a0 [ 41.687096] Mem abort info: [ 41.687345] ESR = 0x96000004 [ 41.687615] EC = 0x25: DABT (current EL), IL = 32 bits [ 41.688082] SET = 0, FnV = 0 [ 41.688352] EA = 0, S1PTW = 0 [ 41.688628] Data abort info: [ 41.688882] ISV = 0, ISS = 0x00000004 [ 41.689219] CM = 0, WnR = 0 [ 41.689481] user pgtable: 4k pages, 48-bit VAs, pgdp=00000000073b2000 [ 41.690046] [00000000000000a0] pgd=0000000000000000, p4d=0000000000000000 [ 41.690654] Internal error: Oops: 96000004 [#1] PREEMPT SMP [ 41.691143] Modules linked in: [ 41.691416] CPU: 5 PID: 1 Comm: shutdown Not tainted 5.13.0-rc4 #43 [ 41.691966] Hardware name: Pine64 RockPro64 v2.0 (DT) [ 41.692409] pstate: 60000005 (nZCv daif -PAN -UAO -TCO BTYPE=--) [ 41.692937] pc : down_read_interruptible+0xec/0x200 [ 41.693373] lr : simple_recursive_removal+0x48/0x280 [ 41.693815] sp : ffff800011fab910 [ 41.694107] x29: ffff800011fab910 x28: ffff0000008fe480 x27: ffff0000008fe4d8 [ 41.694736] x26: ffff800011529a90 x25: 00000000000000a0 x24: ffff800011edd030 [ 41.695364] x23: 0000000000000080 x22: 0000000000000000 x21: ffff800011f23994 [ 41.695992] x20: ffff800011f23998 x19: ffff0000008fe480 x18: ffffffffffffffff [ 41.696620] x17: 000c0400bb44ffff x16: 0000000000000009 x15: ffff800091faba3d [ 41.697248] x14: 0000000000000004 x13: 0000000000000000 x12: 0000000000000020 [ 41.697875] x11: 0101010101010101 x10: 7f7f7f7f7f7f7f7f x9 : 6f6c746364716e62 [ 41.698502] x8 : 7f7f7f7f7f7f7f7f x7 : fefefeff6364626d x6 : 0000000000000440 [ 41.699130] x5 : 0000000000000000 x4 : 0000000000000000 x3 : 00000000000000a0 [ 41.699758] x2 : 0000000000000001 x1 : 0000000000000000 x0 : 00000000000000a0 [ 41.700386] Call trace: [ 41.700602] down_read_interruptible+0xec/0x200 [ 41.701003] debugfs_remove+0x5c/0x80 [ 41.701328] dwc3_debugfs_exit+0x1c/0x6c [ 41.701676] dwc3_remove+0x34/0x1a0 [ 41.701988] platform_remove+0x28/0x60 [ 41.702322] __device_release_driver+0x188/0x22c [ 41.702730] device_release_driver+0x2c/0x44 [ 41.703106] bus_remove_device+0x124/0x130 [ 41.703468] device_del+0x16c/0x424 [ 41.703777] platform_device_del.part.0+0x1c/0x90 [ 41.704193] platform_device_unregister+0x28/0x44 [ 41.704608] of_platform_device_destroy+0xe8/0x100 [ 41.705031] device_for_each_child_reverse+0x64/0xb4 [ 41.705470] of_platform_depopulate+0x40/0x84 [ 41.705853] __dwc3_of_simple_teardown+0x20/0xd4 [ 41.706260] dwc3_of_simple_shutdown+0x14/0x20 [ 41.706652] platform_shutdown+0x28/0x40 [ 41.706998] device_shutdown+0x158/0x330 [ 41.707344] kernel_power_off+0x38/0x7c [ 41.707684] __do_sys_reboot+0x16c/0x2a0 [ 41.708029] __arm64_sys_reboot+0x28/0x34 [ 41.708383] invoke_syscall+0x48/0x114 [ 41.708716] el0_svc_common.constprop.0+0x44/0xdc [ 41.709131] do_el0_svc+0x28/0x90 [ 41.709426] el0_svc+0x2c/0x54 [ 41.709698] el0_sync_handler+0xa4/0x130 [ 41.710045] el0_sync+0x198/0x1c0 [ 41.710342] Code: c8047c62 35ffff84 17fffe5f f9800071 (c85ffc60) [ 41.710881] ---[ end trace 406377df5178f75c ]--- [ 41.711299] Kernel panic - not syncing: Attempted to kill init! exitcode=0x0000000b [ 41.712084] Kernel Offset: disabled [ 41.712391] CPU features: 0x10001031,20000846 [ 41.712775] Memory Limit: none [ 41.713049] ---[ end Kernel panic - not syncing: Attempted to kill init! exitcode=0x0000000b ]--- As Felipe explained: "dwc3_shutdown() is just called dwc3_remove() directly, then we end up calling debugfs_remove_recursive() twice." Reverting the commit fixes the panic. Fixes: 568262bf5492 ("usb: dwc3: core: Add shutdown callback for dwc3") Acked-by: Felipe Balbi <[email protected]> Signed-off-by: Alexandru Elisei <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]>
2021-06-03usb: dwc3: debugfs: Add and remove endpoint dirs dynamicallyJack Pham3-19/+8
The DWC3 DebugFS directory and files are currently created once during probe. This includes creation of subdirectories for each of the gadget's endpoints. This works fine for peripheral-only controllers, as dwc3_core_init_mode() calls dwc3_gadget_init() just prior to calling dwc3_debugfs_init(). However, for dual-role controllers, dwc3_core_init_mode() will instead call dwc3_drd_init() which is problematic in a few ways. First, the initial state must be determined, then dwc3_set_mode() will have to schedule drd_work and by then dwc3_debugfs_init() could have already been invoked. Even if the initial mode is peripheral, dwc3_gadget_init() happens after the DebugFS files are created, and worse so if the initial state is host and the controller switches to peripheral much later. And secondly, even if the gadget endpoints' debug entries were successfully created, if the controller exits peripheral mode, its dwc3_eps are freed so the debug files would now hold stale references. So it is best if the DebugFS endpoint entries are created and removed dynamically at the same time the underlying dwc3_eps are. Do this by calling dwc3_debugfs_create_endpoint_dir() as each endpoint is created, and conversely remove the DebugFS entry when the endpoint is freed. Fixes: 41ce1456e1db ("usb: dwc3: core: make dwc3_set_mode() work properly") Cc: stable <[email protected]> Reviewed-by: Peter Chen <[email protected]> Signed-off-by: Jack Pham <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]>
2021-06-03usb: typec: intel_pmc_mux: Update IOM port status offset for AlderLakeAzhar Shaikh1-5/+23
Intel AlderLake(ADL) IOM has a different IOM port status offset than Intel TigerLake. Add a new ACPI ID for ADL and use the IOM port status offset as per the platform. Acked-by: Heikki Krogerus <[email protected]> Signed-off-by: Azhar Shaikh <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]>
Powered by cgit, Gruvboxed by Blaster4385.