13 Jan, 2019

1 commit

  • commit 7ed1c1901fe52e6c5828deb155920b44b0adabb1 upstream.

    Currently a number of Makefiles break when used with toolchains that
    pass extra flags in CC and other cross-compile related variables (such
    as --sysroot).

    Thus we get this error when we use a toolchain that puts --sysroot in
    the CC var:

    ~/src/linux/tools$ make iio
    [snip]
    iio_event_monitor.c:18:10: fatal error: unistd.h: No such file or directory
    #include
    ^~~~~~~~~~

    This occurs because we clobber several env vars related to
    cross-compiling with lines like this:

    CC = $(CROSS_COMPILE)gcc

    Although this will point to a valid cross-compiler, we lose any extra
    flags that might exist in the CC variable, which can break toolchains
    that rely on them (for example, those that use --sysroot).

    This easily shows up using a Yocto SDK:

    $ . [snip]/sdk/environment-setup-cortexa8hf-neon-poky-linux-gnueabi

    $ echo $CC
    arm-poky-linux-gnueabi-gcc -march=armv7-a -mfpu=neon -mfloat-abi=hard
    -mcpu=cortex-a8
    --sysroot=[snip]/sdk/sysroots/cortexa8hf-neon-poky-linux-gnueabi

    $ echo $CROSS_COMPILE
    arm-poky-linux-gnueabi-

    $ echo ${CROSS_COMPILE}gcc
    krm-poky-linux-gnueabi-gcc

    Although arm-poky-linux-gnueabi-gcc is a cross-compiler, we've lost the
    --sysroot and other flags that enable us to find the right libraries to
    link against, so we can't find unistd.h and other libraries and headers.
    Normally with the --sysroot flag we would find unistd.h in the sdk
    directory in the sysroot:

    $ find [snip]/sdk/sysroots -path '*/usr/include/unistd.h'
    [snip]/sdk/sysroots/cortexa8hf-neon-poky-linux-gnueabi/usr/include/unistd.h

    The perf Makefile adds CC = $(CROSS_COMPILE)gcc if and only if CC is not
    already set, and it compiles correctly with the above toolchain.

    So, generalize the logic that perf uses in the common Makefile and
    remove the manual CC = $(CROSS_COMPILE)gcc lines from each Makefile.

    Note that this patch does not fix cross-compile for all the tools (some
    have other bugs), but it does fix it for all except usb and acpi, which
    still have other unrelated issues.

    I tested both with and without the patch on native and cross-build and
    there appear to be no regressions.

    Link: http://lkml.kernel.org/r/20180107214028.23771-1-martin@martingkelly.com
    Signed-off-by: Martin Kelly
    Acked-by: Mark Brown
    Cc: Tejun Heo
    Cc: Li Zefan
    Cc: Johannes Weiner
    Cc: Linus Walleij
    Cc: "K. Y. Srinivasan"
    Cc: Haiyang Zhang
    Cc: Stephen Hemminger
    Cc: Jonathan Cameron
    Cc: Pali Rohar
    Cc: Richard Purdie
    Cc: Jacek Anaszewski
    Cc: Pavel Machek
    Cc: Peter Zijlstra
    Cc: Ingo Molnar
    Cc: Arnaldo Carvalho de Melo
    Cc: Robert Moore
    Cc: Lv Zheng
    Cc: "Rafael J. Wysocki"
    Cc: Greg Kroah-Hartman
    Cc: Valentina Manea
    Cc: Shuah Khan
    Cc: Mario Limonciello
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds
    Cc: Ignat Korchagin
    Signed-off-by: Greg Kroah-Hartman

    Martin Kelly
     

04 Feb, 2018

1 commit

  • 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

  • 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

  • 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

  • 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
     
  • 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

  • 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

  • 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

  • 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
     
  • 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

  • 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