- 19 Feb, 2020 14 commits
-
-
Corentin Labbe authored
device_driver name is const char pointer, so it not useful to cast udc_name (which is already const char). Signed-off-by: Corentin Labbe <clabbe@baylibre.com> Link: https://lore.kernel.org/r/1582054383-35760-11-git-send-email-clabbe@baylibre.comSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Corentin Labbe authored
device_driver name is const char pointer, so it not useful to cast driver_name (which is already const char). Reviewed-by: Alexandre Belloni <alexandre.belloni@bootlin.com> Signed-off-by: Corentin Labbe <clabbe@baylibre.com> Link: https://lore.kernel.org/r/1582054383-35760-10-git-send-email-clabbe@baylibre.comSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Corentin Labbe authored
pci_driver name is const char pointer, so it not useful to cast driver_name (which is already const char). Signed-off-by: Corentin Labbe <clabbe@baylibre.com> Link: https://lore.kernel.org/r/1582054383-35760-9-git-send-email-clabbe@baylibre.comSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Corentin Labbe authored
device_driver name is const char pointer, so it not useful to cast udc_name (which is already const char). Signed-off-by: Corentin Labbe <clabbe@baylibre.com> Link: https://lore.kernel.org/r/1582054383-35760-8-git-send-email-clabbe@baylibre.comSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Corentin Labbe authored
device_driver name is const char pointer, so it not useful to cast udc_name (which is already const char). Signed-off-by: Corentin Labbe <clabbe@baylibre.com> Link: https://lore.kernel.org/r/1582054383-35760-7-git-send-email-clabbe@baylibre.comSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Corentin Labbe authored
device_driver name is const char pointer, so it not useful to cast driver_name (which is already const char). Signed-off-by: Corentin Labbe <clabbe@baylibre.com> Link: https://lore.kernel.org/r/1582054383-35760-6-git-send-email-clabbe@baylibre.comSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Corentin Labbe authored
device_driver name is const char pointer, so it not useful to cast driver_name (which is already const char). Acked-by: Alexandre Belloni <alexandre.belloni@bootlin.com> Signed-off-by: Corentin Labbe <clabbe@baylibre.com> Link: https://lore.kernel.org/r/1582054383-35760-5-git-send-email-clabbe@baylibre.comSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Corentin Labbe authored
pci_driver name is const char pointer, so it not useful to cast name (which is already const char). Signed-off-by: Corentin Labbe <clabbe@baylibre.com> Link: https://lore.kernel.org/r/1582054383-35760-4-git-send-email-clabbe@baylibre.comSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Corentin Labbe authored
device_driver name is const char pointer, so it not useful to cast shortname (which is already const char). Signed-off-by: Corentin Labbe <clabbe@baylibre.com> Link: https://lore.kernel.org/r/1582054383-35760-3-git-send-email-clabbe@baylibre.comSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Corentin Labbe authored
usb_composite_driver name is const char pointer, so it not useful to cast longname (which is already const char). Signed-off-by: Corentin Labbe <clabbe@baylibre.com> Link: https://lore.kernel.org/r/1582054383-35760-2-git-send-email-clabbe@baylibre.comSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Andy Shevchenko authored
Use ACPI_SUCCESS() to replace !ACPI_FAILURE(), this avoids additional operation. Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Link: https://lore.kernel.org/r/20200218191717.73512-1-andriy.shevchenko@linux.intel.comSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Andy Shevchenko authored
Compiler is not happy about dangling variable: .../core/usb-acpi.c: In function ‘usb_acpi_get_connect_type’: .../core/usb-acpi.c:90:14: warning: variable ‘status’ set but not used [-Wunused-but-set-variable] 90 | acpi_status status; | ^~~~~~ Make use of it by checking the status and bail out in case of error. Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Link: https://lore.kernel.org/r/20200218185207.62527-1-andriy.shevchenko@linux.intel.comSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Joe Perches authored
Make structs const to reduce data size ~20KB. Change function arguments and prototypes as necessary to compile. $ size (x86-64 defconfig pre) text data bss dec hex filename 12281 10948 480 23709 5c9d ./drivers/usb/storage/usb.o 111 10528 8 10647 2997 ./drivers/usb/storage/usual-tables.o $ size (x86-64 defconfig post) text data bss dec hex filename 22809 420 480 23709 5c9d drivers/usb/storage/usb.o 10551 0 0 10551 2937 drivers/usb/storage/usual-tables.o Signed-off-by: Joe Perches <joe@perches.com> Acked-by: Alan Stern <stern@rowland.harvard.edu> Link: https://lore.kernel.org/r/cf13bd2d790ae3afbf5da55ea7bed12e00c5119d.camel@perches.comSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Rasmus Villemoes authored
After this was made buildable for something other than PPC32, kbuild starts warning drivers/usb/host/fhci-hcd.c:398:8: warning: this statement may fall through [-Wimplicit-fallthrough=] I don't know this code, but from the construction (initializing size with 0 and explicitly using "size +=" in the PIPE_BULK case) I assume that fallthrough is indeed intended. Reported-by: kbuild test robot <lkp@intel.com> Signed-off-by: Rasmus Villemoes <linux@rasmusvillemoes.dk> Acked-by: Li Yang <leoyang.li@nxp.com> Link: https://lore.kernel.org/r/20200213085401.27862-1-linux@rasmusvillemoes.dkSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
- 17 Feb, 2020 6 commits
-
-
Ajay Gupta authored
Ucsi ppm is unregistered during fw flashing so disable runtime pm also and reenable after fw flashing is completed and ppm is re-registered. Signed-off-by: Ajay Gupta <ajayg@nvidia.com> Signed-off-by: Heikki Krogerus <heikki.krogerus@linux.intel.com> Link: https://lore.kernel.org/r/20200217144913.55330-3-heikki.krogerus@linux.intel.comSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Ajay Gupta authored
NVIDIA VirtualLink (svid 0x955) has two altmode, vdo=0x1 for VirtualLink DP mode and vdo=0x3 for NVIDIA test mode. Register display altmode driver only for vdo=0x1 Signed-off-by: Ajay Gupta <ajayg@nvidia.com> Signed-off-by: Heikki Krogerus <heikki.krogerus@linux.intel.com> Link: https://lore.kernel.org/r/20200217144913.55330-2-heikki.krogerus@linux.intel.comSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Jules Irenge authored
Sparse reports a warning at xhci_enter_test_mode() warning: context imbalance in xhci_enter_test_mode - unexpected unlock The root cause is the missing annotation at xhci_enter_test_mode() Add the missing __must_hold(&xhci->lock) annotattion Signed-off-by: Jules Irenge <jbi.octave@gmail.com> Link: https://lore.kernel.org/r/20200214204741.94112-24-jbi.octave@gmail.comSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Jules Irenge authored
Sparse reports a warning at xhci_set_port_power() warning: context imbalance in xhci_set_port_power - unexpected unlock The root cause is the missing annotation at xhci_set_port_power() Add the missing __must_hold(&xhci->lock) annotattion Signed-off-by: Jules Irenge <jbi.octave@gmail.com> Link: https://lore.kernel.org/r/20200214204741.94112-23-jbi.octave@gmail.comSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Steven Rostedt (VMware) authored
libtraceevent (used by perf and trace-cmd) failed to parse the xhci_urb_dequeue trace event. This is because the user space trace event format parsing is not a full C compiler. It can handle some basic logic, but is not meant to be able to handle everything C can do. In cases where a trace event field needs to be converted from a number to a string, there's the __print_symbolic() macro that should be used: See samples/trace_events/trace-events-sample.h Some xhci trace events open coded the __print_symbolic() causing the user spaces tools to fail to parse it. This has to be replaced with __print_symbolic() instead. CC: stable@vger.kernel.org Reported-by: Tzvetomir Stoyanov <tstoyanov@vmware.com> Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=206531 Fixes: 5abdc2e6 ("usb: host: xhci: add urb_enqueue/dequeue/giveback tracers") Signed-off-by: Steven Rostedt (VMware) <rostedt@goodmis.org> Link: https://lore.kernel.org/r/20200214115634.30e8ebf2@gandalf.local.homeSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Alexandre Belloni authored
The variable is named reserved, the comment should say so. Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com> Link: https://lore.kernel.org/r/20200214142446.22483-1-alexandre.belloni@bootlin.comSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
- 14 Feb, 2020 5 commits
-
-
Gustavo A. R. Silva authored
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 inadvertenly introduced[3] to the codebase from now on. 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 76497732 ("cxgb3/l2t: Fix undefined behaviour") Signed-off-by: Gustavo A. R. Silva <gustavo@embeddedor.com> Link: https://lore.kernel.org/r/20200211232303.GA21495@embeddedorSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Gustavo A. R. Silva authored
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 inadvertenly introduced[3] to the codebase from now on. 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 76497732 ("cxgb3/l2t: Fix undefined behaviour") Signed-off-by: Gustavo A. R. Silva <gustavo@embeddedor.com> Link: https://lore.kernel.org/r/20200211232519.GA23263@embeddedorSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Li Jun authored
Since the typec port data role is separated from power role, so check the port data capability when setting data role. Signed-off-by: Li Jun <jun.li@nxp.com> Reviewed-by: Heikki Krogerus <heikki.krogerus@linux.intel.com> Link: https://lore.kernel.org/r/1581666828-2063-1-git-send-email-jun.li@nxp.comSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Mika Westerberg authored
Two functions that were added for USB4 support miss kernel-doc parameter descriptions so add them now. Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com> Link: https://lore.kernel.org/r/20200214121638.75589-1-mika.westerberg@linux.intel.comSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
chenqiwu authored
Use kobj_to_dev() API instead of container_of(). Signed-off-by: chenqiwu <chenqiwu@xiaomi.com> Link: https://lore.kernel.org/r/1581683820-9978-1-git-send-email-qiwuchen55@gmail.comSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
- 13 Feb, 2020 1 commit
-
-
Oliver Neukum authored
The product ID is little endian and needs to be converted. Reported-by: kbuild test robot <lkp@intel.com> Signed-off-by: Oliver Neukum <oneukum@suse.com> Reviewed-by: Bastien Nocera <hadess@hadess.net> Link: https://lore.kernel.org/r/20200213111336.32392-1-oneukum@suse.comSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
- 12 Feb, 2020 14 commits
-
-
Bastien Nocera authored
iOS devices will not draw more than 500mA unless instructed to do so. Setting the charge type power supply property to "fast" tells the device to start drawing more power, using the same procedure that official "MFi" chargers would. Signed-off-by: Bastien Nocera <hadess@hadess.net> Acked-by: Alan Stern <stern@rowland.harvard.edu> Link: https://lore.kernel.org/r/20191016093933.693-7-hadess@hadess.netSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Bastien Nocera authored
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.netSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Bastien Nocera authored
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.netSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Bastien Nocera authored
Match a usb_device with a table of IDs. Signed-off-by: Bastien Nocera <hadess@hadess.net> Acked-by: Alan Stern <stern@rowland.harvard.edu> Link: https://lore.kernel.org/r/20191016093933.693-4-hadess@hadess.netSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Bastien Nocera authored
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.netSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Bastien Nocera authored
This will make it possible to implement device drivers which extend the generic driver without needing to reimplement it. Signed-off-by: Bastien Nocera <hadess@hadess.net> Acked-by: Alan Stern <stern@rowland.harvard.edu> Link: https://lore.kernel.org/r/20191016093933.693-2-hadess@hadess.netSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Gustavo A. R. Silva authored
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 inadvertenly introduced[3] to the codebase from now on. 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 76497732 ("cxgb3/l2t: Fix undefined behaviour") Signed-off-by: Gustavo A. R. Silva <gustavo@embeddedor.com> Link: https://lore.kernel.org/r/20200211232148.GA20644@embeddedorSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Heikki Krogerus authored
There are no more users for the old device connection descriptions that used device names. Signed-off-by: Heikki Krogerus <heikki.krogerus@linux.intel.com> Link: https://lore.kernel.org/r/20200211112531.86510-7-heikki.krogerus@linux.intel.comSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Heikki Krogerus authored
Using the generic notification chain is not reasonable with the alternate modes because it would require dependencies between the drivers of the components that need the notifications, and the typec drivers. There are no users for the alternate mode notifications, so removing the chain and the API for it completely. Signed-off-by: Heikki Krogerus <heikki.krogerus@linux.intel.com> Link: https://lore.kernel.org/r/20200211112531.86510-6-heikki.krogerus@linux.intel.comSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Heikki Krogerus authored
Removing descriptions of the mux and sw members. They are no longer part of the structure. Signed-off-by: Heikki Krogerus <heikki.krogerus@linux.intel.com> Link: https://lore.kernel.org/r/20200211112531.86510-5-heikki.krogerus@linux.intel.comSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Heikki Krogerus authored
Even though originally the USB Type-C Specification did not describe the steps for power role swapping without USB PD contract in place, it did not actually mean power role swap without USB PD was not allowed. The USB Type-C Specification did not clearly separate the data and power roles until in the release 1.2 which is why there also were no clear steps for the scenario where only the power role was swapped without USB PD contract before that. Since in the latest version of the specification the power role swap without USB PD is now clearly mentioned as allowed operation, removing the check that prevented power role swap without USB PD support. Signed-off-by: Heikki Krogerus <heikki.krogerus@linux.intel.com> Link: https://lore.kernel.org/r/20200211112531.86510-4-heikki.krogerus@linux.intel.comSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Heikki Krogerus authored
The port_type attribute is special. It is meant to allow changing the capability of the port in runtime. It is purely Linux kernel specific feature, i.e. the feature is not described in any of the USB specifications. Because of the special nature of this attribute, handling it differently compared to the other writable attributes, and hiding it when the underlying port interface (or just the driver) does not support the feature. Signed-off-by: Heikki Krogerus <heikki.krogerus@linux.intel.com> Link: https://lore.kernel.org/r/20200211112531.86510-3-heikki.krogerus@linux.intel.comSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Heikki Krogerus authored
This affects the read-writable attribute files. Before this there was no way for the user to know is changing the value supported or not. >From now on those attribute files will be made read-only unless the underlying driver supports changing of the value. Signed-off-by: Heikki Krogerus <heikki.krogerus@linux.intel.com> Link: https://lore.kernel.org/r/20200211112531.86510-2-heikki.krogerus@linux.intel.comSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Geert Uytterhoeven authored
The DWC3 USB driver is not a clock provider, and just needs to call of_clk_get_parent_count(). Hence it can include <linux/of_clk.h> instead of <linux/clk-provider.h>. Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be> Reviewed-by: Stephen Boyd <sboyd@kernel.org> Link: https://lore.kernel.org/r/20200212101853.9349-1-geert+renesas@glider.beSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-