Received: by 2002:a05:6a10:f347:0:0:0:0 with SMTP id d7csp4435601pxu; Wed, 9 Dec 2020 17:46:36 -0800 (PST) X-Google-Smtp-Source: ABdhPJyWpkGp9RUvVwrfYEtuUE49PwpkhPMMnjcfQMI40nuKBnyl8C3rQonyrGFhNRTkyZ0jxIV6 X-Received: by 2002:a17:906:b0c2:: with SMTP id bk2mr4299614ejb.223.1607564795798; Wed, 09 Dec 2020 17:46:35 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1607564795; cv=none; d=google.com; s=arc-20160816; b=k512btJ+IJk9ZG9pjwiXLzacPDUiYbJHUl8oyrZQGDfWsxAEP3Z6+rtV7E6BoC319F rGi/Zo8CBaoPnXU1Vw+CJ3PBZz2MiwIkHFlDjsifk/ewW8IeUn2NRZJIW1eDDTnQD7OE DT0h6f5LWQ4kuvOB9VyGVguNIRRFgpRaEDysqVNPvur8ds9478a5Wgiq51IP8G/XPRJL G/6KCXkcG12tzXOFpAQwn+tFhdl7+JiQZXSOSvqoVmkejeCSknzICNWRgfNK76/WEcqs 8XnsLze0yljKYATL95G0dLWcMusuwesIYb99d39NIy46KabAh64IeFhQSsLtgvxXyQSb AcrA== 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=0xBrb97lTo75kGlgbY3m4XgGoTI/1jjRhlZu6u72rgk=; b=MH13v6d3WQwP/ql8283yp/XQHm7qR9+2Lz5haI9xKxZJIhmLtQ6PUJf/DiXxqpfz0Q uo1QSlUxGB7x/fjhyuzulCqrClWz1zEUT41wsIAS3MirIiEs8f6n8EyH500e20YTuhfM hQPqKTam9MeAp4l+OLw3+XyRtPegz7kQFyRe/NNWrL07cTAAPJDG1YAZAkUU53qcPysX 7c+FGMFPfVtcJdR5172J0NGsR21WU2gLvbK1Qr5SFM7ZQb6aBKOTSyJ5yh9Z/9rBfYIs 2ZobhsGRoRovlC9gHHH1PyfB6uQw6yVvhPtXll/CibMh6vNdgZqNjLlHa9LggBuggu9D f2AA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@linaro.org header.s=google header.b=sDY9A2yM; 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 c1si1921551edx.275.2020.12.09.17.46.13; Wed, 09 Dec 2020 17:46:35 -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=sDY9A2yM; 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 S1731962AbgLIQ0q (ORCPT + 99 others); Wed, 9 Dec 2020 11:26:46 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:54574 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1730349AbgLIQ0q (ORCPT ); Wed, 9 Dec 2020 11:26:46 -0500 Received: from mail-lf1-x143.google.com (mail-lf1-x143.google.com [IPv6:2a00:1450:4864:20::143]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id A2135C0617A7 for ; Wed, 9 Dec 2020 08:25:45 -0800 (PST) Received: by mail-lf1-x143.google.com with SMTP id l11so3934918lfg.0 for ; Wed, 09 Dec 2020 08:25:45 -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=0xBrb97lTo75kGlgbY3m4XgGoTI/1jjRhlZu6u72rgk=; b=sDY9A2yMs122aEwsLRiAxNJUtdIrEVy+tAylzLcqgQaLuQgU/13aH4FcCdVRF72Jlj LJA7Cg1tkp04n8g6ckBSaSu8dClDZS51O9wMdZR95qKqxdFjS0zeyQ32gK7SFeivKv1l fQq+d+qR9qMZG3/dy8/V5wi8n7koeX96Aj/no3Ia7FmwUUuz1ElPhUTW9RYM5RPzOZiR 2HqlpVHvlMEmmq/BBkVh8BppZTUEWYqEATUK7bngOERX58IbWU9Ma82eT+QH0QZfTtOh GE5Y6UII6VLYGWmuvwZNzo/gbjskQCe/VW+ilicVTjCSt5I1qVyySwWiDo/fYmXF69SG u3iw== 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=0xBrb97lTo75kGlgbY3m4XgGoTI/1jjRhlZu6u72rgk=; b=Ex5R1n6Pg9hindZRtBy9Tgar83urFaR9Tatg8jVNr3U3wXAUV3ddRJ7FgXD+Rb9he1 V6p9ll9H33r/xYJGwEZCncpSVq4vMYzpkDptFJRTm/G83wFEVoATIaiJc3R3mIAq2H/b Cfu3LGoODvBI1bGCrmzuZJ0O/4kGudwrPI65Wtb2gxgBSAW3fojb4uC+XljL6HM7dF9H 3R9ep0TDvL2/6txyDO3QVuG2aRTKgzxSpqkxpgagGudXB92JJ34x89pKu9/aJZJGIlO8 Jqj6HFGLs4JyiXpgcp8JCQkoo6vP8B3TE8ZzRcJqYVQuK5uNuUDPVz8S6IXtnNPcBpTA QKMA== X-Gm-Message-State: AOAM530E0Ll5zfaHUka2/riZBH/Z3JzS53YQOP3XGZZrIc8u3X/jhBkG jfBslvtVvLvpgipXg9pm+TCMIMZDnodzTiZ4HxCVtw== X-Received: by 2002:a19:8384:: with SMTP id f126mr1133455lfd.649.1607531143780; Wed, 09 Dec 2020 08:25:43 -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: Wed, 9 Dec 2020 17:25:32 +0100 Message-ID: Subject: Re: [PATCH v5 2/3] usb: serial: xr_serial: Add gpiochip support To: Johan Hovold , Bartosz Golaszewski Cc: Geert Uytterhoeven , 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 Wed, Dec 9, 2020 at 4:24 PM Johan Hovold wrote: > On Tue, Dec 08, 2020 at 01:41:52PM +0100, Linus Walleij wrote: > > 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. > > Would it possible to set a flag to suppress just the sysfs entry > renaming instead? Hm you mean that when a GPIO is "exported" in sysfs it should not get a symbolic name from the names but instead just the number? I bet someone has written their scripts to take advantage of the symbolic names so I suspect the task becomes bigger like suppress the sysfs entry renaming if and only if there is a namespace collision. But I think we can do that, doesn't seem too hard? I just hacked up this: https://lore.kernel.org/linux-gpio/20201209161821.92931-1-linus.walleij@linaro.org/T/#u > Despite its flaws the sysfs interface is still very convenient and I'd > prefer not to disable it just because of the line names. Would these conveniences be identical to those listed in my recent TODO entry? https://lore.kernel.org/linux-gpio/20201204083533.65830-1-linus.walleij@linaro.org/ There are several other issues with the sysfs, so making it conflict with other drivers is almost plus in the direction of discouragement from the GPIO submaintainer point of view, but I do see that people like it for the reasons in the TODO. :/ I am strongly encouraging any developer with a few spare cycles on their hands to go and implement the debugfs facility because we can make it so much better than the sysfs, easier and more convenient for testing etc. > > Then it should be fine for any driver to provide a names array > > provided all the names are unique on that gpiochip. > > So it sounds like there's nothing preventing per-chip-unique names in > the rest of gpiolib and the new chardev interface then? Are the > user-space libraries able to cope with it, etc? Yes the documentation refers to libgpiod a very well maintained library: https://www.kernel.org/doc/html/latest/driver-api/gpio/using-gpio.html https://git.kernel.org/pub/scm/libs/libgpiod/libgpiod.git/ Then there are the the example tools included with the kernel that provide a second implementation for the same interfaces using just the C standard library: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/tools/gpio I usually use the tools myself. Yours, Linus Walleij