13:26 <detlevc> warpme: so with this new board, you still get the h264 issue but very rarely ?

13:26 <warpme> detlevc : yes

13:28 <warpme> i would say: old board on 20 tries 19 are failing; on new board on 20 tries 1 is failing. but issue still happens :-(

14:35 <TahomaSoft> Hi all, I have a question about the email lists to use when submitting patches.

14:36 <TahomaSoft> For sending in patches to support a new Rockchip board, it looks like the patch should be addressed to linux-rockchip@lists.infradead.org & linux-arm-kernel@lists.infradead.org, as well as <heiko@sntech.de.

14:37 <TahomaSoft> Is there another set of lists I should be looking at in the Linux MAINTAINERS file?

14:38 <qschulz> TahomaSoft: do not read the MAINTAINERS list, there are tools to parse this

14:38 <qschulz> https://www.kernel.org/doc/html/latest/process/submitting-patches.html#select-the-recipients-for-your-patch

14:38 <qschulz> it is automatically run by `b4 prep --auto-to-cc` (which is a tool I highly recommend)

14:39 <TahomaSoft> exit

14:40 <TahomaSoft> Cool, I will give that a try right now!! Thank you.

14:40 <qschulz> have fun! looking forward to having your patch(es) on the mailing list(s) :)

14:40 <qschulz> https://b4.docs.kernel.org/en/latest/contributor/overview.html for the docs

14:41 <TahomaSoft> Thank you!

14:42 <TahomaSoft> So I use that instead of git send-mail?

14:42 <qschulz> there are two options for b4, using git send-email underneath (which I do use), or the b4 web submissin endpoint

14:43 <qschulz> it also kind of replaces the way you handle patch series locally so there may be some getting-used-to period

14:44 <TahomaSoft> Ok, thanks. That helps. B4 preps for git send-mail in this case, and git send-mail then uses whatever mechanism I've set up to talk to sendmail/dovecot etc.

14:46 <TahomaSoft> And should I patch against the daily updates to linux-next, or can I use the tag I started working against mid-last week?

14:47 <qschulz> TahomaSoft: you need to setup git-send-email if you want to use that method yes, but b4 send will call it transparently

14:48 <qschulz> TahomaSoft: I would say typically on top of latest master commit, except if you rely on patches only present in linux-next, in which case you should rebase on top of that and make it clear in the cover-letter that it is based on x tag/commit from linux-next

14:49 <TahomaSoft> ok cool, thanks!

16:26 <CounterPillow> fwiw I always use a recent linux-next tag to base things on, unless -rc1 just released. I also put `base-commit: refyoubasedonhere` in my `b4 prep --edit-deps` and keep it updated with future rebases. So usually to rebase my series, I would do `git rebase --onto new-next-tag oldbase`, then `b4 prep --edit-deps` to change base-commit, then `b4 prep --check-deps` as a quick sanity check to make sure I didn't typo anything

17:17 <TahomaSoft> Thanks!

20:23 <TahomaSoft> Thanks for your help folks! Got the patches out with just one known minor flub :)