Home
last modified time | relevance | path

Searched refs:strong (Results 1 – 25 of 45) sorted by relevance

12

/linux/drivers/hid/
H A Dhid-lg2ff.c27 int weak, strong; in play_effect() local
29 strong = effect->u.rumble.strong_magnitude; in play_effect()
32 if (weak || strong) { in play_effect()
34 strong = strong * 0xff / 0xffff; in play_effect()
38 lg2ff->report->field[0]->value[4] = strong; in play_effect()
/linux/arch/xtensa/boot/lib/
H A DMakefile23 CFLAGS_REMOVE_inflate.o += -fstack-protector -fstack-protector-strong
24 CFLAGS_REMOVE_zmem.o += -fstack-protector -fstack-protector-strong
25 CFLAGS_REMOVE_inftrees.o += -fstack-protector -fstack-protector-strong
26 CFLAGS_REMOVE_inffast.o += -fstack-protector -fstack-protector-strong
/linux/tools/memory-model/
H A Dlinux-kernel.cat65 let strong-fence = mb | gp
67 let nonrw-fence = strong-fence | po-rel | acq-po
97 (* Propagation: Ordering from release operations and strong fences. *)
100 let cumul-fence = [Marked] ; (A-cumul(strong-fence | po-rel) | wmb |
116 (* Propagation: Each non-rf link needs a strong fence. *)
117 let pb = prop ; strong-fence ; hb* ; [Marked]
140 * The synchronize_rcu() strong fence is special in that it can order not
149 * inter-CPU strong fence.
166 let strong-fence = strong
[all...]
/linux/drivers/media/dvb-frontends/
H A Dau8522_dig.c696 u16 strong; in au8522_led_status() local
705 strong = led_config->qam256_strong; in au8522_led_status()
707 strong = led_config->qam64_strong; in au8522_led_status()
709 strong = led_config->vsb8_strong; in au8522_led_status()
711 if (*snr >= strong) in au8522_led_status()
717 (((strong < *snr) ? (*snr - strong) : (strong - *snr)) <= 10)) in au8522_led_status()
/linux/Documentation/w1/slaves/
H A Dw1_therm.rst45 powered devices are detected on the bus (and strong pullup is enabled
57 A strong pullup will be applied during the conversion if required.
100 strong pullup, 1 to enable autodetection or 2 to force strong pullup.
103 If so, it will activate the master's strong pullup.
105 (seems to be the case with some DS18S20) the strong pullup can
108 If the strong pullup is enabled, the master's strong pullup will be
110 does support the strong pullup (or it falls back to a pullup
113 sufficient. The strong pullup is designed to provide the additional
H A Dw1_ds28e04.rst22 attribute "crccheck". The strong pull-up can optionally be enabled/disabled
/linux/drivers/android/
H A Dbinder.c820 static int binder_inc_node_nilocked(struct binder_node *node, int strong, in binder_inc_node_nilocked() argument
829 if (strong) { in binder_inc_node_nilocked()
836 pr_err("invalid inc strong node for %d\n", in binder_inc_node_nilocked()
860 static int binder_inc_node(struct binder_node *node, int strong, int internal, in binder_inc_node() argument
866 ret = binder_inc_node_nilocked(node, strong, internal, target_list); in binder_inc_node()
873 int strong, int internal) in binder_dec_node_nilocked() argument
880 if (strong) { in binder_dec_node_nilocked()
932 static void binder_dec_node(struct binder_node *node, int strong, int internal) in binder_dec_node() argument
937 free_node = binder_dec_node_nilocked(node, strong, internal); in binder_dec_node()
1004 * and cleanup is needed. Calling with strong in binder_dec_node_tmpref()
1243 binder_inc_ref_olocked(struct binder_ref * ref,int strong,struct list_head * target_list) binder_inc_ref_olocked() argument
1275 binder_dec_ref_olocked(struct binder_ref * ref,int strong) binder_dec_ref_olocked() argument
1394 binder_update_ref_for_handle(struct binder_proc * proc,uint32_t desc,bool increment,bool strong,struct binder_ref_data * rdata) binder_update_ref_for_handle() argument
1439 binder_dec_ref_for_handle(struct binder_proc * proc,uint32_t desc,bool strong,struct binder_ref_data * rdata) binder_dec_ref_for_handle() argument
1460 binder_inc_ref_for_node(struct binder_proc * proc,struct binder_node * node,bool strong,struct list_head * target_list,struct binder_ref_data * rdata) binder_inc_ref_for_node() argument
4160 bool strong = cmd == BC_ACQUIRE || cmd == BC_RELEASE; binder_thread_write() local
4871 int strong, weak; binder_thread_read() local
6804 int count, strong, weak, ready_threads; print_binder_proc_stats() local
[all...]
/linux/Documentation/locking/
H A Dlockdep-design.rst512 Dependency types and strong dependency paths:
571 "strong" path, which indicates the strong dependency throughout each dependency
573 -(xR)-> and -(Sx)->. In other words, a "strong" path is a path from a lock
579 We will see why the path is called "strong" in next section.
588 If there is a closed strong path (i.e. a strong circle), then there is a
589 combination of locking sequences that causes deadlock. I.e. a strong circle is
594 If there is no closed strong path (i.e. strong circle), then there is no
595 combination of locking sequences that could cause deadlock. I.e. strong
598 With these two Lemmas, we can easily say a closed strong path is both sufficient
599 and necessary for deadlocks, therefore a closed strong path is equivalent to
[all …]
/linux/drivers/input/
H A Dff-memless.c246 unsigned int strong, weak, i; in ml_combine_effects() local
270 strong = (u32)new->u.rumble.strong_magnitude * gain / 0xffff; in ml_combine_effects()
273 if (effect->u.rumble.strong_magnitude + strong) in ml_combine_effects()
277 new->direction, strong); in ml_combine_effects()
286 min(strong + effect->u.rumble.strong_magnitude, in ml_combine_effects()
/linux/drivers/android/binder/
H A Dcontext.rs136 pub(crate) fn get_manager_node(&self, strong: bool) -> Result<NodeRef, BinderError> { in get_manager_node()
142 .clone(strong) in get_manager_node()
/linux/tools/thermal/tmon/
H A DMakefile11 override CFLAGS+= $(call cc-option,-fstack-protector-strong)
/linux/tools/tracing/rtla/
H A DMakefile.rtla18 FOPTS := -flto=auto -ffat-lto-objects -fexceptions -fstack-protector-strong \
/linux/tools/verification/rv/
H A DMakefile.rv18 FOPTS :=-flto=auto -ffat-lto-objects -fexceptions -fstack-protector-strong \
/linux/Documentation/w1/masters/
H A Dds2490.rst25 - The 5V strong pullup is supported with a minimum of 5.9mA and a
35 buffer, and strong pullup all in one command, instead of the current
/linux/arch/x86/purgatory/
H A DMakefile53 PURGATORY_CFLAGS_REMOVE += -fstack-protector-strong
/linux/drivers/media/usb/dvb-usb/
H A Daf9005-fe.c44 int strong; member
470 if (temp != state->strong) { in af9005_fe_read_status()
472 state->strong = temp; in af9005_fe_read_status()
1212 state->strong = -1; in af9005_fe_set_frontend()
/linux/drivers/input/joystick/
H A Dxpad.c1546 __u16 strong; in xpad_play_effect()
1552 strong = effect->u.rumble.strong_magnitude; in xpad_play_effect()
1562 packet->data[3] = strong / 256; /* left actuator */ in xpad_play_effect()
1573 packet->data[3] = strong / 256; /* left actuator? */ in xpad_play_effect()
1588 packet->data[5] = strong / 256; in xpad_play_effect()
1608 packet->data[8] = strong / 512; /* left actuator */ in xpad_play_effect()
1542 __u16 strong; xpad_play_effect() local
/linux/arch/riscv/purgatory/
H A DMakefile80 PURGATORY_CFLAGS_REMOVE += -fstack-protector-strong
/linux/tools/memory-model/Documentation/
H A Dexplanation.txt864 Any store which propagates to C before a strong fence is
867 the strong fence are executed on C.
869 The propagation ordering enforced by release fences and strong fences
873 strong fences are A-cumulative. By contrast, smp_wmb() fences are not
885 The fences which affect propagation order (i.e., strong, release, and
896 A strong fence event occurs between some X and F in program
1039 at least as strong as atomic updates with release-barrier semantics.)
1056 A strong (smp_mb() or synchronize_rcu()) fence occurs between
1229 The LKMM requires that smp_rmb(), acquire fences, and strong fences
1233 case of a strong fence, the CPU first has to wait for all of its
[all …]
/linux/drivers/pinctrl/spacemit/
H A Dpinctrl-k1.c706 u32 normal, strong; in spacemit_pinconf_dbg_pull() local
717 strong = FIELD_GET(PAD_STRONG_PULL, value); in spacemit_pinconf_dbg_pull()
719 if (normal && strong) in spacemit_pinconf_dbg_pull()
/linux/fs/btrfs/
H A DKconfig27 expected to change unless there are strong reasons to do so. If there
/linux/Documentation/driver-api/media/drivers/
H A Dpvrusb2.rst26 This driver has a strong separation of layers. They are very
51 simultaneously access the driver. I have a strong sense of fairness
/linux/Documentation/process/
H A Dcontribution-maturity-model.rst18 strong talent pipeline, developers should be allowed and encouraged to
/linux/Documentation/w1/
H A Dw1-generic.rst97 w1_master_pullup (rw) 5V strong pullup 0 enabled, 1 disabled
/linux/Documentation/filesystems/nfs/
H A Dknfsd-stats.rst96 a strong indication, for a couple of reasons:

12