lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <ff66efae07b4b97ac5f891e6b37c348105dc17db.camel@yadro.com>
Date:   Wed, 30 Sep 2020 19:22:45 +0300
From:   Ivan Mikhaylov <i.mikhaylov@...ro.com>
To:     Vignesh Raghavendra <vigneshr@...com>,
        Tudor Ambarus <tudor.ambarus@...rochip.com>,
        Miquel Raynal <miquel.raynal@...tlin.com>,
        Richard Weinberger <richard@....at>
CC:     <linux-mtd@...ts.infradead.org>, <linux-kernel@...r.kernel.org>
Subject: Re: [RESEND PATCH 1/2] mtd: spi-nor: do not touch TB bit without
 SPI_NOR_HAS_TB

On Wed, 2020-09-30 at 19:30 +0530, Vignesh Raghavendra wrote:
> 
> On 9/30/20 6:37 PM, Ivan Mikhaylov wrote:
> > On Wed, 2020-09-30 at 15:06 +0530, Vignesh Raghavendra wrote:
> > > On 9/21/20 4:54 PM, Ivan Mikhaylov wrote:
> > > > Some chips like macronix don't have TB(Top/Bottom protection)
> > > > bit in the status register. Do not write tb_mask inside status
> > > > register, unless SPI_NOR_HAS_TB is present for the chip.
> > > > 
> > > 
> > > Not entirely accurate.. Macronix chips have TB bit in config register
> > > and is OTP and hence should not be touched ideally...
> > > 
> > > You still need to "read" that bit to determine actual scheme (Top vs
> > > Bottom). This is needs to be done before 2/2 enables SPI_NOR_HAS_LOCK
> > > flag for macronix flashes.
> > 
> > Vignesh, that's the point about this commit to generalize this part about TB
> > bit
> > plus there is already exist SPI_NOR_HAS_TB flag which representing state of
> > TB
> > existence. I didn't add any support for macronix's TB bit, that's true but
> > that's enough to make macronix chips able to use lock mechanism with default
> > 'use_top' or any other chips which doesn't have TB bit.
> 
> Right, but 2/2 "enables" locking mechanism for Macronix flashes. Therefore
> its 
> necessary to take TB bit into account so that implementation is correct. 
> What if OTP bit is set as "use_bottom"? Although this is non default, 
> we need to take care of this case for correctness.

Maybe wording of my commit message is incorrect, let's try to think about this
commit without macronix words in it. What do you think? Just additional patch
for control TB writes.

mtd: spi-nor: do not touch TB bit without SPI_NOR_HAS_TB
    
Do not write tb_mask inside status register, unless SPI_NOR_HAS_TB is   		
present for the chip.

If we talking from OTP point for Macronix then in this case better way to make
lock/unlock inside macronix.c which brings a lot of copypaste. I'll try to
rework it.

> > > I guess macronix does not support SR_SRWD right? This needs special
> > > treatment as well.
> > 
> > It does support SR_SRWD as well. No need any special treatment here.
> > 
> 
> I did not find it in one Macronix datasheet at least:
> https://www.macronix.com/Lists/Datasheet/Attachments/7902/MX25L25673G,%203V,%20256Mb,%20v1.6.pdf
> 
> Are you sure all Macronix flashes support SRWD?
> 

No, I'm not sure, I did it more than month ago and I've checked BP0-X bits +
SRWD bits in the documentation at this time for whole set of chips in
macronix.c. This one (mx25l25673g) not even listed in macronix.c. Also SRWD was
present there until 1.3 rev for this chip from documentation.

I've noticed one thing also:

	{ "mx25l51245g", INFO(0xc2201a, 0, 64 * 1024, 1024,
			      SECT_4K | SPI_NOR_DUAL_READ | SPI_NOR_QUAD_READ |
			      SPI_NOR_4B_OPCODES | SPI_NOR_HAS_LOCK |
			      SPI_NOR_4BIT_BP) },
	{ "mx66l51235l", INFO(0xc2201a, 0, 64 * 1024, 1024,
			      SPI_NOR_DUAL_READ | SPI_NOR_QUAD_READ |
			      SPI_NOR_4B_OPCODES | SPI_NOR_HAS_LOCK |
			      SPI_NOR_4BIT_BP) },

mx25l51245g and mx66l51235l have same id and different flags(SECT_4K).
As example if you have mx66l51235l, driver will take mx25l51245g because it
comes first in the chip list. I don't think that's right but I didn't find
information how to distinguish them.

Thanks.

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ