sunddi.h revision 8d483882aa3390058094b043f3d62187b5d1de03
* Generic Sun DDI definitions. #
define DDI_EAGAIN (-
3)
/* not enough interrupt resources */#
define DDI_EINVAL (-
4)
/* invalid request or arguments */#
define DDI_ENOTSUP (-
5)
/* operation is not supported */#
define DDI_EPENDING (-
6)
/* operation or an event is pending */ * General-purpose DDI error return value definitions * The following special nodeid values are reserved for use when creating * nodes ONLY. They specify the attributes of the DDI_NC_PSEUDO class node * o DEVI_PSEUDO_NODEID specifics a node without persistence. * o DEVI_SID_NODEID specifies a node with persistence. * A node with the 'persistent' attribute will not be automatically removed by * the framework in the current implementation - driver.conf nodes are without * The actual nodeid value may be assigned by the framework and may be * different than these special values. Drivers may not make assumptions * about the nodeid value that is actually assigned to the node. * ddi_create_minor_node flags #
define CLONE_DEV 1 /* device is a clone device */#
define PRIVONLY_DEV 0x10 /* policy-based permissions only */ * Historical values used for the flag field in ddi_create_minor_node. * Future use of flag bits should avoid these fields to keep binary * #define NODEBOUND_DEV 0x4 * #define NODESPECIFIC_DEV 0x6 * #define ENUMERATED_DEV 0x8 * Device type defines which are used by the 'node_type' element of the * ddi_minor_data structure /* ports (the old ttya, b */ * *_CHAN disk type devices have channel numbers or target numbers. * (i.e. ipi and scsi devices) * The next define is for block type devices that can possible exist on * a sub-bus like the scsi bus or the ipi channel. The 'disks' program * will pick up on this and create logical names like c0t0d0s0 instead of #
define DDI_NT_CD "ddi_block:cdrom" /* rom drives (cd-rom) */#
define DDI_NT_CD_CHAN "ddi_block:cdrom:channel" /* rom drives (scsi type) */#
define DDI_NT_FD "ddi_block:diskette" /* floppy disks */#
define DDI_NT_NET "ddi_network" /* DLPI network devices */#
define DDI_PSEUDO "ddi_pseudo" /* general pseudo devices */#
define DDI_NT_UGEN "ddi_generic:usb" /* USB generic drv */ /* generic bd attachment pt */ /* Device types used for agpgart driver related devices */ #
define EC_DEVFS "EC_devfs" /* Event class devfs */#
define EC_DDI "EC_ddi" /* Event class ddi *//* Class devfs subclasses */ /* Class ddi subclasses */ * devfs event class attributes * The following attributes are private to EC_DEVFS event data. * ddi event class payload * The following attributes are private to EC_DDI event data. * Fault-related definitions * The specific numeric values have been chosen to be ordered, but * not consecutive, to allow for future interpolation if required. * Common property definitions * Values that the function supplied to the dev_info * tree traversal functions defined below must return. * Continue search, if appropriate. * Terminate current depth of traversal. That is, terminate * the current traversal of children nodes, but continue * traversing sibling nodes and their children (if any). * Terminate current width of traversal. That is, terminate * the current traversal of sibling nodes, but continue with * traversing children nodes and their siblings (if appropriate). * Terminate the entire search. * Terminate the entire search because an error occurred in function * Drivers that are prepared to support full driver layering * should create and export a null-valued property of the following * Such drivers should be prepared to be called with FKLYR in * the 'flag' argument of their open(9E), close(9E) routines, and * with FKIOCTL in the 'mode' argument of their ioctl(9E) routines. * See ioctl(9E) and ddi_copyin(9F) for details. * Model definitions for ddi_mmap_get_model(9F) and ddi_model_convert_from(9F). * Functions and data references which really should be in <sys/ddi.h> int,
void (*)(
struct buf *),
struct uio *);
extern long strtol(
const char *,
char **,
int);
extern unsigned long strtoul(
const char *,
char **,
int);
extern char *
strcpy(
char *,
const char *);
/* Need to be consistent with <string.h> C++ definition for strchr() */ extern const char *
strchr(
const char *,
int);
#
endif /* _STRCHR_INLINE */extern char *
strchr(
const char *,
int);
#
endif /* __cplusplus >= 199711L */extern int stoi(
char **);
/* Need to be consistent with <string.h> C++ definition for memchr() */ #
endif /* _MEMCHR_INLINE */#
endif /* __cplusplus >= 199711L */extern int ddi_strtol(
const char *,
char **,
int,
long *);
extern int ddi_strtoul(
const char *,
char **,
int,
unsigned long *);
* Unicode encoding conversion functions and their macros. * UTF-8 text preparation functions and their macros. * Among the macros defined, U8_CANON_DECOMP, U8_COMPAT_DECOMP, and * U8_CANON_COMP are not public interfaces and must not be used directly * at the flag input argument. * Map in the register set given by rnumber. * The register number determine which register * set will be mapped if more than one exists. * The parent driver gets the information * from parent private data and sets up the * appropriate mappings and returns the kernel * virtual address of the register set in *kaddrp. * The offset specifies an offset into the register * space to start from and len indicates the size * of the area to map. If len and offset are 0 then * the entire space is mapped. It returns DDI_SUCCESS on * success or DDI_FAILURE otherwise. * Undo mappings set up by ddi_map_regs. * The register number determines which register * set will be unmapped if more than one exists. * This is provided for drivers preparing * to detach themselves from the system to * allow them to release allocated mappings. * The kaddrp and len specify the area to be * unmapped. *kaddrp was returned from ddi_map_regs * and len should match what ddi_map_regs was called * ddi_rnumber_to_regspec: Not for use by leaf drivers. * Peek and poke to and from a uio structure in xfersize pieces, * Pagesize conversions using the parent nexi * There are no more "block" interrupt functions, per se. * All thread of control should be done with MP/MT lockings. * However, there are certain times in which a driver needs * absolutely a critical guaranteed non-preemptable time * in which to execute a few instructions. * The following pair of functions attempt to guarantee this, * but they are dangerous to use. That is, use them with * extreme care. They do not guarantee to stop other processors * from executing, but they do guarantee that the caller * of ddi_enter_critical will continue to run until the * caller calls ddi_exit_critical. No intervening DDI functions * may be called between an entry and an exit from a critical * ddi_enter_critical returns an integer identifier which must * be passed to ddi_exit_critical. * Be very sparing in the use of these functions since it is * likely that absolutely nothing else can occur in the system * whilst in the critical region. * Functions to lock user memory and do repeated I/O or do devmap_umem_setup * In general, the underlying driver MUST be held * to call it's property functions. * Used to create, modify, and lookup integer properties * Used to create, modify, and lookup string properties * Used to create, modify, and lookup byte properties * Used to verify the existence of a property or to see if a boolean * Used to free the data returned by the above property routines. * nopropop: For internal use in `dummy' cb_prop_op functions only * ddi_prop_op: The basic property operator for drivers. * In ddi_prop_op, the type of valuep is interpreted based on prop_op: * PROP_LEN_AND_VAL_BUF Pointer to callers buffer * PROP_LEN_AND_VAL_ALLOC Address of callers pointer (will be set to * address of allocated buffer, if successful) /* ddi_prop_op_size: for drivers that implement size in bytes */ /* ddi_prop_op_size_blksize: like ddi_prop_op_size, in blksize blocks */ /* ddi_prop_op_nblocks: for drivers that implement size in DEV_BSIZE blocks */ /* ddi_prop_op_nblocks_blksize: like ddi_prop_op_nblocks, in blksize blocks */ * Variable length props... * ddi_getlongprop: Get variable length property len+val into a buffer * allocated by property provider via kmem_alloc. Requester * is responsible for freeing returned property via kmem_free. * dev: Input: dev_t of property. * dip: Input: dev_info_t pointer of child. * flags: Input: Possible flag modifiers are: * DDI_PROP_DONTPASS: Don't pass to parent if prop not found. * DDI_PROP_CANSLEEP: Memory allocation may sleep. * name: Input: name of property. * valuep: Output: Addr of callers buffer pointer. * lengthp:Output: *lengthp will contain prop length on exit. * DDI_PROP_SUCCESS: Prop found and returned. * DDI_PROP_NOT_FOUND: Prop not found * DDI_PROP_UNDEFINED: Prop explicitly undefined. * DDI_PROP_NO_MEMORY: Prop found, but unable to alloc mem. * ddi_getlongprop_buf: Get long prop into pre-allocated callers * buffer. (no memory allocation by provider). * dev: Input: dev_t of property. * dip: Input: dev_info_t pointer of child. * flags: Input: DDI_PROP_DONTPASS or NULL * name: Input: name of property * valuep: Input: ptr to callers buffer. * lengthp:I/O: ptr to length of callers buffer on entry, * actual length of property on exit. * DDI_PROP_SUCCESS Prop found and returned * DDI_PROP_NOT_FOUND Prop not found * DDI_PROP_UNDEFINED Prop explicitly undefined. * DDI_PROP_BUF_TOO_SMALL Prop found, callers buf too small, * no value returned, but actual prop * length returned in *lengthp * Call is value only... returns found boolean or int sized prop value or * defvalue if prop not found or is wrong length or is explicitly undefined. * Only flag is DDI_PROP_DONTPASS... * By convention, this interface returns boolean (0) sized properties * Get prop length interface: flags are 0 or DDI_PROP_DONTPASS * if returns DDI_PROP_SUCCESS, length returned in *lengthp. * Interface to create/modify a managed property on child's behalf... * Only flag is DDI_PROP_CANSLEEP to allow memory allocation to sleep * if no memory available for internal prop structure. Long property * (non integer sized) value references are not copied. * Define property with DDI_DEV_T_NONE dev_t for properties not associated * with any particular dev_t. Use the same dev_t when modifying or undefining * No guarantee on order of property search, so don't mix the same * property name with wildcard and non-wildcard dev_t's. * ddi_prop_create: Define a managed property: * ddi_prop_modify: Modify a managed property value * ddi_prop_remove: Undefine a managed property: * ddi_prop_remove_all: Used before unloading a driver to remove * all properties. (undefines all dev_t's props.) * Also removes `undefined' prop defs. * ddi_prop_undefine: Explicitly undefine a property. Property * searches which match this property return * the error code DDI_PROP_UNDEFINED. * Use ddi_prop_remove to negate effect of * The default ddi_bus_prop_op wrapper... * Routines to traverse the tree of dev_info nodes. * The general idea of these functions is to provide * various tree traversal utilities. For each node * that the tree traversal function finds, a caller * supplied function is called with arguments of * the current node and a caller supplied argument. * The caller supplied function should return one * of the integer values defined below which will * indicate to the tree traversal function whether * the traversal should be continued, and if so, how, * or whether the traversal should terminate. * This general-purpose routine traverses the tree of dev_info nodes, * starting from the given node, and calls the given function for each * node that it finds with the current node and the pointer arg (which * can point to a structure of information that the function * It does the walk a layer at a time, not depth-first. * The given function must return one of the values defined above. * Routines to get at elements of the dev_info structure * ddi_node_name gets the device's 'name' from the device node. * ddi_binding_name gets the string the OS used to bind the node to a driver, * in certain cases, the binding name may be different from the node name, * if the node name does not name a specific device driver. * ddi_get_name is a synonym for ddi_binding_name(). * ddi_dev_is_needed tells system that a device is about to use a * component. Returns when component is ready. * check if DDI_SUSPEND may result in power being removed from a device. * (Obsolete) power entry point * ddi_get_parent requires that the branch of the tree with the * node be held (ddi_hold_installed_driver) or that the devinfo tree * ddi_get_child and ddi_get_next_sibling require that the devinfo * dev_info manipulation functions * Add and remove child devices. These are part of the system framework. * ddi_add_child creates a dev_info structure with the passed name, * nodeid and instance arguments and makes it a child of pdip. Devices * that are known directly by the hardware have real nodeids; devices * that are software constructs use the defined DEVI_PSEUDO_NODEID * ddi_remove_node removes the node from the tree. This fails if this * child has children. Parent and driver private data should already * be released (freed) prior to calling this function. If flag is * non-zero, the child is removed from it's linked list of instances. * Given the major number for a driver, make sure that dev_info nodes * are created form the driver's hwconf file, the driver for the named * device is loaded and attached, as well as any drivers for parent devices. * Return a pointer to the driver's dev_ops struct with the dev_ops held. * Note - Callers must release the dev_ops with ddi_rele_driver. * When a driver is held, the branch of the devinfo tree from any of the * drivers devinfos to the root node are automatically held. This only * applies to tree traversals up (and back down) the tree following the * Use of this interface is discouraged, it may be removed in a future release. * Attach and hold the specified instance of a driver. The flags argument * Associate a streams queue with a devinfo node * Given the identifier string passed, make sure that dev_info nodes * are created form the driver's hwconf file, the driver for the named * device is loaded and attached, as well as any drivers for parent devices. * Note that the driver is not held and is subject to being removed the instant * this call completes. You probably really want ddi_hold_installed_driver. * Routines that return specific nodes * Given a name and an instance number, find and return the * dev_info from the current state of the device tree. * If instance number is -1, return the first named instance. * If attached is 1, exclude all nodes that are < DS_ATTACHED * Requires that the devinfo tree be locked. * If attached is 1, the driver must be held. * Synchronization of I/O with respect to various * caches and system write buffers. * Done at varying points during an I/O transfer (including at the * removal of an I/O mapping). * Due to the support of systems with write buffers which may * not be able to be turned off, this function *must* used at * any point in which data consistency might be required. * Generally this means that if a memory object has multiple mappings * (both for I/O, as described by the handle, and the IU, via, e.g. * a call to ddi_dma_kvaddrp), and one mapping may have been * used to modify the memory object, this function must be called * to ensure that the modification of the memory object is * complete, as well as possibly to inform other mappings of * the object that any cached references to the object are * now stale (and flush or invalidate these stale cache references * The function ddi_dma_sync() provides the general interface with * respect to this capability. Generally, ddi_dma_free() (below) may * be used in preference to ddi_dma_sync() as ddi_dma_free() calls * Returns 0 if all caches that exist and are specified by cache_flags * are successfully operated on, else -1. * The argument offset specifies an offset into the mapping of the mapped * object in which to perform the synchronization. It will be silently * truncated to the granularity of underlying cache line sizes as * The argument len specifies a length starting from offset in which to * perform the synchronization. A value of (uint_t) -1 means that the length * proceeds from offset to the end of the mapping. The length argument * will silently rounded up to the granularity of underlying cache line * The argument flags specifies what to synchronize (the device's view of * the object or the cpu's view of the object). * Inquiring minds want to know when ddi_dma_sync should be used: * + When an object is mapped for dma, assume that an * implicit ddi_dma_sync() is done for you. * + When an object is unmapped (ddi_dma_free()), assume * that an implicit ddi_dma_sync() is done for you. * + At any time between the two times above that the * memory object may have been modified by either * the DMA device or a processor and you wish that * the change be noticed by the master that didn't * Clearly, only the third case above requires the use of ddi_dma_sync. * Inquiring minds also want to know which flag to use: * + If you *modify* with a cpu the object, you use * ddi_dma_sync(...DDI_DMA_SYNC_FORDEV) (you are making sure * that the DMA device sees the changes you made). * + If you are checking, with the processor, an area * of the object that the DMA device *may* have modified, * you use ddi_dma_sync(....DDI_DMA_SYNC_FORCPU) (you are * making sure that the processor(s) will see the changes * that the DMA device may have made). * Return the allowable DMA burst size for the object mapped by handle. * The burst sizes will returned in an integer that encodes power * of two burst sizes that are allowed in bit encoded format. For * example, a transfer that could allow 1, 2, 4, 8 and 32 byte bursts * would be encoded as 0x2f. A transfer that could be allowed as solely * a halfword (2 byte) transfers would be returned as 0x2. * Allocate memory for DMA transfers * bind address to a DMA handle * bind buffer to DMA handle * unbind mapping object to handle * get number of DMA windows * get specific DMA window * activate 64 bit SBus support * Miscellaneous functions * ddi_report_dev: Report a successful attach. * If the device has h/w register(s), report * the size, in bytes, of the specified one into *resultp. * Returns DDI_FAILURE if there are not registers, * or the specified register doesn't exist. * If the device has h/w register(s), report * how many of them that there are into resultp. * Return DDI_FAILURE if the device has no registers. * If the device is self-identifying, i.e., * has already been probed by a smart PROM * (and thus registers are known to be valid) * return DDI_SUCCESS, else DDI_FAILURE. * If the device is on a bus that precludes * the device from being either a dma master or * a dma slave, return DDI_SUCCESS. * Report, via DDI_SUCCESS, whether there exists * an 'affinity' between two dev_info_t's. An * affinity is defined to be either a parent-child, * or a sibling relationship such that the siblings * or in the same part of the bus they happen to be * Set a function/arg pair into the callback list identified * by listid. *listid must always initially start out as zero. * Run the callback list identified by listid. * DDI wrappers for ffs and fls * The next five routines comprise generic storage management utilities * for driver soft state structures. * Allocate a set of pointers to 'n_items' objects of size 'size' * bytes. Each pointer is initialized to nil. 'n_items' is a hint i.e. * Allocate a state structure of size 'size' to be associated * Fetch a pointer to the allocated soft state structure * corresponding to 'item.' * Free the state structure corresponding to 'item.' * Free the handle, and any associated soft state structures. * Set the addr field of the name in dip to name * Get the address part of the name. * High resolution system timer functions. * These functions are already in the kernel (see sys/time.h). * The ddi supports the notion of a hrtime_t type and the * functions gethrtime, hrtadd, hrtsub and hrtcmp. * Nexus wrapper functions * These functions are for entries in a bus nexus driver's bus_ops * structure for when the driver doesn't have such a function and * doesn't wish to prohibit such a function from existing. They * may also be called to start passing a request up the dev_info * dvma support for networking drivers * Send signals to processes /* I/O port access routines */ * Fault-related functions * Miscellaneous redefines * utilities - "reg" mapping and all common portable data access functions * error code from ddi_regs_map_setup * Device address advance flags * these are the prototypes for the common portable data access functions * these are special device handling functions * these are software byte swapping functions * these are the prototypes for PCI local bus functions * PCI power management capabilities reporting in addition to those * provided by the PCI Power Management Specification. * the prototype for the C Language Type Model inquiry. * these are the prototypes for device id functions. * Event to post to when a devinfo node is removed. * Invoke bus nexus driver's implementation of the * (*bus_remove_eventcall)() interface to remove a registered * callback handler for "event". * Invoke bus nexus driver's implementation of the * (*bus_add_eventcall)() interface to register a callback handler * Return a handle for event "name" by calling up the device tree * hierarchy via (*bus_get_eventcookie)() interface until claimed * by a bus nexus or top of dev_info tree is reached. * ddi_log_sysevent() vendors * Opaque task queue handle. * Use default system priority. * Dispatch a task to a task queue * Wait for all previously scheduled tasks to complete. * Suspend all task execution. * Is task queue suspended? * Parse an interface name of the form <alphanumeric>##<numeric> where #
endif /* _SYS_SUNDDI_H */