Eric Lee / smarc-fsl-linux-kernel

15 Aug, 2017

1 commit

04 Oct, 2016

1 commit

29 Jun, 2016

1 commit

09 May, 2016

1 commit

19 Apr, 2016

1 commit

18 Jan, 2016

1 commit

  • 58cf279ac   Merge tag 'gpio-v4.5-1' of git://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-gpio ... Browse Code »

    Pull GPIO updates from Linus Walleij:
    "Here is the bulk of GPIO changes for v4.5.

    Notably there are big refactorings mostly by myself, aimed at getting
    the gpio_chip into a shape that makes me believe I can proceed to
    preserve state for a proper userspace ABI (character device) that has
    already been proposed once, but resulted in the feedback that I need
    to go back and restructure stuff. So I've been restructuring stuff.
    On the way I ran into brokenness (return code from the get_value()
    callback) and had to fix it. Also, refactored generic GPIO to be
    simpler.

    Some of that is still waiting to trickle down from the subsystems all
    over the kernel that provide random gpio_chips, I've touched every
    single GPIO driver in the kernel now, oh man I didn't know I was
    responsible for so much...

    Apart from that we're churning along as usual.

    I took some effort to test and retest so it should merge nicely and we
    shook out a couple of bugs in -next.

    Infrastructural changes:

    - In struct gpio_chip, rename the .dev node to .parent to better
    reflect the fact that this is not the GPIO struct device
    abstraction. We will add that soon so this would be totallt
    confusing.

    - It was noted that the driver .get_value() callbacks was sometimes
    reporting negative -ERR values to the gpiolib core, expecting them
    to be propagated to consumer gpiod_get_value() and gpio_get_value()
    calls. This was not happening, so as there was a mess of drivers
    returning negative errors and some returning "anything else than
    zero" to indicate that a line was active. As some would have bit
    31 set to indicate "line active" it clashed with negative error
    codes. This is fixed by the largeish series clamping values in all
    drivers with !!value to [0,1] and then augmenting the code to
    propagate error codes to consumers. (Includes some ACKed patches
    in other subsystems.)

    - Add a void *data pointer to struct gpio_chip. The container_of()
    design pattern is indeed very nice, but we want to reform the
    struct gpio_chip to be a non-volative, stateless business, and keep
    states internal to the gpiolib to be able to hold on to the state
    when adding a proper userspace ABI (character device) further down
    the road. To achieve this, drivers need a handle at the internal
    state that is not dependent on their struct gpio_chip() so we add
    gpiochip_add_data() and gpiochip_get_data() following the pattern
    of many other subsystems. All the "use gpiochip data pointer"
    patches transforms drivers to this scheme.

    - The Generic GPIO chip header has been merged into the general
    header, and the custom header for that
    removed. Instead of having a separate mm_gpio_chip struct for
    these generic drivers, merge that into struct gpio_chip,
    simplifying the code and removing the need for separate and
    confusing includes.

    Misc improvements:

    - Stabilize the way GPIOs are looked up from the ACPI legacy
    specification.

    - Incremental driver features for PXA, PCA953X, Lantiq (patches from
    the OpenWRT community), RCAR, Zynq, PL061, 104-idi-48

    New drivers:

    - Add a GPIO chip to the ALSA SoC AC97 driver.

    - Add a new Broadcom NSP SoC driver (this lands in the pinctrl dir,
    but the branch is merged here too to account for infrastructural
    changes).

    - The sx150x driver now supports the sx1502"

    * tag 'gpio-v4.5-1' of git://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-gpio: (220 commits)
    gpio: generic: make bgpio_pdata always visible
    gpiolib: fix chip order in gpio list
    gpio: mpc8xxx: Do not use gpiochip_get_data() in mpc8xxx_gpio_save_regs()
    gpio: mm-lantiq: Do not use gpiochip_get_data() in ltq_mm_save_regs()
    gpio: brcmstb: Allow building driver for BMIPS_GENERIC
    gpio: brcmstb: Set endian flags for big-endian MIPS
    gpio: moxart: fix build regression
    gpio: xilinx: Do not use gpiochip_get_data() in xgpio_save_regs()
    leds: pca9532: use gpiochip data pointer
    leds: tca6507: use gpiochip data pointer
    hid: cp2112: use gpiochip data pointer
    bcma: gpio: use gpiochip data pointer
    avr32: gpio: use gpiochip data pointer
    video: fbdev: via: use gpiochip data pointer
    gpio: pch: Optimize pch_gpio_get()
    Revert "pinctrl: lantiq: Implement gpio_chip.to_irq"
    pinctrl: nsp-gpio: use gpiochip data pointer
    pinctrl: vt8500-wmt: use gpiochip data pointer
    pinctrl: exynos5440: use gpiochip data pointer
    pinctrl: at91-pio4: use gpiochip data pointer
    ...

    Linus Torvalds
     

14 Jan, 2016

1 commit

  • fe0b48672   mfd: dm355evm_mps: Be sure to clamp return value ... Browse Code »

    As we want gpio_chip .get() calls to be able to return negative
    error codes and propagate to drivers, we need to go over all
    drivers and make sure their return values are clamped to [0,1].
    We do this by using the ret = !!(val) design pattern.

    Signed-off-by: Linus Walleij
    Signed-off-by: Lee Jones

    Linus Walleij
     

19 Nov, 2015

1 commit

  • 58383c784   gpio: change member .dev to .parent ... Browse Code »

    The name .dev in a struct is normally reserved for a struct device
    that is let us say a superclass to the thing described by the struct.
    struct gpio_chip stands out by confusingly using a struct device *dev
    to point to the parent device (such as a platform_device) that
    represents the hardware. As we want to give gpio_chip:s real devices,
    this is not working. We need to rename this member to parent.

    This was done by two coccinelle scripts, I guess it is possible to
    combine them into one, but I don't know such stuff. They look like
    this:

    @@
    struct gpio_chip *var;
    @@
    -var->dev
    +var->parent

    and:

    @@
    struct gpio_chip var;
    @@
    -var.dev
    +var.parent

    and:

    @@
    struct bgpio_chip *var;
    @@
    -var->gc.dev
    +var->gc.parent

    Plus a few instances of bgpio that I couldn't figure out how
    to teach Coccinelle to rewrite.

    This patch hits all over the place, but I *strongly* prefer this
    solution to any piecemal approaches that just exercise patch
    mechanics all over the place. It mainly hits drivers/gpio and
    drivers/pinctrl which is my own backyard anyway.

    Cc: Haavard Skinnemoen
    Cc: Rafał Miłecki
    Cc: Richard Purdie
    Cc: Mauro Carvalho Chehab
    Cc: Alek Du
    Cc: Jaroslav Kysela
    Cc: Takashi Iwai
    Acked-by: Dmitry Torokhov
    Acked-by: Greg Kroah-Hartman
    Acked-by: Lee Jones
    Acked-by: Jiri Kosina
    Acked-by: Hans-Christian Egtvedt
    Acked-by: Jacek Anaszewski
    Signed-off-by: Linus Walleij

    Linus Walleij
     

22 Jul, 2014

1 commit

31 Jul, 2013

1 commit

09 Jan, 2012

1 commit

01 Nov, 2011

1 commit

17 Sep, 2009

1 commit

  • 89a99e76f   mfd: Correct ro and cd implemantion on DM355 ... Browse Code »

    This patch corrects the support for MMCSD card detection
    and read only feature for SoC DM355.

    EVMDM355_ECP_VA4.pdf, from Spectrum digital, suggests that
    Bit 2 and 4 should be checked for card detection. However
    on the EVM, bits 1 and 3 gives this status, for MMC/SD
    instance 0 and 1 respectively. The pdf also suggests that
    Bit 1 and 3 should be checked for write protection. However
    on the EVM bits 2 and 4 gives this status.

    This document can be downloaded from
    http://c6000.spectrumdigital.com/evmdm355/reve/files/EVMDM355_ECP_VA4.pdf

    Signed-off-by: Vipin Bhandari
    Acked-by: David Brownell
    Signed-off-by: Kevin Hilman
    Signed-off-by: Samuel Ortiz

    Vipin Bhandari
     

29 Jun, 2009

1 commit

11 Jan, 2009

1 commit

04 Jan, 2009

1 commit

  • 0931a4c6d   mfd: dm355evm msp430 driver ... Browse Code »

    Basic MFD framework for the MSP430 microcontroller firmware used
    on the dm355evm board:

    - Provides an interface for other drivers: register read/write
    utilities, and register declarations.

    - Directly exports:
    * Many signals through the GPIO framework
    + LEDs
    + SW6 through gpio sysfs
    + NTSC/nPAL jumper through gpio sysfs
    + ... more could be added later, e.g. MMC signals
    * Child devices:
    + LEDs, via leds-gpio child (and default triggers)
    + RTC, via rtc-dm355evm child device
    + Buttons and IR control, via dm355evm_keys

    - Supports power-off system call. Use the reset button to power
    the board back up; the power supply LED will be on, but the
    MSP430 waits to re-activate the regulators.

    - On probe() this:
    * Announces firmware revision
    * Turns off the banked LEDs
    * Exports the resources noted above
    * Hooks the power-off support
    * Muxes tvp5146 -or- imager for video input

    Unless the new tvp514x driver (tracked for mainline) is configured,
    this assumes that some custom imager driver handles video-in.

    This completely ignores the registers reporting the output voltages
    on the various power supplies. Someone could add a hwmon interface
    if that seems useful.

    Signed-off-by: David Brownell
    Signed-off-by: Samuel Ortiz

    David Brownell