Date   

Re: [RFC] Provide a generic interface for getting the SOC ID and version

Nashif, Anas
 

Did not expect this to generate such a big discussion. Here is a use case in addition to what was mentioned in the thread below. Think of this API as a helper API for higher lever features and not a way to select/deselect features based on HW.

Depending on the HW/MCU being used, getting the hardware information such as model number, vendor ID, hardware revision might vary in complexity so implementing this for supported SOCs makes a lot of sense using an API that can be used by applications and higher level features such as IOT protocols. Originally this ZEP was created to prepare for LWM2M and specifically the device profile:

http://dev_devtoolkit.openmobilealliance.org/IoT/LWM2M10/doc/TS/index.html#!Documents/lwm2mobjectdevice.htm

To prepare for the implementation of the profile and to avoid implementing this for the various MCUs in different places where it can be used, the API was proposed.

Feeding this type of data at build time is always an option, but I do not think it makes sense in this case and especially when the HW has lots of information stored already that would make it very difficult to fill in at build time. Doing this at build time will encourage developers and users to enter random data and things like TODO or XYZ all over the place, just to get their app to build and move on. Why bother if the data is already provided by the hardware?

Uniqueness of the data is not key here, multiple boards of the same HW might end up generating the same ID, however, this depends on the hardware and some cases such data can be combined with other sources to achieve this.


Anas

On 29/07/2016, 23:48, "Kumar Gala" <kumar.gala(a)linaro.org> wrote:

If what you are talking about is really for errata than I think we should solve that specific problem. I think a combination of a consistent #define naming and usage convention:

#define CONFIG_ERRATUM_<VENDOR_NAME>_<CHIP>_<VND/CHIP SPECIFIC ERRATUM DESC>

For cases that could be handled at compile time. Than for runtime cases:

Something like:

bool has_erratum(enum erratum_list e).

where erratum_list can be defined in some SoC specific header and code to report if the given erratum is valid on the given chip.

Also, for what you describe, only the revision info is need so at most we’d have an internal API like:
uint32_t __get_soc_revision(void)

- k

> On Jul 28, 2016, at 11:01 AM, Vij, Gajinder S <gajinder.s.vij(a)intel.com> wrote:
>
> I'm confused as to what you mean by using features. Do you mean major silicon features such as different Cache size or different HW acceleration blocks? These would likely be a major rev of the silicon which would warrant a new binary. Also, how are silicon features determined without reading the underlying SOC version?
>
> The origin of the request for the API is for a very specific scenario. When SOC vendors bring up new silicon, there are often multiple revisions of silicon available to the dev/test team before the chip is commercially available. Early versions of the silicon invariably have hardware bugs and the driver SW needs to compensate. As new iterations of the silicon are available to the dev/test team, either run-time detection is used to apply/disable the HW work-arounds, or the older HW boards become deadweight. This has significant cost and efficiency implications. This API is intended to be used at a very low level to allow drivers to enable/disable HW work-arounds. Having the API in the kernel saves the dev team from deriving their own API. I've seen scenarios where different component teams on the same project each implement their own SOC version detection scheme for this purpose.
>
> The API is not intended for use by applications, and is not intended to distinguish between major chipset releases (example, not intended to distinguish between 384 vs a 486, or a Cortex M0 vs a Cortex M4). I'm still confused as to why a developer go through the trouble to have a single binary that runs on significantly different systems. This would be an inefficient use of FLASH and Memory, unnecessarily increasing cost of the end device.
>
> I maintain that if an OEM picks up new silicon that has additional functionality, there will be a new HW board to enable new features/sensors, a new display etc. The OEM will naturally go through the process to create a separate binary. They may decide to use the same code-base to create multiple binaries, but that will be at compile-time, and won't require run-time detection to distinguish code-paths. It is _more_ work to create a single binary that runs on multiple HW SKUs, and a _lot more_ work to create a single binary that runs on two platforms that are significantly different.
>
> Can you provide an example of an API that would provide feature level granularity?
>
> Thanks,
> Gajinder
>
>
>
> -----Original Message-----
> From: Kumar Gala [mailto:kumar.gala(a)linaro.org]
> Sent: Thursday, July 28, 2016 6:25 AM
> To: Vij, Gajinder S <gajinder.s.vij(a)intel.com>
> Cc: Morgaine <morgaine.dinova(a)googlemail.com>; devel(a)lists.zephyrproject.org
> Subject: Re: [devel] [RFC] Provide a generic interface for getting the SOC ID and version
>
> The use case you specify of picking SOC-version-specific code at run-time should be using features and not an ID for determining such things. This goes directly to Tixy’s email thread which I agree with 100%.
>
> - k
>
>> On Jul 22, 2016, at 8:02 PM, Vij, Gajinder S <gajinder.s.vij(a)intel.com> wrote:
>>
>> There is a clear use case for the API, as articulated by Morgaine and Pedro (included below). The purpose of the API is to provide the mechanism for a developer to be able to select SOC-version-specific code paths at run-time, reducing the need for a custom image per SOC version. When and if version specific code is used depends on the circumstances and should be left to the developer as a policy decision.
>>
>> I’d like to determine if there is still objections to this API being implemented in Zephyr. I read through the thread and will attempt to address the concerns raised.
>>
>> On the concerns articulated by Tixy, since the App, Kernel, and BSP are all compiled from source into a single binary, I don’t see the same app compatibility issues cropping up in a Zephyr scenario that have come up in Linux. It is conceivable that someone may attempt to use the SOC version as a way to distinguish between different variants of a product family, but that would be an inappropriate use of the API.
>>
>> I don’t know where the notion of using this API as an entropy source came from. I have removed this from the Jira description.
>>
>> To the question about forward support and uniqueness of the IDs – should this happen on different architectures, I don’t see a problem because I expect the BSPs will still be unique, and therefore I don’t expect a binary run on one platform to successfully be run on another.
>>
>> Comments welcome.
>>
>> Thanks,
>> Gajinder
>>
>>
>> Pedro’s use case:
>> Ø The user might know the SOC ID at compile time (although a user might want to check against the hardware in case of doubt).
>> Ø The SOC revision can change between hardware stepping, so the user might not know at compile time the version of a given model.
>> Ø In that case reading the hardware registers is the only way to know the revision.
>>
>> Morgaine’s use case:
>> Ø This API creates a 1:N relationship between compiled firmware and target behaviour. In other words it allows target behaviour to be parametrized by some target identifier in a standard way given by the API, without requiring each different target to be loaded with different firmware.
>>
>>
>>
>> From: Morgaine [mailto:morgaine.dinova(a)googlemail.com]
>> Sent: Thursday, July 21, 2016 10:27 AM
>> To: devel(a)lists.zephyrproject.org
>> Subject: [devel] Re: [RFC] Provide a generic interface for getting the SOC ID and version
>>
>> Kumar writes:
>>> So I ask again, what are we trying to accomplish?
>>
>> See my preceding reply, which explored exactly that question.
>>
>> From the original requirement expressed in the RFC and from Tixy's subsequent comments, it's clear that there are at least two distinct purposes in people's minds: the one mentioned in the RFC which required uniqueness for generating unique per-target data, and another purpose related to feature sets. It was noted that the second of these is somewhat problematic.
>>
>> My interest is in the simpler of these, the requirement expressed in the RFC, because it is such a common need. Someone else will have to argue in favour of the other if they feel it's important. The two could of course be combined if the agreed data width permits.
>>
>> Morgaine.
>>
>


Re: Porting to Cortex-M0+

Euan Mutch <euan.mutch@...>
 

TIxy,
I am thinking either, CPU_HAS_BASEPRI or ARCH_HAS_BASEPRI.

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.

Ricardo,
I am hoping to push the finished port back to the community. Although it might not be finished for a litle while yet!

I now have my M0+ board (SAMD20 Xplained Pro) and have managed to program it with zephyr using Atmel Studio. So far it gets to main and can run C code, but not much else.


Re: About the testing framework

Rohit Grover
 

Yes, calling the test case repeatedly isn't important, and may even complicate things. Given than threads can yield/block, this should be easy to abstract into the framework.

I would also like to propose importing test macros from Unity<http://www.throwtheswitch.org/unity/>. It would then be one less thing to maintain.

rohit

From: Hannikainen, Jaakko [mailto:jaakko.hannikainen(a)intel.com]
Sent: 17 August 2016 09:25
To: Rohit Grover; devel(a)lists.zephyrproject.org
Subject: RE: About the testing framework

Hello,

Thanks for the feedback and suggestions!

I believe the framework can be extended to provide support for asynchronous testing. An assertion function which either blocks until a condition/timeout or calls a callback function should be relatively easy to implement. I think the waiting part should be abstracted into the framework itself, so that developers can focus on the test itself and not the framework around it. Especially calling the same function on repeat with a call count seems really like a bad code smell to me - certainly we could do better.

Jaakko
________________________________
From: Rohit Grover [Rohit.Grover(a)arm.com]
Sent: Wednesday, August 17, 2016 10:40
To: Hannikainen, Jaakko; devel(a)lists.zephyrproject.org<mailto:devel(a)lists.zephyrproject.org>
Subject: [devel] Re: About the testing framework
Hello Community,

Thanks for introducing a test framework.

It seems that this proposed test framework only deals with synchronous test execution. It is fine for a start, but this may prove to be a limitation.

Consider the pattern offered by 'utest' from mbed: https://github.com/armmbed/utest#test-case-handlers, where a test case handler may execute asynchronously as many times as needed until a case setup succeeded. So a test case for a peripheral may return partway (after setting up an async. operation) with a CaseTimeout(uint32_t ms) + CaseRepeatAll (for instance) to indicate that the harness should wait for validation from asynchronous activity before proceeding (in this case before repeating the test).

The following shows a sample test for flash-erase which would be valid for flash peripherals operating erase either synchronously or asynchronously.

control_t test_flashErase(size_t call_count)
{
switch(call_count) { /* call_count is automatically incremented by the harness for every repeat-invocation */
case 0:
/* erase the sector at 'addr' */
LOG_INFO("erasing sector at addr %lu", (uint32_t)addr);
rc = drv->Erase(addr, erase_unit); /* assume that the system is setup to call eraseCompleteCallback() upon completion of Erase */
TEST_ASSERT(rc >= 0);
if (rc == 0) { /* this indicates that the operation is still active in the background */
TEST_ASSERT_EQUAL(true, capabilities.asynchronous_ops);
return CaseTimeout(200) + CaseRepeatAll; /* wait for up to 200ms for the operation to complete before proceeding */
} else { /* this is the case for synchronous completion of erase */
TEST_ASSERT_EQUAL(erase_unit, rc);
verifyBytePattern(addr, erase_unit, (uint8_t)0xFF);
}

/* intentional fallthrough */

case 1:
// proceed with testing of erased flash
...
}
}

void eraseCompleteCallback(int32_t status, STORAGE_OPERATION operation)
{
TEST_ASSERT_EQUAL(STORAGE_OPERATION_ERASE, operation);
TEST_ASSERT_EQUAL(ARM_DRIVER_OK, status);
verifyBytePattern(addr, erase_unit, (uint8_t)0xFF);

Harness::validate_callback(); /* this tells the test framework to proceed with the test */
}

Being able to write asynchronous tests will enhance the quality and reach of hardware testing.

Regards,
Rohit.
From: Hannikainen, Jaakko [mailto:jaakko.hannikainen(a)intel.com]
Sent: 17 August 2016 07:56
To: devel(a)lists.zephyrproject.org<mailto:devel(a)lists.zephyrproject.org>
Subject: [devel] Re: About the testing framework

Hello,

I now implemented an initial version of a framework, and I submitted it at https://gerrit.zephyrproject.org/r/#/c/4118/

While developing, it became apparent that the current testing stack also benefits from a more generic way of testing. I made the stack so that it works transparently both on Zephyr and without Zephyr. I implemented a small testing program for native (as in your own computer) testing and converted an existing test to the new framework as a sample.

The framework in general is a work-in-progress, but at its current state it's already usable for general testing. When I ran some dummy native tests, I could run about 30 tests within 5 seconds on my laptop. Comparing this to current QEMU testing, where 1 test took 9 seconds on my computer. Clearly this would improve development speed for test-driven development as initial tests take much less time and can be written simultaneously for both QEMU and native runs, sans a couple lines of boilerplate for native code.

Jaakko
________________________________
From: Hannikainen, Jaakko [jaakko.hannikainen(a)intel.com]
Sent: Wednesday, August 03, 2016 15:29
To: devel(a)lists.zephyrproject.org<mailto:devel(a)lists.zephyrproject.org>
Subject: [devel] About the testing framework
Hello,

Currently, the testing stack consists of an unsorted bunch of integration and end-to-end tests. There's nothing wrong with having integration tests, but currently a lot of the tests could be done at least partially as plain unit tests. This way we could skip over a lot of unneeded time used for both compiling and running tests, as a lot of the testable code is written in portable C. Then the unit tests wouldn't have to do anything except compile the single .c file containing the code and link it with the testing framework. The test would also run a lot faster then the current stack since it can be run natively on the host without dragging in QEMU and the rest of Zephyr OS.

Including a unit testing library (either existing or a new one) would have multiple benefits for the entire system:

1) Unit testing enables testing static methods, rather than having to stick with the public api exposed by the module. This way all functions can be tested, for example edge cases of a static validation function.

2) Writing unit tests is also a lot simpler than writing complex integration tests. This would eventually result as an increase of testing coverage as writing tests would have a lower barrier of entry. This would especially happen if the project would start to enforce some percent of required test coverage for all incoming patches (this would have to exclude eg. arch specific code).

3) Writing native tests enables running valgrind on the tests, exposing bugs like invalid pointer dereferences and uninitialized variables. For certain cases, statically initialized code could be turned to dynamically allocated by mocking the respective functions, which would also allow using valgrind to hunt down memory leaks.

Although C lags a bit behind languages like Java for mocking, GCC's -Wl,--wrap works well for isolating single functions for testing. I tested out a library called CMocka (licensed under Apache 2.0) which seemed to work pretty well. Writing our own testing library isn't really that hard either, an initial usable version can be done in a day or two.

I propose including a unit testing framework in the Zephyr project (1.6.0 as target), and would like some discussion about how it should be implemented. Should we write our own test framework or use an existing one? What kind of adaptations to the existing test frameworks would be needed, if any? Should code coverage metrics be enforced so that we could have actual CI, rather than Jenkins just running some tests?

Jaakko
IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.
IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.


Re: About the testing framework

Hannikainen, Jaakko <jaakko.hannikainen@...>
 

Hello,

Thanks for the feedback and suggestions!

I believe the framework can be extended to provide support for asynchronous testing. An assertion function which either blocks until a condition/timeout or calls a callback function should be relatively easy to implement. I think the waiting part should be abstracted into the framework itself, so that developers can focus on the test itself and not the framework around it. Especially calling the same function on repeat with a call count seems really like a bad code smell to me - certainly we could do better.

Jaakko

________________________________
From: Rohit Grover [Rohit.Grover(a)arm.com]
Sent: Wednesday, August 17, 2016 10:40
To: Hannikainen, Jaakko; devel(a)lists.zephyrproject.org
Subject: [devel] Re: About the testing framework

Hello Community,

Thanks for introducing a test framework.

It seems that this proposed test framework only deals with synchronous test execution. It is fine for a start, but this may prove to be a limitation.

Consider the pattern offered by ‘utest’ from mbed: https://github.com/armmbed/utest#test-case-handlers, where a test case handler may execute asynchronously as many times as needed until a case setup succeeded. So a test case for a peripheral may return partway (after setting up an async. operation) with a CaseTimeout(uint32_t ms) + CaseRepeatAll (for instance) to indicate that the harness should wait for validation from asynchronous activity before proceeding (in this case before repeating the test).

The following shows a sample test for flash-erase which would be valid for flash peripherals operating erase either synchronously or asynchronously.

control_t test_flashErase(size_t call_count)
{
switch(call_count) { /* call_count is automatically incremented by the harness for every repeat-invocation */
case 0:
/* erase the sector at 'addr' */
LOG_INFO("erasing sector at addr %lu", (uint32_t)addr);
rc = drv->Erase(addr, erase_unit); /* assume that the system is setup to call eraseCompleteCallback() upon completion of Erase */
TEST_ASSERT(rc >= 0);
if (rc == 0) { /* this indicates that the operation is still active in the background */
TEST_ASSERT_EQUAL(true, capabilities.asynchronous_ops);
return CaseTimeout(200) + CaseRepeatAll; /* wait for up to 200ms for the operation to complete before proceeding */
} else { /* this is the case for synchronous completion of erase */
TEST_ASSERT_EQUAL(erase_unit, rc);
verifyBytePattern(addr, erase_unit, (uint8_t)0xFF);
}

/* intentional fallthrough */

case 1:
// proceed with testing of erased flash
...
}
}

void eraseCompleteCallback(int32_t status, STORAGE_OPERATION operation)
{
TEST_ASSERT_EQUAL(STORAGE_OPERATION_ERASE, operation);
TEST_ASSERT_EQUAL(ARM_DRIVER_OK, status);
verifyBytePattern(addr, erase_unit, (uint8_t)0xFF);

Harness::validate_callback(); /* this tells the test framework to proceed with the test */
}

Being able to write asynchronous tests will enhance the quality and reach of hardware testing.

Regards,
Rohit.
From: Hannikainen, Jaakko [mailto:jaakko.hannikainen(a)intel.com]
Sent: 17 August 2016 07:56
To: devel(a)lists.zephyrproject.org
Subject: [devel] Re: About the testing framework

Hello,

I now implemented an initial version of a framework, and I submitted it at https://gerrit.zephyrproject.org/r/#/c/4118/

While developing, it became apparent that the current testing stack also benefits from a more generic way of testing. I made the stack so that it works transparently both on Zephyr and without Zephyr. I implemented a small testing program for native (as in your own computer) testing and converted an existing test to the new framework as a sample.

The framework in general is a work-in-progress, but at its current state it's already usable for general testing. When I ran some dummy native tests, I could run about 30 tests within 5 seconds on my laptop. Comparing this to current QEMU testing, where 1 test took 9 seconds on my computer. Clearly this would improve development speed for test-driven development as initial tests take much less time and can be written simultaneously for both QEMU and native runs, sans a couple lines of boilerplate for native code.

Jaakko
________________________________
From: Hannikainen, Jaakko [jaakko.hannikainen(a)intel.com]
Sent: Wednesday, August 03, 2016 15:29
To: devel(a)lists.zephyrproject.org<mailto:devel(a)lists.zephyrproject.org>
Subject: [devel] About the testing framework
Hello,

Currently, the testing stack consists of an unsorted bunch of integration and end-to-end tests. There's nothing wrong with having integration tests, but currently a lot of the tests could be done at least partially as plain unit tests. This way we could skip over a lot of unneeded time used for both compiling and running tests, as a lot of the testable code is written in portable C. Then the unit tests wouldn't have to do anything except compile the single .c file containing the code and link it with the testing framework. The test would also run a lot faster then the current stack since it can be run natively on the host without dragging in QEMU and the rest of Zephyr OS.

Including a unit testing library (either existing or a new one) would have multiple benefits for the entire system:

1) Unit testing enables testing static methods, rather than having to stick with the public api exposed by the module. This way all functions can be tested, for example edge cases of a static validation function.

2) Writing unit tests is also a lot simpler than writing complex integration tests. This would eventually result as an increase of testing coverage as writing tests would have a lower barrier of entry. This would especially happen if the project would start to enforce some percent of required test coverage for all incoming patches (this would have to exclude eg. arch specific code).

3) Writing native tests enables running valgrind on the tests, exposing bugs like invalid pointer dereferences and uninitialized variables. For certain cases, statically initialized code could be turned to dynamically allocated by mocking the respective functions, which would also allow using valgrind to hunt down memory leaks.

Although C lags a bit behind languages like Java for mocking, GCC's -Wl,--wrap works well for isolating single functions for testing. I tested out a library called CMocka (licensed under Apache 2.0) which seemed to work pretty well. Writing our own testing library isn't really that hard either, an initial usable version can be done in a day or two.

I propose including a unit testing framework in the Zephyr project (1.6.0 as target), and would like some discussion about how it should be implemented. Should we write our own test framework or use an existing one? What kind of adaptations to the existing test frameworks would be needed, if any? Should code coverage metrics be enforced so that we could have actual CI, rather than Jenkins just running some tests?

Jaakko
IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.


Re: About the testing framework

Rohit Grover
 

Hello Community,

Thanks for introducing a test framework.

It seems that this proposed test framework only deals with synchronous test execution. It is fine for a start, but this may prove to be a limitation.

Consider the pattern offered by 'utest' from mbed: https://github.com/armmbed/utest#test-case-handlers, where a test case handler may execute asynchronously as many times as needed until a case setup succeeded. So a test case for a peripheral may return partway (after setting up an async. operation) with a CaseTimeout(uint32_t ms) + CaseRepeatAll (for instance) to indicate that the harness should wait for validation from asynchronous activity before proceeding (in this case before repeating the test).

The following shows a sample test for flash-erase which would be valid for flash peripherals operating erase either synchronously or asynchronously.

control_t test_flashErase(size_t call_count)
{
switch(call_count) { /* call_count is automatically incremented by the harness for every repeat-invocation */
case 0:
/* erase the sector at 'addr' */
LOG_INFO("erasing sector at addr %lu", (uint32_t)addr);
rc = drv->Erase(addr, erase_unit); /* assume that the system is setup to call eraseCompleteCallback() upon completion of Erase */
TEST_ASSERT(rc >= 0);
if (rc == 0) { /* this indicates that the operation is still active in the background */
TEST_ASSERT_EQUAL(true, capabilities.asynchronous_ops);
return CaseTimeout(200) + CaseRepeatAll; /* wait for up to 200ms for the operation to complete before proceeding */
} else { /* this is the case for synchronous completion of erase */
TEST_ASSERT_EQUAL(erase_unit, rc);
verifyBytePattern(addr, erase_unit, (uint8_t)0xFF);
}

/* intentional fallthrough */

case 1:
// proceed with testing of erased flash
...
}
}

void eraseCompleteCallback(int32_t status, STORAGE_OPERATION operation)
{
TEST_ASSERT_EQUAL(STORAGE_OPERATION_ERASE, operation);
TEST_ASSERT_EQUAL(ARM_DRIVER_OK, status);
verifyBytePattern(addr, erase_unit, (uint8_t)0xFF);

Harness::validate_callback(); /* this tells the test framework to proceed with the test */
}

Being able to write asynchronous tests will enhance the quality and reach of hardware testing.

Regards,
Rohit.
From: Hannikainen, Jaakko [mailto:jaakko.hannikainen(a)intel.com]
Sent: 17 August 2016 07:56
To: devel(a)lists.zephyrproject.org
Subject: [devel] Re: About the testing framework

Hello,

I now implemented an initial version of a framework, and I submitted it at https://gerrit.zephyrproject.org/r/#/c/4118/

While developing, it became apparent that the current testing stack also benefits from a more generic way of testing. I made the stack so that it works transparently both on Zephyr and without Zephyr. I implemented a small testing program for native (as in your own computer) testing and converted an existing test to the new framework as a sample.

The framework in general is a work-in-progress, but at its current state it's already usable for general testing. When I ran some dummy native tests, I could run about 30 tests within 5 seconds on my laptop. Comparing this to current QEMU testing, where 1 test took 9 seconds on my computer. Clearly this would improve development speed for test-driven development as initial tests take much less time and can be written simultaneously for both QEMU and native runs, sans a couple lines of boilerplate for native code.

Jaakko
________________________________
From: Hannikainen, Jaakko [jaakko.hannikainen(a)intel.com]
Sent: Wednesday, August 03, 2016 15:29
To: devel(a)lists.zephyrproject.org<mailto:devel(a)lists.zephyrproject.org>
Subject: [devel] About the testing framework
Hello,

Currently, the testing stack consists of an unsorted bunch of integration and end-to-end tests. There's nothing wrong with having integration tests, but currently a lot of the tests could be done at least partially as plain unit tests. This way we could skip over a lot of unneeded time used for both compiling and running tests, as a lot of the testable code is written in portable C. Then the unit tests wouldn't have to do anything except compile the single .c file containing the code and link it with the testing framework. The test would also run a lot faster then the current stack since it can be run natively on the host without dragging in QEMU and the rest of Zephyr OS.

Including a unit testing library (either existing or a new one) would have multiple benefits for the entire system:

1) Unit testing enables testing static methods, rather than having to stick with the public api exposed by the module. This way all functions can be tested, for example edge cases of a static validation function.

2) Writing unit tests is also a lot simpler than writing complex integration tests. This would eventually result as an increase of testing coverage as writing tests would have a lower barrier of entry. This would especially happen if the project would start to enforce some percent of required test coverage for all incoming patches (this would have to exclude eg. arch specific code).

3) Writing native tests enables running valgrind on the tests, exposing bugs like invalid pointer dereferences and uninitialized variables. For certain cases, statically initialized code could be turned to dynamically allocated by mocking the respective functions, which would also allow using valgrind to hunt down memory leaks.

Although C lags a bit behind languages like Java for mocking, GCC's -Wl,--wrap works well for isolating single functions for testing. I tested out a library called CMocka (licensed under Apache 2.0) which seemed to work pretty well. Writing our own testing library isn't really that hard either, an initial usable version can be done in a day or two.

I propose including a unit testing framework in the Zephyr project (1.6.0 as target), and would like some discussion about how it should be implemented. Should we write our own test framework or use an existing one? What kind of adaptations to the existing test frameworks would be needed, if any? Should code coverage metrics be enforced so that we could have actual CI, rather than Jenkins just running some tests?

Jaakko
IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.


Re: About the testing framework

Hannikainen, Jaakko <jaakko.hannikainen@...>
 

Hello,

I now implemented an initial version of a framework, and I submitted it at https://gerrit.zephyrproject.org/r/#/c/4118/

While developing, it became apparent that the current testing stack also benefits from a more generic way of testing. I made the stack so that it works transparently both on Zephyr and without Zephyr. I implemented a small testing program for native (as in your own computer) testing and converted an existing test to the new framework as a sample.

The framework in general is a work-in-progress, but at its current state it's already usable for general testing. When I ran some dummy native tests, I could run about 30 tests within 5 seconds on my laptop. Comparing this to current QEMU testing, where 1 test took 9 seconds on my computer. Clearly this would improve development speed for test-driven development as initial tests take much less time and can be written simultaneously for both QEMU and native runs, sans a couple lines of boilerplate for native code.

Jaakko

________________________________
From: Hannikainen, Jaakko [jaakko.hannikainen(a)intel.com]
Sent: Wednesday, August 03, 2016 15:29
To: devel(a)lists.zephyrproject.org
Subject: [devel] About the testing framework

Hello,

Currently, the testing stack consists of an unsorted bunch of integration and end-to-end tests. There's nothing wrong with having integration tests, but currently a lot of the tests could be done at least partially as plain unit tests. This way we could skip over a lot of unneeded time used for both compiling and running tests, as a lot of the testable code is written in portable C. Then the unit tests wouldn't have to do anything except compile the single .c file containing the code and link it with the testing framework. The test would also run a lot faster then the current stack since it can be run natively on the host without dragging in QEMU and the rest of Zephyr OS.

Including a unit testing library (either existing or a new one) would have multiple benefits for the entire system:

1) Unit testing enables testing static methods, rather than having to stick with the public api exposed by the module. This way all functions can be tested, for example edge cases of a static validation function.

2) Writing unit tests is also a lot simpler than writing complex integration tests. This would eventually result as an increase of testing coverage as writing tests would have a lower barrier of entry. This would especially happen if the project would start to enforce some percent of required test coverage for all incoming patches (this would have to exclude eg. arch specific code).

3) Writing native tests enables running valgrind on the tests, exposing bugs like invalid pointer dereferences and uninitialized variables. For certain cases, statically initialized code could be turned to dynamically allocated by mocking the respective functions, which would also allow using valgrind to hunt down memory leaks.

Although C lags a bit behind languages like Java for mocking, GCC's -Wl,--wrap works well for isolating single functions for testing. I tested out a library called CMocka (licensed under Apache 2.0) which seemed to work pretty well. Writing our own testing library isn't really that hard either, an initial usable version can be done in a day or two.

I propose including a unit testing framework in the Zephyr project (1.6.0 as target), and would like some discussion about how it should be implemented. Should we write our own test framework or use an existing one? What kind of adaptations to the existing test frameworks would be needed, if any? Should code coverage metrics be enforced so that we could have actual CI, rather than Jenkins just running some tests?

Jaakko


Re: Porting to Cortex-M0+

Ricardo Salveti <ricardo.salveti@...>
 

Hi Euan,

On Thu, Aug 4, 2016 at 6:00 AM, Euan Mutch <euan.mutch(a)gmail.com> wrote:
Hi Ben,

That seems to be working properly now with the interrupts being disabled.

We might be able to merge the M0 and
M3/M4 implementations as well.
I have been trying to make sure that anything I change still works on M3/M4
and will add config options where a common approach would not work.
I was looking at what would take to get Zephyr to support Cortex-M0
today (wanted to port Zephyr to nRF51), and found your thread :-)

Are you expecting to open source/upstream your Cortex M0+ based port?
Wanted to avoid duplicating this effort, as the M0 port would be quite
similar with M0+. Happy to test/review your implementation as well.

Thanks,
--
Ricardo Salveti


Daily JIRA Digest

donotreply@...
 

NEW JIRA items within last 24 hours: 6
[ZEP-702] Integrate Nordic's Phoenix Link Layer into Zephyr
https://jira.zephyrproject.org/browse/ZEP-702

[ZEP-706] cannot set debug breakpoints on ARC side of Arduino 101
https://jira.zephyrproject.org/browse/ZEP-706

[ZEP-710] debugging on ARC results in spam of symtab internal error messages
https://jira.zephyrproject.org/browse/ZEP-710

[ZEP-707] mem_safe test stomps on top of .data and bottom of .noinit
https://jira.zephyrproject.org/browse/ZEP-707

[ZEP-705] SDK 0.8.2 GCC does not support stand-alone usage
https://jira.zephyrproject.org/browse/ZEP-705

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


UPDATED JIRA items within last 24 hours: 12
[ZEP-245] Restructure Documentation content
https://jira.zephyrproject.org/browse/ZEP-245

[ZEP-230] Define I2S driver APIs
https://jira.zephyrproject.org/browse/ZEP-230

[ZEP-328] HW Encryption Abstraction
https://jira.zephyrproject.org/browse/ZEP-328

[ZEP-216] LWM2M for device management
https://jira.zephyrproject.org/browse/ZEP-216

[ZEP-244] Multiple Published Versions Support
https://jira.zephyrproject.org/browse/ZEP-244

[ZEP-235] Provide an interface for cpu/soc id and version
https://jira.zephyrproject.org/browse/ZEP-235

[ZEP-347] Driver for LSM6DS0 accelerometer and gyroscope
https://jira.zephyrproject.org/browse/ZEP-347

[ZEP-661] QMSI shim driver: SPI: Implement suspend and resume callbacks
https://jira.zephyrproject.org/browse/ZEP-661

[ZEP-653] QMSI shim driver: Watchdog: Implement suspend and resume callbacks
https://jira.zephyrproject.org/browse/ZEP-653

[ZEP-654] QMSI shim driver: I2C: Implement suspend and resume callbacks
https://jira.zephyrproject.org/browse/ZEP-654

[ZEP-657] QMSI shim driver: AONPT: Implement suspend and resume callbacks
https://jira.zephyrproject.org/browse/ZEP-657

[ZEP-559] sanitycheck/CI is not building with all supported toolchains
https://jira.zephyrproject.org/browse/ZEP-559


CLOSED JIRA items within last 24 hours: 7
[ZEP-512] (Fixed) Add suspend/resume support for some core devices to enable Deep Sleep support in PMA
https://jira.zephyrproject.org/browse/ZEP-512

[ZEP-424] (Fixed) AON counter driver needs to add driver API reentrancy support
https://jira.zephyrproject.org/browse/ZEP-424

[ZEP-440] (Fixed) Add driver API reentrancy support to WDT shim driver
https://jira.zephyrproject.org/browse/ZEP-440

[ZEP-320] (Fixed) Support bare-metal toolchains
https://jira.zephyrproject.org/browse/ZEP-320

[ZEP-647] (Fixed) Power management state storage should use GPS1 instead of GPS0
https://jira.zephyrproject.org/browse/ZEP-647

[ZEP-694] (Duplicate) tests/kernel/test_stack/nanokernel: random failures (notably on ARC)
https://jira.zephyrproject.org/browse/ZEP-694

[ZEP-709] (Duplicate) tests/kernel/test_xip/nanokernel Times out on ARC core of Quakr SE devboard and Arduino 101
https://jira.zephyrproject.org/browse/ZEP-709


RESOLVED JIRA items within last 24 hours: 10
[ZEP-285] (Fixed) FAT filesystem support on top of SPI Flash
https://jira.zephyrproject.org/browse/ZEP-285

[ZEP-240] (Fixed) printk/printf usage in samples
https://jira.zephyrproject.org/browse/ZEP-240

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

[ZEP-400] (Fixed) Driver for AK8975C magnetometer
https://jira.zephyrproject.org/browse/ZEP-400

[ZEP-650] (Fixed) Quark SE: Implement PM reference application
https://jira.zephyrproject.org/browse/ZEP-650

[ZEP-662] (Fixed) QMSI shim driver: Pinmux: Implement suspend and resume callbacks
https://jira.zephyrproject.org/browse/ZEP-662

[ZEP-652] (Fixed) QMSI shim driver: RTC: Implement suspend and resume callbacks
https://jira.zephyrproject.org/browse/ZEP-652

[ZEP-655] (Fixed) QMSI shim driver: PWM: Implement suspend and resume callbacks
https://jira.zephyrproject.org/browse/ZEP-655

[ZEP-658] (Fixed) QMSI shim driver: GPIO: Implement suspend and resume callbacks
https://jira.zephyrproject.org/browse/ZEP-658

[ZEP-659] (Fixed) QMSI shim driver: UART: Implement suspend and resume callbacks
https://jira.zephyrproject.org/browse/ZEP-659


Daily Gerrit Digest

donotreply@...
 

NEW within last 24 hours:
- https://gerrit.zephyrproject.org/r/4111 : usb: Add USB sample build test to sanity check
- https://gerrit.zephyrproject.org/r/4106 : ipm_console: rate-limit to avoid losing messages
- https://gerrit.zephyrproject.org/r/4117 : Bluetooth: monitor: Fix condition for disabling UART interrupts
- https://gerrit.zephyrproject.org/r/4104 : libc/printf: Use compiler-provided 64 bit math, phase 2
- https://gerrit.zephyrproject.org/r/4103 : libc/printf: Use compiler-provided 64 bit math, phase 1
- https://gerrit.zephyrproject.org/r/4102 : libc/printf: Remove vestigial "full" parameter to _to_float()
- https://gerrit.zephyrproject.org/r/4118 : RFC: tests: Add a generic testing framework
- https://gerrit.zephyrproject.org/r/4116 : Bluetooth: btp: Add Address Type to Read Controller Information rsp
- https://gerrit.zephyrproject.org/r/4113 : Bluetooth: tests/shell: Set BR/EDR name
- https://gerrit.zephyrproject.org/r/4114 : Bluetooth: tests/init: Add test with BR/EDR name set
- https://gerrit.zephyrproject.org/r/4110 : net: samples: Fix the location of net-tools project files
- https://gerrit.zephyrproject.org/r/4108 : sample: update usb_cdc case to avoid compile error
- https://gerrit.zephyrproject.org/r/4107 : ipm_console_receiver: correctly populate driver data
- https://gerrit.zephyrproject.org/r/4101 : tests/mem_safe: place test buffers at the edges of RAM
- https://gerrit.zephyrproject.org/r/4105 : X
- https://gerrit.zephyrproject.org/r/4100 : build: allow specifying a custom linker script relative to project

UPDATED within last 24 hours:
- https://gerrit.zephyrproject.org/r/3806 : net: yaip: Sample code to play with ieee 802.15.4 stack
- https://gerrit.zephyrproject.org/r/3735 : net: tests: Add unit tests for 6lowpan functionality
- https://gerrit.zephyrproject.org/r/4041 : net: yaip: Add debug message on IPv6 preliminary check
- https://gerrit.zephyrproject.org/r/3835 : net: yaip: Add support for IEEE 802.15.4 fragmentation
- https://gerrit.zephyrproject.org/r/4033 : net: yaip: SYS_INIT() routines are never ran twice
- https://gerrit.zephyrproject.org/r/3786 : net: yaip: Check ICMPv6 options length correctly
- https://gerrit.zephyrproject.org/r/4091 : board: nrf52_pca10040: Include Controller by default in board nrf52_pca10040
- https://gerrit.zephyrproject.org/r/4090 : Bluetooth: Controller: Add driver that glues Link Layer with the BLE stack
- https://gerrit.zephyrproject.org/r/3995 : Bluetooth: Export USB HCI controller using RAW HCI channel
- https://gerrit.zephyrproject.org/r/3821 : net: yaip: Add network interface to neighbor creation call
- https://gerrit.zephyrproject.org/r/4044 : net: yaip: Add more debugging messages into 6lo
- https://gerrit.zephyrproject.org/r/3838 : net: tests: Add fragmentation unit tests
- https://gerrit.zephyrproject.org/r/3826 : net: yaip: Add support for IPv6 prefix lifetime
- https://gerrit.zephyrproject.org/r/3787 : net: yaip: Sent NS was two bytes too long
- https://gerrit.zephyrproject.org/r/4034 : net: yaip: ieee802154: Logging header should be loaded first
- https://gerrit.zephyrproject.org/r/3824 : net: yaip: Send available pending data after receiving IPv6 NA
- https://gerrit.zephyrproject.org/r/3776 : net: yaip: Update UDP sent packet statistics
- https://gerrit.zephyrproject.org/r/3832 : net: yaip: Add 6lowpan without compression header support
- https://gerrit.zephyrproject.org/r/4048 : samples: Build ieee802154 sample with 6lo support
- https://gerrit.zephyrproject.org/r/3790 : net: yaip: l2 layer reserve size might need extra parameter
- https://gerrit.zephyrproject.org/r/4045 : net: yaip: ieee802154: Handle plain/compressed ll addr relevantly
- https://gerrit.zephyrproject.org/r/4046 : net: yaip: Integrate 6lo compression support in IEEE 802.15.4 L2 stack
- https://gerrit.zephyrproject.org/r/3756 : net: yaip: Utility function to append UDP packet into net_buf
- https://gerrit.zephyrproject.org/r/3777 : net: yaip: No need to swap ll address in IPv6 module
- https://gerrit.zephyrproject.org/r/4089 : Bluetooth: Controller: A full, hardware-agnostic Link Layer implementation
- https://gerrit.zephyrproject.org/r/4088 : Bluetooth: Controller: Initial impl. of a HCI controller-side interface
- https://gerrit.zephyrproject.org/r/4087 : Bluetooth: Controller: Add a util folder with basic primitives
- https://gerrit.zephyrproject.org/r/4086 : Bluetooth: Controller: Hardware abstraction layer for nRF5x radio
- https://gerrit.zephyrproject.org/r/3796 : net: yaip: Add new IEEE 802.15.4 Radio API for device drivers
- https://gerrit.zephyrproject.org/r/4032 : net: yaip: net_if section should be always aligned
- https://gerrit.zephyrproject.org/r/3793 : net: yaip: Add a function to lookup for an iface from a device
- https://gerrit.zephyrproject.org/r/4007 : libc/printf: Unify & simplify number printing
- https://gerrit.zephyrproject.org/r/3779 : net: yaip: Ethernet driver needs to set ll address
- https://gerrit.zephyrproject.org/r/4022 : net: yaip: Trickle algorithm implementation
- https://gerrit.zephyrproject.org/r/3785 : net: yaip: Change srctree to ZEPHYR_BASE in Makefiles
- https://gerrit.zephyrproject.org/r/3818 : net: yaip: Set initial neighbor value when IPv6 NS is received
- https://gerrit.zephyrproject.org/r/3769 : net: yaip: Rename ip_protocol to net_ip_protocol
- https://gerrit.zephyrproject.org/r/3755 : net: yaip: Add helper to create IPv4 packet
- https://gerrit.zephyrproject.org/r/3771 : net: yaip: Add token to nbuf
- 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/3804 : drivers: cc2520: Add a new IP stack ready adaptation of CC2520 driver
- https://gerrit.zephyrproject.org/r/3745 : net: yaip: net_hexdump_frags() is only available when debugging
- https://gerrit.zephyrproject.org/r/3753 : net: yaip: Add user space API to net_context
- https://gerrit.zephyrproject.org/r/3772 : net: yaip: Call send callback in net_context properly
- https://gerrit.zephyrproject.org/r/3766 : net: yaip: Add more debugging to nbuf
- https://gerrit.zephyrproject.org/r/3767 : net: yaip: Set reserve, context and iface properly in nbuf
- https://gerrit.zephyrproject.org/r/3775 : net: yaip: nbuf variables needs clearing when allocating nbuf
- 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/3800 : tests: yaip: Add grounds for IEEE 802.15.4 stack tests.
- https://gerrit.zephyrproject.org/r/3743 : net: yaip: Making IP address const in utility func
- https://gerrit.zephyrproject.org/r/3770 : net: yaip: Check IPv6 NS, NA and RA messages for corruption
- https://gerrit.zephyrproject.org/r/3768 : net: apps: Fix echo-server to use the new user API
- https://gerrit.zephyrproject.org/r/3749 : net: yaip: Add helpers for getting protocol specific sockaddr
- https://gerrit.zephyrproject.org/r/3802 : tests: net: Add a IEEE 802.15.4 ACK replies test
- https://gerrit.zephyrproject.org/r/4023 : net: tests: Test Trickle algorithm
- https://gerrit.zephyrproject.org/r/3795 : net: yaip: L2 might need private data per-interface
- https://gerrit.zephyrproject.org/r/3797 : net: yaip: Add preliminary IEEE 802.15.4 L2 driver
- https://gerrit.zephyrproject.org/r/3801 : net: yaip: ieee802154: Support ACK replies
- https://gerrit.zephyrproject.org/r/3754 : net: yaip: Add helper to create IPv6 packet
- https://gerrit.zephyrproject.org/r/3798 : net: yaip: Adding ALOHA radio protocol to IEEE 802.15.4 L2 driver
- https://gerrit.zephyrproject.org/r/3799 : net: yaip: Add support for the IEEE 802.15.4 ORFD
- https://gerrit.zephyrproject.org/r/3774 : net: yaip: Check packet sending status correctly in arp.c
- https://gerrit.zephyrproject.org/r/3748 : net: yaip: Add sockaddr struct
- https://gerrit.zephyrproject.org/r/3759 : net: yaip: Set the protocol family and interface for net_buf
- https://gerrit.zephyrproject.org/r/3757 : net: yaip: Create IPv4, IPv6 and UDP packets when needed
- https://gerrit.zephyrproject.org/r/4040 : net: yaip: Add debug messages on drop reasons
- https://gerrit.zephyrproject.org/r/4047 : net: yaip: Add packet display in ieee802154 l2 stack
- https://gerrit.zephyrproject.org/r/3744 : net: tests: UDP unit test had wrong ll address length
- https://gerrit.zephyrproject.org/r/3758 : net: tests: Unit tests for user space socket API
- https://gerrit.zephyrproject.org/r/3760 : slip: Do not send ethernet header if mtu is large enough
- https://gerrit.zephyrproject.org/r/3784 : net: yaip: Add a function to retrieve a neighbour from an IPv6 address
- https://gerrit.zephyrproject.org/r/4038 : net: yaip: Built IEEE 802.15.4 fragmentation logic if requested only
- https://gerrit.zephyrproject.org/r/3765 : net: yaip: Use proper ll header length when sending IPv6 NS
- https://gerrit.zephyrproject.org/r/3834 : net: tests: Add unit tests for 6lo IPv6 dispatch support
- https://gerrit.zephyrproject.org/r/3752 : net: yaip: Increasing the default IPv6 unicast addr count
- https://gerrit.zephyrproject.org/r/4037 : net: yaip: Follow file naming in ieee802154 l2 stack
- https://gerrit.zephyrproject.org/r/3781 : net: yaip: RX fiber needs bigger stack
- https://gerrit.zephyrproject.org/r/3782 : net: yaip: Add IPv6 ND statistics when relevant
- https://gerrit.zephyrproject.org/r/3778 : net: yaip: IPv6 neighbor was not properly added to cache
- https://gerrit.zephyrproject.org/r/3742 : net: yaip: Protocol family needs to be set for multicast address
- https://gerrit.zephyrproject.org/r/3750 : net: yaip: Convert network connection to use sockaddr
- https://gerrit.zephyrproject.org/r/3773 : net: yaip: Call net_context send callback when packet is sent
- https://gerrit.zephyrproject.org/r/3751 : net: yaip: Add net_conn pointer to callback
- https://gerrit.zephyrproject.org/r/3762 : net: yaip: Neighbor cache entry was not properly init
- https://gerrit.zephyrproject.org/r/4036 : net: yaip: Giving an uncompressed buffer to 6lo is not an error
- https://gerrit.zephyrproject.org/r/4039 : net: yaip: Handle LL part in 6lo logic when relevant
- https://gerrit.zephyrproject.org/r/3783 : net: yaip: Fix IPv6 NS packet size check
- https://gerrit.zephyrproject.org/r/4035 : samples: ieee802154: Debugging needs a new Kconfig option
- https://gerrit.zephyrproject.org/r/3780 : net: yaip: Return NET_CONTINUE in L2 ethernet driver in send()
- https://gerrit.zephyrproject.org/r/3741 : net: tests: udp: Print debug information only when activated
- 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/3761 : net: yaip: Fix debug prints in net conn manager
- https://gerrit.zephyrproject.org/r/4030 : AVDTP Module Changes
- 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/3997 : Bluetooth: L2CAP: Implement connect command on BR/EDR
- https://gerrit.zephyrproject.org/r/3996 : Bluetooth: L2CAP: Fix BR/EDR connect & send internal API
- https://gerrit.zephyrproject.org/r/4024 : Bluetooth: Set BR/EDR device name on init
- https://gerrit.zephyrproject.org/r/4093 : Bluetooth: Enable SOC FLASH
- https://gerrit.zephyrproject.org/r/3839 : net: yaip: Modify NET6LO_ defines to NET_6LO
- https://gerrit.zephyrproject.org/r/3837 : net: yaip: Add support for IEEE 802.15.4 reassembly
- https://gerrit.zephyrproject.org/r/3836 : net: yaip: Integrate 6lowpan and 802.15.4 fragmentation
- https://gerrit.zephyrproject.org/r/3833 : net: yaip: Fix wrong UDP length calculation in 6lo compression
- https://gerrit.zephyrproject.org/r/3831 : net: yaip: Change 6lo api's returned parameter
- 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/3825 : net: yaip: Use target address in IPv6 NS to lookup neighbor
- 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 in IPv6 cache
- https://gerrit.zephyrproject.org/r/3820 : net: yaip: Add more debugging prints to IPv6 ND handling
- https://gerrit.zephyrproject.org/r/3819 : net: yaip: Add debug helper for neighbor tables
- 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/3815 : net: yaip: Wrong pointer was used when setting router status
- 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/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/3805 : boards: quark_se_devboard: Build cc2520 if YAIP IEEE 802.15.4 is in
- https://gerrit.zephyrproject.org/r/3803 : drivers: cc2520: Make current driver for legacy stack only
- https://gerrit.zephyrproject.org/r/4049 : drivers: cc2520: Raise Rx stack size
- https://gerrit.zephyrproject.org/r/3794 : net: yaip: Fix tx fiber on net_if
- 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/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/3873 : net: tests: Fix the context unit test
- https://gerrit.zephyrproject.org/r/4085 : soc: Use nrf.h instead of nrf52.h and nrf52_bitfields.h
- https://gerrit.zephyrproject.org/r/3596 : net: yaip: net_ipaddr_copy() macro was too fragile
- https://gerrit.zephyrproject.org/r/3618 : net: yaip: Fix __packed attribute, use shorter alias
- https://gerrit.zephyrproject.org/r/3571 : net: yaip: Add IPv4 addresses to network interface
- https://gerrit.zephyrproject.org/r/3612 : net: yaip: ICMPv4 checksum calculation fixed
- https://gerrit.zephyrproject.org/r/3703 : net: yaip: Make some IPv6 utility functions to use const addr
- https://gerrit.zephyrproject.org/r/3704 : net: yaip: Add IPv6 minimum MTU value
- https://gerrit.zephyrproject.org/r/3636 : net: yaip: Print available DATA buffers during nbuf alloc
- 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/3627 : net: yaip: Add an L2 layer
- https://gerrit.zephyrproject.org/r/3664 : net: yaip: Add ethernet address helpers
- https://gerrit.zephyrproject.org/r/3623 : net: yaip: Shorten IPv4/6 config options
- https://gerrit.zephyrproject.org/r/3666 : net: yaip: Set the ll src and dst addresses in ethernet l2 driver
- https://gerrit.zephyrproject.org/r/3546 : net: yaip: Add nbuf buffer API
- https://gerrit.zephyrproject.org/r/3572 : net: tests: Add IPv4 address unit tests
- https://gerrit.zephyrproject.org/r/3668 : net: yaip: Make sure ethernet l2 sets src and dst addresses
- https://gerrit.zephyrproject.org/r/3633 : net: yaip: Add comment explaining net_core's verdict values
- https://gerrit.zephyrproject.org/r/3586 : net: yaip: Add debugging option for network utilities
- https://gerrit.zephyrproject.org/r/3613 : net: tests: Additional tests for ICMPv4 checksum verification
- https://gerrit.zephyrproject.org/r/3577 : net: yaip: Added API documentation to IP address check functions
- https://gerrit.zephyrproject.org/r/3575 : net: yaip: Network interface code compiles ok for IPv4 and IPv6
- https://gerrit.zephyrproject.org/r/3574 : net: tests: Add more IPv6 address getters unit tests
- https://gerrit.zephyrproject.org/r/3582 : net: yaip: Add net_send_data() that sends data to network
- 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/3583 : net: yaip: Network interface needs own TX fiber stack
- https://gerrit.zephyrproject.org/r/3581 : net: yaip: Renamed network data receive function
- https://gerrit.zephyrproject.org/r/3578 : net: yaip: Add ICMP protocol header struct
- https://gerrit.zephyrproject.org/r/3576 : net: yaip: Receive IPv4 packet
- https://gerrit.zephyrproject.org/r/3573 : net: yaip: IPv6 address utility funcs for 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/3566 : net: yaip: Drop received source mcast IPv6 packets
- https://gerrit.zephyrproject.org/r/3565 : net: yaip: Receive IPv6 packet
- 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/3693 : slip: Do not try to unref a null pointer
- 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/3551 : net: yaip: Execute net_init() automatically
- https://gerrit.zephyrproject.org/r/3547 : slip: Add driver for host to qemu connectivity
- https://gerrit.zephyrproject.org/r/3552 : net: yaip: Add net_if_get_by_link_addr() util function
- 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/3542 : net: yaip: Add TX fifo to network interface
- https://gerrit.zephyrproject.org/r/3548 : net: yaip: Fix compilation error in net_if.h
- 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/3539 : net: yaip: Add network address information to interface
- https://gerrit.zephyrproject.org/r/3540 : net: yaip: Add multicast address to network interface
- https://gerrit.zephyrproject.org/r/3538 : net: yaip: apps: Create a skeleton echo-server for new IP stack
- https://gerrit.zephyrproject.org/r/3535 : net: yaip: Use same prefix in new IP stack Kconfig
- https://gerrit.zephyrproject.org/r/3537 : net: Add generic network interface header
- https://gerrit.zephyrproject.org/r/3536 : net: yaip: Compile new stack if enabled
- https://gerrit.zephyrproject.org/r/3534 : net: yaip: Add ntohl() and related macros
- 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/3665 : net: yaip: Set the l2 src/dst addresses in nbuf
- 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/3731 : net: yaip: Clear ipv6 addr parameter on create iid
- https://gerrit.zephyrproject.org/r/3714 : net: tests: Unit tests for net_nbuf_push() function
- https://gerrit.zephyrproject.org/r/3732 : net: yaip: Add support for 802.15.4 short address for iid creation
- https://gerrit.zephyrproject.org/r/3730 : net: yaip: Fix net_ip.h 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/3727 : net: yaip: Moving header files to include/net/yaip
- https://gerrit.zephyrproject.org/r/3729 : net: yaip: Cleanup net_if's documentation
- https://gerrit.zephyrproject.org/r/3726 : net: Refine Kconfig to put NET_BUF appart
- https://gerrit.zephyrproject.org/r/3719 : net: tests: Fix IP address test so that it will not crash
- 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/3720 : net: tests: Fix project file for IP address tests
- https://gerrit.zephyrproject.org/r/3712 : net: yaip: Utility function to compact net_buf fragments
- https://gerrit.zephyrproject.org/r/3722 : net: yaip: Debugging function to print fragment chain information
- https://gerrit.zephyrproject.org/r/3721 : net: yaip: Refactor nbuf.h and nbuf.c
- https://gerrit.zephyrproject.org/r/3717 : net: yaip: Fix compilation when IPv6 is disabled
- https://gerrit.zephyrproject.org/r/3718 : net: tests: ICMPv6 test was missing random number config
- https://gerrit.zephyrproject.org/r/3716 : net: yaip: Refactored IPv6 DAD and ND activation
- https://gerrit.zephyrproject.org/r/3711 : net: tests: Fix ARP test so that it will not crash
- https://gerrit.zephyrproject.org/r/3707 : net: yaip: Generic connection handler for UDP and TCP
- https://gerrit.zephyrproject.org/r/3715 : net: tests: Turning off IPv6 for ARP tests
- https://gerrit.zephyrproject.org/r/3713 : net: yaip: Utility that inserts free space to the fragment list
- https://gerrit.zephyrproject.org/r/3709 : net: yaip: Catch UDP network traffic
- https://gerrit.zephyrproject.org/r/3710 : net: tests: Unit tests for UDP handler
- https://gerrit.zephyrproject.org/r/3708 : net: yaip: Initial UDP support
- https://gerrit.zephyrproject.org/r/3706 : net: yaip: Add support for ICMPv4 error message
- https://gerrit.zephyrproject.org/r/3705 : net: yaip: Add support for ICMPv6 error message
- 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/3699 : net: Kconfig: Refactor Kconfig menus for better clarity
- 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/3697 : net: yaip: Initial router advertisement support
- https://gerrit.zephyrproject.org/r/3695 : net: yaip: Initial IPv6 neighbor discovery support
- https://gerrit.zephyrproject.org/r/3694 : slip: Setup fragments properly if MTU is bigger than frag size
- https://gerrit.zephyrproject.org/r/3691 : slip: Network stack needs to be up before sending data to it
- https://gerrit.zephyrproject.org/r/3692 : net: yaip: Start the network stack after device drivers
- https://gerrit.zephyrproject.org/r/3690 : net: yaip: Remove extra debug print in ethernet L2 driver
- https://gerrit.zephyrproject.org/r/3683 : net: yaip: Ethernet L2 TX side needs to setup fragments
- https://gerrit.zephyrproject.org/r/3678 : net: yaip: Add more debugging to arp.c
- https://gerrit.zephyrproject.org/r/3689 : net: yaip: Set multicast dst address in ethernet if missing
- https://gerrit.zephyrproject.org/r/3688 : net: yaip: Add a utility to hexdump all fragments
- https://gerrit.zephyrproject.org/r/3684 : net: yaip: Add more checks when allocating nbuf
- https://gerrit.zephyrproject.org/r/3680 : net: yaip: Reserve ethernet ll header len in L2 ethernet 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/3685 : net: yaip: Refactored ARP packet header handling
- https://gerrit.zephyrproject.org/r/3682 : net: yaip: Add more debug print in ethernet RX side
- https://gerrit.zephyrproject.org/r/3681 : net: yaip: Add more debug checks when sending data in TX fiber
- https://gerrit.zephyrproject.org/r/3679 : net: yaip: IPv4 protocol type was not set to sent ARP packet
- https://gerrit.zephyrproject.org/r/3676 : net: yaip: Add utility function to return eth broadcast addr
- https://gerrit.zephyrproject.org/r/3675 : net: yaip: Add debugging support to ethernet L2 driver
- https://gerrit.zephyrproject.org/r/3677 : net: yaip: Both TX and RX fibers allow other fibers to run
- https://gerrit.zephyrproject.org/r/3674 : net: yaip: Calling net_buf_put() instead of nano_fifo_put()
- https://gerrit.zephyrproject.org/r/3673 : net: yaip: ARP reply did not set the address family
- https://gerrit.zephyrproject.org/r/3672 : net: yaip: Initializing the ll src and dst addresses
- https://gerrit.zephyrproject.org/r/3671 : net: yaip: Add ll reserve information to l2 driver
- https://gerrit.zephyrproject.org/r/3670 : slip: Fix the debug print
- https://gerrit.zephyrproject.org/r/3669 : net: yaip: Write ethernet header when using slip and tap
- https://gerrit.zephyrproject.org/r/3667 : net: yaip: Set IP protocol type when sending ethernet packet
- https://gerrit.zephyrproject.org/r/3659 : net: tests: Fix unit test for IP utils
- https://gerrit.zephyrproject.org/r/3654 : net: yaip: Depending on debug flags the stdio.h is not included
- 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/3658 : net: tests: Fix unit test for IP addresses
- https://gerrit.zephyrproject.org/r/3663 : net: yaip: Re-send ARP when needed
- https://gerrit.zephyrproject.org/r/3661 : net: yaip: Change how the L2 header space is reserved in net_buf
- https://gerrit.zephyrproject.org/r/3657 : net: yaip: Changed the IP and ll address debug prints
- https://gerrit.zephyrproject.org/r/3655 : net: yaip: Fix arp.h so that net_arp_init() is found
- https://gerrit.zephyrproject.org/r/3656 : net: tests: Fix unit test for ARP
- https://gerrit.zephyrproject.org/r/3652 : net: yaip: Network stack analyzer uses now the SYS_LOG sub-system
- https://gerrit.zephyrproject.org/r/3650 : net: yaip: The NET_DEBUG symbol must not be set in header file
- https://gerrit.zephyrproject.org/r/3649 : net: yaip: Use debugging net_buf unref function
- https://gerrit.zephyrproject.org/r/3653 : net: yaip: Print statistics using SYS_LOG
- https://gerrit.zephyrproject.org/r/3651 : net: yaip: Do not overwrite SYS_LOG_DOMAIN
- https://gerrit.zephyrproject.org/r/3648 : net: yaip: Process ICMPv6 packets only if IPv6 is enabled
- https://gerrit.zephyrproject.org/r/3647 : net: yaip: Refactor various network init functions
- https://gerrit.zephyrproject.org/r/3646 : net: yaip: Buffer leak if net_if_send_data() returns NET_DROP
- 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/3643 : net: tests: Add unit tests for neighbor cache
- https://gerrit.zephyrproject.org/r/3642 : net: yaip: Add a neighbor cache needed in IPv6
- https://gerrit.zephyrproject.org/r/3640 : net: yaip: Add IPv6 utilities for address manipulation
- https://gerrit.zephyrproject.org/r/3639 : net: yaip: Changing IPv4 address comparer to a function
- https://gerrit.zephyrproject.org/r/3637 : net: yaip: Add struct to store link layer address
- https://gerrit.zephyrproject.org/r/3624 : slip: Fix compiler warnings
- https://gerrit.zephyrproject.org/r/3604 : slip: Support TAP functionality
- https://gerrit.zephyrproject.org/r/3641 : net: yaip: Add IPv6 address network interface utilities
- https://gerrit.zephyrproject.org/r/3635 : net: yaip: Make sure that RX is started before TX
- https://gerrit.zephyrproject.org/r/3638 : net: yaip: Use const for static pre-defined IPv6 addresses
- https://gerrit.zephyrproject.org/r/3632 : net: yaip: Save some bytes on net_if logic
- https://gerrit.zephyrproject.org/r/3628 : net: yaip: Re-factor Kconfig and move ARP to a better place
- 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/3631 : net: yaip: Add NET_ASSERT() macro
- https://gerrit.zephyrproject.org/r/3630 : net: yaip: Tiny comment fix
- https://gerrit.zephyrproject.org/r/3626 : net: yaip: Make net_core.h include the least amount of necessary header
- https://gerrit.zephyrproject.org/r/3634 : net: yaip: Moved ARP helper macro to arp.h
- https://gerrit.zephyrproject.org/r/3629 : net: yaip: Removing capabilities() from net_if api
- https://gerrit.zephyrproject.org/r/3622 : net: yaip: The core initialize ARP layer relevantly
- https://gerrit.zephyrproject.org/r/3621 : net: debug: Indent properly some config options.
- https://gerrit.zephyrproject.org/r/3620 : net: yaip: Include toolchain related header for aliases
- https://gerrit.zephyrproject.org/r/3619 : net: yaip: Use generic wrapper for semaphore give operation
- https://gerrit.zephyrproject.org/r/3606 : net: yaip: Only accept ARP reply if we requested data
- https://gerrit.zephyrproject.org/r/3617 : net: yaip: Add UDP header
- https://gerrit.zephyrproject.org/r/3616 : net: yaip: Trivial comment fixes in header files
- https://gerrit.zephyrproject.org/r/3615 : net: yaip: Setting static IP addresses for echo-server
- https://gerrit.zephyrproject.org/r/3614 : net: yaip: Handle ARP messages
- 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/3603 : net: tests: Unit tests for IPv4 ARP code
- https://gerrit.zephyrproject.org/r/3609 : net: tests: Fixed the ARP test
- https://gerrit.zephyrproject.org/r/3607 : net: yaip: Make echo-server to use documentation IPv4 addresses
- https://gerrit.zephyrproject.org/r/3605 : net: yaip: Setting preferred status to manually added IPv4 address
- https://gerrit.zephyrproject.org/r/3608 : net: yaip: Use net_nbuf_ll() macro to get into arp header
- https://gerrit.zephyrproject.org/r/3602 : net: yaip: Added IPv4 ARP support
- https://gerrit.zephyrproject.org/r/3599 : net: yaip: Add util to check if IPv4 address is part of subnet
- https://gerrit.zephyrproject.org/r/3601 : net: tests: Add tests for IPv4 netmask, gw and subnet compare
- https://gerrit.zephyrproject.org/r/3600 : net: yaip: Add capabilities flag to net_if API
- https://gerrit.zephyrproject.org/r/3598 : net: yaip: Add utils to set IPv4 netmask and gateway in net_if
- https://gerrit.zephyrproject.org/r/3597 : net: yaip: Macro to compare two IPv4 addresses
- 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/3591 : net: yaip: Process received ICMPv4 messages
- https://gerrit.zephyrproject.org/r/3595 : net: yaip: Add utility function returning IPv4 broadcast address
- 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/3592 : net: yaip: Add utility function to return default network interface
- https://gerrit.zephyrproject.org/r/3589 : net: yaip: Add unit tests for ICMPv6 handler
- https://gerrit.zephyrproject.org/r/4092 : Bluetooth: eddystone: Add timeout to deactivate configuration mode
- https://gerrit.zephyrproject.org/r/3588 : net: yaip: Add ICMPv6 handler
- https://gerrit.zephyrproject.org/r/3587 : net: tests: Unit tests for network utilities
- https://gerrit.zephyrproject.org/r/3584 : net: yaip: Add net_hexdump() utility to print network data
- https://gerrit.zephyrproject.org/r/3994 : Bluetooth: Add RAW interface to Bluetooth
- https://gerrit.zephyrproject.org/r/4029 : AVDTP Module Changes
- https://gerrit.zephyrproject.org/r/3947 : sanitycheck: support for multiple toolchain
- https://gerrit.zephyrproject.org/r/4083 : soc: Use nrf.h instead of nrf52.h and nrf52_bitfields.h

MERGED within last 24 hours:
- https://gerrit.zephyrproject.org/r/4099 : ext qmsi: Fix broken built-in qmsi build
- https://gerrit.zephyrproject.org/r/4109 : Merge remote-tracking branch 'origin/master' into net
- https://gerrit.zephyrproject.org/r/4065 : samples: net: loopback_test: build for sanitycheck runs
- https://gerrit.zephyrproject.org/r/4063 : samples: environmental_sensing: build for sanitycheck runs
- https://gerrit.zephyrproject.org/r/4064 : samples: power: quark_se: build for sanitycheck runs
- https://gerrit.zephyrproject.org/r/4067 : samples: pci_enum: build for sanitycheck
- https://gerrit.zephyrproject.org/r/4069 : samples: sx9500: build for sanitycheck
- https://gerrit.zephyrproject.org/r/4061 : samples: stub: build for sanitycheck runs
- https://gerrit.zephyrproject.org/r/4070 : samples: tmp112: build for sanitycheck
- https://gerrit.zephyrproject.org/r/4060 : samples: hello_world: build for sanitycheck runs
- https://gerrit.zephyrproject.org/r/4072 : samples: mcp9808: build for sanitycheck runs
- https://gerrit.zephyrproject.org/r/4068 : samples: magn_polling: build for sanitycheck
- https://gerrit.zephyrproject.org/r/4071 : samples: bme280: build for sanitycheck runs
- https://gerrit.zephyrproject.org/r/4066 : samples: net: zperf: build for sanitycheck runs
- https://gerrit.zephyrproject.org/r/4062 : samples: shell: build for sanitycheck runs


printf shrinkery

Andy Ross
 

Inspired by the printf discussion last week and no one's explicit
rejection of a quick code-size-reduction patch I threw out, I spent a
little more time in the minimal libc printf implementation, finding
stuff that can be removed or unified. Patch series in gerrit:

https://gerrit.zephyrproject.org/r/4007 libc/printf: Unify & simplify number printing
https://gerrit.zephyrproject.org/r/4102 libc/printf: Remove vestigial "full" parameter to _to_float()
https://gerrit.zephyrproject.org/r/4103 libc/printf: Use compiler-provided 64 bit math, phase 1
https://gerrit.zephyrproject.org/r/4104 libc/printf: Use compiler-provided 64 bit math, phase 2

There's the unified number-formatting code from before, and I
discovered that the floating point generation had a hand-coded 64 bit
math implementation that can be pretty easily replaced with
compiler-provied uint64_t math. Still passes sanitycheck, which
includes our existing sprintf test, plus all the stuff I could find or
hack to use as a unit test. Please review.

Total code savings for the whole patch series is ~400 bytes with no
loss of functionality, so not earthshattering but IMHO worth it. And
floating point output is almost certainly significantly faster, though
unmeasured.

Andy


Re: How to directly dertermine the initialization sequence of all devices

Dmitriy Korovkin
 

On Sun, 14 Aug 2016, Tidy Jiang wrote:


Hi All,

I know that devices' initialization sequence is dertermined by its level and
priority, but it's  difficult to peek those information in enormous code,
especially many devices are included.

So, Is there a way to directly, conveniently get the devices' initialization
sequence?
The way I know looks like this:
grep INIT_PRIORITY outdir/.config

CONFIG_KERNEL_INIT_PRIORITY_DEFAULT is usually the highest usable
priority, CONFIG_KERNEL_INIT_PRIORITY_DEVICE is the priority that devices
usually initialize at. If a device uses something different, it is
specified there.

Regards,
Dmitriy


Daily Gerrit Digest

donotreply@...
 

NEW within last 24 hours:
- 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/4088 : Bluetooth: Controller: Initial impl. of a HCI controller-side interface
- https://gerrit.zephyrproject.org/r/4087 : Bluetooth: Controller: Add a util folder with basic primitives
- https://gerrit.zephyrproject.org/r/4091 : board: nrf52_pca10040: Include native Link Layer by default
- https://gerrit.zephyrproject.org/r/4086 : Bluetooth: Controller: Hardware abstraction layer for nRF5x radio
- https://gerrit.zephyrproject.org/r/4085 : soc: Use nrf.h instead of nrf52.h and nrf52_bitfields.h
- https://gerrit.zephyrproject.org/r/4093 : Bluetooth: Enable SOC FLASH
- https://gerrit.zephyrproject.org/r/4094 : Bluetooth: Use correct buffers sizes
- https://gerrit.zephyrproject.org/r/4092 : Bluetooth: eddystone: Add timeout to deactivate configuration mode
- https://gerrit.zephyrproject.org/r/4083 : soc: Use nrf.h instead of nrf52.h and nrf52_bitfields.h
- 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/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/4076 : enc28j60: hardware errata #6 PKTIF is unreliable

UPDATED within last 24 hours:
- 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/3532 : net: yaip: Initial commit for the new IP stack
- https://gerrit.zephyrproject.org/r/3768 : net: apps: Fix echo-server to use the new user API
- https://gerrit.zephyrproject.org/r/3594 : net: yaip: Do not remove fragments if main buffer is not removed
- https://gerrit.zephyrproject.org/r/3599 : net: yaip: Add util to check if IPv4 address is part of subnet
- https://gerrit.zephyrproject.org/r/4042 : net: yaip: 6lo uncompression should continue to proceed after src addr
- https://gerrit.zephyrproject.org/r/3597 : net: yaip: Macro to compare two IPv4 addresses
- https://gerrit.zephyrproject.org/r/3619 : net: yaip: Use generic wrapper for semaphore give operation
- https://gerrit.zephyrproject.org/r/3626 : net: yaip: Make net_core.h include the least amount of necessary header
- https://gerrit.zephyrproject.org/r/3587 : net: tests: Unit tests for network utilities
- https://gerrit.zephyrproject.org/r/3598 : net: yaip: Add utils to set IPv4 netmask and gateway in net_if
- https://gerrit.zephyrproject.org/r/3634 : net: yaip: Moved ARP helper macro to arp.h
- https://gerrit.zephyrproject.org/r/3593 : net: tests: Tweak the IP address test to use new net_if API
- https://gerrit.zephyrproject.org/r/3591 : net: yaip: Process received ICMPv4 messages
- https://gerrit.zephyrproject.org/r/3601 : net: tests: Add tests for IPv4 netmask, gw and subnet compare
- https://gerrit.zephyrproject.org/r/3596 : net: yaip: net_ipaddr_copy() macro was too fragile
- https://gerrit.zephyrproject.org/r/3590 : net: yaip: Process received ICMPv6 messages
- https://gerrit.zephyrproject.org/r/3604 : slip: Support TAP functionality
- https://gerrit.zephyrproject.org/r/3588 : net: yaip: Add ICMPv6 handler
- https://gerrit.zephyrproject.org/r/3648 : net: yaip: Process ICMPv6 packets only if IPv6 is enabled
- https://gerrit.zephyrproject.org/r/3589 : net: yaip: Add unit tests for ICMPv6 handler
- https://gerrit.zephyrproject.org/r/3586 : net: yaip: Add debugging option for network utilities
- https://gerrit.zephyrproject.org/r/3595 : net: yaip: Add utility function returning IPv4 broadcast address
- https://gerrit.zephyrproject.org/r/3618 : net: yaip: Fix __packed attribute, use shorter alias
- https://gerrit.zephyrproject.org/r/3592 : net: yaip: Add utility function to return default network interface
- https://gerrit.zephyrproject.org/r/3613 : net: tests: Additional tests for ICMPv4 checksum verification
- https://gerrit.zephyrproject.org/r/3544 : net: yaip: Add function that feeds data to RX fifo
- https://gerrit.zephyrproject.org/r/3777 : net: yaip: No need to swap ll address in IPv6 module
- https://gerrit.zephyrproject.org/r/3609 : net: tests: Fixed the ARP test
- https://gerrit.zephyrproject.org/r/3608 : net: yaip: Use net_nbuf_ll() macro to get into arp header
- https://gerrit.zephyrproject.org/r/3602 : net: yaip: Added IPv4 ARP support
- https://gerrit.zephyrproject.org/r/3607 : net: yaip: Make echo-server to use documentation IPv4 addresses
- https://gerrit.zephyrproject.org/r/3605 : net: yaip: Setting preferred status to manually added IPv4 address
- https://gerrit.zephyrproject.org/r/3603 : net: tests: Unit tests for IPv4 ARP code
- https://gerrit.zephyrproject.org/r/4024 : Bluetooth: Set BR/EDR device name on init
- https://gerrit.zephyrproject.org/r/3600 : net: yaip: Add capabilities flag to net_if API
- https://gerrit.zephyrproject.org/r/3606 : net: yaip: Only accept ARP reply if we requested data
- https://gerrit.zephyrproject.org/r/3660 : net: yaip: Make sure that either IPv4 or IPv6 gets selected
- https://gerrit.zephyrproject.org/r/3635 : net: yaip: Make sure that RX is started before TX
- https://gerrit.zephyrproject.org/r/3671 : net: yaip: Add ll reserve information to l2 driver
- https://gerrit.zephyrproject.org/r/3548 : net: yaip: Fix compilation error in net_if.h
- https://gerrit.zephyrproject.org/r/3584 : net: yaip: Add net_hexdump() utility to print network data
- https://gerrit.zephyrproject.org/r/3583 : net: yaip: Network interface needs own TX fiber stack
- https://gerrit.zephyrproject.org/r/3582 : net: yaip: Add net_send_data() that sends data to network
- https://gerrit.zephyrproject.org/r/3578 : net: yaip: Add ICMP protocol header struct
- 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/3576 : net: yaip: Receive IPv4 packet
- https://gerrit.zephyrproject.org/r/3579 : net: yaip: Move IP address print funcs to separate file
- https://gerrit.zephyrproject.org/r/3577 : net: yaip: Added API documentation to IP address check functions
- https://gerrit.zephyrproject.org/r/3575 : net: yaip: Network interface code compiles ok for IPv4 and IPv6
- 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/3572 : net: tests: Add IPv4 address unit tests
- https://gerrit.zephyrproject.org/r/3571 : net: yaip: Add IPv4 addresses to network interface
- https://gerrit.zephyrproject.org/r/3567 : net: yaip: Add utility func to return IP address type as a string
- 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/3585 : net: yaip: Add IP packet checksum calculation utilities
- https://gerrit.zephyrproject.org/r/3566 : net: yaip: Drop received source mcast IPv6 packets
- https://gerrit.zephyrproject.org/r/3565 : net: yaip: Receive IPv6 packet
- https://gerrit.zephyrproject.org/r/3563 : net: yaip: Add debug function to print IP address
- https://gerrit.zephyrproject.org/r/3564 : net: tests: Add unit test for IP and MAC address printing
- 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/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/3550 : net: yaip: Add Kconfig option for compiling IPv6 support
- 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/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/3549 : net: yaip: Add net_analyze_stack() macro
- 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/3547 : slip: Add driver for host to qemu connectivity
- 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/3543 : net: yaip: Refactored RX fiber init
- https://gerrit.zephyrproject.org/r/3542 : net: yaip: Add TX fifo to network interface
- https://gerrit.zephyrproject.org/r/3539 : net: yaip: Add network address information to interface
- https://gerrit.zephyrproject.org/r/3537 : net: Add generic network interface header
- https://gerrit.zephyrproject.org/r/3538 : net: yaip: apps: Create a skeleton echo-server for new IP stack
- https://gerrit.zephyrproject.org/r/3535 : net: yaip: Use same prefix in new IP stack Kconfig
- https://gerrit.zephyrproject.org/r/3534 : net: yaip: Add ntohl() and related macros
- 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/3536 : net: yaip: Compile new stack if enabled
- https://gerrit.zephyrproject.org/r/4046 : net: yaip: Integrate 6lo compression support in IEEE 802.15.4 L2 stack
- https://gerrit.zephyrproject.org/r/4043 : net: yaip: 6lo: Grab uncompressed header type relevantly
- https://gerrit.zephyrproject.org/r/4041 : net: yaip: Add debug message on IPv6 preliminary check
- https://gerrit.zephyrproject.org/r/3533 : net: yaip: Add defines for various IP protocol header lengths
- https://gerrit.zephyrproject.org/r/4045 : net: yaip: ieee802154: Handle plain/compressed ll addr relevantly
- https://gerrit.zephyrproject.org/r/4044 : net: yaip: Add more debugging messages into 6lo
- https://gerrit.zephyrproject.org/r/4040 : net: yaip: Add debug messages on drop reasons
- https://gerrit.zephyrproject.org/r/4039 : net: yaip: Handle LL part in 6lo logic when relevant
- https://gerrit.zephyrproject.org/r/4033 : net: yaip: SYS_INIT() routines are never ran twice
- https://gerrit.zephyrproject.org/r/4038 : net: yaip: Built IEEE 802.15.4 fragmentation logic if requested only
- https://gerrit.zephyrproject.org/r/4037 : net: yaip: Follow file naming in ieee802154 l2 stack
- https://gerrit.zephyrproject.org/r/4035 : samples: ieee802154: Debugging needs a new Kconfig option
- https://gerrit.zephyrproject.org/r/4032 : net: yaip: net_if section should be always aligned
- https://gerrit.zephyrproject.org/r/4036 : net: yaip: Giving an uncompressed buffer to 6lo is not an error
- https://gerrit.zephyrproject.org/r/4034 : net: yaip: ieee802154: Logging header should be loaded first
- 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/3873 : net: tests: Fix the context unit test
- https://gerrit.zephyrproject.org/r/3839 : net: yaip: Modify NET6LO_ defines to NET_6LO
- https://gerrit.zephyrproject.org/r/3838 : net: tests: Add fragmentation unit tests
- https://gerrit.zephyrproject.org/r/3837 : net: yaip: Add support for IEEE 802.15.4 reassembly
- https://gerrit.zephyrproject.org/r/3836 : net: yaip: Integrate 6lowpan 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/3833 : net: yaip: Fix wrong UDP length calculation in 6lo compression
- https://gerrit.zephyrproject.org/r/3834 : net: tests: Add unit tests for 6lo IPv6 dispatch support
- 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's returned parameter
- 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/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/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/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 in IPv6 cache
- https://gerrit.zephyrproject.org/r/3821 : net: yaip: Add network interface to neighbor creation call
- https://gerrit.zephyrproject.org/r/3820 : net: yaip: Add more debugging prints to IPv6 ND handling
- https://gerrit.zephyrproject.org/r/3819 : net: yaip: Add debug helper for neighbor tables
- 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/3815 : net: yaip: Wrong pointer was used when setting router status
- https://gerrit.zephyrproject.org/r/4028 : Bluetooth: ATT: Make it safe to access the request list
- 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/4027 : Bluetooth: GATT: Add queuing support
- 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/3807 : net: yaip: Fix the debug prints in echo-server
- 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/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/3803 : drivers: cc2520: Make current driver for legacy stack only
- 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/3804 : drivers: cc2520: Add a new IP stack ready adaptation of CC2520 driver
- https://gerrit.zephyrproject.org/r/3802 : tests: net: Add a IEEE 802.15.4 ACK replies test
- 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/3790 : net: yaip: l2 layer reserve size might need extra parameter
- 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/3791 : net: yaip: Add documentation to net_l2 header file.
- https://gerrit.zephyrproject.org/r/3792 : net: yaip: Add some debug message on net_if
- 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/3783 : net: yaip: Fix IPv6 NS packet size check
- 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 neighbour from an IPv6 address
- 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/3782 : net: yaip: Add IPv6 ND statistics when relevant
- https://gerrit.zephyrproject.org/r/3779 : net: yaip: Ethernet driver needs to set ll address
- https://gerrit.zephyrproject.org/r/3778 : net: yaip: IPv6 neighbor was not properly added to cache
- https://gerrit.zephyrproject.org/r/3776 : net: yaip: Update UDP sent packet statistics
- https://gerrit.zephyrproject.org/r/3774 : net: yaip: Check packet sending status correctly in arp.c
- https://gerrit.zephyrproject.org/r/3772 : net: yaip: Call send callback in net_context properly
- https://gerrit.zephyrproject.org/r/3770 : net: yaip: Check IPv6 NS, NA and RA messages for corruption
- https://gerrit.zephyrproject.org/r/3775 : net: yaip: nbuf variables needs clearing when allocating nbuf
- https://gerrit.zephyrproject.org/r/3773 : net: yaip: Call net_context send callback when packet is sent
- https://gerrit.zephyrproject.org/r/3771 : net: yaip: Add token to nbuf
- https://gerrit.zephyrproject.org/r/3769 : net: yaip: Rename ip_protocol to net_ip_protocol
- 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/3764 : net: yaip: Resolve LL address for IPv6 packet in ethernet L2 driver
- https://gerrit.zephyrproject.org/r/3765 : net: yaip: Use proper ll header length when sending IPv6 NS
- https://gerrit.zephyrproject.org/r/3763 : net: yaip: Do IPv6 ND if LL address is not known when sending
- https://gerrit.zephyrproject.org/r/3760 : slip: Do not send ethernet header if mtu is large enough
- https://gerrit.zephyrproject.org/r/3757 : net: yaip: Create IPv4, IPv6 and UDP packets when needed
- 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/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/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/3740 : net: yaip: Utility to get net_if according to index value
- https://gerrit.zephyrproject.org/r/3753 : net: yaip: Add user space API to net_context
- 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/3734 : net: yaip: Add initial 6lowpan IPHC compression support.
- https://gerrit.zephyrproject.org/r/3752 : net: yaip: Increasing the default IPv6 unicast addr count
- https://gerrit.zephyrproject.org/r/3749 : net: yaip: Add helpers for getting protocol specific sockaddr
- https://gerrit.zephyrproject.org/r/3732 : net: yaip: Add support for 802.15.4 short address for iid creation
- 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/3742 : net: yaip: Protocol family needs to be set for multicast address
- 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 wrong ll address length
- https://gerrit.zephyrproject.org/r/3743 : net: yaip: Making IP address const in utility func
- https://gerrit.zephyrproject.org/r/3741 : net: tests: udp: Print debug information only when activated
- 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/3733 : net: yaip: Add utility to verify given addr based on ll
- 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/3726 : net: Refine Kconfig to put NET_BUF appart
- https://gerrit.zephyrproject.org/r/3722 : net: yaip: Debugging function to print fragment chain information
- https://gerrit.zephyrproject.org/r/3728 : net: yaip: Let's use inline function for type checking for net_nbuf
- https://gerrit.zephyrproject.org/r/3727 : net: yaip: Moving header files to include/net/yaip
- https://gerrit.zephyrproject.org/r/3725 : samples: Fix echo_server for YAIP
- https://gerrit.zephyrproject.org/r/3723 : sanitycheck: Fix YAIP testcase.ini files
- https://gerrit.zephyrproject.org/r/3724 : sanitycheck: Recognize YAIP specific sections
- https://gerrit.zephyrproject.org/r/3721 : net: yaip: Refactor nbuf.h and nbuf.c
- 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 test was missing random number config
- https://gerrit.zephyrproject.org/r/3717 : net: yaip: Fix compilation when IPv6 is disabled
- https://gerrit.zephyrproject.org/r/3716 : net: yaip: Refactored IPv6 DAD and ND activation
- 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() function
- https://gerrit.zephyrproject.org/r/3713 : net: yaip: Utility that inserts free space to the fragment list
- https://gerrit.zephyrproject.org/r/3712 : net: yaip: Utility function to compact net_buf fragments
- https://gerrit.zephyrproject.org/r/3711 : net: tests: Fix ARP test so that it will not crash
- https://gerrit.zephyrproject.org/r/3710 : net: tests: Unit tests for UDP handler
- https://gerrit.zephyrproject.org/r/3706 : net: yaip: Add support for ICMPv4 error message
- 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/3707 : net: yaip: Generic connection handler for UDP and TCP
- https://gerrit.zephyrproject.org/r/3685 : net: yaip: Refactored ARP packet header handling
- https://gerrit.zephyrproject.org/r/3705 : net: yaip: Add support for ICMPv6 error message
- 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/3704 : net: yaip: Add IPv6 minimum MTU value
- https://gerrit.zephyrproject.org/r/3703 : net: yaip: Make some IPv6 utility functions to use const addr
- https://gerrit.zephyrproject.org/r/3700 : net: yaip: Add net_nbuf_copy() utility function
- https://gerrit.zephyrproject.org/r/3697 : net: yaip: Initial router advertisement support
- https://gerrit.zephyrproject.org/r/3699 : net: Kconfig: Refactor Kconfig menus for better clarity
- 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/3695 : net: yaip: Initial IPv6 neighbor discovery support
- https://gerrit.zephyrproject.org/r/3693 : slip: Do not try to unref a null pointer
- https://gerrit.zephyrproject.org/r/3692 : net: yaip: Start the network stack after device drivers
- https://gerrit.zephyrproject.org/r/3691 : slip: Network stack needs to be up before sending data to it
- https://gerrit.zephyrproject.org/r/3690 : net: yaip: Remove extra debug print in ethernet L2 driver
- https://gerrit.zephyrproject.org/r/3689 : net: yaip: Set multicast dst address in ethernet if missing
- https://gerrit.zephyrproject.org/r/3683 : net: yaip: Ethernet L2 TX side needs to setup fragments
- https://gerrit.zephyrproject.org/r/3688 : net: yaip: Add a utility to hexdump all fragments
- 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/3684 : net: yaip: Add more checks when allocating nbuf
- https://gerrit.zephyrproject.org/r/3682 : net: yaip: Add more debug print in ethernet RX side
- https://gerrit.zephyrproject.org/r/3681 : net: yaip: Add more debug checks when sending data in TX fiber
- https://gerrit.zephyrproject.org/r/3680 : net: yaip: Reserve ethernet ll header len in L2 ethernet driver
- https://gerrit.zephyrproject.org/r/3679 : net: yaip: IPv4 protocol type was not set to sent ARP packet
- https://gerrit.zephyrproject.org/r/3678 : net: yaip: Add more debugging to arp.c
- https://gerrit.zephyrproject.org/r/3677 : net: yaip: Both TX and RX fibers allow other fibers to run
- https://gerrit.zephyrproject.org/r/3676 : net: yaip: Add utility function to return eth broadcast addr
- https://gerrit.zephyrproject.org/r/3675 : net: yaip: Add debugging support to ethernet L2 driver
- https://gerrit.zephyrproject.org/r/3674 : net: yaip: Calling net_buf_put() instead of nano_fifo_put()
- https://gerrit.zephyrproject.org/r/3673 : net: yaip: ARP reply did not set the address family
- 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/3669 : net: yaip: Write ethernet header when using slip and tap
- https://gerrit.zephyrproject.org/r/3667 : net: yaip: Set IP protocol type when sending ethernet packet
- https://gerrit.zephyrproject.org/r/3668 : net: yaip: Make sure ethernet l2 sets src and dst addresses
- 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/3662 : net: yaip: Add utility to remove ipv4 address from iface
- https://gerrit.zephyrproject.org/r/3664 : net: yaip: Add ethernet address helpers
- https://gerrit.zephyrproject.org/r/3663 : net: yaip: Re-send ARP when needed
- https://gerrit.zephyrproject.org/r/3661 : net: yaip: Change how the L2 header space is reserved in net_buf
- https://gerrit.zephyrproject.org/r/3659 : net: tests: Fix unit test for IP utils
- https://gerrit.zephyrproject.org/r/3658 : net: tests: Fix unit test for IP addresses
- https://gerrit.zephyrproject.org/r/3657 : net: yaip: Changed the IP and ll address debug prints
- https://gerrit.zephyrproject.org/r/3656 : net: tests: Fix unit test for ARP
- https://gerrit.zephyrproject.org/r/3655 : net: yaip: Fix arp.h so that net_arp_init() is found
- https://gerrit.zephyrproject.org/r/3654 : net: yaip: Depending on debug flags the stdio.h is not included
- https://gerrit.zephyrproject.org/r/3649 : net: yaip: Use debugging net_buf unref function
- 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/3651 : net: yaip: Do not overwrite SYS_LOG_DOMAIN
- https://gerrit.zephyrproject.org/r/3650 : net: yaip: The NET_DEBUG symbol must not be set in header file
- https://gerrit.zephyrproject.org/r/3647 : net: yaip: Refactor various network init functions
- https://gerrit.zephyrproject.org/r/3645 : net: yaip: No need to do ARP for IPv6 network packet
- https://gerrit.zephyrproject.org/r/3646 : net: yaip: Buffer leak if net_if_send_data() returns NET_DROP
- https://gerrit.zephyrproject.org/r/3644 : net: yaip: The IP protocol type needs to be set in L2 layer
- https://gerrit.zephyrproject.org/r/3642 : net: yaip: Add a neighbor cache needed in IPv6
- https://gerrit.zephyrproject.org/r/3643 : net: tests: Add unit tests for neighbor cache
- https://gerrit.zephyrproject.org/r/3641 : net: yaip: Add IPv6 address network interface utilities
- https://gerrit.zephyrproject.org/r/3638 : net: yaip: Use const for static pre-defined IPv6 addresses
- https://gerrit.zephyrproject.org/r/3637 : net: yaip: Add struct to store link layer address
- https://gerrit.zephyrproject.org/r/3640 : net: yaip: Add IPv6 utilities for address manipulation
- https://gerrit.zephyrproject.org/r/3639 : net: yaip: Changing IPv4 address comparer to a function
- https://gerrit.zephyrproject.org/r/3636 : net: yaip: Print available DATA buffers during nbuf alloc
- https://gerrit.zephyrproject.org/r/3633 : net: yaip: Add comment explaining net_core's verdict values
- https://gerrit.zephyrproject.org/r/3632 : net: yaip: Save some bytes on net_if logic
- https://gerrit.zephyrproject.org/r/3631 : net: yaip: Add NET_ASSERT() macro
- https://gerrit.zephyrproject.org/r/3630 : net: yaip: Tiny comment fix
- https://gerrit.zephyrproject.org/r/3629 : net: yaip: Removing capabilities() from net_if api
- https://gerrit.zephyrproject.org/r/3628 : net: yaip: Re-factor Kconfig and move ARP to a better place
- https://gerrit.zephyrproject.org/r/3627 : net: yaip: Add an L2 layer
- 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/3624 : slip: Fix compiler warnings
- https://gerrit.zephyrproject.org/r/3623 : net: yaip: Shorten IPv4/6 config options
- https://gerrit.zephyrproject.org/r/3622 : net: yaip: The core initialize ARP layer relevantly
- https://gerrit.zephyrproject.org/r/3621 : net: debug: Indent properly some config options.
- https://gerrit.zephyrproject.org/r/3620 : net: yaip: Include toolchain related header for aliases
- https://gerrit.zephyrproject.org/r/3617 : net: yaip: Add UDP header
- https://gerrit.zephyrproject.org/r/3616 : net: yaip: Trivial comment fixes in header files
- https://gerrit.zephyrproject.org/r/3615 : net: yaip: Setting static IP addresses for echo-server
- https://gerrit.zephyrproject.org/r/3612 : net: yaip: ICMPv4 checksum calculation fixed
- https://gerrit.zephyrproject.org/r/3614 : net: yaip: Handle ARP messages
- 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/4030 : AVDTP Module Changes
- https://gerrit.zephyrproject.org/r/3788 : misc: Add an helper for memory alignement

MERGED within last 24 hours:
- https://gerrit.zephyrproject.org/r/4082 : Merge remote-tracking branch 'origin/master' into net
- https://gerrit.zephyrproject.org/r/4000 : ext qmsi: Update to QMSI 1.1.0 release
- https://gerrit.zephyrproject.org/r/4051 : Bluetooth: SMP: Add helper for notifying pairing complete
- https://gerrit.zephyrproject.org/r/4073 : Merge master branch into bluetooth


BLE Link Layer

Carles Cufi
 

Hi all,

We have just posted an initial port of Vinayak Chettimada's BLE Link Layer implementation (internally known as Phoenix) to Gerrit.

This is currently functional on nRF5x devices (nRF52 only since the Cortex-M0 based nRF51 lacks Zephyr support for now) and implements most of the Bluetooth 4.2 specification. By posting those patches we hope to get feedback from the community and progress towards integrating the Link Layer code more tightly into the Zephyr core services and infrastructure.

Please note that this is *not* the Nordic official Link Layer implementation shipping with our SDKs, but rather one written from scratch by Vinayak. This means that, although it passes most conformance tests, it has not gone through qualification.

The patches allow an nRF52-based board running Zephyr to act as a standalone BLE SoC, running Zephyr applications using BLE on a single chip.

https://jira.zephyrproject.org/browse/ZEP-702

https://gerrit.zephyrproject.org/r/#/c/4086/
https://gerrit.zephyrproject.org/r/#/c/4087/
https://gerrit.zephyrproject.org/r/#/c/4088/
https://gerrit.zephyrproject.org/r/#/c/4089/
https://gerrit.zephyrproject.org/r/#/c/4090/

Regards,

Carles


Re: [RFC] Power Management Infrastructure

Kaplan, Amir
 

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 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.


Daily JIRA Digest

donotreply@...
 

NEW JIRA items within last 24 hours: 0

UPDATED JIRA items within last 24 hours: 0

CLOSED JIRA items within last 24 hours: 0

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


Daily Gerrit Digest

donotreply@...
 

NEW within last 24 hours:

UPDATED within last 24 hours:

MERGED within last 24 hours:


How to directly dertermine the initialization sequence of all devices

Tidy(ChunHua) Jiang <tidyjiang@...>
 

Hi All,

I know that devices' initialization sequence is dertermined by its level
and priority, but it's difficult to peek those information in enormous
code, especially many devices are included.

So, Is there a way to *directly*, *conveniently* get the devices'
initialization sequence?

If yes, could you tell me how to do ? If no, any ideas to implement this
function?

Thx!

Tidy Jiang.


Re: how to view the documents as in .rst fomat

Kinder, David B <david.b.kinder@...>
 

Out of curiosity, why do you want to read the ReST files directly instead of the nicely formatted and indexed documentation posted online at https://www.zephyrproject.org/doc/ ?


Zephyr v1.5.0-rc2 tagged

Perez-Gonzalez, Inaky <inaky.perez-gonzalez@...>
 

Hello All

New RC tagged. Thank you for your contributions-we are getting closer to a release, with 48 new fixes

Please remember for rc3 to keep it only for fixes; please consider:


- If your commit can go to 1.6 (if such, please issue a topic 1.6-SOMETHING, so we can tell it apart)

- Indicate in the commit message why this is a 1.5 fix

- Keep them small!

Enjoy your weekend!

Andrei Emeltchenko (5):
usb: Add Bluetooth class codes definitions
usb: Fix incorrect macro assignment
usb: Fix compile error with debug enabled
usb: Add error log to help debugging
Bluetooth: trivial: Remove extra line

Andrew Boie (8):
Revert "ext: qmsi: disable tx empty interrupt at the end of rx transfer"
Revert "ext qmsi: Update to QMSI 1.1.0 release"
em9d: em11d: fix broken build
sanitycheck: arc.ini: add em_starterkit to sanity runs
arc: em11d: em9d: set SPI_DW_IRQ_FLAGS
samples: test_15_4: fix build warning
uart.h: fix path to PCI headers
samples: ipm_demo: build for sanitycheck runs

Andy Ross (2):
tests/kernel/{test_task,test_sleep}: Less aggressive timer testing
test_sleep: More latency workarounds

Baohong Liu (5):
drivers: spi: Update comment for spi config parameter
drivers: adc: Correct an error in Kconfig
ext: qmsi: disable tx empty interrupt at the end of rx transfer
drivers: i2c: Fix i2c failure on multiple slaves
ext: qmsi: disable tx empty interrupt at the end of rx transfer

Bogdan Davidoaia (1):
sensor: hmc5883l: fix data sample axis order

Evan Couzens (1):
doc: Terminology--Replace 'platform' with 'board'

Flavio Santes (5):
crypto/tinycrypt: Update README file
mqtt: fix: pinreq handler function exit condition
mqtt: fix: Eliminate redundant lines by using a common exit point
mqtt: fix: Remove ping function call
samples/net: Update README file w.r.t compiler warnings

Genaro Saucedo Tejada (1):
sanity: non utf-8 characters are tolerated

Inaky Perez-Gonzalez (1):
samples/net/loopback_test: fix testcase markup

Jaakko Hannikainen (2):
net: contiki: Fix timer callback condition
net: Add NULL check to eventhandler

Javier B Perez (1):
checkpatch: add ignore for net/ip/contiki directory

Johan Hedberg (1):
mailmap: Fix broken author information for Evan Couzens

Juan Manuel Cruz (1):
event logger: reduce sample application's RAM footprint

Kumar Gala (1):
arm: Add support for both floating point ABIs

Kuo-Lang Tseng (2):
ext qmsi: Update to QMSI 1.1.0 release
ext qmsi: Update to QMSI 1.1.0 release

Leyi Rong (2):
net: net_context: Fix local ipv4 addr compare with INADDR_ANY
net: uip: Fix uip_udp_conns traverse loop in uip_process

Ravi kumar Veeramally (2):
net: samples: Fix RFC3849 address config option.
net: samples: Fix Rx buffers count.

Szymon Janc (7):
Bluetooth: tester: Fix extra new lines
Bluetooth: tester: Use SYS_LOG_ERR instead of printk
Bluetooth: SMP: Fix non-ASCII characters in comments
Revert "Bluetooth: SMP: Workaround LE SC bug in iOS"
Bluetooth: Remove redundant ifdefs from keys.h
Bluetooth: Remove not needed BT_KEYS_BR_LEGACY flag
Bluetooth: Fix typos in code comments