Hi Tomek, Thanks for your reply.
The current design does not have wrappers, just the helper #defines, although it feels unfinished somehow. I like the upperhalf lowerhalf approach that was added to netdevs. Also, I aim to minimize the amount of hardware dependent code. So, it makes sense to keep things like the mutex (to force single transaction on mdio bus, as there is already ground set for multi phy boards), and timeouts as part of the upperhalf of the mdio bus, while just the actual transfer be part of the lowerhalf. Indeed, the end goal is to also have some kind of phy device that uses the mdio bus, but that is not the issue at hand. Won't not argue about memory consumption, but... Speed may not be a metric for mdio, the transfers should be minimal and (only) at boot, ideally. Also, the code overhead, I am kinda biased, that driver_t approach from freebsd should make its way to nuttx as well, somehow :D. I'll update my implementation to something that is more like the i2c approach, but any ideas matter, I'm still a beginner to unix-like ways (coming from autosar) so any heads up helps. Thanks, Mihai On Thu, 4 Sept 2025 at 17:02, Tomek CEDRO <[email protected]> wrote: > 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 >
