after 15 usecs
> calling init+0x0/0x60 @ 1
> initcall init+0x0/0x60 returned 0 after 2 usecs
> calling init+0x0/0x9a @ 1
> initcall init+0x0/0x9a returned 0 after 74 usecs
>
> Fixes: 8b7d89d02ef3 ("x86: mmiotrace - trace memory mapped IO")
> Signed-off-by:
On Wed, 19 Jan 2022 21:25:08 +0200
Andy Shevchenko wrote:
> > I say keep it one line!
> >
> > Reviewed-by: Steven Rostedt (Google)
>
> I believe Sakari strongly follows the 80 rule, which means...
Checkpatch says "100" I think we need to simply update
On Wed, 19 Jan 2022 21:22:57 +0200
Andy Shevchenko wrote:
> On Wed, Jan 19, 2022 at 04:38:26PM +, David Laight wrote:
> > > > > > +static inline const char *yesno(bool v) { return v ? "yes" : "no";
> > > > > > }
> > >
> > > return "yes\0no" + v * 4;
> > >
> > > :-)
> >
> > except
grant_log ==
TOMOYO_GRANTLOG_YES
is not readable at all. Not compared to
cond->grant_log == TOMOYO_GRANTLOG_YES
I say keep it one line!
Reviewed-by: Steven Rostedt (Google)
-- Steve
>
> Then,
>
> Reviewed-by: Sakari Ailus
On Wed, 19 Jan 2022 11:15:08 +0200
Andy Shevchenko wrote:
> > +static inline const char *yesno(bool v) { return v ? "yes" : "no"; }
>
>
>
> Perhaps keep it on 4 lines? Yes, yes/no is short, but if we add others
> (enable/disable) it will not be possible to keep on one line. And hence
>
tplug functions with the official version.
> The behavior remains unchanged.
>
> Cc: Steven Rostedt
Reviewed-by: Steven Rostedt (VMware)
-- Steve
> Cc: Ingo Molnar
> Cc: Karol Herbst
> Cc: Pekka Paalanen
> Cc: Dave Hansen
> Cc: Andy Lutomirski
> Cc: Peter Zijlstra
&g
mt) "mmiotrace: " fmt
>
> -#define DEBUG 1
Seems to only be used for printing the pr_debug() functions.
> -
> #include
> #include
> #include
Acked-by: Steven Rostedt (VMware)
-- Steve
___
Nouveau mailing list
Nouveau@li
On Mon, 18 May 2020 11:52:47 -0700
Nick Desaulniers wrote:
> On Mon, May 18, 2020 at 2:31 AM Nathan Chancellor
> wrote:
> >
> > On Wed, Apr 08, 2020 at 01:53:23PM -0700, Nathan Chancellor wrote:
> > > When building with Clang + -Wtautological-compare and
> > > CONFIG_CPUMASK_OFFSTACK unset:
>
rn regardless of CONFIG_CPUMASK_OFFSTACK's value.
>
> Link: https://github.com/ClangBuiltLinux/linux/issues/982
> Reported-by: Sedat Dilek
> Signed-off-by: Nathan Chancellor
> ---
>
Acked-by: Steven Rostedt (VMware)
-- Steve
___
Nouv
On Fri, 24 May 2019 19:30:45 +0300
Nikolay Borisov wrote:
> > Yes I do. I corrected it in my next email.
> >
> > http://lkml.kernel.org/r/20190523133648.591f9...@gandalf.local.home
>
> Or perhaps just using is_power_of_2 from include/linux/log2.h ?
Even better. Thanks,
-- Steve
On Fri, 24 May 2019 16:11:14 +0100
Roger Willcocks wrote:
> On 23/05/2019 16:27, Steven Rostedt wrote:
> >
> > I haven't yet tested this, but what about something like the following:
> >
> > ...perhaps forget about the constant check, and just force
On Thu, 23 May 2019 09:51:29 -0700
Linus Torvalds wrote:
> On Thu, May 23, 2019 at 8:27 AM Steven Rostedt wrote:
> >
> > I haven't yet tested this, but what about something like the following:
>
> So that at least handles the constant case that the normal "roun
On Thu, 23 May 2019 08:10:44 -0700
Linus Torvalds wrote:
> On Thu, May 23, 2019 at 7:00 AM Steven Rostedt wrote:
> >
> > +# define roundup_64(x, y) (\
> > +{ \
> >
From: Steven Rostedt (VMware)
In discussing a build failure on x86_32 due to the use of roundup() on
a 64 bit number, I realized that there's no generic equivalent
roundup_64(). It is implemented in two separate places in the kernel,
but there really should be just one that all can use
On Fri, 30 Nov 2018 12:55:21 -0800
Jarkko Sakkinen wrote:
> On Fri, Nov 30, 2018 at 11:56:52AM -0800, Davidlohr Bueso wrote:
> > On Fri, 30 Nov 2018, Kees Cook wrote:
> >
> > > On Fri, Nov 30, 2018 at 11:27 AM Jarkko Sakkinen
> > > wrote:
> > > >
> > > > In order to comply with the CoC,
On Fri, 30 Nov 2018 20:39:01 +
Abuse wrote:
> On Friday, 30 November 2018 20:35:07 GMT David Miller wrote:
> > From: Jens Axboe
> > Date: Fri, 30 Nov 2018 13:12:26 -0700
> >
> > > On 11/30/18 12:56 PM, Davidlohr Bueso wrote:
> > >> On Fri, 30 Nov 2018, Kees Cook wrote:
> > >>
> >
tates drivers in arch/x86/mm/.
>
> Suggested-by: Alan Cox <gno...@lxorguk.ukuu.org.uk>
> Signed-off-by: David Howells <dhowe...@redhat.com>
Acked-by: Steven Rostedt (VMware) <rost...@goodmis.org>
-- Steve
> cc: Ingo Molnar <mi...@kernel.org>
> cc: Thomas Gleix
mmio_address);
> + pr_warn("WARNING: mapping %lu kB @ 0x%08lx in PCI address space, and
> writing 16 kB of rubbish in there\n",
> + size >> 10, mmio_address);
> do_test(size);
> do_test_bulk_ioremapping();
&g
On Wed, 16 Apr 2008, Ingo Molnar wrote:
so lets fix those preemptability bugs. They show that the
cpu-up/cpu-down ops are called from atomic context - it should normally
be straightforward to sort out - there's no particular reason why the
-open()/-close() methods of an ftrace plugin should
19 matches
Mail list logo
