[PATCH RT 0/7] Linux 3.10.105-rt120-rc1

Dear RT Folks, This is the RT stable review cycle of patch 3.10.105-rt120-rc1. Please scream at me if I messed something up. Please test the patches too. The -rc release will be uploaded to kernel.org and will be deleted when the final release is out. This is just a review release (or release

[PATCH RT 0/7] Linux 3.10.105-rt120-rc1

Dear RT Folks, This is the RT stable review cycle of patch 3.10.105-rt120-rc1. Please scream at me if I messed something up. Please test the patches too. The -rc release will be uploaded to kernel.org and will be deleted when the final release is out. This is just a review release (or release

[PATCH RT 7/7] Linux 3.10.105-rt120-rc1

3.10.105-rt120-rc1 stable review patch. If anyone has any objections, please let me know. -- From: "Steven Rostedt (VMware)" --- localversion-rt | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/localversion-rt b/localversion-rt index

[PATCH RT 7/7] Linux 3.10.105-rt120-rc1

3.10.105-rt120-rc1 stable review patch. If anyone has any objections, please let me know. -- From: "Steven Rostedt (VMware)" --- localversion-rt | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/localversion-rt b/localversion-rt index

[PATCH RT 4/8] rt: Drop mutex_disable() on !DEBUG configs and the GPL suffix from export symbol

3.18.48-rt54-rc1 stable review patch. If anyone has any objections, please let me know. -- From: Sebastian Andrzej Siewior Alex Goins reported that mutex_destroy() on RT will force a GPL only symbol which won't link and therefore fail on a non-GPL kernel

[PATCH RT 4/8] rt: Drop mutex_disable() on !DEBUG configs and the GPL suffix from export symbol

3.18.48-rt54-rc1 stable review patch. If anyone has any objections, please let me know. -- From: Sebastian Andrzej Siewior Alex Goins reported that mutex_destroy() on RT will force a GPL only symbol which won't link and therefore fail on a non-GPL kernel module. This does not

[PATCH RT 5/8] lockdep: Handle statically initialized PER_CPU locks proper

3.18.48-rt54-rc1 stable review patch. If anyone has any objections, please let me know. -- From: Thomas Gleixner If a PER_CPU struct which contains a spin_lock is statically initialized via: DEFINE_PER_CPU(struct foo, bla) = { .lock =

[PATCH RT 5/8] lockdep: Handle statically initialized PER_CPU locks proper

3.18.48-rt54-rc1 stable review patch. If anyone has any objections, please let me know. -- From: Thomas Gleixner If a PER_CPU struct which contains a spin_lock is statically initialized via: DEFINE_PER_CPU(struct foo, bla) = { .lock = __SPIN_LOCK_UNLOCKED(bla.lock) };

[PATCH RT 3/7] rt: Drop mutex_disable() on !DEBUG configs and the GPL suffix from export symbol

3.12.70-rt95-rc1 stable review patch. If anyone has any objections, please let me know. -- From: Sebastian Andrzej Siewior Alex Goins reported that mutex_destroy() on RT will force a GPL only symbol which won't link and therefore fail on a non-GPL kernel

[PATCH RT 3/7] rt: Drop mutex_disable() on !DEBUG configs and the GPL suffix from export symbol

3.12.70-rt95-rc1 stable review patch. If anyone has any objections, please let me know. -- From: Sebastian Andrzej Siewior Alex Goins reported that mutex_destroy() on RT will force a GPL only symbol which won't link and therefore fail on a non-GPL kernel module. This does not

[PATCH RT 0/8] Linux 3.18.48-rt54-rc1

Dear RT Folks, This is the RT stable review cycle of patch 3.18.48-rt54-rc1. Please scream at me if I messed something up. Please test the patches too. The -rc release will be uploaded to kernel.org and will be deleted when the final release is out. This is just a review release (or release

[PATCH RT 0/8] Linux 3.18.48-rt54-rc1

Dear RT Folks, This is the RT stable review cycle of patch 3.18.48-rt54-rc1. Please scream at me if I messed something up. Please test the patches too. The -rc release will be uploaded to kernel.org and will be deleted when the final release is out. This is just a review release (or release

[PATCH RT 5/7] rt: Drop the removal of _GPL from rt_mutex_destroy()s EXPORT_SYMBOL

3.12.70-rt95-rc1 stable review patch. If anyone has any objections, please let me know. -- From: Sebastian Andrzej Siewior What we have now should be enough, the EXPORT_SYMBOL statement for rt_mutex_destroy() is not required. Signed-off-by: Sebastian

[PATCH RT 1/7] radix-tree: use local locks

3.12.70-rt95-rc1 stable review patch. If anyone has any objections, please let me know. -- From: Sebastian Andrzej Siewior The preload functionality uses per-CPU variables and preempt-disable to ensure that it does not switch CPUs during its usage. This

[PATCH RT 6/7] lockdep: Fix compilation error for !CONFIG_MODULES and !CONFIG_SMP

3.12.70-rt95-rc1 stable review patch. If anyone has any objections, please let me know. -- From: Dan Murphy When CONFIG_MODULES is not set then it fails to compile in lockdep: |kernel/locking/lockdep.c: In function 'look_up_lock_class':

[PATCH RT 5/7] rt: Drop the removal of _GPL from rt_mutex_destroy()s EXPORT_SYMBOL

3.12.70-rt95-rc1 stable review patch. If anyone has any objections, please let me know. -- From: Sebastian Andrzej Siewior What we have now should be enough, the EXPORT_SYMBOL statement for rt_mutex_destroy() is not required. Signed-off-by: Sebastian Andrzej Siewior

[PATCH RT 1/7] radix-tree: use local locks

3.12.70-rt95-rc1 stable review patch. If anyone has any objections, please let me know. -- From: Sebastian Andrzej Siewior The preload functionality uses per-CPU variables and preempt-disable to ensure that it does not switch CPUs during its usage. This patch adds local_locks()

[PATCH RT 6/7] lockdep: Fix compilation error for !CONFIG_MODULES and !CONFIG_SMP

3.12.70-rt95-rc1 stable review patch. If anyone has any objections, please let me know. -- From: Dan Murphy When CONFIG_MODULES is not set then it fails to compile in lockdep: |kernel/locking/lockdep.c: In function 'look_up_lock_class': |kernel/locking/lockdep.c:684:12: error:

Re: [RFC][PATCH 0/4] tracing: Allow function tracing to start earlier in boot up

On Wed, 08 Mar 2017 11:32:25 -0800 Todd Brandt wrote: > On Wed, 2017-03-08 at 11:15 -0800, Todd Brandt wrote: > > On Tue, 2017-03-07 at 16:28 -0500, Steven Rostedt wrote: > > > I've had people ask about moving tracing up further in the boot process. > > > This

[PATCH RT 5/7] rt: Drop the removal of _GPL from rt_mutex_destroy()s EXPORT_SYMBOL

3.10.105-rt120-rc1 stable review patch. If anyone has any objections, please let me know. -- From: Sebastian Andrzej Siewior What we have now should be enough, the EXPORT_SYMBOL statement for rt_mutex_destroy() is not required. Signed-off-by: Sebastian

Re: [RFC][PATCH 0/4] tracing: Allow function tracing to start earlier in boot up

On Wed, 08 Mar 2017 11:32:25 -0800 Todd Brandt wrote: > On Wed, 2017-03-08 at 11:15 -0800, Todd Brandt wrote: > > On Tue, 2017-03-07 at 16:28 -0500, Steven Rostedt wrote: > > > I've had people ask about moving tracing up further in the boot process. > > > This patch series looks at function

[PATCH RT 5/7] rt: Drop the removal of _GPL from rt_mutex_destroy()s EXPORT_SYMBOL

3.10.105-rt120-rc1 stable review patch. If anyone has any objections, please let me know. -- From: Sebastian Andrzej Siewior What we have now should be enough, the EXPORT_SYMBOL statement for rt_mutex_destroy() is not required. Signed-off-by: Sebastian Andrzej Siewior

[PATCH RT 0/7] Linux 3.12.70-rt95-rc1

Dear RT Folks, This is the RT stable review cycle of patch 3.12.70-rt95-rc1. Please scream at me if I messed something up. Please test the patches too. The -rc release will be uploaded to kernel.org and will be deleted when the final release is out. This is just a review release (or release

[PATCH RT 0/7] Linux 3.12.70-rt95-rc1

Dear RT Folks, This is the RT stable review cycle of patch 3.12.70-rt95-rc1. Please scream at me if I messed something up. Please test the patches too. The -rc release will be uploaded to kernel.org and will be deleted when the final release is out. This is just a review release (or release

[PATCH RT 7/8] lockdep: Fix compilation error for !CONFIG_MODULES and !CONFIG_SMP

3.18.48-rt54-rc1 stable review patch. If anyone has any objections, please let me know. -- From: Dan Murphy When CONFIG_MODULES is not set then it fails to compile in lockdep: |kernel/locking/lockdep.c: In function 'look_up_lock_class':

[PATCH RT 7/8] lockdep: Fix compilation error for !CONFIG_MODULES and !CONFIG_SMP

3.18.48-rt54-rc1 stable review patch. If anyone has any objections, please let me know. -- From: Dan Murphy When CONFIG_MODULES is not set then it fails to compile in lockdep: |kernel/locking/lockdep.c: In function 'look_up_lock_class': |kernel/locking/lockdep.c:684:12: error:

[PATCH RT 7/7] Linux 3.12.70-rt95-rc1

3.12.70-rt95-rc1 stable review patch. If anyone has any objections, please let me know. -- From: "Steven Rostedt (VMware)" --- localversion-rt | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/localversion-rt b/localversion-rt index

[PATCH RT 7/7] Linux 3.12.70-rt95-rc1

3.12.70-rt95-rc1 stable review patch. If anyone has any objections, please let me know. -- From: "Steven Rostedt (VMware)" --- localversion-rt | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/localversion-rt b/localversion-rt index 8d02a9bac500..fe529ae51f64

[PATCH RT 8/8] Linux 3.18.48-rt54-rc1

3.18.48-rt54-rc1 stable review patch. If anyone has any objections, please let me know. -- From: "Steven Rostedt (VMware)" --- localversion-rt | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/localversion-rt b/localversion-rt index

[PATCH RT 1/8] radix-tree: use local locks

3.18.48-rt54-rc1 stable review patch. If anyone has any objections, please let me know. -- From: Sebastian Andrzej Siewior The preload functionality uses per-CPU variables and preempt-disable to ensure that it does not switch CPUs during its usage. This

[PATCH RT 8/8] Linux 3.18.48-rt54-rc1

3.18.48-rt54-rc1 stable review patch. If anyone has any objections, please let me know. -- From: "Steven Rostedt (VMware)" --- localversion-rt | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/localversion-rt b/localversion-rt index e6c0dc6a54cd..cc1bfc08848a

[PATCH RT 1/8] radix-tree: use local locks

3.18.48-rt54-rc1 stable review patch. If anyone has any objections, please let me know. -- From: Sebastian Andrzej Siewior The preload functionality uses per-CPU variables and preempt-disable to ensure that it does not switch CPUs during its usage. This patch adds local_locks()

Re: [RFC][PATCH 4/4] ftrace: Allow for function tracing to record init functions on boot up

Dear mm folks, Are you OK with this change? I need a hook to when the init sections are being freed along with the address that are being freed. As each arch frees their own init sections I need a single location to place my hook. The archs all call free_reserved_area(). As this isn't a critical

Re: [RFC][PATCH 4/4] ftrace: Allow for function tracing to record init functions on boot up

Dear mm folks, Are you OK with this change? I need a hook to when the init sections are being freed along with the address that are being freed. As each arch frees their own init sections I need a single location to place my hook. The archs all call free_reserved_area(). As this isn't a critical

[PATCH RT 2/8] pinctrl: qcom: Use raw spinlock variants

3.18.48-rt54-rc1 stable review patch. If anyone has any objections, please let me know. -- From: Julia Cartwright The MSM pinctrl driver currently implements an irq_chip for handling GPIO interrupts; due to how irq_chip handling is done, it's necessary for the

[PATCH RT 6/8] rt: Drop the removal of _GPL from rt_mutex_destroy()s EXPORT_SYMBOL

3.18.48-rt54-rc1 stable review patch. If anyone has any objections, please let me know. -- From: Sebastian Andrzej Siewior What we have now should be enough, the EXPORT_SYMBOL statement for rt_mutex_destroy() is not required. Signed-off-by: Sebastian

[PATCH RT 6/8] rt: Drop the removal of _GPL from rt_mutex_destroy()s EXPORT_SYMBOL

3.18.48-rt54-rc1 stable review patch. If anyone has any objections, please let me know. -- From: Sebastian Andrzej Siewior What we have now should be enough, the EXPORT_SYMBOL statement for rt_mutex_destroy() is not required. Signed-off-by: Sebastian Andrzej Siewior

[PATCH RT 2/8] pinctrl: qcom: Use raw spinlock variants

3.18.48-rt54-rc1 stable review patch. If anyone has any objections, please let me know. -- From: Julia Cartwright The MSM pinctrl driver currently implements an irq_chip for handling GPIO interrupts; due to how irq_chip handling is done, it's necessary for the irq_chip methods

[PATCH RT 3/8] x86/mm/cpa: avoid wbinvd() for PREEMPT

3.18.48-rt54-rc1 stable review patch. If anyone has any objections, please let me know. -- From: John Ogness Although wbinvd() is faster than flushing many individual pages, it blocks the memory bus for "long" periods of time (>100us), thus directly

[PATCH RT 3/8] x86/mm/cpa: avoid wbinvd() for PREEMPT

3.18.48-rt54-rc1 stable review patch. If anyone has any objections, please let me know. -- From: John Ogness Although wbinvd() is faster than flushing many individual pages, it blocks the memory bus for "long" periods of time (>100us), thus directly causing unusually large

[PATCH RT 4/7] lockdep: Handle statically initialized PER_CPU locks proper

3.12.70-rt95-rc1 stable review patch. If anyone has any objections, please let me know. -- From: Thomas Gleixner If a PER_CPU struct which contains a spin_lock is statically initialized via: DEFINE_PER_CPU(struct foo, bla) = { .lock =

[PATCH RT 4/7] lockdep: Handle statically initialized PER_CPU locks proper

3.12.70-rt95-rc1 stable review patch. If anyone has any objections, please let me know. -- From: Thomas Gleixner If a PER_CPU struct which contains a spin_lock is statically initialized via: DEFINE_PER_CPU(struct foo, bla) = { .lock = __SPIN_LOCK_UNLOCKED(bla.lock) };

[PATCH RT 2/7] x86/mm/cpa: avoid wbinvd() for PREEMPT

3.10.105-rt120-rc1 stable review patch. If anyone has any objections, please let me know. -- From: John Ogness Although wbinvd() is faster than flushing many individual pages, it blocks the memory bus for "long" periods of time (>100us), thus directly

[PATCH RT 3/7] rt: Drop mutex_disable() on !DEBUG configs and the GPL suffix from export symbol

3.10.105-rt120-rc1 stable review patch. If anyone has any objections, please let me know. -- From: Sebastian Andrzej Siewior Alex Goins reported that mutex_destroy() on RT will force a GPL only symbol which won't link and therefore fail on a non-GPL

[PATCH RT 2/7] x86/mm/cpa: avoid wbinvd() for PREEMPT

3.10.105-rt120-rc1 stable review patch. If anyone has any objections, please let me know. -- From: John Ogness Although wbinvd() is faster than flushing many individual pages, it blocks the memory bus for "long" periods of time (>100us), thus directly causing unusually large

[PATCH RT 3/7] rt: Drop mutex_disable() on !DEBUG configs and the GPL suffix from export symbol

3.10.105-rt120-rc1 stable review patch. If anyone has any objections, please let me know. -- From: Sebastian Andrzej Siewior Alex Goins reported that mutex_destroy() on RT will force a GPL only symbol which won't link and therefore fail on a non-GPL kernel module. This does not

[PATCH v6] NTB: Add IDT 89HPESxNTx PCIe-switches support

IDT 89HPESxNTx device series is PCIe-switches, which support Non-Transparent bridging between domains connected to the device ports. Since new NTB API exposes multi-port interface and messaging API, the IDT NT-functions can be now supported in the kernel. This driver adds the following

[PATCH v6] NTB: Add IDT 89HPESxNTx PCIe-switches support

IDT 89HPESxNTx device series is PCIe-switches, which support Non-Transparent bridging between domains connected to the device ports. Since new NTB API exposes multi-port interface and messaging API, the IDT NT-functions can be now supported in the kernel. This driver adds the following

Re: [tpmdd-devel] [PATCH] vTPM: Fix missing NULL check

On Wed, 2017-03-08 at 10:17 -0700, Jason Gunthorpe wrote: > On Tue, Mar 07, 2017 at 11:12:43PM -0500, Hon Ching(Vicky) Lo wrote: > > On Mon, 2017-03-06 at 16:19 -0700, Jason Gunthorpe wrote: > > > > Also, how does locking work here? Does the vio core prevent > > > tpm_ibmvtpm_get_desired_dma and

Re: [tpmdd-devel] [PATCH] vTPM: Fix missing NULL check

On Wed, 2017-03-08 at 10:17 -0700, Jason Gunthorpe wrote: > On Tue, Mar 07, 2017 at 11:12:43PM -0500, Hon Ching(Vicky) Lo wrote: > > On Mon, 2017-03-06 at 16:19 -0700, Jason Gunthorpe wrote: > > > > Also, how does locking work here? Does the vio core prevent > > > tpm_ibmvtpm_get_desired_dma and

[PATCH v2 1/2] regulator: core: add regulator_has_continuous_voltage_range()

The new function allows consumers to determine if a regulator is continuous or discrete, and whether the results of regulator_count_voltages() and regulator_list_voltage() correspond to the regulator itself or its supply. Change-Id: I1198cee9fff60dc747a02860e9652034f4d5da33 Signed-off-by:

[PATCH v2 1/2] regulator: core: add regulator_has_continuous_voltage_range()

The new function allows consumers to determine if a regulator is continuous or discrete, and whether the results of regulator_count_voltages() and regulator_list_voltage() correspond to the regulator itself or its supply. Change-Id: I1198cee9fff60dc747a02860e9652034f4d5da33 Signed-off-by:

Re: [PATCH v15 3/5] tee: add OP-TEE driver

[cut] > +static struct optee *optee_probe(struct device_node *np) > +{ > + optee_invoke_fn *invoke_fn; > + struct tee_shm_pool *pool; > + struct optee *optee = NULL; > + void *memremaped_shm = NULL; > + struct tee_device *teedev; > + u32 sec_caps; > + int

Re: [PATCH v15 3/5] tee: add OP-TEE driver

[cut] > +static struct optee *optee_probe(struct device_node *np) > +{ > + optee_invoke_fn *invoke_fn; > + struct tee_shm_pool *pool; > + struct optee *optee = NULL; > + void *memremaped_shm = NULL; > + struct tee_device *teedev; > + u32 sec_caps; > + int

[PATCH v2 2/2] regulator: Add driver for voltage controlled regulators

The output voltage of a voltage controlled regulator can be controlled through the voltage of another regulator. A vctrl regulator can be continuous or discrete, depending on its control regulator. The current version of this driver assumes that the output voltage is a linear function of the

[PATCH v2 2/2] regulator: Add driver for voltage controlled regulators

The output voltage of a voltage controlled regulator can be controlled through the voltage of another regulator. A vctrl regulator can be continuous or discrete, depending on its control regulator. The current version of this driver assumes that the output voltage is a linear function of the

Re: [Xen-devel] [PATCH 6/7] xen/9pfs: receive responses

On Tue, Mar 07, 2017 at 05:13:59PM -0800, Stefano Stabellini wrote: > On Tue, 7 Mar 2017, Stefano Stabellini wrote: > > > > + > > > > + ring = container_of(work, struct xen_9pfs_dataring, work); > > > > + priv = ring->priv; > > > > + > > > > + while (1) { > > > > +

Re: [GIT pull] CPU hotplug updates for 4.9

On Wed, 2017-03-08 at 09:25 +0100, Thomas Gleixner wrote: > Before you proceed with bisecting, could you try Linus head first, > especially commit: > > fa3aa7a54fe6 ("jiffies: Revert bogus conversion of NSEC_PER_SEC to TICK_NSEC") > > which fixes: 93825f2ec736 ("jiffies: Reuse TICK_NSEC instead

Re: [Xen-devel] [PATCH 6/7] xen/9pfs: receive responses

On Tue, Mar 07, 2017 at 05:13:59PM -0800, Stefano Stabellini wrote: > On Tue, 7 Mar 2017, Stefano Stabellini wrote: > > > > + > > > > + ring = container_of(work, struct xen_9pfs_dataring, work); > > > > + priv = ring->priv; > > > > + > > > > + while (1) { > > > > +

Re: [GIT pull] CPU hotplug updates for 4.9

On Wed, 2017-03-08 at 09:25 +0100, Thomas Gleixner wrote: > Before you proceed with bisecting, could you try Linus head first, > especially commit: > > fa3aa7a54fe6 ("jiffies: Revert bogus conversion of NSEC_PER_SEC to TICK_NSEC") > > which fixes: 93825f2ec736 ("jiffies: Reuse TICK_NSEC instead

[ANNOUNCE] 3.10.105-rt119

Dear RT Folks, I'm pleased to announce the 3.10.105-rt119 stable release. [ I had this tested when I was at ELC but never posted it ] This release is just an update to the new stable 3.10.105 version and no RT specific changes have been made. You can get this release via the git tree at:

[ANNOUNCE] 3.10.105-rt119

Dear RT Folks, I'm pleased to announce the 3.10.105-rt119 stable release. [ I had this tested when I was at ELC but never posted it ] This release is just an update to the new stable 3.10.105 version and no RT specific changes have been made. You can get this release via the git tree at:

[ANNOUNCE] 3.18.48-rt53

Dear RT Folks, I'm pleased to announce the 3.18.48-rt53 stable release. [ I had this tested when I was at ELC, but never posted it ] This release is just an update to the new stable 3.18.48 version and no RT specific changes have been made. You can get this release via the git tree at:

[ANNOUNCE] 3.18.48-rt53

Dear RT Folks, I'm pleased to announce the 3.18.48-rt53 stable release. [ I had this tested when I was at ELC, but never posted it ] This release is just an update to the new stable 3.18.48 version and no RT specific changes have been made. You can get this release via the git tree at:

[PATCH v2] ARM: zynq: Add #io-channel-cells to (x)adc node for iio-hwmon

Fix OF: /iio_hwmon: could not get #io-channel-cells for /amba/adc@f8007100 OF: /iio_hwmon: could not get #io-channel-cells for /amba/adc@f8007100 OF: /iio_hwmon: could not get #io-channel-cells for /amba/adc@f8007100 by adding the #io-channel-cells property. Signed-off-by: Moritz Fischer

[PATCH v2] ARM: zynq: Add #io-channel-cells to (x)adc node for iio-hwmon

Fix OF: /iio_hwmon: could not get #io-channel-cells for /amba/adc@f8007100 OF: /iio_hwmon: could not get #io-channel-cells for /amba/adc@f8007100 OF: /iio_hwmon: could not get #io-channel-cells for /amba/adc@f8007100 by adding the #io-channel-cells property. Signed-off-by: Moritz Fischer Cc:

Re: [PATCH] ARM: zynq: Add #io-channel-cells to (x)adc node for iio-hwmon

On Wed, Mar 8, 2017 at 12:08 PM, Moritz Fischer wrote: > Fix issue when exposing xadc via iio-hwmon by adding missing > That was messed up ... let me resend that. Sorry for the noise ... Thanks, Moritz

Re: [PATCH] ARM: zynq: Add #io-channel-cells to (x)adc node for iio-hwmon

On Wed, Mar 8, 2017 at 12:08 PM, Moritz Fischer wrote: > Fix issue when exposing xadc via iio-hwmon by adding missing > That was messed up ... let me resend that. Sorry for the noise ... Thanks, Moritz

Re: [Question] devm_kmalloc() for DMA ?

On Wed, Mar 08, 2017 at 08:48:31PM +0100, Lars-Peter Clausen wrote: > When the DMA memory is mapped for reading from the device the associated > cachelines are invalidated without writeback. There is no guarantee that > the changes made to the devres_node have made it to main memory yet, or > is

Re: [Question] devm_kmalloc() for DMA ?

On Wed, Mar 08, 2017 at 08:48:31PM +0100, Lars-Peter Clausen wrote: > When the DMA memory is mapped for reading from the device the associated > cachelines are invalidated without writeback. There is no guarantee that > the changes made to the devres_node have made it to main memory yet, or > is

[PATCH 1/2 v3] video: fbdev: imxfb: support AUS mode

Some displays require setting AUS mode in the LDCD AUS Mode Control Register to work with the imxfb driver. Like the value of the Panel Configuration Register, the AUS mode setting depends on the display mode. Allow setting AUS mode from the device tree by adding a boolean property. Make this

[PATCH 1/2 v3] video: fbdev: imxfb: support AUS mode

Some displays require setting AUS mode in the LDCD AUS Mode Control Register to work with the imxfb driver. Like the value of the Panel Configuration Register, the AUS mode setting depends on the display mode. Allow setting AUS mode from the device tree by adding a boolean property. Make this

Re: [PATCH 1/2] x86/efi: Correct a tiny mistake in code comment

On Wed, Mar 8, 2017 at 3:05 PM, Borislav Petkov wrote: > On Wed, Mar 08, 2017 at 05:09:55PM +0800, Baoquan He wrote: >> Yes, it looks better. I can repost with this change. Thanks. > > No it doesn't: > > #define EFI_VA_START ( -4 * (_AC(1, UL) << 30)) > #define EFI_VA_END

Re: [PATCH 1/2] x86/efi: Correct a tiny mistake in code comment

On Wed, Mar 8, 2017 at 3:05 PM, Borislav Petkov wrote: > On Wed, Mar 08, 2017 at 05:09:55PM +0800, Baoquan He wrote: >> Yes, it looks better. I can repost with this change. Thanks. > > No it doesn't: > > #define EFI_VA_START ( -4 * (_AC(1, UL) << 30)) > #define EFI_VA_END (-68 * (_AC(1,

Re: [PATCH 5/7] xen/9pfs: send requests to the backend

On 03/08/2017 02:33 PM, Stefano Stabellini wrote: > On Wed, 8 Mar 2017, Boris Ostrovsky wrote: > +} > + > +static int p9_xen_write_todo(struct xen_9pfs_dataring *ring, RING_IDX > size) > +{ > + RING_IDX cons, prod; > + > + cons = ring->intf->out_cons; > + prod

Re: [PATCH 5/7] xen/9pfs: send requests to the backend

On 03/08/2017 02:33 PM, Stefano Stabellini wrote: > On Wed, 8 Mar 2017, Boris Ostrovsky wrote: > +} > + > +static int p9_xen_write_todo(struct xen_9pfs_dataring *ring, RING_IDX > size) > +{ > + RING_IDX cons, prod; > + > + cons = ring->intf->out_cons; > + prod

[PATCH] doc: ABI: vdso: update parse_vdso.c reference

Since commit f9b6b0ef603 ("selftests: move vDSO tests from Documentation/vDSO") parse_vdso.c moved under selftests. Update the reference to match. Cc: Jonathan Corbet Signed-off-by: Baruch Siach --- Documentation/ABI/stable/vdso | 3 ++- 1 file changed, 2

[PATCH] doc: ABI: vdso: update parse_vdso.c reference

Since commit f9b6b0ef603 ("selftests: move vDSO tests from Documentation/vDSO") parse_vdso.c moved under selftests. Update the reference to match. Cc: Jonathan Corbet Signed-off-by: Baruch Siach --- Documentation/ABI/stable/vdso | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff

Re: [RFC][PATCH 0/4] tracing: Allow function tracing to start earlier in boot up

On Tue, 2017-03-07 at 16:28 -0500, Steven Rostedt wrote: > I've had people ask about moving tracing up further in the boot process. > This patch series looks at function tracing only. It allows for tracing > (and function filtering) to be moved right after memory is initialized. > To have it

Re: [RFC][PATCH 0/4] tracing: Allow function tracing to start earlier in boot up

On Tue, 2017-03-07 at 16:28 -0500, Steven Rostedt wrote: > I've had people ask about moving tracing up further in the boot process. > This patch series looks at function tracing only. It allows for tracing > (and function filtering) to be moved right after memory is initialized. > To have it

Re: [PATCH v3 0/8] try to reduce fragmenting fallbacks

On 8.3.2017 17:46, Johannes Weiner wrote: > Is there any other data you would like me to gather? If you can enable the extfrag tracepoint, it would be nice to have graphs of how unmovable allocations falling back to movable pageblocks, etc. Possibly also /proc/pagetypeinfo for numbers of

Re: [PATCH v3 0/8] try to reduce fragmenting fallbacks

On 8.3.2017 17:46, Johannes Weiner wrote: > Is there any other data you would like me to gather? If you can enable the extfrag tracepoint, it would be nice to have graphs of how unmovable allocations falling back to movable pageblocks, etc. Possibly also /proc/pagetypeinfo for numbers of

[PATCH] usb: host: xhci-plat: Fix timeout on removal of hot pluggable xhci controllers

Upstream commit 98d74f9ceaef ("xhci: fix 10 second timeout on removal of PCI hotpluggable xhci controllers") fixes a problem with hot pluggable PCI xhci controllers which can result in excessive timeouts, to the point where the system reports a deadlock. The same problem is seen with hot

[PATCH] usb: host: xhci-plat: Fix timeout on removal of hot pluggable xhci controllers

Upstream commit 98d74f9ceaef ("xhci: fix 10 second timeout on removal of PCI hotpluggable xhci controllers") fixes a problem with hot pluggable PCI xhci controllers which can result in excessive timeouts, to the point where the system reports a deadlock. The same problem is seen with hot

Re: [PATCH 5/7] xen/9pfs: send requests to the backend

On Wed, 8 Mar 2017, Boris Ostrovsky wrote: > >>> +} > >>> + > >>> +static int p9_xen_write_todo(struct xen_9pfs_dataring *ring, RING_IDX > >>> size) > >>> +{ > >>> + RING_IDX cons, prod; > >>> + > >>> + cons = ring->intf->out_cons; > >>> + prod = ring->intf->out_prod; > >>> + mb(); > >>> + > >>>

Re: [PATCH 5/7] xen/9pfs: send requests to the backend

On Wed, 8 Mar 2017, Boris Ostrovsky wrote: > >>> +} > >>> + > >>> +static int p9_xen_write_todo(struct xen_9pfs_dataring *ring, RING_IDX > >>> size) > >>> +{ > >>> + RING_IDX cons, prod; > >>> + > >>> + cons = ring->intf->out_cons; > >>> + prod = ring->intf->out_prod; > >>> + mb(); > >>> + > >>>

NULL pointer dereference in cgroup

Hi, I've seen this only once, and can't reproduce it. But here it is anyway: https://postimg.org/image/pn94k1yov (Not sure png files are accepted on LKML.) This occurred in a VM while booting 4.11.0-rc1 Cheers, -- Luís

NULL pointer dereference in cgroup

Hi, I've seen this only once, and can't reproduce it. But here it is anyway: https://postimg.org/image/pn94k1yov (Not sure png files are accepted on LKML.) This occurred in a VM while booting 4.11.0-rc1 Cheers, -- Luís

Re: [PATCH] mm,hugetlb: compute page_size_log properly

> One example of the problems with extra layers what this patch fixes: > mmap_pgoff() should never be using SHM_HUGE_* logic. This was > introduced by: > >091d0d55b28 (shm: fix null pointer deref when userspace specifies invalid > hugepage size) > > It is obviously harmless but lets just

Re: [PATCH] mm,hugetlb: compute page_size_log properly

> One example of the problems with extra layers what this patch fixes: > mmap_pgoff() should never be using SHM_HUGE_* logic. This was > introduced by: > >091d0d55b28 (shm: fix null pointer deref when userspace specifies invalid > hugepage size) > > It is obviously harmless but lets just

Re: [PATCH] hwmon: (dell-smm) Add Dell XPS 15 9560 into DMI list

Wow, that was easy :-). so I did: download the driver source and makefile make => several new files show up including a .ko - WOHOOO sudo rmmod dell-smm-hwmon lsmod | grep hwmo => nothing sudo insmod ./dell-smm-hwmon.ko => nothing lsmod | grep hwmo => dell_smm_hwmon 16384 0 sudo sensors

Re: [PATCH] hwmon: (dell-smm) Add Dell XPS 15 9560 into DMI list

Wow, that was easy :-). so I did: download the driver source and makefile make => several new files show up including a .ko - WOHOOO sudo rmmod dell-smm-hwmon lsmod | grep hwmo => nothing sudo insmod ./dell-smm-hwmon.ko => nothing lsmod | grep hwmo => dell_smm_hwmon 16384 0 sudo sensors

Re: [net/bpf] 3051bf36c2 BUG: unable to handle kernel paging request at 0000a7cf

Adding x86 people too, since this seems to be something off about ARCH_HAS_SET_MEMORY for x86-32. The code seems to be shared between x86-32 and 64, I'm not seeing why set_memory_r[ow]() should fail on one but not the other. Considering that it seems to be flaky even on 32-bit, maybe it's

Re: [net/bpf] 3051bf36c2 BUG: unable to handle kernel paging request at 0000a7cf

Adding x86 people too, since this seems to be something off about ARCH_HAS_SET_MEMORY for x86-32. The code seems to be shared between x86-32 and 64, I'm not seeing why set_memory_r[ow]() should fail on one but not the other. Considering that it seems to be flaky even on 32-bit, maybe it's

Re: [PATCH 6/7] xen/9pfs: receive responses

On Wed, 8 Mar 2017, Boris Ostrovsky wrote: > >>> + > >>> + if (xen_9pfs_queued(prod, cons, XEN_9PFS_RING_SIZE) < > >>> sizeof(h)) { > >>> + notify_remote_via_irq(ring->irq); > >>> + return; > >>> + } > >>> + > >>> + masked_prod =

Re: [PATCH 6/7] xen/9pfs: receive responses

On Wed, 8 Mar 2017, Boris Ostrovsky wrote: > >>> + > >>> + if (xen_9pfs_queued(prod, cons, XEN_9PFS_RING_SIZE) < > >>> sizeof(h)) { > >>> + notify_remote_via_irq(ring->irq); > >>> + return; > >>> + } > >>> + > >>> + masked_prod =

Re: [PATCH 4/7] xen/9pfs: connect to the backend

On Wed, 8 Mar 2017, Boris Ostrovsky wrote: > >>> + ring->bytes = (void*)__get_free_pages(GFP_KERNEL | __GFP_ZERO, > >>> XEN_9PFS_RING_ORDER); > >>> + if (ring->bytes == NULL) > >>> + goto error; > >>> + for (i = 0; i < (1 << XEN_9PFS_RING_ORDER); i++) > >>> + ring->intf->ref[i] =

Re: [PATCH 4/7] xen/9pfs: connect to the backend

On Wed, 8 Mar 2017, Boris Ostrovsky wrote: > >>> + ring->bytes = (void*)__get_free_pages(GFP_KERNEL | __GFP_ZERO, > >>> XEN_9PFS_RING_ORDER); > >>> + if (ring->bytes == NULL) > >>> + goto error; > >>> + for (i = 0; i < (1 << XEN_9PFS_RING_ORDER); i++) > >>> + ring->intf->ref[i] =

Re: [PATCH v2 6/9] mm: set mapping error when launder_pages fails

On Wed, 2017-03-08 at 13:38 -0500, Jeff Layton wrote: > On Wed, 2017-03-08 at 18:01 +, Trond Myklebust wrote: > > On Wed, 2017-03-08 at 11:29 -0500, Jeff Layton wrote: > > > If launder_page fails, then we hit a problem writing back some > > > inode > > > data. Ensure that we communicate that

Re: [PATCH v2 6/9] mm: set mapping error when launder_pages fails

On Wed, 2017-03-08 at 13:38 -0500, Jeff Layton wrote: > On Wed, 2017-03-08 at 18:01 +, Trond Myklebust wrote: > > On Wed, 2017-03-08 at 11:29 -0500, Jeff Layton wrote: > > > If launder_page fails, then we hit a problem writing back some > > > inode > > > data. Ensure that we communicate that

<    1   2   3   4   5   6   7   8   9   10   >