1. 07 Feb, 2019 9 commits
  2. 06 Feb, 2019 2 commits
  3. 05 Feb, 2019 2 commits
  4. 29 Jan, 2019 4 commits
  5. 28 Jan, 2019 2 commits
  6. 14 Jan, 2019 7 commits
  7. 07 Jan, 2019 5 commits
  8. 04 Jan, 2019 2 commits
    • Hans de Goede's avatar
      Input: soc_button_array - fix mapping of the 5th GPIO in a PNP0C40 device · e9eb788f
      Hans de Goede authored
      The Microsoft documenation for the PNP0C40 device aka the
      "Windows-compatible button array" describes the 5th GpioInt listed in
      the resources as: '5. Interrupt corresponding to the "Rotation Lock"
      button, if supported'.
      
      Notice this describes the 5th entry as a button while we sofar have been
      mapping it to EV_SW, SW_ROTATE_LOCK. On my Point of View TAB P1006W-232
      which actually comes with a rotation-lock button, the button indeed is a
      button and not a slider/switch. An image search for other Windows tablets
      has found 2 more models with a rotation-lock button and on both of those
      it too is a push-button and not a slider/switch.
      
      Further evidence can be found in the HUT extension HUTRR52 from Microsoft
      which adds rotation lock support to the HUT, which describes 2 different
      usages: "0xC9 System Display Rotation Lock Button" and
      "0xCA System Display Rotation Lock Slider Switch" note that switch is seen
      as a separate thing here and the non switch wording is an exact match for
      the "Windows-compatible button array" spec wording.
      
      TL;DR: our current mapping of the 5th GPIO to SW_ROTATE_LOCK is wrong
      because the 5th GPIO is for a push-button not a switch.
      
      This commit fixes this by maping the 5th GPIO to KEY_ROTATE_LOCK_TOGGLE.
      Signed-off-by: default avatarHans de Goede <hdegoede@redhat.com>
      Signed-off-by: default avatarDmitry Torokhov <dmitry.torokhov@gmail.com>
      e9eb788f
    • Hans de Goede's avatar
      Input: soc_button_array - add usage-page 0x01 usage-id 0xca mapping · 39be9b6d
      Hans de Goede authored
      The ACPI0011 _DSD button descriptor on a CHT based Intel Compute Sticks
      contains a mapping for usage-page 0x01 usage-id 0xca.
      
      As described in hutrr52_system_display_rotation_lock_controls_0.pdf this
      should be mapped as a "System Display Rotation Lock Slider Switch", this
      commit adds support for this, silencing the following warning:
      
      soc_button_array ACPI0011:00: Unknown button index 4 upage 01 usage ca,
      ignoring
      Signed-off-by: default avatarHans de Goede <hdegoede@redhat.com>
      Signed-off-by: default avatarDmitry Torokhov <dmitry.torokhov@gmail.com>
      39be9b6d
  9. 29 Dec, 2018 1 commit
  10. 23 Dec, 2018 2 commits
  11. 22 Dec, 2018 4 commits
    • Linus Torvalds's avatar
      Merge tag 'scsi-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/jejb/scsi · 9105b8aa
      Linus Torvalds authored
      Pull SCSI fixes from James Bottomley:
       "This is two simple target fixes and one discard related I/O starvation
        problem in sd.
      
        The discard problem occurs because the discard page doesn't have a
        mempool backing so if the allocation fails due to memory pressure, we
        then lose the forward progress we require if the writeout is on the
        same device. The fix is to back it with a mempool"
      
      * tag 'scsi-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/jejb/scsi:
        scsi: sd: use mempool for discard special page
        scsi: target: iscsi: cxgbit: add missing spin_lock_init()
        scsi: target: iscsi: cxgbit: fix csk leak
      9105b8aa
    • Linus Torvalds's avatar
      Merge tag 'compiler-attributes-for-linus-v4.20' of https://github.com/ojeda/linux · 1104bd96
      Linus Torvalds authored
      Pull compiler_types.h fix from Miguel Ojeda:
       "A cleanup for userspace in compiler_types.h: don't pollute userspace
        with macro definitions (Xiaozhou Liu)
      
        This is harmless for the kernel, but v4.19 was released with a few
        macros exposed to userspace as the patch explains; which this removes,
        so it *could* happen that we break something for someone (although
        leaving inline redefined is probably worse)"
      
      * tag 'compiler-attributes-for-linus-v4.20' of https://github.com/ojeda/linux:
        include/linux/compiler_types.h: don't pollute userspace with macro definitions
      1104bd96
    • Linus Torvalds's avatar
      Merge tag 'auxdisplay-for-linus-v4.20' of https://github.com/ojeda/linux · 38c0ecf6
      Linus Torvalds authored
      Pull auxdisplay fix from Miguel Ojeda:
       "charlcd: fix x/y command parsing (Mans Rullgard)"
      
      * tag 'auxdisplay-for-linus-v4.20' of https://github.com/ojeda/linux:
        auxdisplay: charlcd: fix x/y command parsing
      38c0ecf6
    • Christian Brauner's avatar
      Revert "vfs: Allow userns root to call mknod on owned filesystems." · 94f82008
      Christian Brauner authored
      This reverts commit 55956b59.
      
      commit 55956b59 ("vfs: Allow userns root to call mknod on owned filesystems.")
      enabled mknod() in user namespaces for userns root if CAP_MKNOD is
      available. However, these device nodes are useless since any filesystem
      mounted from a non-initial user namespace will set the SB_I_NODEV flag on
      the filesystem. Now, when a device node s created in a non-initial user
      namespace a call to open() on said device node will fail due to:
      
      bool may_open_dev(const struct path *path)
      {
              return !(path->mnt->mnt_flags & MNT_NODEV) &&
                      !(path->mnt->mnt_sb->s_iflags & SB_I_NODEV);
      }
      
      The problem with this is that as of the aforementioned commit mknod()
      creates partially functional device nodes in non-initial user namespaces.
      In particular, it has the consequence that as of the aforementioned commit
      open() will be more privileged with respect to device nodes than mknod().
      Before it was the other way around. Specifically, if mknod() succeeded
      then it was transparent for any userspace application that a fatal error
      must have occured when open() failed.
      
      All of this breaks multiple userspace workloads and a widespread assumption
      about how to handle mknod(). Basically, all container runtimes and systemd
      live by the slogan "ask for forgiveness not permission" when running user
      namespace workloads. For mknod() the assumption is that if the syscall
      succeeds the device nodes are useable irrespective of whether it succeeds
      in a non-initial user namespace or not. This logic was chosen explicitly
      to allow for the glorious day when mknod() will actually be able to create
      fully functional device nodes in user namespaces.
      A specific problem people are already running into when running 4.18 rc
      kernels are failing systemd services. For any distro that is run in a
      container systemd services started with the PrivateDevices= property set
      will fail to start since the device nodes in question cannot be
      opened (cf. the arguments in [1]).
      
      Full disclosure, Seth made the very sound argument that it is already
      possible to end up with partially functional device nodes. Any filesystem
      mounted with MS_NODEV set will allow mknod() to succeed but will not allow
      open() to succeed. The difference to the case here is that the MS_NODEV
      case is transparent to userspace since it is an explicitly set mount option
      while the SB_I_NODEV case is an implicit property enforced by the kernel
      and hence opaque to userspace.
      
      [1]: https://github.com/systemd/systemd/pull/9483Signed-off-by: default avatarChristian Brauner <christian@brauner.io>
      Cc: "Eric W. Biederman" <ebiederm@xmission.com>
      Cc: Seth Forshee <seth.forshee@canonical.com>
      Cc: Serge Hallyn <serge@hallyn.com>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      94f82008