Le 29/03/2022 à 00:31, Joel Stanley a écrit :
> On Mon, 29 Nov 2021 at 22:43, Christophe Leroy
> wrote:
>>
>>
>>
>> Le 29/11/2021 à 18:43, Steven Rostedt a écrit :
>>> On Fri, 26 Nov 2021 08:43:23 +
>>> LEROY Christophe wrote:
>>>
Le 24/11/2021 à 15:43, Christophe Leroy a écrit :
Le 29/03/2022 à 18:43, David Hildenbrand a écrit :
> The swap type is simply stored in bits 0x1f of the swap pte. Let's
> simplify by just getting rid of _PAGE_BIT_SWAP_TYPE. It's not like that
> we can simply change it: _PAGE_SWP_SOFT_DIRTY would suddenly fall into
> _RPAGE_RSV1, which isn't
Hi,
Le 08/11/2020 à 22:15, Vaibhav Jain a écrit :
Add support for reporting papr-scm supported generic nvdimm stats by
implementing support for handling ND_CMD_GET_STAT in
'papr_scm_ndctl().
The mapping between libnvdimm generic nvdimm-stats and papr-scm
specific performance-stats is embedded
Le 30/03/2022 à 04:07, Steven Rostedt a écrit :
> On Fri, 25 Mar 2022 09:03:08 +0100
> Christophe Leroy wrote:
>
>> --- a/kernel/trace/fgraph.c
>> +++ b/kernel/trace/fgraph.c
>> @@ -10,6 +10,7 @@
>> #include
>> #include
>> #include
>> +#include
>>
>
> Small nit. Please order the
allmodconfig
powerpc randconfig-c003-20220330
i386 randconfig-c001
sh rts7751r2d1_defconfig
armrealview_defconfig
arm assabet_defconfig
alpha defconfig
ftrace_graph_is_dead() is used on hot paths, it just reads a variable
in memory and is not worth suffering function call constraints.
For instance, at entry of prepare_ftrace_return(), inlining it avoids
saving prepare_ftrace_return() parameters to stack and restoring them
after calling
On 30.03.22 08:07, Christophe Leroy wrote:
>
>
> Le 29/03/2022 à 18:43, David Hildenbrand a écrit :
>> The swap type is simply stored in bits 0x1f of the swap pte. Let's
>> simplify by just getting rid of _PAGE_BIT_SWAP_TYPE. It's not like that
>> we can simply change it: _PAGE_SWP_SOFT_DIRTY
Currently the boot wrapper lacks a -mcpu option, so it will be built for
the toolchain's default cpu. This is a problem if the toolchain defaults
to a cpu with newer instructions.
We could wire in TARGET_CPU but instead use the oldest supported option
so the wrapper runs anywhere.
The GCC
On Mon, Mar 28, 2022 at 08:07:13PM +1100, Michael Ellerman wrote:
> Linus Torvalds writes:
> > On Fri, Mar 25, 2022 at 3:25 AM Michael Ellerman
> > wrote:
>
> > That said:
> >
> >> There's a series of commits cleaning up function descriptor handling,
> >
> > For some reason I also thought
Michal Suchánek writes:
> On Mon, Mar 28, 2022 at 08:07:13PM +1100, Michael Ellerman wrote:
>> Linus Torvalds writes:
>> > On Fri, Mar 25, 2022 at 3:25 AM Michael Ellerman
>> > wrote:
>>
>> > That said:
>> >
>> >> There's a series of commits cleaning up function descriptor handling,
>> >
>> >
Le 30/03/2022 à 13:24, Joel Stanley a écrit :
> Currently the boot wrapper lacks a -mcpu option, so it will be built for
> the toolchain's default cpu. This is a problem if the toolchain defaults
> to a cpu with newer instructions.
>
> We could wire in TARGET_CPU but instead use the oldest
On Wed, 30 Mar 2022 at 11:33, Christophe Leroy
wrote:
>
>
>
> Le 30/03/2022 à 13:24, Joel Stanley a écrit :
> > Currently the boot wrapper lacks a -mcpu option, so it will be built for
> > the toolchain's default cpu. This is a problem if the toolchain defaults
> > to a cpu with newer
From: Arnd Bergmann
[ Upstream commit 23fc539e81295b14b50c6ccc5baeb4f3d59d822d ]
On some architectures, access_ok() does not do any argument type
checking, so replacing the definition with a generic one causes
a few warnings for harmless issues that were never caught before.
Fix the ones that
From: Arnd Bergmann
[ Upstream commit 23fc539e81295b14b50c6ccc5baeb4f3d59d822d ]
On some architectures, access_ok() does not do any argument type
checking, so replacing the definition with a generic one causes
a few warnings for harmless issues that were never caught before.
Fix the ones that
On 29/03/2022, 13:14:10, Michael Ellerman wrote:
> Laurent Dufour writes:
>> On 29/03/2022, 10:31:33, Nicholas Piggin wrote:
>>> Excerpts from Laurent Dufour's message of March 17, 2022 9:06 pm:
RTAS runs in real mode (MSR[DR] and MSR[IR] unset) and in 32bits
mode (MSR[SF] unset).
From: Arnd Bergmann
[ Upstream commit 23fc539e81295b14b50c6ccc5baeb4f3d59d822d ]
On some architectures, access_ok() does not do any argument type
checking, so replacing the definition with a generic one causes
a few warnings for harmless issues that were never caught before.
Fix the ones that
Christophe Leroy wrote:
Le 28/03/2022 à 19:20, Naveen N. Rao a écrit :
Michael Ellerman wrote:
Murilo Opsfelder Araújo writes:
On 3/23/22 08:51, Naveen N. Rao wrote:
+static inline bool can_single_step(u32 inst)
+{
+ switch (inst >> 26) {
Can't ppc_inst_primary_opcode() be used
From: Arnd Bergmann
[ Upstream commit 23fc539e81295b14b50c6ccc5baeb4f3d59d822d ]
On some architectures, access_ok() does not do any argument type
checking, so replacing the definition with a generic one causes
a few warnings for harmless issues that were never caught before.
Fix the ones that
On Wed, Mar 30, 2022 at 07:21:23PM +0530, Srikar Dronamraju wrote:
> With commit 09f49dca570a ("mm: handle uninitialized numa nodes
> gracefully") NODE_DATA for even a memoryless/cpuless node is partially
> initialized at boot time.
>
> Before onlining the node, current Powerpc code checks for
On Thu, Mar 31, 2022 at 12:21:03AM +1100, Michael Ellerman wrote:
> Michal Suchánek writes:
> > On Mon, Mar 28, 2022 at 08:07:13PM +1100, Michael Ellerman wrote:
> >> Linus Torvalds writes:
> >> > On Fri, Mar 25, 2022 at 3:25 AM Michael Ellerman
> >> > wrote:
> >>
> >> > That said:
> >> >
>
Christophe Leroy wrote:
Le 29/03/2022 à 14:01, Michael Ellerman a écrit :
Josh Poimboeuf writes:
On Sun, Mar 27, 2022 at 09:09:20AM +, Christophe Leroy wrote:
What are current works in progress on objtool ? Should I wait Josh's
changes before starting looking at all this ? Should I
The pull request you sent on Tue, 29 Mar 2022 13:54:41 -0700:
> git://git.kernel.org/pub/scm/linux/kernel/git/nvdimm/nvdimm
> tags/libnvdimm-for-5.18
has been merged into torvalds/linux.git:
https://git.kernel.org/torvalds/c/ee96dd9614f1c139e719dd2f296acbed7f1ab4b8
Thank you!
--
From: Nicholas Piggin
emulate_step() instruction emulation including sc instruction emulation
initially appeared in xmon. It was then moved into sstep.c where kprobes
could use it too, and later hw_breakpoint and uprobes started to use it.
Until uprobes, the only instruction emulation users
On Wed, Mar 30, 2022 at 3:21 PM Michael Ellerman wrote:
> Michal Suchánek writes:
> > On Mon, Mar 28, 2022 at 08:07:13PM +1100, Michael Ellerman wrote:
> >> No you're right, we have moved away from them, but not entirely.
> >>
> >> Functions descriptors are still used for 64-bit big endian, but
With commit 09f49dca570a ("mm: handle uninitialized numa nodes
gracefully") NODE_DATA for even a memoryless/cpuless node is partially
initialized at boot time.
Before onlining the node, current Powerpc code checks for NODE_DATA to
be NULL. However since NODE_DATA is partially initialized, this
Since v1, the main change is to use helpers to decode primary/extended
opcode and the addition of macros for some of the used opcodes.
- Naveen
Naveen N. Rao (2):
powerpc: Sort and de-dup primary opcodes in ppc-opcode.h
powerpc: Reject probes on instructions that can't be single stepped
Per the ISA, a Trace interrupt is not generated for:
- [h|u]rfi[d]
- rfscv
- sc, scv, and Trap instructions that trap
- Power-Saving Mode instructions
- other instructions that cause interrupts (other than Trace interrupts)
- the first instructions of any interrupt handler (applies to Branch and
Some of the primary opcodes are duplicated. Remove those, and sort the
rest of the primary opcodes to make it easy to read.
Signed-off-by: Naveen N. Rao
---
arch/powerpc/include/asm/ppc-opcode.h | 69 ---
1 file changed, 31 insertions(+), 38 deletions(-)
diff --git
On Tue, 29 Mar 2022 18:43:27 +0200
David Hildenbrand wrote:
> Let's use bit 52, which is unused.
>
> Signed-off-by: David Hildenbrand
> ---
> arch/s390/include/asm/pgtable.h | 23 +--
> 1 file changed, 21 insertions(+), 2 deletions(-)
>
> diff --git
On Tue, 29 Mar 2022 18:43:26 +0200
David Hildenbrand wrote:
> Bit 52 and bit 55 don't have to be zero: they only trigger a
> translation-specifiation exception if the PTE is marked as valid, which
> is not the case for swap ptes.
>
> Document which bits are used for what, and which ones are
On Wed, 30 Mar 2022 06:55:26 +
Christophe Leroy wrote:
> > Small nit. Please order the includes in "upside-down x-mas tree" fashion:
> >
> > #include
> > #include
> > #include
> > #include
> >
>
> That's the first time I get such a request. Usually people request
> #includes to be
On 3/29/22 1:31 AM, Kai-Heng Feng wrote:
On some Intel AlderLake platforms, Thunderbolt entering D3cold can cause
some errors reported by AER:
[ 30.100211] pcieport :00:1d.0: AER: Uncorrected (Non-Fatal) error
received: :00:1d.0
[ 30.100251] pcieport :00:1d.0: PCIe Bus Error:
https://bugzilla.kernel.org/show_bug.cgi?id=215781
Bug ID: 215781
Summary: Highmem support broken on kernels greater 5.15.x on
ppc32?
Product: Platform Specific/Hardware
Version: 2.5
Kernel Version: 5.16.18
Hardware:
https://bugzilla.kernel.org/show_bug.cgi?id=215781
--- Comment #3 from Erhard F. (erhar...@mailbox.org) ---
Created attachment 300667
--> https://bugzilla.kernel.org/attachment.cgi?id=300667=edit
kernel .config (5.15.32, PowerMac G4 DP)
--
You may reply to this email to add a comment.
You
https://bugzilla.kernel.org/show_bug.cgi?id=215781
--- Comment #1 from Erhard F. (erhar...@mailbox.org) ---
Created attachment 300665
--> https://bugzilla.kernel.org/attachment.cgi?id=300665=edit
dmesg (5.15.32, PowerMac G4 DP)
--
You may reply to this email to add a comment.
You are
https://bugzilla.kernel.org/show_bug.cgi?id=215781
--- Comment #2 from Erhard F. (erhar...@mailbox.org) ---
Created attachment 300666
--> https://bugzilla.kernel.org/attachment.cgi?id=300666=edit
kernel .config (5.16.18, PowerMac G4 DP)
--
You may reply to this email to add a comment.
You
On Thu, 31 Mar 2022 at 02:05, Murilo Opsfelder Araújo
wrote:
>
> Hi, Joel.
>
> On 3/30/22 08:24, Joel Stanley wrote:
> > Currently the boot wrapper lacks a -mcpu option, so it will be built for
> > the toolchain's default cpu. This is a problem if the toolchain defaults
> > to a cpu with newer
Hi, Joel.
On 3/30/22 08:24, Joel Stanley wrote:
Currently the boot wrapper lacks a -mcpu option, so it will be built for
the toolchain's default cpu. This is a problem if the toolchain defaults
to a cpu with newer instructions.
We could wire in TARGET_CPU but instead use the oldest supported
38 matches
Mail list logo