From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-0.8 required=3.0 tests=DKIM_SIGNED,DKIM_VALID, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 086FBC432C0 for ; Thu, 21 Nov 2019 10:03:46 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id C5E7B2089F for ; Thu, 21 Nov 2019 10:03:45 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=bgdev-pl.20150623.gappssmtp.com header.i=@bgdev-pl.20150623.gappssmtp.com header.b="fkxHr5C6" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727051AbfKUKDp (ORCPT ); Thu, 21 Nov 2019 05:03:45 -0500 Received: from mail-io1-f67.google.com ([209.85.166.67]:38063 "EHLO mail-io1-f67.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726614AbfKUKDp (ORCPT ); Thu, 21 Nov 2019 05:03:45 -0500 Received: by mail-io1-f67.google.com with SMTP id u24so984678iob.5 for ; Thu, 21 Nov 2019 02:03:44 -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=Y3Z0zDVlTPlNhNJ5RUPyFqzaLbtvM/FHVTTZSw7nDKw=; b=fkxHr5C6PGf4JEPkxvECkXuYO0fmpPV1j1DXQODelAV045gsU/awCJtHC/I93icdJd Q9teSeQHHh+Q9zMo0dTcy2UUnYxpVupsqsy7/m3zxLZc9kwTX3xKFYOJkr+VzxxmQvaF eJ9F01DTdKNwWgdSguXIEVevuDSXEeJOF4IYBJK9uDW1o83Z+YICci87VEJhCxyJINbP wL1BPMjwLsOpPE29Sj9/GU59nmHpfYpUfM0WtZEnztydiyE/Ro6vi5VkDegzoypCB6oC zk81DS9scklAntn5g7puIjU8jbLLJzSqm68aT7X+MgCzbQWKTc9UGr6MbZ/CRatH7IrD xtBA== 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=Y3Z0zDVlTPlNhNJ5RUPyFqzaLbtvM/FHVTTZSw7nDKw=; b=OTojw1Rb5wrL+/OVGrEZomzGwlaqi51bjTeClQ2fRUGmT5ICIkEkzlcp56RrlWwI8P okguKcW/fQpepvRB/1YZNDB8i3B2M/tQsomDSoSe0CaP6HkRL4gEFHgXmzd5GpEdPBvq O3MC/CPNssRooc5DSX3AKLOPTA1xFaUdHxSd7175zrhWkEqSsTs5fKhIWvsOeENk58AL TZmMn6ynwxyMe6Ij0Fm/FHFNN36Bw03ZpdtiK+3BESvCHj0AZ7bTqyct7xjkQFvLNEuw 9yWOzbEkWtba8K4gSQJH/5rSfoW39Nqp7VtoZMkj19DMaHC4X+YAjtagwrLew751Ru94 C0vQ== X-Gm-Message-State: APjAAAXHGhDrqAPFlRGAVS3Y7bS7nZR/JKeKPvwqTIUSNv0X5w1k7bj3 Do1Ot7jgLj1VeGEo2+eq3JeXnAePWHzoxkMYU/DOMmTC8nw= X-Google-Smtp-Source: APXvYqzZ42F4P/nuyToJw+4wS4HCT4XYRovA5M/bCk8ivmHpDKJS1AcEDoMgVu32MdUV51O5yW+BVKEHwyobIZlSh5M= X-Received: by 2002:a6b:18c1:: with SMTP id 184mr6821240ioy.40.1574330623919; Thu, 21 Nov 2019 02:03:43 -0800 (PST) MIME-Version: 1.0 References: <20191120135857.GA4218@sol> <20191120141353.GA5154@sol> <20191120143644.GA5865@sol> <20191121003443.GA7695@sol> <20191121074621.GA17026@sol> <20191121093030.GA19142@sol> In-Reply-To: <20191121093030.GA19142@sol> From: Bartosz Golaszewski Date: Thu, 21 Nov 2019 11:03:32 +0100 Message-ID: Subject: Re: [libgpiod] [PATCH 11/19] API: add support for SET_CONFIG To: Kent Gibson Cc: Bartosz Golaszewski , linux-gpio Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Sender: linux-gpio-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-gpio@vger.kernel.org czw., 21 lis 2019 o 10:30 Kent Gibson napisa=C5=82(a= ): > > On Thu, Nov 21, 2019 at 09:46:07AM +0100, Bartosz Golaszewski wrote: > > czw., 21 lis 2019 o 08:46 Kent Gibson napisa=C5= =82(a): > > > > > > On Thu, Nov 21, 2019 at 08:13:42AM +0100, Bartosz Golaszewski wrote: > > > > czw., 21 lis 2019 o 01:34 Kent Gibson napisa= =C5=82(a): > > > > > > > > > > On Wed, Nov 20, 2019 at 04:18:24PM +0100, Bartosz Golaszewski wro= te: > > > > > > =C5=9Br., 20 lis 2019 o 15:36 Kent Gibson napisa=C5=82(a): > > > > > > > > > > > > > > On Wed, Nov 20, 2019 at 03:18:36PM +0100, Bartosz Golaszewski= wrote: > > > > > > > > =C5=9Br., 20 lis 2019 o 15:13 Kent Gibson napisa=C5=82(a): > > > > > > > > > > > > > > > > > > On Wed, Nov 20, 2019 at 03:08:57PM +0100, Bartosz Golasze= wski wrote: > > > > > > > > > > =C5=9Br., 20 lis 2019 o 14:59 Kent Gibson napisa=C5=82(a): > > > > > > > > > > > > > > > > > > > > > > On Wed, Nov 20, 2019 at 12:00:45PM +0100, Bartosz Gol= aszewski wrote: > > > > > > > > > > > > wt., 19 lis 2019 o 16:53 Kent Gibson napisa=C5=82(a): > > > > > > > > > > > > > > > > > > > > > > > > > > On Mon, Nov 18, 2019 at 10:48:25PM +0800, Kent Gi= bson wrote: > > > > > > > > > > > > > > On Mon, Nov 18, 2019 at 02:52:04PM +0100, Barto= sz Golaszewski > > > > > > > > > > > > > > > > + > > > > > > > > > > > > > > > > +int gpiod_line_set_flags_bulk(struct gpiod= _line_bulk *bulk, int flags) > > > > > > > > > > > > > > > > +{ > > > > > > > > > > > > > > > > + struct gpiod_line *line; > > > > > > > > > > > > > > > > + int values[GPIOD_LINE_BULK_MAX_LINE= S]; > > > > > > > > > > > > > > > > + unsigned int i; > > > > > > > > > > > > > > > > + int direction; > > > > > > > > > > > > > > > > + > > > > > > > > > > > > > > > > + line =3D gpiod_line_bulk_get_line(b= ulk, 0); > > > > > > > > > > > > > > > > + if (line->as_is) { > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Can you explain the purpose of this as_is fie= ld? I'm not sure this is > > > > > > > > > > > > > > > really needed. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > It is there for gpiod_set_flags, which has to p= opulate the direction > > > > > > > > > > > > > > flags in the SET_CONFIG ioctl. The existing lin= e->direction is > > > > > > > > > > > > > > either input or output. It is drawn from GPIOL= INE_FLAG_IS_OUT, so > > > > > > > > > > > > > > as-is is gets mapped to input. > > > > > > > > > > > > > > I didn't want to change the existing line->dire= ction, and adding the > > > > > > > > > > > > > > as-is seemed clearer than adding another flavou= r of direction that > > > > > > > > > > > > > > contained all three. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Hmmm, I think I see what you were getting at - th= e line->direction is the > > > > > > > > > > > > > direction from the kernel, so it doesn't hurt to = use that value to set the > > > > > > > > > > > > > corresponding request flags - even if the origina= l request was as-is?? > > > > > > > > > > > > > > > > > > > > > > > > > > If that is the case then the line->as_is can be d= ropped throughout. > > > > > > > > > > > > > > > > > > > > > > > > > > Kent. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Yes, this is what I was thinking. Just need to make= sure the value > > > > > > > > > > > > from the kernel is up-to-date. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > So fail if needs_update? > > > > > > > > > > > > > > > > > > > > > > Kent. > > > > > > > > > > > > > > > > > > > > I'd say: do an implicit update before setting config. > > > > > > > > > > > > > > > > > > > > > > > > > > > > So gpiod_line_update if needs_update, and fail if that fa= ils? > > > > > > > > > > > > > > > > > > Kent. > > > > > > > > > > > > > > > > Without the if - needs_update is only set if an implicit up= date fails > > > > > > > > in line_maybe_update(). But in this case we need to be sure= , so do it > > > > > > > > unconditionally. > > > > > > > > > > > > > > > > > > > > > > Given that line_maybe_update is called at the end of request = creation, and > > > > > > > whenever set_config is called, how can line->direction be inc= onsistent > > > > > > > with the kernel state - as long as needs_update is false? > > > > > > > > > > > > > > > > > > > I don't think we should call line_maybe_update() on set_config(= ) - in > > > > > > this case we should call gpiod_line_update() and fail in set_co= nfig() > > > > > > if it fails. > > > > > > > > > > > > I hope that's clearer. > > > > > > > > > > > > > > > > Not really. I was already shaky on the needs_update and I'm gett= ing more > > > > > confused about the overall needs_update handling policy by the mi= nute. > > > > > > > > > > > > > Yeah it's not optimal. If you have better ideas on how to handle th= e > > > > fact that the kernel can't really notify us about the changes in > > > > line's flags introduced by other processes - I'll be more than glad= to > > > > give them a try. At some point I was thinking about another ioctl() > > > > that - for a requested line - would return a file descriptor which > > > > would emit events when a line changes - for instance, it's requeste= d > > > > by someone else or its direction is changed etc. > > > > > > > > > > I didn't realise it was possible for a requested line's flags to be > > > changed by other processes. Quite the opposite - I thought that was = one > > > of the reasons for GPIOD was to allow the userspace to prevent other = from > > > processes messing with requested lines. > > > > > > > Ugh, sorry, was writing it before coffee. I was thinking about a > > non-requested line. Something like lineinfo ioctl() but returning an > > fd notifying about changes. Maybe we could even consider having > > lineinfo2 ioctl() which would be extended with this functionality - > > not only would it fill the relevant structure but also pass a new fd > > for notification about changes. > > > > Whew - that makes more sense. Had me worried there. > > Not sure how useful an async info ioctl would be. Couldn't you build > something equivalent in userspace with the existing API - as long as you > don't mind the daemon holding the line, and so having to control the > line via the daemon. You want to be able to monitor without requesting > the line? > I'm not sure if I was expressing myself clearly enough: a hypothetical daemon calls LINEINFO ioctl(). Now a different program or kernel driver requests this line. The daemon is not up-to-date on its state unless it polls the line all the time. If a user now asks the daemon about this line's state - it will be given outdated info. Listening on this fd would allow us to be informed about such changes immediately. > I'm still puzzled as to when the existing info ioctl could fail on a > requested line - which is when needs_update gets set in > line_maybe_update(). Hardware being unplugged? > If the ioctl() can fail, then we're obligated to check the return value. As you say: unplugging the device is a good example - it may be a GPIO expander on an HID device (e.g. Silicon Labs CP2112) that can be easily disconnected from USB. Bart > Cheers, > Kent.