Received: by 2002:ac0:a582:0:0:0:0:0 with SMTP id m2-v6csp2843044imm; Wed, 3 Oct 2018 09:59:40 -0700 (PDT) X-Google-Smtp-Source: ACcGV63OhmYuxZrtrhnaWSptAbe6fr643KWCUC1wWaIIsuNEqZRUfn2RGQG+XRm5hTgdoJfI23Tm X-Received: by 2002:a63:b518:: with SMTP id y24-v6mr2183482pge.436.1538585980925; Wed, 03 Oct 2018 09:59:40 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1538585980; cv=none; d=google.com; s=arc-20160816; b=bpWTKeXeo+hF8A3w2AhkA7nz9YliablHvQ5R4uJNHSUeFcw3m6vUoLm16plaau0kMk bMC3kojdGM7txxDADhlJgse+93PDox2Lei1b6NNjNT8joYMd6xHddqWdXYeIYMYnfTkL /tzhtDcx9t5ZmEon8TXm21J5dOy1GB42378zluP/mHGHErT/we31Yy02/EEYPmIEB4XL lvYZISsTSWMAl43r9q0ZnzJpMBLvHi3tzNy25t2gJpUy0E6s+vfb1eD0Uw92My6vPPZR kW3mdVW1JemIMmTgI7cV4qrZl7OuvqPcjsY8TjfWQboKJ7gxclAuhbNLSYt+Tbcrf6zA /sMg== 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=6RhphAlFuVkALW36UOZJV3pY9b8TnEjog5IJFt6iiCQ=; b=jY7gNPEYFmjrGl2M+R2dK3ZKp7jX0iVWAeRw75Uf2+1Tuhw+bXgNO9/25AJB8wEpGk ycYtITQTzowdjEOPBKUBkgoPgtZr04bFGM+gYHipCMG4Ow/Ia7EH93j9FxeIOmgF/N70 0OOVHfZGdgah/d4JmCNRFAYBlbgmOGO1lzNzi12jAz0F+aaI2JEur8cZsS3ee12pj5US SOLlq0b6AwxDDoZ8OECOoWJu3oGQGW1glx+P/mai10Gc0g17HpiXQbx1SKc4/1DS+4pC MWeFl3sGf3q3i8MFuwViIGk+mu+OY7hzkk4NwztFVJSaquz1jbapjSzmvVM5uysFqR4o GObA== 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 127-v6si2018993pgj.25.2018.10.03.09.59.25; Wed, 03 Oct 2018 09:59:40 -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 S1727356AbeJCXsL (ORCPT + 99 others); Wed, 3 Oct 2018 19:48:11 -0400 Received: from mail.bootlin.com ([62.4.15.54]:45142 "EHLO mail.bootlin.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726842AbeJCXsK (ORCPT ); Wed, 3 Oct 2018 19:48:10 -0400 Received: by mail.bootlin.com (Postfix, from userid 110) id 33DDE206A7; Wed, 3 Oct 2018 18:58:54 +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 7693920DD8; Wed, 3 Oct 2018 18:58:15 +0200 (CEST) Date: Wed, 3 Oct 2018 18:58:15 +0200 From: Boris Brezillon To: Ricardo Ribalda Delgado Cc: Zhouyang Jia , LKML , Marek Vasut , linux-mtd@lists.infradead.org, Richard Weinberger , Brian Norris , David Woodhouse Subject: Re: [PATCH v4 6/8] mtd: maps: gpio-addr-flash: Convert to gpiod Message-ID: <20181003185815.23b40832@bbrezillon> In-Reply-To: References: <20181001124351.31615-1-ricardo.ribalda@gmail.com> <20181001124351.31615-6-ricardo.ribalda@gmail.com> <20181003171114.51ab47b8@bbrezillon> <20181003171727.145e7e41@bbrezillon> 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 Ricardo, On Wed, 3 Oct 2018 17:56:03 +0200 Ricardo Ribalda Delgado wrote: > Hi Boris > On Wed, Oct 3, 2018 at 5:17 PM Boris Brezillon > wrote: > > > > On Wed, 3 Oct 2018 17:11:14 +0200 > > Boris Brezillon wrote: > > > > > Hi Ricardo, > > > > > > On Mon, 1 Oct 2018 14:43:49 +0200 > > > Ricardo Ribalda Delgado wrote: > > > > > > > @@ -248,14 +252,19 @@ static int gpio_flash_probe(struct platform_device *pdev) > > > > > > > > i = 0; > > > > do { > > > > - if (devm_gpio_request(&pdev->dev, state->gpio_addrs[i], > > > > - DRIVER_NAME)) { > > > > + unsigned int *gpio_id = (unsigned int *)gpios->start; > > > > + > > > > + if (devm_gpio_request_one(&pdev->dev, gpio_id[i], GPIOD_OUT_LOW, > > > > + DRIVER_NAME)) { > > > > dev_err(&pdev->dev, "failed to request gpio %d\n", > > > > - state->gpio_addrs[i]); > > > > + gpio_id[i]); > > > > return -EBUSY; > > > > } > > > > - gpio_direction_output(state->gpio_addrs[i], 0); > > > > - } while (++i < state->gpio_count); > > > > + > > > > + state->gpios->desc[i] = gpio_to_desc(gpio_id[i]); > > > > + if (!state->gpios->desc[i]) > > > > + return -EINVAL; > > > > + } while (++i < state->gpios->ndescs); > > > > > > Actually, I was thinking about using devm_gpiod_get_array() here and > > > defining a gpio lookup table in the board file registering the device. > > > This way, adding support for DT based parsing is transparent. > > > > It's actually easier than I thought since no one is registering such a > > device, so all you have to do is call devm_gpiod_get_array() and have a > > struct gpio_descs pointer in struct async_state. > > That is what I do in patch 8/8 for DT based parsing. Well, yes, except you do it differently for the !DT case, while I'm suggesting to use the same patch for both DT and !DT. > > I am am doing the gpio_to_desc and other to maintain compatibility > with old platform board files (in and out tree). I do care about keeping in-tree users functional (which is why I suggested to declare gpio lookup tables in the first place), but keeping out-of-tree code functional is on a best-effort basis. If it breaks because we have to rework an internal API then that's not our fault. Actually, that's one of the reason we push people to upstream their code => their maintenance burden is greatly reduced once the code has reached mainline. > > I think is important to maintain that compatibility, but you decide ;) And my decision is, keep the code as simple as possible even if it breaks out of tree users. Regards, Boris