From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-5.8 required=3.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI, SPF_HELO_NONE,SPF_PASS autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 4DCC4C54EDB for ; Sat, 12 Dec 2020 01:01:05 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 260B52343E for ; Sat, 12 Dec 2020 01:01:05 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S2395013AbgLLAEn (ORCPT ); Fri, 11 Dec 2020 19:04:43 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:48638 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S2389717AbgLLAEZ (ORCPT ); Fri, 11 Dec 2020 19:04:25 -0500 Received: from mail-lf1-x142.google.com (mail-lf1-x142.google.com [IPv6:2a00:1450:4864:20::142]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id DE835C0613D6 for ; Fri, 11 Dec 2020 16:03:44 -0800 (PST) Received: by mail-lf1-x142.google.com with SMTP id u18so15707081lfd.9 for ; Fri, 11 Dec 2020 16:03:44 -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=SfxY10PKBlgSw6/Fq87LV1LDFIW7NSQj7nViKjsG+no=; b=Wv11Q6mHv1gO+UaNIbL3zUo9qxZ+sUkHbR3bPMfJXBP7hbTgQJTAEuD7NrSlyu5iSs GZY1MvMu2QY+1vgHEbL861U/AW0MFtcrwrOHtO4nQCZsil9oq4+HwCAMi/NszMkxMXcs ds5ydgWlDwUByKmBJHOLU77zHHsuw/a7lcOdiMC2bVLJETcemZlkqkrQWC2BWBZupm5O Ue+0Yhb6R/g69gA0RI1FZdiQU9o4+4dZ9aLzJLwqSUtMbO2GDNouFSMO1ZXgWm0a7wqg w8WCrN9NuJEg+zwXtoHzuXzhY2Q/8zobMukCOIfDB1fFkLkQvxoFPsZCgnjNzr+tEXJU VaxA== 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=SfxY10PKBlgSw6/Fq87LV1LDFIW7NSQj7nViKjsG+no=; b=YpctglOUABB0DmIniwn7Dgz5HOud1zS1apqRV6JJUryfpVc2LoyLcVdFP9YEIy7dIw Dmg/nSCB8uiev8PBbPr3kuiiMC7tSHtumvqZtWdU83/8n4cXMtZz2qabHNZm/KL7VqQr EokAFVPb9+yGUtxJWf47ohPKJx14m8R48sYjbd1qOX6Xjf7c+Pq2JMeiRJksY1Czl6Th n9jArfVB4eQBLL65h4R/8SgOxJBQXgSBLl31ywXOwd6q45lww1CAlHBbqUH1WzCf5F0V WJFdmat1mLWIg3fFFza2rk8VZHx0D4ST1E3Yxji8F51Q2z8hE4adGX1SB/TxArFbU/q5 q1oQ== X-Gm-Message-State: AOAM532dB3eeefZGs8l64+IwutHxhA6rIWS5BSn+FZRvVu2kxIV7aUu4 0UW/97CaGTahq+MfS9BdtV/yyvIAF5PQICkhG3w+xg== X-Google-Smtp-Source: ABdhPJx3IAmrcEpXXMHnifRqVgVvTeCANVyRGmMptZidgvCOnkz50UFCvqUVtOhvhNSlPjj6hHub2Zi1irgcEhjEmys= X-Received: by 2002:a2e:3503:: with SMTP id z3mr5506252ljz.74.1607731423405; Fri, 11 Dec 2020 16:03: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: Sat, 12 Dec 2020 01:03:32 +0100 Message-ID: Subject: Re: [PATCH v5 2/3] usb: serial: xr_serial: Add gpiochip support To: Johan Hovold Cc: Bartosz Golaszewski , 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 Thu, Dec 10, 2020 at 9:53 AM Johan Hovold wrote: > On Wed, Dec 09, 2020 at 05:25:32PM +0100, Linus Walleij wrote: > I just replied to that thread, but to summarize, you can't rely on > having the sysfs code detect collisions since that will trigger a bunch > of nasty warnings and backtraces. We also don't want the sysfs interface > for a specific USB device to depend on probe order (only the first one > plugged in gets to use the line names). And adding line names now could > in fact be what breaks currently working scripts. Yes the sysfs ABI is very volatile and easy to break. As pointed out in the other reply, sysfs base GPIO number is all wibbly-wobbly on anything hot-pluggable so in a way I feel it is the right thing to disallow sysfs altogether on hotpluggable devices. > > 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. > > Don't you run the risk of having people enable debugfs in production > systems now just so they can use the old-style interface? That risk always exist of course. For this and many other reasons. I just have to trust developers to understand that debugfs is named debugfs for a reason. > Side note: if you skip the "export" part of the interface, how would you > indicate that a line is already in use or not available (e.g. > gpio-range-reserved)? The idea is that if you poke around there you know what you're doing or ready to face the consequences. I am thinking if people want to toggle LEDs and switches from debugfs for testing and hacking they'd be alright with corrupting the SPI interface if they make mistakes. The chardev ABI is the only thing which we really designed with some users, multiple users, compatibility and security in mind, yet we had to revamp it once from scratch... > Just did a super quick check and it seems libgpiod still assumes a flat > name space. For example, gpiod_chip_find_line() returns only the first > line found that matches a name. Shouldn't be impossible to extend, but > just want to make sure this flat namespace assumption hasn't been to > heavily relied upon. The unique way to identify a GPIO is gpiochip instance (with topology from sysfs) and then a line number on that chip. This is done e.g. in the example tool tools/gpio/gpio-hammer.c As you can see the tool doesn't use these line names. The line names are really like symbolic links or something. But they are indeed in a flat namespace so we should try to at least make them unique if it turns out people love to use these. As it is now system designers mostly use device tree to assign line names and they try to make these unique because they don't like the nasty warnings from gpiolib. If I google for the phrase "Detected name collision for GPIO name" I just find the code, our discussions and some USB serial devices warning about this so far. Maybe we should just make a patch to disallow it? Yours, Linus Walleij