Re: [PATCH 0/5] RFC: Mezzanine handling for 96boards

[Rob Herring <robh+dt@kernel.org>]

On Mon, Jun 18, 2018 at 6:21 AM, Arnd Bergmann <arnd@arndb.de> wrote:
> On Mon, Jun 18, 2018 at 9:45 AM, Linus Walleij <linus.walleij@linaro.org> wrote:
>> This is a proposal for how to handle the non-discoverable
>> 96boards plug-in expansion boards called "mezzanines" in the
>> Linux kernel. It is a working RFC series meant for discussion
>> at the moment.
>>
>> The RFC was done on the brand new Ultra96 board from Xilinx
>> with a Secure96 mezzanine expansion board. The main part
>> is in patch 4, the rest is enabling and examples.
>>
>> The code can be obtained from here:
>> https://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-integrator.git/log/?h=ultra96
>>
>> You can for example probably augment the DTS file for any
>> upstream-supported 96board and get the Secure96 going with
>> it with minor efforts.
>
> Hi Linus,
>
> Thanks for your work on solving this long-standing problem. I've just
> read through your patches briefly and have a few thoughts:
>
> - 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.

Certainly we need at least some code to trigger probing devices under a connector. I suspect some connectors can be handled generically and some will need connector specific drivers.

> - 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.

Why a bus versus just a platform device? The infrastructure is already there to instantiate platform devices and match to compatible strings and a platform driver can create child devices. So what would we gain from a new bus?

We have 2 cases to consider I think: discoverable and non-discoverable boards. But discoverable here only provides us what overlay to load and/or driver to enumerate.

>
> - 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. One open question
>    is how we structure the commonality between the various
>    connectors, but we can defer that until we have more than one
>    or two of them.
>
>           Arnd