Received-SPF: pass (google.com: domain of linux-kernel+bounces-214856-linux.lists.archive=gmail.com@vger.kernel.org designates 2604:1380:4601:e00::3 as permitted sender) client-ip=2604:1380:4601:e00::3;
Feedback-ID: i56a14606:Fastmail
User-Agent: Cyrus-JMAP/3.11.0-alpha0-515-g87b2bad5a-fm-20240604.001-g87b2bad5
Precedence: bulk
MIME-Version: 1.0
Message-Id: <3bb9b39c-c15f-49e3-987b-26cd47e05f3e@app.fastmail.com>
In-Reply-To: 
 <slpwvai5q24qwymh7nktihvykmlhi5j3nhqjxruxb6yacruu47@27b7rhykw2f3>
References: <20240610112700.80819-2-wsa+renesas@sang-engineering.com>
 <CAMRc=MfZ11U+kAh1+K=DxtJ=QL+cY7Q_sBN4sQDF-RNgjpV0QA@mail.gmail.com>
 <jvnvx7a4pn6evrp5ehfrt4qsiuprq6ogvrue2a3uupwtydmgcm@2rvat7ibvgb4>
 <CAMRc=Mc4__0zzJZG3BPnmbua88SLuEbX=Wk=EZnKH5HQvB+JPg@mail.gmail.com>
 <CACRpkda==5S75Bw6F3ZLUmf7kwgi_JkByiizR=m-61nrMDWuvQ@mail.gmail.com>
 <ce1d8150-c595-44d5-b19a-040920481709@app.fastmail.com>
 <CAMRc=McpRjQO8mUrOA4bU_YqO8Tc9-Ujytfy1fcjGUEgH9NW0A@mail.gmail.com>
 <CACRpkdYtLDA3518uSYiTpu1PJuqNErHr9YMAKuar0CeFbfECPA@mail.gmail.com>
 <CAMRc=Mem6HN13FOA_Ru8zC-GqGGLTsQiktLWs5bN4JD1aM3gHQ@mail.gmail.com>
 <a7463c6e-2801-4d0e-b723-fc1cf77a04ed@app.fastmail.com>
 <slpwvai5q24qwymh7nktihvykmlhi5j3nhqjxruxb6yacruu47@27b7rhykw2f3>
Date: Fri, 14 Jun 2024 13:58:46 +0200
From: "Arnd Bergmann" <arnd@arndb.de>
To: "Wolfram Sang" <wsa+renesas@sang-engineering.com>
Cc: "Bartosz Golaszewski" <brgl@bgdev.pl>,
 "Linus Walleij" <linus.walleij@linaro.org>,
 Linux-Renesas <linux-renesas-soc@vger.kernel.org>,
 "Jonathan Corbet" <corbet@lwn.net>, "Kent Gibson" <warthog618@gmail.com>,
 linux-doc@vger.kernel.org, linux-kernel@vger.kernel.org,
 "open list:GPIO SUBSYSTEM" <linux-gpio@vger.kernel.org>
Subject: Re: [PATCH v9 1/1] gpio: add sloppy logic analyzer using polling
Content-Type: text/plain

On Fri, Jun 14, 2024, at 12:03, Wolfram Sang wrote:
> Hi Arnd, everyone,
>
>> I could imagine treating both gpio-virtuser and this code as
>> a gpiolib extension rather than a consumer (which is usually
>> part of some other subsystem's driver).
>
> I have difficulties seeing this. For the analyzer, at least. It does not
> extend gpiolib in a way another consumer could make use of it?

That's the same as the chardev support in gpiolib: it doesn't
provide functionality to in-kernel consumers but does give
an interface to userspace.

Arguably, integrating the logic analyzer into the chardev
device itself would make sense from an interface, as you
could define it as ioctls and mmap instead of the debugfs
interface.

Of course we don't want to make it a first-class interface
because of the reasons you explain in the cover letter,
but it would totally make sense to me to call it a
debugging feature of libgpio instead of calling it a
standalone driver.

     Arnd