Michael ?
Le 31/05/2022 à 08:24, Christophe Leroy a écrit :
Le 17/05/2022 à 14:37, Michael Ellerman a écrit :
Christophe Leroy writes:
Le 15/05/2022 à 12:28, Michael Ellerman a écrit :
On Tue, 22 Mar 2022 16:40:17 +0100, Christophe Leroy wrote:
This series reduces by 70% the time required
Hi Sathvika
Le 18/06/2022 à 06:56, Sathvika Vasireddy a écrit :
> Hi Christophe,
>
> On 15/06/22 21:33, Christophe Leroy wrote:
>> Do you have any idea when you plan to send next revision ?
>>
>> I'm really looking forward to submitting the inline static calls on top
>> of your series.
>
> I'm p
On Friday 24 June 2022 13:08:59 Michael Ellerman wrote:
> Pali Rohár writes:
> > CZ.NIC Turris 1.0 and 1.1 are open source routers, they have dual-core
> > PowerPC Freescale P2020 CPU and are based on Freescale P2020RDB-PC-A board.
> > Hardware design is fully open source, all firmware and hardwar
On 24/06/2022, 08:31:55, Michael Ellerman wrote:
> Laurent Dufour writes:
>> In some cricunstances it may be interesting to reconfigure the watchdog
>> from inside the kernel.
>>
>> On PowerPC, this may helpful before and after a LPAR migration (LPM) is
>> initiated, because it implies some latenc
* Aneesh Kumar K.V [2022-06-23 18:24:41]:
> If early cpu to node mapping finds an invalid node id, return
> the first online node instead of node 0.
>
> With commit e75130f20b1f ("powerpc/numa: Offline memoryless cpuless node 0")
> the kernel marks node 0 offline in certain scenarios.
>
> Signe
* Aneesh Kumar K.V [2022-06-23 18:24:42]:
> While building the cpu_to_node map make sure we always use the online node
> to build the mapping table. In general this should not be an issue
> because the kernel use similar lookup mechanism (vphn_get_nid()) to mark
> nodes online (setup_node_data())
On Sat, Jun 18, 2022 at 3:06 AM Michael Schmitz wrote:
> Am 18.06.2022 um 00:57 schrieb Arnd Bergmann:
> >
> > All architecture-independent users of virt_to_bus() and bus_to_virt()
> > have been fixed to use the dma mapping interfaces or have been
> > removed now. This means the definitions on mo
CZ.NIC Turris 1.0 and 1.1 are open source routers, they have dual-core
PowerPC Freescale P2020 CPU and are based on Freescale P2020RDB-PC-A board.
Hardware design is fully open source, all firmware and hardware design
files are available at Turris project website:
https://docs.turris.cz/hw/turris-
On Friday 24 June 2022 10:27:00 Pali Rohár wrote:
> On Friday 24 June 2022 13:08:59 Michael Ellerman wrote:
> > Pali Rohár writes:
> > > CZ.NIC Turris 1.0 and 1.1 are open source routers, they have dual-core
> > > PowerPC Freescale P2020 CPU and are based on Freescale P2020RDB-PC-A
> > > board.
>
On Tue, Jun 14, 2022 at 03:54:12PM +0200, Laurent Dufour wrote:
> The watchdog_mutex is exported to allow some variable to be changed under
> its protection and prevent any conflict.
> The lockup_detector_reconfigure() function is exported and is expected to
> be called under the protection of watc
Hi Hari,
Hari Bathini wrote:
This patchset adds atomic operations to the eBPF instruction set on
powerpc. The instructions that are added here can be summarised with
this list of kernel operations for ppc64:
* atomic[64]_[fetch_]add
* atomic[64]_[fetch_]and
* atomic[64]_[fetch_]or
* atomic[64]_
Hari Bathini wrote:
On 14/06/22 12:41 am, Hari Bathini wrote:
On 11/06/22 11:04 pm, Christophe Leroy wrote:
Le 10/06/2022 à 17:55, Hari Bathini a écrit :
This adds two atomic opcodes BPF_XCHG and BPF_CMPXCHG on ppc32, both
of which include the BPF_FETCH flag. The kernel's atomic_cmpxchg
Le 23/06/2022 à 14:29, Aneesh Kumar K.V a écrit :
> Instead of high_memory use VMALLOC_START to validate that the address is
> not in the vmalloc range.
What's the reason for using VMALLOC_START instead ?
The gap between high_memory and VMALLOC_START should not be seen as
valid memory either, s
On Fri, Jun 24, 2022 at 10:13:18AM +0530, Anshuman Khandual wrote:
> This moves protection_map[] inside the platform and makes it a static.
>
> Cc: Catalin Marinas
> Cc: Will Deacon
> Cc: linux-arm-ker...@lists.infradead.org
> Cc: linux-ker...@vger.kernel.org
> Signed-off-by: Anshuman Khandual
On 24/06/2022, 11:37:23, Christoph Hellwig wrote:
> On Tue, Jun 14, 2022 at 03:54:12PM +0200, Laurent Dufour wrote:
>> The watchdog_mutex is exported to allow some variable to be changed under
>> its protection and prevent any conflict.
>> The lockup_detector_reconfigure() function is exported and
Hi Scott,
A few comments below ...
Scott Cheloha writes:
> PAPR v2.12 defines a new hypercall, H_WATCHDOG. The hypercall permits
> guest control of one or more virtual watchdog timers. The timers have
> millisecond granularity. The guest is terminated when a timer
> expires.
>
> This patch ad
Nathan Lynch writes:
> Scott Cheloha writes:
>> PAPR v2.12 defines a new hypercall, H_WATCHDOG. The hypercall permits
>> guest control of one or more virtual watchdog timers.
...
>
> Seems like we don't need pseries_wdt_pdev as it's unused elsewhere? But
> that's quite minor.
It's minor but ple
"Jason A. Donenfeld" writes:
> On POWER8 systems that don't have ibm,power-rng available, a guest that
> ignores the KVM_CAP_PPC_HWRNG flag and calls H_RANDOM anyway will
> dereference a NULL pointer. And on machines with darn instead of
> ibm,power-rng, H_RANDOM won't work at all.
>
> This patch
Scott Cheloha writes:
...
> +
> +static struct platform_driver pseries_wdt_driver = {
> + .driver = {
> + .name = DRV_NAME,
> + .owner = THIS_MODULE,
That owner assignment is not required.
It's set for you by platform_driver_register() via
module_platform_driver().
c
On 23/06/2022, 19:28:34, Nathan Lynch wrote:
> Laurent Dufour writes:
>> diff --git a/arch/powerpc/platforms/pseries/mobility.c
>> b/arch/powerpc/platforms/pseries/mobility.c
>> index 179bbd4ae881..4284ceaf9060 100644
>> --- a/arch/powerpc/platforms/pseries/mobility.c
>> +++ b/arch/powerpc/platfo
Hi Fabiano,
On Fri, Jun 24, 2022 at 3:43 PM Fabiano Rosas wrote:
>
> "Jason A. Donenfeld" writes:
>
> > On POWER8 systems that don't have ibm,power-rng available, a guest that
> > ignores the KVM_CAP_PPC_HWRNG flag and calls H_RANDOM anyway will
> > dereference a NULL pointer. And on machines wi
These are two small cleanups for -next.
Jason A. Donenfeld (2):
powerpc/powernv: rename remaining rng powernv_ functions to pnv_
powerpc/kvm: don't crash on missing rng, and use darn
arch/powerpc/include/asm/archrandom.h | 7 +--
arch/powerpc/kvm/book3s_hv_builtin.c | 7 +--
arch/powerpc/
The preferred nomenclature is pnv_, not powernv_, but rng.c used
powernv_ for some reason, which isn't consistent with the rest. A recent
commit added a few pnv_ functions to rng.c, making the file a bit of a
mishmash. This commit just replaces the rest of them.
Cc: Michael Ellerman
Fixes: f3eac4
On POWER8 systems that don't have ibm,power-rng available, a guest that
ignores the KVM_CAP_PPC_HWRNG flag and calls H_RANDOM anyway will
dereference a NULL pointer. And on machines with darn instead of
ibm,power-rng, H_RANDOM won't work at all.
This patch kills two birds with one stone, by routin
The H_ENTER_NESTED hypercall receives as second parameter the address
of a region of memory containing the values for the nested guest
privileged registers. We currently use the pt_regs structure contained
within kvm_vcpu_arch for that end.
Most hypercalls that receive a memory address expect that
"Jason A. Donenfeld" writes:
> The preferred nomenclature is pnv_, not powernv_, but rng.c used
> powernv_ for some reason, which isn't consistent with the rest. A recent
> commit added a few pnv_ functions to rng.c, making the file a bit of a
> mishmash. This commit just replaces the rest of the
"Jason A. Donenfeld" writes:
> On POWER8 systems that don't have ibm,power-rng available, a guest that
> ignores the KVM_CAP_PPC_HWRNG flag and calls H_RANDOM anyway will
> dereference a NULL pointer. And on machines with darn instead of
> ibm,power-rng, H_RANDOM won't work at all.
>
> This patch
On Fri, Jun 24, 2022 at 11:27:24PM +1000, Michael Ellerman wrote:
> Scott Cheloha writes:
> > + * - For the "Query Watchdog Capabilities" operation, a 64-bit
> > + * value structured as follows:
> > + *
> > + * Bits 0-15: The minimum supported timeout in milliseconds.
> > + * Bits 1
On 6/23/22 08:47, Arnd Bergmann wrote:
Can you test it again with this patch on top?
diff --git a/drivers/scsi/BusLogic.c b/drivers/scsi/BusLogic.c
index d057abfcdd5c..9e67f2ee25ee 100644
--- a/drivers/scsi/BusLogic.c
+++ b/drivers/scsi/BusLogic.c
@@ -2554,8 +2554,14 @@ static void blogic_scan
On Fri, Jun 24, 2022 at 5:38 PM Khalid Aziz wrote:
> On 6/23/22 08:47, Arnd Bergmann wrote:
>
> Driver works with this change. next_inbox is the correct pointer to pass.
Ok, great! I'll add a 'Tested-by' line then. I was already in the process of
preparing a v3 patch set, will send out the fixed
From: Arnd Bergmann
The virt_to_bus/bus_to_virt interface has been deprecated for
decades. After Jakub Kicinski put a lot of work into cleaning out the
network drivers using them, there are only a couple of other drivers
left, which can all be removed or otherwise cleaned up, to remove the
old in
From: Arnd Bergmann
The BusLogic driver is the last remaining driver that relies on the
deprecated bus_to_virt() function, which in turn only works on a few
architectures, and is incompatible with both swiotlb and iommu support.
Before commit 391e2f25601e ("[SCSI] BusLogic: Port driver to 64-bit
From: Arnd Bergmann
All architecture-independent users of virt_to_bus() and bus_to_virt()
have been fixed to use the dma mapping interfaces or have been
removed now. This means the definitions on most architectures, and the
CONFIG_VIRT_TO_BUS symbol are now obsolete and can be removed.
The only
On 6/24/22 09:52, Arnd Bergmann wrote:
From: Arnd Bergmann
The BusLogic driver is the last remaining driver that relies on the
deprecated bus_to_virt() function, which in turn only works on a few
architectures, and is incompatible with both swiotlb and iommu support.
Before commit 391e2f25601e
On Fri, Jun 24, 2022 at 5:52 PM Arnd Bergmann wrote:
> Arnd Bergmann (3):
> scsi: BusLogic remove bus_to_virt
> scsi: dpt_i2o: remove obsolete driver
The dpt_i2o removal is overly large and got dropped by some of the
mailing lists,
if anyone wants to see the full patch, it did make it throug
On 24/06/2022 16:16, Serge Semin wrote:
> In accordance with the Generic EHCI/OHCI bindings the corresponding node
> name is suppose to comply with the Generic USB HCD DT schema, which
> requires the USB nodes to have the name acceptable by the regexp:
> "^usb(@.*)?" . Make sure the "generic-ehci"
On 24/06/2022 16:16, Serge Semin wrote:
> In accordance with the DWC USB3 bindings the corresponding node
> name is suppose to comply with the Generic USB HCD DT schema, which
> requires the USB nodes to have the name acceptable by the regexp:
> "^usb(@.*)?" . Make sure the "snps,dwc3"-compatible n
On 24/06/2022 16:16, Serge Semin wrote:
> In accordance with the DWC USB3 bindings the corresponding node
> name is suppose to comply with the Generic USB HCD DT schema, which
> requires the USB nodes to have the name acceptable by the regexp:
> "^usb(@.*)?" . Make sure the "snps,dwc3"-compatible n
On Fri, 24 Jun 2022 17:16:18 +0300, Serge Semin wrote:
> In accordance with the Generic EHCI/OHCI bindings the corresponding node
> name is suppose to comply with the Generic USB HCD DT schema, which
> requires the USB nodes to have the name acceptable by the regexp:
> "^usb(@.*)?" . Make sure the
These patches are rebased on top of objtool/core
branch of the tip tree, and are tested on
ppc64le with ppc64le_defconfig.
Christophe Leroy (3):
objtool: Fix SEGFAULT
objtool: Use target file endianness instead of a compiled constant
objtool: Use target file class size instead of a compiled
From: Christophe Leroy
Signed-off-by: Christophe Leroy
---
tools/objtool/check.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/tools/objtool/check.c b/tools/objtool/check.c
index 190b2f6e360a..6cb07e151588 100644
--- a/tools/objtool/check.c
+++ b/tools/objtool/check.c
@@ -
From: Christophe Leroy
Some architectures like powerpc support both endianness, it's
therefore not possible to fix the endianness via arch/endianness.h
because there is no easy way to get the target endianness at
build time.
Use the endianness recorded in the file objtool is working on.
Signed-
From: Christophe Leroy
In order to allow using objtool on cross-built kernels,
determine size of long from elf data instead of using
sizeof(long) at build time.
For the time being this covers only mcount.
Signed-off-by: Christophe Leroy
---
tools/objtool/check.c | 16 +--
Architectures can select HAVE_NOP_MCOUNT if they choose
to nop out mcount call sites. If that config option is
selected, then --mnop is passed as an option to objtool,
along with --mcount.
Also, make sure that --mnop can be passed as an option
to objtool only when --mcount is passed.
Signed-off-b
Do not run objtool on VDSO files, by using
OBJECT_FILES_NON_STANDARD
Suggested-by: Christophe Leroy
Signed-off-by: Sathvika Vasireddy
---
arch/powerpc/kernel/vdso/Makefile | 2 ++
1 file changed, 2 insertions(+)
diff --git a/arch/powerpc/kernel/vdso/Makefile
b/arch/powerpc/kernel/vdso/Makefil
This patch reads special sections which have alternate
instructions, only when stackval or orc or uaccess or
noinstr options are passed to objtool.
Signed-off-by: Sathvika Vasireddy
---
tools/objtool/check.c | 8 +---
1 file changed, 5 insertions(+), 3 deletions(-)
diff --git a/tools/objtoo
Make relocation types architecture specific.
Signed-off-by: Sathvika Vasireddy
---
tools/objtool/arch/x86/include/arch/elf.h | 2 ++
tools/objtool/check.c | 2 +-
2 files changed, 3 insertions(+), 1 deletion(-)
diff --git a/tools/objtool/arch/x86/include/arch/elf.h
b/tools/
Add architecture specific function to look for
relocation records pointing to arch specific
symbols.
Suggested-by: Christophe Leroy
Signed-off-by: Sathvika Vasireddy
---
tools/objtool/arch/x86/decode.c | 8
tools/objtool/check.c| 2 +-
tools/objtool/include/objtool
This patch adds [stub] implementations for required
functions, inorder to enable objtool build on powerpc.
Signed-off-by: Sathvika Vasireddy
---
arch/powerpc/Kconfig | 1 +
tools/objtool/arch/powerpc/Build | 2 +
tools/objtool/arch/powerpc/decode.c
This patch enables objtool --mcount on powerpc, and
adds implementation specific to powerpc.
Signed-off-by: Sathvika Vasireddy
---
arch/powerpc/Kconfig | 1 +
tools/objtool/arch/powerpc/decode.c | 22 +++
tools/objtool/arch/powerpc/include/arch
objtool is throwing *unannotated intra-function call*
warnings with a few instructions that are marked
unreachable. Remove unreachable() from WARN_ON()
to fix these warnings, as the codegen remains same
with and without unreachable() in WARN_ON().
Signed-off-by: Sathvika Vasireddy
---
arch/power
objtool throws unannotated intra-function call warnings
in the following assembly files.
arch/powerpc/kernel/head_64.o: warning: objtool: .text+0x358: unannotated
intra-function call
arch/powerpc/kernel/vector.o: warning: objtool: .text+0x53c: unannotated
intra-function call
arch/powerpc/kernel/
Hi Christophe,
On 24/06/22 12:38, Christophe Leroy wrote:
Is everything going ok ? Don't hesitate if you need help.
Yeah, sure. Thanks!
I just posted RFC v3 here:
https://patchwork.ozlabs.org/project/linuxppc-dev/cover/20220624183238.388144-1...@linux.ibm.com/
tree/branch:
https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git master
branch HEAD: 2f9cb3d3bd73fc2225d66aa8fcffb632ed3eb235 Add linux-next specific
files for 20220624
Error/Warning reports:
https://lore.kernel.org/llvm/202206221813.dn1s6uuh-...@intel.com
Error/Warning
On Fri, Jun 24, 2022 at 07:14:44PM +0200, Krzysztof Kozlowski wrote:
> On 24/06/2022 16:16, Serge Semin wrote:
> > In accordance with the Generic EHCI/OHCI bindings the corresponding node
> > name is suppose to comply with the Generic USB HCD DT schema, which
> > requires the USB nodes to have the
On Fri, Jun 24, 2022 at 07:18:57PM +0200, Krzysztof Kozlowski wrote:
> On 24/06/2022 16:16, Serge Semin wrote:
> > In accordance with the DWC USB3 bindings the corresponding node
> > name is suppose to comply with the Generic USB HCD DT schema, which
> > requires the USB nodes to have the name acce
On Fri, Jun 24, 2022 at 07:17:53PM +0200, Krzysztof Kozlowski wrote:
> On 24/06/2022 16:16, Serge Semin wrote:
> > In accordance with the DWC USB3 bindings the corresponding node
> > name is suppose to comply with the Generic USB HCD DT schema, which
> > requires the USB nodes to have the name acce
Hello,
When trying v5.19-rc3 on my ppc64 VM with KASANs enabled, I get the
following on boot:
[0.174621]
==
[0.175501] BUG: KASAN: slab-out-of-bounds in _find_first_zero_bit+0x40/0x140
[0.176132] Read of size 8 at addr c
On 6/24/22 07:16, Serge Semin wrote:
In accordance with the Generic EHCI/OHCI bindings the corresponding node
name is suppose to comply with the Generic USB HCD DT schema, which
requires the USB nodes to have the name acceptable by the regexp:
"^usb(@.*)?" . Make sure the "generic-ehci" and "g
On Fri, Jun 24, 2022 at 03:11:43PM -0700, Vineet Gupta wrote:
>
> On 6/24/22 07:16, Serge Semin wrote:
> > In accordance with the Generic EHCI/OHCI bindings the corresponding node
> > name is suppose to comply with the Generic USB HCD DT schema, which
> > requires the USB nodes to have the name ac
Hi Liam,
Liam Howlett writes:
>
> When trying v5.19-rc3 on my ppc64 VM with KASANs enabled, I get the
> following on boot:
>
> [0.174621]
> ==
> [0.175501] BUG: KASAN: slab-out-of-bounds in
> _find_first_zero_bit+0x40/0x140
* Nathan Lynch [220624 19:51]:
> Hi Liam,
>
> Liam Howlett writes:
> >
> > When trying v5.19-rc3 on my ppc64 VM with KASANs enabled, I get the
> > following on boot:
> >
> > [0.174621]
> > ==
> > [0.175501] BUG: KASAN: slab
For csky part.
Acked-by: Guo Ren
On Fri, Jun 24, 2022 at 12:48 PM Anshuman Khandual
wrote:
>
> This enables ARCH_HAS_VM_GET_PAGE_PROT on the platform and exports standard
> vm_get_page_prot() implementation via DECLARE_VM_GET_PAGE_PROT, which looks
> up a private and static protection_map[] ar
On Fri, Jun 24, 2022 at 10:13:23AM +0530, Anshuman Khandual wrote:
> This enables ARCH_HAS_VM_GET_PAGE_PROT on the platform and exports standard
> vm_get_page_prot() implementation via DECLARE_VM_GET_PAGE_PROT, which looks
> up a private and static protection_map[] array. Subsequently all __SXXX an
Le 24/06/2022 à 20:32, Sathvika Vasireddy a écrit :
> objtool is throwing *unannotated intra-function call*
> warnings with a few instructions that are marked
> unreachable. Remove unreachable() from WARN_ON()
> to fix these warnings, as the codegen remains same
> with and without unreachable() i
65 matches
Mail list logo
