| /linux-4.4.14/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.4.14/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.4.14/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 | 192 Indicates which optional fields in the structure are
198 address pointing to an AFU specific structure
297 structure is defined as:
316 structure is defined as:
345 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.4.14/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.4.14/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 | men-chameleon-bus.txt | 17 4.1 The driver structure
107 4.1 The driver structure
109 Each MCB driver has a structure to identify the device driver as well as
110 device ids which identify the IP Core inside the FPGA. The driver structure
|
| 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 | IRQ-domain.txt | 36 structure to hwirq numbers (Device Tree and ACPI GSI so far), and can
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 | 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 | pnp.txt | 150 structure
153 - call this to initialize the PnP structure
214 3.) create a driver structure
|
| D | adding-syscalls.txt | 73 it's preferred to encapsulate the majority of the arguments into a structure
74 that is passed in by pointer. Such a structure can cope with future extension
75 by including a size argument in the structure:
89 code should check that any memory beyond the size of the structure that it
92 code can zero-extend a smaller instance of the structure (effectively
163 structure that's passed in by pointer.)
303 If the system call involves a structure that is laid out differently on 32-bit
305 header file should also include a compat version of the structure (struct
308 compat_sys_xyzzy() routine can then use this compat_ structure to parse the
454 involves a new userspace-visible structure, the corresponding header will need
|
| 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.4.14/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 | 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 | debugfs.txt | 48 resulting inode structure, and fops is a set of file operations which
123 this structure and function:
135 debugfs_blob_wrapper structure. Some drivers use "blobs" as a simple way
|
| 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
570 Writeback makes use of a writeback_control structure...
867 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.
410 The key data structure to manage the data locations is a "node". Similar to
472 F2FS implements multi-level hash tables for directory structure. Each level has
|
| /linux-4.4.14/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.4.14/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.4.14/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.4.14/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.4.14/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.4.14/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
331 See KVM_GET_REGS for the data structure.
862 See KVM_GET_VCPU_EVENTS for the data structure.
909 See KVM_GET_DEBUGREGS for the data structure. The flags field is unused
1237 Userspace invokes KVM_GET_SUPPORTED_CPUID by passing a kvm_cpuid2 structure
1295 If any additional field gets added to this structure later on, a bit for that
1363 See KVM_ASSIGN_PCI_DEVICE for the data structure. Only assigned_dev_id is
1422 See KVM_ASSIGN_DEV_IRQ for the data structure. The target device is specified
1697 See KVM_ASSIGN_DEV_IRQ for the data structure. The target device is specified
1763 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
189 at the shadow page structure.
193 The spt array forms a DAG structure with the shadow page as a node, and
209 structure with a list of parent_ptes.
|
| /linux-4.4.14/scripts/coccinelle/free/ |
| D | kfreeaddr.cocci | 1 /// Free of a structure field
31 msg = "ERROR: kfree of structure field"
|
| /linux-4.4.14/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.
43 The watchdog device structure looks like this:
72 * info: a pointer to a watchdog_info structure. This structure gives some
115 ensure the structure holding the watchdog_device does not go away.
118 1) Add a kref struct to the same structure which is holding the watchdog_device
131 The routine needs a pointer to the watchdog timer device structure as a
134 The routine needs a pointer to the watchdog timer device structure as a
146 The routine needs a pointer to the watchdog timer device structure as a
155 info structure).
[all …]
|
| D | pcwd-watchdog.txt | 35 returns in structure "PCWDS" which returns:
|
| /linux-4.4.14/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.4.14/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 | 6lowpan.txt | 12 To access the LL_PRIV_6LOWPAN_DATA structure you can cast:
16 to your LL_6LOWPAN_PRIV_DATA structure.
|
| 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 | 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 | stmmac.txt | 52 net_device structure enabling the scatter-gather feature. This is true on
158 o enh_desc: if sets the MAC will use the enhanced descriptor structure.
259 by using the stmmac_mdio_bus_data structure (to provide the id, the
279 o stmmac.h: private driver structure;
281 o descs.h: descriptor structure definitions;
|
| 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 | 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 | 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
380 structure to ioctl(SIOCGHWTSTAMP) in the same way. However, this has
428 to the shared time stamp structure of the skb call skb_hwtstamps(). Then
429 set the time stamps in the structure:
|
| D | can.txt | 265 The basic CAN frame structure and the sockaddr structure are defined
283 The sockaddr_can structure has an interface index like the
402 all structure elements can be used as-is - only the data[] becomes extended.
441 The CAN filter structure is defined in include/linux/can.h:
454 bit is set in can_id element of the can_filter structure. In
592 provided CAN FD structure. Note that the canfd_frame.flags data field is
599 data structure for CAN_RAW based applications. When the application is
665 The aligned payload 'frames' uses the same basic CAN frame structure defined
667 messages to the broadcast manager from user space have this structure.
1004 Furthermore, the interface uses a common data structure and exports a
[all …]
|
| /linux-4.4.14/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
|
| /linux-4.4.14/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
36 implement the rs485_config callback in the uart_port structure. The
|
| D | tty.txt | 12 discipline number and the ldisc structure. At the point of registration the
18 copy of the structure. You must not re-register over the top of the line
28 tty_ldisc structure in the ldisc table counts the number of lines using this
29 discipline. The reference count of the tty_ldisc structure within a tty
78 set_termios() - (optional) Called on termios structure changes.
132 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
456 This returns the gpio structure associated to the modem line index.
|
| /linux-4.4.14/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.4.14/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.4.14/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.4.14/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-firmware-dmi-tables | 8 version, DMI table size, etc. The structure, content and
|
| 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-firmware-efi-esrt | 25 Description: The version of the ESRT structure provided by the firmware.
|
| D | sysfs-bus-event_source-devices-events | 59 corresponding to the <term>) in the perf_event structure passed
|
| /linux-4.4.14/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 | 53 structure that represents the corresponding IPC construct. The grow_ary()
111 a simple check suffices. The pointer to the structure corresponding
137 * was spinning: here verify that the structure is still valid
|
| D | trace.txt | 209 CPUs corresponding to this rcu_node structure are
265 These fields are taken from the rcu_state structure, and are as follows:
329 structure. Each line represents one level of the hierarchy,
370 For example, the example rcu_node structure shown above
374 next higher level rcu_node structure that this rcu_node
375 structure corresponds to. For example, the "d/d ..>. 4:7
434 corresponds to a leaf rcu_node structure. The fields are as follows:
462 thread associated with the corresponding rcu_node structure.
466 CPUs corresponding to this rcu_node structure are
499 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 | 219 o "rtc": The hexadecimal address of the structure currently visible
223 has changed the structure visible to readers.
268 you notice. The age of a newly allocated structure is zero,
290 as it is only incremented if a torture structure's counter
|
| /linux-4.4.14/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.4.14/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.4.14/arch/arm/common/ |
| D | vlock.S | 57 @ r0: lock structure base
100 @ r0: lock structure base
|
| /linux-4.4.14/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.4.14/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.4.14/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.4.14/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.4.14/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.4.14/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.4.14/arch/m32r/platforms/m32700ut/ |
| 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_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_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.4.14/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.4.14/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.4.14/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.4.14/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.4.14/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.4.14/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.4.14/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.4.14/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.4.14/drivers/md/persistent-data/ |
| D | Kconfig | 7 Library providing immutable on-disk data structure support for
|
| /linux-4.4.14/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.4.14/include/rdma/ |
| D | ib_pack.h | 248 void *structure,
254 void *structure);
|
| /linux-4.4.14/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.4.14/Documentation/spi/ |
| D | pxa2xx | 81 using the "spi_board_info" structure found in "linux/spi/spi.h". See
85 information via the structure "pxa2xx_spi_chip" found in
140 The pxa2xx_spi_chip structure is passed to the pxa2xx_spi driver in the
209 by setting the "enable_dma" flag in the "pxa2xx_spi_master" structure. The DMA
|
| /linux-4.4.14/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.4.14/Documentation/devicetree/bindings/powerpc/fsl/cpm_qe/qe/ |
| D | firmware.txt | 10 member of the qe_firmware structure of the uploaded firmware.
|
| /linux-4.4.14/arch/arm/vfp/ |
| D | entry.S | 23 @ r10 = this threads thread_info structure
|
| /linux-4.4.14/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.4.14/Documentation/cma/ |
| D | debugfs.txt | 9 The structure of the files created under that directory is as follows:
|
| /linux-4.4.14/scripts/coccinelle/tests/ |
| D | doublebitand.cocci | 5 //# same structure as other similar expressions
|
| /linux-4.4.14/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.4.14/Documentation/cpuidle/ |
| D | driver.txt | 15 cpuidle driver initializes the cpuidle_device structure for each CPU device
|
| /linux-4.4.14/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.4.14/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.4.14/net/rfkill/ |
| D | Kconfig | 45 rfkill_gpio_platform_data structure and pass that to the driver.
|
| /linux-4.4.14/drivers/net/wan/ |
| D | farsync.h | 121 unsigned char structure; /* unframed, double, crc4, f4, f12, */ member
|
| /linux-4.4.14/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.4.14/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.4.14/drivers/staging/slicoss/ |
| D | TODO | 26 easily available and shouldn't be kept in card structure, cardnum, ...
|
| /linux-4.4.14/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.4.14/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.4.14/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.4.14/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.4.14/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
223 The config_group structure contains a config_item. Properly configuring
243 config_item (or more likely, its container structure), initializes it,
320 and config_item->ci_parent structure members.
385 NULL-terminated array default_groups on the config_group structure.
|
| /linux-4.4.14/Documentation/devicetree/bindings/clock/ |
| D | rockchip.txt | 13 structure a matter of taste, as either all gates can be put into
|
| /linux-4.4.14/Documentation/networking/dsa/ |
| D | dsa.txt | 213 structure describes a switch device's parent device, its address, as well as
218 collection of dsa_chip_data structure if multiples switches are cascaded, the
221 dsa_switch_tree: structure assigned to the master network device under
222 "dsa_ptr", this structure references a dsa_platform_data structure as well as
228 dsa_switch: structure describing a switch device in the tree, referencing a
232 dsa_switch_driver: structure referencing function pointers, see below for a full
360 DSA switch drivers need to implement a dsa_switch_driver structure which will
384 up the dsa_switch_driver private structure with all it needs: register maps,
|
| /linux-4.4.14/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.4.14/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.4.14/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.4.14/tools/perf/Documentation/ |
| D | perf-probe.txt | 157 …structure member (e.g. var->field, var.field2), local array with fixed index (e.g. array[1], var->…
159 …debuginfo. You can specify 'string' type only for the local variable or structure member which is …
|
| /linux-4.4.14/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.4.14/Documentation/power/regulator/ |
| D | machine.txt | 41 for each regulator power domain. This structure also maps the consumers
|
| /linux-4.4.14/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.4.14/Documentation/netlabel/ |
| D | lsm_interface.txt | 20 'netlbl_lsm_secattr' structure in the NetLabel header file. Internally the
|
| /linux-4.4.14/scripts/coccinelle/iterators/ |
| D | use_after_iter.cocci | 3 /// and not a meaningful structure. Thus this value should not be used after
|
| /linux-4.4.14/Documentation/thermal/ |
| D | exynos_thermal | 69 described through structure exynos_tmu_registers. Also several
|
| /linux-4.4.14/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.4.14/Documentation/filesystems/caching/ |
| D | operations.txt | 27 structure.
142 itself. Normally this would be part of a more specific structure with the
|
| /linux-4.4.14/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.4.14/Documentation/EDID/ |
| D | HOWTO.txt | 33 Makefile. Please note that the EDID data structure expects the timing
|
| /linux-4.4.14/arch/sh/kernel/cpu/sh3/ |
| D | swsusp.S | 106 add r3, r15 ! save from top of structure
|
| /linux-4.4.14/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:
|
| /linux-4.4.14/Documentation/arm/keystone/ |
| D | knav-qmss.txt | 9 multi-core Navigator. QMSS consist of queue managers, packed-data structure
|