Hello,
On Wed, Sep 25, 2013 at 02:27:48AM +0800, Zhang Yanfei wrote:
> +#ifdef CONFIG_MOVABLE_NODE
> +static inline void memblock_set_bottom_up(bool enable)
> +{
> + memblock.bottom_up = enable;
> +}
> +
> +static inline bool memblock_bottom_up(void)
> +{
> + return memblock.bottom_up;
> +
Kill RPC_IFDEBUG() and NFS_IFDEBUG() as they're no longer used.
Signed-off-by: David Howells
---
include/linux/nfs_fs.h |2 --
include/linux/sunrpc/debug.h |2 --
2 files changed, 4 deletions(-)
diff --git a/include/linux/nfs_fs.h b/include/linux/nfs_fs.h
index 3ea4cde..e0e95e2 1
Declare and use rpc_task_pid() to wrap task->tk_pid (when it exists) and to
return 0 when it doesn't. This allows us to move towards using no_printk().
This was mostly achieved with:
perl -p -i -e 's/task->tk_pid/rpc_task_pid(task)/g' `git grep -l
'task->tk_pid'`
perl -p -i -e 's/data->ta
On Wed, Sep 25, 2013 at 02:29:06AM +0800, Zhang Yanfei wrote:
> +/**
> + * memory_map_top_down - Map [map_start, map_end) top down
> + * @map_start: start address of the target memory range
> + * @map_end: end address of the target memory range
> + *
> + * This function will setup direct mapping fo
David Howells wrote:
> Declare and use rpc_task_pid() to wrap task->tk_pid (when it exists) and to
> return 0 when it doesn't. This allows us to move towards using no_printk().
>
> This was mostly achieved with:
>
>perl -p -i -e 's/task->tk_pid/rpc_task_pid(task)/g' `git grep -l
> 'task->
On Thu, 26 Sep 2013, James Bottomley wrote:
> > could you please describe the exact scenario you think that the symmetric
> > keys aproach doesn't protect against, while the assymetric key aproach
> > does?
> >
> > The crucial points, which I believe make the symmetric key aproach work
> > (an
On Thu, Sep 26, 2013 at 07:18:15PM +0530, Laxman Dewangan wrote:
> The remove function implemented for platform driver's remove callback
> just return 0 as part of its implementation.
>
> Remove this APIs and do not pass the valid .remove for platform driver.
Yes, this should have been done when
Hello,
On Wed, Sep 25, 2013 at 02:30:51AM +0800, Zhang Yanfei wrote:
> +/**
> + * memory_map_bottom_up - Map [map_start, map_end) bottom up
> + * @map_start: start address of the target memory range
> + * @map_end: end address of the target memory range
> + *
> + * This function will setup direct
On Wed, Sep 25, 2013 at 02:34:34AM +0800, Zhang Yanfei wrote:
> From: Tang Chen
>
> Memory reserved for crashkernel could be large. So we should not allocate
> this memory bottom up from the end of kernel image.
>
> When SRAT is parsed, we will be able to know whihc memory is hotpluggable,
> and
Signed-off-by: LABBE Corentin
---
drivers/cpufreq/exynos-cpufreq.c | 2 +-
include/linux/devfreq.h | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/cpufreq/exynos-cpufreq.c b/drivers/cpufreq/exynos-cpufreq.c
index 0fac344..b4afd07 100644
--- a/drivers/cpufr
The (inner) MTU of a ipip6 (IPv4-in-IPv6) tunnel cannot be set below 1280,
which is the minimum MTU in IPv6.
However, there should be no IPv6 on the tunnel interface at all, so the IPv6
rules should not apply.
More info at https://bugzilla.kernel.org/show_bug.cgi?id=15530
This patch allows to ch
On Wed, Sep 25, 2013 at 02:35:14AM +0800, Zhang Yanfei wrote:
> From: Tang Chen
>
> The hot-Pluggable field in SRAT specifies which memory is hotpluggable.
> As we mentioned before, if hotpluggable memory is used by the kernel,
> it cannot be hot-removed. So memory hotplug users may want to set a
Use no_printk() for the null dprintk() and dfprintk() so that the compiler
doesn't complain about unused variables for stuff that's just printed.
Signed-off-by: David Howells
---
fs/lockd/svc.c |6 --
fs/lockd/svclock.c |6 --
fs/nfs/fscache.c
Suspend and resume of cards are handled by the protocol layer and
consequently the mmc_suspend|resume_host APIs are marked as deprecated.
While moving away from using the deprecated APIs, there are nothing
left to be done for the suspend and resume callbacks, so remove them.
Cc: Ludovic Desroches
This patchset is removing the use of the deprecated APIs from each and every
host driver. The final patch then removes the acutal APIs from mmc core.
I hope to collect acks from each maintainer and then try to merge this through
Chris tree, unless anybody has a better suggestion for the way forwar
Suspend and resume of cards are being handled from the protocol layer
and consequently the mmc_suspend|resume_host APIs are deprecated.
This means we can simplify the suspend|resume callbacks by removing the
use of the deprecated APIs.
Cc: Michał Mirosław
Signed-off-by: Ulf Hansson
---
drivers
Suspend and resume of cards are being handled from the protocol layer
and consequently the mmc_suspend|resume_host APIs are deprecated.
This means we can simplify the suspend|resume callbacks by removing the
use of the deprecated APIs.
Cc: Lars-Peter Clausen
Signed-off-by: Ulf Hansson
---
driv
Suspend and resume of cards are being handled from the protocol layer
and consequently the mmc_suspend|resume_host APIs are deprecated.
This means we can simplify the suspend|resume callbacks by removing the
use of the deprecated APIs.
Cc: Tony Prisk
Cc: linux-arm-ker...@lists.infradead.org
Sign
Suspend and resume of cards are being handled from the protocol layer
and consequently the mmc_suspend|resume_host APIs are deprecated.
This means we can simplify the suspend|resume callbacks by removing the
use of the deprecated APIs.
Signed-off-by: Ulf Hansson
---
drivers/mmc/host/sdhci.c |
Suspend and resume of cards are handled by the protocol layer and
consequently the mmc_suspend|resume_host APIs are marked as deprecated.
While moving away from using the deprecated APIs, there are nothing
left to be done for the suspend and resume callbacks, so remove them.
Cc: Wei WANG
Cc: Sam
The are no more users of the deprecated mmc_suspend|resume_host API,
so let's remove it.
Signed-off-by: Ulf Hansson
---
drivers/mmc/core/core.c | 22 --
include/linux/mmc/host.h |3 ---
2 files changed, 25 deletions(-)
diff --git a/drivers/mmc/core/core.c b/drivers/mm
Suspend and resume of cards are being handled from the protocol layer
and consequently the mmc_suspend|resume_host APIs are deprecated.
This means we can simplify the suspend|resume callbacks by removing the
use of the deprecated APIs.
Cc: Sascha Sommer
Signed-off-by: Ulf Hansson
---
drivers/m
Suspend and resume of cards are being handled from the protocol layer
and consequently the mmc_suspend|resume_host APIs are deprecated.
This means we can simplify the suspend|resume callbacks by removing the
use of the deprecated APIs.
Cc: Bruce Chang
Cc: Harald Welte
Signed-off-by: Ulf Hansson
On Thu, Sep 26, 2013 at 04:48:00PM +0200, Jiri Kosina wrote:
> > The only two problems I see are
> >
> > 1. The key isn't generational (any compromise obtains it). This
> > can be fixed by using a set of keys generated on each boot and
> > passing in both K_{N-1} and K_N
>
In support to what was said by Vlad:
To work with persistent memory as efficiently as we can work with RAM we need a
bit more than "commit". It's reasonable to expect that we get some additional
support from CPUs that goes beyond mfence and mflush. That may include
discovery, transactional supp
Suspend and resume of cards are being handled from the protocol layer
and consequently the mmc_suspend|resume_host APIs are deprecated.
This means we can simplify the suspend|resume callbacks by removing the
use of the deprecated APIs. Additional cleanup done for keeping track
suspended state.
Cc
Suspend and resume of cards are being handled from the protocol layer
and consequently the mmc_suspend|resume_host APIs are deprecated.
This means we can simplify the suspend|resume callbacks by removing the
use of the deprecated APIs.
Cc: Guennadi Liakhovetski
Cc: Ian Molton
Signed-off-by: Ulf
Suspend and resume of cards are being handled from the protocol layer
and consequently the mmc_suspend|resume_host APIs are deprecated.
This means we can simplify the suspend|resume callbacks by removing the
use of the deprecated APIs.
Cc: Russell King
Signed-off-by: Ulf Hansson
---
drivers/mm
Suspend and resume of cards are handled by the protocol layer and
consequently the mmc_suspend|resume_host APIs are marked as deprecated.
While moving away from using the deprecated APIs, there are nothing
left to be done for the suspend and resume callbacks, so remove them.
Cc: Tony Olech
Cc: l
Suspend and resume of cards are being handled from the protocol layer
and consequently the mmc_suspend|resume_host APIs are deprecated.
This means we can simplify the suspend|resume callbacks by removing the
use of the deprecated APIs.
Cc: Guennadi Liakhovetski
Signed-off-by: Ulf Hansson
---
d
Suspend and resume of cards are handled by the protocol layer and
consequently the mmc_suspend|resume_host APIs are marked as deprecated.
While moving away from using the deprecated APIs, there are nothing
left to be done for the suspend and resume callbacks, so remove them.
Cc: Ben Dooks
Cc: li
Suspend and resume of cards are handled by the protocol layer and
consequently the mmc_suspend|resume_host APIs are marked as deprecated.
While moving away from using the deprecated APIs, there are nothing
left to be done for the suspend and resume callbacks, so remove them.
Signed-off-by: Ulf Ha
Suspend and resume of cards are being handled from the protocol layer
and consequently the mmc_suspend|resume_host APIs are deprecated.
This means we can simplify the suspend|resume callbacks by removing the
use of the deprecated APIs.
Cc: Pierre Ossman
Signed-off-by: Ulf Hansson
---
drivers/m
The comment suggests that intention was to limit 16M cards to save memory while
code did something a bit different.
32bpp is a lot more useful with today's apps, such as Weston's fbdev backend
and 32M cards are probably hardly used in apps where dedicating a bit more to
pinned console would matter
Suspend and resume of cards are handled by the protocol layer and
consequently the mmc_suspend|resume_host APIs are marked as deprecated.
While moving away from using the deprecated APIs, there are nothing
left to be done for the suspend and resume callbacks, so remove them.
Cc: Jarkko Lavinen
C
On Wed, Sep 25, 2013 at 05:28:28PM -0600, Bjorn Helgaas wrote:
> There are patches for exynos, imx6, mvebu, and tegra on the PCI list,
> and I want to sort out how people expect them to be merged.
>
> My current assumption is the following:
...
> drivers/pci/host/pci-mvebu.c ?? unclear; Jason C
Suspend and resume of cards are being handled from the protocol layer
and consequently the mmc_suspend|resume_host APIs are deprecated.
This means we can simplify the suspend|resume callbacks by removing the
use of the deprecated APIs.
Cc: Shawn Guo
Cc: Fabio Estevam
Signed-off-by: Ulf Hansson
Suspend and resume of cards are being handled from the protocol layer
and consequently the mmc_suspend|resume_host APIs are deprecated.
This means we can simplify the suspend|resume callbacks by removing the
use of the deprecated APIs.
Cc: Seungwon Jeon
Cc: Jaehoon Chung
Signed-off-by: Ulf Hans
Suspend and resume of cards are handled by the protocol layer and
consequently the mmc_suspend|resume_host APIs are marked as deprecated.
While moving away from using the deprecated APIs, there are nothing
left to be done for the suspend and resume callbacks, so remove them.
Cc: Nicolas Pitre
Cc
Suspend and resume of cards are being handled from the protocol layer
and consequently the mmc_suspend|resume_host APIs are deprecated.
This means we can simplify the suspend|resume callbacks by removing the
use of the deprecated APIs.
Additionally, remove dead code which also used the deprecated
Suspend and resume of cards are being handled from the protocol layer
and consequently the mmc_suspend|resume_host APIs are deprecated.
This means we can simplify the suspend|resume callbacks by removing the
use of the deprecated APIs.
Cc: Sascha Hauer
Cc: Anatolij Gustschin
Signed-off-by: Ulf
Suspend and resume of cards are being handled from the protocol layer
and consequently the mmc_suspend|resume_host APIs are deprecated.
This means we can simplify the suspend|resume callbacks by removing the
use of the deprecated APIs.
Cc: Sekhar Nori
Cc: Manjunathappa, Prakash
Cc: davinci-linu
Suspend and resume of cards are being handled from the protocol layer
and consequently the mmc_suspend|resume_host APIs are deprecated.
This means we can simplify the suspend|resume callbacks by removing the
use of the deprecated APIs.
Cc: Manuel Lauss
Signed-off-by: Ulf Hansson
---
drivers/mm
Suspend and resume of cards are being handled from the protocol layer
and consequently the mmc_suspend|resume_host APIs are deprecated.
This means we can simplify the suspend|resume callbacks by removing the
use of the deprecated APIs.
Cc: Sonic Zhang
Cc: uclinux-dist-de...@blackfin.uclinux.org
Suspend and resume of cards are being handled from the protocol layer
and consequently the mmc_suspend|resume_host APIs are deprecated.
This means we can simplify the suspend|resume callbacks by removing the
use of the deprecated APIs.
Cc: Alex Dubov
Signed-off-by: Ulf Hansson
---
drivers/mmc/
Hi, Peter
On 09/26/2013 05:58 PM, Peter Zijlstra wrote:
[snip]
> diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c
> index 2b89cd2..47b0d0f 100644
> --- a/kernel/sched/fair.c
> +++ b/kernel/sched/fair.c
> @@ -2913,6 +2913,17 @@ static void dequeue_task_fair(struct rq *rq, struct
> task_struc
The 64-bit cmpxchg operation on the lockref is ordered by virtue of
hazarding between the cmpxchg operation and the reference count
manipulation. On weakly ordered memory architectures (such as ARM), it
can be of great benefit to omit the barrier instructions where they are
not needed.
This patch
cmpxchg64_relaxed can be used to provide barrier-less semantics for a
64-bit cmpxchg operation in cases where the strong memory ordering is
not required. A useful use-case for this is in the recently merged
lockless lockref code.
This patch implements a dummy implementation for ia64, which could
p
cmpxchg64_relaxed can be used to provide barrier-less semantics for a
64-bit cmpxchg operation in cases where the strong memory ordering is
not required. A useful use-case for this is in the recently merged
lockless lockref code.
This patch implements a dummy implementation for x86, since the memo
On 9/26/13 8:21 AM, Ramkumar Ramachandra wrote:
The MANIFEST file is used in the following Makefile targets:
$ make tar{,gz,bz2,xz}-src-pkg
to generate an archive that can be used outside the kernel tree. It
contains entries that are used for pathspec filtering 'git archive',
which ultimatel
On Thu, Sep 26, 2013 at 04:11:13PM +0200, Veaceslav Falico wrote:
> Currently we're pci_dev_get/put()-ing pci device on every kobject
> creation/removal. It's useless per se - the kobject is part of the device
> itself, so it should be removed when there are no users of the pdev, and is
> not a use
On Thu, Sep 26, 2013 at 04:11:14PM +0200, Veaceslav Falico wrote:
> Currently we create and populate ->msi_kset while allocating irqs in
> populate_msi_sysfs(), however if it fails and/or we want to free the
> entries - we don't always remove it, and we might have problems if we've
> failed to allo
On Thu, Sep 26, 2013 at 03:45:02PM +0100, David Howells wrote:
>
>
> Here's a series of patches to make SunRPC/NFS use no_printk() to implement its
> null dfprintk() macro (ie. when RPC_DEBUG is disabled). This prevents 'unused
> variable' errors from occurring when a variable is set only for us
On Mon, Sep 02, 2013 at 03:11:04AM +0300, Tomas Winkler wrote:
> 1. Return zero on zero length read and writes
> 2. For a too large write return -EFBIG as defined in man write(2)
> EFBIG An attempt was made to write a file that
> exceeds the implementation-defined maximum
> file si
On 9/25/2013 6:21 PM, Andrew Morton wrote:
On Wed, 25 Sep 2013 18:15:21 -0700 Arjan van de Ven
wrote:
On 9/25/2013 4:47 PM, Andi Kleen wrote:
Also, the changelogs don't appear to discuss one obvious downside: the
latency incurred in bringing a bank out of one of the low-power states
and back
> -Original Message-
> From: J. Bruce Fields [mailto:bfie...@fieldses.org]
> Sent: Thursday, September 26, 2013 10:21 AM
> To: David Howells
> Cc: Myklebust, Trond; o...@lixom.net; linux-...@vger.kernel.org; linux-
> ker...@vger.kernel.org
> Subject: Re: [RFC][PATCH 0/4] SunRPC/NFS: Use no_
J. Bruce Fields wrote:
> > Here's a series of patches to make SunRPC/NFS use no_printk() to implement
> > its null dfprintk() macro (ie. when RPC_DEBUG is disabled). This prevents
> > 'unused variable' errors from occurring when a variable is set only for
> > use in debugging statements and rend
On 9/26/2013 5:58 AM, Srivatsa S. Bhat wrote:
Let me explain the challenge I am facing. A prototype powerpc platform that
I work with has the capability to transition memory banks to content-preserving
low-power states at a per-socket granularity. What that means is that we can
get memory power s
Mark,
What are your thoughts on this approach? I basically add a way to
specify in the DAPM regulator supply widget that the supply lives
on the parent rather than the current device. If you like it I
will send it in as a proper patch.
I had considered adding something like a recursive regulator
On Thu, 2013-09-26 at 15:45 +0100, David Howells wrote:
> Use no_printk() for the null dprintk() and dfprintk() so that the compiler
> doesn't complain about unused variables for stuff that's just printed.
no_printk doesn't prevent any argument side-effects
from being optimized away by the compile
On Thu, Sep 26, 2013 at 07:52:23AM -0400, Peter Hurley wrote:
> On 09/25/2013 11:20 PM, Andi Kleen wrote:
> >Lin Ming writes:
> >>
> >>Would you like below patch?
> >
> >The loop body keeps rather complex state. It could easily
> >get confused by parallel RCU changes.
> >
> >So if the list changes
On Thu, Sep 26, 2013 at 8:13 AM, Will Deacon wrote:
>
> This patch implements a dummy implementation for asm-generic, falling
> back to the usual cmpxchg64 code.
I don't like the "let's add dummy operations for everybody who doesn't
care" when it is this specialized.
I'd much rather just add a s
On Thu, Sep 26, 2013 at 10:58:05AM +0200, Miklos Szeredi wrote:
> On Wed, Sep 25, 2013 at 11:07 PM, Zach Brown wrote:
> >> A client-side copy will be slower, but I guess it does have the
> >> advantage that the application can track progress to some degree, and
> >> abort it fairly quickly without
Add spread spectrum control for PLLE in Tegra114.
Signed-off-by: Peter De Schrijver
---
drivers/clk/tegra/clk-pll.c | 30 +-
1 files changed, 29 insertions(+), 1 deletions(-)
diff --git a/drivers/clk/tegra/clk-pll.c b/drivers/clk/tegra/clk-pll.c
index 87f0533..f057
Joe Perches wrote:
> no_printk doesn't prevent any argument side-effects
> from being optimized away by the compiler.
>
> ie:
> dprintk("%d", func())
> func is now always called when before it wasn't.
Yes, I know. There are half a dozen places where this is the case. Those
I've wrapped
On 09/26/2013 06:48 AM, Laxman Dewangan wrote:
> Recent movement of all configurations of pin in the single call of
> pin_config_set(), it is aborting configuration if BIAS_PULL_PIN_DEFAULT
> is selected as return of configuration.
>
> The original idea was to just avoid any update on register for
On Thu, 2013-09-26 at 16:35 +0100, David Howells wrote:
> Joe Perches wrote:
>
> > no_printk doesn't prevent any argument side-effects
> > from being optimized away by the compiler.
> >
> > ie:
> > dprintk("%d", func())
> > func is now always called when before it wasn't.
>
> Yes, I know.
Hello tejun,
Thanks for your quick comments first:)
On 09/26/2013 10:45 PM, Tejun Heo wrote:
> Hello,
>
> On Wed, Sep 25, 2013 at 02:27:48AM +0800, Zhang Yanfei wrote:
>> +#ifdef CONFIG_MOVABLE_NODE
>> +static inline void memblock_set_bottom_up(bool enable)
>> +{
>> +memblock.bottom_up = ena
Am 26.09.2013 16:36, schrieb Ramkumar Ramachandra:
> Richard Weinberger wrote:
>>> Sorry for chiming in, but... what about cross compiling?
>>> SUBARCH=x86 should give you a 32-bit ia32 kernel, right?
>>
>> Correct.
>> Users expect from SUBARCH=x86 a i386 32bit UML kernel.
>
> This is an insane ex
On Thu, Sep 26, 2013 at 07:31:47AM -0400, Peter Hurley wrote:
> On 09/26/2013 03:33 AM, Andrew Morton wrote:
> >On Tue, 17 Sep 2013 20:22:42 -0400 Peter Hurley
> >wrote:
> >
> >>Looking over vmalloc.c, the critical section footprint of the vmap_area_lock
> >>could definitely be reduced (even near
cmpxchg64_relaxed can be used to provide barrier-less semantics for a
64-bit cmpxchg operation in cases where the strong memory ordering is
not required.
This patch implements a dummy implementation for asm-generic, falling
back to the usual cmpxchg64 code.
Cc: Arnd Bergmann
Signed-off-by: Will
On Mon, Sep 02, 2013 at 01:29:44PM +0300, Tomas Winkler wrote:
> *** BLURB HERE ***
I think you need to read your emails a bit better :)
> Alexander Usyskin (1):
> mei: cancel stall timers in mei_reset
>
> Tomas Winkler (2):
> mei: make me client counters less error prone
> mei: bus: stop
On 09/26/2013 10:46 PM, Tejun Heo wrote:
> On Wed, Sep 25, 2013 at 02:29:06AM +0800, Zhang Yanfei wrote:
>> +/**
>> + * memory_map_top_down - Map [map_start, map_end) top down
>> + * @map_start: start address of the target memory range
>> + * @map_end: end address of the target memory range
>> + *
Hello friend, I am glad to inform you that i need your help for
transfer of fund.
--
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
Please read the FAQ
On Thu, 26 Sep 2013, Ulf Hansson wrote:
> Suspend and resume of cards are handled by the protocol layer and
> consequently the mmc_suspend|resume_host APIs are marked as deprecated.
Having the protocol layer take care of card suspend is perfectly sound.
However, what about host controllers? Sho
On Wed, Sep 25, 2013 at 10:40 PM, Viresh Kumar wrote:
> On 26 September 2013 10:47, Yinghai Lu wrote:
>> can you put this one in acpi tree?
>
> Its already applied in Rafael's linux-next branch.. Do you want something
> else?
sorry, I missed that.
I still had that in local patches directory, bu
On Mon, Sep 16, 2013 at 11:44:42PM +0300, Tomas Winkler wrote:
> From: Alexander Usyskin
>
> Fix calling function names in debug prints.
>
> Signed-off-by: Alexander Usyskin
> Signed-off-by: Tomas Winkler
> ---
> drivers/misc/mei/interrupt.c | 6 +++---
> 1 file changed, 3 insertions(+), 3 de
> -Original Message-
> From: David Howells [mailto:dhowe...@redhat.com]
> Sent: Thursday, September 26, 2013 10:36 AM
> To: Joe Perches
> Cc: dhowe...@redhat.com; bfie...@fieldses.org; Myklebust, Trond;
> o...@lixom.net; linux-...@vger.kernel.org; linux-kernel@vger.kernel.org
> Subject: Re:
Kirill A. Shutemov wrote:
> Alex Thorlton wrote:
> > > THP off:
> > >
> ...
> > > 36.540185552 seconds time elapsed
> > >( +- 18.36% )
> >
> > I'm assuming this was THP off, no patchset, correct?
>
> Yes. But THP off patched is *very* clos
On Thu, Sep 26, 2013 at 04:35:33PM +0200, Peter Zijlstra wrote:
> On Thu, Sep 26, 2013 at 04:39:30AM -0700, Paul Turner wrote:
> > It is my intuition that there are a few common objects with fairly
> > polarized behavior: I.e. For condition variables and producer
> > consumer queues, a wakeup stro
Joe Perches wrote:
> No code is eliminated by the preprocessor
> with the #define I suggest.
Sorry, I misunderstood. I assumed you meant comparing to:
#ifdef RPC_DEBUG
#define dfprintk(...) ...
#else
#define dfprintk(...) do {} while(0)
#endif
sort of t
Hello tejun,
On 09/26/2013 10:48 PM, Tejun Heo wrote:
> Hello,
>
> On Wed, Sep 25, 2013 at 02:30:51AM +0800, Zhang Yanfei wrote:
>> +/**
>> + * memory_map_bottom_up - Map [map_start, map_end) bottom up
>> + * @map_start: start address of the target memory range
>> + * @map_end: end address of the
On Thu, Sep 26, 2013 at 11:09:46PM +0800, Michael wang wrote:
> > + if (sync)
> > + p->se.last_sync_wakeup = sched_clock_cpu(cpu);
>
> Forgive me but I'm trying to understand it... why not 'current' but 'p'
> here? we want the get off speed of waker or the working time of wakee?
Becau
> > It would be better to keep counting and just do RDPMC on the switch
> > points, and then subtract for counting. For sampling could need a MSR
> > write to enable/disable. Still somewhat expensive, but nowhere near as
> > bad as a full switch.
>
> This is essentially an optimized event switc
On 09/26/2013 10:49 PM, Tejun Heo wrote:
> On Wed, Sep 25, 2013 at 02:34:34AM +0800, Zhang Yanfei wrote:
>> From: Tang Chen
>>
>> Memory reserved for crashkernel could be large. So we should not allocate
>> this memory bottom up from the end of kernel image.
>>
>> When SRAT is parsed, we will be a
On Thu, Sep 26, 2013 at 11:43:02PM +0800, Zhang Yanfei wrote:
> > As Yinghai pointed out in another thread, do we need to worry about
> > falling back to top-down?
>
> I've explained to him. Nop, we don't need to worry about that. Because even
> the min_pfn_mapped becomes ISA_END_ADDRESS in the se
David Ahern wrote:
> Did you create a tarfile after this change, unpack it somewhere out of three
> and then verify perf builds?
Yeah, it builds fine. In fact, the archive generated from the current
upstream is broken.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
t
On Thu, Sep 26, 2013 at 11:37:34PM +0800, Zhang Yanfei wrote:
> >> + WARN_ONCE(1, "memblock: Failed to allocate memory in bottom up "
> >> + "direction. Now try top down direction.\n");
> >> + }
> >
> > You and I would know what was going on and what the consequence of t
On Thu, Sep 26, 2013 at 04:34:04PM +0100, Linus Torvalds wrote:
> On Thu, Sep 26, 2013 at 8:13 AM, Will Deacon wrote:
> >
> > This patch implements a dummy implementation for asm-generic, falling
> > back to the usual cmpxchg64 code.
>
> I don't like the "let's add dummy operations for everybody
On 09/26/2013 11:50 PM, Tejun Heo wrote:
> On Thu, Sep 26, 2013 at 11:37:34PM +0800, Zhang Yanfei wrote:
+ WARN_ONCE(1, "memblock: Failed to allocate memory in bottom up "
+ "direction. Now try top down direction.\n");
+ }
>>>
>>> You and I would know what
On 9/26/2013 6:42 AM, Srivatsa S. Bhat wrote:
On 09/26/2013 08:29 AM, Andrew Morton wrote:
On Thu, 26 Sep 2013 03:50:16 +0200 Andi Kleen wrote:
On Wed, Sep 25, 2013 at 06:21:29PM -0700, Andrew Morton wrote:
On Wed, 25 Sep 2013 18:15:21 -0700 Arjan van de Ven
wrote:
On 9/25/2013 4:47 PM,
On Tue, Sep 17, 2013 at 06:42:30PM +, KY Srinivasan wrote:
>
>
> > -Original Message-
> > From: Greg Kroah-Hartman [mailto:gre...@linuxfoundation.org]
> > Sent: Friday, September 13, 2013 11:33 AM
> > To: KY Srinivasan; Haiyang Zhang
> > Cc: de...@linuxdriverproject.org; linux-kernel@
Hi!
I got this in dmesg and lost my X session :-(.
Pavel
shrink_slab: i915_gem_inactive_scan+0x0/0xc0 negative objects to
delete nr=-973650123
shrink_slab: i915_gem_inactive_scan+0x0/0xc0 negative objects to
delete nr=-10845
From: Darbha Sriharsha
Adds support for the bq24735 charger chipset. The bq24735 is a
high-efficiency, synchronous battery charger.
It allows control of the charging current, input current, and the charger
voltage DAC's through SMBus.
Signed-off-by: Darbha Sriharsha
Signed-off-by: Rhyland Klei
On Mon, Sep 23, 2013 at 12:31:32PM +0200, Daniel Mack wrote:
> On 23.09.2013 12:19, Mark Brown wrote:
> > On Sun, Sep 22, 2013 at 09:51:45PM +0200, Daniel Mack wrote:
> >> Here are some trivial things for the ti_dac7512 driver.
> >>
> >> Mark, can you take them through your spi tree?
> >
> > I can
On 09/26/2013 11:48 PM, Tejun Heo wrote:
> On Thu, Sep 26, 2013 at 11:43:02PM +0800, Zhang Yanfei wrote:
>>> As Yinghai pointed out in another thread, do we need to worry about
>>> falling back to top-down?
>>
>> I've explained to him. Nop, we don't need to worry about that. Because even
>> the min
Richard Weinberger wrote:
> And, of course, this makes your patch valid.
> Can you also please ensure that your new defconfigs are minimal?
Yeah, it's close to a minimal configuration for the 3.10 kernel
(latest at the time of patch submission). I was aiming to minimize the
diff between the curren
On Fri, Sep 27, 2013 at 12:03:01AM +0800, Zhang Yanfei wrote:
> Ah, I see. You are saying another issue. He is worrying that if we use
> kexec to load the kernel high, say we have 16GB, we put the kernel in
> 15.99GB (just an example), so we only have less than 100MB above the kernel.
>
> But as I
Em Thu, Sep 26, 2013 at 09:18:48PM +0530, Ramkumar Ramachandra escreveu:
> David Ahern wrote:
> > Did you create a tarfile after this change, unpack it somewhere out of three
> > and then verify perf builds?
>
> Yeah, it builds fine. In fact, the archive generated from the current
> upstream is br
On Thu, Sep 26, 2013 at 05:53:21PM +0200, Oleg Nesterov wrote:
> On 09/26, Peter Zijlstra wrote:
> > void cpu_hotplug_done(void)
> > {
> > - cpu_hotplug.active_writer = NULL;
> > - mutex_unlock(&cpu_hotplug.lock);
> > + /* Signal the writer is done, no fast path yet. */
> > + __cpuhp_stat
301 - 400 of 779 matches
Mail list logo
