dri-devel February 2021

dri-devel@lists.freedesktop.org

314 participants
684 discussions

[PATCH] drm/ttm/ttm_bo: make ttm_bo_glob_use_count static
by Jiapeng Chong 23 Feb '21

23 Feb '21

Fix the following sparse warning: drivers/gpu/drm/ttm/ttm_bo.c:53:10: warning: symbol 'ttm_bo_glob_use_count' was not declared. Should it be static? Reported-by: Abaci Robot <abaci(a)linux.alibaba.com> Signed-off-by: Jiapeng Chong <jiapeng.chong(a)linux.alibaba.com> --- drivers/gpu/drm/ttm/ttm_bo.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/ttm/ttm_bo.c b/drivers/gpu/drm/ttm/ttm_bo.c index b65f4b1..107dd13 100644 --- a/drivers/gpu/drm/ttm/ttm_bo.c +++ b/drivers/gpu/drm/ttm/ttm_bo.c @@ -50,7 +50,7 @@ * ttm_global_mutex - protecting the global BO state */ DEFINE_MUTEX(ttm_global_mutex); -unsigned ttm_bo_glob_use_count; +static unsigned ttm_bo_glob_use_count; struct ttm_bo_global ttm_bo_glob; EXPORT_SYMBOL(ttm_bo_glob); -- 1.8.3.1

2 1

[PATCH v2 0/3] drm/prime: Only call dma_map_sgtable() for devices with DMA support
by Thomas Zimmermann 23 Feb '21

23 Feb '21

USB-based drivers cannot use DMA, so the importing of dma-buf attachments currently fails for udl and gm12u320. This breaks joining/mirroring of displays. The fix is now a little series. To solve the issue on the importer side (i.e., the affected USB-based driver), patch 1 introduces a new PRIME callback, struct drm_driver.gem_prime_create_object, which creates an object and gives more control to the importing driver. Specifically, udl and gm12u320 can now avoid the creation of a scatter/gather table for the imported pages. Patch 1 is self-contained in the sense that it can be backported into older kernels. Patches 2 and 3 update SHMEM and CMA helpers to use the new callback. Effectively this moves the sg table setup from the PRIME helpers into the memory managers. SHMEM now supports devices without DMA support, so custom code can be removed from udl and g12u320. Tested by joining/mirroring displays of udl and radeon under Gnome/X11. v2: * move fix to importer side (Christian, Daniel) * update SHMEM and CMA helpers for new PRIME callbacks Thomas Zimmermann (3): drm: Support importing dmabufs into drivers without DMA drm/shmem-helper: Implement struct drm_driver.gem_prime_create_object drm/cma-helper: Implement struct drm_driver.gem_prime_create_object drivers/gpu/drm/drm_gem_cma_helper.c | 62 ++++++++++++++----------- drivers/gpu/drm/drm_gem_shmem_helper.c | 38 ++++++++++----- drivers/gpu/drm/drm_prime.c | 43 +++++++++++------ drivers/gpu/drm/lima/lima_drv.c | 2 +- drivers/gpu/drm/panfrost/panfrost_drv.c | 2 +- drivers/gpu/drm/panfrost/panfrost_gem.c | 6 +-- drivers/gpu/drm/panfrost/panfrost_gem.h | 4 +- drivers/gpu/drm/pl111/pl111_drv.c | 8 ++-- drivers/gpu/drm/v3d/v3d_bo.c | 6 +-- drivers/gpu/drm/v3d/v3d_drv.c | 2 +- drivers/gpu/drm/v3d/v3d_drv.h | 5 +- include/drm/drm_drv.h | 12 +++++ include/drm/drm_gem_cma_helper.h | 12 ++--- include/drm/drm_gem_shmem_helper.h | 6 +-- 14 files changed, 120 insertions(+), 88 deletions(-) -- 2.30.1

4 11

Re: [PULL] fixes around VM_PFNMAP and follow_pfn for 5.12 merge window
by Daniel Vetter 23 Feb '21

23 Feb '21

Cc all the mailing lists ... my usual script crashed and I had to hand-roll the email and screwed it up ofc :-/ -Daniel On Mon, Feb 22, 2021 at 11:23 AM Daniel Vetter <daniel(a)ffwll.ch> wrote: > > Hi Linus, > > Another small pull from you to ponder. > > This is the first part of a patch series I've been working on for a while: > > https://lore.kernel.org/dri-devel/20201127164131.2244124-1-daniel.vetter@ff… > > I've stumbled over this for my own learning and then realized there's a > bunch of races around VM_PFNMAP mappings vs follow pfn. > > If you're happy with this then I'll follow up with the media patches to > mark their leftover use of follow_pfn as unsafe (it's uapi, so unfixable > issue, all we can do is a config option to harden the kernel). Plus > hopefully kvm and vfio are then fixed too (you've been on the recent kvm > thread where this popped up again) so that we can sunset follow_pfn usage > completely. > > The last two patches have only been in linux-next in their current form > for a week, there was some issue for platforms with HAVE_PCI_LEGACY (not > that many) which took some sorting out. But looks all good now. > > Cheers, Daniel > > The following changes since commit 7c53f6b671f4aba70ff15e1b05148b10d58c2837: > > Linux 5.11-rc3 (2021-01-10 14:34:50 -0800) > > are available in the Git repository at: > > git://anongit.freedesktop.org/drm/drm tags/topic/iomem-mmap-vs-gup-2021-02-22 > > for you to fetch changes up to 636b21b50152d4e203223ee337aca1cb3c1bfe53: > > PCI: Revoke mappings like devmem (2021-02-11 15:59:19 +0100) > > ---------------------------------------------------------------- > Fixes around VM_FPNMAP and follow_pfn > > - replace mm/frame_vector.c by get_user_pages in misc/habana and > drm/exynos drivers, then move that into media as it's sole user > - close race in generic_access_phys > - s390 pci ioctl fix of this series landed in 5.11 already > - properly revoke iomem mappings (/dev/mem, pci files) > > ---------------------------------------------------------------- > Daniel Vetter (13): > drm/exynos: Stop using frame_vector helpers > drm/exynos: Use FOLL_LONGTERM for g2d cmdlists > misc/habana: Stop using frame_vector helpers > misc/habana: Use FOLL_LONGTERM for userptr > mm/frame-vector: Use FOLL_LONGTERM > media: videobuf2: Move frame_vector into media subsystem > mm: Close race in generic_access_phys > PCI: Obey iomem restrictions for procfs mmap > /dev/mem: Only set filp->f_mapping > resource: Move devmem revoke code to resource framework > sysfs: Support zapping of binary attr mmaps > PCI: Also set up legacy files only after sysfs init > PCI: Revoke mappings like devmem > > drivers/char/mem.c | 86 +---------------------------------------------------------------- > drivers/gpu/drm/exynos/Kconfig | 1 - > drivers/gpu/drm/exynos/exynos_drm_g2d.c | 48 ++++++++++++++++--------------------- > drivers/media/common/videobuf2/Kconfig | 1 - > drivers/media/common/videobuf2/Makefile | 1 + > {mm => drivers/media/common/videobuf2}/frame_vector.c | 55 +++++++++++++++--------------------------- > drivers/media/common/videobuf2/videobuf2-memops.c | 3 +-- > drivers/media/platform/omap/Kconfig | 1 - > drivers/misc/habanalabs/Kconfig | 1 - > drivers/misc/habanalabs/common/habanalabs.h | 6 +++-- > drivers/misc/habanalabs/common/memory.c | 52 +++++++++++++++------------------------- > drivers/pci/pci-sysfs.c | 11 +++++++++ > drivers/pci/proc.c | 6 +++++ > fs/sysfs/file.c | 11 +++++++++ > include/linux/ioport.h | 6 +---- > include/linux/mm.h | 45 ++-------------------------------- > include/linux/sysfs.h | 2 ++ > include/media/frame_vector.h | 47 ++++++++++++++++++++++++++++++++++++ > include/media/videobuf2-core.h | 1 + > kernel/resource.c | 98 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++- > mm/Kconfig | 3 --- > mm/Makefile | 1 - > mm/memory.c | 46 ++++++++++++++++++++++++++++++++--- > 23 files changed, 287 insertions(+), 245 deletions(-) > rename {mm => drivers/media/common/videobuf2}/frame_vector.c (85%) > create mode 100644 include/media/frame_vector.h > -- > Daniel Vetter > Software Engineer, Intel Corporation > http://blog.ffwll.ch -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch

2 3

[PULL] topic/kcmp-kconfig
by Daniel Vetter 23 Feb '21

23 Feb '21

Hi Linus, One patch pull request for you to ponder in the hopefully less stressful 2nd week of the merge window :-) It's also marked cc: stable so people can stop building kernels that don't work so well. topic/kcmp-kconfig-2021-02-22: kconfig for kcmp syscall drm userspaces uses this, systemd uses this, makes sense to pull it out from the checkpoint-restore bundle. Kees reviewed this from security pov and is happy with the final version. LWN coverage: https://lwn.net/Articles/845448/ Cheers, Daniel The following changes since commit f40ddce88593482919761f74910f42f4b84c004b: Linux 5.11 (2021-02-14 14:32:24 -0800) are available in the Git repository at: git://anongit.freedesktop.org/drm/drm tags/topic/kcmp-kconfig-2021-02-22 for you to fetch changes up to bfe3911a91047557eb0e620f95a370aee6a248c7: kcmp: Support selection of SYS_kcmp without CHECKPOINT_RESTORE (2021-02-16 09:59:41 +0100) ---------------------------------------------------------------- kconfig for kcmp syscall drm userspaces uses this, systemd uses this, makes sense to pull it out from the checkpoint-restore bundle. Kees reviewed this from security pov and is happy with the final version. LWN coverage: https://lwn.net/Articles/845448/ ---------------------------------------------------------------- Chris Wilson (1): kcmp: Support selection of SYS_kcmp without CHECKPOINT_RESTORE drivers/gpu/drm/Kconfig | 3 +++ fs/eventpoll.c | 4 ++-- include/linux/eventpoll.h | 2 +- init/Kconfig | 11 +++++++++++ kernel/Makefile | 2 +- tools/testing/selftests/seccomp/seccomp_bpf.c | 2 +- 6 files changed, 19 insertions(+), 5 deletions(-) -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch

2 1

Re: [PATCH RFC v1 5/6] xen-swiotlb: convert variables to arrays
by Konrad Rzeszutek Wilk 23 Feb '21

23 Feb '21

On Sun, Feb 07, 2021 at 04:56:01PM +0100, Christoph Hellwig wrote: > On Thu, Feb 04, 2021 at 09:40:23AM +0100, Christoph Hellwig wrote: > > So one thing that has been on my mind for a while: I'd really like > > to kill the separate dma ops in Xen swiotlb. If we compare xen-swiotlb > > to swiotlb the main difference seems to be: > > > > - additional reasons to bounce I/O vs the plain DMA capable > > - the possibility to do a hypercall on arm/arm64 > > - an extra translation layer before doing the phys_to_dma and vice > > versa > > - an special memory allocator > > > > I wonder if inbetween a few jump labels or other no overhead enablement > > options and possibly better use of the dma_range_map we could kill > > off most of swiotlb-xen instead of maintaining all this code duplication? > > So I looked at this a bit more. > > For x86 with XENFEAT_auto_translated_physmap (how common is that?) Juergen, Boris please correct me if I am wrong, but that XENFEAT_auto_translated_physmap only works for PVH guests? > pfn_to_gfn is a nop, so plain phys_to_dma/dma_to_phys do work as-is. > > xen_arch_need_swiotlb always returns true for x86, and > range_straddles_page_boundary should never be true for the > XENFEAT_auto_translated_physmap case. Correct. The kernel should have no clue of what the real MFNs are for PFNs. > > So as far as I can tell the mapping fast path for the > XENFEAT_auto_translated_physmap can be trivially reused from swiotlb. > > That leaves us with the next more complicated case, x86 or fully cache > coherent arm{,64} without XENFEAT_auto_translated_physmap. In that case > we need to patch in a phys_to_dma/dma_to_phys that performs the MFN > lookup, which could be done using alternatives or jump labels. > I think if that is done right we should also be able to let that cover > the foreign pages in is_xen_swiotlb_buffer/is_swiotlb_buffer, but > in that worst case that would need another alternative / jump label. > > For non-coherent arm{,64} we'd also need to use alternatives or jump > labels to for the cache maintainance ops, but that isn't a hard problem > either. > >

3 2

[PATCH] drm/amdgpu/sdma5.2: Remove unnecessary conversion to bool
by Jiapeng Chong 22 Feb '21

22 Feb '21

Fix the following coccicheck warnings: ./drivers/gpu/drm/amd/amdgpu/sdma_v5_2.c:1621:40-45: WARNING: conversion to bool not needed here. ./drivers/gpu/drm/amd/amdgpu/sdma_v5_2.c:1619:40-45: WARNING: conversion to bool not needed here. Reported-by: Abaci Robot <abaci(a)linux.alibaba.com> Signed-off-by: Jiapeng Chong <jiapeng.chong(a)linux.alibaba.com> --- drivers/gpu/drm/amd/amdgpu/sdma_v5_2.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/gpu/drm/amd/amdgpu/sdma_v5_2.c b/drivers/gpu/drm/amd/amdgpu/sdma_v5_2.c index f1ba36a..9ed79a9 100644 --- a/drivers/gpu/drm/amd/amdgpu/sdma_v5_2.c +++ b/drivers/gpu/drm/amd/amdgpu/sdma_v5_2.c @@ -1616,9 +1616,9 @@ static int sdma_v5_2_set_clockgating_state(void *handle, case CHIP_VANGOGH: case CHIP_DIMGREY_CAVEFISH: sdma_v5_2_update_medium_grain_clock_gating(adev, - state == AMD_CG_STATE_GATE ? true : false); + state == AMD_CG_STATE_GATE); sdma_v5_2_update_medium_grain_light_sleep(adev, - state == AMD_CG_STATE_GATE ? true : false); + state == AMD_CG_STATE_GATE); break; default: break; -- 1.8.3.1

2 1

[PATCH] drm/amd/display/dc/core/dc_link_ddc: Remove unnecessary conversion to bool
by Jiapeng Chong 22 Feb '21

22 Feb '21

Fix the following coccicheck warnings: ./drivers/gpu/drm/amd/display/dc/core/dc_link_ddc.c:544:34-39: WARNING: conversion to bool not needed here. Reported-by: Abaci Robot <abaci(a)linux.alibaba.com> Signed-off-by: Jiapeng Chong <jiapeng.chong(a)linux.alibaba.com> --- drivers/gpu/drm/amd/display/dc/core/dc_link_ddc.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/amd/display/dc/core/dc_link_ddc.c b/drivers/gpu/drm/amd/display/dc/core/dc_link_ddc.c index c5936e0..45a59cf 100644 --- a/drivers/gpu/drm/amd/display/dc/core/dc_link_ddc.c +++ b/drivers/gpu/drm/amd/display/dc/core/dc_link_ddc.c @@ -541,7 +541,7 @@ bool dal_ddc_service_query_ddc_data( /* should not set mot (middle of transaction) to 0 * if there are pending read payloads */ - payload.mot = read_size == 0 ? false : true; + payload.mot = !(read_size == 0); payload.length = write_size; payload.data = write_buf; -- 1.8.3.1

2 1

[PATCH v2] drm/amdgpu/swsmu/navi1x: Remove unnecessary conversion to bool
by Jiapeng Chong 22 Feb '21

22 Feb '21

Fix the following coccicheck warnings: ./drivers/gpu/drm/amd/pm/swsmu/smu11/navi10_ppt.c:900:47-52: WARNING: conversion to bool not needed here. Reported-by: Abaci Robot <abaci(a)linux.alibaba.com> Signed-off-by: Jiapeng Chong <jiapeng.chong(a)linux.alibaba.com> --- drivers/gpu/drm/amd/pm/swsmu/smu11/navi10_ppt.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/amd/pm/swsmu/smu11/navi10_ppt.c b/drivers/gpu/drm/amd/pm/swsmu/smu11/navi10_ppt.c index cd7efa9..58028a7 100644 --- a/drivers/gpu/drm/amd/pm/swsmu/smu11/navi10_ppt.c +++ b/drivers/gpu/drm/amd/pm/swsmu/smu11/navi10_ppt.c @@ -897,7 +897,7 @@ static bool navi10_is_support_fine_grained_dpm(struct smu_context *smu, enum smu dpm_desc = &pptable->DpmDescriptor[clk_index]; /* 0 - Fine grained DPM, 1 - Discrete DPM */ - return dpm_desc->SnapToDiscrete == 0 ? true : false; + return dpm_desc->SnapToDiscrete == 0; } static inline bool navi10_od_feature_is_supported(struct smu_11_0_overdrive_table *od_table, enum SMU_11_0_ODFEATURE_CAP cap) -- 1.8.3.1

3 2

2021 X.Org Board of Directors Elections Nomination period is NOW
by Harry Wentland 22 Feb '21

22 Feb '21

We are seeking nominations for candidates for election to the X.Org Foundation Board of Directors. All X.Org Foundation members are eligible for election to the board. Nominations for the 2021 election are now open and will remain open until Sunday, the 7th of March. The Board consists of directors elected from the membership. Each year, an election is held to bring the total number of directors to eight. The four members receiving the highest vote totals will serve as directors for two year terms. The directors who received two year terms starting in 2020 were Eric Anholt, Mark Filion, Keith Packard, and Harry Wentland. They will continue to serve until their term ends in 2022. Current directors whose term expires in 2021 are Samuel Iglesias Gonsálvez, Manasi D Navare, Lyude Paul, and Daniel Vetter. A director is expected to participate in the fortnightly IRC meeting to discuss current business and to attend the annual meeting of the X.Org Foundation, which will be held at a location determined in advance by the Board of Directors. A member may nominate themselves or any other member they feel is qualified. Nominations should be sent to the Election Committee at elections at x.org. Nominees shall be required to be current members of the X.Org Foundation, and submit a personal statement of up to 200 words that will be provided to prospective voters. The collected statements, along with the statement of contribution to the X.Org Foundation in the member's account page on http://members.x.org, will be made available to all voters to help them make their voting decisions. Nominations must be received before the end of day on Sunday, the 7th of March. Membership applications or renewals and completed personal statements must be received no later than the end of day on Thursday, the 11tth of March. The slate of candidates will be published on Monday, the 15th of March and candidate Q&A will begin then. ** Election Schedule ** Nomination period Start: Mon 22nd February Nomination period End: Sun 7th March Deadline of X.Org membership application or renewal: Thu 11th March Publication of Candidates & start of Candidate QA: Mon 15th March Election Planned Start: Mon 22nd March anywhere on earth Election Planned End: Sun 4th April anywhere on earth ** Election Committee ** * Eric Anholt * Mark Filion * Keith Packard * Harry Wentland Cheers, Harry Wentland, on behalf of the X.Org elections committee

1 0

[PATCH] doc: use KCFLAGS instead of EXTRA_CFLAGS to pass flags from command line
by Masahiro Yamada 22 Feb '21

22 Feb '21

You should use KCFLAGS to pass additional compiler flags from the command line. Using EXTRA_CFLAGS is wrong. EXTRA_CFLAGS is supposed to specify flags applied only to the current Makefile (and now deprecated in favor of ccflags-y). It is still used in arch/mips/kvm/Makefile (and possibly in external modules too). Passing EXTRA_CFLAGS from the command line overwrites it and breaks the build. I also fixed drivers/gpu/drm/tilcdc/Makefile because commit 816175dd1fd7 ("drivers/gpu/drm/tilcdc: Makefile, only -Werror when no -W* in EXTRA_CFLAGS") was based on the same misunderstanding. Signed-off-by: Masahiro Yamada <masahiroy(a)kernel.org> --- Documentation/process/4.Coding.rst | 2 +- Documentation/process/submit-checklist.rst | 2 +- Documentation/translations/it_IT/process/4.Coding.rst | 2 +- Documentation/translations/it_IT/process/submit-checklist.rst | 2 +- Documentation/translations/zh_CN/process/4.Coding.rst | 2 +- drivers/gpu/drm/tilcdc/Makefile | 2 +- 6 files changed, 6 insertions(+), 6 deletions(-) diff --git a/Documentation/process/4.Coding.rst b/Documentation/process/4.Coding.rst index 0825dc496f22..1f0d81f44e14 100644 --- a/Documentation/process/4.Coding.rst +++ b/Documentation/process/4.Coding.rst @@ -242,7 +242,7 @@ and try to avoid "fixes" which make the warning go away without addressing its cause. Note that not all compiler warnings are enabled by default. Build the -kernel with "make EXTRA_CFLAGS=-W" to get the full set. +kernel with "make KCFLAGS=-W" to get the full set. The kernel provides several configuration options which turn on debugging features; most of these are found in the "kernel hacking" submenu. Several diff --git a/Documentation/process/submit-checklist.rst b/Documentation/process/submit-checklist.rst index 230ee42f872f..cfc23492b9ea 100644 --- a/Documentation/process/submit-checklist.rst +++ b/Documentation/process/submit-checklist.rst @@ -98,7 +98,7 @@ and elsewhere regarding submitting Linux kernel patches. injection might be appropriate. 21) Newly-added code has been compiled with ``gcc -W`` (use - ``make EXTRA_CFLAGS=-W``). This will generate lots of noise, but is good + ``make KCFLAGS=-W``). This will generate lots of noise, but is good for finding bugs like "warning: comparison between signed and unsigned". 22) Tested after it has been merged into the -mm patchset to make sure diff --git a/Documentation/translations/it_IT/process/4.Coding.rst b/Documentation/translations/it_IT/process/4.Coding.rst index a5e36aa60448..8012fe9497ae 100644 --- a/Documentation/translations/it_IT/process/4.Coding.rst +++ b/Documentation/translations/it_IT/process/4.Coding.rst @@ -256,7 +256,7 @@ e cercate di evitare le "riparazioni" che fan sparire l'avvertimento senza però averne trovato la causa. Tenete a mente che non tutti gli avvertimenti sono disabilitati di default. -Costruite il kernel con "make EXTRA_CFLAGS=-W" per ottenerli tutti. +Costruite il kernel con "make KCFLAGS=-W" per ottenerli tutti. Il kernel fornisce differenti opzioni che abilitano funzionalità di debugging; molti di queste sono trovano all'interno del sotto menu "kernel hacking". diff --git a/Documentation/translations/it_IT/process/submit-checklist.rst b/Documentation/translations/it_IT/process/submit-checklist.rst index 3e575502690f..614fc17d9086 100644 --- a/Documentation/translations/it_IT/process/submit-checklist.rst +++ b/Documentation/translations/it_IT/process/submit-checklist.rst @@ -104,7 +104,7 @@ sottomissione delle patch, in particolare l'iniezione di fallimenti specifici per il sottosistema. 22) Il nuovo codice è stato compilato con ``gcc -W`` (usate - ``make EXTRA_CFLAGS=-W``). Questo genererà molti avvisi, ma è ottimo + ``make KCFLAGS=-W``). Questo genererà molti avvisi, ma è ottimo per scovare bachi come "warning: comparison between signed and unsigned". 23) La patch è stata verificata dopo essere stata inclusa nella serie di patch diff --git a/Documentation/translations/zh_CN/process/4.Coding.rst b/Documentation/translations/zh_CN/process/4.Coding.rst index 959a06ba025c..66cd8ee07606 100644 --- a/Documentation/translations/zh_CN/process/4.Coding.rst +++ b/Documentation/translations/zh_CN/process/4.Coding.rst @@ -165,7 +165,7 @@ Linus对这个问题给出了最佳答案: 通常，这些警告都指向真正的问题。提交以供审阅的代码通常不会产生任何编译器警告。在消除警告时，注意了解真正的原因，并尽量避免“修复”，使警告消失而不解决其原因。 -请注意，并非所有编译器警告都默认启用。使用“make EXTRA_CFLAGS=-W”构建内核以 +请注意，并非所有编译器警告都默认启用。使用“make KCFLAGS=-W”构建内核以获得完整集合。内核提供了几个配置选项，可以打开调试功能；大多数配置选项位于“kernel hacking” diff --git a/drivers/gpu/drm/tilcdc/Makefile b/drivers/gpu/drm/tilcdc/Makefile index 662bf3a348c9..f5190477de72 100644 --- a/drivers/gpu/drm/tilcdc/Makefile +++ b/drivers/gpu/drm/tilcdc/Makefile @@ -1,5 +1,5 @@ # SPDX-License-Identifier: GPL-2.0 -ifeq (, $(findstring -W,$(EXTRA_CFLAGS))) +ifeq (, $(findstring -W,$(KCFLAGS))) ccflags-y += -Werror endif -- 2.27.0

4 3

← Newer
1
...
27
28
29
30
31
32
33
...
69
Older →

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

dri-devel February 2021