This fixes data corruption when accessing the internal SD card in mass storage mode.
I am actually not too sure why. I didn't figure a straightforward way to reproduce the issue, but i seem to get garbage when issuing a lot (over 50) of large reads (over 120 sectors) are done in a quick succession. That is, time seems to matter here -- larger reads are fine if they are done with some delay between them.
But I'm not great at understanding this sort of things, so I'll assume the issue other, smarter, folks were seeing with similar phones is the same problem and I'll just put my quirk next to theirs.
The "Software details" screen on the phone is as follows:
V 04.06 07-08-13 RM-849 (c) Nokia
TL;DR version of the device descriptor:
idVendor 0x0421 Nokia Mobile Phones idProduct 0x06c2 bcdDevice 4.06 iManufacturer 1 Nokia iProduct 2 Nokia 208
The patch assumes older firmwares are broken too (I'm unable to test, but no biggie if they aren't I guess), and I have no idea if newer firmware exists.
Signed-off-by: Lubomir Rintel lkundrak@v3.sk Cc: stable@vger.kernel.org --- drivers/usb/storage/unusual_devs.h | 7 +++++++ 1 file changed, 7 insertions(+)
diff --git a/drivers/usb/storage/unusual_devs.h b/drivers/usb/storage/unusual_devs.h index e5ad23d86833..54f0b1c83317 100644 --- a/drivers/usb/storage/unusual_devs.h +++ b/drivers/usb/storage/unusual_devs.h @@ -255,6 +255,13 @@ UNUSUAL_DEV( 0x0421, 0x06aa, 0x1110, 0x1110, USB_SC_DEVICE, USB_PR_DEVICE, NULL, US_FL_MAX_SECTORS_64 ),
+/* Added by Lubomir Rintel lkundrak@v3.sk, a very fine chap */ +UNUSUAL_DEV( 0x0421, 0x06c2, 0x0000, 0x0406, + "Nokia", + "Nokia 208", + USB_SC_DEVICE, USB_PR_DEVICE, NULL, + US_FL_MAX_SECTORS_64 ), + #ifdef NO_SDDR09 UNUSUAL_DEV( 0x0436, 0x0005, 0x0100, 0x0100, "Microtech",
On Wed, Jan 01, 2025 at 10:22:06PM +0100, Lubomir Rintel wrote:
This fixes data corruption when accessing the internal SD card in mass storage mode.
I am actually not too sure why. I didn't figure a straightforward way to reproduce the issue, but i seem to get garbage when issuing a lot (over 50) of large reads (over 120 sectors) are done in a quick succession. That is, time seems to matter here -- larger reads are fine if they are done with some delay between them.
But I'm not great at understanding this sort of things, so I'll assume the issue other, smarter, folks were seeing with similar phones is the same problem and I'll just put my quirk next to theirs.
The "Software details" screen on the phone is as follows:
V 04.06 07-08-13 RM-849 (c) Nokia
TL;DR version of the device descriptor:
idVendor 0x0421 Nokia Mobile Phones idProduct 0x06c2 bcdDevice 4.06 iManufacturer 1 Nokia iProduct 2 Nokia 208
The patch assumes older firmwares are broken too (I'm unable to test, but no biggie if they aren't I guess), and I have no idea if newer firmware exists.
Signed-off-by: Lubomir Rintel lkundrak@v3.sk Cc: stable@vger.kernel.org
Hmmm, maybe we should automatically set this flag for all Nokia devices. In any case,
Acked-by: Alan Stern stern@rowland.harvard.edu
However, Greg's patch bot is going to ask why you didn't include a Fixes: tag.
drivers/usb/storage/unusual_devs.h | 7 +++++++ 1 file changed, 7 insertions(+)
diff --git a/drivers/usb/storage/unusual_devs.h b/drivers/usb/storage/unusual_devs.h index e5ad23d86833..54f0b1c83317 100644 --- a/drivers/usb/storage/unusual_devs.h +++ b/drivers/usb/storage/unusual_devs.h @@ -255,6 +255,13 @@ UNUSUAL_DEV( 0x0421, 0x06aa, 0x1110, 0x1110, USB_SC_DEVICE, USB_PR_DEVICE, NULL, US_FL_MAX_SECTORS_64 ), +/* Added by Lubomir Rintel lkundrak@v3.sk, a very fine chap */ +UNUSUAL_DEV( 0x0421, 0x06c2, 0x0000, 0x0406,
"Nokia",
"Nokia 208",
USB_SC_DEVICE, USB_PR_DEVICE, NULL,
US_FL_MAX_SECTORS_64 ),
#ifdef NO_SDDR09 UNUSUAL_DEV( 0x0436, 0x0005, 0x0100, 0x0100, "Microtech", -- 2.47.1
On Thu, Jan 02, 2025 at 11:22:00AM -0500, Alan Stern wrote:
On Wed, Jan 01, 2025 at 10:22:06PM +0100, Lubomir Rintel wrote:
This fixes data corruption when accessing the internal SD card in mass storage mode.
I am actually not too sure why. I didn't figure a straightforward way to reproduce the issue, but i seem to get garbage when issuing a lot (over 50) of large reads (over 120 sectors) are done in a quick succession. That is, time seems to matter here -- larger reads are fine if they are done with some delay between them.
But I'm not great at understanding this sort of things, so I'll assume the issue other, smarter, folks were seeing with similar phones is the same problem and I'll just put my quirk next to theirs.
The "Software details" screen on the phone is as follows:
V 04.06 07-08-13 RM-849 (c) Nokia
TL;DR version of the device descriptor:
idVendor 0x0421 Nokia Mobile Phones idProduct 0x06c2 bcdDevice 4.06 iManufacturer 1 Nokia iProduct 2 Nokia 208
The patch assumes older firmwares are broken too (I'm unable to test, but no biggie if they aren't I guess), and I have no idea if newer firmware exists.
Signed-off-by: Lubomir Rintel lkundrak@v3.sk Cc: stable@vger.kernel.org
Hmmm, maybe we should automatically set this flag for all Nokia devices. In any case,
Acked-by: Alan Stern stern@rowland.harvard.edu
However, Greg's patch bot is going to ask why you didn't include a Fixes: tag.
No need for a Fixes: tag for a new quirk, what is odd is that this didn't go through the linux-usb mailing list :(
I'll queue it up soon.
thanks,
greg k-h
linux-stable-mirror@lists.linaro.org