summaryrefslogtreecommitdiffstats
path: root/include/linux/usb.h
Commit message (Collapse)AuthorAgeFilesLines
* Merge 6.2-rc5 into usb-nextGreg Kroah-Hartman2023-01-231-8/+10
|\ | | | | | | | | | | | | | | | | | | | | We need the USB fixes in here and this resolves merge conflicts as reported in linux-next in the following files: drivers/usb/host/xhci.c drivers/usb/host/xhci.h drivers/usb/typec/ucsi/ucsi.c Reported-by: Stephen Rothwell <sfr@canb.auug.org.au> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
| * USB: fix misleading usb_set_intfdata() kernel docJohan Hovold2023-01-171-8/+7
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The struct device driver-data pointer is used for any data that a driver may need in various callbacks while bound to the device. For convenience, subsystems typically provide wrappers such as usb_set_intfdata() of the generic accessor functions for use in bus callbacks. There is generally no longer any need for a driver to clear the pointer, but since commit 0998d0631001 ("device-core: Ensure drvdata = NULL when no driver is bound") the driver-data pointer is set to NULL by driver core post unbind anyway. For historical reasons, USB core also clears this pointer when an explicitly claimed interface is released. Due to a misunderstanding, a misleading kernel doc comment for usb_set_intfdata() was recently added which claimed that the driver data pointer must not be cleared during disconnect before "all actions [are] completed", which is both imprecise and incorrect. Specifically, drivers like cdc-acm which claim additional interfaces use the driver-data pointer as a flag which is cleared when the first interface is unbound. As long as a driver does not do something odd like dereference the pointer in, for example, completion callbacks, this can be done at any time during disconnect. And in any case this is no different than for any other resource, like the driver data itself, which may be freed by the disconnect callback. Note that the comment actually also claimed that the interface itself was somehow being set to NULL by driver core. Fix the kernel doc by removing incorrect, overly specific and misleading details and adding a comment about why some drivers do clear the driver-data pointer. Fixes: 27ef17849779 ("usb: add usb_set_intfdata() documentation") Signed-off-by: Johan Hovold <johan@kernel.org> Acked-by: Alan Stern <stern@rowland.harvard.edu> Acked-by: Vincent Mailhol <mailhol.vincent@wanadoo.fr> Link: https://lore.kernel.org/r/20221212152035.31806-1-johan@kernel.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
| * usb: acpi: add helper to check port lpm capability using acpi _DSMMathias Nyman2023-01-171-0/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Add a helper to evaluate ACPI usb device specific method (_DSM) provided in case the USB3 port shouldn't enter U1 and U2 link states. This _DSM was added as port specific retimer configuration may lead to exit latencies growing beyond U1/U2 exit limits, and OS needs a way to find which ports can't support U1/U2 link power management states. This _DSM is also used by windows: Link: https://docs.microsoft.com/en-us/windows-hardware/drivers/bringup/usb-device-specific-method---dsm- Some patch issues found in testing resolved by Ron Lee Cc: stable@vger.kernel.org Tested-by: Ron Lee <ron.lee@intel.com> Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com> Link: https://lore.kernel.org/r/20230116142216.1141605-7-mathias.nyman@linux.intel.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
* | USB: Improve usb_fill_* documentationRicardo Ribalda2023-01-171-4/+23
|/ | | | | | | | | | | | Document the transfer buffer requirement. That is, the buffer must be DMAble - otherwise data corruption might occur. Acked-by: Randy Dunlap <rdunlap@infradead.org> Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Signed-off-by: Ricardo Ribalda <ribalda@chromium.org> Acked-by: Alan Stern <stern@rowland.harvard.edu> Link: https://lore.kernel.org/r/20221220-usb-dmadoc-v4-0-74a045bf14f4@chromium.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
* Merge tag 'driver-core-6.2-rc1' of ↵Linus Torvalds2022-12-161-4/+15
|\ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/driver-core Pull driver core updates from Greg KH: "Here is the set of driver core and kernfs changes for 6.2-rc1. The "big" change in here is the addition of a new macro, container_of_const() that will preserve the "const-ness" of a pointer passed into it. The "problem" of the current container_of() macro is that if you pass in a "const *", out of it can comes a non-const pointer unless you specifically ask for it. For many usages, we want to preserve the "const" attribute by using the same call. For a specific example, this series changes the kobj_to_dev() macro to use it, allowing it to be used no matter what the const value is. This prevents every subsystem from having to declare 2 different individual macros (i.e. kobj_const_to_dev() and kobj_to_dev()) and having the compiler enforce the const value at build time, which having 2 macros would not do either. The driver for all of this have been discussions with the Rust kernel developers as to how to properly mark driver core, and kobject, objects as being "non-mutable". The changes to the kobject and driver core in this pull request are the result of that, as there are lots of paths where kobjects and device pointers are not modified at all, so marking them as "const" allows the compiler to enforce this. So, a nice side affect of the Rust development effort has been already to clean up the driver core code to be more obvious about object rules. All of this has been bike-shedded in quite a lot of detail on lkml with different names and implementations resulting in the tiny version we have in here, much better than my original proposal. Lots of subsystem maintainers have acked the changes as well. Other than this change, included in here are smaller stuff like: - kernfs fixes and updates to handle lock contention better - vmlinux.lds.h fixes and updates - sysfs and debugfs documentation updates - device property updates All of these have been in the linux-next tree for quite a while with no problems" * tag 'driver-core-6.2-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/driver-core: (58 commits) device property: Fix documentation for fwnode_get_next_parent() firmware_loader: fix up to_fw_sysfs() to preserve const usb.h: take advantage of container_of_const() device.h: move kobj_to_dev() to use container_of_const() container_of: add container_of_const() that preserves const-ness of the pointer driver core: fix up missed drivers/s390/char/hmcdrv_dev.c class.devnode() conversion. driver core: fix up missed scsi/cxlflash class.devnode() conversion. driver core: fix up some missing class.devnode() conversions. driver core: make struct class.devnode() take a const * driver core: make struct class.dev_uevent() take a const * cacheinfo: Remove of_node_put() for fw_token device property: Add a blank line in Kconfig of tests device property: Rename goto label to be more precise device property: Move PROPERTY_ENTRY_BOOL() a bit down device property: Get rid of __PROPERTY_ENTRY_ARRAY_EL*SIZE*() kernfs: fix all kernel-doc warnings and multiple typos driver core: pass a const * into of_device_uevent() kobject: kset_uevent_ops: make name() callback take a const * kobject: kset_uevent_ops: make filter() callback take a const * kobject: make kobject_namespace take a const * ...
| * usb.h: take advantage of container_of_const()Greg Kroah-Hartman2022-12-061-40/+2
| | | | | | | | | | | | | | | | | | | | | | Instead of rolling our own const-checking logic in to_usb_interface() and to_usb_device() use the newly added container_of_const() instead, making the logic much simpler overall. Reviewed-by: Sakari Ailus <sakari.ailus@linux.intel.com> Reviewed-by: Jason Gunthorpe <jgg@nvidia.com> Link: https://lore.kernel.org/r/20221205121206.166576-3-gregkh@linuxfoundation.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
| * USB: make devnode() callback in usb_class_driver take a const *Greg Kroah-Hartman2022-10-201-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | With the changes to the driver core to make more pointers const, the USB subsystem also needs to be modified to take a const * for the devnode callback so that the driver core's constant pointer will also be properly propagated. Cc: Benjamin Tissoires <benjamin.tissoires@redhat.com> Cc: Juergen Stuber <starblue@users.sourceforge.net> Reviewed-by: Johan Hovold <johan@kernel.org> Acked-by: Pete Zaitcev <zaitcev@redhat.com> Reviewed-by: Jiri Kosina <jkosina@suse.cz> Link: https://lore.kernel.org/r/20221001165128.2688526-1-gregkh@linuxfoundation.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
| * USB: allow some usb functions to take a const pointer.Greg Kroah-Hartman2022-10-201-3/+52
| | | | | | | | | | | | | | | | | | | | | | The functions to_usb_interface(), to_usb_device, and interface_to_usbdev() sometimes would like to take a const * and return a const * back. As we are doing pointer math, a call to container_of() loses the const-ness of a pointer, so use a _Generic() macro to pick the proper inline function to call instead. Link: https://lore.kernel.org/r/20221016104155.1260201-1-gregkh@linuxfoundation.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
* | Merge tag 'usb-6.2-rc1' of ↵Linus Torvalds2022-12-161-0/+12
|\ \ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb Pull USB and Thunderbolt driver updates from Greg KH: "Here is the large set of USB and Thunderbolt driver changes for 6.2-rc1. Overall, thanks to the removal of a driver, more lines were removed than added, a nice change. Highlights include: - removal of the sisusbvga driver that was not used by anyone anymore - minor thunderbolt driver changes and tweaks - chipidea driver updates - usual set of typec driver features and hardware support added - musb minor driver fixes - fotg210 driver fixes, bringing that hardware back from the "dead" - minor dwc3 driver updates - addition, and then removal, of a list.h helper function for many USB and other subsystem drivers, that ended up breaking the build. That will come back for 6.3-rc1, it missed this merge window. - usual xhci updates and enhancements - usb-serial driver updates and support for new devices - other minor USB driver updates All of these have been in linux-next for a while with no reported problems" * tag 'usb-6.2-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb: (153 commits) usb: gadget: uvc: Rename bmInterfaceFlags -> bmInterlaceFlags usb: dwc2: power on/off phy for peripheral mode in dual-role mode usb: dwc2: disable lpm feature on Rockchip SoCs dt-bindings: usb: mtk-xhci: add support for mt7986 usb: dwc3: core: defer probe on ulpi_read_id timeout usb: ulpi: defer ulpi_register on ulpi_read_id timeout usb: misc: onboard_usb_hub: add Genesys Logic GL850G hub support dt-bindings: usb: Add binding for Genesys Logic GL850G hub controller dt-bindings: vendor-prefixes: add Genesys Logic usb: fotg210-udc: fix potential memory leak in fotg210_udc_probe() usb: typec: tipd: Set mode of operation for USB Type-C connector usb: gadget: udc: drop obsolete dependencies on COMPILE_TEST usb: musb: remove extra check in musb_gadget_vbus_draw usb: gadget: uvc: Prevent buffer overflow in setup handler usb: dwc3: qcom: Fix memory leak in dwc3_qcom_interconnect_init usb: typec: wusb3801: fix fwnode refcount leak in wusb3801_probe() usb: storage: Add check for kcalloc USB: sisusbvga: use module_usb_driver() USB: sisusbvga: rename sisusb.c to sisusbvga.c USB: sisusbvga: remove console support ...
| * | usb: add usb_set_intfdata() documentationVincent Mailhol2022-11-291-0/+12
| |/ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | USB drivers do not need to call usb_set_intfdata(intf, NULL) in their usb_driver::disconnect callback because the core already does it in [1]. However, this fact is widely unknown, c.f.: $ git grep "usb_set_intfdata(.*NULL)" | wc -l 215 Especially, setting the interface to NULL before all action completed can result in a NULL pointer dereference. Not calling usb_set_intfdata() at all in disconnect() is the safest method. Add documentation to usb_set_intfdata() to clarify this point. Also remove the call in usb-skeletion's disconnect() not to confuse the new comers. [1] function usb_unbind_interface() from drivers/usb/core/driver.c Link: https://elixir.bootlin.com/linux/v6.0/source/drivers/usb/core/driver.c#L497 Signed-off-by: Vincent Mailhol <mailhol.vincent@wanadoo.fr> Link: https://lore.kernel.org/r/20221128102954.3615579-1-mailhol.vincent@wanadoo.fr Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
* / USB: core: export usb_cache_string()Vincent Mailhol2022-12-121-0/+1
|/ | | | | | | | | usb_cache_string() can also be useful for the drivers so export it. Signed-off-by: Vincent Mailhol <mailhol.vincent@wanadoo.fr> Acked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Link: https://lore.kernel.org/all/20221130174658.29282-4-mailhol.vincent@wanadoo.fr Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
* USB: core: Prevent nested device-reset callsAlan Stern2022-08-301-0/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Automatic kernel fuzzing revealed a recursive locking violation in usb-storage: ============================================ WARNING: possible recursive locking detected 5.18.0 #3 Not tainted -------------------------------------------- kworker/1:3/1205 is trying to acquire lock: ffff888018638db8 (&us_interface_key[i]){+.+.}-{3:3}, at: usb_stor_pre_reset+0x35/0x40 drivers/usb/storage/usb.c:230 but task is already holding lock: ffff888018638db8 (&us_interface_key[i]){+.+.}-{3:3}, at: usb_stor_pre_reset+0x35/0x40 drivers/usb/storage/usb.c:230 ... stack backtrace: CPU: 1 PID: 1205 Comm: kworker/1:3 Not tainted 5.18.0 #3 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.13.0-1ubuntu1.1 04/01/2014 Workqueue: usb_hub_wq hub_event Call Trace: <TASK> __dump_stack lib/dump_stack.c:88 [inline] dump_stack_lvl+0xcd/0x134 lib/dump_stack.c:106 print_deadlock_bug kernel/locking/lockdep.c:2988 [inline] check_deadlock kernel/locking/lockdep.c:3031 [inline] validate_chain kernel/locking/lockdep.c:3816 [inline] __lock_acquire.cold+0x152/0x3ca kernel/locking/lockdep.c:5053 lock_acquire kernel/locking/lockdep.c:5665 [inline] lock_acquire+0x1ab/0x520 kernel/locking/lockdep.c:5630 __mutex_lock_common kernel/locking/mutex.c:603 [inline] __mutex_lock+0x14f/0x1610 kernel/locking/mutex.c:747 usb_stor_pre_reset+0x35/0x40 drivers/usb/storage/usb.c:230 usb_reset_device+0x37d/0x9a0 drivers/usb/core/hub.c:6109 r871xu_dev_remove+0x21a/0x270 drivers/staging/rtl8712/usb_intf.c:622 usb_unbind_interface+0x1bd/0x890 drivers/usb/core/driver.c:458 device_remove drivers/base/dd.c:545 [inline] device_remove+0x11f/0x170 drivers/base/dd.c:537 __device_release_driver drivers/base/dd.c:1222 [inline] device_release_driver_internal+0x1a7/0x2f0 drivers/base/dd.c:1248 usb_driver_release_interface+0x102/0x180 drivers/usb/core/driver.c:627 usb_forced_unbind_intf+0x4d/0xa0 drivers/usb/core/driver.c:1118 usb_reset_device+0x39b/0x9a0 drivers/usb/core/hub.c:6114 This turned out not to be an error in usb-storage but rather a nested device reset attempt. That is, as the rtl8712 driver was being unbound from a composite device in preparation for an unrelated USB reset (that driver does not have pre_reset or post_reset callbacks), its ->remove routine called usb_reset_device() -- thus nesting one reset call within another. Performing a reset as part of disconnect processing is a questionable practice at best. However, the bug report points out that the USB core does not have any protection against nested resets. Adding a reset_in_progress flag and testing it will prevent such errors in the future. Link: https://lore.kernel.org/all/CAB7eexKUpvX-JNiLzhXBDWgfg2T9e9_0Tw4HQ6keN==voRbP0g@mail.gmail.com/ Cc: stable@vger.kernel.org Reported-and-tested-by: Rondreis <linhaoguo86@gmail.com> Signed-off-by: Alan Stern <stern@rowland.harvard.edu> Link: https://lore.kernel.org/r/YwkflDxvg0KWqyZK@rowland.harvard.edu Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
* usb: Avoid extra usb SET_SEL requests when enabling link power managementMathias Nyman2022-06-121-0/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | The host needs to tell the device the exit latencies using the SET_SEL request before device initiated link powermanagement can be enabled. The exit latency values do not change after enumeration, it's enough to set them once. So do like Windows 10 and issue the SET_SEL request once just before setting the configuration. This is also the sequence described in USB 3.2 specs "9.1.2 Bus enumeration". SET_SEL is issued once before the Set Configuration request, and won't be cleared by the Set Configuration, Set Interface or ClearFeature (STALL) requests. Only warm reset, hot reset, set Address 0 clears the exit latencies. See USB 3.2 section 9.4.14 Table 9-10 Device parameters and events Add udev->lpm_devinit_allow, and set it if SET_SEL was successful. If not set, then don't try to enable device initiated LPM We used to issue a SET_SEL request every time lpm is enabled for either U1 or U2 link states, meaning a SET_SEL was issued twice after every Set Configuration and Set Interface requests, easily accumulating to over 15 SET_SEL requets during a USB3 webcam enumeration. Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com> Link: https://lore.kernel.org/r/20220506161807.3369439-1-mathias.nyman@linux.intel.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
* usb: rework usb_maxpacket() using usb_pipe_endpoint()Vincent Mailhol2022-04-231-7/+1
| | | | | | | | | | Rework the body of usb_maxpacket() and just rely on the usb_pipe_endpoint() helper function to retrieve the host endpoint instead of doing it by hand. Signed-off-by: Vincent Mailhol <mailhol.vincent@wanadoo.fr> Link: https://lore.kernel.org/r/20220317035514.6378-10-mailhol.vincent@wanadoo.fr Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
* usb: remove third argument of usb_maxpacket()Vincent Mailhol2022-04-231-2/+1
| | | | | | | | | | Now that all users of usb_maxpacket() have been migrated to only use two arguments, remove the third variadic argument which was introduced for the transition. Signed-off-by: Vincent Mailhol <mailhol.vincent@wanadoo.fr> Link: https://lore.kernel.org/r/20220317035514.6378-9-mailhol.vincent@wanadoo.fr Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
* usb: deprecate the third argument of usb_maxpacket()Vincent Mailhol2022-04-231-11/+5
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This is a transitional patch with the ultimate goal of changing the prototype of usb_maxpacket() from: | static inline __u16 | usb_maxpacket(struct usb_device *udev, int pipe, int is_out) into: | static inline u16 usb_maxpacket(struct usb_device *udev, int pipe) The third argument of usb_maxpacket(): is_out gets removed because it can be derived from its second argument: pipe using usb_pipeout(pipe). Furthermore, in the current version, ubs_pipeout(pipe) is called regardless in order to sanitize the is_out parameter. In order to make a smooth change, we first deprecate the is_out parameter by simply ignoring it (using a variadic function) and will remove it later, once all the callers get updated. The body of the function is reworked accordingly and is_out is replaced by usb_pipeout(pipe). The WARN_ON() calls become unnecessary and get removed. Finally, the return type is changed from __u16 to u16 because this is not a UAPI function. Signed-off-by: Vincent Mailhol <mailhol.vincent@wanadoo.fr> Link: https://lore.kernel.org/r/20220317035514.6378-2-mailhol.vincent@wanadoo.fr Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
* usb: Remove usb_for_each_port()Heikki Krogerus2021-12-301-9/+0
| | | | | | | | | | There are no more users for the function. Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Acked-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Signed-off-by: Heikki Krogerus <heikki.krogerus@linux.intel.com> Link: https://lore.kernel.org/r/20211223082432.45653-1-heikki.krogerus@linux.intel.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
* driver core: Move the "removable" attribute from USB to coreRajat Jain2021-05-271-7/+0
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Move the "removable" attribute from USB to core in order to allow it to be supported by other subsystem / buses. Individual buses that want to support this attribute can populate the removable property of the device while enumerating it with the 3 possible values - - "unknown" - "fixed" - "removable" Leaving the field unchanged (i.e. "not supported") would mean that the attribute would not show up in sysfs for that device. The UAPI (location, symantics etc) for the attribute remains unchanged. Move the "removable" attribute from USB to the device core so it can be used by other subsystems / buses. By default, devices do not have a "removable" attribute in sysfs. If a subsystem or bus driver wants to support a "removable" attribute, it should call device_set_removable() before calling device_register() or device_add(), e.g.: device_set_removable(dev, DEVICE_REMOVABLE); device_register(dev); The possible values and the resulting sysfs attribute contents are: DEVICE_REMOVABLE_UNKNOWN -> "unknown" DEVICE_REMOVABLE -> "removable" DEVICE_FIXED -> "fixed" Convert the USB "removable" attribute to use this new device core functionality. There should be no user-visible change in the location or semantics of attribute for USB devices. Reviewed-by: Bjorn Helgaas <bhelgaas@google.com> Signed-off-by: Rajat Jain <rajatja@google.com> Link: https://lore.kernel.org/r/20210524171812.18095-1-rajatja@google.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
* usb: fix spelling mistakes in header filesZhen Lei2021-05-211-1/+1
| | | | | | | | | | | | | | | | | | Fix some spelling mistakes in comments: trasfer ==> transfer consumtion ==> consumption endoint ==> endpoint sharable ==> shareable contraints ==> constraints Auxilary ==> Auxiliary correspondig ==> corresponding interupt ==> interrupt inifinite ==> infinite assignement ==> assignment Signed-off-by: Zhen Lei <thunder.leizhen@huawei.com> Link: https://lore.kernel.org/r/20210517094020.7310-1-thunder.leizhen@huawei.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
* usb: Iterator for portsHeikki Krogerus2021-04-091-0/+9
| | | | | | | | | | | | Introducing usb_for_each_port(). It works the same way as usb_for_each_dev(), but instead of going through every USB device in the system, it walks through the USB ports in the system. Acked-by: Alan Stern <stern@rowland.harvard.edu> Signed-off-by: Heikki Krogerus <heikki.krogerus@linux.intel.com> Link: https://lore.kernel.org/r/20210407065555.88110-4-heikki.krogerus@linux.intel.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
* usb: core: Track SuperSpeed Plus GenXxYThinh Nguyen2021-03-231-0/+2
| | | | | | | | | | Introduce ssp_rate field to usb_device structure to capture the connected SuperSpeed Plus signaling rate generation and lane count with the corresponding usb_ssp_rate enum. Signed-off-by: Thinh Nguyen <Thinh.Nguyen@synopsys.com> Link: https://lore.kernel.org/r/b7805d121e5ae4ad5ae144bd860b6ac04ee47436.1615432770.git.Thinh.Nguyen@synopsys.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
* USB: core: rename usb_driver_claim_interface() data parameterJohan Hovold2021-03-231-1/+1
| | | | | | | | | | | | It's been almost twenty years since the interface "private data" pointer was removed in favour of using the driver-data pointer of struct device. Let's rename the driver-data parameter of usb_driver_claim_interface() so that it better reflects how it's used. Signed-off-by: Johan Hovold <johan@kernel.org> Link: https://lore.kernel.org/r/20210318155406.22399-2-johan@kernel.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
* Merge 5.12-rc3 into usb-nextGreg Kroah-Hartman2021-03-151-0/+2
|\ | | | | | | | | | | We want the USB fixes in here as well. Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
| * drm: Use USB controller's DMA mask when importing dmabufsThomas Zimmermann2021-03-111-0/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | USB devices cannot perform DMA and hence have no dma_mask set in their device structure. Therefore importing dmabuf into a USB-based driver fails, which breaks joining and mirroring of display in X11. For USB devices, pick the associated USB controller as attachment device. This allows the DRM import helpers to perform the DMA setup. If the DMA controller does not support DMA transfers, we're out of luck and cannot import. Our current USB-based DRM drivers don't use DMA, so the actual DMA device is not important. Tested by joining/mirroring displays of udl and radeon under Gnome/X11. v8: * release dmadev if device initialization fails (Noralf) * fix commit description (Noralf) v7: * fix use-before-init bug in gm12u320 (Dan) v6: * implement workaround in DRM drivers and hold reference to DMA device while USB device is in use * remove dev_is_usb() (Greg) * collapse USB helper into usb_intf_get_dma_device() (Alan) * integrate Daniel's TODO statement (Daniel) * fix typos (Greg) v5: * provide a helper for USB interfaces (Alan) * add FIXME item to documentation and TODO list (Daniel) v4: * implement workaround with USB helper functions (Greg) * use struct usb_device->bus->sysdev as DMA device (Takashi) v3: * drop gem_create_object * use DMA mask of USB controller, if any (Daniel, Christian, Noralf) v2: * move fix to importer side (Christian, Daniel) * update SHMEM and CMA helpers for new PRIME callbacks Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de> Fixes: 6eb0233ec2d0 ("usb: don't inherity DMA properties for USB devices") Tested-by: Pavel Machek <pavel@ucw.cz> Reviewed-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Acked-by: Christian König <christian.koenig@amd.com> Acked-by: Daniel Vetter <daniel.vetter@ffwll.ch> Acked-by: Noralf Trønnes <noralf@tronnes.org> Cc: Christoph Hellwig <hch@lst.de> Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Cc: <stable@vger.kernel.org> # v5.10+ Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de> Link: https://patchwork.freedesktop.org/patch/msgid/20210303133229.3288-1-tzimmermann@suse.de Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
* | USB: remove usb_bus_type from usb.hGreg Kroah-Hartman2021-03-101-2/+0
|/ | | | | | | | | | | | | We have 2 forward declarations of usb_bus_type, one in the system-wide usb.h and the other in the "USB core only header file". This variable is not exported from the USB core, so remove the declaration from usb.h as it does not need to be there. Cc: Thomas Zimmermann <tzimmermann@suse.de> Cc: linux-usb@vger.kernel.org Cc: linux-kernel@vger.kernel.org Link: https://lore.kernel.org/r/20210226102356.716746-1-gregkh@linuxfoundation.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
* USB: correct API of usb_control_msg_send/recvOliver Neukum2020-09-251-2/+4
| | | | | | | | | They need to specify how memory is to be allocated, as control messages need to work in contexts that require GFP_NOIO. Signed-off-by: Oliver Neukum <oneukum@suse.com> Link: https://lore.kernel.org/r/20200923134348.23862-9-oneukum@suse.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
* USB: add usb_control_msg_send() and usb_control_msg_recv()Greg Kroah-Hartman2020-09-161-0/+6
| | | | | | | | | | | | | | | | | | | New core functions to make sending/receiving USB control messages easier and saner. In discussions, it turns out that the large majority of users of usb_control_msg() do so in potentially incorrect ways. The most common issue is where a "short" message is received, yet never detected properly due to "incorrect" error handling. Handle all of this in the USB core with two new functions to try to make working with USB control messages simpler. No more need for dynamic data, messages can be on the stack, and only "complete" send/receive will work without causing an error. Link: https://lore.kernel.org/r/20200914153756.3412156-3-gregkh@linuxfoundation.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
* USB: move snd_usb_pipe_sanity_check into the USB coreGreg Kroah-Hartman2020-09-161-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | | snd_usb_pipe_sanity_check() is a great function, so let's move it into the USB core so that other parts of the kernel, including the USB core, can call it. Name it usb_pipe_type_check() to match the existing usb_urb_ep_type_check() call, which now uses this function. Cc: Jaroslav Kysela <perex@perex.cz> Cc: "Gustavo A. R. Silva" <gustavoars@kernel.org> Cc: Eli Billauer <eli.billauer@gmail.com> Cc: Emiliano Ingrassia <ingrassia@epigenesys.com> Cc: Alan Stern <stern@rowland.harvard.edu> Cc: Alexander Tsoy <alexander@tsoy.me> Cc: "Geoffrey D. Bennett" <g@b4.vu> Cc: Jussi Laako <jussi@sonarnerd.net> Cc: Nick Kossifidis <mickflemm@gmail.com> Cc: Dmitry Panchenko <dmitry@d-systems.ee> Cc: Chris Wulff <crwulff@gmail.com> Cc: Jesus Ramos <jesus-ramos@live.com> Reviewed-by: Takashi Iwai <tiwai@suse.de> Link: https://lore.kernel.org/r/20200914153756.3412156-2-gregkh@linuxfoundation.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
* usb: linux/usb.h: drop duplicated word in commentRandy Dunlap2020-07-151-1/+1
| | | | | | | | | | Drop the doubled word "the" in a comment. Signed-off-by: Randy Dunlap <rdunlap@infradead.org> Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Cc: linux-usb@vger.kernel.org Link: https://lore.kernel.org/r/20200715045701.22949-1-rdunlap@infradead.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
* USB: Fix up terminology in include filesGreg Kroah-Hartman2020-07-021-1/+1
| | | | | | | | | | USB is a HOST/DEVICE protocol, as per the specification and all documentation. Fix up terms that are not applicable to make things match up with the terms used through the rest of the USB stack. Acked-by: Felipe Balbi <balbi@kernel.org> Link: https://lore.kernel.org/r/20200701171555.3198836-1-gregkh@linuxfoundation.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
* usb: fix kernel-doc warnings and formatting in <linux/usb.h>Randy Dunlap2020-07-011-3/+7
| | | | | | | | | | | | | | | | | Fix kernel-doc warnings in <linux/usb.h>: ../include/linux/usb.h:713: warning: Function parameter or member 'use_generic_driver' not described in 'usb_device' ../include/linux/usb.h:1253: warning: Function parameter or member 'match' not described in 'usb_device_driver' ../include/linux/usb.h:1253: warning: Function parameter or member 'id_table' not described in 'usb_device_driver' Also drop an extra blank line and fix indentation. Fixes: 77419aa403ca ("USB: Fallback to generic driver when specific driver fails") Fixes: 88b7381a939d ("USB: Select better matching USB drivers when available") Signed-off-by: Randy Dunlap <rdunlap@infradead.org> Cc: Bastien Nocera <hadess@hadess.net> Link: https://lore.kernel.org/r/7014bab2-268c-69f6-7ef5-57fbd45c8b08@infradead.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
* USB: Replace zero-length array with flexible-array memberGustavo A. R. Silva2020-02-231-2/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The current codebase makes use of the zero-length array language extension to the C90 standard, but the preferred mechanism to declare variable-length types such as these ones is a flexible array member[1][2], introduced in C99: struct foo { int stuff; struct boo array[]; }; By making use of the mechanism above, we will get a compiler warning in case the flexible array does not occur last in the structure, which will help us prevent some kind of undefined behavior bugs from being inadvertently introduced[3] to the codebase from now on. Also, notice that, dynamic memory allocations won't be affected by this change: "Flexible array members have incomplete type, and so the sizeof operator may not be applied. As a quirk of the original implementation of zero-length arrays, sizeof evaluates to zero."[1] This issue was found with the help of Coccinelle. [1] https://gcc.gnu.org/onlinedocs/gcc/Zero-Length.html [2] https://github.com/KSPP/linux/issues/21 [3] commit 76497732932f ("cxgb3/l2t: Fix undefined behaviour") Signed-off-by: Gustavo A. R. Silva <gustavo@embeddedor.com> Link: https://lore.kernel.org/r/20200220132017.GA29262@embeddedor Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
* USB: Fallback to generic driver when specific driver failsBastien Nocera2020-02-121-0/+1
| | | | | | | | | | | If ->probe fails for a device specific driver, ask the driver core to reprobe us, after having flagged the device for the generic driver to be forced. Signed-off-by: Bastien Nocera <hadess@hadess.net> Acked-by: Alan Stern <stern@rowland.harvard.edu> Link: https://lore.kernel.org/r/20191016093933.693-6-hadess@hadess.net Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
* USB: Select better matching USB drivers when availableBastien Nocera2020-02-121-0/+2
| | | | | | | | | | | | | | | | | | Now that USB device drivers can reuse code from the generic USB device driver, we need to make sure that they get selected rather than the generic driver. Add an id_table and match vfunc to the usb_device_driver struct, which will get used to select a better matching driver at ->probe time. This is a similar mechanism to that used in the HID drivers, with the generic driver being selected unless there's a better matching one found in the registered drivers (see hid_generic_match() in drivers/hid/hid-generic.c). Signed-off-by: Bastien Nocera <hadess@hadess.net> Acked-by: Alan Stern <stern@rowland.harvard.edu> Link: https://lore.kernel.org/r/20191016093933.693-5-hadess@hadess.net Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
* USB: Make it possible to "subclass" usb_device_driverBastien Nocera2020-02-121-0/+4
| | | | | | | | | | | | | | | | | | The kernel currenly has only 2 usb_device_drivers, one generic one, one that completely replaces the generic one to make USB devices usable over a network. Use the newly exported generic driver functions when a driver declares to want them run, in addition to its own code. This makes it possible to write drivers that extend the generic USB driver. Note that this patch is not enough for another driver to automatically get selected. Signed-off-by: Bastien Nocera <hadess@hadess.net> Acked-by: Alan Stern <stern@rowland.harvard.edu> Link: https://lore.kernel.org/r/20191016093933.693-3-hadess@hadess.net Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
* usb: add a HCD_DMA flag instead of guestimating DMA capabilitiesChristoph Hellwig2019-08-211-1/+0
| | | | | | | | | | | | | | | | | | The usb core is the only major place in the kernel that checks for a non-NULL device dma_mask to see if a device is DMA capable. This is generally a bad idea, as all major busses always set up a DMA mask, even if the device is not DMA capable - in fact bus layers like PCI can't even know if a device is DMA capable at enumeration time. This leads to lots of workaround in HCD drivers, and also prevented us from setting up a DMA mask for platform devices by default last time we tried. Replace this guess with an explicit HCD_DMA that is set by drivers that appear to have DMA support. Signed-off-by: Christoph Hellwig <hch@lst.de> Link: https://lore.kernel.org/r/20190816062435.881-4-hch@lst.de Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
* Merge 5.3-rc5 into usb-nextGreg Kroah-Hartman2019-08-191-1/+1
|\ | | | | | | | | | | We need the usb fixes in here as well for other patches to build on. Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
| * usb: add a hcd_uses_dma helperChristoph Hellwig2019-08-151-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | The USB buffer allocation code is the only place in the usb core (and in fact the whole kernel) that uses is_device_dma_capable, while the URB mapping code uses the uses_dma flag in struct usb_bus. Switch the buffer allocation to use the uses_dma flag used by the rest of the USB code, and create a helper in hcd.h that checks this flag as well as the CONFIG_HAS_DMA to simplify the caller a bit. Signed-off-by: Christoph Hellwig <hch@lst.de> Link: https://lore.kernel.org/r/20190811080520.21712-3-hch@lst.de Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
* | USB: add support for dev_groups to struct usb_device_driverGreg Kroah-Hartman2019-08-071-0/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Now that the driver core supports dev_groups for individual drivers, expose that pointer to struct usb_device_driver to make it easier for USB drivers to also use it. Yes, users of usb_device_driver are much rare, but there are instances already that use custom sysfs files, so adding this support will make things easier for those drivers. usbip is one example, hubs might be another one. Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Link: https://lore.kernel.org/r/20190806144502.17792-3-gregkh@linuxfoundation.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
* | USB: add support for dev_groups to struct usb_driverGreg Kroah-Hartman2019-08-071-0/+3
|/ | | | | | | | | | Now that the driver core supports dev_groups for individual drivers, expose that pointer to struct usb_driver to make it easier for USB drivers to also use it. Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Link: https://lore.kernel.org/r/20190806144502.17792-2-gregkh@linuxfoundation.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
* usb: Add devaddr in struct usb_deviceJim Lin2019-06-051-0/+2
| | | | | | | | | | | | | | | | | | The Clear_TT_Buffer request sent to the hub includes the address of the LS/FS child device in wValue field. usb_hub_clear_tt_buffer() uses udev->devnum to set the address wValue. This won't work for devices connected to xHC. For other host controllers udev->devnum is the same as the address of the usb device, chosen and set by usb core. With xHC the controller hardware assigns the address, and won't be the same as devnum. Here we add devaddr in "struct usb_device" for usb_hub_clear_tt_buffer() to use. Signed-off-by: Jim Lin <jilin@nvidia.com> Acked-by: Alan Stern <stern@rowland.harvard.edu> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
* Merge tag 'usb-5.2-rc1' of ↵Linus Torvalds2019-05-081-1/+1
|\ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb Pull USB/PHY updates from Greg KH: "Here is the big set of USB and PHY driver patches for 5.2-rc1 There is the usual set of: - USB gadget updates - PHY driver updates and additions - USB serial driver updates and fixes - typec updates and new chips supported - mtu3 driver updates - xhci driver updates - other tiny driver updates Nothing really interesting, just constant forward progress. All of these have been in linux-next for a while with no reported issues. The usb-gadget and usb-serial trees were merged a bit "late", but both of them had been in linux-next before they got merged here last Friday" * tag 'usb-5.2-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb: (206 commits) USB: serial: f81232: implement break control USB: serial: f81232: add high baud rate support USB: serial: f81232: clear overrun flag USB: serial: f81232: fix interrupt worker not stop usb: dwc3: Rename DWC3_DCTL_LPM_ERRATA usb: dwc3: Fix default lpm_nyet_threshold value usb: dwc3: debug: Print GET_STATUS(device) tracepoint usb: dwc3: Do core validation early on probe usb: dwc3: gadget: Set lpm_capable usb: gadget: atmel: tie wake lock to running clock usb: gadget: atmel: support USB suspend usb: gadget: atmel_usba_udc: simplify setting of interrupt-enabled mask dwc2: gadget: Fix completed transfer size calculation in DDMA usb: dwc2: Set lpm mode parameters depend on HW configuration usb: dwc2: Fix channel disable flow usb: dwc2: Set actual frame number for completed ISOC transfer usb: gadget: do not use __constant_cpu_to_le16 usb: dwc2: gadget: Increase descriptors count for ISOC's usb: introduce usb_ep_type_string() function usb: dwc3: move synchronize_irq() out of the spinlock protected block ...
| * USB: usb.h: tweak struct urb to remove wasted spaceGreg Kroah-Hartman2019-03-191-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | By moving one field around in 'struct urb' we reduce the size of the structure by 8 bytes. Before the patch on x86_64 the overall size of the structure as reported by pahole was: /* size: 192, cachelines: 3, members: 30 */ /* sum members: 184, holes: 2, sum holes: 8 */ After the patch we now have: /* size: 184, cachelines: 3, members: 30 */ /* last cacheline: 56 bytes */ Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
* | USB: core: Fix bug caused by duplicate interface PM usage counterAlan Stern2019-04-191-2/+0
|/ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The syzkaller fuzzer reported a bug in the USB hub driver which turned out to be caused by a negative runtime-PM usage counter. This allowed a hub to be runtime suspended at a time when the driver did not expect it. The symptom is a WARNING issued because the hub's status URB is submitted while it is already active: URB 0000000031fb463e submitted while active WARNING: CPU: 0 PID: 2917 at drivers/usb/core/urb.c:363 The negative runtime-PM usage count was caused by an unfortunate design decision made when runtime PM was first implemented for USB. At that time, USB class drivers were allowed to unbind from their interfaces without balancing the usage counter (i.e., leaving it with a positive count). The core code would take care of setting the counter back to 0 before allowing another driver to bind to the interface. Later on when runtime PM was implemented for the entire kernel, the opposite decision was made: Drivers were required to balance their runtime-PM get and put calls. In order to maintain backward compatibility, however, the USB subsystem adapted to the new implementation by keeping an independent usage counter for each interface and using it to automatically adjust the normal usage counter back to 0 whenever a driver was unbound. This approach involves duplicating information, but what is worse, it doesn't work properly in cases where a USB class driver delays decrementing the usage counter until after the driver's disconnect() routine has returned and the counter has been adjusted back to 0. Doing so would cause the usage counter to become negative. There's even a warning about this in the USB power management documentation! As it happens, this is exactly what the hub driver does. The kick_hub_wq() routine increments the runtime-PM usage counter, and the corresponding decrement is carried out by hub_event() in the context of the hub_wq work-queue thread. This work routine may sometimes run after the driver has been unbound from its interface, and when it does it causes the usage counter to go negative. It is not possible for hub_disconnect() to wait for a pending hub_event() call to finish, because hub_disconnect() is called with the device lock held and hub_event() acquires that lock. The only feasible fix is to reverse the original design decision: remove the duplicate interface-specific usage counter and require USB drivers to balance their runtime PM gets and puts. As far as I know, all existing drivers currently do this. Signed-off-by: Alan Stern <stern@rowland.harvard.edu> Reported-and-tested-by: syzbot+7634edaea4d0b341c625@syzkaller.appspotmail.com CC: <stable@vger.kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
* USB: check usb_get_extra_descriptor for proper sizeMathias Payer2018-12-051-2/+2
| | | | | | | | | | | | | | | When reading an extra descriptor, we need to properly check the minimum and maximum size allowed, to prevent from invalid data being sent by a device. Reported-by: Hui Peng <benquike@gmail.com> Reported-by: Mathias Payer <mathias.payer@nebelwelt.net> Co-developed-by: Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by: Hui Peng <benquike@gmail.com> Signed-off-by: Mathias Payer <mathias.payer@nebelwelt.net> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org> Cc: stable <stable@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
* usb: hub: Per-port setting to reduce TRSTRCY to 10 msNicolas Boichat2018-05-311-0/+3
| | | | | | | | | | | | | Currently, the USB hub core waits for 50 ms after enumerating the device. This was added to help "some high speed devices" to enumerate (b789696af8 "[PATCH] USB: relax usbcore reset timings"). On some devices, the time-to-active is important, so we provide a per-port option to reduce the time to what the USB specification requires: 10 ms. Signed-off-by: Nicolas Boichat <drinkcat@chromium.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
* usb: hub: Per-port setting to use old enumeration schemeNicolas Boichat2018-05-311-0/+7
| | | | | | | | | | | | | | | | | | | The "old" enumeration scheme is considerably faster (it takes ~244ms instead of ~356ms to get the descriptor). It is currently only possible to use the old scheme globally (/sys/module/usbcore/parameters/old_scheme_first), which is not desirable as the new scheme was introduced to increase compatibility with more devices. However, in our case, we care about time-to-active for a specific USB device (which we make the firmware for), on a specific port (that is pogo-pin based: not a standard USB port). This new sysfs option makes it possible to use the old scheme on a single port only. Signed-off-by: Nicolas Boichat <drinkcat@chromium.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
* USB: Add support to store lane count used by USB 3.2Mathias Nyman2018-04-221-0/+4
| | | | | | | | | | | | | | | | | | | | | | USB 3.2 specification adds Dual-lane support, doubling the maximum SuperSpeedPlus data rate from 10Gbps to 20Gbps. Dual-lane takes into use a second set of rx and tx wires/pins in the Type-C cable and connector. Add "rx_lanes" and "tx_lanes" variables to struct usb_device to store the numer of lanes in use. Number of lanes can be read using the extended port status hub request that was introduced in USB 3.1. Extended port status rx and tx lane count are zero based, maximum lanes supported by non inter-chip (SSIC) USB 3.2 is 2 (dual lane) with rx and tx lane count symmetric. SSIC devices support asymmetric lanes up to 4 lanes per direction. If extended port status is not available then default to one lane. Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
* usb: core: add support for USB_REQ_SET_ISOCH_DELAYFelipe Balbi2017-12-151-0/+6
| | | | | | | | | | | | | | USB SS and SSP hubs provide wHubDelay values on their hub descriptor which we should inform the USB Device about. The USB Specification 3.0 explains, on section 9.4.11, how to calculate the value and how to issue the request. Note that a USB_REQ_SET_ISOCH_DELAY is valid on all device states (Default, Address, Configured), we just *chose* to issue it from Address state right after successfully fetching the USB Device Descriptor. Signed-off-by: Felipe Balbi <felipe.balbi@linux.intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
* USB: remove the URB_NO_FSBR flagAlan Stern2017-12-121-1/+0
| | | | | | | | | | | | | | | | The URB_NO_FSBR flag has never really been used. It was introduced as a potential way for UHCI to minimize PCI bus usage (by not attempting full-speed bulk and control transfers more than once per frame), but the flag was not set by any drivers. There's no point in keeping it around. This patch simplifies the API by removing it. Unfortunately, it does have to be kept as part of the usbfs ABI, but at least we can document in include/uapi/linux/usbdevice_fs.h that it doesn't do anything. Signed-off-by: Alan Stern <stern@rowland.harvard.edu> Acked-by: Shuah Khan <shuahkh@osg.samsung.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
generated by cgit v1.2.3 (git 2.25.1) at 2025-03-22 00:43:42 +0000