drivers/usb/storage/unusual_devs.h | 7 +++++++ 1 file changed, 7 insertions(+)
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",
--
2.47.1On 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
© 2016 - 2026 Red Hat, Inc.