--- /dev/null
+From 0c84bde4f37ba27d50e4c70ecacd33fe4a57030d Mon Sep 17 00:00:00 2001
+From: Sean Young <sean@mess.org>
+Date: Thu, 8 Aug 2024 10:35:19 +0200
+Subject: media: Revert "media: dvb-usb: Fix unexpected infinite loop in dvb_usb_read_remote_control()"
+
+From: Sean Young <sean@mess.org>
+
+commit 0c84bde4f37ba27d50e4c70ecacd33fe4a57030d upstream.
+
+This reverts commit 2052138b7da52ad5ccaf74f736d00f39a1c9198c.
+
+This breaks the TeVii s480 dual DVB-S2 S660. The device has a bulk in
+endpoint but no corresponding out endpoint, so the device does not pass
+the "has both receive and send bulk endpoint" test.
+
+Seemingly this device does not use dvb_usb_generic_rw() so I have tried
+removing the generic_bulk_ctrl_endpoint entry, but this resulted in
+different problems.
+
+As we have no explanation yet, revert.
+
+$ dmesg | grep -i -e dvb -e dw21 -e usb\ 4
+[ 0.999122] usb 1-1: new high-speed USB device number 2 using ehci-pci
+[ 1.023123] usb 4-1: new high-speed USB device number 2 using ehci-pci
+[ 1.130247] usb 1-1: New USB device found, idVendor=9022, idProduct=d482,
++bcdDevice= 0.01
+[ 1.130257] usb 1-1: New USB device strings: Mfr=0, Product=0, SerialNumber=0
+[ 1.152323] usb 4-1: New USB device found, idVendor=9022, idProduct=d481,
++bcdDevice= 0.01
+[ 1.152329] usb 4-1: New USB device strings: Mfr=0, Product=0, SerialNumber=0
+[ 6.701033] dvb-usb: found a 'TeVii S480.2 USB' in cold state, will try to
++load a firmware
+[ 6.701178] dvb-usb: downloading firmware from file 'dvb-usb-s660.fw'
+[ 6.701179] dw2102: start downloading DW210X firmware
+[ 6.703715] dvb-usb: found a 'Microsoft Xbox One Digital TV Tuner' in cold
++state, will try to load a firmware
+[ 6.703974] dvb-usb: downloading firmware from file 'dvb-usb-dib0700-1.20.fw'
+[ 6.756432] usb 1-1: USB disconnect, device number 2
+[ 6.862119] dvb-usb: found a 'TeVii S480.2 USB' in warm state.
+[ 6.862194] dvb-usb: TeVii S480.2 USB error while loading driver (-22)
+[ 6.862209] dvb-usb: found a 'TeVii S480.1 USB' in cold state, will try to
++load a firmware
+[ 6.862244] dvb-usb: downloading firmware from file 'dvb-usb-s660.fw'
+[ 6.862245] dw2102: start downloading DW210X firmware
+[ 6.914811] usb 4-1: USB disconnect, device number 2
+[ 7.014131] dvb-usb: found a 'TeVii S480.1 USB' in warm state.
+[ 7.014487] dvb-usb: TeVii S480.1 USB error while loading driver (-22)
+[ 7.014538] usbcore: registered new interface driver dw2102
+
+Closes: https://lore.kernel.org/stable/20240801165146.38991f60@mir/
+
+Fixes: 2052138b7da5 ("media: dvb-usb: Fix unexpected infinite loop in dvb_usb_read_remote_control()")
+Reported-by: Stefan Lippers-Hollmann <s.l-h@gmx.de>
+Cc: stable@vger.kernel.org
+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/dvb-usb-init.c | 35 +++----------------------------
+ 1 file changed, 4 insertions(+), 31 deletions(-)
+
+--- a/drivers/media/usb/dvb-usb/dvb-usb-init.c
++++ b/drivers/media/usb/dvb-usb/dvb-usb-init.c
+@@ -23,40 +23,11 @@ static int dvb_usb_force_pid_filter_usag
+ module_param_named(force_pid_filter_usage, dvb_usb_force_pid_filter_usage, int, 0444);
+ MODULE_PARM_DESC(force_pid_filter_usage, "force all dvb-usb-devices to use a PID filter, if any (default: 0).");
+
+-static int dvb_usb_check_bulk_endpoint(struct dvb_usb_device *d, u8 endpoint)
+-{
+- if (endpoint) {
+- int ret;
+-
+- ret = usb_pipe_type_check(d->udev, usb_sndbulkpipe(d->udev, endpoint));
+- if (ret)
+- return ret;
+- ret = usb_pipe_type_check(d->udev, usb_rcvbulkpipe(d->udev, endpoint));
+- if (ret)
+- return ret;
+- }
+- return 0;
+-}
+-
+-static void dvb_usb_clear_halt(struct dvb_usb_device *d, u8 endpoint)
+-{
+- if (endpoint) {
+- usb_clear_halt(d->udev, usb_sndbulkpipe(d->udev, endpoint));
+- usb_clear_halt(d->udev, usb_rcvbulkpipe(d->udev, endpoint));
+- }
+-}
+-
+ static int dvb_usb_adapter_init(struct dvb_usb_device *d, short *adapter_nrs)
+ {
+ struct dvb_usb_adapter *adap;
+ int ret, n, o;
+
+- ret = dvb_usb_check_bulk_endpoint(d, d->props.generic_bulk_ctrl_endpoint);
+- if (ret)
+- return ret;
+- ret = dvb_usb_check_bulk_endpoint(d, d->props.generic_bulk_ctrl_endpoint_response);
+- if (ret)
+- return ret;
+ for (n = 0; n < d->props.num_adapters; n++) {
+ adap = &d->adapter[n];
+ adap->dev = d;
+@@ -132,8 +103,10 @@ static int dvb_usb_adapter_init(struct d
+ * when reloading the driver w/o replugging the device
+ * sometimes a timeout occurs, this helps
+ */
+- dvb_usb_clear_halt(d, d->props.generic_bulk_ctrl_endpoint);
+- dvb_usb_clear_halt(d, d->props.generic_bulk_ctrl_endpoint_response);
++ if (d->props.generic_bulk_ctrl_endpoint != 0) {
++ usb_clear_halt(d->udev, usb_sndbulkpipe(d->udev, d->props.generic_bulk_ctrl_endpoint));
++ usb_clear_halt(d->udev, usb_rcvbulkpipe(d->udev, d->props.generic_bulk_ctrl_endpoint));
++ }
+
+ return 0;
+
--- /dev/null
+From fa0db8e568787c665384430eaf2221b299b85367 Mon Sep 17 00:00:00 2001
+From: Niklas Cassel <cassel@kernel.org>
+Date: Tue, 13 Aug 2024 15:19:01 +0200
+Subject: Revert "ata: libata-scsi: Honor the D_SENSE bit for CK_COND=1 and no error"
+
+From: Niklas Cassel <cassel@kernel.org>
+
+commit fa0db8e568787c665384430eaf2221b299b85367 upstream.
+
+This reverts commit 28ab9769117ca944cb6eb537af5599aa436287a4.
+
+Sense data can be in either fixed format or descriptor format.
+
+SAT-6 revision 1, "10.4.6 Control mode page", defines the D_SENSE bit:
+"The SATL shall support this bit as defined in SPC-5 with the following
+exception: if the D_ SENSE bit is set to zero (i.e., fixed format sense
+data), then the SATL should return fixed format sense data for ATA
+PASS-THROUGH commands."
+
+The libata SATL has always kept D_SENSE set to zero by default. (It is
+however possible to change the value using a MODE SELECT SG_IO command.)
+
+Failed ATA PASS-THROUGH commands correctly respected the D_SENSE bit,
+however, successful ATA PASS-THROUGH commands incorrectly returned the
+sense data in descriptor format (regardless of the D_SENSE bit).
+
+Commit 28ab9769117c ("ata: libata-scsi: Honor the D_SENSE bit for
+CK_COND=1 and no error") fixed this bug for successful ATA PASS-THROUGH
+commands.
+
+However, after commit 28ab9769117c ("ata: libata-scsi: Honor the D_SENSE
+bit for CK_COND=1 and no error"), there were bug reports that hdparm,
+hddtemp, and udisks were no longer working as expected.
+
+These applications incorrectly assume the returned sense data is in
+descriptor format, without even looking at the RESPONSE CODE field in the
+returned sense data (to see which format the returned sense data is in).
+
+Considering that there will be broken versions of these applications around
+roughly forever, we are stuck with being bug compatible with older kernels.
+
+Cc: stable@vger.kernel.org # 4.19+
+Reported-by: Stephan Eisvogel <eisvogel@seitics.de>
+Reported-by: Christian Heusel <christian@heusel.eu>
+Closes: https://lore.kernel.org/linux-ide/0bf3f2f0-0fc6-4ba5-a420-c0874ef82d64@heusel.eu/
+Fixes: 28ab9769117c ("ata: libata-scsi: Honor the D_SENSE bit for CK_COND=1 and no error")
+Reviewed-by: Hannes Reinecke <hare@suse.de>
+Reviewed-by: Martin K. Petersen <martin.petersen@oracle.com>
+Link: https://lore.kernel.org/r/20240813131900.1285842-2-cassel@kernel.org
+Signed-off-by: Niklas Cassel <cassel@kernel.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/ata/libata-scsi.c | 15 +++++++++++++--
+ 1 file changed, 13 insertions(+), 2 deletions(-)
+
+--- a/drivers/ata/libata-scsi.c
++++ b/drivers/ata/libata-scsi.c
+@@ -872,8 +872,19 @@ static void ata_gen_passthru_sense(struc
+ &sense_key, &asc, &ascq, verbose);
+ ata_scsi_set_sense(qc->dev, cmd, sense_key, asc, ascq);
+ } else {
+- /* ATA PASS-THROUGH INFORMATION AVAILABLE */
+- ata_scsi_set_sense(qc->dev, cmd, RECOVERED_ERROR, 0, 0x1D);
++ /*
++ * ATA PASS-THROUGH INFORMATION AVAILABLE
++ *
++ * Note: we are supposed to call ata_scsi_set_sense(), which
++ * respects the D_SENSE bit, instead of unconditionally
++ * generating the sense data in descriptor format. However,
++ * because hdparm, hddtemp, and udisks incorrectly assume sense
++ * data in descriptor format, without even looking at the
++ * RESPONSE CODE field in the returned sense data (to see which
++ * format the returned sense data is in), we are stuck with
++ * being bug compatible with older kernels.
++ */
++ scsi_build_sense(cmd, 1, RECOVERED_ERROR, 0, 0x1D);
+ }
+
+ if ((cmd->sense_buffer[0] & 0x7f) >= 0x72) {