| /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-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-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 …]
|
| 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 …]
|
| /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-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-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-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 …]
|
| 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 …]
|
| /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-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-5.10/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 …]
|
| /kernel/linux/linux-5.10/fs/affs/ |
| D | Changes | 39 - sizeof changes from Kernel Janitor Project
87 - s_lock changes
161 - File mode changes were not updated on disk.
186 - dentry changes. (Thanks to Jes Sorensen for his help.)
204 directory changes).
255 - rename() will not ignore changes in filename
291 - Added this Changes file. At last!
306 - Minor changes to adhere to the new VFS interface.
321 - Several other changes I just cannot remember
|
| /kernel/linux/linux-5.10/arch/powerpc/platforms/powernv/ |
| D | opal-fadump.h | 25 * the changes in the structure format. The changes, if any, to the format
49 * is defined in the HDAT spec. Version is used to keep a tab on the changes
50 * in this CPU state data format. Changes to this format are unlikely, but
51 * if there are any changes, please refer to latest HDAT specification.
|
| /kernel/linux/linux-5.10/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
|
| /kernel/linux/linux-5.10/drivers/media/usb/pvrusb2/ |
| D | pvrusb2-debug.h | 22 #define PVR2_TRACE_CTL (1 << 7) /* commit of control changes */
23 #define PVR2_TRACE_STATE (1 << 8) /* Device state changes */
24 #define PVR2_TRACE_STBITS (1 << 9) /* Individual bit state changes */
42 #define PVR2_TRACE_GPIO (1 << 27) /* GPIO state bit changes */
|
| /kernel/linux/linux-5.10/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
|
| /kernel/linux/linux-5.10/drivers/scsi/pcmcia/ |
| D | nsp_message.c | 20 * NSP invoke interrupts only in the case of scsi phase changes, in nsp_message_in()
22 * the next "msg in" if exists (no scsi phase changes). in nsp_message_in()
61 * NSP invoke interrupts only in the case of scsi phase changes, in nsp_message_out()
63 * the next "msg out" if exists (no scsi phase changes). in nsp_message_out()
|
| /kernel/linux/linux-5.10/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
|
| /kernel/linux/linux-5.10/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 …]
|
| /kernel/linux/linux-5.10/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.
|
| /kernel/linux/linux-5.10/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
|