Searched full:good (Results 1 – 25 of 295) sorted by relevance
12345678910>>...12
| /Documentation/leds/ |
| D | well-known-leds.txt | 10 use one of the "good" names from this list, and you should extend the
14 wants to use particular feature, you should probe for good name, first,
31 Good: "input*:*:player-{1,2,3,4,5}
35 Good: "input*:*:capslock"
36 Good: "input*:*:scrolllock"
37 Good: "input*:*:numlock"
54 Good: "platform:*:mute"
55 Good: "platform:*:micmute"
68 Good: "platform:*:charging" (allwinner sun50i)
72 Good: ":backlight" (Motorola Droid 4)
|
| /Documentation/admin-guide/ |
| D | bug-bisect.rst | 45 $ git bisect good [commit]
50 $ git bisect good
61 4.8 is good, you could do::
65 $ git bisect good v4.8
68 .. [#f1] You can, optionally, provide both good and bad arguments at git
69 start with ``git bisect start [BAD] [GOOD]``
|
| /Documentation/driver-api/gpio/ |
| D | using-gpio.rst | 10 For examples of already existing generic drivers that will also be good
28 to any existing kernel subsystem and not be a good fit for an operating system,
32 Applications that have a good reason to use the industrial I/O (IIO) subsystem
33 from userspace will likely be a good fit for using GPIO lines from userspace as
|
| /Documentation/process/ |
| D | management-style.rst | 113 not. After all, if **they** aren't certain whether it's a good idea, you
170 - get really good at apologies
183 3) People II - the Good Kind
202 good idea - go wild", or "That sounds good, but what about xxx?". The
209 specific directions, but let's face it, they might be good at what they
210 do, and suck at everything else. The good news is that people tend to
211 naturally gravitate back to what they are good at, so it's not like you
223 best way of taking the blame: do it for someone else. You'll feel good
224 for taking the fall, they'll feel good about not getting blamed, and the
238 you've followed the previous rules, you'll be pretty good at saying that
[all …]
|
| D | 6.Followthrough.rst | 13 It is a rare patch which is so good at its first posting that there is no
85 around. So it is always a good idea to remind reviewers of previously
86 raised issues and how you dealt with them; the patch changelog is a good
107 If a patch is considered to be a good thing to add to the kernel, and once
124 there's a good chance that you will get more comments from a new set of
200 far. If you are seen as needlessly blocking good work, those patches will
|
| D | howto.rst | 28 parts written in assembly. A good understanding of C is required for
31 are not a good substitute for a solid C education and/or years of
32 experience, the following books are good for, if anything, reference:
164 A good introduction describing exactly what a patch is and how to
352 in the main kernel source directory has a good
400 Please remember to follow good behavioral habits when using the lists.
407 get pretty large. Don't remove anybody from the CC: list without a good
423 good first test is to send the mail to yourself and try to apply your
479 Good things to say regarding your proposed changes:
491 good..."
[all …]
|
| D | 5.Posting.rst | 29 good idea to say so in the posting itself. Also mention any major work
103 good chance that it will be passed over and the important fix will be
162 The items above, together, form the changelog for the patch. Writing good
171 good changelog conveys the needed information to all of these people in the
301 When selecting recipients for a patch, it is good to have an idea of who
309 Patches need good subject lines. The canonical format for a patch line is
|
| D | submit-checklist.rst | 34 4) ppc64 is a good architecture for cross-compilation checking because it
101 ``make EXTRA_CFLAGS=-W``). This will generate lots of noise, but is good
|
| /Documentation/devicetree/bindings/arm/tegra/ |
| D | nvidia,tegra20-pmc.yaml | 82 nvidia,cpu-pwr-good-en:
85 CPU power good signal from external PMIC to PMC is enabled.
96 nvidia,cpu-pwr-good-time:
98 description: CPU power good time in uSec.
104 nvidia,core-pwr-good-time:
108 Core power good time in uSec.
315 "nvidia,core-pwr-off-time": ["nvidia,core-pwr-good-time"]
316 "nvidia,cpu-pwr-off-time": ["nvidia,cpu-pwr-good-time"]
334 nvidia,cpu-pwr-good-time = <0>;
336 nvidia,core-pwr-good-time = <4587 3876>;
|
| /Documentation/arm/ |
| D | mem_alignment.rst | 8 bad idea to configure it out, but Russell King has some good reasons for
20 trap to SIGBUS any code performing unaligned access (good for debugging bad
26 Please note that randomly changing the behaviour without good thought is
|
| /Documentation/sound/designs/ |
| D | powersave.rst | 13 good for laptops (even for desktops).
22 reopen the device frequently. 10 would be a good choice for normal
|
| /Documentation/driver-api/usb/ |
| D | dma.rst | 36 It's good to avoid making CPUs copy data needlessly. The costs can add up,
61 not using a streaming DMA mapping, so it's good for small transfers on
84 high memory to "normal" DMA memory. If you can come up with a good way
114 usbcore do the map/unmap.) Large periodic transfers make good examples
|
| /Documentation/admin-guide/cgroup-v1/ |
| D | memcg_test.rst | 157 When you do test to do racy case, it's good test to set memcg's limit
169 SwapCache. Test with shmem/tmpfs is always good test.
212 memory hotplug test is one of good test.
242 running new jobs in new group is also good.
247 Mounting with other subsystems is a good test because there is a
263 For example, test like following is good:
355 It's good idea to test root cgroup as well.
|
| /Documentation/admin-guide/cifs/ |
| D | authors.rst | 19 for proving years ago that very good smb/cifs clients could be done on Unix-like
44 - Shaggy (Dave Kleikamp) for innumerable small fs suggestions and some good cleanup
|
| /Documentation/x86/i386/ |
| D | IO-APIC.rst | 82 necessity, PCI IRQs can be shared at will, but it's a good for performance
112 boards tend to have a good configuration.
120 Good luck and mail to linux-smp@vger.kernel.org or
|
| /Documentation/userspace-api/media/dvb/ |
| D | frontend_legacy_dvbv3_api.rst | 10 TV standards, doesn't provide good statistics measurements and provides
|
| /Documentation/maintainer/ |
| D | rebasing-and-merging.rst | 67 - Do not reparent a tree without a good reason to do so. Just being on a
69 generally a good reason.
141 there's a good chance that a subsequent pull request will be rejected.
171 in the 5.1 development cycle) and has gotten quite good at conflict
183 pull request is a good idea. It may alert you to problems that you somehow
|
| /Documentation/livepatch/ |
| D | cumulative-patches.rst | 67 A good practice is to set .replace flag in any released livepatch.
101 A good practice might be to remove shadow variables in the post-unpatch
|
| /Documentation/ABI/testing/ |
| D | debugfs-ec | 19 what you are doing! Rebooting afterwards also is a good idea.
|
| /Documentation/filesystems/ |
| D | zonefs.rst | 192 offline zone back to an operational good state. Similarly to zone read-only
222 but only if the file zone is still in a good condition and there is no
266 | | good | fixed yes no yes yes |
270 | | good | fixed yes no yes yes |
274 | | good | 0 no no yes yes |
278 | | good | fixed yes yes yes yes |
292 with mkfs.zonefs (mkzonefs) will not change back offline zone files to a good
298 zone-offline mount options are temporary for zones in a good condition.
302 actions, that is, file size fixes for zones in a good condition. Zones
|
| /Documentation/scsi/ |
| D | qlogicfas.rst | 49 It may be a good idea to enable RESET_AT_START, especially if the
68 The best way to test if your cables, termination, etc. are good is to
|
| /Documentation/networking/ |
| D | eql.rst | 37 good 1 to 2 KB/s slower than the test machine working with a 28.8 Kbps
100 don't do a very good job when it comes to handling more than one
129 I haven't found a good reason to write it yet... other than for
130 completeness, but that isn't a good motivator is it?--)
187 DSLIP. I did find a good tip from LinuxNET:Billy for PPP performance:
290 The good news is that one gets nearly the full advantage of the
|
| /Documentation/crypto/ |
| D | api-intro.rst | 38 very simple, while hiding the core logic from both. Many good ideas
121 It's a good idea to avoid using lots of macros and use inlined functions
122 instead, as gcc does a good job with inlining, while excessive use of
|
| /Documentation/devicetree/bindings/mtd/ |
| D | lpc32xx-mlc.txt | 11 Hz, to make them independent of actual clock speed and to provide for good
|
| /Documentation/hwmon/ |
| D | adm1021.rst | 127 ADM1021-clones do faster measurements, but there is really no good reason
140 loading the adm1021 module, then things are good.
|
12345678910>>...12