From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-8.7 required=3.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_PATCH,MAILING_LIST_MULTI, SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED autolearn=unavailable autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 5415AC4338F for ; Tue, 27 Jul 2021 11:35:54 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 396C261A04 for ; Tue, 27 Jul 2021 11:35:54 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S236523AbhG0Lfw (ORCPT ); Tue, 27 Jul 2021 07:35:52 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:36372 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S231781AbhG0Lfu (ORCPT ); Tue, 27 Jul 2021 07:35:50 -0400 Received: from mail-yb1-xb2c.google.com (mail-yb1-xb2c.google.com [IPv6:2607:f8b0:4864:20::b2c]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 59AE7C061757 for ; Tue, 27 Jul 2021 04:35:49 -0700 (PDT) Received: by mail-yb1-xb2c.google.com with SMTP id q15so20142848ybu.2 for ; Tue, 27 Jul 2021 04:35:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=baylibre-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=qco/AyihnJ5LF9OqcB7SLvxoAFgJ7udwLUJdc+kCzpo=; b=OHQfAWwqSfJLysT2xL6FU2eutfu/bnXiRKUERsAljy4Uv81/MzxAEMW9OyxJokU5wr W2dOvsHDPxN4CtC9uJV40eSOkvfgSWYxDoKsiPQ49Zi4GQDMqGwGJCzCm6xsJ0fAgq+d H9iZvpX9NIbgNCGHa84OAKLaw7MLegBpB7/zaN6sOJN/vAGoT9ORbdQT6WNIF5SX43uJ RmiSzf6JcPfkJQ46jZScHB5/m8Ue/cQvj4jquIP9RYh8xGds6LeiTd/V7hbBW9xouC5y UITiIkzTBJ2wvgrAlPBi8+WUjghsteaOwPmsJErUiU5BFRjQ20bhzxZTyVY+iGlkxJcQ EEvg== 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=qco/AyihnJ5LF9OqcB7SLvxoAFgJ7udwLUJdc+kCzpo=; b=FQeBw9HAVT2U5JXDS25SX/3qYWEMox4xGQh89zwdcZn7QxbL0pWVu8uwV70AzdDS46 DunZJ+al7Aui05KHYV3pbx3X0RrNWMSZDgDoui2/0bNppDme1llH2v1/ZPvvxEBFmLrg POV4/jsqYIpBp9p2LXgNojr36UcDDEIl5kWwbjGQcDi+pXfgF9ufb6OU7GILpZVq6vJD YVd9/1HYiu2kk4HJqY9WOIl7r+du+p/cF7bsDeeMmHcXDFnshTAx+iBbRZ0WHUA5p75b 7delZsP+hRBverx+rAdLoT1e8+W+U3zZreyDH6ULoBzS3e544KPc2pyrgXN+2ygvUg9x VhAw== X-Gm-Message-State: AOAM532XWOIs3sZn2G6dvCW5Ga+KK+I7wWKL/Nh9KHNMOiXSgJzAjarp 4Xf16kIfEkOxSJrmwNeUZJzTqZWuCnsjpecmABvgnA== X-Google-Smtp-Source: ABdhPJzfxtZ4mgMNBH40Q61Gql8DSCEAQWyHWZwB7JYUQpLZ3NY96M/waaOpz6NzjZRVOJBGFxHptQ/RrHpFlVuVv4E= X-Received: by 2002:a25:3750:: with SMTP id e77mr13079030yba.469.1627385748609; Tue, 27 Jul 2021 04:35:48 -0700 (PDT) MIME-Version: 1.0 References: <20210708070429.31871-1-sergio.paracuellos@gmail.com> In-Reply-To: From: Bartosz Golaszewski Date: Tue, 27 Jul 2021 13:35:38 +0200 Message-ID: Subject: Re: [PATCH 0/3] gpiolib: convert 'devprop_gpiochip_set_names' to support multiple gpiochip per device To: Sergio Paracuellos Cc: "open list:GPIO SUBSYSTEM" , Linus Walleij , Gregory Fong , Florian Fainelli , Matthias Brugger , =?UTF-8?Q?Ren=C3=A9_van_Dorst?= , Andy Shevchenko , John Thomson , NeilBrown , Nicholas Mc Guire , linux-kernel Content-Type: text/plain; charset="UTF-8" Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, Jul 27, 2021 at 8:02 AM Sergio Paracuellos wrote: > > On Thu, Jul 8, 2021 at 9:04 AM Sergio Paracuellos > wrote: > > > > There are some unfortunate cases where the DT representation > > of the device and the Linux internal representation differs. > > Such drivers for devices are forced to implement a custom function > > to avoid the core code 'devprop_gpiochip_set_names' to be executed > > since in any other case every gpiochip inside will got repeated > > names through its internal gpiochip banks. To avoid this antipattern > > this changes are introduced trying to adapt core 'devprop_gpiochip_set_names' > > to get a correct behaviour for every single situation. > > > > This series introduces a new 'offset' field in the gpiochip structure > > that can be used for those unfortunate drivers that must define multiple > > gpiochips per device. > > > > Drivers affected by this situation are also updated. These are > > 'gpio-mt7621' and 'gpio-brcmstb'. > > > > Motivation for this series available at [0]. > > > > Thanks in advance for your feedback. > > > > Best regards, > > Sergio Paracuellos > > > > [0]: https://lkml.org/lkml/2021/6/26/198 > > > > Sergio Paracuellos (3): > > gpiolib: convert 'devprop_gpiochip_set_names' to support multiple > > gpiochip baks per device > > gpio: mt7621: support gpio-line-names property > > gpio: brcmstb: remove custom 'brcmstb_gpio_set_names' > > > > drivers/gpio/gpio-brcmstb.c | 45 +------------------------------------ > > drivers/gpio/gpio-mt7621.c | 1 + > > drivers/gpio/gpiolib.c | 34 +++++++++++++++++++++++----- > > include/linux/gpio/driver.h | 4 ++++ > > 4 files changed, 34 insertions(+), 50 deletions(-) > > Hi! > > Linus, Bartosz, any comments on this series? > Looks good, but I was thinking you were going to address Gregory's points first and resend a v2? Bartosz