user/sven/linux.git/drivers/pinctrl, branch v5.4.3

pinctrl: stmfx: fix valid_mask init sequence

2019-11-07T09:06:46Z

With stmfx_pinctrl_gpio_init_valid_mask callback, gpio_valid_mask was used to initialize gpiochip valid_mask for gpiolib. But gpio_valid_mask was not yet initialized. gpio_valid_mask required gpio-ranges to be registered, this is the case after gpiochip_add_data call. But init_valid_mask callback is also called under gpiochip_add_data. gpio_valid_mask initialization cannot be moved before gpiochip_add_data because gpio-ranges are not registered. So, it is not possible to use init_valid_mask callback. To avoid this issue, get rid of valid_mask and rely on ranges. Fixes: da9b142ab2c5 ("pinctrl: stmfx: Use the callback to populate valid_mask") Signed-off-by: Amelie Delaunay Link: https://lore.kernel.org/r/20191104100908.10880-1-amelie.delaunay@st.com Signed-off-by: Linus Walleij

Merge tag 'intel-pinctrl-fixes-v5.4-2' of git://git.kernel.org/pub/scm/linux/kernel/git/pinctrl/intel into fixes

2019-10-30T09:32:55Z

intel-pinctrl fixes for v5.4 part 2 A couple more fixes for Intel pinctrl drivers: - Try to avoid glitches when pin is in GPIO mode - Fix cherryview irq_valid_mask calculation - Allocate cherryview IRQ chip dynamically to avoid triggering warning from GPIO core

pinctrl: cherryview: Allocate IRQ chip dynamic

2019-10-25T09:54:10Z

Keeping the IRQ chip definition static shares it with multiple instances of the GPIO chip in the system. This is bad and now we get this warning from GPIO library: "detected irqchip that is shared with multiple gpiochips: please fix the driver." Hence, move the IRQ chip definition from being driver static into the struct intel_pinctrl. So a unique IRQ chip is used for each GPIO chip instance. This patch is heavily based on the attachment to the bug by Christoph Marz. BugLink: https://bugzilla.kernel.org/show_bug.cgi?id=202543 Fixes: 6e08d6bbebeb ("pinctrl: Add Intel Cherryview/Braswell pin controller support") Depends-on: 83b9dc11312f ("pinctrl: cherryview: Associate IRQ descriptors to irqdomain") Signed-off-by: Andy Shevchenko Signed-off-by: Mika Westerberg

pinctrl: cherryview: Fix irq_valid_mask calculation

2019-10-21T13:57:47Z

Commit 03c4749dd6c7 ("gpio / ACPI: Drop unnecessary ACPI GPIO to Linux GPIO translation") has made the cherryview gpio numbers sparse, to get a 1:1 mapping between ACPI pin numbers and gpio numbers in Linux. This has greatly simplified things, but the code setting the irq_valid_mask was not updated for this, so the valid mask is still in the old "compressed" numbering with the gaps in the pin numbers skipped, which is wrong as irq_valid_mask needs to be expressed in gpio numbers. This results in the following error on devices using pin 24 (0x0018) on the north GPIO controller as an ACPI event source: [ 0.422452] cherryview-pinctrl INT33FF:01: Failed to translate GPIO to IRQ This has been reported (by email) to be happening on a Caterpillar CAT T20 tablet and I've reproduced this myself on a Medion Akoya e2215t 2-in-1. This commit uses the pin number instead of the compressed index into community->pins to clear the correct bits in irq_valid_mask for GPIOs using GPEs for interrupts, fixing these errors and in case of the Medion Akoya e2215t also fixing the LID switch not working. Cc: stable@vger.kernel.org Fixes: 03c4749dd6c7 ("gpio / ACPI: Drop unnecessary ACPI GPIO to Linux GPIO translation") Signed-off-by: Hans de Goede Reviewed-by: Andy Shevchenko Signed-off-by: Mika Westerberg

pinctrl: intel: Avoid potential glitches if pin is in GPIO mode

2019-10-21T12:41:19Z

When consumer requests a pin, in order to be on the safest side, we switch it first to GPIO mode followed by immediate transition to the input state. Due to posted writes it's luckily to be a single I/O transaction. However, if firmware or boot loader already configures the pin to the GPIO mode, user expects no glitches for the requested pin. We may check if the pin is pre-configured and leave it as is till the actual consumer toggles its state to avoid glitches. Fixes: 7981c0015af2 ("pinctrl: intel: Add Intel Sunrisepoint pin controller and GPIO support") Depends-on: f5a26acf0162 ("pinctrl: intel: Initialize GPIO properly when used through irqchip") Cc: stable@vger.kernel.org Cc: fei.yang@intel.com Reported-by: Oliver Barta Reported-by: Malin Jonsson Signed-off-by: Andy Shevchenko Signed-off-by: Mika Westerberg

pinctrl: aspeed-g6: Rename SD3 to EMMC and rework pin groups

2019-10-16T13:58:27Z

AST2600 EMMC support 3 types DAT bus sizes (1, 4 and 8-bit), corresponding to 3 groups: EMMCG1, EMMCG4 and EMMCG8 Fixes: 58dc52ad00a0 ("pinctrl: aspeed: Add AST2600 pinmux support") Signed-off-by: Johnny Huang Signed-off-by: Andrew Jeffery Link: https://lore.kernel.org/r/20191008044153.12734-8-andrew@aj.id.au Reviewed-by: Joel Stanley Signed-off-by: Linus Walleij

pinctrl: aspeed-g6: Fix UART13 group pinmux

2019-10-16T13:58:15Z

When UART13G1 is set the pinmux configuration in SCU4B8 for UART13G0 should be cleared. Fixes: 58dc52ad00a0 ("pinctrl: aspeed: Add AST2600 pinmux support") Signed-off-by: Johnny Huang [AJ: Tweak commit message] Signed-off-by: Andrew Jeffery Link: https://lore.kernel.org/r/20191008044153.12734-7-andrew@aj.id.au Reviewed-by: Joel Stanley Signed-off-by: Linus Walleij

pinctrl: aspeed-g6: Make SIG_DESC_CLEAR() behave intuitively

2019-10-16T13:58:09Z

Signal descriptors can represent multi-bit bitfields and so have explicit "enable" and "disable" states. However many descriptor instances only describe a single bit, and so the SIG_DESC_SET() macro is provides an abstraction for the single-bit cases: Its expansion configures the "enable" state to set the bit and "disable" to clear. SIG_DESC_CLEAR() was introduced to provide a similar single-bit abstraction for for descriptors to clear the bit of interest. However its behaviour was defined as the literal inverse of SIG_DESC_SET() - the impact is the bit of interest is set in the disable path. This behaviour isn't intuitive and doesn't align with how we want to use the macro in practice, so make it clear the bit for both the enable and disable paths. Signed-off-by: Andrew Jeffery Link: https://lore.kernel.org/r/20191008044153.12734-6-andrew@aj.id.au Reviewed-by: Joel Stanley Signed-off-by: Linus Walleij

pinctrl: aspeed-g6: Fix I3C3/I3C4 pinmux configuration

2019-10-16T13:57:49Z

The documentation to configure I3C3/FSI1 and I3C4/FSI2 was initially unclear. Fixes: 58dc52ad00a0 ("pinctrl: aspeed: Add AST2600 pinmux support") Signed-off-by: Johnny Huang [AJ: Tweak commit message, resolve rebase conflicts] Signed-off-by: Andrew Jeffery Link: https://lore.kernel.org/r/20191008044153.12734-5-andrew@aj.id.au Reviewed-by: Joel Stanley Signed-off-by: Linus Walleij

pinctrl: aspeed-g6: Fix I2C14 SDA description

2019-10-16T13:57:42Z

The I2C function the pin participated in was incorrectly named SDA14 which lead to a failure to mux: [ 6.884344] No function I2C14 found on pin 7 (7). Found signal(s) MACLINK4, SDA14, GPIOA7 for function(s) MACLINK4, SDA14, GPIOA7 Fixes: 58dc52ad00a0 ("pinctrl: aspeed: Add AST2600 pinmux support") Signed-off-by: Andrew Jeffery Link: https://lore.kernel.org/r/20191008044153.12734-4-andrew@aj.id.au Reviewed-by: Joel Stanley Signed-off-by: Linus Walleij