/linux-5.10/arch/x86/include/asm/ |
D | bitops.h | 289 * AMD64 says BSFL won't clobber the dest reg if x==0; Intel64 says the in ffs() 290 * dest reg is undefined if x==0, but their CPU architect says its in ffs() 330 * AMD64 says BSRL won't clobber the dest reg if x==0; Intel64 says the in fls() 331 * dest reg is undefined if x==0, but their CPU architect says its in fls() 370 * AMD64 says BSRQ won't clobber the dest reg if x==0; Intel64 says the in fls64() 371 * dest reg is undefined if x==0, but their CPU architect says its in fls64()
|
/linux-5.10/drivers/pcmcia/ |
D | soc_common.h | 181 * The PC Card Standard, Release 7, section 4.13.4, says that twIORD 182 * has a minimum value of 165ns. Section 4.13.5 says that twIOWR has 184 * common and attribute memory write timing) says that twWE has a 187 * operation, also section 4.7.4). Section 4.7.3 says that taOE
|
/linux-5.10/Documentation/process/ |
D | kernel-docs.rst | 168 :Description: The title says it all. 177 :Description: The title says it all. 202 :Description: The title says it all. 210 :Description: The title says it all. 218 :Description: The title says it all. 226 :Description: The title says it all. 234 :Description: The title still says it all. 242 :Description: The title says it all. 566 :Description: The title says it all. There's a fixed kernel section
|
/linux-5.10/Documentation/fb/ |
D | tridentfb.rst | 55 look at the driver output to see what it says when initializing. 59 detection says in all three BIOS selectable situations 2M, 4M, 8M.
|
/linux-5.10/Documentation/devicetree/bindings/timer/ |
D | arm,arch_timer.yaml | 62 description: Indicates the presence of QorIQ erratum A-008585, which says 70 says that reading the counters is unreliable in some cases, and reads may
|
/linux-5.10/drivers/gpu/drm/nouveau/nvkm/subdev/mxm/ |
D | nv50.c | 127 /* override dcb sorconf.link, based on what mxm data says */ in mxm_dcb_sanitise_entry() 140 * the descriptor says the connector type should be. in mxm_dcb_sanitise_entry() 143 * and the mxm data says the connector is really HDMI. another in mxm_dcb_sanitise_entry()
|
/linux-5.10/arch/x86/math-emu/ |
D | reg_mul.c | 84 /* The 80486 book says that the answer is +0, but a real in FPU_mul() 86 IEEE-754 apparently says it should be this way. */ in FPU_mul()
|
/linux-5.10/arch/ia64/include/asm/ |
D | shmparam.h | 7 * get attached. The IA-64 architecture says that there may be a
|
/linux-5.10/arch/x86/tools/ |
D | insn_decoder_test.c | 159 pr_warn("objdump says %d bytes, but insn_get_length() " in main() 160 "says %d\n", nb, insn.length); in main()
|
/linux-5.10/drivers/mtd/maps/ |
D | physmap-versatile.c | 73 /* The manual says bit 2, the code says bit 3, trust the code */
|
D | physmap-gemini.c | 164 dev_warn(dev, "flash hardware say flash is 16 bit wide but DT says it is %d bits wide\n", in of_flash_probe_gemini() 168 dev_warn(dev, "flash hardware say flash is 8 bit wide but DT says it is %d bits wide\n", in of_flash_probe_gemini()
|
/linux-5.10/arch/alpha/include/uapi/asm/ |
D | resource.h | 15 * SuS says limits have to be unsigned. Fine, it's unsigned, but
|
/linux-5.10/Documentation/devicetree/bindings/rtc/ |
D | faraday,ftrtc010.txt | 14 says the clock should be 1 Hz, but implementers actually seem
|
/linux-5.10/arch/sparc/include/uapi/asm/ |
D | resource.h | 22 * SuS says limits have to be unsigned.
|
/linux-5.10/Documentation/litmus-tests/rcu/ |
D | RCU+sync+read.litmus | 10 * This is one implication of the RCU grace-period guarantee, which says (among
|
D | RCU+sync+free.litmus | 14 * This is one implication of the RCU grace-period guarantee, which says (among
|
/linux-5.10/drivers/staging/greybus/Documentation/firmware/ |
D | firmware.c | 78 printf("Load status says loading failed: %d\n", in update_intf_firmware() 150 printf("Load status says loading failed: %d\n", in update_backend_firmware()
|
/linux-5.10/arch/arm/vdso/ |
D | vdsomunge.c | 10 * 0042E) says: 18 * And ELF for the ARM Architecture (ARM IHI 0044E) (Table 4-2) says:
|
/linux-5.10/drivers/gpu/drm/i915/display/ |
D | intel_bios.h | 66 MIPI_SEQ_DEASSERT_RESET, /* Spec says MipiAssertResetPin */ 70 MIPI_SEQ_ASSERT_RESET, /* Spec says MipiDeassertResetPin */
|
/linux-5.10/drivers/hid/ |
D | hid-macally.c | 18 * The Macally ikey keyboard says that its logical and usage maximums are both
|
/linux-5.10/arch/mips/include/uapi/asm/ |
D | resource.h | 25 * SuS says limits have to be unsigned.
|
/linux-5.10/Documentation/devicetree/bindings/leds/backlight/ |
D | common.yaml | 31 on the brightness apart from what the driver says, as it could happen
|
/linux-5.10/tools/lib/subcmd/ |
D | parse-options.h | 83 * PARSE_OPT_OPTARG: says that the argument is optional (not for BOOLEANs) 84 * PARSE_OPT_NOARG: says that this option takes no argument, for CALLBACKs 85 * PARSE_OPT_NONEG: says that this option cannot be negated
|
/linux-5.10/tools/memory-model/Documentation/ |
D | explanation.txt | 188 program source for each CPU. The model says that the value obtained 956 atomic update. This is what the LKMM's "atomic" axiom says. 1054 (the po-loc link says that R comes before W in program order and they 1280 The prop link says that in order to obtain the r1 = 1, r2 = 0 result, 1444 span a full grace period. In more detail, the Guarantee says: 1534 "before", then X ->rcu-gp Y ->rcu-link Z roughly says that X is a 1538 after X ends.) Similarly, X ->rcu-rscsi Y ->rcu-link Z says that X is 1584 section C. Then part (2) of the Grace Period Guarantee says not only 1820 CPUs, but the LKMM says it holds even when they are on the same CPU. 2008 which may execute concurrently; if it does then the LKMM says there is [all …]
|
/linux-5.10/include/linux/reset/ |
D | reset-simple.h | 25 * are set to assert the reset. Note that this says nothing about
|