Problem Statement: Zephyr needs to provide an architecture independent method for power management application to invoke a low power state on the CPU. Why this is a

Problem Statement: Not all Zephyr kernel drivers provide the same interfaces. Why this is a problem: ----------------------------- The Zephyr kernel currently has devices that are essential for core

Problem Statement: Power management Kconfig flags are not consistent and hierarchy is not clear Why this is a problem: ----------------------------- The names include terms like “ADVANCED” which

Here are the revised RFCs that attempts to state the problems, reasons and solutions more clearly Thanks to Dan for spending a lot of time with me in making it right. (It was a challenge to put

The best thing to do if you find code defects is one of two things: 1. Send a patch to Gerrit that fixes it for review. 2. File a bug in JIRA https://jira.zephyrproject.org/ so that the issue is

Question: if they're almost the same, do we really need an extra directory layer, or simply have different files for the parts that differ in the same directory ? That would prevent

Of course, but I don't know if at the time we were thinking about supporting a bunch of variants of a particular microcontroller that are almost the same. I think this is an opportunity for

Hello, I have uploaded another iteration of the sensor API patches on Gerrit [1]. This addresses some minor issues that have been raised this week and also ports another driver, the SX9500 SAR

Hi, i just read the source code of zephyr. I have found an error into : drivers/spi/spi_k64.c line 204, baud_rate_prescaler is use instead of baud_rate_scaler (causes an out of bound

Where did you see a new layer in what I said? The current patch and adding st_stm32 is adding a new layer. st_stm32 is not an SoC, its an architecture (just like there is STM8) that has different

Do we need another layer of abstraction in the build for SoC variants? I share Dan's concerns, I think it may be better to have st_stm32/ SoC and then subdirectories with variants thereof, with common

Yes, the only different from what you have right now is having 1 level less. I think everything else should stay the same. Anas

Summing up, what you're basically suggesting is having a structure like this (assumig that we keep vendor prefix for the time being): arch/ arm/ soc/ st_stm32f1/ Kconfig.soc

+1 from me -- Andrew Boie Staff Engineer - EOS Zephyr Intel Open Source Technology Center

Folks, Not that big of a change for a lot of people, but I pushed a revision to documentation yesterday that enforces a 8-char tabs/80 column coding style. Basically, this makes our coding style the

Maybe I was misunderstood in my email about the structure. I was suggesting to move the SoCs directly under soc/ and ski[ the st_stm32 level. If we are to do things the same way across architecture we

Hi Daniel, Maybe we can move on with current patches yes. Tomasz

Hey Maciek,