Instead of looking into the proc entry provided by broadcom-diag use
the board info from /proc/cpuinfo to get the board we are on.
Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de>
SVN-Revision: 39256
Use the new led api also on brcm47xx.
The led for failsafe indication is searched for.
Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de>
SVN-Revision: 39255
Remove the code used on the old switch driver.
The Ethernet drive is loaded as a module and needs some time to get up
therefor we added some wait function.
Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de>
SVN-Revision: 39254
This makes brcm47xx target use the default gpio led and button driver
and not broadcom-diag any more.
Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de>
SVN-Revision: 39253
Arcadyan ARV4510PW has already a build profile in OpenWrt, but it is
severely lacking. This patch brings it up-to-date.
Signed-off-by: Matti Laakso <malaakso@elisanet.fi>
SVN-Revision: 39230
The r39147 commit introduces a regression: at lease on some routers
with ar8216 switch large packets get lost if 802.1q tagged port is
used on the interface connected to the aforementioned switch.
The r39147 changes code in the way so interface is set to accept
packets no longer than max ethernet frame length for a given mtu.
Unfortunately ar8216 has a feature: it sends two additional bytes
as a packet header and those this header needs to be added to the
max frame length. Otherwise long enough packets get lost.
The problem only manuifests itself if interface is used in vlan
tagged mode. If interface is untagged then ar8216's header fits
into space used by 802.1q tag and not packets are lost.
Include two additional bytes in the max frame length calculation
to fix the issue.
This patch is tested and works with Trendnet TEW-632BRP.
Signed-off-by Nikolay Martynov <mar.kolya@gmail.com>
Patchwork: http://patchwork.openwrt.org/patch/4656/
[juhosg:
- simplify the patch to include the additional bytes of the
switch header unconditionally,
- change subject and update commit message]
Signed-off-by: Gabor Juhos <juhosg@openwrt.org>
SVN-Revision: 39219
The built-in wireless MAC of the AR934x SoC can handle
external LNAs and the control signal of the LNAs can be
routed to any GPIO line. Add a helper function which
can be used to configure the GPIO lines.
The helper function will be used for AR934x boards
which are using externel LNAs to improve sensitivity.
Signed-off-by: Gabor Juhos <juhosg@openwrt.org>
SVN-Revision: 39215
The LNAs need to be enabled by setting their respective GPIO to high even
though the original firmware's setting sets them to low on initialization.
Obviously the LNAs are then later initialized by the driver on the OEM
firmware. Without this fix the device is mostly "deaf".
Signed-off-by: Felix Kaechele <heffer@fedoraproject.org>
Tested-by: Steven Haigh <netwiz@crc.id.au>
Patchwork: http://patchwork.openwrt.org/patch/4689/
[juhosg:
- remove the GPIO LED changes, the My Net N600 has no yellow LEDs at all,
- change subject and update the commit message]
Signed-off-by: Gabor Juhos <juhosg@openwrt.org>
SVN-Revision: 39214
The LNAs need to be enabled by setting their respective GPIO to high even
though the original firmware's setting sets them to low on initialization.
Obviously the LNAs are then later initialized by the driver on the OEM
firmware. Without this fix the device is mostly "deaf".
Signed-off-by: Felix Kaechele <heffer@fedoraproject.org>
Patchwork: http://patchwork.openwrt.org/patch/4688/
Signed-off-by: Gabor Juhos <juhosg@openwrt.org>
SVN-Revision: 39213
This fixes the DMA problems with the Ethernet driver.
This also updates some other parts of the patches.
Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de>
SVN-Revision: 39203
The PHY always says there is no link
Instead of doing this dma sync a mdelay does the same trick and it is as unreliable.
Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de>
SVN-Revision: 39202
