Received: by 2002:a25:8b91:0:0:0:0:0 with SMTP id j17csp7520170ybl; Tue, 24 Dec 2019 04:09:46 -0800 (PST) X-Google-Smtp-Source: APXvYqwjttFyMV73mqrY7FuVb1ZChwhU8dHeB0dHicgFKiVPjhOc5/3WEQQU30Ca3CEFCJElZQhe X-Received: by 2002:a9d:6c06:: with SMTP id f6mr38786447otq.318.1577189386091; Tue, 24 Dec 2019 04:09:46 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1577189386; cv=none; d=google.com; s=arc-20160816; b=OR+nlGhgB0FPsBLpozavxV1kj0qroW56IMekuyfl5wEmA25lH2nVoIOh0v3NAzsGGT 6FAknt4XYfn2bdMBbqK4xinIXyQ0WLltsM9nwb07W8JzVm4njaDBlDIZwOmxYDg0uczl tF5Nb7MLQAo2n7S2uOGMXZGK20aX+BVyNunnCjXUDD485q3pr/uzP6yueauDxBjk1h4t 2SzFcmBz9a9tSRNAtn8iZxuI4bvLbnCT/waCYAF+k3Eau7jEXF9GjZ2ix7fooGT2W5d1 s7YB+8exXt/2K+BbPny9jYhHOxEoYN6qEgkrzk2TowU+GC/nfiC0dmjME0T3FY3rSJNV 8Gmg== 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 :dkim-signature; bh=kMEJ1g3awjiJois5IXlpJaY3/3SmKKn3MhVIUyIiwUc=; b=ChGHPCrsn1CBmz0pc92wsSqcRrMVji/y01mrCjHslvLX6s3H1zrbEOn+cTYLwC/zYV B+PWm/UOR1Cyy8zdUpf88w0C34/qxQUJbc0ByaaDvIWqBcqtpBJwzxNGcNJnD6RMDS3z nhWpNhx2f/aY8H6iYiup/gdtig8x9At1Ez2jRCVVhYWAWWN8MIbIx+Y/zTE+80QBSyP4 VTvj63ax59pR++r9bskf+d7H3Sa0HtbvZ9NmVkEj/lY+PQGhgagT7l3TWWqyO/wrsu2S G7jz+BlQILEBxFhdVYm53jjokjmQeJz5XIeE8BKSPgnYFEU/bOKwSTEs51ofMwXUAN2S Bjew== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@bgdev-pl.20150623.gappssmtp.com header.s=20150623 header.b="xE/k+Zm3"; 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 d17si10746996oib.174.2019.12.24.04.09.33; Tue, 24 Dec 2019 04:09:46 -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=@bgdev-pl.20150623.gappssmtp.com header.s=20150623 header.b="xE/k+Zm3"; 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 S1726435AbfLXMIy (ORCPT + 99 others); Tue, 24 Dec 2019 07:08:54 -0500 Received: from mail-io1-f67.google.com ([209.85.166.67]:40474 "EHLO mail-io1-f67.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726206AbfLXMIx (ORCPT ); Tue, 24 Dec 2019 07:08:53 -0500 Received: by mail-io1-f67.google.com with SMTP id x1so18967987iop.7 for ; Tue, 24 Dec 2019 04:08:52 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bgdev-pl.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=kMEJ1g3awjiJois5IXlpJaY3/3SmKKn3MhVIUyIiwUc=; b=xE/k+Zm3ZFRXndkfMspOBt5kR1YvFrSN0e2ynu/Wmd5Vds0tGvSKoLQ568kSJzlK+9 HM79XkYELPxySMdzErmPeFL+NY4dFv+zPRPCRw/alakoh4B9QoqXIHE79Awa475DyLqq nyQ8jHyCpVmjoQTFe+9AhGTec4hJUJI+seEwGF+Xa85edEgT3Gb8OP03MI8rSI8wwaGx RSYDy/qI4U0s/5cuRns5hsx4Be65/Lq53Sf3zVLf66C1l6K6oIVNA9zJgTASGFqua8ez abXcCTTESsZT+6aWnJPDOflcO8DcUXVO/O3w4H1fU4AjyM/D8jnVGheLVhrC0ytMjZPY xmPg== 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=kMEJ1g3awjiJois5IXlpJaY3/3SmKKn3MhVIUyIiwUc=; b=WS0joAuyfI41es4AJ3+CsAss/CMutiHlolO0yR3DkldUhuVV/Uwm2iGG/jRklRO+Y5 okkOcsGE7FgZmxQIU6w7nB/G/8HJy+EnrO+6TbaVqrb6Xu3jwfMx+SlOU5YuPXfUboXU 5RO2jhEk1ZXIrcz34zqiy6MOTK3mtzmzknyiPo41BqkvWlw7oWxXss56UB2BX20NG4mY kDaTTkqcWp7UqcZWqOljUlcvfJZC357tsgrkAMwrLeG+nMNJVuNBh9iWPKqlW2wyzatx XQmvHo0bjeGhF/F+qzdO45NEQnvHI+acw8/mJkXiPWGxbVSyUHrAPYAbGZbRQVXqPNWf CV4g== X-Gm-Message-State: APjAAAX53U5M42QfaPWmQGrromslvtjs8C2cyckGMtcFrWW9/qCD+CnF MZWHN1jnS4POxJ1d1Df+a/wB6ZlBSEQpxkaGydPrCQ== X-Received: by 2002:a02:40e:: with SMTP id 14mr27133228jab.102.1577189332324; Tue, 24 Dec 2019 04:08:52 -0800 (PST) MIME-Version: 1.0 References: <20191219171528.6348-1-brgl@bgdev.pl> <20191219171528.6348-13-brgl@bgdev.pl> In-Reply-To: From: Bartosz Golaszewski Date: Tue, 24 Dec 2019 13:08:41 +0100 Message-ID: Subject: Re: [PATCH v3 12/13] gpiolib: add new ioctl() for monitoring changes in line info To: Andy Shevchenko Cc: Kent Gibson , Linus Walleij , Andy Shevchenko , Greg Kroah-Hartman , "open list:GPIO SUBSYSTEM" , Linux Kernel Mailing List , Bartosz Golaszewski Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org czw., 19 gru 2019 o 19:17 Andy Shevchenko napisa=C5=82(a): > > On Thu, Dec 19, 2019 at 7:17 PM Bartosz Golaszewski wrote= : > > > > From: Bartosz Golaszewski > > > > Currently there is no way for user-space to be informed about changes > > in status of GPIO lines e.g. when someone else requests the line or its > > config changes. We can only periodically re-read the line-info. This > > is fine for simple one-off user-space tools, but any daemon that provid= es > > a centralized access to GPIO chips would benefit hugely from an event > > driven line info synchronization. > > > > This patch adds a new ioctl() that allows user-space processes to reuse > > the file descriptor associated with the character device for watching > > any changes in line properties. Every such event contains the updated > > line information. > > > > Currently the events are generated on three types of status changes: wh= en > > a line is requested, when it's released and when its config is changed. > > The first two are self-explanatory. For the third one: this will only > > happen when another user-space process calls the new SET_CONFIG ioctl() > > as any changes that can happen from within the kernel (i.e. > > set_transitory() or set_debounce()) are of no interest to user-space. > > > - } else if (cmd =3D=3D GPIO_GET_LINEINFO_IOCTL) { > > + } else if (cmd =3D=3D GPIO_GET_LINEINFO_IOCTL || > > + cmd =3D=3D GPIO_GET_LINEINFO_WATCH_IOCTL) { > > Wouldn't be better for maintenance to have them separated from the day 1? > I think this would lead to a lot of code duplication. I left it as it is is= v4. Bart