Home
last modified time | relevance | path

Searched refs:acquire (Results 1 – 25 of 146) sorted by relevance

123456

/Linux-v4.19/tools/memory-model/
Dlinux-kernel.def14 smp_load_acquire(X) __load{acquire}(*X)
31 xchg_acquire(X,V) __xchg{acquire}(X,V)
34 cmpxchg_acquire(X,V,W) __cmpxchg{acquire}(X,V,W)
62 atomic_add_return_acquire(V,X) __atomic_op_return{acquire}(X,+,V)
66 atomic_fetch_add_acquire(V,X) __atomic_fetch_op{acquire}(X,+,V)
71 atomic_inc_return_acquire(X) __atomic_op_return{acquire}(X,+,1)
75 atomic_fetch_inc_acquire(X) __atomic_fetch_op{acquire}(X,+,1)
80 atomic_sub_return_acquire(V,X) __atomic_op_return{acquire}(X,-,V)
84 atomic_fetch_sub_acquire(V,X) __atomic_fetch_op{acquire}(X,-,V)
89 atomic_dec_return_acquire(X) __atomic_op_return{acquire}(X,-,1)
[all …]
Dlinux-kernel.bell18 'acquire (*smp_load_acquire*) ||
20 instructions R[{'once,'acquire,'noreturn}]
22 instructions RMW[{'once,'acquire,'release}]
/Linux-v4.19/tools/memory-model/litmus-tests/
DREADME44 and load-acquire replaced with READ_ONCE().
47 Can a release-acquire chain order a prior store against
56 Does a release-acquire pair suffice for the load-buffering
62 and load-acquire replaced with READ_ONCE().
69 in one process, and use an acquire load followed by a pair of
74 acquire load followed by a pair of spin_is_locked() calls
85 As below, but with a release-acquire chain.
124 As below, but without the smp_wmb() and acquire load.
127 Can a smp_wmb(), instead of a release, and an acquire order
147 Is the ordering provided by a release-acquire chain sufficient
[all …]
DISA2+pooncerelease+poacquirerelease+poacquireonce.litmus6 * This litmus test demonstrates that a release-acquire chain suffices
8 * that the release-acquire chain suffices is because in all but one
11 * (AKA non-rf) link, so release-acquire is all that is needed.
DS+fencewmbonceonce+poacquireonce.litmus6 * Can a smp_wmb(), instead of a release, and an acquire order a prior
DLB+poacquireonce+pooncerelease.litmus6 * Does a release-acquire pair suffice for the load-buffering litmus
DS+poonceonces.litmus6 * Starting with a two-process release-acquire chain ordering P0()'s
DISA2+poonceonces.litmus6 * Given a release-acquire chain ordering the first process's store
DMP+polockonce+poacquiresilsil.litmus7 * to sense the lock-held state, ordered by acquire? Note that when the
DMP+polockmbonce+poacquiresilsil.litmus8 * state, ordered by acquire? Note that when the first spin_is_locked()
/Linux-v4.19/Documentation/
Dfutex-requeue-pi.txt91 to be able to acquire the rt_mutex before returning to user space.
93 acquire the rt_mutex as it would open a race window between the
99 allow the requeue code to acquire an uncontended rt_mutex on behalf
115 requeueing, futex_requeue() attempts to acquire the requeue target
127 tasks as it can acquire the lock for, which in the majority of cases
129 either pthread_cond_broadcast() or pthread_cond_signal() acquire the
/Linux-v4.19/drivers/net/ethernet/broadcom/bnx2x/
Dbnx2x_vfpf.c228 struct vfpf_acquire_tlv *req = &bp->vf2pf_mbox->req.acquire; in bnx2x_vfpf_acquire()
1366 struct vfpf_acquire_tlv *acquire) in bnx2x_vf_mbx_is_windows_vm() argument
1373 if (!acquire->bulletin_addr || in bnx2x_vf_mbx_is_windows_vm()
1374 acquire->resc_request.num_mc_filters == 32 || in bnx2x_vf_mbx_is_windows_vm()
1375 ((acquire->vfdev_info.vf_os & VF_OS_MASK) == in bnx2x_vf_mbx_is_windows_vm()
1394 if (bnx2x_vf_mbx_is_windows_vm(bp, &mbx->msg->req.acquire)) in bnx2x_vf_mbx_acquire_chk_dorq()
1404 struct vfpf_acquire_tlv *acquire = &mbx->msg->req.acquire; in bnx2x_vf_mbx_acquire() local
1409 vf->abs_vfid, acquire->vfdev_info.vf_id, acquire->vfdev_info.vf_os, in bnx2x_vf_mbx_acquire()
1410 acquire->resc_request.num_rxqs, acquire->resc_request.num_txqs, in bnx2x_vf_mbx_acquire()
1411 acquire->resc_request.num_sbs, acquire->resc_request.num_mac_filters, in bnx2x_vf_mbx_acquire()
[all …]
/Linux-v4.19/Documentation/locking/
Dww-mutex-design.txt63 trying to acquire locks doesn't grab a new reservation id, but keeps the one it
65 acquire context. Furthermore the acquire context keeps track of debugging state
66 to catch w/w mutex interface abuse. An acquire context is representing a
70 w/w mutexes, since it is required to initialize the acquire context. The lock
73 Furthermore there are three different class of w/w lock acquire functions:
97 * Functions to only acquire a single w/w mutex, which results in the exact same
101 Again this is not strictly required. But often you only want to acquire a
102 single lock in which case it's pointless to set up an acquire context (and so
117 Three different ways to acquire locks within the same w/w class. Common
337 (1) Waiters with an acquire context are sorted by stamp order; waiters
[all …]
/Linux-v4.19/drivers/net/ethernet/intel/e1000e/
Dphy.c250 ret_val = hw->phy.ops.acquire(hw); in e1000e_read_phy_reg_m88()
275 ret_val = hw->phy.ops.acquire(hw); in e1000e_write_phy_reg_m88()
322 if (!hw->phy.ops.acquire) in __e1000e_read_phy_reg_igp()
325 ret_val = hw->phy.ops.acquire(hw); in __e1000e_read_phy_reg_igp()
389 if (!hw->phy.ops.acquire) in __e1000e_write_phy_reg_igp()
392 ret_val = hw->phy.ops.acquire(hw); in __e1000e_write_phy_reg_igp()
457 if (!hw->phy.ops.acquire) in __e1000_read_kmrn_reg()
460 ret_val = hw->phy.ops.acquire(hw); in __e1000_read_kmrn_reg()
530 if (!hw->phy.ops.acquire) in __e1000_write_kmrn_reg()
533 ret_val = hw->phy.ops.acquire(hw); in __e1000_write_kmrn_reg()
[all …]
Dich8lan.c216 hw->phy.ops.acquire(hw); in e1000_phy_is_accessible_pchlan()
305 ret_val = hw->phy.ops.acquire(hw); in e1000_init_phy_workarounds_pchlan()
822 ret_val = hw->phy.ops.acquire(hw); in e1000_set_eee_pchlan()
908 ret_val = hw->phy.ops.acquire(hw); in e1000_k1_workaround_lpt_lp()
1115 ret_val = hw->phy.ops.acquire(hw); in e1000_enable_ulp_lpt_lp()
1265 ret_val = hw->phy.ops.acquire(hw); in e1000_disable_ulp_lpt_lp()
1412 ret_val = hw->phy.ops.acquire(hw); in e1000_check_for_copper_link_ich8lan()
1443 ret_val = hw->phy.ops.acquire(hw); in e1000_check_for_copper_link_ich8lan()
1468 ret_val = hw->phy.ops.acquire(hw); in e1000_check_for_copper_link_ich8lan()
2089 ret_val = hw->phy.ops.acquire(hw); in e1000_sw_lcd_config_ich8lan()
[all …]
/Linux-v4.19/Documentation/networking/
Dxfrm_sysctl.txt4 default 30 - hard timeout in seconds for acquire requests
/Linux-v4.19/drivers/gpu/drm/amd/display/dc/i2caux/dce80/
Di2caux_dce80.c140 engine->base.funcs->acquire(&engine->base, ddc)) { in acquire_i2c_hw_engine()
145 if (engine->base.funcs->acquire(&engine->base, ddc)) in acquire_i2c_hw_engine()
/Linux-v4.19/drivers/media/dvb-frontends/
Das102_fe.h23 int (*stream_ctrl)(void *priv, int acquire, uint32_t elna_cfg);
/Linux-v4.19/drivers/gpu/drm/nouveau/include/nvkm/core/
Dmemory.h35 void __iomem *(*acquire)(struct nvkm_memory *); member
68 #define nvkm_kmap(o) (o)->func->acquire(o)
Dgpuobj.h27 void *(*acquire)(struct nvkm_gpuobj *); member
/Linux-v4.19/drivers/net/ethernet/intel/igb/
De1000_i210.c200 if (!(hw->nvm.ops.acquire(hw))) { in igb_read_nvm_srrd_i210()
300 if (!(hw->nvm.ops.acquire(hw))) { in igb_write_nvm_srwr_i210()
542 if (!(hw->nvm.ops.acquire(hw))) { in igb_validate_nvm_checksum_i210()
588 if (!(hw->nvm.ops.acquire(hw))) { in igb_update_nvm_checksum_i210()
797 nvm->ops.acquire = igb_acquire_nvm_i210; in igb_init_nvm_params_i210()
/Linux-v4.19/Documentation/filesystems/
Ddirectory-locking6 always acquire the locks in order by increasing address. We'll call
65 attempts to acquire lock on B, A will remain the parent of B until we
66 acquire the lock on B. (Proof: only cross-directory rename can change
81 attempt to acquire some lock and already holds at least one lock. Let's
111 try to acquire lock on descendent before the lock on ancestor.
/Linux-v4.19/Documentation/RCU/
DUP.txt56 callback function must acquire this same lock. In this case, if
114 acquire the lock.
123 callbacks acquire locks directly. However, a great many RCU
124 callbacks do acquire locks -indirectly-, for example, via
/Linux-v4.19/drivers/gpu/drm/amd/display/dc/i2caux/
Dengine.h86 bool (*acquire)( member
/Linux-v4.19/tools/memory-model/Documentation/
Drecipes.txt195 load buffering, release-acquire chains, store buffering.
213 Release and acquire
237 The init_stack_slab() function in lib/stackdepot.c uses release-acquire
405 Release-acquire chains
408 Release-acquire chains are a low-overhead, flexible, and easy-to-use
464 is that in this version, CPU2() is not part of the release-acquire chain.
467 Despite this limitation, release-acquire chains are low-overhead as
559 release-acquire chain suffices. Both the MP and the ISA2
566 locking and in the release-acquire sections.

123456