Received: by 2002:a25:8b91:0:0:0:0:0 with SMTP id j17csp2374855ybl; Mon, 20 Jan 2020 01:35:11 -0800 (PST) X-Google-Smtp-Source: APXvYqwAx0JO1yHfiARxcdYwnw2TSG6mvrzWJm94KyJxLaeRELjW8lkb6Ei1vwWZQO6uaJUYSIlF X-Received: by 2002:aca:6042:: with SMTP id u63mr12452124oib.76.1579512911279; Mon, 20 Jan 2020 01:35:11 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1579512911; cv=none; d=google.com; s=arc-20160816; b=aIoH1T00nOfeWN/Ljv1Tm6ahs8cIGs+AcW7yPUJbPdaEHk3ZCYi3iQ5V+k+CK413go Xdt03glopiAN7l7sfrLfTwfADVTvI2hLBws84msxrjGUAb4sqnfFLvPx2msPZN1liBdw MxSBHk043VqeVB8J1o2YmpdcHinm3xHUEhe7IM2grdewH8nfkuAj+Sze4ec3ajzIexXm fdf5n2LDRBGK1sCKz8ALk2rhC6TsxYaMr51Im1YgnPZ/iNzKTpjPLE0tudHjebbkcOEK dVqQtNdq/sLAYLE90JdKFY6PmUjKUoCb6HAA5hNvxVcRKaqGHUeGw45SqaVRPZioCMz6 5Qxg== 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; bh=4UGZULGX+YbThMmtUsP+6rz+ppDz5uP2ldQfl/P5Icg=; b=XZDc0idcrbYBhPw5BsMFmDMbxxHaDgF6qsOuJJqNj3J0ez4U4VM2PqvvqB5hiRlK9p xHeVZrvD5aoWEDd1Uh+lCH8G7oR65g5llNzlgFk4cA3lD8SYXXaudxkp6Q5o7jOsJFK5 AKBkcVI0YeA7J374K3n3n9qGOpEBe+Qm7+ME0md5+lQpLrlBQNJpOEZ/wac4uqnPqcpQ 8iQK72V++RO5p/UrFcV1DFggQsW3ZbpG2aq8AhTJ7Z4jshiiNfCZ7+AyADKXmCRQgOFX 3RAYxMLn/9Fw5C0lY65lOUveqdiotbgu6pI5ffj5m+OP1Gr5E/tjAU74Z+QdwGg7oKZF Bj1w== ARC-Authentication-Results: i=1; mx.google.com; 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 e6si19623362otq.217.2020.01.20.01.34.59; Mon, 20 Jan 2020 01:35:11 -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; 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 S1726752AbgATJeG (ORCPT + 99 others); Mon, 20 Jan 2020 04:34:06 -0500 Received: from mail-oi1-f194.google.com ([209.85.167.194]:41769 "EHLO mail-oi1-f194.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726075AbgATJeF (ORCPT ); Mon, 20 Jan 2020 04:34:05 -0500 Received: by mail-oi1-f194.google.com with SMTP id i1so27950956oie.8; Mon, 20 Jan 2020 01:34:05 -0800 (PST) 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=4UGZULGX+YbThMmtUsP+6rz+ppDz5uP2ldQfl/P5Icg=; b=r9BsWJI3/T3ZajffuGYjSoUFTwBkinpE6cXRPJHgDYA9/V+s95oNwuxSMPkQ/4cWRj ZaO1SmpOmS3irAImPnfWNoPnAvu+Rowsz/IfJmN/ZmJ2BhOYckAckM4YIRTPmFDO0uGp EU5jhrVSxHGkBAGYOnbK1WxS3RANycKdJex8Ezu+w7bGXf8G0OmXRp8KiQBpQ/KtgPlT uXP6z8GZhTZOFtZQ698I5XmxKeYh3vQkn2ExZYvB8By/iq6oVezMqNWAXL51HDdCD/QX AMxtTqoUDTIVRBXkFyOKnbPk7rN8QXKlqjSHJZ2ByGxrg+Xn91wVGS5WoYc+2bnY3QwS u0SQ== X-Gm-Message-State: APjAAAXpFc9fimVSH61Kcc6KZFG+NkCsZ4PaHNdcQH3O6dAAoU8e46Qr Xv5RMuH+KdUh5QESUmpq0WKAqYtag6xEkDlPQ7k= X-Received: by 2002:aca:1a06:: with SMTP id a6mr11682717oia.148.1579512844618; Mon, 20 Jan 2020 01:34:04 -0800 (PST) MIME-Version: 1.0 References: <20191127084253.16356-1-geert+renesas@glider.be> <20200118014632.GA14644@lxhi-065.adit-jv.com> In-Reply-To: <20200118014632.GA14644@lxhi-065.adit-jv.com> From: Geert Uytterhoeven Date: Mon, 20 Jan 2020 10:33:53 +0100 Message-ID: Subject: Re: [PATCH v3 0/7] gpio: Add GPIO Aggregator/Repeater To: Eugeniu Rosca Cc: Linus Walleij , Bartosz Golaszewski , Jonathan Corbet , Rob Herring , Mark Rutland , Harish Jenny K N , Alexander Graf , Peter Maydell , Paolo Bonzini , Phil Reid , Marc Zyngier , Christoffer Dall , Magnus Damm , "open list:GPIO SUBSYSTEM" , "open list:DOCUMENTATION" , "open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS" , Linux-Renesas , Linux Kernel Mailing List , QEMU Developers , Eugeniu Rosca 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 Hi Eugeniu, On Sat, Jan 18, 2020 at 2:46 AM Eugeniu Rosca wrote: > On Wed, Nov 27, 2019 at 09:42:46AM +0100, Geert Uytterhoeven wrote: > > - Create aggregators: > > > > $ echo e6052000.gpio 19,20 \ > > > /sys/bus/platform/drivers/gpio-aggregator/new_device > The only unexpected thing is seeing below messages (where gpiochip99 and > gpiochip22 are inexisting gpiochip names, mistakenly provided on command > line prior to passing the correct name): > > root@rcar-gen3:~# echo gpiochip6 12-13 > /sys/bus/platform/drivers/gpio-aggregator/new_device > [ 915.572905] gpio-aggregator gpio-aggregator.0: cannot find GPIO chip gpiochip99, deferring > [ 915.584224] gpio-aggregator gpio-aggregator.2: cannot find GPIO chip gpiochip99, deferring > [ 915.865281] gpio-aggregator gpio-aggregator.29: cannot find GPIO chip gpiochip22, deferring > > Obviously, in the above case, due to a typo in the names, the gpio > chips will never be found, no matter how long gpio-aggregator defers Indeed, that is expected behavior: you have created platform devices referring to resources that are not available. > their probing. Unfortunately, the driver will continuously emit those > messages, upon each successfully created/aggregated gpiochip. I built That is expected behavior, too: every time the driver core manages to bind a device to a driver, it will retry all previously deferred probes, in the hope they can be satisfied by the just bound device. Note that you can destroy these bogus devices, using e.g. # echo gpio-aggregator.0 > \ /sys/bus/platform/drivers/gpio-aggregator/delete_device > gpio-aggregator as a loadable module, if that's relevant. Modular or non-modular shouldn't matter w.r.t. this behavior. Although unloading the module should get rid of the cruft. > Another comment is that, while the series _does_ allow specifying > gpio lines in the DTS (this would require a common compatible string > in gpio_aggregator_dt_ids[] and in the DTS node) and while those lines > are indeed exposed to userspace, based on my testing, these same gpio > lines are marked as "used/reserved" by the kernel. This means that > operating on those gpio pins from userspace will not be possible. > For instance, gpioget/gpioset return "Device or resource busy": > > gpioget: error reading GPIO values: Device or resource busy > gpioset: error setting the GPIO line values: Device or resource busy > > I guess Harish will be unhappy about that, as his expectation was that > upon merging gpio-aggregator with gpio-inverter, he will be able to > describe GPIO polarity and names in DTS without "hogging" the pins. > Perhaps this can be supplemented via an add-on patch later on? When aggregating GPIO lines, the original GPIO lines are indeed marked used/reserved, so you cannot use them from userspace. However, you are expected to use them through the newly created virtual gpiochip representing the aggregated GPIO lines. You can try this using the "door" example in Documentation/admin-guide/gpio/gpio-aggregator.rst, after replacing gpio2 {19,20} by gpio6 {12,13} to suit your H3ULCB. > For the whole series (leaving the above findings to your discretion): > > Reviewed-by: Eugeniu Rosca > Tested-by: Eugeniu Rosca Thanks! Gr{oetje,eeting}s, Geert -- Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org In personal conversations with technical people, I call myself a hacker. But when I'm talking to journalists I just say "programmer" or something like that. -- Linus Torvalds