On 20/10/16 16:29, Lars-Peter Clausen wrote: > On 10/20/2016 04:53 PM, Peter Rosin wrote: > [...] >> Good idea! Then the "envelope-detector,inverted" bool can go, and be >> implied by the compatible string. If some way to rebind the irq trigger >> is later discovered that can be added as a channel attr without >> deprecating any dt bindings stuff. While at it, the other properties >> ("envelope-detector,dac-max" and "envelope-detector,comp-interval-ms") >> could also be implied from the compatible string. Would that be better? >> I think so. >> >> But, the compatible string is one thing and the driver name is another. >> "axentia,tse850-envelope-detector" doesn't seem like the best of driver >> names... > > The driver name is not that important we can still change that later if we > have to, the DT compatible string on the other hand is fixed. > >> >> Are there any existing examples of drivers for (generic) things built >> with discrete components like this that could perhaps provide guidance? > > Not that I'm aware of. > Me neither. Always interesting to break new ground ;) J -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html