[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <ba71422a-e7b0-a5d2-d5d6-d0016c896f28@amd.com>
Date: Wed, 24 May 2023 15:25:26 -0500
From: "Limonciello, Mario" <mario.limonciello@....com>
To: Andy Shevchenko <andy.shevchenko@...il.com>,
"Rafael J. Wysocki" <rafael@...nel.org>
Cc: hdegoede@...hat.com, linus.walleij@...aro.org,
linux-acpi@...r.kernel.org, linux-kernel@...r.kernel.org,
linux-gpio@...r.kernel.org, platform-driver-x86@...r.kernel.org,
linux-pm@...r.kernel.org, Shyam-sundar.S-k@....com,
Basavaraj.Natikar@....com
Subject: Re: [PATCH v2 3/4] pinctrl: amd: Use pm_pr_dbg to show debugging
messages
On 5/24/2023 2:57 PM, Andy Shevchenko wrote:
> On Wed, May 24, 2023 at 9:28 PM Rafael J. Wysocki <rafael@...nel.org> wrote:
>> On Tue, May 23, 2023 at 6:55 PM <andy.shevchenko@...il.com> wrote:
>>> Mon, May 22, 2023 at 03:00:32PM -0500, Mario Limonciello kirjoitti:
> ...
>
>>>> - dev_dbg(&gpio_dev->pdev->dev,
>>>> - "GPIO %d is active: 0x%x",
>>>> - irqnr + i, regval);
>>>> + pm_pr_dbg("GPIO %d is active: 0x%x",
>>>> + irqnr + i, regval);
>>> Regression 1: The device is now omitted from the output.
>> Right.
>>
>>> Regression 2: See https://stackoverflow.com/a/43957671/2511795
>> Care to elaborate? I'm not sure what you mean exactly.
> dev_dbg has 3 cases how it prints its content:
> 1/ With dynamic debug when it's enabled.
> 2/ With -DDEBUG if it's defined for the certain file(s) in the Makefile.
> 3/ No print.
>
> pm_pr_dbg relies on CONFIG_PM_SLEEP_DEBUG, pm_debug_messages_on and
> not on -DDEBUG. I haven't checked all relations between those 3, but
> it seems to me that DEBUG is not equivalent to the others.
> CONFIG_PM_SLEEP_DEBUG=n prevents printing with the dynamic debug on.
>
> OTOH I dunno how this is relevant to the functionality of the driver
> in question. Maybe it's okay to have such changes.
The main reason for this debug statement in the first
place was for debugging sources of spurious wakeups.
As the statement is in the interrupt handler, turning
it on at "runtime" usually makes for a very noisy kernel
log because things like I2C touchpad will fire interrupts
constantly.
Powered by blists - more mailing lists