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

pinctrl: meson: meson8b: add the eth_rxd2 and eth_rxd3 pins

2019-04-05T20:34:51Z

[ Upstream commit 6daae00243e622dd3feec7965bfe421ad6dd317e ] Gigabit Ethernet requires the Ethernet TXD0..3 and RXD0..3 data lines. Add the missing eth_rxd2 and eth_rxd3 definitions so we don't have to rely on the bootloader to set them up correctly. The vendor u-boot sources for Odroid-C1 use the following Ethernet pinmux configuration: SET_CBUS_REG_MASK(PERIPHS_PIN_MUX_6, 0x3f4f); SET_CBUS_REG_MASK(PERIPHS_PIN_MUX_7, 0xf00000); This translates to the following pin groups in the mainline kernel: - register 6 bit 0: eth_rxd1 (DIF_0_P) - register 6 bit 1: eth_rxd0 (DIF_0_N) - register 6 bit 2: eth_rx_dv (DIF_1_P) - register 6 bit 3: eth_rx_clk (DIF_1_N) - register 6 bit 6: eth_tx_en (DIF_3_P) - register 6 bit 8: eth_ref_clk (DIF_3_N) - register 6 bit 9: eth_mdc (DIF_4_P) - register 6 bit 10: eth_mdio_en (DIF_4_N) - register 6 bit 11: eth_tx_clk (GPIOH_9) - register 6 bit 12: eth_txd2 (GPIOH_8) - register 6 bit 13: eth_txd3 (GPIOH_7) - register 7 bit 20: eth_txd0_0 (GPIOH_6) - register 7 bit 21: eth_txd1_0 (GPIOH_5) - register 7 bit 22: eth_rxd3 (DIF_2_P) - register 7 bit 23: eth_rxd2 (DIF_2_N) All functions except eth_rxd2 and eth_rxd3 are already supported by the pinctrl-meson8b driver. Suggested-by: Jianxin Pan Signed-off-by: Martin Blumenstingl Reviewed-by: Kevin Hilman Tested-by: Emiliano Ingrassia Reviewed-by: Emiliano Ingrassia Signed-off-by: Linus Walleij Signed-off-by: Sasha Levin

pinctrl: sh-pfc: r8a77995: Fix MOD_SEL bit numbering

2019-04-05T20:34:49Z

[ Upstream commit 5219aa33caec2f7b68eda2b7e4ab8e276f323254 ] MOD_SEL register bit numbering was different from R-Car D3 SoC and R-Car H3/M3-[WN] SoCs. MOD_SEL 1-bit H3/M3-[WN] D3 =============== ========== ===== Set Value = H'0 b'0 b'0 Set Value = H'1 b'1 b'1 MOD_SEL 2-bits H3/M3-[WN] D3 =============== ========== ===== Set Value = H'0 b'00 b'00 Set Value = H'1 b'01 b'10 Set Value = H'2 b'10 b'01 Set Value = H'3 b'11 b'11 MOD_SEL 3-bits H3/M3-[WN] D3 =============== ========== ===== Set Value = H'0 b'000 b'000 Set Value = H'1 b'001 b'100 Set Value = H'2 b'010 b'010 Set Value = H'3 b'011 b'110 Set Value = H'4 b'100 b'001 Set Value = H'5 b'101 b'101 Set Value = H'6 b'110 b'011 Set Value = H'7 b'111 b'111 This patch replaces the #define name and value of MOD_SEL. Signed-off-by: Takeshi Kihara Fixes: 794a67117646 ("pinctrl: sh-pfc: Initial R8A77995 PFC support") [shimoda: split a patch per SoC and revise the commit log] Signed-off-by: Yoshihiro Shimoda [geert: Use a macro to do the actual reordering] Signed-off-by: Geert Uytterhoeven Reviewed-by: Simon Horman Signed-off-by: Sasha Levin

pinctrl: sh-pfc: r8a77990: Fix MOD_SEL bit numbering

2019-04-05T20:34:49Z

[ Upstream commit 3e3eebeacad79bda8a9664c86c04f5201e86fece ] MOD_SEL register bit numbering was different from R-Car E3 SoC and R-Car H3/M3-[WN] SoCs. MOD_SEL 1-bit H3/M3-[WN] E3 =============== ========== ===== Set Value = H'0 b'0 b'0 Set Value = H'1 b'1 b'1 MOD_SEL 2-bits H3/M3-[WN] E3 =============== ========== ===== Set Value = H'0 b'00 b'00 Set Value = H'1 b'01 b'10 Set Value = H'2 b'10 b'01 Set Value = H'3 b'11 b'11 MOD_SEL 3-bits H3/M3-[WN] E3 =============== ========== ===== Set Value = H'0 b'000 b'000 Set Value = H'1 b'001 b'100 Set Value = H'2 b'010 b'010 Set Value = H'3 b'011 b'110 Set Value = H'4 b'100 b'001 Set Value = H'5 b'101 b'101 Set Value = H'6 b'110 b'011 Set Value = H'7 b'111 b'111 This patch replaces the #define name and value of MOD_SEL. Signed-off-by: Takeshi Kihara Fixes: 6d4036a1e3b3 ("pinctrl: sh-pfc: Initial R8A77990 PFC support") [shimoda: Split a patch per SoC and revise the commit log] Signed-off-by: Yoshihiro Shimoda [geert: Use macros to do the actual reordering] Signed-off-by: Geert Uytterhoeven Reviewed-by: Yoshihiro Shimoda Signed-off-by: Sasha Levin

pinctrl: meson: fix G12A ao pull registers base address

2019-04-05T20:34:49Z

[ Upstream commit e66dd48e8b0dee104d16417d30361074b08baca8 ] Since Meson G12A SoC, Introduce new ao registers AO_RTI_PULL_UP_EN_REG and AO_GPIO_O. These bits of controlling output level are remapped to the new register AO_GPIO_O, and the AO_GPIO_O_EN_N support only controlling output enable. These bits of controlling pull enable are remapped to the new register AO_RTI_PULL_UP_EN_REG, and the AO_RTI_PULL_UP_REG support only controlling pull type(up/down). The new layout of ao gpio/pull registers is as follows: - AO_GPIO_O_EN_N [offset: 0x9 << 2] - AO_GPIO_I [offset: 0xa << 2] - AO_RTI_PULL_UP_REG [offset: 0xb << 2] - AO_RTI_PULL_UP_EN_REG [offset: 0xc << 2] - AO_GPIO_O [offset: 0xd << 2] From above, we can see ao GPIO registers region has been separated by the ao pull registers. In order to ensure the continuity of the region on software, the ao GPIO and ao pull registers use the same base address, but can be identified by the offset. Fixes: 29ae0952e85f ("pinctrl: meson-g12a: add pinctrl driver support") Signed-off-by: Xingyu Chen Signed-off-by: Jianxin Pan Signed-off-by: Jerome Brunet Signed-off-by: Linus Walleij Signed-off-by: Sasha Levin

pinctrl: meson: meson8b: fix the sdxc_a data 1..3 pins

2019-02-17T21:24:32Z

Fix the mismatch between the "sdxc_d13_1_a" pin group definition from meson8b_cbus_groups and the entry in sdxc_a_groups ("sdxc_d0_13_1_a"). This makes it possible to use "sdxc_d13_1_a" in device-tree files to route the MMC data 1..3 pins to GPIOX_1..3. Fixes: 0fefcb6876d0d6 ("pinctrl: Add support for Meson8b") Signed-off-by: Martin Blumenstingl Signed-off-by: Linus Walleij

pinctrl: qcom: qcs404: Correct SDC tile

2019-02-11T08:15:04Z

The SDC controls live in the south tile, not the north one. Correct this so that we program the right registers. Cc: stable@vger.kernel.org Fixes: 22eb8301dbc1 ("pinctrl: qcom: Add qcs404 pinctrl driver") Signed-off-by: Bjorn Andersson Reviewed-by: Vinod Koul Signed-off-by: Linus Walleij

pinctrl: sunxi: Correct number of IRQ banks on H6 main pin controller

2019-01-22T09:52:39Z

The H6 main pin controller has four banks of interrupt-triggering pins. The driver as originally submitted only specified three, but had pin descriptions referencing a fourth bank. This results in a out-of-bounds access into .irq_array of struct sunxi_pinctrl. This however did not result in a crash until v4.20, with commit a66d972465d1 ("devres: Align data[] to ARCH_KMALLOC_MINALIGN"), which changed the alignment of memory region returned by devm_kcalloc(). The increase likely moved the out-of-bounds access into the next, unmapped page. With KASAN on, the bug is quite clear: BUG: KASAN: slab-out-of-bounds in sunxi_pinctrl_init_with_variant+0x49c/0x12b8 Write of size 4 at addr ffff80002c680280 by task swapper/0/1 CPU: 2 PID: 1 Comm: swapper/0 Not tainted 5.0.0-rc1-00016-gc480a5e6a077 #3 Hardware name: OrangePi Lite2 (DT) Call trace: dump_backtrace+0x0/0x220 show_stack+0x14/0x20 dump_stack+0xac/0xd4 print_address_description+0x60/0x25c kasan_report+0x14c/0x1ac __asan_store4+0x80/0xa0 sunxi_pinctrl_init_with_variant+0x49c/0x12b8 h6_pinctrl_probe+0x18/0x20 platform_drv_probe+0x6c/0xc8 really_probe+0x244/0x4b0 driver_probe_device.part.4+0x11c/0x164 __driver_attach+0x120/0x190 bus_for_each_dev+0xe8/0x158 driver_attach+0x30/0x40 bus_add_driver+0x308/0x318 driver_register+0xbc/0x1d0 __platform_driver_register+0x7c/0x88 h6_pinctrl_driver_init+0x18/0x20 do_one_initcall+0xd4/0x208 kernel_init_freeable+0x230/0x2c8 kernel_init+0x10/0x108 ret_from_fork+0x10/0x1c Allocated by task 1: kasan_kmalloc.part.0+0x4c/0x100 kasan_kmalloc+0xc4/0xe8 kasan_slab_alloc+0x14/0x20 __kmalloc_track_caller+0x130/0x238 devm_kmalloc+0x34/0xd0 sunxi_pinctrl_init_with_variant+0x1d8/0x12b8 h6_pinctrl_probe+0x18/0x20 platform_drv_probe+0x6c/0xc8 really_probe+0x244/0x4b0 driver_probe_device.part.4+0x11c/0x164 __driver_attach+0x120/0x190 bus_for_each_dev+0xe8/0x158 driver_attach+0x30/0x40 bus_add_driver+0x308/0x318 driver_register+0xbc/0x1d0 __platform_driver_register+0x7c/0x88 h6_pinctrl_driver_init+0x18/0x20 do_one_initcall+0xd4/0x208 kernel_init_freeable+0x230/0x2c8 kernel_init+0x10/0x108 ret_from_fork+0x10/0x1c Freed by task 0: (stack is not available) The buggy address belongs to the object at ffff80002c680080 which belongs to the cache kmalloc-512 of size 512 The buggy address is located 0 bytes to the right of 512-byte region [ffff80002c680080, ffff80002c680280) The buggy address belongs to the page: page:ffff7e0000b1a000 count:1 mapcount:0 mapping:ffff80002e00c780 index:0xffff80002c683c80 compound_mapcount: 0 flags: 0x10200(slab|head) raw: 0000000000010200 ffff80002e003a10 ffff80002e003a10 ffff80002e00c780 raw: ffff80002c683c80 0000000000100001 00000001ffffffff 0000000000000000 page dumped because: kasan: bad access detected Memory state around the buggy address: ffff80002c680180: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ffff80002c680200: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 >ffff80002c680280: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc ^ ffff80002c680300: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc ffff80002c680380: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc Correct the number of IRQ banks so there are no more mismatches. Fixes: c8a830904991 ("pinctrl: sunxi: add support for the Allwinner H6 main pin controller") Cc: Signed-off-by: Chen-Yu Tsai Tested-by: Neil Armstrong Acked-by: Maxime Ripard Signed-off-by: Linus Walleij

pinctrl: mcp23s08: spi: Fix regmap allocation for mcp23s18

2019-01-21T13:18:15Z

Fixes issue created by 9b3e4207661e67f04c72af15e29f74cd944f5964. It wasn't possible for one_regmap_config to be non-NULL at the point it was tested for mcp23s18 devices. Applied the same pattern of allocating one_regmap_config using devm_kmemdump() and then initializing the local regmap structure from that. Signed-off-by: Jason Kridner Signed-off-by: Linus Walleij

pinctrl: cherryview: fix Strago DMI workaround

2019-01-21T12:05:42Z

Well, hopefully 3rd time is a charm. We tried making that check DMI_BIOS_VERSION and DMI_BOARD_VERSION, but the real one is DMI_PRODUCT_VERSION. Fixes: 86c5dd6860a6 ("pinctrl: cherryview: limit Strago DMI workarounds to version 1.0") Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=197953 Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=1631930 Cc: stable@vger.kernel.org Signed-off-by: Dmitry Torokhov Reviewed-by: Andy Shevchenko Acked-by: Mika Westerberg Signed-off-by: Linus Walleij

pinctrl: sunxi: Consider pin_base when calculating regulator array index

2019-01-14T15:12:59Z

On most newer Allwinner SoCs, there are two pinctrl devices, the PIO and R_PIO. PIO covers pin-banks PA to PI (PJ and PK have not been seen), while R_PIO covers PL to PN. The regulator array only has space for 12 entries, which was designed to cover PA to PL. On the A80, the pin banks go up to PN, which would be the 14th entry in the regulator array. However since the driver only needs to track regulators for its own pin banks, the array only needs to have 9 entries, and also take in to account the value of pin_base, such that the regulator for the first pin-bank of the pinctrl device, be it "PA" or "PL" uses the first entry of the array. Base the regulator array index on pin_base, such that "PA" for PIO and "PL" for R_PIO both take the first element within their respective device's regulator array. Also decrease the size of the regulator array to 9, just enough to cover "PA" to "PI". Fixes: 9a2a566adb00 ("pinctrl: sunxi: Deal with per-bank regulators") Signed-off-by: Chen-Yu Tsai Signed-off-by: Linus Walleij