Received: by 2002:a05:6a10:f3d0:0:0:0:0 with SMTP id a16csp2306142pxv; Sat, 3 Jul 2021 05:06:36 -0700 (PDT) X-Google-Smtp-Source: ABdhPJzXKORZ3awruYHnsXqqpLer/dfRbrxkjM8wHjXAkDs9heJYtC2wpMAIvjJSZJHhFqCmv32O X-Received: by 2002:a92:c7b2:: with SMTP id f18mr3399181ilk.210.1625313996528; Sat, 03 Jul 2021 05:06:36 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1625313996; cv=none; d=google.com; s=arc-20160816; b=z/o2O5piGz6arCSvk+mkP43gK39kFoKLjMpHhy/kNPNZSG39jLZdpBmztz/5o03APV p+PJVxJZEhSAcznMq4CP1qfZ+DnveJKCEpOzcR6gJITBb8Hobn6R+2OhCY+xR5ZHGjcW LuGt2QSi3/Jw5exjnaZ2XIHXywM+bl8lLm/b+MuTq+SCkJ4q8HgqrweyBN3pJFbpeok0 wQX/asmXrmTfSphJBXYi0DFLazmZH3V+SqvqrNsDB3s6SXrXUThUILsiwiafemIdHZma 0Q45LqO5V4ceAgqNfdsb8nvWrXZIkhhw5lRfnQFywqnklWdHeroo27tzQzjHRhhrVFC3 sBMQ== 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=YrphHIKKNpwDrjBvImzBllcHPyqT527cfhc4uIy0bkM=; b=qtCgqoltOpKVH1Mlpdr76YihOkPMRl/TJl/nkRPYlxcbYs2q3jXemKyIDT4JkRt05W VF2BoSKT9PSUV1W3jza1KPrDZbUJd0fjckMRQoClSnnVQrlknxjWtoaqViuDt9QRLGyb VKPQqXV+QQTSmGgPj4n+WxbTg6L/dk+iLtZ8NytCEdfcaxbYmoKn/2u/IMnZDNMQz9gf IVHUug4xQ3hn02E6TLnsI5xkq6aZvyg082t9BJq2WkFbN2sZXk5yFbY575wPw5ojpo5N 57nZnHsyJ2aB1MQkXAyabvCM0nlVIpf9q1L0N/POwYqc8Ya0SF99stuLRUwc8vGuBmu8 8GvQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@gmail.com header.s=20161025 header.b=KzSVMkJR; 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 a14si7703135jat.22.2021.07.03.05.06.11; Sat, 03 Jul 2021 05:06:36 -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=KzSVMkJR; 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 S230209AbhGCMH6 (ORCPT + 99 others); Sat, 3 Jul 2021 08:07:58 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:42078 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S230226AbhGCMH5 (ORCPT ); Sat, 3 Jul 2021 08:07:57 -0400 Received: from mail-vs1-xe34.google.com (mail-vs1-xe34.google.com [IPv6:2607:f8b0:4864:20::e34]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id DEC7AC061762; Sat, 3 Jul 2021 05:05:23 -0700 (PDT) Received: by mail-vs1-xe34.google.com with SMTP id h18so3502383vsj.2; Sat, 03 Jul 2021 05:05:23 -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=YrphHIKKNpwDrjBvImzBllcHPyqT527cfhc4uIy0bkM=; b=KzSVMkJRvUpu/dIMFegOMKzrMIKMdqp7THZ84dvVxOITjQI3hEyNymmZ5YP3wVvmRo BorOFT9ksyhSu43hqzt0fild7OvJDj80ff3H88edW+0oxVuZhM0HRbgJaJJClj0GTR1z rxdIbYdCyisqcLM6m43JVK52oyfDDD/bfklM66XMpC8Erfgu3CNE4sTTTbuwEh3ukSWY Xq3nl9eyBH75EPSiPdy6x6u52PRS3+Ax/B0LVKSLgraq8IpZYNiYJ2IUsRBt9tOcQgmn vB7y8mg3lZjFtxtqb98nMySSSwfJfIalEqdqSUsGpLMHxHKtWwQ3VAL5rGuuOcpjtsJO J3WA== 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=YrphHIKKNpwDrjBvImzBllcHPyqT527cfhc4uIy0bkM=; b=XyxOVRjA2ARC5HfGkBUwCO7M6Iimv6d9tMQizGHNuyD3SkE7DRy0HRtCU9F5w5RwC5 VElIt+VImjJAjd90pfAY/VyjDLFljVumZgmYPlKhi3lcEIF6oWTziml2JjIzocFREKZY spEpeSWSuY3tgmruEIYefW6NX6binESgqDF0NnnTOunHX8nBX5DmCNDrkVUxEM7bAJIl 4uzKa2eWaQ9T/z3E11cs1iFtEPVr6WyJXkVoMQhRFcX19glfE/nkb/5PDBwXFPLDQEej WqGVbAeIqc6rqdqIReYcGh5VTkumPVJr8M11zhVVGVcQ5b2rD+Xh3UzeAWbFaHNnjxt0 G9rQ== X-Gm-Message-State: AOAM531wTR+QdvK0ZIqOczdly4SInspP+tOV9kuCwuQlblSc2KXebaih SilrLrbMGXWhqObt6d+iMrjh3m6o6LRNF7rjUvQ= X-Received: by 2002:a05:6102:32d5:: with SMTP id o21mr3650464vss.28.1625313922947; Sat, 03 Jul 2021 05:05:22 -0700 (PDT) MIME-Version: 1.0 References: <20210626161819.30508-1-sergio.paracuellos@gmail.com> In-Reply-To: From: Sergio Paracuellos Date: Sat, 3 Jul 2021 14:05:11 +0200 Message-ID: Subject: Re: [PATCH v2] gpio: mt7621: support gpio-line-names property To: Andy Shevchenko Cc: Linus Walleij , "open list:GPIO SUBSYSTEM" , Bartosz Golaszewski , Matthias Brugger , 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 Hi Andy, On Sat, Jul 3, 2021 at 1:32 PM Andy Shevchenko wrote: > > On Sat, Jul 3, 2021 at 2:06 PM Sergio Paracuellos > wrote: > > On Fri, Jul 2, 2021 at 1:30 PM Sergio Paracuellos > > wrote: > > ... > > > - ret = devprop_gpiochip_set_names(gc); > > + ret = devprop_gpiochip_set_names(gc, 0); > > I had been expecting that this parameter would be in the field of the gpiochip. > > ... If doing it in that way is preferred, I have no problem at all. But in that case I think there is no need for a new 'devprop_gpiochip_set_names_base' and we can assume for all drivers to be zero and if is set taking it into account directly in devprop_gpiochip_set_names function? Is this what you mean by having this field added there?? > > > The problem I see with this approach is that > > 'devprop_gpiochip_set_names' already trusts in gpio_device already > > created and this happens in 'gpiochip_add_data_with_key'. So doing in > > this way force "broken drivers" to call this new > > 'devprop_gpiochip_set_names_base' function after > > 'devm_gpiochip_add_data' is called so the core code has already set up > > the friendly names repeated for all gpio chip banks and the approach > > would be to "overwrite" those in a second pass which sounds more like > > a hack than a solution. > > > > But maybe I am missing something in what you were pointing out here. > > Would the above work? The following works for me, but the overwritten part of the 'gdev->descs[i].name' because this has been already called once by the core code is hacky and dirty, IMHO :) diff --git a/include/linux/gpio/driver.h b/include/linux/gpio/driver.h index 4a7e295c3640..ad145ab0794c 100644 --- a/include/linux/gpio/driver.h +++ b/include/linux/gpio/driver.h @@ -537,6 +537,8 @@ extern int gpiochip_add_data_with_key(struct gpio_chip *gc, void *data, devm_gpiochip_add_data_with_key(dev, gc, data, NULL, NULL) #endif /* CONFIG_LOCKDEP */ +extern int devprop_gpiochip_set_names_base(struct gpio_chip *gc, int base); + static inline int gpiochip_add(struct gpio_chip *gc) { return gpiochip_add_data(gc, NULL); diff --git a/drivers/gpio/gpiolib.c b/drivers/gpio/gpiolib.c index 6e3c4d7a7d14..f9942d5d2f2a 100644 --- a/drivers/gpio/gpiolib.c +++ b/drivers/gpio/gpiolib.c @@ -361,13 +361,14 @@ static int gpiochip_set_desc_names(struct gpio_chip *gc) /* * devprop_gpiochip_set_names - Set GPIO line names using device properties * @chip: GPIO chip whose lines should be named, if possible + * @base: starting index in names array to start copying from * * Looks for device property "gpio-line-names" and if it exists assigns * GPIO line names for the chip. The memory allocated for the assigned * names belong to the underlying software node and should not be released * by the caller. */ -static int devprop_gpiochip_set_names(struct gpio_chip *chip) +static int devprop_gpiochip_set_names(struct gpio_chip *chip, int base) { struct gpio_device *gdev = chip->gpiodev; struct device *dev = chip->parent; @@ -383,12 +384,18 @@ static int devprop_gpiochip_set_names(struct gpio_chip *chip) if (count < 0) return 0; - if (count > gdev->ngpio) { + if (count > gdev->ngpio && base == 0) { dev_warn(&gdev->dev, "gpio-line-names is length %d but should be at most length %d", count, gdev->ngpio); count = gdev->ngpio; } + if (count <= base) { + for (i = 0; i < count; i++) + gdev->descs[i].name = ""; + return 0; + } + names = kcalloc(count, sizeof(*names), GFP_KERNEL); if (!names) return -ENOMEM; @@ -401,14 +408,21 @@ static int devprop_gpiochip_set_names(struct gpio_chip *chip) return ret; } + count = (base >= count) ? (base - count) : count; for (i = 0; i < count; i++) - gdev->descs[i].name = names[i]; + gdev->descs[i].name = names[base + i]; kfree(names); return 0; } +int devprop_gpiochip_set_names_base(struct gpio_chip *gc, int base) +{ + return devprop_gpiochip_set_names(gc, base); +} +EXPORT_SYMBOL_GPL(devprop_gpiochip_set_names_base); + static unsigned long *gpiochip_allocate_mask(struct gpio_chip *gc) { unsigned long *p; @@ -684,7 +698,7 @@ int gpiochip_add_data_with_key(struct gpio_chip *gc, void *data, if (gc->names) ret = gpiochip_set_desc_names(gc); else - ret = devprop_gpiochip_set_names(gc); + ret = devprop_gpiochip_set_names(gc, 0); if (ret) goto err_remove_from_list; diff --git a/drivers/gpio/gpio-mt7621.c b/drivers/gpio/gpio-mt7621.c index 82fb20dca53a..d4f19ab726b2 100644 --- a/drivers/gpio/gpio-mt7621.c +++ b/drivers/gpio/gpio-mt7621.c @@ -282,6 +282,12 @@ mediatek_gpio_bank_probe(struct device *dev, return ret; } + ret = devprop_gpiochip_set_names_base(&rg->chip, bank * MTK_BANK_WIDTH); + if (ret) { + dev_err(dev, "Error setting line names for bank %d", bank); + return ret; + } + /* set polarity to low for all gpios */ mtk_gpio_w32(rg, GPIO_REG_POL, 0); Best regards, Sergio Paracuellos > > -- > With Best Regards, > Andy Shevchenko