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. -- 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