--- /dev/null
+From 737e65c7956795b3553781fb7bc82fce1c39503f Mon Sep 17 00:00:00 2001
+From: Fabio Estevam <festevam@gmail.com>
+Date: Wed, 24 Nov 2021 15:45:41 -0300
+Subject: ARM: dts: imx6ull-pinfunc: Fix CSI_DATA07__ESAI_TX0 pad name
+
+From: Fabio Estevam <festevam@gmail.com>
+
+commit 737e65c7956795b3553781fb7bc82fce1c39503f upstream.
+
+According to the i.MX6ULL Reference Manual, pad CSI_DATA07 may
+have the ESAI_TX0 functionality, not ESAI_T0.
+
+Also, NXP's i.MX Config Tools 10.0 generates dtsi with the
+MX6ULL_PAD_CSI_DATA07__ESAI_TX0 naming, so fix it accordingly.
+
+There are no devicetree users in mainline that use the old name,
+so just remove the old entry.
+
+Fixes: c201369d4aa5 ("ARM: dts: imx6ull: add imx6ull support")
+Reported-by: George Makarov <georgemakarov1@gmail.com>
+Signed-off-by: Fabio Estevam <festevam@gmail.com>
+Signed-off-by: Shawn Guo <shawnguo@kernel.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ arch/arm/boot/dts/imx6ull-pinfunc.h | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+--- a/arch/arm/boot/dts/imx6ull-pinfunc.h
++++ b/arch/arm/boot/dts/imx6ull-pinfunc.h
+@@ -82,6 +82,6 @@
+ #define MX6ULL_PAD_CSI_DATA04__ESAI_TX_FS 0x01F4 0x0480 0x0000 0x9 0x0
+ #define MX6ULL_PAD_CSI_DATA05__ESAI_TX_CLK 0x01F8 0x0484 0x0000 0x9 0x0
+ #define MX6ULL_PAD_CSI_DATA06__ESAI_TX5_RX0 0x01FC 0x0488 0x0000 0x9 0x0
+-#define MX6ULL_PAD_CSI_DATA07__ESAI_T0 0x0200 0x048C 0x0000 0x9 0x0
++#define MX6ULL_PAD_CSI_DATA07__ESAI_TX0 0x0200 0x048C 0x0000 0x9 0x0
+
+ #endif /* __DTS_IMX6ULL_PINFUNC_H */
--- /dev/null
+From 44870a9e7a3c24acbb3f888b2a7cc22c9bdf7e7f Mon Sep 17 00:00:00 2001
+From: Pavel Skripkin <paskripkin@gmail.com>
+Date: Thu, 19 Aug 2021 12:42:21 +0200
+Subject: media: mxl111sf: change mutex_init() location
+
+From: Pavel Skripkin <paskripkin@gmail.com>
+
+commit 44870a9e7a3c24acbb3f888b2a7cc22c9bdf7e7f upstream.
+
+Syzbot reported, that mxl111sf_ctrl_msg() uses uninitialized
+mutex. The problem was in wrong mutex_init() location.
+
+Previous mutex_init(&state->msg_lock) call was in ->init() function, but
+dvb_usbv2_init() has this order of calls:
+
+ dvb_usbv2_init()
+ dvb_usbv2_adapter_init()
+ dvb_usbv2_adapter_frontend_init()
+ props->frontend_attach()
+
+ props->init()
+
+Since mxl111sf_* devices call mxl111sf_ctrl_msg() in ->frontend_attach()
+internally we need to initialize state->msg_lock before
+frontend_attach(). To achieve it, ->probe() call added to all mxl111sf_*
+devices, which will simply initiaize mutex.
+
+Reported-and-tested-by: syzbot+5ca0bf339f13c4243001@syzkaller.appspotmail.com
+
+Fixes: 8572211842af ("[media] mxl111sf: convert to new DVB USB")
+Signed-off-by: Pavel Skripkin <paskripkin@gmail.com>
+Signed-off-by: Sean Young <sean@mess.org>
+Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/media/usb/dvb-usb-v2/mxl111sf.c | 16 ++++++++++++++--
+ 1 file changed, 14 insertions(+), 2 deletions(-)
+
+--- a/drivers/media/usb/dvb-usb-v2/mxl111sf.c
++++ b/drivers/media/usb/dvb-usb-v2/mxl111sf.c
+@@ -931,8 +931,6 @@ static int mxl111sf_init(struct dvb_usb_
+ .len = sizeof(eeprom), .buf = eeprom },
+ };
+
+- mutex_init(&state->msg_lock);
+-
+ ret = get_chip_info(state);
+ if (mxl_fail(ret))
+ pr_err("failed to get chip info during probe");
+@@ -1074,6 +1072,14 @@ static int mxl111sf_get_stream_config_dv
+ return 0;
+ }
+
++static int mxl111sf_probe(struct dvb_usb_device *dev)
++{
++ struct mxl111sf_state *state = d_to_priv(dev);
++
++ mutex_init(&state->msg_lock);
++ return 0;
++}
++
+ static struct dvb_usb_device_properties mxl111sf_props_dvbt = {
+ .driver_name = KBUILD_MODNAME,
+ .owner = THIS_MODULE,
+@@ -1083,6 +1089,7 @@ static struct dvb_usb_device_properties
+ .generic_bulk_ctrl_endpoint = 0x02,
+ .generic_bulk_ctrl_endpoint_response = 0x81,
+
++ .probe = mxl111sf_probe,
+ .i2c_algo = &mxl111sf_i2c_algo,
+ .frontend_attach = mxl111sf_frontend_attach_dvbt,
+ .tuner_attach = mxl111sf_attach_tuner,
+@@ -1124,6 +1131,7 @@ static struct dvb_usb_device_properties
+ .generic_bulk_ctrl_endpoint = 0x02,
+ .generic_bulk_ctrl_endpoint_response = 0x81,
+
++ .probe = mxl111sf_probe,
+ .i2c_algo = &mxl111sf_i2c_algo,
+ .frontend_attach = mxl111sf_frontend_attach_atsc,
+ .tuner_attach = mxl111sf_attach_tuner,
+@@ -1165,6 +1173,7 @@ static struct dvb_usb_device_properties
+ .generic_bulk_ctrl_endpoint = 0x02,
+ .generic_bulk_ctrl_endpoint_response = 0x81,
+
++ .probe = mxl111sf_probe,
+ .i2c_algo = &mxl111sf_i2c_algo,
+ .frontend_attach = mxl111sf_frontend_attach_mh,
+ .tuner_attach = mxl111sf_attach_tuner,
+@@ -1233,6 +1242,7 @@ static struct dvb_usb_device_properties
+ .generic_bulk_ctrl_endpoint = 0x02,
+ .generic_bulk_ctrl_endpoint_response = 0x81,
+
++ .probe = mxl111sf_probe,
+ .i2c_algo = &mxl111sf_i2c_algo,
+ .frontend_attach = mxl111sf_frontend_attach_atsc_mh,
+ .tuner_attach = mxl111sf_attach_tuner,
+@@ -1311,6 +1321,7 @@ static struct dvb_usb_device_properties
+ .generic_bulk_ctrl_endpoint = 0x02,
+ .generic_bulk_ctrl_endpoint_response = 0x81,
+
++ .probe = mxl111sf_probe,
+ .i2c_algo = &mxl111sf_i2c_algo,
+ .frontend_attach = mxl111sf_frontend_attach_mercury,
+ .tuner_attach = mxl111sf_attach_tuner,
+@@ -1381,6 +1392,7 @@ static struct dvb_usb_device_properties
+ .generic_bulk_ctrl_endpoint = 0x02,
+ .generic_bulk_ctrl_endpoint_response = 0x81,
+
++ .probe = mxl111sf_probe,
+ .i2c_algo = &mxl111sf_i2c_algo,
+ .frontend_attach = mxl111sf_frontend_attach_mercury_mh,
+ .tuner_attach = mxl111sf_attach_tuner,
--- /dev/null
+From bd0687c18e635b63233dc87f38058cd728802ab4 Mon Sep 17 00:00:00 2001
+From: Magnus Karlsson <magnus.karlsson@intel.com>
+Date: Tue, 14 Dec 2021 11:26:07 +0100
+Subject: xsk: Do not sleep in poll() when need_wakeup set
+
+From: Magnus Karlsson <magnus.karlsson@intel.com>
+
+commit bd0687c18e635b63233dc87f38058cd728802ab4 upstream.
+
+Do not sleep in poll() when the need_wakeup flag is set. When this
+flag is set, the application needs to explicitly wake up the driver
+with a syscall (poll, recvmsg, sendmsg, etc.) to guarantee that Rx
+and/or Tx processing will be processed promptly. But the current code
+in poll(), sleeps first then wakes up the driver. This means that no
+driver processing will occur (baring any interrupts) until the timeout
+has expired.
+
+Fix this by checking the need_wakeup flag first and if set, wake the
+driver and return to the application. Only if need_wakeup is not set
+should the process sleep if there is a timeout set in the poll() call.
+
+Fixes: 77cd0d7b3f25 ("xsk: add support for need_wakeup flag in AF_XDP rings")
+Reported-by: Keith Wiles <keith.wiles@intel.com>
+Signed-off-by: Magnus Karlsson <magnus.karlsson@intel.com>
+Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
+Acked-by: Maciej Fijalkowski <maciej.fijalkowski@intel.com>
+Link: https://lore.kernel.org/bpf/20211214102607.7677-1-magnus.karlsson@gmail.com
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ net/xdp/xsk.c | 4 ++--
+ 1 file changed, 2 insertions(+), 2 deletions(-)
+
+--- a/net/xdp/xsk.c
++++ b/net/xdp/xsk.c
+@@ -434,8 +434,6 @@ static __poll_t xsk_poll(struct file *fi
+ struct xdp_sock *xs = xdp_sk(sk);
+ struct xdp_umem *umem;
+
+- sock_poll_wait(file, sock, wait);
+-
+ if (unlikely(!xsk_is_bound(xs)))
+ return mask;
+
+@@ -447,6 +445,8 @@ static __poll_t xsk_poll(struct file *fi
+ else
+ /* Poll needs to drive Tx also in copy mode */
+ __xsk_sendmsg(sk);
++ } else {
++ sock_poll_wait(file, sock, wait);
+ }
+
+ if (xs->rx && !xskq_empty_desc(xs->rx))
projects / thirdparty / kernel / stable-queue.git / commitdiff
