From: Greg Kroah-Hartman Date: Thu, 28 Dec 2023 10:57:50 +0000 (+0000) Subject: 6.1-stable patches X-Git-Tag: v6.1.70~37 X-Git-Url: http://git.ipfire.org/gitweb.cgi?a=commitdiff_plain;h=97721f81e4405440b70a86f23aca88f9b3341919;p=thirdparty%2Fkernel%2Fstable-queue.git 6.1-stable patches added patches: alsa-usb-audio-increase-delay-in-motu-m-quirk.patch iio-adc-ti_am335x_adc-fix-return-value-check-of-tiadc_request_dma.patch iio-common-ms_sensors-ms_sensors_i2c-fix-humidity-conversion-time-table.patch iio-imu-adis16475-add-spi_device_id-table.patch iio-triggered-buffer-prevent-possible-freeing-of-wrong-buffer.patch usb-storage-add-quirk-for-incorrect-wp-on-kingston-dt-ultimate-3.0-g3.patch --- diff --git a/queue-6.1/alsa-usb-audio-increase-delay-in-motu-m-quirk.patch b/queue-6.1/alsa-usb-audio-increase-delay-in-motu-m-quirk.patch new file mode 100644 index 00000000000..b22cee1f8e1 --- /dev/null +++ b/queue-6.1/alsa-usb-audio-increase-delay-in-motu-m-quirk.patch @@ -0,0 +1,48 @@ +From 48d6b91798a6694fdd6edb62799754b9d3fe0792 Mon Sep 17 00:00:00 2001 +From: Jeremie Knuesel +Date: Sun, 17 Dec 2023 12:22:43 +0100 +Subject: ALSA: usb-audio: Increase delay in MOTU M quirk + +From: Jeremie Knuesel + +commit 48d6b91798a6694fdd6edb62799754b9d3fe0792 upstream. + +Increase the quirk delay from 2 seconds to 4 seconds. This reflects a +change in the Windows driver in which the delay was increased to about +3.7 seconds. The larger delay fixes an issue where the device fails to +work unless it was powered up early during boot. + +Also clarify in the quirk comment that the quirk is only applied to +older devices (USB ID 07fd:0008). + +Signed-off-by: Jeremie Knuesel +Suggested-by: Alexander Tsoy +Cc: +Link: https://bugzilla.kernel.org/show_bug.cgi?id=211975 +Link: https://lore.kernel.org/r/20231217112243.33409-1-knuesel@gmail.com +Signed-off-by: Takashi Iwai +Signed-off-by: Greg Kroah-Hartman +--- + sound/usb/quirks.c | 4 ++-- + 1 file changed, 2 insertions(+), 2 deletions(-) + +--- a/sound/usb/quirks.c ++++ b/sound/usb/quirks.c +@@ -1385,7 +1385,7 @@ free_buf: + + static int snd_usb_motu_m_series_boot_quirk(struct usb_device *dev) + { +- msleep(2000); ++ msleep(4000); + + return 0; + } +@@ -1628,7 +1628,7 @@ int snd_usb_apply_boot_quirk_once(struct + unsigned int id) + { + switch (id) { +- case USB_ID(0x07fd, 0x0008): /* MOTU M Series */ ++ case USB_ID(0x07fd, 0x0008): /* MOTU M Series, 1st hardware version */ + return snd_usb_motu_m_series_boot_quirk(dev); + } + diff --git a/queue-6.1/iio-adc-ti_am335x_adc-fix-return-value-check-of-tiadc_request_dma.patch b/queue-6.1/iio-adc-ti_am335x_adc-fix-return-value-check-of-tiadc_request_dma.patch new file mode 100644 index 00000000000..58d5c1ad96f --- /dev/null +++ b/queue-6.1/iio-adc-ti_am335x_adc-fix-return-value-check-of-tiadc_request_dma.patch @@ -0,0 +1,40 @@ +From 60576e84c187043cef11f11d015249e71151d35a Mon Sep 17 00:00:00 2001 +From: Wadim Egorov +Date: Mon, 25 Sep 2023 15:44:27 +0200 +Subject: iio: adc: ti_am335x_adc: Fix return value check of tiadc_request_dma() + +From: Wadim Egorov + +commit 60576e84c187043cef11f11d015249e71151d35a upstream. + +Fix wrong handling of a DMA request where the probing only failed +if -EPROPE_DEFER was returned. Instead, let us fail if a non -ENODEV +value is returned. This makes DMAs explicitly optional. Even if the +DMA request is unsuccessfully, the ADC can still work properly. +We do also handle the defer probe case by making use of dev_err_probe(). + +Fixes: f438b9da75eb ("drivers: iio: ti_am335x_adc: add dma support") +Signed-off-by: Wadim Egorov +Reviewed-by: Bhavya Kapoor +Link: https://lore.kernel.org/r/20230925134427.214556-1-w.egorov@phytec.de +Cc: +Signed-off-by: Jonathan Cameron +Signed-off-by: Greg Kroah-Hartman +--- + drivers/iio/adc/ti_am335x_adc.c | 4 +++- + 1 file changed, 3 insertions(+), 1 deletion(-) + +--- a/drivers/iio/adc/ti_am335x_adc.c ++++ b/drivers/iio/adc/ti_am335x_adc.c +@@ -671,8 +671,10 @@ static int tiadc_probe(struct platform_d + platform_set_drvdata(pdev, indio_dev); + + err = tiadc_request_dma(pdev, adc_dev); +- if (err && err == -EPROBE_DEFER) ++ if (err && err != -ENODEV) { ++ dev_err_probe(&pdev->dev, err, "DMA request failed\n"); + goto err_dma; ++ } + + return 0; + diff --git a/queue-6.1/iio-common-ms_sensors-ms_sensors_i2c-fix-humidity-conversion-time-table.patch b/queue-6.1/iio-common-ms_sensors-ms_sensors_i2c-fix-humidity-conversion-time-table.patch new file mode 100644 index 00000000000..0e48d2dce1f --- /dev/null +++ b/queue-6.1/iio-common-ms_sensors-ms_sensors_i2c-fix-humidity-conversion-time-table.patch @@ -0,0 +1,106 @@ +From 54cf39ec16335dadbe1ba008d8e5e98dae3e26f8 Mon Sep 17 00:00:00 2001 +From: Javier Carrasco +Date: Thu, 26 Oct 2023 17:44:49 +0200 +Subject: iio: common: ms_sensors: ms_sensors_i2c: fix humidity conversion time table + +From: Javier Carrasco + +commit 54cf39ec16335dadbe1ba008d8e5e98dae3e26f8 upstream. + +The HTU21 offers 4 sampling frequencies: 20, 40, 70 and 120, which are +associated to an index that is used to select the right measurement +resolution and its corresponding measurement time. The current +implementation selects the measurement resolution and the temperature +measurement time properly, but it does not select the right humidity +measurement time in all cases. + +In summary, the 40 and 70 humidity measurement times are swapped. + +The reason for that is probably the unusual coding for the measurement +resolution. According to the datasheet, the bits [7,0] of the "user +register" are used as follows to select the bit resolution: + +-------------------------------------------------- +| Bit 7 | Bit 0 | RH | Temp | Trh (us) | Tt (us) | +-------------------------------------------------- +| 0 | 0 | 12 | 14 | 16000 | 50000 | +-------------------------------------------------- +| 0 | 1 | 8 | 12 | 3000 | 13000 | +-------------------------------------------------- +| 1 | 0 | 10 | 13 | 5000 | 25000 | +-------------------------------------------------- +| 1 | 1 | 11 | 11 | 8000 | 7000 | +-------------------------------------------------- +*This table is available in the official datasheet, page 13/21. I have +just appended the times provided in the humidity/temperature tables, +pages 3/21, 5/21. Note that always a pair of resolutions is selected. + +The sampling frequencies [20, 40, 70, 120] are assigned to a linear +index [0..3] which is then coded as follows [1]: + +Index [7,0] +-------------- +idx 0 0,0 +idx 1 1,0 +idx 2 0,1 +idx 3 1,1 + +That is done that way because the temperature measurements are being +used as the reference for the sampling frequency (the frequencies and +the temperature measurement times are correlated), so increasing the +index always reduces the temperature measurement time and its +resolution. Therefore, the temperature measurement time array is as +simple as [50000, 25000, 13000, 7000] + +On the other hand, the humidity resolution cannot follow the same +pattern because of the way it is coded in the "user register", where +both resolutions are selected at the same time. The humidity measurement +time array is the following: [16000, 3000, 5000, 8000], which defines +the following assignments: + +Index [7,0] Trh +----------------------- +idx 0 0,0 16000 -> right, [0,0] selects 12 bits (Trh = 16000) +idx 1 1,0 3000 -> wrong! [1,0] selects 10 bits (Trh = 5000) +idx 2 0,1 5000 -> wrong! [0,1] selects 8 bits (Trh = 3000) +idx 3 1,1 8000 -> right, [1,1] selects 11 bits (Trh = 8000) + +The times have been ordered as if idx = 1 -> [0,1] and idx = 2 -> [1,0], +which is not the case for the reason explained above. + +So a simple modification is required to obtain the right humidity +measurement time array, swapping the values in the positions 1 and 2. + +The right table should be the following: [16000, 5000, 3000, 8000] + +Fix the humidity measurement time array with the right idex/value +coding. + +[1] The actual code that makes this coding and assigns it to the current +value of the "user register" is the following: +config_reg &= 0x7E; +config_reg |= ((i & 1) << 7) + ((i & 2) >> 1); + +Fixes: d574a87cc311 ("Add meas-spec sensors common part") +Signed-off-by: Javier Carrasco +Link: https://lore.kernel.org/r/20231026-topic-htu21_conversion_time-v1-1-bd257dc44209@gmail.com +Cc: +Signed-off-by: Jonathan Cameron +Signed-off-by: Greg Kroah-Hartman +--- + drivers/iio/common/ms_sensors/ms_sensors_i2c.c | 4 ++-- + 1 file changed, 2 insertions(+), 2 deletions(-) + +--- a/drivers/iio/common/ms_sensors/ms_sensors_i2c.c ++++ b/drivers/iio/common/ms_sensors/ms_sensors_i2c.c +@@ -15,8 +15,8 @@ + /* Conversion times in us */ + static const u16 ms_sensors_ht_t_conversion_time[] = { 50000, 25000, + 13000, 7000 }; +-static const u16 ms_sensors_ht_h_conversion_time[] = { 16000, 3000, +- 5000, 8000 }; ++static const u16 ms_sensors_ht_h_conversion_time[] = { 16000, 5000, ++ 3000, 8000 }; + static const u16 ms_sensors_tp_conversion_time[] = { 500, 1100, 2100, + 4100, 8220, 16440 }; + diff --git a/queue-6.1/iio-imu-adis16475-add-spi_device_id-table.patch b/queue-6.1/iio-imu-adis16475-add-spi_device_id-table.patch new file mode 100644 index 00000000000..76ff1354c80 --- /dev/null +++ b/queue-6.1/iio-imu-adis16475-add-spi_device_id-table.patch @@ -0,0 +1,171 @@ +From ee4d79055aeea27f1b8c42233cc0c90d0a8b5355 Mon Sep 17 00:00:00 2001 +From: Nuno Sa +Date: Thu, 2 Nov 2023 13:52:58 +0100 +Subject: iio: imu: adis16475: add spi_device_id table + +From: Nuno Sa + +commit ee4d79055aeea27f1b8c42233cc0c90d0a8b5355 upstream. + +This prevents the warning message "SPI driver has no spi_device_id for..." +when registering the driver. More importantly, it makes sure that +module autoloading works as spi relies on spi: modaliases and not of. + +While at it, move the of_device_id table to it's natural place. + +Fixes: fff7352bf7a3c ("iio: imu: Add support for adis16475") +Signed-off-by: Nuno Sa +Link: https://lore.kernel.org/r/20231102125258.3284830-1-nuno.sa@analog.com +Cc: +Signed-off-by: Jonathan Cameron +Signed-off-by: Greg Kroah-Hartman +--- + drivers/iio/imu/adis16475.c | 117 +++++++++++++++++++++++++++----------------- + 1 file changed, 72 insertions(+), 45 deletions(-) + +--- a/drivers/iio/imu/adis16475.c ++++ b/drivers/iio/imu/adis16475.c +@@ -1243,50 +1243,6 @@ static int adis16475_config_irq_pin(stru + return 0; + } + +-static const struct of_device_id adis16475_of_match[] = { +- { .compatible = "adi,adis16470", +- .data = &adis16475_chip_info[ADIS16470] }, +- { .compatible = "adi,adis16475-1", +- .data = &adis16475_chip_info[ADIS16475_1] }, +- { .compatible = "adi,adis16475-2", +- .data = &adis16475_chip_info[ADIS16475_2] }, +- { .compatible = "adi,adis16475-3", +- .data = &adis16475_chip_info[ADIS16475_3] }, +- { .compatible = "adi,adis16477-1", +- .data = &adis16475_chip_info[ADIS16477_1] }, +- { .compatible = "adi,adis16477-2", +- .data = &adis16475_chip_info[ADIS16477_2] }, +- { .compatible = "adi,adis16477-3", +- .data = &adis16475_chip_info[ADIS16477_3] }, +- { .compatible = "adi,adis16465-1", +- .data = &adis16475_chip_info[ADIS16465_1] }, +- { .compatible = "adi,adis16465-2", +- .data = &adis16475_chip_info[ADIS16465_2] }, +- { .compatible = "adi,adis16465-3", +- .data = &adis16475_chip_info[ADIS16465_3] }, +- { .compatible = "adi,adis16467-1", +- .data = &adis16475_chip_info[ADIS16467_1] }, +- { .compatible = "adi,adis16467-2", +- .data = &adis16475_chip_info[ADIS16467_2] }, +- { .compatible = "adi,adis16467-3", +- .data = &adis16475_chip_info[ADIS16467_3] }, +- { .compatible = "adi,adis16500", +- .data = &adis16475_chip_info[ADIS16500] }, +- { .compatible = "adi,adis16505-1", +- .data = &adis16475_chip_info[ADIS16505_1] }, +- { .compatible = "adi,adis16505-2", +- .data = &adis16475_chip_info[ADIS16505_2] }, +- { .compatible = "adi,adis16505-3", +- .data = &adis16475_chip_info[ADIS16505_3] }, +- { .compatible = "adi,adis16507-1", +- .data = &adis16475_chip_info[ADIS16507_1] }, +- { .compatible = "adi,adis16507-2", +- .data = &adis16475_chip_info[ADIS16507_2] }, +- { .compatible = "adi,adis16507-3", +- .data = &adis16475_chip_info[ADIS16507_3] }, +- { }, +-}; +-MODULE_DEVICE_TABLE(of, adis16475_of_match); + + static int adis16475_probe(struct spi_device *spi) + { +@@ -1300,7 +1256,7 @@ static int adis16475_probe(struct spi_de + + st = iio_priv(indio_dev); + +- st->info = device_get_match_data(&spi->dev); ++ st->info = spi_get_device_match_data(spi); + if (!st->info) + return -EINVAL; + +@@ -1340,12 +1296,83 @@ static int adis16475_probe(struct spi_de + return 0; + } + ++static const struct of_device_id adis16475_of_match[] = { ++ { .compatible = "adi,adis16470", ++ .data = &adis16475_chip_info[ADIS16470] }, ++ { .compatible = "adi,adis16475-1", ++ .data = &adis16475_chip_info[ADIS16475_1] }, ++ { .compatible = "adi,adis16475-2", ++ .data = &adis16475_chip_info[ADIS16475_2] }, ++ { .compatible = "adi,adis16475-3", ++ .data = &adis16475_chip_info[ADIS16475_3] }, ++ { .compatible = "adi,adis16477-1", ++ .data = &adis16475_chip_info[ADIS16477_1] }, ++ { .compatible = "adi,adis16477-2", ++ .data = &adis16475_chip_info[ADIS16477_2] }, ++ { .compatible = "adi,adis16477-3", ++ .data = &adis16475_chip_info[ADIS16477_3] }, ++ { .compatible = "adi,adis16465-1", ++ .data = &adis16475_chip_info[ADIS16465_1] }, ++ { .compatible = "adi,adis16465-2", ++ .data = &adis16475_chip_info[ADIS16465_2] }, ++ { .compatible = "adi,adis16465-3", ++ .data = &adis16475_chip_info[ADIS16465_3] }, ++ { .compatible = "adi,adis16467-1", ++ .data = &adis16475_chip_info[ADIS16467_1] }, ++ { .compatible = "adi,adis16467-2", ++ .data = &adis16475_chip_info[ADIS16467_2] }, ++ { .compatible = "adi,adis16467-3", ++ .data = &adis16475_chip_info[ADIS16467_3] }, ++ { .compatible = "adi,adis16500", ++ .data = &adis16475_chip_info[ADIS16500] }, ++ { .compatible = "adi,adis16505-1", ++ .data = &adis16475_chip_info[ADIS16505_1] }, ++ { .compatible = "adi,adis16505-2", ++ .data = &adis16475_chip_info[ADIS16505_2] }, ++ { .compatible = "adi,adis16505-3", ++ .data = &adis16475_chip_info[ADIS16505_3] }, ++ { .compatible = "adi,adis16507-1", ++ .data = &adis16475_chip_info[ADIS16507_1] }, ++ { .compatible = "adi,adis16507-2", ++ .data = &adis16475_chip_info[ADIS16507_2] }, ++ { .compatible = "adi,adis16507-3", ++ .data = &adis16475_chip_info[ADIS16507_3] }, ++ { }, ++}; ++MODULE_DEVICE_TABLE(of, adis16475_of_match); ++ ++static const struct spi_device_id adis16475_ids[] = { ++ { "adis16470", (kernel_ulong_t)&adis16475_chip_info[ADIS16470] }, ++ { "adis16475-1", (kernel_ulong_t)&adis16475_chip_info[ADIS16475_1] }, ++ { "adis16475-2", (kernel_ulong_t)&adis16475_chip_info[ADIS16475_2] }, ++ { "adis16475-3", (kernel_ulong_t)&adis16475_chip_info[ADIS16475_3] }, ++ { "adis16477-1", (kernel_ulong_t)&adis16475_chip_info[ADIS16477_1] }, ++ { "adis16477-2", (kernel_ulong_t)&adis16475_chip_info[ADIS16477_2] }, ++ { "adis16477-3", (kernel_ulong_t)&adis16475_chip_info[ADIS16477_3] }, ++ { "adis16465-1", (kernel_ulong_t)&adis16475_chip_info[ADIS16465_1] }, ++ { "adis16465-2", (kernel_ulong_t)&adis16475_chip_info[ADIS16465_2] }, ++ { "adis16465-3", (kernel_ulong_t)&adis16475_chip_info[ADIS16465_3] }, ++ { "adis16467-1", (kernel_ulong_t)&adis16475_chip_info[ADIS16467_1] }, ++ { "adis16467-2", (kernel_ulong_t)&adis16475_chip_info[ADIS16467_2] }, ++ { "adis16467-3", (kernel_ulong_t)&adis16475_chip_info[ADIS16467_3] }, ++ { "adis16500", (kernel_ulong_t)&adis16475_chip_info[ADIS16500] }, ++ { "adis16505-1", (kernel_ulong_t)&adis16475_chip_info[ADIS16505_1] }, ++ { "adis16505-2", (kernel_ulong_t)&adis16475_chip_info[ADIS16505_2] }, ++ { "adis16505-3", (kernel_ulong_t)&adis16475_chip_info[ADIS16505_3] }, ++ { "adis16507-1", (kernel_ulong_t)&adis16475_chip_info[ADIS16507_1] }, ++ { "adis16507-2", (kernel_ulong_t)&adis16475_chip_info[ADIS16507_2] }, ++ { "adis16507-3", (kernel_ulong_t)&adis16475_chip_info[ADIS16507_3] }, ++ { } ++}; ++MODULE_DEVICE_TABLE(spi, adis16475_ids); ++ + static struct spi_driver adis16475_driver = { + .driver = { + .name = "adis16475", + .of_match_table = adis16475_of_match, + }, + .probe = adis16475_probe, ++ .id_table = adis16475_ids, + }; + module_spi_driver(adis16475_driver); + diff --git a/queue-6.1/iio-triggered-buffer-prevent-possible-freeing-of-wrong-buffer.patch b/queue-6.1/iio-triggered-buffer-prevent-possible-freeing-of-wrong-buffer.patch new file mode 100644 index 00000000000..a07726920f5 --- /dev/null +++ b/queue-6.1/iio-triggered-buffer-prevent-possible-freeing-of-wrong-buffer.patch @@ -0,0 +1,58 @@ +From bce61476dc82f114e24e9c2e11fb064781ec563c Mon Sep 17 00:00:00 2001 +From: David Lechner +Date: Tue, 31 Oct 2023 16:05:19 -0500 +Subject: iio: triggered-buffer: prevent possible freeing of wrong buffer + +From: David Lechner + +commit bce61476dc82f114e24e9c2e11fb064781ec563c upstream. + +Commit ee708e6baacd ("iio: buffer: introduce support for attaching more +IIO buffers") introduced support for multiple buffers per indio_dev but +left indio_dev->buffer for a few legacy use cases. + +In the case of the triggered buffer, iio_triggered_buffer_cleanup() +still assumes that indio_dev->buffer points to the buffer allocated by +iio_triggered_buffer_setup_ext(). However, since +iio_triggered_buffer_setup_ext() now calls iio_device_attach_buffer() +to attach the buffer, indio_dev->buffer will only point to the buffer +allocated by iio_device_attach_buffer() if it the first buffer attached. + +This adds a check to make sure that no other buffer has been attached +yet to ensure that indio_dev->buffer will be assigned when +iio_device_attach_buffer() is called. + +As per discussion in the review thread, we may want to deal with multiple +triggers per device, but this is a fix for the issue in the meantime and +any such support would be unlikely to be suitable for a backport. + +Fixes: ee708e6baacd ("iio: buffer: introduce support for attaching more IIO buffers") +Signed-off-by: David Lechner +Acked-by: Nuno Sa +Link: https://lore.kernel.org/r/20231031210521.1661552-1-dlechner@baylibre.com +Cc: +Signed-off-by: Jonathan Cameron +Signed-off-by: Greg Kroah-Hartman +--- + drivers/iio/buffer/industrialio-triggered-buffer.c | 10 ++++++++++ + 1 file changed, 10 insertions(+) + +--- a/drivers/iio/buffer/industrialio-triggered-buffer.c ++++ b/drivers/iio/buffer/industrialio-triggered-buffer.c +@@ -46,6 +46,16 @@ int iio_triggered_buffer_setup_ext(struc + struct iio_buffer *buffer; + int ret; + ++ /* ++ * iio_triggered_buffer_cleanup() assumes that the buffer allocated here ++ * is assigned to indio_dev->buffer but this is only the case if this ++ * function is the first caller to iio_device_attach_buffer(). If ++ * indio_dev->buffer is already set then we can't proceed otherwise the ++ * cleanup function will try to free a buffer that was not allocated here. ++ */ ++ if (indio_dev->buffer) ++ return -EADDRINUSE; ++ + buffer = iio_kfifo_allocate(); + if (!buffer) { + ret = -ENOMEM; diff --git a/queue-6.1/series b/queue-6.1/series index 7acfd00e8c4..339f02370f5 100644 --- a/queue-6.1/series +++ b/queue-6.1/series @@ -56,3 +56,9 @@ iio-imu-inv_mpu6050-fix-an-error-code-problem-in-inv.patch interconnect-qcom-sm8250-enable-sync_state.patch input-ipaq-micro-keys-add-error-handling-for-devm_km.patch scsi-bnx2fc-fix-skb-double-free-in-bnx2fc_rcv.patch +iio-common-ms_sensors-ms_sensors_i2c-fix-humidity-conversion-time-table.patch +iio-imu-adis16475-add-spi_device_id-table.patch +iio-adc-ti_am335x_adc-fix-return-value-check-of-tiadc_request_dma.patch +iio-triggered-buffer-prevent-possible-freeing-of-wrong-buffer.patch +alsa-usb-audio-increase-delay-in-motu-m-quirk.patch +usb-storage-add-quirk-for-incorrect-wp-on-kingston-dt-ultimate-3.0-g3.patch diff --git a/queue-6.1/usb-storage-add-quirk-for-incorrect-wp-on-kingston-dt-ultimate-3.0-g3.patch b/queue-6.1/usb-storage-add-quirk-for-incorrect-wp-on-kingston-dt-ultimate-3.0-g3.patch new file mode 100644 index 00000000000..ae630708dfe --- /dev/null +++ b/queue-6.1/usb-storage-add-quirk-for-incorrect-wp-on-kingston-dt-ultimate-3.0-g3.patch @@ -0,0 +1,56 @@ +From 772685c14743ad565bb271041ad3c262298cd6fc Mon Sep 17 00:00:00 2001 +From: Tasos Sahanidis +Date: Thu, 7 Dec 2023 15:44:41 +0200 +Subject: usb-storage: Add quirk for incorrect WP on Kingston DT Ultimate 3.0 G3 + +From: Tasos Sahanidis + +commit 772685c14743ad565bb271041ad3c262298cd6fc upstream. + +This flash drive reports write protect during the first mode sense. + +In the past this was not an issue as the kernel called revalidate twice, +thus asking the device for its write protect status twice, with write +protect being disabled in the second mode sense. + +However, since commit 1e029397d12f ("scsi: sd: Reorganize DIF/DIX code to +avoid calling revalidate twice") that is no longer the case, thus the +device shows up read only. + +[490891.289495] sd 12:0:0:0: [sdl] Write Protect is on +[490891.289497] sd 12:0:0:0: [sdl] Mode Sense: 2b 00 80 08 + +This does not appear to be a timing issue, as enabling the usbcore quirk +USB_QUIRK_DELAY_INIT has no effect on write protect. + +Fixes: 1e029397d12f ("scsi: sd: Reorganize DIF/DIX code to avoid calling revalidate twice") +Cc: stable +Signed-off-by: Tasos Sahanidis +Acked-by: Alan Stern +Reviewed-by: Martin K. Petersen +Link: https://lore.kernel.org/r/20231207134441.298131-1-tasos@tasossah.com +Signed-off-by: Greg Kroah-Hartman +--- + drivers/usb/storage/unusual_devs.h | 11 +++++++++++ + 1 file changed, 11 insertions(+) + +--- a/drivers/usb/storage/unusual_devs.h ++++ b/drivers/usb/storage/unusual_devs.h +@@ -1306,6 +1306,17 @@ UNUSUAL_DEV( 0x090c, 0x6000, 0x0100, 0x + US_FL_INITIAL_READ10 ), + + /* ++ * Patch by Tasos Sahanidis ++ * This flash drive always shows up with write protect enabled ++ * during the first mode sense. ++ */ ++UNUSUAL_DEV(0x0951, 0x1697, 0x0100, 0x0100, ++ "Kingston", ++ "DT Ultimate G3", ++ USB_SC_DEVICE, USB_PR_DEVICE, NULL, ++ US_FL_NO_WP_DETECT), ++ ++/* + * This Pentax still camera is not conformant + * to the USB storage specification: - + * - It does not like the INQUIRY command. So we must handle this command