summaryrefslogtreecommitdiff
AgeCommit message (Collapse)AuthorFilesLines
2022-03-15usb: gadget: udc-xilinx: remove usage of list iterator past the loop bodyJakob Koschel1-5/+8
If the list representing the request queue does not contain the expected request, the value of the list_for_each_entry() iterator will not point to a valid structure. To avoid type confusion in such case, the list iterator scope will be limited to the list_for_each_entry() loop. In preparation to limiting scope of the list iterator to the list traversal loop, use a dedicated pointer to point to the found request object [1]. Link: https://lore.kernel.org/all/YhdfEIwI4EdtHdym@kroah.com/ Signed-off-by: Jakob Koschel <jakobkoschel@gmail.com> Link: https://lore.kernel.org/r/20220308171818.384491-16-jakobkoschel@gmail.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2022-03-15usb: gadget: s3c-hsudc: remove usage of list iterator past the loop bodyJakob Koschel1-5/+7
If the list representing the request queue does not contain the expected request, the value of the list_for_each_entry() iterator will not point to a valid structure. To avoid type confusion in such case, the list iterator scope will be limited to the list_for_each_entry() loop. In preparation to limiting scope of the list iterator to the list traversal loop, use a dedicated pointer to point to the found request object [1]. Link: https://lore.kernel.org/all/YhdfEIwI4EdtHdym@kroah.com/ Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@canonical.com> Signed-off-by: Jakob Koschel <jakobkoschel@gmail.com> Link: https://lore.kernel.org/r/20220308171818.384491-15-jakobkoschel@gmail.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2022-03-15usb: gadget: omap_udc: remove usage of list iterator past the loop bodyJakob Koschel1-5/+7
If the list representing the request queue does not contain the expected request, the value of the list_for_each_entry() iterator will not point to a valid structure. To avoid type confusion in such case, the list iterator scope will be limited to the list_for_each_entry() loop. In preparation to limiting scope of the list iterator to the list traversal loop, use a dedicated pointer to point to the found request object [1]. Link: https://lore.kernel.org/all/YhdfEIwI4EdtHdym@kroah.com/ Signed-off-by: Jakob Koschel <jakobkoschel@gmail.com> Link: https://lore.kernel.org/r/20220308171818.384491-14-jakobkoschel@gmail.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2022-03-15usb: gadget: udc: net2280: remove usage of list iterator past the loop bodyJakob Koschel1-5/+8
If the list representing the request queue does not contain the expected request, the value of the list_for_each_entry() iterator will not point to a valid structure. To avoid type confusion in such case, the list iterator scope will be limited to the list_for_each_entry() loop. In preparation to limiting scope of the list iterator to the list traversal loop, use a dedicated pointer to point to the found request object [1]. Link: https://lore.kernel.org/all/YhdfEIwI4EdtHdym@kroah.com/ Signed-off-by: Jakob Koschel <jakobkoschel@gmail.com> Link: https://lore.kernel.org/r/20220308171818.384491-13-jakobkoschel@gmail.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2022-03-15usb: gadget: net2272: remove usage of list iterator past the loop bodyJakob Koschel1-6/+7
If the list representing the request queue does not contain the expected request, the value of the list_for_each_entry() iterator will not point to a valid structure. To avoid type confusion in such case, the list iterator scope will be limited to the list_for_each_entry() loop. In preparation to limiting scope of the list iterator to the list traversal loop, use a dedicated pointer to point to the found request object [1]. Link: https://lore.kernel.org/all/YhdfEIwI4EdtHdym@kroah.com/ Signed-off-by: Jakob Koschel <jakobkoschel@gmail.com> Link: https://lore.kernel.org/r/20220308171818.384491-12-jakobkoschel@gmail.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2022-03-15usb: gadget: udc: mv_udc_core: remove usage of list iterator past the loop bodyJakob Koschel1-5/+7
If the list representing the request queue does not contain the expected request, the value of the list_for_each_entry() iterator will not point to a valid structure. To avoid type confusion in such case, the list iterator scope will be limited to the list_for_each_entry() loop. In preparation to limiting scope of the list iterator to the list traversal loop, use a dedicated pointer to point to the found request object [1]. Link: https://lore.kernel.org/all/YhdfEIwI4EdtHdym@kroah.com/ Signed-off-by: Jakob Koschel <jakobkoschel@gmail.com> Link: https://lore.kernel.org/r/20220308171818.384491-11-jakobkoschel@gmail.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2022-03-15usb: gadget: mv_u3d: remove usage of list iterator past the loop bodyJakob Koschel1-5/+7
If the list representing the request queue does not contain the expected request, the value of the list_for_each_entry() iterator will not point to a valid structure. To avoid type confusion in such case, the list iterator scope will be limited to the list_for_each_entry() loop. In preparation to limiting scope of the list iterator to the list traversal loop, use a dedicated pointer to point to the found request object [1]. Link: https://lore.kernel.org/all/YhdfEIwI4EdtHdym@kroah.com/ Signed-off-by: Jakob Koschel <jakobkoschel@gmail.com> Link: https://lore.kernel.org/r/20220308171818.384491-10-jakobkoschel@gmail.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2022-03-15usb: gadget: lpc32xx_udc: remove usage of list iterator past the loop bodyJakob Koschel1-5/+7
If the list representing the request queue does not contain the expected request, the value of the list_for_each_entry() iterator will not point to a valid structure. To avoid type confusion in such case, the list iterator scope will be limited to the list_for_each_entry() loop. In preparation to limiting scope of the list iterator to the list traversal loop, use a dedicated pointer to point to the found request object [1]. Link: https://lore.kernel.org/all/YhdfEIwI4EdtHdym@kroah.com/ Signed-off-by: Jakob Koschel <jakobkoschel@gmail.com> Link: https://lore.kernel.org/r/20220308171818.384491-9-jakobkoschel@gmail.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2022-03-15usb: gadget: udc: gr_udc: remove usage of list iterator past the loop bodyJakob Koschel1-5/+7
If the list representing the request queue does not contain the expected request, the value of the list_for_each_entry() iterator will not point to a valid structure. To avoid type confusion in such case, the list iterator scope will be limited to the list_for_each_entry() loop. In preparation to limiting scope of the list iterator to the list traversal loop, use a dedicated pointer to point to the found request object [1]. Link: https://lore.kernel.org/all/YhdfEIwI4EdtHdym@kroah.com/ Signed-off-by: Jakob Koschel <jakobkoschel@gmail.com> Link: https://lore.kernel.org/r/20220308171818.384491-8-jakobkoschel@gmail.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2022-03-15usb: gadget: goku_udc: remove usage of list iterator past the loop bodyJakob Koschel1-5/+7
If the list representing the request queue does not contain the expected request, the value of the list_for_each_entry() iterator will not point to a valid structure. To avoid type confusion in such case, the list iterator scope will be limited to the list_for_each_entry() loop. In preparation to limiting scope of the list iterator to the list traversal loop, use a dedicated pointer to point to the found request object [1]. Link: https://lore.kernel.org/all/YhdfEIwI4EdtHdym@kroah.com/ Signed-off-by: Jakob Koschel <jakobkoschel@gmail.com> Link: https://lore.kernel.org/r/20220308171818.384491-7-jakobkoschel@gmail.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2022-03-15usb: gadget: udc: at91: remove usage of list iterator past the loop bodyJakob Koschel1-5/+7
If the list representing the request queue does not contain the expected request, the value of the list_for_each_entry() iterator will not point to a valid structure. To avoid type confusion in such case, the list iterator scope will be limited to the list_for_each_entry() loop. In preparation to limiting scope of the list iterator to the list traversal loop, use a dedicated pointer to point to the found request object [1]. Link: https://lore.kernel.org/all/YhdfEIwI4EdtHdym@kroah.com/ Signed-off-by: Jakob Koschel <jakobkoschel@gmail.com> Link: https://lore.kernel.org/r/20220308171818.384491-6-jakobkoschel@gmail.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2022-03-15usb: gadget: udc: pxa25x: remove usage of list iterator past the loop bodyJakob Koschel1-5/+8
If the list representing the request queue does not contain the expected request, the value of the list_for_each_entry() iterator will not point to a valid structure. To avoid type confusion in such case, the list iterator scope will be limited to the list_for_each_entry() loop. In preparation to limiting scope of the list iterator to the list traversal loop, use a dedicated pointer to point to the found request object [1]. Link: https://lore.kernel.org/all/YhdfEIwI4EdtHdym@kroah.com/ Signed-off-by: Jakob Koschel <jakobkoschel@gmail.com> Link: https://lore.kernel.org/r/20220308171818.384491-5-jakobkoschel@gmail.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2022-03-15usb: gadget: udc: atmel: remove usage of list iterator past the loop bodyJakob Koschel1-5/+8
If the list representing the request queue does not contain the expected request, the value of the list_for_each_entry() iterator will not point to a valid structure. To avoid type confusion in such case, the list iterator scope will be limited to the list_for_each_entry() loop. In preparation to limiting scope of the list iterator to the list traversal loop, use a dedicated pointer to point to the found request object [1]. Link: https://lore.kernel.org/all/YhdfEIwI4EdtHdym@kroah.com/ Signed-off-by: Jakob Koschel <jakobkoschel@gmail.com> Link: https://lore.kernel.org/r/20220308171818.384491-4-jakobkoschel@gmail.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2022-03-15usb: gadget: bdc: remove usage of list iterator past the loop bodyJakob Koschel1-4/+9
If the list representing the request queue does not contain the expected request, the value of the list_for_each_entry() iterator will not point to a valid structure. To avoid type confusion in such case, the list iterator scope will be limited to the list_for_each_entry() loop. In preparation to limiting scope of the list iterator to the list traversal loop, use a dedicated pointer to point to the found request object [1]. Link: https://lore.kernel.org/all/YhdfEIwI4EdtHdym@kroah.com/ Signed-off-by: Jakob Koschel <jakobkoschel@gmail.com> Link: https://lore.kernel.org/r/20220308171818.384491-3-jakobkoschel@gmail.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2022-03-15usb: gadget: fsl: remove usage of list iterator past the loop bodyJakob Koschel2-10/+16
If the list representing the request queue does not contain the expected request, the value of the list_for_each_entry() iterator will not point to a valid structure. To avoid type confusion in such case, the list iterator scope will be limited to the list_for_each_entry() loop. In preparation to limiting scope of the list iterator to the list traversal loop, use a dedicated pointer to point to the found request object [1]. Link: https://lore.kernel.org/all/YhdfEIwI4EdtHdym@kroah.com/ Signed-off-by: Jakob Koschel <jakobkoschel@gmail.com> Link: https://lore.kernel.org/r/20220308171818.384491-2-jakobkoschel@gmail.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2022-03-15usb: dwc3: pci: Add support for Intel Alder LakeShruthi Sanil1-0/+4
Add the PCI device ID and update the dwc3_pci_id_table for Intel Alder Lake SoC. The DWC3 controllor in the CPU block handles the USB3 traffic and the device ID is common across the Alder Lake platforms. Reviewed-by: Heikki Krogerus <heikki.krogerus@linux.intel.com> Signed-off-by: Shruthi Sanil <shruthi.sanil@intel.com> Link: https://lore.kernel.org/r/20220308170848.30722-1-shruthi.sanil@intel.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2022-03-15usb: dwc3: omap: fix "unbalanced disables for smps10_out1" on omap5evmH. Nikolaus Schaller1-1/+1
Usually, the vbus_regulator (smps10 on omap5evm) boots up disabled. Hence calling regulator_disable() indirectly through dwc3_omap_set_mailbox() during probe leads to: [ 10.332764] WARNING: CPU: 0 PID: 1628 at drivers/regulator/core.c:2853 _regulator_disable+0x40/0x164 [ 10.351919] unbalanced disables for smps10_out1 [ 10.361298] Modules linked in: dwc3_omap(+) clk_twl6040 at24 gpio_twl6040 palmas_gpadc palmas_pwrbutton industrialio snd_soc_omap_mcbsp(+) snd_soc_ti_sdma display_connector ti_tpd12s015 drm leds_gpio drm_panel_orientation_quirks ip_tables x_tables ipv6 autofs4 [ 10.387818] CPU: 0 PID: 1628 Comm: systemd-udevd Not tainted 5.17.0-rc1-letux-lpae+ #8139 [ 10.405129] Hardware name: Generic OMAP5 (Flattened Device Tree) [ 10.411455] unwind_backtrace from show_stack+0x10/0x14 [ 10.416970] show_stack from dump_stack_lvl+0x40/0x4c [ 10.422313] dump_stack_lvl from __warn+0xb8/0x170 [ 10.427377] __warn from warn_slowpath_fmt+0x70/0x9c [ 10.432595] warn_slowpath_fmt from _regulator_disable+0x40/0x164 [ 10.439037] _regulator_disable from regulator_disable+0x30/0x64 [ 10.445382] regulator_disable from dwc3_omap_set_mailbox+0x8c/0xf0 [dwc3_omap] [ 10.453116] dwc3_omap_set_mailbox [dwc3_omap] from dwc3_omap_probe+0x2b8/0x394 [dwc3_omap] [ 10.467021] dwc3_omap_probe [dwc3_omap] from platform_probe+0x58/0xa8 [ 10.481762] platform_probe from really_probe+0x168/0x2fc [ 10.481782] really_probe from __driver_probe_device+0xc4/0xd8 [ 10.481782] __driver_probe_device from driver_probe_device+0x24/0xa4 [ 10.503762] driver_probe_device from __driver_attach+0xc4/0xd8 [ 10.510018] __driver_attach from bus_for_each_dev+0x64/0xa0 [ 10.516001] bus_for_each_dev from bus_add_driver+0x148/0x1a4 [ 10.524880] bus_add_driver from driver_register+0xb4/0xf8 [ 10.530678] driver_register from do_one_initcall+0x90/0x1c4 [ 10.536661] do_one_initcall from do_init_module+0x4c/0x200 [ 10.536683] do_init_module from load_module+0x13dc/0x1910 [ 10.551159] load_module from sys_finit_module+0xc8/0xd8 [ 10.561319] sys_finit_module from __sys_trace_return+0x0/0x18 [ 10.561336] Exception stack(0xc344bfa8 to 0xc344bff0) [ 10.561341] bfa0: b6fb5778 b6fab8d8 00000007 b6ecfbb8 00000000 b6ed0398 [ 10.561341] bfc0: b6fb5778 b6fab8d8 855c0500 0000017b 00020000 b6f9a3cc 00000000 b6fb5778 [ 10.595500] bfe0: bede18f8 bede18e8 b6ec9aeb b6dda1c2 [ 10.601345] ---[ end trace 0000000000000000 ]--- Fix this unnecessary warning by checking if the regulator is enabled. Signed-off-by: H. Nikolaus Schaller <hns@goldelico.com> Link: https://lore.kernel.org/r/af3b750dc2265d875deaabcf5f80098c9645da45.1646744616.git.hns@goldelico.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2022-03-15usb: dwc3: gadget: Give some time to schedule isocThinh Nguyen1-1/+7
Currently the driver will schedule isoc transfers immediately on the next interval, which is quite aggressive when the interval is 125us. There's report that some platforms may need more time to process the transfer, otherwise the controller may miss the first interval. Let's keep it simple and give the controller at least 500us to schedule the isoc transfer. Link: https://lore.kernel.org/linux-usb/20220302143539.GI11577@pengutronix.de/ Tested-by: Michael Grzeschik <m.grzeschik@pengutronix.de> Signed-off-by: Thinh Nguyen <Thinh.Nguyen@synopsys.com> Link: https://lore.kernel.org/r/deb8146b8e1f7f8495ef2d5647017270934cb2d8.1646708142.git.Thinh.Nguyen@synopsys.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2022-03-15usb: dwc3: core: do not use 3.0 clock when operating in 2.0 modeBin Yang2-0/+6
In the 3.0 device core, if the core is programmed to operate in 2.0 only, then setting the GUCTL1.DEV_FORCE_20_CLK_FOR_30_CLK makes the internal 2.0(utmi/ulpi) clock to be routed as the 3.0 (pipe) clock. Enabling this feature allows the pipe3 clock to be not-running when forcibly operating in 2.0 device mode. Tested-by: Michael Riesch <michael.riesch@wolfvision.net> Signed-off-by: Bin Yang <yangbin@rock-chips.com> Signed-off-by: Peter Geis <pgwipeout@gmail.com> Link: https://lore.kernel.org/r/20220228135700.1089526-6-pgwipeout@gmail.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2022-03-15dt-bindings: usb: add rk3568 compatible to rockchip, dwc3Michael Riesch1-0/+2
Add the compatible for the Rockchip RK3568 variant. Tested-by: Michael Riesch <michael.riesch@wolfvision.net> Signed-off-by: Michael Riesch <michael.riesch@wolfvision.net> Link: https://lore.kernel.org/r/20220228135700.1089526-4-pgwipeout@gmail.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2022-03-15arm64: dts: imx8mp: Add memory for USB3 glue layer to usb3 nodesAlexander Stein1-2/+4
The USB3 glue layer has 2 areas in the register set, see RM Rev.1 section 11.2.5.2.1 GLUE_usb3 memory map: * USB3 control/status * PHY control/status Provide the memory area to the usb3 nodes for accessing the features in the USB3 control area. Reviewed-by: Li Jun <jun.li@nxp.com> Signed-off-by: Alexander Stein <alexander.stein@ew.tq-group.com> Link: https://lore.kernel.org/r/20220218152707.2198357-5-alexander.stein@ew.tq-group.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2022-03-15usb: dwc3: imx8mp: Add support for setting SOC specific flagsAlexander Stein1-0/+63
The i.MX8MP glue layer has support for the following flags: * over-current polarity * PWR pad polarity * controlling PPC flag in HCCPARAMS register * permanent port attach for usb2 & usb3 port Allow setting these flags by supporting specific flags in the glue node. In order to get this to work an additional IORESOURCE_MEM and clock is necessary. For backward compatibility this is purely optional. Signed-off-by: Alexander Stein <alexander.stein@ew.tq-group.com> Link: https://lore.kernel.org/r/20220218152707.2198357-4-alexander.stein@ew.tq-group.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2022-03-15dt-bindings: usb: dwc3-imx8mp: Add imx8mp specific flagsAlexander Stein1-4/+27
This adds bindings for features in the USB glue block. They allow setting polarity of PWR and OC as well as disabling port power control. Also permanently attached can be annotated as well. Additional IO address and clock are needed. Reviewed-by: Rob Herring <robh@kernel.org> Signed-off-by: Alexander Stein <alexander.stein@ew.tq-group.com> Link: https://lore.kernel.org/r/20220218152707.2198357-3-alexander.stein@ew.tq-group.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2022-03-15usb: dwc3: imx8mp: rename iomem base pointerAlexander Stein1-8/+8
Until now the iomem used is not USB glue as the name suggests, but HSIO BLK_CTL. Rename the struct member accordingly. This is a preparing patch for when USB glue is actually used. Reviewed-by: Li Jun <jun.li@nxp.com> Signed-off-by: Alexander Stein <alexander.stein@ew.tq-group.com> Link: https://lore.kernel.org/r/20220218152707.2198357-2-alexander.stein@ew.tq-group.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2022-03-15Revert "arm64: dts: qcom: sc7280: Add EUD dt node and dwc3 connector"Souradeep Chowdhury1-36/+0
This reverts commit a0c68e493007a8c72b6b00f6ac95590a86edc937. Revert all the changes to add the Embedded USB Debugger(EUD) Node in the device tree, the connector node and also changes to usb2 Node associated with this.The changes need to be reverted as DT changes for QCOM should go through the QCOM tree and not the USB tree. Signed-off-by: Souradeep Chowdhury <quic_schowdhu@quicinc.com> Link: https://lore.kernel.org/r/8c863e7e76003511dff36383b518ab66d2dd6552.1645793187.git.quic_schowdhu@quicinc.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2022-03-15Revert "arm64: dts: qcom: sc7280: Set the default dr_mode for usb2"Souradeep Chowdhury1-4/+0
This reverts commit c18553956f34819e224a79c9890eba2ba0604e15. Revert the change to set dr_mode for usb2 in case of Embedded USB Debugger(EUD). This change needs to be reverted as the DT changes for QCOM should go through the QCOM tree and not the USB tree. Signed-off-by: Souradeep Chowdhury <quic_schowdhu@quicinc.com> Link: https://lore.kernel.org/r/87008876afb33d8e1b7fd78d2fd5b6d9ec343d7d.1645793187.git.quic_schowdhu@quicinc.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2022-03-15usb: dwc3-meson-g12a: constify drvdata structsHeiner Kallweit1-5/+5
Constify the drvdata structs. This also matches the definition of member drvdata in dwc3_meson_g12a. Reviewed-by: Neil Armstrong <narmstrong@baylibre.com> Signed-off-by: Heiner Kallweit <hkallweit1@gmail.com> Link: https://lore.kernel.org/r/a3c178c9-7c33-d7b8-9f6e-734dc28728ab@gmail.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2022-03-15usb: raw-gadget: return -EINVAL if no proper ep address availableWei Ming Chen1-4/+11
If we try to use raw_ioctl_ep_enable() for ep5in on a hardware that only support from ep1-ep4 for both in and out direction, it will return -EBUSY originally. I think it will be more intuitive if we return -EINVAL, because -EBUSY sounds like ep5in is not available now, but might be available in the future. Reviewed-by: Andrey Konovalov <andreyknvl@gmail.com> Signed-off-by: Wei Ming Chen <jj251510319013@gmail.com> Link: https://lore.kernel.org/r/20220311082944.4881-1-jj251510319013@gmail.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2022-03-15dt-bindings: usb: hcd: correct usb-device pathKrzysztof Kozlowski1-1/+1
The usb-device.yaml reference is absolute so it should use /schemas part in path. Fixes: 23bf6fc7046c ("dt-bindings: usb: convert usb-device.txt to YAML schema") Cc: <stable@vger.kernel.org> Reported-by: Rob Herring <robh@kernel.org> Acked-by: Rob Herring <robh@kernel.org> Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@canonical.com> Link: https://lore.kernel.org/r/20220314181830.245853-1-krzysztof.kozlowski@canonical.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2022-03-15usb: raw-gadget: use kzallocJulia Lawall1-2/+1
Use kzalloc instead of kmalloc + memset. The semantic patch that makes this change is: (https://coccinelle.gitlabpages.inria.fr/website/) //<smpl> @@ expression res, size, flag; @@ - res = kmalloc(size, flag); + res = kzalloc(size, flag); ... - memset(res, 0, size); //</smpl> Signed-off-by: Julia Lawall <Julia.Lawall@inria.fr> Link: https://lore.kernel.org/r/20220312102705.71413-7-Julia.Lawall@inria.fr Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2022-03-15usb: gadget: udc: fix typos in commentsJulia Lawall1-1/+1
Various spelling mistakes in comments. Detected with the help of Coccinelle. Signed-off-by: Julia Lawall <Julia.Lawall@inria.fr> Link: https://lore.kernel.org/r/20220314115354.144023-12-Julia.Lawall@inria.fr Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2022-03-11Merge tag 'thunderbolt-for-v5.18-rc1' of ↵Greg Kroah-Hartman9-40/+265
git://git.kernel.org/pub/scm/linux/kernel/git/westeri/thunderbolt into usb-next Mika writes: thunderbolt: Changes for v5.18 merge window This includes following Thunderbolt/USB4 changes for the v5.18 merge window: * Improvements for Intel Alpine and Titan Ridge support * Replace acpi_bus_get_device() with acpi_fetch_acpi_dev() * Improvements around DROM handling on AMD hardware * A couple of cleanups. All these have been in linux-next with no reported issues. * tag 'thunderbolt-for-v5.18-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/westeri/thunderbolt: thunderbolt: Rename EEPROM handling bits to match USB4 spec thunderbolt: Clarify register definitions for `tb_cap_plug_events` thunderbolt: Do not make DROM read success compulsory thunderbolt: Do not resume routers if UID is not set thunderbolt: Retry DROM reads for more failure scenarios thunderbolt: Replace acpi_bus_get_device() thunderbolt: Add internal xHCI connect flows for Thunderbolt 3 devices thunderbolt: Add missing device ID to tb_switch_is_alpine_ridge() thunderbolt: Disable LTTPR on Intel Titan Ridge thunderbolt: Remove useless DMA-32 fallback configuration
2022-03-11Merge tag 'usb-serial-5.18-rc1' of ↵Greg Kroah-Hartman5-1/+13
https://git.kernel.org/pub/scm/linux/kernel/git/johan/usb-serial into usb-next Johan writes: USB-serial updates for 5.18-rc1 Here are the USB-serial updates for 5.18-rc1, including: - a new "simple driver" for some Nokia phones - a fix for pl2303 GS type detection - another pl2303 device id Included is also a clean up. All have been in linux-next with no reported issues. * tag 'usb-serial-5.18-rc1' of https://git.kernel.org/pub/scm/linux/kernel/git/johan/usb-serial: USB: serial: usb_wwan: remove redundant assignment to variable i USB: serial: pl2303: fix GS type detection USB: serial: pl2303: add IBM device IDs USB: serial: simple: add Nokia phone driver
2022-03-08USB: serial: usb_wwan: remove redundant assignment to variable iColin Ian King1-1/+0
Variable i is being assigned a value that is never read, it is being re-assigned two statements later in a for-loop. The assignment is redundant and can be removed. Cleans up clang scan build warning: drivers/usb/serial/usb_wwan.c:151:2: warning: Value stored to 'i' is never read [deadcode.DeadStores] Signed-off-by: Colin Ian King <colin.i.king@gmail.com> Signed-off-by: Johan Hovold <johan@kernel.org>
2022-03-07USB: serial: pl2303: fix GS type detectionJohan Hovold1-0/+1
At least some PL2303GS have a bcdDevice of 0x605 instead of 0x100 as the datasheet claims. Add it to the list of known release numbers for the HXN (G) type. Fixes: 894758d0571d ("USB: serial: pl2303: tighten type HXN (G) detection") Reported-by: Matyáš Kroupa <kroupa.matyas@gmail.com> Link: https://lore.kernel.org/r/165de6a0-43e9-092c-2916-66b115c7fbf4@gmail.com Cc: stable@vger.kernel.org # 5.13 Signed-off-by: Johan Hovold <johan@kernel.org>
2022-03-04thunderbolt: Rename EEPROM handling bits to match USB4 specMario Limonciello2-17/+17
The structure `tb_eeprom_ctl` is used to show the bits accessed when reading/writing EEPROM. As this structure is specified in the USB4 spec as `VSC_CS_4` update the names and use of members to match the specification. This should not change anything functionally. Signed-off-by: Mario Limonciello <mario.limonciello@amd.com> Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
2022-03-04thunderbolt: Clarify register definitions for `tb_cap_plug_events`Mario Limonciello1-7/+11
The USB4 1.0 specification outlines the `cap_plug_events` structure as `VSC_CS_1`. This shows that 4 bits of `VSC_CS_1` are TBT3 compatible in USB4, but TBT3 controllers also support disabling XHCI. Update the names and comments to more closely match the specification. This should not change anything functionally. Signed-off-by: Mario Limonciello <mario.limonciello@amd.com> Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
2022-03-04thunderbolt: Do not make DROM read success compulsoryMario Limonciello1-4/+2
The USB4 specification doesn't make any requirements that reading a device router's DROM is needed for the operation of the device. Other connection manager solutions don't necessarily read it or gate the usability of the device on whether it was read. So make failures when reading the DROM show warnings but not fail the initialization of the router. Signed-off-by: Mario Limonciello <mario.limonciello@amd.com> Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
2022-03-04thunderbolt: Do not resume routers if UID is not setMario Limonciello1-0/+4
Routers might not have a UID set if the DROM read failed during initialization previously. Normally upon resume the UID is re-read to confirm it's the same device connected. * If the DROM read failed during init but then succeeded during resume it could either be a new device or faulty device * If the DROM read failed during init and also failed during resume it might be a different device plugged in all together. Detect this situation and prevent re-using the same configuration in these cirucmstances. Signed-off-by: Mario Limonciello <mario.limonciello@amd.com> Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
2022-03-04thunderbolt: Retry DROM reads for more failure scenariosMario Limonciello1-7/+10
Currently DROM reads are only retried in the case that parsing failed. However if the size or CRC fails, then there should also be a retry. This helps with reading the DROM on TBT3 devices connected to AMD Yellow Carp which will sometimes fail on the first attempt. Signed-off-by: Mario Limonciello <mario.limonciello@amd.com> Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
2022-03-04USB: serial: pl2303: add IBM device IDsEddie James2-0/+4
IBM manufactures a PL2303 device for UPS communications. Add the vendor and product IDs so that the PL2303 driver binds to the device. Signed-off-by: Eddie James <eajames@linux.ibm.com> Signed-off-by: Joel Stanley <joel@jms.id.au> Signed-off-by: Eddie James <eajames@linux.ibm.com> Link: https://lore.kernel.org/r/20220301224446.21236-1-eajames@linux.ibm.com Cc: stable@vger.kernel.org [ johan: amend the SoB chain ] Signed-off-by: Johan Hovold <johan@kernel.org>
2022-03-03usb: host: xhci: Remove some unnecessary return value initializationsLinyu Yuan1-4/+4
The ret/retval will be set when it used, no need to init at definition. [modified subject line -Mathias] Signed-off-by: Linyu Yuan <quic_linyyuan@quicinc.com> Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com> Link: https://lore.kernel.org/r/20220303110903.1662404-10-mathias.nyman@linux.intel.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2022-03-03usb: host: xhci: add blank line in xhci_halt()Linyu Yuan1-0/+3
It is more readable to add blank lines. Signed-off-by: Linyu Yuan <quic_linyyuan@quicinc.com> Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com> Link: https://lore.kernel.org/r/20220303110903.1662404-9-mathias.nyman@linux.intel.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2022-03-03usb: host: xhci: update hci_version operation in xhci_gen_setup()Linyu Yuan1-2/+1
There is no need to store temperary value in hcc_params. Signed-off-by: Linyu Yuan <quic_linyyuan@quicinc.com> Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com> Link: https://lore.kernel.org/r/20220303110903.1662404-8-mathias.nyman@linux.intel.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2022-03-03usb: host: xhci: fix a comment typo in xhci_mem_init()Linyu Yuan1-1/+1
It should be Device Context, not doorbell. Signed-off-by: Linyu Yuan <quic_linyyuan@quicinc.com> Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com> Link: https://lore.kernel.org/r/20220303110903.1662404-7-mathias.nyman@linux.intel.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2022-03-03usb: host: xhci: use ffs() in xhci_mem_init()Linyu Yuan1-5/+1
The for loop to find page size bit can be replaced with ffs(). Signed-off-by: Linyu Yuan <quic_linyyuan@quicinc.com> Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com> Link: https://lore.kernel.org/r/20220303110903.1662404-6-mathias.nyman@linux.intel.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2022-03-03xhci: fix runtime PM imbalance in USB2 resumeHenry Lin1-0/+3
A race between system resume and device-initiated resume may result in runtime PM imbalance on USB2 root hub. If a device-initiated resume starts and system resume xhci_bus_resume() directs U0 before hub driver sees the resuming device in RESUME state, device-initiated resume will not be finished in xhci_handle_usb2_port_link_resume(). In this case, usb_hcd_end_port_resume() call is missing. This changes calls usb_hcd_end_port_resume() if resuming device reaches U0 to keep runtime PM balance. Fixes: a231ec41e6f6 ("xhci: refactor U0 link state handling in get_port_status") Cc: stable@vger.kernel.org Signed-off-by: Henry Lin <henryl@nvidia.com> Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com> Link: https://lore.kernel.org/r/20220303110903.1662404-5-mathias.nyman@linux.intel.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2022-03-03xhci: fix uninitialized string returned by xhci_decode_ctrl_ctx()Anssi Hannula1-0/+2
xhci_decode_ctrl_ctx() returns the untouched buffer as-is if both "drop" and "add" parameters are zero. Fix the function to return an empty string in that case. It was not immediately clear from the possible call chains whether this issue is currently actually triggerable or not. Note that before commit 4843b4b5ec64 ("xhci: fix even more unsafe memory usage in xhci tracing") the result effect in the failure case was different as a static buffer was used here, but the code still worked incorrectly. Fixes: 90d6d5731da7 ("xhci: Add tracing for input control context") Cc: stable@vger.kernel.org Signed-off-by: Anssi Hannula <anssi.hannula@bitwise.fi> Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com> commit 4843b4b5ec64 ("xhci: fix even more unsafe memory usage in xhci tracing") Link: https://lore.kernel.org/r/20220303110903.1662404-4-mathias.nyman@linux.intel.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2022-03-03xhci: fix garbage USBSTS being logged in some casesAnssi Hannula1-1/+4
xhci_decode_usbsts() is expected to return a zero-terminated string by its only caller, xhci_stop_endpoint_command_watchdog(), which directly logs the return value: xhci_warn(xhci, "USBSTS:%s\n", xhci_decode_usbsts(str, usbsts)); However, if no recognized bits are set in usbsts, the function will return without having called any sprintf() and therefore return an untouched non-zero-terminated caller-provided buffer, causing garbage to be output to log. Fix that by always including the raw value in the output. Note that before commit 4843b4b5ec64 ("xhci: fix even more unsafe memory usage in xhci tracing") the result effect in the failure case was different as a static buffer was used here, but the code still worked incorrectly. Fixes: 9c1aa36efdae ("xhci: Show host status when watchdog triggers and host is assumed dead.") Cc: stable@vger.kernel.org Signed-off-by: Anssi Hannula <anssi.hannula@bitwise.fi> Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com> Link: https://lore.kernel.org/r/20220303110903.1662404-3-mathias.nyman@linux.intel.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2022-03-03xhci: make xhci_handshake timeout for xhci_reset() adjustableMathias Nyman4-15/+16
xhci_reset() timeout was increased from 250ms to 10 seconds in order to give Renesas 720201 xHC enough time to get ready in probe. xhci_reset() is called with interrupts disabled in other places, and waiting for 10 seconds there is not acceptable. Add a timeout parameter to xhci_reset(), and adjust it back to 250ms when called from xhci_stop() or xhci_shutdown() where interrupts are disabled, and successful reset isn't that critical. This solves issues when deactivating host mode on platforms like SM8450. For now don't change the timeout if xHC is reset in xhci_resume(). No issues are reported for it, and we need the reset to succeed. Locking around that reset needs to be revisited later. Additionally change the signed integer timeout parameter in xhci_handshake() to a u64 to match the timeout value we pass to readl_poll_timeout_atomic() Fixes: 22ceac191211 ("xhci: Increase reset timeout for Renesas 720201 host.") Cc: stable@vger.kernel.org Reported-by: Sergey Shtylyov <s.shtylyov@omp.ru> Reported-by: Pavan Kondeti <quic_pkondeti@quicinc.com> Tested-by: Pavan Kondeti <quic_pkondeti@quicinc.com> Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com> Link: https://lore.kernel.org/r/20220303110903.1662404-2-mathias.nyman@linux.intel.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
generated by cgit v1.2.3 (git 2.39.0) at 2024-12-18 16:57:10 +0300