Searched refs:changes (Results 1 – 25 of 335) sorted by relevance
12345678910>>...14
| /Documentation/devicetree/ |
| D | changesets.txt | 1 A DT changeset is a method which allows one to apply changes
2 in the live tree in such a way that either the full set of changes
8 When a changeset is applied, all of the changes get applied to the tree
20 a set of changes. No changes to the active tree are made at this point.
27 4. of_changeset_apply() - Apply the changes to the tree. Either the
|
| /Documentation/laptops/ |
| D | dslm.c | 78 int changes = 0; in measure() local
92 changes++; in measure()
107 changes--; /* Compensate for SIGINT */ in measure()
111 printf(" State changed %d times\n", changes); in measure()
|
| /Documentation/virtual/kvm/ |
| D | review-checklist.txt | 20 7. Emulator changes should be accompanied by unit tests for qemu-kvm.git
24 are better than duplicating changes to vendor code.
26 9. Similarly, prefer changes to arch independent code than to arch dependent
|
| /Documentation/development-process/ |
| D | 7.AdvancedTopics | 37 of the mainline repository, explore the revision history, commit changes to
77 Rewriting history will rewrite the changes contained in that history,
86 So, once you push a set of changes to your publicly-available server, those
87 changes should not be rewritten. Git will attempt to enforce this rule if
88 you try to push changes which do not result in a fast-forward merge
89 (i.e. changes which do not share the same history). It is possible to
97 As the mainline (or other tree upon which a set of changes is based)
105 release). If you are nervous about specific changes, you can always
112 slip in ill-advised changes which go into the mainline below the review
126 should not be making changes to the core memory management code. And, most
[all …]
|
| D | 5.Posting | 71 resolving conflicts and dealing with API changes.
73 Only the most simple changes should be formatted as a single patch;
74 everything else should be made as a logical series of changes. Splitting
80 changes found in your working revision control system. Instead, the
81 changes you have made need to be considered in their final form, then
83 discrete, self-contained changes, not the path you took to get to those
84 changes.
87 patch. These changes can be small ("add a field to this structure") or
94 changes in the same patch. If a single patch fixes a critical security
172 support other changes coming in later patch, say so. If internal APIs are
[all …]
|
| D | 2.Process | 25 API changes, and more. A typical 2.6 release can contain nearly 10,000
26 changesets with changes to several hundred thousand lines of code. 2.6 is
28 rolling development model which is continually integrating major changes.
34 community) is merged into the mainline kernel. The bulk of changes for a
35 new development cycle (and all of the major changes) will be merged during
36 this time, at a rate approaching 1,000 changes ("patches," or "changesets")
39 (As an aside, it is worth noting that the changes integrated during the
94 worse; the pile of changes waiting for the next merge window will grow
137 and controversial changes, go on for years. Much developer frustration
170 getting feedback about changes that are needed, you should either
[all …]
|
| /Documentation/ |
| D | irqflags-tracing.txt | 19 state changes. But an architecture can be irq-flags-tracing enabled in a
23 code-organizational changes first:
27 and then a couple of functional changes are needed as well to implement
48 changes break other code by modifying conditions or registers that
|
| D | SubmittingPatches | 57 All changes to the Linux kernel occur in the form of patches, as
95 If your changes produce a lot of deltas, you need to split them into
106 2) Describe your changes.
155 Describe your changes in imperative mood, e.g. "make xyzzy do frotz"
201 3) Separate your changes.
206 For example, if your changes include both bug fixes and performance
207 enhancements for a single driver, separate those changes into two
208 or more patches. If your changes include an API update, and a new
212 group those changes into a single patch. Thus a single logical change
234 4) Style-check your changes.
[all …]
|
| /Documentation/power/regulator/ |
| D | design.txt | 17 => The API should make no changes to the hardware state unless it has
18 specific knowledge that these changes are safe to perform on this
|
| D | consumer.txt | 83 when enabled, then the voltage changes instantly, otherwise the voltage
84 configuration changes and the voltage is physically set when the regulator is
113 when enabled, then the current limit changes instantly, otherwise the current
114 limit configuration changes and the current limit is physically set when the
131 changes. e.g. consumer driver is idle and subsequently draws less current
|
| /Documentation/ABI/testing/ |
| D | sysfs-driver-toshiba_acpi | 15 a reboot for changes to take effect.
112 Note that toggling this value requires a reboot for changes to
156 Note that toggling this value requires a reboot for changes to
168 Note that toggling this value requires a reboot for changes to
179 Note that toggling this value requires a reboot for changes to
|
| /Documentation/memory-devices/ |
| D | ti-emif.txt | 30 temperature changes
45 EMIF driver registers notifiers for voltage and frequency changes
|
| /Documentation/filesystems/ |
| D | xfs-delayed-logging-design.txt | 9 logged are made up of the changes to in-core structures rather than on-disk
10 structures. Other objects - typically buffers - have their physical changes
23 changes in the new transaction that is written to the log.
25 That is, if we have a sequence of changes A through to F, and the object was
40 the aggregation of all the previous changes currently held only in the log.
62 the log - repeated operations to the same objects write the same changes to
79 Effectively, this gives us the maximum bound of outstanding metadata changes
98 contains all the changes from the previous changes. In other words, we have one
109 infrastructure to keep track of logical changes in memory prior to physically
110 formatting the changes in a transaction to the log buffer. Hence we cannot avoid
[all …]
|
| /Documentation/scsi/ |
| D | ChangeLog.ncr53c8xx | 12 - Merge changes for linux-2.4 that declare the host template
123 through the /proc FS (rather cosmetic changes that consist in
131 some minor changes. The driver can now attach any number of
267 - Cosmetic changes for sparc (but not for the driver) that needs
292 does not have all the Sparc changes of the vger tree.
308 changes, etc ...
333 - Linux config changes for 2.0.34:
343 - Some other minor changes.
353 - Several aggressive SCRIPTS optimizations and changes:
357 - Miscallaneous changes in the C code:
[all …]
|
| /Documentation/video4linux/ |
| D | README.saa7134 | 40 Please mail me unified diffs ("diff -u") with your changes, and don't
41 forget to tell me what it changes / which problem it fixes / whatever
|
| /Documentation/cpu-freq/ |
| D | core.txt | 33 policy changes (ex. thermal modules like ACPI) or of all
34 frequency changes (ex. timing code) or even need to force certain
36 kernel "constant" loops_per_jiffy is updated on frequency changes
|
| /Documentation/ABI/stable/ |
| D | firewire-cdev | 51 during its entire life time. Bus topology changes, and hence
52 node ID changes, are tracked by firewire-core. ABI users do not
96 with the file descriptor, back out any changes to the local
|
| D | sysfs-driver-qla2xxx | 7 Users: qla2xxx-udev.sh. Proposed changes should be mailed to
|
| D | o2cb | 9 Users: ocfs2-tools. It's sufficient to mail proposed changes to
|
| /Documentation/leds/ |
| D | ledtrig-transient.txt | 37 Driver suspend changes the LED state to LED_OFF and resume doesn't change
40 changes are suspended while the driver is in suspend state. Any timers
45 LED state changes are controlled using brightness which is a common led
53 active, in which case LED state changes to LED_OFF.
62 state, the LED state changes to LED_OFF.
|
| /Documentation/devicetree/bindings/input/ |
| D | tca8418_keypad.txt | 2 changes:
|
| /Documentation/hwmon/ |
| D | acpi_power_meter | 49 power[1-*]_cap will be notified if the firmware changes the power cap.
50 power[1-*]_interval will be notified if the firmware changes the averaging
|
| /Documentation/ABI/ |
| D | README | 27 aware of changes that can occur before these interfaces move to
31 notify them if any changes occur (see the description of the
52 it changes. This is very important for interfaces in
|
| /Documentation/isdn/ |
| D | HiSax.cert | 20 version and the tested hardware. Any changes to the HiSax source code may
43 changes in HiSax do not affect the certification.
72 Please send any changes, bugfixes and patches to me rather than implementing
|
| /Documentation/ABI/removed/ |
| D | o2cb | 9 Users: ocfs2-tools. It's sufficient to mail proposed changes to
|
12345678910>>...14