| /kernel/linux/build/ |
| D | README.md | 12 …E patches and OpenHarmony features as the OpenHarmony common kernel baseline. Vendors can complete…
18 …e driver code based on the chip platform and build the kernel image. All patches are licensed unde…
29 kernel/linux/patches
30 ├── linux-4.19 # linux-4.19 patches
32 │ │ └── hdf.patch # linux-4.19 HDF patches
34 │ └── hi3516dv300.patch # linux-4.19 Hi3516D V300 SOC patches
37 │ └── hdf.patch # linux-5.10 HDF patches
39 │ └── hi3516dv300.patch # linux-5.10 Hi3516D V300 SOC patches
41 ├── kernel.patch # linux-5.10 rk3568 SOC patches
42 └── hdf.patch # linux-5.10 rk3568 customized HDF patches
[all …]
|
| D | README_zh.md | 29 kernel/linux/patches
32 │ │ └── hdf.patch # linux-4.19 HDF patches
34 │ └── hi3516dv300.patch # linux-4.19 Hi3516D V300 SOC patches
37 │ └── hdf.patch # linux-5.10 HDF patches
39 │ └── hi3516dv300.patch # linux-5.10 Hi3516D V300 SOC patches
41 ├── kernel.patch # linux-5.10 rk3568 SOC patches
42 └── hdf.patch # linux-5.10 rk3568 定制 HDF patches
62 DEVICE_PATCH_DIR := $(OHOS_BUILD_HOME)/kernel/linux/patches/${KERNEL_VERSION}/$(DEVICE_NAME)_patch
|
| D | kernel.mk | 28 KERNEL_PATCH_PATH := $(OHOS_BUILD_HOME)/kernel/linux/patches/${KERNEL_VERSION}
64 DEVICE_PATCH_DIR := $(OHOS_BUILD_HOME)/kernel/linux/patches/${KERNEL_VERSION}/$(DEVICE_NAME)_patch
66 PRODUCT_PATCH_FILE := $(OHOS_BUILD_HOME)/vendor/hisilicon/watchos/patches/$(DEVICE_NAME).patch
|
| /kernel/linux/patches/ |
| D | README.md | 11 …E patches and OpenHarmony features as the OpenHarmony common kernel baseline. Vendors can complete…
17 …e driver code based on the chip platform and build the kernel image. All patches are licensed unde…
27 ├── patches
28 │ ├── linux-4.19 # linux-4.19 patches
30 │ │ │ └── hdf.patch # linux-4.19 HDF patches
32 │ │ └── hi3516dv300.patch # linux-4.19 Hi3516D V300 SOC patches
35 │ │ └── hdf.patch # linux-5.10 HDF patches
37 │ │ └── hi3516dv300.patch # linux-5.10 Hi3516D V300 SOC patches
39 │ ├── kernel.patch # linux-5.10 rk3568 SOC patches
40 │ └── hdf.patch # linux-5.10 rk3568 customized HDF patches
[all …]
|
| D | README_zh.md | 27 ├── patches
30 │ │ │ └── hdf.patch # linux-4.19 HDF patches
32 │ │ └── hi3516dv300.patch # linux-4.19 Hi3516D V300 SOC patches
35 │ │ └── hdf.patch # linux-5.10 HDF patches
37 │ │ └── hi3516dv300.patch # linux-5.10 Hi3516D V300 SOC patches
39 │ ├── kernel.patch # linux-5.10 rk3568 SOC patches
40 │ └── hdf.patch # linux-5.10 rk3568 定制 HDF patches
77 DEVICE_PATCH_DIR := $(OHOS_BUILD_HOME)/kernel/linux/patches/${KERNEL_VERSION}/$(DEVICE_NAME)_patch
|
| /kernel/linux/linux-5.10/Documentation/process/ |
| D | applying-patches.rst | 19 In addition to explaining how to apply and revert patches, a brief
21 their specific patches) is also provided.
144 If you don't have any third-party patches applied to your kernel source, but
145 only patches from kernel.org and you apply the patches in the correct order,
157 in the wrong directory. Less often, you'll find patches that need to be
203 So if you get these errors with kernel.org patches then you should probably
216 generate a patch representing the differences between two patches and then
220 step. The -z flag to interdiff will even let you feed it patches in gzip or
232 downloading and applying of patches (https://www.selenic.com/ketchup/).
241 Where can I download the patches?
[all …]
|
| D | email-clients.rst | 11 end, maintainers use ``git am`` to apply the patches.
29 for patches and other emails alike. https://useplaintext.email may be useful
33 Email clients that are used for Linux kernel patches should send the
37 Don't send patches with ``format=flowed``. This can cause unexpected
44 Emailed patches should be in ASCII or UTF-8 encoding only.
51 Copy-and-paste (or cut-and-paste) usually does not work for patches
56 Don't use PGP/GPG signatures in mail that contains patches.
57 This breaks many scripts that read and apply the patches.
61 and successfully apply it with 'patch' before sending patches to Linux
69 patches for the Linux kernel. These are not meant to be complete
[all …]
|
| D | 5.Posting.rst | 3 Posting patches
9 of conventions and procedures which are used in the posting of patches;
13 :ref:`Documentation/process/submitting-patches.rst <submittingpatches>`,
21 There is a constant temptation to avoid posting patches before they are
22 completely "ready." For simple patches, that is not a problem. If the
31 patches which are known to be half-baked, but those who do will come in
35 Before creating patches
39 sending patches to the development community. These include:
64 The preparation of patches for posting can be a surprising amount of work,
82 up patches is a bit of an art; some developers spend a long time figuring
[all …]
|
| D | stable-kernel-rules.rst | 6 Rules on what kind of patches are accepted, and which ones are not, into the
30 :ref:`Documentation/process/submitting-patches.rst <submittingpatches>`
35 Procedure for submitting patches to the -stable tree
38 - Security patches should not be handled (solely) by the -stable review
98 Additionally, some patches submitted via :ref:`option_1` may have additional
119 Also, some patches may have kernel version prerequisites. This can be
146 - When the -stable maintainers decide for a review cycle, the patches will be
154 - At the end of the review cycle, the ACKed patches will be added to the
156 - Security patches will be accepted into the -stable tree directly from the
163 - The queues of patches, for both completed versions and in progress
|
| D | 2.Process.rst | 36 merging of patches for each release. At the beginning of each development
41 this time, at a rate approaching 1,000 changes ("patches," or "changesets")
57 Over the next six to ten weeks, only patches which fix problems should be
93 serious. For this reason, patches which cause regressions are looked upon
216 How patches get into the Kernel
219 There is exactly one person who can merge patches into the mainline kernel
220 repository: Linus Torvalds. But, for example, of the over 9,500 patches
238 maintainers to track a list of patches, including authorship information
240 patches in his or her repository are not found in the mainline.
243 the patches they have selected for merging from their repositories. If
[all …]
|
| D | submitting-patches.rst | 3 Submitting patches: the essential guide to getting your code into the kernel
15 a driver, also read :doc:`submitting-drivers`; for device tree binding patches,
16 read :doc:`submitting-patches`.
18 This documentation assumes that you're using ``git`` to prepare your patches.
34 patches prepared against those trees. See the **T:** entry for the subsystem
54 vendor/product-specific trees that cherry-pick only specific patches
151 or more patches. If your changes include an API update, and a new
152 driver which uses that new API, separate those into two patches.
166 When dividing your change into a series of patches, take special care to
172 If you cannot condense your patch set into a smaller set of patches,
[all …]
|
| D | 7.AdvancedTopics.rst | 11 Managing patches with git
23 Managing patches with git can make life much easier for the developer,
24 especially as the volume of those patches grows. Git also has its rough
39 understanding of how git works before trying to use it to make patches
49 Using git to generate patches for submission by email can be a good
65 Publicly-available branches should be created with care; merge in patches
115 mass movement of patches from one repository to another makes it easy to
118 thing happening; putting up a git tree with unreviewed or off-topic patches
123 You can send me patches, but for me to pull a git patch from you, I
130 To avoid this kind of situation, ensure that all patches within a given
[all …]
|
| D | howto.rst | 12 If anything in this document becomes out of date, please send in patches
105 patches if these rules are followed, and many people will only
108 …:ref:`Documentation/process/submitting-patches.rst <submittingpatches>` and :ref:`Documentation/pr…
116 Following these rules will not guarantee success (as all patches are
120 Other excellent descriptions of how to create patches properly are:
163 :ref:`Documentation/process/applying-patches.rst <applying_patches>`
251 Linus, usually the patches that have already been included in the
254 can be found at https://git-scm.com/) but plain patches are also just
257 new kernel as rock solid as possible. Most of the patches at this point
264 patches to Linus after -rc1 is released, but the patches need to also be
[all …]
|
| D | 6.Followthrough.rst | 8 patches. One of the biggest mistakes that even experienced kernel
10 posting patches indicates a transition into the next stage of the process,
19 prevent the inclusion of your patches into the mainline.
81 that your patches go nowhere.
112 dedicated to patches planned for the next merge window, and another for
115 For patches applying to areas for which there is no obvious subsystem tree
116 (memory management patches, for example), the default tree often ends up
130 burner so that the remaining patches can be worked into shape and merged.
132 developers and, possibly, moving some patches between trees to ensure that
171 for; you can start creating cool new patches once any problems with the old
[all …]
|
| D | index.rst | 27 submitting-patches
57 applying-patches
|
| /kernel/linux/linux-5.10/Documentation/translations/zh_CN/process/ |
| D | 5.Posting.rst | 15 :ref:`Documentation/translations/zh_CN/process/submitting-patches.rst <cn_submittingpatches>`,
148 :ref:`Documentation/translations/zh_CN/process/submitting-patches.rst <cn_submittingpatches>`
159 :ref:`Documentation/translations/zh_CN/process/submitting-patches.rst <cn_submittingpatches>`
166 :ref:`Documentation/translations/zh_CN/process/submitting-patches.rst <cn_submittingpatches>`
174 :ref:`Documentation/translations/zh_CN/process/submitting-patches.rst <cn_submittingpatches>`
|
| /kernel/linux/config/ |
| D | README.md | 12 …E patches and OpenHarmony features as the OpenHarmony common kernel baseline. Vendors can complete…
56 1. Apply HDF patches.
58 …Apply the HDF kernel patches matching your kernel version. For details, see the method in **kernel…
64 2. Apply the chip driver patches.
68 …Place the patches for the chip component in the corresponding path based on the path and naming ru…
71 DEVICE_PATCH_DIR := $(OHOS_BUILD_HOME)/kernel/linux/patches/${KERNEL_VERSION}/$(DEVICE_NAME)_patch
86 …>In the OpenHarmony project build process, patches are installed after **kernel/linux/linux-\*\.\*…
|
| /kernel/linux/linux-5.10/Documentation/livepatch/ |
| D | cumulative-patches.rst | 5 There might be dependencies between livepatches. If multiple patches need
7 an order in which the patches will be installed. And function implementations
10 This might become a maintenance nightmare. Especially when more patches
30 Once the transition is finished, all older patches are automatically
65 to reverse it and restore the replaced patches atomically.
78 executed. Any callbacks from the replaced patches are ignored.
83 As a result, it might be dangerous to replace newer cumulative patches by
93 enabled patches were called.
|
| /kernel/linux/linux-5.10/Documentation/bpf/ |
| D | bpf_devel_QA.rst | 6 workflows related to reporting bugs, submitting patches, and queueing
7 patches for stable kernels.
9 For general information about submitting patches, please refer to
44 Submitting patches
47 Q: To which mailing list do I need to submit my BPF patches?
49 A: Please submit your BPF patches to the bpf kernel mailing list:
56 the changes and provide their Acked-by's to the patches.
58 Q: Where can I find patches currently under discussion for BPF subsystem?
60 A: All patches that are Cc'ed to netdev are queued for review under netdev
65 Those patches which target BPF, are assigned to a 'bpf' delegate for
[all …]
|
| /kernel/linux/linux-5.10/drivers/scsi/aic7xxx/aicasm/ |
| D | aicasm.c | 74 STAILQ_HEAD(patch_list, patch) patches;
126 STAILQ_INIT(&patches); in main()
425 for (cur_patch = STAILQ_FIRST(&patches); in output_code()
429 cur_patch == STAILQ_FIRST(&patches) ? "" : ",\n", in output_code()
493 pinfo = &scope->patches[patch]; in emit_patch()
515 STAILQ_INSERT_TAIL(&patches, new_patch, links); in emit_patch()
596 cur_patch = STAILQ_FIRST(&patches); in output_listing()
804 cur_scope->patches[1].skip_patch = in process_scope()
806 cur_scope->patches[1].skip_instr = in process_scope()
816 cur_scope->patches[0].skip_patch = patch0_patch_skip; in process_scope()
[all …]
|
| /kernel/linux/linux-5.10/Documentation/maintainer/ |
| D | maintainer-entry-profile.rst | 7 (submitting-patches, submitting drivers...) with
18 tells the contributor where to send patches for which files, it does not
24 - Are there notifications when patches are applied to the local tree, or
47 require published specifications at a certain revision before patches
53 One of the common misunderstandings of submitters is that patches can be
55 considered for the next -rc1. The reality is that most patches need to
58 week) that patches might be considered for merging and when patches need to
|
| /kernel/linux/linux-5.10/Documentation/nvdimm/ |
| D | maintainer-entry-profile.rst | 15 In general patches can be submitted against the latest -rc; however, if
19 are cases where patches are more suitable to be merged through a
32 Those tests need to be passed before the patches go upstream, but not
38 Before patches enabling a new _DSM family will be considered, it must
52 and some patches may require multiple development cycles to review.
|
| /kernel/linux/linux-5.10/ |
| D | README | 13 Steps of submitting patches
16 1. Compile and test your patches successfully.
20 2. Generate patches
21 Your patches should be based on top of latest OpenHarmony branch, and
22 should use git-format-patch to generate patches, and if it's a patchset,
38 Use this command to send patches to OpenHarmony kernel mailing list:
49 *See*: How to send patches using git-send-email
70 https://www.kernel.org/doc/html/latest/process/submitting-patches.html
114 OpenHarmony will merge massive patches. If all patches are merged by
120 strict patch management will alleviate the pain to migrate patches
|
| /kernel/linux/linux-5.10/Documentation/driver-api/acpi/ |
| D | linuxized-acpica.rst | 125 Linux patches. The patches generated by this process are referred to as
126 "linuxized ACPICA patches". The release process is carried out on a local
182 Before the linuxized ACPICA patches are sent to the Linux ACPI community
191 Ideally, all of the ACPICA commits should be converted into Linux patches
219 user space simulation utilities, thus the linuxized ACPICA patches may
222 linuxized ACPICA patches during the release process. When the release
236 utilities to obtain Linux patches corresponding to upstream ACPICA commits
260 top of the generated ACPICA release patches::
264 $ generate/linux/make-patches.sh -u [commit ID]
|
| /kernel/linux/linux-5.10/Documentation/networking/ |
| D | netdev-FAQ.rst | 120 A: Generally speaking, the patches get triaged quickly (in less than
134 Q: I made changes to only a few patches in a patch series should I resend only those changed?
137 patches such that it is clear this is the latest and greatest set of patches
144 the patches the way they would look like if your latest patch series was to be
196 alongside kernel patches. This gives reviewers a chance to see
202 to a public repo where user space patches can be seen.
205 reviewed on netdev (e.g. patches to `iproute2` tools) kernel and
206 user space patches should form separate series (threads) when posted
233 :ref:`Documentation/process/submitting-patches.rst <submittingpatches>`
|