Arnd, Tony,
On 15:00-20210122, Tony Lindgren wrote:

* Arnd Bergmann [off-list ref] [210122 11:24]:

quoted

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

quoted

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.

Hmm and additionally few more mostly obvious things that have helped
quite a bit:

- Each commit in each topic branch should compile and boot so git
  bisect works

- Each topic branch should be ideally based on -rc1 to leave out
  dependencies to other branches

- Aiming for a working and usable -rc1 is worth the effort in case
  git bisect is needed for any top branches based on it :) Otherwise
  you'll be wasting the -rc cycle chasing regressions..

Thank you both for your valuable insight and direction. much
appreciated.

*) for every patch that is integrated - I already insist on
bisectability, no warnings with W=2 , dtbs_check .... Including
putting additional tooling[1] in place for folks to use - which goes
and tests sparse, coccinelle etc.. The team has been pretty deligent
in making sure things are clean.
*) We also insist on testing with linux-next to maintain rc1
functionality
*) I also maintain the minimal boot requirements equivalent to kernelci
(example:[2]) for my -next branch as well.

Yes, this series introduces 0 regression, new nodes are being added
and the thing I missed for this window, which is insisting on getting
immutable tags from subsystem maintainers for dt-bindings patches they
have picked up, will be rectified in the future. For this window,
for the last time, I am going to depend a bit on the later merge of
arm-soc.


Thanks for the clarifications, once again.

[1] https://github.com/nmenon/kernel_patch_verify
[2] https://storage.kernelci.org/stable/linux-4.14.y/v4.14.217/arm/omap2plus_defconfig/gcc-8/lab-cip/baseline-beaglebone-black.txt
-- 
Regards,
Nishanth Menon
Key (0xDDB5849D1736249D) / Fingerprint: F8A2 8693 54EB 8232 17A3  1A34 DDB5 849D 1736 249D