From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752407AbdCVUPW (ORCPT ); Wed, 22 Mar 2017 16:15:22 -0400 Received: from conuserg-07.nifty.com ([210.131.2.74]:24982 "EHLO conuserg-07.nifty.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751437AbdCVUL6 (ORCPT ); Wed, 22 Mar 2017 16:11:58 -0400 DKIM-Filter: OpenDKIM Filter v2.10.3 conuserg-07.nifty.com v2MK895w029452 X-Nifty-SrcIP: [111.169.71.157] From: Masahiro Yamada To: linux-mtd@lists.infradead.org Cc: laurent.monat@idquantique.com, thorsten.christiansson@idquantique.com, Enrico Jorns , Artem Bityutskiy , Dinh Nguyen , Boris Brezillon , Marek Vasut , Graham Moore , David Woodhouse , Masami Hiramatsu , Chuanxiao Dong , Jassi Brar , Masahiro Yamada , linux-kernel@vger.kernel.org, Brian Norris , Richard Weinberger , Cyrille Pitchen Subject: [RESEND PATCH v2 08/53] mtd: nand: denali: introduce capability flag Date: Thu, 23 Mar 2017 05:07:07 +0900 Message-Id: <1490213273-8571-9-git-send-email-yamada.masahiro@socionext.com> X-Mailer: git-send-email 2.7.4 In-Reply-To: <1490213273-8571-1-git-send-email-yamada.masahiro@socionext.com> References: <1490213273-8571-1-git-send-email-yamada.masahiro@socionext.com> Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org The Denali NAND controller IP has various customizable features. SoC vendors can choose desired functions when a delivery RTL is created. It means there are several variants for this IP. For example, the Intel version is equipped with 32bit DMA, whereas the IP for UniPhier SoC family with 64bit DMA. This driver was originally written for some Intel platforms with Intel specific things hard-coded. What is worse, the revision register of this IP does not work to distinguish such features. We need to do something to make the driver available for other SoCs. Let's introduce a caps member to the denali_nand_info structure to switch on/off various features. Also, add struct denali_dt_data to store the capability associated with compatible string. Boris suggested this approach in discussion [1] instead of a new DT property for every feature. [1] https://lkml.org/lkml/2016/3/29/142 Signed-off-by: Masahiro Yamada --- Changes in v2: None drivers/mtd/nand/denali.h | 1 + drivers/mtd/nand/denali_dt.c | 18 +++++++++--------- 2 files changed, 10 insertions(+), 9 deletions(-) diff --git a/drivers/mtd/nand/denali.h b/drivers/mtd/nand/denali.h index 8df2285..eed001d 100644 --- a/drivers/mtd/nand/denali.h +++ b/drivers/mtd/nand/denali.h @@ -338,6 +338,7 @@ struct denali_nand_info { uint32_t devnum; /* represent how many nands connected */ uint32_t bbtskipbytes; uint32_t max_banks; + unsigned int caps; }; extern int denali_init(struct denali_nand_info *denali); diff --git a/drivers/mtd/nand/denali_dt.c b/drivers/mtd/nand/denali_dt.c index 5607fcd..293ddb8 100644 --- a/drivers/mtd/nand/denali_dt.c +++ b/drivers/mtd/nand/denali_dt.c @@ -29,6 +29,10 @@ struct denali_dt { struct clk *clk; }; +struct denali_dt_data { + unsigned int caps; +}; + static const struct of_device_id denali_nand_dt_ids[] = { { .compatible = "denali,denali-nand-dt" }, { /* sentinel */ } @@ -42,23 +46,19 @@ static int denali_dt_probe(struct platform_device *ofdev) { struct resource *denali_reg, *nand_data; struct denali_dt *dt; + const struct denali_dt_data *data; struct denali_nand_info *denali; int ret; - const struct of_device_id *of_id; - - of_id = of_match_device(denali_nand_dt_ids, &ofdev->dev); - if (of_id) { - ofdev->id_entry = of_id->data; - } else { - pr_err("Failed to find the right device id.\n"); - return -ENOMEM; - } dt = devm_kzalloc(&ofdev->dev, sizeof(*dt), GFP_KERNEL); if (!dt) return -ENOMEM; denali = &dt->denali; + data = of_device_get_match_data(&ofdev->dev); + if (data) + denali->caps = data->caps; + denali->platform = DT; denali->dev = &ofdev->dev; denali->irq = platform_get_irq(ofdev, 0); -- 2.7.4