--- /dev/null
+From 75d057bda1fbca6ade21378aa45db712e5f7d962 Mon Sep 17 00:00:00 2001
+From: Larry Finger <Larry.Finger@lwfinger.net>
+Date: Tue, 26 May 2020 10:59:08 -0500
+Subject: b43: Fix connection problem with WPA3
+
+From: Larry Finger <Larry.Finger@lwfinger.net>
+
+commit 75d057bda1fbca6ade21378aa45db712e5f7d962 upstream.
+
+Since the driver was first introduced into the kernel, it has only
+handled the ciphers associated with WEP, WPA, and WPA2. It fails with
+WPA3 even though mac80211 can handle those additional ciphers in software,
+b43 did not report that it could handle them. By setting MFP_CAPABLE using
+ieee80211_set_hw(), the problem is fixed.
+
+With this change, b43 will handle the ciphers it knows in hardware,
+and let mac80211 handle the others in software. It is not necessary to
+use the module parameter NOHWCRYPT to turn hardware encryption off.
+Although this change essentially eliminates that module parameter,
+I am choosing to keep it for cases where the hardware is broken,
+and software encryption is required for all ciphers.
+
+Reported-and-tested-by: Rui Salvaterra <rsalvaterra@gmail.com>
+Signed-off-by: Larry Finger <Larry.Finger@lwfinger.net>
+Cc: Stable <stable@vger.kernel.org>
+Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
+Link: https://lore.kernel.org/r/20200526155909.5807-2-Larry.Finger@lwfinger.net
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/net/wireless/broadcom/b43/main.c | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+--- a/drivers/net/wireless/broadcom/b43/main.c
++++ b/drivers/net/wireless/broadcom/b43/main.c
+@@ -5569,7 +5569,7 @@ static struct b43_wl *b43_wireless_init(
+ /* fill hw info */
+ ieee80211_hw_set(hw, RX_INCLUDES_FCS);
+ ieee80211_hw_set(hw, SIGNAL_DBM);
+-
++ ieee80211_hw_set(hw, MFP_CAPABLE);
+ hw->wiphy->interface_modes =
+ BIT(NL80211_IFTYPE_AP) |
+ BIT(NL80211_IFTYPE_MESH_POINT) |
--- /dev/null
+From 6a29d134c04a8acebb7a95251acea7ad7abba106 Mon Sep 17 00:00:00 2001
+From: Larry Finger <Larry.Finger@lwfinger.net>
+Date: Tue, 26 May 2020 10:59:09 -0500
+Subject: b43_legacy: Fix connection problem with WPA3
+
+From: Larry Finger <Larry.Finger@lwfinger.net>
+
+commit 6a29d134c04a8acebb7a95251acea7ad7abba106 upstream.
+
+Since the driver was first introduced into the kernel, it has only
+handled the ciphers associated with WEP, WPA, and WPA2. It fails with
+WPA3 even though mac80211 can handle those additional ciphers in software,
+b43legacy did not report that it could handle them. By setting MFP_CAPABLE using
+ieee80211_set_hw(), the problem is fixed.
+
+With this change, b43legacy will handle the ciphers it knows in hardware,
+and let mac80211 handle the others in software. It is not necessary to
+use the module parameter NOHWCRYPT to turn hardware encryption off.
+Although this change essentially eliminates that module parameter,
+I am choosing to keep it for cases where the hardware is broken,
+and software encryption is required for all ciphers.
+
+Signed-off-by: Larry Finger <Larry.Finger@lwfinger.net>
+Cc: Stable <stable@vger.kernel.org>
+Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
+Link: https://lore.kernel.org/r/20200526155909.5807-3-Larry.Finger@lwfinger.net
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/net/wireless/broadcom/b43legacy/main.c | 1 +
+ 1 file changed, 1 insertion(+)
+
+--- a/drivers/net/wireless/broadcom/b43legacy/main.c
++++ b/drivers/net/wireless/broadcom/b43legacy/main.c
+@@ -3801,6 +3801,7 @@ static int b43legacy_wireless_init(struc
+ /* fill hw info */
+ ieee80211_hw_set(hw, RX_INCLUDES_FCS);
+ ieee80211_hw_set(hw, SIGNAL_DBM);
++ ieee80211_hw_set(hw, MFP_CAPABLE); /* Allow WPA3 in software */
+
+ hw->wiphy->interface_modes =
+ BIT(NL80211_IFTYPE_AP) |
--- /dev/null
+From ec4d3e3a054578de34cd0b587ab8a1ac36f629d9 Mon Sep 17 00:00:00 2001
+From: Larry Finger <Larry.Finger@lwfinger.net>
+Date: Tue, 7 Apr 2020 14:00:43 -0500
+Subject: b43legacy: Fix case where channel status is corrupted
+
+From: Larry Finger <Larry.Finger@lwfinger.net>
+
+commit ec4d3e3a054578de34cd0b587ab8a1ac36f629d9 upstream.
+
+This patch fixes commit 75388acd0cd8 ("add mac80211-based driver for
+legacy BCM43xx devices")
+
+In https://bugzilla.kernel.org/show_bug.cgi?id=207093, a defect in
+b43legacy is reported. Upon testing, thus problem exists on PPC and
+X86 platforms, is present in the oldest kernel tested (3.2), and
+has been present in the driver since it was first added to the kernel.
+
+The problem is a corrupted channel status received from the device.
+Both the internal card in a PowerBook G4 and the PCMCIA version
+(Broadcom BCM4306 with PCI ID 14e4:4320) have the problem. Only Rev, 2
+(revision 4 of the 802.11 core) of the chip has been tested. No other
+devices using b43legacy are available for testing.
+
+Various sources of the problem were considered. Buffer overrun and
+other sources of corruption within the driver were rejected because
+the faulty channel status is always the same, not a random value.
+It was concluded that the faulty data is coming from the device, probably
+due to a firmware bug. As that source is not available, the driver
+must take appropriate action to recover.
+
+At present, the driver reports the error, and them continues to process
+the bad packet. This is believed that to be a mistake, and the correct
+action is to drop the correpted packet.
+
+Fixes: 75388acd0cd8 ("add mac80211-based driver for legacy BCM43xx devices")
+Cc: Stable <stable@vger.kernel.org>
+Signed-off-by: Larry Finger <Larry.Finger@lwfinger.net>
+Reported-and-tested by: F. Erhard <erhard_f@mailbox.org>
+Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
+Link: https://lore.kernel.org/r/20200407190043.1686-1-Larry.Finger@lwfinger.net
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/net/wireless/broadcom/b43legacy/xmit.c | 1 +
+ 1 file changed, 1 insertion(+)
+
+--- a/drivers/net/wireless/broadcom/b43legacy/xmit.c
++++ b/drivers/net/wireless/broadcom/b43legacy/xmit.c
+@@ -558,6 +558,7 @@ void b43legacy_rx(struct b43legacy_wldev
+ default:
+ b43legacywarn(dev->wl, "Unexpected value for chanstat (0x%X)\n",
+ chanstat);
++ goto drop;
+ }
+
+ memcpy(IEEE80211_SKB_RXCB(skb), &status, sizeof(status));
--- /dev/null
+From 81bd5d0c62437c02caac6b3f942fcda874063cb0 Mon Sep 17 00:00:00 2001
+From: =?UTF-8?q?Micha=C5=82=20Miros=C5=82aw?= <mirq-linux@rere.qmqm.pl>
+Date: Thu, 2 Apr 2020 14:55:20 +0200
+Subject: Bluetooth: hci_bcm: fix freeing not-requested IRQ
+MIME-Version: 1.0
+Content-Type: text/plain; charset=UTF-8
+Content-Transfer-Encoding: 8bit
+
+From: Michał Mirosław <mirq-linux@rere.qmqm.pl>
+
+commit 81bd5d0c62437c02caac6b3f942fcda874063cb0 upstream.
+
+When BT module can't be initialized, but it has an IRQ, unloading
+the driver WARNs when trying to free not-yet-requested IRQ. Fix it by
+noting whether the IRQ was requested.
+
+WARNING: CPU: 2 PID: 214 at kernel/irq/devres.c:144 devm_free_irq+0x49/0x4ca
+[...]
+WARNING: CPU: 2 PID: 214 at kernel/irq/manage.c:1746 __free_irq+0x8b/0x27c
+Trying to free already-free IRQ 264
+Modules linked in: hci_uart(-) btbcm bluetooth ecdh_generic ecc libaes
+CPU: 2 PID: 214 Comm: rmmod Tainted: G W 5.6.1mq-00044-ga5f9ea098318-dirty #928
+[...]
+[<b016aefb>] (devm_free_irq) from [<af8ba1ff>] (bcm_close+0x97/0x118 [hci_uart])
+[<af8ba1ff>] (bcm_close [hci_uart]) from [<af8b736f>] (hci_uart_unregister_device+0x33/0x3c [hci_uart])
+[<af8b736f>] (hci_uart_unregister_device [hci_uart]) from [<b035930b>] (serdev_drv_remove+0x13/0x20)
+[<b035930b>] (serdev_drv_remove) from [<b037093b>] (device_release_driver_internal+0x97/0x118)
+[<b037093b>] (device_release_driver_internal) from [<b0370a0b>] (driver_detach+0x2f/0x58)
+[<b0370a0b>] (driver_detach) from [<b036f855>] (bus_remove_driver+0x41/0x94)
+[<b036f855>] (bus_remove_driver) from [<af8ba8db>] (bcm_deinit+0x1b/0x740 [hci_uart])
+[<af8ba8db>] (bcm_deinit [hci_uart]) from [<af8ba86f>] (hci_uart_exit+0x13/0x30 [hci_uart])
+[<af8ba86f>] (hci_uart_exit [hci_uart]) from [<b01900bd>] (sys_delete_module+0x109/0x1d0)
+[<b01900bd>] (sys_delete_module) from [<b0101001>] (ret_fast_syscall+0x1/0x5a)
+[...]
+
+Cc: stable@vger.kernel.org
+Fixes: 6cc4396c8829 ("Bluetooth: hci_bcm: Add wake-up capability")
+Signed-off-by: Michał Mirosław <mirq-linux@rere.qmqm.pl>
+Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/bluetooth/hci_bcm.c | 5 ++++-
+ 1 file changed, 4 insertions(+), 1 deletion(-)
+
+--- a/drivers/bluetooth/hci_bcm.c
++++ b/drivers/bluetooth/hci_bcm.c
+@@ -107,6 +107,7 @@ struct bcm_device {
+ u32 oper_speed;
+ int irq;
+ bool irq_active_low;
++ bool irq_acquired;
+
+ #ifdef CONFIG_PM
+ struct hci_uart *hu;
+@@ -319,6 +320,8 @@ static int bcm_request_irq(struct bcm_da
+ goto unlock;
+ }
+
++ bdev->irq_acquired = true;
++
+ device_init_wakeup(bdev->dev, true);
+
+ pm_runtime_set_autosuspend_delay(bdev->dev,
+@@ -487,7 +490,7 @@ static int bcm_close(struct hci_uart *hu
+ }
+
+ if (bdev) {
+- if (IS_ENABLED(CONFIG_PM) && bdev->irq > 0) {
++ if (IS_ENABLED(CONFIG_PM) && bdev->irq_acquired) {
+ devm_free_irq(bdev->dev, bdev->irq, bdev);
+ device_init_wakeup(bdev->dev, false);
+ pm_runtime_disable(bdev->dev);
--- /dev/null
+From 571cfadcc628dd5591444f7289e27445ea732f4c Mon Sep 17 00:00:00 2001
+From: Weiyi Lu <weiyi.lu@mediatek.com>
+Date: Wed, 27 May 2020 14:25:49 +0800
+Subject: clk: mediatek: assign the initial value to clk_init_data of mtk_mux
+
+From: Weiyi Lu <weiyi.lu@mediatek.com>
+
+commit 571cfadcc628dd5591444f7289e27445ea732f4c upstream.
+
+When some new clock supports are introduced, e.g. [1]
+it might lead to an error although it should be NULL because
+clk_init_data is on the stack and it might have random values
+if using without initialization.
+Add the missing initial value to clk_init_data.
+
+[1] https://android-review.googlesource.com/c/kernel/common/+/1278046
+
+Fixes: a3ae549917f1 ("clk: mediatek: Add new clkmux register API")
+Signed-off-by: Weiyi Lu <weiyi.lu@mediatek.com>
+Reviewed-by: Matthias Brugger <matthias.bgg@gmail.com>
+Cc: <stable@vger.kernel.org>
+Link: https://lore.kernel.org/r/1590560749-29136-1-git-send-email-weiyi.lu@mediatek.com
+Signed-off-by: Stephen Boyd <sboyd@kernel.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/clk/mediatek/clk-mux.c | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+--- a/drivers/clk/mediatek/clk-mux.c
++++ b/drivers/clk/mediatek/clk-mux.c
+@@ -160,7 +160,7 @@ struct clk *mtk_clk_register_mux(const s
+ spinlock_t *lock)
+ {
+ struct mtk_clk_mux *clk_mux;
+- struct clk_init_data init;
++ struct clk_init_data init = {};
+ struct clk *clk;
+
+ clk_mux = kzalloc(sizeof(*clk_mux), GFP_KERNEL);
--- /dev/null
+From 165ae7a8feb53dc47fb041357e4b253bfc927cf9 Mon Sep 17 00:00:00 2001
+From: Kai-Heng Feng <kai.heng.feng@canonical.com>
+Date: Tue, 5 May 2020 12:01:54 +0800
+Subject: igb: Report speed and duplex as unknown when device is runtime suspended
+
+From: Kai-Heng Feng <kai.heng.feng@canonical.com>
+
+commit 165ae7a8feb53dc47fb041357e4b253bfc927cf9 upstream.
+
+igb device gets runtime suspended when there's no link partner. We can't
+get correct speed under that state:
+$ cat /sys/class/net/enp3s0/speed
+1000
+
+In addition to that, an error can also be spotted in dmesg:
+[ 385.991957] igb 0000:03:00.0 enp3s0: PCIe link lost
+
+Since device can only be runtime suspended when there's no link partner,
+we can skip reading register and let the following logic set speed and
+duplex with correct status.
+
+The more generic approach will be wrap get_link_ksettings() with begin()
+and complete() callbacks. However, for this particular issue, begin()
+calls igb_runtime_resume() , which tries to rtnl_lock() while the lock
+is already hold by upper ethtool layer.
+
+So let's take this approach until the igb_runtime_resume() no longer
+needs to hold rtnl_lock.
+
+CC: stable <stable@vger.kernel.org>
+Suggested-by: Alexander Duyck <alexander.duyck@gmail.com>
+Signed-off-by: Kai-Heng Feng <kai.heng.feng@canonical.com>
+Tested-by: Aaron Brown <aaron.f.brown@intel.com>
+Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/net/ethernet/intel/igb/igb_ethtool.c | 3 ++-
+ 1 file changed, 2 insertions(+), 1 deletion(-)
+
+--- a/drivers/net/ethernet/intel/igb/igb_ethtool.c
++++ b/drivers/net/ethernet/intel/igb/igb_ethtool.c
+@@ -143,7 +143,8 @@ static int igb_get_link_ksettings(struct
+ u32 speed;
+ u32 supported, advertising;
+
+- status = rd32(E1000_STATUS);
++ status = pm_runtime_suspended(&adapter->pdev->dev) ?
++ 0 : rd32(E1000_STATUS);
+ if (hw->phy.media_type == e1000_media_type_copper) {
+
+ supported = (SUPPORTED_10baseT_Half |
--- /dev/null
+From bfcba38d95a0aed146a958a84a2177af1459eddc Mon Sep 17 00:00:00 2001
+From: Tomi Valkeinen <tomi.valkeinen@ti.com>
+Date: Wed, 25 Mar 2020 13:20:00 +0100
+Subject: media: ov5640: fix use of destroyed mutex
+
+From: Tomi Valkeinen <tomi.valkeinen@ti.com>
+
+commit bfcba38d95a0aed146a958a84a2177af1459eddc upstream.
+
+v4l2_ctrl_handler_free() uses hdl->lock, which in ov5640 driver is set
+to sensor's own sensor->lock. In ov5640_remove(), the driver destroys the
+sensor->lock first, and then calls v4l2_ctrl_handler_free(), resulting
+in the use of the destroyed mutex.
+
+Fix this by calling moving the mutex_destroy() to the end of the cleanup
+sequence, as there's no need to destroy the mutex as early as possible.
+
+Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
+Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
+Cc: stable@vger.kernel.org # v4.14+
+Reviewed-by: Benoit Parrot <bparrot@ti.com>
+Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com>
+Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/media/i2c/ov5640.c | 4 ++--
+ 1 file changed, 2 insertions(+), 2 deletions(-)
+
+--- a/drivers/media/i2c/ov5640.c
++++ b/drivers/media/i2c/ov5640.c
+@@ -3068,8 +3068,8 @@ static int ov5640_probe(struct i2c_clien
+ free_ctrls:
+ v4l2_ctrl_handler_free(&sensor->ctrls.handler);
+ entity_cleanup:
+- mutex_destroy(&sensor->lock);
+ media_entity_cleanup(&sensor->sd.entity);
++ mutex_destroy(&sensor->lock);
+ return ret;
+ }
+
+@@ -3079,9 +3079,9 @@ static int ov5640_remove(struct i2c_clie
+ struct ov5640_dev *sensor = to_ov5640_dev(sd);
+
+ v4l2_async_unregister_subdev(&sensor->sd);
+- mutex_destroy(&sensor->lock);
+ media_entity_cleanup(&sensor->sd.entity);
+ v4l2_ctrl_handler_free(&sensor->ctrls.handler);
++ mutex_destroy(&sensor->lock);
+
+ return 0;
+ }
--- /dev/null
+From e0a851fe6b9b619527bd928aa93caaddd003f70c Mon Sep 17 00:00:00 2001
+From: Lukas Wunner <lukas@wunner.de>
+Date: Tue, 12 May 2020 14:40:01 +0200
+Subject: serial: 8250: Avoid error message on reprobe
+
+From: Lukas Wunner <lukas@wunner.de>
+
+commit e0a851fe6b9b619527bd928aa93caaddd003f70c upstream.
+
+If the call to uart_add_one_port() in serial8250_register_8250_port()
+fails, a half-initialized entry in the serial_8250ports[] array is left
+behind.
+
+A subsequent reprobe of the same serial port causes that entry to be
+reused. Because uart->port.dev is set, uart_remove_one_port() is called
+for the half-initialized entry and bails out with an error message:
+
+bcm2835-aux-uart 3f215040.serial: Removing wrong port: (null) != (ptrval)
+
+The same happens on failure of mctrl_gpio_init() since commit
+4a96895f74c9 ("tty/serial/8250: use mctrl_gpio helpers").
+
+Fix by zeroing the uart->port.dev pointer in the probe error path.
+
+The bug was introduced in v2.6.10 by historical commit befff6f5bf5f
+("[SERIAL] Add new port registration/unregistration functions."):
+https://git.kernel.org/tglx/history/c/befff6f5bf5f
+
+The commit added an unconditional call to uart_remove_one_port() in
+serial8250_register_port(). In v3.7, commit 835d844d1a28 ("8250_pnp:
+do pnp probe before legacy probe") made that call conditional on
+uart->port.dev which allows me to fix the issue by zeroing that pointer
+in the error path. Thus, the present commit will fix the problem as far
+back as v3.7 whereas still older versions need to also cherry-pick
+835d844d1a28.
+
+Fixes: 835d844d1a28 ("8250_pnp: do pnp probe before legacy probe")
+Signed-off-by: Lukas Wunner <lukas@wunner.de>
+Cc: stable@vger.kernel.org # v2.6.10
+Cc: stable@vger.kernel.org # v2.6.10: 835d844d1a28: 8250_pnp: do pnp probe before legacy
+Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
+Link: https://lore.kernel.org/r/b4a072013ee1a1d13ee06b4325afb19bda57ca1b.1589285873.git.lukas@wunner.de
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/tty/serial/8250/8250_core.c | 14 ++++++++++----
+ 1 file changed, 10 insertions(+), 4 deletions(-)
+
+--- a/drivers/tty/serial/8250/8250_core.c
++++ b/drivers/tty/serial/8250/8250_core.c
+@@ -1026,7 +1026,7 @@ int serial8250_register_8250_port(struct
+ gpios = mctrl_gpio_init(&uart->port, 0);
+ if (IS_ERR(gpios)) {
+ ret = PTR_ERR(gpios);
+- goto out_unlock;
++ goto err;
+ } else {
+ uart->gpios = gpios;
+ }
+@@ -1075,8 +1075,10 @@ int serial8250_register_8250_port(struct
+ serial8250_apply_quirks(uart);
+ ret = uart_add_one_port(&serial8250_reg,
+ &uart->port);
+- if (ret == 0)
+- ret = uart->port.line;
++ if (ret)
++ goto err;
++
++ ret = uart->port.line;
+ } else {
+ dev_info(uart->port.dev,
+ "skipping CIR port at 0x%lx / 0x%llx, IRQ %d\n",
+@@ -1098,10 +1100,14 @@ int serial8250_register_8250_port(struct
+ }
+ }
+
+-out_unlock:
+ mutex_unlock(&serial_mutex);
+
+ return ret;
++
++err:
++ uart->port.dev = NULL;
++ mutex_unlock(&serial_mutex);
++ return ret;
+ }
+ EXPORT_SYMBOL(serial8250_register_8250_port);
+
carl9170-remove-p2p_go-support.patch
media-go7007-fix-a-miss-of-snd_card_free.patch
media-cedrus-program-output-format-during-each-run.patch
+serial-8250-avoid-error-message-on-reprobe.patch
+bluetooth-hci_bcm-fix-freeing-not-requested-irq.patch
+b43legacy-fix-case-where-channel-status-is-corrupted.patch
+b43-fix-connection-problem-with-wpa3.patch
+b43_legacy-fix-connection-problem-with-wpa3.patch
+media-ov5640-fix-use-of-destroyed-mutex.patch
+clk-mediatek-assign-the-initial-value-to-clk_init_data-of-mtk_mux.patch
+igb-report-speed-and-duplex-as-unknown-when-device-is-runtime-suspended.patch
projects / thirdparty / kernel / stable-queue.git / commitdiff
