Eric Lee / smarc-fsl-linux-kernel

04 Feb, 2018

1 commit

  • 636124c86   tools/gpio: Fix build error with musl libc ... Browse Code »

    commit 1696784eb7b52b13b62d160c028ef2c2c981d4f2 upstream.

    The GPIO tools build fails when using a buildroot toolchain that uses musl
    as it's C library:

    arm-broomstick-linux-musleabi-gcc -Wp,-MD,./.gpio-event-mon.o.d \
    -Wp,-MT,gpio-event-mon.o -O2 -Wall -g -D_GNU_SOURCE \
    -Iinclude -D"BUILD_STR(s)=#s" -c -o gpio-event-mon.o gpio-event-mon.c
    gpio-event-mon.c:30:6: error: unknown type name ‘u_int32_t’; did you mean ‘uint32_t’?
    u_int32_t handleflags,
    ^~~~~~~~~
    uint32_t

    The glibc headers installed on my laptop include sys/types.h in
    unistd.h, but it appears that musl does not.

    Fixes: 97f69747d8b1 ("tools/gpio: add the gpio-event-mon tool")
    Signed-off-by: Joel Stanley
    Signed-off-by: Linus Walleij
    Signed-off-by: Greg Kroah-Hartman

    Joel Stanley
     

02 Nov, 2017

1 commit

  • b24413180   License cleanup: add SPDX GPL-2.0 license identifier to files with no license ... Browse Code »

    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
     

26 Jan, 2017

1 commit

11 Jan, 2017

1 commit

18 Dec, 2016

1 commit

  • 41e0e24b4   Merge branch 'kbuild' of git://git.kernel.org/pub/scm/linux/kernel/git/mmarek/kbuild ... Browse Code »

    Pull kbuild updates from Michal Marek:

    - prototypes for x86 asm-exported symbols (Adam Borowski) and a warning
    about missing CRCs (Nick Piggin)

    - asm-exports fix for LTO (Nicolas Pitre)

    - thin archives improvements (Nick Piggin)

    - linker script fix for CONFIG_LD_DEAD_CODE_DATA_ELIMINATION (Nick
    Piggin)

    - genksyms support for __builtin_va_list keyword

    - misc minor fixes

    * 'kbuild' of git://git.kernel.org/pub/scm/linux/kernel/git/mmarek/kbuild:
    x86/kbuild: enable modversions for symbols exported from asm
    kbuild: fix scripts/adjust_autoksyms.sh* for the no modules case
    scripts/kallsyms: remove last remnants of --page-offset option
    make use of make variable CURDIR instead of calling pwd
    kbuild: cmd_export_list: tighten the sed script
    kbuild: minor improvement for thin archives build
    kbuild: modpost warn if export version crc is missing
    kbuild: keep data tables through dead code elimination
    kbuild: improve linker compatibility with lib-ksyms.o build
    genksyms: Regenerate parser
    kbuild/genksyms: handle va_list type
    kbuild: thin archives for multi-y targets
    kbuild: kallsyms allow 3-pass generation if symbols size has changed

    Linus Torvalds
     

11 Dec, 2016

1 commit

24 Oct, 2016

2 commits

08 Aug, 2016

1 commit

23 Jun, 2016

2 commits

15 Jun, 2016

2 commits

  • 97f69747d   tools/gpio: add the gpio-event-mon tool ... Browse Code »

    The gpio-event-mon is used from userspace as an example of how
    to monitor GPIO line events. It will latch on to a certain
    GPIO line on a certain gpiochip and print timestamped events
    as they arrive.

    Example output:
    $ gpio-event-mon -n gpiochip2 -o 0 -r -f
    Monitoring line 0 on gpiochip2
    Initial line value: 1
    GPIO EVENT 946685798487609863: falling edge
    GPIO EVENT 946685798732482910: rising edge
    GPIO EVENT 946685799115997314: falling edge
    GPIO EVENT 946685799381469726: rising edge

    Signed-off-by: Linus Walleij

    Linus Walleij
     
  • 2a144dd09   tools/gpio: add the gpio-hammer tool ... Browse Code »

    The gpio-hammer is used from userspace as an example of how
    to retrieve a GPIO handle for one or several GPIO lines and
    hammer the outputs from low to high and back again. It will
    pulse the selected lines once per second for a specified
    number of times or indefinitely if no loop count is
    supplied.

    Example output:
    $ gpio-hammer -n gpiochip0 -o5 -o6 -o7
    Hammer lines [5, 6, 7] on gpiochip0, initial states: [1, 1, 1]
    [-] [5: 0, 6: 0, 7: 0]

    Tested-by: Michael Welling
    Signed-off-by: Linus Walleij

    Linus Walleij
     

31 Mar, 2016

2 commits

26 Feb, 2016

1 commit

  • 214338e37   gpio: present the consumer of a line to userspace ... Browse Code »

    I named the field representing the current user of GPIO line as
    "label" but this is too vague and ambiguous. Before anyone gets
    confused, rename it to "consumer" and indicate clearly in the
    documentation that this is a string set by the user of the line.

    Also clean up leftovers in the documentation.

    Signed-off-by: Linus Walleij

    Linus Walleij
     

23 Feb, 2016

1 commit

  • bb91d345b   tools: gpio: Small updates for output format ... Browse Code »

    Use %2d for the GPIO line number. This should align the results
    horziontally for most gpio chips.

    The GPIO label uses quotes for real values. For GPIO names this is
    currently missing. The patch adds the missing quote.

    Signed-off-by: Markus Pargmann
    Signed-off-by: Linus Walleij

    Markus Pargmann
     

19 Feb, 2016

2 commits

  • 521a2ad6f   gpio: add userspace ABI for GPIO line information ... Browse Code »

    This adds a GPIO line ABI for getting name, label and a few select
    flags from the kernel.

    This hides the kernel internals and only tells userspace what it
    may need to know: the different in-kernel consumers are masked
    behind the flag "kernel" and that is all userspace needs to know.

    However electric characteristics like active low, open drain etc
    are reflected to userspace, as this is important information.

    We provide information on all lines on all chips, later on we will
    likely add a flag for the chardev consumer so we can filter and
    display only the lines userspace actually uses in e.g. lsgpio,
    but then we first need an ABI for userspace to grab and use
    (get/set/select direction) a GPIO line.

    Sample output from "lsgpio" on ux500:

    GPIO chip: gpiochip7, "8011e000.gpio", 32 GPIO lines
    line 0: unnamed unlabeled
    line 1: unnamed unlabeled
    (...)
    line 25: unnamed "SFH7741 Proximity Sensor" [kernel output open-drain]
    line 26: unnamed unlabeled
    (...)

    Tested-by: Michael Welling
    Signed-off-by: Linus Walleij

    Linus Walleij
     
  • df4878e96   gpio: store reflect the label to userspace ... Browse Code »

    The gpio_chip label is useful for userspace to understand what
    kind of GPIO chip it is dealing with. Let's store a copy of this
    label in the gpio_device, add it to the struct passed to userspace
    for GPIO_GET_CHIPINFO_IOCTL and modify lsgpio to show it.

    Signed-off-by: Linus Walleij

    Linus Walleij
     

09 Feb, 2016

1 commit

  • 6d591c46b   tools/gpio: create GPIO tools ... Browse Code »

    This creates GPIO tools under tools/gpio/* and adds a single
    example program to list the GPIOs on a system. When proper
    devices are created it provides this minimal output:

    Cc: Johan Hovold
    Cc: Michael Welling
    Cc: Markus Pargmann
    Signed-off-by: Linus Walleij

    Linus Walleij