From: Michael Ellerman
> Sent: 28 April 2017 07:34
...
> Not sure what you mean. You can enable pr_debug()s individually, by
> function, by module, by file, or for the whole kernel.
It is sort of a shame that you can't turn pr_info() off in the same way.
David
On Fri, 2017-04-28 at 16:34 +1000, Michael Ellerman wrote:
> > > If there's non-verbose debug that we think would be useful to
> > > differentiate from verbose then those could be pr_debug() - which means
> > > they'll be jump labelled off in most production kernels, but still able
> > > to be enab
Benjamin Herrenschmidt writes:
> On Fri, 2017-04-28 at 13:07 +1000, Michael Ellerman wrote:
>> Benjamin Herrenschmidt writes:
>>
>> > The existing verbose debug code doesn't build when enabled.
>>
>> So why don't we convert all the DBG_VERBOSE() to pr_devel()?
>
> pr_devel provides a bunch of
On Fri, 2017-04-28 at 13:07 +1000, Michael Ellerman wrote:
> Benjamin Herrenschmidt writes:
>
> > The existing verbose debug code doesn't build when enabled.
>
> So why don't we convert all the DBG_VERBOSE() to pr_devel()?
pr_devel provides a bunch of debug at init/setup/mask/unmask etc... but
Benjamin Herrenschmidt writes:
> The existing verbose debug code doesn't build when enabled.
So why don't we convert all the DBG_VERBOSE() to pr_devel()?
If there's non-verbose debug that we think would be useful to
differentiate from verbose then those could be pr_debug() - which means
they'l
The existing verbose debug code doesn't build when enabled.
This fixes it and generally improves the output to make it
more useful.
Signed-off-by: Benjamin Herrenschmidt
---
arch/powerpc/sysdev/xive/common.c | 37 ++---
1 file changed, 26 insertions(+), 11 deleti
