On 6/12/23 10:42, Rob Herring wrote: > On Sun, Jun 11, 2023 at 6:48 AM Frank Rowand <frowand.list@xxxxxxxxx> wrote: >> >> On 6/11/23 07:39, Frank Rowand wrote: >>> On 6/9/23 08:47, Rob Herring wrote: >>>> On Mon, Jun 5, 2023 at 6:53 AM Bartosz Golaszewski <brgl@xxxxxxxx> wrote: >>>>> >>>>> From: Bartosz Golaszewski <bartosz.golaszewski@xxxxxxxxxx> >>>>> >>>>> Drivers should be silent when they work correctly. There's no reason to >>>>> emit info messages when GPIO lines are hogged. Demote the message to >>>>> debug. >>>>> >>>>> Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@xxxxxxxxxx> >>>>> Suggested-by: Kent Gibson <warthog618@xxxxxxxxx> >>>>> --- >>>>> drivers/gpio/gpiolib.c | 2 +- >>>>> drivers/of/unittest.c | 16 ++++++++-------- >>>>> 2 files changed, 9 insertions(+), 9 deletions(-) >>>>> >>>>> diff --git a/drivers/gpio/gpiolib.c b/drivers/gpio/gpiolib.c >>>>> index a7220e04a93e..e4515bda8915 100644 >>>>> --- a/drivers/gpio/gpiolib.c >>>>> +++ b/drivers/gpio/gpiolib.c >>>>> @@ -4243,7 +4243,7 @@ int gpiod_hog(struct gpio_desc *desc, const char *name, >>>>> /* Mark GPIO as hogged so it can be identified and removed later */ >>>>> set_bit(FLAG_IS_HOGGED, &desc->flags); >>>>> >>>>> - gpiod_info(desc, "hogged as %s%s\n", >>>>> + gpiod_dbg(desc, "hogged as %s%s\n", >>>>> (dflags & GPIOD_FLAGS_BIT_DIR_OUT) ? "output" : "input", >>>>> (dflags & GPIOD_FLAGS_BIT_DIR_OUT) ? >>>>> (dflags & GPIOD_FLAGS_BIT_DIR_VAL) ? "/high" : "/low" : ""); >>>>> diff --git a/drivers/of/unittest.c b/drivers/of/unittest.c >>>>> index 2191c0136531..0060334a98a7 100644 >>>>> --- a/drivers/of/unittest.c >>>>> +++ b/drivers/of/unittest.c >>>>> @@ -1849,19 +1849,19 @@ static void __init of_unittest_overlay_gpio(void) >>>>> * driver is registered >>>>> */ >>>>> >>>>> - EXPECT_BEGIN(KERN_INFO, >>>>> + EXPECT_BEGIN(KERN_DEBUG, >>>>> "gpio-<<int>> (line-B-input): hogged as input\n"); >>>> >>>> As debug messages are normally off, I think you can just remove these. >>> >>> This patch is an example of exactly why the message level is the first parameter >>> passed to EXPECT_*(). The test results are then _always_ valid, not just >>> _normally_. >> >> One should never say never. One should never say always. :-) >> >> Yes, there is still the exception where debug can be enabled independently >> for drivers/gpio/gpiolib.c vs for drivers/of/unittest.c. And dynamic >> debug can make things even more wonky. > > If we turned on debug messages for drivers/of/, the unittest would be > hopelessly broken. > > Debug messages are special compared to all the other levels as they > are normally off whereas the rest are always on. For the unittest we > should assume they are off. Sorry, I wasn't clear enough in my last email. My intent in that email is to essentially agree with what you say here - if debug is enabled then we are in a special world where the person who enabled debug has to deal with all of the side effects and consequences of enabling debug. -Frank > > Rob