David and the maintainers of mga_dma.c I am wondering about remove this
function and whether I can or do I need to keep it around for other parts of
this driver to work. In addition I will paste the function below from your
convience.
Nick
#if 0
FIXME: Still needed?
*/
static void
Greetings again David and other maintainers,
I am wondering if I can remove the following code below my message in psb_drv.h
as you state it's unneeded in a TODO.
Cheers Nick
/* TODO: To get rid of */
#define PSB_TT_PRIV0_LIMIT (256*1024*1024)
#define PSB_TT_PRIV0_P
Greetings David,
I am wondering whether we can remove the fix me in this file related to
not needing a spin lock or should I remove the comment for locks and then
remove the FIX ME if we need the lock here.
Regards Nick
David,
I am posting some code below this message. Please tell me what you mean by this
fix me in the code pasted.
Nick
int mga_warp_init(drm_mga_private_t *dev_priv)
{
u32 wmisc;
/* FIXME: Get rid of these damned magic numbers...
*/
switch (dev_priv->chip
Sorry about that Patrik. I will resend a v2 with just the FIXME removed.
Regards Nick
On 2014-11-30 08:02 AM, Patrik Jakobsson wrote:
> On Sun, Nov 30, 2014 at 3:24 AM, Nicholas Krause
> wrote:
>> Removes unneeeded struct *lvds_i2c_bus of type, psb_intel_i2c_chan as this
>&g
n", name);
> diff --git a/lib/test_fortify/read_overflow2_field-memcpy.c
> b/lib/test_fortify/read_overflow2_field-memcpy.c
> new file mode 100644
> index ..de9569266223
> --- /dev/null
> +++ b/lib/test_fortify/read_overflow2_field-memcpy.c
> @@ -0,0 +1,5 @@
> +// SPDX-License-Identifier: GPL-2.0-only
> +#define TEST \
> + memcpy(large, instance.buf, sizeof(instance.buf) + 1)
> +
> +#include "test_fortify.h"
> diff --git a/lib/test_fortify/write_overflow_field-memcpy.c
> b/lib/test_fortify/write_overflow_field-memcpy.c
> new file mode 100644
> index ..28cc81058dd3
> --- /dev/null
> +++ b/lib/test_fortify/write_overflow_field-memcpy.c
> @@ -0,0 +1,5 @@
> +// SPDX-License-Identifier: GPL-2.0-only
> +#define TEST \
> + memcpy(instance.buf, large, sizeof(instance.buf) + 1)
> +
> +#include "test_fortify.h"
> --
I haven't read the whole series yet, but I assume test_fortify.h was
provided earlier in the series?
--
Thanks,
~Nick Desaulniers
;
> These are fine:
>
> struct foo ok1 = { };
> struct foo ok2 = { .flag = 7 };
> struct foo ok3 = { .ptr = NULL };
>
> This is not:
>
> struct foo bad = { .flag = 7, .ptr = NULL };
>
> (But, of course, it depends on padding size, compiler version, and
> architecture. i.e. things remain unreliable.)
>
> --
--
Thanks,
~Nick Desaulniers
2]: https://lore.kernel.org/r/20210824022640.2170859-1-nat...@kernel.org/
>
> Signed-off-by: Nathan Chancellor
Thanks for the patch! Do you need to re-ping, rebase, or resend that
other series?
Reviewed-by: Nick Desaulniers
> ---
>
> NOTE: This is based on my series to enable
Add a basic GPU node for mt8192.
Signed-off-by: Nick Fan
---
This patch depends on Mediatek power and regulator support.
Listed as following.
[1]https://lore.kernel.org/patchwork/patch/1336293/
[2]https://patchwork.kernel.org/project/linux-mediatek/list/?series=374013
[3]https
Thanks for your review.
These are fixed in v5 as following link.
https://lore.kernel.org/patchwork/patch/1372271/
Nick Fan
On Thu, 2021-01-14 at 14:14 -0600, Rob Herring wrote:
> On Tue, Jan 12, 2021 at 02:49:32PM +0800, Nick Fan wrote:
> > Add devicetree schema for Arm Mali Va
Add devicetree schema for Arm Mali Valhall GPU
Define a compatible string for the Mali Valhall GPU
for Mediatek's SoC platform.
Signed-off-by: Nick Fan
---
.../bindings/gpu/arm,mali-valhall.yaml| 217 ++
1 file changed, 217 insertions(+)
create mode 1
(writable)
> > 1916*writable = true;
> > 1917
> > 1918 /*
> > 1919 * Get a reference here because callers of
> > *hva_to_pfn* and
> > 1920 * *gfn_to_pfn* ultimately call kvm_release_pfn_clean
> > on the
> > 1921 * returned pfn. This is only needed if the VMA has
> > VM_MIXEDMAP
> > 1922 * set, but the kvm_get_pfn/kvm_release_pfn_clean
> > pair will
> > 1923 * simply do nothing for reserved pfns.
> > 1924 *
> > 1925 * Whoever called remap_pfn_range is also going to
> > call e.g.
> > 1926 * unmap_mapping_range before the underlying pages
> > are freed,
> > 1927 * causing a call to our MMU notifier.
> > 1928 */
> > 1929kvm_get_pfn(pfn);
> > 1930
> > 1931*p_pfn = pfn;
> > 1932return 0;
> > 1933}
> > 1934
> >
> > ---
> > 0-DAY CI Kernel Test Service, Intel Corporation
> > https://lists.01.org/hyperkitty/list/kbuild-...@lists.01.org
>
>
>
> --
> Daniel Vetter
> Software Engineer, Intel Corporation
> http://blog.ffwll.ch
>
> --
> You received this message because you are subscribed to the Google Groups
> "Clang Built Linux" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to clang-built-linux+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/clang-built-linux/20201130142820.GN401619%40phenom.ffwll.local.
--
Thanks,
~Nick Desaulniers
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
way.
>
> Right, looking at my latest randconfig logs, I see the same problem on x86
> builds with clang as well, though I'm not entirely sure which other
> configuration
> options are needed to trigger it.
>
> So my patch can be disregarded, but I agree this needs a better fix,
> either in clang or in the dcn driver.
If you could give https://github.com/ClangBuiltLinux/frame-larger-than
a spin again, I would appreciate any feedback.
--
Thanks,
~Nick Desaulniers
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
On Tue, Dec 8, 2020 at 6:26 AM Arnd Bergmann wrote:
>
> On Mon, Dec 7, 2020 at 11:28 PM 'Nick Desaulniers' via Clang Built
> Linux wrote:
> >
> > On Mon, Dec 7, 2020 at 2:17 PM Arnd Bergmann wrote:
> > >
> > > On Mon, Dec 7, 2020 at 11:08 PM
On Tue, Dec 8, 2020 at 2:18 PM Arnd Bergmann wrote:
>
> On Tue, Dec 8, 2020 at 7:21 PM 'Nick Desaulniers' via Clang Built
> Linux wrote:
> >
> > On Tue, Dec 8, 2020 at 6:26 AM Arnd Bergmann wrote:
> > >
> > > On Mon, Dec 7, 2020 at 11:28 PM
.
> Enable it now that i915 is clean so that it stays that way.
>
> Signed-off-by: Nathan Chancellor
Thanks for the series!
Reviewed-by: Nick Desaulniers
> ---
> drivers/gpu/drm/i915/Makefile | 1 -
> 1 file changed, 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/i915/Ma
On Thu, Sep 30, 2021 at 10:10 AM Alex Deucher wrote:
>
> Applied. Thanks!
>
> Alex
>
> On Thu, Sep 30, 2021 at 12:23 PM Nathan Chancellor wrote:
> >
> > Clang warns:
Any chance AMDGPU folks can look into adding clang to the CI roster?
--
Thanks,
~Nick Desaulniers
Macs
because the BIOS image provides by OF is only the used parts of the ROM,
not a power-of-two blocks read from PCI directly so PCs always have
empty bytes at the end that are never accesseed.
Signed-off-by: Nick Lopez
---
drivers/gpu/drm/nouveau/nvkm/subdev/bios/base.c | 2 +-
1 file changed, 1 inse
Convert the Arm Valhall GPU binding to DT schema format.
Define a compatible string for the Mali Valhall GPU
for Mediatek's SoC platform.
Signed-off-by: Nick Fan
---
.../bindings/gpu/arm,mali-valhall.yaml| 252 ++
1 file changed, 252 insertions(+)
create mode 1
Add a basic GPU node for mt8192.
Signed-off-by: Nick Fan
---
This patch depends on Mediatek power and regulator support.
Listed as following.
[1]https://lore.kernel.org/patchwork/patch/1336293/
[2]https://patchwork.kernel.org/project/linux-mediatek/list/?series=374013
[3]https
Add a basic GPU node for mt8192.
Signed-off-by: Nick Fan
---
This patch depends on Mediatek power and regulator support.
Listed as following.
[1]https://lore.kernel.org/patchwork/patch/1336293/
[2]https://patchwork.kernel.org/project/linux-mediatek/list/?series=374013
[3]https
Convert the Arm Valhall GPU binding to DT schema format.
Define a compatible string for the Mali Valhall GPU
for Mediatek's SoC platform.
Signed-off-by: Nick Fan
---
.../bindings/gpu/arm,mali-valhall.yaml| 252 ++
1 file changed, 252 insertions(+)
create mode 1
Add devicetree schema for Arm Mali Valhall GPU
Define a compatible string for the Mali Valhall GPU
for Mediatek's SoC platform.
Signed-off-by: Nick Fan
---
.../bindings/gpu/arm,mali-valhall.yaml| 252 ++
1 file changed, 252 insertions(+)
create mode 1
Add a basic GPU node for mt8192.
Signed-off-by: Nick Fan
---
This patch depends on Mediatek power and regulator support.
Listed as following.
[1]https://lore.kernel.org/patchwork/patch/1336293/
[2]https://patchwork.kernel.org/project/linux-mediatek/list/?series=374013
[3]https
Add a basic GPU node for mt8192.
Signed-off-by: Nick Fan
---
This patch depends on Mediatek power and regulator support.
Listed as following.
[1]https://lore.kernel.org/patchwork/patch/1336293/
[2]https://patchwork.kernel.org/project/linux-mediatek/list/?series=374013
[3]https
Add devicetree schema for Arm Mali Valhall GPU
Define a compatible string for the Mali Valhall GPU
for Mediatek's SoC platform.
Signed-off-by: Nick Fan
---
.../bindings/gpu/arm,mali-valhall.yaml| 252 ++
1 file changed, 252 insertions(+)
create mode 1
Add a basic GPU node for mt8192.
Signed-off-by: Nick Fan
---
This patch depends on Mediatek power and regulator support.
Listed as following.
[1]https://lore.kernel.org/patchwork/patch/1336293/
[2]https://patchwork.kernel.org/project/linux-mediatek/list/?series=374013
[3]https
Add devicetree schema for Arm Mali Valhall GPU
Define a compatible string for the Mali Valhall GPU
for Mediatek's SoC platform.
Signed-off-by: Nick Fan
---
.../bindings/gpu/arm,mali-valhall.yaml| 252 ++
1 file changed, 252 insertions(+)
create mode 1
On Fri, 2021-01-08 at 15:58 +, Steven Price wrote:
> On 05/01/2021 05:36, Nick Fan wrote:
> > Add a basic GPU node for mt8192.
> >
> > Signed-off-by: Nick Fan
> > ---
> > This patch depends on Mediatek power and regulator support.
> >
>
*pipe = mdev->pipelines[0];
> - union komeda_config_id config_id = {0,};
Haven't seen a trailing comma too often. Thanks for the patch.
Reviewed-by: Nick Desaulniers
> + union komeda_config_id config_id;
> int i;
>
> + memset
like commit 46e2068081e9 ("drm/i915:
> Disable some extra clang warnings").
>
> Link: https://github.com/ClangBuiltLinux/linux/issues/220
> Signed-off-by: Nathan Chancellor
Reviewed-by: Nick Desaulniers
probably could give Chris Wilson the suggested by tag.
https://lore.ke
On Fri, Jan 25, 2019 at 11:34 PM Nick Desaulniers
wrote:
>
> On Fri, Jan 25, 2019 at 11:13 PM Nathan Chancellor
> wrote:
> >
> > This warning is disabled by default in scripts/Makefile.extrawarn when
> > W= is not provided but this Makefile adds -Wall after this wa
thub.com/ClangBuiltLinux/linux/issues/327
> >>>> Cc: sta...@vger.kernel.org # 4.19
> >>>> Reported-by: S, Shirish
> >>>> Reported-by: Matthias Kaehlcke
> >>>> Suggested-by: James Y Knight
> >>>> Suggested-by: Nathan Chancello
nfig and allyesconfig
> without any warnings with tip-of-tree Clang.
Also, please let us know about any other bugs found via testing with
Clang: https://github.com/ClangBuiltLinux/linux/issues
We're happy to take a look!
--
Thanks,
~Nick Desaulniers
_
ditionally pass unitialized memory to
functions. Invariants like "don't touch this possibly unitialized
memory in THIS case" don't always pass from maintainer to maintainer.
Thanks for the patch.
Reviewed-by: Nick Desaulniers
> Just zero initialize this variable so that Clang
t this_cpu;
+ unsigned long local_clock = local_clock_us(&this_cpu);
- if (time_after(local_clock_us(&this_cpu), timeout))
+ if (time_after(local_clock, timeout))
return true;
return this_cpu != cpu;
--
Thanks,
~Nick Desaulniers
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
e that know about this trick, the less it can be [ab]used.
--
Thanks,
~Nick Desaulniers
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
ck for other patches for this warning
when the code was dead or not obviously some kind of
bug/typo/copy-pasta.
Nathan, please submit a patch removing the dead code; it may be
reverted later when it's actually wired up. Nothing is truly lost w/
git*.
--
Thanks,
~Nick Desaulniers
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
igned at the
> bottom of this file but Clang can't tell that. If the callback were
> ever to disappear, num_of_levels would never be initialized. Just
> zero initialize it to ensure that the intent behind this code
> remains the same.
Thanks for the simple fix.
Reviewed-by: Nick D
't disable kernel-wide for most cases.
-Wenum-conversion has spotted many bugs. While the enums in question
today are not different, they MIGHT eventually diverge and lead to
bugs, like the others we've found and fixed throughout the kernel. So
I would r
cc_stack_align := -mpreferred-stack-boundary=4
> +else ifneq ($(call cc-option, -mstack-alignment=16),)
> + cc_stack_align := -mstack-alignment=16
> +endif
> +
> +dsc_ccflags := -mhard-float -msse $(cc_stack_align)
> +
> +CFLAGS_rc_calc.o := $(dsc_ccflags)
> +CFLAGS_
Clang from
emitting libcalls to undefined SW FP routines"")
due to bugreports from GCC builds. Add guards to only do so for Clang.
Link: https://bugs.freedesktop.org/show_bug.cgi?id=109487
Link: https://github.com/ClangBuiltLinux/linux/issues/327
Suggested-by: Sedat Dilek
Suggested-by: Sami
From: Nick Hawkins
GXP is the name of the HPE SoC.
This SoC is used to implement BMC features of HPE servers
(all ProLiant, Synergy, and many Apollo, and Superdome machines)
It does support many features including:
ARMv7 architecture, and it is based on a Cortex A9 core
Use an
do {\
> + typeof(t1) __t1h = type_max(t1);\
> + typeof(t1) __t1l = type_min(t1);\
> + typeof(t2) __t2h = type_max(t2);\
> + typeof(t2) __t2l = type_min(t2);\
Can we use __auto_type here rather than typeof(macro expansion)?
--
Thanks,
~Nick Desaulniers
ese
> lines. Normalize the indentation in these functions so that it is
> consistent with the Linux kernel coding style and clang no longer warns.
>
> Fixes: 1692b37c99d5 ("fbdev: Fix logo if logo depth is less than framebuffer
> depth")
> Link: https://github.com/ClangB
> Apparently this bug is still present in both the released clang-9
> and the current development version of clang-10.
> I was hoping we would not need a workaround in clang-9+, but
> it seems that we do.
I think I'd rather:
1. mark AMDGPU BROKEN if CC_IS_CLANG. There are numerous other issues bui
On Wed, Oct 2, 2019 at 10:07 AM Nathan Chancellor
wrote:
>
> On Wed, Oct 02, 2019 at 09:51:37AM -0700, 'Nick Desaulniers' via Clang Built
> Linux wrote:
> > > Apparently this bug is still present in both the released clang-9
> > > and the current develop
le.build:265: recipe for target
> 'drivers/gpu/drm/amd/amdgpu/../display/dc/dcn21/dcn21_resource.o' failed
>
> Use the same variant that we have for dcn20 to fix compilation.
>
> Fixes: eced51f9babb ("drm/amd/display: Add hubp block for Renoir (v2)")
> S
On Wed, Oct 2, 2019 at 2:24 PM Alex Deucher wrote:
>
> On Wed, Oct 2, 2019 at 5:19 PM Nick Desaulniers
> wrote:
> >
> > Alex, do you know why the AMDGPU driver uses a different stack
> > alignment (16B) than the rest of the x86 kernel? (see
> > arch/x86/Makef
ould silence the warning.
> >
> > I do like this one better than the former.
>
> FWIW, one downside of this one compared to all alternatives (presumably)
> is that it might end up generating actual code even on 64-bit, which
> always ends up skipping the return.
The warning is pointing out that the conditional is always false,
which is correct on 64b. The check is only active for 32b.
https://godbolt.org/z/oQrgT_
The cast silences the warning for 64b. (Note that GCC and Clang also
generate precisely the same instruction sequences in my example, just
GCC doesn't warn on such tautologies).
--
Thanks,
~Nick Desaulniers
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Sorry for my late reply.
I have checked internally.
The MT8183_POWER_DOMAIN_MFG_2D is just a legacy name, not really 2D
domain.
If the naming too confusing, we can change this name to
MT8183_POWER_DOMAIN_MFG_CORE2 for consistency.
Thanks
Nick Fan
On Wed, 2020-02-26 at 08:55 +0800, Nicolas
Wswitch-unreachable]
> 4395 | int sad_count;
> | ^
>
> [1] https://bugs.llvm.org/show_bug.cgi?id=44916
>
> Signed-off-by: Kees Cook
Reviewed-by: Nick Desaulniers
> ---
> v2: move into function block instead being switch-local (Ville Syrjälä)
&g
On Fri, Mar 6, 2020 at 9:36 AM Nick Desaulniers wrote:
>
> On Fri, Mar 6, 2020 at 9:32 AM Kees Cook wrote:
> >
> > Variables declared in a switch statement before any case statements
> > cannot be automatically initialized with compiler instrumentation (as
> > they
On Fri, 2020-03-06 at 14:43 +, Steven Price wrote:
> On Fri, Mar 06, 2020 at 02:13:08PM +, Rob Herring wrote:
> > On Thu, Mar 5, 2020 at 8:34 PM Nick Fan wrote:
> > >
> > > Sorry for my late reply.
> > > I have checked internally.
> > > The MT8
_ptr(entry->relocs_ptr);
remain = entry->relocation_count;
+#ifndef CONFIG_64BIT
if (unlikely(remain > N_RELOC(ULONG_MAX)))
return -EINVAL;
+#endif
/*
* We must check that the entire relocation array is safe
```
We now have 4 proposed solutions:
1. https://lore.kernel.org/lkml/20191123195321.41305-1-natechancel...@gmail.com/
2. https://lore.kernel.org/lkml/20200211050808.29463-1-natechancel...@gmail.com/
3. https://lore.kernel.org/lkml/20200214054706.33870-1-natechancel...@gmail.com/
4. my diff above
Let's please come to a resolution on this.
--
Thanks,
~Nick Desaulniers
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
rq_dlg_calc.o := $(dml_ccflags)
> -CFLAGS_display_rq_dlg_helpers.o := $(dml_ccflags)
> -CFLAGS_dml_common_defs.o := $(dml_ccflags)
> +CFLAGS_$(AMDDALPATH)/dc/dml/dml1_display_rq_dlg_calc.o := $(dml_ccflags)
> +CFLAGS_$(AMDDALPATH)/dc/dml/display_rq_dlg_helpers.o := $(dml_ccflags)
> +CFLAGS_$(AMDDALPATH)/dc/dml/dml_common_defs.o := $(dml_ccflags)
>
> DML = display_mode_lib.o display_rq_dlg_helpers.o
> dml1_display_rq_dlg_calc.o \
> dml_common_defs.o
--
Thanks,
~Nick Desaulniers
as a purpose for conveying information to the reader.
Well leaving a warning unaddressed is also not a solution. Either
replace it with a comment or turn off the warning for your subdir.
The warning here looks valid to me; you have a guard for something
that's impossible.
--
Thanks,
~Nick Desaulni
On Tue, Dec 3, 2019 at 5:42 AM Chris Wilson wrote:
>
> Quoting Nick Desaulniers (2019-12-02 19:18:20)
> > On Sat, Nov 23, 2019 at 12:05 PM Chris Wilson
> > wrote:
> > >
> > > Quoting Nathan Chancellor (2019-11-23 19:53:22)
> > > > -Wtautolog
.o := $(dsc_ccflags)
> -CFLAGS_rc_calc_dpi.o := $(dsc_ccflags)
> -CFLAGS_codec_main_amd.o := $(dsc_ccflags)
> -CFLAGS_dc_dsc.o := $(dsc_ccflags)
> +CFLAGS_$(AMDDALPATH)/dc/dsc/rc_calc.o := $(dsc_ccflags)
> +CFLAGS_$(AMDDALPATH)/dc/dsc/rc_calc_dpi.o := $(dsc_ccflags)
> +CFLAGS_$(AMDDALPATH)/dc/dsc/dc_dsc.o := $(dsc_ccflags)
>
> DSC = dc_dsc.o rc_calc.o rc_calc_dpi.o
>
--
Thanks,
~Nick Desaulniers
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
On Thu, Aug 8, 2019 at 1:22 PM Thomas Gleixner wrote:
> > tglx just picked up 2 other patches of mine, bumping just in case he's
> > not picking up patches while on vacation. ;)
>
> I'm only half on vacation :)
>
> So I can pick it up.
Thanks, will send h
replacement+0x36: redundant UACCESS disable
> > > > > > > >
> > > > > > > > __copy_from_user() already does both STAC and CLAC, so the
> > > > > > > > user_access_end() in its error path adds an extra unnecessary
> > > > >
e syncpoint interrupt handling")
> Signed-off-by: Arnd Bergmann
Thanks Arnd, I saw some reports from kernelci about this, too.
https://lore.kernel.org/linux-next/?q=warning%3A+variable+%27syncpt_irq%27+is+uninitialized+when+used+here
Reported-by: "kernelci.org bot"
Reviewed-by:
le when it is not (false positives), and modprobe
might succeed rather than failing with a suitable error message.
So remove it in the files in this commit, none of which can be built as
modules.
Signed-off-by: Nick Alcock
Suggested-by: Luis Chamberlain
Cc: Luis Chamberlain
Cc:
le when it is not (false positives), and modprobe
might succeed rather than failing with a suitable error message.
So remove it in the files in this commit, none of which can be built as
modules.
Signed-off-by: Nick Alcock
Suggested-by: Luis Chamberlain
Cc: Luis Chamberlain
Cc:
le when it is not (false positives), and modprobe
might succeed rather than failing with a suitable error message.
So remove it in the files in this commit, none of which can be built as
modules.
Signed-off-by: Nick Alcock
Suggested-by: Luis Chamberlain
Cc: Luis Chamberlain
Cc:
le when it is not (false positives), and modprobe
might succeed rather than failing with a suitable error message.
So remove it in the files in this commit, none of which can be built as
modules.
Signed-off-by: Nick Alcock
Suggested-by: Luis Chamberlain
Cc: Luis Chamberlain
Cc:
le when it is not (false positives), and modprobe
might succeed rather than failing with a suitable error message.
So remove it in the files in this commit, none of which can be built as
modules.
Signed-off-by: Nick Alcock
Suggested-by: Luis Chamberlain
Cc: Luis Chamberlain
Cc:
le when it is not (false positives), and modprobe
might succeed rather than failing with a suitable error message.
So remove it in the files in this commit, none of which can be built as
modules.
Signed-off-by: Nick Alcock
Suggested-by: Luis Chamberlain
Cc: Luis Chamberlain
Cc:
x-ker...@vger.kernel.org
Cc: linux-me...@vger.kernel.org
Cc: linux...@kvack.org
Cc: linux-modu...@vger.kernel.org
Cc: x...@kernel.org
Nick Alcock (17):
irqchip: remove MODULE_LICENSE in non-modules
bus: remove MODULE_LICENSE in non-modules
braille_console: remove MODULE_LICENSE in non-modules
arm-cci: r
le when it is not (false positives), and modprobe
might succeed rather than failing with a suitable error message.
So remove it in the files in this commit, none of which can be built as
modules.
Signed-off-by: Nick Alcock
Suggested-by: Luis Chamberlain
Cc: Luis Chamberlain
Cc:
On Thu, Nov 10, 2022 at 02:47:52PM +0100, José Expósito wrote:
> Commit 6bed2ea3cb38 ("drm/vc4: hdmi: Reset link on hotplug") introduced
> the vc4_hdmi_reset_link() function. This function dereferences the
> "connector" pointer before checking whether it is NULL or not.
>
> Rework variable assignm
emove it.
Thanks for the patch!
Fixes: 64122c1f6ad ("drm: add new QXL driver. (v1.4)")
Reviewed-by: Nick Desaulniers
>
> Signed-off-by: Tom Rix
> ---
> drivers/gpu/drm/qxl/qxl_cmd.c | 2 --
> 1 file changed, 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/qxl/
truct drm_gem_object
> > *obj, struct vm_area_struc
> > struct qaic_bo *bo = to_qaic_bo(obj);
> > unsigned long offset = 0;
> > struct scatterlist *sg;
> > - int ret;
> > + int ret = 0;
> >
> > if (obj->import_attach)
> > return -EINVAL;
>
--
Thanks,
~Nick Desaulniers
PLL_FBKDIV_HS3, posdiv1, posdiv2, txprediv,
> > txposdiv, digital_div);
> > - if (ret)
> > - return -EINVAL;
> > -
> > - return 0;
> > }
> >
> > static int mtk_hdmi_pll_drv_setting(struct clk_hw *hw)
> >
> > --
> > 2.40.0
> >
>
--
Thanks,
~Nick Desaulniers
ic functions are not used, so remove them.
>
> Signed-off-by: Tom Rix
Thanks for the patch!
Reviewed-by: Nick Desaulniers
> ---
> drivers/gpu/drm/kmb/kmb_dsi.c | 28
> 1 file changed, 28 deletions(-)
>
> diff --git a/drivers/gpu/drm/kmb/kmb_dsi.c
ay(struct drm_device *dev)
> ^
> This function is not used, so remove it.
>
> Signed-off-by: Tom Rix
Thanks for the patch!
Reviewed-by: Nick Desaulniers
> ---
> drivers/gpu/drm/vmwgfx/vmwgfx_overlay.c | 6 --
> 1 file changed, 6 deletions(-)
>
> diff --git a/driv
rcpy(pstrs, mksstat_kern_name_desc[stat_idx][0]);
> - strcpy(pstrd, mksstat_kern_name_desc[stat_idx][1]);
> -
> - pinfo[stat_idx].name.s = pstrs;
> - pinfo[stat_idx].description.s = pstrd;
> - pinfo[stat_idx].flags = MKS_GUEST_STAT_FLAG_NONE;
This was the
se
> + if (assignment.stream != state->streams[i])
> valid_stream_ptrs = false;
> }
> }
> --
> 2.27.0
>
--
Thanks,
~Nick Desaulniers
ther call sites have
comments like:
114 /*XXX: warn? */
134 /*XXX: warn? */
or other places where the return code isn't checked makes me think
that a better approach would be to
1. plumb error codes back up through nouveau_pfns_map() (and other
call sites of nvif_object_ioctl)
2. consider making nvif_object_ioctl __must_check
>
> mutex_unlock(&svmm->mutex);
> }
> --
> 2.27.0
>
--
Thanks,
~Nick Desaulniers
0;
> ^
> This variable is not used so remove it.
>
> Signed-off-by: Tom Rix
Thanks for the patch!
Fixes: commit 75145aab7a0d ("drm/amdgpu/swsmu: clean up a bunch of
stale interfaces")
Reviewed-by: Nick Desaulniers
> ---
> drivers/gpu/drm/amd/pm/swsmu/am
t; This variable is not used so remove it.
>
> Signed-off-by: Tom Rix
Thanks for the patch!
Fixes: 74d9a6335dce ("drm/qxl: Simplify cleaning qxl processing command")
Reviewed-by: Nick Desaulniers
That commit should also have removed the label out_free_bos IMO since
having two labels f
^
> This variable is not used so remove it.
>
> Signed-off-by: Tom Rix
Ben, any idea if this was supposed to be used somewhere? If not:
Fixes: 4b569ded09fd ("drm/nouveau/acr/ga102: initial support")
Reviewed-by: Nick Desaulniers
> ---
> drivers/gpu/drm/nouvea
On Fri, Apr 7, 2023 at 10:52 AM Nick Desaulniers
wrote:
>
> Jimmy, can you review?
>
> The change LGTM; but I'm not sure if there was something else intended here.
Nevermind, Jimmy's email address bounced.
Reviewed-by: Nick Desaulniers
>
> On Sat, Mar 25, 20
(Sorry about this, MTA delivered a bunch of stuff very late.)
On 3 Mar 2023, Luis Chamberlain verbalised:
> Stupid question, if you're removing MODULE_LICENSE() than why keep the
> other stupid MODULE_*() crap too? If its of no use, be gone!
I wish, but when I tried it it broke stuff. At least s
n you actually build things:
>
> make ARCH=i386
>
> because the ARCH choice ends up being in the .config file, but the
> makefiles themselves always take it from the environment.
>
> There are good historical reasons for our behavior (and probably a
> number of extant practical reasons too), but it's a bit annoying, and
> it would be lovely if we could start moving away from this model.
>
> Linus
>
--
Thanks,
~Nick Desaulniers
t; + mode = drm_mode_duplicate(connector->dev, ctx->desc->drm_mode);
> if (!mode)
> return -ENOMEM;
>
>
> base-commit: 37cee4876a45a5c3da79a83d34ed4f3c68548aef
> --
> 2.40.1
>
--
Thanks,
~Nick Desaulniers
On Tue, May 23, 2023 at 2:29 PM Nick Desaulniers
wrote:
>
> On Tue, May 23, 2023 at 2:20 PM Artur Weber wrote:
> >
> > Fixes compilation errors on older GCC versions (before 8.x) and Clang
> > after changes introduced in commit 6810bb390282 ("drm/panel: Add
> &g
by: Naresh Kamboju
> Closes:
> https://lore.kernel.org/CA+G9fYv68V3ewK0Qj-syQj7qX-hQr0H1MFL=qfnudoe_j2z...@mail.gmail.com/
> Signed-off-by: Nathan Chancellor
Thanks for the patch! I've never seen the closes tag before, that's
new to me. Can you tell me more about it?
A few mo
On Wed, May 24, 2023 at 11:41 AM Nathan Chancellor wrote:
>
> On Wed, May 24, 2023 at 11:32:32AM -0700, Nick Desaulniers wrote:
> > On Wed, May 24, 2023 at 8:38 AM Nathan Chancellor wrote:
> > >
> > > Clang warns:
> > >
> > > drivers/gp
t; drivers/gpu/drm/v3d/v3d_drv.h:343:24: note: remove constant to silence this
> warning
> 1 warning generated.
>
> Turn this into an explicit comparison against zero to make the
> expression a boolean to make it clear this should be a logical check,
> not a bitwise one.
>
>
context for GEM buffers v7")
> Link: https://gcc.gnu.org/onlinedocs/gcc/Statement-Exprs.html
> Link: https://github.com/ClangBuiltLinux/linux/issues/1890
> Link:
> https://github.com/llvm/llvm-project/commit/20219106060208f0c2f5d096eb3aed7b712f5067
> Reported-by: Nathan Chancellor
> R
gt; Reported-by: Nathan Chancellor
> Reported-by: Naresh Kamboju
> CC: Boris Brezillon
> Signed-off-by: Christian König
Works for me; thanks for the patch!
Reviewed-by: Nick Desaulniers
I suspect it's possible to change the indirect goto into a direct goto
with
On Wed, Aug 2, 2023 at 1:44 AM Boris Brezillon
wrote:
>
> On Tue, 1 Aug 2023 13:35:13 -0700
> Nick Desaulniers wrote:
>
> > On Mon, Jul 31, 2023 at 5:36 AM Christian König
> > wrote:
> > >
> > > GCC forbids to jump to labels in loop conditions and
On Thu, May 25, 2023 at 1:30 PM Matthieu Baerts
wrote:
>
> Hi Nick,
>
> On 24/05/2023 20:56, Nick Desaulniers wrote:
> > On Wed, May 24, 2023 at 11:41 AM Nathan Chancellor
> > wrote:
> >>
> >> On Wed, May 24, 2023 at 11:32:32AM -0700, Nick Desaulni
loop
variable is marked const twice.
While this particular call site does not modify the loop variable,
trying to do so would already result in a compile time failure, so we
can remove the current const. Other call sites do not mark the loop
variable const.
Signed-off-by: Nick Desaulniers
Please disregard this patch. I think I may have found a bug in Clang,
or at least an incompatibility with GCC 7.1.
Clang bug: https://bugs.llvm.org/show_bug.cgi?id=32985
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedeskto
ah seems like there's more of these:
drivers/gpu/drm/drm_mm.c:922
surprised compiling drivers/gpu/drm/drm_mm.o did not catch this the
first time...
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo
.
Signed-off-by: Nick Desaulniers
---
I verified that -Wall was redundant by compiling with V=1:
make V=1 -j4 drivers/gpu/drm/i915/i915_gem_request.o
drivers/gpu/drm/i915/gvt/Makefile | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/gvt/Makefile
b/drivers/gpu/drm
eclaration]
static int wait_for_engine(struct intel_engine_cs *engine, int
timeout_ms)
^
Signed-off-by: Nick Desaulniers
---
Additionally, it only has one call site. Should I mark it inline, too, while
I'm at it?
drivers/gpu/drm/i915/i915_gem.c | 3 ++-
1 file changed, 2 i
ping for review
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
1 - 100 of 260 matches
Mail list logo
