/linux-4.1.27/drivers/infiniband/core/ |
D | packer.c | 39 static u64 value_read(int offset, int size, void *structure) in value_read() argument 42 case 1: return *(u8 *) (structure + offset); in value_read() 43 case 2: return be16_to_cpup((__be16 *) (structure + offset)); in value_read() 44 case 4: return be32_to_cpup((__be32 *) (structure + offset)); in value_read() 45 case 8: return be64_to_cpup((__be64 *) (structure + offset)); in value_read() 64 void *structure, in ib_pack() argument 80 structure) << shift; in ib_pack() 97 structure) << shift; in ib_pack() 115 structure + desc[i].struct_offset_bytes, in ib_pack() 127 static void value_write(int offset, int size, u64 val, void *structure) in value_write() argument [all …]
|
/linux-4.1.27/arch/arm/nwfpe/ |
D | ChangeLog | 12 - remove userRegisters pointer from this structure. 18 * The FPA11 structure is not a kernel-specific data structure. 21 FPA11 structure (size or position of elements contained 24 * Since 128-bit float requires the FPA11 structure to change 27 overflow the available space in the task structure. 36 * fpa11.c - Changes due to FPA11, FPREG structure alterations. 37 * fpa11_cpdo.c - Changes due to FPA11, FPREG structure alterations. 38 * fpa11_cpdt.c - Changes due to FPA11, FPREG structure alterations. 39 * fpa11_cprt.c - Changes due to FPA11, FPREG structure alterations. 40 * single_cpdo.c - Changes due to FPA11, FPREG structure alterations. [all …]
|
/linux-4.1.27/Documentation/powerpc/ |
D | qe_firmware.txt | 89 structure signals the microcode which of these virtual traps is active. 91 This structure contains 6 words that the application should copy to some 92 specific been defined. This table describes the structure. 121 and has special instructions for the s/w associated with it. This structure is 183 This structure supports versioning, where the version of the structure is 184 embedded into the structure itself. To ensure forward and backwards 185 compatibility, all versions of the structure must use the same 'qe_header' 186 structure at the beginning. 189 The 'length' field is the size, in bytes, of the entire structure, 195 structure is a QE Firmware structure. [all …]
|
D | ptrace.txt | 25 The query will fill the following structure provided by the requesting process: 47 Sets a hardware breakpoint or watchpoint, according to the provided structure: 89 Some examples of using the structure to:
|
D | firmware-assisted-dump.txt | 250 o The fadump implementation introduces a fadump crash info structure 252 this structure is to pass some important crash info data to the second 256 additional fields (in future) to this structure without affecting 260 whenever a new field is added to the structure in future. The version 262 version of the structure. 264 structure and have unused area as reserved (initialized to zero)
|
D | bootwrapper.txt | 30 bd_info structure and loads the data into the device 33 bd_info structure used in the old U-Boot interfaces, 41 the wrapper structure. 89 vmlinux in the uImage data structure. This image
|
D | cxl.txt | 189 Indicates which optional fields in the structure are 195 address pointing to an AFU specific structure 294 structure is defined as: 313 structure is defined as: 342 If the event type is CXL_EVENT_AFU_ERROR then the event structure
|
D | cpu_features.txt | 25 index, structure dereference, and conditional branch were added. To avoid the
|
/linux-4.1.27/Documentation/ioctl/ |
D | cdrom.txt | 62 DVD_READ_STRUCT Read structure 63 DVD_WRITE_STRUCT Write structure 133 cdrom_msf structure, describing a segment of music to play 157 cdrom_ti structure, describing a segment of music to play 178 cdrom_tochdr structure 181 cdrom_tochdr structure 196 cdrom_tocentry structure 199 cdrom_tocentry structure 297 cdrom_volctrl structure containing volumes for up to 4 333 cdrom_subchnl structure [all …]
|
D | botching-up-ioctls.txt | 37 * Pad the entire struct to a multiple of 64-bits - the structure size will 38 otherwise differ on 32-bit versus 64-bit. Having a different structure size 40 checks the structure size, which e.g. the drm core does. 62 the structure. The drm core checks the passed-in size for each ioctl call
|
/linux-4.1.27/Documentation/ |
D | unshare.txt | 182 with the current task structure and releases corresponding shared 186 structure, where as unshare operates on the current active 196 new namespace structure, the error return code will have to 199 structure, which may not exist anymore. 202 current context structure was moved into new dup_* functions. Now, 205 task structure that is being constructed. unshare system call on 208 2) For each context structure, call the corresponding unshare 210 structure, if the appropriate bit is set in the flags argument. 212 are new context structures then lock the current task structure, 213 associate new context structures with the current task structure, [all …]
|
D | padata.txt | 11 The first step in using padata is to set up a padata_instance structure for 98 padata_priv structure: 106 This structure will almost certainly be embedded within some larger 107 structure specific to the work to be done. Most of its fields are private to 108 padata, but the structure should be zeroed at initialisation time, and the 131 function gets the padata_priv structure pointer as its lone parameter; 133 container_of() to find the enclosing structure. 146 serial() function in the padata_priv structure. That call will happen on
|
D | media-framework.txt | 44 include/media/media-device.h. Allocation of the structure is handled by the 46 larger driver-specific structure. 52 The caller is responsible for initializing the media_device structure before 100 include/media/media-entity.h. The structure is usually embedded into a 101 higher-level structure, such as a v4l2_subdev or video_device instance, 116 pads array in a driver-specific structure, avoiding dynamic allocation. 179 driver-specific structure. 182 Both information are stored in the media_pad structure, making the media_pad 250 The graph structure, provided by the caller, is initialized to start graph 260 required and the graph structure can be freed normally. [all …]
|
D | kobject.txt | 25 usually embedded within some other structure which contains the stuff 28 No structure should EVER have more than one kobject embedded within it. 32 - A ktype is the type of object that embeds a kobject. Every structure 59 direct expression of inheritance, so other techniques - such as structure 67 So, for example, the UIO code in drivers/uio/uio.c has a structure that 75 If you have a struct uio_map structure, finding its embedded kobject is 78 what is the pointer to the containing structure? You must avoid tricks 79 (such as assuming that the kobject is at the beginning of the structure) 87 * "type" is the type of the containing structure, and 88 * "member" is the name of the structure field to which "pointer" points. [all …]
|
D | unaligned-memory-access.txt | 76 structure: 84 Let us assume that an instance of the above structure resides in memory 88 structure, i.e. address 0x10002, but that address is not evenly divisible 93 Therefore, for standard structure types you can always rely on the compiler 106 that you could reorder the fields in the structure in order to place fields 108 resident memory size of structure instances. The optimal layout of the 118 byte of padding at the end of the structure. This padding is added in order 122 structure type. This GCC-specific attribute tells the compiler never to 133 structure padding is of importance.
|
D | kernel-doc-nano-HOWTO.txt | 50 or data structure being described. 86 Example kernel-doc data structure comment. 89 * struct blah - the basic blah structure 94 * Longer description of this structure. 100 The kernel-doc data structure comments describe each structure member 101 in the data structure, with the @name lines. 241 '&struct_name' - name of a structure (up to two words including 'struct')
|
D | kref.txt | 18 The kref can occur anywhere within the data structure. 39 If you already have a valid pointer to a kref-ed structure (the 46 a valid pointer to a kref-ed structure without already 50 3) If the code attempts to gain a reference to a kref-ed structure 53 structure must remain valid during the kref_get().
|
D | magic-number.txt | 2 add a magic number to a structure, you should also add it to this 7 numbers. This allows you to check at run time whether (a) a structure 8 has been clobbered, or (b) you've passed the wrong structure to a 15 the structure, like so:
|
D | IRQ-domain.txt | 44 provide the allocator function with an irq_domain_ops structure. 167 hardware architecture, an irq_domain data structure is built for each 170 child and the irq_domain near to CPU is parent. So a hierarchy structure 200 irq_domain structure is built for each interrupt controller, and an 201 irq_data structure is allocated for each irq_domain associated with an
|
D | pnp.txt | 150 structure 153 - call this to initialize the PnP structure 214 3.) create a driver structure
|
D | rbtree.txt | 50 structures, each instance of struct rb_node is embedded in the data structure 67 structure may be accessed with the standard container_of() macro. In addition, 70 At the root of each rbtree is an rb_root structure, which is initialized to be 177 of the tree, which will return a pointer to the node structure contained in 183 which the containing data structure may be accessed with the container_of()
|
D | robust-futex-ABI.txt | 40 The pointer 'head' points to a structure in the threads address space 53 The first word in the memory structure at 'head' contains a 102 robust_futex mechanism doesn't care what else is in that structure, so 126 A given futex lock structure in a user shared memory region may be held
|
D | vme_api.txt | 16 A pointer to a structure of type 'vme_driver' must be provided to the 17 registration function. The structure is as follows: 31 At the minimum, the '.name', '.match' and '.probe' elements of this structure 51 'struct vme_dev' structure looks like the following: 79 device structure. This pointer should be saved, it will be required for
|
D | xillybus.txt | 100 data structure which completely defines the core's configuration. The Linux 101 driver fetches this data structure during its initialization process, and sets 105 The data structure just mentioned should not be confused with PCI's 140 "channel" structure in the implementation code). 193 xilly_endpoint_hardware structure is passed to the core module on 194 initialization. This structure is populated with pointers to wrapper functions 201 (IP core) is built. They are fetched from the IDT (the data structure which
|
D | eisa.txt | 37 Every function/structure below lives in <linux/eisa.h>, which depends 45 root of an EISA bus. The eisa_root_device structure holds a reference
|
D | highuid.txt | 5 structure.
|
D | this_cpu_ops.txt | 168 Operations on a field of a per cpu structure 171 Let's say we have a percpu structure 281 To access per-cpu data structure remotely, typically the per_cpu_ptr()
|
/linux-4.1.27/Documentation/filesystems/ |
D | files.txt | 25 table are in a separate structure - struct fdtable. 29 expansion of fdtable, a new fdtable structure is allocated 30 and files->fdtab points to the new structure. The fdtable 31 structure is freed with RCU and lock-free readers either 34 the fdtable structure - 61 4. To look up the file structure given an fd, a reader 79 file structure. This is avoided using atomic_long_inc_not_zero()
|
D | seq_file.txt | 97 The entire data structure for this iterator is a single loff_t value 104 structure can be used. There is also a special value which can be returned 113 modules will do what is needed to step through some data structure. The 150 seq_file iterator is finished by creating a seq_operations structure with 160 This structure will be needed to tie our iterator to the /proc file in 233 Here, the call to seq_open() takes the seq_operations structure we created 239 private field of the seq_file structure; that value can then be retrieved 244 private field of the seq_file structure, returning 0 on success. The 277 file_operations structure will look like: 288 seq_file private field to kfree() before releasing the structure. [all …]
|
D | xfs-self-describing-metadata.txt | 8 scalability, but of verification of the filesystem structure. Scalabilty of the 16 structure in different ways. While this is already done by userspace tools for 17 validating and repairing the structure, there are limits to what they can 21 scripting to analyse the structure of a 100TB filesystem when trying to 33 required for basic forensic analysis of the filesystem structure. 188 A typical on-disk structure needs to contain the following information: 199 Depending on the metadata, this information may be part of a header structure 201 structure. The latter occurs with metadata that already contains some of this 209 information as @owner and @blkno in eh above structure, but using 8 320 This will verify the internal structure of the metadata before we go any [all …]
|
D | dnotify.txt | 29 kernel know which signal to deliver, a siginfo structure will be passed to 30 the signal handler and the si_fd member of that structure will contain the
|
D | autofs4-mount-control.txt | 172 All the ioctls use a common structure to pass the needed parameter 199 is used account for the increased structure length when translating the 200 structure sent from user space. 202 This structure can be initialized before setting specific fields by using 205 All of the ioctls perform a copy of this structure from user space to 207 the structure size itself, -ENOMEM if the kernel memory allocation fails 211 the structure size then a path is assumed to be present and is checked to 237 input parameter and sets the version information in the passed in structure. 248 and sets the requested version number in structure field arg1. These
|
D | omfs.txt | 84 A file is an omfs_inode structure followed by an extent table beginning at 105 e_next. These have a header but lack the rest of the inode structure.
|
D | fiemap.txt | 66 which userspace must allocate along with the fiemap structure. The 77 Each extent is described by a single fiemap_extent structure as 178 their inode_operations structure. The fs ->fiemap call is responsible for 199 structure directly. Filesystem handlers should be tolerant to signals and return
|
D | qnx6.txt | 44 (or period) and building up a new (stable) filesystem structure under the 77 The inode structure contains pointers to the filesystem blocks which contain 132 If that structure shall fit for all allowed blocksizes, it is clear why there
|
D | automount-support.txt | 18 structure (vfsmount and dentry). 23 superblock and gain a vfsmount structure representing it.
|
D | debugfs.txt | 48 resulting inode structure, and fops is a set of file operations which 104 this structure and function: 116 debugfs_blob_wrapper structure. Some drivers use "blobs" as a simple way
|
D | coda.txt | 280 upcall is dispatched to Venus by creating a message structure. The 281 structure contains the identification of P, the message sequence 288 synchronization objects. In the upcall routine the message structure 291 data buffer; its structure will be described in the next section. 300 message structure will locate the synchronization object on which P is 333 deallocate the message structure and return. The FS routine can proceed 353 extra field "handle_signals" could be added in the message structure 423 The CodaCred structure defines a variety of user and group ids as 427 semantics for Coda but the structure may have to undergo modification 464 The next important structure shared between Venus and the kernel is [all …]
|
D | vfs.txt | 71 structure (this is the kernel-side implementation of file 72 descriptors). The freshly allocated file structure is initialized with 77 structure is placed into the file descriptor table for the process. 81 file structure, and then calling the required file structure method to 172 The most interesting member of the superblock structure that the 189 struct super_block *sb: the superblock structure. The callback 243 alloc_inode will be used to allocate a larger structure which 382 dentry. The "i_count" field in the inode structure should be 568 Writeback makes use of a writeback_control structure... 860 open method for the newly allocated file structure. You might [all …]
|
D | quota.txt | 6 number of used inodes (inode is a filesystem structure which is associated with
|
D | f2fs.txt | 35 a log-like structure, thereby speeding up both file writing and crash recovery. 36 The log is the only structure on disk; it contains indexing information so that 67 3. It checks the cross-reference between the data and its parent index structure. 407 The key data structure to manage the data locations is a "node". Similar to 469 F2FS implements multi-level hash tables for directory structure. Each level has
|
/linux-4.1.27/Documentation/devicetree/bindings/clock/st/ |
D | st,flexgen.txt | 1 Binding for a type of flexgen structure found on certain 4 This structure includes: 8 Flexgen structure is a part of Clockgen[1]. 14 | Flexgen structure |
|
/linux-4.1.27/drivers/message/fusion/lsi/ |
D | mpi_history.txt | 106 * 05-24-00 00.10.02 Added _MSG_IOC_INIT_REPLY structure. 108 * 06-12-00 01.00.02 Added _MSG_PORT_ENABLE_REPLY structure. 109 * Added _MSG_EVENT_ACK_REPLY structure. 110 * Added _MSG_FW_DOWNLOAD_REPLY structure. 111 * Added _MSG_TOOLBOX_REPLY structure. 112 * 06-30-00 01.00.03 Added MaxLanBuckets to _PORT_FACT_REPLY structure. 113 * 07-27-00 01.00.04 Added _EVENT_DATA structure definitions for _SCSI, 116 * _MSG_EVENT_ACK_REPLY structure to match specification. 128 * Added structure offset comments. 129 * 04-09-01 01.01.07 Added structure EVENT_DATA_EVENT_CHANGE. [all …]
|
/linux-4.1.27/Documentation/hid/ |
D | hiddev.txt | 85 the value that it was changed to. Note that the structure is defined 107 hiddev_devinfo structure. 119 Gets a hiddev_devinfo structure which describes the device. 148 Fills in a hiddev_report_info structure for the user. The report is 157 filled into the returned hiddev_report_info structure. 161 hiddev_field_info structure. The user must fill in report_id and 162 report_type in this structure, as above. The field_index should also 167 Returns the usage_code in a hiddev_usage_ref structure, given that 169 field have already been filled into the structure. 172 Returns the value of a usage in a hiddev_usage_ref structure. The [all …]
|
/linux-4.1.27/Documentation/devicetree/ |
D | todo.txt | 3 === General structure === 4 - Switch from custom lists to (h)list_head for nodes and properties structure
|
D | of_unittest.txt | 19 from the unflattened device tree data structure. This interface is used by 55 Un-flattened device tree structure: 58 structure described below. 69 Figure 1, describes a generic structure of machine's un-flattened device tree 98 Figure 1: Generic structure of un-flattened device tree 136 data node is attached to the live tree above (Figure 1), the final structure is 172 Figure 3: Live device tree structure after attaching the testcase-data. 176 sibling compared to the earlier structure (Figure 2). After attaching first
|
D | 00-INDEX | 1 Documentation for device trees, a data structure by which bootloaders pass
|
D | booting-without-of.txt | 23 3) Device tree "structure" block 85 OF_DT_END_NODE in structure definition. 103 structure 263 option. This file will define a structure of type "ppc_md" 343 that is roughly described in include/linux/of_fdt.h by the structure 349 u32 off_dt_struct; /* offset to structure */ 363 u32 size_dt_struct; /* size of the DT structure block */ 394 the device-tree structure, strings, and the memory reserve map. 399 of the "structure" part the device tree. (see 2) device tree) 427 This is the version of this structure. Version 1 stops [all …]
|
/linux-4.1.27/Documentation/ABI/stable/ |
D | sysfs-firmware-efi-vars | 41 a structure that contains everything 43 For structure definition see "struct 50 match byte for byte with the structure 54 **Note** the efi_variable structure
|
D | sysfs-module | 3 The /sys/module tree consists of the following structure:
|
/linux-4.1.27/Documentation/virtual/kvm/ |
D | msr.txt | 20 structure: 54 a copy of the following structure: 69 updates of this structure is arbitrary and implementation-dependent. 70 The hypervisor may update this structure at any time it sees fit until 80 of the update of this structure. Guests can subtract this value 82 structure update. 85 time at the time this structure was last updated. Unit is 205 hold a copy of the following structure: 216 updates of this structure is arbitrary and implementation-dependent. 217 The hypervisor may update this structure at any time it sees fit until [all …]
|
D | nested-vmx.txt | 71 As a VMX implementation, nested VMX presents a VMCS structure to L1. 73 this structure is *opaque* to its user, who is not supposed to know or care 74 about its internal structure. Rather, the structure is accessed through the 77 internals of this structure; This is struct vmcs12 from arch/x86/kvm/vmx.c. 85 of this structure changes, this can break live migration across KVM versions.
|
D | api.txt | 254 memory slot. Ensure the entire structure is cleared to avoid padding 326 See KVM_GET_REGS for the data structure. 841 See KVM_GET_VCPU_EVENTS for the data structure. 885 See KVM_GET_DEBUGREGS for the data structure. The flags field is unused 1205 Userspace invokes KVM_GET_SUPPORTED_CPUID by passing a kvm_cpuid2 structure 1263 If any additional field gets added to this structure later on, a bit for that 1331 See KVM_ASSIGN_PCI_DEVICE for the data structure. Only assigned_dev_id is 1390 See KVM_ASSIGN_DEV_IRQ for the data structure. The target device is specified 1661 See KVM_ASSIGN_DEV_IRQ for the data structure. The target device is specified 1727 the argument structure. [all …]
|
D | mmu.txt | 39 pte page table entry (used also to refer generically to paging structure 105 The principal data structure is the shadow page, 'struct kvm_mmu_page'. A 113 one paging structure entry. These are always the lowest level of the 183 at the shadow page structure. 187 The spt array forms a DAG structure with the shadow page as a node, and 203 structure with a list of parent_ptes.
|
/linux-4.1.27/scripts/coccinelle/free/ |
D | kfreeaddr.cocci | 1 /// Free of a structure field 31 msg = "ERROR: kfree of structure field"
|
/linux-4.1.27/Documentation/watchdog/ |
D | watchdog-kernel-api.txt | 32 The parameter of this routine is a pointer to a watchdog_device structure. 37 watchdog_device structure. 39 The watchdog device structure looks like this: 67 * info: a pointer to a watchdog_info structure. This structure gives some 108 ensure the structure holding the watchdog_device does not go away. 111 1) Add a kref struct to the same structure which is holding the watchdog_device 124 The routine needs a pointer to the watchdog timer device structure as a 127 The routine needs a pointer to the watchdog timer device structure as a 139 The routine needs a pointer to the watchdog timer device structure as a 148 info structure). [all …]
|
D | pcwd-watchdog.txt | 35 returns in structure "PCWDS" which returns:
|
/linux-4.1.27/Documentation/devicetree/bindings/pwm/ |
D | nxp,pca9685-pwm.txt | 13 - open-drain (bool): boolean to configure outputs with open-drain structure; 14 if omitted use totem-pole structure
|
/linux-4.1.27/Documentation/networking/ |
D | secid.txt | 1 flowi structure: 3 The secid member in the flow structure is used in LSMs (e.g. SELinux) to indicate
|
D | lapb-module.txt | 21 Probably the most important structure is the skbuff structure for holding 25 The two LAPB specific structures are the LAPB initialisation structure and 26 the LAPB parameter structure. These will be defined in a standard header 33 This structure is used only once, in the call to lapb_register (see below). 46 Each member of this structure corresponds to a function in the device driver 55 This structure is used with the lapb_getparms and lapb_setparms functions 200 module with lapb_register (see above) in the structure lapb_register_struct
|
D | regulatory.txt | 143 structure and pass it to the wireless core. To do this you should 144 kmalloc() a structure big enough to hold your regulatory domain 145 structure and you should then fill it with your data. Finally you simply 146 call regulatory_hint() with the regulatory domain structure in it. 201 used to generate a data structure encoded in net/wireless/regdb.c.
|
D | gen_stats.txt | 81 space. The value of this TLV should contain a tc_estimator structure. 89 transported to the kernel. Transfer such a structure in a TLV of type
|
D | stmmac.txt | 52 net_device structure enabling the scatter-gather feature. This is true on 162 o enh_desc: if sets the MAC will use the enhanced descriptor structure. 267 by using the stmmac_mdio_bus_data structure (to provide the id, the 281 and the stmmac_of_data structure inside the include/linux/stmmac.h header file. 289 o stmmac.h: private driver structure; 291 o descs.h: descriptor structure definitions;
|
D | phy.txt | 55 driver needs, setup the mii_bus structure, and register with the PAL using 59 4) Like any driver, the device_driver structure must be configured, and init 108 phydev is a pointer to the phy_device structure which represents the PHY. If 112 has one. The phydev structure will be populated with information about the 197 Using variables inside the phydev structure, either configures advertising 203 Fills the phydev structure with up-to-date information about the current
|
D | packet_mmap.txt | 204 this parameter must to have the following structure: 214 This structure is defined in /usr/include/linux/if_packet.h and establishes a 236 we will get the following buffer structure: 293 To understand the constraints of PACKET_MMAP, we have to see the structure 296 Currently, this structure is a dynamically allocated vector with kmalloc 382 Frame structure: 554 in the tpacket2_hdr structure: 1024 tpacket{,2,3}_hdr structure's tp_sec and tp_{n,u}sec members. To determine
|
D | timestamping.txt | 262 The structure can return up to three timestamps. This is a legacy 291 ee_info in the extended error structure. It contains a value of 373 structure to ioctl(SIOCGHWTSTAMP) in the same way. However, this has 421 to the shared time stamp structure of the skb call skb_hwtstamps(). Then 422 set the time stamps in the structure:
|
D | can.txt | 265 The basic CAN frame structure and the sockaddr structure are defined 280 The sockaddr_can structure has an interface index like the 399 all structure elements can be used as-is - only the data[] becomes extended. 438 The CAN filter structure is defined in include/linux/can.h: 451 bit is set in can_id element of the can_filter structure. In 589 provided CAN FD structure. Note that the canfd_frame.flags data field is 596 data structure for CAN_RAW based applications. When the application is 662 The aligned payload 'frames' uses the same basic CAN frame structure defined 664 messages to the broadcast manager from user space have this structure. 1001 Furthermore, the interface uses a common data structure and exports a [all …]
|
D | e100.txt | 57 structure that describes a receive buffer and its attributes to the network 66 structure that describes a transmit buffer and its attributes to the network
|
D | i40e.txt | 37 The driver is located in the menu structure at:
|
/linux-4.1.27/Documentation/hwmon/ |
D | ads7828 | 23 The ads7828 driver accepts an optional ads7828_platform_data structure (defined 24 in include/linux/platform_data/ads7828.h). The structure fields are: 38 If no structure is provided, the configuration defaults to single ended
|
D | hwmon-kernel-api.txt | 65 monitoring device structure. This function must be called from the driver 86 This structure has the following fields. 93 You can use to_sensor_dev_attr to get the pointer to this structure from the 106 Use to_sensor_dev_attr_2 to get the pointer to this structure. Its parameter
|
D | sht15 | 45 Some options may be set directly in the sht15_platform_data structure
|
D | g762 | 21 using a specific platform_data structure in board initialization
|
/linux-4.1.27/arch/m32r/platforms/oaks32r/ |
D | dot.gdbinit.nommu | 58 # Show current task structure 65 # Show user assigned task structure 72 Show user assigned task structure 73 arg0 : task structure address
|
/linux-4.1.27/Documentation/networking/caif/ |
D | spi_porting.txt | 34 a stream of data from the master. The xfer structure contains 56 returned from the platform probe function in the SPI device structure. 65 returned from the platform probe function in the SPI device structure. 69 - Filling in the SPI slave device structure: 75 Assign your private data (can be used to map to your structure). 77 - Filling in the SPI slave platform device structure: 79 Assign the SPI slave device structure as platform data.
|
D | Linux-CAIF.txt | 62 == CAIF structure == 146 - All layers embed the same structure "struct cflayer"
|
/linux-4.1.27/Documentation/isdn/ |
D | INTERFACE.CAPI | 28 capi_driver. This structure must be filled with the name and revision of the 35 struct capi_ctr before they can be used. This structure must be filled with 43 structure of the device, and signal its readiness by calling capi_ctr_ready(). 58 parameter structure provided by the application. This is analogous to the 77 This structure describes a Kernel CAPI driver itself. It is used in the 92 This structure describes an ISDN device (controller) handled by a Kernel CAPI 159 capi_ctr structure is available from struct proc_dir_entry::data 198 The _cmsg structure stores the contents of a CAPI 2.0 message in an easily 237 _cmsg structure members. 241 and their _cmsg structure representation. Note that capi_cmsg2message() does [all …]
|
/linux-4.1.27/Documentation/ABI/testing/ |
D | sysfs-kernel-boot_params | 18 structure in boot_params. setup_data is maintained in kernel 26 The whole boot_params directory structure is like below:
|
D | sysfs-devices | 13 the tree, please use the /sys/class structure and rely
|
D | sysfs-firmware-ofw | 6 hardware, the device tree structure will be exposed in this
|
D | sysfs-firmware-gsmi | 25 this structure.
|
D | sysfs-firmware-memmap | 22 The structure is as follows: Under /sys/firmware/memmap there
|
D | sysfs-bus-event_source-devices-events | 59 corresponding to the <term>) in the perf_event structure passed
|
/linux-4.1.27/Documentation/RCU/ |
D | whatisRCU.txt | 52 within a data structure (possibly by replacing them with references to 56 either the old or the new version of the data structure rather than a 58 (e.g., freeing) the data items removed from the data structure during the 74 a. Remove pointers to a data structure, so that subsequent 81 to the data structure, so it now may safely be reclaimed 89 prevent an updater from deleting the data structure out from under them. 94 and replacement of data items in a linked structure without disrupting 141 read-side critical sections. Any RCU-protected data structure 224 given structure becomes accessible to other CPUs. That said, 257 RCU-protected structure, using the local variable is of [all …]
|
D | checklist.txt | 11 structure is updated more than about 10% of the time, then you 99 a separate structure, so that the change may be made 101 a new structure containing updated values. 146 structure initialization and pointer planting. 157 may be used to replace an old structure with a new one 164 structure happens before pointers to that structure are 166 when publicizing a pointer to a structure that can 244 a. Keeping a count of the number of data-structure elements 245 used by the RCU-protected data structure, including 347 if the callbacks do manipulate a shared data structure, they [all …]
|
D | arrayRCU.txt | 40 semaphore, message-queue, and shared-memory IDs to the data structure 99 a simple check suffices. The pointer to the structure corresponding 125 * was spinning: here verify that the structure is still valid
|
D | trace.txt | 209 CPUs corresponding to this rcu_node structure are 281 These fields are taken from the rcu_state structure, and are as follows: 345 structure. Each line represents one level of the hierarchy, 386 For example, the example rcu_node structure shown above 390 next higher level rcu_node structure that this rcu_node 391 structure corresponds to. For example, the "d/d ..>. 4:7 450 corresponds to a leaf rcu_node structure. The fields are as follows: 478 thread associated with the corresponding rcu_node structure. 482 CPUs corresponding to this rcu_node structure are 515 when there is one blocked task on one rcu_node structure and [all …]
|
D | rcubarrier.txt | 14 carefully, leaving an old version of the data structure in place until all 32 rcu_head struct placed within the RCU-protected data structure and 34 structure. Code to delete an element p from the linked list from IRQ 243 Lines 3 and 4 locate RCU's internal per-CPU rcu_data structure,
|
D | torture.txt | 232 o "rtc": The hexadecimal address of the structure currently visible 236 has changed the structure visible to readers. 281 you notice. The age of a newly allocated structure is zero, 303 as it is only incremented if a torture structure's counter
|
/linux-4.1.27/Documentation/driver-model/ |
D | overview.txt | 17 Traditional driver models implemented some sort of tree-like structure 40 data structure. These fields must still be accessed by the bus layers, 57 front of the pci_dev structure. This is to make people think about what 62 the structure of struct pci_dev, and it should know the structure of struct
|
D | class.txt | 24 The device class structure looks like: 40 Each device class structure should be exported in a header file so it 63 The class is allowed to create a class-specific structure for the 79 sysfs directory structure
|
D | driver.txt | 42 model because the bus they belong to has a bus-specific structure with 82 The driver registers the structure on startup. For drivers that have 84 structure), they would use driver_register and pass a pointer to their 87 Most drivers, however, will have a bus-specific structure and will 90 It is important that drivers register their driver structure as early as 101 made easier. Drivers can ignore the generic structure altogether and
|
D | device.txt | 32 A driver can access the lock in the device structure using: 105 calls device_create_file() on the device structure passed to it, then
|
D | bus.txt | 23 The structure should be exported to drivers in a header file: 46 driver structure.
|
D | porting.txt | 143 device's parent. sysfs exports a directory structure that mirrors 179 structure, and it would be rude to free the device while that is 228 struct device_driver is a simple driver structure that contains a set 242 - Initialize the generic driver structure.
|
/linux-4.1.27/Documentation/rapidio/ |
D | rapidio.txt | 29 structure. The core logical components of the RapidIO subsystem are defined 37 by a rio_mport data structure. This structure contains master port specific 44 independent interface for RapidIO subsystem operations, rio_mport structure 45 includes rio_ops data structure which contains pointers to hardware specific 52 structure. Devices form one global device list and per-network device lists 60 RapidIO subsystem by rio_dev data structure expanded by additional rio_switch 61 data structure, which contains switch specific information such as copy of the 72 data structure. This structure includes lists of all devices and local master 250 is successfully acquired, the enumerator allocates a new rio_dev structure and 257 structure to store switch specific information. Then the switch's vendor ID and [all …]
|
/linux-4.1.27/Documentation/blockdev/drbd/ |
D | data-structure-v9.txt | 1 This describes the in kernel data structure for DRBD-9. Starting with 2 Linux v3.14 we are reorganizing DRBD to use this data structure.
|
/linux-4.1.27/arch/arm/common/ |
D | vlock.S | 57 @ r0: lock structure base 100 @ r0: lock structure base
|
/linux-4.1.27/drivers/staging/iio/Documentation/ |
D | device.txt | 7 The crucial structure for device drivers in iio is iio_dev. 12 where chip_state is a structure of local state data for this instance of 26 pointer to a structure with elements that tend to be fixed for
|
D | inkernel.txt | 32 must pass the iio_map structures and a pointer to its own iio_dev structure 41 The consumer first has to obtain an iio_channel structure from the core
|
D | trigger.txt | 10 allocates a trigger structure. The key elements to then fill in within
|
D | ring.txt | 11 IIO core. Access to the embedding structure is typically done via
|
/linux-4.1.27/arch/m32r/platforms/mappi3/ |
D | dot.gdbinit | 116 # Show current task structure 123 # Show user assigned task structure 130 Show user assigned task structure 131 arg0 : task structure address
|
/linux-4.1.27/arch/m32r/platforms/mappi2/ |
D | dot.gdbinit.vdec2 | 127 # Show current task structure 134 # Show user assigned task structure 141 Show user assigned task structure 142 arg0 : task structure address
|
/linux-4.1.27/Documentation/accounting/ |
D | taskstats.txt | 61 struct taskstats is the common accounting structure for both per-pid and 102 same structure is used for both per-pid and per-tgid stats. 125 accumulates each exiting task's statistics into a process-wide data structure. 142 structure. Userspace will use only the fields of the struct that correspond 157 extending the attributes structure would be worthwhile. 164 loss. This possibility gets compounded when the taskstats structure gets
|
D | delay-accounting.txt | 39 generic data structure to userspace corresponding to per-pid and per-tgid 41 this structure. See
|
D | cgroupstats.txt | 9 structure.
|
/linux-4.1.27/Documentation/dmaengine/ |
D | provider.txt | 68 your hardware. Each DMA controller will require a different structure, 106 relies on the driver filling a structure and registering against the 107 framework. In our case, that structure is dma_device. 110 structure. Any of the usual memory allocators will do, but you'll also 150 Our dma_device structure has a field called cap_mask that holds the 238 Our dma_device structure also requires a few function pointers in 271 dma_async_tx_descriptor structure, that further represents this 274 - This structure can be initialized using the function 276 - You'll also need to set two fields in this structure: 308 structure pointer as an argument, that will detail which [all …]
|
D | client.txt | 58 specific structure. That gives flexibility to client to pass more 65 Please see the dma_slave_config structure definition in dmaengine.h
|
/linux-4.1.27/arch/m32r/platforms/m32700ut/ |
D | dot.gdbinit_200MHz_16MB | 128 # Show current task structure 135 # Show user assigned task structure 142 Show user assigned task structure 143 arg0 : task structure address
|
D | dot.gdbinit_400MHz_32MB | 128 # Show current task structure 135 # Show user assigned task structure 142 Show user assigned task structure 143 arg0 : task structure address
|
D | dot.gdbinit_300MHz_32MB | 128 # Show current task structure 135 # Show user assigned task structure 142 Show user assigned task structure 143 arg0 : task structure address
|
/linux-4.1.27/arch/m32r/platforms/mappi/ |
D | dot.gdbinit | 144 # Show current task structure 151 # Show user assigned task structure 158 Show user assigned task structure 159 arg0 : task structure address
|
D | dot.gdbinit.nommu | 144 # Show current task structure 151 # Show user assigned task structure 158 Show user assigned task structure 159 arg0 : task structure address
|
D | dot.gdbinit.smp | 212 # Show current task structure 219 # Show user assigned task structure 226 Show user assigned task structure 227 arg0 : task structure address
|
/linux-4.1.27/Documentation/filesystems/pohmelfs/ |
D | network_protocol.txt | 3 Basic structure used in network communication is following command: 84 associated @netfs_path_entry data structure, which contains creation 142 when data or metadata were updated. It operates with the following structure: 163 @size - the same plus size of the netfs_inode_info structure. 205 @size - size of the attached capabilities structure.
|
/linux-4.1.27/Documentation/fmc/ |
D | carrier.txt | 6 SPEC card fills a data structure for each SPEC that it drives, and 15 reason the device structure includes a complete copy of the EEPROM 20 The following listing shows the current structure defining a device. 23 at the beginning of the structure. As usual, the minor number will 130 `fmc_operations' structure, which currently is defined like this 194 structure, and for the mezzanine driver the number is only 233 the array. This is the data structure: 247 no structure at all refers to the current carrier_name), the operation 267 provided the carrier_name field in the data structure is left
|
D | API.txt | 23 The data structure that describe a device is detailed in *note FMC 27 The fmc-bus itself takes care of releasing the structure when their use
|
D | mezzanine.txt | 16 structure. This may be needed for high-bandwidth peripherals like fast 80 fields in the `fmc_driver' structure and simple macro definitions. 106 internal structure by means of kernel messages. It is disabled by
|
D | fmc-chardev.txt | 28 golden FPGA file, that features an SDB structure at offset 256 - i.e.
|
/linux-4.1.27/Documentation/block/ |
D | biodoc.txt | 55 2. New flexible and generic but minimalist i/o structure or descriptor 59 2.3 Changes in the request structure 122 move into the block device structure in the future. Some characteristics 256 The flags and rw fields in the bio structure can be used for some tuning 272 requests. Some bits in the bi_rw flags field in the bio structure are 314 the request structure fields) 337 to the device. The cmd block in the request structure has room for filling 342 The request structure flags can be set up to indicate the type of request 365 2. Flexible and generic but minimalist i/o structure/descriptor. 367 2.1 Reason for a new structure and requirements addressed [all …]
|
D | null_blk.txt | 19 - Directly accepts bio data structure and returns them.
|
/linux-4.1.27/Documentation/fb/ |
D | ep93xx-fb.txt | 29 The ep93xxfb_mach_info structure for your board should look like the 48 The ep93xxfb_mach_info structure has a flags field which can be used 88 The setup and teardown devices pass the platform_device structure as
|
D | api.txt | 149 fb_fix_screeninfo and fb_var_screeninfo structure respectively. 222 ioctl with a pointer to a fb_var_screeninfo structure. If the call is 225 Instead of filling the complete fb_var_screeninfo structure manually,
|
/linux-4.1.27/Documentation/serial/ |
D | serial-rs485.txt | 27 The Linux kernel provides the serial_rs485 structure (see [1]) to handle 28 RS485 communications. This data structure is used to set and configure RS485 32 for bindings). The driver is in charge of filling this data structure from
|
D | tty.txt | 15 discipline number and the ldisc structure. At the point of registration the 21 copy of the structure. You must not re-register over the top of the line 31 tty_ldisc structure in the ldisc table counts the number of lines using this 32 discipline. The reference count of the tty_ldisc structure within a tty 69 set_termios() - (optional) Called on termios structure changes. 117 structure:
|
D | driver | 28 the correct port structure (via uart_get_console) and decoding command line 70 The uart_ops structure is the main interface between serial_core and the 429 structure containing both the uart_port entry with their own extensions, 445 allocated structure. devm_* functions are used, so there's no need 454 This returns the gpio structure associated to the modem line index.
|
/linux-4.1.27/Documentation/PCI/ |
D | PCIEBUS-HOWTO.txt | 15 A PCI Express Port is a logical PCI-PCI Bridge structure. There 87 initializes the pcie_port_service_driver data structure, included in 113 driver data structure. 166 The MSI capability structure enables a device software driver to call 213 capability structure except the PCI Express capability structure, in
|
D | pcieaer-howto.txt | 27 extended capability structure providing more robust error reporting. 88 the AER capability structure within its device and to provide callbacks. 114 capability structure. Error information being logged includes storing 126 3.1 Configure the AER capability structure
|
/linux-4.1.27/Documentation/i2c/ |
D | writing-clients | 19 The driver structure 22 Usually, you will implement a single driver structure, and instantiate 23 all clients from it. Remember, a driver structure contains general access 25 provide. A client structure holds device-specific information like the 67 Each client structure has a special `data' field that can point to any 68 structure at all. You should use this to keep device-specific data. 85 Let's say we have a valid client structure. At some time, we will need 167 structure with the device address and driver name, and calling 342 stop bit is sent between transaction. The i2c_msg structure contains
|
D | summary | 39 data in the Client structure. Usually, Driver and Client are more closely
|
/linux-4.1.27/Documentation/scsi/ |
D | scsi-generic.txt | 22 It is based in the sg_header interface structure. 24 an extended version of the sg_header interface structure. 26 It adds the sg_io_hdr interface structure.
|
D | osd.txt | 66 - osd_dev_init() associates a scsi_device with an osd_dev structure 68 (OSD LUN). The osd_dev structure is needed for calling osd_start_request(). 105 osd_request's structure: 107 The OSD standard defines a complex structure of IO segments pointed to by
|
D | libsas.txt | 44 phy structure: 55 phy structure. 124 structure describing your adapter: 141 structure) and holds the SAS address of the host 354 The structure domain_device describes any device in the SAS 358 contents of the domain_device structure, but it never creates
|
D | ChangeLog.megaraid | 9 and re-initialize its internal RAID structure. 85 3. One of member in the data structure of the driver leads unaligne 89 Root Cause: in uioc_t structure, one of member had misaligned and it 109 > The uioc structure used by ioctl is defined by packed, 111 > In a 64 bit structure, the allignment of member doesn't fit 64 bit 113 > In a 32 bit structure, we don't see the message because the allinment 468 "buffer" fields of the mimd_t structure, instead of embedded 32-bit 547 ii. Redundant structure mraid_driver_t removed.
|
D | ChangeLog.lpfc | 41 * Clear host_scribble in the scsi_cmnd structure when failing in 144 * Fixed a memory leak of iocbq structure. For ELS solicited iocbs 243 * Add entries to hba structure to delegate some functionality from 323 direct structure change 332 not free the structure. 401 structure. 411 * Removed sliinit structure and ringinit[] array. 576 the time the host structure was initialized. lpfc_cfg_params 614 * Remove unused portstatistics_t structure. 644 * Added a blocked member to the lpfc_target structure for [all …]
|
D | ChangeLog.ncr53c8xx | 77 - Get data transfer direction from the scsi command structure 94 - Get data transfer direction from the scsi command structure 129 - proc_dir structure no longer needed for kernel >= 2.3.27. 141 - proc_dir structure no longer needed for kernel >= 2.3.27. 152 in the pci_dev structure.
|
/linux-4.1.27/drivers/md/persistent-data/ |
D | Kconfig | 7 Library providing immutable on-disk data structure support for
|
/linux-4.1.27/include/rdma/ |
D | ib_pack.h | 246 void *structure, 252 void *structure);
|
/linux-4.1.27/Documentation/usb/ |
D | anchors.txt | 8 for them. The anchor is a data structure takes care of 17 initialise the data structure.
|
D | callbacks.txt | 5 structure and through the completion handler of URBs a driver submits. 10 The callbacks defined in the driver structure are: 69 usb_set_intfdata(), to associate a data structure with an interface, so
|
D | usbmon.txt | 112 of the URB structure in hexadecimal, but can be a sequence number or any 196 the following structure (its name is made up, so that we can refer to it): 247 The argument is a pointer to the following structure: 276 structure: 285 pointed by hdr contains the next event structure, and the data buffer contains 293 with mmap(2). Its argument is a pointer to the following structure:
|
D | dwc3.txt | 33 per-endpoint data-structure.
|
/linux-4.1.27/Documentation/video4linux/ |
D | videobuf | 59 The driver's data structure describing a V4L2 device should include a 167 In each case, the parameters are the same: q is the queue structure for the 169 structure for this video device, irqlock is an interrupt-safe spinlock to 173 progressive devices), msize is the size of any containing structure used 277 The returned videobuf_dmabuf structure (defined in 316 Step (1) above is done by looking at the driver-managed list_head structure 324 done field (a wait_queue_head_t structure) with waitqueue_active(). 331 scatterlist structure described above. Drivers using the vmalloc() method 344 structure to the actual size of the captured image, set state to
|
D | pxa_camera.txt | 96 b) DMA prepared buffer will have this structure 102 This structure is pointed by dma->sg_cpu.
|
D | README.saa7134 | 63 cards should have .mute field defined in their tuner structure.
|
D | cpia2_overview.txt | 36 a tuple structure containing address/value pairs. The repeat mode is only
|
/linux-4.1.27/drivers/staging/android/ |
D | TODO | 9 kernel internal type. Data structure for this kuid_t is:
|
/linux-4.1.27/Documentation/spi/ |
D | pxa2xx | 87 using the "spi_board_info" structure found in "linux/spi/spi.h". See 91 information via the structure "pxa2xx_spi_chip" found in 146 The pxa2xx_spi_chip structure is passed to the pxa2xx_spi driver in the 215 by setting the "enable_dma" flag in the "pxa2xx_spi_master" structure. The DMA
|
/linux-4.1.27/Documentation/devicetree/bindings/powerpc/fsl/cpm_qe/qe/ |
D | firmware.txt | 10 member of the qe_firmware structure of the uploaded firmware.
|
/linux-4.1.27/arch/arm/vfp/ |
D | entry.S | 23 @ r10 = this threads thread_info structure
|
/linux-4.1.27/Documentation/filesystems/nfs/ |
D | rpc-cache.txt | 10 There are a number of caches that are similar in structure though 39 structure definition that must contain a 45 2/ A cache needs a "cache_detail" structure that 53 structure 110 cache_check can be passed a "struct cache_req *". This structure is
|
/linux-4.1.27/Documentation/security/ |
D | keys-trusted-encrypted.txt | 45 within the 2048 bit SRK (RSA) keylength, with all necessary structure/padding. 57 key or a more complex structure. The format of the more complex structure is
|
D | keys-ecryptfs.txt | 14 The data structure defined by eCryptfs to contain information required for the
|
/linux-4.1.27/Documentation/cma/ |
D | debugfs.txt | 9 The structure of the files created under that directory is as follows:
|
/linux-4.1.27/scripts/coccinelle/api/ |
D | simple_open.cocci | 70 coccilib.report.print_report(pf[0],"WARNING opportunity for simple_open, see also structure on line…
|
/linux-4.1.27/scripts/coccinelle/tests/ |
D | doublebitand.cocci | 5 //# same structure as other similar expressions
|
/linux-4.1.27/Documentation/cpuidle/ |
D | driver.txt | 15 cpuidle driver initializes the cpuidle_device structure for each CPU device
|
/linux-4.1.27/Documentation/misc-devices/mei/ |
D | mei-client-bus.txt | 25 the mei_cl_driver structure: 42 The mei_cl_id structure allows the driver to bind itself against a device name.
|
/linux-4.1.27/Documentation/arm/ |
D | Setup | 5 structure, otherwise known as 'struct param_struct' which is used 8 This structure is used to pass initialisation parameters from the
|
D | CCN.txt | 17 and config2 fields of the perf_event_attr structure. The "events"
|
D | Interrupts | 51 This structure has the following operations: 98 - irqaction structure list
|
/linux-4.1.27/net/rfkill/ |
D | Kconfig | 44 rfkill_gpio_platform_data structure and pass that to the driver.
|
/linux-4.1.27/drivers/net/wan/ |
D | farsync.h | 121 unsigned char structure; /* unframed, double, crc4, f4, f12, */ member
|
/linux-4.1.27/fs/ncpfs/ |
D | ncplib_kernel.c | 352 void ncp_extract_file_info(const void *structure, struct nw_info_struct *target) in ncp_extract_file_info() argument 357 memcpy(target, structure, info_struct_size); in ncp_extract_file_info() 358 name_len = structure + info_struct_size; in ncp_extract_file_info() 367 static inline void ncp_extract_nfs_info(const unsigned char *structure, in ncp_extract_nfs_info() argument 370 target->mode = DVAL_LH(structure); in ncp_extract_nfs_info() 371 target->rdev = DVAL_LH(structure + 8); in ncp_extract_nfs_info()
|
/linux-4.1.27/drivers/staging/slicoss/ |
D | TODO | 26 easily available and shouldn't be kept in card structure, cardnum, ...
|
/linux-4.1.27/scripts/coccinelle/misc/ |
D | badty.cocci | 68 coccilib.org.print_todo(p[0], "WARNING sizeof argument should be pointer type, not structure type")
|
D | doubleinit.cocci | 2 /// positives due to #ifdefs, which Coccinelle is not aware of in a structure
|
/linux-4.1.27/Documentation/locking/ |
D | rt-mutex-design.txt | 99 structure holds a pointer to the task, as well as the mutex that 227 This list is stored in the task structure of a process as a plist called 228 pi_list. This list is protected by a spin lock also in the task structure, 313 The mutex structure contains a pointer to the owner of the mutex. If the 315 have the task structure on at least a four byte alignment (and if this is 380 prio is returned. This is because the prio field in the task structure 498 task's waiter structure "task" element is NULL. This check is 500 sets the task's waiter structure "task" element to NULL with only 524 One of the flags in the owner field of the mutex structure is "Pending Owner". 569 The slow path function is where the task's waiter structure is created on [all …]
|
D | mutex-design.txt | 14 as an alternative to these. This new data structure provided a number 149 for the largest lock in the kernel. Larger structure sizes mean more
|
/linux-4.1.27/Documentation/w1/ |
D | w1.netlink | 129 structure) will be 'acked' by the w1 core. Format of the reply is the same 133 of the w1_netlink_cmd structure and cn_msg.len will be equal to the sum 142 All other fields in every structure will mirror the same parameters in the
|
/linux-4.1.27/Documentation/power/ |
D | opp.txt | 86 intensive operations on data structure as the OPP library caters to. 240 information from the OPP structure is necessary. Once an OPP pointer is 328 struct dev_pm_opp - The internal data structure of OPP library which is used to 331 for the OPP library to operate on. Pointer to this structure is 343 Overall, in a simplistic view, the data structure operations is represented as
|
/linux-4.1.27/Documentation/input/ |
D | notifier.txt | 4 events (see kbd_keycode() function for details). The passed structure is
|
D | input-programming.txt | 83 Then it allocates a new input device structure with input_allocate_device() 96 Then the example driver registers the input device structure by calling 100 This adds the button_dev structure to linked lists of the input driver and
|
D | ff.txt | 99 "effect" points to a structure describing the effect to upload. The effect is 156 struct input_event ie; /* structure used to communicate with the driver */
|
/linux-4.1.27/Documentation/devicetree/bindings/clock/ |
D | rockchip.txt | 13 structure a matter of taste, as either all gates can be put into
|
D | silabs,si5351.txt | 9 3 output clocks are accessible. The internal structure of the clock
|
/linux-4.1.27/tools/perf/Documentation/ |
D | perf-probe.txt | 150 …structure member (e.g. var->field, var.field2), local array with fixed index (e.g. array[1], var->… 152 …debuginfo. You can specify 'string' type only for the local variable or structure member which is …
|
/linux-4.1.27/Documentation/device-mapper/ |
D | kcopyd.txt | 18 of the copy is given as one io_region structure, and the destinations of the
|
D | dm-log.txt | 44 The structure used for communication between kernel and userspace are
|
/linux-4.1.27/Documentation/ia64/ |
D | efirtc.txt | 62 The rtc is a pointer to a data structure defined in rtc.h which is close 107 The wkt structure encapsulates a struct rtc_time + 2 extra fields to get
|
D | fsys.txt | 19 in a pt-regs structure at the top of the kernel memory stack. 66 The "regs" argument is a pointer to a pt_regs structure. The "task" 67 argument is a pointer to the task structure to which the "regs" 114 member of the thread-info structure and if any of the
|
/linux-4.1.27/Documentation/cdrom/ |
D | cdrom-standard.tex | 201 This structure contains information about the low-level driver for a 202 \cdrom\ device. This structure is conceptually connected to the major 206 This structure contains information about a particular \cdrom\ drive, 207 such as its device name, speed, etc. This structure is conceptually 215 The device information structure, $<device>_info$, contains all the 218 structure is a pointer to the $cdrom_device_ops$ structure of the 221 The device operations structure, $cdrom_device_ops$, contains a list 224 through the functions in this structure. It is impossible to know all 302 structure. 322 which can point to a data structure specific to the low-level driver. [all …]
|
/linux-4.1.27/Documentation/filesystems/configfs/ |
D | configfs.txt | 141 Generally, struct config_item is embedded in a container structure, a 142 structure that actually represents what the subsystem is doing. The 143 config_item portion of that structure is how the object interacts with 229 The config_group structure contains a config_item. Properly configuring 249 config_item (or more likely, its container structure), initializes it, 336 and config_item->ci_parent structure members. 401 NULL-terminated array default_groups on the config_group structure.
|
/linux-4.1.27/Documentation/timers/ |
D | hrtimers.txt | 40 example: that the timer wheel data structure is too rigid for high-res 85 - data structure not bound to jiffies or any other granularity. All the 93 data structure. Rbtrees are available as a library in the kernel and are
|
D | timer_stats.txt | 7 data structure overhead. Even if collection is enabled runtime all the
|
/linux-4.1.27/Documentation/power/regulator/ |
D | machine.txt | 41 for each regulator power domain. This structure also maps the consumers
|
/linux-4.1.27/Documentation/leds/ |
D | leds-lp55xx.txt | 23 In lp55xx common driver, two different data structure is used. 45 To support device specific configurations, special structure
|
D | leds-lp5562.txt | 67 To configure the platform specific data, lp55xx_platform_data structure is used.
|
/linux-4.1.27/Documentation/thermal/ |
D | exynos_thermal | 69 described through structure exynos_tmu_registers. Also several
|
D | sysfs-api.txt | 127 This structure defines the following parameters that are used to bind 147 This structure defines the platform level parameters for a thermal zone. 160 2. sysfs attributes structure 324 method, the sys I/F structure will be built like this:
|
/linux-4.1.27/Documentation/netlabel/ |
D | lsm_interface.txt | 20 'netlbl_lsm_secattr' structure in the NetLabel header file. Internally the
|
/linux-4.1.27/scripts/coccinelle/iterators/ |
D | use_after_iter.cocci | 3 /// and not a meaningful structure. Thus this value should not be used after
|
/linux-4.1.27/Documentation/vm/ |
D | numa_memory_policy.txt | 146 structure, struct mempolicy. Details of this structure will be discussed 300 the structure back to the mempolicy kmem cache when the reference count 305 new policy. When a pointer to a memory policy structure is stored in another 306 structure, another reference is added, as the task's reference will be dropped 347 policy management structure. This requires that we drop this extra 355 shared policies in a tree structure under spinlock, shared policies are
|
/linux-4.1.27/Documentation/filesystems/caching/ |
D | operations.txt | 27 structure. 142 itself. Normally this would be part of a more specific structure with the
|
/linux-4.1.27/Documentation/kbuild/ |
D | kconfig-language.txt | 5 organized in a tree structure: 206 Menu structure 225 The other way to generate the menu structure is done by analyzing the 317 This defines a menu block, see "Menu structure" above for more
|
/linux-4.1.27/Documentation/acpi/ |
D | namespace.txt | 14 This document illustrates the structure of the ACPI device tree. 39 data structure called the ACPI namespace whose topology reflects the 40 structure of the underlying hardware platform.
|
/linux-4.1.27/arch/sh/kernel/cpu/sh3/ |
D | swsusp.S | 106 add r3, r15 ! save from top of structure
|
/linux-4.1.27/Documentation/EDID/ |
D | HOWTO.txt | 33 Makefile. Please note that the EDID data structure expects the timing
|
/linux-4.1.27/Documentation/crypto/ |
D | asymmetric-keys.txt | 130 transferred the relevant bits to the structure pointed to by sig. 173 The subtype definition structure can be found in: 240 The parser definition structure can be found in:
|