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 09F6FC433DF for ; Tue, 9 Jun 2020 09:57:46 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id D8208207ED for ; Tue, 9 Jun 2020 09:57:45 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=baylibre-com.20150623.gappssmtp.com header.i=@baylibre-com.20150623.gappssmtp.com header.b="hvs/IFpk" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1728549AbgFIJ5o (ORCPT ); Tue, 9 Jun 2020 05:57:44 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:53042 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727098AbgFIJ5m (ORCPT ); Tue, 9 Jun 2020 05:57:42 -0400 Received: from mail-qk1-x744.google.com (mail-qk1-x744.google.com [IPv6:2607:f8b0:4864:20::744]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 045C6C05BD1E for ; Tue, 9 Jun 2020 02:57:40 -0700 (PDT) Received: by mail-qk1-x744.google.com with SMTP id b27so20142827qka.4 for ; Tue, 09 Jun 2020 02:57:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=baylibre-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=mSZ9Pf7BMHDh3WUE/xt0FmuEkxc1Vdz25gGMRgBtWPg=; b=hvs/IFpkcvVFV9C0DuVWpln5RNediRV7+SlNLZGIbWgMSdFuPGK70CEnXRvuVqiCPQ yEz0uxDZjlVw+OgyYdC5rQMURQocdeM1dcKoGVbveeOVW45aLBMd+LKdCjvyf0+U7pop Sv+Zo+H8eoCH+rONDcBcgGvxNF4AodAUCq+m7SWn3lCIe1T2HT81SjW3ryd/AFpkrtaT 5Wrmt5XSUiwS/Aj8HYtyDObXrego3RX3Y4NCKNNDkoN2bzxAnOCQr6G68ui1/BThRaca XgPEhB2hS00JxvtU+R6xXL4KLlSQh5TUSwuXq2qn+KTv/j8a95WcISYbssHxOzdzH5lv 5wKQ== 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=mSZ9Pf7BMHDh3WUE/xt0FmuEkxc1Vdz25gGMRgBtWPg=; b=YbLWwIPTpHJDg57ZdTpi+gCIppF83X3yBg+a+Ai2Q0XZ2LbnGxyrRi3nB2M8Sua8ox iPsKlDP56VKUkKcAQrs0ndzb294szLZJuUBbDbUmPMnZXkljCkyLLg+xICjKessbvHjK d3SMXsgPI7b49/rcOvv3IGXGoeNywyRRC7iMWn4hdP6VBQSCB6VQ8yaPUWMyEG0/U+sj xCzJCBvst7srV2tawqF5pfI6nw4VOm7SayodK9N7zWr9nTkvQHSov3JKPVfrBQx8hDIe F7Sj2YWuE7k/vYy31AKuZD3Im5qgJnjNQuMSq/z2AGlrhA0O/YlmrqcrnavJ0tAcEN4d KMMw== X-Gm-Message-State: AOAM530u7BBQJgid9zyrGCZNOrcwQ4xOPL8IP2r6Bi6J2ZlBdXIwrAfv jBivaM/BrQD6ppZiG/I0kFVwOawrV8CQKLg1NosC5Osf X-Google-Smtp-Source: ABdhPJxu6LS/DBVDrKsowqECfF6MhViQJW4MJiVqI/Gqv4K2dXJOO/xIxFFqQHdnBSnwNdXKJU2SU9BCvvkekboYeVo= X-Received: by 2002:a37:4f52:: with SMTP id d79mr26882586qkb.330.1591696659006; Tue, 09 Jun 2020 02:57:39 -0700 (PDT) MIME-Version: 1.0 References: <20200516064507.19058-1-warthog618@gmail.com> <20200604160006.GA5730@sol> <20200606015647.GA8099@sol> <20200609094338.GA16448@sol> In-Reply-To: <20200609094338.GA16448@sol> From: Bartosz Golaszewski Date: Tue, 9 Jun 2020 11:57:27 +0200 Message-ID: Subject: Re: [RFC PATCH] gpio: uapi: v2 proposal To: Kent Gibson Cc: Bartosz Golaszewski , LKML , linux-gpio , Linus Walleij 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 wt., 9 cze 2020 o 11:43 Kent Gibson napisa=C5=82(a): > > On Tue, Jun 09, 2020 at 10:03:42AM +0200, Bartosz Golaszewski wrote: > > sob., 6 cze 2020 o 03:56 Kent Gibson napisa=C5= =82(a): > > > > > > > [snip!] > > > > > > > > > > I'd say yes - consolidation and reuse of data structures is always > > > > good and normally they are going to be wrapped in some kind of > > > > low-level user-space library anyway. > > > > > > > > > > Ok, and I've changed the values field name to bitmap, along with the = change > > > to a bitmap type, so the stuttering is gone. > > > > > > And, as the change to bitmap substantially reduced the size of > > > gpioline_config, I now embed that in the gpioline_info instead of > > > duplicating all the other fields. The values field will be zeroed > > > when returned within info. > > > > > > > Could you post an example, I'm not sure I follow. > > > > The gpioline_info_v2 now looks like this: > > /** > * struct gpioline_info_v2 - Information about a certain GPIO line > * @name: the name of this GPIO line, such as the output pin of the line = on > * the chip, a rail or a pin header name on a board, as specified by the > * gpio chip, may be empty > * @consumer: a functional name for the consumer of this GPIO line as set > * by whatever is using it, will be empty if there is no current user but > * may also be empty if the consumer doesn't set this up > * @config: the configuration of the line. Note that the values field is > * always zeroed. > * @offset: the local offset on this GPIO device, fill this in when > * requesting the line information from the kernel > * @padding: reserved for future use > */ > struct gpioline_info_v2 { > char name[GPIO_MAX_NAME_SIZE]; > char consumer[GPIO_MAX_NAME_SIZE]; > struct gpioline_config config; > __u32 offset; > __u32 padding[GPIOLINE_INFO_V2_PAD_SIZE]; /* for future use */ > }; > > Previously that had all the fields from config - other than the values. > > When that is populated the config.values will always be zeroed. > We'll probably abstract this away in libgpiod and your Go library but for someone looking at the ABI it may be confusing because a zeroed values array is still valid. I don't have a better idea though. [snip!] > > > > > > And would it be useful for userspace to be able to influence the = size of > > > > > the event buffer (currently fixed at 16 events per line)? > > > > > > > > > > > > > Good question. I would prefer to not overdo it though. The event > > > > request would need to contain the desired kfifo size and we'd only > > > > allow to set it on request, right? > > > > > > > > > > Yeah, it would only be relevant if edge detection was set and, as per > > > edge detection itself, would only be settable via the request, not > > > via set_config. It would only be a suggestion, as the kfifo size get= s > > > rounded up to a power of 2 anyway. It would be capped - I'm open to > > > suggestions for a suitable max value. And the 0 value would mean use > > > the default - currently 16 per line. > > > > > > > This sounds good. How about 512 for max value for now and we can > > always increase it if needed. I don't think we should explicitly cap > > it though - let the user specify any value and just silently limit it > > to 512 in the kernel. > > > > It will be an internal cap only - no error if the user requests more. > I was thinking 1024, which corresponds to the maximum default - 16*64. > Yes, this sounds good too. Bart