On 19 June 2018 at 17:26, Yang Zhang <yang.zhang@xxxxxxxxxxxx> wrote: > Yes. > > https://github.com/96boards/documentation/blob/master/mezzanine/files/mezzanine-design-guidelines.pdf > > 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? > On 19 June 2018 at 16:25, Ard Biesheuvel <ard.biesheuvel@xxxxxxxxxx> wrote: >> >> On 19 June 2018 at 17:14, Yang Zhang <yang.zhang@xxxxxxxxxxxx> wrote: >> > >> > >> > On 18 June 2018 at 14:22, Ard Biesheuvel <ard.biesheuvel@xxxxxxxxxx> >> > wrote: >> >> >> >> On 18 June 2018 at 14:21, Arnd Bergmann <arnd@xxxxxxxx> wrote: >> >> > On Mon, Jun 18, 2018 at 9:45 AM, Linus Walleij >> >> > <linus.walleij@xxxxxxxxxx> 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. >> >> > >> >> > - 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 >> >> > 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 >> >> it. >> >> >> >> Also, given that we can (and do) already describe topologies involving >> >> mezzanines by ignoring the connector altogether (which is not entirely >> >> 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@xxxxxxxxxxxxxxxxxx and 96b-spec-sig >> > <96b-spec-sig@xxxxxxxxxxxx> 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? > > -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
