Re: port-i386/53494: vte doesn't work on eBox 3352DX3-AP

[Andrius V <vezhlys%gmail.com@localhost>]

The following reply was made to PR port-i386/53494; it has been noted by GNATS.

From: Andrius V <vezhlys%gmail.com@localhost>
To: gnats-bugs%netbsd.org@localhost
Cc: port-i386-maintainer%netbsd.org@localhost, gnats-admin%netbsd.org@localhost, 
	netbsd-bugs%netbsd.org@localhost, dholland-bugs%netbsd.org@localhost
Subject: Re: port-i386/53494: vte doesn't work on eBox 3352DX3-AP
Date: Sat, 19 Jun 2021 23:27:42 +0300

 Above patch would work only if rdcphy is attached, but since one of
 two ID registers fails to report correct value, oui becomes invalid
 (0xfcff2f) and generic driver (ukphy) is attached instead. So, either
 rdcphy_match should be changed to check just part of ID as well or
 broken OUI added to miidevs. The quick patch below would make vte work
 on my device with some limitations like media type should not be
 changed after. If it looks reasonable to apply, I can cleanup and
 prepare a better one. However, I believe it just easier to consider my
 device broken and close the PR. In case I would somehow find a way to
 restore functionality programmatically (quite unlikely), I would
 create a patch for that.
 
 diff --git a/sys/dev/mii/rdcphy.c b/sys/dev/mii/rdcphy.c
 index 613d945bc09..d5bb0e59daf 100644
 --- a/sys/dev/mii/rdcphy.c
 +++ b/sys/dev/mii/rdcphy.c
 @@ -76,6 +76,7 @@ static const struct mii_phy_funcs rdcphy_funcs = {
  static const struct mii_phydesc rdcphys[] = {
         MII_PHY_DESC(xxRDC, R6040),
         MII_PHY_DESC(xxRDC, R6040_2),
 +       {0xfcff2f, 0x0005, "R6040 10/100 media interface - invalid OUI"},
         MII_PHY_DESC(xxRDC, R6040_3),
         MII_PHY_END,
  };
 @@ -218,6 +219,11 @@ rdcphy_status(struct mii_softc *sc)
                 mii->mii_media_status |= IFM_ACTIVE;
 
         PHY_READ(sc, MII_BMCR, &bmcr);
 +
 +    if ((bmcr & 0xffff) && (physts & 0xffff)) {
 +        goto broken_reset;
 +    }
 +
         if ((bmcr & BMCR_ISO) != 0) {
                 mii->mii_media_active |= IFM_NONE;
                 mii->mii_media_status = 0;
 @@ -250,4 +256,15 @@ rdcphy_status(struct mii_softc *sc)
                 mii->mii_media_active |= IFM_FDX | mii_phy_flowstatus(sc);
         else
                 mii->mii_media_active |= IFM_HDX;
 +
 +   return;
 +
 +   broken_reset:
 +          if ((bmsr & BMSR_ACOMP) == 0) {
 +                      mii->mii_media_active |= IFM_NONE;
 +                      return;
 +          }
 +          mii->mii_media_status |= IFM_ACTIVE;
 +          mii->mii_media_active |= IFM_100_TX;
 +          mii->mii_media_active |= IFM_FDX | mii_phy_flowstatus(sc);
  }
 On Sat, Jun 19, 2021 at 1:07 AM Andrius V <vezhlys%gmail.com@localhost> wrote:
 >
 > Though possible I guess by skipping all bmcr checks in rdcphy_status,
 > if it's value equals to 0xffff, I doubt it's worth an effort. Since
 > status register also doesn't work, I am not sure how Linux was setting
 > the speed/duplex, but I believe by BMSR advertised capabilities and
 > putting the best possible option, which would mean we would also need
 > just to force 100baseTX full duplex. I would imagine patch similar to
 > this (untested):
 >
 > diff --git a/sys/dev/mii/rdcphy.c b/sys/dev/mii/rdcphy.c
 > index 613d945bc09..6aaadd9f604 100644
 > --- a/sys/dev/mii/rdcphy.c
 > +++ b/sys/dev/mii/rdcphy.c
 > @@ -218,6 +218,11 @@ rdcphy_status(struct mii_softc *sc)
 >                 mii->mii_media_status |= IFM_ACTIVE;
 >
 >         PHY_READ(sc, MII_BMCR, &bmcr);
 > +
 > +       if (bmcr == 0xffff && physts == 0xffff) {
 > +               goto broken_reset;
 > +       }
 > +
 >         if ((bmcr & BMCR_ISO) != 0) {
 >                 mii->mii_media_active |= IFM_NONE;
 >                 mii->mii_media_status = 0;
 > @@ -250,4 +255,15 @@ rdcphy_status(struct mii_softc *sc)
 >                 mii->mii_media_active |= IFM_FDX | mii_phy_flowstatus(sc);
 >         else
 >                 mii->mii_media_active |= IFM_HDX;
 > +       return;
 > +
 > +       broken_reset:
 > +               if ((bmsr & BMSR_ACOMP) == 0) {
 > +                       /* Erg, still trying, I guess... */
 > +                       mii->mii_media_active |= IFM_NONE;
 > +                       return;
 > +               }
 > +               mii->mii_media_status |= IFM_ACTIVE;
 > +               mii->mii_media_active |= IFM_100_TX;
 > +               mii->mii_media_active |= IFM_FDX | mii_phy_flowstatus(sc);
 >
 > However, I have an easier solution myself by just commenting out all
 > vte_reset calls, which cause the issue. It makes Ethernet controller
 > to initialize and work without visible issues. Thus, unless someone
 > else hits the same problem, I don't think so, that specific quirk is
 > necessary in the code.
 >
 > Regards,
 > Andrius V
 >
 > On Fri, Jun 18, 2021 at 7:35 PM David Holland <dholland-bugs%netbsd.org@localhost> wrote:
 > >
 > > The following reply was made to PR port-i386/53494; it has been noted by GNATS.
 > >
 > > From: David Holland <dholland-bugs%netbsd.org@localhost>
 > > To: gnats-bugs%netbsd.org@localhost
 > > Cc:
 > > Subject: Re: port-i386/53494: vte doesn't work on eBox 3352DX3-AP
 > > Date: Fri, 18 Jun 2021 16:33:32 +0000
 > >
 > >  On Fri, Jun 18, 2021 at 02:00:02PM +0000, Andrius V wrote:
 > >   >  I would probably recommend to close this bug for now and consider my
 > >   >  hardware being faulty until proved differently.
 > >   >  [...]
 > >
 > >  If it's possible to make it work by using only the one register, is it
 > >  worth adding a code path for that and treating it as a quirk? (maybe
 > >  only selectable explicitly unless/until we figure out how to probe it)
 > >
 > >  I haven't looked at the code and know nothing about the hw, so I have
 > >  no idea how hard or how invasive that would be, but it's a possible
 > >  way forward if you want your hw working and want to spend the time.
 > >
 > >  --
 > >  David A. Holland
 > >  dholland%netbsd.org@localhost
 > >