patch-2.4.20 linux-2.4.20/include/asm-mips64/sn/klconfig.h
Next file: linux-2.4.20/include/asm-mips64/sn/kldir.h
Previous file: linux-2.4.20/include/asm-mips64/sn/io.h
Back to the patch index
Back to the overall index
- Lines: 269
- Date:
Thu Nov 28 15:53:15 2002
- Orig file:
linux-2.4.19/include/asm-mips64/sn/klconfig.h
- Orig date:
Sun Sep 9 10:43:02 2001
diff -urN linux-2.4.19/include/asm-mips64/sn/klconfig.h linux-2.4.20/include/asm-mips64/sn/klconfig.h
@@ -19,9 +19,9 @@
/*
* WARNING:
- * Certain assembly language routines (notably xxxxx.s) in the IP27PROM
- * will depend on the format of the data structures in this file. In
- * most cases, rearranging the fields can seriously break things.
+ * Certain assembly language routines (notably xxxxx.s) in the IP27PROM
+ * will depend on the format of the data structures in this file. In
+ * most cases, rearranging the fields can seriously break things.
* Adding fields in the beginning or middle can also break things.
* Add fields if necessary, to the end of a struct in such a way
* that offsets of existing fields do not change.
@@ -76,11 +76,11 @@
#define MAX_MODULE_ID 255
#define SIZE_PAD 4096 /* 4k padding for structures */
-/*
- * 1 NODE brd, 2 Router brd (1 8p, 1 meta), 6 Widgets,
- * 2 Midplanes assuming no pci card cages
+/*
+ * 1 NODE brd, 2 Router brd (1 8p, 1 meta), 6 Widgets,
+ * 2 Midplanes assuming no pci card cages
*/
-#define MAX_SLOTS_PER_NODE (1 + 2 + 6 + 2)
+#define MAX_SLOTS_PER_NODE (1 + 2 + 6 + 2)
/* XXX if each node is guranteed to have some memory */
@@ -117,7 +117,7 @@
/* Structures to manage various data storage areas */
/* The numbers must be contiguous since the array index i
- is used in the code to allocate various areas.
+ is used in the code to allocate various areas.
*/
#define BOARD_STRUCT 0
@@ -240,7 +240,7 @@
/*
* The KLCONFIG area is organized as a LINKED LIST of BOARDs. A BOARD
- * can be either 'LOCAL' or 'REMOTE'. LOCAL means it is attached to
+ * can be either 'LOCAL' or 'REMOTE'. LOCAL means it is attached to
* the LOCAL/current NODE. REMOTE means it is attached to a different
* node.(TBD - Need a way to treat ROUTER boards.)
*
@@ -250,20 +250,20 @@
* Figure below). The first byte of the rboard or lboard structure
* is used to find out its type - no unions are used.
* If it is a lboard, then the config info of this board will be found
- * on the local node. (LOCAL NODE BASE + offset value gives pointer to
+ * on the local node. (LOCAL NODE BASE + offset value gives pointer to
* the structure.
* If it is a rboard, the local structure contains the node number
* and the offset of the beginning of the LINKED LIST on the remote node.
* The details of the hardware on a remote node can be built locally,
- * if required, by reading the LINKED LIST on the remote node and
+ * if required, by reading the LINKED LIST on the remote node and
* ignoring all the rboards on that node.
*
- * The local node uses the REMOTE NODE NUMBER + OFFSET to point to the
- * First board info on the remote node. The remote node list is
+ * The local node uses the REMOTE NODE NUMBER + OFFSET to point to the
+ * First board info on the remote node. The remote node list is
* traversed as the local list, using the REMOTE BASE ADDRESS and not
* the local base address and ignoring all rboard values.
*
- *
+ *
KLCONFIG
+------------+ +------------+ +------------+ +------------+
@@ -290,7 +290,7 @@
+--------------------------------+
*
- * Each BOARD consists of COMPONENTs and the BOARD structure has
+ * Each BOARD consists of COMPONENTs and the BOARD structure has
* pointers (offsets) to its COMPONENT structure.
* The COMPONENT structure has version info, size and speed info, revision,
* error info and the NIC info. This structure can accomodate any
@@ -298,19 +298,19 @@
*
* The ERRORINFO part of each BOARD has error information
* that describes errors about the BOARD itself. It also has flags to
- * indicate the COMPONENT(s) on the board that have errors. The error
- * information specific to the COMPONENT is present in the respective
+ * indicate the COMPONENT(s) on the board that have errors. The error
+ * information specific to the COMPONENT is present in the respective
* COMPONENT structure.
*
- * The ERRORINFO structure is also treated like a COMPONENT, ie. the
+ * The ERRORINFO structure is also treated like a COMPONENT, ie. the
* BOARD has pointers(offset) to the ERRORINFO structure. The rboard
- * structure also has a pointer to the ERRORINFO structure. This is
+ * structure also has a pointer to the ERRORINFO structure. This is
* the place to store ERRORINFO about a REMOTE NODE, if the HUB on
- * that NODE is not working or if the REMOTE MEMORY is BAD. In cases where
+ * that NODE is not working or if the REMOTE MEMORY is BAD. In cases where
* only the CPU of the REMOTE NODE is disabled, the ERRORINFO pointer can
- * be a NODE NUMBER, REMOTE OFFSET combination, pointing to error info
+ * be a NODE NUMBER, REMOTE OFFSET combination, pointing to error info
* which is present on the REMOTE NODE.(TBD)
- * REMOTE ERRINFO can be stored on any of the nearest nodes
+ * REMOTE ERRINFO can be stored on any of the nearest nodes
* or on all the nearest nodes.(TBD)
* Like BOARD structures, REMOTE ERRINFO structures can be built locally
* using the rboard errinfo pointer.
@@ -319,9 +319,9 @@
* interface routines are provided (TBD). The important thing to remember while
* manipulating the structures, is that, the NODE number information should
* be used. If the NODE is non-zero (remote) then each offset should
- * be added to the REMOTE BASE ADDR else it should be added to the LOCAL BASE ADDR.
+ * be added to the REMOTE BASE ADDR else it should be added to the LOCAL BASE ADDR.
* This includes offsets for BOARDS, COMPONENTS and ERRORINFO.
- *
+ *
* Note that these structures do not provide much info about connectivity.
* That info will be part of HWGRAPH, which is an extension of the cfg_t
* data structure. (ref IP27prom/cfg.h) It has to be extended to include
@@ -342,11 +342,11 @@
* IP27 BOARD classes
*/
-#define KLCLASS_MASK 0xf0
+#define KLCLASS_MASK 0xf0
#define KLCLASS_NONE 0x00
#define KLCLASS_NODE 0x10 /* CPU, Memory and HUB board */
-#define KLCLASS_CPU KLCLASS_NODE
-#define KLCLASS_IO 0x20 /* BaseIO, 4 ch SCSI, ethernet, FDDI
+#define KLCLASS_CPU KLCLASS_NODE
+#define KLCLASS_IO 0x20 /* BaseIO, 4 ch SCSI, ethernet, FDDI
and the non-graphics widget boards */
#define KLCLASS_ROUTER 0x30 /* Router board */
#define KLCLASS_MIDPLANE 0x40 /* We need to treat this as a board
@@ -420,7 +420,7 @@
* out the board name from the NIC string. For values less than
* 8 the name of the board needs to be hard coded in a few places.
* When bringup started nic names had not standardized and so we
- * had to hard code. (For people interested in history.)
+ * had to hard code. (For people interested in history.)
*/
#define KLTYPE_XTHD (KLCLASS_PSEUDO_GFX | 0x9)
@@ -431,7 +431,7 @@
(l->brd_flags & SECOND_NIC_PRESENT))
#define IS_MIO_IOC3(l,n) (IS_MIO_PRESENT(l) && (n > 2))
-/*
+/*
* board structures
*/
@@ -511,10 +511,10 @@
/*
- * Generic info structure. This stores common info about a
+ * Generic info structure. This stores common info about a
* component.
*/
-
+
typedef struct klinfo_s { /* Generic info */
unsigned char struct_type; /* type of this structure */
unsigned char struct_version; /* version of this structure */
@@ -540,9 +540,9 @@
/*
* Component structures.
* Following are the currently identified components:
- * CPU, HUB, MEM_BANK,
+ * CPU, HUB, MEM_BANK,
* XBOW(consists of 16 WIDGETs, each of which can be HUB or GRAPHICS or BRIDGE)
- * BRIDGE, IOC3, SuperIO, SCSI, FDDI
+ * BRIDGE, IOC3, SuperIO, SCSI, FDDI
* ROUTER
* GRAPHICS
*/
@@ -614,9 +614,9 @@
typedef u64 *router_t;
/*
- * The port info in ip27_cfg area translates to a lboart_t in the
+ * The port info in ip27_cfg area translates to a lboart_t in the
* KLCONFIG area. But since KLCONFIG does not use pointers, lboart_t
- * is stored in terms of a nasid and a offset from start of KLCONFIG
+ * is stored in terms of a nasid and a offset from start of KLCONFIG
* area on that nasid.
*/
typedef struct klport_s {
@@ -692,7 +692,7 @@
} klmod_serial_num_t;
/* Macros needed to access serial number structure in lboard_t.
- Hard coded values are necessary since we cannot treat
+ Hard coded values are necessary since we cannot treat
serial number struct as a component without losing compatibility
between prom versions. */
@@ -789,7 +789,7 @@
klconf_off_t gfx_mfg_nic;
} klgfx_t;
-typedef struct klxthd_s {
+typedef struct klxthd_s {
klinfo_t xthd_info ;
klconf_off_t xthd_mfg_nic ; /* MFG NIC string */
} klxthd_t ;
@@ -815,9 +815,9 @@
typedef struct klscsi_s { /* SCSI Controller */
klinfo_t scsi_info ;
- scsi_t scsi_specific ;
+ scsi_t scsi_specific ;
unsigned char scsi_numdevs ;
- klconf_off_t scsi_devinfo[MAX_SCSI_DEVS] ;
+ klconf_off_t scsi_devinfo[MAX_SCSI_DEVS] ;
} klscsi_t ;
typedef struct klscdev_s { /* SCSI device */
@@ -842,20 +842,20 @@
typedef struct klmsdev_s { /* mouse device */
klinfo_t msdev_info ;
- void *msdev_cfg ;
+ void *msdev_cfg ;
} klmsdev_t ;
#define MAX_FDDI_DEVS 10 /* XXX Is this true */
typedef struct klfddi_s { /* FDDI */
klinfo_t fddi_info ;
- fddi_t fddi_specific ;
+ fddi_t fddi_specific ;
klconf_off_t fddi_devinfo[MAX_FDDI_DEVS] ;
} klfddi_t ;
typedef struct klmio_s { /* MIO */
klinfo_t mio_info ;
- mio_t mio_specific ;
+ mio_t mio_specific ;
} klmio_t ;
@@ -890,17 +890,17 @@
/*
* TBD - Can the ARCS and device driver related info also be included in the
- * KLCONFIG area. On the IO4PROM, prom device driver info is part of cfgnode_t
+ * KLCONFIG area. On the IO4PROM, prom device driver info is part of cfgnode_t
* structure, viz private to the IO4prom.
*/
-/*
- * TBD - Allocation issues.
+/*
+ * TBD - Allocation issues.
*
- * Do we need to Mark off sepatate heaps for lboard_t, rboard_t, component,
- * errinfo and allocate from them, or have a single heap and allocate all
+ * Do we need to Mark off sepatate heaps for lboard_t, rboard_t, component,
+ * errinfo and allocate from them, or have a single heap and allocate all
* structures from it. Debug is easier in the former method since we can
- * dump all similar structs in one command, but there will be lots of holes,
+ * dump all similar structs in one command, but there will be lots of holes,
* in memory and max limits are needed for number of structures.
* Another way to make it organized, is to have a union of all components
* and allocate a aligned chunk of memory greater than the biggest
FUNET's LINUX-ADM group, linux-adm@nic.funet.fi
TCL-scripts by Sam Shen (who was at: slshen@lbl.gov)