Received: by 2002:a25:8b91:0:0:0:0:0 with SMTP id j17csp902453ybl; Thu, 12 Dec 2019 06:43:09 -0800 (PST) X-Google-Smtp-Source: APXvYqxD5HpIvP4rgJIbeijO9IshQP97h1LRMmq1O0yLp8fqJ9mA/Cx/tcnqyC43bgnXBHxVbqjr X-Received: by 2002:a9d:7592:: with SMTP id s18mr8879230otk.130.1576161789323; Thu, 12 Dec 2019 06:43:09 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1576161789; cv=none; d=google.com; s=arc-20160816; b=LtaGJewaOCX8xZbnoE1DG74+fF6vZCeZ5AUBfDGVe580JBn9XTGHn56TPfA8IdtJzF zoDu26xu5hK0W/QlQ5FL4YvkNMNgkkwyZxqymZWXrq78LFF2G+RUsYzNhGRNTWnt7Cqv 2QW/dzz/LWHrzYkDdn7TMXQEr5NeTRhOOnJd8kFImZGHflz1DSffwGz/5Gmm1/dGNPFX 0UCJIt0GeQcVop3nldZXkGidCLTQLeavXJz7uKsgtCxxZ4BA1lt8gpDFmRsDN4BXhth0 qlNxf3lE5w1ciDvNE0MFpQk6WQpiRFO4gywt1cI0oO3761S2z5T2GcWdHfl1pmfJxKN8 y9sQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:dkim-signature; bh=tZEozXho8/b7kOqmVnapq/xyhPGY85u/Fazs9Eblm1E=; b=tFUIa3c17QOX+cm/vsY7FvjDjDFpjN+XPm/NhqBKAvl2ZcXS4DxMLQPLYnnL189Jgr eCkpZjJ3FKDWCtAqQO2Ut3y48k5oRhRPop+fR4M0GYRdVNDDpcjSqFEJuTOqXBlmqpkS vO2nnXtUd9GymwrrBjzMd0qBVf1BsaF8rkvi1lZGOU2CVY2+14z2onO/3a3CfvLNlVwh kv/tTNclk4jGRroHTkYDPgIU9SO+yGmgaoRWSR+FeU8o+2+fxl+LSe8tkpDZaXkpZEAD IpRN4bjnUhmOPLVv6GniEDuYMmYrSUCeLg++aBljcij4fQEsgg7gTMDY/sr726arDR// JJHg== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@linaro.org header.s=google header.b=cCFmmoTX; 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; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=linaro.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id w131si3192009oif.240.2019.12.12.06.42.56; Thu, 12 Dec 2019 06:43:09 -0800 (PST) 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; dkim=pass header.i=@linaro.org header.s=google header.b=cCFmmoTX; 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; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=linaro.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1729745AbfLLOmP (ORCPT + 99 others); Thu, 12 Dec 2019 09:42:15 -0500 Received: from mail-lf1-f67.google.com ([209.85.167.67]:39000 "EHLO mail-lf1-f67.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1729355AbfLLOmP (ORCPT ); Thu, 12 Dec 2019 09:42:15 -0500 Received: by mail-lf1-f67.google.com with SMTP id y1so1890784lfb.6 for ; Thu, 12 Dec 2019 06:42:13 -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=tZEozXho8/b7kOqmVnapq/xyhPGY85u/Fazs9Eblm1E=; b=cCFmmoTXOmDLfgP+nSgeOYumVAZUrCnARZzWT6kYYgCKF1bePY08qH25uoDIaIHIIP xy8kMJ6JQ2UyEvDyewbvtPrrH9UtNKJVImB4NokJIoH/R67zMUh04sKFC2b9DZZNNYUs aUGcMes7TUb5SFaiVdEGG5DyRqBgacd0FAD4lAf+ICRsdMe3e2j3QZ8mi0budLFypHnU Q9CAtFfX69QmpkYitVwIFJ08foJUmu7rOTj1ckh5yeQ90ov1O2obpxX2rMKf54BvokNm ude9UZXPiRBYKsQ2CDcY3DczzV6WI8NM6/9D9PHWpM76xo1IPmfR6iBERCj82PcqPI0L ppSg== 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=tZEozXho8/b7kOqmVnapq/xyhPGY85u/Fazs9Eblm1E=; b=hqdIwrkeJ+YCAZ3+y04c7+EN5qYL9OmvOGqwNczK7XraCvYjLViFwPa5ATCtRZ0lIQ d3BdDQMiEgDelP8zkM5MZKW30p5G1lt5QKJbBHdP2kvwagLk9HSWEiu0cYx6RIcUhprv RgGscMip2GPWiy4y0EYtE8B7Ese83uFQuQfRLABtnHbc7i9SSso9KIry/8sXDniyuIp/ fTHUCWABRGUsQqLa0Z0XRXVlDiO/W/UPSl7w9EX/lXof8I6isJC3NOOivSS872Eg8MgO EfFK+O+8OVQ5/sFl+YQabxBOAdhvt0D+lpXD44WU+ZdPbM9Y3RMySePx+M9nAHNYkrTv qtqQ== X-Gm-Message-State: APjAAAUEOyFGMII41F1KE5491P+7i1aif1vXryE95IY/xYOjQ4Mlu/nZ O3YVUVQQbTLygl7hEaHnI1sdvvqMuHpWYVSOdwjO7Q== X-Received: by 2002:ac2:4945:: with SMTP id o5mr5702467lfi.93.1576161732769; Thu, 12 Dec 2019 06:42:12 -0800 (PST) MIME-Version: 1.0 References: <20191127084253.16356-1-geert+renesas@glider.be> <20191127084253.16356-7-geert+renesas@glider.be> In-Reply-To: <20191127084253.16356-7-geert+renesas@glider.be> From: Linus Walleij Date: Thu, 12 Dec 2019 15:42:01 +0100 Message-ID: Subject: Re: [PATCH v3 6/7] docs: gpio: Add GPIO Aggregator/Repeater documentation To: Geert Uytterhoeven Cc: Bartosz Golaszewski , Jonathan Corbet , Rob Herring , Mark Rutland , Harish Jenny K N , Eugeniu Rosca , Alexander Graf , Peter Maydell , Paolo Bonzini , Phil Reid , Marc Zyngier , Christoffer Dall , Magnus Damm , "open list:GPIO SUBSYSTEM" , Linux Doc Mailing List , "open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS" , Linux-Renesas , "linux-kernel@vger.kernel.org" , QEMU Developers Content-Type: text/plain; charset="UTF-8" Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, Nov 27, 2019 at 9:43 AM Geert Uytterhoeven wrote: > +The GPIO Aggregator allows access control for individual GPIOs, by aggregating > +them into a new gpio_chip, which can be assigned to a group or user using > +standard UNIX file ownership and permissions. Furthermore, this simplifies and > +hardens exporting GPIOs to a virtual machine, as the VM can just grab the full > +GPIO controller, and no longer needs to care about which GPIOs to grab and > +which not, reducing the attack surface. > + > +Aggregated GPIO controllers are instantiated and destroyed by writing to > +write-only attribute files in sysfs. I suppose virtual machines will have a lengthy config file where they specify which GPIO lines to pick and use for their GPIO aggregator, and that will all be fine, the VM starts and the aggregator is there and we can start executing. I would perhaps point out a weakness as with all sysfs and with the current gpio sysfs: if a process creates an aggregator device, and then that process crashes, what happens when you try to restart the process and run e.g. your VM again? Time for a hard reboot? Or should we add some design guidelines for these machines so that they can cleanly tear down aggregators previously created by the crashed VM? Yours, Linus Walleij