[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID:
<PH0PR18MB44744DCAE48DA4AAE1082A1DDE19A@PH0PR18MB4474.namprd18.prod.outlook.com>
Date: Sun, 20 Aug 2023 04:12:12 +0000
From: Hariprasad Kelam <hkelam@...vell.com>
To: Jakub Kicinski <kuba@...nel.org>
CC: "netdev@...r.kernel.org" <netdev@...r.kernel.org>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
"davem@...emloft.net" <davem@...emloft.net>,
Sunil Kovvuri Goutham
<sgoutham@...vell.com>,
Geethasowjanya Akula <gakula@...vell.com>,
Jerin
Jacob Kollanukkaran <jerinj@...vell.com>,
Linu Cherian
<lcherian@...vell.com>,
Subbaraya Sundeep Bhatta <sbhatta@...vell.com>,
Naveen Mamindlapalli <naveenm@...vell.com>,
"edumazet@...gle.com"
<edumazet@...gle.com>,
"pabeni@...hat.com" <pabeni@...hat.com>
Subject: Re: [net-next Patch 4/5] octeontx2-af: replace generic error codes
> ----------------------------------------------------------------------
> On Thu, 17 Aug 2023 16:53:56 +0530 Hariprasad Kelam wrote:
> > currently, if any netdev is not mapped to the MAC block(cgx/rpm)
> > requests MAC feature, AF driver returns a generic error like -EPERM.
> > This patch replaces generic error codes with driver-specific error
> > codes for better debugging
>
> The custom error codes are not liked upstream, they make much harder for
> people who don't work on the driver to refactor it.
>
> If you want debugging isn't it better to add a tracepoint to the checks?
Hari>> These error codes are added in AF mailbox handlers, user space tools like ethool ,tc won't see these since these are between pf netdev and AF. During netdev driver probe/open calls, it requests AF driver to configure different hardware blocks MAC/network etc. If there is any error instead of getting EPERM, we will get block specific error codes like LMAC_AF_ERR_INVALID_PARAM, NIX_AF_ERR_PARAM etc.
Thanks,
Hariprasad k
> --
> pw-bot: cr
Powered by blists - more mailing lists