On 09/02/2015 06:39 PM, Shaun Crampton wrote:
Make sure you backported commit
10e2eb878f3ca07ac2f05fa5ca5e6c4c9174a27a
("udp: fix dst races with multicast early demux")
I just tried the latest CoreOS alpha, which had that patch. Sadly, I saw
just as many reboots. Here's a sample of the
On 09/02, Leo Yan wrote:
> The previous code, kernel builds Hi6220's common clock driver and stub
> clock driver together. Stub clock driver has introduced the dependency
> with CONFIG_MAILBOX, so kernel will not build Hi6220's common clock
> driver due ARM64's defconfig have not enabled
On Wed, 2015-09-02 at 20:46 +0200, Luis R. Rodriguez wrote:
> On Tue, Sep 01, 2015 at 11:35:05PM -0400, Mimi Zohar wrote:
> > > OK great, I think that instead of passing the actual routine name we
> > > should
> > > instead pass an enum type for to the LSM, that'd be easier to parse and
> > >
On Thu, Sep 03, 2015 at 12:24:27AM +0200, Peter Zijlstra wrote:
> On Wed, Sep 02, 2015 at 11:50:22PM +0200, Frederic Weisbecker wrote:
> > > > [ 875.703227] [] tick_nohz_full_kick_cpu+0x44/0x50
> >
> > It happens in nohz full, but I'm not sure the guilty is nohz full.
> >
> > The problem here
On 01.09.2015 15:01, Yakir Yang wrote:
> After exynos_dp have been splited the common IP code into analogix_dp driver,
s/splited/split/
> the analogix_dp driver have deprecated some samsung platform properties which
s/samsung/Samsung/
> could be dynamic parsed from EDID/MODE/DPCD message, so
On 09/02, Viresh Kumar wrote:
>
> From: Viresh Kumar
> Date: Mon, 3 Aug 2015 14:34:23 +0530
> Subject: [PATCH 2/3] PM / OPP: Prefix exported opp routines with dev_pm_opp_
>
> That's the naming convention followed in most of opp core, but few
> routines didn't follow this, fix them.
>
>
On 08/03, Georgi Djakov wrote:
> diff --git a/Documentation/devicetree/bindings/clock/qcom,rpmcc.txt
> b/Documentation/devicetree/bindings/clock/qcom,rpmcc.txt
> new file mode 100644
> index ..bd0fd0cd50dc
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/clock/qcom,rpmcc.txt
On Wed, 2015-09-02 at 01:43 +0200, Luis R. Rodriguez wrote:
> On Mon, Aug 31, 2015 at 10:18:55AM -0400, Mimi Zohar wrote:
> > On Sat, 2015-08-29 at 04:16 +0200, Luis R. Rodriguez wrote:
> > > On Thu, Aug 27, 2015 at 07:54:33PM -0400, Mimi Zohar wrote:
> > > > On Thu, 2015-08-27 at 23:29 +0200,
God dag,
Det er vår glede å skrive til deg i forhold til å gi ut lån i posten annonse.
SUN EAST Federal Credit Union, Vi opererer under en kort, klar og forståelig
vilkår Vi gir ut lån med lav rente på 3%. Kjære lesere bør merke seg at dette
tilbudet er for seriøse tenkende
On 03.09.2015 01:41, Anand Moon wrote:
> Enable CONFIG_LEDS_PWM amd CONFIG_LEDS_TRIGGER_HEARTBEAT for
> Odroid-XU3/XU4 board.
>
> Signed-off-by: Anand Moon
>
> ---
> Changes from last version.
> Make all modules build-in.
> Enabled LEDS_GPIO
> ---
> arch/arm/configs/exynos_defconfig | 10
On Wed, Sep 2, 2015 at 11:45 AM, Darrick J. Wong
wrote:
> On Wed, Sep 02, 2015 at 05:52:01PM +0100, Mel Gorman wrote:
>> On the flip side, there does not appear to be any good reason for
>> keeping the ext3 driver around because if there ever is a case where an
>> old kernel is required to mount
On Wed, Sep 2, 2015 at 4:29 PM, Dmitry Torokhov
wrote:
> On Wed, Sep 2, 2015 at 4:22 PM, Luis R. Rodriguez wrote:
>> On Wed, Sep 02, 2015 at 04:13:51PM -0700, Dmitry Torokhov wrote:
>>> On Wed, Sep 2, 2015 at 2:03 PM, Arend van Spriel wrote:
>>> > Ok. So some background why we need it in
From: Andi Kleen
With all the recently added fields in the perf stat CSV output
we should finally document them in the man page. Do this here.
Signed-off-by: Andi Kleen
---
tools/perf/Documentation/perf-stat.txt | 19 +++
1 file changed, 19 insertions(+)
diff --git
From: Andi Kleen
Abstract the printing of shadow metrics. Instead of every
metric calling fprintf directly and taking care of indentation,
use two call backs: one to print metrics and another to
start a new line.
This will allow adding metrics to CSV mode and also
using them for other purposes.
From: Andi Kleen
Now that we can modify the metrics printout functions easily,
it's straight forward to support metric printing for interval mode.
All that is needed is to print the time stamp on every new line.
Pass the prefix into the context and print it out.
Signed-off-by: Andi Kleen
---
From: Andi Kleen
Enable metrics printing in --per-core / --per-socket mode. We need
to save the shadow metrics in a unique place. Always use the first
CPU in the aggregation. Then use the same CPU to retrieve the
shadow value later.
Example output:
% perf stat --per-core -a ./BC1s
From: Andi Kleen
printout now handles unsupported/not counted printing, so we can
remove one extra instance in the aggregated printing.
Signed-off-by: Andi Kleen
---
tools/perf/builtin-stat.c | 22 ++
1 file changed, 2 insertions(+), 20 deletions(-)
diff --git
From: Andi Kleen
Move the running/noise printing into printout to avoid
duplicated code in the callers.
Signed-off-by: Andi Kleen
---
tools/perf/builtin-stat.c | 29 +++--
1 file changed, 11 insertions(+), 18 deletions(-)
diff --git a/tools/perf/builtin-stat.c
From: Andi Kleen
Now support CSV output for metrics. With the new output callbacks
this is relatively straight forward by creating new callbacks.
The new line callback needs to know the number of fields to skip them
correctly
v2: Split out function argument changes
Signed-off-by: Andi Kleen
[v3: Addressed all review feedback. Update manpage for CSV. Various changes
(see individual patches). Remove some more redundant code
in printout callers.]
[v2: Addressed (near) all review feedback. No manpage updates so far.
Add support for --per-core metrics. Various cleanups.]
From: Andi Kleen
Move the special case printing for non-running counters to
printout, so it can be shared by all the output options.
Signed-off-by: Andi Kleen
---
tools/perf/builtin-stat.c | 73 ---
1 file changed, 24 insertions(+), 49 deletions(-)
From: Dave Hansen
The original purpose of XSTATE_RESERVE was to carve out space
to store all of the possible extended state components that
get saved with the XSAVE instruction(s).
However, we are now almost entirely dynamically allocating
the buffers we use for XSAVE by placing them at the
From: Andi Kleen
The sw clock metrics printing was missed in the earlier move to
stat-shadow of all the other metric printouts. Move it too.
Signed-off-by: Andi Kleen
---
tools/perf/builtin-stat.c | 9 -
tools/perf/util/stat-shadow.c | 3 +++
2 files changed, 3 insertions(+), 9
From: Dave Hansen
This is a logcal followon to the last patch. It makes the
XFEATURE_MAX naming consistent with the other enum values.
This is what Ingo suggested.
Signed-off-by: Dave Hansen
Cc: Ingo Molnar
Cc: x...@kernel.org
Cc: Borislav Petkov
Cc: Fenghua Yu
Cc: Tim Chen
Cc:
Alex,
On Wed, Sep 2, 2015 at 4:27 PM, Alexandru M Stan wrote:
> With the previous patch ("rk3288: pull up cts lines") this is redundant,
> I sent that patch for the same reason this existed here, so the lines don't
> wiggle randomly when disconnected.
>
> Signed-off-by: Alexandru M Stan
> ---
>
Alex,
On Wed, Sep 2, 2015 at 4:27 PM, Alexandru M Stan wrote:
> The flow control lines from a user accessible UART are optional,
> the user might not have anything connected to those pins.
> In order to prevent random interrupts happening and noise affecting
> the cts pin should be pulled up.
>
From: Dave Hansen
The 'xstate.c' code has a bunch of references to '2'. This
is because we have a lot more work to do for the "extended"
xstates than the "legacy" ones and state component 2 is the
first "extended" state.
This patch replaces all of the instances of '2' with
From: Dave Hansen
MPX includes two separate "extended state components". There is
no real need to have an 'mpx_struct' because we never really
manage the states together.
We also separate out the actual data in 'mpx_bndcsr_state' from
the padding. We will shortly be checking the state sizes
From: Dave Hansen
There are two concepts that have some confusing naming:
1. Extended State Component numbers (currently called
XFEATURE_BIT_*)
2. Extended State Component masks (currently called XSTATE_*)
The numbers are (currently) from 0-9. State component 3 is the
bounds registers
From: Dave Hansen
We currently use test_bit() in a few places to see if an xfeature
is enabled. It ends up being a bit ugly because 'xfeatures_mask'
is a u64 and test_bit wants an 'unsigned long' so it requires a
cast. The *_bit() functions are also techincally atomic, which
we have no need
From: Dave Hansen
AVX-512 has 3 separate state components:
1. opmask registers
2. zmm upper half of registers 0-15
3. new zmm registers (16-31)
This patch adds C structures for the three components along with
a few comments mostly lifted from the SDM to explain what they
do. This will allow
From: Dave Hansen
LightWeight Profiling was evidently an AMD profiling feature that
we never got around to implementing. Remove the references to it.
Signed-off-by: Dave Hansen
Cc: Ingo Molnar
Cc: x...@kernel.org
Cc: Borislav Petkov
Cc: Fenghua Yu
Cc: Tim Chen
Cc:
From: Dave Hansen
xfeature_nr ended up being initialized too late for me to
use it in the "xsave size sanity check" patch which is
later in the series. I tried to move around its initialization
but realized that it was just as easy to get rid of it.
We only have 9 XFEATURES. Instead of
From: Dave Hansen
We are about to rework all of the "extended state" definitions.
This makes the 'ymm' naming consistent with the AVX-512 types
we will introduce later.
We also add a convenience type: "reg_128_bit" so that we do
not have to spell out our arithmetic.
Signed-off-by: Dave Hansen
From: Dave Hansen
Note: our xsaves support is currently broken and disabled. This
patch does not fix it, but it is an incremental improvement.
This might be useful to someone backporting the entire set of
XSAVES patches at some point, but it should not be backported
alone.
Ingo said he wanted
From: Dave Hansen
The xstate CPUID leaves enumerate where each state component is
inside the XSAVE buffer, along with the size of the entire
buffer. Our new XSAVE sanity-checking code extrapolates an
expected _total_ buffer size by looking at the last component
that it encounters.
That method
From: Dave Hansen
Changes from v2:
* remove XSTATE_RESERVED check, since it is gone now
--
From: Dave Hansen
We now have C structures defined for each of the XSAVE state
components that we support. This patch adds checks during our
verification pass to ensure that the CPU-provided data
From: Dave Hansen
This is utterly a personal taste thing, but I find it way easier
to read structure sizes in decimal than in hex.
Signed-off-by: Dave Hansen
Cc: Ingo Molnar
Cc: x...@kernel.org
Cc: Borislav Petkov
Cc: Fenghua Yu
Cc: Tim Chen
Cc: linux-kernel@vger.kernel.org
---
Changes in v4:
* Fix up a few compile errors/warnings
Changes in v3:
* rework XSTATE_* macros using Ingo's suggested naming
* change state size printk to be in decimal
* add some more sanity-checking to detect and work around
an undersized 'xregs_state'
* remove "nr_" from some of the
From: Dave Hansen
When we want to _completely_ disable XSAVE support as far as
the kernel is concerned, we have a big set of feature flags
to clear. We currently only do this in cases where the user
asks for it to be disabled, but we are about to expand the
places where we do it to handle
The flow control lines from a user accessible UART are optional,
the user might not have anything connected to those pins.
In order to prevent random interrupts happening and noise affecting
the cts pin should be pulled up.
Note that the default state for that pin on the rk3288 is pulled up,
so
On Wed, Sep 2, 2015 at 4:22 PM, Luis R. Rodriguez wrote:
> On Wed, Sep 02, 2015 at 04:13:51PM -0700, Dmitry Torokhov wrote:
>> On Wed, Sep 2, 2015 at 2:03 PM, Arend van Spriel wrote:
>> > On 09/02/2015 08:58 PM, Luis R. Rodriguez wrote:
>> >>
>> >> On Wed, Sep 02, 2015 at 02:13:49PM +0200, Arend
With the previous patch ("rk3288: pull up cts lines") this is redundant,
I sent that patch for the same reason this existed here, so the lines don't
wiggle randomly when disconnected.
Signed-off-by: Alexandru M Stan
---
Changes in v2:
- Restrict changes only to cts pin, leave rts alone
- CC
The flow control lines from a user accessible UART are optional,
the user might not have anything connected to those pins.
In order to prevent random interrupts happening and noise affecting
the cts pin should be pulled up.
The only boards affected (that care about uart*_cts ) are the veyron
From: Kolmakov Dmitriy
Date: Wed, 2 Sep 2015 15:33:00 +
> If an attempt to wake up users of broadcast link is made when there
> is no enough place in send queue than it may hang up inside the
> tipc_sk_rcv() function since the loop breaks only after the wake up
> queue becomes empty. This
On Wed, Sep 02, 2015 at 04:13:51PM -0700, Dmitry Torokhov wrote:
> On Wed, Sep 2, 2015 at 2:03 PM, Arend van Spriel wrote:
> > On 09/02/2015 08:58 PM, Luis R. Rodriguez wrote:
> >>
> >> On Wed, Sep 02, 2015 at 02:13:49PM +0200, Arend van Spriel wrote:
> >>>
> >>> On 09/02/2015 02:09 PM, Arend van
On 9/3/15 2:09 AM, David Matlack wrote:
On Wed, Sep 2, 2015 at 12:42 AM, Wanpeng Li wrote:
Tracepoint for dynamic halt_pool_ns, fired on every potential change.
Signed-off-by: Wanpeng Li
---
include/trace/events/kvm.h | 30 ++
virt/kvm/kvm_main.c| 8
On Tue, Sep 1, 2015 at 6:14 PM, Nuno Gonçalves wrote:
> On Wed, Sep 2, 2015 at 2:03 AM, John Stultz wrote:
>> On Tue, Sep 1, 2015 at 5:36 PM, Nuno Gonçalves wrote:
>>> On Tue, Sep 1, 2015 at 9:25 PM, Thomas Gleixner wrote:
On Tue, 1 Sep 2015, Nuno Gonçalves wrote:
> There is a
On Wed, Sep 02, 2015 at 03:45:10PM -0700, Andy Grover wrote:
> Hi Hans and Greg,
>
> Is this an issue with uio? I swear it didn't used to throw this warning...
>
> Thanks -- Andy
>
> [ 5174.883261] [ cut here ]
> [ 5174.883617] WARNING: CPU: 0 PID: 1532 at
>
On Wed, Sep 2, 2015 at 2:03 PM, Arend van Spriel wrote:
> On 09/02/2015 08:58 PM, Luis R. Rodriguez wrote:
>>
>> On Wed, Sep 02, 2015 at 02:13:49PM +0200, Arend van Spriel wrote:
>>>
>>> On 09/02/2015 02:09 PM, Arend van Spriel wrote:
On 09/02/2015 03:19 AM, Luis R. Rodriguez wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
I'm announcing the release of the 3.18.21 kernel.
All users of the 3.18 kernel series must upgrade.
The updated 3.18.y git tree can be found at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git
linux-3.18.y
and can be
The patch
regulator: qcom_smd: Handle big endian CPUs
has been applied to the regulator tree at
git://git.kernel.org/pub/scm/linux/kernel/git/broonie/regulator.git
All being well this means that it will be integrated into the linux-next
tree (usually sometime in the next 24 hours) and
I have a Business Proposal for you to handle with me, Get back to me for
more details on this project.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
On Wed, Sep 02, 2015 at 12:34:41PM -0400, Vince Weaver wrote:
>
> OK, this time I found the actual bug.
>
> event->read_size is declared as a u16 in include/linux/perf_event.h
>
> but it is very easy to get event->read_size larger than 64k
> (in my case, create 1 events in a group).
>
>
Dear friend,I need your help to transfer
the sum of Six.Million US Dollars
to your bank account No risk involved
in this deal reply me if you
are ready to receive the fund.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
Alex,
On Wed, Sep 2, 2015 at 3:20 PM, Alexandru M Stan wrote:
> The flow control lines from a user accessible UART are optional,
> the user might not have anything connected to those pins.
> In order to prevent random interrupts happening and noise affecting
> that pin it should be pulled up.
>
03.09.2015 01:25, Andy Lutomirski пишет:
On Wed, Sep 2, 2015 at 3:25 PM, Stas Sergeev wrote:
How dosemu2 is supposed to do this:
1. sigreturn() (to DOS)
2. siglongjmp() (to 64bit C-coded)
This should work fine on any kernel, right?
1 - not.
2 - maybe.
If, as you say, siglongjmp() restores
On Wed, Sep 2, 2015 at 5:01 PM, Daniel Drake wrote:
> Hi,
>
> Working with a sample for a new laptop based on Intel Skylake, the
> kernel logs are full of these messages:
>
> pcieport :00:1c.5: AER: Corrected error received: id=00e5
> pcieport :00:1c.5: PCIe Bus Error:
On 09/02/2015 04:41 PM, Jens Axboe wrote:
On 09/02/2015 04:34 PM, Linus Torvalds wrote:
Jens,
On Wed, Sep 2, 2015 at 9:58 AM, Jens Axboe wrote:
This pull request contains a set of scatter-gather related changes/fixes
for 4.3. It contains:
This results in several new and annoying warnings.
Hi, Frederic
I noticed on latest code, the tick_nohz_restart_sched_tick() set the
ts->idle_exittime, should it be done on tick_nohz_stop_idle() since the
tick_nohz_restart_sched_tick() is invoked also on nohz_full scenario, am I
right, or do I miss anything?
Thanks
--jyh
--
To
We already have a function to do this and it silences some sparse
warnings along the way.
Reviewed-by: Bjorn Andersson
Signed-off-by: Stephen Boyd
---
No changes
drivers/soc/qcom/smd.c | 13 -
1 file changed, 4 insertions(+), 9 deletions(-)
diff --git a/drivers/soc/qcom/smd.c
Usage of VLAIS prevents clang from compiling this file, and it
also opens us to the possibility of allocating a large structure
on the stack to the point that we blow past the limit of the
kernel stack. Remove the VLAIS and allocate a structure on the
heap with kmalloc so that we're safer and more
The smd rpm structures are always in little endian, but this
driver is not capable of being used on big endian CPUs. Annotate
the little endian data members and update the code to do the
proper byte swapping.
Cc: Bjorn Andersson
Signed-off-by: Stephen Boyd
---
Changes from v1:
* New patch
This supersedes the 3 "series" of patches to move smem to big endian,
smd to big endian, and make qcom_smem_get() return a pointer.
I've moved the qcom_smem_get() returning a pointer part to the beginning
of the series so it can be applied earlier if desired. I imagine the
first 7 patches can go
The contents of smem are always in little endian, but the smem
driver is not capable of being used on big endian CPUs. Annotate
the little endian data members and update the code to do the
proper byte swapping.
Cc: Bjorn Andersson
Signed-off-by: Stephen Boyd
---
Changes since v1:
* Rebased on
The smd structures are always in little endian, but the smd
driver is not capable of being used on big endian CPUs. Annotate
the little endian data members and update the code to do the
proper byte swapping.
Cc: Bjorn Andersson
Signed-off-by: Stephen Boyd
---
Changes from v1:
* hdr and
The rx and tx channel info are laid out in memory next to each
other, and there are two types of channel info structures, byte
based and word based. We have 4 pointers to these info
structures, when we really only need two to point to the
different types of structures. Encapsulate the byte based
The smd rpm structures are always in little endian, but this
driver is not capable of being used on big endian CPUs. Annotate
the little endian data members and update the code to do the
proper byte swapping.
Cc: Bjorn Andersson
Cc: Andy Gross
Signed-off-by: Stephen Boyd
---
Changes from v1:
Passing a void ** almost always requires a cast at the call site.
Instead of littering the code with casts every time this function
is called, have qcom_smem_get() return a void pointer to the
location of the smem item. This frees the caller from having to
cast the pointer.
Cc: Bjorn Andersson
Dear friend,I need your help to transfer
the sum of Six.Million US Dollars
to your bank account No risk involved
in this deal reply me if you
are ready to receive the fund.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
Hi Hans and Greg,
Is this an issue with uio? I swear it didn't used to throw this warning...
Thanks -- Andy
[ 5174.883261] [ cut here ]
[ 5174.883617] WARNING: CPU: 0 PID: 1532 at
/home/agrover/git/kernel/kernel/sched/core.c:7389 __might_sleep+0x7d/0x90()
[
On 09/02/2015 04:34 PM, Linus Torvalds wrote:
Jens,
On Wed, Sep 2, 2015 at 9:58 AM, Jens Axboe wrote:
This pull request contains a set of scatter-gather related changes/fixes
for 4.3. It contains:
This results in several new and annoying warnings. They may all be ok
code, but they are very
On Thu, Aug 13, 2015 at 09:31:48AM +0200, Paolo Bonzini wrote:
Pinging this thread.
Should I put together a patch to make split irqchip work properly with the old
TMR behavior?
>
>
> On 13/08/2015 08:35, Zhang, Yang Z wrote:
> >> You may be right. It is safe if no future hardware plans to use
-Original Message-
From: Intel-wired-lan [mailto:intel-wired-lan-boun...@lists.osuosl.org] On
Behalf Of Jarod Wilson
Sent: Thursday, August 13, 2015 11:03 AM
To: linux-kernel@vger.kernel.org
Cc: net...@vger.kernel.org; intel-wired-...@lists.osuosl.org; Jarod Wilson
Subject:
Jens,
On Wed, Sep 2, 2015 at 9:58 AM, Jens Axboe wrote:
>
> This pull request contains a set of scatter-gather related changes/fixes
> for 4.3. It contains:
This results in several new and annoying warnings. They may all be ok
code, but they are very distracting. Please stop introducing new
On Wed, 2015-09-02 at 01:25 -0500, Porosanu Alexandru-B06830 wrote:
> Hi Scott,
>
> > -Original Message-
> > From: Wood Scott-B07421
> > Sent: 1 septembrie 2015 03:50
> > To: Geanta Neag Horia Ioan-B05471
> > Cc: Herbert Xu; Catalin Marinas; Will Deacon; linux-cry...@vger.kernel.org;
> >
发自我的 iPhone
> 在 2015年9月2日，下午10:43，Arnaldo Carvalho de Melo 写道：
>
> Em Wed, Sep 02, 2015 at 10:04:21PM +0800, pi3orama escreveu:
>> 发自我的 iPhone
>>> 在 2015年9月2日，下午9:55，Arnaldo Carvalho de Melo 写道：
>>> Em Wed, Sep 02, 2015 at 08:05:54PM +0800, pi3orama escreveu:
发自我的 iPhone
> 在
On Wed, Sep 2, 2015 at 3:25 PM, Stas Sergeev wrote:
> 03.09.2015 00:39, Andy Lutomirski пишет:
>
>> On Wed, Sep 2, 2015 at 2:01 PM, Stas Sergeev wrote:
>>>
>>> 02.09.2015 22:06, Andy Lutomirski пишет:
>>>
On Wed, Sep 2, 2015 at 11:23 AM, Stas Sergeev wrote:
>
> 02.09.2015 21:17,
On Wed, Sep 02, 2015 at 11:50:22PM +0200, Frederic Weisbecker wrote:
> > > [ 875.703227] [] tick_nohz_full_kick_cpu+0x44/0x50
>
> It happens in nohz full, but I'm not sure the guilty is nohz full.
>
> The problem here is that wake_up_nohz_cpu() selects a CPU that is offline.
On Fri, Aug 14, 2015 at 04:08:10PM -0500, Rob Herring wrote:
> On Fri, Aug 14, 2015 at 11:19 AM, Marc Zyngier wrote:
> > Both pci-host-generic and Pseries parse the "linux,pci-probe-only"
> > to engage the PCI_PROBE_ONLY mode, and both have a subtle bug that
> > can be triggered if the property
cpu_cluster_pm_exit() must be sent after cpu_cluster_pm_enter() has been
sent for the cluster and before any cpu_pm_exit() notifications are sent
for any CPU.
Cc: Nicolas Pitre
Acked-by: Kevin Hilman
Signed-off-by: Lina Iyer
---
kernel/cpu_pm.c | 2 +-
1 file changed, 1 insertion(+), 1
03.09.2015 00:39, Andy Lutomirski пишет:
On Wed, Sep 2, 2015 at 2:01 PM, Stas Sergeev wrote:
02.09.2015 22:06, Andy Lutomirski пишет:
On Wed, Sep 2, 2015 at 11:23 AM, Stas Sergeev wrote:
02.09.2015 21:17, Andy Lutomirski пишет:
On Wed, Sep 2, 2015 at 10:46 AM, Stas Sergeev wrote:
The flow control lines from a user accessible UART are optional,
the user might not have anything connected to those pins.
In order to prevent random interrupts happening and noise affecting
that pin it should be pulled up.
Note that the default state for those pins on the rk3288 is pulled up,
so
[resending text-only]
On Wed, Sep 2, 2015 at 3:07 PM, Grant Grundler wrote:
>
>
> On Wed, Sep 2, 2015 at 11:28 AM, Olof Johansson wrote:
> ...
>> > +/**
>> > + * struct mmc_ioc_combo_cmd - combo command information
>> > + * @num_of_cmds: number of commands to send
>> > + * @mmc_ioc_cmd_list:
Hi,
Working with a sample for a new laptop based on Intel Skylake, the
kernel logs are full of these messages:
pcieport :00:1c.5: AER: Corrected error received: id=00e5
pcieport :00:1c.5: PCIe Bus Error: severity=Corrected,
type=Physical Layer, id=00e5(Receiver ID)
pcieport
Hi Linus,
there is quite a lot going on in the GPIO subsystem this merge
window, so the main matter is decribed in the signed tag.
The hits in other subsystems when making the GPIO flags
optional are all ACKed by their respective subsystem
maintainers.
The development cycle was a bit rough, I
The pins for i2c5 can either be configured as "I2C5" which means that
they're controlled by the normal RK3288 I2C controller or as "EDP / HDMI
I2C". It's unclear why EDP is referenced here since apparently setting
the mux to this position enables I2C communication using the dw_hdmi
block with a
On Wed, Sep 02, 2015 at 03:44:05PM -0400, Tejun Heo wrote:
> (cc'ing peterz)
>
> Ooh, this is from irq_work which doesn't have much to do with
> workqueue. Peter?
>
> On Mon, Aug 24, 2015 at 05:16:11PM -0700, Paul E. McKenney wrote:
> > Hello, Tejun,
> >
> > As discussed last week, I am
03.09.2015 00:40, Andy Lutomirski пишет:
On Wed, Sep 2, 2015 at 2:12 PM, Stas Sergeev wrote:
02.09.2015 23:55, Andy Lutomirski пишет:
On Wed, Sep 2, 2015 at 1:47 PM, Stas Sergeev wrote:
02.09.2015 23:22, Josh Boyer пишет:
On Wed, Sep 2, 2015 at 1:50 PM, Stas Sergeev wrote:
02.09.2015
On Wed, Sep 2, 2015 at 2:12 PM, Stas Sergeev wrote:
> 02.09.2015 23:55, Andy Lutomirski пишет:
>
>> On Wed, Sep 2, 2015 at 1:47 PM, Stas Sergeev wrote:
>>>
>>> 02.09.2015 23:22, Josh Boyer пишет:
On Wed, Sep 2, 2015 at 1:50 PM, Stas Sergeev wrote:
>
> 02.09.2015 20:46, Josh
On Wed, Sep 2, 2015 at 2:01 PM, Stas Sergeev wrote:
> 02.09.2015 22:06, Andy Lutomirski пишет:
>
>> On Wed, Sep 2, 2015 at 11:23 AM, Stas Sergeev wrote:
>>>
>>> 02.09.2015 21:17, Andy Lutomirski пишет:
On Wed, Sep 2, 2015 at 10:46 AM, Stas Sergeev wrote:
>
> 02.09.2015 17:21,
On Wed, Sep 02, 2015 at 01:54:43PM -0700, Kees Cook wrote:
> On Wed, Sep 2, 2015 at 11:46 AM, Luis R. Rodriguez wrote:
> > On Tue, Sep 01, 2015 at 11:35:05PM -0400, Mimi Zohar wrote:
> >> > OK great, I think that instead of passing the actual routine name we
> >> > should
> >> > instead pass an
At present, I can use git client via 21cn mail address. Hope it can be
accepted by our mailing list.
Thanks.
On 9/1/15 21:49, Chen Gang wrote:
>
> Sorry for the incorrect format of the patch. So I put the patch into the
> attachment which generated by "git format-patch -M HEAD^". Please help
>
The ddc-i2c-bus property was missing from the veyron dtsi file since
downstream the ddc-i2c-bus was still being specified in rk3288.dtsi and
nobody noticed when the veyron dtsi was sent upstream. Add it.
Signed-off-by: Douglas Anderson
---
Note: I noticed that this was wrong but I don't
[ I sent this some times ago, but didn't get any response ]
Nvidia cards have a BIOS function 0x4f14 that allows to set flat panel
scaling. This patch adds a module parameter "scaling" that uses this
function to set the scaling. By default, the parameter is -1, so that the
driver doesn't attempt
On Wed, Sep 02, 2015 at 01:01:27PM -0700, Sean O. Stalley wrote:
> On Wed, Sep 02, 2015 at 02:25:50PM -0500, Bjorn Helgaas wrote:
> > On Wed, Sep 2, 2015 at 12:46 PM, Sean O. Stalley
> > wrote:
> >
> > > Would it be better to modify pci_claim_resource() to support EA instead
> > > of adding
On Wed, Sep 2, 2015 at 10:00 AM, Peter Zijlstra wrote:
>
> So I'm reading that code like:
>
> MB
> [RmW] ret = *val += i
>
>
> So what is stopping later memory ops like:
>
>[R] a = *foo
>[S] *bar = b
>
> From getting reordered with the RmW, like:
>
> MB
>
>[R] a =
02.09.2015 23:55, Andy Lutomirski пишет:
On Wed, Sep 2, 2015 at 1:47 PM, Stas Sergeev wrote:
02.09.2015 23:22, Josh Boyer пишет:
On Wed, Sep 2, 2015 at 1:50 PM, Stas Sergeev wrote:
02.09.2015 20:46, Josh Boyer пишет:
On Wed, Sep 2, 2015 at 10:08 AM, Andy Lutomirski
wrote:
I'd be amenable
odpovezte mi na nize uvedenou e-mailovou adresu pro vysvetlení výroku.
E-mail: chn.j...@gmail.com
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
On Fri, Aug 21, 2015 at 01:45:35PM +0300, Roger Quadros wrote:
> As both omap2 onenand and omap2 nand driver modules are
> named the same i.e. "omap2.ko", only one of them gets shipped
> during MODPOST if both are configured as loadable modules.
>
> To avoid this ambiguity let's ship the omap2
101 - 200 of 1480 matches
Mail list logo
