12:29 <CounterPillow> Can device tree overlays a la https://www.kernel.org/doc/html/latest/devicetree/overlay-notes.html contain include directives? It doesn't seem that way

12:31 <geertu> CounterPillow: If you run them through cpp first, they can

12:31 <CounterPillow> Thanks

12:35 <CounterPillow> How do I make it not see #gpio-cells = <2>; as an attempt at a preprocessor directive?

12:36 <CounterPillow> ah, -traditional-cpp

12:38 <geertu> CounterPillow: run "make V=1 dtbs

12:39 <geertu> CounterPillow: run "make V=1 dtbs" to see how Linux invokes cpp and tc

12:39 <geertu> and dtc

14:46 <mraynal> broonie: I saw you said something about topic branches and Linus not liking them, what do you mean exactly? Because I was about to create a specific branch for the "external ECC engines & Macronix support" series and merge it into my tree as well as providing it to you in case you would need it. Is this the wrong way to do?

14:47 <broonie> mraynal: You're probably fine so long as you don't end up with many merges. Basically he doesn't like merge commits, especially if you do something like merge a bunch of topic branches down prior to sending things out to him.

14:47 <broonie> I get annoyed because what he *says* and what he actually gets wound up about aren't the same thing.

14:49 <mraynal> broonie: mmmmh. In fact we actually do that all the time in mtd, as there are up to 4 different branches merged into one (so 4 merge commits basically). Maybe it's fine because we provide proper merge requests internally with specific tags.

14:50 <broonie> Oh, lots of trees do it (there's several are quite clearly generating a series of automated merges at teh last minute).

14:50 <bencoh> (he's not the only one not liking merge commits, to be fair)

14:51 <broonie> Basically he has some random tastes that he tries to attach to workflows but they don't actually line up with each other that well.

14:52 <mraynal> hu :)

14:53 <geertu> mraynal: Just don't merge anything from upstream, unless you have a very good reason, which should be explained in the merge commit message.

14:53 <geertu> broonie: perhaps you need some submaintainers to accept PRs from, one for each of your topic branches? ;-)

14:54 <mraynal> geertu: oh yeah, that should not be a problem indeed. It may happen sometimes that we merge the latest -rc when there is conflincting work, but it's rather rare...

14:54 <broonie> Too many merges within your own tree, or the wrong pattern of merges also sets him off (TBH it's more likely to than merging stuff from his tree, he only seems to pick on that if he's looking for other reasons).

14:55 <broonie> In theory he prefers to resolve all conflicts with his tree himself.

14:56 <mraynal> broonie: 'wrong pattern of merges'?

14:56 <broonie> mraynal: Yes, exactly :P

14:56 <geertu> broonie: You can avoid too many internal merges by only merging all your topic branches together right before sending a PR to him.

14:56 <mraynal> I didn't know about the latter. I assumed the opposite.

14:57 <geertu> Of course you need a separate for-next branch for sfr, which you do merge daily, but that one nevers goes to Linus directly.

14:57 <broonie> geertu: Which then generates a big block of merges at once without detailed messages about why the merge happens right now (since the answer is "to package them up for Linus") which he's not thrilled about either.

14:57 <mraynal> geertu: if you do merge all the topic branches, won't you have merge commits anyway?

14:58 <broonie> mraynal: His theory is that you should develop on the topic branch and then only merge it in when it's in some sense complete, doing so with a commit message which explains what's in the topic and why it's complete.

14:59 <mraynal> broonie: ok, looks legitimate

14:59 <geertu> broonie: use a single octopus (or millipede) merge?

14:59 <broonie> geertu: Definitely don't do that, I used to do that and he specifically complained about the number of branches.

14:59 <geertu> broonie: doh

15:00 <geertu> mraynal: yes, but you should avoid having too many.

15:00 <broonie> In practice if it doesn't cause conflicts you're probably fine.

15:00 <mraynal> so the final conclusion is: live off radar :)

15:01 <geertu> I'm not really suffering from that, as I send all individual branches as separate PRs, so e.g. arnd may be merging them together ;-)

15:01 <geertu> The branches that do contains lots of merges (renesas-devel and renesas-next) are never sent upstream.

15:02 <geertu> mraynal: Indeed. Do not cause problems, do not make silly mistakes, and he won't complain.

15:04 <mraynal> yeah, for 5.16-rc1 I did everything clean but Linus refused loudly my PR. It took me quite some time to realize that I wrongly generated my PR against the last patch of mtd/next instead of the mtd/for-xxx tag (which point to the exact same work, but without the PR text...)