Received: by 2002:a25:ab43:0:0:0:0:0 with SMTP id u61csp5386737ybi; Tue, 4 Jun 2019 06:02:36 -0700 (PDT) X-Google-Smtp-Source: APXvYqw+2ud/9/c7rt05ABBkDwoG/7oo3yNznU3Ikng2dOhbIulfUdMYusuT4abyWYF/MaqzGoTr X-Received: by 2002:a17:90a:2201:: with SMTP id c1mr36753766pje.10.1559653356084; Tue, 04 Jun 2019 06:02:36 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1559653356; cv=none; d=google.com; s=arc-20160816; b=nmLO9ZIPeJtQXEX4Hy7P+JOwjNWIUI56TNgXXgF0QjBNgCb4g4NKf/4Yln6d/uP/5K Up2mrvp5+vRJlZOPK0De+bSeCys8QL/XgxL6itU/C4RZJyRkNT1g6dyTDJ+jP1Akxvj1 X/6LEgfzGAR00XNot1KeNfAjy274GPkR12SEY5QpEd/S6nkRiFxu28Q/yAYPiUSiRTQj Tcp/ZrXDOa7yB+VHpF3iH2WhPDbrGJM+nMWyYxhoqwunU39BRynquPvOr9N7os0VSiVe dQZbeh3hLoRyhoZVyP+++4AykiGiW4GTSJyYFNxyIpiRpl9ib9efpqNJ2itncipkIHK0 u32w== 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=kT6Qr0rx2v5W5080i/1OxFTslJEYWZUBCH1QuYCCEFE=; b=lf7ZIHq2cnhUKgOhOokBOxHUCLLEUtsCaxjD6Ew66H5MOeOyetZLe4W8IYOtAwl0l/ TkQasblc25Rxz8TAOgfAyvU08sPmZQtHL7SqJyxhp0L8OWC/nI6YZrgZ/Q1iwBLkfx04 p5eQqADipFkvozvtPbStrdEu9hnjaw/W35DWljt9vqToPdGHLa6PX57xgAwU5Dkupltu ZjK1EBGFxSK3cUsljJwHuma45iJkanpL7fuFv3k/YrdHoM3RyhxWI6RYt96YeJXdWMaP CsNt25Irl64gHPlFj2elIrBGLXeBD+GFTymfKMOQs4KMy4d+xwxNvkCCaSa95Hx4nkir m+xg== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=collabora.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id m4si574636pjk.66.2019.06.04.06.02.16; Tue, 04 Jun 2019 06:02:36 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=collabora.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727129AbfFDNAy (ORCPT + 99 others); Tue, 4 Jun 2019 09:00:54 -0400 Received: from bhuna.collabora.co.uk ([46.235.227.227]:42050 "EHLO bhuna.collabora.co.uk" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727033AbfFDNAy (ORCPT ); Tue, 4 Jun 2019 09:00:54 -0400 Received: from localhost (unknown [IPv6:2a01:e0a:2c:6930:5cf4:84a1:2763:fe0d]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) (Authenticated sender: bbrezillon) by bhuna.collabora.co.uk (Postfix) with ESMTPSA id 68F96281ED8; Tue, 4 Jun 2019 14:00:51 +0100 (BST) Date: Tue, 4 Jun 2019 15:00:47 +0200 From: Boris Brezillon To: "Shivamurthy Shastri (sshivamurthy)" Cc: Lucas Stach , Vignesh Raghavendra , Boris Brezillon , Marcel Ziswiler , Richard Weinberger , Yixun Lan , Chuanhong Guo , Stefan Agner , "linux-kernel@vger.kernel.org" , Paul Cercueil , Marek Vasut , "linux-mtd@lists.infradead.org" , Frieder Schrempf , Miquel Raynal , Anders Roxell , Brian Norris , David Woodhouse , "Bean Huo \(beanhuo\)" Subject: Re: [EXT] Re: [PATCH v3 04/12] mtd: rawnand: introduce struct onfi_helper Message-ID: <20190604150047.063395ab@collabora.com> In-Reply-To: References: <20190603150537.3ca5ca8a@collabora.com> Organization: Collabora X-Mailer: Claws Mail 3.17.3 (GTK+ 2.24.32; x86_64-redhat-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, 4 Jun 2019 12:02:28 +0000 "Shivamurthy Shastri (sshivamurthy)" wrote: > Hi Boris, > > > > Create onfi_helper object. This is base to turn ONFI code to generic. > > > > > > Signed-off-by: Shivamurthy Shastri > > > --- > > > include/linux/mtd/nand.h | 21 +++++++++++++++++++++ > > > 1 file changed, 21 insertions(+) > > > > > > diff --git a/include/linux/mtd/nand.h b/include/linux/mtd/nand.h > > > index 3cdf06cae8b6..645dde4c5797 100644 > > > --- a/include/linux/mtd/nand.h > > > +++ b/include/linux/mtd/nand.h > > > @@ -11,6 +11,7 @@ > > > #define __LINUX_MTD_NAND_H > > > > > > #include > > > +#include > > > > > > /** > > > * struct nand_memory_organization - Memory organization structure > > > @@ -157,6 +158,24 @@ struct nand_ops { > > > bool (*isbad)(struct nand_device *nand, const struct nand_pos > > *pos); > > > }; > > > > > > +/** > > > + * struct onfi_helper - ONFI helper functions that should be implemented > > by > > > + * specialized layers (raw NAND, SPI NAND, etc.) > > > + * @page: Page number for ONFI parameter table > > > + * @check_revision: Check ONFI revision number > > > + * @parameter_page_read: Function to read parameter pages > > > + * @init_intf_data: Initialize interface specific data or fixups > > > + */ > > > +struct onfi_helper { > > > + u8 page; > > > + int (*check_revision)(struct nand_device *base, > > > + struct nand_onfi_params *p, int *onfi_version); > > > + int (*parameter_page_read)(struct nand_device *base, u8 page, > > > + void *buf, unsigned int len); > > > + int (*init_intf_data)(struct nand_device *base, > > > + struct nand_onfi_params *p); > > > +}; > > > + > > > /** > > > * struct nand_device - NAND device > > > * @mtd: MTD instance attached to the NAND device > > > @@ -165,6 +184,7 @@ struct nand_ops { > > > * @rowconv: position to row address converter > > > * @bbt: bad block table info > > > * @ops: NAND operations attached to the NAND device > > > + * @helper: Helper functions to detect and initialize ONFI NAND > > > * > > > * Generic NAND object. Specialized NAND layers (raw NAND, SPI NAND, > > OneNAND) > > > * should declare their own NAND object embedding a nand_device struct > > (that's > > > @@ -183,6 +203,7 @@ struct nand_device { > > > struct nand_row_converter rowconv; > > > struct nand_bbt bbt; > > > const struct nand_ops *ops; > > > + struct onfi_helper helper; > > > > Sorry, but I don't think that's the right solution. When I said we > > should have ONFI code shared I was thinking about the code that parses > > the ONFI struct/data to extract nand_memory_organization bits or other > > generic info, not something that would abstract how to retrieve the > > ONFI param page. Clearly, the generic NAND layer is not supposed to > > handle such protocol/low-level details. > > > > In that case, I am thinking to design as follows, which splits into generic independent code. > Let me know, if you have any concerns or inputs. > > I will parsing code from nand_onfi_detect function and move it to mtd/nand/onfi.c. > Also, I will move functions like sanitize_string, nand_bit_wise_majority, onfi_crc16, and > any other generic info to mtd/nand/onfi.c. Sounds good.