| /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 ar 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 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 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 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_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()
|
| 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 in micron_nand_init()
[all...] |
| /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/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/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/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/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 fo
[all...] |
| /linux/rust/kernel/drm/ |
| H A D | device.rs | 138 // SAFETY: By the safety requirements of this function `ptr` is a valid pointer to a in from_drm_device()
156 // SAFETY: By the safety requirements of this function `ptr` is a valid pointer to a in from_raw()
160 // SAFETY: `ptr` is valid by the safety requirements of this function. in from_raw()
184 // satisfy the requirements.
192 // SAFETY: The safety requirements guarantee that the refcount is non-zero. in dec_ref()
|
| /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/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/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/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/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/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.
|