| /linux/rust/kernel/ |
| H A D | opp.rs | 42 // SAFETY: The requirements are satisfied by the existence of [`Device`] and its safety in new()
43 // requirements. in new()
182 // SAFETY: The requirements are satisfied by the existence of [`Device`] and its safety in new()
183 // requirements. in new()
194 // SAFETY: The requirements are satisfied by the existence of [`Device`] and its safety in drop()
195 // requirements. in drop()
499 // SAFETY: The requirements are satisfied by the existence of [`Device`] and its safety in set()
500 // requirements. The OPP core guarantees not to access fields of [`Config`] after this call in set()
624 // SAFETY: By the safety requirements, ptr is valid and its refcount will be incremented. in from_raw_table()
640 // SAFETY: The requirements are satisfied by the existence of the [`Device`] and its safety in from_dev()
[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 for this function satisfy 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
|
| H A D | cpumask.rs | 62 // SAFETY: Guaranteed by the safety requirements of the function. in as_mut_ref()
76 // SAFETY: Guaranteed by the safety requirements of the function. in as_ref()
269 // SAFETY: Guaranteed by the safety requirements of the function. in new()
283 // SAFETY: Guaranteed by the safety requirements of the function. in as_mut_ref()
297 // SAFETY: Guaranteed by the safety requirements of the function. in as_ref()
|
| /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_hynix.c | 498 struct nand_ecc_props requirements = {}; in hynix_nand_extract_ecc_requirements() local
503 requirements.step_size = 1024; in hynix_nand_extract_ecc_requirements()
507 requirements.step_size = 0; in hynix_nand_extract_ecc_requirements()
508 requirements.strength = 0; in hynix_nand_extract_ecc_requirements()
511 requirements.strength = 4; in hynix_nand_extract_ecc_requirements()
514 requirements.strength = 24; in hynix_nand_extract_ecc_requirements()
517 requirements.strength = 32; in hynix_nand_extract_ecc_requirements()
520 requirements.strength = 40; in hynix_nand_extract_ecc_requirements()
523 requirements.strength = 50; in hynix_nand_extract_ecc_requirements()
526 requirements.strength = 60; in hynix_nand_extract_ecc_requirements()
[all …]
|
| 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/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/rust/kernel/drm/ |
| H A D | device.rs | 140 // SAFETY: By the safety requirements of this function `ptr` is a valid pointer to a in from_drm_device()
158 // SAFETY: By the safety requirements of this function `ptr` is a valid pointer to a in as_ref()
162 // SAFETY: `ptr` is valid by the safety requirements of this function. in as_ref()
176 // satisfy the requirements.
184 // SAFETY: The safety requirements guarantee that the refcount is non-zero. in dec_ref()
|
| /linux/rust/kernel/list/ |
| H A D | impl_list_item_mod.rs | 215 // `post_remove`, or `view_value`. By the safety requirements of those methods,
235 // may choose to satisfy the safety requirements of `post_remove` instead of the safety
236 // requirements for `view_value`.
244 // GUARANTEES: (only when using the `view_value` safety requirements)
257 // value is `prepare_to_insert`, but by the safety requirements the
267 // promise the safety requirements of `post_remove` instead of the safety
268 // requirements for `view_value`.
|
| /linux/Documentation/RCU/ |
| H A D | index.rst | 29 Design/Requirements/Requirements
|
| /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/alloc/ |
| H A D | kbox.rs | 230 // SAFETY: `raw` comes from a previous call to `Box::into_raw`. By the safety requirements in assume_init()
415 // SAFETY: The safety requirements of this function ensure that `ptr` comes from a previous in from_foreign()
421 // SAFETY: The safety requirements of this method ensure that the object remains alive and in borrow()
427 // SAFETY: The safety requirements of this method ensure that the pointer is valid and that in borrow_mut()
448 // SAFETY: The safety requirements of this function ensure that `ptr` comes from a previous in from_foreign()
454 // SAFETY: The safety requirements for this function ensure that the object is still alive, in borrow()
456 // The safety requirements of `from_foreign` also ensure that the object remains alive for in borrow()
465 // SAFETY: The safety requirements for this function ensure that the object is still alive, in borrow_mut()
467 // The safety requirements of `from_foreign` also ensure that the object remains alive for in borrow_mut()
|
| /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/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/power/ |
| H A D | pm_qos_interface.rst | 188 certain protocol requirements or target frame or sample rates etc.
199 latency tolerance requirements for the device is empty, the callback is expected
214 requirements from the kernel side in the device's list.
218 latency tolerance requirements for devices.
|
| /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.
|