That is a separate issue from what we're discussing (arch independent GPIO handling) and I agree with you. I would like to eventually move to a different initialization system based on callbacks and a hierarchical resource description strategy which can describe on-board devices but can be extended (without changing code) to describe off-board devices.
I started to work on the resource description by attempting to use devicetree (see length discussion here: https://github.com/apache/incubator-nuttx/issues?q=is%3Aissue+is%3Aopen+devicetree) which I think is a good option for that part. But from my thinking about this, the best way would be to work on the other part of the problem first (callback based initialization + standardization of device interface operations). I've been meaning to work on this for some time, but since it is something that requires careful planning and discussion, I've been putting it off until I'm sure I can pursue it. Anyway, abstracting GPIO handling from an arch-indepedent device driver is a first good step towards that goal. I think that it would be good to improve the ioexpander interface and start changing how this is handled in SPI device drivers. The goal in the end is the same: minimize board logic when not really required. Best, Matias On Sat, Feb 6, 2021, at 12:38, Grr wrote: > > > > > > The board would initialize this device as: > > > > What if device is external to board? You need to hack code to include > something that's not in any board > > That's the proof GPIO subsystem must be configured outside of board logic >
