Received: by 10.192.165.148 with SMTP id m20csp5562564imm; Wed, 9 May 2018 07:03:22 -0700 (PDT) X-Google-Smtp-Source: AB8JxZp0LunDI4IP7o9lE9adSE6jg5suiBEVGIKNctrkCPfsQoBE0OtL9ttXvv4vD1quD5/UMgBB X-Received: by 2002:a63:618b:: with SMTP id v133-v6mr35214972pgb.285.1525874602265; Wed, 09 May 2018 07:03:22 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1525874602; cv=none; d=google.com; s=arc-20160816; b=ct7m9tbS6RY44VDWZ+2FQYxezgJr4iPkTVBBQ9VzEvCqQsi6HA5bLXS2ZXe+TZ07ni jLghjB88y2Dyie7t+u52+gT3UgCPKJ1OMaCE7JRMEudJD8f2t/CRwCJA/AxGA0W6UsPe OpAIXuq9ZBBtNXiaY99+mu/fH1HSxHGtD8rr1uWICorhs3lBGMBYcQIJvUNpEa4pwMcr G/rGuS2x8CiLhtoPb8R2nxTbvzqDGkcDLSE/zJ8N8GJALYJU4LmRV3HfLUfDjvBR0GfQ nsfRyWrMEgbpOexh1GygE1oc4Y+MedDN6apwV5oQM5eFbUOgM4lS99j1X3CIX1lU3F/3 mRdQ== 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 :references:in-reply-to:message-id:subject:cc:to:from:date :arc-authentication-results; bh=I6i5x/hh90OPl3S0foOvkaBNOQcbmPaXSPS0kvdDNYk=; b=CcmNFV+/VYHDNETqxFOkZl4unykR7Emo+FnHGVh3w+1uWqduLJVHQJM8Xwbe2A88/9 RZFUYb6cGJzgiZmfsTabvfKSEPCafYz1lEAspCfKqsnqZ/Kemzc1aSiPEi8fFxTmaoc6 ufdYl30ICJq9oroS5OLRhNVD0MvHj85Ws8/SSj68C1nWvOU98U8bAHuAAKYcwXl3Ikx9 uYznW3lZt7Fy+lsm1qTIyAksi/qmRYE9Bg/0AT3zoRBO2gxh+tNB/dnUHn64v5Y9geFw /DIXNjfad63uc4RIjxBFJjhnwrINo0YikEVc9p4iFXIV7mL5Xqk3YCW1/+6DtHFYOW5b IlWg== 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 Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id c10-v6si17002534pgv.446.2018.05.09.07.03.07; Wed, 09 May 2018 07:03:22 -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 Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1756379AbeEIOCx (ORCPT + 99 others); Wed, 9 May 2018 10:02:53 -0400 Received: from mail.bootlin.com ([62.4.15.54]:59055 "EHLO mail.bootlin.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S934630AbeEIOCw (ORCPT ); Wed, 9 May 2018 10:02:52 -0400 Received: by mail.bootlin.com (Postfix, from userid 110) id 249FB20756; Wed, 9 May 2018 16:02:50 +0200 (CEST) X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on mail.bootlin.com X-Spam-Level: X-Spam-Status: No, score=-1.0 required=5.0 tests=ALL_TRUSTED,SHORTCIRCUIT shortcircuit=ham autolearn=disabled version=3.4.0 Received: from bbrezillon (LStLambert-657-1-97-87.w90-63.abo.wanadoo.fr [90.63.216.87]) by mail.bootlin.com (Postfix) with ESMTPSA id D10B6207DA; Wed, 9 May 2018 16:02:39 +0200 (CEST) Date: Wed, 9 May 2018 16:02:40 +0200 From: Boris Brezillon To: NeilBrown , Marek Vasut Cc: David Woodhouse , Brian Norris , Richard Weinberger , linux-mtd@lists.infradead.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH/RFC] mtd: spi-nor: honour max_message_size for spi-nor writes. Message-ID: <20180509160240.23ef11f2@bbrezillon> In-Reply-To: <87efj1kw9u.fsf@notabene.neil.brown.name> References: <87efj1kw9u.fsf@notabene.neil.brown.name> X-Mailer: Claws Mail 3.15.0-dirty (GTK+ 2.24.31; x86_64-pc-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 Fri, 27 Apr 2018 16:18:05 +1000 NeilBrown wrote: > Hi, > I've labeled this an RFC because I'm really not sure about removing the > error path from spi_nor_write() -- maybe that really matters. But on > my hardware, performing multiple small spi writes to the flash seems > to work. > > The spi driver is drivers/staging/mt7621-spi. Possibly this needs to > use DMA instead of a FIFO (assuming the hardware can) - or maybe > drivers/spi/spi-mt65xx.c can be made to work on this hardware, though > that is for an ARM SOC and mt7621 is a MIPS SOC. > > I note that openwrt has similar patches: > target/linux/generic/pending-4.14/450-mtd-spi-nor-allow-NOR-driver-to-write-fewer-bytes-th.patch > > They also change the spi driver to do a short write, rather > than change m25p80 to request a short write. > > Is there something horribly wrong with this? Marek, any opinion on this patch? > > Thanks, > NeilBrown > > -----------------------8<------------------------ > > m25p80 honours max_message_size and max_transfer_size > for reads, but not for writes. > I have a driver that has a max message size of 36 bytes > (command, address, 32 bytes data, all places in a FIFO > in the controller). > This requires m25p80_write() to honour the size limits. > For that to work, spi-nor needs to quietly accept partial > writes. > > With this, I can successfully re-flash my device. > > Signed-off-by: NeilBrown > --- > drivers/mtd/devices/m25p80.c | 3 ++- > drivers/mtd/spi-nor/spi-nor.c | 7 ------- > 2 files changed, 2 insertions(+), 8 deletions(-) > > diff --git a/drivers/mtd/devices/m25p80.c b/drivers/mtd/devices/m25p80.c > index a4e18f6aaa33..7ded13507604 100644 > --- a/drivers/mtd/devices/m25p80.c > +++ b/drivers/mtd/devices/m25p80.c > @@ -117,7 +117,8 @@ static ssize_t m25p80_write(struct spi_nor *nor, loff_t to, size_t len, > > t[data_idx].tx_buf = buf; > t[data_idx].tx_nbits = data_nbits; > - t[data_idx].len = len; > + t[data_idx].len = min3(len, spi_max_transfer_size(spi), > + spi_max_message_size(spi) - cmd_sz); > spi_message_add_tail(&t[data_idx], &m); > > ret = spi_sync(spi, &m); > diff --git a/drivers/mtd/spi-nor/spi-nor.c b/drivers/mtd/spi-nor/spi-nor.c > index 42ae9a1529bb..cfa15f2801ad 100644 > --- a/drivers/mtd/spi-nor/spi-nor.c > +++ b/drivers/mtd/spi-nor/spi-nor.c > @@ -1445,13 +1445,6 @@ static int spi_nor_write(struct mtd_info *mtd, loff_t to, size_t len, > goto write_err; > *retlen += written; > i += written; > - if (written != page_remain) { > - dev_err(nor->dev, > - "While writing %zu bytes written %zd bytes\n", > - page_remain, written); > - ret = -EIO; > - goto write_err; > - } > } > > write_err: