1. 19 Aug, 2019 1 commit
  2. 07 Jun, 2019 1 commit
    • Linus Walleij's avatar
      gpio: pass lookup and descriptor flags to request_own · 5923ea6c
      Linus Walleij authored
      When a gpio_chip wants to request a descriptor from itself
      using gpiochip_request_own_desc() it needs to be able to specify
      fully how to use the descriptor, notably line inversion
      semantics. The workaround in the gpiolib.c can be removed
      and cases (such as SPI CS) where we need at times to request
      a GPIO with line inversion semantics directly on a chip for
      workarounds, can be fully supported with this call.
      
      Fix up some users of the API that weren't really using the
      last flag to set up the line as input or output properly
      but instead just calling direction setting explicitly
      after requesting the line.
      
      Cc: Martin Sperl <kernel@martin.sperl.org>
      Signed-off-by: default avatarLinus Walleij <linus.walleij@linaro.org>
      5923ea6c
  3. 05 Jun, 2019 1 commit
  4. 14 Dec, 2018 1 commit
  5. 21 Nov, 2017 1 commit
    • Eudean Sun's avatar
      HID: cp2112: Fix I2C_BLOCK_DATA transactions · 542134c0
      Eudean Sun authored
      The existing driver erroneously treats I2C_BLOCK_DATA and BLOCK_DATA
      commands the same.
      
      For I2C_BLOCK_DATA reads, the length of the read is provided in
      data->block[0], but the length itself should not be sent to the slave. In
      contrast, for BLOCK_DATA reads no length is specified since the length
      will be the first byte returned from the slave. When copying data back
      to the data buffer, for an I2C_BLOCK_DATA read we have to take care not to
      overwrite data->block[0] to avoid overwriting the length. A BLOCK_DATA
      read doesn't have this concern since the first byte returned by the device
      is the length and belongs in data->block[0].
      
      For I2C_BLOCK_DATA writes, the length is also provided in data->block[0],
      but the length itself is not sent to the slave (in contrast to BLOCK_DATA
      writes where the length prefixes the data sent to the slave).
      
      This was tested on physical hardware using i2cdump with the i and s flags
      to test the behavior of I2C_BLOCK_DATA reads and BLOCK_DATA reads,
      respectively. Writes were not tested but the I2C_BLOCK_DATA write change
      is pretty simple to verify by inspection.
      Signed-off-by: default avatarEudean Sun <eudean@arista.com>
      Signed-off-by: default avatarJiri Kosina <jkosina@suse.cz>
      542134c0
  6. 10 Nov, 2017 2 commits
  7. 21 Mar, 2017 1 commit
  8. 31 Jan, 2017 2 commits
  9. 28 Nov, 2016 1 commit
  10. 23 Nov, 2016 1 commit
  11. 06 Jan, 2016 1 commit
  12. 28 Dec, 2015 1 commit
  13. 19 Nov, 2015 1 commit
    • Linus Walleij's avatar
      gpio: change member .dev to .parent · 58383c78
      Linus Walleij authored
      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 <hskinnemoen@gmail.com>
      Cc: Rafał Miłecki <zajec5@gmail.com>
      Cc: Richard Purdie <rpurdie@rpsys.net>
      Cc: Mauro Carvalho Chehab <mchehab@osg.samsung.com>
      Cc: Alek Du <alek.du@intel.com>
      Cc: Jaroslav Kysela <perex@perex.cz>
      Cc: Takashi Iwai <tiwai@suse.com>
      Acked-by: default avatarDmitry Torokhov <dmitry.torokhov@gmail.com>
      Acked-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      Acked-by: default avatarLee Jones <lee.jones@linaro.org>
      Acked-by: default avatarJiri Kosina <jkosina@suse.cz>
      Acked-by: default avatarHans-Christian Egtvedt <egtvedt@samfundet.no>
      Acked-by: default avatarJacek Anaszewski <j.anaszewski@samsung.com>
      Signed-off-by: default avatarLinus Walleij <linus.walleij@linaro.org>
      58383c78
  14. 14 Jul, 2015 2 commits
  15. 10 Jul, 2015 1 commit
    • Ellen Wang's avatar
      HID: cp2112: support i2c write-read transfers in hid-cp2112 · 44eda784
      Ellen Wang authored
      cp2112_i2c_xfer() only supports a single i2c_msg.  More than
      one message at a time just returns EIO.  This breaks certain
      important cases.  For example, the at24 eeprom driver generates
      paired write and read messages (for eeprom address and data).
      
      Since the device doesn't support i2c repeated starts in general,
      but does support a single write-repeated-start-read pair
      (since hardware rev 1), we recognize the latter case and
      implement only that.
      Signed-off-by: default avatarEllen Wang <ellen@cumulusnetworks.com>
      Signed-off-by: default avatarJiri Kosina <jkosina@suse.com>
      44eda784
  16. 09 Jul, 2015 1 commit
  17. 08 Jul, 2015 1 commit
  18. 18 Sep, 2014 1 commit
  19. 29 Jul, 2014 1 commit
  20. 07 Jul, 2014 1 commit
    • Antonio Borneo's avatar
      HID: cp2112: fix gpio value in gpio_direction_output · beb9d007
      Antonio Borneo authored
      CP2112 does not offer an atomic method to set both gpio
      direction and value.
      Also it does not permit to set gpio value before putting
      gpio in output. In fact, accordingly to Silicon Labs
      AN495, Rev. 0.2, cpt. 4.4, the HID report to set gpio
      values "does not affect any pins that are not configured
      as outputs".
      
      This is confirmed on evaluation board CP2112-EK.
      With current driver, after execute:
      	echo in > /sys/class/gpio/gpio248/direction
      	echo low > /sys/class/gpio/gpio248/direction
      gpio output is still high. Only after a following
      	echo low > /sys/class/gpio/gpio248/direction
      gpio output gets low.
      
      Fix driver by changing order of operations; first set
      direction then set value.
      
      The drawback of this new sequence is that we can have
      a pulse on gpio pin when direction is changed from
      input to output-low, but this cannot be avoided on
      current CP2112.
      Signed-off-by: default avatarAntonio Borneo <borneo.antonio@gmail.com>
      Reviewed-by: default avatarBenjamin Tissoires <benjamin.tissoires@redhat.com>
      Signed-off-by: default avatarJiri Kosina <jkosina@suse.cz>
      beb9d007
  21. 14 Mar, 2014 2 commits
  22. 18 Feb, 2014 1 commit
  23. 17 Feb, 2014 4 commits