Re: [PATCH 00/18] prevent bounds-check bypass via speculative execution
On Tue, 9 Jan 2018, Josh Poimboeuf wrote: > On Tue, Jan 09, 2018 at 11:44:05AM -0800, Dan Williams wrote: > > On Tue, Jan 9, 2018 at 11:34 AM, Jiri Kosina <ji...@kernel.org> wrote: > > > On Fri, 5 Jan 2018, Dan Williams wrote: > > > > > > [ ... snip ... ] > > >> Andi Kleen (1): > > >> x86, barrier: stop speculation for failed access_ok > > >> > > >> Dan Williams (13): > > >> x86: implement nospec_barrier() > > >> [media] uvcvideo: prevent bounds-check bypass via speculative > > >> execution > > >> carl9170: prevent bounds-check bypass via speculative execution > > >> p54: prevent bounds-check bypass via speculative execution > > >> qla2xxx: prevent bounds-check bypass via speculative execution > > >> cw1200: prevent bounds-check bypass via speculative execution > > >> Thermal/int340x: prevent bounds-check bypass via speculative > > >> execution > > >> ipv6: prevent bounds-check bypass via speculative execution > > >> ipv4: prevent bounds-check bypass via speculative execution > > >> vfs, fdtable: prevent bounds-check bypass via speculative execution > > >> net: mpls: prevent bounds-check bypass via speculative execution > > >> udf: prevent bounds-check bypass via speculative execution > > >> userns: prevent bounds-check bypass via speculative execution > > >> > > >> Mark Rutland (4): > > >> asm-generic/barrier: add generic nospec helpers > > >> Documentation: document nospec helpers > > >> arm64: implement nospec_ptr() > > >> arm: implement nospec_ptr() > > > > > > So considering the recent publication of [1], how come we all of a sudden > > > don't need the barriers in ___bpf_prog_run(), namely for LD_IMM_DW and > > > LDX_MEM_##SIZEOP, and something comparable for eBPF JIT? > > > > > > Is this going to be handled in eBPF in some other way? > > > > > > Without that in place, and considering Jann Horn's paper, it would seem > > > like PTI doesn't really lock it down fully, right? > > > > Here is the latest (v3) bpf fix: > > > > https://patchwork.ozlabs.org/patch/856645/ > > > > I currently have v2 on my 'nospec' branch and will move that to v3 for > > the next update, unless it goes upstream before then. Daniel, I guess you're planning to send this still for 4.15? > That patch seems specific to CONFIG_BPF_SYSCALL. Is the bpf() syscall > the only attack vector? Or are there other ways to run bpf programs > that we should be worried about? Seems like Alexei is probably the only person in the whole universe who isn't CCed here ... let's fix that. Thanks, -- Jiri Kosina SUSE Labs
Re: [PATCH 00/18] prevent bounds-check bypass via speculative execution
On Fri, 5 Jan 2018, Dan Williams wrote: [ ... snip ... ] > Andi Kleen (1): > x86, barrier: stop speculation for failed access_ok > > Dan Williams (13): > x86: implement nospec_barrier() > [media] uvcvideo: prevent bounds-check bypass via speculative execution > carl9170: prevent bounds-check bypass via speculative execution > p54: prevent bounds-check bypass via speculative execution > qla2xxx: prevent bounds-check bypass via speculative execution > cw1200: prevent bounds-check bypass via speculative execution > Thermal/int340x: prevent bounds-check bypass via speculative execution > ipv6: prevent bounds-check bypass via speculative execution > ipv4: prevent bounds-check bypass via speculative execution > vfs, fdtable: prevent bounds-check bypass via speculative execution > net: mpls: prevent bounds-check bypass via speculative execution > udf: prevent bounds-check bypass via speculative execution > userns: prevent bounds-check bypass via speculative execution > > Mark Rutland (4): > asm-generic/barrier: add generic nospec helpers > Documentation: document nospec helpers > arm64: implement nospec_ptr() > arm: implement nospec_ptr() So considering the recent publication of [1], how come we all of a sudden don't need the barriers in ___bpf_prog_run(), namely for LD_IMM_DW and LDX_MEM_##SIZEOP, and something comparable for eBPF JIT? Is this going to be handled in eBPF in some other way? Without that in place, and considering Jann Horn's paper, it would seem like PTI doesn't really lock it down fully, right? [1] https://bugs.chromium.org/p/project-zero/issues/attachmentText?aid=287305 -- Jiri Kosina SUSE Labs
Re: Problem with VMAP_STACK=y
On Thu, 6 Oct 2016, Mauro Carvalho Chehab wrote: > I can't see any other obvious error on the conversion. You could try to > enable debug options at DVB core/dvb-usb and/or add some printk's to the > driver and see what's happening. Mauro, also please don't forget that there are many more places in drivers/media that still perform DMA on stack, and so have to be fixed for 4.9 (as VMAP_STACK makes that to be immediately visible problem even on x86_64, which it wasn't the case before). Thanks, -- Jiri Kosina SUSE Labs -- 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: Problem with VMAP_STACK=y
On Wed, 5 Oct 2016, Patrick Boettcher wrote: > > > Thanks for the quick response. > > > Drivers are: > > > dvb_core, dvb_usb, dbv_usb_cynergyT2 > > > > This dbv_usb_cynergyT2 is not from Linus' tree, is it? I don't seem > > to be able to find it, and the only google hit I am getting is your > > very mail to LKML :) > > It's a typo, it should say dvb_usb_cinergyT2. Ah, thanks. Same issues there in cinergyt2_frontend_attach() cinergyt2_rc_query() I think this would require more in-depth review of all the media drivers and having all this fixed for 4.9. It should be pretty straightforward; all the instances I've seen so far should be just straightforward conversion to kmalloc() + kfree(), as the buffer is not being embedded in any structure etc. -- Jiri Kosina SUSE Labs -- 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: Problem with VMAP_STACK=y
On Tue, 4 Oct 2016, Jörg Otte wrote: > Thanks for the quick response. > Drivers are: > dvb_core, dvb_usb, dbv_usb_cynergyT2 This dbv_usb_cynergyT2 is not from Linus' tree, is it? I don't seem to be able to find it, and the only google hit I am getting is your very mail to LKML :) -- Jiri Kosina SUSE Labs -- 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: Problem with VMAP_STACK=y
On Tue, 4 Oct 2016, Jörg Otte wrote: > With kernel 4.8.0-01558-g21f54dd I get thousands of > "dvb-usb: bulk message failed: -11 (1/0)" > messages in the logs and the DVB adapter is not working. > > It tourned out the new config option VMAP_STACK=y (which is the default) > is the culprit. > No problems for me with VMAP_STACK=n. I'd guess that this is EAGAIN coming from usb_hcd_map_urb_for_dma() as the DVB driver is trying to perform on-stack DMA. Not really knowing which driver exactly you're using, I quickly skimmed through DVB sources, and it turns out this indeed seems to be rather common antipattern, and it should be fixed nevertheless. See cxusb_ctrl_msg() dibusb_power_ctrl() dibusb2_0_streaming_ctrl() dibusb2_0_power_ctrl() digitv_ctrl_msg() dtt200u_fe_init() dtt200u_fe_set_frontend() dtt200u_power_ctrl() dtt200u_streaming_ctrl() dtt200u_pid_filter() Adding relevant CCs. -- Jiri Kosina SUSE Labs -- 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 07/12] trivial: [media] cx25821: cx25821-medusa-reg.h: fix 0x0x prefix
On Tue, 28 Apr 2015, Antonio Ospite wrote: Fix the 0x0x prefix in integer constants. In this case a padding 0 must also be inserted to make the constants look like all the other 16 bits ones. Signed-off-by: Antonio Ospite a...@ao2.it Cc: Mauro Carvalho Chehab mche...@osg.samsung.com Cc: linux-media@vger.kernel.org Doesn't seem to be in linux-next as of today. I am picking it up. --- drivers/media/pci/cx25821/cx25821-medusa-reg.h | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/drivers/media/pci/cx25821/cx25821-medusa-reg.h b/drivers/media/pci/cx25821/cx25821-medusa-reg.h index c98ac94..2e10643 100644 --- a/drivers/media/pci/cx25821/cx25821-medusa-reg.h +++ b/drivers/media/pci/cx25821/cx25821-medusa-reg.h @@ -84,9 +84,9 @@ #define ABIST_BIN4_VGA3 0x01D4 #define ABIST_BIN5_VGA4 0x01D8 #define ABIST_BIN6_VGA5 0x01DC -#define ABIST_BIN7_VGA6 0x0x1E0 -#define ABIST_CLAMP_A 0x0x1E4 -#define ABIST_CLAMP_B 0x0x1E8 +#define ABIST_BIN7_VGA6 0x01E0 +#define ABIST_CLAMP_A 0x01E4 +#define ABIST_CLAMP_B 0x01E8 #define ABIST_CLAMP_C 0x01EC #define ABIST_CLAMP_D 0x01F0 #define ABIST_CLAMP_E 0x01F4 -- 2.1.4 -- Jiri Kosina SUSE Labs -- 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 v2] radio-bcm2048.c: fix wrong overflow check
On Fri, 9 May 2014, Pali Rohár wrote: Seems like it's not in linux-next as of today, so I am taking it now. Thanks, I still do not see this patch in torvalds branch... So what is needed to include this security buffer overflow patch into mainline stable kernels? I picked it up 4 days ago into trivial.git, which is a tree that doesn't get pushed to Linus really super-often. Of course, if, in the meantime, this goes in through maintainer tree, even better. -- Jiri Kosina SUSE Labs -- 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 v2] radio-bcm2048.c: fix wrong overflow check
On Tue, 22 Apr 2014, Dan Carpenter wrote: From: Pali Rohár pali.ro...@gmail.com This patch fixes an off by one check in bcm2048_set_region(). Reported-by: Dan Carpenter dan.carpen...@oracle.com Signed-off-by: Pali Rohár pali.ro...@gmail.com Signed-off-by: Pavel Machek pa...@ucw.cz Signed-off-by: Dan Carpenter dan.carpen...@oracle.com --- v2: Send it to the correct list. Re-work the changelog. This patch has been floating around for four months but Pavel and Pali are knuckle-heads and don't know how to use get_maintainer.pl so they never send it to linux-media. Also Pali doesn't give reporter credit and Pavel steals authorship credit. Also when you try explain to them about how to send patches correctly they complain that they have been trying but it is too much work so now I have to do it. During the past four months thousands of other people have been able to send patches in the correct format to the correct list but it is too difficult for Pavel and Pali... *sigh*. Seems like it's not in linux-next as of today, so I am taking it now. Thanks, -- Jiri Kosina SUSE Labs -- 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 4/6] si4713 : HID blacklist Si4713 USB development board
On Fri, 30 Aug 2013, Dinesh Ram wrote:
The Si4713 development board contains a Si4713 FM transmitter chip
and is handled by the radio-usb-si4713 driver.
The board reports itself as (10c4:8244) Cygnal Integrated Products, Inc.
and misidentifies itself as a HID device in its USB interface descriptor.
This patch ignores this device as an HID device and hence loads the custom
driver.
Signed-off-by: Dinesh Ram din...@cisco.com
Cc: Jiri Kosina jkos...@suse.cz
Cc: linux-in...@vger.kernel.org
---
drivers/hid/hid-core.c | 1 +
drivers/hid/hid-ids.h | 2 ++
2 files changed, 3 insertions(+)
diff --git a/drivers/hid/hid-core.c b/drivers/hid/hid-core.c
index 36668d1..109510f 100644
--- a/drivers/hid/hid-core.c
+++ b/drivers/hid/hid-core.c
@@ -1977,6 +1977,7 @@ static const struct hid_device_id hid_ignore_list[] = {
{ HID_USB_DEVICE(USB_VENDOR_ID_BERKSHIRE, USB_DEVICE_ID_BERKSHIRE_PCWD)
},
{ HID_USB_DEVICE(USB_VENDOR_ID_CIDC, 0x0103) },
{ HID_USB_DEVICE(USB_VENDOR_ID_CYGNAL,
USB_DEVICE_ID_CYGNAL_RADIO_SI470X) },
+ { HID_USB_DEVICE(USB_VENDOR_ID_CYGNAL,
USB_DEVICE_ID_CYGNAL_RADIO_SI4713) },
{ HID_USB_DEVICE(USB_VENDOR_ID_CMEDIA, USB_DEVICE_ID_CM109) },
{ HID_USB_DEVICE(USB_VENDOR_ID_CYPRESS, USB_DEVICE_ID_CYPRESS_HIDCOM) },
{ HID_USB_DEVICE(USB_VENDOR_ID_CYPRESS,
USB_DEVICE_ID_CYPRESS_ULTRAMOUSE) },
diff --git a/drivers/hid/hid-ids.h b/drivers/hid/hid-ids.h
index ffe4c7a..2a38726 100644
--- a/drivers/hid/hid-ids.h
+++ b/drivers/hid/hid-ids.h
@@ -241,6 +241,8 @@
#define USB_VENDOR_ID_CYGNAL 0x10c4
#define USB_DEVICE_ID_CYGNAL_RADIO_SI470X0x818a
+#define USB_DEVICE_ID_CYGNAL_RADIO_SI4713 0x8244
+
#define USB_VENDOR_ID_CYPRESS0x04b4
#define USB_DEVICE_ID_CYPRESS_MOUSE 0x0001
#define USB_DEVICE_ID_CYPRESS_HIDCOM 0x5500
Acked-by: Jiri Kosina jkos...@suse.cz
(under the assumption that this goes in together with the custom driver).
--
Jiri Kosina
SUSE Labs
--
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 4/6] si4713 : HID blacklist Si4713 USB development board
On Fri, 30 Aug 2013, Dinesh Ram wrote: The Si4713 development board contains a Si4713 FM transmitter chip and is handled by the radio-usb-si4713 driver. The board reports itself as (10c4:8244) Cygnal Integrated Products, Inc. and misidentifies itself as a HID device in its USB interface descriptor. This patch ignores this device as an HID device and hence loads the custom driver. Signed-off-by: Dinesh Ram din...@cisco.com Signed-off-by: Jiri Kosina jkos...@suse.cz Please feel free to take it together with my sigoff with the rest of the series. -- Jiri Kosina SUSE Labs -- 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 02/03 v2] usb hid quirks for Masterkit MA901 usb radio
On Fri, 29 Mar 2013, Mauro Carvalho Chehab wrote: Yes, i just checked how hid_ignore() works and prepared dirty fix to test in almost the same way like it's done for Keene usb driver. I will send correct fix in next few days. Any news on this, please? Hi Jiri, I'm very very sorry (was busy because of life). I just sent two patches to you, Mauro and two mail lists: [patch 1/2] hid: fix Masterkit MA901 hid quirks [patch 2/2] media: radio-ma901: return ENODEV in probe if usb_device doesn't match Please check. First one for hid layer, so maybe you can take it directly through your tree. I hope it's not too late. I think Mauro will take second patch. It is better to add both patches via the same tree. As it is badly affecting HID, it seems better if Jiri can apply both patches. Also, there's no other patch for radio-ma901 on my tree. So, I don't expect any conflicts if those patches got merged via hid tree. Jiri, could you please apply both patches on your tree? For both: [patch 1/2] hid: fix Masterkit MA901 hid quirks [patch 2/2] media: radio-ma901: return ENODEV in probe if usb_device Acked-by: Mauro Carvalho Chehab mche...@redhat.com Absolutely. Will add your Ack and push it to Linus for 3.9 still. Thanks, -- Jiri Kosina SUSE Labs -- 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: Fw: [patch 02/03 v2] usb hid quirks for Masterkit MA901 usb radio
On Tue, 19 Mar 2013, Alexey Klimov wrote: Yes, i just checked how hid_ignore() works and prepared dirty fix to test in almost the same way like it's done for Keene usb driver. I will send correct fix in next few days. Any news on this, please? -- Jiri Kosina SUSE Labs -- 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] documentation: DocBook/media : Fix typo in dvbproperty.xml
On Sun, 24 Mar 2013, Masanari Iida wrote: Correct spelling typos. Signed-off-by: Masanari Iida standby2...@gmail.com I can take this one. Thanks. -- Jiri Kosina SUSE Labs -- 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: Fw: [patch 02/03 v2] usb hid quirks for Masterkit MA901 usb radio
On Tue, 19 Mar 2013, Alexey Klimov wrote: Or Mauro, as the original patch went in through your tree, are you handling that? I think we really need to revert it before final release. It's already -rc3. If Mauro is currently too busy to handle this, I will take it. Please send it to me together with the appropriate hid_ignore() patch. Thanks, -- Jiri Kosina SUSE Labs -- 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: Fw: [patch 02/03 v2] usb hid quirks for Masterkit MA901 usb radio
On Fri, 15 Mar 2013, Alexey Klimov wrote: indeed your patch breaks Atmega applications which using V-USB (http://www.obdev.at/products/vusb/index.html), because 0x16c0, 0x05df are the default Ids of V-USB. Have a look at this FAQ https://github.com/obdev/v-usb/blob/master/usbdrv/USB-ID-FAQ.txt It seems that the Masterkit M901 also uses V-USB. I'm using an IR remote control receiver based on Atmega8 with V-USB. Since Kernel 3.8.2 there is no more hidraw device for my receiver, so I had to change the Device-ID to 0x27d9. I think there are a lot of other V-USB applications with similar problems. Dirk Exactly. That's why i tried to point it out. Thanks for explaining this in simplier words. It's difficult to answer on top posting emails. I don't understand one thing about your letter. Did you put linux-media kernel list in bcc (hide copy)? Is there any reason for this? http://www.mail-archive.com/linux-media@vger.kernel.org/msg59714.html Mauro, Jiri, can we revert this patch? If you need any ack or sign from me i'm ready to send it. I can contact people who cares about stable trees and ask them to revert this patch from stable trees. During 3.9-rcX cycle i can try to figure out some fix or additional checks for radio-ma901.c driver. I can revert 0322bd3980 and push it out to Linus for 3.9 still, Ccing stable. Or Mauro, as the original patch went in through your tree, are you handling that? Also additional work will be needed later to properly detect the underlying device ... the best thing to do here is to put an entry into hid_ignore(), similar to what we do for example for Keene FM vs. Logitech AudioHub. -- Jiri Kosina SUSE Labs -- 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: Fw: [patch 02/03 v2] usb hid quirks for Masterkit MA901 usb radio
On Fri, 28 Dec 2012, Mauro Carvalho Chehab wrote: Hi Jiri, There's another radio device that it is incorrectly detected as an HID driver. As I'll be applying the driver's patch via the media tree, do you mind if I also apply this hid patch there? Hi Mauro, please feel free to add Acked-by: Jiri Kosina jkos...@suse.cz and take the patch through your tree. Thanks, -- Jiri Kosina SUSE Labs -- 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] [media] fix tua6034 pll bandwich configuration [3rd and last attempt]
On Mon, 10 Dec 2012, Arne Fitzenreiter wrote:
i have already send this patch twice and the mailing list but get no response.
(Three weeks delay between the mails).
Why mail mails are ignored?
I have no idea, but I'd like to have this taken through media tree rather
than trivial.
Adding Mauro to CC.
The tua6034 pll is corrupted by commit [media] dvb-pll: use DVBv5 parameters
on set_params()
http://git.linuxtv.org/media_tree.git/commit/80d8d4985f280dca3c395286d13b49f910a029e7
[SNIP]
/* Infineon TUA6034
* used in LG TDTP E102P
*/
-static void tua6034_bw(struct dvb_frontend *fe, u8 *buf,
- const struct dvb_frontend_parameters *params)
+static void tua6034_bw(struct dvb_frontend *fe, u8 *buf)
{
- if (BANDWIDTH_7_MHZ != params-u.ofdm.bandwidth)
+ u32 bw = fe-dtv_property_cache.bandwidth_hz;
+ if (bw == 700)
buf[3] |= 0x08;
}
[/SNIP]
so here is a patch to fix this typo to get the Skymaster DTMU100 (HANFTEK
UMT010 OEM BOX)
working again.
Arne
Resolves-bug: https://bugzilla.kernel.org/show_bug.cgi?id=51011
diff -Naur linux-3.7-rc7-org/drivers/media/dvb-frontends/dvb-pll.c
linux-3.7-rc7/drivers/media/dvb-frontends/dvb-pll.c
--- linux-3.7-rc7-org/drivers/media/dvb-frontends/dvb-pll.c 2012-11-26
02:59:19.0 +0100
+++ linux-3.7-rc7/drivers/media/dvb-frontends/dvb-pll.c 2012-11-27
09:45:16.736775252 +0100
@@ -247,7 +247,7 @@
static void tua6034_bw(struct dvb_frontend *fe, u8 *buf)
{
u32 bw = fe-dtv_property_cache.bandwidth_hz;
- if (bw == 700)
+ if (bw != 700)
buf[3] |= 0x08;
}
--
Jiri Kosina
SUSE Labs
--
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: 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 Tue, 2 Oct 2012, Linus Torvalds wrote: Now, at the same time, I do agree that network devices should generally try to delay it until ifup time Slightly tangential to the ongoing discussion, but still ... I think that even all network drivers should delay firmware loading to ifup time might be too general. I would expect that there are network cards which require firmware to be present for PHY to work, right? On such cards, if you want to have link detection even on interfaces that are down (so that things like ifplugd can detect the link presence and configure the interface), ifup is too late. I admit I haven't checked whether there actually are such cards out there, but it doesn't seem to be completely unrealistic to me. -- Jiri Kosina SUSE Labs -- 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: 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 Tue, 2 Oct 2012, Linus Torvalds wrote: And see this email from Kay Sievers that shows that it was all known about and intentional in the udev camp: http://www.spinics.net/lists/netdev/msg185742.html This seems confusing indeed. That e-mail referenced above is talking about loading firmware at ifup time. While that might work for network device drivers (I am not sure even about that), what are the udev maintainers advice for other drivers, where there is no analogy to ifup? -- Jiri Kosina SUSE Labs -- 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 0/6] HID: picoLCD additional fixes + CIR support
On Sun, 19 Aug 2012, Bruno Prémont wrote: This series fixes some race conditions in picoLCD driver during remove() and adds support for IR functionality. I have now applied the series, thanks Bruno. -- Jiri Kosina SUSE Labs -- 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] tda8261: add printk levels
From: Alan Cox a...@linux.intel.com
This is done as a minimal printk updating patch to ensure correctness. Yes
it should all one day use dev_foo(), but that's one for the maintainers.
Resolves-bug: https://bugzilla.kernel.org/show_bug.cgi?id=32932
Signed-off-by: Alan Cox a...@linux.intel.com
Signed-off-by: Jiri Kosina jkos...@suse.cz
---
The file has been moved in -next, so to avoid unnecessary conflicts, I am
passing this one over from trivial tree to media maintainers.
Thanks.
drivers/media/dvb-frontends/tda8261.c | 28 ++--
1 files changed, 14 insertions(+), 14 deletions(-)
diff --git a/drivers/media/dvb-frontends/tda8261.c
b/drivers/media/dvb-frontends/tda8261.c
index 53c7d8f..19c4888 100644
--- a/drivers/media/dvb-frontends/tda8261.c
+++ b/drivers/media/dvb-frontends/tda8261.c
@@ -43,7 +43,7 @@ static int tda8261_read(struct tda8261_state *state, u8 *buf)
struct i2c_msg msg = { .addr= config-addr, .flags = I2C_M_RD,.buf
= buf, .len = 1 };
if ((err = i2c_transfer(state-i2c, msg, 1)) != 1)
- printk(%s: read error, err=%d\n, __func__, err);
+ pr_err(%s: read error, err=%d\n, __func__, err);
return err;
}
@@ -55,7 +55,7 @@ static int tda8261_write(struct tda8261_state *state, u8 *buf)
struct i2c_msg msg = { .addr = config-addr, .flags = 0, .buf = buf,
.len = 4 };
if ((err = i2c_transfer(state-i2c, msg, 1)) != 1)
- printk(%s: write error, err=%d\n, __func__, err);
+ pr_err(%s: write error, err=%d\n, __func__, err);
return err;
}
@@ -69,11 +69,11 @@ static int tda8261_get_status(struct dvb_frontend *fe, u32
*status)
*status = 0;
if ((err = tda8261_read(state, result)) 0) {
- printk(%s: I/O Error\n, __func__);
+ pr_err(%s: I/O Error\n, __func__);
return err;
}
if ((result 6) 0x01) {
- printk(%s: Tuner Phase Locked\n, __func__);
+ pr_debug(%s: Tuner Phase Locked\n, __func__);
*status = 1;
}
@@ -98,7 +98,7 @@ static int tda8261_get_state(struct dvb_frontend *fe,
tstate-bandwidth = 4000; /* FIXME! need to calculate
Bandwidth */
break;
default:
- printk(%s: Unknown parameter (param=%d)\n, __func__, param);
+ pr_err(%s: Unknown parameter (param=%d)\n, __func__, param);
err = -EINVAL;
break;
}
@@ -124,11 +124,11 @@ static int tda8261_set_state(struct dvb_frontend *fe,
*/
frequency = tstate-frequency;
if ((frequency 95) || (frequency 215)) {
- printk(%s: Frequency beyond limits, frequency=%d\n,
__func__, frequency);
+ pr_warn(%s: Frequency beyond limits, frequency=%d\n,
__func__, frequency);
return -EINVAL;
}
N = (frequency + (div_tab[config-step_size] - 1)) /
div_tab[config-step_size];
- printk(%s: Step size=%d, Divider=%d, PG=0x%02x (%d)\n,
+ pr_debug(%s: Step size=%d, Divider=%d, PG=0x%02x (%d)\n,
__func__, config-step_size,
div_tab[config-step_size], N, N);
buf[0] = (N 8) 0xff;
@@ -144,25 +144,25 @@ static int tda8261_set_state(struct dvb_frontend *fe,
/* Set params */
if ((err = tda8261_write(state, buf)) 0) {
- printk(%s: I/O Error\n, __func__);
+ pr_err(%s: I/O Error\n, __func__);
return err;
}
/* sleep for some time */
- printk(%s: Waiting to Phase LOCK\n, __func__);
+ pr_debug(%s: Waiting to Phase LOCK\n, __func__);
msleep(20);
/* check status */
if ((err = tda8261_get_status(fe, status)) 0) {
- printk(%s: I/O Error\n, __func__);
+ pr_err(%s: I/O Error\n, __func__);
return err;
}
if (status == 1) {
- printk(%s: Tuner Phase locked: status=%d\n, __func__,
status);
+ pr_debug(%s: Tuner Phase locked: status=%d\n,
__func__, status);
state-frequency = frequency; /* cache successful state
*/
} else {
- printk(%s: No Phase lock: status=%d\n, __func__,
status);
+ pr_debug(%s: No Phase lock: status=%d\n, __func__,
status);
}
} else {
- printk(%s: Unknown parameter (param=%d)\n, __func__, param);
+ pr_err(%s: Unknown parameter (param=%d)\n, __func__, param);
return -EINVAL;
}
@@ -214,7 +214,7 @@ struct dvb_frontend *tda8261_attach(struct dvb_frontend *fe,
// printk(%s
Re: [PATCH][Trivial][resend] Documentation: Add newline at end-of-file to files lacking one
On Fri, 20 Jul 2012, Jesper Juhl wrote: This patch simply adds a newline character at end-of-file to those files in Documentation/ that currently lack one. This is done for a few different reasons: A) It's rather annoying when you do cat some_file.txt that your prompt/cursor ends up at the end of the last line of output rather than on a new line. B) Some tools that process files line-by-line may get confused by the lack of a newline on the last line. C) The \ No newline at end of file line in diffs annoys me for some reason. So, let's just add the missing newline once and for all. Signed-off-by: Jesper Juhl j...@chaosbits.net Queued for 3.6, thanks Jesper. -- Jiri Kosina SUSE Labs -- 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 V2]NEXT:drivers:staging:media Fix comments and some typos in staging/media/*
On Fri, 16 Mar 2012, Justin P. Mattock wrote: before I forget about this patch, what was the status of this one? As previously announced multiple times, I am ignoring patches that go to drivers/staging and letting Greg pick them up if he wants to. Greg, if you want to have this changed, just let me know. -- Jiri Kosina SUSE Labs -- 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: Two devices, same USB ID: one needs HID, the other doesn't. How to solve this?
On Fri, 13 Jan 2012, Hans Verkuil wrote: [RFC PATCH] hid-core: ignore the Keene FM transmitter. The Keene FM transmitter USB device has the same USB ID as the Logitech AudioHub Speaker, but it should ignore the hid. Check if the name is that of the Keene device. Signed-off-by: Hans Verkuil hans.verk...@cisco.com --- drivers/hid/hid-core.c | 10 ++ drivers/hid/hid-ids.h |1 + 2 files changed, 11 insertions(+), 0 deletions(-) diff --git a/drivers/hid/hid-core.c b/drivers/hid/hid-core.c index af35384..f02d197 100644 --- a/drivers/hid/hid-core.c +++ b/drivers/hid/hid-core.c @@ -1973,6 +1973,16 @@ static bool hid_ignore(struct hid_device *hdev) if (hdev-product = USB_DEVICE_ID_LOGITECH_HARMONY_FIRST hdev-product = USB_DEVICE_ID_LOGITECH_HARMONY_LAST) return true; + /* + * The Keene FM transmitter USB device has the same USB ID as + * the Logitech AudioHub Speaker, but it should ignore the hid. + * Check if the name is that of the Keene device. + * For reference: the name of the AudioHub is + * HOLTEK AudioHub Speaker. + */ + if (hdev-product == USB_DEVICE_ID_LOGITECH_AUDIOHUB + !strcmp(hdev-name, HOLTEK B-LINK USB Audio )) + return true; break; case USB_VENDOR_ID_SOUNDGRAPH: if (hdev-product = USB_DEVICE_ID_SOUNDGRAPH_IMON_FIRST diff --git a/drivers/hid/hid-ids.h b/drivers/hid/hid-ids.h index 4a441a6..2f6dc92 100644 --- a/drivers/hid/hid-ids.h +++ b/drivers/hid/hid-ids.h @@ -440,6 +440,7 @@ #define USB_DEVICE_ID_LG_MULTITOUCH 0x0064 #define USB_VENDOR_ID_LOGITECH 0x046d +#define USB_DEVICE_ID_LOGITECH_AUDIOHUB 0x0a0e #define USB_DEVICE_ID_LOGITECH_RECEIVER 0xc101 #define USB_DEVICE_ID_LOGITECH_HARMONY_FIRST 0xc110 #define USB_DEVICE_ID_LOGITECH_HARMONY_LAST 0xc14f -- 1.7.7.3 Comments? Or even better, an Acked-by? I'd like to get this driver in for v3.4, that would be nice. This is fine and I will Ack/take it once it goes in with your driver for the device. -- Jiri Kosina SUSE Labs -- 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 6/6] hid-core: ignore the Keene FM transmitter.
On Thu, 2 Feb 2012, Hans Verkuil wrote: From: Hans Verkuil hans.verk...@cisco.com The Keene FM transmitter USB device has the same USB ID as the Logitech AudioHub Speaker, but it should ignore the hid. Check if the name is that of the Keene device. Signed-off-by: Hans Verkuil hans.verk...@cisco.com Mauro, feel free to take this one with the rest of the patchset with my Signed-off-by: Jiri Kosina jkos...@suse.cz Thanks, -- Jiri Kosina SUSE Labs -- 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: [3.1-rc9] kernel tried to execute NX-protected... w/ page fault
in: it87 hwmon_vid coretemp xt_time xt_connlimit xt_realm xt_addrtype iptable_raw xt_comment xt_policy ipt_ULOG ipt_REJECT ipt_REDIRECT ipt_NETMAP ipt_MASQUERADE ipt_LOG ipt_ECN ipt_ecn ipt_ah nf_nat_tftp nf_nat_sip nf_nat_pptp nf_nat_proto_gre nf_nat_irc nf_nat_h323 nf_nat_ftp nf_nat_amanda ts_kmp nf_conntrack_amanda nf_conntrack_sane nf_conntrack_tftp nf_conntrack_sip nf_conntrack_proto_sctp nf_conntrack_pptp nf_conntrack_proto_gre nf_conntrack_netlink nf_conntrack_netbios_ns nf_conntrack_broadcast nf_conntrack_irc nf_conntrack_h323 nf_conntrack_ftp xt_tcpmss xt_recent xt_pkttype xt_owner xt_NFQUEUE xt_NFLOG nfnetlink_log xt_multiport xt_mark xt_mac xt_limit xt_length xt_iprange xt_helper xt_hashlimit xt_DSCP xt_dscp xt_dccp xt_conntrack xt_connmark xt_CLASSIFY xt_tcpudp xt_state iptable_nat nf_nat nf_conntrack_ipv4 nf_defrag_ipv4 nf_conntrack iptable_mangle nfnetlink iptable_filter ip_tables x_tables snd_pcm_oss snd_mixer_oss xts gf128mul us bl p snd_hda_codec_hdmi isl6421 cx24116 cx88_vp3054_i2c videobuf_dvb dvb_core snd_hda_codec_realtek rc_hauppauge ir_lirc_codec lirc_dev tuner snd_hda_intel ir_mce_kbd_decoder ir_sony_decoder ir_jvc_decoder cx8802 snd_virtuoso ir_rc6_decoder nouveau snd_hda_codec cx8800 ir_rc5_decoder snd_oxygen_lib cx88xx ir_nec_decoder snd_hwdep rc_core ttm snd_pcm tveeprom snd_timer v4l2_common videodev fbcon font bitblit softcursor drm_kms_helper drm snd_mpu401_uart fb fbdev snd_rawmidi i2c_algo_bit snd cfbcopyarea v4l2_compat_ioctl32 btcx_risc videobuf_dma_sg mxm_wmi cfbimgblt snd_page_alloc wmi videobuf_core joydev xpad cfbfillrect evdev soundcore fuse ext2 mbcache dm_snapshot dm_mirror dm_region_hash dm_log scsi_wait_scan usb_storage [ 234.518053] Pid: 21406, comm: knotify4 Tainted: P3.1.0-rc9 #2 [ 234.518054] Call Trace: [ 234.518060] [8103c03a] warn_slowpath_common+0x7a/0xb0 [ 234.518064] [810b3e28] ? __do_fault+0x1d8/0x4d0 [ 234.518067] [8103c085] warn_slowpath_null+0x15/0x20 [ 234.518070] [810a1a23] __alloc_pages_nodemask+0x163/0x710 [ 234.518073] [810b652c] ? handle_pte_fault+0x7c/0x7a0 [ 234.518083] [a01915d0] ? v4l_printk_ioctl+0x80/0x80 [videodev] [ 234.518087] [810e58d5] ? release_open_intent+0x35/0x40 [ 234.518090] [810b7ea5] ? handle_mm_fault+0x165/0x300 [ 234.518093] [810a1fe2] __get_free_pages+0x12/0x40 [ 234.518096] [810ce336] __kmalloc+0x136/0x150 [ 234.518102] [a00bd181] usblp_write+0x1d1/0x310 [usblp] [ 234.518107] [a01901eb] v4l2_release+0x4b/0x70 [videodev] [ 234.518111] [810d81e2] fput+0xd2/0x200 [ 234.518114] [810d4a21] filp_close+0x61/0x90 [ 234.518117] [810d4b01] sys_close+0xb1/0x110 [ 234.518121] [813df03b] system_call_fastpath+0x16/0x1b [ 234.518130] ---[ end trace 6fb2e5d4254083e3 ]--- So long, matthias. -- Jiri Kosina SUSE Labs -- 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][Resend] viacam: Don't explode if pci_find_bus() returns NULL
On Mon, 1 Aug 2011, Jesper Juhl wrote: In the unlikely case that pci_find_bus() should return NULL viacam_serial_is_enabled() is going to dereference a NULL pointer and blow up. Better safe than sorry, so be defensive and check the pointer. Signed-off-by: Jesper Juhl j...@chaosbits.net Acked-by: Jonathan Corbet cor...@lwn.net --- drivers/media/video/via-camera.c |2 ++ 1 files changed, 2 insertions(+), 0 deletions(-) diff --git a/drivers/media/video/via-camera.c b/drivers/media/video/via-camera.c index 85d3048..bb7f17f 100644 --- a/drivers/media/video/via-camera.c +++ b/drivers/media/video/via-camera.c @@ -1332,6 +1332,8 @@ static __devinit bool viacam_serial_is_enabled(void) struct pci_bus *pbus = pci_find_bus(0, 0); u8 cbyte; + if (!pbus) + return false; pci_bus_read_config_byte(pbus, VIACAM_SERIAL_DEVFN, VIACAM_SERIAL_CREG, cbyte); if ((cbyte VIACAM_SERIAL_BIT) == 0) Applied, thanks. -- Jiri Kosina SUSE Labs -- 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 0/6] get rid of on-stack dma buffers
On Mon, 21 Mar 2011, Florian Mickler wrote: To be blunt, I'm not shure I fully understand the requirements myself. But as far as I grasped it, the main problem is that we need memory which the processor can see as soon as the device has scribbled upon it. (think caches and the like) Somewhere down the line, the buffer to usb_control_msg get's to be a parameter to dma_map_single which is described as part of the DMA API in Documentation/DMA-API.txt The main point I filter out from that is that the memory has to begin exactly at a cache line boundary... I guess (not verified), that the dma api takes sufficient precautions to abort the dma transfer if a timeout happens. So freeing _should_ not be an issue. (At least, I would expect big fat warnings everywhere if that were the case) I cc'd some people that hopefully will correct me if I'm wrong... It all boils down to making sure that you don't free the memory which is used as target of DMA transfer. This is very likely to hit you when DMA memory region is on stack, but blindly just converting this to kmalloc()/kfree() isn't any better if you don't make sure that all the DMA transfers have been finished and device will not be making any more to that particular memory region. -- Jiri Kosina SUSE Labs, Novell Inc. -- 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] Input: switch completely over to the new versions of get/setkeycode
On Mon, 31 Jan 2011, Mauro Carvalho Chehab wrote: Input: switch completely over to the new versions of get/setkeycode All users of old style get/setkeycode methids have been converted so it is time to retire them. Signed-off-by: Dmitry Torokhov d...@mail.ru --- Jiri, Mauro, There is not a good way to avoid crossing multiple subsystems but the changes are minimal, so if you are OK with the patch I'd like to move it through my tree for .39. Acked-by: Mauro Carvalho Chehab mche...@redhat.com Acked-by: Jiri Kosina jkos...@suse.cz Thanks Dmitry. -- Jiri Kosina SUSE Labs, Novell Inc. -- 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 14/15]include:media:davinci:vpss.h Typo change diable to disable.
On Fri, 31 Dec 2010, Mauro Carvalho Chehab wrote: Em 30-12-2010 21:08, Justin P. Mattock escreveu: The below patch fixes a typo diable to disable. Please let me know if this is correct or not. Signed-off-by: Justin P. Mattock justinmatt...@gmail.com Acked-by: Mauro Carvalho Chehab mche...@redhat.com Applied. PS.: Next time, please c/c linux-media ONLY on patches related to media drivers (/drivers/video and the corresponding include files). Having to dig into a series of 15 patches to just actually look on 3 patches is not nice. Absolutely. Justin, no kernel developer should be afraid of being CCed. But try to avoid really unnecessary spamming (which this was). -- Jiri Kosina SUSE Labs, Novell Inc. -- 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 11/15]drivers:media:video:cx18:cx23418.h Typo change diable to disable.
On Fri, 31 Dec 2010, Mauro Carvalho Chehab wrote: Em 30-12-2010 21:08, Justin P. Mattock escreveu: The below patch fixes a typo diable to disable. Please let me know if this is correct or not. Signed-off-by: Justin P. Mattock justinmatt...@gmail.com Acked-by: Mauro Carvalho Chehab mche...@redhat.com Folded all three 'media' fixes into one and applied with your Ack. Thanks. -- Jiri Kosina SUSE Labs, Novell Inc. -- 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 07/15]drivers:net:wireless:iwlwifi Typo change diable to disable.
On Fri, 31 Dec 2010, Larry Finger wrote: On 12/30/2010 05:07 PM, Justin P. Mattock wrote: The below patch fixes a typo diable to disable. Please let me know if this is correct or not. Signed-off-by: Justin P. Mattock justinmatt...@gmail.com ACKed-by: Larry Finger larry.fin...@lwfinger.net Applied, thanks. -- Jiri Kosina SUSE Labs, Novell Inc. -- 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 08/15]drivers:scsi:lpfc:lpfc_init.c Typo change diable to disable.
On Thu, 30 Dec 2010, Justin P. Mattock wrote: The below patch fixes a typo diable to disable. Please let me know if this is correct or not. Signed-off-by: Justin P. Mattock justinmatt...@gmail.com Folded patched 8, 9, 10 and 13 together and applied. -- Jiri Kosina SUSE Labs, Novell Inc. -- 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: [Ksummit-2010-discuss] [v2] Remaining BKL users, what to do
On Tue, 19 Oct 2010, Greg KH wrote: So no need to clean it up for multiprocessor support. http://download.intel.com/design/chipsets/datashts/29067602.pdf http://www.intel.com/design/chipsets/specupdt/29069403.pdf Great, we can just drop all calls to lock_kernel() and the like in the driver and be done with it, right? No, you still need to switch off preemption. Hm, how would you do that from within a driver? preempt_disable() -- Jiri Kosina SUSE Labs, Novell Inc. -- 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 0/6] Large scancode handling
On Wed, 8 Sep 2010, Jarod Wilson wrote: It'll conflict a little bith with the tivo slide patch I posted yesterday, but mostly just minor context changes. I can redo that patch on top of these changes if that's preferred. I can handle those context changes when merging the patches at linux-next and when merging upstream. We just need to sync in a way that Dmitry send his patch series before mine when sending them to Linus, and I'll take care of fixing the merge conflicts. Ah, the specific conflicts I was referring here are confined to drivers/hid/hid-input.c, and I sent the patch thinking it would go in via the hid tree. It *is* for a remote, but its a pure HID device in this case. Umm, what patch are you talking about please? I don't seem to have anything from you in my queue. Gah. I suck. Forgot to cc you on it. http://www.spinics.net/lists/linux-input/msg11007.html Can resend and/or bounce you a copy if need be. No need to resend, I'll dig it out from linux-input@ archives where I have overlooked it and will start a discussion in that thread if needed, so that we don't pollute this one. Thanks, -- Jiri Kosina SUSE Labs, Novell Inc. -- 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 0/6] Large scancode handling
On Wed, 8 Sep 2010, Dmitry Torokhov wrote: Hi Mauro, I guess I better get off my behind and commit the changes to support large scancodes, or they will not make to 2.6.37 either... There isn't much changes, except I followed David's suggestion and changed boolean index field into u8 flags field. Still, please glance it over once again and shout if you see something you do not like. Jiri, how do you want to handle the changes to HID? I could either push them through my tree together with the first patch or you can push through yours once the first change hits mainline. I think that there will unlikely be any conflict in .37 merge window in this area (and if there were, I'll sort it out). So please add Acked-by: Jiri Kosina jkos...@suse.cz to the hid-input.c bits and feel free to take it through your tree, if it is convenient for you. Thanks, -- Jiri Kosina SUSE Labs, Novell Inc. -- 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] V4L/DVB: remove unneeded null check in anysee_probe()
On Mon, 31 May 2010, Dan Carpenter wrote: Smatch complained because d is dereferenced first and then checked for null later . The only code path where d could be a invalid pointer is if this is a cold device in dvb_usb_device_init(). I consulted Antti Palosaari and he explained that anysee is always a warm device. I have added a comment and removed the unneeded null check. Signed-off-by: Dan Carpenter erro...@gmail.com diff --git a/drivers/media/dvb/dvb-usb/anysee.c b/drivers/media/dvb/dvb-usb/anysee.c index faca1ad..aa5c7d5 100644 --- a/drivers/media/dvb/dvb-usb/anysee.c +++ b/drivers/media/dvb/dvb-usb/anysee.c @@ -463,6 +463,11 @@ static int anysee_probe(struct usb_interface *intf, if (intf-num_altsetting 1) return -ENODEV; + /* + * Anysee is always warm (its USB-bridge, Cypress FX2, uploads + * firmware from eeprom). If dvb_usb_device_init() succeeds that + * means d is a valid pointer. + */ ret = dvb_usb_device_init(intf, anysee_properties, THIS_MODULE, d, adapter_nr); if (ret) @@ -479,10 +484,7 @@ static int anysee_probe(struct usb_interface *intf, if (ret) return ret; - if (d) - ret = anysee_init(d); - - return ret; + return anysee_init(d); Doesn't seem to be present in linux-next as of today. Mauro, will you take it? Or I can take it if you ack it. Thanks, -- Jiri Kosina SUSE Labs, Novell Inc. -- 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: dvb-usb-remote woes [was: HID: ignore afatech 9016]
On Fri, 5 Feb 2010, Pekka Sarnila wrote: Can't be HID bus with a specific driver used instead now? Well it could, but this way it is much less work and more generic. I use many different joysticks, yokes and pedals. And with some generic modifications and improvements into generic HID layer and generic input layer all worked well. Only joystick layer got to be completely rewritten. I did never put this upstream because by the time I got my own patches integrated to the (new) kernel, the hid/input layer had developed so much that the patches could no more be used in the latest kernel. So I hand applied them again, and again kernel had moved on, and so on. Also to argue for patches that cover several areas and several maintainers is difficult, and changing a lot at once is always risky. So I gave up. If anyone is interested, I could take a look again and see if the changes could be argued and applied incrementally instead of one big bunch. Hi Pekka, yes, we are definitely interested (or at least I am). The major rewrite of the HID core to be full-fledged bus was done exactly so that it's easier to add support for new devices, while keeping the main code clean. Even if you have problems porting the drivers to new infrastructure, you can always post wha you have -- I believe that we will be able to sort it out quickly. Thanks, -- Jiri Kosina SUSE Labs, Novell Inc. -- 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 1/1] media: dvb-usb/af9015, fix disconnection crashes
On Thu, 4 Feb 2010, Pekka Sarnila wrote: The FULLSPEED thing is really not ir receiver specific problem. It can happen with any device with interrupt endpoint. That's the reason why I placed the quirk to HID driver. However even the HID driver is logically a wrong place. Really it should belong to the usb/endpoint layer because this really is not HID specific problem but usb layer problem (as also Jiri Kosina then pointed out). However linux usb layer has been build so that it was technically impossible to put it there without completely redesigning usb - higher layer (including HID) interface. But I'm of the opinion that that redesign should be done anyway. Even when no quirk is needed interrupt endpoint handling is a usb level task not a hid level (or any other higher level) task. The usb layer should do the interrupt endpoint polling and just put up interrupt events to higher layers. Partly this confusion is due the poor usb/hid specifications. It really should be a device/endpoint-quirk. Yes, I still think what I have stated before, that this should be properly handled in the USB stack. On the other hand, in usbhid driver we do a lot of USB-specific lower-level things anyway, so it's technically more-or-less OK to apply the quirk there as well (and that's why I have accepted it back then). -- Jiri Kosina SUSE Labs, Novell Inc. -- 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 1/1] HID: ignore afatech 9016
[ Adding Pekka (the author of the patch that added this quirk for AF9016) to
CC ... ]
On Wed, 13 Jan 2010, Jiri Slaby wrote:
Let's ignore the device altogether by HID layer. It's handled by
dvb-usb-remote driver properly already.
By now, FULLSPEED_INTERVAL quirk was used. It probably made things
better, but the remote ctrl was still a perfect X killer. This was
the last user of the particular quirk. So remove the quirk as well.
With input going through dvb-usb-remote, the remote works
perfectly.
Signed-off-by: Jiri Slaby jsl...@suse.cz
Cc: Jiri Kosina jkos...@suse.cz
---
drivers/hid/usbhid/hid-core.c |8
drivers/hid/usbhid/hid-quirks.c |2 +-
include/linux/hid.h |1 -
3 files changed, 1 insertions(+), 10 deletions(-)
diff --git a/drivers/hid/usbhid/hid-core.c b/drivers/hid/usbhid/hid-core.c
index e2997a8..36a1561 100644
--- a/drivers/hid/usbhid/hid-core.c
+++ b/drivers/hid/usbhid/hid-core.c
@@ -938,14 +938,6 @@ static int usbhid_start(struct hid_device *hid)
interval = endpoint-bInterval;
- /* Some vendors give fullspeed interval on highspeed devides */
- if (hid-quirks HID_QUIRK_FULLSPEED_INTERVAL
- dev-speed == USB_SPEED_HIGH) {
- interval = fls(endpoint-bInterval*8);
- printk(KERN_INFO %s: Fixing fullspeed to highspeed
interval: %d - %d\n,
-hid-name, endpoint-bInterval, interval);
- }
-
/* Change the polling interval of mice. */
if (hid-collection-usage == HID_GD_MOUSE
hid_mousepoll_interval 0)
interval = hid_mousepoll_interval;
diff --git a/drivers/hid/usbhid/hid-quirks.c b/drivers/hid/usbhid/hid-quirks.c
index 38773dc..788d9a3 100644
--- a/drivers/hid/usbhid/hid-quirks.c
+++ b/drivers/hid/usbhid/hid-quirks.c
@@ -41,7 +41,7 @@ static const struct hid_blacklist {
{ USB_VENDOR_ID_SAITEK, USB_DEVICE_ID_SAITEK_RUMBLEPAD,
HID_QUIRK_BADPAD },
{ USB_VENDOR_ID_TOPMAX, USB_DEVICE_ID_TOPMAX_COBRAPAD, HID_QUIRK_BADPAD
},
- { USB_VENDOR_ID_AFATECH, USB_DEVICE_ID_AFATECH_AF9016,
HID_QUIRK_FULLSPEED_INTERVAL },
+ { USB_VENDOR_ID_AFATECH, USB_DEVICE_ID_AFATECH_AF9016, HID_QUIRK_IGNORE
},
Hmm, why do we keep HID_QUIRK_IGNORE anyway, when we already have generic
hid_ignore_list[]?
We don't set it for any device in the current codebase any more.
Thanks,x
--
Jiri Kosina
SUSE Labs, Novell Inc.
--
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 1/1] HID: ignore afatech 9016
On Wed, 13 Jan 2010, Jiri Slaby wrote:
--- a/drivers/hid/usbhid/hid-quirks.c
+++ b/drivers/hid/usbhid/hid-quirks.c
@@ -41,7 +41,7 @@ static const struct hid_blacklist {
{ USB_VENDOR_ID_SAITEK, USB_DEVICE_ID_SAITEK_RUMBLEPAD,
HID_QUIRK_BADPAD },
{ USB_VENDOR_ID_TOPMAX, USB_DEVICE_ID_TOPMAX_COBRAPAD, HID_QUIRK_BADPAD
},
- { USB_VENDOR_ID_AFATECH, USB_DEVICE_ID_AFATECH_AF9016,
HID_QUIRK_FULLSPEED_INTERVAL },
+ { USB_VENDOR_ID_AFATECH, USB_DEVICE_ID_AFATECH_AF9016, HID_QUIRK_IGNORE
},
Hmm, why do we keep HID_QUIRK_IGNORE anyway, when we already have generic
hid_ignore_list[]?
You returned it back because of dynamic quirks...
Right you are.
We don't set it for any device in the current codebase any more.
Oh yeah, it's hard for people who don't remember code they wrote :).
Oh, right ... happened to me as well, see a few lines above :)
Will respin. Thanks for the reminder.
Thanks,
--
Jiri Kosina
SUSE Labs, Novell Inc.
--
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 10/10] media/dvb: add __init/__exit macros to drivers/media/dvb/bt8xx/bt878.c
On Tue, 5 Jan 2010, Jean Delvare wrote: Trivial patch which adds the __init/__exit macros to the module_init/ module_exit functions of drivers/media/dvb/bt8xx/bt878.c Please have a look at the small patch and either pull it through your tree, or please ack' it so Jiri can pull it through the trivial tree. Patch against linux-next-tree, 22. Dez 08:38:18 CET 2009 but also present in linus tree. Signed-off-by: Peter Huewe peterhu...@gmx.de Acked-by: Jean Delvare kh...@linux-fr.org Applied, thanks. -- Jiri Kosina SUSE Labs, Novell Inc. -- 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] media/video: adding __init/__exit macros to various drivers
On Tue, 29 Sep 2009, Peter Huewe wrote: From: Peter Huewe peterhu...@gmx.de Trivial patch which adds the __init/__exit macros to the module_init/ module_exit functions of the following drivers in media video: drivers/media/video/ivtv/ivtv-driver.c drivers/media/video/cx18/cx18-driver.c drivers/media/video/davinci/dm355_ccdc.c drivers/media/video/davinci/dm644x_ccdc.c drivers/media/video/saa7164/saa7164-core.c drivers/media/video/saa7134/saa7134-core.c drivers/media/video/cx23885/cx23885-core.c This doesn't seem to be present in linux-next as of today. I have queued in in trivial tree. -- Jiri Kosina SUSE Labs, Novell Inc. -- 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: [BUG] radio-gemtek-pci.c: double mutex_lock
On Thu, 8 Oct 2009, Alexander Strakh wrote:
KERNEL_VERSION: 2.6.31
DESCRIBE:
In driver ./drivers/media/radio/radio-gemtek-pci.c
mutex_lock is called first time in line 184, then in line 186
gemtek_pci_setfrequency is called.
182 static void gemtek_pci_unmute(struct gemtek_pci *card)
183 {
184 mutex_lock(card-lock);
185 if (card-mute) {
186 gemtek_pci_setfrequency(card, card-current_frequency);
187 card-mute = false;
188 }
189 mutex_unlock(card-lock);190 }
In gemtek_pci_setfrequency we call mutex_lock again in line 152
144 static void gemtek_pci_setfrequency(struct gemtek_pci *card, unsigned
long
frequency)
145 {
146 int i;
147 u32 value = frequency / 200 + 856;
148 u16 mask = 0x8000;
149 u8 last_byte;
150 u32 port = card-iobase;
151
152 mutex_lock(card-lock);
Good catch. Adding Hans, who added the (incorrect) locking into
gemtek_pci_unmute(), to CC.
--
Jiri Kosina
SUSE Labs, Novell Inc.
--
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] media/video/cx88: adding __init/__exit macros to cx88 drivers
On Wed, 22 Jul 2009, Peter Hüwe wrote: Trivial patch which adds the __init and __exit macros to the module_init / module_exit functions to several files in drivers/media/video/cx88/ linux version 2.6.31-rc3 - linus git tree Signed-off-by: Peter Huewe peterhu...@gmx.de any updates on this patch? If my minor fixes bug you too much please give me a hint how I can improve my patches. Well the minor issue is that when you send trivial patches to triv...@kernel.org and also to all the involved maintainers, I am waiting for them to apply them into their trees and only if this doesn't happen after some time (I check regularly, but not very frequently), I apply to trivial queue. Thanks, -- Jiri Kosina SUSE Labs
Re: [PATCH] media/video/cx88: adding __init/__exit macros to cx88 drivers
On Wed, 22 Jul 2009, Mauro Carvalho Chehab wrote: Trivial patch which adds the __init and __exit macros to the module_init / module_exit functions to several files in drivers/media/video/cx88/ linux version 2.6.31-rc3 - linus git tree Signed-off-by: Peter Huewe peterhu...@gmx.de any updates on this patch? Acked-by: Mauro Carvalho Chehab mche...@redhat.com Thanks a lot Mauro, I have queued the patch in trivial tree. -- Jiri Kosina SUSE Labs -- 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] DAB: fix typo
On Tue, 17 Feb 2009, Mauro Carvalho Chehab wrote: From: Márton Németh nm...@freemail.hu Fix typo in DAB adapters section in Kconfig. Signed-off-by: Márton Németh nm...@freemail.hu --- --- linux-2.6.29-rc3/drivers/media/Kconfig.orig 2008-12-25 00:26:37.0 +0100 +++ linux-2.6.29-rc3/drivers/media/Kconfig2009-02-01 13:30:54.0 +0100 @@ -117,7 +117,7 @@ source drivers/media/dvb/Kconfig config DAB boolean DAB adapters ---help--- - Allow selecting support for for Digital Audio Broadcasting (DAB) + Allow selecting support for Digital Audio Broadcasting (DAB) Receiver adapters. Didn't find this in today's linux-next, so I have applied it to trivial tree. I was just applying it on my tree right now. Anyway, it is OK for me if you apply it at trivial. No problem, if you take it through your tree I am fine with that, it will be easier that way to avoid conflicts in -next. I am dropping the patch from trivial tree. Thanks, -- Jiri Kosina SUSE Labs
Re: [PATCH] DAB: fix typo
On Sun, 1 Feb 2009, Németh Márton wrote: From: Márton Németh nm...@freemail.hu Fix typo in DAB adapters section in Kconfig. Signed-off-by: Márton Németh nm...@freemail.hu --- --- linux-2.6.29-rc3/drivers/media/Kconfig.orig 2008-12-25 00:26:37.0 +0100 +++ linux-2.6.29-rc3/drivers/media/Kconfig2009-02-01 13:30:54.0 +0100 @@ -117,7 +117,7 @@ source drivers/media/dvb/Kconfig config DAB boolean DAB adapters ---help--- - Allow selecting support for for Digital Audio Broadcasting (DAB) + Allow selecting support for Digital Audio Broadcasting (DAB) Receiver adapters. Didn't find this in today's linux-next, so I have applied it to trivial tree. Thanks, -- Jiri Kosina SUSE Labs
