Re: [PATCH V3 2/2] debugfs: don't assume sizeof(bool) to be 4 bytes

On Tue, 15 Sep 2015 14:04:59 +0530 Viresh Kumar wrote: > diff --git a/drivers/acpi/ec.c b/drivers/acpi/ec.c > index 2614a839c60d..f11e17ad7834 100644 > --- a/drivers/acpi/ec.c > +++ b/drivers/acpi/ec.c > @@ -1237,7 +1237,7 @@ ec_parse_device(acpi_handle handle, u32

Re: [PATCH V3 2/2] debugfs: don't assume sizeof(bool) to be 4 bytes

On Tue, 15 Sep 2015 10:38:32 -0700 Linus Torvalds wrote: > But that user interface issue doesn't seem to be the case here, an I > can't say that I mind the patch. It looks fairly sane. If Linus is fine with it, I'm fine with it too. But please, next time, go

Re: [for-next][PATCH 2/2] tracing: Use temp buffer when filtering events

On Fri, 28 Aug 2020 18:49:55 -0400 Steven Rostedt wrote: > On Fri, 28 Aug 2020 15:53:06 +0800 > Wen Gong wrote: > > > this patch commit id is : 0fc1b09ff1ff404ddf753f5ffa5cd0adc8fdcdc9 which > > has upstream. > > > > how much size is the per cpu b

Re: [for-next][PATCH 2/2] tracing: Use temp buffer when filtering events

On Fri, 28 Aug 2020 15:53:06 +0800 Wen Gong wrote: > this patch commit id is : 0fc1b09ff1ff404ddf753f5ffa5cd0adc8fdcdc9 which > has upstream. > > how much size is the per cpu buffer? > seems it is initilized in trace_buffered_event_enable, > it is only 1 page size as below: > void

Re: [PATCH] ath10k: change len of trace_ath10k_log_dbg_dump for large buffer size

On Tue, 9 Feb 2021 11:35:07 -0800 Brian Norris wrote: > + Steven Rostedt Thanks. > > Hi Wen, > > (Trimming down the description a bit:) > > On Mon, Feb 8, 2021 at 6:59 PM Wen Gong wrote: > > > > Kernel panic every time in kernel when running below case: &

Re: [PATCH] ath10k: change len of trace_ath10k_log_dbg_dump for large buffer size

On Tue, 9 Feb 2021 14:55:31 -0500 Steven Rostedt wrote: > > [for-next][PATCH 2/2] tracing: Use temp buffer when filtering events > > https://lore.kernel.org/lkml/f16b14066317f6a926b6636df6974...@codeaurora.org/ > > > > Note, that is only used when filtering happe

Re: [PATCH] ath10k: change len of trace_ath10k_log_dbg_dump for large buffer size

On Wed, 10 Feb 2021 10:01:57 +0800 Wen Gong wrote: > Not tested with latest kernel. > The reason is below which I said in > https://lore.kernel.org/lkml/b504b3d7e989cae108669a0cd3072...@codeaurora.org/ > > the per cpu buffer seems it is initilized in > trace_buffered_event_enable, > it is

Re: [PATCH] ath10k: change len of trace_ath10k_log_dbg_dump for large buffer size

On Wed, 10 Feb 2021 11:30:26 -0500 Steven Rostedt wrote: > Can you test this patch? v2: diff --git a/kernel/trace/trace.c b/kernel/trace/trace.c index b79bcacdd6f9..c5c3d826d420 100644 --- a/kernel/trace/trace.c +++ b/kernel/trace/trace.c @@ -2739,7 +2739,7 @@ trace_event_buffer_lock_rese

Re: [PATCH] ath10k: change len of trace_ath10k_log_dbg_dump for large buffer size

On Wed, 10 Feb 2021 11:48:23 -0500 Steven Rostedt wrote: > On Wed, 10 Feb 2021 11:30:26 -0500 > Steven Rostedt wrote: > > > Can you test this patch? > > v2: Bah! v3: diff --git a/kernel/trace/trace.c b/kernel/trace/trace.c index b79bcacdd6f9..90d7ade03499 1006

[PATCH 03/13] tracing/ath: Use the new __vstring() helper

From: "Steven Rostedt (Google)" Instead of open coding a __dynamic_array() with a fixed length (which defeats the purpose of the dynamic array in the first place). Use the new __vstring() helper that will use a va_list and only write enough of the string into the ring buffer that is n

[for-next][PATCH 08/23] tracing/ath: Use the new __vstring() helper

From: "Steven Rostedt (Google)" Instead of open coding a __dynamic_array() with a fixed length (which defeats the purpose of the dynamic array in the first place). Use the new __vstring() helper that will use a va_list and only write enough of the string into the ring buffer that

Re: [FYI][PATCH] tracing/treewide: Remove second parameter of __assign_str()

On Fri, 23 Feb 2024 12:56:34 -0500 Steven Rostedt wrote: > Note, the same updates will need to be done for: > > __assign_str_len() > __assign_rel_str() > __assign_rel_str_len() Correction: The below macros do not pass in their source to the entry macros, so the

Re: [FYI][PATCH] tracing/treewide: Remove second parameter of __assign_str()

On Fri, 23 Feb 2024 13:46:53 -0500 Steven Rostedt wrote: > Now one thing I could do is to not remove the parameter, but just add: > > WARN_ON_ONCE((src) != __data_offsets->item##_ptr_); > > in the __assign_str() macro to make sure that it's still the same that is &

Re: [FYI][PATCH] tracing/treewide: Remove second parameter of __assign_str()

On Fri, 23 Feb 2024 10:30:45 -0800 Jeff Johnson wrote: > On 2/23/2024 9:56 AM, Steven Rostedt wrote: > > From: "Steven Rostedt (Google)" > > > > [ > >This is a treewide change. I will likely re-create this patch again in > >the second

Re: [FYI][PATCH] tracing/treewide: Remove second parameter of __assign_str()

On Fri, 23 Feb 2024 14:50:49 -0500 Kent Overstreet wrote: > Tangentially related though, what would make me really happy is if we > could create the string with in the TP__fast_assign() section. I have to > have a bunch of annoying wrappers right now because the string length > has to be known

Re: [FYI][PATCH] tracing/treewide: Remove second parameter of __assign_str()

On Thu, 14 Mar 2024 09:57:57 -0700 Alison Schofield wrote: > On Fri, Feb 23, 2024 at 12:56:34PM -0500, Steven Rostedt wrote: > > From: "Steven Rostedt (Google)" > > > > [ > >This is a treewide change. I will likely re-create this patch again in >