linux.kernel - 26 new messages in 14 topics - digest

linux.kernel
http://groups.google.com/group/linux.kernel?hl=en

linux.kernel@googlegroups.com

Today's topics:

* Please pull powerpc.git merge branch - 1 messages, 1 author
http://groups.google.com/group/linux.kernel/t/0c5155d42ce7fe04?hl=en
* sched: find the latest idle cpu - 1 messages, 1 author
http://groups.google.com/group/linux.kernel/t/c0d098923e6f4ee6?hl=en
* qrwlock: Use smp_store_release() in write_unlock() - 1 messages, 1 author
http://groups.google.com/group/linux.kernel/t/31f786da5ce84591?hl=en
* mfd: MAX6650/6651 support - 1 messages, 1 author
http://groups.google.com/group/linux.kernel/t/f77c4e32918b37db?hl=en
* mtd: davinci_nand: Remove unnecessary labels from error path - 1 messages, 1
author
http://groups.google.com/group/linux.kernel/t/3f7a21b37739cbbb?hl=en
* x86: add generic function to modify more calls using int3 framework - 1
messages, 1 author
http://groups.google.com/group/linux.kernel/t/f397bd207e78dab7?hl=en
* powermgt: Add OPAL call to resync timebase on wakeup - 9 messages, 1 author
http://groups.google.com/group/linux.kernel/t/22674aecfbd885e9?hl=en
* [ tip/sched/core ] System unresponsive after booting - 1 messages, 1 author
http://groups.google.com/group/linux.kernel/t/7e9e79975ef03250?hl=en
* gpio: pxa: normalize the return value for gpio_get - 1 messages, 1 author
http://groups.google.com/group/linux.kernel/t/3ed862e7a52d4aa8?hl=en
* virtio-net: fix build on m68k and sparc64 - 3 messages, 2 authors
http://groups.google.com/group/linux.kernel/t/6c656c739600c6e8?hl=en
* nouveau - BUG: unable to handle kernel NULL pointer dereference - 2 messages,
2 authors
http://groups.google.com/group/linux.kernel/t/eb605f755abdb3d6?hl=en
* mm/memcg: iteration skip memcgs not yet fully initialized - 2 messages, 1
author
http://groups.google.com/group/linux.kernel/t/da1204ed98ee639c?hl=en
* Device Tree support for the at91sam9261ek - 1 messages, 1 author
http://groups.google.com/group/linux.kernel/t/88f86d5983c318d0?hl=en
* mm: vmscan: shrink all slab objects if tight on memory - 1 messages, 1
author
http://groups.google.com/group/linux.kernel/t/1eeb271b3e227b91?hl=en

==============================================================================
TOPIC: Please pull powerpc.git merge branch
http://groups.google.com/group/linux.kernel/t/0c5155d42ce7fe04?hl=en
==============================================================================

== 1 of 1 ==
Date: Wed, Jan 15 2014 12:10 am
From: Linus Torvalds


On Wed, Jan 15, 2014 at 12:01 PM, Benjamin Herrenschmidt
<benh@kernel.crashing.org> wrote:
>
> My original intend was to put it in powerpc-next and then shoot it to
> stable, but it got a tad annoying (due to churn it needs to be applied
> at least on rc4 or later while my next is at rc1 and clean that way), so
> I put it in the merge branch.

Quite frankly, I'll prefer to not merge it now, and then 3.13 will get
it from stable, when it does things like this.

Partly because it fixes a power-only bug, but potentially changes
non-power behavior. If it was all in arch/powerpc, I wouldn't mind.

Linus
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/





==============================================================================
TOPIC: sched: find the latest idle cpu
http://groups.google.com/group/linux.kernel/t/c0d098923e6f4ee6?hl=en
==============================================================================

== 1 of 1 ==
Date: Wed, Jan 15 2014 12:10 am
From: Michael wang


On 01/15/2014 02:45 PM, Alex Shi wrote:
[snip]
>
> yes, to save your scenario, we need to know the next timer for idle cpu,
> but that is not enough, interrupt is totally unpredictable. So, I'd
> rather bear the coarse method now.
>>
>> So what about just check 'ts->tick_stopped' and record one ticking idle
>> cpu? the cost could be lower than time comparison, we could reduce the
>> risk may be...(well, not so risky since the logical only works when
>> system is relaxing with several cpu idle)
>
> first, nohz full also stop tick. second, tick_stopped can not reflect
> the interrupt. when the idle cpu was interrupted, it's waken, then be a
> good candidate for task running.

IMHO, if we have to do gamble here, we better choose the cheaper bet,
unless we could prove this 'coarse method' have more higher chance for
BINGO than just check 'tick_stopped'...

BTW, may be the logical should be in the select_idle_sibling()?

Regards,
Michael Wang

>

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/





==============================================================================
TOPIC: qrwlock: Use smp_store_release() in write_unlock()
http://groups.google.com/group/linux.kernel/t/31f786da5ce84591?hl=en
==============================================================================

== 1 of 1 ==
Date: Wed, Jan 15 2014 12:10 am
From: Peter Zijlstra


On Tue, Jan 14, 2014 at 06:39:58PM -0800, Paul E. McKenney wrote:
> > If you just want to do a store release, on alpha you'd want to
> > implement that as a full memory barrier followed by a store. It
> > doesn't get the advantage of a real release consistency model, but at
> > least it's not doing an external bus access. But you can only do that
> > store as a 4-byte or 8-byte store.on the older alphas (byte and word
> > stores work on newer ones).
> >
> > Of course, it's entirely possible that nobody cares..
>
> That would be my hope. ;-)
>
> If nobody cares about Alpha period, it is easy. However, the last time
> that I tried that approach, they sent me a URL of a wiki showing Alpha
> systems still running mainline. But a slow-but-working approach for
> Alpha does seem reasonable, even for those still running Linux on Alpha.

Well, if they're all EV56 or later we're still good as they can actually
do what we need.

But I don't think a ll/sc implementation of the store_release can even
work, because in that case all users of the other bytes also need a
ll/sc around them but how are we to know about them?

So the only real way to allow store_release on 8/16 bit values is by
removing all Alpha support _pre_ EV56 :/
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/





==============================================================================
TOPIC: mfd: MAX6650/6651 support
http://groups.google.com/group/linux.kernel/t/f77c4e32918b37db?hl=en
==============================================================================

== 1 of 1 ==
Date: Wed, Jan 15 2014 12:10 am
From: Linus Walleij


On Fri, Jan 10, 2014 at 10:56 AM, Lee Jones <lee.jones@linaro.org> wrote:
> On Thu, 09 Jan 2014, Laszlo Papp wrote:
>
>> >> +int max6651_read_reg(struct i2c_client *i2c, u8 reg, u8 *dest)
>> >> +{
>> >
>> > Probably best to use Regmap instead.
>> >
>> > regmap_i2c_read()
>>
>> >> +int max6651_write_reg(struct i2c_client *i2c, u8 reg, u8 value)
>> >> +{
>> >> + struct max6651_dev *max6651 = i2c_get_clientdata(i2c);
>> >> + int ret;
>> >
>> > Same here.
>> >
>> > regmap_i2c_write()
>>
>> Hmm, but what Linus linked is using regmap_read/write(...) instead of
>> regmap_i2c_read/write(...).
>>
>> I thought I would need to be using the former. Perhaps, I
>> misunderstand something?
>>
>> I do not even find the aforementioend functions used by drivers based
>> on this LXR result:
>> http://lxr.free-electrons.com/ident?i=regmap_i2c_write
>
> Linus is in a better position to know, use his suggestion.

Just use regmap_read/write to abstract things and hide the
underlying marshalling in regmap.

regmap_i2c_write is some regmap-internal thing.

Yours,
Linus Walleij
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/





==============================================================================
TOPIC: mtd: davinci_nand: Remove unnecessary labels from error path
http://groups.google.com/group/linux.kernel/t/3f7a21b37739cbbb?hl=en
==============================================================================

== 1 of 1 ==
Date: Wed, Jan 15 2014 12:10 am
From: Prabhakar Lad


From: "Lad, Prabhakar" <prabhakar.csengg@gmail.com>

This patch removes the unnecessary labels from
the error path in probe function which did nothing
than just returning error values, Thus simplifying code
path and improved readability.

Signed-off-by: Lad, Prabhakar <prabhakar.csengg@gmail.com>
---
drivers/mtd/nand/davinci_nand.c | 31 ++++++++++---------------------
1 file changed, 10 insertions(+), 21 deletions(-)

diff --git a/drivers/mtd/nand/davinci_nand.c b/drivers/mtd/nand/davinci_nand.c
index b77a01e..3e4d457 100644
--- a/drivers/mtd/nand/davinci_nand.c
+++ b/drivers/mtd/nand/davinci_nand.c
@@ -609,8 +609,7 @@ static int __init nand_davinci_probe(struct platform_device *pdev)
info = devm_kzalloc(&pdev->dev, sizeof(*info), GFP_KERNEL);
if (!info) {
dev_err(&pdev->dev, "unable to allocate memory\n");
- ret = -ENOMEM;
- goto err_nomem;
+ return -ENOMEM;
}

platform_set_drvdata(pdev, info);
@@ -619,20 +618,16 @@ static int __init nand_davinci_probe(struct platform_device *pdev)
res2 = platform_get_resource(pdev, IORESOURCE_MEM, 1);
if (!res1 || !res2) {
dev_err(&pdev->dev, "resource missing\n");
- ret = -EINVAL;
- goto err_nomem;
+ return -EINVAL;
}

vaddr = devm_ioremap_resource(&pdev->dev, res1);
- if (IS_ERR(vaddr)) {
- ret = PTR_ERR(vaddr);
- goto err_ioremap;
- }
+ if (IS_ERR(vaddr))
+ return PTR_ERR(vaddr);
+
base = devm_ioremap_resource(&pdev->dev, res2);
- if (IS_ERR(base)) {
- ret = PTR_ERR(base);
- goto err_ioremap;
- }
+ if (IS_ERR(base))
+ return PTR_ERR(base);

info->dev = &pdev->dev;
info->base = base;
@@ -699,7 +694,7 @@ static int __init nand_davinci_probe(struct platform_device *pdev)
spin_unlock_irq(&davinci_nand_lock);

if (ret == -EBUSY)
- goto err_ecc;
+ return ret;

info->chip.ecc.calculate = nand_davinci_calculate_4bit;
info->chip.ecc.correct = nand_davinci_correct_4bit;
@@ -715,16 +710,14 @@ static int __init nand_davinci_probe(struct platform_device *pdev)
info->chip.ecc.strength = pdata->ecc_bits;
break;
default:
- ret = -EINVAL;
- goto err_ecc;
+ return -EINVAL;
}
info->chip.ecc.mode = ecc_mode;

info->clk = devm_clk_get(&pdev->dev, "aemif");
if (IS_ERR(info->clk)) {
- ret = PTR_ERR(info->clk);
dev_dbg(&pdev->dev, "unable to get AEMIF clock, err %d\n", ret);
- goto err_clk;
+ return PTR_ERR(info->clk);
}

ret = clk_prepare_enable(info->clk);
@@ -853,10 +846,6 @@ err_clk_enable:
ecc4_busy = false;
spin_unlock_irq(&davinci_nand_lock);

-err_ecc:
-err_clk:
-err_ioremap:
-err_nomem:
return ret;
}

--
1.7.9.5

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/





==============================================================================
TOPIC: x86: add generic function to modify more calls using int3 framework
http://groups.google.com/group/linux.kernel/t/f397bd207e78dab7?hl=en
==============================================================================

== 1 of 1 ==
Date: Wed, Jan 15 2014 12:20 am
From: Masami Hiramatsu


(2014/01/15 9:33), Steven Rostedt wrote:
> On Tue, 10 Dec 2013 16:42:15 +0100
> Petr Mladek <pmladek@suse.cz> wrote:
>
>> diff --git a/arch/x86/include/asm/alternative.h b/arch/x86/include/asm/alternative.h
>> index 586747f5f41d..82ffe7e1529c 100644
>> --- a/arch/x86/include/asm/alternative.h
>> +++ b/arch/x86/include/asm/alternative.h
>> @@ -232,4 +232,40 @@ extern int text_poke_bp(void *addr, const void *opcode, size_t len,
>> extern void text_poke_bp_or_die(void *addr, const void *opcode, size_t len,
>> void *handler);
>
> Small nit. If you can, place comments on the same line as the
> structure field.
>
>> +struct text_poke_bp_iter {
>> + /* information used to start iteration from the beginning */
>> + void *init;
>> + /* length of the patched instruction */
>> + size_t len;
>> + /* details about failure if any */
>> + int fail_count;
>> + void *fail_addr;
>
> The above should have the comments on the same line as the field.
> Something like this:
>
> void *init; /* information used to start
> iteration from the beginning */
>
> The comments for the function pointers below are fine.
>
>> + /* iteration over entries */
>> + void *(*start)(void *init);
>> + void *(*next)(void *prev);
>> + /* callback to get patched address */
>> + void *(*get_addr)(void *cur);
>> + /*
>> + * Callbacks to get the patched code. They could return NULL if no
>> + * patching is needed; This is useful for example in ftrace.
>> + */
>> + const void *(*get_opcode)(void *cur);
>> + const void *(*get_old_opcode)(void *cur);
>> + /*
>> + * Optional function that is called when the patching of the given
>> + * has finished. It might be NULL if no postprocess is needed.
>> + */
>> + int (*finish)(void *cur);
>> + /*
>> + * Helper function for int3 handler. It decides whether the given IP
>> + * is being patched or not.
>> + *
>> + * Try to implement it as fast as possible. It affects performance
>> + * of the system when the patching is in progress.
>> + */
>> + void *(*is_handled)(const unsigned long ip);
>> +};
>> +
>> +extern int text_poke_bp_list(struct text_poke_bp_iter *iter);
>> +
>>