Received: by 2002:a05:6a10:1d13:0:0:0:0 with SMTP id pp19csp1530226pxb; Fri, 20 Aug 2021 07:40:21 -0700 (PDT) X-Google-Smtp-Source: ABdhPJzweud9Vqcqf8TocMOWxJ+HgupRottzR7wW0hXZRd4lC+CP5LyYyiN5iTjFOj96VOB/sEhE X-Received: by 2002:a92:ca89:: with SMTP id t9mr14401400ilo.178.1629470421355; Fri, 20 Aug 2021 07:40:21 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1629470421; cv=none; d=google.com; s=arc-20160816; b=hHD/dI+UoopFg0MuA8RAYmS9CgIKjkuz2JACl35NIVAt4jpqQPk2Emw7oS72tZkX0U LJRmkKG7FE1UB3u1tQEXdJZtwBsPxHIJEjwr1UYfY/Wzvri+zBmA6phxW7nj6837Agba DfNupdKjwwZXciHIBfsOymqLRh1SlwfISs27wy3+8I254C7S3B+yRb5mxChT94yyNT9u tCp1o8jWeRE81OsP7+d5zIJSBMdWFJlsstP9XNAO5msTo9MjYLM63QqzqgIFxpl5aNCD CMio19Q5EkXEDk9kincfNpczn9KCve6biFSMtiCNvKqQHp5X8M1T733tWs2lgchKpIn9 Mgsw== 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=o5qTWcIAQ0dNRic1gsY26BzrEQ8vIChc+iA9sqoPUws=; b=Atvu7+4zlCgiQncvRfMqkjRqJQW9V+5Mu300g0m6PI/EIz7zX5ys778NcvKNWV1s56 UAjdyCxsiNgf2oaDMdxifqTkDpU0tY+Es3yASTLf3J8ivHDdkBevlkkLaLu8N6ZCXbQ8 CZZqCA/VRciZBtNSzeJOkvKbin0ng4rTVkh+X67JQR6jCrAr1Zs3OIp/VyTvisf6PPrH GmlM+XfodtDK/uN3nJcpvjoTAXHyvcsXp8Bp60F+yU2aRi/hlZd46Sb/1PMkkiJmmoOn sv5ZiPclaSIfJixTg8sIwKgqrUa3fmmYBvvKswjWV3EJa95kHxMN92POFnl0xMMpa/f9 z7Qg== 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 a7si6683717ilr.103.2021.08.20.07.40.09; Fri, 20 Aug 2021 07:40:21 -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 S240881AbhHTOip convert rfc822-to-8bit (ORCPT + 99 others); Fri, 20 Aug 2021 10:38:45 -0400 Received: from relay1-d.mail.gandi.net ([217.70.183.193]:42421 "EHLO relay1-d.mail.gandi.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S231706AbhHTOio (ORCPT ); Fri, 20 Aug 2021 10:38:44 -0400 Received: (Authenticated sender: miquel.raynal@bootlin.com) by relay1-d.mail.gandi.net (Postfix) with ESMTPSA id DA099240004; Fri, 20 Aug 2021 14:38:03 +0000 (UTC) Date: Fri, 20 Aug 2021 16:38:02 +0200 From: Miquel Raynal To: Apurva Nandan Cc: Richard Weinberger , Vignesh Raghavendra , Mark Brown , Patrice Chotard , Boris Brezillon , , , , Pratyush Yadav Subject: Re: [PATCH 08/13] mtd: spinand: Reject 8D-8D-8D op_templates if octal_dtr_enale() is missing in manufacturer_op Message-ID: <20210820163802.529482dd@xps13> In-Reply-To: <11d173f2-2011-d029-e905-a10fdd0f2b85@ti.com> References: <20210713130538.646-1-a-nandan@ti.com> <20210713130538.646-9-a-nandan@ti.com> <20210806210146.3358a85b@xps13> <4d428465-59d7-6771-8344-c5090add2a06@ti.com> <20210820141413.6c519255@xps13> <11d173f2-2011-d029-e905-a10fdd0f2b85@ti.com> Organization: Bootlin X-Mailer: Claws Mail 3.17.7 (GTK+ 2.24.32; x86_64-pc-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8BIT Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi Apurva, Apurva Nandan wrote on Fri, 20 Aug 2021 19:24:34 +0530: > Hi Miquèl, > > On 20/08/21 5:44 pm, Miquel Raynal wrote: > > Hi Apurva, > > > > Apurva Nandan wrote on Fri, 20 Aug 2021 16:56:50 > > +0530: > > > >> On 07/08/21 12:31 am, Miquel Raynal wrote: > >>> Hi Apurva, > >>> > >>> Apurva Nandan wrote on Tue, 13 Jul 2021 13:05:33 > >>> +0000: > >>> >>>> The SPI NAND core doesn't know how to switch the flash to Octal DTR > >>>> mode (i.e. which operations to perform). If the manufacturer hasn't > >>>> implemented the octal_dtr_enable() manufacturer_op, the SPI NAND core > >>>> wouldn't be able to switch to 8D-8D-8D mode and will also not be able > >>>> to run in 1S-1S-1S mode due to already selected 8D-8D-8D read/write > >>>> cache op_templates. > >>>> > >>>> So, avoid choosing a Octal DTR SPI op_template for read_cache, > >>>> write_cache and update_cache operations, if the manufacturer_op > >>>> octal_dtr_enable() is missing. > >>> > >>> After looking at your previous commit I don't see why this patch would > >>> be needed. octal_dtr_enable() only updates the mode when it succeeds so > >>> I don't think this patch is really needed. > >>> >> > >> I added it to prevent any errors happening dues to a missing implementation of octal_dtr_enable() from manufacturer driver side. > >> So, if the manufacturers skips the octal_dtr_enable() implementation, we want the spinand core to run in 1s-1s-1s mode. > > > > I still don't get the point: you fail the probe if the octal bit is > > enabled but the manufacturer did not implement octal_dtr_enable(), so > > how could we have issues? Maybe I am overlooking something though, but > > this seemed completely redundant to my eyes so far. > > > > Okay, I feel this may be redundant. This is for the case when the manufacturer has added Octal DTR read/write/update cache variants but hasn't implemented the octal_dtr_enable() method. > > Without this patch, the probe would fail, if the manufacturer did not implement octal_dtr_enable(). But after using this patch, spinand can still use the chip in 1s-1s-1s mode in that case and just skip the Octal DTR op variants during the selection. And also the probe would succeed. Unless I am overlooking something with this series applied (with or without this patch) the possibilities are: - no octal bit -> continue as before - octal bit and vendor callback -> uses octal mode - octal bit and no vendor callback -> will return an error from spinand_init_octal_dtr_enable() which will fail the probe (patch 7) Anyway we have a choice: - Either we consider the tables describing chips as pure descriptions and we can support these chips in mode 1-1-1 (will require changes in your series as this is not what you support as far as I understand the code) - Or we consider these tables as "what is currently supported" and in this case we just fail if one adds the octal bit without any callback implementation. I think the latter is better for now. We can update this choice later if needed anyway. > > >> > >> Read/write/update op variant selection happens in select_op_variant(), much before octal_dtr_enable(). So just check if there is a definition of octal_dtr_enable in manufacturer ops and then only use 8D op variants. > >> > >> Removing this wouldn't break anything in the current implementation. > >> Do you think we should drop this? > >> > >>>> > >>>> Signed-off-by: Apurva Nandan > >>>> --- > >>>> drivers/mtd/nand/spi/core.c | 7 ++++++- > >>>> 1 file changed, 6 insertions(+), 1 deletion(-) > >>>> > >>>> diff --git a/drivers/mtd/nand/spi/core.c b/drivers/mtd/nand/spi/core.c > >>>> index 19d8affac058..8711e887b795 100644 > >>>> --- a/drivers/mtd/nand/spi/core.c > >>>> +++ b/drivers/mtd/nand/spi/core.c > >>>> @@ -1028,6 +1028,8 @@ static int spinand_manufacturer_match(struct spinand_device *spinand, > >>>> if (id[0] != manufacturer->id) > >>>> continue; > >>>> >> + spinand->manufacturer = manufacturer; > >>>> + > >>>> ret = spinand_match_and_init(spinand, > >>>> manufacturer->chips, > >>>> manufacturer->nchips, > >>>> @@ -1035,7 +1037,6 @@ static int spinand_manufacturer_match(struct spinand_device *spinand, > >>>> if (ret < 0) > >>>> continue; > >>>> >> - spinand->manufacturer = manufacturer; > >>>> return 0; > >>>> } > >>>> return -ENOTSUPP; > >>>> @@ -1097,6 +1098,10 @@ spinand_select_op_variant(struct spinand_device *spinand, > >>>> unsigned int nbytes; > >>>> int ret; > >>>> >> + if (spinand_op_is_octal_dtr(&op) && > >>>> + !spinand->manufacturer->ops->octal_dtr_enable) > >>>> + continue; > >>>> + > >>>> nbytes = nanddev_per_page_oobsize(nand) + > >>>> nanddev_page_size(nand); > >>>> > > Thanks, > >>> Miquèl > >>> > >>> ______________________________________________________ > >>> Linux MTD discussion mailing list > >>> http://lists.infradead.org/mailman/listinfo/linux-mtd/ > >>> >> > >> Thanks, > >> Apurva Nandan > > > > > > > > > > Thanks, > > Miquèl > > > > Thanks, > Apurva Nandan Thanks, Miquèl