Re: [OpenWrt-Devel] [PATCH procd 2/4] ujail: remove useless arg in clone call

2015-11-23 Thread John Crispin


On 23/11/2015 09:09, Etienne Champetier wrote:
> Hi,
> 
> Le 23 nov. 2015 08:18, "John Crispin"  > a écrit :
>>
>>
>>
>> On 23/11/2015 01:39, Etienne CHAMPETIER wrote:
>> > spawn_jail(void) produce a compilation error,
>> > so we use spawn_jail()
>> >
>> > Signed-off-by: Etienne CHAMPETIER  >
>> > ---
>> >  jail/jail.c | 4 ++--
>> >  1 file changed, 2 insertions(+), 2 deletions(-)
>> >
>> > diff --git a/jail/jail.c b/jail/jail.c
>> > index 56dc9ca..08babde 100644
>> > --- a/jail/jail.c
>> > +++ b/jail/jail.c
>> > @@ -272,7 +272,7 @@ static int exec_jail()
>> >   exit(EXIT_FAILURE);
>> >  }
>> >
>> > -static int spawn_jail(void *arg)
>> > +static int spawn_jail()
>>
>> Hi,
>>
>> this is still wrong. also you might want to write a sentence why it is
>> useless.
>>
> 
> Well, we don't use it, and passing arg to not use it really doesn't
> improve readability.
> 
> I know it break your code style, but it seems we can't have both here :(
> 
> Etienne
> 
>> John


i wont merge it until there is a (void). it is valid code. try it and
you will see that i am right.



>>
>> >  {
>> >   if (opts.name  && sethostname(opts.name
> , strlen(opts.name ))) {
>> >   ERROR("failed to sethostname: %s\n", strerror(errno));
>> > @@ -424,7 +424,7 @@ int main(int argc, char **argv)
>> >   if (opts.namespace) {
>> >   jail_process.pid = clone(spawn_jail,
>> >   child_stack + STACK_SIZE,
>> > - CLONE_NEWUTS | CLONE_NEWPID | CLONE_NEWNS |
> CLONE_NEWIPC | SIGCHLD, argv);
>> > + CLONE_NEWUTS | CLONE_NEWPID | CLONE_NEWNS |
> CLONE_NEWIPC | SIGCHLD, NULL);
>> >   } else {
>> >   jail_process.pid = fork();
>> >   }
>> >
> 
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel


Re: [OpenWrt-Devel] [PATCH procd 3/4] ujail: use const, stop using extern

2015-11-23 Thread Etienne Champetier
Hi
Le 23 nov. 2015 08:19, "John Crispin"  a écrit :
>
> Hi,
>
> subject relates to extern but then the patch adds const. please make the
> description consistent with the content
>

The subject do start with "use const"
I will improve it in v2

> John
>
> On 23/11/2015 01:39, Etienne CHAMPETIER wrote:
> > extern for function declaration in '.h' doesn't make sense
> >
> > Signed-off-by: Etienne CHAMPETIER 
> > ---
> >  jail/elf.c | 28 +++-
> >  jail/elf.h | 10 +-
> >  2 files changed, 20 insertions(+), 18 deletions(-)
> >
> > diff --git a/jail/elf.c b/jail/elf.c
> > index 34a5aca..a26aa0b 100644
> > --- a/jail/elf.c
> > +++ b/jail/elf.c
> > @@ -69,7 +69,7 @@ static void alloc_library(const char *path, const
char *name)
> >   DEBUG("adding library %s/%s\n", path, name);
> >  }
> >
> > -static int elf_open(char **dir, char *file)
> > +static int elf_open(char **dir, const char *file)
> >  {
> >   struct library_path *p;
> >   char path[256];
> > @@ -95,7 +95,7 @@ static int elf_open(char **dir, char *file)
> >   return fd;
> >  }
> >
> > -char* find_lib(char *file)
> > +char* find_lib(const char *file)
> >  {
> >   struct library *l;
> >   static char path[256];
> > @@ -114,7 +114,7 @@ char* find_lib(char *file)
> >   return path;
> >  }
> >
> > -static int elf64_find_section(char *map, unsigned int type, unsigned
int *offset, unsigned int *size, unsigned int *vaddr)
> > +static int elf64_find_section(const char *map, unsigned int type,
unsigned int *offset, unsigned int *size, unsigned int *vaddr)
> >  {
> >   Elf64_Ehdr *e;
> >   Elf64_Phdr *ph;
> > @@ -137,7 +137,7 @@ static int elf64_find_section(char *map, unsigned
int type, unsigned int *offset
> >   return -1;
> >  }
> >
> > -static int elf32_find_section(char *map, unsigned int type, unsigned
int *offset, unsigned int *size, unsigned int *vaddr)
> > +static int elf32_find_section(const char *map, unsigned int type,
unsigned int *offset, unsigned int *size, unsigned int *vaddr)
> >  {
> >   Elf32_Ehdr *e;
> >   Elf32_Phdr *ph;
> > @@ -160,7 +160,7 @@ static int elf32_find_section(char *map, unsigned
int type, unsigned int *offset
> >   return -1;
> >  }
> >
> > -static int elf_find_section(char *map, unsigned int type, unsigned int
*offset, unsigned int *size, unsigned int *vaddr)
> > +static int elf_find_section(const char *map, unsigned int type,
unsigned int *offset, unsigned int *size, unsigned int *vaddr)
> >  {
> >   int clazz = map[EI_CLASS];
> >
> > @@ -174,10 +174,10 @@ static int elf_find_section(char *map, unsigned
int type, unsigned int *offset,
> >   return -1;
> >  }
> >
> > -static int elf32_scan_dynamic(char *map, int dyn_offset, int dyn_size,
int load_offset)
> > +static int elf32_scan_dynamic(const char *map, int dyn_offset, int
dyn_size, int load_offset)
> >  {
> >   Elf32_Dyn *dynamic = (Elf32_Dyn *) (map + dyn_offset);
> > - char *strtab = NULL;
> > + const char *strtab = NULL;
> >
> >   while ((void *) dynamic < (void *) (map + dyn_offset + dyn_size))
{
> >   Elf32_Dyn *curr = dynamic;
> > @@ -208,10 +208,10 @@ static int elf32_scan_dynamic(char *map, int
dyn_offset, int dyn_size, int load_
> >   return 0;
> >  }
> >
> > -static int elf64_scan_dynamic(char *map, int dyn_offset, int dyn_size,
int load_offset)
> > +static int elf64_scan_dynamic(const char *map, int dyn_offset, int
dyn_size, int load_offset)
> >  {
> >   Elf64_Dyn *dynamic = (Elf64_Dyn *) (map + dyn_offset);
> > - char *strtab = NULL;
> > + const char *strtab = NULL;
> >
> >   while ((void *) dynamic < (void *) (map + dyn_offset + dyn_size))
{
> >   Elf64_Dyn *curr = dynamic;
> > @@ -242,7 +242,7 @@ static int elf64_scan_dynamic(char *map, int
dyn_offset, int dyn_size, int load_
> >   return 0;
> >  }
> >
> > -int elf_load_deps(char *library)
> > +int elf_load_deps(const char *library)
> >  {
> >   unsigned int dyn_offset, dyn_size;
> >   unsigned int load_offset, load_vaddr;
> > @@ -288,10 +288,12 @@ int elf_load_deps(char *library)
> >   if (dir) {
> >   alloc_library(dir, library);
> >   } else {
> > - char *elf = strdup(library);
> > + char *elf1 = strdup(library);
> > + char *elf2 = strdup(library);
> >
> > - alloc_library(dirname(elf), basename(library));
> > - free(elf);
> > + alloc_library(dirname(elf1), basename(elf2));
> > + free(elf1);
> > + free(elf2);
> >   }
> >   clazz = map[EI_CLASS];
> >
> > diff --git a/jail/elf.h b/jail/elf.h
> > index 3ae311e..6c14c39 100644
> > --- a/jail/elf.h
> > +++ b/jail/elf.h
> > @@ -28,11 +28,11 @@ struct library_path {
> >   char *path;
> >  };
> >
> > -extern struct avl_tree libraries;
> > +struct avl_tree libraries;
> >
> > -extern void alloc_library_path(const char *path);
> 

Re: [OpenWrt-Devel] [PATCH procd 2/4] ujail: remove useless arg in clone call

2015-11-23 Thread Etienne Champetier
Hi,

Le 23 nov. 2015 08:18, "John Crispin"  a écrit :
>
>
>
> On 23/11/2015 01:39, Etienne CHAMPETIER wrote:
> > spawn_jail(void) produce a compilation error,
> > so we use spawn_jail()
> >
> > Signed-off-by: Etienne CHAMPETIER 
> > ---
> >  jail/jail.c | 4 ++--
> >  1 file changed, 2 insertions(+), 2 deletions(-)
> >
> > diff --git a/jail/jail.c b/jail/jail.c
> > index 56dc9ca..08babde 100644
> > --- a/jail/jail.c
> > +++ b/jail/jail.c
> > @@ -272,7 +272,7 @@ static int exec_jail()
> >   exit(EXIT_FAILURE);
> >  }
> >
> > -static int spawn_jail(void *arg)
> > +static int spawn_jail()
>
> Hi,
>
> this is still wrong. also you might want to write a sentence why it is
> useless.
>

Well, we don't use it, and passing arg to not use it really doesn't improve
readability.

I know it break your code style, but it seems we can't have both here :(

Etienne

> John
>
> >  {
> >   if (opts.name && sethostname(opts.name, strlen(opts.name))) {
> >   ERROR("failed to sethostname: %s\n", strerror(errno));
> > @@ -424,7 +424,7 @@ int main(int argc, char **argv)
> >   if (opts.namespace) {
> >   jail_process.pid = clone(spawn_jail,
> >   child_stack + STACK_SIZE,
> > - CLONE_NEWUTS | CLONE_NEWPID | CLONE_NEWNS |
CLONE_NEWIPC | SIGCHLD, argv);
> > + CLONE_NEWUTS | CLONE_NEWPID | CLONE_NEWNS |
CLONE_NEWIPC | SIGCHLD, NULL);
> >   } else {
> >   jail_process.pid = fork();
> >   }
> >
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel


Re: [OpenWrt-Devel] buildbot: gb15 fails to upload due to host keys

2015-11-23 Thread Zoltan HERPAI

Hannu A Nyman wrote:
Well, both gb15 and buildslave2 still fail to upload binaries, and as 
they are making 9 of the 22 concurrent builds, almost half of the 
compiled binaries are discarded. Sad.


Logs from today:
http://buildbot.openwrt.org:8010/builders/x86.kvm_guest/builds/119/steps/shell_11/logs/stdio 

http://buildbot.openwrt.org:8010/builders/brcm2708/builds/126/steps/shell_11/logs/stdio 



 Upload Snapshot to Openwrt
 Host key verification failed.
 rsync: connection unexpectedly closed (0 bytes received so far) [sender]
 rsync error: unexplained error (code 255) at io.c(605) [sender=3.0.9]

gb15 is fixed now.

Regards,
-w-
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel


Re: [OpenWrt-Devel] buildbot: gb15 fails to upload due to host keys

2015-11-23 Thread Zoltan HERPAI



On Mon, 23 Nov 2015, Dave Taht wrote:


On Mon, Nov 23, 2015 at 11:07 AM, Zoltan HERPAI  wrote:

Hannu A Nyman wrote:


Well, both gb15 and buildslave2 still fail to upload binaries, and as they
are making 9 of the 22 concurrent builds, almost half of the compiled
binaries are discarded. Sad.

Logs from today:

http://buildbot.openwrt.org:8010/builders/x86.kvm_guest/builds/119/steps/shell_11/logs/stdio

http://buildbot.openwrt.org:8010/builders/brcm2708/builds/126/steps/shell_11/logs/stdio

 Upload Snapshot to Openwrt
 Host key verification failed.
 rsync: connection unexpectedly closed (0 bytes received so far) [sender]
 rsync error: unexplained error (code 255) at io.c(605) [sender=3.0.9]


gb15 is fixed now.


I note that I have long been paying for the google openwrt build
cluster out of my own pocket (after the google grant expired last year
- which was costing 1700/month for 5? 6? servers), but I had cut it
down to just gb10, which is cost me about $250/month.

I am hoping some more grant money arrives (not a lot!) next year.

I was unaware of gb15 (not coming out of my account, thankfully), and
am glad someone else is covering costs on it...

IF there is a need to turn around openwrt builds even quicker, (how
much quicker can it be done?) we can re-scale up my old google cluster
if there is funding for it from somewhere. I can keep the one server
I'm contributing up and running indefinitely. Or... ?

I have always wished we could do a full build in under 3 hours, and
could circulate package changes around in minutes, rather than in a
full build.


This is not a googlebuild server. I've asked Travis to rename the host to 
make the name less confusing, that's yet to happen.


Thanks,
-w-
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel


Re: [OpenWrt-Devel] buildbot: gb15 fails to upload due to host keys

2015-11-23 Thread Dave Taht
On Mon, Nov 23, 2015 at 11:07 AM, Zoltan HERPAI  wrote:
> Hannu A Nyman wrote:
>>
>> Well, both gb15 and buildslave2 still fail to upload binaries, and as they
>> are making 9 of the 22 concurrent builds, almost half of the compiled
>> binaries are discarded. Sad.
>>
>> Logs from today:
>>
>> http://buildbot.openwrt.org:8010/builders/x86.kvm_guest/builds/119/steps/shell_11/logs/stdio
>>
>> http://buildbot.openwrt.org:8010/builders/brcm2708/builds/126/steps/shell_11/logs/stdio
>>
>>  Upload Snapshot to Openwrt
>>  Host key verification failed.
>>  rsync: connection unexpectedly closed (0 bytes received so far) [sender]
>>  rsync error: unexplained error (code 255) at io.c(605) [sender=3.0.9]
>
> gb15 is fixed now.

I note that I have long been paying for the google openwrt build
cluster out of my own pocket (after the google grant expired last year
- which was costing 1700/month for 5? 6? servers), but I had cut it
down to just gb10, which is cost me about $250/month.

I am hoping some more grant money arrives (not a lot!) next year.

I was unaware of gb15 (not coming out of my account, thankfully), and
am glad someone else is covering costs on it...

IF there is a need to turn around openwrt builds even quicker, (how
much quicker can it be done?) we can re-scale up my old google cluster
if there is funding for it from somewhere. I can keep the one server
I'm contributing up and running indefinitely. Or... ?

I have always wished we could do a full build in under 3 hours, and
could circulate package changes around in minutes, rather than in a
full build.



>
> Regards,
>
> -w-
> ___
> openwrt-devel mailing list
> openwrt-devel@lists.openwrt.org
> https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel


Re: [OpenWrt-Devel] [PATCH procd 2/4] ujail: remove useless arg in clone call

2015-11-23 Thread Paul Fertser
Hey Etienne,

Etienne Champetier  writes:
> i know that spawn_jail(void) is valid code, but then the clone call
> refuses to compile

That's type-safety for you. spawn_jail() is valid code too but it's not
type-safe, so AFAICT you're avoiding the errors by letting the compiler
ignore them, not by providing a proper solution. :)

-- 
Be free, use free (http://www.gnu.org/philosophy/free-sw.html) software!
mailto:fercer...@gmail.com
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel


[OpenWrt-Devel] [PATCH v4] [ramips] mt7621: add support for netis WF-2881‏

2015-11-23 Thread YounJae Rho
netis WF-2881 is an MT7621AT based router with MT7602EN, MT7612EN.
It has 128MB DDR3, 128MB SLC NAND FLASH, 5-port Gbps switch and 1x USB 3.0.
The following patch adds support for this device.

this device only works on top of UBI.

Tested and working:
* ethernet
* both WiFi radios
* USB 3.0
* buttons (reset button)
* ethernet switch and USB diag LEDs
* UART
* GPIOs
* sysupgrade

Tested and not working
* failsafe


Signed-off-by: YounJae Rho 
---
tested with git-am (trunk d1104b7ae3de77093756c0124e4946745c06c2f1)


 target/linux/ramips/Makefile   |   2 +-
 target/linux/ramips/base-files/etc/board.d/01_leds |   3 +-
 .../linux/ramips/base-files/etc/board.d/02_network |   1 +
 target/linux/ramips/base-files/etc/diag.sh |   1 +
 target/linux/ramips/base-files/lib/ramips.sh   |   3 +
 .../ramips/base-files/lib/upgrade/platform.sh  |   1 +
 target/linux/ramips/dts/WF-2881.dts| 133 +
 target/linux/ramips/image/Makefile |  11 +-
 target/linux/ramips/mt7621/config-3.18 |  24 +++-
 target/linux/ramips/mt7621/profiles/netis.mk   |  23 
 10 files changed, 198 insertions(+), 4 deletions(-)
 create mode 100644 target/linux/ramips/dts/WF-2881.dts
 create mode 100644 target/linux/ramips/mt7621/profiles/netis.mk

diff --git a/target/linux/ramips/Makefile b/target/linux/ramips/Makefile
index eafd274..a92b287 100644
--- a/target/linux/ramips/Makefile
+++ b/target/linux/ramips/Makefile
@@ -10,7 +10,7 @@ ARCH:=mipsel
 BOARD:=ramips
 BOARDNAME:=Ralink RT288x/RT3xxx
 SUBTARGETS:=rt305x mt7620 mt7621 mt7628 mt7688 rt3883 rt288x
-FEATURES:=squashfs gpio
+FEATURES:=squashfs gpio ubifs
 MAINTAINER:=John Crispin 
 
 KERNEL_PATCHVER:=3.18
diff --git a/target/linux/ramips/base-files/etc/board.d/01_leds 
b/target/linux/ramips/base-files/etc/board.d/01_leds
index 5627c8c..a365c61 100755
--- a/target/linux/ramips/base-files/etc/board.d/01_leds
+++ b/target/linux/ramips/base-files/etc/board.d/01_leds
@@ -44,7 +44,8 @@ air3gii)
 all0239-3g|\
 hw550-3g|\
 mofi3500-3gn|\
-sap-g3200u3)
+sap-g3200u3|\
+wf-2881)
set_usb_led "$board:green:usb"
;;
 all0256n)
diff --git a/target/linux/ramips/base-files/etc/board.d/02_network 
b/target/linux/ramips/base-files/etc/board.d/02_network
index 3821742..45778f3 100755
--- a/target/linux/ramips/base-files/etc/board.d/02_network
+++ b/target/linux/ramips/base-files/etc/board.d/02_network
@@ -78,6 +78,7 @@ ramips_setup_interfaces()
oy-0001|\
pbr-m1|\
sap-g3200u3|\
+   wf-2881|\
whr-300hp2|\
whr-600d|\
wsr-1166|\
diff --git a/target/linux/ramips/base-files/etc/diag.sh 
b/target/linux/ramips/base-files/etc/diag.sh
index 3013d24..ff5fbf2 100644
--- a/target/linux/ramips/base-files/etc/diag.sh
+++ b/target/linux/ramips/base-files/etc/diag.sh
@@ -155,6 +155,7 @@ get_status_led() {
tew-692gr|\
ur-326n4g|\
ur-336un|\
+   wf-2881|\
wr512-3gn)
status_led="$board:green:wps"
;;
diff --git a/target/linux/ramips/base-files/lib/ramips.sh 
b/target/linux/ramips/base-files/lib/ramips.sh
index a1bcb72..eb2f194 100755
--- a/target/linux/ramips/base-files/lib/ramips.sh
+++ b/target/linux/ramips/base-files/lib/ramips.sh
@@ -376,6 +376,9 @@ ramips_board_detect() {
*"WCR-150GN")
name="wcr-150gn"
;;
+   *"WF-2881")
+   name="wf-2881"
+   ;;
*"WHR-1166D")
name="whr-1166d"
;;
diff --git a/target/linux/ramips/base-files/lib/upgrade/platform.sh 
b/target/linux/ramips/base-files/lib/upgrade/platform.sh
index 0e8d619..19ab5a2 100755
--- a/target/linux/ramips/base-files/lib/upgrade/platform.sh
+++ b/target/linux/ramips/base-files/lib/upgrade/platform.sh
@@ -108,6 +108,7 @@ platform_check_image() {
w150m|\
w306r-v20|\
w502u|\
+   wf-2881|\
whr-1166d|\
whr-300hp2|\
whr-600d|\
diff --git a/target/linux/ramips/dts/WF-2881.dts 
b/target/linux/ramips/dts/WF-2881.dts
new file mode 100644
index 000..7228dc5
--- /dev/null
+++ b/target/linux/ramips/dts/WF-2881.dts
@@ -0,0 +1,133 @@
+/dts-v1/;
+
+/include/ "mt7621.dtsi"
+
+/ {
+   compatible = "mediatek,mt7621-eval-board", "mediatek,mt7621-soc";
+   model = "NETIS WF-2881";
+
+   memory@0 {
+   device_type = "memory";
+   reg = <0x0 0x800>;
+   };
+
+   palmbus@1E00 {
+   spi@b00 {
+   status="disabled";
+   };
+   };
+
+   chosen {
+   bootargs = "console=ttyS0,57600";
+   };
+
+   nand@1e003000 {
+   compatible = "mtk,mt7621-nand";
+   bank-width = <2>;
+   reg = <0x1e003000 0x800
+   0x1e003800 0x800>;
+   #address-cells = <1>;
+   #size-cells = 

Re: [OpenWrt-Devel] API documentation of ubus

2015-11-23 Thread Srdjan Rosic
Hi,

--[Far from being an authoritative source, but just happen to be
subscribed to the mailing list]--

I had a brief look at the ubus repo when you first sent an email, and
the header files were pretty usable imho, laid out in a way I'd
consider to be logical, and if you've ever written any kind of
client/server code ubus terminology isn't far off, and you should be
able to find your way around.

Most openwrt users just want to glue stuff in shell, and I found this
wiki to have useful examples for that (if that's what you want to do):
https://wiki.openwrt.org/doc/techref/ubus

If I were you, and were looking for examples, I'd look at existing
openwrt binaries, since they use ubus and try to follow the same
patterns.

-s

P.S. As with any software, you should write integration tests that
exercise the functionality of your software, in order to ensure
possible future changes don't break your software in unintended ways.
Srdjan Rosic


On Sat, Nov 21, 2015 at 11:49 AM, Pratik Prajapati
 wrote:
> Gentle Reminder
>
> On Fri, Nov 20, 2015 at 6:29 PM, Pratik Prajapati
>  wrote:
>>
>> Hi,
>>
>> Is there any API documentation of ubus available?
>>
>> If yes, where can i found those?
>>
>
>
> ___
> openwrt-devel mailing list
> openwrt-devel@lists.openwrt.org
> https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
>
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel


Re: [OpenWrt-Devel] [PATCH procd 2/4] ujail: remove useless arg in clone call

2015-11-23 Thread Etienne Champetier
Hey,

2015-11-23 12:52 GMT+01:00 Paul Fertser :

> Hey Etienne,
>
> Etienne Champetier  writes:
> > i know that spawn_jail(void) is valid code, but then the clone call
> > refuses to compile
>
> That's type-safety for you. spawn_jail() is valid code too but it's not
> type-safe, so AFAICT you're avoiding the errors by letting the compiler
> ignore them, not by providing a proper solution. :)
>

clone really want a function like "int fn(void * arg)"

Is

> *static int spawn_jail(void * _notused)*
>
ok for you both?

Etienne
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel


[OpenWrt-Devel] ath9k-htc init

2015-11-23 Thread Alexey Brodkin
Hi Felix, Jonas,

While playing with my AXS101 board and USB WI-Fi dongles I bumped in
a couple of issues. Fortunately I found at least one dongle that
works quite nice. That's TP-Link TL-WN721N (or its WN722N sibling)
which is based on Atheros AR9271 chip even though it did require
one unexpected tweak.

For starters I just selected "kmod-ath9k-htc" in menuconfig and
on boot saw USB device recognized, its firmware was loaded,
"wifi detect" recognized it as well, see log below.

But then "wlan0" interface was not created on "wifi" command.

After some googling I somehow came to resolution that "hostapd"
package installation fixes this problem. And indeed once I got
image rebuilt with "CONFIG_PACKAGE_hostapd=y" all worked as expected
and I was able to use my board as a Wi-Fi access point.

So the question is if this is expected (requirement for "hostapd")
[for "ath9k_htc"]?

Another minor issue is that USB dongle gets recognized a bit late
so that automatic "wifi detect" gets already executed and
"/etc/config/wireless" isn't created. That requires manual execution of
"wifi detect > /etc/config/wireless". Essentially extending delay in 
"package/base-files/files/etc/init.d/boot" makes a difference:
-->8---
# allow wifi modules time to settle
sleep 15 # instead of 1
-->8---
but I'm not sure if we want to do that change for all devices.
Then if there's a better way to make auto population of
"/etc/config/wireless"?

-Alexey

Generic arc770 + kmod-ath9k-htc (CONFIG_PACKAGE_kmod-ath9k-htc=y):
->8--
[1.14] usb 1-1: new high-speed USB device number 2 using ehci-platform
[1.71] init: - preinit -
Detected arc-sdp // Synopsys AXS101 Development Board
[1.80] random: mktemp urandom read with 3 bits of entropy available
Press the [f] key and hit [enter] to enter failsafe mode
Press the [1], [2], [3] or [4] key and hit [enter] to select the debug level
[4.93] procd: - early -
[5.54] procd: - ubus -
[6.55] procd: - init -
[7.15] Loading modules backported from Linux version 
master-2015-10-26-0-g28c26cb
[7.16] Backport generated by backports.git backports-20150903-4-g12cf266
[7.19] cfg80211: World regulatory domain updated:
[7.19] cfg80211:  DFS Master region: unset
[7.22] cfg80211:   (start_freq - end_freq @ bandwidth), 
(max_antenna_gain, max_eirp), (dfs_cac_time)
[7.24] cfg80211:   (2402000 KHz - 2472000 KHz @ 4 KHz), (N/A, 2000 
mBm), (N/A)
[7.26] cfg80211:   (2457000 KHz - 2482000 KHz @ 4 KHz), (N/A, 2000 
mBm), (N/A)
[7.26] cfg80211:   (2474000 KHz - 2494000 KHz @ 2 KHz), (N/A, 2000 
mBm), (N/A)
[7.28] cfg80211:   (517 KHz - 525 KHz @ 8 KHz, 16 KHz 
AUTO), (N/A, 2000 mBm), (N/A)
[7.28] cfg80211:   (525 KHz - 533 KHz @ 8 KHz, 16 KHz 
AUTO), (N/A, 2000 mBm), (0 s)
[7.30] cfg80211:   (549 KHz - 573 KHz @ 16 KHz), (N/A, 2000 
mBm), (0 s)
[7.30] cfg80211:   (5735000 KHz - 5835000 KHz @ 8 KHz), (N/A, 2000 
mBm), (N/A)
[7.32] cfg80211:   (5724 KHz - 6372 KHz @ 216 KHz), (N/A, 0 
mBm), (N/A)
[7.36] usb 1-1: ath9k_htc: Firmware ath9k_htc/htc_9271-1.4.0.fw 
requested
[7.37] usb 1-1: Direct firmware load for ath9k_htc/htc_9271-1.4.0.fw 
failed with error -2
[7.38] usb 1-1: Falling back to user helper
[7.40] usbcore: registered new interface driver ath9k_htc
[7.41] firmware ath9k_htc!htc_9271-1.4.0.fw: firmware_loading_store: 
map pages failed
[7.42] usb 1-1: ath9k_htc: Firmware htc_9271.fw requested
[7.73] usb 1-1: ath9k_htc: Transferred FW: htc_9271.fw, size: 50980
[7.97] ath9k_htc 1-1:1.0: ath9k_htc: HTC initialized with 33 credits
[   10.30] ath9k_htc 1-1:1.0: ath9k_htc: FW Version: 1.3
[   10.30] ath9k_htc 1-1:1.0: FW RMW support: Off
[   10.41] ieee80211 phy0: Atheros AR9271 Rev:1
[   10.41] cfg80211: Regulatory domain changed to country: CN
[   10.46] cfg80211:  DFS Master region: FCC
[   10.46] cfg80211:   (start_freq - end_freq @ bandwidth), 
(max_antenna_gain, max_eirp), (dfs_cac_time)
[   10.51] cfg80211:   (2402000 KHz - 2482000 KHz @ 4 KHz), (N/A, 2000 
mBm), (N/A)
[   10.51] cfg80211:   (517 KHz - 525 KHz @ 8 KHz, 16 KHz 
AUTO), (N/A, 2300 mBm), (N/A)
[   10.56] cfg80211:   (525 KHz - 533 KHz @ 8 KHz, 16 KHz 
AUTO), (N/A, 2300 mBm), (0 s)
[   10.56] cfg80211:   (5735000 KHz - 5835000 KHz @ 8 KHz), (N/A, 3000 
mBm), (N/A)
[   10.61] cfg80211:   (5724 KHz - 5940 KHz @ 216 KHz), (N/A, 
2800 mBm), (N/A)
[   10.61] cfg80211:   (5940 KHz - 6372 KHz @ 216 KHz), (N/A, 
4400 mBm), (N/A)
[   10.67] cfg80211:   (6372 KHz - 6588 KHz @ 216 KHz), (N/A, 
2800 

[OpenWrt-Devel] [PATCH] axs10x: initilaze network for wireless access-point

2015-11-23 Thread Alexey Brodkin
ARC SDP board sports only 1 network interface - eth0,
so to operate as an access point it requires at least
another interface (preferably wireless),
so USB Wi-Fi dongle is what we want.

And with USB Wi-Fi dongle attached ARC SDP board could be
used as a "dumb" wireless access point.

Now with modified network setup script it is only required
to enable wireless radio on the first boot with
-->8
uci set wireless.radio0.disabled=0
uci commit wireless
wifi
-->8

Note if by the time initscripts are executed USB Wi-Fi
dongle not yet recognized and set up by Linux kernel
its autodetection by "wifi" tool may not happen
automatically. In that case before issuing command above
one needs to populate /etc/config/wireless config:
-->8
wifi detect > /etc/config/wireless
-->8

Signed-off-by: Alexey Brodkin 
Cc: Felix Fietkau 
Cc: Jo-Philipp Wich 
Cc: Jonas Gorski 
---
 target/linux/arc770/base-files/etc/uci-defaults/02_network | 12 +++-
 1 file changed, 11 insertions(+), 1 deletion(-)

diff --git a/target/linux/arc770/base-files/etc/uci-defaults/02_network 
b/target/linux/arc770/base-files/etc/uci-defaults/02_network
index 87cfe81..7503f85 100644
--- a/target/linux/arc770/base-files/etc/uci-defaults/02_network
+++ b/target/linux/arc770/base-files/etc/uci-defaults/02_network
@@ -14,7 +14,17 @@ ucidef_set_interface_loopback
 
 case "$( arc_board_name )" in
 "arc-sdp"*)
-   ucidef_set_interface_raw "lan" "eth0" "dhcp"
+   uci set network.lan='interface'
+   uci set network.lan.type='bridge'
+   uci set network.lan.ifname='eth0 wlan0'
+   uci set network.lan.proto='dhcp'
+   # With multicast-to-unicast enabled kernel crashes
+   # on the first wireless client connection in
+   # br_multicast_add_group() -> br_port_group_equal() ->
+   # ether_addr_equal() due to misaligned read.
+   # For some reason "src" being "eth_hdr(skb)->h_source"
+   # is not 16-bit aligned as it is supposed to be.
+   uci set network.lan.multicast_to_unicast='0'
;;
 esac
 
-- 
2.5.0
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel


Re: [OpenWrt-Devel] [PATCH procd 2/4] ujail: remove useless arg in clone call

2015-11-23 Thread Etienne Champetier
2015-11-23 9:11 GMT+01:00 John Crispin :

>
>
> On 23/11/2015 09:09, Etienne Champetier wrote:
> > Hi,
> >
> > Le 23 nov. 2015 08:18, "John Crispin"  > > a écrit :
> >>
> >>
> >>
> >> On 23/11/2015 01:39, Etienne CHAMPETIER wrote:
> >> > spawn_jail(void) produce a compilation error,
> >> > so we use spawn_jail()
> >> >
> >> > Signed-off-by: Etienne CHAMPETIER  > >
> >> > ---
> >> >  jail/jail.c | 4 ++--
> >> >  1 file changed, 2 insertions(+), 2 deletions(-)
> >> >
> >> > diff --git a/jail/jail.c b/jail/jail.c
> >> > index 56dc9ca..08babde 100644
> >> > --- a/jail/jail.c
> >> > +++ b/jail/jail.c
> >> > @@ -272,7 +272,7 @@ static int exec_jail()
> >> >   exit(EXIT_FAILURE);
> >> >  }
> >> >
> >> > -static int spawn_jail(void *arg)
> >> > +static int spawn_jail()
> >>
> >> Hi,
> >>
> >> this is still wrong. also you might want to write a sentence why it is
> >> useless.
> >>
> >
> > Well, we don't use it, and passing arg to not use it really doesn't
> > improve readability.
> >
> > I know it break your code style, but it seems we can't have both here :(
> >
> > Etienne
> >
> >> John
>
>
> i wont merge it until there is a (void). it is valid code. try it and
> you will see that i am right.
>
> sorry my commit message is bad

try to put NULL at the end of the clone() call, and try with spawn_jail()
and
spawn_jail(void), and you will see

i know that spawn_jail(void) is valid code, but then the clone call refuses
to compile

*/home/etienne/procd/jail/jail.c: In function ‘main’:*
> */home/etienne/procd/jail/jail.c:381:4: error: passing argument 1 of
> ‘clone’ from incompatible pointer type [-Werror]*
> *CLONE_NEWUTS | CLONE_NEWPID | CLONE_NEWNS | CLONE_NEWIPC | SIGCHLD,
> NULL);*
> *^*
> *In file included from /usr/include/sched.h:41:0,*
> * from /home/etienne/procd/jail/jail.c:26:*
> */usr/include/x86_64-linux-gnu/bits/sched.h:81:12: note: expected ‘int
> (*)(void *)’ but argument is of type ‘int (*)(void)’*
> * extern int clone (int (*__fn) (void *__arg), void *__child_stack,*
> *^*
> *cc1: all warnings being treated as errors*
> *make[2]: *** [CMakeFiles/ujail.dir/jail/jail.c.o] Error 1*
> *make[1]: *** [CMakeFiles/ujail.dir/all] Error 2*
> *make: *** [all] Error 2*
>





>
> >>
> >> >  {
> >> >   if (opts.name  && sethostname(opts.name
> > , strlen(opts.name ))) {
> >> >   ERROR("failed to sethostname: %s\n", strerror(errno));
> >> > @@ -424,7 +424,7 @@ int main(int argc, char **argv)
> >> >   if (opts.namespace) {
> >> >   jail_process.pid = clone(spawn_jail,
> >> >   child_stack + STACK_SIZE,
> >> > - CLONE_NEWUTS | CLONE_NEWPID | CLONE_NEWNS |
> > CLONE_NEWIPC | SIGCHLD, argv);
> >> > + CLONE_NEWUTS | CLONE_NEWPID | CLONE_NEWNS |
> > CLONE_NEWIPC | SIGCHLD, NULL);
> >> >   } else {
> >> >   jail_process.pid = fork();
> >> >   }
> >> >
> >
>
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel


[OpenWrt-Devel] [PATCH] arc770/axs101: accomodate DW GMAC long reset sequence

2015-11-23 Thread Alexey Brodkin
On ARC SDP board DMA block of DW GMAC gets out of reset much
longer than expected by default driver.

For now to accomodate this issue we're extending timeout value.

Signed-off-by: Alexey Brodkin 
---
 .../0003-fix-GMAC-init-by-longer-reset-wait.patch  | 45 ++
 1 file changed, 45 insertions(+)
 create mode 100644 
target/linux/arc770/patches-4.3/0003-fix-GMAC-init-by-longer-reset-wait.patch

diff --git 
a/target/linux/arc770/patches-4.3/0003-fix-GMAC-init-by-longer-reset-wait.patch 
b/target/linux/arc770/patches-4.3/0003-fix-GMAC-init-by-longer-reset-wait.patch
new file mode 100644
index 000..8bab11d
--- /dev/null
+++ 
b/target/linux/arc770/patches-4.3/0003-fix-GMAC-init-by-longer-reset-wait.patch
@@ -0,0 +1,45 @@
+From ed78bec3722022f6622f1810111f43e5e752baf6 Mon Sep 17 00:00:00 2001
+From: Alexey Brodkin 
+Date: Mon, 16 Nov 2015 23:15:54 +0300
+Subject: [PATCH] fix GMAC init by longer reset wait
+
+On ARC SDP board DMA block of DW GMAC gets out of reset much
+longer than expected by default driver.
+
+For now to accomodate this issue we're extending timeout value.
+
+Signed-off-by: Alexey Brodkin 
+---
+ drivers/net/ethernet/stmicro/stmmac/dwmac1000_dma.c | 2 +-
+ drivers/net/ethernet/stmicro/stmmac/dwmac100_dma.c  | 2 +-
+ 2 files changed, 2 insertions(+), 2 deletions(-)
+
+diff --git a/drivers/net/ethernet/stmicro/stmmac/dwmac1000_dma.c 
b/drivers/net/ethernet/stmicro/stmmac/dwmac1000_dma.c
+index 0e8937c..f29cf5b 100644
+--- a/drivers/net/ethernet/stmicro/stmmac/dwmac1000_dma.c
 b/drivers/net/ethernet/stmicro/stmmac/dwmac1000_dma.c
+@@ -39,7 +39,7 @@ static int dwmac1000_dma_init(void __iomem *ioaddr, int pbl, 
int fb, int mb,
+   /* DMA SW reset */
+   value |= DMA_BUS_MODE_SFT_RESET;
+   writel(value, ioaddr + DMA_BUS_MODE);
+-  limit = 10;
++  limit = 1000;
+   while (limit--) {
+   if (!(readl(ioaddr + DMA_BUS_MODE) & DMA_BUS_MODE_SFT_RESET))
+   break;
+diff --git a/drivers/net/ethernet/stmicro/stmmac/dwmac100_dma.c 
b/drivers/net/ethernet/stmicro/stmmac/dwmac100_dma.c
+index 9d0971c..651d94c 100644
+--- a/drivers/net/ethernet/stmicro/stmmac/dwmac100_dma.c
 b/drivers/net/ethernet/stmicro/stmmac/dwmac100_dma.c
+@@ -41,7 +41,7 @@ static int dwmac100_dma_init(void __iomem *ioaddr, int pbl, 
int fb, int mb,
+   /* DMA SW reset */
+   value |= DMA_BUS_MODE_SFT_RESET;
+   writel(value, ioaddr + DMA_BUS_MODE);
+-  limit = 10;
++  limit = 1000;
+   while (limit--) {
+   if (!(readl(ioaddr + DMA_BUS_MODE) & DMA_BUS_MODE_SFT_RESET))
+   break;
+-- 
+2.5.0
+
-- 
2.5.0
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel


[OpenWrt-Devel] [PATCH 1/1] ramips: add second spi master sysclk

2015-11-23 Thread Michael Lee
for mt7620, rt3883 and rt5350

Signed-off-by: Michael Lee 
---
 .../patches-3.18/0305-second_spi_sysclk.patch  | 30 ++
 1 file changed, 30 insertions(+)
 create mode 100644 
target/linux/ramips/patches-3.18/0305-second_spi_sysclk.patch

diff --git a/target/linux/ramips/patches-3.18/0305-second_spi_sysclk.patch 
b/target/linux/ramips/patches-3.18/0305-second_spi_sysclk.patch
new file mode 100644
index 000..dffec5e
--- /dev/null
+++ b/target/linux/ramips/patches-3.18/0305-second_spi_sysclk.patch
@@ -0,0 +1,30 @@
+--- a/arch/mips/ralink/mt7620.c
 b/arch/mips/ralink/mt7620.c
+@@ -434,6 +434,7 @@ void __init ralink_clk_init(void)
+   ralink_clk_add("1100.timer", periph_rate);
+   ralink_clk_add("1120.watchdog", periph_rate);
+   ralink_clk_add("1b00.spi", sys_rate);
++  ralink_clk_add("1b40.spi", sys_rate);
+   ralink_clk_add("1c00.uartlite", periph_rate);
+   ralink_clk_add("1d00.uart1", periph_rate);
+   ralink_clk_add("1e00.uart2", periph_rate);
+--- a/arch/mips/ralink/rt305x.c
 b/arch/mips/ralink/rt305x.c
+@@ -199,6 +199,7 @@ void __init ralink_clk_init(void)
+   ralink_clk_add("cpu", cpu_rate);
+   ralink_clk_add("sys", sys_rate);
+   ralink_clk_add("1b00.spi", sys_rate);
++  ralink_clk_add("1b40.spi", sys_rate);
+   ralink_clk_add("1100.timer", wdt_rate);
+   ralink_clk_add("1120.watchdog", wdt_rate);
+   ralink_clk_add("1500.uart", uart_rate);
+--- a/arch/mips/ralink/rt3883.c
 b/arch/mips/ralink/rt3883.c
+@@ -109,6 +109,7 @@ void __init ralink_clk_init(void)
+   ralink_clk_add("1120.watchdog", sys_rate);
+   ralink_clk_add("1500.uart", 4000);
+   ralink_clk_add("1b00.spi", sys_rate);
++  ralink_clk_add("1b40.spi", sys_rate);
+   ralink_clk_add("1c00.uartlite", 4000);
+   ralink_clk_add("1010.ethernet", sys_rate);
+   ralink_clk_add("1018.wmac", 4000);
-- 
2.3.6
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel


Re: [OpenWrt-Devel] [PATCH] oxnas: set irq of usb to cpu1

2015-11-23 Thread Daniel Golle
On Mon, Nov 23, 2015 at 02:30:34PM +0800, Shonn Lu wrote:
> Signed-off-by: Shonn Lu 
> ---
>  .../linux/oxnas/base-files/init.d/set-irq-affinity | 22 
> ++
>  1 file changed, 22 insertions(+)
>  create mode 100755 target/linux/oxnas/base-files/init.d/set-irq-affinity
> 
> diff --git a/target/linux/oxnas/base-files/init.d/set-irq-affinity 
> b/target/linux/oxnas/base-files/init.d/set-irq-affinity
> new file mode 100755
> index 000..8ab066f
> --- /dev/null
> +++ b/target/linux/oxnas/base-files/init.d/set-irq-affinity
> @@ -0,0 +1,22 @@
> +#!/bin/sh /etc/rc.common
> +
> +START=99
> +
> +get_irq() {
> + local name="$1"
> + grep -m 1 "$name" /proc/interrupts | cut -d: -f1 | sed 's, *,,'
> +}
> +
> +set_irq_affinity() {
> + local name="$1"
> + local val="$2"
> + local irq="$(get_irq "$name")"
> + [ -n "$irq" ] || return
> + echo "$val" > "/proc/irq/$irq/smp_affinity"
> +}
> +
> +start() {
> + set_irq_affinity ehci_hcd 2
> + set_irq_affinity xhci_hcd 2
> + set_irq_affinity sata 2
> +}

I'm sorry to be such a pain, however, now that I have a closer look I
realize that naming is 'ehci_hcd' but 'xhci-hcd' (note: '-' vs. '_')
Maybe

set_irq_affinity ehci 2
set_irq_affinity xhci 2

is the safest for now and allows for kernel's driver naming to
eventually get unified in the future...


Cheers


Daniel
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel


Re: [OpenWrt-Devel] [PATCH V2] oxnas: set irq of usb to cpu1

2015-11-23 Thread Jonas Gorski
On Mon, Nov 23, 2015 at 8:43 AM, Shonn Lu  wrote:
>Subject: oxnas: set irq of usb to cpu1

Why? Please explain why this is needed/wanted.


Jonas
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel


Re: [OpenWrt-Devel] [PATCH] axs10x: initilaze network for wireless access-point

2015-11-23 Thread Alexey Brodkin
Hi Jonas,

On Mon, 2015-11-23 at 16:54 +0100, Jonas Gorski wrote:
> On Mon, Nov 23, 2015 at 9:28 AM, Alexey Brodkin
>  wrote:
> > ARC SDP board sports only 1 network interface - eth0,
> > so to operate as an access point it requires at least
> > another interface (preferably wireless),
> > so USB Wi-Fi dongle is what we want.
> > 
> > And with USB Wi-Fi dongle attached ARC SDP board could be
> > used as a "dumb" wireless access point.
> > 
> > Now with modified network setup script it is only required
> > to enable wireless radio on the first boot with
> > -->8
> > uci set wireless.radio0.disabled=0
> > uci commit wireless
> > wifi
> > -->8
> > 
> > Note if by the time initscripts are executed USB Wi-Fi
> > dongle not yet recognized and set up by Linux kernel
> > its autodetection by "wifi" tool may not happen
> > automatically. In that case before issuing command above
> > one needs to populate /etc/config/wireless config:
> > -->8
> > wifi detect > /etc/config/wireless
> > -->8
> > 
> > Signed-off-by: Alexey Brodkin 
> > Cc: Felix Fietkau 
> > Cc: Jo-Philipp Wich 
> > Cc: Jonas Gorski 
> > ---
> >  target/linux/arc770/base-files/etc/uci-defaults/02_network | 12 
> > +++-
> >  1 file changed, 11 insertions(+), 1 deletion(-)
> > 
> > diff --git a/target/linux/arc770/base-files/etc/uci-defaults/02_network 
> > b/target/linux/arc770/base-files/etc/uci
> > -defaults/02_network
> > index 87cfe81..7503f85 100644
> > --- a/target/linux/arc770/base-files/etc/uci-defaults/02_network
> > +++ b/target/linux/arc770/base-files/etc/uci-defaults/02_network
> > @@ -14,7 +14,17 @@ ucidef_set_interface_loopback
> > 
> >  case "$( arc_board_name )" in
> >  "arc-sdp"*)
> > -   ucidef_set_interface_raw "lan" "eth0" "dhcp"
> 
> Keep this line instead
> 
> > +   uci set network.lan.type='bridge'
> 
> And only add this line.
> 
> > +   uci set network.lan.ifname='eth0 wlan0'
> 
> This is unneeded, as netifd will automatically join the wifi interface
> to the bridge in the default config (with the option network 'lan'
> line in /etc/config/wireless).

Yep, I did figure that out just now.
So will re-spin it.

> 
> > +   # With multicast-to-unicast enabled kernel crashes
> > +   # on the first wireless client connection in
> > +   # br_multicast_add_group() -> br_port_group_equal() ->
> > +   # ether_addr_equal() due to misaligned read.
> > +   # For some reason "src" being "eth_hdr(skb)->h_source"
> > +   # is not 16-bit aligned as it is supposed to be.
> > +   uci set network.lan.multicast_to_unicast='0'
> 
> And this doesn't belong here at all, this is a complete separate issue
> and should be fixed where it occurs, not worked around (sounds like an
> issue in the ath9k-htc driver). Does ARC not provide emulation of
> unaligned accesses like mips does?

Well in ARCv1 we can only handle unaligned access in software.
Here I mean handle unaligned exception in Linux kernel and copying
data back to caller. But this essentially comes with performance penalty.

On ARCv2 we may have that feature right in hardware though still not
necessary - remember ARC is highly configurable architecture and real
users (I mean vendors of ASICs) may use or not use each particular feature.

But I'd say unaligned access highlights a problem here (and I'm not yet
to blame yet anybody for now). Because what happens compiler attempts
to use half-word (two-bytes) read () on a byte-aligned address
(something like 0x4000_0001). And that happens in ether_addr_equal()
comment for which clearly states:
https://github.com/torvalds/linux/blob/master/include/linux/etherdevice.h#L308
>8-
Please note: addr1 & addr2 must both be aligned to u16.
>8-

So what we seeing here "src = eth_hdr(skb)->h_source" is not 2-bytes
aligned (=0x9e3c766b) which I believe should not be the case , right?

I mean even if unaligned accesses could be supported something doesn't
match expectations of ether_addr_equal().

Any thoughts?

-Alexey
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel


Re: [OpenWrt-Devel] [PATCH] axs10x: initilaze network for wireless access-point

2015-11-23 Thread Jonas Gorski
On Mon, Nov 23, 2015 at 9:28 AM, Alexey Brodkin
 wrote:
> ARC SDP board sports only 1 network interface - eth0,
> so to operate as an access point it requires at least
> another interface (preferably wireless),
> so USB Wi-Fi dongle is what we want.
>
> And with USB Wi-Fi dongle attached ARC SDP board could be
> used as a "dumb" wireless access point.
>
> Now with modified network setup script it is only required
> to enable wireless radio on the first boot with
> -->8
> uci set wireless.radio0.disabled=0
> uci commit wireless
> wifi
> -->8
>
> Note if by the time initscripts are executed USB Wi-Fi
> dongle not yet recognized and set up by Linux kernel
> its autodetection by "wifi" tool may not happen
> automatically. In that case before issuing command above
> one needs to populate /etc/config/wireless config:
> -->8
> wifi detect > /etc/config/wireless
> -->8
>
> Signed-off-by: Alexey Brodkin 
> Cc: Felix Fietkau 
> Cc: Jo-Philipp Wich 
> Cc: Jonas Gorski 
> ---
>  target/linux/arc770/base-files/etc/uci-defaults/02_network | 12 +++-
>  1 file changed, 11 insertions(+), 1 deletion(-)
>
> diff --git a/target/linux/arc770/base-files/etc/uci-defaults/02_network 
> b/target/linux/arc770/base-files/etc/uci-defaults/02_network
> index 87cfe81..7503f85 100644
> --- a/target/linux/arc770/base-files/etc/uci-defaults/02_network
> +++ b/target/linux/arc770/base-files/etc/uci-defaults/02_network
> @@ -14,7 +14,17 @@ ucidef_set_interface_loopback
>
>  case "$( arc_board_name )" in
>  "arc-sdp"*)
> -   ucidef_set_interface_raw "lan" "eth0" "dhcp"

Keep this line instead

> +   uci set network.lan.type='bridge'

And only add this line.

> +   uci set network.lan.ifname='eth0 wlan0'

This is unneeded, as netifd will automatically join the wifi interface
to the bridge in the default config (with the option network 'lan'
line in /etc/config/wireless).

> +   # With multicast-to-unicast enabled kernel crashes
> +   # on the first wireless client connection in
> +   # br_multicast_add_group() -> br_port_group_equal() ->
> +   # ether_addr_equal() due to misaligned read.
> +   # For some reason "src" being "eth_hdr(skb)->h_source"
> +   # is not 16-bit aligned as it is supposed to be.
> +   uci set network.lan.multicast_to_unicast='0'

And this doesn't belong here at all, this is a complete separate issue
and should be fixed where it occurs, not worked around (sounds like an
issue in the ath9k-htc driver). Does ARC not provide emulation of
unaligned accesses like mips does?


Jonas
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel


Re: [OpenWrt-Devel] [PATCH v2 1/5] kernel: other: add PWM controller support

2015-11-23 Thread Tim Harvey
On Sun, Nov 22, 2015 at 12:55 AM, John Crispin  wrote:
> Hi Tim,
>
>
>
> On 19/11/2015 18:53, Tim Harvey wrote:
>> This adds basic PWM controller support and support for i.MX
>>
>> Signed-off-by: Tim Harvey 
>> ---
>> v2:
>> - add TARGET_imx6 dep for pwm-imx
>>
>>  package/kernel/linux/modules/other.mk | 36 
>> +++
>>  1 file changed, 36 insertions(+)
>>
>> diff --git a/package/kernel/linux/modules/other.mk 
>> b/package/kernel/linux/modules/other.mk
>> index 55fb6f1..6493b91 100644
>> --- a/package/kernel/linux/modules/other.mk
>> +++ b/package/kernel/linux/modules/other.mk
>
> is there a specific reason not to create a new file for PWM ?

John,

No reason - I wasn't sure what was expected. I did create a new file
for backlight but also noticed other things in other.mk that could be
split out in a cleanup.

Tim
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel


Re: [OpenWrt-Devel] [PATCH] axs10x: initilaze network for wireless access-point

2015-11-23 Thread Felix Fietkau
On 2015-11-23 17:20, Alexey Brodkin wrote:
> Well in ARCv1 we can only handle unaligned access in software.
> Here I mean handle unaligned exception in Linux kernel and copying
> data back to caller. But this essentially comes with performance penalty.
> 
> On ARCv2 we may have that feature right in hardware though still not
> necessary - remember ARC is highly configurable architecture and real
> users (I mean vendors of ASICs) may use or not use each particular feature.
> 
> But I'd say unaligned access highlights a problem here (and I'm not yet
> to blame yet anybody for now). Because what happens compiler attempts
> to use half-word (two-bytes) read () on a byte-aligned address
> (something like 0x4000_0001). And that happens in ether_addr_equal()
> comment for which clearly states:
> https://github.com/torvalds/linux/blob/master/include/linux/etherdevice.h#L308
> >8-
> Please note: addr1 & addr2 must both be aligned to u16.
> >8-
> 
> So what we seeing here "src = eth_hdr(skb)->h_source" is not 2-bytes
> aligned (=0x9e3c766b) which I believe should not be the case , right?
> 
> I mean even if unaligned accesses could be supported something doesn't
> match expectations of ether_addr_equal().
An unaligned access in that place usually indicates a driver bug.
Where is that packet coming from, ethernet or wireless? Maybe you can
see that in the stack trace - if not, you can probably add a selective
dump_stack() call in the right place.

- Felix
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel


Re: [OpenWrt-Devel] ath9k-htc init

2015-11-23 Thread Jonas Gorski
On Mon, Nov 23, 2015 at 9:21 AM, Alexey Brodkin
 wrote:
> Hi Felix, Jonas,
>
> While playing with my AXS101 board and USB WI-Fi dongles I bumped in
> a couple of issues. Fortunately I found at least one dongle that
> works quite nice. That's TP-Link TL-WN721N (or its WN722N sibling)
> which is based on Atheros AR9271 chip even though it did require
> one unexpected tweak.
>
> For starters I just selected "kmod-ath9k-htc" in menuconfig and
> on boot saw USB device recognized, its firmware was loaded,
> "wifi detect" recognized it as well, see log below.
>
> But then "wlan0" interface was not created on "wifi" command.
>
> After some googling I somehow came to resolution that "hostapd"
> package installation fixes this problem. And indeed once I got
> image rebuilt with "CONFIG_PACKAGE_hostapd=y" all worked as expected
> and I was able to use my board as a Wi-Fi access point.
>
> So the question is if this is expected (requirement for "hostapd")
> [for "ath9k_htc"]?

Yes, hostapd[-mini] (or wpad[-mini]) is required for AP mode, and
wpasupplicant or wpad for encrypted STA mode.


> Another minor issue is that USB dongle gets recognized a bit late
> so that automatic "wifi detect" gets already executed and
> "/etc/config/wireless" isn't created. That requires manual execution of
> "wifi detect > /etc/config/wireless". Essentially extending delay in
> "package/base-files/files/etc/init.d/boot" makes a difference:
> -->8---
> # allow wifi modules time to settle
> sleep 15 # instead of 1
> -->8---
> but I'm not sure if we want to do that change for all devices.
> Then if there's a better way to make auto population of
> "/etc/config/wireless"?

Likely the firmware is loaded asynchronously, so the _probe function
returns quickly. Our workaround in OpenWrt  for other drivers is to
make the _probe function wait for the firmware to have loaded. and
thus the wifi device registered in the linux kernel. This will ensure
the wifi subsystem knows about it when wifi detect is called. This
seems to be missing for ath9k-htc.


Jonas
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel


Re: [OpenWrt-Devel] [PATCH] arc770/axs101: accomodate DW GMAC long reset sequence

2015-11-23 Thread Alexey Brodkin
Hi Felix,

On Mon, 2015-11-23 at 11:45 +0300, Alexey Brodkin wrote:
> On ARC SDP board DMA block of DW GMAC gets out of reset much
> longer than expected by default driver.
> 
> For now to accomodate this issue we're extending timeout value.
> 
> Signed-off-by: Alexey Brodkin 

Please disregard that patch.
This problem as it turned out was already fixed in hardware,
so the patch is no longer required.

-Alexey
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel