Re: udev breakages - was: Re: Need of an ".async_probe()" type of callback at driver's core - Was: Re: [PATCH] [media] drxk: change it to use request_firmware_nowait()
On 10/2/12, Linus Torvalds wrote: > On Tue, Oct 2, 2012 at 6:03 AM, Mauro Carvalho Chehab > wrote: >> >> I basically tried a few different approaches, including deferred probe(), >> as you suggested, and request_firmware_async(), as Kay suggested. > > Stop this crazy. FIX UDEV ALREADY, DAMMIT. > > Who maintains udev these days? Is it Lennart/Kai, as part of systemd? > > Lennart/Kai, fix the udev regression already. Lennart was the one who > brought up kernel ABI regressions at some conference, and if you now > you have the *gall* to break udev in an incompatible manner that > requires basically impossible kernel changes for the kernel to "fix" > the udev interface, I don't know what to say. > > "Two-faced lying weasel" would be the most polite thing I could say. > But it almost certainly will involve a lot of cursing. > >> However, for 3.7 or 3.8, I think that the better is to revert changeset >> 177bc7dade38b5 >> and to stop with udev's insanity of requiring asynchronous firmware load >> during >> device driver initialization. If udev's developers are not willing to do >> that, >> we'll likely need to add something at the drivers core to trick udev for >> it to >> think that the modules got probed before the probe actually happens. > > The fact is, udev made new - and insane - rules that are simply > *invalid*. Modern udev is broken, and needs to be fixed. > > I don't know where the problem started in udev, but the report I saw > was that udev175 was fine, and udev182 was broken, and would deadlock > if module_init() did a request_firmware(). That kind of nested > behavior is absolutely *required* to work, in order to not cause > idiotic problems for the kernel for no good reason. > > What kind of insane udev maintainership do we have? And can we fix it? > > Greg, I think you need to step up here too. You were the one who let > udev go. If the new maintainers are causing problems, they need to be > fixed some way. I'm not kernel developer and probably my opinion would be a little naive, but here it is. Please, make the kernel load firmware from the filesystem on its own. This should solve almost 99.9% of the problems related to firmware loading. I don't mind if there is still userland component that could be used to request a firmware from repository. You can even keep the udev userland piping as a fallback if you want, but I think you can simplify a lot of code if you phase it out. The firmware loading should follow the same concept as modules loading. I've heard that the udev userland piping of firmware is done to avoid some licensing issues. But honestly, if you can not store the firmware on the user's disk, no free operating system should support it at all. This piping thing have been feature creep that have metastasized all over the kernel while keeping a lot of obscure modules broken (in hard to find way) and requiring increasingly complicated schemes to workaround its flaws. KiSS. Best Regards Ivan Kalvachev -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [git:v4l-dvb/for_v3.4] [media] em28xx: support for 2304:0242 PCTV QuatroStick (510e)
On 3/20/12, Mauro Carvalho Chehab wrote: > This is an automatic generated email to let you know that the following > patch were queued at the > http://git.linuxtv.org/media_tree.git tree: > > Subject: [media] em28xx: support for 2304:0242 PCTV QuatroStick (510e) > Author: Ivan Kalvachev > Date:Mon Mar 19 20:09:55 2012 -0300 > > It is mostly copy/paste of the 520e code with setting GPIO7 removed > (no LED light). > I've worked on just released vanilla linux-3.3.0 kernel, so there may > be 1/2 lines offset to the internal working source, but most of the > code should apply cleanly. If you still haven't pushed this upstream, can you (rebase and) amend the message and remove the above paragraph. It is useless for commit message. Not a big deal if it is too late :) -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] em28xx: support for 2304:0242 PCTV QuatroStick (510e)
Hardware is based of: Empia EM2884 Micronas DRX 3926K NXP TDA18271HDC2 AVF4910 (not used atm) This model is almost identical to the PCTV 520e. There is no LED on it and the drx-k may be spin A1, A2 or A3. Signed-off-by: Ivan Kalvachev -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] em28xx: support for 2304:0242 PCTV QuatroStick (510e)
This patch should be applied after the "PATCH 2/2] em28xx: support for 2013:0251 PCTV QuatroStick nano (520e)" patchset. It is mostly copy/paste of the 520e code with setting GPIO7 removed (no LED light). I've worked on just released vanilla linux-3.3.0 kernel, so there may be 1/2 lines offset to the internal working source, but most of the code should apply cleanly. I was able to get the DVB-C working (tuned and watched TV). Haven't tested DVB-T (no signal atm). Here is a log of the `dmsg` when detecting my device. [ 1197.735520] em28xx: New device Pinnacle Systems PCTV 510e @ 480 Mbps (2304:0242, interface 0, class 0) [ 1197.735525] em28xx: Audio Vendor Class interface 0 found [ 1197.735527] em28xx: Video interface 0 found [ 1197.735530] em28xx: DVB interface 0 found [ 1197.735588] em28xx #0: chip ID is em2884 [ 1198.030970] em28xx #0: Identified as PCTV QuatroStick (510e) (card=85) [ 1198.053727] Registered IR keymap rc-pinnacle-pctv-hd [ 1198.053829] input: em28xx IR (em28xx #0) as /devices/pci:00/:00:1a.7/usb1/1-4/rc/rc0/input10 [ 1198.053933] rc0: em28xx IR (em28xx #0) as /devices/pci:00/:00:1a.7/usb1/1-4/rc/rc0 [ 1198.054591] em28xx #0: Config register raw data: 0xb7 [ 1198.054595] em28xx #0: I2S Audio (5 sample rates) [ 1198.054598] em28xx #0: No AC97 audio processor [ 1198.071627] em28xx #0: v4l2 driver version 0.1.3 [ 1198.093354] em28xx #0: V4L2 video device registered as video1 [ 1198.093382] usbcore: registered new interface driver em28xx [ 1198.097021] em28xx-audio.c: probing for em28xx Audio Vendor Class [ 1198.097026] em28xx-audio.c: Copyright (C) 2006 Markus Rechberger [ 1198.097028] em28xx-audio.c: Copyright (C) 2007-2011 Mauro Carvalho Chehab [ 1198.097721] Em28xx: Initialized (Em28xx Audio Extension) extension [ 1198.116227] drxk: status = 0x039260d9 [ 1198.116233] drxk: detected a drx-3926k, spin A1, xtal 20.250 MHz [ 1199.570712] DRXK driver version 0.9.4300 [ 1199.585694] drxk: frontend initialized. [ 1199.588100] tda18271 2-0060: creating new instance [ 1199.597682] TDA18271HD/C2 detected @ 2-0060 [ 1199.935489] DVB: registering new adapter (em28xx #0) [ 1199.935495] DVB: registering adapter 0 frontend 0 (DRXK DVB-C DVB-T)... [ 1199.936048] em28xx #0: Successfully loaded em28xx-dvb [ 1199.936054] Em28xx: Initialized (Em28xx dvb Extension) extension Special thanks to everybody who worked on the code and to Antti Palosaari and Devin Heitmueller who provided essential support on irc. Best Regards Ivan Kalvachev iive pctv510e.patch Description: Binary data
bttv/msp3400 and hibernation
I'm having analog capture card based on bt878. It works without any major problems. However there is some annoying bug with the msp3400 module (this is audio decoding chip on the card, used to decode stereo sound) when using the build-in kernel hibernation. After resume the kernel module spills some I/O Errors and no audio could be heard. The workaround is simple, remove and modprobe the bttv module. If somebody have idea how to further debug problem, please provide instructions. For now I attach full system log done by having "option bttv debug=10" and "option msp3400 debug=10" in modprobe.conf . The log is using the latest kernel-2.6.31.3, but this happens with every kernel I've tried so far. msp3400.log.gz Description: GNU Zip compressed data
