user/sven/linux.git/drivers/pinctrl, branch v4.9.5

pinctrl: sh-pfc: Do not unconditionally support PIN_CONFIG_BIAS_DISABLE

2017-01-19T19:18:08Z

commit 5d7400c4acbf7fe633a976a89ee845f7333de3e4 upstream. Always stating PIN_CONFIG_BIAS_DISABLE is supported gives untrue output when examining /sys/kernel/debug/pinctrl/e6060000.pfc/pinconf-pins if the operation get_bias() is implemented but the pin is not handled by the get_bias() implementation. In that case the output will state that "input bias disabled" indicating that this pin has bias control support. Make support for PIN_CONFIG_BIAS_DISABLE depend on that the pin either supports SH_PFC_PIN_CFG_PULL_UP or SH_PFC_PIN_CFG_PULL_DOWN. This also solves the issue where SoC specific implementations print error messages if their particular implementation of {set,get}_bias() is called with a pin it does not know about. Signed-off-by: Niklas Söderlund Acked-by: Laurent Pinchart Signed-off-by: Geert Uytterhoeven Signed-off-by: Greg Kroah-Hartman

pinctrl: meson: fix gpio request disabling other modes

2017-01-19T19:18:05Z

commit f24d311f92b516a8aadef5056424ccabb4068e7b upstream. The pinctrl_gpio_request is called with the "full" gpio number, already containing the base, then meson_pmx_request_gpio is then called with the final pin number. Remove the base addition when calling meson_pmx_disable_other_groups. Fixes: 6ac730951104 ("pinctrl: add driver for Amlogic Meson SoCs") CC: Beniamino Galvani Signed-off-by: Neil Armstrong Acked-by: Kevin Hilman Acked-by: Beniamino Galvani Signed-off-by: Linus Walleij Signed-off-by: Greg Kroah-Hartman

pinctrl: sh-pfc: Add helper to handle bias lookup table

2017-01-19T19:17:57Z

commit c314c9f15aa5f43f0e5c0e2602cc65798dbd1598 upstream. On some SoC there are no simple mapping of pins to bias register bits and a lookup table is needed. This logic is already implemented in some SoC specific drivers that could benefit from a generic implementation. Add helpers to deal with the lookup which later can be used by the SoC specific drivers. The logic used to lookup are different from the one it aims to replace, this is intentional. This new method reduces the memory consumption at the cost of increased CPU usage and fix a bug where a WARN() would incorrectly be triggered if the register offset is 0. Signed-off-by: Niklas Söderlund Reviewed-by: Laurent Pinchart Signed-off-by: Geert Uytterhoeven Signed-off-by: Greg Kroah-Hartman

pinctrl: sh-pfc: r8a7795: Use lookup function for bias data

2017-01-19T19:17:57Z

commit d3b861bccdee2fa9963a2b6c64f74a8d752b9315 upstream. There is a bug in the r8a7795 bias code where a WARN() is trigged anytime a pin from PUEN0/PUD0 is accessed. # cat /sys/kernel/debug/pinctrl/e6060000.pfc/pinconf-pins WARNING: CPU: 2 PID: 2391 at drivers/pinctrl/sh-pfc/pfc-r8a7795.c:5364 r8a7795_pinmux_get_bias+0xbc/0xc8 [..] Call trace: [] r8a7795_pinmux_get_bias+0xbc/0xc8 [] sh_pfc_pinconf_get+0x194/0x270 [] pin_config_get_for_pin+0x20/0x30 [] pinconf_generic_dump_one+0x168/0x188 [] pinconf_generic_dump_pins+0x5c/0x98 [] pinconf_pins_show+0xc8/0x128 [] seq_read+0x16c/0x420 [] full_proxy_read+0x58/0x88 [] __vfs_read+0x1c/0xf8 [] vfs_read+0x84/0x148 [] SyS_read+0x44/0xa0 [] __sys_trace_return+0x0/0x4 This is due to the WARN() check if the reg field of the pullups struct is zero, and this should be 0 for pins controlled by the PUEN0/PUD0 registers since PU0 is defined as 0. Change the data structure and use the generic sh_pfc_pin_to_bias_info() function to get the register offset and bit information. Fixes: 560655247b627ac7 ("pinctrl: sh-pfc: r8a7795: Add bias pinconf support") Signed-off-by: Niklas Söderlund Reviewed-by: Laurent Pinchart Signed-off-by: Geert Uytterhoeven Signed-off-by: Greg Kroah-Hartman

pinctrl: imx: fix imx_pinctrl_desc initialization

2017-01-19T19:17:57Z

commit 8f5983ad6b81070376db9487ce81000c85a16027 upstream. Fixes: 6e408ed8be0e ("pinctrl: imx: fix initialization of imx_pinctrl_desc") Reviewed-by: Vladimir Zapolskiy Reviewed-by: Peng Fan Signed-off-by: Gary Bisson Signed-off-by: Greg Kroah-Hartman Signed-off-by: Linus Walleij

pinctrl/amd: Set the level based on ACPI tables

2017-01-12T10:39:07Z

commit 2983f296f2327bc517e3b29344fce82271160197 upstream. In the function amd_gpio_irq_set_type, read the values from the ACPI table to set the level and drop the settings passed by the client. Reviewed-by: Pankaj Sen Reviewed-by: Nitesh Kumar Agrawal Reviewed-by: Shah, Nehal-bakulchandra Signed-off-by: Shyam-sundar S-k Signed-off-by: Linus Walleij Signed-off-by: Greg Kroah-Hartman

pinctrl-aspeed-g5: Never set SCU90[6]

2016-11-07T09:31:33Z

If a pin depending on bit 6 in SCU90 is requested for GPIO, the export will succeed but changes to the GPIO's value will not be accepted by the hardware. This is because the pinmux driver has misconfigured the SCU by writing 1 to the reserved bit. The description of SCU90[6] from the datasheet is 'Reserved, must keep at value ”0”'. The fix is to switch pinmux from the bit-flipping macro to explicitly configuring the .enable and .disable values to zero. The patch has been tested on an AST2500 EVB. Fixes: 56e57cb6c07f (pinctrl: Add pinctrl-aspeed-g5 driver) Reported-by: Uma Yadlapati Signed-off-by: Andrew Jeffery Reviewed-by: Joel Stanley Signed-off-by: Linus Walleij

pinctrl: cherryview: Prevent possible interrupt storm on resume

2016-11-04T21:23:04Z

When the system is suspended to S3 the BIOS might re-initialize certain GPIO pins back to their original state or it may re-program interrupt mask of others. For example Acer TravelMate B116-M had BIOS bug where certain GPIO pin (MF_ISH_GPIO_5) was programmed to trigger on high level, and the pin state was high once the BIOS gave control to the OS on resume. This triggers lots of messages like: irq 117, desc: ffff88017a61e600, depth: 1, count: 0, unhandled: 0 ->handle_irq(): ffffffff8109b613, handle_bad_irq+0x0/0x1e0 ->irq_data.chip(): ffffffffa0020180, chv_pinctrl_exit+0x2d84/0x12 [pinctrl_cherryview] ->action(): (null) IRQ_NOPROBE set We reset the mask back to known state in chv_pinctrl_resume() but that is called only after device interrupts have already been enabled. Now, this particular issue was fixed by upgrading the BIOS to the latest (v1.23) but not everybody upgrades their BIOSes so we fix it up in the driver as well. Prevent the possible interrupt storm by moving suspend and resume hooks to be called at _noirq time instead. Since device interrupts are still disabled we can restore the mask back to known state before interrupt storm happens. Cc: stable@vger.kernel.org Reported-by: Christian Steiner Signed-off-by: Mika Westerberg Signed-off-by: Linus Walleij

pinctrl: cherryview: Serialize register access in suspend/resume

2016-11-04T21:22:28Z

If async suspend is enabled, the driver may access registers concurrently with another instance which may fail because of the bug in Cherryview GPIO hardware. Prevent this by taking the shared lock while accessing the hardware in suspend and resume hooks. Cc: stable@vger.kernel.org Signed-off-by: Mika Westerberg Signed-off-by: Linus Walleij

pinctrl: imx: reset group index on probe

2016-10-31T20:25:15Z

Group index is incremented on every new group parsed. Since the field is part of struct imx_pinctrl_soc_info, which is typically a global variable passed by the individual pinctrl-imx.c based driver, it does not get cleared automatically when re-probing the driver. This lead imx_pinctrl_parse_functions passing a group pointer which is outside of the allocated group space on second probe and onwards. Typically this ended up in a NULL pointer dereference when accessing the name field like this: Unable to handle kernel NULL pointer dereference at virtual address 00000000 ... PC is at strcmp+0x18/0x44 LR is at imx_dt_node_to_map+0xc4/0x290 Avoid this by setting group_index to 0 on probe. This has been observed when using DEBUG_TEST_DRIVER_REMOVE. Signed-off-by: Stefan Agner Signed-off-by: Linus Walleij