[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20241004104610.GD1310185@kernel.org>
Date: Fri, 4 Oct 2024 11:46:10 +0100
From: Simon Horman <horms@...nel.org>
To: MD Danish Anwar <danishanwar@...com>
Cc: Jakub Kicinski <kuba@...nel.org>, robh@...nel.org,
jan.kiszka@...mens.com, dan.carpenter@...aro.org,
diogo.ivo@...mens.com, andrew@...n.ch, pabeni@...hat.com,
edumazet@...gle.com, davem@...emloft.net,
linux-kernel@...r.kernel.org, netdev@...r.kernel.org,
linux-arm-kernel@...ts.infradead.org, srk@...com,
Vignesh Raghavendra <vigneshr@...com>,
Roger Quadros <rogerq@...nel.org>
Subject: Re: [PATCH net] net: ti: icssg-prueth: Fix race condition for VLAN
table access
On Fri, Oct 04, 2024 at 10:25:05AM +0530, MD Danish Anwar wrote:
>
>
> On 04/10/24 6:11 am, Jakub Kicinski wrote:
> > On Thu, 3 Oct 2024 16:29:40 +0530 MD Danish Anwar wrote:
> >> diff --git a/drivers/net/ethernet/ti/icssg/icssg_prueth.h b/drivers/net/ethernet/ti/icssg/icssg_prueth.h
> >> index bba6da2e6bd8..9a33e9ed2976 100644
> >> --- a/drivers/net/ethernet/ti/icssg/icssg_prueth.h
> >> +++ b/drivers/net/ethernet/ti/icssg/icssg_prueth.h
> >> @@ -296,6 +296,7 @@ struct prueth {
> >> bool is_switchmode_supported;
> >> unsigned char switch_id[MAX_PHYS_ITEM_ID_LEN];
> >> int default_vlan;
> >> + spinlock_t vtbl_lock; /* Lock for vtbl in shared memory */
> >
> > This needs to be kdoc, otherwise:
> >
> > drivers/net/ethernet/ti/icssg/icssg_prueth.h:301: warning: Function parameter or struct member 'vtbl_lock' not described in 'prueth'
>
> Hi Jakub,
>
> Removing the documentation from here and keeping it in kdoc results in
> below checkpatch,
>
> CHECK: spinlock_t definition without comment
> #69: FILE: drivers/net/ethernet/ti/icssg/icssg_prueth.h:300:
> + spinlock_t vtbl_lock;
>
>
> What should be done here? Should I,
>
> 1. Move the documentation to kdoc - This is will result in checkpatch
> 2. Keep the documentation in kdoc as well as inline - This will result
> in no warnings but duplicate documentation which I don't think is good.
>
> I was not sure which one takes more precedence check patch or kdoc, thus
> put it inline thinking fixing checkpatch might have more weightage.
>
> Let me know what should be done here.
FWIIW, my preference would be for option 2.
I think it is important that Kernel doc is accurate, as it can end
up incorporated in documentation. And moreover, what is the point
if it is missing bits?
I feel less strongly about the checkpatch bit, but it does seem
to be worthwhile following that practice too.
Maybe you can avoid duplication by making the two location document
different aspects of the field. Or maybe that is silly 🤷
Powered by blists - more mailing lists