linux-stable.git/drivers, branch v4.9.284

drm/nouveau/nvkm: Replace -ENOSYS with -ENODEV

2021-09-26T11:36:19+00:00

commit e8f71f89236ef82d449991bfbc237e3cb6ea584f upstream.

nvkm test builds fail with the following error.

  drivers/gpu/drm/nouveau/nvkm/engine/device/ctrl.c: In function 'nvkm_control_mthd_pstate_info':
  drivers/gpu/drm/nouveau/nvkm/engine/device/ctrl.c:60:35: error: overflow in conversion from 'int' to '__s8' {aka 'signed char'} changes value from '-251' to '5'

The code builds on most architectures, but fails on parisc where ENOSYS
is defined as 251.

Replace the error code with -ENODEV (-19).  The actual error code does
not really matter and is not passed to userspace - it just has to be
negative.

Fixes: 7238eca4cf18 ("drm/nouveau: expose pstate selection per-power source in sysfs")
Signed-off-by: Guenter Roeck 
Cc: Ben Skeggs 
Cc: David Airlie 
Cc: Daniel Vetter 
Signed-off-by: Linus Torvalds 
Signed-off-by: Greg Kroah-Hartman

dmaengine: xilinx_dma: Set DMA mask for coherent APIs

2021-09-26T11:36:18+00:00

[ Upstream commit aac6c0f90799d66b8989be1e056408f33fd99fe6 ]

The xilinx dma driver uses the consistent allocations, so for correct
operation also set the DMA mask for coherent APIs. It fixes the below
kernel crash with dmatest client when DMA IP is configured with 64-bit
address width and linux is booted from high (>4GB) memory.

Call trace:
[  489.531257]  dma_alloc_from_pool+0x8c/0x1c0
[  489.535431]  dma_direct_alloc+0x284/0x330
[  489.539432]  dma_alloc_attrs+0x80/0xf0
[  489.543174]  dma_pool_alloc+0x160/0x2c0
[  489.547003]  xilinx_cdma_prep_memcpy+0xa4/0x180
[  489.551524]  dmatest_func+0x3cc/0x114c
[  489.555266]  kthread+0x124/0x130
[  489.558486]  ret_from_fork+0x10/0x3c
[  489.562051] ---[ end trace 248625b2d596a90a ]---

Signed-off-by: Radhey Shyam Pandey 
Reviewed-by: Harini Katakam 
Link: https://lore.kernel.org/r/1629363528-30347-1-git-send-email-radhey.shyam.pandey@xilinx.com
Signed-off-by: Vinod Koul 
Signed-off-by: Sasha Levin

dmaengine: ioat: depends on !UML

2021-09-26T11:36:18+00:00

[ Upstream commit bbac7a92a46f0876e588722ebe552ddfe6fd790f ]

Now that UML has PCI support, this driver must depend also on
!UML since it pokes at X86_64 architecture internals that don't
exist on ARCH=um.

Reported-by: Geert Uytterhoeven 
Signed-off-by: Johannes Berg 
Acked-by: Dave Jiang 
Link: https://lore.kernel.org/r/20210809112409.a3a0974874d2.I2ffe3d11ed37f735da2f39884a74c953b258b995@changeid
Signed-off-by: Vinod Koul 
Signed-off-by: Sasha Levin

parisc: Move pci_dev_is_behind_card_dino to where it is used

2021-09-26T11:36:18+00:00

[ Upstream commit 907872baa9f1538eed02ec737b8e89eba6c6e4b9 ]

parisc build test images fail to compile with the following error.

drivers/parisc/dino.c:160:12: error:
	'pci_dev_is_behind_card_dino' defined but not used

Move the function just ahead of its only caller to avoid the error.

Fixes: 5fa1659105fa ("parisc: Disable HP HSC-PCI Cards to prevent kernel crash")
Cc: Helge Deller 
Signed-off-by: Guenter Roeck 
Signed-off-by: Helge Deller 
Signed-off-by: Sasha Levin

pwm: lpc32xx: Don't modify HW state in .probe() after the PWM chip was registered

2021-09-26T11:36:18+00:00

commit 3d2813fb17e5fd0d73c1d1442ca0192bde4af10e upstream.

This fixes a race condition: After pwmchip_add() is called there might
already be a consumer and then modifying the hardware behind the
consumer's back is bad. So set the default before.

(Side-note: I don't know what this register setting actually does, if
this modifies the polarity there is an inconsistency because the
inversed polarity isn't considered if the PWM is already running during
.probe().)

Fixes: acfd92fdfb93 ("pwm: lpc32xx: Set PWM_PIN_LEVEL bit to default value")
Cc: Sylvain Lemieux 
Signed-off-by: Uwe Kleine-König 
Signed-off-by: Thierry Reding 
Signed-off-by: Greg Kroah-Hartman

thermal/drivers/exynos: Fix an error code in exynos_tmu_probe()

2021-09-26T11:36:18+00:00

commit 02d438f62c05f0d055ceeedf12a2f8796b258c08 upstream.

This error path return success but it should propagate the negative
error code from devm_clk_get().

Fixes: 6c247393cfdd ("thermal: exynos: Add TMU support for Exynos7 SoC")
Signed-off-by: Dan Carpenter 
Reviewed-by: Krzysztof Kozlowski 
Signed-off-by: Daniel Lezcano 
Link: https://lore.kernel.org/r/20210810084413.GA23810@kili
Signed-off-by: Greg Kroah-Hartman

dmaengine: acpi: Avoid comparison GSI with Linux vIRQ

2021-09-26T11:36:18+00:00

commit 67db87dc8284070adb15b3c02c1c31d5cf51c5d6 upstream.

Currently the CRST parsing relies on the fact that on most of x86 devices
the IRQ mapping is 1:1 with Linux vIRQ. However, it may be not true for
some. Fix this by converting GSI to Linux vIRQ before checking it.

Fixes: ee8209fd026b ("dma: acpi-dma: parse CSRT to extract additional resources")
Signed-off-by: Andy Shevchenko 
Link: https://lore.kernel.org/r/20210730202715.24375-1-andriy.shevchenko@linux.intel.com
Signed-off-by: Vinod Koul 
Signed-off-by: Greg Kroah-Hartman

staging: android: ion: fix page is NULL

2021-09-26T11:36:17+00:00

Fixes: commit e7f63771b60e ("ION: Sys_heap: Add cached pool to spead up cached buffer alloc")
the commit e7f63771b60e introduced the bug which didn't test page which maybe NULL.
and previous logic was right.

the e7f63771b60e has been merged in v4.8-rc3, only longterm 4.9.x has this bug,
and other longterm/stable version have not.

kernel panic is here when page is NULL:

Unable to handle kernel paging request at virtual address b0380000
pgd = d9d94000
[b0380000] *pgd=00000000
Internal error: Oops: 2805 [#1] PREEMPT SMP ARM
...
task: daa2dd00 task.stack: da194000
PC is at v7_dma_clean_range+0x1c/0x34
LR is at arm_dma_sync_single_for_device+0x44/0x58
pc : []    lr : []    psr: 200f0013
sp : da195da0  ip : dc1f9000  fp : c1043dc4
r10: 00000000  r9 : c16f1f58  r8 : 00000001
r7 : c1621f94  r6 : c0116418  r5 : 00000000  r4 : c011aa58
r3 : 0000003f  r2 : 00000040  r1 : b0480000  r0 : b0380000
Flags: nzCv  IRQs on  FIQs on  Mode SVC_32  ISA ARM  Segment none
Control: 10c5383d  Table: 19d9406a  DAC: 00000051
...
[] (v7_dma_clean_range) from [] (arm_dma_sync_single_for_device+0x44/0x58)
[] (arm_dma_sync_single_for_device) from [] (arm_dma_sync_sg_for_device+0x50/0x7c)
[] (arm_dma_sync_sg_for_device) from [] (ion_pages_sync_for_device+0xb0/0xec)
[] (ion_pages_sync_for_device) from [] (ion_system_heap_allocate+0x2a0/0x2e0)
[] (ion_system_heap_allocate) from [] (ion_alloc+0x12c/0x494)
[] (ion_alloc) from [] (ion_ioctl+0x510/0x63c)
[] (ion_ioctl) from [] (do_vfs_ioctl+0xa8/0x9b4)
[] (do_vfs_ioctl) from [] (SyS_ioctl+0x6c/0x7c)
[] (SyS_ioctl) from [] (ret_fast_syscall+0x0/0x48)
Code: e3a02004 e1a02312 e2423001 e1c00003 (ee070f3a)
---[ end trace 89278304932c0e87 ]---
Kernel panic - not syncing: Fatal exception

Signed-off-by: Cheng Chao 
Signed-off-by: Greg Kroah-Hartman

crypto: talitos - fix max key size for sha384 and sha512

2021-09-26T11:36:17+00:00

commit 192125ed5ce62afba24312d8e7a0314577565b4a upstream.

Below commit came with a typo in the CONFIG_ symbol, leading
to a permanently reduced max key size regarless of the driver
capabilities.

Reported-by: Horia Geantă 
Fixes: b8fbdc2bc4e7 ("crypto: talitos - reduce max key size for SEC1")
Signed-off-by: Christophe Leroy 
Reviewed-by: Horia Geantă 
Signed-off-by: Herbert Xu 
Signed-off-by: Nobuhiro Iwamatsu (CIP) 
Signed-off-by: Greg Kroah-Hartman

PM / wakeirq: Fix unbalanced IRQ enable for wakeirq

2021-09-26T11:36:17+00:00

commit 69728051f5bf15efaf6edfbcfe1b5a49a2437918 upstream.

If a device is runtime PM suspended when we enter suspend and has
a dedicated wake IRQ, we can get the following warning:

WARNING: CPU: 0 PID: 108 at kernel/irq/manage.c:526 enable_irq+0x40/0x94
[  102.087860] Unbalanced enable for IRQ 147
...
(enable_irq) from [] (dev_pm_arm_wake_irq+0x4c/0x60)
(dev_pm_arm_wake_irq) from []
 (device_wakeup_arm_wake_irqs+0x58/0x9c)
(device_wakeup_arm_wake_irqs) from []
(dpm_suspend_noirq+0x10/0x48)
(dpm_suspend_noirq) from []
(suspend_devices_and_enter+0x30c/0xf14)
(suspend_devices_and_enter) from []
(enter_state+0xad4/0xbd8)
(enter_state) from [] (pm_suspend+0x38/0x98)
(pm_suspend) from [] (state_store+0x68/0xc8)

This is because the dedicated wake IRQ for the device may have been
already enabled earlier by dev_pm_enable_wake_irq_check().  Fix the
issue by checking for runtime PM suspended status.

This issue can be easily reproduced by setting serial console log level
to zero, letting the serial console idle, and suspend the system from
an ssh terminal.  On resume, dmesg will have the warning above.

The reason why I have not run into this issue earlier has been that I
typically run my PM test cases from on a serial console instead over ssh.

Fixes: c84345597558 (PM / wakeirq: Enable dedicated wakeirq for suspend)
Signed-off-by: Tony Lindgren 
Signed-off-by: Rafael J. Wysocki 
Signed-off-by: Nobuhiro Iwamatsu (CIP) 
Signed-off-by: Greg Kroah-Hartman