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

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

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
> >