Re: [RFC PATCH] gpiolib: make gpiod_direction_output take a logical value, add gpiod_direction_output_raw

2014-01-11 Thread Alexandre Courbot
Hi Philipp,

On Tue, Jan 7, 2014 at 8:34 PM, Philipp Zabel  wrote:
> The documentation was not clear about whether gpio_direction_output should 
> take
> a logical value or the physical level on the output line, i.e. whether the
> ACTIVE_LOW status would be taken into account.
> This converts gpiod_direction_output to use the logical level and adds a new
> gpiod_direction_output_raw for the raw value.

Thanks for taking the time to craft this! The patch seems to do
exactly what we discussed and looks good to me. Maybe Linus can let us
know what he thinks about it? Unless there are reasons against it, I
think this should be merged ASAP as we want to gpiod API to converge
to something stable ASAP.

Reviewed-by: Alexandre Courbot 

>
> Signed-off-by: Philipp Zabel 
> ---
>  Documentation/gpio/consumer.txt |  1 +
>  drivers/gpio/gpiolib.c  | 67 
> +
>  include/asm-generic/gpio.h  |  2 +-
>  include/linux/gpio/consumer.h   |  7 +
>  4 files changed, 57 insertions(+), 20 deletions(-)
>
> diff --git a/Documentation/gpio/consumer.txt b/Documentation/gpio/consumer.txt
> index 07c74a3..4dc4809 100644
> --- a/Documentation/gpio/consumer.txt
> +++ b/Documentation/gpio/consumer.txt
> @@ -150,6 +150,7 @@ raw line value:
> void gpiod_set_raw_value(struct gpio_desc *desc, int value)
> int gpiod_get_raw_value_cansleep(const struct gpio_desc *desc)
> void gpiod_set_raw_value_cansleep(struct gpio_desc *desc, int value)
> +   int gpiod_direction_output_raw(struct gpio_desc *desc, int value)
>
>  The active-low state of a GPIO can also be queried using the following call:
>
> diff --git a/drivers/gpio/gpiolib.c b/drivers/gpio/gpiolib.c
> index 85f772c..f04f1e6 100644
> --- a/drivers/gpio/gpiolib.c
> +++ b/drivers/gpio/gpiolib.c
> @@ -330,9 +330,9 @@ static ssize_t gpio_direction_store(struct device *dev,
> if (!test_bit(FLAG_EXPORT, &desc->flags))
> status = -EIO;
> else if (sysfs_streq(buf, "high"))
> -   status = gpiod_direction_output(desc, 1);
> +   status = gpiod_direction_output_raw(desc, 1);
> else if (sysfs_streq(buf, "out") || sysfs_streq(buf, "low"))
> -   status = gpiod_direction_output(desc, 0);
> +   status = gpiod_direction_output_raw(desc, 0);
> else if (sysfs_streq(buf, "in"))
> status = gpiod_direction_input(desc);
> else
> @@ -1579,7 +1579,7 @@ int gpio_request_one(unsigned gpio, unsigned long 
> flags, const char *label)
> if (flags & GPIOF_DIR_IN)
> err = gpiod_direction_input(desc);
> else
> -   err = gpiod_direction_output(desc,
> +   err = gpiod_direction_output_raw(desc,
> (flags & GPIOF_INIT_HIGH) ? 1 : 0);
>
> if (err)
> @@ -1744,28 +1744,13 @@ fail:
>  }
>  EXPORT_SYMBOL_GPL(gpiod_direction_input);
>
> -/**
> - * gpiod_direction_output - set the GPIO direction to input
> - * @desc:  GPIO to set to output
> - * @value: initial output value of the GPIO
> - *
> - * Set the direction of the passed GPIO to output, such as gpiod_set_value() 
> can
> - * be called safely on it. The initial value of the output must be specified.
> - *
> - * Return 0 in case of success, else an error code.
> - */
> -int gpiod_direction_output(struct gpio_desc *desc, int value)
> +static int _gpiod_direction_output_raw(struct gpio_desc *desc, int value)
>  {
> unsigned long   flags;
> struct gpio_chip*chip;
> int status = -EINVAL;
> int offset;
>
> -   if (!desc || !desc->chip) {
> -   pr_warn("%s: invalid GPIO\n", __func__);
> -   return -EINVAL;
> -   }
> -
> /* GPIOs used for IRQs shall not be set as output */
> if (test_bit(FLAG_USED_AS_IRQ, &desc->flags)) {
> gpiod_err(desc,
> @@ -1827,6 +1812,50 @@ fail:
> gpiod_dbg(desc, "%s: gpio status %d\n", __func__, status);
> return status;
>  }
> +
> +/**
> + * gpiod_direction_output_raw - set the GPIO direction to output
> + * @desc:  GPIO to set to output
> + * @value: initial output value of the GPIO
> + *
> + * Set the direction of the passed GPIO to output, such as gpiod_set_value() 
> can
> + * be called safely on it. The initial value of the output must be specified
> + * as raw value on the physical line without regard for the ACTIVE_LOW 
> status.
> + *
> + * Return 0 in case of success, else an error code.
> + */
> +int gpiod_direction_output_raw(struct gpio_desc *desc, int value)
> +{
> +   if (!desc || !desc->chip) {
> +   pr_warn("%s: invalid GPIO\n", __func__);
> +   return -EINVAL;
> +   }
> +   return _gpiod_direction_output_raw(desc, value);
> +}
> +EXPORT_SYMBOL_GPL(gpiod_direction_output_raw);
> +
> +/**
> + * gpiod_direction_output - set the GPIO direction to in

Re: [PATCH 1/1] When timestamping is enabled, stmmac_tx_clean will call stmmac_get_tx_hwtstamp to get tx TS. It's possible that skb is NULL because there are other network frames that use several desc

2014-01-11 Thread Hannes Frederic Sowa
On Sun, Jan 12, 2014 at 10:01:35AM +0800, damuzi000 wrote:
> 
> Signed-off-by: damuzi000 

Please use real names in submissions.

Thanks,

  Hannes

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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 mmotm/next] fanotify: fix corruption preventing startup

2014-01-11 Thread Hugh Dickins
Two of my machines couldn't boot mmotm with fanotify enabled:
0x4020 was being or'ed into a group's notification_waitq next
pointer, with sad results.  It comes from an over-simplification in
fanotify_merge(): test_event isn't NULL when the loop finds no merge.

Signed-off-by: Hugh Dickins 
---
Fixes fsnotify-do-not-share-events-between-notification-groups.patch

 fs/notify/fanotify/fanotify.c |9 ++---
 1 file changed, 6 insertions(+), 3 deletions(-)

--- mmotm/fs/notify/fanotify/fanotify.c 2014-01-10 18:25:01.700448941 -0800
+++ linux/fs/notify/fanotify/fanotify.c 2014-01-11 22:15:31.580961010 -0800
@@ -37,16 +37,19 @@ static bool should_merge(struct fsnotify
 static struct fsnotify_event *fanotify_merge(struct list_head *list,
 struct fsnotify_event *event)
 {
-   struct fsnotify_event *test_event = NULL;
+   struct fsnotify_event *test_event;
+   bool do_merge = false;
 
pr_debug("%s: list=%p event=%p\n", __func__, list, event);
 
list_for_each_entry_reverse(test_event, list, list) {
-   if (should_merge(test_event, event))
+   if (should_merge(test_event, event)) {
+   do_merge = true;
break;
+   }
}
 
-   if (!test_event)
+   if (!do_merge)
return NULL;
 
test_event->mask |= event->mask;
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] perf tools: Synthesize anon MMAP records on the heap

2014-01-11 Thread Gaurav Jain
Anon records usually do not have the 'execname' entry. However if they are on
the heap, the execname shows up as '[heap]'. The fix considers any executable
entries in the map that do not have a name or are on the heap as anon records
and sets the name to '//anon'.

This fixes JIT profiling for records on the heap.

Signed-off-by: Gaurav Jain 
Cc: Ingo Molnar 
Cc: Jiri Olsa 
Cc: Paul Mackerras 
Cc: Peter Zijlstra 
Cc: Don Zickus 
Cc: Arun Sharma 
---
 tools/perf/util/event.c | 5 ++---
 1 file changed, 2 insertions(+), 3 deletions(-)

diff --git a/tools/perf/util/event.c b/tools/perf/util/event.c
index bb788c1..ae9c55b 100644
--- a/tools/perf/util/event.c
+++ b/tools/perf/util/event.c
@@ -224,10 +224,9 @@ static int perf_event__synthesize_mmap_events(struct 
perf_tool *tool,
continue;
 
event->header.misc |= PERF_RECORD_MISC_MMAP_DATA;
-   }
-
-   if (!strcmp(execname, ""))
+   } if (!strcmp(execname, "") || !strcmp(execname, "[heap]")) {
strcpy(execname, anonstr);
+   }
 
size = strlen(execname) + 1;
memcpy(event->mmap.filename, execname, size);
-- 
1.8.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/


In "pci_fixup_video" check if this is or should be the primary video device to prevent setting the IORESOURCE_ROM_SHADOW flag on a secondary VGA card

2014-01-11 Thread Sander Eikelenboom
Hi Eiichiro / Dave / Greg,

While trying to get secondary PCI/VGA passthrough of a AMD 6570 card to a Xen 
guest with the radeon driver and modesetting
i'm running into the problem that the driver says the BIOS is a COMBIOS while 
it expects a ATOMBIOS for the cards.

So the Guest uses both it's normal emulated VGA card provided by Qemu (f.e. 
cirrus logic) and a real VGA card via
PCI passthrough.

While debugging it turned out that the bios that the driver read was not the 
AMD bios, but the bios from the emulated card.
(so it wasn't a COMBIOS either ..)

I first thought the culprit was with Xen, Seabios or Qemu ..
So it took quite a while and debugging, but finally my eye fell on this in the 
guest dmesg:

[2.545728] pci :00:00.0: calling quirk_natoma+0x0/0x40
[2.545730] pci :00:00.0: Limiting direct PCI/PCI transfers
[2.558998] pci :00:00.0: calling quirk_passive_release+0x0/0x90
[2.559121] pci :00:01.0: PIIX3: Enabling Passive Release
[2.572412] pci :00:01.0: calling quirk_isa_dma_hangs+0x0/0x40
[2.572415] pci :00:01.0: Activating ISA DMA hang workarounds
[2.586527] pci :00:03.0: calling pci_fixup_video+0x0/0xd0
[2.586609] pci :00:03.0: Boot video device
[2.586696] pci :00:05.0: calling pci_fixup_video+0x0/0xd0
[2.586827] pci :00:05.0: Boot video device
[2.586928] pci :00:06.0: calling quirk_e100_interrupt+0x0/0x1c0

It's calling the "pci_fixup_video" quirk ... and it's calling it twice ..
which if i read the comment correctly .. shouldn't be the case:

 /*
 * Fixup to mark boot BIOS video selected by BIOS before it changes
 *
 * From information provided by "Jon Smirl" 
 *
 * The standard boot ROM sequence for an x86 machine uses the BIOS
 * to select an initial video card for boot display. This boot video
 * card will have it's BIOS copied to C in system RAM.
 * IORESOURCE_ROM_SHADOW is used to associate the boot video
 * card with this copy. On laptops this copy has to be used since
 * the main ROM may be compressed or combined with another image.
 * See pci_map_rom() for use of this flag. IORESOURCE_ROM_SHADOW
 * is marked here since the boot video device will be the only enabled
 * video device at this point.
 */


But the code doesn't check if it's actually the only enabled (or first) video 
device at that point ..
and it's setting 2 boot video devices and setting both to use the 
IORESOURCE_ROM_SHADOW at C000 ..
which happens to be the bios from the emulated card.

With this patch applied the passthrough of the card works fine in the guest and 
dmesg reports:

[2.167076] pci :00:00.0: calling quirk_natoma+0x0/0x40
[2.167078] pci :00:00.0: Limiting direct PCI/PCI transfers
[2.179807] pci :00:00.0: calling quirk_passive_release+0x0/0x90
[2.179953] pci :00:01.0: PIIX3: Enabling Passive Release
[2.192953] pci :00:01.0: calling quirk_isa_dma_hangs+0x0/0x40
[2.192955] pci :00:01.0: Activating ISA DMA hang workarounds
[2.206543] pci :00:03.0: calling pci_fixup_video+0x0/0xe0
[2.206623] pci :00:03.0: Boot video device
[2.206710] pci :00:05.0: calling pci_fixup_video+0x0/0xe0
[2.206842] pci :00:06.0: calling quirk_e100_interrupt+0x0/0x1c0

--
Sander

Sander Eikelenboom (1):
  In "pci_fixup_video" check if this is or should be the primary video
device to prevent setting the IORESOURCE_ROM_SHADOW flag on a
secondary VGA card

 arch/x86/pci/fixup.c |   17 +
 1 file changed, 9 insertions(+), 8 deletions(-)

-- 
1.7.10.4

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


[PATCH] In "pci_fixup_video" check if this is or should be the primary video device to prevent setting the IORESOURCE_ROM_SHADOW flag on a secondary VGA card

2014-01-11 Thread Sander Eikelenboom
Setting the IORESOURCE_ROM_SHADOW flag on a secondary VGA card prevents if from
reading it's own rom. It will get the content of the shadowrom at C000 instead,
which is of the primary VGA card and the driver of the secondary card will bail
out.

Fix this by checking if this is or should be the primary video device before
applying the fix and let the comment reflect this.

Signed-off-by: Sander Eikelenboom 
---
 arch/x86/pci/fixup.c |   17 +
 1 file changed, 9 insertions(+), 8 deletions(-)

diff --git a/arch/x86/pci/fixup.c b/arch/x86/pci/fixup.c
index b046e07..525e49a 100644
--- a/arch/x86/pci/fixup.c
+++ b/arch/x86/pci/fixup.c
@@ -314,9 +314,9 @@ DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_INTEL,
PCI_DEVICE_ID_INTEL_MCH_PC1,pcie_r
  * IORESOURCE_ROM_SHADOW is used to associate the boot video
  * card with this copy. On laptops this copy has to be used since
  * the main ROM may be compressed or combined with another image.
- * See pci_map_rom() for use of this flag. IORESOURCE_ROM_SHADOW
- * is marked here since the boot video device will be the only enabled
- * video device at this point.
+ * See pci_map_rom() for use of this flag. Before we mark the device
+ * with IORESOURCE_ROM_SHADOW we have to check if this is or should become
+ * the primary video card, since this quirk is ran for all video devices.
  */
 
 static void pci_fixup_video(struct pci_dev *pdev)
@@ -347,12 +347,13 @@ static void pci_fixup_video(struct pci_dev *pdev)
}
bus = bus->parent;
}
-   pci_read_config_word(pdev, PCI_COMMAND, &config);
-   if (config & (PCI_COMMAND_IO | PCI_COMMAND_MEMORY)) {
-   pdev->resource[PCI_ROM_RESOURCE].flags |= IORESOURCE_ROM_SHADOW;
-   dev_printk(KERN_DEBUG, &pdev->dev, "Boot video device\n");
-   if (!vga_default_device())
+   if (!vga_default_device() || pdev == vga_default_device()) {
+   pci_read_config_word(pdev, PCI_COMMAND, &config);
+   if (config & (PCI_COMMAND_IO | PCI_COMMAND_MEMORY)) {
+   pdev->resource[PCI_ROM_RESOURCE].flags |= 
IORESOURCE_ROM_SHADOW;
+   dev_printk(KERN_DEBUG, &pdev->dev, "Boot video 
device\n");
vga_set_default_device(pdev);
+   }
}
 }
 DECLARE_PCI_FIXUP_CLASS_FINAL(PCI_ANY_ID, PCI_ANY_ID,
-- 
1.7.10.4

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


Re: [ipv6_vti.c] INFO: trying to register non-static key.

2014-01-11 Thread David Miller
From: Fengguang Wu 
Date: Sun, 12 Jan 2014 07:10:23 +0800

> Here is a warning introduced by commit 469bdcefd ("ipv6: fix the use
> of pcpu_tstats in ip6_vti.c"):

It isn't fixed by the following, which is also in Linus's tree?

>From 657e5d19657542631461e72fdc375b1e83e72070 Mon Sep 17 00:00:00 2001
From: Li RongQing 
Date: Tue, 7 Jan 2014 15:39:43 +0800
Subject: [PATCH] ipv6: pcpu_tstats.syncp should be initialised in ip6_vti.c

initialise pcpu_tstats.syncp to kill the calltrace
[   11.973950] Call Trace:
[   11.973950]  [<819bbaff>] dump_stack+0x48/0x60
[   11.973950]  [<819bbaff>] dump_stack+0x48/0x60
[   11.973950]  [<81078dcf>] __lock_acquire.isra.22+0x1bf/0xc10
[   11.973950]  [<81078dcf>] __lock_acquire.isra.22+0x1bf/0xc10
[   11.973950]  [<81079fa7>] lock_acquire+0x77/0xa0
[   11.973950]  [<81079fa7>] lock_acquire+0x77/0xa0
[   11.973950]  [<817ca7ab>] ? dev_get_stats+0xcb/0x130
[   11.973950]  [<817ca7ab>] ? dev_get_stats+0xcb/0x130
[   11.973950]  [<8183862d>] ip_tunnel_get_stats64+0x6d/0x230
[   11.973950]  [<8183862d>] ip_tunnel_get_stats64+0x6d/0x230
[   11.973950]  [<817ca7ab>] ? dev_get_stats+0xcb/0x130
[   11.973950]  [<817ca7ab>] ? dev_get_stats+0xcb/0x130
[   11.973950]  [<811cf8c1>] ? __nla_reserve+0x21/0xd0
[   11.973950]  [<811cf8c1>] ? __nla_reserve+0x21/0xd0
[   11.973950]  [<817ca7ab>] dev_get_stats+0xcb/0x130
[   11.973950]  [<817ca7ab>] dev_get_stats+0xcb/0x130
[   11.973950]  [<817d5409>] rtnl_fill_ifinfo+0x569/0xe20
[   11.973950]  [<817d5409>] rtnl_fill_ifinfo+0x569/0xe20
[   11.973950]  [<810352e0>] ? kvm_clock_read+0x20/0x30
[   11.973950]  [<810352e0>] ? kvm_clock_read+0x20/0x30
[   11.973950]  [<81008e38>] ? sched_clock+0x8/0x10
[   11.973950]  [<81008e38>] ? sched_clock+0x8/0x10
[   11.973950]  [<8106ba45>] ? sched_clock_local+0x25/0x170
[   11.973950]  [<8106ba45>] ? sched_clock_local+0x25/0x170
[   11.973950]  [<810da6bd>] ? __kmalloc+0x3d/0x90
[   11.973950]  [<810da6bd>] ? __kmalloc+0x3d/0x90
[   11.973950]  [<817b8c10>] ? __kmalloc_reserve.isra.41+0x20/0x70
[   11.973950]  [<817b8c10>] ? __kmalloc_reserve.isra.41+0x20/0x70
[   11.973950]  [<810da81a>] ? slob_alloc_node+0x2a/0x60
[   11.973950]  [<810da81a>] ? slob_alloc_node+0x2a/0x60
[   11.973950]  [<817b919a>] ? __alloc_skb+0x6a/0x2b0
[   11.973950]  [<817b919a>] ? __alloc_skb+0x6a/0x2b0
[   11.973950]  [<817d8795>] rtmsg_ifinfo+0x65/0xe0
[   11.973950]  [<817d8795>] rtmsg_ifinfo+0x65/0xe0
[   11.973950]  [<817cbd31>] register_netdevice+0x531/0x5a0
[   11.973950]  [<817cbd31>] register_netdevice+0x531/0x5a0
[   11.973950]  [<81892b87>] ? ip6_tnl_get_cap+0x27/0x90
[   11.973950]  [<81892b87>] ? ip6_tnl_get_cap+0x27/0x90
[   11.973950]  [<817cbdb6>] register_netdev+0x16/0x30
[   11.973950]  [<817cbdb6>] register_netdev+0x16/0x30
[   11.973950]  [<81f574a6>] vti6_init_net+0x1c4/0x1d4
[   11.973950]  [<81f574a6>] vti6_init_net+0x1c4/0x1d4
[   11.973950]  [<81f573af>] ? vti6_init_net+0xcd/0x1d4
[   11.973950]  [<81f573af>] ? vti6_init_net+0xcd/0x1d4
[   11.973950]  [<817c16df>] ops_init.constprop.11+0x17f/0x1c0
[   11.973950]  [<817c16df>] ops_init.constprop.11+0x17f/0x1c0
[   11.973950]  [<817c1779>] register_pernet_operations.isra.9+0x59/0x90
[   11.973950]  [<817c1779>] register_pernet_operations.isra.9+0x59/0x90
[   11.973950]  [<817c18d1>] register_pernet_device+0x21/0x60
[   11.973950]  [<817c18d1>] register_pernet_device+0x21/0x60
[   11.973950]  [<81f574b6>] ? vti6_init_net+0x1d4/0x1d4
[   11.973950]  [<81f574b6>] ? vti6_init_net+0x1d4/0x1d4
[   11.973950]  [<81f574c7>] vti6_tunnel_init+0x11/0x68
[   11.973950]  [<81f574c7>] vti6_tunnel_init+0x11/0x68
[   11.973950]  [<81f572a1>] ? mip6_init+0x73/0xb4
[   11.973950]  [<81f572a1>] ? mip6_init+0x73/0xb4
[   11.973950]  [<81f0cba4>] do_one_initcall+0xbb/0x15b
[   11.973950]  [<81f0cba4>] do_one_initcall+0xbb/0x15b
[   11.973950]  [<811a00d8>] ? sha_transform+0x528/0x1150
[   11.973950]  [<811a00d8>] ? sha_transform+0x528/0x1150
[   11.973950]  [<81f0c544>] ? repair_env_string+0x12/0x51
[   11.973950]  [<81f0c544>] ? repair_env_string+0x12/0x51
[   11.973950]  [<8105c30d>] ? parse_args+0x2ad/0x440
[   11.973950]  [<8105c30d>] ? parse_args+0x2ad/0x440
[   11.973950]  [<810546be>] ? __usermodehelper_set_disable_depth+0x3e/0x50
[   11.973950]  [<810546be>] ? __usermodehelper_set_disable_depth+0x3e/0x50
[   11.973950]  [<81f0cd27>] kernel_init_freeable+0xe3/0x182
[   11.973950]  [<81f0cd27>] kernel_init_freeable+0xe3/0x182
[   11.973950]  [<81f0c532>] ? do_early_param+0x7a/0x7a
[   11.973950]  [<81f0c532>] ? do_early_param+0x7a/0x7a
[   11.973950]  [<819b5b1b>] kernel_init+0xb/0x100
[   11.973950]  [<819b5b1b>] kernel_init+0xb/0x100
[   11.973950]  [<819cebf7>] ret_from_kernel_thread+0x1b/0x28
[   11.973950]  [<819cebf7>] ret_from_kernel_thread+0x1b/0x28
[   11.973950]  [<819b5b10>] ? rest_init+0xc0/0xc0
[   11.973950]  [<819b5b10>] ? rest_init+0xc0/0xc0

Before 469bdcefdc ("ipv6: fix the use of pcpu_tstats in ip6_vti.c"),
the pcpu_tstats.syncp is not used to pretect th

Re: [RFC PATCHv3 03/11] percpu: use VMALLOC_TOTAL instead of VMALLOC_END - VMALLOC_START

2014-01-11 Thread Tejun Heo
On Thu, Jan 02, 2014 at 01:53:21PM -0800, Laura Abbott wrote:
> vmalloc already gives a useful macro to calculate the total vmalloc
> size. Use it.
> 
> Signed-off-by: Laura Abbott 

Applied to percpu/for-3.14.  Thanks.

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


Re: [PATCH] percpu-refcount: Add a WARN() for ref going negative

2014-01-11 Thread Tejun Heo
On Mon, Jan 06, 2014 at 01:13:26PM -0800, Kent Overstreet wrote:
> AIO had a missing get, which led to an ioctx leak - after percpu_ref_kill() 
> the
> ref was 0 so percpu_ref_put() never saw it hit 0.
> 
> This wasn't noticed at the time because it all happened completely silently,
> this adds a WARN() which would've caught the aio bug.
> 
> Signed-off-by: Kent Overstreet 
> Cc: Tejun Heo 

Applied to percpu/for-3.14 w/ WARN_ONCE() instead WARN().

Thanks.

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


[PATCH] fs/notify: don't use module_init for non-modular inotify_user code

2014-01-11 Thread Paul Gortmaker
The INOTIFY_USER option is bool, and hence this code is either
present or absent.  It will never be modular, so using
module_init as an alias for __initcall is rather misleading.

Fix this up now, so that we can relocate module_init from
init.h into module.h in the future.  If we don't do this, we'd
have to add module.h to obviously non-modular code, and that
would be a worse thing.

Note that direct use of __initcall is discouraged, vs. one
of the priority categorized subgroups.  As __initcall gets
mapped onto device_initcall, our use of fs_initcall (which
makes sense for fs code) will thus change this registration
from level 6-device to level 5-fs (i.e. slightly earlier).
However no observable impact of that small difference has
been observed during testing, or is expected.

Signed-off-by: Paul Gortmaker 
---
 fs/notify/inotify/inotify_user.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/fs/notify/inotify/inotify_user.c b/fs/notify/inotify/inotify_user.c
index 497395c8274b..0a23b698c65b 100644
--- a/fs/notify/inotify/inotify_user.c
+++ b/fs/notify/inotify/inotify_user.c
@@ -26,7 +26,7 @@
 #include  /* struct inode */
 #include 
 #include 
-#include  /* module_init */
+#include  /* fs_initcall */
 #include 
 #include  /* roundup() */
 #include  /* LOOKUP_FOLLOW */
@@ -801,4 +801,4 @@ static int __init inotify_user_setup(void)
 
return 0;
 }
-module_init(inotify_user_setup);
+fs_initcall(inotify_user_setup);
-- 
1.8.5.2

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


Re: [PATCH 1/3] workqueue: Calling destroy_work_on_stack() to pair with INIT_WORK_ONSTACK()

2014-01-11 Thread Tejun Heo
On Tue, Jan 07, 2014 at 04:50:05PM +0800, Chuansheng Liu wrote:
> 
> In case CONFIG_DEBUG_OBJECTS_WORK is defined, it is needed to
> call destroy_work_on_stack() which frees the debug object to pair
> with INIT_WORK_ONSTACK().
> 
> Signed-off-by: Liu, Chuansheng 

Applied to wq/for-3.14.  Thanks.

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


[tip:x86/urgent] x86, fpu, amd: Clear exceptions in AMD FXSAVE workaround

2014-01-11 Thread tip-bot for Linus Torvalds
Commit-ID:  26bef1318adc1b3a530ecc807ef99346db2aa8b0
Gitweb: http://git.kernel.org/tip/26bef1318adc1b3a530ecc807ef99346db2aa8b0
Author: Linus Torvalds 
AuthorDate: Sat, 11 Jan 2014 19:15:52 -0800
Committer:  H. Peter Anvin 
CommitDate: Sat, 11 Jan 2014 19:15:52 -0800

x86, fpu, amd: Clear exceptions in AMD FXSAVE workaround

Before we do an EMMS in the AMD FXSAVE information leak workaround we
need to clear any pending exceptions, otherwise we trap with a
floating-point exception inside this code.

Reported-by: halfdog 
Tested-by: Borislav Petkov 
Link: 
http://lkml.kernel.org/r/CA%2B55aFxQnY_PCG_n4=0w-VG=ylxl-yr7omxyy0wu2gcbaf3...@mail.gmail.com
Signed-off-by: H. Peter Anvin 
---
 arch/x86/include/asm/fpu-internal.h | 13 +++--
 1 file changed, 7 insertions(+), 6 deletions(-)

diff --git a/arch/x86/include/asm/fpu-internal.h 
b/arch/x86/include/asm/fpu-internal.h
index c49a613..cea1c76 100644
--- a/arch/x86/include/asm/fpu-internal.h
+++ b/arch/x86/include/asm/fpu-internal.h
@@ -293,12 +293,13 @@ static inline int restore_fpu_checking(struct task_struct 
*tsk)
/* AMD K7/K8 CPUs don't save/restore FDP/FIP/FOP unless an exception
   is pending.  Clear the x87 state here by setting it to fixed
   values. "m" is a random variable that should be in L1 */
-   alternative_input(
-   ASM_NOP8 ASM_NOP2,
-   "emms\n\t"  /* clear stack tags */
-   "fildl %P[addr]",   /* set F?P to defined value */
-   X86_FEATURE_FXSAVE_LEAK,
-   [addr] "m" (tsk->thread.fpu.has_fpu));
+   if (unlikely(static_cpu_has(X86_FEATURE_FXSAVE_LEAK))) {
+   asm volatile(
+   "fnclex\n\t"
+   "emms\n\t"
+   "fildl %P[addr]"/* set F?P to defined value */
+   : : [addr] "m" (tsk->thread.fpu.has_fpu));
+   }
 
return fpu_restore_checking(&tsk->thread.fpu);
 }
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] fs/ramfs: don't use module_init for non-modular core code

2014-01-11 Thread Paul Gortmaker
The ramfs is always built in.  It will never be modular, so
using module_init as an alias for __initcall is rather
misleading.

Fix this up now, so that we can relocate module_init from
init.h into module.h in the future.  If we don't do this, we'd
have to add module.h to obviously non-modular code, and that
would be a worse thing.

Note that direct use of __initcall is discouraged, vs. one
of the priority categorized subgroups.  As __initcall gets
mapped onto device_initcall, our use of fs_initcall (which
makes sense for fs code) will thus change this registration
from level 6-device to level 5-fs (i.e. slightly earlier).
However no observable impact of that small difference has
been observed during testing, or is expected.

Also note that this change uncovers a missing semicolon bug in
the registration of the initcall.

Signed-off-by: Paul Gortmaker 
---
 fs/ramfs/inode.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/fs/ramfs/inode.c b/fs/ramfs/inode.c
index 03b8016e5bbc..d365b1c4eb3c 100644
--- a/fs/ramfs/inode.c
+++ b/fs/ramfs/inode.c
@@ -282,4 +282,4 @@ int __init init_ramfs_fs(void)
 
return err;
 }
-module_init(init_ramfs_fs)
+fs_initcall(init_ramfs_fs);
-- 
1.8.5.2

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


[PATCH 1/1] Drivers: input: serio:hyperv-keyoard: Handle 0xE1 prefix

2014-01-11 Thread K. Y. Srinivasan
Handle the 0xE1 prefix.

Signed-off-by: K. Y. Srinivasan 
---
 drivers/input/serio/hyperv-keyboard.c |4 +++-
 1 files changed, 3 insertions(+), 1 deletions(-)

diff --git a/drivers/input/serio/hyperv-keyboard.c 
b/drivers/input/serio/hyperv-keyboard.c
index 3a83c3c..6132619 100644
--- a/drivers/input/serio/hyperv-keyboard.c
+++ b/drivers/input/serio/hyperv-keyboard.c
@@ -160,7 +160,9 @@ static void hv_kbd_on_receive(struct hv_device *hv_dev,
if (info & IS_E0)
serio_interrupt(kbd_dev->hv_serio,
XTKBD_EMUL0, 0);
-
+   if (info & IS_E1)
+   serio_interrupt(kbd_dev->hv_serio,
+   XTKBD_EMUL1, 0);
scan_code = __le16_to_cpu(ks_msg->make_code);
if (info & IS_BREAK)
scan_code |= XTKBD_RELEASE;
-- 
1.7.4.1

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


[PATCH 4/5] x86, mpx: add MPX related opcodes to the x86 opcode map

2014-01-11 Thread Qiaowei Ren
This patch adds all the MPX instructions to x86 opcode map, and then
the x86 instruction decoder can decode MPX instructions used in kernel.

Signed-off-by: Qiaowei Ren 
---
 arch/x86/lib/x86-opcode-map.txt |4 ++--
 1 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/arch/x86/lib/x86-opcode-map.txt b/arch/x86/lib/x86-opcode-map.txt
index 533a85e..1a2be7c 100644
--- a/arch/x86/lib/x86-opcode-map.txt
+++ b/arch/x86/lib/x86-opcode-map.txt
@@ -346,8 +346,8 @@ AVXcode: 1
 17: vmovhps Mq,Vq (v1) | vmovhpd Mq,Vq (66),(v1)
 18: Grp16 (1A)
 19:
-1a:
-1b:
+1a: BNDCL Ev,Gv | BNDCU Ev,Gv | BNDMOV Gv,Ev | BNDLDX Gv,Ev,Gv
+1b: BNDCN Ev,Gv | BNDMOV Ev,Gv | BNDMK Gv,Ev | BNDSTX Ev,GV,Gv
 1c:
 1d:
 1e:
-- 
1.7.1

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


[PATCH 3/5] x86, mpx: add prctl commands PR_MPX_INIT, PR_MPX_RELEASE

2014-01-11 Thread Qiaowei Ren
This patch adds the PR_MPX_INIT and PR_MPX_RELEASE prctl()
commands on the x86 platform. These commands can be used to
init and release MPX related resource.

A MMU notifier will be registered during PR_MPX_INIT
command execution. So the bound tables can be automatically
deallocated when one memory area is unmapped.

Signed-off-by: Qiaowei Ren 
---
 arch/x86/Kconfig |4 ++
 arch/x86/include/asm/mpx.h   |9 
 arch/x86/include/asm/processor.h |   16 +++
 arch/x86/kernel/mpx.c|   84 ++
 include/uapi/linux/prctl.h   |6 +++
 kernel/sys.c |   12 +
 6 files changed, 131 insertions(+), 0 deletions(-)

diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig
index ee2fb9d..695101a 100644
--- a/arch/x86/Kconfig
+++ b/arch/x86/Kconfig
@@ -233,6 +233,10 @@ config HAVE_INTEL_TXT
def_bool y
depends on INTEL_IOMMU && ACPI
 
+config HAVE_INTEL_MPX
+   def_bool y
+   select MMU_NOTIFIER
+
 config X86_32_SMP
def_bool y
depends on X86_32 && SMP
diff --git a/arch/x86/include/asm/mpx.h b/arch/x86/include/asm/mpx.h
index d074153..9652e9e 100644
--- a/arch/x86/include/asm/mpx.h
+++ b/arch/x86/include/asm/mpx.h
@@ -30,6 +30,15 @@
 
 #endif
 
+typedef union {
+   struct {
+   unsigned long ignored:MPX_IGN_BITS;
+   unsigned long l2index:MPX_L2_BITS;
+   unsigned long l1index:MPX_L1_BITS;
+   };
+   unsigned long addr;
+} mpx_addr;
+
 void do_mpx_bt_fault(struct xsave_struct *xsave_buf);
 
 #endif /* _ASM_X86_MPX_H */
diff --git a/arch/x86/include/asm/processor.h b/arch/x86/include/asm/processor.h
index 43be6f6..ea4e72d 100644
--- a/arch/x86/include/asm/processor.h
+++ b/arch/x86/include/asm/processor.h
@@ -963,6 +963,22 @@ extern void start_thread(struct pt_regs *regs, unsigned 
long new_ip,
 extern int get_tsc_mode(unsigned long adr);
 extern int set_tsc_mode(unsigned int val);
 
+#ifdef CONFIG_HAVE_INTEL_MPX
+
+/* Init/release a process' MPX related resource */
+#define MPX_INIT(tsk)  mpx_init((tsk))
+#define MPX_RELEASE(tsk)   mpx_release((tsk))
+
+extern int mpx_init(struct task_struct *tsk);
+extern int mpx_release(struct task_struct *tsk);
+
+#else /* CONFIG_HAVE_INTEL_MPX */
+
+#define MPX_INIT(tsk)  (-EINVAL)
+#define MPX_RELEASE(tsk)   (-EINVAL)
+
+#endif /* CONFIG_HAVE_INTEL_MPX */
+
 extern u16 amd_get_nb_id(int cpu);
 
 static inline uint32_t hypervisor_cpuid_base(const char *sig, uint32_t leaves)
diff --git a/arch/x86/kernel/mpx.c b/arch/x86/kernel/mpx.c
index 767b3bf..ffe5aee 100644
--- a/arch/x86/kernel/mpx.c
+++ b/arch/x86/kernel/mpx.c
@@ -1,5 +1,7 @@
 #include 
 #include 
+#include 
+#include 
 #include 
 #include 
 #include 
@@ -7,6 +9,88 @@
 #include 
 #include 
 
+static struct mmu_notifier mpx_mn;
+
+static void mpx_invl_range_end(struct mmu_notifier *mn,
+   struct mm_struct *mm,
+   unsigned long start, unsigned long end)
+{
+   struct xsave_struct *xsave_buf;
+   unsigned long bt_size = 1UL << (MPX_L2_BITS+MPX_L2_SHIFT);
+   unsigned long bt_addr;
+   unsigned long bd_base;
+   unsigned long bd_entry, bde_start, bde_end;
+   mpx_addr lap;
+
+   pgd_t *pgd;
+   pud_t *pud;
+   pmd_t *pmd;
+   pte_t *pte;
+
+   /* ignore swap notifications */
+   pgd = pgd_offset(mm, start);
+   pud = pud_offset(pgd, start);
+   pmd = pmd_offset(pud, start);
+   pte = pte_offset_kernel(pmd, start);
+   if (!pte_present(*pte) && !pte_none(*pte) && !pte_file(*pte))
+   return;
+
+   /* get bound directory base address */
+   fpu_xsave(¤t->thread.fpu);
+   xsave_buf = &(current->thread.fpu.state->xsave);
+   bd_base = xsave_buf->bndcsr.cfg_reg_u & MPX_BNDCFG_ADDR_MASK;
+
+   /* get related bde range */
+   lap.addr = start;
+   bde_start = bd_base + (lap.l1index << MPX_L1_SHIFT);
+
+   lap.addr = end;
+   if (lap.ignored || lap.l2index)
+   bde_end = bd_base + (lap.l1indexmm);
+
+   return 0;
+}
+
 static bool allocate_bt(unsigned long bd_entry)
 {
unsigned long bt_size = 1UL << (MPX_L2_BITS+MPX_L2_SHIFT);
diff --git a/include/uapi/linux/prctl.h b/include/uapi/linux/prctl.h
index 289760f..19ab881 100644
--- a/include/uapi/linux/prctl.h
+++ b/include/uapi/linux/prctl.h
@@ -149,4 +149,10 @@
 
 #define PR_GET_TID_ADDRESS 40
 
+/*
+ * Init/release MPX related resource.
+ */
+#define PR_MPX_INIT41
+#define PR_MPX_RELEASE 42
+
 #endif /* _LINUX_PRCTL_H */
diff --git a/kernel/sys.c b/kernel/sys.c
index c18ecca..bbaf573 100644
--- a/kernel/sys.c
+++ b/kernel/sys.c
@@ -92,6 +92,12 @@
 #ifndef SET_TSC_CTL
 # define SET_TSC

[PATCH 1/5] x86, mpx: add documentation on Intel MPX

2014-01-11 Thread Qiaowei Ren
This patch adds the Documentation/x86/intel_mpx.txt file with some
information about Intel MPX.

Signed-off-by: Qiaowei Ren 
---
 Documentation/x86/intel_mpx.txt |   76 +++
 1 files changed, 76 insertions(+), 0 deletions(-)
 create mode 100644 Documentation/x86/intel_mpx.txt

diff --git a/Documentation/x86/intel_mpx.txt b/Documentation/x86/intel_mpx.txt
new file mode 100644
index 000..778d06e
--- /dev/null
+++ b/Documentation/x86/intel_mpx.txt
@@ -0,0 +1,76 @@
+Intel(R) MPX Overview:
+=
+
+Intel(R) Memory Protection Extensions (Intel(R) MPX) is a new
+capability introduced into Intel Architecture. Intel MPX can
+increase the robustness of software when it is used in conjunction
+with compiler changes to check that memory references intended
+at compile time do not become unsafe at runtime.
+
+Two of the most important goals of Intel MPX are to provide
+this capability at very low performance overhead for newly
+compiled code, and to provide compatibility mechanisms with
+legacy software components. A direct benefit Intel MPX provides
+is hardening software against malicious attacks designed to
+cause or exploit buffer overruns.
+
+For details about the Intel MPX instructions, see "Intel(R)
+Architecture Instruction Set Extensions Programming Reference".
+
+Intel(R) MPX Programming Model
+--
+
+Intel MPX introduces new registers and new instructions that
+operate on these registers. Some of the registers added are
+bounds registers which store a pointer's lower bound and upper
+bound limits. Whenever the pointer is used, the requested
+reference is checked against the pointer's associated bounds,
+thereby preventing out-of-bound memory access (such as buffer
+overflows and overruns). Out-of-bounds memory references
+initiate a #BR exception which can then be handled in an
+appropriate manner.
+
+Loading and Storing Bounds using Translation
+
+
+Intel MPX defines two instructions for load/store of the linear
+address of a pointer to a buffer, along with the bounds of the
+buffer into a paging structure of extended bounds. Specifically
+when storing extended bounds, the processor will perform address
+translation of the address where the pointer is stored to an
+address in the Bound Table (BT) to determine the store location
+of extended bounds. Loading of an extended bounds performs the
+reverse sequence.
+
+The structure in memory to load/store an extended bound is a
+4-tuple consisting of lower bound, upper bound, pointer value
+and a reserved field. Bound loads and stores access 32-bit or
+64-bit operand size according to the operation mode. Thus,
+a bound table entry is 4*32 bits in 32-bit mode and 4*64 bits
+in 64-bit mode.
+
+The linear address of a bound table is stored in a Bound
+Directory (BD) entry. And the linear address of the bound
+directory is derived from either BNDCFGU or BNDCFGS registers.
+Bounds in memory are stored in Bound Tables (BT) as an extended
+bound, which are accessed via Bound Directory (BD) and address
+translation performed by BNDLDX/BNDSTX instructions.
+
+Bounds Directory (BD) and Bounds Tables (BT) are stored in
+application memory and are allocated by the application (in case
+of kernel use, the structures will be in kernel memory). The
+bound directory and each instance of bound table are in contiguous
+linear memory.
+
+XSAVE/XRESTOR Support of Intel MPX State
+
+
+Enabling Intel MPX requires an OS to manage two bits in XCR0:
+  - BNDREGS for saving and restoring registers BND0-BND3,
+  - BNDCSR for saving and restoring the user-mode configuration
+(BNDCFGU) and the status register (BNDSTATUS).
+
+The reason for having two separate bits is that BND0-BND3 is
+likely to be volatile state, while BNDCFGU and BNDSTATUS are not.
+Therefore, an OS has flexibility in handling these two states
+differently in saving or restoring them.
-- 
1.7.1

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


[PATCH 2/5] x86, mpx: hook #BR exception handler to allocate bound tables

2014-01-11 Thread Qiaowei Ren
An access to an invalid bound directory entry will cause a #BR
exception. This patch hook #BR exception handler to allocate
one bound table and bind it with that buond directory entry.

This will avoid the need of forwarding the #BR exception
to the user space when bound directory has invalid entry.

Signed-off-by: Qiaowei Ren 
---
 arch/x86/include/asm/mpx.h |   35 +
 arch/x86/kernel/Makefile   |1 +
 arch/x86/kernel/mpx.c  |   44 ++
 arch/x86/kernel/traps.c|   46 +++-
 4 files changed, 125 insertions(+), 1 deletions(-)
 create mode 100644 arch/x86/include/asm/mpx.h
 create mode 100644 arch/x86/kernel/mpx.c

diff --git a/arch/x86/include/asm/mpx.h b/arch/x86/include/asm/mpx.h
new file mode 100644
index 000..d074153
--- /dev/null
+++ b/arch/x86/include/asm/mpx.h
@@ -0,0 +1,35 @@
+#ifndef _ASM_X86_MPX_H
+#define _ASM_X86_MPX_H
+
+#include 
+#include 
+
+#ifdef CONFIG_X86_64
+
+#define MPX_L1_BITS28
+#define MPX_L1_SHIFT   3
+#define MPX_L2_BITS17
+#define MPX_L2_SHIFT   5
+#define MPX_IGN_BITS   3
+#define MPX_L2_NODE_ADDR_MASK  0xfff8UL
+
+#define MPX_BNDSTA_ADDR_MASK   0xfffcUL
+#define MPX_BNDCFG_ADDR_MASK   0xf000UL
+
+#else
+
+#define MPX_L1_BITS20
+#define MPX_L1_SHIFT   2
+#define MPX_L2_BITS10
+#define MPX_L2_SHIFT   4
+#define MPX_IGN_BITS   2
+#define MPX_L2_NODE_ADDR_MASK  0xfffcUL
+
+#define MPX_BNDSTA_ADDR_MASK   0xfffcUL
+#define MPX_BNDCFG_ADDR_MASK   0xf000UL
+
+#endif
+
+void do_mpx_bt_fault(struct xsave_struct *xsave_buf);
+
+#endif /* _ASM_X86_MPX_H */
diff --git a/arch/x86/kernel/Makefile b/arch/x86/kernel/Makefile
index a5408b9..bba7a71 100644
--- a/arch/x86/kernel/Makefile
+++ b/arch/x86/kernel/Makefile
@@ -38,6 +38,7 @@ obj-y += resource.o
 
 obj-y  += process.o
 obj-y  += i387.o xsave.o
+obj-y  += mpx.o
 obj-y  += ptrace.o
 obj-$(CONFIG_X86_32)   += tls.o
 obj-$(CONFIG_IA32_EMULATION)   += tls.o
diff --git a/arch/x86/kernel/mpx.c b/arch/x86/kernel/mpx.c
new file mode 100644
index 000..767b3bf
--- /dev/null
+++ b/arch/x86/kernel/mpx.c
@@ -0,0 +1,44 @@
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+static bool allocate_bt(unsigned long bd_entry)
+{
+   unsigned long bt_size = 1UL << (MPX_L2_BITS+MPX_L2_SHIFT);
+   unsigned long bt_addr, old_val;
+
+   bt_addr = sys_mmap_pgoff(0, bt_size, PROT_READ | PROT_WRITE,
+   MAP_ANONYMOUS | MAP_PRIVATE | MAP_POPULATE, -1, 0);
+   if (bt_addr == -1) {
+   pr_err("L2 Node Allocation Failed at L1 addr %lx\n",
+   bd_entry);
+   return false;
+   }
+   bt_addr = (bt_addr & MPX_L2_NODE_ADDR_MASK) | 0x01;
+
+   user_atomic_cmpxchg_inatomic(&old_val,
+   (long __user *)bd_entry, 0, bt_addr);
+   if (old_val)
+   vm_munmap(bt_addr & MPX_L2_NODE_ADDR_MASK, bt_size);
+
+   return true;
+}
+
+void do_mpx_bt_fault(struct xsave_struct *xsave_buf)
+{
+   unsigned long status;
+   unsigned long bd_entry, bd_base;
+   unsigned long bd_size = 1UL << (MPX_L1_BITS+MPX_L1_SHIFT);
+
+   bd_base = xsave_buf->bndcsr.cfg_reg_u & MPX_BNDCFG_ADDR_MASK;
+   status = xsave_buf->bndcsr.status_reg;
+
+   bd_entry = status & MPX_BNDSTA_ADDR_MASK;
+   if ((bd_entry >= bd_base) && (bd_entry < bd_base + bd_size))
+   allocate_bt(bd_entry);
+}
diff --git a/arch/x86/kernel/traps.c b/arch/x86/kernel/traps.c
index 8c8093b..eb04039 100644
--- a/arch/x86/kernel/traps.c
+++ b/arch/x86/kernel/traps.c
@@ -59,6 +59,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #ifdef CONFIG_X86_64
 #include 
@@ -214,7 +215,6 @@ dotraplinkage void do_##name(struct pt_regs *regs, long 
error_code) \
 DO_ERROR_INFO(X86_TRAP_DE, SIGFPE, "divide error", divide_error, FPE_INTDIV,
regs->ip)
 DO_ERROR(X86_TRAP_OF, SIGSEGV, "overflow", overflow)
-DO_ERROR(X86_TRAP_BR, SIGSEGV, "bounds", bounds)
 DO_ERROR_INFO(X86_TRAP_UD, SIGILL, "invalid opcode", invalid_op, ILL_ILLOPN,
regs->ip)
 DO_ERROR(X86_TRAP_OLD_MF, SIGFPE, "coprocessor segment overrun",
@@ -267,6 +267,50 @@ dotraplinkage void do_double_fault(struct pt_regs *regs, 
long error_code)
 }
 #endif
 
+dotraplinkage void do_bounds(struct pt_regs *regs, long error_code)
+{
+   enum ctx_state prev_state;
+   unsigned long status;
+   struct xsave_struct *xsave_buf;
+   struct task_struct *tsk = current;
+
+   prev_state = exception_enter();
+   if (notify_die(DIE_TRAP, "bounds", regs, error_code,
+   X86_TRAP_BR, SIGSEGV) == NOTIFY_STOP)
+   goto exit;
+   conditional_sti(regs);
+
+   if (!boot_cpu_has(X86_FEATURE_MPX)) {
+ 

[PATCH 5/5] x86, mpx: extend siginfo structure to include bound violation information

2014-01-11 Thread Qiaowei Ren
This patch adds new fields about bound violation into siginfo
structure. si_lower and si_upper are respectively lower bound
and upper bound when bound violation is caused.

These fields will be set in #BR exception handler by decoding
the user instruction and constructing the faulting pointer.
A userspace application can get violation address, lower bound
and upper bound for bound violation from this new siginfo structure.

Signed-off-by: Qiaowei Ren 
---
 arch/x86/include/asm/mpx.h |   39 +
 arch/x86/kernel/mpx.c  |  289 
 arch/x86/kernel/traps.c|6 +
 include/uapi/asm-generic/siginfo.h |9 +-
 kernel/signal.c|4 +
 5 files changed, 346 insertions(+), 1 deletions(-)

diff --git a/arch/x86/include/asm/mpx.h b/arch/x86/include/asm/mpx.h
index 9652e9e..8c1c914 100644
--- a/arch/x86/include/asm/mpx.h
+++ b/arch/x86/include/asm/mpx.h
@@ -30,6 +30,43 @@
 
 #endif
 
+struct mpx_insn_field {
+   union {
+   signed int value;
+   unsigned char bytes[4];
+   };
+   unsigned char nbytes;
+};
+
+struct mpx_insn {
+   struct mpx_insn_field rex_prefix;   /* REX prefix */
+   struct mpx_insn_field modrm;
+   struct mpx_insn_field sib;
+   struct mpx_insn_field displacement;
+
+   unsigned char addr_bytes;   /* effective address size */
+   unsigned char limit;
+   unsigned char x86_64;
+
+   const unsigned char *kaddr; /* kernel address of insn to analyze */
+   const unsigned char *next_byte;
+};
+
+#define MAX_MPX_INSN_SIZE  15
+
+#define X86_MODRM_MOD(modrm) (((modrm) & 0xc0) >> 6)
+#define X86_MODRM_REG(modrm) (((modrm) & 0x38) >> 3)
+#define X86_MODRM_RM(modrm) ((modrm) & 0x07)
+
+#define X86_SIB_SCALE(sib) (((sib) & 0xc0) >> 6)
+#define X86_SIB_INDEX(sib) (((sib) & 0x38) >> 3)
+#define X86_SIB_BASE(sib) ((sib) & 0x07)
+
+#define X86_REX_W(rex) ((rex) & 8)
+#define X86_REX_R(rex) ((rex) & 4)
+#define X86_REX_X(rex) ((rex) & 2)
+#define X86_REX_B(rex) ((rex) & 1)
+
 typedef union {
struct {
unsigned long ignored:MPX_IGN_BITS;
@@ -40,5 +77,7 @@ typedef union {
 } mpx_addr;
 
 void do_mpx_bt_fault(struct xsave_struct *xsave_buf);
+void do_mpx_bounds(struct pt_regs *regs, siginfo_t *info,
+   struct xsave_struct *xsave_buf);
 
 #endif /* _ASM_X86_MPX_H */
diff --git a/arch/x86/kernel/mpx.c b/arch/x86/kernel/mpx.c
index ffe5aee..3770991 100644
--- a/arch/x86/kernel/mpx.c
+++ b/arch/x86/kernel/mpx.c
@@ -91,6 +91,269 @@ int mpx_release(struct task_struct *tsk)
return 0;
 }
 
+typedef enum {REG_TYPE_RM, REG_TYPE_INDEX, REG_TYPE_BASE} reg_type_t;
+static unsigned long get_reg(struct mpx_insn *insn, struct pt_regs *regs,
+reg_type_t type)
+{
+   int regno = 0;
+   unsigned char modrm = (unsigned char)insn->modrm.value;
+   unsigned char sib = (unsigned char)insn->sib.value;
+
+   static const int regoff[] = {
+   offsetof(struct pt_regs, ax),
+   offsetof(struct pt_regs, cx),
+   offsetof(struct pt_regs, dx),
+   offsetof(struct pt_regs, bx),
+   offsetof(struct pt_regs, sp),
+   offsetof(struct pt_regs, bp),
+   offsetof(struct pt_regs, si),
+   offsetof(struct pt_regs, di),
+#ifdef CONFIG_X86_64
+   offsetof(struct pt_regs, r8),
+   offsetof(struct pt_regs, r9),
+   offsetof(struct pt_regs, r10),
+   offsetof(struct pt_regs, r11),
+   offsetof(struct pt_regs, r12),
+   offsetof(struct pt_regs, r13),
+   offsetof(struct pt_regs, r14),
+   offsetof(struct pt_regs, r15),
+#endif
+   };
+
+   switch (type) {
+   case REG_TYPE_RM:
+   regno = X86_MODRM_RM(modrm);
+   if (X86_REX_B(insn->rex_prefix.value) == 1)
+   regno += 8;
+   break;
+
+   case REG_TYPE_INDEX:
+   regno = X86_SIB_INDEX(sib);
+   if (X86_REX_X(insn->rex_prefix.value) == 1)
+   regno += 8;
+   break;
+
+   case REG_TYPE_BASE:
+   regno = X86_SIB_BASE(sib);
+   if (X86_REX_B(insn->rex_prefix.value) == 1)
+   regno += 8;
+   break;
+
+   default:
+   break;
+   }
+
+   return regs_get_register(regs, regoff[regno]);
+}
+
+/*
+ * return the address being referenced be instruction
+ * for rm=3 returning the content of the rm reg
+ * for rm!=3 calculates the address using SIB and Disp
+ */
+static unsigned long get_addr_ref(struct mpx_insn *insn, struct pt_regs *regs)
+{
+   unsigned long addr;
+   unsigned long base;
+   unsigned long indx;
+   unsigned char modrm = (unsigned char)insn->modrm.value;
+   unsigned char sib = (unsigned char)insn->sib.value;
+
+   if (X86_MODRM

[PATCH 1/1] When timestamping is enabled, stmmac_tx_clean will call stmmac_get_tx_hwtstamp to get tx TS. It's possible that skb is NULL because there are other network frames that use several descript

2014-01-11 Thread damuzi000

Signed-off-by: damuzi000 
---
 drivers/net/ethernet/stmicro/stmmac/stmmac_main.c |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c 
b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
index 797b56a..47f2287 100644
--- a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
+++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
@@ -332,7 +332,7 @@ static void stmmac_get_tx_hwtstamp(struct stmmac_priv *priv,
return;
 
/* exit if skb doesn't support hw tstamp */
-   if (likely(!(skb_shinfo(skb)->tx_flags & SKBTX_IN_PROGRESS)))
+   if (likely(!skb || !(skb_shinfo(skb)->tx_flags & SKBTX_IN_PROGRESS)))
return;
 
if (priv->adv_ts)
-- 
1.7.9.5

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


[PATCH v3] arch: use ASM_NL instead of ';' for assembler new line character in the macro

2014-01-11 Thread Chen Gang
For some assemblers, they use another character as newline in a macro
(e.g. arc uses '`'), so for generic assembly code, need use ASM_NL (a
macro) instead of ';' for it.


Signed-off-by: Chen Gang 
Acked-by: Vineet Gupta 
---
 arch/arc/include/asm/linkage.h |  2 ++
 include/linux/linkage.h| 19 ---
 2 files changed, 14 insertions(+), 7 deletions(-)

diff --git a/arch/arc/include/asm/linkage.h b/arch/arc/include/asm/linkage.h
index 0283e9e..66ee552 100644
--- a/arch/arc/include/asm/linkage.h
+++ b/arch/arc/include/asm/linkage.h
@@ -11,6 +11,8 @@
 
 #ifdef __ASSEMBLY__
 
+#define ASM_NL  `  /* use '`' to mark new line in macro */
+
 /* Can't use the ENTRY macro in linux/linkage.h
  * gas considers ';' as comment vs. newline
  */
diff --git a/include/linux/linkage.h b/include/linux/linkage.h
index d3e8ad2..a6a42dd 100644
--- a/include/linux/linkage.h
+++ b/include/linux/linkage.h
@@ -6,6 +6,11 @@
 #include 
 #include 
 
+/* Some toolchains use other characters (e.g. '`') to mark new line in macro */
+#ifndef ASM_NL
+#define ASM_NL  ;
+#endif
+
 #ifdef __cplusplus
 #define CPP_ASMLINKAGE extern "C"
 #else
@@ -75,21 +80,21 @@
 
 #ifndef ENTRY
 #define ENTRY(name) \
-  .globl name; \
-  ALIGN; \
-  name:
+   .globl name ASM_NL \
+   ALIGN ASM_NL \
+   name:
 #endif
 #endif /* LINKER_SCRIPT */
 
 #ifndef WEAK
 #define WEAK(name)\
-   .weak name;\
+   .weak name ASM_NL   \
name:
 #endif
 
 #ifndef END
 #define END(name) \
-  .size name, .-name
+   .size name, .-name
 #endif
 
 /* If symbol 'name' is treated as a subroutine (gets called, and returns)
@@ -98,8 +103,8 @@
  */
 #ifndef ENDPROC
 #define ENDPROC(name) \
-  .type name, @function; \
-  END(name)
+   .type name, @function ASM_NL \
+   END(name)
 #endif
 
 #endif
-- 
1.7.11.7
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


Re: Problem: Possible regression in intel_pstate on 3.12

2014-01-11 Thread Joakim Hernberg
Hello Dirk,

I don't seem to be able to apply this patch?  For what kernel is it
meant, and is it complete?

Best wishes,

On Mon, 16 Dec 2013 09:28:19 -0800
Dirk Brandewie  wrote:

> Hi Joakim,
> 
> Add the following patch to your v3.12 kernel and collect some data
> with the command and send the resulting perf.data file:
>  perf record -a -c 1 -e power:pstate_sample sleep 10
> 
> 
> TIA
> --Dirk
> 
> commit b3dc2c2a106cea68e4c9c0f4747b15291113c4ae
> Author: Dirk Brandewie 
> Date:   Mon Dec 2 09:56:46 2013 -0800
> 
>  intel_pstate: Add trace point to report internal state.
> 
>  Add perf trace event "power:pstate_sample" to report driver
> state to aid in diagnosing issues reported against intel_pstate.
> 
>  Signed-off-by: Dirk Brandewie 
> ---
>   drivers/cpufreq/intel_pstate.c | 22 ++
>   include/trace/events/power.h   | 53
> ++ 2 files changed, 75
> insertions(+)
> 
> diff --git a/drivers/cpufreq/intel_pstate.c
> b/drivers/cpufreq/intel_pstate.c index 5f1cbae..c4f14d1 100644
> --- a/drivers/cpufreq/intel_pstate.c
> +++ b/drivers/cpufreq/intel_pstate.c
> @@ -50,6 +50,8 @@ static inline int32_t div_fp(int32_t x, int32_t y)
>   return div_s64((int64_t)x << FRAC_BITS, (int64_t)y);
>   }
> 
> +static u64 energy_divisor;
> +
>   struct sample {
>   int32_t core_pct_busy;
>   u64 aperf;
> @@ -512,6 +514,7 @@ static inline void intel_pstate_sample(struct
> cpudata *cpu)
> 
>   rdmsrl(MSR_IA32_APERF, aperf);
>   rdmsrl(MSR_IA32_MPERF, mperf);
> +
>   cpu->sample_ptr = (cpu->sample_ptr + 1) % SAMPLE_COUNT;
>   cpu->samples[cpu->sample_ptr].aperf = aperf;
>   cpu->samples[cpu->sample_ptr].mperf = mperf;
> @@ -565,10 +568,24 @@ static inline void
> intel_pstate_adjust_busy_pstate(struct cpudata *cpu)
>   static void intel_pstate_timer_func(unsigned long __data)
>   {
>   struct cpudata *cpu = (struct cpudata *) __data;
> + struct sample *sample;
> + u64 energy;
> 
>   intel_pstate_sample(cpu);
> +
> + sample = &cpu->samples[cpu->sample_ptr];
> + rdmsrl(MSR_PKG_ENERGY_STATUS, energy);
> +
>   intel_pstate_adjust_busy_pstate(cpu);
> 
> + trace_pstate_sample(fp_toint(sample->core_pct_busy),
> + fp_toint(intel_pstate_get_scaled_busy(cpu)),
> + cpu->pstate.current_pstate,
> + sample->mperf,
> + sample->aperf,
> + energy/energy_divisor,
> + sample->freq);
> +
>   if (cpu->pstate.current_pstate == cpu->pstate.min_pstate) {
>   cpu->min_pstate_count++;
>   if (!(cpu->min_pstate_count % 5)) {
> @@ -849,6 +866,7 @@ static int __init intel_pstate_init(void)
>   int cpu, rc = 0;
>   const struct x86_cpu_id *id;
>   struct cpu_defaults *cpu_info;
> + u64 units;
> 
>   if (no_load)
>   return -ENODEV;
> @@ -882,8 +900,12 @@ static int __init intel_pstate_init(void)
>   if (rc)
>   goto out;
> 
> + rdmsrl(MSR_RAPL_POWER_UNIT, units);
> + energy_divisor = 1 << ((units >> 8) & 0x1f); /* bits{12:8} */
> +
>   intel_pstate_debug_expose_params();
>   intel_pstate_sysfs_expose_params();
> +
>   return rc;
>   out:
>   get_online_cpus();
> diff --git a/include/trace/events/power.h
> b/include/trace/events/power.h index cda100d..9e9475c 100644
> --- a/include/trace/events/power.h
> +++ b/include/trace/events/power.h
> @@ -35,6 +35,59 @@ DEFINE_EVENT(cpu, cpu_idle,
>   TP_ARGS(state, cpu_id)
>   );
> 
> +TRACE_EVENT(pstate_sample,
> +
> + TP_PROTO(u32 core_busy,
> + u32 scaled_busy,
> + u32 state,
> + u64 mperf,
> + u64 aperf,
> + u32 energy,
> + u32 freq
> + ),
> +
> + TP_ARGS(core_busy,
> + scaled_busy,
> + state,
> + mperf,
> + aperf,
> + energy,
> + freq
> + ),
> +
> + TP_STRUCT__entry(
> + __field(u32, core_busy)
> + __field(u32, scaled_busy)
> + __field(u32, state)
> + __field(u64, mperf)
> + __field(u64, aperf)
> + __field(u32, energy)
> + __field(u32, freq)
> +
> + ),
> +



-- 

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


Fwd: how to determine kernel interrupt latency

2014-01-11 Thread loody
hi all:
is it possible to determine interrupt latency in kernel with any ftrace or proc?

Appreciate your help in advance.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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/9] re-shrink 'struct page' when SLUB is on.

2014-01-11 Thread Christoph Lameter
On Sat, 11 Jan 2014, Pekka Enberg wrote:

> On Sat, Jan 11, 2014 at 1:42 AM, Dave Hansen  wrote:
> > On 01/10/2014 03:39 PM, Andrew Morton wrote:
> >>> I tested 4 cases, all of these on the "cache-cold kfree()" case.  The
> >>> first 3 are with vanilla upstream kernel source.  The 4th is patched
> >>> with my new slub code (all single-threaded):
> >>>
> >>>  http://www.sr71.net/~dave/intel/slub/slub-perf-20140109.png
> >>
> >> So we're converging on the most complex option.  argh.
> >
> > Yeah, looks that way.
>
> Seems like a reasonable compromise between memory usage and allocation speed.
>
> Christoph?

Fundamentally I think this is good. I need to look at the details but I am
only going to be able to do that next week when I am back in the office.

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


[RFT][PATCH] ACPI / init: Run acpi_early_init() before efi_enter_virtual_mode() (was: Re: [RFC PATCH 00/14] Support timezone of ACPI TAD and EFI TIME)

2014-01-11 Thread Rafael J. Wysocki
On Saturday, December 21, 2013 12:21:48 PM Matt Fleming wrote:
> On Fri, 20 Dec, at 11:18:56PM, Rafael J. Wysocki wrote:
> > 
> > I'm not sure 100%, but I *think* we need to do that with interrupts enabled.
> > At least after mm_init(), because it relies on things initialized there if I
> > remember correctly.
> > 
> > From what I can tell at the moment, it might be possible to move it before
> > efi_enter_virtual_mode() if that would help.
> 
> Actually yeah, that would be super useful, and I think we'd be able to
> get rid of the whole efi_late_init() stuff because we'd no longer need
> to hang on to the EFI_BOOT_SERVICES* regions after
> SetVirtualAddressMap().

OK

I don't see any adverse effects of the patch below on a couple of my test
boxes, but (a) they are Intel-based and (b) they are non-EFI, so it would be
good to give it a go on as many machines as reasonably possible.

Thanks,
Rafael

---
From: Rafael J. Wysocki 
Subject: ACPI / init: Run acpi_early_init() before efi_enter_virtual_mode()

According to Matt Fleming, if acpi_early_init() was executed befpre
efi_enter_virtual_mode(), the EFI initialization could benefit from
it, so make that happen.

Signed-off-by: Rafael J. Wysocki 
---
 init/main.c |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

Index: linux-pm/init/main.c
===
--- linux-pm.orig/init/main.c
+++ linux-pm/init/main.c
@@ -615,6 +615,7 @@ asmlinkage void __init start_kernel(void
calibrate_delay();
pidmap_init();
anon_vma_init();
+   acpi_early_init();
 #ifdef CONFIG_X86
if (efi_enabled(EFI_RUNTIME_SERVICES))
efi_enter_virtual_mode();
@@ -641,7 +642,6 @@ asmlinkage void __init start_kernel(void
 
check_bugs();
 
-   acpi_early_init(); /* before LAPIC and SMP init */
sfi_init_late();
 
if (efi_enabled(EFI_RUNTIME_SERVICES)) {

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


[PATCH v2 0/2] Staging: rtl8188eu: checkpatch.pl error cleanups

2014-01-11 Thread Tim Jester-Pfadt
This patchset fixes all occurrences of the "space required after ','" "space
required around '='" aswell as "foo * bar" related checkpatch.pl errors in
rtl8188eu.

The patchset does not fix the remaining 80 character limit warnings, sinc this
might require more substantial code modification.

v2: Patched against the staging-next branch as requested by Greg KH.

Tim Jester-Pfadt (2):
  Staging: rtl8188eu: Fixed required spaces after ',' and around '=' and
'=='
  Staging: rtl8188eu: Fixed "foo * bar" related coding style issues

 drivers/staging/rtl8188eu/include/Hal8188EPwrSeq.h |  2 +-
 drivers/staging/rtl8188eu/include/odm.h|  2 +-
 drivers/staging/rtl8188eu/include/odm_debug.h  |  2 +-
 drivers/staging/rtl8188eu/include/odm_interface.h  |  2 +-
 drivers/staging/rtl8188eu/include/rtl8188e_hal.h   |  4 ++--
 drivers/staging/rtl8188eu/include/rtl8188e_recv.h  |  6 +++---
 drivers/staging/rtl8188eu/include/rtw_eeprom.h |  2 +-
 drivers/staging/rtl8188eu/include/rtw_efuse.h  |  2 +-
 drivers/staging/rtl8188eu/include/rtw_ioctl_set.h  |  4 ++--
 drivers/staging/rtl8188eu/include/rtw_iol.h|  8 
 drivers/staging/rtl8188eu/include/rtw_led.h|  6 +++---
 drivers/staging/rtl8188eu/include/rtw_mlme.h   |  8 
 drivers/staging/rtl8188eu/include/rtw_mlme_ext.h   | 12 ++--
 drivers/staging/rtl8188eu/include/rtw_mp.h | 10 +-
 drivers/staging/rtl8188eu/include/rtw_mp_ioctl.h   |  2 +-
 drivers/staging/rtl8188eu/include/rtw_security.h   |  2 +-
 drivers/staging/rtl8188eu/include/wifi.h   |  2 +-
 17 files changed, 38 insertions(+), 38 deletions(-)

-- 
1.8.5.2

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


[PATCH v2 2/2] Staging: rtl8188eu: Fixed "foo * bar" related coding style issues

2014-01-11 Thread Tim Jester-Pfadt
This patch fixes all "foo * bar", "foo*bar", "foo* bar" checkpatch.pl errors for
rtl8188eu.

Signed-off-by: Tim Jester-Pfadt 
---
 drivers/staging/rtl8188eu/include/rtl8188e_hal.h  |  2 +-
 drivers/staging/rtl8188eu/include/rtl8188e_recv.h |  6 +++---
 drivers/staging/rtl8188eu/include/rtw_ioctl_set.h |  4 ++--
 drivers/staging/rtl8188eu/include/rtw_led.h   |  4 ++--
 drivers/staging/rtl8188eu/include/rtw_mlme.h  |  2 +-
 drivers/staging/rtl8188eu/include/rtw_mlme_ext.h  | 12 ++--
 drivers/staging/rtl8188eu/include/rtw_mp.h|  8 
 drivers/staging/rtl8188eu/include/rtw_mp_ioctl.h  |  2 +-
 8 files changed, 20 insertions(+), 20 deletions(-)

diff --git a/drivers/staging/rtl8188eu/include/rtl8188e_hal.h 
b/drivers/staging/rtl8188eu/include/rtl8188e_hal.h
index 8d1c37e..161f1e5 100644
--- a/drivers/staging/rtl8188eu/include/rtl8188e_hal.h
+++ b/drivers/staging/rtl8188eu/include/rtl8188e_hal.h
@@ -458,7 +458,7 @@ void Hal_EfuseParseCustomerID88E(struct adapter *padapter, 
u8 *hwinfo,
 bool AutoLoadFail);
 void Hal_ReadAntennaDiversity88E(struct adapter *pAdapter, u8 *PROMContent,
 bool AutoLoadFail);
-void Hal_ReadThermalMeter_88E(struct adapter * dapter, u8 *PROMContent,
+void Hal_ReadThermalMeter_88E(struct adapter *dapter, u8 *PROMContent,
  bool AutoloadFail);
 void Hal_EfuseParseXtal_8188E(struct adapter *pAdapter, u8 *hwinfo,
  bool AutoLoadFail);
diff --git a/drivers/staging/rtl8188eu/include/rtl8188e_recv.h 
b/drivers/staging/rtl8188eu/include/rtl8188e_recv.h
index 02ccb40..a8facf0 100644
--- a/drivers/staging/rtl8188eu/include/rtl8188e_recv.h
+++ b/drivers/staging/rtl8188eu/include/rtl8188e_recv.h
@@ -58,11 +58,11 @@ enum rx_packet_type {
 #define INTERRUPT_MSG_FORMAT_LEN 60
 void rtl8188eu_init_recvbuf(struct adapter *padapter, struct recv_buf *buf);
 s32 rtl8188eu_init_recv_priv(struct adapter *padapter);
-void rtl8188eu_free_recv_priv(struct adapter * padapter);
-void rtl8188eu_recv_hdl(struct adapter * padapter, struct recv_buf *precvbuf);
+void rtl8188eu_free_recv_priv(struct adapter *padapter);
+void rtl8188eu_recv_hdl(struct adapter *padapter, struct recv_buf *precvbuf);
 void rtl8188eu_recv_tasklet(void *priv);
 void rtl8188e_query_rx_phy_status(union recv_frame *fr, struct phy_stat *phy);
-void rtl8188e_process_phy_info(struct adapter * padapter, void *prframe);
+void rtl8188e_process_phy_info(struct adapter *padapter, void *prframe);
 void update_recvframe_phyinfo_88e(union recv_frame *fra, struct phy_stat *phy);
 void update_recvframe_attrib_88e(union recv_frame *fra, struct recv_stat 
*stat);
 
diff --git a/drivers/staging/rtl8188eu/include/rtw_ioctl_set.h 
b/drivers/staging/rtl8188eu/include/rtw_ioctl_set.h
index 49efb23..187fe1f 100644
--- a/drivers/staging/rtl8188eu/include/rtw_ioctl_set.h
+++ b/drivers/staging/rtl8188eu/include/rtw_ioctl_set.h
@@ -28,10 +28,10 @@ typedef u8 NDIS_802_11_PMKID_VALUE[16];
 u8 rtw_set_802_11_add_key(struct adapter *adapt, struct ndis_802_11_key *key);
 u8 rtw_set_802_11_authentication_mode(struct adapter *adapt,
  enum ndis_802_11_auth_mode authmode);
-u8 rtw_set_802_11_bssid(struct adapter*adapter, u8 *bssid);
+u8 rtw_set_802_11_bssid(struct adapter *adapter, u8 *bssid);
 u8 rtw_set_802_11_add_wep(struct adapter *adapter, struct ndis_802_11_wep 
*wep);
 u8 rtw_set_802_11_disassociate(struct adapter *adapter);
-u8 rtw_set_802_11_bssid_list_scan(struct adapter*adapter,
+u8 rtw_set_802_11_bssid_list_scan(struct adapter *adapter,
  struct ndis_802_11_ssid *pssid,
  int ssid_max_num);
 u8 rtw_set_802_11_infrastructure_mode(struct adapter *adapter,
diff --git a/drivers/staging/rtl8188eu/include/rtw_led.h 
b/drivers/staging/rtl8188eu/include/rtw_led.h
index 87682cd..0da4e27 100644
--- a/drivers/staging/rtl8188eu/include/rtw_led.h
+++ b/drivers/staging/rtl8188eu/include/rtw_led.h
@@ -182,7 +182,7 @@ struct led_priv{
 void BlinkTimerCallback(void *data);
 void BlinkWorkItemCallback(struct work_struct *work);
 
-void ResetLedStatus(struct LED_871x * pLed);
+void ResetLedStatus(struct LED_871x *pLed);
 
 void InitLed871x(struct adapter *padapter, struct LED_871x *pLed,
 enum LED_PIN_871x LedPin);
@@ -190,7 +190,7 @@ void InitLed871x(struct adapter *padapter, struct LED_871x 
*pLed,
 void DeInitLed871x(struct LED_871x *pLed);
 
 /* hal... */
-void BlinkHandler(struct LED_871x * pLed);
+void BlinkHandler(struct LED_871x *pLed);
 void SwLedOn(struct adapter *padapter, struct LED_871x *pLed);
 void SwLedOff(struct adapter *padapter, struct LED_871x *pLed);
 
diff --git a/drivers/staging/rtl8188eu/include/rtw_mlme.h 
b/drivers/staging/rtl8188eu/include/rtw_mlme.h
index f1b8233..6cd988f 100644
--- a/drivers/staging/rtl8188eu/include/rtw_mlme.h
+++ b/drivers/staging/rtl8188eu/include/rtw_mlme.h
@@ -614,7 +614,7 

[PATCH v2 1/2] Staging: rtl8188eu: Fixed required spaces after ',' and around '=' and '=='

2014-01-11 Thread Tim Jester-Pfadt
This patch fixes all spaces required after ',' and around '=' aswell as '=='
checkpatch.pl errors for rtl8188eu.

Signed-off-by: Tim Jester-Pfadt 
---
 drivers/staging/rtl8188eu/include/Hal8188EPwrSeq.h | 2 +-
 drivers/staging/rtl8188eu/include/odm.h| 2 +-
 drivers/staging/rtl8188eu/include/odm_debug.h  | 2 +-
 drivers/staging/rtl8188eu/include/odm_interface.h  | 2 +-
 drivers/staging/rtl8188eu/include/rtl8188e_hal.h   | 2 +-
 drivers/staging/rtl8188eu/include/rtw_eeprom.h | 2 +-
 drivers/staging/rtl8188eu/include/rtw_efuse.h  | 2 +-
 drivers/staging/rtl8188eu/include/rtw_iol.h| 8 
 drivers/staging/rtl8188eu/include/rtw_led.h| 2 +-
 drivers/staging/rtl8188eu/include/rtw_mlme.h   | 6 +++---
 drivers/staging/rtl8188eu/include/rtw_mp.h | 2 +-
 drivers/staging/rtl8188eu/include/rtw_security.h   | 2 +-
 drivers/staging/rtl8188eu/include/wifi.h   | 2 +-
 13 files changed, 18 insertions(+), 18 deletions(-)

diff --git a/drivers/staging/rtl8188eu/include/Hal8188EPwrSeq.h 
b/drivers/staging/rtl8188eu/include/Hal8188EPwrSeq.h
index 20d0b3e..aebf1d3 100644
--- a/drivers/staging/rtl8188eu/include/Hal8188EPwrSeq.h
+++ b/drivers/staging/rtl8188eu/include/Hal8188EPwrSeq.h
@@ -160,7 +160,7 @@
 #define RTL8188E_TRANS_END 
\
/* format */
\
/* { offset, cut_msk, fab_msk|interface_msk, base|cmd, msk, value },  
comments here*/   \
-   {0x, PWR_CUT_ALL_MSK, PWR_FAB_ALL_MSK, PWR_INTF_ALL_MSK,0, 
PWR_CMD_END, 0, 0}, /*  */
+   {0x, PWR_CUT_ALL_MSK, PWR_FAB_ALL_MSK, PWR_INTF_ALL_MSK, 0, 
PWR_CMD_END, 0, 0}, /*  */
 
 
 extern struct wl_pwr_cfg 
rtl8188E_power_on_flow[RTL8188E_TRANS_CARDEMU_TO_ACT_STEPS+RTL8188E_TRANS_END_STEPS];
diff --git a/drivers/staging/rtl8188eu/include/odm.h 
b/drivers/staging/rtl8188eu/include/odm.h
index 8e9c92c..9d1a79c 100644
--- a/drivers/staging/rtl8188eu/include/odm.h
+++ b/drivers/staging/rtl8188eu/include/odm.h
@@ -151,7 +151,7 @@ struct rtl_ps {
int Rssi_val_min;
 
u8  initialize;
-   u32 Reg874,RegC70,Reg85C,RegA74;
+   u32 Reg874, RegC70, Reg85C, RegA74;
 
 };
 
diff --git a/drivers/staging/rtl8188eu/include/odm_debug.h 
b/drivers/staging/rtl8188eu/include/odm_debug.h
index c512a4e..e8c4cab 100644
--- a/drivers/staging/rtl8188eu/include/odm_debug.h
+++ b/drivers/staging/rtl8188eu/include/odm_debug.h
@@ -125,7 +125,7 @@
DbgPrint(title_str);\
DbgPrint(" ");  \
for (__i = 0; __i < 6; __i++)   \
-   DbgPrint("%02X%s", __ptr[__i], (__i==5)?"":"-");\
+   DbgPrint("%02X%s", __ptr[__i], (__i == 5)?"":"-");\
DbgPrint("\n"); \
}
 
diff --git a/drivers/staging/rtl8188eu/include/odm_interface.h 
b/drivers/staging/rtl8188eu/include/odm_interface.h
index 22f451e..a50eae3 100644
--- a/drivers/staging/rtl8188eu/include/odm_interface.h
+++ b/drivers/staging/rtl8188eu/include/odm_interface.h
@@ -64,7 +64,7 @@ ODM_REG(DIG,_pDM_Odm)
 
 enum odm_h2c_cmd {
ODM_H2C_RSSI_REPORT = 0,
-   ODM_H2C_PSD_RESULT= 1,
+   ODM_H2C_PSD_RESULT = 1,
ODM_H2C_PathDiv = 2,
ODM_MAX_H2CCMD
 };
diff --git a/drivers/staging/rtl8188eu/include/rtl8188e_hal.h 
b/drivers/staging/rtl8188eu/include/rtl8188e_hal.h
index 555c801..8d1c37e 100644
--- a/drivers/staging/rtl8188eu/include/rtl8188e_hal.h
+++ b/drivers/staging/rtl8188eu/include/rtl8188e_hal.h
@@ -456,7 +456,7 @@ void rtl8188e_EfuseParseChnlPlan(struct adapter *padapter, 
u8 *hwinfo,
 bool AutoLoadFail);
 void Hal_EfuseParseCustomerID88E(struct adapter *padapter, u8 *hwinfo,
 bool AutoLoadFail);
-void Hal_ReadAntennaDiversity88E(struct adapter *pAdapter,u8 *PROMContent,
+void Hal_ReadAntennaDiversity88E(struct adapter *pAdapter, u8 *PROMContent,
 bool AutoLoadFail);
 void Hal_ReadThermalMeter_88E(struct adapter * dapter, u8 *PROMContent,
  bool AutoloadFail);
diff --git a/drivers/staging/rtl8188eu/include/rtw_eeprom.h 
b/drivers/staging/rtl8188eu/include/rtw_eeprom.h
index b2672c3..904fea1 100644
--- a/drivers/staging/rtl8188eu/include/rtw_eeprom.h
+++ b/drivers/staging/rtl8188eu/include/rtw_eeprom.h
@@ -108,7 +108,7 @@ enum RT_CUSTOMER_ID {
RT_CID_CC_C = 38,
RT_CID_819x_Xavi = 39,
RT_CID_819x_FUNAI_TV = 40,
-   RT_CID_819x_ALPHA_WD=41,
+   RT_CID_819x_ALPHA_WD = 41,
 };
 
 struct eeprom_priv {
diff --git a/drivers/s

Re: [char-misc 1/4] mei: do not run reset flow from the interrupt thread

2014-01-11 Thread Greg KH
On Sat, Jan 11, 2014 at 10:46:14PM +, Winkler, Tomas wrote:
> 
> 
> > 
> > This is a _really_ big patch for a stable kernel tree.  Are you sure
> > it's needed there?  Please go read Documentation/stable_kernel_rules.txt
> > again.
> 
> I understand it's big though currently I do not have significantly
> simpler fix for the issue, all 4 patches are needed to make the reset
> issue  go away.

What is the "reset issue"?  Who is it affecting?  What is the problem?
Is there a work-around without this patchset?

As it is, I can't take something this big for the stable tree, sorry.

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


Re: [PATCHSET v2 driver-core-next] kernfs, sysfs, driver-core: implement synchronous self-removal

2014-01-11 Thread Greg KH
On Sat, Jan 11, 2014 at 05:52:30PM -0500, Alan Stern wrote:
> On Sat, 11 Jan 2014, Greg KH wrote:
> 
> > On Sat, Jan 11, 2014 at 01:51:10PM -0500, Tejun Heo wrote:
> > > Hey, Alan.
> > > 
> > > On Fri, Jan 10, 2014 at 10:46:10AM -0500, Alan Stern wrote:
> > > > The SUBJECT lines in your patch emails don't mention the version
> > > > number.  That is, they just say "[PATCH]", not "[PATCH v2]" or "[PATCH
> > > > v3]". This makes it very difficult for me to tell which messages to
> > > > read.
> > > 
> > > Hmm... they're all threaded.  I add version tags when posting
> > > incremental patches but usually don't bother with it when posting a
> > > new version of the whole series.  After all, some patches are get
> > > updated without explicitly given a new version for refrehses and stuff
> > > so it's not like you can determine everything based on subjects only.
> 
> Greg, what do you prefer in this situation?

If the threading is correct, just as Tejun did is the best and easiest
for me to handle, as I can just delete the whole set of old patches and
use the new ones.

> > > > (Reading them in order doesn't work, because my computer mixes up the 
> > > > order of messages when it downloads a large bunch from the email 
> > > > server.  It's kind of annoying...)
> > > 
> > > And they aren't threaded?
> > 
> > They were all threaded for me, perhaps Alan needs a better email client :)
> 
> Undoubtedly I do.  My current client is embarassingly old.

There's nothing wrong with using old mail clients, mutt is very old, it
just works really well.

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


[PATCH driver-core-next] kernfs: remove unnecessary NULL check in __kernfs_remove()

2014-01-11 Thread Tejun Heo
895a068a524e ("kernfs: make kernfs_get_active() block if the node is
deactivated but not removed") added "struct kernfs_root *root =
kernfs_root(kn);" at the head of the function; however, the parameter
@kn is checked for later implying that the function may be called with
NULL.  This means that we may end up invoking kernfs_root() with NULL
which will oops.  None of the existing users invokes removal with NULL
@kn, so this bug doesn't actually trigger.

We can relocate kernfs_root() invocation after NULL check; however,
allowing NULL param tends to cause more confusion than actually
helping anything.  As there's no existing user, let's remove the
spurious NULL check.

This bug was detected by smatch.

Signed-off-by: Tejun Heo 
Reported-by: Dan Carpenter 
---
 fs/kernfs/dir.c |3 ---
 1 file changed, 3 deletions(-)

--- a/fs/kernfs/dir.c
+++ b/fs/kernfs/dir.c
@@ -920,9 +920,6 @@ static void __kernfs_remove(struct kernf
 
lockdep_assert_held(&kernfs_mutex);
 
-   if (!kn)
-   return;
-
pr_debug("kernfs %s: removing\n", kn->name);
 
__kernfs_deactivate(kn);

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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: [PATCHSET v2 driver-core-next] kernfs, sysfs, driver-core: implement synchronous self-removal

2014-01-11 Thread Alan Stern
On Sat, 11 Jan 2014, Greg KH wrote:

> On Sat, Jan 11, 2014 at 01:51:10PM -0500, Tejun Heo wrote:
> > Hey, Alan.
> > 
> > On Fri, Jan 10, 2014 at 10:46:10AM -0500, Alan Stern wrote:
> > > The SUBJECT lines in your patch emails don't mention the version
> > > number.  That is, they just say "[PATCH]", not "[PATCH v2]" or "[PATCH
> > > v3]". This makes it very difficult for me to tell which messages to
> > > read.
> > 
> > Hmm... they're all threaded.  I add version tags when posting
> > incremental patches but usually don't bother with it when posting a
> > new version of the whole series.  After all, some patches are get
> > updated without explicitly given a new version for refrehses and stuff
> > so it's not like you can determine everything based on subjects only.

Greg, what do you prefer in this situation?

> > > (Reading them in order doesn't work, because my computer mixes up the 
> > > order of messages when it downloads a large bunch from the email 
> > > server.  It's kind of annoying...)
> > 
> > And they aren't threaded?
> 
> They were all threaded for me, perhaps Alan needs a better email client :)

Undoubtedly I do.  My current client is embarassingly old.

Alan Stern

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


RE: [char-misc 1/4] mei: do not run reset flow from the interrupt thread

2014-01-11 Thread Winkler, Tomas


> 
> This is a _really_ big patch for a stable kernel tree.  Are you sure
> it's needed there?  Please go read Documentation/stable_kernel_rules.txt
> again.

I understand it's big though currently I do not have significantly simpler fix 
for the issue, all 4 patches are needed to make the reset issue  go away.
 
Thanks
Tomas

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


[char-misc 3/4 V2] mei: revamp mei reset state machine

2014-01-11 Thread Tomas Winkler
1. MEI_DEV_RESETTING device state spans only hardware reset flow
while starting dev state is saved into a local variable for further
reference, this let us to reduce big if statements in case we
are trying to avoid nested resets

2. During initializations if the reset ended in MEI_DEV_DISABLED device
state we bail out with -ENODEV

3. Remove redundant interrupts_enabled parameter as this
 can be deduced from the starting dev_state

4. mei_reset propagates error code to the caller

5. Add mei_restart function to wrap the pci resume

Signed-off-by: Tomas Winkler 
Signed-off-by: Alexander Usyskin 
---
V2: rebased

 drivers/misc/mei/hbm.c   |   2 +-
 drivers/misc/mei/hw-me.c |  10 +--
 drivers/misc/mei/init.c  | 209 ++-
 drivers/misc/mei/interrupt.c |  13 +--
 drivers/misc/mei/mei_dev.h   |   3 +-
 drivers/misc/mei/pci-me.c|  10 +--
 6 files changed, 143 insertions(+), 104 deletions(-)

diff --git a/drivers/misc/mei/hbm.c b/drivers/misc/mei/hbm.c
index 8520cdf..28cd74c 100644
--- a/drivers/misc/mei/hbm.c
+++ b/drivers/misc/mei/hbm.c
@@ -763,7 +763,7 @@ int mei_hbm_dispatch(struct mei_device *dev, struct 
mei_msg_hdr *hdr)
return -EPROTO;
}
 
-   dev->dev_state = MEI_DEV_DISABLED;
+   dev->dev_state = MEI_DEV_POWER_DOWN;
dev_info(&dev->pdev->dev, "hbm: stop response: resetting.\n");
/* force the reset */
return -EPROTO;
diff --git a/drivers/misc/mei/hw-me.c b/drivers/misc/mei/hw-me.c
index 6c07623..6f656c0 100644
--- a/drivers/misc/mei/hw-me.c
+++ b/drivers/misc/mei/hw-me.c
@@ -185,7 +185,7 @@ static int mei_me_hw_reset(struct mei_device *dev, bool 
intr_enable)
 
mei_me_reg_write(hw, H_CSR, hcsr);
 
-   if (dev->dev_state == MEI_DEV_POWER_DOWN)
+   if (intr_enable == false)
mei_me_hw_reset_release(dev);
 
return 0;
@@ -482,11 +482,7 @@ irqreturn_t mei_me_irq_thread_handler(int irq, void 
*dev_id)
mei_clear_interrupts(dev);
 
/* check if ME wants a reset */
-   if (!mei_hw_is_ready(dev) &&
-   dev->dev_state != MEI_DEV_RESETTING &&
-   dev->dev_state != MEI_DEV_INITIALIZING &&
-   dev->dev_state != MEI_DEV_POWER_DOWN &&
-   dev->dev_state != MEI_DEV_POWER_UP) {
+   if (!mei_hw_is_ready(dev) && dev->dev_state != MEI_DEV_RESETTING) {
dev_warn(&dev->pdev->dev, "FW not ready: resetting.\n");
schedule_work(&dev->reset_work);
goto end;
@@ -514,7 +510,7 @@ irqreturn_t mei_me_irq_thread_handler(int irq, void *dev_id)
break;
dev_dbg(&dev->pdev->dev, "slots to read = %08x\n", slots);
rets = mei_irq_read_handler(dev, &complete_list, &slots);
-   if (rets) {
+   if (rets && dev->dev_state != MEI_DEV_RESETTING) {
schedule_work(&dev->reset_work);
goto end;
}
diff --git a/drivers/misc/mei/init.c b/drivers/misc/mei/init.c
index c47fa27..059133d 100644
--- a/drivers/misc/mei/init.c
+++ b/drivers/misc/mei/init.c
@@ -43,62 +43,13 @@ const char *mei_dev_state_str(int state)
 #undef MEI_DEV_STATE
 }
 
-/**
- * mei_start - initializes host and fw to start work.
- *
- * @dev: the device structure
- *
- * returns 0 on success, <0 on failure.
- */
-int mei_start(struct mei_device *dev)
-{
-   mutex_lock(&dev->device_lock);
-
-   /* acknowledge interrupt and stop interupts */
-   mei_clear_interrupts(dev);
-
-   mei_hw_config(dev);
-
-   dev_dbg(&dev->pdev->dev, "reset in start the mei device.\n");
-
-   mei_reset(dev, 1);
-
-   if (mei_hbm_start_wait(dev)) {
-   dev_err(&dev->pdev->dev, "HBM haven't started");
-   goto err;
-   }
-
-   if (!mei_host_is_ready(dev)) {
-   dev_err(&dev->pdev->dev, "host is not ready.\n");
-   goto err;
-   }
-
-   if (!mei_hw_is_ready(dev)) {
-   dev_err(&dev->pdev->dev, "ME is not ready.\n");
-   goto err;
-   }
-
-   if (!mei_hbm_version_is_supported(dev)) {
-   dev_dbg(&dev->pdev->dev, "MEI start failed.\n");
-   goto err;
-   }
-
-   dev_dbg(&dev->pdev->dev, "link layer has been established.\n");
-
-   mutex_unlock(&dev->device_lock);
-   return 0;
-err:
-   dev_err(&dev->pdev->dev, "link layer initialization failed.\n");
-   dev->dev_state = MEI_DEV_DISABLED;
-   mutex_unlock(&dev->device_lock);
-   return -ENODEV;
-}
-EXPORT_SYMBOL_GPL(mei_start);
 
 /**
  * mei_cancel_work. Cancel mei background jobs
  *
  * @dev: the device structure
+ *
+ * returns 0 on success or < 0 if the reset hasn't succeeded
  */
 void mei_cancel_work(struct mei_device *dev)
 {
@@ -113,21 +64,19 @@ EXPORT_SYMBOL_GPL(mei_cancel_work);
  * mei_reset - resets host and fw.
  *
  * @dev: the devic

[char-misc 4/4 V2] mei: limit the number of consecutive resets

2014-01-11 Thread Tomas Winkler
give up reseting after 3 unsuccessful tries

Signed-off-by: Tomas Winkler 
Signed-off-by: Alexander Usyskin 
---
V2: rebased

 drivers/misc/mei/client.c  |  1 +
 drivers/misc/mei/init.c| 10 ++
 drivers/misc/mei/mei_dev.h |  7 +++
 3 files changed, 18 insertions(+)

diff --git a/drivers/misc/mei/client.c b/drivers/misc/mei/client.c
index 4f268a3..1ee2b94 100644
--- a/drivers/misc/mei/client.c
+++ b/drivers/misc/mei/client.c
@@ -370,6 +370,7 @@ void mei_host_client_init(struct work_struct *work)
}
 
dev->dev_state = MEI_DEV_ENABLED;
+   dev->reset_count = 0;
 
mutex_unlock(&dev->device_lock);
 }
diff --git a/drivers/misc/mei/init.c b/drivers/misc/mei/init.c
index 059133d..cdd31c2 100644
--- a/drivers/misc/mei/init.c
+++ b/drivers/misc/mei/init.c
@@ -89,6 +89,13 @@ int mei_reset(struct mei_device *dev)
interrupts_enabled = state != MEI_DEV_POWER_DOWN;
dev->dev_state = MEI_DEV_RESETTING;
 
+   dev->reset_count++;
+   if (dev->reset_count > MEI_MAX_CONSEC_RESET) {
+   dev_err(&dev->pdev->dev, "reset: reached maximal consecutive 
resets: disabling the device\n");
+   dev->dev_state = MEI_DEV_DISABLED;
+   return -ENODEV;
+   }
+
ret = mei_hw_reset(dev, interrupts_enabled);
/* fall through and remove the sw state even if hw reset has failed */
 
@@ -169,6 +176,7 @@ int mei_start(struct mei_device *dev)
dev_dbg(&dev->pdev->dev, "reset in start the mei device.\n");
 
dev->dev_state = MEI_DEV_INITIALIZING;
+   dev->reset_count = 0;
mei_reset(dev);
 
if (dev->dev_state == MEI_DEV_DISABLED) {
@@ -224,6 +232,7 @@ int mei_restart(struct mei_device *dev)
mei_clear_interrupts(dev);
 
dev->dev_state = MEI_DEV_POWER_UP;
+   dev->reset_count = 0;
 
err = mei_reset(dev);
 
@@ -285,6 +294,7 @@ void mei_device_init(struct mei_device *dev)
init_waitqueue_head(&dev->wait_recvd_msg);
init_waitqueue_head(&dev->wait_stop_wd);
dev->dev_state = MEI_DEV_INITIALIZING;
+   dev->reset_count = 0;
 
mei_io_list_init(&dev->read_list);
mei_io_list_init(&dev->write_list);
diff --git a/drivers/misc/mei/mei_dev.h b/drivers/misc/mei/mei_dev.h
index a617c84..f7de95b 100644
--- a/drivers/misc/mei/mei_dev.h
+++ b/drivers/misc/mei/mei_dev.h
@@ -61,6 +61,11 @@ extern const uuid_le mei_wd_guid;
 #define MEI_CLIENTS_MAX 256
 
 /*
+ * maximum number of consecutive resets
+ */
+#define MEI_MAX_CONSEC_RESET  3
+
+/*
  * Number of File descriptors/handles
  * that can be opened to the driver.
  *
@@ -327,6 +332,7 @@ struct mei_cl_device {
 /**
  * struct mei_device -  MEI private device struct
 
+ * @reset_count - limits the number of consecutive resets
  * @hbm_state - state of host bus message protocol
  * @mem_addr - mem mapped base register address
 
@@ -370,6 +376,7 @@ struct mei_device {
/*
 * mei device  states
 */
+   unsigned long reset_count;
enum mei_dev_state dev_state;
enum mei_hbm_state hbm_state;
u16 init_clients_timer;
-- 
1.8.4.2

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


Re: [PATCH v2 0/2] rcu_dereference_check_fdtable fix/cleanups

2014-01-11 Thread Paul E. McKenney
On Sat, Jan 11, 2014 at 07:19:08PM +0100, Oleg Nesterov wrote:
> On 01/10, Paul E. McKenney wrote:
> >
> > On Fri, Jan 10, 2014 at 04:34:59PM +0100, Oleg Nesterov wrote:
> > >
> > > doesn't this look much simpler than adding the "bool unshared" argument
> > > and changing the callers?
> >
> > I might be being too paranoid, but my concern with using rcu_lock_acquire()
> > and rcu_lock_release()
> 
> And I agree, I no longer suggest to use rcu_lock_acquire/release.
> 
> It seems that you misunderstood me, let me send v2 for review.

Ah, I did misunderstand you.  For both:

Acked-by: Paul E. McKenney 

Thanx, Paul

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


[PATCH] perf, tools: Add --initial-delay support to perf record v3

2014-01-11 Thread Andi Kleen
From: Andi Kleen 

perf stat has a --delay option to delay measuring the workload.
This is useful to skip measuring the startup phase of the program, which
is often very different from the main workload.

The same is useful for perf record when sampling.

--no-delay was already taken, so add a --initial-delay
to perf record too.
-D was already taken for record, so there is only a long option.

v2: Don't disable group members (Namhyung Kim)
v3: port to latest perf/core
rename to --initial-delay to avoid conflict with --no-delay
Cc: Namhyung Kim 
Signed-off-by: Andi Kleen 
---
 tools/perf/Documentation/perf-record.txt | 4 
 tools/perf/builtin-record.c  | 9 -
 tools/perf/perf.h| 1 +
 tools/perf/util/evsel.c  | 3 ++-
 4 files changed, 15 insertions(+), 2 deletions(-)

diff --git a/tools/perf/Documentation/perf-record.txt 
b/tools/perf/Documentation/perf-record.txt
index c407897..82bffac 100644
--- a/tools/perf/Documentation/perf-record.txt
+++ b/tools/perf/Documentation/perf-record.txt
@@ -209,6 +209,10 @@ overrides that and uses per-thread mmaps.  A side-effect 
of that is that
 inheritance is automatically disabled.  --per-thread is ignored with a warning
 if combined with -a or -C options.
 
+--initial-delay msecs::
+After starting the program, wait msecs before measuring. This is useful to
+filter out the startup phase of the program, which is often very different.
+
 SEE ALSO
 
 linkperf:perf-stat[1], linkperf:perf-list[1]
diff --git a/tools/perf/builtin-record.c b/tools/perf/builtin-record.c
index 8860015..07d4cf8 100644
--- a/tools/perf/builtin-record.c
+++ b/tools/perf/builtin-record.c
@@ -499,7 +499,7 @@ static int __cmd_record(struct record *rec, int argc, const 
char **argv)
 * (apart from group members) have enable_on_exec=1 set,
 * so don't spoil it by prematurely enabling them.
 */
-   if (!target__none(&opts->target))
+   if (!target__none(&opts->target) && !opts->initial_delay)
perf_evlist__enable(rec->evlist);
 
/*
@@ -508,6 +508,11 @@ static int __cmd_record(struct record *rec, int argc, 
const char **argv)
if (forks)
perf_evlist__start_workload(rec->evlist);
 
+   if (opts->initial_delay) {
+   usleep(opts->initial_delay * 1000);
+   perf_evlist__enable(rec->evlist);
+   }
+
for (;;) {
int hits = rec->samples;
 
@@ -877,6 +882,8 @@ const struct option record_options[] = {
OPT_CALLBACK('G', "cgroup", &record.evlist, "name",
 "monitor event in cgroup name only",
 parse_cgroups),
+   OPT_UINTEGER(0, "initial-delay", &record.opts.initial_delay,
+ "ms to wait before starting measurement after program start"),
OPT_STRING('u', "uid", &record.opts.target.uid_str, "user",
   "user to profile"),
 
diff --git a/tools/perf/perf.h b/tools/perf/perf.h
index b1cc84b..af1ce6e 100644
--- a/tools/perf/perf.h
+++ b/tools/perf/perf.h
@@ -269,6 +269,7 @@ struct record_opts {
u64  user_interval;
u16  stack_dump_size;
bool sample_transaction;
+   unsigned initial_delay;
 };
 
 #endif
diff --git a/tools/perf/util/evsel.c b/tools/perf/util/evsel.c
index ade8d9c..cd4630a 100644
--- a/tools/perf/util/evsel.c
+++ b/tools/perf/util/evsel.c
@@ -658,7 +658,8 @@ void perf_evsel__config(struct perf_evsel *evsel, struct 
record_opts *opts)
 * Setting enable_on_exec for independent events and
 * group leaders for traced executed by perf.
 */
-   if (target__none(&opts->target) && perf_evsel__is_group_leader(evsel))
+   if (target__none(&opts->target) && perf_evsel__is_group_leader(evsel) &&
+   !opts->initial_delay)
attr->enable_on_exec = 1;
 }
 
-- 
1.8.3.1

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


[PATCH] iio: gyro: itg3200: Add DT support.

2014-01-11 Thread Marek Belisko
Signed-off-by: NeilBrown 
Signed-off-by: Marek Belisko 
---
 .../devicetree/bindings/iio/gyro/itg3200.txt   | 22 ++
 drivers/iio/gyro/itg3200_core.c|  9 +
 2 files changed, 31 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/iio/gyro/itg3200.txt

diff --git a/Documentation/devicetree/bindings/iio/gyro/itg3200.txt 
b/Documentation/devicetree/bindings/iio/gyro/itg3200.txt
new file mode 100644
index 000..b1b18dc
--- /dev/null
+++ b/Documentation/devicetree/bindings/iio/gyro/itg3200.txt
@@ -0,0 +1,22 @@
+* InvenSense ITG-3200 gyroscope
+
+http://www.invensense.com/mems/gyro/itg3200.html
+
+Required properties:
+
+  - compatible : should be "invensense,itg3200"
+  - reg : the I2C address of the sensor
+
+Optional properties:
+
+  - interrupt-parent : should be the phandle for the interrupt controller
+  - interrupts : interrupt mapping for GPIO IRQ
+
+Example:
+
+itg3200@68 {
+   compatible = "invensense,itg3200";
+   reg = <0x68>;
+   interrupt-parent = <&gpio2>;
+   interrupts = <29 IRQ_TYPE_EDGE_RISING>;
+};
diff --git a/drivers/iio/gyro/itg3200_core.c b/drivers/iio/gyro/itg3200_core.c
index 4d3f3b9..adbf20d 100644
--- a/drivers/iio/gyro/itg3200_core.c
+++ b/drivers/iio/gyro/itg3200_core.c
@@ -374,10 +374,19 @@ static const struct i2c_device_id itg3200_id[] = {
 };
 MODULE_DEVICE_TABLE(i2c, itg3200_id);
 
+#ifdef CONFIG_OF
+static const struct of_device_id itg3200_of_match[] = {
+   { .compatible = "invensense,itg3200", },
+   {}
+};
+MODULE_DEVICE_TABLE(of, itg3200_of_match);
+#endif
+
 static struct i2c_driver itg3200_driver = {
.driver = {
.owner  = THIS_MODULE,
.name   = "itg3200",
+   .of_match_table = of_match_ptr(itg3200_of_match),
},
.id_table   = itg3200_id,
.probe  = itg3200_probe,
-- 
1.8.4.2

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


Re: No freezing of kernel threads (was: Re: [GIT PULL] libata fixes for v3.13-rc5)

2014-01-11 Thread Pavel Machek
Hi!

> > Well, it looks like we don't really know why things are done the way they
> > are done at least in some cases, so in my personal view it would be good to
> > go through all of the kernel freezer users just for this reason alone.  We
> > can't really say which of them are legitimate without that and how difficult
> > it would be for them to switch over to using something more fine grained 
> > than
> > the freezer.
> 
> I'm a bit worried about things which may not be explicit.
> ie. something which is broken but sorta working because things like
> writeback and jbd are frozen.  I think I worry about that because I
> remember one argument for kernel freezer from way way back, that it's
> too hard to implement proper suspend/resume for all drivers and by
> freezing most kthreads things should mostly work, which sounded pretty
> crazy to me even back then.  Hopefully, we don't have much left
> depending on such magic.

Careful there. Hibernation depends on data on disk not changing after
freeze.

So you definitely do _not_ want writeback/jbd running while uswsusp
does its image writing.

(I wonder what happens if uswsusp needs to trigger writeback to free
memory. But I'm too scared to check :-).
Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) 
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


[PATCH] ARM: dts: twl4030: Add power support.

2014-01-11 Thread Marek Belisko
Signed-off-by: NeilBrown 
Signed-off-by: Marek Belisko 
---
 arch/arm/boot/dts/twl4030.dtsi | 4 
 1 file changed, 4 insertions(+)

diff --git a/arch/arm/boot/dts/twl4030.dtsi b/arch/arm/boot/dts/twl4030.dtsi
index 4217096..21079e1 100644
--- a/arch/arm/boot/dts/twl4030.dtsi
+++ b/arch/arm/boot/dts/twl4030.dtsi
@@ -25,6 +25,10 @@
bci3v1-supply = <&vusb3v1>;
};
 
+   twl_power: power {
+   compatible = "ti,twl4030-power";
+   };
+
watchdog {
compatible = "ti,twl4030-wdt";
};
-- 
1.8.4.2

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


Re: [PATCH 1/4] x86, ptdump: Add the functionality to dump an arbitrary pagetable

2014-01-11 Thread Joe Perches
On Sat, 2014-01-11 at 21:49 +0100, Borislav Petkov wrote:
> From: Borislav Petkov 
> 
> With reusing the ->trampoline_pgd page table for mapping EFI regions in
> order to use them after having switched to EFI virtual mode, it is very
> useful to be able to dump aforementioned page table in dmesg. This adds
> that functionality through the walk_pgd_level() interface which can be
> called from somewhere else.
[]
> diff --git a/arch/x86/mm/dump_pagetables.c b/arch/x86/mm/dump_pagetables.c
[]
> @@ -306,6 +326,11 @@ static void walk_pgd_level(struct seq_file *m)
>   int i;
>   struct pg_state st;
>  
> + if (pgd) {
> + start = pgd;
> + dump_to_dmesg = true;
> + }

else
dump_to_dmesg = false;

?


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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/4] x86, ptdump: Add the functionality to dump an arbitrary pagetable

2014-01-11 Thread Borislav Petkov
From: Borislav Petkov 

With reusing the ->trampoline_pgd page table for mapping EFI regions in
order to use them after having switched to EFI virtual mode, it is very
useful to be able to dump aforementioned page table in dmesg. This adds
that functionality through the walk_pgd_level() interface which can be
called from somewhere else.

The original functionality of dumping to debugfs remains untouched.

Cc: Arjan van de Ven 
Signed-off-by: Borislav Petkov 
---
 arch/x86/include/asm/pgtable.h |  3 +-
 arch/x86/mm/dump_pagetables.c  | 77 --
 2 files changed, 53 insertions(+), 27 deletions(-)

diff --git a/arch/x86/include/asm/pgtable.h b/arch/x86/include/asm/pgtable.h
index bbc8b12fa443..0001851fa785 100644
--- a/arch/x86/include/asm/pgtable.h
+++ b/arch/x86/include/asm/pgtable.h
@@ -15,9 +15,10 @@
 : (prot))
 
 #ifndef __ASSEMBLY__
-
 #include 
 
+void walk_pgd_level(struct seq_file *m, pgd_t *pgd);
+
 /*
  * ZERO_PAGE is a global shared page that is always zero: used
  * for zero-mapped memory areas etc..
diff --git a/arch/x86/mm/dump_pagetables.c b/arch/x86/mm/dump_pagetables.c
index 0002a3a33081..f987ecff9226 100644
--- a/arch/x86/mm/dump_pagetables.c
+++ b/arch/x86/mm/dump_pagetables.c
@@ -19,6 +19,8 @@
 
 #include 
 
+static bool dump_to_dmesg;
+
 /*
  * The dumper groups pagetable entries of the same type into one, and for
  * that it needs to keep some state when walking, and flush this state
@@ -88,6 +90,24 @@ static struct addr_marker address_markers[] = {
 #define PUD_LEVEL_MULT (PTRS_PER_PMD * PMD_LEVEL_MULT)
 #define PGD_LEVEL_MULT (PTRS_PER_PUD * PUD_LEVEL_MULT)
 
+#define pt_dump_seq_printf(m, fmt, args...)\
+({ \
+   if (dump_to_dmesg)  \
+   printk(KERN_INFO fmt, ##args);  \
+   else\
+   if (m)  \
+   seq_printf(m, fmt, ##args); \
+})
+
+#define pt_dump_cont_printf(m, fmt, args...)   \
+({ \
+   if (dump_to_dmesg)  \
+   printk(KERN_CONT fmt, ##args);  \
+   else\
+   if (m)  \
+   seq_printf(m, fmt, ##args); \
+})
+
 /*
  * Print a readable form of a pgprot_t to the seq_file
  */
@@ -99,47 +119,47 @@ static void printk_prot(struct seq_file *m, pgprot_t prot, 
int level)
 
if (!pgprot_val(prot)) {
/* Not present */
-   seq_printf(m, "  ");
+   pt_dump_cont_printf(m, "  ");
} else {
if (pr & _PAGE_USER)
-   seq_printf(m, "USR ");
+   pt_dump_cont_printf(m, "USR ");
else
-   seq_printf(m, "");
+   pt_dump_cont_printf(m, "");
if (pr & _PAGE_RW)
-   seq_printf(m, "RW ");
+   pt_dump_cont_printf(m, "RW ");
else
-   seq_printf(m, "ro ");
+   pt_dump_cont_printf(m, "ro ");
if (pr & _PAGE_PWT)
-   seq_printf(m, "PWT ");
+   pt_dump_cont_printf(m, "PWT ");
else
-   seq_printf(m, "");
+   pt_dump_cont_printf(m, "");
if (pr & _PAGE_PCD)
-   seq_printf(m, "PCD ");
+   pt_dump_cont_printf(m, "PCD ");
else
-   seq_printf(m, "");
+   pt_dump_cont_printf(m, "");
 
/* Bit 9 has a different meaning on level 3 vs 4 */
if (level <= 3) {
if (pr & _PAGE_PSE)
-   seq_printf(m, "PSE ");
+   pt_dump_cont_printf(m, "PSE ");
else
-   seq_printf(m, "");
+   pt_dump_cont_printf(m, "");
} else {
if (pr & _PAGE_PAT)
-   seq_printf(m, "pat ");
+   pt_dump_cont_printf(m, "pat ");
else
-   seq_printf(m, "");
+   pt_dump_cont_printf(m, "");
}
if (pr & _PAGE_GLOBAL)
-   seq_printf(m, "GLB ");
+   pt_dump_cont_printf(m, "GLB ");
else
-   seq_printf(m, "");
+

[PATCH 2/4] efi: Dump the EFI page table

2014-01-11 Thread Borislav Petkov
From: Borislav Petkov 

This is very useful for debugging issues with the recently added
pagetable switching code for EFI virtual mode.

Signed-off-by: Borislav Petkov 
---
 arch/x86/platform/efi/efi.c | 11 +++
 1 file changed, 11 insertions(+)

diff --git a/arch/x86/platform/efi/efi.c b/arch/x86/platform/efi/efi.c
index d62ec87a2b26..c34be4ce94c9 100644
--- a/arch/x86/platform/efi/efi.c
+++ b/arch/x86/platform/efi/efi.c
@@ -54,6 +54,7 @@
 #include 
 
 #define EFI_DEBUG
+#undef EFI_PGT_DBG
 
 #define EFI_MIN_RESERVE 5120
 
@@ -818,6 +819,15 @@ void efi_memory_uc(u64 addr, unsigned long size)
set_memory_uc(addr, npages);
 }
 
+static void dump_pagetable(void)
+{
+#if defined(EFI_PGT_DBG) && defined(CONFIG_X86_PTDUMP)
+   pgd_t *pgd = (pgd_t *)__va(real_mode_header->trampoline_pgd);
+
+   walk_pgd_level(NULL, pgd);
+#endif
+}
+
 void __init old_map_region(efi_memory_desc_t *md)
 {
u64 start_pfn, end_pfn, end;
@@ -1033,6 +1043,7 @@ void __init efi_enter_virtual_mode(void)
 
efi_setup_page_tables();
efi_sync_low_kernel_mappings();
+   dump_pagetable();
 
if (!efi_setup) {
status = phys_efi_set_virtual_address_map(
-- 
1.8.5.2.192.g7794a68

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


[PATCH 4/4] efi: Make efi virtual runtime map passing more robust

2014-01-11 Thread Borislav Petkov
From: Borislav Petkov 

Currently, running SetVirtualAddressMap() and passing the physical
address of the virtual map array was working only by a lucky coincidence
because the memory was present in the EFI page table too. Until Toshi
went and booted this on a big HP box - the krealloc() manner of resizing
the memmap we're doing did allocate from such physical addresses which
were not mapped anymore and boom:

http://lkml.kernel.org/r/1386806463.1791.295.ca...@misato.fc.hp.com

One way to take care of that issue is to reimplement the krealloc thing
but with pages. We start with contiguous pages of order 1, i.e. 2 pages,
and when we deplete that memory (shouldn't happen all that often but you
know firmware) we realloc the next power-of-two pages.

Having the pages, it is much more handy and easy to map them into the
EFI page table with the already existing mapping code which we're using
for building the virtual mappings.

And, it doesn't matter all that much how much pages we've used as we're
freeing them right after they've fulfilled their purpose at the end of
the function anyway.

Reported-by: Toshi Kani 
Signed-off-by: Borislav Petkov 
---
 arch/x86/include/asm/efi.h |  3 +-
 arch/x86/platform/efi/efi.c| 62 ++
 arch/x86/platform/efi/efi_32.c |  6 +++-
 arch/x86/platform/efi/efi_64.c | 31 +++--
 4 files changed, 80 insertions(+), 22 deletions(-)

diff --git a/arch/x86/include/asm/efi.h b/arch/x86/include/asm/efi.h
index 3b978c472d08..0e7973f7492e 100644
--- a/arch/x86/include/asm/efi.h
+++ b/arch/x86/include/asm/efi.h
@@ -130,7 +130,8 @@ extern void efi_memory_uc(u64 addr, unsigned long size);
 extern void __init efi_map_region(efi_memory_desc_t *md);
 extern void __init efi_map_region_fixed(efi_memory_desc_t *md);
 extern void efi_sync_low_kernel_mappings(void);
-extern void efi_setup_page_tables(void);
+extern int efi_setup_page_tables(unsigned long pa_memmap, unsigned num_pages);
+extern void efi_cleanup_page_tables(unsigned long pa_memmap, unsigned 
num_pages);
 extern void __init old_map_region(efi_memory_desc_t *md);
 
 struct efi_setup_data {
diff --git a/arch/x86/platform/efi/efi.c b/arch/x86/platform/efi/efi.c
index c34be4ce94c9..65a8c969db87 100644
--- a/arch/x86/platform/efi/efi.c
+++ b/arch/x86/platform/efi/efi.c
@@ -948,14 +948,36 @@ static void __init efi_map_regions_fixed(void)
 
 }
 
+static void *realloc_pages(void *old_memmap, int old_shift)
+{
+   void *ret;
+
+   ret = (void *)__get_free_pages(GFP_KERNEL, old_shift + 1);
+   if (!ret)
+   goto out;
+
+   /*
+* A first-time allocation doesn't have anything to copy.
+*/
+   if (!old_memmap)
+   return ret;
+
+   memcpy(ret, old_memmap, PAGE_SIZE << old_shift);
+
+out:
+   __free_pages(old_memmap, old_shift);
+   return ret;
+}
+
 /*
- * Map efi memory ranges for runtime serivce and update new_memmap with virtual
- * addresses.
+ * Map the efi memory ranges of the runtime services and update new_mmap with
+ * virtual addresses.
  */
-static void * __init efi_map_regions(int *count)
+static void * __init efi_map_regions(int *count, int *pg_shift)
 {
+   void *p, *new_memmap = NULL;
+   unsigned long left = 0;
efi_memory_desc_t *md;
-   void *p, *tmp, *new_memmap = NULL;
 
for (p = memmap.map; p < memmap.map_end; p += memmap.desc_size) {
md = p;
@@ -970,20 +992,23 @@ static void * __init efi_map_regions(int *count)
efi_map_region(md);
get_systab_virt_addr(md);
 
-   tmp = krealloc(new_memmap, (*count + 1) * memmap.desc_size,
-  GFP_KERNEL);
-   if (!tmp)
-   goto out;
-   new_memmap = tmp;
+   if (left < memmap.desc_size) {
+   new_memmap = realloc_pages(new_memmap, *pg_shift);
+   if (!new_memmap)
+   return NULL;
+
+   left += PAGE_SIZE << *pg_shift;
+   (*pg_shift)++;
+   }
+
memcpy(new_memmap + (*count * memmap.desc_size), md,
   memmap.desc_size);
+
+   left -= memmap.desc_size;
(*count)++;
}
 
return new_memmap;
-out:
-   kfree(new_memmap);
-   return NULL;
 }
 
 /*
@@ -1009,9 +1034,9 @@ out:
  */
 void __init efi_enter_virtual_mode(void)
 {
-   efi_status_t status;
+   int err, count = 0, pg_shift = 0;
void *new_memmap = NULL;
-   int err, count = 0;
+   efi_status_t status;
 
efi.systab = NULL;
 
@@ -1028,7 +1053,7 @@ void __init efi_enter_virtual_mode(void)
efi_map_regions_fixed();
} else {
efi_merge_regions();
-   new_memmap = efi_map_regions(&count);
+   new_memmap = efi_map_regions(&count, &pg_shift);
if (!new_me

[PATCH 0/4] EFI memmap fix v2

2014-01-11 Thread Borislav Petkov
From: Borislav Petkov 

Ok, here's v2 rebased and rediffed against tip (which has the relevant
efi branches).

Toshi, I'm pushing it to:

git://git.kernel.org/pub/scm/linux/kernel/git/bp/bp.git#efi-fixes

so that you can give it another run and so that the build robot can poke
at it.

Thanks.

Changelog:

* v1:

this is the result of Toshi and me debugging a #GP on one of his big HP
boxes sporting UEFI. Each commit message should be self-explanatory so
please look there.

This has more or less an RFC nature thus I'm sending it now to collect
feedback. It is going to wait in the EFI queue anyway after the kexec
stuff gets sorted out first.

Comments and suggestions as always are very much appreciated.

Borislav Petkov (4):
  x86, ptdump: Add the functionality to dump an arbitrary pagetable
  efi: Dump the EFI page table
  x86, pageattr: Export page unmapping interface
  efi: Make efi virtual runtime map passing more robust

 arch/x86/include/asm/efi.h   |  3 +-
 arch/x86/include/asm/pgtable.h   |  3 +-
 arch/x86/include/asm/pgtable_types.h |  2 +
 arch/x86/mm/dump_pagetables.c| 77 
 arch/x86/mm/pageattr.c   | 44 +++--
 arch/x86/platform/efi/efi.c  | 73 ++
 arch/x86/platform/efi/efi_32.c   |  6 ++-
 arch/x86/platform/efi/efi_64.c   | 31 +--
 8 files changed, 177 insertions(+), 62 deletions(-)

-- 
1.8.5.2.192.g7794a68

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


[PATCH 3/4] x86, pageattr: Export page unmapping interface

2014-01-11 Thread Borislav Petkov
From: Borislav Petkov 

We will use it in efi so expose it.

Signed-off-by: Borislav Petkov 
---
 arch/x86/include/asm/pgtable_types.h |  2 ++
 arch/x86/mm/pageattr.c   | 44 +---
 2 files changed, 33 insertions(+), 13 deletions(-)

diff --git a/arch/x86/include/asm/pgtable_types.h 
b/arch/x86/include/asm/pgtable_types.h
index a83aa44bb1fb..765a4f52d6cd 100644
--- a/arch/x86/include/asm/pgtable_types.h
+++ b/arch/x86/include/asm/pgtable_types.h
@@ -384,6 +384,8 @@ extern pte_t *lookup_address(unsigned long address, 
unsigned int *level);
 extern phys_addr_t slow_virt_to_phys(void *__address);
 extern int kernel_map_pages_in_pgd(pgd_t *pgd, u64 pfn, unsigned long address,
   unsigned numpages, unsigned long page_flags);
+void kernel_unmap_pages_in_pgd(pgd_t *root, unsigned long address,
+  unsigned numpages);
 #endif /* !__ASSEMBLY__ */
 
 #endif /* _ASM_X86_PGTABLE_DEFS_H */
diff --git a/arch/x86/mm/pageattr.c b/arch/x86/mm/pageattr.c
index b3b19f46c016..a3488689e301 100644
--- a/arch/x86/mm/pageattr.c
+++ b/arch/x86/mm/pageattr.c
@@ -692,6 +692,18 @@ static bool try_to_free_pmd_page(pmd_t *pmd)
return true;
 }
 
+static bool try_to_free_pud_page(pud_t *pud)
+{
+   int i;
+
+   for (i = 0; i < PTRS_PER_PUD; i++)
+   if (!pud_none(pud[i]))
+   return false;
+
+   free_page((unsigned long)pud);
+   return true;
+}
+
 static bool unmap_pte_range(pmd_t *pmd, unsigned long start, unsigned long end)
 {
pte_t *pte = pte_offset_kernel(pmd, start);
@@ -805,6 +817,16 @@ static void unmap_pud_range(pgd_t *pgd, unsigned long 
start, unsigned long end)
 */
 }
 
+static void unmap_pgd_range(pgd_t *root, unsigned long addr, unsigned long end)
+{
+   pgd_t *pgd_entry = root + pgd_index(addr);
+
+   unmap_pud_range(pgd_entry, addr, end);
+
+   if (try_to_free_pud_page((pud_t *)pgd_page_vaddr(*pgd_entry)))
+   pgd_clear(pgd_entry);
+}
+
 static int alloc_pte_page(pmd_t *pmd)
 {
pte_t *pte = (pte_t *)get_zeroed_page(GFP_KERNEL | __GFP_NOTRACK);
@@ -999,9 +1021,8 @@ static int populate_pud(struct cpa_data *cpa, unsigned 
long start, pgd_t *pgd,
 static int populate_pgd(struct cpa_data *cpa, unsigned long addr)
 {
pgprot_t pgprot = __pgprot(_KERNPG_TABLE);
-   bool allocd_pgd = false;
-   pgd_t *pgd_entry;
pud_t *pud = NULL;  /* shut up gcc */
+   pgd_t *pgd_entry;
int ret;
 
pgd_entry = cpa->pgd + pgd_index(addr);
@@ -1015,7 +1036,6 @@ static int populate_pgd(struct cpa_data *cpa, unsigned 
long addr)
return -1;
 
set_pgd(pgd_entry, __pgd(__pa(pud) | _KERNPG_TABLE));
-   allocd_pgd = true;
}
 
pgprot_val(pgprot) &= ~pgprot_val(cpa->mask_clr);
@@ -1023,19 +1043,11 @@ static int populate_pgd(struct cpa_data *cpa, unsigned 
long addr)
 
ret = populate_pud(cpa, addr, pgd_entry, pgprot);
if (ret < 0) {
-   unmap_pud_range(pgd_entry, addr,
+   unmap_pgd_range(cpa->pgd, addr,
addr + (cpa->numpages << PAGE_SHIFT));
-
-   if (allocd_pgd) {
-   /*
-* If I allocated this PUD page, I can just as well
-* free it in this error path.
-*/
-   pgd_clear(pgd_entry);
-   free_page((unsigned long)pud);
-   }
return ret;
}
+
cpa->numpages = ret;
return 0;
 }
@@ -1861,6 +1873,12 @@ out:
return retval;
 }
 
+void kernel_unmap_pages_in_pgd(pgd_t *root, unsigned long address,
+  unsigned numpages)
+{
+   unmap_pgd_range(root, address, address + (numpages << PAGE_SHIFT));
+}
+
 /*
  * The testcases use internal knowledge of the implementation that shouldn't
  * be exposed to the rest of the kernel. Include these directly here.
-- 
1.8.5.2.192.g7794a68

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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: [percpu_counter] WARNING: CPU: 1 PID: 1 at kernel/locking/lockdep.c:3537 check_flags()

2014-01-11 Thread Andrew Morton
On Sun, 12 Jan 2014 00:36:07 +0800 Ming Lei  wrote:

> >
> > [8.093354] [ cut here ]
> > [8.095469] WARNING: CPU: 1 PID: 1 at kernel/locking/lockdep.c:3537 
> > check_flags+0x77/0x1ba()
> > [8.095469] DEBUG_LOCKS_WARN_ON(current->hardirqs_enabled)
> 
> The warning is caused by the added raw_local_irq_save(), which should
> have been local_irq_save(flags). Actually, it is a false positive.
> 
> Andrew, considered that your approach may be more efficient than this
> one since preempt_disable()/preempt_enable() can be removed too.
> 
> So could you prepare one patch for fixing the problem? Or if you are busy, I'd
> like to do it.

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


Re: [PATCH 0/2] Staging: rtl8188eu: checkpatch.pl error cleanups

2014-01-11 Thread Greg KH
On Thu, Jan 09, 2014 at 09:37:09PM +0100, Tim Jester-Pfadt wrote:
> This patchset fixes all occurrences of the "space required after ','"
> "space required around '='" aswell as "foo * bar" related checkpatch.pl 
> errors in
> rtl8188eu.
> 
> The patchset does not fix the remaining 80 character limit  warnings, since 
> this might
> require more substantial code modifiction.
> 
> Tim Jester-Pfadt (2):
>   Staging: rtl8188eu: Fixed required spaces after ',' and around '=' and
> '=='
>   Staging: rtl8188eu: Fixed "foo * bar" related coding style issues

These patches don't apply to my tree at all.  Please redo them against
the staging-next branch of the staging.git tree on git.kernel.org.

thanks,

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


Re: [PATCH v2 1/3] Staging: lustre: Fix return does not need parantheses

2014-01-11 Thread Greg KH
On Sun, Jan 12, 2014 at 01:31:41AM +0530, Monam Agarwal wrote:
> The patch fixes the following checkpatch.pl error in
> lustre/ldlm/ldlm_flock.c
> ERROR: return is not a function, parentheses are not required 
> 
> Signed-off-by: Monam Agarwal 

I'm totally confused here.  You have multiple series of patches, sent
with different version numbers, some with the same subjects, and some
not.

I've deleted all of your lustre patches from my queue because of this, I
don't want to apply something incorrectly.

Please step back, take a day, and resend all of your pending patches
that I have not applied for the lustre code, in a single series, so I
know what I should be looking at here.

There's no rush, so please take your time and do your best to keep an
overworked maintainer from getting things wrong.

thanks,

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


Re: [PATCH v3 1/2] Staging: lustre: Refactor the function interval_erase_color() in /lustre/ldlm/interval_tree.c

2014-01-11 Thread Greg KH
On Sat, Jan 11, 2014 at 05:14:35PM +0530, Monam Agarwal wrote:
> On Sat, Jan 11, 2014 at 5:09 PM, Dan Carpenter  
> wrote:
> > On Sat, Jan 11, 2014 at 04:56:44PM +0530, Monam Agarwal wrote:
> >> I took n as a flag to decide whether parent->in_left == node is true
> >> or not in the called function.
> >
> > So "n" stands for "node"?
> >
> >> Should I use some other name for the flag.
> >
> >
> > Yes.
> >
> 
> Will "flag" be a suitable name?

Ick, no.  You don't want a "flag" to have to determine what the logic is
for a given function.  That just causes confusion and makes things
really hard to read and understand over time.

This whole function looks like a red/black tree, or something like that.
Shouldn't we just be using the in-kernel implementation of this?  And if
not, then you really need to get the feedback of the code's original
authors as you might be changing the algorithm in ways that could cause
big problems.

thanks,

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


Re: [ANNOUNCE] 3.12.6-rt9

2014-01-11 Thread Joakim Hernberg
On Fri, 27 Dec 2013 21:00:24 +0100
Nicholas Mc Guire  wrote:

> On Mon, 23 Dec 2013, Sebastian Andrzej Siewior wrote:
> 
> > Dear RT folks!
> > 
> > I'm pleased to announce the v3.12.6-rt9 patch set.
> > 
> > Changes since v3.12.6-rt8
> 
> > - A patch from Thomas Gleixner not to raise the timer softirq
> >   unconditionally (only if a timer is pending)
> > 
> 
> This one seems to deadlock early in the boot sequence on x86
> (i3/i7/Phenom-4x here and Carsten Emde also had boot failures)

This patch seems to frequently make the kernel hang hard early in the
boot process on my i7-2600k too. Reverting
timers-do-not-raise-softirq-unconditionally.patch appears to fix the
problem.

-- 

   Joakim
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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: [PATCHSET v2 driver-core-next] kernfs, sysfs, driver-core: implement synchronous self-removal

2014-01-11 Thread Greg KH
On Sat, Jan 11, 2014 at 01:51:10PM -0500, Tejun Heo wrote:
> Hey, Alan.
> 
> On Fri, Jan 10, 2014 at 10:46:10AM -0500, Alan Stern wrote:
> > The SUBJECT lines in your patch emails don't mention the version
> > number.  That is, they just say "[PATCH]", not "[PATCH v2]" or "[PATCH
> > v3]". This makes it very difficult for me to tell which messages to
> > read.
> 
> Hmm... they're all threaded.  I add version tags when posting
> incremental patches but usually don't bother with it when posting a
> new version of the whole series.  After all, some patches are get
> updated without explicitly given a new version for refrehses and stuff
> so it's not like you can determine everything based on subjects only.
> 
> > (Reading them in order doesn't work, because my computer mixes up the 
> > order of messages when it downloads a large bunch from the email 
> > server.  It's kind of annoying...)
> 
> And they aren't threaded?

They were all threaded for me, perhaps Alan needs a better email client :)
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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 v3] Staging: lustre: Use of fls to find last set bit

2014-01-11 Thread Monam Agarwal
This introduces fls in lustre/ldlm/ldlm_extent.c
to find the last set bit.

Signed-off-by: Monam Agarwal 
---
Changes since v1:
* Incorrect commit message
* Use of fls function
Changes since v2:
* Removal of extra variable

 drivers/staging/lustre/lustre/ldlm/ldlm_extent.c |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/staging/lustre/lustre/ldlm/ldlm_extent.c 
b/drivers/staging/lustre/lustre/ldlm/ldlm_extent.c
index ac5d66a..a4f382d 100644
--- a/drivers/staging/lustre/lustre/ldlm/ldlm_extent.c
+++ b/drivers/staging/lustre/lustre/ldlm/ldlm_extent.c
@@ -153,7 +153,7 @@ static inline int lock_mode_to_index(ldlm_mode_t mode)
 
LASSERT(mode != 0);
LASSERT(IS_PO2(mode));
-   for (index = -1; mode; index++, mode >>= 1) ;
+   index = fls(mode)-1;
LASSERT(index < LCK_MODE_NUM);
return index;
 }
-- 
1.7.9.5

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


Re: [PATCH] mtd: nand: assign mtd->name in find_full_id_nand

2014-01-11 Thread Brian Norris
Hi,

On Thu, Dec 26, 2013 at 10:19:39AM +0800, Huang Shijie wrote:
> On Thu, Dec 26, 2013 at 01:51:58AM +, Caizhiyong wrote:
> > From: Cai Zhiyong 
> > Date: Wed, 25 Dec 2013 21:19:21 +0800
> > Subject: [PATCH] mtd: nand: assign mtd->name in find_full_id_nand
> > 
> > This patch assigned the type->name to mtd->name when mtd->name is
> > NULL in function "find_full_id_nand".
> > mtd->name is NULL may cause some problem.
> > 
> > Signed-off-by: Cai Zhiyong 
> Acked-by: Huang Shijie 

Thanks, the patch looks good. Pushed to l2-mtd.git.

Wouldn't this trigger an exception when reading
/sys/class/mtd/mtdX/name? If so, should this be marked for stable?

Brian
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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 3/3] Staging: lustre: Fix warning on quoted string on multiple lines

2014-01-11 Thread Monam Agarwal
This patch fixes the following checkpatch.pl warning in
lustre/ldlm/ldlm_flock.c
WARNING: quoted string split across lines

Signed-off-by: Monam Agarwal 
---
 drivers/staging/lustre/lustre/ldlm/ldlm_flock.c |4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/staging/lustre/lustre/ldlm/ldlm_flock.c 
b/drivers/staging/lustre/lustre/ldlm/ldlm_flock.c
index 2b5c2fe..b175bbc 100644
--- a/drivers/staging/lustre/lustre/ldlm/ldlm_flock.c
+++ b/drivers/staging/lustre/lustre/ldlm/ldlm_flock.c
@@ -592,8 +592,8 @@ ldlm_flock_completion_ast(struct ldlm_lock *lock, __u64 
flags, void *data)
return 0;
}

-   LDLM_DEBUG(lock, "client-side enqueue returned a blocked lock, "
-  "sleeping");
+   LDLM_DEBUG(lock,
+  "client-side enqueue returned a blocked lock, sleeping");
fwd.fwd_lock = lock;
obd = class_exp2obd(lock->l_conn_export);

-- 
1.7.9.5

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


[PATCH v2 2/3] Staging: lustre: :Fix line over 80 character warning

2014-01-11 Thread Monam Agarwal
The patch fixes the following checkpatch.pl error in
lustre/ldlm/ldlm_flock.c
WARNING: line over 80 characters in the file 

Signed-off-by: Monam Agarwal 
---
 drivers/staging/lustre/lustre/ldlm/ldlm_flock.c |3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/staging/lustre/lustre/ldlm/ldlm_flock.c 
b/drivers/staging/lustre/lustre/ldlm/ldlm_flock.c
index 07a2c33..2b5c2fe 100644
--- a/drivers/staging/lustre/lustre/ldlm/ldlm_flock.c
+++ b/drivers/staging/lustre/lustre/ldlm/ldlm_flock.c
@@ -468,7 +468,8 @@ reprocess:
new->l_policy_data.l_flock.end + 1;
new2->l_conn_export = lock->l_conn_export;
if (lock->l_export != NULL) {
-   new2->l_export = class_export_lock_get(lock->l_export, 
new2);
+   new2->l_export =
+   class_export_lock_get(lock->l_export, new2);
if (new2->l_export->exp_lock_hash &&
hlist_unhashed(&new2->l_exp_hash))
cfs_hash_add(new2->l_export->exp_lock_hash,
-- 
1.7.9.5

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


Re: [PATCH v2] Staging: lustre: Use of fls to find last set bit

2014-01-11 Thread Joe Perches
On Sun, 2014-01-12 at 01:02 +0530, Monam Agarwal wrote:
> This introduces fls in lustre/ldlm/ldlm_extent.c 
> to find the last set bit. 
[]
> Signed-off-by: Monam Agarwal 
> ---
> Changes since v1:
> *Incorrect commit message
> *Use of fls function
[]
> diff --git a/drivers/staging/lustre/lustre/ldlm/ldlm_extent.c 
> b/drivers/staging/lustre/lustre/ldlm/ldlm_extent.c
[]
> @@ -150,10 +150,12 @@ struct ldlm_interval *ldlm_interval_detach(struct 
> ldlm_lock *l)
>  static inline int lock_mode_to_index(ldlm_mode_t mode)
>  {
>   int index;
> + int len;
>  
>   LASSERT(mode != 0);
>   LASSERT(IS_PO2(mode));
> - for (index = -1; mode; index++, mode >>= 1) ;
> + len = fls(mode);
> + index = len-1;

There's no need for len at all.

index = fls(mode) - 1;

would be fine.


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


[PATCH v2 1/3] Staging: lustre: Fix return does not need parantheses

2014-01-11 Thread Monam Agarwal
The patch fixes the following checkpatch.pl error in
lustre/ldlm/ldlm_flock.c
ERROR: return is not a function, parentheses are not required 

Signed-off-by: Monam Agarwal 
---
 drivers/staging/lustre/lustre/ldlm/ldlm_flock.c |8 
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/drivers/staging/lustre/lustre/ldlm/ldlm_flock.c 
b/drivers/staging/lustre/lustre/ldlm/ldlm_flock.c
index c9aae13..07a2c33 100644
--- a/drivers/staging/lustre/lustre/ldlm/ldlm_flock.c
+++ b/drivers/staging/lustre/lustre/ldlm/ldlm_flock.c
@@ -81,18 +81,18 @@ int ldlm_flock_blocking_ast(struct ldlm_lock *lock, struct 
ldlm_lock_desc *desc,
 static inline int
 ldlm_same_flock_owner(struct ldlm_lock *lock, struct ldlm_lock *new)
 {
-   return((new->l_policy_data.l_flock.owner ==
+   return (new->l_policy_data.l_flock.owner ==
lock->l_policy_data.l_flock.owner) &&
-  (new->l_export == lock->l_export));
+  (new->l_export == lock->l_export);
 }

 static inline int
 ldlm_flocks_overlap(struct ldlm_lock *lock, struct ldlm_lock *new)
 {
-   return((new->l_policy_data.l_flock.start <=
+   return (new->l_policy_data.l_flock.start <=
lock->l_policy_data.l_flock.end) &&
   (new->l_policy_data.l_flock.end >=
-   lock->l_policy_data.l_flock.start));
+   lock->l_policy_data.l_flock.start);
 }

 static inline void ldlm_flock_blocking_link(struct ldlm_lock *req,
-- 
1.7.9.5

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


Re: [PATCH RFC 00/10] Generic Device Tree based power domain look-up

2014-01-11 Thread Tomasz Figa
On Saturday 11 of January 2014 20:42:42 Tomasz Figa wrote:
> Up till now there was no single generic method to bind devices to their
> power domains using Device Tree. Each platform has been doing this using
> its own way, example of which are Exynos power domain bindings [1] and
> look-up code [2].
> 
> This series is intended to change this and provide generic DT bindings for
> power domain specification and generic code performing look-up of power
> domains and binding them to devices.
> 
> Patches 1, 2, 3 are not directly related to this series, but they are
> dependencies of further patches making mach-s3c64xx a user of introduced
> code. Patch 4 is the most important part of this series, as it's the one
> introducing $subject. Further patches are fixing and adding two users,
> mach-exynos (removing the legacy code) and mach-s3c64xx (no DT support for
> power domains before). Last two patches are adding display support for
> Mini6410 board, including a node for display controller (FIMD) which is
> a power domain consumer.
> 
> Successfully tested on S3C6410-based Mini6410 board.
> 

I left the references for the end of this cover letter and finally forgot
about them. Please accept my apologies ;).

[1] Documentation/devicetree/bindings/arm/exynos/power_domain.txt
[2] arch/arm/mach-exynos/pm_domains.c

Also it might be good to mention that I was heavily inspired by
implementation of clock providers in Common Clock Framework in case of
provider registration and look-up and also by my Exynos power domain
implementation (now removed by this series ;)) in case of code binding
devices to power domains.

Best regards,
Tomasz

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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/9] perf, tools: Enable printing the srcline in the history

2014-01-11 Thread Andi Kleen
From: Andi Kleen 

For lbr-as-callgraph we need to see the line number in the history,
because many LBR entries can be in a single function, and just
showing the same function name many times is not useful.

When the history code is configured to sort by address, also try to
resolve the address to a file:srcline and display this in the browser.
If that doesn't work still display the address.

This can be also useful without LBRs for understanding which call in a large
function (or in which inlined function) called something else.

Contains fixes from Namhyung Kim

Signed-off-by: Andi Kleen 
---
 tools/perf/ui/browsers/hists.c | 15 ---
 tools/perf/ui/stdio/hist.c | 16 +---
 tools/perf/util/callchain.h|  1 +
 tools/perf/util/machine.c  |  2 +-
 tools/perf/util/srcline.c  |  6 --
 5 files changed, 31 insertions(+), 9 deletions(-)

diff --git a/tools/perf/ui/browsers/hists.c b/tools/perf/ui/browsers/hists.c
index b720b92..509f550 100644
--- a/tools/perf/ui/browsers/hists.c
+++ b/tools/perf/ui/browsers/hists.c
@@ -399,9 +399,18 @@ static char *callchain_list__sym_name(struct 
callchain_list *cl,
 {
int printed;
 
-   if (cl->ms.sym)
-   printed = scnprintf(bf, bfsize, "%s", cl->ms.sym->name);
-   else
+   if (cl->ms.sym) {
+   if (callchain_param.key == CCKEY_ADDRESS && 
+   cl->ms.map && !cl->srcline)
+   cl->srcline = get_srcline(cl->ms.map->dso,
+ map__rip_2objdump(cl->ms.map,
+   cl->ip));
+   if (cl->srcline)
+   printed = scnprintf(bf, bfsize, "%s %s", 
+   cl->ms.sym->name, cl->srcline);
+   else
+   printed = scnprintf(bf, bfsize, "%s", cl->ms.sym->name);
+   } else
printed = scnprintf(bf, bfsize, "%#" PRIx64, cl->ip);
 
if (show_dso)
diff --git a/tools/perf/ui/stdio/hist.c b/tools/perf/ui/stdio/hist.c
index 831fbb7..894b12c 100644
--- a/tools/perf/ui/stdio/hist.c
+++ b/tools/perf/ui/stdio/hist.c
@@ -56,9 +56,19 @@ static size_t ipchain__fprintf_graph(FILE *fp, struct 
callchain_list *chain,
} else
ret += fprintf(fp, "%s", "  ");
}
-   if (chain->ms.sym)
-   ret += fprintf(fp, "%s\n", chain->ms.sym->name);
-   else
+   if (chain->ms.sym) {
+   if (callchain_param.key == CCKEY_ADDRESS && 
+   chain->ms.map)
+   chain->srcline = get_srcline(chain->ms.map->dso,
+ map__rip_2objdump(
+ chain->ms.map,
+ chain->ip));
+   if (chain->srcline)
+   ret += fprintf(fp, "%s %s\n", 
+  chain->ms.sym->name, chain->srcline);
+   else
+   ret += fprintf(fp, "%s\n", chain->ms.sym->name);
+   } else
ret += fprintf(fp, "0x%0" PRIx64 "\n", chain->ip);
 
return ret;
diff --git a/tools/perf/util/callchain.h b/tools/perf/util/callchain.h
index a1a298a..0e4d016 100644
--- a/tools/perf/util/callchain.h
+++ b/tools/perf/util/callchain.h
@@ -59,6 +59,7 @@ struct callchain_param {
 struct callchain_list {
u64 ip;
struct map_symbol   ms;
+   char   *srcline;
struct list_headlist;
 };
 
diff --git a/tools/perf/util/machine.c b/tools/perf/util/machine.c
index 2f440f2..4032634 100644
--- a/tools/perf/util/machine.c
+++ b/tools/perf/util/machine.c
@@ -1294,7 +1294,7 @@ static int add_callchain_ip(struct machine *machine,
return -EINVAL;
}
 
-   return callchain_cursor_append(&callchain_cursor, ip, al.map, al.sym);
+   return callchain_cursor_append(&callchain_cursor, al.addr, al.map, 
al.sym);
 }
 
 #define CHASHSZ 127
diff --git a/tools/perf/util/srcline.c b/tools/perf/util/srcline.c
index 7e67879..680c02b 100644
--- a/tools/perf/util/srcline.c
+++ b/tools/perf/util/srcline.c
@@ -258,7 +258,7 @@ char *get_srcline(struct dso *dso, unsigned long addr)
const char *dso_name;
 
if (!dso->has_srcline)
-   return SRCLINE_UNKNOWN;
+   goto out;
 
if (dso->symsrc_filename)
dso_name = dso->symsrc_filename;
@@ -289,7 +289,9 @@ out:
dso->has_srcline = 0;
dso__free_a2l(dso);
}
-   return SRCLINE_UNKNOWN;
+   if (asprintf(&srcline, "%s[%lx]", dso->short_name, addr) < 0)
+   return SRCLINE_UNKNOWN;
+   return srcline;
 }
 
 void free_srcline(char *srcline)
-- 
1.8.3.1

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

[PATCH 2/9] perf, tools: Support handling complete branch stacks as histograms

2014-01-11 Thread Andi Kleen
From: Andi Kleen 

Currently branch stacks can be only shown as edge histograms for
individual branches. I never found this display particularly useful.

This implements an alternative mode that creates histograms over complete
branch traces, instead of individual branches, similar to how normal
callgraphs are handled. This is done by putting it in
front of the normal callgraph and then using the normal callgraph
histogram infrastructure to unify them.

This way in complex functions we can understand the control flow
that lead to a particular sample, and may even see some control
flow in the caller for short functions.

Example (simplified, of course for such simple code this
is usually not needed):

tcall.c:

volatile a = 1, b = 10, c;

__attribute__((noinline)) f2()
{
c = a / b;
}

__attribute__((noinline)) f1()
{
f2();
f2();
}
main()
{
int i;
for (i = 0; i < 100; i++)
f1();
}

% perf record -b -g ./tsrc/tcall
[ perf record: Woken up 1 times to write data ]
[ perf record: Captured and wrote 0.044 MB perf.data (~1923 samples) ]
% perf report --branch-history
...
54.91%  tcall.c:6  [.] f2  tcall
|
|--65.53%-- f2 tcall.c:5
|  |
|  |--70.83%-- f1 tcall.c:11
|  |  f1 tcall.c:10
|  |  main tcall.c:18
|  |  main tcall.c:18
|  |  main tcall.c:17
|  |  main tcall.c:17
|  |  f1 tcall.c:13
|  |  f1 tcall.c:13
|  |  f2 tcall.c:7
|  |  f2 tcall.c:5
|  |  f1 tcall.c:12
|  |  f1 tcall.c:12
|  |  f2 tcall.c:7
|  |  f2 tcall.c:5
|  |  f1 tcall.c:11
|  |
|   --29.17%-- f1 tcall.c:12
| f1 tcall.c:12
| f2 tcall.c:7
| f2 tcall.c:5
| f1 tcall.c:11
| f1 tcall.c:10
| main tcall.c:18
| main tcall.c:18
| main tcall.c:17
| main tcall.c:17
| f1 tcall.c:13
| f1 tcall.c:13
| f2 tcall.c:7
| f2 tcall.c:5
| f1 tcall.c:12

The default output is unchanged.

This is only implemented in perf report, no change to record
or anywhere else.

This adds the basic code to report:
- add a new "branch" option to the -g option parser to enable this mode
- when the flag is set include the LBR into the callstack in machine.c.
The rest of the history code is unchanged and doesn't know the difference
between LBR entry and normal call entry.

Current limitations:
- The LBR flags (mispredict etc.) are not shown in the history
and LBR entries have no special marker.
- It would be nice if annotate marked the LBR entries somehow
(e.g. with arrows)

v2: Various fixes.
Signed-off-by: Andi Kleen 
---
 tools/perf/builtin-report.c |  15 --
 tools/perf/util/callchain.h |   1 +
 tools/perf/util/machine.c   | 113 
 tools/perf/util/symbol.h|   3 +-
 4 files changed, 106 insertions(+), 26 deletions(-)

diff --git a/tools/perf/builtin-report.c b/tools/perf/builtin-report.c
index 46864dd..19a74e1 100644
--- a/tools/perf/builtin-report.c
+++ b/tools/perf/builtin-report.c
@@ -658,7 +658,7 @@ parse_callchain_opt(const struct option *opt, const char 
*arg, int unset)
callchain_param.order = ORDER_CALLER;
else if (!strncmp(tok2, "callee", strlen("callee")))
callchain_param.order = ORDER_CALLEE;
-   else
+   else if (tok2[0] != 0)
return -1;
 
/* Get the sort key */
@@ -669,8 +669,15 @@ parse_callchain_opt(const struct option *opt, const char 
*arg, int unset)
callchain_param.key = CCKEY_FUNCTION;
else if (!strncmp(tok2, "address", strlen("address")))
callchain_param.key = CCKEY_ADDRESS;
-   else
+   else if (tok2[0] != 0)
return -1;
+
+   tok2 = strtok(NULL, ",");
+   if (!tok2)
+   goto setup;
+   if (!strncmp(tok2, "branch", 6))
+   callchain_param.branch_callstack = 1;
+
 setup:
if (callchain_register_param(&callchain_param) < 0) {
pr_err("Can't register callchain params\n");
@@ -786,8 +793,8 @@ int cmd_report(int argc, const char **argv, const char 
*prefix __maybe_unused)
   "regex filter to iden

[PATCH 9/9] perf, tools: Support source line numbers in annotate

2014-01-11 Thread Andi Kleen
From: Andi Kleen 

With srcline key/sort'ing it's useful to have line numbers
in the annotate window. This patch implements this.

Use objdump -l to request the line numbers and
save them in the line structure. Then the browser
displays them for source lines.

The line numbers are not displayed by default, but can be
toggled on with 'k'

There is one unfortunate problem with this setup. For
lines not containing source and which are outside functions
objdump -l reports the wrong line numbers (it always reports
the first line number in the next function even for lines
that are outside the function)
I haven't find a nice way to detect/correct this. Probably objdump
has to be fixed.
See https://sourceware.org/bugzilla/show_bug.cgi?id=16433

The line numbers are still useful even with these problems,
as most are correct.

Signed-off-by: Andi Kleen 
---
 tools/perf/ui/browsers/annotate.c | 13 -
 tools/perf/util/annotate.c| 30 +-
 tools/perf/util/annotate.h|  1 +
 3 files changed, 38 insertions(+), 6 deletions(-)

diff --git a/tools/perf/ui/browsers/annotate.c 
b/tools/perf/ui/browsers/annotate.c
index f0697a3..1c8aab0 100644
--- a/tools/perf/ui/browsers/annotate.c
+++ b/tools/perf/ui/browsers/annotate.c
@@ -27,6 +27,7 @@ static struct annotate_browser_opt {
bool hide_src_code,
 use_offset,
 jump_arrows,
+show_linenr,
 show_nr_jumps;
 } annotate_browser__opts = {
.use_offset = true,
@@ -128,7 +129,11 @@ static void annotate_browser__write(struct ui_browser 
*browser, void *entry, int
if (!*dl->line)
slsmg_write_nstring(" ", width - pcnt_width);
else if (dl->offset == -1) {
-   printed = scnprintf(bf, sizeof(bf), "%*s  ",
+   if (dl->line_nr && annotate_browser__opts.show_linenr) 
+   printed = scnprintf(bf, sizeof(bf), "%*s %-5d ",
+   ab->addr_width, " ", dl->line_nr);
+   else
+   printed = scnprintf(bf, sizeof(bf), "%*s  ",
ab->addr_width, " ");
slsmg_write_nstring(bf, printed);
slsmg_write_nstring(dl->line, width - printed - pcnt_width + 1);
@@ -733,6 +738,7 @@ static int annotate_browser__run(struct annotate_browser 
*browser,
"o Toggle disassembler output/simplified view\n"
"s Toggle source code view\n"
"/ Search string\n"
+   "k Toggle line numbers\n"
"r Run available scripts\n"
"? Search string backwards\n");
continue;
@@ -741,6 +747,10 @@ static int annotate_browser__run(struct annotate_browser 
*browser,
script_browse(NULL);
continue;
}
+   case 'k':
+   annotate_browser__opts.show_linenr =
+   !annotate_browser__opts.show_linenr;
+   break;
case 'H':
nd = browser->curr_hot;
break;
@@ -984,6 +994,7 @@ static struct annotate_config {
 } annotate__configs[] = {
ANNOTATE_CFG(hide_src_code),
ANNOTATE_CFG(jump_arrows),
+   ANNOTATE_CFG(show_linenr),
ANNOTATE_CFG(show_nr_jumps),
ANNOTATE_CFG(use_offset),
 };
diff --git a/tools/perf/util/annotate.c b/tools/perf/util/annotate.c
index 469eb67..f020110 100644
--- a/tools/perf/util/annotate.c
+++ b/tools/perf/util/annotate.c
@@ -15,11 +15,13 @@
 #include "debug.h"
 #include "annotate.h"
 #include "evsel.h"
+#include 
 #include 
 #include 
 
 const char *disassembler_style;
 const char *objdump_path;
+static regex_t  file_lineno;
 
 static struct ins *ins__find(const char *name);
 static int disasm_line__parse(char *line, char **namep, char **rawp);
@@ -562,13 +564,15 @@ out_free_name:
return -1;
 }
 
-static struct disasm_line *disasm_line__new(s64 offset, char *line, size_t 
privsize)
+static struct disasm_line *disasm_line__new(s64 offset, char *line,
+   size_t privsize, int line_nr)
 {
struct disasm_line *dl = zalloc(sizeof(*dl) + privsize);
 
if (dl != NULL) {
dl->offset = offset;
dl->line = strdup(line);
+   dl->line_nr = line_nr;
if (dl->line == NULL)
goto out_delete;
 
@@ -780,13 +784,15 @@ static int disasm_line__print(struct disasm_line *dl, 
struct symbol *sym, u64 st
  * The ops.raw part will be parsed further according to type of the 
instruction.
  */
 static int symbol__parse_objdump_line(struct symbol *sym, struct map *map,
- FILE *file, size_t privsize)
+

[PATCH RFC 00/10] Generic Device Tree based power domain look-up

2014-01-11 Thread Tomasz Figa
Up till now there was no single generic method to bind devices to their
power domains using Device Tree. Each platform has been doing this using
its own way, example of which are Exynos power domain bindings [1] and
look-up code [2].

This series is intended to change this and provide generic DT bindings for
power domain specification and generic code performing look-up of power
domains and binding them to devices.

Patches 1, 2, 3 are not directly related to this series, but they are
dependencies of further patches making mach-s3c64xx a user of introduced
code. Patch 4 is the most important part of this series, as it's the one
introducing $subject. Further patches are fixing and adding two users,
mach-exynos (removing the legacy code) and mach-s3c64xx (no DT support for
power domains before). Last two patches are adding display support for
Mini6410 board, including a node for display controller (FIMD) which is
a power domain consumer.

Successfully tested on S3C6410-based Mini6410 board.

Tomasz Figa (10):
  ARM: s3c64xx: pm: Use name field of generic_pm_domain
  ARM: s3c64xx: pm: Add always_on field to s3c64xx_pm_domain struct
  ARM: s3c64xx: pm: Add pwr_stat bit for domain G
  base: power: Add generic OF-based power domain look-up
  ARM: exynos: Move to generic power domain bindings
  ARM: s3c64xx: pm: Add device tree based power domain instantiation
  ARM: s3c64xx: dt: Enable SoC-level power management
  ARM: dts: s3c64xx: Add nodes for power domains
  ARM: dts: s3c64xx: Add node for display controller
  ARM: dts: s3c6410-mini6410: Add support for LCD screen

 .../bindings/arm/exynos/power_domain.txt   |  12 +-
 .../devicetree/bindings/power/power_domain.txt |  51 
 arch/arm/boot/dts/s3c6400.dtsi |   1 +
 arch/arm/boot/dts/s3c6410-mini6410.dts |  33 ++
 arch/arm/boot/dts/s3c6410.dtsi |   1 +
 arch/arm/boot/dts/s3c64xx.dtsi |  13 +
 arch/arm/mach-exynos/pm_domains.c  |  80 +
 arch/arm/mach-s3c64xx/mach-s3c64xx-dt.c|   8 +
 arch/arm/mach-s3c64xx/pm.c | 106 +--
 drivers/base/power/domain.c| 339 +
 include/dt-bindings/arm/s3c64xx-power-domains.h|  26 ++
 include/linux/pm_domain.h  |  34 +++
 kernel/power/Kconfig   |   4 +
 13 files changed, 597 insertions(+), 111 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/power/power_domain.txt
 create mode 100644 include/dt-bindings/arm/s3c64xx-power-domains.h

-- 
1.8.5.2

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


[PATCH 3/9] perf, tools: Add --branch-history option to report v2

2014-01-11 Thread Andi Kleen
From: Andi Kleen 

Add a --branch-history option to perf report that changes all
the settings necessary for using the branches in callstacks.

This is just a short cut to make this nicer to use, it does
not enable any functionality by itself.

v2: Change sort order. Rename option to --branch-history to
be less confusing.
Signed-off-by: Andi Kleen 
---
 tools/perf/Documentation/perf-report.txt |  5 +
 tools/perf/builtin-report.c  | 27 ---
 2 files changed, 29 insertions(+), 3 deletions(-)

diff --git a/tools/perf/Documentation/perf-report.txt 
b/tools/perf/Documentation/perf-report.txt
index 8eab8a4..5410f35 100644
--- a/tools/perf/Documentation/perf-report.txt
+++ b/tools/perf/Documentation/perf-report.txt
@@ -223,6 +223,11 @@ OPTIONS
branch stacks and it will automatically switch to the branch view mode,
unless --no-branch-stack is used.
 
+--branch-history::
+   Add the addresses of sampled taken branches to the callstack.
+   This allows to examine the path the program took to each sample.
+   The data collection must have used -b (or -j) and -g.
+
 --objdump=::
 Path to objdump binary.
 
diff --git a/tools/perf/builtin-report.c b/tools/perf/builtin-report.c
index 19a74e1..24b48ec 100644
--- a/tools/perf/builtin-report.c
+++ b/tools/perf/builtin-report.c
@@ -715,6 +715,16 @@ parse_branch_mode(const struct option *opt __maybe_unused,
 }
 
 static int
+parse_branch_call_mode(const struct option *opt __maybe_unused,
+ const char *str __maybe_unused, int unset)
+{
+   int *branch_mode = opt->value;
+
+   *branch_mode = !unset;
+   return 0;
+}
+
+static int
 parse_percent_limit(const struct option *opt, const char *str,
int unset __maybe_unused)
 {
@@ -729,7 +739,7 @@ int cmd_report(int argc, const char **argv, const char 
*prefix __maybe_unused)
struct perf_session *session;
struct stat st;
bool has_br_stack = false;
-   int branch_mode = -1;
+   int branch_mode = -1, branch_call_mode = -1;
int ret = -1;
char callchain_default_opt[] = "fractal,0.5,callee";
const char * const report_usage[] = {
@@ -838,7 +848,10 @@ int cmd_report(int argc, const char **argv, const char 
*prefix __maybe_unused)
OPT_BOOLEAN(0, "group", &symbol_conf.event_group,
"Show event group information together"),
OPT_CALLBACK_NOOPT('b', "branch-stack", &branch_mode, "",
-   "use branch records for histogram filling", 
parse_branch_mode),
+   "use branch records for per branch histogram filling", 
parse_branch_mode),
+   OPT_CALLBACK_NOOPT(0, "branch-history", &branch_call_mode, "",
+   "add last branch records to call history",
+   parse_branch_call_mode),
OPT_STRING(0, "objdump", &objdump_path, "path",
   "objdump binary to use for disassembly and annotations"),
OPT_BOOLEAN(0, "demangle", &symbol_conf.demangle,
@@ -886,8 +899,16 @@ repeat:
has_br_stack = perf_header__has_feat(&session->header,
 HEADER_BRANCH_STACK);
 
-   if (branch_mode == -1 && has_br_stack)
+   if (branch_mode == -1 && has_br_stack && branch_call_mode == -1)
sort__mode = SORT_MODE__BRANCH;
+   if (branch_call_mode != -1) {
+   callchain_param.branch_callstack = 1;
+   callchain_param.key = CCKEY_ADDRESS;
+   symbol_conf.use_callchain = true;
+   callchain_register_param(&callchain_param);
+   if (sort_order == default_sort_order)
+   sort_order = "srcline,symbol,dso";
+   }
 
/* sort__mode could be NORMAL if --no-branch-stack */
if (sort__mode == SORT_MODE__BRANCH) {
-- 
1.8.3.1

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


[PATCH 8/9] perf, tools: Only print base source file for srcline

2014-01-11 Thread Andi Kleen
From: Andi Kleen 

For perf report with --sort srcline only print the base source file
name. This makes the results generally fit much better to the
screen. The path is usually not that useful anyways because it is
often from different systems.

Signed-off-by: Andi Kleen 
---
 tools/perf/util/srcline.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/tools/perf/util/srcline.c b/tools/perf/util/srcline.c
index 680c02b..88bf0e8 100644
--- a/tools/perf/util/srcline.c
+++ b/tools/perf/util/srcline.c
@@ -274,7 +274,7 @@ char *get_srcline(struct dso *dso, unsigned long addr)
if (!addr2line(dso_name, addr, &file, &line, dso))
goto out;
 
-   if (asprintf(&srcline, "%s:%u", file, line) < 0) {
+   if (asprintf(&srcline, "%s:%u", basename(file), line) < 0) {
free(file);
goto out;
}
-- 
1.8.3.1

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


[PATCH RFC 01/10] ARM: s3c64xx: pm: Use name field of generic_pm_domain

2014-01-11 Thread Tomasz Figa
This patch removes name field from private s3c64xx_pm_domain struct and
moves domain name to dedicated field of generic_pm_domain struct.

When at it, beautify the names a bit, since they are used by genpd core
as message prefixes.

Signed-off-by: Tomasz Figa 
---
 arch/arm/mach-s3c64xx/pm.c | 19 +--
 1 file changed, 9 insertions(+), 10 deletions(-)

diff --git a/arch/arm/mach-s3c64xx/pm.c b/arch/arm/mach-s3c64xx/pm.c
index 8cdb824..5238d66 100644
--- a/arch/arm/mach-s3c64xx/pm.c
+++ b/arch/arm/mach-s3c64xx/pm.c
@@ -35,7 +35,6 @@
 #include "regs-syscon-power.h"
 
 struct s3c64xx_pm_domain {
-   char *const name;
u32 ena;
u32 pwr_stat;
struct generic_pm_domain pd;
@@ -76,7 +75,7 @@ static int s3c64xx_pd_on(struct generic_pm_domain *domain)
} while (retry--);
 
if (!retry) {
-   pr_err("Failed to start domain %s\n", pd->name);
+   pr_err("Failed to start domain %s\n", pd->pd.name);
return -EBUSY;
}
}
@@ -85,78 +84,78 @@ static int s3c64xx_pd_on(struct generic_pm_domain *domain)
 }
 
 static struct s3c64xx_pm_domain s3c64xx_pm_irom = {
-   .name = "IROM",
.ena = S3C64XX_NORMALCFG_IROM_ON,
.pd = {
+   .name = "domain_irom",
.power_off = s3c64xx_pd_off,
.power_on = s3c64xx_pd_on,
},
 };
 
 static struct s3c64xx_pm_domain s3c64xx_pm_etm = {
-   .name = "ETM",
.ena = S3C64XX_NORMALCFG_DOMAIN_ETM_ON,
.pwr_stat = S3C64XX_BLKPWRSTAT_ETM,
.pd = {
+   .name = "domain_etm",
.power_off = s3c64xx_pd_off,
.power_on = s3c64xx_pd_on,
},
 };
 
 static struct s3c64xx_pm_domain s3c64xx_pm_s = {
-   .name = "S",
.ena = S3C64XX_NORMALCFG_DOMAIN_S_ON,
.pwr_stat = S3C64XX_BLKPWRSTAT_S,
.pd = {
+   .name = "domain_s",
.power_off = s3c64xx_pd_off,
.power_on = s3c64xx_pd_on,
},
 };
 
 static struct s3c64xx_pm_domain s3c64xx_pm_f = {
-   .name = "F",
.ena = S3C64XX_NORMALCFG_DOMAIN_F_ON,
.pwr_stat = S3C64XX_BLKPWRSTAT_F,
.pd = {
+   .name = "domain_f",
.power_off = s3c64xx_pd_off,
.power_on = s3c64xx_pd_on,
},
 };
 
 static struct s3c64xx_pm_domain s3c64xx_pm_p = {
-   .name = "P",
.ena = S3C64XX_NORMALCFG_DOMAIN_P_ON,
.pwr_stat = S3C64XX_BLKPWRSTAT_P,
.pd = {
+   .name = "domain_p",
.power_off = s3c64xx_pd_off,
.power_on = s3c64xx_pd_on,
},
 };
 
 static struct s3c64xx_pm_domain s3c64xx_pm_i = {
-   .name = "I",
.ena = S3C64XX_NORMALCFG_DOMAIN_I_ON,
.pwr_stat = S3C64XX_BLKPWRSTAT_I,
.pd = {
+   .name = "domain_i",
.power_off = s3c64xx_pd_off,
.power_on = s3c64xx_pd_on,
},
 };
 
 static struct s3c64xx_pm_domain s3c64xx_pm_g = {
-   .name = "G",
.ena = S3C64XX_NORMALCFG_DOMAIN_G_ON,
.pd = {
+   .name = "domain_g",
.power_off = s3c64xx_pd_off,
.power_on = s3c64xx_pd_on,
},
 };
 
 static struct s3c64xx_pm_domain s3c64xx_pm_v = {
-   .name = "V",
.ena = S3C64XX_NORMALCFG_DOMAIN_V_ON,
.pwr_stat = S3C64XX_BLKPWRSTAT_V,
.pd = {
+   .name = "domain_v",
.power_off = s3c64xx_pd_off,
.power_on = s3c64xx_pd_on,
},
-- 
1.8.5.2

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


[PATCH 7/9] perf, tools: Add overlap detection for report branch-call-stack mode

2014-01-11 Thread Andi Kleen
From: Andi Kleen 

Add a simple heuristic to detect overlap of LBR entries and the call
stack when in lbr-as-callgraph mode. The return address in the
normal callstack is one off compared to the from entry in the
branch stack. Handle this with a simple "assume call instruction
is not longer than 8 bytes" heuristic. With that we can remove
any redundant call in the callstack that is already in the branch
stack.

Signed-off-by: Andi Kleen 
---
 tools/perf/util/machine.c | 21 +++--
 1 file changed, 15 insertions(+), 6 deletions(-)

diff --git a/tools/perf/util/machine.c b/tools/perf/util/machine.c
index 853639c..1f167fe 100644
--- a/tools/perf/util/machine.c
+++ b/tools/perf/util/machine.c
@@ -1349,6 +1349,7 @@ static int machine__resolve_callchain_sample(struct 
machine *machine,
int chain_nr = min(max_stack, (int)chain->nr);
int i;
int err;
+   int first_call = 0;
 
callchain_cursor_reset(&callchain_cursor);
 
@@ -1362,8 +1363,6 @@ static int machine__resolve_callchain_sample(struct 
machine *machine,
 * Limitations for now:
 * - No extra filters
 * - No annotations (should annotate somehow)
-* - When the sample is near the beginning of the function
-*   we may overlap with the real callstack. 
 */
 
if (branch->nr > PERF_MAX_BRANCH_DEPTH) {
@@ -1372,13 +1371,23 @@ static int machine__resolve_callchain_sample(struct 
machine *machine,
}
 
if (callchain_param.branch_callstack) {
-   int nr = min(max_stack, branch->nr);
+   int nr = min(max_stack, (int)branch->nr);
struct branch_entry be[nr];
 
for (i = 0; i < nr; i++) { 
-   if (callchain_param.order == ORDER_CALLEE)
+   if (callchain_param.order == ORDER_CALLEE) {
be[i] = branch->entries[i];
-   else
+   /* 
+* Check for overlap into the callchain.
+* The return address is one off compared to
+* the branch entry. To adjust for this 
+* assume the calling instruction is not longer
+* than 8 bytes.
+*/
+   if (be[i].from < chain->ips[first_call] &&
+   be[i].from >= chain->ips[first_call] - 8)
+   first_call++;
+   } else
be[i] = branch->entries[branch->nr - i - 1];
}
 
@@ -1405,7 +1414,7 @@ static int machine__resolve_callchain_sample(struct 
machine *machine,
return 0;
}
 
-   for (i = 0; i < chain_nr; i++) {
+   for (i = first_call; i < chain_nr; i++) {
u64 ip;
 
if (callchain_param.order == ORDER_CALLEE)
-- 
1.8.3.1

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


[PATCH RFC 03/10] ARM: s3c64xx: pm: Add pwr_stat bit for domain G

2014-01-11 Thread Tomasz Figa
There is a status bit for domain G present in BLK_PWR_STAT register, but
it is currently not specified in the driver.

This patch adds the status bit of domain G to structure describing it.

Signed-off-by: Tomasz Figa 
---
 arch/arm/mach-s3c64xx/pm.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/arm/mach-s3c64xx/pm.c b/arch/arm/mach-s3c64xx/pm.c
index 605bfa9..717d9be 100644
--- a/arch/arm/mach-s3c64xx/pm.c
+++ b/arch/arm/mach-s3c64xx/pm.c
@@ -146,6 +146,7 @@ static struct s3c64xx_pm_domain s3c64xx_pm_i = {
 
 static struct s3c64xx_pm_domain s3c64xx_pm_g = {
.ena = S3C64XX_NORMALCFG_DOMAIN_G_ON,
+   .pwr_stat = S3C64XX_BLKPWRSTAT_G,
.pd = {
.name = "domain_g",
.power_off = s3c64xx_pd_off,
-- 
1.8.5.2

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


[PATCH RFC 04/10] base: power: Add generic OF-based power domain look-up

2014-01-11 Thread Tomasz Figa
This patch introduces generic code to perform power domain look-up using
device tree and automatically bind devices to their power domains.
Generic device tree binding is introduced to specify power domains of
devices in their device tree nodes.

Backwards compatibility with legacy Samsung-specific power domain
bindings is provided, but for now the new code is not compiled when
CONFIG_ARCH_EXYNOS is selected to avoid collision with legacy code. This
will change as soon as Exynos power domain code gets converted to use
the generic framework in further patch.

Signed-off-by: Tomasz Figa 
---
 .../devicetree/bindings/power/power_domain.txt |  51 
 drivers/base/power/domain.c| 339 +
 include/linux/pm_domain.h  |  34 +++
 kernel/power/Kconfig   |   4 +
 4 files changed, 428 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/power/power_domain.txt

diff --git a/Documentation/devicetree/bindings/power/power_domain.txt 
b/Documentation/devicetree/bindings/power/power_domain.txt
new file mode 100644
index 000..93be5d9
--- /dev/null
+++ b/Documentation/devicetree/bindings/power/power_domain.txt
@@ -0,0 +1,51 @@
+* Generic power domains
+
+System on chip designs are often divided into multiple power domains that
+can be used for power gating of selected IP blocks for power saving by
+reduced leakage current.
+
+This device tree binding can be used to bind power domain consumer devices
+with their power domains provided by power domain providers. A power domain
+provider can be represented by any node in the device tree and can provide
+one or more power domains. A consumer node can refer to the provider by
+a phandle and a set of phandle arguments (so called power domain specifier)
+of length specified by #power-domain-cells property in the power domain
+provider node.
+
+==Power domain providers==
+
+Required properties:
+ - #power-domain-cells : Number of cells in a power domain specifier;
+   Typically 0 for nodes representing a single power domain and 1 for nodes
+   providing multiple power domains (e.g. power controllers), but can be
+   any value as specified by device tree binding documentation of particular
+   provider.
+
+Example:
+
+   power: power-controller@1234 {
+   compatible = "foo,power-controller";
+   reg = <0x1234 0x1000>;
+   #power-domain-cells = <1>;
+   };
+
+The node above defines a power controller that is a power domain provider
+and expects one cell as its phandle argument.
+
+==Power domain consumers==
+
+Required properties:
+ - power-domain : A phandle and power domain specifier as defined by bindings
+  of power controller specified by phandle.
+
+Example:
+
+   leaky-device@1235 {
+   compatible = "foo,i-leak-current";
+   reg = <0x1235 0x1000>;
+   power-domain = <&power 0>;
+   };
+
+The node above defines a typical power domain consumer device, which is located
+inside power domain with index 0 of power controller represented by node with
+label "power".
diff --git a/drivers/base/power/domain.c b/drivers/base/power/domain.c
index bfb8955..6d47498 100644
--- a/drivers/base/power/domain.c
+++ b/drivers/base/power/domain.c
@@ -3,12 +3,16 @@
  *
  * Copyright (C) 2011 Rafael J. Wysocki , Renesas Electronics 
Corp.
  *
+ * Support for Device Tree based power domain providers:
+ * Copyright (C) 2014 Tomasz Figa 
+ *
  * This file is released under the GPLv2.
  */
 
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -2177,3 +2181,338 @@ void pm_genpd_init(struct generic_pm_domain *genpd,
list_add(&genpd->gpd_list_node, &gpd_list);
mutex_unlock(&gpd_list_lock);
 }
+
+#ifdef CONFIG_PM_GENERIC_DOMAINS_OF
+/*
+ * DEVICE TREE BASED POWER DOMAIN PROVIDERS
+ *
+ * The code below implements generic device tree based power domain providers
+ * that bind device tree nodes with generic power domains registered in the
+ * system.
+ *
+ * Any driver that registers generic power domains and need to support binding
+ * of devices to these domains is supposed to register a power domain provider,
+ * which maps a power domain specifier retrieved from device tree to a power
+ * domain.
+ *
+ * Two simple mapping functions have been provided for convenience:
+ *  - of_genpd_xlate_simple() for 1:1 device tree node to domain mapping,
+ *  - of_genpd_xlate_onecell() for mapping of multiple domains per node
+ *by index.
+ */
+
+/**
+ * struct of_genpd_provider - Power domain provider registration structure
+ * @link: Entry in global list of domain providers
+ * @node: Pointer to device tree node of domain provider
+ * @xlate: Provider-specific xlate callback mapping a set of specifier cells
+ * into a power domain.
+ * @data: context pointer to be passed into @xlate callback
+ */
+struct of_genpd_provider {
+

[PATCH RFC 02/10] ARM: s3c64xx: pm: Add always_on field to s3c64xx_pm_domain struct

2014-01-11 Thread Tomasz Figa
This patch adds always_on field to s3c64xx_pm_domain struct to allow
handling registration of all domains in the same way, without the need
to have separate arrays for normal and always on domains.

Signed-off-by: Tomasz Figa 
---
 arch/arm/mach-s3c64xx/pm.c | 21 -
 1 file changed, 12 insertions(+), 9 deletions(-)

diff --git a/arch/arm/mach-s3c64xx/pm.c b/arch/arm/mach-s3c64xx/pm.c
index 5238d66..605bfa9 100644
--- a/arch/arm/mach-s3c64xx/pm.c
+++ b/arch/arm/mach-s3c64xx/pm.c
@@ -35,6 +35,7 @@
 #include "regs-syscon-power.h"
 
 struct s3c64xx_pm_domain {
+   bool always_on;
u32 ena;
u32 pwr_stat;
struct generic_pm_domain pd;
@@ -84,6 +85,7 @@ static int s3c64xx_pd_on(struct generic_pm_domain *domain)
 }
 
 static struct s3c64xx_pm_domain s3c64xx_pm_irom = {
+   .always_on = true,
.ena = S3C64XX_NORMALCFG_IROM_ON,
.pd = {
.name = "domain_irom",
@@ -161,11 +163,8 @@ static struct s3c64xx_pm_domain s3c64xx_pm_v = {
},
 };
 
-static struct s3c64xx_pm_domain *s3c64xx_always_on_pm_domains[] = {
-   &s3c64xx_pm_irom,
-};
-
 static struct s3c64xx_pm_domain *s3c64xx_pm_domains[] = {
+   &s3c64xx_pm_irom,
&s3c64xx_pm_etm,
&s3c64xx_pm_g,
&s3c64xx_pm_v,
@@ -311,12 +310,16 @@ int __init s3c64xx_pm_init(void)
 
s3c_pm_init();
 
-   for (i = 0; i < ARRAY_SIZE(s3c64xx_always_on_pm_domains); i++)
-   pm_genpd_init(&s3c64xx_always_on_pm_domains[i]->pd,
- &pm_domain_always_on_gov, false);
 
-   for (i = 0; i < ARRAY_SIZE(s3c64xx_pm_domains); i++)
-   pm_genpd_init(&s3c64xx_pm_domains[i]->pd, NULL, false);
+   for (i = 0; i < ARRAY_SIZE(s3c64xx_pm_domains); i++) {
+   struct s3c64xx_pm_domain *pd = s3c64xx_pm_domains[i];
+   struct dev_power_governor *gov = NULL;
+
+   if (pd->always_on)
+   gov = &pm_domain_always_on_gov;
+
+   pm_genpd_init(&pd->pd, gov, false);
+   }
 
 #ifdef CONFIG_S3C_DEV_FB
if (dev_get_platdata(&s3c_device_fb.dev))
-- 
1.8.5.2

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


[PATCH RFC 05/10] ARM: exynos: Move to generic power domain bindings

2014-01-11 Thread Tomasz Figa
This patch moves Exynos power domain code to use the new generic power
domain look-up framework introduced by previous patch, allowing the new
code to be compiled with CONFIG_ARCH_EXYNOS selected as well.

Signed-off-by: Tomasz Figa 
---
 .../bindings/arm/exynos/power_domain.txt   | 12 ++--
 arch/arm/mach-exynos/pm_domains.c  | 80 +-
 kernel/power/Kconfig   |  2 +-
 3 files changed, 7 insertions(+), 87 deletions(-)

diff --git a/Documentation/devicetree/bindings/arm/exynos/power_domain.txt 
b/Documentation/devicetree/bindings/arm/exynos/power_domain.txt
index 5216b41..60f26a8 100644
--- a/Documentation/devicetree/bindings/arm/exynos/power_domain.txt
+++ b/Documentation/devicetree/bindings/arm/exynos/power_domain.txt
@@ -8,6 +8,8 @@ Required Properties:
 * samsung,exynos4210-pd - for exynos4210 type power domain.
 - reg: physical base address of the controller and length of memory mapped
 region.
+- #power-domain-cells: number of cells in power domain specifier;
+must be 0.
 
 Node of a device using power domains must have a samsung,power-domain property
 defined with a phandle to respective power domain.
@@ -17,12 +19,8 @@ Example:
lcd0: power-domain-lcd0 {
compatible = "samsung,exynos4210-pd";
reg = <0x10023C00 0x10>;
+   #power-domain-cells = <0>;
};
 
-Example of the node using power domain:
-
-   node {
-   /* ... */
-   samsung,power-domain = <&lcd0>;
-   /* ... */
-   };
+See Documentation/devicetree/bindings/power/power_domain.txt for description
+of consumer-side bindings.
diff --git a/arch/arm/mach-exynos/pm_domains.c 
b/arch/arm/mach-exynos/pm_domains.c
index 1703593..eba90a1 100644
--- a/arch/arm/mach-exynos/pm_domains.c
+++ b/arch/arm/mach-exynos/pm_domains.c
@@ -74,78 +74,6 @@ static int exynos_pd_power_off(struct generic_pm_domain 
*domain)
return exynos_pd_power(domain, false);
 }
 
-static void exynos_add_device_to_domain(struct exynos_pm_domain *pd,
-struct device *dev)
-{
-   int ret;
-
-   dev_dbg(dev, "adding to power domain %s\n", pd->pd.name);
-
-   while (1) {
-   ret = pm_genpd_add_device(&pd->pd, dev);
-   if (ret != -EAGAIN)
-   break;
-   cond_resched();
-   }
-
-   pm_genpd_dev_need_restore(dev, true);
-}
-
-static void exynos_remove_device_from_domain(struct device *dev)
-{
-   struct generic_pm_domain *genpd = dev_to_genpd(dev);
-   int ret;
-
-   dev_dbg(dev, "removing from power domain %s\n", genpd->name);
-
-   while (1) {
-   ret = pm_genpd_remove_device(genpd, dev);
-   if (ret != -EAGAIN)
-   break;
-   cond_resched();
-   }
-}
-
-static void exynos_read_domain_from_dt(struct device *dev)
-{
-   struct platform_device *pd_pdev;
-   struct exynos_pm_domain *pd;
-   struct device_node *node;
-
-   node = of_parse_phandle(dev->of_node, "samsung,power-domain", 0);
-   if (!node)
-   return;
-   pd_pdev = of_find_device_by_node(node);
-   if (!pd_pdev)
-   return;
-   pd = platform_get_drvdata(pd_pdev);
-   exynos_add_device_to_domain(pd, dev);
-}
-
-static int exynos_pm_notifier_call(struct notifier_block *nb,
-   unsigned long event, void *data)
-{
-   struct device *dev = data;
-
-   switch (event) {
-   case BUS_NOTIFY_BIND_DRIVER:
-   if (dev->of_node)
-   exynos_read_domain_from_dt(dev);
-
-   break;
-
-   case BUS_NOTIFY_UNBOUND_DRIVER:
-   exynos_remove_device_from_domain(dev);
-
-   break;
-   }
-   return NOTIFY_DONE;
-}
-
-static struct notifier_block platform_nb = {
-   .notifier_call = exynos_pm_notifier_call,
-};
-
 static __init int exynos4_pm_init_power_domain(void)
 {
struct platform_device *pdev;
@@ -155,8 +83,6 @@ static __init int exynos4_pm_init_power_domain(void)
struct exynos_pm_domain *pd;
int on;
 
-   pdev = of_find_device_by_node(np);
-
pd = kzalloc(sizeof(*pd), GFP_KERNEL);
if (!pd) {
pr_err("%s: failed to allocate memory for domain\n",
@@ -169,17 +95,13 @@ static __init int exynos4_pm_init_power_domain(void)
pd->base = of_iomap(np, 0);
pd->pd.power_off = exynos_pd_power_off;
pd->pd.power_on = exynos_pd_power_on;
-   pd->pd.of_node = np;
-
-   platform_set_drvdata(pdev, pd);
 
on = __raw_readl(pd->base + 0x4) & S5P_INT_LOCAL_PWR_EN;
 
pm_genpd_init(&pd->pd, NULL, !on);
+   of_genpd_add_provider(np, of_genpd_xlate_simple, &pd->pd);
}
 
-   bus_register_

[PATCH RFC 09/10] ARM: dts: s3c64xx: Add node for display controller

2014-01-11 Thread Tomasz Figa
This patch adds device tree node for the display controller present on
S3C64xx SoCs.

Signed-off-by: Tomasz Figa 
---
 arch/arm/boot/dts/s3c64xx.dtsi | 13 +
 1 file changed, 13 insertions(+)

diff --git a/arch/arm/boot/dts/s3c64xx.dtsi b/arch/arm/boot/dts/s3c64xx.dtsi
index 4e3be4d..6fe1042 100644
--- a/arch/arm/boot/dts/s3c64xx.dtsi
+++ b/arch/arm/boot/dts/s3c64xx.dtsi
@@ -18,6 +18,7 @@
 
 #include "skeleton.dtsi"
 #include 
+#include 
 
 / {
aliases {
@@ -56,6 +57,18 @@
#interrupt-cells = <1>;
};
 
+   fimd: display@7710 {
+   compatible = "samsung,s3c6400-fimd";
+   reg = <0x7710 0x1000>;
+   interrupt-parent = <&vic0>;
+   interrupts = <29>, <30>, <31>;
+   interrupt-names = "fifo", "vsync", "lcd_sys";
+   clocks = <&clocks HCLK_LCD>, <&clocks SCLK_LCD>;
+   clock-names = "fimd", "sclk_fimd";
+   power-domain = <&clocks DOMAIN_F>;
+   status = "disabled";
+   };
+
sdhci0: sdhci@7c20 {
compatible = "samsung,s3c6410-sdhci";
reg = <0x7c20 0x100>;
-- 
1.8.5.2

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


[PATCH RFC 06/10] ARM: s3c64xx: pm: Add device tree based power domain instantiation

2014-01-11 Thread Tomasz Figa
This patch adds support for registering power domains of S3C64xx SoCs
and binding devices to them using device tree.

Signed-off-by: Tomasz Figa 
---
 arch/arm/mach-s3c64xx/pm.c  | 71 +
 include/dt-bindings/arm/s3c64xx-power-domains.h | 26 +
 2 files changed, 88 insertions(+), 9 deletions(-)
 create mode 100644 include/dt-bindings/arm/s3c64xx-power-domains.h

diff --git a/arch/arm/mach-s3c64xx/pm.c b/arch/arm/mach-s3c64xx/pm.c
index 717d9be..673baaf 100644
--- a/arch/arm/mach-s3c64xx/pm.c
+++ b/arch/arm/mach-s3c64xx/pm.c
@@ -17,8 +17,11 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 
+#include 
+
 #include 
 #include 
 
@@ -164,17 +167,63 @@ static struct s3c64xx_pm_domain s3c64xx_pm_v = {
},
 };
 
-static struct s3c64xx_pm_domain *s3c64xx_pm_domains[] = {
-   &s3c64xx_pm_irom,
-   &s3c64xx_pm_etm,
-   &s3c64xx_pm_g,
-   &s3c64xx_pm_v,
-   &s3c64xx_pm_i,
-   &s3c64xx_pm_p,
-   &s3c64xx_pm_s,
-   &s3c64xx_pm_f,
+static struct s3c64xx_pm_domain *s3c64xx_pm_domains[NR_DOMAINS] = {
+   [DOMAIN_V] = &s3c64xx_pm_v,
+   [DOMAIN_G] = &s3c64xx_pm_g,
+   [DOMAIN_I] = &s3c64xx_pm_i,
+   [DOMAIN_P] = &s3c64xx_pm_p,
+   [DOMAIN_F] = &s3c64xx_pm_f,
+   [DOMAIN_S] = &s3c64xx_pm_s,
+   [DOMAIN_ETM] = &s3c64xx_pm_etm,
+   [DOMAIN_IROM] = &s3c64xx_pm_irom,
+};
+
+#ifdef CONFIG_OF
+static struct of_device_id s3c64xx_pd_matches[] = {
+   { .compatible = "samsung,s3c6400-clock", },
+   { .compatible = "samsung,s3c6410-clock", },
+   { },
 };
 
+static struct genpd_onecell_data pd_data;
+
+static int s3c64xx_pm_parse_domains(void)
+{
+   struct device_node *np;
+   int i;
+
+   np = of_find_matching_node(NULL, s3c64xx_pd_matches);
+   if (!np)
+   return -ENODEV;
+
+   pd_data.domains = kcalloc(ARRAY_SIZE(s3c64xx_pm_domains),
+ sizeof(*pd_data.domains), GFP_KERNEL);
+   if (!pd_data.domains)
+   return -ENOMEM;
+
+   for (i = 0; i < ARRAY_SIZE(s3c64xx_pm_domains); ++i) {
+   struct s3c64xx_pm_domain *pd = s3c64xx_pm_domains[i];
+   struct dev_power_governor *gov = NULL;
+   int on;
+
+   on = __raw_readl(S3C64XX_NORMAL_CFG) & pd->ena;
+
+   if (pd->always_on)
+   gov = &pm_domain_always_on_gov;
+
+   pm_genpd_init(&pd->pd, gov, !on);
+   pd_data.domains[i] = &pd->pd;
+
+   pr_debug("%s: registered domain %s\n", __func__, pd->pd.name);
+   }
+
+   pd_data.domain_num = ARRAY_SIZE(s3c64xx_pm_domains);
+   of_genpd_add_provider(np, of_genpd_xlate_onecell, &pd_data);
+
+   return 0;
+}
+#endif
+
 #ifdef CONFIG_S3C_PM_DEBUG_LED_SMDK
 void s3c_pm_debug_smdkled(u32 set, u32 clear)
 {
@@ -311,6 +360,10 @@ int __init s3c64xx_pm_init(void)
 
s3c_pm_init();
 
+#ifdef CONFIG_OF
+   if (of_have_populated_dt())
+   return s3c64xx_pm_parse_domains();
+#endif
 
for (i = 0; i < ARRAY_SIZE(s3c64xx_pm_domains); i++) {
struct s3c64xx_pm_domain *pd = s3c64xx_pm_domains[i];
diff --git a/include/dt-bindings/arm/s3c64xx-power-domains.h 
b/include/dt-bindings/arm/s3c64xx-power-domains.h
new file mode 100644
index 000..ce39bef
--- /dev/null
+++ b/include/dt-bindings/arm/s3c64xx-power-domains.h
@@ -0,0 +1,26 @@
+/*
+ * Copyright (c) 2014 Tomasz Figa 
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ *
+ * Device Tree binding constants for Samsung S3C64xx power domains.
+*/
+
+#ifndef _DT_BINDINGS_ARM_S3C64XX_POWER_DOMAINS_H
+#define _DT_BINDINGS_ARM_S3C64XX_POWER_DOMAINS_H
+
+#define DOMAIN_V   0
+#define DOMAIN_G   1
+#define DOMAIN_I   2
+#define DOMAIN_P   3
+#define DOMAIN_F   4
+#define DOMAIN_S   5
+#define DOMAIN_ETM 6
+#define DOMAIN_IROM7
+
+/* Total number of clocks. */
+#define NR_DOMAINS (DOMAIN_IROM + 1)
+
+#endif /* _DT_BINDINGS_ARM_S3C64XX_POWER_DOMAINS_H */
-- 
1.8.5.2

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


[PATCH 1/9] perf, tools: fix BFD detection on opensuse

2014-01-11 Thread Andi Kleen
From: Andi Kleen 

opensuse libbfd requires -lz -liberty to build. Add those
to the BFD feature detection.

Signed-off-by: Andi Kleen 
---
 tools/perf/config/Makefile| 2 +-
 tools/perf/config/feature-checks/Makefile | 2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/tools/perf/config/Makefile b/tools/perf/config/Makefile
index 01dd43d..d86d33c 100644
--- a/tools/perf/config/Makefile
+++ b/tools/perf/config/Makefile
@@ -478,7 +478,7 @@ else
 endif
 
 ifeq ($(feature-libbfd), 1)
-  EXTLIBS += -lbfd
+  EXTLIBS += -lbfd -lz -liberty
 endif
 
 ifdef NO_DEMANGLE
diff --git a/tools/perf/config/feature-checks/Makefile 
b/tools/perf/config/feature-checks/Makefile
index 7cf6fcd..a430e4f 100644
--- a/tools/perf/config/feature-checks/Makefile
+++ b/tools/perf/config/feature-checks/Makefile
@@ -120,7 +120,7 @@ test-libpython-version.bin:
$(BUILD) $(FLAGS_PYTHON_EMBED)
 
 test-libbfd.bin:
-   $(BUILD) -DPACKAGE='"perf"' -lbfd -ldl
+   $(BUILD) -DPACKAGE='"perf"' -lbfd -lz -liberty -ldl
 
 test-liberty.bin:
$(CC) -o $(OUTPUT)$@ test-libbfd.c -DPACKAGE='"perf"' -lbfd -ldl 
-liberty
-- 
1.8.3.1

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


[PATCH RFC 08/10] ARM: dts: s3c64xx: Add nodes for power domains

2014-01-11 Thread Tomasz Figa
This patch adds device tree nodes for power domains available on S3C64xx
SoCs.

Signed-off-by: Tomasz Figa 
---
 arch/arm/boot/dts/s3c6400.dtsi | 1 +
 arch/arm/boot/dts/s3c6410.dtsi | 1 +
 2 files changed, 2 insertions(+)

diff --git a/arch/arm/boot/dts/s3c6400.dtsi b/arch/arm/boot/dts/s3c6400.dtsi
index a7d1c8e..c1abdaf 100644
--- a/arch/arm/boot/dts/s3c6400.dtsi
+++ b/arch/arm/boot/dts/s3c6400.dtsi
@@ -37,5 +37,6 @@
compatible = "samsung,s3c6400-clock";
reg = <0x7e00f000 0x1000>;
#clock-cells = <1>;
+   #power-domain-cells = <1>;
};
 };
diff --git a/arch/arm/boot/dts/s3c6410.dtsi b/arch/arm/boot/dts/s3c6410.dtsi
index eb4226b..7e48c86 100644
--- a/arch/arm/boot/dts/s3c6410.dtsi
+++ b/arch/arm/boot/dts/s3c6410.dtsi
@@ -41,6 +41,7 @@
compatible = "samsung,s3c6410-clock";
reg = <0x7e00f000 0x1000>;
#clock-cells = <1>;
+   #power-domain-cells = <1>;
};
 
i2c1: i2c@7f00f000 {
-- 
1.8.5.2

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


[PATCH RFC 07/10] ARM: s3c64xx: dt: Enable SoC-level power management

2014-01-11 Thread Tomasz Figa
This patch adds call to s3c64xx_pm_init() from init_machine() callback
of mach-s3c64xx-dt to enable SoC-level power management features, such
as power domain management and sleep support.

Signed-off-by: Tomasz Figa 
---
 arch/arm/mach-s3c64xx/mach-s3c64xx-dt.c | 8 
 1 file changed, 8 insertions(+)

diff --git a/arch/arm/mach-s3c64xx/mach-s3c64xx-dt.c 
b/arch/arm/mach-s3c64xx/mach-s3c64xx-dt.c
index 2fddf38..45a4ddc 100644
--- a/arch/arm/mach-s3c64xx/mach-s3c64xx-dt.c
+++ b/arch/arm/mach-s3c64xx/mach-s3c64xx-dt.c
@@ -15,6 +15,7 @@
 #include 
 
 #include 
+#include 
 #include 
 
 #include 
@@ -49,9 +50,15 @@ static void __init s3c64xx_dt_map_io(void)
 static void __init s3c64xx_dt_init_machine(void)
 {
samsung_wdt_reset_of_init();
+   s3c64xx_pm_init();
of_platform_populate(NULL, of_default_bus_match_table, NULL, NULL);
 }
 
+static void __init s3c64xx_dt_init_late(void)
+{
+   s3c64xx_pm_late_initcall();
+}
+
 static void s3c64xx_dt_restart(enum reboot_mode mode, const char *cmd)
 {
if (mode != REBOOT_SOFT)
@@ -72,5 +79,6 @@ DT_MACHINE_START(S3C6400_DT, "Samsung S3C64xx (Flattened 
Device Tree)")
.dt_compat  = s3c64xx_dt_compat,
.map_io = s3c64xx_dt_map_io,
.init_machine   = s3c64xx_dt_init_machine,
+   .init_late  = s3c64xx_dt_init_late,
.restart= s3c64xx_dt_restart,
 MACHINE_END
-- 
1.8.5.2

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


[PATCH RFC 10/10] ARM: dts: s3c6410-mini6410: Add support for LCD screen

2014-01-11 Thread Tomasz Figa
This patch adds necessary device tree nodes and properties to enable LCD
screen on mini6410 board.

Signed-off-by: Tomasz Figa 
---
 arch/arm/boot/dts/s3c6410-mini6410.dts | 33 +
 1 file changed, 33 insertions(+)

diff --git a/arch/arm/boot/dts/s3c6410-mini6410.dts 
b/arch/arm/boot/dts/s3c6410-mini6410.dts
index 57e00f9..97f6353 100644
--- a/arch/arm/boot/dts/s3c6410-mini6410.dts
+++ b/arch/arm/boot/dts/s3c6410-mini6410.dts
@@ -167,6 +167,33 @@
};
 };
 
+&fimd {
+   status = "okay";
+   pinctrl-names = "default";
+   pinctrl-0 = <&lcd_data24>, <&lcd_power>;
+
+   display-timings {
+   native-mode = <&timing0>;
+
+   timing0: timing@0 {
+   /* 480x272@60Hz */
+   clock-frequency = <1000>;
+   hactive = <480>;
+   vactive = <272>;
+   hfront-porch = <4>;
+   hback-porch = <45>;
+   hsync-len = <40>;
+   vback-porch = <3>;
+   vfront-porch = <2>;
+   vsync-len = <6>;
+   vsync-active = <1>;
+   hsync-active = <1>;
+   de-active = <1>;
+   pixelclk-active = <0>;
+   };
+   };
+};
+
 &sdhci0 {
pinctrl-names = "default";
pinctrl-0 = <&sd0_clk>, <&sd0_cmd>, <&sd0_cd>, <&sd0_bus4>;
@@ -213,6 +240,12 @@
"gpn-4", "gpn-5", "gpl-11", "gpl-12";
samsung,pin-pud = ;
};
+
+   lcd_power: lcd-power {
+   samsung,pins = "gpe-0";
+   samsung,pin-function = <0>;
+   samsung,pin-pud = ;
+   };
 };
 
 &i2c0 {
-- 
1.8.5.2

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


[PATCH 6/9] perf, tools: Fix max stack handling with lbr-as-callgraph

2014-01-11 Thread Andi Kleen
From: Andi Kleen 

The original lbr-as-callstack code ignored the maxium callgraph
length set by the user. Fix this.

Signed-off-by: Andi Kleen 
---
 tools/perf/util/machine.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/tools/perf/util/machine.c b/tools/perf/util/machine.c
index 4032634..853639c 100644
--- a/tools/perf/util/machine.c
+++ b/tools/perf/util/machine.c
@@ -1372,7 +1372,7 @@ static int machine__resolve_callchain_sample(struct 
machine *machine,
}
 
if (callchain_param.branch_callstack) {
-   int nr = branch->nr;
+   int nr = min(max_stack, branch->nr);
struct branch_entry be[nr];
 
for (i = 0; i < nr; i++) { 
@@ -1397,6 +1397,7 @@ static int machine__resolve_callchain_sample(struct 
machine *machine,
if (err)
return err;
}
+   chain_nr -= nr;
}
 
if (chain->nr > PERF_MAX_STACK_DEPTH) {
-- 
1.8.3.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/


perf: Implement lbr-as-callgraph v2

2014-01-11 Thread Andi Kleen
This patchkit implements lbr-as-callgraphs in per freport,
as an alternative way to present LBR information.

Current perf report does a histogram over the branch edges,
which is useful to look at basic blocks, but doesn't tell
you anything about the larger control flow.

This patchkit adds a new option --branch-history that
adds the branch paths to the callgraph history instead.

This allows to reason about individual branch paths leading
to specific samples.

Updates to v1:
- rebased on perf/core
- fix various issues
- rename the option to --branch-history
- various fixes to display the information more concise

Example output:

% perf record -b -g ./tsrc/tcall
[ perf record: Woken up 1 times to write data ]
[ perf record: Captured and wrote 0.044 MB perf.data (~1923 samples) ]
% perf report --branch-history
...
54.91%  tcall.c:6  [.] f2  tcall
|
|--66.53%-- f2 tcall.c:5
|  |
|  |--70.83%-- f1 tcall.c:11
|  |  f1 tcall.c:10
|  |  main tcall.c:18
|  |  main tcall.c:18
|  |  main tcall.c:17
|  |  main tcall.c:17
|  |  f1 tcall.c:13
|  |  f1 tcall.c:13
|  |  f2 tcall.c:7
|  |  f2 tcall.c:5
|  |  f1 tcall.c:12
|  |  f1 tcall.c:12
|  |  f2 tcall.c:7
|  |  f2 tcall.c:5
|  |  f1 tcall.c:11

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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/9] perf, tools: Filter out small loops from LBR-as-call-stack

2014-01-11 Thread Andi Kleen
From: Andi Kleen 

Small loops can cause unnecessary duplication in the LBR-as-callstack,
because the loop body appears multiple times. Filter out duplications
from the LBR before unifying it into the histories.  This way the
same loop body only appears once.

This uses a simple hash based cycle detector. It takes some short
cuts (not handling hash collisions) so in rare cases duplicates may
be missed.

Signed-off-by: Andi Kleen 
---
 tools/perf/util/machine.c | 73 ---
 1 file changed, 62 insertions(+), 11 deletions(-)

diff --git a/tools/perf/util/machine.c b/tools/perf/util/machine.c
index f2eaf85..2f440f2 100644
--- a/tools/perf/util/machine.c
+++ b/tools/perf/util/machine.c
@@ -11,6 +11,7 @@
 #include 
 #include 
 #include "unwind.h"
+#include "linux/hash.h"
 
 int machine__init(struct machine *machine, const char *root_dir, pid_t pid)
 {
@@ -1296,6 +1297,46 @@ static int add_callchain_ip(struct machine *machine,
return callchain_cursor_append(&callchain_cursor, ip, al.map, al.sym);
 }
 
+#define CHASHSZ 127
+#define CHASHBITS 7
+#define NO_ENTRY 0xff
+
+#define PERF_MAX_BRANCH_DEPTH 127
+
+/* Remove loops. */
+static int remove_loops(struct branch_entry *l, int nr)
+{
+   int i, j, off;
+   unsigned char chash[CHASHSZ];
+   memset(chash, -1, sizeof(chash));
+
+   BUG_ON(nr >= 256);
+   for (i = 0; i < nr; i++) {
+   int h = hash_64(l[i].from, CHASHBITS) % CHASHSZ;
+
+   /* no collision handling for now */
+   if (chash[h] == NO_ENTRY) {
+   chash[h] = i;
+   } else if (l[chash[h]].from == l[i].from) {
+   bool is_loop = true;
+   /* check if it is a real loop */
+   off = 0;
+   for (j = chash[h]; j < i && i + off < nr; j++, off++)
+   if (l[j].from != l[i + off].from) {
+   is_loop = false;
+   break;
+   }
+   if (is_loop) {
+   memmove(l + i, l + i + off, 
+   (nr - (i + off))
+   * sizeof(struct branch_entry));
+   nr -= off;
+   }
+   }
+   }
+   return nr;
+}
+
 static int machine__resolve_callchain_sample(struct machine *machine,
 struct thread *thread,
 struct ip_callchain *chain,
@@ -1322,29 +1363,39 @@ static int machine__resolve_callchain_sample(struct 
machine *machine,
 * - No extra filters
 * - No annotations (should annotate somehow)
 * - When the sample is near the beginning of the function
-*   we may overlap with the real callstack. Could handle this
-*   case later, by checking against the last ip.
+*   we may overlap with the real callstack. 
 */
 
+   if (branch->nr > PERF_MAX_BRANCH_DEPTH) {
+   pr_warning("corrupted branch chain. skipping...\n");
+   return 0;
+   }
+
if (callchain_param.branch_callstack) {
-   for (i = 0; i < branch->nr; i++) { 
-   struct branch_entry *b; 
+   int nr = branch->nr;
+   struct branch_entry be[nr];
 
+   for (i = 0; i < nr; i++) { 
if (callchain_param.order == ORDER_CALLEE)
-   b = &branch->entries[i];
+   be[i] = branch->entries[i];
else
-   b = &branch->entries[branch->nr - i - 1];
+   be[i] = branch->entries[branch->nr - i - 1];
+   }
 
-   err = add_callchain_ip(machine, thread, parent, root_al,
-  -1, b->to);
+   nr = remove_loops(be, nr);
+
+   for (i = 0; i < nr; i++) {
+   err = add_callchain_ip(machine, thread, parent, 
+  root_al,
+  -1, be[i].to);
if (!err)
-   err = add_callchain_ip(machine, thread, parent, 
root_al,
-  -1, b->from);
+   err = add_callchain_ip(machine, thread, 
+  parent, root_al,
+  -1, be[i].from);
if (err == -EINVAL)
break;
if (err)
return err;
-
}
}
 
-- 
1.8.3.1

--
To unsubscribe from this list: send the line "unsubscribe

Re: sysfs warnings since kernel 3.13-rc1: "WARNING: ... at fs/sysfs/group.c:214 sysfs_remove_group"

2014-01-11 Thread Frank Schäfer
Am 08.01.2014 21:32, schrieb Mauro Carvalho Chehab:
> With the patches that split em28xx-v4l from the main em28xx, this logic
> changed, as em28xx_release_analog_resources() now have another name and
> don't free em28xx dev anymore.
>
> Could you please test again after that patches?
Yes, I've tested it and the warnings are still there.
However, I just started to rework the whole em28xx resources releasing
logic and I think I know how to fix these warnings.

Regards,
Frank

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] Staging: lustre: Use of fls to find last set bit

2014-01-11 Thread Monam Agarwal
This introduces fls in lustre/ldlm/ldlm_extent.c 
to find the last set bit. 

It also fixes the following checkpatch.pl warning in
lustre/ldlm/ldlm_extent.c
WARNING: space prohibited before semicolon.

The patch also fixes the following checkpatch.pl error in
lustre/ldlm/ldlm_extent.c
ERROR: trailing statements should be on next line


Signed-off-by: Monam Agarwal 
---
Changes since v1:
*Incorrect commit message
*Use of fls function

 drivers/staging/lustre/lustre/ldlm/ldlm_extent.c |4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/drivers/staging/lustre/lustre/ldlm/ldlm_extent.c 
b/drivers/staging/lustre/lustre/ldlm/ldlm_extent.c
index ac5d66a..e6fe2cb 100644
--- a/drivers/staging/lustre/lustre/ldlm/ldlm_extent.c
+++ b/drivers/staging/lustre/lustre/ldlm/ldlm_extent.c
@@ -150,10 +150,12 @@ struct ldlm_interval *ldlm_interval_detach(struct 
ldlm_lock *l)
 static inline int lock_mode_to_index(ldlm_mode_t mode)
 {
int index;
+   int len;
 
LASSERT(mode != 0);
LASSERT(IS_PO2(mode));
-   for (index = -1; mode; index++, mode >>= 1) ;
+   len = fls(mode);
+   index = len-1;
LASSERT(index < LCK_MODE_NUM);
return index;
 }
-- 
1.7.9.5

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


Re: [RFC PATCH] mm: thp: Add per-mm_struct flag to control THP

2014-01-11 Thread Alex Thorlton
On Sat, Jan 11, 2014 at 04:53:37PM +0100, Oleg Nesterov wrote:
> On 01/10, Alex Thorlton wrote:
> >
> > This patch adds an mm flag (MMF_THP_DISABLE) to disable transparent
> > hugepages using prctl.  It is based on my original patch to add a
> > per-task_struct flag to disable THP:
> 
> I leave the "whether we need this feature" to other reviewers, although
> personally I think it probably makes sense anyway.
> 
> But the patch doesn't look nice imho.
> 
> > @@ -373,7 +373,15 @@ extern int get_dumpable(struct mm_struct *mm);
> >  #define MMF_HAS_UPROBES19  /* has uprobes */
> >  #define MMF_RECALC_UPROBES 20  /* MMF_HAS_UPROBES can be wrong */
> >  
> > +#ifdef CONFIG_TRANSPARENT_HUGEPAGE
> > +#define MMF_THP_DISABLE21  /* disable THP for this mm */
> > +#define MMF_THP_DISABLE_MASK   (1 << MMF_THP_DISABLE)
> > +
> > +#define MMF_INIT_MASK  (MMF_DUMPABLE_MASK | 
> > MMF_DUMP_FILTER_MASK | MMF_THP_DISABLE_MASK)
> > +#else
> >  #define MMF_INIT_MASK  (MMF_DUMPABLE_MASK | 
> > MMF_DUMP_FILTER_MASK)
> > +#endif
> 
> It would be nice to lessen the number of ifdef's. Why we can't define
> MMF_THP_DISABLE unconditionally and include it into MMF_INIT_MASK?
> Or define it == 0 if !CONFIG_THP. But this is minor.

That's a good idea.  I guess I was thinking that we don't want to define
any THP specific stuff when THP isn't configured, but I guess it doesn't
make much of a difference since the flag will never be set if THP isn't
configured.

> > +#define PR_SET_THP_DISABLE 41
> > +#define PR_CLEAR_THP_DISABLE   42
> > +#define PR_GET_THP_DISABLE 43
> 
> Why we can't add 2 PR_'s, set and get?

See response below.

> > --- a/kernel/fork.c
> > +++ b/kernel/fork.c
> > @@ -818,6 +818,7 @@ struct mm_struct *dup_mm(struct task_struct *tsk)
> >  #if defined(CONFIG_TRANSPARENT_HUGEPAGE) && !USE_SPLIT_PMD_PTLOCKS
> > mm->pmd_huge_pte = NULL;
> >  #endif
> > +
> > if (!mm_init(mm, tsk))
> > goto fail_nomem;
> 
> Why? looks like the accidental change.

Ah, yes.  Didn't catch that when I looked over the patch.  I'll fix
that.

> 
> > --- a/kernel/sys.c
> > +++ b/kernel/sys.c
> > @@ -1835,6 +1835,42 @@ static int prctl_get_tid_address(struct task_struct 
> > *me, int __user **tid_addr)
> >  }
> >  #endif
> >  
> > +#ifdef CONFIG_TRANSPARENT_HUGEPAGE
> > +static int prctl_set_thp_disable(struct task_struct *me)
> > +{
> > +   set_bit(MMF_THP_DISABLE, &me->mm->flags);
> > +   return 0;
> > +}
> > +
> > +static int prctl_clear_thp_disable(struct task_struct *me)
> > +{
> > +   clear_bit(MMF_THP_DISABLE, &me->mm->flags);
> > +   return 0;
> > +}
> > +
> > +static int prctl_get_thp_disable(struct task_struct *me,
> > + int __user *thp_disabled)
> > +{
> > +   return put_user(test_bit(MMF_THP_DISABLE, &me->mm->flags), 
> > thp_disabled);
> > +}
> > +#else
> > +static int prctl_set_thp_disable(struct task_struct *me)
> > +{
> > +   return -EINVAL;
> > +}
> > +
> > +static int prctl_clear_thp_disable(struct task_struct *me)
> > +{
> > +   return -EINVAL;
> > +}
> > +
> > +static int prctl_get_thp_disable(struct task_struct *me,
> > + int __user *thp_disabled)
> > +{
> > +   return -EINVAL;
> > +}
> > +#endif
> > +
> >  SYSCALL_DEFINE5(prctl, int, option, unsigned long, arg2, unsigned long, 
> > arg3,
> > unsigned long, arg4, unsigned long, arg5)
> >  {
> > @@ -1998,6 +2034,15 @@ SYSCALL_DEFINE5(prctl, int, option, unsigned long, 
> > arg2, unsigned long, arg3,
> > if (arg2 || arg3 || arg4 || arg5)
> > return -EINVAL;
> > return current->no_new_privs ? 1 : 0;
> > +   case PR_SET_THP_DISABLE:
> > +   error = prctl_set_thp_disable(me);
> > +   break;
> > +   case PR_CLEAR_THP_DISABLE:
> > +   error = prctl_clear_thp_disable(me);
> > +   break;
> > +   case PR_GET_THP_DISABLE:
> > +   error = prctl_get_thp_disable(me, (int __user *) arg2);
> > +   break;
> > default:
> > error = -EINVAL;
> > break;
> 
> I simply can't understand, this all looks like overkill. Can't you simply add
> 
>   #idfef CONFIG_TRANSPARENT_HUGEPAGE
>   case GET:
>   error = test_bit(MMF_THP_DISABLE);
>   break;
>   case PUT:
>   if (arg2)
>   set_bit();
>   else
>   clear_bit();
>   break;
>   #endif
> 
> into sys_prctl() ?

That's probably a better solution.  I wasn't sure whether or not it was
better to have two functions to handle this, or to have one function
handle both.  If you think it's better to just handle both with one,
that's easy enough to change.

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

Re: [PATCH 1/4] perf, tools: Add support for prepending LBRs to the callstack

2014-01-11 Thread Andi Kleen
> What was your build command line?
> 
> Here, on a f18 system it works with these:
> 
> $ make -C tools/perf O=/tmp/build/perf install
> 
> $ cd tools/perf ; make
> 
> Trying on another system...

Sorry for the false alarm. It looks like it was a problem on my side.
Works now.

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


Re: [PATCH 1/4] perf, tools: Add support for prepending LBRs to the callstack

2014-01-11 Thread Arnaldo Carvalho de Melo
Em Sat, Jan 11, 2014 at 06:58:16PM +0100, Andi Kleen escreveu:
> On Sat, Jan 11, 2014 at 04:36:14PM +0100, Jiri Olsa wrote:
> > On Fri, Jan 10, 2014 at 04:32:03AM -0800, Andi Kleen wrote:
> > > From: Andi Kleen 
> > > 
> > > I never found the default LBR display mode which generates histograms
> > > of individual branches particularly useful.
> > > 
> > > This implements an alternative mode that creates histograms over complete
> > > branch traces, instead of individual branches, similar to how normal
> > > callgraphs are handled. This is done by putting it in
> > > front of the normal callgraph and then using the normal callgraph
> > > histogram infrastructure to unify them.
> > > 
> > > This way in complex functions we can understand the control flow
> > > that lead to a particular sample.
> > > 
> > > The default output is unchanged.
> > > 
> > > This is only implemented in perf report, no change to record
> > > or anywhere else.
> > > 
> > > This adds the basic code to report:
> > > - add a new "branch" option to the -g option parser to enable this mode
> > > - when the flag is set include the LBR into the callstack in machine.c.
> > > The rest of the history code is unchanged and doesn't know the difference
> > > between LBR entry and normal call entry.
> > 
> > sounds like nice idea, but I could not get the patchset applied
> > on acme's perf/core
> 
> It was on Linus master.
> 
> I tried to rebase on perf/core, but it seems to be totally broken by
> itself. All the config tests fail on my opensuse system.
> 
> Arnaldo?

Oops, checking on some systems...
 
> Auto-detecting system features:
> ... backtrace: [ OFF ]
> ... dwarf: [ OFF ]
> ...fortify-source: [ OFF ]
> ... glibc: [ OFF ]
> ...  gtk2: [ OFF ]
> ...  gtk2-infobar: [ OFF ]
> ...  libaudit: [ OFF ]
> ...libbfd: [ OFF ]
> ...libelf: [ OFF ]
> ... libelf-getphdrnum: [ OFF ]
> ...   libelf-mmap: [ OFF ]
> ...   libnuma: [ OFF ]
> ...   libperl: [ OFF ]
> ... libpython: [ OFF ]
> ... libpython-version: [ OFF ]
> ...  libslang: [ OFF ]
> ... libunwind: [ OFF ]
> ...   on-exit: [ OFF ]
> ...stackprotector-all: [ OFF ]
> ...   timerfd: [ OFF ]
> 
> config/Makefile:282: *** No gnu/libc-version.h found, please install
> glibc-dev[el]/glibc-static.  Stop.
> make: *** [all] Error 2
> 
> -Andi
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


Re: [PATCH 1/4] perf, tools: Add support for prepending LBRs to the callstack

2014-01-11 Thread Arnaldo Carvalho de Melo
Em Sat, Jan 11, 2014 at 04:16:57PM -0300, Arnaldo Carvalho de Melo escreveu:
> Em Sat, Jan 11, 2014 at 06:58:16PM +0100, Andi Kleen escreveu:
> > On Sat, Jan 11, 2014 at 04:36:14PM +0100, Jiri Olsa wrote:
> > > On Fri, Jan 10, 2014 at 04:32:03AM -0800, Andi Kleen wrote:
> > > > From: Andi Kleen 
> > > > 
> > > > I never found the default LBR display mode which generates histograms
> > > > of individual branches particularly useful.
> > > > 
> > > > This implements an alternative mode that creates histograms over 
> > > > complete
> > > > branch traces, instead of individual branches, similar to how normal
> > > > callgraphs are handled. This is done by putting it in
> > > > front of the normal callgraph and then using the normal callgraph
> > > > histogram infrastructure to unify them.
> > > > 
> > > > This way in complex functions we can understand the control flow
> > > > that lead to a particular sample.
> > > > 
> > > > The default output is unchanged.
> > > > 
> > > > This is only implemented in perf report, no change to record
> > > > or anywhere else.
> > > > 
> > > > This adds the basic code to report:
> > > > - add a new "branch" option to the -g option parser to enable this mode
> > > > - when the flag is set include the LBR into the callstack in machine.c.
> > > > The rest of the history code is unchanged and doesn't know the 
> > > > difference
> > > > between LBR entry and normal call entry.
> > > 
> > > sounds like nice idea, but I could not get the patchset applied
> > > on acme's perf/core
> > 
> > It was on Linus master.
> > 
> > I tried to rebase on perf/core, but it seems to be totally broken by
> > itself. All the config tests fail on my opensuse system.
> > 
> > Arnaldo?
> 
> Oops, checking on some systems...

What was your build command line?

Here, on a f18 system it works with these:

$ make -C tools/perf O=/tmp/build/perf install

$ cd tools/perf ; make

Trying on another system...

- Arnaldo
  
> > Auto-detecting system features:
> > ... backtrace: [ OFF ]
> > ... dwarf: [ OFF ]
> > ...fortify-source: [ OFF ]
> > ... glibc: [ OFF ]
> > ...  gtk2: [ OFF ]
> > ...  gtk2-infobar: [ OFF ]
> > ...  libaudit: [ OFF ]
> > ...libbfd: [ OFF ]
> > ...libelf: [ OFF ]
> > ... libelf-getphdrnum: [ OFF ]
> > ...   libelf-mmap: [ OFF ]
> > ...   libnuma: [ OFF ]
> > ...   libperl: [ OFF ]
> > ... libpython: [ OFF ]
> > ... libpython-version: [ OFF ]
> > ...  libslang: [ OFF ]
> > ... libunwind: [ OFF ]
> > ...   on-exit: [ OFF ]
> > ...stackprotector-all: [ OFF ]
> > ...   timerfd: [ OFF ]
> > 
> > config/Makefile:282: *** No gnu/libc-version.h found, please install
> > glibc-dev[el]/glibc-static.  Stop.
> > make: *** [all] Error 2
> > 
> > -Andi
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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 RESEND] clk: support hardware-specific debugfs entries

2014-01-11 Thread Alex Elder
Add a new clk_ops->debug_init method to allow a clock hardware
driver to populate the clock's debugfs directory with entries
beyond those common for every clock.

Signed-off-by: Alex Elder 
---
v2: - Define debug_init unconditionally (suggested by Gerhard Sittig).

 drivers/clk/clk.c|4 
 include/linux/clk-provider.h |8 
 2 files changed, 12 insertions(+)

diff --git a/drivers/clk/clk.c b/drivers/clk/clk.c
index e3e0327..8769b01 100644
--- a/drivers/clk/clk.c
+++ b/drivers/clk/clk.c
@@ -277,6 +277,10 @@ static int clk_debug_create_one(struct clk *clk, struct 
dentry *pdentry)
if (!d)
goto err_out;
 
+   if (clk->ops->debug_init)
+   if (clk->ops->debug_init(clk->hw, clk->dentry))
+   goto err_out;
+
ret = 0;
goto out;
 
diff --git a/include/linux/clk-provider.h b/include/linux/clk-provider.h
index 5429f5d..b91674d 100644
--- a/include/linux/clk-provider.h
+++ b/include/linux/clk-provider.h
@@ -32,6 +32,7 @@
 #define CLK_GET_ACCURACY_NOCACHE BIT(8) /* do not use the cached clk accuracy 
*/
 
 struct clk_hw;
+struct dentry;
 
 /**
  * struct clk_ops -  Callback operations for hardware clocks; these are to
@@ -116,6 +117,12 @@ struct clk_hw;
  * set then clock accuracy will be initialized to parent accuracy
  * or 0 (perfect clock) if clock has no parent.
  *
+ * @debug_init:Set up type-specific debugfs entries for this clock.  
This
+ * is called once, after the debugfs directory entry for this
+ * clock has been created.  The dentry pointer representing that
+ * directory is provided as an argument.  Called with
+ * prepare_lock held.  Returns 0 on success, -EERROR otherwise.
+ *
  * The clk_enable/clk_disable and clk_prepare/clk_unprepare pairs allow
  * implementations to split any work between atomic (enable) and sleepable
  * (prepare) contexts.  If enabling a clock requires code that might sleep,
@@ -150,6 +157,7 @@ struct clk_ops {
unsigned long   (*recalc_accuracy)(struct clk_hw *hw,
   unsigned long parent_accuracy);
void(*init)(struct clk_hw *hw);
+   int (*debug_init)(struct clk_hw *hw, struct dentry *dentry);
 };
 
 /**
-- 
1.7.9.5

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


Re: [PATCH v2 0/28] drm/i2c: tda998x: add DT support and other improvements

2014-01-11 Thread Russell King - ARM Linux
On Thu, Jan 09, 2014 at 11:56:51AM +0100, Jean-Francois Moine wrote:
> This patch set contains various extensions to the tda998x driver:
> 
> - simplify the i2c read/write
> - code cleanup and fix some small errors
> - use HDMI constants
> - don't read write-only registers
> - add DT support
> - use irq for connection status and EDID read
> - get a better status of the HDMI connector
> - use the tda998x video format when cea mode
> - add tda998x codec interface
> 
> - v2
>   - decompose patches with different topics
>   - fix some bad i2c register values
>   - add audio codec interface
> 

Next time you post patches, please ensure that each patch is a reply
to your series covering message, so that they can be easily threaded
together.  It's a pain to have to search around for all the individual
patches amongst other people's traffic.

Thanks.

-- 
FTTC broadband for 0.8mile line: 5.8Mbps down 500kbps up.  Estimation
in database were 13.1 to 19Mbit for a good line, about 7.5+ for a bad.
Estimate before purchase was "up to 13.2Mbit".
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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: blackfin + dmaengine: conflicting define/enum "DMA_COMPLETE"

2014-01-11 Thread Marc Kleine-Budde
On 01/11/2014 07:31 PM, Randy Dunlap wrote:
> On 01/11/2014 10:09 AM, Marc Kleine-Budde wrote:
>> Hello,
>>
>> in current linux-next (and net-next) the compilation of the CAN
>> drivers[1] with ARCH=blackfin fails with:
>>
>>>   CC [M]  drivers/net/can/c_can/c_can.o
>>> In file included from linux/include/linux/netdevice.h:38:0,
>>>  from linux/drivers/net/can/c_can/c_can.c:32:
>>> linux/include/linux/dmaengine.h:55:2: error: expected identifier before 
>>> numeric constant
>>> linux/include/linux/dmaengine.h: In function 'dma_async_is_complete':
>>> linux/include/linux/dmaengine.h:1023:9: error: 'DMA_IN_PROGRESS' undeclared 
>>> (first use in this function)
>>> linux/include/linux/dmaengine.h:1023:9: note: each undeclared identifier is 
>>> reported only once for each function it appears in
>>
>> There are two locations where DMA_COMPLETE is defined:
>>
>>> arch/blackfin/mach-bf548/include/mach/defBF547.h:602:#define  
>>> DMA_COMPLETE  0x8/* DMA Complete */
>>> arch/blackfin/mach-bf548/include/mach/defBF544.h:622:#define  
>>> DMA_COMPLETE  0x8/* DMA Complete */
>>
>> and
>>
>>> include/linux/dmaengine.h-enum dma_status {
>>> include/linux/dmaengine.h:  DMA_COMPLETE,
>>> include/linux/dmaengine.h-  DMA_IN_PROGRESS,
>>> include/linux/dmaengine.h-  DMA_PAUSED,
>>> include/linux/dmaengine.h-  DMA_ERROR,
>>> include/linux/dmaengine.h-};
>>
>> What's the appropriate fix for the problem?
> 
> arch/blackfin/mach-bf548/ needs a less generic name for its macro.

Mike, is there a in tree user of blacksfin's DMA_COMPLETE? I cannot find
anyone.

Marc

-- 
Pengutronix e.K.  | Marc Kleine-Budde   |
Industrial Linux Solutions| Phone: +49-231-2826-924 |
Vertretung West/Dortmund  | Fax:   +49-5121-206917- |
Amtsgericht Hildesheim, HRA 2686  | http://www.pengutronix.de   |



signature.asc
Description: OpenPGP digital signature


Re: [PATCH v2 26/28] drm/i2c: tda998x: code optimization

2014-01-11 Thread Russell King - ARM Linux
On Thu, Jan 09, 2014 at 12:07:25PM +0100, Jean-Francois Moine wrote:
> This patch reduces the number of I2C exchanges by setting many bits in
> one write and removing a useless write.
> 
> Signed-off-by: Jean-Francois Moine 
> ---
>  drivers/gpu/drm/i2c/tda998x_drv.c   | 10 --
>  1 file changed, 4 insertions(+), 6 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i2c/tda998x_drv.c 
> b/drivers/gpu/drm/i2c/tda998x_drv.c
> index 6b4f6d2..d3b3f3a 100644
> --- a/drivers/gpu/drm/i2c/tda998x_drv.c
> +++ b/drivers/gpu/drm/i2c/tda998x_drv.c
> @@ -751,10 +751,10 @@ tda998x_configure_audio(struct tda998x_priv *priv,
>   }
>  
>   reg_write(priv, REG_AIP_CLKSEL, clksel_aip);
> - reg_clear(priv, REG_AIP_CNTRL_0, AIP_CNTRL_0_LAYOUT);
> + reg_clear(priv, REG_AIP_CNTRL_0, AIP_CNTRL_0_LAYOUT |

This patch clearly hasn't even been build tested, so I doubt there's
much point reviewing this or the following patches.  From a quick scan
of the following patches, this never got fixed so the following patches
can't have been build tested either.

Thanks.

-- 
FTTC broadband for 0.8mile line: 5.8Mbps down 500kbps up.  Estimation
in database were 13.1 to 19Mbit for a good line, about 7.5+ for a bad.
Estimate before purchase was "up to 13.2Mbit".
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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: [PATCHSET v2 driver-core-next] kernfs, sysfs, driver-core: implement synchronous self-removal

2014-01-11 Thread Tejun Heo
Hey, Alan.

On Fri, Jan 10, 2014 at 10:46:10AM -0500, Alan Stern wrote:
> The SUBJECT lines in your patch emails don't mention the version
> number.  That is, they just say "[PATCH]", not "[PATCH v2]" or "[PATCH
> v3]". This makes it very difficult for me to tell which messages to
> read.

Hmm... they're all threaded.  I add version tags when posting
incremental patches but usually don't bother with it when posting a
new version of the whole series.  After all, some patches are get
updated without explicitly given a new version for refrehses and stuff
so it's not like you can determine everything based on subjects only.

> (Reading them in order doesn't work, because my computer mixes up the 
> order of messages when it downloads a large bunch from the email 
> server.  It's kind of annoying...)

And they aren't threaded?

Thanks.

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


Re: [PATCH v2 23/28] drm/i2c: tda998x: add the active aspect in HDMI AVI frame

2014-01-11 Thread Russell King - ARM Linux
On Thu, Jan 09, 2014 at 12:06:39PM +0100, Jean-Francois Moine wrote:
> This patch adds the active aspect as 'picture' in the HDMI AVI frame
> and also some comments about this frame.

Yes, this should've been set.  It's probably a stable tree candidate,
but first it needs testing.

-- 
FTTC broadband for 0.8mile line: 5.8Mbps down 500kbps up.  Estimation
in database were 13.1 to 19Mbit for a good line, about 7.5+ for a bad.
Estimate before purchase was "up to 13.2Mbit".
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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: [PATCHSET v3 driver-core-next] kernfs, sysfs, driver-core: implement synchronous self-removal

2014-01-11 Thread Tejun Heo
Hey, Greg.

On Fri, Jan 10, 2014 at 04:19:53PM -0800, Greg KH wrote:
> > It's really late in the -rc cycle for me to take this for 3.14, but I
> > see patch 1 is a good one to have, so I'll take that now, and queue the
> > rest up for after 3.14-rc1 is out for 3.15.  Is that ok with you, or do
> > you have patches that depend on this series for 3.14?
> 
> Oh nevermind, these are all good, now applied :)

I don't have anything depending on the series for the up coming merge
window so 3.15 merge window would have been fine but 3.14 merge
windows wokrs too. :)

Thanks.

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


Re: [PATCH v2 21/28] drm/i2c: tda998x: use global constants

2014-01-11 Thread Russell King - ARM Linux
On Thu, Jan 09, 2014 at 12:06:18PM +0100, Jean-Francois Moine wrote:
> 
> Signed-off-by: Jean-Francois Moine 
> ---
>  drivers/gpu/drm/i2c/tda998x_drv.c   | 23 +-
>  1 file changed, 14 insertions(+), 9 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i2c/tda998x_drv.c 
> b/drivers/gpu/drm/i2c/tda998x_drv.c
> index 864b9f5..efd29d1 100644
> --- a/drivers/gpu/drm/i2c/tda998x_drv.c
> +++ b/drivers/gpu/drm/i2c/tda998x_drv.c
> @@ -132,6 +132,8 @@ struct tda998x_priv {
>  # define VIP_CNTRL_5_CKCASE   (1 << 0)
>  # define VIP_CNTRL_5_SP_CNT(x)(((x) & 3) << 1)
>  #define REG_MUX_APREG(0x00, 0x26) /* read/write */
> +# define MUX_AP_SELECT_I2S 0x64
> +# define MUX_AP_SELECT_SPDIF   0x40
>  #define REG_MUX_VP_VIP_OUTREG(0x00, 0x27) /* read/write */
>  #define REG_MAT_CONTRLREG(0x00, 0x80) /* write */
>  # define MAT_CONTRL_MAT_SC(x) (((x) & 3) << 0)
> @@ -212,7 +214,12 @@ struct tda998x_priv {
>  # define AIP_CLKSEL_FS(x) (((x) & 3) << 0)
>  # define AIP_CLKSEL_CLK_POL(x)(((x) & 1) << 2)
>  # define AIP_CLKSEL_AIP(x)(((x) & 7) << 3)
> -
> +#define  SEL_AIP_SPDIF 0
> +#define  SEL_AIP_I2S   1

I'd much rather these became:

# define AIP_CLKSEL_AIP_SPDIF (0 << 3)
# define AIP_CLKSEL_AIP_I2S   (1 << 3)

and kill AIP_CLKSEL_AIP().

> +#define  CLKPOLDSD_ACLK0 /* same pol as 
> ACLK */
> +#define  CLKPOLDSD_NACLK   1 /* inverted */

If this is for AIP_CLKSEL_CLK_POL, this is labelled up in the data I
have as "for internal use" - we should probably remove AIP_CLKSEL_CLK_POL()
from the above definitions.

> +#define  CTSREF_ACLK   0 /* I2S */
> +#define  CTSREF_FS64SPDIF  2 /* spdif */

Again, better to define these as:

# define AIP_CLKSEL_FS_ACLK   (0 << 0)
# define AIP_CLKSEL_FS_MCLK   (1 << 0)
# define AIP_CLKSEL_FS_FS64SPDIF  (2 << 0)

and kill AIP_CLKSEL_FS().

-- 
FTTC broadband for 0.8mile line: 5.8Mbps down 500kbps up.  Estimation
in database were 13.1 to 19Mbit for a good line, about 7.5+ for a bad.
Estimate before purchase was "up to 13.2Mbit".
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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 9/28] drm/i2c: tda998x: don't read write-only registers

2014-01-11 Thread Russell King - ARM Linux
On Thu, Jan 09, 2014 at 11:59:41AM +0100, Jean-Francois Moine wrote:
> @@ -936,10 +926,22 @@ tda998x_encoder_mode_set(struct drm_encoder *encoder,
>   /* must be last register set: */
>   reg_clear(priv, REG_TBG_CNTRL_0, TBG_CNTRL_0_SYNC_ONCE);
>  
> + /*
> +  * Always generate sync polarity relative to input sync and
> +  * revert input stage toggled sync at output stage
> +  */
> + reg = TBG_CNTRL_1_DWIN_DIS | TBG_CNTRL_1_TGL_EN;
> + if (mode->flags & DRM_MODE_FLAG_NHSYNC)
> + reg |= TBG_CNTRL_1_H_TGL;
> + if (mode->flags & DRM_MODE_FLAG_NVSYNC)
> + reg |= TBG_CNTRL_1_V_TGL;
> + reg_write(priv, REG_TBG_CNTRL_1, reg);
> +

I now NAK this patch, as it messes up the register writing order.  See
the comment in the context line above.

-- 
FTTC broadband for 0.8mile line: 5.8Mbps down 500kbps up.  Estimation
in database were 13.1 to 19Mbit for a good line, about 7.5+ for a bad.
Estimate before purchase was "up to 13.2Mbit".
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


man-pages-3.56 is released

2014-01-11 Thread Michael Kerrisk (man-pages)
Gidday,

I've released man-pages-3.55 - man pages for Linux.

Tarball download:
http://www.kernel.org/doc/man-pages/download.html
Git repository:
https://git.kernel.org/cgit/docs/man-pages/man-pages.git/
Online changelog:
http://man7.org/linux/man-pages/changelog.html#release_3.55

A short summary of the release is blogged at:
http://linux-man-pages.blogspot.com/2014/01/man-pages-356-is-released.html

The current version of the pages is browsable at:
http://man7.org/linux/man-pages/

A few changes in this release that may be of interest to readers of
this list are given below.

Cheers,

Michael


 Changes in man-pages-3.56 

New and rewritten pages
---

vdso.7
Mike Frysinger
New page documenting the vDSO mapped into each process by the kernel


Newly documented interfaces in existing pages
-

reboot.2
Elie De Brauwer
Document LINUX_REBOOT_SW_SUSPEND


Changes to individual pages
---

close.2
Michael Kerrisk  [P?draig Brady]
Note that errors from close() should be used only for diagnosis
In particular, retrying after EINTR is a bad idea.

See http://austingroupbugs.net/view.php?id=529

See http://thread.gmane.org/gmane.comp.lib.glibc.alpha/37702
Subject: [RFC][BZ #14627] Make linux close errno to EINPROGRESS
 when interrupted in signal.

perf_event_open.2
Vince Weaver  [Sudhanshu Goswami]
Clarify issues with the disabled bit
Clarify the perf_event_open behavior with respect to the disabled
bit and creating event groups.
Vince Weaver  [Sudhanshu Goswami]
Clarify issues with the exclusive bit
Warn that using the perf_event_open "exclusive" bit, while
it might seem like a good idea, might lead to all 0 results
in some common usage cases.

setpgid.2
Michael Kerrisk  [Joseph S. Myers]
BSD getpgrp() and setpgrp() go away in glibc 2.19

socket.2
Michael Kerrisk  [Dongsheng Song]
Remove crufty statement that AF_INET does not support SOCK_SEQPACKET
Linux AF_INET supports SOCK_SEQPACKET via SCTP.

dlopen.3
Michael Kerrisk  [Mike Frysinger]
Update remarks on cast needed when assigning dlsym() return value
POSIX.1-2013 eases life when casting the dlsym() return value to a
function pointer

setjmp.3
Michael Kerrisk  [Joseph S. Myers]
BSD setjmp() semantics go away in glibc 2.19

sigpause.3
Michael Kerrisk  [Joseph S. Myers]
BSD sigpause() goes away in glibc 2.19

credentials.7
Michael Kerrisk
List APIs that operate on process groups
Michael Kerrisk
Add details on controlling terminal and foreground/background jobs

feature_test_macros.7
Michael Kerrisk
Document _DEFAULT_SOURCE
Michael Kerrisk  [Joseph S. Myers]
From glibc 2.19, _BSD_SOURCE no longer causes __FAVOR_BSD
Starting with glibc 2.19, _BSD_SOURCE no longer causes BSD
definitions to be favored in cases where standards conflict.

man-pages.7
Michael Kerrisk  [Mike Frysinger]
Add STYLE GUIDE section
Incorporate some of the existing material in the page
into the STYLE GUIDE, and add a lot more material, mainly
drawn from the "Global changes" sections in the release
changelogs.
packet.7
Willem de Bruijn  [Daniel Borkmann]
Document fanout, ring, and auxiliary options
This patch adds descriptions of the common packet socket options
  PACKET_AUXDATA, PACKET_FANOUT, PACKET_RX_RING, PACKET_STATISTICS,
  PACKET_TX_RING
and the ring-specific options
  PACKET_LOSS, PACKET_RESERVE, PACKET_TIMESTAMP, PACKET_VERSION
Michael Kerrisk
Add kernel version numbers for PACKET_VERSION and PACKET_TIMESTAMP


-- 
Michael Kerrisk
Linux man-pages maintainer; http://www.kernel.org/doc/man-pages/
Linux/UNIX System Programming Training: http://man7.org/training/

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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 20/28] drm/i2c: tda998x: move the TBG_CNTRL_0 register setting

2014-01-11 Thread Russell King - ARM Linux
On Thu, Jan 09, 2014 at 12:06:07PM +0100, Jean-Francois Moine wrote:
> According to the comment, the TBG_CNTRL_0 register must be set at the
> end of the mode change sequence.

So you believe comments without understanding the history, and you move
code around due to those.

No, this is again wrong.  That write to REG_TBG_CNTRL_0 in the sequence
writing the video information to the chip.  This doesn't encompass the
HDMI/DVI mode setting nor the audio configuration - the audio configuration
can change independently of the video setting, and does not require this
register to be written.

This also brings up a bug in one of your previous patches which I now
must go back and comment upon.

-- 
FTTC broadband for 0.8mile line: 5.8Mbps down 500kbps up.  Estimation
in database were 13.1 to 19Mbit for a good line, about 7.5+ for a bad.
Estimate before purchase was "up to 13.2Mbit".
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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 13/28] drm/i2c: tda998x: use irq for connection status and EDID read

2014-01-11 Thread Sebastian Hesselbarth

On 01/11/2014 07:14 PM, Russell King - ARM Linux wrote:

On Thu, Jan 09, 2014 at 12:04:12PM +0100, Jean-Francois Moine wrote:

@@ -1250,6 +1311,39 @@ tda998x_encoder_init(struct i2c_client *client,
priv->vip_cntrl_2 = video;
}

+   /* install the optional HDMI connect IRQ */
+   priv->int_irq = irq_of_parse_and_map(np, 0);
+   if (priv->int_irq < 0)
+   priv->int_irq = NO_IRQ;
+   if (priv->int_irq != NO_IRQ) {


NAK.  Do not use NO_IRQ.  Use <= 0 instead, or just test against zero for
no IRQ.  It would also be nice to offer this facility to non-DT platforms
via client->irq.  Not every arch in the Linux kernel uses DT.


At least for the DT part, I'd suggest to not ask for interrupt directly
but use a proper gpios property. The can of course be converted to
priv->int_irq in some tda998x_dt_probe.

Sebastian
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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 19/28] drm/i2c: tda998x: fix the value of the TBG_CNTRL_1 register

2014-01-11 Thread Russell King - ARM Linux
On Thu, Jan 09, 2014 at 12:05:43PM +0100, Jean-Francois Moine wrote:
> This patch fixes the 'toggle flag enable' bit of the TBG_CNTRL_1
> register which was set when no toggle was needed.
> 
> Signed-off-by: Jean-Francois Moine 
> ---
>  drivers/gpu/drm/i2c/tda998x_drv.c | 6 +++---
>  1 file changed, 3 insertions(+), 3 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i2c/tda998x_drv.c 
> b/drivers/gpu/drm/i2c/tda998x_drv.c
> index 192ddd2..7dbbc6b 100644
> --- a/drivers/gpu/drm/i2c/tda998x_drv.c
> +++ b/drivers/gpu/drm/i2c/tda998x_drv.c
> @@ -1080,11 +1080,11 @@ tda998x_encoder_mode_set(struct drm_encoder *encoder,
>* Always generate sync polarity relative to input sync and
>* revert input stage toggled sync at output stage
>*/
> - reg = TBG_CNTRL_1_DWIN_DIS | TBG_CNTRL_1_TGL_EN;
> + reg = TBG_CNTRL_1_DWIN_DIS;
>   if (mode->flags & DRM_MODE_FLAG_NHSYNC)
> - reg |= TBG_CNTRL_1_H_TGL;
> + reg |= TBG_CNTRL_1_H_TGL | TBG_CNTRL_1_TGL_EN;
>   if (mode->flags & DRM_MODE_FLAG_NVSYNC)
> - reg |= TBG_CNTRL_1_V_TGL;
> + reg |= TBG_CNTRL_1_V_TGL | TBG_CNTRL_1_TGL_EN;
>   reg_write(priv, REG_TBG_CNTRL_1, reg);

This has me wondering whether you understand the meaning of TGL_EN here,
and what it means.

When TGL_EN is set, the inversion of the syncs is determined by the
settings of the H_TGL and V_TGL bits.  When they're zero, no inversion
happens.

However, when TGL_EN is clear, the inversion is determined by the CEA
mode setting in REG_VIDFORMAT.

What your code above means is that if a mode setting valuates as matching
a CEA mode, but has different syncs (eg, no inversion required) then we
don't set the enable bit, and we fall back to whatever is in the TDA998x
device's internal tables for the CEA mode.  This is wrong behaviour.

If we want to do this, then the right way would be to detect whether a
sync polarity has been specified (iow, whether any [NP][HV]SYNC flags
have been set) and set the TGL_EN if they have.  Otherwise, the TGL_EN
flag can be cleared.

I'm not saying that this will ever result in the TGL_EN flag being
cleared, but to me, your change above is incorrect.

-- 
FTTC broadband for 0.8mile line: 5.8Mbps down 500kbps up.  Estimation
in database were 13.1 to 19Mbit for a good line, about 7.5+ for a bad.
Estimate before purchase was "up to 13.2Mbit".
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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: blackfin + dmaengine: conflicting define/enum "DMA_COMPLETE"

2014-01-11 Thread Randy Dunlap
On 01/11/2014 10:09 AM, Marc Kleine-Budde wrote:
> Hello,
> 
> in current linux-next (and net-next) the compilation of the CAN
> drivers[1] with ARCH=blackfin fails with:
> 
>>   CC [M]  drivers/net/can/c_can/c_can.o
>> In file included from linux/include/linux/netdevice.h:38:0,
>>  from linux/drivers/net/can/c_can/c_can.c:32:
>> linux/include/linux/dmaengine.h:55:2: error: expected identifier before 
>> numeric constant
>> linux/include/linux/dmaengine.h: In function 'dma_async_is_complete':
>> linux/include/linux/dmaengine.h:1023:9: error: 'DMA_IN_PROGRESS' undeclared 
>> (first use in this function)
>> linux/include/linux/dmaengine.h:1023:9: note: each undeclared identifier is 
>> reported only once for each function it appears in
> 
> There are two locations where DMA_COMPLETE is defined:
> 
>> arch/blackfin/mach-bf548/include/mach/defBF547.h:602:#define  
>> DMA_COMPLETE  0x8/* DMA Complete */
>> arch/blackfin/mach-bf548/include/mach/defBF544.h:622:#define  
>> DMA_COMPLETE  0x8/* DMA Complete */
> 
> and
> 
>> include/linux/dmaengine.h-enum dma_status {
>> include/linux/dmaengine.h:  DMA_COMPLETE,
>> include/linux/dmaengine.h-  DMA_IN_PROGRESS,
>> include/linux/dmaengine.h-  DMA_PAUSED,
>> include/linux/dmaengine.h-  DMA_ERROR,
>> include/linux/dmaengine.h-};
> 
> What's the appropriate fix for the problem?

arch/blackfin/mach-bf548/ needs a less generic name for its macro.

> Marc
> 
> [1] Yes, c_can isn't a blackfin driver, but it's the first one in my
> compile tests and it fails.
> 


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


  1   2   >