Re: [PATCH v2] adb: properly mark continued kernel messages

[Michael Ellerman]

Andreas Schwab  writes:

> Use pr_cont where appropriate, and switch to pr_foo throughout.
> Additionally, lower messages in adb_probe_task to debug level.
>
> Signed-off-by: Andreas Schwab 
> ---
>  drivers/macintosh/adb.c| 24 +---
>  drivers/macintosh/adbhid.c | 56 
> +++---
>  2 files changed, 39 insertions(+), 41 deletions(-)
>
> diff --git a/drivers/macintosh/adb.c b/drivers/macintosh/adb.c
> index 226179b975..5abc265383 100644
> --- a/drivers/macintosh/adb.c
> +++ b/drivers/macintosh/adb.c
> @@ -206,18 +206,17 @@ static int adb_scan_bus(void)
>   }
>  
>   /* Now fill in the handler_id field of the adb_handler entries. */
> - printk(KERN_DEBUG "adb devices:");
> + pr_debug("adb devices:\n");

Unfortunately pr_debug() is not directly equivalent to printk(KERN_DEBUG).
The latter always prints at DEBUG level, the former prints at DEBUG
level if it is enabled via dynamic debug, or if DEBUG is #defined in the
source.

So in general using pr_debug() means the messages won't be printed,
unless a user takes some action to enable it.

Perhaps in this case that's actually what we want to do, but if so we
should call it out in the change log.

cheers

Re: [PATCH v2] adb: properly mark continued kernel messages

[Andreas Schwab]

On Nov 30 2016, David Laight  wrote:

> Doesn't pr_cont() have its own major problem - garbled messages if
> there are concurrent writers?
> So it is best avoided if at all possible.

You are free to submit a followup patch the rework the messaging.  My
patch is a strict improvement.

Andreas.

-- 
Andreas Schwab, sch...@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

RE: [PATCH v2] adb: properly mark continued kernel messages

[David Laight]

From: Andreas Schwab
> Sent: 28 November 2016 20:29
> Use pr_cont where appropriate, and switch to pr_foo throughout.
> Additionally, lower messages in adb_probe_task to debug level.

Doesn't pr_cont() have its own major problem - garbled messages if
there are concurrent writers?
So it is best avoided if at all possible.

David