> On Thu, Sep 24, 2015 at 07:47:40PM +, Liang, Kan wrote:
> >
> >
> > > On Tue, Sep 22, 2015 at 10:13:33AM -0400, kan.li...@intel.com wrote:
> > > > From: Kan Liang
> > > >
> > > > The patch series intends to read counter statistics with fixed
> > > > frequency during sampling. The instant
I am announcing the release of the Linux 3.19.8-ckt7 kernel.
The updated 3.19.y-ckt tree can be found at:
git://kernel.ubuntu.com/ubuntu/linux.git linux-3.19.y
and can be browsed at:
http://kernel.ubuntu.com/git/ubuntu/linux.git/log/?h=linux-3.19.y
The diff from v3.19.8-ckt6 is posted as
Paolo Bonzini writes:
> On 24/09/2015 17:45, Bandan Das wrote:
>> > However, I have applied the patch to kvm/queue. Please send the changes
>> > separately, and I will squash them in the existing VPID patch.
>>
>> Please don't do this. It's making it really difficult to review these
>> patches
From: Julien Grall
This typedef is a left-over of the previous MMIO emulation
implementation.
Signed-off-by: Julien Grall
---
Changes in v2:
- Patch added
---
xen/include/asm-arm/mmio.h | 1 -
1 file changed, 1 deletion(-)
diff --git a/xen/include/asm-arm/mmio.h
The guest may try to load data from the emulated MMIO region using
instruction with Sign-Extension (i.e ldrs*). This can happen for any
access smaller than the register size (byte/half-word for aarch32,
byte/half-word/word for aarch64).
The support of sign-extension was limited for byte access in
Please ignore this version, I've sent it to the wrong mailing list.
Sorry for the noise.
On 25/09/15 15:50, Julien Grall wrote:
> Hi all,
>
> This series aims to fix the 32-bit access on 64-bit register. Some guest
> OS such as FreeBSD and Linux (only in the ITS) use 32-bit access and will
>
From: Julien Grall
Rather than letting each handler to retrieve the register used by the
I/O access, add a new parameter to pass the register in parameter.
This will help to implement generic register manipulation on I/O access
such as sign-extension and endianess.
Read handlers need to modify
Based on 8.1.3 (IHI 0069A), unless stated otherwise, the 64-bit registers
supports both 32-bit and 64-bits access.
All the registers we properly emulate (i.e not RAZ/WI) supports 32-bit access.
For RAZ/WI, it's also seems to be the case but I'm not 100% sure. Anyway,
emulating 32-bit access for
Xen is currently directly storing the value of register GICD_ITARGETSR
(for GICv2) and GICD_IROUTER (for GICv3) in the rank. This makes the
emulation of the registers access very simple but makes the code to get
the target vCPU for a given IRQ more complex.
While the target vCPU of an IRQ is
Xen is currently directly storing the value of register GICD_IPRIORITYR
in the rank. This makes emulation of the register access very simple
but makes the code to get the priority for a given IRQ more complex.
While the priority of an IRQ is retrieved everytime an IRQ is injected
to the guest,
and use them in the vGIC emulation.
The GIC registers may support different access sizes. Rather than open
coding the access for every registers, provide a set of helpers to access
them.
The caller will have to call vgic_regN_* where N is the size of the
emulated registers.
The new helpers
Signed-off-by: Julien Grall
---
Changes in v2:
- Patch added
---
xen/include/asm-arm/domain.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/xen/include/asm-arm/domain.h b/xen/include/asm-arm/domain.h
index c3f5a95..1a5bfd7 100644
---
Hi all,
This series aims to fix the 32-bit access on 64-bit register. Some guest
OS such as FreeBSD and Linux (only in the ITS) use 32-bit access and will
crash at boot time.
I took the opportunity to go further and optimize the way Xen is storing
registers such as GICD_IPRIORITYR, GICD_ITARGETR
On 09/24/2015 10:54 AM, Murali Karicheri wrote:
[...]
> ti,omap3 is the family of omap3 devices similar to keystone. ti,omap3450
> is required if there is an exceptional treatment required for ti,omap3450.
>
> In keystone case so far there is no case of exceptional treatment
> required in the
From: Scott Wood
> Sent: 24 September 2015 21:14
> > Isn't this a more general problem?
> >
> > If there are multiple remap requests for the same physical page
> > shouldn't the kernel be just increasing a reference count somewhere
> > and returning address in the same virtual page?
> > This
On Tue, 2015-09-15 at 17:31 +0300, Irina Tirdea wrote:
> Goodix devices can be configured by writing custom data to the device
> at
> init. The configuration data is read with request_firmware from
> "goodix__cfg.bin", where is the product id read from the
> device
> (e.g.: goodix_911_cfg.bin for
On Fri, Sep 25, 2015 at 01:15:56PM +0200, Jiri Kosina wrote:
> From: Jiri Kosina
>
> In many cases of hardlockup reports, it's actually not possible to know
> why it triggered, because the CPU that got stuck is usually waiting on a
> resource (with IRQs disabled) in posession of some other CPU
On Thu, 2015-09-10 at 14:04 +, Tirdea, Irina wrote:
>
> > -Original Message-
> > From: Bastien Nocera [mailto:had...@hadess.net]
> > Sent: 09 September, 2015 20:03
> > To: Tirdea, Irina; linux-in...@vger.kernel.org
> > Cc: linux-kernel@vger.kernel.org; Rob Herring; Pawel Moll; Ian
> >
Liviu Dudau writes:
> On Tue, Sep 15, 2015 at 05:51:01PM +0100, Punit Agrawal wrote:
>> The SCP firmware on Juno provides access to SoC sensors via the
>> SCPI. Add the sensor nodes to the device tree to enable this support.
>>
>> Signed-off-by: Punit Agrawal
>> Cc: Rob Herring
>> Cc: Mark
On Thu, Sep 24, 2015 at 09:35:20PM -0700, Yinghai Lu wrote:
> On Thu, Sep 24, 2015 at 12:01 PM, Yinghai Lu wrote:
>
> > Or do we want to keep a white list to say which device should have
> > ROM bar as mush have, and other is optional to have ?
>
> Subject: [RFC PATCH] PCI: Add
On Fri, 25 Sep 2015, Rafael J. Wysocki wrote:
> We are missing the "no remote wakeup" bit now (well, there is a PM QoS flag,
> but it isn't very useful, so I'd prefer to replace it with a "no remote
> wakeup"
> bit in struct dev_pm_info or something similar).
>
> That is actually quite
On Thu, Sep 24, 2015 at 07:02:36PM +0200, Thierry Reding wrote:
> From: Thierry Reding
>
> Some modules register several sub-drivers. Provide a helper that makes
> it easy to register and unregister a list of sub-drivers, as well as
> unwind properly on error.
>
> Cc: Greg Kroah-Hartman
>
On 09/23, Sasha Levin wrote:
>
> Another similar trace where we see a problem during process exit:
>
> [1922964.887922] kasan: GPF could be caused by NULL-ptr deref or user memory
> accessgeneral protection fault: [#1] PREEMPT SMP DEBUG_PAGEALLOC KASAN
> [1922964.890234] Modules linked in:
>
On Thu, Sep 24, 2015 at 09:16:01PM -0400, Benjamin Tissoires wrote:
> > diff --git a/drivers/hid/hid-multitouch.c b/drivers/hid/hid-multitouch.c
> > index 426b2f1a3450..1911f7698511 100644
> > --- a/drivers/hid/hid-multitouch.c
> > +++ b/drivers/hid/hid-multitouch.c
> > @@ -1020,14 +1020,16 @@
Here's my patch with the changes squashed into it for reference.
David
---
commit 81852354cf81402ae69fda4d67138accab2702d5
Author: David Howells
Date: Thu Sep 24 14:06:02 2015 +0100
MODSIGN: Change from CMS to PKCS#7 signing if the openssl is too old
The sign-file.c program
On Fri, Sep 25, 2015 at 03:13:54PM +0200, Philipp Zabel wrote:
> Am Freitag, den 25.09.2015, 15:09 +0200 schrieb Philipp Zabel:
> > Am Freitag, den 25.09.2015, 14:17 +0200 schrieb Thierry Reding:
> > > I think you gain much less by splitting up than you realize. Compare
> > > this from before the
On Thu 27-08-15 10:46:37, mho...@kernel.org wrote:
> From: Michal Hocko
>
> It seems that skb_propagate_pfmemalloc has never had a user since it was
> introduced by 0614002bb5f7 ("netvm: propagate page->pfmemalloc from
> skb_alloc_page to skb"). Remove it.
>
> Signed-off-by: Michal Hocko
> ---
Le Friday 25 September 2015 à 14:37 +0100, Matt Fleming a écrit :
> On Fri, 25 Sep, at 09:36:10AM, Jean Delvare wrote:
> > On Wed, 12 Aug 2015 08:42:18 -0700, Jim Davis wrote:
> > > Building with the attached random configuration file,
> > >
> > > drivers/built-in.o: In function
On Fri, Sep 25, 2015 at 11:59:52AM +0200, Vitaly Kuznetsov wrote:
> Currently there is a number of issues preventing PVHVM Xen guests from
> doing successful kexec/kdump:
> - Bound event channels.
> - Registered vcpu_info.
> - PIRQ/emuirq mappings.
> - shared_info frame after
On Fri, Sep 25, 2015 at 01:50:28PM +0100, Mel Gorman wrote:
> On Thu, Sep 24, 2015 at 04:34:45PM -0400, Johannes Weiner wrote:
> > On Mon, Sep 21, 2015 at 11:52:36AM +0100, Mel Gorman wrote:
> > > @@ -14,7 +14,7 @@ struct vm_area_struct;
> > > #define ___GFP_HIGHMEM 0x02u
> > > #define
_fdget()
* update description
* rebase to next-20150925
* fix conflict with mlock2
---
arch/x86/entry/syscalls/syscall_32.tbl |1 +
arch/x86/entry/syscalls/syscall_64.tbl |1 +
include/linux/syscalls.h |1 +
include/uapi/asm-generic/unistd.h |4 ++-
kernel
New helper function returns pointer to struct ns_common, can check
namespace type and uses struct fd for returning file reference:
this saves couple atomic operations for single-threaded applications.
Signed-off-by: Konstantin Khlebnikov
---
fs/nsfs.c| 20 +---
The regulator-compatible property from the regulator DT binding was
deprecated and the correct approach is to use the node's name.
This patch has no functional changes since the values of the node's
name and the regulator-compatible match for all the regulators.
Signed-off-by: Javier Martinez
The regulator-compatible property from the regulator DT binding was
deprecated and the correct approach is to use the node's name.
This patch has no functional changes since the values of the node's
name and the regulator-compatible match for all the regulators.
Signed-off-by: Javier Martinez
Em Thu, Sep 24, 2015 at 01:05:20PM +0300, Adrian Hunter escreveu:
> Hi
>
> Here are a couple of urgent fixes for v4.3.
>
> The "Fix copying of /proc/kcore" problem goes back to v3.13
> if you think it is important enough for stable.
I added a Cc: sta...@kernel.org and your notes to the commit
The regulator-compatible property from the regulator DT binding was
deprecated and the correct approach is to use the node's name.
This patch has no functional changes since the values of the node's
name and the regulator-compatible match for all the regulators.
Signed-off-by: Javier Martinez
On Thu, Sep 24, 2015 at 01:12:48PM +0300, Tomi Valkeinen wrote:
>
> On 18/09/15 14:16, Sudip Mukherjee wrote:
> > On the error path we have missed releasing the firmware.
> >
> > Signed-off-by: Sudip Mukherjee
> > ---
>
> This looks like correct fix, but where is the firmware released when
>
The regulator-compatible property from the regulator DT binding was
deprecated and the correct approach is to use the node's name.
This patch has no functional changes but by not using a deprecated
property, new DTS based on this one will not carry the same issue.
Signed-off-by: Javier Martinez
On Thu, Sep 24, 2015 at 02:58:31PM +0300, Tomi Valkeinen wrote:
>
> On 02/09/15 15:48, Sudip Mukherjee wrote:
>
>
> Is there a public datasheet for the HW?
I could not find one in Silicon Motion website. I will try to find else
I can talk to them and keep it in my github. And can send you also
On Fri, 25 Sep, at 09:36:10AM, Jean Delvare wrote:
> On Wed, 12 Aug 2015 08:42:18 -0700, Jim Davis wrote:
> > Building with the attached random configuration file,
> >
> > drivers/built-in.o: In function `dmi_check_onboard_devices':
> > i2c-i801.c:(.text+0x126b36): undefined reference to
Linus,
please pull sound fixes for v4.3-rc3 from:
git://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound.git
tags/sound-4.3-rc3
The topmost commit is 7f57d803ee03730d570dc59a9e3e4842b58dd5cc
sound fixes for 4.3-rc3
This
On 09/23/2015 01:37 PM, Murali Karicheri wrote:
This patch series fixes a set of issues in netcp driver seen during internal
testing of the driver. While at it, do some clean up as well.
The fixes are tested on K2HK, K2L and K2E EVMs and the boot up logs can be
seen at
System: 4.1.0-0.bpo.2-rt-amd64 #1 SMP PREEMPT RT Debian 4.1.6-1~bpo8+1
(2015-09-09) x86_64 GNU/Linux
Dieharder: 3.31.1-4 (debian wheezy amd64)
Commandline: dieharder -d 8 -g NN -Y 2 -k 2 < /dev/urandom
(test is 'diehard_count_1s_str')
AES_OFB (-g 205): ran to psamples=10, final
On Thu, Sep 24, 2015 at 10:35 PM, Yinghai Lu wrote:
> On Thu, Sep 24, 2015 at 12:01 PM, Yinghai Lu wrote:
>
>> Or do we want to keep a white list to say which device should have
>> ROM bar as mush have, and other is optional to have ?
I suppose this idea is one possible outcome that could occur
Hi Linus,
These are fixes for things we merged for v4.3 (VPD, MSI, and bridge window
management), and a new Renesas R8A7794 SoC device ID.
Bjorn
The following changes since commit 6ff33f3902c3b1c5d0db6b1e2c70b6d76fba357f:
Linux 4.3-rc1 (2015-09-12 16:35:56 -0700)
are available in the git
On Wed 05-08-15 15:01:25, Vlastimil Babka wrote:
> From: Jerome Marchand
>
> It's currently inconvenient to retrieve MM_ANONPAGES value from status
> and statm files and there is no way to separate MM_FILEPAGES and
> MM_SHMEMPAGES. Add VmAnon, VmFile and VmShm lines in /proc//status
> to solve
On Friday, September 25, 2015 06:42:41 AM Chen, Yu C wrote:
> Hi,Rafael, thanks a lot for your review, will resend v2 version.
>
> > -Original Message-
> > From: Rafael J. Wysocki [mailto:r...@rjwysocki.net]
> > Sent: Friday, September 25, 2015 9:24 AM
> > To: Chen, Yu C
> > Cc: Wysocki,
Hi
Here are some minor improvements to Intel PT related stuff.
First 3 patches are minor fixes:
perf auxtrace: Fix 'instructions' period of zero
perf report: Fix sample type validation for synthesized callchains
perf intel-pt: Fix potential loop forever
Next 4 are minor
Processing instruction tracing data (e.g. Intel PT) can synthesize
callchains e.g.
$ perf record -e intel_pt//u uname
$ perf report --stdio --itrace=ige
However perf report's callgraph option gets extra validation, so:
$ perf report --stdio --itrace=ige -gflat
On Wed 05-08-15 15:01:24, Vlastimil Babka wrote:
> From: Jerome Marchand
>
> Currently looking at /proc//status or statm, there is no way to
> distinguish shmem pages from pages mapped to a regular file (shmem
> pages are mapped to /dev/zero), even though their implication in
> actual memory use
Instruction tracing options (i.e. --itrace) include an option for
sampling instructions at an arbitrary period. e.g.
--itrace=i10us
means make an 'instructions' sample for every 10us of trace.
Currently the logic does not distinguish between a period of
zero and no period being
The branch stack feature flag is set by 'perf record' when recording
data that contains branch stacks. Consequently, when 'perf inject'
synthesizes branch stacks, the feature flag should be set also.
Signed-off-by: Adrian Hunter
---
tools/perf/builtin-inject.c | 6 +-
1 file changed, 5
Logging is only used for debugging. Use macros to save
calling into the functions only to return immediately
when logging is not enabled.
Signed-off-by: Adrian Hunter
---
tools/perf/util/intel-pt-decoder/intel-pt-log.c | 21 +++---
tools/perf/util/intel-pt-decoder/intel-pt-log.h | 38
perf report looks at event sample types to determine if branch stacks have
been sampled. Adjust the validation to know about instruction tracing
options.
This change allows the use of the -b option which otherwise would complain
with an error like:
Error:
Selected -b but no
perf report will default to displaying branch stacks (-b option) if they
are present. Make that also happen for synthesized branch stacks.
Signed-off-by: Adrian Hunter
---
tools/perf/builtin-report.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/tools/perf/builtin-report.c
TSC packets contain only 7 bytes of TSC. The 8th byte is assumed
to change so infrequently that its value can be inferred. However
the logic must cater for a 7 byte wraparound, which it does by
adding 1 to the top byte.
The existing code was doing that with a while loop even though the
addition
Add some comments to the script and some 'views' to the created
database that better illustrate the database structure and how it
can be used.
Signed-off-by: Adrian Hunter
---
tools/perf/scripts/python/export-to-postgresql.py | 221 ++
1 file changed, 221 insertions(+)
diff
Add option --ns to display time to 9 decimal places.
That is useful in some cases, for example when using
Intel PT cycle accurate mode.
Signed-off-by: Adrian Hunter
---
tools/perf/Documentation/perf-script.txt | 3 +++
tools/perf/builtin-script.c | 8 +++-
2 files changed, 10
Use the max_stack value instead of PERF_MAX_STACK_DEPTH so that
arbitrary-sized callchains can be supported.
Signed-off-by: Adrian Hunter
---
tools/perf/util/hist.c | 6 --
tools/perf/util/hist.h | 1 +
2 files changed, 5 insertions(+), 2 deletions(-)
diff --git a/tools/perf/util/hist.c
Adjust the validation to allow for max_stack greater than
PERF_MAX_STACK_DEPTH.
Signed-off-by: Adrian Hunter
---
tools/perf/util/machine.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/tools/perf/util/machine.c b/tools/perf/util/machine.c
index fd1efeafb343..d7bd9a304535
intel_pt_synth_branch_sample() skips synthesizing if the branch
does not match the branch filter. That logic was sitting in the
middle of the function but is more efficiently placed at the
start of the function, so move it.
Signed-off-by: Adrian Hunter
---
tools/perf/util/intel-pt.c | 6 +++---
Add a setting for maximum stack depth in preparation for
allowing for synthesized callchains.
Signed-off-by: Adrian Hunter
---
tools/perf/builtin-script.c | 6 --
tools/perf/util/session.c | 2 +-
2 files changed, 5 insertions(+), 3 deletions(-)
diff --git a/tools/perf/builtin-script.c
Add support for generating branch stack context for PT samples.
The decoder reports a configurable number of branches as branch
context for each sample. Internally it keeps track of them by
using a simple sliding window. We also flush the last branch
buffer on each sample to avoid overlapping
perf_evlist__id2evsel_strict() is the same as perf_evlist__id2evsel()
except that it ensures that the id must match.
This will be used by perf inject to find a specific evsel that is to
be deleted, hence the need to match exactly.
Signed-off-by: Adrian Hunter
---
tools/perf/util/evlist.c | 15
Add a counterpart to perf_evlist__add() that does the opposite
and deletes the evsel.
This will be used by perf inject to remove unwanted evsels.
Signed-off-by: Adrian Hunter
---
tools/perf/util/evlist.c | 8
tools/perf/util/evlist.h | 1 +
2 files changed, 9 insertions(+)
diff --git
Use the scripting_max_stack value to allow for values greater than
PERF_MAX_STACK_DEPTH.
Signed-off-by: Adrian Hunter
---
tools/perf/builtin-script.c| 2 +-
tools/perf/util/scripting-engines/trace-event-python.c | 2 +-
tools/perf/util/trace-event.h
perf script has a setting to set the maximum stack depth when processing
callchains. The setting defaults to the hard-coded maximum definition
PERF_MAX_STACK_DEPTH which is 127.
It is possible, when processing instruction traces, to synthesize
callchains. Synthesized callchains do not have the
autofdo incorrectly expects branch flags to include either mispred
or predicted. In fact mispred = predicted = 0 is valid and means
the flags are not supported, which they aren't by Intel PT.
To make autofdo work, add a config option which will cause Intel
PT decoder to set the mispred flag on
perf inject can process instruction traces (using the --itrace option)
which removes aux-related events and replaces them with the requested
synthesized events.
However there are still some leftovers, namely PERF_RECORD_ITRACE_START
events and the original evsel (selected event) e.g. intel_pt//
Add a new option --strip which is used with --itrace to strip out
non-synthesized events. This results in a perf.data file that is
simpler for external tools to parse. In particular, this can be used
to prepare a perf.data file for consumption by autofdo.
A subsequent patch makes a change to
perf report has an option (--max-stack) to set the maximum stack depth
when processing callchains. The option defaults to the hard-coded
maximum definition PERF_MAX_STACK_DEPTH which is 127. The intention of
the option is to allow the user to reduce the processing time by
reducing the amount of
By default perf record will postprocess the perf.data file
to determine build-ids. When that happens, the number of lost
perf events is displayed.
Make that also happen for AUX events.
Signed-off-by: Adrian Hunter
---
tools/perf/util/event.h | 1 +
tools/perf/util/session.c | 10 ++
A non-synthesized event might not have a branch stack if branch
stacks have been synthesized (using itrace options).
An example of that is when Intel PT records sched_switch events
for decoding purposes. Those sched_switch events do not have
branch stacks even though the Intel PT decoder may be
On Fri, Sep 25, 2015 at 3:13 PM, Jiri Kosina wrote:
> On Fri, 25 Sep 2015, Sedat Dilek wrote:
>
>> > The sequence looks correct. So I don't really see what call sequence could
>> > lead to calling flush_work() from __cancel_work_timer() with IRQs
>> > disabled (which is what your stacktrace is
Add AUX area tracing option 'l' to synthesize branch stacks on samples
just like sample type PERF_SAMPLE_BRANCH_STACK. This is taken into use
by Intel PT in a subsequent patch.
Based-on-patch-by: Andi Kleen
Signed-off-by: Adrian Hunter
---
tools/perf/Documentation/itrace.txt | 4
On Fri, 25 Sep 2015, Sedat Dilek wrote:
> > The sequence looks correct. So I don't really see what call sequence could
> > lead to calling flush_work() from __cancel_work_timer() with IRQs
> > disabled (which is what your stacktrace is suggesting).
> >
> > The fact that this doesn't happen with
On Fri, 2015-09-25 at 00:43 -0700, Greg Thelen wrote:
> Since commit 5cec38ac866b ("fs, seq_file: fallback to vmalloc instead of
> oom kill processes") seq_buf_alloc() avoids calling the oom killer for
> PAGE_SIZE or smaller allocations; but larger allocations can use the oom
> killer via
Am Freitag, den 25.09.2015, 15:09 +0200 schrieb Philipp Zabel:
> Am Freitag, den 25.09.2015, 14:17 +0200 schrieb Thierry Reding:
> > I think you gain much less by splitting up than you realize. Compare
> > this from before the series:
> >
> > $ du -ch drivers/gpu/drm/imx/*.ko
> > 8.0K
On 25/09/15 13:41, Kamil Lulko wrote:
> Hi,
>
>> fbdev is (more or less) maintained, but it's a deprecated framework. All
>> new Linux display drivers should be done on DRM.
>
> What about no-mmu platforms? DRM has a big fat MMU dependency in the
> kconfig, is there a way to write DRM driver
Am Freitag, den 25.09.2015, 14:17 +0200 schrieb Thierry Reding:
> I think you gain much less by splitting up than you realize. Compare
> this from before the series:
>
> $ du -ch drivers/gpu/drm/imx/*.ko
> 8.0Kdrivers/gpu/drm/imx/dw_hdmi-imx.ko
Oh right, I didn't realize that
From: Marc Titinger
Devices may register an intermediate retention state into the domain upon
attaching. Currently generic domain would register an array of states upon
init. This patch prepares for later insertion (sort per depth, remove).
Signed-off-by: Marc Titinger
---
From: Marc Titinger
This purpose of these debug seq-files is to help investigate
generic power domain state transitions, based on device constraints.
requires the "multiple states" patches from Axel Haslam.
also rename 'summary' from 'pm_genpd_summary'
sample output for 'states'
From: Marc Titinger
fake path to start testing, eventually move this out of /arch/.
incidently enable PM_GENERIC_DOMAINS for VExpress.
Signed-off-by: Marc Titinger
---
arch/arm/common/domains.c | 4 ++--
arch/arm64/Kconfig | 1 +
arch/arm64/include/asm/arm-pd.h | 1 +
---
Summary
1) DESCRIPTION
2) DEPENDENCIES
3) URL
1) DESCRIPTION
This patch set's underlying idea is that cluster-level c-states can be
managed
by the power domain, building upon Lina Iyers recent work on CPU-domain, and
Axel Haslam's
On 25/09/15 12:38, Dave P Martin wrote:
On Wed, Sep 16, 2015 at 03:21:05PM +0100, Suzuki K. Poulose wrote:
From: "Suzuki K. Poulose"
This patch adds an infrastructure to keep track of the CPU feature
registers on the system. For each register, the infrastructure keeps
track of the system wide
From: Marc Titinger
This patch allows cluster-level C-states to being soaked in as generic
domain power states, in order for the domain governor to chose the most
efficient power state compatible with the device constraints. Similarly,
devices can register power-states into the cluster domain,
From: Marc Titinger
This patch checks for irq-safe compatibility in suspend/resume instead of
failing the attach operation early on. Non-cpu devices attaching to an
irq-safe power domain will have to call pm_runtime_irq_safe from their
probe function.
Signed-off-by: Marc Titinger
---
On Tue, Sep 15, 2015 at 6:50 PM, Felipe Balbi wrote:
> Hi,
>
> On Tue, Sep 15, 2015 at 06:41:55PM +0200, Peter Senna Tschudin wrote:
>> On Tue, Sep 15, 2015 at 4:33 PM, Felipe Balbi wrote:
>> > On Mon, Sep 14, 2015 at 07:50:02PM +0200, Peter Senna Tschudin wrote:
>> >> On Mon, Sep 14, 2015 at
From: Marc Titinger
Cpuidle now handles c-states and power-states differently. c-states do not
decrement
the reference count for the CPUs in the cluster, while power-states i.e.
cluster level states like 'CLUSTER_SLEEP_0' in the case of juno, will.
The 'D1' fake device also registers
From: Marc Titinger
Signed-off-by: Marc Titinger
---
arch/arm64/boot/dts/arm/juno.dts | 19 +++
1 file changed, 19 insertions(+)
diff --git a/arch/arm64/boot/dts/arm/juno.dts b/arch/arm64/boot/dts/arm/juno.dts
index 342bb99..499f035 100644
---
[Sorry for a really long delay]
On Wed 05-08-15 15:01:23, Vlastimil Babka wrote:
> Currently, /proc/pid/smaps will always show "Swap: 0 kB" for shmem-backed
> mappings, even if the mapped portion does contain pages that were swapped out.
> This is because unlike private anonymous mappings, shmem
On Thu, Sep 24, 2015 at 04:14:33PM -0500, Eric W. Biederman wrote:
> Seth Forshee writes:
>
> > Initially this will be used to eliminate the implicit MNT_NODEV
> > flag for mounts from user namespaces. In the future it will also
> > be used for translating ids and checking capabilities for
> >
On Thu, Sep 24, 2015 at 04:55:09PM -0400, Johannes Weiner wrote:
> On Mon, Sep 21, 2015 at 11:52:37AM +0100, Mel Gorman wrote:
> > @@ -119,10 +134,10 @@ struct vm_area_struct;
> > #define GFP_USER (__GFP_WAIT | __GFP_IO | __GFP_FS | __GFP_HARDWALL)
> > #define GFP_HIGHUSER (GFP_USER |
On Thu, Sep 24, 2015 at 04:34:45PM -0400, Johannes Weiner wrote:
> On Mon, Sep 21, 2015 at 11:52:36AM +0100, Mel Gorman wrote:
> > @@ -14,7 +14,7 @@ struct vm_area_struct;
> > #define ___GFP_HIGHMEM 0x02u
> > #define ___GFP_DMA32 0x04u
> > #define ___GFP_MOVABLE
Em Fri, Sep 25, 2015 at 02:54:52PM +0900, Namhyung Kim escreveu:
> On Thu, Sep 24, 2015 at 12:56:31PM -0300, Arnaldo Carvalho de Melo wrote:
> > Em Fri, Sep 25, 2015 at 12:01:12AM +0900, Namhyung Kim escreveu:
> > > Hi Arnaldo,
> > >
> > > On Thu, Sep 24, 2015 at 10:42:28AM -0300, Arnaldo
On Thu, Sep 24, 2015 at 04:59:35PM -0500, Eric W. Biederman wrote:
> Seth Forshee writes:
>
> > Capability sets attached to files must be ignored except in the
> > user namespaces where the mounter is privileged, i.e. s_user_ns
> > and its descendants. Otherwise a vector exists for gaining
> >
On Thu, Sep 24, 2015 at 04:53:11PM -0500, Eric W. Biederman wrote:
> Seth Forshee writes:
>
> > When mounting a filesystem on a block device there is currently
> > no verification that the user has appropriate access to the
> > device file passed to mount. This has not been an issue so far
> >
On Fri, Sep 25, 2015 at 2:40 PM, Jiri Kosina wrote:
> On Fri, 25 Sep 2015, Sedat Dilek wrote:
>
>> >> $ egrep -nr 'save|restore|acquire|release'
>> >> objdump-Dr_kernel-workqueue_o_CLANG-3-7.txt | egrep 'irq|map'
>> >> 5718: 4601: R_X86_64_PC32
>> >>
On 09/24, Andrey Ryabinin wrote:
>
> 2015-09-24 20:26 GMT+03:00 Oleg Nesterov :
> > On 09/24, Sasha Levin wrote:
> >>
> >> void unmap_vmas(struct mmu_gather *tlb,
> >> struct vm_area_struct *vma, unsigned long start_addr,
> >> unsigned long end_addr)
> >> {
> >>
On Fri, Sep 25, 2015 at 01:15:46PM +0100, Robin Murphy wrote:
> Since some dma_alloc_coherent implementations return a zeroed buffer
> regardless of whether __GFP_ZERO is passed, there exist drivers which
> are implicitly dependent on this and pass otherwise uninitialised
> buffers to hardware.
301 - 400 of 1180 matches
Mail list logo
