diff options
Diffstat (limited to 'Documentation')
| -rw-r--r-- | Documentation/dvb/README.flexcop | 205 | ||||
| -rw-r--r-- | Documentation/dvb/bt8xx.txt | 69 | ||||
| -rw-r--r-- | Documentation/dvb/ci.txt | 219 | ||||
| -rw-r--r-- | Documentation/dvb/get_dvb_firmware | 4 | ||||
| -rw-r--r-- | Documentation/feature-removal-schedule.txt | 20 | ||||
| -rw-r--r-- | Documentation/filesystems/sysfs-pci.txt | 6 | ||||
| -rw-r--r-- | Documentation/power/devices.txt | 21 | ||||
| -rw-r--r-- | Documentation/powerpc/hvcs.txt | 4 |
8 files changed, 474 insertions, 74 deletions
diff --git a/Documentation/dvb/README.flexcop b/Documentation/dvb/README.flexcop new file mode 100644 index 00000000000..a50c70f9ca7 --- /dev/null +++ b/Documentation/dvb/README.flexcop @@ -0,0 +1,205 @@ +This README escorted the skystar2-driver rewriting procedure. It describes the +state of the new flexcop-driver set and some internals are written down here +too. + +This document hopefully describes things about the flexcop and its +device-offsprings. Goal was to write an easy-to-write and easy-to-read set of +drivers based on the skystar2.c and other information. + +Remark: flexcop-pci.c was a copy of skystar2.c, but every line has been +touched and rewritten. + +History & News +============== + 2005-04-01 - correct USB ISOC transfers (thanks to Vadim Catana) + + + + +General coding processing +========================= + +We should proceed as follows (as long as no one complains): + +0) Think before start writing code! + +1) rewriting the skystar2.c with the help of the flexcop register descriptions +and splitting up the files to a pci-bus-part and a flexcop-part. +The new driver will be called b2c2-flexcop-pci.ko/b2c2-flexcop-usb.ko for the +device-specific part and b2c2-flexcop.ko for the common flexcop-functions. + +2) Search for errors in the leftover of flexcop-pci.c (compare with pluto2.c +and other pci drivers) + +3) make some beautification (see 'Improvements when rewriting (refactoring) is +done') + +4) Testing the new driver and maybe substitute the skystar2.c with it, to reach +a wider tester audience. + +5) creating an usb-bus-part using the already written flexcop code for the pci +card. + +Idea: create a kernel-object for the flexcop and export all important +functions. This option saves kernel-memory, but maybe a lot of functions have +to be exported to kernel namespace. + + +Current situation +================= + +0) Done :) +1) Done (some minor issues left) +2) Done +3) Not ready yet, more information is necessary +4) next to be done (see the table below) +5) USB driver is working (yes, there are some minor issues) + +What seems to be ready? +----------------------- + +1) Rewriting +1a) i2c is cut off from the flexcop-pci.c and seems to work +1b) moved tuner and demod stuff from flexcop-pci.c to flexcop-tuner-fe.c +1c) moved lnb and diseqc stuff from flexcop-pci.c to flexcop-tuner-fe.c +1e) eeprom (reading MAC address) +1d) sram (no dynamic sll size detection (commented out) (using default as JJ told me)) +1f) misc. register accesses for reading parameters (e.g. resetting, revision) +1g) pid/mac filter (flexcop-hw-filter.c) +1i) dvb-stuff initialization in flexcop.c (done) +1h) dma stuff (now just using the size-irq, instead of all-together, to be done) +1j) remove flexcop initialization from flexcop-pci.c completely (done) +1l) use a well working dma IRQ method (done, see 'Known bugs and problems and TODO') +1k) cleanup flexcop-files (remove unused EXPORT_SYMBOLs, make static from +non-static where possible, moved code to proper places) + +2) Search for errors in the leftover of flexcop-pci.c (partially done) +5a) add MAC address reading +5c) feeding of ISOC data to the software demux (format of the isochronous data +and speed optimization, no real error) (thanks to Vadim Catana) + +What to do in the near future? +-------------------------------------- +(no special order here) + +5) USB driver +5b) optimize isoc-transfer (submitting/killing isoc URBs when transfer is starting) + +Testing changes +--------------- + +O = item is working +P = item is partially working +X = item is not working +N = item does not apply here +<empty field> = item need to be examined + + | PCI | USB +item | mt352 | nxt2002 | stv0299 | mt312 | mt352 | nxt2002 | stv0299 | mt312 +-------+-------+---------+---------+-------+-------+---------+---------+------- +1a) | O | | | | N | N | N | N +1b) | O | | | | | | O | +1c) | N | N | | | N | N | O | +1d) | O | O +1e) | O | O +1f) | P +1g) | O +1h) | P | +1i) | O | N +1j) | O | N +1l) | O | N +2) | O | N +5a) | N | O +5b)* | N | +5c) | N | O + +* - not done yet + +Known bugs and problems and TODO +-------------------------------- + +1g/h/l) when pid filtering is enabled on the pci card + +DMA usage currently: + The DMA is splitted in 2 equal-sized subbuffers. The Flexcop writes to first + address and triggers an IRQ when it's full and starts writing to the second + address. When the second address is full, the IRQ is triggered again, and + the flexcop writes to first address again, and so on. + The buffersize of each address is currently 640*188 bytes. + + Problem is, when using hw-pid-filtering and doing some low-bandwidth + operation (like scanning) the buffers won't be filled enough to trigger + the IRQ. That's why: + + When PID filtering is activated, the timer IRQ is used. Every 1.97 ms the IRQ + is triggered. Is the current write address of DMA1 different to the one + during the last IRQ, then the data is passed to the demuxer. + + There is an additional DMA-IRQ-method: packet count IRQ. This isn't + implemented correctly yet. + + The solution is to disable HW PID filtering, but I don't know how the DVB + API software demux behaves on slow systems with 45MBit/s TS. + +Solved bugs :) +-------------- +1g) pid-filtering (somehow pid index 4 and 5 (EMM_PID and ECM_PID) aren't +working) +SOLUTION: also index 0 was affected, because net_translation is done for +these indexes by default + +5b) isochronous transfer does only work in the first attempt (for the Sky2PC +USB, Air2PC is working) SOLUTION: the flexcop was going asleep and never really +woke up again (don't know if this need fixes, see +flexcop-fe-tuner.c:flexcop_sleep) + +NEWS: when the driver is loaded and unloaded and loaded again (w/o doing +anything in the while the driver is loaded the first time), no transfers take +place anymore. + +Improvements when rewriting (refactoring) is done +================================================= + +- split sleeping of the flexcop (misc_204.ACPI3_sig = 1;) from lnb_control + (enable sleeping for other demods than dvb-s) +- add support for CableStar (stv0297 Microtune 203x/ALPS) (almost done, incompatibilities with the Nexus-CA) + +Debugging +--------- +- add verbose debugging to skystar2.c (dump the reg_dw_data) and compare it + with this flexcop, this is important, because i2c is now using the + flexcop_ibi_value union from flexcop-reg.h (do you have a better idea for + that, please tell us so). + +Everything which is identical in the following table, can be put into a common +flexcop-module. + + PCI USB +------------------------------------------------------------------------------- +Different: +Register access: accessing IO memory USB control message +I2C bus: I2C bus of the FC USB control message +Data transfer: DMA isochronous transfer +EEPROM transfer: through i2c bus not clear yet + +Identical: +Streaming: accessing registers +PID Filtering: accessing registers +Sram destinations: accessing registers +Tuner/Demod: I2C bus +DVB-stuff: can be written for common use + +Acknowledgements (just for the rewriting part) +================ + +Bjarne Steinsbo thought a lot in the first place of the pci part for this code +sharing idea. + +Andreas Oberritter for providing a recent PCI initialization template +(pluto2.c). + +Boleslaw Ciesielski for pointing out a problem with firmware loader. + +Vadim Catana for correcting the USB transfer. + +comments, critics and ideas to linux-dvb@linuxtv.org. diff --git a/Documentation/dvb/bt8xx.txt b/Documentation/dvb/bt8xx.txt index e3cacf4f234..d64430bf4bb 100644 --- a/Documentation/dvb/bt8xx.txt +++ b/Documentation/dvb/bt8xx.txt @@ -17,74 +17,53 @@ Because of this, you need to enable "Device drivers" => "Multimedia devices" => "Video For Linux" => "BT848 Video For Linux" +Furthermore you need to enable +"Device drivers" => "Multimedia devices" => "Digital Video Broadcasting Devices" + => "DVB for Linux" "DVB Core Support" "Nebula/Pinnacle PCTV/TwinHan PCI Cards" + 2) Loading Modules ================== In general you need to load the bttv driver, which will handle the gpio and -i2c communication for us. Next you need the common dvb-bt8xx device driver -and one frontend driver. - -The bttv driver will HANG YOUR SYSTEM IF YOU DO NOT SPECIFY THE CORRECT -CARD ID! - -(If you don't get your card running and you suspect that the card id you're -using is wrong, have a look at "bttv-cards.c" for a list of possible card -ids.) - -Pay attention to failures when you load the frontend drivers -(e.g. dmesg, /var/log/messages). +i2c communication for us, plus the common dvb-bt8xx device driver. +The frontends for Nebula (nxt6000), Pinnacle PCTV (cx24110) and +TwinHan (dst) are loaded automatically by the dvb-bt8xx device driver. 3a) Nebula / Pinnacle PCTV -------------------------- - $ modprobe bttv i2c_hw=1 card=0x68 - $ modprobe dvb-bt8xx - -For Nebula cards use the "nxt6000" frontend driver: - $ modprobe nxt6000 + $ modprobe bttv (normally bttv is being loaded automatically by kmod) + $ modprobe dvb-bt8xx (or just place dvb-bt8xx in /etc/modules for automatic loading) -For Pinnacle PCTV cards use the "cx24110" frontend driver: - $ modprobe cx24110 -3b) TwinHan ------------ +3b) TwinHan and Clones +-------------------------- $ modprobe bttv i2c_hw=1 card=0x71 $ modprobe dvb-bt8xx $ modprobe dst -The value 0x71 will override the PCI type detection for dvb-bt8xx, which -is necessary for TwinHan cards.# +The value 0x71 will override the PCI type detection for dvb-bt8xx, +which is necessary for TwinHan cards. -If you're having an older card (blue color circuit) and card=0x71 locks your -machine, try using 0x68, too. If that does not work, ask on the DVB mailing list. +If you're having an older card (blue color circuit) and card=0x71 locks +your machine, try using 0x68, too. If that does not work, ask on the +mailing list. -The DST module takes a couple of useful parameters, in case the -dst drivers fails to detect your type of card correctly. +The DST module takes a couple of useful parameters. -dst_type takes values 0 (satellite), 1 (terrestial TV), 2 (cable). +verbose takes values 0 to 5. These values control the verbosity level. -dst_type_flags takes bit combined values: -1 = new tuner type packets. You can use this if your card is detected - and you have debug and you continually see the tuner packets not - working (make sure not a basic problem like dish alignment etc.) +debug takes values 0 and 1. You can either disable or enable debugging. -2 = TS 204. If your card tunes OK, but the picture is terrible, seemingly - breaking up in one half continually, and crc fails a lot, then - this is worth a try (or trying to turn off) +dst_addons takes values 0 and 0x20. A value of 0 means it is a FTA card. +0x20 means it has a Conditional Access slot. -4 = has symdiv. Some cards, mostly without new tuner packets, require - a symbol division algorithm. Doesn't apply to terrestial TV. - -You can also specify a value to have the autodetected values turned off -(e.g. 0). The autodected values are determined bythe cards 'response +The autodected values are determined bythe cards 'response string' which you can see in your logs e.g. -dst_check_ci: recognize DST-MOT - -or +dst_get_device_id: Recognise [DSTMCI] -dst_check_ci: unable to recognize DSTXCI or STXCI -- -Authors: Richard Walker, Jamie Honan, Michael Hunold +Authors: Richard Walker, Jamie Honan, Michael Hunold, Manu Abraham diff --git a/Documentation/dvb/ci.txt b/Documentation/dvb/ci.txt new file mode 100644 index 00000000000..62e0701b542 --- /dev/null +++ b/Documentation/dvb/ci.txt @@ -0,0 +1,219 @@ +* For the user +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ +NOTE: This document describes the usage of the high level CI API as +in accordance to the Linux DVB API. This is a not a documentation for the, +existing low level CI API. +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +To utilize the High Level CI capabilities, + +(1*) This point is valid only for the Twinhan/clones + For the Twinhan/Twinhan clones, the dst_ca module handles the CI + hardware handling.This module is loaded automatically if a CI + (Common Interface, that holds the CAM (Conditional Access Module) + is detected. + +(2) one requires a userspace application, ca_zap. This small userland + application is in charge of sending the descrambling related information + to the CAM. + +This application requires the following to function properly as of now. + + (a) Tune to a valid channel, with szap. + eg: $ szap -c channels.conf -r "TMC" -x + + (b) a channels.conf containing a valid PMT PID + + eg: TMC:11996:h:0:27500:278:512:650:321 + + here 278 is a valid PMT PID. the rest of the values are the + same ones that szap uses. + + (c) after running a szap, you have to run ca_zap, for the + descrambler to function, + + eg: $ ca_zap patched_channels.conf "TMC" + + The patched means a patch to apply to scan, such that scan can + generate a channels.conf_with pmt, which has this PMT PID info + (NOTE: szap cannot use this channels.conf with the PMT_PID) + + + (d) Hopeflly Enjoy your favourite subscribed channel as you do with + a FTA card. + +(3) Currently ca_zap, and dst_test, both are meant for demonstration + purposes only, they can become full fledged applications if necessary. + + +* Cards that fall in this category +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ +At present the cards that fall in this category are the Twinhan and it's +clones, these cards are available as VVMER, Tomato, Hercules, Orange and +so on. + +* CI modules that are supported +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ +The CI module support is largely dependant upon the firmware on the cards +Some cards do support almost all of the available CI modules. There is +nothing much that can be done in order to make additional CI modules +working with these cards. + +Modules that have been tested by this driver at present are + +(1) Irdeto 1 and 2 from SCM +(2) Viaccess from SCM +(3) Dragoncam + +* The High level CI API +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +* For the programmer +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ +With the High Level CI approach any new card with almost any random +architecture can be implemented with this style, the definitions +insidethe switch statement can be easily adapted for any card, thereby +eliminating the need for any additional ioctls. + +The disadvantage is that the driver/hardware has to manage the rest. For +the application programmer it would be as simple as sending/receiving an +array to/from the CI ioctls as defined in the Linux DVB API. No changes +have been made in the API to accomodate this feature. + + +* Why the need for another CI interface ? +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ +This is one of the most commonly asked question. Well a nice question. +Strictly speaking this is not a new interface. + +The CI interface is defined in the DVB API in ca.h as + +typedef struct ca_slot_info { + int num; /* slot number */ + + int type; /* CA interface this slot supports */ +#define CA_CI 1 /* CI high level interface */ +#define CA_CI_LINK 2 /* CI link layer level interface */ +#define CA_CI_PHYS 4 /* CI physical layer level interface */ +#define CA_DESCR 8 /* built-in descrambler */ +#define CA_SC 128 /* simple smart card interface */ + + unsigned int flags; +#define CA_CI_MODULE_PRESENT 1 /* module (or card) inserted */ +#define CA_CI_MODULE_READY 2 +} ca_slot_info_t; + + + +This CI interface follows the CI high level interface, which is not +implemented by most applications. Hence this area is revisited. + +This CI interface is quite different in the case that it tries to +accomodate all other CI based devices, that fall into the other categories + +This means that this CI interface handles the EN50221 style tags in the +Application layer only and no session management is taken care of by the +application. The driver/hardware will take care of all that. + +This interface is purely an EN50221 interface exchanging APDU's. This +means that no session management, link layer or a transport layer do +exist in this case in the application to driver communication. It is +as simple as that. The driver/hardware has to take care of that. + + +With this High Level CI interface, the interface can be defined with the +regular ioctls. + +All these ioctls are also valid for the High level CI interface + +#define CA_RESET _IO('o', 128) +#define CA_GET_CAP _IOR('o', 129, ca_caps_t) +#define CA_GET_SLOT_INFO _IOR('o', 130, ca_slot_info_t) +#define CA_GET_DESCR_INFO _IOR('o', 131, ca_descr_info_t) +#define CA_GET_MSG _IOR('o', 132, ca_msg_t) +#define CA_SEND_MSG _IOW('o', 133, ca_msg_t) +#define CA_SET_DESCR _IOW('o', 134, ca_descr_t) +#define CA_SET_PID _IOW('o', 135, ca_pid_t) + + +On querying the device, the device yields information thus + +CA_GET_SLOT_INFO +---------------------------- +Command = [info] +APP: Number=[1] +APP: Type=[1] +APP: flags=[1] +APP: CI High level interface +APP: CA/CI Module Present + +CA_GET_CAP +---------------------------- +Command = [caps] +APP: Slots=[1] +APP: Type=[1] +APP: Descrambler keys=[16] +APP: Type=[1] + +CA_SEND_MSG +---------------------------- +Descriptors(Program Level)=[ 09 06 06 04 05 50 ff f1] +Found CA descriptor @ program level + +(20) ES type=[2] ES pid=[201] ES length =[0 (0x0)] +(25) ES type=[4] ES pid=[301] ES length =[0 (0x0)] +ca_message length is 25 (0x19) bytes +EN50221 CA MSG=[ 9f 80 32 19 03 01 2d d1 f0 08 01 09 06 06 04 05 50 ff f1 02 e0 c9 00 00 04 e1 2d 00 00] + + +Not all ioctl's are implemented in the driver from the API, the other +features of the hardware that cannot be implemented by the API are achieved +using the CA_GET_MSG and CA_SEND_MSG ioctls. An EN50221 style wrapper is +used to exchange the data to maintain compatibility with other hardware. + + +/* a message to/from a CI-CAM */ +typedef struct ca_msg { + unsigned int index; + unsigned int type; + unsigned int length; + unsigned char msg[256]; +} ca_msg_t; + + +The flow of data can be described thus, + + + + + + App (User) + ----- + parse + | + | + v + en50221 APDU (package) + -------------------------------------- + | | | High Level CI driver + | | | + | v | + | en50221 APDU (unpackage) | + | | | + | | | + | v | + | sanity checks | + | | | + | | | + | v | + | do (H/W dep) | + -------------------------------------- + | Hardware + | + v + + + + +The High Level CI interface uses the EN50221 DVB standard, following a +standard ensures futureproofness. diff --git a/Documentation/dvb/get_dvb_firmware b/Documentation/dvb/get_dvb_firmware index 3ffdcb39429..a750f0101d9 100644 --- a/Documentation/dvb/get_dvb_firmware +++ b/Documentation/dvb/get_dvb_firmware @@ -107,7 +107,7 @@ sub tda10045 { sub tda10046 { my $sourcefile = "tt_budget_217g.zip"; my $url = "http://www.technotrend.de/new/217g/$sourcefile"; - my $hash = "a25b579e37109af60f4a36c37893957c"; + my $hash = "6a7e1e2f2644b162ff0502367553c72d"; my $outfile = "dvb-fe-tda10046.fw"; my $tmpdir = tempdir(DIR => "/tmp", CLEANUP => 1); @@ -115,7 +115,7 @@ sub tda10046 { wgetfile($sourcefile, $url); unzip($sourcefile, $tmpdir); - extract("$tmpdir/software/OEM/PCI/App/ttlcdacc.dll", 0x3f731, 24479, "$tmpdir/fwtmp"); + extract("$tmpdir/software/OEM/PCI/App/ttlcdacc.dll", 0x3f731, 24478, "$tmpdir/fwtmp"); verify("$tmpdir/fwtmp", $hash); copy("$tmpdir/fwtmp", $outfile); diff --git a/Documentation/feature-removal-schedule.txt b/Documentation/feature-removal-schedule.txt index d3c52dd24a2..b9eb209318a 100644 --- a/Documentation/feature-removal-schedule.txt +++ b/Documentation/feature-removal-schedule.txt @@ -63,3 +63,23 @@ Why: Outside of Linux, the only implementations of anything even people, who might be using implementations that I am not aware of, to adjust to this upcoming change. Who: Paul E. McKenney <paulmck@us.ibm.com> + +--------------------------- + +What: IEEE1394 Audio and Music Data Transmission Protocol driver, + Connection Management Procedures driver +When: November 2005 +Files: drivers/ieee1394/{amdtp,cmp}* +Why: These are incomplete, have never worked, and are better implemented + in userland via raw1394 (see http://freebob.sourceforge.net/ for + example.) +Who: Jody McIntyre <scjody@steamballoon.com> + +--------------------------- + +What: raw1394: requests of type RAW1394_REQ_ISO_SEND, RAW1394_REQ_ISO_LISTEN +When: November 2005 +Why: Deprecated in favour of the new ioctl-based rawiso interface, which is + more efficient. You should really be using libraw1394 for raw1394 + access anyway. +Who: Jody McIntyre <scjody@steamballoon.com> diff --git a/Documentation/filesystems/sysfs-pci.txt b/Documentation/filesystems/sysfs-pci.txt index e97d024eae7..988a62fae11 100644 --- a/Documentation/filesystems/sysfs-pci.txt +++ b/Documentation/filesystems/sysfs-pci.txt @@ -7,7 +7,6 @@ that support it. For example, a given bus might look like this: |-- 0000:17:00.0 | |-- class | |-- config - | |-- detach_state | |-- device | |-- irq | |-- local_cpus @@ -19,7 +18,7 @@ that support it. For example, a given bus might look like this: | |-- subsystem_device | |-- subsystem_vendor | `-- vendor - `-- detach_state + `-- ... The topmost element describes the PCI domain and bus number. In this case, the domain number is 0000 and the bus number is 17 (both values are in hex). @@ -31,7 +30,6 @@ files, each with their own function. ---- -------- class PCI class (ascii, ro) config PCI config space (binary, rw) - detach_state connection status (bool, rw) device PCI device (ascii, ro) irq IRQ number (ascii, ro) local_cpus nearby CPU mask (cpumask, ro) @@ -85,4 +83,4 @@ useful return codes should be provided. Legacy resources are protected by the HAVE_PCI_LEGACY define. Platforms wishing to support legacy functionality should define it and provide -pci_legacy_read, pci_legacy_write and pci_mmap_legacy_page_range functions.
\ No newline at end of file +pci_legacy_read, pci_legacy_write and pci_mmap_legacy_page_range functions. diff --git a/Documentation/power/devices.txt b/Documentation/power/devices.txt index 5d4ae9a39f1..f987afe43e2 100644 --- a/Documentation/power/devices.txt +++ b/Documentation/power/devices.txt @@ -207,27 +207,6 @@ SYSTEM_SHUTDOWN, I do not understand this one too much. probably event #READY_AFTER_RESUME # -Driver Detach Power Management - -The kernel now supports the ability to place a device in a low-power -state when it is detached from its driver, which happens when its -module is removed. - -Each device contains a 'detach_state' file in its sysfs directory -which can be used to control this state. Reading from this file -displays what the current detach state is set to. This is 0 (On) by -default. A user may write a positive integer value to this file in the -range of 1-4 inclusive. - -A value of 1-3 will indicate the device should be placed in that -low-power state, which will cause ->suspend() to be called for that -device. A value of 4 indicates that the device should be shutdown, so -->shutdown() will be called for that device. - -The driver is responsible for reinitializing the device when the -module is re-inserted during it's ->probe() (or equivalent) method. -The driver core will not call any extra functions when binding the -device to the driver. pm_message_t meaning diff --git a/Documentation/powerpc/hvcs.txt b/Documentation/powerpc/hvcs.txt index c0a62e116e6..dca75cbda6f 100644 --- a/Documentation/powerpc/hvcs.txt +++ b/Documentation/powerpc/hvcs.txt @@ -347,8 +347,8 @@ address that is created by firmware. An example vty-server sysfs entry looks like the following: Pow5:/sys/bus/vio/drivers/hvcs/30000004 # ls - . current_vty devspec name partner_vtys - .. detach_state index partner_clcs vterm_state + . current_vty devspec name partner_vtys + .. index partner_clcs vterm_state Each entry is provided, by default with a "name" attribute. Reading the "name" attribute will reveal the device type as shown in the following |