- Kernel - mailweb.openeuler.org

Re: [OLK-5.10 v2] block: update io_ticks when io hang
by Hou Tao 15 Feb '22

15 Feb '22

1 0

Re: [Tc] Re: [Dev] openEuler 技术委员会例会
by Xie XiuQi 14 Feb '22

14 Feb '22

这个议题先在 kernel sig 讨论吧。可以在 https://gitee.com/openeuler/kernel/issues 提个 issue。我把这个提议报到 kernel sig。 On 2022/2/14 16:39, Jianmin Wang wrote: > Hi，王书，您好， > > 感谢提交议题，因为和 kernel 密切相关，是否有 Kernel SIG 的意见以及对应的 PR / Issue 提前发出来呢？ > > ——王建民 > >> On 14 Feb 2022, at 4:18 PM, 王书 <wangshu(a)uniontech.com> wrote: >> >> 议题申报： >> 《推送TOA模块到内核sig组申请》---统信刘冬华 >> >> >> ------------------ Original ------------------ >> From: "叶青龙"<yeqinglong(a)uniontech.com>; >> Date: Mon, Feb 14, 2022 03:22 PM >> To: "王书"<wangshu(a)uniontech.com>; >> Subject: Fw:[Dev] Fwd: openEuler 技术委员会例会 >> >> 请在例会通知邮件上申报议题。 >> >> >> >> >> >>> 服务器OS与云计算产线叶青龙 >>> >>> 联系电话：18991378194 >>> >>> 地址：西安市雁塔区天谷八路西安软件新城软件研发基地2期 >> >> >> >> >> ------------------ Original ------------------ >> From: "王建民"<jianmin(a)iscas.ac.cn>; >> Date: Tue, Feb 8, 2022 04:43 PM >> To: "tc"<tc(a)openeuler.org>; "dev"<dev(a)openeuler.org>; >> Subject: [Dev] Fwd: openEuler 技术委员会例会 >> >> 大家新年好， >> >> 春节后第一次 TC 例会将于 2022 年 2 月 16 日进行，欢迎大家回复邮件提交议题。 >> >> 谢谢。 >> >> -王建民 >> >> Hello, Everyone, >> >> Happy New Year! >> >> The first bi-weekly meeting of openEuler TC will be held on 2022/02/16 Wednesday. >> >> Welcome to submit topics by replying to the email. >> >> >> Best Regards, >> Jianmin Wang >> >> >> Begin forwarded message: >> >> From: openEuler conference <public(a)openeuler.org> >> Date: 8 February 2022 at 2:28:47 PM GMT+8 >> Subject: [Dev] openEuler 技术委员会例会 >> >> 您好！ >> >> TC SIG 邀请您参加 2022-02-16 10:00 召开的ZOOM会议 >> >> 会议主题：openEuler 技术委员会例会 >> >> 会议链接：https://us06web.zoom.us/j/82775432385?pwd=Y2hkOGZkeklrMzJVaUVnM2dONTBxdz09 >> >> 温馨提醒：建议接入会议后修改参会人的姓名，也可以使用您在gitee.com的ID >> >> 更多资讯尽在：https://openeuler.org/zh/ >> >> >> >> >> Hello! >> >> openEuler TC SIG invites you to attend the ZOOM conference will be held at 2022-02-16 10:00, >> >> The subject of the conference is openEuler 技术委员会例会, >> >> You can join the meeting at https://us06web.zoom.us/j/82775432385?pwd=Y2hkOGZkeklrMzJVaUVnM2dONTBxdz09. >> >> Note: You are advised to change the participant name after joining the conference or use your ID at gitee.com. >> >> More information: https://openeuler.org/en/ >> >> _______________________________________________ >> Dev mailing list -- dev(a)openeuler.org >> To unsubscribe send an email to dev-leave(a)openeuler.org >> _______________________________________________ >> Dev mailing list -- dev(a)openeuler.org >> To unsubscribe send an email to dev-leave(a)openeuler.org > > _______________________________________________ > Tc mailing list -- tc(a)openeuler.org > To unsubscribe send an email to tc-leave(a)openeuler.org >

1 0

[PATCH openEuler-1.0-LTS] fs/filesystems.c: downgrade user-reachable WARN_ONCE() to pr_warn_once()
by Yang Yingliang 14 Feb '22

14 Feb '22

From: Eric Biggers <ebiggers(a)google.com> mainline inclusion from mainline-5.7-rc1 commit 26c5d78c976ca298e59a56f6101a97b618ba3539 category: bugfix bugzilla: 34247 CVE: NA --------------------------- After request_module(), nothing is stopping the module from being unloaded until someone takes a reference to it via try_get_module(). The WARN_ONCE() in get_fs_type() is thus user-reachable, via userspace running 'rmmod' concurrently. Since WARN_ONCE() is for kernel bugs only, not for user-reachable situations, downgrade this warning to pr_warn_once(). Keep it printed once only, since the intent of this warning is to detect a bug in modprobe at boot time. Printing the warning more than once wouldn't really provide any useful extra information. Fixes: 41124db869b7 ("fs: warn in case userspace lied about modprobe return") Signed-off-by: Eric Biggers <ebiggers(a)google.com> Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org> Reviewed-by: Jessica Yu <jeyu(a)kernel.org> Cc: Alexei Starovoitov <ast(a)kernel.org> Cc: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> Cc: Jeff Vander Stoep <jeffv(a)google.com> Cc: Jessica Yu <jeyu(a)kernel.org> Cc: Kees Cook <keescook(a)chromium.org> Cc: Luis Chamberlain <mcgrof(a)kernel.org> Cc: NeilBrown <neilb(a)suse.com> Cc: <stable(a)vger.kernel.org> [4.13+] Link: http://lkml.kernel.org/r/20200312202552.241885-3-ebiggers@kernel.org Signed-off-by: Linus Torvalds <torvalds(a)linux-foundation.org> Signed-off-by: Ye Bin <yebin10(a)huawei.com> Reviewed-by: Zhang Yi <yi.zhang(a)huawei.com> Signed-off-by: Yang Yingliang <yangyingliang(a)huawei.com> --- fs/filesystems.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/fs/filesystems.c b/fs/filesystems.c index b03f57b1105b3..181200daeeba7 100644 --- a/fs/filesystems.c +++ b/fs/filesystems.c @@ -267,7 +267,9 @@ struct file_system_type *get_fs_type(const char *name) fs = __get_fs_type(name, len); if (!fs && (request_module("fs-%.*s", len, name) == 0)) { fs = __get_fs_type(name, len); - WARN_ONCE(!fs, "request_module fs-%.*s succeeded, but still no fs?\n", len, name); + if (!fs) + pr_warn_once("request_module fs-%.*s succeeded, but still no fs?\n", + len, name); } if (dot && fs && !(fs->fs_flags & FS_HAS_SUBTYPE)) { -- 2.25.1

1 0

[PATCH openEuler-5.10 1/5] mm/page_alloc: print node fallback order
by Zheng Zengkai 11 Feb '22

11 Feb '22

From: Bharata B Rao <bharata(a)amd.com> mainline inclusion from mainline-v5.16-rc1 commit 6cf253925df72e522c06dac09ede7e81a6e38121 category: bugfix bugzilla: https://gitee.com/openeuler/kernel/issues/I4T0ML CVE: NA ------------------------------------------------- Patch series "Fix NUMA nodes fallback list ordering". For a NUMA system that has multiple nodes at same distance from other nodes, the fallback list generation prefers same node order for them instead of round-robin thereby penalizing one node over others. This series fixes it. More description of the problem and the fix is present in the patch description. This patch (of 2): Print information message about the allocation fallback order for each NUMA node during boot. No functional changes here. This makes it easier to illustrate the problem in the node fallback list generation, which the next patch fixes. Link: https://lkml.kernel.org/r/20210830121603.1081-1-bharata@amd.com Link: https://lkml.kernel.org/r/20210830121603.1081-2-bharata@amd.com Signed-off-by: Bharata B Rao <bharata(a)amd.com> Acked-by: Mel Gorman <mgorman(a)suse.de> Reviewed-by: Anshuman Khandual <anshuman.khandual(a)arm.com> Cc: KAMEZAWA Hiroyuki <kamezawa.hiroyu(a)jp.fujitsu.com> Cc: Lee Schermerhorn <lee.schermerhorn(a)hp.com> Cc: Krupa Ramakrishnan <krupa.ramakrishnan(a)amd.com> Cc: Sadagopan Srinivasan <Sadagopan.Srinivasan(a)amd.com> Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds(a)linux-foundation.org> Signed-off-by: Peng Liu <liupeng256(a)huawei.com> Reviewed-by: Kefeng Wang <wangkefeng.wang(a)huawei.com> Signed-off-by: Zheng Zengkai <zhengzengkai(a)huawei.com> --- mm/page_alloc.c | 4 ++++ 1 file changed, 4 insertions(+) diff --git a/mm/page_alloc.c b/mm/page_alloc.c index 3791bdc958bd..4e67b4506238 100644 --- a/mm/page_alloc.c +++ b/mm/page_alloc.c @@ -6067,6 +6067,10 @@ static void build_zonelists(pg_data_t *pgdat) build_zonelists_in_node_order(pgdat, node_order, nr_nodes); build_thisnode_zonelists(pgdat); + pr_info("Fallback order for Node %d: ", local_node); + for (node = 0; node < nr_nodes; node++) + pr_cont("%d ", node_order[node]); + pr_cont("\n"); } #ifdef CONFIG_HAVE_MEMORYLESS_NODES -- 2.20.1

1 4

[PATCH openEuler-5.10] arm64: openeuler_defconfig: Enable Kunpeng related configs
by Zheng Zengkai 11 Feb '22

11 Feb '22

driver inclusion category: feature bugzilla: https://gitee.com/openeuler/kernel/issues/I4SJLU CVE: NA ----------------------------------------- Enable following configs in arm64 openeuler_defconfig for Kunpeng platform: CONFIG_PCIE_EDR=y CONFIG_HISI_PCIE_PMU=m CONFIG_MLX5_ESWITCH=y Signed-off-by: Zheng Zengkai <zhengzengkai(a)huawei.com> Reviewed-by: Chao Liu <liuchao173(a)huawei.com> Acked-by: Xinwei Kong<kong.kongxinwei(a)hisilicon.com> Reviewed-by: Yicong Yang <yangyicong(a)huawei.com> Reviewed-by: Xie XiuQi <xiexiuqi(a)huawei.com> Signed-off-by: Zheng Zengkai <zhengzengkai(a)huawei.com> --- arch/arm64/configs/openeuler_defconfig | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) diff --git a/arch/arm64/configs/openeuler_defconfig b/arch/arm64/configs/openeuler_defconfig index a86e97dd015e..a93616556d12 100644 --- a/arch/arm64/configs/openeuler_defconfig +++ b/arch/arm64/configs/openeuler_defconfig @@ -1915,7 +1915,7 @@ CONFIG_PCIEASPM_DEFAULT=y CONFIG_PCIE_PME=y CONFIG_PCIE_DPC=y # CONFIG_PCIE_PTM is not set -# CONFIG_PCIE_EDR is not set +CONFIG_PCIE_EDR=y CONFIG_PCI_MSI=y CONFIG_PCI_MSI_IRQ_DOMAIN=y CONFIG_PCI_QUIRKS=y @@ -2757,7 +2757,7 @@ CONFIG_MLX5_CORE_EN=y CONFIG_MLX5_EN_ARFS=y CONFIG_MLX5_EN_RXNFC=y CONFIG_MLX5_MPFS=y -# CONFIG_MLX5_ESWITCH is not set +CONFIG_MLX5_ESWITCH=y CONFIG_MLX5_CORE_EN_DCB=y CONFIG_MLX5_CORE_IPOIB=y # CONFIG_MLX5_IPSEC is not set @@ -6070,6 +6070,7 @@ CONFIG_THUNDERX2_PMU=m CONFIG_XGENE_PMU=y CONFIG_ARM_SPE_PMU=y CONFIG_HISI_PMU=m +CONFIG_HISI_PCIE_PMU=m # end of Performance monitor support CONFIG_RAS=y -- 2.20.1

3 2

[PATCH] configs: enable CONFIG_INTEGRITY_PLATFORM_KEYRING and CONFIG_LOAD_UEFI_KEYS
by Chao Liu 11 Feb '22

11 Feb '22

euler inclusion category: feature bugzilla: https://gitee.com/openeuler/kernel/issues/I4T7MX CVE: NA -------------------------------- Provide a separate, distinct keyring for platform trusted keys which is used in secure boot. Signed-off-by: Chao Liu <liuchao173(a)huawei.com> --- arch/arm64/configs/openeuler_defconfig | 3 ++- arch/x86/configs/openeuler_defconfig | 3 ++- 2 files changed, 4 insertions(+), 2 deletions(-) diff --git a/arch/arm64/configs/openeuler_defconfig b/arch/arm64/configs/openeuler_defconfig index a86e97dd015e..08cf4f419553 100644 --- a/arch/arm64/configs/openeuler_defconfig +++ b/arch/arm64/configs/openeuler_defconfig @@ -6502,7 +6502,8 @@ CONFIG_INTEGRITY=y CONFIG_INTEGRITY_SIGNATURE=y CONFIG_INTEGRITY_ASYMMETRIC_KEYS=y CONFIG_INTEGRITY_TRUSTED_KEYRING=y -# CONFIG_INTEGRITY_PLATFORM_KEYRING is not set +CONFIG_INTEGRITY_PLATFORM_KEYRING=y +CONFIG_LOAD_UEFI_KEYS=y CONFIG_INTEGRITY_AUDIT=y CONFIG_IMA=y # CONFIG_IMA_KEXEC is not set diff --git a/arch/x86/configs/openeuler_defconfig b/arch/x86/configs/openeuler_defconfig index febdd7627f8b..316c4122a859 100644 --- a/arch/x86/configs/openeuler_defconfig +++ b/arch/x86/configs/openeuler_defconfig @@ -7603,7 +7603,8 @@ CONFIG_INTEGRITY=y CONFIG_INTEGRITY_SIGNATURE=y CONFIG_INTEGRITY_ASYMMETRIC_KEYS=y CONFIG_INTEGRITY_TRUSTED_KEYRING=y -# CONFIG_INTEGRITY_PLATFORM_KEYRING is not set +CONFIG_INTEGRITY_PLATFORM_KEYRING=y +CONFIG_LOAD_UEFI_KEYS=y CONFIG_INTEGRITY_AUDIT=y CONFIG_IMA=y CONFIG_IMA_MEASURE_PCR_IDX=10 -- 2.23.0

3 2

Re: [PATCH -next] ext4: fix underflow in ext4_max_bitmap_size()
by weiyongjun (A) 11 Feb '22

11 Feb '22

在 2022/2/11 16:12, Zhang Yi 写道: > The same to commit 1c2d14212b15 ("ext2: Fix underflow in ext2_max_size()") > in ext2 filesystem, ext4 driver has the same issue with 64K block size > and ^huge_file, fix this issue the same as ext2. This patch also revert > commit 75ca6ad408f4 ("ext4: fix loff_t overflow in ext4_max_bitmap_size()") > because it's no longer needed. > > Signed-off-by: Zhang Yi <yi.zhang(a)huawei.com> > --- > fs/ext4/super.c | 46 +++++++++++++++++++++++++++++++--------------- > 1 file changed, 31 insertions(+), 15 deletions(-) > Looks good to me

1 0

Re: [PATCH -next] ext2: correct max file size computing
by weiyongjun (A) 11 Feb '22

11 Feb '22

在 2022/2/11 16:12, Zhang Yi 写道: > We need to calculate the max file size accurately if the total blocks > that can address by block tree exceed the upper_limit. But this check is > not correct now, it only compute the total data blocks but missing > metadata blocks are needed. So in the case of "data blocks < upper_limit > && total blocks > upper_limit", we will get wrong result. Fortunately, > this case could not happen in reality, but it's confused and better to > correct the computing. > > bits data blocks metadatablocks upper_limit > 10 16843020 66051 2147483647 > 11 134480396 263171 1073741823 > 12 1074791436 1050627 536870911 (*) > 13 8594130956 4198403 268435455 (*) > 14 68736258060 16785411 134217727 (*) > 15 549822930956 67125251 67108863 (*) > 16 4398314962956 268468227 33554431 (*) > > [*] Need to calculate in depth. > > Fixes: 1c2d14212b15 ("ext2: Fix underflow in ext2_max_size()") > Signed-off-by: Zhang Yi <yi.zhang(a)huawei.com> Looks good to me

1 0

[PATCH openEuler-1.0-LTS] drm/i915: Flush TLBs before releasing backing store
by Yang Yingliang 11 Feb '22

11 Feb '22

From: Tvrtko Ursulin <tvrtko.ursulin(a)intel.com> stable inclusion from linux-4.19.227 commit b188780649081782e341e52223db47c49f172712 CVE: CVE-2022-0330 -------------------------------- commit 7938d61591d33394a21bdd7797a245b65428f44c upstream. We need to flush TLBs before releasing backing store otherwise userspace is able to encounter stale entries if a) it is not declaring access to certain buffers and b) it races with the backing store release from a such undeclared execution already executing on the GPU in parallel. The approach taken is to mark any buffer objects which were ever bound to the GPU and to trigger a serialized TLB flush when their backing store is released. Alternatively the flushing could be done on VMA unbind, at which point we would be able to ascertain whether there is potential a parallel GPU execution (which could race), but essentially it boils down to paying the cost of TLB flushes potentially needlessly at VMA unbind time (when the backing store is not known to be going away so not needed for safety), versus potentially needlessly at backing store relase time (since we at that point cannot tell whether there is anything executing on the GPU which uses that object). Thereforce simplicity of implementation has been chosen for now with scope to benchmark and refine later as required. Signed-off-by: Tvrtko Ursulin <tvrtko.ursulin(a)intel.com> Reported-by: Sushma Venkatesh Reddy <sushma.venkatesh.reddy(a)intel.com> Reviewed-by: Daniel Vetter <daniel.vetter(a)ffwll.ch> Acked-by: Dave Airlie <airlied(a)redhat.com> Cc: Daniel Vetter <daniel.vetter(a)ffwll.ch> Cc: Jon Bloomfield <jon.bloomfield(a)intel.com> Cc: Joonas Lahtinen <joonas.lahtinen(a)linux.intel.com> Cc: Jani Nikula <jani.nikula(a)intel.com> Cc: stable(a)vger.kernel.org Signed-off-by: Linus Torvalds <torvalds(a)linux-foundation.org> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> Signed-off-by: Yang Yingliang <yangyingliang(a)huawei.com> --- drivers/gpu/drm/i915/i915_drv.h | 2 + drivers/gpu/drm/i915/i915_gem.c | 83 ++++++++++++++++++++++++++ drivers/gpu/drm/i915/i915_gem_object.h | 1 + drivers/gpu/drm/i915/i915_reg.h | 6 ++ drivers/gpu/drm/i915/i915_vma.c | 4 ++ 5 files changed, 96 insertions(+) diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h index db2e9af49ae6f..b65f3e38208a3 100644 --- a/drivers/gpu/drm/i915/i915_drv.h +++ b/drivers/gpu/drm/i915/i915_drv.h @@ -1593,6 +1593,8 @@ struct drm_i915_private { struct intel_uncore uncore; + struct mutex tlb_invalidate_lock; + struct i915_virtual_gpu vgpu; struct intel_gvt *gvt; diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c index 3139047f72465..b1b207747f39f 100644 --- a/drivers/gpu/drm/i915/i915_gem.c +++ b/drivers/gpu/drm/i915/i915_gem.c @@ -2443,6 +2443,78 @@ static void __i915_gem_object_reset_page_iter(struct drm_i915_gem_object *obj) rcu_read_unlock(); } +struct reg_and_bit { + i915_reg_t reg; + u32 bit; +}; + +static struct reg_and_bit +get_reg_and_bit(const struct intel_engine_cs *engine, + const i915_reg_t *regs, const unsigned int num) +{ + const unsigned int class = engine->class; + struct reg_and_bit rb = { .bit = 1 }; + + if (WARN_ON_ONCE(class >= num || !regs[class].reg)) + return rb; + + rb.reg = regs[class]; + if (class == VIDEO_DECODE_CLASS) + rb.reg.reg += 4 * engine->instance; /* GEN8_M2TCR */ + + return rb; +} + +static void invalidate_tlbs(struct drm_i915_private *dev_priv) +{ + static const i915_reg_t gen8_regs[] = { + [RENDER_CLASS] = GEN8_RTCR, + [VIDEO_DECODE_CLASS] = GEN8_M1TCR, /* , GEN8_M2TCR */ + [VIDEO_ENHANCEMENT_CLASS] = GEN8_VTCR, + [COPY_ENGINE_CLASS] = GEN8_BTCR, + }; + const unsigned int num = ARRAY_SIZE(gen8_regs); + const i915_reg_t *regs = gen8_regs; + struct intel_engine_cs *engine; + enum intel_engine_id id; + + if (INTEL_GEN(dev_priv) < 8) + return; + + GEM_TRACE("\n"); + + assert_rpm_wakelock_held(dev_priv); + + mutex_lock(&dev_priv->tlb_invalidate_lock); + intel_uncore_forcewake_get(dev_priv, FORCEWAKE_ALL); + + for_each_engine(engine, dev_priv, id) { + /* + * HW architecture suggest typical invalidation time at 40us, + * with pessimistic cases up to 100us and a recommendation to + * cap at 1ms. We go a bit higher just in case. + */ + const unsigned int timeout_us = 100; + const unsigned int timeout_ms = 4; + struct reg_and_bit rb; + + rb = get_reg_and_bit(engine, regs, num); + if (!i915_mmio_reg_offset(rb.reg)) + continue; + + I915_WRITE_FW(rb.reg, rb.bit); + if (__intel_wait_for_register_fw(dev_priv, + rb.reg, rb.bit, 0, + timeout_us, timeout_ms, + NULL)) + DRM_ERROR_RATELIMITED("%s TLB invalidation did not complete in %ums!\n", + engine->name, timeout_ms); + } + + intel_uncore_forcewake_put(dev_priv, FORCEWAKE_ALL); + mutex_unlock(&dev_priv->tlb_invalidate_lock); +} + static struct sg_table * __i915_gem_object_unset_pages(struct drm_i915_gem_object *obj) { @@ -2472,6 +2544,15 @@ __i915_gem_object_unset_pages(struct drm_i915_gem_object *obj) __i915_gem_object_reset_page_iter(obj); obj->mm.page_sizes.phys = obj->mm.page_sizes.sg = 0; + if (test_and_clear_bit(I915_BO_WAS_BOUND_BIT, &obj->flags)) { + struct drm_i915_private *i915 = to_i915(obj->base.dev); + + if (intel_runtime_pm_get_if_in_use(i915)) { + invalidate_tlbs(i915); + intel_runtime_pm_put(i915); + } + } + return pages; } @@ -5789,6 +5870,8 @@ int i915_gem_init_early(struct drm_i915_private *dev_priv) spin_lock_init(&dev_priv->fb_tracking.lock); + mutex_init(&dev_priv->tlb_invalidate_lock); + err = i915_gemfs_init(dev_priv); if (err) DRM_NOTE("Unable to create a private tmpfs mount, hugepage support will be disabled(%d).\n", err); diff --git a/drivers/gpu/drm/i915/i915_gem_object.h b/drivers/gpu/drm/i915/i915_gem_object.h index 83e5e01fa9eaa..2e3a713e9bcd8 100644 --- a/drivers/gpu/drm/i915/i915_gem_object.h +++ b/drivers/gpu/drm/i915/i915_gem_object.h @@ -136,6 +136,7 @@ struct drm_i915_gem_object { * activity? */ #define I915_BO_ACTIVE_REF 0 +#define I915_BO_WAS_BOUND_BIT 1 /* * Is the object to be mapped as read-only to the GPU diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h index a6f4f32dd71ce..830049985e56d 100644 --- a/drivers/gpu/drm/i915/i915_reg.h +++ b/drivers/gpu/drm/i915/i915_reg.h @@ -2431,6 +2431,12 @@ enum i915_power_well_id { #define GAMT_CHKN_DISABLE_DYNAMIC_CREDIT_SHARING (1 << 28) #define GAMT_CHKN_DISABLE_I2M_CYCLE_ON_WR_PORT (1 << 24) +#define GEN8_RTCR _MMIO(0x4260) +#define GEN8_M1TCR _MMIO(0x4264) +#define GEN8_M2TCR _MMIO(0x4268) +#define GEN8_BTCR _MMIO(0x426c) +#define GEN8_VTCR _MMIO(0x4270) + #if 0 #define PRB0_TAIL _MMIO(0x2030) #define PRB0_HEAD _MMIO(0x2034) diff --git a/drivers/gpu/drm/i915/i915_vma.c b/drivers/gpu/drm/i915/i915_vma.c index 98358b4b36dea..9aceacc43f4b7 100644 --- a/drivers/gpu/drm/i915/i915_vma.c +++ b/drivers/gpu/drm/i915/i915_vma.c @@ -335,6 +335,10 @@ int i915_vma_bind(struct i915_vma *vma, enum i915_cache_level cache_level, return ret; vma->flags |= bind_flags; + + if (vma->obj) + set_bit(I915_BO_WAS_BOUND_BIT, &vma->obj->flags); + return 0; } -- 2.25.1

1 0

Re: [PATCH] modify arm64 and x86 configs
by Kai Liu 11 Feb '22

11 Feb '22

On 2022/02/11 Fri 11:38, 郑振鹏 wrote: >好的, 麻烦给个示例, 我以后按照示例的格式提交. 你前面就有两个来自于Zheng Zengkai和Cao Liu的修改kconfig的patch，可以参考。 Regards, Kai

1 0

2024

2023

2022

2021

2020

2019

Kernel