1. 30 Mar, 2017 40 commits
    • Dmitry Torokhov's avatar
      auxdisplay: img-ascii-lcd: add missing sentinel entry in img_ascii_lcd_matches · 90f39ad2
      Dmitry Torokhov authored
      commit abda288b upstream.
      
      The OF device table must be terminated, otherwise we'll be walking past it
      and into areas unknown.
      
      Fixes: 0cad855f ("auxdisplay: img-ascii-lcd: driver for simple ASCII...")
      Signed-off-by: default avatarDmitry Torokhov <dmitry.torokhov@gmail.com>
      Tested-by: default avatarFengguang Wu <fengguang.wu@intel.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      90f39ad2
    • Alex Deucher's avatar
      drm/amdgpu: reinstate oland workaround for sclk · 9740abe0
      Alex Deucher authored
      commit e11ddff6 upstream.
      
      Higher sclks seem to be unstable on some boards.
      
      bug: https://bugs.freedesktop.org/show_bug.cgi?id=100222Signed-off-by: default avatarAlex Deucher <alexander.deucher@amd.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      9740abe0
    • Ming Lei's avatar
      blk-mq: don't complete un-started request in timeout handler · 21d17f1b
      Ming Lei authored
      commit 95a49603 upstream.
      
      When iterating busy requests in timeout handler,
      if the STARTED flag of one request isn't set, that means
      the request is being processed in block layer or driver, and
      isn't submitted to hardware yet.
      
      In current implementation of blk_mq_check_expired(),
      if the request queue becomes dying, un-started requests are
      handled as being completed/freed immediately. This way is
      wrong, and can cause rq corruption or double allocation[1][2],
      when doing I/O and removing&resetting NVMe device at the sametime.
      
      This patch fixes several issues reported by Yi Zhang.
      
      [1]. oops log 1
      [  581.789754] ------------[ cut here ]------------
      [  581.789758] kernel BUG at block/blk-mq.c:374!
      [  581.789760] invalid opcode: 0000 [#1] SMP
      [  581.789761] Modules linked in: vfat fat ipmi_ssif intel_rapl sb_edac
      edac_core x86_pkg_temp_thermal intel_powerclamp coretemp kvm_intel kvm nvme
      irqbypass crct10dif_pclmul nvme_core crc32_pclmul ghash_clmulni_intel
      intel_cstate ipmi_si mei_me ipmi_devintf intel_uncore sg ipmi_msghandler
      intel_rapl_perf iTCO_wdt mei iTCO_vendor_support mxm_wmi lpc_ich dcdbas shpchp
      pcspkr acpi_power_meter wmi nfsd auth_rpcgss nfs_acl lockd dm_multipath grace
      sunrpc ip_tables xfs libcrc32c sd_mod mgag200 i2c_algo_bit drm_kms_helper
      syscopyarea sysfillrect sysimgblt fb_sys_fops ttm drm ahci libahci
      crc32c_intel tg3 libata megaraid_sas i2c_core ptp fjes pps_core dm_mirror
      dm_region_hash dm_log dm_mod
      [  581.789796] CPU: 1 PID: 1617 Comm: kworker/1:1H Not tainted 4.10.0.bz1420297+ #4
      [  581.789797] Hardware name: Dell Inc. PowerEdge R730xd/072T6D, BIOS 2.2.5 09/06/2016
      [  581.789804] Workqueue: kblockd blk_mq_timeout_work
      [  581.789806] task: ffff8804721c8000 task.stack: ffffc90006ee4000
      [  581.789809] RIP: 0010:blk_mq_end_request+0x58/0x70
      [  581.789810] RSP: 0018:ffffc90006ee7d50 EFLAGS: 00010202
      [  581.789811] RAX: 0000000000000001 RBX: ffff8802e4195340 RCX: ffff88028e2f4b88
      [  581.789812] RDX: 0000000000001000 RSI: 0000000000001000 RDI: 0000000000000000
      [  581.789813] RBP: ffffc90006ee7d60 R08: 0000000000000003 R09: ffff88028e2f4b00
      [  581.789814] R10: 0000000000001000 R11: 0000000000000001 R12: 00000000fffffffb
      [  581.789815] R13: ffff88042abe5780 R14: 000000000000002d R15: ffff88046fbdff80
      [  581.789817] FS:  0000000000000000(0000) GS:ffff88047fc00000(0000) knlGS:0000000000000000
      [  581.789818] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
      [  581.789819] CR2: 00007f64f403a008 CR3: 000000014d078000 CR4: 00000000001406e0
      [  581.789820] Call Trace:
      [  581.789825]  blk_mq_check_expired+0x76/0x80
      [  581.789828]  bt_iter+0x45/0x50
      [  581.789830]  blk_mq_queue_tag_busy_iter+0xdd/0x1f0
      [  581.789832]  ? blk_mq_rq_timed_out+0x70/0x70
      [  581.789833]  ? blk_mq_rq_timed_out+0x70/0x70
      [  581.789840]  ? __switch_to+0x140/0x450
      [  581.789841]  blk_mq_timeout_work+0x88/0x170
      [  581.789845]  process_one_work+0x165/0x410
      [  581.789847]  worker_thread+0x137/0x4c0
      [  581.789851]  kthread+0x101/0x140
      [  581.789853]  ? rescuer_thread+0x3b0/0x3b0
      [  581.789855]  ? kthread_park+0x90/0x90
      [  581.789860]  ret_from_fork+0x2c/0x40
      [  581.789861] Code: 48 85 c0 74 0d 44 89 e6 48 89 df ff d0 5b 41 5c 5d c3 48
      8b bb 70 01 00 00 48 85 ff 75 0f 48 89 df e8 7d f0 ff ff 5b 41 5c 5d c3 <0f>
      0b e8 71 f0 ff ff 90 eb e9 0f 1f 40 00 66 2e 0f 1f 84 00 00
      [  581.789882] RIP: blk_mq_end_request+0x58/0x70 RSP: ffffc90006ee7d50
      [  581.789889] ---[ end trace bcaf03d9a14a0a70 ]---
      
      [2]. oops log2
      [ 6984.857362] BUG: unable to handle kernel NULL pointer dereference at 0000000000000010
      [ 6984.857372] IP: nvme_queue_rq+0x6e6/0x8cd [nvme]
      [ 6984.857373] PGD 0
      [ 6984.857374]
      [ 6984.857376] Oops: 0000 [#1] SMP
      [ 6984.857379] Modules linked in: ipmi_ssif vfat fat intel_rapl sb_edac
      edac_core x86_pkg_temp_thermal intel_powerclamp coretemp kvm_intel kvm
      irqbypass crct10dif_pclmul crc32_pclmul ghash_clmulni_intel ipmi_si iTCO_wdt
      iTCO_vendor_support mxm_wmi ipmi_devintf intel_cstate sg dcdbas intel_uncore
      mei_me intel_rapl_perf mei pcspkr lpc_ich ipmi_msghandler shpchp
      acpi_power_meter wmi nfsd auth_rpcgss dm_multipath nfs_acl lockd grace sunrpc
      ip_tables xfs libcrc32c sd_mod mgag200 i2c_algo_bit drm_kms_helper syscopyarea
      sysfillrect crc32c_intel sysimgblt fb_sys_fops ttm nvme drm nvme_core ahci
      libahci i2c_core tg3 libata ptp megaraid_sas pps_core fjes dm_mirror
      dm_region_hash dm_log dm_mod
      [ 6984.857416] CPU: 7 PID: 1635 Comm: kworker/7:1H Not tainted
      4.10.0-2.el7.bz1420297.x86_64 #1
      [ 6984.857417] Hardware name: Dell Inc. PowerEdge R730xd/072T6D, BIOS 2.2.5 09/06/2016
      [ 6984.857427] Workqueue: kblockd blk_mq_run_work_fn
      [ 6984.857429] task: ffff880476e3da00 task.stack: ffffc90002e90000
      [ 6984.857432] RIP: 0010:nvme_queue_rq+0x6e6/0x8cd [nvme]
      [ 6984.857433] RSP: 0018:ffffc90002e93c50 EFLAGS: 00010246
      [ 6984.857434] RAX: 0000000000000000 RBX: ffff880275646600 RCX: 0000000000001000
      [ 6984.857435] RDX: 0000000000000fff RSI: 00000002fba2a000 RDI: ffff8804734e6950
      [ 6984.857436] RBP: ffffc90002e93d30 R08: 0000000000002000 R09: 0000000000001000
      [ 6984.857437] R10: 0000000000001000 R11: 0000000000000000 R12: ffff8804741d8000
      [ 6984.857438] R13: 0000000000000040 R14: ffff880475649f80 R15: ffff8804734e6780
      [ 6984.857439] FS:  0000000000000000(0000) GS:ffff88047fcc0000(0000) knlGS:0000000000000000
      [ 6984.857440] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
      [ 6984.857442] CR2: 0000000000000010 CR3: 0000000001c09000 CR4: 00000000001406e0
      [ 6984.857443] Call Trace:
      [ 6984.857451]  ? mempool_free+0x2b/0x80
      [ 6984.857455]  ? bio_free+0x4e/0x60
      [ 6984.857459]  blk_mq_dispatch_rq_list+0xf5/0x230
      [ 6984.857462]  blk_mq_process_rq_list+0x133/0x170
      [ 6984.857465]  __blk_mq_run_hw_queue+0x8c/0xa0
      [ 6984.857467]  blk_mq_run_work_fn+0x12/0x20
      [ 6984.857473]  process_one_work+0x165/0x410
      [ 6984.857475]  worker_thread+0x137/0x4c0
      [ 6984.857478]  kthread+0x101/0x140
      [ 6984.857480]  ? rescuer_thread+0x3b0/0x3b0
      [ 6984.857481]  ? kthread_park+0x90/0x90
      [ 6984.857489]  ret_from_fork+0x2c/0x40
      [ 6984.857490] Code: 8b bd 70 ff ff ff 89 95 50 ff ff ff 89 8d 58 ff ff ff 44
      89 95 60 ff ff ff e8 b7 dd 12 e1 8b 95 50 ff ff ff 48 89 85 68 ff ff ff <4c>
      8b 48 10 44 8b 58 18 8b 8d 58 ff ff ff 44 8b 95 60 ff ff ff
      [ 6984.857511] RIP: nvme_queue_rq+0x6e6/0x8cd [nvme] RSP: ffffc90002e93c50
      [ 6984.857512] CR2: 0000000000000010
      [ 6984.895359] ---[ end trace 2d7ceb528432bf83 ]---
      Reported-by: default avatarYi Zhang <yizhan@redhat.com>
      Tested-by: default avatarYi Zhang <yizhan@redhat.com>
      Reviewed-by: default avatarBart Van Assche <bart.vanassche@sandisk.com>
      Reviewed-by: default avatarHannes Reinecke <hare@suse.com>
      Signed-off-by: default avatarMing Lei <tom.leiming@gmail.com>
      Signed-off-by: default avatarJens Axboe <axboe@fb.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      21d17f1b
    • Tejun Heo's avatar
      cgroup, net_cls: iterate the fds of only the tasks which are being migrated · 62f6341c
      Tejun Heo authored
      commit a05d4fd9 upstream.
      
      The net_cls controller controls the classid field of each socket which
      is associated with the cgroup.  Because the classid is per-socket
      attribute, when a task migrates to another cgroup or the configured
      classid of the cgroup changes, the controller needs to walk all
      sockets and update the classid value, which was implemented by
      3b13758f ("cgroups: Allow dynamically changing net_classid").
      
      While the approach is not scalable, migrating tasks which have a lot
      of fds attached to them is rare and the cost is born by the ones
      initiating the operations.  However, for simplicity, both the
      migration and classid config change paths call update_classid() which
      scans all fds of all tasks in the target css.  This is an overkill for
      the migration path which only needs to cover a much smaller subset of
      tasks which are actually getting migrated in.
      
      On cgroup v1, this can lead to unexpected scalability issues when one
      tries to migrate a task or process into a net_cls cgroup which already
      contains a lot of fds.  Even if the migration traget doesn't have many
      to get scanned, update_classid() ends up scanning all fds in the
      target cgroup which can be extremely numerous.
      
      Unfortunately, on cgroup v2 which doesn't use net_cls, the problem is
      even worse.  Before bfc2cf6f ("cgroup: call subsys->*attach() only
      for subsystems which are actually affected by migration"), cgroup core
      would call the ->css_attach callback even for controllers which don't
      see actual migration to a different css.
      
      As net_cls is always disabled but still mounted on cgroup v2, whenever
      a process is migrated on the cgroup v2 hierarchy, net_cls sees
      identity migration from root to root and cgroup core used to call
      ->css_attach callback for those.  The net_cls ->css_attach ends up
      calling update_classid() on the root net_cls css to which all
      processes on the system belong to as the controller isn't used.  This
      makes any cgroup v2 migration O(total_number_of_fds_on_the_system)
      which is horrible and easily leads to noticeable stalls triggering RCU
      stall warnings and so on.
      
      The worst symptom is already fixed in upstream by bfc2cf6f
      ("cgroup: call subsys->*attach() only for subsystems which are
      actually affected by migration"); however, backporting that commit is
      too invasive and we want to avoid other cases too.
      
      This patch updates net_cls's cgrp_attach() to iterate fds of only the
      processes which are actually getting migrated.  This removes the
      surprising migration cost which is dependent on the total number of
      fds in the target cgroup.  As this leaves write_classid() the only
      user of update_classid(), open-code the helper into write_classid().
      Reported-by: default avatarDavid Goode <dgoode@fb.com>
      Fixes: 3b13758f ("cgroups: Allow dynamically changing net_classid")
      Cc: Nina Schiff <ninasc@fb.com>
      Cc: David S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarTejun Heo <tj@kernel.org>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      62f6341c
    • Viresh Kumar's avatar
      cpufreq: Restore policy min/max limits on CPU online · f5650846
      Viresh Kumar authored
      commit ff010472 upstream.
      
      On CPU online the cpufreq core restores the previous governor (or
      the previous "policy" setting for ->setpolicy drivers), but it does
      not restore the min/max limits at the same time, which is confusing,
      inconsistent and real pain for users who set the limits and then
      suspend/resume the system (using full suspend), in which case the
      limits are reset on all CPUs except for the boot one.
      
      Fix this by making cpufreq_online() restore the limits when an inactive
      policy is brought online.
      
      The commit log and patch are inspired from Rafael's earlier work.
      Reported-by: default avatarRafael J. Wysocki <rafael.j.wysocki@intel.com>
      Signed-off-by: default avatarViresh Kumar <viresh.kumar@linaro.org>
      Signed-off-by: default avatarRafael J. Wysocki <rafael.j.wysocki@intel.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      f5650846
    • Neeraj Upadhyay's avatar
      arm64: kaslr: Fix up the kernel image alignment · b9ed800f
      Neeraj Upadhyay authored
      commit afd0e5a8 upstream.
      
      If kernel image extends across alignment boundary, existing
      code increases the KASLR offset by size of kernel image. The
      offset is masked after resizing. There are cases, where after
      masking, we may still have kernel image extending across
      boundary. This eventually results in only 2MB block getting
      mapped while creating the page tables. This results in data aborts
      while accessing unmapped regions during second relocation (with
      kaslr offset) in __primary_switch. To fix this problem, round up the
      kernel image size, by swapper block size, before adding it for
      correction.
      
      For example consider below case, where kernel image still crosses
      1GB alignment boundary, after masking the offset, which is fixed
      by rounding up kernel image size.
      
      SWAPPER_TABLE_SHIFT = 30
      Swapper using section maps with section size 2MB.
      CONFIG_PGTABLE_LEVELS = 3
      VA_BITS = 39
      
      _text  : 0xffffff8008080000
      _end   : 0xffffff800aa1b000
      offset : 0x1f35600000
      mask = ((1UL << (VA_BITS - 2)) - 1) & ~(SZ_2M - 1)
      
      (_text + offset) >> SWAPPER_TABLE_SHIFT = 0x3fffffe7c
      (_end + offset) >> SWAPPER_TABLE_SHIFT  = 0x3fffffe7d
      
      offset after existing correction (before mask) = 0x1f37f9b000
      (_text + offset) >> SWAPPER_TABLE_SHIFT = 0x3fffffe7d
      (_end + offset) >> SWAPPER_TABLE_SHIFT  = 0x3fffffe7d
      
      offset (after mask) = 0x1f37e00000
      (_text + offset) >> SWAPPER_TABLE_SHIFT = 0x3fffffe7c
      (_end + offset) >> SWAPPER_TABLE_SHIFT  = 0x3fffffe7d
      
      new offset w/ rounding up = 0x1f38000000
      (_text + offset) >> SWAPPER_TABLE_SHIFT = 0x3fffffe7d
      (_end + offset) >> SWAPPER_TABLE_SHIFT  = 0x3fffffe7d
      
      Fixes: f80fb3a3 ("arm64: add support for kernel ASLR")
      Reviewed-by: default avatarArd Biesheuvel <ard.biesheuvel@linaro.org>
      Signed-off-by: default avatarNeeraj Upadhyay <neeraju@codeaurora.org>
      Signed-off-by: default avatarSrinivas Ramana <sramana@codeaurora.org>
      Signed-off-by: default avatarWill Deacon <will.deacon@arm.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      b9ed800f
    • Nicolas Ferre's avatar
      ARM: at91: pm: cpu_idle: switch DDR to power-down mode · 2ab97521
      Nicolas Ferre authored
      commit 60b89f19 upstream.
      
      On some DDR controllers, compatible with the sama5d3 one,
      the sequence to enter/exit/re-enter the self-refresh mode adds
      more constrains than what is currently written in the at91_idle
      driver. An actual access to the DDR chip is needed between exit
      and re-enter of this mode which is somehow difficult to implement.
      This sequence can completely hang the SoC. It is particularly
      experienced on parts which embed a L2 cache if the code run
      between IDLE calls fits in it...
      
      Moreover, as the intention is to enter and exit pretty rapidly
      from IDLE, the power-down mode is a good candidate.
      
      So now we use power-down instead of self-refresh. As we can
      simplify the code for sama5d3 compatible DDR controllers,
      we instantiate a new sama5d3_ddr_standby() function.
      Signed-off-by: default avatarNicolas Ferre <nicolas.ferre@microchip.com>
      Fixes: 017b5522 ("ARM: at91: Add new binding for sama5d3-ddramc")
      Signed-off-by: default avatarAlexandre Belloni <alexandre.belloni@free-electrons.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      2ab97521
    • Romain Izard's avatar
      Revert "ARM: at91/dt: sama5d2: Use new compatible for ohci node" · ca5477ad
      Romain Izard authored
      commit 9e10889a upstream.
      
      This reverts commit cab43282 ("ARM: at91/dt: sama5d2: Use new
      compatible for ohci node")
      
      It depends from commit 7150bc9b ("usb: ohci-at91: Forcibly suspend
      ports while USB suspend") which was reverted and implemented
      differently. With the new implementation, the compatible string must
      remain the same.
      
      The compatible string introduced by this commit has been used in the
      default SAMA5D2 dtsi starting from Linux 4.8. As it has never been
      working correctly in an official release, removing it should not be
      breaking the stability rules.
      
      Fixes: cab43282 ("ARM: at91/dt: sama5d2: Use new compatible for ohci node")
      Signed-off-by: default avatarRomain Izard <romain.izard.pro@gmail.com>
      Signed-off-by: default avatarAlexandre Belloni <alexandre.belloni@free-electrons.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      ca5477ad
    • Koos Vriezen's avatar
      iommu/vt-d: Fix NULL pointer dereference in device_to_iommu · 352c0214
      Koos Vriezen authored
      commit 5003ae1e upstream.
      
      The function device_to_iommu() in the Intel VT-d driver
      lacks a NULL-ptr check, resulting in this oops at boot on
      some platforms:
      
       BUG: unable to handle kernel NULL pointer dereference at 00000000000007ab
       IP: [<ffffffff8132234a>] device_to_iommu+0x11a/0x1a0
       PGD 0
      
       [...]
      
       Call Trace:
         ? find_or_alloc_domain.constprop.29+0x1a/0x300
         ? dw_dma_probe+0x561/0x580 [dw_dmac_core]
         ? __get_valid_domain_for_dev+0x39/0x120
         ? __intel_map_single+0x138/0x180
         ? intel_alloc_coherent+0xb6/0x120
         ? sst_hsw_dsp_init+0x173/0x420 [snd_soc_sst_haswell_pcm]
         ? mutex_lock+0x9/0x30
         ? kernfs_add_one+0xdb/0x130
         ? devres_add+0x19/0x60
         ? hsw_pcm_dev_probe+0x46/0xd0 [snd_soc_sst_haswell_pcm]
         ? platform_drv_probe+0x30/0x90
         ? driver_probe_device+0x1ed/0x2b0
         ? __driver_attach+0x8f/0xa0
         ? driver_probe_device+0x2b0/0x2b0
         ? bus_for_each_dev+0x55/0x90
         ? bus_add_driver+0x110/0x210
         ? 0xffffffffa11ea000
         ? driver_register+0x52/0xc0
         ? 0xffffffffa11ea000
         ? do_one_initcall+0x32/0x130
         ? free_vmap_area_noflush+0x37/0x70
         ? kmem_cache_alloc+0x88/0xd0
         ? do_init_module+0x51/0x1c4
         ? load_module+0x1ee9/0x2430
         ? show_taint+0x20/0x20
         ? kernel_read_file+0xfd/0x190
         ? SyS_finit_module+0xa3/0xb0
         ? do_syscall_64+0x4a/0xb0
         ? entry_SYSCALL64_slow_path+0x25/0x25
       Code: 78 ff ff ff 4d 85 c0 74 ee 49 8b 5a 10 0f b6 9b e0 00 00 00 41 38 98 e0 00 00 00 77 da 0f b6 eb 49 39 a8 88 00 00 00 72 ce eb 8f <41> f6 82 ab 07 00 00 04 0f 85 76 ff ff ff 0f b6 4d 08 88 0e 49
       RIP  [<ffffffff8132234a>] device_to_iommu+0x11a/0x1a0
        RSP <ffffc90001457a78>
       CR2: 00000000000007ab
       ---[ end trace 16f974b6d58d0aad ]---
      
      Add the missing pointer check.
      
      Fixes: 1c387188 ("iommu/vt-d: Fix IOMMU lookup for SR-IOV Virtual Functions")
      Signed-off-by: default avatarKoos Vriezen <koos.vriezen@gmail.com>
      Signed-off-by: default avatarJoerg Roedel <jroedel@suse.de>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      352c0214
    • Ankur Arora's avatar
      xen/acpi: upload PM state from init-domain to Xen · bc63212d
      Ankur Arora authored
      commit 1914f0cd upstream.
      
      This was broken in commit cd979883 ("xen/acpi-processor:
      fix enabling interrupts on syscore_resume"). do_suspend (from
      xen/manage.c) and thus xen_resume_notifier never get called on
      the initial-domain at resume (it is if running as guest.)
      
      The rationale for the breaking change was that upload_pm_data()
      potentially does blocking work in syscore_resume(). This patch
      addresses the original issue by scheduling upload_pm_data() to
      execute in workqueue context.
      
      Cc: Stanislaw Gruszka <sgruszka@redhat.com>
      Based-on-patch-by: default avatarKonrad Wilk <konrad.wilk@oracle.com>
      Reviewed-by: default avatarKonrad Rzeszutek Wilk <konrad.wilk@oracle.com>
      Reviewed-by: default avatarStanislaw Gruszka <sgruszka@redhat.com>
      Signed-off-by: default avatarAnkur Arora <ankur.a.arora@oracle.com>
      Signed-off-by: default avatarBoris Ostrovsky <boris.ostrovsky@oracle.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      bc63212d
    • Gary R Hook's avatar
      crypto: ccp - Assign DMA commands to the channel's CCP · b1ef9daa
      Gary R Hook authored
      commit 7c468447 upstream.
      
      The CCP driver generally uses a round-robin approach when
      assigning operations to available CCPs. For the DMA engine,
      however, the DMA mappings of the SGs are associated with a
      specific CCP. When an IOMMU is enabled, the IOMMU is
      programmed based on this specific device.
      
      If the DMA operations are not performed by that specific
      CCP then addressing errors and I/O page faults will occur.
      
      Update the CCP driver to allow a specific CCP device to be
      requested for an operation and use this in the DMA engine
      support.
      Signed-off-by: default avatarGary R Hook <gary.hook@amd.com>
      Signed-off-by: default avatarHerbert Xu <herbert@gondor.apana.org.au>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      b1ef9daa
    • Brian Norris's avatar
      mwifiex: pcie: don't leak DMA buffers when removing · cb6e07ba
      Brian Norris authored
      commit 4e841d3e upstream.
      
      When PCIe FLR support was added, much of the remove/release code for
      PCIe was migrated to ->down_dev(), but ->down_dev() is never called for
      device removal. Let's refactor the cleanup to be done in both cases.
      
      Also, drop the comments above mwifiex_cleanup_pcie(), because they were
      clearly wrong, and it's better to have clear and obvious code than to
      detail the code steps in comments anyway.
      
      Fixes: 4c5dae59 ("mwifiex: add PCIe function level reset support")
      Signed-off-by: default avatarBrian Norris <briannorris@chromium.org>
      Signed-off-by: default avatarKalle Valo <kvalo@codeaurora.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      cb6e07ba
    • Chen-Yu Tsai's avatar
      clk: sunxi-ng: mp: Adjust parent rate for pre-dividers · 35ef543e
      Chen-Yu Tsai authored
      commit ac8616e4 upstream.
      
      The MP style clocks support an mux with pre-dividers. While the driver
      correctly accounted for them in the .determine_rate callback, it did
      not in the .recalc_rate and .set_rate callbacks.
      
      This means when calculating the factors in the .set_rate callback, they
      would be off by a factor of the active pre-divider. Same goes for
      reading back the clock rate after it is set.
      
      Fixes: 2ab836db ("clk: sunxi-ng: Add M-P factor clock support")
      Signed-off-by: default avatarChen-Yu Tsai <wens@csie.org>
      Signed-off-by: default avatarMaxime Ripard <maxime.ripard@free-electrons.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      35ef543e
    • Chen-Yu Tsai's avatar
      clk: sunxi-ng: sun6i: Fix enable bit offset for hdmi-ddc module clock · 867f7804
      Chen-Yu Tsai authored
      commit 9ad0bb39 upstream.
      
      The enable bit offset for the hdmi-ddc module clock is wrong. It is
      pointing to the main hdmi module clock enable bit.
      Reported-by: default avatarBob Ham <rah@settrans.net>
      Fixes: c6e6c96d ("clk: sunxi-ng: Add A31/A31s clocks")
      Signed-off-by: default avatarChen-Yu Tsai <wens@csie.org>
      Signed-off-by: default avatarMaxime Ripard <maxime.ripard@free-electrons.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      867f7804
    • Prarit Bhargava's avatar
      hwrng: geode - Revert managed API changes · c445f996
      Prarit Bhargava authored
      commit 8c75704e upstream.
      
      After commit e9afc746 ("hwrng: geode - Use linux/io.h instead of
      asm/io.h") the geode-rng driver uses devres with pci_dev->dev to keep
      track of resources, but does not actually register a PCI driver.  This
      results in the following issues:
      
      1.  The driver leaks memory because the driver does not attach to a
      device.  The driver only uses the PCI device as a reference.   devm_*()
      functions will release resources on driver detach, which the geode-rng
      driver will never do.  As a result,
      
      2.  The driver cannot be reloaded because there is always a use of the
      ioport and region after the first load of the driver.
      
      Revert the changes made by  e9afc746 ("hwrng: geode - Use linux/io.h
      instead of asm/io.h").
      Signed-off-by: default avatarPrarit Bhargava <prarit@redhat.com>
      Fixes: 6e9b5e76 ("hwrng: geode - Migrate to managed API")
      Cc: Matt Mackall <mpm@selenic.com>
      Cc: Corentin LABBE <clabbe.montjoie@gmail.com>
      Cc: PrasannaKumar Muralidharan <prasannatsmkumar@gmail.com>
      Cc: Wei Yongjun <weiyongjun1@huawei.com>
      Cc: linux-crypto@vger.kernel.org
      Cc: linux-geode@lists.infradead.org
      Signed-off-by: default avatarHerbert Xu <herbert@gondor.apana.org.au>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      c445f996
    • Prarit Bhargava's avatar
      hwrng: amd - Revert managed API changes · 5d6f7b36
      Prarit Bhargava authored
      commit 69db7009 upstream.
      
      After commit 31b2a73c ("hwrng: amd - Migrate to managed API"), the
      amd-rng driver uses devres with pci_dev->dev to keep track of resources,
      but does not actually register a PCI driver.  This results in the
      following issues:
      
      1. The message
      
      WARNING: CPU: 2 PID: 621 at drivers/base/dd.c:349 driver_probe_device+0x38c
      
      is output when the i2c_amd756 driver loads and attempts to register a PCI
      driver.  The PCI & device subsystems assume that no resources have been
      registered for the device, and the WARN_ON() triggers since amd-rng has
      already do so.
      
      2.  The driver leaks memory because the driver does not attach to a
      device.  The driver only uses the PCI device as a reference.   devm_*()
      functions will release resources on driver detach, which the amd-rng
      driver will never do.  As a result,
      
      3.  The driver cannot be reloaded because there is always a use of the
      ioport and region after the first load of the driver.
      
      Revert the changes made by 31b2a73c ("hwrng: amd - Migrate to managed
      API").
      Signed-off-by: default avatarPrarit Bhargava <prarit@redhat.com>
      Fixes: 31b2a73c ("hwrng: amd - Migrate to managed API").
      Cc: Matt Mackall <mpm@selenic.com>
      Cc: Corentin LABBE <clabbe.montjoie@gmail.com>
      Cc: PrasannaKumar Muralidharan <prasannatsmkumar@gmail.com>
      Cc: Wei Yongjun <weiyongjun1@huawei.com>
      Cc: linux-crypto@vger.kernel.org
      Cc: linux-geode@lists.infradead.org
      Signed-off-by: default avatarHerbert Xu <herbert@gondor.apana.org.au>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      5d6f7b36
    • Adrian Hunter's avatar
      mmc: sdhci-pci: Do not disable interrupts in sdhci_intel_set_power · 0d69a880
      Adrian Hunter authored
      commit 027fb89e upstream.
      
      Disabling interrupts for even a millisecond can cause problems for some
      devices. That can happen when Intel host controllers wait for the present
      state to propagate.
      
      The spin lock is not necessary here. Anything that is racing with changes
      to the I/O state is already broken. The mmc core already provides
      synchronization via "claiming" the host.
      
      Although the spin lock probably should be removed from the code paths that
      lead to this point, such a patch would touch too much code to be suitable
      for stable trees. Consequently, for this patch, just drop the spin lock
      while waiting.
      Signed-off-by: default avatarAdrian Hunter <adrian.hunter@intel.com>
      Signed-off-by: default avatarUlf Hansson <ulf.hansson@linaro.org>
      Tested-by: default avatarLudovic Desroches <ludovic.desroches@microchip.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      0d69a880
    • Adrian Hunter's avatar
      mmc: sdhci: Do not disable interrupts while waiting for clock · b43ba21b
      Adrian Hunter authored
      commit e2ebfb21 upstream.
      
      Disabling interrupts for even a millisecond can cause problems for some
      devices. That can happen when sdhci changes clock frequency because it
      waits for the clock to become stable under a spin lock.
      
      The spin lock is not necessary here. Anything that is racing with changes
      to the I/O state is already broken. The mmc core already provides
      synchronization via "claiming" the host.
      
      Although the spin lock probably should be removed from the code paths that
      lead to this point, such a patch would touch too much code to be suitable
      for stable trees. Consequently, for this patch, just drop the spin lock
      while waiting.
      Signed-off-by: default avatarAdrian Hunter <adrian.hunter@intel.com>
      Signed-off-by: default avatarUlf Hansson <ulf.hansson@linaro.org>
      Tested-by: default avatarLudovic Desroches <ludovic.desroches@microchip.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      b43ba21b
    • Anssi Hannula's avatar
      mmc: sdhci-of-arasan: fix incorrect timeout clock · 2ab2e879
      Anssi Hannula authored
      commit 16681037 upstream.
      
      sdhci_arasan_get_timeout_clock() divides the frequency it has with (1 <<
      (13 + divisor)).
      
      However, the divisor is not some Arasan-specific value, but instead is
      just the Data Timeout Counter Value from the SDHCI Timeout Control
      Register.
      
      Applying it here like this is wrong as the sdhci driver already takes
      that value into account when calculating timeouts, and in fact it *sets*
      that register value based on how long a timeout is wanted.
      
      Additionally, sdhci core interprets the .get_timeout_clock callback
      return value as if it were read from hardware registers, i.e. the unit
      should be kHz or MHz depending on SDHCI_TIMEOUT_CLK_UNIT capability bit.
      This bit is set at least on the tested Zynq-7000 SoC.
      
      With the tested hardware (SDHCI_TIMEOUT_CLK_UNIT set) this results in
      too high a timeout clock rate being reported, causing the core to use
      longer-than-needed timeouts. Additionally, on a partitioned MMC
      (therefore having erase_group_def bit set) mmc_calc_max_discard()
      disables discard support as it looks like controller does not support
      the long timeouts needed for that.
      
      Do not apply the extra divisor and return the timeout clock in the
      expected unit.
      
      Tested with a Zynq-7000 SoC and a partitioned Toshiba THGBMAG5A1JBAWR
      eMMC card.
      Signed-off-by: default avatarAnssi Hannula <anssi.hannula@bitwise.fi>
      Fixes: e3ec3a3d ("mmc: arasan: Add driver for Arasan SDHCI")
      Signed-off-by: default avatarUlf Hansson <ulf.hansson@linaro.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      2ab2e879
    • Romain Izard's avatar
      mmc: sdhci-of-at91: Support external regulators · ace22e6f
      Romain Izard authored
      commit 2ce0c7b6 upstream.
      
      The SDHCI controller in the SAMA5D2 chip requires a valid voltage set
      in the power control register, otherwise commands will fail with a
      timeout error.
      
      When using the regulator framework to specify the regulator used by the
      mmc device, the voltage is not configured, and it is not possible to use
      the connected device.
      
      Implement a custom 'set_power' function for this specific hardware, that
      configures the voltage in the register in all cases.
      Signed-off-by: default avatarRomain Izard <romain.izard.pro@gmail.com>
      Acked-by: default avatarLudovic Desroches <ludovic.desroches@microchip.com>
      Signed-off-by: default avatarUlf Hansson <ulf.hansson@linaro.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      ace22e6f
    • Nicholas Piggin's avatar
      powerpc/64s: Fix idle wakeup potential to clobber registers · 1e360905
      Nicholas Piggin authored
      commit 6d98ce0b upstream.
      
      We concluded there may be a window where the idle wakeup code could get
      to pnv_wakeup_tb_loss() (which clobbers non-volatile GPRs), but the
      hardware may set SRR1[46:47] to 01b (no state loss) which would result
      in the wakeup code failing to restore non-volatile GPRs.
      
      I was not able to trigger this condition with trivial tests on real
      hardware or simulator, but the ISA (at least 2.07) seems to allow for
      it, and Gautham says that it can happen if there is an exception pending
      when the sleep/winkle instruction is executed.
      
      Fixes: 17065671 ("powerpc/kvm: make hypervisor state restore a function")
      Signed-off-by: default avatarNicholas Piggin <npiggin@gmail.com>
      Acked-by: default avatarGautham R. Shenoy <ego@linux.vnet.ibm.com>
      Signed-off-by: default avatarMichael Ellerman <mpe@ellerman.id.au>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      1e360905
    • Theodore Ts'o's avatar
      ext4: lock the xattr block before checksuming it · 9a9dc3ec
      Theodore Ts'o authored
      commit dac7a4b4 upstream.
      
      We must lock the xattr block before calculating or verifying the
      checksum in order to avoid spurious checksum failures.
      
      https://bugzilla.kernel.org/show_bug.cgi?id=193661Reported-by: default avatarColin Ian King <colin.king@canonical.com>
      Signed-off-by: default avatarTheodore Ts'o <tytso@mit.edu>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      9a9dc3ec
    • Eric Biggers's avatar
      ext4: mark inode dirty after converting inline directory · f572ba9a
      Eric Biggers authored
      commit b9cf625d upstream.
      
      If ext4_convert_inline_data() was called on a directory with inline
      data, the filesystem was left in an inconsistent state (as considered by
      e2fsck) because the file size was not increased to cover the new block.
      This happened because the inode was not marked dirty after i_disksize
      was updated.  Fix this by marking the inode dirty at the end of
      ext4_finish_convert_inline_dir().
      
      This bug was probably not noticed before because most users mark the
      inode dirty afterwards for other reasons.  But if userspace executed
      FS_IOC_SET_ENCRYPTION_POLICY with invalid parameters, as exercised by
      'kvm-xfstests -c adv generic/396', then the inode was never marked dirty
      after updating i_disksize.
      
      Fixes: 3c47d541Signed-off-by: default avatarEric Biggers <ebiggers@google.com>
      Signed-off-by: default avatarTheodore Ts'o <tytso@mit.edu>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      f572ba9a
    • Sudip Mukherjee's avatar
      parport: fix attempt to write duplicate procfiles · 0f29bcfd
      Sudip Mukherjee authored
      commit 03270c6a upstream.
      
      Usually every parallel port will have a single pardev registered with
      it. But ppdev driver is an exception. This userspace parallel port
      driver allows to create multiple parrallel port devices for a single
      parallel port. And as a result we were having a nice warning like:
      "sysctl table check failed:
      /dev/parport/parport0/devices/ppdev0/timeslice Sysctl already exists"
      
      Use the same logic as used in parport_register_device() and register
      the proc files only once for each parallel port.
      
      Fixes: 6fa45a22 ("parport: add device-model to parport subsystem")
      Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=1414656
      Bugzilla: https://bugs.archlinux.org/task/52322Tested-by: default avatarJames Feeney <james@nurealm.net>
      Signed-off-by: default avatarSudip Mukherjee <sudip.mukherjee@codethink.co.uk>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      0f29bcfd
    • Dmitry Torokhov's avatar
      iio: magnetometer: ak8974: remove incorrect __exit markups · 1e6b5033
      Dmitry Torokhov authored
      commit 3ff861f5 upstream.
      
      Even if bus is not hot-pluggable, devices can be unbound from the
      driver via sysfs, so we should not be using __exit annotations on
      remove() methods. The only exception is drivers registered with
      platform_driver_probe() which specifically disables sysfs bind/unbind
      attributes.
      Signed-off-by: default avatarDmitry Torokhov <dmitry.torokhov@gmail.com>
      Reviewed-by: default avatarLinus Walleij <linus.walleij@linaro.org>
      Signed-off-by: default avatarJonathan Cameron <jic23@kernel.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      1e6b5033
    • Song Hongyan's avatar
      iio: hid-sensor-trigger: Change get poll value function order to avoid sensor... · 9808ff15
      Song Hongyan authored
      iio: hid-sensor-trigger: Change get poll value function order to avoid sensor properties losing after resume from S3
      
      commit 3bec2474 upstream.
      
      In function _hid_sensor_power_state(), when hid_sensor_read_poll_value()
      is called, sensor's all properties will be updated by the value from
      sensor hardware/firmware.
      In some implementation, sensor hardware/firmware will do a power cycle
      during S3. In this case, after resume, once hid_sensor_read_poll_value()
      is called, sensor's all properties which are kept by driver during S3
      will be changed to default value.
      But instead, if a set feature function is called first, sensor
      hardware/firmware will be recovered to the last status. So change the
      sensor_hub_set_feature() calling order to behind of set feature function
      to avoid sensor properties lose.
      Signed-off-by: default avatarSong Hongyan <hongyan.song@intel.com>
      Acked-by: default avatarSrinivas Pandruvada <srinivas.pandruvada@linux.intel.com>
      Signed-off-by: default avatarJonathan Cameron <jic23@kernel.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      
      9808ff15
    • Lars-Peter Clausen's avatar
      iio: sw-device: Fix config group initialization · cf43d679
      Lars-Peter Clausen authored
      commit c42f8218 upstream.
      
      Use the IS_ENABLED() helper macro to ensure that the configfs group is
      initialized either when configfs is built-in or when configfs is built as a
      module. Otherwise software device creation will result in undefined
      behaviour when configfs is built as a module since the configfs group for
      the device not properly initialized.
      
      Similar to commit b2f0c096 ("iio: sw-trigger: Fix config group
      initialization").
      
      Fixes: 0f3a8c3f ("iio: Add support for creating IIO devices via configfs")
      Reported-by: default avatarMiguel Robles <miguel.robles@farole.net>
      Signed-off-by: default avatarLars-Peter Clausen <lars@metafoo.de>
      Acked-by: default avatarDaniel Baluta <daniel.baluta@gmail.com>
      Signed-off-by: default avatarJonathan Cameron <jic23@kernel.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      cf43d679
    • Michael Engl's avatar
      iio: adc: ti_am335x_adc: fix fifo overrun recovery · ec271b0e
      Michael Engl authored
      commit e83bb3e6 upstream.
      
      The tiadc_irq_h(int irq, void *private) function is handling FIFO
      overruns by clearing flags, disabling and enabling the ADC to
      recover.
      
      If the ADC is running in continuous mode a FIFO overrun happens
      regularly. If the disabling of the ADC happens concurrently with
      a new conversion. It might happen that the enabling of the ADC
      is ignored by the hardware. This stops the ADC permanently. No
      more interrupts are triggered.
      
      According to the AM335x Reference Manual (SPRUH73H October 2011 -
      Revised April 2013 - Chapter 12.4 and 12.5) it is necessary to
      check the ADC FSM bits in REG_ADCFSM before enabling the ADC
      again. Because the disabling of the ADC is done right after the
      current conversion has been finished.
      
      To trigger this bug it is necessary to run the ADC in continuous
      mode. The ADC values of all channels need to be read in an endless
      loop. The bug appears within the first 6 hours (~5.4 million
      handled FIFO overruns). The user space application will hang on
      reading new values from the character device.
      
      Fixes: ca9a5638 ("iio: ti_am335x_adc: Add continuous sampling support")
      Signed-off-by: default avatarMichael Engl <michael.engl@wjw-solutions.com>
      Signed-off-by: default avatarJonathan Cameron <jic23@kernel.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      ec271b0e
    • Johan Hovold's avatar
      mmc: ushc: fix NULL-deref at probe · dfcacd07
      Johan Hovold authored
      commit 181302dc upstream.
      
      Make sure to check the number of endpoints to avoid dereferencing a
      NULL-pointer should a malicious device lack endpoints.
      
      Fixes: 53f3a9e2 ("mmc: USB SD Host Controller (USHC) driver")
      Cc: David Vrabel <david.vrabel@csr.com>
      Signed-off-by: default avatarJohan Hovold <johan@kernel.org>
      Signed-off-by: default avatarUlf Hansson <ulf.hansson@linaro.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      dfcacd07
    • Johan Hovold's avatar
      uwb: hwa-rc: fix NULL-deref at probe · 2e7486a0
      Johan Hovold authored
      commit daf229b1 upstream.
      
      Make sure to check the number of endpoints to avoid dereferencing a
      NULL-pointer should a malicious device lack endpoints.
      
      Note that the dereference happens in the start callback which is called
      during probe.
      
      Fixes: de520b8b ("uwb: add HWA radio controller driver")
      Cc: Inaky Perez-Gonzalez <inaky.perez-gonzalez@intel.com>
      Cc: David Vrabel <david.vrabel@csr.com>
      Signed-off-by: default avatarJohan Hovold <johan@kernel.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      2e7486a0
    • Johan Hovold's avatar
      uwb: i1480-dfu: fix NULL-deref at probe · f01c54fe
      Johan Hovold authored
      commit 4ce36271 upstream.
      
      Make sure to check the number of endpoints to avoid dereferencing a
      NULL-pointer should a malicious device lack endpoints.
      
      Note that the dereference happens in the cmd and wait_init_done
      callbacks which are called during probe.
      
      Fixes: 1ba47da5 ("uwb: add the i1480 DFU driver")
      Cc: Inaky Perez-Gonzalez <inaky.perez-gonzalez@intel.com>
      Cc: David Vrabel <david.vrabel@csr.com>
      Signed-off-by: default avatarJohan Hovold <johan@kernel.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      f01c54fe
    • Johan Hovold's avatar
      USB: usbtmc: fix probe error path · 5e50afb2
      Johan Hovold authored
      commit 2e47c535 upstream.
      
      Make sure to initialise the return value to avoid having allocation
      failures going unnoticed when allocating interrupt-endpoint resources.
      
      This prevents use-after-free or worse when the device is later unbound.
      
      Fixes: dbf3e7f6 ("Implement an ioctl to support the USMTMC-USB488 READ_STATUS_BYTE operation.")
      Cc: Dave Penkler <dpenkler@gmail.com>
      Signed-off-by: default avatarJohan Hovold <johan@kernel.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      5e50afb2
    • Johan Hovold's avatar
      USB: usbtmc: add missing endpoint sanity check · 73c4e2ed
      Johan Hovold authored
      commit 687e0687 upstream.
      
      USBTMC devices are required to have a bulk-in and a bulk-out endpoint,
      but the driver failed to verify this, something which could lead to the
      endpoint addresses being taken from uninitialised memory.
      
      Make sure to zero all private data as part of allocation, and add the
      missing endpoint sanity check.
      
      Note that this also addresses a more recently introduced issue, where
      the interrupt-in-presence flag would also be uninitialised whenever the
      optional interrupt-in endpoint is not present. This in turn could lead
      to an interrupt urb being allocated, initialised and submitted based on
      uninitialised values.
      
      Fixes: dbf3e7f6 ("Implement an ioctl to support the USMTMC-USB488 READ_STATUS_BYTE operation.")
      Fixes: 5b775f67 ("USB: add USB test and measurement class driver")
      Signed-off-by: default avatarJohan Hovold <johan@kernel.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      73c4e2ed
    • Guenter Roeck's avatar
      usb: hub: Fix crash after failure to read BOS descriptor · 4e615886
      Guenter Roeck authored
      commit 7b2db29f upstream.
      
      If usb_get_bos_descriptor() returns an error, usb->bos will be NULL.
      Nevertheless, it is dereferenced unconditionally in
      hub_set_initial_usb2_lpm_policy() if usb2_hw_lpm_capable is set.
      This results in a crash.
      
      usb 5-1: unable to get BOS descriptor
      ...
      Unable to handle kernel NULL pointer dereference at virtual address 00000008
      pgd = ffffffc00165f000
      [00000008] *pgd=000000000174f003, *pud=000000000174f003,
      		*pmd=0000000001750003, *pte=00e8000001751713
      Internal error: Oops: 96000005 [#1] PREEMPT SMP
      Modules linked in: uinput uvcvideo videobuf2_vmalloc cmac [ ... ]
      CPU: 5 PID: 3353 Comm: kworker/5:3 Tainted: G    B 4.4.52 #480
      Hardware name: Google Kevin (DT)
      Workqueue: events driver_set_config_work
      task: ffffffc0c3690000 ti: ffffffc0ae9a8000 task.ti: ffffffc0ae9a8000
      PC is at hub_port_init+0xc3c/0xd10
      LR is at hub_port_init+0xc3c/0xd10
      ...
      Call trace:
      [<ffffffc0007fbbfc>] hub_port_init+0xc3c/0xd10
      [<ffffffc0007fbe2c>] usb_reset_and_verify_device+0x15c/0x82c
      [<ffffffc0007fc5e0>] usb_reset_device+0xe4/0x298
      [<ffffffbffc0e3fcc>] rtl8152_probe+0x84/0x9b0 [r8152]
      [<ffffffc00080ca8c>] usb_probe_interface+0x244/0x2f8
      [<ffffffc000774a24>] driver_probe_device+0x180/0x3b4
      [<ffffffc000774e48>] __device_attach_driver+0xb4/0xe0
      [<ffffffc000772168>] bus_for_each_drv+0xb4/0xe4
      [<ffffffc0007747ec>] __device_attach+0xd0/0x158
      [<ffffffc000775080>] device_initial_probe+0x24/0x30
      [<ffffffc0007739d4>] bus_probe_device+0x50/0xe4
      [<ffffffc000770bd0>] device_add+0x414/0x738
      [<ffffffc000809fe8>] usb_set_configuration+0x89c/0x914
      [<ffffffc00080a120>] driver_set_config_work+0xc0/0xf0
      [<ffffffc000249bb8>] process_one_work+0x390/0x6b8
      [<ffffffc00024abcc>] worker_thread+0x480/0x610
      [<ffffffc000251a80>] kthread+0x164/0x178
      [<ffffffc0002045d0>] ret_from_fork+0x10/0x40
      
      Since we don't know anything about LPM capabilities without BOS descriptor,
      don't attempt to enable LPM if it is not available.
      
      Fixes: 890dae88 ("xhci: Enable LPM support only for hardwired ...")
      Cc: Mathias Nyman <mathias.nyman@linux.intel.com>
      Signed-off-by: default avatarGuenter Roeck <linux@roeck-us.net>
      Acked-by: default avatarMathias Nyman <mathias.nyman@linux.intel.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      4e615886
    • Bin Liu's avatar
      usb: musb: cppi41: don't check early-TX-interrupt for Isoch transfer · 51a3f3ec
      Bin Liu authored
      commit 0090114d upstream.
      
      The CPPI 4.1 driver polls register to workaround the premature TX
      interrupt issue, but it causes audio playback underrun when triggered in
      Isoch transfers.
      
      Isoch doesn't do back-to-back transfers, the TX should be done by the
      time the next transfer is scheduled. So skip this polling workaround for
      Isoch transfer.
      
      Fixes: a655f481 ("usb: musb: musb_cppi41: handle pre-mature TX complete interrupt")
      Reported-by: default avatarAlexandre Bailon <abailon@baylibre.com>
      Acked-by: default avatarSebastian Andrzej Siewior <bigeasy@linutronix.de>
      Tested-by: default avatarAlexandre Bailon <abailon@baylibre.com>
      Signed-off-by: default avatarBin Liu <b-liu@ti.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      51a3f3ec
    • Johan Hovold's avatar
      USB: wusbcore: fix NULL-deref at probe · 46aeeb2a
      Johan Hovold authored
      commit 03ace948 upstream.
      
      Make sure to check the number of endpoints to avoid dereferencing a
      NULL-pointer or accessing memory beyond the endpoint array should a
      malicious device lack the expected endpoints.
      
      This specifically fixes the NULL-pointer dereference when probing HWA HC
      devices.
      
      Fixes: df365423 ("wusb: add the Wire Adapter (WA) core")
      Cc: Inaky Perez-Gonzalez <inaky.perez-gonzalez@intel.com>
      Cc: David Vrabel <david.vrabel@csr.com>
      Signed-off-by: default avatarJohan Hovold <johan@kernel.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      46aeeb2a
    • Johan Hovold's avatar
      USB: idmouse: fix NULL-deref at probe · a4887ea5
      Johan Hovold authored
      commit b0addd3f upstream.
      
      Make sure to check the number of endpoints to avoid dereferencing a
      NULL-pointer should a malicious device lack endpoints.
      
      Fixes: 1da177e4 ("Linux-2.6.12-rc2")
      Signed-off-by: default avatarJohan Hovold <johan@kernel.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      a4887ea5
    • Johan Hovold's avatar
      USB: lvtest: fix NULL-deref at probe · 21e0621e
      Johan Hovold authored
      commit 1dc56c52 upstream.
      
      Make sure to check the number of endpoints to avoid dereferencing a
      NULL-pointer should the probed device lack endpoints.
      
      Note that this driver does not bind to any devices by default.
      
      Fixes: ce21bfe6 ("USB: Add LVS Test device driver")
      Cc: Pratyush Anand <pratyush.anand@gmail.com>
      Signed-off-by: default avatarJohan Hovold <johan@kernel.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      21e0621e
    • Johan Hovold's avatar
      USB: uss720: fix NULL-deref at probe · e4942716
      Johan Hovold authored
      commit f259ca3e upstream.
      
      Make sure to check the number of endpoints to avoid dereferencing a
      NULL-pointer or accessing memory beyond the endpoint array should a
      malicious device lack the expected endpoints.
      
      Note that the endpoint access that causes the NULL-deref is currently
      only used for debugging purposes during probe so the oops only happens
      when dynamic debugging is enabled. This means the driver could be
      rewritten to continue to accept device with only two endpoints, should
      such devices exist.
      
      Fixes: 1da177e4 ("Linux-2.6.12-rc2")
      Signed-off-by: default avatarJohan Hovold <johan@kernel.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      e4942716
    • Samuel Thibault's avatar
      usb-core: Add LINEAR_FRAME_INTR_BINTERVAL USB quirk · 222ccd4f
      Samuel Thibault authored
      commit 3243367b upstream.
      
      Some USB 2.0 devices erroneously report millisecond values in
      bInterval. The generic config code manages to catch most of them,
      but in some cases it's not completely enough.
      
      The case at stake here is a USB 2.0 braille device, which wants to
      announce 10ms and thus sets bInterval to 10, but with the USB 2.0
      computation that yields to 64ms.  It happens that one can type fast
      enough to reach this interval and get the device buffers overflown,
      leading to problematic latencies.  The generic config code does not
      catch this case because the 64ms is considered a sane enough value.
      
      This change thus adds a USB_QUIRK_LINEAR_FRAME_INTR_BINTERVAL quirk
      to mark devices which actually report milliseconds in bInterval,
      and marks Vario Ultra devices as needing it.
      Signed-off-by: default avatarSamuel Thibault <samuel.thibault@ens-lyon.org>
      Acked-by: default avatarAlan Stern <stern@rowland.harvard.edu>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      222ccd4f