/linux-6.12.1/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 …]
|
/linux-6.12.1/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 …]
|
/linux-6.12.1/Documentation/process/ |
D | maintainer-soc.rst | 25 The SoC subsystem also serves as an intermediate location for changes to 52 changes. Each architecture has its own maintainers that are responsible for 59 (platform-specific maintainers). This includes also changes to per-platform or 100 If changes are being made to a devicetree that are incompatible with old 102 appropriate time later. Most importantly, any incompatible changes should be 110 A common problem is synchronizing changes between device drivers and devicetree 112 coordinating how the changes get merged through different maintainer trees. 131 * Defer the devicetree changes to a release after the binding and driver have 135 both the driver change and the devicetree changes 177 submaintainers will do the same. Driver, defconfig and devicetree changes should [all …]
|
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 | maintainer-kvm-x86.rst | 54 Changes that target the next release are routed through the KVM x86 tree. Pull 100 and/or has more than superficial changes to other architectures' code. Multi- 163 changes, i.e. for arch/x86/kernel/kvm.c. Do not use file names or complete file 198 a short blurb on the actual changes, and then follow up with the context and 251 obvious, the tests need to pass). The only exception is for changes that have 256 For changes that touch KVM's shadow paging code, running with TDP (EPT/NPT) 257 disabled is mandatory. For changes that affect common KVM MMU code, running 258 with TDP disabled is strongly encouraged. For all other changes, if the code 263 a failure is not due to your changes, verify that the *exact same* failure 264 occurs with and without your changes. [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 148 and controversial changes, go on for years. Much developer frustration 181 getting feedback about changes that are needed, you should either [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 …]
|
D | maintainer-netdev.rst | 75 merge window, the ``net-next`` tree will be closed - no new changes/features. 133 Changes requested patch has not passed the review, new revision is expected 134 with appropriate code and commit message changes 142 requested changes, accepted or rejected the patch 166 the mailing list. For example to mark a series as Changes Requested 169 pw-bot: changes-requested 171 As a result the bot will set the entire series to Changes Requested. 215 Changes requested 218 Patches :ref:`marked<patch_status>` as ``Changes Requested`` need 287 Co-posting changes to user space components [all …]
|
/linux-6.12.1/Documentation/dev-tools/ |
D | checkuapi.rst | 24 will use any dirty changes in tree to UAPI files. If there are no 25 dirty changes, HEAD will be used. 31 -i Ignore ambiguous changes that may or may not break UAPI compatibility. 78 Checking changes to UAPI headers between HEAD and dirty tree... 102 Checking changes to UAPI headers between HEAD and dirty tree... 120 anything. You can pass the ``-i`` flag to the script to ignore changes 126 Checking changes to UAPI headers between HEAD and dirty tree... 152 Checking changes to UAPI headers between HEAD and dirty tree... 156 2 data member changes: 177 Checking changes to UAPI headers between HEAD^1 and HEAD... [all …]
|
/linux-6.12.1/Documentation/devicetree/ |
D | changesets.rst | 7 A Devicetree 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
|
/linux-6.12.1/Documentation/filesystems/xfs/ |
D | xfs-maintainer-entry-profile.rst | 118 context of the changes unnecessarily difficult. 120 - Anyone making kernel changes that have corresponding changes to the 121 userspace utilities should send the userspace changes as separate 160 - Changes to the on-disk format of XFS must be described in the ondisk 174 This gives the community time to review the changes, to suggest other changes, 175 and for the author to retest those changes. 177 Code submissions also requiring changes to fs/iomap and targeting the 180 infrastructure changes. 186 developers that have Reviewed-by tags for XFS changes to take a look and
|
D | xfs-delayed-logging-design.rst | 26 XFS uses Write Ahead Logging for ensuring changes to the filesystem metadata 33 details logged are made up of the changes to in-core structures rather than 35 changes logged. Long running atomic modifications have individual changes 108 this provides a mechanism for complex changes to appear atomic from an external 167 take into account all the hidden changes that might occur. 311 existing changes in the new transaction that is written to the log. 313 That is, if we have a sequence of changes A through to F, and the object was 328 the aggregation of all the previous changes currently held only in the log. 347 the log - repeated operations to the same objects write the same changes to 365 Effectively, this gives us the maximum bound of outstanding metadata changes [all …]
|
/linux-6.12.1/Documentation/userspace-api/media/v4l/ |
D | vidioc-dqevent.rst | 129 control's value changes, if a button control is pressed or if the 147 second-oldest event is kept, but the ``changes`` field of the 148 second-oldest event is ORed with the ``changes`` field of the 175 associated with it. The ``changes`` bitfield denotes what has 177 application could dequeue them, then the changes will have the 182 the regions changes. This event has a struct 214 - ``changes`` 216 :ref:`ctrl-changes-flags`. 278 - ``changes`` 280 :ref:`src-changes-flags`. [all …]
|
/linux-6.12.1/Documentation/ABI/testing/ |
D | sysfs-class-led-trigger-netdev | 32 Setting this value also immediately changes the LED state. 89 Setting this value also immediately changes the LED state. 104 Setting this value also immediately changes the LED state. 119 Setting this value also immediately changes the LED state. 134 Setting this value also immediately changes the LED state. 149 Setting this value also immediately changes the LED state. 164 Setting this value also immediately changes the LED state. 179 Setting this value also immediately changes the LED state. 192 Setting this value also immediately changes the LED state.
|
D | sysfs-platform_profile | 28 platform_profile_choices changes the profile to the new value. 30 This file can be monitored for changes by polling for POLLPRI, 31 POLLPRI will be signalled on any changes, independent of those 32 changes coming from a userspace write; or coming from another
|
/linux-6.12.1/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 …]
|
/linux-6.12.1/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
|
/linux-6.12.1/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 …]
|
/linux-6.12.1/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 */ 83 * Parameters for applying dqtrx changes to a dquot. The hook function arg
|
/linux-6.12.1/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, 217 * changes, until a transaction is finally triggered */ 220 /* Locked, no further changes allowed. 277 * lock, which means there are no pending changes, and any further attempt to
|
/linux-6.12.1/drivers/net/ethernet/intel/ixgbe/ |
D | ixgbe_dcb_nl.c | 30 int changes = 0; in ixgbe_copy_dcb_cfg() local 39 changes |= BIT_APP_UPCHG; in ixgbe_copy_dcb_cfg() 48 changes |= BIT_PG_TX; in ixgbe_copy_dcb_cfg() 53 changes |= BIT_PG_TX; in ixgbe_copy_dcb_cfg() 58 changes |= BIT_PG_TX; in ixgbe_copy_dcb_cfg() 65 changes |= (BIT_PG_TX | BIT_PFC | BIT_APP_UPCHG); in ixgbe_copy_dcb_cfg() 70 changes |= BIT_PG_RX; in ixgbe_copy_dcb_cfg() 75 changes |= BIT_PG_RX; in ixgbe_copy_dcb_cfg() 80 changes |= BIT_PG_RX; in ixgbe_copy_dcb_cfg() 87 changes |= (BIT_PG_RX | BIT_PFC | BIT_APP_UPCHG); in ixgbe_copy_dcb_cfg() [all …]
|
/linux-6.12.1/Documentation/driver-api/media/drivers/ |
D | rkisp1.rst | 9 The rkisp1 block underwent some changes between SoC implementations. 25 has seen really big changes in the vendor kernel, so will need 28 Changes from V10 to V12 38 Changes from V12 to V13
|
/linux-6.12.1/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
|
/linux-6.12.1/Documentation/userspace-api/gpio/ |
D | gpio-v2-get-lineinfo-watch-ioctl.rst | 12 GPIO_V2_GET_LINEINFO_WATCH_IOCTL - Enable watching a line for changes to its 35 Enable watching a line for changes to its request state and configuration 36 information. Changes to line info include a line being requested, released 52 Once a watch is set, any changes to line info will generate events which can be
|
/linux-6.12.1/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.
|