Signed-off-by: NAl Viro <viro@zeniv.linux.org.uk>

We are going to split <linux/sched/signal.h> out of <linux/sched.h>, which
will have to be picked up from other headers and a couple of .c files.

Create a trivial placeholder <linux/sched/signal.h> file that just
maps to <linux/sched.h> to make this patch obviously correct and
bisectable.

Include the new header in the files that are going to need it.
Acked-by: NLinus Torvalds <torvalds@linux-foundation.org>
Cc: Mike Galbraith <efault@gmx.de>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: linux-kernel@vger.kernel.org
Signed-off-by: NIngo Molnar <mingo@kernel.org>

Fix typos and add the following to the scripts/spelling.txt:

  an one||a one

I dropped the "an" before "one or more" in
drivers/net/ethernet/sfc/mcdi_pcol.h.

Link: http://lkml.kernel.org/r/1481573103-11329-6-git-send-email-yamada.masahiro@socionext.comSigned-off-by: NMasahiro Yamada <yamada.masahiro@socionext.com>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

Promote a variable keeping track of USB transfer memory usage to a
wider data type and allow for higher bandwidth transfers from a large
number of USB devices connected to a single host.
Signed-off-by: NMateusz Berezecki <mateuszb@fastmail.fm>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

CURRENT_TIME macro is not appropriate for filesystems as it
doesn't use the right granularity for filesystem timestamps.
Use current_time() instead.

CURRENT_TIME is also not y2038 safe.

This is also in preparation for the patch that transitions
vfs timestamps to use 64 bit time and hence make them
y2038 safe. As part of the effort current_time() will be
extended to do range checks. Hence, it is necessary for all
file system timestamps to use current_time(). Also,
current_time() will be transitioned along with vfs to be
y2038 safe.

Note that whenever a single call to current_time() is used
to change timestamps in different inodes, it is because they
share the same time granularity.
Signed-off-by: NDeepa Dinamani <deepa.kernel@gmail.com>
Reviewed-by: NArnd Bergmann <arnd@arndb.de>
Acked-by: NFelipe Balbi <balbi@kernel.org>
Acked-by: NSteven Whitehouse <swhiteho@redhat.com>
Acked-by: NRyusuke Konishi <konishi.ryusuke@lab.ntt.co.jp>
Acked-by: NDavid Sterba <dsterba@suse.com>
Signed-off-by: NAl Viro <viro@zeniv.linux.org.uk>

UBSAN complains about a left shift by -1 in proc_do_submiturb().  This
can occur when an URB is submitted for a bulk or control endpoint on
a high-speed device, since the code doesn't bother to check the
endpoint type; normally only interrupt or isochronous endpoints have
a nonzero bInterval value.

Aside from the fact that the operation is illegal, it shouldn't matter
because the result isn't used.  Still, in theory it could cause a
hardware exception or other problem, so we should work around it.
This patch avoids doing the left shift unless the shift amount is >= 0.

The same piece of code has another problem.  When checking the device
speed (the exponential encoding for interrupt endpoints is used only
by high-speed or faster devices), we need to look for speed >=
USB_SPEED_SUPER as well as speed == USB_SPEED HIGH.  The patch adds
this check.
Signed-off-by: NAlan Stern <stern@rowland.harvard.edu>
Reported-by: NVittorio Zecca <zeccav@gmail.com>
Tested-by: NVittorio Zecca <zeccav@gmail.com>
Suggested-by: NBjørn Mork <bjorn@mork.no>
CC: <stable@vger.kernel.org>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

Hans de Goede has reported a difficulty in the Linux port of libusb.
When a device is removed, the poll() system call in usbfs starts
returning POLLERR as soon as udev->state is set to
USB_STATE_NOTATTACHED, but the outstanding URBs are not available for
reaping until some time later (after usbdev_remove() has been called).
This is awkward for libusb or other usbfs clients, although not an
insuperable problem.

At any rate, it's easy to change usbfs so that it returns POLLHUP as
soon as the state becomes USB_STATE_NOTATTACHED but it doesn't return
POLLERR until after the outstanding URBs have completed.  That's what
this patch does; it uses the fact that ps->list is always on the
dev->filelist list until usbdev_remove() takes it off, which happens
after all the outstanding URBs have been cancelled.
Signed-off-by: NAlan Stern <stern@rowland.harvard.edu>
Reported-by: NHans de Goede <hdegoede@redhat.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

usbdev_mmap allocates a buffer. The size of the buffer is determined
by a user. So with this code (no need to be root):

	int fd = open("/dev/bus/usb/001/001", O_RDONLY);
	mmap(NULL, 0x800000, PROT_READ, MAP_SHARED, fd, 0);

we can see a warning:

WARNING: CPU: 0 PID: 21771 at ../mm/page_alloc.c:3563 __alloc_pages_slowpath+0x1036/0x16e0()
...
Call Trace:
 [<ffffffff8117a3ae>] ? warn_slowpath_null+0x2e/0x40
 [<ffffffff815178b6>] ? __alloc_pages_slowpath+0x1036/0x16e0
 [<ffffffff81516880>] ? warn_alloc_failed+0x250/0x250
 [<ffffffff8151226b>] ? get_page_from_freelist+0x75b/0x28b0
 [<ffffffff815184e3>] ? __alloc_pages_nodemask+0x583/0x6b0
 [<ffffffff81517f60>] ? __alloc_pages_slowpath+0x16e0/0x16e0
 [<ffffffff810565d4>] ? dma_generic_alloc_coherent+0x104/0x220
 [<ffffffffa0269e56>] ? hcd_buffer_alloc+0x1d6/0x3e0 [usbcore]
 [<ffffffffa0269c80>] ? hcd_buffer_destroy+0xa0/0xa0 [usbcore]
 [<ffffffffa0228f05>] ? usb_alloc_coherent+0x65/0x90 [usbcore]
 [<ffffffffa0275c05>] ? usbdev_mmap+0x1a5/0x770 [usbcore]
...

Allocations like this one should be marked as __GFP_NOWARN. So do so.

The size could be also clipped by something like:
	if (size >= (1 << (MAX_ORDER + PAGE_SHIFT - 1)))
		return -ENOMEM;
But I think the overall limit of 16M (by usbfs_increase_memory_usage)
is enough, so that we only silence the warning here.
Signed-off-by: NJiri Slaby <jslaby@suse.cz>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: Alan Stern <stern@rowland.harvard.edu>
Cc: Steinar H. Gunderson <sesse@google.com>
Cc: Markus Rechberger <mrechberger@gmail.com>
Fixes: f7d34b44 (USB: Add support for usbfs zerocopy.)
Cc: 4.6+ <stable@vger.kernel.org>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

The stack object “ci” has a total size of 8 bytes. Its last 3 bytes
are padding bytes which are not initialized and leaked to userland
via “copy_to_user”.
Signed-off-by: NKangjie Lu <kjlu@gatech.edu>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

usbdev_vm_ops is used in devio.c only, so declare it as static
Signed-off-by: NMichele Curti <michele.curti@gmail.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

The new USBDEVFS_DROP_PRIVILEGES ioctl allows a process to voluntarily
relinquish the ability to issue other ioctls that may interfere with
other processes and drivers that have claimed an interface on the
device.

This commit also includes a simple utility to be able to test the
ioctl, located at Documentation/usb/usbdevfs-drop-permissions.c

Example (with qemu-kvm's input device):

    $ lsusb
    ...
    Bus 001 Device 002: ID 0627:0001 Adomax Technology Co., Ltd

    $ usb-devices
    ...
    C:  #Ifs= 1 Cfg#= 1 Atr=a0 MxPwr=100mA
    I:  If#= 0 Alt= 0 #EPs= 1 Cls=03(HID  ) Sub=00 Prot=02 Driver=usbhid

    $ sudo ./usbdevfs-drop-permissions /dev/bus/usb/001/002
    OK: privileges dropped!
    Available options:
    [0] Exit now
    [1] Reset device. Should fail if device is in use
    [2] Claim 4 interfaces. Should succeed where not in use
    [3] Narrow interface permission mask
    Which option shall I run?: 1
    ERROR: USBDEVFS_RESET failed! (1 - Operation not permitted)
    Which test shall I run next?: 2
    ERROR claiming if 0 (1 - Operation not permitted)
    ERROR claiming if 1 (1 - Operation not permitted)
    ERROR claiming if 2 (1 - Operation not permitted)
    ERROR claiming if 3 (1 - Operation not permitted)
    Which test shall I run next?: 0

After unbinding usbhid:

    $ usb-devices
    ...
    I:  If#= 0 Alt= 0 #EPs= 1 Cls=03(HID  ) Sub=00 Prot=02 Driver=(none)

    $ sudo ./usbdevfs-drop-permissions /dev/bus/usb/001/002
    ...
    Which option shall I run?: 2
    OK: claimed if 0
    ERROR claiming if 1 (1 - Operation not permitted)
    ERROR claiming if 2 (1 - Operation not permitted)
    ERROR claiming if 3 (1 - Operation not permitted)
    Which test shall I run next?: 1
    OK: USBDEVFS_RESET succeeded
    Which test shall I run next?: 0

After unbinding usbhid and restricting the mask:

    $ sudo ./usbdevfs-drop-permissions /dev/bus/usb/001/002
    ...
    Which option shall I run?: 3
    Insert new mask: 0
    OK: privileges dropped!
    Which test shall I run next?: 2
    ERROR claiming if 0 (1 - Operation not permitted)
    ERROR claiming if 1 (1 - Operation not permitted)
    ERROR claiming if 2 (1 - Operation not permitted)
    ERROR claiming if 3 (1 - Operation not permitted)
Signed-off-by: NReilly Grant <reillyg@chromium.org>
Acked-by: NAlan Stern <stern@rowland.harvard.edu>
Signed-off-by: NEmilio López <emilio.lopez@collabora.co.uk>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

Add a new interface for userspace to preallocate memory that can be
used with usbfs. This gives two primary benefits:

 - Zerocopy; data no longer needs to be copied between the userspace
   and the kernel, but can instead be read directly by the driver from
   userspace's buffers. This works for all kinds of transfers (even if
   nonsensical for control and interrupt transfers); isochronous also
   no longer need to memset() the buffer to zero to avoid leaking kernel data.

 - Once the buffers are allocated, USB transfers can no longer fail due to
   memory fragmentation; previously, long-running programs could run into
   problems finding a large enough contiguous memory chunk, especially on
   embedded systems or at high rates.

Memory is allocated by using mmap() against the usbfs file descriptor,
and similarly deallocated by munmap(). Once memory has been allocated,
using it as pointers to a bulk or isochronous operation means you will
automatically get zerocopy behavior. Note that this also means you cannot
modify outgoing data until the transfer is complete. The same holds for
data on the same cache lines as incoming data; DMA modifying them at the
same time could lead to your changes being overwritten.

There's a new capability USBDEVFS_CAP_MMAP that userspace can query to see
if the running kernel supports this functionality, if just trying mmap() is
not acceptable.

Largely based on a patch by Markus Rechberger with some updates. The original
patch can be found at:

  http://sundtek.de/support/devio_mmap_v0.4.diffSigned-off-by: NSteinar H. Gunderson <sesse@google.com>
Signed-off-by: NMarkus Rechberger <mrechberger@gmail.com>
Acked-by: NAlan Stern <stern@rowland.harvard.edu>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

Use to_usb_device() instead of open-coding it.
Signed-off-by: NGeliang Tang <geliangtang@163.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

Fixing coccicheck warning which recommends to use memdup_user instead
to reimplement its code, using memdup_user simplifies the code

./drivers/usb/core/devio.c:1398:11-18: WARNING opportunity for memdup_user
Signed-off-by: NRahul Pathak <rpathak@visteon.com>
Acked-by: NAlan Stern <stern@rowland.harvard.edu>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

Removed an unnecessary space between a function name and arguments.
Signed-off-by: NChase Metzger <chasemetzger15@gmail.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

Signed-off-by: NAl Viro <viro@zeniv.linux.org.uk>

This patch improves the usbfs_snoop debugging facility by adding
messages for a couple of significant events which, up to now, have not
been logged.  The events are reaping and discarding (i.e.,
cancelling) an URB.  The debugging messages include the userspace
address of the URB being reaped or discarded.

The reaping messages have to be added in four places, in order to
handle blocking and non-blocking reaps in both normal and 32-bit
compatibility mode.
Signed-off-by: NAlan Stern <stern@rowland.harvard.edu>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

The usbfs_snoop facility can be very useful for debugging problems
involving usbfs.  However, it always prints out the entire contents of
every URB.  When dealing with large quantities of data, this can be
less than helpful.

This patch ameliorates the situation by adding a module parameter to
usbcore for controlling the maximum number of bytes to print when
snooping an URB.  This makes debugging much easier.  For backward
compatibility, the default value is set unreasonably high.
Signed-off-by: NAlan Stern <stern@rowland.harvard.edu>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

Fix two occurrences of the checkpatch.pl error:

ERROR: space prohibited before that ',' (ctx:WxW)

Fix one occurrence of the checkpatch error:

ERROR: space required before the open parenthesis '('
Signed-off-by: NKris Borer <kborer@gmail.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

Fix five occurrences of the checkpatch.pl error:

ERROR: do not use assignment in if condition

The semantic patch that makes this change is:

// <smpl>
@@
identifier i;
expression E;
statement S1, S2;
@@

+ i = E;
  if (
- (i = E)
+ i
  ) S1 else S2

@@
identifier i;
expression E;
statement S;
constant c;
binary operator b;
@@

+ i = E;
  if (
- (i = E)
+ i
  b
  c ) S
// </smpl>
Signed-off-by: NKris Borer <kborer@gmail.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

Static checkers complain that the current condition is never true.  It
seems pretty likely that it's a typo and "URB" was intended instead of
"USB".

Fixes: 3d97ff63 ('usbdevfs: Use scatter-gather lists for large bulk transfers')
Signed-off-by: NDan Carpenter <dan.carpenter@oracle.com>
Acked-by: NAlan Stern <stern@rowland.harvard.edu>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

Ran checkpatch.pl on file and removed a warning about an unwanted space before
a tab.
Signed-off-by: NChase Metzger <chasemetzger15@gmail.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

When a signal is delivered, the information in the siginfo structure
is copied to userspace.  Good security practice dicatates that the
unused fields in this structure should be initialized to 0 so that
random kernel stack data isn't exposed to the user.  This patch adds
such an initialization to the two places where usbfs raises signals.
Signed-off-by: NAlan Stern <stern@rowland.harvard.edu>
Reported-by: NDave Mielke <dave@mielke.cc>
CC: <stable@vger.kernel.org>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

The usbfs API has a peculiar hole: Users are not allowed to reap their
URBs after the device has been disconnected.  There doesn't seem to be
any good reason for this; it is an ad-hoc inconsistency.

The patch allows users to issue the USBDEVFS_REAPURB and
USBDEVFS_REAPURBNDELAY ioctls (together with their 32-bit counterparts
on 64-bit systems) even after the device is gone.  If no URBs are
pending for a disconnected device then the ioctls will return -ENODEV
rather than -EAGAIN, because obviously no new URBs will ever be able
to complete.

The patch also adds a new capability flag for
USBDEVFS_GET_CAPABILITIES to indicate that the reap-after-disconnect
feature is supported.
Signed-off-by: NAlan Stern <stern@rowland.harvard.edu>
Tested-by: NChris Dickens <christopher.a.dickens@gmail.com>
Acked-by: NHans de Goede <hdegoede@redhat.com>
Signed-off-by: NGreg Kroah-Hartman <greg@kroah.com>

usbfs allows user space to pass down an URB which sets URB_SHORT_NOT_OK
for output URBs. That causes usbcore to log messages without limit
for a nonsensical disallowed combination. The fix is to silently drop
the attribute in usbfs.
The problem is reported to exist since 3.14
https://www.virtualbox.org/ticket/13085Signed-off-by: NOliver Neukum <oneukum@suse.de>
CC: stable@vger.kernel.org
Acked-by: NAlan Stern <stern@rowland.harvard.edu>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

Since it is needed outside usbcore and exposed in include/linux/usb.h,
it conflicts with enum dev_state in rt2x00 wireless driver.

Mark it as usb specific to avoid conflicts in the future.
Signed-off-by: NValentina Manea <valentina.manea.m@gmail.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

This allows userspace to use bulk-streams, just like in kernel drivers, see
Documentation/usb/bulk-streams.txt for details on the in kernel API. This
is exported pretty much one on one to userspace.

To use streams an app must first make a USBDEVFS_ALLOC_STREAMS ioctl,
on success this will return the number of streams available (which may be
less then requested). If there are n streams the app can then submit
usbdevfs_urb-s with their stream_id member set to 1-n to use a specific
stream. IE if USBDEVFS_ALLOC_STREAMS returns 4 then stream_id 1-4 can be
used.

When the app is done using streams it should call USBDEVFS_FREE_STREAMS

Note applications are advised to use libusb rather then using the
usbdevfs api directly. The latest version of libusb has support for streams.
Signed-off-by: NHans de Goede <hdegoede@redhat.com>
Signed-off-by: NSarah Sharp <sarah.a.sharp@linux.intel.com>

Signed-off-by: NHans de Goede <hdegoede@redhat.com>
Signed-off-by: NSarah Sharp <sarah.a.sharp@linux.intel.com>

This patch makes it possible to specify a bulk stream id when submitting
an urb using the async usbfs API. It overloads the number_of_packets
usbdevfs_urb field for this. This is not pretty, but given other
constraints it is the best we can do. The reasoning leading to this goes
as follows:

1) We want to support bulk streams in the usbfs API
2) We do not want to extend the usbdevfs_urb struct with a new member, as
   that would mean defining new ioctl numbers for all async API ioctls +
   adding compat versions for the old ones (times 2 for 32 bit support)
3) 1 + 2 means we need to re-use an existing field
4) number_of_packets is only used for isoc urbs, and streams are bulk only
   so it is the best (and only) candidate for re-using

Note that:
1) This patch only uses number_of_packets as stream_id if the app has
   actually allocated streams on the ep, so that old apps which may have
   garbage in there (as it was unused until now in the bulk case), will not
   break
2) This patch does not add support for allocating / freeing bulk-streams, that
   is done in a follow up patch
Signed-off-by: NHans de Goede <hdegoede@redhat.com>
Signed-off-by: NSarah Sharp <sarah.a.sharp@linux.intel.com>

This is a preparation patch for adding support for bulk streams.
Signed-off-by: NHans de Goede <hdegoede@redhat.com>
Signed-off-by: NSarah Sharp <sarah.a.sharp@linux.intel.com>

The usb_set_interface documentation says:

 * Also, drivers must not change altsettings while urbs are scheduled for
 * endpoints in that interface; all such urbs must first be completed
 * (perhaps forced by unlinking).

For in kernel drivers we trust the drivers to get this right, but we
cannot trust userspace to get this right, so enforce it by killing any
urbs still pending on the interface.
Signed-off-by: NHans de Goede <hdegoede@redhat.com>
Signed-off-by: NSarah Sharp <sarah.a.sharp@linux.intel.com>

It is an error for a driver to call usb_clear_halt() or
usb_reset_endpoint() while there are URBs queued for the endpoint,
because the end result is not well defined.  At the time the endpoint
gets reset, it may or may not be actively running.

As far as I know, no kernel drivers do this.  But some userspace
drivers do, and it seems like a good idea to bring this error to their
attention.

This patch adds a warning to the kernel log whenever a program invokes
the USBDEVFS_CLEAR_HALT or USBDEVFS_RESETEP ioctls at an inappropriate
time, and includes the name of the program.  This will make it clear
that any subsequent errors are not due to the misbehavior of a kernel
driver.
Signed-off-by: NAlan Stern <stern@rowland.harvard.edu>
Suggested-by: NBjørn Mork <bjorn@mork.no>
CC: Stanislaw Gruszka <sgruszka@redhat.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

Signed-off-by: NRahul Bedarkar <rahulbedarkar89@gmail.com>
Acked-by: NRandy Dunlap <rdunlap@infradead.org>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

Replaced spaces by tabs for proc_control_compat() function.
Signed-off-by: NMatthias Beyer <mail@beyermatthias.de>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

Replaced spaces by tabs for proc_reapurbnonblock() function.
Signed-off-by: NMatthias Beyer <mail@beyermatthias.de>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

Trying to read data from the Pegasus Technologies NoteTaker (0e20:0101)
[1] with the Windows App (EasyNote) works natively but fails when
Windows is running under KVM (and the USB device handed to KVM).

The reason is a USB control message
 usb 4-2.2: control urb: bRequestType=22 bRequest=09 wValue=0200 wIndex=0001 wLength=0008
This goes to endpoint address 0x01 (wIndex); however, endpoint address
0x01 does not exist. There is an endpoint 0x81 though (same number,
but other direction); the app may have meant that endpoint instead.

The kernel thus rejects the IO and thus we see the failure.

Apparently, Linux is more strict here than Windows ... we can't change
the Win app easily, so that's a problem.

It seems that the Win app/driver is buggy here and the driver does not
behave fully according to the USB HID class spec that it claims to
belong to.  The device seems to happily deal with that though (and
seems to not really care about this value much).

So the question is whether the Linux kernel should filter here.
Rejecting has the risk that somewhat non-compliant userspace apps/
drivers (most likely in a virtual machine) are prevented from working.
Not rejecting has the risk of confusing an overly sensitive device with
such a transfer. Given the fact that Windows does not filter it makes
this risk rather small though.

The patch makes the kernel more tolerant: If the endpoint address in
wIndex does not exist, but an endpoint with toggled direction bit does,
it will let the transfer through. (It does NOT change the message.)

With attached patch, the app in Windows in KVM works.
 usb 4-2.2: check_ctrlrecip: process 13073 (qemu-kvm) requesting ep 01 but needs 81

I suspect this will mostly affect apps in virtual environments; as on
Linux the apps would have been adapted to the stricter handling of the
kernel. I have done that for mine[2].

[1] http://www.pegatech.com/
[2] https://sourceforge.net/projects/notetakerpen/Signed-off-by: NKurt Garloff <kurt@garloff.de>
Acked-by: NAlan Stern <stern@rowland.harvard.edu>
Cc: stable <stable@vger.kernel.org>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

Urb fields are stored in struct usbdevfs_ctrltransfer in CPU byteorder
and not in little endian, so there is no need to be converted.
This bug was reported by sparse.
Signed-off-by: NXenia Ragiadakou <burzalodowa@gmail.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

For certain (HP) printers the printer device_id does not only contain a
static part identifying the printer, but it also contains a dynamic part
giving printer status, ink level, etc.

To get to this info various userspace utilities need to be able to make a
printer class 'get_device_id' request without first claiming the interface
(as that is in use for the actual printer driver).

Since the printer class 'get_device_id' request does not change interface
settings in anyway, allowing this without claiming the interface should not
cause any issues.

CC: Sanjay Kumar <sanjay.kumar14@hp.com>
CC: Alan Stern <stern@rowland.harvard.edu>
Signed-off-by: NHans de Goede <hdegoede@redhat.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

Increase the current arbitrary limit for isocronous packet size to a
value large enough to account for USB 3.0 super bandwidth streams,
bMaxBurst (0~15 allowed, 1~16 packets)
bmAttributes (bit 1:0, mult 0~2, 1~3 packets)
so the size max for one USB 3 isocronous transfer is
1024 byte * 16 * 3 = 49152 byte
Acked-by: NAlan Stern <stern@rowland.harvard.edu>
Signed-off-by: NFederico Manzan <f.manzan@gmail.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

This patch fixes error: 'do not use assignment in if condition'
in USB/devio.c.
Signed-off-by: NTülin İzer <tulinizer@gmail.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>