Received: by 2002:ac0:a5a7:0:0:0:0:0 with SMTP id m36-v6csp462602imm; Tue, 31 Jul 2018 23:02:30 -0700 (PDT) X-Google-Smtp-Source: AAOMgpf8G57S02joewwE2MxOm9knAEpjoKrn95WYXSgMsOUPEl+oYnEmwCJaJ0Ux//ACqxsgVgP/ X-Received: by 2002:a63:4c56:: with SMTP id m22-v6mr22771792pgl.299.1533103350203; Tue, 31 Jul 2018 23:02:30 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1533103350; cv=none; d=google.com; s=arc-20160816; b=gvio2lKpnI5Np28cz1a9Wwu3QhjLeykQSJ1e1RLhTZ4mC34sIbYizKL50nzemqCFr0 v7RBWD8nbmgS8G9yiu0Dowq5Bf3JnOurMn5WPlHr2RYUPvKauLXnyIhvB5rkBM3Zt15i Ge3+B7PqScDlJ3S9OvQht3Mw7mIeEYDPxSIpYfVtaZjjKd9vQMby2jF/4HBURKAN/tYF Xm8U7Wqn6HtUkFque7JEDHsff6G75N2nG9jb0ccLVqEdOBOt0hdmh4b4h554ShbgDHNE 4V+/KCQgZkkV6vrWFLQRF3c4D7Tsk8AlJwihjIIiqik4HEnxaegJEHcnGlxQV/mh7J+T W/FA== 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=Zi0GGsU8GFxeEVwKjuhiuPYZlAeC1T3+pISyqRBRK0U=; b=esqKxjC6Dt1T2/0JJt546PG67YRha/4ej8YORrsx302ohBlI714iGZUYS0airG67fn LLpxuB8BHKYW3CeE4I6gL36q2TZhPDQ81t3VPU+GWUtKFyLdOXHaB89my5a2q/nFU9Yr xy+FnZDBO9SlRebiZVGolBd0eBXBm+p9l8uhoHgBed4qAox6I90i2Nf+dRuE+bWnwWr+ wAqaismYFtyXeMQTjYJOkwH178yIf6PZmhM6qu4WWiLbMGaCHTikGL81W/IlwyJYNKVr xR0Sjo9SQR+0ukZJZofv2qgPxtRXB1H5+32Eu31yP/ODL2vxeCnFvC3F9K7NDqIvUsv4 nY5w== 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 r28-v6si15461051pfb.65.2018.07.31.23.02.15; Tue, 31 Jul 2018 23:02:30 -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 S1733287AbeHAHpQ (ORCPT + 99 others); Wed, 1 Aug 2018 03:45:16 -0400 Received: from mail.bootlin.com ([62.4.15.54]:58550 "EHLO mail.bootlin.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727829AbeHAHpQ (ORCPT ); Wed, 1 Aug 2018 03:45:16 -0400 Received: by mail.bootlin.com (Postfix, from userid 110) id 6AFCB207AB; Wed, 1 Aug 2018 08:01:18 +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 (91-160-177-164.subs.proxad.net [91.160.177.164]) by mail.bootlin.com (Postfix) with ESMTPSA id 2E00F20799; Wed, 1 Aug 2018 08:01:18 +0200 (CEST) Date: Wed, 1 Aug 2018 08:01:17 +0200 From: Boris Brezillon To: Jheng-Jhong Wu Cc: Greg Kroah-Hartman , Masahiro Yamada , Arun Nagendran , Miquel Raynal , Palle Christensen , devel@driverdev.osuosl.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH] staging:mt29f_spinand: MT29F2G failing as only 16-bit arguments and variables used for addressing. Message-ID: <20180801080117.5386e9f1@bbrezillon> In-Reply-To: <1533093861-9761-1-git-send-email-goodwater.wu@gmail.com> References: <1533093861-9761-1-git-send-email-goodwater.wu@gmail.com> 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 Hi Jheng-Jhong, On Wed, 1 Aug 2018 11:24:19 +0800 Jheng-Jhong Wu wrote: > For NAND flash chips with more than 1Gbit (e.g. MT29F2G) more than 16 bits > are necessary to address the correct page. The driver sets the address for > more than 16 bits, but it uses 16-bit arguments and variables (these are > page_id, block_id, row) to do address operations. Obviously, these > arguments and variables cannot deal with more than 16-bit address. I plan to remove this driver soon (after 4.19-rc1 is out). It's now been replaced by the SPI framework [1]. Can you check if your NAND SPI NAND is supported, if it's not add support for it, and if you find a bug report/fix it. Thanks, Boris [1]https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/tree/drivers/mtd/nand/spi?h=next-20180731 > > Signed-off-by: Jheng-Jhong Wu > --- > drivers/staging/mt29f_spinand/mt29f_spinand.c | 22 +++++++++++----------- > 1 file changed, 11 insertions(+), 11 deletions(-) > > diff --git a/drivers/staging/mt29f_spinand/mt29f_spinand.c b/drivers/staging/mt29f_spinand/mt29f_spinand.c > index 4484784..a0f4cbcb 100644 > --- a/drivers/staging/mt29f_spinand/mt29f_spinand.c > +++ b/drivers/staging/mt29f_spinand/mt29f_spinand.c > @@ -308,10 +308,10 @@ static int spinand_write_enable(struct spi_device *spi_nand) > return spinand_cmd(spi_nand, &cmd); > } > > -static int spinand_read_page_to_cache(struct spi_device *spi_nand, u16 page_id) > +static int spinand_read_page_to_cache(struct spi_device *spi_nand, u32 page_id) > { > struct spinand_cmd cmd = {0}; > - u16 row; > + u32 row; > > row = page_id; > cmd.cmd = CMD_READ; > @@ -331,7 +331,7 @@ static int spinand_read_page_to_cache(struct spi_device *spi_nand, u16 page_id) > * locations. > * No tRd delay. > */ > -static int spinand_read_from_cache(struct spi_device *spi_nand, u16 page_id, > +static int spinand_read_from_cache(struct spi_device *spi_nand, u32 page_id, > u16 byte_id, u16 len, u8 *rbuf) > { > struct spinand_cmd cmd = {0}; > @@ -362,7 +362,7 @@ static int spinand_read_from_cache(struct spi_device *spi_nand, u16 page_id, > * The read includes two commands to the Nand - 0x13 and 0x03 commands > * Poll to read status to wait for tRD time. > */ > -static int spinand_read_page(struct spi_device *spi_nand, u16 page_id, > +static int spinand_read_page(struct spi_device *spi_nand, u32 page_id, > u16 offset, u16 len, u8 *rbuf) > { > int ret; > @@ -430,7 +430,7 @@ static int spinand_read_page(struct spi_device *spi_nand, u16 page_id, > * Since it is writing the data to cache, there is no tPROG time. > */ > static int spinand_program_data_to_cache(struct spi_device *spi_nand, > - u16 page_id, u16 byte_id, > + u32 page_id, u16 byte_id, > u16 len, u8 *wbuf) > { > struct spinand_cmd cmd = {0}; > @@ -457,10 +457,10 @@ static int spinand_program_data_to_cache(struct spi_device *spi_nand, > * the Nand array. > * Need to wait for tPROG time to finish the transaction. > */ > -static int spinand_program_execute(struct spi_device *spi_nand, u16 page_id) > +static int spinand_program_execute(struct spi_device *spi_nand, u32 page_id) > { > struct spinand_cmd cmd = {0}; > - u16 row; > + u32 row; > > row = page_id; > cmd.cmd = CMD_PROG_PAGE_EXC; > @@ -486,7 +486,7 @@ static int spinand_program_execute(struct spi_device *spi_nand, u16 page_id) > * Poll to wait for the tPROG time to finish the transaction. > */ > static int spinand_program_page(struct spi_device *spi_nand, > - u16 page_id, u16 offset, u16 len, u8 *buf) > + u32 page_id, u16 offset, u16 len, u8 *buf) > { > int retval; > u8 status = 0; > @@ -573,10 +573,10 @@ static int spinand_program_page(struct spi_device *spi_nand, > * one block--64 pages > * Need to wait for tERS. > */ > -static int spinand_erase_block_erase(struct spi_device *spi_nand, u16 block_id) > +static int spinand_erase_block_erase(struct spi_device *spi_nand, u32 block_id) > { > struct spinand_cmd cmd = {0}; > - u16 row; > + u32 row; > > row = block_id; > cmd.cmd = CMD_ERASE_BLK; > @@ -599,7 +599,7 @@ static int spinand_erase_block_erase(struct spi_device *spi_nand, u16 block_id) > * and then send the 0xd8 erase command > * Poll to wait for the tERS time to complete the tranaction. > */ > -static int spinand_erase_block(struct spi_device *spi_nand, u16 block_id) > +static int spinand_erase_block(struct spi_device *spi_nand, u32 block_id) > { > int retval; > u8 status = 0;