On Thu, Sep 27, 2012 at 07:22:38PM +0200, Joachim Eastwood wrote:
> [ 13.14] sysfs: cannot create duplicate filename
> '/devices/platform/ssc.0/atmel-ssc-dai.0'
> [ 13.14] Modules linked in: snd_soc_mpa1600_wm8776(+)
Oh, dear. This is probably a genuine bug, triggered by but not real
Hi,
On Thu, Sep 27, 2012 at 4:03 PM, Russell King - ARM Linux
wrote:
> On Thu, Sep 27, 2012 at 02:58:09PM +0100, Russell King - ARM Linux wrote:
>> On Thu, Sep 27, 2012 at 07:47:46AM +0800, Ming Lei wrote:
>> > On Thu, Sep 27, 2012 at 4:23 AM, Russell King - ARM Linux
>> > wrote:
>> > > To be ho
2012/9/27 Tekkaman Ninja :
> This is a Chinese translated version of
> Documentation/IRQ.txt
>
> Signed-off-by: Fu Wei
>
Acked-by: Harry Wei
--
Thanks
Harry Wei
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More
SNIP
> diff --git a/tools/perf/util/parse-events.c b/tools/perf/util/parse-events.c
> index bf5d033ee1b4..3c52d0ab9270 100644
> --- a/tools/perf/util/parse-events.c
> +++ b/tools/perf/util/parse-events.c
> @@ -830,6 +830,7 @@ int parse_events(struct perf_evlist *evlist, const char
> *str,
>
For checkpoint/restore we need to know if tty has
exclusive or packet mode set, as well as if pty
is currently locked. Just to be able to restore
this characteristics.
For this sake the following ioctl codes are introduced
- TIOCGPKT to get packet mode state
- TIOCGPTLCK to get Pty locked state
Since this ioctl is for pty devices only move it to pty.c.
Suggested-by: Alan Cox
Signed-off-by: Cyrill Gorcunov
CC: "H. Peter Anvin"
CC: Greg Kroah-Hartman
CC: Pavel Emelyanov
CC: Jiri Slaby
---
drivers/tty/pty.c | 29 +
drivers/tty/tty_ioctl.c | 20 --
For c/r we need some additional bits to fetch from terminal
connection status to be able to recreate it on restore. This
series adds appropriate ioctls. Please review, i've tested
them locally but still.
Cyrill
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
t
On Thu, Sep 27, 2012 at 9:16 AM, Myklebust, Trond
wrote:
>
> I cannot see how that BUG_ON can be triggered in the current code, given
> that the only place where idmap->idmap_key_cons is set to a non-NULL
> value is covered by a mutex, and that it is always cleared before we
> release said mutex.
On Thu, 27 Sep 2012, Borislav Petkov wrote:
On Thu, Sep 27, 2012 at 12:17:22AM -0700, da...@lang.hm wrote:
It seems to me that trying to figure out if you are going to
overload the L2 is an impossible task, so just assume that it will
all fit, and the worst case is you have one balancing cycle
On Thu, 27 Sep 2012, Peter Zijlstra wrote:
On Wed, 2012-09-26 at 11:19 -0700, Linus Torvalds wrote:
For example, it starts with the maximum target scheduling domain, and
works its way in over the scheduling groups within that domain. What
the f*ck is the logic of that kind of crazy thing? It n
On 2012-09-27 16:35, Greg Kroah-Hartman wrote:
On Thu, Sep 27, 2012 at 10:31:17AM +0100, Ian Abbott wrote:
On 2012-09-26 18:56, Greg Kroah-Hartman wrote:
On Wed, Sep 26, 2012 at 10:56:06AM -0700, Greg Kroah-Hartman wrote:
With 3.6 about to be released, I've now closed the 3.7 staging-next tre
The following changes since commit 5698bd757d55b1bb87edd1a9744ab09c142abfc2:
Linux 3.6-rc6 (2012-09-16 14:58:51 -0700)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb.git/ tags/usb-3.6-rc7
for you to fetch changes up to 0d00dc2611abbe6ad244d5
On 09/27/2012 07:07 PM, Christoph Lameter wrote:
> On Thu, 27 Sep 2012, Glauber Costa wrote:
>
>> --- a/mm/slab_common.c
>> +++ b/mm/slab_common.c
>> @@ -239,7 +239,23 @@ static void s_stop(struct seq_file *m, void *p)
>>
>> static int s_show(struct seq_file *m, void *p)
>> {
>> -return slab
On 09/24/2012 02:32 PM, Xiao Guangrong wrote:
> 3 places after the whole patchset (There are some cleanups after this patch).
>
>> and one by even stronger is_error_pfn().
>
> This one is:
>
> | if (!is_error_pfn(pfn)) {
> |kvm_release_pfn_clean(pfn);
> |ret
On Thu, Sep 27, 2012 at 09:10:11AM +0200, Ingo Molnar wrote:
> The theory would be that this patch fixes psql performance, with CPU
> selection being a measurable but second order of magnitude effect. How
> well does practice match theory in this case?
Yeah, it looks a bit better than default linu
Am Wed, 26 Sep 2012 16:04:03 -0600
schrieb Alex Williamson :
> On Wed, 2012-09-26 at 13:50 -0600, Alex Williamson wrote:
> > On Wed, 2012-09-26 at 10:21 -0600, Alex Williamson wrote:
> > > On Wed, 2012-09-26 at 17:10 +0200, Roedel, Joerg wrote:
> > > > On Wed, Sep 26, 2012 at 08:35:59AM -0600, Ale
Am 27.09.2012 17:46, schrieb Alexander Holler:
Hello,
Am 27.09.2012 17:12, schrieb Jan Kara:
Just some thoughts about your oops:
The assertion which fails is:
BUG_ON(!list_empty(&bh->b_assoc_buffers));
Now b_assoc_buffers isn't used very much. In particular ext4 which you
seem
to be using d
On Thu, Sep 27, 2012 at 10:54 AM, Alex Deucher wrote:
> On Thu, Sep 27, 2012 at 9:23 AM, Andres Freund wrote:
>> On Thursday, September 27, 2012 03:14:31 PM Alex Deucher wrote:
>>> On Thu, Sep 27, 2012 at 2:46 AM, Andres Freund wrote:
>>> > On Wednesday, September 26, 2012 03:42:40 PM Deucher, A
On Thu, 2012-09-27 at 17:39 +0200, Joerg Roedel wrote:
> On Thu, Sep 27, 2012 at 03:32:02PM +, Myklebust, Trond wrote:
>
> > Does your checked out copy of 3.6-rc7 contain commit c50669 (NFS:
> > Clear key construction data if the idmap upcall fails)? The latter was
> > merged in3.6-rc3, and is
On 23.8.2012 20:55, Benjamin Poirier wrote:
> This patch series adds "jump to" keys (similar to the cscope interface) to the
> search results of "make menuconfig" so that we can go directly to the menu
> entry for a config option after searching for it.
>
> Patches 1-4 implement the basic function
On Thu, Sep 27, 2012 at 02:34:45PM +, Arnd Bergmann wrote:
> On Thursday 27 September 2012, Mark Brown wrote:
> > The driver shouldn't be relying on irq_base at all, it should use
> > regmap_get_virq() to look up the interrupt number. If it relies on
> > irq_base then the user is forced to as
On Thu, Sep 27, 2012 at 05:00:37PM +0100, Alan Cox wrote:
> > > Otherwise - TICOGPKT is specific to pty devices. Please therefore put it
> > > in the pty.c code and note that not all platforms use asm-geneic TTY
> > > ioctls so check carefully they all build.
> >
> > I put it into tty_ioctl.c simp
On Thu, Sep 27, 2012 at 9:11 PM, Inderpal Singh
wrote:
> On 27 September 2012 15:18, Vinod Koul wrote:
>> On Wed, 2012-09-26 at 12:11 +0530, Inderpal Singh wrote:
>>> If we fail pl330_remove while some client is queued, the force unload
>>> will fail and the
>>> force unload will lose its purpose
Am 27.09.2012 17:46, schrieb "Jan H. Schönherr":
> If we say "if LOG_CONT is set, this message continues the previous one",
> we can also say "there is no prefix on this message". Then on the other
> hand, we would need a "whatever comes next, it does not continue this
> message"
Thinking a bi
Hello,
On Thursday, September 27, 2012 1:29 PM Thierry Reding wrote:
> any idea why CMA might be broken in next-20120926. I see that there
> haven't been any major changes to CMA itself, but there's been quite a
> bit of restructuring of various memory allocation bits lately. I wasn't
> able to t
> > Otherwise - TICOGPKT is specific to pty devices. Please therefore put it
> > in the pty.c code and note that not all platforms use asm-geneic TTY
> > ioctls so check carefully they all build.
>
> I put it into tty_ioctl.c simply because TIOCPKT was there already so
> I thought it's good idea t
Hi Konrad,
I have applied my patch to your #linux-next, and compiled. I don't
experience the same problem that you do - both PV and HVM boot and work.
Do you have anything special in your setup that might help me reproduce
the problem?
On Fri, 2012-09-21 at 19:41 +0100, Konrad Rzeszutek Wilk wr
On Thu, Sep 27, 2012 at 04:13:12PM +0100, Alan Cox wrote:
> > Well, sure inside our tool before doing checkpoint we stop all
> > tasks which are part of dumpee process tree. This unfortunatly
> > doesn't apply to these ioctl calls. Peter, any idea how to deal
> > with that?
>
> I suspect you can't
Hello,
Am 27.09.2012 17:12, schrieb Jan Kara:
Just some thoughts about your oops:
The assertion which fails is:
BUG_ON(!list_empty(&bh->b_assoc_buffers));
Now b_assoc_buffers isn't used very much. In particular ext4 which you seem
to be using doesn't use this list at all (except when mounted
Am 27.09.2012 15:39, schrieb Kay Sievers:
> On Thu, Sep 27, 2012 at 12:33 AM, "Jan H. Schönherr"
> wrote:
>> "Tested" as in: it fixes my use case: multiple printk()s shortly after each
>> other -- with KERN_prefix but without a newline at the end. Those were
>> sometimes concatenated since that pr
On 25/09/12 20:08, Rohit Vaswani wrote:
> Any comments ?
>
> Marc, would it be possible for you to pull this into your timers-next tree ?
Hi Rohit,
Sorry for the delay.
I'll give these patches a whirl first thing tomorrow.
Thanks,
M.
--
Jazz is not dead. It just smells funny...
--
T
On 09/23/2012 08:56 PM, Petr Holasek wrote:
Introduces new sysfs boolean knob /sys/kernel/mm/ksm/merge_across_nodes
which control merging pages across different numa nodes.
When it is set to zero only pages from the same node are merged,
otherwise pages from all nodes can be merged together (defa
Hello,
I'm observing a high CPU usage at my ThinkPad T420 (i5-2540M CPU), w/
integrated intel graphic.
Powertop-2.1 shows that the GPU is always at 100%, although I've defined
these settings :
$> cat /etc/modprobe.d/i915.conf
options i915 i915_enable_rc6=7 lvds_downclock=0
Kernel 3.5.4 works fin
On 27 September 2012 15:18, Vinod Koul wrote:
> On Wed, 2012-09-26 at 12:11 +0530, Inderpal Singh wrote:
>> If we fail pl330_remove while some client is queued, the force unload
>> will fail and the
>> force unload will lose its purpose.
>> How about conditionally DMA_TERMINATE_ALL and free resour
On Thu, Sep 27, 2012 at 03:32:02PM +, Myklebust, Trond wrote:
> Does your checked out copy of 3.6-rc7 contain commit c50669 (NFS:
> Clear key construction data if the idmap upcall fails)? The latter was
> merged in3.6-rc3, and is reported to fix the problem for the other
> testers.
Yes, it co
This is a Chinese translated version of
Documentation/IRQ.txt
Signed-off-by: Fu Wei
---
Documentation/zh_CN/IRQ.txt | 39 +++
1 file changed, 39 insertions(+)
create mode 100644 Documentation/zh_CN/IRQ.txt
diff --git a/Documentation/zh_CN/IRQ.txt b/Docume
On Thu, Sep 27, 2012 at 10:31:17AM +0100, Ian Abbott wrote:
> On 2012-09-26 18:56, Greg Kroah-Hartman wrote:
> >On Wed, Sep 26, 2012 at 10:56:06AM -0700, Greg Kroah-Hartman wrote:
> >>
> >>With 3.6 about to be released, I've now closed the 3.7 staging-next tree
> >>for new features / cleanups. It'
> -Original Message-
> From: Joerg Roedel [mailto:j...@8bytes.org]
> Sent: Thursday, September 27, 2012 10:52 AM
> To: Myklebust, Trond
> Cc: Joerg Roedel; linux-...@vger.kernel.org; linux-kernel@vger.kernel.org;
> torva...@linux-foundation.org
> Subject: Re: kernel BUG at /data/lemmy/linux
On Thu, Sep 27, 2012 at 04:13:12PM +0100, Alan Cox wrote:
> > Well, sure inside our tool before doing checkpoint we stop all
> > tasks which are part of dumpee process tree. This unfortunatly
> > doesn't apply to these ioctl calls. Peter, any idea how to deal
> > with that?
>
> I suspect you can't
2012/9/25 Michael Neuling :
> Michael Neuling wrote:
>
>> Frederic Weisbecker wrote:
>>
>> > On Thu, Aug 16, 2012 at 02:23:54PM +1000, Michael Neuling wrote:
>> > > Hi,
>> > >
>> > > I've been trying to get hardware breakpoints with perf to work on POWER7
>> > > but I'm getting the following:
>>
On Thu, Sep 27, 2012 at 02:17:05PM +1000, Dave Airlie wrote:
> Hi guys,
>
> we've been seeing an error with nouveau and I'm not sure if its new or
> we just never spent time looking into it.
>
> The basics are when a new drm client opens the device it gets a
> channel assigned, we allocate the ch
On Thu, 27 Sep 2012, Glauber Costa wrote:
> --- a/mm/slab_common.c
> +++ b/mm/slab_common.c
> @@ -239,7 +239,23 @@ static void s_stop(struct seq_file *m, void *p)
>
> static int s_show(struct seq_file *m, void *p)
> {
> - return slabinfo_show(m, p);
> + struct kmem_cache *s = list_entry(
There are two main versions of the ST-Ericsson hardware reference board,
each with subtle differences. These versions are described in current
platform data as 'mop500' for HREF v1.1 & v2.0 and 'hrefv60+' for latter
incarnations. However, the boards have much in common, so this patch
creates a .dts
In ux500 platform code we currently support a number of devices.
Two of these devices are fairly similar, but have key differences.
Early (pre-v60) HREFs and the more up-to-date versions (v60+), and
they both need to be supported by Device Tree. Here we apply a DT
source file for the earlier versio
Here we ensure the SFH7741 Proximity Sensor is registered through
gpio-keys when booting with Device Tree enabled.
Acked-by: Linus Walleij
Signed-off-by: Lee Jones
---
arch/arm/boot/dts/href.dtsi | 11 +++
arch/arm/boot/dts/hrefprev60.dts |6 ++
arch/arm/boot/dts/hrefv6
Snowball's external SD/MMC slot is only capable of 4 bit data
transfer, not 8 bits as previously thought. This is a simple
fixup moving to the correct settings.
Acked-by: Linus Walleij
Signed-off-by: Lee Jones
---
arch/arm/boot/dts/snowball.dts |2 +-
1 file changed, 1 insertion(+), 1 delet
In the DB8500 Reference Manual SDI devices are described as being
part of peripheral blocks. This is more in line with how these devices
are actually represented in hardware, so here we detail which
peripheral block each of the SDI devices belong in the node name.
Requested-by: Linus Walleij
Acke
Contained in this patch are some serious clean-ups for HREF related
Device Tree code. We make clear definition between pre-v60 and post-
v60 HREFs with the creation of their own DTS files. We also start to
take out most of the device registration calls which were duplicated
to aid with step-by-step
On Thu 27-09-12 13:45:14, Alexander Holler wrote:
> Am 25.09.2012 13:02, schrieb Dan Carpenter:
> >Did any of the old kernels work? Have you ruled out bad hardware?
>
> Older kernels worked and I could make full backups without any
> problems. I'm using that hardware since several years, and neve
Most devices have now been successfully DT:ed and each supported
platform has its own Device Tree source file. Hence the majority
of the platform specific device registration calls can now be
successfully removed.
Acked-by: Linus Walleij
Signed-off-by: Lee Jones
---
arch/arm/mach-ux500/board-mo
Here we add the Device Tree nodes which are required to successfully
probe the MMCI driver which will enable the four cards available on
ST-Ericsson's HREF hardware development platform.
Acked-by: Linus Walleij
Signed-off-by: Lee Jones
---
arch/arm/boot/dts/hrefv60plus.dts | 44 +
On Thu 27-09-12 07:33:00, Tejun Heo wrote:
> Hello, Michal.
>
> On Thu, Sep 27, 2012 at 02:08:06PM +0200, Michal Hocko wrote:
> > Yes, because we have many users (basically almost all) who care only
> > about the user memory because that's what occupies the vast majority of
> > the memory. They us
> Well, sure inside our tool before doing checkpoint we stop all
> tasks which are part of dumpee process tree. This unfortunatly
> doesn't apply to these ioctl calls. Peter, any idea how to deal
> with that?
I suspect you can't deal with that. Which isn't to say you can't still
build something us
On 11.9.2012 02:46, Fengguang Wu wrote:
> On Sat, Sep 08, 2012 at 12:47:59PM -0700, Andi Kleen wrote:
>> From: Andi Kleen
>>
>> For large kernel configurations (like a distribution kernel)
>> targz-pkg takes a quite long time to just do the compression.
>> I clocked it at 15+mins for a SUSE kernel
On 09/27/2012 07:48 AM, Cyrill Gorcunov wrote:
On Thu, Sep 27, 2012 at 07:43:44AM -0700, H. Peter Anvin wrote:
If you can't guarantee that ALL those processes are stopped and
checkpointed/restarted, you have a huge problem.
Well, sure inside our tool before doing checkpoint we stop all
tasks w
On Thu, 27 Sep 2012, Glauber Costa wrote:
> The functions oo_order() and oo_objects() are used by the slub to
> determine respectively the order of a candidate allocation, and the
> number of objects made available from it. I would like a stable visible
> location outside slub.c so it can be acess
On 09/27/2012 06:49 PM, Tejun Heo wrote:
> Hello, Mel.
>
> On Thu, Sep 27, 2012 at 03:28:22PM +0100, Mel Gorman wrote:
>>> In addition, how is userland supposed to know which
>>> workload is shared kmem heavy or not?
>>
>> By using a bit of common sense.
>>
>> An application may not be able to fi
On Thu, 20 Sep 2012, Mark Brown wrote:
> On Thu, Sep 20, 2012 at 02:09:09PM +0200, Lee Jones wrote:
> > The following changes since commit 5698bd757d55b1bb87edd1a9744ab09c142abfc2:
> >
> > Linux 3.6-rc6 (2012-09-16 14:58:51 -0700)
> >
> > are available in the git repository at:
> >
> > git:
On Thu, 27 Sep 2012, Glauber Costa wrote:
> By making sure that information conditionally lives inside a
> globally-visible CONFIG_DEBUG_SLAB switch, we can move the header
> printing to a common location.
Acked-by: Christoph Lameter
--
To unsubscribe from this list: send the line "unsubscribe
Hi,
On Thu, Sep 27, 2012 at 7:54 PM, Rob Herring wrote:
> On 09/25/2012 05:06 AM, ABRAHAM, KISHON VIJAY wrote:
>> Hi,
>>
>> On Mon, Sep 24, 2012 at 6:45 PM, Rob Herring wrote:
>>> On 09/06/2012 09:57 AM, Kishon Vijay Abraham I wrote:
All phy related programming like enabling/disabling the c
On Thu, 27 Sep 2012, Glauber Costa wrote:
> This patch moves all the common machinery to slabinfo processing
> to slab_common.c. We can do better by noticing that the output is
> heavily common, and having the allocators to just provide finished
> information about this. But after this first step,
Hello, Mel.
On Thu, Sep 27, 2012 at 03:43:07PM +0100, Mel Gorman wrote:
> > I'm not too convinced. First of all, the overhead added by kmemcg
> > isn't big.
>
> Really?
>
> If kmemcg was globally accounted then every __GFP_KMEMCG allocation in
> the page allocator potentially ends up down in
>
On Thu, 27 Sep 2012, Glauber Costa wrote:
> This patch moves on with the slab caches commonization, by moving
> the slabinfo processing to common code in slab_common.c. It only touches
> slub and slab, since slob doesn't create that file, which is protected
> by a Kconfig switch.
Thanks. That was
On Thu, Sep 27, 2012 at 9:23 AM, Andres Freund wrote:
> On Thursday, September 27, 2012 03:14:31 PM Alex Deucher wrote:
>> On Thu, Sep 27, 2012 at 2:46 AM, Andres Freund wrote:
>> > On Wednesday, September 26, 2012 03:42:40 PM Deucher, Alexander wrote:
>> >> > -Original Message-
>> >> > F
On Tue, Aug 07, 2012 at 03:41:56PM +0200, Joerg Roedel wrote:
> starting with Linux 3.6-rc1 I experience this BUG on one of my test
> machines. Please let me know if you need any additional information.
>
> [ 20.271810] [ cut here ]
> [ 20.276869] kernel BUG at /data/le
Hello, Mel.
On Thu, Sep 27, 2012 at 03:28:22PM +0100, Mel Gorman wrote:
> > In addition, how is userland supposed to know which
> > workload is shared kmem heavy or not?
>
> By using a bit of common sense.
>
> An application may not be able to figure this out but the administrator
> is going to
On Thu, Sep 27, 2012 at 07:43:44AM -0700, H. Peter Anvin wrote:
> >>If you can't guarantee that ALL those processes are stopped and
> >>checkpointed/restarted, you have a huge problem.
> >
> >Well, sure inside our tool before doing checkpoint we stop all
> >tasks which are part of dumpee process tr
[ 287.677274] [ cut here ]
[ 287.678042] WARNING: at block/genhd.c:1570 disk_clear_events+0xbf/0xd0()
[ 287.678042] Hardware name: CLE266-8235
[ 287.678042] Modules linked in: fuse ppdev evdev pcmcia snd_via82xx gameport
snd_ac97_codec ac97_bus snd_pcm ath5k snd_timer u
> Moreover, if your thinking is that we do not need a static inline
> function replicated at every caller, maybe we should introduce a
> lib/hashtable.c that implements those 2 functions.
That was my thought...
Given their nature, I'd guess they aren't critical path.
Probably not worth adding an e
On Wed, 2012-09-26 at 08:55 -0500, k...@linux.vnet.ibm.com wrote:
> On Mon, Sep 24, 2012 at 10:48:21AM -0500, k...@linux.vnet.ibm.com wrote:
> > On Mon, Sep 24, 2012 at 09:10:41AM -0500, k...@linux.vnet.ibm.com wrote:
> > > On Mon, Sep 24, 2012 at 12:26:05PM +1000, James Morris wrote:
> > > > On We
On 09/27/2012 07:21 AM, Cyrill Gorcunov wrote:
On Thu, Sep 27, 2012 at 07:17:49AM -0700, H. Peter Anvin wrote:
While we easily can fetch termios settings and such, there are few bits which
are missed to expord. So this patch provides them to user-space.
What bothers me (and the same applies t
On Thu, Sep 27, 2012 at 07:33:00AM -0700, Tejun Heo wrote:
> Hello, Michal.
>
> On Thu, Sep 27, 2012 at 02:08:06PM +0200, Michal Hocko wrote:
> > Yes, because we have many users (basically almost all) who care only
> > about the user memory because that's what occupies the vast majority of
> > the
On Thursday 27 September 2012, Vinod Koul wrote:
> > where the first one is called by the other two, depending on the bus type.
> > This could be done either splitting the driver into multiple files so you
> > can
> > have the platform and pci parts in separate driver modules depending on the
> >
This patch moves all the common machinery to slabinfo processing
to slab_common.c. We can do better by noticing that the output is
heavily common, and having the allocators to just provide finished
information about this. But after this first step, this can be done
easier.
Signed-off-by: Glauber C
The header format is highly similar between slab and slub. The main
difference lays in the fact that slab may optionally have statistics
added here in case of CONFIG_SLAB_DEBUG, while the slub will stick them
somewhere else.
By making sure that information conditionally lives inside a
globally-vis
The functions oo_order() and oo_objects() are used by the slub to
determine respectively the order of a candidate allocation, and the
number of objects made available from it. I would like a stable visible
location outside slub.c so it can be acessed from slab_common.c.
I considered also just maki
Hi,
This patch moves on with the slab caches commonization, by moving
the slabinfo processing to common code in slab_common.c. It only touches
slub and slab, since slob doesn't create that file, which is protected
by a Kconfig switch.
Enjoy,
Glauber Costa (4):
move slabinfo processing to slab_
With all the infrastructure in place, we can now have slabinfo_show
done from slab_common.c. A cache-specific function is called to grab
information about the cache itself, since that is still heavily
dependent on the implementation. But with the values produced by it, all
the printing and handling
Remove unnecessary semicolon
And:
drivers/media/dvb-frontends/stv0900_core.c: remove unnecessary whitespace
before a
quoted newline
Found by http://coccinelle.lip6.fr/
Signed-off-by: Peter Senna Tschudin
---
drivers/media/dvb-core/dvb_frontend.c | 2 +-
drivers/media/dvb-frontends/a8
On Thursday 27 September 2012, Mark Brown wrote:
> On Thu, Sep 27, 2012 at 12:55:35AM -0300, Fabio Estevam wrote:
> > From: Fabio Estevam
> >
> > On a mx53qsb dt-kernel the da9052-core driver fails to probe:
> >
> > da9052 1-0048: DA9052 ADC IRQ failed ret=-22
> >
> > In request_threaded_irq()
On Thu, 2012-09-27 at 17:00 +0300, Andy Shevchenko wrote:
> On Thu, Sep 27, 2012 at 1:06 PM, Vinod Koul
> wrote:
> > On Tue, 2012-09-25 at 14:39 +0300, Andy Shevchenko wrote:
> >> Not all of the controllers support the 64 bit data width. Make it
> >> configurable
> >> via platform data. The driv
Hello, Michal.
On Thu, Sep 27, 2012 at 02:08:06PM +0200, Michal Hocko wrote:
> Yes, because we have many users (basically almost all) who care only
> about the user memory because that's what occupies the vast majority of
> the memory. They usually want to isolate workload which would disrupt
> th
On 09/27/2012 02:47 PM, Lai Jiangshan wrote:
Currently memory_hotplug only manages the node_states[N_HIGH_MEMORY],
it forgets to manage node_states[N_NORMAL_MEMORY]. it causes
node_states[N_NORMAL_MEMORY] becomes stale.
We add check_nodemasks_changes_online() and check_nodemasks_changes_offline(
Replace 'while' with 'for' as suggested by Tejun Heo
Signed-off-by: Maxim Levitsky
---
lib/scatterlist.c |7 ++-
1 file changed, 2 insertions(+), 5 deletions(-)
diff --git a/lib/scatterlist.c b/lib/scatterlist.c
index 5cd9cdc..3675452b 100644
--- a/lib/scatterlist.c
+++ b/lib/scatterlis
On Thu, 2012-09-27 at 07:41 +, Arnd Bergmann wrote:
> On Thursday 27 September 2012, viresh kumar wrote:
> > I believe there is no common initialization part here, because PCI device
> > in any
> > case would be calling probe of platform device. :)
>
> Looking at the driver more closely now.
On Wed, Sep 26, 2012 at 04:08:07PM -0700, Tejun Heo wrote:
> Hello, Glauber.
>
> On Thu, Sep 27, 2012 at 02:54:11AM +0400, Glauber Costa wrote:
> > I don't. Much has been said in the past about the problem of sharing. A
> > lot of the kernel objects are shared by nature, this is pretty much
> > un
On 09/25/2012 05:06 AM, ABRAHAM, KISHON VIJAY wrote:
> Hi,
>
> On Mon, Sep 24, 2012 at 6:45 PM, Rob Herring wrote:
>> On 09/06/2012 09:57 AM, Kishon Vijay Abraham I wrote:
>>> All phy related programming like enabling/disabling the clocks, powering
>>> on/off the phy is taken care of by this driv
On Thu, Sep 27, 2012 at 07:34:07PM +0530, Kishon Vijay Abraham I wrote:
> +static int omap5_usb_phy_power(struct omap_usb *phy, bool on)
> +{
> + u32 val;
> + unsigned long rate;
> + struct clk *sys_clk;
> +
> + sys_clk = clk_get(NULL, "sys_clkin");
> + if (IS_ERR(sys_clk)) {
>
On Thursday 27 September 2012, viresh kumar wrote:
> I believe there is no common initialization part here, because PCI device in
> any
> case would be calling probe of platform device. :)
Looking at the driver more closely now. Right now, it only supports platform
devices, and the dw_probe func
On Thu, Sep 27, 2012 at 07:17:49AM -0700, H. Peter Anvin wrote:
> >While we easily can fetch termios settings and such, there are few bits which
> >are missed to expord. So this patch provides them to user-space.
> >
>
> What bothers me (and the same applies to termios) is that you have
> NO idea
On 09/27/2012 07:14 AM, Cyrill Gorcunov wrote:
On Thu, Sep 27, 2012 at 03:14:47PM +0100, Alan Cox wrote:
Alan, Greg, what's opinion? This flags fetching is the same as say fetching
of termios settings, once fetched they can be changed immediately, and it's
up to caller what to do with termios se
On Thu, Sep 27, 2012 at 10:03 PM, Russell King - ARM Linux
wrote:
> On Thu, Sep 27, 2012 at 02:58:09PM +0100, Russell King - ARM Linux wrote:
>> On Thu, Sep 27, 2012 at 07:47:46AM +0800, Ming Lei wrote:
>> > On Thu, Sep 27, 2012 at 4:23 AM, Russell King - ARM Linux
>> > wrote:
>> > > To be honest
On Thu, Sep 27, 2012 at 03:14:47PM +0100, Alan Cox wrote:
> > Alan, Greg, what's opinion? This flags fetching is the same as say fetching
> > of termios settings, once fetched they can be changed immediately, and it's
> > up to caller what to do with termios settings. No?
>
> I think you need to e
Hi Joerg,
On Thu, 2012-09-27 at 12:20 +0200, Joerg Roedel wrote:
> Hi Shuah,
>
> the patch looks better then the older versions. It comes closer to a
> merge, but I see one issue here:
>
> On Tue, Sep 25, 2012 at 07:05:17PM -0600, Shuah Khan wrote:
> > debug_dma_mapping_error(struct device *dev,
> Alan, Greg, what's opinion? This flags fetching is the same as say fetching
> of termios settings, once fetched they can be changed immediately, and it's
> up to caller what to do with termios settings. No?
I think you need to explain what you expect to be doing with it, and why
it is safe in th
On Thu, Sep 27, 2012 at 12:55:35AM -0300, Fabio Estevam wrote:
> From: Fabio Estevam
>
> On a mx53qsb dt-kernel the da9052-core driver fails to probe:
>
> da9052 1-0048: DA9052 ADC IRQ failed ret=-22
>
> In request_threaded_irq() the first parameter is missing the da9052->irq_base.
>
> Fix it
> as far as I know, nested locks are fine provided that you always take them in
> the same order and release them in the opposite order (lock A, lock B,
> unlock B, unlock A). So my conclusion is that nested spinlocks require
> potential regmap users of sta2x11 registers to take the sta2x11-mfd spi
On Wed, 26 Sep 2012, David Rientjes wrote:
> On Wed, 26 Sep 2012, Christoph Lameter wrote:
>
> > > Nack, this is already handled by CREATE_MASK in the mm/slab.c allocator;
> >
> > CREATE_MASK defines legal flags that can be specified. Other flags cause
> > and error. This is about flags that are i
On Mon, Sep 24, 2012 at 06:14:41PM +0400, Cyrill Gorcunov wrote:
>
> As to Alan's point on "what's the use of this if it can instantly change
> after you read the value" I guess it's the same as what we have when we
> simply set the value. Imagine we have two tasks fork'ed, first task do
> lock th
Added a driver for usb3 phy that handles the interaction between usb phy
device and dwc3 controller. Currently writing to control module register
is taken care in this driver which will be removed once the control
module driver is in place.
Changes from v1:
* Added missing clk_put()
* Remove the p
301 - 400 of 658 matches
Mail list logo
