An error occurred fetching the project authors.
  1. 18 Apr, 2024 2 commits
  2. 15 Apr, 2024 4 commits
  3. 11 Apr, 2024 2 commits
  4. 01 Mar, 2024 1 commit
  5. 12 Feb, 2024 1 commit
  6. 22 Jan, 2024 1 commit
  7. 20 Oct, 2023 1 commit
  8. 09 Oct, 2023 1 commit
  9. 04 Oct, 2023 1 commit
  10. 11 Sep, 2023 2 commits
  11. 10 Jul, 2023 1 commit
  12. 23 Mar, 2023 3 commits
  13. 07 Mar, 2023 1 commit
    • Hans de Goede's avatar
      ACPI: x86: Introduce an acpi_quirk_skip_gpio_event_handlers() helper · 5adc4093
      Hans de Goede authored
      x86 ACPI boards which ship with only Android as their factory image usually
      have pretty broken ACPI tables, relying on everything being hardcoded in
      the factory kernel image and often disabling parts of the ACPI enumeration
      kernel code to avoid the broken tables causing issues.
      
      Part of this broken ACPI code is that sometimes these boards have _AEI
      ACPI GPIO event handlers which are broken.
      
      So far this has been dealt with in the platform/x86/x86-android-tablets.c
      module, which contains various workarounds for these devices, by it calling
      acpi_gpiochip_free_interrupts() on gpiochip-s with troublesome handlers to
      disable the handlers.
      
      But in some cases this is too late, if the handlers are of the edge type
      then gpiolib-acpi.c's code will already have run them at boot.
      This can cause issues such as GPIOs ending up as owned by "ACPI:OpRegion",
      making them unavailable for drivers which actually need them.
      
      Boards with these broken ACPI tables are already listed in
      drivers/acpi/x86/utils.c for e.g. acpi_quirk_skip_i2c_client_enumeration().
      Extend the quirks mechanism for a new acpi_quirk_skip_gpio_event_handlers()
      helper, this re-uses the DMI-ids rather then having to duplicate the same
      DMI table in gpiolib-acpi.c .
      
      Also add the new ACPI_QUIRK_SKIP_GPIO_EVENT_HANDLERS quirk to existing
      boards with troublesome ACPI gpio event handlers, so that the current
      acpi_gpiochip_free_interrupts() hack can be removed from
      x86-android-tablets.c .
      Signed-off-by: default avatarHans de Goede <hdegoede@redhat.com>
      Acked-by: default avatarAndy Shevchenko <andy.shevchenko@gmail.com>
      Signed-off-by: default avatarRafael J. Wysocki <rjw@rjwysocki.net>
      5adc4093
  14. 06 Mar, 2023 1 commit
  15. 15 Feb, 2023 1 commit
  16. 30 Jan, 2023 1 commit
  17. 23 Jan, 2023 1 commit
  18. 18 Jan, 2023 2 commits
  19. 15 Nov, 2022 4 commits
  20. 25 Oct, 2022 1 commit
  21. 04 Oct, 2022 1 commit
  22. 05 Sep, 2022 2 commits
  23. 19 Jul, 2022 1 commit
  24. 08 Apr, 2022 2 commits
    • Andy Shevchenko's avatar
      gpiolib: acpi: Convert type for pin to be unsigned · 0c2cae09
      Andy Shevchenko authored
      A pin that comes from ACPI tables is of unsigned type. This also applies
      to the internal APIs which use unsigned int to store the pin. Convert
      type for pin to be unsigned in the places where it's not yet true.
      
      While at it, add a stub for acpi_get_and_request_gpiod() for the sake
      of consistency in the APIs.
      Signed-off-by: default avatarAndy Shevchenko <andriy.shevchenko@linux.intel.com>
      0c2cae09
    • Linus Torvalds's avatar
      gpiolib: acpi: use correct format characters · 213d266e
      Linus Torvalds authored
      When compiling with -Wformat, clang emits the following warning:
      
        gpiolib-acpi.c:393:4: warning: format specifies type 'unsigned char' but the argument has type 'int' [-Wformat]
                              pin);
                              ^~~
      
      So warning that '%hhX' is paired with an 'int' is all just completely
      mindless and wrong. Sadly, I can see a different bogus warning reason
      why people would want to use '%02hhX'.
      
      Again, the *sane* thing from a human perspective is to use '%02X. But
      if the compiler doesn't do any range analysis at all, it could decide
      that "Oh, that print format could need up to 8 bytes of space in the
      result". Using '%02hhX' would cut that down to two.
      
      And since we use
      
              char ev_name[5];
      
      and currently use "_%c%02hhX" as the format string, even a compiler
      that doesn't notice that "pin <= 255" test that guards this all will
      go "OK, that's at most 4 bytes and the final NUL termination, so it's
      fine".
      
      While a compiler - like gcc - that only sees that the original source
      of the 'pin' value is a 'unsigned short' array, and then doesn't take
      the "pin <= 255" into account, will warn like this:
      
        gpiolib-acpi.c: In function 'acpi_gpiochip_request_interrupt':
        gpiolib-acpi.c:206:24: warning: '%02X' directive writing between 2 and 4 bytes into a region of size 3 [-Wformat-overflow=]
             sprintf(ev_name, "_%c%02X",
                                  ^~~~
        gpiolib-acpi.c:206:20: note: directive argument in the range [0, 65535]
      
      because gcc isn't being very good at that argument range analysis either.
      
      In other words, the original use of 'hhx' was bogus to begin with, and
      due to *another* compiler warning being bad, and we had that bad code
      being written back in 2016 to work around _that_ compiler warning
      (commit e40a3ae1: "gpio: acpi: work around false-positive
      -Wstring-overflow warning").
      
      Sadly, two different bad compiler warnings together does not make for
      one good one.
      
      It just makes for even more pain.
      
      End result: I think the simplest and cleanest option is simply the
      proposed change which undoes that '%hhX' change for gcc, and replaces
      it with just using a slightly bigger stack allocation. It's not like
      a 5-byte allocation is in any way likely to have saved any actual stack,
      since all the other variables in that function are 'int' or bigger.
      
      False-positive compiler warnings really do make people write worse
      code, and that's a problem. But on a scale of bad code, I feel that
      extending the buffer trivially is better than adding a pointless cast
      that literally makes no sense.
      
      At least in this case the end result isn't unreadable or buggy. We've
      had several cases of bad compiler warnings that caused changes that
      were actually horrendously wrong.
      
      Fixes: e40a3ae1 ("gpio: acpi: work around false-positive -Wstring-overflow warning")
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      Signed-off-by: default avatarAndy Shevchenko <andriy.shevchenko@linux.intel.com>
      213d266e
  25. 07 Mar, 2022 1 commit
  26. 03 Jan, 2022 1 commit