Received: by 2002:a25:1985:0:0:0:0:0 with SMTP id 127csp3819543ybz; Tue, 28 Apr 2020 00:42:42 -0700 (PDT) X-Google-Smtp-Source: APiQypLT8Jb+d4op4uOeFpPSzRioY5UELxbIoYVMOK+ZNHJQDJNKfEv1+Dxaf9n/DbwMK8yIH6QG X-Received: by 2002:a17:906:f74e:: with SMTP id jp14mr24226599ejb.15.1588059761910; Tue, 28 Apr 2020 00:42:41 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1588059761; cv=none; d=google.com; s=arc-20160816; b=q03fjWmMnZuK5RSUDkRvd+hHvt5X7Q/x/qXfL4yCXfUs44vbyEYFmFiaB1nifyDO2P NfjNaWiN/dmW9LNml+mY7oX3UJ7cJN7YBPIUZ7vqcSboPm+IGW36HDjPDuS64t06Ty8I JXyrVka0tO06EWQKRlyd/XwUyY2V1PAhepB2UfJ7p8kuFHsRMkBeevDQH3bafvKgxvY2 1jcnQlAjZVTOC8nUxTbkNJxYDeYXv4Qk2vwSTo/d97pWlX62i5sQjWN6yaeE3n9uZrDT tWrUXaM3oI+nMW6gb/us3CAhyUkQFH/evh7FPnvBg1S5lja4wrCw4HDkswRhpqUHA1Zd lKAA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding:mime-version :organization:references:in-reply-to:message-id:subject:cc:to:from :date; bh=EgAHVR2/xt2xFRwod4PYhFpb+O2TGQoz5lD+EpK/oc4=; b=r+4R57KYuMEYLjGAfHyOHuyBaOVcCMO39BSjzwCzasSDWn4Hy3G53IAQXNyjwPIX/A h6VlAmMR+capxv/4TXqTstX1DyRYZsz2/OhoMjKI11wtImDZQFYfr4IsQSd0WHMsaSiW 5xCLJDc/q6zppdnCXNGeUV6LrV7DpO6ejMuS+b/Wm8kLJL48dp+FoN0PJwK8MiySn8NZ BM+nhhJaJ6eWv64IIfAhKCt6kBL0q4eJEFDkGmN1ekt7p2pBkAbeQw+9Ywrom0ITaTl6 2YZYzvqkMa2sVwPV4MBlRTYTff3md1JMrUNDxtiqvGKOj7+y9Ov3G9i7XQ4wReFmNbk2 W4DQ== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id dc9si1335945ejb.503.2020.04.28.00.42.18; Tue, 28 Apr 2020 00:42:41 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726377AbgD1Hk7 convert rfc822-to-8bit (ORCPT + 99 others); Tue, 28 Apr 2020 03:40:59 -0400 Received: from relay1-d.mail.gandi.net ([217.70.183.193]:11039 "EHLO relay1-d.mail.gandi.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726253AbgD1Hk6 (ORCPT ); Tue, 28 Apr 2020 03:40:58 -0400 X-Originating-IP: 91.224.148.103 Received: from xps13 (unknown [91.224.148.103]) (Authenticated sender: miquel.raynal@bootlin.com) by relay1-d.mail.gandi.net (Postfix) with ESMTPSA id 65549240008; Tue, 28 Apr 2020 07:40:50 +0000 (UTC) Date: Tue, 28 Apr 2020 09:40:49 +0200 From: Miquel Raynal To: "Ramuthevar, Vadivel MuruganX" Cc: Boris Brezillon , linux-kernel@vger.kernel.org, linux-mtd@lists.infradead.org, devicetree@vger.kernel.org, cheol.yong.kim@intel.com, hauke.mehrtens@intel.com, qi-ming.wu@intel.com, vigneshr@ti.com, arnd@arndb.de, richard@nod.at, brendanhiggins@google.com, linux-mips@vger.kernel.org, robh+dt@kernel.org, tglx@linutronix.de, masonccyang@mxic.com.tw, andriy.shevchenko@intel.com Subject: Re: [PATCH v3 2/2] mtd: rawnand: Add NAND controller support on Intel LGM SoC Message-ID: <20200428094049.3c0d4730@xps13> In-Reply-To: References: <20200423162113.38055-1-vadivel.muruganx.ramuthevar@linux.intel.com> <20200423162113.38055-3-vadivel.muruganx.ramuthevar@linux.intel.com> <20200424183612.4cfdbb6a@collabora.com> <20200427175127.0518c193@xps13> <20200428082759.25065146@collabora.com> <38334812-21b9-5b2c-db84-01c9eacc84d0@linux.intel.com> <20200428084704.5e04232a@collabora.com> Organization: Bootlin X-Mailer: Claws Mail 3.17.4 (GTK+ 2.24.32; x86_64-pc-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8BIT Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi Vadivel MuruganX, "Ramuthevar, Vadivel MuruganX" wrote on Tue, 28 Apr 2020 14:50:35 +0800: > Hi Boris, > > On 28/4/2020 2:47 pm, Boris Brezillon wrote: > > On Tue, 28 Apr 2020 14:40:58 +0800 > > "Ramuthevar, Vadivel MuruganX" > > wrote: > > > >> Hi Boris, > >> > >> On 28/4/2020 2:27 pm, Boris Brezillon wrote: > >>> On Tue, 28 Apr 2020 14:17:30 +0800 > >>> "Ramuthevar, Vadivel MuruganX" > >>> wrote: > >>> >>>> Hi Miquel, > >>>> > >>>> Thank you very much for the review comments and your time... > >>>> > >>>> On 27/4/2020 11:51 pm, Miquel Raynal wrote: > >>>>> Hi Ramuthevar, > >>>>> >>>>>>> +static int ebu_nand_probe(struct platform_device *pdev) > >>>>>>> +{ > >>>>>>> + struct device *dev = &pdev->dev; > >>>>>>> + struct ebu_nand_controller *ebu_host; > >>>>>>> + struct nand_chip *nand; > >>>>>>> + phys_addr_t nandaddr_pa; > >>>>>>> + struct mtd_info *mtd; > >>>>>>> + struct resource *res; > >>>>>>> + int ret; > >>>>>>> + u32 cs; > >>>>>>> + > >>>>>>> + ebu_host = devm_kzalloc(dev, sizeof(*ebu_host), GFP_KERNEL); > >>>>>>> + if (!ebu_host) > >>>>>>> + return -ENOMEM; > >>>>>>> + > >>>>>>> + ebu_host->dev = dev; > >>>>>>> + nand_controller_init(&ebu_host->controller); > >>>>>>> + > >>>>>>> + res = platform_get_resource_byname(pdev, IORESOURCE_MEM, "ebunand"); > >>>>>>> + ebu_host->ebu_addr = devm_ioremap_resource(&pdev->dev, res); > >>>>>>> + if (IS_ERR(ebu_host->ebu_addr)) > >>>>>>> + return PTR_ERR(ebu_host->ebu_addr); > >>>>>>> + > >>>>>>> + res = platform_get_resource_byname(pdev, IORESOURCE_MEM, "hsnand"); > >>>>>>> + ebu_host->nand_addr = devm_ioremap_resource(&pdev->dev, res); > >>>>>>> + if (IS_ERR(ebu_host->nand_addr)) > >>>>>>> + return PTR_ERR(ebu_host->nand_addr); > >>>>>>> + > >>>>>>> + ret = device_property_read_u32(dev, "nand,cs", &cs); > >>>>>> > >>>>>> CS ids should be encoded in the reg property (see [1]). > >>>>> > >>>>> Is it your choice to only support a single CS or is it actually a > >>>>> controller limitation? > >>>> > >>>> Yes , its controller limitation to support only one CS > >>> > >>> I'm pretty sure that's not true, otherwise you wouldn't have to select > >>> the CS you want to use :P. > >> > >> At a time it supports only one chip select. > > > > Yes, like 99% of the NAND controllers, but that doesn't mean you can't > > support multi-CS chips. All you have to do is attach an array of > > ebu_nand_cs to your ebu_nand_chip (as done in the atmel driver I > > pointed to). nand_operation.cs tells you which CS (index in your > > ebu_nand_cs array) a specific operation is targeting, and you can pick > > the right MMIO range/reg value based on that. > > Agreed, sure I will add that and update next series of patches . There are also many other places where you assume blindly that there is only one CS. You can check the Atmel NAND controller driver as Boris said and we will probably propose more little changes to be more generic. Thanks, Miquèl