On Wed, Jun 01, 2016 at 11:37:50PM +0800, Lijun Ou wrote:
> This patch mainly added icm support for RoCE. It initializes icm
> which managers the relative memory blocks for RoCE. The data
> structures of RoCE will be located in it. For example, CQ table,
> QP table and MTPT table so on.
I wonder i
Send Application to: n.c.m45...@dr.com
Arrangements to Borrow up to 20,000,000.00 euro Choose between 1 to 25 years
repayment period. repayment plan Flexible.
Marshall Malter
Hi
On 2016-06-08 20:31, Matthew Leach wrote:
From: Ben Dooks
Add initial support for big endian by always writing the pte
in le32. Note, revisit if hardware capable of doing big endian
fetches.
Signed-off-by: Ben Dooks
Acked-by: Marek Szyprowski
Just to keep my curiosity satisfied - wha
* Arnd Bergmann [160608 09:06]:
> On Wednesday, June 8, 2016 2:47:48 AM CEST Tony Lindgren wrote:
> >
> > So we could have ARCH_MULTIPLATFORM_TYPICAL, then have the old
> > ARCH_OMAP2PLUS_TYPICAL select that one. That should keep things
> > behaving just fine if the old .config had ARCH_OMAP2PLUS
* Lukas Wunner wrote:
> > How do you know that sec is valid ?
> >
> > How about on the system that have one bridge that still have sec num
> > register 0?
> >
> > it will be get into dead loop.
>
> Good point. I've just checked pci_scan_bridge() and it does verify that and
> avoids recursin
On Wed 08-06-16 15:51:20, David Rientjes wrote:
> On Wed, 8 Jun 2016, Michal Hocko wrote:
>
> > > Why is the patch asking users to report oom killing of a process that
> > > raced with setting /proc/pid/oom_score_adj to OOM_SCORE_ADJ_MIN? What is
> > > possibly actionable about it?
> >
> > Wel
On Wed 08-06-16 23:19:21, Oleg Nesterov wrote:
> This was needed before to ensure that ->signal != 0 and do_each_thread()
> is safe, see the commit b95c35e76b29b for details.
>
> Today tsk->signal can't go away and for_each_thread(tsk) is always safe.
>
> Signed-off-by: Oleg Nesterov
Acked-by:
On Thu, 2016-06-09 at 11:06 +0530, Prasun Maiti wrote:
> Since add more warnings for inconsistent ops in cfg80211, the
> wireless
> core warns if a driver implements a cfg80211 callback but doesn't
> implements the inverse operation. The ath6kl driver implements a
> cfg80211
> .get_antenna operatio
On Wed, Jun 01, 2016 at 11:37:45PM +0800, Lijun Ou wrote:
> This patch mainly added the initial bare main driver. It
> could get the relative configure information of net node.
>
> Signed-off-by: Wei Hu
> Signed-off-by: Nenglong Zhao
> Signed-off-by: Lijun Ou
> ---
> drivers/infiniband/hw/hns/
Hi all,
News: there will be no linux-next releases on Friday (tomorrow) or
Monday, so the next release will be next-20160614 on Tuesday.
Changes since 20160608:
New tree: kspp
Dropped tree: amlogic (build failure)
My fixes tree contains:
of: silence warnings due to max() usage
The amlogic
On Wed, 8 Jun 2016 13:42:12 -0700
Andrew Morton wrote:
> On Tue, 7 Jun 2016 10:37:41 +0200 Martin Schwidefsky
> wrote:
>
> > The bitmap_equal function has optimized code for small bitmaps with less
> > than BITS_PER_LONG bits. For larger bitmaps the out-of-line function
> > __bitmap_equal is
On Wed, Jun 01, 2016 at 11:37:53PM +0800, Lijun Ou wrote:
> This patch registered IB device when loaded, and unregistered
> IB device when removed.
>
> Signed-off-by: Wei Hu
> Signed-off-by: Nenglong Zhao
> Signed-off-by: Lijun Ou
> ---
> drivers/infiniband/hw/hns/hns_roce_main.c | 46
> +
Hello Tien Hock
On 6/9/2016 7:48 AM, Tien Hock Loh wrote:
[snip]
.../devicetree/bindings/net/socfpga-dwmac.txt | 4 +
drivers/net/ethernet/stmicro/stmmac/Makefile | 2 +-
.../net/ethernet/stmicro/stmmac/dwmac-socfpga.c| 140 +--
drivers/net/ethernet/stmicro/stmmac/t
On 2016/06/08 10:19PM, Nilay Vaish wrote:
> Naveen, can you point out where in the patch you update the variable:
> idx, a member of codegen_contex structure? Somehow I am unable to
> figure it out. I can only see that we set it to 0 in the
> bpf_int_jit_compile function. Since all your test cas
On 2016-06-08 18:39, Jan Kiszka wrote:
The question is since overlays exist and do work, why should he do
anything else
besides using them?
>>>
>>> For one thing, they only work with DT, and there are ACPI ARM server
>>> platforms out there, for which people may wish to use jailhous
Hi Stephen Rothwell,
> Hi Vinod,
>
> After merging the slave-dma tree, today's linux-next build (arm
> multi_v7_defconfig) produced this warning:
>
> drivers/dma/xilinx/xilinx_vdma.c: In function 'xilinx_dma_prep_dma_cyclic':
> drivers/dma/xilinx/xilinx_vdma.c:1808:23: warning: 'segment' may be
This patch fixes the below compilation warining.
drivers/dma/xilinx/xilinx_vdma.c: In function 'xilinx_dma_prep_dma_cyclic':
drivers/dma/xilinx/xilinx_vdma.c:1808:23: warning: 'segment' may be used
uninitialized in this function [-Wmaybe-uninitialized]
segment->hw.control |= XILINX_DMA_BD_SOP;
On Wed, Jun 08, 2016 at 04:07:59PM -0300, Gustavo Padovan wrote:
> Hi Greg,
>
> Any comment on this?
I am just starting to catch up on patches, please give me some time,
staging patches are at the bottom of my priority list, sorry.
greg k-h
Arnd Bergmann writes:
> What exactly is the problem we are seeing, and is there a way to fix
> it on top of my patch? Are we perhaps just missing a call to
> pcie_bus_configure_settings()?
From: khal...@piap.pl (Krzysztof Halasa)
Subject: [PATCH] Extend PCIE_BUS_PEER2PEER to set MRSS=128 to fix
On Wed, 2016-06-08 at 14:43 -0500, Bryant G. Ly wrote:
>
> Hi Nic,
>
> So I was testing the ibmvscsi target driver and I ran into some problems
> again with UA stuff and it looks like you didnt remove the UA checks from
> target_setup_cmd_from_cdb? Was that intentional? I thought we agreed to
Since add more warnings for inconsistent ops in cfg80211, the wireless
core warns if a driver implements a cfg80211 callback but doesn't
implements the inverse operation. The ath6kl driver implements a cfg80211
.get_antenna operation handler but doesn't have the inverse .set_antenna
callback. So, i
NBANK() macro assumes that ngpios is a multiple of 8(BANK_SZ) and
hence results in 0 banks for PCA9536 which has just 4 gpios. This is
wrong as PCA9356 has 1 bank with 4 gpios. This results in uninitialized
PCA953X_INVERT register. Fix this by using DIV_ROUND_UP macro in
NBANK().
Cc: sta...@vger.k
On Tue, Jun 7, 2016 at 8:44 PM, Laxman Dewangan wrote:
> Jetson-TX1 uses the Maxim MAX77620 as system Power management IC.
> Add device node for the MAX77620 with following details:
> - Add device max77620 with.
> - Add all pins configurations.
> - Configure FPS of the device.
>
On Wed, Jun 8, 2016 at 5:03 PM, Roger Quadros wrote:
> Hi,
>
> This series centralizes OTG/Dual-role functionality in the kernel.
> As of now I've got Dual-role functionality working pretty reliably on
> dra7-evm and am437x-gp-evm.
>
> DWC3 controller and TI platform related patches will be sent s
Hi Paul,
Today's linux-next merge of the rcu tree got a conflict in:
kernel/rcu/tree.c
between commit:
6428671bae97 ("locking/mutex: Optimize mutex_trylock() fast-path")
from the tip tree and commit:
3991b105efd5 ("rcu: Move expedited code from tree.c to tree_exp.h")
from the rcu tree.
2016-06-08 10:54 GMT-04:00 Lyude :
> From: Dennis Wassenberg
>
> Lenovo Thinkpad devices T460, T460s, T460p, T560, X260 use
> HKEY version 0x200 without adaptive keyboard.
>
> HKEY version 0x200 has method MHKA with one parameter value.
> Passing parameter value 1 will get hotkey_all_mask (the sam
The series is aimed at getting rid of CURRENT_TIME and CURRENT_TIME_SEC macros.
The macros are not y2038 safe. There is no plan to transition them into being
y2038 safe.
ktime_get_* api's can be used in their place. And, these are y2038 safe.
All filesystem timestamps use current_fs_time() for the
CURRENT_TIME_SEC is not y2038 safe. current_fs_time() will
be transitioned to use 64 bit time along with vfs in a
separate patch.
There is no plan to transition CURRENT_TIME_SEC to use
y2038 safe time interfaces.
current_fs_time() returns timestamps according to the
granularities set in the super_
CURRENT_TIME_SEC is not y2038 safe. current_fs_time() will
be transitioned to use 64 bit time along with vfs in a
separate patch.
There is no plan to transistion CURRENT_TIME_SEC to use
y2038 safe time interfaces.
current_fs_time() will also be extended to use superblock
range checking parameters
CURRENT_TIME_SEC and CURRENT_TIME are not y2038 safe.
current_fs_time() will be transitioned to be y2038 safe
along with vfs.
current_fs_time() returns timestamps according to the
granularities set in the super_block.
The granularity check to call current_fs_time() or
CURRENT_TIME_SEC is not requi
On 06/09/2016 04:34 AM, Chen-Yu Tsai wrote:
> Hi
>
> On Thu, Jun 9, 2016 at 3:03 AM, Rob Herring wrote:
>> On Tue, Jun 07, 2016 at 11:29:02AM +0200, Krzysztof Kozlowski wrote:
>>> On 06/03/2016 04:02 AM, Rob Herring wrote:
> Optional properties:
> - reset-gpios : contains a list of GPIO
boot_time is represented as a struct timespec.
struct timespec and CURRENT_TIME are not y2038 safe.
Overall, the plan is to use timespec64 for all internal
kernel representation of timestamps.
CURRENT_TIME will also be removed.
Use struct timespec64 to represent boot_time.
And, ktime_get_real_ts64(
CURRENT_TIME is not y2038 safe.
CURRENT_TIME macro is also not appropriate for filesystems
as it doesn't use the right granularity for filesystem
timestamps.
Logical Volume Integrity format is described to have the
same timestamp format for "Recording Date and time" as
the other [a,c,m]timestamps
CURRENT_TIME macro is not appropriate for filesystems as it
doesn't use the right granularity for filesystem timestamps.
Use current_fs_time() instead.
This is also in preparation for the patch that transitions
vfs timestamps to use 64 bit time and hence make them
y2038 safe.
CURRENT_TIME macro w
CURRENT_TIME is not y2038 safe.
The macro will be deleted and all the references to it
will be replaced by ktime_get_* apis.
struct timespec is also not y2038 safe.
Retain timespec for timestamp representation here as ceph
uses it internally everywhere.
These references will be changed to use stru
CURRENT_TIME is not y2038 safe.
The macro will be deleted and all the references to it
will be replaced by ktime_get_* apis.
struct timespec is also not y2038 safe.
Retain timespec for timestamp representation here as ceph
uses it internally everywhere.
These references will be changed to use stru
trace timestamps use struct timespec and CURRENT_TIME which
are not y2038 safe.
These timestamps are only part of the trace log on the machine
and are not shared with the fnic.
Replace then with y2038 safe struct timespec64 and
ktime_get_real_ts64(), respectively.
Signed-off-by: Deepa Dinamani
Cc
All uses of these macors have been replaced by other
time functions.
These macros are also not y2038 safe.
And, all its usecases can be fulfilled by y2038
safe ktime_get_* variants.
Signed-off-by: Deepa Dinamani
Cc: John Stultz
Cc: Thomas Gleixner
---
include/linux/time.h | 3 ---
1 file chang
This is in preparation for the patch that transitions
vfs timestamps to use 64 bit time and hence make them
y2038 safe.
CURRENT_TIME macro will be deleted before merging the
aforementioned patch.
Filesystem times will use current_fs_time() instead of
CURRENT_TIME.
Use ktime_get_real_ts() here as
CURRENT_TIME_SEC is not y2038 safe.
Replace use of CURRENT_TIME_SEC with ktime_get_real_seconds
in segment timestamps used by GC algorithm including the
segment mtime timestamps.
Signed-off-by: Deepa Dinamani
Cc: Jaegeuk Kim
Cc: Changman Lee
Cc: Chao Yu
Cc: linux-f2fs-de...@lists.sourceforge.
CURRENT_TIME macro is not appropriate for filesystems as it
doesn't use the right granularity for filesystem timestamps.
Use current_fs_time() instead.
This is also in preparation for the patch that transitions
vfs timestamps to use 64 bit time and hence make them
y2038 safe. As part of the effort
This is in preparation for the change that transitions
filesystem timestamps to use 64 bit time and hence make
them y2038 safe.
CURRENT_TIME macro will be deleted before merging the
aforementioned patch.
Filesystems will use current_fs_time() instead of
CURRENT_TIME.
Use get_seconds() here as thi
CURRENT_TIME macro is not appropriate for filesystems as it
doesn't use the right granularity for filesystem timestamps.
Use current_fs_time() instead.
This is also in preparation for the patch that transitions
vfs timestamps to use 64 bit time and hence make them
y2038 safe. As part of the effort
time_to_tm() takes time_t as an argument.
time_t is not y2038 safe.
Add time64_to_tm() that takes time64_t as an argument
which is y2038 safe.
The plan is to eventually replace all calls to time_to_tm()
by time64_to_tm().
Signed-off-by: Deepa Dinamani
Cc: John Stultz
Cc: Thomas Gleixner
---
in
struct timespec is not y2038 safe.
Use time64_t which is y2038 safe to represent orphan
scan times.
time64_t is sufficient here as only the seconds delta
times are relevant.
Also use appropriate time functions that return time in
time64_t format. Time functions now return monotonic
time instead of
struct timespec is not y2038 safe.
Audit timestamps are recorded in string format into
an audit buffer for a given context.
These mark the entry timestamps for the syscalls.
Use y2038 safe struct timespec64 to represent the times.
The log strings can handle this transition as strings can
hold upto
CURRENT_TIME is not y2038 safe.
Use y2038 safe ktime_get_real_seconds() here for timestamps.
struct heartbeat_block's hb_seq is already 64 bits wide and
accommodates times beyond y2038.
Signed-off-by: Deepa Dinamani
Cc: Mark Fasheh
Cc: Joel Becker
Cc: ocfs2-de...@oss.oracle.com
---
fs/ocfs2/
jfs uses nanosecond granularity for filesystem timestamps.
Only this assignemt is not using nanosecond granularity.
Use current_fs_time() to get the right nanosecond granularity.
Signed-off-by: Deepa Dinamani
Cc: Dave Kleikamp
Cc: jfs-discuss...@lists.sourceforge.net
---
fs/jfs/ioctl.c | 4 ++--
Hello Julian,
It was an assumption on my part that the firmware supports a SET
function. I realize it was premature to do so. I am sending another
patch to convert the ath6kl_set_antenna() to a NO-OP. This will take
care of the kernel warning, but would not fire any commands to
firmware. I hope th
On 06/08/2016 07:22 PM, Shuah Khan wrote:
> Add CONFIG_EXYNOS_IOMMU in not set mode to make it easier to enable it.
Hmmm... How does it make it easier? Enabling such item is just adding
new line, so what is the problem solved here?
Anyway the line will disappear on first savedefconfig (because it
(Cc'ing netdev...)
On Mon, Jun 6, 2016 at 1:24 PM, Steven Caron wrote:
> Back in 2011, Bill Sommerfeld submitted an update to prevent ip_append_data
> to create malformed packets:
> Commit: d9be4f7a6f5a8da3133b832eca41c3591420b1ca
>
> Now we're finding that we need to apply the same logic to ip
On Thu, Jun 02, 2016 at 07:38:58AM -0500, Shreyas B. Prabhu wrote:
...
> +/* Power Management - PSSCR Fields */
It might be nice to give the full name of the register, as below with the FPSCR.
> +#define PSSCR_RL_MASK0x000F
> +#define PSSCR_MTL_MASK 0x00F0
On Wed, 2016-06-08 at 16:12 +0300, Sagi Grimberg wrote:
> >> *) Extensible to multiple types of backend drivers.
> >>
> >> nvme-target needs a way to absorb new backend drivers, that
> >> does not effect existing configfs group layout or attributes.
> >>
> >> Looking at the nvmet/configfs layout as
Hi all,
Today's linux-next merge of the tip tree got a conflict in:
drivers/powercap/intel_rapl.c
between commit:
9b1d0794b70d ("powercap / RAPL: add support for Skylake-X")
from the pm tree and commit:
62d167330679 ("x86, powercap, rapl: Use Intel model macros intead of
open-coding")
> -Original Message-
> From: linux-kernel-ow...@vger.kernel.org [mailto:linux-kernel-
> ow...@vger.kernel.org] On Behalf Of Andi Kleen
> Sent: Tuesday, May 31, 2016 4:23 PM
> To: x...@kernel.org
> Cc: linux-kernel@vger.kernel.org; Andi Kleen
> Subject: [PATCH] x86/microcode/intel: Quiete
Hi,
[auto build test WARNING on pm/linux-next]
[also build test WARNING on v4.7-rc2 next-20160608]
[if your patch is applied to the wrong git tree, please drop us a note to help
improve the system]
url:
https://github.com/0day-ci/linux/commits/dbasehore-chromium-org/Add-suspend-to-idle
Remove superfluous stack frame, saving us 3 instructions for every
LD_ABS or LD_IND.
Signed-off-by: Zi Shen Lim
---
arch/arm64/net/bpf_jit_comp.c | 3 ---
1 file changed, 3 deletions(-)
diff --git a/arch/arm64/net/bpf_jit_comp.c b/arch/arm64/net/bpf_jit_comp.c
index 7ae304e..b2fc97a 100644
---
Remove superfluous stack frame, saving us 3 instructions for
every JMP_CALL.
Signed-off-by: Zi Shen Lim
---
arch/arm64/net/bpf_jit_comp.c | 3 ---
1 file changed, 3 deletions(-)
diff --git a/arch/arm64/net/bpf_jit_comp.c b/arch/arm64/net/bpf_jit_comp.c
index 51abc97..7ae304e 100644
--- a/arch/a
Add support for JMP_CALL_X (tail call) introduced by commit 04fd61ab36ec
("bpf: allow bpf programs to tail-call other bpf programs").
bpf_tail_call() arguments:
ctx - context pointer passed to next program
array - pointer to map which type is BPF_MAP_TYPE_PROG_ARRAY
index - index inside ar
Commit 0fc174dea545 ("ebpf: make internal bpf API independent of
CONFIG_BPF_SYSCALL ifdefs") introduced usage of ERR_PTR() in
bpf_prog_get(), however did not include linux/err.h.
Without this patch, when compiling arm64 BPF without CONFIG_BPF_SYSCALL:
...
In file included from arch/arm64/net/bpf_j
Hi Linus,
Please pull !
Thx,
-Vineet
>
The following changes since commit 1a695a905c18548062509178b98bc91e67510864:
Linux 4.7-rc1 (2016-05-29 09:29:24 -0700)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/vgupta/arc.git/ tags/arc-4.7-
Updates for arm64 eBPF JIT.
The main addition here is implementation of bpf_tail_call.
#1: Fix missing header inclusion in linux/bpf.h.
#2: Add bpf_tail_call for arm64.
#3,4: Optimizations to reduce instruction count for jitted code.
Changes since v2:
- None. Resubmit per David Miller.
Changes
Hi Kees,
On Wed, 8 Jun 2016 19:56:38 -0700 Kees Cook wrote:
>
> Congratulations on having the gcc plugin development headers
> successfully installed! ;)
Thanks :-)
> Ah, yes, that should default to off. We'll get a fix landed ASAP.
Note that this was an allmodconfig build. The default is 'n'
Hi all,
On Thu, 9 Jun 2016 13:59:32 +1000 Stephen Rothwell
wrote:
>
> 50d14ab0130a ("dm: move request-based code out to dm-rq.[hc]")
By the way, resolving these conflicts would have been easier if this
commit had been split into "move with no changes" followed by "small
changes" commits.
--
Hi all,
Today's linux-next merge of the device-mapper tree got a conflict in:
drivers/md/dm.c
between commit:
528ec5abe680 ("dm: pass dm stats data dir instead of bi_rw")
c2df40dfb8c0 ("drivers: use req op accessor")
3a5e02ced11e ("block, drivers: add REQ_OP_FLUSH operation")
from the
On (06/06/16 15:05), Vlastimil Babka wrote:
[..]
> I think this does fix the inconsistency, thanks.
>
> But looking at collapse_huge_page() as of latest -next, I wonder if there's
> another problem:
>
> pmd = mm_find_pmd(mm, address);
> ...
> up_read(&mm->mmap_sem);
> down_write(&mm->mmap_sem);
>
Hi all,
On Thu, 9 Jun 2016 13:26:09 +1000 Stephen Rothwell
wrote:
>
> Today's linux-next merge of the block tree got conflicts in:
>
> fs/f2fs/data.c
> fs/f2fs/segment.c
>
> between commits:
>
> 0a87f664d1ad ("f2fs: detect congestion of flush command issues")
> 19a5f5e2ef37 ("f2fs: dr
On Wed, 2016-06-08 at 14:19 +0200, Christoph Hellwig wrote:
> On Tue, Jun 07, 2016 at 10:21:41PM -0700, Nicholas A. Bellinger wrote:
> > *) Extensible to multiple types of backend drivers.
> >
> > nvme-target needs a way to absorb new backend drivers, that
> > does not effect existing configfs gro
> "Long" == Long Li writes:
Long,
Long> The problem I'm trying to solve is that, I want to have lower
Long> layer driver to setup max_sectors bigger than
Long> BLK_DEF_MAX_SECTORS.
Capping at BLK_DEF_MAX_SECTORS unless a device has explicitly reported
requirements is intentional. We have no
Hi Jens,
Today's linux-next merge of the block tree got conflicts in:
fs/f2fs/data.c
fs/f2fs/segment.c
between commits:
0a87f664d1ad ("f2fs: detect congestion of flush command issues")
19a5f5e2ef37 ("f2fs: drop any block plugging")
from the f2fs tree and commits:
4e49ea4a3d27 ("bloc
Welcome To Direct Cash Loan At 3.5% Interest Rate!!!
Dear Valued Customer,
Consolidate your debts with Direct Cash Loan SA for your peace of mind at a
fixed interest rate of 3.5%, personal and business loans are also welcome.For
details open enclosed documents and file in your applications by
On 09-06-16, 01:45, Rafael J. Wysocki wrote:
> From: Rafael J. Wysocki
>
> There's no reason for gov_cancel_work() to exist at all, as it only
> has one caller and the only thing done by that caller is to invoke
> gov_cancel_work().
>
> Accordingly, drop gov_cancel_work() and move its contents t
Naveen, can you point out where in the patch you update the variable:
idx, a member of codegen_contex structure? Somehow I am unable to
figure it out. I can only see that we set it to 0 in the
bpf_int_jit_compile function. Since all your test cases pass, I am
clearly overlooking something.
Than
Sorry Please neglect the footer. Forgot to configure some settings.
> Hi All,
>
> We are planning to write a PCIe EndPoint DMA driver with DMA Framework
> on x86 machine.
> ("https://www.kernel.org/doc/Documentation/dmaengine/provider.txt";)
> We are targeting to measure PCIe performance with this
h8300 builds fail with
arch/h8300/include/asm/io.h:9:15: error: unknown type name ‘u8’
arch/h8300/include/asm/io.h:15:15: error: unknown type name ‘u16’
arch/h8300/include/asm/io.h:21:15: error: unknown type name ‘u32’
and many related errors.
Fixes: 23c82d41bdf4 ("kexec-allow-architectures-to-o
From: Derek Basehore
Adds a new feature to clockevents to schedule wakeups on a CPU during
freeze. These won't fully wake up the system, but allow simple
platform callbacks that don't require device support to be run during
freeze with little power impact.
This implementation allows an idle driv
On Thu, 2016-06-09 at 09:43 +0800, Su Xuemin wrote:
> On Wed 2016-06-08 at 08:43 -0700, Eric Dumazet wrote:
> > I am not convinced this is the right way to fix the issue.
> >
> > Fact that you did not change udp4_lib_lookup2() is telling me something.
> >
> >
> > 1) If host has 100 different IP,
From: Derek Basehore
This adds support to the clock event devices created by apic to use
timed freeze. The apic is able to run a timer during freeze with near
izero impact on modern CPUs such as skylake. This will allow S0ix,
suspend-to-idle, to be validated on Intel CPUs that support it.
This i
From: Derek Basehore
This adds error reporting for cpuidle to freeze so suspend-to-idle can
report errors when the CPU/SoC is unable to idle properly. Freeze will
abort when an error is encounted.
Signed-off-by: Derek Basehore
---
drivers/acpi/processor_idle.c | 10 ++
drivers/cpuidle/
In previous version, cpu_pm_enter is invoked after the governor
select the state, which cause the executing time of cpu_pm_enter
is included in the idle time. Moving it before the state selection.
Signed-off-by: Zhaoyang Huang
---
kernel/sched/idle.c | 18 --
1 file changed, 12
From: Derek Basehore
This patch set adds support for catching errors when entering freeze
on Intel Skylake SoCs. Support for this can be added to newer SoCs in
later patches.
Verification is done by waking up the CPU up to 1000 seconds later
based on base 10 exponential backoff from 1 second to
From: Derek Basehore
This adds validation of S0ix entry and enables it on Skylake. Using
the new timed_freeze function, we program the CPU to wake up X seconds
after entering freeze. After X seconds, it will wake the CPU to check
the S0ix residency counters and make sure we entered the lowest pow
From: Derek Basehore
This creates an inline function of intel_pmc_slp_s0_counter_read for
!CONFIG_INTEL_PMC_CORE.
Signed-off-by: Derek Basehore
---
arch/x86/include/asm/pmc_core.h | 6 +-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/arch/x86/include/asm/pmc_core.h b/arch/x8
Hi Zhang
Can you check this email ?
> > Thank you for your help
> >
> > > > non thermal-zon
> > > > sensor command: OK
> > > > read from /sys/class/thermal/thermal_zone0 : OK
> > > >
> > > > thermal-zon
> > > > sensor command: NG
> > > >
Hi All,
We are planning to write a PCIe EndPoint DMA driver with DMA Framework on x86
machine. ("https://www.kernel.org/doc/Documentation/dmaengine/provider.txt";)
We are targeting to measure PCIe performance with this Framework driver.
But I did not find any PCIe driver with DMA Framework. Ple
Hi David
ping ?
> These removes unneeded error message from Renesas DU driver.
> Current this unneeded error message makes user confuse.
>
> Kuninori Morimoto (2):
> drm: rcar-du: error message is not needed for drm_vblank_init()
> drm: rcar-du: error message is not needed for EPROB
Asynchronous wb switching of inodes takes an additional ref count on an
inode to make sure inode remains valid until switchover is completed.
However, it is possible that inode->i_count has already reached zero
while inode is in writeback queue:
[ cut here ]
WARNING: CPU:
On Wed, Jun 8, 2016 at 7:22 PM, Stephen Rothwell wrote:
> Hi Michal,
>
> After merging the kbuild tree, today's linux-next build (x86_64
> allmodconfig) produced these warnings:
>
> Cyclomatic Complexity 1 scripts/mod/devicetable-offsets.c:main
> Cyclomatic Complexity 1 kernel/bounds.c:foo
> Cyclo
It used to be the case that state had an rwlock that was locked for write
by downgrades, but for read for upgrades (opens). Well, the problem is
if there are two competing opens for the same state, they step on
each other toes potentially leading to leaking file descriptors
from the state structure
On Wed, 8 Jun 2016 18:38:02 -0700
Omar Sandoval wrote:
> From: Omar Sandoval
>
> ftrace is very quick to give up on saving the task command line (see
> `trace_save_cmdline()`). The workaround for events which really care
> about the command line is to explicitly assign it as part of the entry.
Hi All,
We are planning to write a PCIe EndPoint DMA driver with DMA Framework on x86
machine. ("https://www.kernel.org/doc/Documentation/dmaengine/provider.txt";)
We are targeting to measure PCIe performance with this Framework driver.
But I did not find any PCIe driver with DMA Framework. Plea
Hi Felipe and Heikki,
On 06/08/2016 12:42 PM, Greg Kroah-Hartman wrote:
> On Thu, Jun 02, 2016 at 09:37:23AM +0800, Lu Baolu wrote:
>> Add support to retrieve fixed voltage configure information through
>> ACPI interface. This is needed for Intel Bay Trail devices, where a
>> GPIO is used to contr
Hi Greg,
On 06/08/2016 11:45 PM, Greg Kroah-Hartman wrote:
> On Wed, Jun 08, 2016 at 03:56:04PM +0800, Lu Baolu wrote:
>> Hi Greg,
>>
>> On 06/08/2016 12:45 PM, Greg Kroah-Hartman wrote:
>>> On Thu, Jun 02, 2016 at 09:37:28AM +0800, Lu Baolu wrote:
In some Intel platforms, a single usb port i
On Wed, Jun 08, 2016 at 08:44:53PM -0400, Vivien Didelot wrote:
> Extract the allocation and registration code related to the dsa_switch
> structure in a mv88e6xxx_register_switch helper function.
>
> For symmetry in the code, add a mv88e6xxx_unregister_switch function.
You say what you are doing
On Wed, Jun 08, 2016 at 08:44:52PM -0400, Vivien Didelot wrote:
> The MDIO device probe and remove functions are respectively incrementing
> and decrementing the bus refcount themselves. Since these bus level
> actions are out of the device scope, remove them.
I agree with the patch. But have you
Hi
On Thu, Jun 9, 2016 at 3:03 AM, Rob Herring wrote:
> On Tue, Jun 07, 2016 at 11:29:02AM +0200, Krzysztof Kozlowski wrote:
>> On 06/03/2016 04:02 AM, Rob Herring wrote:
>> >> Optional properties:
>> >> - reset-gpios : contains a list of GPIO specifiers. The reset GPIOs are
>> >> asserted
>>
On 6/8/2016 6:31 PM, Rafael J. Wysocki wrote:
> On Sun, May 29, 2016 at 12:01 AM, Sinan Kaya wrote:
>> The device tree code checks for the presence of a reset driver and calls
>> the of_reset function pointer by looking up the reset driver as a module.
>>
>> ACPI defines _RST method to perform dev
On Wed, Jun 08, 2016 at 08:44:51PM -0400, Vivien Didelot wrote:
> In the MDIO probing function, dev is already assigned to &mdiodev->dev
> and np is already assigned to mdiodev->dev.of_node, so use them.
>
> Signed-off-by: Vivien Didelot
Reviewed-by: Andrew Lunn
Andrew
On Wed, Jun 08, 2016 at 08:44:50PM -0400, Vivien Didelot wrote:
> The chip->ds and ds->slave_mii_bus assignments are common to both legacy
> and new MDIO probing and are already done in the later setup code.
>
> Remove the duplicated assignments from the MDIO probing code.
>
> Signed-off-by: Vivi
On Wed, Jun 08, 2016 at 08:44:49PM -0400, Vivien Didelot wrote:
> This patch fixes 5 style problems reported by checkpatch:
>
> WARNING: suspect code indent for conditional statements (8, 24)
> #492: FILE: drivers/net/dsa/mv88e6xxx.c:492:
> + if (phydev->link)
> + r
1 - 100 of 1227 matches
Mail list logo
