Christophe Leroy writes:
> Le 25/11/2020 à 06:16, Aneesh Kumar K.V a écrit :
>> With hash translation use DSISR_KEYFAULT to identify a wrong access.
>> With Radix we look at the AMR value and type of fault.
>>
>> Signed-off-by: Aneesh Kumar K.V
>> ---
>>
Le 26/11/2020 à 08:38, Aneesh Kumar K.V a écrit :
Christophe Leroy writes:
Le 25/11/2020 à 06:16, Aneesh Kumar K.V a écrit :
+++ b/arch/powerpc/kernel/process.c
@@ -1530,10 +1530,32 @@ void flush_thread(void)
#ifdef CONFIG_PPC_BOOK3S_64
void arch_setup_new_exec(void)
{
-
Christophe Leroy writes:
> Le 25/11/2020 à 06:16, Aneesh Kumar K.V a écrit :
> +++ b/arch/powerpc/kernel/process.c
>> @@ -1530,10 +1530,32 @@ void flush_thread(void)
>> #ifdef CONFIG_PPC_BOOK3S_64
>> void arch_setup_new_exec(void)
>> {
>> -if (radix_enabled())
>> -
On Tue, 2020-11-24 at 21:52 +0800, Wang Hai wrote:
> Fix to return a negative error code from the error handling
> case instead of 0, as done elsewhere in this function.
>
> Fixes: d8d74ea3c002 ("tpm: ibmvtpm: Wait for buffer to be set before
> proceeding")
> Reported-by: Hulk Robot
>
"Aneesh Kumar K.V" writes:
> This patch consolidates UAMOR update across pkey, kuap and kuep features.
> The boot cpu initialize UAMOR via pkey init and both radix/hash do the
> secondary cpu UAMOR init in early_init_mmu_secondary.
>
> We don't check for mmu_feature in radix secondary init
"Aneesh Kumar K.V" writes:
> The next set of patches adds support for kuap with hash translation.
> Hence make KUAP a BOOK3S_64 feature. Also make it a subfeature of
> PPC_MEM_KEYS. Hash translation is going to use pkeys to support
> KUAP/KUEP. Adding this dependency reduces the code complexity
Laurent Vivier writes:
> With virtio multiqueue, normally each queue IRQ is mapped to a CPU.
>
> But since commit 0d9f0a52c8b9f ("virtio_scsi: use virtio IRQ affinity")
> this is broken on pseries.
>
> The affinity is correctly computed in msi_desc but this is not applied
> to the system IRQs.
>
Marc Zyngier writes:
> On 2020-11-25 16:24, Laurent Vivier wrote:
>> On 25/11/2020 17:05, Denis Kirjanov wrote:
>>> On 11/25/20, Laurent Vivier wrote:
With virtio multiqueue, normally each queue IRQ is mapped to a CPU.
But since commit 0d9f0a52c8b9f ("virtio_scsi: use virtio IRQ
"Aneesh Kumar K.V" writes:
> diff --git a/arch/powerpc/include/asm/mmu.h b/arch/powerpc/include/asm/mmu.h
> index 255a1837e9f7..f5c7a17c198a 100644
> --- a/arch/powerpc/include/asm/mmu.h
> +++ b/arch/powerpc/include/asm/mmu.h
> @@ -28,6 +28,11 @@
> * Individual features below.
> */
>
> +/*
Extract the hwq id from a SCSI command and store it in the ibmvfc_event
structure to identify which Sub-CRQ to send the command down when
channels are being utilized.
Signed-off-by: Tyrel Datwyler
---
drivers/scsi/ibmvscsi/ibmvfc.c | 5 +
drivers/scsi/ibmvscsi/ibmvfc.h | 1 +
2 files
If the ibmvfc client adapter requests channels it must submit a number
of Sub-CRQ handles matching the number of channels being requested. The
VIOS in its response will overwrite the actual number of channel
resources allocated which may be less than what was requested. The
client then must store
When the client has negotiated the use of channels all vfcFrames are
required to go down a Sub-CRQ channel or it is a protocoal violation. If
the adapter state is channelized submit vfcFrames to the appropriate
Sub-CRQ via the h_send_sub_crq() helper.
Signed-off-by: Tyrel Datwyler
---
Introduce several new vhost fields for managing MQ state of the adapter
as well as initial defaults for MQ enablement.
Signed-off-by: Tyrel Datwyler
---
drivers/scsi/ibmvscsi/ibmvfc.c | 7 +++
drivers/scsi/ibmvscsi/ibmvfc.h | 9 +
2 files changed, 16 insertions(+)
diff --git
Each Sub-CRQ has its own interrupt. A hypercall is required to toggle
the IRQ state. Provide the necessary mechanism via a helper function.
Signed-off-by: Tyrel Datwyler
---
drivers/scsi/ibmvscsi/ibmvfc.c | 20
1 file changed, 20 insertions(+)
diff --git
New NPIV_ENQUIRY_CHANNEL and NPIV_SETUP_CHANNEL management datagrams
(MADs) were defined in a previous patchset. If the client advertises a
desire to use channels and the partner VIOS is channel capable then the
client must proceed with channel enquiry to determine the maximum number
of channels
Subordinate Command Response Queues (Sub CRQ) are used in conjunction
with the primary CRQ when more than one queue is needed by the virtual
IO adapter. Recent phyp firmware versions support Sub CRQ's with ibmvfc
adapters. This feature is a prerequisite for supporting multiple
hardware backed
Create an irq mapping for the hw_irq number provided from phyp firmware.
Request an irq assigned our Sub-CRQ interrupt handler.
Signed-off-by: Tyrel Datwyler
---
drivers/scsi/ibmvscsi/ibmvfc.c | 22 ++
1 file changed, 22 insertions(+)
diff --git
Allocate a set of Sub-CRQs in advance. During channel setup the client
and VIOS negotiate the number of queues the VIOS supports and the number
that the client desires to request. Its possible that the final channel
resources allocated is less than requested, but the client is still
responsible
Sub-CRQs are registred with firmware via a hypercall. Abstract that
interface into a simpler helper function.
Signed-off-by: Tyrel Datwyler
---
drivers/scsi/ibmvscsi/ibmvfc.c | 14 ++
1 file changed, 14 insertions(+)
diff --git a/drivers/scsi/ibmvscsi/ibmvfc.c
Recent updates in pHyp Firmware and VIOS releases provide new infrastructure
towards enabling Subordinate Command Response Queues (Sub-CRQs) such that each
Sub-CRQ is a channel backed by an actual hardware queue in the FC stack on the
partner VIOS. Sub-CRQs are registered with the firmware via
Simple handler that calls Sub-CRQ drain routine directly.
Signed-off-by: Tyrel Datwyler
---
drivers/scsi/ibmvscsi/ibmvfc.c | 14 ++
1 file changed, 14 insertions(+)
diff --git a/drivers/scsi/ibmvscsi/ibmvfc.c b/drivers/scsi/ibmvscsi/ibmvfc.c
index a8730522920e..4fb782fa2c66 100644
Previous patches have plumbed the necessary Sub-CRQ interface and
channel negotiation MADs to fully channelized hardware queues.
Advertise client support via NPIV Login capability
IBMVFC_CAN_USE_CHANNELS when the client bits have MQ enabled via
vhost->mq_enabled, or when channels were already in
The logic for iterating over the Sub-CRQ responses is similiar to that
of the primary CRQ. Add the necessary handlers for processing those
responses.
Signed-off-by: Tyrel Datwyler
---
drivers/scsi/ibmvscsi/ibmvfc.c | 72 ++
1 file changed, 72 insertions(+)
diff
Inconsistent login with the vnicserver is causing the device to be
removed. This does not give the device a chance to recover from error
state. This patch schedules a FATAL reset instead to bring the adapter
up.
Fixes: 032c5e82847a2 ("Driver for IBM System i/p VNIC protocol")
Signed-off-by: Dany
Reduce the wait time for Command Response Queue response from 30 seconds
to 20 seconds, as recommended by VIOS and Power Hypervisor teams.
Fixes: bd0b672313941 ("ibmvnic: Move login and queue negotiation into
ibmvnic_open")
Fixes: 53da09e92910f ("ibmvnic: Add set_link_state routine for setting
send_login() does not check for the result of ibmvnic_send_crq() of the
login request. This results in the driver needlessly retrying the login
10 times even when CRQ is no longer active. Check the return code and
give up in case of errors in sending the CRQ.
The only time we want to retry is if
Reset timeout is going off right after adapter reset. This patch ensures
that timeout is scheduled if it has been 5 seconds since the last reset.
5 seconds is the default watchdog timeout.
Fixes: ed651a10875f1 ("ibmvnic: Updated reset handling")
Signed-off-by: Dany Madden
---
From: Sukadev Bhattiprolu
If after ibmvnic sends a LOGIN it gets a FAILOVER, it is possible that
the worker thread will start reset process and free the login response
buffer before it gets a (now stale) LOGIN_RSP. The ibmvnic tasklet will
then try to access the login response buffer and crash.
When ibmvnic fails to reset, it breaks out of the reset loop and frees
all of the remaining resets from the workqueue. Doing so prevents the
adapter from recovering if no reset is scheduled after that. Instead,
have the driver continue to process resets on the workqueue.
Remove the no longer need
scrq->msgs could be NULL during device reset, causing Linux to crash.
So, check before memset scrq->msgs.
Fixes: c8b2ad0a4a901 ("ibmvnic: Sanitize entire SCRQ buffer on reset")
Signed-off-by: Dany Madden
Signed-off-by: Lijun Pan
---
drivers/net/ethernet/ibm/ibmvnic.c | 19 +++
From: Sukadev Bhattiprolu
If auto-priority failover is enabled, the backing device needs time
to settle if hard resetting fails for any reason. Add a delay of 60
seconds before retrying the hard-reset.
Fixes: 2770a7984db5 ("ibmvnic: Introduce hard reset recovery")
Signed-off-by: Sukadev
In a failed reset, driver could end up in VNIC_PROBED or VNIC_CLOSED
state and cannot recover in subsequent resets, leaving it offline.
This patch restores the adapter state to reset_state, the original
state when reset was called.
Fixes: b27507bb59ed5 ("net/ibmvnic: unlock rtnl_lock in reset so
Assorted fixes for ibmvnic originated from "[PATCH net 00/15] ibmvnic:
assorted bug fixes" sent by Lijun Pan.
v3 Changes as suggested by Jakub Kicinski:
- Add a space between variable declaration and code in patch 3/9. Checkpatch
does not catch this.
- Unwrapped FIXES lines in patch 9/9.
-
defconfig
mips allyesconfig
mips allmodconfig
powerpc allyesconfig
powerpc allnoconfig
i386 randconfig-a004-20201125
i386 randconfig-a003-20201125
i386
powerpc allyesconfig
powerpc allnoconfig
i386 randconfig-a004-20201125
i386 randconfig-a003-20201125
i386 randconfig-a002-20201125
i386 randconfig-a005-20201125
i386
allyesconfig
mips allmodconfig
powerpc allyesconfig
powerpc allnoconfig
i386 randconfig-a004-20201125
i386 randconfig-a003-20201125
i386 randconfig-a002-20201125
On Wed, 25 Nov 2020 16:42:30 +
Marc Zyngier wrote:
> On 2020-11-25 16:24, Laurent Vivier wrote:
> > On 25/11/2020 17:05, Denis Kirjanov wrote:
> >> On 11/25/20, Laurent Vivier wrote:
> >>> With virtio multiqueue, normally each queue IRQ is mapped to a CPU.
> >>>
> >>> But since commit
On Tue, Nov 24, 2020 at 8:00 PM liwei (GF) wrote:
>
> Hi Yang,
>
> On 2020/11/25 6:13, Li Yang wrote:
> > On Tue, Nov 24, 2020 at 3:44 PM Li Yang wrote:
> >>
> >> On Tue, Nov 24, 2020 at 12:24 AM Wei Li wrote:
> >>>
> >>> IS_ERR_VALUE macro should be used only with unsigned long type.
> >>>
On 2020-11-25 16:24, Laurent Vivier wrote:
On 25/11/2020 17:05, Denis Kirjanov wrote:
On 11/25/20, Laurent Vivier wrote:
With virtio multiqueue, normally each queue IRQ is mapped to a CPU.
But since commit 0d9f0a52c8b9f ("virtio_scsi: use virtio IRQ
affinity")
this is broken on pseries.
On 25/11/2020 17:05, Denis Kirjanov wrote:
> On 11/25/20, Laurent Vivier wrote:
>> With virtio multiqueue, normally each queue IRQ is mapped to a CPU.
>>
>> But since commit 0d9f0a52c8b9f ("virtio_scsi: use virtio IRQ affinity")
>> this is broken on pseries.
>
> Please add "Fixes" tag.
In fact,
On Wed, 25 Nov 2020 12:16:56 +0100
Laurent Vivier wrote:
> This function adds an affinity parameter to irq_create_mapping().
> This parameter is needed to pass it to irq_domain_alloc_descs().
>
> irq_create_mapping() is a wrapper around irq_create_mapping_affinity()
> to pass NULL for the
On 11/25/20, Laurent Vivier wrote:
> With virtio multiqueue, normally each queue IRQ is mapped to a CPU.
>
> But since commit 0d9f0a52c8b9f ("virtio_scsi: use virtio IRQ affinity")
> this is broken on pseries.
Please add "Fixes" tag.
Thanks!
>
> The affinity is correctly computed in msi_desc
Add invalidate_range mmu notifier, when required (ATSD access of MMIO
registers is available), to initiate TLB invalidation commands.
For the time being, the ATSD0 set of registers is used by default.
The pasid and bdf values have to be configured in the Process Element
Entry.
The PEE must be set
When a TLB Invalidate is required for the Logical Partition, the following
sequence has to be performed:
1. Load MMIO ATSD AVA register with the necessary value, if required.
2. Write the MMIO ATSD launch register to initiate the TLB Invalidate
command.
3. Poll the MMIO ATSD status register to
Add specific kernel traces which provide information on mmu notifier and on
pages range.
Acked-by: Frederic Barrat
Signed-off-by: Christophe Lombard
---
drivers/misc/ocxl/link.c | 4 +++
drivers/misc/ocxl/trace.h | 64 +++
2 files changed, 68 insertions(+)
Platform specific function to assign a register set to a Logical Partition.
The "ibm,mmio-atsd" property, provided by the firmware, contains the 16
base ATSD physical addresses (ATSD0 through ATSD15) of the set of MMIO
registers (XTS MMIO ATSDx LPARID/AVA/launch/status register).
For the time
To complete the MMIO based mechanism, the fields: PASID, bus, device and
function of the Process Element Entry have to be filled. (See
OpenCAPI Power Platform Architecture document)
Hypervisor Process Element Entry
Word
0 1 7 8 .. 12 13 ..15 16 19 20
OpenCAPI 4.0/5.0 with TLBI/SLBI Snooping, is not used due to performance
problems caused by the PAU having to process all incoming TLBI/SLBI
commands which will cause them to back up on the PowerBus.
When the Address Translation Mode requires TLB operations to be initiated
using MMIO registers, a
On 11/24/20 11:43 PM, Michael Ellerman wrote:
Thomas Falcon writes:
Ensure that received Subordinate Command-Response Queue (SCRQ)
entries are properly read in order by the driver. These queues
are used in the ibmvnic device to process RX buffer and TX completion
descriptors. dma_rmb barriers
There is currently no way to convey the affinity of an interrupt
via irq_create_mapping(), which creates issues for devices that
expect that affinity to be managed by the kernel.
In order to sort this out, rename irq_create_mapping() to
irq_create_mapping_affinity() with an additional affinity
With virtio multiqueue, normally each queue IRQ is mapped to a CPU.
But since commit 0d9f0a52c8b9f ("virtio_scsi: use virtio IRQ affinity")
this is broken on pseries.
The affinity is correctly computed in msi_desc but this is not applied
to the system IRQs.
It appears the affinity is correctly
With virtio, in multiqueue case, each queue IRQ is normally
bound to a different CPU using the affinity mask.
This works fine on x86_64 but totally ignored on pseries.
This is not obvious at first look because irqbalance is doing
some balancing to improve that.
It appears that the "managed"
On 25/11/2020 15:54, Marc Zyngier wrote:
> On 2020-11-25 14:09, Laurent Vivier wrote:
>> On 25/11/2020 14:20, Thomas Gleixner wrote:
>>> Laurent,
>>>
>>> On Wed, Nov 25 2020 at 12:16, Laurent Vivier wrote:
>>>
>>> The proper subsystem prefix is: 'genirq/irqdomain:' and the first letter
>>> after
Christophe Leroy writes:
> Le 25/11/2020 à 06:16, Aneesh Kumar K.V a écrit :
> diff --git a/arch/powerpc/mm/book3s64/pkeys.c
> b/arch/powerpc/mm/book3s64/pkeys.c
>> index b1d091a97611..7dc71f85683d 100644
>> --- a/arch/powerpc/mm/book3s64/pkeys.c
>> +++ b/arch/powerpc/mm/book3s64/pkeys.c
On 2020-11-25 14:09, Laurent Vivier wrote:
On 25/11/2020 14:20, Thomas Gleixner wrote:
Laurent,
On Wed, Nov 25 2020 at 12:16, Laurent Vivier wrote:
The proper subsystem prefix is: 'genirq/irqdomain:' and the first
letter
after the colon wants to be uppercase.
Ok.
This function adds an
On 24/11/2020 10:58, Christophe Lombard wrote:
Add specific kernel traces which provide information on mmu notifier and on
pages range.
Signed-off-by: Christophe Lombard
---
Acked-by: Frederic Barrat
drivers/misc/ocxl/link.c | 4 +++
drivers/misc/ocxl/trace.h | 64
On 24/11/2020 10:58, Christophe Lombard wrote:
Add invalidate_range mmu notifier, when required (ATSD access of MMIO
registers is available), to initiate TLB invalidation commands.
For the time being, the ATSD0 set of registers is used by default.
The pasid and bdf values have to be
Le 25/11/2020 à 14:55, Aneesh Kumar K.V a écrit :
On 11/25/20 7:22 PM, Christophe Leroy wrote:
Le 25/11/2020 à 06:16, Aneesh Kumar K.V a écrit :
This prepare kernel to operate with a different value than userspace AMR/IAMR.
For this, AMR/IAMR need to be saved and restored on entry and
On 24/11/2020 10:58, Christophe Lombard wrote:
To complete the MMIO based mechanism, the fields: PASID, bus, device and
function of the Process Element Entry have to be filled. (See
OpenCAPI Power Platform Architecture document)
Hypervisor Process Element Entry
Word
On 25/11/2020 14:20, Thomas Gleixner wrote:
> Laurent,
>
> On Wed, Nov 25 2020 at 12:16, Laurent Vivier wrote:
>
> The proper subsystem prefix is: 'genirq/irqdomain:' and the first letter
> after the colon wants to be uppercase.
Ok.
>> This function adds an affinity parameter to
On 24/11/2020 10:58, Christophe Lombard wrote:
When a TLB Invalidate is required for the Logical Partition, the following
sequence has to be performed:
1. Load MMIO ATSD AVA register with the necessary value, if required.
2. Write the MMIO ATSD launch register to initiate the TLB Invalidate
Le 25/11/2020 à 06:16, Aneesh Kumar K.V a écrit :
With hash translation use DSISR_KEYFAULT to identify a wrong access.
With Radix we look at the AMR value and type of fault.
Signed-off-by: Aneesh Kumar K.V
---
arch/powerpc/include/asm/book3s/32/kup.h | 4 +--
On Tue, 24 Nov 2020 16:19:57 +0200, Viorel Suman (OSS) wrote:
> "fw" variable must be relased before return.
Applied to
https://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git for-next
Thanks!
[1/1] ASoC: fsl_xcvr: fix potential resource leak
commit:
On 11/25/20 7:24 PM, Christophe Leroy wrote:
Le 25/11/2020 à 06:16, Aneesh Kumar K.V a écrit :
Child thread.kuap value is inherited from the parent in
copy_thread_tls. We still
need to make sure when the child returns from a fork in the kernel we
start with the kernel
default AMR value.
On 11/25/20 7:22 PM, Christophe Leroy wrote:
Le 25/11/2020 à 06:16, Aneesh Kumar K.V a écrit :
This prepare kernel to operate with a different value than userspace
AMR/IAMR.
For this, AMR/IAMR need to be saved and restored on entry and return
from the
kernel.
With KUAP we modify kernel AMR
Le 25/11/2020 à 06:16, Aneesh Kumar K.V a écrit :
Child thread.kuap value is inherited from the parent in copy_thread_tls. We
still
need to make sure when the child returns from a fork in the kernel we start
with the kernel
default AMR value.
Reviewed-by: Sandipan Das
Signed-off-by:
On 11/25/20 7:13 PM, Christophe Leroy wrote:
Le 25/11/2020 à 06:16, Aneesh Kumar K.V a écrit :
This is in preparate to adding support for kuap with hash translation.
In preparation for that rename/move kuap related functions to
non radix names. Also move the feature bit closer to
Le 25/11/2020 à 06:16, Aneesh Kumar K.V a écrit :
This prepare kernel to operate with a different value than userspace AMR/IAMR.
For this, AMR/IAMR need to be saved and restored on entry and return from the
kernel.
With KUAP we modify kernel AMR when accessing user address from the kernel
Le 25/11/2020 à 06:16, Aneesh Kumar K.V a écrit :
In later patches during exec, we would like to access default regs.amr to
control access to the user mapping. Having thread.regs set early makes the
code changes simpler.
Signed-off-by: Aneesh Kumar K.V
---
On 24/11/2020 10:58, Christophe Lombard wrote:
Platform specific function to assign a register set to a Logical Partition.
The "ibm,mmio-atsd" property, provided by the firmware, contains the 16
base ATSD physical addresses (ATSD0 through ATSD15) of the set of MMIO
registers (XTS MMIO ATSDx
Le 25/11/2020 à 06:16, Aneesh Kumar K.V a écrit :
This is in preparate to adding support for kuap with hash translation.
In preparation for that rename/move kuap related functions to
non radix names. Also move the feature bit closer to MMU_FTR_KUEP.
It was obvious with MMU_FTR_RADIX_KUAP
Le 25/11/2020 à 06:16, Aneesh Kumar K.V a écrit :
This patch consolidates UAMOR update across pkey, kuap and kuep features.
The boot cpu initialize UAMOR via pkey init and both radix/hash do the
secondary cpu UAMOR init in early_init_mmu_secondary.
We don't check for mmu_feature in radix
Le 25/11/2020 à 06:16, Aneesh Kumar K.V a écrit :
The next set of patches adds support for kuap with hash translation.
Hence make KUAP a BOOK3S_64 feature. Also make it a subfeature of
PPC_MEM_KEYS. Hash translation is going to use pkeys to support
KUAP/KUEP. Adding this dependency reduces
Laurent,
On Wed, Nov 25 2020 at 12:16, Laurent Vivier wrote:
The proper subsystem prefix is: 'genirq/irqdomain:' and the first letter
after the colon wants to be uppercase.
> This function adds an affinity parameter to irq_create_mapping().
> This parameter is needed to pass it to
On Wed, 25 Nov 2020 12:16:57 +0100
Laurent Vivier wrote:
> With virtio multiqueue, normally each queue IRQ is mapped to a CPU.
>
> But since commit 0d9f0a52c8b9f ("virtio_scsi: use virtio IRQ affinity")
> this is broken on pseries.
>
> The affinity is correctly computed in msi_desc but this is
Christophe Leroy writes:
> Quoting Michael Ellerman :
>
>> Christophe Leroy writes:
>>> Le 03/11/2020 à 19:13, Christophe Leroy a écrit :
Le 23/10/2020 à 15:24, Michael Ellerman a écrit :
> Christophe Leroy writes:
>> Le 24/09/2020 à 15:17, Christophe Leroy a écrit :
>>> Le
On Wed, 4 Nov 2020 18:59:10 +0800, Youling Tang wrote:
> Use the common INIT_DATA_SECTION rule for the linker script in an effort
> to regularize the linker script.
Applied to powerpc/next.
[1/1] powerpc: Use the common INIT_DATA_SECTION macro in vmlinux.lds.S
On Tue, 10 Nov 2020 21:07:52 -0500, Zhang Xiaoxu wrote:
> This reverts commit a0ff72f9f5a780341e7ff5e9ba50a0dad5fa1980.
>
> Since the commit b015f6bc9547 ("powerpc/pseries: Add cpu DLPAR
> support for drc-info property"), the 'cpu_drcs' wouldn't be double
> freed when the 'cpus' node not found.
>
On Tue, 10 Nov 2020 19:19:30 +0800, xiakaixu1...@gmail.com wrote:
> Fix coccicheck warning:
>
> ./arch/powerpc/platforms/powernv/pci-sriov.c:443:7-10: WARNING: Unsigned
> expression compared with zero: win < 0
> ./arch/powerpc/platforms/powernv/pci-sriov.c:462:7-10: WARNING: Unsigned
>
On Tue, 10 Nov 2020 10:56:01 +0800, xiakaixu1...@gmail.com wrote:
> Fixes coccicheck warning:
>
> ./arch/powerpc/mm/pgtable_32.c:87:11-12: WARNING comparing pointer to 0
>
> Avoid pointer type value compared to 0.
Applied to powerpc/next.
[1/1] powerpc/mm: Fix comparing pointer to 0 warning
On Fri, 23 Oct 2020 10:45:39 +0800, Po-Hsu Lin wrote:
> The eeh-basic test got its own 60 seconds timeout (defined in commit
> 414f50434aa2 "selftests/eeh: Bump EEH wait time to 60s") per breakable
> device.
>
> And we have discovered that the number of breakable devices varies
> on different
On Fri, 23 Oct 2020 14:13:05 +1100, Michael Ellerman wrote:
> This DBG macro is unused, and has been unused since the file was
> originally merged into mainline. Just drop it.
Applied to powerpc/next.
[1/1] powerpc/ps3: Drop unused DBG macro
On Fri, 23 Oct 2020 13:08:38 +1100, Michael Ellerman wrote:
> Currently the clang build of corenet64_smp_defconfig fails with:
>
> arch/powerpc/platforms/85xx/corenet_generic.c:210:1: error:
> attribute declaration must precede definition
> machine_arch_initcall(corenet_generic,
On Wed, 28 Oct 2020 17:15:51 +0800, Qinglang Miao wrote:
> I noticed that iounmap() of msgr_block_addr before return from
> mpic_msgr_probe() in the error handling case is missing. So use
> devm_ioremap() instead of just ioremap() when remapping the message
> register block, so the mapping will be
On Wed, 11 Nov 2020 22:01:51 +1000, Nicholas Piggin wrote:
> read_user_stack_slow that walks user address translation by hand is
> only required on hash, because a hash fault can not be serviced from
> "NMI" context (to avoid re-entering the hash code) so the user stack
> can be mapped into Linux
On Wed, 11 Nov 2020 15:53:14 +0100, David Hildenbrand wrote:
> Based on latest linux/master
>
> powernv/memtrace is the only in-kernel user that rips out random memory
> it never added (doesn't own) in order to allocate memory without a
> linear mapping. Let's stop abusing memory hot(un)plug
On Wed, 14 Oct 2020 18:28:36 +1100, Jordan Niethe wrote:
> Currently in generic_secondary_smp_init(), cur_cpu_spec->cpu_restore()
> is called before a stack has been set up in r1. This was previously fine
> as the cpu_restore() functions were implemented in assembly and did not
> use a stack.
On Thu, 29 Oct 2020 17:27:14 +0100, David Hildenbrand wrote:
> powernv/memtrace is the only in-kernel user that rips out random memory
> it never added (doesn't own) in order to allocate memory without a
> linear mapping. Let's stop abusing memory hot(un)plug infrastructure for
> that - use
On Sun, 8 Nov 2020 16:57:35 + (UTC), Christophe Leroy wrote:
> In head_64.S, we have two places using RFI to return to
> kernel. Use RFI_TO_KERNEL instead.
>
> They are the two only places using RFI on book3s/64, so
> the RFI macro can go away.
Applied to powerpc/next.
[1/3] powerpc/64s:
On Tue, 3 Nov 2020 18:07:11 + (UTC), Christophe Leroy wrote:
> This is a series to switch powerpc VDSO to generic C implementation.
>
> Changes in v13:
> - Reorganised headers to avoid the need for a fake 32 bits config for
> building VDSO32 on PPC64
> - Rebased after the removal of powerpc
On Thu, 22 Oct 2020 14:05:46 + (UTC), Christophe Leroy wrote:
> fls() and fls64() are using __builtin_ctz() and _builtin_ctzll().
> On powerpc, those builtins trivially use ctlzw and ctlzd power
> instructions.
>
> Allthough those instructions provide the expected result with
> input argument
On Wed, 28 Oct 2020 09:04:33 +0100, Ard Biesheuvel wrote:
> Commit 7053f80d9696 ("powerpc/64: Prevent stack protection in early boot")
> introduced a couple of uses of __attribute__((optimize)) with function
> scope, to disable the stack protector in some early boot code.
>
> Unfortunately, and
On Wed, 7 Oct 2020 11:03:05 +0530, Aneesh Kumar K.V wrote:
> With POWER10, single tlbiel instruction invalidates all the congruence
> class of the TLB and hence we need to issue only one tlbiel with SET=0.
Applied to powerpc/next.
[1/1] powerpc/mm: Update tlbiel loop on POWER10
On Thu, 22 Oct 2020 14:41:15 +0530, Aneesh Kumar K.V wrote:
> powerpc used to set the pte specific flags in set_pte_at(). This is
> different from other architectures. To be consistent with other
> architecture powerpc updated pfn_pte to set _PAGE_PTE with
> commit 379c926d6334 ("powerpc/mm: move
With virtio multiqueue, normally each queue IRQ is mapped to a CPU.
But since commit 0d9f0a52c8b9f ("virtio_scsi: use virtio IRQ affinity")
this is broken on pseries.
The affinity is correctly computed in msi_desc but this is not applied
to the system IRQs.
It appears the affinity is correctly
This function adds an affinity parameter to irq_create_mapping().
This parameter is needed to pass it to irq_domain_alloc_descs().
irq_create_mapping() is a wrapper around irq_create_mapping_affinity()
to pass NULL for the affinity parameter.
No functional change.
Signed-off-by: Laurent Vivier
With virtio, in multiqueue case, each queue IRQ is normally
bound to a different CPU using the affinity mask.
This works fine on x86_64 but totally ignored on pseries.
This is not obvious at first look because irqbalance is doing
some balancing to improve that.
It appears that the "managed"
diff --git a/arch/powerpc/lib/sstep.c b/arch/powerpc/lib/sstep.c
index 855457ed09b5..25a5436be6c6 100644
--- a/arch/powerpc/lib/sstep.c
+++ b/arch/powerpc/lib/sstep.c
@@ -2157,11 +2157,15 @@ int analyse_instr(struct instruction_op *op, const
struct pt_regs *regs,
case 23: /* lwzx */
Quoting Michael Ellerman :
Christophe Leroy writes:
Le 03/11/2020 à 19:13, Christophe Leroy a écrit :
Le 23/10/2020 à 15:24, Michael Ellerman a écrit :
Christophe Leroy writes:
Le 24/09/2020 à 15:17, Christophe Leroy a écrit :
Le 17/09/2020 à 14:33, Michael Ellerman a écrit :
On Sat, Nov 21, 2020 at 06:42:28AM -0600, Rob Herring wrote:
> On Thu, Nov 12, 2020 at 01:29:46PM +0300, Serge Semin wrote:
> > On Wed, Nov 11, 2020 at 02:14:23PM -0600, Rob Herring wrote:
> > > On Wed, Nov 11, 2020 at 12:08:45PM +0300, Serge Semin wrote:
> > > > DWC USB3 DT node is supposed to be
1 - 100 of 101 matches
Mail list logo
