litmus-rt.git/drivers/pinctrl, branch test

pinctrl: Fix gpio/pin mapping for Meson8b

2015-05-19T09:40:52+00:00

The num_pins field in the struct meson_domain_data must include also the
missing pins in the Meson8b SoC, otherwise the GPIO <-> pin mapping is
broken on this platform. Avoid also the dinamic allocation for GPIOs.

Signed-off-by: Carlo Caione 
Signed-off-by: Linus Walleij

pinctrl: cygnus: fixed incorrect GPIO-pin mapping

2015-05-19T08:45:11+00:00

This patch fixes an incorrect GPIO-to-pin mapping in the Cygnus GPIO
driver

Signed-off-by: Ray Jui 
Signed-off-by: Linus Walleij

pinctrl: cherryview: Read triggering type from HW if not set when requested

2015-05-12T11:54:32+00:00

If a driver does not set interrupt triggering type when it calls
request_irq(), it means use the pin as the hardware/firmware has
configured it. There are some drivers doing this. One example is
drivers/input/serio/i8042.c that requests the interrupt like:

	error = request_irq(I8042_KBD_IRQ, i8042_interrupt, IRQF_SHARED,
			    "i8042", i8042_platform_device);

It assumes the interrupt is already properly configured. This is true in
case of interrupts connected to the IO-APIC. However, some Intel
Braswell/Cherryview based machines use a GPIO here instead for the internal
keyboard controller.

This is a problem because even if the pin/interrupt is properly configured,
the irqchip ->irq_set_type() will never be called as the triggering flags
are 0. Because of that we do not have correct interrupt flow handler set
for the interrupt.

Fix this by adding a custom ->irq_startup() that checks if the interrupt
has no triggering type set and in that case read the type directly from the
hardware and install correct flow handler along with the mapping.

Reported-by: Jagadish Krishnamoorthy 
Reported-by: Freddy Paul 
Signed-off-by: Mika Westerberg 
Signed-off-by: Linus Walleij

Merge tag 'gpio-v4.1-2' of git://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-gpio

2015-05-09T02:42:59+00:00

Pull GPIO fixes from Linus Walleij:
 "Here is a bunch of GPIO fixes that I collected since -rc1, nothing
  controversial, nothing special:

   - fix a memory leak for GPIO hotplug.

   - fix a signedness bug in the ACPI GPIO pin validation.

   - driver fixes: Qualcomm SPMI and OMAP MPUIO IRQ issues"

* tag 'gpio-v4.1-2' of git://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-gpio:
  gpio: omap: Fix regression for MPUIO interrupts
  gpio: sysfs: fix memory leaks and device hotplug
  pinctrl: qcom-spmi-gpio: Fix input value report
  pinctrl: qcom-spmi-gpio: Fix output type configuration
  gpiolib: change gpio pin from unsigned to signed in acpi callback

pinctrl: Don't just pretend to protect pinctrl_maps, do it for real

2015-05-06T14:24:28+00:00

Way back, when the world was a simpler place and there was no war, no
evil, and no kernel bugs, there was just a single pinctrl lock.  That
was how the world was when (57291ce pinctrl: core device tree mapping
table parsing support) was written.  In that case, there were
instances where the pinctrl mutex was already held when
pinctrl_register_map() was called, hence a "locked" parameter was
passed to the function to indicate that the mutex was already locked
(so we shouldn't lock it again).

A few years ago in (42fed7b pinctrl: move subsystem mutex to
pinctrl_dev struct), we switched to a separate pinctrl_maps_mutex.
...but (oops) we forgot to re-think about the whole "locked" parameter
for pinctrl_register_map().  Basically the "locked" parameter appears
to still refer to whether the bigger pinctrl_dev mutex is locked, but
we're using it to skip locks of our (now separate) pinctrl_maps_mutex.

That's kind of a bad thing(TM).  Probably nobody noticed because most
of the calls to pinctrl_register_map happen at boot time and we've got
synchronous device probing.  ...and even cases where we're
asynchronous don't end up actually hitting the race too often.  ...but
after banging my head against the wall for a bug that reproduced 1 out
of 1000 reboots and lots of looking through kgdb, I finally noticed
this.

Anyway, we can now safely remove the "locked" parameter and go back to
a war-free, evil-free, and kernel-bug-free world.

Fixes: 42fed7ba44e4 ("pinctrl: move subsystem mutex to pinctrl_dev struct")
Signed-off-by: Doug Anderson 
Signed-off-by: Linus Walleij

pinctrl: mediatek: mtk-common: initialize unmask

2015-05-04T13:20:22+00:00

cppcheck detected an uninitialized variable:

[drivers/pinctrl/mediatek/pinctrl-mtk-common.c:897]:
  (error) Uninitialized variable: unmask

unmask should be initialized to zero to ensure unmasking
only occurs if a previous mask occurred. The current situation
is that the unmask variable could contain any random garbage
causing random unexpected unmasking.

Signed-off-by: Colin Ian King 
Signed-off-by: Linus Walleij

pinctrl: qcom-spmi-mpp: Fix input value report

2015-04-28T12:52:50+00:00

Fix interpretation of the pmic_mpp_read() return code,
negative value means an error.

Signed-off-by: Ivan T. Ivanov 
Reviewed-by: Bjorn Andersson 
Signed-off-by: Linus Walleij

pinctrl: qcom-spmi-gpio: Fix input value report

2015-04-28T12:51:45+00:00

Read input buffer when input is enabled, not when it is
disabled. Also fix interpretation of the pmic_gpio_read()
return code, negative value means an error.

Signed-off-by: Ivan T. Ivanov 
Reviewed-by: Bjorn Andersson 
Signed-off-by: Linus Walleij

pinctrl: qcom-spmi-gpio: Fix output type configuration

2015-04-28T12:51:11+00:00

GPIO output type configuration was incorrectly overwritten
by strength value. Fix this.

Signed-off-by: Ivan T. Ivanov 
Acked-by: Bjorn Andersson 
Signed-off-by: Linus Walleij

pinctrl: qcom-spmi: Fix pin direction configuration

2015-04-27T13:33:42+00:00

Pin direction configuration was incorrectly overwritten
by output and function values in set_mux(). Fix this.

Signed-off-by: Ivan T. Ivanov 
Signed-off-by: Linus Walleij