All of lore.kernel.org
 help / color / mirror / Atom feed
From: Suzuki.Poulose@arm.com (Suzuki K Poulose)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH 4/5] coresight: Add better messages for coresight_timeout
Date: Wed, 1 Jun 2016 10:34:52 +0100	[thread overview]
Message-ID: <574EAC3C.5040504@arm.com> (raw)
In-Reply-To: <1464717537.14627.39.camel@perches.com>

On 31/05/16 18:58, Joe Perches wrote:
> On Tue, 2016-05-31 at 12:57 +0100, Suzuki K Poulose wrote:
>> When we encounter a timeout waiting for a status change via
>> coresight_timeout, the caller always print the offset which
>> was tried. This is pretty much useless as it doesn't specify
>> the bit position we wait for. Also, one needs to lookup the
>> TRM to figure out, what was wrong. This patch changes all
>> such error messages to print something more meaningful.
>
> trivia:
>
> Perhaps consistently using
> 	dev_err(dev, "timeout while waiting for %s\n", "<foo>");
> could make the object code a bit smaller.
>
>> diff --git a/drivers/hwtracing/coresight/coresight-etb10.c b/drivers/hwtracing/coresight/coresight-etb10.c
> []
>> @@ -184,8 +184,7 @@ static void etb_disable_hw(struct etb_drvdata *drvdata)
>>
>>   	if (coresight_timeout(drvdata->base, ETB_FFCR, ETB_FFCR_BIT, 0)) {
>>   		dev_err(drvdata->dev,
>> -			"timeout observed when probing at offset %#x\n",
>> -			ETB_FFCR);
>> +			"timeout while waiting for completion of Manual Flush\n");
>
> ie:
> 		dev_err(drvdata->dev,
> 			"timeout while waiting for %s\n",
> 			"completion of Manual Flush");
>
> but that depends on how many of these coresight
> files are compiled and linked.

Or we could move the timeout message to coresight_timeout(). The only disadvantage is
if a caller is OK with silent timeouts. How about :

int coresight_timeout(void *base, u32 offset, u32 bit, u32 val, char *info)

where the message can be suppressed if info == NULL ?

Mathieu, your thoughts ?

>
> There is a while/when usage difference in some of
> the output messages.

Right, I will fix them. This was a merged version of individual patches, hence
the changes.

Cheers
Suzuki

WARNING: multiple messages have this Message-ID (diff)
From: Suzuki K Poulose <Suzuki.Poulose@arm.com>
To: Joe Perches <joe@perches.com>, linux-arm-kernel@lists.infradead.org
Cc: mathieu.poirier@linaro.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH 4/5] coresight: Add better messages for coresight_timeout
Date: Wed, 1 Jun 2016 10:34:52 +0100	[thread overview]
Message-ID: <574EAC3C.5040504@arm.com> (raw)
In-Reply-To: <1464717537.14627.39.camel@perches.com>

On 31/05/16 18:58, Joe Perches wrote:
> On Tue, 2016-05-31 at 12:57 +0100, Suzuki K Poulose wrote:
>> When we encounter a timeout waiting for a status change via
>> coresight_timeout, the caller always print the offset which
>> was tried. This is pretty much useless as it doesn't specify
>> the bit position we wait for. Also, one needs to lookup the
>> TRM to figure out, what was wrong. This patch changes all
>> such error messages to print something more meaningful.
>
> trivia:
>
> Perhaps consistently using
> 	dev_err(dev, "timeout while waiting for %s\n", "<foo>");
> could make the object code a bit smaller.
>
>> diff --git a/drivers/hwtracing/coresight/coresight-etb10.c b/drivers/hwtracing/coresight/coresight-etb10.c
> []
>> @@ -184,8 +184,7 @@ static void etb_disable_hw(struct etb_drvdata *drvdata)
>>
>>   	if (coresight_timeout(drvdata->base, ETB_FFCR, ETB_FFCR_BIT, 0)) {
>>   		dev_err(drvdata->dev,
>> -			"timeout observed when probing at offset %#x\n",
>> -			ETB_FFCR);
>> +			"timeout while waiting for completion of Manual Flush\n");
>
> ie:
> 		dev_err(drvdata->dev,
> 			"timeout while waiting for %s\n",
> 			"completion of Manual Flush");
>
> but that depends on how many of these coresight
> files are compiled and linked.

Or we could move the timeout message to coresight_timeout(). The only disadvantage is
if a caller is OK with silent timeouts. How about :

int coresight_timeout(void *base, u32 offset, u32 bit, u32 val, char *info)

where the message can be suppressed if info == NULL ?

Mathieu, your thoughts ?

>
> There is a while/when usage difference in some of
> the output messages.

Right, I will fix them. This was a merged version of individual patches, hence
the changes.

Cheers
Suzuki

  reply	other threads:[~2016-06-01  9:34 UTC|newest]

Thread overview: 30+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-05-31 11:57 [PATCH 0/5] coresight: Miscellaneous fixes Suzuki K Poulose
2016-05-31 11:57 ` Suzuki K Poulose
2016-05-31 11:57 ` [PATCH 1/5] coresight: Fix NULL pointer dereference in _coresight_build_path Suzuki K Poulose
2016-05-31 11:57   ` Suzuki K Poulose
2016-05-31 17:39   ` Mathieu Poirier
2016-05-31 17:39     ` Mathieu Poirier
2016-05-31 11:57 ` [PATCH 2/5] coresight: etmv4: Fix ETMv4x peripheral ID table Suzuki K Poulose
2016-05-31 11:57   ` Suzuki K Poulose
2016-05-31 17:45   ` Mathieu Poirier
2016-05-31 17:45     ` Mathieu Poirier
2016-05-31 11:57 ` [PATCH 3/5] coresight: Fix csdev connections initialisation Suzuki K Poulose
2016-05-31 11:57   ` Suzuki K Poulose
2016-05-31 17:55   ` Mathieu Poirier
2016-05-31 17:55     ` Mathieu Poirier
2016-06-01  9:30     ` Suzuki K Poulose
2016-06-01  9:30       ` Suzuki K Poulose
2016-05-31 11:57 ` [PATCH 4/5] coresight: Add better messages for coresight_timeout Suzuki K Poulose
2016-05-31 11:57   ` Suzuki K Poulose
2016-05-31 17:57   ` Mathieu Poirier
2016-05-31 17:57     ` Mathieu Poirier
2016-05-31 17:58   ` Joe Perches
2016-05-31 17:58     ` Joe Perches
2016-06-01  9:34     ` Suzuki K Poulose [this message]
2016-06-01  9:34       ` Suzuki K Poulose
2016-06-01 15:15       ` Mathieu Poirier
2016-06-01 15:15         ` Mathieu Poirier
2016-05-31 11:57 ` [PATCH 5/5] coresight: Cleanup TMC status check Suzuki K Poulose
2016-05-31 11:57   ` Suzuki K Poulose
2016-05-31 18:01   ` Mathieu Poirier
2016-05-31 18:01     ` Mathieu Poirier

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=574EAC3C.5040504@arm.com \
    --to=suzuki.poulose@arm.com \
    --cc=linux-arm-kernel@lists.infradead.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.