Hi Phil, > On Nov 29, 2016, at 14:57 , Phil Elwell <phil@xxxxxxxxxxxxxxx> wrote: > > On 29/11/2016 12:24, Pantelis Antoniou wrote: >> First note is that this is exactly what the portable connector is supposed to >> do; abstract away the SoC differences. >> >> Second note is that it’s not the overlay application that’s having problems, it’s >> your parameter patching method. >> >> The 'spimaxfrequency = <&can0>,"spi-max-frequency:0”’ form could more easily be >> done by targeting aliases instead of node labels. >> >> I.e. You can apply the overlay, set an alias to the node and instead of referencing >> the label, reference the alias. > But the patching is done before the overlays are applied, in isolation > from the base tree, so that they can still be used with the kernel > configfs overlay mechanism. How do aliases (which associated symbols > with absolute paths) help? > An alias is the standard way to refer to nodes symbolically. They can be overwritten at runtime without triggering an error. >> Again, this is a stop-gap until the portable connector is done, but what I take out >> of this is the need for a parameterization step in which an overlay is modified before >> it is applied according to an external parameter. > Yes, absolutely. > Speaking of which, since these overlays are applied at runtime, why not build them with a script and have a #define passed to the c preprocessor before compiling them? It doesn’t appear to be a problem doing it this way. > Phil > — Regards — Pantelis -- To unsubscribe from this list: send the line "unsubscribe devicetree-compiler" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
