Message ID | 20120816080932.GP21274@login.drsnuggles.stderr.nl (mailing list archive) |
---|---|
State | RFC, archived |
Headers |
Received: from mail.tu-berlin.de ([130.149.7.33]) by www.linuxtv.org with esmtp (Exim 4.72) (envelope-from <linux-media-owner@vger.kernel.org>) id 1T1v9T-0000KE-UY for patchwork@linuxtv.org; Thu, 16 Aug 2012 10:09:59 +0200 X-tubIT-Incoming-IP: 209.132.180.67 Received: from vger.kernel.org ([209.132.180.67]) by mail.tu-berlin.de (exim-4.75/mailfrontend-4) with esmtp for <patchwork@linuxtv.org> id 1T1v9T-0000ju-Af; Thu, 16 Aug 2012 10:09:59 +0200 Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1756116Ab2HPIJw (ORCPT <rfc822;patchwork@linuxtv.org>); Thu, 16 Aug 2012 04:09:52 -0400 Received: from drsnuggles.stderr.nl ([94.142.244.14]:36603 "EHLO drsnuggles.stderr.nl" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1755894Ab2HPIJn (ORCPT <rfc822;linux-media@vger.kernel.org>); Thu, 16 Aug 2012 04:09:43 -0400 Received: from login.drsnuggles.stderr.nl ([10.42.0.9] ident=mail) by mail.drsnuggles.stderr.nl with smtp (Exim 4.69) (envelope-from <matthijs@stdin.nl>) id 1T1v92-0005UK-OP; Thu, 16 Aug 2012 10:09:33 +0200 Received: (nullmailer pid 21098 invoked by uid 1000); Thu, 16 Aug 2012 08:09:32 -0000 Date: Thu, 16 Aug 2012 10:09:32 +0200 From: Matthijs Kooijman <matthijs@stdin.nl> To: linux-media@vger.kernel.org Cc: Luis Henriques <luis.henriques@canonical.com>, Jarod Wilson <jarod@redhat.com> Subject: Re: (still) NULL pointer crashes with nuvoton_cir driver Message-ID: <20120816080932.GP21274@login.drsnuggles.stderr.nl> Mail-Followup-To: Matthijs Kooijman <matthijs@stdin.nl>, linux-media@vger.kernel.org, Luis Henriques <luis.henriques@canonical.com>, Jarod Wilson <jarod@redhat.com> References: <20120815165153.GJ21274@login.drsnuggles.stderr.nl> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="Kqu4dxz3gYjPH61T" Content-Disposition: inline In-Reply-To: <20120815165153.GJ21274@login.drsnuggles.stderr.nl> X-PGP-Fingerprint: 7F6A 9F44 2820 18E2 18DE 24AA CF49 D0E6 8A2F AFBC X-PGP-Key: http://www.stderr.nl/static/files/gpg_pubkey.asc User-Agent: Mutt/1.5.18 (2008-05-17) X-Spam-Score: -2.6 (--) X-Spam-Report: Spamchecked on "mail.drsnuggles.stderr.nl" pts rule name description ---- ---------------------- ------------------------------------------- -2.6 BAYES_00 BODY: Bayesian spam probability is 0 to 1% [score: 0.0000] Sender: linux-media-owner@vger.kernel.org Precedence: bulk List-ID: <linux-media.vger.kernel.org> X-Mailing-List: linux-media@vger.kernel.org X-PMX-Version: 5.6.1.2065439, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2012.8.16.75718 X-PMX-Spam: Gauge=IIIIIIIII, Probability=9%, Report=' MULTIPLE_RCPTS 0.1, HTML_00_01 0.05, HTML_00_10 0.05, MSGID_ADDED_BY_MTA 0.05, BODYTEXTP_SIZE_3000_LESS 0, BODY_SIZE_1700_1799 0, BODY_SIZE_2000_LESS 0, BODY_SIZE_5000_LESS 0, BODY_SIZE_7000_LESS 0, URI_ENDS_IN_HTML 0, __ANY_URI 0, __BOUNCE_CHALLENGE_SUBJ 0, __BOUNCE_NDR_SUBJ_EXEMPT 0, __CD 0, __CP_URI_IN_BODY 0, __CT 0, __CTYPE_HAS_BOUNDARY 0, __CTYPE_MULTIPART 0, __HAS_FROM 0, __HAS_MSGID 0, __HAS_X_MAILING_LIST 0, __MIME_VERSION 0, __MULTIPLE_RCPTS_CC_X2 0, __SANE_MSGID 0, __SUBJ_ALPHA_END 0, __TO_MALFORMED_2 0, __TO_NO_NAME 0, __URI_NO_WWW 0, __URI_NS , __USER_AGENT 0' |
Commit Message
Matthijs Kooijman
Aug. 16, 2012, 8:09 a.m. UTC
Hi folks, > I'm currently compiling a 3.5 kernel with just the rdev initialization > moved up to see if this will fix my problem at all, but I'd like your > view on this in the meantime as well. Ok, this seems to fix my problem: I'm still not sure if the rc_register_device shouldn't also be moved up. It seems this doesn't trigger a problem right now, but if there is a problem, I suspect its trigger window is a lot smaller than with the rdev initialization problem... Gr. Matthijs
Comments
(Adding Mauro to CC has he is the maintainer) On Thu, Aug 16, 2012 at 10:09:32AM +0200, Matthijs Kooijman wrote: > Hi folks, > > > I'm currently compiling a 3.5 kernel with just the rdev initialization > > moved up to see if this will fix my problem at all, but I'd like your > > view on this in the meantime as well. > Ok, this seems to fix my problem: > > --- a/drivers/media/rc/nuvoton-cir.c > +++ b/drivers/media/rc/nuvoton-cir.c > @@ -1066,6 +1066,7 @@ > /* tx bits */ > rdev->tx_resolution = XYZ; > #endif > + nvt->rdev = rdev; This makes sense to me. Note however that there are more drivers with a similar problem (e.g., fintek-cir.c). > > ret = -EBUSY; /* now claim resources */ @@ -1090,7 +1091,6 > @@ goto failure5; > > device_init_wakeup(&pdev->dev, true); > - nvt->rdev = rdev; > nvt_pr(KERN_NOTICE, "driver has been successfully loaded\n"); > if (debug) { > cir_dump_regs(nvt); > > > I'm still not sure if the rc_register_device shouldn't also be moved up. It > seems this doesn't trigger a problem right now, but if there is a problem, I > suspect its trigger window is a lot smaller than with the rdev initialization > problem... I'm not sure as well, I'm not very familiar with this code. However, it looks like the IRQ request should actually be one of the last things to do here. Cheers, -- Luis -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Em 17-08-2012 12:04, Luis Henriques escreveu: > (Adding Mauro to CC has he is the maintainer) I'm actually waiting for Jarod's comments on it, as he wrote this driver and the similar ones. Jarod? Regards, Mauro > > On Thu, Aug 16, 2012 at 10:09:32AM +0200, Matthijs Kooijman wrote: >> Hi folks, >> >>> I'm currently compiling a 3.5 kernel with just the rdev initialization >>> moved up to see if this will fix my problem at all, but I'd like your >>> view on this in the meantime as well. >> Ok, this seems to fix my problem: >> >> --- a/drivers/media/rc/nuvoton-cir.c >> +++ b/drivers/media/rc/nuvoton-cir.c >> @@ -1066,6 +1066,7 @@ >> /* tx bits */ >> rdev->tx_resolution = XYZ; >> #endif >> + nvt->rdev = rdev; > > This makes sense to me. Note however that there are more drivers with > a similar problem (e.g., fintek-cir.c). > >> >> ret = -EBUSY; /* now claim resources */ @@ -1090,7 +1091,6 >> @@ goto failure5; >> >> device_init_wakeup(&pdev->dev, true); >> - nvt->rdev = rdev; >> nvt_pr(KERN_NOTICE, "driver has been successfully loaded\n"); >> if (debug) { >> cir_dump_regs(nvt); >> >> >> I'm still not sure if the rc_register_device shouldn't also be moved up. It >> seems this doesn't trigger a problem right now, but if there is a problem, I >> suspect its trigger window is a lot smaller than with the rdev initialization >> problem... > > I'm not sure as well, I'm not very familiar with this code. However, > it looks like the IRQ request should actually be one of the last > things to do here. > > Cheers, > -- > Luis > -- > To unsubscribe from this list: send the line "unsubscribe linux-media" in > the body of a message to majordomo@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html > -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
--- a/drivers/media/rc/nuvoton-cir.c +++ b/drivers/media/rc/nuvoton-cir.c @@ -1066,6 +1066,7 @@ /* tx bits */ rdev->tx_resolution = XYZ; #endif + nvt->rdev = rdev; ret = -EBUSY; /* now claim resources */ @@ -1090,7 +1091,6 @@ goto failure5; device_init_wakeup(&pdev->dev, true); - nvt->rdev = rdev; nvt_pr(KERN_NOTICE, "driver has been successfully loaded\n"); if (debug) { cir_dump_regs(nvt);