Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18;
Subject: Re: [PATCH v1] iio: magnetometer: ak8974: Silence deferred-probe
 error
To:     Jonathan Cameron <jic23@kernel.org>,
        Andy Shevchenko <andy.shevchenko@gmail.com>
Cc:     Linus Walleij <linus.walleij@linaro.org>,
        Hartmut Knaack <knaack.h@gmx.de>,
        Lars-Peter Clausen <lars@metafoo.de>,
        Peter Meerwald-Stadler <pmeerw@pmeerw.net>,
        linux-iio <linux-iio@vger.kernel.org>,
        "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
        Thierry Reding <thierry.reding@gmail.com>
References: <20200414222713.32660-1-digetx@gmail.com>
 <CACRpkdY_J8e127etFFYkoxLDDkc334Xgg8ZbapdU36oGsaZ08g@mail.gmail.com>
 <e08c487c-5c2a-3172-7c9c-0e7d2cd51769@gmail.com>
 <CACRpkdbMF4=-g2ic_SKgOkd6kfgKJqZ2UxCRaoXJjq0EiEn+pw@mail.gmail.com>
 <26f96265-c699-66aa-ec70-becd868bb795@gmail.com>
 <20200418153730.1e1d01ef@archlinux>
From:   Dmitry Osipenko <digetx@gmail.com>
Message-ID: <33f96a81-dc45-6eb0-5f88-317a421c04b2@gmail.com>
Date:   Sat, 18 Apr 2020 17:49:05 +0300
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101
 Thunderbird/68.7.0
MIME-Version: 1.0
In-Reply-To: <20200418153730.1e1d01ef@archlinux>
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: 8bit
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk

18.04.2020 17:37, Jonathan Cameron пишет:
> On Thu, 16 Apr 2020 20:35:56 +0300
> Dmitry Osipenko <digetx@gmail.com> wrote:
> 
>> 16.04.2020 19:51, Linus Walleij пишет:
>>> On Thu, Apr 16, 2020 at 4:45 PM Dmitry Osipenko <digetx@gmail.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

Alright, I'll make a v3.