1. 22 Feb, 2023 11 commits
  2. 20 Feb, 2023 1 commit
  3. 16 Feb, 2023 1 commit
  4. 15 Feb, 2023 7 commits
  5. 10 Feb, 2023 8 commits
  6. 09 Feb, 2023 6 commits
    • Linus Torvalds's avatar
      Merge tag 'for-linus-2023020901' of git://git.kernel.org/pub/scm/linux/kernel/git/hid/hid · 0b028189
      Linus Torvalds authored
      Pull HID fixes from Benjamin Tissoires:
      
       - fix potential infinite loop with a badly crafted HID device (Xin
         Zhao)
      
       - fix regression from 6.1 in USB logitech devices potentially making
         their mouse wheel not working (Bastien Nocera)
      
       - clean up in AMD sensors, which fixes a long time resume bug (Mario
         Limonciello)
      
       - few device small fixes and quirks
      
      * tag 'for-linus-2023020901' of git://git.kernel.org/pub/scm/linux/kernel/git/hid/hid:
        HID: Ignore battery for ELAN touchscreen 29DF on HP
        HID: amd_sfh: if no sensors are enabled, clean up
        HID: logitech: Disable hi-res scrolling on USB
        HID: core: Fix deadloop in hid_apply_multiplier.
        HID: Ignore battery for Elan touchscreen on Asus TP420IA
        HID: elecom: add support for TrackBall 056E:011C
      0b028189
    • Linus Torvalds's avatar
      Merge tag '6.2-rc8-smb3-client-fix' of git://git.samba.org/sfrench/cifs-2.6 · 94a1f56d
      Linus Torvalds authored
      Pull cifx fix from Steve French:
       "Small fix for use after free"
      
      * tag '6.2-rc8-smb3-client-fix' of git://git.samba.org/sfrench/cifs-2.6:
        cifs: Fix use-after-free in rdata->read_into_pages()
      94a1f56d
    • Douglas Anderson's avatar
      HID: i2c-hid: goodix: Add mainboard-vddio-supply · eb16f59e
      Douglas Anderson authored
      As talked about in the patch ("dt-bindings: HID: i2c-hid: goodix: Add
      mainboard-vddio-supply") we may need to power up a 1.8V rail on the
      host associated with touchscreen IO. Let's add support in the driver
      for it.
      Signed-off-by: default avatarDouglas Anderson <dianders@chromium.org>
      Reviewed-by: default avatarDmitry Torokhov <dmitry.torokhov@gmail.com>
      Reviewed-by: default avatarMatthias Kaehlcke <mka@chromium.org>
      Link: https://lore.kernel.org/r/20230206184744.6.Ic234b931025d1f920ce9e06fff294643943a65ad@changeidSigned-off-by: default avatarBenjamin Tissoires <benjamin.tissoires@redhat.com>
      eb16f59e
    • Douglas Anderson's avatar
      dt-bindings: HID: i2c-hid: goodix: Add mainboard-vddio-supply · 1d18c1f3
      Douglas Anderson authored
      The goodix i2c-hid bindings currently support two models of
      touchscreen: GT7375P and GT7986U. The datasheets of both touchscreens
      show the following things:
      * The mainboard that the touchscreen is connected to is only expected
        to supply one voltage to the touchscreen: 3.3V.
      * The touchscreen, depending on stuffing options, can accept IO to the
        touchscreen as either 3.3V or 1.8V. Presumably this means that the
        touchscreen has its own way internally to make or deal with 1.8V
        signals when it's configured for 1.8V IO.
      
      NOTE: you've got to look very carefully at the datasheet for the
      touchscreen to see that the above bullets are true. Specifically, the
      datasheet shows a signal called VDDIO and one might think that this is
      where a mainboard would provide VDDIO to the touchscreen. Upon closer
      inspection, however, a footnote can be found that says "When VDDIO is
      left floating, the logic level is 1.8V [...]; when VDDIO is connected
      to AVDD, the logic level is AVDD.". Thus the VDDIO pin on the
      touchscreen IC is actually a selector and not a pin whre the mainboard
      would pass a reference voltage.
      
      The fact that the touchscreen isn't supplied 1.8V by the mainboard
      means that when I originally submitted bindings for these touchscreens
      I only listed the 3.3V rail in the bindings. It can be noted that the
      original bindings and driver were added for sc7180-trogdor boards and
      these boards all use 3.3V IO via a level shifter on the mainboard.
      
      It turns out that with sc7280-herobrine-evoker, we've got a bit of a
      strange monkey on our hands. Due to some very interesting but
      (unfortunately) set-in-stone hardware design, we are doing 1.8V IO to
      the touchscreen but we _also_ have some extra buffers on the mainboard
      that need to be powered up to make the IO lines work. After much
      pondering about this, it seems like the best way to handle this is to
      add an optional "mainboard-vddio" rail to the bindings that is used to
      power up the buffers. Specifically, the fact that the touchscreen
      datasheet documents that its IOs can be at a different voltage level
      than its main power rail means that there truly are two voltage rails
      associated with the touchscreen, even if we don't actually provide the
      IO rail to it. Thus it doesn't feel absurd for the DT node on the host
      to have a 1.8V rail to power up anything related to its 1.8V logic.
      Signed-off-by: default avatarDouglas Anderson <dianders@chromium.org>
      Reviewed-by: default avatarDmitry Torokhov <dmitry.torokhov@gmail.com>
      Acked-by: default avatarRob Herring <robh@kernel.org>
      Link: https://lore.kernel.org/r/20230206184744.5.Ia77a96c6c5564f9cc25e6220b5a9171d5c2639e8@changeidSigned-off-by: default avatarBenjamin Tissoires <benjamin.tissoires@redhat.com>
      1d18c1f3
    • Douglas Anderson's avatar
      HID: i2c-hid: goodix: Stop tying the reset line to the regulator · 557e05fa
      Douglas Anderson authored
      In commit 18eeef46 ("HID: i2c-hid: goodix: Tie the reset line to
      true state of the regulator"), we started tying the reset line of
      Goodix touchscreens to the regulator.
      
      The primary motivation for that patch was some pre-production hardware
      (specifically sc7180-trogdor-homestar) where it was proposed to hook
      the touchscreen's main 3.3V power rail to an always-on supply. In such
      a case, when we turned "off" the touchscreen in Linux it was bad to
      assert the "reset" GPIO because that was causing a power drain. The
      patch accomplished that goal and did it in a general sort of way that
      didn't require special properties to be added in the device tree for
      homestar.
      
      It turns out that the design of using an always-on power rail for the
      touchscreen was rejected soon after the patch was written and long
      before sc7180-trogdor-homestar went into production. The final design
      of homestar actually fully separates the rail for the touchscreen and
      the display panel and both can be powered off and on. That means that
      the original motivation for the feature is gone.
      
      There are 3 other users of the goodix i2c-hid driver in mainline.
      
      I'll first talk about 2 of the other users in mainline: coachz and
      mrbland. On both coachz and mrbland the touchscreen power and panel
      power _are_ shared. That means that the patch to tie the reset line to
      the true state of the regulator _is_ doing something on those
      boards. Specifically, the patch reduced power consumption by tens of
      mA in the case where we turned the touchscreen off but left the panel
      on. Other than saving a small bit of power, the patch wasn't truly
      necessary. That being said, even though a small bit of power was saved
      in the state of "panel on + touchscreen off", that's not actually a
      state we ever expect to be in, except perhaps for very short periods
      of time at boot or during suspend/resume. Thus, the patch is truly not
      necessary. It should be further noted that, as documented in the
      original patch, the current code still didn't optimize power for every
      corner case of the "shared rail" situation.
      
      The last user in mainline was very recently added: evoker. Evoker is
      actually the motivation for me removing this bit of code. It turns out
      that for evoker we need to manage a second power rail for IO to the
      touchscreen. Trying to fit the management of this IO rail into the
      regulator notifiers turns out to be extremely hard. To avoid lockdep
      splats you shouldn't enable/disable other regulators in regulator
      notifiers and trying to find a way around this was going to be fairly
      difficult.
      
      Given the lack of any true motivation to tie the reset line to the
      regulator, lets go back to the simpler days and remove the code. This
      is, effectively, a revert of commit bdbc65eb77ee ("HID: i2c-hid:
      goodix: Fix a lockdep splat"), commit 25ddd7cf ("HID: i2c-hid:
      goodix: Use the devm variant of regulator_register_notifier()"), and
      commit 18eeef46 ("HID: i2c-hid: goodix: Tie the reset line to true
      state of the regulator").
      Signed-off-by: default avatarDouglas Anderson <dianders@chromium.org>
      Reviewed-by: default avatarMatthias Kaehlcke <mka@chromium.org>
      Reviewed-by: default avatarDmitry Torokhov <dmitry.torokhov@gmail.com>
      Link: https://lore.kernel.org/r/20230206184744.4.I085b32b6140c7d1ac4e7e97b712bff9dd5962b62@changeidSigned-off-by: default avatarBenjamin Tissoires <benjamin.tissoires@redhat.com>
      557e05fa
    • Dmitry Torokhov's avatar
      HID: retain initial quirks set up when creating HID devices · 03a86105
      Dmitry Torokhov authored
      In certain circumstances, such as when creating I2C-connected HID
      devices, we want to pass and retain some quirks (axis inversion, etc).
      The source of such quirks may be device tree, or DMI data, or something
      else not readily available to the HID core itself and therefore cannot
      be reconstructed easily. To allow this, introduce "initial_quirks" field
      in hid_device structure and use it when determining the final set of
      quirks.
      
      This fixes the problem with i2c-hid setting up device-tree sourced
      quirks too late and losing them on device rebind, and also allows to
      sever the tie between hid-code and i2c-hid when applying DMI-based
      quirks.
      
      Fixes: b60d3c80 ("HID: i2c-hid-of: Expose the touchscreen-inverted properties")
      Fixes: a2f416bf ("HID: multitouch: Add quirks for flipped axes")
      Reviewed-by: default avatarGuenter Roeck <groeck@chromium.org>
      Tested-by: default avatarAllen Ballway <ballway@chromium.org>
      Signed-off-by: default avatarDmitry Torokhov <dmitry.torokhov@gmail.com>
      Reviewed-by: default avatarAlistair Francis <alistair@alistair23.me>
      Link: https://lore.kernel.org/r/Y+LYwu3Zs13hdVDy@google.comSigned-off-by: default avatarBenjamin Tissoires <benjamin.tissoires@redhat.com>
      03a86105
  7. 07 Feb, 2023 3 commits
    • Linus Torvalds's avatar
      Merge tag 'devicetree-fixes-for-6.2-2' of git://git.kernel.org/pub/scm/linux/kernel/git/robh/linux · 0983f6bf
      Linus Torvalds authored
      Pull devicetree fixes from Rob Herring:
      
       - Fix handling of multiple OF framebuffer devices
      
       - Fix booting on Socionext Synquacer with bad 'dma-ranges' entries
      
       - Add DT binding .yamllint to .gitignore
      
      * tag 'devicetree-fixes-for-6.2-2' of git://git.kernel.org/pub/scm/linux/kernel/git/robh/linux:
        dt-bindings: interrupt-controller: arm,gic-v3: Fix typo in description of msi-controller property
        dt-bindings: Fix .gitignore
        of/address: Return an error when no valid dma-ranges are found
        of: Make OF framebuffer device names unique
      0983f6bf
    • Linus Torvalds's avatar
      Merge tag 'trace-v6.2-rc6' of git://git.kernel.org/pub/scm/linux/kernel/git/trace/linux-trace · 513c1a3d
      Linus Torvalds authored
      Pull tracing fix from Steven Rostedt:
       "Fix regression in poll() and select()
      
        With the fix that made poll() and select() block if read would block
        caused a slight regression in rasdaemon, as it needed that kind of
        behavior. Add a way to make that behavior come back by writing zero
        into the 'buffer_percentage', which means to never block on read"
      
      * tag 'trace-v6.2-rc6' of git://git.kernel.org/pub/scm/linux/kernel/git/trace/linux-trace:
        tracing: Fix poll() and select() do not work on per_cpu trace_pipe and trace_pipe_raw
      513c1a3d
    • ZhaoLong Wang's avatar
      cifs: Fix use-after-free in rdata->read_into_pages() · aa5465ae
      ZhaoLong Wang authored
      When the network status is unstable, use-after-free may occur when
      read data from the server.
      
        BUG: KASAN: use-after-free in readpages_fill_pages+0x14c/0x7e0
      
        Call Trace:
         <TASK>
         dump_stack_lvl+0x38/0x4c
         print_report+0x16f/0x4a6
         kasan_report+0xb7/0x130
         readpages_fill_pages+0x14c/0x7e0
         cifs_readv_receive+0x46d/0xa40
         cifs_demultiplex_thread+0x121c/0x1490
         kthread+0x16b/0x1a0
         ret_from_fork+0x2c/0x50
         </TASK>
      
        Allocated by task 2535:
         kasan_save_stack+0x22/0x50
         kasan_set_track+0x25/0x30
         __kasan_kmalloc+0x82/0x90
         cifs_readdata_direct_alloc+0x2c/0x110
         cifs_readdata_alloc+0x2d/0x60
         cifs_readahead+0x393/0xfe0
         read_pages+0x12f/0x470
         page_cache_ra_unbounded+0x1b1/0x240
         filemap_get_pages+0x1c8/0x9a0
         filemap_read+0x1c0/0x540
         cifs_strict_readv+0x21b/0x240
         vfs_read+0x395/0x4b0
         ksys_read+0xb8/0x150
         do_syscall_64+0x3f/0x90
         entry_SYSCALL_64_after_hwframe+0x72/0xdc
      
        Freed by task 79:
         kasan_save_stack+0x22/0x50
         kasan_set_track+0x25/0x30
         kasan_save_free_info+0x2e/0x50
         __kasan_slab_free+0x10e/0x1a0
         __kmem_cache_free+0x7a/0x1a0
         cifs_readdata_release+0x49/0x60
         process_one_work+0x46c/0x760
         worker_thread+0x2a4/0x6f0
         kthread+0x16b/0x1a0
         ret_from_fork+0x2c/0x50
      
        Last potentially related work creation:
         kasan_save_stack+0x22/0x50
         __kasan_record_aux_stack+0x95/0xb0
         insert_work+0x2b/0x130
         __queue_work+0x1fe/0x660
         queue_work_on+0x4b/0x60
         smb2_readv_callback+0x396/0x800
         cifs_abort_connection+0x474/0x6a0
         cifs_reconnect+0x5cb/0xa50
         cifs_readv_from_socket.cold+0x22/0x6c
         cifs_read_page_from_socket+0xc1/0x100
         readpages_fill_pages.cold+0x2f/0x46
         cifs_readv_receive+0x46d/0xa40
         cifs_demultiplex_thread+0x121c/0x1490
         kthread+0x16b/0x1a0
         ret_from_fork+0x2c/0x50
      
      The following function calls will cause UAF of the rdata pointer.
      
      readpages_fill_pages
       cifs_read_page_from_socket
        cifs_readv_from_socket
         cifs_reconnect
          __cifs_reconnect
           cifs_abort_connection
            mid->callback() --> smb2_readv_callback
             queue_work(&rdata->work)  # if the worker completes first,
                                       # the rdata is freed
                cifs_readv_complete
                  kref_put
                    cifs_readdata_release
                      kfree(rdata)
       return rdata->...               # UAF in readpages_fill_pages()
      
      Similarly, this problem also occurs in the uncache_fill_pages().
      
      Fix this by adjusts the order of condition judgment in the return
      statement.
      Signed-off-by: default avatarZhaoLong Wang <wangzhaolong1@huawei.com>
      Cc: stable@vger.kernel.org
      Acked-by: default avatarPaulo Alcantara (SUSE) <pc@cjr.nz>
      Signed-off-by: default avatarSteve French <stfrench@microsoft.com>
      aa5465ae
  8. 06 Feb, 2023 3 commits
    • Linus Torvalds's avatar
      Merge tag 'cgroup-for-6.2-rc7-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/tj/cgroup · 05ecb680
      Linus Torvalds authored
      Pull cgroup fixes from Tejun Heo:
       "During the v6.2 cycle, there were a series of changes to task cpu
        affinity handling which fixed cpuset inadvertently clobbering
        user-configured affinity masks. Unfortunately, they broke the affinity
        handling on hybrid heterogeneous CPUs which have cores that can
        execute both 64 and 32bit along with cores that can only execute 32bit
        code.
      
        This contains two fix patches for the above issue. While reverting the
        changes that caused the regression is definitely an option, the
        origial patches do improve how cpuset behave signficantly in some
        cases and the fixes seem fairly safe, so I think it'd be better to try
        to fix them first"
      
      * tag 'cgroup-for-6.2-rc7-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/tj/cgroup:
        cpuset: Call set_cpus_allowed_ptr() with appropriate mask for task
        cgroup/cpuset: Don't filter offline CPUs in cpuset_cpus_allowed() for top cpuset tasks
      05ecb680
    • Linus Torvalds's avatar
      Merge tag 'for-6.2-rc7-tag' of git://git.kernel.org/pub/scm/linux/kernel/git/kdave/linux · 66fcf74e
      Linus Torvalds authored
      Pull btrfs fixes from David Sterba:
      
       - explicitly initialize zlib work memory to fix a KCSAN warning
      
       - limit number of send clones by maximum memory allocated
      
       - limit device size extent in case it device shrink races with chunk
         allocation
      
       - raid56 fixes:
           - fix copy&paste error in RAID6 stripe recovery
           - make error bitmap update atomic
      
      * tag 'for-6.2-rc7-tag' of git://git.kernel.org/pub/scm/linux/kernel/git/kdave/linux:
        btrfs: raid56: make error_bitmap update atomic
        btrfs: send: limit number of clones and allocated memory size
        btrfs: zlib: zero-initialize zlib workspace
        btrfs: limit device extents to the device size
        btrfs: raid56: fix stripes if vertical errors are found
      66fcf74e
    • Will Deacon's avatar
      cpuset: Call set_cpus_allowed_ptr() with appropriate mask for task · 7a2127e6
      Will Deacon authored
      set_cpus_allowed_ptr() will fail with -EINVAL if the requested
      affinity mask is not a subset of the task_cpu_possible_mask() for the
      task being updated. Consequently, on a heterogeneous system with cpusets
      spanning the different CPU types, updates to the cgroup hierarchy can
      silently fail to update task affinities when the effective affinity
      mask for the cpuset is expanded.
      
      For example, consider an arm64 system with 4 CPUs, where CPUs 2-3 are
      the only cores capable of executing 32-bit tasks. Attaching a 32-bit
      task to a cpuset containing CPUs 0-2 will correctly affine the task to
      CPU 2. Extending the cpuset to CPUs 0-3, however, will fail to extend
      the affinity mask of the 32-bit task because update_tasks_cpumask() will
      pass the full 0-3 mask to set_cpus_allowed_ptr().
      
      Extend update_tasks_cpumask() to take a temporary 'cpumask' paramater
      and use it to mask the 'effective_cpus' mask with the possible mask for
      each task being updated.
      
      Fixes: 431c69fa ("cpuset: Honour task_cpu_possible_mask() in guarantee_online_cpus()")
      Signed-off-by: default avatarWill Deacon <will@kernel.org>
      Acked-by: default avatarWaiman Long <longman@redhat.com>
      Signed-off-by: default avatarTejun Heo <tj@kernel.org>
      7a2127e6