public inbox for netdev@vger.kernel.org
 help / color / mirror / Atom feed
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.

...

  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