Hello, The PR was merged. Now ALL device instances are constant. Along with this change: all isr handlers take a const void pointer. To all relevant stakeholders that this may affect: !!! PLEASE REBAS

Hello, As part of https://github.com/zephyrproject-rtos/zephyr/issues/22941 I am proposing to switch all device instances to constant, see: https://github.com/zephyrproject-rtos/zephyr/issues/27399 An

Hello, I am proposing to rename 3 attributes of struct device. These attributes names have legacy roots which do not make sense anymore. See: https://github.com/zephyrproject-rtos/zephyr/issues/27397

Hello, You will find the github issue here https://github.com/zephyrproject-rtos/zephyr/issues/26923 Which describes the changes. PRs are already done and linked there as well. Tomasz

Hi Raveendra, Yes it should be up to the driver to manage this. However, this is not the case in many drivers (across all domain, not only DMA). This is also one of the thing which is being solved thr

Hi, Former RPL was a port of contiki's RPL implementation, if I am not mistaken. But it slipped a lot compared to its original code, which one got a lot more features implemented. Also, the issue with

Hi, Indeed the driver requires another instance to be added. Hopefully it's trivial, basically a copy-paste of the existing one minor tiny modifications. The annoying part will be modifying Kconfig as

Hi Lincoln, Can you try https://github.com/zephyrproject-rtos/zephyr/pull/11396 (1st commit) That should solve your issue. Instead of returning -EALREADY if already installed, I just return 0. Tomasz

Hi, Actually you found a bug. It's not up to the user to know that the cb is already installed (even though, logically it does not make sense to add the same cb many times), in other words: gpio shoul

Hi Jiri, One thing is common over all drivers is how it iterates through the r/w buffers (drivers/spi/spi_context.h) but rest depends on hardware and whether or not you use a HAL to access it (nrfx, s

Hi, There is already an on-going work on how devices (aka driver instance) are generated. See issue: https://github.com/zephyrproject-rtos/zephyr/issues/6293 Especially, check for b0661 and erwango PR

Hi Armando, I am not maintaining stm32 driver, I won't much of any help about it. Get in touch with PR 5200 owner or one of the guys that created the driver (git blame). Br, Tomasz

It has not been rebased against latest SPI API changes, thus why it can't be merged. But it's a fine PR besides that. Tomasz

Hi, Check this PR: https://github.com/zephyrproject-rtos/zephyr/pull/5200 You probably need the first patch, and the second is an example how to do it. Note however the API has changed a bit, you'll h

Hi Clemence, Could you try sniffing the ipv4 traffic? And could you paste your .config somewhere? Btw, a tiny detail: You don't need CONFIG_ETH_ENC28J60_0_GPIO_SPI_CS on stm32 board, unless you ant to

Hi Clemence, SPI is supported on stm32f4 SoCs, the doc is probably not up to date. Maybe it's just not enabled on the board's dts file. But on SoC level it is, see dts/arm/st/stm32f407.dtsi which incl

Hi Marcio, Is it an i2c controller you are trying to support or a device that uses the i2c bus? If it's the first option: What you want is looking at include/i2c.h There you'll find the i2c API your d

Hi Ismael, Ah, then you are a bit more in trouble, design wise. I.e., the current LoRaMAC port would need to be finished, and exposing an API which - in turn - your offload device could support as wel

Hi guys, About LoRa, there is already a PR for the LoRaMAC port here: https://github.com/zephyrproject-rtos/zephyr/pull/5764 Get in touch with Ding Tao about it, there a tiny changes required but that

Hi Paul, Fine by me. Tomasz