25 Sep, 2020
1 commit
-
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
Link: https://lore.kernel.org/r/20200923134348.23862-9-oneukum@suse.com
Signed-off-by: Greg Kroah-Hartman
16 Sep, 2020
2 commits
-
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 -
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
Cc: "Gustavo A. R. Silva"
Cc: Eli Billauer
Cc: Emiliano Ingrassia
Cc: Alan Stern
Cc: Alexander Tsoy
Cc: "Geoffrey D. Bennett"
Cc: Jussi Laako
Cc: Nick Kossifidis
Cc: Dmitry Panchenko
Cc: Chris Wulff
Cc: Jesus Ramos
Reviewed-by: Takashi Iwai
Link: https://lore.kernel.org/r/20200914153756.3412156-2-gregkh@linuxfoundation.org
Signed-off-by: Greg Kroah-Hartman
15 Jul, 2020
1 commit
-
Drop the doubled word "the" in a comment.
Signed-off-by: Randy Dunlap
Cc: Greg Kroah-Hartman
Cc: linux-usb@vger.kernel.org
Link: https://lore.kernel.org/r/20200715045701.22949-1-rdunlap@infradead.org
Signed-off-by: Greg Kroah-Hartman
03 Jul, 2020
1 commit
-
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
Link: https://lore.kernel.org/r/20200701171555.3198836-1-gregkh@linuxfoundation.org
Signed-off-by: Greg Kroah-Hartman
01 Jul, 2020
1 commit
-
Fix kernel-doc warnings in :
../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
Cc: Bastien Nocera
Link: https://lore.kernel.org/r/7014bab2-268c-69f6-7ef5-57fbd45c8b08@infradead.org
Signed-off-by: Greg Kroah-Hartman
24 Feb, 2020
1 commit
-
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
Link: https://lore.kernel.org/r/20200220132017.GA29262@embeddedor
Signed-off-by: Greg Kroah-Hartman
13 Feb, 2020
3 commits
-
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
Acked-by: Alan Stern
Link: https://lore.kernel.org/r/20191016093933.693-6-hadess@hadess.net
Signed-off-by: Greg Kroah-Hartman -
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
Acked-by: Alan Stern
Link: https://lore.kernel.org/r/20191016093933.693-5-hadess@hadess.net
Signed-off-by: Greg Kroah-Hartman -
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
Acked-by: Alan Stern
Link: https://lore.kernel.org/r/20191016093933.693-3-hadess@hadess.net
Signed-off-by: Greg Kroah-Hartman
22 Aug, 2019
1 commit
-
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
Link: https://lore.kernel.org/r/20190816062435.881-4-hch@lst.de
Signed-off-by: Greg Kroah-Hartman
19 Aug, 2019
1 commit
-
We need the usb fixes in here as well for other patches to build on.
Signed-off-by: Greg Kroah-Hartman
15 Aug, 2019
1 commit
-
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
Link: https://lore.kernel.org/r/20190811080520.21712-3-hch@lst.de
Signed-off-by: Greg Kroah-Hartman
07 Aug, 2019
2 commits
-
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
Link: https://lore.kernel.org/r/20190806144502.17792-3-gregkh@linuxfoundation.org
Signed-off-by: Greg Kroah-Hartman -
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
Link: https://lore.kernel.org/r/20190806144502.17792-2-gregkh@linuxfoundation.org
Signed-off-by: Greg Kroah-Hartman
05 Jun, 2019
1 commit
-
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
Acked-by: Alan Stern
Signed-off-by: Greg Kroah-Hartman
09 May, 2019
1 commit
-
Pull USB/PHY updates from Greg KH:
"Here is the big set of USB and PHY driver patches for 5.2-rc1There 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
...
20 Apr, 2019
1 commit
-
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:363The 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
Reported-and-tested-by: syzbot+7634edaea4d0b341c625@syzkaller.appspotmail.com
CC:
Signed-off-by: Greg Kroah-Hartman
19 Mar, 2019
1 commit
-
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
06 Dec, 2018
1 commit
-
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
Reported-by: Mathias Payer
Co-developed-by: Linus Torvalds
Signed-off-by: Hui Peng
Signed-off-by: Mathias Payer
Signed-off-by: Linus Torvalds
Cc: stable
Signed-off-by: Greg Kroah-Hartman
31 May, 2018
2 commits
-
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
Signed-off-by: Greg Kroah-Hartman -
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
Signed-off-by: Greg Kroah-Hartman
22 Apr, 2018
1 commit
-
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
Signed-off-by: Greg Kroah-Hartman
16 Dec, 2017
1 commit
-
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
Signed-off-by: Greg Kroah-Hartman
12 Dec, 2017
1 commit
-
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
Acked-by: Shuah Khan
Signed-off-by: Greg Kroah-Hartman
15 Nov, 2017
1 commit
-
Pull sound updates from Takashi Iwai:
"There are no big surprising changes in this cycle, yet not too boring,
either. The biggest change from diffstat POV is the removal of the
legacy OSS driver codes that have been already disabled for a long
time. This will bring a few trivial merge conflicts.As new features in ASoC side, there are two things: a new AC97 bus
implementation and AMD Stony platform support. Both include the
relevant changes shared with other subsystems, e.g. AC97 MFD changes
and DRM AMD changes.Some other highlighted topics are:
- A bunch of USB-audio drivers got the hardening against the
malicious device accesses with a new helper code for endpoint
sanity check- Lots of cleanups for ASoC Intel platform code, including support
for their open source audio firmware- Continued ASoC core componentization works
- Support for scaling MCLK with sample rate in ASoC simple-card
- Stabler PCM hot-unplug capability, especially for ASoC usages"
* tag 'sound-4.15-rc1' of ssh://gitolite.kernel.org/pub/scm/linux/kernel/git/tiwai/sound: (302 commits)
Documentation: sound: hd-audio: notes.rst
ASoC: bcm2835: Support left/right justified and DSP modes
ASoC: bcm2835: Enforce full symmetry
ASoC: bcm2835: Support additional samplerates up to 384kHz
ASoC: bcm2835: Add support for TDM modes
ASoC: add mclk-fs support to audio graph card
ASoC: add mclk-fs to audio graph card binding
ASoC: rt5514: work around link error
ASoC: rt5514: mark PM functions as __maybe_unused
ASoC: rt5663: Check the JD status in the button pushing
ASoC: amd: Modified DMA transfer Mechanism for Playback
ASoC: rt5645: Wait for 400msec before concluding on value of RT5645_VENDOR_ID2
ASoC: sun4i-codec: fixed 32bit audio capture support for H3/H2+
ASoC: da7213: add support for DSP modes
ASoC: sun8i-codec: Add a comment on the LRCK inversion
ASoC: sun8i-codec: Set the BCLK divider
ASoC: rt5663: Delay and retry reading rt5663 ID register
ASoC: amd: use do_div rather than 64 bit division to fix 32 bit builds
ASoC: cs42l56: Fix reset GPIO name in example DT binding
ASoC: rt5514-spi: check irq status to schedule data copy in resume function
...
14 Nov, 2017
1 commit
-
Pull USB/PHY updates from Greg KH:
"Here is the big set of USB and PHY driver updates for 4.15-rc1.There is the usual amount of gadget and xhci driver updates, along
with phy and chipidea enhancements. There's also a lot of SPDX tags
and license boilerplate cleanups as well, which provide some churn in
the diffstat.Other major thing is the typec code that moved out of staging and into
the "real" part of the drivers/usb/ tree, which was nice to see
happen.All of these have been in linux-next with no reported issues for a
while"* tag 'usb-4.15-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb: (263 commits)
usb: gadget: f_fs: Fix use-after-free in ffs_free_inst
USB: usbfs: compute urb->actual_length for isochronous
usb: core: message: remember to reset 'ret' to 0 when necessary
USB: typec: Remove remaining redundant license text
USB: typec: add SPDX identifiers to some files
USB: renesas_usbhs: rcar?.h: add SPDX tags
USB: chipidea: ci_hdrc_tegra.c: add SPDX line
USB: host: xhci-debugfs: add SPDX lines
USB: add SPDX identifiers to all remaining Makefiles
usb: host: isp1362-hcd: remove a couple of redundant assignments
USB: adutux: remove redundant variable minor
usb: core: add a new usb_get_ptm_status() helper
usb: core: add a 'type' parameter to usb_get_status()
usb: core: introduce a new usb_get_std_status() helper
usb: core: rename usb_get_status() 'type' argument to 'recip'
usb: core: add Status Type definitions
USB: gadget: Remove redundant license text
USB: gadget: function: Remove redundant license text
USB: gadget: udc: Remove redundant license text
USB: gadget: legacy: Remove redundant license text
...
13 Nov, 2017
1 commit
-
…e/sound into for-linus
ASoC: Updates for v4.15
The biggest thing this release has been the conversion of the AC98 bus
to the driver model, that's been a long time coming so thanks to Robert
Jarzmik for his dedication there. Due to there being some AC97 MFD
there's a few fairly large changes in input and the MFD layer, mainly to
the wm97xx driver.There's also some drivers/drm changes to support the new AMD Stoney
platform, these are shared with the DRM subsystem and should be being
merged via both.Within the subsystem the overwhelming bulk of the changes is in the
Intel drivers which continue to need lots of cleanups and fixes, this
release they've also gained support for their open source firmware.
There's also some large changs in the core as Morimoto-san continues to
mirror operations into the component level in preparation for conversion
of drivers to that.- The AC97 bus has finally caught up with the driver model thanks to
some dedicated and persistent work from Robert Jarzmik.
- Continued work from Morimoto-san on moving us towards being able to
use components for everything.
- Lots of cleanups for the Intel platform code, including support for
their open source audio firmware.
- Support for scaling MCLK with sample rate in simple-card.
- Support for AMD Stoney platform.
07 Nov, 2017
4 commits
-
Drivers who are interested in the PTM status stype, should use this
new helper to make sure they issue the correct GetStatus message.Signed-off-by: Felipe Balbi
Signed-off-by: Greg Kroah-Hartman -
This new 'type' parameter will allows interested drivers to request
for PTM status or Standard status.Signed-off-by: Felipe Balbi
Signed-off-by: Greg Kroah-Hartman -
This new helper is a simple wrapper around usb_get_status(). This
patch is in preparation to adding support for fetching PTM_STATUS
types. No functional changes.Signed-off-by: Felipe Balbi
Signed-off-by: Greg Kroah-Hartman -
This makes it a lot clearer that we're expecting a recipient as the
argument. A follow-up patch will use the argument 'type' as the status
type selector (standard or ptm).Signed-off-by: Felipe Balbi
Signed-off-by: Greg Kroah-Hartman
02 Nov, 2017
1 commit
-
Many source files in the tree are missing licensing information, which
makes it harder for compliance tools to determine the correct license.By default all files without license information are under the default
license of the kernel, which is GPL version 2.Update the files which contain no license information with the 'GPL-2.0'
SPDX license identifier. The SPDX identifier is a legally binding
shorthand, which can be used instead of the full boiler plate text.This patch is based on work done by Thomas Gleixner and Kate Stewart and
Philippe Ombredanne.How this work was done:
Patches were generated and checked against linux-4.14-rc6 for a subset of
the use cases:
- file had no licensing information it it.
- file was a */uapi/* one with no licensing information in it,
- file was a */uapi/* one with existing licensing information,Further patches will be generated in subsequent months to fix up cases
where non-standard license headers were used, and references to license
had to be inferred by heuristics based on keywords.The analysis to determine which SPDX License Identifier to be applied to
a file was done in a spreadsheet of side by side results from of the
output of two independent scanners (ScanCode & Windriver) producing SPDX
tag:value files created by Philippe Ombredanne. Philippe prepared the
base worksheet, and did an initial spot review of a few 1000 files.The 4.13 kernel was the starting point of the analysis with 60,537 files
assessed. Kate Stewart did a file by file comparison of the scanner
results in the spreadsheet to determine which SPDX license identifier(s)
to be applied to the file. She confirmed any determination that was not
immediately clear with lawyers working with the Linux Foundation.Criteria used to select files for SPDX license identifier tagging was:
- Files considered eligible had to be source code files.
- Make and config files were included as candidates if they contained >5
lines of source
- File already had some variant of a license header in it (even if
Reviewed-by: Philippe Ombredanne
Reviewed-by: Thomas Gleixner
Signed-off-by: Greg Kroah-Hartman
11 Oct, 2017
1 commit
-
This patch adds a new helper function to perform a sanity check of the
given URB to see whether it contains a valid endpoint. It's a light-
weight version of what usb_submit_urb() does, but without the kernel
warning followed by the stack trace, just returns an error code.Especially for a driver that doesn't parse the descriptor but fills
the URB with the fixed endpoint (e.g. some quirks for non-compliant
devices), this kind of check is preferable at the probe phase before
actually submitting the urb.Tested-by: Andrey Konovalov
Acked-by: Greg Kroah-Hartman
Signed-off-by: Takashi Iwai
18 Apr, 2017
1 commit
-
Since when we got rid of usbfs, the /proc/bus/usb is now
elsewhere. Fix references for it.Signed-off-by: Mauro Carvalho Chehab
Acked-by: Serge Hallyn
Signed-off-by: Greg Kroah-Hartman
23 Mar, 2017
3 commits
-
Several drivers have implemented their endpoint look-up loops in such a
way that they have picked the last endpoint descriptor of the specified
type should more than one such descriptor exist.To avoid any regressions, add corresponding helpers to lookup endpoints
by searching the endpoint descriptors in reverse order.Signed-off-by: Johan Hovold
Signed-off-by: Greg Kroah-Hartman -
Many USB drivers iterate over the available endpoints to find required
endpoints of a specific type and direction. Typically the endpoints are
required for proper function and a missing endpoint should abort probe.To facilitate code reuse, add a helper to retrieve common endpoints
(bulk or interrupt, in or out) and four wrappers to find a single
endpoint.Note that the helpers are marked as __must_check to serve as a reminder
to always verify that all expected endpoints are indeed present. This
also means that any optional endpoints, typically need to be looked up
through separate calls.Signed-off-by: Johan Hovold
Signed-off-by: Greg Kroah-Hartman -
For xhci-hcd platform device, all the DMA parameters are not
configured properly, notably dma ops for dwc3 devices.The idea here is that you pass in the parent of_node along with
the child device pointer, so it would behave exactly like the
parent already does. The difference is that it also handles all
the other attributes besides the mask.sysdev will represent the physical device, as seen from firmware
or bus.Splitting the usb_bus->controller field into the
Linux-internal device (used for the sysfs hierarchy, for printks
and for power management) and a new pointer (used for DMA,
DT enumeration and phy lookup) probably covers all that we really
need.Signed-off-by: Arnd Bergmann
Signed-off-by: Sriram Dash
Tested-by: Baolin Wang
Tested-by: Brian Norris
Tested-by: Alexander Sverdlin
Tested-by: Vivek Gautam
Signed-off-by: Mathias Nyman
Signed-off-by: Peter Chen
Cc: Felipe Balbi
Cc: Grygorii Strashko
Cc: Sinjan Kumar
Cc: David Fisher
Cc: Catalin Marinas
Cc: "Thang Q. Nguyen"
Cc: Yoshihiro Shimoda
Cc: Stephen Boyd
Cc: Bjorn Andersson
Cc: Ming Lei
Cc: Jon Masters
Cc: Dann Frazier
Cc: Peter Chen
Cc: Leo Li
Signed-off-by: Greg Kroah-Hartman
24 Oct, 2016
1 commit
-
replace usb_unregister_dev by usb_deregister_dev
Signed-off-by: Amitesh Singh
Signed-off-by: Greg Kroah-Hartman
04 May, 2016
1 commit
-
When a USB driver is bound to an interface (either through probing or
by claiming it) or is unbound from an interface, the USB core always
disables Link Power Management during the transition and then
re-enables it afterward. The reason is because the driver might want
to prevent hub-initiated link power transitions, in which case the HCD
would have to recalculate the various LPM parameters. This
recalculation takes place when LPM is re-enabled and the new
parameters are sent to the device and its parent hub.However, if the driver does not want to prevent hub-initiated link
power transitions then none of this work is necessary. The parameters
don't need to be recalculated, and LPM doesn't need to be disabled and
re-enabled.It turns out that disabling and enabling LPM can be time-consuming,
enough so that it interferes with user programs that want to claim and
release interfaces rapidly via usbfs. Since the usbfs kernel driver
doesn't set the disable_hub_initiated_lpm flag, we can speed things up
and get the user programs to work by leaving LPM alone whenever the
flag isn't set.And while we're improving the way disable_hub_initiated_lpm gets used,
let's also fix its kerneldoc.Signed-off-by: Alan Stern
Tested-by: Matthew Giassa
CC: Mathias Nyman
CC:
Signed-off-by: Greg Kroah-Hartman