Thread:Talk:BeagleBoard/Mikrobus Support/Phases/reply

Could you please clarify if my understanding of the approach is in the right direction?

mikroBUS bus driver with gbsim
Modify Greybus to include Mikrobus under GB Bridged Phy similar to other PHY bus like I2C,SPI. So when a manifest under this category is loaded, then all the greybus interfaces(virtual interfaces for each perpiheral on the mikroBUS: I2C,SPI,GPIO,...) are created and then the corresponding new_device(or similar) call in the mikrobus bus driver is made with the platform data for the device fetched from the manifest to instantiate the device on the bus(greybus created mikrobus), the bus driver then completes the platform data structure for the device and call the device driver to instantiate the device on the bus(virtual greybus). gbsim takes care of the transport(greybus mikrobus<->physical mikrobus).

Instantiate the driver on PocketBeagle+TechLab using whatever device tree entries you need to define it. Define the bus, not any of the devices.

I have one more doubt(maybe dumb), in this case the Mikrobus Driver doesn't do the transport(greybus<->physical) right? So why does it require information about the actual physical Mikrobus? Is it Possible(feasible) to include the transport in the driver itself? Like this:
 * In a suitable device tree entry we define the transport, say 'phy' (where the mikrobus port is on the same device as where kernel greybus is running) then we route out the individual greybus interfaces(SPI/I2C/..) separately to the physical peripheral(SPI/I2C/UART) specified in device tree.

mikroBUS bus driver with I2C EEPROM holding manifest
In this case, the Mikrobus Bus Driver should fetch the manifest blob from an I2C EEPROM(similar to approach done by Bone Cape Manager) and then pass it to greybus(?), so the greybus mikrobus creation and device instantiation happens in the previous manner itself.

Use the Greybus code to parse the manifest, but do not require gbsim to get the data.

In this case who performs the transport?