hi all
helllo
hi!
Hello!
hello even :)
hi
We're complete.
Yesterday I sent a pull request for v4.15, but I can't find it in patchwork. Did it get lost?
I don't have anything special. Basically waiting for rc1 to be released and merged in our master.
syoung: Can you see it in the list archive?
https://www.mail-archive.com/linux-media@vger.kernel.org/msg122193.html
W.r.t. the request API I am waiting for Alexandre to release a first beta.
syoung: did you use git request-pull?
mchehab: do you plan to merge v4.14 in linuxtv master ?
no
we're currently av -rc6
s/av/at/
why not ?
I'll merge v4.15-rc1 when released
mchehab: I did
I try to avoid having too many merges, from upstream
so, I only merge back from upstream when needed
mchehab: I'm looking forward to that. I'd have a pull request to send, once we have rc1. :-)
there's a runtime PM breakage that was fixed after -rc6 (in -rc8 if I recall correctly)
if you merged v4.14 I could already prepare pull requests
pinchartl: if Linus won't release -rc1 this week, feel free to ping me on Monday
from -next status:
Non-merge commits (relative to Linus' tree): 847
 874 files changed, 20738 insertions(+), 7941 deletions(-)
I suspect that he's about to relase -rc1 anytime soon
s/relase/release/
Anything I should review? I think I'm fairly up to date.
I've had some time to work on refcounting on DVB. Seems there are quite a few changes in the framework side needed, let's see how this turns out to be in drivers. I have rtl28xxu stick which uses dvb-udb-v2.
That's work in progress, no patches to review yet.
speaking of reviews, I have one for mchehab
syoung: try to do bounce the e-mail to patchwork@linuxtv.org
mchehab: https://www.spinics.net/lists/linux-renesas-soc/msg20256.html
("[PATCH/RFC 0/2] V4L2: Handle the race condition between device access and unbind")
sailus: if you need some more dvb hardware, let me know. I have some dvb+v4l2+radio sticks that might be of interest to you.
mchehab: Message bounced.
(said mutt)
pinchartl: I'll take a look
mchehab: I did "git request-pull linuxtv/master git://linuxtv.org/syoung/media_tree.git for-v4.15e > pr" then inserted the file pr into an email and wrote a paragraph above it.
hverkuil: I have also an em28xx stick I got from Mike.
syoung: same for you: if you need some DVB hardware (e.g. PCI(e) cards) I can mail you some.
hverkuil: I'm less concerned with PCI devices as they're not hot-unpluggable.
syoung: it didn't get
I'd presume that if I get a single driver working nicely, converting more wouldn't be hard. There aren't that many DVB drivers that support MC.
let me see what's happening
hverkuil: any dvb hardware that needs work would be of interest, I much prefer working on drivers when I have the hardware
$ cat /tmp/git_pull | /usr/local/patchwork/patchwork/bin/parsemail.sh
not a git pull request
there's something that you did on it that causes parsemail to not accept it as a pull request
basically, it doesn't fit at GIT regex expressions there
def find_pull_request(content):
mchehab: postfix said: Nov 23 12:13:39 gofer.mess.org postfix/smtp[28362]: 9B7EB60A51: to=<patchwork@linuxtv.org>, relay=www.linuxtv.org[130.149.80.248]:25, delay=1.5, delays=0.17/0.15/0.18/0.96, dsn=2.0.0, status=sent (250 OK id=1eHqNu-00053U-Ef)
    git_re = re.compile('^The following changes since commit.*' +
                        '^are available in the git repository at:\n'
                        '^\s*([\S]+://[^\n]+)$',
                           re.DOTALL | re.MULTILINE)
    match = git_re.search(content)
    if match:
        return match.group(1)
    print "not a git pull request"
"the Git rep"
ok, let me check
"G" is in uppercase
did you change that?
or git-pull is generating an uppercase G on your machine?
right, git request-pull is doing that for me. Maybe it's seomething in the git version on fedora 27?
gah, it is using uppercase
ok, I fixed the regex to accept both
it got accepted now:
https://patchwork.linuxtv.org/patch/45541/
https://github.com/git/git/commit/e66d7c37a5f123f1dcede06ac0e11f9254c3ef46
mchehab: great, thanks!
mchehab: the patch series I pointed you to is an RFC. I'd like to work on a v2 next week, so I'd appreciate your oppinion
to make sure we agree on the direction
ok
syoung: btw patchwork upstream also seems broken: https://github.com/getpatchwork/patchwork/blob/master/patchwork/parser.py
https://github.com/getpatchwork/patchwork/blob/master/patchwork/parser.py#L829
pinchartl: on a real quick look on your RFC, I would love to see it on a USB driver, in order to check how it would compare with the current solutions out there
which solution(s) ?
USB is slightly different, as some of the race conditions are handled by the USB core
based on USB notification
USB notification ? do you mean USB disconnect ?
I mean, if we'll be adding support for this at the core, it should work for all hotplug devices
yes
the USB driver .disconnect() method is the equivalent of the platform driver .remove() method
I'm not sure to see what your concern is
what I meant to say is that it is easy to check if hotplug is ok with USB hardware
if we're moving the unplug logic to the core, that should be simplifying the code there
I'll make sure to explain what drivers still need to do
also, it is easier to test it on USB
if you find physical unplug easier to test than sysfs unbind, sure
but I find it easier to test using sysfs unbind
I find easier to use a hardware that everyone has
as you can script the test and reproduce it without involving manual unplug
and with users has testing hot unplug for a long time
I believe the uvcvideo is safe already due to a combination of race condition handling by the USB core and careful resource management in the driver. the RFC patch series isn't needed for that driver
if I understood it right, then it is just adding an extra serialization layer at the core that only a few drivers will really benefit from it
it applies to all platform devices at least
if that's only need for a subset of the drivers, then the logic there should be enabled only for those subset of drivers... e. g. the logic should, for example, be checking if access_refcount is not NULL
sorry, access_refcount is not a callback
anyway, if only platform drivers will use, you should likely have something to enable/disable the extra code
I'm actually considering moving that code to the device core as it applies to all drivers that have device nodes, but I'm not sure that will be feasible
it won't hurt other devices
it applies to I2C and SPI as well at least
and PCI too
pinchartl: Which RFC?
sailus: https://www.spinics.net/lists/linux-renesas-soc/msg20256.html
Btw. this discussion would be better on #v4l. Just my opinion.
moving something like that at device core makes sense
sailus: agreed
anyway, I'll make sure to explain the issues in the next version
please c/c Greg on it, as he's maintaining driver core
it probably makes sense to c/c USB ML
I guess there isn't any list specific for driver's core, so maybe c/c LKML
anything else for today's meeting?
not from me
not from me either
ok, thanks for the meeting
pinchartl: with regards to the RFC, just wrote an e-mail with my PoV
maybe hverkuil could take a look on it as well, as he added V4L2 core support for USB hot unplug back in 2009
commit ae6cfaace120f4330715b56265ce0e4a710e1276
Author: Hans Verkuil <hverkuil@xs4all.nl>
Date:   Sat Mar 14 08:28:45 2009 -0300
mchehab: thank you
anytime
I wasn't aware of that patch
unsurprisingly it looks broken, like all hotplug handling code in V4L2 :-)
but that's fine, we'll fix it
hotplug is hard :-)
i mean: doing it right is hard
i suspect that the only way to really avoid race issues on disconnect is to implement it at driver's core
no, I think it can be implemented in subsystems, but then there will be code duplication
I'm not so sure... having multiple spinlocks can be a problem
think, for example, on a v4l+dvb+rc+cec driver handling a disconnect... if every subsystem has its own spinlock, it will end by having race issues
my guts tell that either the lock should be at the driver or at the driver core
actually I've been testing hotplug for lirc recently. I had a process doing an open(/dev/lirc), then doing a few operations requiring the driver, close, in a tight lop
loop
then I bind/unbind the driver in a tight loop in another shell
I discover
ed a few issues there
(kernel with kasan and lockdep enabled)
There were a few use-after-free issues which I had never noticed from reading source code
I had to add locking to rc-core, since drivers do not expect any calls after they call rc_unregister_device()