On Tue, Jun 26, 2018 at 10:02 AM, Linus Walleij
[off-list ref] wrote:

On Mon, Jun 18, 2018 at 2:21 PM Arnd Bergmann [off-list ref] wrote:

quoted

- I really like the idea of having C code deal with the mezzanine
  connector itself, acting as an intermediate to tie a number of
  boards to a number of add-on cards, this seems much simpler than
  trying to do everything with overlays or one of the other more
  generic mechanisms.

This is my point of view as well.

quoted

- I don't like the idea of having the bus driver contain a list of possible
  add-ons, this seems to go against our usual driver model. What
  I think we want instead is to make the connector itself a proper
  bus_type, to allow drivers to register against it as loadable modules,
  and devices (maybe limited to one device) being created as probed
  from DT or some other method as you describe.

OK I think I can do that. It will take some thinking and I would
guess I should also move it to drivers/platform/*

I'd probably leave it in drivers/bus/, though this might be one of the
rare cases that drivers/platform makes sense for as well.

My idea here would be to have a connector bus that some random
add-on (such as a 96board mezzanine) would probe to, so we
make it generic for any connector plug.

The question here is whether we want one 'struct bus_type' instance
shared by all connector types, or one for each type. I was actually
leaning towards the latter here.

quoted

- You export symbols in the mezzanine_* namespace, which I think
   is a bit too generic and should perhaps contain something related
   to  96boards in its name to make it less ambiguous. I suspect we
   would add a number of further connectors for hats, capes, lures etc,
   which could all be described as mezzanines.

Michal also brings up the (discoverable!) FMC connectors Xilinx are
using. So the idea would be to create something generic to help
probe and populate them all whether partly discoverable or not.

If a bus is fully discoverable, I think it's better to use a separate
bus_type that does not use DT based probing for its children.
However, many buses (even USB and PCI) turn out to be only
mostly discoverable, so we end up having to come up with a way
to represent child devices in DT as well.

     Arnd