| /linux/rust/kernel/ |
| H A D | opp.rs | 43 // SAFETY: The requirements are satisfied by the existence of [`Device`] and its safety in new()
44 // requirements. in new()
183 // SAFETY: The requirements are satisfied by the existence of [`Device`] and its safety in new()
184 // requirements. in new()
195 // SAFETY: The requirements are satisfied by the existence of [`Device`] and its safety in drop()
196 // requirements. in drop()
500 // SAFETY: The requirements are satisfied by the existence of [`Device`] and its safety in set()
501 // requirements. The OPP core guarantees not to access fields of [`Config`] after this call in set()
622 // SAFETY: By the safety requirements, ptr is valid and its refcount will be incremented.
638 // SAFETY: The requirements ar
[all...] |
| H A D | configfs.rs | 283 // SAFETY: By impl and function safety requirements this field in group()
348 // SAFETY: By function safety requirements of this function, this call in make_group()
354 // SAFETY: By function safety requirements, name points to a null in make_group()
394 // SAFETY: By function safety requirements of this function, this call in drop_item()
398 // SAFETY: By function safety requirements, `item` is embedded in a in drop_item()
401 // SAFETY: By function safety requirements, `c_child_group_ptr` is in drop_item()
447 // SAFETY: By function safety requirements, `this` is embedded in a in release()
450 // SAFETY: By function safety requirements, `c_group_ptr` is in release()
555 // SAFETY: By function safety requirements, `item` is embedded in a in show()
559 // SAFETY: The function safety requirements fo in show()
[all...] |
| H A D | tracepoint.rs | 9 /// This macro generates an unsafe function that calls into C, and its safety requirements will be
10 /// whatever the relevant C code requires. To document these safety requirements, you may add
|
| /linux/drivers/mtd/nand/raw/ |
| H A D | nand_samsung.c | 14 struct nand_ecc_props requirements = {}; in samsung_nand_decode_id() local
73 /* Extract ECC requirements from 5th id byte*/ in samsung_nand_decode_id()
76 requirements.step_size = 512; in samsung_nand_decode_id()
77 requirements.strength = 1 << extid; in samsung_nand_decode_id()
79 requirements.step_size = 1024; in samsung_nand_decode_id()
82 requirements.strength = 24; in samsung_nand_decode_id()
85 requirements.strength = 40; in samsung_nand_decode_id()
88 requirements.strength = 60; in samsung_nand_decode_id()
92 requirements.step_size = 0; in samsung_nand_decode_id()
102 requirements.step_size = 512; in samsung_nand_decode_id()
[all …]
|
| H A D | nand_esmt.c | 14 struct nand_ecc_props requirements = {}; in esmt_nand_decode_id() local
18 /* Extract ECC requirements from 5th id byte. */ in esmt_nand_decode_id()
20 requirements.step_size = 512; in esmt_nand_decode_id()
23 requirements.strength = 4; in esmt_nand_decode_id()
26 requirements.strength = 2; in esmt_nand_decode_id()
29 requirements.strength = 1; in esmt_nand_decode_id()
33 requirements.step_size = 0; in esmt_nand_decode_id()
38 nanddev_set_ecc_requirements(base, &requirements); in esmt_nand_decode_id()
|
| H A D | nand_toshiba.c | 149 struct nand_ecc_props requirements = {}; in toshiba_nand_decode_id() local
173 * Extract ECC requirements from 6th id byte. in toshiba_nand_decode_id()
180 requirements.step_size = 512; in toshiba_nand_decode_id()
183 requirements.strength = 1; in toshiba_nand_decode_id()
186 requirements.strength = 4; in toshiba_nand_decode_id()
189 requirements.strength = 8; in toshiba_nand_decode_id()
193 requirements.step_size = 0; in toshiba_nand_decode_id()
198 nanddev_set_ecc_requirements(base, &requirements); in toshiba_nand_decode_id()
|
| H A D | nand_micron.c | 416 const struct nand_ecc_props *requirements = in micron_supports_on_die_ecc() local
430 if (requirements->strength != 4 && requirements->strength != 8) in micron_supports_on_die_ecc()
471 if (requirements->strength != 4 && requirements->strength != 8) in micron_supports_on_die_ecc()
480 const struct nand_ecc_props *requirements = in micron_nand_init() local
531 if (requirements->strength == 4) { in micron_nand_init()
541 if (requirements->strength == 4) in micron_nand_init()
548 chip->ecc.bytes = requirements->strength * 2; in micron_nand_init()
550 chip->ecc.strength = requirements->strength; in micron_nand_init()
|
| H A D | nand_onfi.c | 38 struct nand_ecc_props requirements; in nand_flash_detect_ext_param_page() local
99 requirements.strength = ecc->ecc_bits; in nand_flash_detect_ext_param_page()
100 requirements.step_size = 1 << ecc->codeword_size; in nand_flash_detect_ext_param_page()
101 nanddev_set_ecc_requirements(base, &requirements); in nand_flash_detect_ext_param_page()
272 struct nand_ecc_props requirements = { in nand_onfi_detect() local
277 nanddev_set_ecc_requirements(base, &requirements); in nand_onfi_detect()
294 pr_warn("Could not retrieve ONFI ECC requirements\n"); in nand_onfi_detect()
|
| /linux/include/linux/ |
| H A D | zconf.h | 11 /* The memory requirements for deflate are (in bytes):
15 the default memory requirements from 256K to 128K, compile with
19 The memory requirements for inflate are (in bytes) 1 << windowBits
|
| /linux/rust/kernel/drm/ |
| H A D | device.rs | 146 // SAFETY: By the safety requirements of this function `ptr` is a valid pointer to a in from_drm_device()
155 // SAFETY: By the safety requirements of this function, `ptr` is a valid pointer to `Self`. in into_drm_device()
172 // SAFETY: By the safety requirements of this function `ptr` is a valid pointer to a in from_raw()
176 // SAFETY: `ptr` is valid by the safety requirements of this function. in from_raw()
200 // satisfy the requirements.
211 // SAFETY: The safety requirements guarantee that the refcount is non-zero. in dec_ref()
|
| /linux/arch/mips/tools/ |
| H A D | generic-board-config.sh | 8 # generic MIPS kernel. It checks each for requirements specified using
10 # fragments which have no unmet requirements.
12 # An example of requirements in your board config fragment might be:
|
| /linux/Documentation/kbuild/ |
| H A D | Kconfig.recursion-issue-02 | 12 # annotate those requirements, ie, some drivers use "depends on" while others
19 # core requirements are not carefully synced, as drivers evolve features
20 # they select or depend on end up becoming shared requirements which cannot be
|
| /linux/Documentation/ABI/testing/ |
| H A D | sysfs-bus-iio-dma-buffer | 9 This property reports the alignment requirements in bytes.
13 The alignment requirements in number of sample sets will depend
|
| /linux/drivers/gpu/drm/xen/ |
| H A D | xen_drm_front.h | 29 * Depending on the requirements for the para-virtualized environment, namely
30 * requirements dictated by the accompanying DRM/(v)GPU drivers running in both
53 * requirements for display buffers it is possible to allocate such buffers
|
| /linux/rust/kernel/list/ |
| H A D | impl_list_item_mod.rs | 285 // `post_remove`, or `view_value`. By the safety requirements of those methods,
307 // may choose to satisfy the safety requirements of `post_remove` instead of the safety
308 // requirements for `view_value`.
316 // GUARANTEES: (only when using the `view_value` safety requirements)
334 // value is `prepare_to_insert`, but by the safety requirements the
344 // promise the safety requirements of `post_remove` instead of the safety
345 // requirements for `view_value`.
|
| /linux/Documentation/power/regulator/ |
| H A D | design.rst | 15 have different power requirements, and not all components with power
16 requirements are visible to software.
|
| /linux/Documentation/rust/ |
| H A D | quick-start.rst | 20 Alternatively, the next two "Requirements" sections explain each component and
145 Requirements: Building
150 To easily check whether the requirements are met, the following target
254 Requirements: Developing
328 above), as long as the other requirements are met. In turn, this will make
|
| /linux/rust/kernel/alloc/ |
| H A D | allocator.rs | 76 /// This method has the same safety requirements as [`Allocator::realloc`].
107 // - `ptr` is either NULL or valid by the safety requirements of this function. in call()
155 // SAFETY: `ReallocFunc::call` has the same safety requirements as `Allocator::realloc`. in realloc()
200 // - `page` is a valid pointer to a `struct page`, given that by the safety requirements of in to_page()
202 // - By the safety requirements of this function `ptr` is valid for the entire lifetime of in to_page()
|
| /linux/Documentation/power/ |
| H A D | pm_qos_interface.rst | 181 certain protocol requirements or target frame or sample rates etc.
192 latency tolerance requirements for the device is empty, the callback is expected
207 requirements from the kernel side in the device's list.
211 latency tolerance requirements for devices.
|
| /linux/Documentation/security/ |
| H A D | ipe.rst | 24 with these requirements:
76 The minimum requirements for the policy were:
90 considered against these list of requirements, and did not fulfill
91 all of the minimum requirements. Extending IMA to cover these
92 requirements was considered, but ultimately discarded for a
232 to express the first stage bootup requirements appropriately.
237 As requirements change over time (vulnerabilities are found in previously
|
| /linux/Documentation/userspace-api/media/v4l/ |
| H A D | pixfmt-compressed.rst | 47 then the decoder has no requirements since it can parse all the
103 then the decoder has no requirements since it can parse all the
112 then the decoder has no requirements since it can parse all the
203 then the decoder has no requirements since it can parse all the
|
| /linux/Documentation/devicetree/bindings/display/panel/ |
| H A D | olimex,lcd-olinuxino.yaml | 21 - AT24C16C EEPROM holding panel identification and timing requirements
27 device information (id, serial, etc.) and timing requirements.
|
| /linux/Documentation/devicetree/bindings/iio/adc/ |
| H A D | fsl,vf610-adc.yaml | 47 Maximum frequencies from datasheet operating requirements.
59 operating requirements. A safe default across a wide range of R_as and
|
| /linux/Documentation/networking/device_drivers/ethernet/intel/ |
| H A D | igbvf.rst | 23 For questions related to hardware requirements, refer to the documentation
24 supplied with your Intel adapter. All hardware requirements listed apply to use
|
| H A D | ixgbevf.rst | 20 For questions related to hardware requirements, refer to the documentation
21 supplied with your Intel adapter. All hardware requirements listed apply to use
|