1. 05 Mar, 2020 7 commits
    • Prike Liang's avatar
      drm/amd/powerplay: fix pre-check condition for setting clock range · 80381d40
      Prike Liang authored
      This fix will handle some MP1 FW issue like as mclk dpm table in renoir has a reverse
      dpm clock layout and a zero frequency dpm level as following case.
      
      cat pp_dpm_mclk
      0: 1200Mhz
      1: 1200Mhz
      2: 800Mhz
      3: 0Mhz
      Signed-off-by: default avatarPrike Liang <Prike.Liang@amd.com>
      Reviewed-by: default avatarEvan Quan <evan.quan@amd.com>
      Signed-off-by: default avatarAlex Deucher <alexander.deucher@amd.com>
      Cc: stable@vger.kernel.org
      80381d40
    • Josip Pavic's avatar
      drm/amd/display: fix dcc swath size calculations on dcn1 · a0275dfc
      Josip Pavic authored
      [Why]
      Swath sizes are being calculated incorrectly. The horizontal swath size
      should be the product of block height, viewport width, and bytes per
      element, but the calculation uses viewport height instead of width. The
      vertical swath size is similarly incorrectly calculated. The effect of
      this is that we report the wrong DCC caps.
      
      [How]
      Use viewport width in the horizontal swath size calculation and viewport
      height in the vertical swath size calculation.
      Signed-off-by: default avatarJosip Pavic <Josip.Pavic@amd.com>
      Reviewed-by: default avatarAric Cyr <Aric.Cyr@amd.com>
      Acked-by: default avatarRodrigo Siqueira <Rodrigo.Siqueira@amd.com>
      Signed-off-by: default avatarAlex Deucher <alexander.deucher@amd.com>
      a0275dfc
    • Bhawanpreet Lakha's avatar
      drm/amd/display: Clear link settings on MST disable connector · 5ac7fd2f
      Bhawanpreet Lakha authored
      [Why]
      If we have a single MST display and we disconnect it, we dont disable that
      link. This causes the old link settings to still exist
      
      Now on a replug for MST we think its a link loss and will try to reallocate
      mst payload which will fail, throwing warning below.
      
      [  129.374192] [drm] Failed to updateMST allocation table forpipe idx:0
      [  129.374206] ------------[ cut here ]------------
      [  129.374284] WARNING: CPU: 14 PID: 1710 at
      drivers/gpu/drm/amd/amdgpu/../dal-dev/dc/core/dc_link.c:3153
      dc_link_allocate_mst_payload+0x1f7/0x220 [amdgpu]
      
      [  129.374285] Modules linked in: amdgpu(OE) amd_iommu_v2 gpu_sched ttm
      drm_kms_helper drm fb_sys_fops syscopyarea sysfillrect sysimgblt
      binfmt_misc nls_iso8859_1 edac_mce_amd snd_hda_codec_realtek
      snd_hda_codec_generic ledtrig_audio kvm snd_hda_codec_hdmi snd_hda_intel
      snd_intel_nhlt snd_hda_codec irqbypass snd_hda_core snd_hwdep snd_pcm
      snd_seq_midi snd_seq_midi_event snd_rawmidi crct10dif_pclmul snd_seq
      crc32_pclmul ghash_clmulni_intel snd_seq_device snd_timer snd aesni_intel
      eeepc_wmi crypto_simd asus_wmi joydev cryptd sparse_keymap input_leds
      soundcore video glue_helper wmi_bmof mxm_wmi k10temp ccp mac_hid
      sch_fq_codel parport_pc ppdev lp parport ip_tables x_tables autofs4
      hid_generic usbhid hid igb i2c_algo_bit ahci dca i2c_piix4 libahci
      gpio_amdpt wmi gpio_generic
      
      [  129.374318] CPU: 14 PID: 1710 Comm: kworker/14:2 Tainted: G        W  OE     5.4.0-rc7bhawan+ #480
      [  129.374318] Hardware name: System manufacturer System Product Name/PRIME X370-PRO, BIOS 0515 03/30/2017
      [  129.374397] Workqueue: events dm_irq_work_func [amdgpu]
      [  129.374468] RIP: 0010:dc_link_allocate_mst_payload+0x1f7/0x220 [amdgpu]
      [  129.374470] Code: 52 20 e8 1c 63 ad f4 48 8b 5d d0 65 48 33 1c 25 28 00
      00 00 b8 01 00 00 00 75 16 48 8d 65 d8 5b 41 5c 41 5d 41 5e 41 5f 5d c3
      <0f> 0b e9 fa fe ff ff e8 ed 5b d6 f3 41 0f b6 b6 c4 02 00 00 48 c7
      [  129.374471] RSP: 0018:ffff9f9141e7fcc0 EFLAGS: 00010246
      [  129.374472] RAX: 0000000000000000 RBX: ffff91ef0762f800 RCX: 0000000000000000
      [  129.374473] RDX: 0000000000000005 RSI: ffffffffc0c4a988 RDI: 0000000000000004
      [  129.374474] RBP: ffff9f9141e7fd10 R08: 0000000000000005 R09: 0000000000000000
      [  129.374475] R10: 0000000000000002 R11: 0000000000000001 R12: ffff91eebd510c00
      [  129.374475] R13: ffff91eebd510e58 R14: ffff91ef052c01b8 R15: 0000000000000006
      [  129.374476] FS:  0000000000000000(0000) GS:ffff91ef0ef80000(0000) knlGS:0000000000000000
      [  129.374477] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
      [  129.374478] CR2: 000055623ea01d50 CR3: 0000000408a8c000 CR4: 00000000003406e0
      [  129.374479] Call Trace:
      [  129.374550]  dc_link_reallocate_mst_payload+0x12e/0x150 [amdgpu]
      [  129.374617]  dc_link_handle_hpd_rx_irq+0x6d4/0x6e0 [amdgpu]
      [  129.374693]  handle_hpd_rx_irq+0x77/0x310 [amdgpu]
      [  129.374768]  dm_irq_work_func+0x53/0x70 [amdgpu]
      [  129.374774]  process_one_work+0x1fd/0x3f0
      [  129.374776]  worker_thread+0x255/0x410
      [  129.374778]  kthread+0x121/0x140
      [  129.374780]  ? process_one_work+0x3f0/0x3f0
      [  129.374781]  ? kthread_park+0x90/0x90
      [  129.374785]  ret_from_fork+0x22/0x40
      
      [How]
      when we disable MST we should clear the cur link settings (lane_count=0 is
      good enough). This will cause us to not reallocate payloads earlier than
      expected and not throw the warning
      Signed-off-by: default avatarBhawanpreet Lakha <Bhawanpreet.Lakha@amd.com>
      Reviewed-by: default avatarHersen Wu <hersenxs.wu@amd.com>
      Acked-by: default avatarRodrigo Siqueira <Rodrigo.Siqueira@amd.com>
      Signed-off-by: default avatarAlex Deucher <alexander.deucher@amd.com>
      5ac7fd2f
    • Tianci.Yin's avatar
      drm/amdgpu: disable 3D pipe 1 on Navi1x · 194bcf35
      Tianci.Yin authored
      [why]
      CP firmware decide to skip setting the state for 3D pipe 1 for Navi1x as there
      is no use case.
      
      [how]
      Disable 3D pipe 1 on Navi1x.
      Reviewed-by: default avatarFeifei Xu <Feifei.Xu@amd.com>
      Reviewed-by: default avatarMonk Liu <monk.liu@amd.com>
      Signed-off-by: default avatarTianci.Yin <tianci.yin@amd.com>
      Signed-off-by: default avatarAlex Deucher <alexander.deucher@amd.com>
      Cc: stable@vger.kernel.org
      194bcf35
    • Yintian Tao's avatar
      drm/amdgpu: clean wptr on wb when gpu recovery · 2ab7e274
      Yintian Tao authored
      The TDR will be randomly failed due to compute ring
      test failure. If the compute ring wptr & 0x7ff(ring_buf_mask)
      is 0x100 then after map mqd the compute ring rptr will be
      synced with 0x100. And the ring test packet size is also 0x100.
      Then after invocation of amdgpu_ring_commit, the cp will not
      really handle the packet on the ring buffer because rptr is equal to wptr.
      Signed-off-by: default avatarYintian Tao <yttao@amd.com>
      Acked-by: default avatarChristian König <christian.koenig@amd.com>
      Reviewed-by: default avatarMonk Liu <Monk.Liu@amd.com>
      Signed-off-by: default avatarAlex Deucher <alexander.deucher@amd.com>
      2ab7e274
    • Dave Airlie's avatar
      Merge tag 'mediatek-drm-fixes-5.6' of... · 70b8ea1a
      Dave Airlie authored
      Merge tag 'mediatek-drm-fixes-5.6' of https://github.com/ckhu-mediatek/linux.git-tags into drm-fixes
      
      Mediatek DRM Fixes for Linux 5.6
      Signed-off-by: default avatarDave Airlie <airlied@redhat.com>
      
      From: CK Hu <ck.hu@mediatek.com>
      Link: https://patchwork.freedesktop.org/patch/msgid/1583373069.364.4.camel@mtksdaap41
      70b8ea1a
    • Dave Airlie's avatar
      Merge tag 'exynos-drm-fixes-for-v5.6-rc5' of... · 755d7a92
      Dave Airlie authored
      Merge tag 'exynos-drm-fixes-for-v5.6-rc5' of git://git.kernel.org/pub/scm/linux/kernel/git/daeinki/drm-exynos into drm-fixes
      
      Three fixups
      - fix a kernel oops problem in case that driver is loaded as module.
      - fix a regulator warning issue when I2C DDC adapter cannot be gathered.
      - print out an error message only in error case excepting -EPROBE_DEFER.
      Signed-off-by: default avatarDave Airlie <airlied@redhat.com>
      
      From: Inki Dae <inki.dae@samsung.com>
      Link: https://patchwork.freedesktop.org/patch/msgid/1583126752-30477-1-git-send-email-inki.dae@samsung.com
      755d7a92
  2. 02 Mar, 2020 3 commits
    • Marek Szyprowski's avatar
      drm/exynos: hdmi: don't leak enable HDMI_EN regulator if probe fails · 3b6a9b19
      Marek Szyprowski authored
      Move enabling and disabling HDMI_EN optional regulator to probe() function
      to keep track on the regulator status. This fixes following warning if
      probe() fails (for example when I2C DDC adapter cannot be yet gathered
      due to the missing driver). This fixes following warning observed on
      Arndale5250 board with multi_v7_defconfig:
      
      [drm] Failed to get ddc i2c adapter by node
      ------------[ cut here ]------------
      WARNING: CPU: 0 PID: 214 at drivers/regulator/core.c:2051 _regulator_put+0x16c/0x184
      Modules linked in: ...
      CPU: 0 PID: 214 Comm: systemd-udevd Not tainted 5.6.0-rc2-next-20200219-00040-g38af1dfafdbb #7570
      Hardware name: Samsung Exynos (Flattened Device Tree)
      [<c0312258>] (unwind_backtrace) from [<c030cc10>] (show_stack+0x10/0x14)
      [<c030cc10>] (show_stack) from [<c0f0d3a0>] (dump_stack+0xcc/0xe0)
      [<c0f0d3a0>] (dump_stack) from [<c0346a58>] (__warn+0xe0/0xf8)
      [<c0346a58>] (__warn) from [<c0346b20>] (warn_slowpath_fmt+0xb0/0xb8)
      [<c0346b20>] (warn_slowpath_fmt) from [<c0893f58>] (_regulator_put+0x16c/0x184)
      [<c0893f58>] (_regulator_put) from [<c0893f8c>] (regulator_put+0x1c/0x2c)
      [<c0893f8c>] (regulator_put) from [<c09b2664>] (release_nodes+0x17c/0x200)
      [<c09b2664>] (release_nodes) from [<c09aebe8>] (really_probe+0x10c/0x350)
      [<c09aebe8>] (really_probe) from [<c09aefa8>] (driver_probe_device+0x60/0x1a0)
      [<c09aefa8>] (driver_probe_device) from [<c09af288>] (device_driver_attach+0x58/0x60)
      [<c09af288>] (device_driver_attach) from [<c09af310>] (__driver_attach+0x80/0xbc)
      [<c09af310>] (__driver_attach) from [<c09ace34>] (bus_for_each_dev+0x68/0xb4)
      [<c09ace34>] (bus_for_each_dev) from [<c09ae00c>] (bus_add_driver+0x130/0x1e8)
      [<c09ae00c>] (bus_add_driver) from [<c09afd98>] (driver_register+0x78/0x110)
      [<c09afd98>] (driver_register) from [<bf139558>] (exynos_drm_init+0xe8/0x11c [exynosdrm])
      [<bf139558>] (exynos_drm_init [exynosdrm]) from [<c0302fa8>] (do_one_initcall+0x50/0x220)
      [<c0302fa8>] (do_one_initcall) from [<c03dc02c>] (do_init_module+0x60/0x210)
      [<c03dc02c>] (do_init_module) from [<c03daf44>] (load_module+0x1c0c/0x2310)
      [<c03daf44>] (load_module) from [<c03db85c>] (sys_finit_module+0xac/0xbc)
      [<c03db85c>] (sys_finit_module) from [<c0301000>] (ret_fast_syscall+0x0/0x54)
      Exception stack(0xecca3fa8 to 0xecca3ff0)
      ...
      ---[ end trace 276c91214635905c ]---
      Signed-off-by: default avatarMarek Szyprowski <m.szyprowski@samsung.com>
      Reviewed-by: default avatarAndrzej Hajda <a.hajda@samsung.com>
      Signed-off-by: default avatarInki Dae <inki.dae@samsung.com>
      3b6a9b19
    • Marek Szyprowski's avatar
      drm/exynos: dsi: fix workaround for the legacy clock name · c0fd99d6
      Marek Szyprowski authored
      Writing to the built-in strings arrays doesn't work if driver is loaded
      as kernel module. This is also considered as a bad pattern. Fix this by
      adding a call to clk_get() with legacy clock name. This fixes following
      kernel oops if driver is loaded as module:
      
      Unable to handle kernel paging request at virtual address bf047978
       pgd = (ptrval)
       [bf047978] *pgd=59344811, *pte=5903c6df, *ppte=5903c65f
       Internal error: Oops: 80f [#1] SMP ARM
       Modules linked in: mc exynosdrm(+) analogix_dp rtc_s3c exynos_ppmu i2c_gpio
       CPU: 1 PID: 212 Comm: systemd-udevd Not tainted 5.6.0-rc2-next-20200219 #326
       videodev: Linux video capture interface: v2.00
       Hardware name: Samsung Exynos (Flattened Device Tree)
       PC is at exynos_dsi_probe+0x1f0/0x384 [exynosdrm]
       LR is at exynos_dsi_probe+0x1dc/0x384 [exynosdrm]
       ...
       Process systemd-udevd (pid: 212, stack limit = 0x(ptrval))
       ...
       [<bf03cf14>] (exynos_dsi_probe [exynosdrm]) from [<c09b1ca0>] (platform_drv_probe+0x6c/0xa4)
       [<c09b1ca0>] (platform_drv_probe) from [<c09afcb8>] (really_probe+0x210/0x350)
       [<c09afcb8>] (really_probe) from [<c09aff74>] (driver_probe_device+0x60/0x1a0)
       [<c09aff74>] (driver_probe_device) from [<c09b0254>] (device_driver_attach+0x58/0x60)
       [<c09b0254>] (device_driver_attach) from [<c09b02dc>] (__driver_attach+0x80/0xbc)
       [<c09b02dc>] (__driver_attach) from [<c09ade00>] (bus_for_each_dev+0x68/0xb4)
       [<c09ade00>] (bus_for_each_dev) from [<c09aefd8>] (bus_add_driver+0x130/0x1e8)
       [<c09aefd8>] (bus_add_driver) from [<c09b0d64>] (driver_register+0x78/0x110)
       [<c09b0d64>] (driver_register) from [<bf038558>] (exynos_drm_init+0xe8/0x11c [exynosdrm])
       [<bf038558>] (exynos_drm_init [exynosdrm]) from [<c0302fa8>] (do_one_initcall+0x50/0x220)
       [<c0302fa8>] (do_one_initcall) from [<c03dd02c>] (do_init_module+0x60/0x210)
       [<c03dd02c>] (do_init_module) from [<c03dbf44>] (load_module+0x1c0c/0x2310)
       [<c03dbf44>] (load_module) from [<c03dc85c>] (sys_finit_module+0xac/0xbc)
       [<c03dc85c>] (sys_finit_module) from [<c0301000>] (ret_fast_syscall+0x0/0x54)
       Exception stack(0xd979bfa8 to 0xd979bff0)
       ...
       ---[ end trace db16efe05faab470 ]---
      Signed-off-by: default avatarMarek Szyprowski <m.szyprowski@samsung.com>
      Reviewed-by: default avatarAndrzej Hajda <a.hajda@samsung.com>
      Signed-off-by: default avatarInki Dae <inki.dae@samsung.com>
      c0fd99d6
    • Marek Szyprowski's avatar
      drm/exynos: dsi: propagate error value and silence meaningless warning · 0a9d1e3f
      Marek Szyprowski authored
      Properly propagate error value from devm_regulator_bulk_get() and don't
      confuse user with meaningless warning about failure in getting regulators
      in case of deferred probe.
      Signed-off-by: default avatarMarek Szyprowski <m.szyprowski@samsung.com>
      Reviewed-by: default avatarKrzysztof Kozlowski <krzk@kernel.org>
      Signed-off-by: default avatarInki Dae <inki.dae@samsung.com>
      0a9d1e3f
  3. 01 Mar, 2020 5 commits
  4. 29 Feb, 2020 4 commits
    • Dan Carpenter's avatar
      ext4: potential crash on allocation error in ext4_alloc_flex_bg_array() · 37b0b6b8
      Dan Carpenter authored
      If sbi->s_flex_groups_allocated is zero and the first allocation fails
      then this code will crash.  The problem is that "i--" will set "i" to
      -1 but when we compare "i >= sbi->s_flex_groups_allocated" then the -1
      is type promoted to unsigned and becomes UINT_MAX.  Since UINT_MAX
      is more than zero, the condition is true so we call kvfree(new_groups[-1]).
      The loop will carry on freeing invalid memory until it crashes.
      
      Fixes: 7c990728 ("ext4: fix potential race between s_flex_groups online resizing and access")
      Reviewed-by: default avatarSuraj Jitindar Singh <surajjs@amazon.com>
      Signed-off-by: default avatarDan Carpenter <dan.carpenter@oracle.com>
      Cc: stable@kernel.org
      Link: https://lore.kernel.org/r/20200228092142.7irbc44yaz3by7nb@kili.mountainSigned-off-by: default avatarTheodore Ts'o <tytso@mit.edu>
      37b0b6b8
    • Wolfram Sang's avatar
      macintosh: therm_windtunnel: fix regression when instantiating devices · 38b17afb
      Wolfram Sang authored
      Removing attach_adapter from this driver caused a regression for at
      least some machines. Those machines had the sensors described in their
      DT, too, so they didn't need manual creation of the sensor devices. The
      old code worked, though, because manual creation came first. Creation of
      DT devices then failed later and caused error logs, but the sensors
      worked nonetheless because of the manually created devices.
      
      When removing attach_adaper, manual creation now comes later and loses
      the race. The sensor devices were already registered via DT, yet with
      another binding, so the driver could not be bound to it.
      
      This fix refactors the code to remove the race and only manually creates
      devices if there are no DT nodes present. Also, the DT binding is updated
      to match both, the DT and manually created devices. Because we don't
      know which device creation will be used at runtime, the code to start
      the kthread is moved to do_probe() which will be called by both methods.
      
      Fixes: 3e7bed52 ("macintosh: therm_windtunnel: drop using attach_adapter")
      Link: https://bugzilla.kernel.org/show_bug.cgi?id=201723Reported-by: default avatarErhard Furtner <erhard_f@mailbox.org>
      Tested-by: default avatarErhard Furtner <erhard_f@mailbox.org>
      Acked-by: Michael Ellerman <mpe@ellerman.id.au> (powerpc)
      Signed-off-by: default avatarWolfram Sang <wsa@the-dreams.de>
      Cc: stable@kernel.org # v4.19+
      38b17afb
    • Qian Cai's avatar
      jbd2: fix data races at struct journal_head · 6c5d9112
      Qian Cai authored
      journal_head::b_transaction and journal_head::b_next_transaction could
      be accessed concurrently as noticed by KCSAN,
      
       LTP: starting fsync04
       /dev/zero: Can't open blockdev
       EXT4-fs (loop0): mounting ext3 file system using the ext4 subsystem
       EXT4-fs (loop0): mounted filesystem with ordered data mode. Opts: (null)
       ==================================================================
       BUG: KCSAN: data-race in __jbd2_journal_refile_buffer [jbd2] / jbd2_write_access_granted [jbd2]
      
       write to 0xffff99f9b1bd0e30 of 8 bytes by task 25721 on cpu 70:
        __jbd2_journal_refile_buffer+0xdd/0x210 [jbd2]
        __jbd2_journal_refile_buffer at fs/jbd2/transaction.c:2569
        jbd2_journal_commit_transaction+0x2d15/0x3f20 [jbd2]
        (inlined by) jbd2_journal_commit_transaction at fs/jbd2/commit.c:1034
        kjournald2+0x13b/0x450 [jbd2]
        kthread+0x1cd/0x1f0
        ret_from_fork+0x27/0x50
      
       read to 0xffff99f9b1bd0e30 of 8 bytes by task 25724 on cpu 68:
        jbd2_write_access_granted+0x1b2/0x250 [jbd2]
        jbd2_write_access_granted at fs/jbd2/transaction.c:1155
        jbd2_journal_get_write_access+0x2c/0x60 [jbd2]
        __ext4_journal_get_write_access+0x50/0x90 [ext4]
        ext4_mb_mark_diskspace_used+0x158/0x620 [ext4]
        ext4_mb_new_blocks+0x54f/0xca0 [ext4]
        ext4_ind_map_blocks+0xc79/0x1b40 [ext4]
        ext4_map_blocks+0x3b4/0x950 [ext4]
        _ext4_get_block+0xfc/0x270 [ext4]
        ext4_get_block+0x3b/0x50 [ext4]
        __block_write_begin_int+0x22e/0xae0
        __block_write_begin+0x39/0x50
        ext4_write_begin+0x388/0xb50 [ext4]
        generic_perform_write+0x15d/0x290
        ext4_buffered_write_iter+0x11f/0x210 [ext4]
        ext4_file_write_iter+0xce/0x9e0 [ext4]
        new_sync_write+0x29c/0x3b0
        __vfs_write+0x92/0xa0
        vfs_write+0x103/0x260
        ksys_write+0x9d/0x130
        __x64_sys_write+0x4c/0x60
        do_syscall_64+0x91/0xb05
        entry_SYSCALL_64_after_hwframe+0x49/0xbe
      
       5 locks held by fsync04/25724:
        #0: ffff99f9911093f8 (sb_writers#13){.+.+}, at: vfs_write+0x21c/0x260
        #1: ffff99f9db4c0348 (&sb->s_type->i_mutex_key#15){+.+.}, at: ext4_buffered_write_iter+0x65/0x210 [ext4]
        #2: ffff99f5e7dfcf58 (jbd2_handle){++++}, at: start_this_handle+0x1c1/0x9d0 [jbd2]
        #3: ffff99f9db4c0168 (&ei->i_data_sem){++++}, at: ext4_map_blocks+0x176/0x950 [ext4]
        #4: ffffffff99086b40 (rcu_read_lock){....}, at: jbd2_write_access_granted+0x4e/0x250 [jbd2]
       irq event stamp: 1407125
       hardirqs last  enabled at (1407125): [<ffffffff980da9b7>] __find_get_block+0x107/0x790
       hardirqs last disabled at (1407124): [<ffffffff980da8f9>] __find_get_block+0x49/0x790
       softirqs last  enabled at (1405528): [<ffffffff98a0034c>] __do_softirq+0x34c/0x57c
       softirqs last disabled at (1405521): [<ffffffff97cc67a2>] irq_exit+0xa2/0xc0
      
       Reported by Kernel Concurrency Sanitizer on:
       CPU: 68 PID: 25724 Comm: fsync04 Tainted: G L 5.6.0-rc2-next-20200221+ #7
       Hardware name: HPE ProLiant DL385 Gen10/ProLiant DL385 Gen10, BIOS A40 07/10/2019
      
      The plain reads are outside of jh->b_state_lock critical section which result
      in data races. Fix them by adding pairs of READ|WRITE_ONCE().
      Reviewed-by: default avatarJan Kara <jack@suse.cz>
      Signed-off-by: default avatarQian Cai <cai@lca.pw>
      Link: https://lore.kernel.org/r/20200222043111.2227-1-cai@lca.pwSigned-off-by: default avatarTheodore Ts'o <tytso@mit.edu>
      6c5d9112
    • Linus Torvalds's avatar
      Merge tag 'scsi-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/jejb/scsi · 7557c1b3
      Linus Torvalds authored
      Pull SCSI fixes from James Bottomley:
       "Four small fixes.
      
        Three are in drivers for fairly obvious bugs. The fourth is a set of
        regressions introduced by the compat_ioctl changes because some of the
        compat updates wrongly replaced .ioctl instead of .compat_ioctl"
      
      * tag 'scsi-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/jejb/scsi:
        scsi: compat_ioctl: cdrom: Replace .ioctl with .compat_ioctl in four appropriate places
        scsi: zfcp: fix wrong data and display format of SFP+ temperature
        scsi: sd_sbc: Fix sd_zbc_report_zones()
        scsi: libfc: free response frame from GPN_ID
      7557c1b3
  5. 28 Feb, 2020 21 commits