On Fri, Mar 11, 2022 at 12:09 AM Brian Norris <briannorris@xxxxxxxxxxxx> wrote: > > CONFIG_DEBUG_GPIO has existed since the introduction of gpiolib, but its > Kconfig description and motivation seem to have been off-base for quite > some time. > > Description: it says nothing about enabling extra printk()s. But -DDEBUG > does just that; it turns on every dev_dbg()/pr_debug() that would > otherwise be silent. > > Purpose: might_sleep() and WARN_ON() should have very low overhead, and > anyway, there's a separate CONFIG_DEBUG_ATOMIC_SLEEP for the > might_sleep() overhead. > > Additionally, the conflated purpose (extra debug checks, and extra > printing) makes for a mixed bag for users. In particular, some drivers > can be extra-spammy with -DDEBUG -- e.g., with the Rockchip GPIO driver > getting moved out of drivers/pinctrl/ in commit 936ee2675eee > ("gpio/rockchip: add driver for rockchip gpio"), now some dev_dbg() > calls are enabled in its IRQ handler. > > Altogether, it seems like CONFIG_DEBUG_GPIO isn't serving any good > purpose and should just be removed. It can be supplanted by dynamic > debug (which post-dates gpiolib) and atomic-debug facilities. > > Signed-off-by: Brian Norris <briannorris@xxxxxxxxxxxx> > --- > I like it. It's true we don't see many of those DEBUG constructs anymore nowadays and overhead for might_sleep() and WARN_ON() is negligible. Applied, thanks! Bart