linux-toradex.git/drivers/gpio/gpio-intel-mid.c, branch v4.9.98

gpio: intel-mid: Fix build warning when !CONFIG_PM

2018-02-25T10:05:51+00:00

commit fbc2a294f29e726787a0f5238b27137904f26b81 upstream.

The only usage of function intel_gpio_runtime_idle() is here (in the
same file):

static const struct dev_pm_ops intel_gpio_pm_ops = {
	SET_RUNTIME_PM_OPS(NULL, NULL, intel_gpio_runtime_idle)
};

And when CONFIG_PM is not set, the macro SET_RUNTIME_PM_OPS expands to
nothing, causing the following compiler warning:

drivers/gpio/gpio-intel-mid.c:324:12: warning: ‘intel_gpio_runtime_idle’
defined but not used [-Wunused-function]
static int intel_gpio_runtime_idle(struct device *dev)

Fix it by annotating the function with __maybe_unused.

Signed-off-by: Augusto Mecking Caringi 
Acked-by: Andy Shevchenko 
Signed-off-by: Linus Walleij 
Signed-off-by: Greg Kroah-Hartman

gpio: intel-mid: Sort header block alphabetically

2016-07-22T13:30:40+00:00

Sort the header inclusion lines by alphabetical order.

While here, update Intel Copyright.

Signed-off-by: Andy Shevchenko 
Reviewed-by: Mika Westerberg 
Signed-off-by: Linus Walleij

gpio: intel-mid: Remove potentially harmful code

2016-07-22T13:30:40+00:00

The commit d56d6b3d7d69 ("gpio: langwell: add Intel Merrifield support")
doesn't look at all as a proper support for Intel Merrifield and I dare to say
that it distorts the behaviour of the hardware.

The register map is different on Intel Merrifield, i.e. only 6 out of 8
register have the same purpose but none of them has same location in the
address space. The current case potentially harmful to existing hardware since
it's poking registers on wrong offsets and may set some pin to be GPIO output
when connected hardware doesn't expect such.

Besides the above GPIO and pinctrl on Intel Merrifield have been located in
different IP blocks. The functionality has been extended as well, i.e. added
support of level interrupts, special registers for wake capable sources and
thus, in my opinion, requires a completele separate driver.

If someone wondering the existing gpio-intel-mid.c would be converted to actual
pinctrl (which by the fact it is now), though I wouldn't be a volunteer to do
that.

Fixes: d56d6b3d7d69 ("gpio: langwell: add Intel Merrifield support")
Cc: stable@vger.kernel.org # v3.13+
Signed-off-by: Andy Shevchenko 
Reviewed-by: Mika Westerberg 
Signed-off-by: Linus Walleij

gpio: intel-mid: switch to devm_gpiochip_add_data()

2016-06-23T09:07:13+00:00

The error handling is not correct since the commit 3f7dbfd8eea9 ("gpio:
intel-mid: switch to using gpiolib irqchip helpers"). Switch to devres API to
fix the potential resource leak.

Fixes: commit 3f7dbfd8eea9 ("gpio: intel-mid: switch to using gpiolib irqchip helpers")
Signed-off-by: Andy Shevchenko 
Signed-off-by: Linus Walleij

gpio: intel-mid: use gpiochip data pointer

2016-01-05T10:21:05+00:00

This makes the driver use the data pointer added to the gpio_chip
to store a pointer to the state container instead of relying on
container_of().

Cc: David Cohen 
Signed-off-by: Linus Walleij

gpio: intel-mid: Be sure to clamp return value

2015-12-26T21:28:09+00:00

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: David Cohen 
Signed-off-by: Linus Walleij

gpio: change member .dev to .parent

2015-11-19T08:24:35+00:00

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

genirq: Remove irq argument from irq flow handlers

2015-09-16T13:47:51+00:00

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

gpio: intel-mid: switch to using gpiolib irqchip helpers

2014-06-19T07:31:16+00:00

This switches the Intel MID GPIO driver over to using the gpiolib
irqchip helpers in the gpiolib core.

Cc: xinhui.pan 
Acked-by: David Cohen 
Signed-off-by: Linus Walleij

gpio: switch drivers to use new callback

2014-03-18T08:28:30+00:00

This switches all GPIO and pin control drivers with irqchips
that were using .startup() and .shutdown() callbacks to lock
GPIO lines for IRQ usage over to using the .request_resources()
and .release_resources() callbacks just introduced into the
irqchip vtable.

Cc: Thomas Gleixner 
Cc: Jean-Jacques Hiblot 
Signed-off-by: Linus Walleij