Linus Walleij writes:
> On Mon, Oct 4, 2021 at 9:52 PM Rob Herring wrote:
>
>> FYI, I pushed patches 1-3 to kernelCI and didn't see any regressions.
>> I am a bit worried about changes to the DT interrupt parsing and
>> ancient platforms (such as PowerMacs). Most likely there wouldn't be
>> any
Le 05/10/2021 à 22:25, Naveen N. Rao a écrit :
Suppress emitting zero extend instruction for 64-bit BPF_END_FROM_[L|B]E
operation.
Fixes: 51c66ad849a703 ("powerpc/bpf: Implement extended BPF on PPC32")
Signed-off-by: Naveen N. Rao
Reviewed-by: Christophe Leroy
---
Le 05/10/2021 à 22:25, Naveen N. Rao a écrit :
Special case handling of the smallest 32-bit negative number for BPF_SUB.
Fixes: 51c66ad849a703 ("powerpc/bpf: Implement extended BPF on PPC32")
Signed-off-by: Naveen N. Rao
Reviewed-by: Christophe Leroy
---
Le 05/10/2021 à 22:25, Naveen N. Rao a écrit :
'andi' only takes an unsigned 16-bit value. Correct the imm range used
when emitting andi.
Fixes: 51c66ad849a703 ("powerpc/bpf: Implement extended BPF on PPC32")
Signed-off-by: Naveen N. Rao
Reviewed-by: Christophe Leroy
---
Le 05/10/2021 à 22:25, Naveen N. Rao a écrit :
Correct the destination register used for ALU32 BPF_ARSH operation.
Fixes: 51c66ad849a703 ("powerpc/bpf: Implement extended BPF on PPC32")
Signed-off-by: Naveen N. Rao
Reviewed-by: Christophe Leroy
---
arch/powerpc/net/bpf_jit_comp32.c |
Le 05/10/2021 à 22:25, Naveen N. Rao a écrit :
We aren't handling subtraction involving an immediate value of
0x8000 properly. Fix the same.
Fixes: 156d0e290e969c ("powerpc/ebpf/jit: Implement JIT compiler for extended
BPF")
Signed-off-by: Naveen N. Rao
---
Changelog:
- Split up
Le 05/10/2021 à 22:25, Naveen N. Rao a écrit :
Only ignore the operation if dividing by 1.
Acked-by: Song Liu
Acked-by: Johan Almbladh
Tested-by: Johan Almbladh
Fixes: 156d0e290e969c ("powerpc/ebpf/jit: Implement JIT compiler for extended
BPF")
Signed-off-by: Naveen N. Rao
Le 05/10/2021 à 22:25, Naveen N. Rao a écrit :
> Add checks to ensure that we never emit branch instructions with
> truncated branch offsets.
>
> Acked-by: Song Liu
> Acked-by: Johan Almbladh
> Tested-by: Johan Almbladh
> Suggested-by: Michael Ellerman
> Signed-off-by: Naveen N. Rao
Le 05/10/2021 à 22:25, Naveen N. Rao a écrit :
Add checks to ensure that we never emit branch instructions with
truncated branch offsets.
Acked-by: Song Liu
Acked-by: Johan Almbladh
Tested-by: Johan Almbladh
Suggested-by: Michael Ellerman
Signed-off-by: Naveen N. Rao
Reviewed-by:
Le 05/10/2021 à 22:25, Naveen N. Rao a écrit :
Add a helper to check if a given offset is within the branch range for a
powerpc conditional branch instruction, and update some sites to use the
new helper.
Acked-by: Song Liu
Signed-off-by: Naveen N. Rao
Reviewed-by: Christophe Leroy
The upcoming PAPR spec adds a 2M page size, bit 23 right after 16G page
size in the "ibm,query-pe-dma-window" call.
This adds support for the new page size. Since the new page size is out
of sorted order, this changes the loop to not assume that shift[] is
sorted.
This has now been tested and is
Hi Joel,
> The series looks good.
>
> I've got a couple of patches on the ipmi list that this will conflict
> with:
>
> https://sourceforge.net/p/openipmi/mailman/message/37345391/
> https://lore.kernel.org/all/20210903015314.177987-1-j...@jms.id.au/
>
> If there's no feedback from others I
Hi Anton,
On Wed, 6 Oct 2021 at 02:12, Anton Blanchard wrote:
>
> This adds the Microwatt specific bits, including interrupt support.
The series looks good.
I've got a couple of patches on the ipmi list that this will conflict with:
This adds the Microwatt specific bits, including interrupt support.
Signed-off-by: Anton Blanchard
---
.../devicetree/bindings/ipmi/ibt-bmc.txt | 1 +
drivers/char/ipmi/Kconfig | 8 ++-
drivers/char/ipmi/bt-bmc.c| 69 +++
3 files
The driver is no longer specific to ASPEED, so rename the config option
and remove the dependency on ARCH_ASPEED.
Signed-off-by: Anton Blanchard
---
.../bindings/ipmi/{aspeed,ast2400-ibt-bmc.txt => ibt-bmc.txt} | 2 +-
arch/arm/configs/aspeed_g4_defconfig| 2 +-
While most of the driver is arch agnostic, setting up and handling
interrupts, and enabling the hardware is not. Create bt_bmc_ops to
handle these functions.
Signed-off-by: Anton Blanchard
---
drivers/char/ipmi/bt-bmc.c | 24
1 file changed, 20 insertions(+), 4
Signed-off-by: Anton Blanchard
---
drivers/char/ipmi/bt-bmc.c | 16
1 file changed, 8 insertions(+), 8 deletions(-)
diff --git a/drivers/char/ipmi/bt-bmc.c b/drivers/char/ipmi/bt-bmc.c
index f85fafc96ef6..2b0fe1255026 100644
--- a/drivers/char/ipmi/bt-bmc.c
+++
Most of the IPMI BT BMC driver is architecture agnostic - it deals with
architected registers and behaviour in the IPMI specification.
Separate out the few ASPEED specific bits into their own functions
so we can use this driver on other architectures.
Signed-off-by: Anton Blanchard
---
Suppress emitting zero extend instruction for 64-bit BPF_END_FROM_[L|B]E
operation.
Fixes: 51c66ad849a703 ("powerpc/bpf: Implement extended BPF on PPC32")
Signed-off-by: Naveen N. Rao
---
arch/powerpc/net/bpf_jit_comp32.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git
Special case handling of the smallest 32-bit negative number for BPF_SUB.
Fixes: 51c66ad849a703 ("powerpc/bpf: Implement extended BPF on PPC32")
Signed-off-by: Naveen N. Rao
---
arch/powerpc/net/bpf_jit_comp32.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git
'andi' only takes an unsigned 16-bit value. Correct the imm range used
when emitting andi.
Fixes: 51c66ad849a703 ("powerpc/bpf: Implement extended BPF on PPC32")
Signed-off-by: Naveen N. Rao
---
arch/powerpc/net/bpf_jit_comp32.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git
Correct the destination register used for ALU32 BPF_ARSH operation.
Fixes: 51c66ad849a703 ("powerpc/bpf: Implement extended BPF on PPC32")
Signed-off-by: Naveen N. Rao
---
arch/powerpc/net/bpf_jit_comp32.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git
Emit similar instruction sequences to commit a048a07d7f4535
("powerpc/64s: Add support for a store forwarding barrier at kernel
entry/exit") when encountering BPF_NOSPEC.
Mitigations are enabled depending on what the firmware advertises. In
particular, we do not gate these mitigations based on
Add a helper to return the stf_barrier type for the current processor.
Signed-off-by: Naveen N. Rao
---
arch/powerpc/include/asm/security_features.h | 5 +
arch/powerpc/kernel/security.c | 5 +
2 files changed, 10 insertions(+)
diff --git
We aren't handling subtraction involving an immediate value of
0x8000 properly. Fix the same.
Fixes: 156d0e290e969c ("powerpc/ebpf/jit: Implement JIT compiler for extended
BPF")
Signed-off-by: Naveen N. Rao
---
Changelog:
- Split up BPF_ADD and BPF_SUB cases per Christophe's comments
Only ignore the operation if dividing by 1.
Acked-by: Song Liu
Acked-by: Johan Almbladh
Tested-by: Johan Almbladh
Fixes: 156d0e290e969c ("powerpc/ebpf/jit: Implement JIT compiler for extended
BPF")
Signed-off-by: Naveen N. Rao
---
arch/powerpc/net/bpf_jit_comp64.c | 10 --
1 file
Add checks to ensure that we never emit branch instructions with
truncated branch offsets.
Acked-by: Song Liu
Acked-by: Johan Almbladh
Tested-by: Johan Almbladh
Suggested-by: Michael Ellerman
Signed-off-by: Naveen N. Rao
---
arch/powerpc/net/bpf_jit.h| 26 --
Add a helper to check if a given offset is within the branch range for a
powerpc conditional branch instruction, and update some sites to use the
new helper.
Acked-by: Song Liu
Signed-off-by: Naveen N. Rao
---
Changelog:
- Change 0x7FFF to 0x7fff, per Christophe
This is v2 of the series posted at:
http://lkml.kernel.org/r/cover.1633104510.git.naveen.n@linux.vnet.ibm.com
Only patches from v1 that need to go into powerpc/fixes are included.
Other patches will be posted as a separate series for inclusion into
powerpc/next.
Patches 7 to 10 are new and
Christophe Leroy wrote:
Le 04/10/2021 à 20:11, Naveen N. Rao a écrit :
Christophe Leroy wrote:
Le 01/10/2021 à 23:14, Naveen N. Rao a écrit :
From: Ravi Bangoria
SEEN_STACK is unused on PowerPC. Remove it. Also, have
SEEN_TAILCALL use 0x4000.
Why change SEEN_TAILCALL ? Would it be
On Tue, Oct 05, 2021 at 02:48:35PM +0530, Kajol Jain wrote:
> Going forward, future generation systems can have more hierarchy
> within the chip/package level but currently we don't have any data source
> encoding field in perf, which can be used to represent this level of data.
>
> Add a new
Print the contents of Device Control Register of the device which
detected the error. This might help in faster error diagnosis.
Sample output from dummy error injected by aer-inject:
pcieport :00:03.0: AER: Corrected error received: :00:03.0
pcieport :00:03.0: PCIe Bus Error:
pcie_do_recovery() is shared across the following paths:
- ACPI APEI
- Native AER path
- EDR
- DPC
ACPI APEI
==
ghes_handle_aer()
aer_recover_queue()
kfifo_in_spinlocked(aer_recover_ring)
aer_recover_work_func()
while (kfifo_get(aer_recover_ring))
Converge the APEI path and native AER path of clearing the AER registers
of the error device.
In APEI path, the system firmware clears the AER registers before
handing off the record to OS. But in "native AER" path, the execution
path of clearing the AER register is as follows:
In the EDR path, AER registers are cleared *after* DPC error event is
processed. The process stack in EDR is:
edr_handle_event()
dpc_process_error()
pci_aer_raw_clear_status()
pcie_do_recovery()
But in DPC path, AER status registers are cleared *while* processing
the error. The
dpc_process_error() clears both AER fatal and non fatal status
registers. Instead of clearing each status registers via a different
function call use pci_aer_clear_status().
This helps clean up the code a bit.
Signed-off-by: Naveen Naidu
---
drivers/pci/pcie/dpc.c | 3 +--
1 file changed, 1
In the dpc_process_error() path, info->id isn't initialized before being
passed to aer_print_error(). In the corresponding AER path, it is
initialized in aer_isr_one_error().
The error message shown during Coverity Scan is:
Coverity #1461602
CID 1461602 (#1 of 1): Uninitialized scalar
The id, status and the mask fields of the struct aer_err_info comes
directly from the registers, hence their sizes should be explicit.
The length of these registers are:
- id: 16 bits - Represents the Error Source Requester ID
- status: 32 bits - COR/UNCOR Error Status
- mask: 32 bits -
Currently, we do not print the "id" field in the AER error logs. Yet the
aer_agent_string[] has the word "id" in it. The AER error log looks
like:
pcieport :00:03.0: PCIe Bus Error: severity=Corrected, type=Data Link
Layer, (Receiver ID)
Without the "id" field in the error log, The
This patch series aims at fixing some of the AER error handling issues
we have.
Currently we have the following issues:
- Confusing message in aer_print_error()
- aer_err_info not being initialized completely in DPC path before
we print the AER logs
- A bug [1] in clearing of AER registers
On 9/29/21 8:35 AM, David Hildenbrand wrote:
CONFIG_MEMORY_HOTPLUG depends on CONFIG_SPARSEMEM, so there is no need for
CONFIG_MEMORY_HOTPLUG_SPARSE anymore; adjust all instances to use
CONFIG_MEMORY_HOTPLUG and remove CONFIG_MEMORY_HOTPLUG_SPARSE.
Signed-off-by: David Hildenbrand
---
On Wed, Sep 29, 2021 at 04:35:56PM +0200, David Hildenbrand wrote:
> CONFIG_MEMORY_HOTPLUG depends on CONFIG_SPARSEMEM, so there is no need for
> CONFIG_MEMORY_HOTPLUG_SPARSE anymore; adjust all instances to use
> CONFIG_MEMORY_HOTPLUG and remove CONFIG_MEMORY_HOTPLUG_SPARSE.
>
> Signed-off-by:
On Mon, 04 Oct 2021 21:42:45 +0100,
Linus Walleij wrote:
>
> On Mon, Oct 4, 2021 at 9:52 PM Rob Herring wrote:
>
> > FYI, I pushed patches 1-3 to kernelCI and didn't see any regressions.
> > I am a bit worried about changes to the DT interrupt parsing and
> > ancient platforms (such as
Hi,
Sorry I missed to update correct version details.
Link to the previous patch-set, where discussion related to addition of
new data source encoding field 'mem_hops' happened:
https://lkml.org/lkml/2021/9/4/37
Changelog:
- Rather then adding new macros for L2.1/L3.1 (same chip, different
Fix the data source encodings to represent L2.1/L3.1(another core's
L2/L3 on the same chip) accesses properly for power10 and older
plaforms.
Add new macros(LEVEL/REM) which can be used to add mem_lvl_num and remote
field data inside perf_mem_data_src structure.
Result in power9 system with
Going forward, future generation systems can have more hierarchy
within the chip/package level but currently we don't have any data source
encoding field in perf, which can be used to represent this level of data.
Add a new field called 'mem_hops' in the perf_mem_data_src structure
which can be
Going forward, future generation systems can have more hierarchy
within the chip/package level but currently we don't have any data source
encoding field in perf, which can be used to represent this level of data.
Add a new field called 'mem_hops' in the perf_mem_data_src structure
which can be
Add a comment about PERF_MEM_LVL_* namespace being depricated
to some extent in favour of added PERF_MEM_{LVLNUM_,REMOTE_,SNOOPX_}
fields.
Remove an extra line present in perf_mem__lvl_scnprintf function.
Signed-off-by: Kajol Jain
---
include/uapi/linux/perf_event.h | 8 +++-
On 04/10/21 21:36, Aneesh Kumar K.V wrote:
On 10/4/21 20:41, Sourabh Jain wrote:
On large config LPARs (having 192 and more cores), Linux fails to boot
due to insufficient memory in the first memory block. It is due to the
reserve crashkernel area starts at 128MB offset by default and which
Hi Naveen,
Thank you for the patch! Perhaps something to improve:
[auto build test WARNING on helgaas-pci/next]
[also build test WARNING on linux/master linus/master v5.15-rc3 next-20210921]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we
Hi Sourabh,
Thank you for the patch! Yet something to improve:
[auto build test ERROR on powerpc/next]
[also build test ERROR on linux/master linus/master v5.15-rc3 next-20210922]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we suggest to use
51 matches
Mail list logo
