04 Jul, 2017

1 commit

  • Pull uuid subsystem from Christoph Hellwig:
    "This is the new uuid subsystem, in which Amir, Andy and I have started
    consolidating our uuid/guid helpers and improving the types used for
    them. Note that various other subsystems have pulled in this tree, so
    I'd like it to go in early.

    UUID/GUID summary:

    - introduce the new uuid_t/guid_t types that are going to replace the
    somewhat confusing uuid_be/uuid_le types and make the terminology
    fit the various specs, as well as the userspace libuuid library.
    (me, based on a previous version from Amir)

    - consolidated generic uuid/guid helper functions lifted from XFS and
    libnvdimm (Amir and me)

    - conversions to the new types and helpers (Amir, Andy and me)"

    * tag 'uuid-for-4.13' of git://git.infradead.org/users/hch/uuid: (34 commits)
    ACPI: hns_dsaf_acpi_dsm_guid can be static
    mmc: sdhci-pci: make guid intel_dsm_guid static
    uuid: Take const on input of uuid_is_null() and guid_is_null()
    thermal: int340x_thermal: fix compile after the UUID API switch
    thermal: int340x_thermal: Switch to use new generic UUID API
    acpi: always include uuid.h
    ACPI: Switch to use generic guid_t in acpi_evaluate_dsm()
    ACPI / extlog: Switch to use new generic UUID API
    ACPI / bus: Switch to use new generic UUID API
    ACPI / APEI: Switch to use new generic UUID API
    acpi, nfit: Switch to use new generic UUID API
    MAINTAINERS: add uuid entry
    tmpfs: generate random sb->s_uuid
    scsi_debug: switch to uuid_t
    nvme: switch to uuid_t
    sysctl: switch to use uuid_t
    partitions/ldm: switch to use uuid_t
    overlayfs: use uuid_t instead of uuid_be
    fs: switch ->s_uuid to uuid_t
    ima/policy: switch to use uuid_t
    ...

    Linus Torvalds
     

20 Jun, 2017

2 commits


13 Jun, 2017

1 commit

  • There are many situations where generic HID driver provides some basic level
    of support for certain device, but later this support (usually by implementing
    vendor-specific extensions of HID protocol) is extended and the support moved
    over to a separate (usually per-vendor) specific driver.

    This might bring a rather unpleasant suprise for users, as all of a sudden
    there is a new config option they have to enable in order to get any support
    for their device whatsoever, although previous kernel versions provided basic
    support through the generic driver. Which is rightfully seen as a regression.

    Fix this by including the entry for a particular device in
    hid_have_special_driver[] iff the specific config option has been specified,
    and let generic driver handle the device otherwise.
    Also make the behavior of hid_scan_report() (where the same decision is being
    taken on a per-report level) consistent.

    While at it, reshuffle the hid_have_special_driver[] a bit to restore the
    alphabetical ordering (first order by config option, and within those
    sections order by VID).

    This is considered a short-term solution, before generic way of giving
    precedence to special drivers and falling back to generic driver is
    figured out.

    While at it, fixup a missing entry for GFRM driver; thanks to Hans de Geode for
    spotting this (and for discovering a few issues in the conversion).

    Signed-off-by: Jiri Kosina

    Jiri Kosina
     

07 Jun, 2017

1 commit

  • acpi_evaluate_dsm() and friends take a pointer to a raw buffer of 16
    bytes. Instead we convert them to use guid_t type. At the same time we
    convert current users.

    acpi_str_to_uuid() becomes useless after the conversion and it's safe to
    get rid of it.

    Acked-by: Rafael J. Wysocki
    Cc: Borislav Petkov
    Acked-by: Dan Williams
    Cc: Amir Goldstein
    Reviewed-by: Jarkko Sakkinen
    Reviewed-by: Jani Nikula
    Acked-by: Jani Nikula
    Cc: Ben Skeggs
    Acked-by: Benjamin Tissoires
    Acked-by: Joerg Roedel
    Acked-by: Adrian Hunter
    Cc: Yisen Zhuang
    Acked-by: Bjorn Helgaas
    Acked-by: Felipe Balbi
    Acked-by: Mathias Nyman
    Reviewed-by: Heikki Krogerus
    Acked-by: Mark Brown
    Signed-off-by: Andy Shevchenko
    Signed-off-by: Christoph Hellwig

    Andy Shevchenko
     

06 Jun, 2017

1 commit


03 Jun, 2017

1 commit

  • Pull HID fixes from Jiri Kosina:

    - corner-case oops fixes for Asus and Wacom drivers from Carlo Caione
    and Jason Gerecke

    - power management fix (reported on SIS0817 touchscreen) for i2c-hid
    devices from Hans de Goede

    - device-id-specific fixes and quirks from Hans de Goede, Diego Elio
    Pettenò and Che-Liang Chiou

    * 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/jikos/hid:
    HID: asus: Stop underlying hardware on remove
    HID: i2c: Call acpi_device_fix_up_power for ACPI-enumerated devices
    HID: asus: Add support for T100 keyboard
    HID: elecom: extend to fix the descriptor for DEFT trackballs
    HID: magicmouse: Set multi-touch keybits for Magic Mouse
    HID: wacom: Have wacom_tpc_irq guard against possible NULL dereference

    Linus Torvalds
     

02 Jun, 2017

1 commit

  • We are missing a call to hid_hw_stop() on the remove hook.
    Among other things this is causing an Oops when (re-)starting GNOME /
    upowerd / ... after the module has been already rmmod-ed.

    Signed-off-by: Carlo Caione
    Reviewed-by: Benjamin Tissoires
    Signed-off-by: Jiri Kosina

    Carlo Caione
     

29 May, 2017

1 commit

  • For ACPI devices which do not have a _PSC method, the ACPI subsys cannot
    query their initial state at boot, so these devices are assumed to have
    been put in D0 by the BIOS, but for touchscreens that is not always true.

    This commit adds a call to acpi_device_fix_up_power to explicitly put
    devices without a _PSC method into D0 state (for devices with a _PSC
    method it is a nop). Note we only need to do this on probe, after a
    resume the ACPI subsys knows the device is in D3 and will properly
    put it in D0.

    This fixes the SIS0817 i2c-hid touchscreen on a Peaq C1010 2-in-1
    device failing to probe with a "hid_descr_cmd failed" error.

    Acked-by: Benjamin Tissoires
    Signed-off-by: Hans de Goede
    Signed-off-by: Jiri Kosina

    Hans de Goede
     

22 May, 2017

1 commit

  • The keyboard dock used with the Asus Transformer T100 series, uses
    the same vendor-defined 0xff31 usage-page as some other Asus
    keyboards. But with a small twist, it has a small descriptor bug which
    needs to be fixed up for things to work.

    This commit adds the USB-ID for this keyboard to the hid-asus driver
    and makes asus_report_fixup fix the descriptor issue, fixing
    various special function keys on this keyboard not working.

    Signed-off-by: Hans de Goede
    Reviewed-by: Benjamin Tissoires
    Signed-off-by: Jiri Kosina

    Hans de Goede
     

11 May, 2017

1 commit

  • The ELECOM DEFT trackballs report only five buttons, when the device
    actually has 8. Change the descriptor so that the HID driver can see all of
    them.

    For completeness and future reference, I included a side-by-side diff of
    the part of the descriptor that is being edited.

    Cc: Jiri Kosina
    Cc: Benjamin Tissoires
    Cc: Yuxuan Shui
    Signed-off-by: Diego Elio Pettenò
    Signed-off-by: Jiri Kosina

    Diego Elio Pettenò
     

05 May, 2017

2 commits

  • The driver emits multi-touch events for Magic Trackpad as well as Magic
    Mouse, but it does not set keybits that are related to multi-touch event
    for Magic Mouse; so set these keybits.

    The keybits that are not set cause trouble because user programs often
    probe these keybits for self-configuration and thus they cannot operate
    properly if the keybits are not set.

    One of such troubles is that libevdev will not be able to emit correct
    touch count, causing gestures library failed to do fling stop.

    Signed-off-by: Che-Liang Chiou
    Signed-off-by: Thierry Escande
    Signed-off-by: Jiri Kosina

    Che-Liang Chiou
     
  • The following Smatch complaint was generated in response to commit
    2a6cdbd ("HID: wacom: Introduce new 'touch_input' device"):

    drivers/hid/wacom_wac.c:1586 wacom_tpc_irq()
    error: we previously assumed 'wacom->touch_input' could be null (see line 1577)

    The 'touch_input' and 'pen_input' variables point to the 'struct input_dev'
    used for relaying touch and pen events to userspace, respectively. If a
    device does not have a touch interface or pen interface, the associated
    input variable is NULL. The 'wacom_tpc_irq()' function is responsible for
    forwarding input reports to a more-specific IRQ handler function. An
    unknown report could theoretically be mistaken as e.g. a touch report
    on a device which does not have a touch interface. This can be prevented
    by only calling the pen/touch functions are called when the pen/touch
    pointers are valid.

    Fixes: 2a6cdbd ("HID: wacom: Introduce new 'touch_input' device")
    Signed-off-by: Jason Gerecke
    Reviewed-by: Ping Cheng
    Cc: stable@vger.kernel.org
    Signed-off-by: Jiri Kosina

    Jason Gerecke
     

03 May, 2017

1 commit

  • Pull trivial tree updates from Jiri Kosina.

    * 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/jikos/trivial:
    tty: fix comment for __tty_alloc_driver()
    init/main: properly align the multi-line comment
    init/main: Fix double "the" in comment
    Fix dead URLs to ftp.kernel.org
    drivers: Clean up duplicated email address
    treewide: Fix typo in xml/driver-api/basics.xml
    tools/testing/selftests/powerpc: remove redundant CFLAGS in Makefile: "-Wall -O2 -Wall" -> "-O2 -Wall"
    selftests/timers: Spelling s/privledges/privileges/
    HID: picoLCD: Spelling s/REPORT_WRTIE_MEMORY/REPORT_WRITE_MEMORY/
    net: phy: dp83848: Fix Typo
    UBI: Fix typos
    Documentation: ftrace.txt: Correct nice value of 120 priority
    net: fec: Fix typo in error msg and comment
    treewide: Fix typos in printk

    Linus Torvalds
     

02 May, 2017

3 commits


26 Apr, 2017

1 commit


20 Apr, 2017

1 commit

  • It apears that devices designed around Wacom's G11 chipset (e.g. Lenovo
    ThinkPad Yoga 260, Lenovo ThinkPad X1 Yoga, Dell XPS 12 9250, Dell Venue
    8 Pro 5855, etc.) suffer from a common issue in their HID descriptors.
    The logical maximum is not updated for the "Contact Identifier" usage,
    leaving it as just "1" despite these devices being capable of tracking
    far more touches.

    Commit 60a221869803 began ignoring usages with out-of-range values,
    causing problems for devices based on this chipset. Touches after
    the first will have an out-of-range Contact Identifier, and ignoring
    that usage will cause the kernel to incorrectly slot each finger's
    events (along with all the knock-on userspace effects that entails).

    This commit checks for these buggy descriptors and updates the maximum
    where required. Prior chipsets have used "255" as the maximum (and the
    G11, at least, doesn't seem to actually use IDs outside the range of
    1..CONTACTMAX) so continue using this value.

    Cc: stable@vger.kernel.org
    Fixes: 60a221869803 ("HID: wacom: generic: add support for touchring")
    Signed-off-by: Jason Gerecke
    Signed-off-by: Jiri Kosina

    Jason Gerecke
     

19 Apr, 2017

1 commit

  • Because HID_DG_TOOLSERIALNUMBER doesn't first cast the value recieved from HID
    to an unsigned type, sign-extension rules can cause the value of
    wacom_wac->serial[0] to inadvertently wind up with all 32 of its highest bits
    set if the highest bit of "value" was set.

    This can cause problems for Tablet PC devices which use AES sensors and the
    xf86-input-wacom userspace driver. It is not uncommon for AES sensors to send a
    serial number of '0' while the pen is entering or leaving proximity. The
    xf86-input-wacom driver ignores events with a serial number of '0' since it
    cannot match them up to an in-use tool. To ensure the xf86-input-wacom driver
    does not ignore the final out-of-proximity event, the kernel does not send
    MSC_SERIAL events when the value of wacom_wac->serial[0] is '0'. If the highest
    bit of HID_DG_TOOLSERIALNUMBER is set by an in-prox pen which later leaves
    proximity and sends a '0' for HID_DG_TOOLSERIALNUMBER, then only the lowest 32
    bits of wacom_wac->serial[0] are actually cleared, causing the kernel to send
    an MSC_SERIAL event. Since the 'input_event' function takes an 'int' as
    argument, only those lowest (now-cleared) 32 bits of wacom_wac->serial[0] are
    sent to userspace, causing xf86-input-wacom to ignore the event. If the event
    was the final out-of-prox event, then xf86-input-wacom may remain in a state
    where it believes the pen is in proximity and refuses to allow other devices
    under its control (e.g. the touchscreen) to move the cursor.

    It should be noted that EMR devices and devices which use both the
    HID_DG_TOOLSERIALNUMBER and WACOM_HID_WD_SERIALHI usages (in that order) would
    be immune to this issue. It appears only AES devices are affected.

    Fixes: f85c9dc678a ("HID: wacom: generic: Support tool ID and additional tool types")
    Cc: stable@vger.kernel.org
    Signed-off-by: Jason Gerecke
    Acked-by: Benjamin Tissoires
    Signed-off-by: Jiri Kosina

    Jason Gerecke
     

13 Apr, 2017

1 commit

  • The latest USB keyboards shipped on several ASUS laptop models
    (including ROG laptop models such as GL702VMK) have the keyboards
    backlight controlled by the keyboard firmware.

    The firmware implements at least 3 different commands:
    - Init command (to use when the system starts)
    - Configuration command (to get keyboard status/information)
    - Backlight level control (to change the level of the keyboard light)

    With this patch we create the usual 'asus::kbd_backlight' led class
    entry to control the keyboard backlight.

    [jkosina@suse.cz: remove pointless cancel_work_sync() call while
    handling an error in asus_kbd_register_leds(), as spotted by
    Benjamin]

    Signed-off-by: Carlo Caione
    Reviewed-by: Benjamin Tissoires
    Signed-off-by: Jiri Kosina

    Carlo Caione
     

11 Apr, 2017

1 commit

  • This reverts commit 279967a65b320d174a507498aea7d44db3fee7f4.

    Multiple regressions [1] [2] [3] have been reported. The hid-rmi
    support would have to fixed and redone in 4.11+.

    [1] http://lkml.kernel.org/r/b79b88c8-770a-13f6-5668-c3a94254e5e0@gmail.com
    [2] http://lkml.kernel.org/r/375e67b5-2cb8-3491-1d71-d8650d6e9451@gmail.com
    [3] https://bugzilla.kernel.org/show_bug.cgi?id=195287

    Reported-by: Cameron Gutman
    Reported-by: Gabriele Mazzotta
    Reported-by: Lorenzo J. Lucchini
    Reported-by: Thorsten Leemhuis
    Signed-off-by: Jiri Kosina

    Jiri Kosina
     

06 Apr, 2017

18 commits