[OpenWrt-Devel] ar71xx/ath79: at803x_platform_data: reset_gpio

[Joe Ayers]

> > during support of the Ubiquiti Nanostation Loco XW, we encountered the following
> > blocks in ar71xx which are only present for devices not migrated to ath79 yet:
> >
> > static struct mdio_board_info ubnt_loco_m_xw_mdio_info[] = {
> >       {
> >               [...]
> >               .platform_data = &ubnt_loco_m_xw_at803x_data,
> >       },
> > };
> > static struct at803x_platform_data ubnt_loco_m_xw_at803x_data = {
> >       .has_reset_gpio = 1,
> >       .reset_gpio = 0,
> > };
> >
> > How is this translated into ath79? The Loco XW (just merged to master [1]) seems
> > to work well with the setup we have right now, other devices with reset_gpio are
> > few:
>
> AFAIR this is due to a hardware bug, which sometimes leads to the PHY ending up in
> an unrecoverable state when the link-state changes. I assume, the person who did
> the device integration simply did not encounter the bug.
>

The GPIO PHY reset was used, from Chaos Calmer timeframe.    Many
users were plagued with this issue originally, and devices were
unusable.   Symptoms would occur after hours or days after boot, like
clockwork.

Ubiquiti uses an external 803x PHY chip with a SOC GPIO pin over to
reset.  The onboard PHY of the AR93xx was not used, so only know to be
an ubnt issue.

If the Bullet XW in ath79 target has this hardware architecture, and
there hasn't been a reported PHY lock up, then I would wonder if the
root cause is something else and otherwise resolved.

AFAIR, these are some of the devices impacted in ar71xx:

NBE/PBE-M5-300 XW: ag71xx ag71xx.0: connected to PHY at
ag71xx-mdio.0:01 [uid=004dd023, driver=Generic PHY]
NSM5-loco-XW:  ag71xx ag71xx.0: connected to PHY at ag71xx-mdio.0:01
[uid=004dd023, driver=Generic PHY]
Airgrid M5 XW:  ag71xx ag71xx.0: connected to PHY at ag71xx-mdio.0:01
[uid=004dd023, driver=Generic PHY]
NBM5/16 XW:  ag71xx ag71xx.0: connected to PHY at ag71xx-mdio.0:01
[uid=004dd023, driver=Generic PHY]
NBM5/19 XW: ag71xx ag71xx.0: connected to PHY at ag71xx-mdio.0:01
[uid=004dd023, driver=Generic PHY]

PBE-M2-400 XW: ag71xx ag71xx.0: connected to PHY at ag71xx-mdio.0:04
[uid=004dd072, driver=Atheros 8035 ethernet]
PBE-M5-400 XW: ag71xx ag71xx.0: connected to PHY at ag71xx-mdio.0:04
[uid=004dd072, driver=Atheros 8035 ethernet]
PBE-M5-620 XW:  ag71xx ag71xx.0: connected to PHY at ag71xx-mdio.0:04
[uid=004dd072, driver=Atheros 8035 ethernet]
Rocket M5 XW: ag71xx ag71xx.0: connected to PHY at ag71xx-mdio.0:04
[uid=004dd072, driver=Atheros 8035 ethernet]

Joe AE6XE

> Usage of reset GPIOs is documented here. [0]
>
> > adsc at buildfff:/data/openwrt$ grep -rn "reset_gpio"
> > target/linux/ar71xx/files/arch/
> > target/linux/ar71xx/files/arch/mips/ath79/mach-rambutan.c:35:   .has_reset_gpio
> > = 1,
> > target/linux/ar71xx/files/arch/mips/ath79/mach-rambutan.c:36:   .reset_gpio =
> > 17,
> > target/linux/ar71xx/files/arch/mips/ath79/mach-rambutan.c:48:   .has_reset_gpio
> > = 1,
> > target/linux/ar71xx/files/arch/mips/ath79/mach-rambutan.c:50:   .reset_gpio =
> > 23,
> > target/linux/ar71xx/files/arch/mips/ath79/mach-ubnt-xm.c:485:   .has_reset_gpio
> > = 1,
> > target/linux/ar71xx/files/arch/mips/ath79/mach-ubnt-xm.c:486:   .reset_gpio = 0,
> > target/linux/ar71xx/files/arch/mips/ath79/mach-fritz450e.c:124: .has_reset_gpio
> > = 1,
> > target/linux/ar71xx/files/arch/mips/ath79/mach-fritz450e.c:126: .reset_gpio =
> > FRITZ450E_GPIO_PHY_RESET,
>
> At least for the AVM Repeater 450E, the reason is simple: EVA puts the PHY in reset.
> As the subsystem can handle reset-gpio handling, this is the preferred way of
> pulling the device out of reset.
>
> Can't speak about the other boards though. The bug on the Nanostation is not quite common,
> as only the AR8030 (a FE-PHY) is affected.

_______________________________________________
openwrt-devel mailing list
openwrt-devel at lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel