Sure. Below are a summary of the API and changes. Please let me know if anything else needs to be mentioned and I can add. The generic counter API will support 4 functions as summarized below. Based

Before starting, send out a summary of what you're going to change as a final RFC please.

Since this RFC has been quietly for a while and it seems we have reached a good amount of feedback so we will implement it and update the current patch.

Hi Tomasz, I realize this typedef is inherited from the original code, but do we really need/want to enforce an opaque type here? The general preference with the coding style (inherited from Linux

Tomasz Bursztyka <tomasz.bursztyka(a)linux.intel.com> writes: I am just wondering that in the "old" API '_port_enable_callback()' was a way to have the callback called with the pins expressed in a

Hi Iván, It's 2 different features: - one (un)install a callback function (and the pins it's interested in) - one enable or disable the interrupt trigger (and keeps track of it) of one pin. You

Hi Vinicius, gpio_port_callback() make the callback called, whatever pins is triggering the interrupt and enabled or not (callback wise). So they are different (documentation could be better

Consider there's a set/unset function in those changes, do we need to enable? Can't we infer from the callbacks the user sets?

Hi, Sorry if I am a little too late. Tomasz Bursztyka <tomasz.bursztyka(a)linux.intel.com> writes: Another issue of the current API is the confusion caused by 'gpio_port_enable_callback()' and

When I say it's untested, it's for real ... should be *callback here. With new api, this would call all callback handles, whatever is their pin_mask. (see _gpio_fire_callbacks())

Hi, I quickly went through prototyping something, only to detail the RFC (so it's not really tested etc...) Also, it's not something that I am planning to send right away as it breaks the former

Hi, Zephyr v1.1.0 was tagged 2 days ago and merge window for the next release is no open. Release notes and other details will be posted on the website. Here is the log of changes since the

Hi, How is this logging infra RFC going? :) Just noticed one thing to change as well: include/misc/__assert.h Would be nice if those __ASSERT macros would use this logging facilities as

Hi, I've uploaded another patchset. Some of the patches have only gone through updates. Specifically clock_control and the base st_stm32 tree patch. I've decided to keep the RCC driver MCU specific.

As for me, it's a very good aproach for drivers in general. At the very least, it reduces interrupt latency. Keeping in mind the fact that some drivers support callback functions, it may be

I have created a JIRA to address this @ https://jira.zephyrproject.org/browse/ZEP-89 ----- Daniel Leung

Hi Maciek, Would be great to generalize as much as possible now. At least for what's concerning stm32. For instance, maybe gpio/pinmuxer could be generalized as well that way. Tomasz

Hi, Quoting Nashif, Anas (2016-03-04 09:34:45) Nice, let's move on with this convention. I'll send patches to gerrit soon. Thanks all, Andre

Yes please, Thanks. Anas

That's great. I'll definitely take a look at it. Can you check if drivers in the patchset that I posted are useful for you? Specifically, the UART driver might be reusable across a larger number of