Skip to content

L
linux
Switch branch/tag
  1. 13 Dec, 2018 1 commit
    • Linus Walleij's avatar
      Merge tag 'intel-pinctrl-v4.21-1' of... · f836b944
      Linus Walleij authored 
      Merge tag 'intel-pinctrl-v4.21-1' of git://git.kernel.org/pub/scm/linux/kernel/git/pinctrl/intel into devel

intel-pinctrl for v4.21-1

Switch to generic ->probe() callbacks.
Simplify getting .driver_data.
Code formatting fixes and headers clean up.

Special case is the driver for Intel Cherryview SoC, where GPIO enabling bit
was mistakenly cleared when pin gets freed. It's fixed now.

The below commit went to v4.20-rc3, that's why duplication.

- ad774315 MAINTAINERS: Add tree link for Intel pin control driver

The following is an automated git shortlog grouped by driver:

baytrail:
 -  Code formatting fixes
 -  simplify getting .driver_data

broxton:
 -  Code formatting fixes
 -  Get rid of unneeded ->probe() stub

cannonlake:
 -  Code formatting fixes
 -  Get rid of unneeded ->probe() stub

cedarfork:
 -  Replace acpi.h with mod_devicetable.h
 -  Get rid of unneeded ->probe() stub

cherryview:
 -  Stop clearing the GPIO_EN bit from chv_gpio_disable_free
 -  Add chv_gpio_clear_triggering() helper function
 -  simplify getting .driver_data

denverton:
 -  Replace acpi.h with mod_devicetable.h
 -  Get rid of unneeded ->probe() stub

geminilake:
 -  Code formatting fixes

icelake:
 -  Code formatting fixes
 -  Get rid of unneeded ->probe() stub

intel:
 -  Unexport intel_pinctrl_probe()
 -  simplify getting .driver_data

lewisburg:
 -  Replace acpi.h with mod_devicetable.h
 -  Get rid of unneeded ->probe() stub

MAINTAINERS:
 -  Add tree link for Intel pin control driver

merrifield:
 -  include bits.h instead of bitops.h

sunrisepoint:
 -  Get rid of unneeded ->probe() stub
      f836b944
  3. 07 Dec, 2018 6 commits
  5. 05 Dec, 2018 3 commits
    • Nicholas Mc Guire's avatar
      pinctrl: nuvoton: check for devm_kasprintf() failure · 4be1eaf3
      Nicholas Mc Guire authored 
      devm_kasprintf() may return NULL on failure of internal allocation thus
the assignment to  .label  is not safe if not checked. On error
npcm7xx_gpio_of() returns negative values so -ENOMEM in the
(unlikely) failure case of devm_kasprintf() should be fine here.
Signed-off-by: default avatarNicholas Mc Guire <hofrat@osadl.org>
Fixes: 3b588e43 ("pinctrl: nuvoton: add NPCM7xx pinctrl and GPIO driver")
Signed-off-by: default avatarLinus Walleij <linus.walleij@linaro.org>
      4be1eaf3
    • Hans de Goede's avatar
      pinctrl: cherryview: Stop clearing the GPIO_EN bit from chv_gpio_disable_free · 1adde32a
      Hans de Goede authored 
      Clearing the GPIO_EN bit from chv_gpio_disable_free is a bad idea and
pinctrl-cherryview.c is the only Intel pinctrl driver doing something
like this.

Clearing the GPIO_EN bit means that if the pin was an output it is now
effectively floating. The datasheet is not clear what happens to pull ups /
downs in this case, but from testing it looks like these are disabled too,
also floating input pins.

One example where this is causing issues is the soc_button_array input
driver, this parses ACPI tables to create 2 platform devices for the
gpio_keys input driver. The list of GPIOs is passed through struct
gpio_keys_platform_data which uses gpio numbers rather then gpio_desc
pointers.

The buttons handled by this drivers short the pin to ground when pressed
and the volume buttons rely on the SoC's internal pull-up to pull the
pin high when the button is not pressed.

To get the gpio number, the soc_button_array code calls gpiod_get_index
followed by a desc_to_gpio call and then gpiod_put on the gpio_desc.
This last call causes chv_gpio_disable_free to clear the GPIO_EN bit.

When the gpio_keys driver then loads next it gets the gpio_desc again
causing the GPIO_EN bit to be set again and immediately reads the GPIO
value which for the volume buttons reads 0 at this time, causing a spurious
press of the volume buttons to get reported.

Putting a small delay between the gpio_desc request and the read fixes
this, I assume that this is caused by the pull-up being temporarily
disabled while the GPIO_EN bit is cleared as the powerbutton which also
has its GPIO_EN bit cleared does not have this problem.

The soc_button_array code is not the only code temporarily requesting GPIOs
the DWC3 PCI code also does this, to set the enable and reset GPIOs for the
external phy, so that the code instantiating the ULPI phy can read the
vendor and product ID registers from the phy. These GPIOs are released
after this so that the PHY driver can claim and use them when it loads.

Another example of temporary GPIO usage would be a user-space set_gpio
utility using the userspace ioctls to set a GPIO as output value 0 or 1,
having the GPIO revert to floating as soon as this utility exits would
certainly be unexpected behavior.

One argument in favor of clearing the GPIO_EN bit is if the GPIO is going
to be muxed to another function after being released, but in that case
chv_pinmux_set_mux() already clears it.

TL;DR: Clearing the GPIO_EN bit from is a bad idea, this commit therefor
removes the clearing from chv_gpio_disable_free(), replacing it with code
to clear the interrupt-trigger condition so that the GPIO stops generating
interrupts when released, as pinctrl-baytrail.c does.

Note this commit adds a !chv_pad_locked() condition to the trigger clearing
call, which the original GPIO_EN clearing code was missing.
Signed-off-by: default avatarHans de Goede <hdegoede@redhat.com>
Acked-by: default avatarMika Westerberg <mika.westerberg@linux.intel.com>
Signed-off-by: default avatarAndy Shevchenko <andriy.shevchenko@linux.intel.com>
      1adde32a
    • Hans de Goede's avatar
      pinctrl: cherryview: Add chv_gpio_clear_triggering() helper function · b6fb6e11
      Hans de Goede authored 
      This is a preparation patch for clearing the interrupt trigger from
chv_gpio_disable_free().
Signed-off-by: default avatarHans de Goede <hdegoede@redhat.com>
Acked-by: default avatarMika Westerberg <mika.westerberg@linux.intel.com>
Signed-off-by: default avatarAndy Shevchenko <andriy.shevchenko@linux.intel.com>
      b6fb6e11
  7. 04 Dec, 2018 2 commits
  9. 26 Nov, 2018 2 commits
  11. 25 Nov, 2018 3 commits
  13. 23 Nov, 2018 2 commits
  15. 20 Nov, 2018 1 commit
  17. 19 Nov, 2018 20 commits
GitLab Nexedi Edition | About GitLab | About Nexedi | 沪ICP备2021021310号-2 | 沪ICP备2021021310号-7