Hello dri maintainers/developers,
This is a 31-day syzbot report for the dri subsystem.
All related reports/information can be found at:
https://syzkaller.appspot.com/upstream/s/dri
During the period, 2 new issues were detected and 0 were fixed.
In total, 21 issues are still open and 31 have been
On 3/5/2024 4:33 PM, Paneer Selvam, Arunpravin wrote:
Hi Christian,
On 3/4/2024 10:09 PM, Christian König wrote:
Am 04.03.24 um 17:32 schrieb Arunpravin Paneer Selvam:
Add amdgpu driver as user for the drm buddy
defragmentation.
Signed-off-by: Arunpravin Paneer Selvam
---
drivers/gpu/
On Wed, 28 Feb 2024 14:12:06 -0600, Andrew Halaney wrote:
> This gets logged out to /sys/kernel/debug/devices_deferred in the
> -EPROBE_DEFER case and as an error otherwise. The message here provides
> useful information to the user when troubleshooting why their display is
> not working in either
On Tue, 5 Mar 2024 11:07:34 +0200, Jani Nikula wrote:
> Resend of [1] with an intent to merge after the CI results come in. This
> is aiming for v6.10, so we'll have maximal time to find all the issues
> my configs didn't catch.
>
> I built this on x86-64 (both gcc and clang), arm and arm64, and
>
/video/fbdev/core/fbmem.c | 17 ++--
drivers/video/fbdev/core/fbsysfs.c | 4 +--
9 files changed, 60 insertions(+), 63 deletions(-)
---
base-commit: 4a0e7b3c37531aabddf6f144b83ae9b65ec809fd
change-id: 20240305-class_cleanup-drm-591ca73b31f2
Best regards,
--
Ricardo B
Since commit 43a7206b0963 ("driver core: class: make class_register() take
a const *"), the driver core allows for struct class to be in read-only
memory, so move the drm_dp_aux_dev_class structure to be declared at build
time placing it into read-only memory, instead of having to be dynamically
al
Since commit 43a7206b0963 ("driver core: class: make class_register() take
a const *"), the driver core allows for struct class to be in read-only
memory, so move the drm_class structure to be declared at build time
placing it into read-only memory, instead of having to be dynamically
allocated at
Since commit 43a7206b0963 ("driver core: class: make class_register() take
a const *"), the driver core allows for struct class to be in read-only
memory, so move the fb_class structure to be declared at build time placing
it into read-only memory, instead of having to be dynamically allocated at
b
Since commit 43a7206b0963 ("driver core: class: make class_register() take
a const *"), the driver core allows for struct class to be in read-only
memory, so move the dma_heap_class structure to be declared at build time
placing it into read-only memory, instead of having to be dynamically
allocate
On Mon, 4 Mar 2024 18:45:08 +0100
Sebastian Wick wrote:
> The initial idea of the Colorspace prop was that this maps 1:1 to
> InfoFrames/SDP but KMS does not give user space enough information nor
> control over the output format to figure out which variants can be used
> for a given KMS commit.
On Fri, Dec 8, 2023, at 01:52, Mina Almasry wrote:
> +static void *gve_rx_queue_mem_alloc(struct net_device *dev, int idx)
> +{
> + struct gve_per_rx_queue_mem_dqo *gve_q_mem;
...
> +
> + gve_q_mem = kvcalloc(1, sizeof(*gve_q_mem), GFP_KERNEL);
> + if (!gve_q_mem)
> + goto e
Hi Adam,
Sorry for not responding sooner. I've recently just returned from paternity
leave, so just catching up on everything.
On Thu, 2024-02-15 at 11:22 -0600, Adam Ford wrote:
> On Thu, Feb 15, 2024 at 11:10 AM Adam Ford wrote:
> > On Thu, Feb 15, 2024 at 10:54 AM Geert Uytterhoeven
> > wrot
On 2024-02-29 21:21, Linus Torvalds wrote:
> On Thu, 29 Feb 2024 at 01:23, Nikolai Kondrashov wrote:
>>
>> However, I think a better approach would be *not* to add the .gitlab-ci.yaml
>> file in the root of the source tree, but instead change the very same repo
>> setting to point to a particular
Add ring timeout related information in the amdgpu
devcoredump file for debugging purposes.
During the gpu recovery process the registered call
is triggered and add the debug information in data
file created by devcoredump framework under the
directory /sys/class/devcoredump/devcdx/
Signed-off-by
Am 05.03.24 um 12:14 schrieb Paneer Selvam, Arunpravin:
On 3/5/2024 4:33 PM, Paneer Selvam, Arunpravin wrote:
Hi Christian,
On 3/4/2024 10:09 PM, Christian König wrote:
Am 04.03.24 um 17:32 schrieb Arunpravin Paneer Selvam:
Add amdgpu driver as user for the drm buddy
defragmentation.
Signed-
destroy(&kfd_class, MKDEV(kfd_char_dev_major, 0));
+ class_unregister(&kfd_class);
unregister_chrdev(kfd_char_dev_major, kfd_dev_name);
kfd_device = NULL;
}
---
base-commit: 8bc75586ea01f1c645063d3472c115ecab03e76c
change-id: 20240305-class_cleanup-drm-amd-bdc7255b7540
Best regards,
--
Ricardo B. Marliere
(-)
---
base-commit: cd1995b6ac7384149ad755b74e3c3eb25195ab81
change-id: 20240305-class_cleanup-backlight-62b91c38005e
Best regards,
--
Ricardo B. Marliere
Since commit 43a7206b0963 ("driver core: class: make class_register() take
a const *"), the driver core allows for struct class to be in read-only
memory, so move the backlight_class structure to be declared at build time
placing it into read-only memory, instead of having to be dynamically
allocat
Since commit 43a7206b0963 ("driver core: class: make class_register() take
a const *"), the driver core allows for struct class to be in read-only
memory, so move the lcd_class structure to be declared at build time
placing it into read-only memory, instead of having to be dynamically
allocated at
7625_sink_detect(ctx);
+ status = anx7625_sink_detect(ctx);
+ anx7625_audio_update_connector_status(ctx, status);
+ return status;
}
static struct edid *anx7625_bridge_get_edid(struct drm_bridge *bridge,
---
base-commit: 90d35da658da8cff0d4ecbb5113f5fac9d00eb72
change-id: 20240305-anx762
Am 05.03.24 um 12:58 schrieb Sunil Khatri:
Add ring timeout related information in the amdgpu
devcoredump file for debugging purposes.
During the gpu recovery process the registered call
is triggered and add the debug information in data
file created by devcoredump framework under the
directory
On Mon, 04 Mar 2024 14:14:52 +0200 Jani Nikula wrote:
> >> The kcalloc() in nouveau_dmem_evict_chunk() will return null if
> >> the physical memory has run out. As a result, if we dereference
> >> src_pfns, dst_pfns or dma_addrs, the null pointer dereference bugs
> >> will happen.
> >>
> >> This pa
On 2024/3/5 10:01, Mina Almasry wrote:
...
>
> Perf - page-pool benchmark:
> ---
>
> bench_page_pool_simple.ko tests with and without these changes:
> https://pastebin.com/raw/ncHDwAbn
>
> AFAIK the number that really matters in the perf tests is the
> 'tasklet_page_poo
On 2024/3/5 10:01, Mina Almasry wrote:
> The check is duplicated in 2 places, factor it out into a common helper.
Reviewed-by: Yunsheng Lin
On 2024/3/5 10:01, Mina Almasry wrote:
...
>
> The netdev_dmabuf_binding struct is refcounted, and releases its
> resources only when all the refs are released.
>
> Signed-off-by: Willem de Bruijn
> Signed-off-by: Kaiyuan Zhang
> Signed-off-by: Mina Almasry
>
> ---
>
> RFC v6:
> - Validate
On 3/5/2024 6:40 PM, Christian König wrote:
Am 05.03.24 um 12:58 schrieb Sunil Khatri:
Add ring timeout related information in the amdgpu
devcoredump file for debugging purposes.
During the gpu recovery process the registered call
is triggered and add the debug information in data
file create
Am 05.03.24 um 14:17 schrieb Khatri, Sunil:
On 3/5/2024 6:40 PM, Christian König wrote:
Am 05.03.24 um 12:58 schrieb Sunil Khatri:
Add ring timeout related information in the amdgpu
devcoredump file for debugging purposes.
During the gpu recovery process the registered call
is triggered and a
On Tue, 05 Mar 2024, duom...@zju.edu.cn wrote:
> On Mon, 04 Mar 2024 14:14:52 +0200 Jani Nikula wrote:
>> >> The kcalloc() in nouveau_dmem_evict_chunk() will return null if
>> >> the physical memory has run out. As a result, if we dereference
>> >> src_pfns, dst_pfns or dma_addrs, the null pointer
On Tue, Mar 05, 2024 at 11:46:00AM +0100, Julien Panis wrote:
> On 3/1/24 17:38, Andrew Lunn wrote:
> > On Fri, Mar 01, 2024 at 04:02:53PM +0100, Julien Panis wrote:
> > > This patch adds XDP (eXpress Data Path) support to TI AM65 CPSW
> > > Ethernet driver. The following features are implemented:
On Tue, Mar 05, 2024 at 06:55:02AM +0100, Javier Carrasco wrote:
> The current implementation uses generic names for the power supplies,
> which conflicts with proper name definitions in the device bindings.
>
> Add a per-device property to include real supply names and keep generic
> names for ex
If VM_BIND is enabled on the client the legacy submission ioctl can't be
used, however if a client tries to do so regardless it will return an
error. In this case the clients mutex remained unlocked leading to a
deadlock inside nouveau_drm_postclose or any other nouveau ioctl call.
Fixes: b88baab8
Those are already de-facto UAPI, so let's just move it into the uapi
header.
Signed-off-by: Karol Herbst
Reviewed-by: Lyude Paul
Reviewed-by: Danilo Krummrich
Link:
https://patchwork.freedesktop.org/patch/msgid/20240304183157.1587152-2-kher...@redhat.com
---
drivers/gpu/drm/nouveau/nouveau_ab
On 05.03.24 14:34, Greg Kroah-Hartman wrote:
> On Tue, Mar 05, 2024 at 06:55:02AM +0100, Javier Carrasco wrote:
>> The current implementation uses generic names for the power supplies,
>> which conflicts with proper name definitions in the device bindings.
>>
>> Add a per-device property to include
Hi Duoming,
On 3/3/24 08:53, Duoming Zhou wrote:
The kcalloc() in nouveau_dmem_evict_chunk() will return null if
the physical memory has run out. As a result, if we dereference
src_pfns, dst_pfns or dma_addrs, the null pointer dereference bugs
will happen.
This patch uses stack variables to rep
On Tue, Mar 5, 2024 at 5:58 AM Frank Binns wrote:
>
> Hi Adam,
>
> Sorry for not responding sooner. I've recently just returned from paternity
> leave, so just catching up on everything.
Congratulations!
>
> On Thu, 2024-02-15 at 11:22 -0600, Adam Ford wrote:
> > On Thu, Feb 15, 2024 at 11:10 AM
The initial idea of the Colorspace prop was that this maps 1:1 to
InfoFrames/SDP but KMS does not give user space enough information nor
control over the output format to figure out which variants can be used
for a given KMS commit. At the same time, properties like Broadcast RGB
expect full range
Add ring timeout related information in the amdgpu
devcoredump file for debugging purposes.
During the gpu recovery process the registered call
is triggered and add the debug information in data
file created by devcoredump framework under the
directory /sys/class/devcoredump/devcdx/
Signed-off-by
Am 05.03.24 um 14:57 schrieb Sunil Khatri:
Add ring timeout related information in the amdgpu
devcoredump file for debugging purposes.
During the gpu recovery process the registered call
is triggered and add the debug information in data
file created by devcoredump framework under the
directory
Object debugging tools were sporadically reporting illegal attempts to
free a still active i915 VMA object when parking a GT believed to be idle.
[161.359441] ODEBUG: free active (active state 0) object: 88811643b958
object type: i915_active hint: __i915_vma_active+0x0/0x50 [i915]
[161.360082
Object debugging tools were sporadically reporting illegal attempts to
free a still active i915 VMA object when parking a GT believed to be idle.
[161.359441] ODEBUG: free active (active state 0) object: 88811643b958
object type: i915_active hint: __i915_vma_active+0x0/0x50 [i915]
[161.360082
There was an attempt to fix an issue of illegal attempts to free a still
active i915 VMA object when parking a GT believed to be idle, reported by
CI on 2-GT Meteor Lake. As a solution, an extra wakeref for a Primary GT
was acquired from i915_gem_do_execbuffer() -- see commit f56fe3e91787
("drm/i9
This reverts commit 7a2280e8dcd2f1f436db9631287c0b21cf6a92b0, obsoleted
by "drm/i915/vma: Fix UAF on destroy against retire race".
Signed-off-by: Janusz Krzysztofik
Cc: Nirmoy Das
---
drivers/gpu/drm/i915/i915_vma.c | 2 --
1 file changed, 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_
The kcalloc() in nouveau_dmem_evict_chunk() will return null if
the physical memory has run out. As a result, if we dereference
src_pfns, dst_pfns or dma_addrs, the null pointer dereference bugs
will happen.
Moreover, the GPU is going away. If the kcalloc() fails, we could not
evict all pages mapp
On Thu, Feb 29, 2024 at 12:39 PM Frieder Schrempf
wrote:
>
> Hi,
>
> On 28.03.23 19:07, Jagan Teki wrote:
> > For a given bridge pipeline if any bridge sets pre_enable_prev_first
> > flag then the pre_enable for the previous bridge will be called before
> > pre_enable of this bridge and opposite i
On Tue, 05 Mar 2024, Lee Jones wrote:
> On Mon, 04 Mar 2024, Thomas Zimmermann wrote:
>
> > Backlight drivers implement struct backlight_ops.check_fb, which
> > uses struct fb_info in its interface. Replace the callback with one
> > that does not use fb_info.
> >
> > In DRM, we have several driv
On Tue, 28 Mar 2023 22:37:51 +0530, Jagan Teki wrote:
> For a given bridge pipeline if any bridge sets pre_enable_prev_first
> flag then the pre_enable for the previous bridge will be called before
> pre_enable of this bridge and opposite is done for post_disable.
>
> These are the potential bridg
On 3/5/2024 3:35 PM, Janusz Krzysztofik wrote:
This reverts commit 7a2280e8dcd2f1f436db9631287c0b21cf6a92b0, obsoleted
by "drm/i915/vma: Fix UAF on destroy against retire race".
Signed-off-by: Janusz Krzysztofik
Cc: Nirmoy Das
Reviewed-by: Nirmoy Das
---
drivers/gpu/drm/i915/i915_vma.c |
On 3/5/2024 3:35 PM, Janusz Krzysztofik wrote:
Object debugging tools were sporadically reporting illegal attempts to
free a still active i915 VMA object when parking a GT believed to be idle.
[161.359441] ODEBUG: free active (active state 0) object: 88811643b958
object type: i915_active h
On 3/5/2024 3:35 PM, Janusz Krzysztofik wrote:
There was an attempt to fix an issue of illegal attempts to free a still
active i915 VMA object when parking a GT believed to be idle, reported by
CI on 2-GT Meteor Lake. As a solution, an extra wakeref for a Primary GT
was acquired from i915_gem_d
Sorry to ask for this again, but this series has non-trivial merge
conflicts with upstream again.
Could you rebase it and send out an updated version?
Hi Robert
On Tue, Mar 5, 2024 at 3:54 PM Robert Foss wrote:
>
> On Tue, 28 Mar 2023 22:37:51 +0530, Jagan Teki wrote:
> > For a given bridge pipeline if any bridge sets pre_enable_prev_first
> > flag then the pre_enable for the previous bridge will be called before
> > pre_enable of this bridge a
Hi Alvin,
Thank you for the patch.
On Mon, Feb 19, 2024 at 09:12:58PM +0100, Alvin Šipraga wrote:
> From: Alvin Šipraga
>
> In preparation for calling EDID helpers from the hotplug work, move the
> hotplug work below the EDID helper section. No functional change.
>
> Reviewed-by: Robert Foss
Hello Alvin,
Thank you for the patch.
On Mon, Feb 19, 2024 at 09:12:59PM +0100, Alvin Šipraga wrote:
> From: Alvin Šipraga
>
> The adv7511 driver is solely responsible for setting the physical
> address of its CEC adapter. To do this, it must read the EDID. However,
> EDID is only read when eit
On 3/5/24 14:28, Andrew Lunn wrote:
On Tue, Mar 05, 2024 at 11:46:00AM +0100, Julien Panis wrote:
On 3/1/24 17:38, Andrew Lunn wrote:
On Fri, Mar 01, 2024 at 04:02:53PM +0100, Julien Panis wrote:
This patch adds XDP (eXpress Data Path) support to TI AM65 CPSW
Ethernet driver. The following fea
This patch-set is a prerequisite for a standalone TTM shrinker
and for exhaustive TTM eviction using sleeping dma_resv locks,
which is the motivation for it.
Currently when unlocking the TTM lru list lock, iteration needs
to be restarted from the beginning, rather from the next LRU list
node. This
To be able to handle list unlocking while traversing the LRU
list, we want the iterators not only to point to the next
position of the list traversal, but to insert themselves as
list nodes at that point to work around the fact that the
next node might otherwise disappear from the list while
the it
Have iterators insert themselves into the list they are iterating
over using hitch list nodes. Since only the iterator owner
can remove these list nodes from the list, it's safe to unlock
the list and when continuing, use them as a starting point. Due to
the way LRU bumping works in TTM, newly adde
To address the problem with hitches moving when bulk move
sublists are lru-bumped, register the list cursors with the
ttm_lru_bulk_move structure when traversing its list, and
when lru-bumping the list, move the cursor hitch to the tail.
This also means it's mandatory for drivers to call
ttm_lru_bu
The -ENOSPC failure from ttm_bo_swapout() meant that the lru_lock
was dropped and simply restarting the iteration meant we'd likely
hit the same error again on the same resource. Now that we can
restart the iteration even if the lock was dropped, do that.
Cc: Christian König
Cc: Somalapuram Amara
Am 05.03.24 um 15:53 schrieb Lee Jones:
On Tue, 05 Mar 2024, Lee Jones wrote:
On Mon, 04 Mar 2024, Thomas Zimmermann wrote:
Backlight drivers implement struct backlight_ops.check_fb, which
uses struct fb_info in its interface. Replace the callback with one
that does not use fb_info.
In DR
intel-mid.h is providing some core parts of the South Complex PM,
which are usually are not used by individual drivers. In particular,
this driver doesn't use it, so simply remove the unused header.
Signed-off-by: Andy Shevchenko
---
drivers/gpu/drm/gma500/oaktrail_lvds.c | 2 --
1 file changed,
On Tue, 05 Mar 2024, Robert Foss wrote:
> Sorry to ask for this again, but this series has non-trivial merge
> conflicts with upstream again.
>
> Could you rebase it and send out an updated version?
Not just rebase, but all of bridge has been switched over to struct
drm_edid based interfaces.
BR
On Fri, Mar 01, 2024 at 02:42:55PM +0100, Thomas Zimmermann wrote:
> Unregister all in-kernel clients before unloading the i915 driver. For
> other drivers, drm_dev_unregister() does this automatically. As i915
> does not use this helper, it has to perform the call by itself. For xe,
> do the same
On Mon, 19 Feb 2024, Alvin Šipraga wrote:
> From: Alvin Šipraga
>
> The adv7511 driver is solely responsible for setting the physical
> address of its CEC adapter. To do this, it must read the EDID. However,
> EDID is only read when either the drm_bridge_funcs :: get_edid or
> drm_connector_helpe
From: Guilherme G. Piccoli Sent: Monday, March 4, 2024
1:43 PM
>
> On 04/03/2024 18:12, John Ogness wrote:
> > [...]
> >> The second question is how to simulate a panic context in a
> >> non-destructive way, so we can test the panic notifiers in CI, without
> >> crashing the machine.
> >
> > I'm
Backlight drivers implement struct backlight_ops.check_fb, which
uses struct fb_info in its interface. Replace the callback with one
that does not use fb_info.
In DRM, we have several drivers that implement backlight support. By
including these drivers depend on .
At the same time, fbdev is depre
Framebuffer drivers for devices with dedicated backlight are supposed
to set struct fb_info.bl_dev to the backlight's respective device. Use
the value to match backlight and framebuffer in the backlight core code.
The code first tests against struct backlight_ops.check_ops. If this
test succeeds,
The driver sets struct fb_info.bl_dev to the correct backlight
device. Thus rely on the backlight core code to match backlight
and framebuffer devices, and remove the extra check_fb() function
from struct backlight_ops.
v3:
* use 'check_fb()' in commit message (Andy)
Signed-off-by: Thomas
Update the driver to initialize struct fb_info.bl_dev to its backlight
device, if any. Thus rely on the backlight core code to match backlight
and framebuffer devices, and remove the extra check_fb function from
struct backlight_ops.
v2:
* protect against CONFIG_FB_BACKLIGHT (Javier, kerne
The driver's implementation of check_fb always returns true, which
is the default if no implementation has been set. So remove the code
from the driver.
Signed-off-by: Thomas Zimmermann
Reviewed-by: Daniel Thompson
Reviewed-by: Javier Martinez Canillas
---
drivers/video/backlight/aat2870_bl.c
The internal check_fb callback from struct pwm_bl_data is never
implemented. The driver's implementation of check_fb always
returns true, which is the backlight core's default if no
implementation has been set. So remove the code from the driver.
v2:
* reword commit message
Signed-off-by:
The driver sets struct fb_info.bl_dev to the correct backlight
device. Thus rely on the backlight core code to match backlight
and framebuffer devices, and remove the extra check_fb function
from struct backlight_ops.
Signed-off-by: Thomas Zimmermann
Reviewed-by: Javier Martinez Canillas
---
dr
For drivers that support backlight, LCD and fbdev devices, fbdev has
to be initialized last. See documentation for struct fbinfo.bl_dev.
The backlight name's index number comes from register_framebuffer(),
which now happens after initializing the backlight device. So like
in all other backlight dr
For drivers that support backlight, LCD and fbdev devices, fbdev has
to be initialized last. See documentation for struct fbinfo.bl_dev.
Signed-off-by: Thomas Zimmermann
Cc: "Bruno Prémont"
Reviewed-by: Javier Martinez Canillas
---
drivers/hid/hid-picolcd_core.c | 14 +++---
1 file cha
The driver sets struct fb_info.bl_dev to the correct backlight
device. Thus rely on the backlight core code to match backlight
and framebuffer devices, and remove the extra check_fb function
from struct backlight_ops.
Signed-off-by: Thomas Zimmermann
Reviewed-by: Javier Martinez Canillas
---
dr
Replace check_fb with controls_device in struct backlight_ops. The
new callback interface takes a Linux device instead of a framebuffer.
Resolves one of the dependencies of backlight.h on fb.h.
The few drivers that had custom implementations of check_fb can easily
use the framebuffer's Linux devic
On Tue, 05 Mar 2024, Rodrigo Vivi wrote:
> On Fri, Mar 01, 2024 at 02:42:55PM +0100, Thomas Zimmermann wrote:
>> Unregister all in-kernel clients before unloading the i915 driver. For
>> other drivers, drm_dev_unregister() does this automatically. As i915
>> does not use this helper, it has to per
On 04/03/2024 22:12, John Ogness wrote:
[Added printk maintainer and kdb folks]
Hi Jocelyn,
On 2024-03-01, Jocelyn Falempe wrote:
While writing a panic handler for drm devices [1], I needed a way to
test it without crashing the machine.
So from debugfs, I called
atomic_notifier_call_chain(
Hi,
On Tue, Feb 27, 2024 at 3:26 PM Dmitry Baryshkov
wrote:
>
> On Wed, 28 Feb 2024 at 00:19, Douglas Anderson wrote:
> >
> > Even though the UDL driver converts to RGB565 internally (see
> > pixel32_to_be16() in udl_transfer.c), it advertises XRGB for
> > compatibility. Let's add ARGB t
On Tue, 2024-03-05 at 07:47 -0600, Adam Ford wrote:
> On Tue, Mar 5, 2024 at 5:58 AM Frank Binns wrote:
> > Hi Adam,
> >
> > Sorry for not responding sooner. I've recently just returned from paternity
> > leave, so just catching up on everything.
>
> Congratulations!
>
Thanks!
> > On Thu, 202
> 3) From 2), am65_cpsw_alloc_skb() function removed and replaced by
> netdev_alloc_skb_ip_align(), as used by the driver before -> res = 506
> Conclusion: Here is where the loss comes from.
> IOW, My am65_cpsw_alloc_skb() function is not good.
>
> Initially, I mainly created this 'custom' am65_cp
On 05/03/2024 17:23, Michael Kelley wrote:
From: Guilherme G. Piccoli Sent: Monday, March 4, 2024
1:43 PM
On 04/03/2024 18:12, John Ogness wrote:
[...]
The second question is how to simulate a panic context in a
non-destructive way, so we can test the panic notifiers in CI, without
crash
Hi Duoming,
thanks for sending a V2.
On 3/5/24 15:39, Duoming Zhou wrote:
The kcalloc() in nouveau_dmem_evict_chunk() will return null if
the physical memory has run out. As a result, if we dereference
src_pfns, dst_pfns or dma_addrs, the null pointer dereference bugs
will happen.
Moreover, th
Hi Frank,
> -Original Message-
> From: Frank Binns
> Sent: Tuesday, March 5, 2024 4:43 PM
> Subject: Re: [PATCH v2] drm/imagination: DRM_POWERVR should depend on ARCH_K3
>
> On Tue, 2024-03-05 at 07:47 -0600, Adam Ford wrote:
> > On Tue, Mar 5, 2024 at 5:58 AM Frank Binns wrote:
> > > H
This brings in support for Panthor's HW performance counters and querying
them from UM through a specific ioctl(). The code is inspired by existing
functionality for the Panfrost driver, with some noteworthy differences:
- Sample size is now reported by the firmware rather than having to reckon
Hi Janusz,
On Wed, Feb 28, 2024 at 04:24:41PM +0100, Janusz Krzysztofik wrote:
> While trying to reproduce some other issues reported by CI for i915
> hangcheck live selftest, I found them hidden behind timeout failures
> reported by igt_hang_sanitycheck -- the very first hangcheck test case
> exe
On Tue, Mar 5, 2024 at 3:34 AM Ricardo B. Marliere wrote:
>
> Since commit 43a7206b0963 ("driver core: class: make class_register() take
> a const *"), the driver core allows for struct class to be in read-only
> memory, so move the dma_heap_class structure to be declared at build time
> placing i
Hi Janusz,
On Thu, Feb 22, 2024 at 12:32:40PM +0100, Janusz Krzysztofik wrote:
> Third argument of i915_request_wait() accepts a timeout value in jiffies.
> Most users pass either a simple HZ based expression, or a result of
> msecs_to_jiffies(), or MAX_SCHEDULE_TIMEOUT, or a very small number not
hrdev(kfd_char_dev_major, kfd_dev_name);
kfd_device = NULL;
}
---
base-commit: 8bc75586ea01f1c645063d3472c115ecab03e76c
change-id: 20240305-class_cleanup-drm-amd-bdc7255b7540
Best regards,
On Tue, 05 Mar 2024, "Maxime Ripard" wrote:
> On Tue, 5 Mar 2024 11:07:34 +0200, Jani Nikula wrote:
>> Resend of [1] with an intent to merge after the CI results come in. This
>> is aiming for v6.10, so we'll have maximal time to find all the issues
>> my configs didn't catch.
>>
>> I built this
On Tue, Mar 05, 2024 at 07:43:07PM +0200, Jani Nikula wrote:
On Tue, 05 Mar 2024, "Maxime Ripard" wrote:
On Tue, 5 Mar 2024 11:07:34 +0200, Jani Nikula wrote:
Resend of [1] with an intent to merge after the CI results come in. This
is aiming for v6.10, so we'll have maximal time to find all th
On Thu, Jan 18, 2024 at 7:33 PM Tommy Chiang wrote:
>
> This patch tries to improve the display of the code listing
> on The Linux Kernel documentation website for dma-buf [1] .
>
> Originally, it appears that it was attempting to escape
> the '*' character, but looks like it's not necessary (now)
On Tue, 05 Mar 2024, Lucas De Marchi wrote:
> On Tue, Mar 05, 2024 at 07:43:07PM +0200, Jani Nikula wrote:
>>Thanks everyone for acks and reviews, pushed to drm-misc-next.
>
> should we start removing the now duplicate ones in i915 and xe?
After the drm-misc-next to drm-next merge and subsequent
On 05/03/2024 13:52, Jocelyn Falempe wrote:
> [...]
> Or maybe have two lists of panic notifiers, the safe and the destructive
> list. So in case of fake panic, we can only call the safe notifiers.
>
I tried something like that:
https://lore.kernel.org/lkml/20220427224924.592546-1-gpicc...@igali
On 5 Mar 09:07, T.J. Mercier wrote:
>
> Reviewed-by: T.J. Mercier
>
> Is this really a resend? I don't see anything on lore and I can't
> recall seeing this patch in my inbox before.
Hi T.J. thanks for reviewing!
I'm sorry about that, I sent the series only to Greg before but I
thought it had
ister(&kfd_class);
> > err_class_create:
> > unregister_chrdev(kfd_char_dev_major, kfd_dev_name);
> > err_register_chrdev:
> > @@ -118,8 +119,8 @@ int kfd_chardev_init(void)
> >
> > void kfd_chardev_exit(void)
> > {
> > - device_destroy(kfd_class, MKDEV(kfd_char_dev_major, 0));
> > - class_destroy(kfd_class);
> > + device_destroy(&kfd_class, MKDEV(kfd_char_dev_major, 0));
> > + class_unregister(&kfd_class);
> > unregister_chrdev(kfd_char_dev_major, kfd_dev_name);
> > kfd_device = NULL;
> > }
> >
> > ---
> > base-commit: 8bc75586ea01f1c645063d3472c115ecab03e76c
> > change-id: 20240305-class_cleanup-drm-amd-bdc7255b7540
> >
> > Best regards,
tree/branch:
https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git master
branch HEAD: 11afac187274a6177a7ac82997f8691c0f469e41 Add linux-next specific
files for 20240305
Error/Warning reports:
https://lore.kernel.org/oe-kbuild-all/202403051732.lucjfzah-...@intel.com
https
On Tue, Mar 5, 2024 at 10:02 AM Ricardo B. Marliere
wrote:
>
> On 5 Mar 09:07, T.J. Mercier wrote:
> >
> > Reviewed-by: T.J. Mercier
> >
> > Is this really a resend? I don't see anything on lore and I can't
> > recall seeing this patch in my inbox before.
>
> Hi T.J. thanks for reviewing!
>
> I'
On Wed, 2024-03-06 at 02:14 +0800, kernel test robot wrote:
> > |-- drivers-gpu-drm-nouveau-nvkm-subdev-gsp-r535.c:warning:Function-
> > parameter-or-struct-member-gsp-not-described-in-nvkm_gsp_radix3_sg
Could someone please apply
https://lore.kernel.org/nouveau/20240210002900.148982-1-tt...@nv
Some unit tests intentionally trigger warning backtraces by passing bad
parameters to kernel API functions. Such unit tests typically check the
return value from such calls, not the existence of the warning backtrace.
Such intentionally generated warning backtraces are neither desirable
nor useful
1 - 100 of 243 matches
Mail list logo
