linux-stable.git/drivers/staging, branch v5.19.8

staging: r8188eu: add firmware dependency

2022-09-08T09:24:01+00:00

commit b2fa9e13bbf101c662c4cd974608242a0db98cfc upstream.

The old rtl8188eu module, removed in commit 55dfa29b43d2 ("staging:
rtl8188eu: remove rtl8188eu driver from staging dir") (Linux kernel
v5.15-rc1), required (through a MODULE_FIRMWARE call()) the
rtlwifi/rtl8188eufw.bin firmware file, which the new r8188eu driver no
longer requires.

I have tested a few RTL8188EUS-based Wi-Fi cards and, while supported by
both drivers, they do not work when using the new one and the firmware
wasn't manually loaded. According to Larry Finger, the module
maintainer, all such cards need the firmware and the driver should
depend on it (see the linked mails).

Add a proper MODULE_FIRMWARE() call, like it was done in the old driver.

Thanks to Greg Kroah-Hartman and Larry Finger for quick responses to my
questions.

Cc: stable 
Link: https://answers.launchpad.net/ubuntu/+source/linux-meta-hwe-5.15/+question/702611
Link: https://lore.kernel.org/lkml/YukkBu3TNODO3or9@nx64de-df6d00/
Signed-off-by: Grzegorz Szymaszek 
Link: https://lore.kernel.org/r/YulcdKfhA8dPQ78s@nx64de-df6d00
Acked-by: Phillip Potter 
Acked-by: Larry Finger 
Signed-off-by: Greg Kroah-Hartman

staging: r8188eu: Add Rosewill USB-N150 Nano to device tables

2022-09-08T09:24:01+00:00

commit e01f5c8d6af231b3b09e23c1fe8a4057cdcc4e42 upstream.

This device is reported as using the RTL8188EUS chip.

It has the improbable USB ID of 0bda:ffef, which normally would belong
to Realtek, but this ID works for the reporter.

Signed-off-by: Larry Finger 
Cc: stable 
Link: https://lore.kernel.org/r/20220814175027.2689-1-Larry.Finger@lwfinger.net
Signed-off-by: Greg Kroah-Hartman

staging: rtl8712: fix use after free bugs

2022-09-08T09:24:01+00:00

commit e230a4455ac3e9b112f0367d1b8e255e141afae0 upstream.

_Read/Write_MACREG callbacks are NULL so the read/write_macreg_hdl()
functions don't do anything except free the "pcmd" pointer.  It
results in a use after free.  Delete them.

Fixes: 2865d42c78a9 ("staging: r8712u: Add the new driver to the mainline kernel")
Cc: stable 
Reported-by: Zheng Wang 
Signed-off-by: Dan Carpenter 
Link: https://lore.kernel.org/r/Yw4ASqkYcUhUfoY2@kili
Signed-off-by: Greg Kroah-Hartman

staging: r8188eu: add error handling of rtw_read32

2022-08-25T09:45:40+00:00

[ Upstream commit b9c5e272062708680d47df433bfbfe5299ad1a63 ]

rtw_read32() reads data from device via USB API which may fail. In case
of any failure previous code returned stack data to callers, which is
wrong.

Fix it by changing rtw_read32() prototype and prevent caller from
touching random stack data

Signed-off-by: Pavel Skripkin 
Link: https://lore.kernel.org/r/583c3d21c46066275e4fc8da5ba4fd0e3679335b.1654629778.git.paskripkin@gmail.com
Signed-off-by: Greg Kroah-Hartman 
Signed-off-by: Sasha Levin

staging: r8188eu: add error handling of rtw_read16

2022-08-25T09:45:40+00:00

[ Upstream commit fed9e604eeb6150847d9757f6b056c12912d468b ]

rtw_read16() reads data from device via USB API which may fail. In case
of any failure previous code returned stack data to callers, which is
wrong.

Fix it by changing rtw_read16() prototype and prevent caller from
touching random stack data

Signed-off-by: Pavel Skripkin 
Link: https://lore.kernel.org/r/06b45afda048d0aeddeed983c2318680fe6265f5.1654629778.git.paskripkin@gmail.com
Signed-off-by: Greg Kroah-Hartman 
Signed-off-by: Sasha Levin

staging: r8188eu: add error handling of rtw_read8

2022-08-25T09:45:40+00:00

[ Upstream commit 857fe9e5efc09833fe1110e99d8baba954a86abb ]

rtw_read8() reads data from device via USB API which may fail. In case
of any failure previous code returned stack data to callers, which is
wrong.

Fix it by changing rtw_read8() prototype and prevent caller from
touching random stack data

Signed-off-by: Pavel Skripkin 
Link: https://lore.kernel.org/r/c8f8ef4f14db3ba2478a87d5be6eb768a093dfaf.1654629778.git.paskripkin@gmail.com
Signed-off-by: Greg Kroah-Hartman 
Signed-off-by: Sasha Levin

staging: fbtft: core: set smem_len before fb_deferred_io_init call

2022-08-17T13:15:38+00:00

[ Upstream commit 81e878887ff82a7dd42f22951391069a5d520627 ]

The fbtft_framebuffer_alloc() calls fb_deferred_io_init() before
initializing info->fix.smem_len.  It is set to zero by the
framebuffer_alloc() function.  It will trigger a WARN_ON() at the
start of fb_deferred_io_init() and the function will not do anything.

Fixes: 856082f021a2 ("fbdev: defio: fix the pagelist corruption")
Signed-off-by: Peter Suti 
Link: https://lore.kernel.org/r/20220727073550.1491126-1-peter.suti@streamunlimited.com
Signed-off-by: Greg Kroah-Hartman 
Signed-off-by: Sasha Levin

staging: rtl8192u: Fix sleep in atomic context bug in dm_fsync_timer_callback

2022-08-17T13:15:30+00:00

[ Upstream commit 6a0c054930d554ad8f8044ef1fc856d9da391c81 ]

There are sleep in atomic context bugs when dm_fsync_timer_callback is
executing. The root cause is that the memory allocation functions with
GFP_KERNEL or GFP_NOIO parameters are called in dm_fsync_timer_callback
which is a timer handler. The call paths that could trigger bugs are
shown below:

    (interrupt context)
dm_fsync_timer_callback
  write_nic_byte
    kzalloc(sizeof(data), GFP_KERNEL); //may sleep
    usb_control_msg
      kmalloc(.., GFP_NOIO); //may sleep
  write_nic_dword
    kzalloc(sizeof(data), GFP_KERNEL); //may sleep
    usb_control_msg
      kmalloc(.., GFP_NOIO); //may sleep

This patch uses delayed work to replace timer and moves the operations
that may sleep into the delayed work in order to mitigate bugs.

Fixes: 8fc8598e61f6 ("Staging: Added Realtek rtl8192u driver to staging")
Signed-off-by: Duoming Zhou 
Link: https://lore.kernel.org/r/20220710103002.63283-1-duoming@zju.edu.cn
Signed-off-by: Greg Kroah-Hartman 
Signed-off-by: Sasha Levin

hantro: Remove incorrect HEVC SPS validation

2022-08-17T13:14:56+00:00

[ Upstream commit df9ec2fc8e70e01532fd9161cd98711969561ff6 ]

Currently, the driver tries to validat the HEVC SPS
against the CAPTURE queue format (i.e. the decoded format).
This is not correct, because typically the SPS control is set
before the CAPTURE queue is negotiated.

Fixes: 135ad96cb4d6b ("media: hantro: Be more accurate on pixel formats step_width constraints")
Signed-off-by: Ezequiel Garcia 
Signed-off-by: Hans Verkuil 
Signed-off-by: Mauro Carvalho Chehab 
Signed-off-by: Sasha Levin

media: cedrus: hevc: Add check for invalid timestamp

2022-08-17T13:14:55+00:00

[ Upstream commit 143201a6435bf65f0115435e9dc6d95c66b908e9 ]

Not all DPB entries will be used most of the time. Unused entries will
thus have invalid timestamps. They will produce negative buffer index
which is not specifically handled. This works just by chance in current
code. It will even produce bogus pointer, but since it's not used, it
won't do any harm.

Let's fix that brittle design by skipping writing DPB entry altogether
if timestamp is invalid.

Fixes: 86caab29da78 ("media: cedrus: Add HEVC/H.265 decoding support")
Signed-off-by: Jernej Skrabec 
Reviewed-by: Ezequiel Garcia 
Signed-off-by: Hans Verkuil 
Signed-off-by: Mauro Carvalho Chehab 
Signed-off-by: Sasha Levin