| /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()
493 // SAFETY: The requirements are satisfied by the existence of [`Device`] and its safety in set()
494 // requirements. The OPP core guarantees not to access fields of [`Config`] after this in set()
626 // SAFETY: By the safety requirements, ptr is valid and its refcount will be incremented. in from_raw_table()
642 // SAFETY: The requirements are satisfied by the existence of the [`Device`] and its safety in from_dev()
[all …]
|
| H A D | configfs.rs | 282 // SAFETY: By impl and function safety requirements this field in group()
347 // SAFETY: By function safety requirements of this function, this call in make_group()
353 // SAFETY: By function safety requirements, name points to a null in make_group()
393 // SAFETY: By function safety requirements of this function, this call in drop_item()
397 // SAFETY: By function safety requirements, `item` is embedded in a in drop_item()
400 // SAFETY: By function safety requirements, `c_child_group_ptr` is in drop_item()
446 // SAFETY: By function safety requirements, `this` is embedded in a in release()
449 // SAFETY: By function safety requirements, `c_group_ptr` is in release()
554 // SAFETY: By function safety requirements, `item` is embedded in a in show()
558 // SAFETY: The function safety requirements for this function satisfy in show()
[all …]
|
| /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/Documentation/dev-tools/ |
| H A D | testing-devices.rst | 10 with some overlap in coverage and different requirements. This document aims to
21 * **Requirements**: None
27 * **Requirements**: None
33 * **Requirements**: Manually describe the devices that should be tested in a
40 * **Requirements**: Generate the reference (see ``devices/exist/README.rst``
44 (DT-based) platforms, since they don't have any requirements. Then to greatly
|
| /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/Documentation/process/ |
| H A D | coding-assistants.rst | 18 Licensing and Legal Requirements
21 All contributions must comply with the kernel's licensing requirements:
35 * Ensuring compliance with licensing requirements
|
| /linux/Documentation/gpu/nova/ |
| H A D | guidelines.rst | 43 Besides that, there are some minimum requirements.
47 requirements. It is encouraged to have the same minimum documentation for
56 lifetime requirements, as well as example code if applicable.
|
| /linux/Documentation/gpu/ |
| H A D | drm-uapi.rst | 49 Open-Source Userspace Requirements
52 The DRM subsystem has stricter requirements than most other kernel subsystems on
54 explains what exactly those requirements are, and why they exist.
89 leads to a few additional requirements:
105 requirements by doing a quick fork.
107 - The kernel patch can only be merged after all the above requirements are met,
112 These are fairly steep requirements, but have grown out from years of shared
218 The goal raises at least the following requirements for the kernel and
221 Requirements for KMS UAPI
240 Requirements for Render and Cross-Device UAPI
[all …]
|
| /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/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/RCU/ |
| H A D | index.rst | 29 Design/Requirements/Requirements
|
| /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/Documentation/iio/ |
| H A D | ad7191.rst | 73 SPI Interface Requirements
76 The AD7191 has specific SPI interface requirements:
84 Power Supply 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/rust/kernel/list/ |
| H A D | impl_list_item_mod.rs | 289 // `post_remove`, or `view_value`. By the safety requirements of those methods,
311 // may choose to satisfy the safety requirements of `post_remove` instead of the safety
312 // requirements for `view_value`.
320 // GUARANTEES: (only when using the `view_value` safety requirements)
341 // value is `prepare_to_insert`, but by the safety requirements the
351 // promise the safety requirements of `post_remove` instead of the safety
352 // requirements for `view_value`.
|
| /linux/Documentation/networking/ |
| H A D | netmem.rst | 7 This document outlines the requirements for network drivers to support netmem,
22 Driver RX Requirements
81 Driver TX Requirements
|
| /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 | 182 certain protocol requirements or target frame or sample rates etc.
193 latency tolerance requirements for the device is empty, the callback is expected
208 requirements from the kernel side in the device's list.
212 latency tolerance requirements for devices.
|