All of lore.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 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.