[PATCH] spi: spi-ti-qspi: Fix error handling

'dma_request_chan_by_mask()' can not return NULL. Try to keep the logic in 'no_dma:' by resetting 'qspi->rx_chan' in case of error. Signed-off-by: Christophe JAILLET --- drivers/spi/spi-ti-qspi.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git

[PATCH] spi: spi-ti-qspi: Fix error handling

'dma_request_chan_by_mask()' can not return NULL. Try to keep the logic in 'no_dma:' by resetting 'qspi->rx_chan' in case of error. Signed-off-by: Christophe JAILLET --- drivers/spi/spi-ti-qspi.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/drivers/spi/spi-ti-qspi.c

Re: [PATCH] platform/x86: ideapad-laptop: Add sysfs interface for touchpad state

-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Hello Dmitry, On Fri, 2017-02-17 at 11:52 -0800, Dmitry Torokhov wrote: > OK, if firmware disables the touchpad automatically, then it is fine. > > I am wondering about the utility of the new interface though. Are there > already major users of

Re: [PATCH] platform/x86: ideapad-laptop: Add sysfs interface for touchpad state

-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Hello Dmitry, On Fri, 2017-02-17 at 11:52 -0800, Dmitry Torokhov wrote: > OK, if firmware disables the touchpad automatically, then it is fine. > > I am wondering about the utility of the new interface though. Are there > already major users of

Re: [PATCH v7 3/3] i2c: zx2967: add i2c controller driver for ZTE's zx2967 family

2017-02-16 14:00 GMT+08:00 Baoyou Xie : > This patch adds i2c controller driver for ZTE's zx2967 family. > > Signed-off-by: Baoyou Xie > Reviewed-by: Shawn Guo > Reviewed-by: Andy Shevchenko

Re: [PATCH v7 3/3] i2c: zx2967: add i2c controller driver for ZTE's zx2967 family

2017-02-16 14:00 GMT+08:00 Baoyou Xie : > This patch adds i2c controller driver for ZTE's zx2967 family. > > Signed-off-by: Baoyou Xie > Reviewed-by: Shawn Guo > Reviewed-by: Andy Shevchenko Reviewed-by: Jun Nie

next_tick hang was Re: v4.10-rc8 (-rc6) boot regression on Intel desktop, does not boot after cold boots, boots after reboot

Hi! [I droped some CCs here, you may want to check the CC list]. > > These are different bugs. > > > > On x60, I see failures doing hotplug/unplug in a loop, or lot of > > suspends. Someone seen it in v4.8-stable etc. Old bug. Rare to hit. > > > > Desktop machine was failing to boot, and had

next_tick hang was Re: v4.10-rc8 (-rc6) boot regression on Intel desktop, does not boot after cold boots, boots after reboot

Hi! [I droped some CCs here, you may want to check the CC list]. > > These are different bugs. > > > > On x60, I see failures doing hotplug/unplug in a loop, or lot of > > suspends. Someone seen it in v4.8-stable etc. Old bug. Rare to hit. > > > > Desktop machine was failing to boot, and had

Re: [PATCH trivial 1/4] HID: picoLCD: Spelling s/REPORT_WRTIE_MEMORY/REPORT_WRITE_MEMORY/

Hi Geert, Jiri, Fine with me, Acked-by: Bruno Prémont On Fri, 17 Feb 2017 16:36:36 Geert Uytterhoeven wrote: > Signed-off-by: Geert Uytterhoeven > Cc: Bruno Prémont > Cc:

Re: [PATCH trivial 1/4] HID: picoLCD: Spelling s/REPORT_WRTIE_MEMORY/REPORT_WRITE_MEMORY/

Hi Geert, Jiri, Fine with me, Acked-by: Bruno Prémont On Fri, 17 Feb 2017 16:36:36 Geert Uytterhoeven wrote: > Signed-off-by: Geert Uytterhoeven > Cc: Bruno Prémont > Cc: linux-in...@vger.kernel.org > --- > drivers/hid/hid-picolcd_debugfs.c | 2 +- > 1 file changed, 1 insertion(+), 1

[GIT pull] x86 fix for 4.10

Linus, please pull the latest x86-urgent-for-linus git tree from: git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git x86-urgent-for-linus Make the build clean by working around yet another GCC stupidity. Thanks, tglx --> Kirill A. Shutemov (1):

[PATCH] usercopy: Don't test 64-bit get/put_user() on 32-bit powerpc

Add PPC32 to the opt-out list, otherwise it breaks the build. Signed-off-by: Michael Ellerman --- lib/test_user_copy.c | 1 + 1 file changed, 1 insertion(+) diff --git a/lib/test_user_copy.c b/lib/test_user_copy.c index 4a79f2c1cd6e..6f335a3d4ae2 100644 ---

Re: [kernel-hardening] Re: [PATCH] usercopy: Add tests for all get_user() sizes

Kees Cook writes: > On Wed, Feb 15, 2017 at 12:50 AM, Geert Uytterhoeven > wrote: >> On Tue, Feb 14, 2017 at 9:40 PM, Kees Cook wrote: >>> The existing test was only exercising native unsigned long size >>> get_user(). For

[GIT pull] x86 fix for 4.10

Linus, please pull the latest x86-urgent-for-linus git tree from: git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git x86-urgent-for-linus Make the build clean by working around yet another GCC stupidity. Thanks, tglx --> Kirill A. Shutemov (1):

[PATCH] usercopy: Don't test 64-bit get/put_user() on 32-bit powerpc

Add PPC32 to the opt-out list, otherwise it breaks the build. Signed-off-by: Michael Ellerman --- lib/test_user_copy.c | 1 + 1 file changed, 1 insertion(+) diff --git a/lib/test_user_copy.c b/lib/test_user_copy.c index 4a79f2c1cd6e..6f335a3d4ae2 100644 --- a/lib/test_user_copy.c +++

Re: [kernel-hardening] Re: [PATCH] usercopy: Add tests for all get_user() sizes

Kees Cook writes: > On Wed, Feb 15, 2017 at 12:50 AM, Geert Uytterhoeven > wrote: >> On Tue, Feb 14, 2017 at 9:40 PM, Kees Cook wrote: >>> The existing test was only exercising native unsigned long size >>> get_user(). For completeness, we should check all sizes. >>> >>> Signed-off-by: Kees

[GIT pull] locking fix for 4.10

Linus, please pull the latest locking-urgent-for-linus git tree from: git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git locking-urgent-for-linus Move the futex init function to core initcall so user mode helper does not run into an uninitialized futex syscall. Thanks, tglx

[GIT pull] locking fix for 4.10

Linus, please pull the latest locking-urgent-for-linus git tree from: git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git locking-urgent-for-linus Move the futex init function to core initcall so user mode helper does not run into an uninitialized futex syscall. Thanks, tglx

[GIT pull] timer fixes for 4.10

Linus, please pull the latest timers-urgent-for-linus git tree from: git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git timers-urgent-for-linus Two small fixes:: - Prevent deadlock on the tick broadcast lock. Found and fixed by Mike. - Stop using printk() in the timekeeping

[GIT pull] timer fixes for 4.10

Linus, please pull the latest timers-urgent-for-linus git tree from: git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git timers-urgent-for-linus Two small fixes:: - Prevent deadlock on the tick broadcast lock. Found and fixed by Mike. - Stop using printk() in the timekeeping

[PATCH] Staging: xgifb:XGI_main_26: Fixed coding style issues

Fixed coding style issues. Patch applies to linux-next-20170217 tree. Signed-off-by: Georgios Emmanouil --- drivers/staging/xgifb/XGI_main_26.c | 15 --- 1 file changed, 8 insertions(+), 7 deletions(-) diff --git a/drivers/staging/xgifb/XGI_main_26.c

[PATCH] Staging: xgifb:XGI_main_26: Fixed coding style issues

Fixed coding style issues. Patch applies to linux-next-20170217 tree. Signed-off-by: Georgios Emmanouil --- drivers/staging/xgifb/XGI_main_26.c | 15 --- 1 file changed, 8 insertions(+), 7 deletions(-) diff --git a/drivers/staging/xgifb/XGI_main_26.c

Re: [PATCH v4 29/36] media: imx: mipi-csi2: enable setting and getting of frame rates

On Fri, Feb 17, 2017 at 05:12:44PM -0800, Steve Longerbeam wrote: > Hi Russell, > > I signed-off on this but after more review I'm not sure this is right. > > The CSI-2 receiver really has no control over frame rate. It's output > frame rate is the same as the rate that is delivered to it. > >

Re: [PATCH v4 29/36] media: imx: mipi-csi2: enable setting and getting of frame rates

On Fri, Feb 17, 2017 at 05:12:44PM -0800, Steve Longerbeam wrote: > Hi Russell, > > I signed-off on this but after more review I'm not sure this is right. > > The CSI-2 receiver really has no control over frame rate. It's output > frame rate is the same as the rate that is delivered to it. > >

[tip:irq/core] irqchip/qcom: Fix error handling

Commit-ID: 569293c9ca9c5b9b5f7fa3c314ffceafc62957a8 Gitweb: http://git.kernel.org/tip/569293c9ca9c5b9b5f7fa3c314ffceafc62957a8 Author: Christophe JAILLET AuthorDate: Sat, 18 Feb 2017 09:34:34 +0100 Committer: Thomas Gleixner

[tip:irq/core] irqchip/qcom: Fix error handling

Commit-ID: 569293c9ca9c5b9b5f7fa3c314ffceafc62957a8 Gitweb: http://git.kernel.org/tip/569293c9ca9c5b9b5f7fa3c314ffceafc62957a8 Author: Christophe JAILLET AuthorDate: Sat, 18 Feb 2017 09:34:34 +0100 Committer: Thomas Gleixner CommitDate: Sat, 18 Feb 2017 10:19:07 +0100 irqchip/qcom:

Re: [PATCHv3 33/33] mm, x86: introduce PR_SET_MAX_VADDR and PR_GET_MAX_VADDR

On Fri, Feb 17, 2017 at 12:02:13PM -0800, Linus Torvalds wrote: > I also get he feeling that the whole thing is unnecessary. I'm > wondering if we should just instead say that the whole 47 vs 56-bit > virtual address is _purely_ about "get_unmapped_area()", and nothing > else. > > IOW, I'm

Re: [PATCHv3 33/33] mm, x86: introduce PR_SET_MAX_VADDR and PR_GET_MAX_VADDR

On Fri, Feb 17, 2017 at 12:02:13PM -0800, Linus Torvalds wrote: > I also get he feeling that the whole thing is unnecessary. I'm > wondering if we should just instead say that the whole 47 vs 56-bit > virtual address is _purely_ about "get_unmapped_area()", and nothing > else. > > IOW, I'm

Re: [PATCH trivial 3/4] drm/amd: Spelling s/SDMA_WRTIE_SUB_OPCODE_TILED/SDMA_WRITE_SUB_OPCODE_TILED/

Am 17.02.2017 um 16:36 schrieb Geert Uytterhoeven: Signed-off-by: Geert Uytterhoeven Cc: Alex Deucher Cc: Christian König Cc: dri-devel@lists.freedesktop.orgamd-...@lists.freedesktop.org Reviewed-by: Christian

Re: [PATCH trivial 3/4] drm/amd: Spelling s/SDMA_WRTIE_SUB_OPCODE_TILED/SDMA_WRITE_SUB_OPCODE_TILED/

Am 17.02.2017 um 16:36 schrieb Geert Uytterhoeven: Signed-off-by: Geert Uytterhoeven Cc: Alex Deucher Cc: Christian König Cc: dri-devel@lists.freedesktop.orgamd-...@lists.freedesktop.org Reviewed-by: Christian König --- drivers/gpu/drm/amd/amdgpu/cikd.h | 2 +-

Re: [PATCH v9 1/8] drivers:input:tsc2007: add new common binding names, pre-calibration, flipping and rotation

Hi! > > Well, there is some historic confusion wether this driver reports resistance > > or pressure. > > > > The unpatched tsc2007 driver does it wrong (please test!) and we fix it on > > the fly (because a separate patch is much more complex than doing it right > > immediately). > > > > This

Re: [PATCH v9 1/8] drivers:input:tsc2007: add new common binding names, pre-calibration, flipping and rotation

Hi! > > Well, there is some historic confusion wether this driver reports resistance > > or pressure. > > > > The unpatched tsc2007 driver does it wrong (please test!) and we fix it on > > the fly (because a separate patch is much more complex than doing it right > > immediately). > > > > This

Re: [PATCH][RFC v4] ACPI throttling: Disable the MSR T-state if enabled after resumed

On Fri 2017-02-17 16:27:30, Chen Yu wrote: > Previously a bug was reported that on certain Broadwell > platform, after resumed from S3, the CPU is running at > an anomalously low speed, due to the BIOS has enabled the > MSR throttling across S3. The solution to this was to introduce > a quirk

Re: [PATCH][RFC v4] ACPI throttling: Disable the MSR T-state if enabled after resumed

On Fri 2017-02-17 16:27:30, Chen Yu wrote: > Previously a bug was reported that on certain Broadwell > platform, after resumed from S3, the CPU is running at > an anomalously low speed, due to the BIOS has enabled the > MSR throttling across S3. The solution to this was to introduce > a quirk

Re: kexec on panic

Hi Denys, On 02/10/2017 03:14 AM, Denys Fedoryshchenko wrote: > After years of using kexec and recent unpleasant experience with modern > (supposed to be blazing fast to boot) hardware that need 5-10 minutes just to > pass POST tests, > one question came up to me: > Is it possible anyhow to

Re: [PATCH v2 3/3] Make vmbus register arguments read-only

-memory-sections/20170218-141040 config: x86_64-rhel (attached as .config) compiler: gcc-6 (Debian 6.2.0-3) 6.2.0 20160901 reproduce: # save the attached .config to linux build tree make ARCH=x86_64 All errors (new ones prefixed by >>): >> ERROR: "kernel_ro_add

Re: kexec on panic

Hi Denys, On 02/10/2017 03:14 AM, Denys Fedoryshchenko wrote: > After years of using kexec and recent unpleasant experience with modern > (supposed to be blazing fast to boot) hardware that need 5-10 minutes just to > pass POST tests, > one question came up to me: > Is it possible anyhow to

Re: [PATCH v2 3/3] Make vmbus register arguments read-only

-memory-sections/20170218-141040 config: x86_64-rhel (attached as .config) compiler: gcc-6 (Debian 6.2.0-3) 6.2.0 20160901 reproduce: # save the attached .config to linux build tree make ARCH=x86_64 All errors (new ones prefixed by >>): >> ERROR: "kernel_ro_add

Re: v4.10-rc8 (-rc6) boot regression on Intel desktop, does not boot after cold boots, boots after reboot

On Thu 2017-02-16 12:21:13, Linus Torvalds wrote: > On Thu, Feb 16, 2017 at 12:06 PM, Pavel Machek wrote: > > > > Hmm, that would explain problems at boot _and_ problems during > > suspend/resume. > > I've committed the revert, and I'm just assuming that the revert also > fixed

Re: v4.10-rc8 (-rc6) boot regression on Intel desktop, does not boot after cold boots, boots after reboot

On Thu 2017-02-16 12:21:13, Linus Torvalds wrote: > On Thu, Feb 16, 2017 at 12:06 PM, Pavel Machek wrote: > > > > Hmm, that would explain problems at boot _and_ problems during > > suspend/resume. > > I've committed the revert, and I'm just assuming that the revert also > fixed your

[PATCH] irqchip/qcom: Fix error handling

'devm_ioremap()' returns NULL on error, not an error pointer. Fixes: f20cc9b00c7b ("irqchip/qcom: Add IRQ combiner driver") Signed-off-by: Christophe JAILLET --- drivers/irqchip/qcom-irq-combiner.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff

[PATCH] irqchip/qcom: Fix error handling

'devm_ioremap()' returns NULL on error, not an error pointer. Fixes: f20cc9b00c7b ("irqchip/qcom: Add IRQ combiner driver") Signed-off-by: Christophe JAILLET --- drivers/irqchip/qcom-irq-combiner.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git

[RESEND 2] [PATCH] rlimits: Print more information when limits are exceeded

This dumps some information in logs when a process exceeds its CPU or RT limits (soft and hard). Makes debugging easier when userspace triggers these limits. Signed-off-by: Arun Raghavan --- kernel/time/posix-cpu-timers.c | 11 ++- 1 file changed, 10

[RESEND 2] [PATCH] rlimits: Print more information when limits are exceeded

This dumps some information in logs when a process exceeds its CPU or RT limits (soft and hard). Makes debugging easier when userspace triggers these limits. Signed-off-by: Arun Raghavan --- kernel/time/posix-cpu-timers.c | 11 ++- 1 file changed, 10 insertions(+), 1 deletion(-) Hello,

[PATCH] soc: ti: knav_dma: Fix some error handling

'pktdma_get_regs()' never returns NULL. It returns an error pointer or a valid pointer. So test its return value with IS_ERR. Signed-off-by: Christophe JAILLET --- After checking with IS_ERR, it could be better to propagate the error code instead of returning

[PATCH] soc: ti: knav_dma: Fix some error handling

'pktdma_get_regs()' never returns NULL. It returns an error pointer or a valid pointer. So test its return value with IS_ERR. Signed-off-by: Christophe JAILLET --- After checking with IS_ERR, it could be better to propagate the error code instead of returning -ENODEV uncondionnaly ---

Re: [Letux-kernel] [PATCH v9 1/8] drivers:input:tsc2007: add new common binding names, pre-calibration, flipping and rotation

Hi Dmitry, On Fri, 17 Feb 2017 12:40:41 -0800 Dmitry Torokhov wrote: [...] > > Let me cite myself: > > > > >> This makes it possible to pre-calibrate the touch so that is > > >> (almost) > > Yes, it allows you to pre-calibrate, I get it. But you still do > properly

Re: [Letux-kernel] [PATCH v9 1/8] drivers:input:tsc2007: add new common binding names, pre-calibration, flipping and rotation

Hi Dmitry, On Fri, 17 Feb 2017 12:40:41 -0800 Dmitry Torokhov wrote: [...] > > Let me cite myself: > > > > >> This makes it possible to pre-calibrate the touch so that is > > >> (almost) > > Yes, it allows you to pre-calibrate, I get it. But you still do > properly calibrate later, right? So

Re: kexec on panic

On 2017-02-18 09:42, Jon Masters wrote: Hi Denys, On 02/10/2017 03:14 AM, Denys Fedoryshchenko wrote: After years of using kexec and recent unpleasant experience with modern (supposed to be blazing fast to boot) hardware that need 5-10 minutes just to pass POST tests, one question came up

Re: kexec on panic

On 2017-02-18 09:42, Jon Masters wrote: Hi Denys, On 02/10/2017 03:14 AM, Denys Fedoryshchenko wrote: After years of using kexec and recent unpleasant experience with modern (supposed to be blazing fast to boot) hardware that need 5-10 minutes just to pass POST tests, one question came up

<    1   2   3   4   5