Received: by 2002:ac0:a582:0:0:0:0:0 with SMTP id m2-v6csp2534568imm; Wed, 3 Oct 2018 05:31:34 -0700 (PDT) X-Google-Smtp-Source: ACcGV6286q1Gt4t2vjLgXD9xN6fHhiPgWvHlNq6GMShWVoYrQY+IeGeg7aBHeDwAhzpP9/ABZING X-Received: by 2002:a17:902:28a4:: with SMTP id f33-v6mr1399639plb.297.1538569894385; Wed, 03 Oct 2018 05:31:34 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1538569894; cv=none; d=google.com; s=arc-20160816; b=K8r/M4uV8vHd78fDITjs0KLQ3aJ1dAUno+Dk+5PCjMZgixIMtCfPzT+dlfnVPaNTZ6 7pYHL5riIKwPKqWZD1UTFGRBkAndzGjgvBI2hKsHMXQAib95mObeSjukZvs2l6757u6Z fk0qypNefHfnU//1aoNk7nUeLvzyqlqs1dV1okMZ3DKWlRLPlJ4Q/gdX8CpR78qZZDLb 1u/ItzVgtNHoe2iivU/QhXeaQB3cwQfV0gAbbN/ae2Z9TmEB4HTudEMEIauXFS6Zn7+q bNZlxGKUdgkcvYYoznI9UL/KkZOowpj6RZl5Ul5oqKNdOS2KLEKvYYEsrlqR1/uIqoIE GLPA== 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; bh=Tr1Sz/SZWJlFJiCOzJU13DA3zag5CNGNZEI7/ABs0Xc=; b=S3FXphw8vYveriJw5V92mvzTObN4bGzk/dyLdqDyyuz+YrvToWS82BYJygTLn8xD0o v+3pdf9zZqEpfC9SG8NyYilHvEa5zZb4wdFYxJxFfJg0Sol+PURdNUjtaxgOyx44c8w8 qJYSaore8KJVD73437GcMi7ixfI7/veMn1gvf2rK6HXM8muudTMM1/2ymxKAE5W7c4V4 G7k0ORpjiiso5irByYCDigE6jYBsmra4bDxFFTyYAHbo3RffYIbAJtONRUh3YVxcOXIC 24/YeRUWVq68lCEsVBlpu276URSGb0Xusz6QwGnVWwprxomejSnpyFej5ceY1Y5YwV2C gKDw== 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 14-v6si1098901pgm.488.2018.10.03.05.31.19; Wed, 03 Oct 2018 05:31:34 -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 S1726967AbeJCTTS (ORCPT + 99 others); Wed, 3 Oct 2018 15:19:18 -0400 Received: from mail.bootlin.com ([62.4.15.54]:36122 "EHLO mail.bootlin.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726619AbeJCTTS (ORCPT ); Wed, 3 Oct 2018 15:19:18 -0400 Received: by mail.bootlin.com (Postfix, from userid 110) id 5390C207CC; Wed, 3 Oct 2018 14:31:04 +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, URIBL_BLOCKED shortcircuit=ham autolearn=disabled version=3.4.0 Received: from bbrezillon (AAubervilliers-681-1-24-95.w90-88.abo.wanadoo.fr [90.88.144.95]) by mail.bootlin.com (Postfix) with ESMTPSA id 08B28207C3; Wed, 3 Oct 2018 14:30:54 +0200 (CEST) Date: Wed, 3 Oct 2018 14:30:54 +0200 From: Boris Brezillon To: Janusz Krzysztofik Cc: Miquel Raynal , Richard Weinberger , David Woodhouse , Brian Norris , Marek Vasut , linux-mtd@lists.infradead.org, linux-kernel@vger.kernel.org Subject: Re: [RFC PATCH] mtd: rawnand: ams-delta: use ->exec_op() Message-ID: <20181003143054.597b3a9e@bbrezillon> In-Reply-To: <20181003120028.9257-1-jmkrzyszt@gmail.com> References: <20180719081508.5dafebde@bbrezillon> <20181003120028.9257-1-jmkrzyszt@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 Janusz, On Wed, 3 Oct 2018 14:00:28 +0200 Janusz Krzysztofik wrote: > Replace legacy callbacks with ->select_chip() and ->exec_op(). Thanks for working on that, that's really appreciated. > > Implementation of NAND_OP_WAITRDY_INSTR has been based on legacy > nand_wait_ready(), I don't remember what the ams-delta ->dev_ready()/->waitfunc() hooks are doing, but is shouldn't be too hard to replace them by an ams_delta_wait_ready() func. > otherwise that function would probabaly have to be ^ probably > reimplemented inside the driver. Hence, legacy callback ->dev_ready() > is still used. > > Use of IO_ADDR_R and IO_ADDR_W legacy structure members will be dropped > later, as soon as the driver is converted to use GPIO API for data I/O. In the meantime, can you move the iomem pointer to the ams_delta private struct so that this driver no longer uses the ->IO_ADDR_R/W fields? > > Suggested-by: Boris Brezillon > Signed-off-by: Janusz Krzysztofik > --- > Hi, > > I've not tested the change on hardware yet as I'm not sure if: > - handling of NCE limited to that inside ->select_chip() is > sufficient, I think it is. > - releasing ALE / CLE immediately after ams_delta_write_buf() is > correct. Well, you should probably consider waiting for instr->ctx.delay_ns nanoseconds after each instruction, but, if it was working before the conversion to ->exec_op(), it should work just fine now. Regards, Boris