Subject: Re: [EXT] Re: [PATCH v5 1/2] net: stmmac: add support for platform specific reset

From: Simon Horman <[email-masked]>
Date: Tue, 4 Apr 2023 11:34:11 +0200

On Mon, Apr 03, 2023 at 10:16:46PM +0000, Shenwei Wang wrote:
> 
> 
> > -----Original Message-----
> > From: Simon Horman <[email-masked]>
> > Sent: Monday, April 3, 2023 2:50 PM
> > To: Shenwei Wang <[email-masked]>
> > Cc: David S. Miller <[email-masked]>; Eric Dumazet
> > <[email-masked]>; Jakub Kicinski <[email-masked]>; Paolo Abeni
> > <[email-masked]>; Shawn Guo <[email-masked]>; Sascha Hauer
> > <[email-masked]>; Pengutronix Kernel Team <[email-masked]>;
> > Giuseppe Cavallaro <[email-masked]>; Alexandre Torgue
> > <[email-masked]>; Jose Abreu <[email-masked]>; Fabio
> > Estevam <[email-masked]>; dl-linux-imx <[email-masked]>; Maxime
> > Coquelin <[email-masked]>; Wong Vee Khee
> > <[email-masked]>; Kurt Kanzenbach <[email-masked]>; Mohammad
> > Athari Bin Ismail <[email-masked]>; Andrey Konovalov
> > <[email-masked]>; Jochen Henneberg <jh@henneberg-
> > systemdesign.com>; Tan Tee Min <[email-masked]>;
> > [email-masked]; [email-masked]; linux-stm32@st-
> > md-mailman.stormreply.com; [email-masked]
> > Subject: [EXT] Re: [PATCH v5 1/2] net: stmmac: add support for platform specific
> > reset
> > 
> > Caution: EXT Email
> > 
> > On Mon, Apr 03, 2023 at 10:24:07AM -0500, Shenwei Wang wrote:
> > > This patch adds support for platform-specific reset logic in the
> > > stmmac driver. Some SoCs require a different reset mechanism than the
> > > standard dwmac IP reset. To support these platforms, a new function
> > > pointer 'fix_soc_reset' is added to the plat_stmmacenet_data structure.
> > > The stmmac_reset in hwif.h is modified to call the 'fix_soc_reset'
> > > function if it exists. This enables the driver to use the
> > > platform-specific reset logic when necessary.
> > >
> > > Signed-off-by: Shenwei Wang <[email-masked]>
> > > ---
> > >  v5:
> > >   - add the missing __iomem tag in the stmmac_reset definition.
> > >
> > >  drivers/net/ethernet/stmicro/stmmac/hwif.c | 10 ++++++++++
> > > drivers/net/ethernet/stmicro/stmmac/hwif.h |  3 +--
> > >  include/linux/stmmac.h                     |  1 +
> > >  3 files changed, 12 insertions(+), 2 deletions(-)
> > >
> > > diff --git a/drivers/net/ethernet/stmicro/stmmac/hwif.c
> > > b/drivers/net/ethernet/stmicro/stmmac/hwif.c
> > > index bb7114f970f8..0eefa697ffe8 100644
> > > --- a/drivers/net/ethernet/stmicro/stmmac/hwif.c
> > > +++ b/drivers/net/ethernet/stmicro/stmmac/hwif.c
> > > @@ -87,6 +87,16 @@ static int stmmac_dwxlgmac_quirks(struct stmmac_priv
> > *priv)
> > >       return 0;
> > >  }
> > >
> > > +int stmmac_reset(struct stmmac_priv *priv, void __iomem *ioaddr) {
> > > +     struct plat_stmmacenet_data *plat = priv ? priv->plat : NULL;
> > 
> > Here the case where priv is NULL is handled.
> > 
> > > +
> > > +     if (plat && plat->fix_soc_reset)
> > > +             return plat->fix_soc_reset(plat, ioaddr);
> > > +
> > > +     return stmmac_do_callback(priv, dma, reset, ioaddr);
> > 
> > But this will dereference priv unconditionally.
> > 
> 
> The original macro implementation assumes that the priv pointer will not be NULL. However, adding 
> an extra condition check for priv in the stmmac_reset() function can ensure that the code is more 
> robust and secure.

But it seems to me that it is not safe because stmmac_do_callback
will dereference priv even if it is NULL.

So I think either the NULL case should be handled in a safe way.
Or there is no point in checking for it at all.