All of lore.kernel.org
 help / color / mirror / Atom feed
From: Cristian Marussi <cristian.marussi@arm.com>
To: Sudeep Holla <sudeep.holla@arm.com>
Cc: Cristian Marussi <cristian.marussi@arm.com>,
	Luke Parkin <luke.parkin@arm.com>,
	linux-kernel@vger.kernel.org,
	linux-arm-kernel@lists.infradead.org, arm-scmi@vger.kernel.org
Subject: Re: [PATCH v4 4/5] firmware: arm_scmi: Create debugfs files for counts
Date: Wed, 31 Jul 2024 13:54:57 +0100	[thread overview]
Message-ID: <Zqo0IWvrdUUNIAGL@pluto> (raw)
In-Reply-To: <Zqow0WOz0eVf6fwv@bogus>

On Wed, Jul 31, 2024 at 01:40:49PM +0100, Sudeep Holla wrote:
> On Wed, Jul 31, 2024 at 01:32:00PM +0100, Cristian Marussi wrote:
> > On Wed, Jul 31, 2024 at 01:11:22PM +0100, Sudeep Holla wrote:
> > > On Tue, Jul 30, 2024 at 10:33:41AM +0100, Luke Parkin wrote:
> > > > Create debugfs files for the metrics in the debug_counters array
> > > > 
> > > > Signed-off-by: Luke Parkin <luke.parkin@arm.com>
> > > > ---
> > > > v3->v4
> > > > Use new locations for debug array
> > > > Use counter instead of stats
> > > > v2->v3
> > > > Add extra statistics also added in v3
> > > > v1->v2
> > > > Only create stats pointer if stats are enabled
> > > > Move stats debugfs creation into a seperate helper function
> > > > ---
> > > >  drivers/firmware/arm_scmi/driver.c | 38 ++++++++++++++++++++++++++++++
> > > >  1 file changed, 38 insertions(+)
> > > > 
> > > > diff --git a/drivers/firmware/arm_scmi/driver.c b/drivers/firmware/arm_scmi/driver.c
> > > > index 5acd3d324def..ec6434692d1a 100644
> > > > --- a/drivers/firmware/arm_scmi/driver.c
> > > > +++ b/drivers/firmware/arm_scmi/driver.c
> > > > @@ -2847,6 +2847,41 @@ static int scmi_device_request_notifier(struct notifier_block *nb,
> > > >  	return NOTIFY_OK;
> > > >  }
> > > >  
> > > > +static void scmi_debugfs_counters_setup(struct scmi_debug_info *dbg,
> > > > +					struct dentry *trans)
> > > > +{
> > > > +	struct dentry *counters;
> > > > +
> > > > +	counters = debugfs_create_dir("counters", trans);
> > > > +
> > > > +	debugfs_create_atomic_t("sent_ok", 0400, counters,
> > > > +				&dbg->counters[SENT_OK]);
> > > > +	debugfs_create_atomic_t("sent_fail", 0400, counters,
> > > > +				&dbg->counters[SENT_FAIL]);
> > > > +	debugfs_create_atomic_t("sent_fail_polling_unsupported", 0400, counters,
> > > > +				&dbg->counters[SENT_FAIL_POLLING_UNSUPPORTED]);
> > > > +	debugfs_create_atomic_t("sent_fail_channel_not_found", 0400, counters,
> > > > +				&dbg->counters[SENT_FAIL_CHANNEL_NOT_FOUND]);
> > > > +	debugfs_create_atomic_t("response_ok", 0400, counters,
> > > > +				&dbg->counters[RESPONSE_OK]);
> > > > +	debugfs_create_atomic_t("notif_ok", 0400, counters,
> > > > +				&dbg->counters[NOTIF_OK]);
> > > > +	debugfs_create_atomic_t("dlyd_resp_ok", 0400, counters,
> > > > +				&dbg->counters[DLYD_RESPONSE_OK]);
> > > > +	debugfs_create_atomic_t("xfers_resp_timeout", 0400, counters,
> > > > +				&dbg->counters[XFERS_RESPONSE_TIMEOUT]);
> > > > +	debugfs_create_atomic_t("response_polled_ok", 0400, counters,
> > > > +				&dbg->counters[RESPONSE_POLLED_OK]);
> > > > +	debugfs_create_atomic_t("err_msg_unexpected", 0400, counters,
> > > > +				&dbg->counters[ERR_MSG_UNEXPECTED]);
> > > > +	debugfs_create_atomic_t("err_msg_invalid", 0400, counters,
> > > > +				&dbg->counters[ERR_MSG_INVALID]);
> > > > +	debugfs_create_atomic_t("err_msg_nomem", 0400, counters,
> > > > +				&dbg->counters[ERR_MSG_NOMEM]);
> > > > +	debugfs_create_atomic_t("err_protocol", 0400, counters,
> > > > +				&dbg->counters[ERR_PROTOCOL]);
> > > 
> > > Just curious and wonder if we can keep all these read-only and have another
> > > debugfs file which is write only to just reset the counters ?
> > > 
> > > Cristian,
> > > 
> > > Thoughts ? Or am I missing somthing ?
> > 
> > Do you mean creating a bunch of additional reset_sent_ok
> > reset_<your_counters> that are just WO and used to reset each single
> > counter ?
> 
> No, not at all. Sorry if my response meant that.
> 
> > (...I suppose because a global WO reset-all is already there...)
> >
> 
> Indeed, I hadn't seen it carefully. Do we really need per counter reset ?
> For me one global reset all with all files read-only should suffice.
> Let me know if and why you think otherwise.

Well we don't need strictly anything since it is a debug/devel feat, it
just seemed handy to have a way to just reset one of the counters you are
actively working on, if you think about a testing or live devel
scenario...but it is not really needed and I have no strong opinion
about this...it was just a nice to have I asked Luke to add last minute...

...patch 5 indeed already adds also a global WO reset, beside switching all
the above counters to RW...it is just a matter to drop those RO->RW perms
changes in patch 5.

Thanks,
Cristian

  reply	other threads:[~2024-07-31 12:55 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-07-30  9:33 [PATCH v4 0/5] Add Per-transport SCMI debug statistics Luke Parkin
2024-07-30  9:33 ` [PATCH v4 1/5] firmware: arm_scmi: Remove superfluous handle_to_scmi_info Luke Parkin
2024-07-30  9:33 ` [PATCH v4 2/5] firmware: arm_scmi: Add support for tracking metrics Luke Parkin
2024-07-30 16:21   ` Cristian Marussi
2024-07-30  9:33 ` [PATCH v4 3/5] firmware: arm_scmi: Track basic SCMI metrics Luke Parkin
2024-07-30 16:22   ` Cristian Marussi
2024-07-30  9:33 ` [PATCH v4 4/5] firmware: arm_scmi: Create debugfs files for counts Luke Parkin
2024-07-30 16:23   ` Cristian Marussi
2024-07-31 12:11   ` Sudeep Holla
2024-07-31 12:32     ` Cristian Marussi
2024-07-31 12:40       ` Sudeep Holla
2024-07-31 12:54         ` Cristian Marussi [this message]
2024-07-31 13:00           ` Luke Parkin
2024-07-30  9:33 ` [PATCH v4 5/5] firmware: arm_scmi: Reset counters Luke Parkin
2024-07-30 16:37   ` Cristian Marussi
2024-07-30 16:41 ` [PATCH v4 0/5] Add Per-transport SCMI debug statistics Cristian Marussi

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=Zqo0IWvrdUUNIAGL@pluto \
    --to=cristian.marussi@arm.com \
    --cc=arm-scmi@vger.kernel.org \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=luke.parkin@arm.com \
    --cc=sudeep.holla@arm.com \
    /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.