Re: [PATCH 01/10] mm: vmscan: Limit the number of pages kswapd reclaims at each priority

[Will Huck]

Hi Rik,
On 03/22/2013 11:52 AM, Rik van Riel wrote:

On 03/21/2013 08:05 PM, Will Huck wrote:


One offline question, how to understand this in function balance_pgdat:
/*
  * Do some background aging of the anon list, to give
  * pages a chance to be referenced before reclaiming.
  */
age_acitve_anon(zone, );


The anon lrus use a two-handed clock algorithm. New anonymous pages
start off on the active anon list. Older anonymous pages get moved
to the inactive anon list.


The downside of page cache use-once replacement algorithm is 
inter-reference distance, corret? Does it have any other downside? 
What's the downside of two-handed clock algorithm against anonymous pages?




If they get referenced before they reach the end of the inactive anon
list, they get moved back to the active list.

If we need to swap something out and find a non-referenced page at the
end of the inactive anon list, we will swap it out.

In order to make good pageout decisions, pages need to stay on the
inactive anon list for a longer time, so they have plenty of time to
get referenced, before the reclaim code looks at them.

To achieve that, we will move some active anon pages to the inactive
anon list even when we do not want to swap anything out - as long as
the inactive anon list is below its target size.

Does that make sense?



--
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 01/10] mm: vmscan: Limit the number of pages kswapd reclaims at each priority

[Will Huck]

Hi Rik,
On 03/22/2013 11:52 AM, Rik van Riel wrote:

On 03/21/2013 08:05 PM, Will Huck wrote:


One offline question, how to understand this in function balance_pgdat:
/*
  * Do some background aging of the anon list, to give
  * pages a chance to be referenced before reclaiming.
  */
age_acitve_anon(zone, );


The anon lrus use a two-handed clock algorithm. New anonymous pages


Why the algorithm has relationship with two-handed clock?


start off on the active anon list. Older anonymous pages get moved
to the inactive anon list.

If they get referenced before they reach the end of the inactive anon
list, they get moved back to the active list.

If we need to swap something out and find a non-referenced page at the
end of the inactive anon list, we will swap it out.

In order to make good pageout decisions, pages need to stay on the
inactive anon list for a longer time, so they have plenty of time to
get referenced, before the reclaim code looks at them.

To achieve that, we will move some active anon pages to the inactive
anon list even when we do not want to swap anything out - as long as
the inactive anon list is below its target size.

Does that make sense?



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

cirrusfb: possible circular locking dependency

[dyoung]

lockdep is complaining about below, I see it often in kvm guests,
False postive?

[  600.383445] ==
[  600.383447] [ INFO: possible circular locking dependency detected ]
[  600.383452] 3.9.0-rc5+ #71 Not tainted
[  600.383454] ---
[  600.383458] kworker/0:2/1254 is trying to acquire lock:
[  600.383475]  (_info->lock){+.+.+.}, at: [] 
lock_fb_info+0x18/0x37
[  600.383477] 
[  600.383477] but task is already holding lock:
[  600.383490]  (console_lock){+.+.+.}, at: [] 
console_callback+0xb/0xf5
[  600.383491] 
[  600.383491] which lock already depends on the new lock.
[  600.383491] 
[  600.383493] 
[  600.383493] the existing dependency chain (in reverse order) is:
[  600.383499] 
[  600.383499] -> #1 (console_lock){+.+.+.}:
[  600.383509][] lock_acquire+0xa3/0x115
[  600.383516][] console_lock+0x59/0x5b
[  600.383522][] register_framebuffer+0x20d/0x284
[  600.383530][] cirrusfb_pci_register+0x57a/0x617
[  600.383537][] pci_device_probe+0x6b/0xb1
[  600.383544][] driver_probe_device+0x117/0x2ef
[  600.383549][] __driver_attach+0x4e/0x6f
[  600.383554][] bus_for_each_dev+0x57/0x89
[  600.383559][] driver_attach+0x19/0x1b
[  600.383564][] bus_add_driver+0x11d/0x242
[  600.383569][] driver_register+0x8e/0x114
[  600.383575][] __pci_register_driver+0x5d/0x62
[  600.383584][] cirrusfb_init+0x52/0xc0
[  600.383594][] do_one_initcall+0x7a/0x136
[  600.383600][] kernel_init_freeable+0x141/0x1d0
[  600.383609][] kernel_init+0x9/0xcc
[  600.383615][] ret_from_fork+0x7c/0xb0
[  600.383621] 
[  600.383621] -> #0 (_info->lock){+.+.+.}:
[  600.383627][] __lock_acquire+0xae5/0xe78
[  600.383632][] lock_acquire+0xa3/0x115
[  600.383642][] __mutex_lock_common+0x44/0x32e
[  600.383648][] mutex_lock_nested+0x2a/0x31
[  600.383653][] lock_fb_info+0x18/0x37
[  600.383661][] fbcon_blank+0x168/0x1ee
[  600.383668][] do_blank_screen+0x13e/0x1d8
[  600.383675][] console_callback+0xcb/0xf5
[  600.383684][] process_one_work+0x1e8/0x38c
[  600.383691][] worker_thread+0x130/0x1df
[  600.383699][] kthread+0xac/0xb4
[  600.383703][] ret_from_fork+0x7c/0xb0
[  600.383705] 
[  600.383705] other info that might help us debug this:
[  600.383705] 
[  600.383707]  Possible unsafe locking scenario:
[  600.383707] 
[  600.383708]CPU0CPU1
[  600.383710]
[  600.383713]   lock(console_lock);
[  600.383717]lock(_info->lock);
[  600.383720]lock(console_lock);
[  600.383724]   lock(_info->lock);
[  600.383725] 
[  600.383725]  *** DEADLOCK ***
[  600.383725] 
[  600.383728] 3 locks held by kworker/0:2/1254:
[  600.383739]  #0:  (events){.+.+.+}, at: [] 
process_one_work+0x170/0x38c
[  600.383749]  #1:  (console_work){+.+...}, at: [] 
process_one_work+0x170/0x38c
[  600.383759]  #2:  (console_lock){+.+.+.}, at: [] 
console_callback+0xb/0xf5
[  600.383761] 
[  600.383761] stack backtrace:
[  600.383765] Pid: 1254, comm: kworker/0:2 Not tainted 3.9.0-rc5+ #71
[  600.383767] Call Trace:
[  600.383775]  [] print_circular_bug+0x1f8/0x209
[  600.383782]  [] __lock_acquire+0xae5/0xe78
[  600.383788]  [] ? cirrusfb_set_blitter+0x169/0x178
[  600.383794]  [] lock_acquire+0xa3/0x115
[  600.383799]  [] ? lock_fb_info+0x18/0x37
[  600.383807]  [] __mutex_lock_common+0x44/0x32e
[  600.383811]  [] ? lock_fb_info+0x18/0x37
[  600.383816]  [] ? lock_fb_info+0x18/0x37
[  600.383823]  [] ? bit_clear+0xa7/0xb4
[  600.383831]  [] mutex_lock_nested+0x2a/0x31
[  600.383836]  [] lock_fb_info+0x18/0x37
[  600.383842]  [] fbcon_blank+0x168/0x1ee
[  600.383848]  [] ? _raw_spin_unlock_irqrestore+0x40/0x4d
[  600.383855]  [] ? trace_hardirqs_on_caller+0x112/0x1ad
[  600.383860]  [] ? _raw_spin_unlock_irqrestore+0x48/0x4d
[  600.383868]  [] ? try_to_del_timer_sync+0x50/0x5c
[  600.383875]  [] ? del_timer_sync+0xa3/0xc9
[  600.383881]  [] ? try_to_del_timer_sync+0x5c/0x5c
[  600.383887]  [] do_blank_screen+0x13e/0x1d8
[  600.383894]  [] console_callback+0xcb/0xf5
[  600.383901]  [] process_one_work+0x1e8/0x38c
[  600.383908]  [] ? process_one_work+0x170/0x38c
[  600.383915]  [] worker_thread+0x130/0x1df
[  600.383922]  [] ? manage_workers+0x245/0x245
[  600.383928]  [] kthread+0xac/0xb4
[  600.383936]  [] ? __kthread_parkme+0x60/0x60
[  600.383941]  [] ret_from_fork+0x7c/0xb0
[  600.383948]  [] ? __kthread_parkme+0x60/0x60
--
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] kernel: kallsyms: memory override issue, need check destination buffer length

[Chen Gang]

  We don't export any symbols > 128 characters, but if we did then
  kallsyms_expand_symbol() would overflow the buffer handed to it.
  So we need check destination buffer length when copying.

  the related test:
if we define an EXPORT function which name more than 128.
will panic when call kallsyms_lookup_name by init_kprobes on booting.
after check the length (provide this patch), it is ok.

  Implementaion:
add additional destination buffer length parameter (maxlen)
if uncompressed string is too long (>= maxlen), it will be truncated.
not check the parameters whether valid, since it is a static function.


Signed-off-by: Chen Gang 
---
 kernel/kallsyms.c |   26 ++
 1 files changed, 18 insertions(+), 8 deletions(-)

diff --git a/kernel/kallsyms.c b/kernel/kallsyms.c
index 2169fee..43d8150 100644
--- a/kernel/kallsyms.c
+++ b/kernel/kallsyms.c
@@ -84,9 +84,11 @@ static int is_ksym_addr(unsigned long addr)
 
 /*
  * Expand a compressed symbol data into the resulting uncompressed string,
+ * if uncompressed string is too long (>= maxlen), it will be truncated,
  * given the offset to where the symbol is in the compressed stream.
  */
-static unsigned int kallsyms_expand_symbol(unsigned int off, char *result)
+static unsigned int kallsyms_expand_symbol(unsigned int off,
+  char *result, size_t maxlen)
 {
int len, skipped_first = 0;
const u8 *tptr, *data;
@@ -113,15 +115,20 @@ static unsigned int kallsyms_expand_symbol(unsigned int 
off, char *result)
 
while (*tptr) {
if (skipped_first) {
+   if (maxlen <= 1)
+   goto tail;
*result = *tptr;
result++;
+   maxlen--;
} else
skipped_first = 1;
tptr++;
}
}
 
-   *result = '\0';
+tail:
+   if (maxlen)
+   *result = '\0';
 
/* Return to offset to the next symbol. */
return off;
@@ -176,7 +183,7 @@ unsigned long kallsyms_lookup_name(const char *name)
unsigned int off;
 
for (i = 0, off = 0; i < kallsyms_num_syms; i++) {
-   off = kallsyms_expand_symbol(off, namebuf);
+   off = kallsyms_expand_symbol(off, namebuf, ARRAY_SIZE(namebuf));
 
if (strcmp(namebuf, name) == 0)
return kallsyms_addresses[i];
@@ -195,7 +202,7 @@ int kallsyms_on_each_symbol(int (*fn)(void *, const char *, 
struct module *,
int ret;
 
for (i = 0, off = 0; i < kallsyms_num_syms; i++) {
-   off = kallsyms_expand_symbol(off, namebuf);
+   off = kallsyms_expand_symbol(off, namebuf, ARRAY_SIZE(namebuf));
ret = fn(data, namebuf, NULL, kallsyms_addresses[i]);
if (ret != 0)
return ret;
@@ -294,7 +301,8 @@ const char *kallsyms_lookup(unsigned long addr,
 
pos = get_symbol_pos(addr, symbolsize, offset);
/* Grab name */
-   kallsyms_expand_symbol(get_symbol_offset(pos), namebuf);
+   kallsyms_expand_symbol(get_symbol_offset(pos),
+  namebuf, ARRAY_SIZE(namebuf));
if (modname)
*modname = NULL;
return namebuf;
@@ -315,7 +323,8 @@ int lookup_symbol_name(unsigned long addr, char *symname)
 
pos = get_symbol_pos(addr, NULL, NULL);
/* Grab name */
-   kallsyms_expand_symbol(get_symbol_offset(pos), symname);
+   kallsyms_expand_symbol(get_symbol_offset(pos),
+  symname, ARRAY_SIZE(symname));
return 0;
}
/* See if it's in a module. */
@@ -333,7 +342,8 @@ int lookup_symbol_attrs(unsigned long addr, unsigned long 
*size,
 
pos = get_symbol_pos(addr, size, offset);
/* Grab name */
-   kallsyms_expand_symbol(get_symbol_offset(pos), name);
+   kallsyms_expand_symbol(get_symbol_offset(pos),
+  name, ARRAY_SIZE(name));
modname[0] = '\0';
return 0;
}
@@ -463,7 +473,7 @@ static unsigned long get_ksymbol_core(struct kallsym_iter 
*iter)
 
iter->type = kallsyms_get_symbol_type(off);
 
-   off = kallsyms_expand_symbol(off, iter->name);
+   off = kallsyms_expand_symbol(off, iter->name, ARRAY_SIZE(iter->name));
 
return off - iter->nameoff;
 }
-- 
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] Do not force shutdown/reboot to boot cpu.

[Paul Mackerras]

On Wed, Apr 10, 2013 at 08:10:05AM -0700, Linus Torvalds wrote:
> The optimal solution would be to just speed up the
> disable_nonboot_cpus() code so much that it isn't an issue. That would
> be good for suspending too, although I guess suspend isn't a big issue
> if you have a thousand CPU's.
> 
> Has anybody checked whether we could do the cpu_down() on non-boot
> CPU's in parallel? Right now we serialize the thing completely, with

I thought Srivatsa S. Bhat had a patchset that did exactly that.
Srivatsa?

Paul.
--
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 tip tree

[Stephen Rothwell]

Hi Greg,

Today's linux-next merge of the driver-core tree got a conflict in
kernel/rtmutex-tester.c between commit 8184004ed7a0
("locking/rtmutex/tester: Set correct permissions on sysfs files") from
the tip tree and commit 928c0c1571b0 ("rtmutex-tester: fix mode of sysfs
files") from the driver-core tree.

Both patches do the same thing - I used the tip version and can carry the
fix as necessary (no action is required).

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


pgpXUABC7II6V.pgp
Description: PGP signature

Re: [PATCH] drm/i915: don't check inconsistent modeset state when force-restoring

[Tomas Melin]

On Wed, Apr 10, 2013 at 9:32 PM, Tomas Melin  wrote:
> On Tue, Apr 9, 2013 at 10:51 PM, Daniel Vetter  wrote:
>> v2: Try harder not to create a big patch (Chris).
>>
> Tested the patch applied to 3.9-rc6. Atleast on my machine that
> helped, although once I managed to get the error (but not warning and
> call trace as before):
> [drm:i9xx_crtc_mode_set] *ERROR* Couldn't find PLL settings for mode!
>

Update: the situation where I still get an error is if the machine is
in standby with the lid open. Then close and open will generate that
kind of error. The patch however fixes the original problem.

thanks,
Tomas
--
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 13/30] video/s3c: move platform_data out of arch/arm

[Jingoo Han]

On Thursday, April 11, 2013 9:05 AM, Arnd Bergmann wrote:
> 
> The s3c-fb driver requires header files from the samsung platforms
> to find its platform_data definition, but this no longer works on
> multiplatform kernels, so let's move the data into a new header
> file under include/linux/platform_data.
> 
> Signed-off-by: Arnd Bergmann 
> Cc: linux-fb...@vger.kernel.org
> Cc: Jingoo Han 
> ---
>  arch/arm/plat-samsung/include/plat/fb.h | 50 +-
>  drivers/video/s3c-fb.c  |  3 +-
>  include/linux/platform_data/video_s3c.h | 54 
> +
>  3 files changed, 56 insertions(+), 51 deletions(-)
>  create mode 100644 include/linux/platform_data/video_s3c.h
> 

[.]

> +struct s3c_fb_platdata {
> + void(*setup_gpio)(void);
> +
> + struct s3c_fb_pd_win*win[S3C_FB_MAX_WIN];
> + struct fb_videomode *vtiming;
> +
> + u32  vidcon0;
> + u32  vidcon1;
> +};
> + 

There is an unnecessary space.
When the patch is merged, this space should be removed.


Best regards,
Jingoo Han

> +#endif
> --
> 1.8.1.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 12/30] video/exynos: remove unnecessary header inclusions

[Jingoo Han]

On Thursday, April 11, 2013 9:05 AM, Arnd Bergmann wrote:
> 
> In multiplatform configurations, we cannot include headers
> provided by only the exynos platform. Fortunately a number
> of drivers that include those headers do not actually need
> them, so we can just remove the inclusions.
> 
> Signed-off-by: Arnd Bergmann 
> Cc: linux-fb...@vger.kernel.org
> Cc: Jingoo Han 

CC'ed Tomi Valkeinen, Inki Dae, Donghwa Lee, Kyungmin Park


Acked-by: Jingoo Han 

Best regards,
Jingoo Han

> ---
>  drivers/video/exynos/exynos_mipi_dsi.c  | 2 --
>  drivers/video/exynos/exynos_mipi_dsi_common.c   | 2 --
>  drivers/video/exynos/exynos_mipi_dsi_lowlevel.c | 2 --
>  3 files changed, 6 deletions(-)
> 
> diff --git a/drivers/video/exynos/exynos_mipi_dsi.c 
> b/drivers/video/exynos/exynos_mipi_dsi.c
> index fac7df6..3dd43ca 100644
> --- a/drivers/video/exynos/exynos_mipi_dsi.c
> +++ b/drivers/video/exynos/exynos_mipi_dsi.c
> @@ -35,8 +35,6 @@
> 
>  #include 
> 
> -#include 
> -
>  #include "exynos_mipi_dsi_common.h"
>  #include "exynos_mipi_dsi_lowlevel.h"
> 
> diff --git a/drivers/video/exynos/exynos_mipi_dsi_common.c
> b/drivers/video/exynos/exynos_mipi_dsi_common.c
> index c70cb89..520fc9b 100644
> --- a/drivers/video/exynos/exynos_mipi_dsi_common.c
> +++ b/drivers/video/exynos/exynos_mipi_dsi_common.c
> @@ -31,8 +31,6 @@
>  #include 
>  #include 
> 
> -#include 
> -
>  #include "exynos_mipi_dsi_regs.h"
>  #include "exynos_mipi_dsi_lowlevel.h"
>  #include "exynos_mipi_dsi_common.h"
> diff --git a/drivers/video/exynos/exynos_mipi_dsi_lowlevel.c
> b/drivers/video/exynos/exynos_mipi_dsi_lowlevel.c
> index 95cb99a..15c5abd 100644
> --- a/drivers/video/exynos/exynos_mipi_dsi_lowlevel.c
> +++ b/drivers/video/exynos/exynos_mipi_dsi_lowlevel.c
> @@ -26,8 +26,6 @@
> 
>  #include 
> 
> -#include 
> -
>  #include "exynos_mipi_dsi_regs.h"
> 
>  void exynos_mipi_dsi_func_reset(struct mipi_dsim_device *dsim)
> --
> 1.8.1.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] module: add kset_obj_exists() and use it

[Veaceslav Falico]

On Thu, Apr 11, 2013 at 11:28:06AM +0930, Rusty Russell wrote:

Greg KH  writes:


On Tue, Apr 09, 2013 at 01:22:09PM +0200, Veaceslav Falico wrote:

Add a new function, kset_obj_exists(), which is identical to
kset_find_obj() but doesn't take a reference to the kobject
found and only returns bool if found/not found.

The main purpose would be to avoid the possible race scenario,
when we could get the reference in between the kref_put() and
kobject_release() functions (i.e. kref_put() already ran,
refcount became 0, but the kobject_release() function still
didn't run, and we try to get via kobject_get() and thus ending
up with a released kobject). It can be triggered, for example,
by running insmod/rmmod bonding in parallel, which ends up in
a race between kset_obj_find() in mod_sysfs_init() and rmmod's
mod_sysfs_fini()/kobject_put().


As Rusty points out, this isn't a kobject issue that can be solved with
a new api call, but rather, the user of the kobject code needs to be
fixed, with something like his proposed patch instead.

So, because of this, I can't take this patch, sorry.


Greg, I'm shocked!  Surely you've been doing this long enough to know
that we don't use that kind of language on lkml?

To restore the list's reputation as a hostile pressure cooker powered by
the smouldering remains of flame-roasted newcomers, allow me to correct
your reply:

   "NAK.  And you smell."


Got it :). Thank you for your input and your patch, I'll come back with a
proper fix when I'll have one.

Thanks all.



Crisis averted,
Rusty.
PS.  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: Kexec couldn't reboot capture kernel on pandaboard ES with OMAP4460

[Li Haifeng]

2013/4/10 Stephen Warren :
> On 04/10/2013 03:35 AM, Li Haifeng wrote:
>> Hi, everyone.
>>
>> Recently, I try to run kdump on pandaboard ES with omap4460. After
>> load capture kernel by "kexec -l" and execute "kexec -e", the serial
>> port output "Starting new kernel" and "Bye", then the system hangs up.
>>
>> I have tried the upstream Linux Kernel v3.4 and v3.8. All are with this 
>> issue.
>
> This is a shot in the dark. I assume you have SMP enabled. Can you use
> hotplug to remove all CPUs other than CPU0, so that the kexec happens on
> the boot CPU? That is certainly necessary for kexec to work correctly on
> Tegra.

Thanks for your attention.

I do disable SMP feature. And the .config file for v3.8 could be found here:
http://pastehtml.com/view/cylyrfejt.txt

The log and operation could be found here:
http://pastehtml.com/view/cylyfrb3a.txt

Some key setting list below.

bootargs:
rw vram=32M fixrtc mem=1G@0x8000 root=/dev/mmcblk0p2
console=ttyO2,115200n8 rootwait crashkernel=64M@0x8200

operation:
/ # ./kexec -l  --append="rw vram=32M fixrtc  root=/dev/mmcblk0p2 console=ttyO2,
115200n8 rootwait" uImage
/ # ./kexec -d -e

The output:
[   57.373687] Starting new kernel
[   57.377044] Bye!

Then system hangs.
--
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 13/30] video/s3c: move platform_data out of arch/arm

[Jingoo Han]

On Thursday, April 11, 2013 9:05 AM, Arnd Bergmann wrote:
> 
> The s3c-fb driver requires header files from the samsung platforms
> to find its platform_data definition, but this no longer works on
> multiplatform kernels, so let's move the data into a new header
> file under include/linux/platform_data.
> 
> Signed-off-by: Arnd Bergmann 
> Cc: linux-fb...@vger.kernel.org
> Cc: Jingoo Han 

CC'ed Tomi Valkeinen.


Hi Arnd,
It looks good. Thank you for your patch. :)

Acked-by: Jingoo Han 

Best regards,
Jingoo Han

> ---
>  arch/arm/plat-samsung/include/plat/fb.h | 50 +-
>  drivers/video/s3c-fb.c  |  3 +-
>  include/linux/platform_data/video_s3c.h | 54 
> +
>  3 files changed, 56 insertions(+), 51 deletions(-)
>  create mode 100644 include/linux/platform_data/video_s3c.h
> 
> diff --git a/arch/arm/plat-samsung/include/plat/fb.h 
> b/arch/arm/plat-samsung/include/plat/fb.h
> index b885322..9ae5072 100644
> --- a/arch/arm/plat-samsung/include/plat/fb.h
> +++ b/arch/arm/plat-samsung/include/plat/fb.h
> @@ -15,55 +15,7 @@
>  #ifndef __PLAT_S3C_FB_H
>  #define __PLAT_S3C_FB_H __FILE__
> 
> -/* S3C_FB_MAX_WIN
> - * Set to the maximum number of windows that any of the supported hardware
> - * can use. Since the platform data uses this for an array size, having it
> - * set to the maximum of any version of the hardware can do is safe.
> - */
> -#define S3C_FB_MAX_WIN   (5)
> -
> -/**
> - * struct s3c_fb_pd_win - per window setup data
> - * @xres : The window X size.
> - * @yres : The window Y size.
> - * @virtual_x: The virtual X size.
> - * @virtual_y: The virtual Y size.
> - */
> -struct s3c_fb_pd_win {
> - unsigned short  default_bpp;
> - unsigned short  max_bpp;
> - unsigned short  xres;
> - unsigned short  yres;
> - unsigned short  virtual_x;
> - unsigned short  virtual_y;
> -};
> -
> -/**
> - * struct s3c_fb_platdata -  S3C driver platform specific information
> - * @setup_gpio: Setup the external GPIO pins to the right state to transfer
> - *   the data from the display system to the connected display
> - *   device.
> - * @vidcon0: The base vidcon0 values to control the panel data format.
> - * @vidcon1: The base vidcon1 values to control the panel data output.
> - * @vtiming: Video timing when connected to a RGB type panel.
> - * @win: The setup data for each hardware window, or NULL for unused.
> - * @display_mode: The LCD output display mode.
> - *
> - * The platform data supplies the video driver with all the information
> - * it requires to work with the display(s) attached to the machine. It
> - * controls the initial mode, the number of display windows (0 is always
> - * the base framebuffer) that are initialised etc.
> - *
> - */
> -struct s3c_fb_platdata {
> - void(*setup_gpio)(void);
> -
> - struct s3c_fb_pd_win*win[S3C_FB_MAX_WIN];
> - struct fb_videomode *vtiming;
> -
> - u32  vidcon0;
> - u32  vidcon1;
> -};
> +#include 
> 
>  /**
>   * s3c_fb_set_platdata() - Setup the FB device with platform data.
> diff --git a/drivers/video/s3c-fb.c b/drivers/video/s3c-fb.c
> index 968a625..2e7991c 100644
> --- a/drivers/video/s3c-fb.c
> +++ b/drivers/video/s3c-fb.c
> @@ -24,10 +24,9 @@
>  #include 
>  #include 
>  #include 
> +#include 
> 
>  #include 
> -#include 
> -#include 
> 
>  /* This driver will export a number of framebuffer interfaces depending
>   * on the configuration passed in via the platform data. Each fb instance
> diff --git a/include/linux/platform_data/video_s3c.h 
> b/include/linux/platform_data/video_s3c.h
> new file mode 100644
> index 000..fa40f96
> --- /dev/null
> +++ b/include/linux/platform_data/video_s3c.h
> @@ -0,0 +1,54 @@
> +#ifndef __PLATFORM_DATA_VIDEO_S3C
> +#define __PLATFORM_DATA_VIDEO_S3C
> +
> +/* S3C_FB_MAX_WIN
> + * Set to the maximum number of windows that any of the supported hardware
> + * can use. Since the platform data uses this for an array size, having it
> + * set to the maximum of any version of the hardware can do is safe.
> + */
> +#define S3C_FB_MAX_WIN   (5)
> +
> +/**
> + * struct s3c_fb_pd_win - per window setup data
> + * @xres : The window X size.
> + * @yres : The window Y size.
> + * @virtual_x: The virtual X size.
> + * @virtual_y: The virtual Y size.
> + */
> +struct s3c_fb_pd_win {
> + unsigned short  default_bpp;
> + unsigned short  max_bpp;
> + unsigned short  xres;
> + unsigned short  yres;
> + unsigned short  virtual_x;
> + unsigned short  virtual_y;
> +};
> +
> +/**
> + * struct s3c_fb_platdata -  S3C driver platform specific information
> + * @setup_gpio: Setup the external GPIO pins to the right state to transfer
> + *   the data from the display system to the connected display
> + *   

Re: [PATCH] kernel: kallsyms: parameters checking, for EXPORT_SYMBOL_GPL functions

[Chen Gang]

On 2013年04月11日 10:52, Rusty Russell wrote:
>>> >> Or is someone already doing this?
>>> >> 
>> >
>> >   really has:
>> >
>> > kernel: __wake_up_sync_key in kernel/sched/core.c.
>> > lib: *printf.
>> > mm:  kfree.
> No, I mean "is someone calling these functions with NULL".
> 
> Cheers,
> Rusty.
> 
> 

  often "kfree(NULL)", that is ok. it will let caller easier using it.
  also often give 0 size to snprintf, it still let caller easy using.

  if we treat EXPORT functions of kallsyms as commonly used (or we want to)
I suggest to give parameter check for them.


  thanks.

  :-)

-- 
Chen Gang

Asianux Corporation
--
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] kernel: kallsyms: memory override issue, need check destination buffer length

[Chen Gang]

On 2013年04月11日 12:08, Rusty Russell wrote:
> Chen Gang  writes:
>>   We don't export any symbols > 128 characters, but if we did then
>>   kallsyms_expand_symbol() would overflow the buffer handed to it.
>>   So we need check destination buffer length when copying.
>>
>>   the related test:
>> if we define an EXPORT function which name more than 128.
>> will panic when call kallsyms_lookup_name by init_kprobes on booting.
>> after check the length (provide this patch), it is ok.
>>
>>   Implementaion:
>> add additional destination buffer length parameter (maxlen)
>> if uncompressed string is too long (>= maxlen), it will be truncated.
>> not check the parameters whether valid, since it is a static function.
>>
>>
>> Signed-off-by: Chen Gang 
>> Signed-off-by: Rusty Russell 
> 
> ??!!!  I never signed this off!  I've never seen it before!
> 

  ok, thanks. I did not quite understand the rule of it.

  originally, I think since you find it, I prefer to mention about you
in somewhere (e.g. mark as Reported-by ??)

  could you provide additional suggestions for it ?

  :-)


> Minor comments below:
> 

  I don't think they are 'minor comments'. I should improve them.

  thank you for your work.

  :-)


gchen.


>> -static unsigned int kallsyms_expand_symbol(unsigned int off, char *result)
>> +static unsigned int kallsyms_expand_symbol(unsigned int off,
>> +   char *result, int maxlen)
> 
> 'size_t maxlen' would be more explicit.
> 
>>  {
>>  int len, skipped_first = 0;
>>  const u8 *tptr, *data;
>> +char *begin = result;
>>  /* Get the compressed symbol length from the first symbol byte. */
>>  data = _names[off];
>> @@ -113,14 +116,16 @@ static unsigned int kallsyms_expand_symbol(unsigned 
>> int off, char *result)
>>  while (*tptr) {
>>  if (skipped_first) {
>> -*result = *tptr;
>> -result++;
>> +*result++ = *tptr;
>> +if (result - begin == maxlen - 1)
>> +goto tail;
> 
> You could just decrement maxlen instead, and handle maxlen == 0 at the
> same time:
> 
> if (maxlen <= 1)
> goto tail;
> *result = *tptr;
> result++;
> maxlen--;
> 
>> @@ -176,7 +181,7 @@ unsigned long kallsyms_lookup_name(const char *name)
>>  unsigned int off;
>>  for (i = 0, off = 0; i < kallsyms_num_syms; i++) {
>> -off = kallsyms_expand_symbol(off, namebuf);
>> +off = kallsyms_expand_symbol(off, namebuf, sizeof(namebuf));
>>  if (strcmp(namebuf, name) == 0)
>>  return kallsyms_addresses[i];
> 
> I prefer to use ARRAY_SIZE(namebuf) instead of sizeof(namebuf).  That
> way we break compile if the declaration is changed from an array to a
> pointer one day.
> 
> Same for the others.
> 
> Thanks,
> Rusty.
> 
> 


-- 
Chen Gang

Asianux Corporation
--
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] kernel: auditfilter: looping issue, memory leak if has 2 or more AUDIT_FILTERKEYs

[Chen Gang]

On 2013年04月11日 05:19, Eric Paris wrote:
> - Original Message -
> 
>> >   b. has an new issue for AUDIT_DIR:
>> >after AUDIT_DIR succeed, it will set rule->tree.
>> >next, the other case fail, then will call audit_free_rule.
>> >but audit_free_rule will not free rule->tree.
> Definitely a couple of leaks here...
> 
> I'm seeing leaks on size 8, 64, and 128.
> 
> Al, what do you think?  Should I be calling audit_put_tree() in the error 
> case if entry->tree != NULL?  The audit trees are some of the most complex 
> code in the kernel I think.
> 
> 

  can we add it in audit_free_rule ?

  maybe like this:

@@ -75,6 +75,8 @@ static inline void audit_free_rule(struct audit_entry *e)
/* some rules don't have associated watches */
if (erule->watch)
audit_put_watch(erule->watch);
+   if (erule->tree)
+   audit_put_tree(erule->tree);
if (erule->fields)
for (i = 0; i < erule->field_count; i++) {
struct audit_field *f = >fields[i];


  thanks.

  :-)

-- 
Chen Gang

Asianux Corporation
--
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] driver core: add uid and gid to devtmpfs

[Eric W. Biederman]

Greg KH  writes:

> From: Kay Sievers 
>
> Some drivers want to tell userspace what uid and gid should be used for
> their device nodes, so allow that information to percolate through the
> driver core to userspace in order to make this happen.  This means that
> some systems (i.e.  Android and friends) will not need to even run a
> udev-like daemon for their device node manager and can just rely in
> devtmpfs fully, reducing their footprint even more.

This patch is really badly broken in it's uid and gid handling.
Nearly every line of this patch is wrong.

uids and gids in the kernel need to be stored in kuid_t's and kgid_t's.

> Signed-off-by: Kay Sievers 
> Signed-off-by: Greg Kroah-Hartman 
> ---
>  block/genhd.c   |3 ++-
>  drivers/base/core.c |   17 +
>  drivers/base/devtmpfs.c |   27 +--
>  drivers/usb/core/usb.c  |3 ++-
>  include/linux/device.h  |7 +--
>  5 files changed, 39 insertions(+), 18 deletions(-)
>
> --- a/block/genhd.c
> +++ b/block/genhd.c
> @@ -,7 +,8 @@ struct class block_class = {
>   .name   = "block",
>  };
>  
> -static char *block_devnode(struct device *dev, umode_t *mode)
> +static char *block_devnode(struct device *dev, umode_t *mode,
> +uid_t *uid, gid_t *gid)
This needs be kuid_t and kgid_t.

>  {
>   struct gendisk *disk = dev_to_disk(dev);
>  
> --- a/drivers/base/core.c
> +++ b/drivers/base/core.c
> @@ -283,15 +283,21 @@ static int dev_uevent(struct kset *kset,
>   const char *tmp;
>   const char *name;
>   umode_t mode = 0;
> + uid_t uid = 0;
> + gid_t gid = 0;
This needs to be:
kuid_t uid = GLOBAL_ROOT_UID;
kgid_t gid = GLOBAL_ROOT_GID;

>   add_uevent_var(env, "MAJOR=%u", MAJOR(dev->devt));
>   add_uevent_var(env, "MINOR=%u", MINOR(dev->devt));
> - name = device_get_devnode(dev, , );
> + name = device_get_devnode(dev, , , , );
>   if (name) {
>   add_uevent_var(env, "DEVNAME=%s", name);
> - kfree(tmp);
>   if (mode)
>   add_uevent_var(env, "DEVMODE=%#o", mode & 0777);
> + if (uid)
> + add_uevent_var(env, "DEVUID=%u", uid);
> + if (gid)
> + add_uevent_var(env, "DEVGID=%u", gid);

Which user namespace are your users in?
At the very least this should be:
+   if (!uid_eq(uid, GLOBAL_ROOT_UID)
+   add_uevent_var(env, "DEVUID=%u", 
from_kuid(_user_ns, uid));
+   if (!gid_eq(gid, GLOBAL_ROOT_GID))
+   add_uevent_var(env, "DEVGID=%u", 
from_kgid(_user_ns, gid));

I suppose you can assume your users are in the initial user namespace,
as mknod won't work in any other user namespace.

Still it approaches being twisted to have files like
/sys/class/net/eth0/uevent that anyone can read that will only return
values in the initial user namespace.

> + kfree(tmp);
>   }
>   }
>  
> @@ -1274,6 +1280,8 @@ static struct device *next_device(struct
>   * device_get_devnode - path of device node file
>   * @dev: device
>   * @mode: returned file access mode
> + * @uid: returned file owner
> + * @gid: returned file group
>   * @tmp: possibly allocated string
>   *
>   * Return the relative path of a possible device node.
> @@ -1282,7 +1290,8 @@ static struct device *next_device(struct
>   * freed by the caller.
>   */
>  const char *device_get_devnode(struct device *dev,
> -umode_t *mode, const char **tmp)
> +umode_t *mode, uid_t *uid, gid_t *gid,
> +const char **tmp)

This needs to be kuid_t and kgid_t
>  {
>   char *s;
>  
> @@ -1290,7 +1299,7 @@ const char *device_get_devnode(struct de
>  
>   /* the device type may provide a specific name */
>   if (dev->type && dev->type->devnode)
> - *tmp = dev->type->devnode(dev, mode);
> + *tmp = dev->type->devnode(dev, mode, uid, gid);
>   if (*tmp)
>   return *tmp;
>  
> --- a/drivers/base/devtmpfs.c
> +++ b/drivers/base/devtmpfs.c
> @@ -41,6 +41,8 @@ static struct req {
>   int err;
>   const char *name;
>   umode_t mode;   /* 0 => delete */
> + uid_t uid;
> + gid_t gid;

This needs to be kuid_t and kgid_t.
>   struct device *dev;
>  } *requests;
>  
> @@ -85,7 +87,9 @@ int devtmpfs_create_node(struct device *
>   return 0;
>  
>   req.mode = 0;
> - req.name = device_get_devnode(dev, , );
> + req.uid = 0;
> + req.gid = 0;
This needs to be.
req.uid = GLOBAL_ROOT_UID;
req.gid = GLOBAL_ROOT_GID;
> + req.name = device_get_devnode(dev, , , , );
>   if (!req.name)
>   return 

Re: [PATCH] rtc: rtc-s3c: use clk_prepare_enable and clk_disable_unprepare

[Jingoo Han]

On Wednesday, April 10, 2013 6:50 PM, Sylwester Nawrocki wrote:
> On 04/09/2013 04:27 PM, Vivek Gautam wrote:
> > From: Thomas Abraham 
> >
> > Convert clk_enable/clk_disable to clk_prepare_enable/clk_disable_unprepare
> > calls as required by common clock framework.
> >
> > Signed-off-by: Thomas Abraham 
> > Signed-off-by: Vivek Gautam 
> 
> Thanks Vivek.
> 
> Reviewed-by: Sylwester Nawrocki 

CC'ed Andrew Morton

It looks good.
Reviewed-by: Jingoo Han 

> 
> > ---
> >
> > The v1 of this patch is pretty old, but the change needs to be merged to
> > avoid getting those needless WARN_ON() dumps on console.
> >
> > Changes from v1:
> >  - Not using clk_disable_unprepare() at the end of s3c_rtc_probe(), since
> >this will unprepare the rtc clock which is again getting used in other
> >funtions later.
> >  - Using clk_unprepare() at the remove() instead to fix things up.
> >
> >  drivers/rtc/rtc-s3c.c |5 +++--
> >  1 files changed, 3 insertions(+), 2 deletions(-)
> >
> > diff --git a/drivers/rtc/rtc-s3c.c b/drivers/rtc/rtc-s3c.c
> > index fb994e9..e3528c9 100644
> > --- a/drivers/rtc/rtc-s3c.c
> > +++ b/drivers/rtc/rtc-s3c.c
> > @@ -430,6 +430,7 @@ static int s3c_rtc_remove(struct platform_device *dev)
> >
> > s3c_rtc_setaie(>dev, 0);
> >
> > +   clk_unprepare(rtc_clk);
> > rtc_clk = NULL;
> >
> > return 0;
> > @@ -498,7 +499,7 @@ static int s3c_rtc_probe(struct platform_device *pdev)
> > return ret;
> > }
> >
> > -   clk_enable(rtc_clk);
> > +   clk_prepare_enable(rtc_clk);
> >
> > /* check to see if everything is setup correctly */
> >
> > @@ -578,7 +579,7 @@ static int s3c_rtc_probe(struct platform_device *pdev)
> >
> >   err_nortc:
> > s3c_rtc_enable(pdev, 0);
> > -   clk_disable(rtc_clk);
> > +   clk_disable_unprepare(rtc_clk);
> >
> > return ret;
> >  }
> 
> --
> To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" 
> in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

--
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] kernel: kallsyms: memory override issue, need check destination buffer length

[Rusty Russell]

Chen Gang  writes:
>   We don't export any symbols > 128 characters, but if we did then
>   kallsyms_expand_symbol() would overflow the buffer handed to it.
>   So we need check destination buffer length when copying.
>
>   the related test:
> if we define an EXPORT function which name more than 128.
> will panic when call kallsyms_lookup_name by init_kprobes on booting.
> after check the length (provide this patch), it is ok.
>
>   Implementaion:
> add additional destination buffer length parameter (maxlen)
> if uncompressed string is too long (>= maxlen), it will be truncated.
> not check the parameters whether valid, since it is a static function.
>
>
> Signed-off-by: Chen Gang 
> Signed-off-by: Rusty Russell 

??!!!  I never signed this off!  I've never seen it before!

Minor comments below:

> -static unsigned int kallsyms_expand_symbol(unsigned int off, char *result)
> +static unsigned int kallsyms_expand_symbol(unsigned int off,
> +char *result, int maxlen)

'size_t maxlen' would be more explicit.

>  {
>   int len, skipped_first = 0;
>   const u8 *tptr, *data;
> + char *begin = result;
>   /* Get the compressed symbol length from the first symbol byte. */
>   data = _names[off];
> @@ -113,14 +116,16 @@ static unsigned int kallsyms_expand_symbol(unsigned int 
> off, char *result)
>   while (*tptr) {
>   if (skipped_first) {
> - *result = *tptr;
> - result++;
> + *result++ = *tptr;
> + if (result - begin == maxlen - 1)
> + goto tail;

You could just decrement maxlen instead, and handle maxlen == 0 at the
same time:

if (maxlen <= 1)
goto tail;
*result = *tptr;
result++;
maxlen--;

> @@ -176,7 +181,7 @@ unsigned long kallsyms_lookup_name(const char *name)
>   unsigned int off;
>   for (i = 0, off = 0; i < kallsyms_num_syms; i++) {
> - off = kallsyms_expand_symbol(off, namebuf);
> + off = kallsyms_expand_symbol(off, namebuf, sizeof(namebuf));
>   if (strcmp(namebuf, name) == 0)
>   return kallsyms_addresses[i];

I prefer to use ARRAY_SIZE(namebuf) instead of sizeof(namebuf).  That
way we break compile if the declaration is changed from an array to a
pointer one day.

Same for the others.

Thanks,
Rusty.
--
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 tip tree with the pm tree

[Stephen Rothwell]

Hi all,

Today's linux-next merge of the tip tree got a conflict in
include/linux/clockchips.h between commit 4dbad816febb ("timer: move enum
definition out of ifdef section") from the pm tree and commit
19919226c3f2 ("clockevents: Add missing tick_check_broadcast_expired()
for CLOCKEVENTS=n") from the tip 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/clockchips.h
index f9fd937,464e229..000
--- a/include/linux/clockchips.h
+++ b/include/linux/clockchips.h
@@@ -181,7 -192,8 +192,8 @@@ static inline void clockevents_notify(u
  static inline void clockevents_suspend(void) {}
  static inline void clockevents_resume(void) {}
  
 -#define clockevents_notify(reason, arg) do { } while (0)
 +static inline void clockevents_notify(unsigned long reason, void *arg) {}
+ static inline int tick_check_broadcast_expired(void) { return 0; }
  
  #endif
  


pgpVHVUIxGt1Q.pgp
Description: PGP signature

[PATCH 2/2] regulator: ab8500: Unregister ab8500-ext regulators in probe() failure path

[Axel Lin]

Signed-off-by: Axel Lin 
---
 drivers/regulator/ab8500.c |5 -
 1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/drivers/regulator/ab8500.c b/drivers/regulator/ab8500.c
index c200f8b..ea182d3 100644
--- a/drivers/regulator/ab8500.c
+++ b/drivers/regulator/ab8500.c
@@ -3172,8 +3172,11 @@ static int ab8500_regulator_probe(struct platform_device 
*pdev)
for (i = 0; i < abx500_regulator.info_size; i++) {
err = ab8500_regulator_register(pdev, >regulator[i],
i, NULL);
-   if (err < 0)
+   if (err < 0) {
+   if (!is_ab8505(ab8500))
+   ab8500_ext_regulator_exit(pdev);
return err;
+   }
}
 
return 0;
-- 
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/2] regulator: ab8500-ext: Make the return type of ab8500_ext_regulator_exit() void

[Axel Lin]

ab8500_ext_regulator_exit() never fails.

Signed-off-by: Axel Lin 
---
 drivers/regulator/ab8500-ext.c   |4 +---
 drivers/regulator/ab8500.c   |9 +++--
 include/linux/regulator/ab8500.h |2 +-
 3 files changed, 5 insertions(+), 10 deletions(-)

diff --git a/drivers/regulator/ab8500-ext.c b/drivers/regulator/ab8500-ext.c
index dd582be..861ab04 100644
--- a/drivers/regulator/ab8500-ext.c
+++ b/drivers/regulator/ab8500-ext.c
@@ -385,7 +385,7 @@ int ab8500_ext_regulator_init(struct platform_device *pdev)
return 0;
 }
 
-int ab8500_ext_regulator_exit(struct platform_device *pdev)
+void ab8500_ext_regulator_exit(struct platform_device *pdev)
 {
int i;
 
@@ -398,8 +398,6 @@ int ab8500_ext_regulator_exit(struct platform_device *pdev)
 
regulator_unregister(info->rdev);
}
-
-   return 0;
 }
 
 MODULE_LICENSE("GPL v2");
diff --git a/drivers/regulator/ab8500.c b/drivers/regulator/ab8500.c
index 9ebd131..c200f8b 100644
--- a/drivers/regulator/ab8500.c
+++ b/drivers/regulator/ab8500.c
@@ -3194,12 +3194,9 @@ static int ab8500_regulator_remove(struct 
platform_device *pdev)
regulator_unregister(info->regulator);
}
 
-   if (!is_ab8505(ab8500)) {
-   /* remove external regulators (after Vaux1, 2 and 3) */
-   err = ab8500_ext_regulator_exit(pdev);
-   if (err)
-   return err;
-   }
+   /* remove external regulators (after Vaux1, 2 and 3) */
+   if (!is_ab8505(ab8500))
+   ab8500_ext_regulator_exit(pdev);
 
/* remove regulator debug */
err = ab8500_regulator_debug_exit(pdev);
diff --git a/include/linux/regulator/ab8500.h b/include/linux/regulator/ab8500.h
index 90b8b5a..7c5ff0c 100644
--- a/include/linux/regulator/ab8500.h
+++ b/include/linux/regulator/ab8500.h
@@ -338,6 +338,6 @@ static inline int ab8500_regulator_debug_exit(struct 
platform_device *pdev)
 
 /* AB8500 external regulator functions. */
 int ab8500_ext_regulator_init(struct platform_device *pdev);
-int ab8500_ext_regulator_exit(struct platform_device *pdev);
+void ab8500_ext_regulator_exit(struct platform_device *pdev);
 
 #endif
-- 
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/

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

[Stephen Rothwell]

Hi all,

Today's linux-next merge of the tip tree got a conflict in tools/Makefile
between commit e306e2c13b8c ("filter: add minimal BPF JIT image
disassembler") from the net-next tree and commit 85c66be101e1 ("perf
tools: Introduce tools/lib/lk library") from the tip 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 tools/Makefile
index c73c635,6aaeb6c..000
--- a/tools/Makefile
+++ b/tools/Makefile
@@@ -35,7 -34,13 +35,13 @@@ help
  cpupower: FORCE
$(call descend,power/$@)
  
- cgroup firewire lguest perf usb virtio vm net: FORCE
 -cgroup firewire guest usb virtio vm: FORCE
++cgroup firewire guest usb virtio vm net: FORCE
+   $(call descend,$@)
+ 
+ liblk: FORCE
+   $(call descend,lib/lk)
+ 
+ perf: liblk FORCE
$(call descend,$@)
  
  selftests: FORCE
@@@ -63,7 -68,13 +69,13 @@@ install: cgroup_install cpupower_instal
  cpupower_clean:
$(call descend,power/cpupower,clean)
  
- cgroup_clean firewire_clean lguest_clean perf_clean usb_clean virtio_clean 
vm_clean net_clean:
 -cgroup_clean firewire_clean lguest_clean usb_clean virtio_clean vm_clean:
++cgroup_clean firewire_clean lguest_clean usb_clean virtio_clean vm_clean 
net_clean:
+   $(call descend,$(@:_clean=),clean)
+ 
+ liblk_clean:
+   $(call descend,lib/lk,clean)
+ 
+ perf_clean: liblk_clean
$(call descend,$(@:_clean=),clean)
  
  selftests_clean:


pgpL1A3eSerb8.pgp
Description: PGP signature

Re: [PATCH v2] MODSIGN: do not send garbage to stderr when enabling modules signature

[Rusty Russell]

David Cohen  writes:
> On 04/10/2013 03:32 AM, Rusty Russell wrote:
>> David Cohen  writes:
>>> openssl may send garbage to stderr when generating X.509 key pair for
>>> modules signature regardless there was an error or not. It makes more
>>> difficult to create scripts based on kernel error/warning messages.
>>>
>>> When compiling kernel with -jN (N > 1), all warning/error messages
>>> printed while openssl is generating key pair may get mixed dots and
>>> other symbols openssl sends to stderr. This patch makes sure openssl
>>> logs go to default stdout.
>> Ah!  Not garbage, but it writes progress dots and status messages to
>> stderr?
>>
>> I trimmed your commit message as shown below.
>
> Thanks! The new commit message looks fine.
> But it's not the dots. It prints the whole logs to stderr, but the dots 
> are more likely to get mixed.
>
> Br, David

Seems like Linus didn't bite, so I've put it in my modules-next tree.

Thanks,
Rusty.
--
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] kernel: kallsyms: parameters checking, for EXPORT_SYMBOL_GPL functions

[Rusty Russell]

Chen Gang  writes:
> On 2013年04月10日 14:57, Rusty Russell wrote:
>> Chen Gang  writes:
>>> >   for EXPORT_SYMBOL_GPL functions, necessary to check their parameters.
>>> >
>>> > Signed-off-by: Chen Gang 
>> Why?
>> 
>> If someone misuses these functions, they crash and thus indicate that
>> the caller shouldn't do that.
>> 
>
>   for me, I think:
>
> if it is used by self (such as static functions):
>   I prefer to crash immediatly.
>   it will help us to find issue, quickly.
>
> if it can be used by others (such as EXPORT_SYMBOL_GPL):
>   I prefer to return fail and tell caller that parameter is invalid.
>   it is more polite to callers, and still indicate it may be an issue.
>
>   :-)

I disagree.  Calling with invalid parameters is a bug.  You've just
covered up some cases of invalid use and made it less likely to be
found.  Because the caller won't notice they screwed up.

We could sprinkle WARN_ON() everywhere, but I prefer the crash.  Even
harder to ignore.

There's no limit to how many of these checks we could put in, and we can
*never* take them out.  I don't want to code that way.

>> Or is someone already doing this?
>> 
>
>   really has:
>
> kernel: __wake_up_sync_key in kernel/sched/core.c.
> lib: *printf.
> mm:  kfree.

No, I mean "is someone calling these functions with NULL".

Cheers,
Rusty.
--
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] kernel: auditfilter: looping issue, memory leak if has 2 or more AUDIT_FILTERKEYs

[Chen Gang]

On 2013年04月11日 04:08, Eric Paris wrote:
> We only allow one filter key per rule.  So we should never be able to get 
> into this situation.  See audit_data_to_entry()

  really it is, thanks.

  :-)

-- 
Chen Gang

Asianux Corporation
--
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] kernel: auditfilter: looping issue, memory leak if has 2 or more AUDIT_FILTERKEYs

[Chen Gang]

On 2013年04月11日 04:29, Eric Paris wrote:
> - Original Message -
>> > 
>> > 
>> > in another function: audit_data_to_entry:
>> > 
>> >   a. has the same issue for case AUDIT_WATCH.
> You are saying if there were 2 of them it will leak the old one?  No.  If you 
> have 2 AUDIT_WATCH entries the first one will set entry->rule->watch and the 
> second will bomb with EINVAL in audit_to_watch()
> 
> 

  thanks, really it is. it is my fault.

  :-)


-- 
Chen Gang

Asianux Corporation
--
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 Patch 0/2] mm: Add parameters to make kernel behavior at memory error on dirty cache selectable

[Simon Jeons]

Hi Mitsuhiro,
On 04/11/2013 11:26 AM, Mitsuhiro Tanino wrote:

Hi All,
Please find a patch set that introduces these new sysctl interfaces,
to handle a case when an memory error is detected on dirty page cache.

- vm.memory_failure_dirty_panic
- vm.memory_failure_print_ratelimit
- vm.memory_failure_print_ratelimit_burst

Problem
-
Recently, it is common that enterprise servers likely have a large
amount of memory, especially for cloud environment. This means that
possibility of memory failures is increased.

To handle memory failure, Linux has a hwpoison feature. When a memory
error is detected by memory scrub, the error is reported as machine
check, uncorrected recoverable (UCR), to OS. Then OS isolates the memory
region with memory failure if the memory page can be isolated.
The hwpoison handles it according to the memory region, such as kernel,
dirty cache, clean cache. If the memory region can be isolated, the
page is marked "hwpoison" and it is not used again.

When SRAO machine check is reported on a page which is included dirty
page cache, the page is truncated because the memory is corrupted and
data of the page cannot be written to a disk any more.

As a result, if the dirty cache includes user data, the data is lost,
and data corruption occurs if an application uses old data.


One question against mce instead of the patchset. ;-)

When check memory is bad? Before memory access? Is there a process scan 
it period?





Solution
-
The patch proposes a new sysctl interface, vm.memory_failure_dirty_panic,
in order to prevent data corruption comes from data lost problem.
Also this patch displays information of affected file such as device name,
inode number, file offset and file type if the file is mapped on a memory
and the page is dirty cache.

When SRAO machine check occurs on a dirty page cache, corresponding
data cannot be recovered any more. Therefore, the patch proposes a kernel
option to keep a system running or force system panic in order
to avoid further trouble such as data corruption problem of application.

System administrator can select an error action using this option
according to characteristics of target system.



Use Case
-
This option is intended to be adopted in KVM guest because it is
supposed that Linux on KVM guest operates customers business and
it is big impact to lost or corrupt customers data by memory failure.

On the other hand, this option does not recommend to apply KVM host
as following reasons.

- Making KVM host panic has a big impact because all virtual guests are
   affected by their host panic. Affected virtual guests are forced to stop
   and have to be restarted on the other hypervisor.

- If disk cached model of qemu is set to "none", I/O type of virtual
   guests becomes O_DIRECT and KVM host does not cache guest's disk I/O.
   Therefore, if SRAO machine check is reported on a dirty page cache
   in KVM host, its virtual machines are not affected by the machine check.
   So the host is expected to keep operating instead of kernel panic.


Past discussion

This problem was previously discussed in the kernel community,
(refer: mail threads pertaining to
http://marc.info/?l=linux-kernel=135187403804934=4).


- I worry that if a hardware error occurs, it might affect a large
   amount of memory all at the same time.  For example, if a 4G memory
   block goes bad, this message will be printed a million times?


As Andrew mentioned in the above threads, if 4GB memory blocks goes bad,
error messages will be printed a million times and this behavior loses
a system reliability.

Therefore, the second patch introduces two sysctl parameters for
__ratelimit() which is used at mce_notify_irq() in order to notify
occurrence of machine check event to system administrator.
The use of __ratelimit(), this patch can limit quantity of messages
per interval to be output at syslog or terminal console.

If system administrator needs to limit quantity of messages,
these parameters are available.

- vm.memory_failure_print_ratelimit:
   Specifies the minimum length of time between messages.
   By default the rate limiting is disabled.

- vm.memory_failure_print_ratelimit_burst:
   Specifies the number of messages we can send before rate limiting.



Test Results
-
These patches are tested on 3.8.1 kernel(FC18) using software pseudo MCE
injection from KVM host to guest.


 Host OS Screen logs(SRAO Machine Check injection) 
Inject software pseudo MCE into guest qemu process.

(1) Load mce-inject module
# modprobe mce-inject

(2) Find a PID of target qemu-kvm and page struct
# ps -C qemu-kvm -o pid=
  8176

(3) Edit software pseudo MCE data
Choose a offset of page struct and insert the offset to ADDR line in mce-file.

#  ./page-types -p 8176 -LN | grep "___UDlAMa_b___"
voffset offset  flags
...
7fd25eb77   344d77  ___UDlAMa_b___
7fd25eb78   344d78  

[PATCHv2] powerpc/crypto: Add property for 'era' in SEC dts crypto node

[Vakul Garg]

The crypto node now contains a new property 'fsl,sec-era'.
This is required so that applications can retrieve era info without
having to be able to read SEC's register space.

Signed-off-by: Vakul Garg 
---
Changelog:

v2: Added era in p1023si-post.dtsi as per Kim's comments.

 arch/powerpc/boot/dts/fsl/p1023si-post.dtsi   |1 +
 arch/powerpc/boot/dts/fsl/pq3-sec4.4-0.dtsi   |1 +
 arch/powerpc/boot/dts/fsl/qoriq-sec4.0-0.dtsi |1 +
 arch/powerpc/boot/dts/fsl/qoriq-sec4.2-0.dtsi |1 +
 arch/powerpc/boot/dts/fsl/qoriq-sec5.0-0.dtsi |1 +
 arch/powerpc/boot/dts/fsl/qoriq-sec5.2-0.dtsi |1 +
 arch/powerpc/boot/dts/fsl/qoriq-sec5.3-0.dtsi |1 +
 7 files changed, 7 insertions(+), 0 deletions(-)

diff --git a/arch/powerpc/boot/dts/fsl/p1023si-post.dtsi 
b/arch/powerpc/boot/dts/fsl/p1023si-post.dtsi
index 941fa15..f1105bf 100644
--- a/arch/powerpc/boot/dts/fsl/p1023si-post.dtsi
+++ b/arch/powerpc/boot/dts/fsl/p1023si-post.dtsi
@@ -148,6 +148,7 @@
 
crypto: crypto@30 {
compatible = "fsl,sec-v4.2", "fsl,sec-v4.0";
+   fsl,sec-era = <3>;
#address-cells = <1>;
#size-cells = <1>;
reg = <0x3 0x1>;
diff --git a/arch/powerpc/boot/dts/fsl/pq3-sec4.4-0.dtsi 
b/arch/powerpc/boot/dts/fsl/pq3-sec4.4-0.dtsi
index ffadcb5..bb3d826 100644
--- a/arch/powerpc/boot/dts/fsl/pq3-sec4.4-0.dtsi
+++ b/arch/powerpc/boot/dts/fsl/pq3-sec4.4-0.dtsi
@@ -34,6 +34,7 @@
 
 crypto@3 {
compatible = "fsl,sec-v4.4", "fsl,sec-v4.0";
+   fsl,sec-era = <3>;
#address-cells = <1>;
#size-cells = <1>;
ranges   = <0x0 0x3 0x1>;
diff --git a/arch/powerpc/boot/dts/fsl/qoriq-sec4.0-0.dtsi 
b/arch/powerpc/boot/dts/fsl/qoriq-sec4.0-0.dtsi
index 0cbbac3..02bee5f 100644
--- a/arch/powerpc/boot/dts/fsl/qoriq-sec4.0-0.dtsi
+++ b/arch/powerpc/boot/dts/fsl/qoriq-sec4.0-0.dtsi
@@ -34,6 +34,7 @@
 
 crypto: crypto@30 {
compatible = "fsl,sec-v4.0";
+   fsl,sec-era = <1>;
#address-cells = <1>;
#size-cells = <1>;
reg = <0x30 0x1>;
diff --git a/arch/powerpc/boot/dts/fsl/qoriq-sec4.2-0.dtsi 
b/arch/powerpc/boot/dts/fsl/qoriq-sec4.2-0.dtsi
index 7990e0d..7f7574e 100644
--- a/arch/powerpc/boot/dts/fsl/qoriq-sec4.2-0.dtsi
+++ b/arch/powerpc/boot/dts/fsl/qoriq-sec4.2-0.dtsi
@@ -34,6 +34,7 @@
 
 crypto: crypto@30 {
compatible = "fsl,sec-v4.2", "fsl,sec-v4.0";
+   fsl,sec-era = <3>;
#address-cells = <1>;
#size-cells = <1>;
reg  = <0x30 0x1>;
diff --git a/arch/powerpc/boot/dts/fsl/qoriq-sec5.0-0.dtsi 
b/arch/powerpc/boot/dts/fsl/qoriq-sec5.0-0.dtsi
index ffd458f..e298efb 100644
--- a/arch/powerpc/boot/dts/fsl/qoriq-sec5.0-0.dtsi
+++ b/arch/powerpc/boot/dts/fsl/qoriq-sec5.0-0.dtsi
@@ -34,6 +34,7 @@
 
 crypto: crypto@30 {
compatible = "fsl,sec-v5.0", "fsl,sec-v4.0";
+   fsl,sec-era = <5>;
#address-cells = <1>;
#size-cells = <1>;
reg  = <0x30 0x1>;
diff --git a/arch/powerpc/boot/dts/fsl/qoriq-sec5.2-0.dtsi 
b/arch/powerpc/boot/dts/fsl/qoriq-sec5.2-0.dtsi
index 7b2ab8a..33ff09d 100644
--- a/arch/powerpc/boot/dts/fsl/qoriq-sec5.2-0.dtsi
+++ b/arch/powerpc/boot/dts/fsl/qoriq-sec5.2-0.dtsi
@@ -34,6 +34,7 @@
 
 crypto: crypto@30 {
compatible = "fsl,sec-v5.2", "fsl,sec-v5.0", "fsl,sec-v4.0";
+   fsl,sec-era = <5>;
#address-cells = <1>;
#size-cells = <1>;
reg  = <0x30 0x1>;
diff --git a/arch/powerpc/boot/dts/fsl/qoriq-sec5.3-0.dtsi 
b/arch/powerpc/boot/dts/fsl/qoriq-sec5.3-0.dtsi
index 0339825..0877822 100644
--- a/arch/powerpc/boot/dts/fsl/qoriq-sec5.3-0.dtsi
+++ b/arch/powerpc/boot/dts/fsl/qoriq-sec5.3-0.dtsi
@@ -34,6 +34,7 @@
 
 crypto: crypto@30 {
compatible = "fsl,sec-v5.3", "fsl,sec-v5.0", "fsl,sec-v4.0";
+   fsl,sec-era = <4>;
#address-cells = <1>;
#size-cells = <1>;
reg  = <0x30 0x1>;
-- 
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/

[PATCH] powerpc/crypto: removed qoriq-sec4.1-0.dtsi.

[Vakul Garg]

Removing qoriq-sec4.1-0.dtsi as it is not used by any soc anymore.

Signed-off-by: Vakul Garg 
---
 arch/powerpc/boot/dts/fsl/qoriq-sec4.1-0.dtsi |  109 -
 1 files changed, 0 insertions(+), 109 deletions(-)
 delete mode 100644 arch/powerpc/boot/dts/fsl/qoriq-sec4.1-0.dtsi

diff --git a/arch/powerpc/boot/dts/fsl/qoriq-sec4.1-0.dtsi 
b/arch/powerpc/boot/dts/fsl/qoriq-sec4.1-0.dtsi
deleted file mode 100644
index 3308986..000
--- a/arch/powerpc/boot/dts/fsl/qoriq-sec4.1-0.dtsi
+++ /dev/null
@@ -1,109 +0,0 @@
-/*
- * QorIQ Sec/Crypto 4.1 device tree stub [ controller @ offset 0x30 ]
- *
- * Copyright 2011 Freescale Semiconductor Inc.
- *
- * Redistribution and use in source and binary forms, with or without
- * modification, are permitted provided that the following conditions are met:
- * * Redistributions of source code must retain the above copyright
- *   notice, this list of conditions and the following disclaimer.
- * * Redistributions in binary form must reproduce the above copyright
- *   notice, this list of conditions and the following disclaimer in the
- *   documentation and/or other materials provided with the distribution.
- * * Neither the name of Freescale Semiconductor nor the
- *   names of its contributors may be used to endorse or promote products
- *   derived from this software without specific prior written permission.
- *
- *
- * ALTERNATIVELY, this software may be distributed under the terms of the
- * GNU General Public License ("GPL") as published by the Free Software
- * Foundation, either version 2 of that License or (at your option) any
- * later version.
- *
- * THIS SOFTWARE IS PROVIDED BY Freescale Semiconductor ``AS IS'' AND ANY
- * EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED
- * WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE
- * DISCLAIMED. IN NO EVENT SHALL Freescale Semiconductor BE LIABLE FOR ANY
- * DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES
- * (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES;
- * LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND
- * ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT
- * (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF 
THIS
- * SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
- */
-
-crypto: crypto@30 {
-   compatible = "fsl,sec-v4.1", "fsl,sec-v4.0";
-   #address-cells = <1>;
-   #size-cells = <1>;
-   reg  = <0x30 0x1>;
-   ranges   = <0 0x30 0x1>;
-   interrupts   = <92 2 0 0>;
-
-   sec_jr0: jr@1000 {
-   compatible = "fsl,sec-v4.1-job-ring",
-"fsl,sec-v4.0-job-ring";
-   reg = <0x1000 0x1000>;
-   interrupts = <88 2 0 0>;
-   };
-
-   sec_jr1: jr@2000 {
-   compatible = "fsl,sec-v4.1-job-ring",
-"fsl,sec-v4.0-job-ring";
-   reg = <0x2000 0x1000>;
-   interrupts = <89 2 0 0>;
-   };
-
-   sec_jr2: jr@3000 {
-   compatible = "fsl,sec-v4.1-job-ring",
-"fsl,sec-v4.0-job-ring";
-   reg = <0x3000 0x1000>;
-   interrupts = <90 2 0 0>;
-   };
-
-   sec_jr3: jr@4000 {
-   compatible = "fsl,sec-v4.1-job-ring",
-"fsl,sec-v4.0-job-ring";
-   reg = <0x4000 0x1000>;
-   interrupts = <91 2 0 0>;
-   };
-
-   rtic@6000 {
-   compatible = "fsl,sec-v4.1-rtic",
-"fsl,sec-v4.0-rtic";
-   #address-cells = <1>;
-   #size-cells = <1>;
-   reg = <0x6000 0x100>;
-   ranges = <0x0 0x6100 0xe00>;
-
-   rtic_a: rtic-a@0 {
-   compatible = "fsl,sec-v4.1-rtic-memory",
-"fsl,sec-v4.0-rtic-memory";
-   reg = <0x00 0x20 0x100 0x80>;
-   };
-
-   rtic_b: rtic-b@20 {
-   compatible = "fsl,sec-v4.1-rtic-memory",
-"fsl,sec-v4.0-rtic-memory";
-   reg = <0x20 0x20 0x200 0x80>;
-   };
-
-   rtic_c: rtic-c@40 {
-   compatible = "fsl,sec-v4.1-rtic-memory",
-"fsl,sec-v4.0-rtic-memory";
-   reg = <0x40 0x20 0x300 0x80>;
-   };
-
-   rtic_d: rtic-d@60 {
-   compatible = "fsl,sec-v4.1-rtic-memory",
-"fsl,sec-v4.0-rtic-memory";
-   reg = <0x60 0x20 0x500 0x80>;
-   };
-   };
-};
-
-sec_mon: sec_mon@314000 {
-   compatible = "fsl,sec-v4.1-mon", "fsl,sec-v4.0-mon";
-   reg = 

Re: [PATCH] checkpatch: Warn on comparisons to true and false

[Joe Perches]

On Wed, 2013-04-10 at 22:14 -0400, Dave Jones wrote:
> It would be interesting to see how many people have historically screwed 
> up and used (!a) when they mean (a) and vice versa, versus spelling
> it out longform.  I'd be surprised if the results weren't skewed
> in favour of the more verbose form.

I think it'd be interesting too though I'd
take the other side.

--
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] mm, slub: count freed pages via rcu as this task's reclaimed_slab

[Simon Jeons]

Hi Christoph,
On 04/10/2013 09:54 PM, Christoph Lameter wrote:

On Wed, 10 Apr 2013, Simon Jeons wrote:


It seems that you misunderstand my question. I don't doubt slab/slub can use
high order pages. However, what I focus on is why slab/slub can use compound
page, PageCompound() just on behalf of hugetlbfs pages or thp pages which
should used by apps, isn't it?

I am not entirely clear on what you are asking for. The following gives a
couple of answers to what I guess the question was.

THP pages and user pages are on the lru and are managed differently.
The slab allocators cannot work with those pages.

Slab allocators *can* allocate higher order pages therefore they could
allocate a page of the same order as huge pages and manage it that way.

However there is no way that these pages could be handled like THP pages
since they cannot be broken up (unless we add the capability to move slab
objects which I wanted to do for a long time).


You can boot a Linux system that uses huge pages for slab allocation
by specifying the following parameter on the kernel command line.

slub_min_order=9

The slub allocator will start using huge pages for all its storage
needs. You need a large number of huge pages to do this. Lots of memory
is going to be lost due to fragmentation but its going to be fast since
the slowpaths are rarely used. OOMs due to reclaim failure become much
more likely ;-).



It seems that I need to simple my question.
All pages which order >=1 are compound pages?


--
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] kernel: auditfilter: looping issue, memory leak if has 2 or more AUDIT_FILTERKEYs

[Chen Gang]

On 2013年04月11日 05:32, Eric Paris wrote:
> - Original Message -
>> > 
>> >   also for function audit_list:
>> > when call audit_make_reply fails (will return NULL).
>> > we need free all its related variables instead of only kfree rull.
>> >   (such as call autit_free_rule)
>> > 
>> >   please help check, thanks.
> audit_free_rule() takes a struct audit_entry, not an audit_rule. 

  yes. but maybe you misunderstand what I said (excuse me, my English is
not quite weill)
  I said: "need we process the rule just like audit_free_rule has done ?"


> struct audit_rule does not have additional things which need to be freed...
> 
> 

  oh, it is my fault:
(I did not notice: rule is struct audit_rule, not struct audit_krule).

  thanks.

  :-)

-- 
Chen Gang

Asianux Corporation
--
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/4] ARM: mmp: bring up pxa988 with device tree support

[Neil Zhang]

bring up pxa988 with device tree support.

Signed-off-by: Neil Zhang 
Signed-off-by: Chao Xie 
---
 arch/arm/boot/dts/pxa988-dkb.dts  |   36 ++
 arch/arm/boot/dts/pxa988.dtsi |  196 +
 arch/arm/mach-mmp/Kconfig |   25 
 arch/arm/mach-mmp/Makefile|1 +
 arch/arm/mach-mmp/common.c|   11 ++-
 arch/arm/mach-mmp/include/mach/addr-map.h |6 +
 arch/arm/mach-mmp/mmpx-dt.c   |   79 
 drivers/clk/mmp/Makefile  |1 +
 8 files changed, 354 insertions(+), 1 deletions(-)
 create mode 100644 arch/arm/boot/dts/pxa988-dkb.dts
 create mode 100644 arch/arm/boot/dts/pxa988.dtsi
 create mode 100644 arch/arm/mach-mmp/mmpx-dt.c

diff --git a/arch/arm/boot/dts/pxa988-dkb.dts b/arch/arm/boot/dts/pxa988-dkb.dts
new file mode 100644
index 000..2cee3ed
--- /dev/null
+++ b/arch/arm/boot/dts/pxa988-dkb.dts
@@ -0,0 +1,36 @@
+/*
+ *  Copyright (C) 2012 Marvell Technology Group Ltd.
+ *  Author: Haojian Zhuang 
+ *
+ *  This program is free software; you can redistribute it and/or modify
+ *  it under the terms of the GNU General Public License version 2 as
+ *  publishhed by the Free Software Foundation.
+ */
+
+/dts-v1/;
+/include/ "pxa988.dtsi"
+
+/ {
+   model = "Marvell PXA988 DKB Development Board";
+   compatible = "mrvl,pxa988-dkb", "mrvl,pxa988";
+
+   chosen {
+   bootargs = "console=ttyS0,115200 root=/dev/nfs 
nfsroot=192.168.1.100:/nfsroot/ 
ip=192.168.1.101:192.168.1.100::255.255.255.0::eth0:on";
+   };
+
+   memory {
+   reg = <0x 0x1000>;
+   };
+
+   soc {
+   apb@d400 {
+   uart1: uart@d4017000 {
+   status = "okay";
+   };
+
+   rtc: rtc@d401 {
+   status = "okay";
+   };
+   };
+   };
+};
diff --git a/arch/arm/boot/dts/pxa988.dtsi b/arch/arm/boot/dts/pxa988.dtsi
new file mode 100644
index 000..8ec89b0
--- /dev/null
+++ b/arch/arm/boot/dts/pxa988.dtsi
@@ -0,0 +1,196 @@
+/*
+ *  Copyright (C) 2013 Marvell Technology Group Ltd.
+ *  Author: Chao Xie 
+ *
+ *  This program is free software; you can redistribute it and/or modify
+ *  it under the terms of the GNU General Public License version 2 as
+ *  publishhed by the Free Software Foundation.
+ */
+
+/include/ "skeleton.dtsi"
+
+/ {
+   interrupt-parent = <>;
+
+   aliases {
+   serial0 = 
+   serial1 = 
+   serial2 = 
+   i2c0 = 
+   i2c1 = 
+   };
+
+   cpus {
+   cpu@0 {
+   compatible = "arm,cortex-a9";
+   next-level-cache = <>;
+   };
+   cpu@1 {
+   compatible = "arm,cortex-a9";
+   next-level-cache = <>;
+   };
+   };
+
+   gic: interrupt-controller@d1dfe100 {
+   compatible = "arm,cortex-a9-gic";
+   interrupt-controller;
+   #interrupt-cells = <3>;
+   reg = <0xd1dff000 0x1000>,
+ <0xd1dfe100 0x0100>;
+   };
+
+   L2: l2-cache-controller@d1dfb000 {
+   compatible = "arm,pl310-cache";
+   reg = <0xd1dfb000 0x1000>;
+   arm,data-latency = <2 1 1>;
+   arm,tag-latency = <2 1 1>;
+   arm,pwr-dynamic-clk-gating;
+   arm,pwr-standby-mode;
+   cache-unified;
+   cache-level = <2>;
+   };
+
+   local-timer@d1dfe600 {
+   compatible = "arm,cortex-a9-twd-timer";
+   reg = <0xd1dfe600 0x20>;
+   interrupts = <1 13 0x304>;
+   };
+
+   soc {
+   #address-cells = <1>;
+   #size-cells = <1>;
+   compatible = "simple-bus";
+   interrupt-parent = <>;
+   ranges;
+
+   axi@d420 {  /* AXI */
+   compatible = "mrvl,axi-bus", "simple-bus";
+   #address-cells = <1>;
+   #size-cells = <1>;
+   reg = <0xd420 0x0020>;
+   ranges;
+
+   intc: interrupt-controller@d4282000 {
+   compatible = "mrvl,mmp-intc";
+   reg = <0xd4282000 0x1000>;
+   mrvl,intc-wakeup = <0x114 0x3
+   0x144 0x3>;
+   };
+
+   };
+
+   apb@d400 {  /* APB */
+   compatible = "mrvl,apb-bus", "simple-bus";
+   #address-cells = <1>;
+   #size-cells = <1>;
+   reg = <0xd400 0x0020>;
+   ranges;
+
+

[PATCH 2/4] ARM: mmp: move function declaration to head file

[Neil Zhang]

Move some of the function declaration to head file.

Signed-off-by: Neil Zhang 
Signed-off-by: Chao Xie 
---
 arch/arm/mach-mmp/common.h  |3 +++
 arch/arm/mach-mmp/mmp-dt.c  |3 ---
 arch/arm/mach-mmp/mmp2-dt.c |3 ---
 3 files changed, 3 insertions(+), 6 deletions(-)

diff --git a/arch/arm/mach-mmp/common.h b/arch/arm/mach-mmp/common.h
index 0bdc50b..8c9b510 100644
--- a/arch/arm/mach-mmp/common.h
+++ b/arch/arm/mach-mmp/common.h
@@ -8,3 +8,6 @@ extern void mmp_restart(char, const char *);
 extern void __init pxa168_clk_init(void);
 extern void __init pxa910_clk_init(void);
 extern void __init mmp2_clk_init(void);
+
+extern void __init mmp_dt_irq_init(void);
+extern void __init mmp_dt_init_timer(void);
diff --git a/arch/arm/mach-mmp/mmp-dt.c b/arch/arm/mach-mmp/mmp-dt.c
index d063efa..af0bb5b 100644
--- a/arch/arm/mach-mmp/mmp-dt.c
+++ b/arch/arm/mach-mmp/mmp-dt.c
@@ -19,9 +19,6 @@
 
 #include "common.h"
 
-extern void __init mmp_dt_irq_init(void);
-extern void __init mmp_dt_init_timer(void);
-
 static const struct of_dev_auxdata pxa168_auxdata_lookup[] __initconst = {
OF_DEV_AUXDATA("mrvl,mmp-uart", 0xd4017000, "pxa2xx-uart.0", NULL),
OF_DEV_AUXDATA("mrvl,mmp-uart", 0xd4018000, "pxa2xx-uart.1", NULL),
diff --git a/arch/arm/mach-mmp/mmp2-dt.c b/arch/arm/mach-mmp/mmp2-dt.c
index fad431a..4ba1fbe 100644
--- a/arch/arm/mach-mmp/mmp2-dt.c
+++ b/arch/arm/mach-mmp/mmp2-dt.c
@@ -21,9 +21,6 @@
 
 #include "common.h"
 
-extern void __init mmp_dt_irq_init(void);
-extern void __init mmp_dt_init_timer(void);
-
 static const struct of_dev_auxdata mmp2_auxdata_lookup[] __initconst = {
OF_DEV_AUXDATA("mrvl,mmp-uart", 0xd403, "pxa2xx-uart.0", NULL),
OF_DEV_AUXDATA("mrvl,mmp-uart", 0xd4017000, "pxa2xx-uart.1", NULL),
-- 
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 0/4] bring up pxa988 with DT

[Neil Zhang]

This patch sets do the following things:
1. add wakeup function for ICU.
2. move some common funciton declaration to common.h
3. bring up pxa988 with DT support

Chao Xie (1):
  ARM: mmp: add wakeup function for ICU

Neil Zhang (3):
  ARM: mmp: move function declaration to head file
  ARM: mmp: bring up pxa988 with device tree support
  ARM: mmp: add SMP support for pxa988

 .../devicetree/bindings/arm/mrvl/intc.txt  |9 +
 arch/arm/boot/dts/pxa988-dkb.dts   |   36 
 arch/arm/boot/dts/pxa988.dtsi  |  196 
 arch/arm/mach-mmp/Kconfig  |   25 +++
 arch/arm/mach-mmp/Makefile |5 +
 arch/arm/mach-mmp/common.c |   11 +-
 arch/arm/mach-mmp/common.h |5 +
 arch/arm/mach-mmp/headsmp.S|  104 +++
 arch/arm/mach-mmp/include/mach/addr-map.h  |6 +
 arch/arm/mach-mmp/irq.c|   51 -
 arch/arm/mach-mmp/mmp-dt.c |3 -
 arch/arm/mach-mmp/mmp2-dt.c|3 -
 arch/arm/mach-mmp/mmpx-dt.c|   80 
 arch/arm/mach-mmp/platsmp.c|  170 +
 arch/arm/mach-mmp/reset.c  |   66 +++
 arch/arm/mach-mmp/reset.h  |   29 +++
 drivers/clk/mmp/Makefile   |1 +
 17 files changed, 783 insertions(+), 17 deletions(-)
 create mode 100644 arch/arm/boot/dts/pxa988-dkb.dts
 create mode 100644 arch/arm/boot/dts/pxa988.dtsi
 create mode 100644 arch/arm/mach-mmp/headsmp.S
 create mode 100644 arch/arm/mach-mmp/mmpx-dt.c
 create mode 100644 arch/arm/mach-mmp/platsmp.c
 create mode 100644 arch/arm/mach-mmp/reset.c
 create mode 100644 arch/arm/mach-mmp/reset.h

-- 
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 v2] net: mv643xx_eth: use managed devm_kzalloc

[David Miller]

From: Sebastian Hesselbarth 
Date: Wed, 10 Apr 2013 22:42:07 +0200

> This patch moves shared private data kzalloc to managed devm_kzalloc and
> cleans now unneccessary kfree and error handling.
> 
> Signed-off-by: Sebastian Hesselbarth 

This doesn't apply cleanly to the net-next tree.
--
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/4] ARM: mmp: add SMP support for pxa988

[Neil Zhang]

Add SMP support for pxa988.

Signed-off-by: Neil Zhang 
Signed-off-by: Chao Xie 
---
 arch/arm/mach-mmp/Makefile  |4 +
 arch/arm/mach-mmp/common.h  |2 +
 arch/arm/mach-mmp/headsmp.S |  104 ++
 arch/arm/mach-mmp/mmpx-dt.c |1 +
 arch/arm/mach-mmp/platsmp.c |  170 +++
 arch/arm/mach-mmp/reset.c   |   66 +
 arch/arm/mach-mmp/reset.h   |   29 +++
 7 files changed, 376 insertions(+), 0 deletions(-)
 create mode 100644 arch/arm/mach-mmp/headsmp.S
 create mode 100644 arch/arm/mach-mmp/platsmp.c
 create mode 100644 arch/arm/mach-mmp/reset.c
 create mode 100644 arch/arm/mach-mmp/reset.h

diff --git a/arch/arm/mach-mmp/Makefile b/arch/arm/mach-mmp/Makefile
index b60065f..e7b6173 100644
--- a/arch/arm/mach-mmp/Makefile
+++ b/arch/arm/mach-mmp/Makefile
@@ -9,6 +9,10 @@ obj-$(CONFIG_CPU_PXA168)   += pxa168.o
 obj-$(CONFIG_CPU_PXA910)   += pxa910.o
 obj-$(CONFIG_CPU_MMP2) += mmp2.o sram.o
 
+ifeq ($(CONFIG_SMP),y)
+obj-$(CONFIG_CPU_PXA988)   += platsmp.o headsmp.o reset.o
+endif
+
 ifeq ($(CONFIG_COMMON_CLK), )
 obj-y  += clock.o
 obj-$(CONFIG_CPU_PXA168)   += clock-pxa168.o
diff --git a/arch/arm/mach-mmp/common.h b/arch/arm/mach-mmp/common.h
index 8c9b510..7496cd0 100644
--- a/arch/arm/mach-mmp/common.h
+++ b/arch/arm/mach-mmp/common.h
@@ -1,5 +1,7 @@
 #define ARRAY_AND_SIZE(x)  (x), ARRAY_SIZE(x)
 
+extern struct smp_operations mmp_smp_ops;
+
 extern void timer_init(int irq);
 
 extern void __init icu_init_irq(void);
diff --git a/arch/arm/mach-mmp/headsmp.S b/arch/arm/mach-mmp/headsmp.S
new file mode 100644
index 000..2b6177e
--- /dev/null
+++ b/arch/arm/mach-mmp/headsmp.S
@@ -0,0 +1,104 @@
+/*
+ * linux/arch/arm/mach-mmp/headsmp.S
+ *
+ * Copyright (C) 2012 Marvell, Inc.
+ *
+ * Author: Neil Zhang 
+ *
+ * This software is licensed under the terms of the GNU General Public
+ * License version 2, as published by the Free Software Foundation, and
+ * may be copied, distributed, and modified under those terms.
+ *
+ * This program is distributed in the hope that 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.
+ *
+ */
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+   __CPUINIT
+
+/*
+ * Marvell specific entry point for secondary CPUs.
+ * The secondary kernel init calls v7_flush_dcache_all before it enables
+ * the L1; however, the L1 comes out of reset in an undefined state, so
+ * the clean + invalidate performed by v7_flush_dcache_all causes a bunch
+ * of cache lines with uninitialized data and uninitialized tags to get
+ * written out to memory, which does really unpleasant things to the main
+ * processor.  We fix this by performing an invalidate, rather than a
+ * clean + invalidate for secondary core, before jumping into the kernel.
+ *
+ * This funciton is cloned from arch/arm/mach-tegra/headsmp.S, and needs
+ * to be called for both secondary cores startup and primary core resume
+ * procedures.
+ */
+   .align L1_CACHE_SHIFT
+
+
+/*
+ * PXA specific entry point for secondary CPUs.  This provides
+ * a "holding pen" into which all secondary cores are held until we're
+ * ready for them to initialise.
+ */
+ENTRY(mmp_secondary_startup)
+   mrc p15, 0, r0, c0, c0, 5
+   and r0, r0, #15
+   adr r4, 1f
+   ldmia   r4, {r5, r6}
+   sub r4, r4, r5
+   add r6, r6, r4
+pen:   ldr r7, [r6]
+   cmp r7, r0
+   bne pen
+
+   /*
+* we've been released from the holding pen: secondary_stack
+* should now contain the SVC stack for this core
+*/
+   bl  v7_invalidate_l1
+   b   secondary_startup
+ENDPROC(mmp_secondary_startup)
+
+   .align  2
+1: .long   .
+   .long   pen_release
+
+
+/*
+ * Note: The following code is located into the .data section. This is to
+ *   allow sw_reset_flag and cpu_plugin_handler to be accessed with a
+ *   relative load while we can't rely on any MMU translation.
+ *   Reference from: arch/arm/kernel/sleep.S
+ */
+
+   .data
+   .align
+
+/*
+ * ROM code jumps to this function while waking up from CPU
+ * OFF or software reset state. Physical address of the function is
+ * stored at CA9_WARM_RESET_VECTOR while system is bring up.
+ */
+ENTRY(mmp_cpu_reset_entry)
+   adr r1, mmp_entry_vectors
+   mrc p15, 0, r0, c0, c0, 5
+   and r0, r0, #15 @ fetch CPUID
+1:
+   ldr r2, [r1, r0, lsl #2]@ get the handler addr for this core
+   cmp r2, #0
+   movne   pc, r2  @ jump to the handler
+   beq 1b
+ENDPROC(mmp_cpu_reset_entry)
+
+   /* Point to the address that save handlers for each core */
+   .global mmp_entry_vectors
+mmp_entry_vectors:
+   

[PATCH 1/4] ARM: mmp: add wakeup function for ICU

[Neil Zhang]

From: Chao Xie 

PXA988 will use GIC as its interrupt controller, and ICU is used as wakeup
logic. When AP subsystem is powered off, GIC will lose its context, the
PMU will need ICU to wakeup the AP subsystem.
When ICU works as wakeup logic, there is no need to know intc-nr-irqs,
change the corresponding code.

Signed-off-by: Chao Xie 
Signed-off-by: Neil Zhang 
---
 .../devicetree/bindings/arm/mrvl/intc.txt  |9 
 arch/arm/mach-mmp/irq.c|   51 
 2 files changed, 50 insertions(+), 10 deletions(-)

diff --git a/Documentation/devicetree/bindings/arm/mrvl/intc.txt 
b/Documentation/devicetree/bindings/arm/mrvl/intc.txt
index 8b53273..58c0e74 100644
--- a/Documentation/devicetree/bindings/arm/mrvl/intc.txt
+++ b/Documentation/devicetree/bindings/arm/mrvl/intc.txt
@@ -15,6 +15,8 @@ Required properties:
 - interrupt-controller : Identifies the node as an interrupt controller.
 - #interrupt-cells : Specifies the number of cells needed to encode an
   interrupt source.
+- mrvl,intc-wakeup : Specifies the address and value for global mask in the
+  interrupt controller.
 - mrvl,intc-nr-irqs : Specifies the number of interrupts in the interrupt
   controller.
 - mrvl,clr-mfp-irq : Specifies the interrupt that needs to clear MFP edge
@@ -39,6 +41,13 @@ Example:
mrvl,intc-nr-irqs = <2>;
};
 
+   intc: interrupt-controller@d4282000 {
+   compatible = "mrvl,mmp-intc";
+   reg = <0xd4282000 0x1000>;
+   mrvl,intc-wakeup = <0x114 0x3
+   0x144 0x3>;
+   };
+
 * Marvell Orion Interrupt controller
 
 Required properties
diff --git a/arch/arm/mach-mmp/irq.c b/arch/arm/mach-mmp/irq.c
index 3c71246..b8df948 100644
--- a/arch/arm/mach-mmp/irq.c
+++ b/arch/arm/mach-mmp/irq.c
@@ -16,6 +16,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -57,6 +58,7 @@ struct mmp_intc_conf {
 void __iomem *mmp_icu_base;
 static struct icu_chip_data icu_data[MAX_ICU_NR];
 static int max_icu_nr;
+static bool mmp_icu_wakeup;
 
 extern void mmp2_clear_pmic_int(void);
 
@@ -91,8 +93,11 @@ static void icu_mask_irq(struct irq_data *d)
int hwirq;
u32 r;
 
-   hwirq = d->irq - data->virq_base;
-   if (data == _data[0]) {
+   if (mmp_icu_wakeup)
+   hwirq = d->hwirq;
+   else
+   hwirq = d->irq - data->virq_base;
+   if (data == _data[0] || mmp_icu_wakeup) {
r = readl_relaxed(mmp_icu_base + (hwirq << 2));
r &= ~data->conf_mask;
r |= data->conf_disable;
@@ -110,8 +115,11 @@ static void icu_unmask_irq(struct irq_data *d)
int hwirq;
u32 r;
 
-   hwirq = d->irq - data->virq_base;
-   if (data == _data[0]) {
+   if (mmp_icu_wakeup)
+   hwirq = d->hwirq;
+   else
+   hwirq = d->irq - data->virq_base;
+   if (data == _data[0] || mmp_icu_wakeup) {
r = readl_relaxed(mmp_icu_base + (hwirq << 2));
r &= ~data->conf_mask;
r |= data->conf_enable;
@@ -415,6 +423,8 @@ void __init mmp_dt_irq_init(void)
const struct of_device_id *of_id;
struct mmp_intc_conf *conf;
int nr_irqs, irq_base, ret, irq;
+   const __be32 *wakeup_reg;
+   int size, i;
 
node = of_find_matching_node(NULL, intc_ids);
if (!node) {
@@ -424,18 +434,39 @@ void __init mmp_dt_irq_init(void)
of_id = of_match_node(intc_ids, node);
conf = of_id->data;
 
-   ret = of_property_read_u32(node, "mrvl,intc-nr-irqs", _irqs);
-   if (ret) {
-   pr_err("Not found mrvl,intc-nr-irqs property\n");
-   return;
-   }
-
mmp_icu_base = of_iomap(node, 0);
if (!mmp_icu_base) {
pr_err("Failed to get interrupt controller register\n");
return;
}
 
+   /* ICU is only used as wake up logic. */
+   wakeup_reg = of_get_property(node, "mrvl,intc-wakeup", );
+   if (wakeup_reg) {
+   mmp_icu_wakeup = 1;
+   size /= sizeof(*wakeup_reg);
+   i = 0;
+   /* disable the global irq/fiq in icu for all cores. */
+   while (i < size) {
+   unsigned offset, val;
+
+   offset = be32_to_cpup(wakeup_reg + i++);
+   val = be32_to_cpup(wakeup_reg + i++);
+   writel_relaxed(val, mmp_icu_base + offset);
+   }
+
+   gic_arch_extn.irq_mask = icu_mask_irq;
+   gic_arch_extn.irq_unmask = icu_unmask_irq;
+
+   return;
+   }
+
+   ret = of_property_read_u32(node, "mrvl,intc-nr-irqs", _irqs);
+   if (ret) {
+   pr_err("Not found mrvl,intc-nr-irqs property\n");
+   return;
+   }
+
irq_base = irq_alloc_descs(-1, 0, nr_irqs - NR_IRQS_LEGACY, 0);
if 

Re: [PATCH v3 00/12] event tracing expose change and bugfix/cleanup

[zhangwei(Jovi)]

On 2013/4/10 23:08, Steven Rostedt wrote:
> On Wed, 2013-04-10 at 11:26 +0800, zhangwei(Jovi) wrote:
>> From: "zhangwei(Jovi)" 
>>
>> Hi steven,
>>
>> I have reworked this patchset again with minor change.
>> [v2 -> v3:
>> -   change trace_descripte_t defintion in patch 3
>> -   new patch "export ftrace_events"
>> -   remove patch "export syscall metadata"
>> (syscall tracing are use same event_trace_ops backend as normal event 
>> tracepoint,
>>  so there's no need to export anything of syscall)
>> -   remove private data field in ftrace_event_file struct (also not needed)
>> ]
> 
> Thanks,
> 
> Note, I'm trying to catch up on my -rt responsibilities, and most likely
> wont get to this this week, and next week I'll be at collaboration
> summit. It may not be till after I get back from that, that I'll have a
> chance to look at these.
> 
> Depending on when Linus opens the next merge window, even if everything
> goes fine, this patch set may not make it into 3.10, and will have to
> wait till 3.11.
> 
> Just giving you a heads up.
It's fine for me, let's check this patch set later.
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: [PATCH] process cputimer is moving faster than its corresponding clock

[Olivier Langlois]

On Wed, 2013-04-10 at 13:35 +0200, Peter Zijlstra wrote:
> On Fri, 2013-04-05 at 13:59 -0400, Olivier Langlois wrote:
> > Process timers are moving fasters than their corresponding
> >  cpu clock for various reasons:
> > 
> > 1. There is a race condition when getting a timer sample that makes the 
> > sample
> >be smaller than it should leading to setting the timer expiration to 
> > soon.
> > 2. When initializing the cputimer, by including tasks deltas in the initial
> >timer value, it makes them be counted twice.
> > 3. When a thread autoreap itself when exiting, the last context switch 
> > update
> >will update the cputimer and not the overall process values stored in
> >signal.
> 
> Please explain these races. Things like task_sched_runtime() on which
> most of this stuff is build read both sum_exec_runtime and compute the
> delta while holding the rq->lock; this should avoid any and all races
> against update_curr() and the sort.
> 
In my previous reply, I have explained in length the race condition but
I didn't realize that you were also mentioning my refactoring of
task_sched_runtime() so I comment a little bit more about this proposal:

currently:

- cputimer is initialized with the result of thread_group_cputime()
which is (accounted time + tasks deltas)
- cputimer sample value is then cputimer + 1 more task_delta_exec() 
- After all active tasks pass through update_curr(), cputimer is
(accounted time + 2*(tasks deltas))

By being able to get separately get accounted time and delta, you can:

- Initialize cputimer to accounted time
- thread group cputimer sample will be cputimer + delta (which is
essentially equivalent to what would thread_group_cputime() return)
- After all the deltas are in by having called
account_group_exec_runtime(), cputimer will be set to (accounted time +
tasks delta) and have the exact same value of the corresponding process
clock.

In other words, currently the way the cputimer is initialized contribute
to make it advance faster than its corressponding process clock.

This part of the patch has nothing to do with race condition, as far as
I can tell, thread_group_cputime() and task_delta_exec() are rock solid.
It is just that you need delta and accounted time separately and
preferably atomically to be able to initialize posix cpu timer
correctly.

Greetings,
Olivier



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

[RFC Patch 2/2] mm: Add parameters to limit a rate of outputting memory error messages

[Mitsuhiro Tanino]

This patch introduces new sysctl interfaces in order to limit
a rate of outputting memory error messages.

- vm.memory_failure_print_ratelimit:
  Specify the minimum length of time between messages.
  By default the rate limiting is disabled.

- vm.memory_failure_print_ratelimit_burst:
  Specify the number of messages we can send before rate limiting.


Signed-off-by: Mitsuhiro Tanino 
---

diff --git a/a/Documentation/sysctl/vm.txt b/b/Documentation/sysctl/vm.txt
index 7dad994..eea6f4d 100644
--- a/a/Documentation/sysctl/vm.txt
+++ b/b/Documentation/sysctl/vm.txt
@@ -36,6 +36,8 @@ Currently, these files are in /proc/sys/vm:
 - max_map_count
 - memory_failure_dirty_panic
 - memory_failure_early_kill
+- memory_failure_print_ratelimit
+- memory_failure_print_ratelimit_burst
 - memory_failure_recovery
 - min_free_kbytes
 - min_slab_ratio
@@ -358,6 +360,30 @@ Applications can override this setting individually with 
the PR_MCE_KILL prctl
 
 ==
 
+memory_failure_print_ratelimit:
+
+Error messages related data lost which come from truncating
+dirty page cache are rate limited.
+memory_failure_print_ratelimit specifies the minimum length of
+time between these messages (in jiffies), by default the rate
+limiting is disabled.
+
+If a value is set to 5, we allow one error message every 5 seconds.
+
+==
+
+memory_failure_print_ratelimit_burst:
+
+While long term we enforce one message per
+memory_failure_print_ratelimit seconds, we do allow a burst of
+messages to pass through.
+memory_failure_print_ratelimit_burst specifies the number of
+messages we can send before rate limiting kicks in.
+If memory_failure_print_ratelimit is set to 0, this parameter
+is ineffective.
+
+==
+
 memory_failure_recovery
 
 Enable memory failure recovery (when supported by the platform)
diff --git a/a/include/linux/mm.h b/b/include/linux/mm.h
index 0025882..ca27bd9 100644
--- a/a/include/linux/mm.h
+++ b/b/include/linux/mm.h
@@ -1721,6 +1721,7 @@ extern int unpoison_memory(unsigned long pfn);
 extern int sysctl_memory_failure_dirty_panic;
 extern int sysctl_memory_failure_early_kill;
 extern int sysctl_memory_failure_recovery;
+extern struct ratelimit_state sysctl_memory_failure_print_ratelimit;
 extern void shake_page(struct page *p, int access);
 extern atomic_long_t mce_bad_pages;
 extern int soft_offline_page(struct page *page, int flags);
diff --git a/a/kernel/sysctl.c b/b/kernel/sysctl.c
index 452dd80..0703c2e 100644
--- a/a/kernel/sysctl.c
+++ b/b/kernel/sysctl.c
@@ -1421,6 +1421,20 @@ static struct ctl_table vm_table[] = {
.extra1 = ,
.extra2 = ,
},
+   {
+   .procname   = "memory_failure_print_ratelimit",
+   .data   = 
_memory_failure_print_ratelimit.interval,
+   .maxlen = sizeof(int),
+   .mode   = 0644,
+   .proc_handler   = proc_dointvec_jiffies,
+   },
+   {
+   .procname   = "memory_failure_print_ratelimit_burst",
+   .data   = _memory_failure_print_ratelimit.burst,
+   .maxlen = sizeof(int),
+   .mode   = 0644,
+   .proc_handler   = proc_dointvec,
+   },
 #endif
{ }
 };
diff --git a/a/mm/memory-failure.c b/b/mm/memory-failure.c
index 6d3c0ed..ce5bb1a 100644
--- a/a/mm/memory-failure.c
+++ b/b/mm/memory-failure.c
@@ -55,6 +55,7 @@
 #include 
 #include 
 #include 
+#include 
 #include "internal.h"
 
 int sysctl_memory_failure_dirty_panic __read_mostly = 0;
@@ -78,6 +79,16 @@ EXPORT_SYMBOL_GPL(hwpoison_filter_dev_minor);
 EXPORT_SYMBOL_GPL(hwpoison_filter_flags_mask);
 EXPORT_SYMBOL_GPL(hwpoison_filter_flags_value);
 
+/*
+ * This enforces a rate limit for outputting error message.
+ * The default interval is set to "0" HZ. This means that
+ * outputting error message is not limited by default.
+ * The default burst is set to "10". This parameter can control
+ * to output number of messages per interval.
+ * If interval is set to "0", the burst is ineffective.
+ */
+DEFINE_RATELIMIT_STATE(sysctl_memory_failure_print_ratelimit, 0 * HZ, 10);
+
 static int hwpoison_filter_dev(struct page *p)
 {
struct address_space *mapping;
@@ -622,13 +633,16 @@ static int me_pagecache_dirty(struct page *p, unsigned 
long pfn)
SetPageError(p);
if (mapping) {
/* Print more information about the file. */
-   if (mapping->host != NULL && S_ISREG(mapping->host->i_mode))
-   pr_info("MCE %#lx: File was corrupted: Dev:%s Inode:%lu 
Offset:%lu\n",
-   page_to_pfn(p), mapping->host->i_sb->s_id,
-   mapping->host->i_ino, page_index(p));
-   else
-   pr_info("MCE 

[RFC Patch 1/2] mm: Add a parameter to force a kernel panic when memory error occurs on dirty cache

[Mitsuhiro Tanino]

This patch introduces a sysctl interface,
vm.memory_failure_dirty_panic, to provide selectable actions
when a memory error is detected on dirty page cache.


Signed-off-by: Mitsuhiro Tanino 
---

diff --git a/a/Documentation/sysctl/vm.txt b/b/Documentation/sysctl/vm.txt
index 078701f..7dad994 100644
--- a/a/Documentation/sysctl/vm.txt
+++ b/b/Documentation/sysctl/vm.txt
@@ -34,6 +34,7 @@ Currently, these files are in /proc/sys/vm:
 - legacy_va_layout
 - lowmem_reserve_ratio
 - max_map_count
+- memory_failure_dirty_panic
 - memory_failure_early_kill
 - memory_failure_recovery
 - min_free_kbytes
@@ -306,6 +307,29 @@ The default value is 65536.
 
 =
 
+memory_failure_dirty_panic:
+
+Control whether a system continues to operate or not when uncorrected
+recoverable memory error (typically a 2bit error in a memory module)
+is detected in the background by hardware and a page type is a dirty
+page cache.
+
+When uncorrected recoverable memory error occurs on a dirty page
+cache, the kernel truncates the page because a system crashes if
+the kernel touches the corrupted page. However, this page truncation
+causes data lost problem because the dirty page cache does not write
+back to a disk. As a result, if the dirty cache belongs a file,
+the file is not renewed and remains old data.
+
+0: Keep a system running. Note a dirty page is truncated and data
+of dirty page is lost.
+
+1: Force the kernel panic.
+
+The default value is 0.
+
+=
+
 memory_failure_early_kill:
 
 Control how to kill processes when uncorrected memory error (typically
diff --git a/a/include/linux/mm.h b/b/include/linux/mm.h
index 66e2f7c..0025882 100644
--- a/a/include/linux/mm.h
+++ b/b/include/linux/mm.h
@@ -1718,6 +1718,7 @@ enum mf_flags {
 extern int memory_failure(unsigned long pfn, int trapno, int flags);
 extern void memory_failure_queue(unsigned long pfn, int trapno, int flags);
 extern int unpoison_memory(unsigned long pfn);
+extern int sysctl_memory_failure_dirty_panic;
 extern int sysctl_memory_failure_early_kill;
 extern int sysctl_memory_failure_recovery;
 extern void shake_page(struct page *p, int access);
diff --git a/a/kernel/sysctl.c b/b/kernel/sysctl.c
index c88878d..452dd80 100644
--- a/a/kernel/sysctl.c
+++ b/b/kernel/sysctl.c
@@ -1412,6 +1412,15 @@ static struct ctl_table vm_table[] = {
.extra1 = ,
.extra2 = ,
},
+   {
+   .procname   = "memory_failure_dirty_panic",
+   .data   = _memory_failure_dirty_panic,
+   .maxlen = sizeof(sysctl_memory_failure_dirty_panic),
+   .mode   = 0644,
+   .proc_handler   = proc_dointvec_minmax,
+   .extra1 = ,
+   .extra2 = ,
+   },
 #endif
{ }
 };
diff --git a/a/mm/memory-failure.c b/b/mm/memory-failure.c
index c6e4dd3..6d3c0ed 100644
--- a/a/mm/memory-failure.c
+++ b/b/mm/memory-failure.c
@@ -57,6 +57,8 @@
 #include 
 #include "internal.h"
 
+int sysctl_memory_failure_dirty_panic __read_mostly = 0;
+
 int sysctl_memory_failure_early_kill __read_mostly = 0;
 
 int sysctl_memory_failure_recovery __read_mostly = 1;
@@ -618,8 +620,16 @@ static int me_pagecache_dirty(struct page *p, unsigned 
long pfn)
struct address_space *mapping = page_mapping(p);
 
SetPageError(p);
-   /* TBD: print more information about the file. */
if (mapping) {
+   /* Print more information about the file. */
+   if (mapping->host != NULL && S_ISREG(mapping->host->i_mode))
+   pr_info("MCE %#lx: File was corrupted: Dev:%s Inode:%lu 
Offset:%lu\n",
+   page_to_pfn(p), mapping->host->i_sb->s_id,
+   mapping->host->i_ino, page_index(p));
+   else
+   pr_info("MCE %#lx: A dirty page cache was corrupted.\n",
+   page_to_pfn(p));
+
/*
 * IO error will be reported by write(), fsync(), etc.
 * who check the mapping.
@@ -657,6 +667,19 @@ static int me_pagecache_dirty(struct page *p, unsigned 
long pfn)
mapping_set_error(mapping, EIO);
}
 
+   /* Force a kernel panic instantly because a dirty page cache is
+  truncated and this leads data corruption problem when
+  application processes old data.
+   */
+   if (sysctl_memory_failure_dirty_panic) {
+   if (mapping != NULL && mapping->host != NULL)
+   panic("MCE %#lx: Force a panic because a dirty page 
cache was corrupted: File type:0x%x\n",
+   page_to_pfn(p), mapping->host->i_mode);
+   else
+   panic("MCE %#lx: Force a panic because a dirty page 
cache was corrupted.\n",
+   

[RFC Patch 0/2] mm: Add parameters to make kernel behavior at memory error on dirty cache selectable

[Mitsuhiro Tanino]

Hi All,
Please find a patch set that introduces these new sysctl interfaces,
to handle a case when an memory error is detected on dirty page cache.

- vm.memory_failure_dirty_panic
- vm.memory_failure_print_ratelimit
- vm.memory_failure_print_ratelimit_burst

Problem
-
Recently, it is common that enterprise servers likely have a large
amount of memory, especially for cloud environment. This means that
possibility of memory failures is increased.

To handle memory failure, Linux has a hwpoison feature. When a memory
error is detected by memory scrub, the error is reported as machine
check, uncorrected recoverable (UCR), to OS. Then OS isolates the memory
region with memory failure if the memory page can be isolated.
The hwpoison handles it according to the memory region, such as kernel,
dirty cache, clean cache. If the memory region can be isolated, the
page is marked "hwpoison" and it is not used again.

When SRAO machine check is reported on a page which is included dirty
page cache, the page is truncated because the memory is corrupted and
data of the page cannot be written to a disk any more.

As a result, if the dirty cache includes user data, the data is lost,
and data corruption occurs if an application uses old data.



Solution
-
The patch proposes a new sysctl interface, vm.memory_failure_dirty_panic,
in order to prevent data corruption comes from data lost problem.
Also this patch displays information of affected file such as device name,
inode number, file offset and file type if the file is mapped on a memory
and the page is dirty cache.

When SRAO machine check occurs on a dirty page cache, corresponding
data cannot be recovered any more. Therefore, the patch proposes a kernel
option to keep a system running or force system panic in order
to avoid further trouble such as data corruption problem of application.

System administrator can select an error action using this option
according to characteristics of target system.



Use Case
-
This option is intended to be adopted in KVM guest because it is
supposed that Linux on KVM guest operates customers business and
it is big impact to lost or corrupt customers data by memory failure.

On the other hand, this option does not recommend to apply KVM host
as following reasons.

- Making KVM host panic has a big impact because all virtual guests are
  affected by their host panic. Affected virtual guests are forced to stop
  and have to be restarted on the other hypervisor.

- If disk cached model of qemu is set to "none", I/O type of virtual
  guests becomes O_DIRECT and KVM host does not cache guest's disk I/O.
  Therefore, if SRAO machine check is reported on a dirty page cache
  in KVM host, its virtual machines are not affected by the machine check.
  So the host is expected to keep operating instead of kernel panic.


Past discussion

This problem was previously discussed in the kernel community, 
(refer: mail threads pertaining to
http://marc.info/?l=linux-kernel=135187403804934=4). 

> > - I worry that if a hardware error occurs, it might affect a large
> >   amount of memory all at the same time.  For example, if a 4G memory
> >   block goes bad, this message will be printed a million times?


As Andrew mentioned in the above threads, if 4GB memory blocks goes bad,
error messages will be printed a million times and this behavior loses
a system reliability.

Therefore, the second patch introduces two sysctl parameters for
__ratelimit() which is used at mce_notify_irq() in order to notify
occurrence of machine check event to system administrator.
The use of __ratelimit(), this patch can limit quantity of messages
per interval to be output at syslog or terminal console.

If system administrator needs to limit quantity of messages,
these parameters are available.

- vm.memory_failure_print_ratelimit:
  Specifies the minimum length of time between messages.
  By default the rate limiting is disabled.

- vm.memory_failure_print_ratelimit_burst:
  Specifies the number of messages we can send before rate limiting.



Test Results
-
These patches are tested on 3.8.1 kernel(FC18) using software pseudo MCE
injection from KVM host to guest.


 Host OS Screen logs(SRAO Machine Check injection) 
Inject software pseudo MCE into guest qemu process.

(1) Load mce-inject module
# modprobe mce-inject

(2) Find a PID of target qemu-kvm and page struct
# ps -C qemu-kvm -o pid=
 8176

(3) Edit software pseudo MCE data
Choose a offset of page struct and insert the offset to ADDR line in mce-file.

#  ./page-types -p 8176 -LN | grep "___UDlAMa_b___"
voffset offset  flags
...
7fd25eb77   344d77  ___UDlAMa_b___
7fd25eb78   344d78  ___UDlAMa_b___
7fd25eb79   344d79  ___UDlAMa_b___
7fd25eb7a   344d7a  ___UDlAMa_b___
7fd25eb7b   344d7b  ___UDlAMa_b___

Re: [PATCH] net: mvmdio: add clocks property to binding documentation

[David Miller]

From: Sebastian Hesselbarth 
Date: Wed, 10 Apr 2013 19:36:29 +0200

> Patch "net: mvmdio: get and enable optional clock" was missing an
> update of the corresponding device tree binding documentation. This
> patch adds the clocks property to mvmdio binding documentation.
> 
> Signed-off-by: Sebastian Hesselbarth 

Please reference commits by SHA1 ID as well as the commit log
message header line (the latter of which should be inside
of parenthesis and double quotes).

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: [PATCH] tcp: incoming connections might use wrong route under synflood

[David Miller]

From: Dmitry Popov 
Date: Thu, 11 Apr 2013 00:09:09 +0400

> There is a bug in cookie_v4_check (net/ipv4/syncookies.c):
>   flowi4_init_output(, 0, sk->sk_mark, RT_CONN_FLAGS(sk),
>  RT_SCOPE_UNIVERSE, IPPROTO_TCP,
>  inet_sk_flowi_flags(sk),
>  (opt && opt->srr) ? opt->faddr : ireq->rmt_addr,
>  ireq->loc_addr, th->source, th->dest);
> 
> Here we do not respect sk->sk_bound_dev_if, therefore wrong dst_entry may be 
> taken. This dst_entry is used in new socket (get_cookie_sock -> 
> tcp_v4_syn_recv_sock), so its packets may take wrong path. There is no such 
> bug in ipv6 code and non-cookie code (usual case). Bugfix below.
> 
> Signed-off-by: Dmitry Popov 

Please format your commit messages properly, by not allowing lines of
text longer than 80 columns.

Thank you.
--
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.8-stable] net: count hw_addr syncs so that unsync works properly.

[David Miller]

From: Jeremy Kerr 
Date: Thu, 11 Apr 2013 13:02:15 +1000

> Hi all,
> 
 This patch looks like it should be in the 3.8-stable tree, should we apply
 it?
>>>
>>> I queue up networking patches as needed and that queue is
>>> visible at:
>>>
>>> http://patchwork.ozlabs.org/user/bundle/2566/?state=*
>> 
>> Actually, this bundle is not visible via that link.  It appears to be a
>> public bundle and visible via
>> http://patchwork.ozlabs.org/bundle/davem/stable/?state=* .  I have
>> insider knowledge :-)
> 
> Perhaps for public bundles, I should make the private link automatically
> redirect to the public one?

Yes.
--
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] net: usb: active URB submitted multiple times

[David Miller]

I think you need to read Documentation/SubmittingPatches, and
Documentation/email-clients.txt

Do not submit the diff for the individual files seperately,
provide all the changes together as a single patch.

Do not use an attachment, instead provide your patch inline
as plain ASCII, unformatted text.
--
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] kernel: kallsyms: memory override issue, need check destination buffer length

[Chen Gang]

  We don't export any symbols > 128 characters, but if we did then
  kallsyms_expand_symbol() would overflow the buffer handed to it.
  So we need check destination buffer length when copying.

  the related test:
if we define an EXPORT function which name more than 128.
will panic when call kallsyms_lookup_name by init_kprobes on booting.
after check the length (provide this patch), it is ok.

  Implementaion:
add additional destination buffer length parameter (maxlen)
if uncompressed string is too long (>= maxlen), it will be truncated.
not check the parameters whether valid, since it is a static function.


Signed-off-by: Chen Gang 
Signed-off-by: Rusty Russell 
---
 kernel/kallsyms.c |   26 +-
 1 files changed, 17 insertions(+), 9 deletions(-)

diff --git a/kernel/kallsyms.c b/kernel/kallsyms.c
index 2169fee..ae7b90d 100644
--- a/kernel/kallsyms.c
+++ b/kernel/kallsyms.c
@@ -84,12 +84,15 @@ static int is_ksym_addr(unsigned long addr)
  /*
  * Expand a compressed symbol data into the resulting uncompressed string,
+ * if uncompressed string is too long (>= maxlen), it will be truncated,
  * given the offset to where the symbol is in the compressed stream.
  */
-static unsigned int kallsyms_expand_symbol(unsigned int off, char *result)
+static unsigned int kallsyms_expand_symbol(unsigned int off,
+  char *result, int maxlen)
 {
int len, skipped_first = 0;
const u8 *tptr, *data;
+   char *begin = result;
/* Get the compressed symbol length from the first symbol byte. */
data = _names[off];
@@ -113,14 +116,16 @@ static unsigned int kallsyms_expand_symbol(unsigned int 
off, char *result)
while (*tptr) {
if (skipped_first) {
-   *result = *tptr;
-   result++;
+   *result++ = *tptr;
+   if (result - begin == maxlen - 1)
+   goto tail;
} else
skipped_first = 1;
tptr++;
}
}
 +tail:
*result = '\0';
/* Return to offset to the next symbol. */
@@ -176,7 +181,7 @@ unsigned long kallsyms_lookup_name(const char *name)
unsigned int off;
for (i = 0, off = 0; i < kallsyms_num_syms; i++) {
-   off = kallsyms_expand_symbol(off, namebuf);
+   off = kallsyms_expand_symbol(off, namebuf, sizeof(namebuf));
if (strcmp(namebuf, name) == 0)
return kallsyms_addresses[i];
@@ -195,7 +200,7 @@ int kallsyms_on_each_symbol(int (*fn)(void *, const char *, 
struct module *,
int ret;
for (i = 0, off = 0; i < kallsyms_num_syms; i++) {
-   off = kallsyms_expand_symbol(off, namebuf);
+   off = kallsyms_expand_symbol(off, namebuf, sizeof(namebuf));
ret = fn(data, namebuf, NULL, kallsyms_addresses[i]);
if (ret != 0)
return ret;
@@ -294,7 +299,8 @@ const char *kallsyms_lookup(unsigned long addr,
pos = get_symbol_pos(addr, symbolsize, offset);
/* Grab name */
-   kallsyms_expand_symbol(get_symbol_offset(pos), namebuf);
+   kallsyms_expand_symbol(get_symbol_offset(pos),
+  namebuf, sizeof(namebuf));
if (modname)
*modname = NULL;
return namebuf;
@@ -315,7 +321,8 @@ int lookup_symbol_name(unsigned long addr, char *symname)
pos = get_symbol_pos(addr, NULL, NULL);
/* Grab name */
-   kallsyms_expand_symbol(get_symbol_offset(pos), symname);
+   kallsyms_expand_symbol(get_symbol_offset(pos),
+  symname, sizeof(symname));
return 0;
}
/* See if it's in a module. */
@@ -333,7 +340,8 @@ int lookup_symbol_attrs(unsigned long addr, unsigned long 
*size,
pos = get_symbol_pos(addr, size, offset);
/* Grab name */
-   kallsyms_expand_symbol(get_symbol_offset(pos), name);
+   kallsyms_expand_symbol(get_symbol_offset(pos),
+  name, sizeof(name));
modname[0] = '\0';
return 0;
}
@@ -463,7 +471,7 @@ static unsigned long get_ksymbol_core(struct kallsym_iter 
*iter)
iter->type = kallsyms_get_symbol_type(off);
 -  off = kallsyms_expand_symbol(off, iter->name);
+   off = kallsyms_expand_symbol(off, iter->name, sizeof(iter->name));
return off - iter->nameoff;
 }
-- 
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  

Re: [PATCH 3.8-stable] net: count hw_addr syncs so that unsync works properly.

[Jeremy Kerr]

Hi all,

>>> This patch looks like it should be in the 3.8-stable tree, should we apply
>>> it?
>>
>> I queue up networking patches as needed and that queue is
>> visible at:
>>
>> http://patchwork.ozlabs.org/user/bundle/2566/?state=*
> 
> Actually, this bundle is not visible via that link.  It appears to be a
> public bundle and visible via
> http://patchwork.ozlabs.org/bundle/davem/stable/?state=* .  I have
> insider knowledge :-)

Perhaps for public bundles, I should make the private link automatically
redirect to the public one?

Cheers,


Jeremy

--
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/RFC 4/6] ARM: shmobile: sh73a0: add support for the DMA0 controller in DT

[Simon Horman]

On Thu, Apr 11, 2013 at 12:01:27PM +0900, Simon Horman wrote:
> On Thu, Apr 11, 2013 at 12:19:47AM +0200, Guennadi Liakhovetski wrote:
> > Add a Device Tree node for the DMA0 controller on sh73a0 and
> > auxdata to supply platform data to the driver. To enable the
> > DMA0 controller it also has to be taken out of reset.
> > 
> > Signed-off-by: Guennadi Liakhovetski 
> 
> 
> Hi Guennadi, this seems reasonable to me.
> 
> I guess the best thing is for you to repost it once the pre-requisites
> are in place.

Also, Magnus, could you review this?
--
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/RFC 4/6] ARM: shmobile: sh73a0: add support for the DMA0 controller in DT

[Simon Horman]

On Thu, Apr 11, 2013 at 12:19:47AM +0200, Guennadi Liakhovetski wrote:
> Add a Device Tree node for the DMA0 controller on sh73a0 and
> auxdata to supply platform data to the driver. To enable the
> DMA0 controller it also has to be taken out of reset.
> 
> Signed-off-by: Guennadi Liakhovetski 


Hi Guennadi, this seems reasonable to me.

I guess the best thing is for you to repost it once the pre-requisites
are in place.
--
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/RFC 6/6] ARM: shmobile: kzm9g-reference: add DMA channels to the MMCIF DT

[Simon Horman]

On Thu, Apr 11, 2013 at 12:19:49AM +0200, Guennadi Liakhovetski wrote:
> The MMCIF driver can use DMA for data transfer, add suitable
> Device Tree bindings.
> 
> Signed-off-by: Guennadi Liakhovetski 

Hi Guennadi, this seems reasonable to me.

I guess the best thing is for you to repost it once the pre-requisites
are in place.

> ---
>  arch/arm/boot/dts/sh73a0-kzm9g-reference.dts |3 +++
>  1 files changed, 3 insertions(+), 0 deletions(-)
> 
> diff --git a/arch/arm/boot/dts/sh73a0-kzm9g-reference.dts 
> b/arch/arm/boot/dts/sh73a0-kzm9g-reference.dts
> index ed9dd45..e1d0d5d 100644
> --- a/arch/arm/boot/dts/sh73a0-kzm9g-reference.dts
> +++ b/arch/arm/boot/dts/sh73a0-kzm9g-reference.dts
> @@ -156,6 +156,9 @@
>   bus-width = <8>;
>   vmmc-supply = <_1p8v>;
>   status = "okay";
> + dmas = < 0xd1
> +  0xd2>;
> + dma-names = "tx", "rx";
>  };
>  
>   {
> -- 
> 1.7.2.5
> 
> --
> To unsubscribe from this list: send the line "unsubscribe linux-sh" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> 
--
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.8-stable] net: count hw_addr syncs so that unsync works properly.

[Stephen Rothwell]

Hi Dave,

On Wed, 10 Apr 2013 20:54:01 -0400 (EDT) David Miller  
wrote:
>
> From: Jonghwan Choi 
> Date: Thu, 11 Apr 2013 09:31:44 +0900
> 
> > This patch looks like it should be in the 3.8-stable tree, should we apply
> > it?
> 
> I queue up networking patches as needed and that queue is
> visible at:
> 
> http://patchwork.ozlabs.org/user/bundle/2566/?state=*

Actually, this bundle is not visible via that link.  It appears to be a
public bundle and visible via
http://patchwork.ozlabs.org/bundle/davem/stable/?state=* .  I have
insider knowledge :-)

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


pgp9MMKEbW0kR.pgp
Description: PGP signature

Re: [PATCH] x86: add phys addr validity check for /dev/mem mmap

[Simon Jeons]

Hi H.Peter,
On 04/11/2013 10:48 AM, H. Peter Anvin wrote:

On 04/10/2013 07:40 PM, Simon Jeons wrote:

Hi H.Peter,
On 04/04/2013 09:13 AM, H. Peter Anvin wrote:

On 04/03/2013 06:11 PM, Simon Jeons wrote:

Why we consider boot_cpu_data.x86_phys_bits instead of e820 map here?


Because x86_phys_bits is what controls how much address space the
processor has.  e820 tells us how much *RAM* the machine has, or
specifically, how much RAM the machine had on boot.

I have 8GB memory in my machine, but when I accumulated every e820
ranges which dump in dmesg, there are 25MB memory less then 8GB(1024*8)
memory, why 25MB miss?


For whatever reason your BIOS is stealing some memory, possibly for video.


Thanks for your quick response. ;-)
My machine is new which have i7 cpu. How much memory video need? 8MB? 
Why I miss 25MB?




-hpa




--
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] rbd: revalidate_disk upon rbd resize

[Alex Elder]

On 04/10/2013 02:30 PM, Alex Elder wrote:
> On 04/10/2013 11:06 AM, Laurent Barbe wrote:
>> If rbd disk is open and rbd resize is done, new size is not visible by
>> filesystem.
>> Like is done in virtio-blk and dm driver, revalidate_disk() permits to
>> update the bd_inode size.
> 
> Looks good to me.  I'll take this in via the ceph-client tree.
> Thanks a lot.

Unfortunately this leads to a lock inversion.  I'm going to
think about how to go about resolving it, so I won't be
committing it just yet.

-Alex

> 
> Reviewed-by: Alex Elder 
> 
>> Signed-off-by: Laurent Barbe 
>> ---
>>  drivers/block/rbd.c |1 +
>>  1 file changed, 1 insertion(+)
>>
>> diff --git a/drivers/block/rbd.c b/drivers/block/rbd.c
>> index f556f8a..1963025 100644
>> --- a/drivers/block/rbd.c
>> +++ b/drivers/block/rbd.c
>> @@ -2293,6 +2293,7 @@ static void rbd_update_mapping_size(struct rbd_device 
>> *rbd_dev)
>>  dout("setting size to %llu sectors", (unsigned long long) size);
>>  rbd_dev->mapping.size = (u64) size;
>>  set_capacity(rbd_dev->disk, size);
>> +revalidate_disk(rbd_dev->disk);
>>  }
>>  
>>  /*
>>
> 

--
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/4] Documentation: Add memory mapped ARM architected timer binding

[Stephen Boyd]

On 04/10/13 03:13, Mark Rutland wrote:
 +
 +- #size-cells : Must be 1.
 +
 +- ranges : Indicates parent and child bus address space are the same.
 +
>>> Similarly, what if someone wants to write a more complex mapping for some
>>> reason?
>>>
>>> We should be able to handle it if we use the standard accessors.
>> Maybe I should just leave this part out? They are standard DT properties
>> so I could assume DT writers know what to do.
> I'd be happy with that. It may be worth describing them as "as necessary" or
> something to that effect.

Ok. I added this and removed the property descriptions:

Note that #address-cells, #size-cells, and ranges shall be present to ensure
the CPU can address a frame's registers.

> I can see why we need to specify secure/non-secure, but I'm not sure why we
> need to specify hyp/user/kernel usage. Could we not leave this up to the 
> kernel
> to figure out?
>
> A basic overveiew for those that don't know about the memory mapped timers:
>
> * There's one control frame CNTCTLBase. Some registers in this frame are only
>   available for secure accesses, including CNTNSAR which sets whether the
>   counter frames are accessible from the non-secure side.
>
> * There are up to 8 timer frames, which have their own CNTVOFF and
>   physical/virtual timers. Each frame CNTBaseN is duplicated at CNTPL0BaseN
>   with CNTVOFF and CNTPL0ACR (which controls PL0 accesses) inaccessible.
>
> I can see that we might have frames/registers we can't access (if we were
> booted on the non-secure side), but I can't see anything limiting whether we
> use a frame for kernel/hyp/user beyond that. Have I missed something?
>
> Could we not have something like the following for each frame:
>
> frame0 {
>   frame-id = <0>;
>   status = "disabled"; /* booted NS, secure firmware has not enabled 
> access */
>   reg = <0x... 0x1000>, /* CNTBase0 */
> <0x... 0x1000>; /* CNTPL0Base0 */
> };
>

I don't think you're missing anything. Technically the second view is
not always implemented though. Using the status property should be
sufficient I think.

>> Also to get the frame number, I was thinking maybe we should expand the
>> reg property to have two address cells. Then we could have reg = <0
>> 0xf0001000 0x1000>.
> We could do that, but then you definitely need a more complex ranges property,
> and additional parsing code to handle grabbing it out of the reg property. I
> can't see what it buys us.

Ok. It would mandate node names like "frame@0", "frame@1", but I'll drop
the idea unless someone else finds it useful.

-- 
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
hosted by The Linux Foundation

--
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] x86: add phys addr validity check for /dev/mem mmap

[H. Peter Anvin]

On 04/10/2013 07:40 PM, Simon Jeons wrote:
> Hi H.Peter,
> On 04/04/2013 09:13 AM, H. Peter Anvin wrote:
>> On 04/03/2013 06:11 PM, Simon Jeons wrote:
>>> Why we consider boot_cpu_data.x86_phys_bits instead of e820 map here?
>>>
>> Because x86_phys_bits is what controls how much address space the
>> processor has.  e820 tells us how much *RAM* the machine has, or
>> specifically, how much RAM the machine had on boot.
> 
> I have 8GB memory in my machine, but when I accumulated every e820
> ranges which dump in dmesg, there are 25MB memory less then 8GB(1024*8)
> memory, why 25MB miss?
> 

For whatever reason your BIOS is stealing some memory, possibly for video.

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

mm/slab: extremly high slab cache problem

[lulu he]

Hi,

I'am not used to ask but I have followed every piece of information I
could not find solution, so I'am trying here for help.

On one of my server, I have some memory/disk KV service,
Memory KV behave like memcached, ask for a big trunk of memory(10GB)
when initialized,
Disk Kv behave like leveldbd, its random read and sequential write,
and it frequently reads a lot files.
Memory are all alloced using libc malloc.

My KV server process do not consume a lot of memory as below (since
lack of memory, I have killed memory KV, leaving only disk KV, but
free memory still goes down):

:~$top
PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
20 0 5030m 3.9g 2772 S 8 6.1 10430:52 tair_server
20 0 4833m 3.9g 4560 S 8 6.1 10171:07 tair_server
20 0 4844m 3.9g 3844 S 38 6.1 10073:32 tair_server
20 0 4765m 3.8g 4144 S 8 6.0 10552:39 tair_server
20 0 2941m 2.4g 9.8m S 0 3.8 256:45.70 tair_server
20 0 2953m 2.4g 12m S 1 3.7 276:54.64 tair_server

BUT, my memory are gone.
$free -m
 total   used   free sharedbuffers cached
Mem: 64552  57778   6774  0 16326
-/+ buffers/cache:  57435   7117
Swap:0  0  0


I can see slab consume lots of my memory, and it's unreclaimable.
$cat /proc/meminfo
MemTotal:   66101892 kB
MemFree: 6816228 kB
Buffers:   17024 kB
Cached:   456640 kB
SwapCached:0 kB
Active: 19697712 kB
Inactive:3197312 kB
Active(anon):   19546504 kB
Inactive(anon):  2875632 kB
Active(file): 151208 kB
Inactive(file):   321680 kB
Unevictable:  48 kB
Mlocked:   0 kB
SwapTotal: 0 kB
SwapFree:  0 kB
Dirty:  6612 kB
Writeback:72 kB
AnonPages:  22421152 kB
Mapped:54408 kB
Shmem:   332 kB
Slab:   28870400 kB
SReclaimable: 213344 kB
SUnreclaim: 28657056 kB
KernelStack:   3 kB
PageTables:62776 kB
NFS_Unstable:  0 kB
Bounce:0 kB
WritebackTmp:  0 kB
CommitLimit:33050944 kB
Committed_AS:   37517224 kB
VmallocTotal:   34359738367 kB
VmallocUsed:  388624 kB
VmallocChunk:   34324313700 kB
HardwareCorrupted: 0 kB
HugePages_Total:   0
HugePages_Free:0
HugePages_Rsvd:0
HugePages_Surp:0
Hugepagesize:   2048 kB
DirectMap4k:5696 kB
DirectMap2M: 2082816 kB
DirectMap1G:65011712 kB

Here is the slab info.
$slabtop -s c
 OBJS ACTIVE  USE OBJ SIZE  SLABS OBJ/SLAB CACHE SIZE NAME
69842766 69838389  38%0.19K 1663025   42  13304200K kmalloc-192
69314912 69314796  38%0.12K 2166091   32   8664364K kmalloc-128
70866624 70866323  39%0.06K 1107291   64   4429164K kmalloc-64
69299968 69299592  38%0.03K 541406  128   2165624K kmalloc-32
128388  72434  56%0.99K   4230   32135360K ext4_inode_cache
208782  94112  45%0.19K   4971   42 39768K dentry


I don't who and why consume such lots memory, and how to solve this.
Can this be an interval kernel error?
OR it's a glibc problem, it do'not return memory back to system, due
to frequently disk read?

thanks in advance, any help will be appreciated.


--
loloseed
--
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] Add new model: rts5249

[wei_wang]

From: Wei WANG 

v2:
1. Modify copyright notice
2. Add macro definitions for phy registers
3. Replace mdelay with msleep

Wei WANG (1):
  mfd:rtsx: Support RTS5249

 drivers/mfd/Makefile |2 +-
 drivers/mfd/rts5249.c|  241 ++
 drivers/mfd/rtsx_pcr.c   |5 +
 drivers/mfd/rtsx_pcr.h   |1 +
 include/linux/mfd/rtsx_pci.h |   36 +++
 5 files changed, 284 insertions(+), 1 deletion(-)
 create mode 100644 drivers/mfd/rts5249.c

-- 
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 v2] mfd:rtsx: Support RTS5249

[wei_wang]

From: Wei WANG 

Support new model: RTS5249

Signed-off-by: Wei WANG 
---
 drivers/mfd/Makefile |2 +-
 drivers/mfd/rts5249.c|  241 ++
 drivers/mfd/rtsx_pcr.c   |5 +
 drivers/mfd/rtsx_pcr.h   |1 +
 include/linux/mfd/rtsx_pci.h |   36 +++
 5 files changed, 284 insertions(+), 1 deletion(-)
 create mode 100644 drivers/mfd/rts5249.c

diff --git a/drivers/mfd/Makefile b/drivers/mfd/Makefile
index b90409c..f61ac02 100644
--- a/drivers/mfd/Makefile
+++ b/drivers/mfd/Makefile
@@ -9,7 +9,7 @@ obj-$(CONFIG_MFD_88PM805)   += 88pm805.o 88pm80x.o
 obj-$(CONFIG_MFD_SM501)+= sm501.o
 obj-$(CONFIG_MFD_ASIC3)+= asic3.o tmio_core.o
 
-rtsx_pci-objs  := rtsx_pcr.o rts5209.o rts5229.o rtl8411.o 
rts5227.o
+rtsx_pci-objs  := rtsx_pcr.o rts5209.o rts5229.o rtl8411.o 
rts5227.o rts5249.o
 obj-$(CONFIG_MFD_RTSX_PCI) += rtsx_pci.o
 
 obj-$(CONFIG_HTC_EGPIO)+= htc-egpio.o
diff --git a/drivers/mfd/rts5249.c b/drivers/mfd/rts5249.c
new file mode 100644
index 000..15dc848
--- /dev/null
+++ b/drivers/mfd/rts5249.c
@@ -0,0 +1,241 @@
+/* Driver for Realtek PCI-Express card reader
+ *
+ * Copyright(c) 2009-2013 Realtek Semiconductor Corp. All rights reserved.
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms of the GNU General Public License as published by the
+ * Free Software Foundation; either version 2, or (at your option) any
+ * later version.
+ *
+ * This program is distributed in the hope that 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 .
+ *
+ * Author:
+ *   Wei WANG 
+ *   No. 128, West Shenhu Road, Suzhou Industry Park, Suzhou, China
+ */
+
+#include 
+#include 
+#include 
+
+#include "rtsx_pcr.h"
+
+static u8 rts5249_get_ic_version(struct rtsx_pcr *pcr)
+{
+   u8 val;
+
+   rtsx_pci_read_register(pcr, DUMMY_REG_RESET_0, );
+   return val & 0x0F;
+}
+
+static int rts5249_extra_init_hw(struct rtsx_pcr *pcr)
+{
+   rtsx_pci_init_cmd(pcr);
+
+   /* Configure GPIO as output */
+   rtsx_pci_add_cmd(pcr, WRITE_REG_CMD, GPIO_CTL, 0x02, 0x02);
+   /* Switch LDO3318 source from DV33 to card_3v3 */
+   rtsx_pci_add_cmd(pcr, WRITE_REG_CMD, LDO_PWR_SEL, 0x03, 0x00);
+   rtsx_pci_add_cmd(pcr, WRITE_REG_CMD, LDO_PWR_SEL, 0x03, 0x01);
+   /* LED shine disabled, set initial shine cycle period */
+   rtsx_pci_add_cmd(pcr, WRITE_REG_CMD, OLT_LED_CTL, 0x0F, 0x02);
+   /* Correct driving */
+   rtsx_pci_add_cmd(pcr, WRITE_REG_CMD,
+   SD30_CLK_DRIVE_SEL, 0xFF, 0x99);
+   rtsx_pci_add_cmd(pcr, WRITE_REG_CMD,
+   SD30_CMD_DRIVE_SEL, 0xFF, 0x99);
+   rtsx_pci_add_cmd(pcr, WRITE_REG_CMD,
+   SD30_DAT_DRIVE_SEL, 0xFF, 0x92);
+
+   return rtsx_pci_send_cmd(pcr, 100);
+}
+
+static int rts5249_optimize_phy(struct rtsx_pcr *pcr)
+{
+   int err;
+
+   err = rtsx_pci_write_phy_register(pcr, PHY_REG_REV, 0xFE46);
+   if (err < 0)
+   return err;
+
+   msleep(1);
+
+   return rtsx_pci_write_phy_register(pcr, PHY_BPCR, 0x05C0);
+}
+
+static int rts5249_turn_on_led(struct rtsx_pcr *pcr)
+{
+   return rtsx_pci_write_register(pcr, GPIO_CTL, 0x02, 0x02);
+}
+
+static int rts5249_turn_off_led(struct rtsx_pcr *pcr)
+{
+   return rtsx_pci_write_register(pcr, GPIO_CTL, 0x02, 0x00);
+}
+
+static int rts5249_enable_auto_blink(struct rtsx_pcr *pcr)
+{
+   return rtsx_pci_write_register(pcr, OLT_LED_CTL, 0x08, 0x08);
+}
+
+static int rts5249_disable_auto_blink(struct rtsx_pcr *pcr)
+{
+   return rtsx_pci_write_register(pcr, OLT_LED_CTL, 0x08, 0x00);
+}
+
+static int rts5249_card_power_on(struct rtsx_pcr *pcr, int card)
+{
+   int err;
+
+   rtsx_pci_init_cmd(pcr);
+   rtsx_pci_add_cmd(pcr, WRITE_REG_CMD, CARD_PWR_CTL,
+   SD_POWER_MASK, SD_VCC_PARTIAL_POWER_ON);
+   rtsx_pci_add_cmd(pcr, WRITE_REG_CMD, PWR_GATE_CTRL,
+   LDO3318_PWR_MASK, 0x02);
+   err = rtsx_pci_send_cmd(pcr, 100);
+   if (err < 0)
+   return err;
+
+   msleep(5);
+
+   rtsx_pci_init_cmd(pcr);
+   rtsx_pci_add_cmd(pcr, WRITE_REG_CMD, CARD_PWR_CTL,
+   SD_POWER_MASK, SD_VCC_POWER_ON);
+   rtsx_pci_add_cmd(pcr, WRITE_REG_CMD, PWR_GATE_CTRL,
+   LDO3318_PWR_MASK, 0x06);
+   err = rtsx_pci_send_cmd(pcr, 100);
+   if (err < 0)
+   return err;
+
+   return 0;
+}
+
+static int rts5249_card_power_off(struct rtsx_pcr *pcr, int card)
+{
+   rtsx_pci_init_cmd(pcr);
+   

Re: [PATCH] Sys V shared memory limited to 8TiB.

[Robin Holt]

On Wed, Apr 10, 2013 at 04:15:07PM -0700, Andrew Morton wrote:
> On Tue, 9 Apr 2013 21:39:24 -0500 Robin Holt  wrote:
> 
> > Trying to run an application which was trying to put data into half
> > of memory using shmget(), we found that having a shmall value below
> > 8EiB-8TiB would prevent us from using anything more than 8TiB.  By setting
> > kernel.shmall greater that 8EiB-8TiB would make the job work.
> > 
> > In the newseg() function, ns->shm_tot which, at 8TiB is INT_MAX.
> 
> You have way too much memory.
> 
> > ipc/shm.c:
> >  458 static int newseg(struct ipc_namespace *ns, struct ipc_params *params)
> >  459 {
> > ...
> >  465 int numpages = (size + PAGE_SIZE -1) >> PAGE_SHIFT;
> > ...
> >  474 if (ns->shm_tot + numpages > ns->shm_ctlall)
> >  475 return -ENOSPC;
> >
> > ...
> >
> > --- a/include/linux/ipc_namespace.h
> > +++ b/include/linux/ipc_namespace.h
> > @@ -43,8 +43,8 @@ struct ipc_namespace {
> >  
> > size_t  shm_ctlmax;
> > size_t  shm_ctlall;
> > +   unsigned long   shm_tot;
> > int shm_ctlmni;
> > -   int shm_tot;
> > /*
> >  * Defines whether IPC_RMID is forced for _all_ shm segments regardless
> >  * of shmctl()
> 
> I reviewed everything for fallout from this and don't see any obvious
> issues.
> 
> I do wonder about the appropriateness of the unsigned long type.  Most
> (but by no means all) code in this area uses size_t, and the
> above-quoted ns->shm_ctlall is size_t.

The only reason I went with unsigned long instead of size_t was most
places in the kernel track stuff I recalled that was tracking stuff
in pages used unsigned longs.  Also, I found shm_tot field in shm_info
structure was an unsigned long so this felt like a natural fit.  I would
happily changed to size_t.  Whatever you feel is right.

> And the above-quoted num_pages is `int'.  Both the size and signedness
> of `int' make no sense - what happens if the incoming ipc_params.u.size
> is >2G?
> 
> So I'll add this, and ask whether ipc_namespace.shm_tot should be size_t?
> 
> --- a/ipc/shm.c~ipc-sysv-shared-memory-limited-to-8tib-fix
> +++ a/ipc/shm.c
> @@ -462,7 +462,7 @@ static int newseg(struct ipc_namespace *
>   size_t size = params->u.size;
>   int error;
>   struct shmid_kernel *shp;
> - int numpages = (size + PAGE_SIZE -1) >> PAGE_SHIFT;
> + size_t numpages = (size + PAGE_SIZE - 1) >> PAGE_SHIFT;

I was holding off from that change only because I was asking for this
to go to stable and this doubles the size of the patch. ;)

>   struct file * file;
>   char name[13];
>   int id;
> _

Thank you,
Robin
--
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] x86: add phys addr validity check for /dev/mem mmap

[Simon Jeons]

Hi H.Peter,
On 04/04/2013 09:13 AM, H. Peter Anvin wrote:

On 04/03/2013 06:11 PM, Simon Jeons wrote:

Why we consider boot_cpu_data.x86_phys_bits instead of e820 map here?


Because x86_phys_bits is what controls how much address space the
processor has.  e820 tells us how much *RAM* the machine has, or
specifically, how much RAM the machine had on boot.


I have 8GB memory in my machine, but when I accumulated every e820 
ranges which dump in dmesg, there are 25MB memory less then 8GB(1024*8) 
memory, why 25MB miss?




-hpa



--
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] KVM: ARM: Fix wrong address in comment

[Jonghwan Choi]

hyp_hvc vector offset should be 0x14 and hyp_svc vector offset should be
0x8.

Signed-off-by: Jonghwan Choi 
---
 arch/arm/kvm/interrupts.S |4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/arch/arm/kvm/interrupts.S b/arch/arm/kvm/interrupts.S
index 8ca87ab..a8e0c2d 100644
--- a/arch/arm/kvm/interrupts.S
+++ b/arch/arm/kvm/interrupts.S
@@ -235,9 +235,9 @@ ENTRY(kvm_call_hyp)
  * instruction is issued since all traps are disabled when running the host
  * kernel as per the Hyp-mode initialization at boot time.
  *
- * HVC instructions cause a trap to the vector page + offset 0x18 (see
hyp_hvc
+ * HVC instructions cause a trap to the vector page + offset 0x14 (see
hyp_hvc
  * below) when the HVC instruction is called from SVC mode (i.e. a guest or
the
- * host kernel) and they cause a trap to the vector page + offset 0xc when
HVC
+ * host kernel) and they cause a trap to the vector page + offset 0x8 when
HVC
  * instructions are called from within Hyp-mode.
  *
  * Hyp-ABI: Calling HYP-mode functions from host (in SVC mode):
-- 
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] checkpatch: Warn on comparisons to true and false

[Dave Jones]

On Wed, Apr 10, 2013 at 03:57:51PM -0700, Andrew Morton wrote:
 > On Tue, 09 Apr 2013 20:17:14 -0700 Joe Perches  wrote:
 > 
 > > Comparisons of A to true and false are better written
 > > as A and !A.
 > > 
 > > Bleat a message on use.
 > 
 > hm.  I'm counting around 1,100 instances of "== true" and "== false".
 > 
 > That's a lot of people to shout at.  Is it really worthwhile? 
 > "foo==true" is a bit of a waste of space but I can't say that I find it
 > terribly offensive.

It would be interesting to see how many people have historically screwed 
up and used (!a) when they mean (a) and vice versa, versus spelling
it out longform.  I'd be surprised if the results weren't skewed
in favour of the more verbose form.

Dave

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

regulator: Some patches for twl-regulator are not found in regulator tree

[Axel Lin]

Hi Mark,
I found some patches for twl are not in linux-next, and I cannot find them
in your tree ( although you replied the patches applied. )

I think below patches are missing:
[PATCH] regulator: twl: Remove TWL6030_FIXED_RESOURCE [1]
[PATCH] regulator: twl: Remove VDD1_VSEL_table and VDD2_VSEL_table [2]
[PATCH] regulator: twl: Convert fixed voltage to use 
regulator_list_voltage_linear [3]

[1] https://lkml.org/lkml/2013/2/15/691
[2] https://lkml.org/lkml/2013/2/15/272
[3] https://lkml.org/lkml/2013/2/15/681
( For [3], I guess you have applied another commit:
https://git.kernel.org/cgit/linux/kernel/git/broonie/regulator.git/commit/?id=51261dae00f22c1fc1e324a26e9b21b87715fd58
Looks like it's in topic/twl, but it's strange I cannot find topic/twl in 
regulator tree now.
)

I'm wondering if I need to resend these patches?

Regards,
Axel


--
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.8-stable] GFS2: Fix unlock of fcntl locks during withdrawn state

[Jonghwan Choi]

This patch looks like it should be in the 3.8-stable tree, should we apply
it?

--

From: "Steven Whitehouse "

commit c2952d202f710d326ac36a8ea6bd216b20615ec8 upstream

When withdraw occurs, we need to continue to allow unlocks of fcntl
locks to occur, however these will only be local, since the node has
withdrawn from the cluster. This prevents triggering a VFS level
bug trap due to locks remaining when a file is closed.

Signed-off-by: Steven Whitehouse 
Signed-off-by: Jonghwan Choi 
---
 fs/gfs2/file.c |5 -
 1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/fs/gfs2/file.c b/fs/gfs2/file.c
index 991ab2d..7af426b 100644
--- a/fs/gfs2/file.c
+++ b/fs/gfs2/file.c
@@ -924,8 +924,11 @@ static int gfs2_lock(struct file *file, int cmd, struct
file_lock *fl)
cmd = F_SETLK;
fl->fl_type = F_UNLCK;
}
-   if (unlikely(test_bit(SDF_SHUTDOWN, >sd_flags)))
+   if (unlikely(test_bit(SDF_SHUTDOWN, >sd_flags))) {
+   if (fl->fl_type == F_UNLCK)
+   posix_lock_file_wait(file, fl);
return -EIO;
+   }
if (IS_GETLK(cmd))
return dlm_posix_get(ls->ls_dlm, ip->i_no_addr, file, fl);
else if (fl->fl_type == F_UNLCK)
-- 
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 3.8-stable] GFS2: return error if malloc failed in gfs2_rs_alloc()

[Jonghwan Choi]

This patch looks like it should be in the 3.8-stable tree, should we apply
it?

--

From: "Wei Yongjun "

commit 441362d06be349430d06e37286adce4b90e6ce96 upstream

The error code in gfs2_rs_alloc() is set to ENOMEM when error
but never be used, instead, gfs2_rs_alloc() always return 0.
Fix to return 'error'.

Signed-off-by: Wei Yongjun 
Signed-off-by: Steven Whitehouse 
Signed-off-by: Jonghwan Choi 
---
 fs/gfs2/rgrp.c |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/fs/gfs2/rgrp.c b/fs/gfs2/rgrp.c
index b7eff07..9afba3d6 100644
--- a/fs/gfs2/rgrp.c
+++ b/fs/gfs2/rgrp.c
@@ -576,7 +576,7 @@ int gfs2_rs_alloc(struct gfs2_inode *ip)
RB_CLEAR_NODE(>i_res->rs_node);
 out:
up_write(>i_rw_mutex);
-   return 0;
+   return error;
 }
 
 static void dump_rs(struct seq_file *seq, const struct gfs2_blkreserv *rs)
-- 
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] module: add kset_obj_exists() and use it

[Rusty Russell]

Greg KH  writes:

> On Tue, Apr 09, 2013 at 01:22:09PM +0200, Veaceslav Falico wrote:
>> Add a new function, kset_obj_exists(), which is identical to
>> kset_find_obj() but doesn't take a reference to the kobject
>> found and only returns bool if found/not found.
>> 
>> The main purpose would be to avoid the possible race scenario,
>> when we could get the reference in between the kref_put() and
>> kobject_release() functions (i.e. kref_put() already ran,
>> refcount became 0, but the kobject_release() function still
>> didn't run, and we try to get via kobject_get() and thus ending
>> up with a released kobject). It can be triggered, for example,
>> by running insmod/rmmod bonding in parallel, which ends up in
>> a race between kset_obj_find() in mod_sysfs_init() and rmmod's
>> mod_sysfs_fini()/kobject_put().
>
> As Rusty points out, this isn't a kobject issue that can be solved with
> a new api call, but rather, the user of the kobject code needs to be
> fixed, with something like his proposed patch instead.
>
> So, because of this, I can't take this patch, sorry.

Greg, I'm shocked!  Surely you've been doing this long enough to know
that we don't use that kind of language on lkml?

To restore the list's reputation as a hostile pressure cooker powered by
the smouldering remains of flame-roasted newcomers, allow me to correct
your reply:

"NAK.  And you smell."

Crisis averted,
Rusty.
PS.  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: [char-misc-next 0/3 v7] Support NFC device on MEI CL bus

[Greg KH]

On Thu, Apr 11, 2013 at 03:03:28AM +0200, Samuel Ortiz wrote:
> v6 -> v7:
>* Removed include/uapi/linux/mei/nfc.h.
>  All MEI NFC definitions are now folded into drivers/misc/mei/nfc.c

All now applied, thanks for the persistance.

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: [PATCHv9 2/8] zsmalloc: add documentation

[Rob Landley]

On 04/10/2013 01:18:54 PM, Seth Jennings wrote:

This patch adds a documentation file for zsmalloc at
Documentation/vm/zsmalloc.txt


Docs acked-by: Rob Landley 

Literary criticism below:


Signed-off-by: Seth Jennings 
---
 Documentation/vm/zsmalloc.txt | 68  
+++

 1 file changed, 68 insertions(+)
 create mode 100644 Documentation/vm/zsmalloc.txt

diff --git a/Documentation/vm/zsmalloc.txt  
b/Documentation/vm/zsmalloc.txt

new file mode 100644
index 000..85aa617
--- /dev/null
+++ b/Documentation/vm/zsmalloc.txt
@@ -0,0 +1,68 @@
+zsmalloc Memory Allocator
+
+Overview
+
+zmalloc a new slab-based memory allocator,
+zsmalloc, for storing compressed pages.


zmalloc a new slab-based memory allocator, zsmalloc? (How does one  
zmalloc zsmalloc?)


Out of curiosity, what does zsmalloc stand for, anyway?


 It is designed for
+low fragmentation and high allocation success rate on
+large object, but <= PAGE_SIZE allocations.


1) objects

2) maybe "large objects for <= PAGE_SIZE"...


+zsmalloc differs from the kernel slab allocator in two primary
+ways to achieve these design goals.
+
+zsmalloc never requires high order page allocations to back
+slabs, or "size classes" in zsmalloc terms. Instead it allows
+multiple single-order pages to be stitched together into a
+"zspage" which backs the slab.  This allows for higher allocation
+success rate under memory pressure.
+
+Also, zsmalloc allows objects to span page boundaries within the
+zspage.  This allows for lower fragmentation than could be had
+with the kernel slab allocator for objects between PAGE_SIZE/2
+and PAGE_SIZE.  With the kernel slab allocator, if a page compresses
+to 60% of it original size, the memory savings gained through
+compression is lost in fragmentation because another object of


I lean towards "are lost", but it's debatable. (Savings are plural, but  
savings could also be treated as a mass noun like water/air/bison that  
doesn't get pluralized because you can't count instances of a liquid.  
No idea which is more common.)



+the same size can't be stored in the leftover space.
+
+This ability to span pages results in zsmalloc allocations not being
+directly addressable by the user.  The user is given an
+non-dereferencable handle in response to an allocation request.
+That handle must be mapped, using zs_map_object(), which returns
+a pointer to the mapped region that can be used.  The mapping is
+necessary since the object data may reside in two different
+noncontigious pages.


Presumably this allows packing of unmapped entities if you detect  
fragmentation and are up for a latency spike?


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/

Re: [PATCH v8 10/13] PCI/acpiphp: do not use ACPI PCI subdriver mechanism

[Yijing Wang]

>> Hi Bjorn,
>> Thanks for review.
>>
>>> My goal is that a user should never have to specify a kernel boot
>>> parameter or edit a modules.conf file, but the user did previously
>>> have some way to influence whether we use pciehp or acpiphp.  I know
>>> we still have some issues, particularly with acpiphp, so I'm a little
>>> concerned that by removing the CONFIG_HOTPLUG_PCI_ACPI=m, we might be
>>> removing a way to work around those issues.
>>>
>>> A distro that previously used CONFIG_HOTPLUG_PCI_ACPI=m will now have
>>> to use =y, so modules.conf is no longer applicable.  Can you convince
>>> me that the user still has a way to work around issues?  I spent quite
>>> a while trying to understand the pciehp/acpiphp dependencies, but it's
>>> pretty tangled web.
>> I will try my best to explain the relationships between pciehp and acpiphp
>> as of v3.9-rc6.
>>
>> The pciehp driver always have priority over the acpiphp driver.
>> That is, the acpiphp driver rejects binding to an ACPI PCI hotplug slot if
>> a) The slot's parent is a PCIe port with native hotplug capability
>> b) OSPM has taken over PCIe native hotplug control from BIOS.
>> !(root->osc_control_set & OSC_PCI_EXPRESS_NATIVE_HP_CONTROL)
>> The above check has no dependency on the loading order of pciehp and acpiphp
>> drivers. So converting acpiphp driver to builit-in should be ok.
>>
>> On the other hand, I remember Yinghai has mentioned that some PCIe ports
>> with native hotplug capability doesn't work as expected with the pciehp 
>> driver
>> and should be managed by the acpiphp driver. Currently we could achieve that
>> by using boot param "pcie_ports=compat", but this will disable PCIe port
>> drivers altogether. And I also remember that Rafael has mentioned that
>> some BIOSes exhibit strange dependency among PCIe OSC controls, so it's
>> not feasible to only disable PCIe native hotplug.
>>
>> For "pciehp_force", it does only affect the way pciehp to detect a hotplug
>> slot, it doesn't affect acpiphp at all.
>>
>> To sum up, converting acpiphp as built-in should not affect the relationship
>> between pciehp and acpiphp driver.
> 
> My concern is that a user used to be able to remove acpiphp from
> modules.conf.  Now removing acpiphp will require a kernel rebuild.
> But maybe that won't turn out to be a problem.

Hi Bjorn,
   If user don't want to occupy the slot by acpiphp. Conservative approach, 
what about add a kernel parameter
to control acpiphp to enumerate slot ?

Thanks!
Yijing
> 
>> So how about splitting this patch into
>> two and adding more comments for the Kconfig change?
> 
> Yes, please at least split this into two.  While you're at it, please
> also split the first patch into "remove unnecessary is_added guard"
> and "cleanup."
> 
> Bjorn
> 
> .
> 


-- 
Thanks!
Yijing

--
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: [PATCHv9 8/8] zswap: add documentation

[Rob Landley]

On 04/10/2013 01:19:00 PM, Seth Jennings wrote:

This patch adds the documentation file for the zswap functionality

Signed-off-by: Seth Jennings 
---
 Documentation/vm/zsmalloc.txt |  2 +-
 Documentation/vm/zswap.txt| 82  
+++

 2 files changed, 83 insertions(+), 1 deletion(-)
 create mode 100644 Documentation/vm/zswap.txt


Acked-by: Rob Landley 

Minor kibbitzing anyway:

diff --git a/Documentation/vm/zsmalloc.txt  
b/Documentation/vm/zsmalloc.txt

index 85aa617..4133ade 100644
--- a/Documentation/vm/zsmalloc.txt
+++ b/Documentation/vm/zsmalloc.txt
@@ -65,4 +65,4 @@ zs_unmap_object(pool, handle);
 zs_free(pool, handle);

 /* destroy the pool */
-zs_destroy_pool(pool);
+zs_destroy_pool(pool);
diff --git a/Documentation/vm/zswap.txt b/Documentation/vm/zswap.txt
new file mode 100644
index 000..f29b82f
--- /dev/null
+++ b/Documentation/vm/zswap.txt
@@ -0,0 +1,82 @@
+Overview:
+
+Zswap is a lightweight compressed cache for swap pages. It takes
+pages that are in the process of being swapped out and attempts to
+compress them into a dynamically allocated RAM-based memory pool.
+If this process is successful, the writeback to the swap device is
+deferred and, in many cases, avoided completely.  This results in
+a significant I/O reduction and performance gains for systems that
+are swapping.
+
+Zswap provides compressed swap caching that basically trades CPU  
cycles

+for reduced swap I/O.  This trade-off can result in a significant
+performance improvement as reads to/writes from to the compressed


writes from to?


+cache almost always faster that reading from a swap device


are almost


+which incurs the latency of an asynchronous block I/O read.
+
+Some potential benefits:
+* Desktop/laptop users with limited RAM capacities can mitigate the
+    performance impact of swapping.
+* Overcommitted guests that share a common I/O resource can
+    dramatically reduce their swap I/O pressure, avoiding heavy
+    handed I/O throttling by the hypervisor.  This allows more work
+    to get done with less impact to the guest workload and guests
+    sharing the I/O subsystem
+* Users with SSDs as swap devices can extend the life of the device  
by

+    drastically reducing life-shortening writes.


Does it work even if you have no actual swap mounted? And if you swap  
to NBD in a cluster it can keep network traffic down.


+Zswap evicts pages from compressed cache on an LRU basis to the  
backing
+swap device when the compress pool reaches it size limit or the pool  
is

+unable to obtain additional pages from the buddy allocator.  This
+requirement had been identified in prior community discussions.


I do not understand the "this requirement" sentence: aren't you just  
describing the design here? Memory evicts to the compressed cache,  
which evicts to persistent storage? What do historical community  
discussions have to do with it? "We designed this feature based on user  
feedback" is pretty much like saying "and this was developed in an open  
source manner"...


+To enabled zswap, the "enabled" attribute must be set to 1 at boot  
time.

+e.g. zswap.enabled=1


So if you configure it in, nothing happens. You have to press an extra  
button on the command line to have anything actually happen.


Why? (And why can't swapon do this? I dunno, swapon /dev/null or  
something, which the swapon guys can make a nice flag for later.)



+Design:
+
+Zswap receives pages for compression through the Frontswap API and
+is able to evict pages from its own compressed pool on an LRU basis
+and write them back to the backing swap device in the case that the
+compressed pool is full or unable to secure additional pages from
+the buddy allocator.
+
+Zswap makes use of zsmalloc for the managing the compressed memory
+pool.  This is because zsmalloc is specifically designed to minimize


s/.  This is because zsmalloc/, which/


+fragmentation on large (> PAGE_SIZE/2) allocation sizes.  Each
+allocation in zsmalloc is not directly accessible by address.
+Rather, a handle is return by the allocation routine and that handle


returned

+must be mapped before being accessed.  The compressed memory pool  
grows

+on demand and shrinks as compressed pages are freed.  The pool is
+not preallocated.
+
+When a swap page is passed from frontswap to zswap, zswap maintains
+a mapping of the swap entry, a combination of the swap type and swap
+offset, to the zsmalloc handle that references that compressed swap
+page.  This mapping is achieved with a red-black tree per swap type.
+The swap offset is the search key for the tree nodes.
+
+During a page fault on a PTE that is a swap entry, frontswap calls
+the zswap load function to decompress the page into the page
+allocated by the page fault handler.
+
+Once there are no PTEs referencing a swap page stored in zswap
+(i.e. the count in the swap_map goes to 0) the swap code calls
+the zswap invalidate function, via frontswap, to free the 

Re: [PATCH 14/30] thermal/exynos: remove unnecessary header inclusions

[Eduardo Valentin]

Rui, Arnd,

As agreed in [1], I will be helping on the thermal maintenance.

On 10-04-2013 20:04, Arnd Bergmann wrote:

In multiplatform configurations, we cannot include headers
provided by only the exynos platform. Fortunately a number
of drivers that include those headers do not actually need
them, so we can just remove the inclusions.

Signed-off-by: Arnd Bergmann 
Cc: linux...@vger.kernel.org
Cc: Zhang Rui 


This patch looks good to me.

You can add my:
Acked-by: Eduardo Valentin 


[1] - http://marc.info/?l=linux-pm=136560509922173=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] kernel: auditfilter: looping issue, memory leak if has 2 or more AUDIT_FILTERKEYs

[Chen Gang]

On 2013年04月11日 05:38, Eric Paris wrote:
> - Original Message -
>> > 
>> >   also for function audit_list_rules:
>> > when call audit_make_reply fails (will return NULL).
>> > we also need process data->buf, not only data itself.
>> > 
>> >   please help check, thanks.
> struct audit_rule_data {
> [...]
> charbuf[0]; /* string fields buffer */
> };
> 
> The last element in the struct is 0 length.  But the allocation in 
> audit_krule_to_data() looks like:
> 
> data = kmalloc(sizeof(*data) + krule->buflen, GFP_KERNEL);
> 
> So now data->buf appears as an allocation of size krule->buflen.
> 
> We do not need to free it separately.  This is a pretty common C trick.

  ok, thanks

  it is my fault.

  :-)

-- 
Chen Gang

Asianux Corporation
--
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] checkpatch: Warn on comparisons to true and false

[Joe Perches]

On Wed, 2013-04-10 at 15:57 -0700, Andrew Morton wrote:
> On Tue, 09 Apr 2013 20:17:14 -0700 Joe Perches  wrote:
> > Comparisons of A to true and false are better written
> > as A and !A.
> > Bleat a message on use.
> hm.  I'm counting around 1,100 instances of "== true" and "== false".

And about all of them in are staging, where I think they
really should be fixed.

$ find . -maxdepth 2 -type d \
   while read file ; do \
  echo "$(git grep -E '(==|\!=)\s*(true|false)' $file | wc -l)  $file"; \
  done | sort -rn | head -10
1375 .
1298 ./drivers
1055 ./drivers/staging
63 ./drivers/net
59 ./drivers/gpu
24 ./net
20 ./drivers/media
17 ./net/nfc
13 ./fs
11 ./drivers/usb

> That's a lot of people to shout at.

Not really.

>  Is it really worthwhile? 

I think so.


--
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 09/30] mmc: sdhci-s3c: remove platform dependencies

[Chris Ball]

Hi,

On Wed, Apr 10 2013, Arnd Bergmann wrote:
> plat/regs-sdhci.h is not used anywhere but in the sdhci-s3c
> driver, so it can become a local file there and all other
> inclusions removed.
>
> plat/sdhci.h is used only to define the platform devices,
> and with the exception of the platform_data structure not
> needed by the driver, so we can split out the platform_data
> definition instead and leave the rest to platform code.
>
> Signed-off-by: Arnd Bergmann 
> Cc: linux-...@vger.kernel.org
> Cc: Chris Ball 

Acked-by: Chris Ball 

- Chris.
-- 
Chris Ball  
One Laptop Per Child
--
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/

[char-misc-next 3/3 v7] mei: nfc: Implement MEI bus ops

[Samuel Ortiz]

The send ops for NFC builds the command header, updates the request id
and then waits for an ACK.
The recv ops check if it receives data or an ACK and in the latter case
wakes the send ops up.
The enable ops sends the NFC HECI connect command.

Signed-off-by: Samuel Ortiz 
Signed-off-by: Tomas Winkler 
---
 drivers/misc/mei/nfc.c |  170 +++-
 1 file changed, 169 insertions(+), 1 deletion(-)

diff --git a/drivers/misc/mei/nfc.c b/drivers/misc/mei/nfc.c
index 33354d94..3adf8a7 100644
--- a/drivers/misc/mei/nfc.c
+++ b/drivers/misc/mei/nfc.c
@@ -15,6 +15,7 @@
  */
 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -99,10 +100,14 @@ struct mei_nfc_dev {
struct mei_cl *cl;
struct mei_cl *cl_info;
struct work_struct init_work;
+   wait_queue_head_t send_wq;
u8 fw_ivn;
u8 vendor_id;
u8 radio_type;
char *bus_name;
+
+   u16 req_id;
+   u16 recv_req_id;
 };
 
 static struct mei_nfc_dev nfc_dev;
@@ -184,6 +189,73 @@ static int mei_nfc_build_bus_name(struct mei_nfc_dev *ndev)
return 0;
 }
 
+static int mei_nfc_connect(struct mei_nfc_dev *ndev)
+{
+   struct mei_device *dev;
+   struct mei_cl *cl;
+   struct mei_nfc_cmd *cmd, *reply;
+   struct mei_nfc_connect *connect;
+   struct mei_nfc_connect_resp *connect_resp;
+   size_t connect_length, connect_resp_length;
+   int bytes_recv, ret;
+
+   cl = ndev->cl;
+   dev = cl->dev;
+
+   connect_length = sizeof(struct mei_nfc_cmd) +
+   sizeof(struct mei_nfc_connect);
+
+   connect_resp_length = sizeof(struct mei_nfc_cmd) +
+   sizeof(struct mei_nfc_connect_resp);
+
+   cmd = kzalloc(connect_length, GFP_KERNEL);
+   if (!cmd)
+   return -ENOMEM;
+   connect = (struct mei_nfc_connect *)cmd->data;
+
+   reply = kzalloc(connect_resp_length, GFP_KERNEL);
+   if (!reply) {
+   kfree(cmd);
+   return -ENOMEM;
+   }
+
+   connect_resp = (struct mei_nfc_connect_resp *)reply->data;
+
+   cmd->command = MEI_NFC_CMD_MAINTENANCE;
+   cmd->data_size = 3;
+   cmd->sub_command = MEI_NFC_SUBCMD_CONNECT;
+   connect->fw_ivn = ndev->fw_ivn;
+   connect->vendor_id = ndev->vendor_id;
+
+   ret = __mei_cl_send(cl, (u8 *)cmd, connect_length);
+   if (ret < 0) {
+   dev_err(>pdev->dev, "Could not send connect cmd\n");
+   goto err;
+   }
+
+   bytes_recv = __mei_cl_recv(cl, (u8 *)reply, connect_resp_length);
+   if (bytes_recv < 0) {
+   dev_err(>pdev->dev, "Could not read connect response\n");
+   ret = bytes_recv;
+   goto err;
+   }
+
+   dev_info(>pdev->dev, "IVN 0x%x Vendor ID 0x%x\n",
+connect_resp->fw_ivn, connect_resp->vendor_id);
+
+   dev_info(>pdev->dev, "ME FW %d.%d.%d.%d\n",
+   connect_resp->me_major, connect_resp->me_minor,
+   connect_resp->me_hotfix, connect_resp->me_build);
+
+   ret = 0;
+
+err:
+   kfree(reply);
+   kfree(cmd);
+
+   return ret;
+}
+
 static int mei_nfc_if_version(struct mei_nfc_dev *ndev)
 {
struct mei_device *dev;
@@ -235,6 +307,100 @@ err:
return ret;
 }
 
+static int mei_nfc_enable(struct mei_cl_device *cldev)
+{
+   struct mei_device *dev;
+   struct mei_nfc_dev *ndev = _dev;
+   int ret;
+
+   dev = ndev->cl->dev;
+
+   ret = mei_nfc_connect(ndev);
+   if (ret < 0) {
+   dev_err(>pdev->dev, "Could not connect to NFC");
+   return ret;
+   }
+
+   return 0;
+}
+
+static int mei_nfc_disable(struct mei_cl_device *cldev)
+{
+   return 0;
+}
+
+static int mei_nfc_send(struct mei_cl_device *cldev, u8 *buf, size_t length)
+{
+   struct mei_device *dev;
+   struct mei_nfc_dev *ndev;
+   struct mei_nfc_hci_hdr *hdr;
+   u8 *mei_buf;
+   int err;
+
+   ndev = (struct mei_nfc_dev *) cldev->priv_data;
+   dev = ndev->cl->dev;
+
+   mei_buf = kzalloc(length + MEI_NFC_HEADER_SIZE, GFP_KERNEL);
+   if (!mei_buf)
+   return -ENOMEM;
+
+   hdr = (struct mei_nfc_hci_hdr *) mei_buf;
+   hdr->cmd = MEI_NFC_CMD_HCI_SEND;
+   hdr->status = 0;
+   hdr->req_id = ndev->req_id;
+   hdr->reserved = 0;
+   hdr->data_size = length;
+
+   memcpy(mei_buf + MEI_NFC_HEADER_SIZE, buf, length);
+
+   err = __mei_cl_send(ndev->cl, mei_buf, length + MEI_NFC_HEADER_SIZE);
+   if (err < 0)
+   return err;
+
+   kfree(mei_buf);
+
+   if (!wait_event_interruptible_timeout(ndev->send_wq,
+   ndev->recv_req_id == ndev->req_id, HZ)) {
+   dev_err(>pdev->dev, "NFC MEI command timeout\n");
+   err = -ETIMEDOUT;
+   } else {
+   ndev->req_id++;
+   }
+
+   return err;
+}
+
+static int mei_nfc_recv(struct 

Re: [PATCH] kernel: audit: beautify code, for extern function, better to check its parameters by itself

[Chen Gang]

On 2013年04月11日 01:31, Eric Paris wrote:
> - Original Message -
>> > 
>> >   __audit_socketcall is an extern function.
>> >   better to check its parameters by itself.
>> > 
>> > also can return error code, when fail (find invalid parameters).
>> > also use macro instead of real hard code number
>> > also give related comments for it.
>> > 
>> > Signed-off-by: Chen Gang 
>> > ---
>> >  include/linux/audit.h |   12 
>> >  kernel/auditsc.c  |9 ++---
>> >  net/socket.c  |6 --
>> >  3 files changed, 18 insertions(+), 9 deletions(-)
>> > 
>> > diff --git a/include/linux/audit.h b/include/linux/audit.h
>> > @@ -354,7 +358,7 @@ static inline int audit_bprm(struct linux_binprm *bprm)
>> >  {
>> >return 0;
>> >  }
>> > -static inline void audit_socketcall(int nargs, unsigned long *args)
>> > +static inline int audit_socketcall(int nargs, unsigned long *args)
>> >  { }
>> >  static inline void audit_fd_pair(int fd1, int fd2)
>> >  { }
> This now returns a value but you forgot to return a value.  Thus this would 
> not even build...   I fixed it up myself.

  thank you very much.


  :-)


-- 
Chen Gang

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

[char-misc-next 2/3 v7] mei: nfc: Add NFC device to the MEI bus

[Samuel Ortiz]

After building its bus name as a string based on its vendor id and radio
type, we can add it to the bus.

Signed-off-by: Samuel Ortiz 
Signed-off-by: Tomas Winkler 
---
 drivers/misc/mei/nfc.c |   75 
 1 file changed, 75 insertions(+)

diff --git a/drivers/misc/mei/nfc.c b/drivers/misc/mei/nfc.c
index 37d4b09..33354d94 100644
--- a/drivers/misc/mei/nfc.c
+++ b/drivers/misc/mei/nfc.c
@@ -102,6 +102,7 @@ struct mei_nfc_dev {
u8 fw_ivn;
u8 vendor_id;
u8 radio_type;
+   char *bus_name;
 };
 
 static struct mei_nfc_dev nfc_dev;
@@ -115,6 +116,14 @@ static const uuid_le mei_nfc_info_guid = 
UUID_LE(0xd2de1625, 0x382d, 0x417d,
0x48, 0xa4, 0xef, 0xab,
0xba, 0x8a, 0x12, 0x06);
 
+/* Vendors */
+#define MEI_NFC_VENDOR_INSIDE 0x00
+#define MEI_NFC_VENDOR_NXP0x01
+
+/* Radio types */
+#define MEI_NFC_VENDOR_INSIDE_UREAD 0x00
+#define MEI_NFC_VENDOR_NXP_PN5440x01
+
 static void mei_nfc_free(struct mei_nfc_dev *ndev)
 {
if (ndev->cl) {
@@ -130,6 +139,51 @@ static void mei_nfc_free(struct mei_nfc_dev *ndev)
}
 }
 
+static int mei_nfc_build_bus_name(struct mei_nfc_dev *ndev)
+{
+   struct mei_device *dev;
+
+   if (!ndev->cl)
+   return -ENODEV;
+
+   dev = ndev->cl->dev;
+
+   switch (ndev->vendor_id) {
+   case MEI_NFC_VENDOR_INSIDE:
+   switch (ndev->radio_type) {
+   case MEI_NFC_VENDOR_INSIDE_UREAD:
+   ndev->bus_name = "microread";
+   return 0;
+
+   default:
+   dev_err(>pdev->dev, "Unknow radio type 0x%x\n",
+   ndev->radio_type);
+
+   return -EINVAL;
+   }
+
+   case MEI_NFC_VENDOR_NXP:
+   switch (ndev->radio_type) {
+   case MEI_NFC_VENDOR_NXP_PN544:
+   ndev->bus_name = "pn544";
+   return 0;
+   default:
+   dev_err(>pdev->dev, "Unknow radio type 0x%x\n",
+   ndev->radio_type);
+
+   return -EINVAL;
+   }
+
+   default:
+   dev_err(>pdev->dev, "Unknow vendor ID 0x%x\n",
+   ndev->vendor_id);
+
+   return -EINVAL;
+   }
+
+   return 0;
+}
+
 static int mei_nfc_if_version(struct mei_nfc_dev *ndev)
 {
struct mei_device *dev;
@@ -184,6 +238,7 @@ err:
 static void mei_nfc_init(struct work_struct *work)
 {
struct mei_device *dev;
+   struct mei_cl_device *cldev;
struct mei_nfc_dev *ndev;
struct mei_cl *cl_info;
 
@@ -226,6 +281,23 @@ static void mei_nfc_init(struct work_struct *work)
 
mutex_unlock(>device_lock);
 
+   if (mei_nfc_build_bus_name(ndev) < 0) {
+   dev_err(>pdev->dev,
+   "Could not build the bus ID name\n");
+   return;
+   }
+
+   cldev = mei_cl_add_device(dev, mei_nfc_guid, ndev->bus_name, NULL);
+   if (!cldev) {
+   dev_err(>pdev->dev,
+   "Could not add the NFC device to the MEI bus\n");
+
+   goto err;
+   }
+
+   cldev->priv_data = ndev;
+
+
return;
 
 err:
@@ -307,5 +379,8 @@ void mei_nfc_host_exit(void)
 {
struct mei_nfc_dev *ndev = _dev;
 
+   if (ndev->cl && ndev->cl->device)
+   mei_cl_remove_device(ndev->cl->device);
+
mei_nfc_free(ndev);
 }
-- 
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/

[char-misc-next 0/3 v7] Support NFC device on MEI CL bus

[Samuel Ortiz]

v6 -> v7:
   * Removed include/uapi/linux/mei/nfc.h.
 All MEI NFC definitions are now folded into drivers/misc/mei/nfc.c

Samuel Ortiz (3):
  mei: nfc: Initial nfc implementation
  mei: nfc: Add NFC device to the MEI bus
  mei: nfc: Implement MEI bus ops

 drivers/misc/mei/Makefile  |1 +
 drivers/misc/mei/client.c  |3 +
 drivers/misc/mei/init.c|2 +
 drivers/misc/mei/mei_dev.h |   10 +
 drivers/misc/mei/nfc.c |  554 
 5 files changed, 570 insertions(+)
 create mode 100644 drivers/misc/mei/nfc.c

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

[char-misc-next 1/3 v7] mei: nfc: Initial nfc implementation

[Samuel Ortiz]

NFC ME device is exported through the MEI bus to be consumed by the
NFC subsystem.

NFC is represented by two mei clients: An info one and the actual
NFC one. In order to properly build the ME id we first need to retrieve
the firmware information from the info client and then disconnect from it.

Signed-off-by: Samuel Ortiz 
Signed-off-by: Tomas Winkler 
---
 drivers/misc/mei/Makefile  |1 +
 drivers/misc/mei/client.c  |3 +
 drivers/misc/mei/init.c|2 +
 drivers/misc/mei/mei_dev.h |   10 ++
 drivers/misc/mei/nfc.c |  311 
 5 files changed, 327 insertions(+)
 create mode 100644 drivers/misc/mei/nfc.c

diff --git a/drivers/misc/mei/Makefile b/drivers/misc/mei/Makefile
index 3612d57..08698a4 100644
--- a/drivers/misc/mei/Makefile
+++ b/drivers/misc/mei/Makefile
@@ -11,6 +11,7 @@ mei-objs += main.o
 mei-objs += amthif.o
 mei-objs += wd.o
 mei-objs += bus.o
+mei-objs += nfc.o
 mei-$(CONFIG_DEBUG_FS) += debugfs.o
 
 obj-$(CONFIG_INTEL_MEI_ME) += mei-me.o
diff --git a/drivers/misc/mei/client.c b/drivers/misc/mei/client.c
index ecadd00..9541aa9 100644
--- a/drivers/misc/mei/client.c
+++ b/drivers/misc/mei/client.c
@@ -358,6 +358,9 @@ void mei_host_client_init(struct work_struct *work)
mei_amthif_host_init(dev);
else if (!uuid_le_cmp(client_props->protocol_name, mei_wd_guid))
mei_wd_host_init(dev);
+   else if (!uuid_le_cmp(client_props->protocol_name, 
mei_nfc_guid))
+   mei_nfc_host_init(dev);
+
}
 
dev->dev_state = MEI_DEV_ENABLED;
diff --git a/drivers/misc/mei/init.c b/drivers/misc/mei/init.c
index 54b51c0..4e102ad 100644
--- a/drivers/misc/mei/init.c
+++ b/drivers/misc/mei/init.c
@@ -219,6 +219,8 @@ void mei_stop(struct mei_device *dev)
 
mei_wd_stop(dev);
 
+   mei_nfc_host_exit();
+
dev->dev_state = MEI_DEV_POWER_DOWN;
mei_reset(dev, 0);
 
diff --git a/drivers/misc/mei/mei_dev.h b/drivers/misc/mei/mei_dev.h
index c02967d..cd5b6d4 100644
--- a/drivers/misc/mei/mei_dev.h
+++ b/drivers/misc/mei/mei_dev.h
@@ -509,6 +509,16 @@ struct mei_cl_cb *mei_amthif_find_read_list_entry(struct 
mei_device *dev,
 
 void mei_amthif_run_next_cmd(struct mei_device *dev);
 
+/*
+ * NFC functions
+ */
+int mei_nfc_host_init(struct mei_device *dev);
+void mei_nfc_host_exit(void);
+
+/*
+ * NFC Client UUID
+ */
+extern const uuid_le mei_nfc_guid;
 
 int mei_amthif_irq_write_complete(struct mei_device *dev, s32 *slots,
struct mei_cl_cb *cb, struct mei_cl_cb *cmpl_list);
diff --git a/drivers/misc/mei/nfc.c b/drivers/misc/mei/nfc.c
new file mode 100644
index 000..37d4b09
--- /dev/null
+++ b/drivers/misc/mei/nfc.c
@@ -0,0 +1,311 @@
+/*
+ *
+ * Intel Management Engine Interface (Intel MEI) Linux driver
+ * Copyright (c) 2003-2013, Intel Corporation.
+ *
+ * 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.
+ *
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include "mei_dev.h"
+#include "client.h"
+
+struct mei_nfc_cmd {
+   u8 command;
+   u8 status;
+   u16 req_id;
+   u32 reserved;
+   u16 data_size;
+   u8 sub_command;
+   u8 data[];
+} __packed;
+
+struct mei_nfc_reply {
+   u8 command;
+   u8 status;
+   u16 req_id;
+   u32 reserved;
+   u16 data_size;
+   u8 sub_command;
+   u8 reply_status;
+   u8 data[];
+} __packed;
+
+struct mei_nfc_if_version {
+   u8 radio_version_sw[3];
+   u8 reserved[3];
+   u8 radio_version_hw[3];
+   u8 i2c_addr;
+   u8 fw_ivn;
+   u8 vendor_id;
+   u8 radio_type;
+} __packed;
+
+struct mei_nfc_connect {
+   u8 fw_ivn;
+   u8 vendor_id;
+} __packed;
+
+struct mei_nfc_connect_resp {
+   u8 fw_ivn;
+   u8 vendor_id;
+   u16 me_major;
+   u16 me_minor;
+   u16 me_hotfix;
+   u16 me_build;
+} __packed;
+
+struct mei_nfc_hci_hdr {
+   u8 cmd;
+   u8 status;
+   u16 req_id;
+   u32 reserved;
+   u16 data_size;
+} __packed;
+
+#define MEI_NFC_CMD_MAINTENANCE 0x00
+#define MEI_NFC_CMD_HCI_SEND 0x01
+#define MEI_NFC_CMD_HCI_RECV 0x02
+
+#define MEI_NFC_SUBCMD_CONNECT0x00
+#define MEI_NFC_SUBCMD_IF_VERSION 0x01
+
+#define MEI_NFC_HEADER_SIZE 10
+
+/** mei_nfc_dev - NFC mei device
+ *
+ * @cl: NFC host client
+ * @cl_info: NFC info host client
+ * @init_work: perform connection to the info client
+ * @fw_ivn: NFC Intervace Version Number
+ * @vendor_id: NFC manufacturer ID
+ * @radio_type: NFC radio type
+ */
+struct 

[PATCH] ARM: msm: Fix uncompess.h tx underrun check

[Stephen Boyd]

Bit 3 of the SR register is set if there is a tx underrun. If
this bit isn't set, we should loop on the tx ready bit until we
can transmit again. Otherwise we should skip the loop and
transmit immediately. The code is doing the opposite though,
checking for an underrun and then looping on the tx ready bit
causing us to never loop on the tx read bit when the tx buffer
may not be ready.

This doesn't seem to affect my 8960 device too often, but in some
cases I see a lost character or two from the decompressor prints.
This also matches what we do in the assembly in debug-macro.S.

Signed-off-by: Stephen Boyd 
---

Nobody has noticed this so far so I'm ok waiting for 3.10 on this one. Also
it doesn't improve stability (debug feature) so I don't see a reason to send
it to stable.

 arch/arm/mach-msm/include/mach/uncompress.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/arm/mach-msm/include/mach/uncompress.h 
b/arch/arm/mach-msm/include/mach/uncompress.h
index fa97a10..9432487 100644
--- a/arch/arm/mach-msm/include/mach/uncompress.h
+++ b/arch/arm/mach-msm/include/mach/uncompress.h
@@ -37,7 +37,7 @@ static void putc(int c)
 * Wait for TX_READY to be set; but skip it if we have a
 * TX underrun.
 */
-   if (UART_DM_SR & 0x08)
+   if (!(UART_DM_SR & 0x08))
while (!(UART_DM_ISR & 0x80))
cpu_relax();
 
-- 
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
hosted by The Linux Foundation

--
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.8-stable] net: count hw_addr syncs so that unsync works properly.

[David Miller]

From: Jonghwan Choi 
Date: Thu, 11 Apr 2013 09:31:44 +0900

> This patch looks like it should be in the 3.8-stable tree, should we apply
> it?

I queue up networking patches as needed and that queue is
visible at:

http://patchwork.ozlabs.org/user/bundle/2566/?state=*

and yes this patch, along with many others, are there.

I submit networking patches to -stable at a time of my
own choosing, in an effort to allow bug fixes to cook
in Linus's tree for some time just in case the fixes
themselves have bugs.
--
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/5] clean up checks against "high_memory" variable

[Borislav Petkov]

On Wed, Apr 10, 2013 at 04:32:50PM -0700, Dave Hansen wrote:
> 
> We have a new debugging check on x86 that has caught a number
> of long-standing bugs.  However, there is a _bit_ of collateral
> damage with things that call __pa(high_memory).
> 
> We are now checking that any addresses passed to __pa() are
> *valid* and can be dereferenced.
> 
> "high_memory", however, is not valid.  It marks the start of
> highmem, and isn't itself a valid pointer.  But, those users
> are really just asking "is this vaddr mapped"?  So, give them
> a helper that does that, plus is also kind to our new
> debugging check.
> 
> Signed-off-by: Dave Hansen 
> Signed-off-by: Dave Hansen 

FWIW,

this one already fixes the BUG below I'm seeing when booting 32-bit
Atom guests in qemu.

Tested-by: Borislav Petkov 

More testing tomorrow.

[   57.035880] [ cut here ]
[   57.036190] kernel BUG at arch/x86/mm/physaddr.c:79!
[   57.036190] invalid opcode:  [#1] PREEMPT SMP 
[   57.036190] Modules linked in:
[   57.036190] Pid: 2555, comm: wdm Tainted: G S  W3.9.0-rc6+ #5 Bochs 
Bochs
[   57.036190] EIP: 0060:[] EFLAGS: 00010206 CPU: 56
[   57.036190] EIP is at __phys_addr+0x71/0x80
[   57.036190] EAX:  EBX: 373fe000 ECX: 000c EDX: 
[   57.036190] ESI:  EDI: 2000 EBP: ec509f40 ESP: ec509f3c
[   57.036190]  DS: 007b ES: 007b FS: 00d8 GS: 0033 SS: 0068
[   57.036190] CR0: 8005003b CR2: b7620b48 CR3: 2f5b5000 CR4: 06d0
[   57.036190] DR0:  DR1:  DR2:  DR3: 
[   57.036190] DR6: 0ff0 DR7: 0400
[   57.036190] Process wdm (pid: 2555, ti=ec508000 task=ec50 
task.ti=ec508000)
[   57.036190] Stack:
[   57.036190]  2000 ec509f64 c1304268 ec57 ec50e300 bf87299c 2000 
ec50e300
[   57.036190]  c1304240 2000 ec509f8c c1120276 ec509f98  ed540314 
c1304240
[   57.036190]  ec57 ec50e300  08065294 ec509fac c1120488 ec509f98 

[   57.036190] Call Trace:
[   57.036190]  [] read_mem+0x28/0xf0
[   57.036190]  [] ? write_mem+0xf0/0xf0
[   57.036190]  [] vfs_read+0x86/0x140
[   57.036190]  [] ? write_mem+0xf0/0xf0
[   57.036190]  [] sys_read+0x48/0x90
[   57.036190]  [] sysenter_do_call+0x12/0x36
[   57.036190] Code: 39 0b c2 81 c2 00 00 80 00 39 d0 72 cc 8b 15 2c 4c 74 c1 
81 ea 00 a0 a4 00 81 e2 00 00 c0 ff 81 ea 00 20 00 00 39 d0 73 b0 0f 0b <0f> 0b 
0f 0b 8d 74 26 00 8d bc 27 00 00 00 00 55 89 e5 53 3e 8d
[   57.036190] EIP: [] __phys_addr+0x71/0x80 SS:ESP 0068:ec509f3c
[   57.619214] ---[ end trace 4e05f3724c460358 ]---

-- 
Regards/Gruss,
Boris.

Sent from a fat crate under my desk. Formatting is fine.
--
--
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.8-stable] net: count hw_addr syncs so that unsync works properly.

[Jonghwan Choi]

This patch looks like it should be in the 3.8-stable tree, should we apply
it?

--

From: "Vlad Yasevich "

commit 4543fbefe6e06a9e40d9f2b28d688393a299f079 upstream

A few drivers use dev_uc_sync/unsync to synchronize the
address lists from master down to slave/lower devices.  In
some cases (bond/team) a single address list is synched down
to multiple devices.  At the time of unsync, we have a leak
in these lower devices, because "synced" is treated as a
boolean and the address will not be unsynced for anything after
the first device/call.

Treat "synced" as a count (same as refcount) and allow all
unsync calls to work.

Signed-off-by: Vlad Yasevich 
Signed-off-by: David S. Miller 
Signed-off-by: Jonghwan Choi 
---
 include/linux/netdevice.h |2 +-
 net/core/dev_addr_lists.c |6 +++---
 2 files changed, 4 insertions(+), 4 deletions(-)

diff --git a/include/linux/netdevice.h b/include/linux/netdevice.h
index 9ef07d0..0e182f9 100644
--- a/include/linux/netdevice.h
+++ b/include/linux/netdevice.h
@@ -208,9 +208,9 @@ struct netdev_hw_addr {
 #define NETDEV_HW_ADDR_T_SLAVE 3
 #define NETDEV_HW_ADDR_T_UNICAST   4
 #define NETDEV_HW_ADDR_T_MULTICAST 5
-   boolsynced;
boolglobal_use;
int refcount;
+   int synced;
struct rcu_head rcu_head;
 };
 
diff --git a/net/core/dev_addr_lists.c b/net/core/dev_addr_lists.c
index b079c7b..7841d87 100644
--- a/net/core/dev_addr_lists.c
+++ b/net/core/dev_addr_lists.c
@@ -38,7 +38,7 @@ static int __hw_addr_create_ex(struct netdev_hw_addr_list
*list,
ha->type = addr_type;
ha->refcount = 1;
ha->global_use = global;
-   ha->synced = false;
+   ha->synced = 0;
list_add_tail_rcu(>list, >list);
list->count++;
 
@@ -166,7 +166,7 @@ int __hw_addr_sync(struct netdev_hw_addr_list *to_list,
addr_len, ha->type);
if (err)
break;
-   ha->synced = true;
+   ha->synced++;
ha->refcount++;
} else if (ha->refcount == 1) {
__hw_addr_del(to_list, ha->addr, addr_len,
ha->type);
@@ -187,7 +187,7 @@ void __hw_addr_unsync(struct netdev_hw_addr_list
*to_list,
if (ha->synced) {
__hw_addr_del(to_list, ha->addr,
  addr_len, ha->type);
-   ha->synced = false;
+   ha->synced--;
__hw_addr_del(from_list, ha->addr,
  addr_len, ha->type);
}
-- 
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/

[tip:x86/urgent] x86, mm: Patch out arch_flush_lazy_mmu_mode() when running on bare metal

[tip-bot for Boris Ostrovsky]

Commit-ID:  511ba86e1d386f671084b5d0e6f110bb30b8eeb2
Gitweb: http://git.kernel.org/tip/511ba86e1d386f671084b5d0e6f110bb30b8eeb2
Author: Boris Ostrovsky 
AuthorDate: Sat, 23 Mar 2013 09:36:36 -0400
Committer:  H. Peter Anvin 
CommitDate: Wed, 10 Apr 2013 11:25:10 -0700

x86, mm: Patch out arch_flush_lazy_mmu_mode() when running on bare metal

Invoking arch_flush_lazy_mmu_mode() results in calls to
preempt_enable()/disable() which may have performance impact.

Since lazy MMU is not used on bare metal we can patch away
arch_flush_lazy_mmu_mode() so that it is never called in such
environment.

[ hpa: the previous patch "Fix vmalloc_fault oops during lazy MMU
  updates" may cause a minor performance regression on
  bare metal.  This patch resolves that performance regression.  It is
  somewhat unclear to me if this is a good -stable candidate. ]

Signed-off-by: Boris Ostrovsky 
Link: 
http://lkml.kernel.org/r/1364045796-10720-2-git-send-email-konrad.w...@oracle.com
Tested-by: Josh Boyer 
Tested-by: Konrad Rzeszutek Wilk 
Acked-by: Borislav Petkov 
Signed-off-by: Konrad Rzeszutek Wilk 
Signed-off-by: H. Peter Anvin 
Cc:  SEE NOTE ABOVE
---
 arch/x86/include/asm/paravirt.h   |  5 -
 arch/x86/include/asm/paravirt_types.h |  2 ++
 arch/x86/kernel/paravirt.c| 25 +
 arch/x86/lguest/boot.c|  1 +
 arch/x86/xen/mmu.c|  1 +
 5 files changed, 21 insertions(+), 13 deletions(-)

diff --git a/arch/x86/include/asm/paravirt.h b/arch/x86/include/asm/paravirt.h
index 5edd174..7361e47 100644
--- a/arch/x86/include/asm/paravirt.h
+++ b/arch/x86/include/asm/paravirt.h
@@ -703,7 +703,10 @@ static inline void arch_leave_lazy_mmu_mode(void)
PVOP_VCALL0(pv_mmu_ops.lazy_mode.leave);
 }
 
-void arch_flush_lazy_mmu_mode(void);
+static inline void arch_flush_lazy_mmu_mode(void)
+{
+   PVOP_VCALL0(pv_mmu_ops.lazy_mode.flush);
+}
 
 static inline void __set_fixmap(unsigned /* enum fixed_addresses */ idx,
phys_addr_t phys, pgprot_t flags)
diff --git a/arch/x86/include/asm/paravirt_types.h 
b/arch/x86/include/asm/paravirt_types.h
index 142236e..b3b0ec1 100644
--- a/arch/x86/include/asm/paravirt_types.h
+++ b/arch/x86/include/asm/paravirt_types.h
@@ -91,6 +91,7 @@ struct pv_lazy_ops {
/* Set deferred update mode, used for batching operations. */
void (*enter)(void);
void (*leave)(void);
+   void (*flush)(void);
 };
 
 struct pv_time_ops {
@@ -679,6 +680,7 @@ void paravirt_end_context_switch(struct task_struct *next);
 
 void paravirt_enter_lazy_mmu(void);
 void paravirt_leave_lazy_mmu(void);
+void paravirt_flush_lazy_mmu(void);
 
 void _paravirt_nop(void);
 u32 _paravirt_ident_32(u32);
diff --git a/arch/x86/kernel/paravirt.c b/arch/x86/kernel/paravirt.c
index 17fff18..8bfb335 100644
--- a/arch/x86/kernel/paravirt.c
+++ b/arch/x86/kernel/paravirt.c
@@ -263,6 +263,18 @@ void paravirt_leave_lazy_mmu(void)
leave_lazy(PARAVIRT_LAZY_MMU);
 }
 
+void paravirt_flush_lazy_mmu(void)
+{
+   preempt_disable();
+
+   if (paravirt_get_lazy_mode() == PARAVIRT_LAZY_MMU) {
+   arch_leave_lazy_mmu_mode();
+   arch_enter_lazy_mmu_mode();
+   }
+
+   preempt_enable();
+}
+
 void paravirt_start_context_switch(struct task_struct *prev)
 {
BUG_ON(preemptible());
@@ -292,18 +304,6 @@ enum paravirt_lazy_mode paravirt_get_lazy_mode(void)
return this_cpu_read(paravirt_lazy_mode);
 }
 
-void arch_flush_lazy_mmu_mode(void)
-{
-   preempt_disable();
-
-   if (paravirt_get_lazy_mode() == PARAVIRT_LAZY_MMU) {
-   arch_leave_lazy_mmu_mode();
-   arch_enter_lazy_mmu_mode();
-   }
-
-   preempt_enable();
-}
-
 struct pv_info pv_info = {
.name = "bare hardware",
.paravirt_enabled = 0,
@@ -475,6 +475,7 @@ struct pv_mmu_ops pv_mmu_ops = {
.lazy_mode = {
.enter = paravirt_nop,
.leave = paravirt_nop,
+   .flush = paravirt_nop,
},
 
.set_fixmap = native_set_fixmap,
diff --git a/arch/x86/lguest/boot.c b/arch/x86/lguest/boot.c
index 1cbd89c..7114c63 100644
--- a/arch/x86/lguest/boot.c
+++ b/arch/x86/lguest/boot.c
@@ -1334,6 +1334,7 @@ __init void lguest_init(void)
pv_mmu_ops.read_cr3 = lguest_read_cr3;
pv_mmu_ops.lazy_mode.enter = paravirt_enter_lazy_mmu;
pv_mmu_ops.lazy_mode.leave = lguest_leave_lazy_mmu_mode;
+   pv_mmu_ops.lazy_mode.flush = paravirt_flush_lazy_mmu;
pv_mmu_ops.pte_update = lguest_pte_update;
pv_mmu_ops.pte_update_defer = lguest_pte_update;
 
diff --git a/arch/x86/xen/mmu.c b/arch/x86/xen/mmu.c
index 6afbb2c..2f5d687 100644
--- a/arch/x86/xen/mmu.c
+++ b/arch/x86/xen/mmu.c
@@ -2196,6 +2196,7 @@ static const struct pv_mmu_ops xen_mmu_ops __initconst = {
.lazy_mode = {
.enter = paravirt_enter_lazy_mmu,
.leave = xen_leave_lazy_mmu,
+  

[tip:x86/urgent] x86, mm, paravirt: Fix vmalloc_fault oops during lazy MMU updates

[tip-bot for Samu Kallio]

Commit-ID:  1160c2779b826c6f5c08e5cc542de58fd1f667d5
Gitweb: http://git.kernel.org/tip/1160c2779b826c6f5c08e5cc542de58fd1f667d5
Author: Samu Kallio 
AuthorDate: Sat, 23 Mar 2013 09:36:35 -0400
Committer:  H. Peter Anvin 
CommitDate: Wed, 10 Apr 2013 11:25:07 -0700

x86, mm, paravirt: Fix vmalloc_fault oops during lazy MMU updates

In paravirtualized x86_64 kernels, vmalloc_fault may cause an oops
when lazy MMU updates are enabled, because set_pgd effects are being
deferred.

One instance of this problem is during process mm cleanup with memory
cgroups enabled. The chain of events is as follows:

- zap_pte_range enables lazy MMU updates
- zap_pte_range eventually calls mem_cgroup_charge_statistics,
  which accesses the vmalloc'd mem_cgroup per-cpu stat area
- vmalloc_fault is triggered which tries to sync the corresponding
  PGD entry with set_pgd, but the update is deferred
- vmalloc_fault oopses due to a mismatch in the PUD entries

The OOPs usually looks as so:

[ cut here ]
kernel BUG at arch/x86/mm/fault.c:396!
invalid opcode:  [#1] SMP
.. snip ..
CPU 1
Pid: 10866, comm: httpd Not tainted 3.6.10-4.fc18.x86_64 #1
RIP: e030:[]  [] vmalloc_fault+0x11f/0x208
.. snip ..
Call Trace:
 [] do_page_fault+0x399/0x4b0
 [] ? xen_mc_extend_args+0xec/0x110
 [] page_fault+0x25/0x30
 [] ? mem_cgroup_charge_statistics.isra.13+0x13/0x50
 [] __mem_cgroup_uncharge_common+0xd8/0x350
 [] mem_cgroup_uncharge_page+0x57/0x60
 [] page_remove_rmap+0xe0/0x150
 [] ? vm_normal_page+0x1a/0x80
 [] unmap_single_vma+0x531/0x870
 [] unmap_vmas+0x52/0xa0
 [] ? pte_mfn_to_pfn+0x72/0x100
 [] exit_mmap+0x98/0x170
 [] ? __raw_callee_save_xen_pmd_val+0x11/0x1e
 [] mmput+0x83/0xf0
 [] exit_mm+0x104/0x130
 [] do_exit+0x15a/0x8c0
 [] do_group_exit+0x3f/0xa0
 [] sys_exit_group+0x17/0x20
 [] system_call_fastpath+0x16/0x1b

Calling arch_flush_lazy_mmu_mode immediately after set_pgd makes the
changes visible to the consistency checks.

Cc: 
RedHat-Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=914737
Tested-by: Josh Boyer 
Reported-and-Tested-by: Krishna Raman 
Signed-off-by: Samu Kallio 
Link: 
http://lkml.kernel.org/r/1364045796-10720-1-git-send-email-konrad.w...@oracle.com
Tested-by: Konrad Rzeszutek Wilk 
Signed-off-by: Konrad Rzeszutek Wilk 
Signed-off-by: H. Peter Anvin 
---
 arch/x86/mm/fault.c | 6 --
 1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/arch/x86/mm/fault.c b/arch/x86/mm/fault.c
index 2b97525..0e88336 100644
--- a/arch/x86/mm/fault.c
+++ b/arch/x86/mm/fault.c
@@ -378,10 +378,12 @@ static noinline __kprobes int vmalloc_fault(unsigned long 
address)
if (pgd_none(*pgd_ref))
return -1;
 
-   if (pgd_none(*pgd))
+   if (pgd_none(*pgd)) {
set_pgd(pgd, *pgd_ref);
-   else
+   arch_flush_lazy_mmu_mode();
+   } else {
BUG_ON(pgd_page_vaddr(*pgd) != pgd_page_vaddr(*pgd_ref));
+   }
 
/*
 * Below here mismatches are bugs because these lower tables
--
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 15/30] mtd: onenand/samsung: make regs-onenand.h file local

[Kyungmin Park]

Thanks Arnd.

On Thu, Apr 11, 2013 at 9:04 AM, Arnd Bergmann  wrote:
> Nothing uses the NAND register definitions other than the
> actual driver, so we can move the header file into the
> same local directory, which lets us build it in a multiplatform
> configuration.
>
> Signed-off-by: Arnd Bergmann 
> Cc: linux-...@lists.infradead.org
> Cc: Kyungmin Park 
Acked-by: Kyungmin Park 
> Cc: David Woodhouse 
> ---
>  drivers/mtd/onenand/samsung.c | 4 
> ++--
>  .../include/plat/regs-onenand.h => drivers/mtd/onenand/samsung.h  | 2 --
>  2 files changed, 2 insertions(+), 4 deletions(-)
>  rename arch/arm/plat-samsung/include/plat/regs-onenand.h => 
> drivers/mtd/onenand/samsung.h (98%)
>
> diff --git a/drivers/mtd/onenand/samsung.c b/drivers/mtd/onenand/samsung.c
> index 33f2a8f..2cf7408 100644
> --- a/drivers/mtd/onenand/samsung.c
> +++ b/drivers/mtd/onenand/samsung.c
> @@ -23,11 +23,11 @@
>  #include 
>  #include 
>  #include 
> +#include 
>
>  #include 
> -#include 
>
> -#include 
> +#include "samsung.h"
>
>  enum soc_type {
> TYPE_S3C6400,
> diff --git a/arch/arm/plat-samsung/include/plat/regs-onenand.h 
> b/drivers/mtd/onenand/samsung.h
> similarity index 98%
> rename from arch/arm/plat-samsung/include/plat/regs-onenand.h
> rename to drivers/mtd/onenand/samsung.h
> index 930ea8b..c4a80e6 100644
> --- a/arch/arm/plat-samsung/include/plat/regs-onenand.h
> +++ b/drivers/mtd/onenand/samsung.h
> @@ -11,8 +11,6 @@
>  #ifndef __SAMSUNG_ONENAND_H__
>  #define __SAMSUNG_ONENAND_H__
>
> -#include 
> -
>  /*
>   * OneNAND Controller
>   */
> --
> 1.8.1.2
>
>
> __
> Linux MTD discussion mailing list
> http://lists.infradead.org/mailman/listinfo/linux-mtd/
--
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 02/30] ARM: exynos: prepare for sparse IRQ

[Kyungmin Park]

On Thu, Apr 11, 2013 at 9:04 AM, Arnd Bergmann  wrote:
> When we enable CONFIG_SPARSE_IRQ, we have to set the value of NR_IRQS in
> the machine_desc for legacy IRQ domains, and any file referring to the
> number of interrupts or a specific number must include the mach/irqs.h
> header file explicitly.

It's really wanted feature.
>
> Signed-off-by: Arnd Bergmann 
Acked-by: Kyungmin Park 
> ---
>  arch/arm/mach-exynos/dev-uart.c  | 1 +
>  arch/arm/mach-exynos/include/mach/irqs.h | 5 -
>  arch/arm/mach-exynos/mach-armlex4210.c   | 2 ++
>  arch/arm/mach-exynos/mach-exynos4-dt.c   | 3 +++
>  arch/arm/mach-exynos/mach-exynos5-dt.c   | 2 ++
>  arch/arm/mach-exynos/mach-nuri.c | 2 ++
>  arch/arm/mach-exynos/mach-origen.c   | 2 ++
>  arch/arm/mach-exynos/mach-smdk4x12.c | 2 ++
>  arch/arm/mach-exynos/mach-smdkv310.c | 3 +++
>  arch/arm/plat-samsung/irq-vic-timer.c| 1 +
>  arch/arm/plat-samsung/pm.c   | 1 +
>  arch/arm/plat-samsung/s5p-irq.c  | 1 +
>  12 files changed, 24 insertions(+), 1 deletion(-)
>
> diff --git a/arch/arm/mach-exynos/dev-uart.c b/arch/arm/mach-exynos/dev-uart.c
> index 7c42f4b..c48aff0 100644
> --- a/arch/arm/mach-exynos/dev-uart.c
> +++ b/arch/arm/mach-exynos/dev-uart.c
> @@ -20,6 +20,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>
>  #include 
>
> diff --git a/arch/arm/mach-exynos/include/mach/irqs.h 
> b/arch/arm/mach-exynos/include/mach/irqs.h
> index 35fe6d5..c72f59d 100644
> --- a/arch/arm/mach-exynos/include/mach/irqs.h
> +++ b/arch/arm/mach-exynos/include/mach/irqs.h
> @@ -467,7 +467,10 @@
>  #define IRQ_TIMER_BASE (IRQ_GPIO_END + 64)
>
>  /* Set the default NR_IRQS */
> +#define EXYNOS_NR_IRQS (IRQ_TIMER_BASE + IRQ_TIMER_COUNT)
>
> -#define NR_IRQS(IRQ_TIMER_BASE + 
> IRQ_TIMER_COUNT)
> +#ifndef CONFIG_SPARSE_IRQ
> +#define NR_IRQSEXYNOS_NR_IRQS
> +#endif
>
>  #endif /* __ASM_ARCH_IRQS_H */
> diff --git a/arch/arm/mach-exynos/mach-armlex4210.c 
> b/arch/arm/mach-exynos/mach-armlex4210.c
> index 2c23b65..a503e02 100644
> --- a/arch/arm/mach-exynos/mach-armlex4210.c
> +++ b/arch/arm/mach-exynos/mach-armlex4210.c
> @@ -25,6 +25,7 @@
>  #include 
>  #include 
>
> +#include 
>  #include 
>
>  #include "common.h"
> @@ -196,6 +197,7 @@ static void __init armlex4210_machine_init(void)
>  MACHINE_START(ARMLEX4210, "ARMLEX4210")
> /* Maintainer: Alim Akhtar  */
> .atag_offset= 0x100,
> +   .nr_irqs= EXYNOS_NR_IRQS,
> .smp= smp_ops(exynos_smp_ops),
> .init_irq   = exynos4_init_irq,
> .map_io = armlex4210_map_io,
> diff --git a/arch/arm/mach-exynos/mach-exynos4-dt.c 
> b/arch/arm/mach-exynos/mach-exynos4-dt.c
> index b9ed834..5f23682 100644
> --- a/arch/arm/mach-exynos/mach-exynos4-dt.c
> +++ b/arch/arm/mach-exynos/mach-exynos4-dt.c
> @@ -20,6 +20,8 @@
>
>  #include 
>  #include 
> +#include 
> +
>
>  #include "common.h"
>
> @@ -54,6 +56,7 @@ static void __init exynos4_reserve(void)
>  }
>  DT_MACHINE_START(EXYNOS4210_DT, "Samsung Exynos4 (Flattened Device Tree)")
> /* Maintainer: Thomas Abraham  */
> +   .nr_irqs= EXYNOS_NR_IRQS,
> .smp= smp_ops(exynos_smp_ops),
> .init_irq   = exynos4_init_irq,
> .map_io = exynos4_dt_map_io,
> diff --git a/arch/arm/mach-exynos/mach-exynos5-dt.c 
> b/arch/arm/mach-exynos/mach-exynos5-dt.c
> index 753b94f..8b7456a 100644
> --- a/arch/arm/mach-exynos/mach-exynos5-dt.c
> +++ b/arch/arm/mach-exynos/mach-exynos5-dt.c
> @@ -16,6 +16,7 @@
>  #include 
>
>  #include 
> +#include 
>  #include 
>
>  #include 
> @@ -76,6 +77,7 @@ static void __init exynos5_reserve(void)
>
>  DT_MACHINE_START(EXYNOS5_DT, "SAMSUNG EXYNOS5 (Flattened Device Tree)")
> /* Maintainer: Kukjin Kim  */
> +   .nr_irqs= EXYNOS_NR_IRQS,
> .init_irq   = exynos5_init_irq,
> .smp= smp_ops(exynos_smp_ops),
> .map_io = exynos5_dt_map_io,
> diff --git a/arch/arm/mach-exynos/mach-nuri.c 
> b/arch/arm/mach-exynos/mach-nuri.c
> index 0c10852..fbae331 100644
> --- a/arch/arm/mach-exynos/mach-nuri.c
> +++ b/arch/arm/mach-exynos/mach-nuri.c
> @@ -53,6 +53,7 @@
>  #include 
>  #include 
>
> +#include 
>  #include 
>
>  #include "common.h"
> @@ -1376,6 +1377,7 @@ static void __init nuri_machine_init(void)
>  MACHINE_START(NURI, "NURI")
> /* Maintainer: Kyungmin Park  */
> .atag_offset= 0x100,
> +   .nr_irqs= EXYNOS_NR_IRQS,
> .smp= smp_ops(exynos_smp_ops),
> .init_irq   = exynos4_init_irq,
> .map_io = nuri_map_io,
> diff --git a/arch/arm/mach-exynos/mach-origen.c 
> b/arch/arm/mach-exynos/mach-origen.c
> index f662345..a3ee06a 100644
> --- a/arch/arm/mach-exynos/mach-origen.c
> +++ b/arch/arm/mach-exynos/mach-origen.c
> @@ -46,6 +46,7 @@
>  #include 
>
>  #include 

Re: [PATCH 02/10] mm: vmscan: Obey proportional scanning requirements for kswapd

[Kamezawa Hiroyuki]

(2013/04/10 23:08), Mel Gorman wrote:

On Wed, Apr 10, 2013 at 04:16:47PM +0900, Kamezawa Hiroyuki wrote:

(2013/04/09 20:06), Mel Gorman wrote:

Simplistically, the anon and file LRU lists are scanned proportionally
depending on the value of vm.swappiness although there are other factors
taken into account by get_scan_count().  The patch "mm: vmscan: Limit
the number of pages kswapd reclaims" limits the number of pages kswapd
reclaims but it breaks this proportional scanning and may evenly shrink
anon/file LRUs regardless of vm.swappiness.

This patch preserves the proportional scanning and reclaim. It does mean
that kswapd will reclaim more than requested but the number of pages will
be related to the high watermark.

[mho...@suse.cz: Correct proportional reclaim for memcg and simplify]
Signed-off-by: Mel Gorman 
Acked-by: Rik van Riel 
---
   mm/vmscan.c | 54 ++
   1 file changed, 46 insertions(+), 8 deletions(-)

diff --git a/mm/vmscan.c b/mm/vmscan.c
index 4835a7a..0742c45 100644
--- a/mm/vmscan.c
+++ b/mm/vmscan.c
@@ -1825,13 +1825,21 @@ static void shrink_lruvec(struct lruvec *lruvec, struct 
scan_control *sc)
enum lru_list lru;
unsigned long nr_reclaimed = 0;
unsigned long nr_to_reclaim = sc->nr_to_reclaim;
+   unsigned long nr_anon_scantarget, nr_file_scantarget;
struct blk_plug plug;
+   bool scan_adjusted = false;

get_scan_count(lruvec, sc, nr);

+   /* Record the original scan target for proportional adjustments later */
+   nr_file_scantarget = nr[LRU_INACTIVE_FILE] + nr[LRU_ACTIVE_FILE] + 1;
+   nr_anon_scantarget = nr[LRU_INACTIVE_ANON] + nr[LRU_ACTIVE_ANON] + 1;
+


I'm sorry I couldn't understand the calc...

Assume here
 nr_file_scantarget = 100
 nr_anon_file_target = 100.



I think you might have meant nr_anon_scantarget here instead of
nr_anon_file_target.




blk_start_plug();
while (nr[LRU_INACTIVE_ANON] || nr[LRU_ACTIVE_FILE] ||
nr[LRU_INACTIVE_FILE]) {
+   unsigned long nr_anon, nr_file, percentage;
+
for_each_evictable_lru(lru) {
if (nr[lru]) {
nr_to_scan = min(nr[lru], SWAP_CLUSTER_MAX);
@@ -1841,17 +1849,47 @@ static void shrink_lruvec(struct lruvec *lruvec, struct 
scan_control *sc)
lruvec, sc);
}
}
+
+   if (nr_reclaimed < nr_to_reclaim || scan_adjusted)
+   continue;
+
/*
-* On large memory systems, scan >> priority can become
-* really large. This is fine for the starting priority;
-* we want to put equal scanning pressure on each zone.
-* However, if the VM has a harder time of freeing pages,
-* with multiple processes reclaiming pages, the total
-* freeing target can get unreasonably large.
+* For global direct reclaim, reclaim only the number of pages
+* requested. Less care is taken to scan proportionally as it
+* is more important to minimise direct reclaim stall latency
+* than it is to properly age the LRU lists.
 */
-   if (nr_reclaimed >= nr_to_reclaim &&
-   sc->priority < DEF_PRIORITY)
+   if (global_reclaim(sc) && !current_is_kswapd())
break;
+
+   /*
+* For kswapd and memcg, reclaim at least the number of pages
+* requested. Ensure that the anon and file LRUs shrink
+* proportionally what was requested by get_scan_count(). We
+* stop reclaiming one LRU and reduce the amount scanning
+* proportional to the original scan target.
+*/
+   nr_file = nr[LRU_INACTIVE_FILE] + nr[LRU_ACTIVE_FILE];
+   nr_anon = nr[LRU_INACTIVE_ANON] + nr[LRU_ACTIVE_ANON];
+


Then, nr_file = 80, nr_anon=70.



As we scan evenly in SCAN_CLUSTER_MAX groups of pages, this wouldn't happen
but for the purposes of discussions, lets assume it did.




+   if (nr_file > nr_anon) {
+   lru = LRU_BASE;
+   percentage = nr_anon * 100 / nr_anon_scantarget;
+   } else {
+   lru = LRU_FILE;
+   percentage = nr_file * 100 / nr_file_scantarget;
+   }


the percentage will be 70.



Yes.


+
+   /* Stop scanning the smaller of the LRU */
+   nr[lru] = 0;
+   nr[lru + LRU_ACTIVE] = 0;
+


this will stop anon scan.



Yes.


+   /* Reduce scanning of the other LRU proportionally */
+   lru = (lru == LRU_FILE) ? LRU_BASE : LRU_FILE;
+   nr[lru] = 

Re: [PATCH] vfs: dcache: cond_resched in shrink_dentry_list

[Greg Thelen]

On Wed, Apr 10 2013, Andrew Morton wrote:

> On Tue, 09 Apr 2013 17:37:20 -0700 Greg Thelen  wrote:
>
>> > Call cond_resched() in shrink_dcache_parent() to maintain
>> > interactivity.
>> >
>> > Before this patch:
>> >
>> > void shrink_dcache_parent(struct dentry * parent)
>> > {
>> >while ((found = select_parent(parent, )) != 0)
>> >shrink_dentry_list();
>> > }
>> >
>> > select_parent() populates the dispose list with dentries which
>> > shrink_dentry_list() then deletes.  select_parent() carefully uses
>> > need_resched() to avoid doing too much work at once.  But neither
>> > shrink_dcache_parent() nor its called functions call cond_resched().
>> > So once need_resched() is set select_parent() will return single
>> > dentry dispose list which is then deleted by shrink_dentry_list().
>> > This is inefficient when there are a lot of dentry to process.  This
>> > can cause softlockup and hurts interactivity on non preemptable
>> > kernels.
>> >
>> > This change adds cond_resched() in shrink_dcache_parent().  The
>> > benefit of this is that need_resched() is quickly cleared so that
>> > future calls to select_parent() are able to efficiently return a big
>> > batch of dentry.
>> >
>> > These additional cond_resched() do not seem to impact performance, at
>> > least for the workload below.
>> >
>> > Here is a program which can cause soft lockup on a if other system
>> > activity sets need_resched().
>
> I was unable to guess what word was missing from "on a if other" ;)

Less is more ;)  Reword to:

  Here is a program which can cause soft lockup if other system activity
  sets need_resched().

>> Should this change go through Al's or Andrew's branch?
>
> I'll fight him for it.

Thanks.

> Softlockups are fairly serious, so I'll put a cc:stable in there.  Or
> were the changes which triggered this problem added after 3.9?

This also applies to stable.  I see the problem at least back to v3.3.
I did not test earlier kernels, but could if you want.
--
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 10/30] usb: exynos: do not include plat/usb-phy.h

[Arnd Bergmann]

The definitions have moved to include/linux/usb/samsung-usb-phy.h,
and plat/usb-phy.h is unavailable from drivers in a multiplatform
configuration.

Also fix up the plat/usb-phy.h header file to use the definitions
from the new header instead of providing a separate copy.

Signed-off-by: Arnd Bergmann 
Cc: linux-...@vger.kernel.org
Cc: Greg Kroah-Hartman 
Cc: Alan Stern 
---
 arch/arm/mach-exynos/setup-usb-phy.c | 8 
 arch/arm/mach-s3c64xx/setup-usb-phy.c| 4 ++--
 arch/arm/mach-s5pv210/setup-usb-phy.c| 4 ++--
 arch/arm/plat-samsung/include/plat/usb-phy.h | 5 +
 drivers/usb/host/ehci-s5p.c  | 1 -
 drivers/usb/host/ohci-exynos.c   | 1 -
 6 files changed, 9 insertions(+), 14 deletions(-)

diff --git a/arch/arm/mach-exynos/setup-usb-phy.c 
b/arch/arm/mach-exynos/setup-usb-phy.c
index b81cc56..6af4066 100644
--- a/arch/arm/mach-exynos/setup-usb-phy.c
+++ b/arch/arm/mach-exynos/setup-usb-phy.c
@@ -204,9 +204,9 @@ static int exynos4210_usb_phy1_exit(struct platform_device 
*pdev)
 
 int s5p_usb_phy_init(struct platform_device *pdev, int type)
 {
-   if (type == S5P_USB_PHY_DEVICE)
+   if (type == USB_PHY_TYPE_DEVICE)
return exynos4210_usb_phy0_init(pdev);
-   else if (type == S5P_USB_PHY_HOST)
+   else if (type == USB_PHY_TYPE_HOST)
return exynos4210_usb_phy1_init(pdev);
 
return -EINVAL;
@@ -214,9 +214,9 @@ int s5p_usb_phy_init(struct platform_device *pdev, int type)
 
 int s5p_usb_phy_exit(struct platform_device *pdev, int type)
 {
-   if (type == S5P_USB_PHY_DEVICE)
+   if (type == USB_PHY_TYPE_DEVICE)
return exynos4210_usb_phy0_exit(pdev);
-   else if (type == S5P_USB_PHY_HOST)
+   else if (type == USB_PHY_TYPE_HOST)
return exynos4210_usb_phy1_exit(pdev);
 
return -EINVAL;
diff --git a/arch/arm/mach-s3c64xx/setup-usb-phy.c 
b/arch/arm/mach-s3c64xx/setup-usb-phy.c
index c8174d9..ca960bd 100644
--- a/arch/arm/mach-s3c64xx/setup-usb-phy.c
+++ b/arch/arm/mach-s3c64xx/setup-usb-phy.c
@@ -76,7 +76,7 @@ static int s3c_usb_otgphy_exit(struct platform_device *pdev)
 
 int s5p_usb_phy_init(struct platform_device *pdev, int type)
 {
-   if (type == S5P_USB_PHY_DEVICE)
+   if (type == USB_PHY_TYPE_DEVICE)
return s3c_usb_otgphy_init(pdev);
 
return -EINVAL;
@@ -84,7 +84,7 @@ int s5p_usb_phy_init(struct platform_device *pdev, int type)
 
 int s5p_usb_phy_exit(struct platform_device *pdev, int type)
 {
-   if (type == S5P_USB_PHY_DEVICE)
+   if (type == USB_PHY_TYPE_DEVICE)
return s3c_usb_otgphy_exit(pdev);
 
return -EINVAL;
diff --git a/arch/arm/mach-s5pv210/setup-usb-phy.c 
b/arch/arm/mach-s5pv210/setup-usb-phy.c
index 356a090..b2ee533 100644
--- a/arch/arm/mach-s5pv210/setup-usb-phy.c
+++ b/arch/arm/mach-s5pv210/setup-usb-phy.c
@@ -80,7 +80,7 @@ static int s5pv210_usb_otgphy_exit(struct platform_device 
*pdev)
 
 int s5p_usb_phy_init(struct platform_device *pdev, int type)
 {
-   if (type == S5P_USB_PHY_DEVICE)
+   if (type == USB_PHY_TYPE_DEVICE)
return s5pv210_usb_otgphy_init(pdev);
 
return -EINVAL;
@@ -88,7 +88,7 @@ int s5p_usb_phy_init(struct platform_device *pdev, int type)
 
 int s5p_usb_phy_exit(struct platform_device *pdev, int type)
 {
-   if (type == S5P_USB_PHY_DEVICE)
+   if (type == USB_PHY_TYPE_DEVICE)
return s5pv210_usb_otgphy_exit(pdev);
 
return -EINVAL;
diff --git a/arch/arm/plat-samsung/include/plat/usb-phy.h 
b/arch/arm/plat-samsung/include/plat/usb-phy.h
index 959bcdb..ab34dfa 100644
--- a/arch/arm/plat-samsung/include/plat/usb-phy.h
+++ b/arch/arm/plat-samsung/include/plat/usb-phy.h
@@ -11,10 +11,7 @@
 #ifndef __PLAT_SAMSUNG_USB_PHY_H
 #define __PLAT_SAMSUNG_USB_PHY_H __FILE__
 
-enum s5p_usb_phy_type {
-   S5P_USB_PHY_DEVICE,
-   S5P_USB_PHY_HOST,
-};
+#include 
 
 extern int s5p_usb_phy_init(struct platform_device *pdev, int type);
 extern int s5p_usb_phy_exit(struct platform_device *pdev, int type);
diff --git a/drivers/usb/host/ehci-s5p.c b/drivers/usb/host/ehci-s5p.c
index 20ebf6a..7dc9c15 100644
--- a/drivers/usb/host/ehci-s5p.c
+++ b/drivers/usb/host/ehci-s5p.c
@@ -19,7 +19,6 @@
 #include 
 #include 
 #include 
-#include 
 
 #define EHCI_INSNREG00(base)   (base + 0x90)
 #define EHCI_INSNREG00_ENA_INCR16  (0x1 << 25)
diff --git a/drivers/usb/host/ohci-exynos.c b/drivers/usb/host/ohci-exynos.c
index 0bd6f47..0792bfd 100644
--- a/drivers/usb/host/ohci-exynos.c
+++ b/drivers/usb/host/ohci-exynos.c
@@ -18,7 +18,6 @@
 #include 
 #include 
 
-#include 
 
 struct exynos_ohci_hcd {
struct device *dev;
-- 
1.8.1.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/

[PATCH 07/30] tty: serial/samsung: fix modular build

[Arnd Bergmann]

There are a few bugs in the samsung serial driver when built as a
loadable module, which makes the console code unavailable, as well as
giving no access to the 'printascii' early debug function. This adds
the appropriate compile time conditionals.

Signed-off-by: Arnd Bergmann 
Cc: linux-ser...@vger.kernel.org
Cc: Greg Kroah-Hartman 
---
 drivers/tty/serial/samsung.c | 4 ++--
 drivers/tty/serial/samsung.h | 4 +++-
 2 files changed, 5 insertions(+), 3 deletions(-)

diff --git a/drivers/tty/serial/samsung.c b/drivers/tty/serial/samsung.c
index 729a60d..a3277ca 100644
--- a/drivers/tty/serial/samsung.c
+++ b/drivers/tty/serial/samsung.c
@@ -894,7 +894,7 @@ console_initcall(s3c24xx_serial_console_init);
 #define S3C24XX_SERIAL_CONSOLE NULL
 #endif
 
-#ifdef CONFIG_CONSOLE_POLL
+#if defined(CONFIG_SERIAL_SAMSUNG_CONSOLE) && defined(CONFIG_CONSOLE_POLL)
 static int s3c24xx_serial_get_poll_char(struct uart_port *port);
 static void s3c24xx_serial_put_poll_char(struct uart_port *port,
 unsigned char c);
@@ -918,7 +918,7 @@ static struct uart_ops s3c24xx_serial_ops = {
.request_port   = s3c24xx_serial_request_port,
.config_port= s3c24xx_serial_config_port,
.verify_port= s3c24xx_serial_verify_port,
-#ifdef CONFIG_CONSOLE_POLL
+#if defined(CONFIG_SERIAL_SAMSUNG_CONSOLE) && defined(CONFIG_CONSOLE_POLL)
.poll_get_char = s3c24xx_serial_get_poll_char,
.poll_put_char = s3c24xx_serial_put_poll_char,
 #endif
diff --git a/drivers/tty/serial/samsung.h b/drivers/tty/serial/samsung.h
index 1a4bca3..00a499e 100644
--- a/drivers/tty/serial/samsung.h
+++ b/drivers/tty/serial/samsung.h
@@ -76,7 +76,9 @@ struct s3c24xx_uart_port {
 #define wr_regb(port, reg, val) __raw_writeb(val, portaddr(port, reg))
 #define wr_regl(port, reg, val) __raw_writel(val, portaddr(port, reg))
 
-#ifdef CONFIG_SERIAL_SAMSUNG_DEBUG
+#if defined(CONFIG_SERIAL_SAMSUNG_DEBUG) && \
+defined(CONFIG_DEBUG_LL) && \
+!defined(MODULE)
 
 extern void printascii(const char *);
 
-- 
1.8.1.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/

[PATCH 13/30] video/s3c: move platform_data out of arch/arm

[Arnd Bergmann]

The s3c-fb driver requires header files from the samsung platforms
to find its platform_data definition, but this no longer works on
multiplatform kernels, so let's move the data into a new header
file under include/linux/platform_data.

Signed-off-by: Arnd Bergmann 
Cc: linux-fb...@vger.kernel.org
Cc: Jingoo Han 
---
 arch/arm/plat-samsung/include/plat/fb.h | 50 +-
 drivers/video/s3c-fb.c  |  3 +-
 include/linux/platform_data/video_s3c.h | 54 +
 3 files changed, 56 insertions(+), 51 deletions(-)
 create mode 100644 include/linux/platform_data/video_s3c.h

diff --git a/arch/arm/plat-samsung/include/plat/fb.h 
b/arch/arm/plat-samsung/include/plat/fb.h
index b885322..9ae5072 100644
--- a/arch/arm/plat-samsung/include/plat/fb.h
+++ b/arch/arm/plat-samsung/include/plat/fb.h
@@ -15,55 +15,7 @@
 #ifndef __PLAT_S3C_FB_H
 #define __PLAT_S3C_FB_H __FILE__
 
-/* S3C_FB_MAX_WIN
- * Set to the maximum number of windows that any of the supported hardware
- * can use. Since the platform data uses this for an array size, having it
- * set to the maximum of any version of the hardware can do is safe.
- */
-#define S3C_FB_MAX_WIN (5)
-
-/**
- * struct s3c_fb_pd_win - per window setup data
- * @xres : The window X size.
- * @yres : The window Y size.
- * @virtual_x: The virtual X size.
- * @virtual_y: The virtual Y size.
- */
-struct s3c_fb_pd_win {
-   unsigned short  default_bpp;
-   unsigned short  max_bpp;
-   unsigned short  xres;
-   unsigned short  yres;
-   unsigned short  virtual_x;
-   unsigned short  virtual_y;
-};
-
-/**
- * struct s3c_fb_platdata -  S3C driver platform specific information
- * @setup_gpio: Setup the external GPIO pins to the right state to transfer
- * the data from the display system to the connected display
- * device.
- * @vidcon0: The base vidcon0 values to control the panel data format.
- * @vidcon1: The base vidcon1 values to control the panel data output.
- * @vtiming: Video timing when connected to a RGB type panel.
- * @win: The setup data for each hardware window, or NULL for unused.
- * @display_mode: The LCD output display mode.
- *
- * The platform data supplies the video driver with all the information
- * it requires to work with the display(s) attached to the machine. It
- * controls the initial mode, the number of display windows (0 is always
- * the base framebuffer) that are initialised etc.
- *
- */
-struct s3c_fb_platdata {
-   void(*setup_gpio)(void);
-
-   struct s3c_fb_pd_win*win[S3C_FB_MAX_WIN];
-   struct fb_videomode *vtiming;
-
-   u32  vidcon0;
-   u32  vidcon1;
-};
+#include 
 
 /**
  * s3c_fb_set_platdata() - Setup the FB device with platform data.
diff --git a/drivers/video/s3c-fb.c b/drivers/video/s3c-fb.c
index 968a625..2e7991c 100644
--- a/drivers/video/s3c-fb.c
+++ b/drivers/video/s3c-fb.c
@@ -24,10 +24,9 @@
 #include 
 #include 
 #include 
+#include 
 
 #include 
-#include 
-#include 
 
 /* This driver will export a number of framebuffer interfaces depending
  * on the configuration passed in via the platform data. Each fb instance
diff --git a/include/linux/platform_data/video_s3c.h 
b/include/linux/platform_data/video_s3c.h
new file mode 100644
index 000..fa40f96
--- /dev/null
+++ b/include/linux/platform_data/video_s3c.h
@@ -0,0 +1,54 @@
+#ifndef __PLATFORM_DATA_VIDEO_S3C
+#define __PLATFORM_DATA_VIDEO_S3C
+
+/* S3C_FB_MAX_WIN
+ * Set to the maximum number of windows that any of the supported hardware
+ * can use. Since the platform data uses this for an array size, having it
+ * set to the maximum of any version of the hardware can do is safe.
+ */
+#define S3C_FB_MAX_WIN (5)
+
+/**
+ * struct s3c_fb_pd_win - per window setup data
+ * @xres : The window X size.
+ * @yres : The window Y size.
+ * @virtual_x: The virtual X size.
+ * @virtual_y: The virtual Y size.
+ */
+struct s3c_fb_pd_win {
+   unsigned short  default_bpp;
+   unsigned short  max_bpp;
+   unsigned short  xres;
+   unsigned short  yres;
+   unsigned short  virtual_x;
+   unsigned short  virtual_y;
+};
+
+/**
+ * struct s3c_fb_platdata -  S3C driver platform specific information
+ * @setup_gpio: Setup the external GPIO pins to the right state to transfer
+ * the data from the display system to the connected display
+ * device.
+ * @vidcon0: The base vidcon0 values to control the panel data format.
+ * @vidcon1: The base vidcon1 values to control the panel data output.
+ * @vtiming: Video timing when connected to a RGB type panel.
+ * @win: The setup data for each hardware window, or NULL for unused.
+ * @display_mode: The LCD output display mode.
+ *
+ * The platform data supplies the video driver with all the information
+ * it 

[PATCH 05/30] tty: serial/samsung: prepare for common clock API

[Arnd Bergmann]

With the common clock interface, there is no way to provide the
"clock_source" sysfs attribute for the samsung serial ports. Given that
this file was purely informational and had fixed contents, we have reason
to believe that no user space programs were relying on it.

The sysfs file is not documented in the ABI docs.

Signed-off-by: Arnd Bergmann 
Cc: linux-ser...@vger.kernel.org
Cc: Greg Kroah-Hartman 
---
 drivers/tty/serial/samsung.c | 7 ++-
 1 file changed, 6 insertions(+), 1 deletion(-)

diff --git a/drivers/tty/serial/samsung.c b/drivers/tty/serial/samsung.c
index 2769a38..603f3f3 100644
--- a/drivers/tty/serial/samsung.c
+++ b/drivers/tty/serial/samsung.c
@@ -1179,6 +1179,7 @@ static int s3c24xx_serial_init_port(struct 
s3c24xx_uart_port *ourport,
return 0;
 }
 
+#ifdef CONFIG_SAMSUNG_CLOCK
 static ssize_t s3c24xx_serial_show_clksrc(struct device *dev,
  struct device_attribute *attr,
  char *buf)
@@ -1194,7 +1195,7 @@ static ssize_t s3c24xx_serial_show_clksrc(struct device 
*dev,
 }
 
 static DEVICE_ATTR(clock_source, S_IRUGO, s3c24xx_serial_show_clksrc, NULL);
-
+#endif
 
 /* Device driver serial port probe */
 
@@ -1252,9 +1253,11 @@ static int s3c24xx_serial_probe(struct platform_device 
*pdev)
uart_add_one_port(_uart_drv, >port);
platform_set_drvdata(pdev, >port);
 
+#ifdef CONFIG_SAMSUNG_CLOCK
ret = device_create_file(>dev, _attr_clock_source);
if (ret < 0)
dev_err(>dev, "failed to add clock source attr.\n");
+#endif
 
ret = s3c24xx_serial_cpufreq_register(ourport);
if (ret < 0)
@@ -1272,7 +1275,9 @@ static int s3c24xx_serial_remove(struct platform_device 
*dev)
 
if (port) {
s3c24xx_serial_cpufreq_deregister(to_ourport(port));
+#ifdef CONFIG_SAMSUNG_CLOCK
device_remove_file(>dev, _attr_clock_source);
+#endif
uart_remove_one_port(_uart_drv, port);
}
 
-- 
1.8.1.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 11/30] [media] exynos: remove unnecessary header inclusions

[Mauro Carvalho Chehab]

Em Thu, 11 Apr 2013 02:04:53 +0200
Arnd Bergmann  escreveu:

> In multiplatform configurations, we cannot include headers
> provided by only the exynos platform. Fortunately a number
> of drivers that include those headers do not actually need
> them, so we can just remove the inclusions.
> 
> Signed-off-by: Arnd Bergmann 
> Cc: linux-me...@vger.kernel.org
> Cc: Mauro Carvalho Chehab 

Acked-by: Mauro Carvalho Chehab 
> ---
>  drivers/media/platform/exynos-gsc/gsc-regs.c | 1 -
>  drivers/media/platform/s5p-tv/sii9234_drv.c  | 3 ---
>  2 files changed, 4 deletions(-)
> 
> diff --git a/drivers/media/platform/exynos-gsc/gsc-regs.c 
> b/drivers/media/platform/exynos-gsc/gsc-regs.c
> index 6f5b5a4..e22d147 100644
> --- a/drivers/media/platform/exynos-gsc/gsc-regs.c
> +++ b/drivers/media/platform/exynos-gsc/gsc-regs.c
> @@ -12,7 +12,6 @@
>  
>  #include 
>  #include 
> -#include 
>  
>  #include "gsc-core.h"
>  
> diff --git a/drivers/media/platform/s5p-tv/sii9234_drv.c 
> b/drivers/media/platform/s5p-tv/sii9234_drv.c
> index d90d228..39b77d2 100644
> --- a/drivers/media/platform/s5p-tv/sii9234_drv.c
> +++ b/drivers/media/platform/s5p-tv/sii9234_drv.c
> @@ -23,9 +23,6 @@
>  #include 
>  #include 
>  
> -#include 
> -#include 
> -
>  #include 
>  #include 
>  


-- 

Cheers,
Mauro
--
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 18/30] ASoC: samsung: move plat/ headers to local directory

[Arnd Bergmann]

The plat/iis.h and plat/ac97.h files in the samsung platform are
only needed by the ASoC drivers, so they can be moved into the
same directory, as one more step towards a multiplatform build.

Signed-off-by: Arnd Bergmann 
Cc: alsa-de...@alsa-project.org
Cc: Mark Brown 
Cc: Liam Girdwood 
---
 arch/arm/mach-s3c24xx/dma-s3c2410.c   | 2 --
 arch/arm/mach-s3c24xx/dma-s3c2412.c   | 2 --
 arch/arm/mach-s3c24xx/dma-s3c2440.c   | 2 --
 arch/arm/mach-s3c24xx/dma-s3c2443.c   | 2 --
 sound/soc/samsung/ac97.c  | 2 +-
 sound/soc/samsung/h1940_uda1380.c | 2 +-
 sound/soc/samsung/neo1973_wm8753.c| 2 +-
 {arch/arm/plat-samsung/include/plat => sound/soc/samsung}/regs-ac97.h | 0
 {arch/arm/plat-samsung/include/plat => sound/soc/samsung}/regs-iis.h  | 0
 sound/soc/samsung/rx1950_uda1380.c| 2 +-
 sound/soc/samsung/s3c24xx-i2s.c   | 2 +-
 sound/soc/samsung/s3c24xx_uda134x.c   | 2 +-
 12 files changed, 6 insertions(+), 14 deletions(-)
 rename {arch/arm/plat-samsung/include/plat => sound/soc/samsung}/regs-ac97.h 
(100%)
 rename {arch/arm/plat-samsung/include/plat => sound/soc/samsung}/regs-iis.h 
(100%)

diff --git a/arch/arm/mach-s3c24xx/dma-s3c2410.c 
b/arch/arm/mach-s3c24xx/dma-s3c2410.c
index a6c94b8..30aa53f 100644
--- a/arch/arm/mach-s3c24xx/dma-s3c2410.c
+++ b/arch/arm/mach-s3c24xx/dma-s3c2410.c
@@ -25,10 +25,8 @@
 
 #include 
 #include 
-#include 
 #include 
 #include 
-#include 
 #include 
 
 static struct s3c24xx_dma_map __initdata s3c2410_dma_mappings[] = {
diff --git a/arch/arm/mach-s3c24xx/dma-s3c2412.c 
b/arch/arm/mach-s3c24xx/dma-s3c2412.c
index c0e8c3f..ab1700e 100644
--- a/arch/arm/mach-s3c24xx/dma-s3c2412.c
+++ b/arch/arm/mach-s3c24xx/dma-s3c2412.c
@@ -25,10 +25,8 @@
 
 #include 
 #include 
-#include 
 #include 
 #include 
-#include 
 #include 
 
 #define MAP(x) { (x)| DMA_CH_VALID, (x)| DMA_CH_VALID, (x)| DMA_CH_VALID, (x)| 
DMA_CH_VALID }
diff --git a/arch/arm/mach-s3c24xx/dma-s3c2440.c 
b/arch/arm/mach-s3c24xx/dma-s3c2440.c
index 1c08eccd..cd25de2 100644
--- a/arch/arm/mach-s3c24xx/dma-s3c2440.c
+++ b/arch/arm/mach-s3c24xx/dma-s3c2440.c
@@ -25,10 +25,8 @@
 
 #include 
 #include 
-#include 
 #include 
 #include 
-#include 
 #include 
 
 static struct s3c24xx_dma_map __initdata s3c2440_dma_mappings[] = {
diff --git a/arch/arm/mach-s3c24xx/dma-s3c2443.c 
b/arch/arm/mach-s3c24xx/dma-s3c2443.c
index 000e4c6..5fe3539 100644
--- a/arch/arm/mach-s3c24xx/dma-s3c2443.c
+++ b/arch/arm/mach-s3c24xx/dma-s3c2443.c
@@ -25,10 +25,8 @@
 
 #include 
 #include 
-#include 
 #include 
 #include 
-#include 
 #include 
 
 #define MAP(x) { \
diff --git a/sound/soc/samsung/ac97.c b/sound/soc/samsung/ac97.c
index 0df3c56..c76abdf 100644
--- a/sound/soc/samsung/ac97.c
+++ b/sound/soc/samsung/ac97.c
@@ -20,7 +20,7 @@
 #include 
 
 #include 
-#include 
+#include "regs-ac97.h"
 #include 
 
 #include "dma.h"
diff --git a/sound/soc/samsung/h1940_uda1380.c 
b/sound/soc/samsung/h1940_uda1380.c
index 15a3817..fa91376 100644
--- a/sound/soc/samsung/h1940_uda1380.c
+++ b/sound/soc/samsung/h1940_uda1380.c
@@ -20,7 +20,7 @@
 #include 
 #include 
 
-#include 
+#include "regs-iis.h"
 #include 
 
 #include "s3c24xx-i2s.h"
diff --git a/sound/soc/samsung/neo1973_wm8753.c 
b/sound/soc/samsung/neo1973_wm8753.c
index a301d8c..ccc601d 100644
--- a/sound/soc/samsung/neo1973_wm8753.c
+++ b/sound/soc/samsung/neo1973_wm8753.c
@@ -21,7 +21,7 @@
 #include 
 
 #include 
-#include 
+#include "regs-iis.h"
 #include 
 
 #include "../codecs/wm8753.h"
diff --git a/arch/arm/plat-samsung/include/plat/regs-ac97.h 
b/sound/soc/samsung/regs-ac97.h
similarity index 100%
rename from arch/arm/plat-samsung/include/plat/regs-ac97.h
rename to sound/soc/samsung/regs-ac97.h
diff --git a/arch/arm/plat-samsung/include/plat/regs-iis.h 
b/sound/soc/samsung/regs-iis.h
similarity index 100%
rename from arch/arm/plat-samsung/include/plat/regs-iis.h
rename to sound/soc/samsung/regs-iis.h
diff --git a/sound/soc/samsung/rx1950_uda1380.c 
b/sound/soc/samsung/rx1950_uda1380.c
index a5826ea..704460a 100644
--- a/sound/soc/samsung/rx1950_uda1380.c
+++ b/sound/soc/samsung/rx1950_uda1380.c
@@ -24,7 +24,7 @@
 #include 
 #include 
 
-#include 
+#include "regs-iis.h"
 #include 
 
 #include "s3c24xx-i2s.h"
diff --git a/sound/soc/samsung/s3c24xx-i2s.c b/sound/soc/samsung/s3c24xx-i2s.c
index 13f6dd1..a7b17c1 100644
--- a/sound/soc/samsung/s3c24xx-i2s.c
+++ b/sound/soc/samsung/s3c24xx-i2s.c
@@ -24,7 +24,7 @@
 #include 
 
 #include 
-#include 
+#include "regs-iis.h"
 
 #include "dma.h"
 #include "s3c24xx-i2s.h"
diff --git a/sound/soc/samsung/s3c24xx_uda134x.c 
b/sound/soc/samsung/s3c24xx_uda134x.c
index 333e1b7..1b7b52b 100644
--- 

[PATCH 17/30] pwm: samsung: repair the worst MMIO abuses

[Arnd Bergmann]

The Samsung PWM driver uses "magic" pointers that are mapped
at boot time to point its MMIO registers. This fails horribly
with a multiplatform kernel, which can not rely on platform
specific header files to contain the right values, aside from
this being a really bad idea in general.

This changes the driver to at least pass an __iomem token
around in the device structure to dereference that. Fixing
the platform code is much harder, so we'll leave that
until we have a DT binding for pwm-samsung, which may require
other changes in this area. Since we are already touching
every MMIO accessor in this driver, let's also use the
proper readl_relaxed variant rather than __raw_readl.

Tomasz Figa has a set of patches to clean this up in a proper
way, but that might be too late for 3.10.

Signed-off-by: Arnd Bergmann 
Cc: Tomasz Figa 
Cc: Thierry Reding 
---
 drivers/pwm/pwm-samsung.c | 60 +--
 1 file changed, 42 insertions(+), 18 deletions(-)

diff --git a/drivers/pwm/pwm-samsung.c b/drivers/pwm/pwm-samsung.c
index 5207e6c..9d7234d 100644
--- a/drivers/pwm/pwm-samsung.c
+++ b/drivers/pwm/pwm-samsung.c
@@ -22,9 +22,25 @@
 #include 
 #include 
 
-#include 
+#ifndef CONFIG_ARCH_MULTIPLATFORM
+/*
+ * This is gross: the platform maps the timer at a fixed
+ * virtual address and expects us to use that address
+ * rather than a proper resource. This should get done properly
+ * when we get a DT binding for this driver.
+ */
+#include 
+static inline void dummy(void)
+{
+   BUILD_BUG_ON(S3C_VA_TIMER != IOMEM(0xf630));
+}
+#else
+#define S3C_VA_TIMER IOMEM(0xf630);
+#endif
 
-#include 
+#define S3C2410_TCON   8
+#define S3C2410_TCNTB(tmr) (0x0c + (tmr)*0x0c + 0x00)
+#define S3C2410_TCMPB(tmr) (0x0c + (tmr)*0x0c + 0x04)
 
 struct s3c_chip {
struct platform_device  *pdev;
@@ -38,6 +54,7 @@ struct s3c_chip {
 
unsigned chartcon_base;
unsigned charpwm_id;
+   void __iomem*base;
struct pwm_chip  chip;
 };
 
@@ -65,9 +82,9 @@ static int s3c_pwm_enable(struct pwm_chip *chip, struct 
pwm_device *pwm)
 
local_irq_save(flags);
 
-   tcon = __raw_readl(S3C2410_TCON);
+   tcon = readl_relaxed(s3c->base + S3C2410_TCON);
tcon |= pwm_tcon_start(s3c);
-   __raw_writel(tcon, S3C2410_TCON);
+   writel_relaxed(tcon, s3c->base + S3C2410_TCON);
 
local_irq_restore(flags);
 
@@ -82,9 +99,9 @@ static void s3c_pwm_disable(struct pwm_chip *chip, struct 
pwm_device *pwm)
 
local_irq_save(flags);
 
-   tcon = __raw_readl(S3C2410_TCON);
+   tcon = readl_relaxed(s3c->base + S3C2410_TCON);
tcon &= ~pwm_tcon_start(s3c);
-   __raw_writel(tcon, S3C2410_TCON);
+   writel_relaxed(tcon, s3c->base + S3C2410_TCON);
 
local_irq_restore(flags);
 }
@@ -133,8 +150,8 @@ static int s3c_pwm_config(struct pwm_chip *chip, struct 
pwm_device *pwm,
/* The TCMP and TCNT can be read without a lock, they're not
 * shared between the timers. */
 
-   tcmp = __raw_readl(S3C2410_TCMPB(s3c->pwm_id));
-   tcnt = __raw_readl(S3C2410_TCNTB(s3c->pwm_id));
+   tcmp = readl_relaxed(s3c->base + S3C2410_TCMPB(s3c->pwm_id));
+   tcnt = readl_relaxed(s3c->base + S3C2410_TCNTB(s3c->pwm_id));
 
period = NS_IN_HZ / period_ns;
 
@@ -177,16 +194,16 @@ static int s3c_pwm_config(struct pwm_chip *chip, struct 
pwm_device *pwm,
 
local_irq_save(flags);
 
-   __raw_writel(tcmp, S3C2410_TCMPB(s3c->pwm_id));
-   __raw_writel(tcnt, S3C2410_TCNTB(s3c->pwm_id));
+   writel_relaxed(tcmp, s3c->base + S3C2410_TCMPB(s3c->pwm_id));
+   writel_relaxed(tcnt, s3c->base + S3C2410_TCNTB(s3c->pwm_id));
 
-   tcon = __raw_readl(S3C2410_TCON);
+   tcon = readl_relaxed(s3c->base + S3C2410_TCON);
tcon |= pwm_tcon_manulupdate(s3c);
tcon |= pwm_tcon_autoreload(s3c);
-   __raw_writel(tcon, S3C2410_TCON);
+   writel_relaxed(tcon, s3c->base + S3C2410_TCON);
 
tcon &= ~pwm_tcon_manulupdate(s3c);
-   __raw_writel(tcon, S3C2410_TCON);
+   writel_relaxed(tcon, s3c->base + S3C2410_TCON);
 
local_irq_restore(flags);
 
@@ -207,6 +224,7 @@ static int s3c_pwm_probe(struct platform_device *pdev)
unsigned long flags;
unsigned long tcon;
unsigned int id = pdev->id;
+   struct resource *res;
int ret;
 
if (id == 4) {
@@ -220,6 +238,12 @@ static int s3c_pwm_probe(struct platform_device *pdev)
return -ENOMEM;
}
 
+   /* try to get a proper base address, fall back to S3C_VA_TIMER */
+   s3c->base = S3C_VA_TIMER;
+   res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
+   if (res)
+   s3c->base = devm_ioremap(dev, res->start, resource_size(res));
+
/* calculate base of control bits in TCON */
s3c->tcon_base = id == 0 ? 0 : (id * 4) + 4;
s3c->pwm_id = id;
@@ -245,9 +269,9 

[PATCH 01/30] ARM: exynos: introduce EXYNOS_ATAGS symbol

[Arnd Bergmann]

As a preparation for multiplatform support, this introduces
a new Kconfig symbol to split the ATAGS based EXYNOS platforms
from the DT based ones. Turning off CONFIG_EXYNOS_ATAGS disables
all platforms that are not yet converted to DT, and we can
have code that relies on DT checking for this symbol being
disabled.

Signed-off-by: Arnd Bergmann 
---
 arch/arm/mach-exynos/Kconfig | 15 +++
 1 file changed, 15 insertions(+)

diff --git a/arch/arm/mach-exynos/Kconfig b/arch/arm/mach-exynos/Kconfig
index a62cfa0..e815057 100644
--- a/arch/arm/mach-exynos/Kconfig
+++ b/arch/arm/mach-exynos/Kconfig
@@ -82,6 +82,19 @@ config SOC_EXYNOS5440
help
  Enable EXYNOS5440 SoC support
 
+config EXYNOS_ATAGS
+   bool "ATAGS based boot for EXYNOS (deprecated)"
+   depends on ARCH_EXYNOS_SINGLE
+   depends on ATAGS
+   default y
+   help
+ The EXYNOS platform is moving towards being completely probed
+ through device tree. This enables support for board files using
+ the traditional ATAGS boot format.
+ Note that this option is not available for multiplatform builds.
+
+if EXYNOS_ATAGS
+
 config EXYNOS_DEV_DMA
bool
help
@@ -386,6 +399,8 @@ config MACH_SMDK4412
  Machine support for Samsung SMDK4412
 endif
 
+endif
+
 comment "Flattened Device Tree based board for EXYNOS SoCs"
 
 config MACH_EXYNOS4_DT
-- 
1.8.1.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/

[PATCH 24/30] clocksource: exynos_mct: remove platform header dependency

[Arnd Bergmann]

For the non-DT case, the mct_init() function requires access
to a couple of platform specific constants, but cannot include
the header files in case we are building for multiplatform.

This changes the interface to the platform so we pass all
the necessary data as arguments to mct_init.

Signed-off-by: Arnd Bergmann 
Cc: Thomas Gleixner 
Cc: John Stultz 
---
 arch/arm/mach-exynos/common.c|  2 +-
 arch/arm/mach-exynos/common.h|  2 +-
 drivers/clocksource/exynos_mct.c | 21 ++---
 3 files changed, 8 insertions(+), 17 deletions(-)

diff --git a/arch/arm/mach-exynos/common.c b/arch/arm/mach-exynos/common.c
index 87b2e06..8e85d6c 100644
--- a/arch/arm/mach-exynos/common.c
+++ b/arch/arm/mach-exynos/common.c
@@ -448,7 +448,7 @@ void __init exynos_init_time(void)
exynos4_clk_init(NULL, !soc_is_exynos4210(), S5P_VA_CMU, 
readl(S5P_VA_CHIPID + 8) & 1);
exynos4_clk_register_fixed_ext(xxti_f, xusbxti_f);
 #endif
-   mct_init();
+   mct_init(S5P_VA_SYSTIMER, EXYNOS4_IRQ_MCT_G0, 
EXYNOS4_IRQ_MCT_L0, EXYNOS4_IRQ_MCT_L1);
}
 }
 
diff --git a/arch/arm/mach-exynos/common.h b/arch/arm/mach-exynos/common.h
index 9832e03..f426a5b 100644
--- a/arch/arm/mach-exynos/common.h
+++ b/arch/arm/mach-exynos/common.h
@@ -14,7 +14,7 @@
 
 #include 
 
-extern void mct_init(void);
+void mct_init(void __iomem *base, int irq_g0, int irq_l0, int irq_l1);
 void exynos_init_time(void);
 extern unsigned long xxti_f, xusbxti_f;
 
diff --git a/drivers/clocksource/exynos_mct.c b/drivers/clocksource/exynos_mct.c
index 020ba55..88ff404 100644
--- a/drivers/clocksource/exynos_mct.c
+++ b/drivers/clocksource/exynos_mct.c
@@ -26,11 +26,6 @@
 
 #include 
 #include 
-
-#include 
-
-#include 
-#include 
 #include 
 
 #define EXYNOS4_MCTREG(x)  (x)
@@ -511,18 +506,14 @@ static void __init exynos4_timer_resources(struct 
device_node *np, void __iomem
 #endif /* CONFIG_LOCAL_TIMERS */
 }
 
-void __init mct_init(void)
+void __init mct_init(void __iomem *base, int irq_g0, int irq_l0, int irq_l1)
 {
-   if (soc_is_exynos4210()) {
-   mct_irqs[MCT_G0_IRQ] = EXYNOS4_IRQ_MCT_G0;
-   mct_irqs[MCT_L0_IRQ] = EXYNOS4_IRQ_MCT_L0;
-   mct_irqs[MCT_L1_IRQ] = EXYNOS4_IRQ_MCT_L1;
-   mct_int_type = MCT_INT_SPI;
-   } else {
-   panic("unable to determine mct controller type\n");
-   }
+   mct_irqs[MCT_G0_IRQ] = irq_g0;
+   mct_irqs[MCT_L0_IRQ] = irq_l0;
+   mct_irqs[MCT_L1_IRQ] = irq_l1;
+   mct_int_type = MCT_INT_SPI;
 
-   exynos4_timer_resources(NULL, S5P_VA_SYSTIMER);
+   exynos4_timer_resources(NULL, base);
exynos4_clocksource_init();
exynos4_clockevent_init();
 }
-- 
1.8.1.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/