kernel/git/stable/linux.git/drivers/usb/host/fotg210-hcd.c, branch master

usb: fotg210: Collect pieces of dual mode controller

2022-11-09T11:38:09+00:00

The Faraday FOTG210 is a dual-mode OTG USB controller that can act as host, peripheral or both. To be able to probe from one hardware description and to follow the pattern of other dual- mode controllers such as MUSB or MTU3 we need to collect the two, currently completely separate drivers in the same directory. After this, users need to select the main symbol USB_FOTG210 and then each respective subdriver. We pave the road to compile both drivers into the same kernel and select the one we want to use at probe() time, and possibly add OTG support in the end. This patch doesn't do much more than create the new symbol and collect the drivers in one place. We also add a comment for the section of dual-mode controllers in the Kconfig file so people can see what these selections are about. Also add myself as maintainer as there has been little response on my patches to these drivers. Cc: Fabian Vogt Cc: Yuan-Hsin Chen Cc: Felipe Balbi Signed-off-by: Linus Walleij Link: https://lore.kernel.org/r/20221023144708.3596563-1-linus.walleij@linaro.org Signed-off-by: Greg Kroah-Hartman

usb: reduce kernel log spam on driver registration

2022-08-31T07:07:53+00:00

Drivers are typically supposed to be quiet unless they are actually probed, but for some reason, USB host controllers seem to be exempt from this rule, and happily broadcast their existence into the kernel log at boot even if the hardware in question is nowhere to be found. Let's fix that, and remove these pr_info() calls. Cc: Alan Stern Cc: Greg Kroah-Hartman Cc: Nicolas Ferre Cc: Alexandre Belloni Cc: Claudiu Beznea Cc: Krzysztof Kozlowski Cc: Alim Akhtar Cc: Avi Fishman Cc: Tomer Maimon Cc: Tali Perry Cc: Patrick Venture Cc: Nancy Yuen Cc: Benjamin Fair Cc: Patrice Chotard Cc: Vladimir Zapolskiy Cc: linux-usb@vger.kernel.org Cc: linux-arm-kernel@lists.infradead.org Cc: linux-kernel@vger.kernel.org Cc: linux-samsung-soc@vger.kernel.org Cc: linux-omap@vger.kernel.org Reviewed-by: Krzysztof Kozlowski Reviewed-by: Rob Herring Reviewed-by: Alim Akhtar Acked-by: Alan Stern Signed-off-by: Ard Biesheuvel Link: https://lore.kernel.org/r/20220825170327.674446-1-ardb@kernel.org Signed-off-by: Greg Kroah-Hartman

usb: remove third argument of usb_maxpacket()

2022-04-23T08:33:53+00:00

The third argument of usb_maxpacket(): in_out has been deprecated because it could be derived from the second argument (e.g. using usb_pipeout(pipe)). N.B. function usb_maxpacket() was made variadic to accommodate the transition from the old prototype with three arguments to the new one with only two arguments (so that no renaming is needed). The variadic argument is to be removed once all users of usb_maxpacket() get migrated. CC: Duncan Sands CC: Alan Stern CC: Olav Kongas CC: Rui Miguel Silva Signed-off-by: Vincent Mailhol Link: https://lore.kernel.org/r/20220317035514.6378-7-mailhol.vincent@wanadoo.fr Signed-off-by: Greg Kroah-Hartman

usb: host: fotg210: Use struct_size() helper in kzalloc()

2022-01-26T13:01:59+00:00

Make use of the struct_size() helper instead of an open-coded version, in order to avoid any potential type mistakes or integer overflows that, in the worst scenario, could lead to heap overflows. Also, address the following sparse warnings: drivers/usb/host/fotg210-hcd.c:4017:20: warning: using sizeof on a flexible structure Link: https://github.com/KSPP/linux/issues/174 Reviewed-by: Kees Cook Signed-off-by: Gustavo A. R. Silva Link: https://lore.kernel.org/r/20220120222043.GA33559@embeddedor Signed-off-by: Greg Kroah-Hartman

usb: host: fotg210: Use platform_get_irq() to get the interrupt

2021-12-21T07:51:57+00:00

platform_get_resource(pdev, IORESOURCE_IRQ, ..) relies on static allocation of IRQ resources in DT core code, this causes an issue when using hierarchical interrupt domains using "interrupts" property in the node as this bypasses the hierarchical setup and messes up the irq chaining. In preparation for removal of static setup of IRQ resource from DT core code use platform_get_irq(). Reviewed-by: Geert Uytterhoeven Signed-off-by: Lad Prabhakar Link: https://lore.kernel.org/r/20211220010411.12075-2-prabhakar.mahadev-lad.rj@bp.renesas.com Signed-off-by: Greg Kroah-Hartman

usb: host: fotg210: Make use of dma_pool_zalloc() instead of dma_pool_alloc/memset()

2021-10-21T10:47:55+00:00

Replacing dma_pool_alloc/memset() with dma_pool_zalloc() to simplify the code. Signed-off-by: Cai Huoqing Link: https://lore.kernel.org/r/20211018131709.487-1-caihuoqing@baidu.com Signed-off-by: Greg Kroah-Hartman

usb: host: fotg210: Fix a function name in comments

2021-10-05T10:44:56+00:00

Use dma_map_single() instead of pci_map_single(), because only dma_map_single() is called here. Signed-off-by: Cai Huoqing Link: https://lore.kernel.org/r/20210925124920.1564-2-caihuoqing@baidu.com Signed-off-by: Greg Kroah-Hartman

usb: host: fotg210: fix the actual_length of an iso packet

2021-07-21T08:03:42+00:00

We should acquire the actual_length of an iso packet from the iTD directly using FOTG210_ITD_LENGTH() macro. Signed-off-by: Kelly Devilliv Link: https://lore.kernel.org/r/20210627125747.127646-4-kelly.devilliv@gmail.com Signed-off-by: Greg Kroah-Hartman

usb: host: fotg210: fix the endpoint's transactional opportunities calculation

2021-07-21T08:03:42+00:00

Now that usb_endpoint_maxp() only returns the lowest 11 bits from wMaxPacketSize, we should make use of the usb_endpoint_* helpers instead and remove the unnecessary max_packet()/hb_mult() macro. Signed-off-by: Kelly Devilliv Link: https://lore.kernel.org/r/20210627125747.127646-3-kelly.devilliv@gmail.com Signed-off-by: Greg Kroah-Hartman

Revert "usb: host: fotg210: Use dma_pool_zalloc"

2021-07-21T08:03:42+00:00

This reverts commit cb6a0db8fdc12433ed4281331de0c3923dc2807b for the same reason as commit 43b78f1155c868208a413082179251f5fba78153 in the ehci-hcd driver. Alan writes: What you can't see just from reading the patch is that in both cases (ehci->itd_pool and ehci->sitd_pool) there are two allocation paths -- the two branches of an "if" statement -- and only one of the paths calls dma_pool_[z]alloc. However, the memset is needed for both paths, and so it can't be eliminated. Given that it must be present, there's no advantage to calling dma_pool_zalloc rather than dma_pool_alloc. Signed-off-by: Kelly Devilliv Link: https://lore.kernel.org/r/20210627125747.127646-2-kelly.devilliv@gmail.com Signed-off-by: Greg Kroah-Hartman