commit 8a16224b405492bb0ebf450d9f3761580ebe1761
Author: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Date:   Sat Mar 18 19:15:30 2017 +0800

    Linux 4.9.16

commit c8186699527b5b0ee080e510afac9a3db797aa1b
Author: Kamal Heib <kamalh@mellanox.com>
Date:   Wed Jan 18 14:10:32 2017 +0200

    IB/mlx5: Verify that Q counters are supported
    
    commit 45bded2c216da6010184ac5ebe88c27f73439009 upstream.
    
    Make sure that the Q counters are supported by the FW before trying
    to allocate/deallocte them, this will avoid driver load failure when
    they aren't supported by the FW.
    
    Fixes: 0837e86a7a34 ('IB/mlx5: Add per port counters')
    Signed-off-by: Kamal Heib <kamalh@mellanox.com>
    Reviewed-by: Mark Bloch <markb@mellanox.com>
    Signed-off-by: Leon Romanovsky <leon@kernel.org>
    Signed-off-by: Doug Ledford <dledford@redhat.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 8fed8fc18839d7aec7ea046d79eb814dce6255c3
Author: Theodore Ts'o <tytso@mit.edu>
Date:   Tue Feb 14 11:31:15 2017 -0500

    ext4: don't BUG when truncating encrypted inodes on the orphan list
    
    commit 0d06863f903ac5f4f6efb0273079d27de3e53a28 upstream.
    
    Fix a BUG when the kernel tries to mount a file system constructed as
    follows:
    
    echo foo > foo.txt
    mke2fs -Fq -t ext4 -O encrypt foo.img 100
    debugfs -w foo.img << EOF
    write foo.txt a
    set_inode_field a i_flags 0x80800
    set_super_value s_last_orphan 12
    quit
    EOF
    
    root@kvm-xfstests:~# mount -o loop foo.img /mnt
    [  160.238770] ------------[ cut here ]------------
    [  160.240106] kernel BUG at /usr/projects/linux/ext4/fs/ext4/inode.c:3874!
    [  160.240106] invalid opcode: 0000 [#1] SMP
    [  160.240106] Modules linked in:
    [  160.240106] CPU: 0 PID: 2547 Comm: mount Tainted: G        W       4.10.0-rc3-00034-gcdd33b941b67 #227
    [  160.240106] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.10.1-1 04/01/2014
    [  160.240106] task: f4518000 task.stack: f47b6000
    [  160.240106] EIP: ext4_block_zero_page_range+0x1a7/0x2b4
    [  160.240106] EFLAGS: 00010246 CPU: 0
    [  160.240106] EAX: 00000001 EBX: f7be4b50 ECX: f47b7dc0 EDX: 00000007
    [  160.240106] ESI: f43b05a8 EDI: f43babec EBP: f47b7dd0 ESP: f47b7dac
    [  160.240106]  DS: 007b ES: 007b FS: 00d8 GS: 0033 SS: 0068
    [  160.240106] CR0: 80050033 CR2: bfd85b08 CR3: 34a00680 CR4: 000006f0
    [  160.240106] Call Trace:
    [  160.240106]  ext4_truncate+0x1e9/0x3e5
    [  160.240106]  ext4_fill_super+0x286f/0x2b1e
    [  160.240106]  ? set_blocksize+0x2e/0x7e
    [  160.240106]  mount_bdev+0x114/0x15f
    [  160.240106]  ext4_mount+0x15/0x17
    [  160.240106]  ? ext4_calculate_overhead+0x39d/0x39d
    [  160.240106]  mount_fs+0x58/0x115
    [  160.240106]  vfs_kern_mount+0x4b/0xae
    [  160.240106]  do_mount+0x671/0x8c3
    [  160.240106]  ? _copy_from_user+0x70/0x83
    [  160.240106]  ? strndup_user+0x31/0x46
    [  160.240106]  SyS_mount+0x57/0x7b
    [  160.240106]  do_int80_syscall_32+0x4f/0x61
    [  160.240106]  entry_INT80_32+0x2f/0x2f
    [  160.240106] EIP: 0xb76b919e
    [  160.240106] EFLAGS: 00000246 CPU: 0
    [  160.240106] EAX: ffffffda EBX: 08053838 ECX: 08052188 EDX: 080537e8
    [  160.240106] ESI: c0ed0000 EDI: 00000000 EBP: 080537e8 ESP: bfa13660
    [  160.240106]  DS: 007b ES: 007b FS: 0000 GS: 0033 SS: 007b
    [  160.240106] Code: 59 8b 00 a8 01 0f 84 09 01 00 00 8b 07 66 25 00 f0 66 3d 00 80 75 61 89 f8 e8 3e e2 ff ff 84 c0 74 56 83 bf 48 02 00 00 00 75 02 <0f> 0b 81 7d e8 00 10 00 00 74 02 0f 0b 8b 43 04 8b 53 08 31 c9
    [  160.240106] EIP: ext4_block_zero_page_range+0x1a7/0x2b4 SS:ESP: 0068:f47b7dac
    [  160.317241] ---[ end trace d6a773a375c810a5 ]---
    
    The problem is that when the kernel tries to truncate an inode in
    ext4_truncate(), it tries to clear any on-disk data beyond i_size.
    Without the encryption key, it can't do that, and so it triggers a
    BUG.
    
    E2fsck does *not* provide this service, and in practice most file
    systems have their orphan list processed by e2fsck, so to avoid
    crashing, this patch skips this step if we don't have access to the
    encryption key (which is the case when processing the orphan list; in
    all other cases, we will have the encryption key, or the kernel
    wouldn't have allowed the file to be opened).
    
    An open question is whether the fact that e2fsck isn't clearing the
    bytes beyond i_size causing problems --- and if we've lived with it
    not doing it for so long, can we drop this from the kernel replay of
    the orphan list in all cases (not just when we don't have the key for
    encrypted inodes).
    
    Addresses-Google-Bug: #35209576
    
    Signed-off-by: Theodore Ts'o <tytso@mit.edu>
    Signed-off-by: Eric Biggers <ebiggers@google.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 39df5977fd410a8ebd7f736455531440327e9ff0
Author: Sean Young <sean@mess.org>
Date:   Wed Feb 22 18:48:01 2017 -0300

    rc: raw decoder for keymap protocol is not loaded on register
    
    commit 413808685dd7c9b54bbc5af79da2eaddd0fc3cb2 upstream.
    
    When the protocol is set via the sysfs protocols attribute, the
    decoder is loaded. However, when it is not when a device is first
    plugged in or registered.
    
    Fixes: acc1c3c ("[media] media: rc: load decoder modules on-demand")
    
    Signed-off-by: Sean Young <sean@mess.org>
    Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 21582cd0b64ca464084cb872b3d348065b0b54af
Author: Mikulas Patocka <mpatocka@redhat.com>
Date:   Wed Feb 15 11:26:10 2017 -0500

    dm: flush queued bios when process blocks to avoid deadlock
    
    commit d67a5f4b5947aba4bfe9a80a2b86079c215ca755 upstream.
    
    Commit df2cb6daa4 ("block: Avoid deadlocks with bio allocation by
    stacking drivers") created a workqueue for every bio set and code
    in bio_alloc_bioset() that tries to resolve some low-memory deadlocks
    by redirecting bios queued on current->bio_list to the workqueue if the
    system is low on memory.  However other deadlocks (see below **) may
    happen, without any low memory condition, because generic_make_request
    is queuing bios to current->bio_list (rather than submitting them).
    
    ** the related dm-snapshot deadlock is detailed here:
    https://www.redhat.com/archives/dm-devel/2016-July/msg00065.html
    
    Fix this deadlock by redirecting any bios on current->bio_list to the
    bio_set's rescue workqueue on every schedule() call.  Consequently,
    when the process blocks on a mutex, the bios queued on
    current->bio_list are dispatched to independent workqueus and they can
    complete without waiting for the mutex to be available.
    
    The structure blk_plug contains an entry cb_list and this list can contain
    arbitrary callback functions that are called when the process blocks.
    To implement this fix DM (ab)uses the onstack plug's cb_list interface
    to get its flush_current_bio_list() called at schedule() time.
    
    This fixes the snapshot deadlock - if the map method blocks,
    flush_current_bio_list() will be called and it redirects bios waiting
    on current->bio_list to appropriate workqueues.
    
    Fixes: https://bugzilla.redhat.com/show_bug.cgi?id=1267650
    Depends-on: df2cb6daa4 ("block: Avoid deadlocks with bio allocation by stacking drivers")
    Signed-off-by: Mikulas Patocka <mpatocka@redhat.com>
    Signed-off-by: Mike Snitzer <snitzer@redhat.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit d29e6215e5ab9a6b64b5cee57598ae8ec05666a1
Author: Jintack Lim <jintack@cs.columbia.edu>
Date:   Mon Mar 6 05:42:37 2017 -0800

    KVM: arm/arm64: Let vcpu thread modify its own active state
    
    commit 370a0ec1819990f8e2a93df7cc9c0146980ed45f upstream.
    
    Currently, if a vcpu thread tries to change the active state of an
    interrupt which is already on the same vcpu's AP list, it will loop
    forever. Since the VGIC mmio handler is called after a vcpu has
    already synced back the LR state to the struct vgic_irq, we can just
    let it proceed safely.
    
    Reviewed-by: Marc Zyngier <marc.zyngier@arm.com>
    Signed-off-by: Jintack Lim <jintack@cs.columbia.edu>
    Signed-off-by: Christoffer Dall <cdall@linaro.org>
    Signed-off-by: Marc Zyngier <marc.zyngier@arm.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 9d89c20f3b8f82ddb1d7ef63748ad74691549e80
Author: Janosch Frank <frankja@linux.vnet.ibm.com>
Date:   Thu Mar 2 15:23:42 2017 +0100

    KVM: s390: Fix guest migration for huge guests resulting in panic
    
    commit 2e4d88009f57057df7672fa69a32b5224af54d37 upstream.
    
    While we can technically not run huge page guests right now, we can
    setup a guest with huge pages. Trying to migrate it will trigger a
    VM_BUG_ON and, if the kernel is not configured to panic on a BUG, it
    will happily try to work on non-existing page table entries.
    
    With this patch, we always return "dirty" if we encounter a large page
    when migrating. This at least fixes the immediate problem until we
    have proper handling for both kind of pages.
    
    Fixes: 15f36eb ("KVM: s390: Add proper dirty bitmap support to S390 kvm.")
    Signed-off-by: Janosch Frank <frankja@linux.vnet.ibm.com>
    Acked-by: Christian Borntraeger <borntraeger@de.ibm.com>
    Signed-off-by: Martin Schwidefsky <schwidefsky@de.ibm.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit ce8ab5f168f654101ecba3f4443b12d4afdee841
Author: Krzysztof Kozlowski <krzk@kernel.org>
Date:   Sat Feb 25 18:36:44 2017 +0200

    serial: samsung: Continue to work if DMA request fails
    
    commit f98c7bce570bdbe344b74ff5daa7dfeef3f22929 upstream.
    
    If DMA is not available (even when configured in DeviceTree), the driver
    will fail the startup procedure thus making serial console not
    available.
    
    For example this causes boot failure on QEMU ARMv7 (Exynos4210, SMDKC210):
        [    1.302575] OF: amba_device_add() failed (-19) for /amba/pdma@12680000
        ...
        [   11.435732] samsung-uart 13800000.serial: DMA request failed
        [   72.963893] samsung-uart 13800000.serial: DMA request failed
        [   73.143361] Kernel panic - not syncing: Attempted to kill init! exitcode=0x00000000
    
    DMA is not necessary for serial to work, so continue with UART startup
    after emitting a warning.
    
    Fixes: 62c37eedb74c ("serial: samsung: add dma reqest/release functions")
    Signed-off-by: Krzysztof Kozlowski <krzk@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit d0ef6ecee85e17742d8bce1559872cb542d6ccac
Author: Johan Hovold <johan@kernel.org>
Date:   Mon Mar 6 17:36:40 2017 +0100

    USB: serial: io_ti: fix information leak in completion handler
    
    commit 654b404f2a222f918af9b0cd18ad469d0c941a8e upstream.
    
    Add missing sanity check to the bulk-in completion handler to avoid an
    integer underflow that can be triggered by a malicious device.
    
    This avoids leaking 128 kB of memory content from after the URB transfer
    buffer to user space.
    
    Fixes: 8c209e6782ca ("USB: make actual_length in struct urb field u32")
    Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2")
    Signed-off-by: Johan Hovold <johan@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 449b0bb23708ad5e1c0c214632dead8fc5273098
Author: Johan Hovold <johan@kernel.org>
Date:   Mon Mar 6 17:36:37 2017 +0100

    USB: serial: io_ti: fix NULL-deref in interrupt callback
    
    commit 0b1d250afb8eb9d65afb568bac9b9f9253a82b49 upstream.
    
    Fix a NULL-pointer dereference in the interrupt callback should a
    malicious device send data containing a bad port number by adding the
    missing sanity check.
    
    Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2")
    Signed-off-by: Johan Hovold <johan@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit f06b17020a848721f157524c7aed1cea43ea5131
Author: Johan Hovold <johan@kernel.org>
Date:   Tue Mar 7 16:11:04 2017 +0100

    USB: iowarrior: fix NULL-deref in write
    
    commit de46e56653de7b3b54baa625bd582635008b8d05 upstream.
    
    Make sure to verify that we have the required interrupt-out endpoint for
    IOWarrior56 devices to avoid dereferencing a NULL-pointer in write
    should a malicious device lack such an endpoint.
    
    Fixes: 946b960d13c1 ("USB: add driver for iowarrior devices.")
    Signed-off-by: Johan Hovold <johan@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 653418adaf1026a10e0c2e4e29b7319610117b33
Author: Johan Hovold <johan@kernel.org>
Date:   Tue Mar 7 16:11:03 2017 +0100

    USB: iowarrior: fix NULL-deref at probe
    
    commit b7321e81fc369abe353cf094d4f0dc2fe11ab95f upstream.
    
    Make sure to check for the required interrupt-in endpoint to avoid
    dereferencing a NULL-pointer should a malicious device lack such an
    endpoint.
    
    Note that a fairly recent change purported to fix this issue, but added
    an insufficient test on the number of endpoints only, a test which can
    now be removed.
    
    Fixes: 4ec0ef3a8212 ("USB: iowarrior: fix oops with malicious USB descriptors")
    Fixes: 946b960d13c1 ("USB: add driver for iowarrior devices.")
    Signed-off-by: Johan Hovold <johan@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 6d6c5895f45431579c20f4183b25183f0e3afc92
Author: Johan Hovold <johan@kernel.org>
Date:   Mon Mar 6 17:36:38 2017 +0100

    USB: serial: omninet: fix reference leaks at open
    
    commit 30572418b445d85fcfe6c8fe84c947d2606767d8 upstream.
    
    This driver needlessly took another reference to the tty on open, a
    reference which was then never released on close. This lead to not just
    a leak of the tty, but also a driver reference leak that prevented the
    driver from being unloaded after a port had once been opened.
    
    Fixes: 4a90f09b20f4 ("tty: usb-serial krefs")
    Signed-off-by: Johan Hovold <johan@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 0ab90ddba78a3fb34c34971ec36f2d51ba7827ec
Author: Johan Hovold <johan@kernel.org>
Date:   Mon Mar 6 17:36:41 2017 +0100

    USB: serial: safe_serial: fix information leak in completion handler
    
    commit 8c76d7cd520ebffc1ea9ea0850d87a224a50c7f2 upstream.
    
    Add missing sanity check to the bulk-in completion handler to avoid an
    integer underflow that could be triggered by a malicious device.
    
    This avoids leaking up to 56 bytes from after the URB transfer buffer to
    user space.
    
    Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2")
    Signed-off-by: Johan Hovold <johan@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 24db1c5a1c52c74b0218847c0a4cb1b40678cf84
Author: Guenter Roeck <linux@roeck-us.net>
Date:   Thu Mar 9 15:39:37 2017 +0200

    usb: host: xhci-plat: Fix timeout on removal of hot pluggable xhci controllers
    
    commit dcc7620cad5ad1326a78f4031a7bf4f0e5b42984 upstream.
    
    Upstream commit 98d74f9ceaef ("xhci: fix 10 second timeout on removal of
    PCI hotpluggable xhci controllers") fixes a problem with hot pluggable PCI
    xhci controllers which can result in excessive timeouts, to the point where
    the system reports a deadlock.
    
    The same problem is seen with hot pluggable xhci controllers using the
    xhci-plat driver, such as the driver used for Type-C ports on rk3399.
    Similar to hot-pluggable PCI controllers, the driver for this chip
    removes the xhci controller from the system when the Type-C cable is
    disconnected.
    
    The solution for PCI devices works just as well for non-PCI devices
    and avoids the problem.
    
    Signed-off-by: Guenter Roeck <linux@roeck-us.net>
    Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit d863767907527f0d43ea856a78c060d1f3599ac9
Author: Peter Chen <peter.chen@nxp.com>
Date:   Thu Mar 9 15:39:36 2017 +0200

    usb: host: xhci-dbg: HCIVERSION should be a binary number
    
    commit f95e60a7dbecd2de816bb3ad517b3d4fbc20b507 upstream.
    
    According to xHCI spec, HCIVERSION containing a BCD encoding
    of the xHCI specification revision number, 0100h corresponds
    to xHCI version 1.0. Change "100" as "0x100".
    
    Cc: Lu Baolu <baolu.lu@linux.intel.com>
    Fixes: 04abb6de2825 ("xhci: Read and parse new xhci 1.1 capability register")
    Signed-off-by: Peter Chen <peter.chen@nxp.com>
    Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 03123df08e6b77c0491af64e46054dbef5a1cea4
Author: Roger Quadros <rogerq@ti.com>
Date:   Thu Mar 2 10:44:58 2017 +0200

    Revert "usb: gadget: uvc: Add missing call for additional setup data"
    
    commit eb38d913c27f32f4df173791051fecf6aca34173 upstream.
    
    This reverts commit 4fbac5206afd01b717d4bdc58793d471f3391b4b.
    
    This commit breaks g_webcam when used with uvc-gadget [1].
    
    The user space application (e.g. uvc-gadget) is responsible for
    sending response to UVC class specific requests on control endpoint
    in uvc_send_response() in uvc_v4l2.c.
    
    The bad commit was causing a duplicate response to be sent with
    incorrect response data thus causing UVC probe to fail at the host
    and broken control transfer endpoint at the gadget.
    
    [1] - git://git.ideasonboard.org/uvc-gadget.git
    
    Acked-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
    Signed-off-by: Roger Quadros <rogerq@ti.com>
    Signed-off-by: Felipe Balbi <felipe.balbi@linux.intel.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 5ce2e4ce4a8a02d1ca9ed0d4aeac7a24cd3a59b9
Author: Felipe Balbi <felipe.balbi@linux.intel.com>
Date:   Tue Jan 31 14:54:45 2017 +0200

    usb: gadget: function: f_fs: pass companion descriptor along
    
    commit 2bfa0719ac2a9b2f3c91345873d3cdebd0296ba9 upstream.
    
    If we're dealing with SuperSpeed endpoints, we need
    to make sure to pass along the companion descriptor
    and initialize fields needed by the Gadget
    API. Eventually, f_fs.c should be converted to use
    config_ep_by_speed() like all other functions,
    though.
    
    Signed-off-by: Felipe Balbi <felipe.balbi@linux.intel.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 40192c96660f46b9aaaf2b8196856d230f859aca
Author: Jelle Martijn Kok <jmkok@youcom.nl>
Date:   Tue Feb 21 12:48:18 2017 +0100

    usb: ohci-at91: Do not drop unhandled USB suspend control requests
    
    commit 85550f9148a852ed363a386577ad31b97b95dfb8 upstream.
    
    In patch 2e2aa1bc7eff90ecm, USB suspend and wakeup control requests are
    passed to SFR_OHCIICR register. If a processor does not have such a
    register, this hub control request will be dropped.
    
    If no such a SFR register is available, all USB suspend control requests
    will now be processed using ohci_hub_control()
    (like before patch 2e2aa1bc7eff90ecm.)
    
    Tested on an Atmel AT91SAM9G20 with an on-board TI TUSB2046B hub chip
    If the last USB device is unplugged from the USB hub, the hub goes into
    sleep and will not wakeup when an USB devices is inserted.
    
    Fixes: 2e2aa1bc7eff90ec ("usb: ohci-at91: Forcibly suspend ports while USB suspend")
    Signed-off-by: Jelle Martijn Kok <jmkok@youcom.nl>
    Tested-by: Wenyou Yang <wenyou.yang@atmel.com>
    Cc: Wenyou Yang <wenyou.yang@atmel.com>
    Cc: Alan Stern <stern@rowland.harvard.edu>
    Acked-by: Nicolas Ferre <nicolas.ferre@microchip.com>
    Reviewed-by: Alexandre Belloni <alexandre.belloni@free-electrons.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit accadd8164b7a45645c8287839ca9d648415cb5e
Author: Roger Quadros <rogerq@ti.com>
Date:   Wed Feb 15 13:38:22 2017 +0200

    usb: dwc3-omap: Fix missing break in dwc3_omap_set_mailbox()
    
    commit 0913750f9fb6f26bcd00c8f9dd9a8d1b8d031246 upstream.
    
    We need to break from all cases if we want to treat
    each one of them separately.
    
    Reported-by: Gustavo A. R. Silva <garsilva@embeddedor.com>
    Fixes: d2728fb3e01f ("usb: dwc3: omap: Pass VBUS and ID events transparently")
    Signed-off-by: Roger Quadros <rogerq@ti.com>
    Signed-off-by: Felipe Balbi <felipe.balbi@linux.intel.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 808ee146d733ff2792a26d715ac72e6e745c9a47
Author: Felipe Balbi <felipe.balbi@linux.intel.com>
Date:   Tue Jan 31 13:24:54 2017 +0200

    usb: dwc3: gadget: make Set Endpoint Configuration macros safe
    
    commit 7369090a9fb57c3fc705ce355d2e4523a5a24716 upstream.
    
    Some gadget drivers are bad, bad boys. We notice
    that ADB was passing bad Burst Size which caused top
    bits of param0 to be overwritten which confused DWC3
    when running this command.
    
    In order to avoid future issues, we're going to make
    sure values passed by macros are always safe for the
    controller. Note that ADB still needs a fix to *not*
    pass bad values.
    
    Reported-by: Mohamed Abbas <mohamed.abbas@intel.com>
    Sugested-by: Adam Andruszak <adam.andruszak@intel.com>
    Signed-off-by: Felipe Balbi <felipe.balbi@linux.intel.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit de90394b0c6b9cf6e84c8a9ecfb9673e31b88a19
Author: Peter Chen <peter.chen@nxp.com>
Date:   Tue Feb 28 14:25:45 2017 +0800

    usb: gadget: dummy_hcd: clear usb_gadget region before registration
    
    commit 5bbc852676ae08e818241cf66a3ffe4be44225c4 upstream.
    
    When the user does device unbind and rebind test, the kernel will
    show below dump due to usb_gadget memory region is dirty after unbind.
    Clear usb_gadget region for every new probe.
    
    root@imx6qdlsolo:/sys/bus/platform/drivers/dummy_udc# echo dummy_udc.0 > bind
    [  102.523312] kobject (eddd78b0): tried to init an initialized object, something is seriously wrong.
    [  102.532447] CPU: 0 PID: 734 Comm: sh Not tainted 4.10.0-rc7-00872-g1b2b8e9 #1298
    [  102.539866] Hardware name: Freescale i.MX6 SoloX (Device Tree)
    [  102.545717] Backtrace:
    [  102.548225] [<c010d090>] (dump_backtrace) from [<c010d338>] (show_stack+0x18/0x1c)
    [  102.555822]  r7:ede34000 r6:60010013 r5:00000000 r4:c0f29418
    [  102.561512] [<c010d320>] (show_stack) from [<c040c2a4>] (dump_stack+0xb4/0xe8)
    [  102.568764] [<c040c1f0>] (dump_stack) from [<c040e6d4>] (kobject_init+0x80/0x9c)
    [  102.576187]  r10:0000001f r9:eddd7000 r8:eeaf8c10 r7:eddd78a8 r6:c177891c r5:c0f3b060
    [  102.584036]  r4:eddd78b0 r3:00000000
    [  102.587641] [<c040e654>] (kobject_init) from [<c05359a4>] (device_initialize+0x28/0xf8)
    [  102.595665]  r5:eebc4800 r4:eddd78a8
    [  102.599268] [<c053597c>] (device_initialize) from [<c05382ac>] (device_register+0x14/0x20)
    [  102.607556]  r7:eddd78a8 r6:00000000 r5:eebc4800 r4:eddd78a8
    [  102.613256] [<c0538298>] (device_register) from [<c0668ef4>] (usb_add_gadget_udc_release+0x8c/0x1ec)
    [  102.622410]  r5:eebc4800 r4:eddd7860
    [  102.626015] [<c0668e68>] (usb_add_gadget_udc_release) from [<c0669068>] (usb_add_gadget_udc+0x14/0x18)
    [  102.635351]  r10:0000001f r9:eddd7000 r8:eddd788c r7:bf003770 r6:eddd77f8 r5:eddd7818
    [  102.643198]  r4:eddd785c r3:eddd7b24
    [  102.646834] [<c0669054>] (usb_add_gadget_udc) from [<bf003428>] (dummy_udc_probe+0x170/0x1c4 [dummy_hcd])
    [  102.656458] [<bf0032b8>] (dummy_udc_probe [dummy_hcd]) from [<c053d114>] (platform_drv_probe+0x54/0xb8)
    [  102.665881]  r10:00000008 r9:c1778960 r8:bf004128 r7:fffffdfb r6:bf004128 r5:eeaf8c10
    [  102.673727]  r4:eeaf8c10
    [  102.676293] [<c053d0c0>] (platform_drv_probe) from [<c053b160>] (driver_probe_device+0x264/0x474)
    [  102.685186]  r7:00000000 r6:00000000 r5:c1778960 r4:eeaf8c10
    [  102.690876] [<c053aefc>] (driver_probe_device) from [<c05397c4>] (bind_store+0xb8/0x14c)
    [  102.698994]  r10:eeb3bb4c r9:ede34000 r8:0000000c r7:eeaf8c44 r6:bf004128 r5:c0f3b668
    [  102.706840]  r4:eeaf8c10
    [  102.709402] [<c053970c>] (bind_store) from [<c0538ca8>] (drv_attr_store+0x28/0x34)
    [  102.716998]  r9:ede34000 r8:00000000 r7:ee3863c0 r6:ee3863c0 r5:c0538c80 r4:c053970c
    [  102.724776] [<c0538c80>] (drv_attr_store) from [<c029c930>] (sysfs_kf_write+0x50/0x54)
    [  102.732711]  r5:c0538c80 r4:0000000c
    [  102.736313] [<c029c8e0>] (sysfs_kf_write) from [<c029be84>] (kernfs_fop_write+0x100/0x214)
    [  102.744599]  r7:ee3863c0 r6:eeb3bb40 r5:00000000 r4:00000000
    [  102.750287] [<c029bd84>] (kernfs_fop_write) from [<c0222dd8>] (__vfs_write+0x34/0x120)
    [  102.758231]  r10:00000000 r9:ede34000 r8:c0108bc4 r7:0000000c r6:ede35f80 r5:c029bd84
    [  102.766077]  r4:ee223780
    [  102.768638] [<c0222da4>] (__vfs_write) from [<c0224678>] (vfs_write+0xa8/0x170)
    [  102.775974]  r9:ede34000 r8:c0108bc4 r7:ede35f80 r6:01861cb0 r5:ee223780 r4:0000000c
    [  102.783743] [<c02245d0>] (vfs_write) from [<c0225498>] (SyS_write+0x4c/0xa8)
    [  102.790818]  r9:ede34000 r8:c0108bc4 r7:0000000c r6:01861cb0 r5:ee223780 r4:ee223780
    [  102.798595] [<c022544c>] (SyS_write) from [<c0108a20>] (ret_fast_syscall+0x0/0x1c)
    [  102.806188]  r7:00000004 r6:b6e83d58 r5:01861cb0 r4:0000000c
    
    Fixes: 90fccb529d24 ("usb: gadget: Gadget directory cleanup - group UDC drivers")
    Acked-by: Alan Stern <stern@rowland.harvard.edu>
    Signed-off-by: Peter Chen <peter.chen@nxp.com>
    Tested-by: Xiaolong Ye <xiaolong.ye@intel.com>
    Reported-by: Fengguang Wu <fengguang.wu@intel.com>
    Signed-off-by: Felipe Balbi <felipe.balbi@linux.intel.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit ed99f5a09cc6ef662fd29a4ad50b221608a635a8
Author: Ethan Zhao <ethan.zhao@oracle.com>
Date:   Mon Feb 27 17:08:44 2017 +0900

    PCI: Prevent VPD access for QLogic ISP2722
    
    commit 0d5370d1d85251e5893ab7c90a429464de2e140b upstream.
    
    QLogic ISP2722-based 16/32Gb Fibre Channel to PCIe Adapter has the VPD
    access issue too, while read the common pci-sysfs access interface shown as
    
     /sys/devices/pci0000:00/0000:00:03.2/0000:0b:00.0/vpd
    
    with simple 'cat' could cause system hang and panic:
    
      Kernel panic - not syncing: An NMI occurred. Depending on your system the reason for the NMI is logged in any one of the following resources:
      1. Integrated Management Log (IML)
      2. OA Syslog
      3. OA Forward Progress Log
      4. iLO Event Log
      CPU: 0 PID: 15070 Comm: udevadm Not tainted 4.1.12
      Hardware name: HP ProLiant DL380 Gen9/ProLiant DL380 Gen9, BIOS P89 12/27/2015
       0000000000000086 000000007f0cdf51 ffff880c4fa05d58 ffffffff817193de
       ffffffffa00b42d8 0000000000000075 ffff880c4fa05dd8 ffffffff81714072
       0000000000000008 ffff880c4fa05de8 ffff880c4fa05d88 000000007f0cdf51
      Call Trace:
       <NMI>  [<ffffffff817193de>] dump_stack+0x63/0x81
       [<ffffffff81714072>] panic+0xd0/0x20e
       [<ffffffffa00b390d>] hpwdt_pretimeout+0xdd/0xe0 [hpwdt]
       [<ffffffff81021fc9>] ? sched_clock+0x9/0x10
       [<ffffffff8101c101>] nmi_handle+0x91/0x170
       [<ffffffff8101c10c>] ? nmi_handle+0x9c/0x170
       [<ffffffff8101c5fe>] io_check_error+0x1e/0xa0
       [<ffffffff8101c719>] default_do_nmi+0x99/0x140
       [<ffffffff8101c8b4>] do_nmi+0xf4/0x170
       [<ffffffff817232c5>] end_repeat_nmi+0x1a/0x1e
       [<ffffffff815d724b>] ? pci_conf1_read+0xeb/0x120
       [<ffffffff815d724b>] ? pci_conf1_read+0xeb/0x120
       [<ffffffff815d724b>] ? pci_conf1_read+0xeb/0x120
       <<EOE>>  [<ffffffff815db4b3>] raw_pci_read+0x23/0x40
       [<ffffffff815db4fc>] pci_read+0x2c/0x30
       [<ffffffff8136f612>] pci_user_read_config_word+0x72/0x110
       [<ffffffff8136f746>] pci_vpd_pci22_wait+0x96/0x130
       [<ffffffff8136ff9b>] pci_vpd_pci22_read+0xdb/0x1a0
       [<ffffffff8136ea30>] pci_read_vpd+0x20/0x30
       [<ffffffff8137d590>] read_vpd_attr+0x30/0x40
       [<ffffffff8128e037>] sysfs_kf_bin_read+0x47/0x70
       [<ffffffff8128d24e>] kernfs_fop_read+0xae/0x180
       [<ffffffff8120dd97>] __vfs_read+0x37/0x100
       [<ffffffff812ba7e4>] ? security_file_permission+0x84/0xa0
       [<ffffffff8120e366>] ? rw_verify_area+0x56/0xe0
       [<ffffffff8120e476>] vfs_read+0x86/0x140
       [<ffffffff8120f3f5>] SyS_read+0x55/0xd0
       [<ffffffff81720f2e>] system_call_fastpath+0x12/0x71
      Shutting down cpus with NMI
      Kernel Offset: disabled
      drm_kms_helper: panic occurred, switching back to text console
    
    So blacklist the access to its VPD.
    
    Signed-off-by: Ethan Zhao <ethan.zhao@oracle.com>
    Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 1ced52ead2441c493afd80209dec5903f6cdc04a
Author: Balbir Singh <bsingharora@gmail.com>
Date:   Fri Mar 3 11:58:44 2017 +1100

    powerpc/xics: Work around limitations of OPAL XICS priority handling
    
    commit a69e2fb70350a66f91175cd2625f1e8215c5b6e9 upstream.
    
    The CPPR (Current Processor Priority Register) of a XICS interrupt
    presentation controller contains a value N, such that only interrupts
    with a priority "more favoured" than N will be received by the CPU,
    where "more favoured" means "less than". So if the CPPR has the value 5
    then only interrupts with a priority of 0-4 inclusive will be received.
    
    In theory the CPPR can support a value of 0 to 255 inclusive.
    In practice Linux only uses values of 0, 4, 5 and 0xff. Setting the CPPR
    to 0 rejects all interrupts, setting it to 0xff allows all interrupts.
    The values 4 and 5 are used to differentiate IPIs from external
    interrupts. Setting the CPPR to 5 allows IPIs to be received but not
    external interrupts.
    
    The CPPR emulation in the OPAL XICS implementation only directly
    supports priorities 0 and 0xff. All other priorities are considered
    equivalent, and mapped to a single priority value internally. This means
    when using icp-opal we can not allow IPIs but not externals.
    
    This breaks Linux's use of priority values when a CPU is hot unplugged.
    After migrating IRQs away from the CPU that is being offlined, we set
    the priority to 5, meaning we still want the offline CPU to receive
    IPIs. But the effect of the OPAL XICS emulation's use of a single
    priority value is that all interrupts are rejected by the CPU. With the
    CPU offline, and not receiving IPIs, we may not be able to wake it up to
    bring it back online.
    
    The first part of the fix is in icp_opal_set_cpu_priority(). CPPR values
    of 0 to 4 inclusive will correctly cause all interrupts to be rejected,
    so we pass those CPPR values through to OPAL. However if we are called
    with a CPPR of 5 or greater, the caller is expecting to be able to allow
    IPIs but not external interrupts. We know this doesn't work, so instead
    of rejecting all interrupts we choose the opposite which is to allow all
    interrupts. This is still not correct behaviour, but we know for the
    only existing caller (xics_migrate_irqs_away()), that it is the better
    option.
    
    The other part of the fix is in xics_migrate_irqs_away(). Instead of
    setting priority (CPPR) to 0, and then back to 5 before migrating IRQs,
    we migrate the IRQs before setting the priority back to 5. This should
    have no effect on an ICP backend with a working set_priority(), and on
    icp-opal it means we will keep all interrupts blocked until after we've
    finished doing the IRQ migration. Additionally we wait for 5ms after
    doing the migration to make sure there are no IRQs in flight.
    
    Fixes: d74361881f0d ("powerpc/xics: Add ICP OPAL backend")
    Suggested-by: Michael Ellerman <mpe@ellerman.id.au>
    Reported-by: Vaidyanathan Srinivasan <svaidy@linux.vnet.ibm.com>
    Tested-by: Vaidyanathan Srinivasan <svaidy@linux.vnet.ibm.com>
    Signed-off-by: Balbir Singh <bsingharora@gmail.com>
    [mpe: Rewrote comments and change log, change delay to 5ms]
    Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit bc8d2eefe63f6f0f4592ab735d4c95c58956dcf9
Author: Ravi Bangoria <ravi.bangoria@linux.vnet.ibm.com>
Date:   Tue Feb 14 14:46:42 2017 +0530

    powerpc: Emulation support for load/store instructions on LE
    
    commit e148bd17f48bd17fca2f4f089ec879fa6e47e34c upstream.
    
    emulate_step() uses a number of underlying kernel functions that were
    initially not enabled for LE. This has been rectified since. So, fix
    emulate_step() for LE for the corresponding instructions.
    
    Reported-by: Anton Blanchard <anton@samba.org>
    Signed-off-by: Ravi Bangoria <ravi.bangoria@linux.vnet.ibm.com>
    Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit ac4666a7fd1aab0b4e60240ab84f9fd839900669
Author: Qi Hou <qi.hou@windriver.com>
Date:   Fri Mar 3 15:57:11 2017 +0800

    i2c: add missing of_node_put in i2c_mux_del_adapters
    
    commit 2e1e4949f9dfb053122785cd73540bb1e61f768b upstream.
    
    Refcount of of_node is increased with of_node_get() in i2c_mux_add_adapter().
    It must be decreased with of_node_put() in i2c_mux_del_adapters().
    
    Signed-off-by: Qi Hou <qi.hou@windriver.com>
    Reviewed-by: Zhang Xiao <xiao.zhang@windriver.com>
    Signed-off-by: Peter Rosin <peda@axentia.se>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 06996254a605913cd7c1927d0e8a89b5138e110d
Author: Jonathan McDowell <noodles@earth.li>
Date:   Wed Feb 15 18:29:15 2017 -0200

    dw2102: don't do DMA on stack
    
    commit 606142af57dad981b78707234cfbd15f9f7b7125 upstream.
    
    On Kernel 4.9, WARNINGs about doing DMA on stack are hit at
    the dw2102 driver: one in su3000_power_ctrl() and the other in tt_s2_4600_frontend_attach().
    
    Both were due to the use of buffers on the stack as parameters to
    dvb_usb_generic_rw() and the resulting attempt to do DMA with them.
    
    The device was non-functional as a result.
    
    So, switch this driver over to use a buffer within the device state
    structure, as has been done with other DVB-USB drivers.
    
    Tested with TechnoTrend TT-connect S2-4600.
    
    [mchehab@osg.samsung.com: fixed a warning at su3000_i2c_transfer() that
     state var were dereferenced before check 'd']
    Signed-off-by: Jonathan McDowell <noodles@earth.li>
    Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 56d91e106b13f81fea9a6571240ab89eba6d9fe8
Author: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Date:   Wed Mar 1 19:05:54 2017 +0000

    efi/arm: Fix boot crash with CONFIG_CPUMASK_OFFSTACK=y
    
    commit d1eb98143c56f24fef125f5bbed49ae0b52fb7d6 upstream.
    
    On ARM and arm64, we use a dedicated mm_struct to map the UEFI
    Runtime Services regions, which allows us to map those regions
    on demand, and in a way that is guaranteed to be compatible
    with incoming kernels across kexec.
    
    As it turns out, we don't fully initialize the mm_struct in the
    same way as process mm_structs are initialized on fork(), which
    results in the following crash on ARM if CONFIG_CPUMASK_OFFSTACK=y
    is enabled:
    
      ...
      EFI Variables Facility v0.08 2004-May-17
      Unable to handle kernel NULL pointer dereference at virtual address 00000000
      [...]
      Process swapper/0 (pid: 1)
      ...
      __memzero()
      check_and_switch_context()
      virt_efi_get_next_variable()
      efivar_init()
      efivars_sysfs_init()
      do_one_initcall()
      ...
    
    This is due to a missing call to mm_init_cpumask(), so add it.
    
    Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
    Cc: Linus Torvalds <torvalds@linux-foundation.org>
    Cc: Matt Fleming <matt@codeblueprint.co.uk>
    Cc: Peter Zijlstra <peterz@infradead.org>
    Cc: Thomas Gleixner <tglx@linutronix.de>
    Cc: linux-efi@vger.kernel.org
    Link: http://lkml.kernel.org/r/1488395154-29786-1-git-send-email-ard.biesheuvel@linaro.org
    Signed-off-by: Ingo Molnar <mingo@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit ee6f7ee1e4cdb0098fee4593ddf11ca6028abef2
Author: Eric W. Biederman <ebiederm@xmission.com>
Date:   Sun Mar 5 15:03:22 2017 -0600

    ucount: Remove the atomicity from ucount->count
    
    commit 040757f738e13caaa9c5078bca79aa97e11dde88 upstream.
    
    Always increment/decrement ucount->count under the ucounts_lock.  The
    increments are there already and moving the decrements there means the
    locking logic of the code is simpler.  This simplification in the
    locking logic fixes a race between put_ucounts and get_ucounts that
    could result in a use-after-free because the count could go zero then
    be found by get_ucounts and then be freed by put_ucounts.
    
    A bug presumably this one was found by a combination of syzkaller and
    KASAN.  JongWhan Kim reported the syzkaller failure and Dmitry Vyukov
    spotted the race in the code.
    
    Fixes: f6b2db1a3e8d ("userns: Make the count of user namespaces per user")
    Reported-by: JongHwan Kim <zzoru007@gmail.com>
    Reported-by: Dmitry Vyukov <dvyukov@google.com>
    Reviewed-by: Andrei Vagin <avagin@gmail.com>
    Signed-off-by: "Eric W. Biederman" <ebiederm@xmission.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 8bb208d02accfe50cee2a9b5db3ea9da49a208b3
Author: Rik van Riel <riel@redhat.com>
Date:   Wed Sep 28 22:55:54 2016 -0400

    tracing: Add #undef to fix compile error
    
    commit bf7165cfa23695c51998231c4efa080fe1d3548d upstream.
    
    There are several trace include files that define TRACE_INCLUDE_FILE.
    
    Include several of them in the same .c file (as I currently have in
    some code I am working on), and the compile will blow up with a
    "warning: "TRACE_INCLUDE_FILE" redefined #define TRACE_INCLUDE_FILE syscalls"
    
    Every other include file in include/trace/events/ avoids that issue
    by having a #undef TRACE_INCLUDE_FILE before the #define; syscalls.h
    should have one, too.
    
    Link: http://lkml.kernel.org/r/20160928225554.13bd7ac6@annuminas.surriel.com
    
    Fixes: b8007ef74222 ("tracing: Separate raw syscall from syscall tracer")
    Signed-off-by: Rik van Riel <riel@redhat.com>
    Signed-off-by: Steven Rostedt (VMware) <rostedt@goodmis.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit b72ae5ca7a8be7cfa64c4f121b56cfb8ef088410
Author: Arnd Bergmann <arnd@arndb.de>
Date:   Mon Jan 16 14:20:54 2017 +0100

    cpmac: remove hopeless #warning
    
    commit d43e6fb4ac4abfe4ef7c102833ed02330ad701e0 upstream.
    
    The #warning was present 10 years ago when the driver first got merged.
    As the platform is rather obsolete by now, it seems very unlikely that
    the warning will cause anyone to fix the code properly.
    
    kernelci.org reports the warning for every build in the meantime, so
    I think it's better to just turn it into a code comment to reduce
    noise.
    
    Signed-off-by: Arnd Bergmann <arnd@arndb.de>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 04275d2a8af3269e2b0e04512a6b261dd3245545
Author: Arnd Bergmann <arnd@arndb.de>
Date:   Wed Jan 18 15:52:53 2017 +0100

    bcm63xx_enet: avoid uninitialized variable warning
    
    commit df384d435a5c034c735df3d9ea87a03172c59b56 upstream.
    
    gcc-7 and probably earlier versions get confused by this function
    and print a harmless warning:
    
    drivers/net/ethernet/broadcom/bcm63xx_enet.c: In function 'bcm_enet_open':
    drivers/net/ethernet/broadcom/bcm63xx_enet.c:1130:3: error: 'phydev' may be used uninitialized in this function [-Werror=maybe-uninitialized]
    
    This adds an initialization for the 'phydev' variable when it is unused
    and changes the check to test for that NULL pointer to make it clear
    that we always pass a valid pointer here.
    
    Signed-off-by: Arnd Bergmann <arnd@arndb.de>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit b7e968da04d77174477317b1b032be7f62ad856d
Author: Arnd Bergmann <arnd@arndb.de>
Date:   Tue Jan 17 16:18:43 2017 +0100

    MIPS: ralink: Remove unused rt*_wdt_reset functions
    
    commit 886f9c69fc68f56ddea34d3de51ac1fc2ac8dfbc upstream.
    
    All pointers to these functions were removed, so now they produce
    warnings:
    
    arch/mips/ralink/rt305x.c:92:13: error: 'rt305x_wdt_reset' defined but not used [-Werror=unused-function]
    
    This removes the functions. If we need them again, the patch can be
    reverted later.
    
    Fixes: f576fb6a0700 ("MIPS: ralink: cleanup the soc specific pinmux data")
    Signed-off-by: Arnd Bergmann <arnd@arndb.de>
    Cc: John Crispin <john@phrozen.org>
    Cc: Colin Ian King <colin.king@canonical.com>
    Cc: linux-mips@linux-mips.org
    Cc: linux-kernel@vger.kernel.org
    Patchwork: https://patchwork.linux-mips.org/patch/15044/
    Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit dd2419e1cec0498e688069ba84e5d90fd5651496
Author: Arnd Bergmann <arnd@arndb.de>
Date:   Tue Jan 17 16:18:41 2017 +0100

    MIPS: ralink: Remove unused timer functions
    
    commit d92240d12a9c010e0094bbc9280aae4a6be9a2d5 upstream.
    
    The functions were originally used for the module unload path,
    but are not referenced any more and just cause warnings:
    
    arch/mips/ralink/timer.c:104:13: error: 'rt_timer_disable' defined but not used [-Werror=unused-function]
    arch/mips/ralink/timer.c:74:13: error: 'rt_timer_free' defined but not used [-Werror=unused-function]
    
    Cc: Paul Gortmaker <paul.gortmaker@windriver.com>
    Fixes: 62ee73d284e7 ("MIPS: ralink: Make timer explicitly non-modular")
    Signed-off-by: Arnd Bergmann <arnd@arndb.de>
    Cc: Paul Gortmaker <paul.gortmaker@windriver.com>
    Cc: John Crispin <john@phrozen.org>
    Cc: linux-mips@linux-mips.org
    Cc: linux-kernel@vger.kernel.org
    Patchwork: https://patchwork.linux-mips.org/patch/15041/
    Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit f34064186f0ed2fd2a47175a11339509f8fc0034
Author: John Crispin <john@phrozen.org>
Date:   Tue Dec 20 19:12:46 2016 +0100

    MIPS: ralink: Cosmetic change to prom_init().
    
    commit 9c48568b3692f1a56cbf1935e4eea835e6b185b1 upstream.
    
    Over the years the code has been changed various times leading to
    argc/argv being defined in a different function to where we actually
    use the variables. Clean this up by moving them to prom_init_cmdline().
    
    Signed-off-by: John Crispin <john@phrozen.org>
    Cc: linux-mips@linux-mips.org
    Patchwork: https://patchwork.linux-mips.org/patch/14902/
    Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 7b767f6b515d196b832d178035cb865c67937312
Author: Arnd Bergmann <arnd@arndb.de>
Date:   Fri Feb 3 10:49:17 2017 +0100

    mtd: pmcmsp: use kstrndup instead of kmalloc+strncpy
    
    commit 906b268477bc03daaa04f739844c120fe4dbc991 upstream.
    
    kernelci.org reports a warning for this driver, as it copies a local
    variable into a 'const char *' string:
    
        drivers/mtd/maps/pmcmsp-flash.c:149:30: warning: passing argument 1 of 'strncpy' discards 'const' qualifier from pointer target type [-Wdiscarded-qualifiers]
    
    Using kstrndup() simplifies the code and avoids the warning.
    
    Signed-off-by: Arnd Bergmann <arnd@arndb.de>
    Acked-by: Marek Vasut <marek.vasut@gmail.com>
    Signed-off-by: Brian Norris <computersforpeace@gmail.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 976e40d7f6fe15212a0ce6ef0f687130285fecab
Author: Arnd Bergmann <arnd@arndb.de>
Date:   Wed Jan 11 15:29:49 2017 +0100

    MIPS: Update lemote2f_defconfig for CPU_FREQ_STAT change
    
    commit b3f6046186ef45acfeebc5a59c9fb45cefc685e7 upstream.
    
    Since linux-4.8, CPU_FREQ_STAT is a bool symbol, causing a warning in
    kernelci.org:
    
    arch/mips/configs/lemote2f_defconfig:42:warning: symbol value 'm' invalid for CPU_FREQ_STAT
    
    This updates the defconfig to have the feature built-in.
    
    Fixes: 1aefc75b2449 ("cpufreq: stats: Make the stats code non-modular")
    Signed-off-by: Arnd Bergmann <arnd@arndb.de>
    Cc: linux-mips@linux-mips.org
    Cc: linux-kernel@vger.kernel.org
    Patchwork: https://patchwork.linux-mips.org/patch/15000/
    Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit dd2ef28eb76e5cb573f18718275e607e4fc88283
Author: Arnd Bergmann <arnd@arndb.de>
Date:   Tue Jan 17 16:18:46 2017 +0100

    MIPS: ip22: Fix ip28 build for modern gcc
    
    commit 23ca9b522383d3b9b7991d8586db30118992af4a upstream.
    
    kernelci reports a failure of the ip28_defconfig build after upgrading its
    gcc version:
    
    arch/mips/sgi-ip22/Platform:29: *** gcc doesn't support needed option -mr10k-cache-barrier=store.  Stop.
    
    The problem apparently is that the -mr10k-cache-barrier=store option is now
    rejected for CPUs other than r10k. Explicitly including the CPU in the
    check fixes this and is safe because both options were introduced in
    gcc-4.4.
    
    Signed-off-by: Arnd Bergmann <arnd@arndb.de>
    Cc: linux-mips@linux-mips.org
    Cc: linux-kernel@vger.kernel.org
    Patchwork: https://patchwork.linux-mips.org/patch/15049/
    Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit aff853abd2988e16ed65cd0e15983aaf5312c7f6
Author: Arnd Bergmann <arnd@arndb.de>
Date:   Wed Jan 11 15:29:50 2017 +0100

    MIPS: Update ip27_defconfig for SCSI_DH change
    
    commit ea58fca1842a5dc410cae4167b01643db971a4e2 upstream.
    
    Since linux-4.3, SCSI_DH is a bool symbol, causing a warning in
    kernelci.org:
    
    arch/mips/configs/ip27_defconfig:136:warning: symbol value 'm' invalid for SCSI_DH
    
    This updates the defconfig to have the feature built-in.
    
    Fixes: 086b91d052eb ("scsi_dh: integrate into the core SCSI code")
    Signed-off-by: Arnd Bergmann <arnd@arndb.de>
    Cc: linux-mips@linux-mips.org
    Cc: linux-kernel@vger.kernel.org
    Patchwork: https://patchwork.linux-mips.org/patch/15001/
    Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 23096c56787e27b5eddf38874593806df0f819f3
Author: Arnd Bergmann <arnd@arndb.de>
Date:   Fri Feb 3 17:43:50 2017 +0100

    MIPS: ip27: Disable qlge driver in defconfig
    
    commit b617649468390713db1515ea79fc772d2eb897a8 upstream.
    
    One of the last remaining failures in kernelci.org is for a gcc bug:
    
    drivers/net/ethernet/qlogic/qlge/qlge_main.c:4819:1: error: insn does not satisfy its constraints:
    drivers/net/ethernet/qlogic/qlge/qlge_main.c:4819:1: internal compiler error: in extract_constrain_insn, at recog.c:2190
    
    This is apparently broken in gcc-6 but fixed in gcc-7, and I cannot
    reproduce the problem here. However, it is clear that ip27_defconfig
    does not actually need this driver as the platform has only PCI-X but
    not PCIe, and the qlge adapter in turn is PCIe-only.
    
    The driver was originally enabled in 2010 along with lots of other
    drivers.
    
    Fixes: 59d302b342e5 ("MIPS: IP27: Make defconfig useful again.")
    Signed-off-by: Arnd Bergmann <arnd@arndb.de>
    Cc: Ralf Baechle <ralf@linux-mips.org>
    Cc: linux-mips@linux-mips.org
    Cc: linux-kernel@vger.kernel.org
    Patchwork: https://patchwork.linux-mips.org/patch/15197/
    Signed-off-by: James Hogan <james.hogan@imgtec.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit ad8387a602280c27f979b81d95b908d46be68901
Author: Arnd Bergmann <arnd@arndb.de>
Date:   Tue Jan 17 16:18:36 2017 +0100

    MIPS: VDSO: avoid duplicate CAC_BASE definition
    
    commit 1742ac265046f34223e06d5d283496f0291be259 upstream.
    
    vdso.h includes <spaces.h> implicitly after defining CONFIG_32BITS.
    This defeats the override in mach-ip27/spaces.h, leading to
    a build error that shows up in kernelci.org:
    
    In file included from arch/mips/include/asm/mach-ip27/spaces.h:29:0,
                     from arch/mips/include/asm/page.h:12,
                     from arch/mips/vdso/vdso.h:26,
                     from arch/mips/vdso/gettimeofday.c:11:
    arch/mips/include/asm/mach-generic/spaces.h:28:0: error: "CAC_BASE" redefined [-Werror]
     #define CAC_BASE  _AC(0x80000000, UL)
    
    An earlier patch tried to make the second definition conditional,
    but that patch had the #ifdef in the wrong place, and would lead
    to another warning:
    
    arch/mips/include/asm/io.h: In function 'phys_to_virt':
    arch/mips/include/asm/io.h:138:9: error: cast to pointer from integer of different size [-Werror=int-to-pointer-cast]
    
    For all I can tell, there is no other reason than vdso32 to ever
    include this file with CONFIG_32BITS set, and the vdso itself should
    never refer to the base addresses as it is running in user space,
    so adding an #ifdef here is safe.
    
    Link: https://patchwork.kernel.org/patch/9418187/
    Fixes: 3ffc17d8768b ("MIPS: Adjust MIPS64 CAC_BASE to reflect Config.K0")
    Signed-off-by: Arnd Bergmann <arnd@arndb.de>
    Cc: Paul Burton <paul.burton@imgtec.com>
    Cc: linux-mips@linux-mips.org
    Cc: linux-kernel@vger.kernel.org
    Patchwork: https://patchwork.linux-mips.org/patch/15039/
    Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 5841e3d37db9ef1f9e154ae5059cd62e1a5aa934
Author: Arnd Bergmann <arnd@arndb.de>
Date:   Wed Jan 11 15:29:48 2017 +0100

    MIPS: Update defconfigs for NF_CT_PROTO_DCCP/UDPLITE change
    
    commit 9ddc16ad8e0bc7742fc96d5aaabc5b8698512cd1 upstream.
    
    In linux-4.10-rc, NF_CT_PROTO_UDPLITE and NF_CT_PROTO_DCCP are bool
    symbols instead of tristate, and kernelci.org reports a bunch of
    warnings for this, like:
    
    arch/mips/configs/malta_kvm_guest_defconfig:63:warning: symbol value 'm' invalid for NF_CT_PROTO_UDPLITE
    arch/mips/configs/malta_defconfig:62:warning: symbol value 'm' invalid for NF_CT_PROTO_DCCP
    arch/mips/configs/malta_defconfig:63:warning: symbol value 'm' invalid for NF_CT_PROTO_UDPLITE
    arch/mips/configs/ip22_defconfig:70:warning: symbol value 'm' invalid for NF_CT_PROTO_DCCP
    arch/mips/configs/ip22_defconfig:71:warning: symbol value 'm' invalid for NF_CT_PROTO_UDPLITE
    
    This changes all the MIPS defconfigs with these symbols to have them
    built-in.
    
    Fixes: 9b91c96c5d1f ("netfilter: conntrack: built-in support for UDPlite")
    Fixes: c51d39010a1b ("netfilter: conntrack: built-in support for DCCP")
    Signed-off-by: Arnd Bergmann <arnd@arndb.de>
    Cc: linux-mips@linux-mips.org
    Cc: linux-kernel@vger.kernel.org
    Patchwork: https://patchwork.linux-mips.org/patch/14999/
    Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 2c1820ea8dcc8105cf66d13c69f376de3d95f54f
Author: Arnd Bergmann <arnd@arndb.de>
Date:   Fri Feb 3 23:33:23 2017 +0100

    crypto: improve gcc optimization flags for serpent and wp512
    
    commit 7d6e9105026788c497f0ab32fa16c82f4ab5ff61 upstream.
    
    An ancient gcc bug (first reported in 2003) has apparently resurfaced
    on MIPS, where kernelci.org reports an overly large stack frame in the
    whirlpool hash algorithm:
    
    crypto/wp512.c:987:1: warning: the frame size of 1112 bytes is larger than 1024 bytes [-Wframe-larger-than=]
    
    With some testing in different configurations, I'm seeing large
    variations in stack frames size up to 1500 bytes for what should have
    around 300 bytes at most. I also checked the reference implementation,
    which is essentially the same code but also comes with some test and
    benchmarking infrastructure.
    
    It seems that recent compiler versions on at least arm, arm64 and powerpc
    have a partial fix for this problem, but enabling "-fsched-pressure", but
    even with that fix they suffer from the issue to a certain degree. Some
    testing on arm64 shows that the time needed to hash a given amount of
    data is roughly proportional to the stack frame size here, which makes
    sense given that the wp512 implementation is doing lots of loads for
    table lookups, and the problem with the overly large stack is a result
    of doing a lot more loads and stores for spilled registers (as seen from
    inspecting the object code).
    
    Disabling -fschedule-insns consistently fixes the problem for wp512,
    in my collection of cross-compilers, the results are consistently better
    or identical when comparing the stack sizes in this function, though
    some architectures (notable x86) have schedule-insns disabled by
    default.
    
    The four columns are:
    default: -O2
    press:   -O2 -fsched-pressure
    nopress: -O2 -fschedule-insns -fno-sched-pressure
    nosched: -O2 -no-schedule-insns (disables sched-pressure)
    
                                    default press   nopress nosched
    alpha-linux-gcc-4.9.3           1136    848     1136    176
    am33_2.0-linux-gcc-4.9.3        2100    2076    2100    2104
    arm-linux-gnueabi-gcc-4.9.3     848     848     1048    352
    cris-linux-gcc-4.9.3            272     272     272     272
    frv-linux-gcc-4.9.3             1128    1000    1128    280
    hppa64-linux-gcc-4.9.3          1128    336     1128    184
    hppa-linux-gcc-4.9.3            644     308     644     276
    i386-linux-gcc-4.9.3            352     352     352     352
    m32r-linux-gcc-4.9.3            720     656     720     268
    microblaze-linux-gcc-4.9.3      1108    604     1108    256
    mips64-linux-gcc-4.9.3          1328    592     1328    208
    mips-linux-gcc-4.9.3            1096    624     1096    240
    powerpc64-linux-gcc-4.9.3       1088    432     1088    160
    powerpc-linux-gcc-4.9.3         1080    584     1080    224
    s390-linux-gcc-4.9.3            456     456     624     360
    sh3-linux-gcc-4.9.3             292     292     292     292
    sparc64-linux-gcc-4.9.3         992     240     992     208
    sparc-linux-gcc-4.9.3           680     592     680     312
    x86_64-linux-gcc-4.9.3          224     240     272     224
    xtensa-linux-gcc-4.9.3          1152    704     1152    304
    
    aarch64-linux-gcc-7.0.0         224     224     1104    208
    arm-linux-gnueabi-gcc-7.0.1     824     824     1048    352
    mips-linux-gcc-7.0.0            1120    648     1120    272
    x86_64-linux-gcc-7.0.1          240     240     304     240
    
    arm-linux-gnueabi-gcc-4.4.7     840                     392
    arm-linux-gnueabi-gcc-4.5.4     784     728     784     320
    arm-linux-gnueabi-gcc-4.6.4     736     728     736     304
    arm-linux-gnueabi-gcc-4.7.4     944     784     944     352
    arm-linux-gnueabi-gcc-4.8.5     464     464     760     352
    arm-linux-gnueabi-gcc-4.9.3     848     848     1048    352
    arm-linux-gnueabi-gcc-5.3.1     824     824     1064    336
    arm-linux-gnueabi-gcc-6.1.1     808     808     1056    344
    arm-linux-gnueabi-gcc-7.0.1     824     824     1048    352
    
    Trying the same test for serpent-generic, the picture is a bit different,
    and while -fno-schedule-insns is generally better here than the default,
    -fsched-pressure wins overall, so I picked that instead.
    
                                    default press   nopress nosched
    alpha-linux-gcc-4.9.3           1392    864     1392    960
    am33_2.0-linux-gcc-4.9.3        536     524     536     528
    arm-linux-gnueabi-gcc-4.9.3     552     552     776     536
    cris-linux-gcc-4.9.3            528     528     528     528
    frv-linux-gcc-4.9.3             536     400     536     504
    hppa64-linux-gcc-4.9.3          524     208     524     480
    hppa-linux-gcc-4.9.3            768     472     768     508
    i386-linux-gcc-4.9.3            564     564     564     564
    m32r-linux-gcc-4.9.3            712     576     712     532
    microblaze-linux-gcc-4.9.3      724     392     724     512
    mips64-linux-gcc-4.9.3          720     384     720     496
    mips-linux-gcc-4.9.3            728     384     728     496
    powerpc64-linux-gcc-4.9.3       704     304     704     480
    powerpc-linux-gcc-4.9.3         704     296     704     480
    s390-linux-gcc-4.9.3            560     560     592     536
    sh3-linux-gcc-4.9.3             540     540     540     540
    sparc64-linux-gcc-4.9.3         544     352     544     496
    sparc-linux-gcc-4.9.3           544     344     544     496
    x86_64-linux-gcc-4.9.3          528     536     576     528
    xtensa-linux-gcc-4.9.3          752     544     752     544
    
    aarch64-linux-gcc-7.0.0         432     432     656     480
    arm-linux-gnueabi-gcc-7.0.1     616     616     808     536
    mips-linux-gcc-7.0.0            720     464     720     488
    x86_64-linux-gcc-7.0.1          536     528     600     536
    
    arm-linux-gnueabi-gcc-4.4.7     592                     440
    arm-linux-gnueabi-gcc-4.5.4     776     448     776     544
    arm-linux-gnueabi-gcc-4.6.4     776     448     776     544
    arm-linux-gnueabi-gcc-4.7.4     768     448     768     544
    arm-linux-gnueabi-gcc-4.8.5     488     488     776     544
    arm-linux-gnueabi-gcc-4.9.3     552     552     776     536
    arm-linux-gnueabi-gcc-5.3.1     552     552     776     536
    arm-linux-gnueabi-gcc-6.1.1     560     560     776     536
    arm-linux-gnueabi-gcc-7.0.1     616     616     808     536
    
    I did not do any runtime tests with serpent, so it is possible that stack
    frame size does not directly correlate with runtime performance here and
    it actually makes things worse, but it's more likely to help here, and
    the reduced stack frame size is probably enough reason to apply the patch,
    especially given that the crypto code is often used in deep call chains.
    
    Link: https://kernelci.org/build/id/58797d7559b5149efdf6c3a9/logs/
    Link: http://www.larc.usp.br/~pbarreto/WhirlpoolPage.html
    Link: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=11488
    Link: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79149
    Cc: Ralf Baechle <ralf@linux-mips.org>
    Signed-off-by: Arnd Bergmann <arnd@arndb.de>
    Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit ce4d67cb3e6ee305437a3034de239f1dd4441d44
Author: Johan Hovold <johan@kernel.org>
Date:   Fri Feb 24 19:11:28 2017 +0100

    USB: serial: digi_acceleport: fix OOB-event processing
    
    commit 2e46565cf622dd0534a9d8bffe152a577b48d7aa upstream.
    
    A recent change claimed to fix an off-by-one error in the OOB-port
    completion handler, but instead introduced such an error. This could
    specifically led to modem-status changes going unnoticed, effectively
    breaking TIOCMGET.
    
    Note that the offending commit fixes a loop-condition underflow and is
    marked for stable, but should not be backported without this fix.
    
    Reported-by: Ben Hutchings <ben@decadent.org.uk>
    Fixes: 2d380889215f ("USB: serial: digi_acceleport: fix OOB data sanity
    check")
    Signed-off-by: Johan Hovold <johan@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit e1533c46151cedb8904f3f88d6c2fc0753e46c0f
Author: Johan Hovold <johan@kernel.org>
Date:   Tue Jan 31 17:17:27 2017 +0100

    USB: serial: digi_acceleport: fix OOB data sanity check
    
    commit 2d380889215fe20b8523345649dee0579821800c upstream.
    
    Make sure to check for short transfers to avoid underflow in a loop
    condition when parsing the receive buffer.
    
    Also fix an off-by-one error in the incomplete sanity check which could
    lead to invalid data being parsed.
    
    Fixes: 8c209e6782ca ("USB: make actual_length in struct urb field u32")
    Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2")
    Reviewed-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Signed-off-by: Johan Hovold <johan@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>