Searched full:changes (Results 1 – 25 of 479) sorted by relevance
12345678910>>...20
| /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.
24 3. of_changeset_apply() - Apply the changes to the tree. Either the
|
| /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/virt/kvm/ |
| D | review-checklist.txt | 20 7. Emulator changes should be accompanied by unit tests for qemu-kvm.git
23 8. Changes should be vendor neutral when possible. Changes to common code
24 are better than duplicating changes to vendor code.
26 9. Similarly, prefer changes to arch independent code than to arch dependent
|
| /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/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 4.x release contain about 13,000
31 changesets with changes to several hundred thousand lines of code. 4.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
100 worse; the pile of changes waiting for the next merge window will grow
153 and controversial changes, go on for years. Much developer frustration
186 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/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/media/uapi/v4l/ |
| D | vidioc-dqevent.rst | 152 control's value changes, if a button control is pressed or if the
170 second-oldest event is kept, but the ``changes`` field of the
171 second-oldest event is ORed with the ``changes`` field of the
198 associated with it. The ``changes`` bitfield denotes what has
200 application could dequeue them, then the changes will have the
205 the regions changes. This event has a struct
239 - ``changes``
242 :ref:`ctrl-changes-flags`.
314 - ``changes``
316 :ref:`src-changes-flags`.
[all …]
|
| /Documentation/ |
| D | irqflags-tracing.txt | 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/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/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
|
| 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
|
| /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/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/media/v4l-drivers/ |
| D | saa7134.rst | 42 Changes / Fixes
45 Please mail me unified diffs ("diff -u") with your changes, and don't
46 forget to tell me what it changes / which problem it fixes / whatever
|
| /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/bpf/ |
| D | bpf_devel_QA.rst | 58 In case your patch has changes in various different subsystems (e.g.
61 the changes and provide their Acked-by's to the patches.
83 their status in patchwork will be set to 'Changes Requested', and purged
88 Q: How do the changes make their way into Linux?
159 When changes have been requested to the patch series, always send the
194 complexity of changes and current patch load.
222 Q: Verifier changes and test cases
227 A: If the patch has changes to the behavior of the verifier, then yes,
230 needed, then we might ask for them before accepting any changes.
235 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>>...20