[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID:
<MWHPR1801MB1918AD55E5A7E2B2CE91CC98D37A2@MWHPR1801MB1918.namprd18.prod.outlook.com>
Date: Thu, 25 Jan 2024 05:03:15 +0000
From: Ratheesh Kannoth <rkannoth@...vell.com>
To: Simon Horman <horms@...nel.org>
CC: Subbaraya Sundeep Bhatta <sbhatta@...vell.com>,
"netdev@...r.kernel.org"
<netdev@...r.kernel.org>,
"linux-kernel@...r.kernel.org"
<linux-kernel@...r.kernel.org>,
Sunil Kovvuri Goutham <sgoutham@...vell.com>,
"davem@...emloft.net" <davem@...emloft.net>,
"edumazet@...gle.com"
<edumazet@...gle.com>,
"kuba@...nel.org" <kuba@...nel.org>,
"pabeni@...hat.com" <pabeni@...hat.com>,
Geethasowjanya Akula
<gakula@...vell.com>,
Hariprasad Kelam <hkelam@...vell.com>,
Suman Ghosh
<sumang@...vell.com>
Subject: RE: [EXT] Re: [PATCH net] octeontx2-af: Initialize bitmap arrays.
> From: Simon Horman <horms@...nel.org>
> Subject: Re: [EXT] Re: [PATCH net] octeontx2-af: Initialize bitmap arrays.
> I do understand that devm_free() exists, and there are cases where it makes
> sense. But I don't think devm_ is buying us anything here.
For graceful Error handling, this API makes sense.
> 1. Use kcalloc() instead of devm_kcalloc() 2. Not change kfree() calls to
> devm_kfree()
>
> Then you will end up with a smaller diff than the current patch.
> And it will address the problem described in the patch description.
ACK.
Powered by blists - more mailing lists