The Linux Kernel Mailing List
 help / color / mirror / Atom feed
From: Greg KH <gregkh@suse.de>
To: linux-kernel@vger.kernel.org, stable@kernel.org
Cc: stable-review@kernel.org, torvalds@linux-foundation.org,
	akpm@linux-foundation.org, alan@lxorguk.ukuu.org.uk,
	Seth Barry <seth@cyberseth.com>,
	Michael Krufky <mkrufky@kernellabs.com>,
	Mauro Carvalho Chehab <mchehab@redhat.com>
Subject: [08/20] V4L/DVB (13109): tda18271: fix signedness issue in tda18271_rf_tracking_filters_init
Date: Sun, 06 Dec 2009 15:30:40 -0800	[thread overview]
Message-ID: <20091206233209.309431448@mini.kroah.org> (raw)
In-Reply-To: <20091206233711.GA11609@kroah.com>

[-- Attachment #1: v4l-dvb-13109-tda18271-fix-signedness-issue-in-tda18271_rf_tracking_filters_init.patch --]
[-- Type: text/plain, Size: 2997 bytes --]

2.6.27-stable review patch.  If anyone has any objections, please let us know.

------------------
From: Seth Barry <seth@cyberseth.com>

commit a57c1dcb93e43357ed3f666e5a2b5d5071dd3930 upstream.

While having tda18271 module set with debug=17 (cal & info prints) and
cal=0 (delay calibration process until first use) - I discovered that
during the calibration process, if the frequency test for 69750000
returned a bcal of 0 (see tda18721-fe.c in tda18271_powerscan func) that
the tuner wouldn't be able to pickup any of the frequencies in the range
(all the other frequencies bands returned bcal=1).  I spent some time
going over the code and the NXP's tda18271 spec (ver.4 of it i think) and
adding a lot of debug prints and walking/stepping through the calibration
process.  I found that when the powerscan fails to find a frequency, the
rf calibration is not run and the default value is supposed to be used in
its place (pulled from the RF_CAL_map table) - but something was getting
goofed up there.

Now, my c coding skills are very rusty, but i think root of the problem is
a signedness issue with the math operation for calculating the rf_a1 and
rf_a2 values in tda18271_rf_tracking_filters_init func, which results in
values like 20648 for rf_a1 (when it should probably have a value like 0,
or so slightly negative that it should be zero - this bad value for rf_a1
would in turn makes the approx calc within
tda18271c2_rf_tracking_filters_correction go out of whack).  The simplest
solution i found was to explicitly convert the signedness of the
denominator to avoid the implicit conversion.  The values placed into the
u32 rf_freq array should never exceed about 900mhz, so i think the s32 max
value shouldn't be an issue in this case.

I've tested it out a little, and even when i get a bcal=0 with the
modified code, the default calibration value gets used, rf_a1 is zero, and
the tuner seems to lock on the stream and mythtv seems to play it fine.

Signed-off-by: Seth Barry <seth@cyberseth.com>
Signed-off-by: Michael Krufky <mkrufky@kernellabs.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

---
 drivers/media/common/tuners/tda18271-fe.c |    4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

--- a/drivers/media/common/tuners/tda18271-fe.c
+++ b/drivers/media/common/tuners/tda18271-fe.c
@@ -595,13 +595,13 @@ static int tda18271_rf_tracking_filters_
 		case RF2:
 			map[i].rf_a1 = (prog_cal[RF2] - prog_tab[RF2] -
 					prog_cal[RF1] + prog_tab[RF1]) /
-				((rf_freq[RF2] - rf_freq[RF1]) / 1000);
+				(s32)((rf_freq[RF2] - rf_freq[RF1]) / 1000);
 			map[i].rf2   = rf_freq[RF2] / 1000;
 			break;
 		case RF3:
 			map[i].rf_a2 = (prog_cal[RF3] - prog_tab[RF3] -
 					prog_cal[RF2] + prog_tab[RF2]) /
-				((rf_freq[RF3] - rf_freq[RF2]) / 1000);
+				(s32)((rf_freq[RF3] - rf_freq[RF2]) / 1000);
 			map[i].rf_b2 = prog_cal[RF2] - prog_tab[RF2];
 			map[i].rf3   = rf_freq[RF3] / 1000;
 			break;



  parent reply	other threads:[~2009-12-06 23:41 UTC|newest]

Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <20091206233032.387950574@mini.kroah.org>
2009-12-06 23:37 ` [00/20] 2.6.27.40-stable review Greg KH
2009-12-06 23:30   ` [01/20] ALSA: AACI: fix AC97 multiple-open bug Greg KH
2009-12-06 23:30   ` [02/20] ALSA: AACI: fix recording bug Greg KH
2009-12-06 23:30   ` [03/20] ALSA: usb-audio: fix combine_word problem Greg KH
2009-12-06 23:30   ` [04/20] [SCSI] gdth: Prevent negative offsets in ioctl CVE-2009-3080 Greg KH
2009-12-06 23:30   ` [05/20] jffs2: Fix memory corruption in jffs2_read_inode_range() Greg KH
2009-12-06 23:30   ` [06/20] V4L/DVB (13079): dib0700: fixed xc2028 firmware loading kernel oops Greg KH
2009-12-06 23:30   ` [07/20] V4L/DVB (13107): tda18271: fix overflow in FM radio frequency calculation Greg KH
2009-12-06 23:30   ` Greg KH [this message]
2009-12-06 23:30   ` [09/20] V4L/DVB (13190): em28xx: fix panic that can occur when starting audio streaming Greg KH
2009-12-06 23:30   ` [10/20] V4L/DVB (13230): s2255drv: Dont conditionalize video buffer completion on waiting processes Greg KH
2009-12-06 23:30   ` [11/20] [CPUFREQ] Enable ACPI PDC handshake for VIA/Centaur CPUs Greg KH
2009-12-06 23:30   ` [12/20] fuse: reject O_DIRECT flag also in fuse_create Greg KH
2009-12-06 23:30   ` [13/20] fuse: prevent fuse_put_request on invalid pointer Greg KH
2009-12-06 23:30   ` [14/20] isdn: hfc_usb: Fix read buffer overflow Greg KH
2009-12-06 23:30   ` [15/20] thinkpad-acpi: fix sign of ERESTARTSYS return Greg KH
2009-12-06 23:30   ` [16/20] USB: ohci: quirk AMD prefetch for USB 1.1 ISO transfer Greg KH
2009-12-06 23:30   ` [17/20] USB: suspend/resume support for option driver Greg KH
2009-12-06 23:30   ` [18/20] USB: usb-serial: replace shutdown with disconnect, release Greg KH
2009-12-06 23:30   ` [19/20] dca: redesign locks to fix deadlocks Greg KH
2009-12-06 23:30   ` [20/20] hwmon: (it87) Fix VID reading on IT8718F Greg KH

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20091206233209.309431448@mini.kroah.org \
    --to=gregkh@suse.de \
    --cc=akpm@linux-foundation.org \
    --cc=alan@lxorguk.ukuu.org.uk \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mchehab@redhat.com \
    --cc=mkrufky@kernellabs.com \
    --cc=seth@cyberseth.com \
    --cc=stable-review@kernel.org \
    --cc=stable@kernel.org \
    --cc=torvalds@linux-foundation.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox