Received: by 2002:a25:c593:0:0:0:0:0 with SMTP id v141csp978506ybe; Fri, 6 Sep 2019 10:02:54 -0700 (PDT) X-Google-Smtp-Source: APXvYqy1+tVwNCiPn6MciJ5puRCoRQzrwHMijVLFXksttxz+NnEMwDyU0kwo5ZotXcekbWD5sJQx X-Received: by 2002:a17:90a:d684:: with SMTP id x4mr10637062pju.31.1567789374579; Fri, 06 Sep 2019 10:02:54 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1567789374; cv=none; d=google.com; s=arc-20160816; b=kVQDGRXgAbnH/hKhSYixhqrDYTwDdsR+Y8YsE/ZHkmG0l11rdidBD78lK7qcHdQfs1 kTByi+gIExXwBdakCWHBVqXIgVnQyssmbHY1jX0ekXwzhd+8vOvoNOpDTuZSCyX4v0VF oWtoALklW9xscynbD99HWVq6rSs1352JOvwIwG4tHgidzDSzkln34shN/TcPEAHdiglo H2/mziunJGpscBljDmVmXGVVpynKVNMaSErI7p8Z3hMvsFJcRe86HlM4GkKXzC6xwYqh 1RSwoZxQYcTjtxylBU+uzOiQllz1MtYrH/UELX8V27Jr26x5GaoCWPtTn65qFKUs+BQ2 r87Q== 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:cc:to:subject :message-id:date:from:in-reply-to:references:mime-version; bh=AM6qd6l99n60gfwebp8d06d7VaWT8hcI0BqS4O0Yo1c=; b=jvhaST+BpS1wGYQ9Zvf9htQTuXE/r7sVu285BXkdSLiIDC0HP0ecMtRdqOlNavpM7i pCB6wDNemrr6nU8NM5/iAkQLOUezPd4DxgbS/dQVKy91CKNmupOWB6TmMK0cID7QZ/Ce o30lafJNiO75M96Gq7lw8Mkfy0DR24FXBoPaq6E7439Pn8zeOVw0bjQ+hrzepk61GTOO saIJMFeHw3V6K/Y3Lg5vMbWf8YJGgNos43b3H0nAguaMVg+MSnZCLJGR6wq6QGWnMCE3 mAV1U/yGkj4n3BZ2TfiaRlD+J2AyBm8NciIpDe8Xt7eWT//lDin5Jqy7IDTykmbe9z53 9j0Q== 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 g2si5281049plt.26.2019.09.06.10.02.38; Fri, 06 Sep 2019 10:02:54 -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 S1729928AbfIFLOX convert rfc822-to-8bit (ORCPT + 99 others); Fri, 6 Sep 2019 07:14:23 -0400 Received: from mail-ot1-f65.google.com ([209.85.210.65]:39014 "EHLO mail-ot1-f65.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726231AbfIFLOX (ORCPT ); Fri, 6 Sep 2019 07:14:23 -0400 Received: by mail-ot1-f65.google.com with SMTP id n7so5348745otk.6; Fri, 06 Sep 2019 04:14:22 -0700 (PDT) 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:content-transfer-encoding; bh=A+M249Y2yXTR5pLBFzUNH1SBf+7zmy/nNt6gvl0in+8=; b=ay3oHVCvhkOP4NCTsypUY8oM+oDGeXKR8DMt3kZaxiOGKxKu3ocvmz9GawMYIQG0xV dxypLYOYFoIJag0hImEircHpTUDwE5tEedcSuX5+aU2eWGuurARp3DTbjlmIdPvOX0xE JShBsh4+SM4CROCBLTiFvAkeLKURYbZp0HncVEwVYhTSay0WjYVv9a9PH7qyJ+SuHwz1 8QB+kezx1lSi5UxyDJbxcv1dbWmmJtOv8EobOCMfCyMUfY+Aw6LdSdyUiG709F6CBEcy YcTHWNL0zTeAWf52sdAQRCQGgllGQMfvo6VNzRXkjaGrKlJ8DMYUWuY1eFYoxOzsXAGN EQ8A== X-Gm-Message-State: APjAAAVouXrwZq1gD4s6qlAs+H8cuHLbtdbaShdMeIx7c0emn2EunT3D AHBkB7bM5/+cX2dVDqgoEkZrtAGZPu4RGQuJkTw= X-Received: by 2002:a05:6830:1196:: with SMTP id u22mr6812488otq.39.1567768461501; Fri, 06 Sep 2019 04:14:21 -0700 (PDT) MIME-Version: 1.0 References: <20190705160536.12047-1-geert+renesas@glider.be> In-Reply-To: From: Geert Uytterhoeven Date: Fri, 6 Sep 2019 13:14:10 +0200 Message-ID: Subject: Re: [PATCH RFC] gpio: Add Virtual Aggregator GPIO Driver To: Bartosz Golaszewski Cc: Geert Uytterhoeven , Linus Walleij , Peter Maydell , Paolo Bonzini , Magnus Damm , linux-gpio , QEMU Developers , Linux-Renesas , LKML Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8BIT Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi Bartosz, On Fri, Jul 12, 2019 at 11:27 AM Bartosz Golaszewski wrote: > wt., 9 lip 2019 o 17:59 Geert Uytterhoeven napisał(a): > > On Tue, Jul 9, 2019 at 4:59 PM Bartosz Golaszewski > > wrote: > > > pon., 8 lip 2019 o 12:24 Geert Uytterhoeven napisał(a): > > > > On Mon, Jul 8, 2019 at 11:45 AM Bartosz Golaszewski > > > > wrote: > > > > > pt., 5 lip 2019 o 18:05 Geert Uytterhoeven napisał(a): > > > > > > 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 > > > > > Am I doing it right? I'm trying to create a device and am only getting this: > > > > > > # echo gpiochip2 23 > new_device > > > [ 707.507039] gpio-virt-agg gpio-virt-agg.0: Cannot find gpiochip gpiochip2 > > > > > > gpiochip2 *does* exist in the system. > > > > Please try the name of the platform device instead. > > I.e. for my koelsch (R-Car M2-W), it needs "e6052000.gpio" instead > > of "gpiochip2". > > > > Probably the driver should match on both. > > > > > I see. I'll try to review it more thoroughly once I get to play with > > > it. So far I'm stuck on creating the virtual chip. > > This is not a show-stopper but one thing that's bothering me in this > is that lines used by the aggregator are considered 'used' in regard > to the original chip. I'm wondering how much effort would it take to > have them be 'muxed' into two (real and virtual) chips at once. Is that really what you want? If a GPIO is aggregated with othrs, it's intended to be used only through the aggregator, isn't it? > Other than that - seems to works pretty nice other than the matching > by chip name and by line names. Thanks, working on that... Gr{oetje,eeting}s, Geert -- Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org In personal conversations with technical people, I call myself a hacker. But when I'm talking to journalists I just say "programmer" or something like that. -- Linus Torvalds