Received: by 2002:a05:6a10:f3d0:0:0:0:0 with SMTP id a16csp2627955pxv; Sun, 27 Jun 2021 04:03:37 -0700 (PDT) X-Google-Smtp-Source: ABdhPJy722RsFBwZJ4hzKI8XdN9TI/IC/bb5IWx8j170aI7hi18RZ+VedYyXNcFlcj/g4Usd297k X-Received: by 2002:a05:6e02:1c03:: with SMTP id l3mr13661549ilh.34.1624791817373; Sun, 27 Jun 2021 04:03:37 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1624791817; cv=none; d=google.com; s=arc-20160816; b=iXSN6xbQaiJLe3/iA2vCOm5WywF4JHUXDeY6jg9g/sgw6+OHvZQ4SOhnO7il/yZQ4a OwAlQe1b0+sD9C8Rt7kKGmFvmIYRAPmcuejolovldSDeI8casljdS2n+EhuuBX6XdkfW YOOGzA7yUr26IhNDd4vUStEuyAKuy1Jt4RfDHdqOtJHfWj+j6FRj79EbO1vlCUZTerSC x16x8JYZR76/y9Ba9H9hl5tVizZM5ar7N0mWMaPG5S0CGnQ91QMxya5WKIAs5IDRI85b aBGKp/Onn0rxcxvJ2x065DDJV0+PbW28wOzts+RKkx46buAEaVu0DTxf7K+yOqEkF+Mv Srmw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:cc:to:subject:message-id:date:from:in-reply-to :references:mime-version:dkim-signature; bh=kLTwelHcXBJw8i+63n2Vewy+RJJirrdy+PrskcqPqcs=; b=g5n5uaBm6dPZn05RCRWdMVTEsqumuGn9N4hJktvokT6H65/uY+tww2AyZDq+Ed45p0 v4mld4flWAt+goCIRi5jD8SQf3SLlGIYcLcq7lHX1wosRzushs37M+FfOAnDbx+MStgP fBKHCM2+icKftOog8XgHEkIeYFrAQ7k7+7YYAb1R4fuzA0NkgzeH0LfGUuV/1XOpEpWh +tKDvF5oOJ5aMjXa9oC7Htch52qow+ZhW+Le0ub9QqdVoZb2T5Lm1fIbamYSAEqgn856 m+mctlDs1VE167ivXAtRdHamKkSBd9oIq7lQ+yh7U+kbXL3OA1uS5jGxMfhBPhIP725I NYsw== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@gmail.com header.s=20161025 header.b=XgOTGXF1; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id g25si13458683jan.88.2021.06.27.04.03.24; Sun, 27 Jun 2021 04:03:37 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; dkim=pass header.i=@gmail.com header.s=20161025 header.b=XgOTGXF1; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S230205AbhF0K6x (ORCPT + 99 others); Sun, 27 Jun 2021 06:58:53 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:42310 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229526AbhF0K6x (ORCPT ); Sun, 27 Jun 2021 06:58:53 -0400 Received: from mail-vs1-xe32.google.com (mail-vs1-xe32.google.com [IPv6:2607:f8b0:4864:20::e32]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 79396C061574; Sun, 27 Jun 2021 03:56:28 -0700 (PDT) Received: by mail-vs1-xe32.google.com with SMTP id x12so8272426vsp.4; Sun, 27 Jun 2021 03:56:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=kLTwelHcXBJw8i+63n2Vewy+RJJirrdy+PrskcqPqcs=; b=XgOTGXF1fwhkgJohN8gb5ThJ9aYZFVVG4V7G/W+CdVurrRa98CYshGXEnh3rhRGoWw qC3ClikQkr2/YQWvBJKLdHZeK2qJjsKQgwXBJ1KEEtnftNnOwmIHPsqMD/MXbnPbbZES souwmswV2i9epMJiRWy5vfrBZKQn4sPXUE9tuOoivBRlQ2geEbiSamjSY8f9dEmNWKux StTIcIwSD4T6COqSEsIwm4z+skAdiXDaG8GW2rYt9R1//me0R6SbFTmw+AAnWHXU4iFC TyBcG5M15FNmtSRWYVYAU0HZQFudht7ehHLlAeuts3tzBe+6J8zvLAr+IRUaUhj2+39A B19w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=kLTwelHcXBJw8i+63n2Vewy+RJJirrdy+PrskcqPqcs=; b=O1s9L7/Op2+Ie+ShSZQ/8FYHYVWAnTK8UCOUtdQn+SM2TEWZX0BZFxRiZHYnzF7Ovl ROl5VBSrXkqCVlcqHOty4fytx6CHXpw2GDvcyG62AyuLXoHgtYWHJVaB9f6Gr0gFazQO kzsyUQE/wawo3gxzPnvjuWppCIEtZvuHtmyAqrSX9irlOkjZUHXtFsXq5SOkXXMtGI8r n4BodG/E6h9OGTX48lgDu3mUdOCJ5MWBzYAJXMlrr1gIIjtRTKOjN6r5UHNf/2pUmoQ7 5xAaaI97BNg4KnqWVrh8B0nV09t3jX14MFDmsWKiodf2k5ZVP9jN3WrTK9fxU/6/5i3t 2GmQ== X-Gm-Message-State: AOAM533erNmGo/7Tq96mRyl74kn4byYuvcfAib4Bd788YUwO30+lhRXA UOH7ItWPsand+2M9OthBpZx3pXRLERvzdDzhMu0= X-Received: by 2002:a05:6102:90f:: with SMTP id x15mr14453075vsh.28.1624791387598; Sun, 27 Jun 2021 03:56:27 -0700 (PDT) MIME-Version: 1.0 References: <20210626161819.30508-1-sergio.paracuellos@gmail.com> In-Reply-To: From: Sergio Paracuellos Date: Sun, 27 Jun 2021 12:56:15 +0200 Message-ID: Subject: Re: [PATCH v2] gpio: mt7621: support gpio-line-names property To: Andy Shevchenko Cc: "open list:GPIO SUBSYSTEM" , Bartosz Golaszewski , Matthias Brugger , Linus Walleij , John Thomson , Linux Kernel Mailing List , NeilBrown , =?UTF-8?Q?Ren=C3=A9_van_Dorst?= , Nicholas Mc Guire Content-Type: text/plain; charset="UTF-8" Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Sun, Jun 27, 2021 at 12:51 PM Andy Shevchenko wrote: > > On Sun, Jun 27, 2021 at 12:47 PM Sergio Paracuellos > wrote: > > On Sun, Jun 27, 2021 at 11:33 AM Andy Shevchenko > > wrote: > > > > > > On Sat, Jun 26, 2021 at 7:18 PM Sergio Paracuellos > > > wrote: > > > > > > > > The default handling of the gpio-line-names property by the > > > > gpiolib-of implementation does not work with the multiple > > > > gpiochip banks per device structure used by the gpio-mt7621 > > > > driver. > > > > > > > > This commit adds driver level support for the device tree > > > > property so that GPIO lines can be assigned friendly names. > > > > > This driver has three gpiochips with 32 gpios each. Core implementation > > > > > > implementation > > > > > > > > > > got gpio's repeated along each gpio chip if chip.names is not assigned. > > > > To avoid this behaviour driver will set this names as empty or > > > > > > the driver > > > these names > > > > > > > with desired friendly line names. Consider the following sample with > > > > minimal entries for the first chip with this patch changes applied: > > > > > > The same comment as per v1: > > > > > > Any idea why it's not a duplicate of > > > https://elixir.bootlin.com/linux/v5.13-rc7/C/ident/devprop_gpiochip_set_names, > > > and why the latter is not called in your case? > > > > The core properly calls this function but not in the way expected. > > This driver implements three banks of 32 gpios each internally using > > one gpiochip per bank, all of them in the same device. So the core > > code you are pointing out here duplicates the same names along the > > three gpiochips which is not the expected behaviour. So implementing > > in this way and setting names at least reserved avoids the core code > > to be run and also avoids the duplication getting expected behaviour > > for all the banks and each line friendly name. > > Isn't it the problem of how we supply fwnode in that case? > Another possibility is to fix DT (although I'm not sure it's now possible). Since the fwnode is the same for all banks of the same device, each bank repeats the first MTK_BANK_WIDTH label names in each bank. This commit populates the gc.names member of each bank from the device-tree node within the driver. This overrides the default behavior since devprop_gpiochip_set_names() will only be called if names is NULL. Best regards, Sergio Paracuellos > > Have you considered the above? > > -- > With Best Regards, > Andy Shevchenko