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
