Re: [PATCH] UEFI: Don't pass boot services regions to SetVirtualAddressMap()

[Matt Fleming]

On 06/02/2013 11:12 PM, Matthew Garrett wrote:
> We need to map boot services regions during startup in order to avoid
> firmware bugs, but we shouldn't be passing those regions to
> SetVirtualAddressMap(). Ensure that we're only passing regions that are
> marked as being mapped at runtime.
> 
> Signed-off-by: Matthew Garrett 
> ---
>  arch/x86/platform/efi/efi.c | 7 +++
>  1 file changed, 7 insertions(+)
> 
> diff --git a/arch/x86/platform/efi/efi.c b/arch/x86/platform/efi/efi.c
> index 63e167a..add0e37 100644
> --- a/arch/x86/platform/efi/efi.c
> +++ b/arch/x86/platform/efi/efi.c
> @@ -922,6 +922,13 @@ void __init efi_enter_virtual_mode(void)
>   va = efi_ioremap(md->phys_addr, size,
>md->type, md->attribute);
>  
> + if (!(md->attribute & EFI_MEMORY_RUNTIME)) {
> + if (!va)
> + pr_err("ioremap of 0x%llX failed!\n",
> +(unsigned long long)md->phys_addr);
> + continue;
> + }
> +
>   md->virt_addr = (u64) (unsigned long) va;
>  
>   if (!va) {
> 

Is there any point in calling efi_ioremap() for non-runtime regions in
this case? In other words, why not the following patch?

diff --git a/arch/x86/platform/efi/efi.c b/arch/x86/platform/efi/efi.c
index 63e167a..a438ed3 100644
--- a/arch/x86/platform/efi/efi.c
+++ b/arch/x86/platform/efi/efi.c
@@ -903,9 +903,7 @@ void __init efi_enter_virtual_mode(void)
 
for (p = memmap.map; p < memmap.map_end; p += memmap.desc_size) {
md = p;
-   if (!(md->attribute & EFI_MEMORY_RUNTIME) &&
-   md->type != EFI_BOOT_SERVICES_CODE &&
-   md->type != EFI_BOOT_SERVICES_DATA)
+   if (!(md->attribute & EFI_MEMORY_RUNTIME))
continue;
 
size = md->num_pages << EFI_PAGE_SHIFT;
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: linux-next: manual merge of the akpm tree with the percpu tree

[Tejun Heo]

Hello,

Sorry about that. Forgot that the series was already in -mm. Due to
the interface change, the old aio patches won't work on top of the new
percpu-ref patch. Kent is rebasing the rest but until then we need to
either drop the aio patches from -mm or keep using the old percpu-ref
patch. Given that other subsystems are scheduled to pull in the
percpu-ref patch and build on top and Kent is working to rebase the
series, we probably should drop the series from -mm. Andrew?

Thanks and sorry about the trouble.

--
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: [v5][PATCH 5/6] mm: vmscan: batch shrink_page_list() locking operations

[Minchan Kim]

On Mon, Jun 03, 2013 at 11:10:02PM -0700, Dave Hansen wrote:
> On 06/03/2013 10:01 PM, Minchan Kim wrote:
> >> > +static int __remove_mapping_batch(struct list_head *remove_list,
> >> > +  struct list_head *ret_pages,
> >> > +  struct list_head *free_pages)
> >> > +{
> >> > +int nr_reclaimed = 0;
> >> > +struct address_space *mapping;
> >> > +struct page *page;
> >> > +LIST_HEAD(need_free_mapping);
> >> > +
> >> > +while (!list_empty(remove_list)) {
> ...
> >> > +if (!__remove_mapping(mapping, page)) {
> >> > +unlock_page(page);
> >> > +list_add(&page->lru, ret_pages);
> >> > +continue;
> >> > +}
> >> > +list_add(&page->lru, &need_free_mapping);
> ...
> > +   spin_unlock_irq(&mapping->tree_lock);
> > +   while (!list_empty(&need_free_mapping)) {...
> > +   list_move(&page->list, free_pages);
> > +   mapping_release_page(mapping, page);
> > +   }
> > Why do we need new lru list instead of using @free_pages?
> 
> I actually tried using @free_pages at first.  The problem is that we
> need to call mapping_release_page() without the radix tree lock held so
> we can not do it in the first while() loop.
> 
> 'free_pages' is a list created up in shrink_page_list().  There can be
> several calls to __remove_mapping_batch() for each call to
> shrink_page_list().

I missed that point.

> 
> 'need_free_mapping' lets us temporarily differentiate the pages that we
> need to call mapping_release_page()/unlock_page() on versus the ones on
> 'free_pages' which have already had that done.
> 

Right.

> We could theoretically delay _all_ of the
> release_mapping_page()/unlock_page() operations until the _entire_
> shrink_page_list() operation is done, but doing this really helps with

maybe you mean
but doing this doesn't really helps
> lock_page() latency.
> 
> Does that make sense?

If so, It does make sense.
Thanks for pointing me out.

> 
> --
> To unsubscribe, send a message with 'unsubscribe linux-mm' in
> the body to majord...@kvack.org.  For more info on Linux MM,
> see: http://www.linux-mm.org/ .
> Don't email: mailto:"d...@kvack.org";> em...@kvack.org 

-- 
Kind regards,
Minchan Kim
--
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] timekeeping: handle epoch roll-over (2038) on 32-bit systems

[Tobias Waldekranz]

On Mon, Jun 03, 2013 at 04:34:25PM +0200, Thomas Gleixner wrote:
> B1;2601;0cOn Mon, 3 Jun 2013, Tobias Waldekranz wrote:
> > In ktime_get_update_offsets, calculate the current time in the same
> > way as in ktime_get.
> > 
> > On 32-bit systems, the current time is truncated via the call to
> > ktime_set, the following subtraction of offs_real will result in an
> > inaccurate time when the current number of seconds since epoch can no
> > longer fit in 31-bits (2038-01-19 03:14:07 UTC). This will send
> > hrtimer_interrupt into an infinite loop on some architectures (arm),
> > or emit an oops on others(x86).
> 
> If we really want to survive 2038, then we need to get rid of the
> timespec based representation of time in the kernel alltogether and
> switch all related code over to a scalar nsec 64bit storage.
> 
Agreed.

> Just "fixing" some random parts of the code in a "make it work
> somehow" way is a pointless exercise IMO.
> 
Now hold on, it is hardly random. On an ARM system, the kernel will
completely hang. I would think that many users would like to avoid
that. In addition this behavior is rather new, hrtimer_interrupt used
to source its time from ktime_get which avoids this issue. The change
was introduced in:

5baefd6d84163443215f4a99f6a20f054ef11236

I understand that you would like a solution to the broader issue. But
for some users (embedded especially) having a system that continues to
operate 25 years from now is an issue today.

As for "make it work somehow", modifying the current time calculation
to work in the same way as in ktime_get does seem to be a reasonable
way to go IMO.
 
> We already had long discussions about how the timekeeping code should
> be restructured to address that and other problems at least on the
> kernel side and switching everything to scalar storage is definitely
> the way to go.
> 
> Though even if we fix that we still need to twist our brains around
> the timespec/timeval based user space interfaces. That's going to be
> the way more interesting challenge.
> 
> Thanks,
> 
>   tglx

Thanks,
wkz
--
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: [net-next rfc V2 7/8] macvtap: add TUNSETQUEUE ioctl

[Michael S. Tsirkin]

On Tue, Jun 04, 2013 at 01:54:56PM +0800, Jason Wang wrote:
> On 06/03/2013 07:09 PM, Michael S. Tsirkin wrote:
> > On Mon, Jun 03, 2013 at 01:20:58PM +0800, Jason Wang wrote:
> >> On 06/02/2013 07:22 PM, Michael S. Tsirkin wrote:
> >>> On Fri, May 31, 2013 at 05:53:24PM +0800, Jason Wang wrote:
>  This patch adds TUNSETQUEUE ioctl to let userspace can temporarily 
>  disable or
>  enable a queue of macvtap. This is used to be compatible at API layer of 
>  tuntap
>  to simplify the userspace to manage the queues.
> 
>  This is done by split the taps array into three different areas:
> 
>  - [0, numvtaps) : enabled taps
>  - [numvtaps, numvtaps + numdisabled) : disabled taps
>  - [numvtaps + numdisabled, MAX_MAXVTAP_QUEUES) : unused slots
> 
>  When a tap were enabled and disabled, it was moved to another area.
> 
>  Signed-off-by: Jason Wang 
> >>> This seems a bit tricky. Can we just move the tap out of the
> >>> array? 
> >> Certainly yes.
> >>> the only reason we have the array is for fast
> >>> lookup on xmit.
> >>> What's the reason to keep disabled queues there?
> >> It saves us some space and make code simpler.
> >>> To be able to track all queues for cleanups, all we need is
> >>> a linked list of all queues (enabled and disabled).
> >> Yes, but you need iterate both arrays and linked list which won't be
> >> simpler than keeping them in place.
> > No, my idea is to keep all taps in the list.
> >
> > If you need all taps, walks the list.
> > If you need active taps, look them up in the array.
> >
> > Reasonable?
> 
> Looks so, will change in next version.
> >
>  ---
>   drivers/net/macvtap.c  |  167 
>  
>   include/linux/if_macvlan.h |7 ++
>   2 files changed, 159 insertions(+), 15 deletions(-)
> 
>  diff --git a/drivers/net/macvtap.c b/drivers/net/macvtap.c
>  index eac49cb..03b781c 100644
>  --- a/drivers/net/macvtap.c
>  +++ b/drivers/net/macvtap.c
>  @@ -85,32 +85,126 @@ static const struct proto_ops macvtap_socket_ops;
>    */
>   static DEFINE_SPINLOCK(macvtap_lock);
>   
>  -static int macvtap_set_queue(struct net_device *dev, struct file *file,
>  +static void macvtap_swap_slot(struct macvlan_dev *vlan, int a, int b)
>  +{
>  +struct macvtap_queue *q1, *q2;
>  +
>  +if (a == b)
>  +return;
>  +
>  +q1 = rcu_dereference_protected(vlan->taps[a],
>  +   lockdep_is_held(&macvtap_lock));
>  +q2 = rcu_dereference_protected(vlan->taps[b],
>  +   lockdep_is_held(&macvtap_lock));
>  +
>  +BUG_ON(q1 == NULL || q2 == NULL);
>  +
>  +rcu_assign_pointer(vlan->taps[a], q2);
>  +rcu_assign_pointer(vlan->taps[b], q1);
>  +
>  +q1->queue_index = b;
>  +q2->queue_index = a;
>  +}
>  +
>  +static int macvtap_enable_queue(struct net_device *dev, struct file 
>  *file,
>   struct macvtap_queue *q)
>   {
>   struct macvlan_dev *vlan = netdev_priv(dev);
>  +int err = -EINVAL;
>  +int total;
>  +
>  +spin_lock(&macvtap_lock);
>  +total = vlan->numvtaps + vlan->numdisabled;
>  +
>  +if (q->queue_index < vlan->numvtaps)
>  +goto out;
>  +
>  +err = 0;
>  +
>  +BUG_ON(q->queue_index >= total);
>  +macvtap_swap_slot(vlan, q->queue_index, vlan->numvtaps);
>  +
>  +/* Make sure the pointers were seen before indices. */
>  +wmb();
> >>> Which indices?  We only care about numvtaps right?
> >>> So let's just say so.
> >> ok
> >>> Why is this wmb and not smp_wmb()?
> >> will correct it.
>  +
>  +vlan->numdisabled--;
>  +vlan->numvtaps++;
>  +out:
>  +spin_unlock(&macvtap_lock);
>  +return err;
>  +}
>  +
>  +static int macvtap_set_queue(struct net_device *dev, struct file *file,
>  + struct macvtap_queue *q)
>  +{
>  +struct macvlan_dev *vlan = netdev_priv(dev);
>   int err = -EBUSY;
>  +int total;
>   
>   spin_lock(&macvtap_lock);
>  -if (vlan->numvtaps == MAX_MACVTAP_QUEUES)
>  +
>  +total = vlan->numvtaps + vlan->numdisabled;
>  +if (total == MAX_MACVTAP_QUEUES)
>   goto out;
>   
>   err = 0;
>  +
>   rcu_assign_pointer(q->vlan, vlan);
>  -rcu_assign_pointer(vlan->taps[vlan->numvtaps], q);
>  +rcu_assign_pointer(vlan->taps[total], q);
>   sock_hold(&q->sk);
>   
>   q->file = file;
>  -q

Re: [PATCH] ARM: daVinci: remove __init modifier from function declaration

[Prabhakar Lad]

Hi Sekhar,

On Mon, Apr 1, 2013 at 5:03 PM, Prabhakar lad
 wrote:
> From: Lad, Prabhakar 
>
> This patch removes the __init modifier from function declaration
> of all the header files for davinci platform.
>
gentle ping for v3.11

Regards,
--Prabhakar Lad
--
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 07/10] pinctrl: add pinctrl driver for Rockchip SoCs

[Linus Walleij]

On Mon, Jun 3, 2013 at 12:59 AM, Heiko Stübner  wrote:

> This driver adds support the Cortex-A9 based SoCs from Rockchip,
> so at least the RK2928, RK3066 (a and b) and RK3188.
> Earlier Rockchip SoCs seem to use similar mechanics for gpio
> handling so should be supportable with relative small changes.
> Pull handling on the rk3188 is currently a stub, due to it being
> a bit different to the earlier SoCs.
>
> Pinmuxing as well as gpio (and interrupt-) handling tested on
> a rk3066a based machine.
>
> Signed-off-by: Heiko Stuebner 

Overall this is looking very good, mainly minor comments.

> +++ b/Documentation/devicetree/bindings/pinctrl/rockchip-pinctrl.txt

Please name this beginning with the vendor and similar to
the compatible string: rockchip,pinctrl or something.
(Check the neighbors.)

(...)
> +Required properties for gpio sub nodes:
> +  - compatible: "rockchip,gpio-bank"
> +  - reg: register of the gpio bank (different than the iomux registerset)
> +  - interrupts: base interrupt of the gpio bank in the interrupt controller
> +  - clocks: clock that drives this bank
> +  - gpio-controller: identifies the node as a gpio controller and pin bank.
> +  - #gpio-cells: number of cells in GPIO specifier. Since the generic GPIO
> +binding is used, the amount of cells must be specified as 2. See generic
> +GPIO binding documentation for description of particular cells.
> +  - interrupt-controller: identifies the controller node as interrupt-parent.
> +  - #interrupt-cells: the value of this property should be 2.
> + - First Cell: represents the external gpio interrupt number local to the
> +   external gpio interrupt space of the controller.
> + - Second Cell: flags to identify the type of the interrupt
> +   - 1 = rising edge triggered
> +   - 2 = falling edge triggered
> +   - 3 = rising and falling edge triggered
> +   - 4 = high level triggered
> +   - 8 = low level triggered

Can't you just reference
Documentation/devicetree/bindings/interrupt-controller/interrupts.txt?

> +Required properties for pin configuration node:
> +  - rockchip,pins: 4 integers array, represents a group of pins mux and 
> config
> +setting. The format is rockchip,pins =  CONFIG>.
> +The MUX 0 means gpio and MUX 1 to 3 mean the specific device function
> +
> +Bits used for CONFIG:
> +PULL_AUTO  (1 << 0): indicate this pin needs a pull setting for SoCs
> + that determine the pull up or down themselfs

Hm, never saw that before...

(...)
> +   uart2 {
> +   uart2_xfer: uart2-xfer {
> +   rockchip,pins = ,
> +   ;
> +   };

This looks like you're using #include to define these constants,
probably you should include that in the example or mention it?

> +uart2: serial@20064000 {
> +   compatible = "snps,dw-apb-uart";
> +   reg = <0x20064000 0x400>;
> +   interrupts = ;

Using #defines, nice!

(...)
+++ b/drivers/pinctrl/Kconfig
@@ -158,6 +158,12 @@ config PINCTRL_DB8540
bool "DB8540 pin controller driver"
depends on PINCTRL_NOMADIK && ARCH_U8500

+config PINCTRL_ROCKCHIP
+   bool
+   select PINMUX
+   select PINCONF
+   select GENERIC_IRQ_CHIP

Why is this super-simple pin config thing not using
GENERIC_PINCONF?

I *know* it is simpler to implement your own thing, but think of the
poor maintainers that have to wade through 50 identical implementations.
Do this, it pays off.

BTW: it leads to wanting to use generic pinconf DT bindings as experienced
by Laurent and others. We need to fix that too...

(...)
> +++ b/drivers/pinctrl/pinctrl-rockchip.c
> +static void rockchip_pin_dbg_show(struct pinctrl_dev *pctldev,
> +   struct seq_file *s, unsigned offset)
> +{
> +   seq_printf(s, "%s", dev_name(pctldev->dev));
> +}

Nothing else you want to say about the pins here?
(No big deal for sure, but)

> +static int rockchip_get_pull(struct rockchip_pin_bank *bank, int pin_num)
> +{
> +   struct rockchip_pinctrl *info = bank->drvdata;
> +   void __iomem *reg;
> +   int bit;

Is that really an int? I'd guess more like u8...

> +   u32 data;
> +
> +   /* rk3066b does support any pulls */
> +   if (!info->ctrl->pull_offset)
> +   return 0;
> +
> +   reg = info->reg_base + info->ctrl->pull_offset;
> +
> +   if (info->ctrl->pull_auto) {
> +   reg += bank->bank_num * 8;

I'd define some constant like

#define RK_BANK_STRIDE 8
reg += bank->bank_num * RK_BANK_STRIDE;
(Since 8 bytes of stride is no natural law.)

And then use that here and elsewhere.

> +   reg += (pin_num / 16) * 4;
> +   bit = pin_num % 16;

This is clear however.

> +
> +   data = readl_relaxed(reg);
> +   data >>= bit;
> +   data &= 1;
> +
> +   return !data;


That's a bit hard to read, I'd just:

#include

[RESEND][PATCH 3/7] net, ipw2x00: remove redundant D0 power state set

[Yijing Wang]

Pci_enable_device() will set device power state to D0,
so it's no need to do it again in ipw2100_pci_init_one().

Signed-off-by: Yijing Wang 
Cc: Stanislav Yakovlev 
Cc: "John W. Linville" 
Cc: net...@vger.kernel.org
Cc: linux-wirel...@vger.kernel.org
---
 drivers/net/wireless/ipw2x00/ipw2100.c |2 --
 1 files changed, 0 insertions(+), 2 deletions(-)

diff --git a/drivers/net/wireless/ipw2x00/ipw2100.c 
b/drivers/net/wireless/ipw2x00/ipw2100.c
index 15920aa..f8ab193 100644
--- a/drivers/net/wireless/ipw2x00/ipw2100.c
+++ b/drivers/net/wireless/ipw2x00/ipw2100.c
@@ -6242,8 +6242,6 @@ static int ipw2100_pci_init_one(struct pci_dev *pci_dev,
if ((val & 0xff00) != 0)
pci_write_config_dword(pci_dev, 0x40, val & 0x00ff);
 
-   pci_set_power_state(pci_dev, PCI_D0);
-
if (!ipw2100_hw_is_adapter_in_system(dev)) {
printk(KERN_WARNING DRV_NAME
   "Device not found via register read.\n");
-- 
1.7.1


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

[RESEND][PATCH] net: wireless: iwlegacy: fix build error for il_pm_ops

[Yijing Wang]

Fix build error for il_pm_ops if CONFIG_PM is set
but CONFIG_PM_SLEEP is not set.

ERROR: "il_pm_ops" [drivers/net/wireless/iwlegacy/iwl4965.ko] undefined!
ERROR: "il_pm_ops" [drivers/net/wireless/iwlegacy/iwl3945.ko] undefined!
make[1]: *** [__modpost] Error 1
make: *** [modules] Error 2

Acked-by: Jingoo Han 
Signed-off-by: Yijing Wang 
Cc: Stanislaw Gruszka 
Cc: "John W. Linville" 
Cc: net...@vger.kernel.org
Cc: linux-wirel...@vger.kernel.org
Cc: Jingoo Han 
---
 drivers/net/wireless/iwlegacy/common.h |6 +++---
 1 files changed, 3 insertions(+), 3 deletions(-)

diff --git a/drivers/net/wireless/iwlegacy/common.h 
b/drivers/net/wireless/iwlegacy/common.h
index f8246f2..4caaf52 100644
--- a/drivers/net/wireless/iwlegacy/common.h
+++ b/drivers/net/wireless/iwlegacy/common.h
@@ -1832,16 +1832,16 @@ u32 il_usecs_to_beacons(struct il_priv *il, u32 usec, 
u32 beacon_interval);
 __le32 il_add_beacon_time(struct il_priv *il, u32 base, u32 addon,
  u32 beacon_interval);
 
-#ifdef CONFIG_PM
+#ifdef CONFIG_PM_SLEEP
 extern const struct dev_pm_ops il_pm_ops;
 
 #define IL_LEGACY_PM_OPS   (&il_pm_ops)
 
-#else /* !CONFIG_PM */
+#else /* !CONFIG_PM_SLEEP */
 
 #define IL_LEGACY_PM_OPS   NULL
 
-#endif /* !CONFIG_PM */
+#endif /* !CONFIG_PM_SLEEP */
 
 /*
 *  Error Handling Debugging
-- 
1.7.1


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

Re: [PATCH 09/11] mmc: omap_hsmmc: enhance pinctrl support

[Linus Walleij]

On Fri, May 31, 2013 at 12:13 PM, Hebbar Gururaja
 wrote:

> Amend the hsmmc controller to optionally take a pin control handle and
> set the state of the pins to:
>
> - "default" on boot, resume and before performing a mmc transfer
> - "idle" after initial default, after resume default, and after each
> mmc/sd card access
> - "sleep" on suspend()
>
> By optionally putting the pins into sleep state in the suspend callback
> we can accomplish two things.
> - One is to minimize current leakage from pins and thus save power,
> - second, we can prevent the IP from driving pins output in an
> uncontrolled manner, which may happen if the power domain drops the
> domain regulator.
>
> If any of the above pin states are missing in dt, a warning message
> about the missing state is displayed.
> If certain pin-states are not available, to remove this warning message
> pass respective state name with null phandler.
>
> Signed-off-by: Hebbar Gururaja 
> Cc: Balaji T K 
> Cc: Chris Ball 
> Cc: linux-...@vger.kernel.org
> Cc: linux-o...@vger.kernel.org

This is perfectly correct.
Acked-by: Linus Walleij 

As the PM code seems to be similar across platforms I have had
loose plans to move this to the device core as well, but right now
I'm too busy with other things, and it can surely be refactored later.

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

Re: [PATCH RFC V9 9/19] Split out rate limiting from jump_label.h

[Raghavendra K T]

On 06/03/2013 09:26 PM, Konrad Rzeszutek Wilk wrote:

On Sun, Jun 02, 2013 at 12:54:22AM +0530, Raghavendra K T wrote:

Split jumplabel ratelimit


I would change the title a bit, perhaps prefix it with: "jump_label: "


From: Andrew Jones 

Commit b202952075f62603bea9bfb6ebc6b0420db11949 introduced rate limiting


Also please add right after the git id this:

("perf, core: Rate limit perf_sched_events jump_label patching")


Agreed.

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

Re: [PATCH RFC V9 12/19] xen: Enable PV ticketlocks on HVM Xen

[Raghavendra K T]

On 06/03/2013 09:27 PM, Konrad Rzeszutek Wilk wrote:

On Sun, Jun 02, 2013 at 12:55:03AM +0530, Raghavendra K T wrote:

xen: Enable PV ticketlocks on HVM Xen


There is more to it. You should also revert 
70dd4998cb85f0ecd6ac892cc7232abefa432efb



Yes, true. Do you expect the revert to be folded into this patch itself?

--
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: Exotic architecture fixes

[Geert Uytterhoeven]

On Mon, Jun 3, 2013 at 3:28 AM, Stephen Rothwell  wrote:
> On Sun, 2 Jun 2013 21:39:38 +0200 Geert Uytterhoeven  
> wrote:
>> On Tue, May 28, 2013 at 11:38 AM, Geert Uytterhoeven
>>  wrote:
>> > On Thu, May 23, 2013 at 10:09 PM, Geert Uytterhoeven
>> >  wrote:
>> >> I created a branch where I collected several exotic architecture fixes
>> >> (and a few
>> >> other trivial fixes):
>> >>
>> >>   git://git.kernel.org/pub/scm/linux/kernel/git/geert/linux-m68k.git 
>> >> exotic-arch-fixes
>> >>
>> >> Several of these have been ack'ed (cfr. *-indicators below).
>> >> If you reject any of the commits, please scream.
>> >> If you want to take any of them yourself, please do so.
>> >>
>> >> I intend to merge this into my for-next branch after the release of 
>> >> v3.10-rc4,
>> >> and ask Linus to pull after the release of v3.10-rc5.
>>
>> I merged this in the for-next branch of my repo.
>
> Surely, your for-linus branch would have been a better choice.  And then
> maybe merge that into your for-next branch if you really needed these
> fixes to continue with m68k work?

An updated version is now in for-linus, as Linus has pulled the m68k
content on the
old for-linus branch.

Gr{oetje,eeting}s,

Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
--
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/

[RESEND][PATCH 2/7] usb, dwc3: remove redundant D0 power state set

[Yijing Wang]

Pci_enable_device() will set device power state to D0,
so it's no need to do it again in dwc3_pci_probe().

Signed-off-by: Yijing Wang 
Cc: Felipe Balbi 
Cc: linux-o...@vger.kernel.org
Cc: linux-...@vger.kernel.org
---
 drivers/usb/dwc3/dwc3-pci.c |1 -
 1 files changed, 0 insertions(+), 1 deletions(-)

diff --git a/drivers/usb/dwc3/dwc3-pci.c b/drivers/usb/dwc3/dwc3-pci.c
index 227d4a7..c068608 100644
--- a/drivers/usb/dwc3/dwc3-pci.c
+++ b/drivers/usb/dwc3/dwc3-pci.c
@@ -133,7 +133,6 @@ static int dwc3_pci_probe(struct pci_dev *pci,
return -ENODEV;
}
 
-   pci_set_power_state(pci, PCI_D0);
pci_set_master(pci);
 
ret = dwc3_pci_register_phys(glue);
-- 
1.7.1


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

Re: [PATCH RFC V9 16/19] kvm : Paravirtual ticketlocks support for linux guests running on KVM hypervisor

[Raghavendra K T]

On 06/03/2013 09:30 PM, Konrad Rzeszutek Wilk wrote:

On Sun, Jun 02, 2013 at 12:55:57AM +0530, Raghavendra K T wrote:

kvm : Paravirtual ticketlocks support for linux guests running on KVM hypervisor

From: Srivatsa Vaddagiri 

During smp_boot_cpus  paravirtualied KVM guest detects if the hypervisor has
required feature (KVM_FEATURE_PV_UNHALT) to support pv-ticketlocks. If so,
  support for pv-ticketlocks is registered via pv_lock_ops.

Use KVM_HC_KICK_CPU hypercall to wakeup waiting/halted vcpu.

Signed-off-by: Srivatsa Vaddagiri 
Signed-off-by: Suzuki Poulose 
[Raghu: check_zero race fix, enum for kvm_contention_stat
jumplabel related changes ]
Signed-off-by: Raghavendra K T 
---
  arch/x86/include/asm/kvm_para.h |   14 ++
  arch/x86/kernel/kvm.c   |  256 +++
  2 files changed, 268 insertions(+), 2 deletions(-)

diff --git a/arch/x86/include/asm/kvm_para.h b/arch/x86/include/asm/kvm_para.h
index 695399f..427afcb 100644
--- a/arch/x86/include/asm/kvm_para.h
+++ b/arch/x86/include/asm/kvm_para.h
@@ -118,10 +118,20 @@ void kvm_async_pf_task_wait(u32 token);
  void kvm_async_pf_task_wake(u32 token);
  u32 kvm_read_and_reset_pf_reason(void);
  extern void kvm_disable_steal_time(void);
-#else
-#define kvm_guest_init() do { } while (0)
+
+#ifdef CONFIG_PARAVIRT_SPINLOCKS
+void __init kvm_spinlock_init(void);
+#else /* !CONFIG_PARAVIRT_SPINLOCKS */
+static inline void kvm_spinlock_init(void)
+{
+}
+#endif /* CONFIG_PARAVIRT_SPINLOCKS */
+
+#else /* CONFIG_KVM_GUEST */
+#define kvm_guest_init() do {} while (0)
  #define kvm_async_pf_task_wait(T) do {} while(0)
  #define kvm_async_pf_task_wake(T) do {} while(0)
+
  static inline u32 kvm_read_and_reset_pf_reason(void)
  {
return 0;
diff --git a/arch/x86/kernel/kvm.c b/arch/x86/kernel/kvm.c
index cd6d9a5..2715b92 100644
--- a/arch/x86/kernel/kvm.c
+++ b/arch/x86/kernel/kvm.c
@@ -34,6 +34,7 @@
  #include 
  #include 
  #include 
+#include 
  #include 
  #include 
  #include 
@@ -419,6 +420,7 @@ static void __init kvm_smp_prepare_boot_cpu(void)
WARN_ON(kvm_register_clock("primary cpu clock"));
kvm_guest_cpu_init();
native_smp_prepare_boot_cpu();
+   kvm_spinlock_init();
  }

  static void __cpuinit kvm_guest_cpu_online(void *dummy)
@@ -523,3 +525,257 @@ static __init int activate_jump_labels(void)
return 0;
  }
  arch_initcall(activate_jump_labels);
+
+/* Kick a cpu by its apicid. Used to wake up a halted vcpu */
+void kvm_kick_cpu(int cpu)
+{
+   int apicid;
+
+   apicid = per_cpu(x86_cpu_to_apicid, cpu);
+   kvm_hypercall1(KVM_HC_KICK_CPU, apicid);
+}
+
+#ifdef CONFIG_PARAVIRT_SPINLOCKS
+
+enum kvm_contention_stat {
+   TAKEN_SLOW,
+   TAKEN_SLOW_PICKUP,
+   RELEASED_SLOW,
+   RELEASED_SLOW_KICKED,
+   NR_CONTENTION_STATS
+};
+
+#ifdef CONFIG_KVM_DEBUG_FS
+#define HISTO_BUCKETS  30
+
+static struct kvm_spinlock_stats
+{
+   u32 contention_stats[NR_CONTENTION_STATS];
+   u32 histo_spin_blocked[HISTO_BUCKETS+1];
+   u64 time_blocked;
+} spinlock_stats;
+
+static u8 zero_stats;
+
+static inline void check_zero(void)
+{
+   u8 ret;
+   u8 old;
+
+   old = ACCESS_ONCE(zero_stats);
+   if (unlikely(old)) {
+   ret = cmpxchg(&zero_stats, old, 0);
+   /* This ensures only one fellow resets the stat */
+   if (ret == old)
+   memset(&spinlock_stats, 0, sizeof(spinlock_stats));
+   }
+}
+
+static inline void add_stats(enum kvm_contention_stat var, u32 val)
+{
+   check_zero();
+   spinlock_stats.contention_stats[var] += val;
+}
+
+
+static inline u64 spin_time_start(void)
+{
+   return sched_clock();
+}
+
+static void __spin_time_accum(u64 delta, u32 *array)
+{
+   unsigned index;
+
+   index = ilog2(delta);
+   check_zero();
+
+   if (index < HISTO_BUCKETS)
+   array[index]++;
+   else
+   array[HISTO_BUCKETS]++;
+}
+
+static inline void spin_time_accum_blocked(u64 start)
+{
+   u32 delta;
+
+   delta = sched_clock() - start;
+   __spin_time_accum(delta, spinlock_stats.histo_spin_blocked);
+   spinlock_stats.time_blocked += delta;
+}
+
+static struct dentry *d_spin_debug;
+static struct dentry *d_kvm_debug;
+
+struct dentry *kvm_init_debugfs(void)
+{
+   d_kvm_debug = debugfs_create_dir("kvm", NULL);
+   if (!d_kvm_debug)
+   printk(KERN_WARNING "Could not create 'kvm' debugfs 
directory\n");
+
+   return d_kvm_debug;
+}
+
+static int __init kvm_spinlock_debugfs(void)
+{
+   struct dentry *d_kvm;
+
+   d_kvm = kvm_init_debugfs();
+   if (d_kvm == NULL)
+   return -ENOMEM;
+
+   d_spin_debug = debugfs_create_dir("spinlocks", d_kvm);
+
+   debugfs_create_u8("zero_stats", 0644, d_spin_debug, &zero_stats);
+
+   debugfs_create_u32("taken_slow", 0444, d_spin_debug,
+  &spinlock_stats.contention_stats[TAKEN_SLOW]);
+   debugf

Re: [PATCH 1/2, v2] PM / Runtime: Rework the "runtime idle" helper routine

[Lan Tianyu]

2013/6/3 Rafael J. Wysocki :
> From: Rafael J. Wysocki 
>
> The "runtime idle" helper routine, rpm_idle(), currently ignores
> return values from .runtime_idle() callbacks executed by it.
> However, it turns out that many subsystems use
> pm_generic_runtime_idle() which checks the return value of the
> driver's callback and executes pm_runtime_suspend() for the device
> unless that value is not 0.  If that logic is moved to rpm_idle()
> instead, pm_generic_runtime_idle() can be dropped and its users
> will not need any .runtime_idle() callbacks any more.
>
> Moreover, the PCI, SCSI, and SATA subsystems' .runtime_idle()
> routines, pci_pm_runtime_idle(), scsi_runtime_idle(), and
> ata_port_runtime_idle(), respectively, as well as a few drivers'
> ones may be simplified if rpm_idle() calls rpm_suspend() after 0 has
> been returned by the .runtime_idle() callback executed by it.
>
> To reduce overall code bloat, make the changes described above.
>
Usb runtime pm works normally with this patch.
Tested-by: Lan Tianyu 

> Tested-by: Mika Westerberg 
> Tested-by: Kevin Hilman 
> Signed-off-by: Rafael J. Wysocki 
> Acked-by: Kevin Hilman 
> Reviewed-by: Ulf Hansson 
> ---
>  Documentation/power/runtime_pm.txt |5 -
>  arch/arm/mach-omap2/omap_device.c  |7 +--
>  drivers/acpi/device_pm.c   |1 -
>  drivers/amba/bus.c |2 +-
>  drivers/ata/libata-core.c  |2 +-
>  drivers/base/platform.c|1 -
>  drivers/base/power/domain.c|1 -
>  drivers/base/power/generic_ops.c   |   23 ---
>  drivers/base/power/runtime.c   |   12 +---
>  drivers/dma/intel_mid_dma.c|2 +-
>  drivers/gpio/gpio-langwell.c   |6 +-
>  drivers/i2c/i2c-core.c |2 +-
>  drivers/mfd/ab8500-gpadc.c |8 +---
>  drivers/mmc/core/bus.c |2 +-
>  drivers/mmc/core/sdio_bus.c|2 +-
>  drivers/pci/pci-driver.c   |   14 +-
>  drivers/scsi/scsi_pm.c |   11 +++
>  drivers/sh/pm_runtime.c|2 +-
>  drivers/spi/spi.c  |2 +-
>  drivers/tty/serial/mfd.c   |9 ++---
>  drivers/usb/core/driver.c  |3 ++-
>  drivers/usb/core/port.c|1 -
>  include/linux/pm_runtime.h |2 --
>  23 files changed, 28 insertions(+), 92 deletions(-)
>
> Index: linux-pm/drivers/base/power/runtime.c
> ===
> --- linux-pm.orig/drivers/base/power/runtime.c
> +++ linux-pm/drivers/base/power/runtime.c
> @@ -293,11 +293,8 @@ static int rpm_idle(struct device *dev,
> /* Pending requests need to be canceled. */
> dev->power.request = RPM_REQ_NONE;
>
> -   if (dev->power.no_callbacks) {
> -   /* Assume ->runtime_idle() callback would have suspended. */
> -   retval = rpm_suspend(dev, rpmflags);
> +   if (dev->power.no_callbacks)
> goto out;
> -   }
>
> /* Carry out an asynchronous or a synchronous idle notification. */
> if (rpmflags & RPM_ASYNC) {
> @@ -306,7 +303,8 @@ static int rpm_idle(struct device *dev,
> dev->power.request_pending = true;
> queue_work(pm_wq, &dev->power.work);
> }
> -   goto out;
> +   trace_rpm_return_int(dev, _THIS_IP_, 0);
> +   return 0;
> }
>
> dev->power.idle_notification = true;
> @@ -326,14 +324,14 @@ static int rpm_idle(struct device *dev,
> callback = dev->driver->pm->runtime_idle;
>
> if (callback)
> -   __rpm_callback(callback, dev);
> +   retval = __rpm_callback(callback, dev);
>
> dev->power.idle_notification = false;
> wake_up_all(&dev->power.wait_queue);
>
>   out:
> trace_rpm_return_int(dev, _THIS_IP_, retval);
> -   return retval;
> +   return retval ? retval : rpm_suspend(dev, rpmflags);
>  }
>
>  /**
> Index: linux-pm/drivers/base/power/generic_ops.c
> ===
> --- linux-pm.orig/drivers/base/power/generic_ops.c
> +++ linux-pm/drivers/base/power/generic_ops.c
> @@ -12,29 +12,6 @@
>
>  #ifdef CONFIG_PM_RUNTIME
>  /**
> - * pm_generic_runtime_idle - Generic runtime idle callback for subsystems.
> - * @dev: Device to handle.
> - *
> - * If PM operations are defined for the @dev's driver and they include
> - * ->runtime_idle(), execute it and return its error code, if nonzero.
> - * Otherwise, execute pm_runtime_suspend() for the device and return 0.
> - */
> -int pm_generic_runtime_idle(struct device *dev)
> -{
> -   const struct dev_pm_ops *pm = dev->driver ? dev->driver->pm : NULL;
> -
> -   if (pm && pm->runtime_idle) {
> -   int ret = pm->runtime_idle(dev);
> -   if (ret)
> -   return ret;
> -   }

Re: [PATCH RFC V9 5/19] xen/pvticketlock: Xen implementation for PV ticket locks

[Raghavendra K T]

On 06/03/2013 09:33 PM, Konrad Rzeszutek Wilk wrote:

On Sat, Jun 01, 2013 at 12:23:14PM -0700, Raghavendra K T wrote:

xen/pvticketlock: Xen implementation for PV ticket locks

From: Jeremy Fitzhardinge 

Replace the old Xen implementation of PV spinlocks with and implementation
of xen_lock_spinning and xen_unlock_kick.

xen_lock_spinning simply registers the cpu in its entry in lock_waiting,
adds itself to the waiting_cpus set, and blocks on an event channel
until the channel becomes pending.

xen_unlock_kick searches the cpus in waiting_cpus looking for the one
which next wants this lock with the next ticket, if any.  If found,
it kicks it by making its event channel pending, which wakes it up.

We need to make sure interrupts are disabled while we're relying on the
contents of the per-cpu lock_waiting values, otherwise an interrupt
handler could come in, try to take some other lock, block, and overwrite
our values.

Raghu: use function + enum instead of macro, cmpxchg for zero status reset

Signed-off-by: Jeremy Fitzhardinge 
Reviewed-by: Konrad Rzeszutek Wilk 
Signed-off-by: Raghavendra K T 
---
  arch/x86/xen/spinlock.c |  347 +++
  1 file changed, 78 insertions(+), 269 deletions(-)

diff --git a/arch/x86/xen/spinlock.c b/arch/x86/xen/spinlock.c
index d6481a9..860e190 100644
--- a/arch/x86/xen/spinlock.c
+++ b/arch/x86/xen/spinlock.c
@@ -16,45 +16,44 @@
  #include "xen-ops.h"
  #include "debugfs.h"

-#ifdef CONFIG_XEN_DEBUG_FS
-static struct xen_spinlock_stats
-{
-   u64 taken;
-   u32 taken_slow;
-   u32 taken_slow_nested;
-   u32 taken_slow_pickup;
-   u32 taken_slow_spurious;
-   u32 taken_slow_irqenable;
+enum xen_contention_stat {
+   TAKEN_SLOW,
+   TAKEN_SLOW_PICKUP,
+   TAKEN_SLOW_SPURIOUS,
+   RELEASED_SLOW,
+   RELEASED_SLOW_KICKED,
+   NR_CONTENTION_STATS
+};

-   u64 released;
-   u32 released_slow;
-   u32 released_slow_kicked;

+#ifdef CONFIG_XEN_DEBUG_FS
  #define HISTO_BUCKETS 30
-   u32 histo_spin_total[HISTO_BUCKETS+1];
-   u32 histo_spin_spinning[HISTO_BUCKETS+1];
+static struct xen_spinlock_stats
+{
+   u32 contention_stats[NR_CONTENTION_STATS];
u32 histo_spin_blocked[HISTO_BUCKETS+1];
-
-   u64 time_total;
-   u64 time_spinning;
u64 time_blocked;
  } spinlock_stats;

  static u8 zero_stats;

-static unsigned lock_timeout = 1 << 10;
-#define TIMEOUT lock_timeout
-
  static inline void check_zero(void)
  {
-   if (unlikely(zero_stats)) {
-   memset(&spinlock_stats, 0, sizeof(spinlock_stats));
-   zero_stats = 0;
+   u8 ret;
+   u8 old = ACCESS_ONCE(zero_stats);
+   if (unlikely(old)) {
+   ret = cmpxchg(&zero_stats, old, 0);
+   /* This ensures only one fellow resets the stat */
+   if (ret == old)
+   memset(&spinlock_stats, 0, sizeof(spinlock_stats));
}
  }

-#define ADD_STATS(elem, val)   \
-   do { check_zero(); spinlock_stats.elem += (val); } while(0)
+static inline void add_stats(enum xen_contention_stat var, u32 val)
+{
+   check_zero();
+   spinlock_stats.contention_stats[var] += val;
+}

  static inline u64 spin_time_start(void)
  {
@@ -73,22 +72,6 @@ static void __spin_time_accum(u64 delta, u32 *array)
array[HISTO_BUCKETS]++;
  }

-static inline void spin_time_accum_spinning(u64 start)
-{
-   u32 delta = xen_clocksource_read() - start;
-
-   __spin_time_accum(delta, spinlock_stats.histo_spin_spinning);
-   spinlock_stats.time_spinning += delta;
-}
-
-static inline void spin_time_accum_total(u64 start)
-{
-   u32 delta = xen_clocksource_read() - start;
-
-   __spin_time_accum(delta, spinlock_stats.histo_spin_total);
-   spinlock_stats.time_total += delta;
-}
-
  static inline void spin_time_accum_blocked(u64 start)
  {
u32 delta = xen_clocksource_read() - start;
@@ -98,19 +81,15 @@ static inline void spin_time_accum_blocked(u64 start)
  }
  #else  /* !CONFIG_XEN_DEBUG_FS */
  #define TIMEOUT   (1 << 10)
-#define ADD_STATS(elem, val)   do { (void)(val); } while(0)
+static inline void add_stats(enum xen_contention_stat var, u32 val)
+{
+}

  static inline u64 spin_time_start(void)
  {
return 0;
  }

-static inline void spin_time_accum_total(u64 start)
-{
-}
-static inline void spin_time_accum_spinning(u64 start)
-{
-}
  static inline void spin_time_accum_blocked(u64 start)
  {
  }
@@ -133,229 +112,82 @@ typedef u16 xen_spinners_t;
asm(LOCK_PREFIX " decw %0" : "+m" ((xl)->spinners) : : "memory");
  #endif

-struct xen_spinlock {
-   unsigned char lock; /* 0 -> free; 1 -> locked */
-   xen_spinners_t spinners;/* count of waiting cpus */
+struct xen_lock_waiting {
+   struct arch_spinlock *lock;
+   __ticket_t want;
  };

  static DEFINE_PER_CPU(int, lock_kicker_irq) = -1;
+static DEFINE_PER_

Re: [Patch 3/3] clk: Avoid re-parenting orphan clk's having invalid parent index.

[Ambresh K]

On Wednesday 29 May 2013 12:48 PM, Mike Turquette wrote:
> Quoting Ambresh K (2013-05-01 23:25:29)
>> From: Ambresh K 
>>
>> Add orhan clk nodes having invalid parent index to list and use
>> the list to skip re-parenting orphan clk having invalid parents.
>>
>> Signed-off-by: Ambresh K 
>> ---
>>  drivers/clk/clk.c |   21 +++--
>>  1 files changed, 19 insertions(+), 2 deletions(-)
>>
>> diff --git a/drivers/clk/clk.c b/drivers/clk/clk.c
>> index f4d2c73..54d2aa3 100644
>> --- a/drivers/clk/clk.c
>> +++ b/drivers/clk/clk.c
>> @@ -32,6 +32,7 @@ static int enable_refcnt;
>>  
>>  static HLIST_HEAD(clk_root_list);
>>  static HLIST_HEAD(clk_orphan_list);
>> +static HLIST_HEAD(clk_orphan_invalid_parent);
> 
> Why not re-use the clk_orphan_list?  Having an invalid value programmed
> into the hardware for selecting a parent essetially orphans a clock
> from a software point of view.  Is there a specific need for the new
> list?

Sorry for not being descriptive in commit message.  

a) Avoids unnecessary re-parenting cycle for orphan clock's with invalid parent 
for every clock

b) With patch [1/3], after a clk with invalid parent was encountered, for every 
clk registered thereafter seeing following logs. 

[0.00] __clk_init: orphan clk(gpu_core_gclk_mux) invalid parent
[0.00] __clk_init: orphan clk(gpu_core_gclk_mux) invalid parent
[0.00] __clk_init: orphan clk(gpu_core_gclk_mux) invalid parent
[0.00] __clk_init: orphan clk(gpu_core_gclk_mux) invalid parent
[0.00] __clk_init: orphan clk(gpu_core_gclk_mux) invalid parent
[0.00] __clk_init: orphan clk(gpu_core_gclk_mux) invalid parent
[0.00] __clk_init: orphan clk(gpu_core_gclk_mux) invalid parent
[0.00] __clk_init: orphan clk(gpu_core_gclk_mux) invalid parent  

Please advice, if can be handled better. 

Thanks, 
Ambresh


> 
> Regards,
> Mike
> 
>>  static LIST_HEAD(clk_notifier_list);
>>  
>>  /***   locking ***/
>> @@ -1532,8 +1533,8 @@ EXPORT_SYMBOL_GPL(clk_set_parent);
>>   */
>>  int __clk_init(struct device *dev, struct clk *clk)
>>  {
>> -   int i, ret = 0;
>> -   struct clk *orphan;
>> +   int i, ret = 0, skip = 0;
>> +   struct clk *orphan, *has_invalid_parent;
>> struct hlist_node *tmp2;
>>  
>> if (!clk)
>> @@ -1639,11 +1640,27 @@ int __clk_init(struct device *dev, struct clk *clk)
>> if (!strcmp(clk->name, orphan->name))
>> continue;
>>  
>> +   /* Skip iteration if orphan has invalid parent */
>> +   hlist_for_each_entry(has_invalid_parent,
>> +   &clk_orphan_invalid_parent, child_node) {
>> +   if (!strcmp(orphan->name, has_invalid_parent->name)) 
>> {
>> +   skip = 1;
>> +   break;
>> +   }
>> +   }
>> +
>> +   if (skip) {
>> +   skip = 0;
>> +   continue;
>> +   }
>> +
>> if (orphan->ops->get_parent) {
>> i = orphan->ops->get_parent(orphan->hw);
>> if (i < 0) {
>> pr_err("%s: orphan clk(%s) invalid parent\n",
>> __func__, orphan->name);
>> +   hlist_add_head(&orphan->child_node,
>> +   &clk_orphan_invalid_parent);
>> continue;
>> }
>> if (!strcmp(clk->name, orphan->parent_names[i]))
>> -- 
>> 1.7.4.1
> 
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v2 0/2] USB: PHY: Improve PHY selection logic

[Roger Quadros]

On 06/03/2013 08:47 PM, Greg KH wrote:
> On Fri, May 31, 2013 at 02:29:01PM +0300, Roger Quadros wrote:
>> Hi,
>>
>> Improve Kconfig so that the relevant PHY driver can be explicitely
>> selected by the controller driver instead of relying on the user
>> to do so.
>>
>> Detailed description in patch 1.
> 
> Felipe needs to take these, not I.
> 

Felipe,

Could you please take these if appropriate? Thanks.

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

Re: [PATCH RFC V9 18/19] Documentation/kvm : Add documentation on Hypercalls and features used for PV spinlock

[Raghavendra K T]

On 06/03/2013 09:34 PM, Konrad Rzeszutek Wilk wrote:

On Sun, Jun 02, 2013 at 12:56:24AM +0530, Raghavendra K T wrote:

Documentation/kvm : Add documentation on Hypercalls and features used for PV 
spinlock

From: Raghavendra K T 

KVM_HC_KICK_CPU  hypercall added to wakeup halted vcpu in paravirtual spinlock
enabled guest.

KVM_FEATURE_PV_UNHALT enables guest to check whether pv spinlock can be enabled
in guest.

Thanks Vatsa for rewriting KVM_HC_KICK_CPU

Signed-off-by: Srivatsa Vaddagiri 
Signed-off-by: Raghavendra K T 
---
  Documentation/virtual/kvm/cpuid.txt  |4 
  Documentation/virtual/kvm/hypercalls.txt |   13 +
  2 files changed, 17 insertions(+)

diff --git a/Documentation/virtual/kvm/cpuid.txt 
b/Documentation/virtual/kvm/cpuid.txt
index 83afe65..654f43c 100644
--- a/Documentation/virtual/kvm/cpuid.txt
+++ b/Documentation/virtual/kvm/cpuid.txt
@@ -43,6 +43,10 @@ KVM_FEATURE_CLOCKSOURCE2   || 3 || kvmclock 
available at msrs
  KVM_FEATURE_ASYNC_PF   || 4 || async pf can be enabled by
 ||   || writing to msr 0x4b564d02
  --
+KVM_FEATURE_PV_UNHALT  || 6 || guest checks this feature bit
+   ||   || before enabling paravirtualized
+   ||   || spinlock support.
+--
  KVM_FEATURE_CLOCKSOURCE_STABLE_BIT ||24 || host will warn if no guest-side
 ||   || per-cpu warps are expected in
 ||   || kvmclock.
diff --git a/Documentation/virtual/kvm/hypercalls.txt 
b/Documentation/virtual/kvm/hypercalls.txt
index ea113b5..2a4da11 100644
--- a/Documentation/virtual/kvm/hypercalls.txt
+++ b/Documentation/virtual/kvm/hypercalls.txt
@@ -64,3 +64,16 @@ Purpose: To enable communication between the hypervisor and 
guest there is a
  shared page that contains parts of supervisor visible register state.
  The guest can map this shared page to access its supervisor register through
  memory using this hypercall.
+
+5. KVM_HC_KICK_CPU
+
+Architecture: x86
+Status: active
+Purpose: Hypercall used to wakeup a vcpu from HLT state
+Usage example : A vcpu of a paravirtualized guest that is busywaiting in guest
+kernel mode for an event to occur (ex: a spinlock to become available) can
+execute HLT instruction once it has busy-waited for more than a threshold
+time-interval. Execution of HLT instruction would cause the hypervisor to put
+the vcpu to sleep until occurence of an appropriate event. Another vcpu of the
+same guest can wakeup the sleeping vcpu by issuing KVM_HC_KICK_CPU hypercall,
+specifying APIC ID of the vcpu to be wokenup.


woken up.


Yep. :)

--
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 v4] arm: zynq: Add cpuidle support

[Michal Simek]

Add support for cpuidle.

Signed-off-by: Michal Simek 
---
Changes in v4:
- Add record to MAINTAINERS file
- Use long license in header + Maintainer record
- Remove unused headers
- Fix indentations
- s/zynq_init_cpuidle/zynq_cpuidle_init/g
- use cpuidle_register function
- Do not use module_init, use device_initcall instead
  (Using it as module is not possible because some
   arm core functions are not exported for modules)

Changes in v3:
- Move driver to drivers/cpuidle/
- Check zynq compatible string suggested by Arnd
- Use zynq_ function prefix because of multiplatform kernel
- Incorporate comments from Daniel Lezcano
- Rebase on the top of 
git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm.git linux-next

Changes in v2:
- Fix file header

Changes in v1:
- It was the part of Zynq core changes
  https://patchwork.kernel.org/patch/2342511/

 MAINTAINERS|  1 +
 drivers/cpuidle/Kconfig|  6 +++
 drivers/cpuidle/Makefile   |  1 +
 drivers/cpuidle/cpuidle-zynq.c | 83 ++
 4 files changed, 91 insertions(+)
 create mode 100644 drivers/cpuidle/cpuidle-zynq.c

diff --git a/MAINTAINERS b/MAINTAINERS
index 90f45f4..6e4d4e0 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -1309,6 +1309,7 @@ W:http://wiki.xilinx.com
 T: git git://git.xilinx.com/linux-xlnx.git
 S: Supported
 F: arch/arm/mach-zynq/
+F: drivers/cpuidle/cpuidle-zynq.c

 ARM64 PORT (AARCH64 ARCHITECTURE)
 M: Catalin Marinas 
diff --git a/drivers/cpuidle/Kconfig b/drivers/cpuidle/Kconfig
index c4cc27e..8272a08 100644
--- a/drivers/cpuidle/Kconfig
+++ b/drivers/cpuidle/Kconfig
@@ -39,4 +39,10 @@ config CPU_IDLE_CALXEDA
help
  Select this to enable cpuidle on Calxeda processors.

+config CPU_IDLE_ZYNQ
+   bool "CPU Idle Driver for Xilinx Zynq processors"
+   depends on ARCH_ZYNQ
+   help
+ Select this to enable cpuidle on Xilinx Zynq processors.
+
 endif
diff --git a/drivers/cpuidle/Makefile b/drivers/cpuidle/Makefile
index 0d8bd55..8767a7b 100644
--- a/drivers/cpuidle/Makefile
+++ b/drivers/cpuidle/Makefile
@@ -7,3 +7,4 @@ obj-$(CONFIG_ARCH_NEEDS_CPU_IDLE_COUPLED) += coupled.o

 obj-$(CONFIG_CPU_IDLE_CALXEDA) += cpuidle-calxeda.o
 obj-$(CONFIG_ARCH_KIRKWOOD) += cpuidle-kirkwood.o
+obj-$(CONFIG_CPU_IDLE_ZYNQ) += cpuidle-zynq.o
diff --git a/drivers/cpuidle/cpuidle-zynq.c b/drivers/cpuidle/cpuidle-zynq.c
new file mode 100644
index 000..38e03a1
--- /dev/null
+++ b/drivers/cpuidle/cpuidle-zynq.c
@@ -0,0 +1,83 @@
+/*
+ * Copyright (C) 2012-2013 Xilinx
+ *
+ * CPU idle support for Xilinx Zynq
+ *
+ * based on arch/arm/mach-at91/cpuidle.c
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms and conditions of the GNU General Public License,
+ * version 2, as published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope it will be useful, but WITHOUT
+ * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
+ * FITNESS FOR A PARTICULAR PURPOSE.  See the GNU General Public License for
+ * more details.
+ *
+ * You should have received a copy of the GNU General Public License along with
+ * this program.  If not, see .
+ *
+ * The cpu idle uses wait-for-interrupt and RAM self refresh in order
+ * to implement two idle states -
+ * #1 wait-for-interrupt
+ * #2 wait-for-interrupt and RAM self refresh
+ *
+ * Maintainer: Michal Simek 
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#define ZYNQ_MAX_STATES2
+
+/* Actual code that puts the SoC in different idle states */
+static int zynq_enter_idle(struct cpuidle_device *dev,
+  struct cpuidle_driver *drv, int index)
+{
+   /* Devices must be stopped here */
+   cpu_pm_enter();
+
+   /* Add code for DDR self refresh start */
+   cpu_do_idle();
+
+   /* Add code for DDR self refresh stop */
+   cpu_pm_exit();
+
+   return index;
+}
+
+static struct cpuidle_driver zynq_idle_driver = {
+   .name = "zynq_idle",
+   .owner = THIS_MODULE,
+   .states = {
+   ARM_CPUIDLE_WFI_STATE,
+   {
+   .enter  = zynq_enter_idle,
+   .exit_latency   = 10,
+   .target_residency   = 1,
+   .flags  = CPUIDLE_FLAG_TIME_VALID |
+ CPUIDLE_FLAG_TIMER_STOP,
+   .name   = "RAM_SR",
+   .desc   = "WFI and RAM Self Refresh",
+   },
+   },
+   .safe_state_index = 0,
+   .state_count = ZYNQ_MAX_STATES,
+};
+
+/* Initialize CPU idle by registering the idle states */
+static int __init zynq_cpuidle_init(void)
+{
+   if (!of_machine_is_compatible("xlnx,zynq-7000"))
+   return -EN

Re: [PATCH 02/11] leds: leds-gpio: Enhance pinctrl support

[Linus Walleij]

On Fri, May 31, 2013 at 12:13 PM, Hebbar Gururaja
 wrote:

>  struct gpio_leds_priv {
> int num_leds;
> +   /* Two optional pin states - default & sleep */
> +   struct pinctrl  *pinctrl;
> +   struct pinctrl_state*pins_default;
> +   struct pinctrl_state*pins_sleep;
> struct gpio_led_data leds[];
>  };

Or actually, wait. You're adding quite a lot of these.

Could you try:

- Adding pins_sleep and pins_idle to struct dev_pin_info
  in include/linux/pinctrl/devinfo.h

- Modify drivers/base/pinctrl.c to optionally look up
  sleep and idle states, you can make that code
  #ifdef CONFIG_PM I think.

- Add something like static inline functions to
  include/linux/pinctrl/consumer.h
  with names like pinctrl_select_pm_idle(struct device *)
  pinctrl_select_pm_sleep(struct device *) to switch states
  using the device core containers, and includes
  checking IS_ERR() on the handles etc.

I think this will save a *lot* of identical code in all the
drivers, that will just have to call
pinctrl_select_pm_sleep(), pinctrl_select_pm_default()
pinctrl_select_pm_idle() instead of all the complex code.

This is what I planned to do but never got around to.

Please?

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

Re: [PATCH 09/11] mmc: omap_hsmmc: enhance pinctrl support

[Linus Walleij]

On Tue, Jun 4, 2013 at 9:11 AM, Linus Walleij  wrote:
> On Fri, May 31, 2013 at 12:13 PM, Hebbar Gururaja
>  wrote:
>
>> Amend the hsmmc controller to optionally take a pin control handle and
>> set the state of the pins to:
>>
>> - "default" on boot, resume and before performing a mmc transfer
>> - "idle" after initial default, after resume default, and after each
>> mmc/sd card access
>> - "sleep" on suspend()
>>
>> By optionally putting the pins into sleep state in the suspend callback
>> we can accomplish two things.
>> - One is to minimize current leakage from pins and thus save power,
>> - second, we can prevent the IP from driving pins output in an
>> uncontrolled manner, which may happen if the power domain drops the
>> domain regulator.
>>
>> If any of the above pin states are missing in dt, a warning message
>> about the missing state is displayed.
>> If certain pin-states are not available, to remove this warning message
>> pass respective state name with null phandler.
>>
>> Signed-off-by: Hebbar Gururaja 
>> Cc: Balaji T K 
>> Cc: Chris Ball 
>> Cc: linux-...@vger.kernel.org
>> Cc: linux-o...@vger.kernel.org
>
> This is perfectly correct.
> Acked-by: Linus Walleij 

So please consider my other option given in patch 2 instead.

Yours,
Linus Walleij
--
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] mfd: DT bindings for the palmas family MFD

[Lee Jones]

On Mon, 03 Jun 2013, Stephen Warren wrote:

> On 06/03/2013 08:18 AM, Lee Jones wrote:
> > On Mon, 03 Jun 2013, J Keerthy wrote:
> >> Add the various binding files for the palmas family of chips. There is a
> >> top level MFD binding then a seperate binding for regulators IP blocks on 
> >> chips.
> 
> >> diff --git a/Documentation/devicetree/bindings/mfd/palmas.txt 
> >> b/Documentation/devicetree/bindings/mfd/palmas.txt
> 
> >> +Example:
> >> +
> >> +palmas {
> > 
> > Should this be 'palmas@48 {', as it has an address?
> 
> It's common to only include the unit-address (@48) if it's needed to
> make the node name unique (i.e. if you had multiple palmas devices).

I was working on the basis of, if it has a 'reg' value, it should be
highlighted in the node name, but if this is the common way of doing
things then fair enough.

> >> diff --git a/Documentation/devicetree/bindings/regulator/palmas-pmic.txt 
> >> b/Documentation/devicetree/bindings/regulator/palmas-pmic.txt
> 
> > See: Documentation/devicetree/bindings/regulator/gpio-regulator.txt
> > 
> >> + ti,sleep-mode - mode to adopt in pmic sleep 0 - off, 1 - auto,
> >> + 2 - eco, 3 - forced pwm
> > 
> > I've seen lots of sleep-mode properties, can't we define a generic
> > one?
> 
> Isn't it HW-specific?

Yes, they're not all identical. I haven't studied them all in detail,
but I assumed a we would be able to do something in order to
consolidate them somewhat. If they are vastly different then no
problem, it was just an idea to cut down on vendor specific
properties. 

-- 
Lee Jones
Linaro ST-Ericsson Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
--
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/

Handling NUMA page migration

[Frank Mehnert]

Hi,

our memory management on Linux hosts conflicts with NUMA page migration.
I assume this problem existed for a longer time but Linux 3.8 introduced
automatic NUMA page balancing which makes the problem visible on
multi-node hosts leading to kernel oopses.

NUMA page migration means that the physical address of a page changes.
This is fatal if the application assumes that this never happens for
that page as it was supposed to be pinned.

We have two kind of pinned memory:

A) 1. allocate memory in userland with mmap()
   2. madvise(MADV_DONTFORK)
   3. pin with get_user_pages().
   4. flush dcache_page()
   5. vm_flags |= (VM_DONTCOPY | VM_LOCKED)
  (resulting flags are VM_MIXEDMAP | VM_DONTDUMP | VM_DONTEXPAND |
   VM_DONTCOPY | VM_LOCKED | 0xff)

B) 1. allocate memory with alloc_pages()
   2. SetPageReserved()
   3. vm_mmap() to allocate a userspace mapping
   4. vm_insert_page()
   5. vm_flags |= (VM_DONTEXPAND | VM_DONTDUMP)
  (resulting flags are VM_MIXEDMAP | VM_DONTDUMP | VM_DONTEXPAND | 0xff)

At least the memory allocated like B) is affected by automatic NUMA page
migration. I'm not sure about A).

1. How can I prevent automatic NUMA page migration on this memory?
2. Can NUMA page migration also be handled on such kind of memory without
   preventing migration?

Thanks,

Frank
-- 
Dr.-Ing. Frank Mehnert | Software Development Director, VirtualBox
ORACLE Deutschland B.V. & Co. KG | Werkstr. 24 | 71384 Weinstadt, Germany

Hauptverwaltung: Riesstr. 25, D-80992 München
Registergericht: Amtsgericht München, HRA 95603
Geschäftsführer: Jürgen Kunz

Komplementärin: ORACLE Deutschland Verwaltung B.V.
Hertogswetering 163/167, 3543 AS Utrecht, Niederlande
Handelsregister der Handelskammer Midden-Niederlande, Nr. 30143697
Geschäftsführer: Alexander van der Ven, Astrid Kepper, Val Maher
--
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] mfd: replace strict_strtoul() with kstrtoul()

[Lee Jones]

On Tue, 04 Jun 2013, Jingoo Han wrote:

> The usage of strict_strtoul() is not preferred, because
> strict_strtoul() is obsolete. Thus, kstrtoul() should be
> used.
> 
> Signed-off-by: Jingoo Han 
> Reviewed-by: Andy Shevchenko 
> ---
> Changes since v1:
> - Removed redundant variables 'u8 reg'.
> - Changed the type of 'user_value' from 'unsigned long' to 'u8'.
> - Replaced kstrtoul() with kstrtou8() to handle u8 variable.
> - Added Andy Shevchenko's Reviewed-by.
> 
> Changes since v1:
> - Used return code from kstrtoul().
> - Changed the type of 'user_reg' from 'unsigned long' to 'u8'.
> - Replaced kstrtoul() with kstrtou8() to handle u8 variable.
> 
>  drivers/mfd/aat2870-core.c   |5 +++--
>  drivers/mfd/ab3100-core.c|   28 ++--
>  drivers/mfd/ab8500-debugfs.c |2 +-
>  3 files changed, 14 insertions(+), 21 deletions(-)

Applied.

If Andy has any further comments, I'll replace the applied version
with any v3 patch which you send.

-- 
Lee Jones
Linaro ST-Ericsson Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
--
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/3] sched: don't repeat the initialization in sched_init()

[Michael Wang]

Hi, Paul

On 06/04/2013 02:52 PM, Paul Turner wrote:
> On Mon, Jun 3, 2013 at 11:23 PM, Michael Wang

[snip]

> 
> This comment has become unglued from what it's supposed to be attached
> to (it's tied to root_task_group.shares & init_tg_cfs_entry, not
> init_cfs_bandwidth).

Thanks for your review and notify :)

What about put the comment with init_tg_cfs_entry()?

'root_task_group.shares' may not needed to be covered under the comment,
after all, it won't have any peers to flaunt it's share...

Regards,
Michael Wang

> 
>> +   init_cfs_bandwidth(&root_task_group.cfs_bandwidth);
>> +#endif
>> +
>> for_each_possible_cpu(i) {
>> struct rq *rq;
>>
>> @@ -6966,28 +6991,7 @@ void __init sched_init(void)
>> init_cfs_rq(&rq->cfs);
>> init_rt_rq(&rq->rt, rq);
>>  #ifdef CONFIG_FAIR_GROUP_SCHED
>> -   root_task_group.shares = ROOT_TASK_GROUP_LOAD;
>> INIT_LIST_HEAD(&rq->leaf_cfs_rq_list);
>> -   /*
>> -* How much cpu bandwidth does root_task_group get?
>> -*
>> -* In case of task-groups formed thr' the cgroup filesystem, 
>> it
>> -* gets 100% of the cpu resources in the system. This overall
>> -* system cpu resource is divided among the tasks of
>> -* root_task_group and its child task-groups in a fair 
>> manner,
>> -* based on each entity's (task or task-group's) weight
>> -* (se->load.weight).
>> -*
>> -* In other words, if root_task_group has 10 tasks of weight
>> -* 1024) and two child groups A0 and A1 (of weight 1024 
>> each),
>> -* then A0's share of the cpu resource is:
>> -*
>> -*  A0's bandwidth = 1024 / (10*1024 + 1024 + 1024) = 
>> 8.33%
>> -*
>> -* We achieve this by letting root_task_group's tasks sit
>> -* directly in rq->cfs (i.e root_task_group->se[] = NULL).
>> -*/
>> -   init_cfs_bandwidth(&root_task_group.cfs_bandwidth);
>> init_tg_cfs_entry(&root_task_group, &rq->cfs, NULL, i, NULL);
>>  #endif /* CONFIG_FAIR_GROUP_SCHED */
>>
>> --
>> 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/
> 

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

Re: [PATCH RFC V9 19/19] kvm hypervisor: Add directed yield in vcpu block path

[Raghavendra K T]

On 06/03/2013 09:35 PM, Konrad Rzeszutek Wilk wrote:

On Sun, Jun 02, 2013 at 12:56:45AM +0530, Raghavendra K T wrote:

kvm hypervisor: Add directed yield in vcpu block path

From: Raghavendra K T 

We use the improved PLE handler logic in vcpu block patch for
scheduling rather than plain schedule, so that we can make
intelligent decisions


You are missing '.' there, and



Yep.



Signed-off-by: Raghavendra K T 
---
  arch/ia64/include/asm/kvm_host.h|5 +
  arch/powerpc/include/asm/kvm_host.h |5 +
  arch/s390/include/asm/kvm_host.h|5 +
  arch/x86/include/asm/kvm_host.h |2 +-
  arch/x86/kvm/x86.c  |8 
  include/linux/kvm_host.h|2 +-
  virt/kvm/kvm_main.c |6 --
  7 files changed, 29 insertions(+), 4 deletions(-)

diff --git a/arch/ia64/include/asm/kvm_host.h b/arch/ia64/include/asm/kvm_host.h
index 989dd3f..999ab15 100644
--- a/arch/ia64/include/asm/kvm_host.h
+++ b/arch/ia64/include/asm/kvm_host.h
@@ -595,6 +595,11 @@ int kvm_emulate_halt(struct kvm_vcpu *vcpu);
  int kvm_pal_emul(struct kvm_vcpu *vcpu, struct kvm_run *kvm_run);
  void kvm_sal_emul(struct kvm_vcpu *vcpu);

+static inline void kvm_do_schedule(struct kvm_vcpu *vcpu)
+{
+   schedule();
+}
+
  #define __KVM_HAVE_ARCH_VM_ALLOC 1
  struct kvm *kvm_arch_alloc_vm(void);
  void kvm_arch_free_vm(struct kvm *kvm);
diff --git a/arch/powerpc/include/asm/kvm_host.h 
b/arch/powerpc/include/asm/kvm_host.h
index af326cd..1aeecc0 100644
--- a/arch/powerpc/include/asm/kvm_host.h
+++ b/arch/powerpc/include/asm/kvm_host.h
@@ -628,4 +628,9 @@ struct kvm_vcpu_arch {
  #define __KVM_HAVE_ARCH_WQP
  #define __KVM_HAVE_CREATE_DEVICE

+static inline void kvm_do_schedule(struct kvm_vcpu *vcpu)
+{
+   schedule();
+}
+
  #endif /* __POWERPC_KVM_HOST_H__ */
diff --git a/arch/s390/include/asm/kvm_host.h b/arch/s390/include/asm/kvm_host.h
index 16bd5d1..db09a56 100644
--- a/arch/s390/include/asm/kvm_host.h
+++ b/arch/s390/include/asm/kvm_host.h
@@ -266,4 +266,9 @@ struct kvm_arch{
  };

  extern int sie64a(struct kvm_s390_sie_block *, u64 *);
+static inline void kvm_do_schedule(struct kvm_vcpu *vcpu)
+{
+   schedule();
+}
+
  #endif
diff --git a/arch/x86/include/asm/kvm_host.h b/arch/x86/include/asm/kvm_host.h
index 95702de..72ff791 100644
--- a/arch/x86/include/asm/kvm_host.h
+++ b/arch/x86/include/asm/kvm_host.h
@@ -1042,5 +1042,5 @@ int kvm_pmu_set_msr(struct kvm_vcpu *vcpu, struct 
msr_data *msr_info);
  int kvm_pmu_read_pmc(struct kvm_vcpu *vcpu, unsigned pmc, u64 *data);
  void kvm_handle_pmu_event(struct kvm_vcpu *vcpu);
  void kvm_deliver_pmi(struct kvm_vcpu *vcpu);
-
+void kvm_do_schedule(struct kvm_vcpu *vcpu);
  #endif /* _ASM_X86_KVM_HOST_H */
diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c
index b963c86..d26c4be 100644
--- a/arch/x86/kvm/x86.c
+++ b/arch/x86/kvm/x86.c
@@ -7281,6 +7281,14 @@ bool kvm_arch_can_inject_async_page_present(struct 
kvm_vcpu *vcpu)
kvm_x86_ops->interrupt_allowed(vcpu);
  }

+void kvm_do_schedule(struct kvm_vcpu *vcpu)
+{
+   /* We try to yield to a kikced vcpu else do a schedule */


s/kikced/kicked/


:(.  Thanks .. will change that.




[...]

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

Re: [PATCH 11/11] i2c: omap: enhance pinctrl support

[Linus Walleij]

On Fri, May 31, 2013 at 8:07 PM, Kevin Hilman  wrote:

> But that brings up a bigger question about whether or not we should be
> doing the rest of this (idle/sleep) pin management in the drivers or in
> the driver core as well.  I would much prefer it be handled by the
> driver core.

Yes. See my suggestion in 2/11.

> In fact, since these are all PM related events, it should probably be
> handled by the PM core and seems pretty straight forward to do so.

I can see a clean interface with three simple functions toward
 for switching between the default, idle and
sleep states, but you may see even further...

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

Re: [PATCH 00/11] drivers: Add Pinctrl PM support

[Linus Walleij]

On Fri, May 31, 2013 at 7:04 PM, Dmitry Torokhov
 wrote:

> As with the original introduction of pinctrl states my question is: "Can
> all of this be handled in the driver/bus core instead of adding a lot
> of boilerplate code to the individual drivers".

It can. Per the suggestion in 2/11:

- Adding pins_sleep and pins_idle to struct dev_pin_info
  in include/linux/pinctrl/devinfo.h

- Modify drivers/base/pinctrl.c to optionally look up
  sleep and idle states, you can make that code
  #ifdef CONFIG_PM I think.

- Add something like static inline functions to
  include/linux/pinctrl/consumer.h
  with names like pinctrl_select_pm_idle(struct device *)
  pinctrl_select_pm_sleep(struct device *) to switch states
  using the device core containers, and includes
  checking IS_ERR() on the handles etc.

I think this will save a *lot* of identical code in all the
drivers, that will just have to call
pinctrl_select_pm_sleep(), pinctrl_select_pm_default()
pinctrl_select_pm_idle() instead of all the complex code.

This is what I planned to do but never got around to.

Yours,
Linus Walleij
--
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] dmatest: add ability to disable pq and xor

[Andy Shevchenko]

On Tue, Jun 4, 2013 at 2:29 AM, Jon Mason  wrote:
> On Fri, May 31, 2013 at 11:22:10AM +0300, Andy Shevchenko wrote:
>> On Fri, May 17, 2013 at 8:54 PM, Jon Mason  wrote:
>> > dmatest would create a thread to stress XOR and PQ, if the capability is
>> > present in the hardware.  Add the ability to disable XOR and PQ by
>> > disabling it if *_sources are set to zero.
>>
>> Sorry, didn't comment this earlier.
>>
>> Those threads are independent including MEMCPY stuff.
>> I think it's better to have one additional parameter let's say
>> type_of_test where you can set
>> 1 for MEMCPY
>> 2 for XOR
>> 4 for PQ
>>
>> Share this parameter via debugfs and use 0x07 as default value.
>> I doubt we need this as a module parameter.
>
> This is using the existing module parameter, so there is nothing new
> added.

That's why it's a bit confusing. User can more easily forget the
'magic' numbers. And I see no reason to prevent user to enter 0 as a
number of sources.
Moreover, your patch doesn't cover the case when user doesn't want to
run MEMCPY thread.

>  Since the testing is started immediately upon module
> insertion,

It used to be so, but nowadays it's true only when dmatest is compiled in.
If someone wants to compile in that module they probably want to run
stress tests, where XOR and PQ might be useful.

> there needs to be a way to prevent it from ever starting.

My opinion I already shared, new node under debugfs. There is might be
a good reason to add a new module parameter as well.

--
With Best Regards,
Andy Shevchenko
--
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] clean up scary strncpy(dst, src, strlen(src)) uses

[Ursula Braun]

On Friday, May 31, 2013 09:18:07 AM Kees Cook wrote:
> Fix various weird constructions of strncpy(dst, src, strlen(src)).
> Length
> limits should be about the space available in the destination, not
> repurposed as a method to either always include or always exclude
> a trailing NULL byte. Either the NULL should always be copied
> (using strlcpy), or it should not be copied (using something like
> memcpy). Readable code should not depend on the weird behavior of
> strncpy
> when it hits the length limit. Better to avoid the anti-pattern
> entirely.
> 
> Signed-off-by: Kees Cook 

For the s390-part:

Acked-by: Ursula Braun 

> ---
> This is a follow-up to the anti-pattern being fixed in iscsi-target,
> which was exploitable:
> "iscsi-target: fix heap buffer overflow on error"
> http://git.kernel.org/cgit/linux/kernel/git/nab/target-pending.git/commit/?id=cea4dcfdad926a27a18e188720efe0f2c9403456
> ---
> Documentation/accounting/getdelays.c |3 ++-
> drivers/acpi/sysfs.c |3 +--
> drivers/s390/net/qeth_l3_sys.c   |6 ++
> drivers/staging/tidspbridge/rmgr/drv_interface.c |3 +--
> fs/hppfs/hppfs.c |   11 ++-
> 5 files changed, 12 insertions(+), 14 deletions(-)
> 
> diff --git a/Documentation/accounting/getdelays.c
> b/Documentation/accounting/getdelays.c
> index f8ebcde..5e4773d 100644
> --- a/Documentation/accounting/getdelays.c
> +++ b/Documentation/accounting/getdelays.c
> @@ -23,6 +23,7 @@
> #include 
> #include 
> #include 
> +#include 
> 
> #include 
> #include 
> @@ -299,7 +300,7 @@ int main(int argc, char *argv[])
>break;
>   case 'C':
>containerset = 1;
> -
> strncpy(containerpath, optarg, strlen(optarg) + 1);
> +
> strlcpy(containerpath, optarg, sizeof(containerpath));
>break;
>   case 'w':
>logfile =
> strdup(optarg);
> diff --git a/drivers/acpi/sysfs.c b/drivers/acpi/sysfs.c
> index fcae5fa..193745d 100644
> --- a/drivers/acpi/sysfs.c
> +++ b/drivers/acpi/sysfs.c
> @@ -677,10 +677,9 @@ void acpi_irq_stats_init(void)
>   else
>sprintf(buffer,
> "bug%02X", i);
> 
> -  name = kzalloc(strlen(buffer) + 1,
> GFP_KERNEL);
> +  name = kstrdup(buffer, GFP_KERNEL);
>   if (name == NULL)
>goto fail;
> -  strncpy(name, buffer,
> strlen(buffer) + 1);
> 
> 
> sysfs_attr_init(&counter_attrs[i].attr);
>   counter_attrs[i].attr.name = name;
> diff --git a/drivers/s390/net/qeth_l3_sys.c
> b/drivers/s390/net/qeth_l3_sys.c
> index e70af24..d1c8025 100644
> --- a/drivers/s390/net/qeth_l3_sys.c
> +++ b/drivers/s390/net/qeth_l3_sys.c
> @@ -315,10 +315,8 @@ static ssize_t qeth_l3_dev_hsuid_store(struct
> device *dev,
>  if (qeth_configure_cq(card, QETH_CQ_ENABLED))
>   return -EPERM;
> 
> - for (i = 0; i < 8; i++)
> -  card->options.hsuid[i] = ' ';
> - card->options.hsuid[8] = '\0';
> - strncpy(card->options.hsuid, tmp, strlen(tmp));
> + snprintf(card->options.hsuid,
> sizeof(card->options.hsuid),
> +   "%-8s", tmp);
>  ASCEBC(card->options.hsuid, 8);
>  if (card->dev)
>   memcpy(card->dev->perm_addr,
> card->options.hsuid, 9);
> diff --git a/drivers/staging/tidspbridge/rmgr/drv_interface.c
> b/drivers/staging/tidspbridge/rmgr/drv_interface.c
> index df0f37e..c4d632c 100644
> --- a/drivers/staging/tidspbridge/rmgr/drv_interface.c
> +++ b/drivers/staging/tidspbridge/rmgr/drv_interface.c
> @@ -421,12 +421,11 @@ static int omap3_bridge_startup(struct
> platform_device *pdev)
>  drv_datap->tc_wordswapon = tc_wordswapon;
> 
>  if (base_img) {
> -  drv_datap->base_img =
> kmalloc(strlen(base_img) + 1, GFP_KERNEL);
> +  drv_datap->base_img =
> kstrdup(base_img, GFP_KERNEL);
>   if (!drv_datap->base_img) {
>err = -ENOMEM;
>goto err2;
>   }
> -  strncpy(drv_datap->base_img,
> base_img, strlen(base_img) + 1);
>  }
> 
>  dev_set_drvdata(bridge, drv_datap);
> diff --git a/fs/hppfs/hppfs.c b/fs/hppfs/hppfs.c
>

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

[Stephen Rothwell]

Hi all,

After merging the final tree, today's linux-next build (i386_defconfig,
sparc64_defconfig) produced this warning:

net/ipv6/ping.c: In function 'pingv6_init':
net/ipv6/ping.c:87:27: warning: assignment from incompatible pointer type 
[enabled by default]

Probably caused by commit 2a7851bffb00 ("netfilter: add nf_ipv6_ops hook
to fix xt_addrtype with IPv6") interacting with commit 6d0bfe226116
("net: ipv6: Add IPv6 support to the ping socket") from the net-next tree.
-- 
Cheers,
Stephen Rothwells...@canb.auug.org.au


pgpmTzM4CtQO6.pgp
Description: PGP signature

Re: [PATCH 1/1] kernel:time Export symbols of functions declared in linux/alarmtimer.h

[Marcus Gelderie]

On Mon, Jun 03, 2013 at 12:21:22PM -0700, John Stultz wrote:
> These probably should be EXPORT_SYMBOL_GPL, no? Also there's a bunch of 
> new alarm functions that Todd Poynor that I have queued, which will 
> probably need similar.
> 
> thanks
> -john
Opps, yes they should, thanks. I've corrected that. 

Your new alarm functions are not in the tree yet, are they? At least I didn't
find them.

cheers
Marcus

New patch below
-

Export symbols so they can be used by
drivers/staging/android/alarm-dev.c. So far this is built-in but LKM
support is planned (see drivers/staging/android/TODO).

Signed-off-by: Marcus Gelderie 
---
 kernel/time/alarmtimer.c | 5 +
 1 file changed, 5 insertions(+)

diff --git a/kernel/time/alarmtimer.c b/kernel/time/alarmtimer.c
index f11d83b..1e7d514 100644
--- a/kernel/time/alarmtimer.c
+++ b/kernel/time/alarmtimer.c
@@ -303,6 +303,7 @@ void alarm_init(struct alarm *alarm, enum alarmtimer_type 
type,
alarm->type = type;
alarm->state = ALARMTIMER_STATE_INACTIVE;
 }
+EXPORT_SYMBOL_GPL(alarm_init);
 
 /**
  * alarm_start - Sets an alarm to fire
@@ -323,6 +324,7 @@ int alarm_start(struct alarm *alarm, ktime_t start)
spin_unlock_irqrestore(&base->lock, flags);
return ret;
 }
+EXPORT_SYMBOL_GPL(alarm_start);
 
 /**
  * alarm_try_to_cancel - Tries to cancel an alarm timer
@@ -344,6 +346,7 @@ int alarm_try_to_cancel(struct alarm *alarm)
spin_unlock_irqrestore(&base->lock, flags);
return ret;
 }
+EXPORT_SYMBOL_GPL(alarm_try_to_cancel);
 
 
 /**
@@ -361,6 +364,7 @@ int alarm_cancel(struct alarm *alarm)
cpu_relax();
}
 }
+EXPORT_SYMBOL_GPL(alarm_cancel);
 
 
 u64 alarm_forward(struct alarm *alarm, ktime_t now, ktime_t interval)
@@ -393,6 +397,7 @@ u64 alarm_forward(struct alarm *alarm, ktime_t now, ktime_t 
interval)
alarm->node.expires = ktime_add(alarm->node.expires, interval);
return overrun;
 }
+EXPORT_SYMBOL_GPL(alarm_forward);
 
 
 
-- 
1.8.1.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: [PATCHv2 2/2] mfd: ssbi: Use devm_* and simplify code

[Lee Jones]

On Mon, 03 Jun 2013, Stephen Boyd wrote:

> Use devm_ioremap_resource and devm_kzalloc to simplify error
> paths and reduce lines of code. Also use dev_err() to keep
> consistency and drop the .remove function because the devm
> functions take care of what it's doing besides the now obsolete
> platform_set_drvdata() which we can just drop. Finally, use
> module_platform_driver() to save some more lines.
> 
> Cc: David Brown 
> Signed-off-by: Stephen Boyd 
> ---

Really nice.

Acked-by: Lee Jones 

-- 
Lee Jones
Linaro ST-Ericsson Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
--
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] sched: Rename sched.c as sched/core.c in comments and Documentation

[Viresh Kumar]

Most of the stuff from kernel/sched.c was moved to kernel/sched/core.c long time
back and the comments/Documentation never got updated.

I figured it out when I was going through sched-domains.txt and so thought of
fixing it globally.

I haven't crossed check if the stuff that is referenced in sched/core.c by all
these files is still present and hasn't changed as that wasn't the motive behind
this patch.

Signed-off-by: Viresh Kumar 
---
 Documentation/cgroups/cpusets.txt | 2 +-
 Documentation/rt-mutex-design.txt | 2 +-
 Documentation/scheduler/sched-domains.txt | 4 ++--
 Documentation/spinlocks.txt   | 2 +-
 Documentation/virtual/uml/UserModeLinux-HOWTO.txt | 4 ++--
 arch/avr32/kernel/process.c   | 2 +-
 arch/cris/include/arch-v10/arch/bitops.h  | 2 +-
 arch/ia64/kernel/head.S   | 2 +-
 arch/mips/kernel/mips-mt-fpaff.c  | 4 ++--
 arch/mips/kernel/scall32-o32.S| 5 +++--
 arch/powerpc/include/asm/mmu_context.h| 2 +-
 arch/tile/include/asm/processor.h | 2 +-
 arch/tile/kernel/stack.c  | 2 +-
 arch/um/kernel/sysrq.c| 2 +-
 include/linux/completion.h| 2 +-
 include/linux/perf_event.h| 2 +-
 include/linux/spinlock_up.h   | 2 +-
 include/uapi/asm-generic/unistd.h | 2 +-
 kernel/cpuset.c   | 4 ++--
 kernel/time.c | 2 +-
 kernel/workqueue_internal.h   | 2 +-
 21 files changed, 27 insertions(+), 26 deletions(-)

diff --git a/Documentation/cgroups/cpusets.txt 
b/Documentation/cgroups/cpusets.txt
index 12e01d4..7740038 100644
--- a/Documentation/cgroups/cpusets.txt
+++ b/Documentation/cgroups/cpusets.txt
@@ -373,7 +373,7 @@ can become very uneven.
 1.7 What is sched_load_balance ?
 
 
-The kernel scheduler (kernel/sched.c) automatically load balances
+The kernel scheduler (kernel/sched/core.c) automatically load balances
 tasks.  If one CPU is underutilized, kernel code running on that
 CPU will look for tasks on other more overloaded CPUs and move those
 tasks to itself, within the constraints of such placement mechanisms
diff --git a/Documentation/rt-mutex-design.txt 
b/Documentation/rt-mutex-design.txt
index 33ed800..a5bcd7f 100644
--- a/Documentation/rt-mutex-design.txt
+++ b/Documentation/rt-mutex-design.txt
@@ -384,7 +384,7 @@ priority back.
 __rt_mutex_adjust_prio examines the result of rt_mutex_getprio, and if the
 result does not equal the task's current priority, then rt_mutex_setprio
 is called to adjust the priority of the task to the new priority.
-Note that rt_mutex_setprio is defined in kernel/sched.c to implement the
+Note that rt_mutex_setprio is defined in kernel/sched/core.c to implement the
 actual change in priority.
 
 It is interesting to note that __rt_mutex_adjust_prio can either increase
diff --git a/Documentation/scheduler/sched-domains.txt 
b/Documentation/scheduler/sched-domains.txt
index 443f0c7..4af80b1 100644
--- a/Documentation/scheduler/sched-domains.txt
+++ b/Documentation/scheduler/sched-domains.txt
@@ -25,7 +25,7 @@ is treated as one entity. The load of a group is defined as 
the sum of the
 load of each of its member CPUs, and only when the load of a group becomes
 out of balance are tasks moved between groups.
 
-In kernel/sched.c, trigger_load_balance() is run periodically on each CPU
+In kernel/sched/core.c, trigger_load_balance() is run periodically on each CPU
 through scheduler_tick(). It raises a softirq after the next regularly 
scheduled
 rebalancing event for the current runqueue has arrived. The actual load
 balancing workhorse, run_rebalance_domains()->rebalance_domains(), is then run
@@ -62,7 +62,7 @@ struct sched_domain fields, SD_FLAG_*, SD_*_INIT to get an 
idea of
 the specifics and what to tune.
 
 Architectures may retain the regular override the default SD_*_INIT flags
-while using the generic domain builder in kernel/sched.c if they wish to
+while using the generic domain builder in kernel/sched/core.c if they wish to
 retain the traditional SMT->SMP->NUMA topology (or some subset of that). This
 can be done by #define'ing ARCH_HASH_SCHED_TUNE.
 
diff --git a/Documentation/spinlocks.txt b/Documentation/spinlocks.txt
index 9dbe885..97eaf57 100644
--- a/Documentation/spinlocks.txt
+++ b/Documentation/spinlocks.txt
@@ -137,7 +137,7 @@ don't block on each other (and thus there is no dead-lock 
wrt interrupts.
 But when you do the write-lock, you have to use the irq-safe version. 
 
 For an example of being clever with rw-locks, see the "waitqueue_lock" 
-handling in kernel/sched.c - nothing ever _changes_ a wait-queue from
+handling in kernel/sched/core.c - nothing ever _changes_ a wait-queue from
 within an interrupt, they only read the q

linux-next: Tree for Jun 4

[Stephen Rothwell]

Hi all,

Changes since 20130603:

The pci tree gained a conflict against Linus' tree.

The wireless-next tree gained conflicts against the net and net-next trees.

The staging tree gained a build failure so I disabled a driver.

The msm tree still has its build failure for which I applied a fix patch.

The akpm tree gained a conflict against the percpu tree that caused me to
drop several patches.



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.

-- 
Stephen Rothwell 


pgpmc4IdgbyRG.pgp
Description: PGP signature

[GIT PULL] arch/microblaze fixes for 3.10-rc5

[Michal Simek]

Hi Linus,

please pull these two fixes to your tree.
One is fixing warning reported by sparse and the second warning
was reported by Geert in his build regressions/improvements status update
for -rc4.

Thanks,
Michal

The following changes since commit d683b96b072dc4680fc74964eca77e6a23d1fa6e:

  Linux 3.10-rc4 (2013-06-02 17:11:17 +0900)

are available in the git repository at:

  git://git.monstr.eu/linux-2.6-microblaze.git next

for you to fetch changes up to 62bc82a82bb1e2b5ee5048c088af7260ddb2b7b5:

  microblaze: Use static inline functions in cacheflush.h (2013-06-03 11:33:23 
+0200)


Michal Simek (2):
  microblaze: Fix sparse warnings
  microblaze: Use static inline functions in cacheflush.h

 arch/microblaze/include/asm/cacheflush.h | 34 
++
 arch/microblaze/include/asm/uaccess.h|  4 ++--
 2 files changed, 20 insertions(+), 18 deletions(-)


-- 
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 v2 1/3] PCI/AER: Fix incorrect return from aer_hest_parse()

[Chen Gong]

On Thu, May 30, 2013 at 08:39:27AM -0600, Betty Dall wrote:
> Date: Thu, 30 May 2013 08:39:27 -0600
> From: Betty Dall 
> To: r...@sisk.pl, bhelg...@google.com
> Cc: ying.hu...@intel.com, linux-a...@vger.kernel.org,
>  linux-kernel@vger.kernel.org, linux-...@vger.kernel.org, Betty Dall
>  
> Subject: [PATCH v2 1/3] PCI/AER: Fix incorrect return from aer_hest_parse()
> X-Mailer: git-send-email 1.7.7.6
> 
> The function aer_hest_parse() is called to determine if the given
> PCI device is firmware first or not. The code loops through each
> section of the HEST table to look for a match. The bug is that
> the function always returns whether the last HEST section is firmware
> first. The fix stops the iteration once the info.firmware_first
> variable is set.  This is similar to how the function aer_hest_parse_aff()
> stops the iteration.
> 
> Signed-off-by: Betty Dall 

The patch is good. But I have further concern based on your patch.
1) aer_hest_parse never checks the 2nd input parameter (void *data),
which means once it is NULL, it will crash the kernel.

2) both aer_hest_parse and aer_hest_parse_aff utilize some flag
as shortcut, if so, why not adding similar logic in apei_hest_parse
to stop meaningless loops once FFM is confirmed as enabled.

> ---
> 
>  drivers/pci/pcie/aer/aerdrv_acpi.c |3 +++
>  1 files changed, 3 insertions(+), 0 deletions(-)
> 
> 
> diff --git a/drivers/pci/pcie/aer/aerdrv_acpi.c 
> b/drivers/pci/pcie/aer/aerdrv_acpi.c
> index 5194a7d..39b8671 100644
> --- a/drivers/pci/pcie/aer/aerdrv_acpi.c
> +++ b/drivers/pci/pcie/aer/aerdrv_acpi.c
> @@ -42,6 +42,9 @@ static int aer_hest_parse(struct acpi_hest_header 
> *hest_hdr, void *data)
>   u8 bridge = 0;
>   int ff = 0;
>  
> + if (info->firmware_first)
> + return 0;
> +
>   switch (hest_hdr->type) {
>   case ACPI_HEST_TYPE_AER_ROOT_PORT:
>   pcie_type = PCI_EXP_TYPE_ROOT_PORT;
> --
> To unsubscribe from this list: send the line "unsubscribe linux-acpi" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html


signature.asc
Description: Digital signature

Re: [PATCH] net/macb: fix ISR clear-on-write behavior only for some SoC

[Nicolas Ferre]

On 04/06/2013 08:49, Steffen Trumtrar :

On Tue, Jun 04, 2013 at 08:15:45AM +0200, Michal Simek wrote:

On 05/14/2013 07:52 AM, Jean-Christophe PLAGNIOL-VILLARD wrote:

On 08:58 Tue 14 May , Hein Tibosch wrote:

On 5/14/2013 12:05 AM, Jean-Christophe PLAGNIOL-VILLARD wrote:

On May 14, 2013, at 12:05 AM, Nicolas Ferre  wrote:


Commit 749a2b6 (net/macb: clear tx/rx completion flags in ISR)
introduces clear-on-write on ISR register. This behavior is not always
implemented when using Cadence MACB/GEM and is breaking other platforms.
We are using a new Device Tree compatibility string and a capability
property to actually activate this clear-on-write behavior on ISR.

Reported-by: Hein Tibosch 
Signed-off-by: Nicolas Ferre 

can we detect it via the IP?


This was my first proposal, have it based on the value of MACB's
register 'MID' (offset 0x00fc, lower 16 bits).
On avr32 it reads: 0x010D, on Zynq it reports 0x0119

So for the moment, CAPS_ISR_CLEAR_ON_WRITE could be set if the revision
equals to 0x0119?

so no it will not work

as the gem on sama5 is 00020119

so version 0x119 too

nico
Acked-by: Jean-Christophe PLAGNIOL-VILLARD 


Was this added to any queue or branch?
I would like to enable macb for zynq and not sure if "cdns,zynq-7000-gem"
compatible string goes to mainline.



Hi!

This is already in next, but you can use the default compatible as the


Even more: already in Linus' tree!


DCR1 is used instead of DT binding.


Absolutely.

Best regards,
--
Nicolas Ferre
--
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/macb: fix ISR clear-on-write behavior only for some SoC

[Michal Simek]

On 06/04/2013 09:51 AM, Nicolas Ferre wrote:
> On 04/06/2013 08:49, Steffen Trumtrar :
>> On Tue, Jun 04, 2013 at 08:15:45AM +0200, Michal Simek wrote:
>>> On 05/14/2013 07:52 AM, Jean-Christophe PLAGNIOL-VILLARD wrote:
 On 08:58 Tue 14 May , Hein Tibosch wrote:
> On 5/14/2013 12:05 AM, Jean-Christophe PLAGNIOL-VILLARD wrote:
>> On May 14, 2013, at 12:05 AM, Nicolas Ferre  
>> wrote:
>>
>>> Commit 749a2b6 (net/macb: clear tx/rx completion flags in ISR)
>>> introduces clear-on-write on ISR register. This behavior is not always
>>> implemented when using Cadence MACB/GEM and is breaking other platforms.
>>> We are using a new Device Tree compatibility string and a capability
>>> property to actually activate this clear-on-write behavior on ISR.
>>>
>>> Reported-by: Hein Tibosch 
>>> Signed-off-by: Nicolas Ferre 
>> can we detect it via the IP?
>
> This was my first proposal, have it based on the value of MACB's
> register 'MID' (offset 0x00fc, lower 16 bits).
> On avr32 it reads: 0x010D, on Zynq it reports 0x0119
>
> So for the moment, CAPS_ISR_CLEAR_ON_WRITE could be set if the revision
> equals to 0x0119?
 so no it will not work

 as the gem on sama5 is 00020119

 so version 0x119 too

 nico
 Acked-by: Jean-Christophe PLAGNIOL-VILLARD 
>>>
>>> Was this added to any queue or branch?
>>> I would like to enable macb for zynq and not sure if "cdns,zynq-7000-gem"
>>> compatible string goes to mainline.
>>>
>>
>> Hi!
>>
>> This is already in next, but you can use the default compatible as the
> 
> Even more: already in Linus' tree!

Ah I see. v2 is in thunderbird in the same thread and I didn't check this
version for compatible string.

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 3/3] clocksource: dw_apb_timer_of: use clocksource_of_init

[Heiko Stübner]

Am Dienstag, 4. Juni 2013, 06:36:20 schrieb Baruch Siach:
> Hi Heiko,
> 
> On Mon, Jun 03, 2013 at 09:59:55PM +0200, Heiko Stübner wrote:
> > dw_apb_timer_init used to search the devicetree for matching timer
> > devices, making calls to it from board files necessary.
> > 
> > Change the dw_apb_timer_init to work with CLOCKSOURCE_OF_DECLARE.
> > With this change the function gets called once for each timer node
> > and tracks these number of calls to attach clockevent and clocksource
> > devices to the nodes.
> > 
> > Also remove the calls to dw_apb_timer_init from all previous users, as
> > clocksource_of_init is the default for init_time now.
> > 
> > Tested on the upcoming rk3066 code.
> > 
> > Signed-off-by: Heiko Stuebner 
> > Acked-by: Rob Herring 
> > Acked-by: Arnd Bergmann 
> > ---
> > 
> >  arch/arm/mach-picoxcell/Kconfig   |1 +
> >  arch/arm/mach-picoxcell/common.c  |2 -
> >  arch/arm/mach-socfpga/Kconfig |1 +
> >  arch/arm/mach-socfpga/socfpga.c   |2 -
> >  drivers/clocksource/dw_apb_timer_of.c |   41
> >  - include/linux/dw_apb_timer.h 
> >  |1 -
> >  6 files changed, 22 insertions(+), 26 deletions(-)
> > 
> > diff --git a/arch/arm/mach-picoxcell/Kconfig
> > b/arch/arm/mach-picoxcell/Kconfig index 13bae78..3ef6bbe 100644
> > --- a/arch/arm/mach-picoxcell/Kconfig
> > +++ b/arch/arm/mach-picoxcell/Kconfig
> > @@ -6,6 +6,7 @@ config ARCH_PICOXCELL
> > 
> > select CPU_V6K
> > select DW_APB_TIMER
> > select DW_APB_TIMER_OF
> > 
> > +   select CLKSRC_OF
> 
> Shouldn't DW_APB_TIMER 'select CLKSRC_OF if OF' instead of selecting is for
> each and every platform? While at it we can do the same to DW_APB_TIMER_OF.

if anything DW_APB_TIMER_OF should select both DW_APB_TIMER and 'CLKSRC_OF if 
OF', as the base DW_APB_TIMER_OF is the platform glue, that uses DW_APB_TIMER 
internally.

But otherwise sounds sensible to not duplicate these selects everywhere.
--
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] ACPI/APEI: Force fatal AER severity when bus has been reset

[Chen Gong]

On Thu, May 30, 2013 at 08:39:28AM -0600, Betty Dall wrote:
> Date: Thu, 30 May 2013 08:39:28 -0600
> From: Betty Dall 
> To: r...@sisk.pl, bhelg...@google.com
> Cc: ying.hu...@intel.com, linux-a...@vger.kernel.org,
>  linux-kernel@vger.kernel.org, linux-...@vger.kernel.org, Betty Dall
>  
> Subject: [PATCH v2 2/3] ACPI/APEI: Force fatal AER severity when bus has
>  been reset
> X-Mailer: git-send-email 1.7.7.6
> 
> The CPER error record has a reset bit that indicates that the platform
> has reset the bus. The reset bit can be set for any severity error
> including recoverable.  From the AER code path's perspective,
> any error is fatal if the bus has been reset. This patch upgrades the
> severity of the AER recovery to AER_FATAL whenever the CPER error record
> indicates that the bus has been reset.
> 
> Changes since v1:
> Fixed a typo in comment.
> 
> Signed-off-by: Betty Dall 
> ---
> 
>  drivers/acpi/apei/ghes.c |   21 -
>  1 files changed, 20 insertions(+), 1 deletions(-)
> 
> 
> diff --git a/drivers/acpi/apei/ghes.c b/drivers/acpi/apei/ghes.c
> index d668a8a..1c67d5a 100644
> --- a/drivers/acpi/apei/ghes.c
> +++ b/drivers/acpi/apei/ghes.c
> @@ -451,7 +451,26 @@ static void ghes_do_proc(struct ghes *ghes,
>   int aer_severity;
>   devfn = PCI_DEVFN(pcie_err->device_id.device,
> pcie_err->device_id.function);
> - aer_severity = cper_severity_to_aer(sev);
> + /*
> +  * Some Firmware First implementations
> +  * put the device in SBR to contain
> +  * the error. This is indicated by the
> +  * CPER Section Descriptor Flags reset
> +  * bit which means the component must
> +  * be re-initialized or re-enabled
> +  * prior to use. Promoting the AER
> +  * serverity to FATAL will cause the
> +  * AER code to link_reset and allow
> +  * drivers to reprogram their cards.
> +  */
> + if (gdata->flags & CPER_SEC_RESET)
> + aer_severity = cper_severity_to_aer(
> + CPER_SEV_FATAL);
> + else
> + aer_severity =
> + cper_severity_to_aer(sev);
> +
> +

How about this?
if (gdata->flags & CPER_SEC_RESET)
sev = CPER_SEV_FATAL;
cper_severity_to_aer(sev);

>   aer_recover_queue(pcie_err->device_id.segment,
> pcie_err->device_id.bus,
> devfn, aer_severity);
> --
> To unsubscribe from this list: send the line "unsubscribe linux-acpi" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html


signature.asc
Description: Digital signature

[GIT PULL] fuse bugfixes for 3.10-rc5

[Miklos Szeredi]

Hi Linus,

Please pull the following bugfixes for fuse:

  git://git.kernel.org/pub/scm/linux/kernel/git/mszeredi/fuse.git for-linus

One patch fixes an Oops introduced in 3.9 with the readdirplus feature.  The
rest are fixes for async-dio in 3.10.

Thanks,
Miklos

---
Brian Foster (4):
  fuse: allocate for_background dio requests based on io->async state
  fuse: truncate pagecache range on hole punch
  fuse: update inode size and invalidate attributes on fallocate
  fuse: return -EIOCBQUEUED from fuse_direct_IO() for all async requests

Maxim Patlasov (1):
  fuse: fix alignment in short read optimization for async_dio

Miklos Szeredi (1):
  fuse: fix readdirplus Oops in fuse_dentry_revalidate

---
 fs/fuse/dir.c   |   12 +---
 fs/fuse/file.c  |   58 ++-
 fs/fuse/inode.c |7 ---
 3 files changed, 62 insertions(+), 15 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/

Re: linux-next: Tree for May 30

[Stephen Rothwell]

Hi Nicolas,

On Mon, 3 Jun 2013 10:45:15 +0200 Nicolas Ferre  wrote:
>
> Is it possible for you to move the building to the replacement defconfigs:
> at91sam9260_9g20_defconfig
> at91sam9261_9g10_defconfig

Done.

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


pgp_G__qS2WpD.pgp
Description: PGP signature

[PATCH 2/2] xen: remove bm_rld_set of xen_processor_flags

[liguang]

bm_rld_set seems obsolete now

Signed-off-by: liguang 
---
 include/xen/interface/platform.h |1 -
 1 files changed, 0 insertions(+), 1 deletions(-)

diff --git a/include/xen/interface/platform.h b/include/xen/interface/platform.h
index c57d5f6..733 100644
--- a/include/xen/interface/platform.h
+++ b/include/xen/interface/platform.h
@@ -240,7 +240,6 @@ struct xen_processor_flags {
uint32_t bm_check:1;
uint32_t has_cst:1;
uint32_t power_setup_done:1;
-   uint32_t bm_rld_set:1;
 };
 
 struct xen_processor_power {
-- 
1.7.2.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] acpi/processor: remove bm_rld_set of acpi_processor_flags

[liguang]

bm_rld_set seems obsolete now

Signed-off-by: liguang 
---
 include/acpi/processor.h |1 -
 1 files changed, 0 insertions(+), 1 deletions(-)

diff --git a/include/acpi/processor.h b/include/acpi/processor.h
index ea69367..cfec509 100644
--- a/include/acpi/processor.h
+++ b/include/acpi/processor.h
@@ -188,7 +188,6 @@ struct acpi_processor_flags {
u8 bm_check:1;
u8 has_cst:1;
u8 power_setup_done:1;
-   u8 bm_rld_set:1;
u8 need_hotplug_init:1;
 };
 
-- 
1.7.2.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] scsi: Introduce a help function local_time_seconds() to simplify the getting time stamp operation

[Gu Zheng]

ping...

On 05/29/2013 05:33 PM, Gu Zheng wrote:

>>From 4d4caa16f3886ae910ad6dfe13353fc836f546cc Mon Sep 17 00:00:00 2001
> From: Gu Zheng 
> Date: Wed, 29 May 2013 17:34:22 +0900
> Subject: [PATCH] driver/scsi: Introduce a help function local_time_seconds() 
> to simplify the getting time stamp operation
> 
> Signed-off-by: Gu Zheng 
> ---
>  drivers/scsi/3w-9xxx.c |   14 ++
>  drivers/scsi/3w-sas.c  |   14 ++
>  include/scsi/scsi.h|9 +
>  3 files changed, 13 insertions(+), 24 deletions(-)
> 
> diff --git a/drivers/scsi/3w-9xxx.c b/drivers/scsi/3w-9xxx.c
> index 5e1e12c..44b3ea8 100644
> --- a/drivers/scsi/3w-9xxx.c
> +++ b/drivers/scsi/3w-9xxx.c
> @@ -374,8 +374,6 @@ out:
>  /* This function will queue an event */
>  static void twa_aen_queue_event(TW_Device_Extension *tw_dev, 
> TW_Command_Apache_Header *header)
>  {
> - u32 local_time;
> - struct timeval time;
>   TW_Event *event;
>   unsigned short aen;
>   char host[16];
> @@ -398,9 +396,7 @@ static void twa_aen_queue_event(TW_Device_Extension 
> *tw_dev, TW_Command_Apache_H
>   memset(event, 0, sizeof(TW_Event));
>  
>   event->severity = TW_SEV_OUT(header->status_block.severity__reserved);
> - do_gettimeofday(&time);
> - local_time = (u32)(time.tv_sec - (sys_tz.tz_minuteswest * 60));
> - event->time_stamp_sec = local_time;
> + event->time_stamp_sec = local_time_seconds();
>   event->aen_code = aen;
>   event->retrieved = TW_AEN_NOT_RETRIEVED;
>   event->sequence_id = tw_dev->error_sequence_id;
> @@ -479,11 +475,9 @@ out:
>  static void twa_aen_sync_time(TW_Device_Extension *tw_dev, int request_id)
>  {
>   u32 schedulertime;
> - struct timeval utc;
>   TW_Command_Full *full_command_packet;
>   TW_Command *command_packet;
>   TW_Param_Apache *param;
> - u32 local_time;
>  
>   /* Fill out the command packet */
>   full_command_packet = tw_dev->command_packet_virt[request_id];
> @@ -503,11 +497,7 @@ static void twa_aen_sync_time(TW_Device_Extension 
> *tw_dev, int request_id)
>   param->parameter_id = cpu_to_le16(0x3); /* SchedulerTime */
>   param->parameter_size_bytes = cpu_to_le16(4);
>  
> - /* Convert system time in UTC to local time seconds since last 
> -   Sunday 12:00AM */
> - do_gettimeofday(&utc);
> - local_time = (u32)(utc.tv_sec - (sys_tz.tz_minuteswest * 60));
> - schedulertime = local_time - (3 * 86400);
> + schedulertime = local_time_seconds() - (3 * 86400);
>   schedulertime = cpu_to_le32(schedulertime % 604800);
>  
>   memcpy(param->data, &schedulertime, sizeof(u32));
> diff --git a/drivers/scsi/3w-sas.c b/drivers/scsi/3w-sas.c
> index c845bdb..69f1d8a 100644
> --- a/drivers/scsi/3w-sas.c
> +++ b/drivers/scsi/3w-sas.c
> @@ -236,8 +236,6 @@ out:
>  /* This function will queue an event */
>  static void twl_aen_queue_event(TW_Device_Extension *tw_dev, 
> TW_Command_Apache_Header *header)
>  {
> - u32 local_time;
> - struct timeval time;
>   TW_Event *event;
>   unsigned short aen;
>   char host[16];
> @@ -256,9 +254,7 @@ static void twl_aen_queue_event(TW_Device_Extension 
> *tw_dev, TW_Command_Apache_H
>   memset(event, 0, sizeof(TW_Event));
>  
>   event->severity = TW_SEV_OUT(header->status_block.severity__reserved);
> - do_gettimeofday(&time);
> - local_time = (u32)(time.tv_sec - (sys_tz.tz_minuteswest * 60));
> - event->time_stamp_sec = local_time;
> + event->time_stamp_sec = local_time_seconds();
>   event->aen_code = aen;
>   event->retrieved = TW_AEN_NOT_RETRIEVED;
>   event->sequence_id = tw_dev->error_sequence_id;
> @@ -444,11 +440,9 @@ out:
>  static void twl_aen_sync_time(TW_Device_Extension *tw_dev, int request_id)
>  {
>   u32 schedulertime;
> - struct timeval utc;
>   TW_Command_Full *full_command_packet;
>   TW_Command *command_packet;
>   TW_Param_Apache *param;
> - u32 local_time;
>  
>   /* Fill out the command packet */
>   full_command_packet = tw_dev->command_packet_virt[request_id];
> @@ -468,11 +462,7 @@ static void twl_aen_sync_time(TW_Device_Extension 
> *tw_dev, int request_id)
>   param->parameter_id = cpu_to_le16(0x3); /* SchedulerTime */
>   param->parameter_size_bytes = cpu_to_le16(4);
>  
> - /* Convert system time in UTC to local time seconds since last 
> -   Sunday 12:00AM */
> - do_gettimeofday(&utc);
> - local_time = (u32)(utc.tv_sec - (sys_tz.tz_minuteswest * 60));
> - schedulertime = local_time - (3 * 86400);
> + schedulertime = local_time_seconds() - (3 * 86400);
>   schedulertime = cpu_to_le32(schedulertime % 604800);
>  
>   memcpy(param->data, &schedulertime, sizeof(u32));
> diff --git a/include/scsi/scsi.h b/include/scsi/scsi.h
> index 66216c1..f3377ca 100644
> --- a/include/scsi/scsi.h
> +++ b/include/scsi/scsi.h
> @@ -574,4 +574,13 @@ static inline __u32 scsi_to_u32(__u8 *ptr)
>   retu

Re: [PATCH 2/2] xen: remove bm_rld_set of xen_processor_flags

[Jan Beulich]

>>> On 04.06.13 at 10:05, liguang  wrote:
> bm_rld_set seems obsolete now
> 
> Signed-off-by: liguang 
> ---
>  include/xen/interface/platform.h |1 -
>  1 files changed, 0 insertions(+), 1 deletions(-)
> 
> diff --git a/include/xen/interface/platform.h 
> b/include/xen/interface/platform.h
> index c57d5f6..733 100644
> --- a/include/xen/interface/platform.h
> +++ b/include/xen/interface/platform.h
> @@ -240,7 +240,6 @@ struct xen_processor_flags {
>   uint32_t bm_check:1;
>   uint32_t has_cst:1;
>   uint32_t power_setup_done:1;
> - uint32_t bm_rld_set:1;
>  };
>  
>  struct xen_processor_power {

Any such patch would need to be submitted against the master copy
of the header (in the Xen repo), and by recognizing that you'd also
notice that this is part of a public ABI, and hence can't be removed,
but at best can be documented as obsolete. Of course you'd first
need to check whether the hypervisor makes any use of that bit
when passed down from Dom0.

Jan

--
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] EFI 1:1 mapping

[Borislav Petkov]

On Mon, Jun 03, 2013 at 03:54:12PM +0100, Matt Fleming wrote:
> On Mon, 03 Jun, at 03:32:52PM, Matthew Garrett wrote:
> > We can only pass one set of addresses to SetVirtualAddressMap(), but it 
> > doesn't seem like there's any intrinsic reason we can't the runtime 
> > regions mapped to multiple virtual addresses.
> 
> Indeed. That's the approach I took with my 1:1 series from last year. If
> Windows is mapping things at higher addresses like you said, then
> they're probably doing the same.

Right, the way I've done it now is to do the virtual mapping
unconditionally, then do the 1:1 mapping and call SetVirtualAddressMap
(f*cking camelcase is so nasty to type - that's why they need whole IDEs
to program :-)) with that map, if "efi=1:1_map" has been passed on the
cmd line.

After the call, we use *only* the 1:1 map but the virtual mapping is
still there.

The initial approach to addressing the b0rked Macs would then be to
never use the 1:1 map on them.

-- 
Regards/Gruss,
Boris.

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

Re: [PATCH 2/2] xen: remove bm_rld_set of xen_processor_flags

[li guang]

在 2013-06-04二的 09:13 +0100，Jan Beulich写道：
> >>> On 04.06.13 at 10:05, liguang  wrote:
> > bm_rld_set seems obsolete now
> > 
> > Signed-off-by: liguang 
> > ---
> >  include/xen/interface/platform.h |1 -
> >  1 files changed, 0 insertions(+), 1 deletions(-)
> > 
> > diff --git a/include/xen/interface/platform.h 
> > b/include/xen/interface/platform.h
> > index c57d5f6..733 100644
> > --- a/include/xen/interface/platform.h
> > +++ b/include/xen/interface/platform.h
> > @@ -240,7 +240,6 @@ struct xen_processor_flags {
> > uint32_t bm_check:1;
> > uint32_t has_cst:1;
> > uint32_t power_setup_done:1;
> > -   uint32_t bm_rld_set:1;
> >  };
> >  
> >  struct xen_processor_power {
> 
> Any such patch would need to be submitted against the master copy
> of the header (in the Xen repo), and by recognizing that you'd also
> notice that this is part of a public ABI, and hence can't be removed,
> but at best can be documented as obsolete. Of course you'd first
> need to check whether the hypervisor makes any use of that bit
> when passed down from Dom0.
> 

Right, this patch mostly likes a reminder,
hoping someone will try it and verify it's fail or OK,
since I can't test this for now.

Sorry and 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] sched: fix clear NOHZ_BALANCE_KICK

[Vincent Guittot]

On 4 June 2013 00:48, Frederic Weisbecker  wrote:
> On Thu, May 30, 2013 at 05:23:05PM +0200, Vincent Guittot wrote:
>> I have faced a sequence where the Idle Load Balance was sometime not
>>  triggered for a while on my platform.
>>
>> CPU 0 and CPU 1 are running tasks and CPU 2 is idle
>>
>> CPU 1 kicks the Idle Load Balance
>> CPU 1 selects CPU 2 as the new Idle Load Balancer
>> CPU 1 sets NOHZ_BALANCE_KICK for CPU 2
>> CPU 1 sends a reschedule IPI to CPU 2
>> While CPU 2 wakes up, CPU 0 or CPU 1 migrates a waking task A on CPU 2
>> CPU 2 finally wakes up, runs task A and discards the Idle Load Balance
>> Task A quickly goes back to sleep (before a tick occurs on CPU 2)
>> CPU 2 goes back to idle with NOHZ_BALANCE_KICK set
>>
>> Whenever CPU 2 will be selected for the ILB, reschedule IPI will be not
>> sent to CPU2, which is idle, because NOHZ_BALANCE_KICK is already set
>> and no Idle Load Balance will be performed.
>>
>> We must wait for the sched softirq to be raised on CPU 2 thanks to
>> another part of the kernel to clear NOHZ_BALANCE_KICKand come back to
>> a normal situation.
>>
>> The proposed solution clears NOHZ_BALANCE_KICK in schedule_ipi if
>> we can't raise the sched_softirq for the Idle Load Balance.
>>
>> Signed-off-by: Vincent Guittot 
>> ---
>>  kernel/sched/core.c |3 ++-
>>  1 file changed, 2 insertions(+), 1 deletion(-)
>>
>> diff --git a/kernel/sched/core.c b/kernel/sched/core.c
>> index 58453b8..51fc715 100644
>> --- a/kernel/sched/core.c
>> +++ b/kernel/sched/core.c
>> @@ -1420,7 +1420,8 @@ void scheduler_ipi(void)
>>   if (unlikely(got_nohz_idle_kick() && !need_resched())) {
>>   this_rq()->idle_balance = 1;
>>   raise_softirq_irqoff(SCHED_SOFTIRQ);
>> - }
>> + } else
>> + clear_bit(NOHZ_BALANCE_KICK, nohz_flags(smp_processor_id()));
>
> But then do we reach this if the IPI happens while running the non-idle task 
> in
> CPU 2? The first got_nohz_idle_kick() test would drop us out early from 
> scheduler_ipi()
> due to the idle_cpu() test. So the flag doesn't get cleared in this case.

The 1st point is that only idle cpu can be selected for idle load
balance. But this doesn't prevent the cpu to wake up while it is
kicked for idle load balance.
I had added the clear_bit for the 1st got_nohz_idle_kick in the draft
version of this patch but the test of the emptiness of the wake_list,
the call to smp_send_reschedule in the various way to wake up the idle
cpu and the results of the tests have convinced me (may be wrongly)
that it was not necessary.

Vincent
--
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 16/16] perf, persistent: Allow multiple users for an event

[Borislav Petkov]

On Mon, Jun 03, 2013 at 03:49:25PM +0200, Jiri Olsa wrote:
> maybe check for valid cpu, since perf_get_persistent_event_fd is
> called directly from syscall allowing anything in cpu

That should be fine - we're traversing a per-cpu list of events there.

> (unrelated to this patch, but I couldn't find the original
> patch that adds perf_get_persistent_event_fd)

Try this:

http://git.kernel.org/cgit/linux/kernel/git/bp/bp.git/log/?h=persistent5.1

:-)

-- 
Regards/Gruss,
Boris.

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

Re: [PATCH] net: emaclite: include linux/of_irq.h

[Michal Simek]

On 06/03/2013 11:39 PM, Arnd Bergmann wrote:
> The emaclite driver now calls of_irq_to_resource, which is
> declared in linux/of_irq.h. Without this patch, I get a build
> error on ARM.

What about to just change it to use platform_get_resource()?
I will test it.

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: [Xen-devel] [PATCH] PVH: vcpu info placement, load selectors, and remove debug printk.

[Jan Beulich]

>>> On 04.06.13 at 02:43, Mukesh Rathor  wrote:
> @@ -1327,6 +1329,18 @@ static void __init xen_setup_stackprotector(void)
>   /* PVH TBD/FIXME: investigate setup_stack_canary_segment */
>   if (xen_feature(XENFEAT_auto_translated_physmap)) {
>   switch_to_new_gdt(0);
> +
> + /* xen started us with null selectors. load them now */
> + __asm__ __volatile__ (
> + "movl %0,%%ds\n"
> + "movl %0,%%ss\n"
> + "pushq %%rax\n"
> + "leaq 1f(%%rip),%%rax\n"
> + "pushq %%rax\n"
> + "retfq\n"
> + "1:\n"
> + : : "r" (__KERNEL_DS), "a" (__KERNEL_CS) : "memory");
> +

I can see why you want CS to be reloaded (and CS, other than the
comment says, clearly hasn't been holding a null selector up to here.

I can't immediately see why you'd need SS to be other than null, and
it completely escapes me why you'd need to DS (but not ES) to be
non-null.

Furthermore, is there any reason why you use "retfq" (Intel syntax)
when all assembly code otherwise uses AT&T syntax (the proper
equivalent here would be "lretq")?

And finally, please consistently use % (which, once
fixed, will make clear that the second constraint really can be "r"),
and avoid using suffixes on moves to/from selector registers
(which, once fixed, will make clear that at least the first constraint
really can be relaxed to "rm").

Jan

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

Re: [PATCH 01/10] clocksource: dw_apb_timer_of: use the clocksource as sched clock if necessary

[Heiko Stübner]

Am Dienstag, 4. Juni 2013, 08:34:44 schrieb Linus Walleij:
> On Mon, Jun 3, 2013 at 12:56 AM, Heiko Stübner  wrote:
> > Currently the dw_apb_timer always expects a separate special timer to be
> > availbable for the sched_clock. Some devices using dw_apb_timers do not
> > have the sptimer but can use the clocksource as sched_clock.
> > Therefore this patch adds using the clocksource timer as
> > a fallback if no usable sched timer is found.
> > 
> > Signed-off-by: Heiko Stuebner 
> 
> Is this really what the patch does? I mean "ass the clocksourse as
> fallback", it seems more like that is controlled from the device tree,
> this looks more like some more careful handling of the device tree
> input making the sched_timer optional, it doesn't really "add"
> anything, does it?

Right, the commit message is probably based a bit to much on the before-state 
of the driver, always expecting the "sptimer" and panicing if not found.

How about:

Currently the dw_apb_timer always expects a separate special timer to be
availbable for the sched_clock. Some devices using dw_apb_timers do not
have this sptimer but can use the clocksource as sched_clock instead.

Therefore enable the driver to distiguish between devices with and without
sptimer based on the devicetree data and select the correct timer as
sched_clock.
--
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/1] kvm/vmx: Add a tracepoint write_tsc_offset

[Yoshihiro YUNOMAE]

Add a tracepoint write_tsc_offset for tracing TSC offset change.
We want to merge ftrace's trace data of guest OSs and the host OS using
TSC for timestamp in chronological order. We need "TSC offset" values for
each guest when merge those because the TSC value on a guest is always the
host TSC plus guest's TSC offset. If we get the TSC offset values, we can
calculate the host TSC value for each guest events from the TSC offset and
the event TSC value. The host TSC values of the guest events are used when we
want to merge trace data of guests and the host in chronological order.
(Note: the trace_clock of both the host and the guest must be set x86-tsc in
this case)

TSC offset is stored in the VMCS by vmx_write_tsc_offset() or
vmx_adjust_tsc_offset(). KVM executes the former function when a guest boots.
The latter function is executed when kvm clock is updated. Only host can read
TSC offset value from VMCS, so a host needs to output TSC offset value
when TSC offset is changed.

Since the TSC offset is not often changed, it could be overwritten by other
frequent events while tracing. To avoid that, I recommend to use a special
instance for getting this event:

1. set a instance before booting a guest
 # cd /sys/kernel/debug/tracing/instances
 # mkdir tsc_offset
 # cd tsc_offset
 # echo x86-tsc > trace_clock
 # echo 1 > events/kvm/kvm_write_tsc_offset/enable

2. boot a guest

Signed-off-by: Yoshihiro YUNOMAE 
Cc: Marcelo Tosatti 
Cc: Gleb Natapov 
Cc: Thomas Gleixner 
Cc: Ingo Molnar 
Cc: "H. Peter Anvin" 
---
 arch/x86/kvm/trace.h |   18 ++
 arch/x86/kvm/vmx.c   |3 +++
 arch/x86/kvm/x86.c   |1 +
 3 files changed, 22 insertions(+)

diff --git a/arch/x86/kvm/trace.h b/arch/x86/kvm/trace.h
index fe5e00e..9c22e39 100644
--- a/arch/x86/kvm/trace.h
+++ b/arch/x86/kvm/trace.h
@@ -815,6 +815,24 @@ TRACE_EVENT(kvm_track_tsc,
  __print_symbolic(__entry->host_clock, host_clocks))
 );
 
+TRACE_EVENT(kvm_write_tsc_offset,
+   TP_PROTO(__u64 previous_tsc_offset, __u64 next_tsc_offset),
+   TP_ARGS(previous_tsc_offset, next_tsc_offset),
+
+   TP_STRUCT__entry(
+   __field(__u64,  previous_tsc_offset )
+   __field(__u64,  next_tsc_offset )
+   ),
+
+   TP_fast_assign(
+   __entry->previous_tsc_offset= previous_tsc_offset;
+   __entry->next_tsc_offset= next_tsc_offset;
+   ),
+
+   TP_printk("previous=%llu next=%llu",
+ __entry->previous_tsc_offset, __entry->next_tsc_offset)
+);
+
 #endif /* CONFIG_X86_64 */
 
 #endif /* _TRACE_KVM_H */
diff --git a/arch/x86/kvm/vmx.c b/arch/x86/kvm/vmx.c
index 25a791e..00f7dde 100644
--- a/arch/x86/kvm/vmx.c
+++ b/arch/x86/kvm/vmx.c
@@ -2096,6 +2096,7 @@ static void vmx_write_tsc_offset(struct kvm_vcpu *vcpu, 
u64 offset)
(nested_cpu_has(vmcs12, CPU_BASED_USE_TSC_OFFSETING) ?
 vmcs12->tsc_offset : 0));
} else {
+   trace_kvm_write_tsc_offset(vmcs_read64(TSC_OFFSET), offset);
vmcs_write64(TSC_OFFSET, offset);
}
 }
@@ -2103,6 +2104,8 @@ static void vmx_write_tsc_offset(struct kvm_vcpu *vcpu, 
u64 offset)
 static void vmx_adjust_tsc_offset(struct kvm_vcpu *vcpu, s64 adjustment, bool 
host)
 {
u64 offset = vmcs_read64(TSC_OFFSET);
+
+   trace_kvm_write_tsc_offset(offset, offset + adjustment);
vmcs_write64(TSC_OFFSET, offset + adjustment);
if (is_guest_mode(vcpu)) {
/* Even when running L2, the adjustment needs to apply to L1 */
diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c
index 05a8b1a..c942a0c 100644
--- a/arch/x86/kvm/x86.c
+++ b/arch/x86/kvm/x86.c
@@ -7264,3 +7264,4 @@ EXPORT_TRACEPOINT_SYMBOL_GPL(kvm_nested_intr_vmexit);
 EXPORT_TRACEPOINT_SYMBOL_GPL(kvm_invlpga);
 EXPORT_TRACEPOINT_SYMBOL_GPL(kvm_skinit);
 EXPORT_TRACEPOINT_SYMBOL_GPL(kvm_nested_intercepts);
+EXPORT_TRACEPOINT_SYMBOL_GPL(kvm_write_tsc_offset);

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

[PATCH V2 0/1] kvm/vmx: Output TSC offset

[Yoshihiro YUNOMAE]

Hi All,

I'd like to propose a patch which adds a tracepoint at write_tsc_offset for
tracing guests TSC offset changes. It is required for sorting the trace data of
a guest and the host in chronological order.

In a virtualization environment, it is difficult to analyze performance
problems, such as a delay of I/O request on a guest. This is because multiple
guests operate on the host. One of approaches for solving such kind of problems
is to sort trace data of guests and the host in chronological order.

Raw TSC can be chosen as a timestamp of ftrace. I think TSC is useful for
merging trace data in chronological order by two reasons. One of the reasons is 
that guests can directly read raw TSC from the CPU using rdtsc operation. This
means that raw TSC value is not software clock like sched_clock, so we don't
need to consider about how the timestamp is calculated. The other is that TSC
of recent x86 CPUs is constantly incremented. This means that we don't need to
worry about pace of the timestamp. Therefore, choosing TSC as a timestamp for
tracing is reasonable to integrate trace data of guests and a host.

Here, we need to consider about just one matter for using TSC on guests. TSC
value on a guest is always the host TSC plus the guest's "TSC offset". In other
words, to merge trace data using TSC as timestamp in chronological order, we
need to consider TSC offset of the guest.

However, only the host kernel can read the TSC offset from VMCS and TSC offset
is not output in anywhere now. In other words, tools in userland cannot get
the TSC offset value, so we cannot merge trace data of guest and the host in
chronological order. Therefore, I think the TSC offset should be exported for
userland tools.

In this patch, TSC offset is exported by the tracepoint kvm_write_tsc_offset
on the host. TSC offset events will be very rare event because guests may
seldom execute write_tsc. So if we enable this event for a normal buffer of
ftrace, the events will be overwritten by other events. For a recent linux
kernel, a multiple buffer function is available. So, I recommend to enable
this event for a sub buffer of ftrace.


We assume that wakeup-latency for a command is big on a guest. Normally
we will use ftrace's wakeup-latency tracer or event tracer on the guest, but we
may not be able to solve this problem. This is because guests often exit to
the host for several reasons. In the next, we will use TSC as ftrace's timestamp
and record the trace data on the guest and the host. Then, we get following
data:

 /* guest data */
comm-3826  [000] d...49836825726903: sched_wakeup: [detail]
comm-3826  [000] d...49836832225344: sched_switch: [detail]
 /* host data */
qemu-kvm-2687  [003] d...50550079203669: kvm_exit: [detail]
qemu-kvm-2687  [003] d...50550079206816: kvm_entry: [detail]
qemu-kvm-2687  [003] d...50550079240656: kvm_exit: [detail]
qemu-kvm-2687  [003] d...50550079243467: kvm_entry: [detail]
qemu-kvm-2687  [003] d...50550079256103: kvm_exit: [detail]
qemu-kvm-2687  [003] d...50550079268391: kvm_entry: [detail]
qemu-kvm-2687  [003] d...50550079280829: kvm_exit: [detail]
qemu-kvm-2687  [003] d...50550079286028: kvm_entry: [detail]

Since TSC offset is not considered, these data cannot be merged. If this trace
data is shown like as follows, we will be able to understand the reason:

qemu-kvm-2687  [003] d...50550079203669: kvm_exit: [detail]
qemu-kvm-2687  [003] d...50550079206816: kvm_entry: [detail]
comm-3826  [000] d.h.49836825726903: sched_wakeup: [detail] <=
qemu-kvm-2687  [003] d...50550079240656: kvm_exit: [detail]
qemu-kvm-2687  [003] d...50550079243467: kvm_entry: [detail]
qemu-kvm-2687  [003] d...50550079256103: kvm_exit: [detail]
qemu-kvm-2687  [003] d...50550079268391: kvm_entry: [detail]
comm-3826  [000] d...49836832225344: sched_switch: [detail] <=
qemu-kvm-2687  [003] d...50550079280829: kvm_exit: [detail]
qemu-kvm-2687  [003] d...50550079286028: kvm_entry: [detail]

In this case, we can understand wakeup-latency was big due to exit to host
twice. Getting this data sorted in chronological order is our goal.

To merge the data like previous pattern, we apply this patch. Then, we can
get TSC offset of the guest as follows:

# cat /sys/kernel/debug/tracing/instances/tsc_offset/trace
.. d...4300151845072: kvm_write_tsc_offset: previous 0 next 18446739773557710924
 ^  

We use this TSC offset value to a merge script and obtain the following data:

$ ./trace-merge.pl -g guest_data -h host_data -t 18446739773557710924

hqemu-kvm-2687  [003] d...50550079203669: kvm_exit: [detail]
hqemu-kvm-2687  [003] d...50550079206816: kvm_entry: [detail]
gcomm-3826  [000] d.h.50550079226331: sched_wakeup: [detail] <=
hqemu-kvm-2687  [003] d.

[EXAMPLE] tools: a tool for merging trace data of a guest and a host

[Yoshihiro YUNOMAE]

This tool merges trace data of a guest and a host in chronological
order. Restrictions of this tool is as follows:
- one guest (not for multiple guests)
- stable TSC (not backward TSC)
- synchronized TSC
- unchanged TSC offset (the guest does not execute write_TSC)

- How to use
1. [host] Enable kvm_write_tsc_offset before booting a guest
 # cd /sys/kernel/debug/tracing/instances
 # mkdir tsc_offset
 # cd tsc_offset
 # echo x86-tsc > trace_clock
 # echo 1 > events/kvm/kvm_write_tsc_offset/enable

2. [host] Enable events you want
  Note: I recommend to enable kvm_exit/entry events.
 # cd /sys/kernel/debug/tracing
 # echo kvm_entry >> set_event
 # echo kvm_exit >> set_event
 # [snip]
 # echo x86-tsc > trace_clock

3. [host] Boot the guest

4. [guest] Enable events you want
 # cd /sys/kernel/debug/tracing
 # echo sched_wakeup >> set_event
 # echo sched_switch >> set_event
 # [snip]
 # echo x86-tsc > trace_clock

5. [guest] Run programs

6. [guest/host] Get trace data
 # echo 0 > tracing_on
 # cat trace > /home/yourdir/log/guest_trace.txt (for the guest)
   (cat trace > /home/yourdir/log/host_trace.txt (for the host))
 # scp [host_IP]:/home/yourdir/log/guest_trace.txt (only for the guest)

7. [host] Get next TSC offset
 # cat /sys/kernel/debug/tracing/instances/tsc_offset/trace
qemu-kvm-22089 [000] d...4300151845072: kvm_write_tsc_offset: 
previous 0 next 18446739773557710924


8. [host] Run this tool with the next TSC offset for -t option.
$ ./trace-merge.pl -g ~/log/guest_trace.txt -h ~/log/host_trace.txt \
  -t 18446739773557710924

hqemu-kvm-2687  [003] d...50550079203669: kvm_exit: [detail]
hqemu-kvm-2687  [003] d...50550079206816: kvm_entry: [detail]
gcomm-3826  [000] d.h.50550079226331: sched_wakeup: [detail]
hqemu-kvm-2687  [003] d...50550079240656: kvm_exit: [detail]
hqemu-kvm-2687  [003] d...50550079243467: kvm_entry: [detail]
hqemu-kvm-2687  [003] d...50550079256103: kvm_exit: [detail]
hqemu-kvm-2687  [003] d...50550079268391: kvm_entry: [detail]
gcomm-3826  [000] d...50550079279266: sched_switch: [detail]
hqemu-kvm-2687  [003] d...50550079280829: kvm_exit: [detail]
hqemu-kvm-2687  [003] d...50550079286028: kvm_entry: [detail]
|
\guest/host

Thanks,

--
Yoshihiro YUNOMAE
Software Platform Research Dept. Linux Technology Center
Hitachi, Ltd., Yokohama Research Laboratory
E-mail: yoshihiro.yunomae...@hitachi.com


#!/usr/bin/perl
#
# Tool for merging and sorting trace data of a guest and host
#
# Created by Yoshihiro YUNOMAE 
#
# - How to use
# ./trace-merge.pl <-h host_data -g guest_data -t tsc_offset_value>
#
use strict;
use bigint;
use warnings;
use Getopt::Long qw(:config posix_default no_ignore_case);

my @merged_data = ();
my @sorted_data = ();

my ($opt_host, $opt_guest, $opt_offset);
GetOptions(
"host_data|h=s" => \$opt_host,
"guest_data|g=s"=> \$opt_guest,
"tsc_offset|t=i"=> \$opt_offset
);

my $tsc_offset = 0;
my $MASK64 = (1 << 64) - 1;

&get_tsc_offset();
&read_all_data();

sub read_all_data {
my $h_tsc = 0;
my $g_comm = "";
my $g_tsc = 0;
my $g_event = "";
my $h_line = "";
my $g_line = "";

open HOST_DATA, "<", $opt_host or die "Cannot open host file: $!";
open GUEST_DATA, "<", $opt_guest or die "Cannot open guest file: $!";

# skip header information of trace files
while (!$h_tsc) {
$h_line = ;
if ($h_line =~ /\[[0-9]+\]\s.{4}\s([0-9]+):/) {
$h_tsc = $1;
}
}

# skip header information of trace files
while (!$g_tsc) {
$g_line = ;
if ($g_line =~ /^(.+\[[0-9]+\]\s.{4}\s)([0-9]+)(:.+)/) {
$g_comm = $1;
$g_tsc = ($2 - $tsc_offset) & $MASK64;
$g_event = $3;
}
}

# sort trace data by tsc
while ($h_line) {
if ($h_tsc < $g_tsc) {
print "h $h_line";
$h_line = ;
if (!$h_line) {
last;
}
if ($h_line =~ /\[[0-9]+\]\s.{4}\s([0-9]+):/) {
$h_tsc = $1;
}
} else {
print "g $g_comm$g_tsc$g_event\n";
$g_line = ;
if (!$g_line) {
last;
}
if ($g_line =~ /^(.+\[[0-9]+\]\s.{4}\s)([0-9]+)(:.+)/) {
$g_comm = $1;
$g_tsc = ($2 - $tsc_offset) & $MASK64;
$g_event = $3;
}
}
}

  

Re: [PATCH] drm/tegra: add support for runtime pm

[Mayuresh Kulkarni]

On Tuesday 28 May 2013 02:40 PM, Thierry Reding wrote:

* PGP Signed by an unknown key

On Tue, May 28, 2013 at 08:45:03AM +0300, Terje Bergström wrote:

On 27.05.2013 18:45, Thierry Reding wrote:

On Mon, May 27, 2013 at 07:19:28PM +0530, Mayuresh Kulkarni wrote:

+#ifdef CONFIG_PM_RUNTIME
+static int host1x_runtime_suspend(struct device *dev)
+{
+   struct host1x *host;
+
+   host = dev_get_drvdata(dev);
+   if (IS_ERR_OR_NULL(host))


I think a simple

if (!host)
return -EINVAL;

would be enough here. The driver-data of the device should never be an
ERR_PTR()-encoded value, but either a valid pointer to a host1x object
or NULL.


True, we should avoid IS_ERR_OR_NULL() like plague. We always know if
the called API returns a NULL on error or an error code. In case of
error code we should just propagate that.


Yes, that's the case in general. In this specific case the value
obtained by dev_get_drvdata() should either be a valid pointer or NULL,
never an error code. We can easily make sure by only setting the data
(using platform_set_drvdata()) when the pointer is valid.

Thinking about it some more, I don't think we can ever get NULL here. A
device's .runtime_suspend() cannot be called when the device has been
removed, right? That's the only case where the value returned might be
NULL. It would be NULL too if host1x wasn't initialized yet, but that's
already dealt with by the proper ordering in .probe().


Same comments apply here. Also I think it might be a good idea to split
the host1x and gr2d changes into separate patches.


That's a bit tricky, but doable. We just need to enable it for 2D first,
and then host1x to keep bisectability.


Right, there's a dependency. But I'd still prefer to have them separate.
Unless it gets really messy.


  static void action_submit_complete(struct host1x_waitlist *waiter)
  {
+   int completed = waiter->count;
struct host1x_channel *channel = waiter->data;

+   /* disable clocks for all the submits that got completed in this lot */
+   while (completed--)
+   pm_runtime_put(channel->dev);
+
host1x_cdma_update(&channel->cdma);

-   /*  Add nr_completed to trace */
+   /* Add nr_completed to trace */
trace_host1x_channel_submit_complete(dev_name(channel->dev),
 waiter->count, waiter->thresh);
-
  }


This feels hackish. But I can't see any better place to do this. Terje,
Arto: any ideas how we can do this in a cleaner way? If there's nothing
better then maybe moving the code into a separate function, say
host1x_waitlist_complete(), might make this less awkward?


Yeah, it's a bit awkward. action_submit_complete() actually does handle
completion of multiple jobs, and we do one pm_runtime_get() per job.

We could do pm_runtime_put() in host1x_cdma_update(). It anyway goes
through each job that is completed, so while freeing the job it could as
well call runtime PM. That way we could even remove the waiter->count
variable altogether as it's not needed anymore.


That sounds a lot better. We could add a helper (host1x_job_finish()
perhaps) with the following from update_cdma_locked():

/* Unpin the memory */
host1x_job_unpin(job);

/* Pop push buffer slots */
if (job->num_slots) {
struct push_buffer *pb = &cdma->push_buffer;
host1x_pushbuffer_pop(pb, job->num_slots);
if (cdma->event == CDMA_EVENT_PUSH_BUFFER_SPACE)
signal = true;
}

list_del(&job->list);

And add pm_runtime_put() (as well as potentially other stuff) in there.
That'll prevent update_cdma_unlocked() from growing too much. It isn't
too bad right now, so maybe a helper isn't warranted yet, but I don't
think it'll hurt.


The not-so-beautiful aspect is that we do pm_runtime_get() in
host1x_channel.c and pm_runtime_put() in host1x_cdma.c. For code
readability it's be great to have them in the same file. I actually get
questions every now and then because in downstream because of doing
these operations in different files.


With the above helper in place, we could move host1x_job_submit() to
job.c instead and have all the code in one file.

Thierry

* Unknown Key
* 0x7F3EB3A1



In downstream, we have 2 APIs which are wrapper over runtime PM calls. 
We call those from _submit and job complete.


I wonder if we should follow the same here?

--
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 3/3] PCI/AER: Provide reset_link for firmware first root port

[Chen Gong]

On Thu, May 30, 2013 at 08:39:29AM -0600, Betty Dall wrote:
> Date: Thu, 30 May 2013 08:39:29 -0600
> From: Betty Dall 
> To: r...@sisk.pl, bhelg...@google.com
> Cc: ying.hu...@intel.com, linux-a...@vger.kernel.org,
>  linux-kernel@vger.kernel.org, linux-...@vger.kernel.org, Betty Dall
>  
> Subject: [PATCH v2 3/3] PCI/AER: Provide reset_link for firmware first root
>  port
> X-Mailer: git-send-email 1.7.7.6
> 
> The firmware first path does not install the aerdrv root port
> service driver, so the firmware first root port does not have
> a reset_link callback. When a firmware first root port does not have
> a reset_link callback, use a new default reset_link similar to what
> we already do for the default_downstream_reset_link(). The firmware
> first default reset_link brings the root port out of SBR if firmware
> left it in SBR.
> 
> Changes since v1:
> Removed incorrect setting of p2p_ctrl after the read.
> 
> Signed-off-by: Betty Dall 
> ---
> 
>  drivers/pci/pcie/aer/aerdrv_core.c |   36 
> 
>  1 files changed, 36 insertions(+), 0 deletions(-)
> 
> 
> diff --git a/drivers/pci/pcie/aer/aerdrv_core.c 
> b/drivers/pci/pcie/aer/aerdrv_core.c
> index 8ec8b4f..72f76cd 100644
> --- a/drivers/pci/pcie/aer/aerdrv_core.c
> +++ b/drivers/pci/pcie/aer/aerdrv_core.c
> @@ -413,6 +413,39 @@ static pci_ers_result_t 
> default_downstream_reset_link(struct pci_dev *dev)
>   return PCI_ERS_RESULT_RECOVERED;
>  }
>  
> +/**
> + * default_ff_root_port_reset_link - default reset function for firmware
> + *   first Root Port
> + * @dev: pointer to root port's pci_dev data structure
> + *
> + * Invoked when performing link reset at Root Port w/ no aer driver.
> + * This happens through the firmware first path. Firmware may leave
> + * the Root Port in SBR and it is the OS responsiblity to bring it out
> + * of SBR.
> + */
> +static pci_ers_result_t default_ff_root_port_reset_link(struct pci_dev *dev)
> +{
> + u16 p2p_ctrl;
> +
> + /* Read Secondary Bus Reset */
> + pci_read_config_word(dev, PCI_BRIDGE_CONTROL, &p2p_ctrl);
> +
> + /* De-assert Secondary Bus Reset, if it is set */
> + if (p2p_ctrl & PCI_BRIDGE_CTL_BUS_RESET) {
> + p2p_ctrl &= ~PCI_BRIDGE_CTL_BUS_RESET;
> + pci_write_config_word(dev, PCI_BRIDGE_CONTROL, p2p_ctrl);
> +
> + /*
> +  * System software must wait for at least 100ms from the end
> +  * of a reset of one or more device before it is permitted
> +  * to issue Configuration Requests to those devices.
> +  */
> + msleep(200);
> + dev_dbg(&dev->dev, "Root Port link has been reset\n");
> + }
> + return PCI_ERS_RESULT_RECOVERED;
> +}

I don't think this function is OK.
1) You don't really reset the 2nd Bus but just checking its status.
I think you should have following steps to reset 2nd Bus:

a. Assert 2nd Bus Reset
b. wait for some time until this message has been broadcasted well
c. De-assert 2nd Bus Reset
d. wait for Trst time

IOW, since we have aer_do_secondary_bus_reset to perform secondary bus
reset, why you repeat it again?

2) msleep(200) is too long for kernel. You'd better yield the CPU when
sleep.

> +
>  static int find_aer_service_iter(struct device *device, void *data)
>  {
>   struct pcie_port_service_driver *service_driver, **drv;
> @@ -460,6 +493,9 @@ static pci_ers_result_t reset_link(struct pci_dev *dev)
>   status = driver->reset_link(udev);
>   } else if (pci_pcie_type(udev) == PCI_EXP_TYPE_DOWNSTREAM) {
>   status = default_downstream_reset_link(udev);
> + } else if (pci_pcie_type(udev) == PCI_EXP_TYPE_ROOT_PORT &&
> + pcie_aer_get_firmware_first(udev)) {
> + status = default_ff_root_port_reset_link(udev);
>   } else {
>   dev_printk(KERN_DEBUG, &dev->dev,
>   "no link-reset support at upstream device %s\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/


signature.asc
Description: Digital signature

Re: [PATCH 06/10] mmc: dw_mmc-pltfm: add Rockchip variant

[Heiko Stübner]

Am Dienstag, 4. Juni 2013, 06:06:39 schrieb Jaehoon Chung:
> On 06/03/2013 07:59 AM, Heiko Stübner wrote:
> > Cortex-A9 SoCs from Rockchip use a slightly modified variant of dw_mmc
> > controllers that seems to require the SDMMC_CMD_USE_HOLD_REG bit to
> > always be set.
> > 
> > There also seem to be no other modifications (additional register etc)
> > present, so to keep the footprint low, add this small variant to the
> > pltfm driver.
> > 
> > Signed-off-by: Heiko Stuebner 
> > ---
> > 
> >  drivers/mmc/host/dw_mmc-pltfm.c |   48
> >  +++--- 1 files changed, 34
> >  insertions(+), 14 deletions(-)
> > 
> > diff --git a/drivers/mmc/host/dw_mmc-pltfm.c
> > b/drivers/mmc/host/dw_mmc-pltfm.c index 0048da8..7d041b5 100644
> > --- a/drivers/mmc/host/dw_mmc-pltfm.c
> > +++ b/drivers/mmc/host/dw_mmc-pltfm.c
> > @@ -24,6 +24,16 @@
> > 
> >  #include "dw_mmc.h"
> > 
> > +
> > +static void dw_mci_rockchip_prepare_command(struct dw_mci *host, u32
> > *cmdr)
> 
> How about using "dw_mci_pltfm_prepare_command()"?
> Maybe HOLD_REG could be used at other SoC.

The problem I had when thinking about it is that every implementation using 
the HOLD_REG stuff does it differently ... on the Exynos variant it depends on 
the CLKSEL register value and on the SOCFPGA variant on other clock values.

It's only on the Rockchip variant that it seems to needed all the time.

So, doing it with a "dw_mci_pltfm_prepare_command()" would need a flag to 
signal that the implementation needs the HOLD_REG all the time, but we won't 
know yet if other implementations will have other constraints on its use - 
like only i special cases or such.

So personally I would keep it as it is for now, until more platforms using the 
HOLD_REG come along to see some sort of pattern of its use?


--
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: emaclite: include linux/of_irq.h

[Arnd Bergmann]

On Tuesday 04 June 2013 10:21:01 Michal Simek wrote:
> On 06/03/2013 11:39 PM, Arnd Bergmann wrote:
> > The emaclite driver now calls of_irq_to_resource, which is
> > declared in linux/of_irq.h. Without this patch, I get a build
> > error on ARM.
> 
> What about to just change it to use platform_get_resource()?
> I will test it.

Yes, that would work too. It seems the driver predates the automatic
generation of resources for IRQs and MMIO registers.

If you change the IRQ resource to platform_get_resource, you should
change the other one as well.

Arnd
--
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: [tip:perf/urgent] perf: Fix perf mmap bugs

[Peter Zijlstra]

Ingo asked for a delta against the patch already included in -tip.

Vince; perf_fuzzer crashed after about 567 iterations -- not sure
you're aware it will crash at times. Anyway at this time accounting was
still good.

---
Subject: perf: Fix mmap() accounting hole

Vince's fuzzer once again found holes. This time it spotted a leak in
the locked page accounting.

When an event had redirected output and its close() was the last
reference to the buffer we didn't have a vm context to undo accounting.

Change the code to destroy the buffer on the last munmap() and detach
all redirected events at that time. This provides us the right context
to undo the vm accounting.

Reported-by: Vince Weaver 
Signed-off-by: Peter Zijlstra 
---
 kernel/events/core.c |  228 +++---
 kernel/events/internal.h |3 +-
 2 files changed, 159 insertions(+), 72 deletions(-)

diff --git a/kernel/events/core.c b/kernel/events/core.c
index 95edd5a..471e11b 100644
--- a/kernel/events/core.c
+++ b/kernel/events/core.c
@@ -198,9 +198,6 @@ static void cpu_ctx_sched_in(struct perf_cpu_context 
*cpuctx,
 static void update_context_time(struct perf_event_context *ctx);
 static u64 perf_event_time(struct perf_event *event);
 
-static void ring_buffer_attach(struct perf_event *event,
-  struct ring_buffer *rb);
-
 void __weak perf_event_print_debug(void)   { }
 
 extern __weak const char *perf_pmu_name(void)
@@ -3022,7 +3019,8 @@ static void free_event_rcu(struct rcu_head *head)
kfree(event);
 }
 
-static bool ring_buffer_put(struct ring_buffer *rb);
+static void ring_buffer_put(struct ring_buffer *rb);
+static void ring_buffer_detach(struct perf_event *event, struct ring_buffer 
*rb);
 
 static void free_event(struct perf_event *event)
 {
@@ -3047,15 +3045,30 @@ static void free_event(struct perf_event *event)
if (has_branch_stack(event)) {
static_key_slow_dec_deferred(&perf_sched_events);
/* is system-wide event */
-   if (!(event->attach_state & PERF_ATTACH_TASK))
+   if (!(event->attach_state & PERF_ATTACH_TASK)) {
atomic_dec(&per_cpu(perf_branch_stack_events,
event->cpu));
+   }
}
}
 
if (event->rb) {
-   ring_buffer_put(event->rb);
-   event->rb = NULL;
+   struct ring_buffer *rb;
+
+   /*
+* Can happen when we close an event with re-directed output.
+*
+* Since we have a 0 refcount, perf_mmap_close() will skip
+* over us; possibly making our ring_buffer_put() the last.
+*/
+   mutex_lock(&event->mmap_mutex);
+   rb = event->rb;
+   if (rb) {
+   rcu_assign_pointer(event->rb, NULL);
+   ring_buffer_detach(event, rb);
+   ring_buffer_put(rb); /* could be last */
+   }
+   mutex_unlock(&event->mmap_mutex);
}
 
if (is_cgroup_event(event))
@@ -3293,30 +3306,13 @@ static unsigned int perf_poll(struct file *file, 
poll_table *wait)
unsigned int events = POLL_HUP;
 
/*
-* Race between perf_event_set_output() and perf_poll(): perf_poll()
-* grabs the rb reference but perf_event_set_output() overrides it.
-* Here is the timeline for two threads T1, T2:
-* t0: T1, rb = rcu_dereference(event->rb)
-* t1: T2, old_rb = event->rb
-* t2: T2, event->rb = new rb
-* t3: T2, ring_buffer_detach(old_rb)
-* t4: T1, ring_buffer_attach(rb1)
-* t5: T1, poll_wait(event->waitq)
-*
-* To avoid this problem, we grab mmap_mutex in perf_poll()
-* thereby ensuring that the assignment of the new ring buffer
-* and the detachment of the old buffer appear atomic to perf_poll()
+* Pin the event->rb by taking event->mmap_mutex; otherwise
+* perf_event_set_output() can swizzle our rb and make us miss wakeups.
 */
mutex_lock(&event->mmap_mutex);
-
-   rcu_read_lock();
-   rb = rcu_dereference(event->rb);
-   if (rb) {
-   ring_buffer_attach(event, rb);
+   rb = event->rb;
+   if (rb)
events = atomic_xchg(&rb->poll, 0);
-   }
-   rcu_read_unlock();
-
mutex_unlock(&event->mmap_mutex);
 
poll_wait(file, &event->waitq, wait);
@@ -3626,16 +3622,12 @@ static void ring_buffer_attach(struct perf_event *event,
return;
 
spin_lock_irqsave(&rb->event_lock, flags);
-   if (!list_empty(&event->rb_entry))
-   goto unlock;
-
-   list_add(&event->rb_entry, &rb->event_list);
-unlock:
+   if (list_empty(&event->rb_entry))
+   list_add(&

Re: [PATCH] net: emaclite: include linux/of_irq.h

[Michal Simek]

On 06/04/2013 10:44 AM, Arnd Bergmann wrote:
> On Tuesday 04 June 2013 10:21:01 Michal Simek wrote:
>> On 06/03/2013 11:39 PM, Arnd Bergmann wrote:
>>> The emaclite driver now calls of_irq_to_resource, which is
>>> declared in linux/of_irq.h. Without this patch, I get a build
>>> error on ARM.
>>
>> What about to just change it to use platform_get_resource()?
>> I will test it.
> 
> Yes, that would work too. It seems the driver predates the automatic
> generation of resources for IRQs and MMIO registers.
> 
> If you change the IRQ resource to platform_get_resource, you should
> change the other one as well.

Yep. I have done that changes. Let me test them on real hw
and I will send them soon.

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: A bug about system call on ARM

[Will Deacon]

On Tue, Jun 04, 2013 at 06:33:20AM +0100, Wang, Yalin wrote:
> Hi  Will,

Hello,

> Could I know  what's your git branch is  mainly used for ?
> 
> https://git.kernel.org/cgit/linux/kernel/git/will/linux.git
> 
> 
> I mean if the branch is used for ARM arch maintenance ?

I send most of my patches via Russell, and the tree above is where I keep my
patches whilst they're not yet in mainline.

> If yes, I think I can send future bugs about ARM to you directly,
> And do not need ping-pang in the mail list .

Quite the opposite! Having discussions on the mailing list is key to how the
kernel is developed, so please continue to send questions, bug reports and
patches there. As has been pointed out previously in this thread, you need
to choose the right list in the first place, rather than just sending to
LKML.

Of course, you can always CC me on arm/arm64 patches if you like.

Cheers,

Will
--
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 v1 4/8] zram: destroy all devices on error recovery path in zram_init()

[Dan Carpenter]

Everyone stop putting RFC on their bugfixes!  :P  No one wants to
pre-review patches.

On Mon, Jun 03, 2013 at 11:42:16PM +0800, Jiang Liu wrote:
> On error recovery path of zram_init(), it leaks the zram device object
> causing the failure.
> 

This is a real bug but the fix isn't right.  The object causing the
failure has only been partially set up.  And in some cases it has
been partially cleaned up, for example we could end up releasing
->queue twice.

The better way is to make create_device() clean up after itself
completely instead of only partly and sometimes.

regards,
dan carpenter

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

[PATCH v2] mfd: DT bindings for the palmas family MFD

[J Keerthy]

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 regulators IP blocks on chips.

Signed-off-by: Graeme Gregory 
Signed-off-by: J Keerthy 
Signed-off-by: Ian Lartey 
---
Changes from v1:
* Corrected ti,ldo6_vibrator property ---> ti,ldo6-vibrator
* Added the irq.h header file inclusion for defining type of interrupt

 Documentation/devicetree/bindings/mfd/palmas.txt   |   49 +++
 .../devicetree/bindings/regulator/palmas-pmic.txt  |   65 
 2 files changed, 114 insertions(+), 0 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/mfd/palmas.txt
 create mode 100644 Documentation/devicetree/bindings/regulator/palmas-pmic.txt

diff --git a/Documentation/devicetree/bindings/mfd/palmas.txt 
b/Documentation/devicetree/bindings/mfd/palmas.txt
new file mode 100644
index 000..c6c5e78
--- /dev/null
+++ b/Documentation/devicetree/bindings/mfd/palmas.txt
@@ -0,0 +1,49 @@
+* palmas device tree bindings
+
+The TI palmas family current members :-
+twl6035 (palmas)
+twl6037 (palmas)
+tps65913 (palmas)
+tps65914 (palmas)
+
+Required properties:
+- compatible : Should be from the list
+  ti,twl6035
+  ti,twl6036
+  ti,twl6037
+  ti,tps65913
+  ti,tps65914
+  ti,tps80036
+and also the generic series names
+  ti,palmas
+- 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
+- interrupt-parent : The parent interrupt controller.
+
+Optional properties:
+  ti,mux_padX : set the pad register X (1-2) to the correct muxing for the
+   hardware, if not set will use muxing in OTP.
+
+Example:
+
+palmas {
+   compatible = "ti,twl6035", "ti,palmas";
+   reg = <0x48>
+   interrupt-parent = <&intc>;
+   interrupt-controller;
+   #interrupt-cells = <2>;
+
+   ti,mux-pad1 = <0>;
+   ti,mux-pad2 = <0>;
+
+   #address-cells = <1>;
+   #size-cells = <0>;
+
+   pmic {
+   compatible = "ti,twl6035-pmic", "ti,palmas-pmic";
+   
+   };
+}
diff --git a/Documentation/devicetree/bindings/regulator/palmas-pmic.txt 
b/Documentation/devicetree/bindings/regulator/palmas-pmic.txt
new file mode 100644
index 000..a0ccdf2
--- /dev/null
+++ b/Documentation/devicetree/bindings/regulator/palmas-pmic.txt
@@ -0,0 +1,65 @@
+* palmas regulator IP block devicetree bindings
+
+Required properties:
+- compatible : Should be from the list
+  ti,twl6035-pmic
+  ti,twl6036-pmic
+  ti,twl6037-pmic
+  ti,tps65913-pmic
+  ti,tps65914-pmic
+and also the generic series names
+  ti,palmas-pmic
+
+Optional properties:
+- ti,ldo6-vibrator : ldo6 is in vibrator mode
+
+Optional nodes:
+- regulators : should contain the constrains and init information for the
+  regulators. It should contain a subnode per regulator from the
+  list.
+  For ti,palmas-pmic - smps12, smps123, smps3 depending on OTP,
+  smps45, smps457, smps7 depending on varient, smps6, smps[8-10],
+  ldo[1-9], ldoln, ldousb
+
+  optional chip specific regulator fields :-
+  ti,warm-reset - maintain voltage during warm reset(boolean)
+  ti,roof-floor - control voltage selection by pin(boolean)
+  ti,sleep-mode - mode to adopt in pmic sleep 0 - off, 1 - auto,
+  2 - eco, 3 - forced pwm
+  ti,tstep - slope control 0 - Jump, 1 10mV/us, 2 5mV/us, 3 
2.5mV/us
+  ti,smps-range - OTP has the wrong range set for the hardware so 
override
+  0 - low range, 1 - high range
+
+Example:
+
+#include 
+
+pmic {
+   compatible = "ti,twl6035-pmic", "ti,palmas-pmic";
+   interrupt-parent = <&palmas>;
+   interrupts = <14 IRQ_TYPE_NONE>;
+   interrupt-name = "short-irq";
+
+   ti,ldo6-vibrator;
+
+   regulators {
+   smps12_reg : smps12 {
+   regulator-name = "smps12";
+   regulator-min-microvolt = < 60>;
+   regulator-max-microvolt = <150>;
+   regulator-always-on;
+   regulator-boot-on;
+   ti,warm-reset;
+   ti,roof-floor;
+   ti,mode-sleep = <0>;
+   ti,tstep = <0>;
+   ti,smps-range = <1>;
+   };
+
+   ldo1_reg: ldo1 {
+   regulator-name = "ldo1";
+   regulator-min-microvolt = <280>;
+   regulator-max-microvolt = <280>;
+   };
+   };
+};
-- 
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 m

[PATCH] cris: kgdb: use native hex2bin

[Andy Shevchenko]

There are kernel native helpers to convert hex ascii to the binary format:
hex_to_bin() and hex2bin(). Thus, no need to reimplement them customly.

Signed-off-by: Andy Shevchenko 
Cc: Geert Uytterhoeven 
---
 arch/cris/arch-v10/kernel/kgdb.c | 36 +++--
 arch/cris/arch-v32/kernel/kgdb.c | 57 +++-
 2 files changed, 14 insertions(+), 79 deletions(-)

diff --git a/arch/cris/arch-v10/kernel/kgdb.c b/arch/cris/arch-v10/kernel/kgdb.c
index 22d846b..dbd4ba8 100644
--- a/arch/cris/arch-v10/kernel/kgdb.c
+++ b/arch/cris/arch-v10/kernel/kgdb.c
@@ -413,18 +413,6 @@ gdb_cris_strtol (const char *s, char **endptr, int base)
 }
 
 /** Packet I/O **/
-/* Returns the integer equivalent of a hexadecimal character. */
-static int
-hex (char ch)
-{
-   if ((ch >= 'a') && (ch <= 'f'))
-   return (ch - 'a' + 10);
-   if ((ch >= '0') && (ch <= '9'))
-   return (ch - '0');
-   if ((ch >= 'A') && (ch <= 'F'))
-   return (ch - 'A' + 10);
-   return (-1);
-}
 
 /* Convert the memory, pointed to by mem into hexadecimal representation.
Put the result in buf, and return a pointer to the last character
@@ -455,22 +443,6 @@ mem2hex(char *buf, unsigned char *mem, int count)
return (buf);
 }
 
-/* Convert the array, in hexadecimal representation, pointed to by buf into
-   binary representation. Put the result in mem, and return a pointer to
-   the character after the last byte written. */
-static unsigned char*
-hex2mem (unsigned char *mem, char *buf, int count)
-{
-   int i;
-   unsigned char ch;
-   for (i = 0; i < count; i++) {
-   ch = hex (*buf++) << 4;
-   ch = ch + hex (*buf++);
-   *mem++ = ch;
-   }
-   return (mem);
-}
-
 /* Put the content of the array, in binary representation, pointed to by buf
into memory pointed to by mem, and return a pointer to the character after
the last byte written.
@@ -524,8 +496,8 @@ getpacket (char *buffer)
buffer[count] = '\0';

if (ch == '#') {
-   xmitcsum = hex (getDebugChar ()) << 4;
-   xmitcsum += hex (getDebugChar ());
+   xmitcsum = hex_to_bin(getDebugChar()) << 4;
+   xmitcsum += hex_to_bin(getDebugChar());
if (checksum != xmitcsum) {
/* Wrong checksum */
putDebugChar ('-');
@@ -760,7 +732,7 @@ handle_exception (int sigval)
   Each byte of register data  is described by 
two hex digits.
   Success: OK
   Failure: void. */
-   hex2mem((char *)&cris_reg, &remcomInBuffer[1], 
sizeof(registers));
+   hex2bin((char *)&cris_reg, &remcomInBuffer[1], 
sizeof(registers));
gdb_cris_strcpy (remcomOutBuffer, "OK");
break;

@@ -835,7 +807,7 @@ handle_exception (int sigval)
int length = gdb_cris_strtol(lenptr+1, 
&dataptr, 16);
if (*lenptr == ',' && *dataptr == ':') {
if (remcomInBuffer[0] == 'M') {
-   hex2mem(addr, dataptr + 
1, length);
+   hex2bin(addr, dataptr + 
1, length);
}
else /* X */ {
bin2mem(addr, dataptr + 
1, length);
diff --git a/arch/cris/arch-v32/kernel/kgdb.c b/arch/cris/arch-v32/kernel/kgdb.c
index b06813a..590c11b 100644
--- a/arch/cris/arch-v32/kernel/kgdb.c
+++ b/arch/cris/arch-v32/kernel/kgdb.c
@@ -384,19 +384,11 @@ int getDebugChar(void);
 /* Serial port, writes one character. ETRAX 100 specific. from debugport.c */
 void putDebugChar(int val);
 
-/* Returns the integer equivalent of a hexadecimal character. */
-static int hex(char ch);
-
 /* Convert the memory, pointed to by mem into hexadecimal representation.
Put the result in buf, and return a pointer to the last character
in buf (null). */
 static char *mem2hex(char *buf, unsigned char *mem, int count);
 
-/* Convert the array, in hexadecimal representation, pointed to by buf into
-   binary representation. Put the result in mem, and return a pointer to
-   the character after the last byte written. */
-static unsigned char *hex2mem(unsigned char *mem, char *buf, int count);
-
 /* Put the content of the array, in binary representation, pointed to by buf
into memory pointed to by mem, and return a pointer to
the character after the last 

Re: [PATCH v8 net-next 5/7] net: simple poll/select low latency socket poll

[Eliezer Tamir]

On 03/06/2013 16:59, Eliezer Tamir wrote:

On 03/06/2013 16:15, Eric Dumazet wrote:

On Mon, 2013-06-03 at 11:02 +0300, Eliezer Tamir wrote:

  sock = file->private_data;
-return sock->ops->poll(file, sock, wait);
+
+poll_result = sock->ops->poll(file, sock, wait);
+
+if (!(poll_result & (POLLRDNORM | POLLERR | POLLRDHUP |
POLLHUP)) &&
+sk_valid_ll(sock->sk) && sk_poll_ll(sock->sk, 1))
+poll_result = sock->ops->poll(file, sock, NULL);
+
+return poll_result;
  }

  static int sock_mmap(struct file *file, struct vm_area_struct *vma)




In fact, for TCP, POLLOUT event being ready can also be triggered by
incoming messages, as the ACK might allow the user application to push
more data in the write queue.

And you might check wait->_key to avoid testing flags that user is not
interested into.


yes, comparing to _key is more correct.
In any case this needs to be completely rewritten for support for
working well with a large number of sockets.



Is it possible for wait to be NULL? (do we need to check for that?)
I see that poll_does_not_wait() checks for that, but I could not find
anywhere this is actually done.

-Eliezer

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

Re: [PATCH RFC -tip 0/6] perf: IRQ-bound performance events

[Jiri Olsa]

On Mon, Jun 03, 2013 at 09:41:21PM +0200, Frederic Weisbecker wrote:
> On Mon, Jun 03, 2013 at 02:22:23PM +0200, Ingo Molnar wrote:
> > 
> > * Alexander Gordeev  wrote:

SNIP

> How about we define finegrained context on top of perf events themselves?
> Like we could tell perf to count a task's instructions only after
> tracepoint:irq_entry is hit and stop counting when tracepoint:irq_exit.
> 
> This way we can define any kind of fine grained context, not just irqs. We
> are not short on tracepoints, software events, breakpoints, kprobes, uprobes
> to play Legos there.

agreed, we could do the same as Alex did plus we'd have
the generic interface to meassure any place

> 
> I had a branch with a working draft of that:
> 
>   git://git.kernel.org/pub/scm/linux/kernel/git/frederic/linux-dynticks.git
>   perf/custom-ctx-v2-pre
> 
> Frederic Weisbecker (5):
>   perf: Starter and stopper events
>   perf: New enable_on_starter attribute
>   perf: Support for starter and stopper in tools
>   perf: New --enable-on-starter option
>   perf: Add TODOs for event defined context
> 
> It needs quite some improvements, (some are listed in the TODO on the last 
> commit)
> especially in both the kernel and user interfaces.
> 
> Jiri had some nice ideas about it.

yep, one of them is to to get back to this soon ;-)

jirka
--
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] ARM: ux500: Reduce PRCMU reg-names to shorter form for u8540 DT

[Linus Walleij]

On Thu, May 30, 2013 at 10:31 AM, Lee Jones  wrote:

> After some discussion and deliberation we have decided to only use the
> short form of the PRCMU register names i.e. not mention the peripheral
> in which the registers reside.
>
> Signed-off-by: Lee Jones 

Patch applied.

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

Re: [PATCH v4 2/6] staging: android: binder: fix binder interface for 64bit compat layer

[Serban Constantinescu]

On 03/06/13 22:41, Arve Hjønnevåg wrote:

On Wed, May 22, 2013 at 3:12 AM, Serban Constantinescu
 wrote:

The changes in this patch will fix the binder interface for use on 64bit
machines and stand as the base of the 64bit compat support. The changes
apply to the structures that are passed between the kernel and
userspace.

Most of the  changes applied mirror the change to struct binder_version
where there is no need for a 64bit wide protocol_version(on 64bit
machines). The change inlines with the existing 32bit userspace(the
structure has the same size) and simplifies the compat layer such that
the same handler can service the BINDER_VERSION ioctl.

Other changes make use of kernel types as well as user-exportable ones
and fix format specifier issues.

The changes do not affect existing 32bit ABI.

Signed-off-by: Serban Constantinescu 
---
  drivers/staging/android/binder.c |   20 ++--
  drivers/staging/android/binder.h |8 
  2 files changed, 14 insertions(+), 14 deletions(-)

diff --git a/drivers/staging/android/binder.c b/drivers/staging/android/binder.c
index ce70909..ca79084 100644
--- a/drivers/staging/android/binder.c
+++ b/drivers/staging/android/binder.c
@@ -1271,7 +1271,7 @@ static void binder_transaction_buffer_release(struct 
binder_proc *proc,
 case BINDER_TYPE_WEAK_HANDLE: {
 struct binder_ref *ref = binder_get_ref(proc, 
fp->handle);
 if (ref == NULL) {
-   pr_err("transaction release %d bad handle 
%ld\n",
+   pr_err("transaction release %d bad handle %d\n",
  debug_id, fp->handle);
 break;
 }
@@ -1283,13 +1283,13 @@ static void binder_transaction_buffer_release(struct 
binder_proc *proc,

 case BINDER_TYPE_FD:
 binder_debug(BINDER_DEBUG_TRANSACTION,
-"fd %ld\n", fp->handle);
+"fd %d\n", fp->handle);
 if (failed_at)
 task_close_fd(proc, fp->handle);
 break;

 default:
-   pr_err("transaction release %d bad object type %lx\n",
+   pr_err("transaction release %d bad object type %x\n",
 debug_id, fp->type);
 break;
 }
@@ -1547,7 +1547,7 @@ static void binder_transaction(struct binder_proc *proc,
 case BINDER_TYPE_WEAK_HANDLE: {
 struct binder_ref *ref = binder_get_ref(proc, 
fp->handle);
 if (ref == NULL) {
-   binder_user_error("%d:%d got transaction with 
invalid handle, %ld\n",
+   binder_user_error("%d:%d got transaction with 
invalid handle, %d\n",
 proc->pid,
 thread->pid, fp->handle);
 return_error = BR_FAILED_REPLY;
@@ -1590,13 +1590,13 @@ static void binder_transaction(struct binder_proc *proc,

 if (reply) {
 if (!(in_reply_to->flags & TF_ACCEPT_FDS)) {
-   binder_user_error("%d:%d got reply with fd, 
%ld, but target does not allow fds\n",
+   binder_user_error("%d:%d got reply with fd, 
%d, but target does not allow fds\n",
 proc->pid, thread->pid, 
fp->handle);
 return_error = BR_FAILED_REPLY;
 goto err_fd_not_allowed;
 }
 } else if (!target_node->accept_fds) {
-   binder_user_error("%d:%d got transaction with fd, 
%ld, but target does not allow fds\n",
+   binder_user_error("%d:%d got transaction with fd, 
%d, but target does not allow fds\n",
 proc->pid, thread->pid, fp->handle);
 return_error = BR_FAILED_REPLY;
 goto err_fd_not_allowed;
@@ -1604,7 +1604,7 @@ static void binder_transaction(struct binder_proc *proc,

 file = fget(fp->handle);
 if (file == NULL) {
-   binder_user_error("%d:%d got transaction with 
invalid fd, %ld\n",
+   binder_user_error("%d:%d got transaction with 
invalid fd, %d\n",
 proc->pid, thread->pid, fp->handle);
 return_error = BR_FAILED_REPLY;
 goto err_fget_failed;
@@ -1618,13 +16

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

[Peng Tao]

On Tue, Jun 4, 2013 at 1:42 PM, Greg KH  wrote:
> On Tue, Jun 04, 2013 at 02:57:00PM +1000, Stephen Rothwell wrote:
>> Hi Greg,
>>
>> After merging the staging tree, today's linux-next build (x86_64
>> allmodconfig) failed like this:
>>
>> In file included from 
>> drivers/staging/lustre/lustre/fid/../include/linux/lustre_compat25.h:44:0,
>>  from 
>> drivers/staging/lustre/lustre/fid/../include/linux/lvfs.h:48,
>>  from drivers/staging/lustre/lustre/fid/../include/lvfs.h:45,
>>  from 
>> drivers/staging/lustre/lustre/fid/../include/obd_support.h:41,
>>  from 
>> drivers/staging/lustre/lustre/fid/../include/linux/obd.h:44,
>>  from drivers/staging/lustre/lustre/fid/../include/obd.h:40,
>>  from drivers/staging/lustre/lustre/fid/fid_store.c:48:
>> drivers/staging/lustre/lustre/fid/../include/linux/lustre_patchless_compat.h:
>>  In function 'truncate_complete_page':
>> drivers/staging/lustre/lustre/fid/../include/linux/lustre_patchless_compat.h:56:3:
>>  error: too few arguments to function 'page->mapping->a_ops->invalidatepage'
>>page->mapping->a_ops->invalidatepage(page, 0);
>>^
>>
>> Lots of times.
>>
>> Caused by the Lustre client patches interacting with commit d47992f86b30
>> ("mm: change invalidatepage prototype to accept length") from the ext4
>> tree.
>>
>> I added this merge fix patch:
>>
>> From 3873636f50eb89ba5e4f8e4e0523fd62f681edc8 Mon Sep 17 00:00:00 2001
>> From: Stephen Rothwell 
>> Date: Tue, 4 Jun 2013 14:41:00 +1000
>> Subject: [PATCH] staging/lustre: fix for invalidatepage() API change
>>
>> Signed-off-by: Stephen Rothwell 
>> ---
>>  drivers/staging/lustre/lustre/include/linux/lustre_patchless_compat.h | 2 +-
>>  1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git 
>> a/drivers/staging/lustre/lustre/include/linux/lustre_patchless_compat.h 
>> b/drivers/staging/lustre/lustre/include/linux/lustre_patchless_compat.h
>> index f050808..67c4644 100644
>> --- a/drivers/staging/lustre/lustre/include/linux/lustre_patchless_compat.h
>> +++ b/drivers/staging/lustre/lustre/include/linux/lustre_patchless_compat.h
>> @@ -53,7 +53,7 @@ truncate_complete_page(struct address_space *mapping, 
>> struct page *page)
>>   return;
>>
>>   if (PagePrivate(page))
>> - page->mapping->a_ops->invalidatepage(page, 0);
>> + page->mapping->a_ops->invalidatepage(page, 0, PAGE_CACHE_SIZE);
>>
>>   cancel_dirty_page(page, PAGE_SIZE);
>>   ClearPageMappedToDisk(page);
>> --
>> 1.8.1
>>
>> diff --git a/drivers/staging/lustre/lustre/llite/rw26.c 
>> b/drivers/staging/lustre/lustre/llite/rw26.c
>> index 27e4e64..f1a1c5f 100644
>> --- a/drivers/staging/lustre/lustre/llite/rw26.c
>> +++ b/drivers/staging/lustre/lustre/llite/rw26.c
>> @@ -72,7 +72,8 @@
>>   * aligned truncate). Lustre leaves partially truncated page in the cache,
>>   * relying on struct inode::i_size to limit further accesses.
>>   */
>> -static void ll_invalidatepage(struct page *vmpage, unsigned long offset)
>> +static void ll_invalidatepage(struct page *vmpage, unsigned int offset,
>> +   unsigned int length)
>>  {
>>   struct inode *inode;
>>   struct lu_env*env;
>> @@ -89,7 +90,7 @@ static void ll_invalidatepage(struct page *vmpage, 
>> unsigned long offset)
>>* below because they are run with page locked and all our io is
>>* happening with locked page too
>>*/
>> - if (offset == 0) {
>> + if (offset == 0 && length == PAGE_CACHE_SIZE) {
>>   env = cl_env_get(&refcheck);
>>   if (!IS_ERR(env)) {
>>   inode = vmpage->mapping->host;
>
> That patch makes sense.
>
> But then:
>
>> But then got these errors:
>>
>> drivers/staging/lustre/lustre/libcfs/linux/linux-cpu.c: In function 
>> 'cfs_cpt_bind':
>> drivers/staging/lustre/lustre/libcfs/linux/linux-cpu.c:630:3: error: 
>> implicit declaration of function 'set_cpus_allowed' 
>> [-Werror=implicit-function-declaration]
>>rc = set_cpus_allowed(current, *cpumask);
>>^
>> cc1: some warnings being treated as errors
>> drivers/staging/lustre/lustre/obdclass/lu_object.c: In function 'key_fini':
>> drivers/staging/lustre/lustre/obdclass/lu_object.c:1354:4: error: implicit 
>> declaration of function 'module_refcount' 
>> [-Werror=implicit-function-declaration]
>> LINVRNT(module_refcount(key->lct_owner) > 0);
>> ^
>> In file included from 
>> drivers/staging/lustre/include/linux/libcfs/libcfs.h:203:0,
>>  from drivers/staging/lustre/lustre/obdclass/lu_object.c:47:
>> drivers/staging/lustre/lustre/obdclass/lu_object.c: In function 
>> 'lu_context_keys_dump':
>> drivers/staging/lustre/lustre/obdclass/lu_object.c:1936:42: error: 
>> dereferencing pointer to incomplete type
>>key->lct_owner ? key->lct_owner->name : "",
>>   ^
>> drivers/staging/lustre/include/lin

Re: [PATCH 1/4] ARM: ux540: Add ccu8540-uib-v3 Device Tree Machine

[Linus Walleij]

On Thu, May 30, 2013 at 3:20 PM, Gabriel Fernandez
 wrote:

[Lee]
>> Is it a new board, or just a UIB?
>
> For me it's a new board.
>
> ccu8540.dts is a board without uib.
> You can can plug on this board some different uibs.
> That's why, i created a ccu8540-uib-v3.dts board in which i included a
> common board ccu8540.dts

So that means that ccu8540.dts will boot the system even
without any UIB if I understand correctly. Anything that
pertains to the UIB should be in the UIB overlay.

> Another solution is to create one *.dtsi file with all uibs for
> ccu8540 and makes a dynamique detection.
> Linus, Lee  what do you think about that ?

I'm lost on this, dynamic detection would be done in the
boot loader, usually this just encodes one, static tree.

The first approach seems OK with me.

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

Re: [PATCH 1/5] ARM: ux500: Fix trivial typo in v-anamic1 comment

[Linus Walleij]

On Thu, May 30, 2013 at 3:27 PM, Fabio Baltieri
 wrote:

> Fix VAMIC1 LDO comment in DT files to be make it coherent with the
> others.
>
> Signed-off-by: Fabio Baltieri 

Patch applied to my ux500-devicetree branch.

Yours,
Linus Walleij
--
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/5] ARM: ux500: Correct anamic2 typo in DT files

[Linus Walleij]

On Thu, May 30, 2013 at 3:27 PM, Fabio Baltieri
 wrote:

> Fix typo of VAMIC2 LDO regulator name in some DT-related files.  This
> patch replaces all occurrences with the right name.
>
> Signed-off-by: Fabio Baltieri 

Patch applied to my ux500-devicetree branch.

Yours,
Linus Walleij
--
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/5] ARM: ux500: Add DT regulators for ab8500-codec

[Linus Walleij]

On Thu, May 30, 2013 at 3:27 PM, Fabio Baltieri
 wrote:

> Add regulator DT bindings for the ab8500-codec driver.
>
> Signed-off-by: Fabio Baltieri 

Patch applied to my ux500-devicetree branch.

Yours,
Linus Walleij
--
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 v1 0/8] small bugfixes and code improvements for zram

[Minchan Kim]

Hello,

On Mon, Jun 03, 2013 at 11:42:12PM +0800, Jiang Liu wrote:
> This patchset is to fix issues in zram found by code inspection.
> There is still one more issue left: should we repalce zram_stat64_xxx()
> with atomic64_xxx()?
> 
> Jiang Liu (8):
>   zram: simplify and optimize zram_to_dev()
>   zram: avoid invalid memory access in zram_exit()
>   zram: use zram->lock to protect zram_free_page() in swap free notify
> path
>   zram: destroy all devices on error recovery path in zram_init()
>   zram: avoid double free in error recovery path of zram_bvec_write()
>   zram: avoid access beyond the zram device
>   zram: optimize memory operations with clear_page()/copy_page()
>   zram: protect sysfs handler from invalid memory access

I reviewed your patchset roughly and I feel most of patches make sense
to me but some of that isn't not sure because you didn't write up the
possible scenario, expecially "zram: use zram->lock to protect zram_free_page()
in swap free notify path".

If your patchset fix real problem, it should go to the stable tree so
you need to write description up in detail.

So, please rewrite up description on all of patches and resend.
Thanks!
-- 
Kind regards,
Minchan Kim
--
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 8/8] powerpc/pseries: Read common partition via pstore

[Aruna Balakrishnaiah]

On Saturday 01 June 2013 10:22 AM, Benjamin Herrenschmidt wrote:

On Thu, 2013-04-25 at 15:49 +0530, Aruna Balakrishnaiah wrote:


diff --git a/fs/pstore/inode.c b/fs/pstore/inode.c
index 8d4fb65..88cc050 100644
--- a/fs/pstore/inode.c
+++ b/fs/pstore/inode.c
@@ -330,6 +330,9 @@ int pstore_mkfile(enum pstore_type_id type, char *psname, 
u64 id, int count,
case PSTORE_TYPE_PPC_OF:
sprintf(name, "of-%s-%lld", psname, id);
break;

Call this powerpc-ofw-... Does it even contain something we use in Linux
at all ? Last I looked we only used the common one right ? Also it's
format afaik is defined in the CHRP bindings so it's not generic OFW
stuff, hence the powerpc prefix.


+   case PSTORE_TYPE_PPC_COMMON:
+   sprintf(name, "common-%s-%lld", psname, id);
+   break;

Same deal, call that powerpc-common


Sure. Will change it to powerpc prefix.


case PSTORE_TYPE_UNKNOWN:
sprintf(name, "unknown-%s-%lld", psname, id);
break;
diff --git a/include/linux/pstore.h b/include/linux/pstore.h
index 615dc18..656699f 100644
--- a/include/linux/pstore.h
+++ b/include/linux/pstore.h
@@ -38,6 +38,7 @@ enum pstore_type_id {
/* PPC64 partition types */
PSTORE_TYPE_PPC_RTAS= 4,
PSTORE_TYPE_PPC_OF  = 5,
+   PSTORE_TYPE_PPC_COMMON  = 6,
PSTORE_TYPE_UNKNOWN = 255
  };

Do we expose anything else or keep it hidden ?


We are exposing oops, rtas, of-config and common partition of nvram.


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: [RFC PATCH v1 2/8] zram: avoid invalid memory access in zram_exit()

[Minchan Kim]

On Mon, Jun 03, 2013 at 11:42:14PM +0800, Jiang Liu wrote:
> Memory for zram->disk object may have already been freed after returning
> from destroy_device(zram), then it's unsafe for zram_reset_device(zram)
> to access zram->disk again.
> 
> Fix it by holding an extra reference to zram->disk before calling
> destroy_device(zram).
> 
> Signed-off-by: Jiang Liu 
> ---
>  drivers/staging/zram/zram_drv.c | 2 ++
>  1 file changed, 2 insertions(+)
> 
> diff --git a/drivers/staging/zram/zram_drv.c b/drivers/staging/zram/zram_drv.c
> index e34e3fe..ee6b67d 100644
> --- a/drivers/staging/zram/zram_drv.c
> +++ b/drivers/staging/zram/zram_drv.c
> @@ -727,8 +727,10 @@ static void __exit zram_exit(void)
>   for (i = 0; i < num_devices; i++) {
>   zram = &zram_devices[i];
>  
> + get_disk(zram->disk);
>   destroy_device(zram);
>   zram_reset_device(zram);
> + put_disk(zram->disk);

Can't we simple reverse calling order of above two functions?

zram_reset_device(zram);
destroy_device(zram);

-- 
Kind regards,
Minchan Kim
--
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 4/5] ARM: ux500: Provide auxdata to ux500 ASoC driver

[Linus Walleij]

On Thu, May 30, 2013 at 3:27 PM, Fabio Baltieri
 wrote:

> Ux500 ASoC driver is expected to have a specific device name to get
> clock resources correctly.  This patch provides the necessary
> OF_DEV_AUXDATA to match the name in DT and non-DT cases.
>
> Signed-off-by: Fabio Baltieri 

Patch applied to my ux500-devicetree branch after some rebasing.

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

Re: [PATCH 5/5] mfd: ab8500-core: Add of_compatible property for ab8500-codec

[Linus Walleij]

On Thu, May 30, 2013 at 3:27 PM, Fabio Baltieri
 wrote:

> Add of_compatible string to the ab8500-codec cell to allow the driver to
> grab handlers such as regulators from device-tree when available.
>
> Signed-off-by: Fabio Baltieri 

Acked-by: Linus Walleij 

I think Lee is queueing ab8500 patches for Sam these days
to smoothen things, so letting him pick this up.

Yours,
Linus Walleij
--
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/1] KVM: add kvm_para_available to asm-generic/kvm_para.h

[Gleb Natapov]

On Wed, May 22, 2013 at 12:29:22PM +0100, James Hogan wrote:
> According to include/uapi/linux/kvm_para.h architectures should define
> kvm_para_available, so add an implementation to asm-generic/kvm_para.h
> which just returns false.
> 
What is this fixing? The only user of kvm_para_available() that can
benefit from this is in sound/pci/intel8x0.c, but I do not see follow up
patch to use it there.

> Signed-off-by: James Hogan 
> Cc: Marcelo Tosatti 
> Cc: Gleb Natapov 
> Cc: Arnd Bergmann 
> ---
>  include/asm-generic/kvm_para.h | 5 +
>  1 file changed, 5 insertions(+)
> 
> diff --git a/include/asm-generic/kvm_para.h b/include/asm-generic/kvm_para.h
> index 9d96605..fa25bec 100644
> --- a/include/asm-generic/kvm_para.h
> +++ b/include/asm-generic/kvm_para.h
> @@ -18,4 +18,9 @@ static inline unsigned int kvm_arch_para_features(void)
>   return 0;
>  }
>  
> +static inline bool kvm_para_available(void)
> +{
> + return false;
> +}
> +
>  #endif
> -- 
> 1.8.1.2
> 

--
Gleb.
--
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] Various DT fixes related to ux500 ASoC driver

[Linus Walleij]

On Thu, May 30, 2013 at 4:53 PM, Lee Jones  wrote:

> All look good to me.
>
> For patches 1-4:
>
> Acked-by: Lee Jones 

OK added this.

> For patch 5:
> Applied thanks.

Thanks!

Yours,
Linus Walleij
--
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] powerpc/pseries: Support compression of oops text via pstore

[Aruna Balakrishnaiah]

Hi Ben,

On Saturday 01 June 2013 10:24 AM, Benjamin Herrenschmidt wrote:

On Fri, 2013-04-26 at 15:26 +0530, Aruna Balakrishnaiah wrote:

The patch set supports compression of oops messages while writing to NVRAM,
this helps in capturing more of oops data to lnx,oops-log. The pstore file
for oops messages will be in decompressed format making it readable.

In case compression fails, the patch takes care of copying the header added
by pstore and last oops_data_sz bytes of big_oops_buf to NVRAM so that we
have recent oops messages in lnx,oops-log.

In case decompression fails, it will result in absence of oops file but still
have files (in /dev/pstore) for other partitions.

Any reason that isn't handled by pstore itself rather than here ? Ie
make a flag indicating that the partition supports compression and have
pstore do it (so we don't compress everything such as ofw common etc...)

Cheers,
Ben.



Since pstore does not have the compression support, I planned to reuse the
existing compression code in nvram but later we can add compression support
to pstore so that other platforms can make use of it.

Regards,
Aruna


Signed-off-by: Aruna Balakrishnaiah 
---
  arch/powerpc/platforms/pseries/nvram.c |  132 +---
  1 file changed, 118 insertions(+), 14 deletions(-)

diff --git a/arch/powerpc/platforms/pseries/nvram.c 
b/arch/powerpc/platforms/pseries/nvram.c
index 0159d74..b5ba5e2 100644
--- a/arch/powerpc/platforms/pseries/nvram.c
+++ b/arch/powerpc/platforms/pseries/nvram.c
@@ -539,6 +539,65 @@ static int zip_oops(size_t text_len)
  }
  
  #ifdef CONFIG_PSTORE

+/* Derived from logfs_uncompress */
+int nvram_decompress(void *in, void *out, size_t inlen, size_t outlen)
+{
+   int err, ret;
+
+   ret = -EIO;
+   err = zlib_inflateInit(&stream);
+   if (err != Z_OK)
+   goto error;
+
+   stream.next_in = in;
+   stream.avail_in = inlen;
+   stream.total_in = 0;
+   stream.next_out = out;
+   stream.avail_out = outlen;
+   stream.total_out = 0;
+
+   err = zlib_inflate(&stream, Z_FINISH);
+   if (err != Z_STREAM_END)
+   goto error;
+
+   err = zlib_inflateEnd(&stream);
+   if (err != Z_OK)
+   goto error;
+
+   ret = stream.total_out;
+error:
+   return ret;
+}
+
+static int unzip_oops(char *oops_buf, char *big_buf)
+{
+   struct oops_log_info *oops_hdr = (struct oops_log_info *)oops_buf;
+   u64 timestamp = oops_hdr->timestamp;
+   char *big_oops_data = NULL;
+   char *oops_data_buf = NULL;
+   size_t big_oops_data_sz;
+   int unzipped_len;
+
+   big_oops_data = big_buf + sizeof(struct oops_log_info);
+   big_oops_data_sz = big_oops_buf_sz - sizeof(struct oops_log_info);
+   oops_data_buf = oops_buf + sizeof(struct oops_log_info);
+
+   unzipped_len = nvram_decompress(oops_data_buf, big_oops_data,
+   oops_hdr->report_length,
+   big_oops_data_sz);
+
+   if (unzipped_len < 0) {
+   pr_err("nvram: decompression failed; returned %d\n",
+   unzipped_len);
+   return -1;
+   }
+   oops_hdr = (struct oops_log_info *)big_buf;
+   oops_hdr->version = OOPS_HDR_VERSION;
+   oops_hdr->report_length = (u16) unzipped_len;
+   oops_hdr->timestamp = timestamp;
+   return 0;
+}
+
  static int nvram_pstore_open(struct pstore_info *psi)
  {
/* Reset the iterator to start reading partitions again */
@@ -567,6 +626,7 @@ static int nvram_pstore_write(enum pstore_type_id type,
size_t size, struct pstore_info *psi)
  {
int rc;
+   unsigned int err_type = ERR_TYPE_KERNEL_PANIC;
struct oops_log_info *oops_hdr = (struct oops_log_info *) oops_buf;
  
  	/* part 1 has the recent messages from printk buffer */

@@ -577,8 +637,31 @@ static int nvram_pstore_write(enum pstore_type_id type,
oops_hdr->version = OOPS_HDR_VERSION;
oops_hdr->report_length = (u16) size;
oops_hdr->timestamp = get_seconds();
+
+   if (big_oops_buf) {
+   rc = zip_oops(size);
+   /*
+* If compression fails copy recent log messages from
+* big_oops_buf to oops_data.
+*/
+   if (rc != 0) {
+   int hsize = pstore_get_header_size();
+   size_t diff = size - oops_data_sz + hsize;
+
+   if (size > oops_data_sz) {
+   memcpy(oops_data, big_oops_buf, hsize);
+   memcpy(oops_data + hsize, big_oops_buf + diff,
+   oops_data_sz - hsize);
+
+   oops_hdr->report_length = (u16) oops_data_sz;
+   } else
+   memcpy(oops_data, big_oops_buf, s

Re: [RFC PATCH] regulator: palmas: enable all modes for SMPS10

[Kishon Vijay Abraham I]

Hi,

On Sunday 02 June 2013 02:35 AM, Mark Brown wrote:

On Sun, Jun 02, 2013 at 12:33:10AM +0530, Laxman Dewangan wrote:

On Sunday 02 June 2013 12:15 AM, Mark Brown wrote:



No, that makes no sense at all to me.  Why do you think this maps onto
the set mode API?  Modes are all about accuracy of regulation.



I mapped this to the regulation under different load, Fast mode is
in heavy load and so boost enable, normal/idle mode for normal load
and so bypass.


This is still not making any sense.  The quality of regulation and
output voltage are essentially orthogonal, and obviously there's a
specific API for bypass which is something different again to both
mode and output voltage selection.


Do you recommend adding API's (similar to bypass) for BOOST and SWITCH?

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

**Short Note**

[info]

Your Email-ID has been Granted £1,000,000.00 Pounds in Uk National  Lottery, To 
Receive, Send Your Name: Address: Telephone: Country to email: 
claims.jonesgre...@hotmail.co.uk


--
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()

[Linus Walleij]

On Thu, May 30, 2013 at 7:33 PM, Vinod Koul  wrote:
> On Thu, May 30, 2013 at 09:41:38AM +0200, Linus Walleij wrote:
>> On Thu, May 30, 2013 at 6:32 AM, Wei Yongjun  wrote:
>>
>> > 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 
>> > ---
>> > v1 -> v2: rebased on linux-next.git
>>
>> I've tentatively applied this to my dma40 branch, waiting for Vinod
>> to ACK it.
> I though you wanted me to apply this :)
>
> Nevertheless, Acked-by: Vinod Koul 
>
> Can you CC stable too, pls.

Hm I'm not sending any DMA40 stuff for stable, sorry ...
if you want it to go into stable you'd better pick this
(the v3 version) into the DMA tree.

Let me know how you want it, I've removed it from my
dma40 branch for the time being.

Yours,
Linus Walleij
--
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] ARM: ux500: Allocate correct amount of memory for the u8540 in DT

[Linus Walleij]

On Fri, May 31, 2013 at 5:15 PM, Lee Jones  wrote:

> As it stands, the memory node in the u8540 Device Tree is ignored and
> memory is actually stipulated by the bootloader via ATAGS. ARM core
> architecture code then extracts the memory ATAG and inserts it into the
> Device Tree. In the u8540 the LittleKernel bootloader only stipulates
> 512MB of memory; however, the u8540 actually has 2GB. We're taking the
> responsibility to register the remainder from Device Tree here.
>
> Signed-off-by: Lee Jones 

Patch applied to my ux500-devicetree branch.

Yours,
Linus Walleij
--
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: [RESEND][PATCH 3/7] net, ipw2x00: remove redundant D0 power state set

[Stanislav Yakovlev]

Hi Yijing,

On 4 June 2013 00:07, Yijing Wang  wrote:
> Pci_enable_device() will set device power state to D0,
> so it's no need to do it again in ipw2100_pci_init_one().
>
> Signed-off-by: Yijing Wang 
> Cc: Stanislav Yakovlev 
> Cc: "John W. Linville" 
> Cc: net...@vger.kernel.org
> Cc: linux-wirel...@vger.kernel.org

Looks fine, thanks.

Stanislav.
--
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] mm, memcg: add oom killer delay

[Michal Hocko]

On Mon 03-06-13 14:30:18, Johannes Weiner wrote:
> On Mon, Jun 03, 2013 at 12:48:39PM -0400, Johannes Weiner wrote:
> > On Mon, Jun 03, 2013 at 05:34:32PM +0200, Michal Hocko wrote:
[...]
> > > I am just afraid about all the other archs that do not support (from
> > > quick grep it looks like: blackfin, c6x, h8300, metag, mn10300,
> > > openrisc, score and tile). What would be an alternative for them?
> > > #ifdefs for the old code (something like ARCH_HAS_FAULT_OOM_RETRY)? This
> > > would be acceptable for me.
> > 
> > blackfin is NOMMU but I guess the others should be converted to the
> > proper OOM protocol anyway and not just kill the faulting task.  I can
> > update them in the next version of the patch (series).
> 
> It's no longer necessary since I remove the arch-specific flag
> setting, but I converted them anyway while I was at it.  Will send
> them as a separate patch.

I am still not sure doing this unconditionally is the right way. Say
that a new arch will be added. How the poor implementer knows that memcg
oom handling requires an arch specific code to work properly?

So while I obviously do not have anything agains your conversion of
other archs that are in the tree currently I think we need something
like CONFIG_OLD_VERSION_MEMCG_OOM which depends on ARCH_HAS_FAULT_OOM_RETRY.

[...]
> > > > diff --git a/include/linux/sched.h b/include/linux/sched.h
> > > > index e692a02..cf60aef 100644
> > > > --- a/include/linux/sched.h
> > > > +++ b/include/linux/sched.h
> > > > @@ -1282,6 +1282,8 @@ struct task_struct {
> > > >  * execve */
> > > > unsigned in_iowait:1;
> > > >  
> > > > +   unsigned in_userfault:1;
> > > > +
> > > 
> > > [This is more a nit pick but before I forget while I am reading through
> > > the rest of the patch.]
> > > 
> > > OK there is a lot of room around those bit fields but as this is only
> > > for memcg and you are enlarging the structure by the pointer then you
> > > can reuse bottom bit of memcg pointer.
> > 
> > I just didn't want to put anything in the arch code that looks too
> > memcgish, even though it's the only user right now.  But granted, it
> > will also probably remain the only user for a while.
> 
> I tried a couple of variants, including using the lowest memcg bit,
> but it all turned into more ugliness.  So that .in_userfault is still
> there in v2, but it's now set in handle_mm_fault() in a generic manner
> depending on a fault flag, please reconsider if you can live with it.

Sure thing.

[...]
> From: Johannes Weiner 
> Subject: [PATCH] memcg: do not sleep on OOM waitqueue with full charge context
> 
> The memcg OOM handling is incredibly fragile because once a memcg goes
> OOM, one task (kernel or userspace) is responsible for resolving the
> situation.  Every other task that gets caught trying to charge memory
> gets stuck in a waitqueue while potentially holding various filesystem
> and mm locks on which the OOM handling task may now deadlock.
> 
> Do two things:
> 
> 1. When OOMing in a system call (buffered IO and friends), invoke the
>OOM killer but do not trap other tasks and just return -ENOMEM for
>everyone.  Userspace should be able to handle this... right?
> 
> 2. When OOMing in a page fault, invoke the OOM killer but do not trap
>other chargers directly in the charging code.  Instead, remember
>the OOMing memcg in the task struct and then fully unwind the page
>fault stack first.  Then synchronize the memcg OOM from
>pagefault_out_of_memory().
> 
> While reworking the OOM routine, also remove a needless OOM waitqueue
> wakeup when invoking the killer.  Only uncharges and limit increases,
> things that actually change the memory situation, should do wakeups.
> 
> Signed-off-by: Johannes Weiner 
> ---
>  include/linux/memcontrol.h |   6 +++
>  include/linux/mm.h |   1 +
>  include/linux/sched.h  |   6 +++
>  mm/ksm.c   |   2 +-
>  mm/memcontrol.c| 117 
> +++--
>  mm/memory.c|  40 +++-
>  mm/oom_kill.c  |   7 ++-
>  7 files changed, 108 insertions(+), 71 deletions(-)
> 
[...]
> diff --git a/mm/memcontrol.c b/mm/memcontrol.c
> index de22292..97cf32b 100644
> --- a/mm/memcontrol.c
> +++ b/mm/memcontrol.c
[...]
> @@ -2179,56 +2181,72 @@ static void memcg_oom_recover(struct mem_cgroup 
> *memcg)
>  }
>  
>  /*
> - * try to call OOM killer. returns false if we should exit memory-reclaim 
> loop.
> + * try to call OOM killer
>   */
> -static bool mem_cgroup_handle_oom(struct mem_cgroup *memcg, gfp_t mask,
> -   int order)
> +static void mem_cgroup_oom(struct mem_cgroup *memcg, gfp_t mask, int order)
>  {
> - struct oom_wait_info owait;
> - bool locked, need_to_kill;
> -
> - owait.memcg = memcg;
> - owait.wait.flags = 0;
> - owait.wait.func = memcg_oom_wake_function;
> - owait.wait.private = current;
> - INIT_L

Re: [PATCH] ARM: ux500: Enable HIGHMEM in the u8540 defconfig

[Linus Walleij]

On Fri, May 31, 2013 at 5:09 PM, Lee Jones  wrote:

> In order to utilise all of the memory located on ux500 based devices
> we have to enable HIGHMEM. Without it the kernel truncates memory down
> to what's left after the PAGE_OFFSET has been applied, which doesn't
> leave an awful lot, especially if we're running large rootfs' such
> as full Linux desktop distributions or Android.
>
> Signed-off-by: Lee Jones 

Patch applied, but I renamed the topic arch to u8500
as the defconfig is named as such.

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

Re: [PATCH v2 1/5] arm/xen: define xen_remap as ioremap_cached

[Ian Campbell]

On Mon, 2013-06-03 at 16:33 +0100, Stefano Stabellini wrote:
> Define xen_remap as ioremap_cache (MT_MEMORY and MT_DEVICE_CACHED end up
> having the same AttrIndx encoding).

The entries in static struct mem_type mem_types[] look entirely
different to me.  What am I missing?
[MT_DEVICE_CACHED] = {/* ioremap_cached */
.prot_pte   = PROT_PTE_DEVICE | L_PTE_MT_DEV_CACHED,
.prot_l1= PMD_TYPE_TABLE,
.prot_sect  = PROT_SECT_DEVICE | PMD_SECT_WB,
.domain = DOMAIN_IO,
},
[MT_MEMORY] = {
.prot_pte  = L_PTE_PRESENT | L_PTE_YOUNG | L_PTE_DIRTY,
.prot_l1   = PMD_TYPE_TABLE,
.prot_sect = PMD_TYPE_SECT | PMD_SECT_AP_WRITE,
.domain= DOMAIN_KERNEL,
},

I can see in pgtable-3level.h how L_PTE_MT_DEV_CACHED and
L_PTE_MT_WRITEBACK are the same but not where the MT_WRITEBACK comes
from for MT_MEMORY. Things are less clear in pgtable-2level.h, where one
is 0x3 and the other is 0xb. I can see that the entries are the same in
armv6_mt_table but how that would apply to a v7 processor?

Anyhow, even if I'm prepared to believe that MT_MEMORY and
MT_DEVICE_CACHED end up being the same thing (which TBH I am) it seems
that the level of abstraction involved makes us vulnerable to future
changes subtly breaking things for us. What about:

/* Device shared memory */
#define ioremap_shm(cookie,size)__arm_ioremap((cookie), 
(size), MT_MEMORY)

Ian.

> Remove include asm/mach/map.h, not unneeded.
> 
> Signed-off-by: Stefano Stabellini 
> ---
>  arch/arm/include/asm/xen/page.h |3 +--
>  1 files changed, 1 insertions(+), 2 deletions(-)
> 
> diff --git a/arch/arm/include/asm/xen/page.h b/arch/arm/include/asm/xen/page.h
> index 30cdacb..359a7b5 100644
> --- a/arch/arm/include/asm/xen/page.h
> +++ b/arch/arm/include/asm/xen/page.h
> @@ -1,7 +1,6 @@
>  #ifndef _ASM_ARM_XEN_PAGE_H
>  #define _ASM_ARM_XEN_PAGE_H
>  
> -#include 
>  #include 
>  #include 
>  
> @@ -88,6 +87,6 @@ static inline bool set_phys_to_machine(unsigned long pfn, 
> unsigned long mfn)
>   return __set_phys_to_machine(pfn, mfn);
>  }
>  
> -#define xen_remap(cookie, size) __arm_ioremap((cookie), (size), MT_MEMORY);
> +#define xen_remap(cookie, size) ioremap_cached((cookie), (size));
>  
>  #endif /* _ASM_ARM_XEN_PAGE_H */


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

[PATCH 4/6] perf gtk/hists: Make column headers resizable

[Namhyung Kim]

From: Namhyung Kim 

Sometimes it's annoying to see when some symbols have very wierd long
names.  So it might be a good idea to make column size changable.

Reviewed-by: Pekka Enberg 
Signed-off-by: Namhyung Kim 
---
 tools/perf/ui/gtk/hists.c | 11 ---
 1 file changed, 8 insertions(+), 3 deletions(-)

diff --git a/tools/perf/ui/gtk/hists.c b/tools/perf/ui/gtk/hists.c
index fa9f8a09233e..b4a0dd2404a2 100644
--- a/tools/perf/ui/gtk/hists.c
+++ b/tools/perf/ui/gtk/hists.c
@@ -250,11 +250,16 @@ static void perf_gtk__show_hists(GtkWidget *window, 
struct hists *hists,
col_idx++, NULL);
}
 
-   if (symbol_conf.use_callchain && sort__has_sym) {
+   for (col_idx = 0; col_idx < nr_cols; col_idx++) {
GtkTreeViewColumn *column;
 
-   column = gtk_tree_view_get_column(GTK_TREE_VIEW(view), sym_col);
-   gtk_tree_view_set_expander_column(GTK_TREE_VIEW(view), column);
+   column = gtk_tree_view_get_column(GTK_TREE_VIEW(view), col_idx);
+   gtk_tree_view_column_set_resizable(column, TRUE);
+
+   if (col_idx == sym_col) {
+   gtk_tree_view_set_expander_column(GTK_TREE_VIEW(view),
+ column);
+   }
}
 
gtk_tree_view_set_model(GTK_TREE_VIEW(view), GTK_TREE_MODEL(store));
-- 
1.7.11.7

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

[PATCH 5/6] perf gtk/hists: Add a double-click handler for callchains

[Namhyung Kim]

From: Namhyung Kim 

If callchain is displayed, add "row-activated" signal handler for
handling double-click or pressing ENTER key action.

Reviewed-by: Pekka Enberg 
Signed-off-by: Namhyung Kim 
---
 tools/perf/ui/gtk/hists.c | 14 ++
 1 file changed, 14 insertions(+)

diff --git a/tools/perf/ui/gtk/hists.c b/tools/perf/ui/gtk/hists.c
index b4a0dd2404a2..3a5d01319988 100644
--- a/tools/perf/ui/gtk/hists.c
+++ b/tools/perf/ui/gtk/hists.c
@@ -187,6 +187,18 @@ static void perf_gtk__add_callchain(struct rb_root *root, 
GtkTreeStore *store,
}
 }
 
+static void on_row_activated(GtkTreeView *view, GtkTreePath *path,
+GtkTreeViewColumn *col __maybe_unused,
+gpointer user_data __maybe_unused)
+{
+   bool expanded = gtk_tree_view_row_expanded(view, path);
+
+   if (expanded)
+   gtk_tree_view_collapse_row(view, path);
+   else
+   gtk_tree_view_expand_row(view, path, FALSE);
+}
+
 static void perf_gtk__show_hists(GtkWidget *window, struct hists *hists,
 float min_pcnt)
 {
@@ -314,6 +326,8 @@ static void perf_gtk__show_hists(GtkWidget *window, struct 
hists *hists,
}
}
 
+   g_signal_connect(view, "row-activated",
+G_CALLBACK(on_row_activated), NULL);
gtk_container_add(GTK_CONTAINER(window), view);
 }
 
-- 
1.7.11.7

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

[PATCH 6/6] perf gtk/hists: Set rules hint for the hist browser

[Namhyung Kim]

From: Namhyung Kim 

The 'rules' means that every second line of the tree view has a shaded
background, which makes it easier to see which cell belongs to which
row in the tree view.  It can be useful for a tree view that has a lot
of rows.

Cc: Pekka Enberg 
Signed-off-by: Namhyung Kim 
---
 tools/perf/ui/gtk/hists.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/tools/perf/ui/gtk/hists.c b/tools/perf/ui/gtk/hists.c
index 3a5d01319988..32549035f50d 100644
--- a/tools/perf/ui/gtk/hists.c
+++ b/tools/perf/ui/gtk/hists.c
@@ -326,6 +326,8 @@ static void perf_gtk__show_hists(GtkWidget *window, struct 
hists *hists,
}
}
 
+   gtk_tree_view_set_rules_hint(GTK_TREE_VIEW(view), TRUE);
+
g_signal_connect(view, "row-activated",
 G_CALLBACK(on_row_activated), NULL);
gtk_container_add(GTK_CONTAINER(window), view);
-- 
1.7.11.7

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

[PATCH 3/6] perf gtk/hists: Display callchain overhead also

[Namhyung Kim]

From: Namhyung Kim 

Display callchain percent value in the overhead column.

Cc: Pekka Enberg 
Signed-off-by: Namhyung Kim 
---
 tools/perf/ui/gtk/hists.c | 27 ---
 1 file changed, 24 insertions(+), 3 deletions(-)

diff --git a/tools/perf/ui/gtk/hists.c b/tools/perf/ui/gtk/hists.c
index 226c7e10f3cc..fa9f8a09233e 100644
--- a/tools/perf/ui/gtk/hists.c
+++ b/tools/perf/ui/gtk/hists.c
@@ -134,7 +134,7 @@ static void callchain_list__sym_name(struct callchain_list 
*cl,
 }
 
 static void perf_gtk__add_callchain(struct rb_root *root, GtkTreeStore *store,
-   GtkTreeIter *parent, int col)
+   GtkTreeIter *parent, int col, u64 total)
 {
struct rb_node *nd;
bool has_single_node = (rb_first(root) == rb_last(root));
@@ -144,9 +144,14 @@ static void perf_gtk__add_callchain(struct rb_root *root, 
GtkTreeStore *store,
struct callchain_list *chain;
GtkTreeIter iter, new_parent;
bool need_new_parent;
+   double percent;
+   u64 hits, child_total;
 
node = rb_entry(nd, struct callchain_node, rb_node);
 
+   hits = callchain_cumul_hits(node);
+   percent = 100.0 * hits / total;
+
new_parent = *parent;
need_new_parent = !has_single_node && (node->val_nr > 1);
 
@@ -155,6 +160,9 @@ static void perf_gtk__add_callchain(struct rb_root *root, 
GtkTreeStore *store,
 
gtk_tree_store_append(store, &iter, &new_parent);
 
+   scnprintf(buf, sizeof(buf), "%5.2f%%", percent);
+   gtk_tree_store_set(store, &iter, 0, buf, -1);
+
callchain_list__sym_name(chain, buf, sizeof(buf));
gtk_tree_store_set(store, &iter, col, buf, -1);
 
@@ -168,8 +176,14 @@ static void perf_gtk__add_callchain(struct rb_root *root, 
GtkTreeStore *store,
}
}
 
+   if (callchain_param.mode == CHAIN_GRAPH_REL)
+   child_total = node->children_hit;
+   else
+   child_total = total;
+
/* Now 'iter' contains info of the last callchain_list */
-   perf_gtk__add_callchain(&node->rb_root, store, &iter, col);
+   perf_gtk__add_callchain(&node->rb_root, store, &iter, col,
+   child_total);
}
 }
 
@@ -283,8 +297,15 @@ static void perf_gtk__show_hists(GtkWidget *window, struct 
hists *hists,
}
 
if (symbol_conf.use_callchain && sort__has_sym) {
+   u64 total;
+
+   if (callchain_param.mode == CHAIN_GRAPH_REL)
+   total = h->stat.period;
+   else
+   total = hists->stats.total_period;
+
perf_gtk__add_callchain(&h->sorted_chain, store, &iter,
-   sym_col);
+   sym_col, total);
}
}
 
-- 
1.7.11.7

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

[PATCHSET 0/6] perf report: Add support for callchains on GTK browser (v2)

[Namhyung Kim]

Hi,

This patchset implements callchain support in GTK report browser as
Pekka requested.  Please take a look and give me comments.

v2 changes)
 * fix a bug on percent calculation of children nodes
 * show topmost symbol only when multiple paths exist for a node
 * add alternating background colors (Ingo)
 * put callchain info into existing overhead and symbol column (Arnaldo)

You can get it from 'perf/callchain-gtk-v2' branch on my tree at

 git://git.kernel.org/pub/scm/linux/kernel/git/namhyung/linux-perf.git


Any comments are welcome, thanks!
Namhyung

Namhyung Kim (6):
  perf gtk/hists: Use GtkTreeStore instead of GtkListStore
  perf gtk/hists: Add support for callchains
  perf gtk/hists: Display callchain overhead also
  perf gtk/hists: Make column headers resizable
  perf gtk/hists: Add a double-click handler for callchains
  perf gtk/hists: Set rules hint for the hist browser

 tools/perf/ui/gtk/hists.c | 117 --
 1 file changed, 112 insertions(+), 5 deletions(-)

-- 
1.7.11.7

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

[PATCH 2/6] perf gtk/hists: Add support for callchains

[Namhyung Kim]

From: Namhyung Kim 

Display callchain information in the symbol column.  It's only enabled
when recorded with -g and has symbol sort key.

Cc: Pekka Enberg 
Signed-off-by: Namhyung Kim 
---
 tools/perf/ui/gtk/hists.c | 65 +++
 1 file changed, 65 insertions(+)

diff --git a/tools/perf/ui/gtk/hists.c b/tools/perf/ui/gtk/hists.c
index cb6a9b45f789..226c7e10f3cc 100644
--- a/tools/perf/ui/gtk/hists.c
+++ b/tools/perf/ui/gtk/hists.c
@@ -124,6 +124,55 @@ void perf_gtk__init_hpp(void)
perf_gtk__hpp_color_overhead_guest_us;
 }
 
+static void callchain_list__sym_name(struct callchain_list *cl,
+char *bf, size_t bfsize)
+{
+   if (cl->ms.sym)
+   scnprintf(bf, bfsize, "%s", cl->ms.sym->name);
+   else
+   scnprintf(bf, bfsize, "%#" PRIx64, cl->ip);
+}
+
+static void perf_gtk__add_callchain(struct rb_root *root, GtkTreeStore *store,
+   GtkTreeIter *parent, int col)
+{
+   struct rb_node *nd;
+   bool has_single_node = (rb_first(root) == rb_last(root));
+
+   for (nd = rb_first(root); nd; nd = rb_next(nd)) {
+   struct callchain_node *node;
+   struct callchain_list *chain;
+   GtkTreeIter iter, new_parent;
+   bool need_new_parent;
+
+   node = rb_entry(nd, struct callchain_node, rb_node);
+
+   new_parent = *parent;
+   need_new_parent = !has_single_node && (node->val_nr > 1);
+
+   list_for_each_entry(chain, &node->val, list) {
+   char buf[128];
+
+   gtk_tree_store_append(store, &iter, &new_parent);
+
+   callchain_list__sym_name(chain, buf, sizeof(buf));
+   gtk_tree_store_set(store, &iter, col, buf, -1);
+
+   if (need_new_parent) {
+   /*
+* Only show the top-most symbol in a callchain
+* if it's not the only callchain.
+*/
+   new_parent = iter;
+   need_new_parent = false;
+   }
+   }
+
+   /* Now 'iter' contains info of the last callchain_list */
+   perf_gtk__add_callchain(&node->rb_root, store, &iter, col);
+   }
+}
+
 static void perf_gtk__show_hists(GtkWidget *window, struct hists *hists,
 float min_pcnt)
 {
@@ -135,6 +184,7 @@ static void perf_gtk__show_hists(GtkWidget *window, struct 
hists *hists,
struct rb_node *nd;
GtkWidget *view;
int col_idx;
+   int sym_col = -1;
int nr_cols;
char s[512];
 
@@ -153,6 +203,9 @@ static void perf_gtk__show_hists(GtkWidget *window, struct 
hists *hists,
if (se->elide)
continue;
 
+   if (se == &sort_sym)
+   sym_col = nr_cols;
+
col_types[nr_cols++] = G_TYPE_STRING;
}
 
@@ -183,6 +236,13 @@ static void perf_gtk__show_hists(GtkWidget *window, struct 
hists *hists,
col_idx++, NULL);
}
 
+   if (symbol_conf.use_callchain && sort__has_sym) {
+   GtkTreeViewColumn *column;
+
+   column = gtk_tree_view_get_column(GTK_TREE_VIEW(view), sym_col);
+   gtk_tree_view_set_expander_column(GTK_TREE_VIEW(view), column);
+   }
+
gtk_tree_view_set_model(GTK_TREE_VIEW(view), GTK_TREE_MODEL(store));
 
g_object_unref(GTK_TREE_MODEL(store));
@@ -221,6 +281,11 @@ static void perf_gtk__show_hists(GtkWidget *window, struct 
hists *hists,
 
gtk_tree_store_set(store, &iter, col_idx++, s, -1);
}
+
+   if (symbol_conf.use_callchain && sort__has_sym) {
+   perf_gtk__add_callchain(&h->sorted_chain, store, &iter,
+   sym_col);
+   }
}
 
gtk_container_add(GTK_CONTAINER(window), view);
-- 
1.7.11.7

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