BMC/Intel-BMC/linux.git/drivers, branch dev-5.2

gpio: Add in ast2600 details to Aspeed driver

2019-09-10T17:29:57+00:00

The ast2600 is a new generation of SoC from ASPEED. Similarly to the ast2400 and ast2500, it has a GPIO controller for it's 3.3V GPIO pins. Additionally, it has a GPIO controller for 1.8V GPIO pins. As the register names for both controllers are the same and the 36 1.8V GPIOs and the first 36 of the 3.3V GPIOs are all bidirectional, we can use the same configuration struct and use the ngpio property to differentiate between the two sets of GPIOs. OpenBMC-Staging-Count: 1 Signed-off-by: Rashmica Gupta Signed-off-by: Joel Stanley

gpio/aspeed: Use ngpio property from device tree if available

2019-09-10T17:29:57+00:00

Use the ngpio property from the device tree if it exists. If it doesn't then fallback to the hardcoded value in the config. This is in preparation for adding ast2600 support. The ast2600 SoC has two GPIO controllers and so requires two instances of the GPIO driver. We use the ngpio property to different between them as they have different numbers of GPIOs. OpenBMC-Staging-Count: 1 Signed-off-by: Rashmica Gupta Reviewed-by: Joel Stanley Signed-off-by: Joel Stanley

gpio/aspeed: Setup irqchip dynamically

2019-09-10T17:29:57+00:00

This is in preparation for adding ast2600 support. The ast2600 SoC requires two instances of the GPIO driver as it has two GPIO controllers. Each instance needs it's own irqchip. OpenBMC-Staging-Count: 1 Signed-off-by: Rashmica Gupta Reviewed-by: Joel Stanley Signed-off-by: Joel Stanley

gpio/aspeed: Fix incorrect number of banks

2019-09-10T17:29:57+00:00

The current calculation for the number of GPIO banks is only correct if the number of GPIOs is a multiple of 32 (if there were 31 GPIOs we would currently say there are 0 banks, which is incorrect). OpenBMC-Staging-Count: 1 Fixes: 361b79119a4b7 ('gpio: Add Aspeed driver') Signed-off-by: Rashmica Gupta Reviewed-by: Andrew Jeffery Reviewed-by: Joel Stanley Signed-off-by: Joel Stanley

gpio: aspeed: Pass irqchip when adding gpiochip

2019-09-10T17:29:49+00:00

We need to convert all old gpio irqchips to pass the irqchip setup along when adding the gpio_chip. For more info see drivers/gpio/TODO. For chained irqchips this is a pretty straight-forward conversion. Cc: Joel Stanley Cc: Andrew Jeffery Cc: Benjamin Herrenschmidt Cc: Thierry Reding Link: https://lore.kernel.org/r/20190809125515.19094-1-linus.walleij@linaro.org Reviewed-by: Andrew Jeffery Tested-by: Andrew Jeffery Acked-by: Joel Stanley Signed-off-by: Linus Walleij (cherry picked from commit 8512ee31926296fd7d65c1b3c97bb20d67e7eb2a) Signed-off-by: Joel Stanley

Merge tag 'v5.2.14' into dev-5.2

2019-09-10T13:43:25+00:00

This is the 5.2.14 stable release Signed-off-by: Joel Stanley

Revert "mmc: core: do not retry CMD6 in __mmc_switch()"

2019-09-10T09:35:26+00:00

commit 8ad8e02c2fa70cfddc1ded53ba9001c9d444075d upstream. Turns out the commit 3a0681c7448b ("mmc: core: do not retry CMD6 in __mmc_switch()") breaks initialization of a Toshiba THGBMNG5 eMMC card, when using the meson-gx-mmc.c driver on a custom board based on Amlogic A113D. The CMD6 that switches the card into HS200 mode is then one that fails and according to the below printed messages from the log: [ 1.648951] mmc0: mmc_select_hs200 failed, error -84 [ 1.648988] mmc0: error -84 whilst initialising MMC card After some analyze, it turns out that adding a delay of ~5ms inside mmc_select_bus_width() but after mmc_compare_ext_csds() has been executed, also fixes the problem. Adding yet some more debug code, trying to figure out if potentially the card could be in a busy state, both by using CMD13 and ->card_busy() ops concluded that this was not the case. Therefore, let's simply revert the commit that dropped support for retrying of CMD6, as this also fixes the problem. Fixes: 3a0681c7448b ("mmc: core: do not retry CMD6 in __mmc_switch()") Cc: stable@vger.kernel.org Signed-off-by: Jan Kaisrlik Signed-off-by: Ulf Hansson Signed-off-by: Greg Kroah-Hartman

gpio: Fix irqchip initialization order

2019-09-10T09:35:25+00:00

[ Upstream commit 48057ed1840fde9239b1e000bea1a0a1f07c5e99 ] The new API for registering a gpio_irq_chip along with a gpio_chip has a different semantic ordering than the old API which added the irqchip explicitly after registering the gpio_chip. Move the calls to add the gpio_irq_chip *last* in the function, so that the different hooks setting up OF and ACPI and machine gpio_chips are called *before* we try to register the interrupts, preserving the elder semantic order. This cropped up in the PL061 driver which used to work fine with no special ACPI quirks, but started to misbehave using the new API. Fixes: e0d897289813 ("gpio: Implement tighter IRQ chip integration") Cc: Thierry Reding Cc: Grygorii Strashko Cc: Andy Shevchenko Reported-by: Wei Xu Tested-by: Wei Xu Reported-by: Andy Shevchenko Signed-off-by: Linus Walleij Link: https://lore.kernel.org/r/20190820080527.11796-1-linus.walleij@linaro.org Signed-off-by: Sasha Levin

RDMA/bnxt_re: Fix stack-out-of-bounds in bnxt_qplib_rcfw_send_message

2019-09-10T09:35:25+00:00

[ Upstream commit d37b1e534071ab1983e7c85273234b132c77591a ] Driver copies FW commands to the HW queue as units of 16 bytes. Some of the command structures are not exact multiple of 16. So while copying the data from those structures, the stack out of bounds messages are reported by KASAN. The following error is reported. [ 1337.530155] ================================================================== [ 1337.530277] BUG: KASAN: stack-out-of-bounds in bnxt_qplib_rcfw_send_message+0x40a/0x850 [bnxt_re] [ 1337.530413] Read of size 16 at addr ffff888725477a48 by task rmmod/2785 [ 1337.530540] CPU: 5 PID: 2785 Comm: rmmod Tainted: G OE 5.2.0-rc6+ #75 [ 1337.530541] Hardware name: Dell Inc. PowerEdge R730/0599V5, BIOS 1.0.4 08/28/2014 [ 1337.530542] Call Trace: [ 1337.530548] dump_stack+0x5b/0x90 [ 1337.530556] ? bnxt_qplib_rcfw_send_message+0x40a/0x850 [bnxt_re] [ 1337.530560] print_address_description+0x65/0x22e [ 1337.530568] ? bnxt_qplib_rcfw_send_message+0x40a/0x850 [bnxt_re] [ 1337.530575] ? bnxt_qplib_rcfw_send_message+0x40a/0x850 [bnxt_re] [ 1337.530577] __kasan_report.cold.3+0x37/0x77 [ 1337.530581] ? _raw_write_trylock+0x10/0xe0 [ 1337.530588] ? bnxt_qplib_rcfw_send_message+0x40a/0x850 [bnxt_re] [ 1337.530590] kasan_report+0xe/0x20 [ 1337.530592] memcpy+0x1f/0x50 [ 1337.530600] bnxt_qplib_rcfw_send_message+0x40a/0x850 [bnxt_re] [ 1337.530608] ? bnxt_qplib_creq_irq+0xa0/0xa0 [bnxt_re] [ 1337.530611] ? xas_create+0x3aa/0x5f0 [ 1337.530613] ? xas_start+0x77/0x110 [ 1337.530615] ? xas_clear_mark+0x34/0xd0 [ 1337.530623] bnxt_qplib_free_mrw+0x104/0x1a0 [bnxt_re] [ 1337.530631] ? bnxt_qplib_destroy_ah+0x110/0x110 [bnxt_re] [ 1337.530633] ? bit_wait_io_timeout+0xc0/0xc0 [ 1337.530641] bnxt_re_dealloc_mw+0x2c/0x60 [bnxt_re] [ 1337.530648] bnxt_re_destroy_fence_mr+0x77/0x1d0 [bnxt_re] [ 1337.530655] bnxt_re_dealloc_pd+0x25/0x60 [bnxt_re] [ 1337.530677] ib_dealloc_pd_user+0xbe/0xe0 [ib_core] [ 1337.530683] srpt_remove_one+0x5de/0x690 [ib_srpt] [ 1337.530689] ? __srpt_close_all_ch+0xc0/0xc0 [ib_srpt] [ 1337.530692] ? xa_load+0x87/0xe0 ... [ 1337.530840] do_syscall_64+0x6d/0x1f0 [ 1337.530843] entry_SYSCALL_64_after_hwframe+0x44/0xa9 [ 1337.530845] RIP: 0033:0x7ff5b389035b [ 1337.530848] Code: 73 01 c3 48 8b 0d 2d 0b 2c 00 f7 d8 64 89 01 48 83 c8 ff c3 66 2e 0f 1f 84 00 00 00 00 00 90 f3 0f 1e fa b8 b0 00 00 00 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 8b 0d fd 0a 2c 00 f7 d8 64 89 01 48 [ 1337.530849] RSP: 002b:00007fff83425c28 EFLAGS: 00000206 ORIG_RAX: 00000000000000b0 [ 1337.530852] RAX: ffffffffffffffda RBX: 00005596443e6750 RCX: 00007ff5b389035b [ 1337.530853] RDX: 000000000000000a RSI: 0000000000000800 RDI: 00005596443e67b8 [ 1337.530854] RBP: 0000000000000000 R08: 00007fff83424ba1 R09: 0000000000000000 [ 1337.530856] R10: 00007ff5b3902960 R11: 0000000000000206 R12: 00007fff83425e50 [ 1337.530857] R13: 00007fff8342673c R14: 00005596443e6260 R15: 00005596443e6750 [ 1337.530885] The buggy address belongs to the page: [ 1337.530962] page:ffffea001c951dc0 refcount:0 mapcount:0 mapping:0000000000000000 index:0x0 [ 1337.530964] flags: 0x57ffffc0000000() [ 1337.530967] raw: 0057ffffc0000000 0000000000000000 ffffffff1c950101 0000000000000000 [ 1337.530970] raw: 0000000000000000 0000000000000000 00000000ffffffff 0000000000000000 [ 1337.530970] page dumped because: kasan: bad access detected [ 1337.530996] Memory state around the buggy address: [ 1337.531072] ffff888725477900: 00 00 00 00 f1 f1 f1 f1 00 00 00 00 00 f2 f2 f2 [ 1337.531180] ffff888725477980: 00 00 00 00 00 00 00 00 00 00 00 f1 f1 f1 f1 00 [ 1337.531288] >ffff888725477a00: 00 f2 f2 f2 f2 f2 f2 00 00 00 f2 00 00 00 00 00 [ 1337.531393] ^ [ 1337.531478] ffff888725477a80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [ 1337.531585] ffff888725477b00: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [ 1337.531691] ================================================================== Fix this by passing the exact size of each FW command to bnxt_qplib_rcfw_send_message as req->cmd_size. Before sending the command to HW, modify the req->cmd_size to number of 16 byte units. Fixes: 1ac5a4047975 ("RDMA/bnxt_re: Add bnxt_re RoCE driver") Signed-off-by: Selvin Xavier Link: https://lore.kernel.org/r/1566468170-489-1-git-send-email-selvin.xavier@broadcom.com Signed-off-by: Doug Ledford Signed-off-by: Sasha Levin

drm/amdgpu: prevent memory leaks in AMDGPU_CS ioctl

2019-09-10T09:35:23+00:00

[ Upstream commit 1a701ea924815b0518733aa8d5d05c1f6fa87062 ] Error out if the AMDGPU_CS ioctl is called with multiple SYNCOBJ_OUT and/or TIMELINE_SIGNAL chunks, since otherwise the last chunk wins while the allocated array as well as the reference counts of sync objects are leaked. Signed-off-by: Nicolai Hähnle Reviewed-by: Christian König Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin