aboutsummaryrefslogtreecommitdiffstats
path: root/target/linux/at91/modules.mk
diff options
context:
space:
mode:
authorJohn Crispin <blogic@openwrt.org>2015-03-12 10:06:42 +0000
committerJohn Crispin <blogic@openwrt.org>2015-03-12 10:06:42 +0000
commitf30e32991d4dc21cb1c3580430314bcc56732d33 (patch)
tree3d7009d422af7321a658d5220e627cb9d4383993 /target/linux/at91/modules.mk
parentac706e1b3cccbb3685961965d18b54bf1dffbf3b (diff)
downloadupstream-f30e32991d4dc21cb1c3580430314bcc56732d33.tar.gz
upstream-f30e32991d4dc21cb1c3580430314bcc56732d33.tar.bz2
upstream-f30e32991d4dc21cb1c3580430314bcc56732d33.zip
ar71xx: Hornet UB GPIO WPS/Reset
This problem has existed at least since Attitude Adjustment and is also present in trunk. Basically on the Hornet-UB board the functionality of RESET and WPS have "switched places". There are two tickets about the issue at dev.openwrt.org, The solution suggested on them both is incomplete though and introduces the following proglem: Patching as suggested on #14136/#15282 will result in a situation where simply pressing the RESET button on the bottom will cause FACTORY RESET to be run. This is due to GPIO high/low state being incorrect as a result of the above change and virtually the RESET button is in the pressed-down state the entire time. When it is then physically pressed, that causes the opposite, release, to be triggered and since to the board it seemed that the button was pressed long before it was released, the FACTORY RESET results. The attached patch works as expected. I have verified both the incorrect functionality as well as after fixing the issue as described in the patch and flashing the resulting firmware to a Hornet-UB board. Signed-off-by: Janne Cederberg <janne.cederberg@gmail.com> git-svn-id: svn://svn.openwrt.org/openwrt/trunk@44692 3c298f89-4303-0410-b956-a3cf2f4a3e73
Diffstat (limited to 'target/linux/at91/modules.mk')
0 files changed, 0 insertions, 0 deletions