- 18 3月, 2021 12 次提交
-
-
由 Zhang Ming 提交于
openEuler inclusion category: bugfix bugzilla: 48265 CVE: NA Reference: https://gitee.com/openeuler/kernel/issues/I3BPPX --------------------------------------------------- The default branch in switch will not run at present, but there may be related extensions in the future, which may lead to memory leakage. Signed-off-by: Zhang Ming <154842638(a)qq.com> Reported-by: Wang ShaoBo <bobo.shaobowang(a)huawei.com> Suggested-by: Jian Cheng <cj.chengjian(a)huawei.com> Reviewed-by: NXie XiuQi <xiexiuqi@huawei.com> [Zheng Zengkai: adjust commit message] Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>
-
由 Lu Jialin 提交于
hulk inclusion category: bugfix bugzilla: 50779 CVE: NA -------- If parent cgroup files.limit is 0, fail to move a task into child cgroup. When kill the task, the files.usage of parent cgroup and child cgroup is abnormal. /sys/fs/cgroup/parent # ls cgroup.clone_children files.limit tasks cgroup.procs files.usage child notify_on_release /sys/fs/cgroup/parent # echo 0 >files.limit /sys/fs/cgroup/parent # cd child /sys/fs/cgroup/parent/child # ls cgroup.clone_children files.limit notify_on_release cgroup.procs files.usage tasks /sys/fs/cgroup/parent/child # echo 156 >tasks [ 879.564728] Open files limit overcommited /sys/fs/cgroup/parent/child # kill -9 156 /sys/fs/cgroup/parent/child # [ 886.363690] WARNING: CPU: 0 PID: 156 at mm/page_counter.c:62 page_counter_cancel+0x26/0x30 [ 886.364093] Modules linked in: [ 886.364093] CPU: 0 PID: 156 Comm: top Not tainted 4.18.0+ #1 [ 886.364093] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.12.1-0-ga5cab58e9a3f-prebuilt.qemu.org 04/01/2014 [ 886.365350] RIP: 0010:page_counter_cancel+0x26/0x30 [ 886.365350] Code: 0f 1f 40 00 66 66 66 66 90 48 89 f0 53 48 f7 d8 f0 48 0f c1 07 48 29 f0 48 89 c3 48 89 c6 e8 61 ff ff ff 48 85 d5 [ 886.365350] RSP: 0018:ffffb754006b7d00 EFLAGS: 00000286 [ 886.365350] RAX: 0000000000000000 RBX: ffffffffffffffff RCX: 0000000000000001 [ 886.365350] RDX: 0000000000000000 RSI: ffffffffffffffff RDI: ffff9ca61888b930 [ 886.365350] RBP: 0000000000000001 R08: 00000000000295c0 R09: ffffffff820597aa [ 886.365350] R10: ffffffffffffffff R11: ffffd78601823508 R12: 0000000000000000 [ 886.365350] R13: ffff9ca6181c0628 R14: 0000000000000000 R15: ffff9ca663e9d000 [ 886.365350] FS: 0000000000000000(0000) GS:ffff9ca661e00000(0000) knlGS:0000000000000000 [ 886.365350] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 886.365350] CR2: 0000000000867fb8 CR3: 0000000017a0a000 CR4: 00000000000006f0 [ 886.365350] Call Trace: [ 886.369392] page_counter_uncharge+0x1d/0x30 [ 886.369392] put_files_struct+0x7c/0xe0 [ 886.369392] do_exit+0x2c7/0xb90 [ 886.369392] ? __schedule+0x2a1/0x900 [ 886.369392] do_group_exit+0x3a/0xa0 [ 886.369392] get_signal+0x15e/0x870 [ 886.369392] do_signal+0x36/0x610 [ 886.369392] ? do_vfs_ioctl+0xa4/0x640 [ 886.369392] ? do_vfs_ioctl+0xa4/0x640 [ 886.369392] ? dput+0x29/0x110 [ 886.369392] exit_to_usermode_loop+0x71/0xe0 [ 886.369392] do_syscall_64+0x181/0x1b0 [ 886.369392] entry_SYSCALL_64_after_hwframe+0x65/0xca [ 886.369392] RIP: 0033:0x4b9b5a [ 886.369392] Code: Bad RIP value. [ 886.369392] RSP: 002b:00007ffe27221968 EFLAGS: 00000206 ORIG_RAX: 0000000000000010 [ 886.373373] RAX: fffffffffffffe00 RBX: 0000000000000001 RCX: 00000000004b9b5a [ 886.373373] RDX: 00007ffe27221930 RSI: 0000000000005402 RDI: 0000000000000000 [ 886.373373] RBP: 0000000000000135 R08: 00007ffe272219a4 R09: 0000000000000010 [ 886.373373] R10: 0000000000000000 R11: 0000000000000206 R12: 0000000000000000 [ 886.373373] R13: 0000000000000005 R14: 0000000000000135 R15: 0000000000000000 [ 886.373373] ---[ end trace 56c4971a753a98c5 ]--- [1]+ Killed top /sys/fs/cgroup/parent/child # ls cgroup.clone_children files.limit notify_on_release cgroup.procs files.usage tasks /sys/fs/cgroup/parent/child # cat files.usage 18446744073709551613 /sys/fs/cgroup/parent/child # cd .. /sys/fs/cgroup/parent # ls cgroup.clone_children files.limit tasks cgroup.procs files.usage child notify_on_release /sys/fs/cgroup/parent # cat files.usage 18446744073709551613 The reason is when fail to move a task into child cgroup,the files.usage of child cgroup and its parent cgroup are the same as before. The struct files_cgroup points to the dst_css. Therefore, when kill the task, the page_counter_uncharge() will subtract the files.usage of child cgroup and its parent cgroup again. The files.usage will be abnormal. If we just change the struct files_cgroup pointers when charge success in files_cgroup_attach, problems will occur in some extreme scenario. 1)If we add num_files into original page_counter when fail to charge the file resource into new cgroup, the files.usage will be larger than files.limit of the original cgroup when new task moves into the original cgroup at the same time. 2)If we subtract num_files into original page_counter when success to charge the file resource into new cgroup, when the parent files.limit equals to the files.usage and there are two child cgroups of the parent, it will be failed to move the task from one child cgroup into another child cgroup. The patch implements files_cgroup_attach() into files_cgroup_can_attach() and delete files_cgroup_attach(). This will make move file related resource into new cgroup before move task. When try_charge is failed, task and its file resource will be in the original cgroup.The above problems will be solved. Signed-off-by: NLu Jialin <lujialin4@huawei.com> Reviewed-by: NHou Tao <houtao1@huawei.com> Signed-off-by: NYang Yingliang <yangyingliang@huawei.com> Reviewed-by: NXiu Jianfeng <xiujianfeng@huawei.com> Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>
-
由 Zhang Xiaoxu 提交于
hulk inclusion category: bugfix bugzilla: 50779 CVE: NA --------------------------- When fix CVE-2018-12207, the kvm_vm_worker_thread will attach all cgroup subsystem. But the files cgroup doesn't support kernel thread. Because the init_files doesn't init the files cgroup, when kernel thread 'kvm_vm_worker_thread' attach the files cgroup, the files_cgroup get from 'init_files' is an error pointer. It lead the kernel panic as below: [ 724.842302] page_counter_uncharge+0x1d/0x30 [ 724.842431] files_cgroup_attach+0x7c/0x130 [ 724.842564] ? css_set_move_task+0x12e/0x230 [ 724.842694] cgroup_migrate_execute+0x2f9/0x3b0 [ 724.842833] cgroup_attach_task+0x156/0x200 [ 724.843010] ? kvm_mmu_pte_write+0x490/0x490 [kvm] [ 724.843153] cgroup_attach_task_all+0x81/0xd0 [ 724.843289] ? __schedule+0x294/0x910 [ 724.843419] kvm_vm_worker_thread+0x4a/0xc0 [kvm] [ 724.843579] ? kvm_exit+0x80/0x80 [kvm] [ 724.843690] kthread+0x112/0x130 [ 724.843792] ?kthread_create_worker_on_cpu+0x70/0x70 [ 724.843948] ret_from_fork+0x35/0x40 So, we add some check, if the task is kernel thread (files is 'init_files'), we doesn't do the more operation about the files cgroup. Fixes: baa10bc24e1e ("kvm: Add helper function for creating VM ...") Signed-off-by: NZhang Xiaoxu <zhangxiaoxu5@huawei.com> Reviewed-by: NJason Yan <yanaijie@huawei.com> Reviewed-by: NHou Tao <houtao1@huawei.com> Signed-off-by: NYang Yingliang <yangyingliang@huawei.com> Signed-off-by: NLu Jialin <lujialin4@huawei.com> Reviewed-by: NXiu Jianfeng <xiujianfeng@huawei.com> Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com> -
由 Yu Kuai 提交于
hulk inclusion category: bugfix bugzilla: 50779 CVE: NA --------------------------- Such switch can only set the accounting of open fds in filescontrol from enable to disable. If it is disabled arealdy, the switch can't enable it. The counter is enabled by default, and it can be disabled by: a. echo 1 > /sys/fs/cgroup/files/files.no_acct b. add "filescontrol.no_acct=1" to boot cmd Signed-off-by: NYu Kuai <yukuai3@huawei.com> Reviewed-by: NHou Tao <houtao1@huawei.com> Reviewed-by: Nzhangyi (F) <yi.zhang@huawei.com> Signed-off-by: NYang Yingliang <yangyingliang@huawei.com> Signed-off-by: NLu Jialin <lujialin4@huawei.com> Reviewed-by: NXiu Jianfeng <xiujianfeng@huawei.com> Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>
-
由 Hou Tao 提交于
hulk inclusion category: bugfix bugzilla: 50779 CVE: NA ------------------------------------------------- Process fork and cgroup migration can happen simultaneously, and in the following case use-after-free of css_set is possible: CPU 0: process fork CPU 1: cgroup migration dup_fd __cgroup1_procs_write(threadgroup=false) files_cgroup_assign // task A task_lock task_cgroup(current, files_cgrp_id) css_set = task_css_set_check() cgroup_migrate_execute files_cgroup_can_attach css_set_move_task put_css_set_locked() files_cgroup_attach // task B which is in the same // thread group as task A task_lock cgroup_migrate_finish // the css_set will be freed put_css_set_locked() // use-after-free css_set->subsys[files_cgrp_id] Fix it by using task_get_css() instead to get a valid css. Fixes: 52cc1eccf6de ("cgroups: Resource controller for open files") Signed-off-by: NHou Tao <houtao1@huawei.com> Reviewed-by: Nluojiajun <luojiajun3@huawei.com> Signed-off-by: NYang Yingliang <yangyingliang@huawei.com> Signed-off-by: NLu Jialin <lujialin4@huawei.com> Reviewed-by: NXiu Jianfeng <xiujianfeng@huawei.com> Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com> -
由 Binder Makin 提交于
hulk inclusion category: feature/cgroups bugzilla: 50779 CVE: NA ------------------------------------------------- Add a lockless resource controller for limiting the number of open file handles. This allows us to catch misbehaving processes and return EMFILE instead of ENOMEM for kernel memory limits. Original link: https://lwn.net/Articles/604129/.After introduced https://gitlab.indel.ch/thirdparty/linux-indel/commit /5b1efc02. All memory accounting and limiting has been switched over to the lockless page counters. So we convert original resource counters to lockless page counters. Signed-off-by: NBinder Makin <merimus@google.com> Reviewed-by: NQiang Huang <h.huangqiang@huawei.com> [cm: convert to lockless page counters] Signed-off-by: Nluojiajun <luojiajun3@huawei.com> v1->v2 fix some code Reviewed-by: NJason Yan <yanaijie@huawei.com> Signed-off-by: NYang Yingliang <yangyingliang@huawei.com> Signed-off-by: NLu Jialin <lujialin4@huawei.com> Reviewed-by: NXiu Jianfeng <xiujianfeng@huawei.com> Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>
-
由 Lu Jialin 提交于
hulk inclusion category: feature/cgroups bugzilla: 50779 CVE: NA -------- enable CONFIG_CGROUP_FILES by default on x86 and arm64 Signed-off-by: NLu Jialin <lujialin4@huawei.com> Reviewed-by: NXiu Jianfeng <xiujianfeng@huawei.com> Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>
-
由 Zhang Tianxing 提交于
hulk inclusion category: bugfix bugzilla: 46797 CVE: NA Reference: https://gitee.com/openeuler/kernel/issues/I3C03N ------------------------------------------------- This patch fix a memory leak problem when deleting digest list. hlist_del_rcu in ima_del_digest_data_entry only deletes the digest struct from the linked list without releasing the memory it uses. Signed-off-by: NZhang Tianxing <zhangtianxing3@huawei.com> Reviewed-by: NRoberto Sassu <roberto.sassu@huawei.com> Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>
-
由 Zheng Zengkai 提交于
hulk inclusion category: config bugzilla: 50784 CVE: NA --------------------------- Disable CONFIG_BOOTPARAM_HOTPLUG_CPU0 for x86 openeuler_defconfig by default. Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com> Reviewed-by: NXie XiuQi <xiexiuqi@huawei.com>
-
由 Chris Leech 提交于
stable inclusion from stable-5.10.21 commit f40bbcb68131f1c17ed22a1e8a471776b4e57bd3 bugzilla: 50783 CVE: CVE-2021-27365 -------------------------------- commit f9dbdf97 upstream. Open-iSCSI sends passthrough PDUs over netlink, but the kernel should be verifying that the provided PDU header and data lengths fall within the netlink message to prevent accessing beyond that in memory. Cc: stable@vger.kernel.org Reported-by: NAdam Nichols <adam@grimm-co.com> Reviewed-by: NLee Duncan <lduncan@suse.com> Reviewed-by: NMike Christie <michael.christie@oracle.com> Signed-off-by: NChris Leech <cleech@redhat.com> Signed-off-by: NMartin K. Petersen <martin.petersen@oracle.com> Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org> Reviewed-by: NXie XiuQi <xiexiuqi@huawei.com> Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>
-
由 Chris Leech 提交于
stable inclusion from stable-5.10.21 commit 76d92bf293c36a52ea5552919ac645ef2edee55d bugzilla: 50783 CVE: CVE-2021-27365 -------------------------------- commit ec98ea70 upstream. As the iSCSI parameters are exported back through sysfs, it should be enforcing that they never are more than PAGE_SIZE (which should be more than enough) before accepting updates through netlink. Change all iSCSI sysfs attributes to use sysfs_emit(). Cc: stable@vger.kernel.org Reported-by: NAdam Nichols <adam@grimm-co.com> Reviewed-by: NLee Duncan <lduncan@suse.com> Reviewed-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org> Reviewed-by: NMike Christie <michael.christie@oracle.com> Signed-off-by: NChris Leech <cleech@redhat.com> Signed-off-by: NMartin K. Petersen <martin.petersen@oracle.com> Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org> Reviewed-by: NXie XiuQi <xiexiuqi@huawei.com> Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>
-
由 Lee Duncan 提交于
stable inclusion from stable-5.10.21 commit c71edc5d2480774ec2fec62bb84064aed6d582bd bugzilla: 50783 CVE: CVE-2021-27363/CVE-2021-27364 -------------------------------- commit 688e8128 upstream. Protect the iSCSI transport handle, available in sysfs, by requiring CAP_SYS_ADMIN to read it. Also protect the netlink socket by restricting reception of messages to ones sent with CAP_SYS_ADMIN. This disables normal users from being able to end arbitrary iSCSI sessions. Cc: stable@vger.kernel.org Reported-by: NAdam Nichols <adam@grimm-co.com> Reviewed-by: NChris Leech <cleech@redhat.com> Reviewed-by: NMike Christie <michael.christie@oracle.com> Signed-off-by: NLee Duncan <lduncan@suse.com> Signed-off-by: NMartin K. Petersen <martin.petersen@oracle.com> Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org> Reviewed-by: NXie XiuQi <xiexiuqi@huawei.com> Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>
-
- 17 3月, 2021 9 次提交
-
-
由 Catalin Marinas 提交于
mainline inclusion from mainline-5.11-rc1 commit aed5041e category: bugfix bugzilla: 50423 CVE: NA --------------------------------------------- of_dma_get_max_cpu_address() is not defined if !CONFIG_OF_ADDRESS, so return early in of_unittest_dma_get_max_cpu_address(). Fixes: 07d13a1d ("of: unittest: Add test for of_dma_get_max_cpu_address()") Reported-by: Nkernel test robot <lkp@intel.com> Signed-off-by: NCatalin Marinas <catalin.marinas@arm.com> Signed-off-by: NJing Xiangfeng <jingxiangfeng@huawei.com> Reviewed-by: NLiu Shixin <liushixin2@huawei.com> Reviewed-by: NKefeng Wang <wangkefeng.wang@huawei.com> Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>
-
由 Nicolas Saenz Julienne 提交于
mainline inclusion from mainline-5.11-rc1 commit 04435217 category: bugfix bugzilla: 50423 CVE: NA --------------------------------------------- We can't really list every setup in common code. On top of that they are unlikely to stay true for long as things change in the arch trees independently of this comment. Suggested-by: NChristoph Hellwig <hch@lst.de> Signed-off-by: NNicolas Saenz Julienne <nsaenzjulienne@suse.de> Reviewed-by: NChristoph Hellwig <hch@lst.de> Link: https://lore.kernel.org/r/20201119175400.9995-8-nsaenzjulienne@suse.deSigned-off-by: NCatalin Marinas <catalin.marinas@arm.com> Signed-off-by: NJing Xiangfeng <jingxiangfeng@huawei.com> Reviewed-by: NLiu Shixin <liushixin2@huawei.com> Reviewed-by: NKefeng Wang <wangkefeng.wang@huawei.com> Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>
-
由 Ard Biesheuvel 提交于
mainline inclusion from mainline-5.11-rc1 commit 2b865293 category: bugfix bugzilla: 50423 CVE: NA --------------------------------------------- We recently introduced a 1 GB sized ZONE_DMA to cater for platforms incorporating masters that can address less than 32 bits of DMA, in particular the Raspberry Pi 4, which has 4 or 8 GB of DRAM, but has peripherals that can only address up to 1 GB (and its PCIe host bridge can only access the bottom 3 GB) Instructing the DMA layer about these limitations is straight-forward, even though we had to fix some issues regarding memory limits set in the IORT for named components, and regarding the handling of ACPI _DMA methods. However, the DMA layer also needs to be able to allocate memory that is guaranteed to meet those DMA constraints, for bounce buffering as well as allocating the backing for consistent mappings. This is why the 1 GB ZONE_DMA was introduced recently. Unfortunately, it turns out the having a 1 GB ZONE_DMA as well as a ZONE_DMA32 causes problems with kdump, and potentially in other places where allocations cannot cross zone boundaries. Therefore, we should avoid having two separate DMA zones when possible. So let's do an early scan of the IORT, and only create the ZONE_DMA if we encounter any devices that need it. This puts the burden on the firmware to describe such limitations in the IORT, which may be redundant (and less precise) if _DMA methods are also being provided. However, it should be noted that this situation is highly unusual for arm64 ACPI machines. Also, the DMA subsystem still gives precedence to the _DMA method if implemented, and so we will not lose the ability to perform streaming DMA outside the ZONE_DMA if the _DMA method permits it. [nsaenz: unified implementation with DT's counterpart] Signed-off-by: NArd Biesheuvel <ardb@kernel.org> Signed-off-by: NNicolas Saenz Julienne <nsaenzjulienne@suse.de> Tested-by: NJeremy Linton <jeremy.linton@arm.com> Acked-by: NLorenzo Pieralisi <lorenzo.pieralisi@arm.com> Acked-by: NHanjun Guo <guohanjun@huawei.com> Cc: Jeremy Linton <jeremy.linton@arm.com> Cc: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com> Cc: Nicolas Saenz Julienne <nsaenzjulienne@suse.de> Cc: Rob Herring <robh+dt@kernel.org> Cc: Christoph Hellwig <hch@lst.de> Cc: Robin Murphy <robin.murphy@arm.com> Cc: Hanjun Guo <guohanjun@huawei.com> Cc: Sudeep Holla <sudeep.holla@arm.com> Cc: Anshuman Khandual <anshuman.khandual@arm.com> Link: https://lore.kernel.org/r/20201119175400.9995-7-nsaenzjulienne@suse.deSigned-off-by: NCatalin Marinas <catalin.marinas@arm.com> Signed-off-by: NJing Xiangfeng <jingxiangfeng@huawei.com> Reviewed-by: NLiu Shixin <liushixin2@huawei.com> Reviewed-by: NKefeng Wang <wangkefeng.wang@huawei.com> Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>
-
由 Nicolas Saenz Julienne 提交于
mainline inclusion from mainline-5.11-rc1 commit 8424ecdd category: bugfix bugzilla: 50423 CVE: NA --------------------------------------------- We recently introduced a 1 GB sized ZONE_DMA to cater for platforms incorporating masters that can address less than 32 bits of DMA, in particular the Raspberry Pi 4, which has 4 or 8 GB of DRAM, but has peripherals that can only address up to 1 GB (and its PCIe host bridge can only access the bottom 3 GB) The DMA layer also needs to be able to allocate memory that is guaranteed to meet those DMA constraints, for bounce buffering as well as allocating the backing for consistent mappings. This is why the 1 GB ZONE_DMA was introduced recently. Unfortunately, it turns out the having a 1 GB ZONE_DMA as well as a ZONE_DMA32 causes problems with kdump, and potentially in other places where allocations cannot cross zone boundaries. Therefore, we should avoid having two separate DMA zones when possible. So, with the help of of_dma_get_max_cpu_address() get the topmost physical address accessible to all DMA masters in system and use that information to fine-tune ZONE_DMA's size. In the absence of addressing limited masters ZONE_DMA will span the whole 32-bit address space, otherwise, in the case of the Raspberry Pi 4 it'll only span the 30-bit address space, and have ZONE_DMA32 cover the rest of the 32-bit address space. Signed-off-by: NNicolas Saenz Julienne <nsaenzjulienne@suse.de> Link: https://lore.kernel.org/r/20201119175400.9995-6-nsaenzjulienne@suse.deSigned-off-by: NCatalin Marinas <catalin.marinas@arm.com> Signed-off-by: NJing Xiangfeng <jingxiangfeng@huawei.com> Reviewed-by: NLiu Shixin <liushixin2@huawei.com> Reviewed-by: NKefeng Wang <wangkefeng.wang@huawei.com> Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>
-
由 Nicolas Saenz Julienne 提交于
mainline inclusion from mainline-5.11-rc1 commit 07d13a1d category: bugfix bugzilla: 50423 CVE: NA --------------------------------------------- Introduce a test for of_dma_get_max_cup_address(), it uses the same DT data as the rest of dma-ranges unit tests. Signed-off-by: NNicolas Saenz Julienne <nsaenzjulienne@suse.de> Reviewed-by: NRob Herring <robh@kernel.org> Link: https://lore.kernel.org/r/20201119175400.9995-5-nsaenzjulienne@suse.deSigned-off-by: NCatalin Marinas <catalin.marinas@arm.com> Signed-off-by: NJing Xiangfeng <jingxiangfeng@huawei.com> Reviewed-by: NLiu Shixin <liushixin2@huawei.com> Reviewed-by: NKefeng Wang <wangkefeng.wang@huawei.com> Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>
-
由 Nicolas Saenz Julienne 提交于
mainline inclusion from mainline-5.11-rc1 commit 964db79d category: bugfix bugzilla: 50423 CVE: NA --------------------------------------------- Introduce of_dma_get_max_cpu_address(), which provides the highest CPU physical address addressable by all DMA masters in the system. It's specially useful for setting memory zones sizes at early boot time. Signed-off-by: NNicolas Saenz Julienne <nsaenzjulienne@suse.de> Reviewed-by: NRob Herring <robh@kernel.org> Link: https://lore.kernel.org/r/20201119175400.9995-4-nsaenzjulienne@suse.deSigned-off-by: NCatalin Marinas <catalin.marinas@arm.com> Signed-off-by: NJing Xiangfeng <jingxiangfeng@huawei.com> Reviewed-by: NLiu Shixin <liushixin2@huawei.com> Reviewed-by: NKefeng Wang <wangkefeng.wang@huawei.com> Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>
-
由 Nicolas Saenz Julienne 提交于
mainline inclusion from mainline-5.11-rc1 commit 9804f8c6 category: bugfix bugzilla: 50423 CVE: NA --------------------------------------------- zone_dma_bits's initialization happens earlier that it's actually needed, in arm64_memblock_init(). So move it into the more suitable zone_sizes_init(). Signed-off-by: NNicolas Saenz Julienne <nsaenzjulienne@suse.de> Tested-by: NJeremy Linton <jeremy.linton@arm.com> Link: https://lore.kernel.org/r/20201119175400.9995-3-nsaenzjulienne@suse.deSigned-off-by: NCatalin Marinas <catalin.marinas@arm.com> Signed-off-by: NJing Xiangfeng <jingxiangfeng@huawei.com> Reviewed-by: NLiu Shixin <liushixin2@huawei.com> Reviewed-by: NKefeng Wang <wangkefeng.wang@huawei.com> Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>
-
由 Nicolas Saenz Julienne 提交于
mainline inclusion from mainline-5.11-rc1 commit 0a30c535 category: bugfix bugzilla: 50423 CVE: NA --------------------------------------------- crashkernel might reserve memory located in ZONE_DMA. We plan to delay ZONE_DMA's initialization after unflattening the devicetree and ACPI's boot table initialization, so move it later in the boot process. Specifically into bootmem_init() since request_standard_resources() depends on it. Conflict: arch/arm64/mm/init.c Signed-off-by: NNicolas Saenz Julienne <nsaenzjulienne@suse.de> Tested-by: NJeremy Linton <jeremy.linton@arm.com> Link: https://lore.kernel.org/r/20201119175400.9995-2-nsaenzjulienne@suse.deSigned-off-by: NCatalin Marinas <catalin.marinas@arm.com> Signed-off-by: NJing Xiangfeng <jingxiangfeng@huawei.com> Reviewed-by: NLiu Shixin <liushixin2@huawei.com> Reviewed-by: NKefeng Wang <wangkefeng.wang@huawei.com> Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>
-
由 Jingxian He 提交于
hulk inclusion category: feature bugzilla: 48159 CVE: N/A ------------------------------ The old method calls get_user_pages_remote to collect physical pages. The cost time of get_user_pages_remote is longer than 100ms when dumping mysql server with large memory. In order to reduce the cost time of collecting physical pages, we collect the physical page info by reading the page table, which can collect the physical pages within 100ms. v1->v2: - Improved return value check of pagemap_get. v2->v3: - Added new ioctl cmd "INIT_PAGEMAP_READ" for pagemapread initialization. - Removed free operation of initialized pagemapread. v3->v4: - Clean code for physical page collecting method. Signed-off-by: NJingxian He <hejingxian@huawei.com> Reviewed-by: Jing Xiangfeng<jingxiangfeng@huawei.com> Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>
-
- 12 3月, 2021 6 次提交
-
-
由 Sang Yan 提交于
hulk inclusion category: feature bugzilla: 48159 CVE: N/A ------------------------------ One cpu in PARK state could not come up in this case: CPU 0 | CPU 1 boot_secondary(cpu 1) | --> write_park_exit(cpu 1) | | cpu uping from PARK | ... uninstall_cpu_park() | --> memset to 0 park text | | ... | Exception in memory !! wait for cpu up | Cpu 1 uping from PARK may trap into exception while cpu 0 clear cpu 1's park text memory. This uninstall_cpu_park should be after waiting for cpu up. Signed-off-by: NSang Yan <sangyan@huawei.com> Reviewed-by: NXiongfeng Wang <wangxiongfeng2@huawei.com> Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>
-
由 Xiongfeng Wang 提交于
hulk inclusion category: bugfix bugzilla: 50623 CVE: N/A ------------------------------ When we print system information by echo 't' into 'sysrq-trigger' on several cores at the same time, we got the following calltrace. [ 1352.854632] NMI watchdog: Watchdog detected hard LOCKUP on cpu 6 [ 1352.854633] Modules linked in: nf_log_arp nf_log_ipv6 nf_log_ipv4 nf_log_common binfmt_misc salsa20_generic camellia_generic cast6_generic cast_common rfkill serpent_generic twofish_generic twofish_common xts lrw tgr192 wp512 rmd320 rmd256 rmd160 rmd128 md4 sha512_generic loop jprob(OE) ip6t_rpfilter ip6t_REJECT nf_reject_ipv6 ipt_REJECT nf_reject_ipv4 xt_conntrack ebtable_nat ip6table_nat nf_nat_ipv6 ip6table_mangle ip6table_raw ip6table_security iptable_nat nf_nat_ipv4 nf_nat iptable_mangle iptable_raw iptable_security nf_conntrack nf_defrag_ipv6 nf_defrag_ipv4 libcrc32c ip_set nfnetlink ebtable_filter ebtables ip6table_filter ip6_tables iptable_filter vfat fat hns_roce_hw_v2 hns_roce ib_core aes_ce_blk crypto_simd cryptd aes_ce_cipher ghash_ce sha2_ce ipmi_ssif ofpart sha256_arm64 sha1_ce cmdlinepart [ 1352.854649] hi_sfc ses enclosure mtd sg sbsa_gwdt ipmi_si ipmi_devintf ipmi_msghandler spi_dw_mmio sch_fq_codel ip_tables ext4 mbcache jbd2 sr_mod cdrom sd_mod realtek hclge hisi_sas_v3_hw hisi_sas_main ahci libsas libahci hns3 hinic libata usb_storage hnae3 megaraid_sas scsi_transport_sas i2c_designware_platform i2c_designware_core dm_multipath dm_mirror dm_region_hash dm_log dm_mod [last unloaded: ip_vs] [ 1352.854658] CPU: 6 PID: 220569 Comm: sh Kdump: loaded Tainted: G OEL 4.19.90-vhulk2001.1.0.0026.aarch64 #1 [ 1352.854659] Hardware name: Huawei TaiShan 200 (Model 2280)/BC82AMDDA, BIOS 1.06 10/29/2019 [ 1352.854659] pstate: 80400089 (Nzcv daIf +PAN -UAO) [ 1352.854660] pc : queued_spin_lock_slowpath+0x1d8/0x2e0 [ 1352.854660] lr : print_cpu+0x414/0x690 [ 1352.854660] sp : ffff0001743afb80 [ 1352.854661] x29: ffff0001743afb80 x28: ffff805fcef6e880 [ 1352.854662] x27: 0000000000000000 x26: 0000000000000000 [ 1352.854662] x25: ffff000008cab000 x24: ffff000008cab000 [ 1352.854663] x23: 0000000000000000 x22: 0000000000000000 [ 1352.854664] x21: ffff000009478000 x20: 0000000000900001 [ 1352.854664] x19: ffff000009478d20 x18: ffffffffffffffff [ 1352.854665] x17: 0000000000000000 x16: 0000000000000000 [ 1352.854666] x15: ffff000009273708 x14: ffff00000947af60 [ 1352.854667] x13: ffff00000947abab x12: ffff00000929d000 [ 1352.854668] x11: 0000000000006fc8 x10: ffff00000947a1c0 [ 1352.854668] x9 : 0000000000000001 x8 : 0000000000000000 [ 1352.854669] x7 : ffff0000092737c8 x6 : ffff803fffc9e1c0 [ 1352.854670] x5 : 0000000000000000 x4 : ffff803fffc9e1c0 [ 1352.854671] x3 : ffff000008f5e000 x2 : 00000000001c0000 [ 1352.854671] x1 : 0000000000000000 x0 : ffff803fffc9e1c8 [ 1352.854672] Call trace: [ 1352.854673] queued_spin_lock_slowpath+0x1d8/0x2e0 [ 1352.854673] print_cpu+0x414/0x690 [ 1352.854673] sysrq_sched_debug_show+0x50/0x80 [ 1352.854674] show_state_filter+0xc0/0xd0 [ 1352.854674] sysrq_handle_showstate+0x18/0x28 [ 1352.854674] __handle_sysrq+0xa0/0x190 [ 1352.854675] write_sysrq_trigger+0x70/0x88 [ 1352.854675] proc_reg_write+0x80/0xd8 [ 1352.854675] __vfs_write+0x60/0x190 [ 1352.854676] vfs_write+0xac/0x1c0 [ 1352.854676] ksys_write+0x74/0xf0 [ 1352.854676] __arm64_sys_write+0x24/0x30 [ 1352.854677] el0_svc_common+0x78/0x130 [ 1352.854677] el0_svc_handler+0x38/0x78 [ 1352.854677] el0_svc+0x8/0xc [ 1352.854678] Kernel panic - not syncing: Hard LOCKUP [ 1352.854679] CPU: 6 PID: 220569 Comm: sh Kdump: loaded Tainted: G OEL 4.19.90-vhulk2001.1.0.0026.aarch64 #1 [ 1352.854679] Hardware name: Huawei TaiShan 200 (Model 2280)/BC82AMDDA, BIOS 1.06 10/29/2019 [ 1352.854679] Call trace: [ 1352.854680] dump_backtrace+0x0/0x198 [ 1352.854680] show_stack+0x24/0x30 [ 1352.854681] dump_stack+0xa4/0xc4 [ 1352.854681] panic+0x130/0x304 [ 1352.854681] __stack_chk_fail+0x0/0x28 [ 1352.854682] watchdog_hardlockup_check+0x138/0x140 [ 1352.854682] sdei_watchdog_callback+0x20/0x30 [ 1352.854682] sdei_event_handler+0x50/0xf0 [ 1352.854683] __sdei_handler+0xd8/0x228 [ 1352.854683] __sdei_asm_handler+0xbc/0x134 [ 1352.854683] queued_spin_lock_slowpath+0x1d8/0x2e0 [ 1352.854684] print_cpu+0x414/0x690 [ 1352.854684] sysrq_sched_debug_show+0x50/0x80 [ 1352.854684] show_state_filter+0xc0/0xd0 [ 1352.854685] sysrq_handle_showstate+0x18/0x28 [ 1352.854685] __handle_sysrq+0xa0/0x190 [ 1352.854685] write_sysrq_trigger+0x70/0x88 [ 1352.854686] proc_reg_write+0x80/0xd8 [ 1352.854686] __vfs_write+0x60/0x190 [ 1352.854686] vfs_write+0xac/0x1c0 [ 1352.854687] ksys_write+0x74/0xf0 [ 1352.854687] __arm64_sys_write+0x24/0x30 [ 1352.854687] el0_svc_common+0x78/0x130 [ 1352.854688] el0_svc_handler+0x38/0x78 [ 1352.854688] el0_svc+0x8/0xc It is because there are many processes in the system. 'print_cpu()' aquires 'sched_debug_lock', print some information, and releases 'sched_debug_lock'. This procedure takes about 4 seconds in our testcase. When four cores concurrently print system info by sysrq, it will takes the last core 12 seconds to get the spinlock. This will cause a hardlockup. Signed-off-by: NKai Shen <shenkai8@huawei.com> Signed-off-by: NXiongfeng Wang <wangxiongfeng2@huawei.com> Reviewed-By: NXie XiuQi <xiexiuqi@huawei.com> Signed-off-by: NYang Yingliang <yangyingliang@huawei.com> Signed-off-by: NXiongfeng Wang <wangxiongfeng2@huawei.com> Reviewed-by: NXie XiuQi <xiexiuqi@huawei.com> Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>
-
由 Wang ShaoBo 提交于
hulk inclusion category: bugfix bugzilla: 48265 CVE: NA -------------------------------- Workaround cacheinfo's info_list uninitialized error in some special cases, such as free_cache_attributes() free info_list but not set num_leaves to zero when PPTT is not supported. this solution lasts until upstream issue resolved. Fixes: 950e5edb ("drivers: base: cacheinfo: Add helper to search cacheinfo by of_node") Fixes: 709c4362 ("cacheinfo: Move resctrl's get_cache_id() to the cacheinfo header file") Signed-off-by: NWang ShaoBo <bobo.shaobowang@huawei.com> Reviewed-by: NJian Cheng <cj.chengjian@huawei.com> Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>
-
由 Sang Yan 提交于
hulk inclusion category: feature bugzilla: 48159 CVE: N/A ------------------------------ reserve_crashkernel or reserve_quick_kexec may find one sutiable memory region and reserves it, which address of the region is not fixed. As a result, cpu park reserves memory could be failed while specified address used by crashkernel or quickkexec. So, move reserve_park_mem before reserve_crashkernel and reserve_quick_kexec. Signed-off-by: Sang Yan <sangyan(a)huawei.com> Reviewed-by: Jing Xiangfeng <jingxiangfeng(a)huawei.com> Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com> -
由 ZhuLing 提交于
hulk inclusion category: feature bugzilla: 48159 CVE: NA ------------------------------ Enable legacy pmem on openEuler defconfig both arm64 and x86 Signed-off-by: ZhuLing <zhuling8(a)huawei.com> Signed-off-by: Sang Yan <sangyan(a)huawei.com> Acked-by: Hanjun Guo <guohanjun(a)huawei.com> Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com> -
由 ZhuLing 提交于
hulk inclusion category: feature bugzilla: 48159 CVE: NA ------------------------------ Register pmem in arm64: Use memmap(memmap=nn[KMG]!ss[KMG]) reserve memory and e820(driver/nvdimm/e820.c) function to register persistent memory in arm64. when the kernel restart or update, the data in PMEM will not be lost and can be loaded faster. this is a general features. driver/nvdimm/e820.c: The function of this file is scan "iomem_resource" and take advantage of nvdimm resource discovery mechanism by registering a resource named "Persistent Memory (legacy)", this function doesn't depend on architecture. We will push the feature to linux kernel community and discuss to modify the file name. because people have a mistaken notion that the e820.c is depend on x86. If you want use this features, you need do as follows: 1.Reserve memory: add memmap to reserve memory in grub.cfg memmap=nn[KMG]!ss[KMG] exp:memmap=100K!0x1a0000000. 2.Insmod nd_e820.ko: modprobe nd_e820. 3.Check pmem device in /dev exp: /dev/pmem0 Signed-off-by: ZhuLing <zhuling8(a)huawei.com> Signed-off-by: Sang Yan <sangyan(a)huawei.com> Acked-by: Hanjun Guo <guohanjun(a)huawei.com> Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>
-
- 11 3月, 2021 2 次提交
-
-
由 liubo 提交于
euleros inclusion category: feature feature: etmem bugzilla: 48246 ------------------------------------------------- The original memory extension feature name is memig, after open source the feature name is changed to etmem. This patch is used to synchronously modify the feature name and file name. The config options and the file name are modified synchronously to etmem. Signed-off-by: Nliubo <liubo254@huawei.com> Reviewed-by: Ngeruijun <geruijun@huawei.com> Reviewed-by: NXiongfeng Wang <wangxiongfeng2@huawei.com> Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>
-
由 Zheng Zengkai 提交于
raspberrypi inclusion category: feature bugzilla: 50432 ------------------------------ This patch adjusts following arch arm related patches for raspberry pi on non-Raspberry Pi platforms, using specific config CONFIG_OPENEULER_RASPBERRYPI to distinguish them: d5c13edb Improve __copy_to_user and __copy_from_user performance 97145d2a Update vfpmodule.c bffc462c Main bcm2708/bcm2709 linux port 588cfce7 cache: export clean and invalidate 41cd350c ARM: Activate FIQs to avoid __irq_startup warnings 90607c7a ARM: proc-v7: Force misalignment of early stmia ee46d0fa reboot: Use power off rather than busy spinning when halt is requested Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com> Reviewed-by: NXie XiuQi <xiexiuqi@huawei.com>
-
- 08 3月, 2021 2 次提交
-
-
由 Xiongfeng Wang 提交于
hulk inclusion category: bugfix bugzilla: 50485 CVE: NA ------------------------------------------------------------------------- Fix the following compile error. arch/arm64/kernel/ipi_nmi.c: In function ‘ipi_nmi_handler’: arch/arm64/kernel/ipi_nmi.c:54:7: error: implicit declaration of function ‘kgdb_nmicallback’ [-Werror=implicit-function-declaration] if (!kgdb_nmicallback(cpu, get_irq_regs())) ^~~~~~~~~~~~~~~~ Signed-off-by: NXiongfeng Wang <wangxiongfeng2@huawei.com> Reviewed-by: NXie XiuQi <xiexiuqi@huawei.com> Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com> -
由 Fang Yafen 提交于
raspberrypi inclusion category: feature bugzilla: 50432 ------------------------------ Fix the following compile error when using bcm2711_defconfig (for RPi). /bin/sh: -c: line 0: syntax error near unexpected token `(' /bin/sh: -c: line 0: `set -e; echo ' DTCO arch/arm64/boot/dts/overlays/act-led.dtbo'; mkdir -p arch/arm64/boot/dts/overlays/ ; gcc -E -Wp,-MMD,arch/arm64/boot/dts/overlays/.act-led.dtbo.d.pre.tmp -nostdinc -I./scripts/dtc/include-prefixes -undef -D__DTS__ -x assembler-with-cpp -o arch/arm64/boot/dts/overlays/.act-led.dtbo.dts.tmp arch/arm64/boot/dts/overlays/act-led-overlay.dts ; ./scripts/dtc/dtc -@ -H epapr -O dtb -o arch/arm64/boot/dts/overlays/act-led.dtbo -b 0 -i arch/arm64/boot/dts/overlays/ -Wno-interrupt_provider -Wno-unit_address_vs_reg -Wno-unit_address_format -Wno-gpios_property -Wno-avoid_unnecessary_addr_size -Wno-alias_paths -Wno-graph_child_address -Wno-simple_bus_reg -Wno-unique_unit_address -Wno-pci_device_reg -Wno-interrupts_property ifeq (y,y) -Wno-label_is_string -Wno-reg_format -Wno-pci_device_bus_num -Wno-i2c_bus_reg -Wno-spi_bus_reg -Wno-avoid_default_addr_size endif -d arch/arm64/boot/dts/overlays/.act-led.dtbo.d.dtc.tmp arch/arm64/boot/dts/overlays/.act-led.dtbo.dts.tmp ; cat ...; rm -f arch/arm64/boot/dts/overlays/.act-led.dtbo.d' make[2]: *** [scripts/Makefile.lib;363: arch/arm64/boot/dts/overlays/act-led.dtbo] Error 1 make[2]: *** Waiting for unfinished jobs.... Related patches: ffa2d13c BCM2708: Add core Device Tree support 4894352e kbuild: Silence unavoidable dtc overlay warnings a4a4d07f kbuild: keep the original function for non-RPi Signed-off-by: Fang Yafen <yafen(a)iscas.ac.cn> Reviewed-by: NXie XiuQi <xiexiuqi@huawei.com> Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>
-
- 05 3月, 2021 9 次提交
-
-
由 Zheng Zengkai 提交于
raspberrypi inclusion category: feature bugzilla: 50432 ------------------------------ This patch adjusts following kbuild related patches for raspberry pi on non-Raspberry Pi platforms, using specific config CONFIG_OPENEULER_RASPBERRYPI to distinguish them: d2864887 Kbuild: Allow .dtbo overlays to be built, adjust. 0131a56e kbuild: Disable gcc plugins 4894352e kbuild: Silence unavoidable dtc overlay warnings Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com> Reviewed-by: NXie XiuQi <xiexiuqi@huawei.com>
-
由 Zheng Zengkai 提交于
raspberrypi inclusion category: feature bugzilla: 50432 ------------------------------ This patch adjusts following arch arm64 related patches for raspberry pi on non-Raspberry Pi platforms, using specific config CONFIG_OPENEULER_RASPBERRYPI to distinguish them: 154e93c8 ARM64: Force hardware emulation of deprecated instructions 40cdf60c arch/arm64: Add Revision, Serial, Model to cpuinfo Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com> Reviewed-by: NXie XiuQi <xiexiuqi@huawei.com>
-
由 Zheng Zengkai 提交于
raspberrypi inclusion category: feature bugzilla: 50432 ------------------------------ This patch adjusts following usb related patches for raspberry pi on non-Raspberry Pi platforms, using specific config CONFIG_OPENEULER_RASPBERRYPI to distinguish them: cbf9b5f6 Add dwc_otg driver 470f9247 hid: Reduce default mouse polling interval to 60Hz 1771bca0 usb: xhci: Disable the XHCI 5 second timeout fb2ea552 usbhid: call usb_fixup_endpoint after mangling intervals 8f2c6b7c xhci: Use more event ring segment table entries Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com> Reviewed-by: NXie XiuQi <xiexiuqi@huawei.com>
-
由 Zheng Zengkai 提交于
raspberrypi inclusion category: feature bugzilla: 50432 ------------------------------ This patch adjusts following memory related patches for raspberry pi on non-Raspberry Pi platforms, using specific config CONFIG_OPENEULER_RASPBERRYPI to distinguish them: 6e500008 mm: Remove the PFN busy warning 244b4163 cgroup: Disable cgroup "memory" by default a7536dd3 zswap: Defer zswap initialisation Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com> Reviewed-by: NXie XiuQi <xiexiuqi@huawei.com>
-
由 Fang Yafen 提交于
raspberrypi inclusion category: feature bugzilla: 50432 ------------------------------ This patch adjusts following video & logo patches for raspberry pi on non-Raspberry Pi platforms, using specific config CONFIG_OPENEULER_RASPBERRYPI to distinguish them: 38a1e371 bcm2708 framebuffer driver 08fb78e5 drm: Checking of the pitch is only valid for linear formats 31c95f1a media: videobuf2: Allow exporting of a struct dmabuf Signed-off-by: NFang Yafen <yafen@iscas.ac.cn> Reviewed-by: NXie XiuQi <xiexiuqi@huawei.com> Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>
-
由 Fang Yafen 提交于
raspberrypi inclusion category: feature bugzilla: 50432 ------------------------------ This patch adjusts following serial related patches for raspberry pi on non-Raspberry Pi platforms, using specific config CONFIG_OPENEULER_RASPBERRYPI to distinguish them: 239d5fc7 amba_pl011: Round input clock up 05884dbf amba_pl011: Insert mb() for correct FIFO handling 1309c3c7 amba_pl011: Add cts-event-workaround DT property Signed-off-by: NFang Yafen <yafen@iscas.ac.cn> Reviewed-by: NXie XiuQi <xiexiuqi@huawei.com> Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>
-
由 Fang Yafen 提交于
raspberrypi inclusion category: feature bugzilla: 50432 ------------------------------ This patch adjusts following mmc/spi driver related patches for raspberry pi on non-Raspberry Pi platforms, using specific config CONFIG_OPENEULER_RASPBERRYPI to distinguish them: f3badb78 of: overlay: Correct symbol path fixups 8f150108 mmc: sdhci: Silence MMC warnings 893e457c spi: Force CS_HIGH if GPIO descriptors are used Signed-off-by: NFang Yafen <yafen@iscas.ac.cn> Reviewed-by: NXie XiuQi <xiexiuqi@huawei.com> Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>
-
由 Fang Yafen 提交于
raspberrypi inclusion category: feature bugzilla: 50432 ------------------------------ This patch adjusts following net related patches for raspberry pi on non-Raspberry Pi platforms, using specific config CONFIG_OPENEULER_RASPBERRYPI to distinguish them: 5e6ba3df smsc95xx: Experimental: Enable turbo_mode and packetsize=2560 by default ab8cdd97 lan78xx: use default alignment for rx buffers 03c2e3cc net:phy:2711 Change the default ethernet LED actions ae5b52c2 brcmfmac: Prefer a ccode from OTP over nvram file 83998d2a brcmfmac: Increase power saving delay to 2s cd40cb1f net: lan78xx: Ack pending PHY ints when resetting Signed-off-by: NFang Yafen <yafen@iscas.ac.cn> Reviewed-by: NXie XiuQi <xiexiuqi@huawei.com> Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>
-
由 Fang Yafen 提交于
raspberrypi inclusion category: feature bugzilla: 50432 ------------------------------ This patch adjusts following gpio related patches for raspberry pi on non-Raspberry Pi platforms, using specific config CONFIG_OPENEULER_RASPBERRYPI to distinguish them: 680d5826 Revert "mailbox: avoid timer start from callback" 1088c5d4 gpiolib: Don't prevent IRQ usage of output GPIOs 54bc28b4 gpio-poweroff: Allow it to work on Raspberry Pi 26b77aae i2c-gpio: Also set bus numbers from reg property Signed-off-by: NFang Yafen <yafen@iscas.ac.cn> Reviewed-by: NXie XiuQi <xiexiuqi@huawei.com> Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>
-