Home
last modified time | relevance | path

Searched full:believed (Results 1 – 25 of 28) sorted by relevance

12

/linux/Documentation/devicetree/bindings/iio/humidity/
H A Ddht11.yaml14 interface. It is believed the part is made by aosong but don't have
/linux/tools/arch/sparc/include/asm/
H A Dbarrier_64.h12 * It used to be believed that the memory barrier had to be right in the
/linux/arch/sparc/include/asm/
H A Dbarrier_64.h10 * It used to be believed that the memory barrier had to be right in the
/linux/arch/powerpc/include/asm/
H A Dpmac_feature.h56 #define PMAC_TYPE_COMET 0x20 /* Believed to be PowerBook 2400 */
57 #define PMAC_TYPE_HOOPER 0x21 /* Believed to be PowerBook 3400 */
/linux/Documentation/admin-guide/nfs/
H A Dnfs-client.rst44 anything that is believed to be unique across all NFS clients. An
/linux/arch/arm/crypto/
H A DKconfig186 The bit sliced AES code does not use lookup tables, so it is believed
/linux/Documentation/usb/
H A Dgadget_multi.rst124 believed that it should (read: "I have no idea whether it will") work
H A Dehci.rst52 It's believed to do all the right PCI magic so that I/O works even on
/linux/tools/net/sunrpc/xdrgen/
H A DREADME33 2. rpcgen-generated code is believed to be less efficient than code
/linux/Documentation/process/
H A Dresearcher-guidelines.rst116 * What was changed to fix the problem, and why it is believed to be correct?
/linux/arch/alpha/lib/
H A Dev6-clear_user.S27 * The believed purpose of only updating $0 after a store is that a signal
/linux/Documentation/power/
H A Dpower_supply_class.rst15 the attributes provided are believed to be universally applicable to any
/linux/drivers/md/dm-vdo/
H A Dencodings.h552 /* Bit 15: The believed cleanliness of this slab */
555 /* Bit 15: The believed cleanliness of this slab */
/linux/LICENSES/preferred/
H A DGPL-2.0245 This section is intended to make thoroughly clear what is believed to
H A DLGPL-2.1407 This section is intended to make thoroughly clear what is believed to
H A DLGPL-2.0387 This section is intended to make thoroughly clear what is believed to
/linux/tools/usb/usbip/
H A DCOPYING226 This section is intended to make thoroughly clear what is believed to
/linux/drivers/net/ethernet/sfc/falcon/
H A Dtxc43128_phy.c282 * (PHY<->MAC) as this is believed less likely to upset Falcon in txc_apply_defaults()
/linux/drivers/gpu/drm/xe/
H A Dxe_device.c893 * which is believed to be sufficient to cover the worst case in xe_device_td_flush()
/linux/Documentation/filesystems/
H A Dlocking.rst6 It is (believed to be) up-to-date. *Please*, if you change anything in
/linux/Documentation/RCU/Design/Requirements/
H A DRequirements.rst1031 counter, which is currently believed to be an acceptably long time.
1730 sometimes by a large factor. If RCU naively believed the firmware, as it
2696 sockets or cores. Such spreading and alignment is currently believed to
/linux/arch/mips/
H A DKconfig1110 # Attribute bits. It is believed that the uncached access through
/linux/drivers/usb/serial/
H A Dcp210x.c1645 * are made unavailable by configuring the use of GPIO. This is believed to be
/linux/drivers/staging/vme_user/
H A Dvme_tsi148.c1315 * that reading the data we have just written is safe. It is believed in tsi148_master_write()
/linux/arch/x86/
H A DKconfig1933 TSX is enabled on TSX capable HW that is believed to be safe against

12