Received: by 2002:a05:6a10:2726:0:0:0:0 with SMTP id ib38csp1011598pxb; Wed, 6 Apr 2022 06:41:07 -0700 (PDT) X-Google-Smtp-Source: ABdhPJzc9PO23QCGzwjVyIFE4L6aMrNHu96DNAFalqV3RClVJ0TavfXFowHzIgwjLQCpGoK9Ig2l X-Received: by 2002:a17:90a:5647:b0:1ca:85d5:2b0 with SMTP id d7-20020a17090a564700b001ca85d502b0mr9910808pji.121.1649252467012; Wed, 06 Apr 2022 06:41:07 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1649252467; cv=none; d=google.com; s=arc-20160816; b=eDR0q0+VCyn1/KZRfIIE7TtdbFMmc7m26OzS5T0KN1lMK3a3Hsnaw4n+q8GcAmZb3h B7Zmea5Wu+90nA+6eOcys4mZ7lrXGMZd06kEB3Td4tOr2YPZoA7fFNnfyrpj+elhaaQP pnlAyJzMa1AvCzuwl0He/hJATPaJmyxZByplkLt5acLuD197VpywcLwvgxtIXkyNvNBa tSv+HvzlZONLy/JDECn/FjpmuK5iQxsvIr1aA1DGshS64LI+kkzC4ktRD0YuWCLXoXsk PuS+Rwp3JhQld5t0Rc7vscCHSwjRDhfhKEECH6HGZUIU4/ICiBRLisaA6GMbJ/cFOJ7o gscQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:in-reply-to:content-disposition:mime-version :references:message-id:subject:cc:to:from:date:dkim-signature; bh=vtus/60BuspHiW8pCcteyIqj6DRsxR0bpl4QDFqiV0c=; b=kJn3+TuXUgzzy+BARNWVHmGVfdJp5CWVCUYKL7Jfh26rHbwsPI7Ondsbu7sSfg5pLH CG6A9NslYTl+K1wFwdQGBfKpqybC9dlfesjpc7/retXYjrX7XAFFvtVPJhyFsAi+/knP mwyQ2CqCJgKu4sIG4hJdaWHE1TRKw9cfqkdtdzGio4kxufkWIbbwlrIQo8bU/agZeYF4 Ru17Uec/HZAi7flMyyrMkPsNtFyoJPcbSIaMMBD3kVMWgsvjJ+I59TCB6dMhwcsF2Yk1 zZJtduyUGoaz4jnprdnekehJFuZwObY5cCpI6IOCuCoaIuh/fo8h9o8xD53kL5/dqj7G KzMQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@ti.com header.s=ti-com-17Q1 header.b=sRiFsish; spf=softfail (google.com: domain of transitioning linux-kernel-owner@vger.kernel.org does not designate 23.128.96.19 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=QUARANTINE sp=NONE dis=NONE) header.from=ti.com Return-Path: Received: from lindbergh.monkeyblade.net (lindbergh.monkeyblade.net. [23.128.96.19]) by mx.google.com with ESMTPS id t1-20020a1709027fc100b00153b2d16541si14711285plb.329.2022.04.06.06.41.04 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 06 Apr 2022 06:41:06 -0700 (PDT) Received-SPF: softfail (google.com: domain of transitioning linux-kernel-owner@vger.kernel.org does not designate 23.128.96.19 as permitted sender) client-ip=23.128.96.19; Authentication-Results: mx.google.com; dkim=pass header.i=@ti.com header.s=ti-com-17Q1 header.b=sRiFsish; spf=softfail (google.com: domain of transitioning linux-kernel-owner@vger.kernel.org does not designate 23.128.96.19 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=QUARANTINE sp=NONE dis=NONE) header.from=ti.com Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by lindbergh.monkeyblade.net (Postfix) with ESMTP id 4FAB44E3735; Wed, 6 Apr 2022 04:27:43 -0700 (PDT) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1846805AbiDFCIn (ORCPT + 99 others); Tue, 5 Apr 2022 22:08:43 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:39520 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1573658AbiDETja (ORCPT ); Tue, 5 Apr 2022 15:39:30 -0400 Received: from lelv0143.ext.ti.com (lelv0143.ext.ti.com [198.47.23.248]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id AAEFE245BD; Tue, 5 Apr 2022 12:37:31 -0700 (PDT) Received: from lelv0265.itg.ti.com ([10.180.67.224]) by lelv0143.ext.ti.com (8.15.2/8.15.2) with ESMTP id 235JbNjd108077; Tue, 5 Apr 2022 14:37:23 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ti.com; s=ti-com-17Q1; t=1649187443; bh=vtus/60BuspHiW8pCcteyIqj6DRsxR0bpl4QDFqiV0c=; h=Date:From:To:CC:Subject:References:In-Reply-To; b=sRiFsishexfnwFwes5Cfd4trvIkLpL9nmCMdGpyI5QBXLBpmzcWYA+IGYq0gWX93O FYRtMuHM8z5A56zJmmQL3+3teVDmNwyYOGsnKYmTFMvs4+scJ4aNEIF64sMpHk9/rQ e3A0MY/ChDfxOo/WTKf50KnOA6+/gvYM2dDbSX7Y= Received: from DLEE112.ent.ti.com (dlee112.ent.ti.com [157.170.170.23]) by lelv0265.itg.ti.com (8.15.2/8.15.2) with ESMTPS id 235JbMhJ003784 (version=TLSv1.2 cipher=AES256-GCM-SHA384 bits=256 verify=FAIL); Tue, 5 Apr 2022 14:37:22 -0500 Received: from DLEE103.ent.ti.com (157.170.170.33) by DLEE112.ent.ti.com (157.170.170.23) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.2308.14; Tue, 5 Apr 2022 14:37:22 -0500 Received: from fllv0040.itg.ti.com (10.64.41.20) by DLEE103.ent.ti.com (157.170.170.33) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.2308.14 via Frontend Transport; Tue, 5 Apr 2022 14:37:22 -0500 Received: from localhost (ileax41-snat.itg.ti.com [10.172.224.153]) by fllv0040.itg.ti.com (8.15.2/8.15.2) with ESMTP id 235JbLSc041064; Tue, 5 Apr 2022 14:37:22 -0500 Date: Wed, 6 Apr 2022 01:07:21 +0530 From: Pratyush Yadav To: Matthias Schiffer CC: Mark Brown , Tudor Ambarus , Vignesh Raghavendra , Ramuthevar Vadivel Murugan , , Subject: Re: [PATCH] spi: cadence-quadspi: fix protocol setup for non-1-1-X operations Message-ID: <20220405193721.5jf3umfn3dvv6fxd@ti.com> References: <20220331110819.133392-1-matthias.schiffer@ew.tq-group.com> <20220401100606.iz52jbrdcz6pd5sg@ti.com> <6b2bfa6614fbb9339b94a191ab933a2c25b8b4d7.camel@ew.tq-group.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Disposition: inline In-Reply-To: <6b2bfa6614fbb9339b94a191ab933a2c25b8b4d7.camel@ew.tq-group.com> X-EXCLAIMER-MD-CONFIG: e1e8a2fd-e40a-4ac6-ac9b-f7e9cc9ee180 X-Spam-Status: No, score=-2.0 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,RDNS_NONE,SPF_HELO_NONE,T_SCC_BODY_TEXT_LINE autolearn=no autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 01/04/22 12:20PM, Matthias Schiffer wrote: > On Fri, 2022-04-01 at 15:36 +0530, Pratyush Yadav wrote: > > Hi Matthias, > > > > On 31/03/22 01:08PM, Matthias Schiffer wrote: > > > cqspi_set_protocol() only set the data width, but ignored the > > > command > > > and address width (except for 8-8-8 DTR ops), leading to corruption > > > of > > > all transfers using 1-X-X or X-X-X ops. Fix by setting the other > > > two > > > widths as well. > > > > > > While we're at it, simplify the code a bit by replacing the > > > CQSPI_INST_TYPE_* constants with ilog2(). > > > > > > Tested on a TI AM64x with a Macronix MX25U51245G QSPI flash with 1- > > > 4-4 > > > read and write operations. > > > > > > Fixes: a314f6367787 ("mtd: spi-nor: Convert cadence-quadspi to use > > > spi-mem framework") > > > > I think a fixes tag is wrong here. The old driver did not support 1- > > X-X > > modes either. So you are not fixing anything, you are adding a new > > feature. I don't think we should backport this patch to stable. > > > Giving a precise fixes tag is a bit difficult. The referenced commit > made the driver (accidentally) accept commands like 1-4-4 without > handing them correctly, causing data corruption for flashs that support > these modes. The data corruption is fixed by my patch. Ah, you're right. I missed the fact that the original driver explicitly checked for 1-1-1, 1-1-4, and 1-1-8, and returned an error for the rest. So your patch does indeed fix a bug. > > As the change was unintended, one option would be to split this patch > into two parts: One fix patch that makes cqspi_set_protocol() -EINVAL > again for all commands that are not 1-1-X, and one feature patch that > adds actual support for these commands. > > My thought process was that making these commands work correctly can't > break anything that is not already broken in current stable kernels. > But if you prefer the minimal change, I can send a v2 that splits the > patch. Yes, but as I commented below, I would prefer you rework the driver to drop cqspi_set_protocol() entirely. For doing that the 2 patch approach would work best so we don't end up getting the new code backported to stable as well. > > Regards, > Matthias > > > > > > > > Signed-off-by: Matthias Schiffer > > > > > > --- > > > drivers/spi/spi-cadence-quadspi.c | 46 ++++++++------------------- > > > ---- > > > 1 file changed, 12 insertions(+), 34 deletions(-) > > > > > > diff --git a/drivers/spi/spi-cadence-quadspi.c b/drivers/spi/spi- > > > cadence-quadspi.c > > > index b0c9f62ccefb..616ada891974 100644 > > > --- a/drivers/spi/spi-cadence-quadspi.c > > > +++ b/drivers/spi/spi-cadence-quadspi.c > > > @@ -19,6 +19,7 @@ > > > #include > > > #include > > > #include > > > +#include > > > #include > > > #include > > > #include > > > @@ -102,12 +103,6 @@ struct cqspi_driver_platdata { > > > #define CQSPI_TIMEOUT_MS 500 > > > #define CQSPI_READ_TIMEOUT_MS 10 > > > > > > -/* Instruction type */ > > > -#define CQSPI_INST_TYPE_SINGLE 0 > > > -#define CQSPI_INST_TYPE_DUAL 1 > > > -#define CQSPI_INST_TYPE_QUAD 2 > > > -#define CQSPI_INST_TYPE_OCTAL 3 > > > - > > > #define CQSPI_DUMMY_CLKS_PER_BYTE 8 > > > #define CQSPI_DUMMY_BYTES_MAX 4 > > > #define CQSPI_DUMMY_CLKS_MAX 31 > > > @@ -376,10 +371,6 @@ static unsigned int cqspi_calc_dummy(const > > > struct spi_mem_op *op, bool dtr) > > > static int cqspi_set_protocol(struct cqspi_flash_pdata *f_pdata, > > > const struct spi_mem_op *op) > > > { > > > - f_pdata->inst_width = CQSPI_INST_TYPE_SINGLE; > > > - f_pdata->addr_width = CQSPI_INST_TYPE_SINGLE; > > > - f_pdata->data_width = CQSPI_INST_TYPE_SINGLE; > > > - > > > /* > > > * For an op to be DTR, cmd phase along with every other non- > > > empty > > > * phase should have dtr field set to 1. If an op phase has > > > zero > > > @@ -389,32 +380,23 @@ static int cqspi_set_protocol(struct > > > cqspi_flash_pdata *f_pdata, > > > (!op->addr.nbytes || op->addr.dtr) && > > > (!op->data.nbytes || op->data.dtr); > > > > > > - switch (op->data.buswidth) { > > > - case 0: > > > - break; > > > - case 1: > > > - f_pdata->data_width = CQSPI_INST_TYPE_SINGLE; > > > - break; > > > - case 2: > > > - f_pdata->data_width = CQSPI_INST_TYPE_DUAL; > > > - break; > > > - case 4: > > > - f_pdata->data_width = CQSPI_INST_TYPE_QUAD; > > > - break; > > > - case 8: > > > - f_pdata->data_width = CQSPI_INST_TYPE_OCTAL; > > > - break; > > > - default: > > > - return -EINVAL; > > > - } > > > + f_pdata->inst_width = 0; > > > + if (op->cmd.buswidth) > > > + f_pdata->inst_width = ilog2(op->cmd.buswidth); > > > + > > > + f_pdata->addr_width = 0; > > > + if (op->addr.buswidth) > > > + f_pdata->addr_width = ilog2(op->addr.buswidth); > > > + > > > + f_pdata->data_width = 0; > > > + if (op->data.buswidth) > > > + f_pdata->data_width = ilog2(op->data.buswidth); > > > > Honestly, I think we should get rid of cqspi_set_protocol() entirely. > > I > > see no need to store f_pdata->{instr,addr,data}_width since we > > recalculate those for each op execution anyway. So why not just use > > the > > spi_mem_op to get those values directly and be rid of all this mess? > > > > > > > > /* Right now we only support 8-8-8 DTR mode. */ > > > if (f_pdata->dtr) { > > > switch (op->cmd.buswidth) { > > > case 0: > > > - break; > > > case 8: > > > - f_pdata->inst_width = CQSPI_INST_TYPE_OCTAL; > > > break; > > > default: > > > return -EINVAL; > > > @@ -422,9 +404,7 @@ static int cqspi_set_protocol(struct > > > cqspi_flash_pdata *f_pdata, > > > > > > switch (op->addr.buswidth) { > > > case 0: > > > - break; > > > case 8: > > > - f_pdata->addr_width = CQSPI_INST_TYPE_OCTAL; > > > break; > > > default: > > > return -EINVAL; > > > @@ -432,9 +412,7 @@ static int cqspi_set_protocol(struct > > > cqspi_flash_pdata *f_pdata, > > > > > > switch (op->data.buswidth) { > > > case 0: > > > - break; > > > case 8: > > > - f_pdata->data_width = CQSPI_INST_TYPE_OCTAL; > > > break; > > > default: > > > return -EINVAL; > > > -- > > > 2.25.1 > > > > -- Regards, Pratyush Yadav Texas Instruments Inc.