| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
| |
Signed-off-by: Jonas Gorski <jogo@openwrt.org>
SVN-Revision: 45486
|
|
|
|
|
|
| |
Signed-off-by: Felix Fietkau <nbd@openwrt.org>
SVN-Revision: 45480
|
|
|
|
|
|
| |
Signed-off-by: Luka Perkov <luka@openwrt.org>
SVN-Revision: 45478
|
|
|
|
|
|
| |
Signed-off-by: Luka Perkov <luka@openwrt.org>
SVN-Revision: 45477
|
|
|
|
|
|
| |
Signed-off-by: Rafał Miłecki <zajec5@gmail.com>
SVN-Revision: 45474
|
|
|
|
|
|
| |
Signed-off-by: Rafał Miłecki <zajec5@gmail.com>
SVN-Revision: 45473
|
|
|
|
|
|
| |
Signed-off-by: Rafał Miłecki <zajec5@gmail.com>
SVN-Revision: 45472
|
|
|
|
|
|
| |
Signed-off-by: Rafał Miłecki <zajec5@gmail.com>
SVN-Revision: 45470
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The mips74k subtarget of brcm47xx configures gcc to compile for mips32r2;
however, the generated kernel config for 3.14 and later kernels ends up
with CPU_MIPS32_R1 and CPU_MIPSR1 selected. The generated kernel config
for the 3.10 kernel (Barrier Breaker) properly selected CPU_MIPS32_R2 and
CPU_MIPSR2. Modify the default kernel config for mips74k to explicitly
select CPU_MIPS32_R2 and CPU_MIPSR2.
Signed-off-by: Nathan Hintz <nlhintz@hotmail.com>
Tested-by: Rafał Miłecki <zajec5@gmail.com>
SVN-Revision: 45469
|
|
|
|
|
|
| |
Signed-off-by: Felix Fietkau <nbd@openwrt.org>
SVN-Revision: 45468
|
|
|
|
|
|
| |
Signed-off-by: Felix Fietkau <nbd@openwrt.org>
SVN-Revision: 45467
|
|
|
|
|
|
| |
Signed-off-by: Felix Fietkau <nbd@openwrt.org>
SVN-Revision: 45466
|
|
|
|
|
|
| |
Signed-off-by: Felix Fietkau <nbd@openwrt.org>
SVN-Revision: 45465
|
|
|
|
|
|
| |
Signed-off-by: Felix Fietkau <nbd@openwrt.org>
SVN-Revision: 45464
|
|
|
|
|
|
| |
Signed-off-by: Felix Fietkau <nbd@openwrt.org>
SVN-Revision: 45461
|
|
|
|
|
|
| |
Signed-off-by: Felix Fietkau <nbd@openwrt.org>
SVN-Revision: 45460
|
|
|
|
|
|
| |
Signed-off-by: Luka Perkov <luka@openwrt.org>
SVN-Revision: 45459
|
|
|
|
|
|
| |
Signed-off-by: Felix Fietkau <nbd@openwrt.org>
SVN-Revision: 45458
|
|
|
|
|
|
| |
Signed-off-by: Imre Kaloz <kaloz@openwrt.org>
SVN-Revision: 45456
|
|
|
|
|
|
| |
Signed-off-by: Luka Perkov <luka@openwrt.org>
SVN-Revision: 45455
|
|
|
|
|
|
| |
Signed-off-by: Luka Perkov <luka@openwrt.org>
SVN-Revision: 45454
|
|
|
|
|
|
| |
Signed-off-by: Luka Perkov <luka@openwrt.org>
SVN-Revision: 45453
|
|
|
|
|
|
| |
Signed-off-by: Luka Perkov <luka@openwrt.org>
SVN-Revision: 45452
|
|
|
|
|
|
| |
Signed-off-by: Felix Fietkau <nbd@openwrt.org>
SVN-Revision: 45451
|
|
|
|
|
|
| |
Signed-off-by: Felix Fietkau <nbd@openwrt.org>
SVN-Revision: 45450
|
|
|
|
|
|
| |
Signed-off-by: Rafał Miłecki <zajec5@gmail.com>
SVN-Revision: 45445
|
|
|
|
|
|
|
|
| |
This will allow adding more modes without options conflict.
Signed-off-by: Rafał Miłecki <zajec5@gmail.com>
SVN-Revision: 45443
|
|
|
|
|
|
|
|
|
|
|
| |
Open-Mesh OM5P-AN use a AT8035 (F1E) behind one of the ethernet ports. This PHY
requires special flags to work correctly. Otherwise massive packet loss happens
with active POE or when switching the link speed from gigabit ethernet to fast
ethernet. The generic PHY doesn't have support to change these settings.
Signed-off-by: Sven Eckelmann <sven@open-mesh.com>
SVN-Revision: 45439
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The OM5P-AN boards are suffering from ethernet packet loss when booting with
some active POE setups or when switching to Fast Ethernet when previously
booted with Gigabit ethernet attached.
The cause of the problem is that the AR8035 PHYs requires special register
settings to work reliably on these boards. Enable the RGMII TX, RX delays and
disable SmartEE functionality of the AR8035 PHYs. Also enable the RXD and RDV
delay in the ETH_CFG register to fix the issue.
Signed-off-by: Sven Eckelmann <sven@open-mesh.com>
SVN-Revision: 45438
|
|
|
|
|
|
| |
Signed-off-by: Felix Fietkau <nbd@openwrt.org>
SVN-Revision: 45431
|
|
|
|
|
|
| |
Signed-off-by: Felix Fietkau <nbd@openwrt.org>
SVN-Revision: 45426
|
|
|
|
|
|
|
|
|
|
|
| |
it has been non-functional for years and caused numerous memleaks and
crashes for people that tried to enable it.
it has no maintained upstream source, and it does not look like it's
going to be fixed any time soon
Signed-off-by: Felix Fietkau <nbd@openwrt.org>
SVN-Revision: 45423
|
|
|
|
|
|
| |
Signed-off-by: Felix Fietkau <nbd@openwrt.org>
SVN-Revision: 45422
|
|
|
|
|
|
| |
Signed-off-by: Imre Kaloz <kaloz@openwrt.org>
SVN-Revision: 45421
|
|
|
|
|
|
| |
Signed-off-by: Felix Fietkau <nbd@openwrt.org>
SVN-Revision: 45420
|
|
|
|
|
|
| |
Signed-off-by: Felix Fietkau <nbd@openwrt.org>
SVN-Revision: 45419
|
|
|
|
|
|
| |
Signed-off-by: Felix Fietkau <nbd@openwrt.org>
SVN-Revision: 45418
|
|
|
|
|
|
|
|
| |
device)
Signed-off-by: Felix Fietkau <nbd@openwrt.org>
SVN-Revision: 45417
|
|
|
|
|
|
| |
Signed-off-by: Felix Fietkau <nbd@openwrt.org>
SVN-Revision: 45416
|
|
|
|
|
|
| |
Signed-off-by: Imre Kaloz <kaloz@openwrt.org>
SVN-Revision: 45415
|
|
|
|
|
|
| |
Signed-off-by: Imre Kaloz <kaloz@openwrt.org>
SVN-Revision: 45414
|
|
|
|
|
|
|
|
| |
If you can't find the firmware for you board, send proper patches.
Signed-off-by: Imre Kaloz <kaloz@openwrt.org>
SVN-Revision: 45413
|
|
|
|
|
|
|
|
| |
This has been done without having a board, but should work.
Signed-off-by: Imre Kaloz <kaloz@openwrt.org>
SVN-Revision: 45412
|
|
|
|
|
|
| |
Signed-off-by: Imre Kaloz <kaloz@openwrt.org>
SVN-Revision: 45411
|
|
|
|
|
|
| |
Signed-off-by: Felix Fietkau <nbd@openwrt.org>
SVN-Revision: 45408
|
|
|
|
|
|
| |
Signed-off-by: Felix Fietkau <nbd@openwrt.org>
SVN-Revision: 45407
|
|
|
|
|
|
|
|
| |
left "broken" as I'm not sure if my only board is to blame.. testers welcomed
Signed-off-by: Imre Kaloz <kaloz@openwrt.org>
SVN-Revision: 45406
|
|
|
|
|
|
| |
Signed-off-by: Imre Kaloz <kaloz@openwrt.org>
SVN-Revision: 45405
|
|
|
|
|
|
|
|
|
| |
It seems to have few ports connected to CPU (only for CPU sending data?)
as part of "SMP dual core 3 GMAC setup" feature.
Signed-off-by: Rafał Miłecki <zajec5@gmail.com>
SVN-Revision: 45403
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
On BCM5301X there are two different cases to handle: CPU port 8 vs. any
other one. Support for CPU port 8 was already partially implemented but
it lacked setting some extra bit for 2G speed. It also will need to be
extended to implement "SMP dual core 3 GMAC setup". That's the reason
for handling it in separated code block.
This patch also adds overriding CPU port state for port other than 8. It
requires using recently defined GMII_PORT registers.
It was tested for regressions on BCM53011 revs 2 & 3. It was also
confirmed to fix switch on some internal Broadcom board.
Signed-off-by: Rafał Miłecki <zajec5@gmail.com>
Acked-by: Jonas Gorski <jogo@openwrt.org>
SVN-Revision: 45402
|