Cancelled: Zephyr: Power Management Sync This event has been cancelled. When: Thursday, December 23, 2021 11:00am to 12:00pm (UTC-08:00) America/Los Angeles Where: Microsoft Teams Organizer:

Cancelled: Zephyr: Power Management Sync This event has been cancelled. When: Thursday, December 16, 2021 11:00am to 12:00pm (UTC-08:00) America/Los Angeles Where: Microsoft Teams Organizer:

Reminder: Zephyr: Power Management Sync When: 12/16/2021 11:00am to 12:00pm (UTC-08:00) America/Los Angeles Where: Microsoft Teams Organizer: devel@... An RSVP is requested. Click here to

Hi Abramo, I think Nicolas makes some good points here. Zephyr code is too different from Linux style for my liking, e.g. the strange {} around single-line statements. Things like 'if (rc != 0)'

Reminder: Zephyr Project: Dev Meeting When: 12/16/2021 8:00am to 9:00am (UTC-08:00) America/Los Angeles Where: Microsoft Teams Meeting Organizer: devel@... An RSVP is requested. Click here

Unless we find a good place for this macro I'd be forced to leave double cast. If it is preferred I can add a line of documentation before each occurence. I'd like very much you take a look

Agenda for this week's Dev-Review meeting: Add iomux rt driver - https://github.com/zephyrproject-rtos/zephyr/pull/40880 shields: add generic shield to use CDC ACM UART as backend -

Absolutely! This is a great example of papering over what is most likely a flaw in the code. Instead of questioning the fundamental of such non-preserving conversion, the added cast gives the

Are you really arguing that a commented explicit cast (for non obviously value-preserving conversion) is worse than an implicit cast? Are you taking in account that although you can write tests for

I appreciate your points, and similarly for a few others before yours, but I think they are missing the point. No one is against virtue. Everybody wants the code base to be more consistent, more

Hi, I've written this email two days ago and somehow it never left my outbox so I'm re-sending it because I think it is still relevant. We should keep this discussion as much technical as possible.

A few points from my side (probably nothing that has not been already said) MISRA mostly tries to avoid undefined behavior derived issues. Other languages such as Rust have done a better job on this

Olof, Point taken, will start posting agenda the day before. Anas From: devel@... <devel@...> on behalf of Olof Johansson <olof@...> Date: Wednesday, December 15, 2021 at 2:14 AM To: Hibberd,

It’d be great to have a pre-read to frame the discussion and help us can come prepared with questions based on said update (the linked Nov 10 email in last week’s minutes is fairly high

All, As a reminder, the TSC agreed upon theZephyr Project Coding Guidelines. We are working towards compliance to the Project CG. Yes, they are a subset of Misra, but we are not going for Misra

HiVinayak, enhancement request https://github.com/zephyrproject-rtos/zephyr/issues/41140, lets continue discussion there. Regards, Nazar

Cancelled: Zephyr Project: APIs This event has been cancelled. When: Tuesday, December 28, 2021 9:00am to 10:00am (UTC-08:00) America/Los Angeles Where: Microsoft Teams Meeting Organizer:

Cancelled: Zephyr Project: APIs This event has been cancelled. When: Tuesday, December 21, 2021 9:00am to 10:00am (UTC-08:00) America/Los Angeles Where: Microsoft Teams Meeting Organizer:

Cancelled: Zephyr Project: APIs This event has been cancelled. When: Tuesday, December 14, 2021 9:00am to 10:00am (UTC-08:00) America/Los Angeles Where: Microsoft Teams Meeting Organizer:

Hi Nazar, Correct me, the requirement is to be able to use Vendor HCI command/Response on `bt_enable()` after a HCI device is open but before the `bt_init()`. to be able to handle asynchronous