El sáb, 6 feb 2021 a las 9:53, Matias N. (<mat...@imap.cc>) escribió:
> 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. > That's a no brainer: if you consider SPI and I2C as standard busses, the only difference between on-board and off-board devices is on-board are already configured and off-board need to be configured. You only have to go to Menuconfig and add as much SPI or I2C devices as CS and addr space allows > > 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. > DTS mean huge changes and maybe even ditching Kconfig On the other side, a cut down sysfs-like system added to root pseudo-filesystem is feasible right now and can expose needed information at runtime, for example when testing. And Gregory Nutt already said /dev is OK as registration system so zero risk of violating modularity > 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 > > >
