From: Russell King - ARM Linux admin <linux@armlinux.org.uk>
To: Nicolas Ferre <nicolas.ferre@microchip.com>
Cc: andrew@lunn.ch, michal.simek@xilinx.com,
Parshuram Thombare <pthombar@cadence.com>,
netdev@vger.kernel.org, linux-kernel@vger.kernel.org,
davem@davemloft.net, Santiago.Esteban@microchip.com,
harini.katakam@xilinx.com, kuba@kernel.org,
Claudiu.Beznea@microchip.com,
linux-arm-kernel@lists.infradead.org
Subject: Re: [PATCH] net: macb: fix NULL dereference due to no pcs_config method
Date: Thu, 5 Nov 2020 15:48:56 +0000 [thread overview]
Message-ID: <20201105154856.GN1551@shell.armlinux.org.uk> (raw)
In-Reply-To: <6873cf12-456b-c121-037b-d2c5a6138cb3@microchip.com>
On Thu, Nov 05, 2020 at 04:22:18PM +0100, Nicolas Ferre wrote:
> On 05/11/2020 at 15:37, Parshuram Thombare wrote:
> > This patch fixes NULL pointer dereference due to NULL pcs_config
> > in pcs_ops.
> >
> > Fixes: e4e143e26ce8 ("net: macb: add support for high speed interface")
>
> What is this tag? In linux-next? As patch is not yet in Linus' tree, you
> cannot refer to it like this.
>
> > Reported-by: Nicolas Ferre <Nicolas.Ferre@microchip.com>
> > Link: https://lkml.org/lkml/2020/11/4/482
>
> You might need to change this to a "lore" link:
> https://lore.kernel.org/netdev/2db854c7-9ffb-328a-f346-f68982723d29@microchip.com/
>
> > Signed-off-by: Parshuram Thombare <pthombar@cadence.com>
>
> This fix looks a bit weird to me. What about proposing a patch to Russell
> like the chunk that you already identified in function
> phylink_major_config()?
No thanks. macb is currently the only case where a stub implementation
for pcs_config() is required, which only occurs because the only
appropriate protocol supported there is SGMII and not 1000base-X as
well.
> > ---
> > drivers/net/ethernet/cadence/macb_main.c | 17 +++++++++++++++--
> > 1 file changed, 15 insertions(+), 2 deletions(-)
> >
> > diff --git a/drivers/net/ethernet/cadence/macb_main.c b/drivers/net/ethernet/cadence/macb_main.c
> > index b7bc160..130a5af 100644
> > --- a/drivers/net/ethernet/cadence/macb_main.c
> > +++ b/drivers/net/ethernet/cadence/macb_main.c
> > @@ -633,6 +633,15 @@ static void macb_pcs_an_restart(struct phylink_pcs *pcs)
> > /* Not supported */
> > }
> >
> > +static int macb_pcs_config(struct phylink_pcs *pcs,
> > + unsigned int mode,
> > + phy_interface_t interface,
> > + const unsigned long *advertising,
> > + bool permit_pause_to_mac)
> > +{
> > + return 0;
> > +}
>
> Russell, is the requirement for this void function intended?
In response to v3 of the patch on 21st October, I said, and I quote:
I think all that needs to happen is a pcs_ops for the non-10GBASE-R
mode which moves macb_mac_pcs_get_state() and macb_mac_an_restart()
to it, and implements a stub pcs_config(). So it should be simple
to do.
Obviously, my advice was not followed, I didn't spot the lack of it
in v4 (sorry), and the result is the NULL pointer oops.
--
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTP is here! 40Mbps down 10Mbps up. Decent connectivity at last!
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
WARNING: multiple messages have this Message-ID (diff)
From: Russell King - ARM Linux admin <linux@armlinux.org.uk>
To: Nicolas Ferre <nicolas.ferre@microchip.com>
Cc: Parshuram Thombare <pthombar@cadence.com>,
kuba@kernel.org, linux-arm-kernel@lists.infradead.org,
netdev@vger.kernel.org, Claudiu.Beznea@microchip.com,
Santiago.Esteban@microchip.com, andrew@lunn.ch,
davem@davemloft.net, linux-kernel@vger.kernel.org,
harini.katakam@xilinx.com, michal.simek@xilinx.com
Subject: Re: [PATCH] net: macb: fix NULL dereference due to no pcs_config method
Date: Thu, 5 Nov 2020 15:48:56 +0000 [thread overview]
Message-ID: <20201105154856.GN1551@shell.armlinux.org.uk> (raw)
In-Reply-To: <6873cf12-456b-c121-037b-d2c5a6138cb3@microchip.com>
On Thu, Nov 05, 2020 at 04:22:18PM +0100, Nicolas Ferre wrote:
> On 05/11/2020 at 15:37, Parshuram Thombare wrote:
> > This patch fixes NULL pointer dereference due to NULL pcs_config
> > in pcs_ops.
> >
> > Fixes: e4e143e26ce8 ("net: macb: add support for high speed interface")
>
> What is this tag? In linux-next? As patch is not yet in Linus' tree, you
> cannot refer to it like this.
>
> > Reported-by: Nicolas Ferre <Nicolas.Ferre@microchip.com>
> > Link: https://lkml.org/lkml/2020/11/4/482
>
> You might need to change this to a "lore" link:
> https://lore.kernel.org/netdev/2db854c7-9ffb-328a-f346-f68982723d29@microchip.com/
>
> > Signed-off-by: Parshuram Thombare <pthombar@cadence.com>
>
> This fix looks a bit weird to me. What about proposing a patch to Russell
> like the chunk that you already identified in function
> phylink_major_config()?
No thanks. macb is currently the only case where a stub implementation
for pcs_config() is required, which only occurs because the only
appropriate protocol supported there is SGMII and not 1000base-X as
well.
> > ---
> > drivers/net/ethernet/cadence/macb_main.c | 17 +++++++++++++++--
> > 1 file changed, 15 insertions(+), 2 deletions(-)
> >
> > diff --git a/drivers/net/ethernet/cadence/macb_main.c b/drivers/net/ethernet/cadence/macb_main.c
> > index b7bc160..130a5af 100644
> > --- a/drivers/net/ethernet/cadence/macb_main.c
> > +++ b/drivers/net/ethernet/cadence/macb_main.c
> > @@ -633,6 +633,15 @@ static void macb_pcs_an_restart(struct phylink_pcs *pcs)
> > /* Not supported */
> > }
> >
> > +static int macb_pcs_config(struct phylink_pcs *pcs,
> > + unsigned int mode,
> > + phy_interface_t interface,
> > + const unsigned long *advertising,
> > + bool permit_pause_to_mac)
> > +{
> > + return 0;
> > +}
>
> Russell, is the requirement for this void function intended?
In response to v3 of the patch on 21st October, I said, and I quote:
I think all that needs to happen is a pcs_ops for the non-10GBASE-R
mode which moves macb_mac_pcs_get_state() and macb_mac_an_restart()
to it, and implements a stub pcs_config(). So it should be simple
to do.
Obviously, my advice was not followed, I didn't spot the lack of it
in v4 (sorry), and the result is the NULL pointer oops.
--
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTP is here! 40Mbps down 10Mbps up. Decent connectivity at last!
next prev parent reply other threads:[~2020-11-05 15:53 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-11-05 14:37 [PATCH] net: macb: fix NULL dereference due to no pcs_config method Parshuram Thombare
2020-11-05 14:37 ` Parshuram Thombare
2020-11-05 15:22 ` Nicolas Ferre
2020-11-05 15:22 ` Nicolas Ferre
2020-11-05 15:48 ` Russell King - ARM Linux admin [this message]
2020-11-05 15:48 ` Russell King - ARM Linux admin
2020-11-05 16:38 ` Nicolas Ferre
2020-11-05 16:38 ` Nicolas Ferre
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20201105154856.GN1551@shell.armlinux.org.uk \
--to=linux@armlinux.org.uk \
--cc=Claudiu.Beznea@microchip.com \
--cc=Santiago.Esteban@microchip.com \
--cc=andrew@lunn.ch \
--cc=davem@davemloft.net \
--cc=harini.katakam@xilinx.com \
--cc=kuba@kernel.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=michal.simek@xilinx.com \
--cc=netdev@vger.kernel.org \
--cc=nicolas.ferre@microchip.com \
--cc=pthombar@cadence.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.