Re: [PATCH net-next 01/13] octeontx2-af: npc: cn20k: Index management

[Simon Horman]

On Fri, Jan 09, 2026 at 08:10:43AM +0530, Ratheesh Kannoth wrote:
> On 2026-01-08 at 23:23:57, Simon Horman (horms@xxxxxxxxxx) 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.

...