[PATCH 3/4] net/ftgmac100: Add NC-SI mode support

[Samuel Mendoza-Jonas]

On Wed, 2019-06-12 at 03:04 +0000, Joel Stanley wrote:
> On Thu, 6 Jun 2019 at 04:50, Samuel Mendoza-Jonas <sam at mendozajonas.com> wrote:
> > Update the ftgmac100 driver to support NC-SI instead of an mdio phy
> > where available. This is a common setup for Aspeed AST2x00 platforms.
> > 
> > NC-SI mode is determined from the device-tree if either phy-mode sets it
> > or the use-ncsi property exists. If set then normal mdio setup is
> > skipped in favour of the NC-SI phy.
> > 
> > Signed-off-by: Samuel Mendoza-Jonas <sam at mendozajonas.com>
> > ---
> >  drivers/net/ftgmac100.c | 39 +++++++++++++++++++++++++++++----------
> > @@ -181,7 +183,7 @@ static int ftgmac100_phy_adjust_link(struct ftgmac100_data *priv)
> >         struct phy_device *phydev = priv->phydev;
> >         u32 maccr;
> > 
> > -       if (!phydev->link) {
> > +       if (!phydev->link && !priv->ncsi_mode) {
> >                 dev_err(phydev->dev, "No link\n");
> >                 return -EREMOTEIO;
> >         }
> > @@ -217,7 +219,8 @@ static int ftgmac100_phy_init(struct udevice *dev)
> >         if (!phydev)
> >                 return -ENODEV;
> > 
> > -       phydev->supported &= PHY_GBIT_FEATURES;
> > +       if (!priv->ncsi_mode)
> > +               phydev->supported &= PHY_GBIT_FEATURES;
> 
> Instead of hiding this behind ncsi_mode I was assuming the ncsi "phy"
> driver would answer these questions through the phy_read callbacks.
> 
> If you don't think that is going to work then this solution isn't too
> invasive, and we've been using this in Linux for a while, so we know
> it works.

Having this purely transparent would indeed be nice, but it's been a
little awkward fitting NCSI into the u-boot model. phy_read, etc don't
really make sense for a NCSI "PHY" like in the Linux model since there
aren't any registers as such to query - thus checking the device-tree and
skipping the normal mdio bus setup.
I'll have a bit more of a think about the driver model, and probably
exactly how Aspeed (for example) hooks this up; maybe there's a way we
can fit in to the more usual model.