NO_IRQ is used to check the return of irq_of_parse_and_map().
On some architecture NO_IRQ is 0, on other architectures it is -1.
irq_of_parse_and_map() returns 0 on error, independent of NO_IRQ.
So use 0 instead of using NO_IRQ.
Signed-off-by: Christophe Leroy
---
NO_IRQ is used to check the return of irq_of_parse_and_map().
On some architecture NO_IRQ is 0, on other architectures it is -1.
irq_of_parse_and_map() returns 0 on error, independent of NO_IRQ.
So use 0 instead of using NO_IRQ.
Signed-off-by: Christophe Leroy
---
On 06. 10. 22, 7:20, Christophe Leroy wrote:
NO_IRQ is used to check the return of irq_of_parse_and_map().
On some architecture NO_IRQ is 0, on other architectures it is -1.
irq_of_parse_and_map() returns 0 on error, independent of NO_IRQ.
So use 0 instead of using NO_IRQ.
Signed-off-by:
NO_IRQ is used to check the return of irq_of_parse_and_map().
On some architecture NO_IRQ is 0, on other architectures it is -1.
irq_of_parse_and_map() returns 0 on error, independent of NO_IRQ.
So use 0 instead of using NO_IRQ.
Signed-off-by: Christophe Leroy
---
drivers/tty/ehv_bytechan.c
irq_default_primary_handler() can be used only with IRQF_ONESHOT
flag, but the flag disables IRQ before executing the thread handler
and enables it after the interrupt is handled. But this IRQ disable
sets the VAS IRQ OFF state in the hypervisor. In case if NX faults
during this window, the
+ KASAN list
Le 06/10/2022 à 06:10, Michael Ellerman a écrit :
> Nathan Lynch writes:
>> kasan is known to crash at boot on book3s_64 with non-radix MMU. As
>> noted in commit 41b7a347bf14 ("powerpc: Book3S 64-bit outline-only
>> KASAN support"):
>>
>>A kernel with CONFIG_KASAN=y will crash
On Thu, 2022-10-06 at 11:39 +1100, Michael Ellerman wrote:
> Christophe Leroy writes:
> > However, thinking out loudly, I'm wondering, could we make things
> > any
> > simpler when CONFIG_MODULES is not selected, or is that a too much
> > corner case on PPC64 ?
>
> I'd say it's mostly a corner
On Wed, Oct 05, 2022 at 11:48:43PM +0200, Jason A. Donenfeld wrote:
> The prandom_bytes() function has been a deprecated inline wrapper around
> get_random_bytes() for several releases now, and compiles down to the
> exact same code. Replace the deprecated wrapper with a direct call to
> the real
On Wed, Oct 05, 2022 at 11:48:43PM +0200, Jason A. Donenfeld wrote:
> The prandom_bytes() function has been a deprecated inline wrapper around
> get_random_bytes() for several releases now, and compiles down to the
> exact same code. Replace the deprecated wrapper with a direct call to
> the real
On Wed, Oct 05, 2022 at 11:48:44PM +0200, Jason A. Donenfeld wrote:
> With no callers left of prandom_u32() and prandom_bytes(), remove these
> deprecated wrappers.
>
> Signed-off-by: Jason A. Donenfeld
Reviewed-by: Kees Cook
--
Kees Cook
On Wed, Oct 05, 2022 at 11:48:41PM +0200, Jason A. Donenfeld wrote:
> Rather than truncate a 32-bit value to a 16-bit value or an 8-bit value,
> simply use the get_random_{u8,u16}() functions, which are faster than
> wasting the additional bytes from a 32-bit value.
>
> Signed-off-by: Jason A.
On Wed, Oct 5, 2022 at 9:16 PM Kees Cook wrote:
>
> On Wed, Oct 05, 2022 at 11:48:40PM +0200, Jason A. Donenfeld wrote:
> > Rather than incurring a division or requesting too many random bytes for
> > the given range, use the prandom_u32_max() function, which only takes
> > the minimum required
On Wed, Oct 05, 2022 at 11:48:40PM +0200, Jason A. Donenfeld wrote:
> Rather than incurring a division or requesting too many random bytes for
> the given range, use the prandom_u32_max() function, which only takes
> the minimum required bytes from the RNG and avoids divisions.
Yes please!
Since
On Wed, 2022-10-05 at 19:18 +, Christophe Leroy wrote:
>
>
> Le 05/10/2022 à 07:32, Benjamin Gray a écrit :
> > The callee may set a field in st_other to 1 to indicate r2 should
> > be
> > treated as caller-saved. This means a trampoline must be used to
> > save
> > the current TOC before
Nathan Lynch writes:
> kasan is known to crash at boot on book3s_64 with non-radix MMU. As
> noted in commit 41b7a347bf14 ("powerpc: Book3S 64-bit outline-only
> KASAN support"):
>
> A kernel with CONFIG_KASAN=y will crash during boot on a machine
> using HPT translation because not all the
On Wed, 2022-10-05 at 19:18 +, Christophe Leroy wrote:
>
>
> Le 05/10/2022 à 07:32, Benjamin Gray a écrit :
> > The callee may set a field in st_other to 1 to indicate r2 should
> > be
> > treated as caller-saved. This means a trampoline must be used to
> > save
> > the current TOC before
On Wed, 2022-10-05 at 17:55 +, Christophe Leroy wrote:
> I'm on business trip this week so I can't test it on hardware, but
> the
> generated code looks horrid and sub-optimal, with a stack frame and
> so
> many registers saved into it. That's mpc885_ads_defconfig built with
> GCC
> 12,
Although the previous commit made the powerpc instruction dump usable
with scripts/decodecode, there are still some problems.
Because the dump is split across multiple lines, the script doesn't cope
with printk timestamps or caller info.
That can be fixed by printing the entire dump on one line,
Matt reported that scripts/decodecode doesn't work for the instruction
dump in the powerpc oops output. Although there are scripts around that
can decode it, it would be preferable if the standard in-tree script
worked.
All other arches prefix the instruction dump with "Code:", and that's
what
tree/branch: https://git.kernel.org/pub/scm/linux/kernel/git/powerpc/linux.git
next
branch HEAD: b2e82e495a528eed77c15f3923c2b049a21d7280 powerpc/64s/interrupt:
Fix stack frame regs marker
elapsed time: 728m
configs tested: 63
configs skipped: 2
The following configs have been built
tree/branch: https://git.kernel.org/pub/scm/linux/kernel/git/powerpc/linux.git
merge
branch HEAD: 18e4cc8b62fda447da3e713891c9196d47239cca Merge branch 'next' into
merge
elapsed time: 720m
configs tested: 67
configs skipped: 4
The following configs have been built successfully.
More configs
Christophe Leroy writes:
> Le 05/10/2022 à 07:32, Benjamin Gray a écrit :
>> Implement static call support for 64 bit V2 ABI. This requires making
>> sure the TOC is kept correct across kernel-module boundaries. As a
>> secondary concern, it tries to use the local entry point of a target
>>
With no callers left of prandom_u32() and prandom_bytes(), remove these
deprecated wrappers.
Signed-off-by: Jason A. Donenfeld
---
include/linux/prandom.h | 12
1 file changed, 12 deletions(-)
diff --git a/include/linux/prandom.h b/include/linux/prandom.h
index
The prandom_bytes() function has been a deprecated inline wrapper around
get_random_bytes() for several releases now, and compiles down to the
exact same code. Replace the deprecated wrapper with a direct call to
the real function.
Signed-off-by: Jason A. Donenfeld
---
The prandom_u32() function has been a deprecated inline wrapper around
get_random_u32() for several releases now, and compiles down to the
exact same code. Replace the deprecated wrapper with a direct call to
the real function.
Signed-off-by: Jason A. Donenfeld
---
Rather than truncate a 32-bit value to a 16-bit value or an 8-bit value,
simply use the get_random_{u8,u16}() functions, which are faster than
wasting the additional bytes from a 32-bit value.
Signed-off-by: Jason A. Donenfeld
---
crypto/testmgr.c | 8
Rather than incurring a division or requesting too many random bytes for
the given range, use the prandom_u32_max() function, which only takes
the minimum required bytes from the RNG and avoids divisions.
Signed-off-by: Jason A. Donenfeld
---
arch/x86/mm/pat/cpa-test.c| 4
Hi Andy,
On Wed, Oct 05, 2022 at 06:29:46PM +0300, Andy Shevchenko wrote:
> The fwnode_device_is_compatible() helper searches for the
> given string in the "compatible" string array property and,
> if found, returns true.
>
> Signed-off-by: Andy Shevchenko
> ---
> include/linux/property.h | 10
Le 05/10/2022 à 07:32, Benjamin Gray a écrit :
> Implement static call support for 64 bit V2 ABI. This requires making
> sure the TOC is kept correct across kernel-module boundaries. As a
> secondary concern, it tries to use the local entry point of a target
> wherever possible. It does so by
Le 05/10/2022 à 07:32, Benjamin Gray a écrit :
> These tests are out-of-line only, so moving them to the
> their own file allows them to be run when an arch does
> not implement inline static calls.
>
> Signed-off-by: Benjamin Gray
> Reviewed-by: Andrew Donnellan
Reviewed-by: Christophe
Le 05/10/2022 à 07:32, Benjamin Gray a écrit :
> Inserts a direct branch to the stub target when possible, replacing the
> mtctr/btctr sequence.
>
> The load into r12 could potentially be skipped too, but that change
> would need to refactor the arguments to indicate that the address
> does not
Le 05/10/2022 à 07:32, Benjamin Gray a écrit :
> The callee may set a field in st_other to 1 to indicate r2 should be
> treated as caller-saved. This means a trampoline must be used to save
> the current TOC before calling it and restore it afterwards, much like
> external calls.
The 'callee',
> Does fixing the alignment issues and the commit description justify a v3
> of the patch or should the minor fixes go out as a "resend"? Just not sure
> in this particular case as the fixes seem to be very minor ones.
Yes, please send a v3. Since you are only fixing whitespace issues, you
can
Hi,
Le 05/10/2022 à 07:32, Benjamin Gray a écrit :
> Adds a generic text patching mechanism for patches of size int or long
> bytes.
>
> The patch_instruction function is reimplemented in terms of this
> more generic function. This generic implementation allows patching of
> arbitrary long data,
On Thu, Oct 06, 2022 at 12:05:43AM +0800, kernel test robot wrote:
> Hi Andy,
>
> I love your patch! Yet something to improve:
>
> [auto build test ERROR on soc/for-next]
> [also build test ERROR on linus/master v6.0 next-20221005]
> [If your patch is applied to the wrong
Hi Andy,
I love your patch! Yet something to improve:
[auto build test ERROR on soc/for-next]
[also build test ERROR on linus/master v6.0 next-20221005]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we suggest to use '--base' as documented
The OF node in the GPIO library is deprecated and soon
will be removed.
GPIO library now accepts fwnode as a firmware node, so
switch the driver to use it.
Signed-off-by: Andy Shevchenko
---
drivers/soc/fsl/qe/gpio.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git
The fwnode_device_is_compatible() helper searches for the
given string in the "compatible" string array property and,
if found, returns true.
Signed-off-by: Andy Shevchenko
---
include/linux/property.h | 10 +-
1 file changed, 9 insertions(+), 1 deletion(-)
diff --git
One more user outside of GPIO library and pin control folders needs
to be updated to use fwnode instead of of_node. To make this easier
introduce a helper in property.h and convert the user.
Note, the helper will be useful not only for the current users,
but any future ones that want to replace
On Wed, Oct 05, 2022 at 05:38:11PM +0300, Andy Shevchenko wrote:
> The fwnode_device_is_compatible() helper searches for the
> given string in the "compatible" string array property and,
> if found, returns true.
Scratch this, it has some flaws.
--
With Best Regards,
Andy Shevchenko
The fwnode_device_is_compatible() helper searches for the
given string in the "compatible" string array property and,
if found, returns true.
Signed-off-by: Andy Shevchenko
---
include/linux/property.h | 5 +
1 file changed, 5 insertions(+)
diff --git a/include/linux/property.h
The OF node in the GPIO library is deprecated and soon
will be removed.
GPIO library now accepts fwnode as a firmware node, so
switch the driver to use it.
Signed-off-by: Andy Shevchenko
---
drivers/soc/fsl/qe/gpio.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git
Em Wed, Oct 05, 2022 at 09:28:52AM -0300, Arnaldo Carvalho de Melo escreveu:
> Em Wed, Oct 05, 2022 at 10:23:39AM +0530, Athira Rajeev escreveu:
> > diff --git a/tools/perf/util/stat-display.c b/tools/perf/util/stat-display.c
> > index b82844cb0ce7..cf28020798ec 100644
> > ---
Em Wed, Oct 05, 2022 at 10:23:39AM +0530, Athira Rajeev escreveu:
>
>
> > On 04-Oct-2022, at 11:44 PM, Arnaldo Carvalho de Melo
> > wrote:
> >
> > Em Tue, Oct 04, 2022 at 03:14:27PM -0300, Arnaldo Carvalho de Melo escreveu:
> >> Em Tue, Oct 04, 2022 at 07:49:21AM -0700, Ian Rogers escreveu:
>
Em Wed, Oct 05, 2022 at 10:23:39AM +0530, Athira Rajeev escreveu:
>
>
> > On 04-Oct-2022, at 11:44 PM, Arnaldo Carvalho de Melo
> > wrote:
> >
> > Em Tue, Oct 04, 2022 at 03:14:27PM -0300, Arnaldo Carvalho de Melo escreveu:
> >> Em Tue, Oct 04, 2022 at 07:49:21AM -0700, Ian Rogers escreveu:
>
Matthew Wilcox writes:
> On Fri, Sep 30, 2022 at 12:01:26PM +1000, Michael Ellerman wrote:
>> Matthew Wilcox writes:
>> >> [ 4681.238745] Instruction dump:
>> >> [ 4681.238749] fbc1fff0 f821ffc1 7c7d1b78 7c9c2378 ebc30028 7fdff378
>> >> 4818 6000
>> >> [ 4681.238765] 6000
File already contains code that is common along balloon
drivers so rename it to reflect its contents.
mm/balloon_compaction.c -> mm/balloon.c
include/linux/balloon_compaction.h -> include/linux/balloon.h
Remove it from files which do not actually use it.
Drop externs from function delcarations.
47 matches
Mail list logo
