Thread:Talk:BeagleBoard/Mikrobus Support/Phases/reply (2)

mikroBUS bus driver with gbsim
Adding mikroBUS to the Greybus bridged phys might be the right answer, but I'm not sure. Sounds right.

It seems if we make mikroBUS a bus driver, it should have a 'match' function? https://www.kernel.org/doc/html/latest/driver-api/driver-model/bus.html

Is 'match' not needed in this case? Could their be a 'match' function that ends up calling the 'match' function for the I2C/SPI/UART busses? How would it determine which buses it needs?

Why would the device tree define the transport? So many confusing terms!!!

mikroBUS bus driver with I2C EEPROM holding manifest
The transport is the physical I2C/SPI/UART busses! The goal is to first get mikroBUS add-on boards working on PocketBeagle+TechLab before worrying about any other transports or other board configurations. By keeping the handling of defining the extra platform data in the mikroBUS bus driver, it should be able to have all the extra definitions it needs right there.

The use of gbsim in the earlier phase was just to try to avoid needing to parse manifest data.

Aside
I wonder if it would help if I did a device tree example for instantiating a mikroBUS bus. What do you think? I might add that to the main page as a draft.