[PATCH v2 1/2] watchdog: xilinx: Fix driver header

[Michal Simek]

- Remove reference for IP version
- Fix header coding style
- Remove notes which are visible from the code
- Fix driver license according to header

Signed-off-by: Michal Simek 
---
Changes in v2: None

 drivers/watchdog/of_xilinx_wdt.c | 30 ++
 1 file changed, 10 insertions(+), 20 deletions(-)

diff --git a/drivers/watchdog/of_xilinx_wdt.c b/drivers/watchdog/of_xilinx_wdt.c
index 2761ddb..d4a35ab 100644
--- a/drivers/watchdog/of_xilinx_wdt.c
+++ b/drivers/watchdog/of_xilinx_wdt.c
@@ -1,23 +1,13 @@
 /*
-*   of_xilinx_wdt.c  1.01  A Watchdog Device Driver for Xilinx xps_timebase_wdt
-*
-*   (C) Copyright 2011 (Alejandro Cabrera )
-*
-*   ---
-*
-*   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 of the License, or (at your option) any later version.
-*
-*   ---
-*  30-May-2011 Alejandro Cabrera 
-*  - If "xlnx,wdt-enable-once" wasn't found on device tree the
-*module will use CONFIG_WATCHDOG_NOWAYOUT
-*  - If the device tree parameters ("clock-frequency" and
-*"xlnx,wdt-interval") wasn't found the driver won't
-*know the wdt reset interval
-*/
+ * Watchdog Device Driver for Xilinx axi/xps_timebase_wdt
+ *
+ * (C) Copyright 2011 (Alejandro Cabrera )
+ *
+ * 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 of the License, or (at your option) any later version.
+ */

 #define pr_fmt(fmt) KBUILD_MODNAME ": " fmt

@@ -413,5 +403,5 @@ module_platform_driver(xwdt_driver);

 MODULE_AUTHOR("Alejandro Cabrera ");
 MODULE_DESCRIPTION("Xilinx Watchdog driver");
-MODULE_LICENSE("GPL");
+MODULE_LICENSE("GPL v2");
 MODULE_ALIAS_MISCDEV(WATCHDOG_MINOR);
--
1.8.2.3



pgpAN_631E_Zq.pgp
Description: PGP signature

[PATCH v2 2/2] watchdog: xilinx: Setup the origin compatible string

[Michal Simek]

Watchdog 1.01.a is also compatible with 1.00.a.
Add the origin version to compatible list.

Signed-off-by: Michal Simek 
---
Changes in v2:
- Extend compatible list with 1.00.a instead of replacing 1.01.a
  reported by Guenter Roeck 

 drivers/watchdog/of_xilinx_wdt.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/watchdog/of_xilinx_wdt.c b/drivers/watchdog/of_xilinx_wdt.c
index d4a35ab..4dd281f 100644
--- a/drivers/watchdog/of_xilinx_wdt.c
+++ b/drivers/watchdog/of_xilinx_wdt.c
@@ -384,6 +384,7 @@ static int xwdt_remove(struct platform_device *dev)

 /* Match table for of_platform binding */
 static struct of_device_id xwdt_of_match[] = {
+   { .compatible = "xlnx,xps-timebase-wdt-1.00.a", },
{ .compatible = "xlnx,xps-timebase-wdt-1.01.a", },
{},
 };
--
1.8.2.3



pgpbydtlPcv7T.pgp
Description: PGP signature

[PATCH v2 0/2] Xilinx watchdog changes

[Michal Simek]

The patchset fixes license header and add 1.00.a IP to compatible
list.

Thanks for your review,
Michal

Remove the 3rd patch from this series which incorrectly
tried to support set timeout feature.

Changes in v2:
- Extend compatible list with 1.00.a instead of replacing 1.01.a
  reported by Guenter Roeck 

Michal Simek (2):
  watchdog: xilinx: Fix driver header
  watchdog: xilinx: Setup the origin compatible string

 drivers/watchdog/of_xilinx_wdt.c | 31 +++
 1 file changed, 11 insertions(+), 20 deletions(-)

--
1.8.2.3



pgp1hHJVTULbz.pgp
Description: PGP signature

Re: [PATCH 3/3] watchdog: xilinx: Add WDIOC_SETTIMEOUT ioctl function

[Michal Simek]

On 05/31/2013 12:08 AM, Wim Van Sebroeck wrote:
> Hi All,
> 
>>> On Thu, May 30, 2013 at 05:12:24PM +0200, Michal Simek wrote:
 On 05/30/2013 05:03 PM, Guenter Roeck wrote:
> On Thu, May 30, 2013 at 04:34:02PM +0200, Michal Simek wrote:
>> On 05/30/2013 04:21 PM, Guenter Roeck wrote:
>>> On Thu, May 30, 2013 at 04:15:45PM +0200, Michal Simek wrote:
 On 05/30/2013 04:07 PM, Guenter Roeck wrote:
> On Thu, May 30, 2013 at 02:26:04PM +0200, Michal Simek wrote:
>> Standard watchdog programs try to setup timeout
>> via ioctl and this functionality should be implemented.
>> Timeout value is hardcoded in the hardware but
>> based on Documentation/watchdog/watchdog-api.txt
>> can return the real timeout used in the same variable.
>>
>> Signed-off-by: Michal Simek 
>> ---
>>  drivers/watchdog/of_xilinx_wdt.c | 1 +
>>  1 file changed, 1 insertion(+)
>>
>> diff --git a/drivers/watchdog/of_xilinx_wdt.c
>>> b/drivers/watchdog/of_xilinx_wdt.c
>> index 79f358c..a3bbe72 100644
>> --- a/drivers/watchdog/of_xilinx_wdt.c
>> +++ b/drivers/watchdog/of_xilinx_wdt.c
>> @@ -253,6 +253,7 @@ static long xwdt_ioctl(struct file *file,
>>> unsigned int cmd, unsigned long arg)
>>xwdt_keepalive();
>>return 0;
>>
>> +  case WDIOC_SETTIMEOUT:
>>case WDIOC_GETTIMEOUT:
>>if (no_timeout)
>>return -ENOTTY;
>
> Watchdog programs should check ident.options before trying to set
>>> the timeout.
> If they don't, there is an application bug. I don't think it is a
>>> good idea
> to start hacking the kernel to work around application bugs.

 Based on Documentation/watchdog/watchdog-api.txt

 "For some drivers it is possible to modify the watchdog timeout on
>>> the
 fly with the SETTIMEOUT ioctl, those drivers have the
>>> WDIOF_SETTIMEOUT
 flag set in their option field.  The argument is an integer
>>>
>>> Yes, but WDIOF_SETTIMEOUT is not set in the driver's option field.
>>
>> ok. It means I should probably enable it.
>>
> I am missing your point. Applications should not try to write the
>>> timeout
> since WDIOF_SETTIMEOUT is not set. Any application doing it anyway is
>>> buggy
> and should be fixed.

 I fully understand your points and 100% agree with you
 1. the application is broken and should be fixed
 2. also the kernel shouldn't fix any problem with stupid application

 But based on documentation the driver can support setup timeout
 and based on description "the driver returns the real timeout used
 in the same variable and this timeout might differ from the requested one
 due to limitation of the hardware"
 Based on this I still think that the driver can support set timeout
 feature and if the driver supports this option then WDIOF_SETTIMEOUT
 should be set in driver's option field. And I would add this to v2.

 Can you see my point now?
>>>
>>> No. The driver doesn't support setting the timeout. You just want it
>>> to falsely claim that it does to work around an application problem.
>>> With your logic, _every_ watchdog driver would "support" setting
>>> the timeout.
>>>
>>
>> I don't want to falsely claim anything.
>> I am just saying this is written in the documentation and
>> it is my understanding that this can be implemented it this way
>> for this xilinx device and behaviour of the driver will be correct
>> according to documentation which I copied to this thread.
>>
>> If Wim says that if device doesn't support setting timeout in HW
>> then this ioctl can't be implemented in this way I am definitely OK with
>> it.
>> And I will remove this patch and will also remove this change
>> from our xilinx repo.
>> The main purpose for me is to cleanup our repo and push all changes
>> to the mainline. Of course if this change goes against watchdog
>> logic and it is broken I will the first who will revert it in our repo
>> and will have proper description based on our discussion.
>>
>> I really appreciate your inputs for this discussion and both
>> resolution ACK/NACK are OK because I will know what's the correct
>> way and I can fix it in mainline or our repo and both will be in sync.
> 
> Logic is: if device supports setting timeout values, then and only then
> you indicate this by setting the WDIOF_SETTIMEOUT flag and adding the code
> for it. And then you can do minor adjustments if needed and report this back.
> But that's only to make sure that some roundings (like a timer in minutes 
> gives back 60 or 120 seconds if you would set a new timeout of 70 seconds).
> 
> So in this case: the HW doesn't support setting timeout values,
> so we don't add the WDIOF_SETTIMEOUT flag 

Re: [PATCH] powerpc/pci: Improve device hotplug initialization

[Benjamin Herrenschmidt]

On Thu, 2013-05-30 at 22:14 -0700, Guenter Roeck wrote:
> On Wed, May 29, 2013 at 05:30:41PM +0800, Chen Yuanquan-B41889 wrote:
> > On 05/29/2013 01:35 AM, Guenter Roeck wrote:
> > >bios_add_device(). Drop explicit calls to pcibios_setup_device();
> > >this makes pcibios_setup_bus_devices() a noop function which could
> > >eve
> > 
> > Yeah, it's more reasonable to do the irq and DMA related initialization
> > in one code path for all devices.
> > 
> Any comments / feedback on the code itself ?

Sorry, I haven't had a chance to review it yet, I'm fairly bogged down
at the moment. I want to tread carefully because the previous iteration
of changing that stuff did break a few platforms in the end.

Cheers,
Ben.


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

Re: [PATCH 1/2] GPIO: Add support for dual channel in gpio-xilinx.c

[Michal Simek]

Hi Linus,

On 05/30/2013 09:46 PM, Linus Walleij wrote:
> On Wed, May 29, 2013 at 1:27 PM, Michal Simek  wrote:
> 
>> Supporting the second channel in the driver.
>> Offset is 0x8 and both channnels share the same
>> IRQ.
>>
>> Signed-off-by: Michal Simek 
> 
> (...)
>> +/* Read/Write access to the GPIO registers */
>> +#define xgpio_readreg(offset)  __raw_readl(offset)
>> +#define xgpio_writereg(offset, val)__raw_writel(val, offset)
> 
> So you're swithing in_be32/out_be32 to the CPU-dependent
> __raw_readl/__raw_writel functions? Why?

The reason is that this driver can be used on ARM where in_be32/out_be32
is not implemented.

> Can you explain exactly why you are using __raw_* accessors
> rather than e.g. atleast readl_relaxed()/writel_relaxed()
> or even plain readl/writel so you know the writes will hit
> the hardware as immediately as possible?

Using __raw* function ensure that it is working on all
cpus. Microblaze big/little endian, PPC big endian and ARM little endian.

The correct way how to implement this is based on my previous
discussion to detect endians directly on IP.

But for this gpio case without interrupt connected(it means without
interrupt logic) there are just 2 registers data and tristate
(http://www.xilinx.com/support/documentation/ip_documentation/axi_gpio/v1_01_b/ds744_axi_gpio.pdf)
and auto detection can't be done.

> I'd prefer this step to be a separate patch.

ok. Will do based on my discussion around xilinxfb.

>>  struct xgpio_instance {
>> struct of_mm_gpio_chip mmchip;
>> u32 gpio_state; /* GPIO state shadow register */
>> u32 gpio_dir;   /* GPIO direction shadow register */
>> +   u32 offset;
>> spinlock_t gpio_lock;   /* Lock used for synchronization */
>>  };
> 
> Why not take this opportunity to move the comments out to
> kerneldoc above this struct, plus document what "offset"
> means.

Good point. Will fix.

> 
>> -   return (in_be32(mm_gc->regs + XGPIO_DATA_OFFSET) >> gpio) & 1;
>> +   return (xgpio_readreg(regs + XGPIO_DATA_OFFSET) >> gpio) & 1;
> 
> 
> Another way would be:
> 
> #include 
> 
> return !!(xgpio_readreg(regs + XGPIO_DATA_OFFSET & BIT(gpio));
> 
>> +
>> +   pr_info("XGpio: %s: registered, base is %d\n", np->full_name,
>> +   
>> chip->mmchip.gc.base);
>> +
>> +   tree_info = of_get_property(np, "xlnx,is-dual", NULL);
> 
> This looks like you want to use of_property_read_bool().

Ah yeah.

> Have you documented these new bindings? It doesn't seem so.
> Documentation/devicetree/bindings/gpio/*...
> 
> If it's undocumented so far, this is a good oppotunity to add it.

Isn't it enough what it is in 2/2?
Or do you want to describe current binding in the first patch
and then extend it in this patch when dual channel is added?


>> +   if (tree_info && be32_to_cpup(tree_info)) {
>> +   chip = kzalloc(sizeof(*chip), GFP_KERNEL);
>> +   if (!chip)
>> +   return -ENOMEM;
>> +
>> +   /* Add dual channel offset */
>> +   chip->offset = XGPIO_CHANNEL_OFFSET;
>> +
>> +   /* Update GPIO state shadow register with default value */
>> +   tree_info = of_get_property(np, "xlnx,dout-default-2", NULL);
>> +   if (tree_info)
>> +   chip->gpio_state = be32_to_cpup(tree_info);
> 
> This is basically a jam table (hardware set-up) in the device tree.

Not sure what you mean by that. Xilinx GPIO is soft IP which can be configured
to different configurations before bitstream is generated.
At the end you will get different setting/addresses setup for every pin
which is described by these xlnx,X descriptions.

> I don't exactly like this. Is this necessary?

If you mean names or values in there that all of them are autogenerated
from design tools and they are reflect IP hardware description and all
configuration options which you can have there.
It means that all these values give you exact hardware description.

Do I answer your question?


> 
>> +   /* Update GPIO direction shadow register with default value 
>> */
>> +   /* By default, all pins are inputs */
>> +   chip->gpio_dir = 0x;
>> +   tree_info = of_get_property(np, "xlnx,tri-default-2", NULL);
>> +   if (tree_info)
>> +   chip->gpio_dir = be32_to_cpup(tree_info);
> 
> Dito.
> 
>> +   /* Check device node and parent device node for device width 
>> */
>> +   /* By default assume full GPIO controller */
>> +   chip->mmchip.gc.ngpio = 32;
>> +   tree_info = of_get_property(np, "xlnx,gpio2-width", NULL);
>> +   if (tree_info)
>> +   chip->mmchip.gc.ngpio = be32_to_cpup(tree_info);
> 
> Seems fine, but document it in the binding.

I will look at new fdt function to shorten this code to look better.

Re: [PATCH 0/3] pktcdvd: A few more neatenings

[Joe Perches]

On Thu, 2013-05-30 at 13:57 -0700, Joe Perches wrote:
> Joe Perches (3):
>   pktcdvd: Convert ZONE macro to static function get_zone()
>   pktcdvd: Convert printk to pr_
>   pktcdvd: Consolidate DPRINTK and VPRINTK macros
> 
>  drivers/block/pktcdvd.c | 248 
> 
>  1 file changed, 126 insertions(+), 122 deletions(-)
> 

Hey Jiri.

This doesn't compile correctly.
1/3 adds a compile time error, 2/3 corrects it.

Please ignore it.

--
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: 3.9.4 Oops running xfstests (WAS Re: 3.9.3: Oops running xfstests)

[Eric Sandeen]

On 5/30/13 10:03 PM, CAI Qian wrote:
> OK, so the minimal workload to trigger this I found so far was to
> run trinity, ltp and then xfstests. I have been able to easily
> reproduced on 3 servers so far, and I'll post full logs here for
> LKML and linux-mm as this may unrelated to XFS only. As far as
> I can tell from the previous testing results, this has never been
> reproduced back in 3.9 GA time. This seems also been reproduced
> on 3.10-rc3 mostly on s390x so far.
> CAI Qian
> 

Can you hit it w/o trinity?   I ask because trinity's stated
goal is to fuzz and corrupt, right - so it's quite possible
that blowing up later in xfs is a side effect?

-Eric

--
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 2/2] clocksource: dw_apb: allow build for architectures other than arm

[Baruch Siach]

Hi John,

On Thu, May 30, 2013 at 09:11:17AM -0700, John Stultz wrote:
> On 05/29/2013 10:32 PM, Baruch Siach wrote:
> >On Tue, May 28, 2013 at 01:24:17PM -0700, John Stultz wrote:
> >>On 05/26/2013 05:12 AM, Baruch Siach wrote:
> >>>  static const struct of_device_id osctimer_ids[] __initconst = {
> >>>@@ -124,3 +135,10 @@ void __init dw_apb_timer_init(void)
> >>>   init_sched_clock();
> >>>  }
> >>>+
> >>>+#ifndef CONFIG_HAVE_SETUP_SCHED_CLOCK
> >>>+unsigned long long notrace sched_clock()
> >>>+{
> >>>+  return read_sched_clock() * sched_clock_mult;
> >>>+}
> >>>+#endif
> >>Also, can you try to condense the number of #ifndef
> >>CONFIG_HAVE_SETUP_SCHED_CLOCK checks to one, and consolidate the
> >>needed functions all in that one conditional?
> >Thanks for your comments. I'll rework the patch and resubmit.
> >
> >I've just noticed that I have a bigger problem. read_sched_clock() returns
> >u32, not u64. This means that in a rate of, say, 100MHz it will wrap around
> >after a little more than 40 seconds. Would it make sense to put ARM's 32 bin
> >sched_clock extension code (arch/arm/kernel/sched_clock.c) is a common place
> >(maybe drivers/clocksource), and use that? There seems to be nothing ARM
> >specific in this code, after all.
> 
> Yea, working out an actual generic sched_clock implementation is
> something I'd like to see done.
> 
> Though I'd really rather we not toss yet another chunk of
> infrastructure in the drivers/clocksource directory. Instead we
> should probably have a kernel/time/sched_clock.c.
> 
> Then its just the issue of tying that and the clocksource code
> together so you just register existing capable clocksources with a
> SCHED_CLOCK flag or via a different registration hook.
> 
> I don't think it will be an easy job, but if you want to give it a
> shot, I'd be quite interested in reviewing the patches!

Although I'd very much like to contribute in this area, I'm afraid I don't 
have time for this now. My problem is much narrower in scope, though, and I 
think it can be solved without a generic sched_clock implementation at first 
step. All I want is to use a 32 bit counter for sched_clock. The code enabling 
this is currently only available for ARM (arch/arm/kernel/sched_clock.c). 
Should this part of the code move to kernel/time/sched_clock.c?

baruch

-- 
 http://baruch.siach.name/blog/  ~. .~   Tk Open Systems
=}ooO--U--Ooo{=
   - bar...@tkos.co.il - tel: +972.2.679.5364, http://www.tkos.co.il -
--
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: skbuff: use _RET_IP_

[Joe Perches]

On Thu, 2013-05-30 at 18:11 -0700, Davidlohr Bueso wrote:
> On Thu, 2013-05-30 at 13:08 +0200, Bjørn Mork wrote:
> > Sergei Shtylyov  writes:
> > 
> > > Why not "text:%#lx" as already used in this string? It's
> > > equivalent to "0x%lx".
> > 
> > Well, I don't know the reasoning in this case, but I'd like to note that
> > those are not strictly equivalent.  Personally I find the formatting of 0
> > annoying enough to avoid %#x for any value which may be 0.  It's
> > especially bad if you try to line up things by adding leading zeros.
> 
> Yep, I found that 0x%lx produced the same output as %p.

Don't use a standalone gcc compiled program to
determine what the kernel outputs.

lib/vsprintf.c does not output the same. (32 bit)

The kernel output is;

printk("0x%lx\n", 0x100ul)  0x100
printk("%p\n", (void *)0x100ul) 0100
printk("%#p\n", (void *)0x100ul)0x0100

The last one isn't used at all in kernel source. (gcc complains)
It's always "0x%p"

--
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 0/5] Zynq: revised CCF code

[Michal Simek]

On 05/30/2013 08:44 PM, Mike Turquette wrote:
> Quoting Michal Simek (2013-05-17 05:14:47)
>> Hi Mike,
>>
>> I have sent email to Greg to take this patch from this series
>> though his serial tree because it is unrelated to this clock stuff.
>>
>> Can you please give me your ACK for these patches or add them
>> to your CLK tree?
>>
> 
> For the four clock-related patches:
> 
> Acked-by: Mike Turquette 

I have already sent pull request to Arnd and Olof.
Or is it you who should take these patches through your tree?

Thanks.
Michal


-- 
Michal Simek, Ing. (M.Eng), OpenPGP -> KeyID: FE3D1F91
w: www.monstr.eu p: +42-0-721842854
Maintainer of Linux kernel - Microblaze cpu - http://www.monstr.eu/fdt/
Maintainer of Linux kernel - Xilinx Zynq ARM architecture
Microblaze U-BOOT custodian and responsible for u-boot arm zynq platform




signature.asc
Description: OpenPGP digital signature

Re: [PATCH] backlight: Turn backlight on/off when necessary

[Jean-Christophe PLAGNIOL-VILLARD]

On 10:31 Fri 31 May , Liu Ying wrote:
>2013/5/30 Jean-Christophe PLAGNIOL-VILLARD 
> 
>  On 16:13 Thu 30 May , Liu Ying wrote:
>  > We don't have to turn backlight on/off everytime a blanking
>  > or unblanking event comes because the backlight status may have
>  > already been what we want. Another thought is that one backlight
>  > device may be shared by multiple framebuffers. We don't hope that
>  > blanking one of the framebuffers would turn the backlight off for
>  > all the other framebuffers, since they are likely active to show
>  > display content. This patch adds logic to record each framebuffer's
>  > backlight status to determine the backlight device use count and
>  > whether the backlight should be turned on or off.
>  >
>  > Signed-off-by: Liu Ying 
>  > ---
>  >  drivers/video/backlight/backlight.c |   23 +--
>  >  include/linux/backlight.h   |6 ++
>  >  2 files changed, 23 insertions(+), 6 deletions(-)
>  >
>  > diff --git a/drivers/video/backlight/backlight.c
>  b/drivers/video/backlight/backlight.c
>  > index c74e7aa..97ea2b8 100644
>  > --- a/drivers/video/backlight/backlight.c
>  > +++ b/drivers/video/backlight/backlight.c
>  > @@ -31,13 +31,14 @@ static const char *const backlight_types[] = {
>  >
>   defined(CONFIG_BACKLIGHT_CLASS_DEVICE_MODULE))
>  >  /* This callback gets called when something important happens inside
>  a
>  >   * framebuffer driver. We're looking if that important event is
>  blanking,
>  > - * and if it is, we're switching backlight power as well ...
>  > + * and if it is and necessary, we're switching backlight power as
>  well ...
>  >   */
>  >  static int fb_notifier_callback(struct notifier_block *self,
>  >   unsigned long event, void *data)
>  >  {
>  >   struct backlight_device *bd;
>  >   struct fb_event *evdata = data;
>  > + int node = evdata->info->node;
>  >
>  >   /* If we aren't interested in this event, skip it immediately
>  ... */
>  >   if (event != FB_EVENT_BLANK && event != FB_EVENT_CONBLANK)
>  > @@ -49,11 +50,21 @@ static int fb_notifier_callback(struct
>  notifier_block *self,
>  >   if (!bd->ops->check_fb ||
>  >   bd->ops->check_fb(bd, evdata->info)) {
>  >   bd->props.fb_blank = *(int *)evdata->data;
>  > - if (bd->props.fb_blank == FB_BLANK_UNBLANK)
>  > - bd->props.state &= ~BL_CORE_FBBLANK;
>  > - else
>  > - bd->props.state |= BL_CORE_FBBLANK;
>  > - backlight_update_status(bd);
>  > + if (bd->props.fb_blank == FB_BLANK_UNBLANK &&
>  > + !bd->fb_bl_on[node]) {
>  > + bd->fb_bl_on[node] = true;
>  > + if (!bd->use_count++) {
>  > + bd->props.state &=
>  ~BL_CORE_FBBLANK;
>  > + backlight_update_status(bd);
>  > + }
>  > + } else if (bd->props.fb_blank !=
>  FB_BLANK_UNBLANK &&
>  > +bd->fb_bl_on[node]) {
>  > + bd->fb_bl_on[node] = false;
>  > + if (!(--bd->use_count)) {
>  > + bd->props.state |=
>  BL_CORE_FBBLANK;
>  > + backlight_update_status(bd);
>  > + }
>  > + }
>  >   }
>  >   mutex_unlock(>ops_lock);
>  >   return 0;
>  > diff --git a/include/linux/backlight.h b/include/linux/backlight.h
>  > index da9a082..5de71a0 100644
>  > --- a/include/linux/backlight.h
>  > +++ b/include/linux/backlight.h
>  > @@ -9,6 +9,7 @@
>  >  #define _LINUX_BACKLIGHT_H
>  >
>  >  #include 
>  > +#include 
>  >  #include 
>  >  #include 
>  >
>  > @@ -101,6 +102,11 @@ struct backlight_device {
>  >   struct notifier_block fb_notif;
>  >
>  >   struct device dev;
>  > +
>  > + /* Multiple framebuffers may share one backlight device */
>  > + bool fb_bl_on[FB_MAX];
> 
>  I don't like such array at all
> 
>  I understand the fact you will have only on hw backlight for x fb or
>  overlay
>  but have a static on no
> 
> 
>My board has two LVDS display panels. They share one PWM backlight.
>The framebuffer HW engine may drive a background framebuffer and an
>overlay framebuffer on one panel, and only one background 

Re: [PATCH] powerpc/pci: Improve device hotplug initialization

[Guenter Roeck]

On Wed, May 29, 2013 at 05:30:41PM +0800, Chen Yuanquan-B41889 wrote:
> On 05/29/2013 01:35 AM, Guenter Roeck wrote:
> >bios_add_device(). Drop explicit calls to pcibios_setup_device();
> >this makes pcibios_setup_bus_devices() a noop function which could
> >eve
> 
> Yeah, it's more reasonable to do the irq and DMA related initialization
> in one code path for all devices.
> 
Any comments / feedback on the code itself ?

Thanks,
Guenter
--
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: Tree for May 31

[Stephen Rothwell]

Hi all,

Changes since 20130530:

The msm tree gained a build failure for which I applied a fix patch.



I have created today's linux-next tree at
git://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git
(patches at http://www.kernel.org/pub/linux/kernel/next/ ).  If you
are tracking the linux-next tree using git, you should not use "git pull"
to do so as that will try to merge the new linux-next release with the
old one.  You should use "git fetch" as mentioned in the FAQ on the wiki
(see below).

You can see which trees have been included by looking in the Next/Trees
file in the source.  There are also quilt-import.log and merge.log files
in the Next directory.  Between each merge, the tree was built with
a ppc64_defconfig for powerpc and an allmodconfig for x86_64. After the
final fixups (if any), it is also built with powerpc allnoconfig (32 and
64 bit), ppc44x_defconfig and allyesconfig (minus
CONFIG_PROFILE_ALL_BRANCHES - this fails its final link) and i386, sparc,
sparc64 and arm defconfig. These builds also have
CONFIG_ENABLE_WARN_DEPRECATED, CONFIG_ENABLE_MUST_CHECK and
CONFIG_DEBUG_INFO disabled when necessary.

Below is a summary of the state of the merge.

We are up to 227 trees (counting Linus' and 31 trees of patches pending
for Linus' tree), more are welcome (even if they are currently empty).
Thanks to those who have contributed, and to those who haven't, please do.

Status of my local build tests will be at
http://kisskb.ellerman.id.au/linux-next .  If maintainers want to give
advice about cross compilers/configs that work, we are always open to add
more builds.

Thanks to Randy Dunlap for doing many randconfig builds.  And to Paul
Gortmaker for triage and bug fixes.

There is a wiki covering stuff to do with linux-next at
http://linux.f-seidel.de/linux-next/pmwiki/ .  Thanks to Frank Seidel.

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

$ git checkout master
$ git reset --hard stable
Merging origin/master (3655b22 Merge tag 'stable/for-linus-3.10-rc3-tag' of 
git://git.kernel.org/pub/scm/linux/kernel/git/konrad/xen)
Merging fixes/master (0279b3c Merge branch 'sched-urgent-for-linus' of 
git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip)
Merging kbuild-current/rc-fixes (ad06156 kbuild: Don't assume dts files live in 
arch/*/boot/dts)
Merging arc-current/for-curr (e4aa937 Linux 3.10-rc3)
Merging arm-current/fixes (f27d6e1 ARM: 7729/1: vfp: ensure VFP_arch is 
non-zero when VFP is not supported)
Merging m68k-current/for-linus (37c14e8 m68k: Update defconfigs for v3.9)
Merging powerpc-merge/merge (f1dd153 powerpc/pseries: Make 32-bit MSI quirk 
work on systems lacking firmware support)
Merging sparc/master (de9c9f8 Merge tag 'remoteproc-3.10' of 
git://git.kernel.org/pub/scm/linux/kernel/git/ohad/remoteproc)
Merging net/master (8e6d91a tuntap: forbid changing mq flag for persistent 
device)
Merging ipsec/master (da241ef Merge 
git://git.kernel.org/pub/scm/linux/kernel/git/davem/net)
Merging sound-current/for-linus (8a90bb5 Merge tag 'asoc-v3.10-rc3' of 
git://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound into for-linus)
Merging pci-current/for-linus (f3f0117 Revert "x86/pci/mrst: Use configuration 
mechanism 1 for 00:00.0, 00:02.0, 00:03.0")
Merging wireless/master (f942d11 brcmsmac: fix regression observed in 3.10-rc1)
Merging driver-core.current/driver-core-linus (e4aa937 Linux 3.10-rc3)
Merging tty.current/tty-linus (e4aa937 Linux 3.10-rc3)
Merging usb.current/usb-linus (077f5f1 USB: EHCI: fix regression related to 
qh_refresh())
Merging staging.current/staging-linus (76554b8 drivers: staging: zcache: fix 
compile error)
Merging char-misc.current/char-misc-linus (e4aa937 Linux 3.10-rc3)
Merging input-current/for-linus (c73a1af Input: wacom - add an eraser to 
DTH2242/DTK2241)
Merging md-current/for-linus (32f9f57 MD: ignore discard request for hard disks 
of hybid raid1/raid10 array)
Merging audit-current/for-linus (c158a35 audit: no leading space in 
audit_log_d_path prefix)
Merging crypto-current/master (de614e5 crypto: sha256_ssse3 - fix stack 
corruption with SSSE3 and AVX implementations)
Merging ide/master (bf6b438 ide: gayle: use module_platform_driver_probe())
Merging dwmw2/master (5950f08 pcmcia: remove RPX board stuff)
Merging sh-current/sh-fixes-for-linus (4403310 SH: Convert out[bwl] macros to 
inline functions)
Merging irqdomain-current/irqdomain/merge (a0d271c Linux 3.6)
Merging devicetree-current/devicetree/merge (ab28698 of: define struct device 
in of_platform.h if !OF_DEVICE and !OF_ADDRESS)
Merging spi-current/spi/merge (0d2d0cc spi/davinci: fix module build error)
Merging gpio-current/gpio/merge (e97f9b5 gpio/gpio-ich: fix 
ichx_gpio_check_available() return what callers expect)
Merging rr-fixes/fixes (6407d75 virtio_console: fix uapi header)
Merging mfd-fixes/master (5649d8f mfd: ab8500-sysctrl: Let sysctrl drive

Re: race condition in schedule_on_each_cpu()

[Tejun Heo]

On Fri, May 31, 2013 at 12:07:15PM +0800, we...@kylinos.com.cn wrote:
> 
> >the only way for them to get stuck is if there aren't enough execution
> >resources (ie. if a new thread can't be created) but OOM killers would
> >have been activated if that were the case.
> 
> The following is a detailed description of our scenerio:
> 
> 1.  after turnning off the the disk array, the ps results is shown
> in *ps*, which indicates the kworker/1:0 kworker/1:2 are stuck
> 
> 2.  the call stack for the kworkers are shown in *stack_xxx.txt*
> 
> 3.  the workqueue operations during that period is shown in
> *out.txt*, use ftrace
> (we added a new trace point /workqueue_queue_work_insert/,
> immediately before insert_wq_barrier, in the function
> start_flush_work. its implementation is shown in
> *trace_insert_wq_barrier.txt*)
>from the results int *grep_kwork1:0_from_out.txt*, we can see:
>   kworker/1:0 is stuck after start work
> /fc_starget_delete/ at time 360.801271,  and  catch the
> insert_wq_barrier trace_info behind this
> 
> 
> 4.  from out.txt , we can see, there are altogether three
> /fc_starget_delete/ work enqueued.
>   atfer the point of deadlock, kworker/1:1 and kworker/1:3 is
> executing ...
> 
> 
> 5.  if we let the scsi_transport_fc uses only one worker thread,
> i.e.,  change scsi_transport_fc.c : fc_host_setup()
>   alloc_workqueue(fc_host->work_q_name, 0, 0) to
>  alloc_workqueue(fc_host->work_q_name, WQ_UNBOUND, 1)
> 
>   alloc_workqueue(fc_host->devloss_work_q_name, 0, 0) to
> alloc_workqueue(fc_host->devloss_work_q_name, WQ_UNBOUND, 1)
> 
>  the deadlock won't occur.
> >Can you please test a recent kernel?  How easily can you reproduce the
> >issue?
> >
> it's occured every time when hot remove disk array.
> 
> I'll test recent kernel after a while , but  this problem in 3.0.30
> really confused me

Yeah, it definitely sounds like concurrency depletion.  There have
been some fixes and substantial changes in the area, so I really wanna
find out whether the problem is reproducible in recent vanilla kernel
- say, v3.9 or, even better, v3.10-rc2.  Can you please try to
reproduce the problem with a newer kernel?

> by the way, I'm wondering about  what's the race condition before
> which  doesn't exist now

Before the commit you originally quoted, the calling thread could be
preempted and migrated to another CPU before get_online_cpus() thus
ending up executing the function twice on the new cpu but skipping the
old one.

Thanks.

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

linux-next: build failure after merge of the final tree (msm tree related)

[Stephen Rothwell]

Hi all,

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

drivers/gpio/gpio-msm-v2.c: In function 'msm_gpio_irq_domain_map':
drivers/gpio/gpio-msm-v2.c:373:2: error: implicit declaration of function 
'set_irq_flags' [-Werror=implicit-function-declaration]
  set_irq_flags(irq, IRQF_VALID);
  ^
drivers/gpio/gpio-msm-v2.c:373:21: error: 'IRQF_VALID' undeclared (first use in 
this function)
  set_irq_flags(irq, IRQF_VALID);
 ^
drivers/gpio/gpio-msm-v2.c:373:21: note: each undeclared identifier is reported 
only once for each function it appears in
drivers/gpio/gpio-msm-v2.c: In function 'msm_gpio_remove':
drivers/gpio/gpio-msm-v2.c:450:18: error: 'TLMM_SCSS_SUMMARY_IRQ' undeclared 
(first use in this function)
  irq_set_handler(TLMM_SCSS_SUMMARY_IRQ, NULL);
  ^

Caused by commit 69cf52b46b39 ("gpio: msm: Add device tree and irqdomain
support for gpio-msm-v2").

I applied the following patch for today:

From: Stephen Rothwell 
Date: Fri, 31 May 2013 14:54:00 +1000
Subject: [PATCH] restore dependency on ARCH_MSM to GPIO_MSM_V2

Signed-off-by: Stephen Rothwell 
---
 drivers/gpio/Kconfig | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpio/Kconfig b/drivers/gpio/Kconfig
index 2e4a21a..f471fe8 100644
--- a/drivers/gpio/Kconfig
+++ b/drivers/gpio/Kconfig
@@ -165,7 +165,7 @@ config GPIO_MSM_V1
 
 config GPIO_MSM_V2
tristate "Qualcomm MSM GPIO v2"
-   depends on GPIOLIB && OF
+   depends on GPIOLIB && OF && ARCH_MSM
help
  Say yes here to support the GPIO interface on ARM v7 based
  Qualcomm MSM chips.  Most of the pins on the MSM can be
-- 
1.8.1

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


pgpexpbTKd4gU.pgp
Description: PGP signature

Re: [PATCH] dma: mmp_pdma: fix a memory alloc error

[Xiang Wang]

2013/5/28 Andy Shevchenko :
> On Tue, May 28, 2013 at 3:05 PM, Xiang Wang  wrote:
>> From: Xiang Wang 
>>
>> pdev->phy is of type "struct mmp_pdma_phy *". But when
>> allocating memory for it, "struct mmp_pdma_chan" is used
>> by mistake.
>
> Have you tested it?
>
>> Signed-off-by: Xiang Wang 
>> ---
>>  drivers/dma/mmp_pdma.c |2 +-
>>  1 files changed, 1 insertions(+), 1 deletions(-)
>>
>> diff --git a/drivers/dma/mmp_pdma.c b/drivers/dma/mmp_pdma.c
>> index c26699f..76a8dcf 100644
>> --- a/drivers/dma/mmp_pdma.c
>> +++ b/drivers/dma/mmp_pdma.c
>> @@ -801,7 +801,7 @@ static int mmp_pdma_probe(struct platform_device *op)
>> }
>>
>> pdev->phy = devm_kzalloc(pdev->dev,
>> -   dma_channels * sizeof(struct mmp_pdma_chan), GFP_KERNEL);
>> +   dma_channels * sizeof(struct mmp_pdma_phy), GFP_KERNEL);
>
> For me it seems you did get how it works.
>
> --
> With Best Regards,
> Andy Shevchenko

Hi, Andy
Yes. I've tested on marvell pxa988 platform using dmatest.ko.
--
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, part3 06/14] mm, acornfb: use free_reserved_area() to simplify code

[Jiang Liu]

On Fri 31 May 2013 05:58:44 AM CST, Andrew Morton wrote:
> On Sun, 26 May 2013 21:38:34 +0800 Jiang Liu  wrote:
>
>> Use common help function free_reserved_area() to simplify code.
>
> http://ozlabs.org/~akpm/mmots/broken-out/drivers-video-acornfbc-remove-dead-code.patch
> removes all the code which your patch alters.
Thanks Andrew, please just drop that patch.

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

Re: [PATCH V3 4/4] microcode/x86/amd: early microcode patch loading support for AMD

[Henrique de Moraes Holschuh]

On Thu, 30 May 2013, Jacob Shin wrote:
>  mkdir initrd
>  cd initrd
> -mkdir kernel
> -mkdir kernel/x86
> -mkdir kernel/x86/microcode
> -cp ../microcode.bin kernel/x86/microcode/GenuineIntel.bin
> -find .|cpio -oc >../ucode.cpio
> +mkdir -p kernel/x86/microcode
> +cp ../microcode.bin kernel/x86/microcode/GenuineIntel.bin (or 
> AuthenticAMD.bin)

Can I just 
'cat /lib/firmware/amd-ucode/*bin >kernel/x86/microcode/AuthenticAMD.bin' 
to get a valid microcode container for all amd processors?

The answer for Intel is "yes".  I sure hope it is the same for AMD...

-- 
  "One disk to rule them all, One disk to find them. One disk to bring
  them all and in the darkness grind them. In the Land of Redmond
  where the shadows lie." -- The Silicon Valley Tarot
  Henrique Holschuh
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH v2 2/2] acer-wmi: add Acer Aspire 5750G to video vendor list but keep acpi video driver

[Lee, Chun-Yi]

After Andrzej's testing, we found the acpi backlight methods broken on Acer
Aspire 5750G but the i915 backlight control works when we set to vendor mode.
And, we still want to keep the acpi/video driver for transfer acpi event to key
event but not unregister whole acpi/video driver.

This patch introduced a new capability flag is ACER_CAP_KEEP_VIDEO_KEY, it
indicates the machine works fine with acpi/video driver for key event but want
to unregister the backlight interface of acpi/video.

Reference: bko#35622
https://bugzilla.kernel.org/show_bug.cgi?id=35622

v2: changed the information statement of keeping acpi video driver.

Tested-by: Andrzej Krentosz 
Cc: Zhang Rui 
Cc: Len Brown 
Cc: Carlos Corbacho 
Cc: Matthew Garrett 
Cc: Dmitry Torokhov 
Cc: Corentin Chary 
Cc: Rafael J. Wysocki 
Cc: Aaron Lu 
Cc: Thomas Renninger 
Signed-off-by: Lee, Chun-Yi 
---
 drivers/platform/x86/acer-wmi.c |   20 
 1 files changed, 20 insertions(+), 0 deletions(-)

diff --git a/drivers/platform/x86/acer-wmi.c b/drivers/platform/x86/acer-wmi.c
index c9076bd..a81c9ed 100644
--- a/drivers/platform/x86/acer-wmi.c
+++ b/drivers/platform/x86/acer-wmi.c
@@ -207,6 +207,7 @@ struct hotkey_function_type_aa {
 #define ACER_CAP_BRIGHTNESS(1<<3)
 #define ACER_CAP_THREEG(1<<4)
 #define ACER_CAP_ACCEL (1<<5)
+#define ACER_CAP_KEEP_VIDEO_KEY(1<<6)
 #define ACER_CAP_ANY   (0x)
 
 /*
@@ -539,6 +540,15 @@ static int video_set_backlight_video_vendor(const struct 
dmi_system_id *d)
return 0;
 }
 
+static int video_set_backlight_video_vendor_keep_acpi_video(
+   const struct dmi_system_id *d)
+{
+   video_set_backlight_video_vendor(d);
+   interface->capability |= ACER_CAP_KEEP_VIDEO_KEY;
+   pr_info("Keeping acpi video driver active to emit backlight brightness 
change key events\n");
+   return 0;
+}
+
 static const struct dmi_system_id video_vendor_dmi_table[] = {
{
.callback = video_set_backlight_video_vendor,
@@ -572,6 +582,14 @@ static const struct dmi_system_id video_vendor_dmi_table[] 
= {
DMI_MATCH(DMI_PRODUCT_NAME, "Aspire 5750"),
},
},
+   {
+   .callback = video_set_backlight_video_vendor_keep_acpi_video,
+   .ident = "Acer Aspire 5750G",
+   .matches = {
+   DMI_MATCH(DMI_BOARD_VENDOR, "Acer"),
+   DMI_MATCH(DMI_PRODUCT_NAME, "Aspire 5750G"),
+   },
+   },
{}
 };
 
@@ -2228,6 +2246,8 @@ static int __init acer_wmi_init(void)
if (acpi_video_backlight_support()) {
interface->capability &= ~ACER_CAP_BRIGHTNESS;
pr_info("Brightness must be controlled by acpi video driver\n");
+   } else if (interface->capability & ACER_CAP_KEEP_VIDEO_KEY) {
+   acpi_video_backlight_unregister();
} else {
pr_info("Disabling ACPI video driver\n");
acpi_video_unregister();
-- 
1.6.4.2

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

[PATCH v2 1/2] acpi: video: add function to support unregister backlight interface

[Lee, Chun-Yi]

There have some situation we unregister whole acpi/video driver by downstream
driver just want to remove backlight control interface of acpi/video. It caues
we lost other functions of acpi/video, e.g. transfer acpi event to input event.

So, this patch add a new function, find_video_unregister_backlight, it provide
the interface let downstream driver can tell acpi/video to unregister backlight
interface of all acpi video devices. Then we can keep functions of acpi/video
but only remove backlight support.

Reference: bko#35622
https://bugzilla.kernel.org/show_bug.cgi?id=35622

v2: Also unregister cooling devices.

Tested-by: Andrzej Krentosz 
Cc: Zhang Rui 
Cc: Len Brown 
Cc: Rafael J. Wysocki 
Cc: Carlos Corbacho 
Cc: Matthew Garrett 
Cc: Dmitry Torokhov 
Cc: Corentin Chary 
Cc: Aaron Lu 
Cc: Thomas Renninger 
Signed-off-by: Lee, Chun-Yi 
---
 drivers/acpi/video.c |   54 ++
 include/acpi/video.h |2 +
 2 files changed, 56 insertions(+), 0 deletions(-)

diff --git a/drivers/acpi/video.c b/drivers/acpi/video.c
index c3932d0..f21104d 100644
--- a/drivers/acpi/video.c
+++ b/drivers/acpi/video.c
@@ -1861,6 +1861,60 @@ static int __init intel_opregion_present(void)
return opregion;
 }
 
+static acpi_status
+find_video_unregister_backlight(acpi_handle handle, u32 lvl, void *context,
+   void **rv)
+{
+   struct acpi_device *acpi_dev;
+   struct acpi_video_bus *video;
+   struct acpi_video_device *dev, *next;
+
+   if (acpi_bus_get_device(handle, _dev))
+   return AE_OK;
+
+   if (!acpi_match_device_ids(acpi_dev, video_device_ids)) {
+   video = acpi_driver_data(acpi_dev);
+   acpi_video_bus_stop_devices(video);
+   mutex_lock(>device_list_lock);
+   list_for_each_entry_safe(dev, next, >video_device_list,
+   entry) {
+   if (dev->backlight) {
+   backlight_device_unregister(dev->backlight);
+   dev->backlight = NULL;
+   kfree(dev->brightness->levels);
+   kfree(dev->brightness);
+   }
+   if (dev->cooling_dev) {
+   sysfs_remove_link(>dev->dev.kobj,
+ "thermal_cooling");
+   
sysfs_remove_link(>cooling_dev->device.kobj,
+ "device");
+   
thermal_cooling_device_unregister(dev->cooling_dev);
+   dev->cooling_dev = NULL;
+   }
+   }
+   mutex_unlock(>device_list_lock);
+   acpi_video_bus_start_devices(video);
+   }
+   return AE_OK;
+}
+
+void acpi_video_backlight_unregister(void)
+{
+   if (!register_count) {
+   /*
+* If the acpi video bus is already unloaded, don't
+* unregister backlight of devices and return directly.
+*/
+   return;
+   }
+   acpi_walk_namespace(ACPI_TYPE_DEVICE, ACPI_ROOT_OBJECT,
+   ACPI_UINT32_MAX, find_video_unregister_backlight,
+   NULL, NULL, NULL);
+   return;
+}
+EXPORT_SYMBOL(acpi_video_backlight_unregister);
+
 int acpi_video_register(void)
 {
int result = 0;
diff --git a/include/acpi/video.h b/include/acpi/video.h
index 61109f2..1e810a1 100644
--- a/include/acpi/video.h
+++ b/include/acpi/video.h
@@ -19,11 +19,13 @@ struct acpi_device;
 #if (defined CONFIG_ACPI_VIDEO || defined CONFIG_ACPI_VIDEO_MODULE)
 extern int acpi_video_register(void);
 extern void acpi_video_unregister(void);
+extern void acpi_video_backlight_unregister(void);
 extern int acpi_video_get_edid(struct acpi_device *device, int type,
   int device_id, void **edid);
 #else
 static inline int acpi_video_register(void) { return 0; }
 static inline void acpi_video_unregister(void) { return; }
+static inline void acpi_video_backlight_unregister(void) { return; }
 static inline int acpi_video_get_edid(struct acpi_device *device, int type,
  int device_id, void **edid)
 {
-- 
1.6.4.2

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

Re: [PATCH] ACPI: Fix potential NULL pointer dereference in acpi_processor_add()

[Hanjun Guo]

On 2013-5-31 6:25, Greg Kroah-Hartman wrote:
> On Thu, May 30, 2013 at 03:57:58PM +0200, Rafael J. Wysocki wrote:
>> On Thursday, May 30, 2013 10:29:54 AM Hanjun Guo wrote:
>>> On 2013-5-29 19:07, Martin Mokrejs wrote:
 Hanjun Guo wrote:
> On 2013-5-29 7:30, Rafael J. Wysocki wrote:
>> On Thursday, May 23, 2013 08:44:26 PM Hanjun Guo wrote:
>>> In acpi_processor_add(), get_cpu_device() will return NULL sometimes,
>>> although the chances are small, I think it should be fixed.
>>>
>>> Signed-off-by: Hanjun Guo 
>>
>> This patch isn't necessary any more after the changes queued up for 3.11
>> in the acpi-hotplug branch of the linux-pm.git tree.
>
> Ok, I noticed your patch set, just drop my patch.

 But shouldn't this go to stable at least? I checked linux-3.9.4
 and it applies fine. Whether this is relevant for other stable
 series I will leave up to somebody else. ;)
>>>
>>> Hi Rafeal,
>>>
>>> What's your opinion on Martin's suggestion?
>>
>> Well, this is kind of hard to say.  We generally don't apply patches to 
>> -stable
>> that don't have mainline counterparts.
>>
>> Greg, I wonder what your opinion is?
> 
> We do not apply patches to -stable that are not in Linus's tree, unless
> there is no problem in Linus's tree due to a major rewrite of the code,
> and it has been confirmed that the same problem isn't there.

Hi Rafael,

I found that the problem is still there in your acpi-hotplug tree, sorry for
I didn't noticed early. I made a patch for this again, I hope it will make
sense to you.

The patch is attached, based on your acpi-hotplug tree.

Thanks
Hanjun



>From 975e30f5906a883e533e4226d8eca1c449c7366b Mon Sep 17 00:00:00 2001
From: Hanjun Guo 
Date: Fri, 31 May 2013 11:36:08 +0800
Subject: [PATCH 1/1] ACPI / processor: Fix potential NULL pointer dereference
 in acpi_processor_add()

In acpi_processor_add(), get_cpu_device() will return NULL in some cases,
and ACPI_HANDLE_SET() just use the return dev directly, this will case a
potential NULL pointer dereference, fix it.

Signed-off-by: Hanjun Guo 
---
 drivers/acpi/acpi_processor.c |5 +
 1 file changed, 5 insertions(+)

diff --git a/drivers/acpi/acpi_processor.c b/drivers/acpi/acpi_processor.c
index 587d2af..4466b36 100644
--- a/drivers/acpi/acpi_processor.c
+++ b/drivers/acpi/acpi_processor.c
@@ -389,6 +389,11 @@ static int __cpuinit acpi_processor_add(struct acpi_device 
*device,
per_cpu(processor_device_array, pr->id) = device;
 
dev = get_cpu_device(pr->id);
+   if (!dev) {
+   result = -ENODEV;
+   goto err;
+   }
+
ACPI_HANDLE_SET(dev, pr->handle);
result = acpi_bind_one(dev, NULL);
if (result)
-- 
1.7.9.5

Re: A bug about system call on ARM

[Nicolas Pitre]

On Thu, 30 May 2013, Will Deacon wrote:

> On Thu, May 30, 2013 at 10:09:49AM +0100, Will Deacon wrote:
> > On Thu, May 30, 2013 at 02:41:42AM +0100, Wang, Yalin wrote:
> > > If you have some patch for this issue,
> > > I can do the test for it .
> > 
> > I'll have a look at cooking something which uses an exception table entry
> > to rewind the PC and retry the system call. That's simpler than directly
> > injecting a user page fault from the system call path.
> 
> Ok, please can you try the following?
> 
> Will
> 
> --->8
> 
> diff --git a/arch/arm/kernel/entry-common.S b/arch/arm/kernel/entry-common.S
> index bc5bc0a..855926e 100644
> --- a/arch/arm/kernel/entry-common.S
> +++ b/arch/arm/kernel/entry-common.S
> @@ -361,6 +361,15 @@ ENTRY(vector_swi)
>   str r8, [sp, #S_PSR]@ Save CPSR
>   str r0, [sp, #S_OLD_R0] @ Save OLD_R0
>   zero_fp
> + enable_irq
> + ct_user_exit
> +
> +#ifdef CONFIG_ALIGNMENT_TRAP
> + ldr ip, __cr_alignment
> + ldr ip, [ip]
> + mcr p15, 0, ip, c1, c0  @ update control register
> +#endif

This is wrong.  you must set up the align bit in the control register 
_before_ enabling IRQs or an IRQ handler might run without alignment 
fixup.

Otherwise the patch looks good to me.


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

Re: [PATCH v3 3/9] drm: Update drm_addmap and drm_mmap to use PAT WC instead of MTRRs

[Dave Airlie]

On Tue, May 14, 2013 at 9:58 AM, Andy Lutomirski  wrote:
> Previously, DRM_FRAME_BUFFER mappings, as well as DRM_REGISTERS
> mappings with DRM_WRITE_COMBINING set, resulted in an unconditional
> MTRR being added but the actual mappings being created as UC-.
>
> Now these mappings have the MTRR added only if needed, but they will
> be mapped with pgprot_writecombine.
>
> The non-WC DRM_REGISTERS case now uses pgprot_noncached instead of
> hardcoding the bit twiddling.
>
> The DRM_AGP case is unchanged for now.

Just FYI this breaks on powerpc build, I've fixed it up and pushed the
fixed version to
drm-next-staging, I'll push that to drm-next in a couple of days, once
kbuild robot hits it.

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/

Re: [PATCH v7 net-next 4/5] ixgbe: Add support for ndo_ll_poll

[Cong Wang]

On Thu, May 30, 2013 at 7:41 PM, Eliezer Tamir
 wrote:

> +#else /* CONFIG_NET_LL_RX_POLL */
> +static inline void ixgbe_qv_init_lock(struct ixgbe_q_vector *q_vector)
> +{
> +}
> +
> +static inline int ixgbe_qv_lock_napi(struct ixgbe_q_vector *q_vector)
> +{
> +   return true;
> +}
> +
> +static inline int ixgbe_qv_unlock_napi(struct ixgbe_q_vector *q_vector)
> +{
> +   return false;
> +}
> +
> +static inline int ixgbe_qv_lock_poll(struct ixgbe_q_vector *q_vector)
> +{
> +   return false;
> +}
> +
> +static inline int ixgbe_qv_unlock_poll(struct ixgbe_q_vector *q_vector)
> +{
> +   return false;
> +}
> +
> +static inline int ixgbe_qv_ll_polling(struct ixgbe_q_vector *q_vector)
> +{
> +   return false;
> +}


Then please make them bool.
--
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/microcode] x86, microcode, amd: Early microcode patch loading support for AMD

[tip-bot for Jacob Shin]

Commit-ID:  757885e94a22bcc82beb9b1445c95218cb20ceab
Gitweb: http://git.kernel.org/tip/757885e94a22bcc82beb9b1445c95218cb20ceab
Author: Jacob Shin 
AuthorDate: Thu, 30 May 2013 14:09:19 -0500
Committer:  H. Peter Anvin 
CommitDate: Thu, 30 May 2013 20:19:25 -0700

x86, microcode, amd: Early microcode patch loading support for AMD

Add early microcode patch loading support for AMD.

Signed-off-by: Jacob Shin 
Link: 
http://lkml.kernel.org/r/1369940959-2077-5-git-send-email-jacob.s...@amd.com
Signed-off-by: H. Peter Anvin 
Cc: Fenghua Yu 
---
 Documentation/x86/early-microcode.txt  |  11 +-
 arch/x86/Kconfig   |  14 ++-
 arch/x86/include/asm/microcode_amd.h   |  14 +++
 arch/x86/kernel/Makefile   |   1 +
 arch/x86/kernel/microcode_amd.c|  22 
 arch/x86/kernel/microcode_amd_early.c  | 222 +
 arch/x86/kernel/microcode_core_early.c |  43 ++-
 7 files changed, 310 insertions(+), 17 deletions(-)

diff --git a/Documentation/x86/early-microcode.txt 
b/Documentation/x86/early-microcode.txt
index 4aaf0df..d62bea6 100644
--- a/Documentation/x86/early-microcode.txt
+++ b/Documentation/x86/early-microcode.txt
@@ -11,7 +11,8 @@ file and loaded to CPUs during boot time.
 The format of the combined initrd image is microcode in cpio format followed by
 the initrd image (maybe compressed). Kernel parses the combined initrd image
 during boot time. The microcode file in cpio name space is:
-kernel/x86/microcode/GenuineIntel.bin
+on Intel: kernel/x86/microcode/GenuineIntel.bin
+on AMD  : kernel/x86/microcode/AuthenticAMD.bin
 
 During BSP boot (before SMP starts), if the kernel finds the microcode file in
 the initrd file, it parses the microcode and saves matching microcode in 
memory.
@@ -34,10 +35,8 @@ original initrd image /boot/initrd-3.5.0.img.
 
 mkdir initrd
 cd initrd
-mkdir kernel
-mkdir kernel/x86
-mkdir kernel/x86/microcode
-cp ../microcode.bin kernel/x86/microcode/GenuineIntel.bin
-find .|cpio -oc >../ucode.cpio
+mkdir -p kernel/x86/microcode
+cp ../microcode.bin kernel/x86/microcode/GenuineIntel.bin (or AuthenticAMD.bin)
+find . | cpio -o -H newc >../ucode.cpio
 cd ..
 cat ucode.cpio /boot/initrd-3.5.0.img >/boot/initrd-3.5.0.ucode.img
diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig
index 685692c..28dba52 100644
--- a/arch/x86/Kconfig
+++ b/arch/x86/Kconfig
@@ -1058,8 +1058,16 @@ config MICROCODE_INTEL_LIB
depends on MICROCODE_INTEL
 
 config MICROCODE_INTEL_EARLY
+   def_bool n
+
+config MICROCODE_AMD_EARLY
+   def_bool n
+
+config MICROCODE_EARLY
bool "Early load microcode"
-   depends on MICROCODE_INTEL && BLK_DEV_INITRD
+   depends on (MICROCODE_INTEL || MICROCODE_AMD) && BLK_DEV_INITRD
+   select MICROCODE_INTEL_EARLY if MICROCODE_INTEL
+   select MICROCODE_AMD_EARLY if MICROCODE_AMD
default y
help
  This option provides functionality to read additional microcode data
@@ -1067,10 +1075,6 @@ config MICROCODE_INTEL_EARLY
  microcode to CPU's as early as possible. No functional change if no
  microcode data is glued to the initrd, therefore it's safe to say Y.
 
-config MICROCODE_EARLY
-   def_bool y
-   depends on MICROCODE_INTEL_EARLY
-
 config X86_MSR
tristate "/dev/cpu/*/msr - Model-specific register support"
---help---
diff --git a/arch/x86/include/asm/microcode_amd.h 
b/arch/x86/include/asm/microcode_amd.h
index a57d9b7..24254aa 100644
--- a/arch/x86/include/asm/microcode_amd.h
+++ b/arch/x86/include/asm/microcode_amd.h
@@ -61,4 +61,18 @@ extern int __apply_microcode_amd(struct microcode_amd 
*mc_amd);
 extern int apply_microcode_amd(int cpu);
 extern enum ucode_state load_microcode_amd(int cpu, const u8 *data, size_t 
size);
 
+#ifdef CONFIG_MICROCODE_AMD_EARLY
+#ifdef CONFIG_X86_32
+#define MPB_MAX_SIZE PAGE_SIZE
+extern u8 __cpuinitdata amd_bsp_mpb[MPB_MAX_SIZE];
+#endif
+extern void __init load_ucode_amd_bsp(void);
+extern void __cpuinit load_ucode_amd_ap(void);
+extern int __init save_microcode_in_initrd_amd(void);
+#else
+static inline void __init load_ucode_amd_bsp(void) {}
+static inline void __cpuinit load_ucode_amd_ap(void) {}
+static inline int __init save_microcode_in_initrd_amd(void) { return -EINVAL; }
+#endif
+
 #endif /* _ASM_X86_MICROCODE_AMD_H */
diff --git a/arch/x86/kernel/Makefile b/arch/x86/kernel/Makefile
index 7bd3bd3..6c3fcea 100644
--- a/arch/x86/kernel/Makefile
+++ b/arch/x86/kernel/Makefile
@@ -93,6 +93,7 @@ obj-$(CONFIG_MICROCODE_INTEL_LIB) += microcode_intel_lib.o
 microcode-y:= microcode_core.o
 microcode-$(CONFIG_MICROCODE_INTEL)+= microcode_intel.o
 microcode-$(CONFIG_MICROCODE_AMD)  += microcode_amd.o
+obj-$(CONFIG_MICROCODE_AMD_EARLY)  += microcode_amd_early.o
 obj-$(CONFIG_MICROCODE)+= microcode.o
 
 obj-$(CONFIG_X86_CHECK_BIOS_CORRUPTION) += check.o
diff --git a/arch/x86/kernel/microcode_amd.c 

[tip:x86/microcode] x86, microcode, amd: Refactor functions to prepare for early loading

[tip-bot for Jacob Shin]

Commit-ID:  a76096a6571d5389376753c2e18b30a9791fa072
Gitweb: http://git.kernel.org/tip/a76096a6571d5389376753c2e18b30a9791fa072
Author: Jacob Shin 
AuthorDate: Thu, 30 May 2013 14:09:18 -0500
Committer:  H. Peter Anvin 
CommitDate: Thu, 30 May 2013 20:19:25 -0700

x86, microcode, amd: Refactor functions to prepare for early loading

In preparation work for early loading, refactor some common functions
that will be shared, and move some struct defines to a common header file.

Signed-off-by: Jacob Shin 
Link: 
http://lkml.kernel.org/r/1369940959-2077-4-git-send-email-jacob.s...@amd.com
Signed-off-by: H. Peter Anvin 
Cc: Fenghua Yu 
---
 arch/x86/include/asm/microcode_amd.h |  64 
 arch/x86/kernel/microcode_amd.c  | 111 +--
 2 files changed, 106 insertions(+), 69 deletions(-)

diff --git a/arch/x86/include/asm/microcode_amd.h 
b/arch/x86/include/asm/microcode_amd.h
new file mode 100644
index 000..a57d9b7
--- /dev/null
+++ b/arch/x86/include/asm/microcode_amd.h
@@ -0,0 +1,64 @@
+#ifndef _ASM_X86_MICROCODE_AMD_H
+#define _ASM_X86_MICROCODE_AMD_H
+
+#include 
+
+#define UCODE_MAGIC0x00414d44
+#define UCODE_EQUIV_CPU_TABLE_TYPE 0x
+#define UCODE_UCODE_TYPE   0x0001
+
+#define SECTION_HDR_SIZE   8
+#define CONTAINER_HDR_SZ   12
+
+struct equiv_cpu_entry {
+   u32 installed_cpu;
+   u32 fixed_errata_mask;
+   u32 fixed_errata_compare;
+   u16 equiv_cpu;
+   u16 res;
+} __attribute__((packed));
+
+struct microcode_header_amd {
+   u32 data_code;
+   u32 patch_id;
+   u16 mc_patch_data_id;
+   u8  mc_patch_data_len;
+   u8  init_flag;
+   u32 mc_patch_data_checksum;
+   u32 nb_dev_id;
+   u32 sb_dev_id;
+   u16 processor_rev_id;
+   u8  nb_rev_id;
+   u8  sb_rev_id;
+   u8  bios_api_rev;
+   u8  reserved1[3];
+   u32 match_reg[8];
+} __attribute__((packed));
+
+struct microcode_amd {
+   struct microcode_header_amd hdr;
+   unsigned intmpb[0];
+};
+
+static inline u16 find_equiv_id(struct equiv_cpu_entry *equiv_cpu_table,
+   unsigned int sig)
+{
+   int i = 0;
+
+   if (!equiv_cpu_table)
+   return 0;
+
+   while (equiv_cpu_table[i].installed_cpu != 0) {
+   if (sig == equiv_cpu_table[i].installed_cpu)
+   return equiv_cpu_table[i].equiv_cpu;
+
+   i++;
+   }
+   return 0;
+}
+
+extern int __apply_microcode_amd(struct microcode_amd *mc_amd);
+extern int apply_microcode_amd(int cpu);
+extern enum ucode_state load_microcode_amd(int cpu, const u8 *data, size_t 
size);
+
+#endif /* _ASM_X86_MICROCODE_AMD_H */
diff --git a/arch/x86/kernel/microcode_amd.c b/arch/x86/kernel/microcode_amd.c
index efdec7c..8f11f8f 100644
--- a/arch/x86/kernel/microcode_amd.c
+++ b/arch/x86/kernel/microcode_amd.c
@@ -31,48 +31,12 @@
 #include 
 #include 
 #include 
+#include 
 
 MODULE_DESCRIPTION("AMD Microcode Update Driver");
 MODULE_AUTHOR("Peter Oruba");
 MODULE_LICENSE("GPL v2");
 
-#define UCODE_MAGIC0x00414d44
-#define UCODE_EQUIV_CPU_TABLE_TYPE 0x
-#define UCODE_UCODE_TYPE   0x0001
-
-struct equiv_cpu_entry {
-   u32 installed_cpu;
-   u32 fixed_errata_mask;
-   u32 fixed_errata_compare;
-   u16 equiv_cpu;
-   u16 res;
-} __attribute__((packed));
-
-struct microcode_header_amd {
-   u32 data_code;
-   u32 patch_id;
-   u16 mc_patch_data_id;
-   u8  mc_patch_data_len;
-   u8  init_flag;
-   u32 mc_patch_data_checksum;
-   u32 nb_dev_id;
-   u32 sb_dev_id;
-   u16 processor_rev_id;
-   u8  nb_rev_id;
-   u8  sb_rev_id;
-   u8  bios_api_rev;
-   u8  reserved1[3];
-   u32 match_reg[8];
-} __attribute__((packed));
-
-struct microcode_amd {
-   struct microcode_header_amd hdr;
-   unsigned intmpb[0];
-};
-
-#define SECTION_HDR_SIZE   8
-#define CONTAINER_HDR_SZ   12
-
 static struct equiv_cpu_entry *equiv_cpu_table;
 
 struct ucode_patch {
@@ -84,21 +48,10 @@ struct ucode_patch {
 
 static LIST_HEAD(pcache);
 
-static u16 find_equiv_id(unsigned int cpu)
+static u16 __find_equiv_id(unsigned int cpu)
 {
struct ucode_cpu_info *uci = ucode_cpu_info + cpu;
-   int i = 0;
-
-   if (!equiv_cpu_table)
-   return 0;
-
-   while (equiv_cpu_table[i].installed_cpu != 0) {
-   if (uci->cpu_sig.sig == equiv_cpu_table[i].installed_cpu)
-   return equiv_cpu_table[i].equiv_cpu;
-
-   i++;
-   }
-   return 0;
+   return find_equiv_id(equiv_cpu_table, uci->cpu_sig.sig);
 }
 
 static u32 find_cpu_family_by_equiv_cpu(u16 

Re: [regression, bisected] x86: efi: Pass boot services variable info to runtime code

[joeyli]

於 四，2013-05-30 於 21:17 -0500，Russ Anderson 提到：
> On Fri, May 31, 2013 at 12:30:43AM +0200, Jiri Kosina wrote:
> > On Thu, 30 May 2013, Russ Anderson wrote:
> > 
> > > > > That's a great idea.  This patch moves the QueryVariableInfo()
> > > > > call from bootime to runtime, in efi_late_init().  The attached
> > > > > patch is consistent with the UEFI spec and avoids the problem.
> > > > 
> > > > No, that defeats the entire point of the original patch.
> > > 
> > > How so?  It is still calling QueryVariableInfo()
> > > before the data is used.
> > 
> > You lose information provided by QueryVariableInfo() about boot-only 
> > variables once the transition boot -> runtime has happened.
> 
> Is that information really more important than the ability
> to boot?
> 
> Correct me if I'm wrong, but linux was able to boot without
> the boottime QueryVariableInfo() call up until 3.9-rc7,
> and it still does on systems that do not use EFI stubs (ie
> grub and elilo).  It is only when linux uses EFI stubs (ie
> grub2) that linux makes the boottime QueryVariableInfo()
> call.  So why is that call, or whatever is dependent on it,
> more important than booting?
> 
> 
> 
> Thanks,

It related to BIOS's garbage collection behavior of UEFI variable
storage.

The used space of non volatile boottime variables is useful to us for
calculate the active_size, please reference 31ff2f2 patch:

https://lkml.org/lkml/2013/4/15/476

An earlier 68d9298 patch to avoid some machines bricked when more than
50% of the system flash is in use, because the garbage collection will
not trigger on those machines.

We need find out the size of system flash space indeed usage for avoid
this problem. So, cc5a080c5 patch call QueryVariableInfo() to grab the
usage information in boot time.

Calling QueryVariableInfo() at boot time should not causes side effect
until your issue show up. Before this issue happen, avoid bricking some
machines is also important.


Thanks a lot!
Joey Lee

--
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/microcode] x86, microcode: Vendor abstract out save_microcode_in_initrd()

[tip-bot for Jacob Shin]

Commit-ID:  f2b3ee820a9f2368d7f8842ad7da062dfe86e199
Gitweb: http://git.kernel.org/tip/f2b3ee820a9f2368d7f8842ad7da062dfe86e199
Author: Jacob Shin 
AuthorDate: Thu, 30 May 2013 14:09:17 -0500
Committer:  H. Peter Anvin 
CommitDate: Thu, 30 May 2013 20:19:25 -0700

x86, microcode: Vendor abstract out save_microcode_in_initrd()

Currently save_microcode_in_initrd() is declared in vendor neutural
microcode.h file, but defined in vendor specific
microcode_intel_early.c file. Vendor abstract it out to
microcode_core_early.c with a wrapper function.

Signed-off-by: Jacob Shin 
Link: 
http://lkml.kernel.org/r/1369940959-2077-3-git-send-email-jacob.s...@amd.com
Signed-off-by: H. Peter Anvin 
Cc: Fenghua Yu 
---
 arch/x86/include/asm/microcode_intel.h  |  2 ++
 arch/x86/kernel/microcode_core_early.c  | 10 ++
 arch/x86/kernel/microcode_intel_early.c |  2 +-
 3 files changed, 13 insertions(+), 1 deletion(-)

diff --git a/arch/x86/include/asm/microcode_intel.h 
b/arch/x86/include/asm/microcode_intel.h
index 5356f92..87a0853 100644
--- a/arch/x86/include/asm/microcode_intel.h
+++ b/arch/x86/include/asm/microcode_intel.h
@@ -67,10 +67,12 @@ update_match_revision(struct microcode_header_intel 
*mc_header, int rev);
 extern void __init load_ucode_intel_bsp(void);
 extern void __cpuinit load_ucode_intel_ap(void);
 extern void show_ucode_info_early(void);
+extern int __init save_microcode_in_initrd_intel(void);
 #else
 static inline __init void load_ucode_intel_bsp(void) {}
 static inline __cpuinit void load_ucode_intel_ap(void) {}
 static inline void show_ucode_info_early(void) {}
+static inline int __init save_microcode_in_initrd_intel(void) { return 
-EINVAL; }
 #endif
 
 #if defined(CONFIG_MICROCODE_INTEL_EARLY) && defined(CONFIG_HOTPLUG_CPU)
diff --git a/arch/x86/kernel/microcode_core_early.c 
b/arch/x86/kernel/microcode_core_early.c
index 833d51d..0d19ac5 100644
--- a/arch/x86/kernel/microcode_core_early.c
+++ b/arch/x86/kernel/microcode_core_early.c
@@ -98,3 +98,13 @@ void __cpuinit load_ucode_ap(void)
if (vendor == X86_VENDOR_INTEL && x86 >= 6)
load_ucode_intel_ap();
 }
+
+int __init save_microcode_in_initrd(void)
+{
+   struct cpuinfo_x86 *c = _cpu_data;
+
+   if (c->x86_vendor == X86_VENDOR_INTEL && c->x86 >= 6)
+   return save_microcode_in_initrd_intel();
+
+   return 0;
+}
diff --git a/arch/x86/kernel/microcode_intel_early.c 
b/arch/x86/kernel/microcode_intel_early.c
index a07f0a0..dabef95 100644
--- a/arch/x86/kernel/microcode_intel_early.c
+++ b/arch/x86/kernel/microcode_intel_early.c
@@ -699,7 +699,7 @@ static int __cpuinit apply_microcode_early(struct 
mc_saved_data *mc_saved_data,
  * This function converts microcode patch offsets previously stored in
  * mc_saved_in_initrd to pointers and stores the pointers in mc_saved_data.
  */
-int __init save_microcode_in_initrd(void)
+int __init save_microcode_in_initrd_intel(void)
 {
unsigned int count = mc_saved_data.mc_saved_count;
struct microcode_intel *mc_saved[MAX_UCODE_COUNT];
--
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: A bug about system call on ARM

[Wang, Yalin]

Hi Will,

Thanks for your patch ,

But I found  I don't have ct_user_exit  macro 
In my arch/arm/kernel/entry-common.S 

My kernel version is 3.4.0 

I have add the file as attachment,

Could you make a patch for this file ?

Thank you !

-Original Message-
From: Will Deacon [mailto:will.dea...@arm.com] 
Sent: Thursday, May 30, 2013 7:41 PM
To: Wang, Yalin
Cc: 'richard -rw- weinberger'; 'linux-a...@vger.kernel.org'; 
'linux-kernel@vger.kernel.org'; 'linux-arm-ker...@lists.infradead.org'
Subject: Re: A bug about system call on ARM

On Thu, May 30, 2013 at 10:09:49AM +0100, Will Deacon wrote:
> On Thu, May 30, 2013 at 02:41:42AM +0100, Wang, Yalin wrote:
> > If you have some patch for this issue, I can do the test for it .
> 
> I'll have a look at cooking something which uses an exception table 
> entry to rewind the PC and retry the system call. That's simpler than 
> directly injecting a user page fault from the system call path.

Ok, please can you try the following?

Will

--->8

diff --git a/arch/arm/kernel/entry-common.S b/arch/arm/kernel/entry-common.S 
index bc5bc0a..855926e 100644
--- a/arch/arm/kernel/entry-common.S
+++ b/arch/arm/kernel/entry-common.S
@@ -361,6 +361,15 @@ ENTRY(vector_swi)
str r8, [sp, #S_PSR]@ Save CPSR
str r0, [sp, #S_OLD_R0] @ Save OLD_R0
zero_fp
+   enable_irq
+   ct_user_exit
+
+#ifdef CONFIG_ALIGNMENT_TRAP
+   ldr ip, __cr_alignment
+   ldr ip, [ip]
+   mcr p15, 0, ip, c1, c0  @ update control register
+#endif
+   get_thread_info tsk
 
/*
 * Get the system call number.
@@ -375,9 +384,9 @@ ENTRY(vector_swi)
 #ifdef CONFIG_ARM_THUMB
tst r8, #PSR_T_BIT
movne   r10, #0 @ no thumb OABI emulation
-   ldreq   r10, [lr, #-4]  @ get SWI instruction
+ USER( ldreq   r10, [lr, #-4]  )   @ get SWI instruction
 #else
-   ldr r10, [lr, #-4]  @ get SWI instruction
+ USER( ldr r10, [lr, #-4]  )   @ get SWI instruction
 #endif
 #ifdef CONFIG_CPU_ENDIAN_BE8
rev r10, r10@ little endian instruction
@@ -392,22 +401,13 @@ ENTRY(vector_swi)
/* Legacy ABI only, possibly thumb mode. */
tst r8, #PSR_T_BIT  @ this is SPSR from 
save_user_regs
addne   scno, r7, #__NR_SYSCALL_BASE@ put OS number in
-   ldreq   scno, [lr, #-4]
+ USER( ldreq   scno, [lr, #-4] )
 
 #else
/* Legacy ABI only. */
-   ldr scno, [lr, #-4] @ get SWI instruction
-#endif
-
-#ifdef CONFIG_ALIGNMENT_TRAP
-   ldr ip, __cr_alignment
-   ldr ip, [ip]
-   mcr p15, 0, ip, c1, c0  @ update control register
+ USER( ldr scno, [lr, #-4] )   @ get SWI instruction
 #endif
-   enable_irq
-   ct_user_exit
 
-   get_thread_info tsk
adr tbl, sys_call_table @ load syscall table pointer
 
 #if defined(CONFIG_OABI_COMPAT)
@@ -442,6 +442,18 @@ local_restart:
eor r0, scno, #__NR_SYSCALL_BASE@ put OS number back
bcs arm_syscall 
b   sys_ni_syscall  @ not private func
+
+#if defined(CONFIG_OABI_COMPAT) || !defined(CONFIG_AEABI)
+   /*
+* We may have faulted trying to load the SWI instruction due to
+* concurrent page aging on another CPU. In this case, return
+* back to the swi instruction and fault the page back.
+*/
+9001:
+   sub lr, lr, #4
+   str lr, [sp, #S_PC]
+   b   ret_fast_syscall
+#endif
 ENDPROC(vector_swi)
 
/*


entry-common.S
Description: entry-common.S

[tip:x86/microcode] x86, microcode, intel: Correct typo in printk

[tip-bot for Borislav Petkov]

Commit-ID:  83b325f1b4d00035494bc18a7a131b2197b3c718
Gitweb: http://git.kernel.org/tip/83b325f1b4d00035494bc18a7a131b2197b3c718
Author: Borislav Petkov 
AuthorDate: Thu, 30 May 2013 14:09:16 -0500
Committer:  H. Peter Anvin 
CommitDate: Thu, 30 May 2013 20:19:25 -0700

x86, microcode, intel: Correct typo in printk

User-visible so correct it.

Signed-off-by: Borislav Petkov 
Link: 
http://lkml.kernel.org/r/1369940959-2077-2-git-send-email-jacob.s...@amd.com
Signed-off-by: Jacob Shin 
Signed-off-by: H. Peter Anvin 
Cc: Fenghua Yu 
---
 arch/x86/kernel/microcode_intel_early.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/arch/x86/kernel/microcode_intel_early.c 
b/arch/x86/kernel/microcode_intel_early.c
index 2e9e128..a07f0a0 100644
--- a/arch/x86/kernel/microcode_intel_early.c
+++ b/arch/x86/kernel/microcode_intel_early.c
@@ -529,7 +529,7 @@ int save_mc_for_early(u8 *mc)
 */
ret = save_microcode(_saved_data, mc_saved_tmp, mc_saved_count);
if (ret) {
-   pr_err("Can not save microcode patch.\n");
+   pr_err("Cannot save microcode patch.\n");
goto out;
}
 
@@ -711,7 +711,7 @@ int __init save_microcode_in_initrd(void)
microcode_pointer(mc_saved, mc_saved_in_initrd, initrd_start, count);
ret = save_microcode(_saved_data, mc_saved, count);
if (ret)
-   pr_err("Can not save microcod patches from initrd");
+   pr_err("Cannot save microcode patches from initrd.\n");
 
show_saved_mc();
 
--
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/3.9] ipv6: ndisc: fix ndisc_send_redirect writing to the wrong skb

[Cong Wang]

On Fri, May 31, 2013 at 9:27 AM, Matthias Schiffer
 wrote:
> Since some refactoring in 5f5a011, ndisc_send_redirect called
> ndisc_fill_redirect_hdr_option on the wrong skb, leading to data corruption or
> in the worst case a panic when the skb_put failed.
>
> Signed-off-by: Matthias Schiffer 


Good catch!

Reviewed-by: Cong Wang 
--
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 v3 0/9] Clean up write-combining MTRR addition

[Dave Airlie]

On Fri, May 24, 2013 at 4:35 AM, Andy Lutomirski  wrote:
> On Mon, May 13, 2013 at 4:58 PM, Andy Lutomirski  wrote:
>> A fair number of drivers (mostly graphics) add write-combining MTRRs.
>> Most ignore errors and most add the MTRR even on PAT systems which don't
>> need to use MTRRs.
>>
>> This series adds new functions arch_phys_wc_{add,del} that, on PAT-less
>> x86 systems with MTRRs, add MTRRs and report errors, and that do nothing
>> otherwise.  (Other architectures, if any, with a similar mechanism could
>> implement them.)
>
> That's the path to upstream for this?  Should it go through drm-next?
> (Sorry for possible noob question -- I've never sent in anything other
> than trivial fixes to drm stuff before.)

I've pulled the v3 series into drm-next, lets see how they go for a while,

I suppose I should try and boot an AGP box with them.

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/

[PATCH] ARM: scu: empty scu_enable for !CONFIG_HAVE_ARM_SCU

[Neil Zhang]

Use the right config to empty scu_enable.

Signed-off-by: Neil Zhang 
---
 arch/arm/include/asm/smp_scu.h |2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/arch/arm/include/asm/smp_scu.h b/arch/arm/include/asm/smp_scu.h
index 18d1693..ac93189 100644
--- a/arch/arm/include/asm/smp_scu.h
+++ b/arch/arm/include/asm/smp_scu.h
@@ -26,7 +26,7 @@ static inline unsigned long scu_a9_get_base(void)
 unsigned int scu_get_core_count(void __iomem *);
 int scu_power_mode(void __iomem *, unsigned int);
 
-#ifdef CONFIG_SMP
+#ifdef CONFIG_HAVE_ARM_SCU
 void scu_enable(void __iomem *scu_base);
 #else
 static inline void scu_enable(void __iomem *scu_base) {}
-- 
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 2/2] ARM: dts: add the watchdog nodes for at91 boards

[Wenyou Yang]

boards include:
at91sam9263ek, at91sam9g20ek, at91sam9m10g45ek, at91sam9n12ek, at91sam9x5ek

Signed-off-by: Wenyou Yang 
---
 arch/arm/boot/dts/at91sam9263ek.dts |4 
 arch/arm/boot/dts/at91sam9g20ek_common.dtsi |4 
 arch/arm/boot/dts/at91sam9m10g45ek.dts  |4 
 arch/arm/boot/dts/at91sam9n12ek.dts |4 
 arch/arm/boot/dts/at91sam9x5ek.dtsi |4 
 5 files changed, 20 insertions(+)

diff --git a/arch/arm/boot/dts/at91sam9263ek.dts 
b/arch/arm/boot/dts/at91sam9263ek.dts
index 3b82d91..9143842 100644
--- a/arch/arm/boot/dts/at91sam9263ek.dts
+++ b/arch/arm/boot/dts/at91sam9263ek.dts
@@ -89,6 +89,10 @@
reg = <0>;
};
};
+
+   watchdog@fd40 {
+   status = "okay";
+   };
};
 
nand0: nand@4000 {
diff --git a/arch/arm/boot/dts/at91sam9g20ek_common.dtsi 
b/arch/arm/boot/dts/at91sam9g20ek_common.dtsi
index 6a92c5b..6d6b888 100644
--- a/arch/arm/boot/dts/at91sam9g20ek_common.dtsi
+++ b/arch/arm/boot/dts/at91sam9g20ek_common.dtsi
@@ -106,6 +106,10 @@
reg = <1>;
};
};
+
+   watchdog@fd40 {
+   status = "okay";
+   };
};
 
nand0: nand@4000 {
diff --git a/arch/arm/boot/dts/at91sam9m10g45ek.dts 
b/arch/arm/boot/dts/at91sam9m10g45ek.dts
index 51d9251b5..03f391a 100644
--- a/arch/arm/boot/dts/at91sam9m10g45ek.dts
+++ b/arch/arm/boot/dts/at91sam9m10g45ek.dts
@@ -59,6 +59,10 @@
status = "okay";
};
 
+   watchdog@fd40 {
+   status = "okay";
+   };
+
mmc0: mmc@fff8 {
pinctrl-0 = <
_board_mmc0
diff --git a/arch/arm/boot/dts/at91sam9n12ek.dts 
b/arch/arm/boot/dts/at91sam9n12ek.dts
index d30e48b..32e073f 100644
--- a/arch/arm/boot/dts/at91sam9n12ek.dts
+++ b/arch/arm/boot/dts/at91sam9n12ek.dts
@@ -77,6 +77,10 @@
reg = <0>;
};
};
+
+   watchdog@fe40 {
+   status = "okay";
+   };
};
 
nand0: nand@4000 {
diff --git a/arch/arm/boot/dts/at91sam9x5ek.dtsi 
b/arch/arm/boot/dts/at91sam9x5ek.dtsi
index 1fa48d2..e60b05a 100644
--- a/arch/arm/boot/dts/at91sam9x5ek.dtsi
+++ b/arch/arm/boot/dts/at91sam9x5ek.dtsi
@@ -56,6 +56,10 @@
status = "okay";
};
 
+   watchdog@fe40 {
+   status = "okay";
+   };
+
pinctrl@f400 {
mmc0 {
pinctrl_board_mmc0: mmc0-board {
-- 
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 0/2] ARM: dts: add watchdog device tree node in at91 dts files

[Wenyou Yang]

Hello,

The patches is to add watchdog device tree node for at91 SoC and board dts 
files.

Since the watchdog is disabled in the at91bootstrap with default configuration,
if you want to use the watchdog in the kernel, you must make sure the watchdog
doesn't be disabled in the at91bootstrap.

It is tested on at91sam9g20ek, at91sam9263ek, at91sam9g25ek
using Documentation/watchdog/src/watchdog-simple.c.

It is based on v3.10-rc3, tested on linux-watchdog git tree as well.

Best Regards,
Wenyou Yang

Wenyou Yang (2):
  ARM: dts: add the watchdog nodes for at91 SoC
  ARM: dts: add the watchdog nodes for at91 boards

 arch/arm/boot/dts/at91sam9263ek.dts |4 
 arch/arm/boot/dts/at91sam9g20ek_common.dtsi |4 
 arch/arm/boot/dts/at91sam9m10g45ek.dts  |4 
 arch/arm/boot/dts/at91sam9n12.dtsi  |6 ++
 arch/arm/boot/dts/at91sam9n12ek.dts |4 
 arch/arm/boot/dts/at91sam9x5.dtsi   |6 ++
 arch/arm/boot/dts/at91sam9x5ek.dtsi |4 
 7 files changed, 32 insertions(+)

-- 
1.7.9.5

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

[PATCH 1/2] ARM: dts: add the watchdog nodes for at91 SoC

[Wenyou Yang]

at91sam9x5, at91sam9n12

Signed-off-by: Wenyou Yang 
---
 arch/arm/boot/dts/at91sam9n12.dtsi |6 ++
 arch/arm/boot/dts/at91sam9x5.dtsi  |6 ++
 2 files changed, 12 insertions(+)

diff --git a/arch/arm/boot/dts/at91sam9n12.dtsi 
b/arch/arm/boot/dts/at91sam9n12.dtsi
index 8d25f88..7f92f07 100644
--- a/arch/arm/boot/dts/at91sam9n12.dtsi
+++ b/arch/arm/boot/dts/at91sam9n12.dtsi
@@ -423,6 +423,12 @@
pinctrl-0 = <_spi1>;
status = "disabled";
};
+
+   watchdog@fe40 {
+   compatible = "atmel,at91sam9260-wdt";
+   reg = <0xfe40 0x10>;
+   status = "disabled";
+   };
};
 
nand0: nand@4000 {
diff --git a/arch/arm/boot/dts/at91sam9x5.dtsi 
b/arch/arm/boot/dts/at91sam9x5.dtsi
index 1145ac3..1d32064 100644
--- a/arch/arm/boot/dts/at91sam9x5.dtsi
+++ b/arch/arm/boot/dts/at91sam9x5.dtsi
@@ -648,6 +648,12 @@
interrupts = <1 4 7>;
status = "disabled";
};
+
+   watchdog@fe40 {
+   compatible = "atmel,at91sam9260-wdt";
+   reg = <0xfe40 0x10>;
+   status = "disabled";
+   };
};
 
nand0: nand@4000 {
-- 
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 0/2] ARM: dts: add watchdog device tree node in at91 dts files

[Wenyou Yang]

Hello,

The patches is to add watchdog device tree node for at91 SoC and board dts 
files.

Since the watchdog is disabled in the at91bootstrap with default configuration,
if you want to use the watchdog in the kernel, you must make sure the watchdog
doesn't be disabled in the at91bootstrap.

It is tested on at91sam9g20ek, at91sam9263ek, at91sam9g25ek
using Documentation/watchdog/src/watchdog-simple.c.

It is based on v3.10-rc3, tested on linux-watchdog git tree as well.

Best Regards,
Wenyou Yang

Wenyou Yang (2):
  ARM: dts: add the watchdog nodes for at91 SoC
  ARM: dts: add the watchdog nodes for at91 boards

 arch/arm/boot/dts/at91sam9263ek.dts |4 
 arch/arm/boot/dts/at91sam9g20ek_common.dtsi |4 
 arch/arm/boot/dts/at91sam9m10g45ek.dts  |4 
 arch/arm/boot/dts/at91sam9n12.dtsi  |6 ++
 arch/arm/boot/dts/at91sam9n12ek.dts |4 
 arch/arm/boot/dts/at91sam9x5.dtsi   |6 ++
 arch/arm/boot/dts/at91sam9x5ek.dtsi |4 
 7 files changed, 32 insertions(+)

-- 
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 0/2] ARM: dts: add watchdog device tree node in at91 dts files

[Wenyou Yang]

Hello,

The patches is to add watchdog device tree node for at91 SoC and board dts 
files.

Since the watchdog is disabled in the at91bootstrap with default configuration,
if you want to use the watchdog in the kernel, you must make sure the watchdog
doesn't be disabled in the at91bootstrap.

It is tested on at91sam9g20ek, at91sam9263ek, at91sam9g25ek
using Documentation/watchdog/src/watchdog-simple.c.

It is based on v3.10-rc3, tested on linux-watchdog git tree as well.

Best Regards,
Wenyou Yang

Wenyou Yang (2):
  ARM: dts: add the watchdog nodes for at91 SoC
  ARM: dts: add the watchdog nodes for at91 boards

 arch/arm/boot/dts/at91sam9263ek.dts |4 
 arch/arm/boot/dts/at91sam9g20ek_common.dtsi |4 
 arch/arm/boot/dts/at91sam9m10g45ek.dts  |4 
 arch/arm/boot/dts/at91sam9n12.dtsi  |6 ++
 arch/arm/boot/dts/at91sam9n12ek.dts |4 
 arch/arm/boot/dts/at91sam9x5.dtsi   |6 ++
 arch/arm/boot/dts/at91sam9x5ek.dtsi |4 
 7 files changed, 32 insertions(+)

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

[Neil Zhang]

bring up pxa988 with device tree support.

Change-Id: I6fc869b7d5ff8dc6e4eb0042a89429200f7a9fb1
Signed-off-by: Neil Zhang 
---
 arch/arm/boot/dts/pxa988-dkb.dts  |   36 ++
 arch/arm/boot/dts/pxa988.dtsi |  189 +
 arch/arm/mach-mmp/Kconfig |   27 
 arch/arm/mach-mmp/Makefile|2 +
 arch/arm/mach-mmp/common.c|   11 ++-
 arch/arm/mach-mmp/common.h|2 +
 arch/arm/mach-mmp/headsmp.S   |  104 
 arch/arm/mach-mmp/include/mach/addr-map.h |6 +
 arch/arm/mach-mmp/mmpx-dt.c   |   74 +++
 arch/arm/mach-mmp/platsmp.c   |  167 +
 arch/arm/mach-mmp/reset.c |   68 ++
 arch/arm/mach-mmp/reset.h |   28 +
 drivers/clk/mmp/Makefile  |1 +
 13 files changed, 714 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/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

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..567d33d
--- /dev/null
+++ b/arch/arm/boot/dts/pxa988.dtsi
@@ -0,0 +1,189 @@
+/*
+ *  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: wakeupgen@d4282000 {
+   compatible = "mrvl,mmp-intc";
+ 

[PATCH v2] bring up pxa988 with DT

[Neil Zhang]

This patch is supposed to bring up pxa988 SMP.
will change to use CLOCKSOURCE later.

ChangeLog
V2:
1. use early_init call for handler init.
2. Add sanity check for maximum core count.

Neil Zhang (1):
  ARM: mmp: bring up pxa988 with device tree support

 arch/arm/boot/dts/pxa988-dkb.dts  |   36 ++
 arch/arm/boot/dts/pxa988.dtsi |  189 +
 arch/arm/mach-mmp/Kconfig |   27 
 arch/arm/mach-mmp/Makefile|2 +
 arch/arm/mach-mmp/common.c|   11 ++-
 arch/arm/mach-mmp/common.h|2 +
 arch/arm/mach-mmp/headsmp.S   |  104 
 arch/arm/mach-mmp/include/mach/addr-map.h |6 +
 arch/arm/mach-mmp/mmpx-dt.c   |   74 +++
 arch/arm/mach-mmp/platsmp.c   |  167 +
 arch/arm/mach-mmp/reset.c |   68 ++
 arch/arm/mach-mmp/reset.h |   28 +
 drivers/clk/mmp/Makefile  |1 +
 13 files changed, 714 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/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/

[git pull] drm fixes

[Dave Airlie]

Hi Linus,

one qxl 32-bit warning fix, the rest is a bunch of radeon fixes from Alex 
for some issues we've been seeing.

Dave.

The following changes since commit c89b65e7fffef745bdd36c372aa0dea778fecbab:

  qxl: fix Kconfig deps - select FB_DEFERRED_IO (2013-05-28 17:03:37 +1000)

are available in the git repository at:

  git://people.freedesktop.org/~airlied/linux drm-fixes

for you to fetch changes up to 970fa986fadb1165cf38b45b70e98302a3bee497:

  drm/qxl: fix build warnings on 32-bit (2013-05-31 12:45:09 +1000)


Alex Deucher (4):
  drm/radeon: fix typo in cu_per_sh on verde
  drm/radeon: fix card_posted check for newer asics
  drm/radeon: don't check crtcs in card_posted() on cards without DCE
  drm/radeon: narrow scope of Apple re-POST hack

Christian König (1):
  drm/radeon: UVD block on SUMO2 is the same as on SUMO

Dave Airlie (2):
  Merge branch 'drm-fixes-3.10' of 
git://people.freedesktop.org/~agd5f/linux into drm-next
  drm/qxl: fix build warnings on 32-bit

Kleber Sacilotto de Souza (1):
  radeon: use max_bus_speed to activate gen2 speeds

 drivers/gpu/drm/qxl/qxl_ioctl.c|  4 ++--
 drivers/gpu/drm/qxl/qxl_kms.c  |  9 +
 drivers/gpu/drm/radeon/evergreen.c | 10 +++---
 drivers/gpu/drm/radeon/r600.c  |  9 ++---
 drivers/gpu/drm/radeon/radeon_device.c | 27 ---
 drivers/gpu/drm/radeon/rv770.c | 13 +++--
 drivers/gpu/drm/radeon/si.c|  2 +-
 7 files changed, 32 insertions(+), 42 deletions(-)

Re: [PATCH] ARM: EXYNOS: Consolidate multiple low-level UART port definitions

[Tushar Behera]

On 05/31/2013 02:41 AM, Olof Johansson wrote:
> Hi,
> 
> On Wed, May 29, 2013 at 9:40 PM, Tushar Behera  
> wrote:
>> There are two definitions for low-level UART ports for Exynos platform.
>> CONFIG_S3C_LOWLEVEL_UART_PORT is used for printing "Uncompressing
>> Linux... done, booting the kernel." and CONFIG_S3C_UART for other
>> low-level messages.
>>
>> The assumption for both the uart ports is that they are pre-configured
>> in the bootloader. Since they are essentially the same always, it
>> would be good to consolidate them to use only one macro, in this case
>> 'DEBUG_S3C_UART' would be a better option.
>>
>> 'DEBUG_S3C_UART' is defined only if DEBUG_LL is enabled. We can safely
>> disable this option when DEBUG_LL is not defined and we can boot various
>> boards with different UART port settings. Only drawback of this
>> approach is that when DEBUG_LL is not defined, we would be missing the
>> print "Uncompressing Linux... done, booting the kernel."
>>
>> Since CONFIG_S3C_LOWLEVEL_UART_PORT is still used by other Samsung
>> boards, the consolidation applies only for ARCH_EXYNOS.
>>
>> Signed-off-by: Tushar Behera 
> 
> This looks reasonable, but you have to convert the other samsung
> platforms too -- it's not ok to ignore them.
> 

Sure thing. I will update those platforms in a subsequent patchset.

> 
> -Olof
> 


-- 
Tushar Behera
--
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: [regression, bisected] x86: efi: Pass boot services variable info to runtime code

[Russ Anderson]

On Thu, May 30, 2013 at 10:32:09PM +, Matthew Garrett wrote:
> On Thu, 2013-05-30 at 17:28 -0500, Russ Anderson wrote:
> > On Thu, May 30, 2013 at 10:21:53PM +, Matthew Garrett wrote:
> > > On Thu, 2013-05-30 at 17:17 -0500, Russ Anderson wrote:
> > > 
> > > > That's a great idea.  This patch moves the QueryVariableInfo()
> > > > call from bootime to runtime, in efi_late_init().  The attached
> > > > patch is consistent with the UEFI spec and avoids the problem.
> > > 
> > > No, that defeats the entire point of the original patch.
> > 
> > How so?  It is still calling QueryVariableInfo()
> > before the data is used.
> 
> We want to know how much space is used by variables that aren't visible
> at runtime.

We want to boot.  We could boot up through 3.9-rc7.

Knowing how much space is used by variables that aren't
visible at runtime it moot if you can't boot.


And again, maybe this is a bios bug - we have bios people
looking into it - and maybe that call _should_ work, but
the fact is the kernel booted without that change[1] and does
not boot with it.  


[1] commit cc5a080c5d40c36089bb08a8a16fa3fc7047fe0f

Thanks,
-- 
Russ Anderson, OS RAS/Partitioning Project Lead  
SGI - Silicon Graphics Inc  r...@sgi.com
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 3/2] vfio: Provide module option to disable vfio_iommu_type1 hugepage support

[Chegu Vinod]

On 5/28/2013 9:27 AM, Alex Williamson wrote:

Add a module option to vfio_iommu_type1 to disable IOMMU hugepage
support.  This causes iommu_map to only be called with single page
mappings, disabling the IOMMU driver's ability to use hugepages.
This option can be enabled by loading vfio_iommu_type1 with
disable_hugepages=1 or dynamically through sysfs.  If enabled
dynamically, only new mappings are restricted.

Signed-off-by: Alex Williamson 
---

As suggested by Konrad.  This is cleaner to add as a follow-on

  drivers/vfio/vfio_iommu_type1.c |   11 +++
  1 file changed, 11 insertions(+)

diff --git a/drivers/vfio/vfio_iommu_type1.c b/drivers/vfio/vfio_iommu_type1.c
index 6654a7e..8a2be4e 100644
--- a/drivers/vfio/vfio_iommu_type1.c
+++ b/drivers/vfio/vfio_iommu_type1.c
@@ -48,6 +48,12 @@ module_param_named(allow_unsafe_interrupts,
  MODULE_PARM_DESC(allow_unsafe_interrupts,
 "Enable VFIO IOMMU support for on platforms without interrupt 
remapping support.");
  
+static bool disable_hugepages;

+module_param_named(disable_hugepages,
+  disable_hugepages, bool, S_IRUGO | S_IWUSR);
+MODULE_PARM_DESC(disable_hugepages,
+"Disable VFIO IOMMU support for IOMMU hugepages.");
+
  struct vfio_iommu {
struct iommu_domain *domain;
struct mutexlock;
@@ -270,6 +276,11 @@ static long vfio_pin_pages(unsigned long vaddr, long npage,
return -ENOMEM;
}
  
+	if (unlikely(disable_hugepages)) {

+   vfio_lock_acct(1);
+   return 1;
+   }
+
/* Lock all the consecutive pages from pfn_base */
for (i = 1, vaddr += PAGE_SIZE; i < npage; i++, vaddr += PAGE_SIZE) {
unsigned long pfn = 0;

.



Tested-by: Chegu Vinod 

I was able to verify your changes on a 2 Sandybridge-EP socket platform 
and observed about ~7-8% improvement in the netperf's TCP_RR 
performance.  The guest size was small (16vcpu/32GB).


Hopefully these changes also have an indirect benefit of avoiding soft 
lockups on the host side when larger guests (> 256GB ) are rebooted. 
Someone who has ready access to a larger Sandybridge-EP/EX platform can 
verify this.


FYI
Vinod

--
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: [regression, bisected] x86: efi: Pass boot services variable info to runtime code

[Russ Anderson]

On Fri, May 31, 2013 at 12:30:43AM +0200, Jiri Kosina wrote:
> On Thu, 30 May 2013, Russ Anderson wrote:
> 
> > > > That's a great idea.  This patch moves the QueryVariableInfo()
> > > > call from bootime to runtime, in efi_late_init().  The attached
> > > > patch is consistent with the UEFI spec and avoids the problem.
> > > 
> > > No, that defeats the entire point of the original patch.
> > 
> > How so?  It is still calling QueryVariableInfo()
> > before the data is used.
> 
> You lose information provided by QueryVariableInfo() about boot-only 
> variables once the transition boot -> runtime has happened.

Is that information really more important than the ability
to boot?

Correct me if I'm wrong, but linux was able to boot without
the boottime QueryVariableInfo() call up until 3.9-rc7,
and it still does on systems that do not use EFI stubs (ie
grub and elilo).  It is only when linux uses EFI stubs (ie
grub2) that linux makes the boottime QueryVariableInfo()
call.  So why is that call, or whatever is dependent on it,
more important than booting?



Thanks,
-- 
Russ Anderson, OS RAS/Partitioning Project Lead  
SGI - Silicon Graphics Inc  r...@sgi.com
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCHv12 2/4] zbud: add to mm/

[Bob Liu]

Hi Seth,

On 05/31/2013 05:20 AM, Seth Jennings wrote:
> Andrew, Mel,
> 
> This struct page stuffing is taking a lot of time to work out and _might_ be
> fraught with peril when memmap peekers are considered.
> 
> What do you think about just storing the zbud page metadata inline in the
> memory page in the first zbud page chunk?

How about making zswap based on SLAB? Create a PAGE_SIZE slab and when
zswap need to alloc_page() using kmem_cache_alloc() instead.

So that leave SLAB layer to handler the NUMA problem and do the
dynamical pool size for us.

In this way, an extra struct need to manage the zbud page metadate
instead of using struct page.
But I think it's easy and won't occupy many memory.

> 
> Mel, this kinda hurts you plans for making NCHUNKS = 2, since there would
> only be one chunk available for storage and would make zbud useless.
> 
> Just a way to sidestep this whole issue.  What do you think?
> 
> Seth
> 

-- 
Regards,
-Bob
--
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 -next v3] dmaengine: ste_dma40: fix error return code in d40_probe()

[Wei Yongjun]

From: Wei Yongjun 

In many of the error handling case, the return value 'ret' not set
and 0 will be return from d40_probe() even if error, but we should
return a negative error code instead in those error handling case.
This patch fixed them, and also removed useless variable 'err'.

Signed-off-by: Wei Yongjun 
---
v2 -> v3: move NULL assign below set ret, and remove redundant ENODEV check.
---
 drivers/dma/ste_dma40.c | 14 +++---
 1 file changed, 7 insertions(+), 7 deletions(-)

diff --git a/drivers/dma/ste_dma40.c b/drivers/dma/ste_dma40.c
index 7f23d45..88e3cd4 100644
--- a/drivers/dma/ste_dma40.c
+++ b/drivers/dma/ste_dma40.c
@@ -3506,7 +3506,6 @@ static int __init d40_probe(struct platform_device *pdev)
 {
struct stedma40_platform_data *plat_data = pdev->dev.platform_data;
struct device_node *np = pdev->dev.of_node;
-   int err;
int ret = -ENOENT;
struct d40_base *base = NULL;
struct resource *res = NULL;
@@ -3618,6 +3617,7 @@ static int __init d40_probe(struct platform_device *pdev)
base->lcpa_regulator = regulator_get(base->dev, "lcla_esram");
if (IS_ERR(base->lcpa_regulator)) {
d40_err(>dev, "Failed to get lcpa_regulator\n");
+   ret = PTR_ERR(base->lcpa_regulator);
base->lcpa_regulator = NULL;
goto failure;
}
@@ -3633,13 +3633,13 @@ static int __init d40_probe(struct platform_device 
*pdev)
}
 
base->initialized = true;
-   err = d40_dmaengine_init(base, num_reserved_chans);
-   if (err)
+   ret = d40_dmaengine_init(base, num_reserved_chans);
+   if (ret)
goto failure;
 
base->dev->dma_parms = >dma_parms;
-   err = dma_set_max_seg_size(base->dev, STEDMA40_MAX_SEG_SIZE);
-   if (err) {
+   ret = dma_set_max_seg_size(base->dev, STEDMA40_MAX_SEG_SIZE);
+   if (ret) {
d40_err(>dev, "Failed to set dma max seg size\n");
goto failure;
}
@@ -3647,8 +3647,8 @@ static int __init d40_probe(struct platform_device *pdev)
d40_hw_init(base);
 
if (np) {
-   err = of_dma_controller_register(np, d40_xlate, NULL);
-   if (err && err != -ENODEV)
+   ret = of_dma_controller_register(np, d40_xlate, NULL);
+   if (ret)
dev_err(>dev,
"could not register of_dma_controller\n");
}

--
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] PCI: set correct value for iov device before device

[Jiang Liu]

On Fri 31 May 2013 08:54:24 AM CST, Yinghai Lu wrote:
> On Thu, May 30, 2013 at 4:22 PM, Bjorn Helgaas  wrote:
>> On Thu, May 30, 2013 at 2:27 PM, Yinghai Lu  wrote:
>>> On Wed, May 29, 2013 at 11:04 PM, Yinghai Lu  wrote:
 On Wed, May 29, 2013 at 10:45 PM, Xudong Hao  wrote:
> Since device registering is put into pci_device_add(), it must set value 
> of
> Virtual Function device's member before the pci_dev is put to device 
> tree. Or
> some relevant subsystem of driver model such as xen will report a 
> incorrect
> IOV device to Xen hypervior.
>
> Signed-off-by: Xudong Hao 
> ---
>  drivers/pci/iov.c | 6 +++---
>  1 file changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/pci/iov.c b/drivers/pci/iov.c
> index c93071d..43d3de9 100644
> --- a/drivers/pci/iov.c
> +++ b/drivers/pci/iov.c
> @@ -110,12 +110,12 @@ static int virtfn_add(struct pci_dev *dev, int id, 
> int reset)
> if (reset)
> __pci_reset_function(virtfn);
>
> -   pci_device_add(virtfn, virtfn->bus);
> -   mutex_unlock(>dev->sriov->lock);
> -
> virtfn->physfn = pci_dev_get(dev);
> virtfn->is_virtfn = 1;
>
> +   pci_device_add(virtfn, virtfn->bus);
> +   mutex_unlock(>dev->sriov->lock);
> +
> rc = pci_bus_add_device(virtfn);
> sprintf(buf, "virtfn%u", id);
> rc = sysfs_create_link(>dev.kobj, >dev.kobj, buf);

 I have similar patch at
 https://patchwork.kernel.org/patch/2562551/
[5/7] PCI, ACPI: Don't glue ACPI dev with pci VFs

 and Jiang has another one
 https://patchwork.kernel.org/patch/2613481/
[v3,part1,10/10] PCI, IOV: hide remove and rescan sysfs interfaces
 for SR-IOV virtual functions
>>>
>>> Bjorn,
>>>
>>> I double check this one, we should split the patch from me or Jiang.
>>
>> I don't know what the sentence above means.
>
> I mean half of patch
> https://patchwork.kernel.org/patch/2562551/
> or half of patch
> https://patchwork.kernel.org/patch/2613481/
>
> just like what Xudong extracted.
>
>>
>>> and the one about set virtfn=1 should be -stable material.
>>
>> I assume you mean that Jiang's "[v3,part1,10/10] PCI, IOV: hide remove
>> and rescan sysfs interfaces for SR-IOV virtual functions" patch does
>> not need to be in v3.10, but it should be marked for -stable.
>
> no half of it, move set virtfn=1 two lines forward.
>
>>
>> How far back should it go?  v3.9+?
>
> yes. v3.9+
>
>>
>>> That will address another problem that is caused by
>>> moving device_add from pci_bus_add_device to pci_device_add.
>>
>> I assume you're talking about a problem caused by 4f535093 ("PCI: Put
>> pci_dev in device tree as early as possible").  That commit appeared
>> in v3.9.
>
> yes.
>
>>
>> If we're asking to add the "hide remove and rescan sysfs interfaces"
>> patch to the v3.9 stable series, we should have a description of
>> exactly what problem it fixes, and ideally, a bugzilla for it.  Can
>> you provide that?
>
> No. that is not what i mean.
>
> That problem have been there when sriov support was added.
>
>>
>> That patch appears to be the only one in the [v3,part1,0/10] series
>> that actually directly fixes an issue, so it would be nice to have
>> more specifics in that changelog to begin with.  The other patches in
>> that series appear to to be cleanups and preparation for the real
>> fixes that will come later.
>
> yes. even should be separated from that patchset.
>
> Yinghai
> --
> To unsubscribe from this list: send the line "unsubscribe linux-pci" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
Hi Bjorn and Yinghai,
   I think it's ok to separate out the bugfix part.
  We found this issue when implementing the mechanism to hide 
"remove"
sysfs entry for PCI virtual functions because it depends on "is_virtfn" 
flag to
hide "remove" sysfs entry. Actually I didn't realize it also fixes 
other issues
when making this change.
  Sorry for the inconvenience!
Gerry

--
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 net/3.9] ipv6: ndisc: fix ndisc_send_redirect writing to the wrong skb

[Matthias Schiffer]

Since some refactoring in 5f5a011, ndisc_send_redirect called
ndisc_fill_redirect_hdr_option on the wrong skb, leading to data corruption or
in the worst case a panic when the skb_put failed.

Signed-off-by: Matthias Schiffer 
---
 net/ipv6/ndisc.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/net/ipv6/ndisc.c b/net/ipv6/ndisc.c
index 2712ab2..ca4ffcc 100644
--- a/net/ipv6/ndisc.c
+++ b/net/ipv6/ndisc.c
@@ -1493,7 +1493,7 @@ void ndisc_send_redirect(struct sk_buff *skb, const 
struct in6_addr *target)
 */
 
if (ha)
-   ndisc_fill_addr_option(skb, ND_OPT_TARGET_LL_ADDR, ha);
+   ndisc_fill_addr_option(buff, ND_OPT_TARGET_LL_ADDR, ha);
 
/*
 *  build redirect option and copy skb over to the new packet.
-- 
1.8.3

--
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 0/4] clk, mfd: u8540 clock tree definition

[Mike Turquette]

Quoting Philippe Begnic (2013-05-27 05:41:28)
> From: Philippe Begnic 
> 
> Create U8540 clock tree definitions for common clock framework
> 

The clock changes look good to me.  How did you want to merge the
patches?

Regards,
Mike

> Philippe Begnic (4):
>   clk: ux500: Pass clock base adresses in initcall for u8540 and u9540
>   mfd: db8500: Update register definition for u8540 clock
>   mfd: db8500: Update BML clock register for db8580
>   clk: ux500: Clocks definition for u8540
> 
>  arch/arm/mach-ux500/cpu.c |6 +-
>  drivers/clk/ux500/u8540_clk.c |  564 
> -
>  drivers/clk/ux500/u9540_clk.c |4 +-
>  drivers/mfd/db8500-prcmu.c|1 +
>  drivers/mfd/dbx500-prcmu-regs.h   |1 +
>  include/linux/mfd/abx500/ab8500-sysctrl.h |4 +-
>  include/linux/mfd/dbx500-prcmu.h  |   12 +
>  include/linux/platform_data/clk-ux500.h   |6 +-
>  8 files changed, 587 insertions(+), 11 deletions(-)
> 
> -- 
> 1.7.9.5
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v2] ata: increase retry count but shorten duration for Calxeda controller

[Tejun Heo]

On Thu, May 30, 2013 at 09:18:29AM -0500, Mark Langsdorf wrote:
> The Calxeda SATA phy intermittently fails to bring up a link with Gen3
> Retrying the phy hard reset can work around the issue, but the drive
> may fail again. In less than 150 out of 15000 test runs, it took more
> than 10 tries for the link to be established (but never more than 35).
> Triple the maximum observed retry count to provide plenty of margin for
> rare events and to guarantee that the link is established.
> 
> Also, the default 2 second time-out on a failed drive is too long in
> this situation. The uboot implementation of the same driver function
> uses a much shorter time-out period and never experiences a time out
> issue. Shorten the Linux time-out value for this driver to 500 ms and
> keep the other timing constants the same as the stock AHCI driver. This
> change was also tested 15000 times on 24 drives and none of them
> experienced a time out.
> 
> Signed-off-by: Mark Langsdorf 
> ---
> Changes from v1
>   Add const to the timing variable definition
>   Added more detail in why the various numbers were chosen

Can you make the detailed explanation comment in the code so that
people don't have to try to hunt down this commit later on?  The
commit message can explain it briefly and refer to the comment in the
body.

Thanks.

-- 
tejun
--
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] Comparison of power-efficient scheduling patch sets

[Alex Shi]

On 05/30/2013 09:47 PM, Morten Rasmussen wrote:
> Hi,
> 
> A number of patch sets related to power-efficient scheduling have been
> posted over the last couple of months. Most of them do not have much
> data to back them up, so I decided to do some testing.
> 
> Common for all of the patch sets that I have tested, except one, is that
> they attempt to pack tasks on as few cpus as possible to allow the
> remaining cpus to enter deeper sleep states - a strategy that should
> make sense on most platforms that support per-cpu power gating and
> multi-socket machines.
> 
> Kernel: 3.9
> 
> Patch sets:
> rlb-v4: sched: use runnable load based balance (Alex Shi)
> 

Thanks for the valuable comparison!

The runnable load balance target is performance. It is still try to
disperse tasks to as much as possible CPUs. :)
The latest v7 version remove the 6th patch(wake_affine change) in v4.
and plus fix a slept time double counting issue, and remove
blocked_load_avg in tg load.
http://comments.gmane.org/gmane.linux.kernel/1498988
Enjoy!
> pas-v7: sched: power aware scheduling (Alex Shi)
> 

We still have some internal discussion on this patch set before update
it. Sorry for response late on this patchset!

> pst-v3: sched: packing small tasks (Vincent Guittot)
> 
> pst-v4: sched: packing small tasks (Vincent Guittot)
> 
> 
> Configuration:
> pas-v7: Set to "powersaving" mode.
> pst-v4: Set to "Full" packing mode.
> 
> Platform:
> ARM TC2 (test-chip), 2xCortex-A15 + 3xCortex-A7. Cortex-A15s disabled.
> 
> Measurement technique:
> Time spent non-idle (not in idle state) for each cpu based on cpuidle
> ftrace events. TC2 does not have per-core power-gating, so packing
> inside the A7 cluster does not lead to any significant power savings.
> Note that any product grade hardware (TC2 is a test-chip) will very
> likely have per-core power-gating, so in those cases packing will have
> an appreciable effect on power savings.
> Measuring non-idle time rather than power should give a more clear idea
> about the effect of the patch sets given that the idle back-end is
> highly implementation specific.
> 
> Benchmarks:
> audio playback (Android): 30s mp3 file playback on Android.
> bbench+audio (Android): Web page rendering while doing mp3 playback.
> andebench_native (Android): Android benchmark running in native mode.
> cyclictest: Short periodic tasks.
> 
> Results:
> Two runs for each patch set.
> 
> audio playback (Android) SMP
> non-idle %  cpu 0  cpu 1  cpu 2
> 3.9_1   11.96   2.86   2.48
> 3.9_2   12.64   2.81   1.88
> rlb-v4_112.61   2.44   1.90
> rlb-v4_212.45   2.44   1.90
> pas-v7_116.17   0.03   0.24
> pas-v7_216.08   0.28   0.07
> pst-v3_115.18   2.76   1.70
> pst-v3_215.13   0.80   0.38
> pst-v4_116.14   0.05   0.00
> pst-v4_216.34   0.06   0.00
> 
> bbench+audio (Android) SMP
> non-idle %  cpu 0  cpu 1  cpu 2  render time
> 3.9_1   25.00  20.73  21.22   812
> 3.9_2   24.29  19.78  22.34   795
> rlb-v4_123.84  19.36  22.74   782
> rlb-v4_224.07  19.36  22.74   797
> pas-v7_128.29  17.86  16.01   869
> pas-v7_228.62  18.54  15.05   908
> pst-v3_129.14  20.59  21.72   830
> pst-v3_227.69  18.81  20.06   830
> pst-v4_142.20  13.63   2.29   880
> pst-v4_241.56  14.40   2.17   935
> 
> andebench_native (8 threads) (Android) SMP
> non-idle %  cpu 0  cpu 1  cpu 2  Score
> 3.9_1   99.22  98.88  99.61   4139
> 3.9_2   99.56  99.31  99.46   4148
> rlb-v4_199.49  99.61  99.53   4153
> rlb-v4_299.56  99.61  99.53   4149
> pas-v7_199.53  99.59  99.29   4149
> pas-v7_299.42  99.63  99.48   4150
> pst-v3_197.89  99.33  99.42   4097
> pst-v3_299.16  99.62  99.42   4097
> pst-v4_199.34  99.01  99.59   4146
> pst-v4_299.49  99.52  99.20   4146
> 
> cyclictest SMP
> non-idle %  cpu 0  cpu 1  cpu 2
> 3.9_19.13   8.88   8.41
> 3.9_2   10.27   8.02   6.30
> rlb-v4_1 8.88   8.09   8.11
> rlb-v4_2 8.49   8.09   8.11
> pas-v7_110.20   0.02  11.50
> pas-v7_2 7.86  14.31   0.02
> pst-v3_120.44   8.68   7.97
> pst-v3_220.41   0.78   1.00
> pst-v4_121.32   0.21   0.05
> pst-v4_221.56   0.21   0.04
> 
> Overall, pas-v7 seems to do a fairly good job at packing. The idle time
> distribution seems to be somewhere between pst-v3 and the more
> aggressive pst-v4 for all the benchmarks. pst-v4 manages to keep two
> cpus nearly idle (<0.25% non-idle) for both cyclictest and audio, which
> is better than both pst-v3 and pas-v7. pas-v7 fails to pack cyclictest.
> Packing does come at at cost which can be seen for bbench+audio, where
> pst-v3 and rlb-v4 get better render times than pas-v7 and pst-v4 which
> do more aggressive packing. rlb-v4 does not pack, it is only included
> for reference.
> 
> From a packing 

Re: [PATCH 2/2] sata highbank: add bit-banged SGPIO driver support

[Tejun Heo]

On Thu, May 30, 2013 at 03:17:31PM -0500, Mark Langsdorf wrote:
> +static DEFINE_SPINLOCK(sgpio_lock);
> +#define SCLOCK   0
> +#define SLOAD1
> +#define SDATA2
> +static unsigned ecx_sgpio[3];
> +static unsigned long ecx_sgpio_pattern;
> +static int port_to_sgpio[] = { 4, 0, 1, 2, 3};
> +static int n_ports;

Please use more specific names for global constants and variables.
Defining something like n_ports as a global variable is silly and
can lead to silly bugs later on.

> +#define ACTIVITY_BITS0x30 // 0x7
> +#define ACTIVITY_SHIFT   2
> +#define LOCATE_BITS  0x8  // 0x38
> +#define LOCATE_SHIFT 1
> +#define FAULT_BITS   0x40 // 0x1c0

No //s please and please pick and use a common prefix.  It doesn't
have to be long or complete.  Even something as short as HB_ is fine.

> +#define FAULT_SHIFT  1
> +#define SGPIO_BIT(port, shift)   1 << (3 * port_to_sgpio[(port)] 
> + \
> + (shift))

Please make it a function.

> +static void ecx_parse_sgpio(u32 port, u32 state)
> +{
> + if (state == 0) {
> + ecx_sgpio_pattern &= ~(SGPIO_BIT(port, ACTIVITY_SHIFT) |
> + SGPIO_BIT(port, LOCATE_SHIFT) |
> + SGPIO_BIT(port, FAULT_SHIFT));
> + return;
> + }
> + if (state & ACTIVITY_BITS)
> + ecx_sgpio_pattern |= SGPIO_BIT(port, ACTIVITY_SHIFT);
> + if (state & LOCATE_BITS)
> + ecx_sgpio_pattern |= SGPIO_BIT(port, LOCATE_SHIFT);
> + if (state & FAULT_BITS)
> + ecx_sgpio_pattern |= SGPIO_BIT(port, FAULT_SHIFT);
> +}

Maybe I'm misunderstanding the code but things are cleared iff @state
is zero?  Is that intentional?


> +static ssize_t ecx_transmit_led_message(struct ata_port *ap, u32 state,
> + ssize_t size)
> +{
> + struct ahci_host_priv *hpriv = ap->host->private_data;
> + struct ahci_port_priv *pp = ap->private_data;
> + unsigned long flags;
> + int pmp, i;
> + struct ahci_em_priv *emp;
> + u32 sgpio_out;
> +
> + /* get the slot number from the message */
> + pmp = (state & EM_MSG_LED_PMP_SLOT) >> 8;
> + if (pmp < EM_MAX_SLOTS)
> + emp = >em_priv[pmp];
> + else
> + return -EINVAL;
> +
> + if (!hpriv->em_msg_type & EM_MSG_TYPE_LED) 

Huh?  This can't be right.

> + return size;
> +
> + spin_lock_irqsave(_lock, flags);
> + ecx_parse_sgpio(ap->port_no, state);
> + sgpio_out = ecx_sgpio_pattern;

Hmmm... global data.  Can we at least move it into host private data?

> + gpio_set_value(ecx_sgpio[SLOAD], 1);
> + ecx_led_cycle_clock();
> + gpio_set_value(ecx_sgpio[SLOAD], 0);
> + for (i = 0; i < (3 * n_ports); i++) {
> + gpio_set_value(ecx_sgpio[SDATA], sgpio_out & 1);
> + sgpio_out >>= 1;
> + ecx_led_cycle_clock();
> + }

What's the above loop achieving?  Care to add a comment?

> +
> + /* save off new led state for port/slot */
> + emp->led_state = state;
> +
> + spin_unlock_irqrestore(_lock, flags);
> + return size;
> +}
> +
> +void highbank_set_em_messages(struct device *dev, struct ahci_host_priv 
> *hpriv,
> +   struct ata_port_info *pi)
> +{
> + struct device_node *np = dev->of_node;
> + int i;
> + int err;
> +
> + for (i = 0;i < 3; i++) {

Missing space after ; and what's this magic 3 I keep seeing?

> + ecx_sgpio[i] = of_get_named_gpio(np, "calxeda,sgpio-gpio", i);
> + if (IS_ERR_VALUE(ecx_sgpio[i]))
> +return;
> +
> + err = gpio_request(ecx_sgpio[i], "CX SGPIO");
> + if (err) {
> + printk(KERN_ERR
> + "sata_highbank gpio_request %d failed: %d\n",
> + i, err);
> + return;

pr_err()?

> + }
> + gpio_direction_output(ecx_sgpio[i], 1);
> + }
> + /* there's a default ordering, but give it an optional override */
> + for (i = 0; i < n_ports; i++) {
> + of_property_read_u32_array(np, "calxeda,led-order", 
> + port_to_sgpio, i);
> + }

{ } unnecessary.

Thanks.

-- 
tejun
--
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 0/5] scsi: use platform helper macro and wrapper functions

[Kefeng Wang]

On 2013-05-30 22:38, James Bottomley wrote:
> There doesn't seem to be much point to these patches since either idiom
> is fine and easily understood.  We also try to touch the ancient drivers
> as little as possible since it can be months before anyone actually
> tries them out and notices that something got broken, so the rule for
> them is obvious bug fixes only.
> 
> James

hi James,
Thanks for remind, I got it.



--
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 PATCHv4 3/6] clk: TI-Nspire clock drivers

[Mike Turquette]

Quoting Daniel Tang (2013-05-25 04:08:04)
> diff --git a/drivers/clk/clk-nspire.c b/drivers/clk/clk-nspire.c
> new file mode 100644
> index 000..2546f7d
> --- /dev/null
> +++ b/drivers/clk/clk-nspire.c
> @@ -0,0 +1,155 @@
> +/*
> + *  linux/drivers/clk/clk-nspire.c

Hi Daniel,

It's best not to put any file path here, since it could change in the
future.  Please remove it.

> + *
> + *  Copyright (C) 2013 Daniel Tang 
> + *
> + * 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
> + * published by the Free Software Foundation.
> + *
> + */
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +#define MHZ (1000 * 1000)
> +
> +#define BASE_CPU_SHIFT 1
> +#define BASE_CPU_MASK  0x7F
> +
> +#define CPU_AHB_SHIFT  12
> +#define CPU_AHB_MASK   0x07
> +
> +#define FIXED_BASE_SHIFT   8
> +#define FIXED_BASE_MASK0x01
> +
> +#define CLASSIC_BASE_SHIFT 16
> +#define CLASSIC_BASE_MASK  0x1F
> +
> +#define CX_BASE_SHIFT  15
> +#define CX_BASE_MASK   0x3F
> +
> +#define CX_UNKNOWN_SHIFT   21
> +#define CX_UNKNOWN_MASK0x03
> +
> +struct nspire_clk_info {
> +   u32 base_clock;
> +   u16 base_cpu_ratio;
> +   u16 base_ahb_ratio;
> +};
> +
> +
> +#define EXTRACT(var, prop) (((var)>>prop##_SHIFT) & prop##_MASK)
> +static void nspire_clkinfo_cx(u32 val, struct nspire_clk_info *clk)
> +{
> +   if (EXTRACT(val, FIXED_BASE))
> +   clk->base_clock = 48 * MHZ;
> +   else
> +   clk->base_clock = 6 * EXTRACT(val, CX_BASE) * MHZ;
> +
> +   clk->base_cpu_ratio = EXTRACT(val, BASE_CPU) * EXTRACT(val, 
> CX_UNKNOWN);
> +   clk->base_ahb_ratio = clk->base_cpu_ratio * (EXTRACT(val, CPU_AHB) + 
> 1);
> +}
> +
> +static void nspire_clkinfo_classic(u32 val, struct nspire_clk_info *clk)
> +{
> +   if (EXTRACT(val, FIXED_BASE))
> +   clk->base_clock = 27 * MHZ;
> +   else
> +   clk->base_clock = (300 - 6 * EXTRACT(val, CLASSIC_BASE)) * 
> MHZ;
> +
> +   clk->base_cpu_ratio = EXTRACT(val, BASE_CPU) * 2;
> +   clk->base_ahb_ratio = clk->base_cpu_ratio * (EXTRACT(val, CPU_AHB) + 
> 1);
> +}
> +#undef EXTRACT

Any particular reason for the undef?

Rest looks good to me.  If you can respin this patch I'll take it into
clk-next.

Thanks,
Mike
--
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 2/3] video: xilinxfb: Do not use out_be32 IO function

[Timur Tabi]

On Thu, May 30, 2013 at 5:04 PM, Arnd Bergmann  wrote:
>
> This is probably missing barriers, and is wrong on systems on which
> the endianess of the device is different from the CPU.


I suggest what was done in fsl_ssi.c:

#ifdef PPC
#define read_ssi(addr) in_be32(addr)
#define write_ssi(val, addr) out_be32(addr, val)
#define write_ssi_mask(addr, clear, set) clrsetbits_be32(addr, clear, set)
#elif defined ARM
#define read_ssi(addr) readl(addr)
#define write_ssi(val, addr) writel(val, addr)
/*
 * FIXME: Proper locking should be added at write_ssi_mask caller level
 * to ensure this register read/modify/write sequence is race free.
 */
static inline void write_ssi_mask(u32 __iomem *addr, u32 clear, u32 set)
{
u32 val = readl(addr);
val = (val & ~clear) | set;
writel(val, addr);
}
#endif
--
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] mutex: do not unnecessarily deal with waiters

[Davidlohr Bueso]

ping?

On Thu, 2013-05-23 at 16:59 -0700, Davidlohr Bueso wrote:
> From: Davidlohr Bueso 
> 
> Upon entering the slowpath, we immediately attempt to acquire the lock
> by checking if it is already unlocked. If we are lucky enough that this
> is the case, then we don't need to deal with any waiter related logic.
> 
> Furthermore any checks for an empty wait_list are unnecessary as we
> already know that count is non-negative and hence no one is waiting for
> the lock.
> 
> Move the count check and xchg calls to be done before any waiters are
> setup - including waiter debugging. Upon failure to acquire the lock,
> the xchg sets the counter to 0, instead of -1 as it was originally.
> This can be done here since we set it back to -1 right at the beginning
> of the loop so other waiters are woken up when the lock is released.
> 
> When tested on a 8-socket (80 core) system against a vanilla 3.10-rc1
> kernel, this patch provides some small performance benefits (+2-6%).
> While it could be considered in the noise level, the average percentages
> were stable across multiple runs and no performance regressions were seen.
> Two big winners, for small amounts of users (10-100), were the short and
> compute workloads had a +19.36% and +%15.76% in jobs per minute.
>   
> Signed-off-by: Davidlohr Bueso 
> ---
>  kernel/mutex.c | 26 ++
>  1 file changed, 14 insertions(+), 12 deletions(-)
> 
> diff --git a/kernel/mutex.c b/kernel/mutex.c
> index ad53a66..a8cd741 100644
> --- a/kernel/mutex.c
> +++ b/kernel/mutex.c
> @@ -306,7 +306,7 @@ __mutex_lock_common(struct mutex *lock, long state, 
> unsigned int subclass,
>   owner = ACCESS_ONCE(lock->owner);
>   if (owner && !mutex_spin_on_owner(lock, owner)) {
>   mspin_unlock(MLOCK(lock), );
> - break;
> + goto slowpath;
>   }
>  
>   if ((atomic_read(>count) == 1) &&
> @@ -314,8 +314,7 @@ __mutex_lock_common(struct mutex *lock, long state, 
> unsigned int subclass,
>   lock_acquired(>dep_map, ip);
>   mutex_set_owner(lock);
>   mspin_unlock(MLOCK(lock), );
> - preempt_enable();
> - return 0;
> + goto done;
>   }
>   mspin_unlock(MLOCK(lock), );
>  
> @@ -326,7 +325,7 @@ __mutex_lock_common(struct mutex *lock, long state, 
> unsigned int subclass,
>* the owner complete.
>*/
>   if (!owner && (need_resched() || rt_task(task)))
> - break;
> + goto slowpath;
>  
>   /*
>* The cpu_relax() call is a compiler barrier which forces
> @@ -340,6 +339,14 @@ slowpath:
>  #endif
>   spin_lock_mutex(>wait_lock, flags);
>  
> + /* once more, can we acquire the lock? */
> + if (MUTEX_SHOW_NO_WAITER(lock) && (atomic_xchg(>count, 0) == 1)) {
> + lock_acquired(>dep_map, ip);
> + mutex_set_owner(lock);
> + spin_unlock_mutex(>wait_lock, flags);
> + goto done;
> + }
> +
>   debug_mutex_lock_common(lock, );
>   debug_mutex_add_waiter(lock, , task_thread_info(task));
>  
> @@ -347,9 +354,6 @@ slowpath:
>   list_add_tail(, >wait_list);
>   waiter.task = task;
>  
> - if (MUTEX_SHOW_NO_WAITER(lock) && (atomic_xchg(>count, -1) == 1))
> - goto done;
> -
>   lock_contended(>dep_map, ip);
>  
>   for (;;) {
> @@ -363,7 +367,7 @@ slowpath:
>* other waiters:
>*/
>   if (MUTEX_SHOW_NO_WAITER(lock) &&
> -(atomic_xchg(>count, -1) == 1))
> + (atomic_xchg(>count, -1) == 1))
>   break;
>  
>   /*
> @@ -388,9 +392,8 @@ slowpath:
>   spin_lock_mutex(>wait_lock, flags);
>   }
>  
> -done:
> + /* got the lock - cleanup and rejoice! */
>   lock_acquired(>dep_map, ip);
> - /* got the lock - rejoice! */
>   mutex_remove_waiter(lock, , current_thread_info());
>   mutex_set_owner(lock);
>  
> @@ -399,10 +402,9 @@ done:
>   atomic_set(>count, 0);
>  
>   spin_unlock_mutex(>wait_lock, flags);
> -
>   debug_mutex_free_waiter();
> +done:
>   preempt_enable();
> -
>   return 0;
>  }
>  


--
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: skbuff: use _RET_IP_

[Davidlohr Bueso]

On Thu, 2013-05-30 at 13:08 +0200, Bjørn Mork wrote:
> Sergei Shtylyov  writes:
> 
> > Why not "text:%#lx" as already used in this string? It's
> > equivalent to "0x%lx".
> 
> Well, I don't know the reasoning in this case, but I'd like to note that
> those are not strictly equivalent.  Personally I find the formatting of 0
> annoying enough to avoid %#x for any value which may be 0.  It's
> especially bad if you try to line up things by adding leading zeros.

Yep, I found that 0x%lx produced the same output as %p. If you'd rather
I use something else instead, I'm happy to update the patch.

Thanks,
Davidlohr

--
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 -next v2] dmaengine: ste_dma40: fix error return code in d40_probe()

[Wei Yongjun]

On 05/31/2013 02:29 AM, Andy Shevchenko wrote:
> On Thu, May 30, 2013 at 7:32 AM, Wei Yongjun  wrote:
>> In many of the error handling case, the return value 'ret' not set
>> and 0 will be return from d40_probe() even if error, but we should
>> return a negative error code instead in those error handling case.
>> This patch fixed them, and also removed useless variable 'err'.
> Hold on, please.
>
>> --- a/drivers/dma/ste_dma40.c
>> +++ b/drivers/dma/ste_dma40.c
>> @@ -3619,6 +3618,7 @@ static int __init d40_probe(struct platform_device 
>> *pdev)
>> if (IS_ERR(base->lcpa_regulator)) {
>> d40_err(>dev, "Failed to get 
>> lcpa_regulator\n");
>> base->lcpa_regulator = NULL;
>> +   ret = PTR_ERR(base->lcpa_regulator);
> Is it really what we want?
>
> I thixh you may remove that NULL assignment.

Ohh, I will move the ret = PTR_ERR(base->lcpa_regulator) above the NULL
assignment, the failure path test for base->lcpa_regulator to release regulator.

if (base->lcpa_regulator) {
regulator_disable(base->lcpa_regulator);
regulator_put(base->lcpa_regulator);
}

>
>
>> goto failure;
>> }
>>
>> @@ -3647,8 +3647,8 @@ static int __init d40_probe(struct platform_device 
>> *pdev)
>> d40_hw_init(base);
>>
>> if (np) {
>> -   err = of_dma_controller_register(np, d40_xlate, NULL);
>> -   if (err && err != -ENODEV)
>> +   ret = of_dma_controller_register(np, d40_xlate, NULL);
>> +   if (ret && ret != -ENODEV)
> >From the discussion of dw_dmac I remember we decide that ENODEV check
> is redundant.

Get it, I will remove the ENODEV check.

Thanks,
Yongjun Wei

--
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/2] xtensa: Flat DeviceTree copy not future-safe

[Max Filippov]

Hi Vineet,

On Wed, May 29, 2013 at 5:10 PM, Vineet Gupta
 wrote:
> Hi Max,
>
> This patch - acked by you then, got lost in the mist of time. Care to take it 
> in
> via xtensa tree for 3.11

Oops. Thanks for the reminder. Took it to the xtensa-fixes branch.

>  Original Message 
> Subject: [PATCH 2/2] xtensa: Flat DeviceTree copy not future-safe
> Date: Fri, 22 Feb 2013 00:09:22 +0530
> From: Vineet Gupta 
> To: Andrew Morton , Chris Zankel 
> ,
> Max Filippov , Marc Gauthier 
> CC: Vineet Gupta , 
> ,
> 
> Newsgroups: gmane.linux.kernel
> References: <1361471962-25164-1-git-send-email-vgu...@synopsys.com>

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

Re: [PATCH v5 00/13] net: mv643xx_eth DT support and fixes

[David Miller]

From: Sebastian Hesselbarth 
Date: Wed, 29 May 2013 21:32:42 +0200

> For the patches above I suggest to take Patches 1-6 through David
> Miller's branch, and Patches 7-12 through Jason Cooper's when the
> former have appeared on mainline linux. The patch set has been based
> on v3.10-rc3.

Patches 1-6 applied to net-next, and patch #1 queued up for -stable.

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] PCI: set correct value for iov device before device

[Yinghai Lu]

On Thu, May 30, 2013 at 4:22 PM, Bjorn Helgaas  wrote:
> On Thu, May 30, 2013 at 2:27 PM, Yinghai Lu  wrote:
>> On Wed, May 29, 2013 at 11:04 PM, Yinghai Lu  wrote:
>>> On Wed, May 29, 2013 at 10:45 PM, Xudong Hao  wrote:
 Since device registering is put into pci_device_add(), it must set value of
 Virtual Function device's member before the pci_dev is put to device tree. 
 Or
 some relevant subsystem of driver model such as xen will report a incorrect
 IOV device to Xen hypervior.

 Signed-off-by: Xudong Hao 
 ---
  drivers/pci/iov.c | 6 +++---
  1 file changed, 3 insertions(+), 3 deletions(-)

 diff --git a/drivers/pci/iov.c b/drivers/pci/iov.c
 index c93071d..43d3de9 100644
 --- a/drivers/pci/iov.c
 +++ b/drivers/pci/iov.c
 @@ -110,12 +110,12 @@ static int virtfn_add(struct pci_dev *dev, int id, 
 int reset)
 if (reset)
 __pci_reset_function(virtfn);

 -   pci_device_add(virtfn, virtfn->bus);
 -   mutex_unlock(>dev->sriov->lock);
 -
 virtfn->physfn = pci_dev_get(dev);
 virtfn->is_virtfn = 1;

 +   pci_device_add(virtfn, virtfn->bus);
 +   mutex_unlock(>dev->sriov->lock);
 +
 rc = pci_bus_add_device(virtfn);
 sprintf(buf, "virtfn%u", id);
 rc = sysfs_create_link(>dev.kobj, >dev.kobj, buf);
>>>
>>> I have similar patch at
>>> https://patchwork.kernel.org/patch/2562551/
>>>[5/7] PCI, ACPI: Don't glue ACPI dev with pci VFs
>>>
>>> and Jiang has another one
>>> https://patchwork.kernel.org/patch/2613481/
>>>[v3,part1,10/10] PCI, IOV: hide remove and rescan sysfs interfaces
>>> for SR-IOV virtual functions
>>
>> Bjorn,
>>
>> I double check this one, we should split the patch from me or Jiang.
>
> I don't know what the sentence above means.

I mean half of patch
https://patchwork.kernel.org/patch/2562551/
or half of patch
https://patchwork.kernel.org/patch/2613481/

just like what Xudong extracted.

>
>> and the one about set virtfn=1 should be -stable material.
>
> I assume you mean that Jiang's "[v3,part1,10/10] PCI, IOV: hide remove
> and rescan sysfs interfaces for SR-IOV virtual functions" patch does
> not need to be in v3.10, but it should be marked for -stable.

no half of it, move set virtfn=1 two lines forward.

>
> How far back should it go?  v3.9+?

yes. v3.9+

>
>> That will address another problem that is caused by
>> moving device_add from pci_bus_add_device to pci_device_add.
>
> I assume you're talking about a problem caused by 4f535093 ("PCI: Put
> pci_dev in device tree as early as possible").  That commit appeared
> in v3.9.

yes.

>
> If we're asking to add the "hide remove and rescan sysfs interfaces"
> patch to the v3.9 stable series, we should have a description of
> exactly what problem it fixes, and ideally, a bugzilla for it.  Can
> you provide that?

No. that is not what i mean.

That problem have been there when sriov support was added.

>
> That patch appears to be the only one in the [v3,part1,0/10] series
> that actually directly fixes an issue, so it would be nice to have
> more specifics in that changelog to begin with.  The other patches in
> that series appear to to be cleanups and preparation for the real
> fixes that will come later.

yes. even should be separated from that patchset.

Yinghai
--
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.9-stable] ASoC: wm8994: Fix reporting of accessory removal on

[Jonghwan Choi]

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

--

From: "Mark Brown "

commit 9767a58b8b2a0b153c246fb6306c7d48d51bb379 upstream

During recent refactoring the code to report removal when MICDET reports
an absent microphone was removed, causing problems for systems which rely
solely on the MICDET for this functionality. Restore it.

Signed-off-by: Mark Brown 
Signed-off-by: Jonghwan Choi 
---
 sound/soc/codecs/wm8994.c |5 +
 1 file changed, 5 insertions(+)

diff --git a/sound/soc/codecs/wm8994.c b/sound/soc/codecs/wm8994.c
index 8b769ba..f9dc7c0 100644
--- a/sound/soc/codecs/wm8994.c
+++ b/sound/soc/codecs/wm8994.c
@@ -3791,6 +3791,11 @@ static irqreturn_t wm8958_mic_irq(int irq, void
*data)
dev_dbg(codec->dev, "Ignoring removed jack\n");
return IRQ_HANDLED;
}
+   } else if (!(reg & WM8958_MICD_STS)) {
+   snd_soc_jack_report(wm8994->micdet[0].jack, 0,
+   SND_JACK_MECHANICAL | SND_JACK_HEADSET |
+   wm8994->btn_mask);
+   goto out;
}
 
if (wm8994->mic_detecting)
-- 
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.9-stable] ASoC: wm8994: use the correct pointer to get the control

[Jonghwan Choi]

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

--

From: "Vinod Koul "

commit d3134e211e8db7fa833c40b5879fc022693e16c2 upstream

Signed-off-by: Vinod Koul 
Signed-off-by: Mark Brown 
Signed-off-by: Jonghwan Choi 
---
 sound/soc/codecs/wm8994.c |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/sound/soc/codecs/wm8994.c b/sound/soc/codecs/wm8994.c
index 3b269fa..8b769ba 100644
--- a/sound/soc/codecs/wm8994.c
+++ b/sound/soc/codecs/wm8994.c
@@ -1031,7 +1031,7 @@ static int aif1clk_ev(struct snd_soc_dapm_widget *w,
 {
struct snd_soc_codec *codec = w->codec;
struct wm8994_priv *wm8994 = snd_soc_codec_get_drvdata(codec);
-   struct wm8994 *control = codec->control_data;
+   struct wm8994 *control = wm8994->wm8994;
int mask = WM8994_AIF1DAC1L_ENA | WM8994_AIF1DAC1R_ENA;
int i;
int dac;
-- 
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/

[GIT PULL] x86 fixes for v3.10-rc4

[H. Peter Anvin]

Hi Linus,

This is the queue of pending x86 fixes.

3 are EFI-related;
2 are related to early memory initialization;
1 is a build fix for older binutils;
1 is a fix for an eager FPU performance regression -- currently we
  don't allow the use of the FPU at interrupt time *at all* in eager
  mode, which is clearly wrong.  This is the one potentially
  controversial patch in this set as it is a performance regression,
  not a correctness regression, and falls in an area that has,
  obviously, been highly problematic in the past.  If you prefer to
  skip it it is the topmost patch in the set.

The following changes since commit 8f710dd34a46500e135203816c71c3ec567c46fd:

  Merge tag 'sound-3.10' of 
git://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound (2013-05-17 07:17:48 
-0700)

are available in the git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git x86-urgent-for-linus

for you to fetch changes up to 5187b28ff08249ab8a162e802209ed04e271ca02:

  x86: Allow FPU to be used at interrupt time even with eagerfpu (2013-05-30 
16:36:42 -0700)


H. Peter Anvin (1):
  Merge tag 'efi-urgent' into x86/urgent

Jan Beulich (1):
  x86, crc32-pclmul: Fix build with older binutils

Lee, Chun-Yi (1):
  x86, efi: initial the local variable of DataSize to zero

Lingzhu Xiang (1):
  efivarfs: Never return ENOENT from firmware again

Pekka Riikonen (1):
  x86: Allow FPU to be used at interrupt time even with eagerfpu

Seiji Aguchi (1):
  efivar: fix oops in efivar_update_sysfs_entries() caused by memory reuse

Yinghai Lu (1):
  x86, range: fix missing merge during add range

Zhang Yanfei (1):
  x86-64, init: Fix a possible wraparound bug in switchover in head_64.S

 arch/x86/crypto/crc32-pclmul_asm.S |  2 +-
 arch/x86/include/asm/inst.h| 74 --
 arch/x86/kernel/head_64.S  |  6 ++--
 arch/x86/kernel/i387.c | 14 +++-
 arch/x86/platform/efi/efi.c|  2 +-
 drivers/firmware/efi/efivars.c |  8 ++---
 fs/efivarfs/file.c | 14 ++--
 kernel/range.c |  8 +++--
 8 files changed, 103 insertions(+), 25 deletions(-)

diff --git a/arch/x86/crypto/crc32-pclmul_asm.S 
b/arch/x86/crypto/crc32-pclmul_asm.S
index 94c27df..f247304 100644
--- a/arch/x86/crypto/crc32-pclmul_asm.S
+++ b/arch/x86/crypto/crc32-pclmul_asm.S
@@ -240,7 +240,7 @@ fold_64:
pand%xmm3, %xmm1
PCLMULQDQ 0x00, CONSTANT, %xmm1
pxor%xmm2, %xmm1
-   pextrd  $0x01, %xmm1, %eax
+   PEXTRD  0x01, %xmm1, %eax
 
ret
 ENDPROC(crc32_pclmul_le_16)
diff --git a/arch/x86/include/asm/inst.h b/arch/x86/include/asm/inst.h
index 280bf7f..3e11527 100644
--- a/arch/x86/include/asm/inst.h
+++ b/arch/x86/include/asm/inst.h
@@ -9,12 +9,68 @@
 
 #define REG_NUM_INVALID100
 
-#define REG_TYPE_R64   0
-#define REG_TYPE_XMM   1
+#define REG_TYPE_R32   0
+#define REG_TYPE_R64   1
+#define REG_TYPE_XMM   2
 #define REG_TYPE_INVALID   100
 
+   .macro R32_NUM opd r32
+   \opd = REG_NUM_INVALID
+   .ifc \r32,%eax
+   \opd = 0
+   .endif
+   .ifc \r32,%ecx
+   \opd = 1
+   .endif
+   .ifc \r32,%edx
+   \opd = 2
+   .endif
+   .ifc \r32,%ebx
+   \opd = 3
+   .endif
+   .ifc \r32,%esp
+   \opd = 4
+   .endif
+   .ifc \r32,%ebp
+   \opd = 5
+   .endif
+   .ifc \r32,%esi
+   \opd = 6
+   .endif
+   .ifc \r32,%edi
+   \opd = 7
+   .endif
+#ifdef CONFIG_X86_64
+   .ifc \r32,%r8d
+   \opd = 8
+   .endif
+   .ifc \r32,%r9d
+   \opd = 9
+   .endif
+   .ifc \r32,%r10d
+   \opd = 10
+   .endif
+   .ifc \r32,%r11d
+   \opd = 11
+   .endif
+   .ifc \r32,%r12d
+   \opd = 12
+   .endif
+   .ifc \r32,%r13d
+   \opd = 13
+   .endif
+   .ifc \r32,%r14d
+   \opd = 14
+   .endif
+   .ifc \r32,%r15d
+   \opd = 15
+   .endif
+#endif
+   .endm
+
.macro R64_NUM opd r64
\opd = REG_NUM_INVALID
+#ifdef CONFIG_X86_64
.ifc \r64,%rax
\opd = 0
.endif
@@ -63,6 +119,7 @@
.ifc \r64,%r15
\opd = 15
.endif
+#endif
.endm
 
.macro XMM_NUM opd xmm
@@ -118,10 +175,13 @@
.endm
 
.macro REG_TYPE type reg
+   R32_NUM reg_type_r32 \reg
R64_NUM reg_type_r64 \reg
XMM_NUM reg_type_xmm \reg
.if reg_type_r64 <> REG_NUM_INVALID
\type = REG_TYPE_R64
+   .elseif reg_type_r32 <> REG_NUM_INVALID
+   \type = REG_TYPE_R32
.elseif reg_type_xmm <> REG_NUM_INVALID
\type = REG_TYPE_XMM
.else
@@ -162,6 +222,16 @@
.byte \imm8
.endm
 
+   .macro PEXTRD imm8 xmm gpr
+   R32_NUM extrd_opd1 \gpr
+   XMM_NUM extrd_opd2 \xmm
+   

[PATCH v8 07/11] KVM: MMU: do not reuse the obsolete page

[Xiao Guangrong]

The obsolete page will be zapped soon, do not reuse it to
reduce future page fault

Signed-off-by: Xiao Guangrong 
---
 arch/x86/kvm/mmu.c |3 +++
 1 files changed, 3 insertions(+), 0 deletions(-)

diff --git a/arch/x86/kvm/mmu.c b/arch/x86/kvm/mmu.c
index 3fd060a..0880b9b4 100644
--- a/arch/x86/kvm/mmu.c
+++ b/arch/x86/kvm/mmu.c
@@ -1875,6 +1875,9 @@ static struct kvm_mmu_page *kvm_mmu_get_page(struct 
kvm_vcpu *vcpu,
role.quadrant = quadrant;
}
for_each_gfn_sp(vcpu->kvm, sp, gfn) {
+   if (is_obsolete_sp(vcpu->kvm, sp))
+   continue;
+
if (!need_sync && sp->unsync)
need_sync = true;
 
-- 
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 v8 01/11] KVM: x86: drop calling kvm_mmu_zap_all in emulator_fix_hypercall

[Xiao Guangrong]

Quote Gleb's mail:

| Back then kvm->lock protected memslot access so code like:
|
| mutex_lock(>kvm->lock);
| kvm_mmu_zap_all(vcpu->kvm);
| mutex_unlock(>kvm->lock);
|
| which is what 7aa81cc0 does was enough to guaranty that no vcpu will
| run while code is patched. This is no longer the case and
| mutex_lock(>kvm->lock); is gone from that code path long time ago,
| so now kvm_mmu_zap_all() there is useless and the code is incorrect.

So we drop it and it will be fixed later

Signed-off-by: Xiao Guangrong 
---
 arch/x86/kvm/x86.c |7 ---
 1 files changed, 0 insertions(+), 7 deletions(-)

diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c
index 8d28810..6739b1d 100644
--- a/arch/x86/kvm/x86.c
+++ b/arch/x86/kvm/x86.c
@@ -5523,13 +5523,6 @@ static int emulator_fix_hypercall(struct 
x86_emulate_ctxt *ctxt)
char instruction[3];
unsigned long rip = kvm_rip_read(vcpu);
 
-   /*
-* Blow out the MMU to ensure that no other VCPU has an active mapping
-* to ensure that the updated hypercall appears atomically across all
-* VCPUs.
-*/
-   kvm_mmu_zap_all(vcpu->kvm);
-
kvm_x86_ops->patch_hypercall(vcpu, instruction);
 
return emulator_write_emulated(ctxt, rip, instruction, 3, NULL);
-- 
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 v8 08/11] KVM: MMU: zap pages in batch

[Xiao Guangrong]

Zap at lease 10 pages before releasing mmu-lock to reduce the overload
caused by requiring lock

After the patch, kvm_zap_obsolete_pages can forward progress anyway,
so update the comments

[ It improves the case 0.6% ~ 1% that do kernel building meanwhile read
  PCI ROM. ]

Note: i am not sure that "10" is the best speculative value, i just
guessed that '10' can make vcpu do not spend long time on
kvm_zap_obsolete_pages and do not cause mmu-lock too hungry.

Signed-off-by: Xiao Guangrong 
---
 arch/x86/kvm/mmu.c |   35 +++
 1 files changed, 11 insertions(+), 24 deletions(-)

diff --git a/arch/x86/kvm/mmu.c b/arch/x86/kvm/mmu.c
index 0880b9b4..fe9d6f1 100644
--- a/arch/x86/kvm/mmu.c
+++ b/arch/x86/kvm/mmu.c
@@ -4197,14 +4197,18 @@ void kvm_mmu_slot_remove_write_access(struct kvm *kvm, 
int slot)
spin_unlock(>mmu_lock);
 }
 
+#define BATCH_ZAP_PAGES10
 static void kvm_zap_obsolete_pages(struct kvm *kvm)
 {
struct kvm_mmu_page *sp, *node;
LIST_HEAD(invalid_list);
+   int batch = 0;
 
 restart:
list_for_each_entry_safe_reverse(sp, node,
  >arch.active_mmu_pages, link) {
+   int ret;
+
/*
 * No obsolete page exists before new created page since
 * active_mmu_pages is the FIFO list.
@@ -4213,28 +4217,6 @@ restart:
break;
 
/*
-* Do not repeatedly zap a root page to avoid unnecessary
-* KVM_REQ_MMU_RELOAD, otherwise we may not be able to
-* progress:
-*vcpu 0vcpu 1
-* call vcpu_enter_guest():
-*1): handle KVM_REQ_MMU_RELOAD
-*and require mmu-lock to
-*load mmu
-* repeat:
-*1): zap root page and
-*send KVM_REQ_MMU_RELOAD
-*
-*2): if (cond_resched_lock(mmu-lock))
-*
-*2): hold mmu-lock and load mmu
-*
-*3): see KVM_REQ_MMU_RELOAD bit
-*on vcpu->requests is set
-*then return 1 to call
-*vcpu_enter_guest() again.
-*goto repeat;
-*
 * Since we are reversely walking the list and the invalid
 * list will be moved to the head, skip the invalid page
 * can help us to avoid the infinity list walking.
@@ -4242,13 +4224,18 @@ restart:
if (sp->role.invalid)
continue;
 
-   if (need_resched() || spin_needbreak(>mmu_lock)) {
+   if (batch >= BATCH_ZAP_PAGES &&
+ (need_resched() || spin_needbreak(>mmu_lock))) {
+   batch = 0;
kvm_mmu_commit_zap_page(kvm, _list);
cond_resched_lock(>mmu_lock);
goto restart;
}
 
-   if (kvm_mmu_prepare_zap_page(kvm, sp, _list))
+   ret = kvm_mmu_prepare_zap_page(kvm, sp, _list);
+   batch += ret;
+
+   if (ret)
goto restart;
}
 
-- 
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 v8 06/11] KVM: MMU: add tracepoint for kvm_mmu_invalidate_all_pages

[Xiao Guangrong]

It is good for debug and development

Signed-off-by: Xiao Guangrong 
---
 arch/x86/kvm/mmu.c  |1 +
 arch/x86/kvm/mmutrace.h |   20 
 2 files changed, 21 insertions(+), 0 deletions(-)

diff --git a/arch/x86/kvm/mmu.c b/arch/x86/kvm/mmu.c
index c8063b9..3fd060a 100644
--- a/arch/x86/kvm/mmu.c
+++ b/arch/x86/kvm/mmu.c
@@ -4264,6 +4264,7 @@ restart:
 void kvm_mmu_invalidate_zap_all_pages(struct kvm *kvm)
 {
spin_lock(>mmu_lock);
+   trace_kvm_mmu_invalidate_zap_all_pages(kvm);
kvm->arch.mmu_valid_gen++;
 
kvm_zap_obsolete_pages(kvm);
diff --git a/arch/x86/kvm/mmutrace.h b/arch/x86/kvm/mmutrace.h
index 697f466..eb444dd 100644
--- a/arch/x86/kvm/mmutrace.h
+++ b/arch/x86/kvm/mmutrace.h
@@ -276,6 +276,26 @@ TRACE_EVENT(
  __spte_satisfied(old_spte), __spte_satisfied(new_spte)
)
 );
+
+TRACE_EVENT(
+   kvm_mmu_invalidate_zap_all_pages,
+   TP_PROTO(struct kvm *kvm),
+   TP_ARGS(kvm),
+
+   TP_STRUCT__entry(
+   __field(unsigned long, mmu_valid_gen)
+   __field(unsigned int, mmu_used_pages)
+   ),
+
+   TP_fast_assign(
+   __entry->mmu_valid_gen = kvm->arch.mmu_valid_gen;
+   __entry->mmu_used_pages = kvm->arch.n_used_mmu_pages;
+   ),
+
+   TP_printk("kvm-mmu-valid-gen %lx used_pages %x",
+ __entry->mmu_valid_gen, __entry->mmu_used_pages
+   )
+);
 #endif /* _TRACE_KVMMMU_H */
 
 #undef TRACE_INCLUDE_PATH
-- 
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 v8 10/11] KVM: MMU: reclaim the zapped-obsolete page first

[Xiao Guangrong]

As Marcelo pointed out that
| "(retention of large number of pages while zapping)
| can be fatal, it can lead to OOM and host crash"

We introduce a list, kvm->arch.zapped_obsolete_pages, to link all
the pages which are deleted from the mmu cache but not actually
freed. When page reclaiming is needed, we always zap this kind of
pages first.

[
  Can we use this list to instead all of "invalid_list"? That may
  be interesting and will cause big change. Will do it separately
  if it is necessary.
]
Signed-off-by: Xiao Guangrong 
---
 arch/x86/include/asm/kvm_host.h |2 ++
 arch/x86/kvm/mmu.c  |   21 +
 arch/x86/kvm/x86.c  |1 +
 3 files changed, 20 insertions(+), 4 deletions(-)

diff --git a/arch/x86/include/asm/kvm_host.h b/arch/x86/include/asm/kvm_host.h
index bff7d46..1f98c1b 100644
--- a/arch/x86/include/asm/kvm_host.h
+++ b/arch/x86/include/asm/kvm_host.h
@@ -536,6 +536,8 @@ struct kvm_arch {
 * Hash table of struct kvm_mmu_page.
 */
struct list_head active_mmu_pages;
+   struct list_head zapped_obsolete_pages;
+
struct list_head assigned_dev_head;
struct iommu_domain *iommu_domain;
int iommu_flags;
diff --git a/arch/x86/kvm/mmu.c b/arch/x86/kvm/mmu.c
index 674c044..79af88a 100644
--- a/arch/x86/kvm/mmu.c
+++ b/arch/x86/kvm/mmu.c
@@ -4211,7 +4211,6 @@ void kvm_mmu_slot_remove_write_access(struct kvm *kvm, 
int slot)
 static void kvm_zap_obsolete_pages(struct kvm *kvm)
 {
struct kvm_mmu_page *sp, *node;
-   LIST_HEAD(invalid_list);
int batch = 0;
 
 restart:
@@ -4244,7 +4243,8 @@ restart:
goto restart;
}
 
-   ret = kvm_mmu_prepare_zap_page(kvm, sp, _list);
+   ret = kvm_mmu_prepare_zap_page(kvm, sp,
+   >arch.zapped_obsolete_pages);
batch += ret;
 
if (ret)
@@ -4255,7 +4255,7 @@ restart:
 * Should flush tlb before free page tables since lockless-walking
 * may use the pages.
 */
-   kvm_mmu_commit_zap_page(kvm, _list);
+   kvm_mmu_commit_zap_page(kvm, >arch.zapped_obsolete_pages);
 }
 
 /*
@@ -4306,6 +4306,11 @@ restart:
spin_unlock(>mmu_lock);
 }
 
+static bool kvm_has_zapped_obsolete_pages(struct kvm *kvm)
+{
+   return unlikely(!list_empty_careful(>arch.zapped_obsolete_pages));
+}
+
 static int mmu_shrink(struct shrinker *shrink, struct shrink_control *sc)
 {
struct kvm *kvm;
@@ -4334,15 +4339,23 @@ static int mmu_shrink(struct shrinker *shrink, struct 
shrink_control *sc)
 * want to shrink a VM that only started to populate its MMU
 * anyway.
 */
-   if (!kvm->arch.n_used_mmu_pages)
+   if (!kvm->arch.n_used_mmu_pages &&
+ !kvm_has_zapped_obsolete_pages(kvm))
continue;
 
idx = srcu_read_lock(>srcu);
spin_lock(>mmu_lock);
 
+   if (kvm_has_zapped_obsolete_pages(kvm)) {
+   kvm_mmu_commit_zap_page(kvm,
+ >arch.zapped_obsolete_pages);
+   goto unlock;
+   }
+
prepare_zap_oldest_mmu_page(kvm, _list);
kvm_mmu_commit_zap_page(kvm, _list);
 
+unlock:
spin_unlock(>mmu_lock);
srcu_read_unlock(>srcu, idx);
 
diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c
index 15e10f7..6402951 100644
--- a/arch/x86/kvm/x86.c
+++ b/arch/x86/kvm/x86.c
@@ -6832,6 +6832,7 @@ int kvm_arch_init_vm(struct kvm *kvm, unsigned long type)
return -EINVAL;
 
INIT_LIST_HEAD(>arch.active_mmu_pages);
+   INIT_LIST_HEAD(>arch.zapped_obsolete_pages);
INIT_LIST_HEAD(>arch.assigned_dev_head);
 
/* Reserve bit 0 of irq_sources_bitmap for userspace irq source */
-- 
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 v8 09/11] KVM: MMU: collapse TLB flushes when zap all pages

[Xiao Guangrong]

kvm_zap_obsolete_pages uses lock-break technique to zap pages,
it will flush tlb every time when it does lock-break

We can reload mmu on all vcpus after updating the generation
number so that the obsolete pages are not used on any vcpus,
after that we do not need to flush tlb when obsolete pages
are zapped

It will do kvm_mmu_prepare_zap_page many times and use one
kvm_mmu_commit_zap_page to collapse tlb flush, the side-effects
is that causes obsolete pages unlinked from active_list but leave
on hash-list, so we add the comment around the hash list walker

Note: kvm_mmu_commit_zap_page is still needed before free
the pages since other vcpus may be doing locklessly shadow
page walking

Signed-off-by: Xiao Guangrong 
---
 arch/x86/kvm/mmu.c |   33 ++---
 1 files changed, 30 insertions(+), 3 deletions(-)

diff --git a/arch/x86/kvm/mmu.c b/arch/x86/kvm/mmu.c
index fe9d6f1..674c044 100644
--- a/arch/x86/kvm/mmu.c
+++ b/arch/x86/kvm/mmu.c
@@ -1654,6 +1654,16 @@ static int kvm_mmu_prepare_zap_page(struct kvm *kvm, 
struct kvm_mmu_page *sp,
 static void kvm_mmu_commit_zap_page(struct kvm *kvm,
struct list_head *invalid_list);
 
+/*
+ * NOTE: we should pay more attention on the zapped-obsolete page
+ * (is_obsolete_sp(sp) && sp->role.invalid) when you do hash list walk
+ * since it has been deleted from active_mmu_pages but still can be found
+ * at hast list.
+ *
+ * for_each_gfn_indirect_valid_sp has skipped that kind of page and
+ * kvm_mmu_get_page(), the only user of for_each_gfn_sp(), has skipped
+ * all the obsolete pages.
+ */
 #define for_each_gfn_sp(_kvm, _sp, _gfn)   \
hlist_for_each_entry(_sp,   \
  &(_kvm)->arch.mmu_page_hash[kvm_page_table_hashfn(_gfn)], hash_link) \
@@ -4224,11 +4234,13 @@ restart:
if (sp->role.invalid)
continue;
 
+   /*
+* Need not flush tlb since we only zap the sp with invalid
+* generation number.
+*/
if (batch >= BATCH_ZAP_PAGES &&
- (need_resched() || spin_needbreak(>mmu_lock))) {
+ cond_resched_lock(>mmu_lock)) {
batch = 0;
-   kvm_mmu_commit_zap_page(kvm, _list);
-   cond_resched_lock(>mmu_lock);
goto restart;
}
 
@@ -4239,6 +4251,10 @@ restart:
goto restart;
}
 
+   /*
+* Should flush tlb before free page tables since lockless-walking
+* may use the pages.
+*/
kvm_mmu_commit_zap_page(kvm, _list);
 }
 
@@ -4257,6 +4273,17 @@ void kvm_mmu_invalidate_zap_all_pages(struct kvm *kvm)
trace_kvm_mmu_invalidate_zap_all_pages(kvm);
kvm->arch.mmu_valid_gen++;
 
+   /*
+* Notify all vcpus to reload its shadow page table
+* and flush TLB. Then all vcpus will switch to new
+* shadow page table with the new mmu_valid_gen.
+*
+* Note: we should do this under the protection of
+* mmu-lock, otherwise, vcpu would purge shadow page
+* but miss tlb flush.
+*/
+   kvm_reload_remote_mmus(kvm);
+
kvm_zap_obsolete_pages(kvm);
spin_unlock(>mmu_lock);
 }
-- 
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 v8 04/11] KVM: x86: use the fast way to invalidate all pages

[Xiao Guangrong]

Replace kvm_mmu_zap_all by kvm_mmu_invalidate_zap_all_pages

Signed-off-by: Xiao Guangrong 
---
 arch/x86/kvm/mmu.c |   15 ---
 arch/x86/kvm/x86.c |4 ++--
 2 files changed, 2 insertions(+), 17 deletions(-)

diff --git a/arch/x86/kvm/mmu.c b/arch/x86/kvm/mmu.c
index d71bf8f..c8063b9 100644
--- a/arch/x86/kvm/mmu.c
+++ b/arch/x86/kvm/mmu.c
@@ -4194,21 +4194,6 @@ void kvm_mmu_slot_remove_write_access(struct kvm *kvm, 
int slot)
spin_unlock(>mmu_lock);
 }
 
-void kvm_mmu_zap_all(struct kvm *kvm)
-{
-   struct kvm_mmu_page *sp, *node;
-   LIST_HEAD(invalid_list);
-
-   spin_lock(>mmu_lock);
-restart:
-   list_for_each_entry_safe(sp, node, >arch.active_mmu_pages, link)
-   if (kvm_mmu_prepare_zap_page(kvm, sp, _list))
-   goto restart;
-
-   kvm_mmu_commit_zap_page(kvm, _list);
-   spin_unlock(>mmu_lock);
-}
-
 static void kvm_zap_obsolete_pages(struct kvm *kvm)
 {
struct kvm_mmu_page *sp, *node;
diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c
index 3758ff9..15e10f7 100644
--- a/arch/x86/kvm/x86.c
+++ b/arch/x86/kvm/x86.c
@@ -7066,13 +7066,13 @@ void kvm_arch_commit_memory_region(struct kvm *kvm,
 
 void kvm_arch_flush_shadow_all(struct kvm *kvm)
 {
-   kvm_mmu_zap_all(kvm);
+   kvm_mmu_invalidate_zap_all_pages(kvm);
 }
 
 void kvm_arch_flush_shadow_memslot(struct kvm *kvm,
   struct kvm_memory_slot *slot)
 {
-   kvm_arch_flush_shadow_all(kvm);
+   kvm_mmu_invalidate_zap_all_pages(kvm);
 }
 
 int kvm_arch_vcpu_runnable(struct kvm_vcpu *vcpu)
-- 
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 v8 02/11] KVM: MMU: drop unnecessary kvm_reload_remote_mmus

[Xiao Guangrong]

It is the responsibility of kvm_mmu_zap_all that keeps the
consistent of mmu and tlbs. And it is also unnecessary after
zap all mmio sptes since no mmio spte exists on root shadow
page and it can not be cached into tlb

Signed-off-by: Xiao Guangrong 
---
 arch/x86/kvm/x86.c |5 +
 1 files changed, 1 insertions(+), 4 deletions(-)

diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c
index 6739b1d..3758ff9 100644
--- a/arch/x86/kvm/x86.c
+++ b/arch/x86/kvm/x86.c
@@ -7060,16 +7060,13 @@ void kvm_arch_commit_memory_region(struct kvm *kvm,
 * If memory slot is created, or moved, we need to clear all
 * mmio sptes.
 */
-   if ((change == KVM_MR_CREATE) || (change == KVM_MR_MOVE)) {
+   if ((change == KVM_MR_CREATE) || (change == KVM_MR_MOVE))
kvm_mmu_zap_mmio_sptes(kvm);
-   kvm_reload_remote_mmus(kvm);
-   }
 }
 
 void kvm_arch_flush_shadow_all(struct kvm *kvm)
 {
kvm_mmu_zap_all(kvm);
-   kvm_reload_remote_mmus(kvm);
 }
 
 void kvm_arch_flush_shadow_memslot(struct kvm *kvm,
-- 
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 v8 11/11] KVM: MMU: reduce KVM_REQ_MMU_RELOAD when root page is zapped

[Xiao Guangrong]

From: Gleb Natapov 

Quote Gleb's mail:
| why don't we check for sp->role.invalid in
| kvm_mmu_prepare_zap_page before calling kvm_reload_remote_mmus()?

and

| Actually we can add check for is_obsolete_sp() there too since
| kvm_mmu_invalidate_all_pages() already calls kvm_reload_remote_mmus()
| after incrementing mmu_valid_gen.

[ Xiao: add some comments and the check of is_obsolete_sp() ]

Signed-off-by: Gleb Natapov 
Signed-off-by: Xiao Guangrong 
---
 arch/x86/kvm/mmu.c |8 +++-
 1 files changed, 7 insertions(+), 1 deletions(-)

diff --git a/arch/x86/kvm/mmu.c b/arch/x86/kvm/mmu.c
index 79af88a..6941fa7 100644
--- a/arch/x86/kvm/mmu.c
+++ b/arch/x86/kvm/mmu.c
@@ -2108,7 +2108,13 @@ static int kvm_mmu_prepare_zap_page(struct kvm *kvm, 
struct kvm_mmu_page *sp,
kvm_mod_used_mmu_pages(kvm, -1);
} else {
list_move(>link, >arch.active_mmu_pages);
-   kvm_reload_remote_mmus(kvm);
+
+   /*
+* The obsolete pages can not be used on any vcpus.
+* See the comments in kvm_mmu_invalidate_zap_all_pages().
+*/
+   if (!sp->role.invalid && !is_obsolete_sp(kvm, sp))
+   kvm_reload_remote_mmus(kvm);
}
 
sp->role.invalid = 1;
-- 
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 v8 05/11] KVM: MMU: show mmu_valid_gen in shadow page related tracepoints

[Xiao Guangrong]

Show sp->mmu_valid_gen

Signed-off-by: Xiao Guangrong 
---
 arch/x86/kvm/mmutrace.h |   22 --
 1 files changed, 12 insertions(+), 10 deletions(-)

diff --git a/arch/x86/kvm/mmutrace.h b/arch/x86/kvm/mmutrace.h
index b8f6172..697f466 100644
--- a/arch/x86/kvm/mmutrace.h
+++ b/arch/x86/kvm/mmutrace.h
@@ -7,16 +7,18 @@
 #undef TRACE_SYSTEM
 #define TRACE_SYSTEM kvmmmu
 
-#define KVM_MMU_PAGE_FIELDS \
-   __field(__u64, gfn) \
-   __field(__u32, role) \
-   __field(__u32, root_count) \
+#define KVM_MMU_PAGE_FIELDS\
+   __field(unsigned long, mmu_valid_gen)   \
+   __field(__u64, gfn) \
+   __field(__u32, role)\
+   __field(__u32, root_count)  \
__field(bool, unsync)
 
-#define KVM_MMU_PAGE_ASSIGN(sp) \
-   __entry->gfn = sp->gfn;  \
-   __entry->role = sp->role.word;   \
-   __entry->root_count = sp->root_count;\
+#define KVM_MMU_PAGE_ASSIGN(sp)\
+   __entry->mmu_valid_gen = sp->mmu_valid_gen; \
+   __entry->gfn = sp->gfn; \
+   __entry->role = sp->role.word;  \
+   __entry->root_count = sp->root_count;   \
__entry->unsync = sp->unsync;
 
 #define KVM_MMU_PAGE_PRINTK() ({   \
@@ -28,8 +30,8 @@
\
role.word = __entry->role;  \
\
-   trace_seq_printf(p, "sp gfn %llx %u%s q%u%s %s%s"   \
-" %snxe root %u %s%c", \
+   trace_seq_printf(p, "sp gen %lx gfn %llx %u%s q%u%s %s%s"   \
+" %snxe root %u %s%c", __entry->mmu_valid_gen, \
 __entry->gfn, role.level,  \
 role.cr4_pae ? " pae" : "",\
 role.quadrant, \
-- 
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 v8 00/11] KVM: MMU: fast zap all shadow pages

[Xiao Guangrong]

Hi Gleb, Paolo, Marcelo,

I have putted the potential controversial patches to the latter that are
patch 8 ~ 10, patch 11 depends on patch 9. Other patches are fully reviewed,
I think its are ready for being merged. If not luck enough, further discussion
is needed, could you please apply that patches first? :)

Thank you in advance!

Some points are raised during discussion but missed in this version:
1) Gleb's idea that skip obsolete pages in the hast list walker

   Unfortunately, it is not safe. There has a window between updating
   valid-gen and reloading mmu, in that window, the obsolete page can
   be used by vcpu, but the guest page table fail to be write-protected
   (since the obsolete page is skipped in mmu_need_write_protect()).

   Instead, we can only skip the zapped-obsolete page
   (is_obsolete_sp(sp) && sp->role.invalid)), the current code has already
   skip them but put the comment around the hash list walker to warn the
   further development.

2) Marcelo's comment that obsolete pages can cause the number of shadow page
   greater than the n_max_mmu_pages

   I am not sure this is really a problem, it only exists in the really tiny
   window and the page-reclaim path are able to handle the obsolete pages.
   Furthermore, we can properly reduce n_max_mmu_pages to make that window
   more tiny.

   Anyway, like commit 5d21881432 shows that "the mmu counters are for
   beancounting purposes only", maybe that window is allowed.

Changlog:
V8:
  1): add some comments to explain FIFO around active_mmu_list address
  Marcelo's comments.

  2): the page-reclaim path may fail to free zapped-obsolete pages pointed
  out by Marcelo, the patchset fixes it by listing all zapped obsolete
  pages on a global list, always free page from that list first.

  3): address Marcelo's suggestion to move the "zap pages in batch" patch
  to the latter.

  4): drop the previous patch which introduced
  kvm_mmu_prepare_zap_obsolete_page(), instead, we put the comments
  around hash list walker to warn the user that the zapped-obsolete
  page still live on hash list.

  5): add the note into the changelog of "zap pages in batch" patch to explain
  the batch number is the speculative value based on Takuya's comments.

V7:
  1): separate some optimization into two patches which do not reuse
  the obsolete pages and collapse tlb flushes, suggested by Marcelo.

  2): make the patch based on Gleb's diff change which reduce
  KVM_REQ_MMU_RELOAD when root page is being zapped.

  3): remove calling kvm_mmu_zap_page when patching hypercall, investigated
  by Gleb.

  4): drop the patch which deleted page from hash list at the "prepare"
  time since it can break the walk based on hash list.

  5): rename kvm_mmu_invalidate_all_pages to kvm_mmu_invalidate_zap_all_pages.

  6): introduce kvm_mmu_prepare_zap_obsolete_page which is used to zap obsolete
  page to collapse tlb flushes.

V6:
  1): reversely walk active_list to skip the new created pages based
  on the comments from Gleb and Paolo.

  2): completely replace kvm_mmu_zap_all by kvm_mmu_invalidate_all_pages
  based on Gleb's comments.

  3): improve the parameters of kvm_mmu_invalidate_all_pages based on
  Gleb's comments.
 
  4): rename kvm_mmu_invalidate_memslot_pages to kvm_mmu_invalidate_all_pages
  5): rename zap_invalid_pages to kvm_zap_obsolete_pages

V5:
  1): rename is_valid_sp to is_obsolete_sp
  2): use lock-break technique to zap all old pages instead of only pages
  linked on invalid slot's rmap suggested by Marcelo.
  3): trace invalid pages and kvm_mmu_invalidate_memslot_pages()
  4): rename kvm_mmu_invalid_memslot_pages to kvm_mmu_invalidate_memslot_pages
  according to Takuya's comments.

V4:
  1): drop unmapping invalid rmap out of mmu-lock and use lock-break technique
  instead. Thanks to Gleb's comments.

  2): needn't handle invalid-gen pages specially due to page table always
  switched by KVM_REQ_MMU_RELOAD. Thanks to Marcelo's comments.

V3:
  completely redesign the algorithm, please see below.

V2:
  - do not reset n_requested_mmu_pages and n_max_mmu_pages
  - batch free root shadow pages to reduce vcpu notification and mmu-lock
contention
  - remove the first patch that introduce kvm->arch.mmu_cache since we only
'memset zero' on hashtable rather than all mmu cache members in this
version
  - remove unnecessary kvm_reload_remote_mmus after kvm_mmu_zap_all

* Issue
The current kvm_mmu_zap_all is really slow - it is holding mmu-lock to
walk and zap all shadow pages one by one, also it need to zap all guest
page's rmap and all shadow page's parent spte list. Particularly, things
become worse if guest uses more memory or vcpus. It is not good for
scalability.

* Idea
KVM maintains a global mmu invalid generation-number which is stored in
kvm->arch.mmu_valid_gen and every shadow page stores the current global
generation-number into sp->mmu_valid_gen when 

[PATCH v8 03/11] KVM: MMU: fast invalidate all pages

[Xiao Guangrong]

The current kvm_mmu_zap_all is really slow - it is holding mmu-lock to
walk and zap all shadow pages one by one, also it need to zap all guest
page's rmap and all shadow page's parent spte list. Particularly, things
become worse if guest uses more memory or vcpus. It is not good for
scalability

In this patch, we introduce a faster way to invalidate all shadow pages.
KVM maintains a global mmu invalid generation-number which is stored in
kvm->arch.mmu_valid_gen and every shadow page stores the current global
generation-number into sp->mmu_valid_gen when it is created

When KVM need zap all shadow pages sptes, it just simply increase the
global generation-number then reload root shadow pages on all vcpus.
Vcpu will create a new shadow page table according to current kvm's
generation-number. It ensures the old pages are not used any more.
Then the obsolete pages (sp->mmu_valid_gen != kvm->arch.mmu_valid_gen)
are zapped by using lock-break technique

Signed-off-by: Xiao Guangrong 
---
 arch/x86/include/asm/kvm_host.h |2 +
 arch/x86/kvm/mmu.c  |   90 +++
 arch/x86/kvm/mmu.h  |1 +
 3 files changed, 93 insertions(+), 0 deletions(-)

diff --git a/arch/x86/include/asm/kvm_host.h b/arch/x86/include/asm/kvm_host.h
index 3741c65..bff7d46 100644
--- a/arch/x86/include/asm/kvm_host.h
+++ b/arch/x86/include/asm/kvm_host.h
@@ -222,6 +222,7 @@ struct kvm_mmu_page {
int root_count;  /* Currently serving as active root */
unsigned int unsync_children;
unsigned long parent_ptes;  /* Reverse mapping for parent_pte */
+   unsigned long mmu_valid_gen;
DECLARE_BITMAP(unsync_child_bitmap, 512);
 
 #ifdef CONFIG_X86_32
@@ -529,6 +530,7 @@ struct kvm_arch {
unsigned int n_requested_mmu_pages;
unsigned int n_max_mmu_pages;
unsigned int indirect_shadow_pages;
+   unsigned long mmu_valid_gen;
struct hlist_head mmu_page_hash[KVM_NUM_MMU_PAGES];
/*
 * Hash table of struct kvm_mmu_page.
diff --git a/arch/x86/kvm/mmu.c b/arch/x86/kvm/mmu.c
index f8ca2f3..d71bf8f 100644
--- a/arch/x86/kvm/mmu.c
+++ b/arch/x86/kvm/mmu.c
@@ -1511,6 +1511,12 @@ static struct kvm_mmu_page *kvm_mmu_alloc_page(struct 
kvm_vcpu *vcpu,
if (!direct)
sp->gfns = mmu_memory_cache_alloc(>arch.mmu_page_cache);
set_page_private(virt_to_page(sp->spt), (unsigned long)sp);
+
+   /*
+* The active_mmu_pages list is the FIFO list, do not move the
+* page until it is zapped. kvm_zap_obsolete_pages depends on
+* this feature. See the comments in kvm_zap_obsolete_pages().
+*/
list_add(>link, >kvm->arch.active_mmu_pages);
sp->parent_ptes = 0;
mmu_page_add_parent_pte(vcpu, sp, parent_pte);
@@ -1838,6 +1844,11 @@ static void clear_sp_write_flooding_count(u64 *spte)
__clear_sp_write_flooding_count(sp);
 }
 
+static bool is_obsolete_sp(struct kvm *kvm, struct kvm_mmu_page *sp)
+{
+   return unlikely(sp->mmu_valid_gen != kvm->arch.mmu_valid_gen);
+}
+
 static struct kvm_mmu_page *kvm_mmu_get_page(struct kvm_vcpu *vcpu,
 gfn_t gfn,
 gva_t gaddr,
@@ -1900,6 +1911,7 @@ static struct kvm_mmu_page *kvm_mmu_get_page(struct 
kvm_vcpu *vcpu,
 
account_shadowed(vcpu->kvm, gfn);
}
+   sp->mmu_valid_gen = vcpu->kvm->arch.mmu_valid_gen;
init_shadow_page_table(sp);
trace_kvm_mmu_get_page(sp, true);
return sp;
@@ -2070,8 +2082,10 @@ static int kvm_mmu_prepare_zap_page(struct kvm *kvm, 
struct kvm_mmu_page *sp,
ret = mmu_zap_unsync_children(kvm, sp, invalid_list);
kvm_mmu_page_unlink_children(kvm, sp);
kvm_mmu_unlink_parents(kvm, sp);
+
if (!sp->role.invalid && !sp->role.direct)
unaccount_shadowed(kvm, sp->gfn);
+
if (sp->unsync)
kvm_unlink_unsync_page(kvm, sp);
if (!sp->root_count) {
@@ -4195,6 +4209,82 @@ restart:
spin_unlock(>mmu_lock);
 }
 
+static void kvm_zap_obsolete_pages(struct kvm *kvm)
+{
+   struct kvm_mmu_page *sp, *node;
+   LIST_HEAD(invalid_list);
+
+restart:
+   list_for_each_entry_safe_reverse(sp, node,
+ >arch.active_mmu_pages, link) {
+   /*
+* No obsolete page exists before new created page since
+* active_mmu_pages is the FIFO list.
+*/
+   if (!is_obsolete_sp(kvm, sp))
+   break;
+
+   /*
+* Do not repeatedly zap a root page to avoid unnecessary
+* KVM_REQ_MMU_RELOAD, otherwise we may not be able to
+* progress:
+*vcpu 0vcpu 1
+* call vcpu_enter_guest():
+*1): handle KVM_REQ_MMU_RELOAD
+  

Re: [PATCH 1/2] x86/xen: sync the wallclock when the system time changes

[John Stultz]

On 05/30/2013 07:25 AM, David Vrabel wrote:

From: David Vrabel 

Currently the Xen wallclock is only updated every 11 minutes if NTP is
synchronized to its clock source.  If a guest is started before NTP is
synchronized it may see an incorrect wallclock time.


Ok.. So this is maybe starting to make a little more sense.

I was under the mistaken impression domN guests referenced dom0's system 
time when they called xen_get_wallclock(), but looking at this a bit 
closer, its starting to make a bit more sense that xen_get_wallclock() 
is just shared hypervisor data that is updated by dom0, and guests can 
access this data without interacting with dom0.


Thus I can finally see the 11 minute update interval for dom0 to update 
the hypervisor wallclock data causes guests to get invalid time values 
when they initialize, reading the unset by dom0 hypervisor wallclock 
data. And thus I finally see the need for dom0 to more frequently update 
the hypervisor wallclock data.


So first, sorry for being so dense through all of this. But this really 
could use a clearer explanation as to the nature of the issue.


Few minor issues below.


Use the pvclock_gtod notifier chain to receive a notification when the
system time has changed and update the wallclock to match.

This chain is called on every timer tick and we want to avoid an extra
(expensive) hypercall on every tick.  Because dom0 has historically
never provided a very accurate wallclock and guests do not expect one,
we can do this simply.  The wallclock is only updated if the
difference between now and the last update is more than 0.5 s.



So given (at least I think ) I get why this is needed, is there a reason 
you're using the notifier chain instead of a regular timer in dom0 to 
update the hypervisor's wallclock data?





Signed-off-by: David Vrabel 
---
  arch/x86/xen/time.c |   46 ++
  1 files changed, 46 insertions(+), 0 deletions(-)

diff --git a/arch/x86/xen/time.c b/arch/x86/xen/time.c
index a1947ac..60b7d1f 100644
--- a/arch/x86/xen/time.c
+++ b/arch/x86/xen/time.c
@@ -14,6 +14,7 @@
  #include 
  #include 
  #include 
+#include 
  
  #include 

  #include 
@@ -212,6 +213,48 @@ static int xen_set_wallclock(const struct timespec *now)
return HYPERVISOR_dom0_op();
  }
  
+static int xen_pvclock_gtod_notify(struct notifier_block *nb, unsigned long unused,

+  void *priv)
+{
+   static struct timespec last, next;
+   struct timespec now;
+   struct xen_platform_op op;
+   int ret;
+
+   /*
+* Set the Xen wallclock from Linux system time.
+*
+* dom0 hasn't historically maintained a very accurate
+* wallclock so guests don't expect it. We can therefore
+* reduce the number of expensive hypercalls by only updating
+* the wallclock every 0.5 s.


This comment needs some improvement. It doesn't explain why Xen needs to 
set the virtual RTC so frequently, but then goes on to say it can be 
done every half second because guests don't really expect it anyway.



+*/
+
+   now = __current_kernel_time();


You don't seem to be holding the timekeeping lock here, so why are you 
calling the internal __ prefixed current_kernel_time() accessor?




+
+   if (timespec_compare(, ) > 0


Not sure I understand why you're bothering with the last value? Aren't 
you just wanting to trigger when now is greater then next?



So again, apologies for some of the runaround in the discussion! Lets 
sort out the above minor issues and I'll be fine to queue this (given 
Xen maintainer acks) without grumbling.


thanks
-john

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

Re: [PATCH 1/2] USB: xhci: rename ambiguous named XHCI_NEC_HOST to XHCI_NEC_SHOW_FW

[Alexander Holler]

Am 30.05.2013 20:20, schrieb Sarah Sharp:
> On Thu, May 30, 2013 at 06:16:34AM +0200, Alexander Holler wrote:

> The point is that unless Renesas tells us how to know if a host
> supports the firmware fetch vendor command, we should stop issuing that
> command to the host.  I think my contacts at Renesas have moved onto
> other jobs, but maybe you know someone there?

No, sorry.

>> I just dont't like the name, because e.g. in my case, it made me to have
>> a deeper look at what that quirk does, because I had the hope it might
>> solve a problem. Therefor I think it's useful to rename it.
> 
> I understand.  If the command worked fine on all Renesas hosts, I would
> be fine with renaming it and printing it with dev_info instead of
> xhci_dbg.  However, since some Renesas hosts don't support the command,
> I'm concerned we may be forced to rip out the code.  If you don't do it,
> I will have to.

I don't want to do it as it works fine on my Renesas upd720202.

Instead of removing this feature completely, you could just use the
first patch and forget the second one. So only NEC hosts will still have
it and I assume there will not any new appear, as they are now Renesas.

Another possibility would be to use the device ID too (for Renesas
devices), mine has 0x0015.

The reason why I really like this feature is that there were already 2-3
firmware updates and since USB 3.0 still isn't that widely used, I
assume more will appear if more people actually start using such devices.

Regards,

Alexander Holler
--
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 0/6] Emaclite patches

[David Miller]

From: Michal Simek 
Date: Thu, 30 May 2013 12:28:02 +0200

> I have separated these emaclite patches from
> phy patches because it is easier for creating
> new versions.

Series applied, 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: [PATCHv3 0/2] xen: maintain an accurate persistent clock in more cases

[John Stultz]

On 05/30/2013 07:25 AM, David Vrabel wrote:

The kernel has limited support for updating the persistent clock or
RTC when NTP is synced.  This has the following limitations:

* The persistent clock is not updated on step changes.  This leaves a
   window where it will be incorrect (while NTP resyncs).

* Xen guests use the Xen wallclock as their persistent clock.  dom0
   maintains this clock so it is persistent for domUs and not dom0
   itself.



So I'm still skeptical of the urgency to the first patch in this series, 
as I feel its a little overzealous in trying to enforce strict 
RTC/system-time synchronization.  But that said, these patches are now 
done in a way that doesn't affect the timekeeping core, so I'm ok with 
stepping out of the way and leaving the decision to merge it up to the 
Xen maintainers (Modulo a few nits I still have).




These series fixes the above limitations and depends on "x86: increase
precision of x86_platform.get/set_wallclock()" which was previously
posted.


This is the only area that will need some coordination cross the Xen 
tree and tip/timers/core (once that patch and the fix for it I have 
queued lands in -tip). The options here are:


* I queue these two patches with proper Xen maintainer's acks/review 
(possibly adding my grumbles to the commit)
* Wait until the requried patch lands tip/timers/core, then Xen 
maintainers merge tip/timers/core into their tree as well
* These patches get rewritten so they don't depend on the "increase 
precision" patch, then we sort out the merge in -next



The first is probably the easiest, but I do want to make sure that Xen 
maintainers agree that Xen really needs to be special here compared to 
every other platform and always enforce the RTC is synced with system time.




[ On a related note, with CONFIG_HZ=1000 sync_cmos_clock() is always
   scheduled ~3ms too late which causes it to repeatedly try to
   reschedule in ~997 ms and ends up never calling
   updated_persistent_clock().  With HZ=250, the error is ~1ms too late
   which is close enough.

   It is not clear where this systematic error comes from or whether
   this is only a Xen specific bug.  I don't have time to investigate
   right now. ]


I'd be very interested in hearing more about this issue!

thanks
-john

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

Re: [PATCH 3/3] usb: dwc3: use extcon fwrk to receive connect/disconnect notification

[Chanwoo Choi]

On 05/24/2013 11:31 PM, Kishon Vijay Abraham I wrote:
> Modified dwc3-omap to receive connect and disconnect notification using
> extcon framework. Also did the necessary cleanups required after
> adapting to extcon framework.
>
> Signed-off-by: Kishon Vijay Abraham I 
> ---
>  drivers/usb/dwc3/dwc3-omap.c  | 80 
> +--
>  include/linux/usb/dwc3-omap.h | 30 
>  2 files changed, 62 insertions(+), 48 deletions(-)
>  delete mode 100644 include/linux/usb/dwc3-omap.h

Hi Kishon,

Thi patch is suspended until fix following build error.
(If kernel builds extcon fwr as module, dwc3-omap.c happen error message)

---
tree:   git://git.kernel.org/pub/scm/linux/kernel/git/chanwoo/extcon extcon-next
head:   30f5d6ea2561c2a54e40b1e8e8f9bb30e064e01b
commit: 30f5d6ea2561c2a54e40b1e8e8f9bb30e064e01b [3/3] usb: dwc3: use extcon 
fwrk to receive connect/disconnect notification
config: i386-randconfig-x14-0530 (attached as .config)

All error/warnings:

   drivers/built-in.o: In function `dwc3_omap_remove':
   dwc3-omap.c:(.text+0x8c0fa): undefined reference to 
`extcon_unregister_interest'
   dwc3-omap.c:(.text+0x8c102): undefined reference to 
`extcon_unregister_interest'
   drivers/built-in.o: In function `dwc3_omap_probe':
   dwc3-omap.c:(.text+0x8c5e6): undefined reference to `extcon_get_extcon_dev'
   dwc3-omap.c:(.text+0x8c6a4): undefined reference to 
`extcon_register_interest'
   dwc3-omap.c:(.text+0x8c6c9): undefined reference to 
`extcon_register_interest'
   dwc3-omap.c:(.text+0x8c831): undefined reference to `extcon_get_cable_state'
   dwc3-omap.c:(.text+0x8c851): undefined reference to `extcon_get_cable_state'
---

Also, I missed a issue of this patch. If h/w target use other USB device
instead of "palmas-usb", dwc-omap.c driver won't be operating.
So, I propose two method about this issue.
First, we can get extcon device name through platform data or dt.
Two, When use extcon_register_interest() to register notifier block,
NULL pointer pass to extcon_register_interest() instead of specific extcon
device name(palmas-usb). If extcon_register_interest() check NULL
pointer of extcon device name parameter, extcon fwr will find previous
registered extcon device and then register notifier block of consumer
device driver(dwc3-omap.c) to previous registered extcon device.

> + edev = extcon_get_extcon_dev("palmas-usb");
> + if (!edev) {
> + dev_dbg(dev, "couldn't get extcon device\n");
> + return -EPROBE_DEFER;
> + }
> +
>   spin_lock_init(>lock);
>  
>   omap->dev   = dev;
>   omap->irq   = irq;
>   omap->base  = base;
> + omap->vbus_nb.notifier_call = dwc3_omap_vbus_notifier;
> + extcon_register_interest(>extcon_vbus_dev, "palmas-usb", "USB",
> + >vbus_nb);
> + omap->id_nb.notifier_call = dwc3_omap_id_notifier;
> + extcon_register_interest(>extcon_id_dev, "palmas-usb", "USB-HOST",
> + >id_nb);
>   dev->dma_mask   = _omap_dma_mask;
>  
> +

Thanks,
Chanwoo Choi

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

Re: linux-next: build warning after merge of the final tree (net-next tree related)

[Simon Horman]

On Thu, May 30, 2013 at 04:17:57PM +1000, Stephen Rothwell wrote:
> Hi all,
> 
> After merging the final tree, today's linux-next build (i386 defconfig)
> produced this warning:
> 
> net/netfilter/nf_nat_helper.c: In function 'mangle_contents':
> net/netfilter/nf_nat_helper.c:108:9: warning: passing argument 3 of 'memmove' 
> makes integer from pointer without a cast [enabled by default]
> arch/x86/include/asm/string_32.h:200:7: note: expected 'size_t' but argument 
> is of type 'sk_buff_data_t'
> 
> Presumably introduced by commit 1a37e412a022 ("net: Use 16bits for
> *_headers fields of struct skbuff").

Thanks Stephen.

I believe that you are correct. I'll prepare and post a patch ASAP.

--
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: Allow FPU to be used at interrupt time even with eagerfpu

[tip-bot for Pekka Riikonen]

Commit-ID:  5187b28ff08249ab8a162e802209ed04e271ca02
Gitweb: http://git.kernel.org/tip/5187b28ff08249ab8a162e802209ed04e271ca02
Author: Pekka Riikonen 
AuthorDate: Mon, 13 May 2013 14:32:07 +0200
Committer:  H. Peter Anvin 
CommitDate: Thu, 30 May 2013 16:36:42 -0700

x86: Allow FPU to be used at interrupt time even with eagerfpu

With the addition of eagerfpu the irq_fpu_usable() now returns false
negatives especially in the case of ksoftirqd and interrupted idle task,
two common cases for FPU use for example in networking/crypto.  With
eagerfpu=off FPU use is possible in those contexts.  This is because of
the eagerfpu check in interrupted_kernel_fpu_idle():

...
  * For now, with eagerfpu we will return interrupted kernel FPU
  * state as not-idle. TBD: Ideally we can change the return value
  * to something like __thread_has_fpu(current). But we need to
  * be careful of doing __thread_clear_has_fpu() before saving
  * the FPU etc for supporting nested uses etc. For now, take
  * the simple route!
...
if (use_eager_fpu())
return 0;

As eagerfpu is automatically "on" on those CPUs that also have the
features like AES-NI this patch changes the eagerfpu check to return 1 in
case the kernel_fpu_begin() has not been said yet.  Once it has been the
__thread_has_fpu() will start returning 0.

Notice that with eagerfpu the __thread_has_fpu is always true initially.
FPU use is thus always possible no matter what task is under us, unless
the state has already been saved with kernel_fpu_begin().

[ hpa: this is a performance regression, not a correctness regression,
  but since it can be quite serious on CPUs which need encryption at
  interrupt time I am marking this for urgent/stable. ]

Signed-off-by: Pekka Riikonen 
Link: http://lkml.kernel.org/r/alpine.gso.2.00.1305131356320...@git.silcnet.org
Cc:  v3.7+
Signed-off-by: H. Peter Anvin 
---
 arch/x86/kernel/i387.c | 14 +-
 1 file changed, 5 insertions(+), 9 deletions(-)

diff --git a/arch/x86/kernel/i387.c b/arch/x86/kernel/i387.c
index 245a71d..cb33909 100644
--- a/arch/x86/kernel/i387.c
+++ b/arch/x86/kernel/i387.c
@@ -22,23 +22,19 @@
 /*
  * Were we in an interrupt that interrupted kernel mode?
  *
- * For now, with eagerfpu we will return interrupted kernel FPU
- * state as not-idle. TBD: Ideally we can change the return value
- * to something like __thread_has_fpu(current). But we need to
- * be careful of doing __thread_clear_has_fpu() before saving
- * the FPU etc for supporting nested uses etc. For now, take
- * the simple route!
- *
  * On others, we can do a kernel_fpu_begin/end() pair *ONLY* if that
  * pair does nothing at all: the thread must not have fpu (so
  * that we don't try to save the FPU state), and TS must
  * be set (so that the clts/stts pair does nothing that is
  * visible in the interrupted kernel thread).
+ *
+ * Except for the eagerfpu case when we return 1 unless we've already
+ * been eager and saved the state in kernel_fpu_begin().
  */
 static inline bool interrupted_kernel_fpu_idle(void)
 {
if (use_eager_fpu())
-   return 0;
+   return __thread_has_fpu(current);
 
return !__thread_has_fpu(current) &&
(read_cr0() & X86_CR0_TS);
@@ -78,8 +74,8 @@ void __kernel_fpu_begin(void)
struct task_struct *me = current;
 
if (__thread_has_fpu(me)) {
-   __save_init_fpu(me);
__thread_clear_has_fpu(me);
+   __save_init_fpu(me);
/* We do 'stts()' in __kernel_fpu_end() */
} else if (!use_eager_fpu()) {
this_cpu_write(fpu_owner_task, NULL);
--
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, crc32-pclmul: Fix build with older binutils

[tip-bot for Jan Beulich]

Commit-ID:  2baad6121e2b2fa3428ee6cb2298107be11ab23a
Gitweb: http://git.kernel.org/tip/2baad6121e2b2fa3428ee6cb2298107be11ab23a
Author: Jan Beulich 
AuthorDate: Wed, 29 May 2013 13:43:54 +0100
Committer:  H. Peter Anvin 
CommitDate: Thu, 30 May 2013 16:36:23 -0700

x86, crc32-pclmul: Fix build with older binutils

binutils prior to 2.18 (e.g. the ones found on SLE10) don't support
assembling PEXTRD, so a macro based approach like the one for PCLMULQDQ
in the same file should be used.

This requires making the helper macros capable of recognizing 32-bit
general purpose register operands.

[ hpa: tagging for stable as it is a low risk build fix ]

Signed-off-by: Jan Beulich 
Link: http://lkml.kernel.org/r/51a6142a0278000d9...@nat28.tlf.novell.com
Cc: Alexander Boyko 
Cc: Herbert Xu 
Cc: Huang Ying 
Cc:  v3.9
Signed-off-by: H. Peter Anvin 
---
 arch/x86/crypto/crc32-pclmul_asm.S |  2 +-
 arch/x86/include/asm/inst.h| 74 --
 2 files changed, 73 insertions(+), 3 deletions(-)

diff --git a/arch/x86/crypto/crc32-pclmul_asm.S 
b/arch/x86/crypto/crc32-pclmul_asm.S
index 94c27df..f247304 100644
--- a/arch/x86/crypto/crc32-pclmul_asm.S
+++ b/arch/x86/crypto/crc32-pclmul_asm.S
@@ -240,7 +240,7 @@ fold_64:
pand%xmm3, %xmm1
PCLMULQDQ 0x00, CONSTANT, %xmm1
pxor%xmm2, %xmm1
-   pextrd  $0x01, %xmm1, %eax
+   PEXTRD  0x01, %xmm1, %eax
 
ret
 ENDPROC(crc32_pclmul_le_16)
diff --git a/arch/x86/include/asm/inst.h b/arch/x86/include/asm/inst.h
index 280bf7f..3e11527 100644
--- a/arch/x86/include/asm/inst.h
+++ b/arch/x86/include/asm/inst.h
@@ -9,12 +9,68 @@
 
 #define REG_NUM_INVALID100
 
-#define REG_TYPE_R64   0
-#define REG_TYPE_XMM   1
+#define REG_TYPE_R32   0
+#define REG_TYPE_R64   1
+#define REG_TYPE_XMM   2
 #define REG_TYPE_INVALID   100
 
+   .macro R32_NUM opd r32
+   \opd = REG_NUM_INVALID
+   .ifc \r32,%eax
+   \opd = 0
+   .endif
+   .ifc \r32,%ecx
+   \opd = 1
+   .endif
+   .ifc \r32,%edx
+   \opd = 2
+   .endif
+   .ifc \r32,%ebx
+   \opd = 3
+   .endif
+   .ifc \r32,%esp
+   \opd = 4
+   .endif
+   .ifc \r32,%ebp
+   \opd = 5
+   .endif
+   .ifc \r32,%esi
+   \opd = 6
+   .endif
+   .ifc \r32,%edi
+   \opd = 7
+   .endif
+#ifdef CONFIG_X86_64
+   .ifc \r32,%r8d
+   \opd = 8
+   .endif
+   .ifc \r32,%r9d
+   \opd = 9
+   .endif
+   .ifc \r32,%r10d
+   \opd = 10
+   .endif
+   .ifc \r32,%r11d
+   \opd = 11
+   .endif
+   .ifc \r32,%r12d
+   \opd = 12
+   .endif
+   .ifc \r32,%r13d
+   \opd = 13
+   .endif
+   .ifc \r32,%r14d
+   \opd = 14
+   .endif
+   .ifc \r32,%r15d
+   \opd = 15
+   .endif
+#endif
+   .endm
+
.macro R64_NUM opd r64
\opd = REG_NUM_INVALID
+#ifdef CONFIG_X86_64
.ifc \r64,%rax
\opd = 0
.endif
@@ -63,6 +119,7 @@
.ifc \r64,%r15
\opd = 15
.endif
+#endif
.endm
 
.macro XMM_NUM opd xmm
@@ -118,10 +175,13 @@
.endm
 
.macro REG_TYPE type reg
+   R32_NUM reg_type_r32 \reg
R64_NUM reg_type_r64 \reg
XMM_NUM reg_type_xmm \reg
.if reg_type_r64 <> REG_NUM_INVALID
\type = REG_TYPE_R64
+   .elseif reg_type_r32 <> REG_NUM_INVALID
+   \type = REG_TYPE_R32
.elseif reg_type_xmm <> REG_NUM_INVALID
\type = REG_TYPE_XMM
.else
@@ -162,6 +222,16 @@
.byte \imm8
.endm
 
+   .macro PEXTRD imm8 xmm gpr
+   R32_NUM extrd_opd1 \gpr
+   XMM_NUM extrd_opd2 \xmm
+   PFX_OPD_SIZE
+   PFX_REX extrd_opd1 extrd_opd2
+   .byte 0x0f, 0x3a, 0x16
+   MODRM 0xc0 extrd_opd1 extrd_opd2
+   .byte \imm8
+   .endm
+
.macro AESKEYGENASSIST rcon xmm1 xmm2
XMM_NUM aeskeygen_opd1 \xmm1
XMM_NUM aeskeygen_opd2 \xmm2
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [GIT PULL] nohz fixes

[Frederic Weisbecker]

On Wed, May 29, 2013 at 06:39:39PM +0200, Frederic Weisbecker wrote:
> Ingo,
> 
> Please pull the timers/urgent-for-tip branch that can be found at:
> 
> git://git.kernel.org/pub/scm/linux/kernel/git/frederic/linux-dynticks.git
>   timers/urgent-for-tip

Please rather pull timers/urgent-for-tip-v2, it removes
"nohz: Prevent broadcast source from stealing full dynticks timekeeping duty"
and includes "tick: Remove useless timekeeping duty attribution to broadcast 
source"
instead, acked by Thomas.

Thanks.

> 
> Only the 6th patch is new so I'm posting it along, the others have been
> posted a few days ago.
> 
> Thanks,
>   Frederic
> ---
> 
> Frederic Weisbecker (4):
>   vtime: Use consistent clocks among nohz accounting
>   watchdog: Boot-disable by default on full dynticks
>   kvm: Move guest entry/exit APIs to context_tracking
>   nohz: Prevent broadcast source from stealing full dynticks timekeeping 
> duty
> 
> Li Zhong (1):
>   nohz: Fix notifier return val that enforce timekeeping
> 
> Steven Rostedt (1):
>   nohz: Warn if the machine can not perform nohz_full
> 
> 
>  include/linux/context_tracking.h |   35 +++
>  include/linux/kvm_host.h |   37 +
>  include/linux/vtime.h|4 ++--
>  kernel/context_tracking.c|1 -
>  kernel/sched/core.c  |2 +-
>  kernel/sched/cputime.c   |6 +++---
>  kernel/time/tick-broadcast.c |   11 ---
>  kernel/time/tick-sched.c |7 ++-
>  kernel/watchdog.c|6 ++
>  9 files changed, 62 insertions(+), 47 deletions(-)
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH] tick: Remove useless timekeeping duty attribution to broadcast source

[Frederic Weisbecker]

From: Jiri Bohac 

Since 7300711e ("clockevents: broadcast fixup possible waiters"),
the timekeeping duty is assigned to the CPU that handles the tick
broadcast clock device by the time it is set in one shot mode.

This is an issue in full dynticks mode where the timekeeping duty
must stay handled by the boot CPU for now. Otherwise it prevents
secondary CPUs from offlining and this breaks
suspend/shutdown/reboot/...

As it appears there is no reason for this timekeeping duty to be
moved to the broadcast CPU, besides nothing prevent it from being
later re-assigned to another target, let's simply remove it.

Signed-off-by: Jiri Bohac 
Reported-by: Steven Rostedt 
Acked-by: Thomas Gleixner 
Cc: Steven Rostedt 
Cc: Thomas Gleixner 
Cc: Paul E. McKenney 
Cc: Ingo Molnar 
Cc: Peter Zijlstra 
Cc: Borislav Petkov 
Signed-off-by: Frederic Weisbecker 
---
 kernel/time/tick-broadcast.c |4 
 1 files changed, 0 insertions(+), 4 deletions(-)

diff --git a/kernel/time/tick-broadcast.c b/kernel/time/tick-broadcast.c
index 24938d5..ee316b9 100644
--- a/kernel/time/tick-broadcast.c
+++ b/kernel/time/tick-broadcast.c
@@ -692,10 +692,6 @@ void tick_broadcast_setup_oneshot(struct 
clock_event_device *bc)
 
bc->event_handler = tick_handle_oneshot_broadcast;
 
-   /* Take the do_timer update */
-   if (!tick_nohz_full_cpu(cpu))
-   tick_do_timer_cpu = cpu;
-
/*
 * We must be careful here. There might be other CPUs
 * waiting for periodic broadcast. We need to set the
-- 
1.7.5.4

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

Re: Question on mod_sysfs_init and kobject_put in error handling code.

[Ben Greear]

On 05/30/2013 12:39 PM, Ben Greear wrote:

I'm seeing a crash (on hacked 3.9.3+ kernels).  It's rare, but in a kernel
larded down with debugging, we are having some luck reproducing it.

Please note, this kernel is running a fair amount of my patches, so it could
be my bug.  We did not see this before 3.9.3, as far as we know..but I have not
tried bisecting this yet.

The crash happens on startup, and I see this splat or similar:


I was able to reproduce something similar on a stock 3.9.4 kernel,
so I'll start trying to bisect the problem...

Ben




microcode: CPU3 sig=0x20652, pf=0x10, revision=0x9
microcode: CPU3 updated to revision 0xd, date = 2011-09-01
microcode: Microcode Update Driver: v2.00 , Peter 
Oruba
e1000e :01:00.0 eth0: MAC: 3, PHY: 8, PBA No: FF-0FF
kvm: disabled by bios
ieee80211 phy0: Atheros AR9300 Rev:3 mem=0xc90023a4, irq=18
kvm_intel: module is already loaded
BUG: unable to handle kernel paging request at a08e8700
IP: [] kset_find_obj+0x23/0x7a
PGD 1a0f067 PUD 1a10063 PMD 21e9ae067 PTE 0
Oops:  [#1] PREEMPT SMP
Modules linked in: acpi_cpufreq(+) kvm_intel(+) mperf intel_powerclamp kvm 
cdc_acm microcode serio_raw pcspkr snd_hda_codec_realtek ath9k(+) ath9k_common
ath9k_hw ath e1000e ptp snd_hda_intel mac80211 snd_hda_codec snd_hwdep snd_seq 
i2c_i801 snd_seq_device lpc_ich pps_core cfg80211 snd_pcm snd_page_alloc
snd_timer snd soundcore parport_pc parport uinput ipv6 i915 video i2c_algo_bit 
drm_kms_helper drm i2c_core
CPU 0
Pid: 498, comm: udevd Not tainted 3.9.4+ #3 To be filled by O.E.M. To be filled 
by O.E.M./To be filled by O.E.M.
RIP: 0010:[]  [] kset_find_obj+0x23/0x7a
RSP: 0018:88021f145d68  EFLAGS: 00010293
RAX: a08e8708 RBX: a08e8700 RCX: 908f
RDX: 8f61 RSI: a0958029 RDI: 88021527a691
RBP: 88021f145d88 R08:  R09: 88021f145c78
R10:  R11:  R12: 880221cd8410
R13: 880221cd8420 R14: a0958028 R15: a0958028
FS:  7fa594c7f840() GS:88022bc0() knlGS:
CS:  0010 DS:  ES:  CR0: 80050033
CR2: a08e8700 CR3: 0002150a CR4: 07f0
DR0:  DR1:  DR2: 
DR3:  DR6: 0ff0 DR7: 0400
Process udevd (pid: 498, threadinfo 88021f144000, task 88021555)
Stack:
  a0958010 88021f145ef8  a0958028
  88021f145df8 810f2e06 81a51430 0246
  000180007fff a09575e8 88020001 a09575e8
Call Trace:
  [] mod_sysfs_setup+0x52/0x522
  [] load_module+0x13e8/0x15cc
  [] ? ddebug_dyndbg_boot_param_cb+0x45/0x45
  [] sys_init_module+0xfd/0x103
  [] system_call_fastpath+0x16/0x1b
Code: ff 9d e8 ff 5e 5b c9 c3 55 48 89 e5 41 56 49 89 f6 41 55 4c 8d 6f 10 41 54 49 
89 fc 4c 89 ef 53 e8 af 88 2e 00 49 8b 1c 24 eb 34 <48> 8b 3b 48 85 ff 74 28
4c 89 f6 e8 1f 55 00 00 85 c0 75 1c 8b
RIP  [] kset_find_obj+0x23/0x7a
  RSP 
CR2: a08e8700
---[ end trace cc75890eca7ff0aa ]---


While poking around the code, I wonder if the kobject put is correct below?

In both cases I've reproduced I see the error about 'module is already loaded'
printed in the logs right before the crash.  It was a different module name 
each time.

The kset_find_obj plays some tricks where it only grabs a reference
sometimes...maybe the kobject_put needs some similar conditions?


static int mod_sysfs_init(struct module *mod)
{
 int err;
 struct kobject *kobj;

 if (!module_sysfs_initialized) {
 printk(KERN_ERR "%s: module sysfs not initialized\n",
mod->name);
 err = -EINVAL;
 goto out;
 }

 kobj = kset_find_obj(module_kset, mod->name);
 if (kobj) {
 printk(KERN_ERR "%s: module is already loaded\n", mod->name);
 kobject_put(kobj);
 err = -EINVAL;
 goto out;
 }




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

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

Re: [PATCH] PCI: set correct value for iov device before device

[Bjorn Helgaas]

On Thu, May 30, 2013 at 2:27 PM, Yinghai Lu  wrote:
> On Wed, May 29, 2013 at 11:04 PM, Yinghai Lu  wrote:
>> On Wed, May 29, 2013 at 10:45 PM, Xudong Hao  wrote:
>>> Since device registering is put into pci_device_add(), it must set value of
>>> Virtual Function device's member before the pci_dev is put to device tree. 
>>> Or
>>> some relevant subsystem of driver model such as xen will report a incorrect
>>> IOV device to Xen hypervior.
>>>
>>> Signed-off-by: Xudong Hao 
>>> ---
>>>  drivers/pci/iov.c | 6 +++---
>>>  1 file changed, 3 insertions(+), 3 deletions(-)
>>>
>>> diff --git a/drivers/pci/iov.c b/drivers/pci/iov.c
>>> index c93071d..43d3de9 100644
>>> --- a/drivers/pci/iov.c
>>> +++ b/drivers/pci/iov.c
>>> @@ -110,12 +110,12 @@ static int virtfn_add(struct pci_dev *dev, int id, 
>>> int reset)
>>> if (reset)
>>> __pci_reset_function(virtfn);
>>>
>>> -   pci_device_add(virtfn, virtfn->bus);
>>> -   mutex_unlock(>dev->sriov->lock);
>>> -
>>> virtfn->physfn = pci_dev_get(dev);
>>> virtfn->is_virtfn = 1;
>>>
>>> +   pci_device_add(virtfn, virtfn->bus);
>>> +   mutex_unlock(>dev->sriov->lock);
>>> +
>>> rc = pci_bus_add_device(virtfn);
>>> sprintf(buf, "virtfn%u", id);
>>> rc = sysfs_create_link(>dev.kobj, >dev.kobj, buf);
>>
>> I have similar patch at
>> https://patchwork.kernel.org/patch/2562551/
>>[5/7] PCI, ACPI: Don't glue ACPI dev with pci VFs
>>
>> and Jiang has another one
>> https://patchwork.kernel.org/patch/2613481/
>>[v3,part1,10/10] PCI, IOV: hide remove and rescan sysfs interfaces
>> for SR-IOV virtual functions
>
> Bjorn,
>
> I double check this one, we should split the patch from me or Jiang.

I don't know what the sentence above means.

> and the one about set virtfn=1 should be -stable material.

I assume you mean that Jiang's "[v3,part1,10/10] PCI, IOV: hide remove
and rescan sysfs interfaces for SR-IOV virtual functions" patch does
not need to be in v3.10, but it should be marked for -stable.

How far back should it go?  v3.9+?

> That will address another problem that is caused by
> moving device_add from pci_bus_add_device to pci_device_add.

I assume you're talking about a problem caused by 4f535093 ("PCI: Put
pci_dev in device tree as early as possible").  That commit appeared
in v3.9.

If we're asking to add the "hide remove and rescan sysfs interfaces"
patch to the v3.9 stable series, we should have a description of
exactly what problem it fixes, and ideally, a bugzilla for it.  Can
you provide that?

That patch appears to be the only one in the [v3,part1,0/10] series
that actually directly fixes an issue, so it would be nice to have
more specifics in that changelog to begin with.  The other patches in
that series appear to to be cleanups and preparation for the real
fixes that will come later.

Bjorn
--
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 v3 0/5] rtc-at91rm9200: add shadow interrupt mask

[Douglas Gilbert]

On 13-05-30 03:36 PM, Andrew Morton wrote:

On Thu, 30 May 2013 09:50:27 +0200 Nicolas Ferre  
wrote:


The review of this patch series was in my TODO list for some time...

Today, I magically took time to review it ;-)
The patch series is good and I (even if it is too late) here is my:

Acked-by: Nicolas Ferre 

I do not know if the series can be stacked for inclusion in 3.10-rc but
the resolution of this bug can help a lot (as Douglas is saying in
subsequent email...).


We can do that, but looking through the discussion and changelogs I
can't seem to find a usable description of what impact the bug (and its
fix) have upon end-users.

A nicely packaged description of that impact would help grease the
wheels, please.


How about this:

The members of Atmel's at91sam9x5 family (9x5) have
a broken RTC interrupt mask register (AT91_RTC_IMR).
It does not reflect enabled interrupts but instead
always returns zero.

The kernel's rtc-at91rm9200 driver handles the RTC
for the 9x5 family. Currently when the date/time is
set, an interrupt is generated and this driver neglects
to handle the interrupt. The kernel complains about the
un-handled interrupt and disables it henceforth. This
not only breaks the RTC function, but since that
interrupt is shared (Atmel's SYS interrupt) then other
things break as well (e.g. the debug port no longer
accepts characters).

Tested on the at91sam9g25. Bug confirmed by Atmel.

Edit as you please.

Doug Gilbert

--
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: Network issue on 3.10 rcs, bisected

[Pravin Shelar]

On Thu, May 30, 2013 at 2:14 PM, Joao Correia
 wrote:
> On Thu, May 30, 2013 at 5:48 PM, Pravin Shelar  wrote:
>> On Wed, May 29, 2013 at 12:53 PM, Joao Correia
>>  wrote:
>>> On Wed, May 29, 2013 at 7:59 PM, Pravin Shelar  wrote:

 On Wed, May 29, 2013 at 4:37 AM, Joao Correia
  wrote:
 > Hello list
 >
 > While trying the rc's for 3.10, i've stumbled upon a problem where
 > networking does not work at all. Iptables will show packet counts going 
 > up,
 > but nothing actually reaches the programs.
 >
 > I'm running fedora under hyper-v 3 (a windows 2012 host). Only tested 
 > ipv4
 > traffic, and everything times out (ping, telnet to open ports) on both
 > directions. The networking devices come up apparently ok - has static ip
 > set, and dmesg shows no errors (although i don't have many debugging 
 > options
 > enabled).
 >
 > I bisected this, and git blames commit
 > ec5f061564238892005257c83565a0b58ec79295 (net: ill link between CSUM and 
 > SG
 > features.). I can't revert it cleanly on current rc's.
 >
 Can you also send network features set on the device?
 ethtool -k 
>>>
>>>
>>> As requested:
>>> Features for eth0:
>>> rx-checksumming: off [fixed]
>>> tx-checksumming: off
>>> tx-checksum-ipv4: off [fixed]
>>> tx-checksum-ip-generic: off [fixed]
>>> tx-checksum-ipv6: off [fixed]
>>> tx-checksum-fcoe-crc: off [fixed]
>>> tx-checksum-sctp: off [fixed]
>>> scatter-gather: on
>>> tx-scatter-gather: on
>>> tx-scatter-gather-fraglist: off [fixed]
>>> tcp-segmentation-offload: off
>>> tx-tcp-segmentation: off [fixed]
>>> tx-tcp-ecn-segmentation: off [fixed]
>>> tx-tcp6-segmentation: off [fixed]
>>> udp-fragmentation-offload: off [fixed]
>>> generic-segmentation-offload: on
>>> generic-receive-offload: on
>>> large-receive-offload: off [fixed]
>>> rx-vlan-offload: off
>>> tx-vlan-offload: on
>>> ntuple-filters: off [fixed]
>>> receive-hashing: off [fixed]
>>> highdma: off [fixed]
>>> tx-vlan-ctag-hw-insert: on [fixed]
>>> rx-vlan-ctag-hw-parse: off [fixed]
>>> rx-vlan-ctag-filter: off [fixed]
>>> tx-vlan-stag-hw-insert: off [fixed]
>>> rx-vlan-stag-hw-parse: off [fixed]
>>> rx-vlan-stag-filter: off [fixed]
>>> vlan-challenged: off [fixed]
>>> tx-lockless: off [fixed]
>>> netns-local: off [fixed]
>>> tx-gso-robust: off [fixed]
>>> tx-fcoe-segmentation: off [fixed]
>>> tx-gre-segmentation: off [fixed]
>>> tx-udp_tnl-segmentation: off [fixed]
>>> fcoe-mtu: off [fixed]
>>> tx-nocache-copy: off
>>> loopback: off [fixed]
>>> rx-fcs: off [fixed]
>>> rx-all: off [fixed]
>>>
>>> The output is similar on a working (3.9) and a bad (3.10) kernel.
>>> diff-ing both outputs shows:
>>> tx-vlan-stag-hw-insert: off [fixed]
>>> rx-vlan-stag-hw-parse: off [fixed]
>>> rx-vlan-stag-filter: off [fixed]
>>> as last on the broken kernels.
>>>
>>
>> I could not reproduce it, I will try it on VM. Meanwhile can you turn
>> off feature "sg" and try same test ?
>
> Hello
>
> Your hint was spot-on. With sg off, i can't reproduce the problem and
> networking seems fine. It works fine either way on 3.9, so this is a
> regression for 3.10.
>
Nice.
but still this does not look right. Can you tell me driver for the nic?
`ethtool -i `

Thanks,
Pravin.
--
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 v10 01/12] mfd: DT bindings for the palmas family MFD

[Stephen Warren]

On 05/30/2013 05:33 AM, keerthy wrote:
> 
> On 03/25/2013 11:29 PM, Stephen Warren wrote:
> 
>> On 03/22/2013 08:55 AM, Ian Lartey wrote:
>>> From: Graeme Gregory 
>>>
>>> Add the various binding files for the palmas family of chips. There is a
>>> top level MFD binding then a seperate binding for IP blocks on chips.
>>
>>> diff --git a/Documentation/devicetree/bindings/clock/palmas-clk.txt 
>>> b/Documentation/devicetree/bindings/clock/palmas-clk.txt
>>
>> Where is the reg property; if you're instantiating the clk device as a
>> standalone DT node and driver, it should be possible to retrieve the
>> address of this IP block instance from DT, not using driver-internal APIs.
>>
>> This same comment likely applies everywhere, so I won't repeat it.
>>
>>> +Example:
>>> +
>>> +clk {
>>> +compatible = "ti,twl6035-clk", "ti,palmas-clk";
>>> +ti,clk32kg-mode-sleep = <0>;
>>> +ti,clk32kgaudio-mode-sleep = <0>;
>>
>>> +#clock-cells = <1>;
>>> +clock-frequency = <3200>;
>>> +clock-names = "clk32kg", "clk32kgaudio";
>>
>> The binding description itself should describe what clocks this node
>> provides and consumes.
>>
>> What is clock-frequency; which clock does it affect?
>>
>> The presence of #clock-cells implies this is a clock provider. This
>> binding should define the format of the clock cells that this property
>> implies. I assume it's just the ID of the output clocks, but what values
>> correspond to which output clocks? That mapping table needs to be listed
>> here.
>>
>> The presence of clock-names implies this is a clock consumer. However,
>> there is no clocks property in the example. Is clks missing from the
>> example, or should this property be clock-output-names instead? If this
>> node is a clock consumer, the list of which clocks it requires should be
>> documented.
>>
>>> diff --git a/Documentation/devicetree/bindings/gpio/gpio-palmas.txt 
>>> b/Documentation/devicetree/bindings/gpio/gpio-palmas.txt
>>
>>> +- gpio-controller: mark the device as a GPIO controller
>>> +- gpio-cells = <1>:  GPIO lines are provided.
>>
>> That's #gpio-cells not gpio-cells.
>>
>> I assume that cell simply contains the GPIO ID/number. That should be
>> documented for clarity.
>>
>> Surely gpio-cells should be 2 not 1, so there is space for flags. At
>> least an "inverted" or "active-low" flag should be included; GPIO
>> consumers would typically implement that flag in SW, so there' no
>> requirement that the flag only be supported if the HW supports the feature.
>>
>>> +- interrupt-controller : palmas has its own internal IRQs
>>> +- #interrupt-cells : should be set to 2 for IRQ number and flags
>>> +  The first cell is the IRQ number.
>>> +  The second cell is the flags, encoded as the trigger masks from
>>> +  Documentation/devicetree/bindings/interrupts.txt
>>
>> You need "/interrupt-controller" before the filename there.
>>
>>> +- interrupt-parent : The parent interrupt controller.
>>
>> If this IP block has interrupt outputs, it should require an
>> "interrupts" property too. This is the same concept that drives the need
>> for a reg property. This same comment likely applies everywhere, so I
>> won't repeat it.
>>
>>> diff --git a/Documentation/devicetree/bindings/input/palmas-pwrbutton.txt 
>>> b/Documentation/devicetree/bindings/input/palmas-pwrbutton.txt
>>
>>> +- interrupts: the interrupt outputs of the controller.
>>
>> How many entries are there, what do they mean, and in what order must
>> they appear? (Note that the binding of a node must define the order of
>> the interrupts property, since historically it's been accessed by index,
>> not by name, and all bindings must allow that access method to be used).
>>
>>> +- interrupt-names : Should be the name of irq resource. Each interrupt
>>> +  binds its interrupt-name.
>>
>> The binding needs to define standard names for the entries in this
>> property, or define that interrupts are only retrieved by index, in
>> which case interrupt-names shouldn't be present. This same comment
>> likely applies everywhere, so I won't repeat it.
>>
>>> diff --git a/Documentation/devicetree/bindings/mfd/palmas.txt 
>>> b/Documentation/devicetree/bindings/mfd/palmas.txt
>>
>>> +Required properties:
>> ...
>>
>> I believe the Palmas devices have many separate I2C addresses, even
>> buses, which are I think are at least partially independently SW
>> configurable. In that case, the reg property for this node should
>> probably enumerate all the I2C addresses that this chip responds to, so
>> that they can each be passed down to the child nodes.
> 
> 
> Stephen,
> 
> The palmas devices do have multiple I2C slave IDs. From OMAP5 as the master
> all the palmas slave devices are connected via I2C1 bus.
> 
> I did not understand the SW configurable part. It is more board
> dependent. Correct me if i understood it wrongly.

IIRC (and I may not sine it's been a while since I looked at this),
there are SW registers that can modify the I2C address that the 

[RESEND PATCH 1/1] MAINTAINERS: Framebuffer Layer maintainers update

[Jean-Christophe PLAGNIOL-VILLARD]

Tomi and I will now take care of the Framebuffer Layer

The git tree is now on kernel.org

Signed-off-by: Jean-Christophe PLAGNIOL-VILLARD 
Cc: Tomi Valkeinen 
Cc: Olof Johansson 
Cc: Andrew Morton 
Cc: Linus Torvalds 
Cc: Arnd Bergmann 
Cc: Florian Tobias Schandinat 
Cc: linux-fb...@vger.kernel.org
---
Hi,

resend as git send-email drop my name in the From

Best Regards,
J.
 MAINTAINERS |5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/MAINTAINERS b/MAINTAINERS
index fd3a495..7714c3c 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -3322,11 +3322,12 @@ F:  drivers/net/wan/dlci.c
 F: drivers/net/wan/sdla.c
 
 FRAMEBUFFER LAYER
-M: Florian Tobias Schandinat 
+M: Jean-Christophe Plagniol-Villard 
+M: Tomi Valkeinen 
 L: linux-fb...@vger.kernel.org
 W: http://linux-fbdev.sourceforge.net/
 Q: http://patchwork.kernel.org/project/linux-fbdev/list/
-T: git git://github.com/schandinat/linux-2.6.git fbdev-next
+T: git 
git://git.kernel.org/pub/scm/linux/kernel/git/plagnioj/linux-fbdev.git
 S: Maintained
 F: Documentation/fb/
 F: Documentation/devicetree/bindings/fb/
-- 
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/

Re: [PATCH] ACPI: Fix potential NULL pointer dereference in acpi_processor_add()

[Greg Kroah-Hartman]

On Thu, May 30, 2013 at 03:57:58PM +0200, Rafael J. Wysocki wrote:
> On Thursday, May 30, 2013 10:29:54 AM Hanjun Guo wrote:
> > On 2013-5-29 19:07, Martin Mokrejs wrote:
> > > Hanjun Guo wrote:
> > >> On 2013-5-29 7:30, Rafael J. Wysocki wrote:
> > >>> On Thursday, May 23, 2013 08:44:26 PM Hanjun Guo wrote:
> >  In acpi_processor_add(), get_cpu_device() will return NULL sometimes,
> >  although the chances are small, I think it should be fixed.
> > 
> >  Signed-off-by: Hanjun Guo 
> > >>>
> > >>> This patch isn't necessary any more after the changes queued up for 3.11
> > >>> in the acpi-hotplug branch of the linux-pm.git tree.
> > >>
> > >> Ok, I noticed your patch set, just drop my patch.
> > > 
> > > But shouldn't this go to stable at least? I checked linux-3.9.4
> > > and it applies fine. Whether this is relevant for other stable
> > > series I will leave up to somebody else. ;)
> > 
> > Hi Rafeal,
> > 
> > What's your opinion on Martin's suggestion?
> 
> Well, this is kind of hard to say.  We generally don't apply patches to 
> -stable
> that don't have mainline counterparts.
> 
> Greg, I wonder what your opinion is?

We do not apply patches to -stable that are not in Linus's tree, unless
there is no problem in Linus's tree due to a major rewrite of the code,
and it has been confirmed that the same problem isn't there.

thanks,

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

pull request: bluetooth 2013-05-30

[Gustavo Padovan]

Hi John,

The following patches are important bug fixes for 3.10, plus the support for a
new device. We do have three fixes from Johan. The first one is a fix to avoid
LE-only devices to rely on the (inexistent) extended features data. The second
patch fixes length checks on incoming L2CAP signalling PDUs so we can discard
PDU whose size doesn't match the one reported in the header.
The last one fixes the handling of power on failures, we now report proper
errors to mgmt when hci_dev_open().

Please pull or let me know of any issues! Thanks.

Gustavo

---

The following changes since commit f942d116b80feb3ae618a0d8ce2df6e853526d3c:

  brcmsmac: fix regression observed in 3.10-rc1 (2013-05-29 14:46:51 -0400)

are available in the git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/bluetooth/bluetooth master

for you to fetch changes up to 0f9e216b0e12971af8a1d39c98c353c76533283b:

  Bluetooth: Fix mgmt handling of power on failures (2013-05-30 18:36:08 -0300)


Bing Zhao (1):
  Bluetooth: btmrvl: support Marvell Bluetooth device SD8897

Johan Hedberg (3):
  Bluetooth: Fix checks for LE support on LE-only controllers
  Bluetooth: Fix missing length checks for L2CAP signalling PDUs
  Bluetooth: Fix mgmt handling of power on failures

 drivers/bluetooth/Kconfig|  4 +--
 drivers/bluetooth/btmrvl_sdio.c  | 28 ++
 include/net/bluetooth/hci_core.h |  1 +
 include/net/bluetooth/mgmt.h |  1 +
 net/bluetooth/hci_core.c |  6 +++-
 net/bluetooth/l2cap_core.c   | 70 

 net/bluetooth/mgmt.c | 23 ++-
 net/bluetooth/smp.c  |  4 +--
 8 files changed, 113 insertions(+), 24 deletions(-)



pgpDv0_6bwCp2.pgp
Description: PGP signature

[PATCH v2] swap: avoid read_swap_cache_async() race to deadlock while waiting on discard I/O completion

[Rafael Aquini]

read_swap_cache_async() can race against get_swap_page(), and stumble across
a SWAP_HAS_CACHE entry in the swap map whose page wasn't brought into the
swapcache yet. This transient swap_map state is expected to be transitory,
but the actual placement of discard at scan_swap_map() inserts a wait for
I/O completion thus making the thread at read_swap_cache_async() to loop
around its -EEXIST case, while the other end at get_swap_page()
is scheduled away at scan_swap_map(). This can leave the system deadlocked
if the I/O completion happens to be waiting on the CPU waitqueue where
read_swap_cache_async() is busy looping and !CONFIG_PREEMPT.

This patch introduces a cond_resched() call to make the aforementioned
read_swap_cache_async() busy loop condition to bail out when necessary,
thus avoiding the subtle race window.

Signed-off-by: Rafael Aquini 
Acked-by: Johannes Weiner 
Acked-by: KOSAKI Motohiro 
Acked-by: Hugh Dickins 
Cc: sta...@vger.kernel.org
---
Changelog:
* fixed typos in commit message;(hannes)
* enhanced the commentary on the deadlock scenario; (hannes)
* include the received ACKs and Cc: stable

 mm/swap_state.c | 18 +-
 1 file changed, 17 insertions(+), 1 deletion(-)

diff --git a/mm/swap_state.c b/mm/swap_state.c
index b3d40dc..f24ab0d 100644
--- a/mm/swap_state.c
+++ b/mm/swap_state.c
@@ -336,8 +336,24 @@ struct page *read_swap_cache_async(swp_entry_t entry, 
gfp_t gfp_mask,
 * Swap entry may have been freed since our caller observed it.
 */
err = swapcache_prepare(entry);
-   if (err == -EEXIST) {   /* seems racy */
+   if (err == -EEXIST) {
radix_tree_preload_end();
+   /*
+* We might race against get_swap_page() and stumble
+* across a SWAP_HAS_CACHE swap_map entry whose page
+* has not been brought into the swapcache yet, while
+* the other end is scheduled away waiting on discard
+* I/O completion at scan_swap_map().
+*
+* In order to avoid turning this transitory state
+* into a permanent loop around this -EEXIST case
+* if !CONFIG_PREEMPT and the I/O completion happens
+* to be waiting on the CPU waitqueue where we are now
+* busy looping, we just conditionally invoke the
+* scheduler here, if there are some more important
+* tasks to run.
+*/
+   cond_resched();
continue;
}
if (err) {  /* swp entry is obsolete ? */
-- 
1.8.1.4

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

Re: [regression, bisected] x86: efi: Pass boot services variable info to runtime code

[Matthew Garrett]

On Thu, 2013-05-30 at 17:28 -0500, Russ Anderson wrote:
> On Thu, May 30, 2013 at 10:21:53PM +, Matthew Garrett wrote:
> > On Thu, 2013-05-30 at 17:17 -0500, Russ Anderson wrote:
> > 
> > > That's a great idea.  This patch moves the QueryVariableInfo()
> > > call from bootime to runtime, in efi_late_init().  The attached
> > > patch is consistent with the UEFI spec and avoids the problem.
> > 
> > No, that defeats the entire point of the original patch.
> 
> How so?  It is still calling QueryVariableInfo()
> before the data is used.

We want to know how much space is used by variables that aren't visible
at runtime.

-- 
Matthew Garrett | mj...@srcf.ucam.org

Re: [regression, bisected] x86: efi: Pass boot services variable info to runtime code

[Jiri Kosina]

On Thu, 30 May 2013, Russ Anderson wrote:

> > > That's a great idea.  This patch moves the QueryVariableInfo()
> > > call from bootime to runtime, in efi_late_init().  The attached
> > > patch is consistent with the UEFI spec and avoids the problem.
> > 
> > No, that defeats the entire point of the original patch.
> 
> How so?  It is still calling QueryVariableInfo()
> before the data is used.

You lose information provided by QueryVariableInfo() about boot-only 
variables once the transition boot -> runtime has happened.

-- 
Jiri Kosina
SUSE Labs
--
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: [regression, bisected] x86: efi: Pass boot services variable info to runtime code

[Russ Anderson]

On Thu, May 30, 2013 at 10:21:53PM +, Matthew Garrett wrote:
> On Thu, 2013-05-30 at 17:17 -0500, Russ Anderson wrote:
> 
> > That's a great idea.  This patch moves the QueryVariableInfo()
> > call from bootime to runtime, in efi_late_init().  The attached
> > patch is consistent with the UEFI spec and avoids the problem.
> 
> No, that defeats the entire point of the original patch.

How so?  It is still calling QueryVariableInfo()
before the data is used.

-- 
Russ Anderson, OS RAS/Partitioning Project Lead  
SGI - Silicon Graphics Inc  r...@sgi.com
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/