[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <CACRpkdZjSr_-EoZughRLaa83w-0Djj2hM=rqNe4RENudG4eizA@mail.gmail.com>
Date: Wed, 23 Mar 2022 21:44:21 +0100
From: Linus Walleij <linus.walleij@...aro.org>
To: Brian Norris <briannorris@...omium.org>
Cc: Andy Shevchenko <andy.shevchenko@...il.com>,
Bartosz Golaszewski <brgl@...ev.pl>,
"open list:GPIO SUBSYSTEM" <linux-gpio@...r.kernel.org>,
Jianqun Xu <jay.xu@...k-chips.com>,
Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH] gpio: Drop CONFIG_DEBUG_GPIO
On Tue, Mar 22, 2022 at 5:31 PM Brian Norris <briannorris@...omium.org> wrote:
> I'm also curious: does dynamic debug not suit you?
> https://www.kernel.org/doc/html/v4.19/admin-guide/dynamic-debug-howto.html
> TBH, I never remember its syntax, and it seems very easy to get wrong,
> so I often throw in #define's myself, if I want it foolproof. But I'm
> curious others thoughts too.
Dynamic debug almost always assume that the system comes up so you
can go in and enable it manually. What about problems during boot. Or
if the system doesn't even get to userspace?
GPIO and pin control can be critical system resources and the
platform may not boot completely or mount root as a result of some
problem you're debugging.
True, there are ways to pass arguments also on the command line
argument when the kernel boots.
Figuring out how the command line should
look to enable -DDEBUG at boot time on say drivers/pinctrl/intel/* is
a pretty horrific
exercise. Add to that using the boot loader interactively to type that
long argument in for every reboot.
In all such scenarios what people do is go into the Makefile
and add -DDEBUG to the CFLAGS as a hack instead, because it
is faster and persistent.
Adding that as an option in KConfig achieves the same thing, just
easier than hacking the Makefile.
Yours,
Linus Walleij
Powered by blists - more mailing lists