> This new driver supports RTL8723AU, RTL8188CU, RTL8188RU, RTL8191CU, and
> RTL8192CU and is taken from:
> https://git.kernel.org/cgit/linux/kernel/git/jes/linux.git/log/?h=rtl8723au-mac80211
[...]
This driver seems to work well, and it evidently fixes the problem I
earlier described in another e
Hello!
I have been making some progress towards reproducible (aka, deterministic)
builds of OpenWRT packages and "images" (target artifacts). Some emails
from earlier this year on the topic were:
https://lists.openwrt.org/pipermail/openwrt-devel/2015-June/033667.html
https://www.mail-arc
On Thu, 2015-10-22 at 22:50 +0100, Carlos Ferreira wrote:
> Yes :S Sorry!
> Btw, Caps lock day? Did my Gmail applied some weird format again ? :S
HTML.
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailm
Yes :S Sorry!
Btw, Caps lock day? Did my Gmail applied some weird format again ? :S
On 22 October 2015 at 22:46, Daniel Gimpelevich <
dan...@gimpelevich.san-francisco.ca.us> wrote:
> On Thu, 2015-10-22 at 22:30 +0100, Carlos Ferreira wrote:
> > Daniel
> > Your patch did not work without some sim
On Thu, 2015-10-22 at 22:30 +0100, Carlos Ferreira wrote:
> Daniel
> Your patch did not work without some simple modifications.
>
This puzzled me until I realized you meant the other Daniel.
PS: HAPPY INTERNATIONAL CAPS LOCK DAY!
___
openwrt-devel maili
Ok... this is going to be impossible. The problem is not only in procd but
in other system programs.
For example, rpcd is showing the same problems. See bellow.
PS: I added Jo-Philipp to CC
make[1]: Entering directory '/home/ArkHDD/OpenWRT/15.05'
make[2]: Entering directory
'/home/ArkHDD/OpenWRT/1
Daniel
Your patch did not work without some simple modifications.
Instead of having
*inline __attribute__((always_inline)) int ignore(int x) {return x;}*
at procd.h, I had to add a
*static inline __attribute__((always_inline)) int ignore(int x) {return x;}*
at the begining of both coldplug.c and
glibc sets __attribute_warn_unused_result__ on symlink(3) if
FORTIFY_SOURCE is set. This breaks procd which deliberately ignores
the result of the symlink(3) call early during init as there wouldn't
be anything better to do in that case other than ignoring the error and
trying to survive.
Introduc
Kernel 3.14 added aditional genphy_soft_reset phy reset to phy_init_hw in
drivers/net/phy/phy_device.c
Since adm6996 does in driver soft reset and doesn't use BMCR_RESET for soft
reset
add dummy soft_reset callback to adm6996 driver, like it is done in ar8216.
This fixes ticket #20147
Signed-of
Hi!
On Thu, Oct 22, 2015 at 12:53:06PM -0400, W. Michael Petullo wrote:
> I have installed OpenWrt (trunk, as of around October 17) on a Raspberry
> Pi Model B. The network adapter is an Edimax 802.11b/g/n Nano USB Adapter.
> Unfortunately, the network stack of the device is failing after a
> numb
On 10/22/2015 05:53 PM, W. Michael Petullo wrote:
> I have installed OpenWrt (trunk, as of around October 17) on a Raspberry
> Pi Model B. The network adapter is an Edimax 802.11b/g/n Nano USB Adapter.
> Unfortunately, the network stack of the device is failing after a
> number of minutes. At this
I have installed OpenWrt (trunk, as of around October 17) on a Raspberry
Pi Model B. The network adapter is an Edimax 802.11b/g/n Nano USB Adapter.
Unfortunately, the network stack of the device is failing after a
number of minutes. At this point, for example, pinging and other network
communicatio
On Thu, 2015-10-22 at 17:54 +0200, Felix Fietkau wrote:
> On 2015-10-21 01:34, Daniel Golle wrote:
> > Hi!
> >
> > This has been an argument going on between the gcc and the glibc people
> > for about 10 years now.
> > See
> > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=25509
> >
> > It seems li
On 2015-10-21 01:34, Daniel Golle wrote:
> Hi!
>
> This has been an argument going on between the gcc and the glibc people
> for about 10 years now.
> See
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=25509
>
> It seems like commit b6618ffa which added the symlinks silently broke
> things when b
Tested-by: Felix Kaechele
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
The TL-WR841N/ND v10 is mostly identical to the v9. Apart from some minor
changes, it contains a newer revision of the QCA9533 SoC and the CPU clock
is significantly higher.
Signed-off-by: Matthias Schiffer
---
target/linux/ar71xx/image/Makefile | 9 -
1 file changed, 8 insertions(+), 1
ath9k expects to get revision id 2 for the QCA9531 ver. 2 rev. 0. This
fixes the very low TX power on some devices like the TP-LINK
TL-WR841ND v10.
As ath79_soc_rev is only used to get the revision number to ath9k on the
QCA9533, just set it to the expected value on the ver. 2.
Signed-off-by: Mat
17 matches
Mail list logo