#19085: nanostation m5 loco xw "loses" interface
------------------------+------------------------
Reporter: anonymous | Owner: developers
Type: defect | Status: reopened
Priority: normal | Milestone:
Component: kernel | Version: Trunk
Resolution: | Keywords:
------------------------+------------------------
Comment (by cmlara):
Restarting interfaces has not (in the past, I have not re-tested it since
this patch) resolved the issue. It really needs a low level chip reset and
user level tools (to my knowledge) just do not have this ability to do a
full chip reset.
I don't 100% understand the chip layouts but from some of the information
I have grabbed from the web (and the labeling given by Ubiquiti) it seems
0x18040000 is a GPIO control register bank, and presumably the pin we are
triggering is connected somehow to reset the ethernet chip.
https://wiki.opennet-initiative.de/wiki/Benutzer:Leo seemed to be getting
closer however I can see the last code mistep was to try and use gpiod to
write to the register bit rather than setting up a GPIO first and using
that (GPIOD complained that no such gpio existed which is true) or using
ar71xx_wr() to write to the register bit.
My last look was trying to see if there was a way to call ag71xx_hw_init()
on the assumption that it may be 'cleaner' and it would re-initalize the
chip however I was at first thinking that ath79_device_reset_set() and
ath79_device_reset_clear() touched a register provided, instead it looks
like it works on the reset register, though that may still work with
AR71XX_RESET_GE0_MAC (or is it GE1?) in the pdata of the device to trigger
a reset of the chip? It wouldn't follow what was suggested by Ubiquit, so
I am not sure if its a 'better' or 'worse' place to reset and what
repercussion there are by doing it in the reset register.
I've yet to have time to mock this up or to implement correctly (if it is
even the right path)
Speaking for dman776 and myself: We concur bug still exists, testing
triggered this morning in our lab as well.
Speaking for myself:
We did see the Ethernet interface going "UP UP" randomly with r47895
patch, not sure if it was about to get stuck and recovered, or if the
patch itself has issues where it responds differently but eventually it
did stick this morning.
--
Ticket URL: <https://dev.openwrt.org/ticket/19085#comment:54>
OpenWrt <http://openwrt.org>
Opensource Wireless Router Technology
_______________________________________________
openwrt-tickets mailing list
[email protected]
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-tickets
