Date   

Re: Functional Safety Certification

Hibberd, Amber M
 

Hi Thomas,

 

I am the Safety Architect for the Zephyr Project. I set up time with you 11/23 at 9:30 am PST to meet and chat about ZP safety plans.

 

Best,

Amber

 

From: devel@... <devel@...> On Behalf Of Thomas Langaas
Sent: Saturday, November 13, 2021 1:40 AM
To: devel@...
Subject: [Zephyr-devel] Functional Safety Certification

 

Hi,

 

Is there some more details about the functional safety certification for Zephyr, or is there someone who can give me some more information?  I'm working with a company that is considering Zephyr for some of it's products but this requires functional safety certification.  Right now, the most promising options are FreeRTOS and SafeRTOS...

 

 

--

Best regards,

Thomas Langås


Functional Safety Certification

Thomas Langaas
 

Hi,

Is there some more details about the functional safety certification for Zephyr, or is there someone who can give me some more information?  I'm working with a company that is considering Zephyr for some of it's products but this requires functional safety certification.  Right now, the most promising options are FreeRTOS and SafeRTOS...


--
Best regards,
Thomas Langås


clock peripheral zephyr APIs for nordic boards #nrf52

ubaidunited@...
 

Hi,

I need to understand the available zephyr APIs that can let me turn off & turn on the available LFCLK in nordic board.

I found options like:

static inline int clock_control_on(const struct device *dev, clock_control_subsys_t sys)

static inline int clock_control_off(const struct device *dev, clock_control_subsys_t sys)

void z_nrf_clock_control_lf_on(enum nrf_lfclk_start_mode start_mode)

 

I do understand that all of this is done through the configurations in prj.conf.

But i want to know which APIs are responsible for it and how to call those APIs for LFCLK..?

As in if i call clock_control_on( ), how do i populate the arguments *dev and sys..?

Thanks,


Re: Trusted firmware update date

Kevin Townsend
 

Hi Jamie,

We'll have to evalute the complexity of the changes from TF-M, but if there are no major breaking changes to the build system, etc., it should be possible to update for the next Zephyr release cycle. We'll need at least an RC1 or RC2 for TF-M before doing the Zephyr PR, though.

Kevin


On Fri, 12 Nov 2021 at 10:15, lairdjm <jamie.mccrae@...> wrote:
Hi,
We have some board file changes to make for when the next release of TF-M is pulled into zephyr, there is an upcoming TF-M release for version 1.5.0 on Monday - will 1.5.0 be used for the upcoming 3.0 release of Zephyr and if so, what is the expected date of pulling it in? 
Thanks,
Jamie


Trusted firmware update date

lairdjm
 

Hi,
We have some board file changes to make for when the next release of TF-M is pulled into zephyr, there is an upcoming TF-M release for version 1.5.0 on Monday - will 1.5.0 be used for the upcoming 3.0 release of Zephyr and if so, what is the expected date of pulling it in? 
Thanks,
Jamie


Cancelled Event: Zephyr: Power Management Sync - Thursday, November 11, 2021 #cal-cancelled

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

Cancelled: Zephyr: Power Management Sync

This event has been cancelled.

When:
Thursday, November 11, 2021
11:00am to 12:00pm
(UTC-08:00) America/Los Angeles

Where:
Microsoft Teams

Organizer: devel@...

Description:


________________________________________________________________________________
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,,677440320# United States, Orlando
Phone Conference ID: 677 440 320#
 
________________________________________________________________________________


Event: Zephyr Project: Dev Meeting - 11/11/2021 #cal-reminder

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

Reminder: Zephyr Project: Dev Meeting

When:
11/11/2021
8:00am to 9:00am
(UTC-08:00) America/Los Angeles

Where:
Microsoft Teams Meeting

Organizer: devel@...

An RSVP is requested. Click here to RSVP

Description:

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


Re: Dev-Review Meeting Agenda Nov 11th

Kumar Gala
 

(Correcting Subject to Nov 11th)

On Nov 10, 2021, at 12:18 PM, Kumar Gala via lists.zephyrproject.org <kumar.gala=linaro.org@lists.zephyrproject.org> wrote:

All,

Originally we planned on discussing sensors this week, but that will get pushed to next week (Nov 18th). I’ll be out this week and Carles will run the meeting.

Agenda for the week:

doc: replace breathe with Sphinx-Doxygen bridge
- https://github.com/zephyrproject-rtos/zephyr/pull/39702

soc: esp32: Support booting from MCUboot
- https://github.com/zephyrproject-rtos/zephyr/pull/37872

Plus anything anyone else has.

- k




Dev-Review Meeting Agenda Oct 14th

Kumar Gala
 

All,

Originally we planned on discussing sensors this week, but that will get pushed to next week (Nov 18th). I’ll be out this week and Carles will run the meeting.

Agenda for the week:

doc: replace breathe with Sphinx-Doxygen bridge
- https://github.com/zephyrproject-rtos/zephyr/pull/39702

soc: esp32: Support booting from MCUboot
- https://github.com/zephyrproject-rtos/zephyr/pull/37872

Plus anything anyone else has.

- k


Event: Zephyr Project: APIs - 11/09/2021 #cal-reminder

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

Reminder: Zephyr Project: APIs

When:
11/09/2021
9:00am to 10:00am
(UTC-08:00) America/Los Angeles

Where:
Microsoft Teams Meeting

Organizer: devel@...

An RSVP is requested. Click here to RSVP

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
 
 
________________________________________________________________________________


Re: API meeting: agenda

Burdick, Thomas
 

Hi Carles,

I'd like to discuss the stats work I've done for i2c if possible, its on the API project in TODO

Thanks!

Tom

-----Original Message-----
From: devel@lists.zephyrproject.org <devel@lists.zephyrproject.org> On Behalf Of Carles Cufi via lists.zephyrproject.org
Sent: Tuesday, November 9, 2021 5:48 AM
To: devel@lists.zephyrproject.org
Cc: Bursztyka, Tomasz <tomasz.bursztyka@intel.com>
Subject: [Zephyr-devel] API meeting: agenda

Hi all,

Agenda for today:

- SPI API updates
- Issue: https://github.com/zephyrproject-rtos/zephyr/issues/39992

- PM structure optimization: Update
- Issue: https://github.com/zephyrproject-rtos/zephyr/issues/39286
- PR (option 4): https://github.com/zephyrproject-rtos/zephyr/pull/39397

- Road to pinctrl: Update
- Issue: https://github.com/zephyrproject-rtos/zephyr/issues/39740

If you have additional items please let me know.

Teams link: https://teams.microsoft.com/l/meetup-join/19%3ameeting_NWU2MjZlYWEtZDcwMi00MWQzLTgwMjEtNDdkYjQwMjBjMmFj%40thread.v2/0?context=%7b%22Tid%22%3a%22af0096d9-700c-411a-b795-b3dd7122bad2%22%2c%22Oid%22%3a%22841a7c92-7816-4faf-9887-5e334e88f6d8%22%7d

https://lists.zephyrproject.org/g/devel/calendar
https://github.com/zephyrproject-rtos/zephyr/projects/18

Minutes:
https://docs.google.com/document/d/1lv-8B5QE2m4FjBcvfqAXFIgQfW5oz6306zJ7GIZIWCk/edit

Regards,

Carles


Re: API meeting: agenda

Carles Cufi
 

Hi all,

Another item for today:

- I2C stats
- PR: https://github.com/zephyrproject-rtos/zephyr/pull/39788

Thanks,

Carles

-----Original Message-----
From: Cufi, Carles
Sent: 09 November 2021 12:48
To: devel@lists.zephyrproject.org
Cc: Bursztyka, Tomasz <tomasz.bursztyka@intel.com>
Subject: API meeting: agenda

Hi all,

Agenda for today:

- SPI API updates
- Issue: https://github.com/zephyrproject-rtos/zephyr/issues/39992

- PM structure optimization: Update
- Issue: https://github.com/zephyrproject-rtos/zephyr/issues/39286
- PR (option 4): https://github.com/zephyrproject-rtos/zephyr/pull/39397

- Road to pinctrl: Update
- Issue: https://github.com/zephyrproject-rtos/zephyr/issues/39740

If you have additional items please let me know.

Teams link: https://teams.microsoft.com/l/meetup-
join/19%3ameeting_NWU2MjZlYWEtZDcwMi00MWQzLTgwMjEtNDdkYjQwMjBjMmFj%40threa
d.v2/0?context=%7b%22Tid%22%3a%22af0096d9-700c-411a-b795-
b3dd7122bad2%22%2c%22Oid%22%3a%22841a7c92-7816-4faf-9887-
5e334e88f6d8%22%7d

https://lists.zephyrproject.org/g/devel/calendar
https://github.com/zephyrproject-rtos/zephyr/projects/18

Minutes:
https://docs.google.com/document/d/1lv-
8B5QE2m4FjBcvfqAXFIgQfW5oz6306zJ7GIZIWCk/edit

Regards,

Carles


API meeting: agenda

Carles Cufi
 


Re: Issue with k_poll

Venkatesh Sukumaran
 


On Mon, Nov 8, 2021 at 11:27 PM Andy Ross <andrew.j.ross@...> wrote:
Can you submit that as a github bug?  I don't know that I see it, but if you're sure that it can happen it's something we need to fix.

Andy

From: Venkatesh Sukumaran <venkatesh.sukumaran@...>
Sent: Monday, November 8, 2021 9:39 AM
To: Ross, Andrew J <andrew.j.ross@...>
Cc: Cufi, Carles <Carles.Cufi@...>; devel@... <devel@...>; Leung, Daniel <daniel.leung@...>
Subject: Re: [Zephyr-devel] Issue with k_poll
 
I understand that the number of wakeups is not equal to the number of events signalled but the problem here is that the pending thread can *miss* a signal. The "signalled" field is being reset to zero by the pending thread after servicing the signal handler and at that time, the same signal could be set again.

Thanks,
- Venkatesh.


On Mon, Nov 8, 2021 at 6:54 PM Andy Ross <andrew.j.ross@...> wrote:
That's right:  k_poll() is level triggered, it's not a queue.  The number of wakeups is not guaranteed to be equal to the number of events signalled.  The idea is that you go to sleep waiting on any of a number of events/things to occur and are woken up when at least one of them does.  But then you need to do the accounting yourself to figure out who was signaled (and how many times) and what should happen.

In this particular use case it sounds like you should be polling on a semaphore and not a signal.  Semaphores do provide proper counting of how many give/take calls are made.

Andy

From: Cufi, Carles <Carles.Cufi@...>
Sent: Monday, November 8, 2021 1:12 AM
To: venkatesh.sukumaran@... <venkatesh.sukumaran@...>; devel@... <devel@...>; Ross, Andrew J <andrew.j.ross@...>; Leung, Daniel <daniel.leung@...>
Subject: RE: [Zephyr-devel] Issue with k_poll
 

+ Andy, Daniel

 

From: devel@... <devel@...> On Behalf Of Venkatesh Sukumaran via lists.zephyrproject.org
Sent: 08 November 2021 08:08
To: devel@...
Subject: Re: [Zephyr-devel] Issue with k_poll

 

Anyone familiar with k_poll architecture here? Let me know if you need any other info.


Thanks,

- Venkatesh.

 

 

On Wed, Oct 27, 2021 at 12:47 PM Venkatesh Sukumaran <venkatesh.sukumaran@...> wrote:

Hi Zephyr developers,

 

I was looking at the k_poll mechanism in Zephyr and found that it can potentially miss events from the producer in SMP when the following happens:

 

1) Set up a bunch of events with K_POLL_TYPE_SIGNAL and K_POLL_MODE_NOTIFY_ONLY.

2) A producer thread calls k_poll_signal_raise() to set the "signalled" field to 1 for event X in the list above.

3) The destination/consumer thread is already in the middle of processing of events and finds the same event X "raised" (from a previous signal_raise() call maybe), runs the handler for the event to completion and sets the "signalled" field to zero.

4) Destination thread goes back to k_poll to pend on events.

 

Now depending how 2) and 3) are ordered - step 3) could set "signalled" back to zero and lose the update from the producer thread in step 2).

 

Am I missing something here? Shouldn't we take a snapshot of the events/signals when exiting k_poll in the critical section and pass that to the destination thread? Once, a thread calls k_poll again then "OR" the pending events with events that the thread has not handled so far (if any)?


Thanks,

- Venkatesh.


RISC-V: mtvec: Vectored Mode

William <wpatty24@...>
 


Hi all,

I would like to add support for "vectored mode" of the Machine Trap-Vector Base-Address Register (mtvec) to the RISC-V architecture — at the SOC level. Some SOCs have already implemented this directly. It makes sense to centralize this feature since it could be reused for all RISC-V SOCs. Additionally, centralizing the feature would allow RISC-V to support Zephyr’s ‘direct’ IRQ feature when vectored mode is used. Im interested to hear if others agree that this feature would be useful.

For background purposes, I’m working on a project that uses the lowRISC Ibex processor. This processor implements the RISC-V Privileged Architecture specification; however, it doesn’t support mtvec direct mode, only vectored mode.

Given that the vectored mode is in the RISC-V Privileged Architecture specification, it should be supported within the RISCV_PRIVILEGE SOC family. 

Here’s what I’m proposing:

  • Add ‘config RISCV_MTVEC_VECTORED_MODE to “soc/riscv/riscv-privilege/Kconfig’; default will be DIRECT_MODE which is how it is implemented currently
  • Add preprocessor conditions to handle both cases within “soc/riscv/riscv-privilege/common/vector.S”
  • Take advantage of CONFIG_GEN_IRQ_VECTOR_TABLE to generate the vector table to use for mtvec
  • For vectored mode, mtvec will be set to the address of the Zephyr generated IRQ Table (_irq_vector_table symbol)
  • Add a default implementation for _isr_wrapper that’s simply a jump to __irq_wrapper; RISC-V uses CONFIG_GEN_SW_ISR_TABLE.
  • [Future] Enable Zephyr’s ‘direct’ IRQ feature when VECTORED_MODE configuration is set. There are more specifics to discuss here but that can wait until if / when this feature is added. 

However, there is one aspect that’s more complicated:

  • Per the RISC-V Privileged Architecture specification, setting vectored mode may impose additional alignment constraints on the address stored in mtvec. This implies that each processor can have it’s own alignment constraints. If we want to take advantage of Zephyr’s CONFIG_GEN_IRQ_VECTOR_TABLE option, we would need to force correct alignment on _irq_vector_table symbol. We should decide on a “good default” but have a mechanism where alignment could be changed for a specific SOC series. It probably makes sense to enforce the alignment in the default RISC-V linker script. However, linker scripts are not my strong suit and I’m not confident on the approach for this aspect of the change. Any ideas would be welcomed.

I appreciate you taking the time to read this. I look forward to any discussion this proposal might create.

Thanks,
William


Re: Issue with k_poll

Andy Ross
 

Can you submit that as a github bug?  I don't know that I see it, but if you're sure that it can happen it's something we need to fix.

Andy


From: Venkatesh Sukumaran <venkatesh.sukumaran@...>
Sent: Monday, November 8, 2021 9:39 AM
To: Ross, Andrew J <andrew.j.ross@...>
Cc: Cufi, Carles <Carles.Cufi@...>; devel@... <devel@...>; Leung, Daniel <daniel.leung@...>
Subject: Re: [Zephyr-devel] Issue with k_poll
 
I understand that the number of wakeups is not equal to the number of events signalled but the problem here is that the pending thread can *miss* a signal. The "signalled" field is being reset to zero by the pending thread after servicing the signal handler and at that time, the same signal could be set again.

Thanks,
- Venkatesh.


On Mon, Nov 8, 2021 at 6:54 PM Andy Ross <andrew.j.ross@...> wrote:
That's right:  k_poll() is level triggered, it's not a queue.  The number of wakeups is not guaranteed to be equal to the number of events signalled.  The idea is that you go to sleep waiting on any of a number of events/things to occur and are woken up when at least one of them does.  But then you need to do the accounting yourself to figure out who was signaled (and how many times) and what should happen.

In this particular use case it sounds like you should be polling on a semaphore and not a signal.  Semaphores do provide proper counting of how many give/take calls are made.

Andy

From: Cufi, Carles <Carles.Cufi@...>
Sent: Monday, November 8, 2021 1:12 AM
To: venkatesh.sukumaran@... <venkatesh.sukumaran@...>; devel@... <devel@...>; Ross, Andrew J <andrew.j.ross@...>; Leung, Daniel <daniel.leung@...>
Subject: RE: [Zephyr-devel] Issue with k_poll
 

+ Andy, Daniel

 

From: devel@... <devel@...> On Behalf Of Venkatesh Sukumaran via lists.zephyrproject.org
Sent: 08 November 2021 08:08
To: devel@...
Subject: Re: [Zephyr-devel] Issue with k_poll

 

Anyone familiar with k_poll architecture here? Let me know if you need any other info.


Thanks,

- Venkatesh.

 

 

On Wed, Oct 27, 2021 at 12:47 PM Venkatesh Sukumaran <venkatesh.sukumaran@...> wrote:

Hi Zephyr developers,

 

I was looking at the k_poll mechanism in Zephyr and found that it can potentially miss events from the producer in SMP when the following happens:

 

1) Set up a bunch of events with K_POLL_TYPE_SIGNAL and K_POLL_MODE_NOTIFY_ONLY.

2) A producer thread calls k_poll_signal_raise() to set the "signalled" field to 1 for event X in the list above.

3) The destination/consumer thread is already in the middle of processing of events and finds the same event X "raised" (from a previous signal_raise() call maybe), runs the handler for the event to completion and sets the "signalled" field to zero.

4) Destination thread goes back to k_poll to pend on events.

 

Now depending how 2) and 3) are ordered - step 3) could set "signalled" back to zero and lose the update from the producer thread in step 2).

 

Am I missing something here? Shouldn't we take a snapshot of the events/signals when exiting k_poll in the critical section and pass that to the destination thread? Once, a thread calls k_poll again then "OR" the pending events with events that the thread has not handled so far (if any)?


Thanks,

- Venkatesh.


Re: Issue with k_poll

Venkatesh Sukumaran
 

I understand that the number of wakeups is not equal to the number of events signalled but the problem here is that the pending thread can *miss* a signal. The "signalled" field is being reset to zero by the pending thread after servicing the signal handler and at that time, the same signal could be set again.

Thanks,
- Venkatesh.


On Mon, Nov 8, 2021 at 6:54 PM Andy Ross <andrew.j.ross@...> wrote:
That's right:  k_poll() is level triggered, it's not a queue.  The number of wakeups is not guaranteed to be equal to the number of events signalled.  The idea is that you go to sleep waiting on any of a number of events/things to occur and are woken up when at least one of them does.  But then you need to do the accounting yourself to figure out who was signaled (and how many times) and what should happen.

In this particular use case it sounds like you should be polling on a semaphore and not a signal.  Semaphores do provide proper counting of how many give/take calls are made.

Andy

From: Cufi, Carles <Carles.Cufi@...>
Sent: Monday, November 8, 2021 1:12 AM
To: venkatesh.sukumaran@... <venkatesh.sukumaran@...>; devel@... <devel@...>; Ross, Andrew J <andrew.j.ross@...>; Leung, Daniel <daniel.leung@...>
Subject: RE: [Zephyr-devel] Issue with k_poll
 

+ Andy, Daniel

 

From: devel@... <devel@...> On Behalf Of Venkatesh Sukumaran via lists.zephyrproject.org
Sent: 08 November 2021 08:08
To: devel@...
Subject: Re: [Zephyr-devel] Issue with k_poll

 

Anyone familiar with k_poll architecture here? Let me know if you need any other info.


Thanks,

- Venkatesh.

 

 

On Wed, Oct 27, 2021 at 12:47 PM Venkatesh Sukumaran <venkatesh.sukumaran@...> wrote:

Hi Zephyr developers,

 

I was looking at the k_poll mechanism in Zephyr and found that it can potentially miss events from the producer in SMP when the following happens:

 

1) Set up a bunch of events with K_POLL_TYPE_SIGNAL and K_POLL_MODE_NOTIFY_ONLY.

2) A producer thread calls k_poll_signal_raise() to set the "signalled" field to 1 for event X in the list above.

3) The destination/consumer thread is already in the middle of processing of events and finds the same event X "raised" (from a previous signal_raise() call maybe), runs the handler for the event to completion and sets the "signalled" field to zero.

4) Destination thread goes back to k_poll to pend on events.

 

Now depending how 2) and 3) are ordered - step 3) could set "signalled" back to zero and lose the update from the producer thread in step 2).

 

Am I missing something here? Shouldn't we take a snapshot of the events/signals when exiting k_poll in the critical section and pass that to the destination thread? Once, a thread calls k_poll again then "OR" the pending events with events that the thread has not handled so far (if any)?


Thanks,

- Venkatesh.


Event: Zephyr Memory Footprint - biweekly discussion - 11/08/2021 #cal-reminder

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

Reminder: Zephyr Memory Footprint - biweekly discussion

When:
11/08/2021
8:00am to 9:00am
(UTC-08:00) America/Los Angeles

Where:
Microsoft Teams Meeting

Organizer: devel@...

An RSVP is requested. Click here to RSVP

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#
 
 
________________________________________________________________________________


Re: Issue with k_poll

Andy Ross
 

That's right:  k_poll() is level triggered, it's not a queue.  The number of wakeups is not guaranteed to be equal to the number of events signalled.  The idea is that you go to sleep waiting on any of a number of events/things to occur and are woken up when at least one of them does.  But then you need to do the accounting yourself to figure out who was signaled (and how many times) and what should happen.

In this particular use case it sounds like you should be polling on a semaphore and not a signal.  Semaphores do provide proper counting of how many give/take calls are made.

Andy


From: Cufi, Carles <Carles.Cufi@...>
Sent: Monday, November 8, 2021 1:12 AM
To: venkatesh.sukumaran@... <venkatesh.sukumaran@...>; devel@... <devel@...>; Ross, Andrew J <andrew.j.ross@...>; Leung, Daniel <daniel.leung@...>
Subject: RE: [Zephyr-devel] Issue with k_poll
 

+ Andy, Daniel

 

From: devel@... <devel@...> On Behalf Of Venkatesh Sukumaran via lists.zephyrproject.org
Sent: 08 November 2021 08:08
To: devel@...
Subject: Re: [Zephyr-devel] Issue with k_poll

 

Anyone familiar with k_poll architecture here? Let me know if you need any other info.


Thanks,

- Venkatesh.

 

 

On Wed, Oct 27, 2021 at 12:47 PM Venkatesh Sukumaran <venkatesh.sukumaran@...> wrote:

Hi Zephyr developers,

 

I was looking at the k_poll mechanism in Zephyr and found that it can potentially miss events from the producer in SMP when the following happens:

 

1) Set up a bunch of events with K_POLL_TYPE_SIGNAL and K_POLL_MODE_NOTIFY_ONLY.

2) A producer thread calls k_poll_signal_raise() to set the "signalled" field to 1 for event X in the list above.

3) The destination/consumer thread is already in the middle of processing of events and finds the same event X "raised" (from a previous signal_raise() call maybe), runs the handler for the event to completion and sets the "signalled" field to zero.

4) Destination thread goes back to k_poll to pend on events.

 

Now depending how 2) and 3) are ordered - step 3) could set "signalled" back to zero and lose the update from the producer thread in step 2).

 

Am I missing something here? Shouldn't we take a snapshot of the events/signals when exiting k_poll in the critical section and pass that to the destination thread? Once, a thread calls k_poll again then "OR" the pending events with events that the thread has not handled so far (if any)?


Thanks,

- Venkatesh.


Re: Issue with k_poll

Carles Cufi
 

+ Andy, Daniel

 

From: devel@... <devel@...> On Behalf Of Venkatesh Sukumaran via lists.zephyrproject.org
Sent: 08 November 2021 08:08
To: devel@...
Subject: Re: [Zephyr-devel] Issue with k_poll

 

Anyone familiar with k_poll architecture here? Let me know if you need any other info.


Thanks,

- Venkatesh.

 

 

On Wed, Oct 27, 2021 at 12:47 PM Venkatesh Sukumaran <venkatesh.sukumaran@...> wrote:

Hi Zephyr developers,

 

I was looking at the k_poll mechanism in Zephyr and found that it can potentially miss events from the producer in SMP when the following happens:

 

1) Set up a bunch of events with K_POLL_TYPE_SIGNAL and K_POLL_MODE_NOTIFY_ONLY.

2) A producer thread calls k_poll_signal_raise() to set the "signalled" field to 1 for event X in the list above.

3) The destination/consumer thread is already in the middle of processing of events and finds the same event X "raised" (from a previous signal_raise() call maybe), runs the handler for the event to completion and sets the "signalled" field to zero.

4) Destination thread goes back to k_poll to pend on events.

 

Now depending how 2) and 3) are ordered - step 3) could set "signalled" back to zero and lose the update from the producer thread in step 2).

 

Am I missing something here? Shouldn't we take a snapshot of the events/signals when exiting k_poll in the critical section and pass that to the destination thread? Once, a thread calls k_poll again then "OR" the pending events with events that the thread has not handled so far (if any)?


Thanks,

- Venkatesh.

361 - 380 of 8519