With no callers left of prandom_u32() and prandom_bytes(), as well as
get_random_int(), remove these deprecated wrappers, in favor of
get_random_u32() and get_random_bytes().
Reviewed-by: Kees Cook
Signed-off-by: Jason A. Donenfeld
---
drivers/char/random.c | 11 +--
The prandom_bytes() function has been a deprecated inline wrapper around
get_random_bytes() for several releases now, and compiles down to the
exact same code. Replace the deprecated wrapper with a direct call to
the real function. This was done as a basic find and replace.
Reviewed-by: Kees Cook
The prandom_u32() function has been a deprecated inline wrapper around
get_random_u32() for several releases now, and compiles down to the
exact same code. Replace the deprecated wrapper with a direct call to
the real function. The same also applies to get_random_int(), which is
just a wrapper
Rather than truncate a 32-bit value to a 16-bit value or an 8-bit value,
simply use the get_random_{u8,u16}() functions, which are faster than
wasting the additional bytes from a 32-bit value. This was done by hand,
identifying all of the places where one of the random integer functions
was used
Rather than truncate a 32-bit value to a 16-bit value or an 8-bit value,
simply use the get_random_{u8,u16}() functions, which are faster than
wasting the additional bytes from a 32-bit value. This was done
mechanically with this coccinelle script:
@@
expression E;
identifier get_random_u32 =~
Rather than incurring a division or requesting too many random bytes for
the given range, use the prandom_u32_max() function, which only takes
the minimum required bytes from the RNG and avoids divisions. This was
done by hand, covering things that coccinelle could not do on its own.
Reviewed-by:
Rather than incurring a division or requesting too many random bytes for
the given range, use the prandom_u32_max() function, which only takes
the minimum required bytes from the RNG and avoids divisions. This was
done mechanically with this coccinelle script:
@basic@
expression E;
type T;
Changes v4->v5:
- Coccinelle is now used for as much mechanical aspects as possible,
with mechanical parts split off from non-mechanical parts. This should
drastically reduce the amount of code that needs to be reviewed
carefully. Each commit mentions now if it was done by hand or is
[resending because I failed to CC]
On October 7, 2022 7:21:28 PM PDT, "Jason A. Donenfeld" wrote:
>On Fri, Oct 07, 2022 at 03:47:44PM -0700, Kees Cook wrote:
>> On Fri, Oct 07, 2022 at 12:01:03PM -0600, Jason A. Donenfeld wrote:
>> > Rather than incurring a division or requesting too many random
On Fri, Oct 07, 2022 at 03:47:44PM -0700, Kees Cook wrote:
> > diff --git a/lib/test_vmalloc.c b/lib/test_vmalloc.c
> > index 4f2f2d1bac56..56ffaa8dd3f6 100644
> > --- a/lib/test_vmalloc.c
> > +++ b/lib/test_vmalloc.c
> > @@ -151,9 +151,7 @@ static int random_size_alloc_test(void)
> > int i;
>
On Fri, Oct 07, 2022 at 03:47:44PM -0700, Kees Cook wrote:
> On Fri, Oct 07, 2022 at 12:01:03PM -0600, Jason A. Donenfeld wrote:
> > Rather than incurring a division or requesting too many random bytes for
> > the given range, use the prandom_u32_max() function, which only takes
> > the minimum
On Fri, Oct 07, 2022 at 10:34:47PM +0200, Rolf Eike Beer wrote:
> > diff --git a/arch/parisc/kernel/process.c b/arch/parisc/kernel/process.c
> > index 7c37e09c92da..18c4f0e3e906 100644
> > --- a/arch/parisc/kernel/process.c
> > +++ b/arch/parisc/kernel/process.c
> > @@ -288,7 +288,7 @@
On Fri, Oct 07, 2022 at 02:17:22PM -0700, Darrick J. Wong wrote:
> On Fri, Oct 07, 2022 at 12:01:03PM -0600, Jason A. Donenfeld wrote:
> > Rather than incurring a division or requesting too many random bytes for
> > the given range, use the prandom_u32_max() function, which only takes
> > the
Hi,
On 07.10.2022 14:14, Nia Espera wrote:
+
+#define dsi_dcs_write_seq(dsi, seq...) do {\
+ static const u8 d[] = { seq }; \
+ int ret;\
+ ret =
On Fri, Oct 07, 2022 at 12:01:03PM -0600, Jason A. Donenfeld wrote:
> Rather than incurring a division or requesting too many random bytes for
> the given range, use the prandom_u32_max() function, which only takes
> the minimum required bytes from the RNG and avoids divisions.
I actually meant
https://bugzilla.kernel.org/show_bug.cgi?id=205089
laurentc92...@gmail.com changed:
What|Removed |Added
CC||laurentc92...@gmail.com
---
On Fri, Oct 07, 2022 at 12:01:05PM -0600, Jason A. Donenfeld wrote:
> The prandom_u32() function has been a deprecated inline wrapper around
> get_random_u32() for several releases now, and compiles down to the
> exact same code. Replace the deprecated wrapper with a direct call to
> the real
On Fri, Oct 07, 2022 at 12:01:03PM -0600, Jason A. Donenfeld wrote:
> Rather than incurring a division or requesting too many random bytes for
> the given range, use the prandom_u32_max() function, which only takes
> the minimum required bytes from the RNG and avoids divisions.
>
> Reviewed-by:
On Fri, Oct 07, 2022 at 12:01:02PM -0600, Jason A. Donenfeld wrote:
> Rather than incurring a division or requesting too many random bytes for
> the given range, use the prandom_u32_max() function, which only takes
> the minimum required bytes from the RNG and avoids divisions. This was
> done
Hi dri-devel,
what is the difference between GTT and GART for AMD GPUs?
From what I gathered when looking through the mailing list archives and
the freedesktop docs [1] as well as wikipedia [2],
these terms seem to be synonymous, but that can not be the whole truth
(different sizes in dmesg
> diff --git a/arch/parisc/kernel/process.c b/arch/parisc/kernel/process.c
> index 7c37e09c92da..18c4f0e3e906 100644
> --- a/arch/parisc/kernel/process.c
> +++ b/arch/parisc/kernel/process.c
> @@ -288,7 +288,7 @@ __get_wchan(struct task_struct *p)
>
> static inline unsigned long brk_rnd(void)
>
There is a spelling mistake in a Kconfig description. Fix it.
Signed-off-by: Colin Ian King
---
drivers/gpu/drm/msm/Kconfig | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/msm/Kconfig b/drivers/gpu/drm/msm/Kconfig
index 4e0cbd682725..3c9dfdb0b328 100644
---
The assignment to variable taken is redundant and so it can be
removed as well as the variable too.
Cleans up clang-scan build warnings:
warning: Although the value stored to 'taken' is used in the enclosing
expression, the value is never actually read from 'taken'
[deadcode.DeadStores]
tree/branch:
https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git master
branch HEAD: 082fce125e57cff60687181c97f3a8ee620c38f5 Add linux-next specific
files for 20221007
Error/Warning reports:
https://lore.kernel.org/linux-doc/202209201326.sy9kholm-...@intel.com
https
The variable ret is being assigned with a value that is never read
both before and after a while-loop. The variable is being re-assigned
inside the while-loop and afterwards on the call to the function
i915_gem_object_lock_interruptible. Remove the redundants assignments.
Cleans up clang
With no callers left of prandom_u32() and prandom_bytes(), as well as
get_random_int(), remove these deprecated wrappers, in favor of
get_random_u32() and get_random_bytes().
Reviewed-by: Kees Cook
Signed-off-by: Jason A. Donenfeld
---
drivers/char/random.c | 11 +--
The prandom_bytes() function has been a deprecated inline wrapper around
get_random_bytes() for several releases now, and compiles down to the
exact same code. Replace the deprecated wrapper with a direct call to
the real function.
Reviewed-by: Kees Cook
Reviewed-by: Christophe Leroy # powerpc
The prandom_u32() function has been a deprecated inline wrapper around
get_random_u32() for several releases now, and compiles down to the
exact same code. Replace the deprecated wrapper with a direct call to
the real function. The same also applies to get_random_int(), which is
just a wrapper
Rather than truncate a 32-bit value to a 16-bit value or an 8-bit value,
simply use the get_random_{u8,u16}() functions, which are faster than
wasting the additional bytes from a 32-bit value.
Reviewed-by: Kees Cook
Acked-by: Toke Høiland-Jørgensen # for sch_cake
Signed-off-by: Jason A.
Rather than incurring a division or requesting too many random bytes for
the given range, use the prandom_u32_max() function, which only takes
the minimum required bytes from the RNG and avoids divisions.
Reviewed-by: Kees Cook
Reviewed-by: KP Singh
Reviewed-by: Christoph Böhmwalder # for drbd
Rather than incurring a division or requesting too many random bytes for
the given range, use the prandom_u32_max() function, which only takes
the minimum required bytes from the RNG and avoids divisions. This was
done mechanically with these coccinelle scripts:
@no_modulo@
expression E;
Changes v3->v4:
- Split coccinelle mechanical step from non-mechanical step.
- Handle `get_random_int() & ~PAGE_MASK` -> `prandom_u32_max(PAGE_SIZE)`.
Hi folks,
This is a five part treewide cleanup of random integer handling. The
rules for random integers are:
- If you want a secure or an
On Fri, Oct 07, 2022 at 10:12:42AM -0700, Kees Cook wrote:
> On Fri, Oct 07, 2022 at 08:07:58AM -0600, Jason A. Donenfeld wrote:
> > On Fri, Oct 07, 2022 at 04:57:24AM +, Christophe Leroy wrote:
> > >
> > >
> > > Le 07/10/2022 à 01:36, Jason A. Donenfeld a écrit :
> > > > On 10/6/22,
On Fri, Oct 07, 2022 at 08:07:58AM -0600, Jason A. Donenfeld wrote:
> On Fri, Oct 07, 2022 at 04:57:24AM +, Christophe Leroy wrote:
> >
> >
> > Le 07/10/2022 à 01:36, Jason A. Donenfeld a écrit :
> > > On 10/6/22, Christophe Leroy wrote:
> > >>
> > >>
> > >> Le 06/10/2022 à 19:31,
On Thu, Oct 06, 2022 at 06:11:37PM +0300, Ville Syrjälä wrote:
> On Thu, Oct 06, 2022 at 11:33:14AM +0200, Simon Rettberg wrote:
> > Current dual mode adaptor ("DP++") detection code assumes that all
> > adaptors support i2c sub-addressing for read operations from the
> > DP-HDMI adaptor ID
The pull request you sent on Fri, 7 Oct 2022 13:03:25 +1000:
> git://anongit.freedesktop.org/drm/drm tags/drm-next-2022-10-07-1
has been merged into torvalds/linux.git:
https://git.kernel.org/torvalds/c/9d84bb40bcb30a7fa16f33baa967aeb9953dda78
Thank you!
--
Deet-doot-dot, I am a bot.
On 9/28/22 8:09 PM, Linus Torvalds wrote:
On Wed, Sep 28, 2022 at 1:15 AM Gwan-gyeong Mun
wrote:
+ if (check_assign(obj->base.size >> PAGE_SHIFT, ))
+ return -E2BIG;
I have to say, I find that new "check_assign()" macro use to be disgusting.
It's one thing to check
Linus and Kees, I also understood that I should not make and use the
macro that performs assignment and checking at the same time, and I will
drop it and update it.
Kees, the overflows_type() macro had several updates as input from you
and the community, and there is an advantage when moving
On 9/28/22 11:51 AM, Jani Nikula wrote:
On Wed, 28 Sep 2022, Gwan-gyeong Mun wrote:
diff --git a/drivers/gpu/drm/i915/i915_scatterlist.h
b/drivers/gpu/drm/i915/i915_scatterlist.h
index 9ddb3e743a3e..1d1802beb42b 100644
--- a/drivers/gpu/drm/i915/i915_scatterlist.h
+++
>-Original Message-
>From: Dmitry Baryshkov
>Sent: Tuesday, October 4, 2022 8:03 PM
>To: Kalyan Thota (QUIC)
>Cc: dri-devel@lists.freedesktop.org; linux-arm-...@vger.kernel.org;
>freedr...@lists.freedesktop.org; devicet...@vger.kernel.org; linux-
>ker...@vger.kernel.org;
On Fri, Oct 07, 2022 at 04:57:24AM +, Christophe Leroy wrote:
>
>
> Le 07/10/2022 à 01:36, Jason A. Donenfeld a écrit :
> > On 10/6/22, Christophe Leroy wrote:
> >>
> >>
> >> Le 06/10/2022 à 19:31, Christophe Leroy a écrit :
> >>>
> >>>
> >>> Le 06/10/2022 à 19:24, Jason A. Donenfeld a
On Fri, 07 Oct 2022 14:49:42 +0200, Thierry Reding wrote:
> From: Thierry Reding
>
> Document the "framebuffer" compatible string for reserved memory nodes
> to annotate reserved memory regions used for framebuffer carveouts.
>
> Signed-off-by: Thierry Reding
> ---
> Changes in v2:
> - use
On Fri, 07 Oct 2022 14:49:41 +0200, Thierry Reding wrote:
> From: Thierry Reding
>
> This is a variant of the 32-bit RGB format where the red and blue
> components are swapped.
>
> Signed-off-by: Thierry Reding
> ---
> .../devicetree/bindings/display/simple-framebuffer.yaml | 2 ++
>
On Fri, 07 Oct 2022 14:49:40 +0200, Thierry Reding wrote:
> From: Thierry Reding
>
> In order to support framebuffers residing in system memory, allow the
> memory-region property to override the framebuffer memory specification
> in the "reg" property.
>
> Signed-off-by: Thierry Reding
> ---
On Thu, 6 Oct 2022 at 17:07, Abhinav Kumar wrote:
>
> Hi Robert
>
> Thanks for the review.
>
> On 10/4/2022 8:55 AM, Robert Foss wrote:
> > On Mon, 29 Aug 2022 at 20:23, Abhinav Kumar
> > wrote:
> >>
> >> adv7533 bridge tries to dynamically switch lanes based on the
> >> mode by detaching and
Hi Jagan
On Thu, 6 Oct 2022 at 15:25, Jagan Teki wrote:
>
> On Fri, Mar 4, 2022 at 8:48 PM Dave Stevenson
> wrote:
> >
> > Mapping to the drm_bridge flag pre_enable_upstream_first,
> > add a new flag prepare_upstream_first to drm_panel to allow
> > the panel driver to request that the upstream
From: Thierry Reding
Add the framebuffer carveout reserved memory node as well as a simple-
framebuffer node that is used to bind to the framebuffer that the
bootloader has set up.
Signed-off-by: Thierry Reding
---
Changes in v2:
- clear out dynamic fields and leave it up to firmware to fill
From: Thierry Reding
This is a variant of the 32-bit RGB format where the red and blue
components are swapped.
Signed-off-by: Thierry Reding
---
.../devicetree/bindings/display/simple-framebuffer.yaml | 2 ++
1 file changed, 2 insertions(+)
diff --git
From: Thierry Reding
Add XB24 and AB24 to the list of supported formats. The format helpers
support conversion to these formats and they are documented in the
simple-framebuffer device tree bindings.
v2: treat AB24 as XB24 and support both at the same time
Signed-off-by: Thierry Reding
---
From: Thierry Reding
Add a conversion helper for the XB24 format to use in drm_fb_blit().
v2: support XB24 format instead of AB24
Signed-off-by: Thierry Reding
---
drivers/gpu/drm/drm_format_helper.c | 37 +
1 file changed, 37 insertions(+)
diff --git
From: Thierry Reding
Simple framebuffers can be set up in system memory, which cannot be
requested and/or I/O remapped using the I/O resource helpers. Add a
separate code path that obtains system memory framebuffers from the
reserved memory region referenced in the memory-region property.
v2:
From: Thierry Reding
Document the "framebuffer" compatible string for reserved memory nodes
to annotate reserved memory regions used for framebuffer carveouts.
Signed-off-by: Thierry Reding
---
Changes in v2:
- use four spaces for indentation in example (as recommended elsewhere)
- add
From: Thierry Reding
In order to support framebuffers residing in system memory, allow the
memory-region property to override the framebuffer memory specification
in the "reg" property.
Signed-off-by: Thierry Reding
---
.../devicetree/bindings/display/simple-framebuffer.yaml | 5 +
1
From: Thierry Reding
Hi,
this series of patches adds support for framebuffers residing in system
memory to the simple-framebuffer DRM driver. To do this, the DT bindings
are extended do accept the memory-region property in addition to the reg
property for specifying the framebuffer memory. This
In drm_atomic_helper_check_crtc_state(), do not add a new plane state
to the global state if it does not exist already. Adding a new plane
state will result in overhead for the plane during the atomic-commit
step.
For the test in drm_atomic_helper_check_crtc_state() to succeed, it
is important
Rename the atomic helper function drm_atomic_helper_check_crtc_state()
to drm_atomic_helper_check_crtc_primary_plane() and only check for an
attached primary plane. Adapt callers.
Instead of having one big function to check for various CRTC state
conditions, we rather want smaller functions that
Fix the test for the CRTC's primary plane and clean up the test function
to only do the test.
v5:
* fix commit message of patch 1 (Javier)
* rebase onto latest drm-tip
v4:
* clean up the helper function (Ville)
Thomas Zimmermann (2):
drm/atomic-helper: Don't allocate
Hi Nia,
On Fri, Oct 7, 2022 at 8:16 AM Nia Espera wrote:
> +static int samsung_s6e3fc2x01_prepare(struct drm_panel *panel)
> +{
> + struct samsung_s6e3fc2x01 *ctx = to_samsung_s6e3fc2x01(panel);
> + struct device *dev = >dsi->dev;
> + int ret;
> +
> + if (ctx->prepared)
Removes functionality from sofef00 panel driver which allowed it to
drive the s6e3fc2x01 panel
Signed-off-by: Nia Espera
Reviewed-by: Caleb Connolly
---
drivers/gpu/drm/panel/Kconfig | 6 +++---
drivers/gpu/drm/panel/panel-samsung-sofef00.c | 18 --
2 files
Adds a dedicated driver for the Samsung s6e3fc2x01 panel used in OnePlus
6T smartphones which was previously driven by the sofef00 panel driver
Signed-off-by: Nia Espera
Reviewed-by: Caleb Connolly
---
MAINTAINERS | 5 +
drivers/gpu/drm/panel/Kconfig
This patch series adds proper support for the panel used in OnePlus 6T
smartphones (s6e3fc2x01). Previously, the panel relied on the driver
used by the sofef00 panel which failed to properly initialise it after
a reset.
Nia Espera (2):
drivers: gpu: drm: add driver for samsung s6e3fc2x01 cmd
Forgot to add Andrey as scheduler maintainer.
-Daniel
On Fri, 7 Oct 2022 at 10:16, Daniel Vetter wrote:
>
> On Fri, 7 Oct 2022 at 01:45, Linus Torvalds
> wrote:
> >
> > On Thu, Oct 6, 2022 at 1:25 PM Dave Airlie wrote:
> > >
> > >
> > > [ 1234.778760] BUG: kernel NULL pointer dereference,
On Thu, Oct 06, 2022 at 10:53:44AM -0600, Jason A. Donenfeld wrote:
> drivers/thunderbolt/xdomain.c | 2 +-
Acked-by: Mika Westerberg
From: Christophe Leroy
> Sent: 06 October 2022 18:43
...
> But taking into account that sp must remain 16 bytes aligned, would it
> be better to do something like ?
>
> sp -= prandom_u32_max(PAGE_SIZE >> 4) << 4;
That makes me think...
If prandom_u32_max() is passed a (constant) power of 2
On Thu, 6 Oct 2022 12:03:56 +
"Hoosier, Matt" wrote:
> I have a DRM master implementing a purpose-built compositor for a
> dedicated use-case. It drives several different connectors, each on
> its own vsync cadence (there's no clone mode happening here).
>
> The goal is to have commits to
On Thu, 6 Oct 2022 at 18:54, Jason A. Donenfeld wrote:
>
> Changes v2->v3:
> - Handle get_random_int() conversions too, which were overlooked before,
> in the same way as the rest.
>
> Hi folks,
>
> This is a five part treewide cleanup of random integer handling. The
> rules for random integers
On 06/10/2022 22:38, john.c.harri...@intel.com wrote:
From: John Harrison
Compute workloads are inherently not pre-emptible for long periods on
current hardware. As a workaround for this, the pre-emption timeout
for compute capable engines was disabled. This is undesirable with GuC
On Fri, Oct 07, 2022 at 09:58:31AM +0200, Thomas Zimmermann wrote:
> Hi
>
> Am 07.10.22 um 09:15 schrieb Ville Syrjälä:
>
> >>
> >> For the absolute size of fbdev memory, I think we should introduce a
> >> module parameter in drm_fb_helper, which an option to set a default
> >> value in the
On Fri, 7 Oct 2022 at 01:45, Linus Torvalds
wrote:
>
> On Thu, Oct 6, 2022 at 1:25 PM Dave Airlie wrote:
> >
> >
> > [ 1234.778760] BUG: kernel NULL pointer dereference, address:
> > 0088
> > [ 1234.778813] RIP: 0010:drm_sched_job_done.isra.0+0xc/0x140 [gpu_sched]
>
> As far as I
Hi
Am 07.10.22 um 09:29 schrieb Ville Syrjälä:
On Fri, Oct 07, 2022 at 09:17:50AM +0200, Javier Martinez Canillas wrote:
On 10/7/22 09:07, Ville Syrjälä wrote:
On Thu, Oct 06, 2022 at 10:28:12PM +0200, Javier Martinez Canillas wrote:
On 10/5/22 13:40, Thomas Zimmermann wrote:
Rename the
Hi
Am 07.10.22 um 09:15 schrieb Ville Syrjälä:
For the absolute size of fbdev memory, I think we should introduce a
module parameter in drm_fb_helper, which an option to set a default
value in the kernel config. It would benefit all drivers that use fbdev
emulation and work how overalloc
On 10/7/22 09:29, Ville Syrjälä wrote:
[...]
>> drm_for_each_plane_mask(plane, dev, crtc_state->plane_mask)
>> if (plane->type == DRM_PLANE_TYPE_PRIMARY)
>> return 0;
>
> That is exactly what it says not to do.
>
Ah, good to know. I re-read the kernel
On Fri, Oct 07, 2022 at 09:17:50AM +0200, Javier Martinez Canillas wrote:
> On 10/7/22 09:07, Ville Syrjälä wrote:
> > On Thu, Oct 06, 2022 at 10:28:12PM +0200, Javier Martinez Canillas wrote:
> >> On 10/5/22 13:40, Thomas Zimmermann wrote:
> >>> Rename the atomic helper function
On 10/7/22 09:07, Ville Syrjälä wrote:
> On Thu, Oct 06, 2022 at 10:28:12PM +0200, Javier Martinez Canillas wrote:
>> On 10/5/22 13:40, Thomas Zimmermann wrote:
>>> Rename the atomic helper function drm_atomic_helper_check_crtc_state()
>>> to drm_atomic_helper_check_crtc_primary_plane() and only
On Fri, Oct 07, 2022 at 09:10:27AM +0200, Thomas Zimmermann wrote:
> Hi
>
> Am 07.10.22 um 04:16 schrieb Zack Rusin:
> > On Thu, 2022-10-06 at 10:01 +0200, Thomas Zimmermann wrote:
> >> Hi Zack
> >>
> >> Am 05.10.22 um 21:49 schrieb Zack Rusin:
> >>> Hi, Thomas.
> >>>
> >>> Because you've been
Hi
Am 07.10.22 um 04:16 schrieb Zack Rusin:
On Thu, 2022-10-06 at 10:01 +0200, Thomas Zimmermann wrote:
Hi Zack
Am 05.10.22 um 21:49 schrieb Zack Rusin:
Hi, Thomas.
Because you've been the one who's been working on drm_fb_helper.c the most the
last
few years I wanted to pick your brain a
On Thu, Oct 06, 2022 at 10:28:12PM +0200, Javier Martinez Canillas wrote:
> On 10/5/22 13:40, Thomas Zimmermann wrote:
> > Rename the atomic helper function drm_atomic_helper_check_crtc_state()
> > to drm_atomic_helper_check_crtc_primary_plane() and only check for an
> > attached primary plane.
On 07/10/2022 05:18, allen.c...@ite.com.tw wrote:
> hi
>
> -Original Message-
> From: Krzysztof Kozlowski
> Sent: Thursday, October 6, 2022 4:17 PM
> To: Allen Chen (陳柏宇)
> Cc: Jau-Chih Tseng (曾昭智) ; Kenneth Hung (洪家倫)
> ; Hermes Wu (吳佳宏) ; Pin-yen
> Lin ; Andrzej Hajda ; Neil
>
Hi
Am 06.10.22 um 22:18 schrieb Javier Martinez Canillas:
Hello Thomas,
On 10/5/22 13:40, Thomas Zimmermann wrote:
In drm_atomic_helper_check_crtc_state(), do not add a new plane state
to the global state if it does not exist already. Adding a new plane
state will result in overhead for the
Am 07.10.22 um 04:45 schrieb Dave Airlie:
On Fri, 7 Oct 2022 at 09:45, Linus Torvalds
wrote:
On Thu, Oct 6, 2022 at 1:25 PM Dave Airlie wrote:
[ 1234.778760] BUG: kernel NULL pointer dereference, address: 0088
[ 1234.778813] RIP: 0010:drm_sched_job_done.isra.0+0xc/0x140
80 matches
Mail list logo
