On Thu, Sep 13, 2012 at 09:54:09AM +0300, Tomi Valkeinen wrote:
> On Thu, 2012-09-13 at 15:36 +0900, Alex Courbot wrote:
> > On Thursday 13 September 2012 14:22:57 Tomi Valkeinen wrote:
> >
> > > However, I fear these board specific things may be quite a bit anything,
> > > so it may well be pwm,
From: Linus Walleij
The semantics of the interactions between GPIO and pinctrl may be
unclear, e.g. which one do you request first? This amends the
documentation to make this clear.
Reported-by: Domenico Andreoli
Signed-off-by: Linus Walleij
---
This is an attempt to write up some of the uncla
On Wed, Sep 12, 2012 at 22:41:09, Arnd Bergmann wrote:
> On Wednesday 12 September 2012, Hebbar, Gururaja wrote:
> > On Tue, Sep 11, 2012 at 18:29:36, Arnd Bergmann wrote:
>
> > > drivers/usb/musb/da8xx.c |2 +-
> >
> >
> > > .../asp.h => include/linux/pl
On Thu, 2012-09-13 at 09:00 +0200, Sascha Hauer wrote:
> On Thu, Sep 13, 2012 at 09:54:09AM +0300, Tomi Valkeinen wrote:
> > On Thu, 2012-09-13 at 15:36 +0900, Alex Courbot wrote:
> > > On Thursday 13 September 2012 14:22:57 Tomi Valkeinen wrote:
> > >
> > > > However, I fear these board specific
On Wed, 12 Sep 2012 09:19:25 -0700, Guenter Roeck wrote:
> On Wed, Sep 12, 2012 at 05:06:42PM +0200, Peter Senna Tschudin wrote:
> > From: Peter Senna Tschudin
> >
> > Remove useless kfree() and clean up code related to the removal.
>
> Queued for -next.
Patch looks good, but I don't see any "c
On Thursday 13 September 2012 14:54:09 Tomi Valkeinen wrote:
> * PGP Signed by an unknown key
>
> On Thu, 2012-09-13 at 15:36 +0900, Alex Courbot wrote:
>
> > On Thursday 13 September 2012 14:22:57 Tomi Valkeinen wrote:
> >
> >
> >
> > > However, I fear these board specific things may be qui
root_mem_cgroup->info.nodeinfo is initialized when the system boots.
But NODE_DATA(nid) is null if the node is not onlined, so
root_mem_cgroup->info.nodeinfo[nid]->zoneinfo[zone].lruvec.zone contains
an invalid pointer. If we use numactl to bind a program to the node
after onlining the node and its
>From a00cbfadc0053a3c21812593997a1b7338234a9f Mon Sep 17 00:00:00 2001
From: Ramesh Gupta G
Date: Thu, 13 Sep 2012 11:43:20 +0530
Subject: [PATCH v6 0/2] ARM: New cache API for iommu
This patch series is the next version to
- add a new cache maintenance api to support non-coherent iommu drivers
On Tue, Sep 11, 2012 at 11:13:26, S, Venkatraman wrote:
> On Tue, Sep 4, 2012 at 6:38 PM, Hebbar, Gururaja
> wrote:
> > From: Vaibhav Bedia
> >
> > In some cases mmc_suspend_host() is not able to claim the
> > host and proceed with the suspend process. The core returns
> > -EBUSY to the host con
>From e88037801393f86ade3c79bcc900d3c84d989655 Mon Sep 17 00:00:00 2001
From: Ramesh Gupta G
Date: Wed, 12 Sep 2012 13:07:26 +0530
Subject: [PATCH v6 1/2] ARM: new cache maintenance api for iommu
Non-coherent IOMMU drivers need to make sure
that the data held in the caches is available
for the sl
Hi Stephen,
On Thu, Sep 13, 2012 at 04:41:20PM +1000, Stephen Rothwell wrote:
> Today's linux-next merge of the arm-soc tree got a conflict in
> drivers/i2c/busses/i2c-omap.c between commit d9ebd04d3476 ("i2c: omap:
> switch to devm_* API") from the i2c-embedded tree and commit 07baca6f8fc2
> ("i2
>From a00cbfadc0053a3c21812593997a1b7338234a9f Mon Sep 17 00:00:00 2001
From: Ramesh Gupta G
Date: Wed, 12 Sep 2012 19:05:29 +0530
Subject: [PATCH v6 2/2] OMAP:IOMMU:flush L1 and L2 caches
OMAP IOMMU need to make sure that data in the L1 and L2 caches
is visible to the MMU hardware whenever the p
Dne 13.9.2012 02:30, Ezequiel Garcia napsal(a):
> Hi,
>
> On Sun, Sep 9, 2012 at 6:25 PM, David Rientjes wrote:
>> On Sat, 8 Sep 2012, Ezequiel Garcia wrote:
>>
>>> diff --git a/Makefile b/Makefile
>>> index ddf5be9..df6045a 100644
>>> --- a/Makefile
>>> +++ b/Makefile
>>> @@ -561,6 +561,10 @@ el
NVIDIA produces several Tegra SoCs viz Tegra20, Tegra30 etc.
In order to support USB PHY drivers on these SoCs, existing
PHY driver is split into SoC agnostic common USB PHY driver
and Tegra20-specific USB phy driver. This will facilitate
easy addition and deletion of phy drivers for Tegra SoCs.
S
On Thu, Sep 13, 2012 at 10:03:27AM +0300, Tomi Valkeinen wrote:
> On Thu, 2012-09-13 at 09:00 +0200, Sascha Hauer wrote:
> > On Thu, Sep 13, 2012 at 09:54:09AM +0300, Tomi Valkeinen wrote:
> > > On Thu, 2012-09-13 at 15:36 +0900, Alex Courbot wrote:
> > > > On Thursday 13 September 2012 14:22:57 To
On Thursday 13 September 2012 15:03:27 Tomi Valkeinen wrote:
> * PGP Signed by an unknown key
>
> On Thu, 2012-09-13 at 09:00 +0200, Sascha Hauer wrote:
>
> > On Thu, Sep 13, 2012 at 09:54:09AM +0300, Tomi Valkeinen wrote:
> >
> > > On Thu, 2012-09-13 at 15:36 +0900, Alex Courbot wrote:
> > >
>
On Thu, Sep 13, 2012 at 03:42:11PM +0900, Alex Courbot wrote:
> On Thursday 13 September 2012 14:25:53 Mark Brown wrote:
> > It would be sensible to make sure that the framework is done in such a
> > way that drivers can use it - there will be drivers (perhaps not display
> > ones) that have a kno
On Wed, Sep 12, 2012 at 03:52:25PM +, Arnd Bergmann wrote:
> On Tuesday 11 September 2012, Guennadi Liakhovetski wrote:
> > ipu.h is used by the dmaengine and IRQ driver under drivers/dma/ipu/, and
> > by its users drivers/media/platform/soc_camera/mx3_camera.c and
> > drivers/video/mx3fb.c.
On Thursday 13 September 2012 15:19:30 Mark Brown wrote:
> On Thu, Sep 13, 2012 at 03:42:11PM +0900, Alex Courbot wrote:
> > On Thursday 13 September 2012 14:25:53 Mark Brown wrote:
> > > It would be sensible to make sure that the framework is done in such a
> > > way that drivers can use it - ther
From: Namhyung Kim
So that the perf report won't lost the cpu utilization information.
For example, if there're two process that have same name.
$ perf report --stdio --showcpuutilization -s pid
[SNIP]
# Overhead sysus Command: Pid
# ...
From: Namhyung Kim
Print accumulated stat of a hist entry if requested.
Cc: Arun Sharma
Cc: Frederic Weisbecker
Signed-off-by: Namhyung Kim
---
tools/perf/ui/gtk/browser.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/tools/perf/ui/gtk/browser.c b/tools/perf/ui/gtk/browser.c
index 7
From: Namhyung Kim
Print accumulated stat of a hist entry if requested.
Cc: Arun Sharma
Cc: Frederic Weisbecker
Signed-off-by: Namhyung Kim
---
tools/perf/ui/browsers/hists.c | 4
1 file changed, 4 insertions(+)
diff --git a/tools/perf/ui/browsers/hists.c b/tools/perf/ui/browsers/hists
From: Namhyung Kim
Call add_hist_entry() for each callchain node to get an accumulated
stat for an entry. However skip nodes which do not have symbol info
as they caused subtle problems.
AFAICS the current sort methods cannot distinguish entries with NULL
dso/sym well so that processing a callc
From: Namhyung Kim
When symbol_conf.cumulate_callchain is requested, we need to sort the
entries by accumulated period value. To do this, separate out the
compare routine to hists__output_cmp().
In addition, if accumulated periods of two entries are same
(i.e. single path callchain) put the cal
From: Namhyung Kim
Print accumulated stat of a hist entry if requested.
Cc: Arun Sharma
Cc: Frederic Weisbecker
Signed-off-by: Namhyung Kim
---
tools/perf/ui/hist.c | 46 --
1 file changed, 44 insertions(+), 2 deletions(-)
diff --git a/tools/perf/
From: Namhyung Kim
Change the add_hist_entry() to make a template based on given @al.
It makes the callchain cumulation code simpler.
Cc: Arun Sharma
Cc: Frederic Weisbecker
Signed-off-by: Namhyung Kim
---
tools/perf/util/hist.c | 50 +-
1 file
From: Namhyung Kim
When --cumulate option is given, it will print accumulated hist stat
information. It requires callchain information.
Cc: Arun Sharma
Cc: Frederic Weisbecker
Signed-off-by: Namhyung Kim
---
tools/perf/builtin-report.c | 8
1 file changed, 8 insertions(+)
diff --g
On Thu, 2012-09-13 at 09:18 +0200, Sascha Hauer wrote:
> On Thu, Sep 13, 2012 at 10:03:27AM +0300, Tomi Valkeinen wrote:
> > On Thu, 2012-09-13 at 09:00 +0200, Sascha Hauer wrote:
> > > On Thu, Sep 13, 2012 at 09:54:09AM +0300, Tomi Valkeinen wrote:
> > > > On Thu, 2012-09-13 at 15:36 +0900, Alex C
From: Namhyung Kim
To support callchain accumulation, @entry should be recognized if it's
accumulated or not when add_hist_entry() called. The period of an
accumulated entry should be added to ->stat_acc but not ->stat. Add
@sample_self arg for that.
Cc: Arun Sharma
Cc: Frederic Weisbecker
Si
From: Namhyung Kim
To accumulate callchain information of a hist entry, following helper
functions are needed.
Cc: Arun Sharma
Cc: Frederic Weisbecker
Signed-off-by: Namhyung Kim
---
tools/perf/util/callchain.c | 15 +++
tools/perf/util/callchain.h | 17 +
2 files
Hi,
This is my first attempt to implement cumulative hist period report.
This work begins from Arun's SORT_INCLUSIVE patch [1] but I completely
rewrote it from scratch.
It basically adds period in a sample to every node in the callchain.
A hist_entry now has an additional fields to keep the cumul
On Thu, Sep 13, 2012 at 10:03:27AM +0300, Tomi Valkeinen wrote:
> On Thu, 2012-09-13 at 09:00 +0200, Sascha Hauer wrote:
> > On Thu, Sep 13, 2012 at 09:54:09AM +0300, Tomi Valkeinen wrote:
> > > On Thu, 2012-09-13 at 15:36 +0900, Alex Courbot wrote:
> > > > On Thursday 13 September 2012 14:22:57 To
On Thu, Sep 13, 2012 at 04:26:34PM +0900, Alex Courbot wrote:
> On Thursday 13 September 2012 15:19:30 Mark Brown wrote:
> > > On Thursday 13 September 2012 14:25:53 Mark Brown wrote:
> > > > It would be sensible to make sure that the framework is done in such a
> > > > way that drivers can use it
Hi Linus,
The following changes since commit 55d512e245bc7699a8800e23df1a24195dd08217:
Linux 3.6-rc5 (2012-09-08 16:43:45 -0700)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/arm/arm-soc.git
tags/fixes-for-linus
for you to fetch changes up to 2bc733e
From: Namhyung Kim
Maintain accumulated stat information in hist_entry->stat_acc if
symbol_conf.cumulate_callchain is set. Fields in ->stat_acc have same
vaules initially, and will be updated as callchain is processed later.
Cc: Arun Sharma
Cc: Frederic Weisbecker
Signed-off-by: Namhyung Kim
On Wed, Sep 12, 2012 at 11:36:28PM -0700, Olof Johansson wrote:
> I think it could be a good idea to split off the cleanups and fixes to
> a separate branch. For the other patches there seems to be enough for
> at least a 'dt' branch and either a multi-platform topic branch or a
> 'boards' topic b
From: Namhyung Kim
hist_entry__add_cpumode_period() and hist_entry__decay() are dealing
with hist_entry's stat fields only. So make them use the struct
directly.
Cc: Arun Sharma
Cc: Frederic Weisbecker
Signed-off-by: Namhyung Kim
---
tools/perf/util/hist.c | 20 ++--
1 file
From: Namhyung Kim
Add and use hist_entry__add_{period,stat} for calculating hist entry's
stat. It will be used for accumulated stats later as well.
Cc: Arun Sharma
Cc: Frederic Weisbecker
Signed-off-by: Namhyung Kim
---
tools/perf/util/hist.c | 26 ++
1 file changed
From: Namhyung Kim
The struct he_stat is for separating out statistics data of a hist
entry. It is required for later changes.
It's just a mechanical change and should have no functional
differences.
Cc: Arun Sharma
Cc: Frederic Weisbecker
Signed-off-by: Namhyung Kim
---
tools/perf/ui/brow
From: Namhyung Kim
Since it is set to 1 for a new hist entry, no need to set to
separately. Move it to a template entry.
Cc: Arun Sharma
Cc: Frederic Weisbecker
Signed-off-by: Namhyung Kim
---
tools/perf/util/hist.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/tool
On Thu, Sep 13, 2012 at 12:31 AM, David Brown wrote:
> On Wed, Sep 12, 2012 at 11:36:28PM -0700, Olof Johansson wrote:
>
>> I think it could be a good idea to split off the cleanups and fixes to
>> a separate branch. For the other patches there seems to be enough for
>> at least a 'dt' branch and
On 09/13/2012 09:52 AM, Linus Walleij wrote:
> On Wed, Sep 12, 2012 at 10:27 PM, Tony Lindgren wrote:
>> * Peter Ujfalusi [120911 01:54]:
>>> With pinctrl-single,bits it is possible to update just part of the register
>>> within the pinctrl-single,function-mask area.
>>> This is useful when one r
Hi Samuel,
On Thu, 13 Sep 2012 08:59:25 +0200 Samuel Iglesias Gonsálvez
wrote:
>
> On Thu, 2012-09-13 at 16:14 +1000, Stephen Rothwell wrote:
> >
> > Today's linux-next merge of the staging tree got a conflict in
> > drivers/staging/ipack/devices/ipoctal.c between commit 734cc1783816
> > ("TTY:
Hi Andrew,
After merging the akpm tree, today's linux-next build (x86_64
allmodconfig) failed like this:
drivers/thermal/cpu_cooling.c: In function 'get_idr':
drivers/thermal/cpu_cooling.c:89:14: error: 'MAX_ID_MASK' undeclared (first use
in this function)
Caused by commit "idr: rename MAX_LEVE
On 13 September 2012 13:14, Stephen Rothwell wrote:
> Hi Andrew,
>
> After merging the akpm tree, today's linux-next build (x86_64
> allmodconfig) failed like this:
>
> drivers/thermal/cpu_cooling.c: In function 'get_idr':
> drivers/thermal/cpu_cooling.c:89:14: error: 'MAX_ID_MASK' undeclared (fir
On Thu, Sep 13, 2012 at 09:29:20AM +0200, Thierry Reding wrote:
> On Thu, Sep 13, 2012 at 10:03:27AM +0300, Tomi Valkeinen wrote:
> > On Thu, 2012-09-13 at 09:00 +0200, Sascha Hauer wrote:
> > > On Thu, Sep 13, 2012 at 09:54:09AM +0300, Tomi Valkeinen wrote:
> > > > On Thu, 2012-09-13 at 15:36 +090
On Thu, 13 Sep 2012 17:44:41 +1000 Stephen Rothwell
wrote:
> Hi Andrew,
>
> After merging the akpm tree, today's linux-next build (x86_64
> allmodconfig) failed like this:
>
> drivers/thermal/cpu_cooling.c: In function 'get_idr':
> drivers/thermal/cpu_cooling.c:89:14: error: 'MAX_ID_MASK' unde
Fengguang Wu writes:
> On Wed, Sep 12, 2012 at 03:28:42AM +0900, OGAWA Hirofumi wrote:
>>
>> If bdi has BDI_CAP_NO_WRITEBACK, bdi_forker_thread() doesn't start
>> writeback thread. This means there is no consumer of work item made
>> by bdi_queue_work().
>>
>> This adds to checking of !bdi_cap_
On Thu, 2012-09-13 at 09:29 +0200, Thierry Reding wrote:
> On Thu, Sep 13, 2012 at 10:03:27AM +0300, Tomi Valkeinen wrote:
> > On Thu, 2012-09-13 at 09:00 +0200, Sascha Hauer wrote:
> > > On Thu, Sep 13, 2012 at 09:54:09AM +0300, Tomi Valkeinen wrote:
> > > > On Thu, 2012-09-13 at 15:36 +0900, Alex
On Thu, Sep 13, 2012 at 03:46:00AM +0200, Bruce Humphrey wrote:
> Replace printk(KERN_XXX with dev_info, dev_warn, dev_dbg as appropiate in
> dyna_pci10xx
>
> Signed-off-by: Bruce Humphrey Ventura
> ---
> drivers/staging/comedi/drivers/dyna_pci10xx.c | 14 ++
> 1 file changed, 6 i
Hi all,
After merging the final tree, today's linux-next build (sparc64 defconfig)
failed like this:
mm/internal.h: In function 'swap_cache_hit':
mm/internal.h:377:3: error: implicit declaration of function
'atomic_dec_if_positive' [-Werror=implicit-function-declaration]
Caused by commit "swap:
On Thu, Sep 13, 2012 at 03:46:36AM +0200, Bruce Humphrey wrote:
> Replace printk(KERN_XXX with the appropiate dev_info, dev_warn, dev_dbg in
> fl512.c
>
> Signed-off-by: Bruce Humphrey Ventura
> ---
> drivers/staging/comedi/drivers/fl512.c | 12 +++-
> 1 file changed, 7 insertions(+),
After the release of Linux 3.5 in July, August saw the big XFS merge for
the Linux 3.6 merge window. In the meantime the XFS tree has seen low
activity, with refined support for SEEK_HOLE/SEEK_DATA that takes unwritten
extents into account as the main feature. A couple of fixes also went in
and m
On Wed, Sep 12, 2012 at 06:57:44PM +0900, Alexandre Courbot wrote:
> Some device drivers (panel backlights especially) need to follow precise
> sequences for powering on and off, involving gpios, regulators, PWMs
> with a precise powering order and delays to respect between each steps.
> These sequ
Hi all,
After merging the final tree, today's linux-next build (sparc64 defconfig)
failed like this:
drivers/built-in.o: In function `rtc_hctosys':
hctosys.c:(.init.text+0x4a98): undefined reference to `rtc_hctosys_ret'
hctosys.c:(.init.text+0x4b54): undefined reference to `rtc_hctosys_ret'
hctos
On Wed, Sep 12, 2012 at 02:46:56PM +0300, Peter Ujfalusi wrote:
> Hello,
>
> This series will switch the OMAP audio to use dmaengine.
> The final patch which does the switch was based on Russell King's earlier
> patch.
I'm fine with this from the ASoC side but it sounds like you're going to
resp
> >> -> ESTALE will be returned -> discard old FH -> restart from LOOKUP ->
> >> make cached inode -> use returned new FH.
> >>
> >> Yeah, I know this is unstable (there is no perfect solution for now),
> >
> > You may end up with a totally different file, of course:
> >
> > client:
On Thu, 2012-09-06 at 13:40 +0800, Jeremy Kerr wrote:
> From: Matthew Garrett
>
> The existing EFI variables code only supports variables of up to 1024
> bytes. This limitation existed in version 0.99 of the EFI
> specification,
> but was removed before any full releases. Since variables can now
於 二，2012-09-11 於 15:23 +0800，lee joey 提到：
> From: Matthew Garrett
>
> The existing EFI variables code only supports variables of up to 1024
> bytes. This limitation existed in version 0.99 of the EFI
> specification,
> but was removed before any full releases. Since variables can now be
> larger
gt; [1]
>> > http://git.kernel.org/?p=linux/kernel/git/next/linux-next.git;a=commitdiff;h=b276fc1e875a51e4a9dc3322ed008bf4ae481baf
>>
>> Henrik,
>>
>> It looks like your changes are causing the panic.
>
> Indeed, I have pushed the fix below to next already.
On Thursday 13 September 2012 15:50:37 Sascha Hauer wrote:
> On Thu, Sep 13, 2012 at 09:29:20AM +0200, Thierry Reding wrote:
> > On Thu, Sep 13, 2012 at 10:03:27AM +0300, Tomi Valkeinen wrote:
> > > On Thu, 2012-09-13 at 09:00 +0200, Sascha Hauer wrote:
> > > > On Thu, Sep 13, 2012 at 09:54:09AM +0
On Thu, 2012-09-13 at 08:49 +0200, Mike Galbraith wrote:
> On Thu, 2012-09-13 at 06:11 +0200, Vincent Guittot wrote:
> > On tickless system, one CPU runs load balance for all idle CPUs.
> > The cpu_load of this CPU is updated before starting the load balance
> > of each other idle CPUs. We should
Thanks, Peter. I will schedule these changes for our next posting.
Ursula Braun
> Peter Senna Tschudin wrote on 12/09/2012 19:03:14:
>
> > From:
> >
> > Peter Senna Tschudin
> >
> > To:
> >
> > Ursula Braun1/Germany/IBM@IBMDE
> >
> > Cc:
> >
> > triv...@kernel.org, kernel-janit...@vger.ker
On Thu, 2012-09-13 at 06:11 +0200, Vincent Guittot wrote:
> On tickless system, one CPU runs load balance for all idle CPUs.
> The cpu_load of this CPU is updated before starting the load balance
> of each other idle CPUs. We should instead update the cpu_load of the
> balance_cpu.
>
> Signed-off
Hi all,
Changes since 201209012:
The staging tree gained a conflict against the tty tree.
The arm-soc tree gained a conflict against the i2c-embedded tree.
The tegra tree lost 2 conflicts.
The akpm tree gained 3 build failures for which I applied a merge fix
patch and reverted 3 commits.
V2:
1. Rebase on mfd/for-next tree.
In-Reply-To:
--
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 at http://www.tux.org/lkml/
Remove the register offset definition. All these register offset
are transfered as IORESOURCE_REG resources.
Signed-off-by: Haojian Zhuang
---
drivers/mfd/max8925-core.c | 31 ++---
drivers/video/backlight/max8925_bl.c | 79 ++
2 files change
Remove array in parent's platform data. Use struct regulator_init_data
as regulator device's platform data directly. So a lot of pdata are
added into parent's platform data. And voltage out register offset
is used as IORESOURCE_REG to distinguish different regualtor devices.
Signed-off-by: Haojian
On Tue, 2012-09-11 at 11:33 -0700, Suresh Siddha wrote:
> > nohz_balance_enter_idle is good a name too. but I name it as
> > set_nohz_tick_stopped, since there is a clear_nohz_tick_stopped(), that
> > just do the opposed action of this function. According to this, is it
> > better to another functi
On 13/09/12 01:15, richard -rw- weinberger wrote:
On Thu, Sep 13, 2012 at 12:50 AM, Tracey Dent wrote:
Makefile.rej should not be there. That was introduced
in commit 3fa68afc3d774bab1e91cbb3a3cdd1e36068ee95 .
Linus' tree does not contain such a commit id.
Hi,
my bad .. its in linux-next (
On Thu, Sep 13, 2012 at 05:21:10PM +0900, Alex Courbot wrote:
> On Thursday 13 September 2012 15:50:37 Sascha Hauer wrote:
> > On Thu, Sep 13, 2012 at 09:29:20AM +0200, Thierry Reding wrote:
> > > On Thu, Sep 13, 2012 at 10:03:27AM +0300, Tomi Valkeinen wrote:
> > > > On Thu, 2012-09-13 at 09:00 +0
Hi Andrew,
On Thu, 13 Sep 2012 00:56:57 -0700 Andrew Morton
wrote:
>
> On Thu, 13 Sep 2012 17:44:41 +1000 Stephen Rothwell
> wrote:
>
> > After merging the akpm tree, today's linux-next build (x86_64
> > allmodconfig) failed like this:
> >
> > drivers/thermal/cpu_cooling.c: In function 'get_
Hi Sachin,
On Thu, 13 Sep 2012 13:19:48 +0530 Sachin Kamat wrote:
>
> > - * This program is distributed in the hope that it will be useful, but
> > + * This program is distributed in the hope that it will be useful,
> > butX_ID_MASK
>
> ^
> Looks like a
Namjae Jeon writes:
>> I see. So, client can't solve the ESTALE if inode cache was evicted,
>> right? (without application changes)
>
> There can be situation where we may get not only ESTALE but EIO also.
>
> For example,
> ---
> fd = open(“foo.txt”);
> while (1) {
>
On Thu, Sep 13, 2012 at 11:00:18AM +0300, Tomi Valkeinen wrote:
> Yes, I think the backlight and the panel should be considered separate
> devices. Just like, say, a touch screen and a panel may happen to be in
> the same display module, a backlight and a panel can be in the same
> display module.
On 09/12/2012 06:06 PM, Srivatsa S. Bhat wrote:
> On 07/19/2012 10:45 PM, Paul E. McKenney wrote:
>> On Thu, Jul 19, 2012 at 05:39:30PM +0530, Srivatsa S. Bhat wrote:
>>> Hi Paul,
>>>
>>> While running a CPU hotplug stress test on v3.5-rc7+
>>> (mainline commit 8a7298b7805ab) I hit this warning.
>>
Hello,
On Mon, Aug 29, 2011 at 01:01:42PM -0600, Grant Likely wrote:
> On Thu, Feb 17, 2011 at 10:18:53PM +0100, Uwe Kleine-König wrote:
> > Signed-off-by: Uwe Kleine-König
>
> Applied, thanks.
I cannot see it in Linus' tree?!
> > ---
> > drivers/gpio/gpiolib.c |1 +
> > 1 files changed, 1
Wrong button make me removed others guys from the thread.
Sorry for this mistake.
On 13 September 2012 09:56, Mike Galbraith wrote:
> On Thu, 2012-09-13 at 09:44 +0200, Vincent Guittot wrote:
>> On 13 September 2012 09:29, Mike Galbraith wrote:
>> > On Thu, 2012-09-13 at 08:59 +0200, Vincent Gu
> Remove useless kfree() and clean up code related to the removal.
...
> diff --git a/drivers/isdn/gigaset/common.c b/drivers/isdn/gigaset/common.c
> index aa41485..30a6b17 100644
> --- a/drivers/isdn/gigaset/common.c
> +++ b/drivers/isdn/gigaset/common.c
> @@ -1123,7 +1123,6 @@ struct gigaset_driv
Hi, all,
On 四, 2012-09-13 at 17:44 +1000, Stephen Rothwell wrote:
> Hi Andrew,
>
> After merging the akpm tree, today's linux-next build (x86_64
> allmodconfig) failed like this:
>
> drivers/thermal/cpu_cooling.c: In function 'get_idr':
> drivers/thermal/cpu_cooling.c:89:14: error: 'MAX_ID_MASK'
On Thu, 2012-09-13 at 10:37 +0200, Vincent Guittot wrote:
> > I think you need to present numbers showing benefit. Crawling all over
> > a mostly idle (4096p?) box is decidedly bad thing to do.
Yeah, but we're already doing that anyway.. we know nohz idle balance
doesn't scale. Venki and Suresh
On 13 September 2012 03:06, Randy Dunlap wrote:
> From: Randy Dunlap
>
> cpu_cooling.c (CONFIG_CPU_THERMAL) uses cpu frequency table
> intefaces so it should select CPU_FREQ_TABLE.
> Fixes these build errors:
>
> drivers/built-in.o: In function `cpufreq_get_max_state':
> cpu_cooling.c:(.text+0x4e
On Thu, Sep 13, 2012 at 10:20:30AM +0800, Raul Xiong wrote:
> I have several questions:
> 1. Even we call flush_calche_all in __cpu_suspend_save, since later we
> will outer_clean_range which may cause cache operations so we still
> need to flush again in finisher, right?
Why would it? Any data w
On Thu, 2012-09-13 at 10:45 +0200, Peter Zijlstra wrote:
> On Thu, 2012-09-13 at 10:37 +0200, Vincent Guittot wrote:
> > > I think you need to present numbers showing benefit. Crawling all over
> > > a mostly idle (4096p?) box is decidedly bad thing to do.
>
> Yeah, but we're already doing that
On Thu, Sep 13, 2012 at 10:46 AM, Amit Kachhap wrote:
> On 13 September 2012 03:06, Randy Dunlap wrote:
>> From: Randy Dunlap
>>
>> cpu_cooling.c (CONFIG_CPU_THERMAL) uses cpu frequency table
>> intefaces so it should select CPU_FREQ_TABLE.
>> Fixes these build errors:
>>
>> drivers/built-in.o:
way input folks should look at this.
>>> >
>>> > Kind Regards,
>>> > - Sedat -
>>> >
>>> > [1]
>>> > http://git.kernel.org/?p=linux/kernel/git/next/linux-next.git;a=commitdiff;h=b276fc1e875a51e4a9dc3322ed008bf4ae481baf
>>&g
Hi, pls allow me introduce.
We are a professional manufacturer of ink and master for Riso, Ricoh, Duplo and
Gestetner over 12 years in Guangzhou, China, we also have a close relationship
with China Riso.
If you have any need, I will send you best price, thanks.
Best regards,
Lucky
Shibakawa
On Fri, Sep 07, 2012 at 08:47:45PM +0100, Arnd Bergmann wrote:
> On Friday 07 September 2012, Catalin Marinas wrote:
> >
> > From: Will Deacon
> >
> > This patch adds support for 32-bit applications. The vectors page is a
> > binary blob mapped into the application user space at 0x (the
On Thu, Sep 13, 2012 at 10:22 AM, Stephen Rothwell
wrote:
> Hi all,
>
> Changes since 201209012:
>
> The staging tree gained a conflict against the tty tree.
>
> The arm-soc tree gained a conflict against the i2c-embedded tree.
>
> The tegra tree lost 2 conflicts.
>
> The akpm tree gained 3 build
On 12.09.12 11:50:57, Arnaldo Carvalho de Melo wrote:
> Em Wed, Sep 12, 2012 at 07:46:55PM +0200, Robert Richter escreveu:
> > On 12.09.12 09:16:28, David Ahern wrote:
> > >
> > > Kernel side AMD currently ignores all exclude_* bits, so there is no
> > > impact
> > > to existing IBS code paths. R
On Thu, Sep 13, 2012 at 4:17 AM, Michal Marek wrote:
> Dne 13.9.2012 02:30, Ezequiel Garcia napsal(a):
>> Hi,
>>
>> On Sun, Sep 9, 2012 at 6:25 PM, David Rientjes wrote:
>>> On Sat, 8 Sep 2012, Ezequiel Garcia wrote:
>>>
diff --git a/Makefile b/Makefile
index ddf5be9..df6045a 100644
>>>
On 10 July 2012 15:42, Peter Zijlstra wrote:
> On Tue, 2012-07-10 at 14:35 +0200, Vincent Guittot wrote:
>>
>> May be the last one which enable ARCH_POWER should also go into tip ?
>>
> OK, I can take it.
Hi Peter,
I can't find the patch that enable ARCH_POWER in the tip tree. Have
you take it i
On 09/13/2012 06:18 AM, Andrew Morton wrote:
> On Wed, 12 Sep 2012 20:56:41 +0800
> Xiao Guangrong wrote:
>
>> To make the code more clear, move release the lock out of
>> khugepaged_alloc_page
>>
>> ...
>>
>> --- a/mm/huge_memory.c
>> +++ b/mm/huge_memory.c
>> @@ -1854,11 +1854,6 @@ static stru
On 09/13/2012 11:11 AM, Mark Brown wrote:
> On Wed, Sep 12, 2012 at 02:46:56PM +0300, Peter Ujfalusi wrote:
>> Hello,
>>
>> This series will switch the OMAP audio to use dmaengine.
>> The final patch which does the switch was based on Russell King's earlier
>> patch.
>
> I'm fine with this from t
On Thu, Sep 13, 2012 at 09:31:45AM +0100, David Laight wrote:
> > Remove useless kfree() and clean up code related to the removal.
> ...
> > diff --git a/drivers/isdn/gigaset/common.c b/drivers/isdn/gigaset/common.c
> > index aa41485..30a6b17 100644
> > --- a/drivers/isdn/gigaset/common.c
> > +++ b
On 09/13/2012 02:27 PM, Hugh Dickins wrote:
> On Wed, 12 Sep 2012, Xiao Guangrong wrote:
>> On 09/12/2012 10:03 AM, Hugh Dickins wrote:
>>
>>> What brought me to look at it was hitting "BUG at mm/huge_memory.c:1842!"
>>> running tmpfs kbuild swapping load (with memcg's memory.limit_in_bytes
>>> for
> Seems to me that (assuming kfree(NULL) is ok) the kfree()
> is best left in - just in case some other error path is
> added after drv->cs is assigned.
> Better safe than a memory leak.
I'm not sure if I got your point. Now the label "error:" is only
reached if drv->cs is NULL. There is not other
On 09/03/2012 10:16 AM, Michael Wang wrote:
> On 08/22/2012 10:40 AM, Michael Wang wrote:
>> From: Michael Wang
>>
>> Fengguang Wu has reported the bug:
>>
>> [0.043953] BUG: scheduling while atomic: swapper/0/1/0x1002
>> [0.044017] no locks held by swapper/0/1.
>> [0.044692] Pid:
On 13/09/12 09:57, Christoph Jung wrote:
Am 13.09.2012 10:49, schrieb Alan Jenkins:
On 13/09/12 08:25, Christoph Jung wrote:
Hello,
I am from the company "Code Mercenaries GmbH" from Germany. We have
some USB HID devices wich work with Linux.
Since kernel version 2.6 our default products will
On Thu, Aug 30, 2012 at 06:10:36PM -, m-kariche...@ti.com wrote:
> As a first step towards migrating davinci platforms to use common clock
> framework, replace all instances of clk_enable() with clk_prepare_enable()
> and clk_disable() with clk_disable_unprepare(). Until the platform is
> switc
1 - 100 of 670 matches
Mail list logo
