mt25qu512a[1] supports locking/unlocking through BP bits in SR.
Tested using mtd-utils- flash_lock/flash_unlock for MT25QU512ABB8E12.
[1] https://media-www.micron.com/-/media/client/global/documents/products/data-sheet/nor-flash/serial-nor/mt25q/die-rev-b/mt25q_qlkt_u_512_abb_0.pdf?rev=b259aadc3bea49ea8210a41c9ad58211
Signed-off-by: Mamta Shukla <[email protected]>
---
drivers/mtd/spi-nor/micron-st.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/mtd/spi-nor/micron-st.c b/drivers/mtd/spi-nor/micron-st.c
index 4b919756a205..5d1dc8e0bbba 100644
--- a/drivers/mtd/spi-nor/micron-st.c
+++ b/drivers/mtd/spi-nor/micron-st.c
@@ -218,6 +218,8 @@ static const struct flash_info st_nor_parts[] = {
MFR_FLAGS(USE_FSR)
},
{ "mt25ql512a", INFO6(0x20ba20, 0x104400, 64 * 1024, 1024)
+ FLAGS(SPI_NOR_HAS_LOCK | SPI_NOR_HAS_TB | SPI_NOR_4BIT_BP |
+ SPI_NOR_BP3_SR_BIT6)
NO_SFDP_FLAGS(SECT_4K | SPI_NOR_DUAL_READ | SPI_NOR_QUAD_READ)
FIXUP_FLAGS(SPI_NOR_4B_OPCODES)
MFR_FLAGS(USE_FSR)
--
2.25.1
Am 2023-07-05 15:00, schrieb Mamta Shukla:
> mt25qu512a[1] supports locking/unlocking through BP bits in SR.
>
> Tested using mtd-utils- flash_lock/flash_unlock for MT25QU512ABB8E12.
>
> [1]
> https://media-www.micron.com/-/media/client/global/documents/products/data-sheet/nor-flash/serial-nor/mt25q/die-rev-b/mt25q_qlkt_u_512_abb_0.pdf?rev=b259aadc3bea49ea8210a41c9ad58211
Link: tag please
> Signed-off-by: Mamta Shukla <[email protected]>
> ---
> drivers/mtd/spi-nor/micron-st.c | 2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git a/drivers/mtd/spi-nor/micron-st.c
> b/drivers/mtd/spi-nor/micron-st.c
> index 4b919756a205..5d1dc8e0bbba 100644
> --- a/drivers/mtd/spi-nor/micron-st.c
> +++ b/drivers/mtd/spi-nor/micron-st.c
> @@ -218,6 +218,8 @@ static const struct flash_info st_nor_parts[] = {
> MFR_FLAGS(USE_FSR)
> },
> { "mt25ql512a", INFO6(0x20ba20, 0x104400, 64 * 1024, 1024)
> + FLAGS(SPI_NOR_HAS_LOCK | SPI_NOR_HAS_TB | SPI_NOR_4BIT_BP |
> + SPI_NOR_BP3_SR_BIT6)
With the changes above:
Reviewed-by: Michael Walle <[email protected]>
Unrelated to this patch, but could you please dump the SFDP tables,
see [1].
FWIW, I noticed the difference between MT25QU and MT25QL here. But
I don't think we can do anything about it. It is just another example,
that the name is mostly irrelavant/cannot be trusted. Vendors tend to
reuse the id for different (software compatible probably) parts. Maybe
we can get rid of it entirely. Tudor, Pratyush?
-michael
[1]
https://lore.kernel.org/all/[email protected]/
Hello Michael,
On 05.07.23 15:22, Michael Walle wrote:
> This email is not from Hexagon’s Office 365 instance. Please be careful
> while clicking links, opening attachments, or replying to this email.
>
>
> Am 2023-07-05 15:00, schrieb Mamta Shukla:
>> mt25qu512a[1] supports locking/unlocking through BP bits in SR.
>>
>> Tested using mtd-utils- flash_lock/flash_unlock for MT25QU512ABB8E12.
>>
>
>> [1]
>> https://media-www.micron.com/-/media/client/global/documents/products/data-sheet/nor-flash/serial-nor/mt25q/die-rev-b/mt25q_qlkt_u_512_abb_0.pdf?rev=b259aadc3bea49ea8210a41c9ad58211
>
> Link: tag please
Added in v2.
>> Signed-off-by: Mamta Shukla <[email protected]>
>> ---
>> drivers/mtd/spi-nor/micron-st.c | 2 ++
>> 1 file changed, 2 insertions(+)
>>
>> diff --git a/drivers/mtd/spi-nor/micron-st.c
>> b/drivers/mtd/spi-nor/micron-st.c
>> index 4b919756a205..5d1dc8e0bbba 100644
>> --- a/drivers/mtd/spi-nor/micron-st.c
>> +++ b/drivers/mtd/spi-nor/micron-st.c
>> @@ -218,6 +218,8 @@ static const struct flash_info st_nor_parts[] = {
>> MFR_FLAGS(USE_FSR)
>> },
>> { "mt25ql512a", INFO6(0x20ba20, 0x104400, 64 * 1024, 1024)
>> + FLAGS(SPI_NOR_HAS_LOCK | SPI_NOR_HAS_TB | SPI_NOR_4BIT_BP |
>> + SPI_NOR_BP3_SR_BIT6)
>
> With the changes above:
>
> Reviewed-by: Michael Walle <[email protected]>
>
> Unrelated to this patch, but could you please dump the SFDP tables,
> see [1].
Apologies for the confusion. This patch was only intended for mt25qu512a
chip. Modified in v2.
Here is enumeration log and SFDP table:
[ 214.275995] ACPI: Host-directed Dynamic ACPI Table Load:
[ 214.281387] ACPI: SSDT 0xFFFF8EFBC5A2C300 0000EC (v02 ALASKA MT25QU
00001000 INTL 20190509)
[ 315.452108] spi-nor spi-PRP0001:00: mt25qu512a (65536 Kbytes)
xxd -p /sys/bus/spi/devices/spi-PRP0001:00/spi-nor/sfdp
53464450060101ff00060110300000ff84000102800000ffffffffffffff
ffffffffffffffffffffffffffffffffffffe520fbffffffff1f29eb276b
273b27bbffffffffffff27bbffff29eb0c2010d80f520000244a99008b8e
03e1ac0127387a757a75fbbdd55c4a0f82ff81bd3d36ffffffffffffffff
ffffffffffffffffffe7ffff21dcffff
cat /sys/bus/spi/devices/spi-PRP0001:00/spi-nor/jedec_id
20bb20104400
cat /sys/bus/spi/devices/spi-PRP0001:00/spi-nor/manufacturer
st
cat /sys/bus/spi/devices/spi-PRP0001:00/spi-nor/partname
mt25qu512a
> FWIW, I noticed the difference between MT25QU and MT25QL here. But
> I don't think we can do anything about it. It is just another example,
> that the name is mostly irrelavant/cannot be trusted. Vendors tend to
> reuse the id for different (software compatible probably) parts. Maybe
> we can get rid of it entirely. Tudor, Pratyush?
>
> -michael
>
> [1]
> https://lore.kernel.org/all/[email protected]/
Thanks,
Mamta
Am 2023-07-05 15:22, schrieb Michael Walle:
> FWIW, I noticed the difference between MT25QU and MT25QL here. But
> I don't think we can do anything about it. It is just another example,
> that the name is mostly irrelavant/cannot be trusted. Vendors tend to
> reuse the id for different (software compatible probably) parts. Maybe
> we can get rid of it entirely. Tudor, Pratyush?
I must have been blind, the ID is different (ba vs bb), but my point
is still valid.
-michael
On 06.07.2023 10:26, Michael Walle wrote:
> Am 2023-07-05 15:22, schrieb Michael Walle:
>
>> FWIW, I noticed the difference between MT25QU and MT25QL here. But
>> I don't think we can do anything about it. It is just another example,
>> that the name is mostly irrelavant/cannot be trusted. Vendors tend to
>> reuse the id for different (software compatible probably) parts. Maybe
>> we can get rid of it entirely. Tudor, Pratyush?
>
> I must have been blind, the ID is different (ba vs bb), but my point
> is still valid.
>
the name is good for debug purposes to differentiate between flashes
that use the same ID. But otherwise I too don't see a great benefit of
showing/printing the flash name.