---

yaml --- r: 12009 b: refs/heads/master c: 4887c61 h: refs/heads/master i: 12007: 44a50fa v: v3
git-mirror · Jul 13, 2005 · 30601ef · 30601ef
1 parent d723952
commit 30601ef
Show file tree

Hide file tree

Showing 439 changed files with 37,798 additions and 31,698 deletions.
diff --git a/[refs] b/[refs]
@@ -1,2 +1,2 @@
 ---
-refs/heads/master: c27510c031cae15f84b90f28d6dc02c314d84cf8
+refs/heads/master: 4887c61811c2283162684d7f9075b7676ef6a9bf
diff --git a/trunk/Documentation/acpi-hotkey.txt b/trunk/Documentation/acpi-hotkey.txt
@@ -0,0 +1,35 @@
+driver/acpi/hotkey.c implement:
+1. /proc/acpi/hotkey/event_config 
+(event based hotkey or event config interface):
+a. add a  event based hotkey(event) : 
+echo "0:bus::action:method:num:num" > event_config
+
+b. delete a event based hotkey(event): 
+echo "1:::::num:num" > event_config
+
+c.  modify a event based hotkey(event):    
+echo "2:bus::action:method:num:num" > event_config
+
+2. /proc/acpi/hotkey/poll_config 
+(polling based hotkey or event config interface):
+a.add a polling based hotkey(event) : 	
+echo "0:bus:method:action:method:num" > poll_config
+this adding command will create a proc file 
+/proc/acpi/hotkey/method, which is used to get 
+result of polling.
+
+b.delete a polling based hotkey(event): 	
+echo "1:::::num" > event_config
+
+c.modify a polling based hotkey(event):    
+echo "2:bus:method:action:method:num" > poll_config
+
+3./proc/acpi/hotkey/action 
+(interface to call aml method associated with a 
+specific hotkey(event))
+echo "event_num:event_type:event_argument" > 
+	/proc/acpi/hotkey/action.
+The result of the execution of this aml method is 
+attached to /proc/acpi/hotkey/poll_method, which is dnyamically
+created.  Please use command "cat /proc/acpi/hotkey/polling_method" 
+to retrieve it.
diff --git a/trunk/Documentation/filesystems/inotify.txt b/trunk/Documentation/filesystems/inotify.txt
@@ -0,0 +1,138 @@
+				    inotify
+	     a powerful yet simple file change notification system
+
+
+
+Document started 15 Mar 2005 by Robert Love <rml@novell.com>
+
+(i) User Interface
+
+Inotify is controlled by a set of three sys calls 
+
+First step in using inotify is to initialise an inotify instance
+
+	int fd = inotify_init ();
+
+Change events are managed by "watches".  A watch is an (object,mask) pair where
+the object is a file or directory and the mask is a bit mask of one or more
+inotify events that the application wishes to receive.  See <linux/inotify.h>
+for valid events.  A watch is referenced by a watch descriptor, or wd.
+
+Watches are added via a path to the file.
+
+Watches on a directory will return events on any files inside of the directory.
+
+Adding a watch is simple,
+
+	int wd = inotify_add_watch (fd, path, mask);
+
+You can add a large number of files via something like
+
+	for each file to watch {
+		int wd = inotify_add_watch (fd, file, mask);
+	}
+
+You can update an existing watch in the same manner, by passing in a new mask.
+
+An existing watch is removed via the INOTIFY_IGNORE ioctl, for example
+
+	inotify_rm_watch (fd, wd);
+
+Events are provided in the form of an inotify_event structure that is read(2)
+from a inotify instance fd.  The filename is of dynamic length and follows the 
+struct. It is of size len.  The filename is padded with null bytes to ensure 
+proper alignment.  This padding is reflected in len.
+
+You can slurp multiple events by passing a large buffer, for example
+
+	size_t len = read (fd, buf, BUF_LEN);
+
+Will return as many events as are available and fit in BUF_LEN.
+
+each inotify instance fd is also select()- and poll()-able.
+
+You can find the size of the current event queue via the FIONREAD ioctl.
+
+All watches are destroyed and cleaned up on close.
+
+
+(ii) Internal Kernel Implementation
+
+Each open inotify instance is associated with an inotify_device structure.
+
+Each watch is associated with an inotify_watch structure.  Watches are chained
+off of each associated device and each associated inode.
+
+See fs/inotify.c for the locking and lifetime rules.
+
+
+(iii) Rationale
+
+Q: What is the design decision behind not tying the watch to the open fd of
+   the watched object?
+
+A: Watches are associated with an open inotify device, not an open file.
+   This solves the primary problem with dnotify: keeping the file open pins
+   the file and thus, worse, pins the mount.  Dnotify is therefore infeasible
+   for use on a desktop system with removable media as the media cannot be
+   unmounted.
+
+Q: What is the design decision behind using an-fd-per-device as opposed to
+   an fd-per-watch?
+
+A: An fd-per-watch quickly consumes more file descriptors than are allowed,
+   more fd's than are feasible to manage, and more fd's than are optimally
+   select()-able.  Yes, root can bump the per-process fd limit and yes, users
+   can use epoll, but requiring both is a silly and extraneous requirement.
+   A watch consumes less memory than an open file, separating the number
+   spaces is thus sensible.  The current design is what user-space developers
+   want: Users initialize inotify, once, and add n watches, requiring but one fd
+   and no twiddling with fd limits.  Initializing an inotify instance two
+   thousand times is silly.  If we can implement user-space's preferences 
+   cleanly--and we can, the idr layer makes stuff like this trivial--then we 
+   should.
+
+   There are other good arguments.  With a single fd, there is a single
+   item to block on, which is mapped to a single queue of events.  The single
+   fd returns all watch events and also any potential out-of-band data.  If
+   every fd was a separate watch,
+
+   - There would be no way to get event ordering.  Events on file foo and
+     file bar would pop poll() on both fd's, but there would be no way to tell
+     which happened first.  A single queue trivially gives you ordering.  Such
+     ordering is crucial to existing applications such as Beagle.  Imagine
+     "mv a b ; mv b a" events without ordering.
+
+   - We'd have to maintain n fd's and n internal queues with state,
+     versus just one.  It is a lot messier in the kernel.  A single, linear
+     queue is the data structure that makes sense.
+
+   - User-space developers prefer the current API.  The Beagle guys, for
+     example, love it.  Trust me, I asked.  It is not a surprise: Who'd want
+     to manage and block on 1000 fd's via select?
+
+   - You'd have to manage the fd's, as an example: Call close() when you
+     received a delete event.
+
+   - No way to get out of band data.
+
+   - 1024 is still too low.  ;-)
+
+   When you talk about designing a file change notification system that
+   scales to 1000s of directories, juggling 1000s of fd's just does not seem
+   the right interface.  It is too heavy.
+
+Q: Why the system call approach?
+
+A: The poor user-space interface is the second biggest problem with dnotify.
+   Signals are a terrible, terrible interface for file notification.  Or for
+   anything, for that matter.  The ideal solution, from all perspectives, is a
+   file descriptor-based one that allows basic file I/O and poll/select.
+   Obtaining the fd and managing the watches could have been done either via a
+   device file or a family of new system calls.  We decided to implement a
+   family of system calls because that is the preffered approach for new kernel
+   features and it means our user interface requirements.
+
+   Additionally, it _is_ possible to  more than one instance  and
+   juggle more than one queue and thus more than one associated fd.
+
diff --git a/trunk/Documentation/i2c/chips/adm1021 → trunk/Documentation/hwmon/adm1021 b/trunk/Documentation/i2c/chips/adm1021 → trunk/Documentation/hwmon/adm1021
diff --git a/trunk/Documentation/i2c/chips/adm1025 → trunk/Documentation/hwmon/adm1025 b/trunk/Documentation/i2c/chips/adm1025 → trunk/Documentation/hwmon/adm1025
diff --git a/trunk/Documentation/i2c/chips/adm1026 → trunk/Documentation/hwmon/adm1026 b/trunk/Documentation/i2c/chips/adm1026 → trunk/Documentation/hwmon/adm1026
diff --git a/trunk/Documentation/i2c/chips/adm1031 → trunk/Documentation/hwmon/adm1031 b/trunk/Documentation/i2c/chips/adm1031 → trunk/Documentation/hwmon/adm1031
diff --git a/trunk/Documentation/i2c/chips/adm9240 → trunk/Documentation/hwmon/adm9240 b/trunk/Documentation/i2c/chips/adm9240 → trunk/Documentation/hwmon/adm9240
diff --git a/trunk/Documentation/i2c/chips/asb100 → trunk/Documentation/hwmon/asb100 b/trunk/Documentation/i2c/chips/asb100 → trunk/Documentation/hwmon/asb100
diff --git a/trunk/Documentation/i2c/chips/ds1621 → trunk/Documentation/hwmon/ds1621 b/trunk/Documentation/i2c/chips/ds1621 → trunk/Documentation/hwmon/ds1621
diff --git a/trunk/Documentation/i2c/chips/fscher → trunk/Documentation/hwmon/fscher b/trunk/Documentation/i2c/chips/fscher → trunk/Documentation/hwmon/fscher
diff --git a/trunk/Documentation/i2c/chips/gl518sm → trunk/Documentation/hwmon/gl518sm b/trunk/Documentation/i2c/chips/gl518sm → trunk/Documentation/hwmon/gl518sm
diff --git a/trunk/Documentation/i2c/chips/it87 → trunk/Documentation/hwmon/it87 b/trunk/Documentation/i2c/chips/it87 → trunk/Documentation/hwmon/it87
diff --git a/trunk/Documentation/i2c/chips/lm63 → trunk/Documentation/hwmon/lm63 b/trunk/Documentation/i2c/chips/lm63 → trunk/Documentation/hwmon/lm63
diff --git a/trunk/Documentation/i2c/chips/lm75 → trunk/Documentation/hwmon/lm75 b/trunk/Documentation/i2c/chips/lm75 → trunk/Documentation/hwmon/lm75
diff --git a/trunk/Documentation/i2c/chips/lm77 → trunk/Documentation/hwmon/lm77 b/trunk/Documentation/i2c/chips/lm77 → trunk/Documentation/hwmon/lm77
diff --git a/trunk/Documentation/i2c/chips/lm78 → trunk/Documentation/hwmon/lm78 b/trunk/Documentation/i2c/chips/lm78 → trunk/Documentation/hwmon/lm78
diff --git a/trunk/Documentation/i2c/chips/lm80 → trunk/Documentation/hwmon/lm80 b/trunk/Documentation/i2c/chips/lm80 → trunk/Documentation/hwmon/lm80
diff --git a/trunk/Documentation/i2c/chips/lm83 → trunk/Documentation/hwmon/lm83 b/trunk/Documentation/i2c/chips/lm83 → trunk/Documentation/hwmon/lm83
diff --git a/trunk/Documentation/i2c/chips/lm85 → trunk/Documentation/hwmon/lm85 b/trunk/Documentation/i2c/chips/lm85 → trunk/Documentation/hwmon/lm85
diff --git a/trunk/Documentation/i2c/chips/lm87 → trunk/Documentation/hwmon/lm87 b/trunk/Documentation/i2c/chips/lm87 → trunk/Documentation/hwmon/lm87
diff --git a/trunk/Documentation/i2c/chips/lm90 → trunk/Documentation/hwmon/lm90 b/trunk/Documentation/i2c/chips/lm90 → trunk/Documentation/hwmon/lm90
diff --git a/trunk/Documentation/i2c/chips/lm92 → trunk/Documentation/hwmon/lm92 b/trunk/Documentation/i2c/chips/lm92 → trunk/Documentation/hwmon/lm92
diff --git a/trunk/Documentation/i2c/chips/max1619 → trunk/Documentation/hwmon/max1619 b/trunk/Documentation/i2c/chips/max1619 → trunk/Documentation/hwmon/max1619
diff --git a/trunk/Documentation/i2c/chips/pc87360 → trunk/Documentation/hwmon/pc87360 b/trunk/Documentation/i2c/chips/pc87360 → trunk/Documentation/hwmon/pc87360
diff --git a/trunk/Documentation/i2c/chips/sis5595 → trunk/Documentation/hwmon/sis5595 b/trunk/Documentation/i2c/chips/sis5595 → trunk/Documentation/hwmon/sis5595
diff --git a/trunk/Documentation/i2c/chips/smsc47b397 → trunk/Documentation/hwmon/smsc47b397 b/trunk/Documentation/i2c/chips/smsc47b397 → trunk/Documentation/hwmon/smsc47b397
diff --git a/trunk/Documentation/i2c/chips/smsc47m1 → trunk/Documentation/hwmon/smsc47m1 b/trunk/Documentation/i2c/chips/smsc47m1 → trunk/Documentation/hwmon/smsc47m1
diff --git a/trunk/Documentation/i2c/sysfs-interface → trunk/Documentation/hwmon/sysfs-interface b/trunk/Documentation/i2c/sysfs-interface → trunk/Documentation/hwmon/sysfs-interface
diff --git a/trunk/Documentation/i2c/userspace-tools → trunk/Documentation/hwmon/userspace-tools b/trunk/Documentation/i2c/userspace-tools → trunk/Documentation/hwmon/userspace-tools
diff --git a/trunk/Documentation/i2c/chips/via686a → trunk/Documentation/hwmon/via686a b/trunk/Documentation/i2c/chips/via686a → trunk/Documentation/hwmon/via686a
diff --git a/trunk/Documentation/i2c/chips/w83627hf → trunk/Documentation/hwmon/w83627hf b/trunk/Documentation/i2c/chips/w83627hf → trunk/Documentation/hwmon/w83627hf
diff --git a/trunk/Documentation/i2c/chips/w83781d → trunk/Documentation/hwmon/w83781d b/trunk/Documentation/i2c/chips/w83781d → trunk/Documentation/hwmon/w83781d
diff --git a/trunk/Documentation/i2c/chips/w83l785ts → trunk/Documentation/hwmon/w83l785ts b/trunk/Documentation/i2c/chips/w83l785ts → trunk/Documentation/hwmon/w83l785ts
diff --git a/trunk/Documentation/i2c/chips/max6875 b/trunk/Documentation/i2c/chips/max6875
@@ -2,10 +2,10 @@ Kernel driver max6875
 =====================
 
 Supported chips:
-  * Maxim max6874, max6875
-    Prefixes: 'max6875'
+  * Maxim MAX6874, MAX6875
+    Prefix: 'max6875'
     Addresses scanned: 0x50, 0x52
-    Datasheets:
+    Datasheet:
         http://pdfserv.maxim-ic.com/en/ds/MAX6874-MAX6875.pdf
 
 Author: Ben Gardner <bgardner@wabtec.com>
@@ -23,14 +23,26 @@ Module Parameters
 Description
 -----------
 
-The MAXIM max6875 is a EEPROM-programmable power-supply sequencer/supervisor.
+The Maxim MAX6875 is an EEPROM-programmable power-supply sequencer/supervisor.
 It provides timed outputs that can be used as a watchdog, if properly wired.
 It also provides 512 bytes of user EEPROM.
 
-At reset, the max6875 reads the configuration eeprom into its configuration
+At reset, the MAX6875 reads the configuration EEPROM into its configuration
 registers.  The chip then begins to operate according to the values in the
 registers.
 
+The Maxim MAX6874 is a similar, mostly compatible device, with more intputs
+and outputs:
+
+             vin     gpi    vout
+MAX6874        6       4       8
+MAX6875        4       3       5
+
+MAX6874 chips can have four different addresses (as opposed to only two for
+the MAX6875). The additional addresses (0x54 and 0x56) are not probed by
+this driver by default, but the probe module parameter can be used if
+needed.
+
 See the datasheet for details on how to program the EEPROM.
 
 

diff --git a/trunk/Documentation/i2c/dev-interface b/trunk/Documentation/i2c/dev-interface
@@ -14,9 +14,12 @@ C example
 =========
 
 So let's say you want to access an i2c adapter from a C program. The
-first thing to do is `#include <linux/i2c.h>" and "#include <linux/i2c-dev.h>. 
-Yes, I know, you should never include kernel header files, but until glibc 
-knows about i2c, there is not much choice.
+first thing to do is "#include <linux/i2c-dev.h>". Please note that
+there are two files named "i2c-dev.h" out there, one is distributed
+with the Linux kernel and is meant to be included from kernel
+driver code, the other one is distributed with lm_sensors and is
+meant to be included from user-space programs. You obviously want
+the second one here.
 
 Now, you have to decide which adapter you want to access. You should
 inspect /sys/class/i2c-dev/ to decide this. Adapter numbers are assigned
@@ -78,7 +81,7 @@ Full interface description
 ==========================
 
 The following IOCTLs are defined and fully supported 
-(see also i2c-dev.h and i2c.h):
+(see also i2c-dev.h):
 
 ioctl(file,I2C_SLAVE,long addr)
   Change slave address. The address is passed in the 7 lower bits of the
@@ -97,10 +100,10 @@ ioctl(file,I2C_PEC,long select)
 ioctl(file,I2C_FUNCS,unsigned long *funcs)
   Gets the adapter functionality and puts it in *funcs.
 
-ioctl(file,I2C_RDWR,struct i2c_ioctl_rdwr_data *msgset)
+ioctl(file,I2C_RDWR,struct i2c_rdwr_ioctl_data *msgset)
 
   Do combined read/write transaction without stop in between.
-  The argument is a pointer to a struct i2c_ioctl_rdwr_data {
+  The argument is a pointer to a struct i2c_rdwr_ioctl_data {
 
       struct i2c_msg *msgs;  /* ptr to array of simple messages */
       int nmsgs;             /* number of messages to exchange */

diff --git a/trunk/Documentation/i2c/writing-clients b/trunk/Documentation/i2c/writing-clients
@@ -27,7 +27,6 @@ address.
 static struct i2c_driver foo_driver = {
 	.owner		= THIS_MODULE,
 	.name		= "Foo version 2.3 driver",
-	.id		= I2C_DRIVERID_FOO, /* from i2c-id.h, optional */
 	.flags		= I2C_DF_NOTIFY,
 	.attach_adapter	= &foo_attach_adapter,
 	.detach_client	= &foo_detach_client,
@@ -37,12 +36,6 @@ static struct i2c_driver foo_driver = {
 The name can be chosen freely, and may be upto 40 characters long. Please
 use something descriptive here.
 
-If used, the id should be a unique ID. The range 0xf000 to 0xffff is
-reserved for local use, and you can use one of those until you start
-distributing the driver, at which time you should contact the i2c authors
-to get your own ID(s). Note that most of the time you don't need an ID
-at all so you can just omit it.
-
 Don't worry about the flags field; just put I2C_DF_NOTIFY into it. This
 means that your driver will be notified when new adapters are found.
 This is almost always what you want.

diff --git a/trunk/Documentation/kernel-parameters.txt b/trunk/Documentation/kernel-parameters.txt
@@ -37,7 +37,7 @@ restrictions referred to are that the relevant option is valid if:
 	IA-32	IA-32 aka i386 architecture is enabled.
 	IA-64	IA-64 architecture is enabled.
 	IOSCHED	More than one I/O scheduler is enabled.
-	IP_PNP	IP DCHP, BOOTP, or RARP is enabled.
+	IP_PNP	IP DHCP, BOOTP, or RARP is enabled.
 	ISAPNP	ISA PnP code is enabled.
 	ISDN	Appropriate ISDN support is enabled.
 	JOY	Appropriate joystick support is enabled.

diff --git a/trunk/Documentation/pcmcia/driver-changes.txt b/trunk/Documentation/pcmcia/driver-changes.txt
@@ -1,6 +1,13 @@
 This file details changes in 2.6 which affect PCMCIA card driver authors:
 
-* in-kernel device<->driver matching
+* event handler initialization in struct pcmcia_driver (as of 2.6.13)
+   The event handler is notified of all events, and must be initialized
+   as the event() callback in the driver's struct pcmcia_driver.
+
+* pcmcia/version.h should not be used (as of 2.6.13)
+   This file will be removed eventually.
+
+* in-kernel device<->driver matching (as of 2.6.13)
    PCMCIA devices and their correct drivers can now be matched in
    kernelspace. See 'devicetable.txt' for details.
 

diff --git a/trunk/Documentation/video4linux/CARDLIST.bttv b/trunk/Documentation/video4linux/CARDLIST.bttv
@@ -1,4 +1,4 @@
-card=0 -  *** UNKNOWN/GENERIC *** 
+card=0 -  *** UNKNOWN/GENERIC ***
 card=1 - MIRO PCTV
 card=2 - Hauppauge (bt848)
 card=3 - STB, Gateway P/N 6000699 (bt848)

diff --git a/trunk/Documentation/video4linux/CARDLIST.cx88 b/trunk/Documentation/video4linux/CARDLIST.cx88
@@ -27,3 +27,5 @@ card=25 - Digital-Logic MICROSPACE Entertainment Center (MEC)
 card=26 - IODATA GV/BCTV7E
 card=27 - PixelView PlayTV Ultra Pro (Stereo)
 card=28 - DViCO FusionHDTV 3 Gold-T
+card=29 - ADS Tech Instant TV DVB-T PCI
+card=30 - TerraTec Cinergy 1400 DVB-T
diff --git a/trunk/Documentation/video4linux/CARDLIST.saa7134 b/trunk/Documentation/video4linux/CARDLIST.saa7134
@@ -1,10 +1,10 @@
-  0 -> UNKNOWN/GENERIC                         
+  0 -> UNKNOWN/GENERIC
   1 -> Proteus Pro [philips reference design]   [1131:2001,1131:2001]
   2 -> LifeView FlyVIDEO3000                    [5168:0138,4e42:0138]
   3 -> LifeView FlyVIDEO2000                    [5168:0138]
   4 -> EMPRESS                                  [1131:6752]
   5 -> SKNet Monster TV                         [1131:4e85]
-  6 -> Tevion MD 9717                          
+  6 -> Tevion MD 9717
   7 -> KNC One TV-Station RDS / Typhoon TV Tuner RDS [1131:fe01,1894:fe01]
   8 -> Terratec Cinergy 400 TV                  [153B:1142]
   9 -> Medion 5044
@@ -34,6 +34,7 @@
  33 -> AVerMedia DVD EZMaker                    [1461:10ff]
  34 -> Noval Prime TV 7133
  35 -> AverMedia AverTV Studio 305              [1461:2115]
+ 36 -> UPMOST PURPLE TV                         [12ab:0800]
  37 -> Items MuchTV Plus / IT-005
  38 -> Terratec Cinergy 200 TV                  [153B:1152]
  39 -> LifeView FlyTV Platinum Mini             [5168:0212]
@@ -43,20 +44,21 @@
  43 -> :Zolid Xpert TV7134
  44 -> Empire PCI TV-Radio LE
  45 -> Avermedia AVerTV Studio 307              [1461:9715]
- 46 -> AVerMedia Cardbus TV/Radio               [1461:d6ee]
+ 46 -> AVerMedia Cardbus TV/Radio (E500)        [1461:d6ee]
  47 -> Terratec Cinergy 400 mobile              [153b:1162]
  48 -> Terratec Cinergy 600 TV MK3              [153B:1158]
  49 -> Compro VideoMate Gold+ Pal               [185b:c200]
  50 -> Pinnacle PCTV 300i DVB-T + PAL           [11bd:002d]
  51 -> ProVideo PV952                           [1540:9524]
  52 -> AverMedia AverTV/305                     [1461:2108]
+ 53 -> ASUS TV-FM 7135                          [1043:4845]
  54 -> LifeView FlyTV Platinum FM               [5168:0214,1489:0214]
- 55 -> LifeView FlyDVB-T DUO                    [5168:0306]
+ 55 -> LifeView FlyDVB-T DUO                    [5168:0502,5168:0306]
  56 -> Avermedia AVerTV 307                     [1461:a70a]
  57 -> Avermedia AVerTV GO 007 FM               [1461:f31f]
  58 -> ADS Tech Instant TV (saa7135)            [1421:0350,1421:0370]
  59 -> Kworld/Tevion V-Stream Xpert TV PVR7134
- 60 -> Typhoon DVB-T Duo Digital/Analog Cardbus
- 61 -> Philips TOUGH DVB-T reference design
+ 60 -> Typhoon DVB-T Duo Digital/Analog Cardbus [4e42:0502]
+ 61 -> Philips TOUGH DVB-T reference design     [1131:2004]
  62 -> Compro VideoMate TV Gold+II
  63 -> Kworld Xpert TV PVR7134
diff --git a/trunk/Documentation/video4linux/CARDLIST.tuner b/trunk/Documentation/video4linux/CARDLIST.tuner
@@ -56,9 +56,9 @@ tuner=54 - tda8290+75
 tuner=55 - LG PAL (TAPE series)
 tuner=56 - Philips PAL/SECAM multi (FQ1216AME MK4)
 tuner=57 - Philips FQ1236A MK4
-tuner=58 - Ymec TVision TVF-8531MF
+tuner=58 - Ymec TVision TVF-8531MF/8831MF/8731MF
 tuner=59 - Ymec TVision TVF-5533MF
 tuner=60 - Thomson DDT 7611 (ATSC/NTSC)
-tuner=61 - Tena TNF9533-D/IF
+tuner=61 - Tena TNF9533-D/IF/TNF9533-B/DF
 tuner=62 - Philips TEA5767HN FM Radio
 tuner=63 - Philips FMD1216ME MK3 Hybrid Tuner