Hey there Mihai :-) I guess the device ops are used anyways, pointers are provided by underlying hardware, wrappers are for convenience and use ops below, I2C is more popular with various sensors so it may be okay to just have read/write calls exposed to the user, that may be easier to use but may slightly slow things down and increase memory consumption (i.e. stack + code) as opposed to using ops directly that is a bit harder but may just remove unused code parts at build time ? SPI may also be attached in DMA transfers and/or other drivers layers that just need ops and wrappers here would just slow things down? Long story short ops are for code, wrappers are for users :-P
I am not sure if there are any metrics of code, stack, and speed comparison between I2C and SPI implementations with and without wrappers to answer your question in numbers. Yes probably it would be good to have this more coherent so both ops and wrappers can be used as needed. You may try to follow both paths and see what the exact difference is in your mdio implementation? I would start with implementation without wrappers and then see if wrappers are even necessary, as these ops may just be used by another layer or drivers (i.e. (r)mii) and not users directly. https://github.com/apache/nuttx/blob/master/include/nuttx/i2c/i2c_master.h https://github.com/apache/nuttx/blob/master/include/nuttx/spi/spi.h https://github.com/apache/nuttx/blob/master/drivers/i2c/i2c_driver.c https://github.com/apache/nuttx/blob/master/drivers/spi/spi_driver.c You may also take a look at implementation of these in FreeBSD and Linux and get some inspiration? https://cgit.freebsd.org/src/tree/sys/dev/iicbus https://cgit.freebsd.org/src/tree/sys/dev/spibus https://cgit.freebsd.org/src/tree/sys/dev/mdio https://cgit.freebsd.org/src/tree/sys/dev/mii Thanks :-) Tomek On Thu, Sep 4, 2025 at 9:35 AM Luchian Mihai <[email protected]> wrote: > > Hello everyone. > > I have been tinkering around net drivers lately. I set my goal to implement > a mdio bus to add a bit of modularity to the monolithic netdevs approach > (the full ones, not the lowerhalfs). > > Currently my prototype is working although I cannot wrap my head around the > "logic" or "architecture" of the existing buses implementation, spi and i2c > to be specific. I understand both approaches, but I do not know why they > are used differently and what approach should mdio follow. > > So, to be short. Aside from the device struct specification (i2c_master_s > located in i2c_master.h and spi_dev_s in spi.h) both buses also offers > wrappers around data exchange (i2c_read, i2c_write, spi_transfer, etc) > which handles the common bus transaction logic. There is a description for > spi_transfer function which states that it is a helper function. I also see > that the spi also offers multiple dev types which may be another reason why > these two buses are used differently. > > My questions are: > > Why is the i2c bus used mainly through the "wrapper" functions (i2c_read, > i2c_write, i2c_writeread) while the spi bus prefers using the device ops > functions directly (using the provided #defines). > > Which of these two approaches would you recommend for a mdio bus, or which > should be the prefered approach in general? > > Any other feedback or ideas are also welcomed. What would you like to see > in a mdio bus implementation for NuttX? > > Cheers, > Mihai -- CeDeROM, SQ7MHZ, http://www.tomek.cedro.info
