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>] [day] [month] [year] [list]
Date:	Thu, 29 Oct 2015 22:02:49 -0700
From:	Brian Norris <computersforpeace@...il.com>
To:	"bayi.cheng" <bayi.cheng@...iatek.com>
Cc:	Mark Rutland <mark.rutland@....com>, devicetree@...r.kernel.org,
	Marek Vasut <marex@...x.de>, srv_heupstream@...iatek.com,
	Pawel Moll <pawel.moll@....com>,
	Ian Campbell <ijc+devicetree@...lion.org.uk>,
	Sascha Hauer <s.hauer@...gutronix.de>,
	linux-kernel@...r.kernel.org, Rob Herring <robh+dt@...nel.org>,
	linux-mediatek@...ts.infradead.org,
	Kumar Gala <galak@...eaurora.org>,
	Matthias Brugger <matthias.bgg@...il.com>,
	linux-mtd@...ts.infradead.org,
	David Woodhouse <dwmw2@...radead.org>,
	linux-arm-kernel@...ts.infradead.org
Subject: Re: [PATCH v4 2/3] mtd: mtk-nor: mtk serial flash controller driver

Hi Bayi,

On Fri, Oct 30, 2015 at 10:12:39AM +0800, bayi.cheng wrote:
> Hi Brian,  The current station is as follows.
> 
> 1: put 0x9F to MTK_NOR_PRGDATA5_REG, and five 0x0 to
> MTK_NOR_PRGDATA4_REG ~ MTK_NOR_PRGDATA0_REG, then set (1 + 5) * 8 
> to MTK_NOR_CNT_REG, for this way, we can read five IDs.
> 
> 2: put 0x9F to MTK_NOR_PRGDATA5_REG, and five 0x0 to
> MTK_NOR_PRGDATA4_REG ~ MTK_NOR_PRGDATA0_REG, then set (1 + 5 + 1) * 8
> to MTK_NOR_CNT_REG, for this way, we can read six IDs.
> In this case, nor flash IDs can be read from MTK_NOR_SHREG5_REG to
> MTK_NOR_SHREG0_REG . Thanks!

Thanks for the update. Glad to hear you can read more bytes there; the
extra number of Shift Registers *looked* to me like you should be able
to read even more than 5...

So in my other email, I showed you how I generalized the TX/RX function,
so it can handle most of both the write_reg() and read_reg() functions.
I'm not 100% sure now that it has all of the RX path correct; it worked
for the cases I could test, but it's confusing when reading the manual
to figure out which SHREG register I should start from. But anyway, I
think it should only take some small adjustments to my patch to make it
handle things properly.

I'd really appreciate it if you could incorporate my feedback and
review/improve the ..._do_tx_rx() function I wrote, to make sure it
handles reading any arbitrary number of bytes (at least up to 6). So,
you might, for example, run some tests where you have spi-nor.c call

	nor->read_reg(nor, SPINOR_OP_RDID, id, idlen)

with varying values for 'idlen', and make sure they all work properly.

Let me know if you have any questions about comments either here, or on
v5.

Regards,
Brian
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ