Hi all,
Getting the following warning on linux-next from yesterday,
CC net/sunrpc/svcsock.o
net/sunrpc/svcsock.c:227:5: warning: "ARCH_IMPLEMENTS_FLUSH_DCACHE_PAGE"
is not defined [-Wundef]
#if ARCH_IMPLEMENTS_FLUSH_DCACHE_PAGE
^
Bisected to ca07eda33e01 (refs/bisect/bad)
On Thu, 2020-06-04 at 14:52 -0700, Kees Cook wrote:
> On Wed, Jun 03, 2020 at 04:04:31PM -0700, Joe Perches wrote:
> > On Wed, 2020-06-03 at 15:40 -0700, Kees Cook wrote:
> > > The IS_ENABLED() use was missing the CONFIG_ prefix which would have
> > > lead to skipping this code.
> > >
> > >
On Thu, Jun 04, 2020 at 06:06:39PM -0500, Segher Boessenkool wrote:
> On Thu, Jun 04, 2020 at 11:55:11PM +0200, Phil Blundell wrote:
> > 1a. Define your own subset of ELFv2 which is interworkable with the full
> > ABI at the function call interface but doesn't make all the same
> > guarantees
tree/branch: https://git.kernel.org/pub/scm/linux/kernel/git/powerpc/linux.git
next
branch HEAD: 1395375c592770fe5158a592944aaeed67fa94ff Merge branch
'topic/ppc-kvm' into next
elapsed time: 860m
configs tested: 99
configs skipped: 9
The following configs have been built successfully.
More
powerpc defconfig
i386 randconfig-a001-20200604
i386 randconfig-a006-20200604
i386 randconfig-a002-20200604
i386 randconfig-a005-20200604
i386 randconfig-a004-20200604
i386
On Thu, Jun 04, 2020 at 10:39:30PM +0200, Daniel Kolesa wrote:
> Is there *any* way I can take that would make upstreams of all parts
> of the toolchain happy? I explicitly don't want to go back to ELFv1.
> While at it, I'd like to transition to ld64 long double format, to
> match musl and
On Fri, Jun 5, 2020, at 01:35, Segher Boessenkool wrote:
> Hi!
>
> On Thu, Jun 04, 2020 at 11:43:53PM +0200, Daniel Kolesa wrote:
> > The thing is, I've yet to see in which way the ELFv2 ABI *actually*
> > requires VSX - I don't think compiling for 970 introduces any actual
> > differences.
> -Original Message-
> From: Vaibhav Jain
> Sent: Thursday, June 4, 2020 2:06 AM
> To: Williams, Dan J ; linuxppc-
> d...@lists.ozlabs.org; linux-nvd...@lists.01.org; linux-
> ker...@vger.kernel.org
> Cc: Santosh Sivaraj ; Aneesh Kumar K . V
> ; Steven Rostedt ;
> Oliver O'Halloran ;
Hi!
On Fri, Jun 05, 2020 at 12:26:22AM +0200, Daniel Kolesa wrote:
> Either way I'll think about it some more and possibly prepare an RFC port.
> I'm definitely willing to put in the work and later maintenance effort if
> that's what it takes to make it happen.
Yeah, you'll need to convince
This patch implements support for PDSM request 'PAPR_PDSM_HEALTH'
that returns a newly introduced 'struct nd_papr_pdsm_health' instance
containing dimm health information back to user space in response to
ND_CMD_CALL. This functionality is implemented in newly introduced
papr_pdsm_health() that
Hi!
On Thu, Jun 04, 2020 at 10:08:02PM +, Joseph Myers wrote:
> > The ELFv2 document specifies things like passing of quadruple precision
> > floats. Indeed, VSX is needed there, but that's not a concern if you
> > *don't* use quadruple precision floats.
>
> My understanding is that the
'seq_buf' provides a very useful abstraction for writing to a string
buffer without needing to worry about it over-flowing. However even
though the API has been stable for couple of years now its still not
exported to kernel loadable modules limiting its usage.
Hence this patch proposes update to
Since papr_scm_ndctl() can be called from outside papr_scm, its
exposed to the possibility of receiving NULL as value of 'cmd_rc'
argument. This patch updates papr_scm_ndctl() to protect against such
possibility by assigning it pointer to a local variable in case cmd_rc
== NULL.
Finally the patch
Implement support for fetching nvdimm health information via
H_SCM_HEALTH hcall as documented in Ref[1]. The hcall returns a pair
of 64-bit bitmap, bitwise-and of which is then stored in
'struct papr_scm_priv' and subsequently partially exposed to
user-space via newly introduced dimm specific
Introduce support for PAPR NVDIMM Specific Methods (PDSM) in papr_scm
module and add the command family NVDIMM_FAMILY_PAPR to the white list
of NVDIMM command sets. Also advertise support for ND_CMD_CALL for the
nvdimm command mask and implement necessary scaffolding in the module
to handle
Add documentation to 'papr_hcalls.rst' describing the bitmap flags
that are returned from H_SCM_HEALTH hcall as per the PAPR-SCM
specification.
Cc: "Aneesh Kumar K . V"
Cc: Dan Williams
Cc: Michael Ellerman
Cc: Ira Weiny
Acked-by: Ira Weiny
Signed-off-by: Vaibhav Jain
---
Changelog:
Changes since v9 [1]:
* Addressed review comments from Ira and Dan Williams.
* Removed the contentious 'payload_version' field from struct
nd_pdsm_cmd_pkg.
* Also removed code/defines related to handling of different version
of a pdsm payload struct.
* Consolidated validation checks for
Hi!
On Thu, Jun 04, 2020 at 11:43:53PM +0200, Daniel Kolesa wrote:
> The thing is, I've yet to see in which way the ELFv2 ABI *actually* requires
> VSX - I don't think compiling for 970 introduces any actual differences.
> There will be omissions, yes - but then the more accurate thing would be
Hi!
On Thu, Jun 04, 2020 at 11:55:11PM +0200, Phil Blundell wrote:
> 1a. Define your own subset of ELFv2 which is interworkable with the full
> ABI at the function call interface but doesn't make all the same
> guarantees about binary compatibility. That would mean that a binary
> built with
From: Valentin Longchamp
Date: Wed, 3 Jun 2020 23:28:23 +0200
> net/sch_generic.h does not need to be included, remove it.
>
> Signed-off-by: Valentin Longchamp
Applied.
On Fri, Jun 5, 2020, at 00:08, Joseph Myers wrote:
> On Thu, 4 Jun 2020, Daniel Kolesa wrote:
>
> > The ELFv2 document specifies things like passing of quadruple precision
> > floats. Indeed, VSX is needed there, but that's not a concern if you
> > *don't* use quadruple precision floats.
>
>
On Thu, 4 Jun 2020, Daniel Kolesa wrote:
> The ELFv2 document specifies things like passing of quadruple precision
> floats. Indeed, VSX is needed there, but that's not a concern if you
> *don't* use quadruple precision floats.
My understanding is that the registers used for argument passing
On Thu, Jun 4, 2020, at 23:55, Phil Blundell wrote:
> On Thu, Jun 04, 2020 at 10:39:30PM +0200, Daniel Kolesa wrote:
> > Is there *any* way I can take that would make upstreams of all parts
> > of the toolchain happy? I explicitly don't want to go back to ELFv1.
> > While at it, I'd like to
On Wed, Jun 03, 2020 at 04:04:31PM -0700, Joe Perches wrote:
> On Wed, 2020-06-03 at 15:40 -0700, Kees Cook wrote:
> > The IS_ENABLED() use was missing the CONFIG_ prefix which would have
> > lead to skipping this code.
> >
> > Fixes: 3ad1f3a33286 ("pwm: Implement some checks for lowlevel
On Thu, Jun 4, 2020, at 23:10, Segher Boessenkool wrote:
> Hi!
>
> On Thu, Jun 04, 2020 at 10:39:30PM +0200, Daniel Kolesa wrote:
> > On Thu, Jun 4, 2020, at 19:33, Segher Boessenkool wrote:
> > > It is the ABI. If you think it should be different, make your own ABI,
> > > don't pretend the
Hi!
On Thu, Jun 04, 2020 at 10:39:30PM +0200, Daniel Kolesa wrote:
> On Thu, Jun 4, 2020, at 19:33, Segher Boessenkool wrote:
> > It is the ABI. If you think it should be different, make your own ABI,
> > don't pretend the existing ABI is different than what it is. Thank you.
>
> Well then -
On Thu, Jun 4, 2020 at 1:46 PM Rich Felker wrote:
>
> On Thu, Jun 04, 2020 at 12:33:12PM -0500, Segher Boessenkool wrote:
> > On Thu, Jun 04, 2020 at 01:18:44PM -0400, Rich Felker wrote:
> > > On Thu, Jun 04, 2020 at 12:12:32PM -0500, Segher Boessenkool wrote:
> > > > On Tue, Jun 02, 2020 at
Hello Christophe,
I tested it on my Nemo board with a P.A. Semi PA6T CPU [1], on my Cyrus+ board
with a FSL P5040 CPU [2] and in a virtual e5500 QEMU machine. You can find the
kernel configs in the following package.
Link: http://www.xenosoft.de/linux-image-5.8-alpha1-X1000_X5000.tar.gz
Hi,
+
+The STATS_FS_HIDDEN attribute won't affect the aggregation, it will only
+block the creation of the files.
Why does HIDDEN block the creation of files? instead of their visibility?
The file itself is used to allow the user to view the content of a
value. In order to make it hidden,
On Thu, Jun 04, 2020 at 12:41:33PM +0300, Mike Rapoport wrote:
> On Wed, Jun 03, 2020 at 04:44:17PM -0700, Guenter Roeck wrote:
> >
> > sparc32 smp images in next-20200603 still crash for me with a spinlock
> > recursion. s390 images hang early in boot. Several others (alpha, arm64,
> > various
On Thu, Jun 4, 2020, at 19:33, Segher Boessenkool wrote:
> On Thu, Jun 04, 2020 at 01:18:44PM -0400, Rich Felker wrote:
> > On Thu, Jun 04, 2020 at 12:12:32PM -0500, Segher Boessenkool wrote:
> > > On Tue, Jun 02, 2020 at 05:13:25PM +0200, Daniel Kolesa wrote:
> > > > well, ppc64le already cannot
On Thu, Jun 04, 2020 at 06:57:03PM +0200, Peter Zijlstra wrote:
> I think I see, what happens is that these headers end up in the VDSO
> build, and that doesn't have these CFLAGS, because userspace.
>
> Let me see what to do about that.
I feel like the below is cheating, but it's the best I
On Thu, 4 Jun 2020 19:48:14 +0300 Mike Rapoport wrote:
> On Thu, Jun 04, 2020 at 09:44:46AM +0200, Joerg Roedel wrote:
> > From: Joerg Roedel
> >
> > The pud_alloc_track() needs to do different checks based on whether
> > __ARCH_HAS_5LEVEL_HACK is defined, like it already does in
> >
On Thu, Jun 04, 2020 at 03:00:51PM -0400, David Edelsohn wrote:
> On Thu, Jun 4, 2020 at 1:46 PM Rich Felker wrote:
> >
> > On Thu, Jun 04, 2020 at 12:33:12PM -0500, Segher Boessenkool wrote:
> > > On Thu, Jun 04, 2020 at 01:18:44PM -0400, Rich Felker wrote:
> > > > On Thu, Jun 04, 2020 at
When we enter into fadump crash path via system reset we fail to update
the pstore.
On the system reset path we first update the pstore then we go for fadump
crash. But the problem here is when all the CPUs try to get the pstore
lock to initiate the pstore write, only one CPUs will acquire the
Hi Ira,
Thanks again for looking into patch. My responses below:
Ira Weiny writes:
> On Thu, Jun 04, 2020 at 12:34:04AM +0530, Vaibhav Jain wrote:
>> Hi Ira,
>>
>> Thanks for reviewing this patch. My responses below:
>>
>> Ira Weiny writes:
>>
>> > On Tue, Jun 02, 2020 at 03:44:38PM +0530,
Ira Weiny writes:
> On Wed, Jun 03, 2020 at 11:41:42PM +0530, Vaibhav Jain wrote:
>> Hi Ira,
>>
>> Thanks for reviewing this patch. My responses below:
>>
>> Ira Weiny writes:
>>
>
> ...
>
>> >> + *
>> >> + * Payload Version:
>> >> + *
>> >> + * A 'payload_version' field is present in PDSM
On Thu, Jun 04, 2020 at 09:44:46AM +0200, Joerg Roedel wrote:
> From: Joerg Roedel
>
> The pud_alloc_track() needs to do different checks based on whether
> __ARCH_HAS_5LEVEL_HACK is defined, like it already does in
> pud_alloc(). Otherwise it causes boot failures on PowerPC.
>
> Provide the
On Thu, Jun 04, 2020 at 12:33:12PM -0500, Segher Boessenkool wrote:
> On Thu, Jun 04, 2020 at 01:18:44PM -0400, Rich Felker wrote:
> > On Thu, Jun 04, 2020 at 12:12:32PM -0500, Segher Boessenkool wrote:
> > > On Tue, Jun 02, 2020 at 05:13:25PM +0200, Daniel Kolesa wrote:
> > > > well, ppc64le
On Thu, Jun 04, 2020 at 01:18:44PM -0400, Rich Felker wrote:
> On Thu, Jun 04, 2020 at 12:12:32PM -0500, Segher Boessenkool wrote:
> > On Tue, Jun 02, 2020 at 05:13:25PM +0200, Daniel Kolesa wrote:
> > > well, ppc64le already cannot be run on those, as far as I know (I
> > > don't think it's
On Tue, Jun 02, 2020 at 05:27:24PM +0200, Michal Suchánek wrote:
> Naturally on POWER the first cpu that has LE support is POWER8 so you
> can count on all other POWER8 features to be present.
This is not true.
The oldest CPU the ELFv2 ABI (and so, powerpc64le-linux) supports is
POWER8, but most
On Thu, Jun 04, 2020 at 12:12:32PM -0500, Segher Boessenkool wrote:
> On Tue, Jun 02, 2020 at 05:13:25PM +0200, Daniel Kolesa wrote:
> > well, ppc64le already cannot be run on those, as far as I know (I
> > don't think it's possible to build ppc64le userland without VSX in
> > any configuration)
>
Le 04/06/2020 à 17:53, Christian Zigotzky a écrit :
On 4. Jun 2020, at 16:29, Christophe Leroy wrote:
And are you able to perform a 'git bisect' to identify the guilty commit ?
Thanks
Christophe
Hello Christophe,
Unfortunately I haven’t had time to bisect the latest Git kernel. Does
On Tue, Jun 02, 2020 at 05:13:25PM +0200, Daniel Kolesa wrote:
> well, ppc64le already cannot be run on those, as far as I know (I don't think
> it's possible to build ppc64le userland without VSX in any configuration)
VSX is required by the ELFv2 ABI:
"""
Specifically, to use this ABI and
On Thu, Jun 4, 2020 at 6:49 PM Mike Rapoport wrote:
>
> On Thu, Jun 04, 2020 at 09:44:46AM +0200, Joerg Roedel wrote:
> > From: Joerg Roedel
> >
> > The pud_alloc_track() needs to do different checks based on whether
> > __ARCH_HAS_5LEVEL_HACK is defined, like it already does in
> > pud_alloc().
On Fri, May 29, 2020 at 04:29:17PM -0700, David Miller wrote:
> From: Peter Zijlstra
> Date: Fri, 29 May 2020 23:35:51 +0200
>
> > ../arch/sparc/include/asm/percpu_64.h:7:24: warning: call-clobbered
> > register used for global register variable
> > register unsigned long __local_per_cpu_offset
On Thu, Jun 04, 2020 at 09:44:46AM +0200, Joerg Roedel wrote:
> From: Joerg Roedel
>
> The pud_alloc_track() needs to do different checks based on whether
> __ARCH_HAS_5LEVEL_HACK is defined, like it already does in
> pud_alloc(). Otherwise it causes boot failures on PowerPC.
>
> Provide the
[+Arnd since I think we spoke about this on IRC once]
On Thu, Jun 04, 2020 at 02:35:14PM +, Christophe Leroy wrote:
> Now I get the same issue at
>
>CC mm/mincore.o
> In file included from ./include/asm-generic/bug.h:5:0,
> from ./arch/powerpc/include/asm/bug.h:109,
> On 4. Jun 2020, at 16:29, Christophe Leroy
> wrote:
>
> And are you able to perform a 'git bisect' to identify the guilty commit ?
>
> Thanks
> Christophe
Hello Christophe,
Unfortunately I haven’t had time to bisect the latest Git kernel. Does it boot
on your PowerPC machine?
Thanks,
On 06/04/2020 12:00 PM, Peter Zijlstra wrote:
On Thu, Jun 04, 2020 at 12:17:23PM +0100, Will Deacon wrote:
Hi, [+Peter]
On Thu, Jun 04, 2020 at 10:48:03AM +, Christophe Leroy wrote:
Using mpc885_ads_defconfig with CONFIG_PPC_16K_PAGES instead of
CONFIG_PPC_4K_PAGES, getting the
Le 04/06/2020 à 16:26, Christophe Leroy a écrit :
Hi,
Le 04/06/2020 à 16:16, Christian Zigotzky a écrit :
Hi All,
I tested the latest Git kernel today. [1]. Unfortunately it doesn't
boot on my PowerPC machines.
Could you please test the latest Git kernel with your PowerPC machine?
Hi,
Le 04/06/2020 à 16:16, Christian Zigotzky a écrit :
Hi All,
I tested the latest Git kernel today. [1]. Unfortunately it doesn't boot
on my PowerPC machines.
Could you please test the latest Git kernel with your PowerPC machine?
BTW, it doesn't boot in a virtual QEMU PowerPC machine
Hi All,
I tested the latest Git kernel today. [1]. Unfortunately it doesn't boot
on my PowerPC machines.
Could you please test the latest Git kernel with your PowerPC machine?
BTW, it doesn't boot in a virtual QEMU PowerPC machine either.
Thanks,
Christian
[1]
On Thu, 4 Jun 2020 14:25:30 +0800, Shengjiu Wang wrote:
> Defer probe when fail to find codec device, because the codec
> device maybe probed later than machine driver.
Applied to
https://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git for-next
Thanks!
[1/1] ASoC: fsl-asoc-card:
On 06/04/2020 11:17 AM, Will Deacon wrote:
Hi, [+Peter]
On Thu, Jun 04, 2020 at 10:48:03AM +, Christophe Leroy wrote:
Using mpc885_ads_defconfig with CONFIG_PPC_16K_PAGES instead of
CONFIG_PPC_4K_PAGES, getting the following build failure:
CC mm/gup.o
In file included from
The Power ISA mandates that all writes to the Authority
Mask Register (AMR) must always be preceded as well as
succeeded by a context synchronizing instruction.
This makes sure that the tests follow this requirement
when attempting to update a pkey's access rights.
Signed-off-by: Sandipan Das
Apart from read and write access, memory protection keys can
also be used for restricting execute permission of pages on
powerpc. This adds a test to verify if the feature works as
expected.
Signed-off-by: Sandipan Das
---
tools/testing/selftests/powerpc/mm/.gitignore | 1 +
This moves a function to test if the MMU is in Hash mode
under the generic test utilities.
Signed-off-by: Sandipan Das
---
.../testing/selftests/powerpc/include/utils.h | 1 +
tools/testing/selftests/powerpc/mm/Makefile | 2 +-
.../selftests/powerpc/mm/bad_accesses.c | 28
This fixes the way the Authority Mask Register (AMR) is updated
by the existing pkey tests and adds a new test to verify the
functionality of execute-disabled pkeys.
Previous versions can be found at:
v2:
https://lore.kernel.org/linuxppc-dev/20200527030342.13712-1-sandi...@linux.ibm.com/
v1:
Stephen Rothwell writes:
> Hi all,
>
> On Thu, 4 Jun 2020 16:52:46 +1000 Stephen Rothwell
> wrote:
>>
>> diff --git a/arch/powerpc/mm/kasan/8xx.c b/arch/powerpc/mm/kasan/8xx.c
>> index db4ef44af22f..569d98a41881 100644
>> --- a/arch/powerpc/mm/kasan/8xx.c
>> +++ b/arch/powerpc/mm/kasan/8xx.c
>>
On Thu, Jun 04, 2020 at 12:17:23PM +0100, Will Deacon wrote:
> Hi, [+Peter]
>
> On Thu, Jun 04, 2020 at 10:48:03AM +, Christophe Leroy wrote:
> > Using mpc885_ads_defconfig with CONFIG_PPC_16K_PAGES instead of
> > CONFIG_PPC_4K_PAGES, getting the following build failure:
> >
> > CC
On Tue, May 5, 2020 at 3:07 AM David Rientjes wrote:
>
> On Mon, 4 May 2020, Emanuele Giuseppe Esposito wrote:
>
> > There is currently no common way for Linux kernel subsystems to expose
> > statistics to userspace shared throughout the Linux kernel; subsystems
> > have to take care of gathering
Stephen Rothwell writes:
> Hi all,
>
> On Thu, 4 Jun 2020 16:52:46 +1000 Stephen Rothwell
> wrote:
>>
>> diff --git a/arch/powerpc/include/asm/book3s/64/pgtable.h
>> b/arch/powerpc/include/asm/book3s/64/pgtable.h
>> index 25c3cb8272c0..a6799723cd98 100644
>> ---
Hi all,
On Thu, 4 Jun 2020 17:49:25 +1000 Stephen Rothwell
wrote:
>
> diff --cc arch/powerpc/include/asm/nohash/32/pgtable.h
> index 639f3b3713ec,eb8538c85077..1927e1b653f2
> --- a/arch/powerpc/include/asm/nohash/32/pgtable.h
> +++ b/arch/powerpc/include/asm/nohash/32/pgtable.h
> @@@ -342,15
Hi, [+Peter]
On Thu, Jun 04, 2020 at 10:48:03AM +, Christophe Leroy wrote:
> Using mpc885_ads_defconfig with CONFIG_PPC_16K_PAGES instead of
> CONFIG_PPC_4K_PAGES, getting the following build failure:
>
> CC mm/gup.o
> In file included from ./include/linux/kernel.h:11:0,
>
Hi all,
On Thu, 4 Jun 2020 17:49:25 +1000 Stephen Rothwell
wrote:
>
> diff --cc arch/powerpc/include/asm/nohash/32/pgtable.h
> index 639f3b3713ec,eb8538c85077..1927e1b653f2
> --- a/arch/powerpc/include/asm/nohash/32/pgtable.h
> +++ b/arch/powerpc/include/asm/nohash/32/pgtable.h
> @@@ -204,13
Hi all,
Using mpc885_ads_defconfig with CONFIG_PPC_16K_PAGES instead of
CONFIG_PPC_4K_PAGES, getting the following build failure:
CC mm/gup.o
In file included from ./include/linux/kernel.h:11:0,
from mm/gup.c:2:
In function 'gup_hugepte.constprop',
inlined from
> On Jun 3, 2020, at 3:05 PM, Andrew Morton wrote:
>
> A bunch of new material just landed in linux-next/powerpc.
>
> The timing is awkward! I trust this will be going into mainline during
> this merge window? If not, please drop it and repull after -rc1.
I have noticed the same pattern
On Wed, Jun 03, 2020 at 04:44:17PM -0700, Guenter Roeck wrote:
>
> sparc32 smp images in next-20200603 still crash for me with a spinlock
> recursion. s390 images hang early in boot. Several others (alpha, arm64,
> various ppc) don't even compile. I can run some more bisects over time,
> but this
On 6/3/20 11:22 PM, Ira Weiny wrote:
[ ... ]
>
> s390: (does not compile)
>
> :1511:2: warning: #warning syscall clone3 not implemented [-Wcpp]
> In file included from ./arch/sparc/include/asm/bug.h:6:0,
> from ./include/linux/bug.h:5,
> from
Hi Dan,
Thanks for review and insights on this. My responses below:
"Williams, Dan J" writes:
> [ forgive formatting I'm temporarily stuck using Outlook this week... ]
>
>> From: Vaibhav Jain
> [..]
>>
>> Introduce support for PAPR NVDIMM Specific Methods (PDSM) in papr_scm
>> module and add
On Wed, 3 Jun 2020 at 19:03, Joerg Roedel wrote:
>
> On Wed, Jun 03, 2020 at 04:20:57PM +0530, Abdul Haleem wrote:
> > @Joerg, Could you please have a look?
>
> Can you please try the attached patch?
@Joerg, Linaro test farm noticed this kernel crash on nxp ls2088
Machine model: Freescale
On 2020/5/29 15:41, Luis Chamberlain wrote:
This moves the binfmt_misc sysctl to its own file to help remove
clutter from kernel/sysctl.c.
Signed-off-by: Luis Chamberlain
---
fs/binfmt_misc.c | 1 +
kernel/sysctl.c | 7 ---
2 files changed, 1 insertion(+), 7 deletions(-)
diff --git
Hi all,
On Thu, 4 Jun 2020 16:52:46 +1000 Stephen Rothwell
wrote:
>
> diff --git a/arch/powerpc/mm/kasan/8xx.c b/arch/powerpc/mm/kasan/8xx.c
> index db4ef44af22f..569d98a41881 100644
> --- a/arch/powerpc/mm/kasan/8xx.c
> +++ b/arch/powerpc/mm/kasan/8xx.c
> @@ -10,7 +10,7 @@
> static int __init
Hi all,
On Thu, 4 Jun 2020 16:52:46 +1000 Stephen Rothwell
wrote:
>
> diff --git a/arch/powerpc/include/asm/book3s/64/pgtable.h
> b/arch/powerpc/include/asm/book3s/64/pgtable.h
> index 25c3cb8272c0..a6799723cd98 100644
> --- a/arch/powerpc/include/asm/book3s/64/pgtable.h
> +++
On 30/3/20 7:34 pm, Frederic Barrat wrote:
From: Philippe Bergheaud
Some opencapi FPGA images allow to control if the FPGA should be reloaded
on the next adapter reset. If it is supported, the image specifies it
through a Vendor Specific DVSEC in the config space of function 0.
Signed-off-by:
From: Joerg Roedel
The pud_alloc_track() needs to do different checks based on whether
__ARCH_HAS_5LEVEL_HACK is defined, like it already does in
pud_alloc(). Otherwise it causes boot failures on PowerPC.
Provide the correct implementations for both possible settings of
__ARCH_HAS_5LEVEL_HACK
Hi all,
On Thu, 4 Jun 2020 16:52:46 +1000 Stephen Rothwell
wrote:
>
> diff --git a/arch/powerpc/include/asm/nohash/32/pgtable.h
> b/arch/powerpc/include/asm/nohash/32/pgtable.h
> index c188a6f64bcd..1927e1b653f2 100644
> --- a/arch/powerpc/include/asm/nohash/32/pgtable.h
> +++
Hi all,
On Wed, 3 Jun 2020 20:26:55 +1000 Stephen Rothwell
wrote:
>
> Some things turned up in the powerpc tree today that required some changes
> to patches in the akpm tree and also the following fixup patch provided
> (mostly) by Michael. I have applied this as a single patch today, but
>
On Thu, Jun 04, 2020 at 09:37:45AM +0300, Mike Rapoport wrote:
> On Wed, Jun 03, 2020 at 11:22:26PM -0700, Ira Weiny wrote:
> > On Wed, Jun 03, 2020 at 04:44:17PM -0700, Guenter Roeck wrote:
> >
> > With linux-next on sparc I too see the spinlock issue; something like:
> >
> > ...
> > Starting
On Thu, Jun 04, 2020 at 09:18:05AM +0300, Mike Rapoport wrote:
> On Wed, Jun 03, 2020 at 04:44:17PM -0700, Guenter Roeck wrote:
> > On 6/3/20 2:14 PM, Ira Weiny wrote:
> > > On Wed, Jun 03, 2020 at 01:57:36PM -0700, Andrew Morton wrote:
> > >> On Thu, 21 May 2020 10:42:50 -0700 Ira Weiny wrote:
>
On Wed, Jun 03, 2020 at 11:22:26PM -0700, Ira Weiny wrote:
> On Wed, Jun 03, 2020 at 04:44:17PM -0700, Guenter Roeck wrote:
>
> With linux-next on sparc I too see the spinlock issue; something like:
>
> ...
> Starting syslogd: BUG: spinlock recursion on CPU#0, S01syslogd/139
> lock: 0xf53ef350,
Defer probe when fail to find codec device, because the codec
device maybe probed later than machine driver.
Signed-off-by: Shengjiu Wang
---
sound/soc/fsl/fsl-asoc-card.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/sound/soc/fsl/fsl-asoc-card.c
On Wed, Jun 03, 2020 at 04:44:17PM -0700, Guenter Roeck wrote:
> On 6/3/20 2:14 PM, Ira Weiny wrote:
> > On Wed, Jun 03, 2020 at 01:57:36PM -0700, Andrew Morton wrote:
> >> On Thu, 21 May 2020 10:42:50 -0700 Ira Weiny wrote:
> >>
...
> >>
> >> This all petered out, but as I understand it, this
On Wed, Jun 03, 2020 at 04:44:17PM -0700, Guenter Roeck wrote:
> On 6/3/20 2:14 PM, Ira Weiny wrote:
> > On Wed, Jun 03, 2020 at 01:57:36PM -0700, Andrew Morton wrote:
> >> On Thu, 21 May 2020 10:42:50 -0700 Ira Weiny wrote:
> >>
> >
> > Actually it occurs to me that the patch
On Wed, 2020-06-03 at 15:32 +0200, Joerg Roedel wrote:
> On Wed, Jun 03, 2020 at 04:20:57PM +0530, Abdul Haleem wrote:
> > @Joerg, Could you please have a look?
>
> Can you please try the attached patch?
Thanks Joerg, The given patch fixes the boot problem.
Please add Reported-by in fix commit.
86 matches
Mail list logo
