On Mon, Aug 12, 2019 at 12:49:59PM -0400, Christopher Friedt wrote:
On Mon, Aug 12, 2019 at 12:47 PM Christopher Friedt email@example.com wrote:
On Mon, Aug 12, 2019 at 11:23 AM Jason Kridner firstname.lastname@example.org wrote:
On Mon, Jul 22, 2019 at 12:43 PM Jason Kridner email@example.com wrote:
On Wed, Jul 17, 2019 at 11:28 AM Jason Kridner firstname.lastname@example.org wrote:
On Tue, Jul 16, 2019 at 3:25 PM Greg KH email@example.com wrote:
On Sun, Jul 14, 2019 at 01:13:37AM +0530, Vaishnav MA wrote: > > On Sat, Jul 13, 2019 at 06:03:02PM +0530, Vaishnav MA wrote:
I believe there are two problems here to solve:
Let's just focus on #1.
- How do we specify the extra data?
The *extra* data here is whatever else a driver needs to load. Manifests have the buses needed and name to find the driver, but are missing any association between extra signals, like IRQ or other named GPIOs. We'd like a common way to specify those.
Chris has suggested adding some additional data to the manifests, like
[string-descriptor 2]string = driver-specific-gpio-name=manifest-specific-gpio-name
Hi - I'll chime in here because IRC did not really preserve formatting. Maybe greybus kernel code / manifesto already implements something like this, but I just haven't seen it.
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.
For a contrived example, imagine an sensor "foo", that interrupts the host when temperature gets really hot, the driver depends on DT or something to query the value associated with the "foo,interrupt-source" key. The driver would then make a
of_property_read_string(node, "foo,interrupt-source") => "mymodule,foo-interrupt-gpio" ... gpio_find_device( "mymodule,foo-interrupt-gpio" )
In any case, my suggestion is to do something like the following inside the manifest:
[property 1] type = string value = mymodule,foo-interrupt-gpio
[property 2] type = u8 value = 11
; Sensor protocol on CPort 1 [cport-descriptor 1] bundle = 1 protocol = 0x0e property = foo,interrupt-source, 1
; GPIO protocol on CPort 2 [cport-descriptor 2] bundle = 2 protocol = 0x02 property = mymodule,foo-interrupt-gpio, 2
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.
I have no objection to that as long as we can do so in a backwards-compatible way (and I think we can).