[PATCH V5 2/4] coresight: adding path for STM device

From: Mathieu Poirier >From a core framework point of view an STM device is a source that is treated the same way as any other tracers. Unlike tracers though STM devices are not associated with a CPU. As such it doesn't make sense to associate the path from an STM

[PATCH V5 1/4] stm class: Support devices that override software assigned masters

From: Alexander Shishkin Some STM devices adjust software assigned master numbers depending on the trace source and its runtime state and whatnot. This patch adds a sysfs attribute to inform the trace-side software that master numbers assigned to software

[PATCH V5 3/4] coresight-stm: Bindings for System Trace Macrocell

From: Mathieu Poirier The System Trace Macrocell (STM) is an IP block falling under the CoreSight umbrella. It's main purpose it so expose stimulus channels to any system component for the purpose of information logging. Bindings for this IP block adds a couple of

[PATCH V5 4/4] coresight-stm: adding driver for CoreSight STM component

From: Pratik Patel This driver adds support for the STM CoreSight IP block, allowing any system compoment (HW or SW) to log and aggregate messages via a single entity. The CoreSight STM exposes an application defined number of channels called stimulus port.

[PATCH V5 0/4] Introduce CoreSight STM support

This patchset adds support for the CoreSight STM IP block. Changes from V4: - Rebased the whole patch set onto [4] (v4.6-rc1). - Made a few minor modifications according to the code changes since v4.5. - Replaced the original 1/4 with a new patch the Alex provided. - Another new patch 2/4 in

[PATCH] Documentation: clk: update file names containing referenced structures

Commit 'b09d6d991' removes include/linux/clk-private.h and re-arranges the clock related structures contained in it in different files. The documentation has not been updated accordingly, thus it wasn't anymore consistent. Place the structures referenced by Documentation/clk.txt in the correct

Re: [PATCH] Prefer kASLR over Hibernation

* Rafael J. Wysocki wrote: > [...] > > One of the weak points is the final jump, because it has to be done to the > physical location of the image kernel's entry point even though the virtual > addresses of it may differ between the boot and the image kernels. The seed >

Re: [PATCH] Prefer kASLR over Hibernation

* Kees Cook wrote: > >> I don't think this is a good idea, as it turns off emergency hibernation > >> of > >> laptops - many desktop distros support it by default. > > > > Right, I forgot about this one. > > When I last checked Ubuntu doesn't enable hibernation by

Re: [PATCH] Prefer kASLR over Hibernation

On wo, 2016-04-06 at 15:16 -0700, Kees Cook wrote: > And it seems like Fedora either doesn't either, or has a lot of people > for whom it doesn't work: > https://bugzilla.redhat.com/show_bug.cgi?id=1206936 > https://bugzilla.redhat.com/show_bug.cgi?id=1224151 >

Re: [PATCH] Prefer kASLR over Hibernation

On Wed, Apr 6, 2016 at 3:04 PM, Rafael J. Wysocki wrote: > On Wed, Apr 6, 2016 at 11:56 PM, Ingo Molnar wrote: >> >> * Rafael J. Wysocki wrote: >> >>> On Wed, Apr 6, 2016 at 9:44 PM, Kees Cook wrote: >>> > When

Re: [PATCH 0/2] memory_hotplug: introduce config and command line options to set the default onlining policy

On Wed, 6 Apr 2016, Andrew Morton wrote: > > This patchset continues the work I started with: > > > > commit 31bc3858ea3ebcc3157b3f5f0e624c5962f5a7a6 > > Author: Vitaly Kuznetsov > > Date: Tue Mar 15 14:56:48 2016 -0700 > > > > memory-hotplug: add automatic onlining

Re: [PATCH] Prefer kASLR over Hibernation

On Wed, Apr 6, 2016 at 11:56 PM, Ingo Molnar wrote: > > * Rafael J. Wysocki wrote: > >> On Wed, Apr 6, 2016 at 9:44 PM, Kees Cook wrote: >> > When building with both CONFIG_HIBERNATION and CONFIG_RANDOMIZE_BASE, >> > one or the other

Re: [PATCH] Prefer kASLR over Hibernation

* Rafael J. Wysocki wrote: > On Wed, Apr 6, 2016 at 9:44 PM, Kees Cook wrote: > > When building with both CONFIG_HIBERNATION and CONFIG_RANDOMIZE_BASE, > > one or the other must be chosen at boot-time. Until now, hibernation > > was selected when no

Re: [PATCH] Prefer kASLR over Hibernation

* Ingo Molnar wrote: > > * Kees Cook wrote: > > > On Wed, Apr 6, 2016 at 1:56 PM, Linus Torvalds > > wrote: > > > On Wed, Apr 6, 2016 at 1:17 PM, Pavel Machek wrote: > > >> > > >> Why is kASLR

Re: [PATCH] Prefer kASLR over Hibernation

On Wed, Apr 6, 2016 at 9:44 PM, Kees Cook wrote: > When building with both CONFIG_HIBERNATION and CONFIG_RANDOMIZE_BASE, > one or the other must be chosen at boot-time. Until now, hibernation > was selected when no choice was made on the command line. > > To make the

Re: [PATCH] Prefer kASLR over Hibernation

* Kees Cook wrote: > On Wed, Apr 6, 2016 at 1:56 PM, Linus Torvalds > wrote: > > On Wed, Apr 6, 2016 at 1:17 PM, Pavel Machek wrote: > >> > >> Why is kASLR incompatible with hibernation? We can hibernate have > >> 4.3 kernel

Re: [PATCH 1/7] cpufreq: remove redundant CPUFREQ_INCOMPATIBLE notifier event

On Wed, Apr 6, 2016 at 11:29 PM, Saravana Kannan wrote: > On 04/06/2016 02:21 PM, Rafael J. Wysocki wrote: >> >> On Wed, Apr 6, 2016 at 10:30 PM, Saravana Kannan >> wrote: >>> >>> On 09/09/2015 05:53 PM, Rafael J. Wysocki wrote: [cut] >> >>

Re: [PATCH 1/7] cpufreq: remove redundant CPUFREQ_INCOMPATIBLE notifier event

On 04/06/2016 02:21 PM, Rafael J. Wysocki wrote: On Wed, Apr 6, 2016 at 10:30 PM, Saravana Kannan wrote: On 09/09/2015 05:53 PM, Rafael J. Wysocki wrote: Hi, On Thu, Sep 10, 2015 at 2:39 AM, Viresh Kumar wrote: On 10-09-15, 01:26, Rafael

Re: [PATCH] Prefer kASLR over Hibernation

On Wed, Apr 6, 2016 at 1:56 PM, Linus Torvalds wrote: > On Wed, Apr 6, 2016 at 1:17 PM, Pavel Machek wrote: >> >> Why is kASLR incompatible with hibernation? We can hibernate have >> 4.3 kernel resume hibernation image of 4.2 kernel (on x86-64, and I

Re: [PATCH] Prefer kASLR over Hibernation

On Wed, Apr 6, 2016 at 1:17 PM, Pavel Machek wrote: > > Why is kASLR incompatible with hibernation? We can hibernate have > 4.3 kernel resume hibernation image of 4.2 kernel (on x86-64, and I > have patches for x86). Resuming kernel with different randomization > does not look that

Re: [PATCH] Prefer kASLR over Hibernation

Hi! > When building with both CONFIG_HIBERNATION and CONFIG_RANDOMIZE_BASE, > one or the other must be chosen at boot-time. Until now, hibernation > was selected when no choice was made on the command line. > > To make the security benefits of kASLR more widely available to end > users (since

Re: [PATCH 0/2] memory_hotplug: introduce config and command line options to set the default onlining policy

On Wed, 6 Apr 2016 15:45:10 +0200 Vitaly Kuznetsov wrote: > This patchset continues the work I started with: > > commit 31bc3858ea3ebcc3157b3f5f0e624c5962f5a7a6 > Author: Vitaly Kuznetsov > Date: Tue Mar 15 14:56:48 2016 -0700 > >

Re: [PATCH 1/3] iio: core: Add devm_ APIs for iio_channel_{get,release}

Hi Daniel, On Wednesday 06 April 2016 07:19 PM, Daniel Baluta wrote: On Wed, Apr 6, 2016 at 1:31 PM, Laxman Dewangan wrote: Some of kernel driver uses the IIO framework to get the sensor value via ADC or IIO HW driver. The client driver get iio channel by

Re: [RFC v5 7/7] vfio-pci: Allow to mmap MSI-X table if interrupt remapping is supported

On Tue, 5 Apr 2016 21:46:44 +0800 Yongji Xie wrote: > This patch enables mmapping MSI-X tables if > hardware supports interrupt remapping which > can ensure that a given pci device can only > shoot the MSIs assigned for it. > > Signed-off-by: Yongji Xie

[PATCH 1/2] memory_hotplug: introduce CONFIG_MEMORY_HOTPLUG_DEFAULT_ONLINE

Introduce config option to set the default value for memory hotplug onlining policy (/sys/devices/system/memory/auto_online_blocks). The reason one would want to turn this option on are to have early onlining for hotpluggable memory available at boot and to not require any userspace actions to

[PATCH 0/2] memory_hotplug: introduce config and command line options to set the default onlining policy

This patchset continues the work I started with: commit 31bc3858ea3ebcc3157b3f5f0e624c5962f5a7a6 Author: Vitaly Kuznetsov Date: Tue Mar 15 14:56:48 2016 -0700 memory-hotplug: add automatic onlining policy for the newly added memory Initially I was going to stop there

Re: [RFC6 PATCH v6 00/21] ILP32 for ARM64

Hi Geert, On Wed, Apr 06, 2016 at 08:51:50AM +0200, Geert Uytterhoeven wrote: > Hi Yuri, > > On Wed, Apr 6, 2016 at 12:08 AM, Yury Norov wrote: > > This version is rebased on kernel v4.6-rc2, and has fixes in signal > > subsystem. > > It works with updated glibc [1]

[PATCH 2/3] iio: core: Add devm_ APIs for iio_channel_{get,release}_all

Some of kernel driver uses the IIO framework to get the sensor value via ADC or IIO HW driver. The client driver get iio channel by iio_channel_get_all() and release it by calling iio_channel_release_all(). Add resource managed version (devm_*) of these APIs so that if client calls the

[PATCH 3/3] iio: Add resource managed APIs devm_iio_channel_{get,release) in devres

Add following APIs in the list of managed resources of IIO: devm_iio_channel_get() devm_iio_channel_get_all() devm_iio_channel_release() devm_iio_channel_release_all() Signed-off-by: Laxman Dewangan --- Documentation/driver-model/devres.txt

Re: [PATCH] ARM: kexec: fix crashkernel= handling

On 04/01/16 at 02:25pm, Russell King - ARM Linux wrote: [snip] > Well, if we want to remove it, we then need to sort out a method of > specifying a limit on the address - where platforms physical memory > bridges the 4GB CPU-accessible limit, the crashkernel region must be > allocated below that

Re: [RFC6 PATCH v6 00/21] ILP32 for ARM64

Hi Yuri, On Wed, Apr 6, 2016 at 12:08 AM, Yury Norov wrote: > This version is rebased on kernel v4.6-rc2, and has fixes in signal subsystem. > It works with updated glibc [1] (though very draft), and tested with LTP. > > It was tested on QEMU and ThunderX machines. No