~vicamo/+git/ubuntu-kernel:bug-1954300/wcn6855-handle-bt-download-fw-failure/jammy

Branch merges

Related source package recipes

No recipes using this branch. (?)

Create packaging recipe

Related snap packages

Related charm recipes

7104f51... by Mark-YW.Chen on 2021-12-06

UBUNTU: SAUCE: Bluetooth: btusb: Return error code when getting patch status failed

BugLink: https://bugs.launchpad.net/bugs/1954300

If there are failure cases in getting patch status, it should return the
error code (-EIO).

Fixes: fc342c4dc4087 ("Bluetooth: btusb: Add protocol support for MediaTek MT7921U USB devices")
Co-developed-by: Sean Wang <email address hidden>
Signed-off-by: Sean Wang <email address hidden>
Signed-off-by: Mark Chen <email address hidden>
Signed-off-by: Marcel Holtmann <email address hidden>
(backported from
https://git.kernel.org/pub/scm/linux/kernel/git/bluetooth/bluetooth-next.git/commit/?id=995d948cf2e45834275f07afc1c9881a9902e73c)
Signed-off-by: You-Sheng Yang <email address hidden>

cd913c7... by Mark-YW.Chen on 2021-12-06

UBUNTU: SAUCE: Bluetooth: btusb: Handle download_firmware failure cases

BugLink: https://bugs.launchpad.net/bugs/1954300

For Mediatek chipset, it can not enabled if there are something wrong
in btmtk_setup_firmware_79xx(). Thus, the process must be terminated
and returned error code.

Fixes: fc342c4dc4087 ("Bluetooth: btusb: Add protocol support for MediaTek MT7921U USB devices")
Co-developed-by: Sean Wang <email address hidden>
Signed-off-by: Sean Wang <email address hidden>
Signed-off-by: Mark Chen <email address hidden>
Signed-off-by: Marcel Holtmann <email address hidden>
(backported from
https://git.kernel.org/pub/scm/linux/kernel/git/bluetooth/bluetooth-next.git/commit/?id=00c0ee9850b7b0cb7c40b8daba806ae2245e59d4)
Signed-off-by: You-Sheng Yang <email address hidden>

748b150... by Paolo Pisati on 2021-12-10

Revert "UBUNTU: SAUCE: vt -- maintain bootloader screen mode and content until vt switch"

Upstream FRAMEBUFFER_CONSOLE_DEFERRED_TAKEOVER supersedes this SAUCE
patch.

This reverts commit 320cfac8ef319a24d1f6871b2b1e85fa2c3681aa.

Signed-off-by: Paolo Pisati <email address hidden>

83a2f07... by Paolo Pisati on 2021-12-09

Revert "UBUNTU: [Config] Temporarily disable signing for ppc64el and s390x"

This reverts commit e522620714658df68e4938a39e8a3325ece77f48.

Signed-off-by: Paolo Pisati <email address hidden>

3f05582... by Greg Kroah-Hartman <email address hidden> on 2021-12-08

Linux 5.15.7

BugLink: https://bugs.launchpad.net/bugs/1953731

Link: https://<email address hidden>
Tested-by: Florian Fainelli <email address hidden>
Tested-by: Ronald Warsow <email address hidden>
Tested-by: Shuah Khan <email address hidden>
Tested-by: Fox Chen <email address hidden>
Tested-by: Linux Kernel Functional Testing <email address hidden>
Tested-by: Jon Hunter <email address hidden>
Tested-by: Rudi Heitbaum <email address hidden>
Tested-by: Guenter Roeck <email address hidden>
Signed-off-by: Greg Kroah-Hartman <email address hidden>
Signed-off-by: Paolo Pisati <email address hidden>

1b8a0d6... by Wei Yongjun <email address hidden> on 2021-11-23

ipmi: msghandler: Make symbol 'remove_work_wq' static

BugLink: https://bugs.launchpad.net/bugs/1953731

commit 5a3ba99b62d8486de0316334e72ac620d4b94fdd upstream.

The sparse tool complains as follows:

drivers/char/ipmi/ipmi_msghandler.c:194:25: warning:
 symbol 'remove_work_wq' was not declared. Should it be static?

This symbol is not used outside of ipmi_msghandler.c, so
marks it static.

Fixes: 1d49eb91e86e ("ipmi: Move remove_work to dedicated workqueue")
Reported-by: Hulk Robot <email address hidden>
Signed-off-by: Wei Yongjun <email address hidden>
Message-Id: <email address hidden>
Signed-off-by: Corey Minyard <email address hidden>
Signed-off-by: Greg Kroah-Hartman <email address hidden>
Signed-off-by: Paolo Pisati <email address hidden>

0cb4288... by Johan Hovold <email address hidden> on 2021-11-17

serial: liteuart: fix minor-number leak on probe errors

BugLink: https://bugs.launchpad.net/bugs/1953731

commit dd5e90b16cca8a697cbe17b72e2a5f49291cabb2 upstream.

Make sure to release the allocated minor number before returning on
probe errors.

Fixes: 1da81e5562fa ("drivers/tty/serial: add LiteUART driver")
Cc: <email address hidden> # 5.11
Cc: Filip Kokosinski <email address hidden>
Cc: Mateusz Holenko <email address hidden>
Reviewed-by: Stafford Horne <email address hidden>
Reviewed-by: Andy Shevchenko <email address hidden>
Signed-off-by: Johan Hovold <email address hidden>
Link: https://<email address hidden>
Signed-off-by: Greg Kroah-Hartman <email address hidden>
Signed-off-by: Paolo Pisati <email address hidden>

5762b52... by Johan Hovold <email address hidden> on 2021-11-17

serial: liteuart: fix use-after-free and memleak on unbind

BugLink: https://bugs.launchpad.net/bugs/1953731

commit 05f929b395dec8957b636ff14e66b277ed022ed9 upstream.

Deregister the port when unbinding the driver to prevent it from being
used after releasing the driver data and leaking memory allocated by
serial core.

Fixes: 1da81e5562fa ("drivers/tty/serial: add LiteUART driver")
Cc: <email address hidden> # 5.11
Cc: Filip Kokosinski <email address hidden>
Cc: Mateusz Holenko <email address hidden>
Reviewed-by: Stafford Horne <email address hidden>
Reviewed-by: Andy Shevchenko <email address hidden>
Signed-off-by: Johan Hovold <email address hidden>
Link: https://<email address hidden>
Signed-off-by: Greg Kroah-Hartman <email address hidden>
Signed-off-by: Paolo Pisati <email address hidden>

4172bad... by Ilia Sergachev <email address hidden> on 2021-11-15

serial: liteuart: Fix NULL pointer dereference in ->remove()

BugLink: https://bugs.launchpad.net/bugs/1953731

commit 0f55f89d98c8b3e12b4f55f71c127a173e29557c upstream.

drvdata has to be set in _probe() - otherwise platform_get_drvdata()
causes null pointer dereference BUG in _remove().

Fixes: 1da81e5562fa ("drivers/tty/serial: add LiteUART driver")
Cc: stable <email address hidden>
Reviewed-by: Johan Hovold <email address hidden>
Signed-off-by: Ilia Sergachev <email address hidden>
Link: https://lore.kernel.org/r/20211115224944.23f8c12b@dtkw
Signed-off-by: Greg Kroah-Hartman <email address hidden>
Signed-off-by: Paolo Pisati <email address hidden>

7fd45cb... by Lukas Wunner <email address hidden> on 2021-11-22

serial: 8250: Fix RTS modem control while in rs485 mode

BugLink: https://bugs.launchpad.net/bugs/1953731

commit f85e04503f369b3f2be28c83fc48b74e19936ebc upstream.

Commit f45709df7731 ("serial: 8250: Don't touch RTS modem control while
in rs485 mode") sought to prevent user space from interfering with rs485
communication by ignoring a TIOCMSET ioctl() which changes RTS polarity.

It did so in serial8250_do_set_mctrl(), which turns out to be too deep
in the call stack: When a uart_port is opened, RTS polarity is set by
the rs485-aware function uart_port_dtr_rts(). It calls down to
serial8250_do_set_mctrl() and that particular RTS polarity change should
*not* be ignored.

The user-visible result is that on 8250_omap ports which use rs485 with
inverse polarity (RTS bit in MCR register is 1 to receive, 0 to send),
a newly opened port initially sets up RTS for sending instead of
receiving. That's because omap_8250_startup() sets the cached value
up->mcr to 0 and omap_8250_restore_regs() subsequently writes it to the
MCR register. Due to the commit, serial8250_do_set_mctrl() preserves
that incorrect register value:

do_sys_openat2
  do_filp_open
    path_openat
      vfs_open
        do_dentry_open
   chrdev_open
     tty_open
       uart_open
         tty_port_open
    uart_port_activate
      uart_startup
        uart_port_startup
          serial8250_startup
     omap_8250_startup # up->mcr = 0
   uart_change_speed
     serial8250_set_termios
       omap_8250_set_termios
         omap_8250_restore_regs
           serial8250_out_MCR # up->mcr written
    tty_port_block_til_ready
      uart_dtr_rts
        uart_port_dtr_rts
          serial8250_set_mctrl
     omap8250_set_mctrl
       serial8250_do_set_mctrl # mcr[1] = 1 ignored

Fix by intercepting RTS changes from user space in uart_tiocmset()
instead.

Link: https://lore<email address hidden>/
Fixes: f45709df7731 ("serial: 8250: Don't touch RTS modem control while in rs485 mode")
Cc: Chao Zeng <email address hidden>
Cc: <email address hidden> # v5.7+
Reported-by: Su Bao Cheng <email address hidden>
Reported-by: Jan Kiszka <email address hidden>
Tested-by: Su Bao Cheng <email address hidden>
Signed-off-by: Lukas Wunner <email address hidden>
Link: https://lore.kernel.org<email address hidden>
Signed-off-by: Greg Kroah-Hartman <email address hidden>
Signed-off-by: Paolo Pisati <email address hidden>