- 02 Feb, 2023 14 commits
-
-
Daniel Scally authored
The f_uvc code includes an interrupt endpoint against the VideoControl interface. According to section 2.4.2 of the UVC specification however this endpoint is optional in at least some cases: "This endpoint is optional, but may be mandatory under certain conditions" The conditions enumerated are whether... 1. The device supports hardware triggers 2. The device implements any AutoUpdate controls 3. The device implements any Asynchronous controls As all of those things are implementation dependent, this endpoint might be unnecessary for some users. Further to that it is unusable in the current implementation as there is no mechanism within the UVC gadget driver that allows data to be sent over that endpoint. Disable the interrupt endpoint by default, but check whether the user has asked for it to be enabled in configfs and continue to generate it if so. Signed-off-by:
Daniel Scally <dan.scally@ideasonboard.com> Link: https://lore.kernel.org/r/20230130105045.120886-4-dan.scally@ideasonboard.comSigned-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Daniel Scally authored
Add a new attribute to the default control config group that allows users to specify whether they want to enable the optional interrupt endpoint for the VideoControl interface. Signed-off-by:
-
Daniel Scally authored
The f_uvc code defines an endpoint named "uvc_control_ep" but it is configured with a non-zero endpoint address and has its bmAttributes flagged as USB_ENDPOINT_XFER_INT - this cannot be the VideoControl interface's control endpoint, as the default endpoint 0 is used for that purpose. This is instead the optional interrupt endpoint that can be contained by a VideoControl interface. There is also a Class-specific VC Interrupt Endpoint Descriptor and a SuperSpeed companion descriptor that are also for the VC interface's interrupt endpoint but are named as though they are for the control endpoint. Rename the variables to make that clear. Signed-off-by:
-
Jon Hunter authored
Enable the TYPEC UCSI support and the Cypress UCSI driver that is used on the NVIDIA Jetson platforms. Signed-off-by:
Jon Hunter <jonathanh@nvidia.com> Link: https://lore.kernel.org/r/20230131175748.256423-7-jonathanh@nvidia.comSigned-off-by:
-
Wayne Chang authored
Now the Cypress CCG driver has been updated to support the 'firmware-name' property to align with device-tree, remove the 'ccgx,firmware-build' property as this is no longer needed. Signed-off-by:
Wayne Chang <waynec@nvidia.com> Signed-off-by:
Ajay Gupta <ajayg@nvidia.com> Acked-by:
Wolfram Sang <wsa@kernel.org> Link: https://lore.kernel.org/r/20230131175748.256423-5-jonathanh@nvidia.comSigned-off-by:
-
Wayne Chang authored
Add device-tree support for the Cypress CCG UCSI driver. The device-tree binding for the Cypress CCG device uses the standard device-tree 'firmware-name' string property to indicate the firmware build that is used. The NVIDIA GPU I2C driver has been updated to use an ACPI string property that is also named 'firmware-build' and given that this was the only users of the 'ccgx,firmware-build' property, we can now remove support for this legacy property. Signed-off-by:
Heikki Krogerus <heikki.krogerus@linux.intel.com> Link: https://lore.kernel.org/r/20230131175748.256423-4-jonathanh@nvidia.comSigned-off-by:
-
Wayne Chang authored
Device-tree uses the 'firmware-name' string property to pass a name of the firmware build to the Cypress CCGx driver. Add a new ACPI string property to the NVIDIA GPU I2C driver to align with device-tree so that we can migrate to using a common property name for both ACPI and device-tree. Signed-off-by:
-
Wayne Chang authored
Add the device-tree binding documentation for Cypress cypd4226 dual Type-C controller. Signed-off-by:
Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Link: https://lore.kernel.org/r/20230131175748.256423-2-jonathanh@nvidia.comSigned-off-by:
-
Udipto Goswami authored
During enumeration or composition switch,a userspace process agnostic of the conventions of configs can try to create function symlinks even after the UDC is bound to current config which is not correct. Potentially it can create duplicates within the current config. Prevent this by adding a check if udc_name already exists, then bail out of cfg_link. Following is an example: Step1: ln -s X1 ffs.a -->cfg_link --> usb_get_function(ffs.a) ->ffs_alloc CFG->FUNC_LIST: <ffs.a> C->FUNCTION: <empty> Step2: echo udc.name > /config/usb_gadget/g1/UDC --> UDC_store ->composite_bind ->usb_add_function CFG->FUNC_LIST: <empty> C->FUNCTION: <ffs.a> Step3: ln -s Y1 ffs.a -->cfg_link -->usb_get_function(ffs.a) ->ffs_alloc CFG->FUNC_LIST: <ffs.a> C->FUNCTION: <ffs.a> both the lists corresponds to the same function instance ffs.a but the usb_function* pointer is different because in step 3 ffs_alloc has created a new reference to usb_function* for ffs.a and added it to cfg_list. Step4: Now a composition switch involving <ffs.b,ffs.a> is executed. the composition switch will involve 3 things: 1. unlinking the previous functions existing 2. creating new symlinks 3. writing UDC However, the composition switch is generally taken care by userspace process which creates the symlinks in its own nomenclature(X*) and removes only those. So it won't be able to remove Y1 which user had created by own. Due to this the new symlinks cannot be created for ffs.a since the entry already exists in CFG->FUNC_LIST. The state of the CFG->FUNC_LIST is as follows: CFG->FUNC_LIST: <ffs.a> Fixes: 88af8bbe ("usb: gadget: the start of the configfs interface") Signed-off-by:
Krishna Kurapati PSSNV <quic_kriskura@quicinc.com> Signed-off-by:
Udipto Goswami <quic_ugoswami@quicinc.com> Link: https://lore.kernel.org/r/20230201132308.31523-1-quic_ugoswami@quicinc.comSigned-off-by:
-
Andre Przywara authored
Currently the probe routine explicitly compares the compatible string of the device node to figure out which features and quirks a certain Allwinner MUSB model requires. This gets harder to maintain for new SoCs. Add a struct sunxi_musb_cfg that names the features and quirks explicitly, and create instances of this struct for every type of MUSB device we support. Then bind this to the compatible strings via the OF data feature. Signed-off-by:
Andre Przywara <andre.przywara@arm.com> Reviewed-by:
Jernej Skrabec <jernej.skrabec@gmail.com> Link: https://lore.kernel.org/r/20230201105348.1815461-4-andre.przywara@arm.comSigned-off-by:
-
Icenowy Zheng authored
The suniv SoC has a MUSB controller like the one in A33, but with a SRAM region to be claimed. Add support for it. Signed-off-by:
Icenowy Zheng <uwu@icenowy.me> Acked-by:
-
Icenowy Zheng authored
Allwinner F1C100s has a hybrid MUSB controller between the A10 one and the A33 one. Add a compatible string for it. Signed-off-by:
Samuel Holland <samuel@sholland.org> Signed-off-by:
-
Arnd Bergmann authored
The USB_XHCI_RZV2M and USB_RENESAS_USB3 select other drivers based on the enabled SoC types, which leads to build failures when the dependencies are not met: WARNING: unmet direct dependencies detected for USB_RZV2M_USB3DRD Depends on [n]: USB_SUPPORT [=y] && USB_GADGET [=n] && (ARCH_R9A09G011 [=n] || COMPILE_TEST [=y]) Selected by [m]: - USB_XHCI_RZV2M [=m] && USB_SUPPORT [=y] && USB [=y] && USB_XHCI_HCD [=m] && USB_XHCI_PLATFORM [=m] && (ARCH_R9A09G011 [=n] || COMPILE_TEST [=y]) ERROR: modpost: "rzv2m_usb3drd_reset" [drivers/usb/host/xhci-plat-hcd.ko] undefined! The xhci-rcar driver has a reverse dependency with the xhci core, and it depends on the UDC driver in turn. To untangle this, make the xhci-rcar.ko driver a standalone module that just calls into the xhci-plat.ko module like other drivers do. This allows handling the dependency on the USB_RZV2M_USB3DRD driver to only affect the xhci-rcar module and simplify the xhci-plat module. It also allows leaving out the hacks for broken dma mask and nested devices from the rcar side and keep that only in the generic xhci driver. As a future cleanup, the marvell and dwc3 specific bits of xhci-plat.c could be moved out as well, but that is not required for this bugfix. Fixes: c52c9acc ("xhci: host: Add Renesas RZ/V2M SoC support") Signed-off-by:
Arnd Bergmann <arnd@arndb.de> Tested-by:
Biju Das <biju.das.jz@bp.renesas.com> Link: https://lore.kernel.org/r/20230131150531.12347-1-arnd@kernel.orgSigned-off-by:
-
Dan Carpenter authored
This function only calls mtk_otg_switch_init() when the ->port_mode is MUSB_OTG so the clean up code should only call mtk_otg_switch_exit() for that mode. Fixes: 0990366b ("usb: musb: Add support for MediaTek musb controller") Signed-off-by:
Dan Carpenter <error27@gmail.com> Link: https://lore.kernel.org/r/Y8/3TqpqiSr0RxFH@kiliSigned-off-by:
-
- 31 Jan, 2023 23 commits
-
-
Alan Stern authored
Ever since commit 83e83ecb ("usb: core: get config and string descriptors for unauthorized devices") was merged in 2013, there has been no mechanism for reallocating the rawdescriptors buffers in struct usb_device after the initial enumeration. Before that commit, the buffers would be deallocated when a device was deauthorized and reallocated when it was authorized and enumerated. This means that the locking in the read_descriptors() routine is not needed, since the buffers it reads will never be reallocated while the routine is running. This locking can interfere with user programs trying to read a hub's descriptors via sysfs while new child devices of the hub are being initialized, since the hub is locked during this procedure. Since the locking in read_descriptors() hasn't been needed for over nine years, we can remove it. Reported-and-tested-by:
Troels Liebe Bentsen <troels@connectedcars.dk> Signed-off-by:
Alan Stern <stern@rowland.harvard.edu> CC: stable@vger.kernel.org Link: https://lore.kernel.org/r/Y9l+wDTRbuZABzsE@rowland.harvard.eduSigned-off-by:
-
Christophe JAILLET authored
Instead of zeroing some memory and then copying data in part or all of it, use memcpy_and_pad(). This avoids writing some memory twice and should save a few cycles. Signed-off-by:
Christophe JAILLET <christophe.jaillet@wanadoo.fr> Link: https://lore.kernel.org/r/b447a7e9778d3f9e6997eb9494f1687dc2d5d3bf.1675016180.git.christophe.jaillet@wanadoo.frSigned-off-by:
-
Christophe JAILLET authored
There is no point in zeroing 'buf'. It would be cleared only once, and if the 'while' loop is executed several times, all but the first run would have a 'dirty' buffer. Moreover, the size of the chunk is computed in the loop and this size is passed to xdbc_bulk_write(). So remove this useless memset(). Signed-off-by:
-
Christophe JAILLET authored
If xdbc_bulk_write() fails, the values in 'buf' can be anything. So the string is not guaranteed to be NULL terminated when xdbc_trace() is called. Reserve an extra byte, which will be zeroed automatically because 'buf' is a static variable, in order to avoid troubles, should it happen. Fixes: aeb9dd1d ("usb/early: Add driver for xhci debug capability") Signed-off-by:
-
Fabien Parent authored
Add binding documentation for the MT8365 SoC. Signed-off-by:
Fabien Parent <fparent@baylibre.com> [bero@baylibre.com: Cleanups suggested by reviewers] Signed-off-by:
Bernhard Rosenkränzer <bero@baylibre.com> Acked-by:
AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com> Reviewed-by:
Matthias Brugger <matthias.bgg@gmail.com> Reviewed-by:
Chunfeng Yun <chunfeng.yun@mediatek.com> Link: https://lore.kernel.org/r/20230125143503.1015424-7-bero@baylibre.comSigned-off-by:
-
Fabien Parent authored
Add binding documentation for the MT8365 SoC. Signed-off-by:
-
Alexander Stein authored
Add error message if finding USB PHY fails or is deferred. Signed-off-by:
Alexander Stein <alexander.stein@ew.tq-group.com> Link: https://lore.kernel.org/r/20230130094151.95174-1-alexander.stein@ew.tq-group.comSigned-off-by:
-
Konrad Dybcio authored
Node names should be generic. Change fsa4480@ to typec-mux@. Fixes: 01afa882 ("dt-bindings: usb: Add binding for fcs,fsa4480") Signed-off-by:
Konrad Dybcio <konrad.dybcio@linaro.org> Acked-by:
Rob Herring <robh@kernel.org> Link: https://lore.kernel.org/r/20230130113151.2130063-1-konrad.dybcio@linaro.orgSigned-off-by:
-
Jonathan Neuschäfer authored
Spell it correctly as "specify". Signed-off-by:
Jonathan Neuschäfer <j.neuschaefer@gmx.net> Acked-by:
-
Krzysztof Kozlowski authored
The Samsung Exynos SoC USB 3.0 DWC3 Controller is a simple wrapper of actual DWC3 Controller device node. It handles necessary Samsung Exynos-specific resources (regulators, clocks), but does not have its own MMIO address space. However neither simple-bus bindings nor dtc W=1 accept device nodes in soc@ node which do not have unit address. Signed-off-by:
-
Yang Yingliang authored
devm_platform_get_and_ioremap_resource() never returns NULL pointer, it will return ERR_PTR() when it fails, so replace the check with IS_ERR(). Fixes: baef5330 ("usb: fotg210: Acquire memory resource in core") Signed-off-by:
Yang Yingliang <yangyingliang@huawei.com> Reviewed-by:
Linus Walleij <linus.walleij@linaro.org> Link: https://lore.kernel.org/r/20230130120633.3342285-1-yangyingliang@huawei.comSigned-off-by:
-
Anand Moon authored
Cleanup by removing unneeded quotes from refs and add maxItems to reset-gpios and fix the required list. Fixes: 31360c28 ("dt-bindings: usb: Add binding for Via lab VL817 hub controller") Signed-off-by:
Anand Moon <linux.amoon@gmail.com> Reviewed-by:
-
Mark Tomlinson authored
A USB peripheral can respond with a NAK if it is not yet ready to send/receive data. In this case, the transaction should be retried. The MAX3421 driver did do this, and switched to a different type of retry after a number of 'fast' retries. On at least some USB flash devices, this second type of retry never succeeds. This patch changes the behaviour so that 'fast' retries continue. Signed-off-by:
Mark Tomlinson <mark.tomlinson@alliedtelesis.co.nz> Link: https://lore.kernel.org/r/20230127024734.8777-1-mark.tomlinson@alliedtelesis.co.nzSigned-off-by:
-
Krzysztof Kozlowski authored
Few Qualcomm SoCs require minimum performance level of power domain, so allow it: sm8550-mtp.dtb: usb@a6f8800: 'required-opps' does not match any of the regexes: '^usb@[0-9a-f]+$', 'pinctrl-[0-9]+' Signed-off-by:
Abel Vesa <abel.vesa@linaro.org> Acked-by:
-
Andy Shevchenko authored
Validation has nothing to do with any protected data, move it out of the lock and make code neater. Signed-off-by:
Andy Shevchenko <andriy.shevchenko@linux.intel.com> Link: https://lore.kernel.org/r/20230127112638.84806-1-andriy.shevchenko@linux.intel.comSigned-off-by:
-
Andy Shevchenko authored
We have two types for UUIDs depending on the byte ordering. Instead of explaining how bytes should go over the wire, use dedicated APIs and data types. This removes a confusion over the byte ordering. Signed-off-by:
Jó Ágila Bitsch <jgilab@gmail.com> Link: https://lore.kernel.org/r/20230125143425.85268-1-andriy.shevchenko@linux.intel.comSigned-off-by:
-
Randy Dunlap authored
Correct spelling problems for Documentation/usb/ as reported by codespell. Signed-off-by:
Randy Dunlap <rdunlap@infradead.org> Cc: linux-usb@vger.kernel.org Cc: Jonathan Corbet <corbet@lwn.net> Cc: linux-doc@vger.kernel.org Link: https://lore.kernel.org/r/20230127064005.1558-33-rdunlap@infradead.orgSigned-off-by:
-
Michael Grzeschik authored
Since v4l2_fill_fmtdesc will be called in the ioctl v4l_enum_fmt anyway. We can set the format description and compressed flag from v4l_fill_fmtdesc and can remove the extra name field in uvc_format_desc. Reviewed-by:
Michael Grzeschik <m.grzeschik@pengutronix.de> Reviewed-by:
Laurent Pinchart <laurent.pinchart@ideasonboard.com> Link: https://lore.kernel.org/r/20230126231456.3402323-6-m.grzeschik@pengutronix.deSigned-off-by:
-
Michael Grzeschik authored
Since the uvc_fmts array can not be modified we declare it const and change every user of the uvc_format_by_guid function aswell. Reviewed-by:
-
Michael Grzeschik authored
The media driver USB_VIDEO_CLASS and USB_F_UVC are using the same function uvc_format_by_guid. Since the function is inline, every user will get a copy of the used uvc_fmts array and the function. This patch moves the code to an own compile unit and add this dependency as UVC_COMMON to both users. Reviewed-by:
-
Michael Grzeschik authored
Since the headerfile is only used in usb devices it is better placed with the other usb files. Reviewed-by:
-
Marek Vasut authored
The Cypress EZUSB FX3 UVC example can be configured to report pixel format "e436eb7e-524f-11ce-9f53-0020af0ba770". This is its GUID for BGRA/X 8:8:8:8. The UVC 1.5 spec [1] only defines GUIDs for YUY2, NV12, M420 and I420. This seems to be an extension documented in the Microsoft Windows Media Format SDK[2]. This Media Format SDK defines this GUID as corresponding to `MEDIASUBTYPE_RGB32`, which is confirmed by [4] as `MEDIASUBTYPE_ARGB32` has different GUID. Note that in my case, the FX3 UVC can output either channel order, BGR or RGB or any other mix for that matter. Since Linux commit 1b8dc322 ("[media] uvcvideo: Add GUID for BGR 8:8:8") defined a GUID for `MEDIASUBTYPE_RGB24` channel order as BGR, keep this change consistent and define `MEDIASUBTYPE_RGB32` as BGR as well. Document [3] also indicates the channel order is BGR. [1] https://www.usb.org/document-library/video-class-v15-document-set [2] https://learn.microsoft.com/en-us/windows/win32/wmformat/media-type-identifiers [3] https://learn.microsoft.com/en-us/windows/win32/directshow/uncompressed-rgb-video-subtypes [4] https://gix.github.io/media-types/Signed-off-by:
Marek Vasut <marex@denx.de> Reviewed-by:
Ricardo Ribalda <ricardo@ribalda.com> Signed-off-by:
-
Greg Kroah-Hartman authored
Merge tag 'media-uvc-next-20230115' of git://git.kernel.org/pub/scm/linux/kernel/git/pinchartl/linux into usb-next Merge in this tag from the media tree so that future USB uvc patches will apply properly. Signed-off-by:
-
- 25 Jan, 2023 3 commits
-
-
Biju Das authored
RZ/V2M is similar to R-Car XHCI but it doesn't require any firmware, we need to reset the USB Host reset release in DRD Module before accessing host registers. Signed-off-by:
-
Biju Das authored
Add optional reset support. This is in preparation to adding USB xHCI support for RZ/V2M SoC. Signed-off-by:
Geert Uytterhoeven <geert+renesas@glider.be> Link: https://lore.kernel.org/r/20230121145853.4792-9-biju.das.jz@bp.renesas.comSigned-off-by:
-
Biju Das authored
It is always better to acquire all the clock resources first and then do the clock operations. This patch acquires all the optional clocks first and then calls corresponding prepare_enable(). There is no functional change. Signed-off-by:
-
