The unlock_addr rework in kernel 2.6.25 breaks 16-bit SST chips. SST
39LF160 and SST 39VF1601 are both 16-bit only chip and new uaddr value
is not correct for them. Add MTD_UADDR_0xAAAA_0x5555 for those chips.
Tested with SST 39VF1601 chip.
Signed-off-by: Atsushi Nemoto <[email protected]>
---
drivers/mtd/chips/jedec_probe.c | 14 ++++++++++----
1 files changed, 10 insertions(+), 4 deletions(-)
diff --git a/drivers/mtd/chips/jedec_probe.c b/drivers/mtd/chips/jedec_probe.c
index aa07575..97395be 100644
--- a/drivers/mtd/chips/jedec_probe.c
+++ b/drivers/mtd/chips/jedec_probe.c
@@ -191,6 +191,7 @@ enum uaddr {
MTD_UADDR_0x0555_0x0AAA,
MTD_UADDR_0x5555_0x2AAA,
MTD_UADDR_0x0AAA_0x0555,
+ MTD_UADDR_0xAAAA_0x5555,
MTD_UADDR_DONT_CARE, /* Requires an arbitrary address */
MTD_UADDR_UNNECESSARY, /* Does not require any address */
};
@@ -238,6 +239,11 @@ static const struct unlock_addr unlock_addrs[] = {
.addr2 = 0x0555
},
+ [MTD_UADDR_0xAAAA_0x5555] = {
+ .addr1 = 0xaaaa,
+ .addr2 = 0x5555
+ },
+
[MTD_UADDR_DONT_CARE] = {
.addr1 = 0x0000, /* Doesn't matter which address */
.addr2 = 0x0000 /* is used - must be last entry */
@@ -1392,8 +1398,8 @@ static const struct amd_flash_info jedec_table[] = {
.mfr_id = MANUFACTURER_SST, /* should be CFI */
.dev_id = SST39LF160,
.name = "SST 39LF160",
- .devtypes = CFI_DEVICETYPE_X16|CFI_DEVICETYPE_X8,
- .uaddr = MTD_UADDR_0x5555_0x2AAA, /* ???? */
+ .devtypes = CFI_DEVICETYPE_X16,
+ .uaddr = MTD_UADDR_0xAAAA_0x5555,
.dev_size = SIZE_2MiB,
.cmd_set = P_ID_AMD_STD,
.nr_regions = 2,
@@ -1405,8 +1411,8 @@ static const struct amd_flash_info jedec_table[] = {
.mfr_id = MANUFACTURER_SST, /* should be CFI */
.dev_id = SST39VF1601,
.name = "SST 39VF1601",
- .devtypes = CFI_DEVICETYPE_X16|CFI_DEVICETYPE_X8,
- .uaddr = MTD_UADDR_0x5555_0x2AAA, /* ???? */
+ .devtypes = CFI_DEVICETYPE_X16,
+ .uaddr = MTD_UADDR_0xAAAA_0x5555,
.dev_size = SIZE_2MiB,
.cmd_set = P_ID_AMD_STD,
.nr_regions = 2,
On Thu, Jun 19, 2008 at 04:36:48PM +0900, Atsushi Nemoto wrote:
> The unlock_addr rework in kernel 2.6.25 breaks 16-bit SST chips. SST
> 39LF160 and SST 39VF1601 are both 16-bit only chip and new uaddr value
> is not correct for them. Add MTD_UADDR_0xAAAA_0x5555 for those chips.
> Tested with SST 39VF1601 chip.
>
> Signed-off-by: Atsushi Nemoto <[email protected]>
In the future, if you want something to go into the stable tree, just
add:
cc: stable <[email protected]>
to the signed-off-by area of the patch and we will be automatically
notifed when it goes into Linus's tree and will then add it to the
-stable tree.
Otherwise it's a pain to try to track when a patch goes into mainline.
Can you notify us when this patch is accepted?
thanks,
greg k-h
On Thu, 19 Jun 2008 04:04:18 -0700, Greg KH <[email protected]> wrote:
> In the future, if you want something to go into the stable tree, just
> add:
> cc: stable <[email protected]>
> to the signed-off-by area of the patch and we will be automatically
> notifed when it goes into Linus's tree and will then add it to the
> -stable tree.
>
> Otherwise it's a pain to try to track when a patch goes into mainline.
Sure. Will do next time. I had misunderstand the statement in
stable_kernel_rules.txt, as CC: in mail header (not S-O-B area) is
enough. Thank you.
> Can you notify us when this patch is accepted?
Sure too.
---
Atsushi Nemoto
On Thu, 2008-06-19 at 16:36 +0900, Atsushi Nemoto wrote:
> - .devtypes = CFI_DEVICETYPE_X16|CFI_DEVICETYPE_X8,
> + .devtypes = CFI_DEVICETYPE_X16,
I believe you about the uaddr -- but can these devices really not be
used in 8-bit mode?
--
dwmw2
On Thursday 19 June 2008, David Woodhouse wrote:
> On Thu, 2008-06-19 at 16:36 +0900, Atsushi Nemoto wrote:
> > - .devtypes = CFI_DEVICETYPE_X16|CFI_DEVICETYPE_X8,
> > + .devtypes = CFI_DEVICETYPE_X16,
>
> I believe you about the uaddr -- but can these devices really not be
> used in 8-bit mode?
No. They are 16-bit only.
Best regards,
Stefan
On Fri, 20 Jun 2008 07:08:37 +0200, Stefan Roese <[email protected]> wrote:
> > I believe you about the uaddr -- but can these devices really not be
> > used in 8-bit mode?
>
> No. They are 16-bit only.
Right. They do not have BYTE# pin, according to their datasheets:
http://www.sst.com/downloads/datasheet/S71145.pdf
http://www.sst.com/downloads/datasheet/S71223.pdf
---
Atsushi Nemoto