1. 22 Sep, 2019 8 commits
  2. 18 Sep, 2019 3 commits
  3. 05 Sep, 2019 2 commits
    • Alan Stern's avatar
      HID: prodikeys: Fix general protection fault during probe · 98375b86
      Alan Stern authored
      The syzbot fuzzer provoked a general protection fault in the
      hid-prodikeys driver:
      
      kasan: CONFIG_KASAN_INLINE enabled
      kasan: GPF could be caused by NULL-ptr deref or user memory access
      general protection fault: 0000 [#1] SMP KASAN
      CPU: 0 PID: 12 Comm: kworker/0:1 Not tainted 5.3.0-rc5+ #28
      Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS
      Google 01/01/2011
      Workqueue: usb_hub_wq hub_event
      RIP: 0010:pcmidi_submit_output_report drivers/hid/hid-prodikeys.c:300  [inline]
      RIP: 0010:pcmidi_set_operational drivers/hid/hid-prodikeys.c:558 [inline]
      RIP: 0010:pcmidi_snd_initialise drivers/hid/hid-prodikeys.c:686 [inline]
      RIP: 0010:pk_probe+0xb51/0xfd0 drivers/hid/hid-prodikeys.c:836
      Code: 0f 85 50 04 00 00 48 8b 04 24 4c 89 7d 10 48 8b 58 08 e8 b2 53 e4 fc
      48 8b 54 24 20 48 b8 00 00 00 00 00 fc ff df 48 c1 ea 03 <80> 3c 02 00 0f
      85 13 04 00 00 48 ba 00 00 00 00 00 fc ff df 49 8b
      
      The problem is caused by the fact that pcmidi_get_output_report() will
      return an error if the HID device doesn't provide the right sort of
      output report, but pcmidi_set_operational() doesn't bother to check
      the return code and assumes the function call always succeeds.
      
      This patch adds the missing check and aborts the probe operation if
      necessary.
      
      Reported-and-tested-by: syzbot+1088533649dafa1c9004@syzkaller.appspotmail.com
      Signed-off-by: default avatarAlan Stern <stern@rowland.harvard.edu>
      CC: <stable@vger.kernel.org>
      Signed-off-by: default avatarJiri Kosina <jkosina@suse.cz>
      98375b86
    • Roderick Colenbrander's avatar
      HID: sony: Fix memory corruption issue on cleanup. · 2bcdacb7
      Roderick Colenbrander authored
      The sony driver is not properly cleaning up from potential failures in
      sony_input_configured. Currently it calls hid_hw_stop, while hid_connect
      is still running. This is not a good idea, instead hid_hw_stop should
      be moved to sony_probe. Similar changes were recently made to Logitech
      drivers, which were also doing improper cleanup.
      Signed-off-by: default avatarRoderick Colenbrander <roderick.colenbrander@sony.com>
      CC: stable@vger.kernel.org
      Signed-off-by: default avatarJiri Kosina <jkosina@suse.cz>
      2bcdacb7
  4. 04 Sep, 2019 2 commits
  5. 03 Sep, 2019 1 commit
  6. 26 Aug, 2019 1 commit
    • Hans de Goede's avatar
      HID: logitech-dj: Fix crash when initial logi_dj_recv_query_paired_devices fails · 8ccff284
      Hans de Goede authored
      Before this commit dj_probe would exit with an error if the initial
      logi_dj_recv_query_paired_devices fails. The initial call may fail
      when the receiver is connected through a kvm and the focus is away.
      
      When the call fails this causes 2 problems:
      
      1) dj_probe calls logi_dj_recv_query_paired_devices after calling
      hid_device_io_start() so a HID report may have been received in between
      and our delayedwork_callback may be running. It seems that the initial
      logi_dj_recv_query_paired_devices failure happening with some KVMs triggers
      this exact scenario, causing the work-queue to run on free-ed memory,
      leading to:
      
       BUG: unable to handle page fault for address: 0000000000001e88
       #PF: supervisor read access in kernel mode
       #PF: error_code(0x0000) - not-present page
       PGD 0 P4D 0
       Oops: 0000 [#1] SMP PTI
       CPU: 3 PID: 257 Comm: kworker/3:3 Tainted: G           OE     5.3.0-rc5+ #100
       Hardware name: To Be Filled By O.E.M. To Be Filled By O.E.M./B150M Pro4S/D3, BIOS P7.10 12/06/2016
       Workqueue: events 0xffffffffc02ba200
       RIP: 0010:0xffffffffc02ba1bd
       Code: e8 e8 13 00 d8 48 89 c5 48 85 c0 74 4c 48 8b 7b 10 48 89 ea b9 07 00 00 00 41 b9 09 00 00 00 41 b8 01 00 00 00 be 10 00 00 00 <48> 8b 87 88 1e 00 00 48 8b 40 40 e8 b3 6b b4 d8 48 89 ef 41 89 c4
       RSP: 0018:ffffb760c046bdb8 EFLAGS: 00010286
       RAX: ffff935038ea4550 RBX: ffff935046778000 RCX: 0000000000000007
       RDX: ffff935038ea4550 RSI: 0000000000000010 RDI: 0000000000000000
       RBP: ffff935038ea4550 R08: 0000000000000001 R09: 0000000000000009
       R10: 000000000000e011 R11: 0000000000000001 R12: ffff9350467780e8
       R13: ffff935046778000 R14: 0000000000000000 R15: ffff935046778070
       FS:  0000000000000000(0000) GS:ffff935054e00000(0000) knlGS:0000000000000000
       CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
       CR2: 0000000000001e88 CR3: 000000075a612002 CR4: 00000000003606e0
       DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
       DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
       Call Trace:
        0xffffffffc02ba2f7
        ? process_one_work+0x1b1/0x560
        process_one_work+0x234/0x560
        worker_thread+0x50/0x3b0
        kthread+0x10a/0x140
        ? process_one_work+0x560/0x560
        ? kthread_park+0x80/0x80
        ret_from_fork+0x3a/0x50
       Modules linked in: vboxpci(O) vboxnetadp(O) vboxnetflt(O) vboxdrv(O) bnep vfat fat btusb btrtl btbcm btintel bluetooth intel_rapl_msr ecdh_generic rfkill ecc snd_usb_audio snd_usbmidi_lib intel_rapl_common snd_rawmidi mc x86_pkg_temp_thermal intel_powerclamp coretemp iTCO_wdt iTCO_vendor_support mei_wdt mei_hdcp ppdev kvm_intel kvm irqbypass crct10dif_pclmul crc32_generic crc32_pclmul snd_hda_codec_hdmi snd_hda_codec_realtek snd_hda_codec_generic ledtrig_audio ghash_clmulni_intel intel_cstate snd_hda_intel snd_hda_codec intel_uncore snd_hda_core snd_hwdep intel_rapl_perf snd_seq snd_seq_device snd_pcm snd_timer intel_wmi_thunderbolt snd e1000e soundcore mxm_wmi i2c_i801 bfq mei_me mei intel_pch_thermal parport_pc parport acpi_pad binfmt_misc hid_lg_g15(E) hid_logitech_dj(E) i915 crc32c_intel i2c_algo_bit drm_kms_helper nvme nvme_core drm wmi video uas usb_storage i2c_dev
       CR2: 0000000000001e88
       ---[ end trace 1d3f8afdcfcbd842 ]---
      
      2) Even if we were to fix 1. by making sure the work is stopped before
      failing probe, failing probe is the wrong thing to do, we have
      logi_dj_recv_queue_unknown_work to deal with the initial
      logi_dj_recv_query_paired_devices failure.
      
      Rather then error-ing out of the probe, causing the receiver to not work at
      all we should rely on this, so that the attached devices will get properly
      enumerated once the KVM focus is switched back.
      
      Cc: stable@vger.kernel.org
      Fixes: 74808f91 ("HID: logitech-dj: add support for non unifying receivers")
      Signed-off-by: default avatarHans de Goede <hdegoede@redhat.com>
      Signed-off-by: default avatarBenjamin Tissoires <benjamin.tissoires@redhat.com>
      8ccff284
  7. 23 Aug, 2019 3 commits
  8. 22 Aug, 2019 5 commits
    • Benjamin Tissoires's avatar
      HID: multitouch: add support for the Smart Tech panel · 69ecd44d
      Benjamin Tissoires authored
      This panel is not very friendly to us:
      it exposes multiple multitouch collections, some of them being of
      logical application stylus.
      
      Usually, a device has only one report per application, and that is
      what I assumed in commit 8dfe14b3 ("HID: multitouch: ditch mt_report_id")
      
      To avoid breaking all working device, add a new class and a new quirk
      for that situation.
      Reported-and-tested-by: default avatarMatthias Fend <Matthias.Fend@wolfvision.net>
      Signed-off-by: default avatarBenjamin Tissoires <benjamin.tissoires@redhat.com>
      69ecd44d
    • Benjamin Tissoires's avatar
      HID: multitouch: do not filter mice nodes · c23e2043
      Benjamin Tissoires authored
      It was a good idea at the time to not create a mouse node for the
      multitouch touchscreens, but:
      - touchscreens following the Win 8 protocol should not have this
        disturbing mouse node anymore, or if they have, it should be
        used for something else (like a joystick attached to the screen)
      - touchpads have it, and they should not use it unless there is a bug,
        but when the laptop has a trackstick, the data are reported through this
        mouse node.
      
      So instead of whitelisting all of the devices that have a need for the
      mouse node, just export it.
      hid-input.c will append a suffix to it ('Mouse'), so users will eventually
      see if something goes wrong.
      Signed-off-by: default avatarBenjamin Tissoires <benjamin.tissoires@redhat.com>
      c23e2043
    • Benjamin Tissoires's avatar
      HID: do not call hid_set_drvdata(hdev, NULL) in drivers · 87fcb6a6
      Benjamin Tissoires authored
      This is a common pattern in the HID drivers to reset the drvdata. Some
      do it properly, some do it only in case of failure.
      
      But, this is actually already handled by driver core, so there is no need
      to do it manually.
      
      [for hid-sensor-hub.c]
      Acked-by: default avatarSrinivas Pandruvada <srinivas.pandruvada@linux.intel.com>
      [For hid-picolcd_core.c]
      Acked-by: default avatarBruno Prémont <bonbons@linux-vserver.org>
      Signed-off-by: default avatarBenjamin Tissoires <benjamin.tissoires@redhat.com>
      87fcb6a6
    • Alan Stern's avatar
      HID: logitech: Fix general protection fault caused by Logitech driver · 5f924277
      Alan Stern authored
      The syzbot fuzzer found a general protection fault in the HID subsystem:
      
      kasan: CONFIG_KASAN_INLINE enabled
      kasan: GPF could be caused by NULL-ptr deref or user memory access
      general protection fault: 0000 [#1] SMP KASAN
      CPU: 0 PID: 3715 Comm: syz-executor.3 Not tainted 5.2.0-rc6+ #15
      Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS
      Google 01/01/2011
      RIP: 0010:__pm_runtime_resume+0x49/0x180 drivers/base/power/runtime.c:1069
      Code: ed 74 d5 fe 45 85 ed 0f 85 9a 00 00 00 e8 6f 73 d5 fe 48 8d bd c1 02
      00 00 48 b8 00 00 00 00 00 fc ff df 48 89 fa 48 c1 ea 03 <0f> b6 04 02 48
      89 fa 83 e2 07 38 d0 7f 08 84 c0 0f 85 fe 00 00 00
      RSP: 0018:ffff8881d99d78e0 EFLAGS: 00010202
      RAX: dffffc0000000000 RBX: 0000000000000020 RCX: ffffc90003f3f000
      RDX: 0000000416d8686d RSI: ffffffff82676841 RDI: 00000020b6c3436a
      RBP: 00000020b6c340a9 R08: ffff8881c6d64800 R09: fffffbfff0e84c25
      R10: ffff8881d99d7940 R11: ffffffff87426127 R12: 0000000000000004
      R13: 0000000000000000 R14: ffff8881d9b94000 R15: ffffffff897f9048
      FS:  00007f047f542700(0000) GS:ffff8881db200000(0000) knlGS:0000000000000000
      CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
      CR2: 0000001b30f21000 CR3: 00000001ca032000 CR4: 00000000001406f0
      DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
      DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
      Call Trace:
        pm_runtime_get_sync include/linux/pm_runtime.h:226 [inline]
        usb_autopm_get_interface+0x1b/0x50 drivers/usb/core/driver.c:1707
        usbhid_power+0x7c/0xe0 drivers/hid/usbhid/hid-core.c:1234
        hid_hw_power include/linux/hid.h:1038 [inline]
        hidraw_open+0x20d/0x740 drivers/hid/hidraw.c:282
        chrdev_open+0x219/0x5c0 fs/char_dev.c:413
        do_dentry_open+0x497/0x1040 fs/open.c:778
        do_last fs/namei.c:3416 [inline]
        path_openat+0x1430/0x3ff0 fs/namei.c:3533
        do_filp_open+0x1a1/0x280 fs/namei.c:3563
        do_sys_open+0x3c0/0x580 fs/open.c:1070
        do_syscall_64+0xb7/0x560 arch/x86/entry/common.c:301
        entry_SYSCALL_64_after_hwframe+0x49/0xbe
      
      It turns out the fault was caused by a bug in the HID Logitech driver,
      which violates the requirement that every pathway calling
      hid_hw_start() must also call hid_hw_stop().  This patch fixes the bug
      by making sure the requirement is met.
      
      Reported-and-tested-by: syzbot+3cbe5cd105d2ad56a1df@syzkaller.appspotmail.com
      Signed-off-by: default avatarAlan Stern <stern@rowland.harvard.edu>
      CC: <stable@vger.kernel.org>
      Signed-off-by: default avatarJiri Kosina <jkosina@suse.cz>
      5f924277
    • Alan Stern's avatar
      HID: hidraw: Fix invalid read in hidraw_ioctl · 416dacb8
      Alan Stern authored
      The syzbot fuzzer has reported a pair of problems in the
      hidraw_ioctl() function: slab-out-of-bounds read and use-after-free
      read.  An example of the first:
      
      BUG: KASAN: slab-out-of-bounds in strlen+0x79/0x90 lib/string.c:525
      Read of size 1 at addr ffff8881c8035f38 by task syz-executor.4/2833
      
      CPU: 1 PID: 2833 Comm: syz-executor.4 Not tainted 5.3.0-rc2+ #1
      Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS
      Google 01/01/2011
      Call Trace:
        __dump_stack lib/dump_stack.c:77 [inline]
        dump_stack+0xca/0x13e lib/dump_stack.c:113
        print_address_description+0x6a/0x32c mm/kasan/report.c:351
        __kasan_report.cold+0x1a/0x33 mm/kasan/report.c:482
        kasan_report+0xe/0x12 mm/kasan/common.c:612
        strlen+0x79/0x90 lib/string.c:525
        strlen include/linux/string.h:281 [inline]
        hidraw_ioctl+0x245/0xae0 drivers/hid/hidraw.c:446
        vfs_ioctl fs/ioctl.c:46 [inline]
        file_ioctl fs/ioctl.c:509 [inline]
        do_vfs_ioctl+0xd2d/0x1330 fs/ioctl.c:696
        ksys_ioctl+0x9b/0xc0 fs/ioctl.c:713
        __do_sys_ioctl fs/ioctl.c:720 [inline]
        __se_sys_ioctl fs/ioctl.c:718 [inline]
        __x64_sys_ioctl+0x6f/0xb0 fs/ioctl.c:718
        do_syscall_64+0xb7/0x580 arch/x86/entry/common.c:296
        entry_SYSCALL_64_after_hwframe+0x49/0xbe
      RIP: 0033:0x459829
      Code: fd b7 fb ff c3 66 2e 0f 1f 84 00 00 00 00 00 66 90 48 89 f8 48 89 f7
      48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff
      ff 0f 83 cb b7 fb ff c3 66 2e 0f 1f 84 00 00 00 00
      RSP: 002b:00007f7a68f6dc78 EFLAGS: 00000246 ORIG_RAX: 0000000000000010
      RAX: ffffffffffffffda RBX: 0000000000000003 RCX: 0000000000459829
      RDX: 0000000000000000 RSI: 0000000080404805 RDI: 0000000000000004
      RBP: 000000000075bf20 R08: 0000000000000000 R09: 0000000000000000
      R10: 0000000000000000 R11: 0000000000000246 R12: 00007f7a68f6e6d4
      R13: 00000000004c21de R14: 00000000004d5620 R15: 00000000ffffffff
      
      The two problems have the same cause: hidraw_ioctl() fails to test
      whether the device has been removed.  This patch adds the missing test.
      
      Reported-and-tested-by: syzbot+5a6c4ec678a0c6ee84ba@syzkaller.appspotmail.com
      Signed-off-by: default avatarAlan Stern <stern@rowland.harvard.edu>
      CC: <stable@vger.kernel.org>
      Signed-off-by: default avatarJiri Kosina <jkosina@suse.cz>
      416dacb8
  9. 20 Aug, 2019 2 commits
  10. 19 Aug, 2019 11 commits
    • Linus Torvalds's avatar
      Merge tag 'clk-fixes-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/clk/linux · 5f97cbe2
      Linus Torvalds authored
      Pull clk fixes from Stephen Boyd:
       "A couple fixes to the core framework logic that finds clk parents, a
        handful of samsung clk driver fixes for audio and display clks, and a
        small fix for the Stratix10 SoC driver that was checking the wrong
        register for validity"
      
      * tag 'clk-fixes-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/clk/linux:
        clk: Fix potential NULL dereference in clk_fetch_parent_index()
        clk: Fix falling back to legacy parent string matching
        clk: socfpga: stratix10: fix rate caclulationg for cnt_clks
        clk: samsung: exynos542x: Move MSCL subsystem clocks to its sub-CMU
        clk: samsung: exynos5800: Move MAU subsystem clocks to MAU sub-CMU
        clk: samsung: Change signature of exynos5_subcmus_init() function
      5f97cbe2
    • Linus Torvalds's avatar
      Merge branch 'siginfo-linus' of... · 287c55ed
      Linus Torvalds authored
      Merge branch 'siginfo-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/ebiederm/user-namespace
      
      Pull kernel thread signal handling fix from Eric Biederman:
       "I overlooked the fact that kernel threads are created with all signals
        set to SIG_IGN, and accidentally caused a regression in cifs and drbd
        when replacing force_sig with send_sig.
      
        This is my fix for that regression. I add a new function
        allow_kernel_signal which allows kernel threads to receive signals
        sent from the kernel, but continues to ignore all signals sent from
        userspace. This ensures the user space interface for cifs and drbd
        remain the same.
      
        These kernel threads depend on blocking networking calls which block
        until something is received or a signal is pending. Making receiving
        of signals somewhat necessary for these kernel threads.
      
        Perhaps someday we can cleanup those interfaces and remove
        allow_kernel_signal. If not allow_kernel_signal is pretty trivial and
        clearly documents what is going on so I don't think we will mind
        carrying it"
      
      * 'siginfo-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/ebiederm/user-namespace:
        signal: Allow cifs and drbd to receive their terminating signals
      287c55ed
    • Linus Torvalds's avatar
      Merge git://git.kernel.org/pub/scm/linux/kernel/git/netdev/net · 06821504
      Linus Torvalds authored
      Pull networking fixes from David Miller:
      
        1) Fix jmp to 1st instruction in x64 JIT, from Alexei Starovoitov.
      
        2) Severl kTLS fixes in mlx5 driver, from Tariq Toukan.
      
        3) Fix severe performance regression due to lack of SKB coalescing of
           fragments during local delivery, from Guillaume Nault.
      
        4) Error path memory leak in sch_taprio, from Ivan Khoronzhuk.
      
        5) Fix batched events in skbedit packet action, from Roman Mashak.
      
        6) Propagate VLAN TX offload to hw_enc_features in bond and team
           drivers, from Yue Haibing.
      
        7) RXRPC local endpoint refcounting fix and read after free in
           rxrpc_queue_local(), from David Howells.
      
        8) Fix endian bug in ibmveth multicast list handling, from Thomas
           Falcon.
      
        9) Oops, make nlmsg_parse() wrap around the correct function,
           __nlmsg_parse not __nla_parse(). Fix from David Ahern.
      
       10) Memleak in sctp_scend_reset_streams(), fro Zheng Bin.
      
       11) Fix memory leak in cxgb4, from Wenwen Wang.
      
       12) Yet another race in AF_PACKET, from Eric Dumazet.
      
       13) Fix false detection of retransmit failures in tipc, from Tuong
           Lien.
      
       14) Use after free in ravb_tstamp_skb, from Tho Vu.
      
      * git://git.kernel.org/pub/scm/linux/kernel/git/netdev/net: (101 commits)
        ravb: Fix use-after-free ravb_tstamp_skb
        netfilter: nf_tables: map basechain priority to hardware priority
        net: sched: use major priority number as hardware priority
        wimax/i2400m: fix a memory leak bug
        net: cavium: fix driver name
        ibmvnic: Unmap DMA address of TX descriptor buffers after use
        bnxt_en: Fix to include flow direction in L2 key
        bnxt_en: Use correct src_fid to determine direction of the flow
        bnxt_en: Suppress HWRM errors for HWRM_NVM_GET_VARIABLE command
        bnxt_en: Fix handling FRAG_ERR when NVM_INSTALL_UPDATE cmd fails
        bnxt_en: Improve RX doorbell sequence.
        bnxt_en: Fix VNIC clearing logic for 57500 chips.
        net: kalmia: fix memory leaks
        cx82310_eth: fix a memory leak bug
        bnx2x: Fix VF's VLAN reconfiguration in reload.
        Bluetooth: Add debug setting for changing minimum encryption key size
        tipc: fix false detection of retransmit failures
        lan78xx: Fix memory leaks
        MAINTAINERS: r8169: Update path to the driver
        MAINTAINERS: PHY LIBRARY: Update files in the record
        ...
      06821504
    • David Howells's avatar
      keys: Fix description size · 555df336
      David Howells authored
      The maximum key description size is 4095.  Commit f771fde8 ("keys:
      Simplify key description management") inadvertantly reduced that to 255
      and made sizes between 256 and 4095 work weirdly, and any size whereby
      size & 255 == 0 would cause an assertion in __key_link_begin() at the
      following line:
      
      	BUG_ON(index_key->desc_len == 0);
      
      This can be fixed by simply increasing the size of desc_len in struct
      keyring_index_key to a u16.
      
      Note the argument length test in keyutils only checked empty
      descriptions and descriptions with a size around the limit (ie.  4095)
      and not for all the values in between, so it missed this.  This has been
      addressed and
      
      	https://git.kernel.org/pub/scm/linux/kernel/git/dhowells/keyutils.git/commit/?id=066bf56807c26cd3045a25f355b34c1d8a20a5aa
      
      now exhaustively tests all possible lengths of type, description and
      payload and then some.
      
      The assertion failure looks something like:
      
       kernel BUG at security/keys/keyring.c:1245!
       ...
       RIP: 0010:__key_link_begin+0x88/0xa0
       ...
       Call Trace:
        key_create_or_update+0x211/0x4b0
        __x64_sys_add_key+0x101/0x200
        do_syscall_64+0x5b/0x1e0
        entry_SYSCALL_64_after_hwframe+0x44/0xa9
      
      It can be triggered by:
      
      	keyctl add user "aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa" a @s
      
      Fixes: f771fde8 ("keys: Simplify key description management")
      Reported-by: default avatarkernel test robot <rong.a.chen@intel.com>
      Signed-off-by: default avatarDavid Howells <dhowells@redhat.com>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      555df336
    • Benjamin Tissoires's avatar
      HID: cp2112: prevent sleeping function called from invalid context · 2d05dba2
      Benjamin Tissoires authored
      When calling request_threaded_irq() with a CP2112, the function
      cp2112_gpio_irq_startup() is called in a IRQ context.
      
      Therefore we can not sleep, and we can not call
      cp2112_gpio_direction_input() there.
      
      Move the call to cp2112_gpio_direction_input() earlier to have a working
      driver.
      Signed-off-by: default avatarBenjamin Tissoires <benjamin.tissoires@redhat.com>
      Signed-off-by: default avatarJiri Kosina <jkosina@suse.cz>
      2d05dba2
    • Even Xu's avatar
      HID: intel-ish-hid: ipc: add EHL device id · b640be5b
      Even Xu authored
      EHL is a new platform using ishtp solution, add its device id
      to support list.
      Signed-off-by: default avatarEven Xu <even.xu@intel.com>
      Acked-by: default avatarSrinivas Pandruvada <srinivas.pandruvada@linux.intel.com>
      Signed-off-by: default avatarJiri Kosina <jkosina@suse.cz>
      b640be5b
    • Jason Gerecke's avatar
      HID: wacom: Correct distance scale for 2nd-gen Intuos devices · b72fb1dc
      Jason Gerecke authored
      Distance values reported by 2nd-gen Intuos tablets are on an inverted
      scale (0 == far, 63 == near). We need to change them over to a normal
      scale before reporting to userspace or else userspace drivers and
      applications can get confused.
      
      Ref: https://github.com/linuxwacom/input-wacom/issues/98
      Fixes: eda01dab ("HID: wacom: Add four new Intuos devices")
      Signed-off-by: default avatarJason Gerecke <jason.gerecke@wacom.com>
      Cc: <stable@vger.kernel.org> # v4.4+
      Signed-off-by: default avatarJiri Kosina <jkosina@suse.cz>
      b72fb1dc
    • Zhang Lixu's avatar
      HID: intel-ish-hid: ipc: check the NO_D3 flag to distinguish resume paths · fc19a57d
      Zhang Lixu authored
      The NO_D3 flag would be set if the ISH enter D0i3 in ish_suspend(),
      The resume paths can be distinguished by checking the NO_D3 flag.
      It's more reasonable than checking the FW status.
      Signed-off-by: default avatarZhang Lixu <lixu.zhang@intel.com>
      Acked-by: default avatarSrinivas Pandruvada <srinivas.pandruvada@linux.intel.com>
      Signed-off-by: default avatarJiri Kosina <jkosina@suse.cz>
      fc19a57d
    • Zhang Lixu's avatar
      HID: intel-ish-hid: ipc: make ish suspend paths clear · 2db8edaa
      Zhang Lixu authored
      For suspend-to-idle, send suspend message and set N0_D3 flag to put
      the ISH into D0i3 state.
      For suspend-to-mem, disable the DMA bit before ISH entering D3, and
      NO_D3 flag is cleared by default, then the ISH would enter D3.
      Signed-off-by: default avatarZhang Lixu <lixu.zhang@intel.com>
      Acked-by: default avatarSrinivas Pandruvada <srinivas.pandruvada@linux.intel.com>
      Signed-off-by: default avatarJiri Kosina <jkosina@suse.cz>
      2db8edaa
    • Zhang Lixu's avatar
      HID: intel-ish-hid: ipc: set NO_D3 flag only when needed · c1ca58f6
      Zhang Lixu authored
      Currently, the NO_D3 flag is set in ish_probe(), and cleared in
      ish_remove(). So even if the system goes into S3, ISH is still
      in D0i3 state. It makes more sense that put ISH into D3 as system
      goes into S3 and put ISH into D0i3 as system goes into suspend-to-idle.
      I remove the NO_D3 setting in ish_probe(), so that ISH can enter
      D3 state when system enters S3. Only set N0_D3 flag when system
      enters the suspend-to-idle or platform specified, and clear it
      when system resume.
      
      When the ISH enters D3, the FW will check the DMA bit status.
      If the DMA bit is set, the FW will reset automatically. So the
      DMA bit need be clear before putting ISH into D3 state.
      Signed-off-by: default avatarZhang Lixu <lixu.zhang@intel.com>
      Acked-by: default avatarSrinivas Pandruvada <srinivas.pandruvada@linux.intel.com>
      Signed-off-by: default avatarJiri Kosina <jkosina@suse.cz>
      c1ca58f6
    • Eric W. Biederman's avatar
      signal: Allow cifs and drbd to receive their terminating signals · 33da8e7c
      Eric W. Biederman authored
      My recent to change to only use force_sig for a synchronous events
      wound up breaking signal reception cifs and drbd.  I had overlooked
      the fact that by default kthreads start out with all signals set to
      SIG_IGN.  So a change I thought was safe turned out to have made it
      impossible for those kernel thread to catch their signals.
      
      Reverting the work on force_sig is a bad idea because what the code
      was doing was very much a misuse of force_sig.  As the way force_sig
      ultimately allowed the signal to happen was to change the signal
      handler to SIG_DFL.  Which after the first signal will allow userspace
      to send signals to these kernel threads.  At least for
      wake_ack_receiver in drbd that does not appear actively wrong.
      
      So correct this problem by adding allow_kernel_signal that will allow
      signals whose siginfo reports they were sent by the kernel through,
      but will not allow userspace generated signals, and update cifs and
      drbd to call allow_kernel_signal in an appropriate place so that their
      thread can receive this signal.
      
      Fixing things this way ensures that userspace won't be able to send
      signals and cause problems, that it is clear which signals the
      threads are expecting to receive, and it guarantees that nothing
      else in the system will be affected.
      
      This change was partly inspired by similar cifs and drbd patches that
      added allow_signal.
      Reported-by: default avatarronnie sahlberg <ronniesahlberg@gmail.com>
      Reported-by: default avatarChristoph Böhmwalder <christoph.boehmwalder@linbit.com>
      Tested-by: default avatarChristoph Böhmwalder <christoph.boehmwalder@linbit.com>
      Cc: Steve French <smfrench@gmail.com>
      Cc: Philipp Reisner <philipp.reisner@linbit.com>
      Cc: David Laight <David.Laight@ACULAB.COM>
      Fixes: 247bc947 ("cifs: fix rmmod regression in cifs.ko caused by force_sig changes")
      Fixes: 72abe3bc ("signal/cifs: Fix cifs_put_tcp_session to call send_sig instead of force_sig")
      Fixes: fee10990 ("signal/drbd: Use send_sig not force_sig")
      Fixes: 3cf5d076 ("signal: Remove task parameter from force_sig")
      Signed-off-by: default avatar"Eric W. Biederman" <ebiederm@xmission.com>
      33da8e7c
  11. 18 Aug, 2019 2 commits