Received: by 2002:a05:6a10:f347:0:0:0:0 with SMTP id d7csp3150155pxu; Tue, 8 Dec 2020 05:00:37 -0800 (PST) X-Google-Smtp-Source: ABdhPJxPR7RBTvFmNhGJ6ExwZ8OiZxz97mqdXt9VdgR+c0hmHBRr/lQb68ehu5Un57ZHmXWWTDfx X-Received: by 2002:a17:906:2602:: with SMTP id h2mr22639814ejc.358.1607432436816; Tue, 08 Dec 2020 05:00:36 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1607432436; cv=none; d=google.com; s=arc-20160816; b=I3cdeXGPT5nVbh8VH1BOi7rD7VxFJa9N07sX+6Izves5lY+dPYk7IcvmXEM76Ww9/c YvzucO6U7ANXD5hY/7iPJolb+KHE0EOmUwcFC6K2OFPy4Q3O/X5jx6zpHvV4RDtvGcvH zhOCuN6oZkrO1hfmxCwNzAK+W/LwdFia2KXAJQ7dkomaR90LQ9Q+rZk2sM9OQZnp0c7P 78QIAhLgdGkWf0MHymFtPiFeblYE/VHlY/rvQLUpU93l1eDJd5N836vsiyJEFIm5waMh qeTJbniHrdaaYbttwJtv1Hs49rMW8Q6qFmYs1b0GFGkpRp6YSTrwgSQNTwhHMPyZbmAk Afmw== 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=tx7so5XKh7FIt1CA8a0h/fwFWUTtxj/iNvR1h5PSzgs=; b=W8Z+fsMcLekb74LNru7dC6WD8y9pHTaNBsQLMEtX61IRCgpNm0GoJM9sBw7DVll2U3 dSyTtWofGd3I1MzSWAOruadWXEaVo7IQ7kFTS4wgqBnNnCQ2qXQFCkEd1AQWMCDCwT0I k8fGv+yog5jHr8bg91Z2XDCoP2VQEoQT6LoA50Yb1dS2WUYfhE0mREQBW3F1BxKC0YdN 4w6sR6AwdgBbEymGgskQhT/JX+KiwtbtzWbhSALXMJ/Sy6LxkoK3gRrUX6M8fg5UCEZ0 GtFNWYRB/gF1t9Muky4aIORUSVHuWZ+uQFEpNdv0Yp66OAfXnG/IcHYjeVvvy2IUsXTM NYfw== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@linaro.org header.s=google header.b=X9IfdZ07; 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=NONE dis=NONE) header.from=linaro.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id g10si8145915ejp.536.2020.12.08.05.00.13; Tue, 08 Dec 2020 05:00:36 -0800 (PST) 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=@linaro.org header.s=google header.b=X9IfdZ07; 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=NONE dis=NONE) header.from=linaro.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1729556AbgLHMmq (ORCPT + 99 others); Tue, 8 Dec 2020 07:42:46 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:49208 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1729067AbgLHMmp (ORCPT ); Tue, 8 Dec 2020 07:42:45 -0500 Received: from mail-ej1-x643.google.com (mail-ej1-x643.google.com [IPv6:2a00:1450:4864:20::643]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 3CA94C061793 for ; Tue, 8 Dec 2020 04:42:05 -0800 (PST) Received: by mail-ej1-x643.google.com with SMTP id n26so24363845eju.6 for ; Tue, 08 Dec 2020 04:42:05 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=tx7so5XKh7FIt1CA8a0h/fwFWUTtxj/iNvR1h5PSzgs=; b=X9IfdZ07CRaiRKxilHDYeGeCj7zned0+KK4/c2hUOKGBFsLX4mL5lpbLbO4tW8eFx+ S1SPRlOnL119OUpixgUVUsaanEf+Inh54zdDT4arb83ADCp1T0ZRxNlpvvuyUtlVq6BL /B0K29s1R81mTX/7k9+yGB2VfH4gAsqUMKzGZ61+GP37udF5so1UcUvtNiP7Fpv2W/uN LzcRJM+sfvD2NRyYdvW6qhzTCOb3GpRgDp0uyTJd209DJESVQL1CXmjfLWhEqyMYh6Lc bNoqBEzhWivPk5Uy/g7HHyJWaOQm3flu8ayUQzLrpGpuM2LIEJMnhhJV5/be7zf/ZZQI 8FGQ== 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=tx7so5XKh7FIt1CA8a0h/fwFWUTtxj/iNvR1h5PSzgs=; b=rX/jd6WnMKzk0hgQ5z5/qAS5SEaSipmJJVjG0o9Lk7aAodE+T4pWjyxgUsbabKcYBA uV0pIu/HvtuMmqUsmiFrU5Is1kTpIz2R5Yg36ngTVKSEYS0880Jhe95PXrQZzDRVwKwl ScrDCbOPFpNJwlTCjXviAdnhb1KAQf0m4SJJnZSE+Zel5DyeDIQMvOHiR22wJyGUWJPs uIYdA6aqaB9aretefJf+dmv/kD1qs0XOlF/d5E7jgF9HoxD+6hlB56jW8j2hQ+B9vzu1 Bi333ML15aDAQHanX/4Rm/cgtf1ECRtVP3bS3VVpj+zgUzAuPbshJUHHdm/p2whc4kS/ ECDw== X-Gm-Message-State: AOAM531ZR1OCfxylABqc5MJBNrz8yuHRYghWjauLx529GBTasOfxvK/j a5VrsVK3iW9AnRZB6KksJm0iz3Rm9tzoXT7nYZcGJQ== X-Received: by 2002:a17:906:38c3:: with SMTP id r3mr2523260ejd.193.1607431323939; Tue, 08 Dec 2020 04:42:03 -0800 (PST) MIME-Version: 1.0 References: <20201122170822.21715-1-mani@kernel.org> <20201122170822.21715-3-mani@kernel.org> In-Reply-To: From: Linus Walleij Date: Tue, 8 Dec 2020 13:41:52 +0100 Message-ID: Subject: Re: [PATCH v5 2/3] usb: serial: xr_serial: Add gpiochip support To: Johan Hovold , Geert Uytterhoeven Cc: Manivannan Sadhasivam , Greg KH , linux-usb , "linux-kernel@vger.kernel.org" , patong.mxl@gmail.com, Mauro Carvalho Chehab , Angelo Dureghello , "open list:GPIO SUBSYSTEM" Content-Type: text/plain; charset="UTF-8" Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, Dec 8, 2020 at 10:57 AM Johan Hovold wrote: > [Me] > > A better approach might be to create an array of names > > prepended with something device-unique like the USB > > bus topology? Or do we need a helper to help naming the > > GPIOs? What would be helpful here? > > > > name = kasprintf(GFP_KERNEL, "%s-NAME", topology_str); > > Well we started discussing this back when we only had the sysfs > interface which suffered from the same problem. I thought the chardev > interface was supposed to get rid of the assumption of a flat name > space? Perhaps in v3 of the ABI. ;P It's "mostly true" that the line names are unique per-chip actually, because people don't like the nasty warning message. I wonder if anything would really break if I go in and make a patch to enforce it, since all drivers passing ->names in the gpiochip are in the kernel we can check them all. If the names are unique-per-chip, we can add a restriction like this with the requirement: depends on !GPIO_SYSFS so it can't even be compiled in if someone is using the sysfs. That should solve the situation where people are (ab)using the sysfs and getting name collisions as a result. Then it should be fine for any driver to provide a names array provided all the names are unique on that gpiochip. I doubt it would break anything, but let's see what Geert says. He has some special usecases in the gpio-aggregator driver which will incidentally look for just linenames when aggregating gpios, but I feel it is a bit thick for it to work with multiple hot-pluggable GPIO chips as well, I don't think that is its usecase. (We all want to be perfect but...) > But what about any other non-pluggable > IC, which provides a few named GPIO lines and of which there could be > more than one in a system? I think if there are such, and the lines are unique per-chip we should make the drivers depend on !GPIO_SYSFS. > The topology is already encoded in sysfs and it seems backwards to have > each and every gpio driver reconstruct it. I agree. I think if this driver already has unique line-names per-gpiochip we could actually make it depend on !GPIO_SYSFS and just add the names. Yours, Linus Walleij