On Mon., Aug. 12, 2019, 2:06 p.m. Jason Kridner, jkridner@beagleboard.org wrote:
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.
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.