Received: by 2002:a25:7ec1:0:0:0:0:0 with SMTP id z184csp7853112ybc; Fri, 29 Nov 2019 02:06:32 -0800 (PST) X-Google-Smtp-Source: APXvYqz1ThsU3UinpYmPb/hrfzYuEiA7VxAbAe+/hiNpL1ASSx0DHjHCcK2YeY9NOQJMsUxc1BcR X-Received: by 2002:a05:600c:230d:: with SMTP id 13mr8571090wmo.12.1575021991802; Fri, 29 Nov 2019 02:06:31 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1575021991; cv=none; d=google.com; s=arc-20160816; b=dbjZkQekA8tgBkUnz2qbnvtWJH8I0i8/VgSZKhanDQB/omWNgmyo7NzQNSdITtN4LI sL1Vcs8Re4EyETnUZyfLyHgO0iaJKVp/LDSqH4xPFY2zMBMUKK43ohynBa9g0E3iqdny eaTT4VhyYQEUv1uvNkR7pRExcWeVQ1TdAxg54TXmsQDkWuRT8lz4zBacFLwwnYmbLBk7 7Qq5utWkVvUktXBmL+ZOxA5Yfir4Cpk8BOGwfcdXnB8wWyqW925ST/Mh64W9Fm0/fh44 WzzvTO/KigPYhlF9wdWkkRU5IONkc/l/+T5aSmWla04cSiAxbNXUiUSTWoa5bEOIJnws 0yAw== 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=HF4UdVCwi1c1BKIgz/FESLhrgzjX9oNjO8/KjUNWsfk=; b=xyfVoUHwaro+JMpt6RAP7t0ACWMOBsSujV/WVYmnXMJMNsD+uKpVFSEMME0YJpDgb+ esJZj5+lIUSEZBuX8ikkl4ieaokQtWmGp7JQw8RbpVgEpy8ackCBTDzSBYZYgevkIEak iW6eCq4ZwnKZXAGoFI1p4HZDEMXlD3Lsd+nMOOYsqHgyW/qGs7m8kE9J1YorV/b44s/8 Ed6NF+I4EYLZuTDXKTyio7oV4AuaMDcTAlzFiRnQozL96eveImAguFoI03Z4uFIsw32W 1tfuAB8e2tzB8qqQFXvJGOMZZSyDjm6gvXZiEB7rrmzGqXxP03vo8goM+0QI8Mw7T1Ee X7Sw== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@linaro.org header.s=google header.b=LtOv8jPC; 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 g30si15695925edf.362.2019.11.29.02.06.06; Fri, 29 Nov 2019 02:06:31 -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=LtOv8jPC; 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 S1726832AbfK2KEg (ORCPT + 99 others); Fri, 29 Nov 2019 05:04:36 -0500 Received: from mail-lj1-f194.google.com ([209.85.208.194]:39568 "EHLO mail-lj1-f194.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726604AbfK2KEf (ORCPT ); Fri, 29 Nov 2019 05:04:35 -0500 Received: by mail-lj1-f194.google.com with SMTP id e10so22165346ljj.6 for ; Fri, 29 Nov 2019 02:04:34 -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=HF4UdVCwi1c1BKIgz/FESLhrgzjX9oNjO8/KjUNWsfk=; b=LtOv8jPCyXyB1wKB9sWSvMTFb/tuSMW7v8P5uDbv/o9y8q5F/5Dr9e2DE4jrD3A4vZ dAimauptihuec8YSuN8eVIwYruZG/G2wblAhcLl5bfHWDGElLo7ZlJ3jNhkxiqI0Tdl7 O2o5TSxbMBN8vQN8jlS27uptf5xuVVx3QCR1zPGnR0gHORk6MnRixVGuP8hsb3xN7zAn o32WLEO6bm/VKjqRUNpigbmRvDuPvx05Z1o18j2Os2jR4dk7FFWYuSqcTCHvEE++r+Gj zqJb47XOrvk2ac3sEKJzh8Vb2VLiin4/KTvuNT0DQpZkD948ZGRPpTRPeygeZY5q55mu RvHQ== 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=HF4UdVCwi1c1BKIgz/FESLhrgzjX9oNjO8/KjUNWsfk=; b=o+TfW6r6ZGp4vYJY2n6sCrmb5L6O4iE/C/VXQ6fWI3imQRPbLt6u/81fG8Va6IYtGI ISiL7yz/Xapm96FaiLFoIVT8lzc9AR89sj/R/IItkHqy2iSxBQY33ChGPNs2955jkmhT xjvEVS8K+6T6hvMI76KR/qtsAuPxtK0bQ5gJP1vpoAPvFipXX3m9KzKUENvrL9BOnWFk eqiSaFqOvYLrmKNU51Y7tRYxcL2rk1RmIGXw+idS7vhvomTRPlUf5b9+kqI40nm/KW6m G6HfCdC4odJnLhcACeCRXoyyNYeOrqmfYbo+dF/szVPj8TB6lVC5YmfPFluqDxgG5CxN V9pQ== X-Gm-Message-State: APjAAAWy3SK+Kv+DT3jI2KTgyo19wlaQ3+furFgZfoSKW2jLNr8puOA7 N4qRfs031SNNPYP3Qql1vGGSjIdo5yfgL6I9m9Z6k0kH1sk= X-Received: by 2002:a2e:9699:: with SMTP id q25mr37212398lji.251.1575021873761; Fri, 29 Nov 2019 02:04:33 -0800 (PST) MIME-Version: 1.0 References: <20191127133510.10614-1-brgl@bgdev.pl> In-Reply-To: <20191127133510.10614-1-brgl@bgdev.pl> From: Linus Walleij Date: Fri, 29 Nov 2019 11:04:22 +0100 Message-ID: Subject: Re: [PATCH 0/8] gpiolib: add an ioctl() for monitoring line status changes To: Bartosz Golaszewski Cc: Kent Gibson , "open list:GPIO SUBSYSTEM" , "linux-kernel@vger.kernel.org" , Bartosz Golaszewski 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 2:35 PM Bartosz Golaszewski wrote: > This series adds a new ioctl() that allows user-space to retrieve a > file-descriptor which can then be polled for events emitted by the kernel > when the line is requested, released or its status changed. This of course > doesn't require the line to be requested. Multiple user-space processes > can watch the same lines. So if I understand correctly all the series do is expose metadata about all GPIO lines to userspace? I think up until now the use case assumptions have been: - The kernel will pick off some GPIO lines, mostly during boot but occasionally at runtime (by users such as kernel modules or hotlugged devices). - Userspace will pick some lines from those that are available, after the kernel picked those it wants. If it tries to pick one of those that the kernel already picked, the request will be denied. The assumption (at least in my head) was that the GPIOs the kernel picks will not be a very dynamic business. So this appears to be dealing with this very dynamic business. Is the *main* use case different userspace processes trying to use the same pins and getting denied? Because in that case we might be putting a bit too much userspace plumbing into the kernel and we need to think about that for a while. (Binder and kdbus etc comes to mind.) So there is some feature growth happening here and I want to be aware of the whole picture. On a side track: There is a bit about policy that needs to happen here I suppose, like for example what if the kernel actually wants one of the lines that userspace has picked? Should userspace be kicked out and kernel get what it wants? (Arguably yes.) Yours, Linus Walleij