[PATCH] coresight: etm4x: Don't bother the user with nonessential log message

[Suzuki K Poulose]

On 03/08/2023 18:24, James Clark wrote:
> 
> 
> On 03/08/2023 17:34, Suzuki K Poulose wrote:
>> On 03/08/2023 10:08, James Clark wrote:
>>>
>>>
>>> On 03/08/2023 07:22, Tian Tao wrote:
>>>> Each cpu will print the following log when initializing
>>>> ETM "coresight etm1: CPU1: etm v4.5 initialized", if there are a lot
>>>> of cpus, e.g. 128. there will be a screen full of this log. replace
>>>> dev_info with dev_dbg prints only when needed.
>>>>
>>>> Signed-off-by: Tian Tao <tiantao6 at hisilicon.com>
>>>> ---
>>>>    drivers/hwtracing/coresight/coresight-etm4x-core.c | 2 +-
>>>>    1 file changed, 1 insertion(+), 1 deletion(-)
>>>>
>>>> diff --git a/drivers/hwtracing/coresight/coresight-etm4x-core.c
>>>> b/drivers/hwtracing/coresight/coresight-etm4x-core.c
>>>> index 7e307022303a..7b51e8594fd5 100644
>>>> --- a/drivers/hwtracing/coresight/coresight-etm4x-core.c
>>>> +++ b/drivers/hwtracing/coresight/coresight-etm4x-core.c
>>>> @@ -2033,7 +2033,7 @@ static int etm4_add_coresight_dev(struct
>>>> etm4_init_arg *init_arg)
>>>>          etmdrvdata[drvdata->cpu] = drvdata;
>>>>    -    dev_info(&drvdata->csdev->dev, "CPU%d: %s v%d.%d initialized\n",
>>>> +    dev_dbg(&drvdata->csdev->dev, "CPU%d: %s v%d.%d initialized\n",
>>>>             drvdata->cpu, type_name, major, minor);
>>>>          if (boot_enable) {
>>>
>>> Hi Tian,
>>>
>>> Do you think it's worth keeping a single info printout as well as the
>>> per-cpu dbg one? I'm thinking that the only way to get these messages
>>> now is to boot with debug printing on, and that is quite noisy. Because
>>> it's too late to use debugfs to enable just coresight debug messages
>>> after booting. So something like this:
>>>
>>>     dev_info_once(&drvdata->csdev->dev, "%s v%d.%d initialized\n",
>>
>> I would rather remove all of this. One can always check the devices
>> at /sys/bus/coresight/devices/etmX.
>>
> 
> It might be nice to keep the log message if you think something can go
> wrong between here and registering in sysfs as it might give a clue. If
> not, yeah I suppose we can remove them.

That message comes up after all the sysfs entries are created via
coresight_register(). The only thing that may not be reflected in the 
sysfs is the connection links, which turns up as and when the other 
devices are probed. So, there is nothing that can go wrong from the
CoreSight ETMv4x side.

Suzuki