[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20200418153730.1e1d01ef@archlinux>
Date: Sat, 18 Apr 2020 15:37:30 +0100
From: Jonathan Cameron <jic23@...nel.org>
To: Dmitry Osipenko <digetx@...il.com>
Cc: Linus Walleij <linus.walleij@...aro.org>,
Hartmut Knaack <knaack.h@....de>,
Lars-Peter Clausen <lars@...afoo.de>,
Peter Meerwald-Stadler <pmeerw@...erw.net>,
linux-iio <linux-iio@...r.kernel.org>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
Thierry Reding <thierry.reding@...il.com>
Subject: Re: [PATCH v1] iio: magnetometer: ak8974: Silence deferred-probe
error
On Thu, 16 Apr 2020 20:35:56 +0300
Dmitry Osipenko <digetx@...il.com> wrote:
> 16.04.2020 19:51, Linus Walleij пишет:
> > On Thu, Apr 16, 2020 at 4:45 PM Dmitry Osipenko <digetx@...il.com> wrote:
> >> 16.04.2020 14:33, Linus Walleij пишет:
> >
> >>> This misses some important aspects of dev_dbg(), notably this:
> >>>
> >>> #if defined(CONFIG_DYNAMIC_DEBUG)
> >>> #define dev_dbg(dev, fmt, ...) \
> >>> dynamic_dev_dbg(dev, dev_fmt(fmt), ##__VA_ARGS__)
> >>> #elif defined(DEBUG)
> >>> #define dev_dbg(dev, fmt, ...) \
> >>> dev_printk(KERN_DEBUG, dev, dev_fmt(fmt), ##__VA_ARGS__)
> >>> #else
> >>> #define dev_dbg(dev, fmt, ...) \
> >>> ({ \
> >>> if (0) \
> >>> dev_printk(KERN_DEBUG, dev, dev_fmt(fmt), ##__VA_ARGS__); \
> >>> })
> >>> #endif
> >>>
> >>> If DEBUG is not defined the entire dev_dbg() message is enclodes in if (0)
> >>> and compiled out of the kernel, saving space. The above does not
> >>> fulfil that.
> >>
> >> Hello Linus,
> >>
> >> After some recent discussions in regards to the EPROBE_DEFER handling,
> >> Thierry Reding suggested the form which is used in my patch and we
> >> started to use it recently in the Tegra DRM driver [1]. The reason is
> >> that we don't want to miss any deferred-probe messages under any
> >> circumstances, for example like in a case of a disabled DYNAMIC_DEBUG.
> >
> > I have a hard time to accept this reasoning.
> >
> > Who doesn't feel that way about their subsystem? If you don't want
> > to miss the message under any circumstances then use dev_info().
> > Don't override the default behaviour of dev_dbg().
> >
> >> The debug messages are usually disabled in a release-build and when not
> >> a very experienced person hands you KMSG for diagnosing a problem, the
> >> KMSG is pretty much useless if error is hidden silently.
> >
> > So use dev_info().
> >
> >> By moving the message to a debug level, we reduce the noise in the KMSG
> >> because usually people look for a bold-red error messages. Secondly, we
> >> don't introduce an additional overhead to the kernel size since the same
> >> text is reused for all error conditions.
> >
> > dev_info() is not supposed to be an error message, it is supposed to
> > be information, so use that.
>
> Okay, I'll make a v2. Thank you for the review.
Ah I commented on this in v2 - now I see why you did it :)
Nope to dev_info. That will often spam normal logs and as Andy pointed
out for v2 that can be dozens of entries on a sophisticated board. Much
better to stick to dev_dbg but I'd like to see it done explicitly in the
form you mention with the if / else
Thanks,
Jonathan
Powered by blists - more mailing lists