Phases

== mikroBUS bus driver with gbsim ==

 Is 'match' not needed in this case? Could there 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?

As per my understanding match function is required?Which eventually calls the match function of the individual I2C/SPI/UART buses, I was thinking that the manifest has different Cports in it , so we can structure it like this: say for a click that uses I2C and GPIO resources :
 ; I2C protocol on CPort 1
 [cport-descriptor 1]
 bundle = 1
 protocol = 0x03
 property = ...

 ; GPIO protocol on CPort 2
 [cport-descriptor 2]
 bundle = 2
 protocol = 0x02
 property = ...

The property field under each Cport specifies the Extra Platform Data, is this feasible? In this case we can get the required information from the manifest itself.

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

This was a misunderstanding, I was thinking of the bus driver's relation with greybus, The bus driver has no direct relation with greybus right? It is just an independent bus driver, mainly for handling of defining the extra platform data while instantiating the click devices(works similar to Cape Bus difference being the data will be fetched from manifest blob, reusing the greybus manifest parsing logic), in the later phase this bus can be added to greybus Phy.

 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.

This would be really helpful