Searched full:changes (Results 1 – 25 of 517) sorted by relevance
12345678910>>...21
| /Documentation/devicetree/ |
| D | changesets.rst | 7 A DT changeset is a method which allows one to apply changes
8 in the live tree in such a way that either the full set of changes
14 When a changeset is applied, all of the changes get applied to the tree
26 a set of changes. No changes to the active tree are made at this point.
30 3. of_changeset_apply() - Apply the changes to the tree. Either the
|
| /Documentation/core-api/ |
| D | refcount-vs-atomic.rst | 79 Function changes:
84 Memory ordering guarantee changes:
92 Function changes:
97 Memory ordering guarantee changes:
104 Function changes:
108 Memory ordering guarantee changes:
116 Function changes:
121 Memory ordering guarantees changes:
132 Function changes:
137 Memory ordering guarantees changes:
[all …]
|
| /Documentation/virt/kvm/ |
| D | review-checklist.rst | 23 7. Emulator changes should be accompanied by unit tests for qemu-kvm.git
26 8. Changes should be vendor neutral when possible. Changes to common code
27 are better than duplicating changes to vendor code.
29 9. Similarly, prefer changes to arch independent code than to arch dependent
|
| /Documentation/process/ |
| D | 7.AdvancedTopics.rst | 41 of the mainline repository, explore the revision history, commit changes to
74 you have been working on it for months. Changes can be transparently
81 Rewriting history will rewrite the changes contained in that history,
90 So, once you push a set of changes to your publicly-available server, those
91 changes should not be rewritten. Git will attempt to enforce this rule if
92 you try to push changes which do not result in a fast-forward merge
93 (i.e. changes which do not share the same history). It is possible to
101 As the mainline (or other tree upon which a set of changes is based)
109 release). If you are nervous about specific changes, you can always
116 slip in ill-advised changes which go into the mainline below the review
[all …]
|
| D | 5.Posting.rst | 78 resolving conflicts and dealing with API changes.
80 Only the most simple changes should be formatted as a single patch;
81 everything else should be made as a logical series of changes. Splitting
87 changes found in your working revision control system. Instead, the
88 changes you have made need to be considered in their final form, then
90 discrete, self-contained changes, not the path you took to get to those
91 changes.
94 patch. These changes can be small ("add a field to this structure") or
101 changes in the same patch. If a single patch fixes a critical security
182 support other changes coming in later patch, say so. If internal APIs are
[all …]
|
| D | 2.Process.rst | 30 API changes, and more. A typical release can contain about 13,000
31 changesets with changes to several hundred thousand lines of code. 5.x is
33 rolling development model which is continually integrating major changes.
39 community) is merged into the mainline kernel. The bulk of changes for a
40 new development cycle (and all of the major changes) will be merged during
41 this time, at a rate approaching 1,000 changes ("patches," or "changesets")
44 (As an aside, it is worth noting that the changes integrated during the
101 worse; the pile of changes waiting for the next merge window will grow
155 and controversial changes, go on for years. Much developer frustration
188 getting feedback about changes that are needed, you should either
[all …]
|
| D | index.rst | 14 it much easier for you to get your changes merged with a minimum of
40 changes
|
| /Documentation/ABI/stable/ |
| D | sysfs-driver-aspeed-vuart | 6 Users: OpenBMC. Proposed changes should be mailed to
14 Users: OpenBMC. Proposed changes should be mailed to
23 Users: OpenBMC. Proposed changes should be mailed to
|
| /Documentation/userspace-api/media/v4l/ |
| D | vidioc-dqevent.rst | 130 control's value changes, if a button control is pressed or if the
148 second-oldest event is kept, but the ``changes`` field of the
149 second-oldest event is ORed with the ``changes`` field of the
176 associated with it. The ``changes`` bitfield denotes what has
178 application could dequeue them, then the changes will have the
183 the regions changes. This event has a struct
215 - ``changes``
217 :ref:`ctrl-changes-flags`.
279 - ``changes``
281 :ref:`src-changes-flags`.
[all …]
|
| /Documentation/devicetree/bindings/power/supply/ |
| D | lt3651-charger.txt | 17 The driver will attempt to aquire interrupts for all GPIOs to detect changes in
19 cannot report changes and userspace will need to periodically read the sysfs
20 attributes to detect changes.
|
| /Documentation/core-api/irq/ |
| D | irqflags-tracing.rst | 21 state changes. But an architecture can be irq-flags-tracing enabled in a
25 code-organizational changes first:
29 and then a couple of functional changes are needed as well to implement
50 changes break other code by modifying conditions or registers that
|
| /Documentation/admin-guide/cifs/ |
| D | changes.rst | 2 Changes title
7 "git log fs/cifs") about fixes/improvements to CIFS/SMB2/SMB3 support (changes
|
| /Documentation/ABI/testing/ |
| D | sysfs-class-backlight | 9 hence linear changes in brightness are perceived as being
10 non-linear. To achieve a linear perception of brightness changes
20 The brightness changes linearly with each step. Brightness
25 The brightness changes non-linearly with each step. Brightness
|
| /Documentation/filesystems/ |
| D | xfs-delayed-logging-design.rst | 12 logged are made up of the changes to in-core structures rather than on-disk
13 structures. Other objects - typically buffers - have their physical changes
26 changes in the new transaction that is written to the log.
28 That is, if we have a sequence of changes A through to F, and the object was
43 the aggregation of all the previous changes currently held only in the log.
65 the log - repeated operations to the same objects write the same changes to
82 Effectively, this gives us the maximum bound of outstanding metadata changes
101 contains all the changes from the previous changes. In other words, we have one
112 infrastructure to keep track of logical changes in memory prior to physically
113 formatting the changes in a transaction to the log buffer. Hence we cannot avoid
[all …]
|
| /Documentation/admin-guide/ |
| D | abi-testing.rst | 12 be aware of changes that can occur before these interfaces move to
17 developers can easily notify them if any changes occur.
|
| /Documentation/scsi/ |
| D | ChangeLog.lpfc | 5 Changes from 20050323 to 20050413
27 * Changes in lpfc_abort_handler(): Return SUCCESS if we did not
47 Changes from 20050308 to 20050323
79 Changes from 20050223 to 20050308
98 Changes from 20050215 to 20050223
141 Changes from 20050208 to 20050215
169 Changes from 20050201 to 20050208
207 * VPD changes: 1) Modify driver to use the model name and
213 Changes from 20050124 to 20050201
276 Changes from 20050110 to 20050124
[all …]
|
| 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
244 - Changes from Eddie Dost for Sparc and Alpha:
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:
[all …]
|
| /Documentation/maintainer/ |
| D | modifying-patches.rst | 14 yours, indicating the nature of your changes. While there is nothing mandatory
17 that you are responsible for last-minute changes. Example::
24 want at the same time to credit the author, track changes, merge the fix,
|
| /Documentation/livepatch/ |
| D | system-state.rst | 2 System State Changes
16 any new livepatch must be able to detect what changes have already been
32 or by the newly used code. Also it must be possible to find changes done by
86 state changes. Every compatible livepatch has to support the following
102 - Remove any already made changes when error occurs and the livepatch
|
| /Documentation/leds/ |
| D | uleds.rst | 28 changes. The device node can also be polled to notify when the brightness value
29 changes.
|
| /Documentation/power/regulator/ |
| D | design.rst | 20 The API should make no changes to the hardware state unless it has
21 specific knowledge that these changes are safe to perform on this
|
| /Documentation/bpf/ |
| D | bpf_devel_QA.rst | 53 In case your patch has changes in various different subsystems (e.g.
56 the changes and provide their Acked-by's to the patches.
78 their status in patchwork will be set to 'Changes Requested', and purged
83 Q: How do the changes make their way into Linux?
154 When changes have been requested to the patch series, always send the
189 complexity of changes and current patch load.
217 Q: Verifier changes and test cases
222 A: If the patch has changes to the behavior of the verifier, then yes,
225 needed, then we might ask for them before accepting any changes.
230 absolutely crucial to make sure future changes do not accidentally
[all …]
|
| /Documentation/devicetree/bindings/media/ |
| D | cec-gpio.txt | 22 the following property is optional and can be used for debugging HPD changes:
26 This property is optional and can be used for debugging changes on the 5V line:
|
| /Documentation/devicetree/bindings/sifive/ |
| D | sifive-blocks-ip-versioning.txt | 19 interface to these IP blocks changes, or when the functionality of the
20 underlying IP blocks changes in a way that software should be aware of.
|
| /Documentation/device-mapper/ |
| D | dm-bow.txt | 5 data that is overwritten. The changes can then be committed by a simple state
23 that sector 0 is used to keep a log of the latest changes, both to indicate that
40 the changes can either be committed by switching to state 2, or rolled back by
58 changes. This is the one exception.
|
12345678910>>...21