Received: by 2002:a25:ad19:0:0:0:0:0 with SMTP id y25csp10262045ybi; Thu, 11 Jul 2019 02:27:02 -0700 (PDT) X-Google-Smtp-Source: APXvYqyWMsZ9RPBL7QiKWoAVT/nHREhcYjkRuMJhf2S1iMvOjABtTV0VWuBv+q1zQ1K+z7KMw5dE X-Received: by 2002:a63:61c6:: with SMTP id v189mr821985pgb.427.1562837222464; Thu, 11 Jul 2019 02:27:02 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1562837222; cv=none; d=google.com; s=arc-20160816; b=kHjZoYGAW94NSCQgqqXj2kLwg9051TRx25GQVB1FGYXftPsWJi9WJaHo6hmVD77skl nwPJ7szJ+irgi+GOHC1eTfsYVB9NfE28LlJG0fteQvAchWWyp0qGyPQR5eMMPEIEsLkn AzZK1TlLhA++sTQF53B5fYTQgYSq+cyqngcrI9nn3UpAhNHYOv7DxLe65PlF8GgUI2rP MN/saynV0z3nQBm2ozC8anrx0EqYbseVUdgDG6pcmUjIPM9Wb0OEUGQlxiCKcY6zptSR 1BosrrhiCtDnMyJgRRjnHRn3Txec9BIEC6LyUb9Rus47J8qlIcCBEprRHC02p60FKMgX u/YQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding :content-language:in-reply-to:mime-version:user-agent:date :message-id:from:references:cc:to:subject; bh=Pc4si5bfMvRLmLV5jpZ1lVQJ8A20kgSsM9v684R86WM=; b=zcr3SqoiO595SHHPU/e+TUi8uqBWGhVbyvDxNCg2pYMk7mKVTxweA0a4MwatBxDMFH 5R2Y4BbV9vy9Ou7E1vF3Dh+7as25bfgcZ2iyCAATuCadR6m6VeiZ2xVTIflb+cqHT6HI Sml9fdBRVNT4bZadEmhmzrWI9HfR1qZLZVPCGGS00e9/AXXkzoItWL3cd9RMaPvy0DlM 0vTq6BtYEEyRjtXsguOE2yUKnprewOGgW+RoNZQU4Ipta0UiWPSyVPbh34EpE9Z0bFtq 8of8TzTudbWdFSSxchhKvxyzW5nTsnGyi9ihbxLtZs8OC9XCJQ9bMO3oiwxBz//Eb3rg C7WA== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id f7si4309905pgv.105.2019.07.11.02.26.46; Thu, 11 Jul 2019 02:27:02 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1728196AbfGKJYu (ORCPT + 99 others); Thu, 11 Jul 2019 05:24:50 -0400 Received: from anchovy1.45ru.net.au ([203.30.46.145]:34123 "EHLO anchovy1.45ru.net.au" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727595AbfGKJYu (ORCPT ); Thu, 11 Jul 2019 05:24:50 -0400 Received: (qmail 30049 invoked by uid 5089); 11 Jul 2019 09:24:48 -0000 Received: by simscan 1.2.0 ppid: 29900, pid: 29902, t: 0.0630s scanners: regex: 1.2.0 attach: 1.2.0 clamav: 0.88.3/m:40/d:1950 Received: from unknown (HELO ?192.168.0.128?) (preid@electromag.com.au@203.59.235.95) by anchovy1.45ru.net.au with ESMTPA; 11 Jul 2019 09:24:47 -0000 Subject: Re: [PATCH RFC] gpio: Add Virtual Aggregator GPIO Driver To: Geert Uytterhoeven Cc: Geert Uytterhoeven , Linus Walleij , Bartosz Golaszewski , Alexander Graf , Peter Maydell , Paolo Bonzini , Magnus Damm , "open list:GPIO SUBSYSTEM" , QEMU Developers , Linux-Renesas , Linux Kernel Mailing List References: <20190705160536.12047-1-geert+renesas@glider.be> <8500a069-9e29-d6ad-e5e4-22d5a3eead59@electromag.com.au> From: Phil Reid Message-ID: <1fc3a5ad-6eb6-3356-5fd4-93ce0482bb7e@electromag.com.au> Date: Thu, 11 Jul 2019 17:24:40 +0800 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:60.0) Gecko/20100101 Thunderbird/60.7.2 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-AU Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 10/07/2019 18:21, Geert Uytterhoeven wrote: > Hi Phil, > > On Wed, Jul 10, 2019 at 4:00 AM Phil Reid wrote: >> On 6/07/2019 00:05, Geert Uytterhoeven wrote: >>> GPIO controllers are exported to userspace using /dev/gpiochip* >>> character devices. Access control to these devices is provided by >>> standard UNIX file system permissions, on an all-or-nothing basis: >>> either a GPIO controller is accessible for a user, or it is not. >>> Currently no mechanism exists to control access to individual GPIOs. >>> >>> Hence add a virtual GPIO driver to aggregate existing GPIOs (up to 32), >>> and expose them as a new gpiochip. This is useful for implementing >>> access control, and assigning a set of GPIOs to a specific user. >>> Furthermore, it would simplify and harden exporting GPIOs to a virtual >>> machine, as the VM can just grab the full virtual GPIO controller, and >>> no longer needs to care about which GPIOs to grab and which not, >>> reducing the attack surface. >>> >>> Virtual GPIO controllers are instantiated by writing to the "new_device" >>> attribute file in sysfs: >>> >>> $ echo " [ ...]" >>> "[, [ ...]] ...]" >>> > /sys/bus/platform/drivers/gpio-virt-agg/new_device >>> >>> Likewise, virtual GPIO controllers can be destroyed after use: >>> >>> $ echo gpio-virt-agg. \ >>> > /sys/bus/platform/drivers/gpio-virt-agg/delete_device >>> >> >> Nice. >> This provides similar functionality to the "gpio inverter" driver currently on the list. >> Other than being just a buffer. > > Indeed, both drivers forward GPIO calls, but the gpio inverter modifies > some parameters passed. > > The way the drivers obtain references to GPIOs is different, though: the > inverter driver obtains a fixed description from DT, while the virtual > aggregator receives the description at runtime, from sysfs. > > But perhaps both drivers could share some code? Other than probing they're almost the same, except the inversion. This one's more complete for set / get multiple etc. > >> Would it be possible to do the lookup via line names? > > Doesn't the fact that a GPIO has a line name means that it is in use, and > thus cannot be aggregated and exported to another user? > They can be given line names via the dt property gpio-line-names. Which can be used by user space to find a gpio. Not sure if there's an equivalent api inkerenl. But it looks like we can find the info via struct gpiochip_info / gpioline_info linfo and work out the chip name and line offsets. So probably not required. Find the right gpio always seems tricky. We have systems with multiple i2c gpio behind muxes that may or may not be present. So i2c bus numbers are never consistent. And then different board revisions move the same gpio line to a different pin (or cahnge the gpio chip type completely) to make routing easier etc. -- Regards Phil Reid