| /kernel/linux/linux-5.10/arch/arm/nwfpe/ |
| D | ChangeLog | 20 floating point registers. Therefore, any changes to the
29 * The changes are designed to break any patch that goes on top
30 of this code, so that the authors properly review their changes.
36 * fpa11.c - Changes due to FPA11, FPREG structure alterations.
37 * fpa11_cpdo.c - Changes due to FPA11, FPREG structure alterations.
38 * fpa11_cpdt.c - Changes due to FPA11, FPREG structure alterations.
39 * fpa11_cprt.c - Changes due to FPA11, FPREG structure alterations.
40 * single_cpdo.c - Changes due to FPA11, FPREG structure alterations.
41 * double_cpdo.c - Changes due to FPA11, FPREG structure alterations.
42 * extended_cpdo.c - Changes due to FPA11, FPREG structure alterations.
[all …]
|
| /kernel/linux/linux-4.19/arch/arm/nwfpe/ |
| D | ChangeLog | 20 floating point registers. Therefore, any changes to the
29 * The changes are designed to break any patch that goes on top
30 of this code, so that the authors properly review their changes.
36 * fpa11.c - Changes due to FPA11, FPREG structure alterations.
37 * fpa11_cpdo.c - Changes due to FPA11, FPREG structure alterations.
38 * fpa11_cpdt.c - Changes due to FPA11, FPREG structure alterations.
39 * fpa11_cprt.c - Changes due to FPA11, FPREG structure alterations.
40 * single_cpdo.c - Changes due to FPA11, FPREG structure alterations.
41 * double_cpdo.c - Changes due to FPA11, FPREG structure alterations.
42 * extended_cpdo.c - Changes due to FPA11, FPREG structure alterations.
[all …]
|
| /kernel/linux/linux-5.10/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 …]
|
| /kernel/linux/linux-4.19/Documentation/core-api/ |
| D | refcount-vs-atomic.rst | 72 Function changes:
77 Memory ordering guarantee changes:
85 Function changes:
90 Memory ordering guarantee changes:
97 Function changes:
101 Memory ordering guarantee changes:
109 Function changes:
114 Memory ordering guarantees changes:
125 Function changes:
132 Memory ordering guarantees changes:
[all …]
|
| /kernel/linux/linux-4.19/Documentation/scsi/ |
| D | 00-INDEX | 8 - Changes to scsi files, if not listed elsewhere
10 - Changes to driver for ARECA's SATA RAID controller cards
14 - Changes to lpfc driver
16 - Changes to LSI megaraid controller.
18 - Changes to serial attached scsi version of LSI megaraid controller.
20 - Changes to ncr53c8xx driver
22 - Changes to sym53c8xx driver
24 - Changes to second generation of sym53c8xx driver
|
| 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 …]
|
| /kernel/linux/linux-4.19/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
|
| /kernel/linux/linux-5.10/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
|
| /kernel/linux/linux-5.10/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 …]
|
| /kernel/linux/linux-4.19/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 | 77 resolving conflicts and dealing with API changes.
79 Only the most simple changes should be formatted as a single patch;
80 everything else should be made as a logical series of changes. Splitting
86 changes found in your working revision control system. Instead, the
87 changes you have made need to be considered in their final form, then
89 discrete, self-contained changes, not the path you took to get to those
90 changes.
93 patch. These changes can be small ("add a field to this structure") or
100 changes in the same patch. If a single patch fixes a critical security
181 support other changes coming in later patch, say so. If internal APIs are
[all …]
|
| /kernel/linux/linux-4.19/Documentation/media/uapi/v4l/ |
| D | vidioc-dqevent.rst | 145 control's value changes, if a button control is pressed or if the
163 second-oldest event is kept, but the ``changes`` field of the
164 second-oldest event is ORed with the ``changes`` field of the
191 associated with it. The ``changes`` bitfield denotes what has
193 application could dequeue them, then the changes will have the
198 the regions changes. This event has a struct
232 - ``changes``
235 :ref:`ctrl-changes-flags`.
307 - ``changes``
309 :ref:`src-changes-flags`.
[all …]
|
| /kernel/linux/linux-5.10/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 …]
|
| /kernel/linux/linux-4.19/Documentation/virtual/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
|
| /kernel/linux/linux-5.10/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
|
| /kernel/linux/linux-4.19/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 …]
|
| /kernel/linux/linux-5.10/drivers/net/slip/ |
| D | slhc.c | 234 short changes = 0; in slhc_compress() local
365 * receiver expects changes in the order: urgent, window, in slhc_compress()
372 changes |= NEW_U; in slhc_compress()
382 changes |= NEW_W; in slhc_compress()
388 changes |= NEW_A; in slhc_compress()
394 changes |= NEW_S; in slhc_compress()
397 switch(changes){ in slhc_compress()
411 /* actual changes match one of our special case encodings -- in slhc_compress()
419 changes = SPECIAL_I; in slhc_compress()
426 changes = SPECIAL_D; in slhc_compress()
[all …]
|
| /kernel/linux/linux-4.19/drivers/net/slip/ |
| D | slhc.c | 234 register short changes = 0; in slhc_compress() local
365 * receiver expects changes in the order: urgent, window, in slhc_compress()
372 changes |= NEW_U; in slhc_compress()
382 changes |= NEW_W; in slhc_compress()
388 changes |= NEW_A; in slhc_compress()
394 changes |= NEW_S; in slhc_compress()
397 switch(changes){ in slhc_compress()
411 /* actual changes match one of our special case encodings -- in slhc_compress()
419 changes = SPECIAL_I; in slhc_compress()
426 changes = SPECIAL_D; in slhc_compress()
[all …]
|
| /kernel/linux/linux-5.10/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 …]
|
| /kernel/linux/linux-5.10/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 …]
|
| /kernel/linux/linux-4.19/fs/xfs/ |
| D | xfs_quota.h | 22 * If, for example, the ownership of the inode changes while
56 * The structure kept inside the xfs_trans_t keep track of dquot changes
64 long qt_bcount_delta; /* dquot blk count changes */
65 long qt_delbcnt_delta; /* delayed dquot blk count changes */
66 long qt_icount_delta; /* dquot inode count changes */
69 long qt_rtbcount_delta;/* dquot realtime blk changes */
70 long qt_delrtb_delta; /* delayed RT blk count changes */
|
| /kernel/linux/linux-5.10/fs/xfs/ |
| D | xfs_quota.h | 23 * If, for example, the ownership of the inode changes while
57 * The structure kept inside the xfs_trans_t keep track of dquot changes
64 int64_t qt_bcount_delta; /* dquot blk count changes */
65 int64_t qt_delbcnt_delta; /* delayed dquot blk count changes */
69 int64_t qt_rtbcount_delta;/* dquot realtime blk changes */
70 int64_t qt_delrtb_delta; /* delayed RT blk count changes */
74 int64_t qt_icount_delta; /* dquot inode count changes */
|
| /kernel/linux/linux-5.10/include/linux/ |
| D | lru_cache.h | 26 and changes to an "active set" of objects, as well as pending transactions,
27 to persistently record those changes.
93 To be able to use a ring buffer for this journal of changes to the active
94 set, we not only record the actual changes to that set, but also record the
116 We plan to change the transaction format to support multiple changes per
160 /* for pending changes */
188 /* allow to accumulate a few (index:label) changes,
218 * changes, until a transaction is finally triggered */
221 /* Locked, no further changes allowed.
279 * lock, which means there are no pending changes, and any further attempt to
|
| /kernel/linux/linux-4.19/drivers/net/ethernet/intel/ixgbe/ |
| D | ixgbe_dcb_nl.c | 32 int changes = 0; in ixgbe_copy_dcb_cfg() local
41 changes |= BIT_APP_UPCHG; in ixgbe_copy_dcb_cfg()
50 changes |= BIT_PG_TX; in ixgbe_copy_dcb_cfg()
55 changes |= BIT_PG_TX; in ixgbe_copy_dcb_cfg()
60 changes |= BIT_PG_TX; in ixgbe_copy_dcb_cfg()
67 changes |= (BIT_PG_TX | BIT_PFC | BIT_APP_UPCHG); in ixgbe_copy_dcb_cfg()
72 changes |= BIT_PG_RX; in ixgbe_copy_dcb_cfg()
77 changes |= BIT_PG_RX; in ixgbe_copy_dcb_cfg()
82 changes |= BIT_PG_RX; in ixgbe_copy_dcb_cfg()
89 changes |= (BIT_PG_RX | BIT_PFC | BIT_APP_UPCHG); in ixgbe_copy_dcb_cfg()
[all …]
|