OK, thanks.
> On 18. May 2020, at 04:40, Michael Ellerman wrote:
>
> Christian Zigotzky writes:
>> Hi All,
>>
>> This patch wasn't included in the PowerPC fixes 5.7-4. Please add it.
>
> It's not an important bug. I'll take the patch for v5.8
>
> cheers
>
>>> On 29 April 2020 at 09:02 am
Emil Velikov writes:
> As mentioned in earlier commit, the riva and nvidia fbdev drivers have
> seen no love over the years, are short on features and overall below par
>
> Users are encouraged to switch to the nouveau drm driver instead.
>
> v2: Split configs to separate patch, enable nouveau (Ba
In the function fsl_micfil_startup(), the two lines of dev_err()
can be shortened to one line. And delete unused initialized value
of 'ret', because it will be assigned by the function
fsl_micfil_set_mclk_rate().
Signed-off-by: Tang Bin
---
sound/soc/fsl/fsl_micfil.c | 5 ++---
1 file changed, 2
On Mon, Apr 13, 2020 at 12:06:45PM -0700, Nathan Chancellor wrote:
> A 0day randconfig uncovered an error with clang, trimmed for brevity:
>
> arch/powerpc/platforms/embedded6xx/wii.c:195:7: error: attribute
> declaration must precede definition [-Werror,-Wignored-attributes]
> if (!machin
On Mon, May 18, 2020 at 03:44:05PM +0800, Tang Bin wrote:
> In the function fsl_micfil_startup(), the two lines of dev_err()
> can be shortened to one line. And delete unused initialized value
> of 'ret', because it will be assigned by the function
> fsl_micfil_set_mclk_rate().
This is two separat
On Mon, 2 Mar 2020, Christophe Leroy wrote:
> > Include linux/io.h into fsl_85xx_cache_sram.c to fix the
> > implicit-declaration compile errors when building Cache-Sram.
> >
> > arch/powerpc/sysdev/fsl_85xx_cache_sram.c: In function
> > ‘instantiate_cache_sram’:
> > arch/powerpc/sysdev/fsl_85xx_
On Mon, 18 May 2020, Jiri Kosina wrote:
> > > Include linux/io.h into fsl_85xx_cache_sram.c to fix the
> > > implicit-declaration compile errors when building Cache-Sram.
> > >
> > > arch/powerpc/sysdev/fsl_85xx_cache_sram.c: In function
> > > ‘instantiate_cache_sram’:
> > > arch/powerpc/sysdev/f
Le 18/05/2020 à 12:32, Jiri Kosina a écrit :
On Mon, 18 May 2020, Jiri Kosina wrote:
Include linux/io.h into fsl_85xx_cache_sram.c to fix the
implicit-declaration compile errors when building Cache-Sram.
arch/powerpc/sysdev/fsl_85xx_cache_sram.c: In function
‘instantiate_cache_sram’:
arch/p
On 2020/5/18 18:25, Mark Brown wrote:
On Mon, May 18, 2020 at 03:44:05PM +0800, Tang Bin wrote:
In the function fsl_micfil_startup(), the two lines of dev_err()
can be shortened to one line. And delete unused initialized value
of 'ret', because it will be assigned by the function
fsl_micfil_se
In the function fsl_micfil_startup(), the two lines of dev_err()
can be shortened to one line.
Signed-off-by: Tang Bin
---
sound/soc/fsl/fsl_micfil.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/sound/soc/fsl/fsl_micfil.c b/sound/soc/fsl/fsl_micfil.c
index f7f2d29f1..79c
Hi Benjamin,
On Mon, 18 May 2020 at 01:45, Benjamin Herrenschmidt
wrote:
>
> On Sun, 2020-05-17 at 23:05 +0100, Emil Velikov wrote:
> > As mentioned in earlier commit, the riva and nvidia fbdev drivers
> > have
> > seen no love over the years, are short on features and overall below
> > par
> >
>
Update papr_scm.c to query dimm performance statistics from PHYP via
H_SCM_PERFORMANCE_STATS hcall and export them to userspace as PAPR
specific NVDIMM attribute 'perf_stats' in sysfs. The patch also
provide a sysfs ABI documentation for the stats being reported and
their meanings.
During NVDIMM p
The patch-set proposes to add support for fetching and reporting
performance statistics for PAPR compliant NVDIMMs as described in
documentation for H_SCM_PERFORMANCE_STATS hcall Ref[1]. The patch-set
also implements mechanisms to expose NVDIMM performance stats via
sysfs and newly introduced PDSMs
Add support for pdsm PAPR_SCM_PDSM_FETCH_PERF_STATS that issues HCALL
H_SCM_PERFORMANCE_STATS to PHYP to fetch all the NVDIMM performance
stats and store them in per nvdimm 'struct papr_scm_priv' as member
'perf_stats'. A further PDSM request (introduced later) is needed to
read the contents of thi
Implement support for pdsm READ_PERF_STATS to be used by libndctl to
fetch all NVDIMM performance statistics. The stats are to be exchanged
via newly introduced 'struct nd_pdsm_get_perf_stats' which is
allocated and sent by libndctl to papr_scm. The struct contains
members 'in_offset' and 'in_lengt
This patch adds support for retrieving a singled NVDIMM performance
stat from PHYP via PDSM GET_PERF_STAT_VERSION. A new uapi 'struct
nd_pdsm_get_perf_stat' is introduced that holds a single performance
stat and is populated by newly introduced papr_scm_get_perf_stat() by
issuing an H_SCM_PERFORMAN
Delete unused initialized value of 'ret', because it will
be assigned by the function fsl_micfil_set_mclk_rate().
Signed-off-by: Tang Bin
---
sound/soc/fsl/fsl_micfil.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/sound/soc/fsl/fsl_micfil.c b/sound/soc/fsl/fsl_micfil.c
ind
[Resending since I messed up the subject, sorry]
Hi, everyone,
Something went wrong between Linux 5.6 and 5.7-rc1. This is an iBook
G4 laptop with 1.5 GiB of RAM running the Debian powerpc port. I
haven't bisected yet, since it's going to take quite a bit of time, so
I'm sending this mostly as a
Hi Michael,
On Mon, 18 May 2020 at 08:30, Michael Ellerman wrote:
>
> Emil Velikov writes:
> > As mentioned in earlier commit, the riva and nvidia fbdev drivers have
> > seen no love over the years, are short on features and overall below par
> >
> > Users are encouraged to switch to the nouveau
Hi, everyone,
I strongly suspect something went wrong between Linux 5.6 and 5.7-rc1.
This is an iBook G4 laptop with 1.5 GiB of RAM running the Debian
powerpc port. I haven't bisected yet, since it's going to take quite a
bit of time, so I'm sending this mostly as a heads-up (and to see if
anybody
Jiri Kosina writes:
> On Mon, 18 May 2020, Jiri Kosina wrote:
>> > > Include linux/io.h into fsl_85xx_cache_sram.c to fix the
>> > > implicit-declaration compile errors when building Cache-Sram.
>> > >
>> > > arch/powerpc/sysdev/fsl_85xx_cache_sram.c: In function
>> > > ‘instantiate_cache_sram’:
Hi,
Le 18/05/2020 à 13:20, Rui Salvaterra a écrit :
[Resending since I messed up the subject, sorry]
Hi, everyone,
Something went wrong between Linux 5.6 and 5.7-rc1. This is an iBook
G4 laptop with 1.5 GiB of RAM running the Debian powerpc port. I
haven't bisected yet, since it's going to tak
Patchset fixes the inconsistent results we are getting when
we run multiple 24x7 events.
"hv_24x7" pmu interface events needs system dependent parameter
like socket/chip/core. For example, hv_24x7 chip level events needs
specific chip-id to which the data is requested should be added as part
of pm
Commit 2b206ee6b0df ("powerpc/perf/hv-24x7: Display change in counter
values")' added to print _change_ in the counter value rather then raw
value for 24x7 counters. Incase of transactions, the event count
is set to 0 at the beginning of the transaction. It also sets
the event's prev_count to the r
For hv_24x7 socket/chip level events, specific chip-id to which
the data requested should be added as part of pmu events.
But number of chips/socket in the system details are not exposed.
Patch implements read_sys_info_pseries() to get system
parameter values like number of sockets, cores per chip
Function 'read_sys_info_pseries()' is added to get system parameter
values like number of sockets and chips per socket.
and it gets these details via rtas_call with token
"PROCESSOR_MODULE_INFO".
Incase lpar migrate from one system to another, system
parameter details like chips per sockets or num
To expose the system dependent parameter like total number of
sockets and numbers of chips per socket, patch adds two sysfs files.
"sockets" and "chips" are added to /sys/devices/hv_24x7/interface/
of the "hv_24x7" pmu.
Signed-off-by: Kajol Jain
---
arch/powerpc/perf/hv-24x7.c | 24 +
Add documentation for the following sysfs files:
/sys/devices/hv_24x7/interface/chipspersocket,
/sys/devices/hv_24x7/interface/sockets,
/sys/devices/hv_24x7/interface/coresperchip
Signed-off-by: Kajol Jain
---
.../sysfs-bus-event_source-devices-hv_24x7| 21 +++
1 file changed
Hi!
On Mon, May 18, 2020 at 04:35:22PM +1000, Michael Ellerman wrote:
> Nicholas Piggin writes:
> > Provide an option to build big-endian kernels using the ELF V2 ABI. This
> > works
> > on GCC and clang (since about 2014). it is is not officially supported by
> > the
> > GNU toolchain, but it
On Mon, 2020-05-18 at 12:00 +0100, Emil Velikov wrote:
> I believe you reported issues due to different page size for the CPU/GPU.
> Have you tried nouveau recently, there has been a handful of patches
> on the topic since your report.
>
> Alternatively, it would make sense you rebase, cleanup and
On Mon, 2020-05-18 at 12:19 +0100, Emil Velikov wrote:
>
> - attempted out-of-bound attempts to read the vbios
So on these things, the actual ROM doesn't contain what you want, but
the device-tree has a property "NVDA,BMP" that contains some kind of
mini-BIOS (around 2.4KB) which should contain
On 5/18/20 1:19 PM, Emil Velikov wrote:
> Hi Michael,
>
> On Mon, 18 May 2020 at 08:30, Michael Ellerman wrote:
>>
>> Emil Velikov writes:
>>> As mentioned in earlier commit, the riva and nvidia fbdev drivers have
>>> seen no love over the years, are short on features and overall below par
>>>
+++ Christoph Hellwig [15/05/20 16:36 +0200]:
flush_icache_range generally operates on kernel addresses, but for some
reason m68k needed a set_fs override. Move that into the m68k code
insted of keeping it in the module loader.
Signed-off-by: Christoph Hellwig
Reviewed-by: Geert Uytterhoeven
On Mon, 18 May 2020 at 13:48, Bartlomiej Zolnierkiewicz
wrote:
>
>
> On 5/18/20 1:19 PM, Emil Velikov wrote:
> > Hi Michael,
> >
> > On Mon, 18 May 2020 at 08:30, Michael Ellerman wrote:
> >>
> >> Emil Velikov writes:
> >>> As mentioned in earlier commit, the riva and nvidia fbdev drivers have
>
[ Cc += linuxppc-dev ]
Nathan Chancellor writes:
> On Thu, May 14, 2020 at 08:13:48AM +0800, kbuild test robot wrote:
>> tree: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
>> master
>> head: 24085f70a6e1b0cb647ec92623284641d8270637
>> commit: 5990cdee689c6885b27c6d969a3
On Mai 18 2020, Michael Ellerman wrote:
> The old drivers may be crufty but they presumably have been tested by
> people and at least somewhat work.
I can confirm that the nvidia fbdev driver is working perfectly fine.
> I gave it a quick spin on a G5 I have access to and dmesg has a bunch of
>
Hi
On 05/18/2020 01:25 PM, Rui Salvaterra wrote:
Hi, Christophe,
On Mon, 18 May 2020 at 12:50, Christophe Leroy
wrote:
Can you provide your .config, tell which GCC version you are using, and
tell a bit more about your config: amount of RAM, is there swap, etc ...
Ok, so this laptop has 1.5
Hi again, Christophe,
On Mon, 18 May 2020 at 15:03, Christophe Leroy
wrote:
>
> Can you try reverting 697ece78f8f749aeea40f2711389901f0974017a ? It may
> have broken swap.
Yeah, that was a good call. :) Linux 5.7-rc1 with the revert on top
survives the beating. I'll be happy to test a definitive
On Sun, May 17, 2020 at 08:49:39PM -0700, Ira Weiny wrote:
[ ... ]
> >
> > ---
> > # bad: [bdecf38f228bcca73b31ada98b5b7ba1215eb9c9] Add linux-next specific
> > files for 20200515
> > # good: [2ef96a5bb12be62ef75b5828c0aab838ebb29cb8] Linux 5.7-rc5
> > git bisect start 'HEAD' 'v5.7-rc5'
> > # g
On Mon, 18 May 2020 18:59:51 +0800, Tang Bin wrote:
> In the function fsl_micfil_startup(), the two lines of dev_err()
> can be shortened to one line.
Applied to
https://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git for-5.8
Thanks!
[1/1] ASoC: fsl_micfil: Fix indentation to put o
On Mon, 18 May 2020 19:00:40 +0800, Tang Bin wrote:
> Delete unused initialized value of 'ret', because it will
> be assigned by the function fsl_micfil_set_mclk_rate().
Applied to
https://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git for-5.8
Thanks!
[1/1] ASoC: fsl_micfil: Fix u
Le 18/05/2020 à 17:19, Rui Salvaterra a écrit :
Hi again, Christophe,
On Mon, 18 May 2020 at 15:03, Christophe Leroy
wrote:
Can you try reverting 697ece78f8f749aeea40f2711389901f0974017a ? It may
have broken swap.
Yeah, that was a good call. :) Linux 5.7-rc1 with the revert on top
surviv
On Mon, 18 May 2020 at 18:15, Christophe Leroy
wrote:
>
> Yeah I discovered recently that the way swap is implemented on powerpc
> expects RW and other important bits not be one of the 3 least
> significant bits (see __pte_to_swp_entry() )
I see, you get the swap entry by shifting the PTE right t
This causes a build error with CONFIG_WALNUT because kb_cs and kb_data
were removed in commit 917f0af9e5a9 ("powerpc: Remove arch/ppc and
include/asm-ppc").
ld.lld: error: undefined symbol: kb_cs
> referenced by i8042-ppcio.h:28 (drivers/input/serio/i8042-ppcio.h:28)
> input/serio/i8042.o:(__i8042
On Sun, May 17, 2020 at 09:29:32PM -0700, Guenter Roeck wrote:
> On Sun, May 17, 2020 at 08:49:39PM -0700, Ira Weiny wrote:
> > On Sat, May 16, 2020 at 03:33:06PM -0700, Guenter Roeck wrote:
> > > On Thu, May 07, 2020 at 07:59:55AM -0700, ira.we...@intel.com wrote:
> > > > From: Ira Weiny
> > > >
On Sun, May 17, 2020 at 10:37:22AM -0700, Guenter Roeck wrote:
> Hi,
>
> On Thu, May 07, 2020 at 07:59:58AM -0700, ira.we...@intel.com wrote:
> > From: Ira Weiny
> >
> > To support kmap_atomic_prot(), all architectures need to support
> > protections passed to their kmap_atomic_high() function.
On Fri, 2020-05-15 at 16:36 +0200, Christoph Hellwig wrote:
> C6x needs almost no cache flushing routines of its own. Rely on
> asm-generic/cacheflush.h for the defaults.
>
> Signed-off-by: Christoph Hellwig
> ---
> arch/c6x/include/asm/cacheflush.h | 19 +--
> 1 file changed, 1
From: Ira Weiny
The kunmap_atomic clean up failed to remove one set of pagefault/preempt
enables when vaddr is not in the fixmap.
Fixes: bee2128a09e6 ("arch/kunmap_atomic: consolidate duplicate code")
Signed-off-by: Ira Weiny
---
arch/microblaze/mm/highmem.c | 5 +
arch/mips/mm/highmem.c
On 5/12/20 4:05 PM, Rob Herring wrote:
On Wed, May 06, 2020 at 10:50:04PM -0700, Prakhar Srivastava wrote:
Hi Mark,
Please don't top post.
This patch set currently only address the Pure DT implementation.
EFI and ACPI implementations will be posted in subsequent patchsets.
The logs are i
On 5/12/20 4:09 PM, Rob Herring wrote:
On Mon, May 04, 2020 at 01:38:28PM -0700, Prakhar Srivastava wrote:
Introduce a device tree layer for to read and store ima buffer
from the reserved memory section of a device tree.
But why do I need 'a layer of abstraction'? I don't like them.
This
Hi Mike and Baoquan,
On 4/22/20 6:13 PM, Baoquan He wrote:
On 04/12/20 at 10:48pm, Mike Rapoport wrote:
From: Mike Rapoport
The commit f47ac088c406 ("mm: memmap_init: iterate over memblock regions
This commit id should be a temporary one, will be changed when merged
into maintainer's tree a
The current codebase makes use of one-element arrays in the following
form:
struct something {
int length;
u8 data[1];
};
struct something *instance;
instance = kmalloc(sizeof(*instance) + size, GFP_KERNEL);
instance->length = size;
memcpy(instance->data, source, size);
but the preferre
On Fri, May 15, 2020 at 12:44 PM Kees Cook wrote:
>
> From: Pavel Tatashin
Subject still has 'max_reason'.
>
> Currently, it is possible to dump kmsges for panic, or oops.
> With max_reason it is possible to dump messages for other
And here.
> kmesg_dump events, for example reboot, halt, shut
On Mon, May 18, 2020 at 05:19:04PM -0500, Gustavo A. R. Silva wrote:
> The current codebase makes use of one-element arrays in the following
> form:
>
> struct something {
> int length;
> u8 data[1];
> };
>
> struct something *instance;
>
> instance = kmalloc(sizeof(*instance) + size, GF
On Mon, May 18, 2020 at 04:45:32PM -0600, Rob Herring wrote:
> On Fri, May 15, 2020 at 12:44 PM Kees Cook wrote:
> >
> > From: Pavel Tatashin
>
> Subject still has 'max_reason'.
>
> >
> > Currently, it is possible to dump kmsges for panic, or oops.
> > With max_reason it is possible to dump mes
On Sat, 2020-05-16 at 17:36 +1000, Nicholas Piggin wrote:
> Good, I think this should work as you want now. Can you allocate it like
> lppacas? Put it under PSERIES (and in the paca) and check for !HV?
Sure, I will do that.
> Oh and while there, could you prefix the name with rtas_?
Sure, repl
allyesconfig
powerpc rhel-kconfig
powerpc allmodconfig
powerpc allnoconfig
i386 randconfig-a006-20200518
i386 randconfig-a005-20200518
i386 randconfig
Patch 2 implement rtas_call_reentrant() for reentrant rtas-calls:
"ibm,int-on", "ibm,int-off",ibm,get-xive" and "ibm,set-xive",
according to LoPAPR Version 1.1 (March 24, 2016).
For that, it's necessary that every call uses a different
rtas buffer (rtas_args). Paul Mackerras suggested using the P
In order to get any rtas* struct into other headers, including rtas.h
may cause a lot of errors, regarding include dependency needed for
inline functions.
Create rtas-types.h and move there all type/struct definitions
from rtas.h, then include rtas-types.h into rtas.h.
Also, as suggested by check
Implement rtas_call_reentrant() for reentrant rtas-calls:
"ibm,int-on", "ibm,int-off",ibm,get-xive" and "ibm,set-xive".
On LoPAPR Version 1.1 (March 24, 2016), from 7.3.10.1 to 7.3.10.4,
items 2 and 3 say:
2 - For the PowerPC External Interrupt option: The * call must be
reentrant to the number
On Sun, May 17, 2020 at 09:29:32PM -0700, Guenter Roeck wrote:
> On Sun, May 17, 2020 at 08:49:39PM -0700, Ira Weiny wrote:
> > On Sat, May 16, 2020 at 03:33:06PM -0700, Guenter Roeck wrote:
> > > On Thu, May 07, 2020 at 07:59:55AM -0700, ira.we...@intel.com wrote:
> > > > From: Ira Weiny
> > > >
defconfig
powerpc allyesconfig
powerpc rhel-kconfig
powerpc allmodconfig
powerpc allnoconfig
i386 randconfig-a006-20200518
i386
Currently, if printk lock (logbuf_lock) is held by other thread during
crash, there is a chance of deadlocking the crash on next printk, and
blocking a possibly desired kdump.
At the start of default_machine_crash_shutdown, make printk enter
NMI context, as it will use per-cpu buffers to store the
This series brings together several previously posted patches required for
POWER10 support and introduces a new patch enabling POWER10 architected
mode to enable booting as a POWER10 pseries guest.
It includes support for enabling facilities related to MMA and prefix
instructions.
Changes from v1
POWER10 introduces two new architectural features - ISAv3.1 and matrix
multiply accumulate (MMA) instructions. Userspace detects the presence
of these features via two HWCAP bits introduced in this patch. These
bits have been agreed to by the compiler and binutils team.
Signed-off-by: Alistair Pop
Newer ISA versions are enabled by clearing all bits in the PCR
associated with previous versions of the ISA. Enable ISA v3.1 support
by updating the PCR mask to include ISA v3.0. This ensures all PCR
bits corresponding to earlier architecture versions get cleared
thereby enabling ISA v3.1 if suppor
On powernv hardware support for ISAv3.1 is advertised via a cpu feature
bit in the device tree. This patch enables the associated HWCAP bit if
the device tree indicates ISAv3.1 is available.
Signed-off-by: Alistair Popple
---
arch/powerpc/kernel/dt_cpu_ftrs.c | 6 ++
1 file changed, 6 insert
Setting the FSCR bit directly in the SPR only sets it during the initial
boot and early init of the kernel but not for the init process or any
subsequent kthreads. This is because the thread_struct for those is
copied from the current thread_struct setup at boot which doesn't
reflect any changes ma
Prefix instructions have their own FSCR bit which needs to be enabled
via a CPU feature. The kernel will save the FSCR for problem state but
it needs to be enabled initially.
Signed-off-by: Alistair Popple
---
arch/powerpc/kernel/dt_cpu_ftrs.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/
Matrix multiple accumulate (MMA) is a new feature added to ISAv3.1 and
POWER10. Support on powernv can be selected via a firmware CPU device
tree feature which enables it via a PCR bit.
Signed-off-by: Alistair Popple
---
arch/powerpc/include/asm/reg.h| 3 ++-
arch/powerpc/kernel/dt_cpu_ftrs
PVR value of 0x0F06 means we are arch v3.1 compliant (i.e. POWER10).
This is used by phyp and kvm when booting as a pseries guest to detect
the presence of new P10 features and to enable the appropriate hwcap and
facility bits.
Signed-off-by: Alistair Popple
Signed-off-by: Cédric Le Goater
-
Hi Ira,
On 5/18/20 5:03 PM, Ira Weiny wrote:
> On Sun, May 17, 2020 at 09:29:32PM -0700, Guenter Roeck wrote:
>> On Sun, May 17, 2020 at 08:49:39PM -0700, Ira Weiny wrote:
>>> On Sat, May 16, 2020 at 03:33:06PM -0700, Guenter Roeck wrote:
On Thu, May 07, 2020 at 07:59:55AM -0700, ira.we...@in
On Tue, 2020-05-19 at 10:31 +1000, Alistair Popple wrote:
> POWER10 introduces two new architectural features - ISAv3.1 and matrix
> multiply accumulate (MMA) instructions. Userspace detects the presence
> of these features via two HWCAP bits introduced in this patch. These
> bits have been agreed
On 2020/5/19 6:19, Gustavo A. R. Silva wrote:
> -Original Message-
> From: Gustavo A. R. Silva
> Sent: 2020年5月19日 6:19
> To: Qiang Zhao ; Leo Li
> Cc: linuxppc-dev@lists.ozlabs.org; linux-arm-ker...@lists.infradead.org;
> linux-ker...@vger.kernel.org; Gustavo A. R. Silva ;
> Kees Cook
On Tue, May 19, 2020 at 10:48 AM Alistair Popple wrote:
>
> PVR value of 0x0F06 means we are arch v3.1 compliant (i.e. POWER10).
> This is used by phyp and kvm when booting as a pseries guest to detect
> the presence of new P10 features and to enable the appropriate hwcap and
> facility bits.
On Tue, May 19, 2020 at 10:39 AM Alistair Popple wrote:
>
> Newer ISA versions are enabled by clearing all bits in the PCR
> associated with previous versions of the ISA. Enable ISA v3.1 support
> by updating the PCR mask to include ISA v3.0. This ensures all PCR
> bits corresponding to earlier ar
Jordan Niethe writes:
> On Sun, May 17, 2020 at 4:39 AM Christophe Leroy
> wrote:
>>
>> Le 06/05/2020 à 05:40, Jordan Niethe a écrit :
>> > Prefixed instructions will mean there are instructions of different
>> > length. As a result dereferencing a pointer to an instruction will not
>> > necessar
This gives us OF_PMEM which is useful in mambo.
This adds 153K to the text of ppc64le_defconfig which 0.8% of the
total text.
LIBNVDIMM text databss dec hex
Without 18574833 5518150 1539240 25632223 1871ddf
With 18727834 5546206 1539368 25813408 189e1a0
Signed-off-b
Le 19/05/2020 à 06:05, Michael Ellerman a écrit :
Jordan Niethe writes:
On Sun, May 17, 2020 at 4:39 AM Christophe Leroy
wrote:
Le 06/05/2020 à 05:40, Jordan Niethe a écrit :
Prefixed instructions will mean there are instructions of different
length. As a result dereferencing a pointer t
Hi Dan,
Apologies for the delay in response. I was waiting for feedback from
hardware team before responding to this email.
Dan Williams writes:
> On Tue, May 12, 2020 at 8:47 PM Aneesh Kumar K.V
> wrote:
>>
>> Architectures like ppc64 provide persistent memory specific barriers
>> that wil
On Tuesday, 19 May 2020 2:04:51 PM AEST Jordan Niethe wrote:
> On Tue, May 19, 2020 at 10:39 AM Alistair Popple
wrote:
> > Newer ISA versions are enabled by clearing all bits in the PCR
> > associated with previous versions of the ISA. Enable ISA v3.1 support
> > by updating the PCR mask to inclu
In case (k_start & PAGE_MASK) doesn't equal (kstart), 'va' will never be
NULL allthough 'block' is NULL
Check the return of memblock_alloc() directly instead of
the resulting address in the loop.
Fixes: 509cd3f2b473 ("powerpc/32: Simplify KASAN init")
Signed-off-by: Christophe Leroy
---
arch/po
The main purpose of this big series is to:
- reorganise huge page handling to avoid using mm_slices.
- use huge pages to map kernel memory on the 8xx.
The 8xx supports 4 page sizes: 4k, 16k, 512k and 8M.
It uses 2 Level page tables, PGD having 1024 entries, each entry
covering 4M address space. Th
At the time being, KASAN_SHADOW_END is 0x1, which
is 0 in 32 bits representation.
This leads to a couple of issues:
- kasan_remap_early_shadow_ro() does nothing because the comparison
k_cur < k_end is always false.
- In ptdump, address comparison for markers display fails and the
marker's
Doing kasan pages allocation in MMU_init is too early, kernel doesn't
have access yet to the entire memory space and memblock_alloc() fails
when the kernel is a bit big.
Do it from kasan_init() instead.
Fixes: 2edb16efc899 ("powerpc/32: Add KASAN support")
Cc: sta...@vger.kernel.org
Signed-off-by
Commit 45ff3c559585 ("powerpc/kasan: Fix parallel loading of
modules.") added spinlocks to manage parallele module loading.
Since then commit 47febbeeec44 ("powerpc/32: Force KASAN_VMALLOC for
modules") converted the module loading to KASAN_VMALLOC.
The spinlocking has then become unneeded and ca
kasan_remap_early_shadow_ro() and kasan_unmap_early_shadow_vmalloc()
are both updating the early shadow mapping: the first one sets
the mapping read-only while the other clears the mapping.
Refactor and create kasan_update_early_region()
Signed-off-by: Christophe Leroy
---
arch/powerpc/mm/kasan
In order to alloc sub-arches to alloc KASAN regions using optimised
methods (Huge pages on 8xx, BATs on BOOK3S, ...), declare
kasan_init_region() weak.
Also make kasan_init_shadow_page_tables() accessible from outside,
so that it can be called from the specific kasan_init_region()
functions if nee
In order to have all flags fit on a 80 chars wide screen,
reduce the flags to 1 char (2 where ambiguous).
No cache is 'i'
User is 'ur' (Supervisor would be sr)
Shared (for 8xx) becomes 'sh' (it was 'user' when not shared but
that was ambiguous because that's not entirely right)
Signed-off-by: Chr
For platforms using shared.c (4xx, Book3e, Book3s/32),
also handle the _PAGE_COHERENT flag with corresponds to the
M bit of the WIMG flags.
Signed-off-by: Christophe Leroy
---
arch/powerpc/mm/ptdump/shared.c | 5 +
1 file changed, 5 insertions(+)
diff --git a/arch/powerpc/mm/ptdump/shared.c
Reorder flags in a more logical way:
- Page size (huge) first
- User
- RWX
- Present
- WIMG
- Special
- Dirty and Accessed
Signed-off-by: Christophe Leroy
---
arch/powerpc/mm/ptdump/8xx.c| 30 +++---
arch/powerpc/mm/ptdump/shared.c | 30 +++---
Display the size of areas mapped with BATs.
For that, the size display for pages is refactorised.
Signed-off-by: Christophe Leroy
---
v2: Add missing include of linux/seq_file.h (Thanks to kbuild test robot)
---
arch/powerpc/mm/ptdump/bats.c | 4
arch/powerpc/mm/ptdump/ptdump.c | 23 +++
Display BAT flags the same way as page flags: rwx and wimg
Signed-off-by: Christophe Leroy
---
arch/powerpc/mm/ptdump/bats.c | 37 ++-
1 file changed, 15 insertions(+), 22 deletions(-)
diff --git a/arch/powerpc/mm/ptdump/bats.c b/arch/powerpc/mm/ptdump/bats.c
ind
The 8xx is about to map kernel linear space and IMMR using huge
pages.
In order to display those pages properly, ptdump needs to handle
hugepd tables at PGD level.
For the time being do it only at PGD level. Further patches may
add handling of hugepd tables at lower level for other platforms
when
In order to properly display information regardless of the page size,
it is necessary to take into account real page size.
Signed-off-by: Christophe Leroy
Fixes: cabe8138b23c ("powerpc: dump as a single line areas mapping a single
physical page.")
Cc: sta...@vger.kernel.org
---
v3: Fixed sizes w
Mapping RO data as ROX is not an issue since that data
cannot be modified to introduce an exploit.
PPC64 accepts to have RO data mapped ROX, as a trade off
between kernel size and strictness of protection.
On PPC32, kernel size is even more critical as amount of
memory is usually small.
Dependin
Allocate static page tables for the fixmap area. This allows
setting mappings through page tables before memblock is ready.
That's needed to use early_ioremap() early and to use standard
page mappings with fixmap.
Signed-off-by: Christophe Leroy
---
arch/powerpc/include/asm/fixmap.h | 4
a
Setting init mem to NX shall depend on sinittext being mapped by
block, not on stext being mapped by block.
Setting text and rodata to RO shall depend on stext being mapped by
block, not on sinittext being mapped by block.
Fixes: 63b2bc619565 ("powerpc/mm/32s: Use BATs for STRICT_KERNEL_RWX")
Cc:
Only 40x still uses PTE_ATOMIC_UPDATES.
40x cannot not select CONFIG_PTE64_BIT.
Drop handling of PTE_ATOMIC_UPDATES:
- In nohash/64
- In nohash/32 for CONFIG_PTE_64BIT
Keep PTE_ATOMIC_UPDATES only for nohash/32 for !CONFIG_PTE_64BIT
Signed-off-by: Christophe Leroy
---
arch/powerpc/include/asm/
When CONFIG_PTE_64BIT is set, pte_update() operates on
'unsigned long long'
When CONFIG_PTE_64BIT is not set, pte_update() operates on
'unsigned long'
In asm/page.h, we have pte_basic_t which is 'unsigned long long'
when CONFIG_PTE_64BIT is set and 'unsigned long' otherwise.
Refactor pte_update()
1 - 100 of 118 matches
Mail list logo
