From: Simon Horman <horms@kernel.org>
To: Ratheesh Kannoth <rkannoth@marvell.com>
Cc: netdev@vger.kernel.org, linux-kernel@vger.kernel.org,
sgoutham@marvell.com, davem@davemloft.net, edumazet@google.com,
kuba@kernel.org, pabeni@redhat.com, andrew+netdev@lunn.ch,
sumang@marvell.com
Subject: Re: [PATCH net-next 01/13] octeontx2-af: npc: cn20k: Index management
Date: Tue, 13 Jan 2026 13:09:13 +0000 [thread overview]
Message-ID: <aWZD-bDON-wzfQHe@horms.kernel.org> (raw)
In-Reply-To: <aWBqq9UKWD5ewKpA@rkannoth-OptiPlex-7090>
On Fri, Jan 09, 2026 at 08:10:43AM +0530, Ratheesh Kannoth wrote:
> On 2026-01-08 at 23:23:57, Simon Horman (horms@kernel.org) wrote:
> > On Mon, Jan 05, 2026 at 08:02:42AM +0530, Ratheesh Kannoth wrote:
> >
> > > + if (strlen(t1) < 3) {
> > > + pr_err("%s:%d Bad Token %s=%s\n",
> > > + __func__, __LINE__, t1, t2);
> > > + goto err;
> > > + }
> > > +
> > > + if (t1[0] != '[' || t1[strlen(t1) - 1] != ']') {
> > > + pr_err("%s:%d Bad Token %s=%s\n",
> > > + __func__, __LINE__, t1, t2);
> >
> > Hi Ratheesh,
> >
> > FWIIW, I would advocate slightly more descriptive and thus unique
> > error messages
> ACK.
>
> >and dropping __func__ and __LINE__ from logs,
> > here and elsewhere.
> ACK.
>
> >
> > The __func__, and in particular __LINE__ information will only
> > tend to change as the file is up dated, and so any debugging will
> > need to know the source that the kernel was compiled from.
> ACK.
>
> >
> > And I'd say that given the state of debugging functionality in the kernel -
> > e..g dynamic tracepoints - this is not as useful as it may seem at first.
> Since these represent valid error cases, they should be logged by default.
> Relying on dynamic trace points would require the customer to recompile the
> kernel and retest, which could lead to significant debugging delays and
> multiple rounds of communication.
FTR, I think that logging them is reasonable, it's just the __func__ and
__LINE__ portions that I question the usefulness of.
Also, in my experience, recompiling is not necessary to use dynamic trace
points. But YMMV.
...
next prev parent reply other threads:[~2026-01-13 13:09 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-01-05 2:32 [PATCH net-next 00/13] NPC HW block support for cn20k Ratheesh Kannoth
2026-01-05 2:32 ` [PATCH net-next 01/13] octeontx2-af: npc: cn20k: Index management Ratheesh Kannoth
2026-01-05 15:15 ` Andrew Lunn
2026-01-06 3:29 ` Ratheesh Kannoth
2026-01-06 8:15 ` Kalesh Anakkur Purayil
2026-01-06 9:32 ` Ratheesh Kannoth
2026-01-08 17:53 ` Simon Horman
2026-01-09 2:40 ` Ratheesh Kannoth
2026-01-13 13:09 ` Simon Horman [this message]
2026-01-05 2:32 ` [PATCH net-next 02/13] octeontx2-af: npc: cn20k: KPM profile changes Ratheesh Kannoth
2026-01-05 2:32 ` [PATCH net-next 03/13] octeontx2-af: npc: cn20k: Add default profile Ratheesh Kannoth
2026-01-05 2:32 ` [PATCH net-next 04/13] ocetontx2-af: npc: cn20k: MKEX profile support Ratheesh Kannoth
2026-01-05 2:32 ` [PATCH net-next 05/13] octeontx2-af: npc: cn20k: Allocate default MCAM indexes Ratheesh Kannoth
2026-01-05 2:32 ` [PATCH net-next 06/13] octeontx2-af: npc: cn20k: Use common APIs Ratheesh Kannoth
2026-01-05 2:32 ` [PATCH net-next 07/13] octeontx2-af: npc: cn20k: Prepare for new SoC Ratheesh Kannoth
2026-01-05 2:32 ` [PATCH net-next 08/13] octeontx2-af: npc: cn20k: Add new mailboxes for CN20K silicon Ratheesh Kannoth
2026-01-05 2:32 ` [PATCH net-next 09/13] octeontx2-af: npc: cn20k: virtual index support Ratheesh Kannoth
2026-01-05 2:32 ` [PATCH net-next 10/13] octeontx2-af: npc: cn20k: Allocate MCAM entry for flow installation Ratheesh Kannoth
2026-01-05 2:32 ` [PATCH net-next 11/13] octeontx2-pf: cn20k: Add TC rules support Ratheesh Kannoth
2026-01-05 2:32 ` [PATCH net-next 12/13] octeontx2-af: npc: cn20k: add debugfs support Ratheesh Kannoth
2026-01-05 2:32 ` [PATCH net-next 13/13] octeontx-af: npc: Use common structures Ratheesh Kannoth
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=aWZD-bDON-wzfQHe@horms.kernel.org \
--to=horms@kernel.org \
--cc=andrew+netdev@lunn.ch \
--cc=davem@davemloft.net \
--cc=edumazet@google.com \
--cc=kuba@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=netdev@vger.kernel.org \
--cc=pabeni@redhat.com \
--cc=rkannoth@marvell.com \
--cc=sgoutham@marvell.com \
--cc=sumang@marvell.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox