1. devel@lists.zephyrproject.org
  2. Messages
   Date   
logging MACRO LOG_ERR/LOG_INF/LOG_DBG expansion issue

qzhang@...
 

Hi,

I am new to zephyr, I am reading the logging subsystem code and find that 'LOG_ERR/LOG_INF/LOG_DBG ..., etc.' will be expanded finally by below MACRO

looks like even I disable the logging (not set CONFIG_LOG), below code is still remained in the code after the preprocessing, Is my understanding correct or not? does it cause the code bloat?  

/*****************************************************************************/
/****************** Macros for standard logging ******************************/
/*****************************************************************************/
#define Z_LOG2(_level, _source, _dsource, ...) do { \
if (!Z_LOG_CONST_LEVEL_CHECK(_level)) { \
break; \
} \
if (IS_ENABLED(CONFIG_LOG_MINIMAL)) { \
Z_LOG_TO_PRINTK(_level, __VA_ARGS__); \
break; \
} \
\
bool is_user_context = k_is_user_context(); \
uint32_t filters = IS_ENABLED(CONFIG_LOG_RUNTIME_FILTERING) ? \
(_dsource)->filters : 0;\
if (!LOG_CHECK_CTX_LVL_FILTER(is_user_context, _level, filters)) { \
break; \
} \
if (IS_ENABLED(CONFIG_LOG2)) { \
int _mode; \
void *_src = IS_ENABLED(CONFIG_LOG_RUNTIME_FILTERING) ? \
(void *)_dsource : (void *)_source; \
Z_LOG_MSG2_CREATE(UTIL_NOT(IS_ENABLED(CONFIG_USERSPACE)), _mode, \
  CONFIG_LOG_DOMAIN_ID, _src, _level, NULL,\
  0, __VA_ARGS__); \
} else { \
Z_LOG_INTERNAL(is_user_context, _level, \
_source, _dsource, __VA_ARGS__);\
} \
if (false) { \
/* Arguments checker present but never evaluated.*/ \
/* Placed here to ensure that __VA_ARGS__ are*/ \
/* evaluated once when log is enabled.*/ \
z_log_printf_arg_checker(__VA_ARGS__); \
} \
} while (false) 

Br
Quan
problem porting Zephyr to new architecture (Renesas RX65N): architecture-specific GCC is adding leading underscores

Jan Peters
 

Hello all,

I'm part of a team that is porting Zephyr to Renesas RX65N processors, and we have encountered a bit of a problem. The GCC toolchain for the processor (available at https://llvm-gcc-renesas.com/) by default adds leading underscores to C-Symbols. These lead to problems with Zephyr Linker scripts and at least one build-script (gen_handles.py), which do expect symbols from C-code without these underscores. We have contacted the developers of the Renesas GCC and they told us that this a a common behaviour ("for 20 out of the 50 targets of the GCC"). Has this problem been encountered before with other toolchains used to build Zephyr ? Does anyone have an idea how it can be solved (using the GCC option -fno-leading-underscore leads to problems with gcclib, which does assume the leading undescores) ?

Thanks,

Jan
Re: Review of concept of changing UART flow control from Kconfig to DTS config

lairdjm
 

Hi Marti,
Let's say there is a board (all our boards are Nordic-based so this applies to all of them) which has a UART brought out to a header, the UART might be used for a multitude of things, it could be a debug port which is mostly unused, or it could be connected to a PC for exchanging a lot of data, or it could be connected to a shield, perhaps a modem, which does not have flow control pins - this is one board (and one .dts file) but with different requirements for flow control, in the old system this worked fine and flow control could be enabled or disabled on a per-project configuration or even by board/shield overlays (one board but many different projects). With the new system, that isn't possible, this requires unique board .dts files because you can no longer disable or enable flow control via a Kconfig option (yet strangely parity is still a Kconfig option, the change itself doesn't really make sense to me).
The issue is not that it is opt-in or opt-out, the issue is that it is opt-in at a DTS level (and thus a board level) and not opt-in at a project level. If we enable flow control for our board, we need to add overlays to every sample project for all of our boards whereby flow control isn't needed which becomes a mess.
Thanks,
Jamie

-----Original Message-----
From: Bolivar, Marti <Marti.Bolivar@...>
Sent: 13 May 2021 17:11
To: Jamie Mccrae <Jamie.Mccrae@...>; devel@...
Cc: Chruściński, Krzysztof <Krzysztof.Chruscinski@...>
Subject: Re: [Zephyr-devel] Review of concept of changing UART flow control from Kconfig to DTS config

EXTERNAL EMAIL: Be careful with attachments and links.

Hi (and +Krzysztof in Cc),

"lairdjm via lists.zephyrproject.org"
<jamie.mccrae=lairdconnect.com@...> writes:

Hi,
I only noticed today that the Kconfig option for enabling hardware
flow control on UARTs, which used to be an optional Kconfig option,
was removed and replaced with a DTS boards file configuration option
instead, as per
https://github.com/zephyrproject-rtos/zephyr/pull/25999
To be clear, this PR is limited to nRF SoCs only, it is not a project-wide change.

I find this to be a bit of a step backwards for application
development, we have many boards in zephyr that we and customers use,
these boards might be used for something simple like a sensor or might
be used alongside a PC for doing some heavy processing and message
passing over Bluetooth, so with a sensor, the log system might be
active but it won't have anything connected to it most of the time
unless there's an issue, so flow control is not required here, if it's
enabled then it's going to cause an issue once the UART buffer gets
full. However, on a PC communications module, that would be using the
UART constantly, and need data integrity so needs flow control - in
the old system, the boards file would have the flow control pins and
it would be disabled by default, a project could enable it with a
Kconfig option, this was great. However with the new system, it seems
that we need to force flow control on all our boards, and then in
instances where it's not needed, have an overlay for that specific
board (and we have many boards) to delete the hardware flow control
part. This means that to enable hardware flow control, we need to
update our boards file then add an overlay to almost every sample
application in zephyr for most of our boards to disable flow control.
This seems a bit chaotic to me so I would like to revisit this concept
of having flow control configurable as a Kconfig option, the pins
should be defined in the DTS file which hasn't changed but if flow
control is needed or not should be controlled on a project basis, opt
in not opt out.
I'm having a bit of trouble understanding what you mean here.

The boolean hw-flow-control property is still available for enabling hardware flow control for both UART and UARTE:

https://docs.zephyrproject.org/latest/reference/devicetree/bindings/serial/nordic%2Cnrf-uarte.html#dtbinding-nordic-nrf-uarte
https://docs.zephyrproject.org/latest/reference/devicetree/bindings/serial/nordic%2Cnrf-uart.html#dtbinding-nordic-nrf-uart

Looking at the code, if hw-flow-control is disabled in DTS (the default), then in both drivers cfg->flow_ctrl is false. The HAL configuration structure ends up with flow control disabled in that case:

https://github.com/zephyrproject-rtos/zephyr/blob/5f5fb7d7925be3b40b4a963b11fb8b4cfedf03a1/drivers/serial/uart_nrfx_uart.c#L346
https://github.com/zephyrproject-rtos/zephyr/blob/5f5fb7d7925be3b40b4a963b11fb8b4cfedf03a1/drivers/serial/uart_nrfx_uarte.c#L397

So flow control at a SoC level seems to be turned off by default.

It's true that many boards in PR #25999 do enable it by default, e.g.
nRF52840-DK:

https://github.com/zephyrproject-rtos/zephyr/pull/25999/files#diff-f496b12068cf78fdbb22c1b8a4eaeb66010db95b4e80db7377a340ae30a83519R7

But it seems like at a board maintainer level, you can leave the SoC default as-is to make flow control "opt in" as requested.


Are there any thoughts on this subject and how to get this working,
focused on ease of being able to set this for ours and customer's
reuse?
It looks like flow control is off by default and it's opt-in; what did I miss?

Thanks!
Martí

Thanks,
Jamie
Re: [REMINDER] Changing default branch name on GitHub - action required

Kumar Gala
 

Details for how to rename your fork can be found here:

https://github.com/github/renaming

On May 14, 2021, at 3:36 AM, Kumar Gala <kumar.gala@...> wrote:

Reminder to all that this change has gone into effect.

You may additionally want to make this change in your own GitHub fork of Zephyr.

- k

On May 12, 2021, at 10:35 AM, Kumar Gala <kumar.gala@...> wrote:

We will be changing the default branch on github from 'master' to 'main' on Friday (May 14, 2021).

There is no action required for any open PRs, however you'll need to update your local git clone as follows:

git branch -m master main
git fetch origin
git branch -u origin/main main

You'll need to be utilizing at least west 0.10.1 or later.

Will announce here when this change is made on Friday.

I’ve also opened this GitHub discussion on this topic as well:

https://github.com/zephyrproject-rtos/zephyr/discussions/35230

thanks

- k
[REMINDER] Changing default branch name on GitHub - action required

Kumar Gala
 

Reminder to all that this change has gone into effect.

You may additionally want to make this change in your own GitHub fork of Zephyr.

- k

On May 12, 2021, at 10:35 AM, Kumar Gala <kumar.gala@...> wrote:

We will be changing the default branch on github from 'master' to 'main' on Friday (May 14, 2021).

There is no action required for any open PRs, however you'll need to update your local git clone as follows:

git branch -m master main
git fetch origin
git branch -u origin/main main

You'll need to be utilizing at least west 0.10.1 or later.

Will announce here when this change is made on Friday.

I’ve also opened this GitHub discussion on this topic as well:

https://github.com/zephyrproject-rtos/zephyr/discussions/35230

thanks

- k
Re: Review of concept of changing UART flow control from Kconfig to DTS config

Bolivar, Marti
 

Hi (and +Krzysztof in Cc),

"lairdjm via lists.zephyrproject.org"
<jamie.mccrae=lairdconnect.com@...> writes:

Hi,
I only noticed today that the Kconfig option for enabling hardware
flow control on UARTs, which used to be an optional Kconfig option,
was removed and replaced with a DTS boards file configuration option
instead, as per
https://github.com/zephyrproject-rtos/zephyr/pull/25999
To be clear, this PR is limited to nRF SoCs only, it is not a
project-wide change.

I find this to be a bit of a step backwards for application
development, we have many boards in zephyr that we and customers use,
these boards might be used for something simple like a sensor or might
be used alongside a PC for doing some heavy processing and message
passing over Bluetooth, so with a sensor, the log system might be
active but it won't have anything connected to it most of the time
unless there's an issue, so flow control is not required here, if it's
enabled then it's going to cause an issue once the UART buffer gets
full. However, on a PC communications module, that would be using the
UART constantly, and need data integrity so needs flow control - in
the old system, the boards file would have the flow control pins and
it would be disabled by default, a project could enable it with a
Kconfig option, this was great. However with the new system, it seems
that we need to force flow control on all our boards, and then in
instances where it's not needed, have an overlay for that specific
board (and we have many boards) to delete the hardware flow control
part. This means that to enable hardware flow control, we need to
update our boards file then add an overlay to almost every sample
application in zephyr for most of our boards to disable flow control.
This seems a bit chaotic to me so I would like to revisit this concept
of having flow control configurable as a Kconfig option, the pins
should be defined in the DTS file which hasn't changed but if flow
control is needed or not should be controlled on a project basis, opt
in not opt out.
I'm having a bit of trouble understanding what you mean here.

The boolean hw-flow-control property is still available for enabling
hardware flow control for both UART and UARTE:

https://docs.zephyrproject.org/latest/reference/devicetree/bindings/serial/nordic%2Cnrf-uarte.html#dtbinding-nordic-nrf-uarte
https://docs.zephyrproject.org/latest/reference/devicetree/bindings/serial/nordic%2Cnrf-uart.html#dtbinding-nordic-nrf-uart

Looking at the code, if hw-flow-control is disabled in DTS (the
default), then in both drivers cfg->flow_ctrl is false. The HAL
configuration structure ends up with flow control disabled in that case:

https://github.com/zephyrproject-rtos/zephyr/blob/5f5fb7d7925be3b40b4a963b11fb8b4cfedf03a1/drivers/serial/uart_nrfx_uart.c#L346
https://github.com/zephyrproject-rtos/zephyr/blob/5f5fb7d7925be3b40b4a963b11fb8b4cfedf03a1/drivers/serial/uart_nrfx_uarte.c#L397

So flow control at a SoC level seems to be turned off by default.

It's true that many boards in PR #25999 do enable it by default, e.g.
nRF52840-DK:

https://github.com/zephyrproject-rtos/zephyr/pull/25999/files#diff-f496b12068cf78fdbb22c1b8a4eaeb66010db95b4e80db7377a340ae30a83519R7

But it seems like at a board maintainer level, you can leave the SoC
default as-is to make flow control "opt in" as requested.


Are there any thoughts on this subject and how to get this working,
focused on ease of being able to set this for ours and customer's
reuse?
It looks like flow control is off by default and it's opt-in; what did I
miss?

Thanks!
Martí

Thanks,
Jamie
Re: SAMC21 support and subscribe to zephyr development lists.

Michael Hope
 

Hi Romin. There's more information about the devel@ list at https://lists.zephyrproject.org/g/devel including instructions on how to subscribe.

re: the SAMC21, I haven't been involved with the SAM0 work in a while but I also haven't heard of anyone working on that particular family. The SAM0 series is interesting as the families are all similar but slightly incompatible - it should be straight forward for you to add support and adapt the drivers but it's hard to say without diving in!

-- Michael

‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐

On Thursday, May 6th, 2021 at 7:01 PM, Romin Gajjar <rominzephyr@...> wrote:

Hello Zephyr Development Team,

1) I want to subscribe to the  devel@ mailing list.

2) My Colleague and I are working on development of SAMC21 port for Zephyr. Like I have seen D21, D20, E54 etx files in zephyr which I got working with their respective evaluation boards (D21 Xplained )

I would be highly obliged if anybody has any leads on any existing on-going activities  for SAMC21 microcontroller. I have been trying to integrate things but there are many hiccups to build the code considering the clocking style is different for SAMC21 compared to D21 or E54. I have already integrated the ASF files from Microchip studio utilities/cmsis.

Thank you in advance for any slightest piece of information or help for this topic. Even if you could connect me with any on-going development team in the community that shall be greatly appreciated. 

I am really looking forward to some direction or experienced help from your community as I am not an expert at this point.

Yours sincerely,

Romin
Re: Cancelled Event: Zephyr Project: Dev Meeting - Thursday, 13 May 2021 #cal-cancelled

Kumar Gala
 

Canceling this week due to several things:

* I had some last minute meetings that I need to join this week and can’t attend/run the meeting

* Various people have holidays this week, so wasn’t able to coordinate a replacement

* I know we had a topic around the Flash APIs we planned to discuss. I’ll move this to next week

* Let people focus a bit more on bugs to help reduce our bug count this week

thanks

- k

On May 12, 2021, at 5:51 PM, devel@... Calendar <noreply@...> wrote:

Cancelled: Zephyr Project: Dev Meeting

This event has been cancelled.

When:
Thursday, 13 May 2021
3:00pm to 4:00pm
(UTC+00:00) UTC

Where:
Microsoft Teams Meeting

Organizer: devel@...

Description:

________________________________________________________________________________
Join Microsoft Teams Meeting
+1 321-558-6518 United States, Orlando (Toll)
Conference ID: 483 314 739#
Local numbers | Reset PIN | Learn more about Teams | Meeting options


________________________________________________________________________________


<Mail Attachment.ics><invite.ics>
Cancelled Event: Zephyr Project: Dev Meeting - Thursday, 13 May 2021 #cal-cancelled

devel@lists.zephyrproject.org Calendar <noreply@...>
 

Cancelled: Zephyr Project: Dev Meeting

This event has been cancelled.

When:
Thursday, 13 May 2021
3:00pm to 4:00pm
(UTC+00:00) UTC

Where:
Microsoft Teams Meeting

Organizer: devel@...

Description:

________________________________________________________________________________
+1 321-558-6518 United States, Orlando (Toll)
Conference ID: 483 314 739#
Local numbers | Reset PIN | Learn more about Teams | Meeting options
 
 
________________________________________________________________________________

Calendar
Calendar

Changing default branch name on GitHub - action required

Kumar Gala
 

We will be changing the default branch on github from 'master' to 'main' on Friday (May 14, 2021).

There is no action required for any open PRs, however you'll need to update your local git clone as follows:

git branch -m master main
git fetch origin
git branch -u origin/main main

You'll need to be utilizing at least west 0.10.1 or later.

Will announce here when this change is made on Friday.

I’ve also opened this GitHub discussion on this topic as well:

https://github.com/zephyrproject-rtos/zephyr/discussions/35230

thanks

- k
Re: SAMC21 support and subscribe to zephyr development lists.

rominzephyr@...
 

Hi a quick reminder is there any support or development happening? 

Please, I am need of some direction or help from anyone who has done something similar in zephyr.

Yours sincerely,

Romin
Re: using low level sensor drivers directly, without sensor API

Martin Schröder
 

Hi Rudolph, 

If you want to configure FIFO it would make the most sense to do so in the adxl driver. So just modify the driver, perhaps add a boolean dts option for the functionality and then create a pull request to get that functionality accepted into and managed by the main project. 

On Mon, 10 May 2021 at 15:12, Rudolph Aschmoneit <rudolph.aschmoneit@...> wrote:
Hey all,

I'm quite new to Zephyr, and I have definitely not yet understood all the concepts in their full depth. So please excuse me if my question seems a little bit stupid. Is it possible to use the functions of low level sensor drivers directly, without using the sensor API? About the background: I want to use the ADXL372 Sensor in Instant On mode. There is no Kconfig Macro for this. I also do not see any possibility to set the sensor to this mode or configure his FIFO accordingly using the Sensor API. But I found the functions I need in the driver implementation of the sensor (adxl372.c) But I can not use them (they’re definitions are not mentioned in adxl372.h and when I try to add it there, removing the static attribute in their adxl372.c declaration and adding them in the .h file everything becomes very unstable.) So it seems to me, that it is not intended by Zephyr to use this functions in my Applications. And of course I don’t want to write something into the original driver files, this was just for a short test.

I am very grateful for any kind of advice or suggestion!

Thank you a lot in Advance

Best Regards
Rudolph



--
Best regards,

Martin Schröder
Consultant
Review of concept of changing UART flow control from Kconfig to DTS config

lairdjm
 

Hi,

I only noticed today that the Kconfig option for enabling hardware flow control on UARTs, which used to be an optional Kconfig option, was removed and replaced with a DTS boards file configuration option instead, as per https://github.com/zephyrproject-rtos/zephyr/pull/25999

I find this to be a bit of a step backwards for application development, we have many boards in zephyr that we and customers use, these boards might be used for something simple like a sensor or might be used alongside a PC for doing some heavy processing and message passing over Bluetooth, so with a sensor, the log system might be active but it won’t have anything connected to it most of the time unless there’s an issue, so flow control is not required here, if it’s enabled then it’s going to cause an issue once the UART buffer gets full. However, on a PC communications module, that would be using the UART constantly, and need data integrity so needs flow control – in the old system, the boards file would have the flow control pins and it would be disabled by default, a project could enable it with a Kconfig option, this was great. However with the new system, it seems that we need to force flow control on all our boards, and then in instances where it’s not needed, have an overlay for that specific board (and we have many boards) to delete the hardware flow control part. This means that to enable hardware flow control, we need to update our boards file then add an overlay to almost every sample application in zephyr for most of our boards to disable flow control. This seems a bit chaotic to me so I would like to revisit this concept of having flow control configurable as a Kconfig option, the pins should be defined in the DTS file which hasn’t changed but if flow control is needed or not should be controlled on a project basis, opt in not opt out.

 

Are there any thoughts on this subject and how to get this working, focused on ease of being able to set this for ours and customer’s reuse?

Thanks,

Jamie
Re: using low level sensor drivers directly, without sensor API

William Fish
 

Rudolph,
With the Zephyr project being open source, if you would find it useful for someone in the future to access this functionality you should raise either a RFC or PR in the GitHub.

You should find the community fairly helpful in appraising and assisting with making changes.

Billy..
Zephyr Project: APIs - Tue, 05/11/2021 4:00pm-5:00pm, Please RSVP #cal-reminder

devel@lists.zephyrproject.org Calendar <devel@...>
 

Reminder: Zephyr Project: APIs

When: Tuesday, 11 May 2021, 4:00pm to 5:00pm, (GMT+00:00) UTC

Where:Microsoft Teams Meeting

An RSVP is requested. Click here to RSVP

Organizer: devel@...

Description:

Meeting decisions/discussions in their respective PRs, tracked here: https://github.com/zephyrproject-rtos/zephyr/projects/18


________________________________________________________________________________
+1 321-558-6518 United States, Orlando (Toll)
Conference ID: 317 990 129#
Local numbers | Reset PIN | Learn more about Teams | Meeting options
 
 
________________________________________________________________________________
API meeting: agenda

Carles Cufi
 

Zephyr Memory Footprint - biweekly discussion - Mon, 05/10/2021 3:00pm-4:00pm, Please RSVP #cal-reminder

devel@lists.zephyrproject.org Calendar <devel@...>
 

Reminder: Zephyr Memory Footprint - biweekly discussion

When: Monday, 10 May 2021, 3:00pm to 4:00pm, (GMT+00:00) UTC

Where:Microsoft Teams Meeting

An RSVP is requested. Click here to RSVP

Organizer: devel@...

Description: Working doc: https://docs.google.com/document/d/1bnQLJKVhgI3zkk3MsSXun8onEsA8z1Rf5ohdbCHASmU/edit#heading=h.x36xe8bnwr9r

________________________________________________________________________________
Microsoft Teams meeting
Join on your computer or mobile app
Click here to join the meeting
Or call in (audio only)
+1 321-558-6518,,546018126# United States, Orlando
Phone Conference ID: 546 018 126#
 
 
________________________________________________________________________________
using low level sensor drivers directly, without sensor API

Rudolph Aschmoneit <rudolph.aschmoneit@...>
 

Hey all,

I'm quite new to Zephyr, and I have definitely not yet understood all the concepts in their full depth. So please excuse me if my question seems a little bit stupid. Is it possible to use the functions of low level sensor drivers directly, without using the sensor API? About the background: I want to use the ADXL372 Sensor in Instant On mode. There is no Kconfig Macro for this. I also do not see any possibility to set the sensor to this mode or configure his FIFO accordingly using the Sensor API. But I found the functions I need in the driver implementation of the sensor (adxl372.c) But I can not use them (they’re definitions are not mentioned in adxl372.h and when I try to add it there, removing the static attribute in their adxl372.c declaration and adding them in the .h file everything becomes very unstable.) So it seems to me, that it is not intended by Zephyr to use this functions in my Applications. And of course I don’t want to write something into the original driver files, this was just for a short test.

I am very grateful for any kind of advice or suggestion!

Thank you a lot in Advance

Best Regards
Rudolph
Zephyr 2.6.0-rc1 tagged

Kumar Gala
 

Hi all,

The first release candidate for Zephyr 2.6.0 has been tagged (v2.6.0-rc1).

The merge window for features and enhancements is now closed for this release, and it will remain closed until 2.6.0 is released; the stabilization period is now open. During the stabilization period only bug-fix, documentation, and stabilization-related patches may be merged to master. Additional features or enhancements for the 2.6.0 release require approval by the TSC.

We currently have the following bug counts:

* High - 5
* Medium - 41
* Low - 152

The goal for release is to be at:
* High - 0
* Medium < 20
* Low < 50

We have a long way to go on lows!

As we need to reduce bug counts for the release, you are all encouraged to submit PRs that close existing bug reports, and to help reviewing such PRs submitted by other contributors or maintainers. You can follow the bug numbers with the thresholds for each bug category here:

https://testing.zephyrproject.org/issues/zephyrproject-rtos/zephyr/index.html

Testing Zephyr master branch during the stabilization period is also requested; please test the code base and file bug reports so they can be addressed before the release deadline. Everyone is encouraged, especially hardware vendors, to test on hardware available to them. Use twister to run tests from the Zephyr tree on the boards you have using the device testing features.

The full release log can be found here:

https://github.com/zephyrproject-rtos/zephyr/releases/tag/v2.6.0-rc1

We plan to release weekly candidates (2.6.0-rcx) leading to the final release (2.6.0) which is tentatively scheduled for 28 May.

You may continue to submit pull requests for new features in order to gather feedback early or collaborate with others, but the release team would like to encourage everyone to focus on bugfixes and documentation improvements to the largest extent possible, so that we can release 2.6.0 on time and in the best shape possible.

A big Thank You to everyone that contributed to this release so far, be it with code, reviews, documentation or any other type of contribution!

Kumar
API: Remove support for `GPIO_INT_*` flags in `gpio_pin_configure()` function

Piotr Mienkowski
 

Hi all,

This is to let you know that we are going to remove support for passing `GPIO_INT_*` flags to `gpio_pin_configure()` function. The feature has been deprecated in the Zephyr 2.2 release. The interrupt flags will be accepted by `gpio_pin_interrupt_configure()` function only.

Regards,
Piotr
821 - 840 of 8574