On 08/09/2013 03:09 AM, Mark Rutland wrote: > On Thu, Aug 08, 2013 at 07:34:28PM +0100, Stephen Warren wrote: >> On 08/08/2013 03:11 AM, Mark Rutland wrote: >>> On Wed, Aug 07, 2013 at 05:12:12PM +0100, Stephen Warren wrote: >>>> On 08/07/2013 08:07 AM, Mark Rutland wrote: >>>>> On Tue, Aug 06, 2013 at 12:00:50PM +0100, Pawel Moll wrote: >>>>>> On Wed, 2013-07-31 at 16:56 +0100, Mark Rutland wrote: >>>>>>>> Ah, I guess the question more: Do we want generic bindings that describe >>>>>>>> the low-level details of the HW in a completely generic fashion so that >>>>>>>> new HW can be supported with zero kernel changes, or do we want a simple >>>>>>>> driver with a lookup table that maps from compatible value to the HW >>>>>>>> configuration? One of the potential benefits of DT is to be able to >>>>>>>> support new HW without code changes, although perhaps that's more >>>>>>>> typically considered in the context of new boards rather than new IP >>>>>>>> blocks or SoCs. >>>>>> >>>>>> ... or FPGAs that can be synthesized with random collection of standard >>>>>> IP blocks. With Xilinx's Zynq and Altera's SOCFPGA this is getting >>>>>> simpler and simpler... >>>>>> >>>>>>> I think that going forward it would be better to have have a compatible >>>>>>> string per different device. As Olof pointed out, we're leaking the way >>>>>>> we currently handle things in Linux into the binding, rather than >>>>>>> precisely describing the hardware (with a unique compatible string). I'm >>>>>>> not sure if this is much better than embedding a bytecode describing how >>>>>>> to poke devices. >>>> >>>> This really isn't leaking information about how Linux handles the >>>> device. It's simply saying that there is a GPIO controller whose HW is >>>> able to be described by a simple/generic binding, and that binding >>>> provides full details of the register layout. Other OSs can handle this >>>> differently; see below ... >>> >>> I worry that it doesn't provide a full description, but rather a >>> description of the subset of the hardware used by the driver. >> >> I don't see that as a problem. >> >> A particular DT file provides a description of an interface to HW. To my >> mind, if that particular DT doesn't describe everything about a >> particular HW module (e.g. some advanced feature can't be enabled), >> that's basically equivalent to not describing aspect of the board/system >> (so e.g. some I2C device isn't represented at all, and hence some >> temperature probe can't be monitored). > > My concern is simply that if people can get basic functionality with the > generic driver they won't bother describing the details of the more > specific binding, and you'll never be able to use the board with a > better driver without having to modify the dt later. > > I guess the question boils down to how much we care about that > situation. I personally think it's fine. If people only want to expose the basic functionality and can do so with simple-gpio, I don't see any problem at all with that. (Why should we care that a binding doesn't expose all features of the device? I'm sure there are many undocumented features, e.g. debug/backdoor, in HW that we don't even know exist and so don't know aren't exposed by various bindings) If someone later finds it useful to expose more functionality than is sensible to expose through simple-gpio, then a HW-specific binding can be added for that purpose, and the .dts file amended to use that. The more I think about this, the more I think that simply having disjoint simple and HW-specific bindings makes sense. In that case, the new DT won't be compatible with an old kernel, but I think that's reasonable, since it was explicitly changed to implement new features. I think we should resolve this aspect first before considering the details. I'm curious what other DT maintainers and users think about this topic? -- 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
