1. 16 5月, 2018 2 次提交
  2. 10 5月, 2018 1 次提交
  3. 09 5月, 2018 4 次提交
  4. 24 4月, 2018 2 次提交
    • P
      Input: alps - demystify trackstick initialization for v3 and v6 protocols · d91abc21
      Pali Rohár 提交于
      Remove cite "Not sure what this does, but it is absolutely essential".
      
      Extract initialization of trackstick part when touchpad is in passthrough
      mode for v3 and v6 protocols into own function. Initialization for v3 is:
      setscale11, setscale11, setscale11, nibble 0x9, nibble 0x4. Initialization
      for v6 is: setscale11, setscale11, setscale11, setrate 0xC8, setrate 0x14.
      Nibbles 0x9 and 0x4 for v3 protocol correspond to setrate 0xC8 and 0x14,
      therefore these sequences are same.
      
      When touchpad is in passthrough mode, then OS communicates with trackstick
      and this sequence is some magic vendor PS/2 command to put trackstick into
      "extended" mode. After that sequence trackstick starts reporting packets in
      some vendor 4 bytes format (first byte is always 0xE8).
      
      Next step after configuring trackstick to be in "extended" mode, is to
      configure touchpad for v3 protocol to expect that trackstick reports data
      in "extended" mode. For v3 protocol this is done by setting bit 1 in
      register 0xC2C8 (offset 0x08 from base address 0xC2C0).
      
      When both touchpad and trackstick are not configured for "extended" mode
      then touchpad reports trackstick packets in different format, which is not
      supported by psmouse/alps driver (yet).
      
      In Cirque documentation GP-AN- 130823 INTERFACING TO GEN4 OVER I2C (PDF)
      available at http://www.cirque.com/gen4-dev-resources is Logical Address
      0xC2C8 named as PS2AuxControl and Bit Number 1 as ProcessAuxExtendedData
      with description: Auxiliary device data is assumed to be extended data when
      set.
      Signed-off-by: NPali Rohár <pali.rohar@gmail.com>
      Signed-off-by: NDmitry Torokhov <dmitry.torokhov@gmail.com>
      d91abc21
    • D
      Merge branch 'ib-chrome-platform-input-atmel-mx-ts-platform-removal' of... · 57eb13a9
      Dmitry Torokhov 提交于
      Merge branch 'ib-chrome-platform-input-atmel-mx-ts-platform-removal' of git://git.kernel.org/pub/scm/linux/kernel/git/bleung/chrome-platform into next
      
      Sync up with chrome-platform to bring in changes to Atmel touch
      controller.
      57eb13a9
  5. 10 4月, 2018 14 次提交
  6. 05 4月, 2018 1 次提交
    • O
      Input: i8042 - enable MUX on Sony VAIO VGN-CS series to fix touchpad · 04bb1719
      Ondrej Zary 提交于
      The touch sensor buttons on Sony VAIO VGN-CS series laptops (e.g.
      VGN-CS31S) are a separate PS/2 device. As the MUX is disabled for all
      VAIO machines by the nomux blacklist, the data from touch sensor
      buttons and touchpad are combined. The protocol used by the buttons is
      probably similar to the touchpad protocol (both are Synaptics) so both
      devices get enabled. The controller combines the data, creating a mess
      which results in random button clicks, touchpad stopping working and
      lost sync error messages:
      psmouse serio1: TouchPad at isa0060/serio1/input0 lost sync at byte 4
      psmouse serio1: TouchPad at isa0060/serio1/input0 lost sync at byte 1
      psmouse serio1: TouchPad at isa0060/serio1/input0 lost sync at byte 1
      psmouse serio1: TouchPad at isa0060/serio1/input0 lost sync at byte 1
      psmouse serio1: TouchPad at isa0060/serio1/input0 lost sync at byte 1
      psmouse serio1: issuing reconnect request
      
      Add a new i8042_dmi_forcemux_table whitelist with VGN-CS.
      With MUX enabled, touch sensor buttons are detected as separate device
      (and left disabled as there's currently no driver), fixing all touchpad
      problems.
      Signed-off-by: NOndrej Zary <linux@rainbow-software.org>
      Cc: stable@vger.kernel.org
      Signed-off-by: NDmitry Torokhov <dmitry.torokhov@gmail.com>
      04bb1719
  7. 31 3月, 2018 2 次提交
  8. 27 3月, 2018 4 次提交
  9. 26 3月, 2018 8 次提交
  10. 25 3月, 2018 2 次提交
    • L
      Merge branch 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/ebiederm/user-namespace · e43d40b3
      Linus Torvalds 提交于
      Pull mqueuefs revert from Eric Biederman:
       "This fixes a regression that came in the merge window for v4.16.
      
        The problem is that the permissions for mounting and using the
        mqueuefs filesystem are broken. The necessary permission check is
        missing letting people who should not be able to mount mqueuefs mount
        mqueuefs. The field sb->s_user_ns is set incorrectly not allowing the
        mounter of mqueuefs to remount and otherwise have proper control over
        the filesystem.
      
        Al Viro and I see the path to the necessary fixes differently and I am
        not even certain at this point he actually sees all of the necessary
        fixes. Given a couple weeks we can probably work something out but I
        don't see the review being resolved in time for the final v4.16. I
        don't want v4.16 shipping with a nasty regression. So unfortunately I
        am sending a revert"
      
      * 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/ebiederm/user-namespace:
        Revert "mqueue: switch to on-demand creation of internal mount"
      e43d40b3
    • E
      Revert "mqueue: switch to on-demand creation of internal mount" · cfb2f6f6
      Eric W. Biederman 提交于
      This reverts commit 36735a6a.
      
      Aleksa Sarai <asarai@suse.de> writes:
      > [REGRESSION v4.16-rc6] [PATCH] mqueue: forbid unprivileged user access to internal mount
      >
      > Felix reported weird behaviour on 4.16.0-rc6 with regards to mqueue[1],
      > which was introduced by 36735a6a ("mqueue: switch to on-demand
      > creation of internal mount").
      >
      > Basically, the reproducer boils down to being able to mount mqueue if
      > you create a new user namespace, even if you don't unshare the IPC
      > namespace.
      >
      > Previously this was not possible, and you would get an -EPERM. The mount
      > is the *host* mqueue mount, which is being cached and just returned from
      > mqueue_mount(). To be honest, I'm not sure if this is safe or not (or if
      > it was intentional -- since I'm not familiar with mqueue).
      >
      > To me it looks like there is a missing permission check. I've included a
      > patch below that I've compile-tested, and should block the above case.
      > Can someone please tell me if I'm missing something? Is this actually
      > safe?
      >
      > [1]: https://github.com/docker/docker/issues/36674
      
      The issue is a lot deeper than a missing permission check.  sb->s_user_ns
      was is improperly set as well.  So in addition to the filesystem being
      mounted when it should not be mounted, so things are not allow that should
      be.
      
      We are practically to the release of 4.16 and there is no agreement between
      Al Viro and myself on what the code should looks like to fix things properly.
      So revert the code to what it was before so that we can take our time
      and discuss this properly.
      
      Fixes: 36735a6a ("mqueue: switch to on-demand creation of internal mount")
      Reported-by: NFelix Abecassis <fabecassis@nvidia.com>
      Reported-by: NAleksa Sarai <asarai@suse.de>
      Signed-off-by: N"Eric W. Biederman" <ebiederm@xmission.com>
      cfb2f6f6