On Mon, Aug 12, 2019 at 12:49 PM Christopher Friedt <chrisfriedt@gmail.com> wrote:
>
> On Mon, Aug 12, 2019 at 12:47 PM Christopher Friedt
> <chrisfriedt@gmail.com> wrote:
[snip]

> >
> > My thoughts were that manifests could be a source of platform_data in
> > the kernel just like devicetree or acpi, accessed through the
> > linux/of.h interface in driver code.
> >
[snip]

> >
> > Care would need to be taken that all of the property types defined in
> > linux/of.h were accounted for.
>
> This would require a rev to the manifest specification, and also some
> plumbing in the kernel.

Assuming we take on this task and our proposed modifications are accepted, would it be sufficient to be able to describe the body of 600 mikroBus-compatible Click boards for which at likely hundreds already have drivers in some same shape without needing to touch all the drivers? I mean, my goal here is to produce a pattern that enables getting such boards supported in the kernel tremendously quicker and easier than touching the existing body of microcontroller firmware.

--
https://beagleboard.org/about - a 501c3 non-profit educating around open hardware computing