1. 11 4月, 2019 4 次提交
  2. 09 4月, 2019 1 次提交
    • I
      drm/i915: Get power refs in encoder->get_power_domains() · bef42cb2
      Imre Deak 提交于
      Push getting the reference for the encoders' power domains into the
      encoder get_power_domains() hook instead of doing this from the caller.
      This way the encoder can store away the corresponding wakerefs.
      
      This fixes the DSI encoder disabling, which didn't release these
      power references it acquired during HW state readout.
      
      Note that longtime ownership for the corresponding wakerefs can be thus
      acquired / released in two ways. Nevertheless there is always only one
      owner for them:
      
      After HW readout (booting/system resume):
      - encoder->get_power_domains() acquires
      - encoder->disable*() releases
      
      After a modeset (calling intel_atomic_commit()):
      - encoder->enable*() acquires
      - encoder->disable*() releases
      
      * can be any of the encoder enable/disable hooks.
      
      v2:
      - Check that the DSI io_wakerefs are unset both during encoder HW
        readout and enabling. (Chris)
      
      Fixes: 0e6e0be4 ("drm/i915: Markup paired operations on display power domains")
      Cc: Vandita Kulkarni <vandita.kulkarni@intel.com>
      Cc: Chris Wilson <chris@chris-wilson.co.uk>
      Signed-off-by: NImre Deak <imre.deak@intel.com>
      Reviewed-by: NChris Wilson <chris@chris-wilson.co.uk>
      Link: https://patchwork.freedesktop.org/patch/msgid/20190407124655.31536-1-imre.deak@intel.com
      (cherry picked from commit 3a52fb7e)
      Signed-off-by: NRodrigo Vivi <rodrigo.vivi@intel.com>
      bef42cb2
  3. 08 4月, 2019 3 次提交
    • V
      drm/i915: Fix pipe_bpp readout for BXT/GLK DSI · e1b7058e
      Ville Syrjälä 提交于
      The only bpc information in pipe registers for BXT/GLK DSI
      is the PIPEMISC dither bpc. Let's try to use that to read
      out pipe_bpp on these platforms. However, I'm not sure if
      this will be correctly populated by the GOP since bspec
      suggests it's only needed if dithering is actually enabled.
      If not I guess we'll have to go one step further and
      extract pipe_bpp from the DSI pixel format when dithering
      is disabled.
      
      Cc: Hans de Goede <hdegoede@redhat.com>
      Fixes: ca0b04db ("drm/i915/dsi: Fix pipe_bpp for handling for 6 bpc pixel-formats")
      References: https://bugs.freedesktop.org/show_bug.cgi?id=109516Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
      Reviewed-by: NImre Deak <imre.deak@intel.com>
      Signed-off-by: NJani Nikula <jani.nikula@intel.com>
      Link: https://patchwork.freedesktop.org/patch/msgid/20190405141349.11950-1-ville.syrjala@linux.intel.com
      (cherry picked from commit 49965350)
      Signed-off-by: NRodrigo Vivi <rodrigo.vivi@intel.com>
      e1b7058e
    • C
      drm/i915/gvt: Prevent use-after-free in ppgtt_free_all_spt() · 968a85b1
      Chris Wilson 提交于
      ppgtt_free_all_spt() iterates the radixtree as it is deleting it,
      forgoing all protection against the leaves being freed in the process
      (leaving the iter pointing into the void).
      
      A minimal fix seems to be to use the available post_shadow_list to
      decompose the tree into a list prior to destroying the radixtree.
      
      Alerted by the sparse warnings:
      
      drivers/gpu/drm/i915/gvt/gtt.c:757:9: warning: incorrect type in assignment (different address spaces)
      drivers/gpu/drm/i915/gvt/gtt.c:757:9:    expected void **slot
      drivers/gpu/drm/i915/gvt/gtt.c:757:9:    got void [noderef] <asn:4> **
      drivers/gpu/drm/i915/gvt/gtt.c:757:9: warning: incorrect type in assignment (different address spaces)
      drivers/gpu/drm/i915/gvt/gtt.c:757:9:    expected void **slot
      drivers/gpu/drm/i915/gvt/gtt.c:757:9:    got void [noderef] <asn:4> **
      drivers/gpu/drm/i915/gvt/gtt.c:758:45: warning: incorrect type in argument 1 (different address spaces)
      drivers/gpu/drm/i915/gvt/gtt.c:758:45:    expected void [noderef] <asn:4> **slot
      drivers/gpu/drm/i915/gvt/gtt.c:758:45:    got void **slot
      drivers/gpu/drm/i915/gvt/gtt.c:757:9: warning: incorrect type in argument 1 (different address spaces)
      drivers/gpu/drm/i915/gvt/gtt.c:757:9:    expected void [noderef] <asn:4> **slot
      drivers/gpu/drm/i915/gvt/gtt.c:757:9:    got void **slot
      drivers/gpu/drm/i915/gvt/gtt.c:757:9: warning: incorrect type in assignment (different address spaces)
      drivers/gpu/drm/i915/gvt/gtt.c:757:9:    expected void **slot
      drivers/gpu/drm/i915/gvt/gtt.c:757:9:    got void [noderef] <asn:4> **
      
      This would also have been loudly warning if run through CI for the
      invalid RCU dereferences.
      
      Fixes: b6c126a3 ("drm/i915/gvt: Manage shadow pages with radix tree")
      Reviewed-by: NZhenyu Wang <zhenyuw@linux.intel.com>
      Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
      Cc: Changbin Du <changbin.du@intel.com>
      Cc: Zhenyu Wang <zhenyuw@linux.intel.com>
      Cc: Zhi Wang <zhi.a.wang@intel.com>
      Signed-off-by: NZhenyu Wang <zhenyuw@linux.intel.com>
      968a85b1
    • C
      drm/i915/gvt: Annotate iomem usage · 196a6627
      Chris Wilson 提交于
      Fix the sparse warning for blithely using iomem with normal memcpy:
      
      drivers/gpu/drm/i915/gvt/kvmgt.c:916:21: warning: incorrect type in assignment (different address spaces)
      drivers/gpu/drm/i915/gvt/kvmgt.c:916:21:    expected void *aperture_va
      drivers/gpu/drm/i915/gvt/kvmgt.c:916:21:    got void [noderef] <asn:2> *
      drivers/gpu/drm/i915/gvt/kvmgt.c:927:26: warning: incorrect type in argument 1 (different address spaces)
      drivers/gpu/drm/i915/gvt/kvmgt.c:927:26:    expected void [noderef] <asn:2> *vaddr
      drivers/gpu/drm/i915/gvt/kvmgt.c:927:26:    got void *aperture_va
      
      Fixes: d480b28a ("drm/i915/gvt: Fix aperture read/write emulation when enable x-no-mmap=on")
      Reviewed-by: NZhenyu Wang <zhenyuw@linux.intel.com>
      Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
      Cc: Zhenyu Wang <zhenyuw@linux.intel.com>
      Cc: Changbin Du <changbin.du@intel.com>
      Cc: Zhi Wang <zhi.a.wang@intel.com>
      Signed-off-by: NZhenyu Wang <zhenyuw@linux.intel.com>
      196a6627
  4. 04 4月, 2019 2 次提交
  5. 02 4月, 2019 1 次提交
    • C
      drm/i915: Always backoff after a drm_modeset_lock() deadlock · a145b5b0
      Chris Wilson 提交于
      If drm_modeset_lock() reports a deadlock it sets the ctx->contexted
      field and insists that the caller calls drm_modeset_backoff() or else it
      generates a WARN on cleanup.
      
      <4> [1601.870376] WARNING: CPU: 3 PID: 8445 at drivers/gpu/drm/drm_modeset_lock.c:228 drm_modeset_drop_locks+0x35/0x40
      <4> [1601.870395] Modules linked in: vgem snd_hda_codec_hdmi snd_hda_codec_realtek snd_hda_codec_generic x86_pkg_temp_thermal i915 coretemp crct10dif_pclmul
      <6> [1601.870403] Console: switching
      <4> [1601.870403]  snd_hda_intel
      <4> [1601.870406] to colour frame buffer device 320x90
      <4> [1601.870406]  crc32_pclmul snd_hda_codec snd_hwdep ghash_clmulni_intel e1000e snd_hda_core cdc_ether ptp usbnet mii pps_core snd_pcm i2c_i801 mei_me mei prime_numbers
      <4> [1601.870422] CPU: 3 PID: 8445 Comm: cat Tainted: G     U            5.0.0-rc7-CI-CI_DRM_5650+ #1
      <4> [1601.870424] Hardware name: Intel Corporation Ice Lake Client Platform/IceLake U DDR4 SODIMM PD RVP TLC, BIOS ICLSFWR1.R00.2402.AD3.1810170014 10/17/2018
      <4> [1601.870427] RIP: 0010:drm_modeset_drop_locks+0x35/0x40
      <4> [1601.870430] Code: 29 48 8b 43 60 48 8d 6b 60 48 39 c5 74 19 48 8b 43 60 48 8d b8 70 ff ff ff e8 87 ff ff ff 48 8b 43 60 48 39 c5 75 e7 5b 5d c3 <0f> 0b eb d3 0f 1f 80 00 00 00 00 41 56 41 55 41 54 55 53 48 8b 6f
      <4> [1601.870432] RSP: 0018:ffffc90000d67ce8 EFLAGS: 00010282
      <4> [1601.870435] RAX: 00000000ffffffdd RBX: ffffc90000d67d00 RCX: 5dbbe23d00000000
      <4> [1601.870437] RDX: 0000000000000000 RSI: 0000000093e6194a RDI: ffffc90000d67d00
      <4> [1601.870439] RBP: ffff88849e62e678 R08: 0000000003b7329a R09: 0000000000000001
      <4> [1601.870441] R10: 0000000000000000 R11: 0000000000000000 R12: ffff888492100410
      <4> [1601.870442] R13: ffff88849ea50958 R14: ffff8884a67eb028 R15: ffff8884a67eb028
      <4> [1601.870445] FS:  00007fa7a27745c0(0000) GS:ffff8884aff80000(0000) knlGS:0000000000000000
      <4> [1601.870447] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
      <4> [1601.870449] CR2: 000055af07e66000 CR3: 00000004a8cc2006 CR4: 0000000000760ee0
      <4> [1601.870451] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
      <4> [1601.870453] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
      <4> [1601.870454] PKRU: 55555554
      <4> [1601.870456] Call Trace:
      <4> [1601.870505]  i915_dsc_fec_support_show+0x91/0x190 [i915]
      <4> [1601.870522]  seq_read+0xdb/0x3c0
      <4> [1601.870531]  full_proxy_read+0x51/0x80
      <4> [1601.870538]  __vfs_read+0x31/0x190
      <4> [1601.870546]  ? __se_sys_newfstat+0x3c/0x60
      <4> [1601.870552]  vfs_read+0x9e/0x150
      <4> [1601.870557]  ksys_read+0x50/0xc0
      <4> [1601.870564]  do_syscall_64+0x55/0x190
      <4> [1601.870569]  entry_SYSCALL_64_after_hwframe+0x49/0xbe
      <4> [1601.870572] RIP: 0033:0x7fa7a226d081
      <4> [1601.870574] Code: fe ff ff 48 8d 3d 67 9c 0a 00 48 83 ec 08 e8 a6 4c 02 00 66 0f 1f 44 00 00 48 8d 05 81 08 2e 00 8b 00 85 c0 75 13 31 c0 0f 05 <48> 3d 00 f0 ff ff 77 57 f3 c3 0f 1f 44 00 00 41 54 55 49 89 d4 53
      <4> [1601.870576] RSP: 002b:00007ffcc05140c8 EFLAGS: 00000246 ORIG_RAX: 0000000000000000
      <4> [1601.870579] RAX: ffffffffffffffda RBX: 0000000000020000 RCX: 00007fa7a226d081
      <4> [1601.870581] RDX: 0000000000020000 RSI: 000055af07e63000 RDI: 0000000000000007
      <4> [1601.870583] RBP: 0000000000020000 R08: 000000000000007b R09: 0000000000000000
      <4> [1601.870585] R10: 000055af07e60010 R11: 0000000000000246 R12: 000055af07e63000
      <4> [1601.870587] R13: 0000000000000007 R14: 000055af07e634bf R15: 0000000000020000
      
      Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=109745
      Fixes: e845f099 ("drm/i915/dsc: Add Per connector debugfs node for DSC support/enable")
      Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
      Cc: Rodrigo Vivi <rodrigo.vivi@intel.com>
      Cc: Ville Syrjala <ville.syrjala@linux.intel.com>
      Cc: Anusha Srivatsa <anusha.srivatsa@intel.com>
      Cc: Lyude Paul <lyude@redhat.com>
      Cc: Manasi Navare <manasi.d.navare@intel.com>
      Reviewed-by: NManasi Navare <manasi.d.navare@intel.com>
      Link: https://patchwork.freedesktop.org/patch/msgid/20190329165152.29259-1-chris@chris-wilson.co.uk
      (cherry picked from commit ee6df569)
      Signed-off-by: NRodrigo Vivi <rodrigo.vivi@intel.com>
      a145b5b0
  6. 31 3月, 2019 2 次提交
  7. 30 3月, 2019 5 次提交
    • M
      drivers/block/zram/zram_drv.c: fix idle/writeback string compare · 0bc9f5d1
      Minchan Kim 提交于
      Makoto report a below KASAN error: zram does out-of-bounds read.  Because
      strscpy copies from source up to count bytes unconditionally.  It could
      cause out-of-bounds read on next object in slab.
      
      To prevent it, use strlcpy which checks source's length automatically.
      
         BUG: KASAN: slab-out-of-bounds in strscpy+0x68/0x154
         Read of size 8 at addr ffffffc0c3495a00 by task system_server/1314
         ..
         Call trace:
           strscpy+0x68/0x154
           idle_store+0xc4/0x34c
           dev_attr_store+0x50/0x6c
           sysfs_kf_write+0x98/0xb4
           kernfs_fop_write+0x198/0x260
           __vfs_write+0x10c/0x338
           vfs_write+0x114/0x238
           SyS_write+0xc8/0x168
           __sys_trace_return+0x0/0x4
      
         Allocated by task 1314:
          __kmalloc+0x280/0x318
          kernfs_fop_write+0xac/0x260
          __vfs_write+0x10c/0x338
          vfs_write+0x114/0x238
          SyS_write+0xc8/0x168
          __sys_trace_return+0x0/0x4
      
         Freed by task 2855:
          kfree+0x138/0x630
          kernfs_put_open_node+0x10c/0x124
          kernfs_fop_release+0xd8/0x114
          __fput+0x130/0x2a4
          ____fput+0x1c/0x28
          task_work_run+0x16c/0x1c8
          do_notify_resume+0x2bc/0x107c
          work_pending+0x8/0x10
      
         The buggy address belongs to the object at ffffffc0c3495a00
          which belongs to the cache kmalloc-128 of size 128
         The buggy address is located 0 bytes inside of
          128-byte region [ffffffc0c3495a00, ffffffc0c3495a80)
         The buggy address belongs to the page:
         page:ffffffbf030d2500 count:1 mapcount:0 mapping:          (null) index:0x0 compound_mapcount: 0
         flags: 0x4000000000010200(slab|head)
         page dumped because: kasan: bad access detected
      
         Memory state around the buggy address:
          ffffffc0c3495900: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
          ffffffc0c3495980: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
         >ffffffc0c3495a00: 04 fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
                            ^
          ffffffc0c3495a80: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
          ffffffc0c3495b00: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
      
      Link: http://lkml.kernel.org/r/20190319231911.145968-1-minchan@kernel.org
      Cc: <stable@vger.kernel.org>	[5.0]
      Signed-off-by: NMinchan Kim <minchan@kernel.org>
      Reported-by: NMakoto Wu <makotowu@google.com>
      Reviewed-by: NSergey Senozhatsky <sergey.senozhatsky@gmail.com>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      0bc9f5d1
    • N
      iommu/io-pgtable-arm-v7s: request DMA32 memory, and improve debugging · 0a352554
      Nicolas Boichat 提交于
      IOMMUs using ARMv7 short-descriptor format require page tables (level 1
      and 2) to be allocated within the first 4GB of RAM, even on 64-bit
      systems.
      
      For level 1/2 pages, ensure GFP_DMA32 is used if CONFIG_ZONE_DMA32 is
      defined (e.g.  on arm64 platforms).
      
      For level 2 pages, allocate a slab cache in SLAB_CACHE_DMA32.  Note that
      we do not explicitly pass GFP_DMA[32] to kmem_cache_zalloc, as this is
      not strictly necessary, and would cause a warning in mm/sl*b.c, as we
      did not update GFP_SLAB_BUG_MASK.
      
      Also, print an error when the physical address does not fit in
      32-bit, to make debugging easier in the future.
      
      Link: http://lkml.kernel.org/r/20181210011504.122604-3-drinkcat@chromium.org
      Fixes: ad67f5a6 ("arm64: replace ZONE_DMA with ZONE_DMA32")
      Signed-off-by: NNicolas Boichat <drinkcat@chromium.org>
      Acked-by: NWill Deacon <will.deacon@arm.com>
      Cc: Christoph Hellwig <hch@infradead.org>
      Cc: Christoph Lameter <cl@linux.com>
      Cc: David Rientjes <rientjes@google.com>
      Cc: Hsin-Yi Wang <hsinyi@chromium.org>
      Cc: Huaisheng Ye <yehs1@lenovo.com>
      Cc: Joerg Roedel <joro@8bytes.org>
      Cc: Joonsoo Kim <iamjoonsoo.kim@lge.com>
      Cc: Matthew Wilcox <willy@infradead.org>
      Cc: Matthias Brugger <matthias.bgg@gmail.com>
      Cc: Mel Gorman <mgorman@techsingularity.net>
      Cc: Michal Hocko <mhocko@suse.com>
      Cc: Mike Rapoport <rppt@linux.vnet.ibm.com>
      Cc: Pekka Enberg <penberg@kernel.org>
      Cc: Robin Murphy <robin.murphy@arm.com>
      Cc: Sasha Levin <Alexander.Levin@microsoft.com>
      Cc: Tomasz Figa <tfiga@google.com>
      Cc: Vlastimil Babka <vbabka@suse.cz>
      Cc: Yingjoe Chen <yingjoe.chen@mediatek.com>
      Cc: Yong Wu <yong.wu@mediatek.com>
      Cc: <stable@vger.kernel.org>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      0a352554
    • M
      staging: vt6655: Remove vif check from vnt_interrupt · cc26358f
      Malcolm Priestley 提交于
      A check for vif is made in vnt_interrupt_work.
      
      There is a small chance of leaving interrupt disabled while vif
      is NULL and the work hasn't been scheduled.
      Signed-off-by: NMalcolm Priestley <tvboxspy@gmail.com>
      CC: stable@vger.kernel.org # v4.2+
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      cc26358f
    • G
      staging: erofs: keep corrupted fs from crashing kernel in erofs_readdir() · 33bac912
      Gao Xiang 提交于
      After commit 419d6efc, kernel cannot be crashed in the namei
      path. However, corrupted nameoff can do harm in the process of
      readdir for scenerios without dm-verity as well. Fix it now.
      
      Fixes: 3aa8ec71 ("staging: erofs: add directory operations")
      Cc: <stable@vger.kernel.org> # 4.19+
      Signed-off-by: NGao Xiang <gaoxiang25@huawei.com>
      Reviewed-by: NChao Yu <yuchao0@huawei.com>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      33bac912
    • J
      iommu/amd: Reserve exclusion range in iova-domain · 8aafaaf2
      Joerg Roedel 提交于
      If a device has an exclusion range specified in the IVRS
      table, this region needs to be reserved in the iova-domain
      of that device. This hasn't happened until now and can cause
      data corruption on data transfered with these devices.
      
      Treat exclusion ranges as reserved regions in the iommu-core
      to fix the problem.
      
      Fixes: be2a022c ('x86, AMD IOMMU: add functions to parse IOMMU memory mapping requirements for devices')
      Signed-off-by: NJoerg Roedel <jroedel@suse.de>
      Reviewed-by: NGary R Hook <gary.hook@amd.com>
      8aafaaf2
  8. 29 3月, 2019 10 次提交
  9. 28 3月, 2019 12 次提交
    • R
      libata: fix using DMA buffers on stack · dd08a8d9
      raymond pang 提交于
      When CONFIG_VMAP_STACK=y, __pa() returns incorrect physical address for
      a stack virtual address. Stack DMA buffers must be avoided.
      Signed-off-by: Nraymond pang <raymondpangxd@gmail.com>
      Signed-off-by: NJens Axboe <axboe@kernel.dk>
      dd08a8d9
    • J
      drm/i915/icl: Fix VEBOX mismatch BUG_ON() · 26cdaac4
      José Roberto de Souza 提交于
      GT VEBOX DISABLE is only 4 bits wide but it was using a 8 bits wide
      mask, the remaning reserved bits is set to 0 causing 4 more
      nonexistent VEBOX engines being detected as enabled, triggering the
      BUG_ON() because of mismatch between vebox_mask and newly added
      VEBOX_MASK().
      
      [   64.081621] [drm:intel_device_info_init_mmio [i915]] vdbox enable: 0005, instances: 0005
      [   64.081763] [drm:intel_device_info_init_mmio [i915]] vebox enable: 00f1, instances: 0001
      [   64.081825] intel_device_info_init_mmio:925 GEM_BUG_ON(vebox_mask != ({ unsigned int first__ = (VECS0); unsigned int count__ = (2); ((&(dev_priv)->__info)->engine_mask & (((~0UL) - (1UL << (first__)) + 1) & (~0UL >> (64 - 1 - (first__ + count__ - 1))))) >> first__; }))
      [   64.082047] ------------[ cut here ]------------
      [   64.082054] kernel BUG at drivers/gpu/drm/i915/intel_device_info.c:925!
      
      BSpec: 20680
      Fixes: 26376a7e ("drm/i915/icl: Check for fused-off VDBOX and VEBOX instances")
      Cc: Chris Wilson <chris@chris-wilson.co.uk>
      Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
      Cc: Oscar Mateo <oscar.mateo@intel.com>
      Signed-off-by: NJosé Roberto de Souza <jose.souza@intel.com>
      Reviewed-by: NTvrtko Ursulin <tvrtko.ursulin@intel.com>
      Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
      Link: https://patchwork.freedesktop.org/patch/msgid/20190326230223.26336-1-jose.souza@intel.com
      (cherry picked from commit 547fcf9b)
      Signed-off-by: NJani Nikula <jani.nikula@intel.com>
      26cdaac4
    • V
      cpufreq: scpi: Fix use after free · 31d4c528
      Vincent Stehlé 提交于
      Free the priv structure only after we are done using it.
      
      Fixes: 1690d8bb ("cpufreq: scpi/scmi: Fix freeing of dynamic OPPs")
      Signed-off-by: NVincent Stehlé <vincent.stehle@laposte.net>
      Cc: 4.20+ <stable@vger.kernel.org> # 4.20+
      Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
      31d4c528
    • B
      USB: serial: option: add Olicard 600 · 84f3b43f
      Bjørn Mork 提交于
      This is a Qualcomm based device with a QMI function on interface 4.
      It is mode switched from 2020:2030 using a standard eject message.
      
      T:  Bus=01 Lev=01 Prnt=01 Port=00 Cnt=01 Dev#=  6 Spd=480  MxCh= 0
      D:  Ver= 2.00 Cls=00(>ifc ) Sub=00 Prot=00 MxPS=64 #Cfgs=  1
      P:  Vendor=2020 ProdID=2031 Rev= 2.32
      S:  Manufacturer=Mobile Connect
      S:  Product=Mobile Connect
      S:  SerialNumber=0123456789ABCDEF
      C:* #Ifs= 6 Cfg#= 1 Atr=80 MxPwr=500mA
      I:* If#= 0 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=ff Prot=ff Driver=(none)
      E:  Ad=81(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms
      E:  Ad=01(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms
      I:* If#= 1 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=00 Prot=00 Driver=(none)
      E:  Ad=83(I) Atr=03(Int.) MxPS=  10 Ivl=32ms
      E:  Ad=82(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms
      E:  Ad=02(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms
      I:* If#= 2 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=00 Prot=00 Driver=(none)
      E:  Ad=85(I) Atr=03(Int.) MxPS=  10 Ivl=32ms
      E:  Ad=84(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms
      E:  Ad=03(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms
      I:* If#= 3 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=00 Prot=00 Driver=(none)
      E:  Ad=87(I) Atr=03(Int.) MxPS=  10 Ivl=32ms
      E:  Ad=86(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms
      E:  Ad=04(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms
      I:* If#= 4 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=ff Prot=ff Driver=(none)
      E:  Ad=89(I) Atr=03(Int.) MxPS=   8 Ivl=32ms
      E:  Ad=88(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms
      E:  Ad=05(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms
      I:* If#= 5 Alt= 0 #EPs= 2 Cls=08(stor.) Sub=06 Prot=50 Driver=(none)
      E:  Ad=8a(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms
      E:  Ad=06(O) Atr=02(Bulk) MxPS= 512 Ivl=125us
      
      Cc: stable@vger.kernel.org
      Signed-off-by: NBjørn Mork <bjorn@mork.no>
      [ johan: use tabs to align comments in adjacent lines ]
      Signed-off-by: NJohan Hovold <johan@kernel.org>
      84f3b43f
    • G
      USB: serial: cp210x: add new device id · a595ecdd
      Greg Kroah-Hartman 提交于
      Lorenz Messtechnik has a device that is controlled by the cp210x driver,
      so add the device id to the driver.  The device id was provided by
      Silicon-Labs for the devices from this vendor.
      Reported-by: NUli <t9cpu@web.de>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      Cc: stable <stable@vger.kernel.org>
      Signed-off-by: NJohan Hovold <johan@kernel.org>
      a595ecdd
    • T
      scsi: ibmvfc: Clean up transport events · d6e2635b
      Tyrel Datwyler 提交于
      No change to functionality. Simply make transport event messages a little
      clearer, and rework CRQ format enums such that we have separate enums for
      INIT messages and XPORT events.
      
      [mkp: typo]
      Signed-off-by: NTyrel Datwyler <tyreld@linux.vnet.ibm.com>
      Signed-off-by: NMartin K. Petersen <martin.petersen@oracle.com>
      d6e2635b
    • T
      scsi: ibmvfc: Byte swap status and error codes when logging · 3e6f7de4
      Tyrel Datwyler 提交于
      Status and error codes are returned in big endian from the VIOS. The values
      are translated into a human readable format when logged, but the values are
      also logged. This patch byte swaps those values so that they are consistent
      between BE and LE platforms.
      Signed-off-by: NTyrel Datwyler <tyreld@linux.vnet.ibm.com>
      Signed-off-by: NMartin K. Petersen <martin.petersen@oracle.com>
      3e6f7de4
    • T
      scsi: ibmvfc: Add failed PRLI to cmd_status lookup array · 95237c25
      Tyrel Datwyler 提交于
      The VIOS uses the SCSI_ERROR class to report PRLI failures. These errors
      are indicated with the combination of a IBMVFC_FC_SCSI_ERROR return status
      and 0x8000 error code. Add these codes to cmd_status[] with appropriate
      human readable error message.
      Signed-off-by: NTyrel Datwyler <tyreld@linux.vnet.ibm.com>
      Signed-off-by: NMartin K. Petersen <martin.petersen@oracle.com>
      95237c25
    • T
      scsi: ibmvfc: Remove "failed" from logged errors · 6dc6a944
      Tyrel Datwyler 提交于
      The text of messages logged with ibmvfc_log_error() always contain the term
      "failed". In the case of cancelled commands during EH they are reported
      back by the VIOS using error codes. This can be confusing to somebody
      looking at these log messages as to whether a command was successfully
      cancelled. The following real log message for example it is unclear if the
      transaction was actaully cancelled.
      
      <6>sd 0:0:1:1: Cancelling outstanding commands.
      <3>sd 0:0:1:1: [sde] Command (28) failed: transaction cancelled (2:6) flags: 0 fcp_rsp: 0, resid=0, scsi_status: 0
      
      Remove prefixing of "failed" to all error logged messages. The
      ibmvfc_log_error() function translates the returned error/status codes to a
      human readable message already.
      Signed-off-by: NTyrel Datwyler <tyreld@linux.vnet.ibm.com>
      Signed-off-by: NMartin K. Petersen <martin.petersen@oracle.com>
      6dc6a944
    • S
      scsi: zfcp: reduce flood of fcrscn1 trace records on multi-element RSCN · c8206579
      Steffen Maier 提交于
      If an incoming ELS of type RSCN contains more than one element, zfcp
      suboptimally causes repeated erp trigger NOP trace records for each
      previously failed port. These could be ports that went away.  It loops over
      each RSCN element, and for each of those in an inner loop over all
      zfcp_ports.
      
      The trigger to recover failed ports should be just the reception of some
      RSCN, no matter how many elements it has. So we can loop over failed ports
      separately, and only then loop over each RSCN element to handle the
      non-failed ports.
      
      The call chain was:
      
        zfcp_fc_incoming_rscn
          for (i = 1; i < no_entries; i++)
            _zfcp_fc_incoming_rscn
              list_for_each_entry(port, &adapter->port_list, list)
                if (masked port->d_id match) zfcp_fc_test_link
                if (!port->d_id) zfcp_erp_port_reopen "fcrscn1"   <===
      
      In order the reduce the "flooding" of the REC trace area in such cases, we
      factor out handling the failed ports to be outside of the entries loop:
      
        zfcp_fc_incoming_rscn
          if (no_entries > 1)                                     <===
            list_for_each_entry(port, &adapter->port_list, list)  <===
              if (!port->d_id) zfcp_erp_port_reopen "fcrscn1"     <===
          for (i = 1; i < no_entries; i++)
            _zfcp_fc_incoming_rscn
              list_for_each_entry(port, &adapter->port_list, list)
                if (masked port->d_id match) zfcp_fc_test_link
      
      Abbreviated example trace records before this code change:
      
      Tag            : fcrscn1
      WWPN           : 0x500507630310d327
      ERP want       : 0x02
      ERP need       : 0x02
      
      Tag            : fcrscn1
      WWPN           : 0x500507630310d327
      ERP want       : 0x02
      ERP need       : 0x00                 NOP => superfluous trace record
      
      The last trace entry repeats if there are more than 2 RSCN elements.
      Signed-off-by: NSteffen Maier <maier@linux.ibm.com>
      Reviewed-by: NBenjamin Block <bblock@linux.ibm.com>
      Reviewed-by: NJens Remus <jremus@linux.ibm.com>
      Signed-off-by: NMartin K. Petersen <martin.petersen@oracle.com>
      c8206579
    • S
      scsi: zfcp: fix scsi_eh host reset with port_forced ERP for non-NPIV FCP devices · 242ec145
      Steffen Maier 提交于
      Suppose more than one non-NPIV FCP device is active on the same channel.
      Send I/O to storage and have some of the pending I/O run into a SCSI
      command timeout, e.g. due to bit errors on the fibre. Now the error
      situation stops. However, we saw FCP requests continue to timeout in the
      channel. The abort will be successful, but the subsequent TUR fails.
      Scsi_eh starts. The LUN reset fails. The target reset fails.  The host
      reset only did an FCP device recovery. However, for non-NPIV FCP devices,
      this does not close and reopen ports on the SAN-side if other non-NPIV FCP
      device(s) share the same open ports.
      
      In order to resolve the continuing FCP request timeouts, we need to
      explicitly close and reopen ports on the SAN-side.
      
      This was missing since the beginning of zfcp in v2.6.0 history commit
      ea127f975424 ("[PATCH] s390 (7/7): zfcp host adapter.").
      
      Note: The FSF requests for forced port reopen could run into FSF request
      timeouts due to other reasons. This would trigger an internal FCP device
      recovery. Pending forced port reopen recoveries would get dismissed. So
      some ports might not get fully reopened during this host reset handler.
      However, subsequent I/O would trigger the above described escalation and
      eventually all ports would be forced reopen to resolve any continuing FCP
      request timeouts due to earlier bit errors.
      Signed-off-by: NSteffen Maier <maier@linux.ibm.com>
      Fixes: 1da177e4 ("Linux-2.6.12-rc2")
      Cc: <stable@vger.kernel.org> #3.0+
      Reviewed-by: NJens Remus <jremus@linux.ibm.com>
      Reviewed-by: NBenjamin Block <bblock@linux.ibm.com>
      Signed-off-by: NMartin K. Petersen <martin.petersen@oracle.com>
      242ec145
    • S
      scsi: zfcp: fix rport unblock if deleted SCSI devices on Scsi_Host · fe67888f
      Steffen Maier 提交于
      An already deleted SCSI device can exist on the Scsi_Host and remain there
      because something still holds a reference.  A new SCSI device with the same
      H:C:T:L and FCP device, target port WWPN, and FCP LUN can be created.  When
      we try to unblock an rport, we still find the deleted SCSI device and
      return early because the zfcp_scsi_dev of that SCSI device is not
      ZFCP_STATUS_COMMON_UNBLOCKED. Hence we miss to unblock the rport, even if
      the new proper SCSI device would be in good state.
      
      Therefore, skip deleted SCSI devices when iterating the sdevs of the shost.
      [cf. __scsi_device_lookup{_by_target}() or scsi_device_get()]
      
      The following abbreviated trace sequence can indicate such problem:
      
      Area           : REC
      Tag            : ersfs_3
      LUN            : 0x4045400300000000
      WWPN           : 0x50050763031bd327
      LUN status     : 0x40000000     not ZFCP_STATUS_COMMON_UNBLOCKED
      Ready count    : n		not incremented yet
      Running count  : 0x00000000
      ERP want       : 0x01
      ERP need       : 0xc1		ZFCP_ERP_ACTION_NONE
      
      Area           : REC
      Tag            : ersfs_3
      LUN            : 0x4045400300000000
      WWPN           : 0x50050763031bd327
      LUN status     : 0x41000000
      Ready count    : n+1
      Running count  : 0x00000000
      ERP want       : 0x01
      ERP need       : 0x01
      
      ...
      
      Area           : REC
      Level          : 4		only with increased trace level
      Tag            : ertru_l
      LUN            : 0x4045400300000000
      WWPN           : 0x50050763031bd327
      LUN status     : 0x40000000
      Request ID     : 0x0000000000000000
      ERP status     : 0x01800000
      ERP step       : 0x1000
      ERP action     : 0x01
      ERP count      : 0x00
      
      NOT followed by a trace record with tag "scpaddy"
      for WWPN 0x50050763031bd327.
      Signed-off-by: NSteffen Maier <maier@linux.ibm.com>
      Fixes: 6f2ce1c6 ("scsi: zfcp: fix rport unblock race with LUN recovery")
      Cc: <stable@vger.kernel.org> #2.6.32+
      Reviewed-by: NJens Remus <jremus@linux.ibm.com>
      Reviewed-by: NBenjamin Block <bblock@linux.ibm.com>
      Signed-off-by: NMartin K. Petersen <martin.petersen@oracle.com>
      fe67888f
反馈
建议
客服 返回
顶部