Re: [PATCH v2 0/6] Add support of inverting power control and some minor cleanup

On 2016/8/9 9:49, Shawn Lin wrote: Hi, On 2016/8/8 18:24, Jaehoon Chung wrote: Hi Shawn, On 08/07/2016 10:33 AM, Shawn Lin wrote: By default, dw_mmc outputs high level voltage to indicate powering up the card and outputs low level vcltage to indicate powering off the card. But that is not

Re: [PATCH v2 0/6] Add support of inverting power control and some minor cleanup

On 2016/8/9 9:49, Shawn Lin wrote: Hi, On 2016/8/8 18:24, Jaehoon Chung wrote: Hi Shawn, On 08/07/2016 10:33 AM, Shawn Lin wrote: By default, dw_mmc outputs high level voltage to indicate powering up the card and outputs low level vcltage to indicate powering off the card. But that is not

Re: [PATCH] powerpc: vdso: Add missing include file

On 08/08/2016 06:46 PM, Michael Ellerman wrote: Guenter Roeck writes: Some powerpc builds fail with the following buld error. Is that a randconfig? No, it is a configuration I use for qemu testing.

Re: [PATCH] powerpc: vdso: Add missing include file

On 08/08/2016 06:46 PM, Michael Ellerman wrote: Guenter Roeck writes: Some powerpc builds fail with the following buld error. Is that a randconfig? No, it is a configuration I use for qemu testing.

Re: [PATCH] megaraid_sas: Fix probing cards without io port

> "Yinghai" == Yinghai Lu writes: > Found one megaraid_sas HBA probe fails, > > [ 187.235190] scsi host2: Avago SAS based MegaRAID driver > [ 191.112365] megaraid_sas :89:00.0: BAR 0: can't reserve [io > 0x-0x00ff] > [ 191.120548] megaraid_sas :89:00.0:

Re: [PATCH] megaraid_sas: Fix probing cards without io port

> "Yinghai" == Yinghai Lu writes: > Found one megaraid_sas HBA probe fails, > > [ 187.235190] scsi host2: Avago SAS based MegaRAID driver > [ 191.112365] megaraid_sas :89:00.0: BAR 0: can't reserve [io > 0x-0x00ff] > [ 191.120548] megaraid_sas :89:00.0: IO memory region

Re: [PATCH] mpt3sas: Fix resume on WarpDrive flash cards

> "Greg" == Greg Edwards writes: Greg> mpt3sas crashes on resume after suspend with WarpDrive flash Greg> cards. The reply_post_host_index array is not set back up after Greg> the resume, and we deference a stale pointer in _base_interrupt(). Chaitra, Suganath? --

Re: [PATCH] mpt3sas: Fix resume on WarpDrive flash cards

> "Greg" == Greg Edwards writes: Greg> mpt3sas crashes on resume after suspend with WarpDrive flash Greg> cards. The reply_post_host_index array is not set back up after Greg> the resume, and we deference a stale pointer in _base_interrupt(). Chaitra, Suganath? -- Martin K. Petersen

Re: [PATCH v2 0/6] Add support of inverting power control and some minor cleanup

Hi, On 2016/8/8 18:24, Jaehoon Chung wrote: Hi Shawn, On 08/07/2016 10:33 AM, Shawn Lin wrote: By default, dw_mmc outputs high level voltage to indicate powering up the card and outputs low level vcltage to indicate powering off the card. But that is not always correct. The power io should be

Re: [PATCH v2 0/6] Add support of inverting power control and some minor cleanup

Hi, On 2016/8/8 18:24, Jaehoon Chung wrote: Hi Shawn, On 08/07/2016 10:33 AM, Shawn Lin wrote: By default, dw_mmc outputs high level voltage to indicate powering up the card and outputs low level vcltage to indicate powering off the card. But that is not always correct. The power io should be

Re: [PATCH] powerpc: vdso: Add missing include file

Guenter Roeck writes: > Some powerpc builds fail with the following buld error. Is that a randconfig? All my builds are green. Thanks for the patch anyway. cheers

Re: [PATCH] powerpc: vdso: Add missing include file

Guenter Roeck writes: > Some powerpc builds fail with the following buld error. Is that a randconfig? All my builds are green. Thanks for the patch anyway. cheers

Re: [PATCH 00/11] ARM: dts: NSP: define SATA, Reboot, RAM and new device tree files

On 08/03/2016 11:38 AM, Jon Mason wrote: > This patch series adds SATA and RAM for the existing HR and XMC device > tree files (as they were missed when those peices were originally > added). It also adds GPIO rebooting to the platforms that support that > feature. Finally, add device tree files

Re: [PATCH 00/11] ARM: dts: NSP: define SATA, Reboot, RAM and new device tree files

On 08/03/2016 11:38 AM, Jon Mason wrote: > This patch series adds SATA and RAM for the existing HR and XMC device > tree files (as they were missed when those peices were originally > added). It also adds GPIO rebooting to the platforms that support that > feature. Finally, add device tree files

Re: [lkp] [fs] 45ec18d5c7: BUG: KASAN: user-memory-access on address 00007f90291c7ec0

On Tue, Aug 09, 2016 at 09:17:58AM +0800, Ye Xiaolong wrote: > On 08/08, valdis.kletni...@vt.edu wrote: > >On Sun, 07 Aug 2016 22:02:42 +0800, kernel test robot said: > > > >> FYI, we noticed the following commit: > >> > >> https://github.com/0day-ci/linux > >>

Re: [lkp] [fs] 45ec18d5c7: BUG: KASAN: user-memory-access on address 00007f90291c7ec0

On Tue, Aug 09, 2016 at 09:17:58AM +0800, Ye Xiaolong wrote: > On 08/08, valdis.kletni...@vt.edu wrote: > >On Sun, 07 Aug 2016 22:02:42 +0800, kernel test robot said: > > > >> FYI, we noticed the following commit: > >> > >> https://github.com/0day-ci/linux > >>

Re: [PATCH] mpt3sas: Don't spam logs if logging level is 0

> "Johannes" == Johannes Thumshirn writes: Johannes> In _scsih_io_done() we test if the ioc->logging_level does Johannes> _not_ have the MPT_DEBUG_REPLY bit set and if it hasn't we Johannes> print the debug messages. This unfortunately is the wrong way Johannes> around.

Re: [PATCH] mpt3sas: Don't spam logs if logging level is 0

> "Johannes" == Johannes Thumshirn writes: Johannes> In _scsih_io_done() we test if the ioc->logging_level does Johannes> _not_ have the MPT_DEBUG_REPLY bit set and if it hasn't we Johannes> print the debug messages. This unfortunately is the wrong way Johannes> around. Applied to

Re: [PATCH] clk: Hi6220: enable stub clock driver for ARCH_HISI

On Mon, Aug 08, 2016 at 09:36:32PM +0100, Daniel Thompson wrote: [...] > >My earlier patch focused on enabling the stub driver in the case the > >thermal driver was enabled (and subsequently turning on HISI_THERMAL > >in defconfig). The EAS profiling usecase to prevent thermal-throttling > >from

Re: [PATCH] clk: Hi6220: enable stub clock driver for ARCH_HISI

On Mon, Aug 08, 2016 at 09:36:32PM +0100, Daniel Thompson wrote: [...] > >My earlier patch focused on enabling the stub driver in the case the > >thermal driver was enabled (and subsequently turning on HISI_THERMAL > >in defconfig). The EAS profiling usecase to prevent thermal-throttling > >from

Re: [lkp] [fs] 45ec18d5c7: BUG: KASAN: user-memory-access on address 00007f90291c7ec0

On 08/08, valdis.kletni...@vt.edu wrote: >On Sun, 07 Aug 2016 22:02:42 +0800, kernel test robot said: > >> FYI, we noticed the following commit: >> >> https://github.com/0day-ci/linux >>

Re: [lkp] [fs] 45ec18d5c7: BUG: KASAN: user-memory-access on address 00007f90291c7ec0

On 08/08, valdis.kletni...@vt.edu wrote: >On Sun, 07 Aug 2016 22:02:42 +0800, kernel test robot said: > >> FYI, we noticed the following commit: >> >> https://github.com/0day-ci/linux >>

Re: [RFC PATCH 0/9][V3] Overlayfs SELinux Support

On Thu, Jul 21, 2016 at 5:16 PM, Paul Moore wrote: > On Wed, Jul 13, 2016 at 10:44 AM, Vivek Goyal wrote: >> Hi All, >> >> Please find attached the V3 of patches. Changes since V2 are as follows. >> >> - Fixed the build issue with CONFIG_SECURITY=n. >> >>

Re: [RFC PATCH 0/9][V3] Overlayfs SELinux Support

On Thu, Jul 21, 2016 at 5:16 PM, Paul Moore wrote: > On Wed, Jul 13, 2016 at 10:44 AM, Vivek Goyal wrote: >> Hi All, >> >> Please find attached the V3 of patches. Changes since V2 are as follows. >> >> - Fixed the build issue with CONFIG_SECURITY=n. >> >> - Dan Walsh was writing more tests for

Re: [PATCH 3/3] mpt3sas: Fix warnings exposed by W=1

> "Calvin" == Calvin Owens writes: Calvin> Trivial non-functional changes for a couple annoying things: 1) Calvin> Functions local to files are not declared static, which is Calvin> frustrating when reading the code because it's non-obvious at Calvin> first glance what's

Re: [PATCH 3/3] mpt3sas: Fix warnings exposed by W=1

> "Calvin" == Calvin Owens writes: Calvin> Trivial non-functional changes for a couple annoying things: 1) Calvin> Functions local to files are not declared static, which is Calvin> frustrating when reading the code because it's non-obvious at Calvin> first glance what's actually called from

Re: [PATCH] device probe: add self triggered delayed work request

On 8/8/2016 6:11 PM, Frank Rowand wrote: On 08/08/16 14:51, Qing Huang wrote: On 08/08/2016 01:44 PM, Frank Rowand wrote: On 07/29/16 22:39, Qing Huang wrote: In normal condition, the device probe requests kept in deferred queue would only be triggered for re-probing when another new

Re: [PATCH] device probe: add self triggered delayed work request

On 8/8/2016 6:11 PM, Frank Rowand wrote: On 08/08/16 14:51, Qing Huang wrote: On 08/08/2016 01:44 PM, Frank Rowand wrote: On 07/29/16 22:39, Qing Huang wrote: In normal condition, the device probe requests kept in deferred queue would only be triggered for re-probing when another new

Re: [PATCH 2/3] mpt3sas: Eliminate dead sleep_flag code

> "Calvin" == Calvin Owens writes: Calvin> With the exception of a single call to wait_for_doorbell_int(), Calvin> all this conditional sleeping code is dead. So delete it. Applied to 4.9/scsi-queue. -- Martin K. Petersen Oracle Linux Engineering

Re: [PATCH 2/3] mpt3sas: Eliminate dead sleep_flag code

> "Calvin" == Calvin Owens writes: Calvin> With the exception of a single call to wait_for_doorbell_int(), Calvin> all this conditional sleeping code is dead. So delete it. Applied to 4.9/scsi-queue. -- Martin K. Petersen Oracle Linux Engineering

Re: [PATCH 1/3] mpt3sas: Eliminate conditional locking in mpt3sas_scsih_issue_tm()

> "Calvin" == Calvin Owens writes: Calvin> This flag that conditionally acquires the mutex is confusing and Calvin> prone to bugginess: refactor it into two separate function Calvin> calls, and make the unlocked one complain if it's called outside Calvin> the mutex.

Re: [PATCH 1/3] mpt3sas: Eliminate conditional locking in mpt3sas_scsih_issue_tm()

> "Calvin" == Calvin Owens writes: Calvin> This flag that conditionally acquires the mutex is confusing and Calvin> prone to bugginess: refactor it into two separate function Calvin> calls, and make the unlocked one complain if it's called outside Calvin> the mutex. Applied to

Re: [PATCH] device probe: add self triggered delayed work request

On 08/08/16 14:51, Qing Huang wrote: > > > On 08/08/2016 01:44 PM, Frank Rowand wrote: >> On 07/29/16 22:39, Qing Huang wrote: >>> In normal condition, the device probe requests kept in deferred >>> queue would only be triggered for re-probing when another new device >>> probe is finished

Re: [PATCH] device probe: add self triggered delayed work request

On 08/08/16 14:51, Qing Huang wrote: > > > On 08/08/2016 01:44 PM, Frank Rowand wrote: >> On 07/29/16 22:39, Qing Huang wrote: >>> In normal condition, the device probe requests kept in deferred >>> queue would only be triggered for re-probing when another new device >>> probe is finished

Re: [PATCH] mpt3sas: Ensure the connector_name string is NUL-terminated

> "Calvin" == Calvin Owens writes: Calvin> We blindly trust the hardware to give us NUL-terminated strings, Calvin> which is a bad idea because it doesn't always do that. For Calvin> example: Calvin> [ 481.184784] mpt3sas_cm0: enclosure level(0x), connector Calvin>

Re: [PATCH] mpt3sas: Ensure the connector_name string is NUL-terminated

> "Calvin" == Calvin Owens writes: Calvin> We blindly trust the hardware to give us NUL-terminated strings, Calvin> which is a bad idea because it doesn't always do that. For Calvin> example: Calvin> [ 481.184784] mpt3sas_cm0: enclosure level(0x), connector Calvin> name( \x3) Calvin>

[GIT PULL] gcc-plugin-infrastructure updates for v4.8-rc2

The following changes since commit 574673c231a5fad1560249cc3a598907acb36cf9: printk: Remove unnecessary #ifdef CONFIG_PRINTK (2016-08-08 11:29:39 -0700) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/kees/linux.git

[GIT PULL] gcc-plugin-infrastructure updates for v4.8-rc2

The following changes since commit 574673c231a5fad1560249cc3a598907acb36cf9: printk: Remove unnecessary #ifdef CONFIG_PRINTK (2016-08-08 11:29:39 -0700) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/kees/linux.git

RE: [PATCH v2 08/22] usb: chipidea: Remove locking in ci_udc_start()

>Quoting Peter Chen (2016-08-06 00:54:35) >> On Fri, Aug 05, 2016 at 02:53:56PM -0700, Stephen Boyd wrote: >> > Quoting Peter Chen (2016-07-08 02:45:28) >> > > On Thu, Jul 07, 2016 at 03:20:59PM -0700, Stephen Boyd wrote: >> > > > We don't call hw_device_reset() with the ci->lock held, so it >> >

RE: [PATCH v2 08/22] usb: chipidea: Remove locking in ci_udc_start()

>Quoting Peter Chen (2016-08-06 00:54:35) >> On Fri, Aug 05, 2016 at 02:53:56PM -0700, Stephen Boyd wrote: >> > Quoting Peter Chen (2016-07-08 02:45:28) >> > > On Thu, Jul 07, 2016 at 03:20:59PM -0700, Stephen Boyd wrote: >> > > > We don't call hw_device_reset() with the ci->lock held, so it >> >

Re: [PATCH v2 0/3] Fix seccomp for UM (next)

On Mon, 1 Aug 2016, Mickaël Salaün wrote: > Hi, > > This series fix the recent seccomp update for the User-mode Linux architecture > (32-bit and 64-bit) since commit 26703c636c1f ("um/ptrace: run seccomp after > ptrace") which close the hole where ptrace can change a syscall out from under >

Re: [PATCH v2 0/3] Fix seccomp for UM (next)

On Mon, 1 Aug 2016, Mickaël Salaün wrote: > Hi, > > This series fix the recent seccomp update for the User-mode Linux architecture > (32-bit and 64-bit) since commit 26703c636c1f ("um/ptrace: run seccomp after > ptrace") which close the hole where ptrace can change a syscall out from under >

Re: [RFC][PATCH 4/4 v2] arm64: dts: hikey: Add pstore support for HiKey

On Mon, Aug 8, 2016 at 4:48 PM, John Stultz wrote: > This patch reserves some memory in the DTS and sets up a > pstore device tree node to enable pstore support on HiKey. > > Cc: Kees Cook > Cc: Guodong Xu > Cc: Haojian

Re: [RFC][PATCH 4/4 v2] arm64: dts: hikey: Add pstore support for HiKey

On Mon, Aug 8, 2016 at 4:48 PM, John Stultz wrote: > This patch reserves some memory in the DTS and sets up a > pstore device tree node to enable pstore support on HiKey. > > Cc: Kees Cook > Cc: Guodong Xu > Cc: Haojian Zhuang > Cc: Wei Xu > Cc: Rob Herring > Cc: Mark Rutland > Cc: Catalin

[PATCHv4] arm64: Handle el1 synchronous instruction aborts cleanly

Executing from a non-executable area gives an ugly message: lkdtm: Performing direct entry EXEC_RODATA lkdtm: attempting ok execution at 084c0e08 lkdtm: attempting bad execution at 08880700 Bad mode in Synchronous Abort handler detected on CPU2, code 0x840e -- IABT (current

[PATCHv4] arm64: Handle el1 synchronous instruction aborts cleanly

Executing from a non-executable area gives an ugly message: lkdtm: Performing direct entry EXEC_RODATA lkdtm: attempting ok execution at 084c0e08 lkdtm: attempting bad execution at 08880700 Bad mode in Synchronous Abort handler detected on CPU2, code 0x840e -- IABT (current

Kernel panic - Fails to load BIOS-E820 memory map booted through iPXE, uses BIOS-88

<<< How does booting through iPXE disrupt the BIOS E820 map? >>> Booting 4.6.4 from the Arch 2016.08.01 ISO on a DVD properly sees 64GB. (See quote 1.) Booting the same ISO through iPXE only sees about 50*M*B usable, and the detected memory map sections are reported as "BIOS-88" rather than

Kernel panic - Fails to load BIOS-E820 memory map booted through iPXE, uses BIOS-88

<<< How does booting through iPXE disrupt the BIOS E820 map? >>> Booting 4.6.4 from the Arch 2016.08.01 ISO on a DVD properly sees 64GB. (See quote 1.) Booting the same ISO through iPXE only sees about 50*M*B usable, and the detected memory map sections are reported as "BIOS-88" rather than

[PATCH v2 1/2] ACPI/tables: Correct the wrong count increasing

The current code always increases the count in the 1st element of array proc[]. Signed-off-by: Baoquan He Cc: Rafael J. Wysocki Cc: Len Brown Cc: linux-a...@vger.kernel.org --- v1->v2: V1 is a wrong post because I didn't update the

[PATCH v2 1/2] ACPI/tables: Correct the wrong count increasing

The current code always increases the count in the 1st element of array proc[]. Signed-off-by: Baoquan He Cc: Rafael J. Wysocki Cc: Len Brown Cc: linux-a...@vger.kernel.org --- v1->v2: V1 is a wrong post because I didn't update the tested code to my local laptop. Repost with a correct

Re: [PATCH 1/2] ACPI/tables: Correct the wrong count increasing

Sorry, I tested in another system, but forget updating code on my laptop. Will reply with a v2 post. Sorry again about this mistake.

Re: [PATCH 1/2] ACPI/tables: Correct the wrong count increasing

Sorry, I tested in another system, but forget updating code on my laptop. Will reply with a v2 post. Sorry again about this mistake.

Re: [PATCH] ASoC: simple-card: fix module load "unknown symbol" issue

Hi Sekhar > > An ASoC driver using simple-card, when built as a module gets the > > following error at module load time: > > > > [ 23.571873] simple_card_utils: Unknown symbol snd_soc_of_parse_daifmt > > (err 0) > > [ 23.712726] simple_card_utils: Unknown symbol snd_soc_of_parse_card_name

Re: [PATCH] ASoC: simple-card: fix module load "unknown symbol" issue

Hi Sekhar > > An ASoC driver using simple-card, when built as a module gets the > > following error at module load time: > > > > [ 23.571873] simple_card_utils: Unknown symbol snd_soc_of_parse_daifmt > > (err 0) > > [ 23.712726] simple_card_utils: Unknown symbol snd_soc_of_parse_card_name

Re: [PATCH v5 2/6] power: add power sequence library

El Mon, Aug 08, 2016 at 04:52:07PM +0800 Peter Chen ha dit: > We have an well-known problem that the device needs to do some power > sequence before it can be recognized by related host, the typical > example like hard-wired mmc devices and usb devices. > > This power sequence is hard to be

Re: [PATCH v5 2/6] power: add power sequence library

El Mon, Aug 08, 2016 at 04:52:07PM +0800 Peter Chen ha dit: > We have an well-known problem that the device needs to do some power > sequence before it can be recognized by related host, the typical > example like hard-wired mmc devices and usb devices. > > This power sequence is hard to be

Re: [RFC 0/4] RFC: Add Checmate, BPF-driven minor LSM

On Mon, Aug 8, 2016 at 5:00 PM, Sargun Dhillon wrote: > On Mon, Aug 08, 2016 at 04:44:02PM -0700, Kees Cook wrote: >> On Thu, Aug 4, 2016 at 12:11 AM, Sargun Dhillon wrote: >> > I distributed this patchset to linux-security-mod...@vger.kernel.org >> >

Re: [RFC 0/4] RFC: Add Checmate, BPF-driven minor LSM

On Mon, Aug 8, 2016 at 5:00 PM, Sargun Dhillon wrote: > On Mon, Aug 08, 2016 at 04:44:02PM -0700, Kees Cook wrote: >> On Thu, Aug 4, 2016 at 12:11 AM, Sargun Dhillon wrote: >> > I distributed this patchset to linux-security-mod...@vger.kernel.org >> > earlier, >> > but based on the fact that

[PATCH v2] iio: fix sched WARNING "do not call blocking ops when !TASK_RUNNING"

When using CONFIG_DEBUG_ATOMIC_SLEEP, the scheduler nicely points out that we're calling sleeping primitives within the wait_event loop, which means we might clobber the task state: [ 10.831289] do not call blocking ops when !TASK_RUNNING; state=1 set at [] [ 10.845531] [ cut

[PATCH v2] iio: fix sched WARNING "do not call blocking ops when !TASK_RUNNING"

When using CONFIG_DEBUG_ATOMIC_SLEEP, the scheduler nicely points out that we're calling sleeping primitives within the wait_event loop, which means we might clobber the task state: [ 10.831289] do not call blocking ops when !TASK_RUNNING; state=1 set at [] [ 10.845531] [ cut

linux-next: stats (Was: Linux 4.8-rc1)

Hi all, As usual, the executive friendly graph is at http://neuling.org/linux-next-size.html :-) (No merge commits counted, next-20160725 was the first linux-next after the merge window opened.) Commits in v4.8-rc1 (relative to v4.7):11618 Commits in next-20160725:

linux-next: stats (Was: Linux 4.8-rc1)

Hi all, As usual, the executive friendly graph is at http://neuling.org/linux-next-size.html :-) (No merge commits counted, next-20160725 was the first linux-next after the merge window opened.) Commits in v4.8-rc1 (relative to v4.7):11618 Commits in next-20160725:

[PATCH 0/7 v4] K3DMA fixes for HiKey HDMI audio

Here's another go at the k3dma fixes and cyclic mode patches needed to support audio on HiKey. New in v4: * Reworked patch set so fixes are applied first before features Let me know if there is any feedback or objections! thanks -john Cc: Zhangfei Gao Cc: Jingoo Han

[PATCH 0/7 v4] K3DMA fixes for HiKey HDMI audio

Here's another go at the k3dma fixes and cyclic mode patches needed to support audio on HiKey. New in v4: * Reworked patch set so fixes are applied first before features Let me know if there is any feedback or objections! thanks -john Cc: Zhangfei Gao Cc: Jingoo Han Cc: Krzysztof Kozlowski

[PATCH 5/7] k3dma: Fix occasional DMA ERR issue by using proper dma api

After lots of debugging on an occasional DMA ERR issue, I realized that the desc structures which we point the dma hardware are being allocated out of regular memory. This means when we fill the desc structures, that data doesn't always get flushed out to memory by the time we start the dma

[PATCH 6/7] k3dma: Fix memory handling in preparation for cyclic mode

With cyclic mode, the shared virt-dma logic doesn't actually manage the descriptor state, nor the calling of the descriptor free callback. This results in leaking a desc structure every time we start an audio transfer. Thus we must manage it ourselves. The k3dma driver already keeps track of the

[PATCH 4/7] k3dma: Fix "nobody cared" message seen on any error

From: Andy Green As it was before, as soon as the DMAC IP felt there was an error he would return IRQ_NONE since no actual transfer had completed. After spinning on that for 100K interrupts, Linux yanks the IRQ with a "nobody cared" error. This patch lets it handle the

[PATCH 1/7] Kconfig: Allow k3dma driver to be selected for more then HISI3xx platforms

This allows the k3dma driver to be selected on HiKey via the ARCH_HISI dependency. Cc: Zhangfei Gao Cc: Jingoo Han Cc: Krzysztof Kozlowski Cc: Maxime Ripard Cc: Vinod Koul

[PATCH 5/7] k3dma: Fix occasional DMA ERR issue by using proper dma api

After lots of debugging on an occasional DMA ERR issue, I realized that the desc structures which we point the dma hardware are being allocated out of regular memory. This means when we fill the desc structures, that data doesn't always get flushed out to memory by the time we start the dma

[PATCH 6/7] k3dma: Fix memory handling in preparation for cyclic mode

With cyclic mode, the shared virt-dma logic doesn't actually manage the descriptor state, nor the calling of the descriptor free callback. This results in leaking a desc structure every time we start an audio transfer. Thus we must manage it ourselves. The k3dma driver already keeps track of the

[PATCH 4/7] k3dma: Fix "nobody cared" message seen on any error

From: Andy Green As it was before, as soon as the DMAC IP felt there was an error he would return IRQ_NONE since no actual transfer had completed. After spinning on that for 100K interrupts, Linux yanks the IRQ with a "nobody cared" error. This patch lets it handle the interrupt and keep the

[PATCH 1/7] Kconfig: Allow k3dma driver to be selected for more then HISI3xx platforms

This allows the k3dma driver to be selected on HiKey via the ARCH_HISI dependency. Cc: Zhangfei Gao Cc: Jingoo Han Cc: Krzysztof Kozlowski Cc: Maxime Ripard Cc: Vinod Koul Cc: Dan Williams Cc: Mark Brown Cc: Andy Green Signed-off-by: John Stultz --- v2: * Use ARCH_HISI and COMPILE_TEST

[PATCH 2/7] k3dma: Fix hisi burst clipping

From: Andy Green Max burst len is a 4-bit field, but at the moment it's clipped with a 5-bit constant... reduce it to that which can be expressed Cc: Zhangfei Gao Cc: Jingoo Han Cc: Krzysztof Kozlowski

[PATCH] drm/cirrus: Fix NULL pointer dereference when registering the fbdev

cirrus_modeset_init() is initializing/registering the emulated fbdev and, since commit c61b93fe51b1 ("drm/atomic: Fix remaining places where !funcs->best_encoder is valid"), DRM internals can access/test some of the fields in mode_config->funcs as part of the fbdev registration process. Make sure

[PATCH 7/7] k3dma: Add cyclic mode for audio

From: Andy Green Currently the k3dma driver doesn't offer the cyclic mode necessary for handling audio. This patch adds it. Cc: Zhangfei Gao Cc: Jingoo Han Cc: Krzysztof Kozlowski Cc: Maxime Ripard

[PATCH 2/7] k3dma: Fix hisi burst clipping

From: Andy Green Max burst len is a 4-bit field, but at the moment it's clipped with a 5-bit constant... reduce it to that which can be expressed Cc: Zhangfei Gao Cc: Jingoo Han Cc: Krzysztof Kozlowski Cc: Maxime Ripard Cc: Vinod Koul Cc: Dan Williams Cc: Mark Brown Cc: Andy Green

[PATCH] drm/cirrus: Fix NULL pointer dereference when registering the fbdev

cirrus_modeset_init() is initializing/registering the emulated fbdev and, since commit c61b93fe51b1 ("drm/atomic: Fix remaining places where !funcs->best_encoder is valid"), DRM internals can access/test some of the fields in mode_config->funcs as part of the fbdev registration process. Make sure

[PATCH 7/7] k3dma: Add cyclic mode for audio

From: Andy Green Currently the k3dma driver doesn't offer the cyclic mode necessary for handling audio. This patch adds it. Cc: Zhangfei Gao Cc: Jingoo Han Cc: Krzysztof Kozlowski Cc: Maxime Ripard Cc: Vinod Koul Cc: Dan Williams Cc: Mark Brown Cc: Andy Green Acked-by: Zhangfei Gao

[PATCH 3/7] k3dma: Fix dma err offsets

From: Andy Green The offsets for ERR1 and ERR2 are wrong actually. That's why you can never clear an error. Cc: Zhangfei Gao Cc: Jingoo Han Cc: Krzysztof Kozlowski Cc: Maxime Ripard

[PATCH 3/7] k3dma: Fix dma err offsets

From: Andy Green The offsets for ERR1 and ERR2 are wrong actually. That's why you can never clear an error. Cc: Zhangfei Gao Cc: Jingoo Han Cc: Krzysztof Kozlowski Cc: Maxime Ripard Cc: Vinod Koul Cc: Dan Williams Cc: Mark Brown Cc: Andy Green Acked-by: Zhangfei Gao Signed-off-by: Andy

Re: [PATCH] device probe: add self triggered delayed work request

On 08/08/2016 03:42 AM, Shamir Rabinovitch wrote: Hi Qing, I suspect there is potential dead-lock with this patch: cpu0cpu1 driver_deferred_probe_add deferred_probe_work_func ...

Re: [PATCH] device probe: add self triggered delayed work request

On 08/08/2016 03:42 AM, Shamir Rabinovitch wrote: Hi Qing, I suspect there is potential dead-lock with this patch: cpu0cpu1 driver_deferred_probe_add deferred_probe_work_func ...

Re: [Patch v3 08/11] driver/edac/fsl_ddr: Add support of little endian

On 08/08/2016 01:50 AM, Borislav Petkov wrote: > On Thu, Aug 04, 2016 at 03:58:33PM -0700, York Sun wrote: >> Get endianness from device tree. Both big endian and little endian >> are supported. Default to big endian for backward compatibility to >> MPC85xx. >> >> Signed-off-by: York Sun

Re: [Patch v3 08/11] driver/edac/fsl_ddr: Add support of little endian

On 08/08/2016 01:50 AM, Borislav Petkov wrote: > On Thu, Aug 04, 2016 at 03:58:33PM -0700, York Sun wrote: >> Get endianness from device tree. Both big endian and little endian >> are supported. Default to big endian for backward compatibility to >> MPC85xx. >> >> Signed-off-by: York Sun >> >>

Re: [RFC 0/4] RFC: Add Checmate, BPF-driven minor LSM

On Mon, Aug 08, 2016 at 04:44:02PM -0700, Kees Cook wrote: > On Thu, Aug 4, 2016 at 12:11 AM, Sargun Dhillon wrote: > > I distributed this patchset to linux-security-mod...@vger.kernel.org > > earlier, > > but based on the fact that the archive is down, and this is a fairly > >

Re: [RFC 0/4] RFC: Add Checmate, BPF-driven minor LSM

On Mon, Aug 08, 2016 at 04:44:02PM -0700, Kees Cook wrote: > On Thu, Aug 4, 2016 at 12:11 AM, Sargun Dhillon wrote: > > I distributed this patchset to linux-security-mod...@vger.kernel.org > > earlier, > > but based on the fact that the archive is down, and this is a fairly > > broad-sweeping

Re: linux-next: build failure after merge of Linus' tree

Hi Doug, On Mon, 8 Aug 2016 19:30:57 -0400 Doug Ledford wrote: > > Doh! My apologies, that would certainly explain it. I'll reset my > for-next tag. Thanks. -- Cheers, Stephen Rothwell

Re: linux-next: build failure after merge of Linus' tree

Hi Doug, On Mon, 8 Aug 2016 19:30:57 -0400 Doug Ledford wrote: > > Doh! My apologies, that would certainly explain it. I'll reset my > for-next tag. Thanks. -- Cheers, Stephen Rothwell

linux-next: please clean up the samsung-krzk tree

Hi Krzysztof, The samsung-krzk tree (git://git.kernel.org/pub/scm/linux/kernel/git/krzk/linux.git#for-next) contains just these: 253256f64294 Merge branch 'next/soc' into for-next b148ebe425aa Merge branch 'next/defconfig64' into for-next d11d19d93a01 Merge branch 'next/defconfig64' into

linux-next: please clean up the samsung-krzk tree

Hi Krzysztof, The samsung-krzk tree (git://git.kernel.org/pub/scm/linux/kernel/git/krzk/linux.git#for-next) contains just these: 253256f64294 Merge branch 'next/soc' into for-next b148ebe425aa Merge branch 'next/defconfig64' into for-next d11d19d93a01 Merge branch 'next/defconfig64' into

Re: [Letux-kernel] [BUG] 4.8-rc1: wlcore: NULL pointer dereference in wlcore_op_get_expected_throughput

On Mon, Aug 08, 2016 at 11:26:38PM +0200, H. Nikolaus Schaller wrote: > Here is what I see in 4.8-rc1 on Pyra device after typing "poweroff". > I hope someone knows what it means. > > BR and thanks, > Nikolaus > > root@letux:~# poweroff > > Broadcast message from root@letux (pts/0) (Mon Aug 8

Re: [Letux-kernel] [BUG] 4.8-rc1: wlcore: NULL pointer dereference in wlcore_op_get_expected_throughput

On Mon, Aug 08, 2016 at 11:26:38PM +0200, H. Nikolaus Schaller wrote: > Here is what I see in 4.8-rc1 on Pyra device after typing "poweroff". > I hope someone knows what it means. > > BR and thanks, > Nikolaus > > root@letux:~# poweroff > > Broadcast message from root@letux (pts/0) (Mon Aug 8

[RFC][PATCH 4/4 v2] arm64: dts: hikey: Add pstore support for HiKey

This patch reserves some memory in the DTS and sets up a pstore device tree node to enable pstore support on HiKey. Cc: Kees Cook Cc: Guodong Xu Cc: Haojian Zhuang Cc: Wei Xu Cc: Rob Herring

[RFC][PATCH 4/4 v2] arm64: dts: hikey: Add pstore support for HiKey

This patch reserves some memory in the DTS and sets up a pstore device tree node to enable pstore support on HiKey. Cc: Kees Cook Cc: Guodong Xu Cc: Haojian Zhuang Cc: Wei Xu Cc: Rob Herring Cc: Mark Rutland Cc: Catalin Marinas Cc: Will Deacon Cc: linux-arm-ker...@lists.infradead.org Cc:

[PATCH v2] exynos-drm: Fix unsupported GEM memory type error message to be clear

Fix unsupported GEM memory type error message to include the memory type information. Signed-off-by: Shuah Khan --- Changes since v1: -- Comment changed to read clearly drivers/gpu/drm/exynos/exynos_drm_fb.c | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-)

Re: [GIT PULL] gcc-plugins update for v4.8-rc1

On Mon, Aug 8, 2016 at 4:18 PM, Kees Cook wrote: > > In theory, this tree is the plugin support tree (now that the core > infrastructure landed by way of the kbuild tree). Perhaps I'm > misunderstanding the segregation of responsibilities on this, though. So at this point,

[PATCH v2] exynos-drm: Fix unsupported GEM memory type error message to be clear

Fix unsupported GEM memory type error message to include the memory type information. Signed-off-by: Shuah Khan --- Changes since v1: -- Comment changed to read clearly drivers/gpu/drm/exynos/exynos_drm_fb.c | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git

Re: [GIT PULL] gcc-plugins update for v4.8-rc1

On Mon, Aug 8, 2016 at 4:18 PM, Kees Cook wrote: > > In theory, this tree is the plugin support tree (now that the core > infrastructure landed by way of the kbuild tree). Perhaps I'm > misunderstanding the segregation of responsibilities on this, though. So at this point, I'd rather not mix in

Re: [RFC 0/4] RFC: Add Checmate, BPF-driven minor LSM

On Thu, Aug 4, 2016 at 12:11 AM, Sargun Dhillon wrote: > I distributed this patchset to linux-security-mod...@vger.kernel.org earlier, > but based on the fact that the archive is down, and this is a fairly > broad-sweeping proposal, I figured I'd grow the audience a little bit.

Re: [RFC 0/4] RFC: Add Checmate, BPF-driven minor LSM

On Thu, Aug 4, 2016 at 12:11 AM, Sargun Dhillon wrote: > I distributed this patchset to linux-security-mod...@vger.kernel.org earlier, > but based on the fact that the archive is down, and this is a fairly > broad-sweeping proposal, I figured I'd grow the audience a little bit. Sorry > if you

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