linux-kernel - Re: pvrusb2: fix 7MHz & 8MHz DVB-T tuner support for HVR1900 rev D1F5

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [thread-next>] [day] [month] [year] [list]

Date:	Mon, 27 Feb 2012 05:15:04 -0500
From:	Michael Krufky <mkrufky@...uxtv.org>
To:	Mauro Carvalho Chehab <mchehab@...hat.com>
Cc:	Mike Isely <isely@...ox.com>,
	linux-media <linux-media@...r.kernel.org>,
	Communications nexus for pvrusb2 driver <pvrusb2@...ly.net>,
	stable@...nel.org, LKML <linux-kernel@...r.kernel.org>
Subject: Re: pvrusb2: fix 7MHz & 8MHz DVB-T tuner support for HVR1900 rev D1F5

On Fri, Feb 24, 2012 at 2:27 PM, Mauro Carvalho Chehab
<mchehab@...hat.com> wrote:
> Em 07-02-2012 15:08, Michael Krufky escreveu:
>> There are some new revisions of the HVR-1900 around whose DVB-T
>> support is broken without this small bug-fix.  Please merge asap -
>> this fix needs to go to stable kernels as well.  It applies cleanly
>> against *all* recent kernels.
>>
>> The following changes since commit 805a6af8dba5dfdd35ec35dc52ec0122400b2610:
>>
>>   Linux 3.2 (2012-01-04 15:55:44 -0800)
>>
>> are available in the git repository at:
>>   git://linuxtv.org/mkrufky/hauppauge surrey
>>
>> Michael Krufky (1):
>>       pvrusb2: fix 7MHz & 8MHz DVB-T tuner support for HVR1900 rev D1F5
>>
>>  drivers/media/video/pvrusb2/pvrusb2-devattr.c |   10 ++++++++++
>>  1 files changed, 10 insertions(+), 0 deletions(-)
>
>> The D1F5 revision of the WinTV HVR-1900 uses a tda18271c2 tuner
>> instead of a tda18271c1 tuner as used in revision D1E9. To
>> account for this, we must hardcode the frontend configuration
>> to use the same IF frequency configuration for both revisions
>> of the device.
>
> No, you don't need to hardcode the IF. Just use the get_if_frequency
> callback at the demod, and it will work with whatever frequency you
> use at the tuner.
>
> Regards,
> Mauro

(apologies for delayed reply - I am travelling in Europe this month
and not checking all my email every day)

Mauro,

get_if_frequency will work, but for *optimal* settings for the
hardware that my company manufactures, this is it.  The hardcoded IF
is the correct setting for *this* hardware.  There are more factors
than just a tuner and demodulator, here.  I know the board layout and
the crystal configurations, and we did extensive testing.  Sure, you
can use get_if_frequency and it will "work" ... but when I have
information about how it will work *best* then you should merge my
patch.

This is the fix.  You can merge it or you will not merge it.  I did my
part, Mauro.  My customers need this fix and I will not argue.

ALSO, for -stable, there is no get_if_frequency.  I cannot have the
patch merged into stable unless you merge it into mainline. There is
no time for opinion - only facts.  Please merge.

-MK
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/