[06:53] <hverkuil> mchehab: just a heads up: unless something unexpected happens I'll make a new PR tomorrow for 5.3 with the first three patches from the "cec: improve notifier support, add connector info" series I posted yesterday.
[06:55] <hverkuil> This makes life much easier for the 5.4 cycle since all further changes in drm and media can be done independently without requiring cross-subsystem patches.
[07:18] <hverkuil> RFC: can we please kill off drivers/staging/media/soc_camera for 5.4?
[07:20] <hverkuil> Candidates for outreachy or linux kernel mentee projects keep trying to 'clean them up', and I think keeping BROKEN drivers around is just a really bad idea.
[10:16] <mchehab> hverkuil: I don't see any issue on a mentee that want to work on soc_camera... they just need to convert the drivers and test them after the changes
[10:16] <mchehab> it is up to the mentor to put them into the right direction (or to convince them to select a different target)
[10:17] <mchehab> removing stuff from the kernel just because a mentor can't convince the mentee to do what should be done sounds stupid :-p
[10:20] <mchehab> with regards to PR, as I said before, I'll be OOT next week, being without Internet access - so I'll probably stop merging patches a little earlier this time
[10:20] <mchehab> so, the earliest you send me a PR, the more likely it will be merged for 5.3...
[10:21] <mchehab> yet, as I said before, it is not a good idea to send big patches like driver additions the very last week before the merge window
[10:22] <mchehab> (I mean: "before the merge window freeze" - with happens one week before the actual merge window)
[10:45] <hverkuil> mchehab: I meant soc_camera style patches like this: https://patchwork.linuxtv.org/patch/57074/
[10:45] <hverkuil> Nobody will be converting those drivers as an internship project since that requires specialized hardware.
[10:46] <hverkuil> Generally not an option for interns.
[10:46] <hverkuil> I plan on posting the PR this evening.
[10:49] <mchehab> hverkuil: well, if one really wants to do it, he could buy the hardware and do the patch - otherwise the mentor should tell them to say out of that
[10:50] <mchehab> btw, the TODO tells what it is expected there:
[10:50] <mchehab> $ more drivers/staging/media/soc_camera/TODO
[10:50] <mchehab> The SoC camera framework is obsolete and scheduled for removal in the near
[10:50] <mchehab> future. Developers are encouraged to convert the drivers to use the
[10:50] <mchehab> regular V4L2 API if these drivers are still needed (and if someone has the
[10:50] <mchehab> hardware).
[10:51] <mchehab> at very least, I would expect that any mentor would tell their mentees to read TODO when touching at drivers/staging
[10:51] <hverkuil> It seems we have different views on this. I hate having dead code in the kernel. What's the point of git if you still keep old dead code around?
[10:52] <hverkuil> Anyway, not important enough to make a big deal of it. I'll just keep rejecting patches touching on soc_camera.
[10:52] <mchehab> I'm ok to make the TODO even clearer, explicitly stating that we'll *only* accept patches converting the drivers
[10:54] <mchehab> hverkuil: yeah, our views are somewhat different with regards to staging
[10:54] <mchehab> for me, staging is a sort of trash can, where we place bad code
[10:55] <mchehab> ok, we should not keep stuff there for too much time
[10:56] <hverkuil> bad code, yes, but broken code is where I draw the line.
[10:56] <mchehab> as, from time to time, we need to recycle the trash can
[10:57] <mchehab> I have a hysteresis criteria with regards to broken code
[10:57] <mchehab> I won't accept adding a broken code to staging...
[10:57] <mchehab> but I won't use broken code as my removal criteria..
[10:58] <mchehab> instead, I use other criteria for removal :
[10:58] <mchehab> - don't build anymore
[10:59] <mchehab> - prevents of makes the introduction of a new feature too complex
[10:59] <mchehab> - it is at staging for a long time
[10:59] <mchehab> so, yeah, the third criteria will eventually reach the soc_camera drivers
[11:00] <mchehab> but there are some stuff under drivers/staging/media/ that are older than soc_camera
[11:00] <mchehab> I mean soc_camera -> staging patchset
[11:02] <mchehab> that's said, what is a "long time" for staging i something that we never defined
[11:02] <mchehab> omap24xx and omap4iss, for example, are there for a very long time (IMHO), without any patches addressing the issues that made them to go to staging
[11:02] <mchehab> I'm not seeing any efforts to move imx out of staging
[11:03] <mchehab> ...
[11:03] <mchehab> I propose adding this as a theme for our next Media Summit:
[11:03] <mchehab> criteria to remove drivers from staging
[11:04] <mchehab> syoung: just sent a dvb patch today. Care to review and ack or merge though your tree?
[11:05] <mchehab> (it is a no-brainer - yet, I'd like to have at least 2 SoBs for patches that do functional changes)
[11:06] <hverkuil> mchehab: can you post that topic to media-submaintainers? Let's collect all such ideas there.
[11:06] <hverkuil> Any progress finding a location?
[11:06] <mchehab> by SOB here - I actually mean: sob, review, ack or test)
[11:07] <mchehab> hverkuil: no... didn't have much time to chase for a location myself
[11:07] <mchehab> will re-ping KS/Plumbers comittee
[11:10] <mchehab> Just sent an e-mail to LF... maybe they could help us to rent a location
[11:12] <pinchartl> hverkuil: for what it matters, I agree with you, I'm fine removing that code
[11:14] <mchehab> The soc-camera driver went to staging on    Thu Feb 7 08:43:47 2019 -0500
[11:15] <mchehab> if we're removing it, we should also remove the other drivers that went to staging before Feb, 2019
[11:17] <mchehab> omap24xx last patch:
[11:17] <mchehab>    commit db85a0403be4a59cf536a25622fe110feefba8d3
[11:17] <mchehab>    Date:   Fri Nov 14 10:19:47 2014 +0100
[11:17] <hverkuil> but the others aren't dead code. That's the key difference for me.
[11:18] <mchehab> for me, a driver at staging that it is there for 4 years without anyone touching it is dead
[11:18] <hverkuil> that said, I think bcm2048 and omap4iss are candidates for removal unless someone actually steps up and finishes them.
[11:19] <mchehab> my proposal here is to discuss those things at the summit
[11:19] <mchehab> check when the last time people did a non-cleanup contribution to the stuff under staging
[11:20] <mchehab> if it is more than, let's say, 12 months, I would "tag" it to be subject to removal
[11:20] <mchehab> we should make a public announce about what will be removed and when...
[11:20] <mchehab> if nobody steps out to fix, we just send to /dev/null
[11:22] <mchehab> it sounds that the last functional changes at omap4iss that were not due to a kAPI change were back on 2015
[11:29] <mchehab> hmm... omap24xx were already removed - sometimes git keeps the old dirs - even without any files on them
[11:29] <mchehab> hverkuil: yeah, I agree that bcm2048 and omap4iss are good candidates for removal
[11:31] <hverkuil> ditto davinci_vpfe
[11:31] <mchehab> yep
[11:33] <mchehab> lots of cleanup, but I'm already at 2016 logs - no changes directly related to its code so far
[11:34] <mchehab> I guess this is the last patch specific to DaVinci:
[11:34] <mchehab>     commit 171fe6d1270d535eae798e4b5acc9f5d25e6e17e
[11:34] <mchehab>     [media] media: davinci_vpfe: set minimum required buffers to three
[11:35] <mchehab> Actually, this one
[11:35] <mchehab>    commit 4f26aa17860dadbfb861d8701224c52275ca8593
[11:35] <mchehab>    Date:   Mon May 25 12:34:29 2015 -0300
[11:35] <mchehab> 2015
[11:48] <mchehab> hverkuil: just sent a patch proposing a date for those legacy code to RIP
[11:49] <mchehab> still, IMO we should discuss at the media summit about a criteria for getting stuff out of staging
[12:00] <mchehab> sent a proposal for the next media summit for such discussions too