diff options
author | John Crispin <john@openwrt.org> | 2015-03-12 10:06:42 +0000 |
---|---|---|
committer | John Crispin <john@openwrt.org> | 2015-03-12 10:06:42 +0000 |
commit | fd82ffec00ad6edc094a68778059329c8105fe21 (patch) | |
tree | fc5453d45aeb9390f02e3212a6b66160b89af250 /target/linux/mxs | |
parent | 835b17c333dc927120a0395f9fef7be5a43bb55a (diff) | |
download | upstream-fd82ffec00ad6edc094a68778059329c8105fe21.tar.gz upstream-fd82ffec00ad6edc094a68778059329c8105fe21.tar.bz2 upstream-fd82ffec00ad6edc094a68778059329c8105fe21.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>
SVN-Revision: 44692
Diffstat (limited to 'target/linux/mxs')
0 files changed, 0 insertions, 0 deletions