The purpose of these APIs, is to provide applications, a hardware independent way to perform encryption/decryption (ZEP-328 - https://jira.zephyrproject.org/browse/ZEP-328 ). In other words Crypto har

Unix like generic async API framework can potentially simplify app/driver development . So it is great to have. From a quick read, I have a question regarding the callback mechanism (Perhaps it may be

Please find the answers below : No - application code need not do that. It is enough that the apps define CONFIG_UART_CONSOLE_ON_DEV_NAME if they want to override the default console device Console ou

Noticed a typo in my earlier reply, corrected inline Thanks Jithu Sent: Monday, December 5, 2016 10:49 AM To: Mahendravarman Rajarao (RBEI/EAA3) <Mahendravarman.Rajarao(a)in.bosch.com>; devel(a)lists.

Right, USB device functionality in general is supported only on the x86 side of C1000, consequently USB UART is only available there and not on the ARC side. Thanks Sent: Tuesday, January 3, 2017 10:0

Hi Christer, We have a bunch of USB device stuff under "subsys/usb/*". In brief we have support for the following device classes : CDC ACM - uart over usb Mass storage Webusb You can exercise them via

By composite device I think you are referring to USB device configurations which support multiple interfaces. I took a quick look of the USB stack, and it seems that presently we support single interf

We presently have only USB device (and not USB host) support in Zephyr, that’s why you are unable to find host controller drivers under Zephyr/drivers/usb > if not supported hci really, why? USB devic