I am working right now on defining a new layer in Kconfig and reorganising Kconfig for this purpose and will take the STM32 changes and propose better structure for all architectures and existing

I downloaded the Zephyr SDK v0.7.2 last night and tried to install it this morning on my MacBook. During the installation, I cancelled with ctrl-C and somehow it seems to have executed a "rm -rf /"

We are looking into this and will send a proposal to address this by EOD. Anas

Do we have a consensus on this matter then? Did you get a chance to discuss this internally? Cheers, -- Maciek Borzecki

Thanks Tomasz, It compiles :) I will try lator today with a real GPIO test. Thanks again. /Anders

Hi Anders, According to arch/arm/soc/fsl_frdm_k64f/Kconfig GPIO and GPIO_K64 are set by default. Verify you get these in your output/.config The name you should use is GPIO_K64_<X>_DEV_NAME (where

Hi, I am trying to use GPIO on my Freescale FRDM-K64 board. However, I cannot seem to find the driver name. It from this page that the driver name should be something like

Hi, I have a Freescale FRDM-K64 board. I cannot get the samples/hello_world/microkernel to work. Compiling with this: # make O=out-arm BOARD=frdm_k64f It compiles fine and the out-arm/zephyr.bin can

That was my first thought but I don't think we have the liberty of changing our 1.0 APIs. Andrew

Sounds good. We can use the SYS_INIT_NAMED() macro for devices that need a name for PM purpose. Do you think we should replace SYS_INIT() with the new one? i.e. just modify SYS_INIT(). I am ok

Hi all, Quoting Andre Guedes (2016-03-03 16:43:24) Do we have a consensus about this? After the "errno-drivers" patchset, DEV_* codes will be used only at 'board' and 'arch' layers. Actually, all

Hi all, Quoting Andre Guedes (2016-03-04 10:55:24) I just sent a patchset with topic "errno-drivers" implementing what we have discussed in this RFC. The patchset basically redefines DEV_* using -E*

Something that also occurred to me: we have the same issue with our boards/ directory. As Zephyr gets put on more and more boards we're going to find ourselves with different variants of each board. I

I see. So at boot it could use device_get_binding() or DEVICE_GET() to populate some data structure with device pointers which is then used at suspend/resume time. You're already calling .suspend the

The list enables the PMA to choose the order in which it suspends/resumes the devices by creating its own ordered list based on policies. If the iteration is done by the kernel then the order will

If you just need to iterate over all devices this code does the job: struct device *info; for (info = __device_init_start; info != __device_init_end; info++) { /* do stuff */ } Could add an API to

Hi, "Thomas, Ramesh" <ramesh.thomas(a)intel.com> writes: Ah, I see. Thanks. Cheers, -- Vinicius

The power manager application should be able to handle that case. It can either retry after trying other drivers, ignore that driver or abort suspend. The callback is not going to help because