Hi, First of all, I'm not sure what would be the best mailing list to ask this question, so if you have an idea what would be a better choice then I would be grateful if you could direct me to the right place. In the board that I've been working on, apart from the main CPU we also have an Intel MAX10 FPGA which acts as a system controller. It has a lot of signals connected over the board that it supervises. Eg. We have a few i2c devices and most of them expose a reset pin. All these reset pins from these devices are connected to the FPGA which is responsible for triggering resets. Apart from that, we thought about implementing a reset controller driver in the kernel that would communicate with this FPGA and allow to trigger a reset on any device (that has its reset pin connected to FPGA of course). I've browsed through the drivers that I'll need to enable on our board, and most of them expect some kind of reset api that they use e.g. during probe. Most of them however expects the reset_gpio which in our case is not what we want, as all resets are managed by FPGA and all reset requests should go through it. I'm wondering - would it be possible (and what is even more important, would it make sense?) to implement a reset controller driver (perhaps there is already something similiar?), that for the consumer drivers (like some sensors and so on that currently use gpiod* calls) would still remain as gpio-like reset (so they would still use gpiod* calls), whereas under the hood the calls would be forwarded to FPGA? If not, the other option I see is to extend the functionality of the drives that we are going to use reset_controller consumer api). I would be grateful for some advice. Best regards Patryk