Received: by 2002:a05:6a10:5bc5:0:0:0:0 with SMTP id os5csp2155506pxb; Mon, 11 Oct 2021 23:57:15 -0700 (PDT) X-Google-Smtp-Source: ABdhPJwkb9lupIDAj/LRsW8gi8v2xaJthmoQnc/2qDC+wKDWssC7Hgqy6+4AF1qfC3JCmeQpjB0W X-Received: by 2002:a05:6402:4311:: with SMTP id m17mr17960711edc.368.1634021835156; Mon, 11 Oct 2021 23:57:15 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1634021835; cv=none; d=google.com; s=arc-20160816; b=NWIld9VsCfXwoomLNmBFBmUJ0rjNNs6XPhO67tUpqbcHvU0plCE9dOYJG9PIVBkdbJ E+gCoUFk/NjOVbfxQ0vCZ85AY4RZbq+7bzME7Gifimk5OsrpQtMRxnG8zZ2rup3AFyk9 mK1wj9XE3vidl8+MD+Skw1xnG6x1aHmt3/vO//yNGI0nhEdMLU4X6Ge2VCEJ2MuDtn/e K5Y17NcDJUTZHW2sJZh6UfGGXFnoCJYZmiwxn/yleupTRG+IxozLf/tVslPmnYzbBXP9 cr2YuWc2nNQwBNx21Zi6p5e61Yk5WbfGi8nsgvwU71kQX9mQLsDvwtyVjG9AkmQt4ya2 pxIQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:mime-version :organization:references:in-reply-to:message-id:subject:cc:to:from :date; bh=qdJtIpAwjrFvq8+fqbglYUgONCSPHdJ3UY9CSINO714=; b=LdEzU7h77j/FId7sideeVMSoav1HlFQjyUTSHmJy4vLp30KSjI/+6Z8u20wg8Dxz6A TlPBqokE+Siu+RmG1Y1PLn6a99NVO4xWFXDkzx0n3Ids7dIHU+mfK0frebGLujjC8KCV Z0RsBK3w+moQKm3IrygYI1ThCA/JNUVGhaE55iEfcg/1jzdmeh9SdcLjlAONCRpgu0WU jK7iwXTvr67QKN21TaEyYzNniHndXhXN3/5f/SDw2hPhmQUPU2yhfBpGy7jwn8nZtaTk 7+QivqrjAyZZRoAk43BAoV+KeYpe1jaROngrKtmHkplZxtssuutrD6qSDOsS3m16u5b2 V+Og== 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; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=collabora.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id 12si15081292ejk.308.2021.10.11.23.56.51; Mon, 11 Oct 2021 23:57:15 -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; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=collabora.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S233900AbhJLG4s (ORCPT + 99 others); Tue, 12 Oct 2021 02:56:48 -0400 Received: from bhuna.collabora.co.uk ([46.235.227.227]:57832 "EHLO bhuna.collabora.co.uk" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S233414AbhJLG4l (ORCPT ); Tue, 12 Oct 2021 02:56:41 -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 E611E1F410A6; Tue, 12 Oct 2021 07:54:38 +0100 (BST) Date: Tue, 12 Oct 2021 08:54:35 +0200 From: Boris Brezillon To: Apurva Nandan Cc: Miquel Raynal , Richard Weinberger , Vignesh Raghavendra , Mark Brown , Patrice Chotard , Christophe Kerello , , , , Subject: Re: [PATCH v2 05/14] mtd: spinand: Add adjust_op() in manufacturer_ops to modify the ops for manufacturer specific changes Message-ID: <20211012085435.1aedfb7f@collabora.com> In-Reply-To: <20211011204619.81893-6-a-nandan@ti.com> References: <20211011204619.81893-1-a-nandan@ti.com> <20211011204619.81893-6-a-nandan@ti.com> Organization: Collabora X-Mailer: Claws Mail 3.18.0 (GTK+ 2.24.33; x86_64-redhat-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, 12 Oct 2021 02:16:10 +0530 Apurva Nandan wrote: > Manufacturers might use a variation of standard SPI NAND flash > instructions, e.g. Winbond W35N01JW changes the dummy cycle length for > read register commands when in Octal DTR mode. > > Add new function in manufacturer_ops: adjust_op(), which can be called > to correct the spi_mem op for any alteration in the instruction made by > the manufacturers. And hence, this function can also be used for > incorporating variations of SPI instructions in Octal DTR mode. Okay, so now we have reg accesses differing between vendors in DTR. Looks like we should have an OP-table for non-IO commands too (similar to the op_variants mechanism we have for IO commands), at least when operating in DTR. The reg access path would just end up doing: struct spi_mem_op op = spinand->templates[spinand->protocol][cmd]; This way you get rid of all this live-patching/vendor-specific adjustment (which is likely to get more and more complex since flash vendors have a tendency of diverging from the common behavior), and everything gets initialized at probe time. > > Datasheet: https://www.winbond.com/export/sites/winbond/datasheet/W35N01JW_Datasheet_Brief.pdf > > Signed-off-by: Apurva Nandan > --- > drivers/mtd/nand/spi/core.c | 3 +++ > include/linux/mtd/spinand.h | 4 ++++ > 2 files changed, 7 insertions(+) > > diff --git a/drivers/mtd/nand/spi/core.c b/drivers/mtd/nand/spi/core.c > index 4da794ae728d..8e6cf7941a0f 100644 > --- a/drivers/mtd/nand/spi/core.c > +++ b/drivers/mtd/nand/spi/core.c > @@ -61,6 +61,9 @@ static void spinand_patch_op(const struct spinand_device *spinand, > op->data.buswidth = op_buswidth; > op->data.dtr = op_is_dtr; > } > + > + if (spinand->manufacturer->ops->adjust_op) > + spinand->manufacturer->ops->adjust_op(op, spinand->reg_proto); > } > > static void spinand_patch_reg_op(const struct spinand_device *spinand, > diff --git a/include/linux/mtd/spinand.h b/include/linux/mtd/spinand.h > index f6093cd98d7b..ebb19b2cec84 100644 > --- a/include/linux/mtd/spinand.h > +++ b/include/linux/mtd/spinand.h > @@ -257,6 +257,8 @@ struct spinand_devid { > /** > * struct manufacurer_ops - SPI NAND manufacturer specific operations > * @init: initialize a SPI NAND device > + * @adjust_op: modify the ops for any variation in their cmd, address, dummy or > + * data phase by the manufacturer > * @cleanup: cleanup a SPI NAND device > * > * Each SPI NAND manufacturer driver should implement this interface so that > @@ -264,6 +266,8 @@ struct spinand_devid { > */ > struct spinand_manufacturer_ops { > int (*init)(struct spinand_device *spinand); > + void (*adjust_op)(struct spi_mem_op *op, > + const enum spinand_proto reg_proto); > void (*cleanup)(struct spinand_device *spinand); > }; >