[11:57] <mchehab> hi all
[11:57] <hverkuil> hi!
[11:59] <mchehab> hi syoung, sailus, pinchartl
[11:59] <mchehab> anything for today?
[11:59] <syoung> hi
[12:00] <hverkuil> mchehab: there are some pending PRs, when do you plan to look at those?
[12:00] <mchehab> hverkuil: didn't have time yet to look at the patchset you pointed me (that videodev2 sync thing).... has been too busy on my side
[12:01] <hverkuil> My tentative plan is to go through my pending patches next week for new PRs, so expect more PRs coming next week.
[12:02] <mchehab> good question. I'm working against the time to solve something internally... I'm hoping to address it until Fri. If so, I'll handle PRs either tomorrow or early next week
[12:02] <hverkuil> OK. That gives me some idea of what to expect.
[12:03] <hverkuil> I have WAY too many pending patches :-(
[12:03] <mchehab> heh :-(
[12:04] <hverkuil> pinchartl: I'll probably ping you next week about that ti-vpe cal 107-part series :-)
[12:04] <mchehab> If things get calm here, I'll try to help picking some pending stuff
[12:04] <mchehab> syoung: there's a patch addressing config32 stuff for DVB
[12:04] <mchehab> not sure if you know much about that...
[12:05] <mchehab> basically, when a driver runs on 64 bits, while userspace is on 32 bits, the compat32 code makes the conversion
[12:05] <mchehab> (as pointers change their size)
[12:06] <mchehab> I didn't tried, but it sounds that the patch is supposed to fix some ioctls
[12:06] <syoung> I was just going to mention that series
[12:06] <syoung> (looking for the link)
[12:07] <mchehab> Unbreak 32-bit DVB applications on  64-bit kernels
[12:07] <mchehab> (that's the name of the thread)
[12:07] <syoung> Yes, this is not something I've looked at before.
[12:07] <pinchartl> hverkuil: sure :-)
[12:07] <pinchartl> there will be a v2 of the series
[12:07] <mchehab> with people start using 64 bits on ARM, the compat thing became more important
[12:08] <mchehab> (on x86, I guess nobody actually uses the compat32 anymore, in practice, as distros are fasing out support for x86_32)
[12:08] <hverkuil> pinchartl: do you want me to review v1? Or should I wait for v2? I got 442 patches in my TODO list, so if I can get rid of 107 for now, then that would be nice :-)
[12:09] <mchehab> funny enough, the series is for Kernel 4.9...
[12:09] <mchehab> not sure what's the upstream status with that regards
[12:10] <syoung> I find it a bit annoying having to review something for ancient kernels, why are we encouraging people to run ancient kernels.
[12:11] <mchehab> well, just check if upsream is OK, then ;-)
[12:11] <pinchartl> hverkuil: up to you. it's a bunch of tiny patches, I don't expect any major change to be required
[12:11] <pinchartl> if you want to have a look at the big picture, you can review v1
[12:11] <pinchartl> if you want to review all details you can wait for v2, but that may not be the best use of your time
[12:11] <mchehab> I bet that the port to 4.9 is due to some android or some other embedded hw that uses a platform DVB driver on arm64
[12:11] <pinchartl> Tomi and Kieran are reviewing the details already
[12:11] <mchehab> 4.9 is a LTS Kernel
[12:13] <syoung> Sure 4.9 is an LTS kernel. Still, if you're suddenly interested in compat then you're doing something completely new like run a 64 bit kernel
[12:14] <hverkuil> pinchartl: would it make sense to split this into two series: one cleanup/refactoring (001-083) and one for the actual MC conversion on top? The first part can probably be merged quite quickly. Up to you, though.
[12:14] <mchehab> syoung: it is not that easy... right now, I'm stuggling with a 4.9-based kernel, with a driver that were not ported upstream
[12:15] <mchehab> (there's an open source version, but on a downstream Kernel, based on Android)
[12:15] <mchehab> it even depends on staging android crap
[12:15] <pinchartl> hverkuil: I'm fine not merging everything in one go, but I'd rather not split the submission in two series
[12:16] <hverkuil> OK.
[12:16] <pinchartl> as for MC conversion, it's not a real conversion, it's addition of an optional API. the video node centric API still works as before
[12:16] <pinchartl> (or better, as there should be a few bug fixes in the series :)-)
[12:17] <syoung> I realise reality is not that easy, because of all the non-upstream crap. Crap we shouldn't be caring about.
[12:17] <mchehab> hverkuil, pinchartl: please refrain from sending a PR with too many paches... the mailbomb script has a threshold (something between 50-100 patches), as a protection measure about flooding ML with too many patches
[12:17] <syoung> Anyway I don't mind reviewing the current state of 32 compat on dvb, and then doing a quick review on the 4.9 rubbish based on that.
[12:18] <mchehab> well, if you send a PR, I'll just pull it by parts, but still it would be better to have smaller PRs
[12:18] <mchehab> syoung: ok, thank you!
[12:18] <hverkuil> pinchartl: do you expect changes in v2 for patches 001-083?
[12:19] <syoung> mchehab: I'm pretty busy on all fronts so it'll be next week or late
[12:19] <mchehab> ok
[12:19] <hverkuil> ah, probably you will based on Tomi/Kieran review comments.
[12:20] <mchehab> syoung: my main concern is if upstream is OK or not. depending on what's there, it is possible that the code is just a complete garbage
[12:22] <pinchartl> hverkuil: yes, small changes and bugfixes
[12:22] <mchehab> we had to do a large rework on compat32 a few years ago at V4L2 side. We didn't do the same on dvb
[12:24] <hverkuil> it looks like a lot of the patches from Florian are cleanups/fixes, those can probably be reviewed quite easily.
[12:25] <mchehab> yeah, it sounds that most of his patches aren't the actual compat32 fixes
[12:25] <mchehab> as the DVB core doesn't change much, it may be possible that they would even apply almst cleanly against upstream
[12:26] <mchehab> hverkuil: do you remember who wrote the initial compat32 code on that time?
[12:26] <mchehab> If my memories are not tricking me...
[12:26] <hverkuil> I think patch 19/21 is the only patch that does compat32 stuff.
[12:26] <hverkuil> compat32 code of what? dvb? v4l2?
[12:26] <mchehab> someone sent a version against an older kernel, and you did the efforts of making it work upstream
[12:26] <mchehab> v4l2
[12:27] <hverkuil> That was not for compat32 support as such, that was to fix a security hole in the v4l2 compat32 code.
[12:27] <hverkuil> It was v4l2 specific, it didn't affect dvb.
[12:29] <mchehab> yes, I remember it was due to set_fs() calls at v4l2 compat32 code
[12:29] <hverkuil> right
[12:29] <mchehab> dvb doesn't use this, as far as I remember
[12:29] <mchehab> but I guess the original set was sent against some older Kernel version or had some other issue...
[12:30] <mchehab> and you ended needing to do the work against upstream. right? (or my memories are tricking me?)
[12:31] <hverkuil> Yes, that's correct. But it was badly done anyway so I believe I just rewrote most (all?) of it.
[12:31] <mchehab> yes
[12:32] <hverkuil> this dvb series looks much easier to port to mainline.
[12:34] <mchehab> hmm.. all patches seem to be backports from upstream...
[12:34] <mchehab> as they all seem to contain my SOB
[12:48] <mchehab> but in thesis, it should call dtv_set_frontend() only once
[12:58] <syoung> I'll go through them when I have some time