1. 16 6月, 2020 2 次提交
    • A
      gpio: pca953x: Override IRQ for one of the expanders on Galileo Gen 2 · ba8c90c6
      Andy Shevchenko 提交于
      ACPI table on Intel Galileo Gen 2 has wrong pin number for IRQ resource
      of one of the I²C GPIO expanders. Since we know what that number is and
      luckily have GPIO bases fixed for SoC's controllers, we may use a simple
      DMI quirk to match the platform and retrieve GpioInt() pin on it for
      the expander in question.
      
      Mika suggested the way to avoid a quirk in the GPIO ACPI library and
      here is the second, almost rewritten version of it.
      
      Fixes: f32517bf ("gpio: pca953x: support ACPI devices found on Galileo Gen2")
      Depends-on: 25e3ef89 ("gpio: acpi: Split out acpi_gpio_get_irq_resource() helper")
      Suggested-by: NMika Westerberg <mika.westerberg@linux.intel.com>
      Reviewed-by: NMika Westerberg <mika.westerberg@linux.intel.com>
      Signed-off-by: NAndy Shevchenko <andriy.shevchenko@linux.intel.com>
      Signed-off-by: NBartosz Golaszewski <bgolaszewski@baylibre.com>
      ba8c90c6
    • A
      gpio: pca953x: Synchronize interrupt handler properly · 064c73af
      Andy Shevchenko 提交于
      Since the commit aa58a21a ("gpio: pca953x: disable regmap locking")
      the locking of regmap is disabled and that immediately introduces
      a synchronization issue. It's easy to see when we try to monitor
      more than one interrupt from the same chip.
      
      It seems that the problem exists from the day one and even commit
      6e20fb18 ("drivers/gpio/pca953x.c: add a mutex to fix race condition")
      missed this.
      
      Below are the traces and shell reproducers before and after proposed change.
      Note duplicates in the IRQ events. /proc/interrupts also shows a deviation,
      i.e. sum of children interrupts higher than parent's one.
      
      When locking is disabled for regmap and no protection in IRQ handler
      ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
       ...
       gpioset-194          regmap_hw_write_start: i2c-INT3491:02 reg=2 count=1
       irq/31-i2c-INT3-139  regmap_hw_read_start: i2c-INT3491:02 reg=4c count=2
       gpioset-194          regmap_hw_write_done: i2c-INT3491:02 reg=2 count=1
       gpioset-194          regmap_reg_read_cache: i2c-INT3491:02 reg=6 val=f5
       gpioset-194          regmap_reg_write: i2c-INT3491:02 reg=6 val=f5
       gpioset-194          regmap_hw_write_start: i2c-INT3491:02 reg=6 count=1
       irq/31-i2c-INT3-139  regmap_hw_read_done: i2c-INT3491:02 reg=4c count=2
       ...
      
       % gpiomon gpiochip3 0 &
       % gpioset gpiochip3 1=0
       % gpioset gpiochip3 1=1
       event:  RISING EDGE offset: 0 timestamp: [     302.782583765]
       % gpiomon gpiochip3 2 &
       % gpioset gpiochip3 1=0
       event:  RISING EDGE offset: 2 timestamp: [     312.033148829]
       event: FALLING EDGE offset: 0 timestamp: [     312.022757525]
       % gpioset gpiochip3 1=1
       event:  RISING EDGE offset: 2 timestamp: [     316.201148473]
       event:  RISING EDGE offset: 0 timestamp: [     316.191759599]
      
      When locking is disabled for regmap and protection in IRQ handler
      ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
       ...
       gpioset-202          regmap_hw_write_start: i2c-INT3491:02 reg=2 count=1
       gpioset-202          regmap_hw_write_done: i2c-INT3491:02 reg=2 count=1
       gpioset-202          regmap_reg_read_cache: i2c-INT3491:02 reg=6 val=fd
       gpioset-202          regmap_reg_write: i2c-INT3491:02 reg=6 val=fd
       gpioset-202          regmap_hw_write_start: i2c-INT3491:02 reg=6 count=1
       gpioset-202          regmap_hw_write_done: i2c-INT3491:02 reg=6 count=1
       irq/31-i2c-INT3-139  regmap_hw_read_start: i2c-INT3491:02 reg=4c count=2
       irq/31-i2c-INT3-139  regmap_hw_read_done: i2c-INT3491:02 reg=4c count=2
       ...
      
       % gpiomon gpiochip3 0 &
       % gpioset gpiochip3 1=0
       event: FALLING EDGE offset: 0 timestamp: [     531.330078107]
       % gpioset gpiochip3 1=1
       event:  RISING EDGE offset: 0 timestamp: [     532.912239128]
       % gpiomon gpiochip3 2 &
       % gpioset gpiochip3 1=0
       event: FALLING EDGE offset: 0 timestamp: [     539.633669484]
       % gpioset gpiochip3 1=1
       event:  RISING EDGE offset: 0 timestamp: [     542.256978461]
      
      Fixes: 6e20fb18 ("drivers/gpio/pca953x.c: add a mutex to fix race condition")
      Depends-on: 35d13d94 ("gpio: pca953x: convert to use bitmap API")
      Depends-on: 49427232 ("gpio: pca953x: Perform basic regmap conversion")
      Cc: Marek Vasut <marek.vasut@gmail.com>
      Cc: Roland Stigge <stigge@antcom.de>
      Signed-off-by: NAndy Shevchenko <andriy.shevchenko@linux.intel.com>
      Signed-off-by: NBartosz Golaszewski <bgolaszewski@baylibre.com>
      064c73af
  2. 03 6月, 2020 1 次提交
  3. 29 4月, 2020 3 次提交
  4. 23 4月, 2020 1 次提交
  5. 17 4月, 2020 1 次提交
  6. 16 4月, 2020 1 次提交
  7. 11 12月, 2019 3 次提交
  8. 05 12月, 2019 5 次提交
  9. 07 11月, 2019 1 次提交
  10. 28 8月, 2019 2 次提交
  11. 02 8月, 2019 4 次提交
  12. 08 6月, 2019 1 次提交
    • H
      gpio: pca953x: hack to fix 24 bit gpio expanders · 3b00691c
      H. Nikolaus Schaller 提交于
      24 bit expanders use REG_ADDR_AI in combination with register addressing. This
      conflicts with regmap which takes this bit as part of the register number,
      i.e. a second cache entry is defined for accessed with REG_ADDR_AI being
      set although on the chip it is the same register as with REG_ADDR_AI being
      cleared.
      
      The problem was introduced by
      
      	commit b32cecb4 ("gpio: pca953x: Extract the register address mangling to single function")
      
      but only became visible by
      
      	commit 8b9f9d4d ("regmap: verify if register is writeable before writing operations")
      
      because before, the regmap size was effectively ignored and
      pca953x_writeable_register() did know to ignore REG_ADDR_AI. Still, there
      were two separate cache entries created.
      
      Since the use of REG_ADDR_AI seems to be static we can work around this
      issue by simply increasing the size of the regmap to cover the "virtual"
      registers with REG_ADDR_AI being set. This only means that half of the
      regmap buffer will be unused.
      Reported-by: NH. Nikolaus Schaller <hns@goldelico.com>
      Suggested-by: NLinus Walleij <linus.walleij@linaro.org>
      Signed-off-by: NH. Nikolaus Schaller <hns@goldelico.com>
      Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>
      3b00691c
  13. 05 6月, 2019 1 次提交
  14. 03 6月, 2019 1 次提交
  15. 11 4月, 2019 2 次提交
  16. 08 4月, 2019 1 次提交
  17. 22 3月, 2019 1 次提交
  18. 08 3月, 2019 1 次提交
  19. 01 3月, 2019 1 次提交
    • M
      gpio: pca953x: Fix dereference of irq data in shutdown · c378b3aa
      Mark Walton 提交于
      If a PCA953x gpio was used as an interrupt and then released,
      the shutdown function was trying to extract the pca953x_chip
      pointer directly from the irq_data, but in reality was getting
      the gpio_chip structure.
      
      The net effect was that the subsequent writes to the data
      structure corrupted data in the gpio_chip structure, which wasn't
      immediately obvious until attempting to use the GPIO again in the
      future, at which point the kernel panics.
      
      This fix correctly extracts the pca953x_chip structure via the
      gpio_chip structure, as is correctly done in the other irq
      functions.
      
      Fixes: 0a70fe00 ("gpio: pca953x: Clear irq trigger type on irq shutdown")
      Cc: stable@vger.kernel.org
      Signed-off-by: NMark Walton <mark.walton@serialtek.com>
      Reviewed-by: NBartosz Golaszewski <bgolaszewski@baylibre.com>
      Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>
      c378b3aa
  20. 20 2月, 2019 1 次提交
  21. 14 2月, 2019 1 次提交
  22. 13 2月, 2019 1 次提交
  23. 21 1月, 2019 2 次提交
    • T
      gpio: pca953x: use a per instance irq_chip structure · 5c4fee63
      Thomas Petazzoni 提交于
      When a system has two PCA953x GPIO expanders, the kernel complains with:
      
      gpio gpiochip2: (0-0021): detected irqchip that is shared with multiple gpiochips: please fix the driver.
      
      Indeed, there is a single instance of "struct irq_chip" that gets
      re-used for both PCA953x instance. This commit moves the "struct
      irq_chip" to be part of the "struct pca953x_chip", so that we have one
      "struct irq_chip" per PCA953X instance.
      
      As part of this, the name of the irq_chip is also made different on a
      per-instance basis, now using the dev_name() of the I2C device. This
      changes what is visible in /proc/interrupts.
      
      Before:
      
       47:          0          0   pca953x  10 Edge      e0100000.sdhci cd
       48:          0          0   pca953x   6 Edge      e0101000.sdhci cd
      
      After:
      
       47:          0          0    0-0020  10 Edge      e0100000.sdhci cd
       48:          2          0    0-0020   6 Edge      e0101000.sdhci cd
      Signed-off-by: NThomas Petazzoni <thomas.petazzoni@bootlin.com>
      Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>
      5c4fee63
    • T
      gpio: pca953x: reduce indentation level in pca953x_irq_setup() · 7341fa7a
      Thomas Petazzoni 提交于
      The current design of pca953x_irq_setup() is:
      
       if (all conditions to support IRQ are met) {
         lots of code to support IRQs, which goes to a serious indentation
         level.
       }
      
       return 0;
      
      It makes more sense to handle this like this:
      
       if (!all conditions to support IRQ are met)
         return 0;
      
       handle IRQ support
      
      This commit does just this change, reducing by one tab the indentation
      level of the IRQ setup code. Thanks to this reduced indentation level,
      we are less restricted by the 80-column limit, and we can have more
      function arguments on the same line.
      Signed-off-by: NThomas Petazzoni <thomas.petazzoni@bootlin.com>
      Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>
      7341fa7a
  24. 11 1月, 2019 1 次提交
  25. 17 12月, 2018 1 次提交