Date   

Re: Impending gerrit restart / reconfiguration (Zephyr)

Andrew Grimberg <agrimberg@...>
 

Sorry, I forgot to mention what project this is for. This change will be
happening to the Zephyr Jenkins / Gerrit CI.

-Andy-

On 09/13/2016 02:57 PM, Andrew Grimberg wrote:
What: The Linux Foundation will be changing the maximum connection
settings for Gerrit

When: ASAP (we're waiting on jobs to clear Jenkins first)

Why: Many jobs in Jenkins are presently failing due to Gerrit stating
that there are too many open connections. This usually happens when far
too many Jenkins jobs fire at the exact same time. We will be increasing
the maximum connection count to try to get around the problem.

Impact: Jenkins will not be building during the outage and Gerrit will
be offline for up to 30 minutes as the reconfiguration happens and
Gerrit restarts.

-Andy-
--
Andrew J Grimberg
Systems Administrator
Release Engineering Team Lead
The Linux Foundation


Impending gerrit restart / reconfiguration

Andrew Grimberg <agrimberg@...>
 

What: The Linux Foundation will be changing the maximum connection
settings for Gerrit

When: ASAP (we're waiting on jobs to clear Jenkins first)

Why: Many jobs in Jenkins are presently failing due to Gerrit stating
that there are too many open connections. This usually happens when far
too many Jenkins jobs fire at the exact same time. We will be increasing
the maximum connection count to try to get around the problem.

Impact: Jenkins will not be building during the outage and Gerrit will
be offline for up to 30 minutes as the reconfiguration happens and
Gerrit restarts.

-Andy-

--
Andrew J Grimberg
Systems Administrator
Release Engineering Team Lead
The Linux Foundation


Re: [RFC] SPI API update

Liu, Baohong
 

-----Original Message-----
From: Tomasz Bursztyka [mailto:tomasz.bursztyka(a)linux.intel.com]
Sent: Tuesday, September 13, 2016 4:19 AM
To: devel(a)lists.zephyrproject.org
Subject: [devel] [RFC] SPI API update

Hello everyone,

I would like to introduce a major update on SPI API

Known problems
--------------

- Concurrency of multiple devices on the same SPI bus:

* User code has to (re)configure the driver before each spi API call,
to be sure its configuration is in use (frequency and so on).
* User code has to call slave select before each spi API call to be
sure the driver is using the right one.

This is a user experience improvement.

- Asymmetric buffers (aka: smart "dummy" bytes handling). This was
already handled partially in the current API. However, for the Quark
SE users, QMSI has brought a regression on that feature.

SPI is a symmetrical bus, for each written byte, one byte will be
received. (there is no way you will receive n bytes without
writing n bytes first, or being able to write 2+ bytes before
receiving 1 byte, controller's buffer and logic put aside)

SPI devices works (always I guess?) this way:
TX <n bytes of specified commands> + <0+ bytes of data>
RX <as many bytes as tx>

When you are interested only by reading bytes, you need to write a
0 per-each byte you want to read. This 0 is called a dummy byte.

For instance, let's take again cc2520 device. When you want to read
the received packet, you send one byte of command, and write as many
0s you need to be able to receive the requested content. For a
content of 100 bytes, we would then need to write 1 byte of command
+ 100 dummy bytes. Either we let the user handle the dummy bytes: up
to him to provide the buffers of dummy bytes (and thus ask him to
provide both TX and RX buffers of same length), or we have a driver
which is smart enough to guess when it's up to him to generate such
dummy bytes, and then in our example TX can be made of 1 byte, and
RX made of 1+100 bytes. (the 0-copy solution could solve that RX
would be made of only 100 bytes)

Note that such asymmetric buffer support can easily enable the use
of specific modes of the SPI controller itself (tx only, eeprom
read...)

This is a performance improvement and can be - if TX and RX have to
be of different origins - a memory improvement too.

- Enabling true zero-copy from user's buffers throughout the driver:
Unless the user has the possibility to think about the SPI command
bytes he will require, there is no way you can write n bytes without
copying these into a new buffer of a size such as: k bytes of SPI
commands + n bytes of user data. This problem occurs easily when an
SPI device is hidden under some API. Same example: cc2520 below the
network stack. Net stack wants to send a "packet", hold in a buffer,
and has no clue about how cc2520 works. And thus in cc2520 driver,
we copy the packet data into a buffer that holds the first SPI
command byte as well.

This is a memory and performance improvement.

- (Optional?) It's currently impossible to manage n transaction on the
same call without releasing the CS unless all is put in the same
buffer.

This is a user experience improvement.

- (Optional?) SPI daisy chaining:

Shall we do something about SPI daisy chaining on the API level?

Providing helpers, or even configuration bits that would let the
driver to be smart about such wiring setup?



Solutions
---------

1) The SPI configuration pointer should be provided to every API
calls. For instance:

int spi_write(struct device *dev, struct spi_config *conf,
const void *buf, uint32_t len)

From driver's implementation point of view, it will be then just a
matter of storing a struct spi_config pointer in its private data
holder, and then at every call:
if (conf != private->conf) {
... call configure ...

private->conf = conf;
}

Public function spi_configure() would thus disappear.

2) Instead of calling the slave every-time, we could give it as a
parameter to every call as well. The logic behind would be more or
less the same as for the configuration.

int spi_write(struct device *dev, struct spi_config *conf,
uint32_t slave, const void *buf, uint32_t len)

Public function spi_slave_select() would thus disappear as well.

3) Optional:

In order to reduce the number of parameters which has grown with
the addition of struct spi_config *conf parameter, we could put
struct device *dev into the struct spi_config. That's meant to
let the compiler to use as much as possible registers instead.

I am not proposing to include slave into the configuration because
the same device's configuration could be used against a different
slave.

4) About zero-copy, we would provide a "scatter-gather" type of buffer.

struct spi_buf {
void *buf;
uint32_t len;
};

And then spi_transceive would be:

int spi_transceive(struct spi_config *conf, uint32_t slave,
const struct spi_buf *tx, uint32_t tx_nb_buf,
struct spi_buf *rx, uint32_t rx_nb_buf);

tx and rx would be array of struct spi_buf, and the function would
get the number of items in each array.

Let's use again cc2520 as an example, on function
write_txfifo_content():

{
uint8_t ins = CC2520_INS_TXBUF;
struct spi_buf cmd[2] = {
{ .buf = &ins, .len = 1 },
{ .buf = net_nbuf_ll(buf),
.len = net_nbuf_ll_reserve(buf) +
net_buf_frags_len(buf)
},
};

return (spi_write(spi_conf, spi_slave, cmd, 2) == 0);
}

Now, when reading, on function cc2520's read_rxfifo_content():

{
uint8_t ins = CC2520_INS_RXBUF;
struct spi_buf cmd = { .buf = &ins, .len = 1 };
struct spi_buf data[2] = {
{ .buf = NULL, .len = 0 },
{ .buf = buf->data, len },
}

if (spi_transceive(spi_conf, spi_slave,
&cmd, 1, data, 2) != 0) {
return false;
}

( ... )
}

Which could be optimized for stack usage this way:

{
uint8_t ins = CC2520_INS_RXBUF;
struct spi_buf data[2] = {
{ .buf = &ins, .len = 1 },
{ .buf = buf->data, len },
}

if (spi_transceive(spi_conf, spi_slave,
data, 1, data, 2) != 0) {
return false;
}

( ... )
}

5) Multiple transaction without releasing the CS

I would like to get use cases on that one to define something
generic. Because, it could replace spi_transceive on driver's API
level, and public function spi_transceive could be an inline
function wrapping it then.

6) About daisy chaining, we could have a configuration bit telling the
wiring is following such setup. Then, according to the slave
parameter, the API implementation could be smart, and generate the
necessary train of dummy bytes to shift the user's buffer to
the right slave. If the user would like to handle it himself,
either he would not set such config bit.

That said, I am not sure it's relevant to chain different chips
this way. The common use case seems to be many identical chips,
like memory chips etc... thus all driven by a central code, so
buffers are directly managed, taking care of the actual chaining.


API transition
--------------

There would not be any proper API update without a transition period, which
would keep the legacy API around for some time, until the right moment
would come to remove it.

As stated above these 2 functions would be doomed to disappear:

- spi_slave_select
- spi_configure

In the mean time, it would however be necessary to support it. I don't see
another way but to keep the 2 related device api functions. The
implementation below would be slightly different, as both would just set a
data into driver's private structure. Which info, would be in turn used the
same way as the new API will.

spi_configure(spi_dev, spi_conf) in the driver would end up:

{
if (spi_conf != private->conf) {
... configure ...
}

private->conf = spi_conf;
private->conf->dev = spi_dev;
}

Legacy spi_transceive() for instance would be, inside the driver:

{
_select_slave(private->slave);

(...)
}

The only big issue is function naming. We obviously cannot have 2 different
definitions for spi_read or spi_write, though their names are quite self-
documented. If anybody has an idea for new function names, I will be glad to
hear it. Here is what I have in mind:

- spi_transmit()
- spi_receive()

Unfortunately, both are longer names and spi_transceive() is already in use...
I am not super found about the idea of replacing current names. Ok, maybe
for write/read to transmit/receive, it's more SPI-like. But I still fail to find a
better name than spi_transceive.

The other solution, more like a bold move, would be to keep the existing
names, and make legacy and new API Kconfig based. Which means only one
API version would be available at built time. It's much simpler from API
modification point of view, less for all existing devices/app/etc... using the
current API.


Finally
-------

Once the transition period would be over, from legacy API to new one.


Buffer structure:

struct spi_buffer {
void *buf;
uint32_t len; /* Or should we use size_t ? */ };

Configuration structure:

struct spi_config {
struct device *dev;
uint32_t config; /* One of current reserved bits
could be used for daisy chaining */
uint32_t frequency; /* Previous name was not great at all */ };


Device's API structure:

typedef int (*spi_api_io)(struct spi_config *conf, uint32_t slave,
struct spi_buffer *tx, uint32_t nb_tx_buf,
struct spi_buffer *rx, uint32_t nb_rx_buf); struct spi_driver_api
{
spi_api_io transceive;
};


Function signatures:

Disappearance of spi_configure() and spi_slave_select()

inline int spi_read(struct spi_config *conf, uint32_t slave,
struct spi_buffer *rx, uint32_t nb_rx_buf);

inline int spi_write(struct spi_config *conf, uint32_t slave,
struct spi_buffer *tx, uint32_t nb_tx_buf);

(I did not change the name, but they could become respectively spi_receive
and spi_transmit)

inline int spi_transceive(struct spi_config *conf, uint32_t slave,
struct spi_buffer *tx, uint32_t nb_tx_buf,
struct spi_buffer *rx, uint32_t nb_rx_buf);

GPIO is and will be used for virtually any cases since the maximum duration of the CS
from the controller is so short. So, slave select is just giving a non-zero value to make
the controller happy and the GPIO pin is selecting the slave device. But, in the current
code, only one GPIO pin is defined for each controller by Kconfig. In other words, one
controller is only able to control one slave. This needs to be addressed.


Please comment. If you have any use case that would not fit, or any other
issue about current API you know of and which is not addressed by this RFC:
please tell.


Br,

Tomasz


Re: Porting to ARM M0, M0+

Phil Keating <pkeating@...>
 

I'm actually getting assembler error messages trying to process atomic.S. Again, this is on zephyr v1.4.0.

The actual command line and error message(s) are:

/tools/zephyr/zephyr-sdk/sysroots/i686-pokysdk-linux/usr/bin/arm-poky-eabi/arm-poky-eabi-gcc -Wp,-MD,arch/arm/core/.atomic.o.d -nostdinc -isystem /tools/zephyr/zephyr-sdk/sysroots/i686-pokysdk-linux/usr/bin/arm-poky-eabi/../../lib/arm-poky-eabi/gcc/arm-poky-eabi/5.2.0/include -isystem /tools/zephyr/zephyr-sdk/sysroots/i686-pokysdk-linux/usr/bin/arm-poky-eabi/../../lib/arm-poky-eabi/gcc/arm-poky-eabi/5.2.0/include-fixed -I/projects/itrx_soc_zephyr/engs/pkeating/software/zephyr-v1.4.0/arch/arm/include -I/projects/itrx_soc_zephyr/engs/pkeating/software/zephyr-v1.4.0/arch/arm/soc/itrx_m0 -I/projects/itrx_soc_zephyr/engs/pkeating/software/zephyr-v1.4.0/boards/itrx_som -I/projects/itrx_soc_zephyr/engs/pkeating/software/zephyr-v1.4.0/include -I/projects/itrx_soc_zephyr/engs/pkeating/software/zephyr-v1.4.0/include -I/projects/itrx_soc_zephyr/engs/pkeating/software/zephyr-v1.4.0/samples/hello_world/nanokernel/outdir/include/generated -I/projects/itrx_soc_zephyr/engs/pkeating/software/zeph
yr-v1.4.0/samples/hello_world/nanokernel/outdir/misc/generated/sysgen -include /projects/itrx_soc_zephyr/engs/pkeating/software/zephyr-v1.4.0/samples/hello_world/nanokernel/outdir/include/generated/autoconf.h -I/projects/itrx_soc_zephyr/engs/pkeating/software/zephyr-v1.4.0/lib/libc/minimal/include -DKERNEL -c -g -xassembler-with-cpp -mabi=aapcs -mthumb -mcpu=cortex-m0 -mthumb -march=armv6-m -I/projects/itrx_soc_zephyr/engs/pkeating/software/zephyr-v1.4.0/include/drivers -I/projects/itrx_soc_zephyr/engs/pkeating/software/zephyr-v1.4.0/drivers -I/projects/itrx_soc_zephyr/engs/pkeating/software/zephyr-v1.4.0/kernel/nanokernel/include -I/projects/itrx_soc_zephyr/engs/pkeating/software/zephyr-v1.4.0/kernel/microkernel/include -c -o arch/arm/core/atomic.o /projects/itrx_soc_zephyr/engs/pkeating/software/zephyr-v1.4.0/arch/arm/core/atomic.S
/projects/itrx_soc_zephyr/engs/pkeating/software/zephyr-v1.4.0/arch/arm/core/atomic.S: Assembler messages:
/projects/itrx_soc_zephyr/engs/pkeating/software/zephyr-v1.4.0/arch/arm/core/atomic.S:94: Error: selected processor does not support Thumb mode `ldrex r2,[r0]'
/projects/itrx_soc_zephyr/engs/pkeating/software/zephyr-v1.4.0/arch/arm/core/atomic.S:95: Error: selected processor does not support Thumb mode `strex r12,r1,[r0]'
...ad infinitum....

If it would be useful, I can post the various changes I've made to get CONFIG_CPU_CORTEX_M0 enabled. You can see the options to the compiler for which processor to coin[pile for in the command line above.


Re: [RFC] SPI API update

Liu, Baohong
 

Hi,

-----Original Message-----
From: Jon Medhurst (Tixy) [mailto:tixy(a)linaro.org]
Sent: Tuesday, September 13, 2016 8:18 AM
To: devel(a)lists.zephyrproject.org
Subject: [devel] Re: [RFC] SPI API update

On Tue, 2016-09-13 at 13:19 +0200, Tomasz Bursztyka wrote:
Hello everyone,

I would like to introduce a major update on SPI API
That's good timing I was about to ask about the flaws in the current API,
specifically that it seems to force everything into a single transaction on a
single buffer, meaning copying of large data buffers just to prepend a tiny (in
my case one byte) header.
+1


[...]
Solutions
---------

1) The SPI configuration pointer should be provided to every API
calls. For instance:

int spi_write(struct device *dev, struct spi_config *conf,
const void *buf, uint32_t len)

From driver's implementation point of view, it will be then just a
matter of storing a struct spi_config pointer in its private data
holder, and then at every call:
if (conf != private->conf) {
... call configure ...

private->conf = conf;
}

Public function spi_configure() would thus disappear.

2) Instead of calling the slave every-time, we could give it as a
parameter to every call as well. The logic behind would be more or
less the same as for the configuration.

int spi_write(struct device *dev, struct spi_config *conf,
uint32_t slave, const void *buf, uint32_t len)

Public function spi_slave_select() would thus disappear as well.
What about the case (like I have) where there is only a single device attached
to an SPI bus and the config never needs to change once set?
For this there is no need for conf and slave parameters on every transaction
and it's an unnecessary overhead to supply those parameters and for them
to be checked.

Orthogonal to my comment above. How about separating out config into a
separate 'begin' function call. If that also enables chip select, then we can
build arbitrary complex transactions (with zero-copy) using the current API's

spi_begin(dev, conf, slave) /* Enables chip select for slave */
...
spi_write(dev, ...)
spi_tranceive(dev, ...)
spi_read(dev, ...)
...
spi_end(dev) /* Disables chip select */
Introducing dependency between API calls is not a good idea.

An alternative to that for zero copy support would be to add a 'flags'
parameter to spi_{read,write,transceive} with 2 flags bits:

SPI_ENABLE_CS_BEFORE
SPI_DISABLE_CS_AFTER

That would gain the arbitrary complex and zero copy transaction support,
without forcing a begin/end call. E.g. I could send my bitmap to the LCD
controller without copying it by

spi_write(dev, &id_byte, sizeof(id_byte), SPI_ENABLE_CS_BEFORE);
spi_write(dev, &bitmap, sizeof(bitmap), SPI_DISABLE_CS_AFTER);

And the current implementation of spi_write would be equivalent to

spi_write(dev, data, size, SPI_ENABLE_CS_BEFORE|SPI_DISABLE_CS_AFTER)

If we wanted, we could also crowbar the slave select value into those flags.
Then if we created a config function that operated per slave:

spi_configure(dev, config, slave_id);

and that saved the config in an array somewhere, then the driver or
framework could reconfigure the hardware if the slave changes.

[...]
4) About zero-copy, we would provide a "scatter-gather" type of buffer.

struct spi_buf {
void *buf;
uint32_t len;
};

And then spi_transceive would be:

int spi_transceive(struct spi_config *conf, uint32_t slave,
const struct spi_buf *tx, uint32_t tx_nb_buf,
struct spi_buf *rx, uint32_t rx_nb_buf);

tx and rx would be array of struct spi_buf, and the function would
get the number of items in each array.

Let's use again cc2520 as an example, on function
write_txfifo_content():

{
uint8_t ins = CC2520_INS_TXBUF;
struct spi_buf cmd[2] = {
{ .buf = &ins, .len = 1 },
{ .buf = net_nbuf_ll(buf),
.len = net_nbuf_ll_reserve(buf) +
net_buf_frags_len(buf)
},
};

return (spi_write(spi_conf, spi_slave, cmd, 2) == 0);
}

Now, when reading, on function cc2520's read_rxfifo_content():

{
uint8_t ins = CC2520_INS_RXBUF;
struct spi_buf cmd = { .buf = &ins, .len = 1 };
struct spi_buf data[2] = {
{ .buf = NULL, .len = 0 },
So the above pairs with the single 'cmd' buffer and means 'ignore the read
data'? And in general, each entry in the tx list pairs with the equivalent in the
rx list. And if one list runs out it means transmit zeros or discard received data
as appropriate? I.e. the code implementing the new transceive is a for loop
passing pairs of parameters to the existing transceive?
+1

Seems simple to implement but a pig to use and understand ;-) I like my
separate function calls with CS flags better :-)

Some other questions about things not mentioned in the RFC...

1. What about DMA integration? I haven't spotted much in the way of DMA
support in driver APIs and the DMA API itself doesn't support scatter gather
so that's looking like a whole area that's yet to be sorted out?

2. Like most Zephyr code, there seems to be an absence of any kind of
locking in drivers or APIs that prevent users interfering with each other. So,
what prevents two drivers/apps trying to talk to two different devices on the
same SPI bus at the same time?
+1

--
Tixy


Random CI build failures

Perez Hernandez, Javier B <javier.b.perez.hernandez@...>
 

Hi!

We have detected some CI random failures due to the limit of concurrent
connections between Jenkins and Gerrit.

Problem:
Too many concurrent builds in Jenkins. Too many patches
submitted/rebased at the same time.
The patch in Gerrit is not compiled, reviewers are not added or never
get the verified +1 from Jenkins.

Workaround:
If you see that your commit is not being build, please wait a little (a
few minutes) and comment "recheck" on your change. This will trigger a
new build for it.
Please try to avoid to rebase a huge set of patches so often.

Really sorry for the inconvenience.
We will inform here once we have fixed the problem.

Regards

Javier B. Perez


Re: Porting to ARM M0, M0+

Daniel Thompson <daniel.thompson@...>
 

On 13/09/16 14:34, Phil Keating wrote:
Good morning, I'm new to the Zephyr project, as well as open source
in general, and noticed another thread regarding a port to the ARM
M0+ processor. I didn't want to piggy back on that thread as my
question(s) are more general regarding porting Zephyr from one ARM
core (M3/M4) to another (M0/M0+). I'm looking for a set of guidelines
as I've tried mucking up the 1.4.0 tree to get an M0 SOC/board
building and keep tripping over the GNU tools claiming my "processor"
either doesn't support THUMB instructions at all, or specific THUMB
instructions (depending on whether I define CONFIG_ISA_THUMB or
CONFIG_ISA_THUMB2).
I'm pretty new to zephyr too but this sounds more like a toolset problem
rather than a zephyr one!

Cortex-M0 is small *because* it does not implement the entire thumb
instruction set (for example if memory serves it does not implement
integer divide). That means, for example, if you try to link together
code for C-M0 with code for C-M3 it is likely to cause severe problems
at runtime.

You haven't shared them but I think the errors you are seeing is the
linker trying to protect you from such problems)


> I noticed a JIRA entry requesting documentation
for new SOC/Board porting. Any pointers, help, etc would be
appreciated.
That means you must make sure you are linking with M0-compatible
libraries (typically achieved by using a multilib toolchain such as
gcc-arm-embedded) and compiling using -mthumb -mcpu=cortex-m0.

I'm afraid here my advice runs out because I have no idea if the zephyr
SDK has multilib support or not.

However... personally I would set ZEPHYR_GCC_VARIANT=gccarmemb and start
hacking at scripts/Makefile.toolchain.gccarmemb to add support for
linking against different versions of the libraries. I'd let the table
halfway down https://launchpadlibrarian.net/268329726/readme.txt be my
guide!


Daniel.


Daily JIRA Digest

donotreply@...
 

NEW JIRA items within last 24 hours: 2
[ZEP-854] CoAP with DTLS sample
https://jira.zephyrproject.org/browse/ZEP-854

[ZEP-859] Migrate ENC28J60 driver to YAIP IP stack
https://jira.zephyrproject.org/browse/ZEP-859


UPDATED JIRA items within last 24 hours: 29
[ZEP-794] Requirements for Internet Hosts - Communication Layers
https://jira.zephyrproject.org/browse/ZEP-794

[ZEP-804] IPv6 Addressing Architecture
https://jira.zephyrproject.org/browse/ZEP-804

[ZEP-805] Internet Control Message Protocol (ICMP) v6
https://jira.zephyrproject.org/browse/ZEP-805

[ZEP-807] Neighbor Discovery for IPv6
https://jira.zephyrproject.org/browse/ZEP-807

[ZEP-798] IPv6
https://jira.zephyrproject.org/browse/ZEP-798

[ZEP-814] Routing Metrics used in Path Selection
https://jira.zephyrproject.org/browse/ZEP-814

[ZEP-815] Objective Function Zero for RPL
https://jira.zephyrproject.org/browse/ZEP-815

[ZEP-816] Minimum Rank with Hysteresis (RPL)
https://jira.zephyrproject.org/browse/ZEP-816

[ZEP-813] RPL: IPv6 Routing Protocol
https://jira.zephyrproject.org/browse/ZEP-813

[ZEP-812] Compression Format for IPv6 over 802.15.4
https://jira.zephyrproject.org/browse/ZEP-812

[ZEP-809] IPv6 over 802.15.4
https://jira.zephyrproject.org/browse/ZEP-809

[ZEP-825] Porting guide for old-to-new IP Stack APIs
https://jira.zephyrproject.org/browse/ZEP-825

[ZEP-824] Network Device Driver Porting Guide
https://jira.zephyrproject.org/browse/ZEP-824

[ZEP-823] New IP Stack - Documentation
https://jira.zephyrproject.org/browse/ZEP-823

[ZEP-827] HTTP Client sample application
https://jira.zephyrproject.org/browse/ZEP-827

[ZEP-792] ARP
https://jira.zephyrproject.org/browse/ZEP-792

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

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

[ZEP-648] New CoAP Implementation
https://jira.zephyrproject.org/browse/ZEP-648

[ZEP-833] IP-to-IP tunneling support
https://jira.zephyrproject.org/browse/ZEP-833

[ZEP-796] DHCPv4
https://jira.zephyrproject.org/browse/ZEP-796

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

[ZEP-635] Add FS API to grow a file
https://jira.zephyrproject.org/browse/ZEP-635

[ZEP-636] Add FS API to get volume total and free space
https://jira.zephyrproject.org/browse/ZEP-636

[ZEP-622] Add FS API to truncate/shrink a file
https://jira.zephyrproject.org/browse/ZEP-622

[ZEP-847] IoT protocol functionality must be moved from samples to lib/iot
https://jira.zephyrproject.org/browse/ZEP-847

[ZEP-767] Add FS API to flush cache of an open file
https://jira.zephyrproject.org/browse/ZEP-767

[ZEP-346] Provide a HTTP library within Zephyr
https://jira.zephyrproject.org/browse/ZEP-346

[ZEP-779] Using current MinGW gcc version 5.3.0 breaks Zephyr build on Windows
https://jira.zephyrproject.org/browse/ZEP-779


CLOSED JIRA items within last 24 hours: 7
[ZEP-753] (Duplicate) Make I2C_SDA_HOLD and I2C_SDA_SETUP SoC specific
https://jira.zephyrproject.org/browse/ZEP-753

[ZEP-764] (Fixed) Doc is being built for no reason and fails
https://jira.zephyrproject.org/browse/ZEP-764

[ZEP-778] (Fixed) Samples/drivers/i2c_lsm9ds0: kconfig build warning from "select DMA_QMSI"
https://jira.zephyrproject.org/browse/ZEP-778

[ZEP-777] (Fixed) samples/driver/i2c_stts751: kconfig build warning from "select DMA_QMSI"
https://jira.zephyrproject.org/browse/ZEP-777

[ZEP-782] (Fixed) Samples:drivers:adc:should define ARCH in samples/drivers/adc/Makefile
https://jira.zephyrproject.org/browse/ZEP-782

[ZEP-639] (Fixed) device_pm_ops structure should be defined as static
https://jira.zephyrproject.org/browse/ZEP-639

[ZEP-558] (Won't Do) nios2 all sys_write* oprtations map to sys_write32 due to CPU bug
https://jira.zephyrproject.org/browse/ZEP-558


RESOLVED JIRA items within last 24 hours: 11
[ZEP-451] (Fixed) Quark SE output by default redirected to IPM
https://jira.zephyrproject.org/browse/ZEP-451

[ZEP-546] (Fixed) UART interrupts not triggered on ARC
https://jira.zephyrproject.org/browse/ZEP-546

[ZEP-627] (Fixed) Port Trickle support from Contiki into current stack
https://jira.zephyrproject.org/browse/ZEP-627

[ZEP-48] (Fixed) define API for interrupt controllers
https://jira.zephyrproject.org/browse/ZEP-48

[ZEP-353] (Fixed) Driver for HP206C barometer, altimeter and temperature sensor
https://jira.zephyrproject.org/browse/ZEP-353

[ZEP-342] (Fixed) USB DFU
https://jira.zephyrproject.org/browse/ZEP-342

[ZEP-789] (Fixed) IPv4
https://jira.zephyrproject.org/browse/ZEP-789

[ZEP-757] (Fixed) tests/kernel/test_context/ fail in Arduino 101 and Quark SE C1000
https://jira.zephyrproject.org/browse/ZEP-757

[ZEP-762] (Fixed) unexpected "abspath" and "notdir" from mingw make system
https://jira.zephyrproject.org/browse/ZEP-762

[ZEP-849] (Fixed) dma driver fails to build on quark d2000
https://jira.zephyrproject.org/browse/ZEP-849

[ZEP-848] (Fixed) test_context fails on quark d2000
https://jira.zephyrproject.org/browse/ZEP-848


Re: [RFC] SPI API update

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

On Tue, 2016-09-13 at 13:19 +0200, Tomasz Bursztyka wrote:
Hello everyone,

I would like to introduce a major update on SPI API
That's good timing I was about to ask about the flaws in the current
API, specifically that it seems to force everything into a single
transaction on a single buffer, meaning copying of large data buffers
just to prepend a tiny (in my case one byte) header.

[...]
Solutions
---------

1) The SPI configuration pointer should be provided to every API
calls. For instance:

int spi_write(struct device *dev, struct spi_config *conf,
const void *buf, uint32_t len)

From driver's implementation point of view, it will be then just a
matter of storing a struct spi_config pointer in its private data
holder, and then at every call:
if (conf != private->conf) {
... call configure ...

private->conf = conf;
}

Public function spi_configure() would thus disappear.

2) Instead of calling the slave every-time, we could give it as a
parameter to every call as well. The logic behind would be more or
less the same as for the configuration.

int spi_write(struct device *dev, struct spi_config *conf,
uint32_t slave, const void *buf, uint32_t len)

Public function spi_slave_select() would thus disappear as well.
What about the case (like I have) where there is only a single device
attached to an SPI bus and the config never needs to change once set?
For this there is no need for conf and slave parameters on every
transaction and it's an unnecessary overhead to supply those parameters
and for them to be checked.

Orthogonal to my comment above. How about separating out config into a
separate 'begin' function call. If that also enables chip select, then
we can build arbitrary complex transactions (with zero-copy) using the
current API's

spi_begin(dev, conf, slave) /* Enables chip select for slave */
...
spi_write(dev, ...)
spi_tranceive(dev, ...)
spi_read(dev, ...)
...
spi_end(dev) /* Disables chip select */

An alternative to that for zero copy support would be to add a 'flags'
parameter to spi_{read,write,transceive} with 2 flags bits:

SPI_ENABLE_CS_BEFORE
SPI_DISABLE_CS_AFTER

That would gain the arbitrary complex and zero copy transaction support,
without forcing a begin/end call. E.g. I could send my bitmap to the LCD
controller without copying it by

spi_write(dev, &id_byte, sizeof(id_byte), SPI_ENABLE_CS_BEFORE);
spi_write(dev, &bitmap, sizeof(bitmap), SPI_DISABLE_CS_AFTER);

And the current implementation of spi_write would be equivalent to

spi_write(dev, data, size, SPI_ENABLE_CS_BEFORE|SPI_DISABLE_CS_AFTER)

If we wanted, we could also crowbar the slave select value into those
flags. Then if we created a config function that operated per slave:

spi_configure(dev, config, slave_id);

and that saved the config in an array somewhere, then the driver or
framework could reconfigure the hardware if the slave changes.

[...]
4) About zero-copy, we would provide a "scatter-gather" type of buffer.

struct spi_buf {
void *buf;
uint32_t len;
};

And then spi_transceive would be:

int spi_transceive(struct spi_config *conf, uint32_t slave,
const struct spi_buf *tx, uint32_t tx_nb_buf,
struct spi_buf *rx, uint32_t rx_nb_buf);

tx and rx would be array of struct spi_buf, and the function would
get the number of items in each array.

Let's use again cc2520 as an example, on function
write_txfifo_content():

{
uint8_t ins = CC2520_INS_TXBUF;
struct spi_buf cmd[2] = {
{ .buf = &ins, .len = 1 },
{ .buf = net_nbuf_ll(buf),
.len = net_nbuf_ll_reserve(buf) +
net_buf_frags_len(buf)
},
};

return (spi_write(spi_conf, spi_slave, cmd, 2) == 0);
}

Now, when reading, on function cc2520's read_rxfifo_content():

{
uint8_t ins = CC2520_INS_RXBUF;
struct spi_buf cmd = { .buf = &ins, .len = 1 };
struct spi_buf data[2] = {
{ .buf = NULL, .len = 0 },
So the above pairs with the single 'cmd' buffer and means 'ignore the
read data'? And in general, each entry in the tx list pairs with the
equivalent in the rx list. And if one list runs out it means transmit
zeros or discard received data as appropriate? I.e. the code
implementing the new transceive is a for loop passing pairs of
parameters to the existing transceive?

Seems simple to implement but a pig to use and understand ;-)
I like my separate function calls with CS flags better :-)

Some other questions about things not mentioned in the RFC...

1. What about DMA integration? I haven't spotted much in the way of DMA
support in driver APIs and the DMA API itself doesn't support scatter
gather so that's looking like a whole area that's yet to be sorted out?

2. Like most Zephyr code, there seems to be an absence of any kind of
locking in drivers or APIs that prevent users interfering with each
other. So, what prevents two drivers/apps trying to talk to two
different devices on the same SPI bus at the same time?

--
Tixy


Daily Gerrit Digest

donotreply@...
 

NEW within last 24 hours:
- https://gerrit.zephyrproject.org/r/4754 : Bluetooth: SMP: Fix encryption key size check in BR/EDR pairing req
- https://gerrit.zephyrproject.org/r/4753 : Bluetooht: Add support for reading encryption key size for BR/EDR
- https://gerrit.zephyrproject.org/r/4748 : Bluetooth: Controller: Use hci.h for ACL data
- https://gerrit.zephyrproject.org/r/4752 : Bluetooth: Controller: Implement LE_RAND command
- https://gerrit.zephyrproject.org/r/4751 : Bluetooth: Controller: Clean up HCI macros
- https://gerrit.zephyrproject.org/r/4749 : nano_work: Add nano_work_pending
- https://gerrit.zephyrproject.org/r/4744 : libc: replace null.h and size_t.h with stddef.h
- https://gerrit.zephyrproject.org/r/4750 : Bluetooth: HCI: Fix updating RPA too early
- https://gerrit.zephyrproject.org/r/4747 : tinycrypt: Solve style issues
- https://gerrit.zephyrproject.org/r/4746 : Bluetooth: Fix giving back pkts semaphore when disconnecting
- https://gerrit.zephyrproject.org/r/4745 : tinycrypt: Rename current tests to avoid confusions with new algorithms
- https://gerrit.zephyrproject.org/r/4741 : doc: workaround for __deprecated functions

UPDATED within last 24 hours:
- https://gerrit.zephyrproject.org/r/4730 : Bluetooth: SMP: Add support for sending Pairing Request over BR/EDR
- https://gerrit.zephyrproject.org/r/4729 : Bluetooth: SMP: Add helper for reporting BR/EDR pairing complete
- https://gerrit.zephyrproject.org/r/4728 : Bluetooth: SMP: Add support for Signing Information over BR/EDR
- https://gerrit.zephyrproject.org/r/4727 : Bluetooth: SMP: Add support for Identity Information over BR/EDR
- https://gerrit.zephyrproject.org/r/4726 : Bluetooth: SMP: Add support for LTK derivation from LinkKey
- https://gerrit.zephyrproject.org/r/4725 : Bluetooth: SMP: Allow to force BR/EDR without SC support
- https://gerrit.zephyrproject.org/r/4724 : Bluetooth: SMP: Support Pairing Response over BR/EDR
- https://gerrit.zephyrproject.org/r/4670 : intel_quark: Group Quark SoCs under intel_quark/
- https://gerrit.zephyrproject.org/r/4688 : boards: rename arduino_101_sss to arduino_101_ss
- https://gerrit.zephyrproject.org/r/4447 : Bluetooth: AVDTP: Module Initialization
- https://gerrit.zephyrproject.org/r/4422 : boards: rename Quark SE Devboard to Quark SE C1000
- https://gerrit.zephyrproject.org/r/3527 : console: shell: Shell enhancement - Support multiple modules
- https://gerrit.zephyrproject.org/r/4715 : net: yaip: Add DHCPv4 client support
- https://gerrit.zephyrproject.org/r/4717 : net: apps: Add DHCPv4 client sample application
- https://gerrit.zephyrproject.org/r/4699 : nano_work: Add nano_delayed_work_pending
- https://gerrit.zephyrproject.org/r/4708 : net: yaip: Fix arp/ethernet broadcast and multcast addr scenario
- https://gerrit.zephyrproject.org/r/4710 : net: yaip: Fix IPv4 packet reception
- https://gerrit.zephyrproject.org/r/4716 : net: tests: Add DHCPv4 client unit tests
- https://gerrit.zephyrproject.org/r/4713 : net: yaip: Fix net address state
- https://gerrit.zephyrproject.org/r/4711 : net: tests: Add include directory only when specific config options enabled
- https://gerrit.zephyrproject.org/r/4321 : Bluetooth: L2CAP: Drop channel if missing linkkey on peer
- https://gerrit.zephyrproject.org/r/4540 : Bluetooth: AVDTP: Connect and Disconnect
- https://gerrit.zephyrproject.org/r/4530 : unified: initial unified kernel implementation
- https://gerrit.zephyrproject.org/r/4502 : dlist: add static initialization macro
- https://gerrit.zephyrproject.org/r/4501 : dlist: add SYS_DLIST_FOR_EACH_NODE/_SAFE
- https://gerrit.zephyrproject.org/r/4503 : slist: add sys_slist_get() to fetch and remove the head
- https://gerrit.zephyrproject.org/r/4504 : slist: add sys_slist_append_list and sys_slist_merge_slist()
- https://gerrit.zephyrproject.org/r/4705 : power_mgmt: Mark old device pm API functions as deprecated
- https://gerrit.zephyrproject.org/r/4679 : ARM: irq: Add _arch_irq_is_enabled external interrupt API
- https://gerrit.zephyrproject.org/r/4707 : net: yaip: Fix slip multipackets reception
- https://gerrit.zephyrproject.org/r/4704 : power_mgmt: Update sample and drivers according to new pm device API
- https://gerrit.zephyrproject.org/r/4463 : power_mgmt: Update Power Management device driver API
- https://gerrit.zephyrproject.org/r/4678 : irq: Add irq_is_enabled external interrupt API
- https://gerrit.zephyrproject.org/r/4677 : ARM: irq: Add _arch_irq_enable_keep external interrupt API
- https://gerrit.zephyrproject.org/r/4551 : tests: move test code from samples to tests
- https://gerrit.zephyrproject.org/r/4600 : samples: heartrate-monitor: Fixes for following issues.
- https://gerrit.zephyrproject.org/r/4687 : arduino 101: make factory bootloader config the default
- https://gerrit.zephyrproject.org/r/4689 : parse board defconfig at the very end
- https://gerrit.zephyrproject.org/r/4671 : soc: intel_quark: move quark d2000 to intel_quark family
- https://gerrit.zephyrproject.org/r/4684 : quark_x1000: move the X1000 into the intel_quark family
- https://gerrit.zephyrproject.org/r/4423 : MAINTAINERS: add maintainer for some of the boards
- https://gerrit.zephyrproject.org/r/4420 : boards: rename Quark SE Devboard to Quark SE C1000 (Sensor Subsystem)
- https://gerrit.zephyrproject.org/r/4517 : unified: include kernel.h via major top-level header files
- https://gerrit.zephyrproject.org/r/4512 : unified/build: adapt Kbuild for unified kernel
- https://gerrit.zephyrproject.org/r/4509 : arm: add __ASSERT() for stack alignment
- https://gerrit.zephyrproject.org/r/4508 : build: only generate the SSE group for x86
- https://gerrit.zephyrproject.org/r/4507 : sysgen: add --kernel_type argument
- https://gerrit.zephyrproject.org/r/4506 : build: make sysgen take optional command line arguments
- https://gerrit.zephyrproject.org/r/4505 : kernel: add CONFIG_MDEF
- https://gerrit.zephyrproject.org/r/4571 : checkpatch: do not check for min_t/max_t
- https://gerrit.zephyrproject.org/r/4570 : checkpatch: add --ignore DATE_TIME
- https://gerrit.zephyrproject.org/r/4516 : workqueue: use kernel.h for workqueue header file
- https://gerrit.zephyrproject.org/r/4515 : atomic: fix bug in ATOMIC_INIT()
- https://gerrit.zephyrproject.org/r/4674 : x86: load _nanokernel in %edi in _Swap()
- https://gerrit.zephyrproject.org/r/4514 : unified/x86: add unified kernel support for x86 arch
- https://gerrit.zephyrproject.org/r/4347 : net: yaip: User connectivity API documentation
- https://gerrit.zephyrproject.org/r/4346 : net: yaip: Initial architecture documentation
- https://gerrit.zephyrproject.org/r/4526 : unified/test_timer: adapt for unified kernel
- https://gerrit.zephyrproject.org/r/4529 : unified/test_fp: mark test so that it runs the nanokernel version
- https://gerrit.zephyrproject.org/r/4531 : unified/build: allow building the unified kernel
- https://gerrit.zephyrproject.org/r/4528 : unified/test_sema: fix isr wrapper names
- https://gerrit.zephyrproject.org/r/4527 : unified: Fix test_sema/microkernel
- https://gerrit.zephyrproject.org/r/4525 : unified/test_pipe: adapt to not use sem groups
- https://gerrit.zephyrproject.org/r/4524 : unified/test_mail: adapt test to not use sem groups and mem pools
- https://gerrit.zephyrproject.org/r/4523 : unified/test_context: adapt test to run on unified kernel
- https://gerrit.zephyrproject.org/r/4522 : unified/tests: tag working some tests kernel as 'unified_capable'
- https://gerrit.zephyrproject.org/r/4521 : zperf_shell: add unified kernel string for unified kernel case
- https://gerrit.zephyrproject.org/r/4520 : unified/object_tracing: disable object tracing in unified kernel
- https://gerrit.zephyrproject.org/r/4519 : unified/sys_timer: guard microkernel announce with !KERNEL_V2
- https://gerrit.zephyrproject.org/r/4518 : unified/drivers: adapt timer drivers to unified kernel
- https://gerrit.zephyrproject.org/r/4513 : unified/arm: add unified kernel support for ARM arch
- https://gerrit.zephyrproject.org/r/4511 : unified/doc: Kernel primer for unified kernel
- https://gerrit.zephyrproject.org/r/4510 : arm: only compile gdb stubs when CONFIG_GDB_INFO=y
- https://gerrit.zephyrproject.org/r/4675 : unified/test_mutex: adapt to run on unified kernel
- https://gerrit.zephyrproject.org/r/3922 : lib: Add HTTP support for Zephyr
- https://gerrit.zephyrproject.org/r/3924 : lib/http: Add test-case for HTTP header fields
- https://gerrit.zephyrproject.org/r/4659 : task profiler: Adds the task profiler samples to the sanity check
- https://gerrit.zephyrproject.org/r/4658 : task profiler: README file update
- https://gerrit.zephyrproject.org/r/4680 : irq: Add irq_pending_clear external interrupt API
- https://gerrit.zephyrproject.org/r/4682 : irq: Add irq_is_priority_equal external interrupt API
- https://gerrit.zephyrproject.org/r/4681 : ARM: irq: Add _arch_irq_pending_clear external interrupt API
- https://gerrit.zephyrproject.org/r/4657 : task profiler: project configuration files clean up
- https://gerrit.zephyrproject.org/r/4660 : sanity: disable qemu cortex for GCC ARM toolchain.
- https://gerrit.zephyrproject.org/r/4593 : Clean dev and latest docs sites before deploy

MERGED within last 24 hours:
- https://gerrit.zephyrproject.org/r/4738 : Bluetooth: Controller: Remove HCI event definitions from hci.c
- https://gerrit.zephyrproject.org/r/4737 : Bluetooth: Controller: Use hci.h for num complete
- https://gerrit.zephyrproject.org/r/4742 : Bluetooth: GATT: Fix potential bt_conn reference leak
- https://gerrit.zephyrproject.org/r/4743 : samples: zoap: build only for specified boards
- https://gerrit.zephyrproject.org/r/4740 : known-issues: clarify documentation on ignore blocks
- https://gerrit.zephyrproject.org/r/4739 : known-issues: remove entries for fixed ZEP-757
- https://gerrit.zephyrproject.org/r/4735 : samples: dma: don't skip this test case
- https://gerrit.zephyrproject.org/r/4733 : test_context: use correct timer IRQ for mint valley
- https://gerrit.zephyrproject.org/r/4734 : mvic: default to IRQ 10 instead of 0 for timer
- https://gerrit.zephyrproject.org/r/4736 : gen_idt: validate IRQ line before vector assignment
- https://gerrit.zephyrproject.org/r/4732 : sensor: HP206C: fix kconfig sys log help
- https://gerrit.zephyrproject.org/r/4723 : Bluetooth: SMP: Distribute local keys over BR/EDR
- https://gerrit.zephyrproject.org/r/4722 : Bluetooth: SMP: Support Pairing Failed over BR/EDR
- https://gerrit.zephyrproject.org/r/4721 : Bluetooth: SMP: Support Pairing Request over BR/EDR
- https://gerrit.zephyrproject.org/r/4720 : Bluetooth: SMP: Clear keys on timeout when running over BR/EDR
- https://gerrit.zephyrproject.org/r/4691 : build: zephyr: Remove unused QEMU variable
- https://gerrit.zephyrproject.org/r/3850 : samples/net: Add a sample for a CoAP client
- https://gerrit.zephyrproject.org/r/4719 : Bluetooth: SMP: Add initial code for BR/EDR support
- https://gerrit.zephyrproject.org/r/4718 : Bluetooth: SMP: Move smp_create_pdu function up in a file
- https://gerrit.zephyrproject.org/r/4701 : Bluetooth: Controller: Use hci.h for control event handling
- https://gerrit.zephyrproject.org/r/4703 : Bluetooth: Controller: Use hci.h for data-control evt handling
- https://gerrit.zephyrproject.org/r/4702 : Bluetooth: HCI: Add read remote version info event
- https://gerrit.zephyrproject.org/r/2076 : sensor: add driver for HP206C sensor
- https://gerrit.zephyrproject.org/r/4248 : net: Fix net_send return value documentation


Porting to ARM M0, M0+

Phil Keating <pkeating@...>
 

Good morning,
I'm new to the Zephyr project, as well as open source in general, and noticed another thread regarding a port to the ARM M0+ processor. I didn't want to piggy back on that thread as my question(s) are more general regarding porting Zephyr from one ARM core (M3/M4) to another (M0/M0+).
I'm looking for a set of guidelines as I've tried mucking up the 1.4.0 tree to get an M0 SOC/board building and keep tripping over the GNU tools claiming my "processor" either doesn't support THUMB instructions at all, or specific THUMB instructions (depending on whether I define CONFIG_ISA_THUMB or CONFIG_ISA_THUMB2).
I noticed a JIRA entry requesting documentation for new SOC/Board porting.
Any pointers, help, etc would be appreciated. For example, since someone is already working on an M0+ port, would that become part of the Zephyr code base?
Thanks in advance,
Phil Keating


[RFC] SPI API update

Tomasz Bursztyka
 

Hello everyone,

I would like to introduce a major update on SPI API

Known problems
--------------

- Concurrency of multiple devices on the same SPI bus:

* User code has to (re)configure the driver before each spi API call,
to be sure its configuration is in use (frequency and so on).
* User code has to call slave select before each spi API call to be
sure the driver is using the right one.

This is a user experience improvement.

- Asymmetric buffers (aka: smart "dummy" bytes handling). This was
already handled partially in the current API. However, for the Quark
SE users, QMSI has brought a regression on that feature.

SPI is a symmetrical bus, for each written byte, one byte will be
received. (there is no way you will receive n bytes without
writing n bytes first, or being able to write 2+ bytes before
receiving 1 byte, controller's buffer and logic put aside)

SPI devices works (always I guess?) this way:
TX <n bytes of specified commands> + <0+ bytes of data>
RX <as many bytes as tx>

When you are interested only by reading bytes, you need to write a
0 per-each byte you want to read. This 0 is called a dummy byte.

For instance, let's take again cc2520 device. When you want to read
the received packet, you send one byte of command, and write as many
0s you need to be able to receive the requested content. For a
content of 100 bytes, we would then need to write 1 byte of command
+ 100 dummy bytes. Either we let the user handle the dummy bytes: up
to him to provide the buffers of dummy bytes (and thus ask him to
provide both TX and RX buffers of same length), or we have a driver
which is smart enough to guess when it's up to him to generate such
dummy bytes, and then in our example TX can be made of 1 byte, and
RX made of 1+100 bytes. (the 0-copy solution could solve that RX
would be made of only 100 bytes)

Note that such asymmetric buffer support can easily enable the use
of specific modes of the SPI controller itself (tx only, eeprom
read...)

This is a performance improvement and can be - if TX and RX have to
be of different origins - a memory improvement too.

- Enabling true zero-copy from user's buffers throughout the driver:
Unless the user has the possibility to think about the SPI command
bytes he will require, there is no way you can write n bytes without
copying these into a new buffer of a size such as: k bytes of SPI
commands + n bytes of user data. This problem occurs easily when an
SPI device is hidden under some API. Same example: cc2520 below the
network stack. Net stack wants to send a "packet", hold in a buffer,
and has no clue about how cc2520 works. And thus in cc2520 driver,
we copy the packet data into a buffer that holds the first SPI
command byte as well.

This is a memory and performance improvement.

- (Optional?) It's currently impossible to manage n transaction on the
same call without releasing the CS unless all is put in the same
buffer.

This is a user experience improvement.

- (Optional?) SPI daisy chaining:

Shall we do something about SPI daisy chaining on the API level?

Providing helpers, or even configuration bits that would let the
driver to be smart about such wiring setup?



Solutions
---------

1) The SPI configuration pointer should be provided to every API
calls. For instance:

int spi_write(struct device *dev, struct spi_config *conf,
const void *buf, uint32_t len)

From driver's implementation point of view, it will be then just a
matter of storing a struct spi_config pointer in its private data
holder, and then at every call:
if (conf != private->conf) {
... call configure ...

private->conf = conf;
}

Public function spi_configure() would thus disappear.

2) Instead of calling the slave every-time, we could give it as a
parameter to every call as well. The logic behind would be more or
less the same as for the configuration.

int spi_write(struct device *dev, struct spi_config *conf,
uint32_t slave, const void *buf, uint32_t len)

Public function spi_slave_select() would thus disappear as well.

3) Optional:

In order to reduce the number of parameters which has grown with
the addition of struct spi_config *conf parameter, we could put
struct device *dev into the struct spi_config. That's meant to
let the compiler to use as much as possible registers instead.

I am not proposing to include slave into the configuration because
the same device's configuration could be used against a different
slave.

4) About zero-copy, we would provide a "scatter-gather" type of buffer.

struct spi_buf {
void *buf;
uint32_t len;
};

And then spi_transceive would be:

int spi_transceive(struct spi_config *conf, uint32_t slave,
const struct spi_buf *tx, uint32_t tx_nb_buf,
struct spi_buf *rx, uint32_t rx_nb_buf);

tx and rx would be array of struct spi_buf, and the function would
get the number of items in each array.

Let's use again cc2520 as an example, on function
write_txfifo_content():

{
uint8_t ins = CC2520_INS_TXBUF;
struct spi_buf cmd[2] = {
{ .buf = &ins, .len = 1 },
{ .buf = net_nbuf_ll(buf),
.len = net_nbuf_ll_reserve(buf) +
net_buf_frags_len(buf)
},
};

return (spi_write(spi_conf, spi_slave, cmd, 2) == 0);
}

Now, when reading, on function cc2520's read_rxfifo_content():

{
uint8_t ins = CC2520_INS_RXBUF;
struct spi_buf cmd = { .buf = &ins, .len = 1 };
struct spi_buf data[2] = {
{ .buf = NULL, .len = 0 },
{ .buf = buf->data, len },
}

if (spi_transceive(spi_conf, spi_slave,
&cmd, 1, data, 2) != 0) {
return false;
}

( ... )
}

Which could be optimized for stack usage this way:

{
uint8_t ins = CC2520_INS_RXBUF;
struct spi_buf data[2] = {
{ .buf = &ins, .len = 1 },
{ .buf = buf->data, len },
}

if (spi_transceive(spi_conf, spi_slave,
data, 1, data, 2) != 0) {
return false;
}

( ... )
}

5) Multiple transaction without releasing the CS

I would like to get use cases on that one to define something
generic. Because, it could replace spi_transceive on driver's API
level, and public function spi_transceive could be an inline
function wrapping it then.

6) About daisy chaining, we could have a configuration bit telling the
wiring is following such setup. Then, according to the slave
parameter, the API implementation could be smart, and generate the
necessary train of dummy bytes to shift the user's buffer to
the right slave. If the user would like to handle it himself,
either he would not set such config bit.

That said, I am not sure it's relevant to chain different chips
this way. The common use case seems to be many identical chips,
like memory chips etc... thus all driven by a central code, so
buffers are directly managed, taking care of the actual chaining.


API transition
--------------

There would not be any proper API update without a transition period,
which would keep the legacy API around for some time, until the right
moment would come to remove it.

As stated above these 2 functions would be doomed to disappear:

- spi_slave_select
- spi_configure

In the mean time, it would however be necessary to support it. I don't
see another way but to keep the 2 related device api functions. The
implementation below would be slightly different, as both would just
set a data into driver's private structure. Which info, would be in
turn used the same way as the new API will.

spi_configure(spi_dev, spi_conf) in the driver would end up:

{
if (spi_conf != private->conf) {
... configure ...
}

private->conf = spi_conf;
private->conf->dev = spi_dev;
}

Legacy spi_transceive() for instance would be, inside the driver:

{
_select_slave(private->slave);

(...)
}

The only big issue is function naming. We obviously cannot have 2
different definitions for spi_read or spi_write, though their names
are quite self-documented. If anybody has an idea for new function
names, I will be glad to hear it. Here is what I have in mind:

- spi_transmit()
- spi_receive()

Unfortunately, both are longer names and spi_transceive() is already
in use... I am not super found about the idea of replacing current
names. Ok, maybe for write/read to transmit/receive, it's more
SPI-like. But I still fail to find a better name than spi_transceive.

The other solution, more like a bold move, would be to keep the
existing names, and make legacy and new API Kconfig based. Which means
only one API version would be available at built time. It's much
simpler from API modification point of view, less for all existing
devices/app/etc... using the current API.


Finally
-------

Once the transition period would be over, from legacy API to new one.


Buffer structure:

struct spi_buffer {
void *buf;
uint32_t len; /* Or should we use size_t ? */
};

Configuration structure:

struct spi_config {
struct device *dev;
uint32_t config; /* One of current reserved bits
could be used for daisy chaining */
uint32_t frequency; /* Previous name was not great at all */
};


Device's API structure:

typedef int (*spi_api_io)(struct spi_config *conf, uint32_t slave,
struct spi_buffer *tx, uint32_t nb_tx_buf,
struct spi_buffer *rx, uint32_t nb_rx_buf);
struct spi_driver_api {
spi_api_io transceive;
};


Function signatures:

Disappearance of spi_configure() and spi_slave_select()

inline int spi_read(struct spi_config *conf, uint32_t slave,
struct spi_buffer *rx, uint32_t nb_rx_buf);

inline int spi_write(struct spi_config *conf, uint32_t slave,
struct spi_buffer *tx, uint32_t nb_tx_buf);

(I did not change the name, but they could become respectively
spi_receive and spi_transmit)

inline int spi_transceive(struct spi_config *conf, uint32_t slave,
struct spi_buffer *tx, uint32_t nb_tx_buf,
struct spi_buffer *rx, uint32_t nb_rx_buf);



Please comment. If you have any use case that would not fit, or any
other issue about current API you know of and which is not addressed by
this RFC: please tell.


Br,

Tomasz


Re: deprecated issue after push to gerrit - need some help

Boie, Andrew P
 

? Any idea why the checking doesn't "catch" the "problem"?

Because it's perfectly valid C code.
Doxygen's C parser is suboptimal and freaks out if you try to do function annotations. Which is how adding a preprocessor directive to have them expand to nothing works around it.

Andrew

From: Kaplan, Amir [mailto:amir.kaplan(a)intel.com]
Sent: Monday, September 12, 2016 8:57 AM
To: Ross, Andrew J <andrew.j.ross(a)intel.com>; devel(a)lists.zephyrproject.org
Subject: [devel] Re: deprecated issue after push to gerrit - need some help

Thanks!

It leads to the same solution as David suggested

I will try it tomorrow

Or I will try Andrew P solution...


There is a command who checks the code in advance:

git show | ./scripts/checkpatch.pl --no-tree -

Any idea why the checking doesn't "catch" the "problem"?



Thanks,
Amir


From: Ross, Andrew J
Sent: Monday, September 12, 2016 18:44
To: Kaplan, Amir <amir.kaplan(a)intel.com<mailto:amir.kaplan(a)intel.com>>; devel(a)lists.zephyrproject.org<mailto:devel(a)lists.zephyrproject.org>
Subject: Re: [devel] deprecated issue after push to gerrit - need some help


It looks like Inaky struggled with this a few months back. Sphinx claims to have fixed it in the bug, no idea if we've done anything to patch it on our end:

https://github.com/sphinx-doc/sphinx/issues/2682

Andy

________________________________
From: Kaplan, Amir
Sent: Monday, September 12, 2016 7:56AM
To: Devel
Subject: [devel] deprecated issue after push to gerrit - need some help
Hi all,

I pushed to : https://gerrit.zephyrproject.org/r/4705

And I got Verified -1 error:

Going to there, and I see:


ERROR: Please fix the documentation warnings
/jenkins/workspace/zephyr-verify/doc/api/power_management_api.rst:16: WARNING: Error when parsing function declaration.
If the function has no return type:
Error in declarator or parameters and qualifiers
Invalid definition: Expected identifier in nested name, got keyword: int [error at 10]
static int __deprecated device_suspend(struct device * device, int pm_policy)
----------^
If the function has a return type:
Error in declarator or parameters and qualifiers
If pointer to member declarator:
Invalid definition: Expected '::' in pointer to member (function). [error at 24]
static int __deprecated device_suspend(struct device * device, int pm_policy)
------------------------^
If declarator-id:
Invalid definition: Expecting "(" in parameters_and_qualifiers. [error at 24]
static int __deprecated device_suspend(struct device * device, int pm_policy)
------------------------^

The function is (in device.h):

static inline int __deprecated device_suspend(struct device *device,
int pm_policy)
{
return device->config->dev_pm_ops->suspend(device, pm_policy);
}

Any idea (I didn't find what is wrong with it)?

Thanks in advance,
Amir Kaplan (S/W dev. in wiot )






---------------------------------------------------------------------
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: deprecated issue after push to gerrit - need some help

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

After talking with Inaky, I'll update the wiki to reflect the two ways to work around this issue AND update the doxygen.config (gerrit patch submitted: https://gerrit.zephyrproject.org/r/#/c/4741/ )
-- david


From: Kaplan, Amir [mailto:amir.kaplan(a)intel.com]
Sent: Monday, September 12, 2016 8:57 AM
To: Ross, Andrew J <andrew.j.ross(a)intel.com>; devel(a)lists.zephyrproject.org
Subject: [devel] Re: deprecated issue after push to gerrit - need some help

Thanks!

It leads to the same solution as David suggested

I will try it tomorrow

Or I will try Andrew P solution...


There is a command who checks the code in advance:

git show | ./scripts/checkpatch.pl --no-tree -

Any idea why the checking doesn't "catch" the "problem"?



Thanks,
Amir


From: Ross, Andrew J
Sent: Monday, September 12, 2016 18:44
To: Kaplan, Amir <amir.kaplan(a)intel.com<mailto:amir.kaplan(a)intel.com>>; devel(a)lists.zephyrproject.org<mailto:devel(a)lists.zephyrproject.org>
Subject: Re: [devel] deprecated issue after push to gerrit - need some help


It looks like Inaky struggled with this a few months back. Sphinx claims to have fixed it in the bug, no idea if we've done anything to patch it on our end:

https://github.com/sphinx-doc/sphinx/issues/2682

Andy

________________________________
From: Kaplan, Amir
Sent: Monday, September 12, 2016 7:56AM
To: Devel
Subject: [devel] deprecated issue after push to gerrit - need some help
Hi all,

I pushed to : https://gerrit.zephyrproject.org/r/4705

And I got Verified -1 error:

Going to there, and I see:


ERROR: Please fix the documentation warnings
/jenkins/workspace/zephyr-verify/doc/api/power_management_api.rst:16: WARNING: Error when parsing function declaration.
If the function has no return type:
Error in declarator or parameters and qualifiers
Invalid definition: Expected identifier in nested name, got keyword: int [error at 10]
static int __deprecated device_suspend(struct device * device, int pm_policy)
----------^
If the function has a return type:
Error in declarator or parameters and qualifiers
If pointer to member declarator:
Invalid definition: Expected '::' in pointer to member (function). [error at 24]
static int __deprecated device_suspend(struct device * device, int pm_policy)
------------------------^
If declarator-id:
Invalid definition: Expecting "(" in parameters_and_qualifiers. [error at 24]
static int __deprecated device_suspend(struct device * device, int pm_policy)
------------------------^

The function is (in device.h):

static inline int __deprecated device_suspend(struct device *device,
int pm_policy)
{
return device->config->dev_pm_ops->suspend(device, pm_policy);
}

Any idea (I didn't find what is wrong with it)?

Thanks in advance,
Amir Kaplan (S/W dev. in wiot )






---------------------------------------------------------------------
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: deprecated issue after push to gerrit - need some help

Kaplan, Amir
 

Thanks!

It leads to the same solution as David suggested

I will try it tomorrow

Or I will try Andrew P solution...


There is a command who checks the code in advance:

git show | ./scripts/checkpatch.pl --no-tree -

Any idea why the checking doesn't "catch" the "problem"?



Thanks,
Amir


From: Ross, Andrew J
Sent: Monday, September 12, 2016 18:44
To: Kaplan, Amir <amir.kaplan(a)intel.com>; devel(a)lists.zephyrproject.org
Subject: Re: [devel] deprecated issue after push to gerrit - need some help


It looks like Inaky struggled with this a few months back. Sphinx claims to have fixed it in the bug, no idea if we've done anything to patch it on our end:

https://github.com/sphinx-doc/sphinx/issues/2682

Andy

________________________________
From: Kaplan, Amir
Sent: Monday, September 12, 2016 7:56AM
To: Devel
Subject: [devel] deprecated issue after push to gerrit - need some help
Hi all,

I pushed to : https://gerrit.zephyrproject.org/r/4705

And I got Verified -1 error:

Going to there, and I see:


ERROR: Please fix the documentation warnings
/jenkins/workspace/zephyr-verify/doc/api/power_management_api.rst:16: WARNING: Error when parsing function declaration.
If the function has no return type:
Error in declarator or parameters and qualifiers
Invalid definition: Expected identifier in nested name, got keyword: int [error at 10]
static int __deprecated device_suspend(struct device * device, int pm_policy)
----------^
If the function has a return type:
Error in declarator or parameters and qualifiers
If pointer to member declarator:
Invalid definition: Expected '::' in pointer to member (function). [error at 24]
static int __deprecated device_suspend(struct device * device, int pm_policy)
------------------------^
If declarator-id:
Invalid definition: Expecting "(" in parameters_and_qualifiers. [error at 24]
static int __deprecated device_suspend(struct device * device, int pm_policy)
------------------------^

The function is (in device.h):

static inline int __deprecated device_suspend(struct device *device,
int pm_policy)
{
return device->config->dev_pm_ops->suspend(device, pm_policy);
}

Any idea (I didn't find what is wrong with it)?

Thanks in advance,
Amir Kaplan (S/W dev. in wiot )






---------------------------------------------------------------------
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: deprecated issue after push to gerrit - need some help

Boie, Andrew P
 

On Mon, 2016-09-12 at 14:56 +0000, Kaplan, Amir wrote:
Hi all,
 
I pushed to : https://gerrit.zephyrproject.org/r/4705
 
And I got Verified -1 error:
Edit doc/doxygen.config, look for PREDEFINED, add "__deprecated=" to
the list.

This causes Doxygen to treat __deprecated as a predefined macro which
expands to nothing.

Andrew


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-763] (Fixed) Samples:README: samples/drivers/I2c_stts751 describes error
https://jira.zephyrproject.org/browse/ZEP-763


Re: deprecated issue after push to gerrit - need some help

Andy Ross
 

It looks like Inaky struggled with this a few months back. Sphinx claims to have fixed it in the bug, no idea if we've done anything to patch it on our end:

https://github.com/sphinx-doc/sphinx/issues/2682


Andy



------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
*From:* Kaplan, Amir
*Sent:* Monday, September 12, 2016 7:56AM
*To:* Devel
*Subject:* [devel] deprecated issue after push to gerrit - need some help

Hi all,



I pushed to : https://gerrit.zephyrproject.org/r/4705 <https://gerrit.zephyrproject.org/r/4705>



And I got Verified -1 error:



Going to there, and I see:





ERROR: Please fix the documentation warnings

/jenkins/workspace/zephyr-verify/doc/api/power_management_api.rst:16: WARNING: Error when parsing function declaration.

If the function has no return type:

Error in declarator or parameters and qualifiers

Invalid definition: Expected identifier in nested name, got keyword: int [error at 10]

static int __deprecated device_suspend(struct device * device, int pm_policy)

----------^

If the function has a return type:

Error in declarator or parameters and qualifiers

If pointer to member declarator:

Invalid definition: Expected '::' in pointer to member (function). [error at 24]

static int __deprecated device_suspend(struct device * device, int pm_policy)

------------------------^

If declarator-id:

Invalid definition: Expecting "(" in parameters_and_qualifiers. [error at 24]

static int __deprecated device_suspend(struct device * device, int pm_policy)

------------------------^



The function is (in device.h):



static inline int __deprecated device_suspend(struct device *device,

int pm_policy)

{

return device->config->dev_pm_ops->suspend(device, pm_policy);

}



*Any idea (I didn’t find what is wrong with it)?*



Thanks in advance,

Amir Kaplan (S/W dev. in wiot )











---------------------------------------------------------------------
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: deprecated issue after push to gerrit - need some help

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

Hi Amir,
Check out this Zephyr wiki note for a workaround: https://wiki.zephyrproject.org/view/Function_Documentation#Workarounds

-- david


From: Kaplan, Amir [mailto:amir.kaplan(a)intel.com]
Sent: Monday, September 12, 2016 7:57 AM
To: devel(a)lists.zephyrproject.org
Subject: [devel] deprecated issue after push to gerrit - need some help

Hi all,

I pushed to : https://gerrit.zephyrproject.org/r/4705

And I got Verified -1 error:

Going to there, and I see:


ERROR: Please fix the documentation warnings
/jenkins/workspace/zephyr-verify/doc/api/power_management_api.rst:16: WARNING: Error when parsing function declaration.
If the function has no return type:
Error in declarator or parameters and qualifiers
Invalid definition: Expected identifier in nested name, got keyword: int [error at 10]
static int __deprecated device_suspend(struct device * device, int pm_policy)
----------^
If the function has a return type:
Error in declarator or parameters and qualifiers
If pointer to member declarator:
Invalid definition: Expected '::' in pointer to member (function). [error at 24]
static int __deprecated device_suspend(struct device * device, int pm_policy)
------------------------^
If declarator-id:
Invalid definition: Expecting "(" in parameters_and_qualifiers. [error at 24]
static int __deprecated device_suspend(struct device * device, int pm_policy)
------------------------^

The function is (in device.h):

static inline int __deprecated device_suspend(struct device *device,
int pm_policy)
{
return device->config->dev_pm_ops->suspend(device, pm_policy);
}

Any idea (I didn't find what is wrong with it)?

Thanks in advance,
Amir Kaplan (S/W dev. in wiot )






---------------------------------------------------------------------
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 Gerrit Digest

donotreply@...
 

NEW within last 24 hours:
- https://gerrit.zephyrproject.org/r/4714 : net: yaip: trivial changes
- https://gerrit.zephyrproject.org/r/4713 : net: yaip: Fix net address state
- https://gerrit.zephyrproject.org/r/4701 : Bluetooth: Controller: Use hci.h for control event handling
- https://gerrit.zephyrproject.org/r/4702 : Bluetooth: HCI: Add read remote version info event
- https://gerrit.zephyrproject.org/r/4723 : Bluetooth: SMP: Distribute local keys over BR/EDR
- https://gerrit.zephyrproject.org/r/4703 : Bluetooth: Controller: Use hci.h for data-control evt handling
- https://gerrit.zephyrproject.org/r/4706 : net: fix a potential refcount leak of SYN buffers
- https://gerrit.zephyrproject.org/r/4730 : Bluetooth: SMP: Add support for sending Pairing Request over BR/EDR
- https://gerrit.zephyrproject.org/r/4729 : Bluetooth: SMP: Add helper for reporting BR/EDR pairing complete
- https://gerrit.zephyrproject.org/r/4728 : Bluetooth: SMP: Add support for Signing Information over BR/EDR
- https://gerrit.zephyrproject.org/r/4727 : Bluetooth: SMP: Add support for Identity Information over BR/EDR
- https://gerrit.zephyrproject.org/r/4726 : Bluetooth: SMP: Add support for LTK derivation from LinkKey
- https://gerrit.zephyrproject.org/r/4725 : Bluetooth: SMP: Allow to force BR/EDR without SC support
- https://gerrit.zephyrproject.org/r/4724 : Bluetooth: SMP: Support Pairing Resonse over BR/EDR
- https://gerrit.zephyrproject.org/r/4722 : Bluetooth: SMP: Support Pairing Failed over BR/EDR
- https://gerrit.zephyrproject.org/r/4721 : Bluetooth: SMP: Support Pairing Request over BR/EDR
- https://gerrit.zephyrproject.org/r/4720 : Bluetooth: SMP: Clear keys on timeout when running over BR/EDR
- https://gerrit.zephyrproject.org/r/4719 : Bluetooth: SMP: Add initial code for BR/EDR support
- https://gerrit.zephyrproject.org/r/4718 : Bluetooth: SMP: Move smp_create_pdu function up in a file
- https://gerrit.zephyrproject.org/r/4717 : net: apps: Add DHCPv4 client sample application
- https://gerrit.zephyrproject.org/r/4716 : net: tests: Add DHCPv4 client unit tests
- https://gerrit.zephyrproject.org/r/4715 : net: yaip: Add DHCPv4 client support
- https://gerrit.zephyrproject.org/r/4712 : net: yaip: Add callbacks on interface for IP address add and rm
- https://gerrit.zephyrproject.org/r/4711 : net: tests: Add include directory only when specific config options enabled
- https://gerrit.zephyrproject.org/r/4710 : net: yaip: Fix IPv4 packet reception
- https://gerrit.zephyrproject.org/r/4709 : net: yaip: Fix typo
- https://gerrit.zephyrproject.org/r/4708 : net: yaip: Fix arp/ethernet broadcast and multcast addr scenario
- https://gerrit.zephyrproject.org/r/4707 : net: yaip: Fix slip multipackets reception
- https://gerrit.zephyrproject.org/r/4704 : power_mgmt: Update sample and drivers according to new pm device API
- https://gerrit.zephyrproject.org/r/4699 : nano_work: Add nano_delayed_work_is_idle
- https://gerrit.zephyrproject.org/r/4705 : power_mgmt: Mark old device pm API functions as deprecated
- https://gerrit.zephyrproject.org/r/4697 : gpio: Remove obsolete API 1.0 callback mechanism
- https://gerrit.zephyrproject.org/r/4694 : tests: fp_sharing: removing dependency on ARCH
- https://gerrit.zephyrproject.org/r/4693 : tests: remove dependency on architecture and use one prj.conf

UPDATED within last 24 hours:
- https://gerrit.zephyrproject.org/r/4101 : tests/mem_safe: place test buffers at the edges of RAM
- https://gerrit.zephyrproject.org/r/4531 : unified/build: allow building the unified kernel
- https://gerrit.zephyrproject.org/r/3527 : console: shell: Shell enhancement - Support multiple modules
- https://gerrit.zephyrproject.org/r/4593 : Clean dev and latest docs sites before deploy
- https://gerrit.zephyrproject.org/r/3924 : lib/http: Add test-case for HTTP header fields
- https://gerrit.zephyrproject.org/r/3922 : lib: Add HTTP support for Zephyr
- https://gerrit.zephyrproject.org/r/4503 : slist: add sys_slist_get() to fetch and remove the head
- https://gerrit.zephyrproject.org/r/4504 : slist: add sys_slist_append_list/slist()
- https://gerrit.zephyrproject.org/r/4447 : Bluetooth: AVDTP: Module Initialization
- https://gerrit.zephyrproject.org/r/4463 : power_mgmt: Update Power Management device driver API
- https://gerrit.zephyrproject.org/r/4562 : Bluetooth: Sample: handsfree sample application
- https://gerrit.zephyrproject.org/r/4632 : arduino_101: don't erase factory 2nd-stage loader
- https://gerrit.zephyrproject.org/r/4346 : net: yaip: Initial architecture documentation
- https://gerrit.zephyrproject.org/r/3461 : bluetooth: adding Direct Test Mode support to shell application
- https://gerrit.zephyrproject.org/r/4139 : TCF: Tags test previously broken by ARC-x86 communication issue
- https://gerrit.zephyrproject.org/r/3895 : tests/kernel/test_multilib: Test for proper multilib selection.
- https://gerrit.zephyrproject.org/r/4480 : fs: Add file system API to flush cache of an open file
- https://gerrit.zephyrproject.org/r/4100 : build: allow specifying a custom linker script relative to project
- https://gerrit.zephyrproject.org/r/4505 : kernel: add CONFIG_MDEF
- https://gerrit.zephyrproject.org/r/4571 : checkpatch: do not check for min_t/max_t
- https://gerrit.zephyrproject.org/r/4502 : dlist: add static initialization macro
- https://gerrit.zephyrproject.org/r/4515 : atomic: fix bug in ATOMIC_INIT()

MERGED within last 24 hours:
- https://gerrit.zephyrproject.org/r/4696 : net: Remove dead sections left by revert
- https://gerrit.zephyrproject.org/r/4700 : Bluetooth: HCI: Add auth payload expiry event
- https://gerrit.zephyrproject.org/r/4698 : Bluetooth: HCI: Fix and extend advertising report events
- https://gerrit.zephyrproject.org/r/4695 : Bluetooth: Pre-allocated RFCOMM Channels
- https://gerrit.zephyrproject.org/r/4692 : build: Make QEMU_BIN_PATH optional
- https://gerrit.zephyrproject.org/r/4691 : build: zephyr: Remove unused QEMU variable
- https://gerrit.zephyrproject.org/r/4532 : fix: net samples no longer include unneeded 802.15.4 files
- https://gerrit.zephyrproject.org/r/4595 : boards: ia32_pci is long gone, use galileo instead
- https://gerrit.zephyrproject.org/r/4371 : win-build: fixes to build with alternative make implementations
- https://gerrit.zephyrproject.org/r/3851 : samples/net: Add a sample for a CoAP server
- https://gerrit.zephyrproject.org/r/3850 : samples/net: Add a sample for a CoAP client
- https://gerrit.zephyrproject.org/r/3853 : MAINTAINERS: add Zoap section
- https://gerrit.zephyrproject.org/r/4549 : samples: move spi tests to tests/
- https://gerrit.zephyrproject.org/r/2076 : sensor: add driver for HP206C sensor
- https://gerrit.zephyrproject.org/r/3439 : spi_qmsi: Add suspend/resume
- https://gerrit.zephyrproject.org/r/4550 : samples: move pci tests to tests/
- https://gerrit.zephyrproject.org/r/3848 : lib: Introduce the CoAP implementation for Zephyr
- https://gerrit.zephyrproject.org/r/3849 : tests: Add simple CoAP tests
- https://gerrit.zephyrproject.org/r/4341 : Bluetooth: HFP HF: Initialize Handsfree profile
- https://gerrit.zephyrproject.org/r/4327 : fix: previously uninitialized variables break DEBUG sanity
- https://gerrit.zephyrproject.org/r/4686 : build: xtools: Honour CROSS_COMPILE (if set)
- https://gerrit.zephyrproject.org/r/4574 : samples: shell: add support for nano/micro kernel
- https://gerrit.zephyrproject.org/r/4685 : build: xtools: Simplify derivation of toolchain flags
- https://gerrit.zephyrproject.org/r/4248 : net: Fix net_send return value documentation
- https://gerrit.zephyrproject.org/r/4661 : dns: Remove deprecated functionality
- https://gerrit.zephyrproject.org/r/4484 : drivers/pinmux: delete deprecated PINMUX_DEV_QUARK_MCU
- https://gerrit.zephyrproject.org/r/4111 : usb: Add USB sample build test to sanity check
- https://gerrit.zephyrproject.org/r/4323 : usb: Allow to register and handle vendor specific commands
- https://gerrit.zephyrproject.org/r/3973 : net: apps: Example app for Trickle algorithm
- https://gerrit.zephyrproject.org/r/4483 : drivers/pinmux: fix CONFIG_PINMUX_DEV_NAME dependency issue
- https://gerrit.zephyrproject.org/r/4004 : arm atmel sam3: Add constants and structures for watchdog registers
- https://gerrit.zephyrproject.org/r/4005 : arm atmel sam3: Disable watchdog timer
- https://gerrit.zephyrproject.org/r/3972 : net: Initial trickle algorithm support for legacy IP stack
- https://gerrit.zephyrproject.org/r/3911 : i2c_qmsi: Implement suspend and resume functions
- https://gerrit.zephyrproject.org/r/3886 : scripts: Port get_maintainer.pl to Zephyr
- https://gerrit.zephyrproject.org/r/3948 : wdt_qmsi: Implement suspend and resume functions
- https://gerrit.zephyrproject.org/r/3894 : power_mgmt: Make device_pm_ops definition static
- https://gerrit.zephyrproject.org/r/3966 : aonpt_qmsi: Implement suspend and resume functions
- https://gerrit.zephyrproject.org/r/2315 : tests: change tags for sensors

6601 - 6620 of 8033