- 25 7月, 2023 1 次提交
-
-
由 Michael Grzeschik 提交于
stable inclusion from stable-v5.10.157 commit a32635528d6552cb729968af2db09e64c4ac6f24 category: bugfix bugzilla: https://gitee.com/openeuler/kernel/issues/I7MU59 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=a32635528d6552cb729968af2db09e64c4ac6f24 -------------------------------- [ Upstream commit b44c0e7f ] The functions stop_active_transfers and ep_disable are both calling remove_requests. This functions in both cases will giveback the requests with status ESHUTDOWN, which also represents an physical disconnection. For ep_disable this is not true. This patch adds the status parameter to remove_requests and sets the status to ECONNRESET on ep_disable. Signed-off-by: NMichael Grzeschik <m.grzeschik@pengutronix.de> Link: https://lore.kernel.org/r/20220720213523.1055897-1-m.grzeschik@pengutronix.deSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org> Stable-dep-of: f90f5afd ("usb: dwc3: gadget: Clear ep descriptor last") Signed-off-by: NSasha Levin <sashal@kernel.org> Signed-off-by: Nsanglipeng <sanglipeng1@jd.com>
-
- 23 5月, 2023 2 次提交
-
-
由 Thinh Nguyen 提交于
stable inclusion from stable-v5.10.153 commit e440957f9c8bedae784f718c42207af222c25818 category: bugfix bugzilla: https://gitee.com/openeuler/kernel/issues/I64YCA Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=e440957f9c8bedae784f718c42207af222c25818 -------------------------------- commit 308c316d upstream. The gadget driver may have a certain expectation of how the request completion flow should be from to its configuration. Make sure the controller driver respect that. That is, don't set IMI (Interrupt on Missed Isoc) when usb_request->no_interrupt is set. Also, the driver should only set IMI to the last TRB of a chain. Fixes: 72246da4 ("usb: Introduce DesignWare USB3 DRD Driver") Cc: stable@vger.kernel.org Signed-off-by: NThinh Nguyen <Thinh.Nguyen@synopsys.com> Reviewed-by: NJeff Vanhoof <jdv1029@gmail.com> Tested-by: NJeff Vanhoof <jdv1029@gmail.com> Link: https://lore.kernel.org/r/ced336c84434571340c07994e3667a0ee284fefe.1666735451.git.Thinh.Nguyen@synopsys.comSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: NLipeng Sang <sanglipeng1@jd.com>
-
由 Thinh Nguyen 提交于
stable inclusion from stable-v5.10.153 commit fb074d622ccc7e3999cde47f18ea7f8970b09d11 category: bugfix bugzilla: https://gitee.com/openeuler/kernel/issues/I64YCA Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=fb074d622ccc7e3999cde47f18ea7f8970b09d11 -------------------------------- commit f78961f8 upstream. When servicing a transfer completion event, the dwc3 driver will reclaim TRBs of started requests up to the request associated with the interrupt event. Currently we don't check for interrupt due to missed isoc, and the driver may attempt to reclaim TRBs beyond the associated event. This causes invalid memory access when the hardware still owns the TRB. If there's a missed isoc TRB with IMI (interrupt on missed isoc), make sure to stop servicing further. Note that only the last TRB of chained TRBs has its status updated with missed isoc. Fixes: 72246da4 ("usb: Introduce DesignWare USB3 DRD Driver") Cc: stable@vger.kernel.org Reported-by: NJeff Vanhoof <jdv1029@gmail.com> Reported-by: NDan Vacura <w36195@motorola.com> Signed-off-by: NThinh Nguyen <Thinh.Nguyen@synopsys.com> Reviewed-by: NJeff Vanhoof <jdv1029@gmail.com> Tested-by: NJeff Vanhoof <jdv1029@gmail.com> Link: https://lore.kernel.org/r/b29acbeab531b666095dfdafd8cb5c7654fbb3e1.1666735451.git.Thinh.Nguyen@synopsys.comSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: NLipeng Sang <sanglipeng1@jd.com>
-
- 17 2月, 2023 6 次提交
-
-
由 Wesley Cheng 提交于
stable inclusion from stable-v5.10.146 commit 9c28189bb654a97efadbdb78c6ef67564b03eb3e category: bugfix bugzilla: https://gitee.com/openeuler/kernel/issues/I6D0VX Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=9c28189bb654a97efadbdb78c6ef67564b03eb3e -------------------------------- [ Upstream commit 040f2dbd ] Relocate the pullups_connected check until after it is ensured that there are no runtime PM transitions. If another context triggered the DWC3 core's runtime resume, it may have already enabled the Run/Stop. Do not re-run the entire pullup sequence again, as it may issue a core soft reset while Run/Stop is already set. This patch depends on commit 69e131d1 ("usb: dwc3: gadget: Prevent repeat pullup()") Fixes: 77adb8bd ("usb: dwc3: gadget: Allow runtime suspend if UDC unbinded") Cc: stable <stable@kernel.org> Signed-off-by: NWesley Cheng <quic_wcheng@quicinc.com> Link: https://lore.kernel.org/r/20220728020647.9377-1-quic_wcheng@quicinc.comSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: NSasha Levin <sashal@kernel.org> Signed-off-by: NJialin Zhang <zhangjialin11@huawei.com> Reviewed-by: NZheng Zengkai <zhengzengkai@huawei.com>
-
由 Thinh Nguyen 提交于
stable inclusion from stable-v5.10.146 commit ff23c7277fb41fe13283b1b3edd997cbddd7a18c category: bugfix bugzilla: https://gitee.com/openeuler/kernel/issues/I6D0VX Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=ff23c7277fb41fe13283b1b3edd997cbddd7a18c -------------------------------- [ Upstream commit 8f8034f4 ] If the GEVNTCOUNT indicates events in the event buffer, the driver needs to acknowledge them before the controller can halt. Simply let the interrupt handler acknowledges the remaining event generated by the controller while polling for DSTS.DEVCTLHLT. This avoids disabling irq and taking care of race condition between the interrupt handlers and pullup(). Signed-off-by: NThinh Nguyen <Thinh.Nguyen@synopsys.com> Link: https://lore.kernel.org/r/ea306ec93c41ccafbdb5d16404ff3b6eca299613.1650593829.git.Thinh.Nguyen@synopsys.comSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org> Stable-dep-of: 040f2dbd ("usb: dwc3: gadget: Avoid duplicate requests to enable Run/Stop") Signed-off-by: NSasha Levin <sashal@kernel.org> Signed-off-by: NJialin Zhang <zhangjialin11@huawei.com> Reviewed-by: NZheng Zengkai <zhengzengkai@huawei.com>
-
由 Thinh Nguyen 提交于
stable inclusion from stable-v5.10.146 commit ab046365c91c5444c3f0354665859726a3d5e378 category: bugfix bugzilla: https://gitee.com/openeuler/kernel/issues/I6D0VX Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=ab046365c91c5444c3f0354665859726a3d5e378 -------------------------------- [ Upstream commit 861c010a ] Move soft-disconnect sequence out of dwc3_gadget_pullup(). No functional change here. Signed-off-by: NThinh Nguyen <Thinh.Nguyen@synopsys.com> Link: https://lore.kernel.org/r/4c0f259b17d95acaaa931f90276683a48a32fe22.1650593829.git.Thinh.Nguyen@synopsys.comSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org> Stable-dep-of: 040f2dbd ("usb: dwc3: gadget: Avoid duplicate requests to enable Run/Stop") Signed-off-by: NSasha Levin <sashal@kernel.org> Signed-off-by: NJialin Zhang <zhangjialin11@huawei.com> Reviewed-by: NZheng Zengkai <zhengzengkai@huawei.com>
-
由 Thinh Nguyen 提交于
stable inclusion from stable-v5.10.146 commit db27874477fd5772e1a87e292e807a834d49e9f6 category: bugfix bugzilla: https://gitee.com/openeuler/kernel/issues/I6D0VX Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=db27874477fd5772e1a87e292e807a834d49e9f6 -------------------------------- [ Upstream commit 69e131d1 ] Don't do soft-disconnect if it's previously done. Likewise, don't do soft-connect if the device is currently connected and running. It would break normal operation. Currently the caller of pullup() (udc's sysfs soft_connect) only checks if it had initiated disconnect to prevent repeating soft-disconnect. It doesn't check for soft-connect. To be safe, let's keep the check here regardless whether the udc core is fixed. Signed-off-by: NThinh Nguyen <Thinh.Nguyen@synopsys.com> Link: https://lore.kernel.org/r/1c1345bd66c97a9d32f77d63aaadd04b7b037143.1650593829.git.Thinh.Nguyen@synopsys.comSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org> Stable-dep-of: 040f2dbd ("usb: dwc3: gadget: Avoid duplicate requests to enable Run/Stop") Signed-off-by: NSasha Levin <sashal@kernel.org> Signed-off-by: NJialin Zhang <zhangjialin11@huawei.com> Reviewed-by: NZheng Zengkai <zhengzengkai@huawei.com>
-
由 Wesley Cheng 提交于
stable inclusion from stable-v5.10.146 commit 6bd182beef5deaf5ceaa5d658f22e46cc3014912 category: bugfix bugzilla: https://gitee.com/openeuler/kernel/issues/I6D0VX Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=6bd182beef5deaf5ceaa5d658f22e46cc3014912 -------------------------------- [ Upstream commit 0066472d ] It is recommended by the Synopsis databook to issue a DCTL.CSftReset when reconnecting from a device-initiated disconnect routine. This resolves issues with enumeration during fast composition switching cases, which result in an unknown device on the host. Reviewed-by: NThinh Nguyen <Thinh.Nguyen@synopsys.com> Signed-off-by: NWesley Cheng <quic_wcheng@quicinc.com> Link: https://lore.kernel.org/r/20220316011358.3057-1-quic_wcheng@quicinc.comSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org> Stable-dep-of: 040f2dbd ("usb: dwc3: gadget: Avoid duplicate requests to enable Run/Stop") Signed-off-by: NSasha Levin <sashal@kernel.org> Signed-off-by: NJialin Zhang <zhangjialin11@huawei.com> Reviewed-by: NZheng Zengkai <zhengzengkai@huawei.com>
-
由 Wesley Cheng 提交于
stable inclusion from stable-v5.10.146 commit b83692feb09c1817674839f5b0ad68e630f61e51 category: bugfix bugzilla: https://gitee.com/openeuler/kernel/issues/I6D0VX Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=b83692feb09c1817674839f5b0ad68e630f61e51 -------------------------------- [ Upstream commit 8217f07a ] There is a race present where the DWC3 runtime resume runs in parallel to the UDC unbind sequence. This will eventually lead to a possible scenario where we are enabling the run/stop bit, without a valid composition defined. Thread#1 (handling UDC unbind): usb_gadget_remove_driver() -->usb_gadget_disconnect() -->dwc3_gadget_pullup(0) --> continue UDC unbind sequence -->Thread#2 is running in parallel here Thread#2 (handing next cable connect) __dwc3_set_mode() -->pm_runtime_get_sync() -->dwc3_gadget_resume() -->dwc->gadget_driver is NOT NULL yet -->dwc3_gadget_run_stop(1) --> _dwc3gadget_start() ... Fix this by tracking the pullup disable routine, and avoiding resuming of the DWC3 gadget. Once the UDC is re-binded, that will trigger the pullup enable routine, which would handle enabling the DWC3 gadget. Acked-by: NFelipe Balbi <balbi@kernel.org> Signed-off-by: NWesley Cheng <wcheng@codeaurora.org> Link: https://lore.kernel.org/r/20210917021852.2037-1-wcheng@codeaurora.orgSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org> Stable-dep-of: 040f2dbd ("usb: dwc3: gadget: Avoid duplicate requests to enable Run/Stop") Signed-off-by: NSasha Levin <sashal@kernel.org> Signed-off-by: NJialin Zhang <zhangjialin11@huawei.com> Reviewed-by: NZheng Zengkai <zhengzengkai@huawei.com>
-
- 18 11月, 2022 2 次提交
-
-
由 Michael Grzeschik 提交于
stable inclusion from stable-v5.10.137 commit f294829fb47ee508ad21566f8e29db82d41a5a79 category: bugfix bugzilla: https://gitee.com/openeuler/kernel/issues/I60PLB Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=f294829fb47ee508ad21566f8e29db82d41a5a79 -------------------------------- commit 8affe37c upstream. For High-Speed Transfers the prepare_one_trb function is calculating the multiplier setting for the trb based on the length parameter of the trb currently prepared. This assumption is wrong. For trbs with a sg list, the length of the actual request has to be taken instead. Fixes: 40d829fb ("usb: dwc3: gadget: Correct ISOC DATA PIDs for short packets") Cc: stable <stable@kernel.org> Signed-off-by: NMichael Grzeschik <m.grzeschik@pengutronix.de> Link: https://lore.kernel.org/r/20220704141812.1532306-3-m.grzeschik@pengutronix.deSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com> Reviewed-by: NWei Li <liwei391@huawei.com>
-
由 Michael Grzeschik 提交于
stable inclusion from stable-v5.10.137 commit fc2a039cdb3d50eaa8ea21a060f4e929ca91cdd7 category: bugfix bugzilla: https://gitee.com/openeuler/kernel/issues/I60PLB Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=fc2a039cdb3d50eaa8ea21a060f4e929ca91cdd7 -------------------------------- commit 23385cec upstream. The function __dwc3_prepare_one_trb has many parameters. Since it is only used in dwc3_prepare_one_trb there is no point in keeping the function. We merge both functions and get rid of the big list of parameters. Fixes: 40d829fb ("usb: dwc3: gadget: Correct ISOC DATA PIDs for short packets") Cc: stable <stable@kernel.org> Signed-off-by: NMichael Grzeschik <m.grzeschik@pengutronix.de> Link: https://lore.kernel.org/r/20220704141812.1532306-2-m.grzeschik@pengutronix.deSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com> Reviewed-by: NWei Li <liwei391@huawei.com>
-
- 02 11月, 2022 1 次提交
-
-
由 Thinh Nguyen 提交于
stable inclusion from stable-v5.10.132 commit 0e5668ed7b7aaab4a53126daeef0258c5c573d5d category: bugfix bugzilla: https://gitee.com/openeuler/kernel/issues/I5YS3T Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=0e5668ed7b7aaab4a53126daeef0258c5c573d5d -------------------------------- commit 7441b273 upstream. The DWC3_EVENT_PENDING flag is used to protect against invalid call to top-half interrupt handler, which can occur when there's a delay in software detection of the interrupt line deassertion. However, the clearing of this flag was done prior to unmasking the interrupt line, creating opportunity where the top-half handler can come. This breaks the serialization and creates a race between the top-half and bottom-half handler, resulting in losing synchronization between the controller and the driver when processing events. To fix this, make sure the clearing of the DWC3_EVENT_PENDING is done at the end of the bottom-half handler. Fixes: d325a1de ("usb: dwc3: gadget: Prevent losing events in event cache") Cc: stable@vger.kernel.org Signed-off-by: NThinh Nguyen <Thinh.Nguyen@synopsys.com> Link: https://lore.kernel.org/r/8670aaf1cf52e7d1e6df2a827af2d77263b93b75.1656380429.git.Thinh.Nguyen@synopsys.comSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com> Acked-by: NXie XiuQi <xiexiuqi@huawei.com>
-
- 29 9月, 2022 1 次提交
-
-
由 Albert Wang 提交于
stable inclusion from stable-v5.10.121 commit a2532c441705c406f07f55afe586af54e9cf4041 category: bugfix bugzilla: https://gitee.com/openeuler/kernel/issues/I5L6CQ Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=a2532c441705c406f07f55afe586af54e9cf4041 -------------------------------- commit 3c588074 upstream. When dwc3_gadget_ep_cleanup_completed_requests() called to dwc3_gadget_giveback() where the dwc3 lock is released, other thread is able to execute. In this situation, usb_ep_disable() gets the chance to clear endpoint descriptor pointer which leds to the null pointer dereference problem. So needs to move the null pointer check to a proper place. Example call stack: Thread#1: dwc3_thread_interrupt() spin_lock -> dwc3_process_event_buf() -> dwc3_process_event_entry() -> dwc3_endpoint_interrupt() -> dwc3_gadget_endpoint_trbs_complete() -> dwc3_gadget_ep_cleanup_completed_requests() ... -> dwc3_giveback() spin_unlock Thread#2 executes Thread#2: configfs_composite_disconnect() -> __composite_disconnect() -> ffs_func_disable() -> ffs_func_set_alt() -> ffs_func_eps_disable() -> usb_ep_disable() wait for dwc3 spin_lock Thread#1 released lock clear endpoint.desc Fixes: 26288448 ("usb: dwc3: gadget: Fix null pointer exception") Cc: stable <stable@kernel.org> Signed-off-by: NAlbert Wang <albertccwang@google.com> Link: https://lore.kernel.org/r/20220518061315.3359198-1-albertccwang@google.comSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com> Acked-by: NXie XiuQi <xiexiuqi@huawei.com>
-
- 04 8月, 2022 1 次提交
-
-
由 Thinh Nguyen 提交于
stable inclusion from stable-v5.10.114 commit bd7f84708ea02b632fac872c5d0792d20560d826 category: bugfix bugzilla: https://gitee.com/openeuler/kernel/issues/I5IY1V Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=bd7f84708ea02b632fac872c5d0792d20560d826 -------------------------------- commit c7428dbd upstream. If the user sets the usb_request's no_interrupt, then there will be no completion event for the request. Currently the driver incorrectly uses the event status of a different request to report the status for a request with no_interrupt. The dwc3 driver needs to check the TRB status associated with the request when reporting its status. Note: this is only applicable to missed_isoc TRB completion status, but the other status are also listed for completeness/documentation. Fixes: 6d8a0196 ("usb: dwc3: gadget: check for Missed Isoc from event status") Cc: <stable@vger.kernel.org> Signed-off-by: NThinh Nguyen <Thinh.Nguyen@synopsys.com> Link: https://lore.kernel.org/r/db2c80108286cfd108adb05bad52138b78d7c3a7.1650673655.git.Thinh.Nguyen@synopsys.comSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com> Acked-by: NXie XiuQi <xiexiuqi@huawei.com>
-
- 26 5月, 2022 1 次提交
-
-
stable inclusion from stable-v5.10.103 commit 328faee6d4099de2e8d9dc18ded9ea31f62b5b5f bugzilla: https://gitee.com/openeuler/kernel/issues/I56NE7 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=328faee6d4099de2e8d9dc18ded9ea31f62b5b5f -------------------------------- commit 84918a89 upstream. The interrupt service routine registered for the gadget is a primary handler which mask the interrupt source and a threaded handler which handles the source of the interrupt. Since the threaded handler is voluntary threaded, the IRQ-core does not disable bottom halves before invoke the handler like it does for the forced-threaded handler. Due to changes in networking it became visible that a network gadget's completions handler may schedule a softirq which remains unprocessed. The gadget's completion handler is usually invoked either in hard-IRQ or soft-IRQ context. In this context it is enough to just raise the softirq because the softirq itself will be handled once that context is left. In the case of the voluntary threaded handler, there is nothing that will process pending softirqs. Which means it remain queued until another random interrupt (on this CPU) fires and handles it on its exit path or another thread locks and unlocks a lock with the bh suffix. Worst case is that the CPU goes idle and the NOHZ complains about unhandled softirqs. Disable bottom halves before acquiring the lock (and disabling interrupts) and enable them after dropping the lock. This ensures that any pending softirqs will handled right away. Link: https://lkml.kernel.org/r/c2a64979-73d1-2c22-e048-c275c9f81558@samsung.com Fixes: e5f68b4a ("Revert "usb: dwc3: gadget: remove unnecessary _irqsave()"") Cc: stable <stable@kernel.org> Reported-by: NMarek Szyprowski <m.szyprowski@samsung.com> Tested-by: NMarek Szyprowski <m.szyprowski@samsung.com> Signed-off-by: NSebastian Andrzej Siewior <bigeasy@linutronix.de> Link: https://lore.kernel.org/r/Yg/YPejVQH3KkRVd@linutronix.deSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: NYu Liao <liaoyu15@huawei.com> Reviewed-by: NWei Li <liwei391@huawei.com> Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>
-
- 19 5月, 2022 1 次提交
-
-
由 Udipto Goswami 提交于
stable inclusion from stable-v5.10.101 commit 3bfca38914807293faa3d9b748bb1bec894e909a bugzilla: https://gitee.com/openeuler/kernel/issues/I5669Z Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=3bfca38914807293faa3d9b748bb1bec894e909a -------------------------------- commit 117b4e96 upstream. With CPU re-ordering on write instructions, there might be a chance that the HWO is set before the TRB is updated with the new mapped buffer address. And in the case where core is processing a list of TRBs it is possible that it fetched the TRBs when the HWO is set but before the buffer address is updated. Prevent this by adding a memory barrier before the HWO is updated to ensure that the core always process the updated TRBs. Fixes: f6bafc6a ("usb: dwc3: convert TRBs into bitshifts") Cc: stable <stable@vger.kernel.org> Reviewed-by: NPavankumar Kondeti <quic_pkondeti@quicinc.com> Signed-off-by: NUdipto Goswami <quic_ugoswami@quicinc.com> Link: https://lore.kernel.org/r/1644207958-18287-1-git-send-email-quic_ugoswami@quicinc.comSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: NYu Liao <liaoyu15@huawei.com> Reviewed-by: NWei Li <liwei391@huawei.com> Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>
-
- 14 1月, 2022 3 次提交
-
-
由 Albert Wang 提交于
stable inclusion from stable-v5.10.83 commit 0755f3f32277b0860b10a09fcd28b66361b7fd4d bugzilla: 185879 https://gitee.com/openeuler/kernel/issues/I4QUVG Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=0755f3f32277b0860b10a09fcd28b66361b7fd4d -------------------------------- commit 26288448 upstream. In the endpoint interrupt functions dwc3_gadget_endpoint_transfer_in_progress() and dwc3_gadget_endpoint_trbs_complete() will dereference the endpoint descriptor. But it could be cleared in __dwc3_gadget_ep_disable() when accessory disconnected. So we need to check whether it is null or not before dereferencing it. Fixes: f09ddcfc ("usb: dwc3: gadget: Prevent EP queuing while stopping transfers") Cc: stable <stable@vger.kernel.org> Reviewed-by: NJack Pham <quic_jackp@quicinc.com> Signed-off-by: NAlbert Wang <albertccwang@google.com> Link: https://lore.kernel.org/r/20211109092642.3507692-1-albertccwang@google.comSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: NChen Jun <chenjun102@huawei.com> Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>
-
由 Thinh Nguyen 提交于
stable inclusion from stable-v5.10.83 commit 140e2df472ba0014692c6202e6b44cc5e5161f79 bugzilla: 185879 https://gitee.com/openeuler/kernel/issues/I4QUVG Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=140e2df472ba0014692c6202e6b44cc5e5161f79 -------------------------------- commit 63c4c320 upstream. The programming guide noted that the driver needs to verify if the link state is in U0 before executing the Start Transfer command. If it's not in U0, the driver needs to perform remote wakeup. This is not accurate. If the link state is in U1/U2, then the controller will not respond to link recovery request from DCTL.ULSTCHNGREQ. The Start Transfer command will trigger a link recovery if it is in U1/U2. A clarification will be added to the programming guide for all controller versions. The current implementation shouldn't cause any functional issue. It may occasionally report an invalid time out warning from failed link recovery request. The driver will still go ahead with the Start Transfer command if the remote wakeup fails. The new change only initiates remote wakeup where it is needed, which is when the link state is in L1/L2/U3. Fixes: c36d8e94 ("usb: dwc3: gadget: put link to U0 before Start Transfer") Cc: <stable@vger.kernel.org> Signed-off-by: NThinh Nguyen <Thinh.Nguyen@synopsys.com> Link: https://lore.kernel.org/r/05b4a5fbfbd0863fc9b1d7af934a366219e3d0b4.1635204761.git.Thinh.Nguyen@synopsys.comSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: NChen Jun <chenjun102@huawei.com> Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>
-
由 Thinh Nguyen 提交于
stable inclusion from stable-v5.10.83 commit 3abf746e800b56077fabb3f128afa5929ea94eb9 bugzilla: 185879 https://gitee.com/openeuler/kernel/issues/I4QUVG Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=3abf746e800b56077fabb3f128afa5929ea94eb9 -------------------------------- commit d74dc3e9 upstream. The End Transfer command from a stream endpoint will generate a NoStream event, and we should ignore it. Currently we set the flag DWC3_EP_IGNORE_NEXT_NOSTREAM to track this prior to sending the command, and it will be cleared on the next stream event. However, a stream event may be generated before the End Transfer command completion and prematurely clear the flag. Fix this by setting the flag on End Transfer completion instead. Fixes: 140ca4cf ("usb: dwc3: gadget: Handle stream transfers") Cc: <stable@vger.kernel.org> Signed-off-by: NThinh Nguyen <Thinh.Nguyen@synopsys.com> Link: https://lore.kernel.org/r/cee1253af4c3600edb878d11c9c08b040817ae23.1635203975.git.Thinh.Nguyen@synopsys.comSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: NChen Jun <chenjun102@huawei.com> Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>
-
- 19 10月, 2021 2 次提交
-
-
由 Wesley Cheng 提交于
mainline inclusion from mainline-5.10.62 commit 01da7c1dc4cfc3332351037b12adcc8bb355095b bugzilla: 182217 https://gitee.com/openeuler/kernel/issues/I4EFOS Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=01da7c1dc4cfc3332351037b12adcc8bb355095b -------------------------------- commit 4a1e25c0 upstream. During a USB cable disconnect, or soft disconnect scenario, a pending SETUP transaction may not be completed, leading to the following error: dwc3 a600000.dwc3: timed out waiting for SETUP phase If this occurs, then the entire pullup disable routine is skipped and proper cleanup and halting of the controller does not complete. Instead of returning an error (which is ignored from the UDC perspective), allow the pullup disable routine to continue, which will also handle disabling of EP0/1. This will end any active transfers as well. Ensure to clear any delayed_status also, as the timeout could happen within the STATUS stage. Fixes: bb014736 ("usb: dwc3: gadget: don't clear RUN/STOP when it's invalid to do so") Cc: <stable@vger.kernel.org> Reviewed-by: NThinh Nguyen <Thinh.Nguyen@synopsys.com> Acked-by: NFelipe Balbi <balbi@kernel.org> Signed-off-by: NWesley Cheng <wcheng@codeaurora.org> Link: https://lore.kernel.org/r/20210825042855.7977-1-wcheng@codeaurora.orgSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: NChen Jun <chenjun102@huawei.com> Acked-by: NWeilong Chen <chenweilong@huawei.com> Signed-off-by: NChen Jun <chenjun102@huawei.com> Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>
-
由 Thinh Nguyen 提交于
mainline inclusion from mainline-5.10.62 commit 87b2016493eb72659a154fe2cfe4cd14dd4a1661 bugzilla: 182217 https://gitee.com/openeuler/kernel/issues/I4EFOS Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=87b2016493eb72659a154fe2cfe4cd14dd4a1661 -------------------------------- commit 51f1954a upstream. We can't depend on the TRB's HWO bit to determine if the TRB ring is "full". A TRB is only available when the driver had processed it, not when the controller consumed and relinquished the TRB's ownership to the driver. Otherwise, the driver may overwrite unprocessed TRBs. This can happen when many transfer events accumulate and the system is slow to process them and/or when there are too many small requests. If a request is in the started_list, that means there is one or more unprocessed TRBs remained. Check this instead of the TRB's HWO bit whether the TRB ring is full. Fixes: c4233573 ("usb: dwc3: gadget: prepare TRBs on update transfers too") Cc: <stable@vger.kernel.org> Acked-by: NFelipe Balbi <balbi@kernel.org> Signed-off-by: NThinh Nguyen <Thinh.Nguyen@synopsys.com> Link: https://lore.kernel.org/r/e91e975affb0d0d02770686afc3a5b9eb84409f6.1629335416.git.Thinh.Nguyen@synopsys.comSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: NChen Jun <chenjun102@huawei.com> Acked-by: NWeilong Chen <chenweilong@huawei.com> Signed-off-by: NChen Jun <chenjun102@huawei.com> Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>
-
- 15 10月, 2021 1 次提交
-
-
由 Wesley Cheng 提交于
stable inclusion from stable-5.10.58 commit 98c83d72614e47ed67d6b42dc4884fcf3a5be627 bugzilla: 176984 https://gitee.com/openeuler/kernel/issues/I4E2P4 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=98c83d72614e47ed67d6b42dc4884fcf3a5be627 -------------------------------- commit cb10f68a upstream. If the device is already in the runtime suspended state, any call to the pullup routine will issue a runtime resume on the DWC3 core device. If the USB gadget is disabling the pullup, then avoid having to issue a runtime resume, as DWC3 gadget has already been halted/stopped. This fixes an issue where the following condition occurs: usb_gadget_remove_driver() -->usb_gadget_disconnect() -->dwc3_gadget_pullup(0) -->pm_runtime_get_sync() -> ret = 0 -->pm_runtime_put() [async] -->usb_gadget_udc_stop() -->dwc3_gadget_stop() -->dwc->gadget_driver = NULL ... dwc3_suspend_common() -->dwc3_gadget_suspend() -->DWC3 halt/stop routine skipped, driver_data == NULL This leads to a situation where the DWC3 gadget is not properly stopped, as the runtime resume would have re-enabled EP0 and event interrupts, and since we avoided the DWC3 gadget suspend, these resources were never disabled. Fixes: 77adb8bd ("usb: dwc3: gadget: Allow runtime suspend if UDC unbinded") Cc: stable <stable@vger.kernel.org> Acked-by: NFelipe Balbi <balbi@kernel.org> Signed-off-by: NWesley Cheng <wcheng@codeaurora.org> Link: https://lore.kernel.org/r/1628058245-30692-1-git-send-email-wcheng@codeaurora.orgSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: NChen Jun <chenjun102@huawei.com> Acked-by: NWeilong Chen <chenweilong@huawei.com> Signed-off-by: NChen Jun <chenjun102@huawei.com> Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>
-
- 06 7月, 2021 1 次提交
-
-
由 Jack Pham 提交于
stable inclusion from stable-5.10.46 commit e52d43c82f2f6556f0b7a790c19c072c1e99a95f bugzilla: 168323 CVE: NA -------------------------------- commit 8d396bb0 upstream. 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: 41ce1456 ("usb: dwc3: core: make dwc3_set_mode() work properly") Cc: stable <stable@vger.kernel.org> Reviewed-by: NPeter Chen <peter.chen@kernel.org> Signed-off-by: NJack Pham <jackp@codeaurora.org> Link: https://lore.kernel.org/r/20210529192932.22912-1-jackp@codeaurora.orgSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: NChen Jun <chenjun102@huawei.com> Acked-by: NWeilong Chen <chenweilong@huawei.com> Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>
-
- 03 7月, 2021 2 次提交
-
-
由 Wesley Cheng 提交于
stable inclusion from stable-5.10.44 commit 9e0677c2e39052ac20efae4474bb20614d9a88c9 bugzilla: 109295 CVE: NA -------------------------------- commit 82129373 upstream. Current sequence utilizes dwc3_gadget_disable_irq() alongside synchronize_irq() to ensure that no further DWC3 events are generated. However, the dwc3_gadget_disable_irq() API only disables device specific events. Endpoint events can still be generated. Briefly disable the interrupt line, so that the cleanup code can run to prevent device and endpoint events. (i.e. __dwc3_gadget_stop() and dwc3_stop_active_transfers() respectively) Without doing so, it can lead to both the interrupt handler and the pullup disable routine both writing to the GEVNTCOUNT register, which will cause an incorrect count being read from future interrupts. Fixes: ae7e8610 ("usb: dwc3: Stop active transfers before halting the controller") Signed-off-by: NWesley Cheng <wcheng@codeaurora.org> Link: https://lore.kernel.org/r/1621571037-1424-1-git-send-email-wcheng@codeaurora.orgSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: NChen Jun <chenjun102@huawei.com> Acked-by: NWeilong Chen <chenweilong@huawei.com> Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>
-
由 Jack Pham 提交于
stable inclusion from stable-5.10.44 commit 851dee5a5da56564a70290713aee665403bb0b24 bugzilla: 109295 CVE: NA -------------------------------- commit 03715ea2 upstream. There exists a possible scenario in which dwc3_gadget_init() can fail: during during host -> peripheral mode switch in dwc3_set_mode(), and a pending gadget driver fails to bind. Then, if the DRD undergoes another mode switch from peripheral->host the resulting dwc3_gadget_exit() will attempt to reference an invalid and dangling dwc->gadget pointer as well as call dma_free_coherent() on unmapped DMA pointers. The exact scenario can be reproduced as follows: - Start DWC3 in peripheral mode - Configure ConfigFS gadget with FunctionFS instance (or use g_ffs) - Run FunctionFS userspace application (open EPs, write descriptors, etc) - Bind gadget driver to DWC3's UDC - Switch DWC3 to host mode => dwc3_gadget_exit() is called. usb_del_gadget() will put the ConfigFS driver instance on the gadget_driver_pending_list - Stop FunctionFS application (closes the ep files) - Switch DWC3 to peripheral mode => dwc3_gadget_init() fails as usb_add_gadget() calls check_pending_gadget_drivers() and attempts to rebind the UDC to the ConfigFS gadget but fails with -19 (-ENODEV) because the FFS instance is not in FFS_ACTIVE state (userspace has not re-opened and written the descriptors yet, i.e. desc_ready!=0). - Switch DWC3 back to host mode => dwc3_gadget_exit() is called again, but this time dwc->gadget is invalid. Although it can be argued that userspace should take responsibility for ensuring that the FunctionFS application be ready prior to allowing the composite driver bind to the UDC, failure to do so should not result in a panic from the kernel driver. Fix this by setting dwc->gadget to NULL in the failure path of dwc3_gadget_init() and add a check to dwc3_gadget_exit() to bail out unless the gadget pointer is valid. Fixes: e81a7018 ("usb: dwc3: allocate gadget structure dynamically") Cc: <stable@vger.kernel.org> Reviewed-by: NPeter Chen <peter.chen@kernel.org> Signed-off-by: NJack Pham <jackp@codeaurora.org> Link: https://lore.kernel.org/r/20210528160405.17550-1-jackp@codeaurora.orgSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: NChen Jun <chenjun102@huawei.com> Acked-by: NWeilong Chen <chenweilong@huawei.com> Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>
-
- 15 6月, 2021 1 次提交
-
-
由 Thinh Nguyen 提交于
stable inclusion from stable-5.10.42 commit adccf17982628ed82eabd915799104ca4fcd4a76 bugzilla: 55093 CVE: NA -------------------------------- commit 25dda9fc upstream. The driver incorrectly uses req->num_pending_sgs to track both the number of pending and queued SG entries. It only prepares the next request if the previous is done, and it doesn't update num_pending_sgs until there is TRB completion interrupt. This may starve the controller of more TRBs until the num_pending_sgs is decremented. Fix this by decrementing the num_pending_sgs after they are queued and properly track both num_mapped_sgs and num_queued_sgs. Fixes: c96e6725 ("usb: dwc3: gadget: Correct the logic for queuing sgs") Cc: <stable@vger.kernel.org> Reported-by: NMichael Grzeschik <m.grzeschik@pengutronix.de> Tested-by: NMichael Grzeschik <m.grzeschik@pengutronix.de> Acked-by: NFelipe Balbi <balbi@kernel.org> Signed-off-by: NThinh Nguyen <Thinh.Nguyen@synopsys.com> Link: https://lore.kernel.org/r/ba24591dbcaad8f244a3e88bd449bb7205a5aec3.1620874069.git.Thinh.Nguyen@synopsys.comSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: NChen Jun <chenjun102@huawei.com> Acked-by: NWeilong Chen <chenweilong@huawei.com> Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>
-
- 03 6月, 2021 7 次提交
-
-
由 Wesley Cheng 提交于
stable inclusion from stable-5.10.38 commit 9bd96a2e77fd71b39bfa3f710f6001f94da57c51 bugzilla: 51875 CVE: NA -------------------------------- commit 18ffa988 upstream. If an error is received when issuing a start or update transfer command, the error handler will stop all active requests (including the current USB request), and call dwc3_gadget_giveback() to notify function drivers of the requests which have been stopped. Avoid returning an error for kick transfer during EP queue, to remove duplicate cleanup operations on the request being queued. Fixes: 8d99087c ("usb: dwc3: gadget: Properly handle failed kick_transfer") cc: stable@vger.kernel.org Signed-off-by: NWesley Cheng <wcheng@codeaurora.org> Link: https://lore.kernel.org/r/1620410119-24971-1-git-send-email-wcheng@codeaurora.orgSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: NChen Jun <chenjun102@huawei.com> Acked-by: NWeilong Chen <chenweilong@huawei.com> Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>
-
由 Jack Pham 提交于
stable inclusion from stable-5.10.38 commit 45f37f54e7c16e2981ba3a847c0778fd561888c3 bugzilla: 51875 CVE: NA -------------------------------- commit d1d90dd2 upstream. commit 72704f87 ("dwc3: gadget: Implement the suspend entry event handler") introduced (nearly 5 years ago!) an interrupt handler for U3/L1-L2 suspend events. The problem is that these events aren't currently enabled in the DEVTEN register so the handler is never even invoked. Fix this simply by enabling the corresponding bit in dwc3_gadget_enable_irq() using the same revision check as found in the handler. Fixes: 72704f87 ("dwc3: gadget: Implement the suspend entry event handler") Acked-by: NFelipe Balbi <balbi@kernel.org> Signed-off-by: NJack Pham <jackp@codeaurora.org> Cc: stable <stable@vger.kernel.org> Link: https://lore.kernel.org/r/20210428090111.3370-1-jackp@codeaurora.orgSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: NChen Jun <chenjun102@huawei.com> Acked-by: NWeilong Chen <chenweilong@huawei.com> Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>
-
由 Jack Pham 提交于
stable inclusion from stable-5.10.38 commit 1ea775021282d90e1d08d696b7ab54aa75d688e5 bugzilla: 51875 CVE: NA -------------------------------- [ Upstream commit bb9c74a5 ] As part of commit e81a7018 ("usb: dwc3: allocate gadget structure dynamically") the dwc3_gadget_release() was added which will free the dwc->gadget structure upon the device's removal when usb_del_gadget_udc() is called in dwc3_gadget_exit(). However, simply freeing the gadget results a dangling pointer situation: the endpoints created in dwc3_gadget_init_endpoints() have their dep->endpoint.ep_list members chained off the list_head anchored at dwc->gadget->ep_list. Thus when dwc->gadget is freed, the first dwc3_ep in the list now has a dangling prev pointer and likewise for the next pointer of the dwc3_ep at the tail of the list. The dwc3_gadget_free_endpoints() that follows will result in a use-after-free when it calls list_del(). This was caught by enabling KASAN and performing a driver unbind. The recent commit 568262bf ("usb: dwc3: core: Add shutdown callback for dwc3") also exposes this as a panic during shutdown. There are a few possibilities to fix this. One could be to perform a list_del() of the gadget->ep_list itself which removes it from the rest of the dwc3_ep chain. Another approach is what this patch does, by splitting up the usb_del_gadget_udc() call into its separate "del" and "put" components. This allows dwc3_gadget_free_endpoints() to be called before the gadget is finally freed with usb_put_gadget(). Fixes: e81a7018 ("usb: dwc3: allocate gadget structure dynamically") Reviewed-by: NPeter Chen <peter.chen@kernel.org> Signed-off-by: NJack Pham <jackp@codeaurora.org> Link: https://lore.kernel.org/r/20210501093558.7375-1-jackp@codeaurora.orgSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: NSasha Levin <sashal@kernel.org> Signed-off-by: NChen Jun <chenjun102@huawei.com> Acked-by: NWeilong Chen <chenweilong@huawei.com> Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>
-
由 Thinh Nguyen 提交于
stable inclusion from stable-5.10.36 commit b624b32584ac44f4f7e0c53878b22da7cea6f2e4 bugzilla: 51867 CVE: NA -------------------------------- commit c560e763 upstream. The START_TRANSFER command needs to be executed while in ON/U0 link state (with an exception during register initialization). Don't use dwc->link_state to check this since the driver only tracks the link state when the link state change interrupt is enabled. Check the link state from DSTS register instead. Note that often the host already brings the device out of low power before it sends/requests the next transfer. So, the user won't see any issue when the device starts transfer then. This issue is more noticeable in cases when the device delays starting transfer, which can happen during delayed control status after the host put the device in low power. Fixes: 799e9dc8 ("usb: dwc3: gadget: conditionally disable Link State change events") Cc: <stable@vger.kernel.org> Acked-by: NFelipe Balbi <balbi@kernel.org> Signed-off-by: NThinh Nguyen <Thinh.Nguyen@synopsys.com> Link: https://lore.kernel.org/r/bcefaa9ecbc3e1936858c0baa14de6612960e909.1618884221.git.Thinh.Nguyen@synopsys.comSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: NChen Jun <chenjun102@huawei.com> Acked-by: NWeilong Chen <chenweilong@huawei.com> Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>
-
由 Thinh Nguyen 提交于
stable inclusion from stable-5.10.36 commit f9ddfaa9703c5c0efff8b828bb45a0612d5bf466 bugzilla: 51867 CVE: NA -------------------------------- commit 3232a3ce upstream. The programming guide incorrectly stated that the DCFG.bInterval_m1 must be set to 0 when operating in fullspeed. There's no such limitation for all IPs. See DWC_usb3x programming guide section 3.2.2.1. Fixes: a1679af8 ("usb: dwc3: gadget: Fix setting of DEPCFG.bInterval_m1") Cc: <stable@vger.kernel.org> Acked-by: NFelipe Balbi <balbi@kernel.org> Signed-off-by: NThinh Nguyen <Thinh.Nguyen@synopsys.com> Link: https://lore.kernel.org/r/5d4139ae89d810eb0a2d8577fb096fc88e87bfab.1618472454.git.Thinh.Nguyen@synopsys.comSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: NChen Jun <chenjun102@huawei.com> Acked-by: NWeilong Chen <chenweilong@huawei.com> Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>
-
由 Thinh Nguyen 提交于
stable inclusion from stable-5.10.36 commit 8f7cdbbf61f9282a2d8fe6ef870c5eab4edb3ed0 bugzilla: 51867 CVE: NA -------------------------------- [ Upstream commit 475e8be5 ] If the device doesn't support LPM, make sure to disable the LPM capability and don't advertise to the host that it supports it. Acked-by: NFelipe Balbi <balbi@kernel.org> Signed-off-by: NThinh Nguyen <Thinh.Nguyen@synopsys.com> Link: https://lore.kernel.org/r/9e68527ff932b1646f92a7593d4092a903754666.1618366071.git.Thinh.Nguyen@synopsys.comSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: NSasha Levin <sashal@kernel.org> Signed-off-by: NChen Jun <chenjun102@huawei.com> Acked-by: NWeilong Chen <chenweilong@huawei.com> Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>
-
由 Wesley Cheng 提交于
stable inclusion from stable-5.10.36 commit 45f879b29da717e289b2bca84d7af03e91ebcc13 bugzilla: 51867 CVE: NA -------------------------------- [ Upstream commit 71ca43f3 ] The current dwc3_gadget_reset_interrupt() will stop any active transfers, but only addresses blocking of EP queuing for while we are coming from a disconnected scenario, i.e. after receiving the disconnect event. If the host decides to issue a bus reset on the device, the connected parameter will still be set to true, allowing for EP queuing to continue while we are disabling the functions. To avoid this, set the connected flag to false until the stop active transfers is complete. Signed-off-by: NWesley Cheng <wcheng@codeaurora.org> Link: https://lore.kernel.org/r/1616146285-19149-3-git-send-email-wcheng@codeaurora.orgSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: NSasha Levin <sashal@kernel.org> Signed-off-by: NChen Jun <chenjun102@huawei.com> Acked-by: NWeilong Chen <chenweilong@huawei.com> Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>
-
- 22 4月, 2021 1 次提交
-
-
由 Wesley Cheng 提交于
stable inclusion from stable-5.10.28 commit 996a5782faef8f2903e64fdf23feb3893156e94b bugzilla: 51779 -------------------------------- commit 5aef6297 upstream. Ensure that dep->flags are cleared until after stop active transfers is completed. Otherwise, the ENDXFER command will not be executed during ep disable. Fixes: f09ddcfc ("usb: dwc3: gadget: Prevent EP queuing while stopping transfers") Cc: stable <stable@vger.kernel.org> Reported-and-tested-by: NAndy Shevchenko <andy.shevchenko@gmail.com> Tested-by: NMarek Szyprowski <m.szyprowski@samsung.com> Signed-off-by: NWesley Cheng <wcheng@codeaurora.org> Link: https://lore.kernel.org/r/1616610664-16495-1-git-send-email-wcheng@codeaurora.orgSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: NChen Jun <chenjun102@huawei.com> Acked-by: N Weilong Chen <chenweilong@huawei.com> Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>
-
- 13 4月, 2021 2 次提交
-
-
由 Wesley Cheng 提交于
stable inclusion from stable-5.10.26 commit c7bb96a37dd2095fcd6c65a59689004e63e4b872 bugzilla: 51363 -------------------------------- commit f09ddcfc upstream. In the situations where the DWC3 gadget stops active transfers, once calling the dwc3_gadget_giveback(), there is a chance where a function driver can queue a new USB request in between the time where the dwc3 lock has been released and re-aquired. This occurs after we've already issued an ENDXFER command. When the stop active transfers continues to remove USB requests from all dep lists, the newly added request will also be removed, while controller still has an active TRB for it. This can lead to the controller accessing an unmapped memory address. Fix this by ensuring parameters to prevent EP queuing are set before calling the stop active transfers API. Fixes: ae7e8610 ("usb: dwc3: Stop active transfers before halting the controller") Signed-off-by: NWesley Cheng <wcheng@codeaurora.org> Link: https://lore.kernel.org/r/1615507142-23097-1-git-send-email-wcheng@codeaurora.org Cc: stable <stable@vger.kernel.org> Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: NChen Jun <chenjun102@huawei.com> Acked-by: N Weilong Chen <chenweilong@huawei.com> Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>
-
由 Wesley Cheng 提交于
stable inclusion from stable-5.10.26 commit 395d273f29980f658ac0087019661325aa777344 bugzilla: 51363 -------------------------------- commit 77adb8bd upstream. The DWC3 runtime suspend routine checks for the USB connected parameter to determine if the controller can enter into a low power state. The connected state is only set to false after receiving a disconnect event. However, in the case of a device initiated disconnect (i.e. UDC unbind), the controller is halted and a disconnect event is never generated. Set the connected flag to false if issuing a device initiated disconnect to allow the controller to be suspended. Signed-off-by: NWesley Cheng <wcheng@codeaurora.org> Link: https://lore.kernel.org/r/1609283136-22140-2-git-send-email-wcheng@codeaurora.orgSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: NChen Jun <chenjun102@huawei.com> Acked-by: N Weilong Chen <chenweilong@huawei.com> Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>
-
- 09 4月, 2021 2 次提交
-
-
由 Thinh Nguyen 提交于
stable inclusion from stable-5.10.20 commit 5b4cd967876269bfce36b0ec22a846882224b7e9 bugzilla: 50608 -------------------------------- commit 4b049f55 upstream. The dep->interval captures the number of frames/microframes per interval from bInterval. Fullspeed interrupt endpoint bInterval is the number of frames per interval and not 2^(bInterval - 1). So fix it here. This change is only for debugging purpose and should not affect the interrupt endpoint operation. Fixes: 72246da4 ("usb: Introduce DesignWare USB3 DRD Driver") Cc: <stable@vger.kernel.org> Signed-off-by: NThinh Nguyen <Thinh.Nguyen@synopsys.com> Link: https://lore.kernel.org/r/1263b563dedc4ab8b0fb854fba06ce4bc56bd495.1612820995.git.Thinh.Nguyen@synopsys.comSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: NChen Jun <chenjun102@huawei.com> Acked-by: NXie XiuQi <xiexiuqi@huawei.com> Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>
-
由 Thinh Nguyen 提交于
stable inclusion from stable-5.10.20 commit 6b78b380db60e4434931572d7d7943b5976a0fd6 bugzilla: 50608 -------------------------------- commit a1679af8 upstream. Valid range for DEPCFG.bInterval_m1 is from 0 to 13, and it must be set to 0 when the controller operates in full-speed. See the programming guide for DEPCFG command section 3.2.2.1 (v3.30a). Fixes: 72246da4 ("usb: Introduce DesignWare USB3 DRD Driver") Cc: <stable@vger.kernel.org> Signed-off-by: NThinh Nguyen <Thinh.Nguyen@synopsys.com> Link: https://lore.kernel.org/r/3f57026f993c0ce71498dbb06e49b3a47c4d0265.1612820995.git.Thinh.Nguyen@synopsys.comSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: NChen Jun <chenjun102@huawei.com> Acked-by: NXie XiuQi <xiexiuqi@huawei.com> Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>
-
- 27 1月, 2021 2 次提交
-
-
由 Thinh Nguyen 提交于
stable inclusion from stable-5.10.7 commit 8907a10c8ffaaa830358b08f97da55e856e9b093 bugzilla: 47429 -------------------------------- commit a5c7682a upstream. If an active transfer is dequeued, then the endpoint is freed to start a new transfer. Make sure to clear the endpoint's transfer wait flag for this case. Fixes: e0d19563 ("usb: dwc3: gadget: Wait for transfer completion") Cc: stable@vger.kernel.org Acked-by: NFelipe Balbi <balbi@kernel.org> Signed-off-by: NThinh Nguyen <Thinh.Nguyen@synopsys.com> Link: https://lore.kernel.org/r/b81cd5b5281cfbfdadb002c4bcf5c9be7c017cfd.1609828485.git.Thinh.Nguyen@synopsys.comSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: NChen Jun <chenjun102@huawei.com> Acked-by: NXie XiuQi <xiexiuqi@huawei.com>
-
由 Wesley Cheng 提交于
stable inclusion from stable-5.10.7 commit dd8363fbca508616811f8a94006b09c66c094107 bugzilla: 47429 -------------------------------- commit a1383b35 upstream. usb_gadget_deactivate/usb_gadget_activate does not execute the UDC start operation, which may leave EP0 disabled and event IRQs disabled when re-activating the function. Move the enabling/disabling of USB EP0 and device event IRQs to be performed in the pullup routine. Fixes: ae7e8610 ("usb: dwc3: Stop active transfers before halting the controller") Tested-by: NMichael Tretter <m.tretter@pengutronix.de> Cc: stable <stable@vger.kernel.org> Reported-by: NMichael Tretter <m.tretter@pengutronix.de> Signed-off-by: NWesley Cheng <wcheng@codeaurora.org> Link: https://lore.kernel.org/r/1609282837-21666-1-git-send-email-wcheng@codeaurora.orgSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: NChen Jun <chenjun102@huawei.com> Acked-by: NXie XiuQi <xiexiuqi@huawei.com>
-