On 06/07/2022 21:10, Christian Marangi wrote: > On Wed, Jul 06, 2022 at 05:07:12PM +0200, Krzysztof Kozlowski wrote: >> On 06/07/2022 12:20, Christian Marangi wrote: >>> On Wed, Jul 06, 2022 at 09:44:04AM +0200, Krzysztof Kozlowski wrote: >>>> On 05/07/2022 22:28, Christian Marangi wrote: >>>>> Fix dtbs_check warning for new rpmcc Documentation changes and add the >>>>> required clocks. >>>> >>>> There is no warning in the kernel, right? So the commit is not correct. >>>> >>> >>> Oh ok, the warning is generated by the new Documentation. >> >> Patches, especially DTS, might go via different trees, so the moment DTS >> is applied there might be no such warning. >> > > I'm still confused about this topic... > With this kind of change, I notice I sent Documentation change and then > rob bot complain about dtbs_check having warning... > > So the correct way is to send Documentation change and fix dtbs_check > warning in the same commit OR keep what I'm doing with sending > Documentation changes and fix DTS in a separate commit? Binding is almost always separate from DTS and always separate from driver. The order depends on what you're doing. If you bring ABI break change to bindings, then the order does not matter, because each order will be non-bisectable. Because you broke ABI. That's the case in this patchset. For other cases, usually bindings patches should be the first in patchset. How it goes via maintainer trees is not your problem here. Patches might go together or might go separate. Anyway it was not the topic of my comment. Comment was about not specific commit msg which does not fit the Linux kernel process and does not fit git history once applied by maintainer. It fits even less when backported to stable kernels, which you commit msg encourages to do. Best regards, Krzysztof
