[PATCH 4/6] drivers: net: octeontx: fix QSGMII

[Tim Harvey]

On Fri, Mar 26, 2021 at 9:39 AM Suneel Garapati <suneelglinux at gmail.com> wrote:
>
> + Chandra
>
> On Fri, Mar 26, 2021 at 9:38 AM Tim Harvey <tharvey at gateworks.com> wrote:
> >
> > On Fri, Mar 26, 2021 at 9:09 AM Suneel Garapati <suneelglinux at gmail.com> wrote:
> > >
> > > This looks like a workaround than the root cause fix.
> > > As this patch just moves the bringup of link from probe stage to on-demand.
> > >
> > > On Thu, Mar 25, 2021 at 11:46 PM Stefan Roese <sr at denx.de> wrote:
> > > >
> > > > On 26.03.21 01:07, Tim Harvey wrote:
> > > > > Revert a change that occured between the Marvell SDK-10.1.1.0
> > > > > and SDK-10.3.1.1 which broke QSMII phy support.
> > > > >
> > > > > Signed-off-by: Tim Harvey <tharvey at gateworks.com>
> > > >
> > > > Thanks.
> > > >
> > > > Suneel, do you have a comment on this? Is this revert the "best way" to
> > > > handle this?
> > > >
> > > > Thanks,
> > > > Stefan
> > > >
> > > > > ---
> > > > >   drivers/net/octeontx/bgx.c | 20 +++++++-------------
> > > > >   1 file changed, 7 insertions(+), 13 deletions(-)
> > > > >
> > > > > diff --git a/drivers/net/octeontx/bgx.c b/drivers/net/octeontx/bgx.c
> > > > > index 2ea54be84d..a5c0c9fe2b 100644
> > > > > --- a/drivers/net/octeontx/bgx.c
> > > > > +++ b/drivers/net/octeontx/bgx.c
> > > > > @@ -36,7 +36,6 @@ struct lmac {
> > > > >       int                     dmac;
> > > > >       u8                      mac[6];
> > > > >       bool                    link_up;
> > > > > -     bool                    init_pend;
> > > > >       int                     lmacid; /* ID within BGX */
> > > > >       int                     phy_addr; /* ID on board */
> > > > >       struct udevice          *dev;
> > > > > @@ -849,6 +848,7 @@ static int bgx_lmac_enable(struct bgx *bgx, int8_t lmacid)
> > > > >       u64 cfg;
> > > > >
> > > > >       lmac = &bgx->lmac[lmacid];
> > > > > +     lmac->bgx = bgx;
> > > > >
> > > > >       debug("%s: lmac: %p, lmacid = %d\n", __func__, lmac, lmacid);
> > > > >
> > > > > @@ -895,16 +895,6 @@ int bgx_poll_for_link(int node, int bgx_idx, int lmacid)
> > > > >       debug("%s: %d, lmac: %d/%d/%d %p\n",
> > > > >             __FILE__, __LINE__,
> > > > >             node, bgx_idx, lmacid, lmac);
> > > > > -     if (lmac->init_pend) {
> > > > > -             ret = bgx_lmac_enable(lmac->bgx, lmacid);
> > > > > -             if (ret < 0) {
> > > > > -                     printf("BGX%d LMAC%d lmac_enable failed\n", bgx_idx,
> > > > > -                            lmacid);
> > > > > -                     return ret;
> > > > > -             }
> > > > > -             lmac->init_pend = 0;
> > > > > -             mdelay(100);
> > > > > -     }
> > > > >       if (lmac->qlm_mode == QLM_MODE_SGMII ||
> > > > >           lmac->qlm_mode == QLM_MODE_RGMII ||
> > > > >           lmac->qlm_mode == QLM_MODE_QSGMII) {
> > > > > @@ -1461,6 +1451,7 @@ int octeontx_bgx_remove(struct udevice *dev)
> > > > >
> > > > >   int octeontx_bgx_probe(struct udevice *dev)
> > > > >   {
> > > > > +     int err;
> > > > >       struct bgx *bgx = dev_get_priv(dev);
> > > > >       u8 lmac = 0;
> > > > >       int qlm[4] = {-1, -1, -1, -1};
> > > > > @@ -1540,8 +1531,11 @@ skip_qlm_config:
> > > > >               struct lmac *tlmac = &bgx->lmac[lmac];
> > > > >
> > > > >               tlmac->dev = dev;
> > > > > -             tlmac->init_pend = 1;
> > > > > -             tlmac->bgx = bgx;
> > > > > +             err = bgx_lmac_enable(bgx, lmac);
> > > > > +             if (err) {
> > > > > +                     printf("BGX%d failed to enable lmac%d\n",
> > > > > +                            bgx->bgx_id, lmac);
> > > > > +             }
> > > > >       }
> > > > >
> > > > >       return 0;
> > > > >
> > > >
> >
> > Suneel,
> >
> > I agree, it is a workaround and I don't quite understand the reason.
> >
> > Can you look into the code history of the SDK BDK and see what the
> > reason was for introducing this 'pending' state that defers the
> > bgx_lmac_enable call that breaks QSGMII? That specific change was made
> > between SDK-10.1.1.0 and SDK-10.3.1.1.
> >
> > What boards and PHY's have you tested octeontx BGX with?
> >
> > I have the following boards to test with that we designed and support:
> > - GW630x: supports both RGMII and SGMII GbE PHY's
> > - GW640x: supports both RGMII and QSGMII GbE PHy's
> >
> > The only issue I have that is worked around by the above is QSGMII.
> >

Sunell / Chandrakala,

Any comments here about what PHY's you have tested octeontx BGX with
and what the reasoning was for the code change here between Marvell
SDK-10.1.1.0 and SDK-10.3.1.1?

Tim