[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <qnjiwkrqnwyz65nieioq2lt2kaauj2xqvddq5ba7ajrkmk7rky@hik3pexv7er7>
Date: Sun, 16 Jun 2024 18:04:27 +0200
From: Wolfram Sang <wsa+renesas@...g-engineering.com>
To: Linus Walleij <linus.walleij@...aro.org>
Cc: Arnd Bergmann <arnd@...db.de>, Bartosz Golaszewski <brgl@...ev.pl>,
Linux-Renesas <linux-renesas-soc@...r.kernel.org>, Jonathan Corbet <corbet@....net>,
Kent Gibson <warthog618@...il.com>, linux-doc@...r.kernel.org, linux-kernel@...r.kernel.org,
"open list:GPIO SUBSYSTEM" <linux-gpio@...r.kernel.org>
Subject: Re: [PATCH v9 1/1] gpio: add sloppy logic analyzer using polling
> I second this opinion. The logic analyzer does in my mind
> classify as a GPIO debugging feature. Surely someone
> debugging anything connected to GPIO, such as a key or
> MMC card detect or whatever could use this feature to see
> what is going on on that line.
Okay, with that picture I can see where your argument is coming from.
However, making it a gpiolib debugging feature will surely raise
expectations. And it is not only the non-equi-distant sampling. The
script trying to isolate a CPU core tries really hard but is still hacky
IMO. It has to disable the RCU stall detector and will likely interfere
with your CPUSET configuration if you have one. As I always said, it is
last resort debugging.
As I write this, I start to wonder if this should be really upstream or
if I just keep it as a branch in my repo. Maybe it is just too hackish
to be supported mainline?
Download attachment "signature.asc" of type "application/pgp-signature" (834 bytes)
Powered by blists - more mailing lists