Replacing reset gpio with reset controller

Patryk pbiel7 at gmail.com
Thu Nov 14 05:34:41 EST 2024


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



More information about the Kernelnewbies mailing list