Received: by 2002:a05:6a10:f347:0:0:0:0 with SMTP id d7csp4070866pxu; Wed, 9 Dec 2020 07:41:07 -0800 (PST) X-Google-Smtp-Source: ABdhPJyCXtqzf+a+4erhfHQz4fKMbe+OWQ+1wAVQe5iEKDlFRW8RMNpBwDePjoOJA2MG08bb/8xH X-Received: by 2002:a50:d8c8:: with SMTP id y8mr2513136edj.82.1607528467264; Wed, 09 Dec 2020 07:41:07 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1607528467; cv=none; d=google.com; s=arc-20160816; b=tIMKIK3U1bi7ta/pVL6o9hFT02EFZiRmdBefxbY0Sx5yTEAMAWhJMO8+OC+UACb2aa SSYHRswhFjb49ULv1a0zDcDy3PFd+lvR2RWHbddKfw9143S74dOm/08fCBdqO/cgl5Tq ICtRvEba4jSFnVcI+NeTy3Ws+2SJXaBnHKxeRCiXGHiNmpPlpTkjWaqcmOk0jRmaIWHZ OoLXJ3Rlgh2IN+p83VsIjKp13r64kiC0IOk0Bw4W9F9R0U+SqxEKmqS2xoVm0g/u8pVY XlGDPCqeyzvAN5DYymqOxKBcigLd9sydzkqsdi70km/qf/G+zPbpaRnQvwcyPWn4ybhW I7Jg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:in-reply-to:content-disposition:mime-version :references:message-id:subject:cc:to:from:date; bh=c82hnL+n/w5N2k4itbMOvCwk0PTaYeye6Ht48+ywYyA=; b=bIwx2vfhzBZL7kKbg3AadXGomSarSF2cmAZ8quTew1Zn7O0ynp53EsXJTLP+4nBL6m I9ChmdzYppUxKpLInTFYFwVyJGhLiRuhXxwS/88KGOEuKeKhCk5eVcuEzRL59ciH/TF1 Fb2MGRbS9WvrMNE33FFZH0CJs620IpOSLCSAjRh47qRTHlYkBIqMx29JUF1TBTdaKbtK 0mGaPG/EEsthsp0HZz4GJAxQXSSX+lrjJbZuoHHOHuVVfM/v1mJ5Q09olp9mYBma/DH5 /a/z2WNADWeALIOf2dzLwQJIb01H1kfReKGd6I/QqRjkX+spsaOIADTV9zikc57SWVv9 5fJQ== ARC-Authentication-Results: i=1; mx.google.com; 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=kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id o9si1026950ejr.672.2020.12.09.07.40.44; Wed, 09 Dec 2020 07:41:07 -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; 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=kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1729997AbgLIPZR (ORCPT + 99 others); Wed, 9 Dec 2020 10:25:17 -0500 Received: from mail-lf1-f66.google.com ([209.85.167.66]:44573 "EHLO mail-lf1-f66.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1729949AbgLIPZQ (ORCPT ); Wed, 9 Dec 2020 10:25:16 -0500 Received: by mail-lf1-f66.google.com with SMTP id m25so3598385lfc.11; Wed, 09 Dec 2020 07:24:59 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to; bh=c82hnL+n/w5N2k4itbMOvCwk0PTaYeye6Ht48+ywYyA=; b=WfVFG6SBxzj19SwB7jgFUjzCQU/xibwzzKc/mBicKBmriepuFopDC33Z9WYTpFUWEw wfvZfTIaAbxztqTRJ+s4qTEYkhCh7rhBjO7k3MCSKU75RizbvoevFrUCoGr6NnVmg7hg wjlvvI65wYouPxHALr8e5XtVyYaLrID0lE4M5nbwzIrsPqYikj6944kHt6cETwc/M8I9 4/igDarUcUhIH0T0P638l46VYESTHQ30Fn1Hg9ymMg7F77yH6aVF2a5THS8ofj/M43lW IH+uPt52jQqlYO/LHE77+8M5krLq/TPFXoUPuGP2fcgN7W6ckzUh9aCpkBpmXrJXWOXi pj9g== X-Gm-Message-State: AOAM532Uzhck6/cBEczimeywQZXzExOuV+HRoIUuW8CELebLHwm2JFTk 1rxPk11Wn/yib0YQG6R333s= X-Received: by 2002:ac2:5469:: with SMTP id e9mr1107904lfn.439.1607527473924; Wed, 09 Dec 2020 07:24:33 -0800 (PST) Received: from xi.terra (c-beaee455.07-184-6d6c6d4.bbcust.telenor.se. [85.228.174.190]) by smtp.gmail.com with ESMTPSA id f15sm267706ljo.7.2020.12.09.07.24.32 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 09 Dec 2020 07:24:33 -0800 (PST) Received: from johan by xi.terra with local (Exim 4.93.0.4) (envelope-from ) id 1kn1L7-0005Wj-Sm; Wed, 09 Dec 2020 16:25:14 +0100 Date: Wed, 9 Dec 2020 16:25:13 +0100 From: Johan Hovold To: Linus Walleij Cc: Johan Hovold , 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" Subject: Re: [PATCH v5 2/3] usb: serial: xr_serial: Add gpiochip support Message-ID: References: <20201122170822.21715-1-mani@kernel.org> <20201122170822.21715-3-mani@kernel.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, Dec 08, 2020 at 01:41:52PM +0100, Linus Walleij wrote: > On Tue, Dec 8, 2020 at 10:57 AM Johan Hovold wrote: > > 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. Would it possible to set a flag to suppress just the sysfs entry renaming instead? Despite its flaws the sysfs interface is still very convenient and I'd prefer not to disable it just because of the line names. > 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? > 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...) Ok. > > 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. Or just suppress the sysfs-entry renaming if that's the only thing that's blocking this. Johan