linux-kernel - Re: [PATCH] [PATCH v5] mtd:spi-nor: Add Altera Quad SPI Driver

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] [thread-next>] [day] [month] [year] [list]

Message-ID: <20150820203726.GE74600@google.com>
Date:	Thu, 20 Aug 2015 13:37:26 -0700
From:	Brian Norris <computersforpeace@...il.com>
To:	Viet Nga Dao <vndao@...era.com>
Cc:	Marek Vasut <marex@...x.de>,
	"linux-mtd@...ts.infradead.org" <linux-mtd@...ts.infradead.org>,
	David Woodhouse <dwmw2@...radead.org>,
	"devicetree@...r.kernel.org" <devicetree@...r.kernel.org>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	nga_chi86 <ngachi86@...il.com>
Subject: Re: [PATCH] [PATCH v5] mtd:spi-nor: Add Altera Quad SPI Driver

On Thu, Aug 20, 2015 at 05:18:14PM +0800, Viet Nga Dao wrote:
> You might misunderstand the hardware problem i mention here. This soft
> IP controller is able to provide the ID for our Altera EPCS/EPCQ flash
> chips, which are non JEDEC chips. As from EPCQ device data sheet
> (https://www.altera.com/content/dam/altera-www/global/en_US/pdfs/literature/hb/cfg/cfg_cf52012.pdf),
> the device ID is 8 bit data.

8 bits of data is vastly insufficient for uniquely identifying a flash.
This is not extendible and is not really a candidate for inclusion in
mainline, unless it's somehow guaranteed that these flash can only be
used with your controller (and I'm not sure how you would do that).
Otherwise, you need to augment every flash with more out-of-band
device-tree information.

> The remaining problem here is that this
> controller is able to support Micron chips but it currently has
> limitation in providing only 8 bit ID, which is not full JEDEC ID for
> Micron chips.

You're just proving my point. I will not support "READ ID" detection
that is based on only 8 bits of ID.

> Hence, we are asking hardware engineer to find out the
> solution so that the driver does not need to do any dirty hacking.

OK, then I wish your hardware team great speed.

> And
> so, this table should still be here even hardware fix will take place
> or not.

I'm not sure how you come to this conclusion.

BTW, to reiterate one other question that I feel wasn't adequately
answered: what does the full ID string look like for these EPCS/EPCQ
flash chips? Not the ID as seen by your limited controller, but the ID
that can be reported by the flash chip. Is it really only an 8-bit
number? Or does it have a longer string that your controller just can't
read?

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/