From patchwork Sat Aug 16 13:13:08 2014 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Patchwork-Submitter: =?utf-8?b?UmFmYcWCIE1pxYJlY2tp?= X-Patchwork-Id: 380476 Return-Path: X-Original-To: incoming@patchwork.ozlabs.org Delivered-To: patchwork-incoming@bilbo.ozlabs.org Received: from bombadil.infradead.org (bombadil.infradead.org [IPv6:2001:1868:205::9]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ozlabs.org (Postfix) with ESMTPS id 390B1140119 for ; Sat, 16 Aug 2014 23:16:21 +1000 (EST) Received: from localhost ([127.0.0.1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.80.1 #2 (Red Hat Linux)) id 1XIdo7-0007Mj-Lr; Sat, 16 Aug 2014 13:14:07 +0000 Received: from mail-wi0-x22c.google.com ([2a00:1450:400c:c05::22c]) by bombadil.infradead.org with esmtps (Exim 4.80.1 #2 (Red Hat Linux)) id 1XIdo5-0007JI-Jy for linux-mtd@lists.infradead.org; Sat, 16 Aug 2014 13:14:06 +0000 Received: by mail-wi0-f172.google.com with SMTP id n3so1859561wiv.11 for ; Sat, 16 Aug 2014 06:13:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:cc:subject:date:message-id:in-reply-to:references :mime-version:content-type:content-transfer-encoding; bh=T0MqbBy7NN4H4k1Ssds/fAqEGqLk/xGVDxda5npYHmw=; b=tWeP8p0gr9rYNliNI82u9Ky0Sbga1v27XnAPUI5d7XefVjyB9mmMsAWGyCD+o7QrL1 px1v32v1fBtSDvvfWtWkg2gSFK6BJKq/biJsoaJh/Ouav9LtmAAc8tUb3vt3j0thgGmb sSuwM5wwCdRb5veOGb7AzWgSPZIW04saIp3lHIDek2jltUTBagK30ehVY1frG/31xfHb OsrP+kmq8TpK/UmYllo9xD88VKX8IEILDWc5FPuy5Y4R1Z3JHFeLTjAgfe+BldEItMvA TQaAmQN+T5bjJ3YMi53vkJjkZ0I54fd+rLz4TMEFVxu+hEh0fcEMQ4HZ2T0Ptimln/1I F8Hw== X-Received: by 10.181.5.39 with SMTP id cj7mr62757318wid.79.1408194814611; Sat, 16 Aug 2014 06:13:34 -0700 (PDT) Received: from linux-tdhb.lan (ip-194-187-74-233.konfederacka.maverick.com.pl. [194.187.74.233]) by mx.google.com with ESMTPSA id pf4sm16891070wic.18.2014.08.16.06.13.32 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sat, 16 Aug 2014 06:13:33 -0700 (PDT) From: =?UTF-8?q?Rafa=C5=82=20Mi=C5=82ecki?= To: linux-mtd@lists.infradead.org, David Woodhouse , Artem Bityutskiy , Brian Norris Subject: [PATCH V2] mtd: move support for struct flash_platform_data into m25p80 Date: Sat, 16 Aug 2014 15:13:08 +0200 Message-Id: <1408194788-10434-1-git-send-email-zajec5@gmail.com> X-Mailer: git-send-email 1.8.4.5 In-Reply-To: <1407420506-20696-1-git-send-email-zajec5@gmail.com> References: <1407420506-20696-1-git-send-email-zajec5@gmail.com> MIME-Version: 1.0 X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20140816_061405_811679_770CBA47 X-CRM114-Status: GOOD ( 17.00 ) X-Spam-Score: -0.6 (/) X-Spam-Report: SpamAssassin version 3.4.0 on bombadil.infradead.org summary: Content analysis details: (-0.6 points) pts rule name description ---- ---------------------- -------------------------------------------------- -0.7 RCVD_IN_DNSWL_LOW RBL: Sender listed at http://www.dnswl.org/, low trust [2a00:1450:400c:c05:0:0:0:22c listed in] [list.dnswl.org] 0.2 FREEMAIL_ENVFROM_END_DIGIT Envelope-from freemail username ends in digit (zajec5[at]gmail.com) 0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail provider (zajec5[at]gmail.com) -0.0 SPF_PASS SPF: sender matches SPF record -0.1 DKIM_VALID Message has at least one valid DKIM or DK signature -0.1 DKIM_VALID_AU Message has a valid DKIM or DK signature from author's domain 0.1 DKIM_SIGNED Message has a DKIM or DK signature, not necessarily valid Cc: =?UTF-8?q?Rafa=C5=82=20Mi=C5=82ecki?= X-BeenThere: linux-mtd@lists.infradead.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Linux MTD discussion mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: "linux-mtd" Errors-To: linux-mtd-bounces+incoming=patchwork.ozlabs.org@lists.infradead.org This "type" seems to be an extra hint for m25p80 about the flash. Some archs register flash_platform_data with "name" set to "m25p80" and then with a real flash name set in "type". It seems to be a trick specific to the m25p80 so let's move it out of spi-nor. Btw switch to the spi_nor_match_id instead of iterating spi_nor_ids. Signed-off-by: Rafał Miłecki --- V2: Comment usage of data->type Set mtd.name in m25p80 --- drivers/mtd/devices/m25p80.c | 22 ++++++++++++++++++++-- drivers/mtd/spi-nor/spi-nor.c | 28 +--------------------------- 2 files changed, 21 insertions(+), 29 deletions(-) diff --git a/drivers/mtd/devices/m25p80.c b/drivers/mtd/devices/m25p80.c index ed7e0a1b..4d40c96 100644 --- a/drivers/mtd/devices/m25p80.c +++ b/drivers/mtd/devices/m25p80.c @@ -193,11 +193,14 @@ static int m25p_probe(struct spi_device *spi) { struct mtd_part_parser_data ppdata; struct flash_platform_data *data; + const struct spi_device_id *id = NULL; struct m25p *flash; struct spi_nor *nor; enum read_mode mode = SPI_NOR_NORMAL; int ret; + data = dev_get_platdata(&spi->dev); + flash = devm_kzalloc(&spi->dev, sizeof(*flash), GFP_KERNEL); if (!flash) return -ENOMEM; @@ -223,11 +226,26 @@ static int m25p_probe(struct spi_device *spi) mode = SPI_NOR_QUAD; else if (spi->mode & SPI_RX_DUAL) mode = SPI_NOR_DUAL; - ret = spi_nor_scan(nor, spi_get_device_id(spi), mode); + + if (data && data->name) + flash->mtd.name = data->name; + + /* For some (historical?) reason many platforms provide two different + * names in flash_platform_data: "name" and "type". Quite often name is + * set to "m25p80" and then "type" provides a real chip name. + * If that's the case, respsec "type" and ignore "name". + */ + if (data && data->type) + id = spi_nor_match_id(data->type); + + /* If we didn't get name from platform, simply use "modalias". */ + if (!id) + id = spi_get_device_id(spi); + + ret = spi_nor_scan(nor, id, mode); if (ret) return ret; - data = dev_get_platdata(&spi->dev); ppdata.of_node = spi->dev.of_node; return mtd_device_parse_register(&flash->mtd, NULL, &ppdata, diff --git a/drivers/mtd/spi-nor/spi-nor.c b/drivers/mtd/spi-nor/spi-nor.c index 03e0ab8..ba3f61e 100644 --- a/drivers/mtd/spi-nor/spi-nor.c +++ b/drivers/mtd/spi-nor/spi-nor.c @@ -915,7 +915,6 @@ int spi_nor_scan(struct spi_nor *nor, const struct spi_device_id *id, enum read_mode mode) { struct flash_info *info; - struct flash_platform_data *data; struct device *dev = nor->dev; struct mtd_info *mtd = nor->mtd; struct device_node *np = dev->of_node; @@ -926,28 +925,6 @@ int spi_nor_scan(struct spi_nor *nor, const struct spi_device_id *id, if (ret) return ret; - /* Platform data helps sort out which chip type we have, as - * well as how this board partitions it. If we don't have - * a chip ID, try the JEDEC id commands; they'll work for most - * newer chips, even if we don't recognize the particular chip. - */ - data = dev_get_platdata(dev); - if (data && data->type) { - const struct spi_device_id *plat_id; - - for (i = 0; i < ARRAY_SIZE(spi_nor_ids) - 1; i++) { - plat_id = &spi_nor_ids[i]; - if (strcmp(data->type, plat_id->name)) - continue; - break; - } - - if (i < ARRAY_SIZE(spi_nor_ids) - 1) - id = plat_id; - else - dev_warn(dev, "unrecognized id %s\n", data->type); - } - info = (void *)id->driver_data; if (info->jedec_id) { @@ -985,11 +962,8 @@ int spi_nor_scan(struct spi_nor *nor, const struct spi_device_id *id, write_sr(nor, 0); } - if (data && data->name) - mtd->name = data->name; - else + if (!mtd->name) mtd->name = dev_name(dev); - mtd->type = MTD_NORFLASH; mtd->writesize = 1; mtd->flags = MTD_CAP_NORFLASH;