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,

Hi, I've pushed another set of updates. Hopefully I have not missed any comments that were added to the previous versions. I took the liberty of rebasing Daniel's patch on top of current master, and

Hi, Something like that yes, though I'd put empty lines in between ;) Tomasz

<tomasz.bursztyka(a)linux.intel.com> wrote: If I understood correctly what you're suggesting, the example code could look like this: static inline uint32_t pinmux_pin_input_enable(struct device

Hi, Tomasz Bursztyka <tomasz.bursztyka(a)linux.intel.com> wrote: There was a thread before [1] about differing between an API not supported and an API not implemented for a given driver

Hi Maciek, Note that on many API, some calls have a mandatory support (let's say spi_transceive), so such test would not have to be generalized. What about a different approach: Thing is, Zephyr

Hi, I'd like to make a proposal for enhancement of driver API callbacks, but before jumping to code I'd like to get some feedback first. Right now, whenever a call to an API is made, we directly

Sure, let me know. If it ends up you need a dynamic handler for one specific exception on x86 we could treat it as a special case. irq_offload() is like this. Andrew

Hang on on this, I'm cleaning up a GDB server implementation that we want to upstream, and it uses at least dynamic exceptions. I'll see if I can refactor it to use static ones instead.

Problem statement: We currently have two separate implementations on how to connect interrupts on all arches: static IRQs and dynamic IRQs. On x86 only we also have static and dynamic APIs for

Hi Corey, You'll have to wait k64f spi driver gets into the tree first, unless you want to try under review patch. You won't have to tell anything about any pins. The driver manages all that for

Hi, I think the best we can do is to clearly document the life-time expectation of the struct. I don't think there's really any other way around it with asynchronous APIs that need to track more

Hi, Im looking to use the zephyr project spi driver for writing to the SD card slot on the FRDM K64f board. So far I have found little to no documentation on how to use the spi driver. For example

Another thing is: it seems like that you expect the app developers to statically allocate a bunch of this struct to have multiple callbacks. This is, AFAIK, not a common practice when setting

Sure. Below are a summary of the API and changes. Please let me know if anything else needs to be mentioned and I can add. The generic counter API will support 4 functions as summarized below. Based