On Thu, Jan 21, 2021 at 8:57 PM Suman Anna [off-list ref] wrote:

On 1/21/21 12:39 PM, Nishanth Menon wrote:

quoted

On 12:13-20210121, Suman Anna wrote:

quoted

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.

quoted

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