On 9/15/21 11:53 AM, Michael Ellerman wrote:
Vasant Hegde writes:
Currently only FSP based powernv systems supports firmware update
interfaces. Hence check that the token OPAL_FLASH_VALIDATE exists
before initalising the flash driver.
Signed-off-by: Vasant Hegde
---
arch/powerpc/platforms/p
On 9/15/21 11:53 AM, Michael Ellerman wrote:
Vasant Hegde writes:
Currently only FSP based powernv systems supports firmware update
interfaces. Hence check that the token OPAL_FLASH_VALIDATE exists
before initalising the flash driver.
Signed-off-by: Vasant Hegde
---
arch/powerpc/platforms/p
Vasant Hegde writes:
> Currently only FSP based powernv systems supports firmware update
> interfaces. Hence check that the token OPAL_FLASH_VALIDATE exists
> before initalising the flash driver.
>
> Signed-off-by: Vasant Hegde
> ---
> arch/powerpc/platforms/powernv/opal-flash.c | 4
> 1 fi
On Sat, Sep 11, 2021 at 12:39 PM Christopher M. Riedl
wrote:
>
> When code patching a STRICT_KERNEL_RWX kernel the page containing the
> address to be patched is temporarily mapped as writeable. Currently, a
> per-cpu vmalloc patch area is used for this purpose. While the patch
> area is per-cpu,
On Tue, Sep 14, 2021 at 9:08 PM Dan Williams wrote:
>
> On Thu, Sep 9, 2021 at 12:56 AM kajoljain wrote:
> >
> >
> >
> > On 9/8/21 3:29 AM, Dan Williams wrote:
> > > Hi Kajol,
> > >
> > > Apologies for the delay in responding to this series, some comments below:
> >
> > Hi Dan,
> > No issues,
On Thu, Sep 9, 2021 at 12:56 AM kajoljain wrote:
>
>
>
> On 9/8/21 3:29 AM, Dan Williams wrote:
> > Hi Kajol,
> >
> > Apologies for the delay in responding to this series, some comments below:
>
> Hi Dan,
> No issues, thanks for reviewing the patches.
>
> >
> > On Thu, Sep 2, 2021 at 10:10 PM
On 15/9/21 12:32 am, Mauro Carvalho Chehab wrote:
The What: field should have just the location of the ABI.
Anything else should be inside the description.
This fixes its parsing by get_abi.pl script.
Signed-off-by: Mauro Carvalho Chehab
Looks fine to me.
Acked-by: Andrew Donnellan
---
On Tue, 14 Sep 2021, Christoph Hellwig wrote:
> On Tue, Sep 14, 2021 at 05:29:07PM +0200, Jan Beulich wrote:
> > I'm not convinced the swiotlb use describe there falls under "intended
> > use" - mapping a 1280x720 framebuffer in a single chunk? (As an aside,
> > the bottom of this page is also conf
Borislav Petkov writes:
> On Wed, Sep 08, 2021 at 05:58:35PM -0500, Tom Lendacky wrote:
>> Introduce a powerpc version of the cc_platform_has() function. This will
>> be used to replace the powerpc mem_encrypt_active() implementation, so
>> the implementation will initially only support the CC_ATT
Bjorn Helgaas writes:
> On Fri, Sep 10, 2021 at 04:19:40PM +0200, Niklas Schnelle wrote:
>> On powerpc, pci_dev_is_added() is called as part of SR-IOV fixups
>> that are done under pcibios_add_device() which in turn is only called in
>> pci_device_add() whih is called when a PCI device is scanned.
From: Roman Skakun
It is possible when default IO TLB size is not
enough to fit a long buffers as described here [1].
This patch makes a way to set this parameter
using cmdline instead of recompiling a kernel.
[1] https://www.xilinx.com/support/answers/72694.html
Signed-off-by: Roman Skakun
-
UPD_CONSTR was previously a preprocessor define for an old GCC 4.9 inline
asm bug with m<> constraints.
Fixes: 6563139d90ad ("powerpc: remove GCC version check for UPD_CONSTR")
Suggested-by: Nathan Chancellor
Suggested-by: Christophe Leroy
Suggested-by: Michael Ellerman
Signed-off-by: Nick Desa
On Tue, Sep 14, 2021 at 01:27:08AM +1000, Oliver O'Halloran wrote:
> The general convention for pcibios_* hooks is that they're named after
> the corresponding pci_* function they provide a hook for. The exception
> is pcibios_add_device() which provides a hook for pci_device_add(). This
> has been
On Fri, Sep 10, 2021 at 04:19:40PM +0200, Niklas Schnelle wrote:
> On powerpc, pci_dev_is_added() is called as part of SR-IOV fixups
> that are done under pcibios_add_device() which in turn is only called in
> pci_device_add() whih is called when a PCI device is scanned.
>
> Now pci_dev_assign_add
On 14.09.2021 17:10, Roman Skakun wrote:
> From: Roman Skakun
>
> It is possible when default IO TLB size is not
> enough to fit a long buffers as described here [1].
>
> This patch makes a way to set this parameter
> using cmdline instead of recompiling a kernel.
>
> [1] https://www.xilinx.com
On Mon, Sep 13, 2021 at 11:22 PM Stephen Rothwell wrote:
>
> Hi Abdul,
>
> On Tue, 14 Sep 2021 11:39:44 +0530 Abdul Haleem
> wrote:
> >
> > Today's mainline kernel fails to compile on my powerpc box with below errors
> >
> > ././include/linux/compiler_attributes.h:62:5: warning: "__has_attribute
On Wed, Sep 08, 2021 at 05:58:36PM -0500, Tom Lendacky wrote:
> diff --git a/arch/x86/mm/mem_encrypt.c b/arch/x86/mm/mem_encrypt.c
> index 18fe19916bc3..4b54a2377821 100644
> --- a/arch/x86/mm/mem_encrypt.c
> +++ b/arch/x86/mm/mem_encrypt.c
> @@ -144,7 +144,7 @@ void __init sme_unmap_bootdata(char
On 9/14/2021 9:17 AM, Nick Desaulniers wrote:
UPD_CONSTR was previously a preprocessor define for an old GCC 4.9 inline
asm bug with m<> constraints.
Fixes: 6563139d90ad ("powerpc: remove GCC version check for UPD_CONSTR")
Suggested-by: Nathan Chancellor
Suggested-by: Christophe Leroy
Suggeste
On Tue, 14 Sept 2021 at 17:59, Linus Torvalds
wrote:
>
> On Tue, Sep 14, 2021 at 8:53 AM Ard Biesheuvel wrote:
> >
> > task_cpu() takes a 'const struct task_struct *', whereas
> > task_thread_info() takes a 'struct task_struct *'.
>
> Oh, annoying, but that's easily fixed. Just make that
>
>s
Hello Juergen,
Hello All,
Since the RC1 of kernel 5.13, -smp 2 and -smp 4 don't work with a
virtual e5500 QEMU KVM-HV machine anymore. [1]
I see in the serial console, that the uImage doesn't load. I use the
following QEMU command for booting:
qemu-system-ppc64 -M ppce500 -cpu e5500 -enable-k
On Tue, Sep 14, 2021 at 8:53 AM Ard Biesheuvel wrote:
>
> task_cpu() takes a 'const struct task_struct *', whereas
> task_thread_info() takes a 'struct task_struct *'.
Oh, annoying, but that's easily fixed. Just make that
static inline struct thread_info *task_thread_info(struct
task_struct *
On Tue, 14 Sept 2021 at 17:49, Linus Torvalds
wrote:
>
> On Tue, Sep 14, 2021 at 5:11 AM Ard Biesheuvel wrote:
> >
> > static inline unsigned int task_cpu(const struct task_struct *p)
> > {
> > #ifdef CONFIG_THREAD_INFO_IN_TASK
> > - return READ_ONCE(p->cpu);
> > + return READ_ONCE
On Tue, Sep 14, 2021 at 5:11 AM Ard Biesheuvel wrote:
>
> static inline unsigned int task_cpu(const struct task_struct *p)
> {
> #ifdef CONFIG_THREAD_INFO_IN_TASK
> - return READ_ONCE(p->cpu);
> + return READ_ONCE(p->thread_info.cpu);
> #else
> return READ_ONCE(task_thread_
On Tue, 14 Sept 2021 at 17:41, Linus Torvalds
wrote:
>
> On Tue, Sep 14, 2021 at 5:10 AM Ard Biesheuvel wrote:
> >
> > The CPU field will be moved back into thread_info even when
> > THREAD_INFO_IN_TASK is enabled, so add it back to arm64's definition of
> > struct thread_info.
>
> The series loo
On Tue, Sep 14, 2021 at 5:10 AM Ard Biesheuvel wrote:
>
> The CPU field will be moved back into thread_info even when
> THREAD_INFO_IN_TASK is enabled, so add it back to arm64's definition of
> struct thread_info.
The series looks sane to me, but it strikes me that it's inconsistent
- here for ar
On Tue, Sep 14, 2021 at 05:29:07PM +0200, Jan Beulich wrote:
> I'm not convinced the swiotlb use describe there falls under "intended
> use" - mapping a 1280x720 framebuffer in a single chunk? (As an aside,
> the bottom of this page is also confusing, as following "Then we can
> confirm the modifie
On Tue, Sep 14, 2021 at 04:47:41PM +0200, Christophe Leroy wrote:
> Yes, see
> https://lore.kernel.org/linuxppc-dev/20210914123919.58203...@canb.auug.org.au/T/#t
Aha, more compiler magic stuff ;-\
Oh well, I guess that fix will land upstream soon.
Thx.
--
Regards/Gruss,
Boris.
https://pe
Le 14/09/2021 à 13:58, Borislav Petkov a écrit :
On Wed, Sep 08, 2021 at 05:58:35PM -0500, Tom Lendacky wrote:
Introduce a powerpc version of the cc_platform_has() function. This will
be used to replace the powerpc mem_encrypt_active() implementation, so
the implementation will initially only
On Tue, Sep 14, 2021 at 10:17:23PM +1000, Michael Ellerman wrote:
> Stephen reported that the build was broken since commit
> 6d2ef226f2f1 ("compiler_attributes.h: drop __has_attribute() support for
> gcc4"), with errors such as:
>
> include/linux/compiler_attributes.h:296:5: warning: "__has_att
Signed-off-by: Vasant Hegde
---
arch/powerpc/platforms/powernv/opal-dump.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/powerpc/platforms/powernv/opal-dump.c
b/arch/powerpc/platforms/powernv/opal-dump.c
index 00c5a59d82d9..717d1d30ade5 100644
--- a/arch/powerpc/platfo
The What: field should have just the location of the ABI.
Anything else should be inside the description.
This fixes its parsing by get_abi.pl script.
Signed-off-by: Mauro Carvalho Chehab
---
Documentation/ABI/testing/sysfs-class-cxl | 15 ++-
1 file changed, 10 insertions(+), 5 del
The ABI files are meant to be parsed via a script (scripts/get_abi.pl).
A new improvement on it will allow it to help to detect if an ABI description
is missing, or if the What: field won't match the actual location of the symbol.
In order for get_abi.pl to convert What: into regex, changes are n
Include the new stack frame inside the user access block and set it up
using unsafe_put_user().
On an mpc 8321 (book3s/32) the improvment is about 4% on a process
sending a signal to itself.
Signed-off-by: Christophe Leroy
---
arch/powerpc/kernel/signal_32.c | 29 +
In the same spirit as commit fb05121fd6a2 ("signal: Add
unsafe_get_compat_sigset()"), implement an 'unsafe' version of
copy_siginfo_to_user() in order to use it within user access blocks.
For that, also add an 'unsafe' version of clear_user().
This commit adds the generic fallback for unsafe_clea
Use unsafe_copy_siginfo_to_user() in order to do the copy
within the user access block.
On an mpc 8321 (book3s/32) the improvment is about 5% on a process
sending a signal to itself.
Signed-off-by: Christophe Leroy
---
v4: Use another approach for compat: drop the unsafe_copy_siginfo_to_user32()
Implement unsafe_clear_user() for powerpc.
It's a copy/paste of unsafe_copy_to_user() with value 0 as source.
It may be improved in a later patch by using 'dcbz' instruction
to zeroize full cache lines at once.
Signed-off-by: Christophe Leroy
---
arch/powerpc/include/asm/uaccess.h | 20
Access the function descriptor of the handler within a
user access block.
Signed-off-by: Christophe Leroy
---
v3: Flatten the change to avoid nested gotos.
---
arch/powerpc/kernel/signal_64.c | 16 ++--
1 file changed, 14 insertions(+), 2 deletions(-)
diff --git a/arch/powerpc/kerne
Le 13/09/2021 à 21:11, Eric W. Biederman a écrit :
Christophe Leroy writes:
Le 13/09/2021 à 18:21, Eric W. Biederman a écrit :
ebied...@xmission.com (Eric W. Biederman) writes:
Christophe Leroy writes:
Use unsafe_copy_siginfo_to_user() in order to do the copy
within the user access bl
On Tue, Sep 14, 2021 at 02:10:28PM +0200, Ard Biesheuvel wrote:
> Commit c65eacbe290b ("sched/core: Allow putting thread_info into
> task_struct") mentions that, along with moving thread_info into
> task_struct, the cpu field is moved out of the former into the latter,
> but does not explain why.
Le 14/09/2021 à 14:10, Ard Biesheuvel a écrit :
Commit c65eacbe290b ("sched/core: Allow putting thread_info into
task_struct") mentions that, along with moving thread_info into
task_struct, the cpu field is moved out of the former into the latter,
but does not explain why.
I think it does ex
On Tue, 14 Sept 2021 at 10:17, Vasant Hegde
wrote:
>
> Signed-off-by: Vasant Hegde
There's a typo in your commit message :)
> ---
> arch/powerpc/platforms/powernv/opal-dump.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/arch/powerpc/platforms/powernv/opal-dump.c
>
On 09/14/2021 03:30 PM, Daniel Borkmann wrote:
On 9/11/21 3:56 AM, Tiezhu Yang wrote:
[...]
With this patch, it does not change the current limit 33,
MAX_TAIL_CALL_CNT
can reflect the actual max tail call count, the tailcall selftests
can work
well, and also the above failed testcase in test
Linus Torvalds writes:
> On Mon, Sep 13, 2021 at 7:08 PM Stephen Rothwell
> wrote:
>>
>> That patch works for me - for the ppc64_defconfig build at least.
>
> Yeah, I just tested the allmodconfig case too, although I suspect it's
> essentially the same wrt the boot *.S files, so it probably does
Stephen reported that the build was broken since commit
6d2ef226f2f1 ("compiler_attributes.h: drop __has_attribute() support for
gcc4"), with errors such as:
include/linux/compiler_attributes.h:296:5: warning: "__has_attribute" is not
defined, evaluates to 0 [-Wundef]
296 | #if __has_attrib
Now that the core code switched back to using thread_info::cpu to keep
a task's CPU number, we no longer need to keep it in sync explicitly. So
just drop the code that does this.
Signed-off-by: Ard Biesheuvel
---
This patch applies onto [0], which we hope to get merged for v5.16
[0]
https://git
Now that the core code switched back to using thread_info::cpu to keep
a task's CPU number, we no longer need to keep it in sync explicitly. So
just drop the code that does this.
Signed-off-by: Ard Biesheuvel
---
arch/riscv/kernel/asm-offsets.c | 1 -
arch/riscv/kernel/entry.S | 5 -
a
Instead of relying on awful hacks to obtain the offset of the cpu field
in struct task_struct, move it back into struct thread_info, which does
not create the same level of circular dependency hell when trying to
include the header file that defines it.
Signed-off-by: Ard Biesheuvel
---
arch/pow
THREAD_INFO_IN_TASK moved the CPU field out of thread_info, but this
causes some issues on architectures that define raw_smp_processor_id()
in terms of this field, due to the fact that #include'ing linux/sched.h
to get at struct task_struct is problematic in terms of circular
dependencies.
Given t
The CPU field will be moved back into thread_info even when
THREAD_INFO_IN_TASK is enabled, so add it back to powerpc's definition
of struct thread_info.
Signed-off-by: Ard Biesheuvel
---
arch/powerpc/include/asm/thread_info.h | 3 +++
1 file changed, 3 insertions(+)
diff --git a/arch/powerpc/i
The CPU field will be moved back into thread_info even when
THREAD_INFO_IN_TASK is enabled, so add it back to s390's definition of
struct thread_info.
Signed-off-by: Ard Biesheuvel
---
arch/s390/include/asm/thread_info.h | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/s390/include/asm/t
The CPU field will be moved back into thread_info even when
THREAD_INFO_IN_TASK is enabled, so add it back to x86's definition of
struct thread_info.
Signed-off-by: Ard Biesheuvel
---
arch/x86/include/asm/thread_info.h | 3 +++
1 file changed, 3 insertions(+)
diff --git a/arch/x86/include/asm/t
The CPU field will be moved back into thread_info even when
THREAD_INFO_IN_TASK is enabled, so add it back to arm64's definition of
struct thread_info.
Signed-off-by: Ard Biesheuvel
---
arch/arm64/include/asm/thread_info.h | 1 +
arch/arm64/kernel/asm-offsets.c | 1 +
2 files changed, 2 ins
Commit c65eacbe290b ("sched/core: Allow putting thread_info into
task_struct") mentions that, along with moving thread_info into
task_struct, the cpu field is moved out of the former into the latter,
but does not explain why.
While collaborating with Keith on adding THREAD_INFO_IN_TASK support to
On Wed, Sep 08, 2021 at 05:58:35PM -0500, Tom Lendacky wrote:
> Introduce a powerpc version of the cc_platform_has() function. This will
> be used to replace the powerpc mem_encrypt_active() implementation, so
> the implementation will initially only support the CC_ATTR_MEM_ENCRYPT
> attribute.
>
On Tue, Sep 14, 2021 at 08:40:38PM +1000, Michael Ellerman wrote:
> Peter Zijlstra writes:
> > I'm thinking we ought to keep hops as steps along the NUMA fabric, with
> > 0 hops being the local node. That only gets us:
> >
> > L2, remote=0, hops=HOPS_0 -- our L2
> > L2, remote=1, hops=HOPS_0 --
Peter Zijlstra writes:
> On Thu, Sep 09, 2021 at 10:45:54PM +1000, Michael Ellerman wrote:
>
>> > The 'new' composite doesnt have a hops field because the hardware that
>> > nessecitated that change doesn't report it, but we could easily add a
>> > field there.
>> >
>> > Suppose we add, mem_hops:3
Signed-off-by: Vasant Hegde
---
arch/powerpc/platforms/powernv/opal-dump.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/powerpc/platforms/powernv/opal-dump.c
b/arch/powerpc/platforms/powernv/opal-dump.c
index 00c5a59d82d9..717d1d30ade5 100644
--- a/arch/powerpc/platfo
Currently only FSP based powernv systems supports firmware update
interfaces. Hence check that the token OPAL_FLASH_VALIDATE exists
before initalising the flash driver.
Signed-off-by: Vasant Hegde
---
arch/powerpc/platforms/powernv/opal-flash.c | 4
1 file changed, 4 insertions(+)
diff --g
The Nintendo Wii and Wii U OTP is only present on Nintendo Wii and Wii U
consoles. Hence add a dependency on WII, to prevent asking the user
about this driver when configuring a kernel without Nintendo Wii and Wii
U console support.
Fixes: 3683b761fe3a10ad ("nvmem: nintendo-otp: Add new driver fo
On 9/11/21 3:56 AM, Tiezhu Yang wrote:
In the current code, the actual max tail call count is 33 which is greater
than MAX_TAIL_CALL_CNT (defined as 32), the actual limit is not consistent
with the meaning of MAX_TAIL_CALL_CNT, there is some confusion and need to
spend some time to think about th
60 matches
Mail list logo
