[PATCH v2 8/8] arm64: dts: db820c: add support to external sd card.

This patch adds support to external sd card. Signed-off-by: Srinivas Kandagatla --- arch/arm64/boot/dts/qcom/apq8096-db820c-pins.dtsi | 39 +++ arch/arm64/boot/dts/qcom/apq8096-db820c.dtsi | 10 ++ 2 files changed, 49 insertions(+)

[PATCH v2 8/8] arm64: dts: db820c: add support to external sd card.

This patch adds support to external sd card. Signed-off-by: Srinivas Kandagatla --- arch/arm64/boot/dts/qcom/apq8096-db820c-pins.dtsi | 39 +++ arch/arm64/boot/dts/qcom/apq8096-db820c.dtsi | 10 ++ 2 files changed, 49 insertions(+) create mode 100644

Re: [PATCH v3 00/13] Virtually mapped stacks with guard pages (x86, core)

On Tue, Jun 21, 2016 at 2:24 AM, Arnd Bergmann wrote: > On Monday, June 20, 2016 4:43:30 PM CEST Andy Lutomirski wrote: >> >> On my laptop, this adds about 1.5µs of overhead to task creation, >> which seems to be mainly caused by vmalloc inefficiently allocating >> individual pages

Re: [PATCH v3 00/13] Virtually mapped stacks with guard pages (x86, core)

On Tue, Jun 21, 2016 at 2:24 AM, Arnd Bergmann wrote: > On Monday, June 20, 2016 4:43:30 PM CEST Andy Lutomirski wrote: >> >> On my laptop, this adds about 1.5µs of overhead to task creation, >> which seems to be mainly caused by vmalloc inefficiently allocating >> individual pages even when a

Re: [PART2 RFC v2 00/10] iommu/AMD: Introduce IOMMU AVIC support

On 6/21/2016 9:46 AM, Joerg Roedel wrote: On Tue, Jun 21, 2016 at 09:27:27AM -0500, Suthikulpanit, Suravee wrote: On 6/21/2016 8:50 AM, Joerg Roedel wrote: The code has a few style issues (thing I'd implemented differently), but it looks functional. Anything in particular that you think I

Re: [PART2 RFC v2 00/10] iommu/AMD: Introduce IOMMU AVIC support

On 6/21/2016 9:46 AM, Joerg Roedel wrote: On Tue, Jun 21, 2016 at 09:27:27AM -0500, Suthikulpanit, Suravee wrote: On 6/21/2016 8:50 AM, Joerg Roedel wrote: The code has a few style issues (thing I'd implemented differently), but it looks functional. Anything in particular that you think I

Re: [PATCH v4 0/5] /dev/random - a new approach

Am Dienstag, 21. Juni 2016, 13:18:33 schrieb Austin S. Hemmelgarn: Hi Austin, > > You have to trust the host for anything, not just for the entropy in > > timings. This is completely invalid argument unless you can present a > > method that one guest can manipulate timings in other guest in such

Re: [PATCH v4 0/5] /dev/random - a new approach

Am Dienstag, 21. Juni 2016, 13:18:33 schrieb Austin S. Hemmelgarn: Hi Austin, > > You have to trust the host for anything, not just for the entropy in > > timings. This is completely invalid argument unless you can present a > > method that one guest can manipulate timings in other guest in such

Re: [PATCH] memcg: css_alloc should return an ERR_PTR value on error

On Tue 21-06-16 12:57:40, Tejun Heo wrote: > mem_cgroup_css_alloc() was returning NULL on failure while cgroup core > expected it to return an ERR_PTR value leading to the following NULL > deref after a css allocation failure. Fix it by return > ERR_PTR(-ENOMEM) instead. I'll also update cgroup

Re: [PATCH] memcg: css_alloc should return an ERR_PTR value on error

On Tue 21-06-16 12:57:40, Tejun Heo wrote: > mem_cgroup_css_alloc() was returning NULL on failure while cgroup core > expected it to return an ERR_PTR value leading to the following NULL > deref after a css allocation failure. Fix it by return > ERR_PTR(-ENOMEM) instead. I'll also update cgroup

Re: [Qemu-ppc] [PATCH v2] powerpc/pseries: start rtasd before PCI probing

On Wed, 15 Jun 2016 22:26:41 +0200 Greg Kurz wrote: > A strange behaviour is observed when comparing PCI hotplug in QEMU, between > x86 and pseries. If you consider the following steps: > - start a VM > - add a PCI device via the QEMU monitor before the rtasd has

Re: [PATCH v4 3/8] iommu/rockchip: Fix allocation of bases array in driver probe

Hi, On Mon, Jun 20, 2016 at 9:34 PM, Tomasz Figa wrote: > From: Shunqian Zheng > > In .probe(), devm_kzalloc() is called with size == 0 and works only > by luck, due to internal behavior of the allocator and the fact > that the proper allocation size

Re: [Qemu-ppc] [PATCH v2] powerpc/pseries: start rtasd before PCI probing

On Wed, 15 Jun 2016 22:26:41 +0200 Greg Kurz wrote: > A strange behaviour is observed when comparing PCI hotplug in QEMU, between > x86 and pseries. If you consider the following steps: > - start a VM > - add a PCI device via the QEMU monitor before the rtasd has started (for > example

Re: [PATCH v4 3/8] iommu/rockchip: Fix allocation of bases array in driver probe

Hi, On Mon, Jun 20, 2016 at 9:34 PM, Tomasz Figa wrote: > From: Shunqian Zheng > > In .probe(), devm_kzalloc() is called with size == 0 and works only > by luck, due to internal behavior of the allocator and the fact > that the proper allocation size is small. Let's use proper value for >

Re: [PATCH 7/8] dmaengine: tegra20-apb-dma: Only calculate residue if txstate exists.

On 21/06/16 17:01, Vinod Koul wrote: > On Wed, Jun 08, 2016 at 09:51:57AM +0100, Jon Hunter wrote: >> Hi Peter, >> >> On 07/06/16 18:38, Peter Griffin wrote: >>> There is no point calculating the residue if there is >>> no txstate to store the value. >>> >>> Signed-off-by: Peter Griffin

Re: [alsa-devel] [very-RFC 0/8] TSN driver for the kernel

On 6/20/16 5:31 AM, Richard Cochran wrote: On Mon, Jun 20, 2016 at 02:18:38PM +0200, Richard Cochran wrote: Documentation/sound/alsa/timestamping.txt says: Examples of typestamping with HDaudio: 1. DMA timestamp, no compensation for DMA+analog delay $ ./audio_time -p --ts_type=1

Re: [PATCH 7/8] dmaengine: tegra20-apb-dma: Only calculate residue if txstate exists.

On 21/06/16 17:01, Vinod Koul wrote: > On Wed, Jun 08, 2016 at 09:51:57AM +0100, Jon Hunter wrote: >> Hi Peter, >> >> On 07/06/16 18:38, Peter Griffin wrote: >>> There is no point calculating the residue if there is >>> no txstate to store the value. >>> >>> Signed-off-by: Peter Griffin >>> ---

Re: [alsa-devel] [very-RFC 0/8] TSN driver for the kernel

On 6/20/16 5:31 AM, Richard Cochran wrote: On Mon, Jun 20, 2016 at 02:18:38PM +0200, Richard Cochran wrote: Documentation/sound/alsa/timestamping.txt says: Examples of typestamping with HDaudio: 1. DMA timestamp, no compensation for DMA+analog delay $ ./audio_time -p --ts_type=1

Re: [Y2038] [PATCH] crypto: use timespec64 for jent_get_nstime

Am Dienstag, 21. Juni 2016, 10:12:24 schrieb John Stultz: Hi John, > > So this is definitely more clear then what was described earlier, and > worries me because on many x86 machines (though fewer I guess these > days then in the past) the clocksource will often not be the TSC (and > have lower

Re: [PATCH v4 0/5] /dev/random - a new approach

On 2016-06-21 09:42, Pavel Machek wrote: Hi! 6. You have a significant lack of data regarding embedded systems, which is one of the two biggest segments of Linux's market share. You list no results for any pre-ARMv6 systems (Linux still runs on and is regularly used on ARMv4 CPU's, and it's

Re: [Y2038] [PATCH] crypto: use timespec64 for jent_get_nstime

Am Dienstag, 21. Juni 2016, 10:12:24 schrieb John Stultz: Hi John, > > So this is definitely more clear then what was described earlier, and > worries me because on many x86 machines (though fewer I guess these > days then in the past) the clocksource will often not be the TSC (and > have lower

Re: [PATCH v4 0/5] /dev/random - a new approach

On 2016-06-21 09:42, Pavel Machek wrote: Hi! 6. You have a significant lack of data regarding embedded systems, which is one of the two biggest segments of Linux's market share. You list no results for any pre-ARMv6 systems (Linux still runs on and is regularly used on ARMv4 CPU's, and it's

Re: [PATCH v3 00/13] Virtually mapped stacks with guard pages (x86, core)

On Tue, Jun 21, 2016 at 9:45 AM, Andy Lutomirski wrote: > > So I'm leaning toward fewer cache entries per cpu, maybe just one. > I'm all for making it a bit faster, but I think we should weigh that > against increasing memory usage too much and thus scaring away the >

Re: [PATCH v3 00/13] Virtually mapped stacks with guard pages (x86, core)

On Tue, Jun 21, 2016 at 9:45 AM, Andy Lutomirski wrote: > > So I'm leaning toward fewer cache entries per cpu, maybe just one. > I'm all for making it a bit faster, but I think we should weigh that > against increasing memory usage too much and thus scaring away the > embedded folks. I don't

Re: [PATCH v2 01/12] locking/atomic: Introduce inc/dec calls for FETCH-OP flavors

Sorry, I was also missing the _long variants. While at it I added a missing ATOMIC_LONG_FETCH_INC_DEC_OP undef. --8<- From: Davidlohr Bueso Subject: [PATCH -v3 01/12] locking/atomic: Introduce inc/dec calls for FETCH-OP flavors With

Re: [PATCH 0/6] Support DAX for device-mapper dm-linear devices

On Tue, 2016-06-21 at 09:45 -0700, Dan Williams wrote: > On Tue, Jun 21, 2016 at 9:35 AM, Kani, Toshimitsu > wrote: > > On Tue, 2016-06-21 at 09:25 -0700, Dan Williams wrote: > > > On Tue, Jun 21, 2016 at 8:44 AM, Kani, Toshimitsu > > > wrote: > > > >  :

Re: [PATCH v2 01/12] locking/atomic: Introduce inc/dec calls for FETCH-OP flavors

Sorry, I was also missing the _long variants. While at it I added a missing ATOMIC_LONG_FETCH_INC_DEC_OP undef. --8<- From: Davidlohr Bueso Subject: [PATCH -v3 01/12] locking/atomic: Introduce inc/dec calls for FETCH-OP flavors With the inclusion of

Re: [PATCH 0/6] Support DAX for device-mapper dm-linear devices

On Tue, 2016-06-21 at 09:45 -0700, Dan Williams wrote: > On Tue, Jun 21, 2016 at 9:35 AM, Kani, Toshimitsu > wrote: > > On Tue, 2016-06-21 at 09:25 -0700, Dan Williams wrote: > > > On Tue, Jun 21, 2016 at 8:44 AM, Kani, Toshimitsu > > > wrote: > > > >  : > > > > I think GENHD_FL_DAX is more

Re: [Y2038] [PATCH] crypto: use timespec64 for jent_get_nstime

On Tue, Jun 21, 2016 at 9:51 AM, Stephan Mueller wrote: > Am Dienstag, 21. Juni 2016, 09:47:23 schrieb John Stultz: > > Hi John, > >> On Tue, Jun 21, 2016 at 9:34 AM, Stephan Mueller > wrote: >> > Am Dienstag, 21. Juni 2016, 09:22:31 schrieb John Stultz:

Re: [Y2038] [PATCH] crypto: use timespec64 for jent_get_nstime

On Tue, Jun 21, 2016 at 9:51 AM, Stephan Mueller wrote: > Am Dienstag, 21. Juni 2016, 09:47:23 schrieb John Stultz: > > Hi John, > >> On Tue, Jun 21, 2016 at 9:34 AM, Stephan Mueller > wrote: >> > Am Dienstag, 21. Juni 2016, 09:22:31 schrieb John Stultz: >> > >> > Hi John, >> > >> >> On Tue, Jun

Re: [PATCH v3 06/13] fork: Add generic vmalloced stack support

On Tue, Jun 21, 2016 at 9:59 AM, Andy Lutomirski wrote: > On Tue, Jun 21, 2016 at 12:30 AM, Jann Horn wrote: >> On Tue, Jun 21, 2016 at 1:43 AM, Andy Lutomirski wrote: >>> If CONFIG_VMAP_STACK is selected, kernel stacks are allocated with

Re: [PATCH v3 06/13] fork: Add generic vmalloced stack support

On Tue, Jun 21, 2016 at 9:59 AM, Andy Lutomirski wrote: > On Tue, Jun 21, 2016 at 12:30 AM, Jann Horn wrote: >> On Tue, Jun 21, 2016 at 1:43 AM, Andy Lutomirski wrote: >>> If CONFIG_VMAP_STACK is selected, kernel stacks are allocated with >>> vmalloc_node. >> [...] >>> static struct

[PATCH 1/2] ARM: Make PCI I/O space optional

For callers of pci_common_init_dev(), we previously always required a PCI I/O port resource. If the caller's ->setup() function had added an I/O resource, we used that; otherwise, we added a default 64K I/O port space for it. There are PCI host bridges that do not support I/O port space, and we

[PATCH 1/2] ARM: Make PCI I/O space optional

For callers of pci_common_init_dev(), we previously always required a PCI I/O port resource. If the caller's ->setup() function had added an I/O resource, we used that; otherwise, we added a default 64K I/O port space for it. There are PCI host bridges that do not support I/O port space, and we

Re: [PATCH v3] cgroup: Add pids controller event when fork fails because of pid limit

Hello, Just a couple nits. On Tue, Jun 21, 2016 at 09:56:38AM -0700, Kenny Yu wrote: > Summary: No need for "Summary:" tag. > This patch adds more visibility into the pids controller when the controller > rejects a fork request. Whenever fork fails because the limit on the number of > pids in

Re: [PATCH v10 2/2] dmaengine: Add Xilinx zynqmp dma engine driver support

On Tue, Jun 21, 2016 at 04:19:38PM +, Punnaiah Choudary Kalluri wrote: > > > > > > > mode Earlier In the driver this configuration is read from the > > > > > > > device-tree But as per lars and your suggestion moved it as > > > > > > > runtime > > config > > > > parameters. > > > > > > > > >

Re: [PATCH v3] cgroup: Add pids controller event when fork fails because of pid limit

Hello, Just a couple nits. On Tue, Jun 21, 2016 at 09:56:38AM -0700, Kenny Yu wrote: > Summary: No need for "Summary:" tag. > This patch adds more visibility into the pids controller when the controller > rejects a fork request. Whenever fork fails because the limit on the number of > pids in

Re: [PATCH v10 2/2] dmaengine: Add Xilinx zynqmp dma engine driver support

On Tue, Jun 21, 2016 at 04:19:38PM +, Punnaiah Choudary Kalluri wrote: > > > > > > > mode Earlier In the driver this configuration is read from the > > > > > > > device-tree But as per lars and your suggestion moved it as > > > > > > > runtime > > config > > > > parameters. > > > > > > > > >

[PATCH 2/2] PCI: rcar: Drop gen2 dummy I/O port region

Previously we added a dummy I/O port region even though the R-Car controller doesn't support PCI port I/O. This resulted in bogus root bus resources like this: pci_bus :00: root bus resource [io 0xee08-0xee0810ff] pci_bus :00: root bus resource [mem 0xee08-0xee0810ff] Drop

[PATCH 2/2] PCI: rcar: Drop gen2 dummy I/O port region

Previously we added a dummy I/O port region even though the R-Car controller doesn't support PCI port I/O. This resulted in bogus root bus resources like this: pci_bus :00: root bus resource [io 0xee08-0xee0810ff] pci_bus :00: root bus resource [mem 0xee08-0xee0810ff] Drop

[GIT PULL] ARM: at91: dt for 4.8 #2

Arnd, Olof, Kevin, This is the device tree for a new board (well, from 2006). I don't expect to send you much more this cycle unless we get an agreement on the TCB driver rework. The following changes since commit 64c0703e269d442f0406b34e64e23744151ea276: ARM: dts: at91: calao: remove

[GIT PULL] ARM: at91: dt for 4.8 #2

Arnd, Olof, Kevin, This is the device tree for a new board (well, from 2006). I don't expect to send you much more this cycle unless we get an agreement on the TCB driver rework. The following changes since commit 64c0703e269d442f0406b34e64e23744151ea276: ARM: dts: at91: calao: remove

[PATCH cgroup/for-4.8] cgroup: allow NULL return from ss->css_alloc()

cgroup core expected css_alloc to return an ERR_PTR value on failure and caused NULL deref if it returned NULL. It's an easy mistake to make from an alloc function and there's no ambiguity in what's being indicated. Update css_create() so that it interprets NULL return from css_alloc as -ENOMEM.

[PATCH cgroup/for-4.8] cgroup: allow NULL return from ss->css_alloc()

cgroup core expected css_alloc to return an ERR_PTR value on failure and caused NULL deref if it returned NULL. It's an easy mistake to make from an alloc function and there's no ambiguity in what's being indicated. Update css_create() so that it interprets NULL return from css_alloc as -ENOMEM.

Re: [PATCH] coresight: always use stashed trace id value in etm4_trace_id

On 20 June 2016 at 08:25, Sudeep Holla wrote: > etm4_trace_id is not guaranteed to be executed on the CPU whose ETM is > being accessed. This leads to exception similar to below one if the > CPU whose ETM is being accessed is in deeper idle states. So it must > be executed

Re: [PATCH] coresight: always use stashed trace id value in etm4_trace_id

On 20 June 2016 at 08:25, Sudeep Holla wrote: > etm4_trace_id is not guaranteed to be executed on the CPU whose ETM is > being accessed. This leads to exception similar to below one if the > CPU whose ETM is being accessed is in deeper idle states. So it must > be executed on the CPU whose ETM is

[GIT PULL] ARM: at91: soc for 4.8 #2

Arnd, Olof, Kevin, Here are more compilation warning fixes and the final documentation for the sama5d2 that we forgot about. The following changes since commit 8b2f2d0356184cc7c409b2f046c550ce00ca8f70: ARM: at91: debug: add default DEBUG_LL addresses (2016-06-10 17:09:28 +0200) are available

[GIT PULL] ARM: at91: soc for 4.8 #2

Arnd, Olof, Kevin, Here are more compilation warning fixes and the final documentation for the sama5d2 that we forgot about. The following changes since commit 8b2f2d0356184cc7c409b2f046c550ce00ca8f70: ARM: at91: debug: add default DEBUG_LL addresses (2016-06-10 17:09:28 +0200) are available

Re: linux-next: Tree for Jun 21

On Tue, Jun 21, 2016 at 11:26:19AM -0400, Chris Metcalf wrote: > On 6/21/2016 10:14 AM, Peter Zijlstra wrote: > >On Tue, Jun 21, 2016 at 04:04:08PM +0200, Peter Zijlstra wrote: > >>>I'm not sure who builds the toolchains, but tilepro is in upstream > >>>gcc/binutils/etc > >>>so should be easy

Re: linux-next: Tree for Jun 21

On Tue, Jun 21, 2016 at 11:26:19AM -0400, Chris Metcalf wrote: > On 6/21/2016 10:14 AM, Peter Zijlstra wrote: > >On Tue, Jun 21, 2016 at 04:04:08PM +0200, Peter Zijlstra wrote: > >>>I'm not sure who builds the toolchains, but tilepro is in upstream > >>>gcc/binutils/etc > >>>so should be easy

[PATCH] static_key: fix concurrent static_key_slow_inc

The following scenario is possible: CPU 1 CPU 2 static_key_slow_inc atomic_inc_not_zero -> key.enabled == 0, no increment jump_label_lock atomic_inc_return -> key.enabled == 1 now

perf cc/perf bpf was: Re: [PATCH 2/2] perf record: Add --dry-run option to check cmdline options

Em Tue, Jun 21, 2016 at 02:12:38PM +0800, Wangnan (F) escreveu: > On 2016/6/21 0:22, Alexei Starovoitov wrote: > > On Mon, Jun 20, 2016 at 11:38:18AM -0300, Arnaldo Carvalho de Melo wrote: > > > Em Mon, Jun 20, 2016 at 11:29:13AM +0800, Wangnan (F) escreveu: > > > > On 2016/6/17 0:48, Arnaldo

perf cc/perf bpf was: Re: [PATCH 2/2] perf record: Add --dry-run option to check cmdline options

Em Tue, Jun 21, 2016 at 02:12:38PM +0800, Wangnan (F) escreveu: > On 2016/6/21 0:22, Alexei Starovoitov wrote: > > On Mon, Jun 20, 2016 at 11:38:18AM -0300, Arnaldo Carvalho de Melo wrote: > > > Em Mon, Jun 20, 2016 at 11:29:13AM +0800, Wangnan (F) escreveu: > > > > On 2016/6/17 0:48, Arnaldo

[PATCH] static_key: fix concurrent static_key_slow_inc

The following scenario is possible: CPU 1 CPU 2 static_key_slow_inc atomic_inc_not_zero -> key.enabled == 0, no increment jump_label_lock atomic_inc_return -> key.enabled == 1 now

Re: [PATCH] sparc64: Swap registers for fault code and address in mna trap

Hisashi Kanda wrote: > In fact, BUG() in do_sparc64_fault occurred in modified version > of linux-2.6.25.8 on SPARC64VIIIfx. I'm misunderstanding that > the same problem remains in the latest. Fujitsu K computer, with SPARC64 VIIIfx, runs a heavily modified 2.6.25.8 kernel. And maybe also

Re: [PATCH] sparc64: Swap registers for fault code and address in mna trap

Hisashi Kanda wrote: > In fact, BUG() in do_sparc64_fault occurred in modified version > of linux-2.6.25.8 on SPARC64VIIIfx. I'm misunderstanding that > the same problem remains in the latest. Fujitsu K computer, with SPARC64 VIIIfx, runs a heavily modified 2.6.25.8 kernel. And maybe also

[GIT PULL] ARM: at91: drivers for 4.8 #2

Arnd, Olof, Kevin, Here are two simple fixes for our memory drivers. The following changes since commit 1fdab21d1d52a85c31f932844242fec5fb81daac: memory: atmel-ebi: add DT bindings documentation (2016-06-02 08:32:25 +0200) are available in the git repository at:

[PATCH v3 0/4] Fixes for HPD

This is a revised version of the patchset: https://lists.freedesktop.org/archives/intel-gfx/2016-June/098787.html This patchset is intended to fix the issue of not having HPD when we're in runtime suspend, or on Valleyview/Cherryview systems when we don't have any power wells enabled. While this

[PATCH v3 1/4] drm/i915/vlv: Make intel_crt_reset() per-encoder

This lets call intel_crt_reset() in contexts where IRQs are disabled and as such, can't hold the locks required to work with the connectors. Cc: sta...@vger.kernel.org Cc: Ville Syrjälä Acked-by: Daniel Vetter Signed-off-by: Lyude

Re: linux-next: Tree for Jun 21

On 6/21/2016 10:14 AM, Peter Zijlstra wrote: On Tue, Jun 21, 2016 at 04:04:08PM +0200, Peter Zijlstra wrote: I'm not sure who builds the toolchains, but tilepro is in upstream gcc/binutils/etc so should be easy enough to include. There's also a cross-toolchain for x64 I put up a while ago

[PATCH v3 2/4] drm/i915/vlv: Reset the ADPA in vlv_display_power_well_init()

While VGA hotplugging worked(ish) before, it looks like that was mainly because we'd unintentionally enable it in valleyview_crt_detect_hotplug() when we did a force trigger. This doesn't work reliably enough because whenever the display powerwell on vlv gets disabled, the values set in VLV_ADPA

[GIT PULL] ARM: at91: drivers for 4.8 #2

Arnd, Olof, Kevin, Here are two simple fixes for our memory drivers. The following changes since commit 1fdab21d1d52a85c31f932844242fec5fb81daac: memory: atmel-ebi: add DT bindings documentation (2016-06-02 08:32:25 +0200) are available in the git repository at:

[PATCH v3 0/4] Fixes for HPD

This is a revised version of the patchset: https://lists.freedesktop.org/archives/intel-gfx/2016-June/098787.html This patchset is intended to fix the issue of not having HPD when we're in runtime suspend, or on Valleyview/Cherryview systems when we don't have any power wells enabled. While this

[PATCH v3 1/4] drm/i915/vlv: Make intel_crt_reset() per-encoder

This lets call intel_crt_reset() in contexts where IRQs are disabled and as such, can't hold the locks required to work with the connectors. Cc: sta...@vger.kernel.org Cc: Ville Syrjälä Acked-by: Daniel Vetter Signed-off-by: Lyude --- drivers/gpu/drm/i915/intel_crt.c | 10 +- 1 file

Re: linux-next: Tree for Jun 21

On 6/21/2016 10:14 AM, Peter Zijlstra wrote: On Tue, Jun 21, 2016 at 04:04:08PM +0200, Peter Zijlstra wrote: I'm not sure who builds the toolchains, but tilepro is in upstream gcc/binutils/etc so should be easy enough to include. There's also a cross-toolchain for x64 I put up a while ago

[PATCH v3 2/4] drm/i915/vlv: Reset the ADPA in vlv_display_power_well_init()

While VGA hotplugging worked(ish) before, it looks like that was mainly because we'd unintentionally enable it in valleyview_crt_detect_hotplug() when we did a force trigger. This doesn't work reliably enough because whenever the display powerwell on vlv gets disabled, the values set in VLV_ADPA

Re: [PATCH v2 06/13] fork: Add generic vmalloced stack support

On Tue, Jun 21, 2016 at 1:46 AM, Michal Hocko wrote: > On Mon 20-06-16 09:13:55, Andy Lutomirski wrote: >> On Mon, Jun 20, 2016 at 6:36 AM, Michal Hocko wrote: >> > On Fri 17-06-16 13:00:42, Andy Lutomirski wrote: >> >> If CONFIG_VMAP_STACK is selected,

Re: [RFC PATCH 2/2] xfs: map KM_MAYFAIL to __GFP_RETRY_HARD

On Tue 21-06-16 00:22:49, Johannes Weiner wrote: [...] > As for changing the default - remember that we currently warn about > allocation failures as if they were bugs, unless they are explicitely > allocated with the __GFP_NOWARN flag. We can assume that the current > __GFP_NOWARN sites are 1)

[PATCH v3 4/4] drm/i915: Enable polling when we don't have hpd

Unfortunately, there's two situations where we lose hpd right now: - Runtime suspend - When we've shut off all of the power wells on Valleyview/Cherryview While it would be nice if this didn't cause issues, this has the ability to get us in some awkward states where a user won't be able to get

Re: cmpxchg and x86 flags output

On June 21, 2016 2:06:20 AM PDT, David Howells wrote: >H. Peter Anvin wrote: > >> Well, that sounds promising. I wonder how David's model, using >> intrinsics (do we have enough intrinsics to actually be able to do >this >> "correctly"?), compare to using

Re: [PATCH v2 06/13] fork: Add generic vmalloced stack support

On Tue, Jun 21, 2016 at 1:46 AM, Michal Hocko wrote: > On Mon 20-06-16 09:13:55, Andy Lutomirski wrote: >> On Mon, Jun 20, 2016 at 6:36 AM, Michal Hocko wrote: >> > On Fri 17-06-16 13:00:42, Andy Lutomirski wrote: >> >> If CONFIG_VMAP_STACK is selected, kernel stacks are allocated with >> >>

Re: [RFC PATCH 2/2] xfs: map KM_MAYFAIL to __GFP_RETRY_HARD

On Tue 21-06-16 00:22:49, Johannes Weiner wrote: [...] > As for changing the default - remember that we currently warn about > allocation failures as if they were bugs, unless they are explicitely > allocated with the __GFP_NOWARN flag. We can assume that the current > __GFP_NOWARN sites are 1)

[PATCH v3 4/4] drm/i915: Enable polling when we don't have hpd

Unfortunately, there's two situations where we lose hpd right now: - Runtime suspend - When we've shut off all of the power wells on Valleyview/Cherryview While it would be nice if this didn't cause issues, this has the ability to get us in some awkward states where a user won't be able to get

Re: cmpxchg and x86 flags output

On June 21, 2016 2:06:20 AM PDT, David Howells wrote: >H. Peter Anvin wrote: > >> Well, that sounds promising. I wonder how David's model, using >> intrinsics (do we have enough intrinsics to actually be able to do >this >> "correctly"?), compare to using the flags output from assembly. >

[PATCH 0/2] ARM/PCI: Make I/O port space optional

Currently we always require an I/O port resource for PCI host bridges. Even if the bridge doesn't actually support I/O port space, we add a default I/O resource for it. These patches make I/O port space optional on ARM. Comments welcome. If these look OK, I'll fold them into the series at [1],

[PATCH 0/2] ARM/PCI: Make I/O port space optional

Currently we always require an I/O port resource for PCI host bridges. Even if the bridge doesn't actually support I/O port space, we add a default I/O resource for it. These patches make I/O port space optional on ARM. Comments welcome. If these look OK, I'll fold them into the series at [1],

[PATCH v3 3/4] drm/i915/vlv: Disable HPD in valleyview_crt_detect_hotplug()

One of the things preventing us from using polling is the fact that calling valleyview_crt_detect_hotplug() when there's a VGA cable connected results in sending another hotplug. With polling enabled when HPD is disabled, this results in a scenario like this: - We enable power wells and reset the

Re: [PATCH v3 06/13] fork: Add generic vmalloced stack support

On Tue, Jun 21, 2016 at 12:30 AM, Jann Horn wrote: > On Tue, Jun 21, 2016 at 1:43 AM, Andy Lutomirski wrote: >> If CONFIG_VMAP_STACK is selected, kernel stacks are allocated with >> vmalloc_node. > [...] >> static struct thread_info

[PATCH v3 3/4] drm/i915/vlv: Disable HPD in valleyview_crt_detect_hotplug()

One of the things preventing us from using polling is the fact that calling valleyview_crt_detect_hotplug() when there's a VGA cable connected results in sending another hotplug. With polling enabled when HPD is disabled, this results in a scenario like this: - We enable power wells and reset the

Re: [PATCH v3 06/13] fork: Add generic vmalloced stack support

On Tue, Jun 21, 2016 at 12:30 AM, Jann Horn wrote: > On Tue, Jun 21, 2016 at 1:43 AM, Andy Lutomirski wrote: >> If CONFIG_VMAP_STACK is selected, kernel stacks are allocated with >> vmalloc_node. > [...] >> static struct thread_info *alloc_thread_info_node(struct task_struct *tsk, >>

[PATCH v3] cgroup: Add pids controller event when fork fails because of pid limit

Summary: This patch adds more visibility into the pids controller when the controller rejects a fork request. Whenever fork fails because the limit on the number of pids in the cgroup is reached, the controller will log this and also notify the newly added cgroups events file. The `max` key in the

[PATCH v3] cgroup: Add pids controller event when fork fails because of pid limit

Summary: This patch adds more visibility into the pids controller when the controller rejects a fork request. Whenever fork fails because the limit on the number of pids in the cgroup is reached, the controller will log this and also notify the newly added cgroups events file. The `max` key in the

[PATCH] memcg: css_alloc should return an ERR_PTR value on error

mem_cgroup_css_alloc() was returning NULL on failure while cgroup core expected it to return an ERR_PTR value leading to the following NULL deref after a css allocation failure. Fix it by return ERR_PTR(-ENOMEM) instead. I'll also update cgroup core so that it can handle NULL returns. mkdir:

[PATCH] memcg: css_alloc should return an ERR_PTR value on error

mem_cgroup_css_alloc() was returning NULL on failure while cgroup core expected it to return an ERR_PTR value leading to the following NULL deref after a css allocation failure. Fix it by return ERR_PTR(-ENOMEM) instead. I'll also update cgroup core so that it can handle NULL returns. mkdir:

Re: [PATCH] driver core: fix race between creating/querying glue dir and its cleanup

Hi Ming/Chandrasekhar, Chandra Sekhar Lingutla codeaurora.org> writes: > > Hi Ming, > > [...] > > +static inline bool live_in_glue_dir(struct kobject *kobj, > > + struct device *dev) > > +{ > > + if (!kobj || !dev->class || > > + kobj->kset !=

Re: [PATCH] driver core: fix race between creating/querying glue dir and its cleanup

Hi Ming/Chandrasekhar, Chandra Sekhar Lingutla codeaurora.org> writes: > > Hi Ming, > > [...] > > +static inline bool live_in_glue_dir(struct kobject *kobj, > > + struct device *dev) > > +{ > > + if (!kobj || !dev->class || > > + kobj->kset !=

Re: [PATCH 0/6] Support DAX for device-mapper dm-linear devices

On Tue, 2016-06-21 at 09:25 -0700, Dan Williams wrote: > On Tue, Jun 21, 2016 at 8:44 AM, Kani, Toshimitsu > wrote: > > > > On Tue, 2016-06-21 at 09:41 -0400, Mike Snitzer wrote: > > > > > > On Mon, Jun 20 2016 at  6:22pm -0400, > > > Mike Snitzer wrote:

Re: [PATCH 0/6] Support DAX for device-mapper dm-linear devices

On Tue, 2016-06-21 at 09:25 -0700, Dan Williams wrote: > On Tue, Jun 21, 2016 at 8:44 AM, Kani, Toshimitsu > wrote: > > > > On Tue, 2016-06-21 at 09:41 -0400, Mike Snitzer wrote: > > > > > > On Mon, Jun 20 2016 at  6:22pm -0400, > > > Mike Snitzer wrote: > > > > > > > > On Mon, Jun 20 2016 at 

Re: [Y2038] [PATCH] crypto: use timespec64 for jent_get_nstime

Am Dienstag, 21. Juni 2016, 09:47:23 schrieb John Stultz: Hi John, > On Tue, Jun 21, 2016 at 9:34 AM, Stephan Mueller wrote: > > Am Dienstag, 21. Juni 2016, 09:22:31 schrieb John Stultz: > > > > Hi John, > > > >> On Tue, Jun 21, 2016 at 1:32 AM, Arnd Bergmann

Re: [Y2038] [PATCH] crypto: use timespec64 for jent_get_nstime

Am Dienstag, 21. Juni 2016, 09:47:23 schrieb John Stultz: Hi John, > On Tue, Jun 21, 2016 at 9:34 AM, Stephan Mueller wrote: > > Am Dienstag, 21. Juni 2016, 09:22:31 schrieb John Stultz: > > > > Hi John, > > > >> On Tue, Jun 21, 2016 at 1:32 AM, Arnd Bergmann wrote: > >> > On Tuesday, June

Re: [PATCH v1 19/25] PCI: rcar Gen2: Request host bridge window resources

On Tue, Jun 21, 2016 at 06:41:00PM +0300, Valentine Barshak wrote: > On Tue, Jun 21, 2016 at 09:26:23AM -0500, Bjorn Helgaas wrote: > > [+cc Valentine] > > > > Hi Bjorn, > > > Hi Geert, > > > > Thanks a lot for testing this, and sorry for the breakage. > > > > On Tue, Jun 21, 2016 at

Re: [PATCH v1 19/25] PCI: rcar Gen2: Request host bridge window resources

On Tue, Jun 21, 2016 at 06:41:00PM +0300, Valentine Barshak wrote: > On Tue, Jun 21, 2016 at 09:26:23AM -0500, Bjorn Helgaas wrote: > > [+cc Valentine] > > > > Hi Bjorn, > > > Hi Geert, > > > > Thanks a lot for testing this, and sorry for the breakage. > > > > On Tue, Jun 21, 2016 at

Re: [PATCH v6 2/3] x86/mm: Implement ASLR for kernel memory sections (x86_64)

On Fri, Jun 17, 2016 at 3:26 AM, Ingo Molnar wrote: > > * Kees Cook wrote: > >> --- a/arch/x86/Kconfig >> +++ b/arch/x86/Kconfig >> @@ -1993,6 +1993,23 @@ config PHYSICAL_ALIGN >> >> Don't change this unless you know what you are doing. >> >>

Re: [PATCH v6 2/3] x86/mm: Implement ASLR for kernel memory sections (x86_64)

On Fri, Jun 17, 2016 at 3:26 AM, Ingo Molnar wrote: > > * Kees Cook wrote: > >> --- a/arch/x86/Kconfig >> +++ b/arch/x86/Kconfig >> @@ -1993,6 +1993,23 @@ config PHYSICAL_ALIGN >> >> Don't change this unless you know what you are doing. >> >> +config RANDOMIZE_MEMORY >> + bool

Re: [PATCH 0/6] Support DAX for device-mapper dm-linear devices

On Tue, Jun 21, 2016 at 9:35 AM, Kani, Toshimitsu wrote: > On Tue, 2016-06-21 at 09:25 -0700, Dan Williams wrote: >> On Tue, Jun 21, 2016 at 8:44 AM, Kani, Toshimitsu >> wrote: >> > >> > On Tue, 2016-06-21 at 09:41 -0400, Mike Snitzer wrote: >> > > >> > >

Re: [PATCH v11 08/14] usb: otg: add OTG/dual-role core

On Tue, Jun 21, 2016 at 01:02:59PM +0300, Felipe Balbi wrote: > > Hi, > > Peter Chen writes: > >> >> So far, I haven't seen anybody talking about real USB OTG (the spec) > >> >> when they say OTG. Usually they just mean "a method for swapping between > >> >> host and

Re: [PATCH v11 08/14] usb: otg: add OTG/dual-role core

On Tue, Jun 21, 2016 at 01:02:59PM +0300, Felipe Balbi wrote: > > Hi, > > Peter Chen writes: > >> >> So far, I haven't seen anybody talking about real USB OTG (the spec) > >> >> when they say OTG. Usually they just mean "a method for swapping between > >> >> host and peripheral roles, but we

Re: [PATCH 0/6] Support DAX for device-mapper dm-linear devices

On Tue, Jun 21, 2016 at 9:35 AM, Kani, Toshimitsu wrote: > On Tue, 2016-06-21 at 09:25 -0700, Dan Williams wrote: >> On Tue, Jun 21, 2016 at 8:44 AM, Kani, Toshimitsu >> wrote: >> > >> > On Tue, 2016-06-21 at 09:41 -0400, Mike Snitzer wrote: >> > > >> > > On Mon, Jun 20 2016 at 6:22pm -0400, >>

[PATCH] proc: proc_tty.c should include internal.h

The proc_tty_init() is defined in proc_tty.c, but has no declaration as the file does not include internal.h where the declaration is. Fix the following sparse error by including internal.h: linux/fs/proc/proc_tty.c:175:13: warning: symbol 'proc_tty_init' was not declared. Should it be static?

[PATCH] proc: proc_tty.c should include internal.h

The proc_tty_init() is defined in proc_tty.c, but has no declaration as the file does not include internal.h where the declaration is. Fix the following sparse error by including internal.h: linux/fs/proc/proc_tty.c:175:13: warning: symbol 'proc_tty_init' was not declared. Should it be static?

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