On Thu, Jan 21, 2021 at 8:57 PM Suman Anna <s-anna@xxxxxx> wrote: > On 1/21/21 12:39 PM, Nishanth Menon wrote: > > On 12:13-20210121, Suman Anna wrote: > >> > >> Hmm, this is kinda counter-intuitive. When I see a dts node, I am expecting the > > > > What is counter intutive about a -next branch be tested against > > linux-next tree? > > The -next process is well understood. FWIW, you are not sending your PR against > -next branch, but against primarily a -rc1 or -rc2 baseline. > > As a developer, when I am submitting patches, I am making sure that things are > functional against the baseline you use. For example, when I split functionality > into a driver portions and dts portions, I need to make sure both those > individual pieces boot fine and do not cause regressions, even though for the > final functionality, you need both. > > > > > > Now, if you want to launch a product with my -next branch - go ahead, I > > don't intent it for current kernel version - you are on your own. > > > > If there is a real risk of upstream next-breaking - speakup with an > > real example - All I care about is keeping upstream functional and > > useable. > > This is all moot when your own tree doesn't boot properly. In this case, you are > adding MMC nodes, but yet for a boot test, you are saying use linux-next for the > nodes that were added or you need additional driver patches (which is not how > maintainer-level trees are verified). > > Arnd, > Can you please guide us here as to what is expected in general, given that the > pull-request from Nishanth goes through you, and if there is some pre-existing > norms around this? There are two very different cases to consider, and I'm not sure which one we have here: - When submitting any changes to a working platform, each patch on a branch that gets merged needs to work incrementally, e.g. a device tree change merged through the soc tree must never stop a platform from booting without a patch that gets merged through another branch in the same merge window, or vice versa. As an extension of this, I would actually appreciate if we never do incompatible binding changes at all. If a driver patch enables a new binding for already supported hardware, a second patch changes the dts file to use the new binding, and a third patch removes the original binding, this could still be done without regressions over multiple merge windows, but it breaks the assumption that a new kernel can boot with an old dtb (or vice versa). This second one is a softer requirement, and we can make exceptions for particularly good reasons, but please explain those in the patch description and discuss with upstream maintainers before submitting patches that do this. - For a newly added hardware support, having a runtime dependency on another branch is not a problem, we do that all the time: Adding a device node for an existing board (or a new board) and the driver code in another branch is not a regression because each branch only has incremental changes that improve hardware support, and it will work as soon as both are merged. You raised the point about device bindings, which is best addressed by having one commit that adds the (reviewed) binding document first, and then have the driver branch and the dts branch based on the same commit. I hope that clarifies the case you are interested in, let me know if I missed something for the specific case at hand. Arnd