Hello Mark, On 10/09/2014 12:27 PM, Mark Rutland wrote: >> >> Well, is not fairly obvious to me. One can also say the opposite, why the >> kernel is documenting a DT binding that is not (currently) implemented? > > Checkpatch will complain regarding undocumented bindings, so from a > pragmatic point of view the binding must come first. > > Personally, when I read a patch series I do an initial pass in-order, > and having the binding first makes things clearer. I might have some > questions regarding the binding that the driver answers later, and it makes it > easier to spot undocumented properties or conventions used by the > driver. Doing so the other way around usually leaves me with more > questions at the end. > Thanks a lot for the explanation, it certainly makes sense then to have the DT binding before. I'll propose a patch to add that information to Documentation/devicetree/bindings/submitting-patches.txt so people (like me) who didn't find it obvious can know what the convention is. >> That's why what makes the most sense for me is what the old convention did, >> add the DT binding docs in the same patch that implements the binding. > > Having a separate patch for the binding is very helpful for those of us > doing review. For one thing it helps us to find the binding document, > which can be important when a driver is thousands of lines long. For > another it means that we can be clear that our Acked-by, Reviewed-by, > etc apply to the binding and not necessarily the rest of the code. > Agreed. > For small patches, this is obviously less of a concern. > > Thanks, > Mark. > Best regards, Javier -- 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
