Remove tasklet for it may cause the reset operation
can't be handled immediately, then there will be
endless xrun interrupt.
Fixes: 7ccafa2b3879 ("ASoC: fsl_esai: recover the channel swap after xrun")
Signed-off-by: Shengjiu Wang
---
sound/soc/fsl/fsl_esai.c | 15 ---
1 file changed,
>Le 24/04/2020 à 04:45, Wang Wenhu a écrit :
>> New module which registers its memory allocation and free APIs to the
>> sram_dynamic module, which would create a device of struct sram_device
>> type to act as an interface for user level applications to access the
>> backend hardware device, fsl_85
ppc-opcode.h have base instruction encoding wrapped with stringify_in_c()
for raw encoding to have compatibility. But there are redundant macros for
base instruction encodings in bpf, instruction emulation test infrastructure
and powerpc selftests.
Currently PPC_INST_* macros are used for encoding
Few ppc instructions are encoded in test_emulate_step.c, consolidate
them and use it from ppc-opcode.h
Signed-off-by: Balamuruhan S
---
arch/powerpc/include/asm/ppc-opcode.h | 35 ++
arch/powerpc/lib/test_emulate_step.c | 155 ++
2 files changed, 91 insertions(+), 9
Introduce PPC_RAW_* macros to have all the bare encoding of ppc
instructions. Move `VSX_XX*()` and `TMRN()` macros up to reuse it.
Signed-off-by: Balamuruhan S
---
arch/powerpc/include/asm/ppc-opcode.h | 183 --
1 file changed, 175 insertions(+), 8 deletions(-)
diff --gi
remove duplicate macro definitions from bpf_jit.h and reuse the macros from
ppc-opcode.h
Signed-off-by: Balamuruhan S
---
arch/powerpc/net/bpf_jit.h| 18 +-
arch/powerpc/net/bpf_jit32.h | 10 +-
arch/powerpc/net/bpf_jit64.h | 4 ++--
arch/powerpc/net/bp
move macro definitions of powerpc instructions from bpf_jit.h to ppc-opcode.h
and adopt the users of the macros accordingly. `PPC_MR()` is defined twice in
bpf_jit.h, remove the duplicate one.
Signed-off-by: Balamuruhan S
---
arch/powerpc/include/asm/ppc-opcode.h | 139 +
arch/powerp
Lot of PPC_INST_* macros are used only ever in PPC_* macros, fold those
PPC_INST_* into PPC_RAW_* to avoid using PPC_INST_* accidentally.
Signed-off-by: Balamuruhan S
---
arch/powerpc/include/asm/ppc-opcode.h | 381 +-
1 file changed, 125 insertions(+), 256 deletions(-)
Wrap existing stringify macros to reuse raw instruction encoding macros that
are newly added.
Signed-off-by: Balamuruhan S
---
arch/powerpc/include/asm/ppc-opcode.h | 220 +-
1 file changed, 71 insertions(+), 149 deletions(-)
diff --git a/arch/powerpc/include/asm/ppc-opc
Avoid redefining macros to encode ppc instructions instead reuse it from
ppc-opcode.h, Makefile changes are necessary to compile memcmp_64.S with
__ASSEMBLY__ defined from selftests.
Signed-off-by: Balamuruhan S
---
.../selftests/powerpc/stringloops/Makefile| 34 ++
.../power
Le 24/04/2020 à 09:05, 王文虎 a écrit :
Le 24/04/2020 à 04:45, Wang Wenhu a écrit :
New module which registers its memory allocation and free APIs to the
sram_dynamic module, which would create a device of struct sram_device
type to act as an interface for user level applications to access the
b
On 12.04.20 21:48, Mike Rapoport wrote:
> From: Baoquan He
>
> When called during boot the memmap_init_zone() function checks if each PFN
> is valid and actually belongs to the node being initialized using
> early_pfn_valid() and early_pfn_in_nid().
>
> Each such check may cost up to O(log(n)) w
https://bugzilla.kernel.org/show_bug.cgi?id=199471
--- Comment #24 from Wolfram Sang (w...@the-dreams.de) ---
@Michael: commit bcf3588d8ed has the following tags:
Reported-by: Erhard Furtner
Tested-by: Erhard Furtner
And Erhard is also the one who created this bug entry.
--
You are receiving
create mode 100644 arch/powerpc/sysdev/fsl_85xx_sram_uapi.c
>>>
>>> We shouldn't add more stuff in arch/powerpc/sysdev/
>>>
>>> Either it is dedicated to 85xx, and it should go into
>>> arch/powerpc/platform/85xx/ , or it is common to several
>>> platforms/architectures and should be moved
On Fri, Apr 24, 2020 at 01:23:37PM +1000, Michael Ellerman wrote:
> Nathan Chancellor writes:
> > On Tue, Apr 14, 2020 at 11:57:31PM +1000, Herbert Xu wrote:
> >> On Mon, Apr 13, 2020 at 12:50:42PM -0700, Nathan Chancellor wrote:
> >> > 0day reports over and over on an powerpc randconfig with clan
Include "linux/of_address.h" to fix the compile error for
mpc85xx_l2ctlr_of_probe() when compiling fsl_85xx_cache_sram.c.
CC arch/powerpc/sysdev/fsl_85xx_l2ctlr.o
arch/powerpc/sysdev/fsl_85xx_l2ctlr.c: In function ‘mpc85xx_l2ctlr_of_probe’:
arch/powerpc/sysdev/fsl_85xx_l2ctlr.c:90:11: error
Include linux/io.h into fsl_85xx_cache_sram.c to fix the
implicit-declaration compile error when building Cache-Sram.
arch/powerpc/sysdev/fsl_85xx_cache_sram.c: In function ‘instantiate_cache_sram’:
arch/powerpc/sysdev/fsl_85xx_cache_sram.c:97:26: error: implicit declaration of
function ‘ioremap_
A generic User-Kernel interface module that allows a misc device created
when a backend SRAM hardware device driver registers its APIs to support
file operations of ioctl and mmap for user space applications to allocate
SRAM memory, mmap it to process address space and free it then after.
It is ex
Function instantiate_cache_sram should not be linked into the init
section for its caller mpc85xx_l2ctlr_of_probe is none-__init.
Cc: Greg Kroah-Hartman
Cc: Arnd Bergmann
Cc: Christophe Leroy
Cc: Scott Wood
Cc: Michael Ellerman
Cc: Randy Dunlap
Cc: linuxppc-dev@lists.ozlabs.org
Fixes: 6db92c
New module which registers its memory allocation and free APIs to the
sram_dynamic module, which would create a device of struct sram_device
type to act as an interface for user level applications to access the
backend hardware device, fsl_85xx_cache_sram, which is drived by the
FSL_85XX_CACHE_SRAM
On Fri, Apr 24, 2020 at 02:54:06PM +0800, Shengjiu Wang wrote:
> Remove tasklet for it may cause the reset operation
> can't be handled immediately, then there will be
> endless xrun interrupt.
The reset routine is really long and expensive, so not sure
if it'd be good to do it completely inside H
The patch 955ac624058f: "ASoC: fsl_easrc: Add EASRC ASoC CPU DAI
drivers" from Apr 16, 2020, leads to the following Smatch complaint:
sound/soc/fsl/fsl_easrc.c:1529 fsl_easrc_hw_free()
warn: variable dereferenced before check 'ctx' (see line 1527)
sound/soc/fsl/fsl_easrc.c
1526 struct
On Fri, 17 Apr 2020 10:57:10 +1000
Michael Ellerman wrote:
> >>> Does it needs to be a BUG_ON() ? Can't we fail gracefully with just a
> >>> WARN_ON ?
> >>>
> >>
> >> I'm not sure what failing gracefully means here? The main reason this could
> >> fail is if there is not enough memory to alloc
On Thu, 23 Apr 2020 18:21:14 +0200
Christophe Leroy wrote:
> Le 23/04/2020 à 17:09, Naveen N. Rao a écrit :
> > With STRICT_KERNEL_RWX, we are currently ignoring return value from
> > __patch_instruction() in do_patch_instruction(), resulting in the error
> > not being propagated back. Fix the sa
On Thu, 23 Apr 2020 17:41:52 +0200
Christophe Leroy wrote:
> > diff --git a/arch/powerpc/kernel/optprobes.c
> > b/arch/powerpc/kernel/optprobes.c
> > index 024f7aad1952..046485bb0a52 100644
> > --- a/arch/powerpc/kernel/optprobes.c
> > +++ b/arch/powerpc/kernel/optprobes.c
> > @@ -139,52 +139,
> The patch 955ac624058f: "ASoC: fsl_easrc: Add EASRC ASoC CPU DAI
> drivers" from Apr 16, 2020, leads to the following Smatch complaint:
>
> sound/soc/fsl/fsl_easrc.c:1529 fsl_easrc_hw_free()
> warn: variable dereferenced before check 'ctx' (see line 1527)
Please avoid a typo in the final commit
Sam Bobroff writes:
> Export rtas_error_rc() so that it can be used by other users of
> rtas_call() (which is already exported).
This will do the right thing for your ibm,configure-pe use case in patch
2, but the -900x => errno translations in rtas_error_rc() appear
tailored for the indicator- an
Sam Bobroff writes:
> If a device is hot unplgged during EEH recovery, it's possible for the
> RTAS call to ibm,configure-pe in pseries_eeh_configure() to return
> parameter error (-3), however negative return values are not checked
> for and this leads to an infinite loop.
>
> Fix this by correct
Hi Jason,
Apologies for the delay in testing.
I'm seeing this problem when I try to boot on a t4240rdb:
random: get_random_u64 called from .start_kernel+0x734/0x964 with crng_init=0
[8/973]
clocksource: timebase: mask: 0x max_cycles: 0xa9210e89c,
m
Christophe Leroy wrote:
Le 23/04/2020 à 17:09, Naveen N. Rao a écrit :
With STRICT_KERNEL_RWX, we are currently ignoring return value from
__patch_instruction() in do_patch_instruction(), resulting in the error
not being propagated back. Fix the same.
Good patch.
Be aware that there is ongo
Hi Steve,
Steven Rostedt wrote:
On Thu, 23 Apr 2020 18:21:14 +0200
Christophe Leroy wrote:
Le 23/04/2020 à 17:09, Naveen N. Rao a écrit :
> With STRICT_KERNEL_RWX, we are currently ignoring return value from
> __patch_instruction() in do_patch_instruction(), resulting in the error
> not being
Steven Rostedt wrote:
On Thu, 23 Apr 2020 17:41:52 +0200
Christophe Leroy wrote:
> diff --git a/arch/powerpc/kernel/optprobes.c b/arch/powerpc/kernel/optprobes.c
> index 024f7aad1952..046485bb0a52 100644
> --- a/arch/powerpc/kernel/optprobes.c
> +++ b/arch/powerpc/kernel/optprobes.c
> @@ -13
On Fri, 24 Apr 2020 23:37:06 +0530
"Naveen N. Rao" wrote:
> >> Le 23/04/2020 à 17:09, Naveen N. Rao a écrit :
> >> > With STRICT_KERNEL_RWX, we are currently ignoring return value from
> >> > __patch_instruction() in do_patch_instruction(), resulting in the error
> >> > not being propagated bac
On Fri, 24 Apr 2020 23:56:25 +0530
"Naveen N. Rao" wrote:
> > #define PATCH_INSN(addr, instr) \
> > ({
> > int rc = patch_instruction((unsigned int *)(addr), instr); \
> > if (rc) \
> > pr_err("%s:%d Error
https://bugzilla.kernel.org/show_bug.cgi?id=199471
--- Comment #25 from Erhard F. (erhar...@mailbox.org) ---
(In reply to Michael Ellerman from comment #23)
> The memory leak is a separate issue, see bug #206695.
>
> Can anyone verify that bcf3588d8ed fixes the original issue?
Yes, thanks to Wolf
On Fri Apr 24, 2020 at 9:15 AM, Steven Rostedt wrote:
> On Thu, 23 Apr 2020 18:21:14 +0200
> Christophe Leroy wrote:
>
>
> > Le 23/04/2020 à 17:09, Naveen N. Rao a écrit :
> > > With STRICT_KERNEL_RWX, we are currently ignoring return value from
> > > __patch_instruction() in do_patch_instruction
Steven Rostedt wrote:
On Fri, 24 Apr 2020 23:56:25 +0530
"Naveen N. Rao" wrote:
> #define PATCH_INSN(addr, instr) \
> ({
>int rc = patch_instruction((unsigned int *)(addr), instr); \
>if (rc) \
>pr_err("
Since cbb961ca271e ("Use random MAC address when none is given")
Varisys Cyrus P5020 boards have been listing 5 ethernet ports instead of
the 2 the board has.This is because we were preventing the adding of the
unused ports by not suppling them a MAC address, which this patch now
supplies.
Prevent
On 4/24/2020 3:29 PM, Darren Stevens wrote:
> Since cbb961ca271e ("Use random MAC address when none is given")
> Varisys Cyrus P5020 boards have been listing 5 ethernet ports instead of
> the 2 the board has.This is because we were preventing the adding of the
> unused ports by not suppling them
On Thu, Apr 16, 2020 at 04:51:14PM -0500, Rob Herring wrote:
> Convert string compares of DT node names to use of_node_name_eq helper
> instead. This removes direct access to the node name pointer.
>
> Cc: Benjamin Herrenschmidt
> Cc: Paul Mackerras
> Cc: Michael Ellerman
> Cc: Bjorn Helgaas
>
Hi Jon,
I'm glad you raised this because I think the way we handle
FIRMWARE_FIRST is really screwed up.
On Mon, Apr 20, 2020 at 03:37:09PM -0600, Jon Derrick wrote:
> Some platforms have a mix of ports whose capabilities can be negotiated
> by _OSC, and some ports which are not described by ACPI
On Fri, Apr 24, 2020 at 11:29:38PM +0100, Darren Stevens wrote:
> Since cbb961ca271e ("Use random MAC address when none is given")
> Varisys Cyrus P5020 boards have been listing 5 ethernet ports instead of
> the 2 the board has.This is because we were preventing the adding of the
> unused ports by
Excerpts from Rich Felker's message of April 23, 2020 12:36 pm:
> On Wed, Apr 22, 2020 at 04:18:36PM +1000, Nicholas Piggin wrote:
>> Yeah I had a bit of a play around with musl (which is very nice code I
>> must say). The powerpc64 syscall asm is missing ctr clobber by the way.
>> Fortunately ad
Excerpts from Rich Felker's message of April 24, 2020 3:42 am:
> On Thu, Apr 23, 2020 at 02:15:58PM -0300, Adhemerval Zanella wrote:
>>
>>
>> On 23/04/2020 13:43, Rich Felker wrote:
>> > On Thu, Apr 23, 2020 at 01:35:01PM -0300, Adhemerval Zanella wrote:
>> >>
>> >>
>> >> On 23/04/2020 13:18, Ric
On Sat, Apr 25, 2020 at 01:40:24PM +1000, Nicholas Piggin wrote:
> Excerpts from Rich Felker's message of April 24, 2020 3:42 am:
> > On Thu, Apr 23, 2020 at 02:15:58PM -0300, Adhemerval Zanella wrote:
> >>
> >>
> >> On 23/04/2020 13:43, Rich Felker wrote:
> >> > On Thu, Apr 23, 2020 at 01:35:01P
As noted in the 'scv' thread, powerpc's vdso calling convention does not
match the C ELF ABI calling convention (or the proposed scv convention).
I think we could implement a new ABI by basically duplicating function
entry points with different names.
The ELF v2 ABI convention would suit it well,
On Sat, Apr 25, 2020 at 03:22:27PM +1000, Nicholas Piggin wrote:
> As noted in the 'scv' thread, powerpc's vdso calling convention does not
> match the C ELF ABI calling convention (or the proposed scv convention).
> I think we could implement a new ABI by basically duplicating function
> entry po
47 matches
Mail list logo
