On Mon, Aug 12, 2019 at 12:49:59PM -0400, Christopher Friedt wrote: > On Mon, Aug 12, 2019 at 12:47 PM Christopher Friedt > <chrisfriedt@xxxxxxxxx> wrote: > > > > On Mon, Aug 12, 2019 at 11:23 AM Jason Kridner <jkridner@xxxxxxxxxxxxxxx> wrote: > > > > > > On Mon, Jul 22, 2019 at 12:43 PM Jason Kridner <jkridner@xxxxxxxxxxxxxxx> wrote: > > > > On Wed, Jul 17, 2019 at 11:28 AM Jason Kridner <jkridner@xxxxxxxxxxxxxxx> wrote: > > > > > On Tue, Jul 16, 2019 at 3:25 PM Greg KH <gregkh@xxxxxxxxxxxxxxxxxxx> 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. > > > > > > > > > > > > > 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). thanks, greg k-h _______________________________________________ greybus-dev mailing list greybus-dev@xxxxxxxxxxxxxxxx https://lists.linaro.org/mailman/listinfo/greybus-dev
|