Searched full:good (Results 1 – 25 of 352) sorted by relevance
12345678910>>...15
| /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"
61 Good: "rgb:status"
69 Good: "platform:*:charging" (allwinner sun50i, leds-cht-wcove)
[all …]
|
| /Documentation/filesystems/bcachefs/ |
| D | CodingStyle.rst | 6 Good development is like gardening, and codebases are our gardens. Tend to them
12 good. But appreciate beauty when you see it - and let people know.
20 Good code is readable code, where the structure is simple and leaves nowhere
37 Assertions are documentation that can't go out of date. Good assertions are
40 Good assertions drastically and dramatically reduce the amount of testing
43 Good assertions are based on state, not logic. To write good assertions, you
46 Good invariants and assertions will hold everywhere in your codebase. This
51 A good assertion checks something that the compiler could check for us, and
63 Good code is code where you can poke around and see what it's doing -
83 labels, and good structure - we don't want files with a list of bare integers,
[all …]
|
| /Documentation/translations/zh_CN/admin-guide/ |
| D | bug-bisect.rst | 49 $ git bisect good [commit]
54 $ git bisect good
67 $ git bisect good v4.8
71 ``git bisect start [BAD] [GOOD]``
|
| /Documentation/translations/zh_TW/admin-guide/ |
| D | bug-bisect.rst | 52 $ git bisect good [commit]
57 $ git bisect good
70 $ git bisect good v4.8
74 ``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
92 around. So it is always a good idea to remind reviewers of previously
93 raised issues and how you dealt with them; the patch changelog is a good
114 If a patch is considered to be a good thing to add to the kernel, and once
131 there's a good chance that you will get more comments from a new set of
207 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:
163 A good introduction describing exactly what a patch is and how to
398 Please remember to follow good behavioral habits when using the lists.
405 get pretty large. Don't remove anybody from the CC: list without a good
421 good first test is to send the mail to yourself and try to apply your
477 Good things to say regarding your proposed changes:
489 good..."
511 comfortable with English. A good grasp of the language can be needed in
[all …]
|
| /Documentation/devicetree/bindings/soc/tegra/ |
| D | nvidia,tegra20-pmc.yaml | 72 nvidia,cpu-pwr-good-en:
74 description: CPU power good signal from external PMIC to PMC is enabled
87 nvidia,cpu-pwr-good-time:
89 description: CPU power good time in microseconds
95 nvidia,core-pwr-good-time:
97 description: core power good time in microseconds
369 nvidia,core-pwr-off-time: ["nvidia,core-pwr-good-time"]
370 nvidia,cpu-pwr-off-time: ["nvidia,cpu-pwr-good-time"]
388 nvidia,cpu-pwr-good-time = <0>;
390 nvidia,core-pwr-good-time = <4587 3876>;
|
| /Documentation/devicetree/bindings/mfd/ |
| D | silergy,sy7636a.yaml | 30 epd-pwr-good-gpios:
32 Specifying the power good GPIOs.
|
| /Documentation/arch/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/gpu/amdgpu/display/ |
| D | display-contributing.rst | 11 this is a static page, and it is always a good idea to try to reach developers
34 you wish to contribute to the display code but are unsure where a good place
74 if a set of functions has a proper prefix, it becomes easy to create a good
98 task, it would be a good idea to find a tool that can discover code duplication
152 display output fidelity, it would be good if this option was something that
|
| /Documentation/admin-guide/cgroup-v1/ |
| D | memcg_test.rst | 148 When you do test to do racy case, it's good test to set memcg's limit
160 SwapCache. Test with shmem/tmpfs is always good test.
203 memory hotplug test is one of good test.
231 running new jobs in new group is also good.
236 Mounting with other subsystems is a good test because there is a
252 For example, test like following is good:
344 It's good idea to test root cgroup as well.
|
| /Documentation/devicetree/bindings/hwmon/ |
| D | adi,ltc4282.yaml | 111 good (PULL the pin low when power is not good) or that power is bad (Go
112 into high-z when power is not good).
|
| /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
|
| /Documentation/filesystems/iomap/ |
| D | porting.rst | 58 ``FS_IOC_FIEMAP`` is a good first target because it is trivial to
61 If FIEMAP is returning the correct information, it's a good sign that
89 XFS is a good example of this.
|
| /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/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/arch/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/gpu/rfc/ |
| D | index.rst | 5 For complex work, especially new uapi, it is often good to nail the high level
|
| /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/networking/ |
| D | filter.rst | 348 jeq #15, good /* __NR_rt_sigreturn */
349 jeq #231, good /* __NR_exit_group */
350 jeq #60, good /* __NR_exit */
351 jeq #0, good /* __NR_read */
352 jeq #1, good /* __NR_write */
353 jeq #5, good /* __NR_fstat */
354 jeq #9, good /* __NR_mmap */
355 jeq #14, good /* __NR_rt_sigprocmask */
356 jeq #13, good /* __NR_rt_sigaction */
357 jeq #35, good /* __NR_nanosleep */
[all …]
|
| /Documentation/ABI/testing/ |
| D | debugfs-ec | 19 what you are doing! Rebooting afterwards also is a good idea.
|
12345678910>>...15