On 19 June 2018 at 16:30, Ard Biesheuvel [off-list ref] wrote:

On 19 June 2018 at 17:26, Yang Zhang [off-list ref] wrote:

quoted

Yes.

https://github.com/96boards/documentation/blob/master/

mezzanine/files/mezzanine-design-guidelines.pdf

quoted

Under Configuration data section

OK, fair enough. Do any such mezzanines exist yet? Should we offer
more guidance on how exactly this discovery should be implemented?

I can't be sure, could look into it - I know there were couple of from
Arrow and ST were supporting this.

Yes, more details guidance of "How to" is always welcome :-).

quoted

On 19 June 2018 at 16:25, Ard Biesheuvel [off-list ref]

wrote:

quoted

quoted

On 19 June 2018 at 17:14, Yang Zhang [off-list ref] wrote:

quoted

On 18 June 2018 at 14:22, Ard Biesheuvel [off-list ref]
wrote:

quoted

On 18 June 2018 at 14:21, Arnd Bergmann [off-list ref] wrote:

quoted

On Mon, Jun 18, 2018 at 9:45 AM, Linus Walleij
[off-list ref] wrote:

quoted

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

quoted

quoted

quoted

quoted

quoted

quoted

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

quoted

quoted

quoted

quoted

quoted

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.

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

- You export symbols in the mezzanine_* namespace, which I think
   is a bit too generic and should perhaps contain something

related

quoted

quoted

quoted

quoted

quoted

   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.

Hello all,

We should also consider firmware use of the mezzanines. For instance,
the Secure96 has a RNG which UEFI may want to use so the early boot
code can access is for KASLR. It also has a TPM, which should not be
reset/reinitialized/etc by the OS if we want to make meaningful use

of

quoted

quoted

quoted

quoted

it.

Also, given that we can (and do) already describe topologies

involving

quoted

quoted

quoted

quoted

mezzanines by ignoring the connector altogether (which is not

entirely

quoted

quoted

quoted

quoted

unreasonable given the fact that we [as Linaro/96boards] dropped the
ball on this one and did not mandate discoverability for mezzanines).

The design guideline has been reviewed by many inside/outside linaro
through
the mezzanine@lists.96boards.org and 96b-spec-sig
[off-list ref] published as recommended/strongly
recommended
item from day one. 'dropping the ball' is a strong conclusion.

Apologies for using a term that you seem to take issue with. Are you
saying the spec currently recommends it?

quoted