Again, do we want to take over _another_ namespace ? Maybe it should be sys_debug or sys_dbg or sys_dbg_log ? The sample implementation is adding all these in logging.h, which is a public API file:

If get binding fails the app will know the device failed or is otherwise unavailable. The return code from init() tells the kernel whether it's a fatal error and to call _NanoFatalErrorHandler()

I like this in general we need a common set of debug output macros that all drivers can use. Currently we have a *bunch* of different versions of the same thing in use throughout the driver tree. I

Dirk Brandewie <dirk.j.brandewie(a)intel.com> writes: [...] I already started this. Hoping to have something to show later today or tomorrow. Cheers, -- Vinicius

yeah better idea :-D when the quark_se gets more design wins things would get crowded. Now the question is who is signing up to do the refactoring? :-)

Hi Genaro, The idea is nice, at least it will prevent to declare debug macros everywhere. However, split the patch: - first provide a patch with the logging.h and it's related Kconfig file - and

Hi Genaro, <genaro.saucedo.tejada(a)intel.com> wrote: I welcome these changes but Im not so sure logging levels are actually necessary if one can define different domains, at least in case

From 9baee79d211bfb94aeed970c55f31cd3c4b2a8ad Mon Sep 17 00:00:00 2001 From: Genaro Saucedo Tejada <genaro.saucedo.tejada(a)intel.com> Date: Fri, 19 February 2016 23:10:28 +0000 Subject: [PATCH] Log

Hello, please review this proposal and provide feedback if possible. This email should be followed by a patch containing a prototype implementation for reference but not meant to be

Thanks for pointing out the facts and issues :-) I agree it cannot be used as a replacement for proper handling of resume() by devices.

Hi Dirk, Dirk Brandewie <dirk.j.brandewie(a)intel.com> writes: [...] I like it. The only thing I am thinking about is polluting the drivers/pinmux/ directory when there are more than a couple of

I do agree with you that the app cannot do much in failures. But then kernel need not do even what you propose with failing binding. Let the app figure out when it tries to use the port. Also

Don't hate it :-) Although it occurs to me that the pinmux API is not all that useful and could be considered harmful. Setting up the pin configuration on an SOC/platform is an init time only

Yeah, that would do it: the task has to yield to the fiber somehow, since it will never pend (in a nanokernel context). Hmm, I would counter this with the argument that passing the current fiber

Hi, "Kalowsky, Daniel" <daniel.kalowsky(a)intel.com> writes: Thanks for the well thought answer.

I think I figured this out: - I was trying to wake up the same fiber I was running - I was always calling fiber_fiber_wakeup() instead of proper context depending version After fixing these two

Re-sending this using proper mail address. I managed to get following backtrace when the system is hanging: _nano_fiber_ready (tcs=tcs(a)entry=0xa800f020 <tx_fiber_stack>)     at

I managed to get following backtrace when the system is hanging: _nano_fiber_ready (tcs=tcs(a)entry=0xa800f020 <tx_fiber_stack>)     at

Hi Peter & Ben, I am seeing couple of issues when trying to wake up a fiber. 1) if my fiber tries to to wake up itself (yes, there was a bug in my program), there seems to be weird issues (hangs).