Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S932399AbaJVHGw (ORCPT ); Wed, 22 Oct 2014 03:06:52 -0400 Received: from mail-ie0-f171.google.com ([209.85.223.171]:60717 "EHLO mail-ie0-f171.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750756AbaJVHGv (ORCPT ); Wed, 22 Oct 2014 03:06:51 -0400 MIME-Version: 1.0 In-Reply-To: References: <201410150045.53976.marex@denx.de> Date: Wed, 22 Oct 2014 09:06:51 +0200 Message-ID: Subject: Re: [PATCH 1/1 v2] driver:mtd:spi-nor:fix spi_nor_scan overwrite platform ID point From: =?UTF-8?B?UmFmYcWCIE1pxYJlY2tp?= To: bpqw Cc: Marek Vasut , "geert+renesas@glider.be" , "dwmw2@infradead.org" , "linux-kernel@vger.kernel.org" , "linux-mtd@lists.infradead.org" , "grmoore@altera.com" , Brian Norris , "shijie8@gmail.com" Content-Type: text/plain; charset=UTF-8 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 16 October 2014 02:52, bpqw 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@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/