Home
last modified time | relevance | path

Searched refs:good (Results 1 – 200 of 331) sorted by relevance

12

/linux-4.4.14/arch/x86/platform/intel-mid/device_libs/
Dplatform_gpio_keys.c62 int i, num, good = 0; in pb_keys_init() local
72 if (i != good) in pb_keys_init()
73 gb[good] = gb[i]; in pb_keys_init()
74 good++; in pb_keys_init()
77 if (good) { in pb_keys_init()
78 gpio_keys.nbuttons = good; in pb_keys_init()
/linux-4.4.14/kernel/
DKconfig.hz29 250 Hz is a good compromise choice allowing server performance
30 while also showing good interactive responsiveness even
37 300 Hz is a good compromise choice allowing server performance
38 while also showing good interactive responsiveness even
DKconfig.preempt10 throughput. It will still provide good latencies most of the
/linux-4.4.14/Documentation/devicetree/bindings/arm/tegra/
Dnvidia,tegra20-pmc.txt35 - nvidia,cpu-pwr-good-en : Boolean, CPU power good signal (from PMIC to PMC)
39 - nvidia,cpu-pwr-good-time : CPU power good time in uS.
41 - nvidia,core-pwr-good-time : <Oscillator-stable-time Power-stable-time>
42 Core power good time in uS.
81 nvidia,cpu-pwr-good-time = <2000>;
83 nvidia,core-pwr-good-time = <3845 3845>;
/linux-4.4.14/crypto/async_tx/
Dasync_raid6_recov.c210 int good_srcs, good, i; in __2data_recov_5() local
213 good = -1; in __2data_recov_5()
219 good = i; in __2data_recov_5()
226 g = blocks[good]; in __2data_recov_5()
238 tx = async_mult(dq, g, raid6_gfexp[good], bytes, submit); in __2data_recov_5()
433 int good_srcs, good, i; in async_raid6_datap_recov() local
461 good = -1; in async_raid6_datap_recov()
466 good = i; in async_raid6_datap_recov()
488 struct page *g = blocks[good]; in async_raid6_datap_recov()
496 tx = async_mult(dq, g, raid6_gfexp[good], bytes, submit); in async_raid6_datap_recov()
/linux-4.4.14/arch/cris/arch-v32/mach-fs/
DKconfig28 Waitstates for SRAM. 0 is a good choice for most Axis products.
35 Waitstates for CSP0-3. 0 is a good choice for most Axis products.
44 Waitstates for CSP4-6. 0 is a good choice for most Axis products.
97 as inputs, although floating inputs isn't good.
119 as inputs, although floating inputs isn't good.
141 as inputs, although floating inputs isn't good.
163 as inputs, although floating inputs isn't good.
185 as inputs, although floating inputs isn't good.
/linux-4.4.14/drivers/block/
Dumem.c130 int good; member
659 if (card->battery[0].good && card->battery[1].good) in set_fault_to_battery_status()
663 else if (!card->battery[0].good && !card->battery[1].good) in set_fault_to_battery_status()
673 if (status != card->battery[battery].good) { in check_battery()
674 card->battery[battery].good = !card->battery[battery].good; in check_battery()
677 if (card->battery[battery].good) { in check_battery()
686 } else if (!card->battery[battery].good && in check_battery()
935 card->battery[0].good = !(batt_status & BATTERY_1_FAILURE); in mm_pci_probe()
936 card->battery[1].good = !(batt_status & BATTERY_2_FAILURE); in mm_pci_probe()
947 card->battery[0].good ? "OK" : "FAILURE", in mm_pci_probe()
[all …]
/linux-4.4.14/arch/cris/arch-v32/
DKconfig43 Waitstates for SRAM. 0 is a good choice for most Axis products.
50 Waitstates for CSP0-3. 0 is a good choice for most Axis products.
59 Waitstates for CSP4-6. 0 is a good choice for most Axis products.
112 as inputs, although floating inputs isn't good.
134 as inputs, although floating inputs isn't good.
156 as inputs, although floating inputs isn't good.
178 as inputs, although floating inputs isn't good.
200 as inputs, although floating inputs isn't good.
/linux-4.4.14/drivers/net/wireless/cw1200/
Dsta.h67 void __cw1200_cqm_bssloss_sm(struct cw1200_common *priv, int init, int good,
70 int init, int good, int bad) in cw1200_cqm_bssloss_sm() argument
73 __cw1200_cqm_bssloss_sm(priv, init, good, bad); in cw1200_cqm_bssloss_sm()
Dsta.c152 int init, int good, int bad) in __cw1200_cqm_bssloss_sm() argument
161 init, good, bad, in __cw1200_cqm_bssloss_sm()
178 } else if (good) { in __cw1200_cqm_bssloss_sm()
/linux-4.4.14/Documentation/arm/
Dmem_alignment4 bad idea to configure it out, but Russell King has some good reasons for
16 trap to SIGBUS any code performing unaligned access (good for debugging bad
22 Please note that randomly changing the behaviour without good thought is
DREADME12 a good compiler. Fortunately, you needn't guess. The kernel will report
96 make good use of modularisation.
DSetup53 It's generally a good idea to set these to be either standard VGA, or
/linux-4.4.14/Documentation/cgroups/
Dmemcg_test.txt126 When you do test to do racy case, it's good test to set memcg's limit
135 SwapCache. Test with shmem/tmpfs is always good test.
172 memory hotplug test is one of good test.
195 running new jobs in new group is also good.
198 Mounting with other subsystems is a good test because there is a
211 For example, test like following is good.
280 It's good idea to test root cgroup as well.
/linux-4.4.14/drivers/ide/
Dide-iops.c105 int __ide_wait_stat(ide_drive_t *drive, u8 good, u8 bad, in __ide_wait_stat() argument
150 if (OK_STAT(stat, good, bad)) { in __ide_wait_stat()
164 int ide_wait_stat(ide_startstop_t *startstop, ide_drive_t *drive, u8 good, in ide_wait_stat() argument
176 err = __ide_wait_stat(drive, good, bad, timeout, &stat); in ide_wait_stat()
/linux-4.4.14/Documentation/
DManagementStyle107 not. After all, if _they_ aren't certain whether it's a good idea, you
161 - get really good at apologies
192 good idea - go wild", or "That sounds good, but what about xxx?". The
199 specific directions, but let's face it, they might be good at what they
200 do, and suck at everything else. The good news is that people tend to
201 naturally gravitate back to what they are good at, so it's not like you
212 best way of taking the blame: do it for another guy. You'll feel good
213 for taking the fall, he'll feel good about not getting blamed, and the
226 you've followed the previous rules, you'll be pretty good at saying that
236 do a good job.
[all …]
DHOWTO26 parts written in assembly. A good understanding of C is required for
29 are not a good substitute for a solid C education and/or years of
30 experience, the following books are good for, if anything, reference:
153 A good introduction describing exactly what a patch is and how to
341 The file REPORTING-BUGS in the main kernel source directory has a good
391 Please remember to follow good behavioral habits when using the lists.
397 get pretty large. Don't remove anybody from the CC: list without a good
412 characters. A good first test is to send the mail to yourself and try
475 good..."
497 comfortable with English. A good grasp of the language can be needed in
[all …]
DSubmitChecklist26 4: ppc64 is a good architecture for cross-compilation checking because it
88 EXTRA_CFLAGS=-W"). This will generate lots of noise, but is good for
DDMA-ISA-LPC.txt44 allocate the memory during boot-up it's a good idea to also pass
86 Now for the good stuff, the actual DMA transfer. :)
Dstable_api_nonsense.txt22 get lots of other good benefits if your driver is in the main kernel
160 under this category, good luck, you are on your own here, you leech
167 The very good side effects of having your driver in the main kernel tree
Demail-clients.txt7 email clients. The man page for this is quite good. On the receiving
51 It's a good idea to send a patch to yourself, save the received message,
185 However, it's a good idea to set the "send_charset" to:
DSubmittingDrivers108 driver it is a good idea to state this in the comments,
115 often a good thing. If there is a stable working driver from
DCodingStyle296 NOTE! Opaqueness and "accessor functions" are not good in themselves.
399 example of a good name could be "out_buffer:" if the goto frees "buffer". Avoid
446 Comments are good, but there is also a danger of over-commenting. NEVER
501 make a good program).
652 might look like a good thing, but it's confusing as hell when one reads the
685 of kernel messages to make a good impression. Do not use crippled
700 Coming up with good debugging messages can be quite a challenge; and once
763 function away at compile time. For a good example of this later case, see
DIRQ-domain.txt78 The Linear map is a good choice when the maximum number of hwirqs is
93 The tree map is a good choice if the hwirq number can be very large
Dfutex-requeue-pi.txt127 should be 0 as good programming practice dictates that the caller of
Dxz.txt104 it is good to know this if testing the code e.g. with the test files
Dkernel-docs.txt83 figures. Gives good overall kernel understanding.
92 figures. Gives good overall kernel understanding. This papers
205 Hackers' Guide" which give a very good overview of the topic.
464 configuration tools' code. Very good to get a general overview of
Dpi-futex.txt62 the only technique that currently enables good determinism for userspace
DSubmittingPatches374 ignoring reviewers is a good way to get ignored in return. Review comments
520 mergers will sometimes manually convert an acker's "yep, looks good to me"
703 One good use for the additional comments after the "---" marker is for
708 here. A good example of such comments might be "patch changelogs"
771 be a good way to find developers who can sign your key.
Dstable_kernel_rules.txt13 security issue, or some "oh, that's not good" issue. In short, something
Dmagic-number.txt6 It is a *very* good idea to protect kernel data structures with magic
Dapplying-patches.txt110 everything looks good it has just moved up or down a bit, and patch will
235 these are good things, so do use mirrors when possible.
316 This is a good branch to run for people who want to help out testing
Dmemory-hotplug.txt64 for the purpose (B), but this is good phase for communication between
348 more work. Returning -EBUSY under some situation may be good because the user
Dadding-syscalls.txt52 indefinitely. As such, it's a very good idea to explicitly discuss the
449 call. A good way to combine these aims is to include a simple self-test
508 - Suggestion from Greg Kroah-Hartman that it's good for new system calls to
Dkmemcheck.txt32 as memcheck, but it turns out to be good enough in practice to discover real
123 enable kmemcheck in case of some problem, it might be a good idea to
632 good one, because it shows how one would go about to find out what the report
/linux-4.4.14/arch/cris/arch-v32/mach-a3/
DKconfig59 as inputs, although floating inputs isn't good.
79 as inputs, although floating inputs isn't good.
99 as inputs, although floating inputs isn't good.
/linux-4.4.14/arch/ia64/scripts/
Dcheck-gas13 echo good
/linux-4.4.14/Documentation/sound/alsa/
Dpowersave.txt12 good for laptops (even for desktops).
21 reopen the device frequently. 10 would be a good choice for normal
Dhdspm.txt3 (translated from German, so no good English ;-),
163 RME-PLL is very good, there are almost no problems with
/linux-4.4.14/drivers/infiniband/hw/mthca/
Dmthca_reset.c179 goto good; in mthca_reset()
190 good: in mthca_reset()
/linux-4.4.14/tools/testing/ktest/examples/include/
Dbisect.conf90 CONFIG_BISECT_GOOD = ${THIS_DIR}/config-good
/linux-4.4.14/Documentation/sound/oss/
DVIBRA1613 A good starting point is that the vibra16x chip full-duplex facility
58 So, after a good kernel modules compilation and a 'depmod -a kernel_ver'
DCMI833063 …In order to use CMI8330 under Linux you just have to use a proper isapnp.conf, a good isapnp and …
/linux-4.4.14/Documentation/usb/
Ddma.txt33 It's good to avoid making CPUs copy data needlessly. The costs can add up,
58 not using a streaming DMA mapping, so it's good for small transfers on
81 high memory to "normal" DMA memory. If you can come up with a good way
111 usbcore do the map/unmap.) Large periodic transfers make good examples
Dcallbacks.txt39 The ioctl interface (2) should be used only if you have a very good
73 initialisation that doesn't take too long is a good idea here.
Dauthorization.txt78 echo "We are good, connected"
Dgadget_printer.txt53 your other USB products if you have any. It would be a good idea to
56 bcdDevice - This is the version number of your product. It would be a good idea
Dpersist.txt50 entirely the BIOS's fault, but that doesn't do _you_ any good unless
98 now a good and happy place.
Dgadget_multi.txt49 The good news is: you do not have to worry about most of the
DCREDITS174 and that's good to allow for vendor specific quirks on the
/linux-4.4.14/Documentation/networking/
Deql.txt30 good 1 to 2 KB/s slower than the test machine working with a 28.8 Kbps
99 don't do a very good job when it comes to handling more than one
138 I haven't found a good reason to write it yet... other than for
139 completeness, but that isn't a good motivator is it?--)
227 DSLIP. I did find a good tip from LinuxNET:Billy for PPP performance:
386 The good news is that one gets nearly the full advantage of the
Dfilter.txt330 jeq #15, good /* __NR_rt_sigreturn */
331 jeq #231, good /* __NR_exit_group */
332 jeq #60, good /* __NR_exit */
333 jeq #0, good /* __NR_read */
334 jeq #1, good /* __NR_write */
335 jeq #5, good /* __NR_fstat */
336 jeq #9, good /* __NR_mmap */
337 jeq #14, good /* __NR_rt_sigprocmask */
338 jeq #13, good /* __NR_rt_sigaction */
339 jeq #35, good /* __NR_nanosleep */
[all …]
Ds2io.txt92 good performance.
De1000e.txt65 InterruptThrottleRate value of 8000, providing a good fallback value for
122 systems and is a good starting point, but the optimal value will
Darcnet.txt226 Linux has pretty good support for this now, but since I've been busy, the
358 two available protocols. As mentioned above, it's a good idea to use
359 only arc0 unless you have a good reason (like some other software, ie.
512 D_DURING or more, it would be a REALLY good idea to kill your klogd daemon
Dfib_trie.txt63 A good start for understanding this code. This function implements a
De1000.txt97 InterruptThrottleRate value of 8000, providing a good fallback value for
164 systems and is a good starting point, but the optimal value will
/linux-4.4.14/drivers/block/zram/
DKconfig11 good amounts of memory savings.
/linux-4.4.14/Documentation/filesystems/cifs/
DAUTHORS14 for proving years ago that very good smb/cifs clients could be done on Unix-like
38 Shaggy (Dave Kleikamp) for innumerable small fs suggestions and some good cleanup
/linux-4.4.14/include/linux/
Dhil_mlc.h99 int good; /* Node to jump to on success */ member
Dide.h92 #define OK_STAT(stat,good,bad) (((stat)&((good)|(bad)))==(good)) argument
/linux-4.4.14/scripts/
Dcheckpatch.pl3779 my $good = $fix_elements[$n] . $fix_elements[$n + 1];
3841 $good = $fix_elements[$n] . trim($fix_elements[$n + 1]) . " ";
3859 $good = rtrim($fix_elements[$n]) . trim($fix_elements[$n + 1]);
3888 $good = rtrim($fix_elements[$n]) . trim($fix_elements[$n + 1]);
3890 $good = $fix_elements[$n] . trim($fix_elements[$n + 1]);
3893 $good .= " ";
3911 $good = $fix_elements[$n] . " " . ltrim($fix_elements[$n + 1]);
3922 $good = $fix_elements[$n] . rtrim($fix_elements[$n + 1]);
3935 $good = $fix_elements[$n] . trim($fix_elements[$n + 1]) . " ";
3943 $good = rtrim($fix_elements[$n]) . trim($fix_elements[$n + 1]);
[all …]
DKbuild.include289 # This is a good hint that there is a bug in the kbuild file
334 # But it's only cosmetic, and $(patsubst "%",%,$(CONFIG_FOO)) is good
/linux-4.4.14/arch/s390/
DKconfig.debug28 It is probably not a good idea to enable this feature in a production
/linux-4.4.14/Documentation/devicetree/bindings/mtd/
Dlpc32xx-mlc.txt11 Hz, to make them independent of actual clock speed and to provide for good
/linux-4.4.14/drivers/staging/media/mn88473/
DTODO1 Driver general quality is not good enough for mainline. Also, other
/linux-4.4.14/Documentation/ABI/testing/
Ddebugfs-ec18 what you are doing! Rebooting afterwards also is a good idea.
Dsysfs-class-net-statistics106 Indicates the total number of good packets received by this
/linux-4.4.14/drivers/staging/media/mn88472/
DTODO1 Driver general quality is not good enough for mainline. Also, other
/linux-4.4.14/tools/testing/selftests/zram/
DREADME8 good amounts of memory savings. Some of the usecases include /tmp storage,
/linux-4.4.14/arch/arm/crypto/
DKconfig75 Rijndael appears to be consistently a very good performer in
79 good. Rijndael's very low memory requirements make it very well
/linux-4.4.14/Documentation/scsi/
Dqlogicfas.txt42 It may be a good idea to enable RESET_AT_START, especially if the
59 The best way to test if your cables, termination, etc. are good is to
Din2000.txt11 with. Done some heavy testing and it looks very good.
64 should take a good look at 'in2000_proc_info()' in the
111 Lots of good changes. Advice from Bill Earnest resulted
DNinjaSCSI.txt110 It works good when I using this driver right way. But I'm not guarantee
D53c700.txt61 This will be a standard SCSI driver (I don't know of a good document
/linux-4.4.14/Documentation/devicetree/bindings/pinctrl/
Dmarvell,dove-pinctrl.txt70 core-pwr-good Pin is used for CORE_PWR_GOOD (Pins 0-7 only)
71 cpu-pwr-good Pin is used for CPU_PWR_GOOD (Pins 8-15 only)
/linux-4.4.14/Documentation/crypto/
Dapi-intro.txt33 very simple, while hiding the core logic from both. Many good ideas
112 It's a good idea to avoid using lots of macros and use inlined functions
113 instead, as gcc does a good job with inlining, while excessive use of
/linux-4.4.14/Documentation/development-process/
D6.Followthrough10 It is a rare patch which is so good at its first posting that there is no
81 around. So it is always a good idea to remind reviewers of previously
82 raised issues and how you dealt with them; the patch changelog is a good
102 If a patch is considered to be a good thing to add to the kernel, and once
119 there's a good chance that you will get more comments from a new set of
194 far. If you are seen as needlessly blocking good work, those patches will
D5.Posting24 good idea to say so in the posting itself. Also mention any major work
96 good chance that it will be passed over and the important fix will be
152 The items above, together, form the changelog for the patch. Writing good
161 good changelog conveys the needed information to all of these people in the
279 When selecting recipients for a patch, it is good to have an idea of who
287 Patches need good subject lines. The canonical format for a patch line is
D7.AdvancedTopics45 Using git to generate patches for submission by email can be a good
102 makes good sense, but overly frequent merges can clutter the history
166 by the patch as a whole is a good thing for the kernel or not. Yet others
D8.Conclusion40 the shelves for a while now. Still, there is quite a bit of good
/linux-4.4.14/drivers/staging/media/bcm2048/
DTODO22 radio-si4713/si4713-i2c.c as a good example. But I would wait with that
/linux-4.4.14/Documentation/devicetree/bindings/pci/
Ddesignware-pcie.txt22 - reset-gpio: gpio pin number of power good signal
/linux-4.4.14/scripts/coccinelle/iterators/
Dlist_entry_update.cocci2 /// the list to the next, so it is usually not a good idea to reassign it.
/linux-4.4.14/tools/testing/ktest/
Dktest.pl2831 my $good = $bisect_good;
2845 $good = get_sha1($good);
2902 doprint "TESTING BISECT GOOD [$good]\n";
2903 run_command "git checkout $good" or
2904 die "Failed to checkout $good";
2909 fail "Tested BISECT_GOOD [$good] and it failed" and return 0;
2926 run_command "git bisect good $good" or
2927 dodie "could not set bisect good to $good";
/linux-4.4.14/Documentation/hwmon/
Dadm102187 ADM1021-clones do faster measurements, but there is really no good reason
100 loading the adm1021 module, then things are good.
Df71805f139 above the audible range, such as 25 kHz, may be a good choice; if this
140 doesn't give you good linear control, try reducing it. Fintek recommends
Dsubmitting-patches54 cleanup, but it is a good start.
/linux-4.4.14/Documentation/x86/i386/
DIO-APIC.txt76 necessity, PCI IRQs can be shared at will, but it's a good for performance
106 boards tend to have a good configuration.
/linux-4.4.14/Documentation/devicetree/bindings/mmc/
Dfsl-imx-esdhc.txt24 to select a proper data sampling window in case the clock quality is not good
/linux-4.4.14/Documentation/devicetree/bindings/
DABI.txt20 1) Maintainers, don't let perfect be the enemy of good. Don't hold up a
/linux-4.4.14/drivers/staging/android/
DKconfig14 It is, in theory, a good memory allocator for low-memory devices,
/linux-4.4.14/Documentation/video4linux/
Dhauppauge-wintv-cx88-ir.txt20 Setup 4KHz sampling rate (roughly 2x oversampled; good enough for our RC5
DREADME.saa713442 it is good for ...
Dsh_mobile_ceu_camera.txt129 good as possible, but it could have changed. Retrieve it again.
Dradiotrack.txt23 running the card, and found that it was good! Frans Brinkman made a
DREADME.cpia288 The default of 68k should be good for most users. This will handle
Dv4l2-controls.txt208 specific menu for an otherwise standard menu control. A good example for this
328 value is passed to the hardware. It is generally a good idea to call this
403 A good example is the MPEG Audio Layer II Bitrate menu control where the
679 use it. For example, this is not a good idea:
/linux-4.4.14/fs/ufs/
DKconfig17 good portable way to transport files and directories between unixes
/linux-4.4.14/fs/sysv/
DKconfig25 good portable way to transport files and directories between unixes
/linux-4.4.14/Documentation/video4linux/cx88/
Dhauppauge-wintv-cx88-ir.txt20 Setup 4KHz sampling rate (roughly 2x oversampled; good enough for our RC5
/linux-4.4.14/drivers/staging/media/lirc/
DTODO.lirc_zilog16 (The good news is ref-counting of lirc_zilog internal structures appears to be
/linux-4.4.14/arch/unicore32/kernel/
Dasm-offsets.c34 #error Known good compilers: 4.2.2
/linux-4.4.14/Documentation/input/
Djoystick-api.txt130 until it timeouts. There's a good example on the select(2)
188 sizeof(js_event) Again, if the buffer was full, it's a good idea to
214 JSIOGCVERSION is a good way to check in run-time whether the running
Dff.txt218 a really good reason to use this, please contact
Dxpad.txt51 report their values as 8 bit unsigned, not sure what this is good for.
/linux-4.4.14/Documentation/power/regulator/
Dmachine.txt58 used for the supply rail in the schematic is a good choice. If no
/linux-4.4.14/crypto/
DKconfig799 Rijndael appears to be consistently a very good performer in
803 good. Rijndael's very low memory requirements make it very well
821 Rijndael appears to be consistently a very good performer in
825 good. Rijndael's very low memory requirements make it very well
843 Rijndael appears to be consistently a very good performer in
847 good. Rijndael's very low memory requirements make it very well
873 Rijndael appears to be consistently a very good performer in
877 good. Rijndael's very low memory requirements make it very well
902 Rijndael appears to be consistently a very good performer in
906 good. Rijndael's very low memory requirements make it very well
[all …]
/linux-4.4.14/drivers/usb/
DREADME11 The USB specification has a good overview chapter, and USB
/linux-4.4.14/arch/arm/boot/dts/
Dtegra30-colibri.dtsi391 nvidia,cpu-pwr-good-time = <5000>;
393 nvidia,core-pwr-good-time = <3845 3845>;
Dtegra20-trimslice.dts313 nvidia,cpu-pwr-good-time = <5000>;
315 nvidia,core-pwr-good-time = <3845 3845>;
Dtegra20-tamonten.dtsi470 nvidia,cpu-pwr-good-time = <5000>;
472 nvidia,core-pwr-good-time = <3845 3845>;
Dtegra20-colibri-512.dtsi380 nvidia,cpu-pwr-good-time = <5000>;
382 nvidia,core-pwr-good-time = <3845 3845>;
Dtegra20-paz00.dts443 nvidia,cpu-pwr-good-time = <2000>;
445 nvidia,core-pwr-good-time = <3845 3845>;
Dtegra124-nyan.dtsi355 nvidia,cpu-pwr-good-time = <500>;
357 nvidia,core-pwr-good-time = <641 3845>;
Dtegra20-whistler.dts521 nvidia,cpu-pwr-good-time = <2000>;
523 nvidia,core-pwr-good-time = <0 3845>;
Dtegra20-ventana.dts517 nvidia,cpu-pwr-good-time = <2000>;
519 nvidia,core-pwr-good-time = <3845 3845>;
Dtegra30-cardhu.dtsi367 nvidia,cpu-pwr-good-time = <2000>;
369 nvidia,core-pwr-good-time = <3845 3845>;
Dtegra30-apalis.dtsi655 nvidia,cpu-pwr-good-time = <5000>;
657 nvidia,core-pwr-good-time = <3845 3845>;
Dtegra20-harmony.dts558 nvidia,cpu-pwr-good-time = <5000>;
560 nvidia,core-pwr-good-time = <3845 3845>;
Dtegra20-seaboard.dts682 nvidia,cpu-pwr-good-time = <5000>;
684 nvidia,core-pwr-good-time = <3845 3845>;
Dtegra124-venice2.dts886 nvidia,cpu-pwr-good-time = <500>;
888 nvidia,core-pwr-good-time = <641 3845>;
Dtegra114-dalmore.dts1094 nvidia,cpu-pwr-good-time = <500>;
1096 nvidia,core-pwr-good-time = <641 3845>;
/linux-4.4.14/arch/mips/include/asm/mach-cavium-octeon/
Dkernel-entry-init.h60 slti t1, t1, 2 # 66-P1.2 and later good.
/linux-4.4.14/arch/cris/arch-v10/
DKconfig268 good choice for most Axis products...
276 a good choice for most Axis products...
334 as inputs, although floating inputs isn't good.
/linux-4.4.14/drivers/input/serio/
Dhil_mlc.c645 ((rc < 0) ? node->bad : node->good); in hilse_donode()
666 nextidx = node->good; in hilse_donode()
720 nextidx = mlc->cts(mlc) ? node->bad : node->good; in hilse_donode()
/linux-4.4.14/Documentation/EDID/
DHOWTO.txt1 In the good old days when graphics parameters were configured explicitly
/linux-4.4.14/arch/m68k/
DKconfig110 interface is strongly in flux, so no good recommendation can be
/linux-4.4.14/Documentation/fb/
Dudlfb.txt19 can support surprisingly high resolutions with good performance for
64 means that from a hardware and fbdev software perspective, everything is good.
Dviafb.txt210 provide a good starting point to figure out which of those names match
/linux-4.4.14/Documentation/serial/
Dn_gsm.txt21 (a good starting point is util-linux-ng/sys-utils/ldattach.c)
/linux-4.4.14/Documentation/mmc/
Dmmc-dev-attrs.txt59 hence "preferred_erase_size" provides a good chunk
/linux-4.4.14/Documentation/devicetree/bindings/input/
Dads7846.txt61 ti,debounce-rep Additional consecutive good readings
/linux-4.4.14/drivers/leds/trigger/
DKconfig77 This allows LEDs to be controlled by gpio events. It's good
/linux-4.4.14/drivers/scsi/sym53c8xx_2/
Dsym_hipd.h1109 good: in sym_build_sge()
1115 goto good; in sym_build_sge()
/linux-4.4.14/Documentation/isdn/
DsyncPPP.FAQ195 A: A good help log is the debug output from the ipppd...
210 -> not good ... check /var/adm/syslog and /var/adm/daemon.
/linux-4.4.14/arch/arm64/
DKconfig.debug13 It is probably not a good idea to enable this feature in a production
/linux-4.4.14/drivers/net/ethernet/cavium/thunder/
Dnicvf_queues.h185 u64 good; member
/linux-4.4.14/fs/proc/
DKconfig61 As it is generally a good thing, you should say Y here unless
/linux-4.4.14/Documentation/timers/
Dtimers-howto.txt78 - Why is there no "usleep" / What is a good range?
DNO_HZ.txt251 We do not currently have a good way to remove OS jitter from single-CPU
311 runtime, there would need to be an earthshakingly good reason.
Dhrtimers.txt25 code is very good and tight code, there's zero problems with it in its
/linux-4.4.14/drivers/net/slip/
DKconfig77 end of the link as well. It's good enough, for example, to run IP
/linux-4.4.14/Documentation/devicetree/bindings/power/
Drockchip-io-domain.txt25 this driver would handle telling the SoC about it. A good example is
/linux-4.4.14/Documentation/filesystems/
Dbefs.txt63 scope of this document. I suggest the Kernel-HOWTO document as a good general
Dinotify.txt36 There are other good arguments. With a single fd, there is a single
Dhpfs.txt94 chgrp symlinks but I don't know what is it good for. chmoding symlink results
110 partition. It marked file name codepage as 850 - good. But when I again booted
160 You can't rename over directories (what is it good for?).
Docfs2.txt73 will hurt performance, but it's good for data-safety.
Dceph.txt4 Ceph is a distributed network file system designed to provide good
/linux-4.4.14/Documentation/w1/masters/
Dds249041 removed it can produce a good amount of error output before the bus
/linux-4.4.14/drivers/extcon/
DKconfig11 also good examples.
/linux-4.4.14/Documentation/filesystems/nfs/
Dnfs-rdma.txt160 Before configuring the NFS/RDMA software, it is a good idea to test
162 In particular, it is a good idea to verify that the RDMA stack
Dknfsd-stats.txt81 network-facing NFS work is being handled quickly, which is a good
/linux-4.4.14/arch/mips/include/asm/octeon/
Dcvmx-sriox-defs.h1178 uint64_t good:16; member
1180 uint64_t good:16;
1726 uint64_t good:16; member
1728 uint64_t good:16;
/linux-4.4.14/Documentation/fmc/
DFMC-and-SDB.txt63 this package can make good use of it. SDB itself is developed in the
/linux-4.4.14/Documentation/RCU/
DNMI-RCU.txt52 anyway. However, in practice it is a good documentation aid, particularly
/linux-4.4.14/Documentation/mtd/nand/
Dpxa3xx-nand.txt109 for this is that there's no point in marking a block as bad, because good
/linux-4.4.14/Documentation/firmware_class/
DREADME105 - Why OPTIONAL in-kernel persistence may be a good idea sometimes:
/linux-4.4.14/arch/arm/kernel/
Dasm-offsets.c51 #error Known good compilers: 3.3, 4.x
/linux-4.4.14/Documentation/driver-model/
Dplatform.txt121 The only "good" reason for this is to handle older system designs which, like
234 as possible may be good for the serial port case.
Ddevres.txt22 example, a plain SFF ATA controller (that is, good old PCI IDE) in
/linux-4.4.14/block/partitions/
DKconfig168 removable IDE drives. Note, however, that a good portable way to
235 drives; note however that a good portable way to transport files and
/linux-4.4.14/drivers/block/aoe/
Daoecmd.c735 int i, good; in count_targets() local
737 for (i = good = 0; i < d->ntargets && d->targets[i]; ++i) in count_targets()
739 good++; in count_targets()
742 *untainted = good; in count_targets()
/linux-4.4.14/arch/powerpc/platforms/powermac/
Dpci.c1110 goto good; in pmac_pci_fixup_pciata()
1115 good: in pmac_pci_fixup_pciata()
/linux-4.4.14/Documentation/i2c/busses/
Di2c-piix441 SMBus - you can not access it on I2C levels. The good news is that it
Di2c-parport86 the i2c-parport module might be a good safety since data line state
Di2c-i801149 drivers/pci/quirks.c. Then please give it very good testing, to make sure
/linux-4.4.14/arch/x86/kernel/
Dhead_64.S381 jz 20f # All good
/linux-4.4.14/Documentation/devicetree/bindings/net/
Dfsl-tsec-phy.txt104 Here is how to figure good values:
/linux-4.4.14/arch/x86/math-emu/
DREADME66 (3) The sqrt function has been tuned to get good performance. It is based
72 based upon getting good accuracy with reasonable speed.
305 good as the results from an 80486 FPU. From version 1.20, the accuracy
/linux-4.4.14/net/netfilter/ipvs/
DKconfig59 to your virtual server application. It is good to set the table size
64 should be not far less than 200x200, it is good to set the table
/linux-4.4.14/drivers/media/usb/gspca/
Dzc3xx.c5938 int change, good; in transfer_update() local
5944 good = 0; in transfer_update()
5965 good = 0; in transfer_update()
5974 good++; in transfer_update()
5975 if (good >= 10) { in transfer_update()
5976 good = 0; in transfer_update()
/linux-4.4.14/Documentation/scheduler/
Dsched-nice-design.txt82 proof, and a buggy SCHED_FIFO app can also lock up the system for good.
Dcompletion.txt53 Completions should be named to convey the intent of the waiter. A good
/linux-4.4.14/Documentation/vm/
Dksm.txt91 A high ratio of pages_sharing to pages_shared indicates good sharing, but
Dbalance39 zone. The good part is, while balancing, we do not need to look at sizes
/linux-4.4.14/arch/x86/
DKconfig.debug80 It is probably not a good idea to enable this feature in a production
327 this algorithm is so good that allowing gcc 4.x and above to make the
/linux-4.4.14/Documentation/s390/
DDebugging390.txt10 This document is intended to give a good overview of how to debug Linux for
188 vector table. This is a good thing & does simplify some of the kernel coding
760 you get good at it.
764 felt that it was a good idea not to go over the 80 columns on the screen.
766 decode mentally and you can make a good guess at a lot of them as all the
904 script with breakpoints on every kernel procedure, this isn't a good idea
909 in the file menu called "Save Screen In File" - this is very good for keeping a
1114 under VM ( unless you are good at decoding ASCII in your head ).
1493 A good trick is tracing all the IO's and CCWS and spooling them into the reader
1585 Note gdb's online help is very good use it.
[all …]
/linux-4.4.14/Documentation/device-mapper/
Dverity.txt87 booting from a known-good device (like a USB drive or CD).
Dcache-policies.txt58 since spindles tend to have good sequential I/O bandwidth. The
/linux-4.4.14/Documentation/video4linux/bttv/
DSound-FAQ119 know what the other elements in the tvcards array are good for:
/linux-4.4.14/Documentation/ABI/stable/
Dsysfs-class-ubi115 Total number of good (not marked as bad) physical eraseblocks on
/linux-4.4.14/arch/ia64/
DKconfig472 a good idea to turn this on. If you're unsure, say Y.
533 interface is strongly in flux, so no good recommendation can be
/linux-4.4.14/fs/cramfs/
DREADME138 value don't get as good compression as they can.
/linux-4.4.14/sound/drivers/
DKconfig209 good choice for normal operations.
/linux-4.4.14/arch/s390/kernel/
Dhead.S332 lpsw 3f-.LPG0(%r13) # machine type not good enough, crash
/linux-4.4.14/arch/mips/cavium-octeon/
Docteon-memcpy.S407 LOAD t0, THREAD_BUADDR(t0) # t0 is just past last good address
/linux-4.4.14/Documentation/i2c/
Dslave-interface154 It is good behaviour to always ACK the address phase, so the master knows if a
/linux-4.4.14/Documentation/locking/
Dspinlocks.txt142 wake up. So read-locks are safe (which is good: they are very common
/linux-4.4.14/fs/squashfs/
DKconfig117 file systems. It offers a good trade-off between compression
/linux-4.4.14/Documentation/arm64/
Darm-acpi.txt17 specifications, then ACPI may not be a good fit for the hardware.
32 reasoning behind ACPI on ARMv8 servers. Actually, we snitch a good portion
79 integrated devices, but there are no good processes for supporting what the
/linux-4.4.14/Documentation/power/
Dpower_supply_class.txt165 time. Batteries are good example. So, batteries usually care if they're
Dvideo.txt84 your video card (good luck getting docs :-(). Maybe suspending from X
/linux-4.4.14/Documentation/watchdog/
Dwatchdog-api.txt47 good idea, since if there is a bug in the watchdog daemon and it
/linux-4.4.14/Documentation/thermal/
Dpower_allocator.txt244 won't be very good. Note that this is not particular to this
/linux-4.4.14/Documentation/blockdev/
Dzram.txt9 good amounts of memory savings. Some of the usecases include /tmp storage,
/linux-4.4.14/Documentation/pps/
Dpps.txt232 transition. The default of 30us should be good enough in most situations.
/linux-4.4.14/drivers/net/ethernet/octeon/
Docteon_mgmt.c404 good: in octeon_mgmt_receive_one()
446 goto good; in octeon_mgmt_receive_one()
/linux-4.4.14/arch/mips/lib/
Dmemcpy.S561 LOADK t0, THREAD_BUADDR(t0) # t0 is just past last good address
/linux-4.4.14/tools/perf/Documentation/
Dperf-probe.txt173 many lines to show by using 'NUM'. Moreover, 'FUNC@SRC' combination is good

12