On Thu, Mar 28, 2024, at 11:46, Jani Nikula wrote:
> On Thu, 28 Mar 2024, "Arnd Bergmann" wrote:
>> On Thu, Mar 28, 2024, at 11:24, Jani Nikula wrote:
>>> Use localized __diag_push(), __diag_ignore_all() with rationale, and
>>> __diag_pop() for specif
all() and it was fixed by commit 689b097a06ba
> ("compiler-gcc: Suppress -Wmissing-prototypes warning for all supported
> GCC"). So we should be able to pull this off now.
>
> Cc: "Arnd Bergmann"
> Cc: Lucas De Marchi
> Signed-off-by: Jani Nikula
Looks good to me,
Acked-by: Arnd Bergmann
From: Arnd Bergmann
This is a follow-up on a couple of patch series I sent in the past,
enabling -Wextra (aside from stuff that is explicitly disabled),
-Wcast-function-pointer-strict and -Wrestrict.
I have tested these on 'defconfig' and 'allmodconfig' builds across
all ar
From: Arnd Bergmann
The newly added function is not available without CONFIG_ACPI, causing
a build failure:
drivers/gpu/drm/i915/display/intel_bios.c:3424:24: error: implicit declaration
of function 'intel_opregion_vbt_present'; did you mean
'intel_opregion_asle_present'
On Tue, Oct 17, 2023, at 00:10, Andi Shyti wrote:
> Hi Arnd,
>
>> static void rc6_res_reg_init(struct intel_rc6 *rc6)
>> {
>> -memset(rc6->res_reg, INVALID_MMIO_REG.reg, sizeof(rc6->res_reg));
>
> This is a complex initialization, indeed... how about just
>
>memset(rc6->res_reg, 0, sizeof
From: Arnd Bergmann
The newly added memset() causes a warning for some reason I could not figure
out:
In file included from arch/x86/include/asm/string.h:3,
from drivers/gpu/drm/i915/gt/intel_rc6.c:6:
In function 'rc6_res_reg_init',
inlined from 'intel_rc6_i
From: Arnd Bergmann
The mchbar_addr variable is only used inside of an #ifdef:
drivers/gpu/drm/i915/soc/intel_gmch.c:41:6: error: variable 'mchbar_addr' set
but not used [-Werror,-Wunused-but-set-variable]
Change this to an IS_ENABLED() check to let the compiler see how
it
From: Arnd Bergmann
The function is only defined if CONFIG_PROC_FS is enabled:
ld.lld: error: undefined symbol: i915_drm_client_fdinfo
>>> referenced by i915_driver.c
>>> drivers/gpu/drm/i915/i915_driver.o:(i915_drm_driver) in
>>> archive vmlinux.a
From: Arnd Bergmann
When CONFIG_PNP is disabled, the mchbar_addr variable is only written but
not read:
drivers/gpu/drm/i915/soc/intel_gmch.c: In function
'intel_alloc_mchbar_resource':
drivers/gpu/drm/i915/soc/intel_gmch.c:41:13: error: variable 'mchbar_addr' set
but not
From: Arnd Bergmann
While 'unsigned long' needs the %ld format string, size_t needs the %z
modifier:
drivers/gpu/drm/i915/pxp/intel_pxp_gsccs.c: In function 'gsccs_send_message':
include/drm/drm_print.h:456:39: error: format '%ld' expects argument of type
'
From: Arnd Bergmann
When ACPI is disabled, i915 fails to build because of a missing
declaration:
drivers/gpu/drm/i915/i915_driver.c: In function 'i915_driver_hw_probe':
drivers/gpu/drm/i915/i915_driver.c:556:9: error: implicit declaration of
function 'intel_opregion_cleanup
On Fri, Feb 17, 2023, at 16:38, Andrzej Hajda wrote:
> On 17.02.2023 13:46, Arnd Bergmann wrote:
>> From: Arnd Bergmann
>>
>> With gcc-7 and earlier, there are lots of warnings like
>>
>> In file included from :0:0:
>> In function '__guc_context_p
From: Arnd Bergmann
With gcc-7 and earlier, there are lots of warnings like
In file included from :0:0:
In function '__guc_context_policy_add_priority.isra.66',
inlined from '__guc_context_set_prio.isra.67' at
drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c:3292
From: Arnd Bergmann
CONFIG_VFIO_MDEV cannot be selected when VFIO itself is
disabled, otherwise we get a link failure:
WARNING: unmet direct dependencies detected for VFIO_MDEV
Depends on [n]: VFIO [=n]
Selected by [y]:
- SAMPLE_VFIO_MDEV_MTTY [=y] && SAM
From: Arnd Bergmann
The definition of intel_selftest_modify_policy() does not match the
declaration, as gcc-13 points out:
drivers/gpu/drm/i915/selftests/intel_scheduler_helpers.c:29:5: error:
conflicting types for 'intel_selftest_modify_policy' due to enum/integer
mismatch; have &
On Thu, Dec 22, 2022, at 12:46, Andrzej Hajda wrote:
> __xchg will be used for non-atomic xchg macro.
>
> Signed-off-by: Andrzej Hajda
> ---
> arch/arc/include/asm/cmpxchg.h | 4 ++--
Reviewed-by: Arnd Bergmann
for all the arch/*/include/asm/cmpxchg.h changes.
Since these patc
On Tue, Dec 13, 2022, at 10:28, Andrzej Hajda wrote:
> On 09.12.2022 18:16, Arnd Bergmann wrote:
>> name for the backing of arch_xchg() or arch_xchg_relaxed(),
>> maybe we can instead rename those to __arch_xchg() and use the
>> __xchg() name for the new non-atomic version
On Fri, Dec 9, 2022, at 16:48, Andrzej Hajda wrote:
> The pattern of setting variable with new value and returning old
> one is very common in kernel. Usually atomicity of the operation
> is not required, so xchg seems to be suboptimal and confusing in
> such cases. Since name xchg is already in us
On Mon, Sep 26, 2022, at 11:07 PM, Kees Cook wrote:
> On Mon, Sep 26, 2022 at 01:17:18PM -0700, Nick Desaulniers wrote:
>> + Arnd
>>
>> On Mon, Sep 26, 2022 at 12:11 PM Kees Cook wrote:
>> > ---
>> > v2:
>> > - fix comment typo
>> > - wrap clang pragma to avoid GCC warnings
>> > - style nit cl
On Mon, Feb 28, 2022 at 10:41 PM Fangrui Song wrote:
> >
> >More precisely, the semantics of "extern inline" functions changed
> >between ISO C90 and ISO C99.
>
> Perhaps a clearer explanation to readers is: "extern inline" and "inline" swap
> semantics with gnu_inline (-fgnu89-inline or __attribu
On Tue, Mar 1, 2022 at 11:43 AM Miguel Ojeda
wrote:
>
> On Mon, Feb 28, 2022 at 11:32 AM Arnd Bergmann wrote:
> >
> > -under ``-std=gnu89`` [gcc-c-dialect-options]_: the GNU dialect of ISO C90
> > -(including some C99 features). ``clang`` [clang]_ is also supported, see
On Mon, Feb 28, 2022 at 6:02 PM Masahiro Yamada wrote:
>
> On Mon, Feb 28, 2022 at 7:32 PM Arnd Bergmann wrote:
> >
> > From: Arnd Bergmann
> >
> > During a patch discussion, Linus brought up the option of changing
> > the C standard version from gnu89 t
On Mon, Feb 28, 2022 at 12:47 PM Marco Elver wrote:
> On Mon, 28 Feb 2022 at 11:32, Arnd Bergmann wrote:
>
> > Nathan Chancellor reported an additional -Wdeclaration-after-statement
> > warning that appears in a system header on arm, this still needs a
> > workaro
On Mon, Feb 28, 2022 at 1:14 AM John Stoffel wrote:
>
> On Sun, Feb 27, 2022 at 10:52:43PM +0100, Arnd Bergmann wrote:
> > From: Arnd Bergmann
> >
> > During a patch discussion, Linus brought up the option of changing
> > the C standard version from gnu89 to gnu9
From: Arnd Bergmann
During a patch discussion, Linus brought up the option of changing
the C standard version from gnu89 to gnu99, which allows using variable
declaration inside of a for() loop. While the C99, C11 and later standards
introduce many other features, most of these are already
From: Arnd Bergmann
During a patch discussion, Linus brought up the option of changing
the C standard version from gnu89 to gnu99, which allows using variable
declaration inside of a for() loop. While the C99, C11 and later standards
introduce many other features, most of these are already
On Mon, Feb 28, 2022 at 1:36 PM Jani Nikula wrote:
> >
> > One minor issue that remains is an added gcc warning for shifts of
> > negative integers when building with -Werror, which happens with the
> > 'make W=1' option, as well as for three drivers in the kernel that always
> > enable -Werror, b
On Mon, Feb 28, 2022 at 12:04 AM Alex Elder wrote:
> On 2/27/22 3:52 PM, Arnd Bergmann wrote: From: Arnd Bergmann
> > I put the suggestion into patch form, based on what we discussed
> > in the thread. I only gave it minimal testing, but it would
> > be good to have it in
On Sun, Feb 27, 2022 at 11:36 PM Linus Torvalds
wrote:
>
> And I don't want somebody with a newer compiler version to not notice
> that he or she ended up using a c17 feature, just because _that_
> compiler supported it, and then other people get build errors because
> their compilers use gnu11 in
On Mon, Feb 28, 2022 at 12:25 PM Mark Rutland wrote:
> On Mon, Feb 28, 2022 at 11:27:43AM +0100, Arnd Bergmann wrote:
> >
> > Nathan Chancellor reported an additional -Wdeclaration-after-statement
> > warning that appears in a system header on arm, this still needs a
> &
On Fri, Nov 19, 2021 at 5:22 PM Alejandro Colomar (man-pages)
wrote:
> On 11/19/21 17:18, Arnd Bergmann wrote:
> > On Fri, Nov 19, 2021 at 5:10 PM Andy Shevchenko
> > wrote:
> >> On Fri, Nov 19, 2021 at 04:57:46PM +0100, Arnd Bergmann wrote:
> >
> >>> T
On Fri, Nov 19, 2021 at 5:12 PM Alejandro Colomar (man-pages)
wrote:
>
> On 11/19/21 16:57, Arnd Bergmann wrote:
> >
> > From what I can tell, linux/stddef.h is tiny, I don't think it's really
> > worth optimizing this part. I have spent some time last year
>
On Fri, Nov 19, 2021 at 5:10 PM Andy Shevchenko
wrote:
> On Fri, Nov 19, 2021 at 04:57:46PM +0100, Arnd Bergmann wrote:
> > The main problem with this approach is that as soon as you start
> > actually reducing the unneeded indirect includes, you end up with
> > countless .c
On Fri, Nov 19, 2021 at 4:06 PM Alejandro Colomar (man-pages)
wrote:
> On 11/19/21 15:47, Arnd Bergmann wrote:
> > On Fri, Nov 19, 2021 at 12:36 PM Alejandro Colomar
>
> Yes, I would like to untangle the dependencies.
>
> The main reason I started doing this splitting
>
On Fri, Nov 19, 2021 at 12:36 PM Alejandro Colomar
wrote:
>
> Alejandro Colomar (17):
> linux/container_of.h: Add memberof(T, m)
> Use memberof(T, m) instead of explicit NULL dereference
> Replace some uses of memberof() by its wrappers
> linux/memberof.h: Move memberof() to separate heade
On Wed, Oct 27, 2021 at 3:41 PM Jani Nikula wrote:
> > @@ -16,10 +18,6 @@ config DRM_I915
> > select IRQ_WORK
> > # i915 depends on ACPI_VIDEO when ACPI is enabled
> > # but for select to work, need to select ACPI_VIDEO's dependencies,
> > ick
>
> The comment needs updating as w
From: Arnd Bergmann
Rather than having CONFIG_FB_BACKLIGHT select CONFIG_BACKLIGHT_CLASS_DEVICE,
make any driver that needs it have a dependency on the class device
being available, to prevent circular dependencies.
This is the same way that the backlight is already treated for the DRM
From: Arnd Bergmann
Selecting FB_DDC currently turns on CONFIG_I2C implicitly,
which is often not desired and can lead to circular dependencies.
Change this to a 'depends on' and change all drivers that
rely on FB_DDC to have an appropriate I2C dependency as well.
Signed-off-by: Arn
From: Arnd Bergmann
The i915 driver can use the backlight subsystem as an option, and usually
selects it when CONFIG_ACPI is set. However it is possible to configure
a kernel with modular backlight classdev support and a built-in i915
driver, which leads to a linker error:
drivers/gpu/drm/i915
From: Arnd Bergmann
The x86 low-level cache management operations are declared in
asm/smp.h, so drivers that call into this code need to include
the header:
drivers/gpu/drm/i915/gem/i915_gem_dmabuf.c:248:3: error: implicit declaration
of function 'wbinvd_on_all_cpus' [-Werror,
On Thu, Oct 7, 2021 at 11:51 AM Geert Uytterhoeven wrote:
> On Wed, Oct 6, 2021 at 9:28 AM Christian König
> wrote:
> > Am 06.10.21 um 09:20 schrieb Stephen Rothwell:
> > > On Tue, 5 Oct 2021 22:48:03 -0700 Randy Dunlap
> > > wrote:
> > >> on i386:
> > >>
> > >> ld: drivers/gpu/drm/msm/hdmi/hd
On Wed, Oct 13, 2021 at 12:54 PM Arnd Bergmann wrote:
> On Thu, Oct 7, 2021 at 11:51 AM Geert Uytterhoeven
> wrote:
>
> -msm-$(CONFIG_DRM_FBDEV_EMULATION) += msm_fbdev.o
> -msm-$(CONFIG_COMMON_CLK) += disp/mdp4/mdp4_lvds_pll.o
> -msm-$(CONFIG_COMMON_CLK) += hdmi/hdmi
From: Arnd Bergmann
The Kconfig dependency is incomplete since DRM_I915_GVT is a 'bool'
symbol that depends on the 'tristate' VFIO_MDEV. This allows a
configuration with VFIO_MDEV=m, DRM_I915_GVT=y and DRM_I915=y that
causes a link failure:
x86_64-linux-ld: drivers/gpu/dr
On Tue, Mar 30, 2021 at 10:41 AM Michal Koutný wrote:
>
> On Mon, Mar 22, 2021 at 05:02:44PM +0100, Arnd Bergmann
> wrote:
> > I'm not sure what is expected to happen for such a configuration,
> > presumably these functions are never calls in that case.
> Yes, th
SIZE - 2],
int lane_count);
bool drm_dp_clock_recovery_ok(const u8 link_status[DP_LINK_STATUS_SIZE],
int lane_count);
This obviously needs a good explanation in the code and the changelog text,
which I don't have, but if the above is what you had in mind, plea
On Mon, Mar 22, 2021 at 9:29 PM Ingo Molnar wrote:
> * Arnd Bergmann wrote:
> > From: Arnd Bergmann
> This is indeed rather ugly - and the other patch that removes a debug
> check seems counterproductive as well.
>
> Do we know how many genuine bugs -Wstringop-overread-wa
On Mon, Mar 22, 2021 at 11:09 PM Martin Sebor wrote:
> On 3/22/21 2:29 PM, Ingo Molnar wrote:
> > * Arnd Bergmann wrote:
> >
> > I.e. the real workaround might be to turn off the
> > -Wstringop-overread-warning,
> > until GCC-11 gets fixed?
>
> In GC
From: Arnd Bergmann
gcc-11 warns about what appears to be an out-of-range array access:
In function ‘snb_wm_latency_quirk’,
inlined from ‘ilk_setup_wm_latency’ at
drivers/gpu/drm/i915/intel_pm.c:3108:3:
drivers/gpu/drm/i915/intel_pm.c:3057:9: error: ‘intel_print_wm_latency’ reading
16
From: Arnd Bergmann
gcc gets confused by the comparison of a pointer to an integer listeral,
with the assumption that this is an offset from a NULL pointer and that
dereferencing it is invalid:
In file included from arch/x86/boot/compressed/misc.c:18:
In function ‘parse_elf’,
inlined from
From: Arnd Bergmann
gcc-11 warns about using string operations on pointers that are
defined at compile time as offsets from a NULL pointer. Unfortunately
that also happens on the result of fix_to_virt(), which is a
compile-time constant for a constantn input:
arch/x86/kernel/tboot.c: In
From: Arnd Bergmann
gcc-11 notices that the fields as defined in the ass_req_format
structure do not match the actual use of that structure:
cc1: error: writing 4 bytes into a region of size between 18446744073709551613
and 2 [-Werror=stringop-overflow=]
drivers/net/wireless/atmel/atmel.c:2884
From: Arnd Bergmann
gcc-11 warns that intel_dp_check_mst_status() has a local array of
fourteen bytes and passes the last four bytes into a function that
expects a six-byte array:
drivers/gpu/drm/i915/display/intel_dp.c: In function
‘intel_dp_check_mst_status’:
drivers/gpu/drm/i915/display
From: Arnd Bergmann
gcc warns that accessing a pointer based on a numeric constant may
be an offset into a NULL pointer, and would therefore has zero
accessible bytes:
arch/arm/common/sharpsl_param.c: In function ‘sharpsl_save_param’:
arch/arm/common/sharpsl_param.c:43:9: error: ‘memcpy
From: Arnd Bergmann
gcc-11 introdces a harmless warning for cap_inode_getsecurity:
security/commoncap.c: In function ‘cap_inode_getsecurity’:
security/commoncap.c:440:33: error: ‘memcpy’ reading 16 bytes from a region of
size 0 [-Werror=stringop-overread]
440
From: Arnd Bergmann
gcc-11 warns about an strnlen with a length larger than the size of the
passed buffer:
drivers/scsi/lpfc/lpfc_attr.c: In function 'lpfc_nvme_info_show':
drivers/scsi/lpfc/lpfc_attr.c:518:25: error: 'strnlen' specified bound 4095
exceeds source size
From: Arnd Bergmann
gcc-11 with the kernel address sanitizer prints a warning for this
driver:
In function 'ath11k_peer_assoc_h_vht',
inlined from 'ath11k_peer_assoc_prepare' at
drivers/net/wireless/ath/ath11k/mac.c:1632:2:
drivers/net/wireless/ath/ath11k/
From: Arnd Bergmann
gcc-11 warns that the size of the link name is longer than the di_fname
field:
fs/qnx4/dir.c: In function ‘qnx4_readdir’:
fs/qnx4/dir.c:51:32: error: ‘strnlen’ specified bound 48 exceeds source size 16
[-Werror=stringop-overread]
51 | size
From: Arnd Bergmann
When cgroups are enabled, but every single subsystem is turned off,
CGROUP_SUBSYS_COUNT is zero, and the cgrp->subsys[] array has no
members.
gcc-11 points out that this leads to an invalid access in any function
that might access this array:
kernel/cgroup/cgroup.c:
From: Arnd Bergmann
The coming gcc release introduces a new warning for string operations
reading beyond the end of a fixed-length object. After testing
randconfig kernels for a while, think I have patches for any such
warnings that came up on x86, arm and arm64.
Most of these warnings are
On Mon, Jan 25, 2021 at 1:33 PM Chris Wilson wrote:
>
> Quoting Arnd Bergmann (2021-01-25 12:26:44)
> > From: Arnd Bergmann
> >
> > CONFIG_DRM_I915_DEBUG now selects CONFIG_DRM_I915_WERROR, but fails
> > to honor its dependencies:
> >
> > WARNI
From: Arnd Bergmann
The x86-specific wbinvd_on_all_cpus() function is exported
through asm/smp.h, causing a build failure in the i915 driver
when SMP is disabled:
drivers/gpu/drm/i915/i915_gem.c:1182:2: error: implicit declaration of function
'wbinvd_on_all_cpus' [-Werror,-Wimplici
From: Arnd Bergmann
CONFIG_DRM_I915_DEBUG now selects CONFIG_DRM_I915_WERROR, but fails
to honor its dependencies:
WARNING: unmet direct dependencies detected for DRM_I915_WERROR
Depends on [n]: HAS_IOMEM [=y] && DRM_I915 [=m] && EXPERT [=y] &&
!COMPILE_TE
From: Arnd Bergmann
Randconfig builds on 32-bit machines show lots of warnings for
the i915 driver for passing a 32-bit value into __const_hweight64():
drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c:2584:9: error: shift count >=
width of type [-Werror,-Wshift-count-overflow]
ret
From: Arnd Bergmann
Randconfig builds on 32-bit machines show lots of warnings for
the i915 driver for incorrect bit masks like:
drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c:2584:9: error: shift count >=
width of type [-Werror,-Wshift-count-overflow]
return hweight64(VDBOX_MASK(&a
On Wed, Dec 30, 2020 at 4:56 PM Chris Wilson wrote:
>
> Quoting Arnd Bergmann (2020-12-30 15:39:14)
> > From: Arnd Bergmann
> >
> > Randconfig builds on 32-bit machines show lots of warnings for
> > the i915 driver for incorrect bit masks like:
>
> mask is
in softirq
> 2 maps in interrupt
>
> So a total of 16 is sufficient and probably overestimated.
>
> Signed-off-by: Thomas Gleixner
Acked-by: Arnd Bergmann
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
' was declared here
288 | unsigned long flags;
| ^
Split out the part between the locks into a separate function
for readability and to let the compiler figure out what the
logic actually is.
Fixes: d79e1bd676f0 ("drm/i915/pmu: Only use exclusive mmio ac
be-uninitialized]
I could not figure out a good way to do this in a way that gcc
understands better, so initialize the variable to zero, as last
resort.
Fixes: aee20aaed887 ("drm/i915: Implement read-only support in whitelist
selftest")
Signed-off-by: Arnd Bergmann
---
drivers/gpu/drm/
to detect rollback during
batchbuffer preemption")
Signed-off-by: Arnd Bergmann
---
drivers/gpu/drm/i915/gt/selftest_lrc.c | 21 +
1 file changed, 13 insertions(+), 8 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/selftest_lrc.c
b/drivers/gpu/drm/i915/gt/selftest_lrc.c
index 824
le_user_to_hw(struct intel_connector *connector,
|^~~~
Move the function itself into that #ifdef as well.
Fixes: 81b55ef1f47b ("drm/i915: drop a bunch of superfluous inlines")
Signed-off-by: Arnd Bergmann
---
drivers/gpu/drm/i915/display/intel_panel.c | 2
mean 'wrmsr_on_cpus'?
[-Werror=implicit-function-declaration]
wbinvd_on_all_cpus();
^~
wrmsr_on_cpus
Add the missing header file.
Fixes: 2c86e55d2ab5 ("drm/i915/gtt: split up i915_gem_gtt")
Signed-off-by: Arnd Bergmann
---
I ran into this bug a few days ago o
ed reference to
`backlight_device_unregister'
Add another Kconfig option to ensure the driver only tries to use
the backlight support when it can in fact be linked that way. The
new option is on by default to keep the existing behavior.
This is roughly what other drivers like nouveau do as well.
Signed-off-by: Arn
This function has been unused since commit 5ed0bdf21a85 ("drm: i915:
Use nsec based interfaces"). Let's remove the definition as well now
to help get rid of all uses of 'timespec'.
Signed-off-by: Arnd Bergmann
---
drivers/gpu/drm/i915/i915_drv.h | 8
1
atchwork.freedesktop.org/series/39939/ is my version of the fix for
> this. (Now merged.) Hopefully it works for your randconfigs as well and
> thanks for sending a patch in the first place!
The patch looks good to me, thanks for the follow-up
Acked-by: Arnd Bergmann
I didn't test it, b
On Tue, Mar 13, 2018 at 6:46 PM, Tvrtko Ursulin
wrote:
>
> On 13/03/2018 16:19, Arnd Bergmann wrote:
>>
>> The conditional spinlock confuses gcc into thinking the 'flags' value
>> might contain uninitialized data:
>>
>> drivers/gpu/drm/i915/i915_pmu.c
n this function [-Werror=maybe-uninitialized]
The code is correct, but it's easy to see how the compiler gets confused
here. This avoids the problem by pulling the lock outside of the function
into its only caller.
Fixes: 1fe699e30113 ("drm/i915/pmu: Fix sleep under atomic in RC6 readou
On Tue, Mar 13, 2018 at 1:31 PM, Chris Wilson wrote:
> Quoting Arnd Bergmann (2018-03-13 12:08:29)
>> The conditional spinlock confuses gcc into thinking the 'flags' value
>> might contain uninitialized data:
>>
>> drivers/gpu/drm/i915/i915_pmu.c: In function
On Tue, Mar 13, 2018 at 1:29 PM, Patchwork
wrote:
> == Series Details ==
>
> Series: drm/i915/pmu: avoid -Wmaybe-uninitialized warning
> URL : https://patchwork.freedesktop.org/series/39857/
> State : warning
>
> == Summary ==
>
> $ dim sparse origin/drm-tip
> Commit: drm/i915/pmu: avoid -Wmaybe
n this function [-Werror=maybe-uninitialized]
The code is correct, but it's easy to see how the compiler gets confused
here. This avoids the problem by pulling the lock outside of the function
into its only caller.
Fixes: 1fe699e30113 ("drm/i915/pmu: Fix sleep under atomic in RC6 readout"
This moves it into the CONFIG_BACKLIGHT_CLASS_DEVICE section that
its caller is in.
Signed-off-by: Arnd Bergmann
Signed-off-by: Daniel Vetter
Link:
https://patchwork.freedesktop.org/patch/msgid/20171127151239.1813673-2-a...@arndb.de
[arnd: manually rebased to 4.9]
Signed-off-by: Arn
struct timeval is deprecated because it cannot represent times
past 2038. In this driver, the only use of this structure is
to capture debug information. This is easily changed to ktime_t,
which we then format as needed when printing it later.
Reviewed-by: Chris Wilson
Signed-off-by: Arnd
On Mon, Dec 11, 2017 at 7:40 PM, Chris Wilson wrote:
> Quoting Chris Wilson (2017-12-11 12:51:42)
>> Quoting Arnd Bergmann (2017-12-11 12:46:22)
>> > v2: rebased after a1986f4174a4 ("drm/i915: Remove unnecessary PORT3
>> > definition.")
>> >
oose
port/pipe based registers")
Link: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80114
Link: https://lkml.org/lkml/2017/3/20/1022
Cc: Jani Nikula
Signed-off-by: Arnd Bergmann
---
v2: rebased after a1986f4174a4 ("drm/i915: Remove unnecessary PORT3
definition.")
---
drivers/gpu/dr
On Tue, Mar 21, 2017 at 12:23 PM, Jani Nikula
wrote:
> On Tue, 21 Mar 2017, Daniel Vetter wrote:
>> On Tue, Mar 21, 2017 at 09:44:07AM +0100, Arnd Bergmann wrote:
>>> On Tue, Mar 21, 2017 at 9:26 AM, Jani Nikula
>>> wrote:
>>> > On Mon, 20 Mar 2017, A
er to just remove this completely, possibly replace it with a
Kconfig fragment.
Fixes: bccd3b831185 ("drm/i915: Use trace_printk to provide a death rattle for
GEM")
Signed-off-by: Arnd Bergmann
---
drivers/gpu/drm/i915/Kconfig.debug | 2 ++
1 file changed, 2 insertions(+)
diff --g
:
'intel_backlight_device_register' defined but not used [-Werror=unused-function]
This marks the function as 'inline', which was surely the original
intention here.
Fixes: 1ebaa0b9c2d4 ("drm/i915: Move backlight registration to connector
registration")
Signed-off-by: Arnd Bergm
n that
its caller is in.
Signed-off-by: Arnd Bergmann
---
drivers/gpu/drm/i915/intel_panel.c | 88 +++---
1 file changed, 44 insertions(+), 44 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_panel.c
b/drivers/gpu/drm/i915/intel_panel.c
index adc51e452e3e..fa
On Wed, Nov 8, 2017 at 1:31 PM, Patchwork
wrote:
> == Series Details ==
>
> Series: drm: i915: remove timeval users
> URL : https://patchwork.freedesktop.org/series/33147/
> State : failure
> For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_6971/
Can someone explain to m
struct timeval is deprecated because it cannot represent times
past 2038. In this driver, the only use of this structure is
to capture debug information. This is easily changed to ktime_t,
which we then format as needed when printing it later.
Signed-off-by: Arnd Bergmann
---
drivers/gpu/drm
to get a clean build on top of today's
tree. I don't know which of the versions is the one we want,
so this may just as well be wrong.
Fixes: 05724bd054c3 ("Merge branch 'akpm/master'")
Signed-off-by: Arnd Bergmann
---
drivers/gpu/drm/i915/i915_gem.c | 2 ++
1 file
On Mon, Oct 16, 2017 at 1:35 PM, Mark Brown wrote:
> Hi all,
>
> Today's linux-next merge of the drm-intel tree got a conflict in:
>
> drivers/gpu/drm/i915/i915_gem.c
>
> between commit:
>
> b85577b72837e ("drm/i915: Order two completing nop_submit_request")
>
> from the drm-intel-fixes tree a
: Only touch archdata.iommu when it
exists")
Signed-off-by: Arnd Bergmann
---
drivers/gpu/drm/i915/selftests/mock_gem_device.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/selftests/mock_gem_device.c
b/drivers/gpu/drm/i915/selftests/mock_gem_d
n the number as an array index later on.
Fixes: cc9cabfdec38 ("drm/i915/cnl: Move voltage check into ddi buf trans
functions.")
Signed-off-by: Arnd Bergmann
---
drivers/gpu/drm/i915/intel_ddi.c | 12 +---
1 file changed, 9 insertions(+), 3 deletions(-)
diff --git a/drivers/gp
eo driver that explicitly selects 'THERMAL'. Turning
this into a 'depends on' addresses the problem.
For completeness, I'm also removing the redundant 'select THERMAL'
from INTEL_MENLOW, so no other driver uses that statement.
Fixes: bcdfb5e56dc5 ("drm/etnaviv:
h 'depends on LCD_CLASS_DEVICE', that would clean
it up some more, but it is also a more invasive change that we
can do separately at some point.
Arnd
Arnd Bergmann (3):
backlight: always select BACKLIGHT_LCD_SUPPORT for
BACKLIGHT_CLASS_DEVICE
ACPI/DRM: rework ACPI_VIDEO
r dependency with X86_PLATFORM_DEVICES/NOUVEAU.
Signed-off-by: Arnd Bergmann
---
drivers/acpi/Kconfig| 5 -
drivers/gpu/drm/gma500/Kconfig | 6 +-
drivers/gpu/drm/i915/Kconfig| 7 +--
drivers/gpu/drm/nouveau/Kconfig | 10 ++
drivers/platform/x86/Kconfi
users of BACKLIGHT_CLASS_DEVICE also select
BACKLIGHT_LCD_SUPPORT, but not all of them do. This makes the remaining
ones behave like the others.
It would probably be best to rework the way those two options related
entirely, but for now this takes the simpler and safer approach to
fix the war
On Tue, May 2, 2017 at 10:41 AM, Stephen Rothwell wrote:
> Hi Daniel,
>
> On Tue, 2 May 2017 10:25:18 +0200 Daniel Vetter wrote:
>>
>> Since this is an all-new driver it might be best to stagger the pull
>> requests and merge the new tee subsystem (or whatever it is) after drm?
>>
>> Not sure wha
bytes [-Werror=frame-larger-than=]
>
> Reported-by: Arnd Bergmann
> Fixes: 66d9cb5d805a ("drm/i915: Mock the GEM device for self-testing")
> Signed-off-by: Chris Wilson
> Cc: Joonas Lahtinen
> Cc: Tvrtko Ursulin
> Cc: Matthew Auld
> Cc: Arnd Bergmann
This is
On Tue, Mar 21, 2017 at 12:23 PM, Jani Nikula
wrote:
> On Tue, 21 Mar 2017, Daniel Vetter wrote:
>> On Tue, Mar 21, 2017 at 09:44:07AM +0100, Arnd Bergmann wrote:
> Arnd, can you check that with kasan please? (I don't have gcc 7.) For me
> the size diff against current
1 - 100 of 113 matches
Mail list logo
