On Fri, Jul 18, 2025 at 03:49:37PM +0200, Thierry Reding wrote:
> On Thu, Jul 17, 2025 at 02:11:41PM +0200, Greg Kroah-Hartman wrote:
> > On Thu, Jul 17, 2025 at 12:32:34PM +0200, Thierry Reding wrote:
> > > From: Thierry Reding
> > >
> > > Hi,
> > >
> > > Something that's been bugging me over t
From: Bartosz Golaszewski
On Mon, 14 Jul 2025 15:19:51 -0500, Rob Herring (Arm) wrote:
> Many simple GPIO controllers without interrupt capability have the same
> schema other than their compatible value. Combine all these bindings
> into a single schema. The criteria to be included here is must
On Fri, Jul 18, 2025 at 3:10 AM Andrew Morton wrote:
>
> On Thu, 17 Jul 2025 19:27:21 +0500 Sabyrzhan Tasbolatov
> wrote:
>
> > Introduce CONFIG_ARCH_DEFER_KASAN to identify architectures that need
> > to defer KASAN initialization until shadow memory is properly set up.
> >
> > Some architectur
In the past %pK was preferable to %p as it would not leak raw pointer
values into the kernel log.
Since commit ad67b74d2469 ("printk: hash addresses printed with %p")
the regular %p has been improved to avoid this issue.
Furthermore, restricted pointers ("%pK") were never meant to be used
through p
On Thu, Jul 17, 2025 at 02:11:41PM +0200, Greg Kroah-Hartman wrote:
> On Thu, Jul 17, 2025 at 12:32:34PM +0200, Thierry Reding wrote:
> > From: Thierry Reding
> >
> > Hi,
> >
> > Something that's been bugging me over the years is how some drivers have
> > had to adopt file-scoped variables to pa
On Sat, Jul 12, 2025 at 04:22:51PM -0700, Eric Biggers wrote:
> For 6.17, I'd like to take patches 1-15 at the most. Patches 16-26
> would be for later, and I'll probably resend them individually later for
> subsystem maintainers to take.
FYI, patches 1-15 have been in linux-next (via libcrypto-n
Hello Tony,
On Thu, Jul 17, 2025 at 05:29:14PM +, Luck, Tony wrote:
>
> If the intent is still to add this information to vmcore (as in
> earlier discussions in this thread). Then it could go into
> kernel/vmcore_info.c (and be configured with CONFIG_VMCORE_INFO).
>
> Would just need an empty
> I found that I don't need to expose the metrics in vmcore info at all to
> be able to read them from vmcore, given crash/drgn can read those
> symbols.
>
> Global variable hwerror_tracking will be write-only during kernel
> run-time, and only read during post morten analyzes. I am still not sure
On Fri, Jul 18, 2025 at 12:28:44PM +0200, Niklas Cassel wrote:
> On Tue, Jul 15, 2025 at 07:51:03PM +0530, Manivannan Sadhasivam via B4 Relay
> wrote:
> 2) Testing link down reset:
>
> selftests before link down reset:
> # FAILED: 14 / 16 tests passed.
>
> ## On EP side:
> # echo 0 > /sys/kernel
On Tue, Jul 15, 2025 at 07:51:03PM +0530, Manivannan Sadhasivam via B4 Relay
wrote:
> Testing
> ---
>
> I've lost access to my test setup now. So Krishna (Cced) will help with
> testing
> on the Qcom platform and Wilfred or Niklas should be able to test it on
> Rockchip
> platform. For the
On Thu, Jul 17, 2025 at 07:27:30PM +0500, Sabyrzhan Tasbolatov wrote:
> Call kasan_init_generic() which handles Generic KASAN initialization
> and prints the banner. Since s390 doesn't select ARCH_DEFER_KASAN,
> kasan_enable() will be a no-op, and kasan_enabled() will return
> IS_ENABLED(CONFIG_KAS
On Thu, Jul 17, 2025 at 07:27:21PM +0500, Sabyrzhan Tasbolatov wrote:
> Introduce CONFIG_ARCH_DEFER_KASAN to identify architectures that need
> to defer KASAN initialization until shadow memory is properly set up.
>
> Some architectures (like PowerPC with radix MMU) need to set up their
> shadow m
On Thu, Jul 17, 2025 at 04:10:49PM -0400, Mingming Cao wrote:
> This patch enables batched RX buffer replenishment in ibmveth by
> using the new firmware-supported h_add_logical_lan_buffers() hcall
> to submit up to 8 RX buffers in a single call, instead of repeatedly
> calling the single-buffer h
13 matches
Mail list logo
