Re: [PATCH for-4.6-fixes] memcg: remove lru_add_drain_all() invocation from mem_cgroup_move_charge()

On Wed 2016-04-20 23:27:05, Michal Hocko wrote: > On Wed 20-04-16 17:29:22, Tejun Heo wrote: > > Hello, Michal. > > > > On Sun, Apr 17, 2016 at 08:07:48AM -0400, Michal Hocko wrote: > [...] > > > I liked your proposal when mem_cgroup_move_charge would be called from a > > > context which doesn't

Re: [PATCH for-4.6-fixes] memcg: remove lru_add_drain_all() invocation from mem_cgroup_move_charge()

On Wed 2016-04-20 23:27:05, Michal Hocko wrote: > On Wed 20-04-16 17:29:22, Tejun Heo wrote: > > Hello, Michal. > > > > On Sun, Apr 17, 2016 at 08:07:48AM -0400, Michal Hocko wrote: > [...] > > > I liked your proposal when mem_cgroup_move_charge would be called from a > > > context which doesn't

[PATCH V2 2/2] perf/x86/intel/uncore: add enable_box for client msr uncore

From: Kan Liang PERF_GLOBAL_CTL could be cleared after Package C7. This patch tries to workaround this issue by re-enable PERF_GLOBAL_CTL in enable_box. The workaround does not cover all cases. It helps for new events after returning from C7. There is no drawback in letting

[PATCH V2 1/2] perf/x86/intel/uncore: Add support for Intel SKL client uncore

From: Kan Liang This patch addes full support for Intel SKL client uncore. - Add support for SKL client cpu uncore, which is similar to BDW client. There are some differences in CBOX number and uncore control MSR. - Add new CPU model 78 for SkyLake Mobile, include

Re: [PATCH 03/18] dmaengine: st_fdma: Add STMicroelectronics FDMA engine driver support

Hi Appana, Thanks for the review. On Thu, 21 Apr 2016, Appana Durga Kedareswara Rao wrote: > > > > -Original Message- > > From: dmaengine-ow...@vger.kernel.org [mailto:dmaengine- > > ow...@vger.kernel.org] On Behalf Of Peter Griffin > > Sent: Thursday, April 21, 2016 4:34 PM > > To:

[PATCH V2 2/2] perf/x86/intel/uncore: add enable_box for client msr uncore

From: Kan Liang PERF_GLOBAL_CTL could be cleared after Package C7. This patch tries to workaround this issue by re-enable PERF_GLOBAL_CTL in enable_box. The workaround does not cover all cases. It helps for new events after returning from C7. There is no drawback in letting the thing enabled, so

[PATCH V2 1/2] perf/x86/intel/uncore: Add support for Intel SKL client uncore

From: Kan Liang This patch addes full support for Intel SKL client uncore. - Add support for SKL client cpu uncore, which is similar to BDW client. There are some differences in CBOX number and uncore control MSR. - Add new CPU model 78 for SkyLake Mobile, include both cpu and pci

Re: [PATCH 03/18] dmaengine: st_fdma: Add STMicroelectronics FDMA engine driver support

Hi Appana, Thanks for the review. On Thu, 21 Apr 2016, Appana Durga Kedareswara Rao wrote: > > > > -Original Message- > > From: dmaengine-ow...@vger.kernel.org [mailto:dmaengine- > > ow...@vger.kernel.org] On Behalf Of Peter Griffin > > Sent: Thursday, April 21, 2016 4:34 PM > > To:

Re: [PATCH] watchdog: core: Fix circular locking dependency

> Turns out the call to cancel_delayed_work_sync() in watchdog_release() > is not necessary and can be dropped. If the worker is no longer necessary, > the subsequent call to watchdog_update_worker() will cancel it. If it is > already running, it won't do anything, since the worker function checks

Re: [PATCH] watchdog: core: Fix circular locking dependency

> Turns out the call to cancel_delayed_work_sync() in watchdog_release() > is not necessary and can be dropped. If the worker is no longer necessary, > the subsequent call to watchdog_update_worker() will cancel it. If it is > already running, it won't do anything, since the worker function checks

[PATCH v3 2/5] arm64: Allow a capability to be checked on a single CPU

From: Marc Zyngier Now that the capabilities are only available once all the CPUs have booted, we're unable to check for a particular feature in any subsystem that gets initialized before then. In order to support this, introduce a local_cpu_has_cap() function that tests

[PATCH v3 2/5] arm64: Allow a capability to be checked on a single CPU

From: Marc Zyngier Now that the capabilities are only available once all the CPUs have booted, we're unable to check for a particular feature in any subsystem that gets initialized before then. In order to support this, introduce a local_cpu_has_cap() function that tests for the presence of a

Re: [PATCH V2 RFC] fixup! virtio: convert to use DMA api

On Thu, Apr 21, 2016 at 04:43:45PM +0300, Michael S. Tsirkin wrote: > This adds a flag to enable/disable bypassing the IOMMU by > virtio devices. > > This is on top of patch > http://article.gmane.org/gmane.comp.emulators.qemu/403467 > virtio: convert to use DMA api > > Tested with patchset >

[PATCH v3 1/5] arm64: cpufeature: Add scope for capability check

Add scope parameter to the arm64_cpu_capabilities::matches(), so that this can be reused for checking the capability on a given CPU vs the system wide. The system uses the default scope associated with the capability for initialising the CPU_HWCAPs and ELF_HWCAPs. Cc: James Morse

Re: [PATCH V2 RFC] fixup! virtio: convert to use DMA api

On Thu, Apr 21, 2016 at 04:43:45PM +0300, Michael S. Tsirkin wrote: > This adds a flag to enable/disable bypassing the IOMMU by > virtio devices. > > This is on top of patch > http://article.gmane.org/gmane.comp.emulators.qemu/403467 > virtio: convert to use DMA api > > Tested with patchset >

[PATCH v3 1/5] arm64: cpufeature: Add scope for capability check

Add scope parameter to the arm64_cpu_capabilities::matches(), so that this can be reused for checking the capability on a given CPU vs the system wide. The system uses the default scope associated with the capability for initialising the CPU_HWCAPs and ELF_HWCAPs. Cc: James Morse Cc: Marc

[PATCH v3 0/5] arm64: Fix behavior of maxcpus=n

This series is an attempt at fixing the maxcpus=n behavior on arm64. So far we have disabled hotplugging a CPU > n, when maxcpus=n is in effect, due to following reasons. 1) Possible cpu feature incompatibilities with the new CPU in heterogeneous systems. 2) New CPU requiring an errata work

[PATCH v3 0/5] arm64: Fix behavior of maxcpus=n

This series is an attempt at fixing the maxcpus=n behavior on arm64. So far we have disabled hotplugging a CPU > n, when maxcpus=n is in effect, due to following reasons. 1) Possible cpu feature incompatibilities with the new CPU in heterogeneous systems. 2) New CPU requiring an errata work

[PATCH v3 5/5] arm64: Fix behavior of maxcpus=N

maxcpu=n sets the number of CPUs activated at boot time to a max of n, but allowing the remaining CPUs to be brought up later if the user decides to do so. However, on arm64 due to various reasons, we disallowed hotplugging CPUs beyond n, by marking them not present. Now that we have checks in

[PATCH v3 5/5] arm64: Fix behavior of maxcpus=N

maxcpu=n sets the number of CPUs activated at boot time to a max of n, but allowing the remaining CPUs to be brought up later if the user decides to do so. However, on arm64 due to various reasons, we disallowed hotplugging CPUs beyond n, by marking them not present. Now that we have checks in

[PATCH] watchdog: core: Fix circular locking dependency

lockdep reports the following circular locking dependency. == INFO: possible circular locking dependency detected ] 4.6.0-rc3-00191-gfabf418 #162 Not tainted --- systemd/1 is trying to acquire

[PATCH] watchdog: core: Fix circular locking dependency

lockdep reports the following circular locking dependency. == INFO: possible circular locking dependency detected ] 4.6.0-rc3-00191-gfabf418 #162 Not tainted --- systemd/1 is trying to acquire

Re: stable-security kernel updates

On 04/21/2016, 03:53 PM, Sasha Levin wrote: >> Pardom my ignorance, how can you actually be sure? > > I'm not, same way you can't be sure about your stable patch selection either. I repeat I am not doing any selection. Patches are not included iff they do not apply and I am not confident enough

Re: stable-security kernel updates

On 04/21/2016, 03:53 PM, Sasha Levin wrote: >> Pardom my ignorance, how can you actually be sure? > > I'm not, same way you can't be sure about your stable patch selection either. I repeat I am not doing any selection. Patches are not included iff they do not apply and I am not confident enough

[GIT PULL] fbdev fixes for 4.6

Hi Linus, Please pull these two fbdev fixes for 4.6. Tomi The following changes since commit c3b46c73264b03000d1e18b22f5caf63332547c9: Linux 4.6-rc4 (2016-04-17 19:13:32 -0700) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/tomba/linux.git

[GIT PULL] fbdev fixes for 4.6

Hi Linus, Please pull these two fbdev fixes for 4.6. Tomi The following changes since commit c3b46c73264b03000d1e18b22f5caf63332547c9: Linux 4.6-rc4 (2016-04-17 19:13:32 -0700) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/tomba/linux.git

Re: [PATCH v2] Force cppc_cpufreq to report values in KHz to fix user space reporting

On Tue, Apr 19, 2016 at 1:11 AM, Al Stone wrote: > > When CPPC is being used by ACPI on arm64, user space tools such as > cpupower report CPU frequency values from sysfs that are incorrect. > > What the driver was doing was reporting the values given by ACPI tables > in

Re: [PATCH v2] Force cppc_cpufreq to report values in KHz to fix user space reporting

On Tue, Apr 19, 2016 at 1:11 AM, Al Stone wrote: > > When CPPC is being used by ACPI on arm64, user space tools such as > cpupower report CPU frequency values from sysfs that are incorrect. > > What the driver was doing was reporting the values given by ACPI tables > in whatever scale was used

Re: [PATCH v4 0/2] Skylake PSys support

On Thu, 2016-04-21 at 15:10 +0200, Peter Zijlstra wrote: > On Wed, Apr 20, 2016 at 10:21:14PM +0200, Rafael J. Wysocki wrote: > > You can send both and they both can go in via tip as far as I'm > > concerned. > > OK, thanks! > > Srinivas I've munged the rapl patch to match the new style, so no >

Re: [PATCH v4 0/2] Skylake PSys support

On Thu, 2016-04-21 at 15:10 +0200, Peter Zijlstra wrote: > On Wed, Apr 20, 2016 at 10:21:14PM +0200, Rafael J. Wysocki wrote: > > You can send both and they both can go in via tip as far as I'm > > concerned. > > OK, thanks! > > Srinivas I've munged the rapl patch to match the new style, so no >

Re: Major KVM issues with kernel 4.5 on the host

On Thu, Apr 21, 2016 at 02:37:11PM +0200, Borislav Petkov wrote: > On Thu, Apr 21, 2016 at 10:39:48AM +0200, Marc Haber wrote: > > Currently, I cannot explain how this has happened, I must have flagged > > an actually good kernel as bad from my understanding of git bisect. > > > > Can you give

Re: Major KVM issues with kernel 4.5 on the host

On Thu, Apr 21, 2016 at 02:37:11PM +0200, Borislav Petkov wrote: > On Thu, Apr 21, 2016 at 10:39:48AM +0200, Marc Haber wrote: > > Currently, I cannot explain how this has happened, I must have flagged > > an actually good kernel as bad from my understanding of git bisect. > > > > Can you give

[PATCH 07/11] NFC: pn533: improve cmd queue handling

Make sure cmd is set before a frame is passed to the transport layer for sending. In addition pn533_send_async_complete checks if cmd is set before accessing its members. Signed-off-by: Michael Thalmeier --- drivers/nfc/pn533/pn533.c | 54

[PATCH 07/11] NFC: pn533: improve cmd queue handling

Make sure cmd is set before a frame is passed to the transport layer for sending. In addition pn533_send_async_complete checks if cmd is set before accessing its members. Signed-off-by: Michael Thalmeier --- drivers/nfc/pn533/pn533.c | 54 +-- 1 file

Re: [PATCH 1/5] x86, KASLR: Update description for decompressor worst case size

On Wed, Apr 20, 2016 at 01:55:42PM -0700, Kees Cook wrote: ... > diff --git a/arch/x86/boot/header.S b/arch/x86/boot/header.S > index 6236b9ec4b76..6b8f8728c1fa 100644 > --- a/arch/x86/boot/header.S > +++ b/arch/x86/boot/header.S > @@ -440,6 +440,93 @@ setup_data: .quad 0

Re: [PATCH 1/5] x86, KASLR: Update description for decompressor worst case size

On Wed, Apr 20, 2016 at 01:55:42PM -0700, Kees Cook wrote: ... > diff --git a/arch/x86/boot/header.S b/arch/x86/boot/header.S > index 6236b9ec4b76..6b8f8728c1fa 100644 > --- a/arch/x86/boot/header.S > +++ b/arch/x86/boot/header.S > @@ -440,6 +440,93 @@ setup_data: .quad 0

[PATCH 11/11] nfc: pn533: increase clock frequency for PN532

Default clock frequency of PN532 is 6.78 MHz. Increase the frequency to 27.12 MHz to increase throughput. Signed-off-by: Michael Thalmeier --- drivers/nfc/pn533/pn533.c | 70 +++ drivers/nfc/pn533/pn533.h | 2 ++ 2 files

[PATCH 11/11] nfc: pn533: increase clock frequency for PN532

Default clock frequency of PN532 is 6.78 MHz. Increase the frequency to 27.12 MHz to increase throughput. Signed-off-by: Michael Thalmeier --- drivers/nfc/pn533/pn533.c | 70 +++ drivers/nfc/pn533/pn533.h | 2 ++ 2 files changed, 72 insertions(+)

[PATCH 04/11] NFC: pn533: reset poll modulation list before calling nfc_targets_found

We need to reset the poll modulation list before calling nfc_targets_found because otherwise it is possible that the application is scheduled to run before the modulation list is cleared and gets an error "Cannot activate target while polling" upon calling activate_target. Signed-off-by: Michael

[PATCH 04/11] NFC: pn533: reset poll modulation list before calling nfc_targets_found

We need to reset the poll modulation list before calling nfc_targets_found because otherwise it is possible that the application is scheduled to run before the modulation list is cleared and gets an error "Cannot activate target while polling" upon calling activate_target. Signed-off-by: Michael

[PATCH 08/11] NFC: pn533: reduce output when stopping poll

Handle return codes for stopped polling operations better to reduce logging activity. Signed-off-by: Michael Thalmeier --- drivers/nfc/pn533/pn533.c | 8 +++- 1 file changed, 3 insertions(+), 5 deletions(-) diff --git a/drivers/nfc/pn533/pn533.c

[PATCH 06/11] NFC: pn533: usb: fix errors when poll is stopped

When a poll ist stopped we need to kill the out_urb request too before starting a new request. Additionally check if cmd is set in pn533_recv_ack befor accessing its struct members. Signed-off-by: Michael Thalmeier --- drivers/nfc/pn533/usb.c | 12 +--- 1

[PATCH 08/11] NFC: pn533: reduce output when stopping poll

Handle return codes for stopped polling operations better to reduce logging activity. Signed-off-by: Michael Thalmeier --- drivers/nfc/pn533/pn533.c | 8 +++- 1 file changed, 3 insertions(+), 5 deletions(-) diff --git a/drivers/nfc/pn533/pn533.c b/drivers/nfc/pn533/pn533.c index

[PATCH 06/11] NFC: pn533: usb: fix errors when poll is stopped

When a poll ist stopped we need to kill the out_urb request too before starting a new request. Additionally check if cmd is set in pn533_recv_ack befor accessing its struct members. Signed-off-by: Michael Thalmeier --- drivers/nfc/pn533/usb.c | 12 +--- 1 file changed, 9 insertions(+),

[PATCH 03/11] NFC: pn533: i2c: do not call pn533_recv_frame with aborted commands

When a command gets aborted the pn533 core does not need any RX frames that may be received until a new frame is sent. Signed-off-by: Michael Thalmeier --- drivers/nfc/pn533/i2c.c | 15 +++ 1 file changed, 11 insertions(+), 4 deletions(-) diff --git

[PATCH 09/11] NFC: pn533: use nfc_alloc_recv_skb for skb allocation

When multiple receive frames need to be put together in pn533_build_response we need to use nfc_alloc_recv_skb instead of the normal alloc_skb. Otherwise the nfc core causes an skb error when it tries to push the status byte in front of the data. Signed-off-by: Michael Thalmeier

[PATCH 09/11] NFC: pn533: use nfc_alloc_recv_skb for skb allocation

When multiple receive frames need to be put together in pn533_build_response we need to use nfc_alloc_recv_skb instead of the normal alloc_skb. Otherwise the nfc core causes an skb error when it tries to push the status byte in front of the data. Signed-off-by: Michael Thalmeier ---

[PATCH 03/11] NFC: pn533: i2c: do not call pn533_recv_frame with aborted commands

When a command gets aborted the pn533 core does not need any RX frames that may be received until a new frame is sent. Signed-off-by: Michael Thalmeier --- drivers/nfc/pn533/i2c.c | 15 +++ 1 file changed, 11 insertions(+), 4 deletions(-) diff --git a/drivers/nfc/pn533/i2c.c

[PATCH 00/11] NFC: pn533: bug fixes and improvements

Hello Samuel, This patchset fixes some major bugs in the pn533 drivers (usb and i2c) and improves performance of the PN532 chip by increasing its clock speed. Best Regards Michael Michael Thalmeier (11): NFC: pn533: i2c: free irq on driver remove NFC: pn533: fix order of initialization

[PATCH 00/11] NFC: pn533: bug fixes and improvements

Hello Samuel, This patchset fixes some major bugs in the pn533 drivers (usb and i2c) and improves performance of the PN532 chip by increasing its clock speed. Best Regards Michael Michael Thalmeier (11): NFC: pn533: i2c: free irq on driver remove NFC: pn533: fix order of initialization

[PATCH 05/11] NFC: pn533: handle interrupted commands in pn533_recv_frame

When pn533_recv_frame is called from within abort_command context the current dev->cmd is not guaranteed to be set. Additionally on receiving an error status we can omit frame checking and simply schedule the workquueue. Signed-off-by: Michael Thalmeier ---

[PATCH 05/11] NFC: pn533: handle interrupted commands in pn533_recv_frame

When pn533_recv_frame is called from within abort_command context the current dev->cmd is not guaranteed to be set. Additionally on receiving an error status we can omit frame checking and simply schedule the workquueue. Signed-off-by: Michael Thalmeier --- drivers/nfc/pn533/pn533.c | 8

[PATCH 02/11] NFC: pn533: fix order of initialization

Correctly call nfc_set_parent_dev before nfc_register_device. Otherwise the driver will oops when being removed. Signed-off-by: Michael Thalmeier --- drivers/nfc/pn533/i2c.c | 3 ++- drivers/nfc/pn533/pn533.c | 4 +++- drivers/nfc/pn533/pn533.h | 3 ++-

[PATCH 01/11] NFC: pn533: i2c: free irq on driver remove

The requested irq needs to be freed when removing the driver, otherwise a following driver load fails to request the irq. Signed-off-by: Michael Thalmeier --- drivers/nfc/pn533/i2c.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/drivers/nfc/pn533/i2c.c

[PATCH 02/11] NFC: pn533: fix order of initialization

Correctly call nfc_set_parent_dev before nfc_register_device. Otherwise the driver will oops when being removed. Signed-off-by: Michael Thalmeier --- drivers/nfc/pn533/i2c.c | 3 ++- drivers/nfc/pn533/pn533.c | 4 +++- drivers/nfc/pn533/pn533.h | 3 ++- drivers/nfc/pn533/usb.c | 3 +-- 4

[PATCH 01/11] NFC: pn533: i2c: free irq on driver remove

The requested irq needs to be freed when removing the driver, otherwise a following driver load fails to request the irq. Signed-off-by: Michael Thalmeier --- drivers/nfc/pn533/i2c.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/drivers/nfc/pn533/i2c.c b/drivers/nfc/pn533/i2c.c index

[PATCH 10/11] NFC: pn533: set cmd status when not set

When pn533_recv_frame is called with skb = NULL and cmd->status = 0, set cmd->status to an error code. Signed-off-by: Michael Thalmeier --- drivers/nfc/pn533/pn533.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/drivers/nfc/pn533/pn533.c

[PATCH 10/11] NFC: pn533: set cmd status when not set

When pn533_recv_frame is called with skb = NULL and cmd->status = 0, set cmd->status to an error code. Signed-off-by: Michael Thalmeier --- drivers/nfc/pn533/pn533.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/drivers/nfc/pn533/pn533.c b/drivers/nfc/pn533/pn533.c index

Re: [PATCH] OMAPDSS: HDMI5: Fix AVI infoframe

Hi, On 21/04/16 16:48, J.D. Schroeder wrote: > From: "Lodes, Jim" > > The AVI infoframe R0-R3 in the 2nd data byte represents the > Active Format Aspect Ratio. It is four bits long not two bits. > This fixes that mask used to extract the bits before writing the > bits to

Re: [PATCH] OMAPDSS: HDMI5: Fix AVI infoframe

Hi, On 21/04/16 16:48, J.D. Schroeder wrote: > From: "Lodes, Jim" > > The AVI infoframe R0-R3 in the 2nd data byte represents the > Active Format Aspect Ratio. It is four bits long not two bits. > This fixes that mask used to extract the bits before writing the > bits to the hardware registers.

Re: [PATCH] nohz_full: Make sched_should_stop_tick() more conservative

On Mon, Apr 18, 2016 at 10:00:42AM +0800, Wanpeng Li wrote: > > H is for hierarchy. That counts the total of runnable tasks in the > > entire child hierarchy. Nr_running is the number of se entities in > > the current tree. > > So I think we should at least change cfs_rq->nr_running to >

Re: [PATCH] nohz_full: Make sched_should_stop_tick() more conservative

On Mon, Apr 18, 2016 at 10:00:42AM +0800, Wanpeng Li wrote: > > H is for hierarchy. That counts the total of runnable tasks in the > > entire child hierarchy. Nr_running is the number of se entities in > > the current tree. > > So I think we should at least change cfs_rq->nr_running to >

Re: [PATCH v2] ARM: exynos_defconfig: Enable Samsung media platform drivers as modules

[adding Seung-Woo Kim to cc] Hello Krzysztof, On 03/28/2016 09:25 PM, Krzysztof Kozlowski wrote: > On 29.03.2016 00:15, Javier Martinez Canillas wrote: >> Tobias mentioned on IRC that the exynos4-is driver conflicts with the >> Exynos DRM driver since both exynos_drm_fimc and exynos-fimc-is use

Re: [PATCH v2] ARM: exynos_defconfig: Enable Samsung media platform drivers as modules

[adding Seung-Woo Kim to cc] Hello Krzysztof, On 03/28/2016 09:25 PM, Krzysztof Kozlowski wrote: > On 29.03.2016 00:15, Javier Martinez Canillas wrote: >> Tobias mentioned on IRC that the exynos4-is driver conflicts with the >> Exynos DRM driver since both exynos_drm_fimc and exynos-fimc-is use

Re: [PATCH] OMAPDSS: HDMI5: Change DDC timings

Hi, On 21/04/16 03:02, J.D. Schroeder wrote: > From: "Lodes, Jim" > > The DDC scl high and low times were set to the minimum values > from the i2c specification, but the i2c specification takes into > account the rise time and fall time to calculate the frequency. > To

Re: [PATCH] OMAPDSS: HDMI5: Change DDC timings

Hi, On 21/04/16 03:02, J.D. Schroeder wrote: > From: "Lodes, Jim" > > The DDC scl high and low times were set to the minimum values > from the i2c specification, but the i2c specification takes into > account the rise time and fall time to calculate the frequency. > To pass HDMI certification

Re: [PATCH v7 1/2] dt: bindings: add MARVELL's bt-sd8xxx wireless device

On Mon, Apr 18, 2016 at 05:23:49AM -0700, Amitkumar Karwar wrote: > From: Xinming Hu > > Add device tree binding documentation for MARVELL's bluetooth sdio > (sd8897 and sd8997) chip. > > Signed-off-by: Xinming Hu > Signed-off-by: Amitkumar Karwar

Re: [PATCH v7 1/2] dt: bindings: add MARVELL's bt-sd8xxx wireless device

On Mon, Apr 18, 2016 at 05:23:49AM -0700, Amitkumar Karwar wrote: > From: Xinming Hu > > Add device tree binding documentation for MARVELL's bluetooth sdio > (sd8897 and sd8997) chip. > > Signed-off-by: Xinming Hu > Signed-off-by: Amitkumar Karwar > --- > Listing changelist for both 1/2 and

Re: [PATCH v2 7/7] rtc: Kconfig: Name RK818 in Kconfig for RTC_DRV_RK808

On 21/04/2016 at 15:12:41 +0200, Wadim Egorov wrote : > The RK808 and RK818 PMICs are using a similar register map. > We can reuse the rtc driver for the RK818 PMIC. So let's add > the RK818 in the Kconfig description. > > Signed-off-by: Wadim Egorov Acked-by: Alexandre

Re: [PATCH v2 7/7] rtc: Kconfig: Name RK818 in Kconfig for RTC_DRV_RK808

On 21/04/2016 at 15:12:41 +0200, Wadim Egorov wrote : > The RK808 and RK818 PMICs are using a similar register map. > We can reuse the rtc driver for the RK818 PMIC. So let's add > the RK818 in the Kconfig description. > > Signed-off-by: Wadim Egorov Acked-by: Alexandre Belloni > --- >

Re: stable-security kernel updates

On Thu, Apr 21, 2016 at 10:27:46AM -0400, Sasha Levin wrote: > This means that missing CVE fixes are quite common with stable trees? Until someone reports they are missing :-) Willy

Re: stable-security kernel updates

On Thu, Apr 21, 2016 at 10:27:46AM -0400, Sasha Levin wrote: > This means that missing CVE fixes are quite common with stable trees? Until someone reports they are missing :-) Willy

Re: [PATCH v2] MAINTAINERS: net: add entry for TI Ethernet Switch drivers

* Mugunthan V N [160421 04:19]: > On Thursday 21 April 2016 03:43 PM, Grygorii Strashko wrote: > > Add record for TI Ethernet Switch Driver CPSW/CPDMA/MDIO HW > > (am33/am43/am57/dr7/davinci) to ensure that related patches > > will go through dedicated linux-omap list. > > >

Re: [PATCH v2] MAINTAINERS: net: add entry for TI Ethernet Switch drivers

* Mugunthan V N [160421 04:19]: > On Thursday 21 April 2016 03:43 PM, Grygorii Strashko wrote: > > Add record for TI Ethernet Switch Driver CPSW/CPDMA/MDIO HW > > (am33/am43/am57/dr7/davinci) to ensure that related patches > > will go through dedicated linux-omap list. > > > > Also add Mugunthan

Re: [RESEND PATCH v4] clk/axs10x: Add I2S PLL clock driver

Hi Jose, On Thu, 2016-04-21 at 14:10 +0100, Jose Abreu wrote: > Hi Alexey, > > > On 21-04-2016 13:18, Alexey Brodkin wrote: > > > > Hi Jose, > > > > On Thu, 2016-04-21 at 10:51 +0100, Jose Abreu wrote: > > > > > > Hi Alexey, > > >  > > Ok reference clock will change. > > But I may guess

Re: [RESEND PATCH v4] clk/axs10x: Add I2S PLL clock driver

Hi Jose, On Thu, 2016-04-21 at 14:10 +0100, Jose Abreu wrote: > Hi Alexey, > > > On 21-04-2016 13:18, Alexey Brodkin wrote: > > > > Hi Jose, > > > > On Thu, 2016-04-21 at 10:51 +0100, Jose Abreu wrote: > > > > > > Hi Alexey, > > >  > > Ok reference clock will change. > > But I may guess

Re: [PATCH v4 3/4] devicetree: Add ANX7814 SlimPort transmitter binding.

On Mon, Apr 18, 2016 at 01:26:11PM +0200, Enric Balletbo i Serra wrote: > The ANX7814 is an ultra-low power Full-HD (1080p60) SlimPort transmitter > designed for portable devices. > > Signed-off-by: Enric Balletbo i Serra > Cc: Rob Herring > --- >

Re: [PATCH v4 3/4] devicetree: Add ANX7814 SlimPort transmitter binding.

On Mon, Apr 18, 2016 at 01:26:11PM +0200, Enric Balletbo i Serra wrote: > The ANX7814 is an ultra-low power Full-HD (1080p60) SlimPort transmitter > designed for portable devices. > > Signed-off-by: Enric Balletbo i Serra > Cc: Rob Herring > --- > Changes since v3: > - Model v10 as regulator

Re: [PATCH v4 1/2] KVM: remove NULL return path for vcpu ids >= KVM_MAX_VCPUS

On Thu, 21 Apr 2016 16:17:29 +0200 David Hildenbrand wrote: > > Commit c896939f7cff ("KVM: use heuristic for fast VCPU lookup by id") added > > a return path that prevents vcpu ids to exceed KVM_MAX_VCPUS. This is a > > problem for powerpc where vcpu ids can grow up to

Re: [PATCH v4 1/2] KVM: remove NULL return path for vcpu ids >= KVM_MAX_VCPUS

On Thu, 21 Apr 2016 16:17:29 +0200 David Hildenbrand wrote: > > Commit c896939f7cff ("KVM: use heuristic for fast VCPU lookup by id") added > > a return path that prevents vcpu ids to exceed KVM_MAX_VCPUS. This is a > > problem for powerpc where vcpu ids can grow up to 8*KVM_MAX_VCPUS. > > > >

Re: stable-security kernel updates

On 04/21/2016 10:13 AM, Jiri Slaby wrote: > On 04/21/2016, 03:54 PM, Sasha Levin wrote: >> On 04/21/2016 08:39 AM, Greg KH wrote: >>> On Thu, Apr 21, 2016 at 02:05:41PM +0200, Jiri Slaby wrote: > On 04/21/2016, 01:59 PM, Jiri Slaby wrote: > (CVE-2016-2085) 613317b EVM: Use

Re: stable-security kernel updates

On 04/21/2016 10:13 AM, Jiri Slaby wrote: > On 04/21/2016, 03:54 PM, Sasha Levin wrote: >> On 04/21/2016 08:39 AM, Greg KH wrote: >>> On Thu, Apr 21, 2016 at 02:05:41PM +0200, Jiri Slaby wrote: > On 04/21/2016, 01:59 PM, Jiri Slaby wrote: > (CVE-2016-2085) 613317b EVM: Use

Re: [patch] direct-io: propagate -ENOSPC errors

On 03/21/2016 04:22 PM, Jeff Moyer wrote: >> Just propagating some errors defintively seems odd. > > Not really. read, write, etc only expect a subset of errnos to be > returned. The goal was not to leak kernel-internal or unexpected error > numbers to userspace, and I didn't think I would be

Re: [patch] direct-io: propagate -ENOSPC errors

On 03/21/2016 04:22 PM, Jeff Moyer wrote: >> Just propagating some errors defintively seems odd. > > Not really. read, write, etc only expect a subset of errnos to be > returned. The goal was not to leak kernel-internal or unexpected error > numbers to userspace, and I didn't think I would be

[PATCH] OMAPDSS: HDMI5: Fix AVI infoframe

From: "Lodes, Jim" The AVI infoframe R0-R3 in the 2nd data byte represents the Active Format Aspect Ratio. It is four bits long not two bits. This fixes that mask used to extract the bits before writing the bits to the hardware registers. Signed-off-by: Lodes, Jim

[PATCH] OMAPDSS: HDMI5: Fix AVI infoframe

From: "Lodes, Jim" The AVI infoframe R0-R3 in the 2nd data byte represents the Active Format Aspect Ratio. It is four bits long not two bits. This fixes that mask used to extract the bits before writing the bits to the hardware registers. Signed-off-by: Lodes, Jim Signed-off-by: J.D. Schroeder

[PATCH v4 2/2] KVM: move vcpu id checking to archs

Commit 338c7dbadd26 ("KVM: Improve create VCPU parameter (CVE-2013-4587)") introduced a check to prevent potential kernel memory corruption in case the vcpu id is too great. Unfortunately this check assumes vcpu ids grow in sequence with a common difference of 1, which is wrong: archs are free to

[PATCH v4 2/2] KVM: move vcpu id checking to archs

Commit 338c7dbadd26 ("KVM: Improve create VCPU parameter (CVE-2013-4587)") introduced a check to prevent potential kernel memory corruption in case the vcpu id is too great. Unfortunately this check assumes vcpu ids grow in sequence with a common difference of 1, which is wrong: archs are free to

[PATCH v4 1/2] KVM: remove NULL return path for vcpu ids >= KVM_MAX_VCPUS

Commit c896939f7cff ("KVM: use heuristic for fast VCPU lookup by id") added a return path that prevents vcpu ids to exceed KVM_MAX_VCPUS. This is a problem for powerpc where vcpu ids can grow up to 8*KVM_MAX_VCPUS. This patch simply reverses the logic so that we only try fast path if the vcpu id

[PATCH v4 1/2] KVM: remove NULL return path for vcpu ids >= KVM_MAX_VCPUS

Commit c896939f7cff ("KVM: use heuristic for fast VCPU lookup by id") added a return path that prevents vcpu ids to exceed KVM_MAX_VCPUS. This is a problem for powerpc where vcpu ids can grow up to 8*KVM_MAX_VCPUS. This patch simply reverses the logic so that we only try fast path if the vcpu id

[PATCH v4 0/2] let archs decide for vcpu ids

This series mostly addresses Radim's comments on my previous patch "KVM: remove buggy vcpu id check on vcpu creation": - prepended a patch to fix kvm_get_vcpu_by_id() - updated the KVM API documentation --- Greg Kurz (2): KVM: remove NULL return path for vcpu ids >= KVM_MAX_VCPUS

[PATCH v4 0/2] let archs decide for vcpu ids

This series mostly addresses Radim's comments on my previous patch "KVM: remove buggy vcpu id check on vcpu creation": - prepended a patch to fix kvm_get_vcpu_by_id() - updated the KVM API documentation --- Greg Kurz (2): KVM: remove NULL return path for vcpu ids >= KVM_MAX_VCPUS

Re: [PATCH v2 1/7] drivers: mfd: rk808: rename rk808 struct to rk8xx

On 21/04/2016 at 15:12:35 +0200, Wadim Egorov wrote : > This patch renames the rk808 struct. So it is more clear that this > struct can be shared between all RK8XX related PMIC drivers. > I'm still thinking this is unnecessary and that the rk8xx will become more confusing that rx808 in the

Re: [PATCH v2 1/7] drivers: mfd: rk808: rename rk808 struct to rk8xx

On 21/04/2016 at 15:12:35 +0200, Wadim Egorov wrote : > This patch renames the rk808 struct. So it is more clear that this > struct can be shared between all RK8XX related PMIC drivers. > I'm still thinking this is unnecessary and that the rk8xx will become more confusing that rx808 in the

Re: [PATCHv2 1/5] efi/runtime-wrappers: add {__,}efi_call_virt templates

On Thu, Apr 21, 2016 at 01:55:07PM +0100, Mark Rutland wrote: > On Thu, Apr 21, 2016 at 12:42:56PM +0100, Leif Lindholm wrote: > > On Thu, Apr 21, 2016 at 12:35:25PM +0100, Mark Rutland wrote: > > > Currently each architecture must implement two macros, efi_call_virt and > > > __efi_call_virt,

Re: [PATCHv2 1/5] efi/runtime-wrappers: add {__,}efi_call_virt templates

On Thu, Apr 21, 2016 at 01:55:07PM +0100, Mark Rutland wrote: > On Thu, Apr 21, 2016 at 12:42:56PM +0100, Leif Lindholm wrote: > > On Thu, Apr 21, 2016 at 12:35:25PM +0100, Mark Rutland wrote: > > > Currently each architecture must implement two macros, efi_call_virt and > > > __efi_call_virt,

Re: stable-security kernel updates

On Thu, Apr 21, 2016 at 04:13:07PM +0200, Jiri Slaby wrote: > On 04/21/2016, 03:54 PM, Sasha Levin wrote: > > On 04/21/2016 08:39 AM, Greg KH wrote: > >> On Thu, Apr 21, 2016 at 02:05:41PM +0200, Jiri Slaby wrote: > On 04/21/2016, 01:59 PM, Jiri Slaby wrote: > (CVE-2016-2085) 613317b

Re: stable-security kernel updates

On Thu, Apr 21, 2016 at 04:13:07PM +0200, Jiri Slaby wrote: > On 04/21/2016, 03:54 PM, Sasha Levin wrote: > > On 04/21/2016 08:39 AM, Greg KH wrote: > >> On Thu, Apr 21, 2016 at 02:05:41PM +0200, Jiri Slaby wrote: > On 04/21/2016, 01:59 PM, Jiri Slaby wrote: > (CVE-2016-2085) 613317b

Re: [PATCH 2/3] ASoC: simple-card: Add support jack detection via codec

On Mon, Apr 18, 2016 at 04:17:31PM +0800, Xing Zheng wrote: > In most cases, many codecs already supports jack detection, previouslly, > we need to create a customized machine driver every time. > > Hence, the simple-card need to support use them dynamically via parse dts > file for better

Re: [PATCH 2/3] ASoC: simple-card: Add support jack detection via codec

On Mon, Apr 18, 2016 at 04:17:31PM +0800, Xing Zheng wrote: > In most cases, many codecs already supports jack detection, previouslly, > we need to create a customized machine driver every time. > > Hence, the simple-card need to support use them dynamically via parse dts > file for better

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