Thanks for answer. I cannot unfortunately test new patch right away,
because I sort of put this device "in production" but if it is only
compilation flags that changed that I am sure it works. I suspected
some kind of memory leak, because driver control process is quite
heavy on memory but it does
On 2015-05-27 22:48, Stefan Rompf wrote:
> Hi Kirill,
>
>> So I made a patch for atheros driver and it works. A signal level on
>> different frequencies is more or less equal and seems adequate (about
>> -30 dbm if a client within a meter from ap).
>
> so you reverse engineered the timer values,
Hi Kirill,
> > An Unifi specific user space daemon listens to scan and channel change
> > events via netlink (will check next weekend if channel change is
> > broadcasted reliably) and tune the filter via sysfs interface
> > accordingly like hsr.c tried.
>
> I like this idea because in this case
Hi Aleksander,
On Wed, May 27, 2015 at 9:20 PM, Aleksander Wałęski wrote:
> add --enable-debug-prints=err to ltq-vdsl-app and change
> enable-debug-prints to err in ltq-vdsl-vr9.
> ...
> Additionally, I added --disable-dsl-ceoc to ltq-vdsl-app since CEOC is
> disabled in API by default anyway.
Th
On 30/05/2015 10:51, Jonas Gorski wrote:
> Hi,
>
> On Sat, May 30, 2015 at 3:11 AM, Mathieu Olivari
> wrote:
>> Ethernet GMAC is built-in the SoC, so there is no need to enable it as a
>> module. We'll just assume we need it. That's what is done for other
>> platform where this driver is used
tftpboot 0x8050 openwrt-ar71xx-generic-wpj531-16M-squashfs-sysupgrade.bin
erase 0x9f03 +$filesize
erase 0x9f68 +1
cp.b $fileaddr 0x9f03 $filesize
---
v2:
fix indentation with spaces
refresh patch
Signed-off-by: Christian Mehlis
---
target/linux/ar71xx/base-files/etc/diag.sh
John Crispin wrote:
> On 27/05/2015 18:03, Karl Palsson wrote:
> > + my $this_feed_target = lookup_target($feed, $name);
> > + $this_feed_target and do {
>
> how about just calling it $target ?
Because even though the method is "lookup_target" it actually returns a
feed for the target $name
Hi!
Someone with the needed access rights, please make sure all buildbot
targets also have their folder on downloads.openwrt.org
Looks like at least ipq806x is missing and cannot upload the packages
made:
http://buildbot.openwrt.org:8010/builders/ipq806x/builds/17/steps/shell_11/logs/stdio
Che
On 1 June 2015 at 00:08, Rafał Miłecki wrote:
> @@ -440,6 +441,7 @@ static void brcmf_fw_request_nvram_done(const struct
> firmware *fw, void *ctx)
> }
>
> fwctx->done(fwctx->dev, fwctx->code, nvram, nvram_length);
> + complete(&fwctx->completion);
> kfree(fwctx);
>
* Steven Barth [01.06.2015 10:46]:
> Is that okay with you as well https://dev.openwrt.org/changeset/45867 ?
it's ok for me, but IMHO not the proper way,
because you are hiding errors, if there are any...
bye, bastian
___
openwrt-devel mailing list
ope
Is that okay with you as well https://dev.openwrt.org/changeset/45867 ?
Cheers,
Steven
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
2015-05-30 0:50 GMT+03:00 valent.turko...@gmail.com :
> Awesome news Sergey,
> will this patch be applied to latest trunk anytime soon so that I can test it?
I'm not aware of any plans like that, I wouldn't hold my breath. I'm
afraid you'll need to apply the patch yourself for the time being. The
Actually ignore this patch. After querying a bit more about the device
it seems it's not going to be released to the public in its current
form.
Sorry about the noise.
On 26 May 2015 at 08:45, Cristian Morales Vega wrote:
> I can't find any reference online. It's similar (the case looks the
> s
13 matches
Mail list logo
