[PATCH] coresight: etb: Remove simple announcement message

[PATCH] coresight: etb: Remove simple announcement message

[Mark Brown]

It's generally preferred that drivers not print initialisation messages on
startup that don't contain information gained at runtime such as specific
hardware revision information. This provides a small speedup on systems
with serial consoles and keeps the boot less noisy.

Signed-off-by: Mark Brown <broonie@kernel.org>
---
 drivers/hwtracing/coresight/coresight-etb10.c | 1 -
 1 file changed, 1 deletion(-)

diff --git a/drivers/hwtracing/coresight/coresight-etb10.c b/drivers/hwtracing/coresight/coresight-etb10.c
index 77d0f9c1118d..e34e34b8edfb 100644
--- a/drivers/hwtracing/coresight/coresight-etb10.c
+++ b/drivers/hwtracing/coresight/coresight-etb10.c
@@ -481,7 +481,6 @@ static int etb_probe(struct amba_device *adev, const struct amba_id *id)
 	if (ret)
 		goto err_misc_register;
 
-	dev_info(dev, "ETB initialized\n");
 	return 0;
 
 err_misc_register:
-- 
2.1.4

[PATCH] coresight: etb: Remove simple announcement message

[Mathieu Poirier]

On 20 May 2015 at 05:41, Mark Brown <broonie@kernel.org> wrote:
> It's generally preferred that drivers not print initialisation messages on
> startup that don't contain information gained at runtime such as specific
> hardware revision information. This provides a small speedup on systems
> with serial consoles and keeps the boot less noisy.
>
> Signed-off-by: Mark Brown <broonie@kernel.org>
> ---
>  drivers/hwtracing/coresight/coresight-etb10.c | 1 -
>  1 file changed, 1 deletion(-)
>
> diff --git a/drivers/hwtracing/coresight/coresight-etb10.c b/drivers/hwtracing/coresight/coresight-etb10.c
> index 77d0f9c1118d..e34e34b8edfb 100644
> --- a/drivers/hwtracing/coresight/coresight-etb10.c
> +++ b/drivers/hwtracing/coresight/coresight-etb10.c
> @@ -481,7 +481,6 @@ static int etb_probe(struct amba_device *adev, const struct amba_id *id)
>         if (ret)
>                 goto err_misc_register;
>
> -       dev_info(dev, "ETB initialized\n");

Linus Walleij started doing something interesting with the initial
printouts [1] and I think this is a better option than not printing
anything at all.

[1]. https://git.linaro.org/kernel/coresight.git/commitdiff/509133a2715367c2ec9f8026ff55a028d04cdae0?hp=0b81f7e469b846b1b56d19d4f8f1f476943856f6

>         return 0;
>
>  err_misc_register:
> --
> 2.1.4
>

[PATCH] coresight: etb: Remove simple announcement message

[Mark Brown]

On Fri, May 22, 2015 at 08:17:21AM -0600, Mathieu Poirier wrote:

> Linus Walleij started doing something interesting with the initial
> printouts [1] and I think this is a better option than not printing
> anything at all.

It's definitely better to print information we enumerate from hardware,
though I'm not 100% sure if AMBA does the right thing with matching here
(most of the buses ignore hardware IDs in favour of DT information if
things are bound via DT).
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 473 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20150522/08d720aa/attachment.sig>

[PATCH] coresight: etb: Remove simple announcement message

[Mathieu Poirier]

On 22 May 2015 at 10:33, Mark Brown <broonie@kernel.org> wrote:
> On Fri, May 22, 2015 at 08:17:21AM -0600, Mathieu Poirier wrote:
>
>> Linus Walleij started doing something interesting with the initial
>> printouts [1] and I think this is a better option than not printing
>> anything at all.
>
> It's definitely better to print information we enumerate from hardware,
> though I'm not 100% sure if AMBA does the right thing with matching here
> (most of the buses ignore hardware IDs in favour of DT information if
> things are bound via DT).

AMBA has been done properly - bypassing the initial ID lookup with the
"arm,primecell-periphid" binding only prevent the HW from being
accessed when the DT is parsed.  At driver init time the peripheral ID
from the DT is checked against the list of AMBA IDs supported by the
driver and fails if a match is not found.

One can always force things with the "driver-override" sysfs property
but that's another story.

[PATCH] coresight: etb: Remove simple announcement message

[Mark Brown]

It's generally preferred that drivers not print initialisation messages on
startup that don't contain information gained at runtime such as specific
hardware revision information. This provides a small speedup on systems
with serial consoles and keeps the boot less noisy.

Signed-off-by: Mark Brown <broonie@kernel.org>
---
 drivers/hwtracing/coresight/coresight-etb10.c | 1 -
 1 file changed, 1 deletion(-)

diff --git a/drivers/hwtracing/coresight/coresight-etb10.c b/drivers/hwtracing/coresight/coresight-etb10.c
index 92969dae739d..18c55d1c428c 100644
--- a/drivers/hwtracing/coresight/coresight-etb10.c
+++ b/drivers/hwtracing/coresight/coresight-etb10.c
@@ -481,7 +481,6 @@ static int etb_probe(struct amba_device *adev, const struct amba_id *id)
 	if (ret)
 		goto err_misc_register;
 
-	dev_info(dev, "ETB initialized\n");
 	return 0;
 
 err_misc_register:
-- 
2.7.0

[PATCH] coresight: etb: Remove simple announcement message

[Mathieu Poirier]

On 11 February 2016 at 05:50, Mark Brown <broonie@kernel.org> wrote:
> It's generally preferred that drivers not print initialisation messages on
> startup that don't contain information gained at runtime such as specific
> hardware revision information. This provides a small speedup on systems
> with serial consoles and keeps the boot less noisy.
>
> Signed-off-by: Mark Brown <broonie@kernel.org>
> ---
>  drivers/hwtracing/coresight/coresight-etb10.c | 1 -
>  1 file changed, 1 deletion(-)
>
> diff --git a/drivers/hwtracing/coresight/coresight-etb10.c b/drivers/hwtracing/coresight/coresight-etb10.c
> index 92969dae739d..18c55d1c428c 100644
> --- a/drivers/hwtracing/coresight/coresight-etb10.c
> +++ b/drivers/hwtracing/coresight/coresight-etb10.c
> @@ -481,7 +481,6 @@ static int etb_probe(struct amba_device *adev, const struct amba_id *id)
>         if (ret)
>                 goto err_misc_register;
>
> -       dev_info(dev, "ETB initialized\n");
>         return 0;

Didn't we touch base on that topic before?  I'm not against moving
forward with this but it has to be all or nothing - whether we remove
all the CS boot log message or they all stay.  Otherwise people could
mistakenly come to the conclusion that some of the CS components did
not boot properly.

ETB, funnel and TMCs don't output any useful HW related information
but tracers (ETMv3, PTM and ETMv4) actually do.

People concerned about boot time will definitely set their loglevel
accordingly on the kernel cmd line.  Otherwise we are likely talking
about developers interested in knowing what happened when their kernel
booted.

Thanks,
Mathieu

>
>  err_misc_register:
> --
> 2.7.0
>

[PATCH] coresight: etb: Remove simple announcement message

[Mark Brown]

On Fri, Feb 12, 2016 at 01:44:31PM -0700, Mathieu Poirier wrote:
> On 11 February 2016 at 05:50, Mark Brown <broonie@kernel.org> wrote:

> > -       dev_info(dev, "ETB initialized\n");
> >         return 0;

> Didn't we touch base on that topic before?  I'm not against moving

We did and you said that there was a patch pending which would change it
to print something useful but the patch still applies so I guess that
didn't happen.

> forward with this but it has to be all or nothing - whether we remove
> all the CS boot log message or they all stay.  Otherwise people could
> mistakenly come to the conclusion that some of the CS components did
> not boot properly.

> ETB, funnel and TMCs don't output any useful HW related information
> but tracers (ETMv3, PTM and ETMv4) actually do.

I think people are familiar enough with the general policy on this stuff
to be able to cope with this, it's certainly not something that's ever
come up with ASoC where we do have a similar multi-device structure.

> People concerned about boot time will definitely set their loglevel
> accordingly on the kernel cmd line.  Otherwise we are likely talking
> about developers interested in knowing what happened when their kernel
> booted.

That applies equally to all drivers so from that point of view we should
be doing something in the driver core - there is actually some logging
there that can be enabled, though it's not that widely used.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 473 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20160212/4aa128c5/attachment.sig>

[PATCH] coresight: etb: Remove simple announcement message

[Mathieu Poirier]

On 12 February 2016 at 14:54, Mark Brown <broonie@kernel.org> wrote:
> On Fri, Feb 12, 2016 at 01:44:31PM -0700, Mathieu Poirier wrote:
>> On 11 February 2016 at 05:50, Mark Brown <broonie@kernel.org> wrote:
>
>> > -       dev_info(dev, "ETB initialized\n");
>> >         return 0;
>
>> Didn't we touch base on that topic before?  I'm not against moving
>
> We did and you said that there was a patch pending which would change it
> to print something useful but the patch still applies so I guess that
> didn't happen.
>
>> forward with this but it has to be all or nothing - whether we remove
>> all the CS boot log message or they all stay.  Otherwise people could
>> mistakenly come to the conclusion that some of the CS components did
>> not boot properly.
>
>> ETB, funnel and TMCs don't output any useful HW related information
>> but tracers (ETMv3, PTM and ETMv4) actually do.
>
> I think people are familiar enough with the general policy on this stuff
> to be able to cope with this, it's certainly not something that's ever
> come up with ASoC where we do have a similar multi-device structure.

Ok - please send me another patch that removes the boot log messages
for  the TMC, funnel and TPIU drivers.  That way only the tracers
(ETMv3/4) get to keep their boot logs.

Thanks,
Mathieu

>
>> People concerned about boot time will definitely set their loglevel
>> accordingly on the kernel cmd line.  Otherwise we are likely talking
>> about developers interested in knowing what happened when their kernel
>> booted.
>
> That applies equally to all drivers so from that point of view we should
> be doing something in the driver core - there is actually some logging
> there that can be enabled, though it's not that widely used.