I understand you are looking for a generic API that can be used from drivers to access GPIOs, right? I understand this may come up in situations like handling CS lines from SPI driver. Currently we handle this by delegating the select line handling to board logic completely.
I thought about this a few times and I think this can be made better without breaking modularity. I think the closest approach is to use something in the lines of what Xiang suggested: give the lower-half part of the SPI device driver the ability to control the GPIO via some interface (ioexpander in this case). One improvement I can think of is to avoid the devid -> CS line routing to be made at board-logic level and make a SPI device driver (eg: a sensor) handle it itself. In other words, make a SPI device driver provide the select operation (instead of the typical <arch>_spiNselect() at board logic level. This could also be used for the spiNstatus and D/C lines, if present. That could go a long way to reduce boilerplate code to enable use of a SPI device from a given board. Best, Matias On Sat, Feb 6, 2021, at 09:16, Grr wrote: > El vie, 5 feb 2021 a las 23:15, Brennan Ashton (<bash...@brennanashton.com>) > escribió: > > > On Fri, Feb 5, 2021, 8:43 PM Grr <gebbe...@gmail.com> wrote: > > > > > > Arch specific ones are not allowed in arch/ or your application > > > There is no reason to provide your application > > > > GPIO system is _not_ my application > > We are talking in circles here at this point. You would have to show what > > you are planning on doing with the information you are trying to put in > > board.h because I don't see how it helps > > > I already did that > > Where would this base address be > > used, what exactly would call it? > > > > GPIO system gpio_setpin() function >
