On Mon, 04 Apr 2016, Michal Hocko wrote:
Not sure I got your point here.
You set current to TASK_KILLABLE in the sleep loop, why do you want to change
it here to TASK_RUNNING if its about to be killed? At least in the case of
UNINTERRUPTABLE we do it merely as a redundancy after the breaking o
Hi,
On Monday 28 March 2016 20:15:46 Irina Tirdea wrote:
> When reading gyroscope axes using iio buffers, the values
> returned are always 0. In the interrupt handler, the return
> value of the read operation is returned to the user instead
> of the value read. Return the value read to the user.
>
On 2016/04/07 10:00AM, Ananth N wrote:
> On Wed, Apr 06, 2016 at 06:02:57PM +0530, Naveen N. Rao wrote:
>
> > + if (!pev->uprobes && map->dso->symtab_type == DSO_BINARY_TYPE__KALLSYMS)
> > tev->point.offset += PPC64LE_LEP_OFFSET;
>
> uprobes check against kallsysms? Am I missing som
So I recently got made aware of the fact that cgroupv2 doesn't allow
tasks to be associated with !leaf cgroups, this is yet another
capability of cpu-cgroup you've destroyed.
At this point I really don't see why I should spend another second
considering anything v2.
So full NAK and stop wasting
On Wed, Apr 06, 2016 at 05:53:07PM -0400, Tejun Heo wrote:
> Can you list applications which make use of CLONE_VM without
> CLONE_THREAD?
I ran into one two years ago or so; I forgot what it was, but it made
perf misbehave because we too had assumed this not to happen.
Eventually it turned out a
On Wed, Apr 6, 2016 at 9:45 PM, Andi Kleen wrote:
> zengzhao...@163.com writes:
>
>> From: Zhaoxiu Zeng
>>
>> Use alternatives, lifted from arch_hweight
>
> Is there actually anything performance critical in the kernel that uses
> parity?
>
> FWIW the arch hweight custom calling convention is a p
2016-03-21 20:12 GMT+08:00 Axel Lin :
> devm_kzalloc() returns NULL on failure.
Hi,
I'm wondering if this trivial fix is lost.
Should I resend it?
On 7 April 2016 at 12:56, Felipe Balbi wrote:
>
> Hi,
>
> Peter Chen writes:
>> On Wed, Apr 06, 2016 at 01:25:06PM +0300, Felipe Balbi wrote:
>>>
>>> Hi,
>>>
>>> Peter Chen writes:
>>> > On Wed, Apr 06, 2016 at 11:05:26AM +0300, Felipe Balbi wrote:
>>> >> Peter Chen writes:
>>> >> > On Wed, Apr
Jiri Kosina writes:
> Hi,
>
> after updating to 4.6-rcX (where X is 1 or 2, doesn't really matter) on
> thinkpad x200s notebook with
>
> 00:02.0 VGA compatible controller: Intel Corporation Mobile 4 Series
> Chipset Integrated Graphics Controller (rev 07)
>
> closing and opening the lid f
Hi Linus,
This is mostly amdgpu/radeon fixes, and imx related fixes.
There are also one one TTM fix, one nouveau fix, and one hdlcd fix.
The AMD ones are some fixes for power management after suspend/resume
one some GPUs, and some vblank fixes.
The IMX ones are for more stricter plane checks a
Hi, Robert
I'm woking with a board which integrated PXA310 on it. While
Debugging U2DC controller, found that once U2DC Controller have been
started, It couldn't be stopped completely. The windows shows unknown
device while Stopping U2DC and Usb line haven't been unplugged from PC
Have
This just adds user space exported ABI definitions for both 16MB and
16GB non default huge page sizes to be used with mmap() system call.
Signed-off-by: Anshuman Khandual
---
arch/powerpc/include/uapi/asm/mman.h | 3 +++
1 file changed, 3 insertions(+)
diff --git a/arch/powerpc/include/uapi/asm
Currently the function 'huge_pte_offset' has just got one version for all
possible configurations and platforms. This change splits that function
into two versions, first one for ARCH_WANT_GENERAL_HUGETLB implementation
and the other one for everything else. This change is again one of the
prerequi
This adds two tests for memory page migration. One for normal page
migration which works for both 4K or 64K base page size kernel and
the other one is for huge page migration which works only on 64K
base page sized 16MB huge page implemention at the PMD level.
Signed-off-by: Anshuman Khandual
---
Currently the config ARCH_WANT_GENERAL_HUGETLB enabled functions like
'huge_pte_alloc' and 'huge_pte_offset' dont take into account HugeTLB
page implementation at the PGD level. This is also true for functions
like 'follow_page_mask' which is called from move_pages() system call.
This lack of PGD l
Currently the function 'huge_pte_alloc' has got two versions, one for the
BOOK3S server and the other one for the BOOK3E embedded platforms. This
change splits only the BOOK3S server version into two parts, one for the
ARCH_WANT_GENERAL_HUGETLB config implementation and the other one for
everything
The commit 091d0d55b286 ("shm: fix null pointer deref when userspace
specifies invalid hugepage size") had replaced MAP_HUGE_MASK with
SHM_HUGE_MASK. Though both of them contain the same numeric value of
0x3f, MAP_HUGE_MASK flag sounds more appropriate than the other one
in the context. Hence chang
follow_huge_(pmd|pud|pgd) functions are used to walk the page table and
fetch the page struct during 'follow_page_mask' call. There are possible
race conditions faced by these functions which arise out of simultaneous
calls of move_pages() and freeing of huge pages. This was fixed partly
by the pre
This enables ARCH_WANT_GENERAL_HUGETLB config option only for BOOK3S
platforms with 64K page size implementation. Existing arch specific
functions for ARCH_WANT_GENERAL_HUGETLB config like 'huge_pte_alloc'
and 'huge_pte_offset' are no longer required and are removed with
this change.
Signed-off-by
Arch override function 'follow_huge_addr' is called from 'follow_page_mask'
looking out for the associated page struct. Right now, it does not support
the FOLL_GET option.
With ARCH_WANTS_GENERAL_HUGETLB, we will need function 'follow_page_mask'
to use generic 'follow_huge_*' functions instead of
This change enables the config option ARCH_ENABLE_HUGEPAGE_MIGRATION
depending on whether the platform has got ARCH_WANT_GENERAL_HUGETLB
or not along with config option MIGRATION. In turn, it turns on the
'hugepage_migration_supported' function which is checked for feature
presence during HugeTLB p
This patch series enables HugeTLB page migration on POWER platform.
This series has some core VM changes (patch 1, 2, 3) and some powerpc
specific changes (patch 4, 5, 6, 7, 8, 9, 10). Comments, suggestions
and inputs are welcome.
Anshuman Khandual (10):
mm/mmap: Replace SHM_HUGE_MASK with MAP_H
Hello,
On 2016-04-06 22:33, Alison Schofield wrote:
On Wed, Apr 06, 2016 at 09:03:00AM +0200, Marek Szyprowski wrote:
Hello,
On 2016-04-06 07:15, Alison Schofield wrote:
Driver includes struct regmap and struct device in its global data.
Remove the struct device and use regmap API to retrieve
This patch updates the device-tree binding doc for
adding support for AXI DMA.
Also this patch differentiates required properties b/w
DMA and VDMA.
Signed-off-by: Kedareswara rao Appana
---
Changes for v4:
---> None.
Changes for v3:
---> Removed AXI DMA DT example from the patch as suggested by R
This patch adds support for the AXI Direct Memory Access (AXI DMA)
core in the existing vdma driver, AXI DMA Core is a
soft Xilinx IP core that provides high-bandwidth
direct memory access between memory and AXI4-Stream
type target peripherals.
Signed-off-by: Kedareswara rao Appana
---
Changes fo
This patch updates the device-tree binding doc for
adding support for AXI CDMA.
Signed-off-by: Kedareswara rao Appana
---
Changes for v4:
---> None.
Changes for v3:
---> Removed CDMA DT example from the patch as suggested by the Rob.
Changes for v2:
---> Modified commit message as suggested by Vi
This patch series does some enhancments to the VDMA driver
which includes
--> Adding support for AXI DMA IP.
--> Adding support for AXI CDMA IP.
Kedareswara rao Appana (5):
dmaengine: vdma: Rename xilinx_vdma_ prefix to xilinx_dma
Documentation: DT: vdma: update binding doc for AXI DMA
dmaen
This patch adds support for the AXI Central Direct Memory Access
(AXI CDMA) core to the existing vdma driver, AXI CDMA is a
soft Xilinx IP core that provides high-bandwidth
Direct Memory Access(DMA) between a memory-mapped
source address and a memory-mapped destination address.
Signed-off-by: Keda
This patch renames the xilinx_vdma_ prefix to xilinx_dma
for the API's and masks that will be shared b/w three DMA
IP cores.
Signed-off-by: Kedareswara rao Appana
---
Changes for v4:
> Removed renaming of vdma-mm2s/vdma-s2mm channel names.
Changes for v3:
---> None.
Changes for v2:
---> New p
Hi all,
Changes since 20160406:
The akpm-current tree gained a build failure for which I applied a patch.
Non-merge commits (relative to Linus' tree): 2722
2566 files changed, 106575 insertions(+), 66077 dele
Related thread (2012): https://marc.info/?l=linux-netdev&m=133897212713981&w=2
FreeBSD[1] chose signatures of:
int bindat(int fd, int s, const struct sockaddr *addr, socklen_t addrlen);
int connectat(int fd, int s, const struct sockaddr *name,
socklen_t namelen);
An alternate implementati
Hi all,
After merging the tip tree, today's linux-next build (powerpc ppc44x_defconfig)
produced this warning:
mm/gup.c: In function 'get_user_pages_fast':
mm/gup.c:1510:20: warning: unused variable 'mm' [-Wunused-variable]
struct mm_struct *mm = current->mm;
^
Introduced b
On 04/06/2016 10:05 PM, Huang Rui wrote:
On Wed, Apr 06, 2016 at 08:30:25AM -0700, Guenter Roeck wrote:
On Wed, Apr 06, 2016 at 03:44:11PM +0800, Huang Rui wrote:
+static void do_read_registers_on_cu(void *_data)
+{
+ struct fam15h_power_data *data = _data;
+ int cpu, cu;
+
+
On Thu, 7 Apr 2016, Stephen Rothwell wrote:
> Hi Andrew,
>
> After merging the akpm-current tree, today's linux-next build (arm
> multi_v7_defconfig) failed like this:
>
> In file included from include/linux/linkage.h:4:0,
> from include/linux/fs.h:4,
> from mm/
HI
"Du, Changbin" writes:
>> before I review your patches, one comment
>>
>> changbin...@intel.com writes:
>> > From: "Du, Changbin"
>> >
>> > The first patch removed unnecessary checking for debugfs api call;
>> > The second patch fix a memory leak issue;
>> > The third patch add one new entr
> before I review your patches, one comment
>
> changbin...@intel.com writes:
> > From: "Du, Changbin"
> >
> > The first patch removed unnecessary checking for debugfs api call;
> > The second patch fix a memory leak issue;
> > The third patch add one new entry to debufs.
> >
> > Du, Changbin (3)
Hi Andrew,
After merging the akpm-current tree, today's linux-next build (arm
multi_v7_defconfig) failed like this:
In file included from include/linux/linkage.h:4:0,
from include/linux/fs.h:4,
from mm/shmem.c:24:
In function 'shmem_disband_hugeteam',
inlined
changbin...@intel.com writes:
> From: "Du, Changbin"
>
no commit log == no commit, sorry
> Signed-off-by: Du, Changbin
> ---
> drivers/usb/dwc3/debugfs.c | 3 +++
> 1 file changed, 3 insertions(+)
>
> diff --git a/drivers/usb/dwc3/debugfs.c b/drivers/usb/dwc3/debugfs.c
> index 071b286..2d4f39
Hi,
before I review your patches, one comment
changbin...@intel.com writes:
> From: "Du, Changbin"
>
> The first patch removed unnecessary checking for debugfs api call;
> The second patch fix a memory leak issue;
> The third patch add one new entry to debufs.
>
> Du, Changbin (3):
> usb: dwc
On Wed, Apr 06, 2016 at 08:30:25AM -0700, Guenter Roeck wrote:
> On Wed, Apr 06, 2016 at 03:44:11PM +0800, Huang Rui wrote:
> >
> > +static void do_read_registers_on_cu(void *_data)
> > +{
> > + struct fam15h_power_data *data = _data;
> > + int cpu, cu;
> > +
> > + cpu = smp_processor_id();
Hi,
Greg Kroah-Hartman writes:
> On Wed, Apr 06, 2016 at 01:19:04PM +0300, Felipe Balbi wrote:
>> > What happened to getting internal help in designing this api? This
>> > shouldn't be my job :)
>>
>> I looked at this Baolu but, at least to me, it's unclear what you're
>> hinting here. Sure, t
Hi,
Peter Chen writes:
>> >> > In below change of usb_gadget_vbus_draw(), already can get charger
>> >> > type via usb_charger_get_type().
>> >> >
>> >> > static inline int usb_gadget_vbus_draw(struct usb_gadget *gadget,
>> >> > unsigned mA) {
>> >> > + enum usb_charger_type type;
>> >> >
Galileo Gen2 board uses the PCAL9535 as the GPIO expansion,
it is different from PCA9535 and includes interrupt mask/status registers,
The current driver does not support the interrupt registers configuration,
it causes some gpio pins cannot trigger interrupt events,
this patch fix this issue. The
Hi,
Peter Chen writes:
> On Wed, Apr 06, 2016 at 01:25:06PM +0300, Felipe Balbi wrote:
>>
>> Hi,
>>
>> Peter Chen writes:
>> > On Wed, Apr 06, 2016 at 11:05:26AM +0300, Felipe Balbi wrote:
>> >> Peter Chen writes:
>> >> > On Wed, Apr 06, 2016 at 10:38:23AM +0300, Felipe Balbi wrote:
>> >> >>
On Wed, Apr 6, 2016 at 7:02 AM, Waiman Long wrote:
> On a large system with many CPUs, using HPET as the clock source can
> have a significant impact on the overall system performance because
> of the following reasons:
> 1) There is a single HPET counter shared by all the CPUs.
> 2) HPET counte
On Fri, Apr 1, 2016 at 4:40 PM, Tony Lindgren wrote:
> * Tony Lindgren [160401 14:37]:
>> We currently try to match of_dev_auxdata based on compatible,
>> IO address, and device name. But in some cases we have multiple
>> instances of drivers that can use the same auxdata.
>>
>> Let's add an addi
On Wed, 2016-04-06 at 14:00 +0200, Mike Galbraith wrote:
> It'll take a hotplug beating seemingly as well as any non-rt kernel,
> but big box NAKed it due to jitter, which can mean 1.0 things.. duh.
FWIW, the below turned big box NAK into ACK. Stressing hotplug over
night, iteration completion ti
On Wed, Apr 06, 2016 at 06:02:57PM +0530, Naveen N. Rao wrote:
> + if (!pev->uprobes && map->dso->symtab_type == DSO_BINARY_TYPE__KALLSYMS)
> tev->point.offset += PPC64LE_LEP_OFFSET;
uprobes check against kallsysms? Am I missing something here?
Ananth
On 07-04-16, 03:31, Rafael J. Wysocki wrote:
> From: Rafael J. Wysocki
>
> Reorganize the code in cpufreq_add_dev() to avoid using the ret
> variable and reduce the indentation level in it.
>
> No functional changes.
>
> Signed-off-by: Rafael J. Wysocki
> ---
> drivers/cpufreq/cpufreq.c | 2
On 07-04-16, 03:30, Rafael J. Wysocki wrote:
> From: Rafael J. Wysocki
>
> Merge two switch entries that do the same thing in
> cpufreq_cpu_callback().
>
> No functional changes.
>
> Signed-off-by: Rafael J. Wysocki
> ---
> drivers/cpufreq/cpufreq.c |5 +
> 1 file changed, 1 insertion
On 07-04-16, 03:29, Rafael J. Wysocki wrote:
> From: Rafael J. Wysocki
>
> Since governor operations are generally skipped if cpufreq_suspended
> is set, do nothing at all in cpufreq_start_governor() and
> cpufreq_exit_governor() in that case.
>
> In particular, this prevents fast frequency swit
Hello.
In August 2013, I have reported this bug:
https://bugzilla.kernel.org/show_bug.cgi?id=60769 . It has been
determined on October 2013 to be a bug with IOMMU. The bug manifests
itself as either unreliable or completely non-working HDMI audio on
Haswell systems.
However, there have been
The enum value of DP_IRQ_TYPE_HP_CABLE_IN is zero, but driver only
send drm hp event when the irq_type and the enum value is true.
if (irq_type & DP_IRQ_TYPE_HP_CABLE_IN || ...)
drm_helper_hpd_irq_event(dp->drm_dev);
So there would no drm hpd event when cable plug in, to fix that
just nee
Sorry for disturb, I make a mistaken about the
receive list, please ignore this email.
- Yakir
On 04/07/2016 12:15 PM, Yakir Yang wrote:
The enum value of DP_IRQ_TYPE_HP_CABLE_IN is zero, but driver only
send drm hp event when the irq_type and the enum value is true.
if (irq_type & DP_IRQ_TYPE
Hi Yong,
[auto build test WARNING on gpio/for-next]
[also build test WARNING on v4.6-rc2 next-20160406]
[if your patch is applied to the wrong git tree, please drop us a note to help
improving the system]
url:
https://github.com/0day-ci/linux/commits/Yong-Li/gpio-pca953x-add-PCAL9535
drivers/gpio/gpio-pca953x.c:522:10-11: WARNING: return of 0/1 in function
'pca953x_irq_pending' with return type bool
Return statements in functions returning bool should use
true/false instead of 1/0.
Generated by: scripts/coccinelle/misc/boolreturn.cocci
CC: Yong Li
Signed-off-by: Fengguang
The enum value of DP_IRQ_TYPE_HP_CABLE_IN is zero, but driver only
send drm hp event when the irq_type and the enum value is true.
if (irq_type & DP_IRQ_TYPE_HP_CABLE_IN || ...)
drm_helper_hpd_irq_event(dp->drm_dev);
So there would no drm hpd event when cable plug in, to fix that
just nee
On Tue, Apr 5, 2016 at 9:02 PM, Christoph Hellwig wrote:
> On Tue, Apr 05, 2016 at 07:56:54PM +0800, Ming Lei wrote:
>> +++ b/drivers/target/target_core_pscsi.c
>> @@ -951,7 +951,7 @@ pscsi_map_sg(struct se_cmd *cmd, struct scatterlist
>> *sgl, u32 sgl_nents,
>> pr_debug("PS
Hi Vinod,
> -Original Message-
> From: Koul, Vinod [mailto:vinod.k...@intel.com]
> Sent: Thursday, April 07, 2016 5:53 AM
> To: Soren Brinkmann
> Cc: l...@metafoo.de; linux-kernel@vger.kernel.org; pawel.m...@arm.com;
> Appana Durga Kedareswara Rao ;
> l...@debethencourt.com; moritz.fisc..
在 2016年04月06日 18:53, Borislav Petkov 写道:
On Wed, Apr 06, 2016 at 11:37:37AM +0100, One Thousand Gnomes wrote:
Even that would still be wrong for the smaller parity values. The CPU
supports 8bit parity directly going back to the 8086 so the
implementation for 8bit and I think 16bit is still wrong
在 2016年04月07日 03:45, Andi Kleen 写道:
zengzhao...@163.com writes:
From: Zhaoxiu Zeng
Use alternatives, lifted from arch_hweight
Is there actually anything performance critical in the kernel that uses
parity?
FWIW the arch hweight custom calling convention is a problem for LTO
because it needs
在 2016年04月07日 02:44, Sam Ravnborg 写道:
Hi Zeng.
Use runtime patching for sparc64, lifted from hweight
No errors found in patch - but a few comments.
In general patch looks good.
Thanks. Sparc, powerpc, and x86 are all new to me.
+++ b/arch/sparc/include/asm/bitops_64.h
@@ -47,6 +47,24 @@ un
在 2016年04月06日 21:27, Chris Metcalf 写道:
On 4/6/2016 5:08 AM, zengzhao...@163.com wrote:
From: Zhaoxiu Zeng
Signed-off-by: Zhaoxiu Zeng
---
arch/tile/include/asm/bitops.h | 26 ++
1 file changed, 26 insertions(+)
Since all the code you are adding here is architecture-
在 2016年04月06日 18:13, Borislav Petkov 写道:
On Wed, Apr 06, 2016 at 05:14:45PM +0800, zengzhao...@163.com wrote:
From: Zhaoxiu Zeng
Use alternatives, lifted from arch_hweight
Signed-off-by: Zhaoxiu Zeng
---
arch/x86/include/asm/arch_hweight.h | 5 ++
arch/x86/include/asm/arch_parity.h | 1
The mm-of-the-moment snapshot 2016-04-06-20-40 has been uploaded to
http://www.ozlabs.org/~akpm/mmotm/
mmotm-readme.txt says
README for mm-of-the-moment:
http://www.ozlabs.org/~akpm/mmotm/
This is a snapshot of my -mm patch queue. Uploaded at random hopefully
more than once a week.
You wi
On Wed, 2016-04-06 at 20:00 -0400, Tejun Heo wrote:
> Hello, Mike.
>
> On Sun, Mar 13, 2016 at 06:40:35PM +0100, Mike Galbraith wrote:
> > On Sun, 2016-03-13 at 11:00 -0400, Tejun Heo wrote:
> > > Let's say there is an application which wants to manage resource
> > > distributions across its multi
Fixes CHECK: Alignment should match open parenthesis
Signed-off-by: Manav Batra
---
drivers/staging/rts5208/ms.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/staging/rts5208/ms.c b/drivers/staging/rts5208/ms.c
index 3e75db7..0f0cd4a 100644
--- a/drivers/staging/rts
On 7 April 2016 at 09:40, Jaehoon Chung wrote:
> On 04/06/2016 08:57 PM, Jisheng Zhang wrote:
>>
>>
>> On Wed, 6 Apr 2016 19:38:30 +0800 Baolin Wang wrote:
>>
>>> This patch removes some redundant debug prints, since we have added some
>>> tracepoints to help with performance analysis of MMC subs
On 6 April 2016 at 19:57, Jisheng Zhang wrote:
>
>
> On Wed, 6 Apr 2016 19:38:30 +0800 Baolin Wang wrote:
>
>> This patch removes some redundant debug prints, since we have added some
>> tracepoints to help with performance analysis of MMC subsystem.
>
> I think the debug prints you removed are u
On Wed, Apr 06, 2016 at 04:58:03PM +0300, Felipe Balbi wrote:
>
> Hi,
>
> Jun Li writes:
> >> >> >> > Since we already have get_charger_type callback at usb_charger
> >> >> >> > structure, why we still need this API at usb_gadget_ops?
> >> >> >>
> >> >> >> In case some users want to get charger
On Sun, Mar 27, 2016 at 05:10:56PM -0400, Paul Gortmaker wrote:
> The Kconfig currently controlling compilation of this code is:
>
> drivers/bus/Kconfig:config IMX_WEIM
> drivers/bus/Kconfig:bool "Freescale EIM DRIVER
>
> ...meaning that it currently is not being built as a module by anyone.
On Wed, 6 Apr 2016, Ingo Molnar wrote:
> * Hugh Dickins wrote:
>
> > ---
> > Cc'ed to arch maintainers as an FYI: this patch is not expected to
> > go into the tree in the next few weeks, and depends upon a PageTeam
> > definition not yet available outside this huge tmpfs patchset.
> > Please ref
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 items to the current
mandatory
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. Configuration is done using entries i
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 device to its sink with a per-
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 sources will not match those in the STP s
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 t
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 fil
FYI, we noticed below warning "BUG: sleeping function called from invalid
context at kernel/locking/mutex.c:97" showed on
https://github.com/0day-ci/linux
Bastien-Philbert/ipv6-icmp-Add-protection-from-concurrent-users-in-the-function-icmpv6_echo_reply/20160406-053
On Wed, Apr 06, 2016 at 01:25:06PM +0300, Felipe Balbi wrote:
>
> Hi,
>
> Peter Chen writes:
> > On Wed, Apr 06, 2016 at 11:05:26AM +0300, Felipe Balbi wrote:
> >> Peter Chen writes:
> >> > On Wed, Apr 06, 2016 at 10:38:23AM +0300, Felipe Balbi wrote:
> >> >> Peter Chen writes:
> >> >> > On Fr
Hi,
> From: linux-acpi-ow...@vger.kernel.org [mailto:linux-acpi-
> ow...@vger.kernel.org] On Behalf Of Octavian Purdila
> Subject: Re: [RFC PATCH 10/10] acpi: add support for loading SSDTs via
> configfs
>
> On Wed, Apr 6, 2016 at 9:05 AM, Zheng, Lv wrote:
>
> >> It is hard to create new kerne
Hi Gabriele,
On Wed, 6 Apr 2016 14:50:29 + Gabriele Paoloni wrote:
> Hi, sorry to be late on this
>
> > -Original Message-
> > From: linux-kernel-ow...@vger.kernel.org [mailto:linux-kernel-
> > ow...@vger.kernel.org] On Behalf Of Jisheng Zhang
> > Sent: 16 March 2016 11:41
> > To: ji
On 2016/4/7 9:06, kernel test robot wrote:
> FYI, we noticed that will-it-scale.scalability -4.0% regression on
>
> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git master
> commit 6f25a14a7053b69917e2ebea0d31dd444cd31fd5 ("mm: fix invalid node in
> alloc_migrate_target()")
>
On Mon, Apr 04, 2016 at 03:24:34PM +0200, Vlastimil Babka wrote:
> On 04/04/2016 07:12 AM, Minchan Kim wrote:
> >On Fri, Apr 01, 2016 at 11:29:14PM +0200, Vlastimil Babka wrote:
> >>Might have been better as a separate migration patch and then a
> >>compaction patch. It's prefixed mm/compaction, bu
On 04/07/2016 04:10 AM, Jiancheng Xue wrote:
> Hi Brian,
>Thank you very much for your comments. I'll fix these issues in next
> version.
> In addition, for easy understanding I'd like to rewrite hisi_spi_nor_write and
> hisi_spi_nor_read. Your comments on these modifications will be highly
>
On Mon, Apr 04, 2016 at 03:09:22PM +0200, Vlastimil Babka wrote:
> On 04/04/2016 04:25 AM, Minchan Kim wrote:
> >>
> >>Ah, I see, so it's designed with page lock to handle the concurrent
> >>isolations etc.
> >>
> >>In http://marc.info/?l=linux-mm&m=143816716511904&w=2 Mel has warned
> >>about doi
On Wed, Apr 6, 2016 at 7:12 PM, Franklin S Cooper Jr. wrote:
> Hi All,
>
> Currently linux-next is failing to boot via NFS on my AM335x GP evm,
> AM437x GP evm and Beagle X15. I bisected the problem down to the commit
> "udp: remove headers from UDP packets before queueing".
>
> I had to revert th
Galileo Gen2 board uses the PCAL9535 as the GPIO expansion,
it is different from PCA9535 and includes interrupt mask/status registers,
The current driver does not support the interrupt registers configuration,
it causes some gpio pins cannot trigger interrupt events,
this patch fix this issue. The
On Thu, Apr 7, 2016 at 9:56 AM, Eric Wheeler wrote:
> On Thu, 7 Apr 2016, Ming Lei wrote:
>
>> On Thu, Apr 7, 2016 at 9:36 AM, Eric Wheeler
>> wrote:
>> > On Wed, 6 Apr 2016, Ming Lei wrote:
>> >
>> >> After arbitrary bio size is supported, the incoming bio may
>> >> be very big. We have to spli
Hi Brian,
Thank you very much for your comments. I'll fix these issues in next version.
In addition, for easy understanding I'd like to rewrite hisi_spi_nor_write and
hisi_spi_nor_read. Your comments on these modifications will be highly
appreciated.
static int hisi_spi_nor_read(struct spi_nor
On Wed, Apr 06, 2016 at 04:26:33PM -0700, Kees Cook wrote:
> Hi Greg,
>
> Please pull these lkdtm changes for 4.6-rc3. (BTW, should I send these
> lkdtm pulls to you, or to Linus?)
I can take them, not a problem.
Or you send send me patches if that's easier.
> The following changes since commit
On 2016/4/5 23:54, Radim Krčmář wrote:
2016-04-05 14:18+0800, Yang Zhang:
On 2016/4/5 5:00, Rik van Riel wrote:
Given that delivering a timer to a guest seems to
involve trapping from the guest to the host, anyway,
I don't see a downside to your patch.
If that is ever changed (eg. allowing del
On Wed, 6 Apr 2016, Mika Penttila wrote:
> On 04/06/2016 12:53 AM, Hugh Dickins wrote:
> > +static void shmem_recovery_work(struct work_struct *work)
...
> > +
> > + if (head) {
> > + /* We are resuming work from a previous partial recovery */
> > + if (PageTeam(page))
> > +
On Thu, 7 Apr 2016, Ming Lei wrote:
> On Thu, Apr 7, 2016 at 9:36 AM, Eric Wheeler
> wrote:
> > On Wed, 6 Apr 2016, Ming Lei wrote:
> >
> >> After arbitrary bio size is supported, the incoming bio may
> >> be very big. We have to split the bio into small bios so that
> >> each holds at most BIO_
On Thu, Apr 7, 2016 at 9:36 AM, Eric Wheeler wrote:
> On Wed, 6 Apr 2016, Ming Lei wrote:
>
>> After arbitrary bio size is supported, the incoming bio may
>> be very big. We have to split the bio into small bios so that
>> each holds at most BIO_MAX_PAGES bvecs for safety reason, such
>> as bio_cl
On Wed, 6 Apr 2016, Ming Lei wrote:
> On Wed, Apr 6, 2016 at 1:44 AM, Ming Lei wrote:
> > After arbitrary bio size is supported, the incoming bio may
> > be very big. We have to split the bio into small bios so that
> > each holds at most BIO_MAX_PAGES bvecs for safety reason, such
> > as bio_clo
avoid memset in perf_fetch_caller_regs, since it's the critical path of all
tracepoints.
It's called from perf_sw_event_sched, perf_event_task_sched_in and all of
perf_trace_##call
with this_cpu_ptr(&__perf_regs[..]) which are zero initialized by perpcu init
logic and
subsequent call to perf_arc
introduce BPF_PROG_TYPE_TRACEPOINT program type and allow it to be attached
to the perf tracepoint handler, which will copy the arguments into
the per-cpu buffer and pass it to the bpf program as its first argument.
The layout of the fields can be discovered by doing
'cat /sys/kernel/debug/tracing/
Hi Steven, Peter,
v1->v2: addressed Peter's comments:
- fixed wording in patch 1, added ack
- refactored 2nd patch into 3:
2/10 remove unused __perf_addr macro which frees up
an argument in perf_trace_buf_submit
3/10 split perf_trace_buf_prepare into alloc and update parts, so that bpf
programs do
now all calls to perf_trace_buf_submit() pass 0 as 4th
argument which will be repurposed in the next patch which will
change the meaning of 1st arg of perf_tp_event() to event_type
Signed-off-by: Alexei Starovoitov
---
include/trace/perf.h | 7 ++-
include/trace/trace_events.h | 3 --
1 - 100 of 911 matches
Mail list logo
