On Wed, Jan 14, 2015 at 03:34:49PM -0800, Andrew Morton wrote:
> On Wed, 14 Jan 2015 16:55:36 +0300 Vladimir Davydov
> wrote:
> > This patch also makes shrink_slab() return the number of reclaimed slab
> > pages (obtained from reclaim_state) instead of the number of reclaimed
> > objects,
On Thu, 2015-01-15 at 08:33 +0100, Takashi Iwai wrote:
> At Wed, 14 Jan 2015 23:11:43 -0800,
> Davidlohr Bueso wrote:
> >
> > From: Davidlohr Bueso
> >
> > Call __set_current_state() instead of assigning the new state directly.
> > These interfaces also aid CONFIG_DEBUG_ATOMIC_SLEEP
Dear Eric:
3.6 or later kernels (including recent mainline) do not have this problem.
3.4.105 is based on an old kernel, but it is a latest kernel of 3.4 LTS branch.
I think it is better to backport 20 patches to LTS branch.
But if you do not have such support policy, I will apply these patches
Call __set_current_state() instead of assigning the new state directly.
These interfaces also aid CONFIG_DEBUG_ATOMIC_SLEEP environments, keeping
track of who changed the state.
Signed-off-by: Davidlohr Bueso
---
Completely untested.
arch/ia64/kernel/mca.c| 2 +-
arch/ia64/kernel/ptrace.c
Signed-off-by: Michal Simek
---
arch/arm/Kconfig | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index 97d07ed60a0b..da77f786f99f 100644
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@ -1488,7 +1488,7 @@ config ARM_PSCI
# selected
compaction deferring logic is heavy hammer that block the way to
the compaction. It doesn't consider overall system state, so it
could prevent user from doing compaction falsely. In other words,
even if system has enough range of memory to compact, compaction would be
skipped due to compaction
It'd be useful to know current range where compaction work for detailed
analysis. With it, we can know pageblock where we actually scan and
isolate, and, how much pages we try in that pageblock and can guess why
it doesn't become freepage with pageblock order roughly.
Acked-by: Vlastimil Babka
It is not well analyzed that when/why compaction start/finish or not. With
these new tracepoints, we can know much more about start/finish reason of
compaction. I can find following bug with these tracepoint.
http://www.spinics.net/lists/linux-mm/msg81582.html
Change from v2: omit alloc_flag,
We now have tracepoint for begin event of compaction and it prints
start position of both scanners, but, tracepoint for end event of
compaction doesn't print finish position of both scanners. It'd be
also useful to know finish position of both scanners so this patch
add it. It will help to find
Hi hl,
On Thu, Jan 15, 2015 at 2:15 PM, huang lin wrote:
> The AUO b101ean01 panel is a 10.1" 1280x800 panel,
> which can be supported by the simple panel driver.
>
> Signed-off-by: huang lin
>
> ---
>
> Changes in v2:
> - changed panel timing
>
> drivers/gpu/drm/panel/panel-simple.c | 26
To check the range that compaction is working, tracepoint print
start/end pfn of zone and start pfn of both scanner with decimal format.
Since we manage all pages in order of 2 and it is well represented by
hexadecimal, this patch change the tracepoint format from decimal to
hexadecimal. This
We had to insert a preempt enable/disable in the fastpath a while ago
in order to guarantee that tid and kmem_cache_cpu are retrieved on the
same cpu. It is the problem only for CONFIG_PREEMPT in which scheduler
can move the process to other cpu during retrieving data.
Now, I reach the solution
compound_head() is implemented with assumption that there would be
race condition when checking tail flag. This assumption is only true
when we try to access arbitrary positioned struct page.
The situation that virt_to_head_page() is called is different case.
We call virt_to_head_page() only in
Hi,
Am 15.01.2015 um 01:59 schrieb Dmitry Torokhov :
> On Sat, Jan 10, 2015 at 03:15:39PM +0100, Belisko Marek wrote:
>> Ping for input maintainer. DT changes was acked. Thanks.
>>
>> On Tue, Sep 30, 2014 at 10:17 PM, Marek Belisko wrote:
>>> This patch adds new parameters that allow to
Hi Clark, John,
On Mon, 2014-11-10 at 10:16 +0300, Alexey Brodkin wrote:
> Some architectures are still stuck with non-NPTL toolchains.
> These are for example ARC, Blackfin, Xtensa etc.
>
> Still rt-tests are very good benchmarks and it would be good to enable use of
> at least selected (those
At Wed, 14 Jan 2015 23:11:43 -0800,
Davidlohr Bueso wrote:
>
> From: Davidlohr Bueso
>
> Call __set_current_state() instead of assigning the new state directly.
> These interfaces also aid CONFIG_DEBUG_ATOMIC_SLEEP environments, keeping
> track of who changed the state.
>
> Signed-off-by:
On Thu, Jan 15, 2015 at 12:08:40AM +0300, Dan Carpenter wrote:
> The code here is checking for IS_ERR() when request_mem_region() only
> returns NULL on error and never an ERR_PTR.
>
> Signed-off-by: Dan Carpenter
>
> diff --git a/drivers/mcb/mcb-pci.c b/drivers/mcb/mcb-pci.c
> index
A card insertion happens after the lastest polling before reader is
suspended may never have a chance to be detected. Under current 1-HZ
polling interval setting in mmc_core, the worst case of such
undetectablility is about 1 second.
To further reduce the undetectability, detect card slot again
The patchset fixes a deadlock situation of runtime PM methods and minimize
card detection "deadtime" during runtime suspending.
Roger Tseng (2):
mfd: rtsx_usb: Fix runtime PM deadlock
mfd: rtsx_usb: Defer autosuspend while card exists
drivers/mfd/rtsx_usb.c | 21 +
1
From: Davidlohr Bueso
Call __set_current_state() instead of assigning the new state directly.
These interfaces also aid CONFIG_DEBUG_ATOMIC_SLEEP environments, keeping
track of who changed the state.
Signed-off-by: Davidlohr Bueso
---
sound/oss/msnd_pinnacle.c | 4 ++--
sd_set_power_mode() in derived module drivers/mmc/host/rtsx_usb_sdmmc.c
acquires dev_mutex and then calls pm_runtime_get_sync() to make sure the
device is awake while initializing a newly inserted card. Once it is
called during suspending state and explicitly before rtsx_usb_suspend()
acquires the
(2015/01/12 21:51), Steve Capper wrote:
> On Sat, Jan 10, 2015 at 11:03:16PM -0500, David Long wrote:
>> From: "David A. Long"
>>
>> Add HAVE_REGS_AND_STACK_ACCESS_API feature for arm64.
>>
>> Signed-off-by: David A. Long
>> ---
>> arch/arm64/Kconfig | 1 +
>>
Hi all,
Changes since 20150114:
The renesas tree gained a conflict against the arm-soc tree.
The net-next tree gained a conflict against the net tree.
Non-merge commits (relative to Linus' tree): 2952
2909 files changed, 90289 insertions(+), 49341 deletions
Call __set_current_state() instead of assigning the new state directly.
These interfaces also aid CONFIG_DEBUG_ATOMIC_SLEEP environments, keeping
track of who changed the state.
Signed-off-by: Davidlohr Bueso
---
ipc/sem.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git
On 01/15/15 at 01:45pm, Li, ZhenHua wrote:
> Hi Baoquan,
> Thank you very much for your review. But according to the latest
> discussion, the page tables will not be copied from old kernel. We keep
> using the old page tables before driver is loaded. So there are many
> changes in next version;
A quick search shows that there are no users, drop the
macro for both jbd and jbd2.
Signed-off-by: Davidlohr Bueso
Cc: Jan Kara
---
My goal here was to just change how we set current state, however
I realized that the function is not used.
include/linux/jbd.h | 9 -
Call __set_current_state() instead of assigning the new state directly.
These interfaces also aid CONFIG_DEBUG_ATOMIC_SLEEP environments, keeping
track of who changed the state.
Signed-off-by: Davidlohr Bueso
Cc: Oleg Nesterov
---
kernel/signal.c | 4 ++--
1 file changed, 2 insertions(+), 2
On Thu, 2015-01-15 at 05:57 +, Nakashima Akihiro wrote:
> Dear David and networking developers:
>
> I got kernel panic on 3.4.105 kernel.
> Please see a report below.
Please try a recent kernel.
We are not going to debug such an old one, given there are chances we
already fixed the problem
Hi Linus,
Please pull some more powerpc fixes for 3.19:
The following changes since commit eaa27f34e91a14cdceed26ed6c6793ec1d186115:
linux 3.19-rc4 (2015-01-11 12:44:53 -0800)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/mpe/linux.git
The AUO b101ean01 panel is a 10.1" 1280x800 panel,
which can be supported by the simple panel driver.
Signed-off-by: huang lin
---
Changes in v2:
- changed panel timing
drivers/gpu/drm/panel/panel-simple.c | 26 ++
1 file changed, 26 insertions(+)
diff --git
Hi,
On Wed, Jan 14, 2015 at 11:04:27PM +, Paul Zimmerman wrote:
> > > > > > > > > > This is really, really odd. Register accesses are atomic,
> > > > > > > > > > so the lock
> > > > > > > > > > isn't really doing anything. Besides, you're calling
> > > > > > > > > >
At Wed, 14 Jan 2015 16:34:15 +,
Mark Brown wrote:
>
> On Wed, Jan 14, 2015 at 02:01:33PM +0100, Takashi Iwai wrote:
> > Mark Brown wrote:
>
> > > > Above all, disallowing the module unload while using is the common
> > > > behavior of any other drivers. Why do we have to be a rebel against
At Thu, 15 Jan 2015 13:40:49 +0900,
jiwang wrote:
>
> Hi
> On 01/14/2015 10:43 PM, Fabio Estevam wrote:
> > On Wed, Jan 14, 2015 at 10:57 AM, Lars-Peter Clausen
> > wrote:
> >
> >> My personal opinion on this is that disallowing module removal while a
> >> driver registered by the module when
From 2384c119d04b54e6e6c282a8693246c4e7d1347e Mon Sep 17 00:00:00 2001
From: "bk0121.shin"
Date: Wed, 14 Jan 2015 20:35:57 +0900
Subject: [PATCH] [media] dvb-core: Fix frontend thread serialization
dvb_frontend_thread's life cycle is controlled by dvb_frontend_start
and dvb_frontend_release.
On Wed, 2015-01-14 at 13:03 -0500, Steven Rostedt wrote:
> On Wed, 14 Jan 2015 09:35:17 +1100
> Michael Ellerman wrote:
>
> > In commit 5f893b2639b2 "tracing: Move enabling tracepoints to just after
> > rcu_init()", tracing was enabled earlier in boot.
> >
> > This broke tracing of the
Dear David and networking developers:
I got kernel panic on 3.4.105 kernel.
Please see a report below.
[1.] One line summary of the problem: [3.4] neigh_destroy() crashes on unplug
netdev.
[2.] Full description of the problem/report:
I got kernel panic: neigh_destroy() crashes on unplug my
On Wed, Jan 14, 2015 at 09:44:39PM -0800, Scott Branden wrote:
> On 15-01-14 05:02 PM, Dmitry Torokhov wrote:
> >Hi Jonathan,
> >
> >On Fri, Dec 19, 2014 at 02:17:49PM -0800, Jonathan Richardson wrote:
> >>+ if (of_property_read_u32(np, "scanning_period", ) >= 0) {
> >>+ if (val < 1 ||
From: Stephen Rothwell
Date: Thu, 15 Jan 2015 13:47:35 +1100
> Today's linux-next merge of the net-next tree got a conflict in
> drivers/net/xen-netfront.c between commit 900e183301b5 ("xen-netfront:
> use different locks for Rx and Tx stats") from the net tree and commit
> a55e8bb8fb89
When building perf for arm64 I hit a warning (and be treated as an
error) like below:
aarch64-oe-linux-gcc -o .../util/scripting-engines/trace-event-python.o -c
-Wbad-function-cast \
... util/scripting-engines/trace-event-python.c
In file included from
> -Original Message-
> From: Ferre, Nicolas
> Sent: Thursday, January 15, 2015 12:48 AM
> To: Peter Rosin; linux-arm-ker...@lists.infradead.org; Yang, Wenyou
> Cc: Peter Rosin; Andrew Victor; Jean-Christophe Plagniol-Villard; Russell
> King;
> linux-kernel@vger.kernel.org; Alexandre
Hi Baoquan,
Thank you very much for your review. But according to the latest
discussion, the page tables will not be copied from old kernel. We keep
using the old page tables before driver is loaded. So there are many
changes in next version;
See my comments.
On 01/15/2015 11:28 AM, Baoquan He
On 15-01-14 05:02 PM, Dmitry Torokhov wrote:
Hi Jonathan,
On Fri, Dec 19, 2014 at 02:17:49PM -0800, Jonathan Richardson wrote:
+ if (of_property_read_u32(np, "scanning_period", ) >= 0) {
+ if (val < 1 || val > 256) {
+ dev_err(dev, "scanning_period
This patch fixes the checkpatch.pl issue
Error: trailing statements should be on next line
Signed-off-by: Balavasu
---
drivers/staging/lustre/lnet/lnet/router.c | 9 ++---
1 file changed, 6 insertions(+), 3 deletions(-)
diff --git a/drivers/staging/lustre/lnet/lnet/router.c
No need to check set->nr_hw_queues twice in blk_mq_alloc_tag_set(),
remove the latter one.
Signed-off-by: hujianyang
---
block/blk-mq.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/block/blk-mq.c b/block/blk-mq.c
index a7d4a98..eddeccc 100644
--- a/block/blk-mq.c
On Wed, Jan 14, 2015 at 08:48:43PM -0800, Guenter Roeck wrote:
> On 01/13/2015 11:21 PM, Greg Kroah-Hartman wrote:
> >This is the start of the stable review cycle for the 3.18.3 release.
> >There are 150 patches in this series, all will be posted as a response
> >to this one. If anyone has any
On Friday 01/09 at 16:36 -0500, Paul Moore wrote:
> On Friday, January 09, 2015 01:24:51 PM Calvin Owens wrote:
> > On Friday 01/09 at 15:33 -0500, Paul Moore wrote:
> > > While I haven't had reason to test this code lately, last I knew it was
> > > working, what problems are you seeing Calvin?
On Thu, Jan 15, 2015 at 09:49:12AM +0530, Vineet Gupta wrote:
> Hi Greg,
>
> On Saturday 10 January 2015 04:56 PM, Vineet Gupta wrote:
> > 8250 earlycon is broken on multi-platform ARC because the UART clk
> > value (BASE_BAUD) is fixed at build time.
> >
> > Instead, determine the appropriate
On 01/13/2015 11:21 PM, Greg Kroah-Hartman wrote:
This is the start of the stable review cycle for the 3.18.3 release.
There are 150 patches in this series, all will be posted as a response
to this one. If anyone has any issues with these being applied, please
let me know.
Responses should be
On Wed, Jan 14, 2015 at 8:31 PM, Yinghai Lu wrote:
> Some bios put range that is not fully coverred by root bus resources.
> Try to clip them and update them in pci bridge bars.
>
> We'd like to fix other arches instead of just x86.
>
> Link: https://bugzilla.kernel.org/show_bug.cgi?id=85491
>
On 01/13/2015 11:22 PM, Greg Kroah-Hartman wrote:
This is the start of the stable review cycle for the 3.14.29 release.
There are 77 patches in this series, all will be posted as a response
to this one. If anyone has any issues with these being applied, please
let me know.
Responses should be
Hi
On 01/14/2015 10:43 PM, Fabio Estevam wrote:
On Wed, Jan 14, 2015 at 10:57 AM, Lars-Peter Clausen wrote:
My personal opinion on this is that disallowing module removal while a
driver registered by the module when is in use, while there is no technical
reason to do so, is a anti-feature.
Some bios put range that is not fully coverred by root bus resources.
Try to clip them and update them in pci bridge bars.
We'd like to fix other arches instead of just x86.
Link: https://bugzilla.kernel.org/show_bug.cgi?id=85491
Reported-by: Marek Kordik
Fixes: 5b28541552ef ("PCI: Restrict
Some bios put range that is not fully coverred by root bus resources.
Try to clip them and update them in pci bridge bars.
We'd like to fix other arches instead of just x86.
Link: https://bugzilla.kernel.org/show_bug.cgi?id=85491
Reported-by: Marek Kordik
Fixes: 5b28541552ef ("PCI: Restrict
Some bios put range that is not fully coverred by root bus resources.
Try to clip them and update them in pci bridge bars.
We'd like to fix other arches instead of just x86.
Link: https://bugzilla.kernel.org/show_bug.cgi?id=85491
Reported-by: Marek Kordik
Fixes: 5b28541552ef ("PCI: Restrict
Some bios put range that is not fully coverred by root bus resources.
Try to clip them and update them in pci bridge bars.
Link: https://bugzilla.kernel.org/show_bug.cgi?id=85491
Reported-by: Marek Kordik
Tested-by: Marek Kordik
Fixes: 5b28541552ef ("PCI: Restrict 64-bit prefetchable bridge
Some bios put range that is not fully coverred by root bus resources.
Try to clip them and update them in pci bridge bars.
We'd like to fix other arches instead of just x86.
Link: https://bugzilla.kernel.org/show_bug.cgi?id=85491
Reported-by: Marek Kordik
Fixes: 5b28541552ef ("PCI: Restrict
Some bios put range that is not fully coverred by root bus resources.
Try to clip them and update them in pci bridge bars.
We'd like to fix other arches instead of just x86.
Link: https://bugzilla.kernel.org/show_bug.cgi?id=85491
Reported-by: Marek Kordik
Fixes: 5b28541552ef ("PCI: Restrict
Some bios put range that is not fully coverred by root bus resources.
Try to clip them and update them in pci bridge bars.
We'd like to fix other arches instead of just x86.
Link: https://bugzilla.kernel.org/show_bug.cgi?id=85491
Reported-by: Marek Kordik
Fixes: 5b28541552ef ("PCI: Restrict
Some bios put range that is not fully coverred by root bus resources.
Try to clip them and update them in pci bridge bars.
We'd like to fix other arches instead of just x86.
Link: https://bugzilla.kernel.org/show_bug.cgi?id=85491
Reported-by: Marek Kordik
Fixes: 5b28541552ef ("PCI: Restrict
Some bios put range that is not fully coverred by root bus resources.
Try to clip them and update them in pci bridge bars.
We'd like to fix other arches instead of just x86.
Link: https://bugzilla.kernel.org/show_bug.cgi?id=85491
Reported-by: Marek Kordik
Fixes: 5b28541552ef ("PCI: Restrict
During the fix https://bugzilla.kernel.org/show_bug.cgi?id=85491,
Bjorn suggest that we should clip the resources instead of just
reject them.
We should only need first two for x86. others for related arches
to keep them consistent.
-v2: only handle bridge resource, and add
Some bios put range that is not fully coverred by root bus resources.
Try to clip them and update them in pci bridge bars.
This one is core part, arch changes will be in following patches.
-v2: add pci_claim_bridge_resource to core according to Bjorn.
Link:
On Mon, 2014-11-24 at 15:07 +0100, Laurent Dufour wrote:
> On pseries system (LPAR) xmon failed to enter when running in LE mode, system
> is hunging. Inititating xmon will lead to such an output on the console:
>
> SysRq : Entering xmon
> cpu 0x15: Vector: 0 at [c003f39ffb10]
> pc:
Hi Greg,
On Saturday 10 January 2015 04:56 PM, Vineet Gupta wrote:
> 8250 earlycon is broken on multi-platform ARC because the UART clk
> value (BASE_BAUD) is fixed at build time.
>
> Instead, determine the appropriate UART clk at runtime; parse the
> devicetree early for platforms requiring
From: "Steven Rostedt (Red Hat)"
Because jprobes replaces the stack frame to call the jprobe handler with
the function arguments, if kprobes/jprobes uses ftrace (fentry)
infrastructure for its implementation, it messes with the tracing of
the function graph tracer.
The jprobe gets set up from
This is built on top of the patches that disable function graph tracer
for jprobes:
https://lkml.org/lkml/2015/1/14/631
This is actually the first solution I had to deal with jprobes and
function graph tracing, but as I thought the problem only happened
when kprobes used the ftrace
From: "Steven Rostedt (Red Hat)"
Currently when a jprobe handler is called it disables function graph
tracing until the jprobe handler is complete. This means that jprobe
handlers can not be traced, nor can the functions they probe be traced
if fentry is used (the disabling happens around the
From: "Steven Rostedt (Red Hat)"
trace_init() calls init_ftrace_syscalls() and then calls trace_event_init()
which also calls init_ftrace_syscalls(). It makes more sense to only
call it from trace_event_init().
Calling it twice wastes memory, as it allocates the syscall events twice,
and loses
Some bugs have been reported and this fixes them. I'll be testing them
a bit more before pushing them to Linus.
Steven Rostedt (Red Hat) (2):
tracing: Remove extra call to init_ftrace_syscalls()
tracing: Fix enabling of syscall events on the command line
kernel/trace/trace.c
From: "Steven Rostedt (Red Hat)"
Commit 5f893b2639b2 "tracing: Move enabling tracepoints to just after
rcu_init()" broke the enabling of system call events from the command
line. The reason was that the enabling of command line trace events
was moved before PID 1 started, and the syscall
The descriptor member `bNumEndpoints' is plural.
Signed-off-by: Chris Rorvick
---
include/linux/usb.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/include/linux/usb.h b/include/linux/usb.h
index f89c24a..4add566 100644
--- a/include/linux/usb.h
+++ b/include/linux/usb.h
(2015/01/14 17:47), Jiri Kosina wrote:
> Using IPMODIFY needs to be allowed only with compilers which are
> guaranteed to generate function prologues compatible with function
> redirection through changing instruction pointer in saved regs.
>
> For example changing regs->ip on x86_64 in cases
On 01/12/15 at 03:06pm, Li, Zhen-Hua wrote:
> +/*
> + * Interface to the "copy translation tables" set of functions
> + * from mainline code.
> + */
> +static int intel_iommu_load_translation_tables(struct dmar_drhd_unit *drhd,
> + int g_num_of_iommus)
The argument g_num_of_iommus is
Hi, Rickard
I've done some corrections in the following commit for this report:
https://github.com/zetalog/acpica/commit/f86ad0858eacfe890cbeae43846da2638c389c1c
All other utilities related corrections are done in:
https://github.com/zetalog/acpica/commit/06fb69ea0e4c47edc91544a90a69b983fd161963
Hi Brian,
For Altera EPCQ flashes, almost operations are performed underline hardware.
Software only able to perform the following through registers:
- read status register
- read id
- write status registers bit SR_BP0,SR_BP1, SR_BP2,SR_BP3, SR_TB
(2015/01/14 17:48), Jiri Kosina wrote:
> If ftrace doesn't claim to support IPMODIFY support, there is no need to
> compile IPMODIFY support in kprobes either.
>
This looks good to me :)
Acked-by: Masami Hiramatsu
Thanks!
> Signed-off-by: Jiri Kosina
> ---
> kernel/kprobes.c | 8
On 14 January 2015 at 16:03, Russell King - ARM Linux
wrote:
> On Wed, Jan 14, 2015 at 10:38:38AM -0800, Victor Kamensky wrote:
>> >From fed6caab410ddcaf487ff23a3908eca129e50b89 Mon Sep 17 00:00:00 2001
>> From: Victor Kamensky
>> Date: Wed, 14 Jan 2015 07:42:41 -0800
>> Subject: [PATCH 3/3]
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 01/14/2015 01:36 PM, Oleg Nesterov wrote:
> On 01/11, r...@redhat.com wrote:
>>
>> If the next task still has its FPU state present in the FPU
>> registers, there is no need to restore it from memory.
>
> Another patch I can't understand...
>
>>
Hi all,
Today's linux-next merge of the net-next tree got a conflict in
drivers/net/xen-netfront.c between commit 900e183301b5 ("xen-netfront:
use different locks for Rx and Tx stats") from the net tree and commit
a55e8bb8fb89 ("xen-netfront: refactor making Tx requests") from the
net-next tree.
>From 47bd18e210fecf701d493c27884e13c69bc449ea Mon Sep 17 00:00:00 2001
From: Paul Zimmerman
Date: Wed, 14 Jan 2015 18:15:58 -0800
Subject: [PATCH] usb: phy: make GPIOs optional for the generic phy
The use of GPIOs should be optional for the generic phy, otherwise
the Altera SOCFPGA platform at
On Wed, 14 Jan 2015 18:44:41 -0500
Sasha Levin wrote:
> On 01/14/2015 09:27 AM, Jeff Layton wrote:
> > On Tue, 13 Jan 2015 17:50:45 -0500
> > Sasha Levin wrote:
> >
> >> On 01/13/2015 04:44 PM, Jeff Layton wrote:
> >>> On Tue, 13 Jan 2015 00:11:37 -0500
> >>> Sasha Levin wrote:
> >>>
>
On Fri, Dec 26, 2014 at 3:58 PM, Jesse Gross wrote:
> On Fri, Dec 5, 2014 at 2:12 PM, Jeff Kirsher
> wrote:
>> On Fri, 2014-12-05 at 10:41 -0800, Joe Stringer wrote:
>>> ndo_gso_check() was recently introduced to allow NICs to report the
>>> offloading support that they have on a per-skb basis.
Hi Joe,
Thanks for reviewing.
On 14 January 2015 at 15:43, Yingjoe Chen wrote:
>
> Hi,
>
> On Fri, 2015-01-09 at 17:54 +0800, pi-cheng.chen wrote:
>> When doing DVFS on MT8173 SoC, 2 rules should be followed to make sure the
>> SoC works properly:
>> 1. When doing frequency scaling of CPUs, the
enable_irq_wakeup returns 0 in case it correctly enabled the IRQ to
generate the wakeup event (and thus resume should call disable_irq_wake).
Currently gpio-charger driver has this logic inverted. Correct that thus
correcting enable/disable_irq_wake() calls balance.
Cc: sta...@vger.kernel.org
Hi,
> From: Rickard Strandqvist [mailto:rickard_strandqv...@spectrumdigital.se]
> Sent: Thursday, January 15, 2015 6:50 AM
>
> 2015-01-14 9:55 GMT+01:00 Zheng, Lv :
> > Hi, Rickard
> >
> > The functions below seem already marked by "ACPI_ASL_COMPILER ||
> > ACPI_HELP_APP".
> > How did you
Teach collie_battery driver to communicate to the kernel that it can
generate wakeup events. Handle enabling/disabling wakeup on battery full
event in suspend/resume callbacks.
Signed-off-by: Dmitry Eremin-Solenikov
---
drivers/power/collie_battery.c | 24
1 file
/kernel/git/luto/linux.git
tags/pr-20150114-x86-entry
for you to fetch changes up to f6f64681d9d87ded48a90b644b2991c6ee05da2d:
x86: entry_64.S: fold SAVE_ARGS_IRQ macro into its sole user
(2015-01-13 14:18:08 -0800)
This is my
On Thu, Jan 15, 2015 at 5:51 AM, Kees Cook wrote:
> On Tue, Jan 13, 2015 at 12:35 AM, Roman Peniaev wrote:
>> On Tue, Jan 13, 2015 at 3:39 AM, Will Deacon wrote:
>>> On Sun, Jan 11, 2015 at 02:32:30PM +, Roman Pen wrote:
thread_info->syscall is used only for ptrace, but syscall number
Fix the following warning:
WARNING: drivers/clocksource/built-in.o(.text.unlikely+0x70): Section mismatch
in reference from the function pxa_timer_common_init() to the function
.init.text:clocksource_mmio_init()
The function pxa_timer_common_init() references
the function __init
This patch adds the memory bus node for Exynos4x12 SoC. Exynos4x12 SoC has
two memory bus to translate data between DRAM and eMMC/sub-IPs.
Following list specifies the detailed relation between memory bus clock and DMC
IP in MIF (Memory Interface) block:
- DMC/ACP clock : DMC (Dynamic Memory
This patch adds the divider clock id for Exynos4 memory bus frequency.
The clock id is used fo DVFS (Dynamic Voltage/Frequency Scaling)
feature of exynos memory bus frequency.
Cc: Sylwester Nawrocki
Cc: Tomasz Figa
Signed-off-by: Chanwoo Choi
---
drivers/clk/samsung/clk-exynos4.c | 10
This patch adds the generic exynos bus frequency driver for memory bus
with DEVFREQ framework. The Samsung Exynos SoCs have the common architecture
for memory bus between DRAM memory and MMC/sub IP in SoC. This driver can
support the memory bus frequency driver for Exynos SoCs.
Each memory bus
This patch-set adds the generic exynos bus frequency driver for memory bus
with DEVFREQ framework. The Samsung Exynos SoCs have the common architecture
for memory bus between DRAM memory and MMC/sub IP in SoC. This driver can
support the memory bus frequency driver for Exynos SoCs.
Each memory
On 14/01/15 16:13, Brian Norris wrote:
> Since I found this in my inbox during garbage collection...
>
> On Tue, Nov 4, 2014 at 3:23 PM, Florian Fainelli wrote:
>> On 11/04/2014 02:56 PM, Grant Likely wrote:
>>> On Tue, Nov 4, 2014 at 10:48 PM, Florian Fainelli
>>> wrote:
On 11/04/2014
This patch adds the memory bus node for Exynos4210 SoC. Exynos4210 SoC has
one memory bus to translate data between DRAM and eMMC/sub-IPs because
Exynos4210 must need only one regulator for memory bus.
Following list specifies the detailed relation between memory bus clock and
sub-IPs:
- DMC/ACP
This patch adds the memory bus node for Exynos3250 SoC. Exynos3250 has
following memory buses to translate data between DRAM and eMMC/sub-IPs.
Following list specifies the detailed relation between memory bus clock and DMC
IP in MIF (Memory Interface) block:
- DMC clock : DMC (Dynamic Memory
This patch adds the Exynos3250 memory-bus node which includes the regulator
and devfreq-event phandle. The devfreq-event phandle is used for the
governor of devfreq device and provide the current usage state of
MIF (Memory Interface) / INT (Internal) memory bus group.
Cc: Kukjin Kim
Cc: Myungjoo
This patch removes the unused exynos4 memory busfreq driver by adding generic
exynos memory bus frequency driver.
Cc: Myungjoo Ham
Cc: Kyungmin Park
Signed-off-by: Chanwoo Choi
---
drivers/devfreq/Kconfig | 12 -
drivers/devfreq/exynos/Makefile |1 -
This patch adds the documentation for generic exynos memory bus frequency
driver.
Cc: MyungJoo Ham
Cc: Kyungmin Park
Cc: Kukjin Kim
Signed-off-by: Chanwoo Choi
Acked-by: MyungJoo Ham
---
.../devicetree/bindings/devfreq/exynos-bus.txt | 188 +
1 file changed, 188
This patch adds the Exynos4412 memory-bus node which includes the regulator
and devfreq-event phandle. The devfreq-event phandle is used for the
governor of devfreq device and provide the current usage state of
MIF (Memory Interface) / INT (Internal) memory bus group.
Cc: Kukjin Kim
Cc: Myungjoo
1 - 100 of 1822 matches
Mail list logo
