Re: Greybus For IoT : Click Board Support on Beaglebone Boards

[Christopher Friedt <chrisfriedt@xxxxxxxxx>]

On Mon., Aug. 12, 2019, 2:06 p.m. Jason Kridner, <jkridner@xxxxxxxxxxxxxxx> wrote:

On Mon, Aug 12, 2019 at 12:49 PM Christopher Friedt <chrisfriedt@xxxxxxxxx> wrote:
>
> On Mon, Aug 12, 2019 at 12:47 PM Christopher Friedt
> <chrisfriedt@xxxxxxxxx> 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.

Yes. We would essentially just be using the same interface as device tree, so if the drivers used device tree before, they would Just Work™ with this change.

There are some intricacies though. Specifically to ensure that "phandles" referenced resources on the same physical module.

Technically speaking, it *might* be possible to string a wire up from a remote module to the host gpio, or from one module to another module, but I just can't see that as being practical.

_______________________________________________
greybus-dev mailing list
greybus-dev@xxxxxxxxxxxxxxxx
https://lists.linaro.org/mailman/listinfo/greybus-dev