Received: by 2002:a05:6a10:1287:0:0:0:0 with SMTP id d7csp3516465pxv; Mon, 19 Jul 2021 02:03:25 -0700 (PDT) X-Google-Smtp-Source: ABdhPJyNadYyQ2aj7ZAYyTB6KNs8mae/PMdnzHf71gyxd07f0eMUShrcO9uXSQwq/ua3yu7M23jM X-Received: by 2002:a05:6e02:1354:: with SMTP id k20mr15960223ilr.169.1626685405479; Mon, 19 Jul 2021 02:03:25 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1626685405; cv=none; d=google.com; s=arc-20160816; b=NfkvF8uhoi58yqAeRRj084IuAUwABHpWE0klMNAl4BMfJH/gDv8OzJe1n3IFfCNCdT lW2C3QeHIwymEJ8ggiSyx+IvlH6AuhLZGloixMtXQQrIqKoWUnhvvQMJ0BY/1ul4QLWH ETR7G+IBvQ5aMXWHRIf4LQh/0RabYyzc5+rIdDSWoMUY5AQGw6W25kjPPqmMXRoCQVmF RuzAPXDNCRVP8ElZLuwM1rjA3nnUK16UPUC9Ooh9lTUnwM3PN+rKpsH9cETWVONLj52w KDx8wnAIHha7ZQjfTeJei6lzh4HgtB8F5uHj6NM9JqN876xQdG0uPwPT31cMcF+314M0 Z/vA== 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=cGOQ+tHFFR3Lj7D9YmjuYRyBNzj2z0fXhnb3i5wHBdU=; b=FmC2oXwxYCQChkFo+Vb4c2OgUfOU0d2dIASqvLNECHzvI5rPaJdoH4Hs3s9EQn2dU5 RsUDQDzlNXkIWvLCaHRy/kQsa8nVQAQ5/gvhROlm++dWMfezPe+D/cSMlxSsrSl1AeBG lvA8w9JNJg/sdPXAWF/L7YkOq/qWdwo3HoSb6YYZBFCYvcMWqG26JRIgzrxAA1g5/YuO 5uuhlWjbWDkZhGAXsN9wwPdz42VwtPcTD8ehD13J9zHE0MvBpekhU8d2vkypPRJRi+7+ WFrNmo3cvrijCCZQZWclC5Nwht63Ip2VAmETuXHTqIW6CYO7+dGfEsFFC59m4rYJ55bx LXCQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@gmail.com header.s=20161025 header.b=Tuv4KBac; 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 d9si2396712ila.112.2021.07.19.02.03.13; Mon, 19 Jul 2021 02:03:25 -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=Tuv4KBac; 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 S235648AbhGSIWF (ORCPT + 99 others); Mon, 19 Jul 2021 04:22:05 -0400 Received: from mail-qv1-f45.google.com ([209.85.219.45]:42541 "EHLO mail-qv1-f45.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S235609AbhGSIWE (ORCPT ); Mon, 19 Jul 2021 04:22:04 -0400 Received: by mail-qv1-f45.google.com with SMTP id ck17so8006518qvb.9; Mon, 19 Jul 2021 02:02:44 -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=cGOQ+tHFFR3Lj7D9YmjuYRyBNzj2z0fXhnb3i5wHBdU=; b=Tuv4KBacoXGBFfhz3unVvZAsOpJYEE59bZCMw8zc6xo1kS6sY97c7tw/9rWHG7xqPO j6V9k5W+jiN0rRdnRKwpFJXlWCh60r+m6I3B7ZJGA/4pJ4zlopc+0z19BhOMnEYlGW5U U3t/jO5kw2mFtnHWhjWgYokgTK0F5tWjzPwkcjwKLbzXOJxz8Z00zV7uJnJ0v3gdov7+ 6ct09u//y/8/5TvhxNrLPxQh/g4Xew5zvPJHj/GXUWTKKA0idSOOenlKuXOZ6Dhin7Ei g6LBoMms879Ar6GmZ7NCT6G17wb6o5ppGMo4w0lYSVKgdHoRLGib2lRuIHrSg7om8R9Q iRew== 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=cGOQ+tHFFR3Lj7D9YmjuYRyBNzj2z0fXhnb3i5wHBdU=; b=b7V83+gf4JdTYV+YBezpbcYnfGjVeG2QX16IghLQ2lIwBRYQ+xKICfuQ3lZRaKaiio ywEGZr32c9KAFQL4Upie7onApBRbkPm52gstI8m0efnFGgfl0f35FmLm1zY8eVB4JPR2 UCKe5n6yE0h4QUfRPk+FKgkasgtSrIb9jjAxZU5SqaRWEUIF5gvtC7EJXmm0QFE+6eRB fNlNvApelKE8lVFp8lDhUNDdCXpZ2YBnkJ7Pk2spehVg/84MoI1oUzYIbV+IkBWLTSSw 5rr2Y0BQbxf2NOSiokbzD3m2gPbs/oqnu31ccjiTvfCVPOWojZGn7vF+VUOfbZyP23X5 +1fA== X-Gm-Message-State: AOAM531qeEgye0rvKRWI+hMUo+OPs2i7QB2WxRY7tzt/USiiDuv/LJU0 6L/WDKYAKWrcfX9ol8BphUJROENsjhYGUj5nvwquKj6+MPJAJg== X-Received: by 2002:a05:6122:1041:: with SMTP id z1mr20802749vkn.5.1626683483673; Mon, 19 Jul 2021 01:31:23 -0700 (PDT) MIME-Version: 1.0 References: <20210708070429.31871-1-sergio.paracuellos@gmail.com> <20210708070429.31871-2-sergio.paracuellos@gmail.com> <20210719075723.GA8818@kessel> In-Reply-To: <20210719075723.GA8818@kessel> From: Sergio Paracuellos Date: Mon, 19 Jul 2021 10:31:12 +0200 Message-ID: Subject: Re: [PATCH 1/3] gpiolib: convert 'devprop_gpiochip_set_names' to support multiple gpiochip baks per device To: Gregory Fong Cc: "open list:GPIO SUBSYSTEM" , Linus Walleij , Bartosz Golaszewski , 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 Hi Gregory, Thanks for the feedback. On Mon, Jul 19, 2021 at 9:57 AM Gregory Fong wrote: > > Hi Sergio, > > On Thu, Jul 08, 2021 at 09:04:27AM +0200, Sergio Paracuellos wrote: > > The default gpiolib-of implementation does not work with the multiple > > gpiochip banks per device structure used for example by the gpio-mt7621 > > and gpio-brcmstb drivers. To fix these kind of situations driver code > > is forced to fill the names to avoid the gpiolib code to set names > > repeated along the banks. Instead of continue with that antipattern > > fix the gpiolib core function to get expected behaviour for every > > single situation adding a field 'offset' in the gpiochip structure. > > Doing in this way, we can assume this offset will be zero for normal > > driver code where only one gpiochip bank per device is used but > > can be set explicitly in those drivers that really need more than > > one gpiochip. > > This is a nice improvement, thanks for putting this together! A few > remarks below: > > > > > Signed-off-by: Sergio Paracuellos > > --- > > drivers/gpio/gpiolib.c | 34 ++++++++++++++++++++++++++++------ > > include/linux/gpio/driver.h | 4 ++++ > > 2 files changed, 32 insertions(+), 6 deletions(-) > > > > diff --git a/drivers/gpio/gpiolib.c b/drivers/gpio/gpiolib.c > > index 27c07108496d..f3f45b804542 100644 > > --- a/drivers/gpio/gpiolib.c > > +++ b/drivers/gpio/gpiolib.c > > @@ -382,11 +382,16 @@ static int devprop_gpiochip_set_names(struct gpio_chip *chip) > > if (count < 0) > > return 0; > > > > - if (count > gdev->ngpio) { > > - dev_warn(&gdev->dev, "gpio-line-names is length %d but should be at most length %d", > > - count, gdev->ngpio); > > - count = gdev->ngpio; > > - } > > + /* > > + * When offset is set in the driver side we assume the driver internally > > + * is using more than one gpiochip per the same device. We have to stop > > + * setting friendly names if the specified ones with 'gpio-line-names' > > + * are less than the offset in the device itself. This means all the > > + * lines are not present for every single pin within all the internal > > + * gpiochips. > > + */ > > + if (count <= chip->offset) > > + return 0; > > This case needs a descriptive warning message. Silent failure to assign > names here will leave someone confused about what they're doing wrong. Ok, I will add something like "All line names are not defined for bank X.". Or any other suggestion would be also ok :). > > > > > names = kcalloc(count, sizeof(*names), GFP_KERNEL); > > if (!names) > > @@ -400,8 +405,25 @@ static int devprop_gpiochip_set_names(struct gpio_chip *chip) > > return ret; > > } > > > > + /* > > + * When more that one gpiochip per device is used, 'count' can > > + * contain at most number gpiochips x chip->ngpio. We have to > > + * correctly distribute all defined lines taking into account > > + * chip->offset as starting point from where we will assign > > + * the names to pins from the 'names' array. Since property > > + * 'gpio-line-names' cannot contains gaps, we have to be sure > > + * we only assign those pins that really exists since chip->ngpio > > + * can be different of the chip->offset. > > + */ > > + count = (count > chip->offset) ? count - chip->offset : count; > > + if (count > chip->ngpio) { > > In the multiple gpiochip case, if there are 3+ gpiochips this seems like > it will yield an invalid warning. For example, if there are 3 gpiochips > (banks 0, 1, and 2), and all gpios are given names in gpio-line-names, > isn't this condition going to always evaluate to true for bank 1, > resulting in an invalid warning? In that case I would think setting > count to chip->ngpio is the *expected* behavior. > > Since that's a "normal" behavior in the multiple gpiochip case, I'm not > sure there's a simple way to detect an over-long gpio-line-names here > in this function anymore. Yes, in case of multiple chips with all lines names defined this warning will be displayed but I wanted to maintain the warning for normal cases and I was not able to find an easy way of distinc that cases with those having multiple gpiochips internally. So I ended up in "ok, will be displayed for those special cases and interpreted as we are just assigning names within an offset along the gpiochips in the device.". Any other suggestion of course is always welcome :) Thanks, Sergio Paracuellos > > > + dev_warn(&gdev->dev, "gpio-line-names is length %d but > > should be at most length %d", + count, > > chip->ngpio); > > + count = chip->ngpio; + } + for (i = 0; i < count; i++) > > - gdev->descs[i].name = names[i]; + > > gdev->descs[i].name = names[chip->offset + i]; > > > > kfree(names); > > > > [snip] > > Best regards, > Gregory