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

Hej Maciek, I added stm32f4 support to your stm32 patch: https://gerrit.zephyrproject.org/r/#/c/671/ Code is tested to run on Nucleo board included it the patch. Cheers, Pawel

Hi Andre, Tomasz, Jesus, Thanks for your feedbacks. I updated the API with these feedbacks. Please correct or if I missed any part that needed to be reflected. The updated API looks like

Hi all, Quoting Jesus Sanchez-Palencia (2016-03-02 16:03:22) Yes, this is the idea. Back then, I reviewed the error codes usages and this was what I had in mind: DEV_OK = 0 DEV_FAIL =

Hi everyone, Benjamin Walsh <benjamin.walsh(a)windriver.com> wrote: After all the feedback so far (thanks, btw!), the updated list now looks like: DEV_OK = 0 DEV_FAIL =

I think -ENOTSUP is a 1-1 match here: ENOTSUP Operation not supported (POSIX.1)