| ↑back Search ←Prev date Next date→ Show only urls | (Click on time to select a line by its url) |
| Who | What | When |
|---|---|---|
| *** | ChanServ sets mode: +v mchehab | [11:58] |
| mchehab | hi all | [11:58] |
| syoung | helllo | [11:59] |
| hverkuil | hi! | [11:59] |
| sailus | Hello! | [12:00] |
| syoung | hello even :) | [12:00] |
| pinchartl | hi | [12:01] |
| hverkuil | We're complete. | [12:03] |
| syoung | Yesterday I sent a pull request for v4.15, but I can't find it in patchwork. Did it get lost? | [12:04] |
| hverkuil | I don't have anything special. Basically waiting for rc1 to be released and merged in our master. | [12:04] |
| sailus | syoung: Can you see it in the list archive? | [12:04] |
| syoung | https://www.mail-archive.com/linux-media@vger.kernel.org/msg122193.html | [12:05] |
| hverkuil | W.r.t. the request API I am waiting for Alexandre to release a first beta. | [12:05] |
| mchehab | syoung: did you use git request-pull? | [12:06] |
| pinchartl | mchehab: do you plan to merge v4.14 in linuxtv master ? | [12:06] |
| mchehab | no | [12:07] |
| pinchartl | we're currently av -rc6
s/av/at/ why not ? | [12:07] |
| mchehab | I'll merge v4.15-rc1 when released | [12:07] |
| syoung | mchehab: I did | [12:08] |
| mchehab | I try to avoid having too many merges, from upstream
so, I only merge back from upstream when needed | [12:08] |
| sailus | mchehab: I'm looking forward to that. I'd have a pull request to send, once we have rc1. :-) | [12:08] |
| pinchartl | 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 | [12:08] |
| mchehab | 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/ | [12:09] |
| hverkuil | Anything I should review? I think I'm fairly up to date. | [12:12] |
| 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.
That's work in progress, no patches to review yet. | [12:12] |
| pinchartl | speaking of reviews, I have one for mchehab | [12:12] |
| mchehab | syoung: try to do bounce the e-mail to patchwork@linuxtv.org | [12:13] |
| pinchartl | 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") | [12:13] |
| hverkuil | 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. | [12:13] |
| syoung | mchehab: Message bounced.
(said mutt) | [12:14] |
| mchehab | pinchartl: I'll take a look | [12:15] |
| syoung | 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. | [12:15] |
| sailus | hverkuil: I have also an em28xx stick I got from Mike. | [12:15] |
| hverkuil | syoung: same for you: if you need some DVB hardware (e.g. PCI(e) cards) I can mail you some. | [12:15] |
| sailus | hverkuil: I'm less concerned with PCI devices as they're not hot-unpluggable. | [12:16] |
| mchehab | syoung: it didn't get | [12:17] |
| 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. | [12:17] |
| mchehab | let me see what's happening | [12:17] |
| syoung | hverkuil: any dvb hardware that needs work would be of interest, I much prefer working on drivers when I have the hardware | [12:18] |
| mchehab | $ 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): | [12:20] |
| syoung | 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) | [12:21] |
| mchehab | 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" | [12:21] |
| syoung | ok, let me check | [12:22] |
| mchehab | "G" is in uppercase
did you change that? or git-pull is generating an uppercase G on your machine? | [12:22] |
| syoung | right, git request-pull is doing that for me. Maybe it's seomething in the git version on fedora 27? | [12:23] |
| mchehab | gah, it is using uppercase
ok, I fixed the regex to accept both it got accepted now: https://patchwork.linuxtv.org/patch/45541/ | [12:24] |
| syoung | https://github.com/git/git/commit/e66d7c37a5f123f1dcede06ac0e11f9254c3ef46
mchehab: great, thanks! | [12:26] |
| pinchartl | 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 | [12:28] |
| mchehab | 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 | [12:30] |
| pinchartl | which solution(s) ?
USB is slightly different, as some of the race conditions are handled by the USB core | [12:37] |
| mchehab | based on USB notification | [12:37] |
| pinchartl | USB notification ? do you mean USB disconnect ? | [12:37] |
| mchehab | I mean, if we'll be adding support for this at the core, it should work for all hotplug devices
yes | [12:37] |
| pinchartl | the USB driver .disconnect() method is the equivalent of the platform driver .remove() method
I'm not sure to see what your concern is | [12:38] |
| mchehab | 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 | [12:40] |
| pinchartl | I'll make sure to explain what drivers still need to do | [12:42] |
| mchehab | also, it is easier to test it on USB | [12:43] |
| pinchartl | if you find physical unplug easier to test than sysfs unbind, sure
but I find it easier to test using sysfs unbind | [12:43] |
| mchehab | I find easier to use a hardware that everyone has | [12:44] |
| pinchartl | as you can script the test and reproduce it without involving manual unplug | [12:44] |
| mchehab | and with users has testing hot unplug for a long time | [12:44] |
| 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 | [12:45] |
| 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 | [12:46] |
| pinchartl | it applies to all platform devices at least | [12:47] |
| 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
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 | [12:48] |
| 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
it won't hurt other devices it applies to I2C and SPI as well at least and PCI too | [12:50] |
| sailus | pinchartl: Which RFC? | [12:51] |
| pinchartl | sailus: https://www.spinics.net/lists/linux-renesas-soc/msg20256.html | [12:52] |
| sailus | Btw. this discussion would be better on #v4l. Just my opinion. | [12:52] |
| mchehab | moving something like that at device core makes sense | [12:52] |
| pinchartl | sailus: agreed
anyway, I'll make sure to explain the issues in the next version | [12:53] |
| mchehab | 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? | [12:55] |
| hverkuil | not from me | [12:57] |
| pinchartl | not from me either | [13:01] |
| mchehab | 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 | [13:08] |
| pinchartl | mchehab: thank you | [13:12] |
| mchehab | anytime | [13:12] |
| pinchartl | 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 | [13:12] |
| mchehab | 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 | [13:14] |
| pinchartl | no, I think it can be implemented in subsystems, but then there will be code duplication | [13:17] |
| mchehab | 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 | [13:18] |
| ........... (idle for 52mn) | ||
| 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
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() | [14:12] |
| ↑back Search ←Prev date Next date→ Show only urls | (Click on time to select a line by its url) |