* Vishal Chourasia [2022-11-19 14:19:52]:
> On Mon, Nov 14, 2022 at 08:26:11PM +0530, Aboorva Devarajan wrote:
> > During the comparative study of cpuidle governors, it is noticed that the
> > menu governor does not select CEDE state in some scenarios even though when
> > the sleep duration of th
On 11/30/22 17:45, Crystal Wood wrote:
On Mon, 2022-11-28 at 14:36 +1000, Nicholas Piggin wrote:
BookE KVM is in a deep maintenance state, I'm not sure how much testing
it gets. I don't have a test setup, and it does not look like QEMU has
any HV architecture enabled. It hasn't been too painf
Hello:
This series was applied to netdev/net-next.git (master)
by Jakub Kicinski :
On Wed, 30 Nov 2022 17:10:35 +0300 you wrote:
> Hello folks,
>
> With this patch series, we're completely getting rid of 'label = "cpu";'
> which is not used by the DSA dt-binding at all.
>
> Information for taki
tree/branch:
https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git master
branch HEAD: 5be860bfc73408bc1a8af9167955e480ecebba84 Add linux-next specific
files for 20221202
Error/Warning reports:
https://lore.kernel.org/oe-kbuild-all/202211041320.coq8eelj-...@intel.com
https
On Thursday 01 December 2022 17:44:00 Rob Herring wrote:
> On Thu, Dec 01, 2022 at 06:39:02PM +0100, Pali Rohár wrote:
> > On Thursday 01 December 2022 21:40:03 Michael Ellerman wrote:
> > > Arınç ÜNAL writes:
> > > > This is not used by the DSA dt-binding, so remove it from all
> > > > devicetre
Le 26/11/2022 à 17:25, Pali Rohár a écrit :
> On Wednesday 02 November 2022 00:25:03 Pali Rohár wrote:
>> On Sunday 16 October 2022 16:59:53 Christophe Leroy wrote:
>>> Hello,
>>>
>>> Le 16/10/2022 à 13:05, Pali Rohár a écrit :
Hello Christophe! Do you have any other comments for this patch
On Thu, Dec 1, 2022 at 12:08 PM Ricardo Ribalda wrote:
>
> Add a way to let the drivers know if the processes are frozen.
>
> This is needed by drivers that are waiting for processes to end on their
> shutdown path.
>
> Convert pm_freezing into a function and export it, so it can be used by
> driv
"make dtbs_check":
arch/arm64/boot/dts/marvell/armada-8040-mcbin.dtb: i2c-switch@70:
$nodename:0: 'i2c-switch@70' does not match '^(i2c-?)?mux'
From schema:
Documentation/devicetree/bindings/i2c/i2c-mux-pca954x.yaml
arch/arm64/boot/dts/marvell/armada-8040-mcbin.dtb: i2c-switc
"make dtbs_check":
arch/arm/boot/dts/aspeed-bmc-bytedance-g220a.dtb: i2c-switch@70:
$nodename:0: 'i2c-switch@70' does not match '^(i2c-?)?mux'
From schema:
Documentation/devicetree/bindings/i2c/i2c-mux-pca954x.yaml
arm/boot/dts/aspeed-bmc-bytedance-g220a.dtb: i2c-switch@70: U
"make dtbs_check":
arch/arm/boot/dts/am3874-iceboard.dtb: pca9548@70: $nodename:0:
'pca9548@70' does not match '^(i2c-?)?mux'
From schema:
Documentation/devicetree/bindings/i2c/i2c-mux-pca954x.yaml
arch/arm/boot/dts/am3874-iceboard.dtb: pca9548@70: Unevaluated properties
are
"make dtbs_check":
arch/arm/boot/dts/socfpga_cyclone5_vining_fpga.dtb: i2cswitch@70:
$nodename:0: 'i2cswitch@70' does not match '^(i2c-?)?mux'
From schema:
Documentation/devicetree/bindings/i2c/i2c-mux-pca954x.yaml
arch/arm/boot/dts/socfpga_cyclone5_vining_fpga.dtb: i2cswitch
Hi all,
According to the I2C bus multiplexer/switch DT bindings, i2c-mux nodes
should be named "i2c-mux" (or something similar).
This patch series renames nodes for pca954x i2c-muxes that are flagged
by
make dtbs_checK
DT_SCHEMA_FILES=Documentation/devicetree/bindings/i2c/i2c-mux-pca
"make dtbs_check":
arch/arm/boot/dts/nuvoton-npcm730-gbs.dtb: i2c-switch@71: $nodename:0:
'i2c-switch@71' does not match '^(i2c-?)?mux'
From schema:
Documentation/devicetree/bindings/i2c/i2c-mux-pca954x.yaml
...
Fix this by renaming PCA954x nodes to "i2c-mux", to match the I
"make dtbs_check":
arch/arm/boot/dts/vf610-zii-dev-rev-b.dtb: tca9548@70: $nodename:0:
'tca9548@70' does not match '^(i2c-?)?mux'
From schema:
Documentation/devicetree/bindings/i2c/i2c-mux-pca954x.yaml
arch/arm/boot/dts/vf610-zii-dev-rev-b.dtb: tca9548@70: Unevaluated
proper
"make dtbs_check":
arch/mips/boot/dts/mscc/jaguar2_pcb110.dtb: pca9545@70: $nodename:0:
'pca9545@70' does not match '^(i2c-?)?mux'
From schema:
Documentation/devicetree/bindings/i2c/i2c-mux-pca954x.yaml
arch/mips/boot/dts/mscc/jaguar2_pcb110.dtb: pca9545@70: Unevaluated
prop
"make dtbs_check":
arch/arm/boot/dts/imx53-ppd.dtb: i2c-switch@70: $nodename:0:
'i2c-switch@70' does not match '^(i2c-?)?mux'
From schema:
Documentation/devicetree/bindings/i2c/i2c-mux-pca954x.yaml
arch/arm/boot/dts/imx53-ppd.dtb: i2c-switch@70: Unevaluated properties are
no
"make dtbs_check":
arch/arm64/boot/dts/freescale/fsl-ls1012a-qds.dtb: pca9547@77: $nodename:0:
'pca9547@77' does not match '^(i2c-?)?mux'
From schema:
Documentation/devicetree/bindings/i2c/i2c-mux-pca954x.yaml
arch/arm64/boot/dts/freescale/fsl-ls1012a-qds.dtb: pca9547@77: Une
"make dtbs_check":
arch/powerpc/boot/dts/fsl/t1040rdb-rev-a.dtb: pca9546@77: $nodename:0:
'pca9546@77' does not match '^(i2c-?)?mux'
From schema:
Documentation/devicetree/bindings/i2c/i2c-mux-pca954x.yaml
arch/powerpc/boot/dts/fsl/t1024qds.dtb: pca9547@77: Unevaluated properti
"make dtbs_check":
arch/arm64/boot/dts/renesas/r8a77951-ulcb-kf.dtb: i2c-switch@71:
$nodename:0: 'i2c-switch@71' does not match '^(i2c-?)?mux'
From schema:
Documentation/devicetree/bindings/i2c/i2c-mux-pca954x.yaml
arch/arm64/boot/dts/renesas/r8a77951-ulcb-kf.dtb: i2c-switch@
On Fri, Dec 02, 2022, Huang, Kai wrote:
> On Wed, 2022-11-30 at 23:09 +, Sean Christopherson wrote:
> > From: Chao Gao
> >
> > Disable CPU hotplug when enabling/disabling hardware to prevent the
> > corner case where if the following sequence occurs:
> >
> > 1. A hotplugged CPU marks itsel
On Fri, Dec 02, 2022, Huang, Kai wrote:
> On Wed, 2022-11-30 at 23:09 +, Sean Christopherson wrote:
> > From: Chao Gao
> >
> ...
>
> >
> > Suggested-by: Thomas Gleixner
> > Signed-off-by: Chao Gao
> > Signed-off-by: Isaku Yamahata
>
> Perhaps I am wrong, but I have memory that if someon
On Fri, Dec 02, 2022, Huang, Kai wrote:
> On Wed, 2022-11-30 at 23:09 +, Sean Christopherson wrote:
> > --- a/arch/x86/kvm/x86.c
> > +++ b/arch/x86/kvm/x86.c
> > @@ -11967,6 +11967,11 @@ int kvm_arch_hardware_enable(void)
> > bool stable, backwards_tsc = false;
> >
> > kvm_user_return
Context
===
The newly-introduced ipi_send_cpumask tracepoint has a "callback" parameter
which so far has only been fed with NULL.
While CSD_TYPE_SYNC/ASYNC and CSD_TYPE_IRQ_WORK share a similar backing
struct layout (meaning their callback func can be accessed without caring
about the actual
Accessing the call_single_queue hasn't involved a spinlock since 2014:
6897fc22ea01 ("kernel: use lockless list for smp_call_function_single")
The llist operations (namely cmpxchg() and xchg()) provide similar ordering
guarantees, update the comment to lessen confusion.
Signed-off-by: Valentin
To be able to trace invocations of smp_send_reschedule(), rename the
arch-specific definitions of it to arch_smp_send_reschedule() and wrap it
into an smp_send_reschedule() that contains a tracepoint.
Changes to include the declaration of the tracepoint were driven by the
following coccinelle scri
send_call_function_single_ipi() is the thing that sends IPIs at the bottom
of smp_call_function*() via either generic_exec_single() or
smp_call_function_many_cond(). Give it an IPI-related tracepoint.
Note that this ends up tracing any IPI sent via __smp_call_single_queue(),
which covers __ttwu_qu
IPIs sent to remote CPUs via irq_work_queue_on() are now covered by
trace_ipi_send_cpumask(), add another instance of the tracepoint to cover
self-IPIs.
Signed-off-by: Valentin Schneider
Reviewed-by: Steven Rostedt (Google)
---
kernel/irq_work.c | 14 +-
1 file changed, 13 insertion
This simply wraps around the arch function and prepends it with a
tracepoint, similar to send_call_function_single_ipi().
Signed-off-by: Valentin Schneider
Reviewed-by: Steven Rostedt (Google)
---
kernel/smp.c | 9 -
1 file changed, 8 insertions(+), 1 deletion(-)
diff --git a/kernel/sm
trace_ipi_raise() is unsuitable for generically tracing IPI sources due to
its "reason" argument being an uninformative string (on arm64 all you get
is "Function call interrupts" for SMP calls).
Add a variant of it that exports a target CPU, a callsite and a callback.
Signed-off-by: Valentin Schn
From: "Steven Rostedt (Google)"
The trace events have a __bitmask field that can be used for anything
that requires bitmasks. Although currently it is only used for CPU
masks, it could be used in the future for any type of bitmasks.
There is some user space tooling that wants to know if a field
Background
==
Detecting IPI *reception* is relatively easy, e.g. using
trace_irq_handler_{entry,exit} or even just function-trace
flush_smp_call_function_queue() for SMP calls.
Figuring out their *origin*, is trickier as there is no generic tracepoint tied
to e.g. smp_call_function():
On Fri, 2022-12-02 at 07:56 +0100, Hannes Reinecke wrote:
> On 12/1/22 19:03, Greg Joyce wrote:
> > On Wed, 2022-11-30 at 08:00 +0100, Hannes Reinecke wrote:
> > > On 11/30/22 00:25, gjo...@linux.vnet.ibm.com wrote:
> > > > From: Greg Joyce
> > > >
> > > > Extend the SED block driver so it can al
On Wed, 2022-11-30 at 23:09 +, Sean Christopherson wrote:
> --- a/arch/x86/kvm/x86.c
> +++ b/arch/x86/kvm/x86.c
> @@ -11967,6 +11967,11 @@ int kvm_arch_hardware_enable(void)
> bool stable, backwards_tsc = false;
>
> kvm_user_return_msr_cpu_online();
> +
> + ret = kvm_x86_check
On Wed, 2022-11-30 at 23:09 +, Sean Christopherson wrote:
> From: Chao Gao
>
...
>
> Suggested-by: Thomas Gleixner
> Signed-off-by: Chao Gao
> Signed-off-by: Isaku Yamahata
Perhaps I am wrong, but I have memory that if someone has SoB but isn't the
original author should also have a Co-
On Wed, 2022-11-30 at 23:09 +, Sean Christopherson wrote:
> From: Chao Gao
>
> Do compatibility checks when enabling hardware to effectively add
> compatibility checks when onlining a CPU. Abort enabling, i.e. the
> online process, if the (hotplugged) CPU is incompatible with the known
> goo
On Wed, 2022-11-30 at 23:09 +, Sean Christopherson wrote:
> Move the .check_processor_compatibility() callback from kvm_x86_init_ops
> to kvm_x86_ops to allow a future patch to do compatibility checks during
> CPU hotplug.
>
> Do kvm_ops_update() before compat checks so that static_call() can
On Wed, 2022-11-30 at 23:09 +, Sean Christopherson wrote:
> From: Chao Gao
>
> Disable CPU hotplug when enabling/disabling hardware to prevent the
> corner case where if the following sequence occurs:
>
> 1. A hotplugged CPU marks itself online in cpu_online_mask
> 2. The hotplugged CPU
On Wed, 2022-11-30 at 23:09 +, Sean Christopherson wrote:
> Use this_cpu_has() instead of boot_cpu_has() to perform the effective
> "disabled by BIOS?" checks for VMX. This will allow consolidating code
> between vmx_disabled_by_bios() and vmx_check_processor_compat().
>
> Checking the boot C
On Wed, 2022-11-30 at 23:09 +, Sean Christopherson wrote:
> Drop kvm_arch_check_processor_compat() and its support code now that all
> architecture implementations are nops.
>
> Signed-off-by: Sean Christopherson
> Reviewed-by: Philippe Mathieu-Daudé
> Reviewed-by: Eric Farman# s390
On Wed, 2022-11-30 at 23:09 +, Sean Christopherson wrote:
> Move the CPU compatibility checks to pure x86 code, i.e. drop x86's use
> of the common kvm_x86_check_cpu_compat() arch hook. x86 is the only
^
kvm_arch_check_processor_compat()
> architecture that "ne
On 12/2/22 12:04, Daniel Henrique Barboza wrote:
On 11/30/22 17:45, Crystal Wood wrote:
On Mon, 2022-11-28 at 14:36 +1000, Nicholas Piggin wrote:
BookE KVM is in a deep maintenance state, I'm not sure how much testing
it gets. I don't have a test setup, and it does not look like QEMU has
any
On Wed, Nov 30, 2022 at 05:08:06PM -0800, Stefano Stabellini wrote:
> On Wed, 30 Nov 2022, Roger Pau Monne wrote:
> > The hvc machinery registers both a console and a tty device based on
> > the hv ops provided by the specific implementation. Those two
> > interfaces however have different locks,
Benjamin Gray writes:
> File read/write is reimplemented in about 5 different ways in the
> various PowerPC selftests. This indicates it should be a common util.
>
> Add a common read_file / write_file implementation and convert users
> to it where (easily) possible.
>
> Signed-off-by: Benjamin Gr
Stephen Rothwell writes:
> Hi all,
>
> After merging the tip tree, today's linux-next build (powerpc
> ppc64_defconfig) failed like this:
>
> arch/powerpc/lib/code-patching.c: In function 'text_area_cpu_up_mm':
> arch/powerpc/lib/code-patching.c:157:14: error: implicit declaration of
> function '
Stephen Rothwell writes:
> Hi all,
>
> After merging all the trees, today's linux-next qemu run (powerpc
> pseries_le_defconfig with kvm) crashed like this:
>
> Memory: 2029504K/2097152K available (14592K kernel code, 2944K rwdata, 18176K
> rodata, 5120K init, 1468K bss, 67648K reserved, 0K cma-r
Several fonctions have the same loop for patching instructions.
Introduce function do_patch_fixups() to refactor those loops.
Signed-off-by: Christophe Leroy
---
arch/powerpc/lib/feature-fixups.c | 77 +++
1 file changed, 28 insertions(+), 49 deletions(-)
diff --git
Several fonctions have the same loop for patching instructions.
Introduce function do_patch_entry_fixups() to refactor those loops.
Signed-off-by: Christophe Leroy
---
arch/powerpc/lib/feature-fixups.c | 84 ---
1 file changed, 32 insertions(+), 52 deletions(-)
diff
Once init section is freed, attempting to patch init code
ends up in the weed.
Commit 51c3c62b58b3 ("powerpc: Avoid code patching freed init sections")
protected patch_instruction() against that, but it is the responsibility
of the caller to ensure that the patched memory is valid.
All callers ha
Once init section is freed, attempting to patch init code
ends up in the weed.
Commit 51c3c62b58b3 ("powerpc: Avoid code patching freed init sections")
protected patch_instruction() against that, but it is the responsibility
of the caller to ensure that the patched memory is valid.
In the same sp
No need to have one implementation of patch_instruction() for
CONFIG_STRICT_KERNEL_RWX and one for !CONFIG_STRICT_KERNEL_RWX.
In patch_instruction(), call raw_patch_instruction() when
!CONFIG_STRICT_KERNEL_RWX.
In poking_init(), bail out immediately, it will be equivalent
to the weak default impl
On Wed, Nov 30, 2022 at 11:08:44PM +, Sean Christopherson wrote:
>The main theme of this series is to kill off kvm_arch_init(),
>kvm_arch_hardware_(un)setup(), and kvm_arch_check_processor_compat(), which
>all originated in x86 code from way back when, and needlessly complicate
>both common KVM
51 matches
Mail list logo
