Re: [PATCH v3 07/12] KVM: arm/arm64: Adapt vgic_v3_check_base to multiple rdist regions

On Fri, Apr 13, 2018 at 10:20:53AM +0200, Eric Auger wrote: > We introduce a new helper to check there is no overlap between > dist region (if set) and registered rdist regions. This both > handles the case of legacy single rdist region (implicitly sized > with the number of online vcpus) and the

Re: [PATCH v3 07/12] KVM: arm/arm64: Adapt vgic_v3_check_base to multiple rdist regions

On Fri, Apr 13, 2018 at 10:20:53AM +0200, Eric Auger wrote: > We introduce a new helper to check there is no overlap between > dist region (if set) and registered rdist regions. This both > handles the case of legacy single rdist region (implicitly sized > with the number of online vcpus) and the

Re: [PATCH v3 10/12] KVM: arm/arm64: Add KVM_VGIC_V3_ADDR_TYPE_REDIST_REGION

On Fri, Apr 13, 2018 at 10:20:56AM +0200, Eric Auger wrote: > This new attribute allows the userspace to set the base address > of a reditributor region, relaxing the constraint of having all > consecutive redistibutor frames contiguous. > > Signed-off-by: Eric Auger > --- >

Re: [PATCH v3 09/12] KVM: arm/arm64: Check all vcpu redistributors are set on map_resources

On Fri, Apr 13, 2018 at 10:20:55AM +0200, Eric Auger wrote: > On vcpu first run, we eventually know the actual number of vcpus. > This is a synchronization point to check all redistributors regions > were assigned. Isn't it the other way around? We want to check that all redistributors (one for

Re: [PATCH v3 08/12] KVM: arm/arm64: Check vcpu redist base before registering an iodev

On Fri, Apr 13, 2018 at 10:20:54AM +0200, Eric Auger wrote: > As we are going to register several redist regions, > vgic_register_all_redist_iodevs() may be called several times. We need > to register a redist_iodev for a given vcpu only once. Wouldn't it be more natural to change that caller to

Re: [PATCH v3 08/12] KVM: arm/arm64: Check vcpu redist base before registering an iodev

On Fri, Apr 13, 2018 at 10:20:54AM +0200, Eric Auger wrote: > As we are going to register several redist regions, > vgic_register_all_redist_iodevs() may be called several times. We need > to register a redist_iodev for a given vcpu only once. Wouldn't it be more natural to change that caller to

Re: [patch v2] mm, oom: fix concurrent munlock and oom reaperunmap

On Tue, 24 Apr 2018, Michal Hocko wrote: > > > > My patch has passed intensive testing on both x86 and powerpc, so I'll > > > > ask > > > > that it's pushed for 4.17-rc3. Many thanks to Tetsuo for the > > > > suggestion > > > > on calling __oom_reap_task_mm() from exit_mmap(). > > > > > >

Re: [patch v2] mm, oom: fix concurrent munlock and oom reaperunmap

On Tue, 24 Apr 2018, Michal Hocko wrote: > > > > My patch has passed intensive testing on both x86 and powerpc, so I'll > > > > ask > > > > that it's pushed for 4.17-rc3. Many thanks to Tetsuo for the > > > > suggestion > > > > on calling __oom_reap_task_mm() from exit_mmap(). > > > > > >

Re: [PATCH v3 04/12] KVM: arm/arm64: Helper to locate free rdist index

On Fri, Apr 13, 2018 at 10:20:50AM +0200, Eric Auger wrote: > We introduce vgic_v3_rdist_free_slot to help identifying > where we can place a new 2x64KB redistributor. > > Signed-off-by: Eric Auger > --- > virt/kvm/arm/vgic/vgic-mmio-v3.c | 3 +-- >

Re: [PATCH v3 04/12] KVM: arm/arm64: Helper to locate free rdist index

On Fri, Apr 13, 2018 at 10:20:50AM +0200, Eric Auger wrote: > We introduce vgic_v3_rdist_free_slot to help identifying > where we can place a new 2x64KB redistributor. > > Signed-off-by: Eric Auger > --- > virt/kvm/arm/vgic/vgic-mmio-v3.c | 3 +-- > virt/kvm/arm/vgic/vgic-v3.c | 17

Re: [PATCH v3 05/12] KVM: arm/arm64: Revisit Redistributor TYPER last bit computation

On Fri, Apr 13, 2018 at 10:20:51AM +0200, Eric Auger wrote: > The TYPER of an redistributor reflects whether the rdist is > the last one of the redistributor region. Let's compare the TYPER > GPA against the address of the last occupied slot within the > redistributor region. > > Signed-off-by:

Re: [PATCH v3 05/12] KVM: arm/arm64: Revisit Redistributor TYPER last bit computation

On Fri, Apr 13, 2018 at 10:20:51AM +0200, Eric Auger wrote: > The TYPER of an redistributor reflects whether the rdist is > the last one of the redistributor region. Let's compare the TYPER > GPA against the address of the last occupied slot within the > redistributor region. > > Signed-off-by:

Re: [PATCH v3 03/12] KVM: arm/arm64: Replace the single rdist region by a list

On Fri, Apr 13, 2018 at 10:20:49AM +0200, Eric Auger wrote: > At the moment KVM supports a single rdist region. We want to > support several separate rdist regions so let's introduce a list > of them. This patch currently only cares about a single > entry in this list as the functionality to

Re: [PATCH v3 03/12] KVM: arm/arm64: Replace the single rdist region by a list

On Fri, Apr 13, 2018 at 10:20:49AM +0200, Eric Auger wrote: > At the moment KVM supports a single rdist region. We want to > support several separate rdist regions so let's introduce a list > of them. This patch currently only cares about a single > entry in this list as the functionality to

Re: [PATCH v3 01/12] KVM: arm/arm64: Set dist->spis to NULL after kfree

On Fri, Apr 13, 2018 at 10:20:47AM +0200, Eric Auger wrote: > in case kvm_vgic_map_resources() fails, typically if the vgic > distributor is not defined, __kvm_vgic_destroy will be called > several times. Indeed kvm_vgic_map_resources() is called on > first vcpu run. As a result dist->spis is

Re: [PATCH v3 11/12] KVM: arm/arm64: Implement KVM_VGIC_V3_ADDR_TYPE_REDIST_REGION

On Fri, Apr 13, 2018 at 10:20:57AM +0200, Eric Auger wrote: > Now all the internals are ready to handle multiple redistributor > regions, let's allow the userspace to register them. > > Signed-off-by: Eric Auger > > --- > > v2 -> v3: > - early exit if

Re: [PATCH v3 11/12] KVM: arm/arm64: Implement KVM_VGIC_V3_ADDR_TYPE_REDIST_REGION

On Fri, Apr 13, 2018 at 10:20:57AM +0200, Eric Auger wrote: > Now all the internals are ready to handle multiple redistributor > regions, let's allow the userspace to register them. > > Signed-off-by: Eric Auger > > --- > > v2 -> v3: > - early exit if vgic_v3_rdist_region_from_index() fails >

Re: [PATCH v3 01/12] KVM: arm/arm64: Set dist->spis to NULL after kfree

On Fri, Apr 13, 2018 at 10:20:47AM +0200, Eric Auger wrote: > in case kvm_vgic_map_resources() fails, typically if the vgic > distributor is not defined, __kvm_vgic_destroy will be called > several times. Indeed kvm_vgic_map_resources() is called on > first vcpu run. As a result dist->spis is

[PATCH v2] Always report a writeback error once

The errseq_t infrastructure assumes that errors which occurred before the file descriptor was opened are of no interest to the application. This turns out to be a regression for some applications, notably Postgres. Before errseq_t, a writeback error would be reported exactly once (as long as the

[PATCH v2] Always report a writeback error once

The errseq_t infrastructure assumes that errors which occurred before the file descriptor was opened are of no interest to the application. This turns out to be a regression for some applications, notably Postgres. Before errseq_t, a writeback error would be reported exactly once (as long as the

Re: [PATCH 2/3] drm/scheduler: Don't call wait_event_killable for signaled process.

On 04/24/2018 03:44 PM, Daniel Vetter wrote: On Tue, Apr 24, 2018 at 05:46:52PM +0200, Michel Dänzer wrote: Adding the dri-devel list, since this is driver independent code. On 2018-04-24 05:30 PM, Andrey Grodzovsky wrote: Avoid calling wait_event_killable when you are possibly being

Re: [PATCH 2/3] drm/scheduler: Don't call wait_event_killable for signaled process.

On 04/24/2018 03:44 PM, Daniel Vetter wrote: On Tue, Apr 24, 2018 at 05:46:52PM +0200, Michel Dänzer wrote: Adding the dri-devel list, since this is driver independent code. On 2018-04-24 05:30 PM, Andrey Grodzovsky wrote: Avoid calling wait_event_killable when you are possibly being

Re: [PATCH 2/3] drm/scheduler: Don't call wait_event_killable for signaled process.

Daniel Vetter writes: > On Tue, Apr 24, 2018 at 05:46:52PM +0200, Michel Dänzer wrote: >> >> Adding the dri-devel list, since this is driver independent code. >> >> >> On 2018-04-24 05:30 PM, Andrey Grodzovsky wrote: >> > Avoid calling wait_event_killable when you are

Re: [PATCH 2/3] drm/scheduler: Don't call wait_event_killable for signaled process.

Daniel Vetter writes: > On Tue, Apr 24, 2018 at 05:46:52PM +0200, Michel Dänzer wrote: >> >> Adding the dri-devel list, since this is driver independent code. >> >> >> On 2018-04-24 05:30 PM, Andrey Grodzovsky wrote: >> > Avoid calling wait_event_killable when you are possibly being called >>

Re: [PATCH 0/7] gnss: add new GNSS subsystem

On Tue, 24 Apr 2018 22:13:19 +0200 Pavel Machek wrote: > Hi! > > > This series adds a new subsystem for GNSS receivers (e.g. GPS > > receivers). > > Actually... I'd just call it GPS subsystem. Yes, GPS is a bit > misleading, but so is GNSS. We'd like Loran to use similar

Re: [PATCH 0/7] gnss: add new GNSS subsystem

On Tue, 24 Apr 2018 22:13:19 +0200 Pavel Machek wrote: > Hi! > > > This series adds a new subsystem for GNSS receivers (e.g. GPS > > receivers). > > Actually... I'd just call it GPS subsystem. Yes, GPS is a bit > misleading, but so is GNSS. We'd like Loran to use similar interface, > right?

Re: [PATCH] of: overlay: Stop leaking resources on overlay removal

On 04/24/18 10:50, Jan Kiszka wrote: > On 2018-04-24 19:44, Frank Rowand wrote: >> On 04/24/18 09:19, Jan Kiszka wrote: >>> Only the overlay notifier callbacks have a chance to potentially get >>> hold of references to those two resources, but they do not store them. >>> So it is safe to stop the

Re: [PATCH] of: overlay: Stop leaking resources on overlay removal

On 04/24/18 10:50, Jan Kiszka wrote: > On 2018-04-24 19:44, Frank Rowand wrote: >> On 04/24/18 09:19, Jan Kiszka wrote: >>> Only the overlay notifier callbacks have a chance to potentially get >>> hold of references to those two resources, but they do not store them. >>> So it is safe to stop the

Re: [RFC 00/10] ARM: Remove support for Exynos5440

On Tue, Apr 24, 2018 at 10:50:58PM +0200, Arnd Bergmann wrote: > On Tue, Apr 24, 2018 at 10:32 PM, Krzysztof Kozlowski wrote: > > Hi, > > > > > > Overview > > > > Let's continue the removal of old platforms. We already get rid of > > Exynos4212. > > Now it's time for

Re: [RFC 00/10] ARM: Remove support for Exynos5440

On Tue, Apr 24, 2018 at 10:50:58PM +0200, Arnd Bergmann wrote: > On Tue, Apr 24, 2018 at 10:32 PM, Krzysztof Kozlowski wrote: > > Hi, > > > > > > Overview > > > > Let's continue the removal of old platforms. We already get rid of > > Exynos4212. > > Now it's time for Exynos5440. > > > >

Re: [PATCH v7 2/5] of: change overlay apply input data from unflattened to FDT

Hi Alan, On 04/23/18 15:38, Frank Rowand wrote: > Hi Jan, > > + Alan Tull for fpga perspective > > On 04/22/18 03:30, Jan Kiszka wrote: >> On 2018-04-11 07:42, Jan Kiszka wrote: >>> On 2018-04-05 23:12, Rob Herring wrote: On Thu, Apr 5, 2018 at 2:28 PM, Frank Rowand

Re: [PATCH v7 2/5] of: change overlay apply input data from unflattened to FDT

Hi Alan, On 04/23/18 15:38, Frank Rowand wrote: > Hi Jan, > > + Alan Tull for fpga perspective > > On 04/22/18 03:30, Jan Kiszka wrote: >> On 2018-04-11 07:42, Jan Kiszka wrote: >>> On 2018-04-05 23:12, Rob Herring wrote: On Thu, Apr 5, 2018 at 2:28 PM, Frank Rowand wrote: > On

Re: [RFC 00/10] ARM: Remove support for Exynos5440

On Tue, Apr 24, 2018 at 10:32 PM, Krzysztof Kozlowski wrote: > Hi, > > > Overview > > Let's continue the removal of old platforms. We already get rid of Exynos4212. > Now it's time for Exynos5440. > > The Exynos5440 (quad-core A15 with GMAC, PCIe, SATA) was targeting >

Re: [RFC 00/10] ARM: Remove support for Exynos5440

On Tue, Apr 24, 2018 at 10:32 PM, Krzysztof Kozlowski wrote: > Hi, > > > Overview > > Let's continue the removal of old platforms. We already get rid of Exynos4212. > Now it's time for Exynos5440. > > The Exynos5440 (quad-core A15 with GMAC, PCIe, SATA) was targeting > server platforms

Re: [PATCH] do not call trace_printk on non-debug build

On Tue, 24 Apr 2018 16:45:05 -0400 Steven Rostedt wrote: > On Tue, 24 Apr 2018 20:39:27 + > Wei Wang wrote: > > > The config is not something new and it is controlling pr_debug and > > pr_devel, so might not be too annoying, IMHO. But I agree this is

Re: [PATCH] do not call trace_printk on non-debug build

On Tue, 24 Apr 2018 16:45:05 -0400 Steven Rostedt wrote: > On Tue, 24 Apr 2018 20:39:27 + > Wei Wang wrote: > > > The config is not something new and it is controlling pr_debug and > > pr_devel, so might not be too annoying, IMHO. But I agree this is not a > > problem from us but from

Re: [PATCH 1/2] regulator: add QCOM RPMh regulator driver

On 04/24/2018 10:41 AM, Mark Brown wrote: > On Fri, Apr 20, 2018 at 12:28:21PM -0700, David Collins wrote: >> RPMh hardware enforces the requested minimum headroom voltage for all >> regulators with a parent. It has full knowledge of the parent-child >> connections of regulators on the board (as

Re: [PATCH 1/2] regulator: add QCOM RPMh regulator driver

On 04/24/2018 10:41 AM, Mark Brown wrote: > On Fri, Apr 20, 2018 at 12:28:21PM -0700, David Collins wrote: >> RPMh hardware enforces the requested minimum headroom voltage for all >> regulators with a parent. It has full knowledge of the parent-child >> connections of regulators on the board (as

Re: [PATCH net-next 2/2 v1] netns: isolate seqnums to use per-netns locks

On Tue, Apr 24, 2018 at 03:39:25PM -0400, David Miller wrote: > From: Christian Brauner > Date: Mon, 23 Apr 2018 12:24:43 +0200 > > > + #ifdef CONFIG_NET > > + seqnum = get_ns_uevent_seqnum_by_vpid(); > > + #else > > + seqnum = uevent_seqnum;

Re: [PATCH net-next 2/2 v1] netns: isolate seqnums to use per-netns locks

On Tue, Apr 24, 2018 at 03:39:25PM -0400, David Miller wrote: > From: Christian Brauner > Date: Mon, 23 Apr 2018 12:24:43 +0200 > > > + #ifdef CONFIG_NET > > + seqnum = get_ns_uevent_seqnum_by_vpid(); > > + #else > > + seqnum = uevent_seqnum; > > + #endif > > Please

Re: [PATCH] do not call trace_printk on non-debug build

On Tue, 24 Apr 2018 20:39:27 + Wei Wang wrote: > The config is not something new and it is controlling pr_debug and > pr_devel, so might not be too annoying, IMHO. But I agree this is not a > problem from us but from abusers. And is the reason I never use pr_debug() and

Re: [PATCH] do not call trace_printk on non-debug build

On Tue, 24 Apr 2018 20:39:27 + Wei Wang wrote: > The config is not something new and it is controlling pr_debug and > pr_devel, so might not be too annoying, IMHO. But I agree this is not a > problem from us but from abusers. And is the reason I never use pr_debug() and pr_devel(). --

[PATCH net-next 1/2 v2] netns: restrict uevents

commit 07e98962fa77 ("kobject: Send hotplug events in all network namespaces") enabled sending hotplug events into all network namespaces back in 2010. Over time the set of uevents that get sent into all network namespaces has shrunk a little. We have now reached the point where hotplug events

[PATCH net-next 1/2 v2] netns: restrict uevents

commit 07e98962fa77 ("kobject: Send hotplug events in all network namespaces") enabled sending hotplug events into all network namespaces back in 2010. Over time the set of uevents that get sent into all network namespaces has shrunk a little. We have now reached the point where hotplug events

[PATCH net-next 0/2 v2] netns: uevent performance tweaks

Hey everyone, This is v2 of "netns: uevent performance tweaks" which contains *no functional changes* just a minor indendation fix as requested by David. Like Eric requested, I did extensive testing that prove significant performance improvements when using per-netns uevent sequence numbers with

[PATCH net-next 0/2 v2] netns: uevent performance tweaks

Hey everyone, This is v2 of "netns: uevent performance tweaks" which contains *no functional changes* just a minor indendation fix as requested by David. Like Eric requested, I did extensive testing that prove significant performance improvements when using per-netns uevent sequence numbers with

[PATCH net-next 2/2 v2] netns: isolate seqnums to use per-netns locks

Now that it's possible to have a different set of uevents in different network namespaces, per-network namespace uevent sequence numbers are introduced. This increases performance as locking is now restricted to the network namespace affected by the uevent rather than locking everything. Testing

[PATCH net-next 2/2 v2] netns: isolate seqnums to use per-netns locks

Now that it's possible to have a different set of uevents in different network namespaces, per-network namespace uevent sequence numbers are introduced. This increases performance as locking is now restricted to the network namespace affected by the uevent rather than locking everything. Testing

[PATCH] media: zoran: move to dma-mapping interface

No drivers should use virt_to_bus() any more. This converts one of the few remaining ones to the DMA mapping interface. Signed-off-by: Arnd Bergmann --- drivers/media/pci/zoran/Kconfig| 2 +- drivers/media/pci/zoran/zoran.h| 10 +--

[PATCH] media: zoran: move to dma-mapping interface

No drivers should use virt_to_bus() any more. This converts one of the few remaining ones to the DMA mapping interface. Signed-off-by: Arnd Bergmann --- drivers/media/pci/zoran/Kconfig| 2 +- drivers/media/pci/zoran/zoran.h| 10 +-- drivers/media/pci/zoran/zoran_card.c |

Re: [PATCH] do not call trace_printk on non-debug build

On Tue, Apr 24, 2018, 12:26 Steven Rostedt wrote: > On Tue, 24 Apr 2018 19:20:03 + > Wei Wang wrote: > > checkpatch.pl sounds good. One thing to add is we have many off tree > > patches with abuse trace_printk. Also as you mentioned, given this is > >

Re: [PATCH] do not call trace_printk on non-debug build

On Tue, Apr 24, 2018, 12:26 Steven Rostedt wrote: > On Tue, 24 Apr 2018 19:20:03 + > Wei Wang wrote: > > checkpatch.pl sounds good. One thing to add is we have many off tree > > patches with abuse trace_printk. Also as you mentioned, given this is > > really not for use in production and

[GIT] Networking

1) Fix rtnl deadlock in ipvs, from Julian Anastasov. 2) s390 qeth fixes from Julian Wiedmann (control IO completion stalls, bad MAC address update sequence, request side races on command IO timeouts). 3) Handle seq_file overflow properly in l2tp, from Guillaume Nault. 4) Fix VLAN priority

[GIT] Networking

1) Fix rtnl deadlock in ipvs, from Julian Anastasov. 2) s390 qeth fixes from Julian Wiedmann (control IO completion stalls, bad MAC address update sequence, request side races on command IO timeouts). 3) Handle seq_file overflow properly in l2tp, from Guillaume Nault. 4) Fix VLAN priority

Re: [PATCH 0/7] gnss: add new GNSS subsystem

> As proof-of-concept I have implemented drivers for receivers based on > two common GNSS chipsets (SiRFstar and u-blox), but due to lack of > hardware these have so far only been tested using mockup devices and a > USB-serial-based GPS device (using out-of-tree code). [ Let me know if > you've

Re: [PATCH 0/7] gnss: add new GNSS subsystem

> As proof-of-concept I have implemented drivers for receivers based on > two common GNSS chipsets (SiRFstar and u-blox), but due to lack of > hardware these have so far only been tested using mockup devices and a > USB-serial-based GPS device (using out-of-tree code). [ Let me know if > you've

[RFC 03/10] cpufreq: exynos: Remove support for Exynos5440

The Exynos5440 is not actively developed, there are no development boards available and probably there are no real products with it. Remove wide-tree support for Exynos5440. Signed-off-by: Krzysztof Kozlowski --- .../bindings/cpufreq/cpufreq-exynos5440.txt| 28 --

[RFC 01/10] ARM: dts: exynos: Remove Exynos5440

The Exynos5440 (quad-core A15 with GMAC, PCIe, SATA) was targeting server platforms but it did not make it to the market really. There are no development boards with it and probably there are no real products neither. The development for Exynos5440 ended in 2013 and since then the platform is in

[RFC 03/10] cpufreq: exynos: Remove support for Exynos5440

The Exynos5440 is not actively developed, there are no development boards available and probably there are no real products with it. Remove wide-tree support for Exynos5440. Signed-off-by: Krzysztof Kozlowski --- .../bindings/cpufreq/cpufreq-exynos5440.txt| 28 --

[RFC 01/10] ARM: dts: exynos: Remove Exynos5440

The Exynos5440 (quad-core A15 with GMAC, PCIe, SATA) was targeting server platforms but it did not make it to the market really. There are no development boards with it and probably there are no real products neither. The development for Exynos5440 ended in 2013 and since then the platform is in

[RFC 04/10] clk: samsung: Remove support for Exynos5440

The Exynos5440 is not actively developed, there are no development boards available and probably there are no real products with it. Remove wide-tree support for Exynos5440. Signed-off-by: Krzysztof Kozlowski --- .../devicetree/bindings/clock/exynos5440-clock.txt | 28

[RFC 04/10] clk: samsung: Remove support for Exynos5440

The Exynos5440 is not actively developed, there are no development boards available and probably there are no real products with it. Remove wide-tree support for Exynos5440. Signed-off-by: Krzysztof Kozlowski --- .../devicetree/bindings/clock/exynos5440-clock.txt | 28

Re: [PATCH 1/2] regulator: add QCOM RPMh regulator driver

>> + ret = cmd_db_ready(); >> + if (ret < 0) { >> + if (ret != -EPROBE_DEFER) >> + dev_err(dev, "Command DB not available, >> ret=%d\n", ret); >> + return ret; >> + } > > We should just make

Re: [PATCH 1/2] regulator: add QCOM RPMh regulator driver

>> + ret = cmd_db_ready(); >> + if (ret < 0) { >> + if (ret != -EPROBE_DEFER) >> + dev_err(dev, "Command DB not available, >> ret=%d\n", ret); >> + return ret; >> + } > > We should just make

[RFC 06/10] thermal: samsung: Remove support for Exynos5440

The Exynos5440 is not actively developed, there are no development boards available and probably there are no real products with it. Remove wide-tree support for Exynos5440. Signed-off-by: Krzysztof Kozlowski --- .../devicetree/bindings/thermal/exynos-thermal.txt | 14 +-

[RFC 06/10] thermal: samsung: Remove support for Exynos5440

The Exynos5440 is not actively developed, there are no development boards available and probably there are no real products with it. Remove wide-tree support for Exynos5440. Signed-off-by: Krzysztof Kozlowski --- .../devicetree/bindings/thermal/exynos-thermal.txt | 14 +-

Re: [Xen-devel] [PATCH 0/1] drm/xen-zcopy: Add Xen zero-copy helper DRM driver

Had a meeting with Daniel and talked about bringing out generic part of hyper-dmabuf to the userspace, which means we most likely reuse IOCTLs defined in xen-zcopy for our use-case if we follow his suggestion. So assuming we use these IOCTLs as they are, Several things I would like you to

Re: [Xen-devel] [PATCH 0/1] drm/xen-zcopy: Add Xen zero-copy helper DRM driver

Had a meeting with Daniel and talked about bringing out generic part of hyper-dmabuf to the userspace, which means we most likely reuse IOCTLs defined in xen-zcopy for our use-case if we follow his suggestion. So assuming we use these IOCTLs as they are, Several things I would like you to

[RFC 07/10] pinctrl: samsung: Remove support for Exynos5440

The Exynos5440 is not actively developed, there are no development boards available and probably there are no real products with it. Remove wide-tree support for Exynos5440. Signed-off-by: Krzysztof Kozlowski --- drivers/pinctrl/samsung/Kconfig | 10 +-

[RFC 07/10] pinctrl: samsung: Remove support for Exynos5440

The Exynos5440 is not actively developed, there are no development boards available and probably there are no real products with it. Remove wide-tree support for Exynos5440. Signed-off-by: Krzysztof Kozlowski --- drivers/pinctrl/samsung/Kconfig | 10 +-

Re: [PATCH v3 02/12] KVM: arm/arm64: Document KVM_VGIC_V3_ADDR_TYPE_REDIST_REGION

Hi Christoffer, Peter, On 04/24/2018 06:50 PM, Peter Maydell wrote: > On 24 April 2018 at 17:46, Christoffer Dall wrote: >> On Fri, Apr 13, 2018 at 10:20:48AM +0200, Eric Auger wrote: >>> --- a/Documentation/virtual/kvm/devices/arm-vgic-v3.txt >>> +++

Re: [PATCH v3 02/12] KVM: arm/arm64: Document KVM_VGIC_V3_ADDR_TYPE_REDIST_REGION

Hi Christoffer, Peter, On 04/24/2018 06:50 PM, Peter Maydell wrote: > On 24 April 2018 at 17:46, Christoffer Dall wrote: >> On Fri, Apr 13, 2018 at 10:20:48AM +0200, Eric Auger wrote: >>> --- a/Documentation/virtual/kvm/devices/arm-vgic-v3.txt >>> +++

[RFC 08/10] spi: s3c64xx: samsung: Remove support for Exynos5440

The Exynos5440 is not actively developed, there are no development boards available and probably there are no real products with it. Remove wide-tree support for Exynos5440. Signed-off-by: Krzysztof Kozlowski --- drivers/spi/spi-s3c64xx.c | 12 1 file changed, 12

[RFC 08/10] spi: s3c64xx: samsung: Remove support for Exynos5440

The Exynos5440 is not actively developed, there are no development boards available and probably there are no real products with it. Remove wide-tree support for Exynos5440. Signed-off-by: Krzysztof Kozlowski --- drivers/spi/spi-s3c64xx.c | 12 1 file changed, 12 deletions(-) diff

[RFC 10/10] ARM: exynos: Remove support for Exynos5440

The Exynos5440 is not actively developed, there are no development boards available and probably there are no real products with it. Remove wide-tree support for Exynos5440. Signed-off-by: Krzysztof Kozlowski --- arch/arm/mach-exynos/Kconfig | 12

[RFC 10/10] ARM: exynos: Remove support for Exynos5440

The Exynos5440 is not actively developed, there are no development boards available and probably there are no real products with it. Remove wide-tree support for Exynos5440. Signed-off-by: Krzysztof Kozlowski --- arch/arm/mach-exynos/Kconfig | 12 arch/arm/mach-exynos/common.h |

[RFC 09/10] usb: host: exynos: Remove support for Exynos5440

The Exynos5440 is not actively developed, there are no development boards available and probably there are no real products with it. Remove wide-tree support for Exynos5440. Signed-off-by: Krzysztof Kozlowski --- drivers/usb/host/ehci-exynos.c | 7 ---

[RFC 09/10] usb: host: exynos: Remove support for Exynos5440

The Exynos5440 is not actively developed, there are no development boards available and probably there are no real products with it. Remove wide-tree support for Exynos5440. Signed-off-by: Krzysztof Kozlowski --- drivers/usb/host/ehci-exynos.c | 7 --- drivers/usb/host/ohci-exynos.c | 6

[RFC 02/10] ata: ahci-platform: Remove support for Exynos5440

The Exynos5440 is not actively developed, there are no development boards available and probably there are no real products with it. Remove wide-tree support for Exynos5440. Signed-off-by: Krzysztof Kozlowski --- Documentation/devicetree/bindings/ata/ahci-platform.txt | 1 -

[RFC 02/10] ata: ahci-platform: Remove support for Exynos5440

The Exynos5440 is not actively developed, there are no development boards available and probably there are no real products with it. Remove wide-tree support for Exynos5440. Signed-off-by: Krzysztof Kozlowski --- Documentation/devicetree/bindings/ata/ahci-platform.txt | 1 -

[RFC 05/10] i2c: s3c2410: Remove support for Exynos5440

The Exynos5440 is not actively developed, there are no development boards available and probably there are no real products with it. Remove wide-tree support for Exynos5440. Signed-off-by: Krzysztof Kozlowski --- Documentation/devicetree/bindings/i2c/i2c-s3c2410.txt | 4 +---

[RFC 05/10] i2c: s3c2410: Remove support for Exynos5440

The Exynos5440 is not actively developed, there are no development boards available and probably there are no real products with it. Remove wide-tree support for Exynos5440. Signed-off-by: Krzysztof Kozlowski --- Documentation/devicetree/bindings/i2c/i2c-s3c2410.txt | 4 +---

[RFC 00/10] ARM: Remove support for Exynos5440

Hi, Overview Let's continue the removal of old platforms. We already get rid of Exynos4212. Now it's time for Exynos5440. The Exynos5440 (quad-core A15 with GMAC, PCIe, SATA) was targeting server platforms but it did not make it to the market really. There are no development boards

[RFC 00/10] ARM: Remove support for Exynos5440

Hi, Overview Let's continue the removal of old platforms. We already get rid of Exynos4212. Now it's time for Exynos5440. The Exynos5440 (quad-core A15 with GMAC, PCIe, SATA) was targeting server platforms but it did not make it to the market really. There are no development boards

Re: [patch v2] mm, oom: fix concurrent munlock and oom reaperunmap

On Tue 24-04-18 13:22:45, David Rientjes wrote: [...] > > > My patch has passed intensive testing on both x86 and powerpc, so I'll > > > ask > > > that it's pushed for 4.17-rc3. Many thanks to Tetsuo for the suggestion > > > on calling __oom_reap_task_mm() from exit_mmap(). > > > > Yeah, but

Re: [patch v2] mm, oom: fix concurrent munlock and oom reaperunmap

On Tue 24-04-18 13:22:45, David Rientjes wrote: [...] > > > My patch has passed intensive testing on both x86 and powerpc, so I'll > > > ask > > > that it's pushed for 4.17-rc3. Many thanks to Tetsuo for the suggestion > > > on calling __oom_reap_task_mm() from exit_mmap(). > > > > Yeah, but

[PATCH v3 3/3] dh key: get rid of stack allocated array for zeroes

We're interested in getting rid of all of the stack allocated arrays in the kernel: https://lkml.org/lkml/2018/3/7/621 This case is interesting, since we really just need an array of bytes that are zero. The loop already ensures that if the array isn't exactly the right size that enough zero

[PATCH v3 3/3] dh key: get rid of stack allocated array for zeroes

We're interested in getting rid of all of the stack allocated arrays in the kernel: https://lkml.org/lkml/2018/3/7/621 This case is interesting, since we really just need an array of bytes that are zero. The loop already ensures that if the array isn't exactly the right size that enough zero

[PATCH v3 2/3] dh key: get rid of stack allocated array

We're interested in getting rid of all of the stack allocated arrays in the kernel: https://lkml.org/lkml/2018/3/7/621 This particular vla is used as a temporary output buffer in case there is too much hash output for the destination buffer. Instead, let's just allocate a buffer that's big enough

[PATCH v3 2/3] dh key: get rid of stack allocated array

We're interested in getting rid of all of the stack allocated arrays in the kernel: https://lkml.org/lkml/2018/3/7/621 This particular vla is used as a temporary output buffer in case there is too much hash output for the destination buffer. Instead, let's just allocate a buffer that's big enough

[PATCH v3 1/3] big key: get rid of stack array allocation

We're interested in getting rid of all of the stack allocated arrays in the kernel [1]. This patch simply hardcodes the iv length to match that of the hardcoded cipher. [1]: https://lkml.org/lkml/2018/3/7/621 v2: hardcode the length of the nonce to be the GCM AES IV length, and do a sanity

[PATCH v3 1/3] big key: get rid of stack array allocation

We're interested in getting rid of all of the stack allocated arrays in the kernel [1]. This patch simply hardcodes the iv length to match that of the hardcoded cipher. [1]: https://lkml.org/lkml/2018/3/7/621 v2: hardcode the length of the nonce to be the GCM AES IV length, and do a sanity

Re: [patch v2] mm, oom: fix concurrent munlock and oom reaperunmap

On Tue, 24 Apr 2018, Michal Hocko wrote: > > I wanted to remove all per task checks because they are now irrelevant: > > this would be the first dependency that exit_mmap() has on any > > task_struct, which isn't intuitive -- we simply want to exit the mmap. > > There's no requirement that

Re: [patch v2] mm, oom: fix concurrent munlock and oom reaperunmap

On Tue, 24 Apr 2018, Michal Hocko wrote: > > I wanted to remove all per task checks because they are now irrelevant: > > this would be the first dependency that exit_mmap() has on any > > task_struct, which isn't intuitive -- we simply want to exit the mmap. > > There's no requirement that

Re: [patch v2] mm, oom: fix concurrent munlock and oom reaperunmap

On Tue 24-04-18 13:01:03, David Rientjes wrote: > On Tue, 24 Apr 2018, Michal Hocko wrote: > > > Is there any reason why we cannot simply call __oom_reap_task_mm as we > > have it now? mmap_sem for read shouldn't fail here because this is the > > last reference of the mm and we are past the ksm

Re: [patch v2] mm, oom: fix concurrent munlock and oom reaperunmap

On Tue 24-04-18 13:01:03, David Rientjes wrote: > On Tue, 24 Apr 2018, Michal Hocko wrote: > > > Is there any reason why we cannot simply call __oom_reap_task_mm as we > > have it now? mmap_sem for read shouldn't fail here because this is the > > last reference of the mm and we are past the ksm

Re: [PATCH 0/7] gnss: add new GNSS subsystem

Hi! > This series adds a new subsystem for GNSS receivers (e.g. GPS > receivers). Actually... I'd just call it GPS subsystem. Yes, GPS is a bit misleading, but so is GNSS. We'd like Loran to use similar interface, right? We'd like to QZSS to use similar interface, too...

Re: [PATCH 0/7] gnss: add new GNSS subsystem

Hi! > This series adds a new subsystem for GNSS receivers (e.g. GPS > receivers). Actually... I'd just call it GPS subsystem. Yes, GPS is a bit misleading, but so is GNSS. We'd like Loran to use similar interface, right? We'd like to QZSS to use similar interface, too...

RE: [PATCH] tpm: tpm_crb: relinquish locality on error path.

> On Tue, Apr 24, 2018 at 07:03:28PM +0300, Jarkko Sakkinen wrote: > > On Fri, Apr 20, 2018 at 01:19:12PM +, Winkler, Tomas wrote: > > > > > On Tue, 2018-04-10 at 09:00 +, Winkler, Tomas wrote: > > > > > > > > > > > > > > On Sat, 2018-04-07 at 19:12 +0300, Tomas Winkler wrote: > > > > > >

RE: [PATCH] tpm: tpm_crb: relinquish locality on error path.

> On Tue, Apr 24, 2018 at 07:03:28PM +0300, Jarkko Sakkinen wrote: > > On Fri, Apr 20, 2018 at 01:19:12PM +, Winkler, Tomas wrote: > > > > > On Tue, 2018-04-10 at 09:00 +, Winkler, Tomas wrote: > > > > > > > > > > > > > > On Sat, 2018-04-07 at 19:12 +0300, Tomas Winkler wrote: > > > > > >

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