commit f07cb3489cff38984a8df4d3a0fea5d0858c1eb0
Author: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Date:   Sun Sep 10 07:49:19 2017 +0200

    Linux 4.9.49

commit 8bc67f67b7631122f1047cd8f3c7edbda106d48d
Author: John Stultz <john.stultz@linaro.org>
Date:   Mon Jan 16 16:52:48 2017 -0800

    drm/bridge: adv7511: Switch to using drm_kms_helper_hotplug_event()
    
    commit 6d5104c5a6b56385426e15047050584794bb6254 upstream.
    
    In chasing down a previous issue with EDID probing from calling
    drm_helper_hpd_irq_event() from irq context, Laurent noticed
    that the DRM documentation suggests that
    drm_kms_helper_hotplug_event() should be used instead.
    
    Thus this patch replaces drm_helper_hpd_irq_event() with
    drm_kms_helper_hotplug_event(), which requires we update the
    connector.status entry and only call _hotplug_event() when the
    status changes.
    
    Cc: David Airlie <airlied@linux.ie>
    Cc: Archit Taneja <architt@codeaurora.org>
    Cc: Wolfram Sang <wsa+renesas@sang-engineering.com>
    Cc: Lars-Peter Clausen <lars@metafoo.de>
    Cc: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
    Cc: dri-devel@lists.freedesktop.org
    Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
    Tested-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
    Signed-off-by: John Stultz <john.stultz@linaro.org>
    Signed-off-by: Archit Taneja <architt@codeaurora.org>
    Link: http://patchwork.freedesktop.org/patch/msgid/1484614372-15342-3-git-send-email-john.stultz@linaro.org
    Signed-off-by: Thong Ho <thong.ho.px@rvc.renesas.com>
    Signed-off-by: Nhan Nguyen <nhan.nguyen.yb@renesas.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 8b5a7e4436228c98d6fc97071f3bddcd6a614915
Author: John Stultz <john.stultz@linaro.org>
Date:   Mon Jan 16 16:52:47 2017 -0800

    drm/bridge: adv7511: Use work_struct to defer hotplug handing to out of irq context
    
    commit 518cb7057a59b9441336d2e88a396d52b6ab0cce upstream.
    
    I was recently seeing issues with EDID probing, where
    the logic to wait for the EDID read bit to be set by the
    IRQ wasn't happening and the code would time out and fail.
    
    Digging deeper, I found this was due to the fact that
    IRQs were disabled as we were running in IRQ context from
    the HPD signal.
    
    Thus this patch changes the logic to handle the HPD signal
    via a work_struct so we can be out of irq context.
    
    With this patch, the EDID probing on hotplug does not time
    out.
    
    Cc: David Airlie <airlied@linux.ie>
    Cc: Archit Taneja <architt@codeaurora.org>
    Cc: Wolfram Sang <wsa+renesas@sang-engineering.com>
    Cc: Lars-Peter Clausen <lars@metafoo.de>
    Cc: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
    Cc: dri-devel@lists.freedesktop.org
    Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
    Tested-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
    Signed-off-by: John Stultz <john.stultz@linaro.org>
    Signed-off-by: Archit Taneja <architt@codeaurora.org>
    Link: http://patchwork.freedesktop.org/patch/msgid/1484614372-15342-2-git-send-email-john.stultz@linaro.org
    Signed-off-by: Thong Ho <thong.ho.px@rvc.renesas.com>
    Signed-off-by: Nhan Nguyen <nhan.nguyen.yb@renesas.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 7791b59153cb2adfe2fa4273b2f9c8925c3238ed
Author: Todd Poynor <toddpoynor@google.com>
Date:   Tue Aug 15 21:48:43 2017 -0700

    scsi: sg: recheck MMAP_IO request length with lock held
    
    commit 8d26f491116feaa0b16de370b6a7ba40a40fa0b4 upstream.
    
    Commit 1bc0eb044615 ("scsi: sg: protect accesses to 'reserved' page
    array") adds needed concurrency protection for the "reserve" buffer.
    Some checks that are initially made outside the lock are replicated once
    the lock is taken to ensure the checks and resulting decisions are made
    using consistent state.
    
    The check that a request with flag SG_FLAG_MMAP_IO set fits in the
    reserve buffer also needs to be performed again under the lock to ensure
    the reserve buffer length compared against matches the value in effect
    when the request is linked to the reserve buffer.  An -ENOMEM should be
    returned in this case, instead of switching over to an indirect buffer
    as for non-MMAP_IO requests.
    
    Signed-off-by: Todd Poynor <toddpoynor@google.com>
    Acked-by: Douglas Gilbert <dgilbert@interlog.com>
    Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit b06e1abf1ff26046f0f3369b7abe8a221dadf26b
Author: Todd Poynor <toddpoynor@google.com>
Date:   Tue Aug 15 22:41:08 2017 -0700

    scsi: sg: protect against races between mmap() and SG_SET_RESERVED_SIZE
    
    commit 6a8dadcca81fceff9976e8828cceb072873b7bd5 upstream.
    
    Take f_mutex around mmap() processing to protect against races with the
    SG_SET_RESERVED_SIZE ioctl.  Ensure the reserve buffer length remains
    consistent during the mapping operation, and set the "mmap called" flag
    to prevent further changes to the reserved buffer size as an atomic
    operation with the mapping.
    
    [mkp: fixed whitespace]
    
    Signed-off-by: Todd Poynor <toddpoynor@google.com>
    Acked-by: Douglas Gilbert <dgilbert@interlog.com>
    Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 5b9c6a54c629e38271acf833f75154f2f8333365
Author: Andrey Korolyov <andrey@xdel.ru>
Date:   Thu Aug 10 13:21:14 2017 +0300

    cs5536: add support for IDE controller variant
    
    commit 591b6bb605785c12a21e8b07a08a277065b655a5 upstream.
    
    Several legacy devices such as Geode-based Cisco ASA appliances
    and DB800 development board do possess CS5536 IDE controller
    with different PCI id than existing one. Using pata_generic is
    not always feasible as at least DB800 requires MSR quirk from
    pata_cs5536 to be used with vendor firmware.
    
    Signed-off-by: Andrey Korolyov <andrey@xdel.ru>
    Signed-off-by: Tejun Heo <tj@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit ec552ece1f25e8ecadf0afafe87ce314d13dc3e7
Author: Ben Hutchings <ben@decadent.org.uk>
Date:   Sun Sep 3 01:18:41 2017 +0100

    workqueue: Fix flag collision
    
    commit fbf1c41fc0f4d3574ac2377245efd666c1fa3075 upstream.
    
    Commit 0a94efb5acbb ("workqueue: implicit ordered attribute should be
    overridable") introduced a __WQ_ORDERED_EXPLICIT flag but gave it the
    same value as __WQ_LEGACY.  I don't believe these were intended to
    mean the same thing, so renumber __WQ_ORDERED_EXPLICIT.
    
    Fixes: 0a94efb5acbb ("workqueue: implicit ordered attribute should be ...")
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
    Signed-off-by: Tejun Heo <tj@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 25bdc516b58e84b96d3755b55c73674778055a41
Author: Ilia Mirkin <imirkin@alum.mit.edu>
Date:   Thu Aug 10 12:13:40 2017 -0400

    drm/nouveau/pci/msi: disable MSI on big-endian platforms by default
    
    commit bc60c90f472b6e762ea96ef384072145adc8d4af upstream.
    
    It appears that MSI does not work on either G5 PPC nor on a E5500-based
    platform, where other hardware is reported to work fine with MSI.
    
    Both tests were conducted with NV4x hardware, so perhaps other (or even
    this) hardware can be made to work. It's still possible to force-enable
    with config=NvMSI=1 on load.
    
    Signed-off-by: Ilia Mirkin <imirkin@alum.mit.edu>
    Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 078866740e3503825e8717c7f7f0cecf55817e09
Author: Christian Borntraeger <borntraeger@de.ibm.com>
Date:   Thu Aug 24 12:55:08 2017 +0200

    s390/mm: avoid empty zero pages for KVM guests to avoid postcopy hangs
    
    commit fa41ba0d08de7c975c3e94d0067553f9b934221f upstream.
    
    Right now there is a potential hang situation for postcopy migrations,
    if the guest is enabling storage keys on the target system during the
    postcopy process.
    
    For storage key virtualization, we have to forbid the empty zero page as
    the storage key is a property of the physical page frame.  As we enable
    storage key handling lazily we then drop all mappings for empty zero
    pages for lazy refaulting later on.
    
    This does not work with the postcopy migration, which relies on the
    empty zero page never triggering a fault again in the future. The reason
    is that postcopy migration will simply read a page on the target system
    if that page is a known zero page to fault in an empty zero page.  At
    the same time postcopy remembers that this page was already transferred
    - so any future userfault on that page will NOT be retransmitted again
    to avoid races.
    
    If now the guest enters the storage key mode while in postcopy, we will
    break this assumption of postcopy.
    
    The solution is to disable the empty zero page for KVM guests early on
    and not during storage key enablement. With this change, the postcopy
    migration process is guaranteed to start after no zero pages are left.
    
    As guest pages are very likely not empty zero pages anyway the memory
    overhead is also pretty small.
    
    While at it this also adds proper page table locking to the zero page
    removal.
    
    Signed-off-by: Christian Borntraeger <borntraeger@de.ibm.com>
    Acked-by: Janosch Frank <frankja@linux.vnet.ibm.com>
    Signed-off-by: Martin Schwidefsky <schwidefsky@de.ibm.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit c193becad9add8bb170e525872f95b80c99caca6
Author: Michael Moese <michael.moese@men.de>
Date:   Tue Aug 29 14:47:24 2017 +0200

    MCB: add support for SC31 to mcb-lpc
    
    commit acf5e051ac44d5dc60b21bc4734ef1b844d55551 upstream.
    
    This patch adds the resources and DMI ID's for the MEN SC31,
    which uses a different address region to map the LPC bus than
    the one used for the existing SC24.
    
    Signed-off-by: Michael Moese <michael.moese@men.de>
    [jth add stable tag]
    Signed-off-by: Johannes Thumshirn <jthumshirn@suse.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 0e720cd70631968e506e13fa366da77d4cf770e1
Author: Brian Norris <briannorris@chromium.org>
Date:   Thu Jun 29 18:23:54 2017 -0700

    mwifiex: correct channel stat buffer overflows
    
    commit 4b5dde2d6234ff5bc68e97e6901d1f2a0a7f3749 upstream.
    
    mwifiex records information about various channels as it receives scan
    information. It does this by appending to a buffer that was sized
    to the max number of supported channels on any band, but there are
    numerous problems:
    
    (a) scans can return info from more than one band (e.g., both 2.4 and 5
        GHz), so the determined "max" is not large enough
    (b) some firmware appears to return multiple results for a given
        channel, so the max *really* isn't large enough
    (c) there is no bounds checking when stashing these stats, so problems
        (a) and (b) can easily lead to buffer overflows
    
    Let's patch this by setting a slightly-more-correct max (that accounts
    for a combination of both 2.4G and 5G bands) and adding a bounds check
    when writing to our statistics buffer.
    
    Due to problem (b), we still might not properly report all known survey
    information (e.g., with "iw <dev> survey dump"), since duplicate results
    (or otherwise "larger than expected" results) will cause some
    truncation. But that's a problem for a future bugfix.
    
    (And because of this known deficiency, only log the excess at the WARN
    level, since that isn't visible by default in this driver and would
    otherwise be a bit too noisy.)
    
    Fixes: bf35443314ac ("mwifiex: channel statistics support for mwifiex")
    Cc: Avinash Patil <patila@marvell.com>
    Cc: Xinming Hu <huxm@marvell.com>
    Signed-off-by: Brian Norris <briannorris@chromium.org>
    Reviewed-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
    Reviewed-by: Ganapathi Bhat <gbhat@marvell.com>
    Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 5c23d3ed1190eb91ebb208d2fb8414b92b566a37
Author: Edwin Török <edvin.torok@citrix.com>
Date:   Thu Aug 3 10:30:06 2017 +0100

    dlm: avoid double-free on error path in dlm_device_{register,unregister}
    
    commit 55acdd926f6b21a5cdba23da98a48aedf19ac9c3 upstream.
    
    Can be reproduced when running dlm_controld (tested on 4.4.x, 4.12.4):
     # seq 1 100 | xargs -P0 -n1 dlm_tool join
     # seq 1 100 | xargs -P0 -n1 dlm_tool leave
    
    misc_register fails due to duplicate sysfs entry, which causes
    dlm_device_register to free ls->ls_device.name.
    In dlm_device_deregister the name was freed again, causing memory
    corruption.
    
    According to the comment in dlm_device_deregister the name should've been
    set to NULL when registration fails,
    so this patch does that.
    
    sysfs: cannot create duplicate filename '/dev/char/10:1'
    ------------[ cut here ]------------
    warning: cpu: 1 pid: 4450 at fs/sysfs/dir.c:31 sysfs_warn_dup+0x56/0x70
    modules linked in: msr rfcomm dlm ccm bnep dm_crypt uvcvideo
    videobuf2_vmalloc videobuf2_memops videobuf2_v4l2 videobuf2_core videodev
    btusb media btrtl btbcm btintel bluetooth ecdh_generic intel_rapl
    x86_pkg_temp_thermal intel_powerclamp coretemp kvm_intel kvm
    snd_hda_codec_hdmi irqbypass crct10dif_pclmul crc32_pclmul
    ghash_clmulni_intel thinkpad_acpi pcbc nvram snd_seq_midi
    snd_seq_midi_event aesni_intel snd_hda_codec_realtek snd_hda_codec_generic
    snd_rawmidi aes_x86_64 crypto_simd glue_helper snd_hda_intel snd_hda_codec
    cryptd intel_cstate arc4 snd_hda_core snd_seq snd_seq_device snd_hwdep
    iwldvm intel_rapl_perf mac80211 joydev input_leds iwlwifi serio_raw
    cfg80211 snd_pcm shpchp snd_timer snd mac_hid mei_me lpc_ich mei soundcore
    sunrpc parport_pc ppdev lp parport autofs4 i915 psmouse
     e1000e ahci libahci i2c_algo_bit sdhci_pci ptp drm_kms_helper sdhci
    pps_core syscopyarea sysfillrect sysimgblt fb_sys_fops drm wmi video
    cpu: 1 pid: 4450 comm: dlm_test.exe not tainted 4.12.4-041204-generic
    hardware name: lenovo 232425u/232425u, bios g2et82ww (2.02 ) 09/11/2012
    task: ffff96b0cbabe140 task.stack: ffffb199027d0000
    rip: 0010:sysfs_warn_dup+0x56/0x70
    rsp: 0018:ffffb199027d3c58 eflags: 00010282
    rax: 0000000000000038 rbx: ffff96b0e2c49158 rcx: 0000000000000006
    rdx: 0000000000000000 rsi: 0000000000000086 rdi: ffff96b15e24dcc0
    rbp: ffffb199027d3c70 r08: 0000000000000001 r09: 0000000000000721
    r10: ffffb199027d3c00 r11: 0000000000000721 r12: ffffb199027d3cd1
    r13: ffff96b1592088f0 r14: 0000000000000001 r15: ffffffffffffffef
    fs:  00007f78069c0700(0000) gs:ffff96b15e240000(0000)
    knlgs:0000000000000000
    cs:  0010 ds: 0000 es: 0000 cr0: 0000000080050033
    cr2: 000000178625ed28 cr3: 0000000091d3e000 cr4: 00000000001406e0
    call trace:
     sysfs_do_create_link_sd.isra.2+0x9e/0xb0
     sysfs_create_link+0x25/0x40
     device_add+0x5a9/0x640
     device_create_groups_vargs+0xe0/0xf0
     device_create_with_groups+0x3f/0x60
     ? snprintf+0x45/0x70
     misc_register+0x140/0x180
     device_write+0x6a8/0x790 [dlm]
     __vfs_write+0x37/0x160
     ? apparmor_file_permission+0x1a/0x20
     ? security_file_permission+0x3b/0xc0
     vfs_write+0xb5/0x1a0
     sys_write+0x55/0xc0
     ? sys_fcntl+0x5d/0xb0
     entry_syscall_64_fastpath+0x1e/0xa9
    rip: 0033:0x7f78083454bd
    rsp: 002b:00007f78069bbd30 eflags: 00000293 orig_rax: 0000000000000001
    rax: ffffffffffffffda rbx: 0000000000000006 rcx: 00007f78083454bd
    rdx: 000000000000009c rsi: 00007f78069bee00 rdi: 0000000000000005
    rbp: 00007f77f8000a20 r08: 000000000000fcf0 r09: 0000000000000032
    r10: 0000000000000024 r11: 0000000000000293 r12: 00007f78069bde00
    r13: 00007f78069bee00 r14: 000000000000000a r15: 00007f78069bbd70
    code: 85 c0 48 89 c3 74 12 b9 00 10 00 00 48 89 c2 31 f6 4c 89 ef e8 2c c8
    ff ff 4c 89 e2 48 89 de 48 c7 c7 b0 8e 0c a8 e8 41 e8 ed ff <0f> ff 48 89
    df e8 00 d5 f4 ff 5b 41 5c 41 5d 5d c3 66 0f 1f 84
    ---[ end trace 40412246357cc9e0 ]---
    
    dlm: 59f24629-ae39-44e2-9030-397ebc2eda26: leaving the lockspace group...
    bug: unable to handle kernel null pointer dereference at 0000000000000001
    ip: [<ffffffff811a3b4a>] kmem_cache_alloc+0x7a/0x140
    pgd 0
    oops: 0000 [#1] smp
    modules linked in: dlm 8021q garp mrp stp llc openvswitch nf_defrag_ipv6
    nf_conntrack libcrc32c iptable_filter dm_multipath crc32_pclmul dm_mod
    aesni_intel psmouse aes_x86_64 sg ablk_helper cryptd lrw gf128mul
    glue_helper i2c_piix4 nls_utf8 tpm_tis tpm isofs nfsd auth_rpcgss
    oid_registry nfs_acl lockd grace sunrpc xen_wdt ip_tables x_tables autofs4
    hid_generic usbhid hid sr_mod cdrom sd_mod ata_generic pata_acpi 8139too
    serio_raw ata_piix 8139cp mii uhci_hcd ehci_pci ehci_hcd libata
    scsi_dh_rdac scsi_dh_hp_sw scsi_dh_emc scsi_dh_alua scsi_mod ipv6
    cpu: 0 pid: 394 comm: systemd-udevd tainted: g w 4.4.0+0 #1
    hardware name: xen hvm domu, bios 4.7.2-2.2 05/11/2017
    task: ffff880002410000 ti: ffff88000243c000 task.ti: ffff88000243c000
    rip: e030:[<ffffffff811a3b4a>] [<ffffffff811a3b4a>]
    kmem_cache_alloc+0x7a/0x140
    rsp: e02b:ffff88000243fd90 eflags: 00010202
    rax: 0000000000000000 rbx: ffff8800029864d0 rcx: 000000000007b36c
    rdx: 000000000007b36b rsi: 00000000024000c0 rdi: ffff880036801c00
    rbp: ffff88000243fdc0 r08: 0000000000018880 r09: 0000000000000054
    r10: 000000000000004a r11: ffff880034ace6c0 r12: 00000000024000c0
    r13: ffff880036801c00 r14: 0000000000000001 r15: ffffffff8118dcc2
    fs: 00007f0ab77548c0(0000) gs:ffff880036e00000(0000) knlgs:0000000000000000
    cs: e033 ds: 0000 es: 0000 cr0: 0000000080050033
    cr2: 0000000000000001 cr3: 000000000332d000 cr4: 0000000000040660
    stack:
    ffffffff8118dc90 ffff8800029864d0 0000000000000000 ffff88003430b0b0
    ffff880034b78320 ffff88003430b0b0 ffff88000243fdf8 ffffffff8118dcc2
    ffff8800349c6700 ffff8800029864d0 000000000000000b 00007f0ab7754b90
    call trace:
    [<ffffffff8118dc90>] ? anon_vma_fork+0x60/0x140
    [<ffffffff8118dcc2>] anon_vma_fork+0x92/0x140
    [<ffffffff8107033e>] copy_process+0xcae/0x1a80
    [<ffffffff8107128b>] _do_fork+0x8b/0x2d0
    [<ffffffff81071579>] sys_clone+0x19/0x20
    [<ffffffff815a30ae>] entry_syscall_64_fastpath+0x12/0x71
    ] code: f6 75 1c 4c 89 fa 44 89 e6 4c 89 ef e8 a7 e4 00 00 41 f7 c4 00 80
    00 00 49 89 c6 74 47 eb 32 49 63 45 20 48 8d 4a 01 4d 8b 45 00 <49> 8b 1c
    06 4c 89 f0 65 49 0f c7 08 0f 94 c0 84 c0 74 ac 49 63
    rip [<ffffffff811a3b4a>] kmem_cache_alloc+0x7a/0x140
    rsp <ffff88000243fd90>
    cr2: 0000000000000001
    --[ end trace 70cb9fd1b164a0e8 ]--
    
    Signed-off-by: Edwin Török <edvin.torok@citrix.com>
    Signed-off-by: David Teigland <teigland@redhat.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 23b7d4f52b694a0d25ad1f619e90a482898efc85
Author: Luca Coelho <luciano.coelho@intel.com>
Date:   Wed Aug 16 08:47:38 2017 +0300

    iwlwifi: pci: add new PCI ID for 7265D
    
    commit 3f7a5e13e85026b6e460bbd6e87f87379421d272 upstream.
    
    We have a new PCI subsystem ID for 7265D.  Add it to the list.
    
    Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 747562619512d1fd9ad99d0836f692d47f9b2853
Author: Dmitry Tunin <hanipouspilot@gmail.com>
Date:   Tue Aug 8 14:09:02 2017 +0300

    Bluetooth: Add support of 13d3:3494 RTL8723BE device
    
    commit a81d72d2002d6a932bd83022cbf8c442b1b97512 upstream.
    
    T: Bus=02 Lev=01 Prnt=01 Port=03 Cnt=03 Dev#= 4 Spd=12 MxCh= 0
    D: Ver= 2.10 Cls=e0(wlcon) Sub=01 Prot=01 MxPS=64 #Cfgs= 1
    P: Vendor=13d3 ProdID=3494 Rev= 2.00
    S: Manufacturer=Realtek
    S: Product=Bluetooth Radio
    S: SerialNumber=00e04c000001
    C:* #Ifs= 2 Cfg#= 1 Atr=e0 MxPwr=500mA
    I:* If#= 0 Alt= 0 #EPs= 3 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
    E: Ad=81(I) Atr=03(Int.) MxPS= 16 Ivl=1ms
    E: Ad=02(O) Atr=02(Bulk) MxPS= 64 Ivl=0ms
    E: Ad=82(I) Atr=02(Bulk) MxPS= 64 Ivl=0ms
    I:* If#= 1 Alt= 0 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
    E: Ad=03(O) Atr=01(Isoc) MxPS= 0 Ivl=1ms
    E: Ad=83(I) Atr=01(Isoc) MxPS= 0 Ivl=1ms
    I: If#= 1 Alt= 1 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
    E: Ad=03(O) Atr=01(Isoc) MxPS= 9 Ivl=1ms
    E: Ad=83(I) Atr=01(Isoc) MxPS= 9 Ivl=1ms
    I: If#= 1 Alt= 2 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
    E: Ad=03(O) Atr=01(Isoc) MxPS= 17 Ivl=1ms
    E: Ad=83(I) Atr=01(Isoc) MxPS= 17 Ivl=1ms
    I: If#= 1 Alt= 3 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
    E: Ad=03(O) Atr=01(Isoc) MxPS= 25 Ivl=1ms
    E: Ad=83(I) Atr=01(Isoc) MxPS= 25 Ivl=1ms
    I: If#= 1 Alt= 4 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
    E: Ad=03(O) Atr=01(Isoc) MxPS= 33 Ivl=1ms
    E: Ad=83(I) Atr=01(Isoc) MxPS= 33 Ivl=1ms
    I: If#= 1 Alt= 5 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
    E: Ad=03(O) Atr=01(Isoc) MxPS= 49 Ivl=1ms
    E: Ad=83(I) Atr=01(Isoc) MxPS= 49 Ivl=1ms
    
    Signed-off-by: Dmitry Tunin <hanipouspilot@gmail.com>
    Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit b48f7183c64cd12b7451ea677f964e10acd6a52b
Author: Malcolm Priestley <tvboxspy@gmail.com>
Date:   Sun Jul 30 09:02:19 2017 +0100

    rtlwifi: rtl_pci_probe: Fix fail path of _rtl_pci_find_adapter
    
    commit fc81bab5eeb103711925d7510157cf5cd2b153f4 upstream.
    
    _rtl_pci_find_adapter fail path will jump to label fail3 for
    unsupported adapter types.
    
    However, on course for fail3 there will be call rtl_deinit_core
    before rtl_init_core.
    
    For the inclusion of checking pci_iounmap this fail can be moved to
    fail2.
    
    Fixes
    [    4.492963] BUG: unable to handle kernel NULL pointer dereference at           (null)
    [    4.493067] IP: rtl_deinit_core+0x31/0x90 [rtlwifi]
    
    Signed-off-by: Malcolm Priestley <tvboxspy@gmail.com>
    Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit ed7a384a904f1d5031b4d10173ef32ab405333a1
Author: Oscar Campos <oscar.campos@member.fsf.org>
Date:   Tue Jul 18 17:20:36 2017 -0700

    Input: trackpoint - assume 3 buttons when buttons detection fails
    
    commit 293b915fd9bebf33cdc906516fb28d54649a25ac upstream.
    
    Trackpoint buttons detection fails on ThinkPad 570 and 470 series,
    this makes the middle button of the trackpoint to not being recogized.
    As I don't believe there is any trackpoint with less than 3 buttons this
    patch just assumes three buttons when the extended button information
    read fails.
    
    Signed-off-by: Oscar Campos <oscar.campos@member.fsf.org>
    Acked-by: Peter Hutterer <peter.hutterer@who-t.net>
    Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
    Signed-off-by: Aaron Ma <aaron.ma@canonical.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 90a1e2e19ed731d66f95f5471c99d0e16a92021d
Author: Rakesh Pillai <pillair@qti.qualcomm.com>
Date:   Wed Aug 2 16:03:37 2017 +0530

    ath10k: fix memory leak in rx ring buffer allocation
    
    commit f35a7f91f66af528b3ee1921de16bea31d347ab0 upstream.
    
    The rx ring buffers are added to a hash table if
    firmware support full rx reorder. If the full rx
    reorder support flag is not set before allocating
    the rx ring buffers, none of the buffers are added
    to the hash table.
    
    There is a race condition between rx ring refill and
    rx buffer replenish from napi poll. The interrupts are
    enabled in hif start, before the rx ring is refilled during init.
    We replenish buffers from napi poll due to the interrupts which
    get enabled after hif start. Hence before the entire rx ring is
    refilled during the init, the napi poll replenishes a few buffers
    in steps of 100 buffers per attempt. During this rx ring replenish
    from napi poll, the rx reorder flag has not been set due to which
    the replenished buffers are not added to the hash table
    
    Set the rx full reorder support flag before we allocate
    the rx ring buffer to avoid the memory leak.
    
    Signed-off-by: Rakesh Pillai <pillair@qti.qualcomm.com>
    Signed-off-by: Kalle Valo <kvalo@qca.qualcomm.com>
    Cc: Christian Lamparter <chunkeey@googlemail.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit d8b992d93555af94d31264be3fbe73aca1945947
Author: Alexander Shishkin <alexander.shishkin@linux.intel.com>
Date:   Thu Jun 30 16:11:31 2016 +0300

    intel_th: pci: Add Cannon Lake PCH-LP support
    
    commit efb3669e14fe17d0ec4ecf57d0365039fe726f59 upstream.
    
    This adds Intel(R) Trace Hub PCI ID for Cannon Lake PCH-LP.
    
    Signed-off-by: Alexander Shishkin <alexander.shishkin@linux.intel.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit a22d561178ee2e96ca4bf519669d533144e7145c
Author: Alexander Shishkin <alexander.shishkin@linux.intel.com>
Date:   Thu Jun 30 16:11:13 2016 +0300

    intel_th: pci: Add Cannon Lake PCH-H support
    
    commit 84331e1390b6378a5129a3678c87a42c6f697d29 upstream.
    
    This adds Intel(R) Trace Hub PCI ID for Cannon Lake PCH-H.
    
    Signed-off-by: Alexander Shishkin <alexander.shishkin@linux.intel.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 5555eb956edc3c89f59ed7636b29a3a4d0dd8063
Author: Christophe JAILLET <christophe.jaillet@wanadoo.fr>
Date:   Tue Aug 29 21:23:49 2017 +0200

    driver core: bus: Fix a potential double free
    
    commit 0f9b011d3321ca1079c7a46c18cb1956fbdb7bcb upstream.
    
    The .release function of driver_ktype is 'driver_release()'.
    This function frees the container_of this kobject.
    
    So, this memory must not be freed explicitly in the error handling path of
    'bus_add_driver()'. Otherwise a double free will occur.
    
    Signed-off-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit ffb58b875d241f4121335a7668da743f26c0514b
Author: Akinobu Mita <akinobu.mita@gmail.com>
Date:   Fri Jul 21 00:24:22 2017 +0900

    iio: adc: ti-ads1015: add adequate wait time to get correct conversion
    
    commit 4744d4e2afebf9644a439da9ca73d822fdd67bd9 upstream.
    
    This driver assumes that the device is operating in the continuous
    conversion mode which performs the conversion continuously.  So this driver
    inserts a wait time before reading the conversion register if the
    configuration is changed from a previous request.
    
    Currently, the wait time is only the period required for a single
    conversion that is calculated as the reciprocal of the sampling frequency.
    However we also need to wait for the the previous conversion to complete.
    Otherwise we probably get the conversion result for the previous
    configuration when the sampling frequency is lower.
    
    Cc: Daniel Baluta <daniel.baluta@gmail.com>
    Signed-off-by: Akinobu Mita <akinobu.mita@gmail.com>
    Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit ff4a98e3bcb3756544b31a2610a24db77f5a20b4
Author: Akinobu Mita <akinobu.mita@gmail.com>
Date:   Fri Jul 21 00:24:21 2017 +0900

    iio: adc: ti-ads1015: don't return invalid value from buffer setup callbacks
    
    commit a6fe5e52d5ecfc98530034d6c9db73777cf41ede upstream.
    
    pm_runtime_get_sync() and pm_runtime_put_autosuspend() return 0 on
    success, 1 if the device's runtime PM status was already requested status
    or error code on failure.  So a positive return value doesn't indicate an
    error condition.
    
    However, any non-zero return values from buffer preenable and postdisable
    callbacks are recognized as an error and this driver reuses the return
    value from pm_runtime_get_sync() and pm_runtime_put_autosuspend() in
    these callbacks.  This change fixes the false error detections.
    
    Cc: Daniel Baluta <daniel.baluta@gmail.com>
    Signed-off-by: Akinobu Mita <akinobu.mita@gmail.com>
    Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 1ed4565b7c7bb73d802800c333244498f0993274
Author: Akinobu Mita <akinobu.mita@gmail.com>
Date:   Fri Jul 21 00:24:20 2017 +0900

    iio: adc: ti-ads1015: avoid getting stale result after runtime resume
    
    commit 73e3e3fc50de50cfd68e945d85679c983ed31bd9 upstream.
    
    This driver assumes that the device is operating in the continuous
    conversion mode which performs the conversion continuously.  So this driver
    doesn't insert a wait time before reading the conversion register if the
    configuration is not changed from a previous request.
    
    This assumption is broken if the device is runtime suspended and entered
    a power-down state.  The forthcoming request causes reading a stale result
    from the conversion register as the device is runtime resumed just before.
    
    Fix it by adding a flag to detect that condition and insert a necessary
    wait time.
    
    Cc: Daniel Baluta <daniel.baluta@gmail.com>
    Signed-off-by: Akinobu Mita <akinobu.mita@gmail.com>
    Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit c72ad1a4fdf044c5253a72bc413e1869d6b16f39
Author: Akinobu Mita <akinobu.mita@gmail.com>
Date:   Fri Jul 21 00:24:19 2017 +0900

    iio: adc: ti-ads1015: enable conversion when CONFIG_PM is not set
    
    commit e8245c68350104b6022b6783719e843d69ea7c43 upstream.
    
    The ADS1015 device have two operating modes, continuous conversion mode
    and single-shot mode.  This driver assumes that the continuous conversion
    mode is selected by runtime resume callback when the ADC result is
    requested.
    
    If CONFIG_PM is disabled, the device is always in the default single-shot
    mode and no one begins a single conversion.  So the conversion register
    doesn't contain valid ADC result.  Fix it by changing the continuous mode
    in probe function.
    
    Cc: Daniel Baluta <daniel.baluta@gmail.com>
    Signed-off-by: Akinobu Mita <akinobu.mita@gmail.com>
    Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 115af6c3b155a2e6d1d9c7b3e1db81fbf8d48727
Author: Akinobu Mita <akinobu.mita@gmail.com>
Date:   Fri Jul 21 00:24:18 2017 +0900

    iio: adc: ti-ads1015: fix scale information for ADS1115
    
    commit 8d0e8e795623bd6229cf48bb7777a1c456c370ed upstream.
    
    The ti-ads1015 driver supports ADS1015 and ADS1115 devices.  The same
    scale information is used for both devices in this driver, however they
    have actually different values and the ADS1115's one is not correct.
    
    These devices have the same full-scale input voltage range for each PGA
    selection.  So instead of adding another hardcoded scale information,
    compute a correct scale on demand from each device's resolution.
    
    Cc: Daniel Baluta <daniel.baluta@gmail.com>
    Signed-off-by: Akinobu Mita <akinobu.mita@gmail.com>
    Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 177d84e3a72abfc646fcc63e331b03dafa0ac943
Author: Akinobu Mita <akinobu.mita@gmail.com>
Date:   Fri Jul 21 00:24:17 2017 +0900

    iio: adc: ti-ads1015: fix incorrect data rate setting update
    
    commit 0d106b74c558e3000aa0e058b4725cacb70ce77a upstream.
    
    The ti-ads1015 driver has eight iio voltage channels and each iio channel
    can hold own sampling frequency information.
    
    The ADS1015 device only have a single config register which contains an
    input multiplexer selection, PGA and data rate settings.  So the driver
    should load the correct settings when the input multiplexer selection is
    changed.
    
    However, regardless of which channlel is currently selected, changing any
    iio channel's sampling frequency information immediately overwrites the
    current data rate setting in the config register.
    
    It breaks the current data rate setting if the different channel's sampling
    frequency information is changed because the data rate setting is not
    reloaded when the input multiplexer is switched.
    
    This removes the unexpected config register update and correctly load the
    data rate setting before getting adc result.
    
    Cc: Daniel Baluta <daniel.baluta@gmail.com>
    Signed-off-by: Akinobu Mita <akinobu.mita@gmail.com>
    Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit e58b04fb5b0bf2847f28b8e0cd879fabfec1355b
Author: Colin Ian King <colin.king@canonical.com>
Date:   Fri Aug 18 14:34:16 2017 +0100

    staging/rts5208: fix incorrect shift to extract upper nybble
    
    commit 34ff1bf4920471cff66775dc39537b15c5f0feff upstream.
    
    The mask of sns_key_info1 suggests the upper nybble is being extracted
    however the following shift of 8 bits is too large and always results in
    0.  Fix this by shifting only by 4 bits to correctly get the upper nybble.
    
    Detected by CoverityScan, CID#142891 ("Operands don't affect result")
    
    Fixes: fa590c222fba ("staging: rts5208: add support for rts5208 and rts5288")
    Signed-off-by: Colin Ian King <colin.king@canonical.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit afcfe0661a747bf1f447dd9f24be4ad67f1cf018
Author: Douglas Anderson <dianders@chromium.org>
Date:   Thu Aug 10 15:42:22 2017 -0700

    USB: core: Avoid race of async_completed() w/ usbdev_release()
    
    commit ed62ca2f4f51c17841ea39d98c0c409cb53a3e10 upstream.
    
    While running reboot tests w/ a specific set of USB devices (and
    slub_debug enabled), I found that once every few hours my device would
    be crashed with a stack that looked like this:
    
    [   14.012445] BUG: spinlock bad magic on CPU#0, modprobe/2091
    [   14.012460]  lock: 0xffffffc0cb055978, .magic: ffffffc0, .owner: cryption contexts: %lu/%lu
    [   14.012460] /1025536097, .owner_cpu: 0
    [   14.012466] CPU: 0 PID: 2091 Comm: modprobe Not tainted 4.4.79 #352
    [   14.012468] Hardware name: Google Kevin (DT)
    [   14.012471] Call trace:
    [   14.012483] [<....>] dump_backtrace+0x0/0x160
    [   14.012487] [<....>] show_stack+0x20/0x28
    [   14.012494] [<....>] dump_stack+0xb4/0xf0
    [   14.012500] [<....>] spin_dump+0x8c/0x98
    [   14.012504] [<....>] spin_bug+0x30/0x3c
    [   14.012508] [<....>] do_raw_spin_lock+0x40/0x164
    [   14.012515] [<....>] _raw_spin_lock_irqsave+0x64/0x74
    [   14.012521] [<....>] __wake_up+0x2c/0x60
    [   14.012528] [<....>] async_completed+0x2d0/0x300
    [   14.012534] [<....>] __usb_hcd_giveback_urb+0xc4/0x138
    [   14.012538] [<....>] usb_hcd_giveback_urb+0x54/0xf0
    [   14.012544] [<....>] xhci_irq+0x1314/0x1348
    [   14.012548] [<....>] usb_hcd_irq+0x40/0x50
    [   14.012553] [<....>] handle_irq_event_percpu+0x1b4/0x3f0
    [   14.012556] [<....>] handle_irq_event+0x4c/0x7c
    [   14.012561] [<....>] handle_fasteoi_irq+0x158/0x1c8
    [   14.012564] [<....>] generic_handle_irq+0x30/0x44
    [   14.012568] [<....>] __handle_domain_irq+0x90/0xbc
    [   14.012572] [<....>] gic_handle_irq+0xcc/0x18c
    
    Investigation using kgdb() found that the wait queue that was passed
    into wake_up() had been freed (it was filled with slub_debug poison).
    
    I analyzed and instrumented the code and reproduced.  My current
    belief is that this is happening:
    
    1. async_completed() is called (from IRQ).  Moves "as" onto the
       completed list.
    2. On another CPU, proc_reapurbnonblock_compat() calls
       async_getcompleted().  Blocks on spinlock.
    3. async_completed() releases the lock; keeps running; gets blocked
       midway through wake_up().
    4. proc_reapurbnonblock_compat() => async_getcompleted() gets the
       lock; removes "as" from completed list and frees it.
    5. usbdev_release() is called.  Frees "ps".
    6. async_completed() finally continues running wake_up().  ...but
       wake_up() has a pointer to the freed "ps".
    
    The instrumentation that led me to believe this was based on adding
    some trace_printk() calls in a select few functions and then using
    kdb's "ftdump" at crash time.  The trace follows (NOTE: in the trace
    below I cheated a little bit and added a udelay(1000) in
    async_completed() after releasing the spinlock because I wanted it to
    trigger quicker):
    
    <...>-2104   0d.h2 13759034us!: async_completed at start: as=ffffffc0cc638200
    mtpd-2055    3.... 13759356us : async_getcompleted before spin_lock_irqsave
    mtpd-2055    3d..1 13759362us : async_getcompleted after list_del_init: as=ffffffc0cc638200
    mtpd-2055    3.... 13759371us+: proc_reapurbnonblock_compat: free_async(ffffffc0cc638200)
    mtpd-2055    3.... 13759422us+: async_getcompleted before spin_lock_irqsave
    mtpd-2055    3.... 13759479us : usbdev_release at start: ps=ffffffc0cc042080
    mtpd-2055    3.... 13759487us : async_getcompleted before spin_lock_irqsave
    mtpd-2055    3.... 13759497us!: usbdev_release after kfree(ps): ps=ffffffc0cc042080
    <...>-2104   0d.h2 13760294us : async_completed before wake_up(): as=ffffffc0cc638200
    
    To fix this problem we can just move the wake_up() under the ps->lock.
    There should be no issues there that I'm aware of.
    
    Signed-off-by: Douglas Anderson <dianders@chromium.org>
    Acked-by: Alan Stern <stern@rowland.harvard.edu>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 80cdcd7f533585a62fa31f87a25ab5dbfd5e0e1a
Author: Johan Hovold <johan@kernel.org>
Date:   Thu Aug 24 11:38:36 2017 -0500

    USB: musb: fix external abort on suspend
    
    commit 082df8be455ade361748f0385aa6c9c8d07be167 upstream.
    
    Make sure that the controller is runtime resumed when system suspending
    to avoid an external abort when accessing the interrupt registers:
    
      Unhandled fault: external abort on non-linefetch (0x1008) at 0xd025840a
      ...
      [<c05481a4>] (musb_default_readb) from [<c0545abc>] (musb_disable_interrupts+0x84/0xa8)
      [<c0545abc>] (musb_disable_interrupts) from [<c0546b08>] (musb_suspend+0x38/0xb8)
      [<c0546b08>] (musb_suspend) from [<c04a57f8>] (platform_pm_suspend+0x3c/0x64)
    
    This is easily reproduced on a BBB by enabling the peripheral port only
    (as the host port may enable the shared clock) and keeping it
    disconnected so that the controller is runtime suspended. (Well, you
    would also need to the not-yet-merged am33xx-suspend patches by Dave
    Gerlach to be able to suspend the BBB.)
    
    This is a regression that was introduced by commit 1c4d0b4e1806 ("usb:
    musb: Remove pm_runtime_set_irq_safe") which allowed the parent glue
    device to runtime suspend and thereby exposed a couple of older issues:
    
    Register accesses without explicitly making sure the controller is
    runtime resumed during suspend was first introduced by commit c338412b5ded
    ("usb: musb: unconditionally save and restore the context on suspend")
    in 3.14.
    
    Commit a1fc1920aaaa ("usb: musb: core: make sure musb is in RPM_ACTIVE on
    resume") later started setting the RPM status to active during resume,
    and this was also implicitly relying on the parent always being active.
    Since commit 71723f95463d ("PM / runtime: print error when activating a
    child to unactive parent") this now also results in the following
    warning:
    
      musb-hdrc musb-hdrc.0: runtime PM trying to activate child device
        musb-hdrc.0 but parent (47401400.usb) is not active
    
    This patch has been verified on 4.13-rc2, 4.12 and 4.9 using a BBB
    (the dsps glue would always be active also in 4.8).
    
    Fixes: c338412b5ded ("usb: musb: unconditionally save and restore the context on suspend")
    Fixes: a1fc1920aaaa ("usb: musb: core: make sure musb is in RPM_ACTIVE on resume")
    Fixes: 1c4d0b4e1806 ("usb: musb: Remove pm_runtime_set_irq_safe")
    Cc: Alan Stern <stern@rowland.harvard.edu>
    Cc: Daniel Mack <zonque@gmail.com>
    Cc: Dave Gerlach <d-gerlach@ti.com>
    Cc: Rafael J. Wysocki <rjw@rjwysocki.net>
    Cc: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
    Cc: Tony Lindgren <tony@atomide.com>
    Signed-off-by: Johan Hovold <johan@kernel.org>
    Signed-off-by: Bin Liu <b-liu@ti.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 6b3b3a22ef206ba9c141e04c50b0f48762571bc9
Author: Sandeep Singh <sandeep.singh@amd.com>
Date:   Thu Aug 24 09:57:15 2017 +0530

    usb:xhci:Fix regression when ATI chipsets detected
    
    commit e6b422b88b46353cf596e0db6dc0e39d50d90d6e upstream.
    
    The following commit cause a regression on ATI chipsets.
    'commit e788787ef4f9 ("usb:xhci:Add quirk for Certain
    failing HP keyboard on reset after resume")'
    
    This causes pinfo->smbus_dev to be wrongly set to NULL on
    systems with the ATI chipset that this function checks for first.
    
    Added conditional check for AMD chipsets to avoid the overwriting
    pinfo->smbus_dev.
    
    Reported-by: Ben Hutchings <ben@decadent.org.uk>
    Fixes: e788787ef4f9 ("usb:xhci:Add quirk for Certain
    failing HP keyboard on reset after resume")
    cc: Nehal Shah <Nehal-bakulchandra.Shah@amd.com>
    Signed-off-by: Sandeep Singh <Sandeep.Singh@amd.com>
    Signed-off-by: Shyam Sundar S K <Shyam-sundar.S-k@amd.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 99a22c84f51d9fff570beef1a8c788e0dc7a3a4d
Author: Dmitry Fleytman <dmitry@daynix.com>
Date:   Fri Aug 25 10:38:35 2017 +0300

    usb: Add device quirk for Logitech HD Pro Webcam C920-C
    
    commit a1279ef74eeeb5f627f091c71d80dd7ac766c99d upstream.
    
    Commit e0429362ab15
    ("usb: Add device quirk for Logitech HD Pro Webcams C920 and C930e")
    introduced quirk to workaround an issue with some Logitech webcams.
    
    Apparently model C920-C has the same issue so applying
    the same quirk as well.
    
    See aforementioned commit message for detailed explanation of the problem.
    
    Signed-off-by: Dmitry Fleytman <dmitry@daynix.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 773b93f4255f899fdfa417239f7b9ae2107f9793
Author: Maciej S. Szmigiero <mail@maciej.szmigiero.name>
Date:   Tue Aug 29 21:50:03 2017 +0200

    USB: serial: option: add support for D-Link DWM-157 C1
    
    commit 169e86546f5712179709de23cd64bbb15f199fab upstream.
    
    This commit adds support (an ID, really) for D-Link DWM-157 hardware
    version C1 USB modem to option driver.
    
    According to manufacturer-provided Windows INF file the device has four
    serial ports:
    "D-Link HSPA+DataCard Diagnostics Interface" (interface 2; modem port),
    "D-Link HSPA+DataCard NMEA Device" (interface 3),
    "D-Link HSPA+DataCard Speech Port" (interface 4),
    "D-Link HSPA+DataCard Debug Port" (interface 5).
    
    usb-devices output:
    T:  Bus=05 Lev=01 Prnt=01 Port=04 Cnt=01 Dev#=  3 Spd=480 MxCh= 0
    D:  Ver= 2.00 Cls=ef(misc ) Sub=02 Prot=01 MxPS=64 #Cfgs=  1
    P:  Vendor=2001 ProdID=7d0e Rev=03.00
    S:  Manufacturer=D-Link,Inc
    S:  Product=D-Link DWM-157
    C:  #Ifs= 7 Cfg#= 1 Atr=a0 MxPwr=500mA
    I:  If#= 0 Alt= 0 #EPs= 1 Cls=02(commc) Sub=0e Prot=00 Driver=cdc_mbim
    I:  If#= 1 Alt= 1 #EPs= 2 Cls=0a(data ) Sub=00 Prot=02 Driver=cdc_mbim
    I:  If#= 2 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=02 Prot=01 Driver=option
    I:  If#= 3 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=00 Prot=00 Driver=option
    I:  If#= 4 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=00 Prot=00 Driver=option
    I:  If#= 5 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=00 Prot=00 Driver=option
    I:  If#= 6 Alt= 0 #EPs= 2 Cls=08(stor.) Sub=06 Prot=50 Driver=usb-storage
    
    Signed-off-by: Maciej S. Szmigiero <mail@maciej.szmigiero.name>
    Signed-off-by: Johan Hovold <johan@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 2ea91c52ff5f8df5df3d5e2e16926049583c4cff
Author: Kai-Heng Feng <kai.heng.feng@canonical.com>
Date:   Wed Aug 16 10:53:20 2017 +0800

    usb: quirks: add delay init quirk for Corsair Strafe RGB keyboard
    
    commit de3af5bf259d7a0bfaac70441c8568ab5998d80c upstream.
    
    Corsair Strafe RGB keyboard has trouble to initialize:
    
    [ 1.679455] usb 3-6: new full-speed USB device number 4 using xhci_hcd
    [ 6.871136] usb 3-6: unable to read config index 0 descriptor/all
    [ 6.871138] usb 3-6: can't read configurations, error -110
    [ 6.991019] usb 3-6: new full-speed USB device number 5 using xhci_hcd
    [ 12.246642] usb 3-6: unable to read config index 0 descriptor/all
    [ 12.246644] usb 3-6: can't read configurations, error -110
    [ 12.366555] usb 3-6: new full-speed USB device number 6 using xhci_hcd
    [ 17.622145] usb 3-6: unable to read config index 0 descriptor/all
    [ 17.622147] usb 3-6: can't read configurations, error -110
    [ 17.742093] usb 3-6: new full-speed USB device number 7 using xhci_hcd
    [ 22.997715] usb 3-6: unable to read config index 0 descriptor/all
    [ 22.997716] usb 3-6: can't read configurations, error -110
    
    Although it may work after several times unpluging/pluging:
    
    [ 68.195240] usb 3-6: new full-speed USB device number 11 using xhci_hcd
    [ 68.337459] usb 3-6: New USB device found, idVendor=1b1c, idProduct=1b20
    [ 68.337463] usb 3-6: New USB device strings: Mfr=1, Product=2, SerialNumber=3
    [ 68.337466] usb 3-6: Product: Corsair STRAFE RGB Gaming Keyboard
    [ 68.337468] usb 3-6: Manufacturer: Corsair
    [ 68.337470] usb 3-6: SerialNumber: 0F013021AEB8046755A93ED3F5001941
    
    Tried three quirks: USB_QUIRK_DELAY_INIT, USB_QUIRK_NO_LPM and
    USB_QUIRK_DEVICE_QUALIFIER, user confirmed that USB_QUIRK_DELAY_INIT alone
    can workaround this issue. Hence add the quirk for Corsair Strafe RGB.
    
    BugLink: https://bugs.launchpad.net/bugs/1678477
    Signed-off-by: Kai-Heng Feng <kai.heng.feng@canonical.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>