mchehab: I should remember to test the docs. :/ Let me have a look, I'll send a patch soon.
hi all
hi!
almost finished with git pull handling
one pull left
finishing atm
that's the cec error injection pull request?
Hi
yep
cool
mchehab: I've just sent another pull, just to add to your work
the doc warning fixup? already handled :-)
mchehab: I assume the window for taking pull requests closes today?
probably yes
Hello!
I might eventually handle something tomorrow or at weekend, but no promises
next week is a short one
due to some holidays
Same here.
I probably won't be able to join you next Thursday
well, I may, if needed, but I guess that there won't be much to discuss
I definitely won't be here next Thursday.
I guess anything urgent can just be posted to the media-submaintainers ML
works for me.
let's do this: let's skip next week's meeting
ack
if someone has something urgent, ping via e-mail
btw, FYI, today I submitted at LKML a patch series doing some text changes at COPYING, in order to mention the SPDX documentation...
in the hope that this will make easier for us to discuss with developers/companies when replacing in-file licenses by SPDX
not sure if it will be accepted or not, but I guess chances are high that it will be accepted
I'm trying to discuss with the authors of ddbridge drivers such replacement on their files
(in priv)
on a separate news, I'm preparing a patchset for tuner-xc2028 in order to make it independent of tuner-core. patchset is complex, so I'd appreciate reviews when ready
Long time ago since I last looked at tuners...
(the work is almost done - but it require tests)
yeah, I haven't touched at tuner-core for a while :-)
the goal here is to make it to fully use I2C binding - for both V4L2 and DVB
that's great.
yep
Nice to see some real progress for DVB.
yep. Well, newer drivers were already doing I2C binding for dvb, but attaching with the new way was complex
I made some patches to make it simpler
probably we'll have some instability for a while, until the code gets mature enough
but the net result will be a huge improvement, IMO
anything to discuss?
I talked to Padovan at the ELC.
good
His fences patch series is almost ready, hopefully it will be done with the next version he'll post.
I didn't have time yet to look at the last version of it
Probably in around 2 weeks time.
great!
So hopefully it can go in early for 4.18.
mchehab, hverkuil: I'll send a patch to address the v4l2_find_nearest_size issue in my previous pull request. The pull request unfortunately contained an old version for the latter four patches.
sounds a nice goal
Other than that, I'm working on the request API.
sailus: please next time do compilation tests on every patch you send...
usually, I would have caught it, but I broke my compilation test when I tried to use Gert's diff script
I reverted it already
btw, I'll likely work on trying to reduce the warning messages
mchehab: Reverted what?
as now I won't have the diff script anymore, I'll try to reduce it to a more manageable list of "valid" warnings
Geert developed a script called "linux-log-diff"
in thesis, you could feed it with a previous build log...
I'll try to do better in validating the patches... :-+
and use it to compare both old and new build logs
in order to see what are the new warnings/errors
I moved to sometime ago, when he pointed about that on one of the patches I wrote
s/moved to/moved to use it/
it works fine on some cases... however after spectrum/retpoline patches, sometimes the build fails very early, and the script doesn't get it...
or doesn't return an error code
so, my scripts were printing nothing, but "compilation succeeded"
So, effectively, I was missing new build errors/warnings
For now, I just reverted the changes
and added a few patches to smatch in order to make it shut up with some very annoying warnings at Kernel's core asm headers (due to retpoline patches)
FYI, my scripts currently do:
$ make ARCH=i386  CF=-D__CHECK_ENDIAN__ CONFIG_DEBUG_SECTION_MISMATCH=y C=1 W=1 CHECK='compile_checks' M=drivers/staging/media
$ make ARCH=i386  CF=-D__CHECK_ENDIAN__ CONFIG_DEBUG_SECTION_MISMATCH=y C=1 W=1 CHECK='compile_checks' M=drivers/media
where compile_checks is a small script with:
#!/bin/bash
/devel/smatch/smatch -p=kernel $@
/devel/sparse/sparse $@
so, for every single patch I receive, I check with W=1, smatch, smarse and CF=-D__CHECK_ENDIAN__ CONFIG_DEBUG_SECTION_MISMATCH=y
sailus: I'll likely write a pile of patches to fix some atomisp warnings
mchehab: Which ones? :-D
Well, just send them. I think there is just a single, trivial one pending right now (from me).
https://pastebin.com/fmZ2qang
Wow.
That's the entire media tree but staging:
https://pastebin.com/eHa11NnE
(and several are false-positives)
that's because we already disabled a lot of warnings at atomisp's Makefile
with:
ccflags-y += $(call cc-disable-warning, unused-but-set-variable)
ccflags-y += $(call cc-disable-warning, unused-const-variable)
ccflags-y += $(call cc-disable-warning, missing-prototypes)
ccflags-y += $(call cc-disable-warning, missing-declarations)
(see drivers/staging/media/atomisp/i2c/Makefile)
mchehab: I'll take a look at the cec-core.c warnings.
thanks, that will help!
I'll wait until that cec error inj pull request is merged, though.
ideally, this should be zero, but, if it is around ~20-40 lines of warnings, it won't be that bad
the conversion to the new I2C binding schema will help to get rid of several false-positives - but that takes time
need to go... bbl
OK, thanks!
back