19 Apr, 2016

1 commit


09 Mar, 2016

1 commit

  • tps65010 driver's initcall cannot succeed when the driver is built-in,
    because it expects that the I2C probe is completed at initcall time;
    this cannot happen as MFD is initialized before I2C. Also on systems
    where the chip is not present there is unnecessary 30 ms delay during
    the boot.

    Instead of waiting for probe to finish, just register the I2C device.
    If some boards need retry mechanism for startup glitches, that should be
    done in the actual probe function. Also delete the driver banner message.

    The patch allows to use tps65010 again with OMAP1 (where it's required
    to be built-in) and enables e.g. USB and LED functionality on OMAP5912 OSK.

    Signed-off-by: Aaro Koskinen
    Signed-off-by: Lee Jones

    Aaro Koskinen
     

18 Jan, 2016

1 commit

  • 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

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

    This also start to propagate the negative error code from the
    smbus call if there is one, as the last commit of this series
    will make the gpiolib core deal with that properly.

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

    Linus Walleij
     

19 Nov, 2015

1 commit

  • 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
     

09 Apr, 2015

1 commit

  • Even if bus is not hot-pluggable, the devices can be unbound from the
    driver via sysfs, so we should not be using __exit annotations on
    remove() methods. The only exception is drivers registered with
    platform_driver_probe() which specifically disables sysfs bind/unbind
    attributes.

    Signed-off-by: Dmitry Torokhov
    Signed-off-by: Lee Jones

    Dmitry Torokhov
     

20 Aug, 2013

1 commit


15 Aug, 2013

1 commit


31 Jul, 2013

1 commit


19 Jul, 2012

1 commit

  • With the changes in the random tree, IRQF_SAMPLE_RANDOM is now a
    no-op; interrupt randomness is now collected unconditionally in a very
    low-overhead fashion; see commit 775f4b297b. The IRQF_SAMPLE_RANDOM
    flag was scheduled to be removed in 2009 on the
    feature-removal-schedule, so this patch is preparation for the final
    removal of this flag.

    Signed-off-by: "Theodore Ts'o"
    Cc: Samuel Ortiz

    Theodore Ts'o
     

14 Jan, 2011

1 commit


24 Dec, 2010

1 commit

  • flush_scheduled_work() is deprecated and scheduled to be removed.

    * In menelaus, flush menelaus->work directly on probe failure. Also,
    make sure the work isn't running on removal.

    * In tps65010, cancel_delayed_work() + flush_scheduled_work() ->
    cancel_delayed_work_sync(). While at it, remove unnecessary (void)
    casts on return value, and use schedule_delayed_work() and
    to_delayed_work() instead of using delayed_work's internal work
    field.

    Signed-off-by: Tejun Heo
    Cc: Samuel Ortiz

    Tejun Heo
     

03 Jun, 2010

1 commit

  • I2C drivers can use the clientdata-pointer to point to private data. As I2C
    devices are not really unregistered, but merely detached from their driver, it
    used to be the drivers obligation to clear this pointer during remove() or a
    failed probe(). As a couple of drivers forgot to do this, it was agreed that it
    was cleaner if the i2c-core does this clearance when appropriate, as there is
    no guarantee for the lifetime of the clientdata-pointer after remove() anyhow.
    This feature was added to the core with commit
    e4a7b9b04de15f6b63da5ccdd373ffa3057a3681 to fix the faulty drivers.

    As there is no need anymore to clear the clientdata-pointer, remove all current
    occurrences in the drivers to simplify the code and prevent confusion.

    Signed-off-by: Wolfram Sang
    Acked-by: Mark Brown
    Acked-by: Greg Kroah-Hartman
    Acked-by: Richard Purdie
    Acked-by: Dmitry Torokhov
    Signed-off-by: Jean Delvare

    Wolfram Sang
     

28 May, 2010

1 commit

  • Fix I2C-drivers which missed setting clientdata to NULL before freeing the
    structure it points to. Also fix drivers which do this _after_ the structure
    was freed already.

    Signed-off-by: Wolfram Sang
    Acked-by: Mark Brown
    Signed-off-by: Samuel Ortiz

    Wolfram Sang
     

14 Dec, 2009

2 commits

  • Add function to allow the configuation fo the VDCDC2 register by
    external users, to allow changing of the standard and low-power
    running modes.

    This is needed, for example, for the Simtec IM2440D20 where we need
    to use the low-power mode to shutdown the LDO/DCDC that are not needed
    during suspend (saving substantial power) and the runtime use of the
    low-power mode to change VCore.

    Signed-off-by: Ben Dooks
    Signed-off-by: Simtec Linux Team
    Signed-off-by: Samuel Ortiz

    Ben Dooks
     
  • If the board does not care where the TPS turns up, then specifiying the
    value -1 to get gpiolib to dynamically allocate the base for the chip
    is valid.

    Change the test to look for != 0, so that any boards specifying zero
    will not end up with gpio that they didn't want.

    Signed-off-by: Ben Dooks
    Signed-off-by: Simtec Liunx Team
    Signed-off-by: Samuel Ortiz

    Ben Dooks
     

04 Jan, 2009

1 commit

  • Move the tps65010 driver from drivers/i2c/chips to drivers/mfd
    since it's more of a multi-function device than anything else,
    and since Jean is trying to vanish drivers/i2c/chips ASAP.

    One way to think of these chips are as the PMIC family most
    used with OMAP1 generation chips.

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

    David Brownell