- 18 Jun, 2015 4 commits
-
-
blogic authored
This patch is for PandoraBox PBR-M1 which is based on mt7621, all the features work fine, including rtc, leds, button, usb3.0, etc. Signed-off-by:
tymon <banglang.huang@foxmail.com> Backport of r46041 git-svn-id: svn://svn.openwrt.org/openwrt/branches/chaos_calmer@46051 3c298f89-4303-0410-b956-a3cf2f4a3e73
-
blogic authored
Signed-off-by:
John Crispin <blogic@openwrt.org> Backport of r46038 git-svn-id: svn://svn.openwrt.org/openwrt/branches/chaos_calmer@46039 3c298f89-4303-0410-b956-a3cf2f4a3e73
-
nbd authored
Signed-off-by:
Felix Fietkau <nbd@openwrt.org> Backport of r46032 git-svn-id: svn://svn.openwrt.org/openwrt/branches/chaos_calmer@46033 3c298f89-4303-0410-b956-a3cf2f4a3e73
-
nbd authored
Signed-off-by:
-
- 17 Jun, 2015 6 commits
-
-
jow authored
This is required to use x86/64 in KVM containers with VirtIO disks Signed-off-by:
Jo-Philipp Wich <jow@openwrt.org> Backport of r46017 git-svn-id: svn://svn.openwrt.org/openwrt/branches/chaos_calmer@46018 3c298f89-4303-0410-b956-a3cf2f4a3e73
-
jogo authored
It seems that there are maximum timings for mdio accesses that can be hit when the system is under load and the thread is scheduled during a read or write access. Since there is no way of knowing if this happens as there is not even a parity bit, try to work around it by disabling interrupts during any gpio-mdio accesses. Performance impact seems to be neglectable, as mdio accesses are not that often. Hopefully fixes #19500. Signed-off-by:
Jonas Gorski <jogo@openwrt.org> Backport of r46012. git-svn-id: svn://svn.openwrt.org/openwrt/branches/chaos_calmer@46016 3c298f89-4303-0410-b956-a3cf2f4a3e73
-
jogo authored
Changelogs: * https://www.kernel.org/pub/linux/kernel/v3.x/ChangeLog-3.18.15 * https://www.kernel.org/pub/linux/kernel/v3.x/ChangeLog-3.18.16Signed-off-by:
-
nbd authored
Signed-off-by:
-
nbd authored
Signed-off-by:
-
nbd authored
Signed-off-by:
-
- 16 Jun, 2015 4 commits
-
-
nbd authored
Signed-off-by:
-
nbd authored
Signed-off-by:
-
rmilecki authored
This stabilizes USB support. The old patch was handling initialization in a different order that was causing some problems with few USB 3.0 devices. Some weren't detected, some were working unstable, sometimes USB 3.0 could hang the whole controller. A still known issue (but not a regression) is controller hang triggered by connecting USB 1.1 device when not having OHCI controller enabled (kmod-usb-ohci). Signed-off-by:
Rafał Miłecki <zajec5@gmail.com> Backport of r45997 git-svn-id: svn://svn.openwrt.org/openwrt/branches/chaos_calmer@45998 3c298f89-4303-0410-b956-a3cf2f4a3e73
-
rmilecki authored
On bcm53xx we still need usb-ohci to support USB 1.1 devices and it obviously needs bcma-hcd.ko that will init controller and register platform device. Signed-off-by:
-
- 15 Jun, 2015 5 commits
-
-
nbd authored
Signed-off-by:
-
nbd authored
Signed-off-by:
-
nbd authored
Signed-off-by:
-
cyrus authored
Signed-off-by:
Toke Høiland-Jørgensen <toke@toke.dk> git-svn-id: svn://svn.openwrt.org/openwrt/branches/chaos_calmer@45987 3c298f89-4303-0410-b956-a3cf2f4a3e73
-
nbd authored
This one cannot possibly work, as it depends on cfg80211, which is built out of tree. Signed-off-by:
-
- 14 Jun, 2015 5 commits
-
-
nbd authored
Signed-off-by:
-
nbd authored
Signed-off-by:
-
nbd authored
Signed-off-by:
-
nbd authored
Signed-off-by:
-
nbd authored
git-svn-id: svn://svn.openwrt.org/openwrt/branches/chaos_calmer@45974 3c298f89-4303-0410-b956-a3cf2f4a3e73
-
