<!-- Some styling for better description lists --><style type='text/css'>dt { font-weight: bold;float: left;display:inline;margin-right: 1em} dd { display:block; margin-left: 2em}</style>
mchehab: hi all
syoung: helllo
hverkuil: hi!
sailus: Hello!
syoung: hello even :)
pinchartl: hi
hverkuil: We're complete.
syoung: Yesterday I sent a pull request for v4.15, but I can't find it in patchwork. Did it get lost?
hverkuil: I don't have anything special. Basically waiting for rc1 to be released and merged in our master.
sailus: <u>syoung</u>: Can you see it in the list archive?
syoung: https://www.mail-archive.com/linux-media@vger.kernel.org/msg122193.html
hverkuil: W.r.t. the request API I am waiting for Alexandre to release a first beta.
mchehab: <u>syoung</u>: did you use git request-pull?
pinchartl: <u>mchehab</u>: do you plan to merge v4.14 in linuxtv master ?
mchehab: no
pinchartl: we're currently av -rc6
<br> s/av/at/
<br> why not ?
mchehab: I'll merge v4.15-rc1 when released
syoung: <u>mchehab</u>: I did
mchehab: I try to avoid having too many merges, from upstream
<br> so, I only merge back from upstream when needed
sailus: <u>mchehab</u>: I'm looking forward to that. I'd have a pull request to send, once we have rc1. :-)
pinchartl: there's a runtime PM breakage that was fixed after -rc6 (in -rc8 if I recall correctly)
<br> if you merged v4.14 I could already prepare pull requests
mchehab: <u>pinchartl</u>: if Linus won't release -rc1 this week, feel free to ping me on Monday
<br> from -next status:
<br> Non-merge commits (relative to Linus' tree): 847
<br> 874 files changed, 20738 insertions(+), 7941 deletions(-)
<br> I suspect that he's about to relase -rc1 anytime soon
<br> s/relase/release/
hverkuil: Anything I should review? I think I'm fairly up to date.
sailus: 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.
<br> That's work in progress, no patches to review yet.
pinchartl: speaking of reviews, I have one for mchehab
mchehab: <u>syoung</u>: try to do bounce the e-mail to patchwork@linuxtv.org
pinchartl: <u>mchehab</u>: https://www.spinics.net/lists/linux-renesas-soc/msg20256.html
<br> ("[PATCH/RFC 0/2] V4L2: Handle the race condition between device access and unbind")
hverkuil: <u>sailus</u>: if you need some more dvb hardware, let me know. I have some dvb+v4l2+radio sticks that might be of interest to you.
syoung: <u>mchehab</u>: Message bounced.
<br> (said mutt)
mchehab: <u>pinchartl</u>: I'll take a look
syoung: <u>mchehab</u>: 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.
sailus: <u>hverkuil</u>: I have also an em28xx stick I got from Mike.
hverkuil: <u>syoung</u>: same for you: if you need some DVB hardware (e.g. PCI(e) cards) I can mail you some.
sailus: <u>hverkuil</u>: I'm less concerned with PCI devices as they're not hot-unpluggable.
mchehab: <u>syoung</u>: it didn't get
sailus: 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.
mchehab: let me see what's happening
syoung: <u>hverkuil</u>: any dvb hardware that needs work would be of interest, I much prefer working on drivers when I have the hardware
mchehab: $ cat /tmp/git_pull | /usr/local/patchwork/patchwork/bin/parsemail.sh
<br> not a git pull request
<br> there's something that you did on it that causes parsemail to not accept it as a pull request
<br> basically, it doesn't fit at GIT regex expressions there
<br> def find_pull_request(content):
syoung: <u>mchehab</u>: 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)
mchehab: git_re = re.compile('^The following changes since commit.*' +
<br> '^are available in the git repository at:\n'
<br> '^\s*([\S]+://[^\n]+)$',
<br> re.DOTALL | re.MULTILINE)
<br> match = git_re.search(content)
<br> if match:
<br> return match.group(1)
<br> print "not a git pull request"
<br> "the Git rep"
syoung: ok, let me check
mchehab: "G" is in uppercase
<br> did you change that?
<br> or git-pull is generating an uppercase G on your machine?
syoung: right, git request-pull is doing that for me. Maybe it's seomething in the git version on fedora 27?
mchehab: gah, it is using uppercase
<br> ok, I fixed the regex to accept both
<br> it got accepted now:
<br> https://patchwork.linuxtv.org/patch/45541/
syoung: https://github.com/git/git/commit/e66d7c37a5f123f1dcede06ac0e11f9254c3ef46
<br> <u>mchehab</u>: great, thanks!
pinchartl: <u>mchehab</u>: 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
<br> to make sure we agree on the direction
mchehab: ok
<br> <u>syoung</u>: btw patchwork upstream also seems broken: https://github.com/getpatchwork/patchwork/blob/master/patchwork/parser.py
<br> https://github.com/getpatchwork/patchwork/blob/master/patchwork/parser.py#L829
<br> <u>pinchartl</u>: 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
pinchartl: which solution(s) ?
<br> USB is slightly different, as some of the race conditions are handled by the USB core
mchehab: based on USB notification
pinchartl: USB notification ? do you mean USB disconnect ?
mchehab: I mean, if we'll be adding support for this at the core, it should work for all hotplug devices
<br> yes
pinchartl: the USB driver .disconnect() method is the equivalent of the platform driver .remove() method
<br> I'm not sure to see what your concern is
mchehab: what I meant to say is that it is easy to check if hotplug is ok with USB hardware
<br> if we're moving the unplug logic to the core, that should be simplifying the code there
pinchartl: I'll make sure to explain what drivers still need to do
mchehab: also, it is easier to test it on USB
pinchartl: if you find physical unplug easier to test than sysfs unbind, sure
<br> but I find it easier to test using sysfs unbind
mchehab: I find easier to use a hardware that everyone has
pinchartl: as you can script the test and reproduce it without involving manual unplug
mchehab: and with users has testing hot unplug for a long time
pinchartl: 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
mchehab: 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
pinchartl: it applies to all platform devices at least
mchehab: 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
<br> sorry, access_refcount is not a callback
<br> anyway, if only platform drivers will use, you should likely have something to enable/disable the extra code
pinchartl: 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
<br> it won't hurt other devices
<br> it applies to I2C and SPI as well at least
<br> and PCI too
sailus: <u>pinchartl</u>: Which RFC?
pinchartl: <u>sailus</u>: https://www.spinics.net/lists/linux-renesas-soc/msg20256.html
sailus: Btw. this discussion would be better on #v4l. Just my opinion.
mchehab: moving something like that at device core makes sense
pinchartl: <u>sailus</u>: agreed
<br> anyway, I'll make sure to explain the issues in the next version
mchehab: please c/c Greg on it, as he's maintaining driver core
<br> it probably makes sense to c/c USB ML
<br> I guess there isn't any list specific for driver's core, so maybe c/c LKML
<br> anything else for today's meeting?
hverkuil: not from me
pinchartl: not from me either
mchehab: ok, thanks for the meeting
<br> <u>pinchartl</u>: with regards to the RFC, just wrote an e-mail with my PoV
<br> maybe hverkuil could take a look on it as well, as he added V4L2 core support for USB hot unplug back in 2009
<br> commit ae6cfaace120f4330715b56265ce0e4a710e1276
<br> <u>Author</u>: Hans Verkuil <hverkuil@xs4all.nl>
<br> <u>Date</u>: Sat Mar 14 08:28:45 2009 -0300
pinchartl: <u>mchehab</u>: thank you
mchehab: anytime
pinchartl: I wasn't aware of that patch
<br> unsurprisingly it looks broken, like all hotplug handling code in V4L2 :-)
<br> but that's fine, we'll fix it
mchehab: hotplug is hard :-)
<br> i mean: doing it right is hard
<br> i suspect that the only way to really avoid race issues on disconnect is to implement it at driver's core
pinchartl: no, I think it can be implemented in subsystems, but then there will be code duplication
mchehab: I'm not so sure... having multiple spinlocks can be a problem
<br> 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
<br> my guts tell that either the lock should be at the driver or at the driver core
syoung: 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
<br> loop
<br> then I bind/unbind the driver in a tight loop in another shell
<br> I discover
<br> ed a few issues there
<br> (kernel with kasan and lockdep enabled)
<br> There were a few use-after-free issues which I had never noticed from reading source code
<br> I had to add locking to rc-core, since drivers do not expect any calls after they call rc_unregister_device()