On Fri, May 30, 2025 at 8:50 PM Jagan Teki wrote:
>
> On Mon, 19 May 2025 at 19:14, Tomeu Vizoso wrote:
> >
> > This series adds a new driver for the NPU that Rockchip includes in its
> > newer SoCs, developed by them on the NVDLA base.
> >
> > In its current form, it supports the specific NPU in
Hello,
syzbot found the following issue on:
HEAD commit:d7fa1af5b33e Merge branch 'for-next/core' into for-kernelci
git tree: git://git.kernel.org/pub/scm/linux/kernel/git/arm64/linux.git
for-kernelci
console output: https://syzkaller.appspot.com/x/log.txt?x=1059717058
kernel confi
The pull request you sent on Sat, 31 May 2025 19:13:31 +0200:
> http://git.kernel.org/pub/scm/linux/kernel/git/deller/linux-fbdev.git
> tags/fbdev-for-6.16-rc1
has been merged into torvalds/linux.git:
https://git.kernel.org/torvalds/c/b42966552bb8d3027b66782fc1b53ce570e4d356
Thank you!
--
Dee
Hello,
syzbot found the following issue on:
HEAD commit:914873bc7df9 Merge tag 'x86-build-2025-05-25' of git://git..
git tree: upstream
console output: https://syzkaller.appspot.com/x/log.txt?x=1550fdf458
kernel config: https://syzkaller.appspot.com/x/.config?x=99deacfb6378f156
das
Hi Linus,
please pull the fbdev fixes and updates for 6.16-rc1:
Many small but important fixes for special cases in the fbdev, fbcon and vgacon
code, some smaller code cleanups in the nvidiafb, arkfb, atyfb and viafb drivers
and two spelling fixes.
Thanks!
Helge
PS: All patches have been sittin
On Sat, May 31, 2025 at 4:37 PM Danilo Krummrich wrote:
>
> I agreed to take this code without waiting for those abstractions, but with a
> TODO to fix things up once they land.
That sounds good, yeah.
Cheers,
Miguel
On Sat, May 31, 2025 at 04:09:29PM +0200, Miguel Ojeda wrote:
> On Fri, May 30, 2025 at 11:51 PM Lyude Paul wrote:
> > TBH - we should really add some safe bindings for sleeps instead of calling
> > this unsafely, I'd be happy to review them if you do
>
> In case it helps, there is:
>
>
> h
On Fri, May 30, 2025 at 11:51 PM Lyude Paul wrote:
>
> JFYI: You can actually just say Result here, since () is the default type for
> the kernel's Result type
+1
> TBH - we should really add some safe bindings for sleeps instead of calling
> this unsafely, I'd be happy to review them if you do
On May 31, 2025 3:23:04 AM PDT, Peter Zijlstra wrote:
>On Fri, May 30, 2025 at 10:48:47AM -0700, Kees Cook wrote:
>> On Fri, May 30, 2025 at 04:01:40PM +0200, Peter Zijlstra wrote:
>> > I'm not really concerned with performance here, but more with the size
>> > of the code emitted by WARN_ONCE(
Currently even the SoC's OVL does not declare the support of AFBC, AFBC
is still announced to the userspace within the IN_FORMATS blob, which
breaks modern Wayland compositors like KWin Wayland and others.
Gate passing modifiers to drm_universal_plane_init() behind querying the
driver of the hardw
On Fri, May 30, 2025 at 10:48:47AM -0700, Kees Cook wrote:
> This needs docs too. I think this is collapsing 1 and 2 argument WARNs
> into the ud1, and anything larger is explicitly calling __warn_printk +
> __WARN_FLAGS? If only 1 and 2 args can be collapsed, why reserve 0xfe00
> through 0xfeff?
On Fri, May 30, 2025 at 10:48:47AM -0700, Kees Cook wrote:
> On Fri, May 30, 2025 at 04:01:40PM +0200, Peter Zijlstra wrote:
> > I'm not really concerned with performance here, but more with the size
> > of the code emitted by WARN_ONCE(). There are a *ton* of WARN sites,
> > while only one report_
Hi,
On 29.5.2025 3.06, Eero Tamminen wrote:
On 28.5.2025 11.57, Geert Uytterhoeven wrote:
There were some extra config differences between my builds for 6.15
"atafb" and your "atari-drm-wip-rebasing" branch.
After removing the ones I could:
$ diff -ub .config.
This avoids the need to manually call fwnode_handle_put() in error paths.
Prevents potential memory leaks if future error paths forget the cleanup.
Signed-off-by: Andre Luiz da Nobrega
---
drivers/video/backlight/lm3630a_bl.c | 121 +--
1 file changed, 56 insertions(+), 6
On Fri, May 30, 2025 at 12:40 PM wangtao wrote:
>
> Memory-backed files can optimize copy performance via
> copy_file_range callbacks. Compared to mmap&read: reduces
> GUP (get_user_pages) overhead; vs sendfile/splice: eliminates
> one memory copy; supports dmabuf zero-copy implementation.
>
> Sig
Hi Prabhakar,
> -Original Message-
> From: Prabhakar
> Sent: 30 May 2025 17:59
> Subject: [PATCH v6 01/12] dt-bindings: display: renesas,rzg2l-du: Add support
> for RZ/V2H(P) SoC
>
> From: Lad Prabhakar
>
> The DU block on the RZ/V2H(P) SoC is identical to the one found on the RZ/G2L
Hello Peter,
thanks for the clear explanation.
I finally understand what was bothering you, it wasn’t the __bug_table
size or the execution time overhead, but the code size itself.
On Fri, May 30, 2025 at 4:02 PM Peter Zijlstra wrote:
>
>
> +Mark because he loves a hack :-)
>
> On Thu, May 29, 20
On Fri, May 30, 2025 at 04:01:40PM +0200, Peter Zijlstra wrote:
> I'm not really concerned with performance here, but more with the size
> of the code emitted by WARN_ONCE(). There are a *ton* of WARN sites,
> while only one report_bug() and printk().
We need a new and stronger unlikely(), result
18 matches
Mail list logo
