23 Aug, 2016

1 commit

  • The Kconfig currently controlling compilation of this code is:

    drivers/gpio/Kconfig:config GPIO_MSIC
    drivers/gpio/Kconfig: bool "Intel MSIC mixed signal gpio support"

    ...meaning that it currently is not being built as a module by anyone.

    Lets remove the couple traces of modular infrastructure use, so that
    when reading the driver there is no doubt it is builtin-only.

    We delete the MODULE_LICENSE tag etc. since all that information
    is already contained at the top of the file in the comments.

    We don't replace module.h with init.h since the file already has that.

    Cc: Alexandre Courbot
    Cc: Mathias Nyman
    Cc: linux-gpio@vger.kernel.org
    Signed-off-by: Paul Gortmaker
    Signed-off-by: Linus Walleij

    Paul Gortmaker
     

05 Jan, 2016

1 commit


27 Dec, 2015

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.

    Acked-by: Mathias Nyman
    Signed-off-by: Linus Walleij

    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
     

16 Sep, 2015

1 commit

  • Most interrupt flow handlers do not use the irq argument. Those few
    which use it can retrieve the irq number from the irq descriptor.

    Remove the argument.

    Search and replace was done with coccinelle and some extra helper
    scripts around it. Thanks to Julia for her help!

    Signed-off-by: Thomas Gleixner
    Cc: Julia Lawall
    Cc: Jiang Liu

    Thomas Gleixner
     

25 Jun, 2015

1 commit

  • Fix a race where a pending interrupt could be received and the handler
    called before the handler's data has been setup, by converting to
    irq_set_chained_handler_and_data().

    Search and conversion was done with coccinelle:

    @@
    expression E1, E2, E3;
    @@
    (
    -if (irq_set_chained_handler(E1, E3) != 0)
    - BUG();
    |
    -irq_set_chained_handler(E1, E3);
    )
    -irq_set_handler_data(E1, E2);
    +irq_set_chained_handler_and_data(E1, E3, E2);

    @@
    expression E1, E2, E3;
    @@
    (
    -if (irq_set_chained_handler(E1, E3) != 0)
    - BUG();
    ...
    |
    -irq_set_chained_handler(E1, E3);
    ...
    )
    -irq_set_handler_data(E1, E2);
    +irq_set_chained_handler_and_data(E1, E3, E2);

    Reported-by: Russell King
    Signed-off-by: Thomas Gleixner
    Cc: Julia Lawall
    Cc: Linus Walleij
    Cc: Alexandre Courbot
    Cc: linux-gpio@vger.kernel.org

    Thomas Gleixner
     

20 Oct, 2014

1 commit


04 Dec, 2013

1 commit

  • This switches the two members of struct gpio_chip that were
    defined as unsigned foo:1 to bool, because that is indeed what
    they are. Switch all users in the gpio and pinctrl subsystems
    to assign these values with true/false instead of 0/1. The
    users outside these subsystems will survive since true/false
    is 1/0, atleast we set some kind of more strict typing example.

    Signed-off-by: Linus Walleij

    Linus Walleij
     

03 Dec, 2013

1 commit

  • Switch all users of irq_set_chip_and_handler_name() to simply
    use irq_set_chip_and_handler(), all just provide a boilerplate
    name like "demux" or "mux" - a fact which is anyway obvious
    from the hwirq number from the irqdomain now present in e.g.
    /proc/interrupts.

    Cc: Mathias Nyman
    Cc: Dan Carpenter
    Acked-by: David Cohen
    Acked-by: Mika Westerberg
    Tested-by: Mika Westerberg
    Signed-off-by: Linus Walleij

    Linus Walleij
     

16 Aug, 2013

1 commit


29 Nov, 2012

1 commit

  • CONFIG_HOTPLUG is going away as an option so __devinit is no longer
    needed.

    Signed-off-by: Bill Pemberton
    Cc: Grant Likely
    Cc: Peter Tyser
    Cc: Santosh Shilimkar
    Cc: Kevin Hilman
    Acked-by: Linus Walleij
    Acked-by: Mark Brown
    Signed-off-by: Greg Kroah-Hartman

    Bill Pemberton
     

05 Aug, 2012

1 commit

  • In the case offset is 20 ... 23, the equation to get the register should be:
    INTEL_MSIC_GPIO1HV0CTLO - offset + 20

    With above equation, we can get below mapping between offset and the register:
    offset is 20: INTEL_MSIC_GPIO1HV0CTLO
    offset is 21: INTEL_MSIC_GPIO1HV1CTLO
    offset is 22: INTEL_MSIC_GPIO1HV2CTLO
    offset is 23: INTEL_MSIC_GPIO1HV3CTLO

    Signed-off-by: Axel Lin
    Acked-by: Mathias Nyman
    Signed-off-by: Linus Walleij

    Axel Lin
     

12 May, 2012

1 commit

  • Add gpio support for Intel MSIC chips found in Intel Medfield platforms.
    MSIC supports totally 24 GPIOs with 16 low voltage and 8 high voltage pins.
    Driver uses MSIC mfd interface for MSIC access.

    (Updated comment to indicate why locking is actually safe)

    Signed-off-by: Mathias Nyman
    Signed-off-by: Alan Cox
    Signed-off-by: Grant Likely

    Mathias Nyman