Skip to content

L
linux
Switch branch/tag
  1. 23 Jun, 2016 7 commits
  3. 18 Jun, 2016 2 commits
  5. 16 Jun, 2016 1 commit
    • Arnd Bergmann's avatar
      gpiolib: avoid uninitialized data in gpio kfifo · bc0207a5
      Arnd Bergmann authored 
      gcc reports a theoretical case for returning uninitialized data in
the kfifo when a GPIO interrupt happens and neither
GPIOEVENT_REQUEST_RISING_EDGE nor GPIOEVENT_REQUEST_FALLING_EDGE
are set:

drivers/gpio/gpiolib.c: In function 'lineevent_irq_thread':
drivers/gpio/gpiolib.c:683:87: error: 'ge.id' may be used uninitialized in this function [-Werror=maybe-uninitialized]

This case should not happen, but to be on the safe side, let's
return from the irq handler without adding data to the FIFO
to ensure we can never leak stack data to user space.
Signed-off-by: default avatarArnd Bergmann <arnd@arndb.de>
Fixes: 61f922db ("gpio: userspace ABI for reading GPIO line events")
Signed-off-by: default avatarLinus Walleij <linus.walleij@linaro.org>
      bc0207a5
  7. 15 Jun, 2016 6 commits
    • Linus Walleij's avatar
      tools/gpio: add the gpio-event-mon tool · 97f69747
      Linus Walleij authored 
      The gpio-event-mon is used from userspace as an example of how
to monitor GPIO line events. It will latch on to a certain
GPIO line on a certain gpiochip and print timestamped events
as they arrive.

Example output:
$ gpio-event-mon -n gpiochip2 -o 0 -r -f
Monitoring line 0 on gpiochip2
Initial line value: 1
GPIO EVENT 946685798487609863: falling edge
GPIO EVENT 946685798732482910: rising edge
GPIO EVENT 946685799115997314: falling edge
GPIO EVENT 946685799381469726: rising edge
Signed-off-by: default avatarLinus Walleij <linus.walleij@linaro.org>
      97f69747
    • Linus Walleij's avatar
      gpio: userspace ABI for reading GPIO line events · 61f922db
      Linus Walleij authored 
      This adds an ABI for listening to events on GPIO lines.
The mechanism returns an anonymous file handle to a request
to listen to a specific offset on a specific gpiochip.
To fetch the stream of events from the file handle, userspace
simply reads an event.

- Events can be requested with the same flags as ordinary
  handles, i.e. open drain or open source. An ioctl() call
  GPIO_GET_LINEEVENT_IOCTL is issued indicating the desired
  line.

- Events can be requested for falling edge events, rising
  edge events, or both.

- All events are timestamped using the kernel real time
  nanosecond timestamp (the same as is used by IIO).

- The supplied consumer label will appear in "lsgpio"
  listings of the lines, and in /proc/interrupts as the
  mechanism will request an interrupt from the gpio chip.

- Events are not supported on gpiochips that do not serve
  interrupts (no legal .to_irq() call). The event interrupt
  is threaded to avoid any realtime problems.

- It is possible to also directly read the current value
  of the registered GPIO line by issuing the same
  GPIOHANDLE_GET_LINE_VALUES_IOCTL as used by the
  line handles. Setting the value is not supported: we
  do not listen to events on output lines.

This ABI is strongly influenced by Industrial I/O and surpasses
the old sysfs ABI by providing proper precision timestamps,
making it possible to set flags like open drain, and put
consumer names on the GPIO lines.
Signed-off-by: default avatarLinus Walleij <linus.walleij@linaro.org>
      61f922db
    • Linus Walleij's avatar
      tools/gpio: add the gpio-hammer tool · 2a144dd0
      Linus Walleij authored 
      The gpio-hammer is used from userspace as an example of how
to retrieve a GPIO handle for one or several GPIO lines and
hammer the outputs from low to high and back again. It will
pulse the selected lines once per second for a specified
number of times or indefinitely if no loop count is
supplied.

Example output:
$ gpio-hammer -n gpiochip0 -o5 -o6 -o7
Hammer lines [5, 6, 7] on gpiochip0, initial states: [1, 1, 1]
[-] [5: 0, 6: 0, 7: 0]
Tested-by: default avatarMichael Welling <mwelling@ieee.org>
Signed-off-by: default avatarLinus Walleij <linus.walleij@linaro.org>
      2a144dd0
    • Linus Walleij's avatar
      gpio: userspace ABI for reading/writing GPIO lines · d7c51b47
      Linus Walleij authored 
      This adds a userspace ABI for reading and writing GPIO lines.
The mechanism returns an anonymous file handle to a request
to read/write n offsets from a gpiochip. This file handle
in turn accepts two ioctl()s: one that reads and one that
writes values to the selected lines.

- Handles can be requested as input/output, active low,
  open drain, open source, however when you issue a request
  for n lines with GPIO_GET_LINEHANDLE_IOCTL, they must all
  have the same flags, i.e. all inputs or all outputs, all
  open drain etc. If a granular control of the flags for
  each line is desired, they need to be requested
  individually, not in a batch.

- The GPIOHANDLE_GET_LINE_VALUES_IOCTL read ioctl() can be
  issued also to output lines to verify that the hardware
  is in the expected state.

- It reads and writes up to GPIOHANDLES_MAX lines at once,
  utilizing the .set_multiple() call in the driver if
  possible, making the call efficient if several lines
  can be written with a single register update.

The limitation of GPIOHANDLES_MAX to 64 lines is done under
the assumption that we may expect hardware that can issue a
transaction updating 64 bits at an instant but unlikely
anything larger than that.

ChangeLog v2->v3:
- Use gpiod_get_value_cansleep() so we support also slowpath
  GPIO drivers.
- Fix up the UAPI docs kerneldoc.
- Allocate the anonymous fd last, so that the release
  function don't get called until that point of something
  fails. After this point, skip the errorpath.
ChangeLog v1->v2:
- Handle ioctl_compat() properly based on a similar patch
  to the other ioctl() handling code.
- Use _IOWR() as we pass pointers both in and out of the
  ioctl()
- Use kmalloc() and kfree() for the linehandled, do not
  try to be fancy with devm_* it doesn't work the way I
  thought.
- Fix const-correctness on the linehandle name field.
Acked-by: default avatarMichael Welling <mwelling@ieee.org>
Signed-off-by: default avatarLinus Walleij <linus.walleij@linaro.org>
      d7c51b47
    • Andy Shevchenko's avatar
      gpio: pca953x: enable driver on Intel Edison · 747e42a1
      Andy Shevchenko authored 
      Intel Edison board has 4 GPIO expanders PCA9555a connected to I2C bus. Add an
ID to support them.
Signed-off-by: default avatarAndy Shevchenko <andriy.shevchenko@linux.intel.com>
Signed-off-by: default avatarLinus Walleij <linus.walleij@linaro.org>
      747e42a1
    • Rui Zhang's avatar
      gpio: acpi: add _DEP support for Acer One 10 · 3f86a635
      Rui Zhang authored 
      On Acer One 10, the ACPI battery driver can not be probed because
it depends on the GPIO controller as well as the I2C controller to work,
        Device (BATC)
        {
            Name (_HID, EisaId ("PNP0C0A") /* Control Method Battery */)
            ...
            Name (_DEP, Package (0x03)  // _DEP: Dependencies
            {
                I2C1,
                GPO2,
                GPO0
            })
            ...
        }

The I2C dependency also exists on other platforms and has been fixed by commit
40e7fcb1 ("ACPI: Add _DEP support to fix battery issue on Asus T100TA"),
this patch resolves the GPIO dependency for Acer One 10.

Link:https://bugzilla.kernel.org/show_bug.cgi?id=115191Tested-by: default avatarStace A. Zacharov <stace75@gmail.com>
Signed-off-by: default avatarZhang Rui <rui.zhang@intel.com>
Acked-by: default avatarMika Westerberg <mika.westerberg@linux.intel.com>
Acked-by: default avatarRafael J. Wysocki <rafael.j.wysocki@intel.com>
Signed-off-by: default avatarLinus Walleij <linus.walleij@linaro.org>
      3f86a635
  9. 14 Jun, 2016 2 commits
  11. 13 Jun, 2016 2 commits
  13. 08 Jun, 2016 16 commits
  15. 07 Jun, 2016 4 commits
    • Linus Walleij's avatar
      pinctrl: xway: use devm_gpiochip_add_data() · 86ede3d4
      Linus Walleij authored 
      Avoid a gpiochip_free() and use standard functions.

Cc: John Crispin <blogic@openwrt.org>
Cc: Pramod Gurav <pramod.gurav@smartplayin.com>
Cc: Martin Schiller <mschiller@tdt.de>
Signed-off-by: default avatarLinus Walleij <linus.walleij@linaro.org>
      86ede3d4
    • Andy Shevchenko's avatar
      gpio: pca953x: remove redundant assignments · 8c7a92da
      Andy Shevchenko authored 
      There are few redundant assignments of ret variable which is updated anyway.
Remove them for good.

While here, correct indentation of the constant definition and remove one empty
line.
Signed-off-by: default avatarAndy Shevchenko <andriy.shevchenko@linux.intel.com>
Signed-off-by: default avatarLinus Walleij <linus.walleij@linaro.org>
      8c7a92da
    • Linus Walleij's avatar
      hexagon: update TODO list · d4f80b81
      Linus Walleij authored 
      The symbol that will be selected when GPIO is implemented
for Hexagon will be GPIOLIB, we have removed
ARCH_REQUIRE_GPIOLIB and ARCH_WANT_OPTIONAL_GPIOLIB.

Cc: Michael Büsch <m@bues.ch>
Cc: Richard Kuo <rkuo@codeaurora.org>
Cc: linux-hexagon@vger.kernel.org
Signed-off-by: default avatarLinus Walleij <linus.walleij@linaro.org>
      d4f80b81
    • Kishon Vijay Abraham I's avatar
      gpio: pcf857x: restore the initial line state of all pcf lines · adc28475
      Kishon Vijay Abraham I authored 
      The reset values for all the PCF lines are high and hence on
shutdown we should drive all the lines high in order to
bring it to the reset state.

This is actually required since PCF doesn't have a reset
line and even after warm reset (by invoking "reboot" in
prompt) the PCF lines maintains it's previous programmed
state. This becomes a problem if the boards are designed to
work with the default initial state.

DRA7XX_evm uses PCF8575 and one of the PCF output lines
feeds to MMC/SD VDD and this line should be driven high in order
for the MMC/SD to be detected.  This line is modelled as
regulator and the hsmmc driver takes care of enabling and
disabling it. In the case of 'reboot', during shutdown path
as part of it's cleanup process the hsmmc driver disables
this regulator. This makes MMC *boot* not functional.

Fix it by driving all the pcf lines high.

This patch was sent long back
(https://patchwork.ozlabs.org/patch/420382/)
But there was a concern that contention might occur if the
PCF shutdown handler is invoked before the shutdown handler
of the PCF's consumers. In that case PCF shutdown handler can't
drive all the pcf lines high without knowing if the PCF
consumers are still active.

However commit 52cdbdd4 ("driver core: correct device's
shutdown order") will make sure shutdown handler of PCF's
consumers are invoked before invoking the shutdown
handler of PCF. So it should be safe to merge this now.
Signed-off-by: default avatarKishon Vijay Abraham I <kishon@ti.com>
Signed-off-by: default avatarSekhar Nori <nsekhar@ti.com>
Signed-off-by: default avatarLinus Walleij <linus.walleij@linaro.org>
      adc28475
GitLab Nexedi Edition | About GitLab | About Nexedi | 沪ICP备2021021310号-2 | 沪ICP备2021021310号-7