Received: by 2002:ac0:a582:0:0:0:0:0 with SMTP id m2-v6csp2643766imm; Wed, 3 Oct 2018 07:06:59 -0700 (PDT) X-Google-Smtp-Source: ACcGV62cySlLrSZjlwnKluO3eg1tGA3zAyPAEobKNrWKR/1hBIy1jjBF96q4fpY/H+vkxQse+EM4 X-Received: by 2002:a17:902:d90e:: with SMTP id c14-v6mr1843570plz.61.1538575619894; Wed, 03 Oct 2018 07:06:59 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1538575619; cv=none; d=google.com; s=arc-20160816; b=fy2TEh+JivnP8UexD7fFp4X9RjZ4VZXRa3YoMO2c+6QBHbq2k6W5fkTOuUX4JPnzcu WRmIUfzhhDgu36/GtMhSk9Scm+ZKCQrrNpjPRf76xmOs+bhWymUHlCj4EGG9JDNj1a1a 0EPTAlWgu5hXinPQdODRTtmKVyCa2EgYT2RjR46OWNGrN3x+UXr2ZPihLg4el572kG/X dLhM44U6aCbQJA+R+YqQMmcs9QDRIC5BeRK65GwEAVaLTCLVkLpxmYlLCeADEYb8joM3 9rgNpdrE6UqitCriI7u3fpP4ejcEMh4aN3gI1wX7xCcSTYLu7BjR3MOHirM3MIljRqD0 /leA== 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=MbwoCGhc2WW7Aofb9FInudsAb6FjR7IZeh3zQPMh5jI=; b=gQIwTdY9ukeQ8o6LPAB9iQCcq+8WcBNndj6UXfd/y3WUnzY/iLb1Gtnq8L29BM/sof 1h4D+TgHgL4gpf3ax9nG7KMmUHUqcBGqzWaCSD/aroR8ArZn7ELNWlj90D/zBghuWaaa k6PrXic5lYjsOHnI49HRR6b5Od8CaWnLyLMefNH9yWoaBpdurIK0zAvRrH1mvcsmbJBd qIhaGk/YVWqzxaasiq6QZY0GuniK20dYuejKRG9+5AUBJnPspCjZcTxSypUqGntlTMna lX26sYxT0vehSHvThch1u/N9sBIPThjWyGqpBFC3h9o4lDdZr6KRWiV+YBpq0z2Iv92V TEUw== 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 v20-v6si1603067pgl.249.2018.10.03.07.06.43; Wed, 03 Oct 2018 07:06:59 -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 S1726871AbeJCUzL (ORCPT + 99 others); Wed, 3 Oct 2018 16:55:11 -0400 Received: from mail.bootlin.com ([62.4.15.54]:39413 "EHLO mail.bootlin.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726694AbeJCUzK (ORCPT ); Wed, 3 Oct 2018 16:55:10 -0400 Received: by mail.bootlin.com (Postfix, from userid 110) id 00AAA2072B; Wed, 3 Oct 2018 16:06:35 +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 (AAubervilliers-681-1-24-95.w90-88.abo.wanadoo.fr [90.88.144.95]) by mail.bootlin.com (Postfix) with ESMTPSA id B8414206A2; Wed, 3 Oct 2018 16:06:35 +0200 (CEST) Date: Wed, 3 Oct 2018 16:06:34 +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: <20181003160634.147dd95c@bbrezillon> In-Reply-To: <4278198.vlhjLe5TOR@z50> References: <20180719081508.5dafebde@bbrezillon> <20181003120028.9257-1-jmkrzyszt@gmail.com> <20181003143054.597b3a9e@bbrezillon> <4278198.vlhjLe5TOR@z50> 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 Wed, 03 Oct 2018 15:55:25 +0200 Janusz Krzysztofik wrote: > > > > > > 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. > > Default nand_wait() is used as ->waitfunc(), and ->dev_ready() returns R/B > GPIO pin status. Okay. Then it might make sense to provide a generic helper to poll a gpio. void nand_gpio_waitrdy(struct nand_chip *chip, struct gpio_desc *gpiod) { ... } > > > > otherwise that function would probabaly have to be > > > > ^ probably > > Do you think other drivers which now provide ->dev_ready() won't require > reimplementation of nand_wait_ready()? It depends. I mean, most controllers support native R/B sensing, and in case they do actually require you to poll the RB pin status, duplicating the wait_ready() logic shouldn't be a problem. On the other hand, I really want to get rid of ->dev_ready().