[RFC v4 00/18] Landlock LSM: Unprivileged sandboxing

Hi, This fourth RFC brings some improvements over the previous one [1]. An important new point is the abstraction from the raw types of LSM hook arguments. It is now possible to call a Landlock function the same way for LSM hooks with different internal argument types. Some parts of the code are r

[RFC v4 01/18] landlock: Add Kconfig

Initial Landlock Kconfig needed to split the Landlock eBPF and seccomp parts to ease the review. Changes from v2: * add seccomp filter or cgroups (with eBPF programs attached support) dependencies Signed-off-by: Mickaël Salaün Cc: James Morris Cc: Kees Cook Cc: Serge E. Hallyn --- security

[RFC v4 11/18] seccomp,landlock: Handle Landlock hooks per process hierarchy

The seccomp(2) syscall can be use to apply a Landlock rule to the current process. As with a seccomp filter, the Landlock rule is enforced for all its future children. An inherited rule tree can be updated (append-only) by the owner of inherited Landlock nodes (e.g. a parent process that create a n

RE: [PATCH v9 02/12] vfio: VFIO based driver for Mediated devices

> From: Kirti Wankhede [mailto:kwankh...@nvidia.com] > Sent: Tuesday, October 18, 2016 5:22 AM > > vfio_mdev driver registers with mdev core driver. > MDEV core driver creates mediated device and calls probe routine of use same case - either 'mdev core' or 'MDEV core' > vfio_mdev driver for each

[tip:x86/asm] x86/decoder: Use stderr if insn sanity test fails

Commit-ID: bb12d6740f6de393927362f23f833a79d85df384 Gitweb: http://git.kernel.org/tip/bb12d6740f6de393927362f23f833a79d85df384 Author: Paul Bolle AuthorDate: Tue, 25 Oct 2016 22:56:05 +0200 Committer: Ingo Molnar CommitDate: Wed, 26 Oct 2016 08:41:06 +0200 x86/decoder: Use stderr if in

[tip:x86/asm] x86/decoder: Use stdout if insn decoder test is successful

Commit-ID: bdcc18b548b8f1fab23c097724c6f32daac03185 Gitweb: http://git.kernel.org/tip/bdcc18b548b8f1fab23c097724c6f32daac03185 Author: Paul Bolle AuthorDate: Tue, 25 Oct 2016 22:56:04 +0200 Committer: Ingo Molnar CommitDate: Wed, 26 Oct 2016 08:41:06 +0200 x86/decoder: Use stdout if in

[git pull] drm/x86 pat regression fix.

Hi Linus, This is a standalone pull request for the fix for a regression introduced in -rc1 by a change to vm_insert_mixed to start using the PAT range tracking to validate page protections. With this fix in place, all the VRAM mappings for GPU drivers ended up at UC instead of WC. There are prob

RE: [PATCH v9 01/12] vfio: Mediated device Core driver

> From: Kirti Wankhede [mailto:kwankh...@nvidia.com] > Sent: Tuesday, October 18, 2016 5:22 AM > > Design for Mediated Device Driver: > Main purpose of this driver is to provide a common interface for mediated > device management that can be used by different drivers of different > devices. > > T

Re: [PATCH] tty/serial: at91: fix hardware handshake on Atmel platforms

On 25/10/2016 18:22, Alexandre Belloni wrote: > Hi, > > On 25/10/2016 at 18:11:35 +0200, Richard Genoud wrote : >> commit 1cf6e8fc8341 ("tty/serial: at91: fix RTS line management when >> hardware handshake is enabled"), despite its title, broke hardware >> handshake on *every* Atmel platforms. >>

Re: [PATCH] IB/mlx4: avoid a -Wmaybe-uninitialize warning

On 10/25/2016 7:16 PM, Arnd Bergmann wrote: There is an old warning about mlx4_SW2HW_EQ_wrapper on x86: ethernet/mellanox/mlx4/resource_tracker.c: In function ‘mlx4_SW2HW_EQ_wrapper’: ethernet/mellanox/mlx4/resource_tracker.c:3071:10: error: ‘eq’ may be used uninitialized in this function [-Wer

Re: [PATCH 19/28] brcmfmac: avoid maybe-uninitialized warning in brcmf_cfg80211_start_ap

Arnd Bergmann writes: > A bugfix added a sanity check around the assignment and use of the > 'is_11d' variable, which looks correct to me, but as the function is > rather complex already, this confuses the compiler to the point where > it can no longer figure out if the variable is always initial

Re: [PATCH v2] staging: vc04_services: Replace dmac_map_area with dmac_map_sg

On Tue, Oct 25, 2016 at 07:23:27PM -0700, Michael Zoran wrote: > The original arm implementation uses dmac_map_area which is not > portable. Replace it with an architecture neutral version > which uses dma_map_sg. > > As you can see that for larger page sizes, the dma_map_sg > implementation is f

Re: [PATCH v2] drm/mediatek: fixed the calc method of data rate per lane

Hi, Jitao: On Tue, 2016-10-25 at 13:40 +0800, Jitao Shi wrote: > Tune dsi frame rate by pixel clock, dsi add some extra signal (i.e. Tlpx, > Ths-prepare, Ths-zero, Ths-trail,Ths-exit) when enter and exit LP mode, this > signal will cause h-time larger than normal and reduce FPS. > Need to multiply

Re: [PATCH] crypto: caam: fix type mismatch warning

On 10/26/2016 12:29 AM, Arnd Bergmann wrote: > Building the caam driver on arm64 produces a harmless warning: > > drivers/crypto/caam/caamalg.c:140:139: warning: comparison of distinct > pointer types lacks a cast > > We can use min_t to tell the compiler which type we want it to use > here. >

[PATCH V3 1/9] PM / OPP: Reword binding supporting multiple regulators per device

On certain platforms (like TI), DVFS for a single device (CPU) requires configuring multiple power supplies. The OPP bindings already contains binding and example to explain this case, but it isn't sufficient. For example, there is no way for the code parsing these bindings to know which voltage v

[PATCH V3 9/9] PM / OPP: Don't assume platform doesn't have regulators

If the regulators aren't set explicitly by the platform, the OPP core assumes that the platform doesn't have any regulator and uses the clk-only callback. If the platform failed to register a regulator with the core, then this can turn out to be a dangerous assumption as the OPP core will try to c

[PATCH V3 8/9] PM / OPP: Don't WARN on multiple calls to dev_pm_opp_set_regulators()

If a platform specific OPP driver has called this routine first and set the regulators, then the second call from cpufreq-dt driver will hit the WARN_ON(). Remove the WARN_ON(), but continue to return error in such cases. Signed-off-by: Viresh Kumar Reviewed-by: Stephen Boyd Tested-by: Dave Gerl

[PATCH V3 4/9] PM / OPP: Pass struct dev_pm_opp_supply to _set_opp_voltage()

Pass the entire supply structure instead of all of its fields. Signed-off-by: Viresh Kumar Tested-by: Dave Gerlach --- drivers/base/power/opp/core.c | 44 +-- 1 file changed, 17 insertions(+), 27 deletions(-) diff --git a/drivers/base/power/opp/core.c b/

[PATCH V3 7/9] PM / OPP: Allow platform specific custom set_opp() callbacks

The generic set_opp() handler isn't sufficient for platforms with complex DVFS. For example, some TI platforms have multiple regulators for a CPU device. The order in which various supplies need to be programmed is only known to the platform code and its best to leave it to it. This patch impleme

[PATCH V3 6/9] PM / OPP: Separate out _generic_opp_set_rate()

Later patches would add support for custom opp_set_rate callbacks. This patch separates out the code for generic opp_set_rate handler in order to prepare for that. Signed-off-by: Viresh Kumar Tested-by: Dave Gerlach --- drivers/base/power/opp/core.c | 180 +--

[PATCH V3 2/9] PM / OPP: Don't use OPP structure outside of rcu protected section

The OPP structure must not be used out of the rcu protected section. Cache the values to be used in separate variables instead. Signed-off-by: Viresh Kumar Tested-by: Dave Gerlach --- drivers/base/power/opp/core.c | 16 +--- 1 file changed, 13 insertions(+), 3 deletions(-) diff --g

[PATCH V3 5/9] PM / OPP: Add infrastructure to manage multiple regulators

This patch adds infrastructure to manage multiple regulators and updates the only user (cpufreq-dt) of dev_pm_opp_set{put}_regulator(). This is preparatory work for adding full support for devices with multiple regulators. Signed-off-by: Viresh Kumar Tested-by: Dave Gerlach --- drivers/base/po

[PATCH V3 0/9] PM / OPP: Multiple regulator support

Hi, Some platforms (like TI) have complex DVFS configuration for CPU devices, where multiple regulators are required to be configured to change DVFS state of the device. This was explained well by Nishanth earlier [1]. One of the major complaints around multiple regulators case was that the DT is

[PATCH V3 3/9] PM / OPP: Manage supply's voltage/current in a separate structure

This is a preparatory step for multiple regulator per device support. Move the voltage/current variables to a new structure. Signed-off-by: Viresh Kumar Tested-by: Dave Gerlach --- drivers/base/power/opp/core.c| 44 +--- drivers/base/power/opp/debugfs.c |

Re: [PATCH] powerpc: process.c: fix Kconfig typo

On Wed, Oct 26, 2016 at 7:52 AM, Michael Ellerman wrote: > Cyril Bur writes: > >> On Wed, 2016-10-05 at 07:57 +0200, Valentin Rothberg wrote: >>> s/ALIVEC/ALTIVEC/ >>> >> >> Oops, nice catch >> >>> Signed-off-by: Valentin Rothberg >> >> Reviewed-by: Cyril Bur > > How did we not notice? Sounds l

RE: [PATCH 0/6] ACPICA: Interpreter: Improve lock order fixes

Hi, Rafael > From: linux-acpi-ow...@vger.kernel.org > [mailto:linux-acpi-ow...@vger.kernel.org] On Behalf Of Rafael J. > Wysocki > Subject: Re: [PATCH 0/6] ACPICA: Interpreter: Improve lock order fixes > > On Tue, Oct 25, 2016 at 7:20 AM, Lv Zheng wrote: > > This patchset improves ACPICA intepr

Re: [PATCH 1/2] x86/io: add interface to reserve io memtype for a resource range. (v1.1)

>> >> Is anything on a driver to be able to tell when this is actually needed ? >> How will driver developers know? Can you add a bit of documentation to >> the API? If its transitive towards a secondary solution indicating so >> would help driver developers. > > I'll plug the io-mapping stuff agai

Re: [PATCH V2 6/8] PM / OPP: Separate out _generic_opp_set_rate()

On 25-10-16, 11:59, Stephen Boyd wrote: > On 10/20, Viresh Kumar wrote: > > Later patches would add support for custom opp_set_rate callbacks. This > > I know the OPP consumer function has "rate" in the name, but it > makes more sense to call the callback set_opp instead because we > could be doin

Re: [RFC PATCH 1/5] mm/page_alloc: always add freeing page at the tail of the buddy list

On 2016/10/26 13:59, Joonsoo Kim wrote: > On Wed, Oct 26, 2016 at 01:50:37PM +0800, Xishi Qiu wrote: >> On 2016/10/26 12:37, Joonsoo Kim wrote: >> >>> On Mon, Oct 17, 2016 at 05:21:54PM +0800, Xishi Qiu wrote: On 2016/10/13 16:08, js1...@gmail.com wrote: > From: Joonsoo Kim > >>

Re: [PATCH 6/5] KVM: x86: fix periodic lapic timer with hrtimers

2016-10-26 14:02 GMT+08:00 Wanpeng Li : > 2016-10-25 19:43 GMT+08:00 Radim Krčmář : >> 2016-10-25 07:39+0800, Wanpeng Li: >>> 2016-10-24 23:27 GMT+08:00 Radim Krčmář : 2016-10-24 17:09+0200, Paolo Bonzini: > On 24/10/2016 17:03, Radim Krčmář wrote: [...] > > Reviewed-by: Paolo

Re: [PATCH V2 7/8] PM / OPP: Allow platform specific custom opp_set_rate() callbacks

On 25-10-16, 12:01, Stephen Boyd wrote: > On 10/20, Viresh Kumar wrote: > > The generic opp_set_rate() handler isn't sufficient for platforms with > > complex DVFS. For example, some TI platforms have multiple regulators > > for a CPU device. The order in which various supplies need to be > > prog

Re: [PATCH V2 5/8] PM / OPP: Add infrastructure to manage multiple regulators

On 25-10-16, 09:49, Stephen Boyd wrote: > On 10/20, Viresh Kumar wrote: > > diff --git a/drivers/base/power/opp/core.c b/drivers/base/power/opp/core.c > > index 37fad2eb0f47..45c70ce07864 100644 > > --- a/drivers/base/power/opp/core.c > > +++ b/drivers/base/power/opp/core.c > > @@ -235,21 +237,44 @

Re: [PATCH 6/5] KVM: x86: fix periodic lapic timer with hrtimers

2016-10-25 19:43 GMT+08:00 Radim Krčmář : > 2016-10-25 07:39+0800, Wanpeng Li: >> 2016-10-24 23:27 GMT+08:00 Radim Krčmář : >>> 2016-10-24 17:09+0200, Paolo Bonzini: On 24/10/2016 17:03, Radim Krčmář wrote: >>> [...] Reviewed-by: Paolo Bonzini Go ahead, squash it into 5/5

Re: [RFC PATCH 1/5] mm/page_alloc: always add freeing page at the tail of the buddy list

On Wed, Oct 26, 2016 at 01:50:37PM +0800, Xishi Qiu wrote: > On 2016/10/26 12:37, Joonsoo Kim wrote: > > > On Mon, Oct 17, 2016 at 05:21:54PM +0800, Xishi Qiu wrote: > >> On 2016/10/13 16:08, js1...@gmail.com wrote: > >> > >>> From: Joonsoo Kim > >>> > >>> Currently, freeing page can stay longer

Re: [RFC PATCH 1/5] mm/page_alloc: always add freeing page at the tail of the buddy list

On 2016/10/26 12:37, Joonsoo Kim wrote: > On Mon, Oct 17, 2016 at 05:21:54PM +0800, Xishi Qiu wrote: >> On 2016/10/13 16:08, js1...@gmail.com wrote: >> >>> From: Joonsoo Kim >>> >>> Currently, freeing page can stay longer in the buddy list if next higher >>> order page is in the buddy list in ord

Re: [PATCH 1/2] x86/io: add interface to reserve io memtype for a resource range. (v1.1)

On Tue, Oct 25, 2016 at 07:31:29PM +0200, Luis R. Rodriguez wrote: > On Mon, Oct 24, 2016 at 04:31:45PM +1000, Dave Airlie wrote: > > A recent change to the mm code in: > > 87744ab3832b83ba71b931f86f9cfdb000d07da5 > > mm: fix cache mode tracking in vm_insert_mixed() > > > > started enforcing check

[tip:x86/asm] mm/page_alloc: Remove kernel address exposure in free_reserved_area()

Commit-ID: adb1fe9ae2ee6ef6bc10f3d5a588020e7664dfa7 Gitweb: http://git.kernel.org/tip/adb1fe9ae2ee6ef6bc10f3d5a588020e7664dfa7 Author: Josh Poimboeuf AuthorDate: Tue, 25 Oct 2016 09:51:14 -0500 Committer: Ingo Molnar CommitDate: Tue, 25 Oct 2016 18:40:37 +0200 mm/page_alloc: Remove ker

[tip:x86/asm] x86/dumpstack: Remove raw stack dump

Commit-ID: 0ee1dd9f5e7eae4e55f95935b72d4beecb03de9c Gitweb: http://git.kernel.org/tip/0ee1dd9f5e7eae4e55f95935b72d4beecb03de9c Author: Josh Poimboeuf AuthorDate: Tue, 25 Oct 2016 09:51:13 -0500 Committer: Ingo Molnar CommitDate: Tue, 25 Oct 2016 18:40:37 +0200 x86/dumpstack: Remove raw

[tip:x86/asm] x86/dumpstack: Remove kernel text addresses from stack dump

Commit-ID: bb5e5ce545f2031c96f7901cd8d1698ea3ca4c9c Gitweb: http://git.kernel.org/tip/bb5e5ce545f2031c96f7901cd8d1698ea3ca4c9c Author: Josh Poimboeuf AuthorDate: Tue, 25 Oct 2016 09:51:12 -0500 Committer: Ingo Molnar CommitDate: Tue, 25 Oct 2016 18:40:37 +0200 x86/dumpstack: Remove ker

[tip:x86/asm] scripts/faddr2line: Fix "size mismatch" error

Commit-ID: efdb4167e676aaba7505bec739785b76e206cb45 Gitweb: http://git.kernel.org/tip/efdb4167e676aaba7505bec739785b76e206cb45 Author: Josh Poimboeuf AuthorDate: Tue, 25 Oct 2016 09:51:11 -0500 Committer: Ingo Molnar CommitDate: Tue, 25 Oct 2016 18:40:37 +0200 scripts/faddr2line: Fix "

[PATCH v2 3/3] kernel/smp: Tell the user we're bringing up secondary CPUs

Currently we don't print anything before starting to bring up secondary CPUs. This can be confusing if it takes a long time to bring up the secondaries, or if the kernel crashes while doing so and produces no further output. On x86 they work around this by detecting when the first secondary CPU co

[PATCH v2 2/3] kernel/smp: Make the SMP boot message common on all arches

Currently after bringing up secondary CPUs all arches print "Brought up %d CPUs". On x86 they also print the number of nodes that were brought online. It would be nice to also print the number of nodes on other arches. Although we could override smp_announce() on the other ~10 NUMA aware arches, i

[PATCH v2 1/3] kernel/smp: Define pr_fmt() for smp.c

This makes all our pr_xxx()'s start with "smp: ", which helps pin down where they come from and generally looks nice. There is actually only one pr_xxx() use in smp.c at the moment, but we will add some more in the next commit. Suggested-by: Borislav Petkov Signed-off-by: Michael Ellerman --- k

Re: [PATCH 1/2] kernel/smp: Make the SMP boot message common on all arches

Ingo Molnar writes: > * Michael Ellerman wrote: >> @@ -564,8 +560,11 @@ void __init smp_init(void) >> cpu_up(cpu); >> } >> >> +num_nodes = num_online_nodes(); >> +pr_info("smp: Brought up %d node%s, %d CPUs\n", >> +num_nodes, (num_nodes > 1 ? "s" :

Re: [PATCH 1/2] kernel/smp: Make the SMP boot message common on all arches

Borislav Petkov writes: > On Thu, Oct 13, 2016 at 07:55:19PM +1100, Michael Ellerman wrote: >> @@ -564,8 +560,11 @@ void __init smp_init(void) >> cpu_up(cpu); >> } >> >> +num_nodes = num_online_nodes(); >> +pr_info("smp: Brought up %d node%s, %d CPUs\n", >> +

[PATCH] arm64: defconfig: Enable DRM DU and V4L2 FCP + VSP modules

From: Magnus Damm Extend the ARM64 defconfig to enable the DU DRM device as module together with required dependencies of V4L2 FCP and VSP modules. This enables VGA output on the r8a7795 Salvator-X board. Signed-off-by: Magnus Damm --- Written against next-20161026 arch/arm64/configs/defco

[PATCH 3/3] x86/vmware: Add paravirt sched clock

Set pv_time_ops.sched_clock to vmware_sched_clock(). It is simplified version of native_sched_clock() without ring buffer of mult/shift/offset triplets and preempt toggling. Since VMware hypervisor provides constant tsc we can use constant mult/shift/offset triplet calculated at boot time. no-vmw-

[PATCH 2/3] x86/vmware: Add basic paravirt ops support

Add basic paravirt support: 1. set pv_info.name to "VMware" to have proper boot log message Booting paravirtualized kernel on VMware instead of "... on bare hardware" 2. set pv_cpu_ops.io_delay() to empty function - paravirt_nop() to avoid vm-exits on IO delays. Signed-off-by: Al

lening bieden 3%

Goede dag, Dit is Lloyd's TSB Bank plc leningen aan te bieden. Lloyds TSB biedt flexibele en betaalbare leningen voor welk doel u te helpen uw doelen te bereiken. we lening tegen lage rente van 3%. Hier zijn een aantal belangrijke kenmerken van de persoonlijke lening aangeboden door Lloyd's

[PATCH 0/3] x86/vmware guest improvements

This patchset includes several VMware guest improvements: Alexey Makhalov (3): x86/vmware: Use tsc_khz value for calibrate_cpu() x86/vmware: Add basic paravirt ops support x86/vmware: Add paravirt sched clock Documentation/kernel-parameters.txt | 4 +++ arch/x86/kernel/cpu/vmware.c

[PATCH 1/3] x86/vmware: Use tsc_khz value for calibrate_cpu()

After aa297292d708, there are separate native calibrations for cpu_khz and tsc_khz. The code sets x86_platform.calibrate_cpu to native_calibrate_cpu() which looks in cpuid leaf 0x16 or msrs for the cpu frequency. Since we keep the tsc_khz constant (even after vmotion), the cpu_khz and tsc_khz may s

RE: [PATCH 0/9] staging: fsl-mc: move bus driver out of staging, add dpio

> -Original Message- > From: Alexander Graf [mailto:ag...@suse.de] > Sent: Monday, October 24, 2016 9:34 AM > To: Stuart Yoder ; gre...@linuxfoundation.org > Cc: German Rivera ; de...@driverdev.osuosl.org; > linux-kernel@vger.kernel.org; > a...@arndb.de; Leo Li > Subject: Re: [PATCH 0/9

Re: [RFC 8/8] mm: Add N_COHERENT_DEVICE node type into node_states[]

On 10/25/2016 12:52 PM, Balbir Singh wrote: > > > On 24/10/16 15:31, Anshuman Khandual wrote: >> Add a new member N_COHERENT_DEVICE into node_states[] nodemask array to >> enlist all those nodes which contain only coherent device memory. Also >> creates a new sysfs interface /sys/devices/system/n

Re: [RFC PATCH 2/5] mm/page_alloc: use smallest fallback page first in movable allocation

On Fri, Oct 14, 2016 at 12:52:26PM +0200, Vlastimil Babka wrote: > On 10/14/2016 03:26 AM, Joonsoo Kim wrote: > >On Thu, Oct 13, 2016 at 11:12:10AM +0200, Vlastimil Babka wrote: > >>On 10/13/2016 10:08 AM, js1...@gmail.com wrote: > >>>From: Joonsoo Kim > >>> > >>>When we try to find freepage in fa

Re: [RFC PATCH 1/5] mm/page_alloc: always add freeing page at the tail of the buddy list

On Mon, Oct 17, 2016 at 05:21:54PM +0800, Xishi Qiu wrote: > On 2016/10/13 16:08, js1...@gmail.com wrote: > > > From: Joonsoo Kim > > > > Currently, freeing page can stay longer in the buddy list if next higher > > order page is in the buddy list in order to help coalescence. However, > > it doe

Re: [kernel-hardening] [PATCH] module: extend 'rodata=off' boot cmdline parameter to module mappings

Rusty, Jessica On Wed, Oct 26, 2016 at 10:43:32AM +1030, Rusty Russell wrote: > AKASHI Takahiro writes: > > On Thu, Oct 20, 2016 at 01:48:15PM -0700, Kees Cook wrote: > >> On Wed, Oct 19, 2016 at 11:24 PM, AKASHI Takahiro > >> wrote: > >> > The current "rodata=off" parameter disables read-only k

Re: [PATCH v6 3/6] mm/cma: populate ZONE_CMA

On Tue, Oct 18, 2016 at 05:27:30PM +0900, Joonsoo Kim wrote: > On Tue, Oct 18, 2016 at 09:42:57AM +0200, Vlastimil Babka wrote: > > On 10/14/2016 05:03 AM, js1...@gmail.com wrote: > > >@@ -145,6 +145,35 @@ static int __init cma_activate_area(struct cma *cma) > > > static int __init cma_init_reserve

Re: [PATCH v3] x86/msr: Add write msr notrace to avoid the debug codes splash

2016-10-25 19:15 GMT+08:00 Paolo Bonzini : > > > On 25/10/2016 04:58, Wanpeng Li wrote: >> @@ -319,7 +319,7 @@ static void kvm_guest_apic_eoi_write(u32 reg, u32 val) > > This needs to be notrace too. Ok, I just sent out a new version for this. Regards, Wanpeng Li

Re: [RFC PATCH] xhci: do not halt the secondary HCD

On Tue, Sep 20, 2016 at 5:56 PM, Mathias Nyman wrote: > Quick Googling shows that that TI TUSB 73x0 USB3.0 xHCI host has an issue > with halting. > > Errata says host needs 125us to 1ms between the last control transfer and > clearing the run/stop bit. (halting the host) > > Suggested workaround i

[PATCH v4] x86/msr: Add write msr notrace to avoid the debug codes splash

From: Wanpeng Li As Peterz pointed out: | The thing is, many many smp_reschedule_interrupt() invocations don't | actually execute anything much at all and are only send to tickle the | return to user path (which does the actual preemption). This patch add write msr notrace to avoid the debug co

Re: [PATCHv4 18/43] block: define BIO_MAX_PAGES to HPAGE_PMD_NR if huge page cache enabled

On Oct 25, 2016, at 6:54 AM, Kirill A. Shutemov wrote: > > On Tue, Oct 25, 2016 at 12:21:22AM -0700, Christoph Hellwig wrote: >> On Tue, Oct 25, 2016 at 03:13:17AM +0300, Kirill A. Shutemov wrote: >>> We are going to do IO a huge page a time. So we need BIO_MAX_PAGES to be >>> at least HPAGE_PMD_

RE: [PATCH 1/3] clk: qcom: gdsc: Add support for gdscs with HW control

Hi Stan, >Hi Sricharan, > >On 10/24/2016 01:18 PM, Sricharan R wrote: >> From: Rajendra Nayak >> >> Some GDSCs might support a HW control mode, where in the power >> domain (gdsc) is brought in and out of low power state (while >> unsued) without any SW assistance, saving power. >> Such GDSCs can

[PATCH] drm: rcar-du: Fix R-Car Gen3 crash when VSP is disabled

From: Magnus Damm For the DU to operate on R-Car Gen3 hardware a combination of DU and VSP devices are required. Since the DU driver also supports earlier generations hardware the VSP portion is enabled via Kconfig. The arm64 defconfig is as of v4.9-rc1 having the DU driver enabled as a module,

Re: [PATCH V2 4/8] PM / OPP: Pass struct dev_pm_opp_supply to _set_opp_voltage()

On 25-10-16, 13:26, Stephen Boyd wrote: > For things like AVS we'll probably want to do that, although it's > sort of funny because replacing RCU with rw-locks is the opposite > direction most people go. Yes, that would be very funny :) > With AVS we would be updating the > voltage(s) in use for

Re: [PATCH 1/3] usb: dwc3: host: inherit dma configuration from parent dev

On Tue, Oct 25, 2016 at 04:26:26PM +0530, Sriram Dash wrote: > For xhci-hcd platform device, all the DMA parameters are not configured > properly, notably dma ops for dwc3 devices. > > The idea here is that you pass in the parent of_node along with the child > device pointer, so it would behave ex

Re: [PATCH V2 0/8] PM / OPP: Multiple regulator support

On 25-10-16, 16:13, Dave Gerlach wrote: > I think what you have shared below is a good safety check but if I rename > the regulator properties in the DT for the cpu (to vdd and vbb, meaning > cpufreq detects no regulator) and do *not* call dev_pm_opp_set_regulators > before cpufreq-dt probes we fai

Re: [PATCH V2 0/6] ARM64: Uprobe support added

Hi Catalin, Please let me know if everything else other than is_trap_insn() looks fine to you. May be I can work well in time. It would be great if we can make it into v4.9. ~Pratyush On Tue, Sep 27, 2016 at 1:17 PM, Pratyush Anand wrote: > Changes since v1: > * Exposed sync_icache_aliases()

Re: [PATCH 1/2] mm/memblock: prepare a capability to support memblock near alloc

On 2016/10/25 21:23, Michal Hocko wrote: > On Tue 25-10-16 10:59:17, Zhen Lei wrote: >> If HAVE_MEMORYLESS_NODES is selected, and some memoryless numa nodes are >> actually exist. The percpu variable areas and numa control blocks of that >> memoryless numa nodes need to be allocated from the near

[PATCH v6 4/5] ARM: DTS: da850: Add cfgchip syscon node

Add a syscon node for the SoC CFGCHIPn registers. This is needed for the new usb phy driver. Signed-off-by: David Lechner --- arch/arm/boot/dts/da850.dtsi | 4 1 file changed, 4 insertions(+) diff --git a/arch/arm/boot/dts/da850.dtsi b/arch/arm/boot/dts/da850.dtsi index f79e1b9..6bbf20d 10

[PATCH v6 0/5] da8xx USB PHY platform devices and clocks

It has been almost 6 months since the v5 submission, so here is a recap: * There were a number of phy and usb dependencies that were submitted separately. * The last of the usb dependencies has finally made its way into linux-next today. * This series was recently included in "[PATCH/RFT v2 00

[PATCH v6 1/5] ARM: davinci: da8xx: add usb phy clocks

Up to this point, the USB phy clock configuration was handled manually in the board files and in the usb drivers. This adds proper clocks so that the usb drivers can use clk_get and clk_enable and not have to worry about the details. Also, the related code is removed from the board files and replac

[PATCH v6 3/5] ARM: davinci: da8xx: Add USB PHY platform declaration

There is now a proper phy driver for the DA8xx SoC USB PHY. This adds the platform device declarations needed to use it. Signed-off-by: David Lechner --- da8xx-usb-phy device id is changed to -1 since there is only one da8xx-usb-phy device. arch/arm/mach-davinci/board-da830-evm.c | 28

[PATCH v6 2/5] ARM: davinci: da8xx: Add CFGCHIP syscon platform declaration.

The CFGCHIP registers are used by a number of devices, so using a syscon device to share them. The first consumer of this will by the phy-da8xx-usb driver. Signed-off-by: David Lechner --- syscon device id is changed to -1 since there is only one syscon device. arch/arm/mach-davinci/board-da83

[PATCH v6 5/5] ARM: DTS: da850: Add usb phy node

Add a node for the new usb phy driver. Signed-off-by: David Lechner --- arch/arm/boot/dts/da850.dtsi | 5 + 1 file changed, 5 insertions(+) diff --git a/arch/arm/boot/dts/da850.dtsi b/arch/arm/boot/dts/da850.dtsi index 6bbf20d..33fcdce 100644 --- a/arch/arm/boot/dts/da850.dtsi +++ b/arch/ar

linux-next: no releases next week

Hi all, There will probably be no linux-next releases next week while I am attending Kernel Summit. -- Cheers, Stephen Rothwell

linux-next: Tree for Oct 26

Hi all, There will probably be no linux-next releases next week while I attend the Kernel Summit. Changes since 20161025: The sunxi tree lost its build failure. The akpm-current tree still had its build failures for which I applied 2 patches. Non-merge commits (relative to Linus' tree):

Re: [RFC PATCH 0/6] UART slave devices using serio

Hi, On Tue, Oct 25, 2016 at 05:02:23PM -0500, Rob Herring wrote: > On Tue, Oct 25, 2016 at 4:55 PM, Sebastian Reichel wrote: > > On Wed, Aug 24, 2016 at 06:24:30PM -0500, Rob Herring wrote: > >> [...] > > I had a more detailed look at the series during the last two weeks. > > For me the approach l

[PATCH v2 5/5] posix-timers: make it configurable

Some embedded systems have no use for them. This removes about 22KB from the kernel binary size when configured out. Corresponding syscalls are routed to a stub logging the attempt to use those syscalls which should be enough of a clue if they were disabled without proper consideration. They are:

[PATCH v2 3/5] kconfig: regenerate *.c_shipped files after previous changes

Signed-off-by: Nicolas Pitre --- scripts/kconfig/zconf.hash.c_shipped | 228 ++--- scripts/kconfig/zconf.tab.c_shipped | 1631 -- 2 files changed, 888 insertions(+), 971 deletions(-) diff --git a/scripts/kconfig/zconf.hash.c_shipped b/scripts/kconfig/zconf.hash

[PATCH v2 1/5] kconfig: introduce the "imply" keyword

The "imply" keyword is a weak version of "select" where the target config symbol can still be turned off, avoiding those pitfalls that come with the "select" keyword. This is useful e.g. with multiple drivers that want to indicate their ability to hook into a given subsystem while still being able

Re: [PATCH -next 1/2] Input: synaptics-rmi4 - add support for F55 sensor tuning

On 10/25/2016 11:26 AM, Andrew Duggan wrote: On 10/24/2016 08:13 PM, Guenter Roeck wrote: Hi Andrew, On 10/24/2016 05:59 PM, Andrew Duggan wrote: Hi Guenter, I have a couple of comments below. Thanks a lot for the feedback. On 09/30/2016 08:22 PM, Guenter Roeck wrote: Sensor tuning supp

[PATCH] Change the document about iowait

The iowait is not reliable by reading from /proc/stat, so this method to get iowait is not suggested. And we mark it in the document. Signed-off-by: Cao Jin Signed-off-by: Chao Fan --- Documentation/filesystems/proc.txt | 11 ++- 1 file changed, 10 insertions(+), 1 deletion(-) diff --g

Re: [PATCH] ARM: imx6: Fix GPC probe error path

On 10/25/2016 10:34 AM, Guenter Roeck wrote: GPC may fail to instantiate with imx-gpc: probe of 20dc000.gpc failed with error -22 which is returned from of_genpd_add_provider_onecell(). The error path does not call pm_genpd_remove(). This results in the following crash later on. Unhandled faul

Re: [PATCH -next] unicore32: Fix build error

> Since the oldabi syscall interface was first introduced, the > infrastructure > changed and the patch no longer compiles. See commit f56141e3e2d9a ("all > arches, signal: move restart_block to struct task_struct") for details. > > Fixes: 1ace5d1e3d4b4 ("unicore32-oldabi: add oldabi syscall interf

[PATCH v2 4/5] ptp_clock: allow for it to be optional

In order to break the hard dependency between the PTP clock subsystem and ethernet drivers capable of being clock providers, this patch provides simple PTP stub functions to allow linkage of those drivers into the kernel even when the PTP subsystem is configured out. Drivers must be ready to accept

[no subject]

From: Nicolas Pitre Subject: [PATCH v2 0/5] make POSIX timers optional with some Kconfig help Many embedded systems don't need the full POSIX timer support. Configuring them out provides a nice kernel image size reduction. When POSIX timers are configured out, the PTP clock subsystem should be l

[PATCH v2 2/5] kconfig: introduce the "suggest" keyword

Similar to "imply" but with no added restrictions on the target symbol's value. Useful for providing a default value to another symbol. Suggested by Edward Cree. Signed-off-by: Nicolas Pitre --- Documentation/kbuild/kconfig-language.txt | 6 ++ scripts/kconfig/expr.h|

[PATCH v2] staging: vc04_services: Replace dmac_map_area with dmac_map_sg

The original arm implementation uses dmac_map_area which is not portable. Replace it with an architecture neutral version which uses dma_map_sg. As you can see that for larger page sizes, the dma_map_sg implementation is faster then the original unportable dma_map_area implementation. Test

Re: [LKP] [lkp] [perf powerpc] 18d1796d0b: [No primary change]

Peter Zijlstra writes: > On Tue, Oct 25, 2016 at 02:40:13PM +0800, kernel test robot wrote: >> [will-it-scale] perf-stat.branch-miss-rate +7.4% regression >> Reply-To: kernel test robot >> User-Agent: Heirloom mailx 12.5 6/20/10 >> >> >> FYI, we noticed a +7.4% regression of perf-stat.branch-

Re: [PATCH] irqchip/gic: Enable gic_set_affinity set more than one cpu

on 10/25/2016 06:09 PM, Marc Zyngier wrote: > On 15/10/16 08:23, Cheng Chao wrote: >> On 10/15/2016 01:33 AM, Marc Zyngier wrote: on 10/13/2016 11:31 PM, Marc Zyngier wrote: > On Thu, 13 Oct 2016 18:57:14 +0800 > Cheng Chao wrote: > >> GIC can distribute an interrupt to more

[PATCH] include/linux/rtmutex.h: NOOP rt_mutex_destroy if !CONFIG_DEBUG_RT_MUTEXES

mutex_destroy is no-op inline when DEBUG_MUTEX is not enabled. When mutex_destroy is indirectly used by non-GPL kernel modules that use inline functions such as reservation_object_fini(), users can use a kernel with DEBUG_MUTEX disabled to avoid a dependence on the GPL-only symbol mutex_destroy. T

[RFC] HID:hid-lg4ff: Delay to allow wheels to center after plug-in

A number of wheels (G27/etc) do a little full right/full left 'dance' when first plugged in. This patch inserts a delay so that this 'dance' is completed before we disable (set to zero) the autocenter spring. A side benefit is that the DFGT was confused without the delay, and is now correctly bein

Re: [RFC][PATCH v2] mount: In propagate_umount handle overlapping mount propagation trees

Andrei Vagin writes: > On Tue, Oct 25, 2016 at 04:45:44PM -0500, Eric W. Biederman wrote: >> That is certainly interesting. The problem is that the reason we were >> going slow is that there were in fact mounts that had not been traversed >> in the share group. > > You are right. > >> >> And in

Re: bio linked list corruption.

On Tue, Oct 25, 2016 at 6:33 PM, Linus Torvalds wrote: > > Completely untested. Maybe there's some reason we can't write to the > whole thing like that? That hack boots and seems to work for me, but doesn't show anything. Dave, mind just trying that oneliner? Linus

Re: taint/module: Clean up global and module taint flags handling

Jiri Kosina writes: > On Fri, 23 Sep 2016, Jessica Yu wrote: > >> Hm, quick question, which tree would this patch go to? Though the >> cleanup is for modules, there is an indirect cross-tree dependency >> (taint_flag.module needs to be true for TAINT_LIVEPATCH for Josh's >> patch to still work as

Re: [RFC PATCH 1/2] module: Ensure a module's state is set accordingly during module coming cleanup code

Aaron Tomlin writes: > In load_module() in the event of an error, for e.g. unknown module > parameter(s) specified we go to perform some module coming clean up > operations. At this point the module is still in a "formed" state > when it is actually going away. > > This patch updates the module's

Re: [RFC PATCH 2/2] module: When modifying a module's text ignore modules which are going away too

Aaron Tomlin writes: > By default, during the access permission modification of a module's core > and init pages, we only ignore modules that are malformed. There is no > reason not to extend this to modules which are going away too. Well, it depends on all the callers (ie. ftrace): is that also

Re: bio linked list corruption.

On Tue, Oct 25, 2016 at 5:27 PM, Dave Jones wrote: > > DaveC: Do these look like real problems, or is this more "looks like > random memory corruption" ? It's been a while since I did some stress > testing on XFS, so these might not be new.. Andy, do you think we could just do some poisoning of

Re: [RFC PATCH] PCI/ACPI: xgene: Add ECAM quirk for X-Gene PCIe controller

On Wed, Sep 21, 2016 at 2:22 PM, Bjorn Helgaas wrote: > On Mon, Sep 19, 2016 at 06:07:37PM -0700, Duc Dang wrote: >> On Mon, Sep 19, 2016 at 1:06 PM, Bjorn Helgaas wrote: >> > On Sat, Sep 17, 2016 at 07:24:38AM -0700, Duc Dang wrote: > >> This patch only adds the ability for X-Gene PCIe controlle

[RFC PATCH v2 1/1] PCI/ACPI: xgene: Add ECAM quirk for X-Gene PCIe controller

PCIe controllers in X-Gene SoCs is not ECAM compliant: software needs to configure additional controller's register to address device at bus:dev:function. This patch depends on "ECAM quirks handling for ARM64 platforms" series (http://www.spinics.net/lists/arm-kernel/msg530692.html, the series was

  1   2   3   4   5   6   7   8   9   >