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]
Date:	Wed, 22 Oct 2014 09:06:51 +0200
From:	Rafał Miłecki <zajec5@...il.com>
To:	bpqw <bpqw@...ron.com>
Cc:	Marek Vasut <marex@...x.de>,
	"geert+renesas@...der.be" <geert+renesas@...der.be>,
	"dwmw2@...radead.org" <dwmw2@...radead.org>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	"linux-mtd@...ts.infradead.org" <linux-mtd@...ts.infradead.org>,
	"grmoore@...era.com" <grmoore@...era.com>,
	Brian Norris <computersforpeace@...il.com>,
	"shijie8@...il.com" <shijie8@...il.com>
Subject: Re: [PATCH 1/1 v2] driver:mtd:spi-nor:fix spi_nor_scan overwrite
 platform ID point

On 16 October 2014 02:52, bpqw <bpqw@...ron.com> wrote:
> For example:
>
> const struct spi_device_id spi_nor_ids[] = {
> ......
> ......
> ......
>         { "n25q064",     INFO(0x20ba17, 0, 64 * 1024,  128, 0) },
>         { "n25q128a11",  INFO(0x20bb18, 0, 64 * 1024,  256, 0) },//former right platform point will be overwrote by this data info.
>         { "n25q128a13",  INFO(0x20bb18, 0x1234, 64 * 1024,  512, SECT_4K) },//this is the right platform data,I want to match this data info.
>         { "n25q256a",    INFO(0x20ba19, 0, 64 * 1024,  512, SECT_4K) },
>         { "n25q512a",    INFO(0x20bb20, 0, 64 * 1024, 1024, SECT_4K) },

Your initial commit was really missing some example indeed. It was
trying to understand it for 10 minutes with no luck (until seeing
above case) ;)

I see problem in spi-nor that your patch reveals:
ISSUE: spi-nor accepts any entry from spi_nor_ids with no ext_id
specified as long as the jedec_id matches
I guess reason behind this is to support chips with the same
parameters but different extended IDs. That simplifies the driver and
support for extra chips but may also cause problems like in your case.

So AFAIU your patch tries to force using specific flash info, because
JEDEC based detection fails. In general this is what we try to avoid.
We want to auto-detect flash chips and to relieve platform code / DT.

Could we drop this patch and modify spi-nor to detect your chip
automatically? That would be much cleaner solution to me.
--
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