mchehab: this is the linux-next repo, right: git://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git and the master branch is the right branch to check out? I ask because the input patches of my CEC series apply cleanly there, but you had conflicts. So now I am confused. hverkuil: I didn't actually tried to apply the patch. Just looked at the file via cgit Still, I think that it is better/safer to send such patch via input tree mchehab: do you want both patch 1 and 2 to go via input tree? How to handle this so patches 3 and up can still be merged in our tree? yes, patches 1 and 2 the RC map file can also be send to his tree, with my ack well, patch 1 actually seems ok to go via my tree as I doubt there are much updates for new types I would prefer to have just patch 2 and 3 go via Dmitry. I'll have to double-check, but I think those are independent of the remainder of the series. (compiling now without patches 2 & 3) hmm, dependency on RC_TYPE_CEC. patch 1 can go on both trees, I guess OK, if I split patch 3 in two: one patch for rc-cec and one for the remainder, then I think it should work OK. OK, just to check: if I split patch 3 into two: one patch for rc-cec.c and one for rc-main/rc-map.h, then patch 2 can go via Dmitry's tree and the rc-cec patch would be on hold in our tree until the input-event-codes.h changes are merged for 4.8. Everything else can be merged in our master. You just don't have the rc-cec keymap module. (rc-cec.c depends on the rc-map.h changes AND on the input-event-codes.h changes) ok hmm... maybe it is better to just merge patch 1 on both this s/this/trees/ this way, I don't need to put it on a separate topic branch I propose that I split up patch 3 as described above and that I post a v18 (I just fixed a s5p-cec warning as well that I missed) with a CC to linux-input. Once done, you can Ack the input patch(es) that you want Dmitry to handle. You can then merge the cec patches except the one for the rc-cec keymap. Alternatively, I can also #if 0 the new keys in rc-cec.c so it can be merged in our tree, and for 4.8 a follow-up patch is added that removes the #if 0's. #if 0 works for me well, it also works to merge the rc-cec late you mean the rc-cec keymap patch late, right? right ok, let's do that OK. can the rc-cec be merged via Dmitry's tree? if so, we can send him patches 1 and 2 + rc-cec keymap and merge the rest via our tree well, rc-cec depends on both the input-event-codes.h change AND the rc-map.h change, and the cec framework depends on rc-map.h. It makes no sense to me to have Dmitry handle rc-cec.c. I think it is easiest to just keep rc-cec.c aside until both the input and media changes are merged in 4.8. I don't see any problem asking dmitry to merge patch 3 as a hole it won't cause any conflicts on our side of course, I'll need to sign it or ack you're talking about patch 3 as I posted it in v17? the remaining patches on this series depend on patch 1-3 to build? yes As it stands now in v17, the remaining patches depend on 1-3. what's de dependency? +#define RC_MAP_CEC "rc-cec" ? But only rc-cec.c depends on input-event-codes.h. I mean: what patches 4-16 depends on the stuff at 1-3? the cec framework depends on patch 1 (BUS_CEC) and RC_BIT_CEC, RC_MAP_CEC and RC_TYPE_CEC defines from rc-map.h. (patch 9) ok. let's then put patch 1 and a patch adding those 3 defines on a stable topic branch... asking Dmitry to pull from it and merge patch 1 and 3 (without the above) on his tree I think this is overly complex. If I split patch 3 in two, one updating rc-main.c and rc-map.h and the other for rc-cec.c, then all that needs to be kept aside is the rc-cec patch. No need to keep a big topic branch. My opinion. Besides, rc-cec.c itself depends on RC_TYPE_CEC as well. and RC_MAP_CEC. ok let's do that You were planning to merge patch 1 through both trees, right? Since patch 9 depends on that. (both trees == linux-input and linux-media) works for me just let me and Dmitry to know what patches should go to each tree IMHO, the best is if you send 2 patch series: one for me; another for Dmitry I"ll ack on his series OK, sounds good. I'll do a third patch series as well with just the rc-cec patch, to keep it separate from the other two. Is there anything else I should do before I spam the lists with a v18? I hate having to do a v19 :-) hverkuil: v18 ? looks like the patch set reached adulthood :-) it does feel like that :-) I guess that's it OK. I'm preparing the patch series. I got it half working http://www.ideasonboard.org/vsp-rotation.png but there seems to be still something missing mchehab: posted the patch series for linux-input. Hmm, the original RFC for CEC was posted March 2010. So this patch series is the equivalent of a nice 6 year old whisky :-) posted v18 of the patch series. mchehab: do you want a pull request as well for v18? I'll just post one.