[PATCH] kernel/events: using uninitialized variable: slots.flexible for arm cross-compiling

[Chen Gang]

for arm cross-compiling, in function __reserve_bp_slot:

  slots.flexible may be used without initializing.

slots.flexible is not initialized when define it.
it is as a parameter passed to fetch_bp_busy_slots.
in function fetch_bp_busy_slots:
  if bp->cpu < 0
slots->flexible will be used for comparing, firstly.
that will cause issue.


building:
  make EXTRA_CFLAGS=-W ARCH=arm
  ...
  linux/kernel/events/hw_breakpoint.c:300:
warning: missing initializer
  linux/kernel/events/hw_breakpoint.c:300:
warning: (near initialization for 'slots.flexible')
  ...

Signed-off-by: Chen Gang 
---
 kernel/events/hw_breakpoint.c |2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/kernel/events/hw_breakpoint.c b/kernel/events/hw_breakpoint.c
index fe8a916..ef69215 100644
--- a/kernel/events/hw_breakpoint.c
+++ b/kernel/events/hw_breakpoint.c
@@ -297,7 +297,7 @@ __weak void arch_unregister_hw_breakpoint(struct perf_event 
*bp)
  */
 static int __reserve_bp_slot(struct perf_event *bp)
 {
-   struct bp_busy_slots slots = {0};
+   struct bp_busy_slots slots = {0, 0};
enum bp_type_idx type;
int weight;
 
-- 
1.7.7.6
--
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/

Re: [PATCH v7 01/10] ARM: davinci: move private EDMA API to arm/common

[Felipe Balbi]

On Tue, Feb 05, 2013 at 10:26:30PM +, Arnd Bergmann wrote:
> On Tuesday 05 February 2013, Tony Lindgren wrote:
> > * Felipe Balbi  [130204 07:46]:
> > > 
> > > Current DMA abstraction is quite poor, for example there's no way to
> > > compile support for multiple DMA engines. Code also makes certain, IMO
> > > unnecessary, assumptions about the underlying DMA engine (abstraction is
> > > poor, as said above but it we could follow MUSB's programming guide when
> > > it comes to programming DMA transfers).
> > > 
> > > Considering all of the above, it's far better to use DMA engine and get
> > > rid of all the mess.
> > 
> > How about just disable MUSB DMA support if ARCH_MULTIPLATFORM for now?
> > That way MUSB can be fixed up first to support ARCH_MULTIPLATFORM
> > using PIO while sorting out the DMA related issues.
> 
> Sounds ok to me. Someone still needs to do the work to make the non-DMA
> variants of MUSB coexist in one kernel, but as we discussed erlier, that
> should be much simpler.

Yeah, I'm cooking some patches to at least make it buildable. Dropping
unnecessary dependencies and marking da8xx and davinci as depending on
BROKEN seems to be the easiest way; those two glues hasn't seen a real
patch since 2010 or so.

-- 
balbi


signature.asc
Description: Digital signature

Re: linux-next: build failure after merge of the final tree

[Stephen Rothwell]

Hi all,

On Wed, 6 Feb 2013 18:30:40 +1100 Stephen Rothwell  
wrote:
>
> After merging the final tree, today's linux-next build (sparc defconfig)
> failed like this:
> 
> arch/sparc/kernel/kgdb_32.c: In function 'sleeping_thread_to_gdb_regs':
> arch/sparc/kernel/kgdb_32.c:46:9: error: implicit declaration of function 
> 'task_thread_info' [-Werror=implicit-function-declaration]
> arch/sparc/kernel/kgdb_32.c:46:26: error: initialization makes pointer from 
> integer without a cast [-Werror]
> 
> I can only imagine that the implicit include of linux/sched.h got removed
> in one of our include file changes. :-(
> 
> I have added this patch for today:
> 
> From: Stephen Rothwell 
> Date: Wed, 6 Feb 2013 18:26:51 +1100
> Subject: [PATCH] sparc: explicitly include sched.h to get task_thread_info 
> declaration
> 
> Signed-off-by: Stephen Rothwell 
> ---
>  arch/sparc/kernel/kgdb_32.c | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/arch/sparc/kernel/kgdb_32.c b/arch/sparc/kernel/kgdb_32.c
> index 2e424a5..dcf2108 100644
> --- a/arch/sparc/kernel/kgdb_32.c
> +++ b/arch/sparc/kernel/kgdb_32.c
> @@ -5,6 +5,7 @@
>  
>  #include 
>  #include 
> +#include 
>  
>  #include 
>  #include 

This was probably caused by commit 16559ae48c76 ("kgdb: remove #include
 from kgdb.h") from the tty tree.

Removing includes from include files is always fraught with this sort of
danger :-(
-- 
Cheers,
Stephen Rothwells...@canb.auug.org.au


pgppuFlY1VtJ7.pgp
Description: PGP signature

linux-next: build failure after merge of the final tree

[Stephen Rothwell]

Hi all,

After merging the final tree, today's linux-next build (sparc defconfig)
failed like this:

arch/sparc/kernel/kgdb_32.c: In function 'sleeping_thread_to_gdb_regs':
arch/sparc/kernel/kgdb_32.c:46:9: error: implicit declaration of function 
'task_thread_info' [-Werror=implicit-function-declaration]
arch/sparc/kernel/kgdb_32.c:46:26: error: initialization makes pointer from 
integer without a cast [-Werror]

I can only imagine that the implicit include of linux/sched.h got removed
in one of our include file changes. :-(

I have added this patch for today:

From: Stephen Rothwell 
Date: Wed, 6 Feb 2013 18:26:51 +1100
Subject: [PATCH] sparc: explicitly include sched.h to get task_thread_info 
declaration

Signed-off-by: Stephen Rothwell 
---
 arch/sparc/kernel/kgdb_32.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/sparc/kernel/kgdb_32.c b/arch/sparc/kernel/kgdb_32.c
index 2e424a5..dcf2108 100644
--- a/arch/sparc/kernel/kgdb_32.c
+++ b/arch/sparc/kernel/kgdb_32.c
@@ -5,6 +5,7 @@
 
 #include 
 #include 
+#include 
 
 #include 
 #include 
-- 
1.8.1

-- 
Cheers,
Stephen Rothwells...@canb.auug.org.au


pgpResImbzfna.pgp
Description: PGP signature

RE: [PATCH] kdump, oldmem: support mmap on /dev/oldmem

[Hatayama, Daisuke]

From: Vivek Goyal 
Subject: Re: [PATCH] kdump, oldmem: support mmap on /dev/oldmem
Date: Tue, 5 Feb 2013 10:12:56 -0500

> On Mon, Feb 04, 2013 at 04:59:35AM +, Hatayama, Daisuke wrote:

> [..]
>> For design decision, I didn't support mmap() on /proc/vmcore because
>> it abstracts old memory as ELF format, so there's range consequtive on
>> /proc/vmcore but not consequtive on the actual old memory. For
>> example, consider ELF headers on the 2nd kernel and the note objects,
>> memory chunks corresponding to PT_LOAD entries on the first kernel.
>> They are not consequtive on the old memory. So reampping them so
>> /proc/vmcore appears consequtive using existing remap_pfn_range() needs
>> some complicated work.
> 
> Can't we call remap_pfn_range() multiple times. Once for each sequential
> range of memory. /proc/vmcore already has list of contiguous memory areas.
> So we can parse user passed file offset and size and map into respective
> physical chunks and call rempa_pfn_range() on all these chunks.
> 
> I think supporting mmap() both on /dev/oldmem as well as /proc/vmcore will
> be nice.
> 
> Agreed that supporting mmap() on /proc/vmcore is more work as compared to
> /dev/oldmem but should be doable.
> 

The complication to support mmap() on /proc/vmcore lies in kdump
side. Objects exported from /proc/vmcore needs to be page-size aligned
on /proc/vmcore. This comes from the restriction of mmap() that
requires user-space address and physical address to be page-size
aligned.

As I said in the description, objects implicitly referened by
/proc/vmcore are

  - ELF headers,
  - NOTE objects (NT_PRSTATUS entries x cpus, VMCOREINFO), and
  - memory chunks x (the number of PT_LOAD entries).

Note objects are scattered on old memory. They are exported as a
single NOTE entry from program headers, so they need to be gathered at
the same location in the 2nd kernel starting from the page-size
aligned address.

VMCOREINFO is about 1.5KB on 2.6.32 kernel. One NT_PRSTATUS is 355
bytes. Recent limit of NR_CPUS is 5120 on x86_64. So less than about 2
MB is enough even on the worst case.

Note that the format of /proc/vmcore need to change since offset of
each object need to be page-size aligned.

Thanks.
HATAYAMA, Daisuke

--
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/

Re: [PATCH 12/15] USB: gadget/freescale: disable non-multiplatform drivers

[Felipe Balbi]

On Tue, Feb 05, 2013 at 05:55:11PM -0800, Greg Kroah-Hartman wrote:
> On Tue, Feb 05, 2013 at 10:54:00PM +, Arnd Bergmann wrote:
> > On Tuesday 05 February 2013, Felipe Balbi wrote:
> > > [linus/master] Merge branch 'fix-max-write' of 
> > > git://git.kernel.org/pub/scm/linux/kernel/git/teigland/linux-dlm
> > > 
> > > It's building find for me:
> > > 
> > > $ crossmake drivers/usb/gadget/fsl_udc_core.o \
> > > drivers/usb/gadget/fsl_mxc_udc.o > /dev/null
> > > 
> > > (crossmake is an alias to make ARCH=arm)
> > > 
> > > Arnd, are you maybe missing a merge of v3.8-rc6 ?
> > >
> > > I can see that imx_udc.c is broken still, but there are no maintainers
> > > for that driver. I'm adding Sascha to Cc list, maybe he knows someone
> > > who can help, but if this driver isn't fixed in 2 merge windows, I will
> > > schedule for removal from tree and someone else will have to
> > > re-introduce it later without all the bogus includes.
> > 
> > Ah, I see what happened now: I submitted a patch that lumped together
> > two patches, disabling both fsl_mxc_udc and imx_udc. You already had
> > a fix for the first one, so I dropped my patch, but now I see the
> > build error for the second one that my patch was avoiding.
> > 
> > The last patch to imx_udc that seems to have seen more than just
> > build testing was probably "USB: gadget: imx_udc: don't queue more
> > data when zlp is to be sent", while fsl_mxc_udc looks actively
> > maintained. It's not completely clear to me whether these
> > are actually two drivers for the same hardware, of whether
> > imx_udc is the i.mx1 variant and fsl_mxc_udc is the i.mx2 variant.
> > 
> > What I can say is that no platform in the kernel currently defines
> > an "imx_udc" platform_device, so it is certainly unused, and has
> > been since at least e08300043e in 2010.
> > 
> > I would suggest that we mark the imx_udc driver as 'depends on
> > BROKEN' right away, since no in-tree user needs it, and any
> > out of tree user is already broken in 3.8. I also wouldn't
> > mind removing the driver unless the imx maintainers have
> > a plan for it.
> 
> Sure, someone just send me a patch for that and I'll be glad to mark it
> BROKEN.

coming in a minute

-- 
balbi


signature.asc
Description: Digital signature

Re: 3.8-rc1 patch_cirrus 4.0 regression...

[Takashi Iwai]

At Wed, 6 Feb 2013 08:47:41 +0800,
Daniel J Blueman wrote:
> 
> On 6 February 2013 01:40, Takashi Iwai  wrote:
> > At Tue, 05 Feb 2013 17:34:15 +0100,
> > Takashi Iwai wrote:
> >>
> >> At Wed, 6 Feb 2013 00:29:54 +0800,
> >> Daniel J Blueman wrote:
> >> >
> >> > On 6 February 2013 00:16, Takashi Iwai  wrote:
> >> > > At Wed, 6 Feb 2013 00:10:30 +0800,
> >> > > Daniel J Blueman wrote:
> >> > >>
> >> > >> Hi Takashi,
> >> > >>
> >> > >> The v3.8-rc kernels have regressed from v3.7 with the quad-speaker
> >> > >> arrangement on my Macbook Pro 10,1 - only the higher-frequency
> >> > >> speakers work despite the front and rear channels being exposed in the
> >> > >> mixer.
> >> > >
> >> > > Interesting.  So you have a machine with 4.0 built-in speaker instead
> >> > > of 2.1?  Then we need to add a device-specific flag for it.  Currently
> >> > > the driver assumes 2.1 system blindly because majority of machines
> >> > > have that.
> >> > >
> >> > > FWIW, the codec parser code has been totally rewritten for 3.9, so any
> >> > > patch to 3.8 won't be applied to 3.9 (and vice versa)...
> >> > >
> >> > > Could you give alsa-info.sh output on 3.8 kernel?  Then I'll try to
> >> > > cook it for 3.9 (and maybe backport to 3.8).
> >> >
> >> > Here's the output from the current alsa-info.sh on 3.8-rc6 with the
> >> > two cited patches reverted [1]; let me know if you'd like 3.8-rc6
> >> > pure.
> >>
> >> Thanks.
> >>
> >> > The sound is pretty impressive for a laptop when the low-frequecy
> >> > speakers are enabled.
> >>
> >> Which program are you using for testing the surrounds?
> >> I'm interested in it because the commit you reverted is basically
> >> providing only an additional information for the channel map, and it
> >> doesn't change anything else.  It implies that some applications are
> >> really referring to the chmap info.
> >
> > Or, it might be that the mixer value is simply not set correct.
> >
> > To be sure, could you try again 3.8-rc6 without reversing patches,
> > adjust "Speaker" and "Bass Speaker" volumes properly, and retest?
> > If it still doesn't work, please take alsa-info.sh snapshot at this
> > state for comparing with the previous result.
> 
> My apologies! We do now have "Bass Speaker" which affects both bass
> speakers. It was always being restored to level 0 and works when set
> up.

OK, good to know.

> There is a "Subwoofer" slider in addition to "Balance" and "Fade" in
> the GNOME mixer UI which is greyed out; presumably this is intended as
> the same mixer control?

I have no idea about GNOME stuff... David, do you know of this?


Takashi
--
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/

linux-next: build failure after merge of the akpm tree

[Stephen Rothwell]

Hi Andrew,

After merging the akpm tree, today's linux-next build (powerpc
ppc64_defconfig) failed like this:

arch/powerpc/mm/mem.c: In function 'arch_add_memory':
arch/powerpc/mm/mem.c:134:2: error: implicit declaration of function 
'__add_pages' [-Werror=implicit-function-declaration]
arch/powerpc/mm/mem.c: In function 'arch_remove_memory':
arch/powerpc/mm/mem.c:145:2: error: implicit declaration of function 
'__remove_pages' [-Werror=implicit-function-declaration]
arch/powerpc/platforms/pseries/hotplug-memory.c: In function 
'pseries_remove_memblock':
arch/powerpc/platforms/pseries/hotplug-memory.c:104:3: error: implicit 
declaration of function '__remove_pages' [-Werror=implicit-function-declaration]
mm/bootmem.c: In function 'free_all_bootmem_node':
mm/bootmem.c:269:2: error: implicit declaration of function 
'register_page_bootmem_info_node' [-Werror=implicit-function-declaration]

Presumably caused by commit "mm: break circular include from
linux/mmzone.h".  That is a very optimistic patch :-)

I have reverted that commit for today.

-- 
Cheers,
Stephen Rothwells...@canb.auug.org.au


pgpjgQl0sARmI.pgp
Description: PGP signature

linux-next: manual merge of the akpm tree with the nfsd tree

[Stephen Rothwell]

Hi Andrew,

Today's linux-next merge of the akpm tree got a conflict in
fs/nfsd/nfscache.c between commit 2c6b691c05bf ("nfsd: when updating an
entry with RC_NOCACHE, just free it") from the nfsd tree and commit
"hlist: drop the node parameter from iterators" from the akpm tree.

I fixed it up (see below) and can carry the fix as necessary (no action
is required).

-- 
Cheers,
Stephen Rothwells...@canb.auug.org.au

diff --cc fs/nfsd/nfscache.c
index d16a5d6,30c27eb..000
--- a/fs/nfsd/nfscache.c
+++ b/fs/nfsd/nfscache.c
@@@ -254,9 -165,11 +253,9 @@@ nfsd_cache_search(struct svc_rqst *rqst
proc = rqstp->rq_proc;
  
rh = _hash[request_hash(xid)];
-   hlist_for_each_entry(rp, hn, rh, c_hash) {
+   hlist_for_each_entry(rp, rh, c_hash) {
 -  if (rp->c_state != RC_UNUSED &&
 -  xid == rp->c_xid && proc == rp->c_proc &&
 +  if (xid == rp->c_xid && proc == rp->c_proc &&
proto == rp->c_prot && vers == rp->c_vers &&
 -  !nfsd_cache_entry_expired(rp) &&
rpc_cmp_addr(svc_addr(rqstp), (struct sockaddr 
*)>c_addr) &&
rpc_get_port(svc_addr(rqstp)) == rpc_get_port((struct 
sockaddr *)>c_addr))
return rp;


pgph3oSZcvytf.pgp
Description: PGP signature

[LSF/MM TOPIC] f2fs: Dynamic Control of GC Thread at User Level and Stabilizing sudden eject behavior for SD Cards.

[Namjae Jeon]

Hello.

I am considering the following subjects on f2fs. I'm not sure if it is
proper TOPIC.
Let me know opinions :)

1. Dynamic Control of GC Thread at User Level.
To cope with rapid increase in number of smart phone users and
increasing demands for different media application with Quality Of
Service (QoS) interaction on such devices,
it is becoming imperative to provide the necessary support at the
underlying filesystem layer also.
Currently, when we consider the Garbage collection behavior and its
execution period overlapping with the normal I/O - while garbage
collection is in progress it results in blocking the normal I/O Path,
i.e.,
it provides a sense of unresponsiveness to the user and could also
potentially feel like a hung state in the worst cases, resulting in
hard-reboot from the user.
So, in order to improve upon this behavior. We can introduce the
“dynamic control” concept for the Garbage collection.
It will allow the user to check the status of garbage at any time and
in-turn will also allow user to run the GC from the user interface.
It can be similar to the concept of checking the fragmentation level
of filesystem and running defragmentation and showing status
dynamically.
For a specific scenario we can have an example like this: When
Application is recording Video data on some storage device or showing
screen by decoding (TV) or may be the device is switching to idle
mode.
In such cases Application will have the intelligence that there is no
access to F2Fs partition at such intervals, and which partitions are
not used on such times. In such intervals if the Application user can
control the GC thread,
it will allows the F2FS partition be ready in advance and normal I/O
can run properly without any intervention from the GC thread.

2. Stabilizing sudden eject behavior for SD Cards
As a continuation to the usage of smart phone and related devices, the
trend is that the usage of SD cards on mobile devices in on increase.
It is a great challenge to have the content on SD cards intact as well
keep the system stable while using SD cards.
Currently, when F2FS formatted SD card is connected to the device and
I/O is in progress- there are several code paths in the F2FS
filesystem which tried to guarantee no failure for few routines.
But this results in abnormal situation, because initially F2FS design
did not take into account the sudden unplug behavior. As a result it
potentially left various paths which resulted in infinite looping even
in the case when the device is removed,
which in-turn actually results in hung state for the device as it is
not able to come out of the tight loop to handle other interrupts.
To combat such problem there is a need for redesign which allows both
guarantee for no failure in default routines and safe exit
routines/fallback path in case of unsafe device ejection.

Thanks.
--
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/

Re: Question on lockdep and MAX_LOCK_DEPTH

[Ben Greear]

On 02/05/2013 08:36 PM, Steven Rostedt wrote:

On Tue, 2013-02-05 at 19:30 -0800, Ben Greear wrote:


It's huge, so here's a link:

http://www.candelatech.com/~greearb/debug.tgz



The trace shows that __netif_receive_skb() is grabbing an
rcu_read_lock() but never releasing it. But I don't see any possible way
that can be true in the code.

Can you apply the following patch and run the trace again. I'd like to
see if the code is going in the path I expect it is.


I'll look at this in detail tomorrow.  I have a few patches in dev.c code, maybe
I merged something badly

Thanks,
Ben

--
Ben Greear 
Candela Technologies Inc  http://www.candelatech.com

--
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/

Re: Question on lockdep and MAX_LOCK_DEPTH

[Ben Greear]

On 02/05/2013 08:26 PM, Steven Rostedt wrote:

On Tue, Feb 05, 2013 at 05:10:37PM -0800, Ben Greear wrote:



===
[ INFO: suspicious RCU usage. ]
3.7.6+ #4 Tainted: G C O
---
/home/greearb/git/linux-3.7.dev.y/kernel/rcutree.c:360 Illegal idle entry in 
RCU read-side critical section.!

other info that might help us debug this:


RCU used illegally from idle CPU!
rcu_scheduler_active = 1, debug_locks = 1
RCU used illegally from extended quiescent state!
1 lock held by swapper/1/0:
  #0:  (rcu_read_lock){.+.+..}, at: [] rcu_read_lock+0x0/0x6f

stack backtrace:
Pid: 0, comm: swapper/1 Tainted: G C O 3.7.6+ #4
Call Trace:
[] lockdep_rcu_suspicious+0xfc/0x105
  [] rcu_eqs_enter_common+0xef/0x178
  [] rcu_irq_exit+0x7f/0xb0
  [] irq_exit+0xc0/0xcc
  [] do_IRQ+0x97/0xae
  [] common_interrupt+0x72/0x72
[] ? mwait_idle+0x77/0x9f
  [] ? mwait_idle+0x6e/0x9f
  [] cpu_idle+0x68/0xbc
  [] start_secondary+0x1fc/0x203


BTW, did the above error only happen when you added the dump of the
locks, or was it always there? Is this the bug you were trying to debug?


It's often there, at least..and was from the beginning, and I
am interested in debugging it.

Thanks,
Ben



--
Ben Greear 
Candela Technologies Inc  http://www.candelatech.com

--
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/

Re: [PATCH v5 3/3] ARM: mm: use static_vm for managing static mapped areas

[Nicolas Pitre]

On Wed, 6 Feb 2013, Joonsoo Kim wrote:

> On Wed, Feb 06, 2013 at 11:07:07AM +0900, Joonsoo Kim wrote:
> > Hello, Rob.
> > 
> > On Tue, Feb 05, 2013 at 01:12:51PM -0600, Rob Herring wrote:
> > > On 02/05/2013 12:13 PM, Nicolas Pitre wrote:
> > > > On Tue, 5 Feb 2013, Rob Herring wrote:
> > > > 
> > > >> On 02/04/2013 10:44 PM, Nicolas Pitre wrote:
> > > >>> On Tue, 5 Feb 2013, Joonsoo Kim wrote:
> > > >>>
> > >  A static mapped area is ARM-specific, so it is better not to use
> > >  generic vmalloc data structure, that is, vmlist and vmlist_lock
> > >  for managing static mapped area. And it causes some needless 
> > >  overhead and
> > >  reducing this overhead is better idea.
> > > 
> > >  Now, we have newly introduced static_vm infrastructure.
> > >  With it, we don't need to iterate all mapped areas. Instead, we just
> > >  iterate static mapped areas. It helps to reduce an overhead of 
> > >  finding
> > >  matched area. And architecture dependency on vmalloc layer is 
> > >  removed,
> > >  so it will help to maintainability for vmalloc layer.
> > > 
> > >  Signed-off-by: Joonsoo Kim 
> > > >>
> > > >> [snip]
> > > >>
> > >  @@ -859,17 +864,12 @@ static void __init pci_reserve_io(void)
> > >   {
> > >   struct vm_struct *vm;
> > >   unsigned long addr;
> > >  +struct static_vm *svm;
> > >   
> > >  -/* we're still single threaded hence no lock needed here */
> > >  -for (vm = vmlist; vm; vm = vm->next) {
> > >  -if (!(vm->flags & VM_ARM_STATIC_MAPPING))
> > >  -continue;
> > >  -addr = (unsigned long)vm->addr;
> > >  -addr &= ~(SZ_2M - 1);
> > >  -if (addr == PCI_IO_VIRT_BASE)
> > >  -return;
> > >  +svm = find_static_vm_vaddr((void *)PCI_IO_VIRT_BASE);
> > >  +if (svm)
> > >  +return;
> > > 
> > >  -}
> > >   
> > >   vm_reserve_area_early(PCI_IO_VIRT_BASE, SZ_2M, pci_reserve_io);
> > >   }
> > > >>>
> > > >>> The replacement code is not equivalent.  I can't recall why the 
> > > >>> original 
> > > >>> is as it is, but it doesn't look right to me.  The 2MB round down 
> > > >>> certainly looks suspicious.
> > > >>
> > > >> The PCI mapping is at a fixed, aligned 2MB mapping. If we find any
> > > >> virtual address within that region already mapped, it is an error.
> > > > Ah, OK.  This wasn't clear looking at the code.
> > > >> We probably should have had a WARN here.
> > > > 
> > > > Indeed.
> > > > 
> > 
> > Okay.
> > I should fix it to find any mapping within PCI reserved region.
> 
> Ah...
> Above comment is my mistake.
> 
> If there is a region already mapped within PCI reserved region and
> it is not found by find_static_vm_vaddr(), vm_area_add_early() hit BUG_ON().
> So, to leave find_static_vm_vaddr() is safe.

Yes.  In conclusion, your patch was fine.  You may remove the redundant 
parents and send the whole set to Russell.


Nicolas
--
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/

Re: [PATCH V2] clk: Add composite clock type

[Hiroshi Doyu]

Prashant Gaikwad  wrote @ Wed, 6 Feb 2013 03:55:00 +0100:

> >> No, clk_ops depends on the clocks you are using. There could be a clock
> >> with mux and gate while another one with mux and div.
> > You are right. What about the following? We don't have to have similar
> > copy of clk_composite_ops for each instances.
> 
> Clock framework takes decision depending on the ops availability and it 
> does not know if the clock is mux or gate.
> 
> For example,
> 
>  if (clk->ops->enable) {
>  ret = clk->ops->enable(clk->hw);
>  if (ret) {
>  __clk_disable(clk->parent);
>  return ret;
>  }
>  }
> 
> in above case if clk_composite does not have gate clock then as per your 
> suggestion if it returns error value then it will fail and it is wrong.

Ok, now I understand. Thank you for explanation.

We always need to allocate clk_composite_ops for each clk_composite,
right? If so what about having "struct clk_ops ops" in "struct
clk_composite"?

diff --git a/drivers/clk/clk-composite.c b/drivers/clk/clk-composite.c
index f30fb4b..5240e24 100644
--- a/drivers/clk/clk-composite.c
+++ b/drivers/clk/clk-composite.c
@@ -129,20 +129,13 @@ struct clk *clk_register_composite(struct device *dev, 
const char *name,
pr_err("%s: could not allocate composite clk\n", __func__);
return ERR_PTR(-ENOMEM);
}
+   clk_composite_ops = >ops;
 
init.name = name;
init.flags = flags | CLK_IS_BASIC;
init.parent_names = parent_names;
init.num_parents = num_parents;
 
-   /* allocate the clock ops */
-   clk_composite_ops = kzalloc(sizeof(*clk_composite_ops), GFP_KERNEL);
-   if (!clk_composite_ops) {
-   pr_err("%s: could not allocate clk ops\n", __func__);
-   kfree(composite);
-   return ERR_PTR(-ENOMEM);
-   }
-
if (mux_hw && mux_ops) {
if (!mux_ops->get_parent || !mux_ops->set_parent) {
clk = ERR_PTR(-EINVAL);
@@ -202,7 +195,6 @@ struct clk *clk_register_composite(struct device *dev, 
const char *name,
return clk;
 
 err:
-   kfree(clk_composite_ops);
kfree(composite);
return clk;
 }
diff --git a/include/linux/clk-provider.h b/include/linux/clk-provider.h
index f0ac818..bb5d36a 100644
--- a/include/linux/clk-provider.h
+++ b/include/linux/clk-provider.h
@@ -346,6 +346,8 @@ struct clk_composite {
const struct clk_ops*mux_ops;
const struct clk_ops*div_ops;
const struct clk_ops*gate_ops;
+
+   const struct clk_opsops;
 };
 
 struct clk *clk_register_composite(struct device *dev, const char *name,


> > diff --git a/drivers/clk/clk-composite.c b/drivers/clk/clk-composite.c
> > index f30fb4b..8f88805 100644
> > --- a/drivers/clk/clk-composite.c
> > +++ b/drivers/clk/clk-composite.c
> > @@ -27,6 +27,9 @@ static u8 clk_composite_get_parent(struct clk_hw *hw)
> >  const struct clk_ops *mux_ops = composite->mux_ops;
> >  struct clk_hw *mux_hw = composite->mux_hw;
> >   
> > +   if (!mux_hw->clk)
> > +  return -EINVAL;
> > +
> >  mux_hw->clk = hw->clk;
>
> It is wrong.

Will the above "mux_hw->clk = hw->clk" be removed from the original?
--
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/

[PATCH] smp: give WARN in case of in_interrupt() when calling smp_call_function_many/single

[Chuansheng Liu]

Currently, in function smp_call_function_many/single, it will give WARN just in 
case
of irqs_disabled(), but it is not enough.

In many other cases such as softirq handling/interrupt handling, the two APIs 
still
can not be called, just as the smp_call_function_many() comments said:
 * You must not call this function with disabled interrupts or from a
 * hardware interrupt handler or from a bottom half handler. Preemption
 * must be disabled when calling this function.

There is a real case for softirq DEADLOCK case:
CPUACPUB
spin_lock()
Any irq coming, call the irq handler
irq_exit()
spin_lock_irq()
<== Blocking here due to
CPUB hold it
  __do_softirq()
run_timer_softirq()
  timer_cb()
call smp_call_function_many()
  send IPI interrupt to CPUA
wait_csd()

Then both CPUA and CPUB will be DEADLOCK here.

So we should give WARN in case of in_interrupt(), not only irqd_disabled().

Signed-off-by: liu chuansheng 
---
 kernel/smp.c |8 +---
 1 files changed, 5 insertions(+), 3 deletions(-)

diff --git a/kernel/smp.c b/kernel/smp.c
index 69f38bd..a2f0b2c 100644
--- a/kernel/smp.c
+++ b/kernel/smp.c
@@ -12,6 +12,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include "smpboot.h"
 
@@ -323,7 +324,7 @@ int smp_call_function_single(int cpu, smp_call_func_t func, 
void *info,
 * send smp call function interrupt to this cpu and as such deadlocks
 * can't happen.
 */
-   WARN_ON_ONCE(cpu_online(this_cpu) && irqs_disabled()
+   WARN_ON_ONCE(cpu_online(this_cpu) && (irqs_disabled() || in_interrupt())
 && !oops_in_progress);
 
if (cpu == this_cpu) {
@@ -421,8 +422,9 @@ void __smp_call_function_single(int cpu, struct 
call_single_data *data,
 * send smp call function interrupt to this cpu and as such deadlocks
 * can't happen.
 */
-   WARN_ON_ONCE(cpu_online(smp_processor_id()) && wait && irqs_disabled()
-&& !oops_in_progress);
+   WARN_ON_ONCE(cpu_online(smp_processor_id()) && wait
+   && (irqs_disabled() || in_interrupt())
+   && !oops_in_progress);
 
if (cpu == this_cpu) {
local_irq_save(flags);
-- 
1.7.0.4



--
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/

RE: [PATCH V2 1/6] pinctrl: pinctrl-single: use arch_initcall and module_exit

[Vishwanathrao Badarkhe, Manish]

Hi Russell,

On Tue, Feb 05, 2013 at 16:57:31, Russell King - ARM Linux wrote:
> On Tue, Feb 05, 2013 at 06:36:34AM +, Vishwanathrao Badarkhe, Manish 
> wrote:
> > I made following changes, in order to update "dip->p" pointer with 
> > correct value:
> > 
> > -   if (!dpi->p) {
> > +   if (IS_ERR_OR_NULL(dpi->p)) {
> > dpi->p = devm_pinctrl_get(dev);
> > -   if (IS_ERR_OR_NULL(dpi->p)) {
> > -   int ret = PTR_ERR(dpi->p);
> > -
> > -   dev_dbg(dev, "no pinctrl handle\n");
> > -   /* Only return deferrals */
> > -   if (ret == -EPROBE_DEFER)
> > -   return ret;
> > -   return 0;
> > -   }
> > +   ret = PTR_ERR(dpi->p);
> > +   dev_dbg(dev, "no pinctrl handle\n");
> > +   /* Only return deferrals */
> > +   if (ret == -EPROBE_DEFER)
> > +   return ret;
> > +   return 0;
> > 
> > Is this intended change?
> 
> The above looks totally broken to me.
> 
> Oh, it's using IS_ERR_OR_NULL(), so it's bound to be broken.
> 

I went through discussion in community on usage of "IS_ERR_OR_NULL".
https://patchwork.kernel.org/patch/1953271/
Will take care not use this in future.

Thanks,
Manish
--
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/

Re: [PATCH] X.509: Support parse long form of length octets in Authority Key Identifier

[joeyli]

於 三，2013-02-06 於 13:08 +0800，Lee, Chun-Yi 提到：
> Per X.509 spec in 4.2.1.1 section, the structure of Authority Key
> Identifier Exception is:
^^ Extension

Sorry for my typo, I will send patch again.

Thanks
Joey Lee

> 
>AuthorityKeyIdentifier ::= SEQUENCE {
>   keyIdentifier [0] KeyIdentifier   OPTIONAL,
>   authorityCertIssuer   [1] GeneralNamesOPTIONAL,
>   authorityCertSerialNumber [2] CertificateSerialNumber OPTIONAL  }
> 
>KeyIdentifier ::= OCTET STRING
> 
> When a certificate also provides
> authorityCertIssuer and authorityCertSerialNumber then the length of
> AuthorityKeyIdentifier SEQUENCE is likely to long form format.
> e.g.
>The example certificate demos/tunala/A-server.pem in openssl source:
> 
> X509v3 Authority Key Identifier:
> keyid:49:FB:45:72:12:C4:CC:E1:45:A1:D3:08:9E:95:C4:2C:6D:55:3F:17
> DirName:/C=NZ/L=Wellington/O=Really Irresponsible Authorisation Authority 
> (RIAA)/OU=Cert-stamping/CN=Jackov al-Trades/emailAddress=none@fake.domain
> serial:00
> 
> Current parsing rule of OID_authorityKeyIdentifier only take care the
> short form format, it causes load certificate to modsign_keyring fail:
> 
> [   12.061147] X.509: Extension: 47
> [   12.075121] MODSIGN: Problem loading in-kernel X.509 certificate (-74)
> 
> So, this patch add the parsing rule for support long form format against
> Authority Key Identifier.
> 
> Cc: David Howells 
> Cc: Rusty Russell 
> Cc: Josh Boyer 
> Cc: Randy Dunlap 
> Cc: Herbert Xu 
> Cc: "David S. Miller" 
> Signed-off-by: Lee, Chun-Yi 
> ---
>  crypto/asymmetric_keys/x509_cert_parser.c |   56 
>  1 files changed, 48 insertions(+), 8 deletions(-)
> 
> diff --git a/crypto/asymmetric_keys/x509_cert_parser.c 
> b/crypto/asymmetric_keys/x509_cert_parser.c
> index 7fabc4c..7f6a152 100644
> --- a/crypto/asymmetric_keys/x509_cert_parser.c
> +++ b/crypto/asymmetric_keys/x509_cert_parser.c
> @@ -373,6 +373,9 @@ int rsa_extract_mpi(void *context, size_t hdrlen,
>   return 0;
>  }
>  
> +/* The keyIdentifier in AuthorityKeyIdentifier SEQUENCE is tag(CONT,PRIM,0) 
> */
> +#define SEQ_TAG_KEYID (ASN1_CONT << 6)
> +
>  /*
>   * Process certificate extensions that are used to qualify the certificate.
>   */
> @@ -407,21 +410,58 @@ int x509_process_extension(void *context, size_t hdrlen,
>   }
>  
>   if (ctx->last_oid == OID_authorityKeyIdentifier) {
> + size_t key_len;
> +
>   /* Get hold of the CA key fingerprint */
>   if (vlen < 5)
>   return -EBADMSG;
> - if (v[0] != (ASN1_SEQ | (ASN1_CONS << 5)) ||
> - v[1] != vlen - 2 ||
> - v[2] != (ASN1_CONT << 6) ||
> - v[3] != vlen - 4)
> +
> + /* Authority Key Identifier must be a Constructed SEQUENCE */
> + if (v[0] != (ASN1_SEQ | (ASN1_CONS << 5)))
>   return -EBADMSG;
> - v += 4;
> - vlen -= 4;
>  
> - f = kmalloc(vlen * 2 + 1, GFP_KERNEL);
> + /* Authority Key Identifier is not indefinite length */
> + if (unlikely(vlen == ASN1_INDEFINITE_LENGTH))
> + return -EBADMSG;
> +
> + /* Short Form length */
> + if (vlen <= 127) {
> +
> + if (v[1] != vlen - 2 ||
> + v[2] != SEQ_TAG_KEYID ||
> + v[3] != vlen - 4)
> + return -EBADMSG;
> +
> + v += 4;
> + key_len = v[3];
> + } else {
> + /* Long Form length */
> + size_t seq_len = 0;
> + int sub = v[1] - 0x80;
> +
> + if (sub > 2)
> + return -EBADMSG;
> +
> + /* calculate the length from subsequent octet */
> + for (i = 0; i < sub; i++) {
> + seq_len <<= 8;
> + seq_len |= v[2 + i];
> + }
> +
> + /* check vlen should not less then length of keyid */
> + if (seq_len != vlen - 2 - sub ||
> + v[2 + sub] != SEQ_TAG_KEYID ||
> + v[3 + sub] > vlen - 4 - sub)
> + return -EBADMSG;
> +
> + v += (4 + sub);
> + key_len = v[3 + sub];
> + }
> +
> + f = kmalloc(key_len * 2 + 1, GFP_KERNEL);
>   if (!f)
>   return -ENOMEM;
> - for (i = 0; i < vlen; i++)
> + for (i = 0; i < key_len; i++)
>   sprintf(f + i * 2, "%02x", v[i]);
>   pr_debug("authority   %s\n", f);
>   ctx->cert->authority = f;


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in

[PATCH] X.509: Support parse long form of length octets in Authority Key Identifier

[Lee, Chun-Yi]

Per X.509 spec in 4.2.1.1 section, the structure of Authority Key
Identifier Extension is:

   AuthorityKeyIdentifier ::= SEQUENCE {
  keyIdentifier [0] KeyIdentifier   OPTIONAL,
  authorityCertIssuer   [1] GeneralNamesOPTIONAL,
  authorityCertSerialNumber [2] CertificateSerialNumber OPTIONAL  }

   KeyIdentifier ::= OCTET STRING

When a certificate also provides
authorityCertIssuer and authorityCertSerialNumber then the length of
AuthorityKeyIdentifier SEQUENCE is likely to long form format.
e.g.
   The example certificate demos/tunala/A-server.pem in openssl source:

X509v3 Authority Key Identifier:
keyid:49:FB:45:72:12:C4:CC:E1:45:A1:D3:08:9E:95:C4:2C:6D:55:3F:17
DirName:/C=NZ/L=Wellington/O=Really Irresponsible Authorisation Authority 
(RIAA)/OU=Cert-stamping/CN=Jackov al-Trades/emailAddress=none@fake.domain
serial:00

Current parsing rule of OID_authorityKeyIdentifier only take care the
short form format, it causes load certificate to modsign_keyring fail:

[   12.061147] X.509: Extension: 47
[   12.075121] MODSIGN: Problem loading in-kernel X.509 certificate (-74)

So, this patch add the parsing rule for support long form format against
Authority Key Identifier.

Cc: David Howells 
Cc: Rusty Russell 
Cc: Josh Boyer 
Cc: Randy Dunlap 
Cc: Herbert Xu 
Cc: "David S. Miller" 
Signed-off-by: Lee, Chun-Yi 
---
 crypto/asymmetric_keys/x509_cert_parser.c |   56 
 1 files changed, 48 insertions(+), 8 deletions(-)

diff --git a/crypto/asymmetric_keys/x509_cert_parser.c 
b/crypto/asymmetric_keys/x509_cert_parser.c
index 7fabc4c..7f6a152 100644
--- a/crypto/asymmetric_keys/x509_cert_parser.c
+++ b/crypto/asymmetric_keys/x509_cert_parser.c
@@ -373,6 +373,9 @@ int rsa_extract_mpi(void *context, size_t hdrlen,
return 0;
 }
 
+/* The keyIdentifier in AuthorityKeyIdentifier SEQUENCE is tag(CONT,PRIM,0) */
+#define SEQ_TAG_KEYID (ASN1_CONT << 6)
+
 /*
  * Process certificate extensions that are used to qualify the certificate.
  */
@@ -407,21 +410,58 @@ int x509_process_extension(void *context, size_t hdrlen,
}
 
if (ctx->last_oid == OID_authorityKeyIdentifier) {
+   size_t key_len;
+
/* Get hold of the CA key fingerprint */
if (vlen < 5)
return -EBADMSG;
-   if (v[0] != (ASN1_SEQ | (ASN1_CONS << 5)) ||
-   v[1] != vlen - 2 ||
-   v[2] != (ASN1_CONT << 6) ||
-   v[3] != vlen - 4)
+
+   /* Authority Key Identifier must be a Constructed SEQUENCE */
+   if (v[0] != (ASN1_SEQ | (ASN1_CONS << 5)))
return -EBADMSG;
-   v += 4;
-   vlen -= 4;
 
-   f = kmalloc(vlen * 2 + 1, GFP_KERNEL);
+   /* Authority Key Identifier is not indefinite length */
+   if (unlikely(vlen == ASN1_INDEFINITE_LENGTH))
+   return -EBADMSG;
+
+   /* Short Form length */
+   if (vlen <= 127) {
+
+   if (v[1] != vlen - 2 ||
+   v[2] != SEQ_TAG_KEYID ||
+   v[3] != vlen - 4)
+   return -EBADMSG;
+
+   v += 4;
+   key_len = v[3];
+   } else {
+   /* Long Form length */
+   size_t seq_len = 0;
+   int sub = v[1] - 0x80;
+
+   if (sub > 2)
+   return -EBADMSG;
+
+   /* calculate the length from subsequent octet */
+   for (i = 0; i < sub; i++) {
+   seq_len <<= 8;
+   seq_len |= v[2 + i];
+   }
+
+   /* check vlen should not less then length of keyid */
+   if (seq_len != vlen - 2 - sub ||
+   v[2 + sub] != SEQ_TAG_KEYID ||
+   v[3 + sub] > vlen - 4 - sub)
+   return -EBADMSG;
+
+   v += (4 + sub);
+   key_len = v[3 + sub];
+   }
+
+   f = kmalloc(key_len * 2 + 1, GFP_KERNEL);
if (!f)
return -ENOMEM;
-   for (i = 0; i < vlen; i++)
+   for (i = 0; i < key_len; i++)
sprintf(f + i * 2, "%02x", v[i]);
pr_debug("authority   %s\n", f);
ctx->cert->authority = f;
-- 
1.6.4.2

--
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/

Re: linux-next: manual merge of the driver-core tree with the spi tree

[Greg KH]

On Wed, Feb 06, 2013 at 04:21:51PM +1100, Stephen Rothwell wrote:
> Hi Greg,
> 
> Today's linux-next merge of the driver-core tree got a conflict in 
> drivers/spi/spi-s3c64xx.c between commit 4eb770067f3a ("spi/s3c64xx: Use 
> devm_clk_get() and devm_request_irq()") from the  tree and commit 
> b0ee5605234a ("spi: Convert to devm_ioremap_resource()") from the driver-core 
> tree.
> 
> I fixed it up (see below) and can carry the fix as necessary (no action
> is required).

Looks good to me, thanks.

greg k-h
--
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/

Re: linux-next: manual merge of the driver-core tree with the iommu tree

[Greg KH]

On Wed, Feb 06, 2013 at 04:25:23PM +1100, Stephen Rothwell wrote:
> Hi Greg,
> 
> Today's linux-next merge of the driver-core tree got a conflict in
> drivers/iommu/tegra-smmu.c between commit a6870e928d1b ("iommu/tegra:
> smmu: Support variable MMIO ranges/blocks") from the iommu tree and
> commit bc5e6dea81b0 ("iommu: Convert to devm_ioremap_resource()") from
> the driver-core tree.
> 
> I fixed it up (see below) and can carry the fix as necessary (no action
> is required).

Looks good to me, thanks.

greg k-h
--
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/

[PATCH 3/5] ARM: OMAP2: MUSB: Specify omap4 has mailbox

[Kishon Vijay Abraham I]

Added has_mailbox to the musb platform data to specify that omap uses
an external mailbox (in control module) to communicate with the musb
core during device connect and disconnect.

Signed-off-by: Kishon Vijay Abraham I 
Acked-by: Tony Lindgren 
---
 arch/arm/mach-omap2/usb-musb.c |3 +++
 include/linux/usb/musb.h   |2 ++
 2 files changed, 5 insertions(+)

diff --git a/arch/arm/mach-omap2/usb-musb.c b/arch/arm/mach-omap2/usb-musb.c
index 7b33b37..9d27e3f 100644
--- a/arch/arm/mach-omap2/usb-musb.c
+++ b/arch/arm/mach-omap2/usb-musb.c
@@ -85,6 +85,9 @@ void __init usb_musb_init(struct omap_musb_board_data 
*musb_board_data)
musb_plat.mode = board_data->mode;
musb_plat.extvbus = board_data->extvbus;
 
+   if (cpu_is_omap44xx())
+   musb_plat.has_mailbox = true;
+
if (soc_is_am35xx()) {
oh_name = "am35x_otg_hs";
name = "musb-am35x";
diff --git a/include/linux/usb/musb.h b/include/linux/usb/musb.h
index eb50525..053c268 100644
--- a/include/linux/usb/musb.h
+++ b/include/linux/usb/musb.h
@@ -99,6 +99,8 @@ struct musb_hdrc_platform_data {
/* MUSB_HOST, MUSB_PERIPHERAL, or MUSB_OTG */
u8  mode;
 
+   u8  has_mailbox:1;
+
/* for clk_get() */
const char  *clock;
 
-- 
1.7.10.4

--
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/

[PATCH 2/5] ARM: OMAP: devices: create device for usb part of control module

[Kishon Vijay Abraham I]

A seperate driver has been added to handle the usb part of control
module. A device for the above driver is created here, using the register
address information to be used by the driver for powering on the PHY and
for writing to the mailbox.

Signed-off-by: Kishon Vijay Abraham I 
Acked-by: Tony Lindgren 
---
 arch/arm/mach-omap2/devices.c |   45 +
 1 file changed, 45 insertions(+)

diff --git a/arch/arm/mach-omap2/devices.c b/arch/arm/mach-omap2/devices.c
index 626f3ea..6cda103 100644
--- a/arch/arm/mach-omap2/devices.c
+++ b/arch/arm/mach-omap2/devices.c
@@ -20,6 +20,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include 
 #include 
@@ -254,6 +255,49 @@ static inline void omap_init_camera(void)
 #endif
 }
 
+#if IS_ENABLED(CONFIG_OMAP_CONTROL_USB)
+static struct omap_control_usb_platform_data omap4_control_usb_pdata = {
+   .type = 1,
+};
+
+struct resource omap4_control_usb_res[] = {
+   {
+   .name   = "control_dev_conf",
+   .start  = 0x4a002300,
+   .end= 0x4a002303,
+   .flags  = IORESOURCE_MEM,
+   },
+   {
+   .name   = "otghs_control",
+   .start  = 0x4a00233c,
+   .end= 0x4a00233f,
+   .flags  = IORESOURCE_MEM,
+   },
+};
+
+static struct platform_device omap4_control_usb = {
+   .name   = "omap-control-usb",
+   .id = -1,
+   .dev = {
+   .platform_data = _control_usb_pdata,
+   },
+   .num_resources = 2,
+   .resource = omap4_control_usb_res,
+};
+
+static inline void __init omap_init_control_usb(void)
+{
+   if (!cpu_is_omap44xx())
+   return;
+
+   if (platform_device_register(_control_usb))
+   pr_err("Error registering omap_control_usb device\n");
+}
+
+#else
+static inline void omap_init_control_usb(void) { }
+#endif /* CONFIG_OMAP_CONTROL_USB */
+
 int __init omap4_keyboard_init(struct omap4_keypad_platform_data
*sdp4430_keypad_data, struct omap_board_data *bdata)
 {
@@ -721,6 +765,7 @@ static int __init omap2_init_devices(void)
omap_init_mbox();
/* If dtb is there, the devices will be created dynamically */
if (!of_have_populated_dt()) {
+   omap_init_control_usb();
omap_init_dmic();
omap_init_mcpdm();
omap_init_mcspi();
-- 
1.7.10.4

--
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/

[PATCH 5/5] usb: omap_control_usb: fix compile warning

[Kishon Vijay Abraham I]

From: Felipe Balbi 

When CONFIG_OMAP_CONTROL_USB isn't enabled,
there's a compile warning stating that a
particular function isn't a prototype.

Fix it.

Signed-off-by: Felipe Balbi 
Signed-off-by: Kishon Vijay Abraham I 
---
 include/linux/usb/omap_control_usb.h |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/include/linux/usb/omap_control_usb.h 
b/include/linux/usb/omap_control_usb.h
index f306db7..27b5b8c 100644
--- a/include/linux/usb/omap_control_usb.h
+++ b/include/linux/usb/omap_control_usb.h
@@ -70,7 +70,7 @@ extern void omap_control_usb3_phy_power(struct device *dev, 
bool on);
 extern void omap_control_usb_set_mode(struct device *dev,
enum omap_control_usb_mode mode);
 #else
-static inline struct device *omap_get_control_dev()
+static inline struct device *omap_get_control_dev(void)
 {
return ERR_PTR(-ENODEV);
 }
-- 
1.7.10.4

--
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/

[PATCH 1/5] ARM: OMAP4: remove control module address space from PHY and OTG

[Kishon Vijay Abraham I]

Now that we have a separate driver for the control module,
stop populating the control module device data in other modules
(PHY and OTG) device info.

Signed-off-by: Kishon Vijay Abraham I 
Acked-by: Tony Lindgren 
---
 arch/arm/mach-omap2/omap_hwmod_44xx_data.c |   13 -
 1 file changed, 13 deletions(-)

diff --git a/arch/arm/mach-omap2/omap_hwmod_44xx_data.c 
b/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
index 793f54a..624a7e8 100644
--- a/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
@@ -2702,13 +2702,6 @@ static struct resource omap44xx_usb_phy_and_pll_addrs[] 
= {
.end= 0x4a0ae000,
.flags  = IORESOURCE_MEM,
},
-   {
-   /* XXX: Remove this once control module driver is in place */
-   .name   = "ctrl_dev",
-   .start  = 0x4a002300,
-   .end= 0x4a002303,
-   .flags  = IORESOURCE_MEM,
-   },
{ }
 };
 
@@ -6156,12 +6149,6 @@ static struct omap_hwmod_addr_space 
omap44xx_usb_otg_hs_addrs[] = {
.pa_end = 0x4a0ab7ff,
.flags  = ADDR_TYPE_RT
},
-   {
-   /* XXX: Remove this once control module driver is in place */
-   .pa_start   = 0x4a00233c,
-   .pa_end = 0x4a00233f,
-   .flags  = ADDR_TYPE_RT
-   },
{ }
 };
 
-- 
1.7.10.4

--
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/

[PATCH 4/5] ARM: OMAP: USB: Add phy binding information

[Kishon Vijay Abraham I]

This is w.r.t the changes in PHY library to support adding and getting
multiple PHYs of the same type. In the new design, the
binding information between the PHY and the USB controller should be
specified in the platform specific initialization code. So it's been
done here for OMAP platforms.

Signed-off-by: Kishon Vijay Abraham I 
Acked-by: Tony Lindgren 
---
 arch/arm/mach-omap2/board-2430sdp.c  |2 ++
 arch/arm/mach-omap2/board-3430sdp.c  |2 ++
 arch/arm/mach-omap2/board-4430sdp.c  |2 ++
 arch/arm/mach-omap2/board-cm-t35.c   |2 ++
 arch/arm/mach-omap2/board-devkit8000.c   |2 ++
 arch/arm/mach-omap2/board-igep0020.c |2 ++
 arch/arm/mach-omap2/board-ldp.c  |2 ++
 arch/arm/mach-omap2/board-omap3beagle.c  |2 ++
 arch/arm/mach-omap2/board-omap3evm.c |2 ++
 arch/arm/mach-omap2/board-omap3logic.c   |2 ++
 arch/arm/mach-omap2/board-omap3pandora.c |2 ++
 arch/arm/mach-omap2/board-omap3stalker.c |2 ++
 arch/arm/mach-omap2/board-omap3touchbook.c   |2 ++
 arch/arm/mach-omap2/board-omap4panda.c   |2 ++
 arch/arm/mach-omap2/board-overo.c|2 ++
 arch/arm/mach-omap2/board-rm680.c|2 ++
 arch/arm/mach-omap2/board-zoom-peripherals.c |2 ++
 17 files changed, 34 insertions(+)

diff --git a/arch/arm/mach-omap2/board-2430sdp.c 
b/arch/arm/mach-omap2/board-2430sdp.c
index 4815ea6..1337f2c 100644
--- a/arch/arm/mach-omap2/board-2430sdp.c
+++ b/arch/arm/mach-omap2/board-2430sdp.c
@@ -27,6 +27,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include 
 #include 
@@ -263,6 +264,7 @@ static void __init omap_2430sdp_init(void)
omap_hsmmc_init(mmc);
 
omap_mux_init_signal("usb0hs_stp", OMAP_PULL_ENA | OMAP_PULL_UP);
+   usb_bind_phy("musb-hdrc.0.auto", 0, "twl4030_usb");
usb_musb_init(NULL);
 
board_smc91x_init();
diff --git a/arch/arm/mach-omap2/board-3430sdp.c 
b/arch/arm/mach-omap2/board-3430sdp.c
index bb73afc..8a2e242 100644
--- a/arch/arm/mach-omap2/board-3430sdp.c
+++ b/arch/arm/mach-omap2/board-3430sdp.c
@@ -25,6 +25,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include 
 #include 
@@ -579,6 +580,7 @@ static void __init omap_3430sdp_init(void)
omap_ads7846_init(1, gpio_pendown, 310, NULL);
omap_serial_init();
omap_sdrc_init(hyb18m512160af6_sdrc_params, NULL);
+   usb_bind_phy("musb-hdrc.0.auto", 0, "twl4030_usb");
usb_musb_init(NULL);
board_smc91x_init();
board_flash_init(sdp_flash_partitions, chip_sel_3430, 0);
diff --git a/arch/arm/mach-omap2/board-4430sdp.c 
b/arch/arm/mach-omap2/board-4430sdp.c
index 1cc6696..8e8efcc 100644
--- a/arch/arm/mach-omap2/board-4430sdp.c
+++ b/arch/arm/mach-omap2/board-4430sdp.c
@@ -28,6 +28,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include 
 #include 
@@ -696,6 +697,7 @@ static void __init omap_4430sdp_init(void)
omap4_sdp4430_wifi_init();
omap4_twl6030_hsmmc_init(mmc);
 
+   usb_bind_phy("musb-hdrc.0.auto", 0, "omap-usb2.1.auto");
usb_musb_init(_board_data);
 
status = omap_ethernet_init();
diff --git a/arch/arm/mach-omap2/board-cm-t35.c 
b/arch/arm/mach-omap2/board-cm-t35.c
index b3102c2..f1172f2 100644
--- a/arch/arm/mach-omap2/board-cm-t35.c
+++ b/arch/arm/mach-omap2/board-cm-t35.c
@@ -30,6 +30,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include 
 #include 
@@ -724,6 +725,7 @@ static void __init cm_t3x_common_init(void)
cm_t35_init_display();
omap_twl4030_audio_init("cm-t3x");
 
+   usb_bind_phy("musb-hdrc.0.auto", 0, "twl4030_usb");
usb_musb_init(NULL);
cm_t35_init_usbh();
cm_t35_init_camera();
diff --git a/arch/arm/mach-omap2/board-devkit8000.c 
b/arch/arm/mach-omap2/board-devkit8000.c
index 12865af..77cade52 100644
--- a/arch/arm/mach-omap2/board-devkit8000.c
+++ b/arch/arm/mach-omap2/board-devkit8000.c
@@ -29,6 +29,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include 
 #include 
@@ -622,6 +623,7 @@ static void __init devkit8000_init(void)
 
omap_ads7846_init(2, OMAP3_DEVKIT_TS_GPIO, 0, NULL);
 
+   usb_bind_phy("musb-hdrc.0.auto", 0, "twl4030_usb");
usb_musb_init(NULL);
usbhs_init(_bdata);
board_nand_init(devkit8000_nand_partitions,
diff --git a/arch/arm/mach-omap2/board-igep0020.c 
b/arch/arm/mach-omap2/board-igep0020.c
index 0f24cb8..15e5881 100644
--- a/arch/arm/mach-omap2/board-igep0020.c
+++ b/arch/arm/mach-omap2/board-igep0020.c
@@ -18,6 +18,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include 
 #include 
@@ -625,6 +626,7 @@ static void __init igep_init(void)
omap_serial_init();
omap_sdrc_init(m65kam_sdrc_params,
  m65kam_sdrc_params);
+   usb_bind_phy("musb-hdrc.0.auto", 0, "twl4030_usb");
usb_musb_init(NULL);
 
igep_flash_init();
diff --git a/arch/arm/mach-omap2/board-ldp.c 

[PATCH 0/5] ARM: OMAP: arm part of usb patches

[Kishon Vijay Abraham I]

Hi Greg,

Here is the patch series that includes the arch/arm part to get MUSB
working in OMAP platforms. As discussed in the other mail thread with
Tony, this patch series should go into usb-next.

This patch series also contains a patch by Felipe to fix compilation
warning in usb-next when CONFIG_OMAP_CONTROL_USB is not set.

Boot tested panda board.

Felipe Balbi (1):
  usb: omap_control_usb: fix compile warning

Kishon Vijay Abraham I (4):
  ARM: OMAP4: remove control module address space from PHY and OTG
  ARM: OMAP: devices: create device for usb part of control module
  ARM: OMAP2: MUSB: Specify omap4 has mailbox
  ARM: OMAP: USB: Add phy binding information

 arch/arm/mach-omap2/board-2430sdp.c  |2 ++
 arch/arm/mach-omap2/board-3430sdp.c  |2 ++
 arch/arm/mach-omap2/board-4430sdp.c  |2 ++
 arch/arm/mach-omap2/board-cm-t35.c   |2 ++
 arch/arm/mach-omap2/board-devkit8000.c   |2 ++
 arch/arm/mach-omap2/board-igep0020.c |2 ++
 arch/arm/mach-omap2/board-ldp.c  |2 ++
 arch/arm/mach-omap2/board-omap3beagle.c  |2 ++
 arch/arm/mach-omap2/board-omap3evm.c |2 ++
 arch/arm/mach-omap2/board-omap3logic.c   |2 ++
 arch/arm/mach-omap2/board-omap3pandora.c |2 ++
 arch/arm/mach-omap2/board-omap3stalker.c |2 ++
 arch/arm/mach-omap2/board-omap3touchbook.c   |2 ++
 arch/arm/mach-omap2/board-omap4panda.c   |2 ++
 arch/arm/mach-omap2/board-overo.c|2 ++
 arch/arm/mach-omap2/board-rm680.c|2 ++
 arch/arm/mach-omap2/board-zoom-peripherals.c |2 ++
 arch/arm/mach-omap2/devices.c|   45 ++
 arch/arm/mach-omap2/omap_hwmod_44xx_data.c   |   13 
 arch/arm/mach-omap2/usb-musb.c   |3 ++
 include/linux/usb/musb.h |2 ++
 include/linux/usb/omap_control_usb.h |2 +-
 22 files changed, 85 insertions(+), 14 deletions(-)

-- 
1.7.10.4

--
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/

[PATCH 2/3] perf sort: Make setup_sorting returns an error code

[Namhyung Kim]

From: Namhyung Kim 

Currently the setup_sorting() is called for parsing sort keys and
exits if it failed to add the sort key.  As it's included in libperf
it'd be better returning an error code rather than exiting application
inside of the library.

Suggested-by: Arnaldo Carvalho de Melo 
Cc: Stephane Eranian 
Cc: Jiri Olsa 
Signed-off-by: Namhyung Kim 
---
 tools/perf/builtin-annotate.c |  3 ++-
 tools/perf/builtin-diff.c |  4 +++-
 tools/perf/builtin-report.c   |  3 ++-
 tools/perf/builtin-top.c  |  3 ++-
 tools/perf/tests/hists_link.c |  3 ++-
 tools/perf/util/sort.c| 10 ++
 tools/perf/util/sort.h|  2 +-
 7 files changed, 18 insertions(+), 10 deletions(-)

diff --git a/tools/perf/builtin-annotate.c b/tools/perf/builtin-annotate.c
index dc870cf31b79..95a2ad3f043e 100644
--- a/tools/perf/builtin-annotate.c
+++ b/tools/perf/builtin-annotate.c
@@ -309,7 +309,8 @@ int cmd_annotate(int argc, const char **argv, const char 
*prefix __maybe_unused)
if (symbol__init() < 0)
return -1;
 
-   setup_sorting(annotate_usage, options);
+   if (setup_sorting() < 0)
+   usage_with_options(annotate_usage, options);
 
if (argc) {
/*
diff --git a/tools/perf/builtin-diff.c b/tools/perf/builtin-diff.c
index 4af0b580b046..d207a97a2db1 100644
--- a/tools/perf/builtin-diff.c
+++ b/tools/perf/builtin-diff.c
@@ -605,7 +605,9 @@ int cmd_diff(int argc, const char **argv, const char 
*prefix __maybe_unused)
 
ui_init();
 
-   setup_sorting(diff_usage, options);
+   if (setup_sorting() < 0)
+   usage_with_options(diff_usage, options);
+
setup_pager();
 
sort_entry__setup_elide(_dso, symbol_conf.dso_list, "dso", NULL);
diff --git a/tools/perf/builtin-report.c b/tools/perf/builtin-report.c
index 0d221870561a..71d0b0e334be 100644
--- a/tools/perf/builtin-report.c
+++ b/tools/perf/builtin-report.c
@@ -741,7 +741,8 @@ int cmd_report(int argc, const char **argv, const char 
*prefix __maybe_unused)
perf_hpp__init();
}
 
-   setup_sorting(report_usage, options);
+   if (setup_sorting() < 0)
+   usage_with_options(report_usage, options);
 
/*
 * Only in the newt browser we are doing integrated annotation,
diff --git a/tools/perf/builtin-top.c b/tools/perf/builtin-top.c
index f561757b1bfa..72f6eb7b4173 100644
--- a/tools/perf/builtin-top.c
+++ b/tools/perf/builtin-top.c
@@ -1129,7 +1129,8 @@ int cmd_top(int argc, const char **argv, const char 
*prefix __maybe_unused)
if (sort_order == default_sort_order)
sort_order = "dso,symbol";
 
-   setup_sorting(top_usage, options);
+   if (setup_sorting() < 0)
+   usage_with_options(top_usage, options);
 
if (top.use_stdio)
use_browser = 0;
diff --git a/tools/perf/tests/hists_link.c b/tools/perf/tests/hists_link.c
index 0afd9223bde7..1be64a6c5daf 100644
--- a/tools/perf/tests/hists_link.c
+++ b/tools/perf/tests/hists_link.c
@@ -449,7 +449,8 @@ int test__hists_link(void)
goto out;
 
/* default sort order (comm,dso,sym) will be used */
-   setup_sorting(NULL, NULL);
+   if (setup_sorting() < 0)
+   goto out;
 
machines__init();
 
diff --git a/tools/perf/util/sort.c b/tools/perf/util/sort.c
index 03cabe5678d0..d8b48827a17e 100644
--- a/tools/perf/util/sort.c
+++ b/tools/perf/util/sort.c
@@ -565,23 +565,25 @@ int sort_dimension__add(const char *tok)
return -ESRCH;
 }
 
-void setup_sorting(const char * const usagestr[], const struct option *opts)
+int setup_sorting(void)
 {
char *tmp, *tok, *str = strdup(sort_order);
+   int ret = 0;
 
for (tok = strtok_r(str, ", ", );
tok; tok = strtok_r(NULL, ", ", )) {
-   int ret = sort_dimension__add(tok);
+   ret = sort_dimension__add(tok);
if (ret == -EINVAL) {
error("Invalid --sort key: `%s'", tok);
-   usage_with_options(usagestr, opts);
+   break;
} else if (ret == -ESRCH) {
error("Unknown --sort key: `%s'", tok);
-   usage_with_options(usagestr, opts);
+   break;
}
}
 
free(str);
+   return ret;
 }
 
 void sort_entry__setup_elide(struct sort_entry *self, struct strlist *list,
diff --git a/tools/perf/util/sort.h b/tools/perf/util/sort.h
index e994ad3e9897..b13e56f6ccbe 100644
--- a/tools/perf/util/sort.h
+++ b/tools/perf/util/sort.h
@@ -160,7 +160,7 @@ struct sort_entry {
 extern struct sort_entry sort_thread;
 extern struct list_head hist_entry__sort_list;
 
-void setup_sorting(const char * const usagestr[], const struct option *opts);
+int setup_sorting(void);
 extern int sort_dimension__add(const char *);
 void sort_entry__setup_elide(struct sort_entry *self, struct strlist 

Re: [PATCH] unbreak automounter support on 64-bit kernel with 32-bit userspace (v2)

[Ian Kent]

On Mon, 2013-02-04 at 20:39 +0100, Helge Deller wrote:
> automount-support is broken on the parisc architecture, because the existing
> #if list does not include a check for defined(__hppa__). The HPPA (parisc)
> architecture is similiar to other 64bit Linux targets where we have to define
> autofs_wqt_t (which is passed back and forth to user space) as int type which
> has a size of 32bit across 32 and 64bit kernels.
> 
> During the discussion on the mailing list, H. Peter Anvin suggested to invert
> the #if list since only specific platforms (specifically those who do not have
> a 32bit userspace, like IA64 and Alpha) should have autofs_wqt_t as unsigned
> long type.
> 
> This suggestion is probably the best way to go, since Arm64 (and maybe 
> others?)
> seems to have a non-working automounter. So in the long run even for other new
> upcoming architectures this inverted check seem to be the best solution, since
> it will not require them to change this #if again (unless they are 64bit 
> only).
> 
> Signed-off-by: Helge Deller 
> CC: James Bottomley 
> CC: Catalin Marinas 
> CC: Rolf Eike Beer 
> CC: H. Peter Anvin 
> CC: Ian Kent 
> 
> 
> diff --git a/include/uapi/linux/auto_fs.h b/include/uapi/linux/auto_fs.h
> index 77cdba9..bb991df 100644
> --- a/include/uapi/linux/auto_fs.h
> +++ b/include/uapi/linux/auto_fs.h
> @@ -28,25 +28,16 @@
>  #define AUTOFS_MIN_PROTO_VERSION AUTOFS_PROTO_VERSION
>  
>  /*
> - * Architectures where both 32- and 64-bit binaries can be executed
> - * on 64-bit kernels need this.  This keeps the structure format
> - * uniform, and makes sure the wait_queue_token isn't too big to be
> - * passed back down to the kernel.
> - *
> - * This assumes that on these architectures:
> - * mode 32 bit64 bit
> - * -
> - * int  32 bit32 bit
> - * long 32 bit64 bit
> - *
> - * If so, 32-bit user-space code should be backwards compatible.
> + * The wait_queue_token (autofs_wqt_t) is part of a structure which is passed
> + * back to the kernel via ioctl from userspace. On architectures where 32- 
> and
> + * 64-bit userspace binaries can be executed it's important that the size of
> + * autofs_wqt_t stays constant between 32- and 64-bit Linux kernels so that 
> we
> + * do not break the binary ABI interface by changing the structure size.
>   */
> -
> -#if defined(__sparc__) || defined(__mips__) || defined(__x86_64__) \
> - || defined(__powerpc__) || defined(__s390__)
> -typedef unsigned int autofs_wqt_t;
> -#else
> +#if defined(__ia64__) || defined(__alpha__) /* pure 64bit architectures */
>  typedef unsigned long autofs_wqt_t;
> +#else
> +typedef unsigned int autofs_wqt_t;
>  #endif
>  
>  /* Packet types */

Acked-by: Ian Kent 


--
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/

[PATCH 3/3] perf sort: Check return value of strdup()

[Namhyung Kim]

From: Namhyung Kim 

When setup_sorting() is called, 'str' is passed to strtok_r() but it's
not checked to have a valid pointer.  As strtok_r() accepts NULL
pointer on a first argument and use the third argument in that case,
it can cause a trouble since our third argument, tmp, is not
initialized.

Acked-by: Jiri Olsa 
Cc: Stephane Eranian 
Signed-off-by: Namhyung Kim 
---
 tools/perf/util/sort.c | 5 +
 1 file changed, 5 insertions(+)

diff --git a/tools/perf/util/sort.c b/tools/perf/util/sort.c
index d8b48827a17e..d41926cb9e3f 100644
--- a/tools/perf/util/sort.c
+++ b/tools/perf/util/sort.c
@@ -570,6 +570,11 @@ int setup_sorting(void)
char *tmp, *tok, *str = strdup(sort_order);
int ret = 0;
 
+   if (str == NULL) {
+   error("Not enough memory to setup sort keys");
+   return -ENOMEM;
+   }
+
for (tok = strtok_r(str, ", ", );
tok; tok = strtok_r(NULL, ", ", )) {
ret = sort_dimension__add(tok);
-- 
1.7.11.7

--
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/

[PATCH RESEND 1/3] perf sort: Drop ip_[lr] arguments from _sort__sym_cmp()

[Namhyung Kim]

From: Namhyung Kim 

Current _sort__sym_cmp() function is used for comparing symbols
between two hist entries on symbol, symbol_from and symbol_to sort
keys.  Those functions pass addresses of symbols but it's meaningless
since it gets over-written inside of the _sort__sym_cmp function to a
start address of the symbol.  So just get rid of them.

This might cause a difference than prior output for branch stacks
since it seems not using start address of the symbol but branch
address.  However AFAICS it'd be same as it gets overwritten anyway.

Also remove redundant part of code in sort__sym_cmp().

Acked-by: Jiri Olsa 
Cc: Stephane Eranian 
Signed-off-by: Namhyung Kim 
---
 tools/perf/util/sort.c | 23 ++-
 1 file changed, 6 insertions(+), 17 deletions(-)

diff --git a/tools/perf/util/sort.c b/tools/perf/util/sort.c
index 83336610faa9..03cabe5678d0 100644
--- a/tools/perf/util/sort.c
+++ b/tools/perf/util/sort.c
@@ -160,9 +160,10 @@ struct sort_entry sort_dso = {
 
 /* --sort symbol */
 
-static int64_t _sort__sym_cmp(struct symbol *sym_l, struct symbol *sym_r,
- u64 ip_l, u64 ip_r)
+static int64_t _sort__sym_cmp(struct symbol *sym_l, struct symbol *sym_r)
 {
+   u64 ip_l, ip_r;
+
if (!sym_l || !sym_r)
return cmp_null(sym_l, sym_r);
 
@@ -178,21 +179,10 @@ static int64_t _sort__sym_cmp(struct symbol *sym_l, 
struct symbol *sym_r,
 static int64_t
 sort__sym_cmp(struct hist_entry *left, struct hist_entry *right)
 {
-   u64 ip_l, ip_r;
-
if (!left->ms.sym && !right->ms.sym)
return right->level - left->level;
 
-   if (!left->ms.sym || !right->ms.sym)
-   return cmp_null(left->ms.sym, right->ms.sym);
-
-   if (left->ms.sym == right->ms.sym)
-   return 0;
-
-   ip_l = left->ms.sym->start;
-   ip_r = right->ms.sym->start;
-
-   return _sort__sym_cmp(left->ms.sym, right->ms.sym, ip_l, ip_r);
+   return _sort__sym_cmp(left->ms.sym, right->ms.sym);
 }
 
 static int _hist_entry__sym_snprintf(struct map *map, struct symbol *sym,
@@ -383,8 +373,7 @@ sort__sym_from_cmp(struct hist_entry *left, struct 
hist_entry *right)
if (!from_l->sym && !from_r->sym)
return right->level - left->level;
 
-   return _sort__sym_cmp(from_l->sym, from_r->sym, from_l->addr,
-from_r->addr);
+   return _sort__sym_cmp(from_l->sym, from_r->sym);
 }
 
 static int64_t
@@ -396,7 +385,7 @@ sort__sym_to_cmp(struct hist_entry *left, struct hist_entry 
*right)
if (!to_l->sym && !to_r->sym)
return right->level - left->level;
 
-   return _sort__sym_cmp(to_l->sym, to_r->sym, to_l->addr, to_r->addr);
+   return _sort__sym_cmp(to_l->sym, to_r->sym);
 }
 
 static int hist_entry__sym_from_snprintf(struct hist_entry *self, char *bf,
-- 
1.7.11.7

--
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/

RE: [PATCH 2/3] omap: craneboard: support the TPS65910 PMU

[Kim, Milo]

> Thanks applying 1 and 2 into omap-for-v3.9/board. Did not
> see patch 3 of this anywhere?

Thank you.

The third patch is for the TPS65910 PMU on the Craneboard.
It was already applied.
https://lkml.org/lkml/2012/11/30/192

Regards,
Milo
--
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/

Re: linux-next: manual merge of the crypto tree with the net-next tree

[Herbert Xu]

On Wed, Feb 06, 2013 at 01:20:11PM +1100, Stephen Rothwell wrote:
> Hi Herbert,
> 
> Today's linux-next merge of the crypto tree got a conflict in
> crypto/ctr.c between commit 69d3150cfc20 ("crypto: ctr - make rfc3686
> asynchronous block cipher") from the net-next tree and commit
> 3e8afe35c36f ("crypto: use ERR_CAST") from the crypto tree.
> 
> I fixed it up (see below) and can carry the fix as necessary (no action
> is required).

Looks good.  Thanks Stephen!
-- 
Email: Herbert Xu 
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
--
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/

Re: [PATCH] cpufreq: ondemand: Replace down_differential tuner with adj_up_threshold

[Viresh Kumar]

On Wed, Feb 6, 2013 at 2:34 AM, Stratos Karafotis  wrote:
> In order to avoid the calculation of up_threshold - down_differential
> every time that the frequency must be decreased, we replace the
> down_differential tuner with the adj_up_threshold which keeps the
> difference across multiple checks.
>
> Update the adj_up_threshold only when the up_theshold is also updated.
>
> Signed-off-by: Stratos Karafotis 
> ---
>  drivers/cpufreq/cpufreq_governor.h |  2 +-
>  drivers/cpufreq/cpufreq_ondemand.c | 16 ++--
>  2 files changed, 11 insertions(+), 7 deletions(-)

Makes sense.

Acked-by: Viresh Kumar 
--
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/

[PATCH 3/7] fs/buffer.c: change type of max_buffer_heads to unsigned long

[Zhang Yanfei]

max_buffer_heads is calculated from nr_free_buffer_pages(), so
change its type to unsigned long in case of overflow.

Signed-off-by: Zhang Yanfei 
---
 fs/buffer.c |4 ++--
 1 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/fs/buffer.c b/fs/buffer.c
index 7a75c3e..3eb675b 100644
--- a/fs/buffer.c
+++ b/fs/buffer.c
@@ -3227,7 +3227,7 @@ static struct kmem_cache *bh_cachep __read_mostly;
  * Once the number of bh's in the machine exceeds this level, we start
  * stripping them in writeback.
  */
-static int max_buffer_heads;
+static unsigned long max_buffer_heads;
 
 int buffer_heads_over_limit;
 
@@ -3343,7 +3343,7 @@ EXPORT_SYMBOL(bh_submit_read);
 
 void __init buffer_init(void)
 {
-   int nrpages;
+   unsigned long nrpages;
 
bh_cachep = kmem_cache_create("buffer_head",
sizeof(struct buffer_head), 0,
-- 
1.7.1

--
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/

[PATCH 2/7] ia64: use %ld to print pages calculated in nr_free_buffer_pages

[Zhang Yanfei]

Now the function nr_free_buffer_pages returns unsigned long, so
use %ld to print its return value.

Signed-off-by: Zhang Yanfei 
---
 arch/ia64/mm/contig.c|2 +-
 arch/ia64/mm/discontig.c |2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/arch/ia64/mm/contig.c b/arch/ia64/mm/contig.c
index 1516d1d..80dab50 100644
--- a/arch/ia64/mm/contig.c
+++ b/arch/ia64/mm/contig.c
@@ -93,7 +93,7 @@ void show_mem(unsigned int filter)
printk(KERN_INFO "%d pages swap cached\n", total_cached);
printk(KERN_INFO "Total of %ld pages in page table cache\n",
   quicklist_total_size());
-   printk(KERN_INFO "%d free buffer pages\n", nr_free_buffer_pages());
+   printk(KERN_INFO "%ld free buffer pages\n", nr_free_buffer_pages());
 }
 
 
diff --git a/arch/ia64/mm/discontig.c b/arch/ia64/mm/discontig.c
index c641333..b8a8fa3 100644
--- a/arch/ia64/mm/discontig.c
+++ b/arch/ia64/mm/discontig.c
@@ -666,7 +666,7 @@ void show_mem(unsigned int filter)
printk(KERN_INFO "%d pages swap cached\n", total_cached);
printk(KERN_INFO "Total of %ld pages in page table cache\n",
   quicklist_total_size());
-   printk(KERN_INFO "%d free buffer pages\n", nr_free_buffer_pages());
+   printk(KERN_INFO "%ld free buffer pages\n", nr_free_buffer_pages());
 }
 
 /**
-- 
1.7.1

--
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/

[PATCH 4/7] fs/nfsd: change type of max_delegations, nfsd_drc_max_mem and nfsd_drc_mem_used

[Zhang Yanfei]

The three variables are calculated from nr_free_buffer_pages so
change their types to unsigned long in case of overflow.

Signed-off-by: Zhang Yanfei 
---
 fs/nfsd/nfs4state.c |6 +++---
 fs/nfsd/nfsd.h  |6 +++---
 fs/nfsd/nfssvc.c|6 +++---
 3 files changed, 9 insertions(+), 9 deletions(-)

diff --git a/fs/nfsd/nfs4state.c b/fs/nfsd/nfs4state.c
index ac8ed96..499e957 100644
--- a/fs/nfsd/nfs4state.c
+++ b/fs/nfsd/nfs4state.c
@@ -151,7 +151,7 @@ get_nfs4_file(struct nfs4_file *fi)
 }
 
 static int num_delegations;
-unsigned int max_delegations;
+unsigned long max_delegations;
 
 /*
  * Open owner state (share locks)
@@ -700,8 +700,8 @@ static int nfsd4_get_drc_mem(int slotsize, u32 num)
num = min_t(u32, num, NFSD_MAX_SLOTS_PER_SESSION);
 
spin_lock(_drc_lock);
-   avail = min_t(int, NFSD_MAX_MEM_PER_SESSION,
-   nfsd_drc_max_mem - nfsd_drc_mem_used);
+   avail = min((unsigned long)NFSD_MAX_MEM_PER_SESSION,
+   nfsd_drc_max_mem - nfsd_drc_mem_used);
num = min_t(int, num, avail / slotsize);
nfsd_drc_mem_used += num * slotsize;
spin_unlock(_drc_lock);
diff --git a/fs/nfsd/nfsd.h b/fs/nfsd/nfsd.h
index de23db2..07a473f 100644
--- a/fs/nfsd/nfsd.h
+++ b/fs/nfsd/nfsd.h
@@ -56,8 +56,8 @@ extern struct svc_version nfsd_version2, nfsd_version3,
 extern u32 nfsd_supported_minorversion;
 extern struct mutexnfsd_mutex;
 extern spinlock_t  nfsd_drc_lock;
-extern unsigned intnfsd_drc_max_mem;
-extern unsigned intnfsd_drc_mem_used;
+extern unsigned long   nfsd_drc_max_mem;
+extern unsigned long   nfsd_drc_mem_used;
 
 extern const struct seq_operations nfs_exports_op;
 
@@ -106,7 +106,7 @@ static inline int nfsd_v4client(struct svc_rqst *rq)
  * NFSv4 State
  */
 #ifdef CONFIG_NFSD_V4
-extern unsigned int max_delegations;
+extern unsigned long max_delegations;
 void nfs4_state_init(void);
 int nfsd4_init_slabs(void);
 void nfsd4_free_slabs(void);
diff --git a/fs/nfsd/nfssvc.c b/fs/nfsd/nfssvc.c
index cee62ab..be7af50 100644
--- a/fs/nfsd/nfssvc.c
+++ b/fs/nfsd/nfssvc.c
@@ -59,8 +59,8 @@ DEFINE_MUTEX(nfsd_mutex);
  * nfsd_drc_pages_used tracks the current version 4.1 DRC memory usage.
  */
 spinlock_t nfsd_drc_lock;
-unsigned int   nfsd_drc_max_mem;
-unsigned int   nfsd_drc_mem_used;
+unsigned long  nfsd_drc_max_mem;
+unsigned long  nfsd_drc_mem_used;
 
 #if defined(CONFIG_NFSD_V2_ACL) || defined(CONFIG_NFSD_V3_ACL)
 static struct svc_stat nfsd_acl_svcstats;
@@ -342,7 +342,7 @@ static void set_max_drc(void)
>> NFSD_DRC_SIZE_SHIFT) * PAGE_SIZE;
nfsd_drc_mem_used = 0;
spin_lock_init(_drc_lock);
-   dprintk("%s nfsd_drc_max_mem %u \n", __func__, nfsd_drc_max_mem);
+   dprintk("%s nfsd_drc_max_mem %lu \n", __func__, nfsd_drc_max_mem);
 }
 
 static int nfsd_get_default_max_blksize(void)
-- 
1.7.1
--
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/

linux-next: manual merge of the driver-core tree with the iommu tree

[Stephen Rothwell]

Hi Greg,

Today's linux-next merge of the driver-core tree got a conflict in
drivers/iommu/tegra-smmu.c between commit a6870e928d1b ("iommu/tegra:
smmu: Support variable MMIO ranges/blocks") from the iommu tree and
commit bc5e6dea81b0 ("iommu: Convert to devm_ioremap_resource()") from
the driver-core tree.

I fixed it up (see below) and can carry the fix as necessary (no action
is required).

-- 
Cheers,
Stephen Rothwells...@canb.auug.org.au

diff --cc drivers/iommu/tegra-smmu.c
index 7747283,f08dbcd..000
--- a/drivers/iommu/tegra-smmu.c
+++ b/drivers/iommu/tegra-smmu.c
@@@ -1185,13 -1177,10 +1186,13 @@@ static int tegra_smmu_probe(struct plat
res = platform_get_resource(pdev, IORESOURCE_MEM, i);
if (!res)
return -ENODEV;
-   smmu->regs[i] = devm_request_and_ioremap(>dev, res);
-   if (!smmu->regs[i])
-   return -EBUSY;
+   smmu->regs[i] = devm_ioremap_resource(>dev, res);
+   if (IS_ERR(smmu->regs[i]))
+   return PTR_ERR(smmu->regs[i]);
 +  smmu->rege[i] = smmu->regs[i] + resource_size(res) - 1;
}
 +  /* Same as "mc" 1st regiter block start address */
 +  smmu->regbase = (void __iomem *)((u32)smmu->regs[0] & ~PAGE_MASK);
  
err = of_get_dma_window(dev->of_node, NULL, 0, NULL, , );
if (err)


pgpWgCwHd51ks.pgp
Description: PGP signature

[PATCH 7/7] net: change type of virtio_chan->p9_max_pages

[Zhang Yanfei]

This member of struct virtio_chan is calculated from nr_free_buffer_pages
so change its type to unsigned long in case of overflow.

Signed-off-by: Zhang Yanfei 
---
 net/9p/trans_virtio.c |2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/net/9p/trans_virtio.c b/net/9p/trans_virtio.c
index fd05c81..de2e950 100644
--- a/net/9p/trans_virtio.c
+++ b/net/9p/trans_virtio.c
@@ -87,7 +87,7 @@ struct virtio_chan {
/* This is global limit. Since we don't have a global structure,
 * will be placing it in each channel.
 */
-   int p9_max_pages;
+   unsigned long p9_max_pages;
/* Scatterlist: can be too big for stack. */
struct scatterlist sg[VIRTQUEUE_NUM];
 
-- 
1.7.1

--
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/

[PATCH 6/7] net: change type of netns_ipvs->sysctl_sync_qlen_max

[Zhang Yanfei]

This member of struct netns_ipvs is calculated from nr_free_buffer_pages
so change its type to unsigned long in case of overflow.

Signed-off-by: Zhang Yanfei 
---
 include/net/ip_vs.h |2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/include/net/ip_vs.h b/include/net/ip_vs.h
index 68c69d5..66e6c01 100644
--- a/include/net/ip_vs.h
+++ b/include/net/ip_vs.h
@@ -966,7 +966,7 @@ struct netns_ipvs {
int sysctl_snat_reroute;
int sysctl_sync_ver;
int sysctl_sync_ports;
-   int sysctl_sync_qlen_max;
+   unsigned long   sysctl_sync_qlen_max;
int sysctl_sync_sock_size;
int sysctl_cache_bypass;
int sysctl_expire_nodest_conn;
-- 
1.7.1
--
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/

linux-next: manual merge of the driver-core tree with the spi tree

[Stephen Rothwell]

Hi Greg,

Today's linux-next merge of the driver-core tree got a conflict in 
drivers/spi/spi-s3c64xx.c between commit 4eb770067f3a ("spi/s3c64xx: Use 
devm_clk_get() and devm_request_irq()") from the  tree and commit b0ee5605234a 
("spi: Convert to devm_ioremap_resource()") from the driver-core tree.

I fixed it up (see below) and can carry the fix as necessary (no action
is required).

-- 
Cheers,
Stephen Rothwells...@canb.auug.org.au

diff --cc drivers/spi/spi-s3c64xx.c
index 7cfbe9d,3d4a7c4..000
--- a/drivers/spi/spi-s3c64xx.c
+++ b/drivers/spi/spi-s3c64xx.c
@@@ -1241,11 -1276,10 +1241,10 @@@ static int s3c64xx_spi_probe(struct pla
/* the spi->mode bits understood by this driver: */
master->mode_bits = SPI_CPOL | SPI_CPHA | SPI_CS_HIGH;
  
-   sdd->regs = devm_request_and_ioremap(>dev, mem_res);
-   if (sdd->regs == NULL) {
-   dev_err(>dev, "Unable to remap IO\n");
-   ret = -ENXIO;
+   sdd->regs = devm_ioremap_resource(>dev, mem_res);
+   if (IS_ERR(sdd->regs)) {
+   ret = PTR_ERR(sdd->regs);
 -  goto err1;
 +  goto err0;
}
  
if (!sci->cfg_gpio && pdev->dev.of_node) {


pgp4GIU_OCwxQ.pgp
Description: PGP signature

[PATCH RESEND] ARM: sched: correct update_sched_clock()

[Joonsoo Kim]

If we want load epoch_cyc and epoch_ns atomically,
we should update epoch_cyc_copy first of all.
This notify reader that updating is in progress.

If we update epoch_cyc first like as current implementation,
there is subtle error case.
Look at the below example.


cyc = 9
ns = 900
cyc_copy = 9

== CASE 1 ==
   
   write cyc = 10
read cyc = 10
read ns = 900
   write ns = 1000
   write cyc_copy = 10
read cyc_copy = 10

output = (10, 900)

== CASE 2 ==
   
read cyc = 9
   write cyc = 10
   write ns = 1000
read ns = 1000
read cyc_copy = 9
   write cyc_copy = 10
output = (9, 1000)

If atomic read is ensured, output should be (9, 900) or (10, 1000).
But, output in example case are not.

So, change updating sequence in order to correct this problem.

Signed-off-by: Joonsoo Kim 

diff --git a/arch/arm/kernel/sched_clock.c b/arch/arm/kernel/sched_clock.c
index fc6692e..bd6f56b 100644
--- a/arch/arm/kernel/sched_clock.c
+++ b/arch/arm/kernel/sched_clock.c
@@ -93,11 +93,11 @@ static void notrace update_sched_clock(void)
 * detectable in cyc_to_fixed_sched_clock().
 */
raw_local_irq_save(flags);
-   cd.epoch_cyc = cyc;
+   cd.epoch_cyc_copy = cyc;
smp_wmb();
cd.epoch_ns = ns;
smp_wmb();
-   cd.epoch_cyc_copy = cyc;
+   cd.epoch_cyc = cyc;
raw_local_irq_restore(flags);
 }
 
-- 
1.7.9.5

--
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/

[PATCH 5/7] vmscan: change type of vm_total_pages to unsigned long

[Zhang Yanfei]

This variable is calculated from nr_free_pagecache_pages so
change its type to unsigned long.

Signed-off-by: Zhang Yanfei 
---
 include/linux/swap.h |2 +-
 mm/vmscan.c  |2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/include/linux/swap.h b/include/linux/swap.h
index c238323..fa1f686 100644
--- a/include/linux/swap.h
+++ b/include/linux/swap.h
@@ -266,7 +266,7 @@ extern unsigned long mem_cgroup_shrink_node_zone(struct 
mem_cgroup *mem,
 extern unsigned long shrink_all_memory(unsigned long nr_pages);
 extern int vm_swappiness;
 extern int remove_mapping(struct address_space *mapping, struct page *page);
-extern long vm_total_pages;
+extern unsigned long vm_total_pages;
 
 #ifdef CONFIG_NUMA
 extern int zone_reclaim_mode;
diff --git a/mm/vmscan.c b/mm/vmscan.c
index 196709f..5344a5b 100644
--- a/mm/vmscan.c
+++ b/mm/vmscan.c
@@ -128,7 +128,7 @@ struct scan_control {
  * From 0 .. 100.  Higher means more swappy.
  */
 int vm_swappiness = 60;
-long vm_total_pages;   /* The total number of pages which the VM controls */
+unsigned long vm_total_pages;  /* The total number of pages which the VM 
controls */
 
 static LIST_HEAD(shrinker_list);
 static DECLARE_RWSEM(shrinker_rwsem);
-- 
1.7.1
--
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/

RE: [GIT PULL] ARM part of USB patches

[Hiremath, Vaibhav]

On Tue, Feb 05, 2013 at 23:49:47, Tony Lindgren wrote:
> * gre...@linuxfoundation.org  [130205 09:28]:
> > On Tue, Feb 05, 2013 at 08:56:13PM +0530, kishon wrote:
> > > Hi Tony, Greg,
> > > 
> > > On Tuesday 05 February 2013 08:54 PM, kishon wrote:
> > > >Hi Tony,
> > > >
> > > >As discussed, I'm sending a pull request for the arch/arm part of my USB
> > > >patches. These patches are necessary to get MUSB functional in both dt
> > > >and non-dt boot. Also added dt data for dwc3 present in OMAP. This patch
> > > >series *depends* on some of the patches which are merged in usb-next.
> > > 
> > > This patch series should go in only after USB. Or else it will break
> > > compilation.
> > 
> > Then it probably should go through the USB tree, right?  We don't want
> > to break bisectability.
> 
> Looks like this branch needs to be based on at least 01658f0f (usb: phy:
> add a new driver for usb part of control module) to compile. Probably
> needs other USB patches too to make sense.
> 
> This branch has a high likelihood of conflicting with .dts files, so
> Kishon, I suggest you do two branches:
> 
> 1. A branch for Greg based on top of the USB changes
> 
>This branch should contain:
> 
>ARM: OMAP4: remove control module address space from PHY and OTG
>ARM: OMAP: devices: create device for usb part of control module
>ARM: OMAP2: MUSB: Specify omap4 has mailbox
>ARM: OMAP: USB: Add phy binding information
> 
>Naturally please make sure they compile and boot on their own.
>Looks like this will only cause few trivial include merge conflicts
>with what I have queued up.
> 
>You can add my Acked-by: Tony Lindgren  for those.
> 
> 2. A branch for Benoit based on v3.8-rc6
> 
>That branch should contain all the .dts changes as those will
>most likely cause nasty merge conflicts otherwise with what
>Benoit has queued up.
> 

Tony/Benoit,

There are few AM33xx DTS patches pending from long time, how do you want to 
take it forward? You want me to put it into one branch and share? OR just 
provide the list of all patches to you?

Thanks,
Vaibhav
> Regards,
> 
> Tony
> ___
> devicetree-discuss mailing list
> devicetree-disc...@lists.ozlabs.org
> https://lists.ozlabs.org/listinfo/devicetree-discuss
> 

--
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/

[PATCH 1/7] mm: fix return type for functions nr_free_*_pages

[Zhang Yanfei]

Currently, the amount of RAM that functions nr_free_*_pages return
is held in unsigned int. But in machines with big memory (exceeding
16TB), the amount may be incorrect because of overflow, so fix it.

Signed-off-by: Zhang Yanfei 
---
 include/linux/swap.h |4 ++--
 mm/page_alloc.c  |8 
 2 files changed, 6 insertions(+), 6 deletions(-)

diff --git a/include/linux/swap.h b/include/linux/swap.h
index 68df9c1..c238323 100644
--- a/include/linux/swap.h
+++ b/include/linux/swap.h
@@ -216,8 +216,8 @@ struct swap_list_t {
 extern unsigned long totalram_pages;
 extern unsigned long totalreserve_pages;
 extern unsigned long dirty_balance_reserve;
-extern unsigned int nr_free_buffer_pages(void);
-extern unsigned int nr_free_pagecache_pages(void);
+extern unsigned long nr_free_buffer_pages(void);
+extern unsigned long nr_free_pagecache_pages(void);
 
 /* Definition of global_page_state not available yet */
 #define nr_free_pages() global_page_state(NR_FREE_PAGES)
diff --git a/mm/page_alloc.c b/mm/page_alloc.c
index df2022f..4acf733 100644
--- a/mm/page_alloc.c
+++ b/mm/page_alloc.c
@@ -2785,13 +2785,13 @@ void free_pages_exact(void *virt, size_t size)
 }
 EXPORT_SYMBOL(free_pages_exact);
 
-static unsigned int nr_free_zone_pages(int offset)
+static unsigned long nr_free_zone_pages(int offset)
 {
struct zoneref *z;
struct zone *zone;
 
/* Just pick one node, since fallback list is circular */
-   unsigned int sum = 0;
+   unsigned long sum = 0;
 
struct zonelist *zonelist = node_zonelist(numa_node_id(), GFP_KERNEL);
 
@@ -2808,7 +2808,7 @@ static unsigned int nr_free_zone_pages(int offset)
 /*
  * Amount of free RAM allocatable within ZONE_DMA and ZONE_NORMAL
  */
-unsigned int nr_free_buffer_pages(void)
+unsigned long nr_free_buffer_pages(void)
 {
return nr_free_zone_pages(gfp_zone(GFP_USER));
 }
@@ -2817,7 +2817,7 @@ EXPORT_SYMBOL_GPL(nr_free_buffer_pages);
 /*
  * Amount of free RAM allocatable within all zones
  */
-unsigned int nr_free_pagecache_pages(void)
+unsigned long nr_free_pagecache_pages(void)
 {
return nr_free_zone_pages(gfp_zone(GFP_HIGHUSER_MOVABLE));
 }
-- 
1.7.1

--
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/

[PATCH 0/7] mm: fix types for some functions and variables in case of overflow

[Zhang Yanfei]

Currently, the amount of RAM that functions nr_free_*_pages return
is held in unsigned int. But in machines with big memory (exceeding
16TB), the amount may be incorrect because of overflow, so fix this
problem.

Also, fix the types of variables that is related to nr_free_*_pages.
For these variables are placed in several subsystems, I may be incorrectly
fix them, if there is any problem with the fix, please correct me.

Zhang Yanfei (7):
  mm: fix return type for functions nr_free_*_pages
  ia64: use %ld to print pages calculated in nr_free_buffer_pages
  fs/buffer.c: change type of max_buffer_heads to unsigned long
  fs/nfsd: change type of max_delegations, nfsd_drc_max_mem and
nfsd_drc_mem_used
  vmscan: change type of vm_total_pages to unsigned long
  net: change type of netns_ipvs->sysctl_sync_qlen_max
  net: change type of virtio_chan->p9_max_pages

 arch/ia64/mm/contig.c|2 +-
 arch/ia64/mm/discontig.c |2 +-
 fs/buffer.c  |4 ++--
 fs/nfsd/nfs4state.c  |6 +++---
 fs/nfsd/nfsd.h   |6 +++---
 fs/nfsd/nfssvc.c |6 +++---
 include/linux/swap.h |6 +++---
 include/net/ip_vs.h  |2 +-
 mm/page_alloc.c  |8 
 mm/vmscan.c  |2 +-
 net/9p/trans_virtio.c|2 +-
 11 files changed, 23 insertions(+), 23 deletions(-)

--
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/

[PATCH] X.509: Support parse long form of length octets in Authority Key Identifier

[Lee, Chun-Yi]

Per X.509 spec in 4.2.1.1 section, the structure of Authority Key
Identifier Exception is:

   AuthorityKeyIdentifier ::= SEQUENCE {
  keyIdentifier [0] KeyIdentifier   OPTIONAL,
  authorityCertIssuer   [1] GeneralNamesOPTIONAL,
  authorityCertSerialNumber [2] CertificateSerialNumber OPTIONAL  }

   KeyIdentifier ::= OCTET STRING

When a certificate also provides
authorityCertIssuer and authorityCertSerialNumber then the length of
AuthorityKeyIdentifier SEQUENCE is likely to long form format.
e.g.
   The example certificate demos/tunala/A-server.pem in openssl source:

X509v3 Authority Key Identifier:
keyid:49:FB:45:72:12:C4:CC:E1:45:A1:D3:08:9E:95:C4:2C:6D:55:3F:17
DirName:/C=NZ/L=Wellington/O=Really Irresponsible Authorisation Authority 
(RIAA)/OU=Cert-stamping/CN=Jackov al-Trades/emailAddress=none@fake.domain
serial:00

Current parsing rule of OID_authorityKeyIdentifier only take care the
short form format, it causes load certificate to modsign_keyring fail:

[   12.061147] X.509: Extension: 47
[   12.075121] MODSIGN: Problem loading in-kernel X.509 certificate (-74)

So, this patch add the parsing rule for support long form format against
Authority Key Identifier.

Cc: David Howells 
Cc: Rusty Russell 
Cc: Josh Boyer 
Cc: Randy Dunlap 
Cc: Herbert Xu 
Cc: "David S. Miller" 
Signed-off-by: Lee, Chun-Yi 
---
 crypto/asymmetric_keys/x509_cert_parser.c |   56 
 1 files changed, 48 insertions(+), 8 deletions(-)

diff --git a/crypto/asymmetric_keys/x509_cert_parser.c 
b/crypto/asymmetric_keys/x509_cert_parser.c
index 7fabc4c..7f6a152 100644
--- a/crypto/asymmetric_keys/x509_cert_parser.c
+++ b/crypto/asymmetric_keys/x509_cert_parser.c
@@ -373,6 +373,9 @@ int rsa_extract_mpi(void *context, size_t hdrlen,
return 0;
 }
 
+/* The keyIdentifier in AuthorityKeyIdentifier SEQUENCE is tag(CONT,PRIM,0) */
+#define SEQ_TAG_KEYID (ASN1_CONT << 6)
+
 /*
  * Process certificate extensions that are used to qualify the certificate.
  */
@@ -407,21 +410,58 @@ int x509_process_extension(void *context, size_t hdrlen,
}
 
if (ctx->last_oid == OID_authorityKeyIdentifier) {
+   size_t key_len;
+
/* Get hold of the CA key fingerprint */
if (vlen < 5)
return -EBADMSG;
-   if (v[0] != (ASN1_SEQ | (ASN1_CONS << 5)) ||
-   v[1] != vlen - 2 ||
-   v[2] != (ASN1_CONT << 6) ||
-   v[3] != vlen - 4)
+
+   /* Authority Key Identifier must be a Constructed SEQUENCE */
+   if (v[0] != (ASN1_SEQ | (ASN1_CONS << 5)))
return -EBADMSG;
-   v += 4;
-   vlen -= 4;
 
-   f = kmalloc(vlen * 2 + 1, GFP_KERNEL);
+   /* Authority Key Identifier is not indefinite length */
+   if (unlikely(vlen == ASN1_INDEFINITE_LENGTH))
+   return -EBADMSG;
+
+   /* Short Form length */
+   if (vlen <= 127) {
+
+   if (v[1] != vlen - 2 ||
+   v[2] != SEQ_TAG_KEYID ||
+   v[3] != vlen - 4)
+   return -EBADMSG;
+
+   v += 4;
+   key_len = v[3];
+   } else {
+   /* Long Form length */
+   size_t seq_len = 0;
+   int sub = v[1] - 0x80;
+
+   if (sub > 2)
+   return -EBADMSG;
+
+   /* calculate the length from subsequent octet */
+   for (i = 0; i < sub; i++) {
+   seq_len <<= 8;
+   seq_len |= v[2 + i];
+   }
+
+   /* check vlen should not less then length of keyid */
+   if (seq_len != vlen - 2 - sub ||
+   v[2 + sub] != SEQ_TAG_KEYID ||
+   v[3 + sub] > vlen - 4 - sub)
+   return -EBADMSG;
+
+   v += (4 + sub);
+   key_len = v[3 + sub];
+   }
+
+   f = kmalloc(key_len * 2 + 1, GFP_KERNEL);
if (!f)
return -ENOMEM;
-   for (i = 0; i < vlen; i++)
+   for (i = 0; i < key_len; i++)
sprintf(f + i * 2, "%02x", v[i]);
pr_debug("authority   %s\n", f);
ctx->cert->authority = f;
-- 
1.6.4.2

--
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/

Re: [patch v4 0/18] sched: simplified fork, release load avg and power awareness scheduling

[Alex Shi]

BTW,

Since numa balance scheduling is also a kind of cpu locality policy, it
is natural compatible with power aware scheduling.

The v2/v3 of this patch had developed on tip/master, testing show above
2 scheduling policy work together well.

-- 
Thanks Alex
--
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/

Re: [PATCH v5 3/3] ARM: mm: use static_vm for managing static mapped areas

[Joonsoo Kim]

On Wed, Feb 06, 2013 at 11:07:07AM +0900, Joonsoo Kim wrote:
> Hello, Rob.
> 
> On Tue, Feb 05, 2013 at 01:12:51PM -0600, Rob Herring wrote:
> > On 02/05/2013 12:13 PM, Nicolas Pitre wrote:
> > > On Tue, 5 Feb 2013, Rob Herring wrote:
> > > 
> > >> On 02/04/2013 10:44 PM, Nicolas Pitre wrote:
> > >>> On Tue, 5 Feb 2013, Joonsoo Kim wrote:
> > >>>
> >  A static mapped area is ARM-specific, so it is better not to use
> >  generic vmalloc data structure, that is, vmlist and vmlist_lock
> >  for managing static mapped area. And it causes some needless overhead 
> >  and
> >  reducing this overhead is better idea.
> > 
> >  Now, we have newly introduced static_vm infrastructure.
> >  With it, we don't need to iterate all mapped areas. Instead, we just
> >  iterate static mapped areas. It helps to reduce an overhead of finding
> >  matched area. And architecture dependency on vmalloc layer is removed,
> >  so it will help to maintainability for vmalloc layer.
> > 
> >  Signed-off-by: Joonsoo Kim 
> > >>
> > >> [snip]
> > >>
> >  @@ -859,17 +864,12 @@ static void __init pci_reserve_io(void)
> >   {
> > struct vm_struct *vm;
> > unsigned long addr;
> >  +  struct static_vm *svm;
> >   
> >  -  /* we're still single threaded hence no lock needed here */
> >  -  for (vm = vmlist; vm; vm = vm->next) {
> >  -  if (!(vm->flags & VM_ARM_STATIC_MAPPING))
> >  -  continue;
> >  -  addr = (unsigned long)vm->addr;
> >  -  addr &= ~(SZ_2M - 1);
> >  -  if (addr == PCI_IO_VIRT_BASE)
> >  -  return;
> >  +  svm = find_static_vm_vaddr((void *)PCI_IO_VIRT_BASE);
> >  +  if (svm)
> >  +  return;
> > 
> >  -  }
> >   
> > vm_reserve_area_early(PCI_IO_VIRT_BASE, SZ_2M, pci_reserve_io);
> >   }
> > >>>
> > >>> The replacement code is not equivalent.  I can't recall why the 
> > >>> original 
> > >>> is as it is, but it doesn't look right to me.  The 2MB round down 
> > >>> certainly looks suspicious.
> > >>
> > >> The PCI mapping is at a fixed, aligned 2MB mapping. If we find any
> > >> virtual address within that region already mapped, it is an error.
> > > Ah, OK.  This wasn't clear looking at the code.
> > >> We probably should have had a WARN here.
> > > 
> > > Indeed.
> > > 
> 
> Okay.
> I should fix it to find any mapping within PCI reserved region.

Ah...
Above comment is my mistake.

If there is a region already mapped within PCI reserved region and
it is not found by find_static_vm_vaddr(), vm_area_add_early() hit BUG_ON().
So, to leave find_static_vm_vaddr() is safe.

> But, I think that it is not an error.
> Now, I see your original commit 'c2794437091a4fda72c4a4f3567dd728dcc0c3c9'
> and find below message.
> 
> "Platforms which need early i/o mapping (e.g. for vga console) can call
> pci_map_io_early in their .map_io function."
> 
> Therfore, for some platform, it is possible that there is a mapping within
> PCI reserved range.
> 
> So, I will not add WARN here.
> 
> I will fix and re-send v6 with your ACK.
> 
> Thanks for review.
> 
> > >>>
> > >>> The replacement code should be better.  However I'd like you to get an 
> > >>> ACK from Rob Herring as well for this patch.
> > >>
> > >> It doesn't appear to me the above case is handled. The virt addr is
> > >> checked whether it is within an existing mapping, but not whether the
> > >> new mapping would overlap an existing mapping. It would be good to check
> > >> for this generically rather than specifically for the PCI i/o mapping.
> > > 
> > > Agreed.  However that is checked already in vm_area_add_early().  
> > > Therefore the overlap test here is redundant.
> > 
> > Ah, right. In that case:
> > 
> > Acked-by: Rob Herring 
> > 
> > Rob
> > 
> > --
> > 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/
> --
> 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/
--
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/

Re: [RFC 2/2] initramfs with digital signature protection

[H. Peter Anvin]

On 02/05/2013 02:09 PM, Kasatkin, Dmitry wrote:


It should not be like that. Actually when pre-init exits, cleanup code
umount tmpfs, which in turn cleanups the RAM.



It doesn't quite... the rootfs is permanent.  This is also only one 
usage mode: there are quite a few Linux systems running directly out of 
initramfs.


-hpa


--
H. Peter Anvin, Intel Open Source Technology Center
I work for Intel.  I don't speak on their behalf.

--
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/

Re: [PATCH 00/11] perf tool: Add PERF_SAMPLE_READ sample read support

[Namhyung Kim]

On Mon,  4 Feb 2013 13:32:54 +0100, Jiri Olsa wrote:
> hi,
> adding support to read sample values through the PERF_SAMPLE_READ
> sample type. It's now possible to specify 'S' modifier for an event
> and get its sample value by PERF_SAMPLE_READ.
>
> For group the 'S' modifier will enable sampling only for the leader
> and read all the group member by PERF_SAMPLE_READ smple type with
> PERF_FORMAT_GROUP read format.
>
> This was first introduced in here:
> https://lkml.org/lkml/2012/10/20/75
>
> Example:
>
>   $ perf record -e '{cycles,cache-misses}:S' ls
>   ...
>   $ perf report --group --show-total-period --stdio
>   ...
>   # Samples: 36  of event 'anon group { cycles, cache-misses }'
>   # Event count (approx.): 12585593
>   #
>   # OverheadPeriod  Command  Shared Object
>   Symbol
>   #     ...  .  
> ..
>   #
>   19.92%   1.20%   2505936  31   ls  [kernel.kallsyms]  
> [k] mark_held_locks
>   13.74%   0.47%   1729327  12   ls  [kernel.kallsyms]  
> [k] sched_clock_local
>   13.64%  23.72%   1716147 612   ls  ld-2.14.90.so  
> [.] check_match.10805
>   13.12%  23.22%   1650778 599   ls  libc-2.14.90.so
> [.] _nl_intern_locale_data
>   11.24%  29.19%   1414554 753   ls  [kernel.kallsyms]  
> [k] sched_clock_cpu
>8.50%   0.35%   1070150   9   ls  [kernel.kallsyms]  
> [k] check_chain_key
>   ...
>
>
> The patchset is based on following fix:
> http://lkml.org/lkml/2013/2/4/122
>
> and is available also at:
> git://git.kernel.org/pub/scm/linux/kernel/git/jolsa/linux.git
> perf/group6

For the whole series:

  Acked-by: Namhyung Kim 

Thanks,
Namhyung
--
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/

Re: [PATCH] f2fs: fix to name f2fs GC task as per partition instead of per device

[Namjae Jeon]

2013/2/6, Jaegeuk Kim :
> Hi,
>
> How about this?
>
> 2013-02-05 (화), 23:24 +0900, Namjae Jeon:
>> From: Namjae Jeon 
>>
>> After the commit 2184ad190a79ae2b40b5f5db1fbde5c22db6d310, it allowed
>> for naming GC threads based on the device.
>> i.e., if we have F2FS formatted partition in different devices - we will
>> have their GC thread names after the device. But, when we have a case
>> like
>> 2 or more partitions on the same device having F2FS filesystem.
>> In that case we are not able to differentiate between the GC threads.
>> So, to differentiate at all possible levels we can use the major/minor of
>> the device to have unique identification in the name.
>>
>> Before patch:
>> root  9726  0.0  0.0  0  0 ?  S  14:32   0:00 [f2fs_gc-8:48]
>> root  9736  0.0  0.0  0  0 ?  S  14:32   0:00 [f2fs_gc-8:16]
>> root  9892  0.0  0.0  0  0 ?  S  14:33   0:00 [f2fs_gc-8:32]
>> root  9907  0.0  0.0  0  0 ?  S  14:34   0:00 [f2fs_gc-8:32]
>>
>> After Patch:
>> root  16756  0.0  0.0  0  0 ?  S  14:57   0:00 [f2fs_gc-8:18]
>> root  16765  0.0  0.0  0  0 ?  S  14:57   0:00 [f2fs_gc-8:19]
>> root  16806  0.0  0.0  0  0 ?  S  14:58   0:00 [f2fs_gc-8:34]
>> root  16817  0.0  0.0  0  0 ?  S  14:58   0:00 [f2fs_gc-8:52]
>>
>
> root  16756  0.0  0.0  0  0 ?  S  14:57   0:00 [f2fs_gc-sdb1]
> root  16765  0.0  0.0  0  0 ?  S  14:57   0:00 [f2fs_gc-sdb2]
>
> IMO, it would be better to describe like this.
> We can simply use bdevname(bdev, name), so if no objection, I'll rebase
> this patch with this.
> Please, give me your opinion.
> Thanks,
Hi Jaegeuk.

Although it is good opinion to have user friendly names in the task
list, but we cannot have such names.

Because, even though bdevname() will provide the correct string. But
there is a limitation from the task struct command length.
The Task struct allows for the name to be maximum of ‘16’ characters in length.
char comm[TASK_COMM_LEN];

/* Task command name length */
#define TASK_COMM_LEN 16
So, the task name would be truncated to ‘16’ characters.

In case like for MMC partitions where partition name can be like:
mmcblk0p18, the name would become f2fs_gc-mmcblk0p18 -> this will be
truncate to “f2fs_gc-mmcblk0p”

Let me know your opinion.
Thanks.
>
>
>> Signed-off-by: Namjae Jeon 
>> Signed-off-by: Amit Sahrawat 
>> ---
>>  fs/f2fs/gc.c |3 ++-
>>  1 file changed, 2 insertions(+), 1 deletion(-)
>>
>> diff --git a/fs/f2fs/gc.c b/fs/f2fs/gc.c
>> index 742135a..b0c1f8c 100644
>> --- a/fs/f2fs/gc.c
>> +++ b/fs/f2fs/gc.c
>> @@ -91,6 +91,7 @@ static int gc_thread_func(void *data)
>>  int start_gc_thread(struct f2fs_sb_info *sbi)
>>  {
>>  struct f2fs_gc_kthread *gc_th;
>> +dev_t dev = sbi->sb->s_bdev->bd_dev;
>>
>>  if (!test_opt(sbi, BG_GC))
>>  return 0;
>> @@ -101,7 +102,7 @@ int start_gc_thread(struct f2fs_sb_info *sbi)
>>  sbi->gc_thread = gc_th;
>>  init_waitqueue_head(>gc_thread->gc_wait_queue_head);
>>  sbi->gc_thread->f2fs_gc_task = kthread_run(gc_thread_func, sbi,
>> -"f2fs_gc-%s", dev_name(sbi->sb->s_bdi->dev));
>> +"f2fs_gc-%u:%u", MAJOR(dev), MINOR(dev));
>>  if (IS_ERR(gc_th->f2fs_gc_task)) {
>>  kfree(gc_th);
>>  sbi->gc_thread = NULL;
>
> --
> Jaegeuk Kim
> Samsung
>
--
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/

RE: [PATCH V2 1/6] pinctrl: pinctrl-single: use arch_initcall and module_exit

[Vishwanathrao Badarkhe, Manish]

Hi Linus

On Tue, Feb 05, 2013 at 18:30:48, Linus Walleij wrote:
> On Tue, Feb 5, 2013 at 7:36 AM, Vishwanathrao Badarkhe, Manish 
>  wrote:
> 
> > I made following changes, in order to update "dip->p" pointer with 
> > correct value:
> >
> > -   if (!dpi->p) {
> > +   if (IS_ERR_OR_NULL(dpi->p)) {
> > dpi->p = devm_pinctrl_get(dev);
> > -   if (IS_ERR_OR_NULL(dpi->p)) {
> > -   int ret = PTR_ERR(dpi->p);
> > -
> > -   dev_dbg(dev, "no pinctrl handle\n");
> > -   /* Only return deferrals */
> > -   if (ret == -EPROBE_DEFER)
> > -   return ret;
> > -   return 0;
> > -   }
> > +   ret = PTR_ERR(dpi->p);
> > +   dev_dbg(dev, "no pinctrl handle\n");
> > +   /* Only return deferrals */
> > +   if (ret == -EPROBE_DEFER)
> > +   return ret;
> > +   return 0;
> 
> This is based on some old code that I wrote ages ago. Check the pinctrl tree 
> or linux-next for the latest core pin grabbing code.
> Use that instead.

Thanks for your reply.
I have checked with your latest changes regarding pinctrl 
in linux-next tree and these changes are working fine for me.

Regards
Manish Badarkhe
--
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/

Re: [PATCH 5/9] gpiolib: use gpio_chips list in gpiochip_find_base

[Alex Courbot]

On 02/06/2013 02:21 AM, Linus Walleij wrote:

This looks like it is preserving this userspace-sensitive semantic
so that dynamically added chips will still get the same assigned
numbers.


It does (it should, at least), the assigned ranges should be strictly 
identical to the previous version. While testing I also made sure all 
chips had the same GPIO range.



But I want some guarantees, so state clearly in the commit
that any dynamically assigned chip will get the same base
address after this change as it got before it, and please take
this opportunity to add a comment stating that this search
method is vital for userspace ABIs, and must be preserved.


Done. I will take the blame if something goes wrong. :)

Thanks,
Alex.


--
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/

Re: [ 105/128] efi: Make efi_enabled a function to query EFI facilities

[Ben Hutchings]

On Mon, 2013-02-04 at 10:20 -0800, Greg KH wrote:
> On Mon, Feb 04, 2013 at 04:44:25PM +, Matt Fleming wrote:
> > On Sun, 2013-02-03 at 16:15 +0100, Ben Hutchings wrote:
> > > As you can see this needed quite a lot of work to backport, and I
> > > haven't been able to test it yet.  So I would particularly appreciate
> > > careful review of this.
> > 
> > Everything looks fine to me but I haven't actually booted with these
> > changes.
> 
> I didn't backport this to the 3.4 kernel, as I didn't think it really
> was necessary, but now that Ben did all of the hard work, I'll see if
> his version applies there, as it would be good to solve this issue for
> that kernel release.  Thanks for verifying that this work at least looks
> sane.

No, my backporting work for 3.2 is not applicable and not needed on 3.4.
I think you just need to adjust context in arch/x86/kernel/setup.c and
init/main.c.

Ben.

-- 
Ben Hutchings
Everything should be made as simple as possible, but not simpler.
   - Albert Einstein


signature.asc
Description: This is a digitally signed message part

linux-next: manual merge of the kvm tree with the arm tree

[Stephen Rothwell]

Hi all,

Today's linux-next merge of the kvm tree got a conflict in
include/uapi/linux/kvm.h between commit aa024c2f35a0 ("KVM: ARM: Power
State Coordination Interface implementation") from the arm tree and
commits fa6b7fe9928d ("KVM: s390: Add support for channel I/O
instructions") and 1c810636556c ("KVM: PPC: BookE: Implement EPR exit")
from the kvm tree.

I fixed it up (see below) and can carry the fix as necessary (no action
is required).

-- 
Cheers,
Stephen Rothwells...@canb.auug.org.au

diff --cc include/uapi/linux/kvm.h
index 7f2360a,9a2db57..000
--- a/include/uapi/linux/kvm.h
+++ b/include/uapi/linux/kvm.h
@@@ -636,7 -660,8 +661,9 @@@ struct kvm_ppc_smmu_info 
  #define KVM_CAP_IRQFD_RESAMPLE 82
  #define KVM_CAP_PPC_BOOKE_WATCHDOG 83
  #define KVM_CAP_PPC_HTAB_FD 84
+ #define KVM_CAP_S390_CSS_SUPPORT 85
+ #define KVM_CAP_PPC_EPR 86
 +#define KVM_CAP_ARM_PSCI 87
  
  #ifdef KVM_CAP_IRQ_ROUTING
  


pgpUfJumKIJzf.pgp
Description: PGP signature

Re: [PATCH] f2fs: fix to name f2fs GC task as per partition instead of per device

[Jaegeuk Kim]

Hi,

How about this?

2013-02-05 (화), 23:24 +0900, Namjae Jeon:
> From: Namjae Jeon 
> 
> After the commit 2184ad190a79ae2b40b5f5db1fbde5c22db6d310, it allowed
> for naming GC threads based on the device.
> i.e., if we have F2FS formatted partition in different devices - we will
> have their GC thread names after the device. But, when we have a case like
> 2 or more partitions on the same device having F2FS filesystem.
> In that case we are not able to differentiate between the GC threads.
> So, to differentiate at all possible levels we can use the major/minor of
> the device to have unique identification in the name.
> 
> Before patch:
> root  9726  0.0  0.0  0  0 ?  S  14:32   0:00 [f2fs_gc-8:48]
> root  9736  0.0  0.0  0  0 ?  S  14:32   0:00 [f2fs_gc-8:16]
> root  9892  0.0  0.0  0  0 ?  S  14:33   0:00 [f2fs_gc-8:32]
> root  9907  0.0  0.0  0  0 ?  S  14:34   0:00 [f2fs_gc-8:32]
> 
> After Patch:
> root  16756  0.0  0.0  0  0 ?  S  14:57   0:00 [f2fs_gc-8:18]
> root  16765  0.0  0.0  0  0 ?  S  14:57   0:00 [f2fs_gc-8:19]
> root  16806  0.0  0.0  0  0 ?  S  14:58   0:00 [f2fs_gc-8:34]
> root  16817  0.0  0.0  0  0 ?  S  14:58   0:00 [f2fs_gc-8:52]
> 

root  16756  0.0  0.0  0  0 ?  S  14:57   0:00 [f2fs_gc-sdb1]
root  16765  0.0  0.0  0  0 ?  S  14:57   0:00 [f2fs_gc-sdb2]

IMO, it would be better to describe like this.
We can simply use bdevname(bdev, name), so if no objection, I'll rebase
this patch with this.
Please, give me your opinion.
Thanks,


> Signed-off-by: Namjae Jeon 
> Signed-off-by: Amit Sahrawat 
> ---
>  fs/f2fs/gc.c |3 ++-
>  1 file changed, 2 insertions(+), 1 deletion(-)
> 
> diff --git a/fs/f2fs/gc.c b/fs/f2fs/gc.c
> index 742135a..b0c1f8c 100644
> --- a/fs/f2fs/gc.c
> +++ b/fs/f2fs/gc.c
> @@ -91,6 +91,7 @@ static int gc_thread_func(void *data)
>  int start_gc_thread(struct f2fs_sb_info *sbi)
>  {
>   struct f2fs_gc_kthread *gc_th;
> + dev_t dev = sbi->sb->s_bdev->bd_dev;
>  
>   if (!test_opt(sbi, BG_GC))
>   return 0;
> @@ -101,7 +102,7 @@ int start_gc_thread(struct f2fs_sb_info *sbi)
>   sbi->gc_thread = gc_th;
>   init_waitqueue_head(>gc_thread->gc_wait_queue_head);
>   sbi->gc_thread->f2fs_gc_task = kthread_run(gc_thread_func, sbi,
> - "f2fs_gc-%s", dev_name(sbi->sb->s_bdi->dev));
> + "f2fs_gc-%u:%u", MAJOR(dev), MINOR(dev));
>   if (IS_ERR(gc_th->f2fs_gc_task)) {
>   kfree(gc_th);
>   sbi->gc_thread = NULL;

-- 
Jaegeuk Kim
Samsung


signature.asc
Description: This is a digitally signed message part

Re: [PATCH 01/11] perf ui/hist: Add support to display whole group data for raw columns

[Namhyung Kim]

Hi Jiri,

On Mon,  4 Feb 2013 13:32:55 +0100, Jiri Olsa wrote:
> Currently we don't display group members' values for raw
> columns like 'Samples' and 'Period' when in group report
> mode.

Oops, it was lost during the rework.  Thanks for fixing this.

Thanks,
Namhyung
--
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/

Re: Question on lockdep and MAX_LOCK_DEPTH

[Steven Rostedt]

On Tue, 2013-02-05 at 19:30 -0800, Ben Greear wrote:

> It's huge, so here's a link:
> 
> http://www.candelatech.com/~greearb/debug.tgz
> 

The trace shows that __netif_receive_skb() is grabbing an
rcu_read_lock() but never releasing it. But I don't see any possible way
that can be true in the code.

Can you apply the following patch and run the trace again. I'd like to
see if the code is going in the path I expect it is.

Thanks,

-- Steve

diff --git a/net/core/dev.c b/net/core/dev.c
index e5942bf..5b12ff5 100644
--- a/net/core/dev.c
+++ b/net/core/dev.c
@@ -3260,6 +3260,7 @@ static int __netif_receive_skb(struct sk_buff *skb)
pt_prev = NULL;
 
rcu_read_lock();
+   trace_printk("lock\n");
 
 another_round:
skb->skb_iif = skb->dev->ifindex;
@@ -3314,6 +3315,7 @@ ncls:
}
 
rx_handler = rcu_dereference(skb->dev->rx_handler);
+   trace_printk("handler %pS\n", rx_handler);
if (rx_handler) {
if (pt_prev) {
ret = deliver_skb(skb, pt_prev, orig_dev);
@@ -3359,6 +3361,7 @@ ncls:
} else {
 drop:
atomic_long_inc(>dev->rx_dropped);
+   trace_printk("kfree\n");
kfree_skb(skb);
/* Jamal, now you will not able to escape explaining
 * me how you were going to use this. :-)
@@ -3367,6 +3370,7 @@ drop:
}
 
 unlock:
+   trace_printk("unlock\n");
rcu_read_unlock();
 out:
tsk_restore_flags(current, pflags, PF_MEMALLOC);


--
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/

Re: Question on lockdep and MAX_LOCK_DEPTH

[Steven Rostedt]

On Tue, Feb 05, 2013 at 05:10:37PM -0800, Ben Greear wrote:
> 
> 
> ===
> [ INFO: suspicious RCU usage. ]
> 3.7.6+ #4 Tainted: G C O
> ---
> /home/greearb/git/linux-3.7.dev.y/kernel/rcutree.c:360 Illegal idle entry in 
> RCU read-side critical section.!
> 
> other info that might help us debug this:
> 
> 
> RCU used illegally from idle CPU!
> rcu_scheduler_active = 1, debug_locks = 1
> RCU used illegally from extended quiescent state!
> 1 lock held by swapper/1/0:
>  #0:  (rcu_read_lock){.+.+..}, at: [] rcu_read_lock+0x0/0x6f
> 
> stack backtrace:
> Pid: 0, comm: swapper/1 Tainted: G C O 3.7.6+ #4
> Call Trace:
>[] lockdep_rcu_suspicious+0xfc/0x105
>  [] rcu_eqs_enter_common+0xef/0x178
>  [] rcu_irq_exit+0x7f/0xb0
>  [] irq_exit+0xc0/0xcc
>  [] do_IRQ+0x97/0xae
>  [] common_interrupt+0x72/0x72
>[] ? mwait_idle+0x77/0x9f
>  [] ? mwait_idle+0x6e/0x9f
>  [] cpu_idle+0x68/0xbc
>  [] start_secondary+0x1fc/0x203

BTW, did the above error only happen when you added the dump of the
locks, or was it always there? Is this the bug you were trying to debug?

-- Steve

--
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/

Re: [PATCH linux-next] x86/mm: Fix compile warning in remove_pagetable()

[Yinghai Lu]

On Tue, Feb 5, 2013 at 6:52 PM, Shuah Khan  wrote:
> Fix the following compile warning in remove_pagetable():
> arch/x86/mm/init_64.c: In function ‘remove_pagetable’:
> arch/x86/mm/init_64.c:996:9: warning: ‘next’ may be used uninitialized in 
> this function [-Wuninitialized]
>
>
> Signed-off-by: Shuah Khan 
> ---
>  arch/x86/mm/init_64.c |2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/arch/x86/mm/init_64.c b/arch/x86/mm/init_64.c
> index 67bad4b..ed78400 100644
> --- a/arch/x86/mm/init_64.c
> +++ b/arch/x86/mm/init_64.c
> @@ -987,7 +987,7 @@ remove_pud_table(pud_t *pud_start, unsigned long addr, 
> unsigned long end,
>  static void __meminit
>  remove_pagetable(unsigned long start, unsigned long end, bool direct)
>  {
> -   unsigned long next;
> +   unsigned long next = pgd_addr_end(start, end);
> pgd_t *pgd;
> pud_t *pud;
> bool pgd_changed = false;
> --
> 1.7.9.5

Andrew already had one fix-fix-...-fix for that.



On Mon, Feb 4, 2013 at 3:28 PM, Andrew Morton  wrote:
> On Mon, 4 Feb 2013 15:18:58 -0800
> Yinghai Lu  wrote:
>
>> On Mon, Feb 4, 2013 at 3:04 PM,   wrote:
>> >
>> > The patch titled
>> >  Subject: 
>> > memory-hotplug-common-apis-to-support-page-tables-hot-remove-fix-fix-fix-fix-fix-fix-fix
>> > has been added to the -mm tree.  Its filename is
>> >  
>> > memory-hotplug-common-apis-to-support-page-tables-hot-remove-fix-fix-fix-fix-fix-fix-fix.patch
>> >
>> > Before you just go and hit "reply", please:
>> >a) Consider who else should be cc'ed
>> >b) Prefer to cc a suitable mailing list as well
>> >c) Ideally: find the original patch on the mailing list and do a
>> >   reply-to-all to that, adding suitable additional cc's
>> >
>> > *** Remember to use Documentation/SubmitChecklist when testing your code 
>> > ***
>> >
>> > The -mm tree is included into linux-next and is updated
>> > there every 3-4 working days
>> >
>> > --
>> > From: Andrew Morton 
>> > Subject: 
>> > memory-hotplug-common-apis-to-support-page-tables-hot-remove-fix-fix-fix-fix-fix-fix-fix
>> >
>> > fix used-uninitialised bug
>> >
>> > Cc: Jiang Liu 
>> > Cc: Jianguo Wu 
>> > Cc: Kamezawa Hiroyuki 
>> > Cc: Lai Jiangshan 
>> > Cc: Tang Chen 
>> > Cc: Wen Congyang 
>> > Cc: Yasuaki Ishimatsu 
>> > Cc: Yinghai Lu 
>> > Signed-off-by: Andrew Morton 
>> > ---
>> >
>> >  arch/x86/mm/init_64.c |4 ++--
>> >  1 file changed, 2 insertions(+), 2 deletions(-)
>> >
>> > diff -puN 
>> > arch/x86/mm/init_64.c~memory-hotplug-common-apis-to-support-page-tables-hot-remove-fix-fix-fix-fix-fix-fix-fix
>> >  arch/x86/mm/init_64.c
>> > --- 
>> > a/arch/x86/mm/init_64.c~memory-hotplug-common-apis-to-support-page-tables-hot-remove-fix-fix-fix-fix-fix-fix-fix
>>
>> it is hard to count fix now!
>
> Yes, I think that's a world record ;)
>
>> > +++ a/arch/x86/mm/init_64.c
>> > @@ -993,12 +993,12 @@ remove_pagetable(unsigned long start, un
>> > bool pgd_changed = false;
>> >
>> > for (; start < end; start = next) {
>> > +   next = pgd_addr_end(start, end);
>> > +
>> > pgd = pgd_offset_k(start);
>> > if (!pgd_present(*pgd))
>> > continue;
>> >
>> > -   next = pgd_addr_end(start, end);
>> > -
>> > pud = (pud_t *)pgd_page_vaddr(*pgd);
>> > remove_pud_table(pud, start, next, direct);
>> > if (free_pud_table(pud, pgd))
>> > _
>>
>> It's a real bug fix.
>> Without this fix, it will get dead loop if there is 512G (and aligned)
>> memory hole in the range.
>
> OK, thanks.
--
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/

Re: [ 014/128] mwifiex: wakeup and stop multiple tx queues in net_device

[Ben Hutchings]

On Mon, 2013-02-04 at 16:36 -0800, Bing Zhao wrote:
> Hi Ben,
> 
> > On Mon, 2013-02-04 at 11:43 -0800, Bing Zhao wrote:
> > > Hi Ben,
> > >
> > > > 3.2-stable review patch.  If anyone has any objections, please let me 
> > > > know.
> > > >
> > > > --
> > > >
> > > > From: Avinash Patil 
> > > >
> > > > commit bbea3bc432dc5c08d09ca5c80afdd82515470688 upstream.
> > >
> > > This patch is not for stable kernel.
> > [...]
> > 
> > Right, I've managed to pick up 3 changes to mwifiex that it looks like I
> > shouldn't have included.  Firstly:
> > 
> > 9c969d8ccb1e mwifiex: check wait_event_interruptible return value
> > 
> > This had "3.6+" to the left of , whereas I
> > expect version qualifiers to be on the right.  So my import script just
> > put this in the queue without asking me to interpret the version
> > qualifier.  (I don't automate *that* because people use too wide a
> > variety of syntaxes.)
> 
> Sorry. From now on I will put version qualifiers on the right side of 
> 
> 
> > 
> > When trying to apply that, I found that it seemed to depend on these
> > two:
> > 
> > bbea3bc432dc mwifiex: wakeup and stop multiple tx queues in net_device
> 
> I'd rather classify this patch as an enhancement because the code change is 
> relatively large.
> To play it safe, let's drop this patch from -stable.
> 
> > b7097eb75fa1 mwifiex: handle association failure case correctly
> 
> This is a bug fix indeed.
> 
> > 
> > which also looked like they were important fixes.  Presumably I should
> > drop all of those?
> 
> Please drop bbea3bc432dc only.
> 
> I can resend a backport of "b7097eb75fa1 mwifiex: handle association failure 
> case correctly" for 3.2-stable.

Thanks, I've made these two changes.

Ben.

-- 
Ben Hutchings
Everything should be made as simple as possible, but not simpler.
   - Albert Einstein


signature.asc
Description: This is a digitally signed message part

Re: [ 000/128] 3.2.38-stable review

[Ben Hutchings]

On Mon, 2013-02-04 at 23:39 +0900, Satoru Takeuchi wrote:
> At Sun, 03 Feb 2013 15:46:44 +0100,
> Ben Hutchings wrote:
> > 
> > This is the start of the stable review cycle for the 3.2.38 release.
> > There are 128 patches in this series, which will be posted as responses
> > to this one.  If anyone has any issues with these being applied, please
> > let me know.
> > 
> > Responses should be made by Tue Feb  5 21:00:00 UTC 2013.
> > Anything received after that time might be too late.
> 
> This kernel can be built and boot without any problem.
> Building a kernel with this kernel also works fine.
> 
>  - Build Machine: debian wheezy x86_64
>CPU: Intel(R) Core(TM) i5-2400 CPU @ 3.10GHz x 4
>memory: 8GB
> 
>  - Test machine: debian wheezy x86_64(KVM guest on the Build Machine)
>vCPU: x2
>memory: 2GB
> 
> I reviewed the following patches and it looks good to me.
[...]

Thanks.

Ben.

-- 
Ben Hutchings
Everything should be made as simple as possible, but not simpler.
   - Albert Einstein


signature.asc
Description: This is a digitally signed message part

linux-next: manual merge of the spi tree with the sound-asoc tree

[Stephen Rothwell]

Hi Grant,

Today's linux-next merge of the spi tree got a conflict in
drivers/spi/spi-s3c64xx.c between commit b5be04d35dbb ("spi: s3c64xx:
Modify SPI driver to use generic DMA DT support") from the sound-asoc tree and
commit 75bf33611041 ("spi/s3c64xx: fix checkpatch warnings and error")
from the spi tree.

I fixed it up (the former removed a function modified by the latter) and
can carry the fix as necessary (no action is required).

-- 
Cheers,
Stephen Rothwells...@canb.auug.org.au


pgpsqxc_RYO6z.pgp
Description: PGP signature

Re: [PATCH] ASoC: fsl: fix allyesconfig build for imx-pcm

[Shawn Guo]

On Tue, Feb 05, 2013 at 04:42:25PM +, Arnd Bergmann wrote:
> Patch 25b8d314 "ASoC: fsl: fix multiple definition of init_module changed
> the Makefile for imx-pcm.ko to build two modules that both contain the
> imx-pcm.c file, which nicely solves the problem of building both versions
> of the driver as modules, but it causes two new problems:
> 
It's my fault, Arnd.  The patch 25b8d314 is a crap.  Instead of making
the Kconfig even complexer, I chose to revert the patch and do a little
surgery on the code to make it match the Kconfig rational.  The fix[1]
should be on the way to mainline now.

I'm sorry for messing thing up during -rc time.

Shawn

[1] http://thread.gmane.org/gmane.linux.alsa.devel/105018

--
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/

[PATCH V2 0/2] ARM: davinci: da850: add wdt DT node

[Kumar, Anil]

Add wdt DT node and OF_DEV_AUXDATA for wdt driver in
da850 board dt file to use wdt clock.

This is tested on da850 EVM.

Test Procedure:

$watchdog -F /dev/watchdog (Device should not reboot)
 After wdt heartbeat timeout(DEFAULT_HEARTBEAT is 60 sec)
$ctr + c   (Device should reboot after heartbeat timeout)

Changes since V1:

 - Rebase changes on top of v3.8-rc6.
 - Make single patch for wdt DT node and its OF_DEV_AUXDATA entry changes.
 - Fix wdt to machine restart with DT.

Kumar, Anil (2):
  ARM: davinci: da850: add wdt DT node
  ARM: davinci: restart: fix wdt to machine restart with DT

 arch/arm/boot/dts/da850-evm.dts|3 +++
 arch/arm/boot/dts/da850.dtsi   |5 +
 arch/arm/mach-davinci/da8xx-dt.c   |8 +++-
 arch/arm/mach-davinci/devices-da8xx.c  |   14 --
 arch/arm/mach-davinci/include/mach/da8xx.h |1 -
 5 files changed, 27 insertions(+), 4 deletions(-)

-- 
1.7.4.1

--
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/

[PATCH V2 2/2] ARM: davinci: restart: fix wdt to machine restart with DT

[Kumar, Anil]

In non DT case da8xx_register_watchdog() is called to register platform device
"da8xx_wdt_device" by board file. But in DT case it is not called and wdt
device get registered via wdt DT node.

Currently code is passing platform device "da8xx_wdt_device" in
"davinci_watchdog_reset" function in both DT and non DT case and that
leads to crash in DT boot.

Update restart function to make it generic DaVinci machine restart
in case of DT and non DT boot.

Signed-off-by: Kumar, Anil 
---
:100644 100644 2d5502d... 1df68fd... M  arch/arm/mach-davinci/devices-da8xx.c
:100644 100644 700d311... ef9f70e... M  
arch/arm/mach-davinci/include/mach/da8xx.h
 arch/arm/mach-davinci/devices-da8xx.c  |   14 --
 arch/arm/mach-davinci/include/mach/da8xx.h |1 -
 2 files changed, 12 insertions(+), 3 deletions(-)

diff --git a/arch/arm/mach-davinci/devices-da8xx.c 
b/arch/arm/mach-davinci/devices-da8xx.c
index 2d5502d..1df68fd 100644
--- a/arch/arm/mach-davinci/devices-da8xx.c
+++ b/arch/arm/mach-davinci/devices-da8xx.c
@@ -359,7 +359,7 @@ static struct resource da8xx_watchdog_resources[] = {
},
 };
 
-struct platform_device da8xx_wdt_device = {
+static struct platform_device da8xx_wdt_device = {
.name   = "watchdog",
.id = -1,
.num_resources  = ARRAY_SIZE(da8xx_watchdog_resources),
@@ -368,7 +368,17 @@ struct platform_device da8xx_wdt_device = {
 
 void da8xx_restart(char mode, const char *cmd)
 {
-   davinci_watchdog_reset(_wdt_device);
+   struct device *dev = NULL;
+   struct platform_device *wdt_device = NULL;
+
+   dev = bus_find_device_by_name(_bus_type, NULL, "watchdog");
+   if (!dev) {
+   pr_err("wdt device not found to machine reboot\n");
+   return;
+   }
+
+   wdt_device = to_platform_device(dev);
+   davinci_watchdog_reset(wdt_device);
 }
 
 int __init da8xx_register_watchdog(void)
diff --git a/arch/arm/mach-davinci/include/mach/da8xx.h 
b/arch/arm/mach-davinci/include/mach/da8xx.h
index 700d311..ef9f70e 100644
--- a/arch/arm/mach-davinci/include/mach/da8xx.h
+++ b/arch/arm/mach-davinci/include/mach/da8xx.h
@@ -112,7 +112,6 @@ extern struct da8xx_lcdc_platform_data 
sharp_lcd035q3dg01_pdata;
 extern struct da8xx_lcdc_platform_data sharp_lk043t1dg01_pdata;
 extern struct davinci_spi_platform_data da8xx_spi_pdata[];
 
-extern struct platform_device da8xx_wdt_device;
 
 extern const short da830_emif25_pins[];
 extern const short da830_spi0_pins[];
-- 
1.7.4.1

--
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/

[PATCH V2 1/2] ARM: davinci: da850: add wdt DT node

[Kumar, Anil]

Add da850 wdt DT node.
Add OF_DEV_AUXDATA for wdt driver to use wdt clock.

Signed-off-by: Kumar, Anil 
---
Changes for V2:

 -Make single patch for wdt DT node and its OF_DEV_AUXDATA entry changes.

:100644 100644 37dc5a3... 4666ce9... M  arch/arm/boot/dts/da850-evm.dts
:100644 100644 640ab75... ffba00f... M  arch/arm/boot/dts/da850.dtsi
:100644 100644 37c27af... 01521ed... M  arch/arm/mach-davinci/da8xx-dt.c
 arch/arm/boot/dts/da850-evm.dts  |3 +++
 arch/arm/boot/dts/da850.dtsi |5 +
 arch/arm/mach-davinci/da8xx-dt.c |8 +++-
 3 files changed, 15 insertions(+), 1 deletions(-)

diff --git a/arch/arm/boot/dts/da850-evm.dts b/arch/arm/boot/dts/da850-evm.dts
index 37dc5a3..4666ce9 100644
--- a/arch/arm/boot/dts/da850-evm.dts
+++ b/arch/arm/boot/dts/da850-evm.dts
@@ -24,5 +24,8 @@
serial2: serial@1d0d000 {
status = "okay";
};
+   wdt: wdt@1c21000 {
+   status = "okay";
+   };
};
 };
diff --git a/arch/arm/boot/dts/da850.dtsi b/arch/arm/boot/dts/da850.dtsi
index 640ab75..ffba00f 100644
--- a/arch/arm/boot/dts/da850.dtsi
+++ b/arch/arm/boot/dts/da850.dtsi
@@ -56,5 +56,10 @@
interrupt-parent = <>;
status = "disabled";
};
+   wdt: wdt@1c21000 {
+   compatible = "ti,davinci-wdt";
+   reg = <0x21000 0x1000>;
+   status = "disabled";
+   };
};
 };
diff --git a/arch/arm/mach-davinci/da8xx-dt.c b/arch/arm/mach-davinci/da8xx-dt.c
index 37c27af..01521ed 100644
--- a/arch/arm/mach-davinci/da8xx-dt.c
+++ b/arch/arm/mach-davinci/da8xx-dt.c
@@ -37,11 +37,17 @@ static void __init da8xx_init_irq(void)
of_irq_init(da8xx_irq_match);
 }
 
+struct of_dev_auxdata da850_auxdata_lookup[] __initdata = {
+   OF_DEV_AUXDATA("ti,davinci-wdt", 0x01c21000, "watchdog", NULL),
+   {}
+};
+
 #ifdef CONFIG_ARCH_DAVINCI_DA850
 
 static void __init da850_init_machine(void)
 {
-   of_platform_populate(NULL, of_default_bus_match_table, NULL, NULL);
+   of_platform_populate(NULL, of_default_bus_match_table,
+   da850_auxdata_lookup, NULL);
 
da8xx_uart_clk_enable();
 }
-- 
1.7.4.1

--
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/

RE: [PATCH] i2c: davinci: update to devm_* API

[Vishwanathrao Badarkhe, Manish]

Hi Sekhar

On Tue, Feb 05, 2013 at 17:17:25, Nori, Sekhar wrote:
> 
> 
> On 2/5/2013 1:54 PM, Vishwanathrao Badarkhe, Manish wrote:
> > Update the code to use devm_* API so that driver core will manage 
> > resources.
> > 
> > Signed-off-by: Vishwanathrao Badarkhe, Manish 
> 
> You can use devm_clk_get() as well. We should also move to runtime 
  PM but that can be a different patch.

Sure, I will apply devm operation for clk_get also in next version.
Ok, will move to runtime PM in a different patch.


Thanks, 
Manish Badarkhe
> > ---
> > :100644 100644 6a0a553... f3dfffb... M  drivers/i2c/busses/i2c-davinci.c
> >  drivers/i2c/busses/i2c-davinci.c |   41 
> > +++--
> >  1 files changed, 12 insertions(+), 29 deletions(-)
> > 
> > diff --git a/drivers/i2c/busses/i2c-davinci.c 
> > b/drivers/i2c/busses/i2c-davinci.c
> > index 6a0a553..f3dfffb 100644
> > --- a/drivers/i2c/busses/i2c-davinci.c
> > +++ b/drivers/i2c/busses/i2c-davinci.c
> > @@ -643,7 +643,7 @@ static int davinci_i2c_probe(struct 
> > platform_device *pdev)  {
> > struct davinci_i2c_dev *dev;
> > struct i2c_adapter *adap;
> > -   struct resource *mem, *irq, *ioarea;
> > +   struct resource *mem, *irq;
> > int r;
> >  
> > /* NOTE: driver uses the static register mapping */ @@ -659,17 
> > +659,11 @@ static int davinci_i2c_probe(struct platform_device *pdev)
> > return -ENODEV;
> > }
> >  
> > -   ioarea = request_mem_region(mem->start, resource_size(mem),
> > -   pdev->name);
> > -   if (!ioarea) {
> > -   dev_err(>dev, "I2C region already claimed\n");
> > -   return -EBUSY;
> > -   }
> > -
> > -   dev = kzalloc(sizeof(struct davinci_i2c_dev), GFP_KERNEL);
> > +   dev = devm_kzalloc(>dev, sizeof(struct davinci_i2c_dev),
> > +   GFP_KERNEL);
> > if (!dev) {
> > -   r = -ENOMEM;
> > -   goto err_release_region;
> > +   dev_err(>dev, "Memory allocation failed\n");
> > +   return -ENOMEM;
> > }
> >  
> > init_completion(>cmd_complete);
> > @@ -706,15 +700,17 @@ static int davinci_i2c_probe(struct platform_device 
> > *pdev)
> > }
> > clk_prepare_enable(dev->clk);
> >  
> > -   dev->base = ioremap(mem->start, resource_size(mem));
> > +   dev->base = devm_request_and_ioremap(>dev, mem);
> > if (!dev->base) {
> > r = -EBUSY;
> > -   goto err_mem_ioremap;
> > +   dev_err(>dev, "I2C region already claimed\n");
> > +   goto err_unuse_clocks;
> > }
> >  
> > i2c_davinci_init(dev);
> >  
> > -   r = request_irq(dev->irq, i2c_davinci_isr, 0, pdev->name, dev);
> > +   r = devm_request_irq(>dev, dev->irq, i2c_davinci_isr, 0,
> > +   pdev->name, dev);
> > if (r) {
> > dev_err(>dev, "failure requesting irq %i\n", dev->irq);
> > goto err_unuse_clocks;
> > @@ -723,7 +719,7 @@ static int davinci_i2c_probe(struct platform_device 
> > *pdev)
> > r = i2c_davinci_cpufreq_register(dev);
> > if (r) {
> > dev_err(>dev, "failed to register cpufreq\n");
> > -   goto err_free_irq;
> > +   goto err_unuse_clocks;
> > }
> >  
> > adap = >adapter;
> > @@ -740,26 +736,19 @@ static int davinci_i2c_probe(struct platform_device 
> > *pdev)
> > r = i2c_add_numbered_adapter(adap);
> > if (r) {
> > dev_err(>dev, "failure adding adapter\n");
> > -   goto err_free_irq;
> > +   goto err_unuse_clocks;
> > }
> > of_i2c_register_devices(adap);
> >  
> > return 0;
> >  
> > -err_free_irq:
> > -   free_irq(dev->irq, dev);
> >  err_unuse_clocks:
> > -   iounmap(dev->base);
> > -err_mem_ioremap:
> > clk_disable_unprepare(dev->clk);
> > clk_put(dev->clk);
> > dev->clk = NULL;
> >  err_free_mem:
> > platform_set_drvdata(pdev, NULL);
> > put_device(>dev);
> > -   kfree(dev);
> > -err_release_region:
> > -   release_mem_region(mem->start, resource_size(mem));
> >  
> > return r;
> >  }
> > @@ -767,7 +756,6 @@ err_release_region:
> >  static int davinci_i2c_remove(struct platform_device *pdev)  {
> > struct davinci_i2c_dev *dev = platform_get_drvdata(pdev);
> > -   struct resource *mem;
> >  
> > i2c_davinci_cpufreq_deregister(dev);
> >  
> > @@ -780,12 +768,7 @@ static int davinci_i2c_remove(struct platform_device 
> > *pdev)
> > dev->clk = NULL;
> >  
> > davinci_i2c_write_reg(dev, DAVINCI_I2C_MDR_REG, 0);
> > -   free_irq(dev->irq, dev);
> > -   iounmap(dev->base);
> > -   kfree(dev);
> >  
> > -   mem = platform_get_resource(pdev, IORESOURCE_MEM, 0);
> > -   release_mem_region(mem->start, resource_size(mem));
> > return 0;
> >  }
> >  
> > 
> 


N�r��yb�X��ǧv�^�)޺{.n�+{zX����ܨ}���Ơz�:+v���zZ+��+zf���h���~i���z��w���?�&�)ߢf��^jǫy�m��@A�a���
0��h���i

linux-next: manual merge of the battery tree with the mfd tree

[Stephen Rothwell]

Hi Anton,

Today's linux-next merge of the battery tree got a conflict in
include/linux/mfd/abx500/ab8500.h between commit 1d843a6c8c20 ("mfd:
ab8500-core: Allow the possibility to dump all AB8500 registers") from
the mfd tree and commit 0ed5107fa860 ("ab8500-charger: Do not touch
VBUSOVV bits") from the battery tree.

I fixed it up (see below) and can carry the fix as necessary (no action
is required).

-- 
Cheers,
Stephen Rothwells...@canb.auug.org.au

diff --cc include/linux/mfd/abx500/ab8500.h
index fa7173d,b9a6a84..000
--- a/include/linux/mfd/abx500/ab8500.h
+++ b/include/linux/mfd/abx500/ab8500.h
@@@ -345,12 -346,23 +350,32 @@@ static inline int is_ab8500_2p0(struct 
return (is_ab8500(ab) && (ab->chip_id == AB8500_CUT2P0));
  }
  
+ static inline int is_ab8505_1p0_or_earlier(struct ab8500 *ab)
+ {
+   return (is_ab8505(ab) && (ab->chip_id <= AB8500_CUT1P0));
+ }
+ 
+ static inline int is_ab8505_2p0(struct ab8500 *ab)
+ {
+   return (is_ab8505(ab) && (ab->chip_id == AB8500_CUT2P0));
+ }
+ 
+ static inline int is_ab9540_1p0_or_earlier(struct ab8500 *ab)
+ {
+   return (is_ab9540(ab) && (ab->chip_id <= AB8500_CUT1P0));
+ }
+ 
+ static inline int is_ab9540_2p0(struct ab8500 *ab)
+ {
+   return (is_ab9540(ab) && (ab->chip_id == AB8500_CUT2P0));
+ }
++
 +#ifdef CONFIG_AB8500_DEBUG
 +void ab8500_dump_all_banks(struct device *dev);
 +void ab8500_debug_register_interrupt(int line);
 +#else
 +static inline void ab8500_dump_all_banks(struct device *dev) {}
 +static inline void ab8500_debug_register_interrupt(int line) {}
 +#endif
 +
  #endif /* MFD_AB8500_H */


pgpEo04XGH8Z_.pgp
Description: PGP signature

Re: Question on lockdep and MAX_LOCK_DEPTH

[Ben Greear]

On 02/05/2013 06:52 PM, Steven Rostedt wrote:

On Tue, 2013-02-05 at 18:26 -0800, Ben Greear wrote:

Well, here it is..something is calling rcu_read_lock lots and lots,


Or a bug in the way lockdep handles rcu mappings.


it seems.  Any way to get a better idea of where those calls are
made?


Yeah, with ftrace.


96 locks held by swapper/0/0:
   #0:  (rcu_read_lock){.+.+..}, at: [] rcu_read_lock+0x0/0x6f
   #1:  (rcu_read_lock){.+.+..}, at: [] rcu_read_lock+0x0/0x6f

[...]

   #92:  (rcu_read_lock){.+.+..}, at: [] 
rcu_read_lock+0x0/0x6f
   #93:  (&(>cfg_spin_lock)->rlock){..-...}, at: [] 
handle_rcv+0x15d/0x1dd [wanlink]
   #94:  (_threads[q].my_wq){..-...}, at: [] 
__wake_up+0x1d/0x48
   #95:  (>pi_lock){-.-.-.}, at: [] 
try_to_wake_up+0x29/0x20b


If you haven't already configured ftrace into your kernel, can you
please do so. Specifically:

CONFIG_FUNCTION_TRACER=y
CONFIG_FUNCTION_GRAPH_TRACER=y
CONFIG_DYNAMIC_FTRACE=y

Then, before triggering this, run the following as root:

  # mount -t debugfs nodev /sys/kernel/debug
  # cd /sys/kernel/debug/tracing
  # echo net_rx_action > set_graph_function
  # echo function_graph > current_tracer

In the kernel, where you added the above dump, before any of the printks
happen, add this too:

trace_printk("BUG\n");
tracing_off();

This will stop the trace at the point of the error. The trace_printk()
is a nice way to see the trace too.

Then after you trigger the bug, do the following:

   cat /sys/kernel/debug/tracing/trace

and reply with that.


It's huge, so here's a link:

http://www.candelatech.com/~greearb/debug.tgz


Thanks,
Ben

--
Ben Greear 
Candela Technologies Inc  http://www.candelatech.com

--
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/

Re: [PATCH] clk: Fix build for Allwinner A1X SoCs

[Prashant Gaikwad]

On Tuesday 05 February 2013 08:35 PM, Thierry Reding wrote:

Commit 85a1819 (clk: sunxi: Use common of_clk_init() function) removed
the source file but didn't update the Makefile, therefore causing the
build to break on Allwinner A1X SoCs.

Signed-off-by: Thierry Reding 


Thanks Thierry!!


---
  drivers/clk/Makefile | 1 -
  1 file changed, 1 deletion(-)

diff --git a/drivers/clk/Makefile b/drivers/clk/Makefile
index ce77077..be9392e 100644
--- a/drivers/clk/Makefile
+++ b/drivers/clk/Makefile
@@ -25,7 +25,6 @@ endif
  obj-$(CONFIG_MACH_LOONGSON1)  += clk-ls1x.o
  obj-$(CONFIG_ARCH_U8500)  += ux500/
  obj-$(CONFIG_ARCH_VT8500) += clk-vt8500.o
-obj-$(CONFIG_ARCH_SUNXI)   += clk-sunxi.o
  obj-$(CONFIG_ARCH_ZYNQ)   += clk-zynq.o
  obj-$(CONFIG_X86) += x86/
  obj-$(CONFIG_ARCH_TEGRA)  += tegra/


--
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/

[PATCH 2/2] regulator: max8998: Let regulator core handle the case selector == old_selector

[Axel Lin]

Signed-off-by: Axel Lin 
---
 drivers/regulator/max8998.c |   14 +-
 1 file changed, 1 insertion(+), 13 deletions(-)

diff --git a/drivers/regulator/max8998.c b/drivers/regulator/max8998.c
index 0a8dd1c..b588f07 100644
--- a/drivers/regulator/max8998.c
+++ b/drivers/regulator/max8998.c
@@ -311,25 +311,13 @@ static int max8998_set_voltage_buck_sel(struct 
regulator_dev *rdev,
dev_get_platdata(max8998->iodev->dev);
struct i2c_client *i2c = max8998->iodev->i2c;
int buck = rdev_get_id(rdev);
-   int reg, shift = 0, mask, ret;
-   int j, previous_sel;
+   int reg, shift = 0, mask, ret, j;
static u8 buck1_last_val;
 
ret = max8998_get_voltage_register(rdev, , , );
if (ret)
return ret;
 
-   previous_sel = max8998_get_voltage_sel(rdev);
-
-   /* Check if voltage needs to be changed */
-   /* if previous_voltage equal new voltage, return */
-   if (previous_sel == selector) {
-   dev_dbg(max8998->dev, "No voltage change, old:%d, new:%d\n",
-   regulator_list_voltage_linear(rdev, previous_sel),
-   regulator_list_voltage_linear(rdev, selector));
-   return ret;
-   }
-
switch (buck) {
case MAX8998_BUCK1:
dev_dbg(max8998->dev,
-- 
1.7.9.5



--
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/

[PATCH 1/2] regulator: core: Optimize _regulator_do_set_voltage if voltage does not change

[Axel Lin]

Optimize _regulator_do_set_voltage() for the case selector is equal to
old_selector. Since the voltage does not change, we don't need to call
set_voltage_sel() and set_voltage_time_sel() in this case.

Signed-off-by: Axel Lin 
---
 drivers/regulator/core.c |9 ++---
 1 file changed, 6 insertions(+), 3 deletions(-)

diff --git a/drivers/regulator/core.c b/drivers/regulator/core.c
index de47880..e9df76e 100644
--- a/drivers/regulator/core.c
+++ b/drivers/regulator/core.c
@@ -2239,8 +2239,11 @@ static int _regulator_do_set_voltage(struct 
regulator_dev *rdev,
best_val = rdev->desc->ops->list_voltage(rdev, ret);
if (min_uV <= best_val && max_uV >= best_val) {
selector = ret;
-   ret = rdev->desc->ops->set_voltage_sel(rdev,
-  ret);
+   if (old_selector == selector)
+   ret = 0;
+   else
+   ret = rdev->desc->ops->set_voltage_sel(
+   rdev, ret);
} else {
ret = -EINVAL;
}
@@ -2251,7 +2254,7 @@ static int _regulator_do_set_voltage(struct regulator_dev 
*rdev,
 
/* Call set_voltage_time_sel if successfully obtained old_selector */
if (ret == 0 && _regulator_is_enabled(rdev) && old_selector >= 0 &&
-   rdev->desc->ops->set_voltage_time_sel) {
+   old_selector != selector && rdev->desc->ops->set_voltage_time_sel) {
 
delay = rdev->desc->ops->set_voltage_time_sel(rdev,
old_selector, selector);
-- 
1.7.9.5



--
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/

Re: [PATCH v5 01/14] memory-hotplug: try to offline the memory twice to avoid dependence

[Tang Chen]

Hi Glauber, all,

An old thing I want to discuss with you. :)

On 01/09/2013 11:09 PM, Glauber Costa wrote:

memory can't be offlined when CONFIG_MEMCG is selected.
For example: there is a memory device on node 1. The address range
is [1G, 1.5G). You will find 4 new directories memory8, memory9, memory10,
and memory11 under the directory /sys/devices/system/memory/.

If CONFIG_MEMCG is selected, we will allocate memory to store page cgroup
when we online pages. When we online memory8, the memory stored page cgroup
is not provided by this memory device. But when we online memory9, the memory
stored page cgroup may be provided by memory8. So we can't offline memory8
now. We should offline the memory in the reversed order.

When the memory device is hotremoved, we will auto offline memory provided
by this memory device. But we don't know which memory is onlined first, so
offlining memory may fail. In such case, iterate twice to offline the memory.
1st iterate: offline every non primary memory block.
2nd iterate: offline primary (i.e. first added) memory block.

This idea is suggested by KOSAKI Motohiro.

Signed-off-by: Wen Congyang


Maybe there is something here that I am missing - I admit that I came
late to this one, but this really sounds like a very ugly hack, that
really has no place in here.

Retrying, of course, may make sense, if we have reasonable belief that
we may now succeed. If this is the case, you need to document - in the
code - while is that.

The memcg argument, however, doesn't really cut it. Why can't we make
all page_cgroup allocations local to the node they are describing? If
memcg is the culprit here, we should fix it, and not retry. If there is
still any benefit in retrying, then we retry being very specific about why.


We try to make all page_cgroup allocations local to the node they are describing
now. If the memory is the first memory onlined in this node, we will allocate
it from the other node.

For example, node1 has 4 memory blocks: 8-11, and we online it from 8 to 11
1. memory block 8, page_cgroup allocations are in the other nodes
2. memory block 9, page_cgroup allocations are in memory block 8

So we should offline memory block 9 first. But we don't know in which order
the user online the memory block.

I think we can modify memcg like this:
allocate the memory from the memory block they are describing

I am not sure it is OK to do so.


I don't see a reason why not.

You would have to tweak a bit the lookup function for page_cgroup, but
assuming you will always have the pfns and limits, it should be easy to do.

I think the only tricky part is that today we have a single
node_page_cgroup, and we would of course have to have one per memory
block. My assumption is that the number of memory blocks is limited and
likely not very big. So even a static array would do.



About the idea "allocate the memory from the memory block they are 
describing",


online_pages()
 |-->memory_notify(MEM_GOING_ONLINE, ) --- memory of this 
section is not in buddy yet.

  |-->page_cgroup_callback()
   |-->online_page_cgroup()
|-->init_section_page_cgroup()
 |-->alloc_page_cgroup() - allocate 
page_cgroup from buddy system.


When onlining pages, we allocate page_cgroup from buddy. And the being 
onlined pages are not in
buddy yet. I think we can reserve some memory in the section for 
page_cgroup, and return all the

rest to the buddy.

But when the system is booting,

start_kernel()
 |-->setup_arch()
 |-->mm_init()
 ||-->mem_init()
 | |-->numa_free_all_bootmem() -- all the pages are 
in buddy system.

 |-->page_cgroup_init()
  |-->init_section_page_cgroup()
   |-->alloc_page_cgroup() -- I don't know how 
to reserve memory in each section.


So any idea about how to deal with it when the system is booting please?


And one more question, a memory section is 128MB in Linux. If we reserve 
part of the them for page_cgroup,
then anyone who wants to allocate a contiguous memory larger than 128MB, 
it will fail, right ?

Is it OK ?

Thanks. :)




--
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/

Re: [RFC] arm: use built-in byte swap function

[Kim Phillips]

On Fri, 1 Feb 2013 07:33:17 +
"Woodhouse, David"  wrote:

> On Fri, 2013-02-01 at 01:17 +, Russell King - ARM Linux wrote:
> > 
> > > I've tried both gcc 4.6.3 [1] and 4.6.4 [2].  If you can point me to
> > > a 4.5.x, I'll try that, too, but as it stands now, if one moves the
> > > code added to swab.h below outside of its armv6 protection,
> > > gcc adds calls to __bswapsi2.
> > 
> > Take a look at the message I sent on the 29th towards the beginning of
> > this thread for details of gcc 4.5.4 behaviour.
> 
> I'd like to see a comment (with PR# if appropriate) explaining clearly
> *why* it isn't enabled for  Russell's test also seemed to indicate that the 32-bit and 64-bit swap
> support was present and functional in GCC 4.5.4 (as indeed it should
> have been since 4.4), so I'm still not quite sure why you require 4.6
> for that.

initially it was based at looking at gcc commit history for the
'rev' instruction implementation, but now I've got 4.4, 4.5, 4.6 and
4.7 compilers to perform Russell's test:

$ for cc in 4.4 4.5 4.6 4.7; do \
arm-linux-gnueabi-gcc-$cc --version | grep gcc ; \
for a in armv3 armv4 armv4t armv5t armv5te armv6k armv6 armv7-a; do \
  echo -n $a:; \
  for f in 16 32 64; do \
 echo 'unsigned foo(unsigned val) { return __builtin_bswap'$f'(val); }' 
| arm-linux-gnueabi-gcc-$cc -w -x c -S -o - - -march=$a | grep 'bl'; \
  done; \
done; \
done

whose output is:

arm-linux-gnueabi-gcc-4.4 (Ubuntu/Linaro 4.4.7-1ubuntu2) 4.4.7
armv3:  bl  __builtin_bswap16
bl  __bswapsi2
bl  __bswapdi2
armv4:  bl  __builtin_bswap16
bl  __bswapsi2
bl  __bswapdi2
armv4t: bl  __builtin_bswap16
bl  __bswapsi2
bl  __bswapdi2
armv5t: bl  __builtin_bswap16
bl  __bswapsi2
bl  __bswapdi2
armv5te:bl  __builtin_bswap16
bl  __bswapsi2
bl  __bswapdi2
armv6k: bl  __builtin_bswap16
bl  __bswapsi2
bl  __bswapdi2
armv6:  bl  __builtin_bswap16
bl  __bswapsi2
bl  __bswapdi2
armv7-a:bl  __builtin_bswap16
bl  __bswapsi2
bl  __bswapdi2
arm-linux-gnueabi-gcc-4.5 (Ubuntu/Linaro 4.5.3-12ubuntu2) 4.5.3
armv3:  bl  __builtin_bswap16
armv4:  bl  __builtin_bswap16
armv4t: bl  __builtin_bswap16
armv5t: bl  __builtin_bswap16
armv5te:bl  __builtin_bswap16
armv6k: bl  __builtin_bswap16
armv6:  bl  __builtin_bswap16
armv7-a:bl  __builtin_bswap16
arm-linux-gnueabi-gcc-4.6 (Ubuntu/Linaro 4.6.3-8ubuntu1) 4.6.3 20120624 
(prerelease)
armv3:  bl  __builtin_bswap16
armv4:  bl  __builtin_bswap16
armv4t: bl  __builtin_bswap16
armv5t: bl  __builtin_bswap16
armv5te:bl  __builtin_bswap16
armv6k: bl  __builtin_bswap16
armv6:  bl  __builtin_bswap16
armv7-a:bl  __builtin_bswap16
arm-linux-gnueabi-gcc-4.7 (Ubuntu/Linaro 4.7.2-1ubuntu1) 4.7.2
armv3:  bl  __builtin_bswap16
armv4:  bl  __builtin_bswap16
armv4t: bl  __builtin_bswap16
armv5t: bl  __builtin_bswap16
armv5te:bl  __builtin_bswap16
armv6k: bl  __builtin_bswap16
armv6:  bl  __builtin_bswap16
armv7-a:bl  __builtin_bswap16

So 4.4 should be exempt from using the built-ins because it always
emits __bswapsi2 calls: it doesn't matter whether or not -Os or -O2
are added as options in the test.

gcc 4.5, 4.6, and 4.7 all support 32 & 64-bit versions, so we
should check for gcc >= 4.5 instead of gcc >= 4.6.

I've added a new check for !CC_OPTIMIZE_FOR_SIZE and build-tested all
defconfigs with gcc 4.6.3 - here's v5:

>From 11aa942a84fe94d204424a19b6b13fdb2b359ee6 Mon Sep 17 00:00:00 2001
From: Kim Phillips 
Date: Mon, 28 Jan 2013 19:30:33 -0600
Subject: [PATCH] arm: use built-in byte swap function

Enable the compiler intrinsic for byte swapping on arch ARM.  This
allows the compiler to detect and be able to optimize out byte
swappings.

__builtin_bswap{32,64} support was added in gcc 4.4, but until
gcc 4.5, it emitted calls to libgcc's __bswap[sd]i2 (even
with -O2).

All gcc versions tested (4.[4567]) emit calls to __bswap[sd]i2 when
optimizing for size, so we add the !CC_OPTIMIZE_FOR_SIZE check.

Support for 16-bit built-ins will be in gcc version 4.8.

This has a tiny benefit on vmlinux text size (gcc 4.6.4):

multi_v7_defconfig:
   textdata bss dec hex filename
3135208  188396  203344 3526948  35d124 vmlinux
multi_v7_defconfig with builtin_bswap:
   textdata bss dec hex filename
3135112  188396  203344 3526852  35d0c4 vmlinux

exynos_defconfig:
   textdata bss dec hex filename
4286605  360564  223172 4870341  4a50c5 vmlinux
exynos_defconfig with 

linux-next: build failure after merge of the block tree

[Stephen Rothwell]

Hi Jens,

After merging the block tree, today's linux-next build (x86_64
allmodconfig) failed like this:

drivers/block/rsxx/core.c:322:22: error: expected '=', ',', ';', 'asm' or 
'__attribute__' before 'rsxx_pci_probe'
drivers/block/rsxx/core.c:513:23: error: expected '=', ',', ';', 'asm' or 
'__attribute__' before 'rsxx_pci_remove'
drivers/block/rsxx/core.c:610:12: error: 'rsxx_pci_probe' undeclared here (not 
in a function)
drivers/block/rsxx/core.c:611:2: error: implicit declaration of function 
'__devexit_p' [-Werror=implicit-function-declaration]
drivers/block/rsxx/core.c:611:25: error: 'rsxx_pci_remove' undeclared here (not 
in a function)
drivers/block/rsxx/core.c:51:8: warning: 'rsxx_disk_ida' defined but not used 
[-Wunused-variable]
drivers/block/rsxx/core.c:52:8: warning: 'rsxx_ida_lock' defined but not used 
[-Wunused-variable]
drivers/block/rsxx/core.c:219:13: warning: 'card_event_handler' defined but not 
used [-Wunused-function]
drivers/block/rsxx/core.c:311:12: warning: 'rsxx_compatibility_check' defined 
but not used [-Wunused-function]

Caused by commit 8722ff8cdbfa ("block: IBM RamSan 70/80 device driver")
interacting with commit 54b956b90360 ("Remove __dev* markings from
init.h") from Linus' tree (as of v3.8-rc4).

I added the following merge fix patch:

From: Stephen Rothwell 
Date: Wed, 6 Feb 2013 14:03:13 +1100
Subject: [PATCH] block: remove new __devinit/exit annotations

Signed-off-by: Stephen Rothwell 
---
 drivers/block/rsxx/core.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/drivers/block/rsxx/core.c b/drivers/block/rsxx/core.c
index f752191..83dadbe 100644
--- a/drivers/block/rsxx/core.c
+++ b/drivers/block/rsxx/core.c
@@ -319,7 +319,7 @@ static int rsxx_compatibility_check(struct rsxx_cardinfo 
*card)
return 0;
 }
 
-static int __devinit rsxx_pci_probe(struct pci_dev *dev,
+static int rsxx_pci_probe(struct pci_dev *dev,
const struct pci_device_id *id)
 {
struct rsxx_cardinfo *card;
@@ -510,7 +510,7 @@ failed_ida_get:
return st;
 }
 
-static void __devexit rsxx_pci_remove(struct pci_dev *dev)
+static void rsxx_pci_remove(struct pci_dev *dev)
 {
struct rsxx_cardinfo *card = pci_get_drvdata(dev);
unsigned long flags;
@@ -608,7 +608,7 @@ static struct pci_driver rsxx_pci_driver = {
.name   = DRIVER_NAME,
.id_table   = rsxx_pci_ids,
.probe  = rsxx_pci_probe,
-   .remove = __devexit_p(rsxx_pci_remove),
+   .remove = rsxx_pci_remove,
.suspend= rsxx_pci_suspend,
.shutdown   = rsxx_pci_shutdown,
 };
-- 
1.8.1

-- 
Cheers,
Stephen Rothwells...@canb.auug.org.au


pgpT54_yQnEqd.pgp
Description: PGP signature

Re: [PATCH V2] clk: Add composite clock type

[Prashant Gaikwad]

On Tuesday 05 February 2013 03:45 PM, Tomasz Figa wrote:

Hi Prashant,

Thank you for your patch. Please see some comments inline.

On Monday 04 of February 2013 13:41:22 Prashant Gaikwad wrote:

Not all clocks are required to be decomposed into basic clock
types but at the same time want to use the functionality
provided by these basic clock types instead of duplicating.

For example, Tegra SoC has ~100 clocks which can be decomposed
into Mux -> Div -> Gate clock types making the clock count to
~300. Also, parent change operation can not be performed on gate
clock which forces to use mux clock in driver if want to change
the parent.

Instead aggregate the basic clock types functionality into one
clock and just use this clock for all operations. This clock
type re-uses the functionality of basic clock types and not
limited to basic clock types but any hardware-specific
implementation.

Signed-off-by: Prashant Gaikwad 
---

Changes from V1:
- 2nd patch dropped as the concept is acked by Mike.
- Fixed comments from Stephen.

---
  drivers/clk/Makefile |1 +
  drivers/clk/clk-composite.c  |  208
++ include/linux/clk-provider.h
|   30 ++
  3 files changed, 239 insertions(+), 0 deletions(-)
  create mode 100644 drivers/clk/clk-composite.c

diff --git a/drivers/clk/Makefile b/drivers/clk/Makefile
index ce77077..2287848 100644
--- a/drivers/clk/Makefile
+++ b/drivers/clk/Makefile
@@ -7,6 +7,7 @@ obj-$(CONFIG_COMMON_CLK)  += clk-fixed-factor.o
  obj-$(CONFIG_COMMON_CLK) += clk-fixed-rate.o
  obj-$(CONFIG_COMMON_CLK) += clk-gate.o
  obj-$(CONFIG_COMMON_CLK) += clk-mux.o
+obj-$(CONFIG_COMMON_CLK) += clk-composite.o

  # SoCs specific
  obj-$(CONFIG_ARCH_BCM2835)   += clk-bcm2835.o
diff --git a/drivers/clk/clk-composite.c b/drivers/clk/clk-composite.c
new file mode 100644
index 000..5a6587f
--- /dev/null
+++ b/drivers/clk/clk-composite.c
@@ -0,0 +1,208 @@
+/*
+ * Copyright (c) 2013 NVIDIA CORPORATION.  All rights reserved.
+ *
+ * This program is free software; you can redistribute it and/or modify
it + * under the terms and conditions of the GNU General Public
License, + * version 2, as published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope it will be useful, but
WITHOUT + * ANY WARRANTY; without even the implied warranty of
MERCHANTABILITY or + * FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
General Public License for + * more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program.  If not, see
. + */
+
+#include 
+#include 
+#include 
+#include 
+
+#define to_clk_composite(_hw) container_of(_hw, struct clk_composite,
hw) +
+static u8 clk_composite_get_parent(struct clk_hw *hw)
+{
+ struct clk_composite *composite = to_clk_composite(hw);
+ const struct clk_ops *mux_ops = composite->mux_ops;
+ struct clk_hw *mux_hw = composite->mux_hw;
+
+ mux_hw->clk = hw->clk;

Why is this needed? Looks like this filed is already being initialized in
clk_register_composite.


Some ops will get called during clk_init where this clk is not populated 
hence doing here. I have done it for all ops to make sure that any 
future change in clock framework don't break this clock.
Now, why duplicate it in clk_register_composite? It is possible that 
none of these ops get called in clk_init.
For example, recalc_rate is called during init and this ops is supported 
by div clock type, but what if div clock is not added.


I hope this explains the need.


+
+ return mux_ops->get_parent(mux_hw);
+}
+
+static int clk_composite_set_parent(struct clk_hw *hw, u8 index)
+{
+ struct clk_composite *composite = to_clk_composite(hw);
+ const struct clk_ops *mux_ops = composite->mux_ops;
+ struct clk_hw *mux_hw = composite->mux_hw;
+
+ mux_hw->clk = hw->clk;

Ditto.


+
+ return mux_ops->set_parent(mux_hw, index);
+}
+
+static unsigned long clk_composite_recalc_rate(struct clk_hw *hw,
+ unsigned long parent_rate)
+{
+ struct clk_composite *composite = to_clk_composite(hw);
+ const struct clk_ops *div_ops = composite->div_ops;
+ struct clk_hw *div_hw = composite->div_hw;
+
+ div_hw->clk = hw->clk;

Ditto.


+
+ return div_ops->recalc_rate(div_hw, parent_rate);
+}
+
+static long clk_composite_round_rate(struct clk_hw *hw, unsigned long
rate, + unsigned long *prate)
+{
+ struct clk_composite *composite = to_clk_composite(hw);
+ const struct clk_ops *div_ops = composite->div_ops;
+ struct clk_hw *div_hw = composite->div_hw;
+
+ div_hw->clk = hw->clk;

Ditto.


+
+ return div_ops->round_rate(div_hw, rate, prate);
+}
+
+static int clk_composite_set_rate(struct clk_hw *hw, unsigned long
rate, +  unsigned long parent_rate)
+{
+ struct clk_composite *composite = to_clk_composite(hw);

[PATCH 3/3] regulator: s5m8767: Prevent possible NULL pointer dereference

[Axel Lin]

s5m8767_pmic_dt_parse_pdata dereferenes pdata, thus check pdata earlier to
avoid NULL pointer dereference.

Signed-off-by: Axel Lin 
---
 drivers/regulator/s5m8767.c |   10 +-
 1 file changed, 5 insertions(+), 5 deletions(-)

diff --git a/drivers/regulator/s5m8767.c b/drivers/regulator/s5m8767.c
index 4cb65e3..0349358 100644
--- a/drivers/regulator/s5m8767.c
+++ b/drivers/regulator/s5m8767.c
@@ -659,17 +659,17 @@ static int s5m8767_pmic_probe(struct platform_device 
*pdev)
struct s5m8767_info *s5m8767;
int i, ret, size, buck_init;
 
+   if (!pdata) {
+   dev_err(>dev, "Platform data not supplied\n");
+   return -ENODEV;
+   }
+
if (iodev->dev->of_node) {
ret = s5m8767_pmic_dt_parse_pdata(pdev, pdata);
if (ret)
return ret;
}
 
-   if (!pdata) {
-   dev_err(>dev, "Platform data not supplied\n");
-   return -ENODEV;
-   }
-
if (pdata->buck2_gpiodvs) {
if (pdata->buck3_gpiodvs || pdata->buck4_gpiodvs) {
dev_err(>dev, "S5M8767 GPIO DVS NOT VALID\n");
-- 
1.7.9.5



--
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/

[PATCH linux-next] x86/kvm: Fix compile warning in kvm_register_steal_time()

[Shuah Khan]

Fix the following compile warning in kvm_register_steal_time():
  CC  arch/x86/kernel/kvm.o
arch/x86/kernel/kvm.c: In function ‘kvm_register_steal_time’:
arch/x86/kernel/kvm.c:302:3: warning: format ‘%lx’ expects argument of type 
‘long unsigned int’, but argument 3 has type ‘phys_addr_t’ [-Wformat]

Signed-off-by: Shuah Khan 
---
 arch/x86/kernel/kvm.c |4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/arch/x86/kernel/kvm.c b/arch/x86/kernel/kvm.c
index fe75a28..b686a90 100644
--- a/arch/x86/kernel/kvm.c
+++ b/arch/x86/kernel/kvm.c
@@ -298,8 +298,8 @@ static void kvm_register_steal_time(void)
memset(st, 0, sizeof(*st));
 
wrmsrl(MSR_KVM_STEAL_TIME, (slow_virt_to_phys(st) | KVM_MSR_ENABLED));
-   printk(KERN_INFO "kvm-stealtime: cpu %d, msr %lx\n",
-   cpu, slow_virt_to_phys(st));
+   pr_info("kvm-stealtime: cpu %d, msr %llx\n",
+   cpu, (unsigned long long) slow_virt_to_phys(st));
 }
 
 static DEFINE_PER_CPU(unsigned long, kvm_apic_eoi) = KVM_PV_EOI_DISABLED;
-- 
1.7.9.5



--
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/

[PATCH 2/3] regulator: s5m8767: Fix using wrong dev argument at various places

[Axel Lin]

Use >dev rather than iodev->dev for dev_err(), dev_warn() and dev_info().
Use >dev rather than iodev->dev for devm_kzalloc() and
of_get_regulator_init_data(), this fixes memory leak.

Signed-off-by: Axel Lin 
---
 drivers/regulator/s5m8767.c |   47 ++-
 1 file changed, 24 insertions(+), 23 deletions(-)

diff --git a/drivers/regulator/s5m8767.c b/drivers/regulator/s5m8767.c
index 194b5dd..4cb65e3 100644
--- a/drivers/regulator/s5m8767.c
+++ b/drivers/regulator/s5m8767.c
@@ -479,7 +479,7 @@ static struct regulator_desc regulators[] = {
 };
 
 #ifdef CONFIG_OF
-static int s5m8767_pmic_dt_parse_dvs_gpio(struct sec_pmic_dev *iodev,
+static int s5m8767_pmic_dt_parse_dvs_gpio(struct platform_device *pdev,
struct sec_platform_data *pdata,
struct device_node *pmic_np)
 {
@@ -489,7 +489,7 @@ static int s5m8767_pmic_dt_parse_dvs_gpio(struct 
sec_pmic_dev *iodev,
gpio = of_get_named_gpio(pmic_np,
"s5m8767,pmic-buck-dvs-gpios", i);
if (!gpio_is_valid(gpio)) {
-   dev_err(iodev->dev, "invalid gpio[%d]: %d\n", i, gpio);
+   dev_err(>dev, "invalid gpio[%d]: %d\n", i, gpio);
return -EINVAL;
}
pdata->buck_gpios[i] = gpio;
@@ -497,7 +497,7 @@ static int s5m8767_pmic_dt_parse_dvs_gpio(struct 
sec_pmic_dev *iodev,
return 0;
 }
 
-static int s5m8767_pmic_dt_parse_ds_gpio(struct sec_pmic_dev *iodev,
+static int s5m8767_pmic_dt_parse_ds_gpio(struct platform_device *pdev,
struct sec_platform_data *pdata,
struct device_node *pmic_np)
 {
@@ -507,7 +507,7 @@ static int s5m8767_pmic_dt_parse_ds_gpio(struct 
sec_pmic_dev *iodev,
gpio = of_get_named_gpio(pmic_np,
"s5m8767,pmic-buck-ds-gpios", i);
if (!gpio_is_valid(gpio)) {
-   dev_err(iodev->dev, "invalid gpio[%d]: %d\n", i, gpio);
+   dev_err(>dev, "invalid gpio[%d]: %d\n", i, gpio);
return -EINVAL;
}
pdata->buck_ds[i] = gpio;
@@ -515,9 +515,10 @@ static int s5m8767_pmic_dt_parse_ds_gpio(struct 
sec_pmic_dev *iodev,
return 0;
 }
 
-static int s5m8767_pmic_dt_parse_pdata(struct sec_pmic_dev *iodev,
+static int s5m8767_pmic_dt_parse_pdata(struct platform_device *pdev,
struct sec_platform_data *pdata)
 {
+   struct sec_pmic_dev *iodev = dev_get_drvdata(pdev->dev.parent);
struct device_node *pmic_np, *regulators_np, *reg_np;
struct sec_regulator_data *rdata;
struct sec_opmode_data *rmode;
@@ -525,31 +526,31 @@ static int s5m8767_pmic_dt_parse_pdata(struct 
sec_pmic_dev *iodev,
 
pmic_np = iodev->dev->of_node;
if (!pmic_np) {
-   dev_err(iodev->dev, "could not find pmic sub-node\n");
+   dev_err(>dev, "could not find pmic sub-node\n");
return -ENODEV;
}
 
regulators_np = of_find_node_by_name(pmic_np, "regulators");
if (!regulators_np) {
-   dev_err(iodev->dev, "could not find regulators sub-node\n");
+   dev_err(>dev, "could not find regulators sub-node\n");
return -EINVAL;
}
 
/* count the number of regulators to be supported in pmic */
pdata->num_regulators = of_get_child_count(regulators_np);
 
-   rdata = devm_kzalloc(iodev->dev, sizeof(*rdata) *
+   rdata = devm_kzalloc(>dev, sizeof(*rdata) *
pdata->num_regulators, GFP_KERNEL);
if (!rdata) {
-   dev_err(iodev->dev,
+   dev_err(>dev,
"could not allocate memory for regulator data\n");
return -ENOMEM;
}
 
-   rmode = devm_kzalloc(iodev->dev, sizeof(*rmode) *
+   rmode = devm_kzalloc(>dev, sizeof(*rmode) *
pdata->num_regulators, GFP_KERNEL);
if (!rdata) {
-   dev_err(iodev->dev,
+   dev_err(>dev,
"could not allocate memory for regulator mode\n");
return -ENOMEM;
}
@@ -562,7 +563,7 @@ static int s5m8767_pmic_dt_parse_pdata(struct sec_pmic_dev 
*iodev,
break;
 
if (i == ARRAY_SIZE(regulators)) {
-   dev_warn(iodev->dev,
+   dev_warn(>dev,
"don't know how to configure regulator %s\n",
reg_np->name);
continue;
@@ -570,13 +571,13 @@ static int s5m8767_pmic_dt_parse_pdata(struct 
sec_pmic_dev *iodev,
 
rdata->id = i;
rdata->initdata = of_get_regulator_init_data(
-   iodev->dev, reg_np);
+   

Re: [PATCH v3 1/3] drm/exynos: Get HDMI version from device tree

[김승우]

On 2013년 02월 06일 09:56, Sean Paul wrote:
> On Tue, Feb 5, 2013 at 4:42 PM, Stephen Warren  wrote:
>> On 02/05/2013 05:37 PM, Sean Paul wrote:
>>> On Tue, Feb 5, 2013 at 4:22 PM, Stephen Warren  
>>> wrote:
 n 02/05/2013 04:42 PM, Sean Paul wrote:
> Use the compatible string in the device tree to determine which
> registers/functions to use in the HDMI driver. Also changes the
> references from v13 to 4210 and v14 to 4212 to reflect the IP
> block version instead of the HDMI version.

> diff --git a/Documentation/devicetree/bindings/drm/exynos/hdmi.txt 
> b/Documentation/devicetree/bindings/drm/exynos/hdmi.txt

 Binding looks sane to me.

> diff --git a/drivers/gpu/drm/exynos/exynos_hdmi.c 
> b/drivers/gpu/drm/exynos/exynos_hdmi.c

>  #ifdef CONFIG_OF
>  static struct of_device_id hdmi_match_types[] = {
>   {
> - .compatible = "samsung,exynos5-hdmi",
> - .data   = (void *)HDMI_TYPE14,
> + .compatible = "samsung,exynos4-hdmi",
>   }, {
>   /* end node */
>   }

 Why not fill in all the "base" compatible values there (I think you need
 this anyway so that DTs don't all have to be compatible with
 samsung,exynos4-hdmi), with .data containing the HDMI_VER_EXYNOS*
 values, then ...

>>>
>>> At the moment, all DTs have to be compatible with exynos4-hdmi since
>>> it provides the base for the current driver. The driver uses 4210 and
>>> 4212 to differentiate between different register addresses and
>>> features, but most things are just exynos4-hdmi compatible.
>>
>> The DT nodes should include only the compatible values that the HW is
>> actually compatible with. If the HW isn't compatible with exynos4-hdmi,
>> that value shouldn't be in the compatible property, but instead whatever
>> the "base" value that the HW really is compatible with. The driver can
>> support multiple "base" compatible values from this table.
>>
> 
> All devices that use this driver are compatible, at some level, with
> exynos4-hdmi, so I think its usage is correct here.
> 
> @@ -2218,17 +2217,18 @@ static int hdmi_probe(struct platform_device 
> *pdev)

> +
> + if (of_device_is_compatible(dev->of_node, 
> "samsung,exynos4210-hdmi"))
> + hdata->version |= HDMI_VER_EXYNOS4210;
> + if (of_device_is_compatible(dev->of_node, 
> "samsung,exynos4212-hdmi"))
> + hdata->version |= HDMI_VER_EXYNOS4212;
> + if (of_device_is_compatible(dev->of_node, 
> "samsung,exynos5250-hdmi"))
> + hdata->version |= HDMI_VER_EXYNOS5250;

 Instead of that, do roughly:

 match = of_match_device(hdmi_match_types, >dev);
 if (match)
 hdata->version |= (int)match->data;

 That way, it's all table-based. Any future additions to
 hdmi_match_types[] won't require another if statement to be added to
 probe().
>>>
>>> I don't think it's that easy. of_match_device returns the first match
>>> from the device table, so I'd still need to iterate through the
>>> matches. I could still break this out into a table, but I don't think
>>> of_match_device is the right way to probe it.
>>
>> You shouldn't have to iterate over multiple matches. of_match_device()
>> is supposed to return the match for the first entry in the compatible
>> property, then if there was no match, move on to looking at the next
>> entry in the compatible property, etc. In practice, I think it's still
>> not implemented quite correctly for this, but you can make it work by
>> putting the newest compatible value first in the match table.
> 
> I think the only way that works is if you hardcode the compatible
> versions in the driver, like this:
> 
> static struct of_device_id hdmi_match_types[] = {
> {
> .compatible = "samsung,exynos5250-hdmi",
> .data = (void *)(HDMI_VER_EXYNOS5250 | HDMI_VER_EXYNOS4212);
> }, {
> .compatible = "samsung,exynos4212-hdmi",
> .data = (void *)HDMI_VER_EXYNOS4212;
> }, {
> .compatible = "samsung,exynos4210-hdmi",
> .data = (void *)HDMI_VER_EXYNOS4210;
> }, {
> /* end node */
> }
> };

Actually, I can't understand why there is HDMI_VER_EXYNOS5250 because it
is not used anywhere in your patch. I'm not sure I missed something from
your v2 patch thread, but to me, just hdmi version or hdmi ip version
can be used as data field of struct of_device_id as like your v2 patch
set. and then of_match_device() can be used without | in data field.

If I have missed some point from v2 thread, please let me know.

Best Regards,
- Seung-Woo Kim

> 
> In that case, it eliminates the benefit of using device tree to
> determine the compatible bits. I hope I'm just being thick and missing
> something.
> 
> Sean
> 

[PATCH 1/3] regulator: s5m8767: Use of_get_child_count()

[Axel Lin]

Signed-off-by: Axel Lin 
---
 drivers/regulator/s5m8767.c |4 +---
 1 file changed, 1 insertion(+), 3 deletions(-)

diff --git a/drivers/regulator/s5m8767.c b/drivers/regulator/s5m8767.c
index 1250cef..194b5dd 100644
--- a/drivers/regulator/s5m8767.c
+++ b/drivers/regulator/s5m8767.c
@@ -536,9 +536,7 @@ static int s5m8767_pmic_dt_parse_pdata(struct sec_pmic_dev 
*iodev,
}
 
/* count the number of regulators to be supported in pmic */
-   pdata->num_regulators = 0;
-   for_each_child_of_node(regulators_np, reg_np)
-   pdata->num_regulators++;
+   pdata->num_regulators = of_get_child_count(regulators_np);
 
rdata = devm_kzalloc(iodev->dev, sizeof(*rdata) *
pdata->num_regulators, GFP_KERNEL);
-- 
1.7.9.5



--
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/

Re: [PATCH V2] clk: Add composite clock type

[Prashant Gaikwad]

On Tuesday 05 February 2013 03:52 PM, Hiroshi Doyu wrote:

Prashant Gaikwad  wrote @ Tue, 5 Feb 2013 09:33:41 +0100:


The members of "clk_composite_ops" seems to be always assigned
statically. Istead of dynamically allocating/assigning, can't we just
have "clk_composite_ops" statically as below?

static struct clk_ops clk_composite_ops = {
.get_parent = clk_composite_get_parent;
.set_parent = clk_composite_set_parent;
.recalc_rate = clk_composite_recalc_rate;
.round_rate = clk_composite_round_rate;
.set_rate = clk_composite_set_rate;
.is_enabled = clk_composite_is_enabled;
.enable = clk_composite_enable;
.disable = clk_composite_disable;
};

struct clk *clk_register_composite(struct device *dev, const char *name,
   const char **parent_names, int num_parents,
   struct clk_hw *mux_hw, const struct clk_ops *mux_ops,
   struct clk_hw *div_hw, const struct clk_ops *div_ops,
   struct clk_hw *gate_hw, const struct clk_ops *gate_ops,
   unsigned long flags)
{
.

init.ops = _composite_ops;

No, clk_ops depends on the clocks you are using. There could be a clock
with mux and gate while another one with mux and div.

You are right. What about the following? We don't have to have similar
copy of clk_composite_ops for each instances.


Clock framework takes decision depending on the ops availability and it 
does not know if the clock is mux or gate.


For example,

if (clk->ops->enable) {
ret = clk->ops->enable(clk->hw);
if (ret) {
__clk_disable(clk->parent);
return ret;
}
}

in above case if clk_composite does not have gate clock then as per your 
suggestion if it returns error value then it will fail and it is wrong.


Hence clock ops are populated depending on the clock types.


diff --git a/drivers/clk/clk-composite.c b/drivers/clk/clk-composite.c
index f30fb4b..8f88805 100644
--- a/drivers/clk/clk-composite.c
+++ b/drivers/clk/clk-composite.c
@@ -27,6 +27,9 @@ static u8 clk_composite_get_parent(struct clk_hw *hw)
 const struct clk_ops *mux_ops = composite->mux_ops;
 struct clk_hw *mux_hw = composite->mux_hw;
  
+   if (!mux_hw->clk)

+  return -EINVAL;
+
 mux_hw->clk = hw->clk;
  


It is wrong.


 return mux_ops->get_parent(mux_hw);
@@ -38,6 +41,9 @@ static int clk_composite_set_parent(struct clk_hw *hw, u8 
index)
 const struct clk_ops *mux_ops = composite->mux_ops;
 struct clk_hw *mux_hw = composite->mux_hw;
  
+   if (!mux_hw->clk)

+  return -EINVAL;
+
 mux_hw->clk = hw->clk;
  
 return mux_ops->set_parent(mux_hw, index);

@@ -50,6 +56,9 @@ static unsigned long clk_composite_recalc_rate(struct clk_hw 
*hw,
 const struct clk_ops *div_ops = composite->div_ops;
 struct clk_hw *div_hw = composite->div_hw;
  
+   if (!div_hw->clk)

+  return -EINVAL;
+
 div_hw->clk = hw->clk;
  
 return div_ops->recalc_rate(div_hw, parent_rate);

@@ -62,6 +71,9 @@ static long clk_composite_round_rate(struct clk_hw *hw, 
unsigned long rate,
 const struct clk_ops *div_ops = composite->div_ops;
 struct clk_hw *div_hw = composite->div_hw;
  
+   if (!div_hw->clk)

+  return -EINVAL;
+
 div_hw->clk = hw->clk;
  
 return div_ops->round_rate(div_hw, rate, prate);

@@ -74,6 +86,9 @@ static int clk_composite_set_rate(struct clk_hw *hw, unsigned 
long rate,
 const struct clk_ops *div_ops = composite->div_ops;
 struct clk_hw *div_hw = composite->div_hw;
  
+   if (!div_hw->clk)

+  return -EINVAL;
+
 div_hw->clk = hw->clk;
  
 return div_ops->set_rate(div_hw, rate, parent_rate);

@@ -85,6 +100,9 @@ static int clk_composite_is_enabled(struct clk_hw *hw)
 const struct clk_ops *gate_ops = composite->gate_ops;
 struct clk_hw *gate_hw = composite->gate_hw;
  
+   if (!gate_hw->clk)

+  return -EINVAL;
+
 gate_hw->clk = hw->clk;
  
 return gate_ops->is_enabled(gate_hw);

@@ -96,6 +114,9 @@ static int clk_composite_enable(struct clk_hw *hw)
 const struct clk_ops *gate_ops = composite->gate_ops;
 struct clk_hw *gate_hw = composite->gate_hw;
  
+   if (!gate_hw->clk)

+  return -EINVAL;
+
 gate_hw->clk = hw->clk;
  
 return gate_ops->enable(gate_hw);

@@ -107,11 +128,25 @@ static void clk_composite_disable(struct clk_hw *hw)
 const struct clk_ops *gate_ops = composite->gate_ops;
 struct clk_hw *gate_hw = composite->gate_hw;
  
+   if (!gate_hw->clk)

+  return -EINVAL;
+
 gate_hw->clk = hw->clk;
  
 

Re: [PATCH v2 linux-next 2/2] cpufreq: Convert the cpufreq_driver_lock to use the rcu

[Viresh Kumar]

On 6 February 2013 07:34, Nathan Zimmer  wrote:
> In general rwlocks are discourged so we are moving it to use the rcu instead.
>
> Cc: Viresh Kumar 
> Cc: "Rafael J. Wysocki" 
> Signed-off-by: Nathan Zimmer 
> ---
>  drivers/cpufreq/cpufreq.c | 173 
> +-
>  1 file changed, 96 insertions(+), 77 deletions(-)

bleeding-edge got updated again and this patch would have conflicts :)

Acked-by: Viresh Kumar 
--
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/

[PATCH linux-next] x86/mm: Fix compile warning in remove_pagetable()

[Shuah Khan]

Fix the following compile warning in remove_pagetable():
arch/x86/mm/init_64.c: In function ‘remove_pagetable’:
arch/x86/mm/init_64.c:996:9: warning: ‘next’ may be used uninitialized in this 
function [-Wuninitialized]


Signed-off-by: Shuah Khan 
---
 arch/x86/mm/init_64.c |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/x86/mm/init_64.c b/arch/x86/mm/init_64.c
index 67bad4b..ed78400 100644
--- a/arch/x86/mm/init_64.c
+++ b/arch/x86/mm/init_64.c
@@ -987,7 +987,7 @@ remove_pud_table(pud_t *pud_start, unsigned long addr, 
unsigned long end,
 static void __meminit
 remove_pagetable(unsigned long start, unsigned long end, bool direct)
 {
-   unsigned long next;
+   unsigned long next = pgd_addr_end(start, end);
pgd_t *pgd;
pud_t *pud;
bool pgd_changed = false;
-- 
1.7.9.5



--
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/

Re: Question on lockdep and MAX_LOCK_DEPTH

[Steven Rostedt]

On Tue, 2013-02-05 at 18:26 -0800, Ben Greear wrote:
> Well, here it is..something is calling rcu_read_lock lots and lots,

Or a bug in the way lockdep handles rcu mappings.

> it seems.  Any way to get a better idea of where those calls are
> made?

Yeah, with ftrace.

> 96 locks held by swapper/0/0:
>   #0:  (rcu_read_lock){.+.+..}, at: [] 
> rcu_read_lock+0x0/0x6f
>   #1:  (rcu_read_lock){.+.+..}, at: [] 
> rcu_read_lock+0x0/0x6f
[...]
>   #92:  (rcu_read_lock){.+.+..}, at: [] 
> rcu_read_lock+0x0/0x6f
>   #93:  (&(>cfg_spin_lock)->rlock){..-...}, at: [] 
> handle_rcv+0x15d/0x1dd [wanlink]
>   #94:  (_threads[q].my_wq){..-...}, at: [] 
> __wake_up+0x1d/0x48
>   #95:  (>pi_lock){-.-.-.}, at: [] 
> try_to_wake_up+0x29/0x20b

If you haven't already configured ftrace into your kernel, can you
please do so. Specifically:

CONFIG_FUNCTION_TRACER=y
CONFIG_FUNCTION_GRAPH_TRACER=y
CONFIG_DYNAMIC_FTRACE=y

Then, before triggering this, run the following as root:

 # mount -t debugfs nodev /sys/kernel/debug
 # cd /sys/kernel/debug/tracing
 # echo net_rx_action > set_graph_function
 # echo function_graph > current_tracer

In the kernel, where you added the above dump, before any of the printks
happen, add this too:

trace_printk("BUG\n");
tracing_off();

This will stop the trace at the point of the error. The trace_printk()
is a nice way to see the trace too.

Then after you trigger the bug, do the following:

  cat /sys/kernel/debug/tracing/trace

and reply with that.

To turn tracing on again (because the tracing_off() disabled it), you
can do:

  echo 1 > /sys/kernel/debug/tracing/tracing_on

Careful not to do "echo 1> ..." ;-)

-- Steve




--
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/

Re: [PATCH v2] zsmalloc: Add Kconfig for enabling PTE method

[Minchan Kim]

On Tue, Feb 05, 2013 at 06:28:54PM -0800, Greg Kroah-Hartman wrote:
> On Wed, Feb 06, 2013 at 11:17:08AM +0900, Minchan Kim wrote:
> > diff --git a/drivers/staging/zsmalloc/Kconfig 
> > b/drivers/staging/zsmalloc/Kconfig
> > index 9084565..232b3b6 100644
> > --- a/drivers/staging/zsmalloc/Kconfig
> > +++ b/drivers/staging/zsmalloc/Kconfig
> > @@ -8,3 +8,15 @@ config ZSMALLOC
> >   non-standard allocator interface where a handle, not a pointer, is
> >   returned by an alloc().  This handle must be mapped in order to
> >   access the allocated space.
> > +
> > +config PGTABLE_MAPPING
> > +bool "Use page table mapping to access allocations that span two 
> > pages"
> 
> No tabs?
> 
> Please also put "ZSmalloc somewhere in the text here, otherwise it
> really doesn't make much sense when seeing it in a menu.
> 
> > +depends on ZSMALLOC
> > +default n
> 
> That's the default, so it can be dropped.
> 
> > +help
> > + By default, zsmalloc uses a copy-based object mapping method to access
> > + allocations that span two pages. However, if a particular architecture
> > + performs VM mapping faster than copying, then you should select this.
> > + This causes zsmalloc to use page table mapping rather than copying
> > + for object mapping. You can check speed with zsmalloc benchmark[1].
> > + [1] https://github.com/spartacus06/zsmalloc
> 
> Care to specify exactly _what_ architectures this should be set for or
> not?  That will help the distros out a lot in determining if this should
> be enabled or not.
> 
> > diff --git a/drivers/staging/zsmalloc/zsmalloc-main.c 
> > b/drivers/staging/zsmalloc/zsmalloc-main.c
> > index 06f73a9..2c1805c 100644
> > --- a/drivers/staging/zsmalloc/zsmalloc-main.c
> > +++ b/drivers/staging/zsmalloc/zsmalloc-main.c
> > @@ -207,6 +207,7 @@ struct zs_pool {
> > struct size_class size_class[ZS_SIZE_CLASSES];
> >  
> > gfp_t flags;/* allocation flags used when growing pool */
> > +
> >  };
> >  
> >  /*
> 
> Why add this extra line?
> 
> thanks,
> 
> greg k-h

Sorry for bothering you.
I fixed all you pointed out.
Thanks for the review, Greg!

Here it goes.

--- 8< ---

>From 506acea72916c9a12cf80290bc5cd87f4af1914d Mon Sep 17 00:00:00 2001
From: Minchan Kim 
Date: Wed, 6 Feb 2013 11:10:59 +0900
Subject: [PATCH v3] zsmalloc: Add Kconfig for enabling PTE method

Zsmalloc has two methods 1) copy-based and 2) pte-based to access
allocations that span two pages. You can see history why we supported
two approach from [1].

In summary, copy-based method is 3 times fater in x86 while pte-based
is 6 times faster in ARM.

But it was bad choice that adding hard coding to select architecture
which want to use pte based method. This patch removed it and adds
new Kconfig to select the approach.

This patch is based on next-20130205.

[1] https://lkml.org/lkml/2012/7/11/58

* Changelog from v2
  * Add tab and drop "default n" - Greg
  * Modify description - Greg
  * Drop unnecessary extra line - Greg

* Changelog from v1
  * Fix CONFIG_PGTABLE_MAPPING in zsmalloc-main.c - Greg

Cc: Andrew Morton 
Cc: Seth Jennings 
Cc: Nitin Gupta 
Cc: Dan Magenheimer 
Cc: Konrad Rzeszutek Wilk 
Signed-off-by: Minchan Kim 
---
 drivers/staging/zsmalloc/Kconfig | 13 +
 drivers/staging/zsmalloc/zsmalloc-main.c | 19 ---
 2 files changed, 17 insertions(+), 15 deletions(-)

diff --git a/drivers/staging/zsmalloc/Kconfig b/drivers/staging/zsmalloc/Kconfig
index 9084565..83f9cec 100644
--- a/drivers/staging/zsmalloc/Kconfig
+++ b/drivers/staging/zsmalloc/Kconfig
@@ -8,3 +8,16 @@ config ZSMALLOC
  non-standard allocator interface where a handle, not a pointer, is
  returned by an alloc().  This handle must be mapped in order to
  access the allocated space.
+
+config PGTABLE_MAPPING
+   bool "Use page table mapping to access object in zsmalloc"
+   depends on ZSMALLOC
+   help
+ By default, zsmalloc uses a copy-based object mapping method to
+ access allocations that span two pages. However, if a particular
+ architecture (ex, ARM) performs VM mapping faster than copying,
+ then you should select this. This causes zsmalloc to use page table
+ mapping rather than copying for object mapping.
+
+ You can check speed with zsmalloc benchmark[1].
+ [1] https://github.com/spartacus06/zsmalloc
diff --git a/drivers/staging/zsmalloc/zsmalloc-main.c 
b/drivers/staging/zsmalloc/zsmalloc-main.c
index 06f73a9..aa6aac4 100644
--- a/drivers/staging/zsmalloc/zsmalloc-main.c
+++ b/drivers/staging/zsmallo

Re: [PATCH v3 1/3] drm/exynos: Get HDMI version from device tree

[Stephen Warren]

On 02/05/2013 05:56 PM, Sean Paul wrote:
> On Tue, Feb 5, 2013 at 4:42 PM, Stephen Warren  wrote:
>> On 02/05/2013 05:37 PM, Sean Paul wrote:
>>> On Tue, Feb 5, 2013 at 4:22 PM, Stephen Warren  
>>> wrote:
 n 02/05/2013 04:42 PM, Sean Paul wrote:
> Use the compatible string in the device tree to determine which
> registers/functions to use in the HDMI driver. Also changes the
> references from v13 to 4210 and v14 to 4212 to reflect the IP
> block version instead of the HDMI version.

> diff --git a/Documentation/devicetree/bindings/drm/exynos/hdmi.txt 
> b/Documentation/devicetree/bindings/drm/exynos/hdmi.txt

 Binding looks sane to me.

> diff --git a/drivers/gpu/drm/exynos/exynos_hdmi.c 
> b/drivers/gpu/drm/exynos/exynos_hdmi.c

>  #ifdef CONFIG_OF
>  static struct of_device_id hdmi_match_types[] = {
>   {
> - .compatible = "samsung,exynos5-hdmi",
> - .data   = (void *)HDMI_TYPE14,
> + .compatible = "samsung,exynos4-hdmi",
>   }, {
>   /* end node */
>   }

 Why not fill in all the "base" compatible values there (I think you need
 this anyway so that DTs don't all have to be compatible with
 samsung,exynos4-hdmi), with .data containing the HDMI_VER_EXYNOS*
 values, then ...

>>>
>>> At the moment, all DTs have to be compatible with exynos4-hdmi since
>>> it provides the base for the current driver. The driver uses 4210 and
>>> 4212 to differentiate between different register addresses and
>>> features, but most things are just exynos4-hdmi compatible.
>>
>> The DT nodes should include only the compatible values that the HW is
>> actually compatible with. If the HW isn't compatible with exynos4-hdmi,
>> that value shouldn't be in the compatible property, but instead whatever
>> the "base" value that the HW really is compatible with. The driver can
>> support multiple "base" compatible values from this table.
> 
> All devices that use this driver are compatible, at some level, with
> exynos4-hdmi, so I think its usage is correct here.

But can a driver that only knows about the original exynos4-hdmi operate
any of the HW correctly without any additional knowledge? If not, the
new HW isn't compatible with the old.

> @@ -2218,17 +2217,18 @@ static int hdmi_probe(struct platform_device 
> *pdev)

> +
> + if (of_device_is_compatible(dev->of_node, 
> "samsung,exynos4210-hdmi"))
> + hdata->version |= HDMI_VER_EXYNOS4210;
> + if (of_device_is_compatible(dev->of_node, 
> "samsung,exynos4212-hdmi"))
> + hdata->version |= HDMI_VER_EXYNOS4212;
> + if (of_device_is_compatible(dev->of_node, 
> "samsung,exynos5250-hdmi"))
> + hdata->version |= HDMI_VER_EXYNOS5250;

 Instead of that, do roughly:

 match = of_match_device(hdmi_match_types, >dev);
 if (match)
 hdata->version |= (int)match->data;

 That way, it's all table-based. Any future additions to
 hdmi_match_types[] won't require another if statement to be added to
 probe().
>>>
>>> I don't think it's that easy. of_match_device returns the first match
>>> from the device table, so I'd still need to iterate through the
>>> matches. I could still break this out into a table, but I don't think
>>> of_match_device is the right way to probe it.
>>
>> You shouldn't have to iterate over multiple matches. of_match_device()
>> is supposed to return the match for the first entry in the compatible
>> property, then if there was no match, move on to looking at the next
>> entry in the compatible property, etc. In practice, I think it's still
>> not implemented quite correctly for this, but you can make it work by
>> putting the newest compatible value first in the match table.
> 
> I think the only way that works is if you hardcode the compatible
> versions in the driver, like this:
> 
> static struct of_device_id hdmi_match_types[] = {
> {
> .compatible = "samsung,exynos5250-hdmi",
> .data = (void *)(HDMI_VER_EXYNOS5250 | HDMI_VER_EXYNOS4212);
> }, {
> .compatible = "samsung,exynos4212-hdmi",
> .data = (void *)HDMI_VER_EXYNOS4212;
> }, {
> .compatible = "samsung,exynos4210-hdmi",
> .data = (void *)HDMI_VER_EXYNOS4210;
> }, {
> /* end node */
> }
> };
> 
> In that case, it eliminates the benefit of using device tree to
> determine the compatible bits. I hope I'm just being thick and missing
> something.

The table above looks /almost/ exactly correct to me, although I'm
unsure why samsung,exynos5250-hdmi has *two* version values; surely
there's a 1:1 mapping between the compatible values and the HW
compatibility they represent? That's certainly the intent.

Perhaps the "two values" think is because 

Re: [PATCH v2 linux-next 1/2] cpufreq: Convert the cpufreq_driver_lock to a rwlock

[Viresh Kumar]

On 6 February 2013 07:34, Nathan Zimmer  wrote:
> This eliminates the contention I am seeing in __cpufreq_cpu_get.
> It also nicely stages the lock to be replaced by the rcu.
>
> Cc: Viresh Kumar 
> Cc: "Rafael J. Wysocki" 
> Signed-off-by: Nathan Zimmer 
> ---
>  drivers/cpufreq/cpufreq.c | 42 +-
>  1 file changed, 21 insertions(+), 21 deletions(-)

Acked-by: Viresh Kumar 
--
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/

Re: [PATCH 2/7] cpufreq: Retrieve current frequency from scaling drivers with internal governors

[Viresh Kumar]

On 6 February 2013 08:01, Dirk Brandewie  wrote:
> diff --git a/drivers/cpufreq/cpufreq.c b/drivers/cpufreq/cpufreq.c
> index 2817c3c..7516b7d 100644
> --- a/drivers/cpufreq/cpufreq.c
> +++ b/drivers/cpufreq/cpufreq.c
> @@ -1178,9 +1178,14 @@ static void cpufreq_out_of_sync(unsigned int cpu,
> unsigned int old_freq,
>   */
>
>  unsigned int cpufreq_quick_get(unsigned int cpu)
>  {
> -   struct cpufreq_policy *policy = cpufreq_cpu_get(cpu);
> +   struct cpufreq_policy *policy;
>
> unsigned int ret_freq = 0;
>
> +   if (cpufreq_driver && cpufreq_driver->setpolicy &&
> +   cpufreq_driver->get)
> +   return cpufreq_driver->get(cpu);
> +
> +   policy = cpufreq_cpu_get(cpu);
> if (policy) {
> ret_freq = policy->cur;
> cpufreq_cpu_put(policy);

Acked-by: Viresh Kumar 
--
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/

Re: [PATCH 5/7] cpufreq: balance out cpufreq_cpu_{get,put} for scaling drivers using setpolicy

[Viresh Kumar]

On 6 February 2013 07:38, Dirk Brandewie  wrote:
> On 02/05/2013 05:58 PM, Viresh Kumar wrote:
>>
>> On Tue, Feb 5, 2013 at 11:54 PM,   wrote:
>>>
>>> From: Dirk Brandewie 
>>>
>>> There is an additional reference added to the driver in
>>> cpufreq_add_dev()  that is removed in__cpufreq_governor() if the
>>>
>>> driver implements target().  Remove the last reference when the
>>> driver implements setpolicy()
>>>
>>> Signed-off-by: Dirk Brandewie 
>>>
>>> ---
>>>   drivers/cpufreq/cpufreq.c |3 +++
>>>   1 files changed, 3 insertions(+), 0 deletions(-)
>>>
>>> diff --git a/drivers/cpufreq/cpufreq.c b/drivers/cpufreq/cpufreq.c
>>> index 622e282..d17477b 100644
>>> --- a/drivers/cpufreq/cpufreq.c
>>> +++ b/drivers/cpufreq/cpufreq.c
>>> @@ -1049,6 +1049,9 @@ static int __cpufreq_remove_dev(struct device *dev,
>>> struct subsys_interface *sif
>>>
>>>  if (cpufreq_driver->target)
>>>  __cpufreq_governor(data, CPUFREQ_GOV_STOP);
>>>
>>> +   if (cpufreq_driver->setpolicy)
>>> +   cpufreq_cpu_put(data);
>>
>>
>> I don't understand this patch at all.. I grepped both cpufreq_cpu_get() &
>> put()
>> in bleeding-edge and found everything to be correct.
>>
>> Can you please point me to the exact line numbers ?
>>
>
> Line 878 in cpufreq_add_dev()

Following is line 878:

for_each_online_cpu(sibling) {
struct cpufreq_policy *cp = per_cpu(cpufreq_cpu_data, sibling);
if (cp && cpumask_test_cpu(cpu, cp->related_cpus))
return cpufreq_add_policy_cpu(cpu, sibling, dev);
}

How is this related to your patch?
--
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/

Re: [PATCH 3/7] cpufreq: Only query drivers that implement cpufreq_driver.target()

[Viresh Kumar]

On 6 February 2013 07:36, Dirk Brandewie  wrote:
> On 02/05/2013 05:47 PM, Viresh Kumar wrote:
>>
>> On Tue, Feb 5, 2013 at 11:54 PM,   wrote:
>>>
>>> From: Dirk Brandewie 
>>>
>>> Scaling drivers that implement cpufreq_driver.setpolicy() have
>>> internal governors and may/will change the current operating frequency
>>> very frequently this will cause cpufreq_out_of_sync() to be called
>>> every time. Only call cpufreq_driver.get() for drivers that implement
>>> cpufreq_driver.target()
>>>
>>> Signed-off-by: Dirk Brandewie 
>>> ---
>>>   drivers/cpufreq/cpufreq.c |2 +-
>>>   1 files changed, 1 insertions(+), 1 deletions(-)
>>>
>>> diff --git a/drivers/cpufreq/cpufreq.c b/drivers/cpufreq/cpufreq.c
>>> index 96bc302..d8daa4b 100644
>>> --- a/drivers/cpufreq/cpufreq.c
>>> +++ b/drivers/cpufreq/cpufreq.c
>>> @@ -1787,7 +1787,7 @@ int cpufreq_update_policy(unsigned int cpu)
>>>
>>>  /* BIOS might change freq behind our back
>>>-> ask driver for current freq and notify governors about a
>>> change */
>>> -   if (cpufreq_driver->get) {
>>> +   if (cpufreq_driver->get && cpufreq_driver->target) {
>>>  policy.cur = cpufreq_driver->get(cpu);
>>>  if (!data->cur) {
>>>  pr_debug("Driver did not initialize current
>>> freq");
>>
>>
>> I am really not liking copy-pasting my older comments here :(
>>
>> "This would mean policy->cur has a garbage value. I don't really know
>> how would other routine behave on this. Would it make sense to make
>> policy->cur zero atleast?
>> "
>>
> The driver implements get() and will return a valid value but the other
> components that track the current frequency will not have been notified
> about any change so there is nothing to be out of sync with.  There is no
> reason to call cpufreq_out_of_sync() where the driver being used implements
> an internal
> governor.

Not sure if we are discussing the same issue. What i am saying is, with your
patch we aren't calling following line:

>>>  policy.cur = cpufreq_driver->get(cpu);

and policy was a local variable. Hence policy->cur is having a garbage value.
policy->cur is used at multiple places in cpufreq.c . Please check everywhere
if this garbage value doesn't break set_policy() type systems.
--
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/

Re: [PATCH 2/7] cpufreq: Retrieve current frequency from scaling drivers with internal governors

[Dirk Brandewie]

On 02/05/2013 06:25 PM, Viresh Kumar wrote:

On Wed, Feb 6, 2013 at 7:45 AM, Dirk Brandewie  wrote:

How about this?

diff --git a/drivers/cpufreq/cpufreq.c b/drivers/cpufreq/cpufreq.c
index 2817c3c..9c0eac4 100644
--- a/drivers/cpufreq/cpufreq.c
+++ b/drivers/cpufreq/cpufreq.c
@@ -1182,7 +1182,12 @@ unsigned int cpufreq_quick_get(unsigned int cpu)

 unsigned int ret_freq = 0;

 if (policy) {
-   ret_freq = policy->cur;

+   if (cpufreq_driver && cpufreq_driver->setpolicy &&
+   cpufreq_driver->get) {
+   ret_freq = cpufreq_driver->get(cpu);
+   } else {
+   ret_freq = policy->cur;
+   }
 cpufreq_cpu_put(policy);


diff --git a/drivers/cpufreq/cpufreq.c b/drivers/cpufreq/cpufreq.c
index 2817c3c..7516b7d 100644
--- a/drivers/cpufreq/cpufreq.c
+++ b/drivers/cpufreq/cpufreq.c
@@ -1178,9 +1178,14 @@ static void cpufreq_out_of_sync(unsigned int cpu, 
unsigned int old_freq,

  */
 unsigned int cpufreq_quick_get(unsigned int cpu)
 {
-   struct cpufreq_policy *policy = cpufreq_cpu_get(cpu);
+   struct cpufreq_policy *policy;
unsigned int ret_freq = 0;

+   if (cpufreq_driver && cpufreq_driver->setpolicy &&
+   cpufreq_driver->get)
+   return cpufreq_driver->get(cpu);
+
+   policy = cpufreq_cpu_get(cpu);
if (policy) {
ret_freq = policy->cur;
cpufreq_cpu_put(policy);


--
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/

Re: [PATCH 1/2] mm: hotplug: implement non-movable version of get_user_pages() called get_user_pages_non_movable()

[Michel Lespinasse]

Just nitpicking, but:

On Tue, Feb 5, 2013 at 3:57 AM, Mel Gorman  wrote:
> +static inline bool zone_is_idx(struct zone *zone, enum zone_type idx)
> +{
> +   /* This mess avoids a potentially expensive pointer subtraction. */
> +   int zone_off = (char *)zone - (char *)zone->zone_pgdat->node_zones;
> +   return zone_off == idx * sizeof(*zone);
> +}

Maybe:
return zone == zone->zone_pgdat->node_zones + idx;
?

-- 
Michel "Walken" Lespinasse
A program is never fully debugged until the last user dies.
--
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/

Re: [PATCH v2] zsmalloc: Add Kconfig for enabling PTE method

[Greg Kroah-Hartman]

On Wed, Feb 06, 2013 at 11:17:08AM +0900, Minchan Kim wrote:
> diff --git a/drivers/staging/zsmalloc/Kconfig 
> b/drivers/staging/zsmalloc/Kconfig
> index 9084565..232b3b6 100644
> --- a/drivers/staging/zsmalloc/Kconfig
> +++ b/drivers/staging/zsmalloc/Kconfig
> @@ -8,3 +8,15 @@ config ZSMALLOC
> non-standard allocator interface where a handle, not a pointer, is
> returned by an alloc().  This handle must be mapped in order to
> access the allocated space.
> +
> +config PGTABLE_MAPPING
> +bool "Use page table mapping to access allocations that span two 
> pages"

No tabs?

Please also put "ZSmalloc somewhere in the text here, otherwise it
really doesn't make much sense when seeing it in a menu.

> +depends on ZSMALLOC
> +default n

That's the default, so it can be dropped.

> +help
> +   By default, zsmalloc uses a copy-based object mapping method to access
> +   allocations that span two pages. However, if a particular architecture
> +   performs VM mapping faster than copying, then you should select this.
> +   This causes zsmalloc to use page table mapping rather than copying
> +   for object mapping. You can check speed with zsmalloc benchmark[1].
> +   [1] https://github.com/spartacus06/zsmalloc

Care to specify exactly _what_ architectures this should be set for or
not?  That will help the distros out a lot in determining if this should
be enabled or not.

> diff --git a/drivers/staging/zsmalloc/zsmalloc-main.c 
> b/drivers/staging/zsmalloc/zsmalloc-main.c
> index 06f73a9..2c1805c 100644
> --- a/drivers/staging/zsmalloc/zsmalloc-main.c
> +++ b/drivers/staging/zsmalloc/zsmalloc-main.c
> @@ -207,6 +207,7 @@ struct zs_pool {
>   struct size_class size_class[ZS_SIZE_CLASSES];
>  
>   gfp_t flags;/* allocation flags used when growing pool */
> +
>  };
>  
>  /*

Why add this extra line?

thanks,

greg k-h
--
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/

Re: Question on lockdep and MAX_LOCK_DEPTH

[Ben Greear]

On 02/05/2013 05:54 PM, Steven Rostedt wrote:

On Tue, Feb 05, 2013 at 05:10:37PM -0800, Ben Greear wrote:

I'm debugging something that could be my own bug in my wanlink module (but then
again, haven't seen this on 3.5 kernels, and my module is
basically un-changed since then).

I'm using lockdep, and keep seeing "BUG: MAX_LOCK_DEPTH too low".
I tried changing the depth to 96 from 48, but it still hits.

I also added debug_show_all_locks(); when this error
case hits.  I was assuming that if lockdep depth is large,
there would be lots of locks held..but that does not
seem to be the case??



Perhaps what you want to do is add a:

lockdep_print_held_locks(current);


Well, here it is..something is calling rcu_read_lock lots and lots,
it seems.  Any way to get a better idea of where those calls are
made?

Showing all locks held in the system:
1 lock held by mingetty/2868:
 #0:  (>atomic_read_lock){+.+...}, at: [] 
n_tty_read+0x28d/0x785
1 lock held by mingetty/2870:
 #0:  (>atomic_read_lock){+.+...}, at: [] 
n_tty_read+0x28d/0x785
1 lock held by mingetty/2872:
 #0:  (>atomic_read_lock){+.+...}, at: [] 
n_tty_read+0x28d/0x785
1 lock held by mingetty/2874:
 #0:  (>atomic_read_lock){+.+...}, at: [] 
n_tty_read+0x28d/0x785
1 lock held by mingetty/2876:
 #0:  (>atomic_read_lock){+.+...}, at: [] 
n_tty_read+0x28d/0x785
1 lock held by mingetty/2878:
 #0:  (>atomic_read_lock){+.+...}, at: [] 
n_tty_read+0x28d/0x785
1 lock held by bash/3337:
 #0:  (>atomic_read_lock){+.+...}, at: [] 
n_tty_read+0x28d/0x785
1 lock held by bash/3369:
 #0:  (>atomic_read_lock){+.+...}, at: [] 
n_tty_read+0x28d/0x785

=

96 locks held by swapper/0/0:
 #0:  (rcu_read_lock){.+.+..}, at: [] rcu_read_lock+0x0/0x6f
 #1:  (rcu_read_lock){.+.+..}, at: [] rcu_read_lock+0x0/0x6f
 #2:  (rcu_read_lock){.+.+..}, at: [] rcu_read_lock+0x0/0x6f
 #3:  (rcu_read_lock){.+.+..}, at: [] rcu_read_lock+0x0/0x6f
 #4:  (rcu_read_lock){.+.+..}, at: [] rcu_read_lock+0x0/0x6f
 #5:  (rcu_read_lock){.+.+..}, at: [] rcu_read_lock+0x0/0x6f
 #6:  (rcu_read_lock){.+.+..}, at: [] rcu_read_lock+0x0/0x6f
 #7:  (rcu_read_lock){.+.+..}, at: [] rcu_read_lock+0x0/0x6f
 #8:  (rcu_read_lock){.+.+..}, at: [] rcu_read_lock+0x0/0x6f
 #9:  (rcu_read_lock){.+.+..}, at: [] rcu_read_lock+0x0/0x6f
 #10:  (rcu_read_lock){.+.+..}, at: [] rcu_read_lock+0x0/0x6f
 #11:  (rcu_read_lock){.+.+..}, at: [] rcu_read_lock+0x0/0x6f
 #12:  (rcu_read_lock){.+.+..}, at: [] rcu_read_lock+0x0/0x6f
 #13:  (rcu_read_lock){.+.+..}, at: [] rcu_read_lock+0x0/0x6f
 #14:  (rcu_read_lock){.+.+..}, at: [] rcu_read_lock+0x0/0x6f
 #15:  (rcu_read_lock){.+.+..}, at: [] rcu_read_lock+0x0/0x6f
 #16:  (rcu_read_lock){.+.+..}, at: [] rcu_read_lock+0x0/0x6f
 #17:  (rcu_read_lock){.+.+..}, at: [] rcu_read_lock+0x0/0x6f
 #18:  (rcu_read_lock){.+.+..}, at: [] rcu_read_lock+0x0/0x6f
 #19:  (rcu_read_lock){.+.+..}, at: [] rcu_read_lock+0x0/0x6f
 #20:  (rcu_read_lock){.+.+..}, at: [] rcu_read_lock+0x0/0x6f
 #21:  (rcu_read_lock){.+.+..}, at: [] rcu_read_lock+0x0/0x6f
 #22:  (rcu_read_lock){.+.+..}, at: [] rcu_read_lock+0x0/0x6f
 #23:  (rcu_read_lock){.+.+..}, at: [] rcu_read_lock+0x0/0x6f
 #24:  (rcu_read_lock){.+.+..}, at: [] rcu_read_lock+0x0/0x6f
 #25:  (rcu_read_lock){.+.+..}, at: [] rcu_read_lock+0x0/0x6f
 #26:  (rcu_read_lock){.+.+..}, at: [] rcu_read_lock+0x0/0x6f
 #27:  (rcu_read_lock){.+.+..}, at: [] rcu_read_lock+0x0/0x6f
 #28:  (rcu_read_lock){.+.+..}, at: [] rcu_read_lock+0x0/0x6f
 #29:  (rcu_read_lock){.+.+..}, at: [] rcu_read_lock+0x0/0x6f
 #30:  (rcu_read_lock){.+.+..}, at: [] rcu_read_lock+0x0/0x6f
 #31:  (rcu_read_lock){.+.+..}, at: [] rcu_read_lock+0x0/0x6f
 #32:  (rcu_read_lock){.+.+..}, at: [] rcu_read_lock+0x0/0x6f
 #33:  (rcu_read_lock){.+.+..}, at: [] rcu_read_lock+0x0/0x6f
 #34:  (rcu_read_lock){.+.+..}, at: [] rcu_read_lock+0x0/0x6f
 #35:  (rcu_read_lock){.+.+..}, at: [] rcu_read_lock+0x0/0x6f
 #36:  (rcu_read_lock){.+.+..}, at: [] rcu_read_lock+0x0/0x6f
 #37:  (rcu_read_lock){.+.+..}, at: [] rcu_read_lock+0x0/0x6f
 #38:  (rcu_read_lock){.+.+..}, at: [] rcu_read_lock+0x0/0x6f
 #39:  (rcu_read_lock){.+.+..}, at: [] rcu_read_lock+0x0/0x6f
 #40:  (rcu_read_lock){.+.+..}, at: [] rcu_read_lock+0x0/0x6f
 #41:  (rcu_read_lock){.+.+..}, at: [] rcu_read_lock+0x0/0x6f
 #42:  (rcu_read_lock){.+.+..}, at: [] rcu_read_lock+0x0/0x6f
 #43:  (rcu_read_lock){.+.+..}, at: [] rcu_read_lock+0x0/0x6f
 #44:  (rcu_read_lock){.+.+..}, at: [] rcu_read_lock+0x0/0x6f
 #45:  (rcu_read_lock){.+.+..}, at: [] rcu_read_lock+0x0/0x6f
 #46:  (rcu_read_lock){.+.+..}, at: [] rcu_read_lock+0x0/0x6f
 #47:  (rcu_read_lock){.+.+..}, at: [] rcu_read_lock+0x0/0x6f
 #48:  (rcu_read_lock){.+.+..}, at: [] rcu_read_lock+0x0/0x6f
 #49:  (rcu_read_lock){.+.+..}, at: [] rcu_read_lock+0x0/0x6f
 #50:  (rcu_read_lock){.+.+..}, at: [] rcu_read_lock+0x0/0x6f
 #51:  (rcu_read_lock){.+.+..}, at: [] rcu_read_lock+0x0/0x6f
 #52:  (rcu_read_lock){.+.+..}, at: [] rcu_read_lock+0x0/0x6f
 #53:  

Re: [PATCH 2/7] cpufreq: Retrieve current frequency from scaling drivers with internal governors

[Viresh Kumar]

On Wed, Feb 6, 2013 at 7:45 AM, Dirk Brandewie  wrote:
> How about this?
>
> diff --git a/drivers/cpufreq/cpufreq.c b/drivers/cpufreq/cpufreq.c
> index 2817c3c..9c0eac4 100644
> --- a/drivers/cpufreq/cpufreq.c
> +++ b/drivers/cpufreq/cpufreq.c
> @@ -1182,7 +1182,12 @@ unsigned int cpufreq_quick_get(unsigned int cpu)
>
> unsigned int ret_freq = 0;
>
> if (policy) {
> -   ret_freq = policy->cur;
>
> +   if (cpufreq_driver && cpufreq_driver->setpolicy &&
> +   cpufreq_driver->get) {
> +   ret_freq = cpufreq_driver->get(cpu);
> +   } else {
> +   ret_freq = policy->cur;
> +   }
> cpufreq_cpu_put(policy);

The problem is: You don't need to do get/put in your case at all.
--
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/

Re: [PATCH 3/3] acpi, memory-hotplug: Support getting hotplug info from SRAT.

[Tang Chen]

On 02/05/2013 07:26 AM, Andrew Morton wrote:

On Fri, 25 Jan 2013 17:42:09 +0800
Tang Chen  wrote:


We now provide an option for users who don't want to specify physical
memory address in kernel commandline.

 /*
  * For movablemem_map=acpi:
  *
  * SRAT:|_| |_| |_| |_| ..
  * node id:0   1 1   2
  * hotpluggable:   n   y y   n
  * movablemem_map:  |_| |_|
  *
  * Using movablemem_map, we can prevent memblock from allocating memory
  * on ZONE_MOVABLE at boot time.
  */

So user just specify movablemem_map=acpi, and the kernel will use hotpluggable
info in SRAT to determine which memory ranges should be set as ZONE_MOVABLE.

...

+   if (!strncmp(p, "acpi", max(4, strlen(p
+   movablemem_map.acpi = true;


Generates a warning:

mm/page_alloc.c: In function 'cmdline_parse_movablemem_map':
mm/page_alloc.c:5312: warning: comparison of distinct pointer types lacks a cast

due to max(int, size_t).

This is easily fixed, but the code looks rather pointless.  If the
incoming string is supposed to be exactly "acpi" then use strcmp().  If
the incoming string must start with "acpi" then use strncmp(p, "acpi", 4).

IOW, the max is unneeded?


Hi Andrew,

I think I made another mistake here. I meant to use min(4, strlen(p)) in 
case p is
something like 'aaa' whose length is less then 4. But I mistook it with 
max().


But after I dig into strcmp() in the kernel, I think it is OK to use 
strcmp().

min() or max() is not needed.

Thanks. :)



--
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/


--
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/

linux-next: manual merge of the crypto tree with the net-next tree

[Stephen Rothwell]

Hi Herbert,

Today's linux-next merge of the crypto tree got a conflict in
crypto/ctr.c between commit 69d3150cfc20 ("crypto: ctr - make rfc3686
asynchronous block cipher") from the net-next tree and commit
3e8afe35c36f ("crypto: use ERR_CAST") from the crypto tree.

I fixed it up (see below) and can carry the fix as necessary (no action
is required).

-- 
Cheers,
Stephen Rothwells...@canb.auug.org.au

diff --cc crypto/ctr.c
index 1f2997c,095dcb6..000
--- a/crypto/ctr.c
+++ b/crypto/ctr.c
@@@ -335,40 -324,18 +335,38 @@@ static void crypto_rfc3686_exit_tfm(str
  
  static struct crypto_instance *crypto_rfc3686_alloc(struct rtattr **tb)
  {
 +  struct crypto_attr_type *algt;
struct crypto_instance *inst;
struct crypto_alg *alg;
 +  struct crypto_skcipher_spawn *spawn;
 +  const char *cipher_name;
int err;
  
 -  err = crypto_check_attr_type(tb, CRYPTO_ALG_TYPE_BLKCIPHER);
 +  algt = crypto_get_attr_type(tb);
-   err = PTR_ERR(algt);
 +  if (IS_ERR(algt))
-   return ERR_PTR(err);
++  return ERR_CAST(algt);
 +
 +  if ((algt->type ^ CRYPTO_ALG_TYPE_BLKCIPHER) & algt->mask)
 +  return ERR_PTR(-EINVAL);
 +
 +  cipher_name = crypto_attr_alg_name(tb[1]);
-   err = PTR_ERR(cipher_name);
 +  if (IS_ERR(cipher_name))
-   return ERR_PTR(err);
++  return ERR_CAST(cipher_name);
 +
 +  inst = kzalloc(sizeof(*inst) + sizeof(*spawn), GFP_KERNEL);
 +  if (!inst)
 +  return ERR_PTR(-ENOMEM);
 +
 +  spawn = crypto_instance_ctx(inst);
 +
 +  crypto_set_skcipher_spawn(spawn, inst);
 +  err = crypto_grab_skcipher(spawn, cipher_name, 0,
 + crypto_requires_sync(algt->type,
 +  algt->mask));
if (err)
 -  return ERR_PTR(err);
 +  goto err_free_inst;
  
 -  alg = crypto_attr_alg(tb[1], CRYPTO_ALG_TYPE_BLKCIPHER,
 -CRYPTO_ALG_TYPE_MASK);
 -  if (IS_ERR(alg))
 -  return ERR_CAST(alg);
 +  alg = crypto_skcipher_spawn_alg(spawn);
  
/* We only support 16-byte blocks. */
err = -EINVAL;


pgp223AEUclT_.pgp
Description: PGP signature

Re: Question on lockdep and MAX_LOCK_DEPTH

[Ben Greear]

On 02/05/2013 05:54 PM, Steven Rostedt wrote:


I'm not sure the swapper task is part of the 'do_each_thread()' loop.

Perhaps what you want to do is add a:

lockdep_print_held_locks(current);


I'll add that and test...


I'm curious. Does your code grab a read lock? If you grab the same read
lock multiple times it adds to the list each time. Thus if you have
anything like:

for (i = 0; i < 100; i++ ) {
read_lock();
}

for (i = 0; i < 100; i++) {
read_unlock();
}

That will fill up the held locks quite a bit.

The above code I showed is ridiculous and I doubt you have it, but if
you have something that does lots of recursive reads for some reason,
that could be an issue.


I have only one read/write lock in my module, and it looks like
I always lock it as a writer (will fix that soon for performance
reasons, but it should be valid locking I think).

I have no rcu locks at all in my module currently.

I've seen similar lockups on another machine that does not use
this module, but it uses a hacked up pktgen.  I haven't found
a test case that reproduces this on a clean upstream build,
but I am still fairly suspicious that it isn't my code.
Famous last words I'm sure :)

Thanks,
Ben

--
Ben Greear 
Candela Technologies Inc  http://www.candelatech.com

--
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/