Server IP : 62.109.13.187 / Your IP : 216.73.216.11 [Reverse IP] Web Server : Apache/2.4.6 (CentOS) mpm-itk/2.4.7-04 OpenSSL/1.0.2k-fips PHP/8.2.28 System : Linux robothost.ru 3.10.0-1160.119.1.el7.x86_64 #1 SMP Tue Jun 4 14:43:51 UTC 2024 x86_64 User : mosrembit ( 6064) PHP Version : 8.2.28 Disable Function : NONE Domains : 0 Domains MySQL : OFF | cURL : ON | WGET : ON | Perl : ON | Python : ON | Sudo : ON | Pkexec : ON Directory : /usr/share/doc/lshw-B.02.18/
Current File : /usr/share/doc/lshw-B.02.18/IODC.txt
Some notes on IODC, its general brokenness, and how to work around it.
Short Version
IODC is HP's pre-PCI standard for device identification (a la PCI vendor,
device IDs), detection, configuration, initialization and so on.
It also can provide firmware function to do the actual IO, which are slow,
not really defined for runtime usage and generally not desirable. (There
are other firmware standards, such as STI, to do real IO).
Usually, there are two parts to IODC. The actual ROMs, which are laid out,
detected aso in a bus-specific manner (IO_DC_ADDRESS / IO_DC_DATA on
GSC/Runway, PCI spec - compliant ROMs for PCI, God-only-knows how on EISA),
and the slightly cooked data read by PDC_IODC.
The ROM layout is generally icky (only one byte out of every 4-byte-word
might be valid, and many devices don't implement required options), so
using PDC_IODC is highly recommended. (In fact, you should use the device
lists set up by the kernel proper instead of calling PDC_IODC yourself).
Now, let's have a look at what the cooked ROM looks like (see iodc.pdf for
the details, this is the simplified version).
Basically, the first 8 bytes of IODC contain two 32-bit ids called HVERSION
and SVERSION. Those are further split up into bit fields, and
unfortunately just ignoring this split up isn't an option.
SVERSION consists of a 4-bit revision field, a 20-bit model field and a
8-bit opt field. Now, forget the revision and opt fields exist. Basically,
the model field is equivalent to a PCI device id (there is no vendor id.
this is proprietary hardware we're talking about). That is, all your
driver cares for, in 90 % of the cases, is to find all devices that match
the model field.
The rev field is - you guessed it - roughly equivalent to the revision
byte for PCI, with the exception that higher revisions should be strict
supersets of lower revisions.
The last byte of HVERSION, "type", and the last byte of SVERSION, "opt",
belong together; type gives a very rough indication of what the device
is supposed to do, and opt contains some type-specific information. (For
example, the "bus converter" (ie bus bridge) type encodes the kind of
bus behind the bridge in the opt field.
The rest of HVERSION contains, in most cases, a number identifying the
machine the chip was used in, or a revision indicator that just fixed
bugs and didn't add any features (or was done in a shrinked process or
whatever).
So, here's the interface you actually should use to find your devices:
/* Find a device, matching the model field of sversion only (from=NULL
* for the first call */
struct iodc_dev *iodc_find_device(u32 sversion, struct iodc_dev *from);
Here's a function you should use if you have special requirements, such
as finding devices by type rather than by model. Generally, if you're
using this, you should be me).
/* Find a device, masking out bits as specified */
struct iodc_dev *iodc_find_device_mask(u32 hversion, u32 sversion,
u32 hversion_mask, u32 sversion_mask, struct iodc_dev *from);
Philipp Rumpf <prumpf@tux.org>