02 Nov, 2017

1 commit

  • Many source files in the tree are missing licensing information, which
    makes it harder for compliance tools to determine the correct license.

    By default all files without license information are under the default
    license of the kernel, which is GPL version 2.

    Update the files which contain no license information with the 'GPL-2.0'
    SPDX license identifier. The SPDX identifier is a legally binding
    shorthand, which can be used instead of the full boiler plate text.

    This patch is based on work done by Thomas Gleixner and Kate Stewart and
    Philippe Ombredanne.

    How this work was done:

    Patches were generated and checked against linux-4.14-rc6 for a subset of
    the use cases:
    - file had no licensing information it it.
    - file was a */uapi/* one with no licensing information in it,
    - file was a */uapi/* one with existing licensing information,

    Further patches will be generated in subsequent months to fix up cases
    where non-standard license headers were used, and references to license
    had to be inferred by heuristics based on keywords.

    The analysis to determine which SPDX License Identifier to be applied to
    a file was done in a spreadsheet of side by side results from of the
    output of two independent scanners (ScanCode & Windriver) producing SPDX
    tag:value files created by Philippe Ombredanne. Philippe prepared the
    base worksheet, and did an initial spot review of a few 1000 files.

    The 4.13 kernel was the starting point of the analysis with 60,537 files
    assessed. Kate Stewart did a file by file comparison of the scanner
    results in the spreadsheet to determine which SPDX license identifier(s)
    to be applied to the file. She confirmed any determination that was not
    immediately clear with lawyers working with the Linux Foundation.

    Criteria used to select files for SPDX license identifier tagging was:
    - Files considered eligible had to be source code files.
    - Make and config files were included as candidates if they contained >5
    lines of source
    - File already had some variant of a license header in it (even if
    Reviewed-by: Philippe Ombredanne
    Reviewed-by: Thomas Gleixner
    Signed-off-by: Greg Kroah-Hartman

    Greg Kroah-Hartman
     

08 Nov, 2016

1 commit

  • Commit 633a21d80b4a ("input: gpio_keys_polled: Add support for GPIO
    descriptors") placed gpio descriptor into gpio_keys_button structure, which
    is supposed to be part of platform data and not modifiable by the driver.
    To keep the data constant, let's move the descriptor to
    gpio_keys_button_data structure instead.

    Tested-by: Mika Westerberg
    Signed-off-by: Dmitry Torokhov

    Dmitry Torokhov
     

05 Nov, 2014

1 commit

  • GPIO descriptors are the preferred way over legacy GPIO numbers
    nowadays. Convert the driver to use GPIO descriptors internally but
    still allow passing legacy GPIO numbers from platform data to support
    existing platforms.

    Signed-off-by: Aaron Lu
    Signed-off-by: Mika Westerberg
    Acked-by: Alexandre Courbot
    Reviewed-by: Linus Walleij
    Acked-by: Dmitry Torokhov
    Acked-by: Grant Likely
    Signed-off-by: Rafael J. Wysocki

    Aaron Lu
     

15 May, 2014

1 commit


20 Mar, 2012

1 commit

  • Some of buttons, like power-on key or onkey, may only generate interrupts
    when pressed and not actually be mapped as gpio in the system. Allow
    setting gpio to invalid value and specify IRQ instead to support such
    keys. The debounce timer is used not to debounce but to ignore new IRQs
    coming while button is kept pressed.

    Signed-off-by: Laxman Dewangan
    Signed-off-by: Dmitry Torokhov

    Laxman Dewangan
     

02 Feb, 2012

1 commit


12 Apr, 2011

2 commits


07 Dec, 2010

1 commit

  • The existing gpio-keys driver can be usable only for GPIO lines with
    interrupt support. Several devices have buttons connected to a GPIO
    line which is not capable to generate interrupts. This patch adds a
    new input driver using the generic GPIO layer and the input-polldev
    to support such buttons.

    [Ben Gardiner
    Signed-off-by: Ben Gardiner
    Tested-by: Ben Gardiner
    Signed-off-by: Dmitry Torokhov

    Gabor Juhos
     

04 Aug, 2010

1 commit


04 Feb, 2010

1 commit

  • Now gpio-keys input driver exports 4 new attributes to userland through
    sysfs:
    /sys/devices/platform/gpio-keys/keys [ro]
    /sys/devices/platform/gpio-keys/switches [ro]
    /sys/devices/platform/gpio-keys/disabled_keys [rw]
    /sys/devices/platform/gpio-keys/disables_switches [rw]

    With these attributes, userland program can read which keys and
    switches can be disabled and then disable/enable them as needed.
    Keys and switches are exported as stringified bitmap of codes
    (keycodes or switch codes). For example keys 15, 89, 100, 101,
    102 are exported as: '15,89,100-102'.

    Description of the attributes:
    keys - bitmap of keys which can be disabled
    switches - bitmap of switches which can be disabled
    disabled_keys - bitmap of currently disabled keys
    (bit 1 means disabled, 0 enabled)
    disabled_switches - bitmap of currently disabled switches
    (bit 1 means disabled, 0 enabled)

    Signed-off-by: Mika Westerberg
    Signed-off-by: Dmitry Torokhov

    Mika Westerberg
     

28 Oct, 2008

1 commit


17 May, 2008

1 commit


26 Sep, 2007

1 commit


01 May, 2007

1 commit


05 Mar, 2007

1 commit

  • The gpio_keys driver is wrongly ARM-specific; it can't build on
    other platforms with GPIO suport. This fixes that problem.

    Signed-off-by: David Brownell
    Cc: Dmitry Torokhov
    Cc: pHilipp Zabel
    Cc: Haavard Skinnemoen
    Cc: Russell King
    Cc: Richard Purdie
    Cc: Ben Nizette
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    David Brownell