From: Thomas Gleixner
> Sent: 11 December 2020 12:58
..
> > After my failed hasty sketch from last night I had a different one which
> > was kind of heuristics based (re-reading the upper dword and retrying if
> > it changed on 32-bit).
>
> The problem is that there will be two seperate modificati
From: Thomas Gleixner
> Sent: 11 December 2020 21:11
>
> On Fri, Dec 11 2020 at 14:19, David Laight wrote:
> > From: Thomas Gleixner
> >> You can't catch that. If this really becomes an issue you need a
> >> sequence counter around it.
> >
> > Or
From: Martin Sebor
> Sent: 22 March 2021 22:08
...
> In GCC 11, all access warnings expect objects to be either declared
> or allocated. Pointers with constant values are taken to point to
> nothing valid (as Arnd mentioned above, this is to detect invalid
> accesses to members of structs at addre
From: David Laight
> Sent: 24 March 2021 09:12
>
> From: Martin Sebor
> > Sent: 22 March 2021 22:08
> ...
> > In GCC 11, all access warnings expect objects to be either declared
> > or allocated. Pointers with constant values are taken to point to
> > nothing
From: Alastair D'Silva
> Sent: 08 May 2019 08:02
> To: alast...@d-silva.org
...
> --- a/include/linux/printk.h
> +++ b/include/linux/printk.h
> @@ -480,13 +480,13 @@ enum {
> DUMP_PREFIX_OFFSET
> };
>
> -extern int hex_dump_to_buffer(const void *buf, size_t len, int rowsize,
> -
From: Alastair D'Silva
> Sent: 10 April 2019 04:17
> With the wider display format, it can become hard to identify how many
> bytes into the line you are looking at.
>
> The patch adds new flags to hex_dump_to_buffer() and print_hex_dump() to
> print vertical lines to separate every N groups of by
From: Alastair D'Silva
> Sent: 15 April 2019 11:07
...
> In the above example the author only wants the hex output, while in other
> situations, both hex & ASCII output is desirable. If you just want ASCII
> output, the caller should just use a printk or one of it's wrappers.
Hexdump will 'sanitis
From: Alastair D'Silva
> Sent: 15 April 2019 11:29
...
> I do, and I believe the choice of the output length should be in the hands
> of the caller.
>
> On further thought, it would make more sense to remove the hardcoded list of
> sizes and just enforce a power of 2. The function shouldn't dictat
From: Alastair D'Silva
> Sent: 15 April 2019 11:45
...
> > Although I think you'd want a 'no hex' flag to suppress the hex.
> >
> > Probably more useful flags are ones to suppress the address column.
>
> This is already supported by the prefix_type parameter - are you proposing
> that we eliminat
From: Christoph Hellwig
> Sent: 14 June 2019 14:47
>
> Many architectures (e.g. arm, m68 and sh) have always used exact
> allocation in their dma coherent allocator, which avoids a lot of
> memory waste especially for larger allocations. Lift this behavior
> into the generic allocator so that dma
From: 'Christoph Hellwig'
> Sent: 14 June 2019 15:50
> To: David Laight
> On Fri, Jun 14, 2019 at 02:15:44PM +, David Laight wrote:
> > Does this still guarantee that requests for 16k will not cross a 16k
> > boundary?
> > It looks like you are losing the
From: Robin Murphy
> Sent: 14 June 2019 16:06
...
> Well, apart from the bit in DMA-API-HOWTO which has said this since
> forever (well, before Git history, at least):
>
> "The CPU virtual address and the DMA address are both
> guaranteed to be aligned to the smallest PAGE_SIZE order which
> is gr
> > > +static inline const char *yesno(bool v) { return v ? "yes" : "no"; }
return "yes\0no" + v * 4;
:-)
-
Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT,
UK
Registration No: 1397386 (Wales)
> > > > +static inline const char *yesno(bool v) { return v ? "yes" : "no"; }
>
> return "yes\0no" + v * 4;
>
> :-)
except '"no\0\0yes" + v * 4' works a bit better.
-
Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT,
UK
Registration No: 1397386 (Wales)
> > except '"no\0\0yes" + v * 4' works a bit better.
>
> Is it a C code obfuscation contest?
That would be:
return &(v * 3)["no\0yes"];
:-)
-
Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT,
UK
Registration No: 1397386 (Wales)
From: Mauro Carvalho Chehab
> Sent: 18 July 2022 15:54
>
> On Mon, 18 Jul 2022 14:16:10 +0100
> Tvrtko Ursulin wrote:
>
> > On 14/07/2022 13:06, Mauro Carvalho Chehab wrote:
> > > From: Chris Wilson
> > >
> > > Check if the device is powered down prior to any engine activity,
> > > as, on such
From: Tvrtko Ursulin
> Sent: 19 July 2022 08:25
...
> > It's not only the TLB flushes that cause grief.
> >
> > There is a loop that forces a write-back of all the frame buffer pages.
> > With a large display and some cpu (like my Ivy bridge one) that
> > takes long enough with pre-emption disabled
From: Mauro Carvalho Chehab
> Sent: 30 April 2022 14:38
>
> Em Sat, 30 Apr 2022 14:04:59 +0200
> Greg KH escreveu:
>
> > On Sat, Apr 30, 2022 at 11:30:58AM +0100, Mauro Carvalho Chehab wrote:
>
> > Did you run checkpatch on this? Please do :)
> >
> > > +
> > > + if (mod == this)
> > > +
From: Linus Torvalds
> Sent: 28 February 2022 19:56
> On Mon, Feb 28, 2022 at 4:19 AM Christian König
> wrote:
> >
> > I don't think that using the extra variable makes the code in any way
> > more reliable or easier to read.
>
> So I think the next step is to do the attached patch (which require
From: Matthew Wilcox
> Sent: 28 February 2022 20:16
>
> On Mon, Feb 28, 2022 at 12:10:24PM -0800, Linus Torvalds wrote:
> > We can do
> >
> > typeof(pos) pos
> >
> > in the 'for ()' loop, and never use __iter at all.
> >
> > That means that inside the for-loop, we use a _different_ 'pos' t
From: Linus Torvalds
> Sent: 01 March 2022 19:07
> On Mon, Feb 28, 2022 at 2:29 PM James Bottomley
> wrote:
> >
> > However, if the desire is really to poison the loop variable then we
> > can do
> >
> > #define list_for_each_entry(pos, head, member) \
> > for (pos
From: Linus Torvalds
> Sent: 01 March 2022 23:03
>
> On Tue, Mar 1, 2022 at 2:58 PM David Laight wrote:
> >
> > Can it be resolved by making:
> > #define list_entry_is_head(pos, head, member) ((pos) == NULL)
> > and double-checking that it isn't used anywhe
From: Xiaomeng Tong
> Sent: 02 March 2022 09:31
>
> On Mon, 28 Feb 2022 16:41:04 -0800, Linus Torvalds
> wrote:
> >
> > But basically to _me_, the important part is that the end result is
> > maintainable longer-term.
>
> I couldn't agree more. And because of that, I stick with the following
> a
From: Xiaomeng Tong
> Sent: 03 March 2022 02:27
>
> On Wed, 2 Mar 2022 14:04:06 +0000, David Laight
> wrote:
> > I think that it would be better to make any alternate loop macro
> > just set the variable to NULL on the loop exit.
> > That is easier to code for and t
From: Xiaomeng Tong
> Sent: 03 March 2022 07:27
>
> On Thu, 3 Mar 2022 04:58:23 +0000, David Laight wrote:
> > on 3 Mar 2022 10:27:29 +0800, Xiaomeng Tong wrote:
> > > The problem is the mis-use of iterator outside the loop on exit, and
> > > the iterator will b
From: Jarkko Sakkinen
> Sent: 06 March 2022 05:32
>
> For device memory (aka VM_IO | VM_PFNMAP) MAP_POPULATE does nothing. Allow
> to use that for initializing the device memory by providing a new callback
> f_ops->populate() for the purpose.
>
> SGX patches are provided to show the callback in c
From: Dan Carpenter
> Sent: 07 March 2022 15:01
>
> Updating this API is risky because some places rely on the old behavior
> and not all of them have been updated. Here are some additional places
> you might want to change.
I really can't help thinking that trying to merge this patch is
actuall
From: Christoph Hellwig
> Sent: 07 March 2022 15:57
>
> On Mon, Mar 07, 2022 at 03:29:35PM +0200, Jarkko Sakkinen wrote:
> > So what would you suggest to sort out the issue? I'm happy to go with
> > ioctl if nothing else is acceptable.
>
> PLenty of drivers treat all mmaps as if MAP_POPULATE was
...
> Yeah, and I am sorry for bikeshedding. Honestly, I do not know what is
> better. This is why I do not want to block this series when others
> like this.
>
> My main motivation is to point out that:
>
> enabledisable(enable)
>
> might be, for some people, more eye bleeding than
>
>
flushing large objects takes a demonstrable amount to time
> > > to flush all the cachelines, clflush is still preferred over a
> > > system-wide wbinvd as the latter has unpredictable latencies affecting
> > > the whole system not just the local task.
> > >
From: Chris Wilson
> Sent: 16 January 2020 12:29
>
> Quoting David Laight (2020-01-16 12:26:45)
> > However there is a call from __i915_gem_objet_set_pages() that
> > is preceded by a lockdep_assert_held() check - so mustn't sleep.
>
> That is a mutex; it
> I'll do some measurements later this afternoon.
This is an Ivy bridge cpu, so clflush (not clflushopt).
With a cond_resched for every page I get:
(Note these calls are every 10 seconds)
# tracer: function_graph
#
# CPU DURATION FUNCTION CALLS
# | | |
From: David Laight
> Sent: 16 January 2020 14:41
> > I'll do some measurements later this afternoon.
>
> This is an Ivy bridge cpu, so clflush (not clflushopt).
> With a cond_resched for every page I get:
> (Note these calls are every 10 seconds)
For comparison
re between 800MHz and 4GHz
depending on the whim of the hardware (probable at the low end).
Considerably faster, and enough that calling cond_resched() every 4k
is probably noticable.
So every 128 pages is probably a reasonable compromise.
David
> Reported-by: David Laight
> Sign
From: Sebastian Andrzej Siewior
> Sent: 01 May 2020 11:42
> On 2020-04-30 16:10:16 [-0600], Jason A. Donenfeld wrote:
> > Sometimes it's not okay to use SIMD registers, the conditions for which
> > have changed subtly from kernel release to kernel release. Usually the
> > pattern is to check for ma
From: Christoph Hellwig
> Sent: 04 May 2020 17:03
>
> On Sun, May 03, 2020 at 09:20:19PM +0100, Chris Wilson wrote:
> > > Err, why does i915 implements its own uncached memcpy instead of relying
> > > on core functionality to start with?
> >
> > What is this core functionality that provides movntq
From: Chris Wilson
> Sent: 10 March 2020 09:21
> Instruct the compiler to read the next element in the list iteration
> once, and that it is not allowed to reload the value from the stale
> element later. This is important as during the course of the safe
> iteration, the stale element may be poiso
From: Chris Wilson
> Sent: 10 March 2020 11:50
>
> Quoting David Laight (2020-03-10 11:36:41)
> > From: Chris Wilson
> > > Sent: 10 March 2020 09:21
> > > Instruct the compiler to read the next element in the list iteration
> > > once, and that it is not
From: Marco Elver
> Sent: 10 March 2020 14:10
...
> FWIW, for writes we're already being quite generous, in that plain
> aligned writes up to word-size are assumed to be "atomic" with the
> default (conservative) config, i.e. marking such writes is optional.
> Although, that's a generous assumption
From: Kees Cook
> Sent: 06 December 2017 20:29
>
> There's no good reason to separate the access_ok() from the copy,
> especially since the access_ok() size is hard-coded instead of using
> sizeof(). Instead, just use copy_from_user() directly.
Looks like an optimisation to save doing the access_o
From: Kees Cook
> Sent: 08 December 2017 21:10
> >> There's no good reason to separate the access_ok() from the copy,
> >> especially since the access_ok() size is hard-coded instead of using
> >> sizeof(). Instead, just use copy_from_user() directly.
> >
> > Looks like an optimisation to save doin
From: Logan Gunthorpe
> Sent: 13 April 2017 23:05
> Straightforward conversion to the new helper, except due to
> the lack of error path, we have to warn if unmapable memory
> is ever present in the sgl.
>
> Signed-off-by: Logan Gunthorpe
> ---
> drivers/block/xen-blkfront.c | 33 +++
From: Bin Meng
> Sent: 08 October 2018 10:44
...
> Correct, disable the shared interrupt line keeps all devices using
> that line from working, which is current kernel's behavior w/o this
> quirk handling: it disables the (shared) interrupt line after 100.000+
> generated interrupts. But the side e
From: Bin Meng
> Sent: 08 October 2018 13:34
> Hi David,
>
> On Mon, Oct 8, 2018 at 6:06 PM David Laight wrote:
> >
> > From: Bin Meng
> > > Sent: 08 October 2018 10:44
> > ...
> > > Correct, disable the shared interrupt line keeps all devices usin
From: Andrew Morton
> Sent: 03 August 2023 18:25
>
> On Thu, 3 Aug 2023 16:19:18 +0300 Andy Shevchenko
> wrote:
>
> > abs_diff() belongs to math.h. Move it there.
> > This will allow others to use it.
> >
> > ...
> >
> > --- a/include/linux/math.h
> > +++ b/include/linux/math.h
> > @@ -155,6 +
From: Andrzej Hajda
> Sent: 09 December 2022 15:49
>
> The pattern of setting variable with new value and returning old
> one is very common in kernel. Usually atomicity of the operation
> is not required, so xchg seems to be suboptimal and confusing in
> such cases. Since name xchg is already in
From: Andrew Morton
> Sent: 30 March 2023 20:51
>
> On Thu, 30 Mar 2023 13:42:39 +0300 Jani Nikula wrote:
>
> > is_power_of_2() only works for types <= sizeof(unsigned long) and it's
> > also not a constant expression. There are a number of places in kernel
> > where is_power_of_2() is called on
From: Andrew Morton
> Sent: 30 March 2023 23:19
>
> On Thu, 30 Mar 2023 21:53:03 +0000 David Laight
> wrote:
>
> > > But wouldn't all these issues be addressed by simply doing
> > >
> > > #define is_power_of_2(n) (n != 0 && ((n & (n -
From: Jani Nikula
> Sent: 05 January 2023 13:28
>
> On Thu, 05 Jan 2023, Daniel Vetter wrote:
> > On Mon, Dec 12, 2022 at 09:38:12AM +0000, David Laight wrote:
> >> From: Andrzej Hajda
> >> > Sent: 09 December 2022 15:49
> >> >
> >> >
From: Daniel Vetter
> Sent: 05 January 2023 14:13
...
> > > So here we are, with Andrzej looking to add the common helper. And the
> > > same concerns crop up. What should it be called to make it clear that
> > > it's not atomic? Is that possible?
> >
> > old_value = read_write(variable, new_value)
...
> >> +#define BIT_U8(b) ((u8)(BIT_INPUT_CHECK(u8, b) + BIT(b)))
> >> +#define BIT_U16(b)((u16)(BIT_INPUT_CHECK(u16, b) +
> >> BIT(b)))
> >> +#define BIT_U32(b)((u32)(BIT_INPUT_CHECK(u32, b) +
> >> BIT(b)))
> >> +#define BIT_U64(b)((u64)(
From: Vincent Mailhol
> Sent: 02 December 2024 17:33
>
> From: Vincent Mailhol
>
> For completion, add statically_false() which is the equivalent of
> statically_true() except that it will return true only if the input is
> known to be false at compile time.
This is pretty much pointless.
It is
From: Vincent Mailhol
> Sent: 02 December 2024 17:33
>
> From: Vincent Mailhol
>
> __is_constexpr(), while being one of the most glorious one liner hack
> ever witnessed by mankind, is overly complex. Following the adoption
> of C11 in the kernel, this macro can be simplified through the use of
From: Vincent Mailhol
> Sent: 02 December 2024 17:33
>
> __builtin_choose_expr(__is_constexpr((l) > (h)), (l) > (h), 0)
>
> is equivalent to:
>
> is_const_true((l) > (h))
Change it to BUILD_BUG_ON_MSG(statically_true((l) < (h)), "error message")
and then fix all the fallout :-)
Da
From: Vincent Mailhol
> Sent: 02 December 2024 17:33
>
> From: Vincent Mailhol
>
> is_const() is a one to one replacement of __is_constexpr(). Do the
> replacement so that __is_constexpr() can be removed.
>
> Signed-off-by: Vincent Mailhol
> ---
> include/linux/fortify-string.h | 4 ++--
> 1
From: Vincent Mailhol
> Sent: 02 December 2024 17:34
>
> Most of the use of __is_const_expr() in i915_reg_defs.h are just to
> test whether an expression is known to be true. Because those checks
> are all done in a BUILD_BUG_ON_ZERO(), replace those with
> is_const_true().
Another place that cou
From: Vincent Mailhol
> Sent: 02 December 2024 17:33
>
> In __clamp_once(),
>
> __builtin_choose_expr(__is_constexpr((lo) > (hi)), (lo) <= (hi), true)
>
> is equivalent to:
>
> !is_const_false((lo) <= (hi))
>
> Apply is_const_false() to simplify __clamp_once().
There is already a patch 'f
From: Vincent Mailhol
> Sent: 02 December 2024 17:33
>
> __builtin_constant_p() is known for not always being able to produce
> constant expression [1] which led to the introduction of
> __is_constexpr() [2]. Because of its dependency on
> __builtin_constant_p(), statically_true() suffers from the
From: Martin Uecker
> Sent: 07 December 2024 23:52
...
> While the compiler can not automatically prove every use
> of VLA bounded, it can reliably diagnose the cases where it
> can *not* see that it is bounded. Consider this example:
>
> void oob(int n, char p[n]);
> void f(unsigned int n)
> {
>
From: David Laight
> Sent: 06 December 2024 02:26
(now it is no longer 2am...)
Linus suggested this a while back:
> in
> https://lore.kernel.org/all/CAHk-=wiq=gunwjwwh1craychw73umoaskacovlatfdkevez...@mail.gmail.com/
>
>/*
> * iff 'x' is a non-zero
From: Vincent Mailhol
> Sent: 05 December 2024 15:26
>
> On Thu. 5 Dec 2024 at 03:30, David Laight wrote:
> > From: Vincent Mailhol
> > > Sent: 02 December 2024 17:33
> > >
> > > From: Vincent Mailhol
> > >
> > > For c
From: Vincent Mailhol
> Sent: 07 December 2024 13:51
...
> > > It seems to me that the long term solution to this problem are the
> > > constexpr functions.
> >
> > How would constexpr functions help here? (I am a bit sceptical about
> > constexpr functions.)
>
> I was thinking of some of the "si
From: Martin Uecker
> Sent: 08 December 2024 12:38
>
> Am Sonntag, dem 08.12.2024 um 11:26 + schrieb David Laight:
> > From: Martin Uecker
> > > Sent: 07 December 2024 23:52
> > ...
> > > While the compiler can not automatically prove every use
> &g
From: Linus Torvalds
> Sent: 07 December 2024 20:31
...
> We're currently still accepting gcc-5.1 as a compiler, although it's
> time to look at that and probably (judging by what stable distros use)
> upgrade to something like gcc-8.1 as the minimum supported compiler
> version.
That's going to a
From: Martin Uecker
> Sent: 07 December 2024 19:52
...
> > Of course, often the compiler *does* have helper builtins, but we
> > can't use them, because they aren't *quite* the right thing. Like that
> > "__builtin_constant_p()" not actually working for some situations
> > where we absolutely need
From: Martin Uecker
> Sent: 07 December 2024 21:06
>
> Am Samstag, dem 07.12.2024 um 21:00 + schrieb David Laight:
> > From: Martin Uecker
> > > Sent: 07 December 2024 19:52
> ...
>
> >
> > > There exist proposals along those lines for C2Y.
On Wed, 1 Jan 2025 16:41:19 +
David Laight wrote:
> On Wed, 1 Jan 2025 17:39:20 +0200
> Alexander Usyskin wrote:
>
> > GSC NVM controller HW errors on quad access overlapping 1K border.
> > Align 64bit read and write to avoid readq/writeq over 1K border.
> >
On Wed, 1 Jan 2025 17:39:20 +0200
Alexander Usyskin wrote:
> GSC NVM controller HW errors on quad access overlapping 1K border.
> Align 64bit read and write to avoid readq/writeq over 1K border.
>
> Acked-by: Miquel Raynal
> Signed-off-by: Alexander Usyskin
> ---
> drivers/mtd/devices/mtd-in
On Tue, 21 Jan 2025 15:15:09 -0800
Linus Torvalds wrote:
> On Tue, 21 Jan 2025 at 14:59, Rodrigo Vivi wrote:
> >
> > I'm pushing this soon to drm-intel-next, unless Linus want to take
> > this one directly to his tree
>
> Let's just go through the proper channels and go through the drm tree.
...
> > > #define const_NULL(x) _Generic(0 ? (x) : (char *)0, char *: 1, void *: 0)
> > > #define const_true(x) const_NULL((x) ? NULL : (void *)1L))
> > > #define const_expr(x) const_NULL((x) ? NULL : NULL))
> > > I send this morning.
> > > Needs 's/char/struct kjkjkjkjui/' applied.
> >
> > Oh Chri
From: Vincent Mailhol
> Sent: 05 December 2024 15:31
>
> -CC: Martin Uecker
> +CC: Martin Uecker
> (seems that Martin changed his address)
>
> On Thu. 5 Dec. 2024 at 03:39, David Laight wrote:
> > > Sent: 02 December 2024 17:33
> > >
> > > F
From: Linus Torvalds
> Sent: 06 December 2024 18:53
>
> On Fri, 6 Dec 2024 at 10:31, Vincent Mailhol
> wrote:
> >
> > > causes issues when 'x' is not an integer expression (think
> > > "is_const(NULL)" or "is_const(1 == 2)".
> >
> > But 1 == 2 already has an integer type as proven by:
>
> Yeah,
From: Willy Tarreau
> Sent: 06 December 2024 19:39
> On Fri, Dec 06, 2024 at 11:15:20AM -0800, Linus Torvalds wrote:
> > On Fri, 6 Dec 2024 at 11:07, David Laight wrote:
> > >
> > > I'm missing the compiler version and options to generate the error.
>
From: Linus Torvalds
> Sent: 06 December 2024 19:15
> On Fri, 6 Dec 2024 at 11:07, David Laight wrote:
> >
> > I'm missing the compiler version and options to generate the error.
>
> Just -Wall with most recent gcc versions seems to do it. At least I
> can repro
From: Martin Uecker
> Sent: 07 December 2024 08:40
...
> I find it amazing how much time the Linux kernel community spends
> revising code to make it work perfectly.
>
> Still, I am wondering whether some of this time and effort should not
> be targeted at C compilers and language work to make the
From: Vincent Mailhol
> Sent: 07 December 2024 07:43
...
> > So maybe the slightly long lines:
> > #define const_true(x) _Generic(0 ? (void *)((x) + 0 ? 0L : 1L) : (char *)0,
> > char *: 1, void *: 0)
> > #define const_expr(x) _Generic(0 ? (void *)((x) + 0 ? 0L : 0L) : (char *)0,
> > char *: 1, v
On Sat, 18 Jan 2025 14:58:48 -0800
Guenter Roeck wrote:
> On 1/18/25 14:11, David Laight wrote:
> > On Sat, 18 Jan 2025 13:21:39 -0800
> > Linus Torvalds wrote:
> >
> >> On Sat, 18 Jan 2025 at 09:49, Guenter Roeck wrote:
> >>>
> >>> N
On Sat, 18 Jan 2025 09:49:21 -0800
Guenter Roeck wrote:
> On Sat, Jan 18, 2025 at 05:09:59PM +0000, David Laight wrote:
> > On Sat, 18 Jan 2025 08:13:06 -0800
> > Guenter Roeck wrote:
> >
> > > Hi,
> > >
> > > On Mon, Nov 18, 2024 at 07:
On Sat, 18 Jan 2025 08:13:06 -0800
Guenter Roeck wrote:
> Hi,
>
> On Mon, Nov 18, 2024 at 07:13:31PM +0000, David Laight wrote:
> > Use BUILD_BUG_ON_MSG(statically_true(ulo > uhi), ...) for the sanity
> > check of the bounds in clamp().
> > Gives better error cove
On Mon, 20 Jan 2025 06:15:30 -0800
Guenter Roeck wrote:
> On 1/20/25 03:21, Jani Nikula wrote:
> > On Mon, 20 Jan 2025, David Laight wrote:
> >> On Mon, 20 Jan 2025 12:48:11 +0200
> >> Jani Nikula wrote:
> >>
> >>> On Sun, 19 Jan 2025, Davi
On Sat, 18 Jan 2025 10:36:11 -0800
Guenter Roeck wrote:
> On 1/18/25 10:09, David Laight wrote:
> > On Sat, 18 Jan 2025 09:49:21 -0800
> > Guenter Roeck wrote:
> >
> >> On Sat, Jan 18, 2025 at 05:09:59PM +, David Laight wrote:
> >>> On Sat
On Mon, 20 Jan 2025 12:48:11 +0200
Jani Nikula wrote:
> On Sun, 19 Jan 2025, David Laight wrote:
> > On Sat, 18 Jan 2025 14:58:48 -0800
> > Guenter Roeck wrote:
> >
> >> On 1/18/25 14:11, David Laight wrote:
> >> > On Sat, 18 Jan 2025 1
On Sat, 18 Jan 2025 13:21:39 -0800
Linus Torvalds wrote:
> On Sat, 18 Jan 2025 at 09:49, Guenter Roeck wrote:
> >
> > No idea why the compiler would know that the values are invalid.
>
> It's not that the compiler knows tat they are invalid, but I bet what
> happens is in scale() (and possibl
On Wed, 5 Mar 2025 17:48:05 +0200
Andy Shevchenko wrote:
> On Wed, Mar 05, 2025 at 11:48:10PM +0900, Vincent Mailhol wrote:
> > On 05/03/2025 at 23:33, Andy Shevchenko wrote:
> > > On Wed, Mar 05, 2025 at 10:00:16PM +0900, Vincent Mailhol via B4 Relay
> > > wrote:
>
> ...
>
> > >> +#define
On Wed, 5 Mar 2025 21:56:22 +0200
Andy Shevchenko wrote:
> On Thu, Mar 06, 2025 at 02:17:18AM +0900, Vincent Mailhol wrote:
> > On 06/03/2025 at 00:48, Andy Shevchenko wrote:
> > > On Wed, Mar 05, 2025 at 11:48:10PM +0900, Vincent Mailhol wrote:
> > >> On 05/03/2025 at 23:33, Andy Shevchenko
On Thu, 06 Mar 2025 20:29:52 +0900
Vincent Mailhol via B4 Relay
wrote:
> From: Vincent Mailhol
>
> In an upcoming change, GENMASK() and its friends will indirectly
> depend on sizeof() which is not available in asm.
>
> Instead of adding further complexity to __GENMASK() to make it work
> for
On Fri, 7 Mar 2025 18:58:08 +0900
Vincent Mailhol wrote:
> On 07/03/2025 at 04:23, David Laight wrote:
> > On Thu, 06 Mar 2025 20:29:52 +0900
> > Vincent Mailhol via B4 Relay
> > wrote:
> >
> >> From: Vincent Mailhol
> >>
> >>
On Fri, 7 Mar 2025 18:58:08 +0900
Vincent Mailhol wrote:
> On 07/03/2025 at 04:23, David Laight wrote:
> > On Thu, 06 Mar 2025 20:29:52 +0900
> > Vincent Mailhol via B4 Relay
> > wrote:
> >
> >> From: Vincent Mailhol
> >>
> >>
On Sun, 9 Mar 2025 01:58:53 +
David Laight wrote:
> On Fri, 7 Mar 2025 18:58:08 +0900
> Vincent Mailhol wrote:
>
> > On 07/03/2025 at 04:23, David Laight wrote:
> > > On Thu, 06 Mar 2025 20:29:52 +0900
> > > Vincent Mailhol via B4 Relay
> > &g
89 matches
Mail list logo
