Applied "mfd: arizona: Remove audio bindings from MFD binding document" to the asoc tree

The patch mfd: arizona: Remove audio bindings from MFD binding document has been applied to the asoc tree at git://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git All being well this means that it will be integrated into the linux-next tree (usually sometime in the next 24

Applied "mfd: arizona: Remove audio bindings from MFD binding document" to the asoc tree

The patch mfd: arizona: Remove audio bindings from MFD binding document has been applied to the asoc tree at git://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git All being well this means that it will be integrated into the linux-next tree (usually sometime in the next 24

[PATCH 3/7] smp/hotplug: Rewrite AP state machine core

There is currently no explicit state change on rollback. That is, st->bringup, st->rollback and st->target are not consistent when doing the rollback. Rework the AP state handling to be more coherent. This does mean we have to do a second AP kick-and-wait for rollback, but since rollback is the

[PATCH 3/7] smp/hotplug: Rewrite AP state machine core

There is currently no explicit state change on rollback. That is, st->bringup, st->rollback and st->target are not consistent when doing the rollback. Rework the AP state handling to be more coherent. This does mean we have to do a second AP kick-and-wait for rollback, but since rollback is the

[PATCH 6/7] smp/hotplug: Differentiate the AP-work lockdep class between up and down

With lockdep-crossrelease we get deadlock reports that span cpu-up and cpu-down chains. Such deadlocks cannot possibly happen because cpu-up and cpu-down are globally serialized. CPU0 CPU1CPU2 cpuhp_up_callbacks: takedown_cpu: cpuhp_thread_fun:

[PATCH 6/7] smp/hotplug: Differentiate the AP-work lockdep class between up and down

With lockdep-crossrelease we get deadlock reports that span cpu-up and cpu-down chains. Such deadlocks cannot possibly happen because cpu-up and cpu-down are globally serialized. CPU0 CPU1CPU2 cpuhp_up_callbacks: takedown_cpu: cpuhp_thread_fun:

[PATCH 5/7] smp/hotplug: Differentiate the AP completion between up and down

With lockdep-crossrelease we get deadlock reports that span cpu-up and cpu-down chains. Such deadlocks cannot possibly happen because cpu-up and cpu-down are globally serialized. takedown_cpu() irq_lock_sparse() wait_for_completion(>done)

[PATCH 0/7] smp/hotplug rework / lockdep annotate

These here patches rework the cpu hotplug state machine and add two lockdep (crossrelease) annotations. The rework is quite invasive, but was suggested by Thomas as being the right way to go about doing things :-) These patches have been tested with Steve's hotplug stress script, as well as two

[PATCH 7/7] smp/hotplug: Hotplug state fail injection

Add a sysfs file to one-time fail a specific state. This can be used to test the state rollback code paths. Something like this (hotplug-up.sh): #!/bin/bash echo 0 > /debug/sched_debug echo 1 > /debug/tracing/events/cpuhp/enable ALL_STATES=`cat /sys/devices/system/cpu/hotplug/states |

[PATCH 4/7] smp/hotplug: Callback vs state-machine consistency

While the generic callback functions have an 'int' return and thus appear to be allowed to return error, this is not true for all states. Specifically, what used to be STARTING/DYING are ran with IRQs disabled from critical parts of CPU bringup/teardown and are not allowed to fail. Add WARNs to

[PATCH 5/7] smp/hotplug: Differentiate the AP completion between up and down

With lockdep-crossrelease we get deadlock reports that span cpu-up and cpu-down chains. Such deadlocks cannot possibly happen because cpu-up and cpu-down are globally serialized. takedown_cpu() irq_lock_sparse() wait_for_completion(>done)

[PATCH 0/7] smp/hotplug rework / lockdep annotate

These here patches rework the cpu hotplug state machine and add two lockdep (crossrelease) annotations. The rework is quite invasive, but was suggested by Thomas as being the right way to go about doing things :-) These patches have been tested with Steve's hotplug stress script, as well as two

[PATCH 7/7] smp/hotplug: Hotplug state fail injection

Add a sysfs file to one-time fail a specific state. This can be used to test the state rollback code paths. Something like this (hotplug-up.sh): #!/bin/bash echo 0 > /debug/sched_debug echo 1 > /debug/tracing/events/cpuhp/enable ALL_STATES=`cat /sys/devices/system/cpu/hotplug/states |

[PATCH 4/7] smp/hotplug: Callback vs state-machine consistency

While the generic callback functions have an 'int' return and thus appear to be allowed to return error, this is not true for all states. Specifically, what used to be STARTING/DYING are ran with IRQs disabled from critical parts of CPU bringup/teardown and are not allowed to fail. Add WARNs to

[PATCH 2/7] smp/hotplug: Allow external multi-instance rollback

Currently the rollback of multi-instance states is handled inside cpuhp_invoke_callback(). The problem is that when we want to allow an explicit state change for rollback, we need to return from the function without doing the rollback. Change cpuhp_invoke_callback() to optionally return the

[PATCH 2/7] smp/hotplug: Allow external multi-instance rollback

Currently the rollback of multi-instance states is handled inside cpuhp_invoke_callback(). The problem is that when we want to allow an explicit state change for rollback, we need to return from the function without doing the rollback. Change cpuhp_invoke_callback() to optionally return the

Re: [PATCH] PM / OPP: Call notifier without holding opp_table->lock

On 20-09-17, 10:00, Stephen Boyd wrote: > On 09/20, Viresh Kumar wrote: > > diff --git a/drivers/base/power/opp/core.c b/drivers/base/power/opp/core.c > > index 4360b4efcd4c..668fd940d362 100644 > > --- a/drivers/base/power/opp/core.c > > +++ b/drivers/base/power/opp/core.c > > @@ -1627,6 +1627,9

Re: [PATCH] PM / OPP: Call notifier without holding opp_table->lock

On 20-09-17, 10:00, Stephen Boyd wrote: > On 09/20, Viresh Kumar wrote: > > diff --git a/drivers/base/power/opp/core.c b/drivers/base/power/opp/core.c > > index 4360b4efcd4c..668fd940d362 100644 > > --- a/drivers/base/power/opp/core.c > > +++ b/drivers/base/power/opp/core.c > > @@ -1627,6 +1627,9

[PATCH 1/7] smp/hotplug: Add state diagram

Add a state diagram to clarify when which states are ran where. Signed-off-by: Peter Zijlstra (Intel) --- include/linux/cpuhotplug.h | 18 ++ 1 file changed, 18 insertions(+) --- a/include/linux/cpuhotplug.h +++ b/include/linux/cpuhotplug.h @@ -3,6 +3,24

[PATCH 1/7] smp/hotplug: Add state diagram

Add a state diagram to clarify when which states are ran where. Signed-off-by: Peter Zijlstra (Intel) --- include/linux/cpuhotplug.h | 18 ++ 1 file changed, 18 insertions(+) --- a/include/linux/cpuhotplug.h +++ b/include/linux/cpuhotplug.h @@ -3,6 +3,24 @@ #include +/*

[PATCH 5/5] [media] s2255drv: Delete an unnecessary return statement in five functions

From: Markus Elfring Date: Wed, 20 Sep 2017 17:50:36 +0200 The script "checkpatch.pl" pointed information out like the following. WARNING: void function return statements are not generally useful Thus remove such a statement in the affected functions.

[PATCH 5/5] [media] s2255drv: Delete an unnecessary return statement in five functions

From: Markus Elfring Date: Wed, 20 Sep 2017 17:50:36 +0200 The script "checkpatch.pl" pointed information out like the following. WARNING: void function return statements are not generally useful Thus remove such a statement in the affected functions. Signed-off-by: Markus Elfring ---

[PATCH 4/5] [media] s2255drv: Use common error handling code in read_pipe_completion()

From: Markus Elfring Date: Wed, 20 Sep 2017 17:45:13 +0200 Add a jump target so that a bit of exception handling can be better reused at the end of this function. Signed-off-by: Markus Elfring --- drivers/media/usb/s2255/s2255drv.c

[PATCH 4/5] [media] s2255drv: Use common error handling code in read_pipe_completion()

From: Markus Elfring Date: Wed, 20 Sep 2017 17:45:13 +0200 Add a jump target so that a bit of exception handling can be better reused at the end of this function. Signed-off-by: Markus Elfring --- drivers/media/usb/s2255/s2255drv.c | 17 + 1 file changed, 9 insertions(+), 8

Re: [PATCH] [media] staging: atomisp: use clock framework for camera clocks

On 09/20/2017 04:12 AM, Andy Shevchenko wrote: On Tue, 2017-09-19 at 15:45 -0500, Pierre-Louis Bossart wrote: The Atom ISP driver initializes and configures PMC clocks which are already handled by the clock framework. Remove all legacy vlv2_platform_clock stuff and move to the clk API to

Re: [PATCH] [media] staging: atomisp: use clock framework for camera clocks

On 09/20/2017 04:12 AM, Andy Shevchenko wrote: On Tue, 2017-09-19 at 15:45 -0500, Pierre-Louis Bossart wrote: The Atom ISP driver initializes and configures PMC clocks which are already handled by the clock framework. Remove all legacy vlv2_platform_clock stuff and move to the clk API to

[PATCH 3/5] [media] s2255drv: Improve two size determinations in s2255_probe()

From: Markus Elfring Date: Wed, 20 Sep 2017 16:56:20 +0200 Replace the specification of data structures by variable references as the parameter for the operator "sizeof" to make the corresponding size determination a bit safer according to the Linux coding style

[PATCH 3/5] [media] s2255drv: Improve two size determinations in s2255_probe()

From: Markus Elfring Date: Wed, 20 Sep 2017 16:56:20 +0200 Replace the specification of data structures by variable references as the parameter for the operator "sizeof" to make the corresponding size determination a bit safer according to the Linux coding style convention. Signed-off-by:

Re: [PATCH] PM / OPP: Call notifier without holding opp_table->lock

On 09/20, Viresh Kumar wrote: > The notifier callbacks may want to call some OPP helper routines which > may try to take the same opp_table->lock again and cause a deadlock. One > such usecase was reported by Chanwoo Choi, where calling > dev_pm_opp_disable() leads us to the devfreq's OPP notifier

Re: [PATCH] PM / OPP: Call notifier without holding opp_table->lock

On 09/20, Viresh Kumar wrote: > The notifier callbacks may want to call some OPP helper routines which > may try to take the same opp_table->lock again and cause a deadlock. One > such usecase was reported by Chanwoo Choi, where calling > dev_pm_opp_disable() leads us to the devfreq's OPP notifier

[PATCH 2/5] [media] s2255drv: Adjust 13 checks for null pointers

From: Markus Elfring Date: Wed, 20 Sep 2017 16:46:19 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit The script “checkpatch.pl” pointed information out like the following. Comparison to NULL could be written !… Thus

[PATCH 2/5] [media] s2255drv: Adjust 13 checks for null pointers

From: Markus Elfring Date: Wed, 20 Sep 2017 16:46:19 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit The script “checkpatch.pl” pointed information out like the following. Comparison to NULL could be written !… Thus fix the affected source code

Re: [PATCH] PM / OPP: Handle return value of kasprintf

Hi, On Wednesday 20 September 2017 08:19 PM, Viresh Kumar wrote: On 20-09-17, 04:17, Joe Perches wrote: On Wed, 2017-09-20 at 12:29 +0530, Arvind Yadav wrote: kasprintf() can fail here and we must check its return value. [] diff --git a/drivers/base/power/opp/debugfs.c

Re: [PATCH] PM / OPP: Handle return value of kasprintf

Hi, On Wednesday 20 September 2017 08:19 PM, Viresh Kumar wrote: On 20-09-17, 04:17, Joe Perches wrote: On Wed, 2017-09-20 at 12:29 +0530, Arvind Yadav wrote: kasprintf() can fail here and we must check its return value. [] diff --git a/drivers/base/power/opp/debugfs.c

[PATCH 1/5] [media] s2255drv: Delete three error messages for a failed memory allocation in s2255_probe()

From: Markus Elfring Date: Wed, 20 Sep 2017 16:30:13 +0200 Omit extra messages for a memory allocation failure in this function. This issue was detected by using the Coccinelle software. Signed-off-by: Markus Elfring ---

[PATCH 1/5] [media] s2255drv: Delete three error messages for a failed memory allocation in s2255_probe()

From: Markus Elfring Date: Wed, 20 Sep 2017 16:30:13 +0200 Omit extra messages for a memory allocation failure in this function. This issue was detected by using the Coccinelle software. Signed-off-by: Markus Elfring --- drivers/media/usb/s2255/s2255drv.c | 13 - 1 file changed,

[PATCH 0/5] [media] s2255drv: Fine-tuning for some function implementations

From: Markus Elfring Date: Wed, 20 Sep 2017 18:18:28 +0200 A few update suggestions were taken into account from static source code analysis. Markus Elfring (5): Delete three error messages for a failed memory allocation in s2255_probe() Adjust 13 checks for

[PATCH 0/5] [media] s2255drv: Fine-tuning for some function implementations

From: Markus Elfring Date: Wed, 20 Sep 2017 18:18:28 +0200 A few update suggestions were taken into account from static source code analysis. Markus Elfring (5): Delete three error messages for a failed memory allocation in s2255_probe() Adjust 13 checks for null pointers Improve two size

Re: [PATCH 0/3] Add and enable DSP device on OMAPL138 LCDK board

On 09/20/2017 10:14 AM, Sekhar Nori wrote: > Hi Suman, > > On Tuesday 19 September 2017 05:58 AM, Suman Anna wrote: >> Hi Sekhar, >> >> The following series adds the DT node for the DSP device present on >> on DA850/OMAPL138 SoCs. The node is disabled in the base dts file, and >> enabled in the

Re: [PATCH 0/3] Add and enable DSP device on OMAPL138 LCDK board

On 09/20/2017 10:14 AM, Sekhar Nori wrote: > Hi Suman, > > On Tuesday 19 September 2017 05:58 AM, Suman Anna wrote: >> Hi Sekhar, >> >> The following series adds the DT node for the DSP device present on >> on DA850/OMAPL138 SoCs. The node is disabled in the base dts file, and >> enabled in the

Re: 4.13 breaks suspend to ram wakeup

Dear all, thanks for the quick feedback. On Wed, 20 Sep 2017, Ming Lei wrote: > Looks your issue is very similar with Oleksandr's report: Indeed, I am using dm-crypt (full disk encryption) and CONFIG_DEFAULT_IOSCHED="cfq" Any suggestion what should be selected instead? > And Oleksandr

Re: 4.13 breaks suspend to ram wakeup

Dear all, thanks for the quick feedback. On Wed, 20 Sep 2017, Ming Lei wrote: > Looks your issue is very similar with Oleksandr's report: Indeed, I am using dm-crypt (full disk encryption) and CONFIG_DEFAULT_IOSCHED="cfq" Any suggestion what should be selected instead? > And Oleksandr

Re: [PATCH ALT4 V3 1/2] audit: show fstype:pathname for entries with anonymous parents

On Wed, Aug 23, 2017 at 7:03 AM, Richard Guy Briggs wrote: > Tracefs or debugfs were causing hundreds to thousands of null PATH > records to be associated with the init_module and finit_module SYSCALL > records on a few modules when the following rule was in place for > startup:

Re: [PATCH ALT4 V3 1/2] audit: show fstype:pathname for entries with anonymous parents

On Wed, Aug 23, 2017 at 7:03 AM, Richard Guy Briggs wrote: > Tracefs or debugfs were causing hundreds to thousands of null PATH > records to be associated with the init_module and finit_module SYSCALL > records on a few modules when the following rule was in place for > startup: > -a

Re: [PATCH v4 4/4] samples/bpf: Add documentation on cross compilation

On 09/20/17 09:11, Joel Fernandes wrote: > Acked-by: Alexei Starovoitov > Signed-off-by: Joel Fernandes > --- > samples/bpf/README.rst | 10 ++ > 1 file changed, 10 insertions(+) > > diff --git a/samples/bpf/README.rst b/samples/bpf/README.rst >

Re: [PATCH v4 4/4] samples/bpf: Add documentation on cross compilation

On 09/20/17 09:11, Joel Fernandes wrote: > Acked-by: Alexei Starovoitov > Signed-off-by: Joel Fernandes > --- > samples/bpf/README.rst | 10 ++ > 1 file changed, 10 insertions(+) > > diff --git a/samples/bpf/README.rst b/samples/bpf/README.rst > index 79f9a58f1872..2b906127ef54 100644

Re: [PATCH v3 5/5] tpm: parse TPM event logs based on EFI table

On Wed, Sep 20, 2017 at 10:13:40AM +0200, Thiebaud Weksteen wrote: > If we are not able to retrieve the TPM event logs from the ACPI table, > check the EFI configuration table (Linux-specific GUID). > > The format version of the log is now returned by the provider function. > > Signed-off-by:

Re: [PATCH v3 5/5] tpm: parse TPM event logs based on EFI table

On Wed, Sep 20, 2017 at 10:13:40AM +0200, Thiebaud Weksteen wrote: > If we are not able to retrieve the TPM event logs from the ACPI table, > check the EFI configuration table (Linux-specific GUID). > > The format version of the log is now returned by the provider function. > > Signed-off-by:

Re: [PATCH 1/2] bus: mbus: fix window size calculation for 4GB windows

On Tue, Sep 19, 2017 at 04:43:18PM +0200, Gregory CLEMENT wrote: > Hi Jan, > > On lun., août 28 2017, Jan Luebbe wrote: > > > At least the Armada XP SoC supports 4GB on a single DRAM window. Because > > the size register values contain the actual size - 1, the MSB is set

Re: [PATCH 1/2] bus: mbus: fix window size calculation for 4GB windows

On Tue, Sep 19, 2017 at 04:43:18PM +0200, Gregory CLEMENT wrote: > Hi Jan, > > On lun., août 28 2017, Jan Luebbe wrote: > > > At least the Armada XP SoC supports 4GB on a single DRAM window. Because > > the size register values contain the actual size - 1, the MSB is set in > > that case. For

Re: [RFC][PATCH v2 7/7] checkpatch: add pF/pf deprecation warning

On (09/21/17 01:29), Sergey Senozhatsky wrote: > We deprecated '%pF/%pf' printk specifiers, since '%pS/%ps' is now smart > enough to handle function pointer dereference on platforms where such > dereference is required. > > checkpatch warning example: > > WARNING: Use '%pS/%ps' instead. This

Re: [RFC][PATCH v2 7/7] checkpatch: add pF/pf deprecation warning

On (09/21/17 01:29), Sergey Senozhatsky wrote: > We deprecated '%pF/%pf' printk specifiers, since '%pS/%ps' is now smart > enough to handle function pointer dereference on platforms where such > dereference is required. > > checkpatch warning example: > > WARNING: Use '%pS/%ps' instead. This

[RFC][PATCH v2 1/7] switch dereference_function_descriptor() to `unsigned long'

Convert dereference_function_descriptor() to accept and return `unsigned long'. There will be two new ARCH function for kernel and module function pointer dereference, which will work with `unsigned long', so the patch unifies interfaces. Besides, dereference_function_descriptor() mostly work

Re: [PATCH 2/5] nvmem: mtk-efuse: use stack for nvmem_config instead of malloc'ing it

Hi, Masahiro For maintainability, I felt it's better if we use the same way to register nvmem as that most drivers does under nvmem usually using static structure. Otherwise, they should also be changed to use the one-time data in stack to avoid extra bytes to keep them. Sean On Mon,

[RFC][PATCH v2 1/7] switch dereference_function_descriptor() to `unsigned long'

Convert dereference_function_descriptor() to accept and return `unsigned long'. There will be two new ARCH function for kernel and module function pointer dereference, which will work with `unsigned long', so the patch unifies interfaces. Besides, dereference_function_descriptor() mostly work

Re: [PATCH 2/5] nvmem: mtk-efuse: use stack for nvmem_config instead of malloc'ing it

Hi, Masahiro For maintainability, I felt it's better if we use the same way to register nvmem as that most drivers does under nvmem usually using static structure. Otherwise, they should also be changed to use the one-time data in stack to avoid extra bytes to keep them. Sean On Mon,

Re: [PATCH v4] PCI: quirks: update Cavium ThunderX ACS quirk implementation

On Mon, 18 Sep 2017 01:48:01 -0700 Vadim Lomovtsev wrote: > This commit makes Cavium PCI ACS quirk applicable only to Cavium > ThunderX (CN81/83/88XX) PCIE Root Ports which has limited PCI capabilities > in terms of no ACS support advertisement. However, the

[PATCH net-next] net: dsa: use dedicated CPU port

Each port in DSA has its own dedicated CPU port currently available in its parent switch's ds->ports[port].cpu_dp. Use it instead of getting the unique tree CPU port, which will be deprecated soon. Signed-off-by: Vivien Didelot ---

Re: [PATCH v4] PCI: quirks: update Cavium ThunderX ACS quirk implementation

On Mon, 18 Sep 2017 01:48:01 -0700 Vadim Lomovtsev wrote: > This commit makes Cavium PCI ACS quirk applicable only to Cavium > ThunderX (CN81/83/88XX) PCIE Root Ports which has limited PCI capabilities > in terms of no ACS support advertisement. However, the RTL internally > implements similar

[PATCH net-next] net: dsa: use dedicated CPU port

Each port in DSA has its own dedicated CPU port currently available in its parent switch's ds->ports[port].cpu_dp. Use it instead of getting the unique tree CPU port, which will be deprecated soon. Signed-off-by: Vivien Didelot --- drivers/net/dsa/b53/b53_common.c | 4 ++--

[RFC][PATCH v2 4/7] powerpc64: Add .opd based function descriptor dereference

We are moving towards separate kernel and module function descriptor dereference callbacks. This patch enables it for powerpc64. For pointers that belong to the kernel - Added __start_opd and __end_opd pointers, to track the kernel .opd section address range; - Added

[RFC][PATCH v2 4/7] powerpc64: Add .opd based function descriptor dereference

We are moving towards separate kernel and module function descriptor dereference callbacks. This patch enables it for powerpc64. For pointers that belong to the kernel - Added __start_opd and __end_opd pointers, to track the kernel .opd section address range; - Added

Re: [PATCH 0/5] [RFC] printk/ia64/ppc64/parisc64: let's deprecate %pF/%pf printk specifiers

On (09/20/17 12:20), Helge Deller wrote: [..] > > I've not looked at the specifics case... > > > > Another option is using a struct with a single member and > > passing it by value. > > Actually, we do already have correct structs which could be referenced: > parisc: struct Elf64_Fdesc > ia64:

Re: [PATCH] ARM: uaccess: Add missing include for set_thread_flag

On Tue, Sep 19, 2017 at 2:35 PM, Jonathan Liu wrote: > > Hi Thomas, > > The top of the C source file I am compiling has: > #include > #include > > Tracing through the asm/uaccess.h include I see > asm/uaccess.h -> asm/domain.h -> asm/thread_info.h > > but set_thread_info is

Re: [PATCH 0/5] [RFC] printk/ia64/ppc64/parisc64: let's deprecate %pF/%pf printk specifiers

On (09/20/17 12:20), Helge Deller wrote: [..] > > I've not looked at the specifics case... > > > > Another option is using a struct with a single member and > > passing it by value. > > Actually, we do already have correct structs which could be referenced: > parisc: struct Elf64_Fdesc > ia64:

Re: [PATCH] ARM: uaccess: Add missing include for set_thread_flag

On Tue, Sep 19, 2017 at 2:35 PM, Jonathan Liu wrote: > > Hi Thomas, > > The top of the C source file I am compiling has: > #include > #include > > Tracing through the asm/uaccess.h include I see > asm/uaccess.h -> asm/domain.h -> asm/thread_info.h > > but set_thread_info is defined in

[RFC][PATCH v2 5/7] parisc64: Add .opd based function descriptor dereference

We are moving towards separate kernel and module function descriptor dereference callbacks. This patch enables it for parisc64. For pointers that belong to the kernel - Added __start_opd and __end_opd pointers, to track the kernel .opd section address range; - Added

[RFC][PATCH v2 3/7] ia64: Add .opd based function descriptor dereference

We are moving towards separate kernel and module function descriptor dereference callbacks. This patch enables it for IA64. For pointers that belong to the kernel - Added __start_opd and __end_opd pointers, to track the kernel .opd section address range; - Added

[RFC][PATCH v2 3/7] ia64: Add .opd based function descriptor dereference

We are moving towards separate kernel and module function descriptor dereference callbacks. This patch enables it for IA64. For pointers that belong to the kernel - Added __start_opd and __end_opd pointers, to track the kernel .opd section address range; - Added

[RFC][PATCH v2 5/7] parisc64: Add .opd based function descriptor dereference

We are moving towards separate kernel and module function descriptor dereference callbacks. This patch enables it for parisc64. For pointers that belong to the kernel - Added __start_opd and __end_opd pointers, to track the kernel .opd section address range; - Added

[RFC][PATCH v2 7/7] checkpatch: add pF/pf deprecation warning

We deprecated '%pF/%pf' printk specifiers, since '%pS/%ps' is now smart enough to handle function pointer dereference on platforms where such dereference is required. checkpatch warning example: WARNING: Use '%pS/%ps' instead. This pointer extension was deprecated: '%pF' Signed-off-by: Sergey

[RFC][PATCH v2 6/7] symbol lookup: use new kernel and module dereference functions

Call appropriate function descriptor dereference ARCH callbacks: - dereference_kernel_function_descriptor() if the pointer is a kernel symbol; - dereference_module_function_descriptor() if the pointer is a module symbol. This patch also removes dereference_function_descriptor() from

[RFC][PATCH v2 7/7] checkpatch: add pF/pf deprecation warning

We deprecated '%pF/%pf' printk specifiers, since '%pS/%ps' is now smart enough to handle function pointer dereference on platforms where such dereference is required. checkpatch warning example: WARNING: Use '%pS/%ps' instead. This pointer extension was deprecated: '%pF' Signed-off-by: Sergey

[RFC][PATCH v2 6/7] symbol lookup: use new kernel and module dereference functions

Call appropriate function descriptor dereference ARCH callbacks: - dereference_kernel_function_descriptor() if the pointer is a kernel symbol; - dereference_module_function_descriptor() if the pointer is a module symbol. This patch also removes dereference_function_descriptor() from

[RFC][PATCH v2 7/7] checkpatch: add pF/pf deprecation warning

We deprecated '%pF/%pf' printk specifiers, since '%pS/%ps' is now smart enough to handle function pointer dereference on platforms where such dereference is required. checkpatch warning example: WARNING: Use '%pS/%ps' instead. This pointer extension was deprecated: '%pF' Signed-off-by: Sergey

[RFC][PATCH v2 7/7] checkpatch: add pF/pf deprecation warning

We deprecated '%pF/%pf' printk specifiers, since '%pS/%ps' is now smart enough to handle function pointer dereference on platforms where such dereference is required. checkpatch warning example: WARNING: Use '%pS/%ps' instead. This pointer extension was deprecated: '%pF' Signed-off-by: Sergey

[RFC][PATCH v2 2/7] sections: split dereference_function_descriptor()

There are two format specifiers to print out a pointer in symbolic format: '%pS/%ps' and '%pF/%pf'. On most architectures, the two mean exactly the same thing, but some architectures (ia64, ppc64, parisc64) use an indirect pointer for C function pointers, where the function pointer points to a

[RFC][PATCH v2 2/7] sections: split dereference_function_descriptor()

There are two format specifiers to print out a pointer in symbolic format: '%pS/%ps' and '%pF/%pf'. On most architectures, the two mean exactly the same thing, but some architectures (ia64, ppc64, parisc64) use an indirect pointer for C function pointers, where the function pointer points to a

Re: [PATCH] vfio/pci: Virtualize Maximum Payload Size

On 9/20/2017 12:11 PM, Alex Williamson wrote: > My impression is that the issue would be inefficiency. There should be > nothing functionally wrong with a read request less than MPS, but we're > not "filling" the TLP as much as the topology allows. Is that your > understanding as well, Sinan?

Re: [PATCH] vfio/pci: Virtualize Maximum Payload Size

On 9/20/2017 12:11 PM, Alex Williamson wrote: > My impression is that the issue would be inefficiency. There should be > nothing functionally wrong with a read request less than MPS, but we're > not "filling" the TLP as much as the topology allows. Is that your > understanding as well, Sinan?

[RFC][PATCH v2 0/7] printk/ia64/ppc64/parisc64: let's deprecate %pF/%pf printk specifiers

Hello RFC On some arches C function pointers are indirect and point to a function descriptor, which contains the actual pointer to the code. This mostly doesn't matter, except for cases when people want to print out function pointers in symbolic format, because the usual

[RFC][PATCH v2 0/7] printk/ia64/ppc64/parisc64: let's deprecate %pF/%pf printk specifiers

Hello RFC On some arches C function pointers are indirect and point to a function descriptor, which contains the actual pointer to the code. This mostly doesn't matter, except for cases when people want to print out function pointers in symbolic format, because the usual

Re: [PATCH] ARM: unaligned.h: Use an arch-specific version

On 20 September 2017 at 08:41, Russell King - ARM Linux wrote: > On Wed, Sep 20, 2017 at 08:26:09AM -0700, Ard Biesheuvel wrote: >> Hi Romain, >> >> On 20 September 2017 at 08:18, Romain Izard >> wrote: >> > For the 32-bit ARM architecture,

Re: [PATCH] ARM: unaligned.h: Use an arch-specific version

On 20 September 2017 at 08:41, Russell King - ARM Linux wrote: > On Wed, Sep 20, 2017 at 08:26:09AM -0700, Ard Biesheuvel wrote: >> Hi Romain, >> >> On 20 September 2017 at 08:18, Romain Izard >> wrote: >> > For the 32-bit ARM architecture, unaligned access support is variable. >> > On a chip

Re: [PATCH] PM: Document rules on using pm_runtime_resume() in system suspend callbacks

On Wed, Sep 20, 2017 at 04:01:32PM +0200, Rafael J. Wysocki wrote: > On Wed, Sep 20, 2017 at 2:28 PM, Ulf Hansson wrote: > > On 20 September 2017 at 02:26, Rafael J. Wysocki wrote: > >> > >> Second, leaving devices in runtime suspend in the "suspend"

Re: [PATCH] PM: Document rules on using pm_runtime_resume() in system suspend callbacks

On Wed, Sep 20, 2017 at 04:01:32PM +0200, Rafael J. Wysocki wrote: > On Wed, Sep 20, 2017 at 2:28 PM, Ulf Hansson wrote: > > On 20 September 2017 at 02:26, Rafael J. Wysocki wrote: > >> > >> Second, leaving devices in runtime suspend in the "suspend" phase of system > >> suspend is fishy even

Re: native_smp_send_reschedule() splat from rt_mutex_lock()?

On 2017-09-18 09:51:10 [-0700], Paul E. McKenney wrote: > Hello! Hi, > [11072.586518] sched: Unexpected reschedule of offline CPU#6! > [11072.587578] [ cut here ] > [11072.588563] WARNING: CPU: 0 PID: 59 at > /home/paulmck/public_git/linux-rcu/arch/x86/kernel/smp.c:128 >

Re: native_smp_send_reschedule() splat from rt_mutex_lock()?

On 2017-09-18 09:51:10 [-0700], Paul E. McKenney wrote: > Hello! Hi, > [11072.586518] sched: Unexpected reschedule of offline CPU#6! > [11072.587578] [ cut here ] > [11072.588563] WARNING: CPU: 0 PID: 59 at > /home/paulmck/public_git/linux-rcu/arch/x86/kernel/smp.c:128 >

Re: [PATCH v5 03/10] swiotlb: Map the buffer if it was unmapped by XPFO

On 08/09/2017 01:07 PM, Tycho Andersen wrote: > --- a/lib/swiotlb.c > +++ b/lib/swiotlb.c > @@ -420,8 +420,9 @@ static void swiotlb_bounce(phys_addr_t orig_addr, > phys_addr_t tlb_addr, > { > unsigned long pfn = PFN_DOWN(orig_addr); > unsigned char *vaddr = phys_to_virt(tlb_addr); >

Re: [PATCH v5 03/10] swiotlb: Map the buffer if it was unmapped by XPFO

On 08/09/2017 01:07 PM, Tycho Andersen wrote: > --- a/lib/swiotlb.c > +++ b/lib/swiotlb.c > @@ -420,8 +420,9 @@ static void swiotlb_bounce(phys_addr_t orig_addr, > phys_addr_t tlb_addr, > { > unsigned long pfn = PFN_DOWN(orig_addr); > unsigned char *vaddr = phys_to_virt(tlb_addr); >

Re: [PATCH 3/5] nvmem: mtk-efuse: fix different address space warnings of sparse

On Mon, 2017-09-11 at 22:01 +0900, Masahiro Yamada wrote: > Fix the following sparse warnings: > > drivers/nvmem/mtk-efuse.c:24:30: warning: incorrect type in initializer > (different address spaces) > drivers/nvmem/mtk-efuse.c:24:30:expected void [noderef] *base >

Re: [PATCH 3/5] nvmem: mtk-efuse: fix different address space warnings of sparse

On Mon, 2017-09-11 at 22:01 +0900, Masahiro Yamada wrote: > Fix the following sparse warnings: > > drivers/nvmem/mtk-efuse.c:24:30: warning: incorrect type in initializer > (different address spaces) > drivers/nvmem/mtk-efuse.c:24:30:expected void [noderef] *base >

Re: [Part1 PATCH v4 15/17] percpu: introduce DEFINE_PER_CPU_UNENCRYPTED

On 09/20/2017 02:34 AM, Borislav Petkov wrote: On Tue, Sep 19, 2017 at 08:50:20AM -0500, Brijesh Singh wrote: "..shared_aligned" section does not start and end with page-size alignment. Nowhere in the code there's a comment saying: "This percpu section really must be page-size aligned

Re: [Part1 PATCH v4 15/17] percpu: introduce DEFINE_PER_CPU_UNENCRYPTED

On 09/20/2017 02:34 AM, Borislav Petkov wrote: On Tue, Sep 19, 2017 at 08:50:20AM -0500, Brijesh Singh wrote: "..shared_aligned" section does not start and end with page-size alignment. Nowhere in the code there's a comment saying: "This percpu section really must be page-size aligned

Re: [PATCH] PM: Document rules on using pm_runtime_resume() in system suspend callbacks

On Wed, 20 Sep 2017, Rafael J. Wysocki wrote: > >> Second, leaving devices in runtime suspend in the "suspend" phase of system > >> suspend is fishy even when their runtime PM is disabled, because that > >> doesn't > >> guarantee anything regarding their children or possible consumers. Runtime

Re: [PATCH] PM: Document rules on using pm_runtime_resume() in system suspend callbacks

On Wed, 20 Sep 2017, Rafael J. Wysocki wrote: > >> Second, leaving devices in runtime suspend in the "suspend" phase of system > >> suspend is fishy even when their runtime PM is disabled, because that > >> doesn't > >> guarantee anything regarding their children or possible consumers. Runtime

Re: [PATCH] pci: Add dummy for pci_acs_enabled() if CONFIG_PCI=n to fix iommmu build

On Mon, 11 Sep 2017 14:29:15 +0200 Geert Uytterhoeven wrote: > If CONFIG_PCI=n, and gcc (e.g. 4.1.2) decides not to inline > get_pci_function_alias_group(), the build fails with: > > drivers/iommu/iommu.o: In function `get_pci_function_alias_group': >

Re: [PATCH] pci: Add dummy for pci_acs_enabled() if CONFIG_PCI=n to fix iommmu build

On Mon, 11 Sep 2017 14:29:15 +0200 Geert Uytterhoeven wrote: > If CONFIG_PCI=n, and gcc (e.g. 4.1.2) decides not to inline > get_pci_function_alias_group(), the build fails with: > > drivers/iommu/iommu.o: In function `get_pci_function_alias_group': > iommu.c:(.text+0xfdc): undefined

Re: introduce get_nth_filter()

On 09/20, Oleg Nesterov wrote: > > On 09/20, Tycho Andersen wrote: > > > > Thanks for cleaning this up, I'll be happy to test whatever final > > patch we come up with. > > Well, I just noticed you sent another "[PATCH] ptrace, seccomp: add support > for retrieving seccomp flags" today... > > So if

Re: introduce get_nth_filter()

On 09/20, Oleg Nesterov wrote: > > On 09/20, Tycho Andersen wrote: > > > > Thanks for cleaning this up, I'll be happy to test whatever final > > patch we come up with. > > Well, I just noticed you sent another "[PATCH] ptrace, seccomp: add support > for retrieving seccomp flags" today... > > So if

<    5   6   7   8   9   10   11   12   13   14   >