Date   

Re: _Swap crash in attempt to add support for STM32F3 board

Benjamin Walsh <benjamin.walsh@...>
 

On Thu, Aug 18, 2016 at 11:07:32PM +0200, Mirza Krak wrote:
2016-08-18 22:55 GMT+02:00 Benjamin Walsh <benjamin.walsh(a)windriver.com>:
On Thu, Aug 18, 2016 at 10:02:07PM +0200, Mirza Krak wrote:
2016-08-18 21:50 GMT+02:00 Benjamin Walsh <benjamin.walsh(a)windriver.com>:
On Thu, Aug 18, 2016 at 09:43:49PM +0200, Mirza Krak wrote:
Do you guys have any tips on why it crashes here?
sp 0x20009e90 0x20009e90
lr 0x8000837 134219831
^^^^^^^^^

Contents of lr looks corrupted: it should be something like 0xfffffffd.
Is it OK when entering __svc() ?
It seems to be corrupted when entering __svc, but once inside the
__svc it seems to have a value of what you where expecting.
Ah, no, this might be OK then. 0xfffffffd gets put by the CPU when
taking the SVC exception and entering __svc().

If this is the very first call to _Swap() when the kernel boots, that
call will never return.


(gdb) s
249 svc #0
(gdb) info registers
r0 0x20 32
r1 0x20000138 536871224
r2 0x20009e98 536911512
r3 0x20000060 536871008
r4 0x0 0
r5 0x0 0
r6 0x0 0
r7 0x20009e90 536911504
r8 0x0 0
r9 0x0 0
r10 0x0 0
r11 0x0 0
r12 0x0 0
sp 0x20009e90 0x20009e90
lr 0x8000a6f 134220399
pc 0x8001256 0x8001256 <_Swap+6>
^^^^^^^^^
Although, these addresses look weird: normally the .text section is at 0
on these targets, but the PC shows an address in the 0x8001256 range as
well, and it is resolved as being _Swap+6. I suppose the link address is
different on that board.

cpsr 0x21000000 553648128
(gdb) s
__svc () at /home/mirzak/git/zephyr-project/arch/arm/core/swap.S:197
197 eors.n r0, r0
(gdb) info registers
r0 0x20 32
r1 0x20000138 536871224
r2 0x20009e98 536911512
r3 0x20000060 536871008
r4 0x0 0
r5 0x0 0
r6 0x0 0
r7 0x20009e90 536911504
r8 0x0 0
r9 0x0 0
r10 0x0 0
r11 0x0 0
r12 0x0 0
sp 0x20000d60 0x20000d60
lr 0xfffffffd 4294967293
pc 0x8001238 0x8001238 <__svc>
cpsr 0x2100000b 553648139>

Are you trying to run a stock project or is it your own application ?
I am attempting to run the samples/drivers/gpio application.
The comments in main.c list a bunch of boards, but not the STM ones.

I guess you adapted it to run on your board ?

Cheers,
Ben


Re: _Swap crash in attempt to add support for STM32F3 board

Mirza Krak
 

2016-08-18 22:55 GMT+02:00 Benjamin Walsh <benjamin.walsh(a)windriver.com>:
On Thu, Aug 18, 2016 at 10:02:07PM +0200, Mirza Krak wrote:
2016-08-18 21:50 GMT+02:00 Benjamin Walsh <benjamin.walsh(a)windriver.com>:
On Thu, Aug 18, 2016 at 09:43:49PM +0200, Mirza Krak wrote:
Do you guys have any tips on why it crashes here?
sp 0x20009e90 0x20009e90
lr 0x8000837 134219831
^^^^^^^^^

Contents of lr looks corrupted: it should be something like 0xfffffffd.
Is it OK when entering __svc() ?
But if I understand this correctly, shouldn't LR contain the address
of main at this stage.

The code says:
/* context switch to main task (entry function is _main()) */
_nano_fiber_swap();

I am not sure where it does get the address of main though. Because I
cant find the address that LR has when entering __Swap in any of of
the files (.map .lst), and maybe that is the root of it.

Best Regards
Mirza


Re: _Swap crash in attempt to add support for STM32F3 board

Mirza Krak
 

2016-08-18 22:55 GMT+02:00 Benjamin Walsh <benjamin.walsh(a)windriver.com>:
On Thu, Aug 18, 2016 at 10:02:07PM +0200, Mirza Krak wrote:
2016-08-18 21:50 GMT+02:00 Benjamin Walsh <benjamin.walsh(a)windriver.com>:
On Thu, Aug 18, 2016 at 09:43:49PM +0200, Mirza Krak wrote:
Do you guys have any tips on why it crashes here?
sp 0x20009e90 0x20009e90
lr 0x8000837 134219831
^^^^^^^^^

Contents of lr looks corrupted: it should be something like 0xfffffffd.
Is it OK when entering __svc() ?
It seems to be corrupted when entering __svc, but once inside the
__svc it seems to have a value of what you where expecting.

(gdb) s
249 svc #0
(gdb) info registers
r0 0x20 32
r1 0x20000138 536871224
r2 0x20009e98 536911512
r3 0x20000060 536871008
r4 0x0 0
r5 0x0 0
r6 0x0 0
r7 0x20009e90 536911504
r8 0x0 0
r9 0x0 0
r10 0x0 0
r11 0x0 0
r12 0x0 0
sp 0x20009e90 0x20009e90
lr 0x8000a6f 134220399
pc 0x8001256 0x8001256 <_Swap+6>
cpsr 0x21000000 553648128
(gdb) s
__svc () at /home/mirzak/git/zephyr-project/arch/arm/core/swap.S:197
197 eors.n r0, r0
(gdb) info registers
r0 0x20 32
r1 0x20000138 536871224
r2 0x20009e98 536911512
r3 0x20000060 536871008
r4 0x0 0
r5 0x0 0
r6 0x0 0
r7 0x20009e90 536911504
r8 0x0 0
r9 0x0 0
r10 0x0 0
r11 0x0 0
r12 0x0 0
sp 0x20000d60 0x20000d60
lr 0xfffffffd 4294967293
pc 0x8001238 0x8001238 <__svc>
cpsr 0x2100000b 553648139>

Are you trying to run a stock project or is it your own application ?
I am attempting to run the samples/drivers/gpio application.

Best Regards
Mirza


Re: _Swap crash in attempt to add support for STM32F3 board

Benjamin Walsh <benjamin.walsh@...>
 

On Thu, Aug 18, 2016 at 10:02:07PM +0200, Mirza Krak wrote:
2016-08-18 21:50 GMT+02:00 Benjamin Walsh <benjamin.walsh(a)windriver.com>:
On Thu, Aug 18, 2016 at 09:43:49PM +0200, Mirza Krak wrote:
Do you guys have any tips on why it crashes here?

Posting a gdb trace below:

_nano_fiber_swap () at
/home/mirzak/git/zephyr-project/kernel/nanokernel/nano_fiber.c:159
159 _Swap(imask);
(gdb) s
_Swap () at /home/mirzak/git/zephyr-project/arch/arm/core/swap.S:245
245 ldr r1, =_nanokernel
(gdb) s
246 ldr r2, [r1, #__tNANO_current_OFFSET]
(gdb) s
247 str r0, [r2, #__tTCS_basepri_OFFSET]
(gdb) s
249 svc #0
(gdb) s
__svc () at /home/mirzak/git/zephyr-project/arch/arm/core/swap.S:197
197 eors.n r0, r0
(gdb) s
198 msr BASEPRI, r0
(gdb) s
201 ldr r1, =_SCS_ICSR
(gdb) s
202 ldr r2, =_SCS_ICSR_PENDSV
(gdb) s
203 str r2, [r1, #0]
(gdb) s
208 bx lr
(gdb) s
_Swap () at /home/mirzak/git/zephyr-project/arch/arm/core/swap.S:252
252 bx lr
(gdb) s
Looks like it's going in the weeds when trying to return from the svc
handler. What's the value of the LR register at that time ?
I get the following just before it tries to exit.

252 bx lr
(gdb) info registers
r0 0x20 32
r1 0x20000120 536871200
r2 0x20009e98 536911512
r3 0x20000044 536870980
r4 0x0 0
r5 0x0 0
r6 0x0 0
r7 0x20009e90 536911504
r8 0x0 0
r9 0x0 0
r10 0x0 0
r11 0x0 0
r12 0x0 0
sp 0x20009e90 0x20009e90
lr 0x8000837 134219831
^^^^^^^^^

Contents of lr looks corrupted: it should be something like 0xfffffffd.
Is it OK when entering __svc() ?

Are you trying to run a stock project or is it your own application ?

pc 0x8001020 0x8001020 <_Swap+8>
cpsr 0x21000000 553648128
(gdb) s
^C
Program received signal SIGTRAP, Trace/breakpoint trap.
0x0800130a in _SysFatalErrorHandler (reason=reason(a)entry=0,
pEsf=pEsf(a)entry=0x200004f8 <main_task_stack+944>) at
/home/mirzak/git/zephyr-project/arch/arm/core/sys_fatal_error_handler.c:77
77 if ((curCtx == NANO_CTX_ISR) || _is_thread_essential()) {

Best Regards,
Mirza


Re: _Swap crash in attempt to add support for STM32F3 board

Mirza Krak
 

2016-08-18 21:50 GMT+02:00 Benjamin Walsh <benjamin.walsh(a)windriver.com>:
On Thu, Aug 18, 2016 at 09:43:49PM +0200, Mirza Krak wrote:
Do you guys have any tips on why it crashes here?

Posting a gdb trace below:

_nano_fiber_swap () at
/home/mirzak/git/zephyr-project/kernel/nanokernel/nano_fiber.c:159
159 _Swap(imask);
(gdb) s
_Swap () at /home/mirzak/git/zephyr-project/arch/arm/core/swap.S:245
245 ldr r1, =_nanokernel
(gdb) s
246 ldr r2, [r1, #__tNANO_current_OFFSET]
(gdb) s
247 str r0, [r2, #__tTCS_basepri_OFFSET]
(gdb) s
249 svc #0
(gdb) s
__svc () at /home/mirzak/git/zephyr-project/arch/arm/core/swap.S:197
197 eors.n r0, r0
(gdb) s
198 msr BASEPRI, r0
(gdb) s
201 ldr r1, =_SCS_ICSR
(gdb) s
202 ldr r2, =_SCS_ICSR_PENDSV
(gdb) s
203 str r2, [r1, #0]
(gdb) s
208 bx lr
(gdb) s
_Swap () at /home/mirzak/git/zephyr-project/arch/arm/core/swap.S:252
252 bx lr
(gdb) s
Looks like it's going in the weeds when trying to return from the svc
handler. What's the value of the LR register at that time ?
I get the following just before it tries to exit.

252 bx lr
(gdb) info registers
r0 0x20 32
r1 0x20000120 536871200
r2 0x20009e98 536911512
r3 0x20000044 536870980
r4 0x0 0
r5 0x0 0
r6 0x0 0
r7 0x20009e90 536911504
r8 0x0 0
r9 0x0 0
r10 0x0 0
r11 0x0 0
r12 0x0 0
sp 0x20009e90 0x20009e90
lr 0x8000837 134219831
pc 0x8001020 0x8001020 <_Swap+8>
cpsr 0x21000000 553648128
(gdb) s
^C
Program received signal SIGTRAP, Trace/breakpoint trap.
0x0800130a in _SysFatalErrorHandler (reason=reason(a)entry=0,
pEsf=pEsf(a)entry=0x200004f8 <main_task_stack+944>) at
/home/mirzak/git/zephyr-project/arch/arm/core/sys_fatal_error_handler.c:77
77 if ((curCtx == NANO_CTX_ISR) || _is_thread_essential()) {

Best Regards,
Mirza


Re: _Swap crash in attempt to add support for STM32F3 board

Benjamin Walsh <benjamin.walsh@...>
 

On Thu, Aug 18, 2016 at 09:43:49PM +0200, Mirza Krak wrote:
Hi.

My first post on this list so would like to say that this project
seems very promising and is something that I have been waiting for.

I wanted to get involved so I dusted of a STM32F3 discovery board and
started coding. It helped a lot that there was STM32F1 support all
ready.

I have gotten it to compile and also have flash and debug support for
the board which has a STlink v2 interface.

But I am having some problems booting the system. As my topic says the
code gets to the _Swap call and then triggers a hard fault.

Do you guys have any tips on why it crashes here?

Posting a gdb trace below:

_nano_fiber_swap () at
/home/mirzak/git/zephyr-project/kernel/nanokernel/nano_fiber.c:159
159 _Swap(imask);
(gdb) s
_Swap () at /home/mirzak/git/zephyr-project/arch/arm/core/swap.S:245
245 ldr r1, =_nanokernel
(gdb) s
246 ldr r2, [r1, #__tNANO_current_OFFSET]
(gdb) s
247 str r0, [r2, #__tTCS_basepri_OFFSET]
(gdb) s
249 svc #0
(gdb) s
__svc () at /home/mirzak/git/zephyr-project/arch/arm/core/swap.S:197
197 eors.n r0, r0
(gdb) s
198 msr BASEPRI, r0
(gdb) s
201 ldr r1, =_SCS_ICSR
(gdb) s
202 ldr r2, =_SCS_ICSR_PENDSV
(gdb) s
203 str r2, [r1, #0]
(gdb) s
208 bx lr
(gdb) s
_Swap () at /home/mirzak/git/zephyr-project/arch/arm/core/swap.S:252
252 bx lr
(gdb) s
Looks like it's going in the weeds when trying to return from the svc
handler. What's the value of the LR register at that time ?


^C
Program received signal SIGTRAP, Trace/breakpoint trap.
0x0800130a in _SysFatalErrorHandler (reason=reason(a)entry=0,
pEsf=pEsf(a)entry=0x200004f8 <main_task_stack+944>) at
/home/mirzak/git/zephyr-project/arch/arm/core/sys_fatal_error_handler.c:77
77 if ((curCtx == NANO_CTX_ISR) || _is_thread_essential()) {
(gdb) backtrace
Python Exception <type 'exceptions.ImportError'> No module named gdb.frames:
#0 0x0800130a in _SysFatalErrorHandler (reason=reason(a)entry=0,
pEsf=pEsf(a)entry=0x200004f8 <main_task_stack+944>)
at /home/mirzak/git/zephyr-project/arch/arm/core/sys_fatal_error_handler.c:77
#1 0x080011b8 in _Fault (esf=0x200004f8 <main_task_stack+944>) at
/home/mirzak/git/zephyr-project/arch/arm/core/fault.c:346
#2 0x080012c2 in __usage_fault () at
/home/mirzak/git/zephyr-project/arch/arm/core/fault_s.S:89
#3 <signal handler called>
#4 0x3d45e07c in ?? ()
#5 0xdba824f0 in ?? ()
Backtrace stopped: previous frame identical to this frame (corrupt stack?)

Best Regards,
Mirza
--
Benjamin Walsh, SMTS
Wind River Rocket
www.windriver.com
Zephyr kernel maintainer
www.zephyrproject.org


Re: QEMU networking: CONFIG_NET_TESTING breaks things, echo_server IPv6 address is "wrong"

Paul Sokolovsky
 

On Wed, 17 Aug 2016 17:26:39 +0300
Paul Sokolovsky <Paul.Sokolovsky(a)linaro.org> wrote:

[]

So, I'm not sure what the exact issue is. I may imagine following
might happen:

1. There was a simple CONFIG_NET_TESTING, for things like echo_server.
2. Later, it was made into a separate module, but echo_server possibly
wasn't updated to play with the new module well.
3. net-tools and wiki page predate CONFIG_NET_TESTING altogether.

The obvious question is what to do in this situation. I'm personally
keen to update
https://wiki.zephyrproject.org/view/Networking-with-Qemu to describe
a setup which actually works now (this is mostly doing steps in the
right order, but also building with CONFIG_NET_TESTING=n).
Ok, mystery [seems to be] solved. The default setup of
echo_server/echo_client is tailored towards running QEMU-QEMU
communication, as described in samples/net/README. However, QEMU-Host
setup is definitely regressed. Moreover, CONFIG_NET_TESTING, with all
its addresses flip-floppig, appears to be needed exactly for QEMU-QEMU
case, and only complicates matters for QEMU-Host case.

Proposed/done items:

1. Done: https://wiki.zephyrproject.org/view/Networking-with-Qemu now
describes both QEMU-Host and QEMU-QEMU cases.
2. Done: QEMU-Host includes instructions on patching echo_server to make
net-tools to work as is.
3. Suggestion: Update CONFIG_NET_TESTING's description in Kconfig to
clearly state that it's pertinent to (only) QEMU-QEMU setup.
4. Suggestion: For all test apps not running in QEMU-QEMU mode,
standardize of 2001:db8::1 to be host side, and 2001:db8::2 to be
device side (eb it QEMU or physical device).
5. Suggestion: Apparently, add separate prj_*.conf's to run samples in
QEMU-QEMU vs QEMU-Host mode.

Jukka, your comments would be appreciated.


--
Best Regards,
Paul

Linaro.org | Open source software for ARM SoCs
Follow Linaro: http://www.facebook.com/pages/Linaro
http://twitter.com/#!/linaroorg - http://www.linaro.org/linaro-blog


_Swap crash in attempt to add support for STM32F3 board

Mirza Krak
 

Hi.

My first post on this list so would like to say that this project
seems very promising and is something that I have been waiting for.

I wanted to get involved so I dusted of a STM32F3 discovery board and
started coding. It helped a lot that there was STM32F1 support all
ready.

I have gotten it to compile and also have flash and debug support for
the board which has a STlink v2 interface.

But I am having some problems booting the system. As my topic says the
code gets to the _Swap call and then triggers a hard fault.

Do you guys have any tips on why it crashes here?

Posting a gdb trace below:

_nano_fiber_swap () at
/home/mirzak/git/zephyr-project/kernel/nanokernel/nano_fiber.c:159
159 _Swap(imask);
(gdb) s
_Swap () at /home/mirzak/git/zephyr-project/arch/arm/core/swap.S:245
245 ldr r1, =_nanokernel
(gdb) s
246 ldr r2, [r1, #__tNANO_current_OFFSET]
(gdb) s
247 str r0, [r2, #__tTCS_basepri_OFFSET]
(gdb) s
249 svc #0
(gdb) s
__svc () at /home/mirzak/git/zephyr-project/arch/arm/core/swap.S:197
197 eors.n r0, r0
(gdb) s
198 msr BASEPRI, r0
(gdb) s
201 ldr r1, =_SCS_ICSR
(gdb) s
202 ldr r2, =_SCS_ICSR_PENDSV
(gdb) s
203 str r2, [r1, #0]
(gdb) s
208 bx lr
(gdb) s
_Swap () at /home/mirzak/git/zephyr-project/arch/arm/core/swap.S:252
252 bx lr
(gdb) s

^C
Program received signal SIGTRAP, Trace/breakpoint trap.
0x0800130a in _SysFatalErrorHandler (reason=reason(a)entry=0,
pEsf=pEsf(a)entry=0x200004f8 <main_task_stack+944>) at
/home/mirzak/git/zephyr-project/arch/arm/core/sys_fatal_error_handler.c:77
77 if ((curCtx == NANO_CTX_ISR) || _is_thread_essential()) {
(gdb) backtrace
Python Exception <type 'exceptions.ImportError'> No module named gdb.frames:
#0 0x0800130a in _SysFatalErrorHandler (reason=reason(a)entry=0,
pEsf=pEsf(a)entry=0x200004f8 <main_task_stack+944>)
at /home/mirzak/git/zephyr-project/arch/arm/core/sys_fatal_error_handler.c:77
#1 0x080011b8 in _Fault (esf=0x200004f8 <main_task_stack+944>) at
/home/mirzak/git/zephyr-project/arch/arm/core/fault.c:346
#2 0x080012c2 in __usage_fault () at
/home/mirzak/git/zephyr-project/arch/arm/core/fault_s.S:89
#3 <signal handler called>
#4 0x3d45e07c in ?? ()
#5 0xdba824f0 in ?? ()
Backtrace stopped: previous frame identical to this frame (corrupt stack?)

Best Regards,
Mirza


Re: QEMU networking: CONFIG_NET_TESTING breaks things, echo_server IPv6 address is "wrong"

Maureen Helm
 

-----Original Message-----
From: Paul Sokolovsky [mailto:paul.sokolovsky(a)linaro.org]
Sent: Thursday, August 18, 2016 10:43 AM
To: Flavio Santes <flavio.santes(a)intel.com>
Cc: devel(a)lists.zephyrproject.org
Subject: [devel] Re: Re: QEMU networking: CONFIG_NET_TESTING breaks
things, echo_server IPv6 address is "wrong"

On Wed, 17 Aug 2016 20:19:06 -0000
"Flavio Santes" <flavio.santes(a)intel.com> wrote:

Hello

Hello,

Taking a chance, I'd like to start with drawing attention to
https://jira.zephyrproject.org/browse/ZEP-687 "docs:
Subsystems/Networking section is almost empty". Zephyr networking
See also https://jira.zephyrproject.org/browse/ZEP-188

information currently is sparse, disperse, bits are out of date, and
there're omissions/inconsistencies. Just linking a wiki landing page
from the official docs and letting community fill in that wiki would
be a good first step.
Agree

Anyway, waiting for real hardware support, I decided to give QEMU
networking a try. After some moderate googling, I arrived at
https://gerrit.zephyrproject.org/r/gitweb?p=net-tools.git;a=summary
and https://wiki.zephyrproject.org/view/Networking-with-Qemu . The
initial outcome: nothing works.
There is support for real hardware, see:
https://gerrit.zephyrproject.org/r/gitweb?p=zephyr.git;a=blob;f=sample
s/net/dns_client/prj_galileo.conf

There is also a driver for enc28j60, see:
https://jira.zephyrproject.org/browse/ZEP-291
https://www.olimex.com/Products/Modules/Ethernet/ENC28J60-
H/resources/
ENC28J60-H.pdf
Yes, thanks, I meant for Ethernet support in FRDM-K64F which I have on my
hands now.
Can you share?

[]

The obvious question is what to do in this situation. I'm personally
keen to update
https://wiki.zephyrproject.org/view/Networking-with-Qemu to describe
a setup which actually works now (this is mostly doing steps in the
right order, but also building with CONFIG_NET_TESTING=n).
I've made first pass of changes to
https://wiki.zephyrproject.org/view/Networking-with-Qemu , ordering
connection bring up steps properly and adding a bit more info here and there.
Going to look into CONFIG_NET_TESTING in more detail before adding
suggestion to disable it in the wiki.


--
Best Regards,
Paul

Linaro.org | Open source software for ARM SoCs Follow Linaro:
http://www.facebook.com/pages/Linaro
http://twitter.com/#!/linaroorg - http://www.linaro.org/linaro-blog


Daily JIRA Digest

donotreply@...
 

NEW JIRA items within last 24 hours: 1
[ZEP-714] I2C fails to write/read the fourth slave among operation of multi-slaves
https://jira.zephyrproject.org/browse/ZEP-714


UPDATED JIRA items within last 24 hours: 5
[ZEP-328] HW Encryption Abstraction
https://jira.zephyrproject.org/browse/ZEP-328

[ZEP-454] Add driver API reentrancy support to UART shim drivers
https://jira.zephyrproject.org/browse/ZEP-454

[ZEP-365] Zephyr's MQTT library
https://jira.zephyrproject.org/browse/ZEP-365

[ZEP-428] Ethernet/IPv4/TCP net_send error
https://jira.zephyrproject.org/browse/ZEP-428

[ZEP-690] TCF isn't setting ARCH when running testcases
https://jira.zephyrproject.org/browse/ZEP-690


CLOSED JIRA items within last 24 hours: 16
[ZEP-228] (Fixed) File system interface designed after POSIX
https://jira.zephyrproject.org/browse/ZEP-228

[ZEP-285] (Fixed) FAT filesystem support on top of SPI Flash
https://jira.zephyrproject.org/browse/ZEP-285

[ZEP-60] (Fixed) irq priorities should be rebased to safe values
https://jira.zephyrproject.org/browse/ZEP-60

[ZEP-357] (Fixed) Support for the MAX44009 sensor
https://jira.zephyrproject.org/browse/ZEP-357

[ZEP-358] (Fixed) Add support for TMP112 sensor
https://jira.zephyrproject.org/browse/ZEP-358

[ZEP-469] (Fixed) Ethernet/IPv4/TCP: net_receive & net_reply in server mode
https://jira.zephyrproject.org/browse/ZEP-469

[ZEP-595] (Fixed) UART: usb simulated uart doesn't work in poll mode
https://jira.zephyrproject.org/browse/ZEP-595

[ZEP-633] (Fixed) samples/usb/cdc_acm: undefined reference to `uart_qmsi_pm_save_config'
https://jira.zephyrproject.org/browse/ZEP-633

[ZEP-646] (Fixed) I2C fail to read GY2561 sensor when GY2561 & GY271 sensor are attached to I2C bus.
https://jira.zephyrproject.org/browse/ZEP-646

[ZEP-523] (Fixed) FIFOs defined by DEFINE_FIFO macro use the same memory buffer
https://jira.zephyrproject.org/browse/ZEP-523

[ZEP-545] (Fixed) Wrong default value of CONFIG_ADC_QMSI_SAMPLE_WIDTH for x86 QMSI ADC
https://jira.zephyrproject.org/browse/ZEP-545

[ZEP-681] (Fixed) MQTT client sample throws too many warnings when build.
https://jira.zephyrproject.org/browse/ZEP-681

[ZEP-166] (Fixed) Dynamic IRQ Routing on x86 Fails for IRQs with Index Great than 7
https://jira.zephyrproject.org/browse/ZEP-166

[ZEP-679] (Fixed) HMC5883L I2C Register Read Order
https://jira.zephyrproject.org/browse/ZEP-679

[ZEP-696] (Won't Do) bad hyperlink on Zephyr docs page
https://jira.zephyrproject.org/browse/ZEP-696

[ZEP-180] (Fixed) make menuconfig user provided options are ignored at building time
https://jira.zephyrproject.org/browse/ZEP-180


RESOLVED JIRA items within last 24 hours: 8
[ZEP-522] (Fixed) TCP/client-mode: disconnect
https://jira.zephyrproject.org/browse/ZEP-522

[ZEP-461] (Fixed) Release 1.4.0 has broken the BMI160 sample as well as an application based on it
https://jira.zephyrproject.org/browse/ZEP-461

[ZEP-704] (Fixed) test_atomic does not complete on ARC
https://jira.zephyrproject.org/browse/ZEP-704

[ZEP-693] (Fixed) tests/kernel/test_lifo: execution fails on ARC
https://jira.zephyrproject.org/browse/ZEP-693

[ZEP-695] (Fixed) FatFs doesn't compile using Newlib
https://jira.zephyrproject.org/browse/ZEP-695

[ZEP-689] (Fixed) Builds on em_starterkit fail
https://jira.zephyrproject.org/browse/ZEP-689

[ZEP-708] (Fixed) tests/kernel/test_ipm fails on Arduino 101
https://jira.zephyrproject.org/browse/ZEP-708

[ZEP-534] (Fixed) Scan for consistent use of "platform/board/SoC" in documentation
https://jira.zephyrproject.org/browse/ZEP-534


Re: QEMU networking: CONFIG_NET_TESTING breaks things, echo_server IPv6 address is "wrong"

Paul Sokolovsky
 

On Wed, 17 Aug 2016 20:19:06 -0000
"Flavio Santes" <flavio.santes(a)intel.com> wrote:

Hello

Hello,

Taking a chance, I'd like to start with drawing attention to
https://jira.zephyrproject.org/browse/ZEP-687 "docs:
Subsystems/Networking section is almost empty". Zephyr networking
See also https://jira.zephyrproject.org/browse/ZEP-188

information currently is sparse, disperse, bits are out of date, and
there're omissions/inconsistencies. Just linking a wiki landing
page from the official docs and letting community fill in that wiki
would be a good first step.
Agree

Anyway, waiting for real hardware support, I decided to give QEMU
networking a try. After some moderate googling, I arrived at
https://gerrit.zephyrproject.org/r/gitweb?p=net-tools.git;a=summary
and https://wiki.zephyrproject.org/view/Networking-with-Qemu . The
initial outcome: nothing works.
There is support for real hardware, see:
https://gerrit.zephyrproject.org/r/gitweb?p=zephyr.git;a=blob;f=samples/net/dns_client/prj_galileo.conf

There is also a driver for enc28j60, see:
https://jira.zephyrproject.org/browse/ZEP-291
https://www.olimex.com/Products/Modules/Ethernet/ENC28J60-H/resources/ENC28J60-H.pdf
Yes, thanks, I meant for Ethernet support in FRDM-K64F which I have on
my hands now.

[]

The obvious question is what to do in this situation. I'm personally
keen to update
https://wiki.zephyrproject.org/view/Networking-with-Qemu to
describe a setup which actually works now (this is mostly doing
steps in the right order, but also building with
CONFIG_NET_TESTING=n).
I've made first pass of changes to
https://wiki.zephyrproject.org/view/Networking-with-Qemu , ordering
connection bring up steps properly and adding a bit more info here and
there. Going to look into CONFIG_NET_TESTING in more detail before
adding suggestion to disable it in the wiki.


--
Best Regards,
Paul

Linaro.org | Open source software for ARM SoCs
Follow Linaro: http://www.facebook.com/pages/Linaro
http://twitter.com/#!/linaroorg - http://www.linaro.org/linaro-blog


Daily Gerrit Digest

donotreply@...
 

NEW within last 24 hours:
- https://gerrit.zephyrproject.org/r/4137 : samples/net: Remove call to unref routine when net_send returns >= 0
- https://gerrit.zephyrproject.org/r/4152 : Bluetooth: RFCOMM: Implement Register Server channel API
- https://gerrit.zephyrproject.org/r/4158 : Bluetooth: shell: Add support for RFCOMM test
- https://gerrit.zephyrproject.org/r/4155 : Bluetooth: RFCOMM: Handle signalling connection request
- https://gerrit.zephyrproject.org/r/4157 : Bluetooth: RFCOMM: Handle incoming dlc request
- https://gerrit.zephyrproject.org/r/4153 : Bluetooth: RFCOMM: Init buffer for outgoing signalling packets
- https://gerrit.zephyrproject.org/r/4156 : Bluetooth: RFCOMM: Handle PN request
- https://gerrit.zephyrproject.org/r/4151 : Bluetooth: RFCOMM: Initialize and register to L2CAP
- https://gerrit.zephyrproject.org/r/4154 : Bluetooth: RFCOMM: Introduce FCS table and functions
- https://gerrit.zephyrproject.org/r/4162 : sanitycheck: Add support for section net_l2_data
- https://gerrit.zephyrproject.org/r/4144 : net: tests: Enable unit tests for the new IP stack
- https://gerrit.zephyrproject.org/r/4160 : MAINTAINERS: add ARM and ARC architecture maintainers
- https://gerrit.zephyrproject.org/r/4161 : samples: power_mgmt: Update sample according to new Power Management device driver API
- https://gerrit.zephyrproject.org/r/4159 : timer: power_mgmt: Update code according to new Power Management idevice driver API
- https://gerrit.zephyrproject.org/r/4149 : uart: power_mgmt: Update code according to new Power Management idevice driver API
- https://gerrit.zephyrproject.org/r/4150 : spi: power_mgmt: Update code according to new Power Management idevice driver API
- https://gerrit.zephyrproject.org/r/4140 : doc: Fix terminology in Kconfig files for 'platform'
- https://gerrit.zephyrproject.org/r/4148 : rtc: power_mgmt: Update code according to new Power Management idevice driver API
- https://gerrit.zephyrproject.org/r/4147 : pwm: power_mgmt: Update code according to new Power Management idevice driver API
- https://gerrit.zephyrproject.org/r/4146 : pwm: power_mgmt: Update code according to new Power Management device driver API
- https://gerrit.zephyrproject.org/r/4145 : interrupt_controller: power_mgmt: Update code according to new Power Management idevice driver API
- https://gerrit.zephyrproject.org/r/4143 : gpio: power_mgmt: Update code according to new Power Management device driver API
- https://gerrit.zephyrproject.org/r/4142 : power_mgmt: Update Power Management device driver API
- https://gerrit.zephyrproject.org/r/4139 : TCF: adds test fixed by ZEP-704
- https://gerrit.zephyrproject.org/r/4138 : arch: RISC-V 64-bits architecture and MSVC targets were added.

UPDATED within last 24 hours:
- https://gerrit.zephyrproject.org/r/3994 : Bluetooth: Add RAW interface to Bluetooth
- https://gerrit.zephyrproject.org/r/4028 : Bluetooth: ATT: Make it safe to access the request list
- https://gerrit.zephyrproject.org/r/3995 : Bluetooth: Export USB HCI controller using RAW HCI channel
- https://gerrit.zephyrproject.org/r/3997 : Bluetooth: L2CAP: Implement connect command on BR/EDR
- https://gerrit.zephyrproject.org/r/4129 : Bluetooth: Include btusb sample to sanity check
- https://gerrit.zephyrproject.org/r/4128 : Bluetooth: Add documentation to HCI RAW interface
- https://gerrit.zephyrproject.org/r/3956 : arc: unify copied linker script
- https://gerrit.zephyrproject.org/r/3846 : arc: remove deprecated dynamic interrupt implementation
- https://gerrit.zephyrproject.org/r/4127 : qmsi:wdt: remove duplicated wdt clock enable code
- https://gerrit.zephyrproject.org/r/4088 : Bluetooth: Controller: Initial impl. of a HCI controller-side interface
- https://gerrit.zephyrproject.org/r/4105 : sanity: enable sanity multiple configuration
- https://gerrit.zephyrproject.org/r/4089 : Bluetooth: Controller: A full, hardware-agnostic Link Layer implementation
- https://gerrit.zephyrproject.org/r/4090 : Bluetooth: Controller: Add driver that glues Link Layer with the BLE stack
- https://gerrit.zephyrproject.org/r/4086 : Bluetooth: Controller: Hardware abstraction layer for nRF5x radio
- https://gerrit.zephyrproject.org/r/4091 : board: nrf52_pca10040: Include Controller by default in board nrf52_pca10040
- https://gerrit.zephyrproject.org/r/4087 : Bluetooth: Controller: Add a util folder with basic primitives
- https://gerrit.zephyrproject.org/r/4130 : drivers: spi: Fix typos in SPI port numbers
- https://gerrit.zephyrproject.org/r/3947 : sanitycheck: support for multiple toolchain
- https://gerrit.zephyrproject.org/r/2047 : !!DO NOT MERGE!! unified: snapshot of development status

MERGED within last 24 hours:
- https://gerrit.zephyrproject.org/r/4163 : Bluetooth: Fix race condition when initializing ECC FIFO
- https://gerrit.zephyrproject.org/r/4136 : Bluetooth: Fix race condition between ecc_send and ecc_task
- https://gerrit.zephyrproject.org/r/4141 : Merge remote-tracking branch 'origin/master' into net
- https://gerrit.zephyrproject.org/r/4135 : Revert "REVERTME exclude test_sha256 on Nios2"
- https://gerrit.zephyrproject.org/r/4112 : Bluetooth: L2CAP: Implement bt_l2cap_br_chan_send()
- https://gerrit.zephyrproject.org/r/4134 : Bluetooth: L2CAP: Make bt_l2cap_br_fixed_chan_register global
- https://gerrit.zephyrproject.org/r/4132 : Bluetooth: L2CAP: Use BIT macro for supported BR/EDR fixed channels
- https://gerrit.zephyrproject.org/r/4133 : Bluetooth: L2CAP: Remove mask from struct bt_l2cap_fixed_chan
- https://gerrit.zephyrproject.org/r/4120 : test_ipm: disable on Quark SE ARC core
- https://gerrit.zephyrproject.org/r/4119 : arc: fix management of IRQ priority levels
- https://gerrit.zephyrproject.org/r/4124 : enc28j60: Correction to ECON1.RXEN bit location
- https://gerrit.zephyrproject.org/r/4123 : enc28j60: rx fiber's stack size is increased
- https://gerrit.zephyrproject.org/r/3724 : sanitycheck: Recognize YAIP specific sections
- https://gerrit.zephyrproject.org/r/3722 : net: yaip: Debugging function to print fragment chain information
- https://gerrit.zephyrproject.org/r/3720 : net: tests: Fix project file for IP address tests
- https://gerrit.zephyrproject.org/r/3707 : net: yaip: Generic connection handler for UDP and TCP
- https://gerrit.zephyrproject.org/r/3705 : net: yaip: Add support for ICMPv6 error message
- https://gerrit.zephyrproject.org/r/3711 : net: tests: Fix ARP test so that it will not crash
- https://gerrit.zephyrproject.org/r/3726 : net: Refine Kconfig to put NET_BUF appart
- https://gerrit.zephyrproject.org/r/4079 : enc28j60: allow simultaneous reception and transmission
- https://gerrit.zephyrproject.org/r/4078 : enc28j60: remove rx interruption handling
- https://gerrit.zephyrproject.org/r/4077 : enc28j60: hardware errata #14 ERXRDPT register failure
- https://gerrit.zephyrproject.org/r/4106 : ipm_console: rate-limit to avoid losing messages
- https://gerrit.zephyrproject.org/r/4076 : enc28j60: hardware errata #6 PKTIF is unreliable
- https://gerrit.zephyrproject.org/r/3728 : net: yaip: Let's use inline function for type checking for net_nbuf
- https://gerrit.zephyrproject.org/r/4107 : ipm_console_receiver: correctly populate driver data
- https://gerrit.zephyrproject.org/r/3725 : samples: Fix echo_server for YAIP
- https://gerrit.zephyrproject.org/r/3721 : net: yaip: Refactor nbuf.h and nbuf.c
- https://gerrit.zephyrproject.org/r/3719 : net: tests: Fix IP address test so that it will not crash
- https://gerrit.zephyrproject.org/r/4121 : fat_fs: zfs_diskio: use same typedefs in header
- https://gerrit.zephyrproject.org/r/3718 : net: tests: ICMPv6 was missing random number config
- https://gerrit.zephyrproject.org/r/3715 : net: tests: Turning off IPv6 for ARP tests
- https://gerrit.zephyrproject.org/r/3712 : net: yaip: Utility function to compact net_buf fragments
- https://gerrit.zephyrproject.org/r/3710 : net: tests: Unit tests for UDP handler
- https://gerrit.zephyrproject.org/r/3709 : net: yaip: Catch UDP network traffic
- https://gerrit.zephyrproject.org/r/3708 : net: yaip: Initial UDP support
- https://gerrit.zephyrproject.org/r/3716 : net: yaip: Refactored IPv6 DAD and ND activation
- https://gerrit.zephyrproject.org/r/3727 : net: yaip: Moving header files to include/net/yaip
- https://gerrit.zephyrproject.org/r/3717 : net: yaip: Fix compilation when IPv6 is disabled
- https://gerrit.zephyrproject.org/r/3713 : net: yaip: Utility that inserts free space to the fragment list
- https://gerrit.zephyrproject.org/r/3706 : net: yaip: Add support for ICMPv4 error message
- https://gerrit.zephyrproject.org/r/3714 : net: tests: Unit tests for net_nbuf_push()
- https://gerrit.zephyrproject.org/r/3704 : net: yaip: Add IPv6 minimum MTU value
- https://gerrit.zephyrproject.org/r/3670 : slip: Fix the debug print
- https://gerrit.zephyrproject.org/r/3672 : net: yaip: Initializing the ll src and dst addresses
- https://gerrit.zephyrproject.org/r/3668 : net: yaip: Make sure ethernet l2 sets src and dst addresses
- https://gerrit.zephyrproject.org/r/3703 : net: yaip: Make some IPv6 utility functions to use const addr
- https://gerrit.zephyrproject.org/r/3699 : net: Kconfig: Refactor Kconfig menus for better clarity
- https://gerrit.zephyrproject.org/r/3702 : net: yaip: Add TTL IPv4 option
- https://gerrit.zephyrproject.org/r/3701 : net: tests: Add unit tests for net_nbuf_copy()
- https://gerrit.zephyrproject.org/r/3700 : net: yaip: Add net_nbuf_copy() utility function
- https://gerrit.zephyrproject.org/r/3637 : net: yaip: Add struct to store link layer address
- https://gerrit.zephyrproject.org/r/3691 : slip: Network stack needs to be up before sending data to it
- https://gerrit.zephyrproject.org/r/3636 : net: yaip: Print available DATA buffers during nbuf alloc
- https://gerrit.zephyrproject.org/r/3638 : net: yaip: Use const for static and pre-defined IPv6 addresses
- https://gerrit.zephyrproject.org/r/3689 : net: yaip: Set multicast dst address in ethernet if missing
- https://gerrit.zephyrproject.org/r/3633 : net: yaip: Add comment explaining net_core's verdict values
- https://gerrit.zephyrproject.org/r/3692 : net: yaip: Start the network stack after device drivers
- https://gerrit.zephyrproject.org/r/3695 : net: yaip: Initial IPv6 neighbor discovery support
- https://gerrit.zephyrproject.org/r/3698 : net: yaip: Make IPv6 ND optional
- https://gerrit.zephyrproject.org/r/3696 : net: yaip: Initial router solicitation support
- https://gerrit.zephyrproject.org/r/3694 : slip: Setup fragments properly if MTU is bigger than frag size
- https://gerrit.zephyrproject.org/r/3697 : net: yaip: Initial router advertisement support
- https://gerrit.zephyrproject.org/r/3693 : slip: Do not try to unref a null pointer
- https://gerrit.zephyrproject.org/r/3679 : net: yaip: IPv4 protocol type was not set to sent ARP packet
- https://gerrit.zephyrproject.org/r/3634 : net: yaip: Moved ARP helper macro to arp.h
- https://gerrit.zephyrproject.org/r/3685 : net: yaip: Refactored ARP packet header handling
- https://gerrit.zephyrproject.org/r/3683 : net: yaip: Ethernet L2 TX side needs to setup fragments
- https://gerrit.zephyrproject.org/r/3684 : net: yaip: Add more checks when allocating nbuf
- https://gerrit.zephyrproject.org/r/3632 : net: yaip: Save some bytes on net_if logic
- https://gerrit.zephyrproject.org/r/3688 : net: yaip: Add a utility to hexdump all fragments
- https://gerrit.zephyrproject.org/r/3631 : net: yaip: Add NET_ASSERT() macro
- https://gerrit.zephyrproject.org/r/3690 : net: yaip: Remove extra debug print in ethernet L2 driver
- https://gerrit.zephyrproject.org/r/3687 : net: yaip: Pointer to a ethernet header was incorrectly set
- https://gerrit.zephyrproject.org/r/3686 : net: yaip: ARP unit test needs to be run from fiber
- https://gerrit.zephyrproject.org/r/3682 : net: yaip: Add more debug print in ethernet RX side
- https://gerrit.zephyrproject.org/r/3680 : net: yaip: Reserve eth ll header len in L2 ethernet driver
- https://gerrit.zephyrproject.org/r/3676 : net: yaip: Add utility func to return eth broadcast addr
- https://gerrit.zephyrproject.org/r/3678 : net: yaip: Add more debugging to arp.c
- https://gerrit.zephyrproject.org/r/3681 : net: yaip: Add debug checks when sending data in TX fiber
- https://gerrit.zephyrproject.org/r/3677 : net: yaip: Both TX and RX fibers allow other fibers to run
- https://gerrit.zephyrproject.org/r/3675 : net: yaip: Add debug support to ethernet L2 driver
- https://gerrit.zephyrproject.org/r/3671 : net: yaip: Add link layer reserve information to l2 driver
- https://gerrit.zephyrproject.org/r/3673 : net: yaip: ARP reply did not set the address family
- https://gerrit.zephyrproject.org/r/3657 : net: yaip: Changed the IP and ll address debug prints
- https://gerrit.zephyrproject.org/r/3658 : net: tests: Fix unit test for IP addresses
- https://gerrit.zephyrproject.org/r/3674 : net: yaip: Calling net_buf_put() instead of nano_fifo_put()
- https://gerrit.zephyrproject.org/r/3655 : net: yaip: Fix arp.h so that net_arp_init() is found
- https://gerrit.zephyrproject.org/r/3663 : net: yaip: Re-send ARP when needed
- https://gerrit.zephyrproject.org/r/3669 : net: yaip: Write ethernet header in pdu when using slip and tap
- https://gerrit.zephyrproject.org/r/3661 : net: yaip: Change how the L2 header space is reserved in net_buf
- https://gerrit.zephyrproject.org/r/3653 : net: yaip: Print statistics using SYS_LOG
- https://gerrit.zephyrproject.org/r/3652 : net: yaip: Network stack analyzer uses now the SYS_LOG sub-system
- https://gerrit.zephyrproject.org/r/3654 : net: yaip: Depending on debug flags the stdio.h is not included
- https://gerrit.zephyrproject.org/r/3659 : net: tests: Fix unit test for IP utils
- https://gerrit.zephyrproject.org/r/3662 : net: yaip: Add utility to remove ipv4 address from iface
- https://gerrit.zephyrproject.org/r/3660 : net: yaip: Make sure that either IPv4 or IPv6 gets selected
- https://gerrit.zephyrproject.org/r/3651 : net: yaip: Do not overwrite SYS_LOG_DOMAIN
- https://gerrit.zephyrproject.org/r/3656 : net: tests: Fix unit test for ARP
- https://gerrit.zephyrproject.org/r/3650 : net: yaip: The NET_DEBUG must not be set in header file


Re: [RFC] Power Management Infrastructure

Nashif, Anas
 

Amir,
All commits need to pass Jenkins, so you should make the changes and organise the commits in a way that keeps Jenkins happy all the way.

Thanks,
Anas

On 18/08/2016, 12:03, "Kaplan, Amir" <amir.kaplan(a)intel.com> wrote:

Hi,
Following Ramesh and Ku-Lang's feedbacks we have split the changes to multiple small patches(instead of the original delivery).

Note: Due to the fact that the drivers changes depends on the change in device.h only the last delivery(https://gerrit.zephyrproject.org/r/#/c/4161/) passes all required verifications in Jenkins.

Below are the updated deliveries:
Device API:
https://gerrit.zephyrproject.org/r/#/c/4142/

gpio:
https://gerrit.zephyrproject.org/r/#/c/4143/

interrupt_controler:
https://gerrit.zephyrproject.org/r/#/c/4145/

pwm:
https://gerrit.zephyrproject.org/r/#/c/4147/

rtc:
https://gerrit.zephyrproject.org/r/#/c/4148/

uart:
https://gerrit.zephyrproject.org/r/#/c/4149/

spi:
https://gerrit.zephyrproject.org/r/#/c/4150/

timer:
https://gerrit.zephyrproject.org/r/#/c/4159/

samples:
https://gerrit.zephyrproject.org/r/#/c/4161/

Regards,
Amir & Keren

-----Original Message-----
From: Kaplan, Amir
Sent: Monday, August 15, 2016 13:36
To: devel(a)lists.zephyrproject.org
Cc: Rahamim, Hezi <hezi.rahamim(a)intel.com>; Siman-tov, Keren <keren.siman-tov(a)intel.com>; Kanner, Noa <noa.kanner(a)intel.com>
Subject: RE: [devel] Re: Re: Re: Re: Re: [RFC] Power Management Infrastructure

Hi all,

The corresponding Gerrit link:
https://gerrit.zephyrproject.org/r/4081


-----Original Message-----
From: Kaplan, Amir
Sent: Monday, August 15, 2016 11:18
To: 'devel(a)lists.zephyrproject.org' <devel(a)lists.zephyrproject.org>
Cc: Rahamim, Hezi <hezi.rahamim(a)intel.com>; Siman-tov, Keren <keren.siman-tov(a)intel.com>; Kaplan, Amir <amir.kaplan(a)intel.com>; Kanner, Noa <noa.kanner(a)intel.com>
Subject: RE: [devel] Re: Re: Re: Re: Re: [RFC] Power Management Infrastructure

Hi all,
After reviewing all the comments and consulting Ramesh, below is the updated RFC:

Current state
===========

In the current Zephyr implementation the driver power hooks distinguish only between two driver states (suspend and resume). Drivers may have more than two states (i.e. D-states) and can traverse between those states. The state change today is limited only from active to suspend while there can be cases of other transitions requested by the application.
Please look at the below suggested device power states E.g. transition between DEVICE_PM_LOW_POWER_STATE to DEVICE_PM_OFF_STATE.

Moreover, the current device state cannot be queried by an application or a Power Manager service.

Below is the current Zephyr PM hooks:

struct device_pm_ops {
int (*suspend)(struct device *device, int pm_policy);
int (*resume)(struct device *device, int pm_policy); };

Proposed changes
===============

1. Have one function that can be used for all possible device PM purposes using a control code instead of the suspend resume functions:

int (*device_pm_control)(struct device *device, int pm_command, int device_power_state);

In first version will support DEVICE_SET_POWER_STATE and DEVICE_GET_POWER_STATE commands.

2. Add the below device power states:
Note: Many devices do not have all four power states defined.

DEVICE_PM_ACTIVE_STATE
--------------------------------------------
Normal operation of the device. All device context is retained.

DEVICE_PM_LOW_POWER_STATE
-------------------------------------------------------
Device context is preserved by the HW and need not be restored by the driver.
The device do not allow the Power Manager service to power it down.

DEVICE_PM_SUSPEND_STATE
------------------------------------------------
Most device context is lost by the hardware.
Device drivers must save and restore or reinitialize any context lost by the hardware.
The device can be powered down.
The device is allowing a wake signal to send them to active state.

DEVICE_PM_OFF_STATE
---------------------------------------
Power has been fully removed from the device. The device context is lost when this state is entered, so the OS software will reinitialize the device when powering it back on.
Device may not wake itself as the SoC need to reinitialize the device.

3. The set state functionality (via device_pm_control ) will behave according to the state transition of a specific driver. E.g. transition from active state to suspend state in a UART device will save device states and gate the clock.
The set state functionality (via device_pm_control ) will enable the Power Manager service to know the state of a driver if needed thus enable it to configure the SoC power behavior.

The advantages in the new method:
1. Active device PM that does not need system to go idle to do device PM. Any component can call it. Multiple PM states and transitions need not always between active and low power states.
2. Reduces memory use and complexity because now there is only one function.
3. Compatible with legacy suspend/resume done from central PMA during idle 4. Scalable- In future more control codes can be added to support other device pm operations without having to change infrastructure.

Regards,
Amir, Keren, Hezi

-----Original Message-----
From: Rahamim, Hezi
Sent: Wednesday, August 10, 2016 10:18
To: Kaplan, Amir <amir.kaplan(a)intel.com>; Siman-tov, Keren <keren.siman-tov(a)intel.com>
Subject: FW: [devel] Re: Re: Re: Re: Re: [RFC] Power Management Infrastructure



-----Original Message-----
From: Thomas, Ramesh
Sent: Friday, July 15, 2016 06:22
To: Rahamim, Hezi <hezi.rahamim(a)intel.com>; devel(a)lists.zephyrproject.org
Subject: Re: [devel] Re: Re: Re: Re: Re: [RFC] Power Management Infrastructure



On 07/14/2016 06:17 AM, Rahamim, Hezi wrote:
> Hi Ramesh'
>
> Please see my comments below.
>
> Regards,
> Hezi
>
> -----Original Message-----
> From: Thomas, Ramesh [mailto:ramesh.thomas(a)intel.com]
> Sent: Thursday, July 14, 2016 10:32
> To: devel(a)lists.zephyrproject.org
> Subject: [devel] Re: Re: Re: Re: Re: [RFC] Power Management
> Infrastructure
>
> On 7/13/2016 11:40 PM, Rahamim, Hezi wrote:
>> Hi Dimitriy,
>>
>> The get_state is there only for symmetry and good practice.
>> As mentioned below the power manager service will probably not use it as it is not efficient to do get_state to all devices to know all the devices states...
>> The more important part of the RFC is adding the set_state function and the device policies.
>
> That made me think why we originally came up with 2 functions when one was enough. Probably we thought the same way - to keep symmetry. Problem is that we will keep getting more needs and we will either add more functions to device_pm_ops or will have to change existing ones.
>
> How about having one function that can be used for all possible device
> PM purposes using a control code? Something like following :-
>
> int device_pm_control(device, flags);
>
> flags = (CONTROL_CODE | SYSTEM_POWER_STATE | DEVICE_POWER_STATE)
>
> CONTROL_CODE = {SET_POWER_STATE, GET_POWER_STATE, ...}
> DEVICE_POWER_STATE = {device PM states} SYSTEM_POWER_STATE = {system
> power policies}
>
> (We can add additional parameters if flags param is overloaded)
>
> returns value based on CONTROL_CODE
> e.g. returns device power state if CONTROL_CODE == GET_POWER_STATE
>
> (We probably don't need device_pm_ops if we have only one function.)
>
> [HR] Looks good. If the PM service will be designed as a driver than it can use the SYSTEM_POWER_STATE and a device driver will use the DEVICE_POWER_STATE.
>
>
> ***I also have some questions inline below***
>
>
>>
>> Thanks for the comment,
>> Hezi
>>
>> -----Original Message-----
>> From: Dmitriy Korovkin [mailto:dmitriy.korovkin(a)windriver.com]
>> Sent: Thursday, July 14, 2016 00:41
>> To: devel(a)lists.zephyrproject.org
>> Subject: [devel] Re: Re: Re: [RFC] Power Management Infrastructure
>>
>> Hi Hezi,
>> I think RFC needs to be extended with the description of the idea of controlling power state of each device (if I got you correctly).
>> Without it the need of
>> int (*get_state)(struct device *device, int device_pm_policy); looks very unclear.
>> If all you need is to provide more that two states, then set_state() looks quite enough.
>>
>> Regards,
>>
>> Dmitriy Korovkin
>>
>> On 16-07-13 12:11 PM, Rahamim, Hezi wrote:
>>> Hi Ramesh,
>>>
>>> Please see my comments below/
>>>
>>> Thanks for the comments,
>>> Hezi
>>>
>>> -----Original Message-----
>>> From: Thomas, Ramesh [mailto:ramesh.thomas(a)intel.com]
>>> Sent: Wednesday, July 13, 2016 09:41
>>> To: devel(a)lists.zephyrproject.org
>>> Subject: [devel] Re: [RFC] Power Management Infrastructure
>>>
>>> On 7/12/2016 2:03 AM, Rahamim, Hezi wrote:
>>>> Hi all,
>>>>
>>>> Current state
>>>>
>>>> ===========
>>>>
>>>> In the current Zephyr implementation the driver power hooks
>>>> distinguish only
>>>>
>>>> between two driver states (suspend and resume). Drivers may have
>>>> more than two
>>>
>>> Currently suspend and resume are not actually states but a notification of the state transition. There is a second argument to those functions that specify the current policy for which the transition is happening.
>>>
>>>>
>>>> states (i.e. D-states) and can traverse between those states. The
>>>> state change
>>>>
>>>> today is limited only from active to suspend while there can be
>>>> cases of other
>>>>
>>>> transitions requested by the application.
>>>>
>>>> Please look at the below suggested device power states E.g.
>>>> transition between
>>>>
>>>> DEVICE_PM_LOW_POWER_STATE to DEVICE_PM_OFF_STATE.
>>>>
>>>> Moreover, the current device state cannot be queried by an
>>>> application or
>>>>
>>>> a Power Manager service.
>>>>
>>>> Below is the current Zephyr PM hooks:
>>>>
>>>> struct device_pm_ops {
>>>>
>>>> int (*suspend)(struct device *device, int pm_policy);
>>>>
>>>> int (*resume)(struct device *device, int pm_policy);
>>>>
>>>> };
>>>>
>>>> Proposed changes
>>>>
>>>> ===============
>>>>
>>>> First proposed change is to have a set state and get state driver
>>>> functions
>>>>
>>>> instead of the suspend resume functions:
>>>>
>>>> struct device_pm_ops {
>>>>
>>>> int (*set_state)(struct device *device, int
>>>> device_pm_policy);
>>>>
>>>> int (*get_state)(struct device *device, int
>>>> device_pm_policy);
>>>>
>>>> };
>>>>
>>>> The set_state function will behave according to the state
>>>> transition of a specific
>>>>
>>>> driver. E.g. transition from active state to suspend state in a
>>>> UART device will
>>>>
>>>> save device states and gate the clock.
>>>
>>> The proposal, as I understand, is to use the pm hooks to actively
>>> control the power states instead of using them as just notifications
>>> of the SOC's power transitions. Considering this, we had one power
>>> policy called "device_suspend_only". That is open to be broken down
>>> into more device specific power states.
>>>
>>> [HR] You are correct, we intend to use the pm driver hooks to
>>> actively control the device Power states. We will use the Zephyer's
>>> current power policies to indicate the system power state. As you
>>> mentioned, when devices will not be in active state the system can still be at "device_suspend_only" state.
>
> Do you see any issues with the apps/drivers keeping the PM service updated of the device's current state in real time? What about race conditions? Complexity of communication framework?
> [HR] The need of communication framework and device state database
> lock may be needed. For example, inter processor communication may be
> needed if in a specific SoC there are shared power resources between
> two cores (in AtP3 we may avoid that...)
>
>>>
>>>>
>>>> The get_state function will enable the Power Manager service to
>>>> know the state
>>>>
>>>> of each driver thus enable it to configure the SoC power behavior.
>>>>
>>>
>>> The set_state function looks ok. It is the same as the current
>>> suspend but with the name change. The purpose of the name change is
>>> to add a corresponding get_state. The RFC is not giving much
>>> details of the use of the get_state function.
>>>
>>> I assume there is a need for the PM service to build a device tree,
>>> with power hierarchy. It would be helpful if you could explain how
>>> this function fits in your larger design of the PM service's power
>>> policy management of the devices.
>>>
>>> [HR] I will give an example:
>>> A user application decides to suspend the I2C and the SPI devices.
>>> The application will then call the corresponding set_state functions of these devices.
>>> The set_state functions will perform the store of the relevant
>>> device state and gate the device clock. In the next idle time the _sys_soc_suspend will be called.
>>> This will trigger the power manager service which will decide what
>>> should be done to optimize the power (clock gate a branch or change the system power state.
>>> The decision of the power manager service will be based on the
>>> devices states which can be obtained also by using the get_state functions.
>>>
>>> Since the PM service is expected to have communication established
>>> with all components in the system, wouldn't it know what state each
>>> device is set to? Querying each device and building a tree every
>>> time there is an opportunity to suspend, may take some time causing delay in suspend.
>>>
>>> [HR] You are correct, using the get_state function will lead to a
>>> less optimal Power manager service and it will need to use a more optimized method.
>>> However, it is a good practice to have this function as the
>>> application may want to query the device state.
>>>
>>>> Second proposed change is to add the below device power states:
>>>>
>>>> Note: Many devices do not have all four power states defined.
>>>>
>>>> DEVICE_PM_ACTIVE_STATE
>>>>
>>>> --------------------------------------------
>>>>
>>>> Normal operation of the device. All device context is retained.
>>>>
>>>> DEVICE_PM_LOW_POWER_STATE
>>>>
>>>> -------------------------------------------------------
>>>>
>>>> Device context is preserved by the HW and need not be restored by
>>>> the driver.
>>>>
>>>> The device do not allow the Power Manager service to power it down.
>>>>
>>>> DEVICE_PM_SUSPEND_STATE
>>>>
>>>> ------------------------------------------------
>>>>
>>>> Most device context is lost by the hardware.
>>>>
>>>> Device drivers must save and restore or reinitialize any context
>>>> lost
>>>>
>>>> by the hardware.
>>>>
>>>> The device can be powered down.
>>>>
>>>> The device is allowing a wake signal to send them to active state.
>>>>
>>>> DEVICE_PM_OFF_STATE
>>>>
>>>> ---------------------------------------
>>>>
>>>> Power has been fully removed from the device. The device context is
>>>> lost
>>>>
>>>> when this state is entered, so the OS software will reinitialize
>>>> the device
>>>>
>>>> when powering it back on.
>>>>
>>>> Device may not wake itself as the SoC need to reinitialize the device.
>>>>
>>>
>>> The description of the power states here sounds like they are
>>> notifications. It sounds like some other component is setting the
>>> power state and notifies using these values and the drivers do
>>> save/restore or other operations based on the notification. Are the
>>> drivers expected to gate clocks, turn off peripherals etc. in these notifications?
>>>
>>> [HR] These device power states serve two purposes:
>>> 1. The drivers are expected to perform all the power/clock changes
>>> It can perform according to the selected power state and do not
>>> influence other drivers.
>>> 2. The power manager service will use the drivers states to decide
>>> on system power policy to go to (it can also stay in
>>> SYS_PM_DEVICE_SUSPEND_ONLY but to optimize the clock gating scheme)
>
> Would these become part of a specification that all device drivers would need to implement? In this scheme, the PM responsibilities are shared between PM Service, various apps and drivers. So some plan needs to be in place to ensure all of them cooperate as expected.
> [HR] You are right, there is a need to define the PM responsibilities of the PM service, drivers and apps. However, this RFC was written to add the ability to support more than two device states, define the available states and to enable transition between them.
> We will be happy to contribute also to define the above.

The device PM states look ok to me. They are architecture independent and the drivers can map them to device specific operations.

I think this RFC should be part of other RFCs that define the bigger picture of how it is used. As I see it, the kind of device PM you propose can function independent of system idle. In my opinion, it would be good to define it independent of system power management. The 2 will coordinate, but should not be a requirement. That way, either infrastructure can be used independently by users. Also there would be implementations that would want to do all device PM in the PM service for various reasons.

>
>>>
>>> The initial part of the RFC does mention the application can set the
>>> power state of the device and that is what the proposed set_state
>>> function also suggests.
>>>
>>> Do they serve both purposes? May be an example of how the device's
>>> power state is actively changed and who and when does it, with
>>> respect to these notifications, would help.
>>>
>>> [HR] Here is an example:
>>> There are three peripherals in a certain SOC: UART, I2C and SPI.
>>> Both I2C and SPI are fed from the same PLL and the UART from a second one.
>>> At the beginning the three peripherals are at DEVICE_PM_ACTIVE_STATE.
>>> The user application decides that the I2C and the SPI should go to suspend.
>>> It then calls the set_state function of these devices with DEVICE_PM_SUSPEND_STATE.
>>> When idle comes the PM service is called and see that it can close the SPI and I2C PLL.
>>> However, it cannot move to SYS_PM_DEEP_SLEEP as the UART is still active.
>
> Will the PM service also put devices to suspend state, or only the apps will do it? Looks like the PM Service will never enter Deep Sleep if any device is on - any exceptions?
> [HR] Only apps will do that. The PM service can decide in some cases to go to deep sleep even if specific device is active (e.g. the device is located in the always on power domain). The decision to change power state is SoC specific.
>
> In the above example, the system had to go to idle for the PLL to get turned off. If you had a central scheme to turn off clocks then the PLL could have been turned off when both i2c and spi got turned off. Just an observation.
> [HR] There are indeed several ways to solve this and there will be a need to choose the best one for the specific SoC.
>>>
>>>> Comments/concerns welcome.
>>>>
>>>> Thanks,
>>>>
>>>> Hezi
>>>>
>>>> -------------------------------------------------------------------
>>>> -
>>>> - A member of the Intel Corporation group of companies
>>>>
>>>> This e-mail and any attachments may contain confidential material
>>>> for the sole use of the intended recipient(s). Any review or
>>>> distribution by others is strictly prohibited. If you are not the
>>>> intended recipient, please contact the sender and delete all copies.
>>>>
>>> --------------------------------------------------------------------
>>> - A member of the Intel Corporation group of companies
>>>
>>> This e-mail and any attachments may contain confidential material
>>> for the sole use of the intended recipient(s). Any review or
>>> distribution by others is strictly prohibited. If you are not the
>>> intended recipient, please contact the sender and delete all copies.
>>>
>> ---------------------------------------------------------------------
>> A member of the Intel Corporation group of companies
>>
>> This e-mail and any attachments may contain confidential material for
>> the sole use of the intended recipient(s). Any review or distribution
>> by others is strictly prohibited. If you are not the intended
>> recipient, please contact the sender and delete all copies.
>>
---------------------------------------------------------------------
A member of the Intel Corporation group of companies

This e-mail and any attachments may contain confidential material for
the sole use of the intended recipient(s). Any review or distribution
by others is strictly prohibited. If you are not the intended
recipient, please contact the sender and delete all copies.


Re: [RFC] Power Management Infrastructure

Kaplan, Amir
 

Hi,
Following Ramesh and Ku-Lang's feedbacks we have split the changes to multiple small patches(instead of the original delivery).

Note: Due to the fact that the drivers changes depends on the change in device.h only the last delivery(https://gerrit.zephyrproject.org/r/#/c/4161/) passes all required verifications in Jenkins.

Below are the updated deliveries:
Device API:
https://gerrit.zephyrproject.org/r/#/c/4142/

gpio:
https://gerrit.zephyrproject.org/r/#/c/4143/

interrupt_controler:
https://gerrit.zephyrproject.org/r/#/c/4145/

pwm:
https://gerrit.zephyrproject.org/r/#/c/4147/

rtc:
https://gerrit.zephyrproject.org/r/#/c/4148/

uart:
https://gerrit.zephyrproject.org/r/#/c/4149/

spi:
https://gerrit.zephyrproject.org/r/#/c/4150/

timer:
https://gerrit.zephyrproject.org/r/#/c/4159/

samples:
https://gerrit.zephyrproject.org/r/#/c/4161/

Regards,
Amir & Keren

-----Original Message-----
From: Kaplan, Amir
Sent: Monday, August 15, 2016 13:36
To: devel(a)lists.zephyrproject.org
Cc: Rahamim, Hezi <hezi.rahamim(a)intel.com>; Siman-tov, Keren <keren.siman-tov(a)intel.com>; Kanner, Noa <noa.kanner(a)intel.com>
Subject: RE: [devel] Re: Re: Re: Re: Re: [RFC] Power Management Infrastructure

Hi all,

The corresponding Gerrit link:
https://gerrit.zephyrproject.org/r/4081


-----Original Message-----
From: Kaplan, Amir
Sent: Monday, August 15, 2016 11:18
To: 'devel(a)lists.zephyrproject.org' <devel(a)lists.zephyrproject.org>
Cc: Rahamim, Hezi <hezi.rahamim(a)intel.com>; Siman-tov, Keren <keren.siman-tov(a)intel.com>; Kaplan, Amir <amir.kaplan(a)intel.com>; Kanner, Noa <noa.kanner(a)intel.com>
Subject: RE: [devel] Re: Re: Re: Re: Re: [RFC] Power Management Infrastructure

Hi all,
After reviewing all the comments and consulting Ramesh, below is the updated RFC:

Current state
===========

In the current Zephyr implementation the driver power hooks distinguish only between two driver states (suspend and resume). Drivers may have more than two states (i.e. D-states) and can traverse between those states. The state change today is limited only from active to suspend while there can be cases of other transitions requested by the application.
Please look at the below suggested device power states E.g. transition between DEVICE_PM_LOW_POWER_STATE to DEVICE_PM_OFF_STATE.

Moreover, the current device state cannot be queried by an application or a Power Manager service.

Below is the current Zephyr PM hooks:

struct device_pm_ops {
int (*suspend)(struct device *device, int pm_policy);
int (*resume)(struct device *device, int pm_policy); };

Proposed changes
===============

1. Have one function that can be used for all possible device PM purposes using a control code instead of the suspend resume functions:

int (*device_pm_control)(struct device *device, int pm_command, int device_power_state);

In first version will support DEVICE_SET_POWER_STATE and DEVICE_GET_POWER_STATE commands.

2. Add the below device power states:
Note: Many devices do not have all four power states defined.

DEVICE_PM_ACTIVE_STATE
--------------------------------------------
Normal operation of the device. All device context is retained.

DEVICE_PM_LOW_POWER_STATE
-------------------------------------------------------
Device context is preserved by the HW and need not be restored by the driver.
The device do not allow the Power Manager service to power it down.

DEVICE_PM_SUSPEND_STATE
------------------------------------------------
Most device context is lost by the hardware.
Device drivers must save and restore or reinitialize any context lost by the hardware.
The device can be powered down.
The device is allowing a wake signal to send them to active state.

DEVICE_PM_OFF_STATE
---------------------------------------
Power has been fully removed from the device. The device context is lost when this state is entered, so the OS software will reinitialize the device when powering it back on.
Device may not wake itself as the SoC need to reinitialize the device.

3. The set state functionality (via device_pm_control ) will behave according to the state transition of a specific driver. E.g. transition from active state to suspend state in a UART device will save device states and gate the clock.
The set state functionality (via device_pm_control ) will enable the Power Manager service to know the state of a driver if needed thus enable it to configure the SoC power behavior.

The advantages in the new method:
1. Active device PM that does not need system to go idle to do device PM. Any component can call it. Multiple PM states and transitions need not always between active and low power states.
2. Reduces memory use and complexity because now there is only one function.
3. Compatible with legacy suspend/resume done from central PMA during idle 4. Scalable- In future more control codes can be added to support other device pm operations without having to change infrastructure.

Regards,
Amir, Keren, Hezi

-----Original Message-----
From: Rahamim, Hezi
Sent: Wednesday, August 10, 2016 10:18
To: Kaplan, Amir <amir.kaplan(a)intel.com>; Siman-tov, Keren <keren.siman-tov(a)intel.com>
Subject: FW: [devel] Re: Re: Re: Re: Re: [RFC] Power Management Infrastructure



-----Original Message-----
From: Thomas, Ramesh
Sent: Friday, July 15, 2016 06:22
To: Rahamim, Hezi <hezi.rahamim(a)intel.com>; devel(a)lists.zephyrproject.org
Subject: Re: [devel] Re: Re: Re: Re: Re: [RFC] Power Management Infrastructure



On 07/14/2016 06:17 AM, Rahamim, Hezi wrote:
Hi Ramesh'

Please see my comments below.

Regards,
Hezi

-----Original Message-----
From: Thomas, Ramesh [mailto:ramesh.thomas(a)intel.com]
Sent: Thursday, July 14, 2016 10:32
To: devel(a)lists.zephyrproject.org
Subject: [devel] Re: Re: Re: Re: Re: [RFC] Power Management
Infrastructure

On 7/13/2016 11:40 PM, Rahamim, Hezi wrote:
Hi Dimitriy,

The get_state is there only for symmetry and good practice.
As mentioned below the power manager service will probably not use it as it is not efficient to do get_state to all devices to know all the devices states...
The more important part of the RFC is adding the set_state function and the device policies.
That made me think why we originally came up with 2 functions when one was enough. Probably we thought the same way - to keep symmetry. Problem is that we will keep getting more needs and we will either add more functions to device_pm_ops or will have to change existing ones.

How about having one function that can be used for all possible device
PM purposes using a control code? Something like following :-

int device_pm_control(device, flags);

flags = (CONTROL_CODE | SYSTEM_POWER_STATE | DEVICE_POWER_STATE)

CONTROL_CODE = {SET_POWER_STATE, GET_POWER_STATE, ...}
DEVICE_POWER_STATE = {device PM states} SYSTEM_POWER_STATE = {system
power policies}

(We can add additional parameters if flags param is overloaded)

returns value based on CONTROL_CODE
e.g. returns device power state if CONTROL_CODE == GET_POWER_STATE

(We probably don't need device_pm_ops if we have only one function.)

[HR] Looks good. If the PM service will be designed as a driver than it can use the SYSTEM_POWER_STATE and a device driver will use the DEVICE_POWER_STATE.


***I also have some questions inline below***



Thanks for the comment,
Hezi

-----Original Message-----
From: Dmitriy Korovkin [mailto:dmitriy.korovkin(a)windriver.com]
Sent: Thursday, July 14, 2016 00:41
To: devel(a)lists.zephyrproject.org
Subject: [devel] Re: Re: Re: [RFC] Power Management Infrastructure

Hi Hezi,
I think RFC needs to be extended with the description of the idea of controlling power state of each device (if I got you correctly).
Without it the need of
int (*get_state)(struct device *device, int device_pm_policy); looks very unclear.
If all you need is to provide more that two states, then set_state() looks quite enough.

Regards,

Dmitriy Korovkin

On 16-07-13 12:11 PM, Rahamim, Hezi wrote:
Hi Ramesh,

Please see my comments below/

Thanks for the comments,
Hezi

-----Original Message-----
From: Thomas, Ramesh [mailto:ramesh.thomas(a)intel.com]
Sent: Wednesday, July 13, 2016 09:41
To: devel(a)lists.zephyrproject.org
Subject: [devel] Re: [RFC] Power Management Infrastructure

On 7/12/2016 2:03 AM, Rahamim, Hezi wrote:
Hi all,

Current state

===========

In the current Zephyr implementation the driver power hooks
distinguish only

between two driver states (suspend and resume). Drivers may have
more than two
Currently suspend and resume are not actually states but a notification of the state transition. There is a second argument to those functions that specify the current policy for which the transition is happening.


states (i.e. D-states) and can traverse between those states. The
state change

today is limited only from active to suspend while there can be
cases of other

transitions requested by the application.

Please look at the below suggested device power states E.g.
transition between

DEVICE_PM_LOW_POWER_STATE to DEVICE_PM_OFF_STATE.

Moreover, the current device state cannot be queried by an
application or

a Power Manager service.

Below is the current Zephyr PM hooks:

struct device_pm_ops {

int (*suspend)(struct device *device, int pm_policy);

int (*resume)(struct device *device, int pm_policy);

};

Proposed changes

===============

First proposed change is to have a set state and get state driver
functions

instead of the suspend resume functions:

struct device_pm_ops {

int (*set_state)(struct device *device, int
device_pm_policy);

int (*get_state)(struct device *device, int
device_pm_policy);

};

The set_state function will behave according to the state
transition of a specific

driver. E.g. transition from active state to suspend state in a
UART device will

save device states and gate the clock.
The proposal, as I understand, is to use the pm hooks to actively
control the power states instead of using them as just notifications
of the SOC's power transitions. Considering this, we had one power
policy called "device_suspend_only". That is open to be broken down
into more device specific power states.

[HR] You are correct, we intend to use the pm driver hooks to
actively control the device Power states. We will use the Zephyer's
current power policies to indicate the system power state. As you
mentioned, when devices will not be in active state the system can still be at "device_suspend_only" state.
Do you see any issues with the apps/drivers keeping the PM service updated of the device's current state in real time? What about race conditions? Complexity of communication framework?
[HR] The need of communication framework and device state database
lock may be needed. For example, inter processor communication may be
needed if in a specific SoC there are shared power resources between
two cores (in AtP3 we may avoid that...)



The get_state function will enable the Power Manager service to
know the state

of each driver thus enable it to configure the SoC power behavior.
The set_state function looks ok. It is the same as the current
suspend but with the name change. The purpose of the name change is
to add a corresponding get_state. The RFC is not giving much
details of the use of the get_state function.

I assume there is a need for the PM service to build a device tree,
with power hierarchy. It would be helpful if you could explain how
this function fits in your larger design of the PM service's power
policy management of the devices.

[HR] I will give an example:
A user application decides to suspend the I2C and the SPI devices.
The application will then call the corresponding set_state functions of these devices.
The set_state functions will perform the store of the relevant
device state and gate the device clock. In the next idle time the _sys_soc_suspend will be called.
This will trigger the power manager service which will decide what
should be done to optimize the power (clock gate a branch or change the system power state.
The decision of the power manager service will be based on the
devices states which can be obtained also by using the get_state functions.

Since the PM service is expected to have communication established
with all components in the system, wouldn't it know what state each
device is set to? Querying each device and building a tree every
time there is an opportunity to suspend, may take some time causing delay in suspend.

[HR] You are correct, using the get_state function will lead to a
less optimal Power manager service and it will need to use a more optimized method.
However, it is a good practice to have this function as the
application may want to query the device state.

Second proposed change is to add the below device power states:

Note: Many devices do not have all four power states defined.

DEVICE_PM_ACTIVE_STATE

--------------------------------------------

Normal operation of the device. All device context is retained.

DEVICE_PM_LOW_POWER_STATE

-------------------------------------------------------

Device context is preserved by the HW and need not be restored by
the driver.

The device do not allow the Power Manager service to power it down.

DEVICE_PM_SUSPEND_STATE

------------------------------------------------

Most device context is lost by the hardware.

Device drivers must save and restore or reinitialize any context
lost

by the hardware.

The device can be powered down.

The device is allowing a wake signal to send them to active state.

DEVICE_PM_OFF_STATE

---------------------------------------

Power has been fully removed from the device. The device context is
lost

when this state is entered, so the OS software will reinitialize
the device

when powering it back on.

Device may not wake itself as the SoC need to reinitialize the device.
The description of the power states here sounds like they are
notifications. It sounds like some other component is setting the
power state and notifies using these values and the drivers do
save/restore or other operations based on the notification. Are the
drivers expected to gate clocks, turn off peripherals etc. in these notifications?

[HR] These device power states serve two purposes:
1. The drivers are expected to perform all the power/clock changes
It can perform according to the selected power state and do not
influence other drivers.
2. The power manager service will use the drivers states to decide
on system power policy to go to (it can also stay in
SYS_PM_DEVICE_SUSPEND_ONLY but to optimize the clock gating scheme)
Would these become part of a specification that all device drivers would need to implement? In this scheme, the PM responsibilities are shared between PM Service, various apps and drivers. So some plan needs to be in place to ensure all of them cooperate as expected.
[HR] You are right, there is a need to define the PM responsibilities of the PM service, drivers and apps. However, this RFC was written to add the ability to support more than two device states, define the available states and to enable transition between them.
We will be happy to contribute also to define the above.
The device PM states look ok to me. They are architecture independent and the drivers can map them to device specific operations.

I think this RFC should be part of other RFCs that define the bigger picture of how it is used. As I see it, the kind of device PM you propose can function independent of system idle. In my opinion, it would be good to define it independent of system power management. The 2 will coordinate, but should not be a requirement. That way, either infrastructure can be used independently by users. Also there would be implementations that would want to do all device PM in the PM service for various reasons.



The initial part of the RFC does mention the application can set the
power state of the device and that is what the proposed set_state
function also suggests.

Do they serve both purposes? May be an example of how the device's
power state is actively changed and who and when does it, with
respect to these notifications, would help.

[HR] Here is an example:
There are three peripherals in a certain SOC: UART, I2C and SPI.
Both I2C and SPI are fed from the same PLL and the UART from a second one.
At the beginning the three peripherals are at DEVICE_PM_ACTIVE_STATE.
The user application decides that the I2C and the SPI should go to suspend.
It then calls the set_state function of these devices with DEVICE_PM_SUSPEND_STATE.
When idle comes the PM service is called and see that it can close the SPI and I2C PLL.
However, it cannot move to SYS_PM_DEEP_SLEEP as the UART is still active.
Will the PM service also put devices to suspend state, or only the apps will do it? Looks like the PM Service will never enter Deep Sleep if any device is on - any exceptions?
[HR] Only apps will do that. The PM service can decide in some cases to go to deep sleep even if specific device is active (e.g. the device is located in the always on power domain). The decision to change power state is SoC specific.

In the above example, the system had to go to idle for the PLL to get turned off. If you had a central scheme to turn off clocks then the PLL could have been turned off when both i2c and spi got turned off. Just an observation.
[HR] There are indeed several ways to solve this and there will be a need to choose the best one for the specific SoC.

Comments/concerns welcome.

Thanks,

Hezi

-------------------------------------------------------------------
-
- A member of the Intel Corporation group of companies

This e-mail and any attachments may contain confidential material
for the sole use of the intended recipient(s). Any review or
distribution by others is strictly prohibited. If you are not the
intended recipient, please contact the sender and delete all copies.
--------------------------------------------------------------------
- A member of the Intel Corporation group of companies

This e-mail and any attachments may contain confidential material
for the sole use of the intended recipient(s). Any review or
distribution by others is strictly prohibited. If you are not the
intended recipient, please contact the sender and delete all copies.
---------------------------------------------------------------------
A member of the Intel Corporation group of companies

This e-mail and any attachments may contain confidential material for
the sole use of the intended recipient(s). Any review or distribution
by others is strictly prohibited. If you are not the intended
recipient, please contact the sender and delete all copies.
---------------------------------------------------------------------
A member of the Intel Corporation group of companies

This e-mail and any attachments may contain confidential material for
the sole use of the intended recipient(s). Any review or distribution
by others is strictly prohibited. If you are not the intended
recipient, please contact the sender and delete all copies.


Re: Porting to Cortex-M0+

Nashif, Anas
 

See https://gerrit.zephyrproject.org/r/4160 for the maintainers.

Anas

On 18/08/2016, 11:00, "Jon Medhurst (Tixy)" <tixy(a)linaro.org> wrote:

On Wed, 2016-08-17 at 14:13 -0400, Benjamin Walsh wrote:
> > > I also want to add an ARCH_ARMV6, V7 etc to handle architecture
> > > specific code. We still need the more specific CPU_CORTEX_M0PLUS,
> 3,
> > > 4, etc because each cpu has different features.
>
> > Sounds reasonable to me. (I'm new around here though, so don't count
> > that as anything other than a random opinion ;-)
>
> Sounds reasonable to me as well. I'd like to hear from the ARM
> maintainers to get their opinion too.

Which reminds me to ask... who _are_ the ARM maintainers and how do we
find out such things given that the MAINTAINERS file in the source tree
is somewhat deficient in coverage?

--
Tixy


Re: Porting to Cortex-M0+

Jon Medhurst (Tixy) <tixy@...>
 

On Wed, 2016-08-17 at 14:13 -0400, Benjamin Walsh wrote:
I also want to add an ARCH_ARMV6, V7 etc to handle architecture
specific code. We still need the more specific CPU_CORTEX_M0PLUS,
3,
4, etc because each cpu has different features.
Sounds reasonable to me. (I'm new around here though, so don't count
that as anything other than a random opinion ;-)
Sounds reasonable to me as well. I'd like to hear from the ARM
maintainers to get their opinion too.
Which reminds me to ask... who _are_ the ARM maintainers and how do we
find out such things given that the MAINTAINERS file in the source tree
is somewhat deficient in coverage?

--
Tixy


Re: QEMU networking: CONFIG_NET_TESTING breaks things, echo_server IPv6 address is "wrong"

Flavio Santes <flavio.santes@...>
 

Hello

Hello,

Taking a chance, I'd like to start with drawing attention to
https://jira.zephyrproject.org/browse/ZEP-687 "docs:
Subsystems/Networking section is almost empty". Zephyr networking
See also https://jira.zephyrproject.org/browse/ZEP-188

information currently is sparse, disperse, bits are out of date, and
there're omissions/inconsistencies. Just linking a wiki landing
page from the official docs and letting community fill in that wiki
would be a good first step.
Agree

Anyway, waiting for real hardware support, I decided to give QEMU
networking a try. After some moderate googling, I arrived at
https://gerrit.zephyrproject.org/r/gitweb?p=net-tools.git;a=summary and
https://wiki.zephyrproject.org/view/Networking-with-Qemu . The initial
outcome: nothing works.
There is support for real hardware, see:
https://gerrit.zephyrproject.org/r/gitweb?p=zephyr.git;a=blob;f=samples/net/dns_client/prj_galileo.conf

There is also a driver for enc28j60, see:
https://jira.zephyrproject.org/browse/ZEP-291
https://www.olimex.com/Products/Modules/Ethernet/ENC28J60-H/resources/ENC28J60-H.pdf

On a 3rd day of fiddling, with a following patch to echo_server it
finally worked:

--- a/samples/net/echo_server/prj_slip.conf
+++ b/samples/net/echo_server/prj_slip.conf
-CONFIG_NET_TESTING=y
+CONFIG_NET_TESTING=n
diff --git a/samples/net/echo_server/src/echo-server.c
b/samples/net/echo_server/src/echo-server.c
index deb0d98..9ceef46 100644
--- a/samples/net/echo_server/src/echo-server.c
+++ b/samples/net/echo_server/src/echo-server.c
-#define MY_IPADDR { { { 0x20, 0x01, 0x0d, 0xb8, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0x1 } }
}
+#define MY_IPADDR { { { 0x20, 0x01, 0x0d, 0xb8, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0x2 } }
}

Commentary: Both
https://gerrit.zephyrproject.org/r/gitweb?p=net-tools.git;a=blob;f=README...
and
https://gerrit.zephyrproject.org/r/gitweb?p=net-tools.git;a=blob;f=loop-s...
configure host's side of tun interface with address 2001:db8::1, but
that's also what echo-server uses, so no talk between them.

That's however a 2nd in row issue, because with CONFIG_NET_TESTING=y, an
application thread doesn't really receive any packets, apparently due to
app's address being configured as IN6ADDR_ANY_INIT (or something else,
few minutes of looking at this NET_TESTING thing isn't enough to say
what it's doing).

In the nearby thread, Rohit Grover reported issues with getting echo on
a real hardware, so I wonder if CONFIG_NET_TESTING=y may be involved
too.

That's the source code side of the issue, another is documentation.
Both net-tools/README and the wiki page above omit some details to get
a virtual network set up seamlessly.


So, I'm not sure what the exact issue is. I may imagine following
might happen:

1. There was a simple CONFIG_NET_TESTING, for things like echo_server.
2. Later, it was made into a separate module, but echo_server possibly
wasn't updated to play with the new module well.
3. net-tools and wiki page predate CONFIG_NET_TESTING altogether.

The obvious question is what to do in this situation. I'm personally
keen to update https://wiki.zephyrproject.org/view/Networking-with-Qemu
to describe a setup which actually works now (this is mostly doing
steps in the right order, but also building with CONFIG_NET_TESTING=n).


Thanks,
Paul

Linaro.org | Open source software for ARM SoCs
Follow Linaro: http://www.facebook.com/pages/Linaro
http://twitter.com/#!/linaroorg - http://www.linaro.org/linaro-blog
Regards,
Flavio


Re: Porting to Cortex-M0+

Benjamin Walsh <benjamin.walsh@...>
 

On Wed, Aug 17, 2016 at 02:36:07PM +0100, Jon Medhurst (Tixy) wrote:
On Wed, 2016-08-17 at 09:40 +0000, Euan Mutch wrote:
I am thinking either, CPU_HAS_BASEPRI or ARCH_HAS_BASEPRI.
No objection from me.

I also want to add an ARCH_ARMV6, V7 etc to handle architecture
specific code. We still need the more specific CPU_CORTEX_M0PLUS, 3,
4, etc because each cpu has different features.
Sounds reasonable to me. (I'm new around here though, so don't count
that as anything other than a random opinion ;-)
Sounds reasonable to me as well. I'd like to hear from the ARM
maintainers to get their opinion too.

My main thought was that boards/SoCs select a CPU type which then
selects the individual feature that CPU supports. That way, core kernel
changes are decoupled better from people's board/SoC definitions which
don't have to break when kernel changes are made.
Cheers,
Ben


Daily JIRA Digest

donotreply@...
 

NEW JIRA items within last 24 hours: 2
[ZEP-713] Implement preemptible regular IRQs on ARC
https://jira.zephyrproject.org/browse/ZEP-713

[ZEP-711] I2c: fails to write with mode fast plus
https://jira.zephyrproject.org/browse/ZEP-711


UPDATED JIRA items within last 24 hours: 5
[ZEP-318] Provide single point of notification for new data on multiple sockets.
https://jira.zephyrproject.org/browse/ZEP-318

[ZEP-547] [nble] Failed to start encryption after reconnection
https://jira.zephyrproject.org/browse/ZEP-547

[ZEP-518] SPI not working on Arduino101
https://jira.zephyrproject.org/browse/ZEP-518

[ZEP-218] [drivers/nble][PTS_TEST] Fix responding with the wrong error codes to the Prepare Write Request
https://jira.zephyrproject.org/browse/ZEP-218

[ZEP-221] [drivers/nble][PTS_TEST] Implement Execute Write Request handler
https://jira.zephyrproject.org/browse/ZEP-221


CLOSED JIRA items within last 24 hours: 13
[ZEP-291] (Fixed) Driver for the ENC28J60 ethernet device
https://jira.zephyrproject.org/browse/ZEP-291

[ZEP-541] (Fixed) Integrate QMSI releases to Zephyr
https://jira.zephyrproject.org/browse/ZEP-541

[ZEP-575] (Fixed) Ethernet/IPv4/UDP: ip_buf_appdatalen returns wrong values
https://jira.zephyrproject.org/browse/ZEP-575

[ZEP-621] (Fixed) samples/static_lib: fatal error: stdio.h: No such file or directory
https://jira.zephyrproject.org/browse/ZEP-621

[ZEP-536] (Fixed) Update SDK ARC GCC compiler with last toolchain release
https://jira.zephyrproject.org/browse/ZEP-536

[ZEP-474] (Fixed) ND: Neighbor cache is not getting cleared
https://jira.zephyrproject.org/browse/ZEP-474

[ZEP-581] (Fixed) test_sha256 fails on Nios II if CONFIG_DEBUG=y
https://jira.zephyrproject.org/browse/ZEP-581

[ZEP-370] (Fixed) Crash on Arduino101 if fiber is CPU hog
https://jira.zephyrproject.org/browse/ZEP-370

[ZEP-555] (Fixed) correct libgcc not getting linked for CONFIG_FLOAT=y on ARM
https://jira.zephyrproject.org/browse/ZEP-555

[ZEP-556] (Fixed) System hangs during I2C transfer
https://jira.zephyrproject.org/browse/ZEP-556

[ZEP-51] (Fixed) footprint benchmarks are not enabled on all arches
https://jira.zephyrproject.org/browse/ZEP-51

[ZEP-478] (Fixed) Linux setup docs missing step to install curses development package for Fedora
https://jira.zephyrproject.org/browse/ZEP-478

[ZEP-457] (Fixed) doc: contribute/doxygen/typedefs.rst: examples files are broken
https://jira.zephyrproject.org/browse/ZEP-457


RESOLVED JIRA items within last 24 hours: 7
[ZEP-327] (Fixed) Encryption Libraries needed for Thread support
https://jira.zephyrproject.org/browse/ZEP-327

[ZEP-49] (Fixed) x86: unify separate SysV and IAMCU code
https://jira.zephyrproject.org/browse/ZEP-49

[ZEP-88] (Fixed) SDK installation can wipe out your root dir on Mac
https://jira.zephyrproject.org/browse/ZEP-88

[ZEP-385] (Fixed) Ethernet+IP{v4|v6}+TCP client mode is not working
https://jira.zephyrproject.org/browse/ZEP-385

[ZEP-703] (Fixed) USB sample apps are broken after QMSI update
https://jira.zephyrproject.org/browse/ZEP-703

[ZEP-313] (Fixed) wrong logic when debugging ARC core on arduino 101
https://jira.zephyrproject.org/browse/ZEP-313

[ZEP-425] (Duplicate) SYS_LOG interface not documented
https://jira.zephyrproject.org/browse/ZEP-425


Daily Gerrit Digest

donotreply@...
 

NEW within last 24 hours:
- https://gerrit.zephyrproject.org/r/4127 : WDT: remote duplicated wdt clock enable code
- https://gerrit.zephyrproject.org/r/4136 : Bluetooth: Fix race condition between ecc_send and ecc_task.
- https://gerrit.zephyrproject.org/r/4135 : Revert "REVERTME exclude test_sha256 on Nios2"
- https://gerrit.zephyrproject.org/r/4123 : enc28j60: rx fiber's stack size is increased
- https://gerrit.zephyrproject.org/r/4124 : enc28j60: Correction to ECON1.RXEN bit location
- https://gerrit.zephyrproject.org/r/4134 : Bluetooth: L2CAP: Make bt_l2cap_br_fixed_chan_register global
- https://gerrit.zephyrproject.org/r/4133 : Bluetooth: L2CAP: Remove mask from struct bt_l2cap_fixed_chan
- https://gerrit.zephyrproject.org/r/4132 : Bluetooth: L2CAP: Use BIT macro for supported BR/EDR fixed channels
- https://gerrit.zephyrproject.org/r/4130 : drivers: spi: Fix typos in SPI port numbers
- https://gerrit.zephyrproject.org/r/4129 : Bluetooth: Include btusb sample to sanity check
- https://gerrit.zephyrproject.org/r/4128 : Bluetooth: Add documentation to HCI RAW interface
- https://gerrit.zephyrproject.org/r/4122 : net: remove duplicated include line for uip-ds6
- https://gerrit.zephyrproject.org/r/4119 : arc: fix management of IRQ priority levels
- https://gerrit.zephyrproject.org/r/4120 : test_ipm: disable on Quark SE ARC core

UPDATED within last 24 hours:
- https://gerrit.zephyrproject.org/r/4108 : sample: update usb_cdc case to avoid compile error
- https://gerrit.zephyrproject.org/r/3846 : arc: remove deprecated dynamic interrupt implementation
- https://gerrit.zephyrproject.org/r/4028 : Bluetooth: ATT: Make it safe to access the request list
- https://gerrit.zephyrproject.org/r/4076 : enc28j60: hardware errata #6 PKTIF is unreliable
- https://gerrit.zephyrproject.org/r/4106 : ipm_console: rate-limit to avoid losing messages
- https://gerrit.zephyrproject.org/r/4027 : Bluetooth: GATT: Add queuing support
- https://gerrit.zephyrproject.org/r/4055 : Bluetooth: SDP: Server implementation
- https://gerrit.zephyrproject.org/r/4112 : Bluetooth: L2CAP: Implement bt_l2cap_br_chan_send()
- https://gerrit.zephyrproject.org/r/4088 : Bluetooth: Controller: Initial impl. of a HCI controller-side interface
- https://gerrit.zephyrproject.org/r/4086 : Bluetooth: Controller: Hardware abstraction layer for nRF5x radio
- https://gerrit.zephyrproject.org/r/4090 : Bluetooth: Controller: Add driver that glues Link Layer with the BLE stack
- https://gerrit.zephyrproject.org/r/4089 : Bluetooth: Controller: A full, hardware-agnostic Link Layer implementation
- https://gerrit.zephyrproject.org/r/4091 : board: nrf52_pca10040: Include Controller by default in board nrf52_pca10040
- https://gerrit.zephyrproject.org/r/4087 : Bluetooth: Controller: Add a util folder with basic primitives
- https://gerrit.zephyrproject.org/r/4030 : AVDTP Module Changes
- https://gerrit.zephyrproject.org/r/4111 : usb: Add USB sample build test to sanity check
- https://gerrit.zephyrproject.org/r/3995 : Bluetooth: Export USB HCI controller using RAW HCI channel
- https://gerrit.zephyrproject.org/r/3994 : Bluetooth: Add RAW interface to Bluetooth
- https://gerrit.zephyrproject.org/r/4118 : RFC: tests: Add a generic testing framework
- https://gerrit.zephyrproject.org/r/4081 : fix doxygen error doc: Update Power Management device driver API 1. Have one function that can be used for all possible device PM purposes using a control code instead of the suspend resume functions. 2. Add the below device power states: Note: Many devic
- https://gerrit.zephyrproject.org/r/4078 : enc28j60: remove rx interruption handling
- https://gerrit.zephyrproject.org/r/4079 : enc28j60: allow simultaneous reception and transmission
- https://gerrit.zephyrproject.org/r/4077 : enc28j60: hardware errata #14 ERXRDPT register failure

MERGED within last 24 hours:
- https://gerrit.zephyrproject.org/r/4121 : fat_fs: zfs_diskio: use same typedefs in header
- https://gerrit.zephyrproject.org/r/4131 : Merge remote-tracking branch 'origin/master' into net
- https://gerrit.zephyrproject.org/r/4125 : Bluetooth: Fail on init if BR/EDR is enabled but not supported
- https://gerrit.zephyrproject.org/r/4126 : Merge master branch into bluetooth
- https://gerrit.zephyrproject.org/r/3668 : net: yaip: Make sure ethernet l2 sets src and dst addresses
- https://gerrit.zephyrproject.org/r/3703 : net: yaip: Make some IPv6 utility functions to use const addr
- https://gerrit.zephyrproject.org/r/3699 : net: Kconfig: Refactor Kconfig menus for better clarity
- https://gerrit.zephyrproject.org/r/3702 : net: yaip: Add TTL IPv4 option
- https://gerrit.zephyrproject.org/r/3701 : net: tests: Add unit tests for net_nbuf_copy()
- https://gerrit.zephyrproject.org/r/3727 : net: yaip: Moving header files to include/net/yaip
- https://gerrit.zephyrproject.org/r/3700 : net: yaip: Add net_nbuf_copy() utility function
- https://gerrit.zephyrproject.org/r/3726 : net: Refine Kconfig to put NET_BUF appart
- https://gerrit.zephyrproject.org/r/3637 : net: yaip: Add struct to store link layer address
- https://gerrit.zephyrproject.org/r/3691 : slip: Network stack needs to be up before sending data to it
- https://gerrit.zephyrproject.org/r/3636 : net: yaip: Print available DATA buffers during nbuf alloc
- https://gerrit.zephyrproject.org/r/3638 : net: yaip: Use const for static and pre-defined IPv6 addresses
- https://gerrit.zephyrproject.org/r/3721 : net: yaip: Refactor nbuf.h and nbuf.c
- https://gerrit.zephyrproject.org/r/3689 : net: yaip: Set multicast dst address in ethernet if missing
- https://gerrit.zephyrproject.org/r/3633 : net: yaip: Add comment explaining net_core's verdict values
- https://gerrit.zephyrproject.org/r/3716 : net: yaip: Refactored IPv6 DAD and ND activation
- https://gerrit.zephyrproject.org/r/3692 : net: yaip: Start the network stack after device drivers
- https://gerrit.zephyrproject.org/r/3695 : net: yaip: Initial IPv6 neighbor discovery support
- https://gerrit.zephyrproject.org/r/3698 : net: yaip: Make IPv6 ND optional
- https://gerrit.zephyrproject.org/r/3696 : net: yaip: Initial router solicitation support
- https://gerrit.zephyrproject.org/r/3694 : slip: Setup fragments properly if MTU is bigger than frag size
- https://gerrit.zephyrproject.org/r/3697 : net: yaip: Initial router advertisement support
- https://gerrit.zephyrproject.org/r/3693 : slip: Do not try to unref a null pointer
- https://gerrit.zephyrproject.org/r/3712 : net: yaip: Utility function to compact net_buf fragments
- https://gerrit.zephyrproject.org/r/3679 : net: yaip: IPv4 protocol type was not set to sent ARP packet
- https://gerrit.zephyrproject.org/r/3634 : net: yaip: Moved ARP helper macro to arp.h
- https://gerrit.zephyrproject.org/r/3710 : net: tests: Unit tests for UDP handler
- https://gerrit.zephyrproject.org/r/3685 : net: yaip: Refactored ARP packet header handling
- https://gerrit.zephyrproject.org/r/3683 : net: yaip: Ethernet L2 TX side needs to setup fragments
- https://gerrit.zephyrproject.org/r/3708 : net: yaip: Initial UDP support
- https://gerrit.zephyrproject.org/r/3684 : net: yaip: Add more checks when allocating nbuf
- https://gerrit.zephyrproject.org/r/3707 : net: yaip: Generic connection handler for UDP and TCP
- https://gerrit.zephyrproject.org/r/3632 : net: yaip: Save some bytes on net_if logic
- https://gerrit.zephyrproject.org/r/3705 : net: yaip: Add support for ICMPv6 error message
- https://gerrit.zephyrproject.org/r/3688 : net: yaip: Add a utility to hexdump all fragments
- https://gerrit.zephyrproject.org/r/3631 : net: yaip: Add NET_ASSERT() macro
- https://gerrit.zephyrproject.org/r/3690 : net: yaip: Remove extra debug print in ethernet L2 driver
- https://gerrit.zephyrproject.org/r/3687 : net: yaip: Pointer to a ethernet header was incorrectly set
- https://gerrit.zephyrproject.org/r/3686 : net: yaip: ARP unit test needs to be run from fiber
- https://gerrit.zephyrproject.org/r/3682 : net: yaip: Add more debug print in ethernet RX side
- https://gerrit.zephyrproject.org/r/3680 : net: yaip: Reserve eth ll header len in L2 ethernet driver
- https://gerrit.zephyrproject.org/r/3676 : net: yaip: Add utility func to return eth broadcast addr
- https://gerrit.zephyrproject.org/r/3678 : net: yaip: Add more debugging to arp.c
- https://gerrit.zephyrproject.org/r/3681 : net: yaip: Add debug checks when sending data in TX fiber
- https://gerrit.zephyrproject.org/r/3677 : net: yaip: Both TX and RX fibers allow other fibers to run
- https://gerrit.zephyrproject.org/r/3675 : net: yaip: Add debug support to ethernet L2 driver
- https://gerrit.zephyrproject.org/r/3671 : net: yaip: Add link layer reserve information to l2 driver
- https://gerrit.zephyrproject.org/r/3673 : net: yaip: ARP reply did not set the address family
- https://gerrit.zephyrproject.org/r/3657 : net: yaip: Changed the IP and ll address debug prints
- https://gerrit.zephyrproject.org/r/3658 : net: tests: Fix unit test for IP addresses
- https://gerrit.zephyrproject.org/r/3674 : net: yaip: Calling net_buf_put() instead of nano_fifo_put()
- https://gerrit.zephyrproject.org/r/3655 : net: yaip: Fix arp.h so that net_arp_init() is found
- https://gerrit.zephyrproject.org/r/3663 : net: yaip: Re-send ARP when needed
- https://gerrit.zephyrproject.org/r/3669 : net: yaip: Write ethernet header in pdu when using slip and tap
- https://gerrit.zephyrproject.org/r/3661 : net: yaip: Change how the L2 header space is reserved in net_buf
- https://gerrit.zephyrproject.org/r/3653 : net: yaip: Print statistics using SYS_LOG
- https://gerrit.zephyrproject.org/r/3652 : net: yaip: Network stack analyzer uses now the SYS_LOG sub-system
- https://gerrit.zephyrproject.org/r/3654 : net: yaip: Depending on debug flags the stdio.h is not included
- https://gerrit.zephyrproject.org/r/3659 : net: tests: Fix unit test for IP utils
- https://gerrit.zephyrproject.org/r/3662 : net: yaip: Add utility to remove ipv4 address from iface
- https://gerrit.zephyrproject.org/r/3660 : net: yaip: Make sure that either IPv4 or IPv6 gets selected
- https://gerrit.zephyrproject.org/r/3651 : net: yaip: Do not overwrite SYS_LOG_DOMAIN
- https://gerrit.zephyrproject.org/r/3656 : net: tests: Fix unit test for ARP
- https://gerrit.zephyrproject.org/r/3650 : net: yaip: The NET_DEBUG must not be set in header file
- https://gerrit.zephyrproject.org/r/3645 : net: yaip: No need to do ARP for IPv6 network packet
- https://gerrit.zephyrproject.org/r/3644 : net: yaip: The IP protocol type needs to be set in L2 layer
- https://gerrit.zephyrproject.org/r/3649 : net: yaip: Use debugging net_buf unref function
- https://gerrit.zephyrproject.org/r/3647 : net: yaip: Refactor various network init functions
- https://gerrit.zephyrproject.org/r/3608 : net: yaip: Use net_nbuf_ll() to get into arp header
- https://gerrit.zephyrproject.org/r/3640 : net: yaip: Add IPv6 utils for address manipulation
- https://gerrit.zephyrproject.org/r/3646 : net: yaip: Buffer leak if net_if_send_data() returns NET_DROP
- https://gerrit.zephyrproject.org/r/3642 : net: yaip: Add a neighbor cache needed in IPv6
- https://gerrit.zephyrproject.org/r/3639 : net: yaip: Changing IPv4 address compare to a function
- https://gerrit.zephyrproject.org/r/3641 : net: yaip: Add IPv6 address network interface utils
- https://gerrit.zephyrproject.org/r/3643 : net: tests: Add unit tests for neighbor cache handling
- https://gerrit.zephyrproject.org/r/3626 : net: yaip: Make net_core.h include the least amount of necessary header
- https://gerrit.zephyrproject.org/r/3627 : net: yaip: Add an L2 layer
- https://gerrit.zephyrproject.org/r/3635 : net: yaip: Make sure that RX is started before TX
- https://gerrit.zephyrproject.org/r/3622 : net: yaip: The core initialize ARP layer relevantly
- https://gerrit.zephyrproject.org/r/3624 : slip: Fix compiler warnings
- https://gerrit.zephyrproject.org/r/3625 : net: yaip: Add a helper to queue a buffer in a net_if instance
- https://gerrit.zephyrproject.org/r/3623 : net: yaip: Shorten IPv4/6 config options
- https://gerrit.zephyrproject.org/r/3617 : net: yaip: Add UDP header definition
- https://gerrit.zephyrproject.org/r/3628 : net: yaip: Re-factor Kconfig and move ARP to a better location
- https://gerrit.zephyrproject.org/r/3629 : net: yaip: Removing capabilities from net_if api
- https://gerrit.zephyrproject.org/r/4107 : ipm_console_receiver: correctly populate driver data
- https://gerrit.zephyrproject.org/r/3630 : net: yaip: Tiny comment fix
- https://gerrit.zephyrproject.org/r/3621 : net: debug: Indent properly some config options.
- https://gerrit.zephyrproject.org/r/3619 : net: yaip: Use generic wrapper for semaphore give operation
- https://gerrit.zephyrproject.org/r/3614 : net: yaip: Handle ARP messages
- https://gerrit.zephyrproject.org/r/3616 : net: yaip: Fix trivial comment errors in header files
- https://gerrit.zephyrproject.org/r/3620 : net: yaip: Include toolchain related header for aliases
- https://gerrit.zephyrproject.org/r/3618 : net: yaip: Use shorter alias for __packed attribute
- https://gerrit.zephyrproject.org/r/3615 : net: yaip: Setting static IP addresses for echo-server
- https://gerrit.zephyrproject.org/r/3588 : net: yaip: Add ICMPv6 handler
- https://gerrit.zephyrproject.org/r/3586 : net: yaip: Add debugging option for network utilities
- https://gerrit.zephyrproject.org/r/3589 : net: yaip: Add unit tests for ICMPv6 handler
- https://gerrit.zephyrproject.org/r/3613 : net: tests: Additional tests for ICMPv4 checksum verification
- https://gerrit.zephyrproject.org/r/3590 : net: yaip: Process received ICMPv6 messages
- https://gerrit.zephyrproject.org/r/3585 : net: yaip: Add IP packet checksum calculation utilities
- https://gerrit.zephyrproject.org/r/4049 : drivers: cc2520: Raise Rx stack size
- https://gerrit.zephyrproject.org/r/4048 : samples: Build ieee802154 sample with 6lo support
- https://gerrit.zephyrproject.org/r/4047 : net: yaip: Add packet display in ieee802154 l2 stack
- https://gerrit.zephyrproject.org/r/4046 : net: yaip: Integrate 6lo compression support in IEEE 802.15.4 L2 stack
- https://gerrit.zephyrproject.org/r/4045 : net: yaip: ieee802154: Handle plain/compressed ll addr
- https://gerrit.zephyrproject.org/r/4044 : net: yaip: Add more debugging messages to 6lo
- https://gerrit.zephyrproject.org/r/4043 : net: yaip: 6lo: Grab uncompressed header type relevantly
- https://gerrit.zephyrproject.org/r/4042 : net: yaip: 6lo uncompression should continue to proceed after src addr
- https://gerrit.zephyrproject.org/r/4041 : net: yaip: Add debug print on IPv6 preliminary check
- https://gerrit.zephyrproject.org/r/4040 : net: yaip: Add debug messages when dropping packets
- https://gerrit.zephyrproject.org/r/4039 : net: yaip: Handle ll part in 6lo logic when relevant
- https://gerrit.zephyrproject.org/r/4038 : net: yaip: Built IEEE 802.15.4 fragmentation logic if requested
- https://gerrit.zephyrproject.org/r/4037 : net: yaip: Follow file naming in ieee802154 l2 stack
- https://gerrit.zephyrproject.org/r/4036 : net: yaip: Giving uncompressed buffer to 6lo is not an error
- https://gerrit.zephyrproject.org/r/4035 : samples: ieee802154: Debugging needs new Kconfig option
- https://gerrit.zephyrproject.org/r/4034 : net: yaip: ieee802154: Logging header should be loaded first
- https://gerrit.zephyrproject.org/r/4033 : net: yaip: SYS_INIT() routines are never ran twice
- https://gerrit.zephyrproject.org/r/4023 : net: tests: Test Trickle algorithm
- https://gerrit.zephyrproject.org/r/4022 : net: yaip: Trickle algorithm implementation
- https://gerrit.zephyrproject.org/r/3839 : net: yaip: Change NET6LO_ defines to NET_6LO
- https://gerrit.zephyrproject.org/r/3838 : net: tests: Add fragmentation unit tests for 802.15.4
- https://gerrit.zephyrproject.org/r/3837 : net: yaip: Add support for IEEE 802.15.4 re-assembly
- https://gerrit.zephyrproject.org/r/3836 : net: yaip: Integrate 6lo and 802.15.4 fragmentation
- https://gerrit.zephyrproject.org/r/3835 : net: yaip: Add support for IEEE 802.15.4 fragmentation
- https://gerrit.zephyrproject.org/r/3834 : net: tests: Add unit tests for 6lo IPv6 dispatch
- https://gerrit.zephyrproject.org/r/3833 : net: yaip: Fix wrong UDP length calc in 6lo compression
- https://gerrit.zephyrproject.org/r/3832 : net: yaip: Add 6lowpan without compression header support
- https://gerrit.zephyrproject.org/r/3831 : net: yaip: Change 6lo API returned parameter
- https://gerrit.zephyrproject.org/r/3587 : net: tests: Unit tests for network utilities
- https://gerrit.zephyrproject.org/r/3830 : net: tests: Fix 6lo tests
- https://gerrit.zephyrproject.org/r/3829 : net: yaip: Fix typo and alignment in 6lo
- https://gerrit.zephyrproject.org/r/3828 : net: yaip: Do not access IPv6 neighbor cache directly
- https://gerrit.zephyrproject.org/r/3827 : net: yaip: Neighbor cache table was incorrectly accessed
- https://gerrit.zephyrproject.org/r/3826 : net: yaip: Add support for IPv6 prefix lifetime
- https://gerrit.zephyrproject.org/r/3825 : net: yaip: Use target address in IPv6 NS to lookup neighbor
- https://gerrit.zephyrproject.org/r/3824 : net: yaip: Send available pending data after receiving IPv6 NA
- https://gerrit.zephyrproject.org/r/3823 : net: yaip: Add IPv6 ND reachability support
- https://gerrit.zephyrproject.org/r/3822 : net: yaip: Add neighbor free function to IPv6 cache
- https://gerrit.zephyrproject.org/r/3821 : net: yaip: Add network iface to neighbor creation call
- https://gerrit.zephyrproject.org/r/3820 : net: yaip: Add more debugging prints in IPv6 ND handling
- https://gerrit.zephyrproject.org/r/3819 : net: yaip: Add debug helper for neigh tables
- https://gerrit.zephyrproject.org/r/3584 : net: yaip: Add net_hexdump() utility to print network data
- https://gerrit.zephyrproject.org/r/3612 : net: yaip: ICMPv4 checksum calculation fixed
- https://gerrit.zephyrproject.org/r/3611 : net: yaip: IP checksum calculation should ignore ll header
- https://gerrit.zephyrproject.org/r/3610 : net: yaip: Clarified the debug print about packet length
- https://gerrit.zephyrproject.org/r/3605 : net: yaip: Setting preferred status to manually added IPv4 address
- https://gerrit.zephyrproject.org/r/3607 : net: yaip: Make echo-server to use documentation IPv4 addresses
- https://gerrit.zephyrproject.org/r/3818 : net: yaip: Set initial neighbor value when IPv6 NS is received
- https://gerrit.zephyrproject.org/r/3817 : net: yaip: IPv6 ND fixes
- https://gerrit.zephyrproject.org/r/3816 : net: yaip: Timeout a pending NS
- https://gerrit.zephyrproject.org/r/3814 : net: yaip: Utility helper to access IPv6 ND cache data
- https://gerrit.zephyrproject.org/r/3813 : net: yaip: Print buffer usage after receiving or sending data
- https://gerrit.zephyrproject.org/r/3812 : net: yaip: Fix compilation warning
- https://gerrit.zephyrproject.org/r/3606 : net: yaip: Only accept ARP reply if we requested data
- https://gerrit.zephyrproject.org/r/3811 : net: yaip: Ethernet mac address length was incorrectly set
- https://gerrit.zephyrproject.org/r/3810 : net: yaip: Discard ethernet frame if it is not for us
- https://gerrit.zephyrproject.org/r/3809 : net: yaip: Add ll address checker function
- https://gerrit.zephyrproject.org/r/3808 : net: yaip: Fix compilation if IPv4 is disabled
- https://gerrit.zephyrproject.org/r/3807 : net: yaip: Fix the debug prints in echo-server
- https://gerrit.zephyrproject.org/r/3806 : net: yaip: Sample code to play with ieee 802.15.4 stack
- https://gerrit.zephyrproject.org/r/3805 : boards: quark_se_devboard: Build cc2520 if YAIP IEEE 802.15.4 is in
- https://gerrit.zephyrproject.org/r/3804 : drivers: cc2520: Add a new IP stack ready adaptation of CC2520 driver
- https://gerrit.zephyrproject.org/r/3803 : drivers: cc2520: Make current driver for legacy stack only
- https://gerrit.zephyrproject.org/r/3802 : tests: net: Add a IEEE 802.15.4 ACK replies test
- https://gerrit.zephyrproject.org/r/3604 : slip: Support TAP functionality
- https://gerrit.zephyrproject.org/r/3801 : net: yaip: ieee802154: Support ACK replies
- https://gerrit.zephyrproject.org/r/3800 : tests: yaip: Add grounds for IEEE 802.15.4 stack tests.
- https://gerrit.zephyrproject.org/r/3799 : net: yaip: Add support for the IEEE 802.15.4 ORFD
- https://gerrit.zephyrproject.org/r/3798 : net: yaip: Adding ALOHA radio protocol to IEEE 802.15.4 L2 driver
- https://gerrit.zephyrproject.org/r/3797 : net: yaip: Add preliminary IEEE 802.15.4 L2 driver
- https://gerrit.zephyrproject.org/r/3796 : net: yaip: Add new IEEE 802.15.4 Radio API for device drivers
- https://gerrit.zephyrproject.org/r/3795 : net: yaip: L2 might need private data per-interface
- https://gerrit.zephyrproject.org/r/3794 : net: yaip: Fix TX fiber on net_if
- https://gerrit.zephyrproject.org/r/3793 : net: yaip: Add a function to lookup for an iface from a device
- https://gerrit.zephyrproject.org/r/3792 : net: yaip: Add some debug message on net_if
- https://gerrit.zephyrproject.org/r/3791 : net: yaip: Add documentation to net_l2 header file
- https://gerrit.zephyrproject.org/r/3790 : net: yaip: l2 layer reserve size might need extra parameter
- https://gerrit.zephyrproject.org/r/3787 : net: yaip: Sent NS was two bytes too long
- https://gerrit.zephyrproject.org/r/3786 : net: yaip: Check ICMPv6 options length correctly
- https://gerrit.zephyrproject.org/r/3785 : net: yaip: Change srctree to ZEPHYR_BASE in Makefiles
- https://gerrit.zephyrproject.org/r/3784 : net: yaip: Add a function to retrieve a neigh from an IPv6 address
- https://gerrit.zephyrproject.org/r/3783 : net: yaip: Fix IPv6 NS packet size check
- https://gerrit.zephyrproject.org/r/3782 : net: yaip: Add IPv6 ND statistics when relevant
- https://gerrit.zephyrproject.org/r/3781 : net: yaip: RX fiber needs bigger stack
- https://gerrit.zephyrproject.org/r/3780 : net: yaip: Return NET_CONTINUE in L2 ethernet driver in send()
- https://gerrit.zephyrproject.org/r/3779 : net: yaip: Ethernet driver needs to set ll address
- https://gerrit.zephyrproject.org/r/3609 : net: tests: Fixed the ARP test
- https://gerrit.zephyrproject.org/r/3778 : net: yaip: IPv6 neighbor was not properly added to cache
- https://gerrit.zephyrproject.org/r/3777 : net: yaip: No need to swap ll address in IPv6 module
- https://gerrit.zephyrproject.org/r/3776 : net: yaip: Update UDP sent packet statistics
- https://gerrit.zephyrproject.org/r/3775 : net: yaip: nbuf variables needs clearing when allocating nbuf
- https://gerrit.zephyrproject.org/r/3774 : net: yaip: Check packet sending status correctly in arp.c
- https://gerrit.zephyrproject.org/r/3773 : net: yaip: Call net_context send callback when packet is sent
- https://gerrit.zephyrproject.org/r/3772 : net: yaip: Call send callback in net_context properly
- https://gerrit.zephyrproject.org/r/3771 : net: yaip: Add token to nbuf
- https://gerrit.zephyrproject.org/r/3770 : net: yaip: Check IPv6 NS, NA and RA messages for corruption
- https://gerrit.zephyrproject.org/r/3769 : net: yaip: Rename ip_protocol to net_ip_protocol
- https://gerrit.zephyrproject.org/r/3768 : net: apps: Fix echo-server to use the new user API
- https://gerrit.zephyrproject.org/r/3767 : net: yaip: Set reserve, context and iface properly in nbuf
- https://gerrit.zephyrproject.org/r/3766 : net: yaip: Add more debugging to nbuf
- https://gerrit.zephyrproject.org/r/3765 : net: yaip: Use proper ll header length when sending IPv6 NS
- https://gerrit.zephyrproject.org/r/3764 : net: yaip: Resolve LL address for IPv6 packet in ethernet L2 driver
- https://gerrit.zephyrproject.org/r/3763 : net: yaip: Do IPv6 ND if LL address is not known when sending
- https://gerrit.zephyrproject.org/r/3762 : net: yaip: Neighbor cache entry was not properly init
- https://gerrit.zephyrproject.org/r/3761 : net: yaip: Fix debug prints in net conn manager
- https://gerrit.zephyrproject.org/r/3760 : slip: Do not send ethernet header if MTU is large enough
- https://gerrit.zephyrproject.org/r/3759 : net: yaip: Set the protocol family and interface for net_buf
- https://gerrit.zephyrproject.org/r/3758 : net: tests: Unit tests for user space socket API
- https://gerrit.zephyrproject.org/r/3757 : net: yaip: Create IPv4, IPv6 and UDP packets when needed
- https://gerrit.zephyrproject.org/r/3756 : net: yaip: Utility function to append UDP packet into net_buf
- https://gerrit.zephyrproject.org/r/3755 : net: yaip: Add helper to create IPv4 packet
- https://gerrit.zephyrproject.org/r/3754 : net: yaip: Add helper to create IPv6 packet
- https://gerrit.zephyrproject.org/r/3753 : net: yaip: Add user space API to net_context
- https://gerrit.zephyrproject.org/r/3752 : net: yaip: Increasing the default IPv6 unicast addr count
- https://gerrit.zephyrproject.org/r/3751 : net: yaip: Add net_conn pointer to callback
- https://gerrit.zephyrproject.org/r/3750 : net: yaip: Convert network connection to use sockaddr
- https://gerrit.zephyrproject.org/r/3749 : net: yaip: Add helpers for getting protocol specific sockaddr
- https://gerrit.zephyrproject.org/r/3748 : net: yaip: Add sockaddr struct
- https://gerrit.zephyrproject.org/r/3747 : net: yaip: UDP checksum calculator
- https://gerrit.zephyrproject.org/r/3746 : net: yaip: Swap ll addresses when handling ICMPv6 Echo-Request
- https://gerrit.zephyrproject.org/r/3745 : net: yaip: net_hexdump_frags() is only available when debugging
- https://gerrit.zephyrproject.org/r/3744 : net: tests: UDP unit test had incorrect ll address length
- https://gerrit.zephyrproject.org/r/3743 : net: yaip: Making IP address const in utility func
- https://gerrit.zephyrproject.org/r/3742 : net: yaip: Address family needs to be set for multicast address
- https://gerrit.zephyrproject.org/r/3741 : net: tests: udp: Print debug info only when activated
- https://gerrit.zephyrproject.org/r/3601 : net: tests: Add tests for IPv4 netmask, gateway and subnet compare
- https://gerrit.zephyrproject.org/r/3603 : net: tests: Unit tests for the IPv4 ARP code
- https://gerrit.zephyrproject.org/r/3740 : net: yaip: Utility to get net_if according to index value
- https://gerrit.zephyrproject.org/r/3739 : net: yaip: IP address lookup functions return interface
- https://gerrit.zephyrproject.org/r/3738 : net: yaip: Do not include anything from net/ip directory
- https://gerrit.zephyrproject.org/r/3737 : net: yaip: Fix dedicated IPv4 function for net_if
- https://gerrit.zephyrproject.org/r/3736 : net: yaip: Simplify IPV<4/6> config management in net_if
- https://gerrit.zephyrproject.org/r/3735 : net: tests: Add unit tests for 6lowpan functionality
- https://gerrit.zephyrproject.org/r/3734 : net: yaip: Add initial 6lowpan IPHC compression support.
- https://gerrit.zephyrproject.org/r/3733 : net: yaip: Add utility to verify given addr based on ll
- https://gerrit.zephyrproject.org/r/3732 : net: yaip: Add support for 802.15.4 short address for iid creation
- https://gerrit.zephyrproject.org/r/3731 : net: yaip: Clear ipv6 addr parameter on create iid
- https://gerrit.zephyrproject.org/r/3730 : net: yaip: Fix net_ip.h documentation
- https://gerrit.zephyrproject.org/r/3729 : net: yaip: Cleanup net_if's documentation
- https://gerrit.zephyrproject.org/r/3728 : net: yaip: Let's use inline function for type checking for net_nbuf
- https://gerrit.zephyrproject.org/r/3725 : samples: Fix echo_server for YAIP
- https://gerrit.zephyrproject.org/r/3724 : sanitycheck: Recognize YAIP specific sections
- https://gerrit.zephyrproject.org/r/3722 : net: yaip: Debugging function to print fragment chain information
- https://gerrit.zephyrproject.org/r/3720 : net: tests: Fix project file for IP address tests
- https://gerrit.zephyrproject.org/r/3719 : net: tests: Fix IP address test so that it will not crash
- https://gerrit.zephyrproject.org/r/3718 : net: tests: ICMPv6 was missing random number config
- https://gerrit.zephyrproject.org/r/3717 : net: yaip: Fix compilation when IPv6 is disabled
- https://gerrit.zephyrproject.org/r/3715 : net: tests: Turning off IPv6 for ARP tests
- https://gerrit.zephyrproject.org/r/3714 : net: tests: Unit tests for net_nbuf_push()
- https://gerrit.zephyrproject.org/r/3600 : net: yaip: Add capabilities flag to net_if API
- https://gerrit.zephyrproject.org/r/3599 : net: yaip: Add util to check if IPv4 address is part of a subnet
- https://gerrit.zephyrproject.org/r/3713 : net: yaip: Utility that inserts free space to the fragment list
- https://gerrit.zephyrproject.org/r/3711 : net: tests: Fix ARP test so that it will not crash
- https://gerrit.zephyrproject.org/r/3709 : net: yaip: Catch UDP network traffic
- https://gerrit.zephyrproject.org/r/3602 : net: yaip: Added IPv4 ARP support
- https://gerrit.zephyrproject.org/r/3706 : net: yaip: Add support for ICMPv4 error message
- https://gerrit.zephyrproject.org/r/3704 : net: yaip: Add IPv6 minimum MTU value
- https://gerrit.zephyrproject.org/r/3598 : net: yaip: Add utils to set IPv4 netmask and gateway to net_if
- https://gerrit.zephyrproject.org/r/3672 : net: yaip: Initializing the ll src and dst addresses
- https://gerrit.zephyrproject.org/r/3670 : slip: Fix the debug print
- https://gerrit.zephyrproject.org/r/3667 : net: yaip: Set IP protocol type when sending ethernet packet
- https://gerrit.zephyrproject.org/r/3666 : net: yaip: Set the ll src and dst addresses in ethernet l2 driver
- https://gerrit.zephyrproject.org/r/3665 : net: yaip: Set the l2 src/dst addresses in nbuf
- https://gerrit.zephyrproject.org/r/3664 : net: yaip: Add ethernet address helpers
- https://gerrit.zephyrproject.org/r/3648 : net: yaip: Process ICMPv6 packets only if IPv6 is enabled
- https://gerrit.zephyrproject.org/r/3597 : net: yaip: Add macro to compare two IPv4 addresses
- https://gerrit.zephyrproject.org/r/3596 : net: yaip: net_ipaddr_copy() macro was too fragile
- https://gerrit.zephyrproject.org/r/3595 : net: yaip: Add utility function returning IPv4 broadcast address
- https://gerrit.zephyrproject.org/r/3594 : net: yaip: Do not remove fragments if main buffer is not removed
- https://gerrit.zephyrproject.org/r/3593 : net: tests: Tweak the IP address test to use new net_if API
- https://gerrit.zephyrproject.org/r/3592 : net: yaip: Add utility function to return default network interface
- https://gerrit.zephyrproject.org/r/3591 : net: yaip: Process received ICMPv4 messages
- https://gerrit.zephyrproject.org/r/3577 : net: yaip: Added API documentation to IP address check functions
- https://gerrit.zephyrproject.org/r/3576 : net: yaip: Receive IPv4 packet
- https://gerrit.zephyrproject.org/r/3583 : net: yaip: Network interface needs own TX fiber stack
- https://gerrit.zephyrproject.org/r/3566 : net: yaip: Drop received source mcast IPv6 packets
- https://gerrit.zephyrproject.org/r/3575 : net: yaip: Network interface code compiles ok for IPv4 and IPv6
- https://gerrit.zephyrproject.org/r/3572 : net: tests: Add IPv4 address unit tests
- https://gerrit.zephyrproject.org/r/3542 : net: yaip: Add TX fifo to network interface
- https://gerrit.zephyrproject.org/r/3534 : net: yaip: Add ntohl() and related macros
- https://gerrit.zephyrproject.org/r/3536 : net: yaip: Compile new stack if enabled
- https://gerrit.zephyrproject.org/r/3582 : net: yaip: Add net_send_data() that sends data to network
- https://gerrit.zephyrproject.org/r/3581 : net: yaip: Renamed network data receive function
- https://gerrit.zephyrproject.org/r/3580 : net: yaip: Network interface sets default IPv6 hop limit
- https://gerrit.zephyrproject.org/r/3579 : net: yaip: Move IP address print funcs to separate file
- https://gerrit.zephyrproject.org/r/3578 : net: yaip: Add ICMP protocol header struct
- https://gerrit.zephyrproject.org/r/3574 : net: tests: Add more IPv6 address getters unit tests
- https://gerrit.zephyrproject.org/r/3573 : net: yaip: IPv6 address utility funcs for network interface
- https://gerrit.zephyrproject.org/r/3571 : net: yaip: Add IPv4 addresses to network interface
- https://gerrit.zephyrproject.org/r/3570 : net: tests: Add IPv6 address manipulation unit tests
- https://gerrit.zephyrproject.org/r/3569 : net: yaip: Utilities to set and lookup interface IPv6 addresses
- https://gerrit.zephyrproject.org/r/3568 : net: yaip: Add utility functions to check IPv6 addresses
- https://gerrit.zephyrproject.org/r/3567 : net: yaip: Add utility func to return IP address type as a string
- https://gerrit.zephyrproject.org/r/3565 : net: yaip: Receive IPv6 packet
- https://gerrit.zephyrproject.org/r/4054 : Bluetooth: SMP: Add self test for H6 function
- https://gerrit.zephyrproject.org/r/3564 : net: tests: Add unit test for IP and MAC address printing
- https://gerrit.zephyrproject.org/r/3563 : net: yaip: Add debug function to print IP address
- https://gerrit.zephyrproject.org/r/3562 : net: yaip: Add debug function to print MAC address
- https://gerrit.zephyrproject.org/r/3561 : net: yaip: Add statistics gathering support
- https://gerrit.zephyrproject.org/r/3560 : net: yaip: Add net_context to compilation
- https://gerrit.zephyrproject.org/r/3559 : net: yaip: Start to receive network packets
- https://gerrit.zephyrproject.org/r/3558 : net: tests: Temporarily remove nbuf unit test
- https://gerrit.zephyrproject.org/r/3557 : net: yaip: Enable compilation of net_if.c
- https://gerrit.zephyrproject.org/r/3556 : net: yaip: Refactor debug printing in net_if
- https://gerrit.zephyrproject.org/r/3555 : net: yaip: Start to use logging macros from sys_log.h
- https://gerrit.zephyrproject.org/r/3554 : net: yaip: Add send() to net_if API
- https://gerrit.zephyrproject.org/r/3553 : net: yaip: Add Kconfig option for compiling IPv4 support
- https://gerrit.zephyrproject.org/r/3552 : net: yaip: Add net_if_get_by_link_addr() util function
- https://gerrit.zephyrproject.org/r/3551 : net: yaip: Execute net_init() automatically
- https://gerrit.zephyrproject.org/r/3550 : net: yaip: Add Kconfig option for compiling IPv6 support
- https://gerrit.zephyrproject.org/r/3549 : net: yaip: Add net_analyze_stack() macro
- https://gerrit.zephyrproject.org/r/3548 : net: yaip: Fix compilation error in net_if.h
- https://gerrit.zephyrproject.org/r/3547 : slip: Add driver for host to qemu connectivity
- https://gerrit.zephyrproject.org/r/3546 : net: yaip: Add nbuf buffer API
- https://gerrit.zephyrproject.org/r/3545 : net: yaip: Compile IPv6 and IPv4 address conditionally
- https://gerrit.zephyrproject.org/r/3544 : net: yaip: Add function that feeds data to RX fifo
- https://gerrit.zephyrproject.org/r/3543 : net: yaip: Refactored RX fiber init
- https://gerrit.zephyrproject.org/r/3541 : net: yaip: Add IPv6 prefixes to network interface
- https://gerrit.zephyrproject.org/r/3540 : net: yaip: Add multicast address to network interface
- https://gerrit.zephyrproject.org/r/3539 : net: yaip: Add network address information to interface
- https://gerrit.zephyrproject.org/r/3538 : net: yaip: apps: Create a skeleton echo-server for new IP stack
- https://gerrit.zephyrproject.org/r/3537 : net: Add generic network interface header
- https://gerrit.zephyrproject.org/r/3535 : net: yaip: Use same prefix in new IP stack Kconfig
- https://gerrit.zephyrproject.org/r/3533 : net: yaip: Add defines for various IP protocol header lengths
- https://gerrit.zephyrproject.org/r/3532 : net: yaip: Initial commit for the new IP stack
- https://gerrit.zephyrproject.org/r/4053 : Bluetooth: SMP: Add support for Link Key derivation
- https://gerrit.zephyrproject.org/r/4092 : Bluetooth: eddystone: Add timeout to deactivate configuration mode
- https://gerrit.zephyrproject.org/r/4052 : Bluetooth: SMP: Refactor keys distribution bitfields
- https://gerrit.zephyrproject.org/r/4117 : Bluetooth: monitor: Fix condition for disabling UART interrupts
- https://gerrit.zephyrproject.org/r/4085 : soc: Use nrf.h instead of nrf52.h and nrf52_bitfields.h
- https://gerrit.zephyrproject.org/r/4099 : ext qmsi: Fix broken built-in qmsi build

6861 - 6880 of 8104