Re: [PATCH v9 3/5] crypto: drbg - add async seeding operation

2015-05-20 Thread Herbert Xu
On Thu, May 21, 2015 at 08:53:13AM +0200, Stephan Mueller wrote:
>
> Thank you for pointing that out - I have seen that too. But the crux is that 
> when using wait_event, the cancel function to serialize the destruction code 
> path will *not* return at all, even when the async callback function 
> completed 
> successfully. Hence the choice for wait_event_interruptible

Why is that? It should return when the pool is initialised and
your work completes.  If it does not then that means either the
pool isn't initialising or somehow your code is racy and getting
stuck.

If it's racy then wait_event_interruptible is just hiding the
real problem.

Cheers,
-- 
Email: Herbert Xu 
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


Aw: Re: [PATCH v1] ARM: dts: nitrogen6x: add CAN support

2015-05-20 Thread Peter Seiderer
Hello Shawn,

> Gesendet: Donnerstag, 21. Mai 2015 um 03:33 Uhr
> Von: "Shawn Guo" 
> An: "Peter Seiderer" 
> Cc: linux-kernel@vger.kernel.org, devicet...@vger.kernel.org, 
> linux-arm-ker...@lists.infradead.org, "Russell King" 
> , "Kumar Gala" , "Ian Campbell" 
> , "Mark Rutland" , 
> "Pawel Moll" , "Rob Herring" , 
> "Sascha Hauer" 
> Betreff: Re: [PATCH v1] ARM: dts: nitrogen6x: add CAN support
>
> On Wed, May 20, 2015 at 11:49:29PM +0200, Peter Seiderer wrote:
> > Regulator stuff copied from imx6qdl-tx6.dtsi, pin configuration
> > taken from Boundary Devices linux kernel tree ([1] and [2]).
> > 
> > [1] 
> > https://github.com/boundarydevices/linux-imx6/blob/boundary-imx_3.10.17_1.0.2_ga/arch/arm/boot/dts/imx6qdl-nitrogen6x.dts
> > [2] 
> > https://github.com/boundarydevices/linux-imx6/blob/boundary-imx_3.10.17_1.0.2_ga/arch/arm/boot/dts/imx6qdl.dtsi
> > 
> > Signed-off-by: Peter Seiderer 
> > ---
> >  arch/arm/boot/dts/imx6qdl-nitrogen6x.dtsi | 32 
> > +++
> >  1 file changed, 32 insertions(+)
> > 
> > diff --git a/arch/arm/boot/dts/imx6qdl-nitrogen6x.dtsi 
> > b/arch/arm/boot/dts/imx6qdl-nitrogen6x.dtsi
> > index fd096dc..1c415e4 100644
> > --- a/arch/arm/boot/dts/imx6qdl-nitrogen6x.dtsi
> > +++ b/arch/arm/boot/dts/imx6qdl-nitrogen6x.dtsi
> > @@ -54,6 +54,17 @@
> > gpio = <&gpio3 22 0>;
> > enable-active-high;
> > };
> > +
> > +   reg_can_xcvr: regulator@3 {
> > +   compatible = "regulator-fixed";
> > +   reg = <3>;
> > +   regulator-name = "CAN XCVR";
> > +   regulator-min-microvolt = <330>;
> > +   regulator-max-microvolt = <330>;
> > +   pinctrl-names = "default";
> > +   pinctrl-0 = <&pinctrl_can_xcvr>;
> > +   gpio = <&gpio1 2 GPIO_ACTIVE_HIGH>;
> > +   };
> > };
> >  
> > gpio-keys {
> > @@ -138,6 +149,13 @@
> > status = "okay";
> >  };
> >  
> > +&can1 {
> > +   pinctrl-names = "default";
> > +   pinctrl-0 = <&pinctrl_can1_1>;
> > +   xceiver-supply = <®_can_xcvr>;
> > +   status = "okay";
> > +};
> > +
> >  &ecspi1 {
> > fsl,spi-num-chipselects = <1>;
> > cs-gpios = <&gpio3 19 0>;
> > @@ -234,6 +252,20 @@
> > >;
> > };
> >  
> > +   pinctrl_can1_1: can1grp-1 {
> 
> The '_1' suffix is meaningless.
> 
>   pinctrl_can1: can1grp {

Thanks for review, will fix it...

Regards,
Peter

> 
> Shawn
> 
> > +   fsl,pins = <
> > +   MX6QDL_PAD_KEY_COL2__FLEXCAN1_TX 0x8000
> > +   MX6QDL_PAD_KEY_ROW2__FLEXCAN1_RX 0x8000
> > +   >;
> > +   };
> > +
> > +   pinctrl_can_xcvr: can-xcvrgrp {
> > +   fsl,pins = <
> > +   /* Flexcan XCVR enable */
> > +   MX6QDL_PAD_GPIO_2__GPIO1_IO02   0x1b0b0
> > +   >;
> > +   };
> > +
> > pinctrl_ecspi1: ecspi1grp {
> > fsl,pins = <
> > MX6QDL_PAD_EIM_D17__ECSPI1_MISO 0x100b1
> > -- 
> > 2.1.4
> > 
> > --
> > To unsubscribe from this list: send the line "unsubscribe devicetree" in
> > the body of a message to majord...@vger.kernel.org
> > More majordomo info at  http://vger.kernel.org/majordomo-info.html
> 
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


Re: [PATCH v11 08/10] iommu/vt-d: assign new page table for dma_map

2015-05-20 Thread Baoquan He
On 05/21/15 at 09:27am, Li, ZhenHua wrote:
> Hi Baoquan,
> 
> In the early version of this patchset, old page tables are used by new
> kernel.  But as discussed, we need to make kernel use new pages when
> there is a new dma request , so we need to unmap the pages which were
> mapped in old kernel, and this is what this patch does.

OK, just a new page table allocated in init_domain(), right? I thought a
specific empty page-table is allocated for these new domains in kdump
kernel.

> 
> Thanks
> Zhenhua
> 
> On 05/21/2015 07:52 AM, Baoquan He wrote:
> >On 05/11/15 at 05:52pm, Li, Zhen-Hua wrote:
> >>When a device driver issues the first dma_map command for a device, we
> >>assign a new and empty page-table, thus removing all mappings from the
> >>old kernel for the device.
> >
> >Hi Zhenhua,
> >
> > From your patch I got it will remove all mappings, assign a new
> >page-table. But I didn't got why you stress an empty page-table. Did I
> >miss anything?
> >
> >Thanks
> >Baoquan
> >
> >>
> >>Signed-off-by: Li, Zhen-Hua 
> >>---
> >>  drivers/iommu/intel-iommu.c | 58 
> >> ++---
> >>  1 file changed, 50 insertions(+), 8 deletions(-)
> >>
> >>diff --git a/drivers/iommu/intel-iommu.c b/drivers/iommu/intel-iommu.c
> >>index 91545bf..3cc1027 100644
> >>--- a/drivers/iommu/intel-iommu.c
> >>+++ b/drivers/iommu/intel-iommu.c
> >>@@ -396,6 +396,9 @@ static int copy_root_entry_table(struct intel_iommu 
> >>*iommu);
> >>
> >>  static int intel_iommu_load_translation_tables(struct intel_iommu *iommu);
> >>
> >>+static void unmap_device_dma(struct dmar_domain *domain,
> >>+   struct device *dev,
> >>+   struct intel_iommu *iommu);
> >>  static void iommu_check_pre_te_status(struct intel_iommu *iommu);
> >>  static u8 g_translation_pre_enabled;
> >>
> >>@@ -3115,6 +3118,7 @@ static struct iova *intel_alloc_iova(struct device 
> >>*dev,
> >>  static struct dmar_domain *__get_valid_domain_for_dev(struct device *dev)
> >>  {
> >>struct dmar_domain *domain;
> >>+   struct intel_iommu *iommu;
> >>int ret;
> >>
> >>domain = get_domain_for_dev(dev, DEFAULT_DOMAIN_ADDRESS_WIDTH);
> >>@@ -3124,14 +3128,30 @@ static struct dmar_domain 
> >>*__get_valid_domain_for_dev(struct device *dev)
> >>return NULL;
> >>}
> >>
> >>-   /* make sure context mapping is ok */
> >>-   if (unlikely(!domain_context_mapped(dev))) {
> >>-   ret = domain_context_mapping(domain, dev, 
> >>CONTEXT_TT_MULTI_LEVEL);
> >>-   if (ret) {
> >>-   printk(KERN_ERR "Domain context map for %s failed",
> >>-  dev_name(dev));
> >>-   return NULL;
> >>-   }
> >>+   /* if in kdump kernel, we need to unmap the mapped dma pages,
> >>+* detach this device first.
> >>+*/
> >>+   if (likely(domain_context_mapped(dev))) {
> >>+   iommu = domain_get_iommu(domain);
> >>+   if (iommu->pre_enabled_trans) {
> >>+   unmap_device_dma(domain, dev, iommu);
> >>+
> >>+   domain = get_domain_for_dev(dev,
> >>+   DEFAULT_DOMAIN_ADDRESS_WIDTH);
> >>+   if (!domain) {
> >>+   pr_err("Allocating domain for %s failed",
> >>+  dev_name(dev));
> >>+   return NULL;
> >>+   }
> >>+   } else
> >>+   return domain;
> >>+   }
> >>+
> >>+   ret = domain_context_mapping(domain, dev, CONTEXT_TT_MULTI_LEVEL);
> >>+   if (ret) {
> >>+   pr_err("Domain context map for %s failed",
> >>+  dev_name(dev));
> >>+   return NULL;
> >>}
> >>
> >>return domain;
> >>@@ -5168,6 +5188,28 @@ static int 
> >>intel_iommu_load_translation_tables(struct intel_iommu *iommu)
> >>return ret;
> >>  }
> >>
> >>+static void unmap_device_dma(struct dmar_domain *domain,
> >>+   struct device *dev,
> >>+   struct intel_iommu *iommu)
> >>+{
> >>+   struct context_entry *ce;
> >>+   struct iova *iova;
> >>+   phys_addr_t phys_addr;
> >>+   dma_addr_t dev_addr;
> >>+   struct pci_dev *pdev;
> >>+
> >>+   pdev = to_pci_dev(dev);
> >>+   ce = iommu_context_addr(iommu, pdev->bus->number, pdev->devfn, 1);
> >>+   phys_addr = context_address_root(ce) << VTD_PAGE_SHIFT;
> >>+   dev_addr = phys_to_dma(dev, phys_addr);
> >>+
> >>+   iova = find_iova(&domain->iovad, IOVA_PFN(dev_addr));
> >>+   if (iova)
> >>+   intel_unmap(dev, dev_addr);
> >>+
> >>+   domain_remove_one_dev_info(domain, dev);
> >>+}
> >>+
> >>  static void iommu_check_pre_te_status(struct intel_iommu *iommu)
> >>  {
> >>u32 sts;
> >>--
> >>2.0.0-rc0
> >>
> 
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the F

Re: [PATCH v9 3/5] crypto: drbg - add async seeding operation

2015-05-20 Thread Stephan Mueller
Am Donnerstag, 21. Mai 2015, 14:36:18 schrieb Herbert Xu:

Hi Herbert,

>On Thu, May 21, 2015 at 08:10:13AM +0200, Stephan Mueller wrote:
>> The cancel operation is needed as otherwise my drbg context handle will be
>> removed by the crypto API during the sleep. That is the whole reason why
>> wait_event_interruptible is used.
>> 
>> So, even when using an uninterruptible sleep, the crypto API has no
>> knowledge about it and I have to serialize the destruction code path with
>> the async callback.
>
>I understand.  But if you use the uniterruptible version at least
>you won't have to deal with bogus early returns.

Thank you for pointing that out - I have seen that too. But the crux is that 
when using wait_event, the cancel function to serialize the destruction code 
path will *not* return at all, even when the async callback function completed 
successfully. Hence the choice for wait_event_interruptible
>
>The cancel by itself will *not* cause wait_event_interruptible
>to return early.  Somebody has to send it a signal for that to
>happen.

Correct. But I can only wake it up with a handle on urandom_init_wait on which 
the wait sleeps. That handle lives in random.c. So, to wake it up, I need 
another piece of code in random.c. That piece of code used to be the 
get_blocking_random_bytes_cancel function I offered in previous patches.

As Ted mentioned, he did not want to much code in random.c for this. In 
addition, if I understand you correctly in previous emails, it would be 
acceptable to wait until the callback was triggered (and thus causing the 
caller module to be not unloadable for that period of time.


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


Aw: Re: [PATCH v1] ARM: dts: nitrogen6x: add CAN support

2015-05-20 Thread Peter Seiderer
Hello Fabio,

> Gesendet: Donnerstag, 21. Mai 2015 um 00:26 Uhr
> Von: "Fabio Estevam" 
> An: "Peter Seiderer" 
> Cc: linux-kernel , "Mark Rutland" 
> , "devicet...@vger.kernel.org" 
> , "Russell King" , "Pawel 
> Moll" , "Ian Campbell" , 
> "Rob Herring" , "Sascha Hauer" , 
> "Kumar Gala" , "Shawn Guo" , 
> "linux-arm-ker...@lists.infradead.org" 
> Betreff: Re: [PATCH v1] ARM: dts: nitrogen6x: add CAN support
>
> On Wed, May 20, 2015 at 6:49 PM, Peter Seiderer  wrote:
> 
> > +   pinctrl_can1_1: can1grp-1 {
> > +   fsl,pins = <
> > +   MX6QDL_PAD_KEY_COL2__FLEXCAN1_TX 0x8000
> > +   MX6QDL_PAD_KEY_ROW2__FLEXCAN1_RX 0x8000
> 
> Better not to pass 0x8000. Use the real PAD settings instead.
> 

Thanks for review, will fix it...

Regards,
Peter
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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: blktrans: change blktrans_getgeo rerurn value

2015-05-20 Thread Wenlin Kang

On 2015年05月21日 03:47, nick wrote:


On 2015-05-20 03:33 PM, Brian Norris wrote:

Hi Wenlin,

In the subject:

s/rerurn/return/


   Thanks for pointing out this, I will modify it.



On Wed, May 13, 2015 at 02:29:16PM +0800, Wenlin Kang wrote:

Modify function blktrans_getgeo()'s return value to -ENXIO when
dev->tr->getgeo == NULL.

We shouldn't make the return value to 0 when dev->tr->getgeo == NULL,
because the function blktrans_getgeo() has an output value "hd_geometry"
which is usually used by some application, if return 0, it will make some
application get the wrong information.

Signed-off-by: Wenlin Kang 
---
  drivers/mtd/mtd_blkdevs.c |2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/mtd/mtd_blkdevs.c b/drivers/mtd/mtd_blkdevs.c
index 2b0c5287..f8bb16e 100644
--- a/drivers/mtd/mtd_blkdevs.c
+++ b/drivers/mtd/mtd_blkdevs.c
@@ -273,7 +273,7 @@ static int blktrans_getgeo(struct block_device *bdev, 
struct hd_geometry *geo)
if (!dev->mtd)
goto unlock;
  
-	ret = dev->tr->getgeo ? dev->tr->getgeo(dev, geo) : 0;

+   ret = dev->tr->getgeo ? dev->tr->getgeo(dev, geo) : -ENXIO;

Good catch. I don't think ENXIO is correct in this case, though. Maybe
-EOPNOTSUPP or -ENOSYS? The latter might make more sense I guess.


I would recommend -EOPNOTSUPP as this as nothing to do with unimplemented
functions or hardware support. This is just unsupported due to the value
being NULL and therefore the hardware support is not there.
Just My Option,
Nick


As you said, -EOPNOTSUPP might be better,thanks.


Hi Brian

I have remade the patch and attached it, would you please check it 
again? thanks.




  unlock:
mutex_unlock(&dev->lock);
blktrans_dev_put(dev);

Thanks,
Brian

__
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/






--
Thanks,
Wenlin Kang

>From d8fa6589438a6992ed13b91c0124ed6cd8114eff Mon Sep 17 00:00:00 2001
From: Wenlin Kang 
Date: Thu, 21 May 2015 14:11:58 +0800
Subject: [PATCH] mtd: blktrans: change blktrans_getgeo return value

Modify function blktrans_getgeo()'s return value to -EOPNOTSUPP when
dev->tr->getgeo == NULL.

We shouldn't make the return value to 0 when dev->tr->getgeo == NULL,
because the function blktrans_getgeo() has an output value "hd_geometry"
which is usually used by some application, if return 0, it will make some
application get the wrong information.

Signed-off-by: Wenlin Kang 
---
 drivers/mtd/mtd_blkdevs.c |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/mtd/mtd_blkdevs.c b/drivers/mtd/mtd_blkdevs.c
index 2b0c5287..2012216 100644
--- a/drivers/mtd/mtd_blkdevs.c
+++ b/drivers/mtd/mtd_blkdevs.c
@@ -273,7 +273,7 @@ static int blktrans_getgeo(struct block_device *bdev, struct hd_geometry *geo)
 	if (!dev->mtd)
 		goto unlock;
 
-	ret = dev->tr->getgeo ? dev->tr->getgeo(dev, geo) : 0;
+	ret = dev->tr->getgeo ? dev->tr->getgeo(dev, geo) : -EOPNOTSUPP;
 unlock:
 	mutex_unlock(&dev->lock);
 	blktrans_dev_put(dev);
-- 
1.7.9.5



[PATCH V5 11/13] selftests, powerpc: Add test for all DSCR sysfs interfaces

2015-05-20 Thread Anshuman Khandual
This test continuously updates the system wide DSCR default value
in the sysfs interface and makes sure that the same is reflected
across all the sysfs interfaces for each individual CPUs present
on the system.

Acked-by: Shuah Khan 
Signed-off-by: Anshuman Khandual 
---
 tools/testing/selftests/powerpc/dscr/Makefile  |  3 +-
 .../selftests/powerpc/dscr/dscr_sysfs_test.c   | 98 ++
 2 files changed, 100 insertions(+), 1 deletion(-)
 create mode 100644 tools/testing/selftests/powerpc/dscr/dscr_sysfs_test.c

diff --git a/tools/testing/selftests/powerpc/dscr/Makefile 
b/tools/testing/selftests/powerpc/dscr/Makefile
index 4e84309..fada526 100644
--- a/tools/testing/selftests/powerpc/dscr/Makefile
+++ b/tools/testing/selftests/powerpc/dscr/Makefile
@@ -1,5 +1,6 @@
 PROGS := dscr_default_test dscr_explicit_test dscr_user_test   \
-dscr_inherit_test dscr_inherit_exec_test
+dscr_inherit_test dscr_inherit_exec_test   \
+dscr_sysfs_test
 
 CFLAGS := $(CFLAGS) -lpthread
 
diff --git a/tools/testing/selftests/powerpc/dscr/dscr_sysfs_test.c 
b/tools/testing/selftests/powerpc/dscr/dscr_sysfs_test.c
new file mode 100644
index 000..f7082ce
--- /dev/null
+++ b/tools/testing/selftests/powerpc/dscr/dscr_sysfs_test.c
@@ -0,0 +1,98 @@
+/*
+ * POWER Data Stream Control Register (DSCR) sysfs interface test
+ *
+ * This test updates to system wide DSCR default through the sysfs interface
+ * and then verifies that all the CPU specific DSCR defaults are updated as
+ * well verified from their sysfs interfaces.
+ *
+ * Copyright (C) 2015 Anshuman Khandual , IBM
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License
+ * as published by the Free Software Foundation; either version
+ * 2 of the License, or (at your option) any later version.
+ */
+#include "dscr.h"
+
+static int check_cpu_dscr_default(char *file, unsigned long val)
+{
+   char buf[10];
+   int fd, rc;
+
+   fd = open(file, O_RDWR);
+   if (fd == -1) {
+   perror("open() failed");
+   return 1;
+   }
+
+   rc = read(fd, buf, sizeof(buf));
+   if (rc == -1) {
+   perror("read() failed");
+   return 1;
+   }
+   close(fd);
+
+   buf[rc] = '\0';
+   if (strtol(buf, NULL, 16) != val) {
+   printf("DSCR match failed: %ld (system) %ld (cpu)\n",
+   val, strtol(buf, NULL, 16));
+   return 1;
+   }
+   return 0;
+}
+
+static int check_all_cpu_dscr_defaults(unsigned long val)
+{
+   DIR *sysfs;
+   struct dirent *dp;
+   char file[LEN_MAX];
+
+   sysfs = opendir(CPU_PATH);
+   if (!sysfs) {
+   perror("opendir() failed");
+   return 1;
+   }
+
+   while ((dp = readdir(sysfs))) {
+   if (!(dp->d_type & DT_DIR))
+   continue;
+   if (!strcmp(dp->d_name, "cpuidle"))
+   continue;
+   if (!strstr(dp->d_name, "cpu"))
+   continue;
+
+   sprintf(file, "%s%s/dscr", CPU_PATH, dp->d_name);
+   if (access(file, F_OK))
+   continue;
+
+   if (check_cpu_dscr_default(file, val))
+   return 1;
+   }
+   closedir(sysfs);
+   return 0;
+}
+
+int dscr_sysfs(void)
+{
+   unsigned long orig_dscr_default;
+   int i, j;
+
+   orig_dscr_default = get_default_dscr();
+   for (i = 0; i < COUNT; i++) {
+   for (j = 0; j < DSCR_MAX; j++) {
+   set_default_dscr(j);
+   if (check_all_cpu_dscr_defaults(j))
+   goto fail;
+   }
+   }
+   set_default_dscr(orig_dscr_default);
+   return 0;
+fail:
+   set_default_dscr(orig_dscr_default);
+   return 1;
+}
+
+int main(int argc, char *argv[])
+{
+   return test_harness(dscr_sysfs, "dscr_sysfs_test");
+}
-- 
2.1.0

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


[PATCH V5 06/13] selftests, powerpc: Add test for system wide DSCR default

2015-05-20 Thread Anshuman Khandual
This patch adds a test case for the system wide DSCR default
value, which when changed through it's sysfs interface must
be visible to all threads reading DSCR either through the
privilege state SPR or the problem state SPR. The DSCR value
change should be immediate as well.

Acked-by: Shuah Khan 
Signed-off-by: Anshuman Khandual 
Signed-off-by: Anton Blanchard 
---
 tools/testing/selftests/powerpc/Makefile   |   2 +-
 tools/testing/selftests/powerpc/dscr/Makefile  |  17 +++
 tools/testing/selftests/powerpc/dscr/dscr.h| 128 +
 .../selftests/powerpc/dscr/dscr_default_test.c | 128 +
 4 files changed, 274 insertions(+), 1 deletion(-)
 create mode 100644 tools/testing/selftests/powerpc/dscr/Makefile
 create mode 100644 tools/testing/selftests/powerpc/dscr/dscr.h
 create mode 100644 tools/testing/selftests/powerpc/dscr/dscr_default_test.c

diff --git a/tools/testing/selftests/powerpc/Makefile 
b/tools/testing/selftests/powerpc/Makefile
index 5ad0423..03ca2e6 100644
--- a/tools/testing/selftests/powerpc/Makefile
+++ b/tools/testing/selftests/powerpc/Makefile
@@ -12,7 +12,7 @@ CFLAGS := -Wall -O2 -flto -Wall -Werror 
-DGIT_VERSION='"$(GIT_VERSION)"' -I$(CUR
 
 export CFLAGS
 
-SUB_DIRS = pmu copyloops mm tm primitives stringloops vphn switch_endian
+SUB_DIRS = pmu copyloops mm tm primitives stringloops vphn switch_endian dscr
 
 endif
 
diff --git a/tools/testing/selftests/powerpc/dscr/Makefile 
b/tools/testing/selftests/powerpc/dscr/Makefile
new file mode 100644
index 000..0aa90ab
--- /dev/null
+++ b/tools/testing/selftests/powerpc/dscr/Makefile
@@ -0,0 +1,17 @@
+PROGS := dscr_default_test
+
+CFLAGS := $(CFLAGS) -lpthread
+
+all: $(PROGS)
+
+$(PROGS): ../harness.c
+
+run_tests: all
+   @-for PROG in $(PROGS); do \
+   ./$$PROG; \
+   done;
+
+clean:
+   rm -f $(PROGS) *.o
+
+.PHONY: all run_tests clean
diff --git a/tools/testing/selftests/powerpc/dscr/dscr.h 
b/tools/testing/selftests/powerpc/dscr/dscr.h
new file mode 100644
index 000..c98622c
--- /dev/null
+++ b/tools/testing/selftests/powerpc/dscr/dscr.h
@@ -0,0 +1,128 @@
+/*
+ * POWER Data Stream Control Register (DSCR)
+ *
+ * This header file contains helper functions and macros
+ * required for all the DSCR related test cases.
+ *
+ * Copyright (C) 2012 Anton Blanchard , IBM
+ * Copyright (C) 2015 Anshuman Khandual , IBM
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License
+ * as published by the Free Software Foundation; either version
+ * 2 of the License, or (at your option) any later version.
+ */
+#ifndef _SELFTESTS_POWERPC_DSCR_DSCR_H
+#define _SELFTESTS_POWERPC_DSCR_DSCR_H
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include "utils.h"
+
+#define SPRN_DSCR  0x11/* Privilege state SPR */
+#define SPRN_DSCR_USR  0x03/* Problem state SPR */
+#define THREADS100 /* Max threads */
+#define COUNT  100 /* Max iterations */
+#define DSCR_MAX   16  /* Max DSCR value */
+#define LEN_MAX100 /* Max name length */
+
+#define DSCR_DEFAULT   "/sys/devices/system/cpu/dscr_default"
+#define CPU_PATH   "/sys/devices/system/cpu/"
+
+#define rmb()  asm volatile("lwsync":::"memory")
+#define wmb()  asm volatile("lwsync":::"memory")
+
+#define ACCESS_ONCE(x) (*(volatile typeof(x) *)&(x))
+
+/* Prilvilege state DSCR access */
+inline unsigned long get_dscr(void)
+{
+   unsigned long ret;
+
+   asm volatile("mfspr %0,%1" : "=r" (ret): "i" (SPRN_DSCR));
+
+   return ret;
+}
+
+inline void set_dscr(unsigned long val)
+{
+   asm volatile("mtspr %1,%0" : : "r" (val), "i" (SPRN_DSCR));
+}
+
+/* Problem state DSCR access */
+inline unsigned long get_dscr_usr(void)
+{
+   unsigned long ret;
+
+   asm volatile("mfspr %0,%1" : "=r" (ret): "i" (SPRN_DSCR_USR));
+
+   return ret;
+}
+
+inline void set_dscr_usr(unsigned long val)
+{
+   asm volatile("mtspr %1,%0" : : "r" (val), "i" (SPRN_DSCR_USR));
+}
+
+/* Default DSCR access */
+unsigned long get_default_dscr(void)
+{
+   int fd = -1, ret;
+   char buf[16];
+   unsigned long val;
+
+   if (fd == -1) {
+   fd = open(DSCR_DEFAULT, O_RDONLY);
+   if (fd == -1) {
+   perror("open() failed");
+   exit(1);
+   }
+   }
+   memset(buf, 0, sizeof(buf));
+   lseek(fd, 0, SEEK_SET);
+   ret = read(fd, buf, sizeof(buf));
+   if (ret == -1) {
+   perror("read() failed");
+   exit(1);
+   }
+   sscanf(buf, "%lx", &val);
+   close(fd);
+   return val;
+}
+
+void set_default_dscr(unsigned long val)
+{
+   int fd = -1, ret;
+   char buf[16];
+
+   if (fd == -1) {
+   fd = open(DSCR_DEFAULT, O_RDWR);
+   if

[PATCH V5 12/13] selftests, powerpc: Add thread based stress test for DSCR sysfs interfaces

2015-05-20 Thread Anshuman Khandual
This patch adds a test to update the system wide DSCR value repeatedly
and then verifies that any thread on any given CPU on the system must
be able to see the same DSCR value whether its is being read through
the problem state based SPR or the privilege state based SPR.

Acked-by: Shuah Khan 
Signed-off-by: Anshuman Khandual 
---
 tools/testing/selftests/powerpc/dscr/Makefile  |   2 +-
 .../powerpc/dscr/dscr_sysfs_thread_test.c  | 123 +
 2 files changed, 124 insertions(+), 1 deletion(-)
 create mode 100644 
tools/testing/selftests/powerpc/dscr/dscr_sysfs_thread_test.c

diff --git a/tools/testing/selftests/powerpc/dscr/Makefile 
b/tools/testing/selftests/powerpc/dscr/Makefile
index fada526..834ef88 100644
--- a/tools/testing/selftests/powerpc/dscr/Makefile
+++ b/tools/testing/selftests/powerpc/dscr/Makefile
@@ -1,6 +1,6 @@
 PROGS := dscr_default_test dscr_explicit_test dscr_user_test   \
 dscr_inherit_test dscr_inherit_exec_test   \
-dscr_sysfs_test
+dscr_sysfs_test dscr_sysfs_thread_test
 
 CFLAGS := $(CFLAGS) -lpthread
 
diff --git a/tools/testing/selftests/powerpc/dscr/dscr_sysfs_thread_test.c 
b/tools/testing/selftests/powerpc/dscr/dscr_sysfs_thread_test.c
new file mode 100644
index 000..bf4a8a6
--- /dev/null
+++ b/tools/testing/selftests/powerpc/dscr/dscr_sysfs_thread_test.c
@@ -0,0 +1,123 @@
+/*
+ * POWER Data Stream Control Register (DSCR) sysfs thread test
+ *
+ * This test updates the system wide DSCR default value through
+ * sysfs interface which should then update all the CPU specific
+ * DSCR default values which must also be then visible to threads
+ * executing on individual CPUs on the system.
+ *
+ * Copyright (C) 2015 Anshuman Khandual , IBM
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License
+ * as published by the Free Software Foundation; either version
+ * 2 of the License, or (at your option) any later version.
+ */
+#define _GNU_SOURCE
+#include "dscr.h"
+
+static pthread_mutex_t lock;   /* Pthread lock */
+static cpu_set_t cpuset;   /* Thread cpu set */
+static int target; /* Thread target cpu */
+static unsigned long *result;  /* Thread exit status array */
+
+#define NR_ONLN sysconf(_SC_NPROCESSORS_ONLN)
+
+static void *test_thread_dscr(void *in)
+{
+   unsigned long cur_dscr, cur_dscr_usr;
+   unsigned long val = (unsigned long)in;
+
+   pthread_mutex_lock(&lock);
+   target++;
+   if (target == NR_ONLN)
+   target =  0;
+   CPU_ZERO(&cpuset);
+   CPU_SET(target, &cpuset);
+
+   if (sched_setaffinity(0, sizeof(cpuset), &cpuset)) {
+   perror("sched_setaffinity() failed");
+   pthread_mutex_unlock(&lock);
+   result[target] = 1;
+   pthread_exit(&result[target]);
+   }
+   pthread_mutex_unlock(&lock);
+
+   cur_dscr = get_dscr();
+   cur_dscr_usr = get_dscr_usr();
+
+   if (val != cur_dscr) {
+   printf("[cpu %d] Kernel DSCR should be %ld but is %ld\n",
+   sched_getcpu(), val, cur_dscr);
+   result[target] = 1;
+   pthread_exit(&result[target]);
+   }
+
+   if (val != cur_dscr_usr) {
+   printf("[cpu %d] User DSCR should be %ld but is %ld\n",
+   sched_getcpu(), val, cur_dscr_usr);
+   result[target] = 1;
+   pthread_exit(&result[target]);
+   }
+   result[target] = 0;
+   pthread_exit(&result[target]);
+}
+
+static int check_cpu_dscr_thread(unsigned long val)
+{
+   pthread_t threads[NR_ONLN];
+   unsigned long *status[NR_ONLN];
+   unsigned long i;
+
+   for (i = 0; i < NR_ONLN; i++) {
+   if (pthread_create(&threads[i], NULL,
+   test_thread_dscr, (void *)val)) {
+   perror("pthread_create() failed");
+   return 1;
+   }
+   }
+
+   for (i = 0; i < NR_ONLN; i++) {
+   if (pthread_join(threads[i], (void **)&(status[i]))) {
+   perror("pthread_join() failed");
+   return 1;
+   }
+
+   if (*status[i]) {
+   printf(" %ldth thread join failed with %ld\n",
+   i, *status[i]);
+   return 1;
+   }
+   }
+   return 0;
+}
+
+int dscr_sysfs_thread(void)
+{
+   unsigned long orig_dscr_default;
+   int i, j;
+
+   result = malloc(sizeof(unsigned long) * NR_ONLN);
+   pthread_mutex_init(&lock, NULL);
+   target = 0;
+   orig_dscr_default = get_default_dscr();
+   for (i = 0; i < COUNT; i++) {
+   for (j = 0; j < DSCR_MAX; j++) {
+   set_default_dscr(j);
+   if (check_cpu_dsc

[PATCH V5 07/13] selftests, powerpc: Add test for explicitly changing DSCR value

2015-05-20 Thread Anshuman Khandual
This patch adds a test which modifies the DSCR using mtspr instruction
and verifies the change using mfspr instruction. It uses both the
privilege state SPR as well as the problem state SPR for the purpose.

Acked-by: Shuah Khan 
Signed-off-by: Anshuman Khandual 
Signed-off-by: Anton Blanchard 
---
 tools/testing/selftests/powerpc/dscr/Makefile  |  2 +-
 .../selftests/powerpc/dscr/dscr_explicit_test.c| 72 ++
 2 files changed, 73 insertions(+), 1 deletion(-)
 create mode 100644 tools/testing/selftests/powerpc/dscr/dscr_explicit_test.c

diff --git a/tools/testing/selftests/powerpc/dscr/Makefile 
b/tools/testing/selftests/powerpc/dscr/Makefile
index 0aa90ab..aede453 100644
--- a/tools/testing/selftests/powerpc/dscr/Makefile
+++ b/tools/testing/selftests/powerpc/dscr/Makefile
@@ -1,4 +1,4 @@
-PROGS := dscr_default_test
+PROGS := dscr_default_test dscr_explicit_test
 
 CFLAGS := $(CFLAGS) -lpthread
 
diff --git a/tools/testing/selftests/powerpc/dscr/dscr_explicit_test.c 
b/tools/testing/selftests/powerpc/dscr/dscr_explicit_test.c
new file mode 100644
index 000..a0fe368
--- /dev/null
+++ b/tools/testing/selftests/powerpc/dscr/dscr_explicit_test.c
@@ -0,0 +1,72 @@
+/*
+ * POWER Data Stream Control Register (DSCR) explicit test
+ *
+ * This test modifies the DSCR value using mtspr instruction and
+ * verifies the change with mfspr instruction. It uses both the
+ * privilege state SPR and the problem state SPR for this purpose.
+ *
+ * When using the privilege state SPR, the instructions such as
+ * mfspr or mtspr are priviledged and the kernel emulates them
+ * for us. Instructions using problem state SPR can be exuecuted
+ * directly without any emulation if the HW supports them. Else
+ * they also get emulated by the kernel.
+ *
+ * Copyright (C) 2012 Anton Blanchard , IBM
+ * Copyright (C) 2015 Anshuman Khandual , IBM
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License
+ * as published by the Free Software Foundation; either version
+ * 2 of the License, or (at your option) any later version.
+ */
+#include "dscr.h"
+
+int dscr_explicit(void)
+{
+   unsigned long i, dscr = 0;
+
+   srand(getpid());
+   set_dscr(dscr);
+
+   for (i = 0; i < COUNT; i++) {
+   unsigned long cur_dscr, cur_dscr_usr;
+   double ret = uniform_deviate(rand());
+
+   if (ret < 0.001) {
+   dscr++;
+   if (dscr > DSCR_MAX)
+   dscr = 0;
+
+   set_dscr(dscr);
+   }
+
+   cur_dscr = get_dscr();
+   if (cur_dscr != dscr) {
+   fprintf(stderr, "Kernel DSCR should be %ld but "
+   "is %ld\n", dscr, cur_dscr);
+   return 1;
+   }
+
+   ret = uniform_deviate(rand());
+   if (ret < 0.001) {
+   dscr++;
+   if (dscr > DSCR_MAX)
+   dscr = 0;
+
+   set_dscr_usr(dscr);
+   }
+
+   cur_dscr_usr = get_dscr_usr();
+   if (cur_dscr_usr != dscr) {
+   fprintf(stderr, "User DSCR should be %ld but "
+   "is %ld\n", dscr, cur_dscr_usr);
+   return 1;
+   }
+   }
+   return 0;
+}
+
+int main(int argc, char *argv[])
+{
+   return test_harness(dscr_explicit, "dscr_explicit_test");
+}
-- 
2.1.0

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


[PATCH V5 08/13] selftests, powerpc: Add test for DSCR SPR numbers

2015-05-20 Thread Anshuman Khandual
This patch adds a test which verifies that the DSCR privilege and
problem state SPR read & write accesses while making sure that the
results are always the same irrespective of which SPR number is
being used.

Acked-by: Shuah Khan 
Signed-off-by: Anshuman Khandual 
Signed-off-by: Anton Blanchard 
---
 tools/testing/selftests/powerpc/dscr/Makefile  |  2 +-
 .../selftests/powerpc/dscr/dscr_user_test.c| 62 ++
 2 files changed, 63 insertions(+), 1 deletion(-)
 create mode 100644 tools/testing/selftests/powerpc/dscr/dscr_user_test.c

diff --git a/tools/testing/selftests/powerpc/dscr/Makefile 
b/tools/testing/selftests/powerpc/dscr/Makefile
index aede453..ae865d8 100644
--- a/tools/testing/selftests/powerpc/dscr/Makefile
+++ b/tools/testing/selftests/powerpc/dscr/Makefile
@@ -1,4 +1,4 @@
-PROGS := dscr_default_test dscr_explicit_test
+PROGS := dscr_default_test dscr_explicit_test dscr_user_test
 
 CFLAGS := $(CFLAGS) -lpthread
 
diff --git a/tools/testing/selftests/powerpc/dscr/dscr_user_test.c 
b/tools/testing/selftests/powerpc/dscr/dscr_user_test.c
new file mode 100644
index 000..c23c2f3
--- /dev/null
+++ b/tools/testing/selftests/powerpc/dscr/dscr_user_test.c
@@ -0,0 +1,62 @@
+/*
+ * POWER Data Stream Control Register (DSCR) SPR test
+ *
+ * This test modifies the DSCR value through both the SPR number
+ * based mtspr instruction and then makes sure that the same is
+ * reflected through mfspr instruction using either of the SPR
+ * numbers.
+ *
+ * When using the privilege state SPR, the instructions such as
+ * mfspr or mtspr are priviledged and the kernel emulates them
+ * for us. Instructions using problem state SPR can be exuecuted
+ * directly without any emulation if the HW supports them. Else
+ * they also get emulated by the kernel.
+ *
+ * Copyright (C) 2013 Anton Blanchard , IBM
+ * Copyright (C) 2015 Anshuman Khandual , IBM
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License
+ * as published by the Free Software Foundation; either version
+ * 2 of the License, or (at your option) any later version.
+ */
+#include "dscr.h"
+
+static int check_dscr(char *str)
+{
+   unsigned long cur_dscr, cur_dscr_usr;
+
+   cur_dscr = get_dscr();
+   cur_dscr_usr = get_dscr_usr();
+   if (cur_dscr != cur_dscr_usr) {
+   printf("%s set, kernel get %lx != user get %lx\n",
+   str, cur_dscr, cur_dscr_usr);
+   return 1;
+   }
+   return 0;
+}
+
+int dscr_user(void)
+{
+   int i;
+
+   check_dscr("");
+
+   for (i = 0; i < COUNT; i++) {
+   set_dscr(i);
+   if (check_dscr("kernel"))
+   return 1;
+   }
+
+   for (i = 0; i < COUNT; i++) {
+   set_dscr_usr(i);
+   if (check_dscr("user"))
+   return 1;
+   }
+   return 0;
+}
+
+int main(int argc, char *argv[])
+{
+   return test_harness(dscr_user, "dscr_user_test");
+}
-- 
2.1.0

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


[PATCH V5 02/13] powerpc, process: Remove the unused extern dscr_default

2015-05-20 Thread Anshuman Khandual
The process context switch code no longer uses dscr_default variable
from the sysfs.c file. The variable became unused when we started
storing the CPU specific DSCR value in the PACA structure instead.
This patch just removes this extern declaration. It was originally
added by the following commit.

efcac658: powerpc: Per process DSCR + some fixes (try#4)

Signed-off-by: Anshuman Khandual 
---
 arch/powerpc/kernel/process.c | 1 -
 1 file changed, 1 deletion(-)

diff --git a/arch/powerpc/kernel/process.c b/arch/powerpc/kernel/process.c
index febb50d..8005e18 100644
--- a/arch/powerpc/kernel/process.c
+++ b/arch/powerpc/kernel/process.c
@@ -1112,7 +1112,6 @@ static void setup_ksp_vsid(struct task_struct *p, 
unsigned long sp)
 /*
  * Copy a thread..
  */
-extern unsigned long dscr_default; /* defined in arch/powerpc/kernel/sysfs.c */
 
 /*
  * Copy architecture-specific thread state
-- 
2.1.0

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


[PATCH V5 00/13] POWER DSCR fixes, improvements, docs and tests

2015-05-20 Thread Anshuman Khandual
This patch series has patches for POWER DSCR fixes, improvements,
in code documentaion, kernel support user documentation and selftest based
test cases. It has got five test cases which are derived from Anton's DSCR
test bucket which can be listed as follows.

(1) http://ozlabs.org/~anton/junkcode/dscr_default_test.c
(2) http://ozlabs.org/~anton/junkcode/dscr_explicit_test.c
(3) http://ozlabs.org/~anton/junkcode/dscr_inherit_exec_test.c
(4) http://ozlabs.org/~anton/junkcode/dscr_inherit_test.c
(5) http://ozlabs.org/~anton/junkcode/user_dscr_test.c

NOTE1: Anton's original inherit exec test expected the child to have
system default DSCR value instead of the inherited DSCR value from
it's parent. But looks like thats not the case when we execute the
test, it always inherits it's parent's DSCR value over the exec call
as well. So I have changed the test program assuming its correct to
have the inherited DSCR value in the fork/execed child program.
Please let me know if thats not correct and I am missing something
there.

Changes in V5:
-
- Fixed build problem with get_default_dscr/set_default_dscr functions
  by checking on the return values of read & write system calls.

Changes in V4: (https://lkml.org/lkml/2015/5/18/215)
--
- Restoring the system DSCR default value in test cases before exiting
- Removed new-line from all the perror() calls
- Some minor cosmetic changes to the test cases
- Added Anton's SOB to the above mentioned five derived test cases

Changes in V3: (https://lkml.org/lkml/2015/4/10/117)
--
- Minor changes to last couple of sysfs test cases
- Added .gitignore file for the new test directory

Changes in V2: (https://lkml.org/lkml/2015/1/13/148)
-
- Updated the thread struct DSCR value inside mtspr facility exception path
- Modified the in code documentation to follow the kernel-doc format
- Added seven selftest based DSCR related test cases under powerpc

Original V1:

- Posted here at https://patchwork.ozlabs.org/patch/418583/


Anshuman Khandual (13):
  powerpc: Fix handling of DSCR related facility unavailable exception
  powerpc, process: Remove the unused extern dscr_default
  powerpc, offset: Change PACA_DSCR to PACA_DSCR_DEFAULT
  powerpc, dscr: Added some in-code documentation
  documentation, powerpc: Add documentation for DSCR support
  selftests, powerpc: Add test for system wide DSCR default
  selftests, powerpc: Add test for explicitly changing DSCR value
  selftests, powerpc: Add test for DSCR SPR numbers
  selftests, powerpc: Add test for DSCR value inheritence across fork
  selftests, powerpc: Add test for DSCR inheritence across fork & exec
  selftests, powerpc: Add test for all DSCR sysfs interfaces
  selftests, powerpc: Add thread based stress test for DSCR sysfs interfaces
  selftests, powerpc: Add gitignore file for the new DSCR tests

 Documentation/powerpc/00-INDEX |   2 +
 Documentation/powerpc/dscr.txt |  83 +
 arch/powerpc/include/asm/processor.h   |   9 ++
 arch/powerpc/kernel/asm-offsets.c  |   2 +-
 arch/powerpc/kernel/entry_64.S |   2 +-
 arch/powerpc/kernel/process.c  |   1 -
 arch/powerpc/kernel/sysfs.c|  38 ++
 arch/powerpc/kernel/tm.S   |   4 +-
 arch/powerpc/kernel/traps.c|  45 +++-
 arch/powerpc/kvm/book3s_hv_rmhandlers.S|   2 +-
 tools/testing/selftests/powerpc/Makefile   |   2 +-
 tools/testing/selftests/powerpc/dscr/.gitignore|   7 ++
 tools/testing/selftests/powerpc/dscr/Makefile  |  19 +++
 tools/testing/selftests/powerpc/dscr/dscr.h| 128 +
 .../selftests/powerpc/dscr/dscr_default_test.c | 128 +
 .../selftests/powerpc/dscr/dscr_explicit_test.c|  72 
 .../powerpc/dscr/dscr_inherit_exec_test.c  | 118 +++
 .../selftests/powerpc/dscr/dscr_inherit_test.c |  96 
 .../selftests/powerpc/dscr/dscr_sysfs_test.c   |  98 
 .../powerpc/dscr/dscr_sysfs_thread_test.c  | 123 
 .../selftests/powerpc/dscr/dscr_user_test.c|  62 ++
 21 files changed, 1029 insertions(+), 12 deletions(-)
 create mode 100644 Documentation/powerpc/dscr.txt
 create mode 100644 tools/testing/selftests/powerpc/dscr/.gitignore
 create mode 100644 tools/testing/selftests/powerpc/dscr/Makefile
 create mode 100644 tools/testing/selftests/powerpc/dscr/dscr.h
 create mode 100644 tools/testing/selftests/powerpc/dscr/dscr_default_test.c
 create mode 100644 tools/testing/selftests/powerpc/dscr/dscr_explicit_test.c
 create mode 100644 
tools/testing/selftests/powerpc/dscr/dscr_inherit_exec_test.c
 create mode 100644 tools/testing/selftests/powerpc/dscr/dscr_inherit_test.c
 create mode 100644 tools/testing/selftests/powerpc/dscr/dscr_sysfs_

[PATCH V5 05/13] documentation, powerpc: Add documentation for DSCR support

2015-05-20 Thread Anshuman Khandual
This patch adds a new documentation file explaining the DSCR
support on powerpc platforms. This explains DSCR related data
structure, code paths and also available user interfaces. Any
further functional changes to the DSCR support in the kernel
should definitely update the documentation here.

Signed-off-by: Anshuman Khandual 
---
 Documentation/powerpc/00-INDEX |  2 +
 Documentation/powerpc/dscr.txt | 83 ++
 2 files changed, 85 insertions(+)
 create mode 100644 Documentation/powerpc/dscr.txt

diff --git a/Documentation/powerpc/00-INDEX b/Documentation/powerpc/00-INDEX
index 6fd0e8b..9dc845c 100644
--- a/Documentation/powerpc/00-INDEX
+++ b/Documentation/powerpc/00-INDEX
@@ -30,3 +30,5 @@ ptrace.txt
- Information on the ptrace interfaces for hardware debug registers.
 transactional_memory.txt
- Overview of the Power8 transactional memory support.
+dscr.txt
+   - Overview DSCR (Data Stream Control Register) support.
diff --git a/Documentation/powerpc/dscr.txt b/Documentation/powerpc/dscr.txt
new file mode 100644
index 000..1ff4400
--- /dev/null
+++ b/Documentation/powerpc/dscr.txt
@@ -0,0 +1,83 @@
+   DSCR (Data Stream Control Register)
+   
+
+DSCR register in powerpc allows user to have some control of prefetch of data
+stream in the processor. Please refer to the ISA documents or related manual
+for more detailed information regarding how to use this DSCR to attain this
+control of the pefetches . This document here provides an overview of kernel
+support for DSCR, related kernel objects, it's functionalities and exported
+user interface.
+
+(A) Data Structures:
+
+   (1) thread_struct:
+   dscr/* Thread DSCR value */
+   dscr_inherit/* Thread has changed default DSCR */
+
+   (2) PACA:
+   dscr_default/* per-CPU DSCR default value */
+
+   (3) sysfs.c:
+   dscr_default/* System DSCR default value */
+
+(B) Scheduler Changes:
+
+   Scheduler will write the per-CPU DSCR default which is stored in the
+   CPU's PACA value into the register if the thread has dscr_inherit value
+   cleared which means that it has not changed the default DSCR till now.
+   If the dscr_inherit value is set which means that it has changed the
+   default DSCR value, scheduler will write the changed value which will
+   now be contained in thread struct's dscr into the register instead of
+   the per-CPU default PACA based DSCR value.
+
+   NOTE: Please note here that the system wide global DSCR value never
+   gets used directly in the scheduler process context switch at all.
+
+(C) SYSFS Interface:
+
+   Global DSCR default:/sys/devices/system/cpu/dscr_default
+   CPU specific DSCR default:  /sys/devices/system/cpu/cpuN/dscr
+
+   Changing the global DSCR default in the sysfs will change all the CPU
+   specific DSCR defaults immediately in their PACA structures. Again if
+   the current process has the dscr_inherit clear, it also writes the new
+   value into every CPU's DSCR register right away and updates the current
+   thread's DSCR value as well.
+
+   Changing the CPU specif DSCR default value in the sysfs does exactly
+   the same thing as above but unlike the global one above, it just changes
+   stuff for that particular CPU instead for all the CPUs on the system.
+
+(D) User Space Instructions:
+
+   The DSCR register can be accessed in the user space using any of these
+   two SPR numbers available for that purpose.
+
+   (1) Problem state SPR:  0x03(Un-privileged, POWER8 only)
+   (2) Privileged state SPR:   0x11(Privileged)
+
+   Accessing DSCR through privileged SPR number (0x11) from user space
+   works, as it is emulated following an illegal instruction exception
+   inside the kernel. Both mfspr and mtspr instructions are emulated.
+
+   Accessing DSCR through user level SPR (0x03) from user space will first
+   create a facility unavailable exception. Inside this exception handler
+   all mfspr isntruction based read attempts will get emulated and returned
+   where as the first mtspr instruction based write attempts will enable
+   the DSCR facility for the next time around (both for read and write) by
+   setting DSCR facility in the FSCR register.
+
+(E) Specifics about 'dscr_inherit':
+
+   The thread struct element 'dscr_inherit' represents whether the thread
+   in question has attempted and changed the DSCR itself using any of the
+   following methods. This element signifies whether the thread wants to
+   use the CPU default DSCR value or its own changed DSCR value in the
+   kernel.
+
+   (1) mtspr instruction   (SPR number 0x03)
+   (2) mtspr instruction   (SPR number

[PATCH V5 04/13] powerpc, dscr: Added some in-code documentation

2015-05-20 Thread Anshuman Khandual
This patch adds some in-code documentation to the DSCR related
code to make it more readable without having any functional
change to it.

Signed-off-by: Anshuman Khandual 
---
 arch/powerpc/include/asm/processor.h |  9 +
 arch/powerpc/kernel/sysfs.c  | 38 
 2 files changed, 47 insertions(+)

diff --git a/arch/powerpc/include/asm/processor.h 
b/arch/powerpc/include/asm/processor.h
index bf117d8..28ded5d 100644
--- a/arch/powerpc/include/asm/processor.h
+++ b/arch/powerpc/include/asm/processor.h
@@ -295,6 +295,15 @@ struct thread_struct {
 #endif
 #ifdef CONFIG_PPC64
unsigned long   dscr;
+   /*
+* This member element dscr_inherit indicates that the process
+* has explicitly attempted and changed the DSCR register value
+* for itself. Hence kernel wont use the default CPU DSCR value
+* contained in the PACA structure anymore during process context
+* switch. Once this variable is set, this behaviour will also be
+* inherited to all the children of this process from that point
+* onwards.
+*/
int dscr_inherit;
unsigned long   ppr;/* used to save/restore SMT priority */
 #endif
diff --git a/arch/powerpc/kernel/sysfs.c b/arch/powerpc/kernel/sysfs.c
index fa1fd8a..692873b 100644
--- a/arch/powerpc/kernel/sysfs.c
+++ b/arch/powerpc/kernel/sysfs.c
@@ -496,13 +496,34 @@ static DEVICE_ATTR(spurr, 0400, show_spurr, NULL);
 static DEVICE_ATTR(purr, 0400, show_purr, store_purr);
 static DEVICE_ATTR(pir, 0400, show_pir, NULL);
 
+/*
+ * This is the system wide DSCR register default value. Any
+ * change to this default value through the sysfs interface
+ * will update all per cpu DSCR default values across the
+ * system stored in their respective PACA structures.
+ */
 static unsigned long dscr_default;
 
+/**
+ * read_dscr() - Fetch the cpu specific DSCR default
+ * @val:   Returned cpu specific DSCR default value
+ *
+ * This function returns the per cpu DSCR default value
+ * for any cpu which is contained in it's PACA structure.
+ */
 static void read_dscr(void *val)
 {
*(unsigned long *)val = get_paca()->dscr_default;
 }
 
+
+/**
+ * write_dscr() - Update the cpu specific DSCR default
+ * @val:   New cpu specific DSCR default value to update
+ *
+ * This function updates the per cpu DSCR default value
+ * for any cpu which is contained in it's PACA structure.
+ */
 static void write_dscr(void *val)
 {
get_paca()->dscr_default = *(unsigned long *)val;
@@ -520,12 +541,29 @@ static void add_write_permission_dev_attr(struct 
device_attribute *attr)
attr->attr.mode |= 0200;
 }
 
+/**
+ * show_dscr_default() - Fetch the system wide DSCR default
+ * @dev:   Device structure
+ * @attr:  Device attribute structure
+ * @buf:   Interface buffer
+ *
+ * This function returns the system wide DSCR default value.
+ */
 static ssize_t show_dscr_default(struct device *dev,
struct device_attribute *attr, char *buf)
 {
return sprintf(buf, "%lx\n", dscr_default);
 }
 
+/**
+ * store_dscr_default() - Update the system wide DSCR default
+ * @dev:   Device structure
+ * @attr:  Device attribute structure
+ * @buf:   Interface buffer
+ * @count: Size of the update
+ *
+ * This function updates the system wide DSCR default value.
+ */
 static ssize_t __used store_dscr_default(struct device *dev,
struct device_attribute *attr, const char *buf,
size_t count)
-- 
2.1.0

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


[PATCH V5 13/13] selftests, powerpc: Add gitignore file for the new DSCR tests

2015-05-20 Thread Anshuman Khandual
This patch adds .gitignore for all the newly added DSCR tests.

Signed-off-by: Anshuman Khandual 
---
 tools/testing/selftests/powerpc/dscr/.gitignore | 7 +++
 1 file changed, 7 insertions(+)
 create mode 100644 tools/testing/selftests/powerpc/dscr/.gitignore

diff --git a/tools/testing/selftests/powerpc/dscr/.gitignore 
b/tools/testing/selftests/powerpc/dscr/.gitignore
new file mode 100644
index 000..b585c6c
--- /dev/null
+++ b/tools/testing/selftests/powerpc/dscr/.gitignore
@@ -0,0 +1,7 @@
+dscr_default_test
+dscr_explicit_test
+dscr_inherit_exec_test
+dscr_inherit_test
+dscr_sysfs_test
+dscr_sysfs_thread_test
+dscr_user_test
-- 
2.1.0

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


Re: [PATCH soc] ARM: use ARM_SINGLE_ARMV7M for ARMv7-M platforms

2015-05-20 Thread Uwe Kleine-König
On Thu, May 21, 2015 at 12:35:44AM +0200, Stefan Agner wrote:
> Use the new config symbol ARM_SINGLE_ARMV7M which groups config
> symbols used by modern ARMv7-M platforms. This allows supporting
> multiple ARMv7-M platforms in one kernel image. However, a common
> kernel image requires the combined platforms to share the same
> main memory layout to be bootable.
> 
> Acked-by: Uwe Kleine-König 
> Signed-off-by: Stefan Agner 
> ---
> Since this is essentially only a shift of config symbols, it
> should not change runtime behavior, at least when selecting
> only one platform.
> 
> Uwe, this is essentially the same I had in my patchset, just
> converting the other platforms too. I was bold and added your
> Ack anyway...
That's fine.

Uwe

-- 
Pengutronix e.K.   | Uwe Kleine-König|
Industrial Linux Solutions | http://www.pengutronix.de/  |
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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: Filesystem corruption MD (imsm) Raid0 via 2 SSD's + discard

2015-05-20 Thread Holger Kiehl

On Thu, 21 May 2015, NeilBrown wrote:


On Thu, 21 May 2015 01:32:13 +0500 Roman Mamedov  wrote:


On Wed, 20 May 2015 20:12:31 + (UTC)
Holger Kiehl  wrote:


The kernel I was running when I discovered the
problem was 4.0.2 from kernel.org. However, after reinstalling from DVD
I updated to Fedora's lattest kernel, which was 3.19.? (I do not remember
the last numbers). So that kernel seems also effected, but I assume it
contains many 'fixes' from 4.0.x. As filesystem I use ext4, distribution
is Fedora 21 and hardware is: Xeon E3-1275, 16GB ECC Ram.

My system seems to be now running stable for some days with kernel.org
kernel 4.0.3 and with discard DISABLED. But I am still unsure what could
be the real cause.


It is a bug in the 4.0.2 kernel, fixed in 4.0.3.

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=785672
https://bbs.archlinux.org/viewtopic.php?id=197400
https://kernel.googlesource.com/pub/scm/linux/kernel/git/stable/linux-stable/+/d2dc317d564a46dfc683978a2e5a4f91434e9711




I suspect that is a different bug.
I think this one is
 https://bugzilla.kernel.org/show_bug.cgi?id=98501


Should there not be a big fat warning going around telling users to disable
discard on Raid 0 until this is fixed? This breaks the filesystem completely
and I believe there is absolutly no way one can get back the data.

Is this fixed in 4.0.4? And which kernels are effected? There could be many
people running systems that have not noticed this and don't know in what
dangerous situation they are when they delete data.

Regards,
Holger
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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 V5 01/13] powerpc: Fix handling of DSCR related facility unavailable exception

2015-05-20 Thread Anshuman Khandual
Currently DSCR (Data Stream Control Register) can be accessed with
mfspr or mtspr instructions inside a thread via two different SPR
numbers. One being the user accessible problem state SPR number 0x03
and the other being the privilege state SPR number 0x11. All access
through the privilege state SPR number get emulated through illegal
instruction exception. Any access through the problem state SPR number
raises one facility unavailable exception which sets the thread based
dscr_inherit bit and enables DSCR facility through FSCR register thus
allowing direct access to DSCR without going through this exception in
the future. We set the thread.dscr_inherit bit whether the access was
with mfspr or mtspr instruction which is neither correct nor does it
match the behaviour through the instruction emulation code path driven
from privilege state SPR number. User currently observes two different
kind of behaviour when accessing the DSCR through these two SPR numbers.
This problem can be observed through these two test cases by replacing
the privilege state SPR number with the problem state SPR number.

(1) http://ozlabs.org/~anton/junkcode/dscr_default_test.c
(2) http://ozlabs.org/~anton/junkcode/dscr_explicit_test.c

This patch fixes the problem by making sure that the behaviour visible
to the user remains the same irrespective of which SPR number is being
used. Inside facility unavailable exception, we check whether it was
cuased by a mfspr or a mtspr isntrucction. In case of mfspr instruction,
just emulate the instruction. In case of mtspr instruction, set the
thread based dscr_inherit bit and also enable the facility through FSCR.
All user SPR based mfspr instruction will be emulated till one user SPR
based mtspr has been executed.

Signed-off-by: Anshuman Khandual 
---
 arch/powerpc/kernel/traps.c | 45 -
 1 file changed, 40 insertions(+), 5 deletions(-)

diff --git a/arch/powerpc/kernel/traps.c b/arch/powerpc/kernel/traps.c
index 19e4744..6530f1b 100644
--- a/arch/powerpc/kernel/traps.c
+++ b/arch/powerpc/kernel/traps.c
@@ -1377,6 +1377,7 @@ void facility_unavailable_exception(struct pt_regs *regs)
};
char *facility = "unknown";
u64 value;
+   u32 instword, rd;
u8 status;
bool hv;
 
@@ -1388,12 +1389,46 @@ void facility_unavailable_exception(struct pt_regs 
*regs)
 
status = value >> 56;
if (status == FSCR_DSCR_LG) {
-   /* User is acessing the DSCR.  Set the inherit bit and allow
-* the user to set it directly in future by setting via the
-* FSCR DSCR bit.  We always leave HFSCR DSCR set.
+   /*
+* User is accessing the DSCR register using the problem
+* state only SPR number (0x03) either through a mfspr or
+* a mtspr instruction. If it is a write attempt through
+* a mtspr, then we set the inherit bit. This also allows
+* the user to write or read the register directly in the
+* future by setting via the FSCR DSCR bit. But in case it
+* is a read DSCR attempt through a mfspr instruction, we
+* just emulate the instruction instead. This code path will
+* always emulate all the mfspr instructions till the user
+* has attempted atleast one mtspr instruction. This way it
+* preserves the same behaviour when the user is accessing
+* the DSCR through privilege level only SPR number (0x11)
+* which is emulated through illegal instruction exception.
+* We always leave HFSCR DSCR set.
 */
-   current->thread.dscr_inherit = 1;
-   mtspr(SPRN_FSCR, value | FSCR_DSCR);
+   if (get_user(instword, (u32 __user *)(regs->nip))) {
+   pr_err("Failed to fetch the user instruction\n");
+   return;
+   }
+
+   /* Write into DSCR (mtspr 0x03, RS) */
+   if ((instword & PPC_INST_MTSPR_DSCR_USER_MASK)
+   == PPC_INST_MTSPR_DSCR_USER) {
+   rd = (instword >> 21) & 0x1f;
+   current->thread.dscr = regs->gpr[rd];
+   current->thread.dscr_inherit = 1;
+   mtspr(SPRN_FSCR, value | FSCR_DSCR);
+   }
+
+   /* Read from DSCR (mfspr RT, 0x03) */
+   if ((instword & PPC_INST_MFSPR_DSCR_USER_MASK)
+   == PPC_INST_MFSPR_DSCR_USER) {
+   if (emulate_instruction(regs)) {
+   pr_err("DSCR based mfspr emulation failed\n");
+   return;
+   }
+   regs->nip += 4;
+   emulate_single_step(regs);
+   }
r

[PATCH V5 10/13] selftests, powerpc: Add test for DSCR inheritence across fork & exec

2015-05-20 Thread Anshuman Khandual
This patch adds a test case to verify that the changed DSCR value
inside any process would be inherited to it's child across the fork
and exec system call.

Acked-by: Shuah Khan 
Signed-off-by: Anshuman Khandual 
Signed-off-by: Anton Blanchard 
---
 tools/testing/selftests/powerpc/dscr/Makefile  |   2 +-
 .../powerpc/dscr/dscr_inherit_exec_test.c  | 118 +
 2 files changed, 119 insertions(+), 1 deletion(-)
 create mode 100644 
tools/testing/selftests/powerpc/dscr/dscr_inherit_exec_test.c

diff --git a/tools/testing/selftests/powerpc/dscr/Makefile 
b/tools/testing/selftests/powerpc/dscr/Makefile
index 81239e2..4e84309 100644
--- a/tools/testing/selftests/powerpc/dscr/Makefile
+++ b/tools/testing/selftests/powerpc/dscr/Makefile
@@ -1,5 +1,5 @@
 PROGS := dscr_default_test dscr_explicit_test dscr_user_test   \
-dscr_inherit_test
+dscr_inherit_test dscr_inherit_exec_test
 
 CFLAGS := $(CFLAGS) -lpthread
 
diff --git a/tools/testing/selftests/powerpc/dscr/dscr_inherit_exec_test.c 
b/tools/testing/selftests/powerpc/dscr/dscr_inherit_exec_test.c
new file mode 100644
index 000..7283954
--- /dev/null
+++ b/tools/testing/selftests/powerpc/dscr/dscr_inherit_exec_test.c
@@ -0,0 +1,118 @@
+/*
+ * POWER Data Stream Control Register (DSCR) fork exec test
+ *
+ * This testcase modifies the DSCR using mtspr, forks & execs and
+ * verifies that the child is using the changed DSCR using mfspr.
+ *
+ * When using the privilege state SPR, the instructions such as
+ * mfspr or mtspr are priviledged and the kernel emulates them
+ * for us. Instructions using problem state SPR can be exuecuted
+ * directly without any emulation if the HW supports them. Else
+ * they also get emulated by the kernel.
+ *
+ * Copyright (C) 2012 Anton Blanchard , IBM
+ * Copyright (C) 2015 Anshuman Khandual , IBM
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License
+ * as published by the Free Software Foundation; either version
+ * 2 of the License, or (at your option) any later version.
+ */
+#include "dscr.h"
+
+static char prog[LEN_MAX];
+
+static void do_exec(unsigned long parent_dscr)
+{
+   unsigned long cur_dscr, cur_dscr_usr;
+
+   cur_dscr = get_dscr();
+   cur_dscr_usr = get_dscr_usr();
+
+   if (cur_dscr != parent_dscr) {
+   fprintf(stderr, "Parent DSCR %ld was not inherited "
+   "over exec (kernel value)\n", parent_dscr);
+   exit(1);
+   }
+
+   if (cur_dscr_usr != parent_dscr) {
+   fprintf(stderr, "Parent DSCR %ld was not inherited "
+   "over exec (user value)\n", parent_dscr);
+   exit(1);
+   }
+   exit(0);
+}
+
+int dscr_inherit_exec(void)
+{
+   unsigned long i, dscr = 0;
+   pid_t pid;
+
+   for (i = 0; i < COUNT; i++) {
+   dscr++;
+   if (dscr > DSCR_MAX)
+   dscr = 0;
+
+   if (dscr == get_default_dscr())
+   continue;
+
+   if (i % 2 == 0)
+   set_dscr_usr(dscr);
+   else
+   set_dscr(dscr);
+
+   /*
+* XXX: Force a context switch out so that DSCR
+* current value is copied into the thread struct
+* which is required for the child to inherit the
+* changed value.
+*/
+   sleep(1);
+
+   pid = fork();
+   if (pid == -1) {
+   perror("fork() failed");
+   exit(1);
+   } else if (pid) {
+   int status;
+
+   if (waitpid(pid, &status, 0) == -1) {
+   perror("waitpid() failed");
+   exit(1);
+   }
+
+   if (!WIFEXITED(status)) {
+   fprintf(stderr, "Child didn't exit cleanly\n");
+   exit(1);
+   }
+
+   if (WEXITSTATUS(status) != 0) {
+   fprintf(stderr, "Child didn't exit cleanly\n");
+   return 1;
+   }
+   } else {
+   char dscr_str[16];
+
+   sprintf(dscr_str, "%ld", dscr);
+   execlp(prog, prog, "exec", dscr_str, NULL);
+   exit(1);
+   }
+   }
+   return 0;
+}
+
+int main(int argc, char *argv[])
+{
+   if (argc == 3 && !strcmp(argv[1], "exec")) {
+   unsigned long parent_dscr;
+
+   parent_dscr = atoi(argv[2]);
+   do_exec(parent_dscr);
+   } else if (argc != 1) {
+   fprintf(stderr, "Usage: %s\n", argv[0]);
+   exit(1);
+   }
+
+   strncpy(prog, 

[PATCH V5 03/13] powerpc, offset: Change PACA_DSCR to PACA_DSCR_DEFAULT

2015-05-20 Thread Anshuman Khandual
PACA_DSCR offset macro tracks dscr_default element in the paca
structure. Better change the name of this macro to match that
of the data element it tracks. Makes the code more readable.

Signed-off-by: Anshuman Khandual 
---
 arch/powerpc/kernel/asm-offsets.c   | 2 +-
 arch/powerpc/kernel/entry_64.S  | 2 +-
 arch/powerpc/kernel/tm.S| 4 ++--
 arch/powerpc/kvm/book3s_hv_rmhandlers.S | 2 +-
 4 files changed, 5 insertions(+), 5 deletions(-)

diff --git a/arch/powerpc/kernel/asm-offsets.c 
b/arch/powerpc/kernel/asm-offsets.c
index 0034b6b..9823057 100644
--- a/arch/powerpc/kernel/asm-offsets.c
+++ b/arch/powerpc/kernel/asm-offsets.c
@@ -247,7 +247,7 @@ int main(void)
 #endif
DEFINE(PACAHWCPUID, offsetof(struct paca_struct, hw_cpu_id));
DEFINE(PACAKEXECSTATE, offsetof(struct paca_struct, kexec_state));
-   DEFINE(PACA_DSCR, offsetof(struct paca_struct, dscr_default));
+   DEFINE(PACA_DSCR_DEFAULT, offsetof(struct paca_struct, dscr_default));
DEFINE(PACA_STARTTIME, offsetof(struct paca_struct, starttime));
DEFINE(PACA_STARTTIME_USER, offsetof(struct paca_struct, 
starttime_user));
DEFINE(PACA_USER_TIME, offsetof(struct paca_struct, user_time));
diff --git a/arch/powerpc/kernel/entry_64.S b/arch/powerpc/kernel/entry_64.S
index afbc200..27e 100644
--- a/arch/powerpc/kernel/entry_64.S
+++ b/arch/powerpc/kernel/entry_64.S
@@ -556,7 +556,7 @@ BEGIN_FTR_SECTION
ld  r0,THREAD_DSCR(r4)
cmpwi   r6,0
bne 1f
-   ld  r0,PACA_DSCR(r13)
+   ld  r0,PACA_DSCR_DEFAULT(r13)
 1:
 BEGIN_FTR_SECTION_NESTED(70)
mfspr   r8, SPRN_FSCR
diff --git a/arch/powerpc/kernel/tm.S b/arch/powerpc/kernel/tm.S
index 5754b22..bf8f34a 100644
--- a/arch/powerpc/kernel/tm.S
+++ b/arch/powerpc/kernel/tm.S
@@ -293,7 +293,7 @@ dont_backup_fp:
ld  r2, STK_GOT(r1)
 
/* Load CPU's default DSCR */
-   ld  r0, PACA_DSCR(r13)
+   ld  r0, PACA_DSCR_DEFAULT(r13)
mtspr   SPRN_DSCR, r0
 
blr
@@ -473,7 +473,7 @@ restore_gprs:
ld  r2, STK_GOT(r1)
 
/* Load CPU's default DSCR */
-   ld  r0, PACA_DSCR(r13)
+   ld  r0, PACA_DSCR_DEFAULT(r13)
mtspr   SPRN_DSCR, r0
 
blr
diff --git a/arch/powerpc/kvm/book3s_hv_rmhandlers.S 
b/arch/powerpc/kvm/book3s_hv_rmhandlers.S
index 4d70df2..faa86e9 100644
--- a/arch/powerpc/kvm/book3s_hv_rmhandlers.S
+++ b/arch/powerpc/kvm/book3s_hv_rmhandlers.S
@@ -324,7 +324,7 @@ kvm_start_guest:
 kvm_secondary_got_guest:
 
/* Set HSTATE_DSCR(r13) to something sensible */
-   ld  r6, PACA_DSCR(r13)
+   ld  r6, PACA_DSCR_DEFAULT(r13)
std r6, HSTATE_DSCR(r13)
 
/* Order load of vcore, ptid etc. after load of vcpu */
-- 
2.1.0

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


[PATCH V5 09/13] selftests, powerpc: Add test for DSCR value inheritence across fork

2015-05-20 Thread Anshuman Khandual
This patch adds a test to verify that the changed DSCR value inside
any process would be inherited to it's child process across the fork
system call.

Acked-by: Shuah Khan 
Signed-off-by: Anshuman Khandual 
Signed-off-by: Anton Blanchard 
---
 tools/testing/selftests/powerpc/dscr/Makefile  |  3 +-
 .../selftests/powerpc/dscr/dscr_inherit_test.c | 96 ++
 2 files changed, 98 insertions(+), 1 deletion(-)
 create mode 100644 tools/testing/selftests/powerpc/dscr/dscr_inherit_test.c

diff --git a/tools/testing/selftests/powerpc/dscr/Makefile 
b/tools/testing/selftests/powerpc/dscr/Makefile
index ae865d8..81239e2 100644
--- a/tools/testing/selftests/powerpc/dscr/Makefile
+++ b/tools/testing/selftests/powerpc/dscr/Makefile
@@ -1,4 +1,5 @@
-PROGS := dscr_default_test dscr_explicit_test dscr_user_test
+PROGS := dscr_default_test dscr_explicit_test dscr_user_test   \
+dscr_inherit_test
 
 CFLAGS := $(CFLAGS) -lpthread
 
diff --git a/tools/testing/selftests/powerpc/dscr/dscr_inherit_test.c 
b/tools/testing/selftests/powerpc/dscr/dscr_inherit_test.c
new file mode 100644
index 000..9d0ca37
--- /dev/null
+++ b/tools/testing/selftests/powerpc/dscr/dscr_inherit_test.c
@@ -0,0 +1,96 @@
+/*
+ * POWER Data Stream Control Register (DSCR) fork test
+ *
+ * This testcase modifies the DSCR using mtspr, forks and then
+ * verifies that the child process has the correct changed DSCR
+ * value using mfspr.
+ *
+ * When using the privilege state SPR, the instructions such as
+ * mfspr or mtspr are priviledged and the kernel emulates them
+ * for us. Instructions using problem state SPR can be exuecuted
+ * directly without any emulation if the HW supports them. Else
+ * they also get emulated by the kernel.
+ *
+ * Copyright (C) 2012 Anton Blanchard , IBM
+ * Copyright (C) 2015 Anshuman Khandual , IBM
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License
+ * as published by the Free Software Foundation; either version
+ * 2 of the License, or (at your option) any later version.
+ */
+#include "dscr.h"
+
+int dscr_inherit(void)
+{
+   unsigned long i, dscr = 0;
+   pid_t pid;
+
+   srand(getpid());
+   set_dscr(dscr);
+
+   for (i = 0; i < COUNT; i++) {
+   unsigned long cur_dscr, cur_dscr_usr;
+
+   dscr++;
+   if (dscr > DSCR_MAX)
+   dscr = 0;
+
+   if (i % 2 == 0)
+   set_dscr_usr(dscr);
+   else
+   set_dscr(dscr);
+
+   /*
+* XXX: Force a context switch out so that DSCR
+* current value is copied into the thread struct
+* which is required for the child to inherit the
+* changed value.
+*/
+   sleep(1);
+
+   pid = fork();
+   if (pid == -1) {
+   perror("fork() failed");
+   exit(1);
+   } else if (pid) {
+   int status;
+
+   if (waitpid(pid, &status, 0) == -1) {
+   perror("waitpid() failed");
+   exit(1);
+   }
+
+   if (!WIFEXITED(status)) {
+   fprintf(stderr, "Child didn't exit cleanly\n");
+   exit(1);
+   }
+
+   if (WEXITSTATUS(status) != 0) {
+   fprintf(stderr, "Child didn't exit cleanly\n");
+   return 1;
+   }
+   } else {
+   cur_dscr = get_dscr();
+   if (cur_dscr != dscr) {
+   fprintf(stderr, "Kernel DSCR should be %ld "
+   "but is %ld\n", dscr, cur_dscr);
+   exit(1);
+   }
+
+   cur_dscr_usr = get_dscr_usr();
+   if (cur_dscr_usr != dscr) {
+   fprintf(stderr, "User DSCR should be %ld "
+   "but is %ld\n", dscr, cur_dscr_usr);
+   exit(1);
+   }
+   exit(0);
+   }
+   }
+   return 0;
+}
+
+int main(int argc, char *argv[])
+{
+   return test_harness(dscr_inherit, "dscr_inherit_test");
+}
-- 
2.1.0

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


Re: [PATCH] regulator: core: fix constraints debug output

2015-05-20 Thread Stefan Wahren
Hi Joe,

> Joe Perches  hat am 20. Mai 2015 um 22:35 geschrieben:
>
>
> On Wed, 2015-05-20 at 20:17 +, Stefan Wahren wrote:
> > In the case uV_offset is greater than 0 the debug output before
> > is accidentally overwritten. So take care of the output count.
>
> If you are going to take care, please change all of these
> sprintf calls to snprintf.

thanks for pointing out. I will create a second version.

But using scnprintf should be better here.

>
> The buf array may not be big enough [80] to hold the longest
> possible output string.
>

Stefan
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] usb: ulpi: don't register drivers if bus doesn't exist

2015-05-20 Thread Lu, Baolu



On 05/21/2015 05:22 AM, David Cohen wrote:

Hi,

On Wed, May 20, 2015 at 03:33:26PM -0400, Sasha Levin wrote:

ULPI registers it's bus at module_init so if the bus fails to register, the

A minor comment: s/it's/its/


module will fail to load and all will be well in the world.

However, if the ULPI code is built-in rather than a module, the bus
initialization may fail but we'd still try to register drivers later onto
a non-existant bus, which will panic the kernel.

Fix that by checking that the bus was indeed initialized before trying to
register drivers on top of it.

Signed-off-by: Sasha Levin 
---
  drivers/usb/common/ulpi.c |4 
  1 file changed, 4 insertions(+)

diff --git a/drivers/usb/common/ulpi.c b/drivers/usb/common/ulpi.c
index 0e6f968..0b0a5e7 100644
--- a/drivers/usb/common/ulpi.c
+++ b/drivers/usb/common/ulpi.c
@@ -132,6 +132,10 @@ int ulpi_register_driver(struct ulpi_driver *drv)
if (!drv->probe)
return -EINVAL;
  
+	/* Was the bus registered successfully? */

+   if (!ulpi_bus.p)
+   return -ENODEV;
+

Good catch. Otherwise it may trigger BUG() on driver_register().
I wonder if it would be nice to have a macro for that checking :)

Anyway,

Reviewed-by: David Cohen 


Well, I was also encountering panic issue when running it on
Intel Bay Trail tablets. In my case, it's due to the execution
sequence. When ulpi bus is built-in, driver or device registered
before ulpi bus registration.

Thanks,
Baolu




drv->driver.bus = &ulpi_bus;
  
  	return driver_register(&drv->driver);

--
1.7.10.4


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




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


Re: [PATCH v9 3/5] crypto: drbg - add async seeding operation

2015-05-20 Thread Herbert Xu
On Thu, May 21, 2015 at 08:10:13AM +0200, Stephan Mueller wrote:
>
> The cancel operation is needed as otherwise my drbg context handle will be 
> removed by the crypto API during the sleep. That is the whole reason why 
> wait_event_interruptible is used.
> 
> So, even when using an uninterruptible sleep, the crypto API has no knowledge 
> about it and I have to serialize the destruction code path with the async 
> callback.

I understand.  But if you use the uniterruptible version at least
you won't have to deal with bogus early returns.

The cancel by itself will *not* cause wait_event_interruptible
to return early.  Somebody has to send it a signal for that to
happen.

Cheers,
-- 
Email: Herbert Xu 
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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: [EDT][PATCH] kernel/exit.c : Fix missing read_unlock

2015-05-20 Thread Maninder Singh
EP-F6AA0618C49C4AEDA73BFF1B39950BAB
>> Hi,
>> 
>> From: Maninder Singh 
>> 
>> Subject: [PATCH 1/1] kernel/exit.c : Fix missing task_unlock
>> 
 Subject: [PATCH 1/1] kernel/exit.c : Fix missing read_unlock
 
>> This patch adds missing read_unlock if do_wait_thread or ptrace_do_wait 
>> returns non zero.

  Reported By Prevent Under Missing unlock category(program hangs):-
  missing_unlock: returning without unlocking tasklist_lock
>> 
>> Signed-off-by: Maninder Singh 
>> Signed-off-by: Vaneet Narang 
>> Reviewd-by: Akhilesh Kumar 
>> ---
>>  kernel/exit.c |8 ++--
>>  1 files changed, 6 insertions(+), 2 deletions(-)
>> 
>> diff --git a/kernel/exit.c b/kernel/exit.c
>> index 22fcc05..31a061f 100644
>> --- a/kernel/exit.c
>> +++ b/kernel/exit.c
>> @@ -1486,12 +1486,16 @@ repeat:
>>  tsk = current;
>>  do {
>>  retval = do_wait_thread(wo, tsk);
>> -if (retval)
>> +if (retval) {
>> +read_unlock(&tasklist_lock);
>>  goto end;
>> +}
>>  
>>  retval = ptrace_do_wait(wo, tsk);
>> -if (retval)
>> +if (retval) {
>> +read_unlock(&tasklist_lock);
>>  goto end;
>> +}
>>  
>>  if (wo->wo_flags & __WNOTHREAD)
>>  break;
>
>That's surprising and the changelog is lacking.

>So the last time that code was touched upstream was 7 years ago:

> commit 64a16caf5e3417ee32f670debcb5857b02a9e08e
> Author: Oleg Nesterov 
> Date:   Wed Jun 17 16:27:40 2009 -0700

>do_wait: simplify retval/tsk_result/notask_error mess

>please explain whether what you fix is:

>  1) an ancient bug that somehow nobody ever triggered (plus analysis 
> of why it wasn't triggered)

>  2) a new bug introduced by commit XYZ (plus analysis)

>  3) something else

This issue is reported by Prevent Under category Missing Unlock, So we think it 
should be reported to maintainers.

>Thanks,
>   Ingo

Thanks.

Re: [PATCH v3] Fix endian issues and remove the board specific codes

2015-05-20 Thread Dmitry Torokhov
Hi Hn,

On Mon, May 11, 2015 at 01:11:39AM +0800, HungNien Chen wrote:
> Signed-off-by: HungNien Chen 

Thank you for making the requested changes. Some more comments below.

> ---
>  drivers/input/touchscreen/Kconfig   |   12 +
>  drivers/input/touchscreen/Makefile  |1 +
>  drivers/input/touchscreen/wdt87xx_i2c.c | 1509 
> +++
>  3 files changed, 1522 insertions(+)
>  create mode 100644 drivers/input/touchscreen/wdt87xx_i2c.c
> 
> diff --git a/drivers/input/touchscreen/Kconfig 
> b/drivers/input/touchscreen/Kconfig
> index 80f6386..0c1a6cc 100644
> --- a/drivers/input/touchscreen/Kconfig
> +++ b/drivers/input/touchscreen/Kconfig
> @@ -658,6 +658,18 @@ config TOUCHSCREEN_PIXCIR
> To compile this driver as a module, choose M here: the
> module will be called pixcir_i2c_ts.
>  
> +config TOUCHSCREEN_WDT87XX_I2C
> + tristate "Weida HiTech I2C touchscreen"
> + depends on I2C
> + help
> +   Say Y here if you have an Weida WDT87XX I2C touchscreen
> +   connected to your system.
> +
> +   If unsure, say N.
> +
> +   To compile this driver as a module, choose M here: the
> +   module will be called wdt87xx_i2c.
> +
>  config TOUCHSCREEN_WM831X
>   tristate "Support for WM831x touchscreen controllers"
>   depends on MFD_WM831X
> diff --git a/drivers/input/touchscreen/Makefile 
> b/drivers/input/touchscreen/Makefile
> index 44deea7..fa3d33b 100644
> --- a/drivers/input/touchscreen/Makefile
> +++ b/drivers/input/touchscreen/Makefile
> @@ -72,6 +72,7 @@ obj-$(CONFIG_TOUCHSCREEN_TSC2007)   += tsc2007.o
>  obj-$(CONFIG_TOUCHSCREEN_UCB1400)+= ucb1400_ts.o
>  obj-$(CONFIG_TOUCHSCREEN_WACOM_W8001)+= wacom_w8001.o
>  obj-$(CONFIG_TOUCHSCREEN_WACOM_I2C)  += wacom_i2c.o
> +obj-$(CONFIG_TOUCHSCREEN_WDT87XX_I2C)+= wdt87xx_i2c.o
>  obj-$(CONFIG_TOUCHSCREEN_WM831X) += wm831x-ts.o
>  obj-$(CONFIG_TOUCHSCREEN_WM97XX) += wm97xx-ts.o
>  wm97xx-ts-$(CONFIG_TOUCHSCREEN_WM9705)   += wm9705.o
> diff --git a/drivers/input/touchscreen/wdt87xx_i2c.c 
> b/drivers/input/touchscreen/wdt87xx_i2c.c
> new file mode 100644
> index 000..e3eef1c
> --- /dev/null
> +++ b/drivers/input/touchscreen/wdt87xx_i2c.c
> @@ -0,0 +1,1509 @@
> +/*
> + * Weida HiTech WDT87xx TouchScreen I2C driver
> + *
> + * Copyright (c) 2014  Weida HiTech Ltd.
> + * HN Chen 
> + *
> + * This software is licensed under the terms of the GNU General Public
> + * License, as published by the Free Software Foundation, and
> + * may be copied, distributed, and modified under those terms.
> + *
> + * Note: this is a I2C device driver and report touch events througt the
> + *   input device
> + */
> +
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +#define WDT87XX_NAME "wdt87xx_i2c"
> +#define  WDT87XX_DRV_VER "0.9.2"
> +#define  WDT87XX_FW_NAME "wdt87xx_fw.bin"
> +
> +#define  WDT87XX_FW  1
> +#define  WDT87XX_CFG 2
> +
> +#define MODE_ACTIVE  0x01
> +#define MODE_READY   0x02
> +#define MODE_IDLE0x03
> +#define MODE_SLEEP   0x04
> +#define  MODE_STOP   0xFF
> +
> +#define WDT_MAX_POINT10
> +#define  WDT_RAW_BUF_COUNT   54
> +
> +#define  PG_SIZE 0x1000
> +#define MAX_RETRIES  3
> +
> +#define  WDT_UNITS_PER_MM60
> +
> +/* the definition for one finger */
> +#define  FINGER_EV_OFFSET_ID 0
> +#define  FINGER_EV_OFFSET_X  1
> +#define  FINGER_EV_OFFSET_Y  3
> +#define  FINGER_EV_SIZE  5
> +
> +/* the definition for a packet */
> +#define  TOUCH_PK_OFFSET_REPORT_ID   0
> +#define  TOUCH_PK_OFFSET_EVENT   1
> +#define TOUCH_PK_OFFSET_SCAN_TIME51
> +#define  TOUCH_PK_OFFSET_FNGR_NUM53
> +
> +/* the definition for the controller parameters */
> +#define  CTL_PARAM_OFFSET_FW_ID  0
> +#define  CTL_PARAM_OFFSET_PLAT_ID2
> +#define  CTL_PARAM_OFFSET_XMLS_ID1   4
> +#define  CTL_PARAM_OFFSET_XMLS_ID2   6
> +#define  CTL_PARAM_OFFSET_PHY_X  8
> +#define  CTL_PARAM_OFFSET_PHY_Y  10
> +
> +struct sys_param {
> + unsigned short  fw_id;
> + unsigned short  plat_id;
> + unsigned short  xmls_id1;
> + unsigned short  xmls_id2;
> + unsigned short  phy_x;
> + unsigned short  phy_y;
> +} __packed;
> +
> +/* the definition for this driver needed */
> +struct wdt87xx_ts_data {
> + struct i2c_client   *client;
> + struct input_dev*input_dev;
> +/* to protect the operation in sysfs */
> + 

Re: [PATCH 2/2] misc: Add initial Digital Timing Engine (DTE) driver for cygnus

2015-05-20 Thread Richard Cochran
On Wed, May 20, 2015 at 04:38:02PM -0700, Jonathan Richardson wrote:
> 
> Richard, this design isn't going to work. We need to have both kernel
> and user space consumers.

But you did not implement even a single kernel consumer.

> We don't want all GPIO's in a common timestamp
> buffer either, as it presents problems I mentioned previously. Currently
> the network input is a gpio.

That won't work.  Consider what happens when the MAC drops a packet.

> After some discussion here I think we'll
> have to keep this driver out of the kernel for now.

Fine with me.

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


Re: [PATCHv2] coccinelle: api: add vma_pages.cocci

2015-05-20 Thread Michal Marek
Dne 18.5.2015 v 04:25 Julia Lawall napsal(a):
> On Sun, 17 May 2015, Dmitry Kalinkin wrote:
>> This semantic patch replaces explicit computations of vma page count
>> with explicit function call.
>>
>> Signed-off-by: Dmitry Kalinkin 
> Acked-by: Julia Lawall 

Thanks, applied to kbuild.git#misc.

Michal
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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 7/7] time: Remove read_boot_clock()

2015-05-20 Thread Ingo Molnar

* John Stultz  wrote:

> From: Xunlei Pang 
> 
> Now we have all the read_boot_clock64() for all implementations,
> it's time to remove read_boot_clock() completely from the kernel.

This sentence does not parse for me. Did you want to say:

  Now that we have a read_boot_clock64() function available on every
  architecture, and converted all the users to it, it's time to remove 
  the (now unused) read_boot_clock() completely from the kernel.

?

Thanks,

Ingo
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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 6/7] s390: time: Provide read_boot_clock64() and read_persistent_clock64()

2015-05-20 Thread Ingo Molnar

* John Stultz  wrote:

> From: Xunlei Pang 
> 
> As part of addressing "y2038 problem" for in-kernel uses, this
> patch converts read_boot_clock() to read_boot_clock64() and
> read_persistent_clock() to read_persistent_clock64() using
> timespec64.

s/addressing "y2037 problem"/
  addressing the "y2037 problem"

> Rename some timespec to timespec64 in time.c and related references.

This sentence does not parse. Did you want to say:

  Rename some instances of 'timespec' to 'timespec64' in time.c and 
  related references.

?

> @@ -108,10 +109,10 @@ int get_sync_clock(unsigned long long *clock);
>  void init_cpu_timer(void);
>  unsigned long long monotonic_clock(void);
>  
> -void tod_to_timeval(__u64, struct timespec *);
> +void tod_to_timeval(__u64, struct timespec64 *);

Please use proper prototypes with parameters spelled out as well, so 
that people grepping for APIs don't have to guess too much.

> - rc += sprintf(out_buf, "%02i %011lu:%06lu %1u %1s %02i %p  ",
> -   area, time_spec.tv_sec, time_spec.tv_nsec / 1000, level,
> -   except_str, entry->id.fields.cpuid, (void *) caller);
> + rc += sprintf(out_buf, "%02i %011lld:%06lu %1u %1s %02i %p  ",
> +   area, (long long) time_spec.tv_sec,
> +   time_spec.tv_nsec / 1000, level, except_str,
> +   entry->id.fields.cpuid, (void *) caller);

Unnecessary space before the casts.

Thanks,

Ingo
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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 v6 1/2] PCI/MSI: Don't disable MSI/MSI-X at shutdown

2015-05-20 Thread Fam Zheng
On Tue, 05/19 09:58, Bjorn Helgaas wrote:
> On Tue, May 12, 2015 at 03:03:32PM +0200, Michael S. Tsirkin wrote:
> > d52877c7b1af ("pci/irq: let pci_device_shutdown to call pci_msi_shutdown
> > v2") disabled MSI/MSI-X at device shutdown to address a kexec problem.
> > ... 

Hi Bjorn,
> 
> I know you're trying to put all the justification in the changelog, and
> that's great if it can be done.  But would you please just add the single
> link here to https://bugzilla.kernel.org/show_bug.cgi?id=96571 ?
> 
> And please attach the dmesg log and instructions for reproducing the
> problem to the bugzilla.  I've asked for this before, and it seems like a
> simple request, but maybe there's a reason it's more complicated than it
> seems to me.  It's obvious to you how all this fits together, but I'd like
> it to be more concrete to the rest of us, too.

I've updated what I could see with current master build as much as I can, the
softlockup is not observed in my tests, but the dmesg log already shows the
spurious IRQ.

> 
> The bugzilla says Ulrich Obergfell noticed this in RHEL7.  If there's a
> RHEL bugzilla, it'd be nice to have a link to it in the kernel.org
> bugzilla.  Informal hints are great right now, but they'll be useless after
> six months.

The original bug is not public accessible, so I didn't include the link.

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


Re: [PATCH 5/7] time: include math64.h in time64.h

2015-05-20 Thread Ingo Molnar

* John Stultz  wrote:

> From: Xunlei Pang 
> 
> On 32-bit systems, timespec64_add_ns() calls __iter_div_u64_rem()
> which needs match64.h, and we want to include time64.h in some

s/match64.h
  math64.h

Also, missing comma.

Thanks,

Ingo
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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/7] Current queue for tip/timers/core

2015-05-20 Thread Ingo Molnar

* John Stultz  wrote:

> Hey Thomas, Ingo,
>   Just wanted to send you my current queue of items that I
> have pending for tip/timers/core for 4.2
> 
> Let me know if you have any concerns or objections.
> 
> thanks
> -john
> 
>   tracing: timer: Add deferrable flag to timer_start
>   timekeeping: Provide new API to get the current time resolution
>   time: Rework debugging variables so they aren't global
>   time: make sure tz_minuteswest is set to a valid value when setting time
>   time: include math64.h in time64.h
>   s390: time: Provide read_boot_clock64() and read_persistent_clock64()
>   time: Remove read_boot_clock()

Please use consistent capitalization in patch titles, i.e.:

   s/make sure/
 Make sure

   s/include/
 Include

Thanks,

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


Re: [PATCH 4/7] tracing: timer: Add deferrable flag to timer_start

2015-05-20 Thread Ingo Molnar

* John Stultz  wrote:

> From: Badhri Jagan Sridharan 
> 
> The timer_start event now shows whether the timer is
> deferrable in case of a low-res timer. The debug_activate
> function now includes deferrable flag while calling
> trace_timer_start event.

s/now includes deferrable flag/
  now includes a deferrable flag

s/calling trace_timer_start event/
  calling the trace_timer_start event

>  TRACE_EVENT(timer_start,
>  
> - TP_PROTO(struct timer_list *timer, unsigned long expires),
> + TP_PROTO(struct timer_list *timer,
> + unsigned long expires,

This isn't compat safe, should any tooling rely on this.

I see it's a mistake in prior code:

> + unsigned int deferrable),
>  
> - TP_ARGS(timer, expires),
> + TP_ARGS(timer, expires, deferrable),
>  
>   TP_STRUCT__entry(
>   __field( void *,timer   )
>   __field( void *,function)
>   __field( unsigned long, expires )
>   __field( unsigned long, now )

which should probably be fixed as well.

> @@ -650,7 +650,8 @@ static inline void
>  debug_activate(struct timer_list *timer, unsigned long expires)
>  {
>   debug_timer_activate(timer);
> - trace_timer_start(timer, expires);
> + trace_timer_start(timer, expires,
> + tbase_get_deferrable(timer->base));

why is this line broken? If you put it into a single line it's still 
below 80 cols, so there's really no reason for it.

Thanks,

Ingo
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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 4/6] soc: mediatek: Add SMI driver

2015-05-20 Thread Yong Wu
Hi Matthias,
 Thanks very much for your suggestion.
 Abort the smi clock name, Could you help check below.
 The others I will improve in next time.

On Tue, 2015-05-19 at 13:14 +0200, Matthias Brugger wrote:
> 2015-05-15 11:43 GMT+02:00 Yong Wu :
> > This patch add SMI(Smart Multimedia Interface) driver. This driver is
> > responsible to enable/disable iommu and control the clocks of each local 
> > arbiter.
> >
[snip]
> > +
> > +#define SMI_LARB_MMU_EN(0xf00)
> > +#define F_SMI_MMU_EN(port) (1 << (port))
> > +
> > +enum {
> > +   MTK_CLK_APB,
> > +   MTK_CLK_SMI,
> > +   MTK_CLK_MAX,
> 
> Maybe add something like:
> MTK_CLK_FIRST = MTK_CLK_APB,
> to make the for loops better readable.
> 
Then, Is it like this? : 
 enum {
MTK_CLK_FIRST = MTK_CLK_APB,
MTK_CLK_SMI,
MTK_CLK_MAX,
 }
or the CLK_SMI also need MTK_CLK_SECOND = MTK_CLK_SMI.
> > +};
> > +
> > +struct mtk_smi_common {
> > +   void __iomem*base;
> 
> That seems to be never used. Please delete it.
> 
> > +   struct clk  *clk[MTK_CLK_MAX];
> > +};
> > +
> > +struct mtk_smi_larb {
> > +   void __iomem*base;
> > +   spinlock_t  portlock; /* lock for config port */
> > +   struct clk  *clk[MTK_CLK_MAX];
> > +   struct device   *smi;
> > +};
> > +
> Thanks,
> Matthias


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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 4/6] i2c-parport: use new parport device model

2015-05-20 Thread Sudip Mukherjee
Modify i2c-parport driver to use the new parallel port device model.

Tested-by: Jean Delvare 
Acked-by: Wolfram Sang 
Signed-off-by: Sudip Mukherjee 
---

v2: Changed to one space instead of tab in i2c_parport_driver.

i2c_parport_cb is made local, devmodel added to driver structure,
and probe removed. 

 drivers/i2c/busses/i2c-parport.c | 15 ++-
 1 file changed, 10 insertions(+), 5 deletions(-)

diff --git a/drivers/i2c/busses/i2c-parport.c b/drivers/i2c/busses/i2c-parport.c
index 155da95..138347e 100644
--- a/drivers/i2c/busses/i2c-parport.c
+++ b/drivers/i2c/busses/i2c-parport.c
@@ -185,11 +185,15 @@ static void i2c_parport_attach(struct parport *port)
printk(KERN_ERR "i2c-parport: Failed to kzalloc\n");
return;
}
+   memset(&i2c_parport_cb, 0, sizeof(i2c_parport_cb));
+   i2c_parport_cb.flags = PARPORT_FLAG_EXCL;
+   i2c_parport_cb.irq_func = i2c_parport_irq;
+   i2c_parport_cb.private = adapter;
 
pr_debug("i2c-parport: attaching to %s\n", port->name);
parport_disable_irq(port);
-   adapter->pdev = parport_register_device(port, "i2c-parport",
-   NULL, NULL, i2c_parport_irq, PARPORT_FLAG_EXCL, adapter);
+   adapter->pdev = parport_register_dev_model(port, "i2c-parport",
+  &i2c_parport_cb, i);
if (!adapter->pdev) {
printk(KERN_ERR "i2c-parport: Unable to register with 
parport\n");
goto err_free;
@@ -283,9 +287,10 @@ static void i2c_parport_detach(struct parport *port)
 }
 
 static struct parport_driver i2c_parport_driver = {
-   .name   = "i2c-parport",
-   .attach = i2c_parport_attach,
-   .detach = i2c_parport_detach,
+   .name = "i2c-parport",
+   .match_port = i2c_parport_attach,
+   .detach = i2c_parport_detach,
+   .devmodel = true,
 };
 
 /* - Module loading, unloading and information  */
-- 
1.8.1.2

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


Re: [RFD] linux-firmware key arrangement for firmware signing

2015-05-20 Thread Greg Kroah-Hartman
On Thu, May 21, 2015 at 08:41:02AM +0300, Petko Manolov wrote:
> > I too don't understand this need to sign something that you don't really 
> > know 
> > what it is from some other company, just to send it to a separate device 
> > that 
> > is going to do whatever it wants with it if it is signed or not.
> 
> This is not the point.  What you need to know is _where_ the firmware came 
> from, 
> not _what_ it does once it reach your system.  If you don't care about such 
> things, just ignore the signature. :)

Ok, but how do we know "where"?  Who is going to start signing and
attesting to the validity of all of the firmware images in the
linux-firmware tree suddenly?  Why is it the kernel's job to attest this
"where"?  Shouldn't your distro/manufacturer be doing that as part of
their "put this file on this disk" responsibilities (i.e. the package
manager?)

What is verifying a firmware image signature in the kernel attesting
that isn't already known in userspace?

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 3/7] time: Rework debugging variables so they aren't global

2015-05-20 Thread Ingo Molnar

* John Stultz  wrote:

> Ingo suggested that the timekeeping debugging variables
> recently added should not be global, and should be tied
> to the timekeeper's read_base.
> 
> Thus this patch implements that suggestion.
> 
> This version is differnet from the earlier versions

s/differnet/
  different

> as it keeps the variables in the timekeeper structure
> rather then in the tkr.

> + * @last_warning:Warning ratelimiter (DEBUG_TIMEKEEPING)
> + * @underflow_seen:  Underflow warning flag (DEBUG_TIMEKEEPING)
> + * @overflow_seen:   Overflow warning flag (DEBUG_TIMEKEEPING)
>   *
>   * Note: For timespec(64) based interfaces wall_to_monotonic is what
>   * we need to add to xtime (or xtime corrected for sub jiffie times)
> @@ -106,6 +109,18 @@ struct timekeeper {
>   s64 ntp_error;
>   u32 ntp_error_shift;
>   u32 ntp_err_mult;
> +#ifdef CONFIG_DEBUG_TIMEKEEPING
> + longlast_warning;
> + /*
> +  * These simple flag variables are managed
> +  * without locks, which is racy, but ok since
> +  * we don't really care about being super
> +  * precise about how many events were seen,
> +  * just that a problem was observed.

s/but ok since/
  but they are ok since

Thanks,

Ingo
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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 v9 3/5] crypto: drbg - add async seeding operation

2015-05-20 Thread Stephan Mueller
Am Donnerstag, 21. Mai 2015, 05:44:08 schrieb Herbert Xu:

Hi Herbert,

> On Wed, May 20, 2015 at 10:03:45PM +0200, Stephan Mueller wrote:
> >> @@ -1487,6 +1514,7 @@ unlock:
> >   */
> >  
> >  static int drbg_uninstantiate(struct drbg_state *drbg)
> >  {
> > 
> > +   cancel_work_sync(&drbg->seed_work);
> 
> This will just block until the work is done, i.e., until the
> pool is ready.  It's no different to an uninterruptible sleep.
> 
> So either just do an uninterruptible sleep, or allow the async
> seed to fail.
> 
The cancel operation is needed as otherwise my drbg context handle will be 
removed by the crypto API during the sleep. That is the whole reason why 
wait_event_interruptible is used.

So, even when using an uninterruptible sleep, the crypto API has no knowledge 
about it and I have to serialize the destruction code path with the async 
callback.

-- 
Ciao
Stephan
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] kvm:Return -ENOMEM directly for the function, kvm_create_lapic

2015-05-20 Thread Ingo Molnar

* Nicholas Krause  wrote:

> In order to make code paths easier to read in the function,
> kvm_create_lapic we return -ENOMEM when unable to allocate
> memory for a kvm_lapic structure pointer directly. This
> makes the code easier to read and cleaner then jumping
> to a goto label at the end of the function's body for
> returning just the error code, -ENOMEM.
> 
> Signed-off-by: Nicholas Krause 
> ---
>  arch/x86/kvm/lapic.c | 3 +--
>  1 file changed, 1 insertion(+), 2 deletions(-)
> 
> diff --git a/arch/x86/kvm/lapic.c b/arch/x86/kvm/lapic.c
> index 629af0f..88d0cce 100644
> --- a/arch/x86/kvm/lapic.c
> +++ b/arch/x86/kvm/lapic.c
> @@ -1687,7 +1687,7 @@ int kvm_create_lapic(struct kvm_vcpu *vcpu)
>  
>   apic = kzalloc(sizeof(*apic), GFP_KERNEL);
>   if (!apic)
> - goto nomem;
> + return -ENOMEM;
>  
>   vcpu->arch.apic = apic;
>  
> @@ -1718,7 +1718,6 @@ int kvm_create_lapic(struct kvm_vcpu *vcpu)
>   return 0;
>  nomem_free_apic:
>   kfree(apic);
> -nomem:
>   return -ENOMEM;
>  }

NAK!

You just half destroyed the nice error handling cascade of labels.

Thanks,

Ingo
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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 6/6] MAINTAINERS: maintain parport

2015-05-20 Thread Greg Kroah-Hartman
On Thu, May 21, 2015 at 07:51:18AM +0200, Willy Tarreau wrote:
> On Wed, May 20, 2015 at 05:46:44PM +0200, Richard Weinberger wrote:
> > On Wed, May 20, 2015 at 5:27 PM, Sudip Mukherjee
> >  wrote:
> > > Lets give the parport subsystem a proper name and start
> > > maintaining the files.
> > 
> > Excuse me, but usually someone takes over the maintainer role after
> > proving that he
> > cares for a sub system for a certain period of time.
> > Or did I miss something?
> 
> Sudip has been volunteering for fixing this code which is marked
> as "orphan". So whatever his experience and care in this area,
> it will be better for the driver to have a maintainer than none.
> 
> Good luck Sudip, as drivers which have become orphans are probably
> the ones that deserve the least love :-)

I agree.  I've been "baby-sitting" this subsystem for a long time now.
If Sudip wants to take it on, and based on his recent patches it looks
like he does, I'm all for him to be the maintainer of it.  So this patch
in the series is fine with me, I'll apply it when the rest of this
series gets merged.

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] dma-buf: Minor coding style fixes

2015-05-20 Thread Sumit Semwal
Hi Jagan,

On 21 May 2015 at 01:09, Jagan Teki  wrote:
> - WARNING: Missing a blank line after declarations
> - WARNING: line over 80 characters
> - WARNING: please, no space before tabs
>
> Signed-off-by: Jagan Teki 
> Cc: Sumit Semwal 

Thanks for the patch; I've queued it up in for-next.

Best regards,
~Sumit.


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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: [EDT][PATCH] kernel/exit.c : Fix missing read_unlock

2015-05-20 Thread Ingo Molnar

* Maninder Singh  wrote:

>  EP-F6AA0618C49C4AEDA73BFF1B39950BAB
> Hi,
> 
> From: Maninder Singh 
> 
> Subject: [PATCH 1/1] kernel/exit.c : Fix missing task_unlock
> 
> This patch adds missing read_unlock if do_wait_thread or ptrace_do_wait 
> returns non zero.
> 
> Signed-off-by: Maninder Singh 
> Signed-off-by: Vaneet Narang 
> Reviewd-by: Akhilesh Kumar 
> ---
>  kernel/exit.c |8 ++--
>  1 files changed, 6 insertions(+), 2 deletions(-)
> 
> diff --git a/kernel/exit.c b/kernel/exit.c
> index 22fcc05..31a061f 100644
> --- a/kernel/exit.c
> +++ b/kernel/exit.c
> @@ -1486,12 +1486,16 @@ repeat:
>   tsk = current;
>   do {
>   retval = do_wait_thread(wo, tsk);
> - if (retval)
> + if (retval) {
> + read_unlock(&tasklist_lock);
>   goto end;
> + }
>  
>   retval = ptrace_do_wait(wo, tsk);
> - if (retval)
> + if (retval) {
> + read_unlock(&tasklist_lock);
>   goto end;
> + }
>  
>   if (wo->wo_flags & __WNOTHREAD)
>   break;

That's surprising and the changelog is lacking.

So the last time that code was touched upstream was 7 years ago:

 commit 64a16caf5e3417ee32f670debcb5857b02a9e08e
 Author: Oleg Nesterov 
 Date:   Wed Jun 17 16:27:40 2009 -0700

do_wait: simplify retval/tsk_result/notask_error mess

please explain whether what you fix is:

  1) an ancient bug that somehow nobody ever triggered (plus analysis 
 of why it wasn't triggered)

  2) a new bug introduced by commit XYZ (plus analysis)

  3) something else

Thanks,

Ingo
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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 6/6] MAINTAINERS: maintain parport

2015-05-20 Thread Sudip Mukherjee
On Wed, May 20, 2015 at 10:36:04PM +0200, Richard Weinberger wrote:
> Am 20.05.2015 um 18:33 schrieb One Thousand Gnomes:
> > On Wed, 20 May 2015 17:46:44 +0200
> > Richard Weinberger  wrote:
> > 
> >> On Wed, May 20, 2015 at 5:27 PM, Sudip Mukherjee
> >>  wrote:
> >>> Lets give the parport subsystem a proper name and start
> >>> maintaining the files.
> >>
> >> Excuse me, but usually someone takes over the maintainer role after
> >> proving that he
> >> cares for a sub system for a certain period of time.
> >> Or did I miss something?
> > 
> > It currently (and for some time) has had no maintainer so having a
> > maintainer is IMHO definitely an improvement in things.
> 
> Having a maintainer is good.
> All I wanted to point out was that it is IMHO uncommon to claim maintainership
> before being the main contributor or the de facto maintainer of a
> subsystem.
> 
> This "rule" prevents us from "Mommy!!! Look, I'm a maintainer!!!1" patches. 
> ;-)

I already have my name in the MAINTAINERS file, so that is not a cookie
to cry for.
Personnaly I will prefer Joe Perches or Dan Carpenter to be the maintainer.
They have reviewed many of my patches since I started contributing here and
I have learnt and still learning many things from them.
if this patch is a debatable topic, then lets drop it. I have written these
changes, and will write the next changes also, it doesnot matter if my name
is there in the MAINTAINERS or not.
The main reason I gave this patch is just because if any problem
(read as regression) arises due to these changes then those problem mails
would have directly come to my inbox.

regards
sudip

> 
> Thanks,
> //richard
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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 6/6] MAINTAINERS: maintain parport

2015-05-20 Thread Willy Tarreau
On Wed, May 20, 2015 at 05:46:44PM +0200, Richard Weinberger wrote:
> On Wed, May 20, 2015 at 5:27 PM, Sudip Mukherjee
>  wrote:
> > Lets give the parport subsystem a proper name and start
> > maintaining the files.
> 
> Excuse me, but usually someone takes over the maintainer role after
> proving that he
> cares for a sub system for a certain period of time.
> Or did I miss something?

Sudip has been volunteering for fixing this code which is marked
as "orphan". So whatever his experience and care in this area,
it will be better for the driver to have a maintainer than none.

Good luck Sudip, as drivers which have become orphans are probably
the ones that deserve the least love :-)

Willy

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] arch: alpha: kernel: remove deprecated call to pci_get_slot

2015-05-20 Thread Matt Turner
On Thu, Feb 5, 2015 at 1:17 PM, Pierre Chevalier
 wrote:
> According to Documentation/PCI/pci.txt, pci_get_slot has been
> superseded by pci_get_domain_bus_and_slot.
>
> Signed-off-by: Pierre Chevalier 
> ---
>  arch/alpha/kernel/sys_miata.c | 3 ++-
>  1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/arch/alpha/kernel/sys_miata.c b/arch/alpha/kernel/sys_miata.c
> index d5b9776..7b98b40 100644
> --- a/arch/alpha/kernel/sys_miata.c
> +++ b/arch/alpha/kernel/sys_miata.c
> @@ -182,7 +182,8 @@ miata_map_irq(const struct pci_dev *dev, u8 slot, u8 pin)
>
> if((slot == 7) && (PCI_FUNC(dev->devfn) == 3)) {
> u8 irq=0;
> -   struct pci_dev *pdev = pci_get_slot(dev->bus, dev->devfn & 
> ~7);
> +   struct pci_dev *pdev =
> +   pci_get_domain_bus_and_slot(dev->bus, dev->devfn & 
> ~7);

Given that pci_get_domain_bus_and_slot takes three arguments, I don't
think this compiles.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] checkpatch: check for 2 or more spaces around assignment of a declaration

2015-05-20 Thread Willy Tarreau
On Wed, May 20, 2015 at 06:02:06PM -0700, Joe Perches wrote:
> Perhaps space aligned declarations should have some
> checkpatch --strict warning for 2 or more spaces
> around any assignment of the declaration.
> 
>   int a   = 1;// 2+ spaces before =
>   int b   =  2;   // 2+ spaces after =
>   int c   =   3;  // uses tabs around =, no warning
>   int d   = 4;// uses 2 tabs before =, no warning

FWIW, in my own code I've stopped using tabs for this and replaced
them with spaces. Tabs are fine *before* code but they completely
mangle the display for people using different tab sizes, or even
when reading diffs, because they heavily depend on the number of
characters *before* them while what you want is to ensure that
what is *after* is on a fixed position.

I would even go further and report warnings when tabs are used after
text.

Tabs after text were very useful in ASM editors in the past because
it was possible to define 3 fixed positions (mnemonic, operands,
comments) and that was the primary purpose of tabs. But in todays
editors, tabs do not mean "jump to next position" but "add between
1 and 8 to the current position" which doesn't make sense at all
if what preceeds can be larger than 8 (which is most often the case
in C code).

Willy

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


Re: [RFC PATCH 2/4] x86, mwaitt: introduce mwaitx idle with a configurable timer

2015-05-20 Thread Andy Lutomirski
On May 20, 2015 6:34 PM, "Andy Lutomirski"  wrote:
> If we did that *and* we had a non-crappy mwaitx, then we could apply an 
> optimization: when going idle, we could turn off the TSC deadline timer and 
> use mwaitx instead.  This would about an interrupt if the event that wakes us 
> is our timer.
>

Hey, Intel, want to document your secret "Timed MWAIT" feature?  It
causes a transition to C0 when the deadline expires (see 4.2.4 of the
Desktop 4th Generation Intel Core Processor Family Datasheet Volume 1,
order number 328897-001) and it even has an erratum (HSD63 / BDM32),
but the instruction itself doesn't appear to be documented.

--Andy
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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: Crash in crc32_le during kmemleak_scan()

2015-05-20 Thread vigneshr
> Analysis so far :
>
> I haven't been able to figure out exactly how the dots are connected and
> the relation to the change provided earlier but the following is what i
> could put together :
>
> When i checked the post mortem analysis i see the following in the
> crashing stack :
>
> -018|rb_erase(
> |[locdesc] node = ?,
> |[X1] root = 0xFFC0016E05B8)
> |  [X1] root = 0xFFC0016E05B8
> |  [locdesc] node = ?
> |  [X2] parent = 0xFFC02EEB6F40
> |  [X4] node = 0x0
> |  [X3] sibling = 0x0
> -019|__delete_object(
> |[X19] object = 0xFFC0236B03C0)
> |  [X21] flags = 0x0140
> -020|delete_object_full(
> |  ?)
> |  [X19] object = 0xFFC0236B03C0
> -021|__kmemleak_do_cleanup()
> |  [X19] object = 0xFFC0236B03C0 -> (
> |[0xFFC0236B03C0] lock = ([0xFFC0236B03C0] rlock =
> ([0xFFC0236B03C0] raw_lock = ([0xFFC0236B03C0] owner
> |[0xFFC0236B03D8] flags = 0x0,
> |[0xFFC0236B03E0] object_list = ([NSD:0xFFC0236B03E0] next
> = 0xFFC0236B1920, [NSD:0xFFC0236B03E8] prev = 0x00200200),
> |[0xFFC0236B03F0] gray_list = ([0xFFC0236B03F0] next =
> 0x00100100, [0xFFC0236B03F8] prev = 0x00200200),
>[0xFFC0236B0400] rb_node = (
>   [0xFFC0236B0400] __rb_parent_color = 
> 0xFFC02EEB6F41,
>   [0xFFC0236B0408] rb_right = 0x0,
>   [0xFFC0236B0410] rb_left = 0x0
>
>
> The node is becoming 0x0 here and is crashing in the following piece of
> code in rb_erase:
>
>
>   309 } else {
>   310 sibling = parent->rb_left;
>   311 if (rb_is_red(sibling)) {
>
> and rb_is_red(sibling) resolves into :
>
> 96 #define rb_is_red(rb)  __rb_is_red((rb)->__rb_parent_color)
>
>
>
> 1. Here the parent ptr refers to Object pointer residing at
> 0xFFC0236B03C0 and we can see that rb_node->rb_left is becoming 0x0 (
> this is from the values observed in the crashed stack)
>
>[0xFFC0236B0400] rb_node = (
>   [0xFFC0236B0400] __rb_parent_color = 
> 0xFFC02EEB6F41,
>   [0xFFC0236B0408] rb_right = 0x0,
>   [0xFFC0236B0410] rb_left = 0x0
>
> 2. Therefore the sibling will take the value 0x0
>
> 3. And then when rb->__rb_parent_color operation takes place, we crash
> since its not able to resolve 0x0 (since rb=0x0 here).
>
>
> So the question is how this variable ended up being this way.
>
> 1. I checked the object_list via list walkthrough  and it did not report
> any corruptions.
>
> 2. However, the object in question from our call stack,
> object->object_list pointers looks a bit amiss.
>
>   object_list = ([NSD:0xFFC0236B03E0] next = 0xFFC0236B1920,
> [NSD:0xFFC0236B03E8] prev = 0x00200200),
>
> But its not clear to me how it ended up being in this state.
>
>
> I will continue to debug what went wrong and share my analysis. Please let
> me know if anything looks obvious to you that i can try out.

I went through the bug again and i think the following is happening :

I just noticed that there could be possible race that's happening between 2
cores causing the aforementioned crash to occur :

Core 0  Core 1

rb_erase()  |
__delete_object()   |
delete_object_full()|
|
___ | __delete_object()
|
___ | delete_object_full()
|
___ | kmemleak_free()-Call from some other ctxt.
|
|
__kmemleak_do_cleanup() |
kmemleak_do_cleanup()   |
process_one_work()  |
worker_thread() |
kthread()   |
ret_from_fork() |

Just after __delete_object() running on core 1 unlocks the writelock
(kmemleak_lock), from core 0 we take the same object and try to do rb_erase
again. This is causing it to crash in this fashion.

Therefore, together with the warning that i quoted in the earlier mail and
the above race, i think the following can be added to the patch provided
earlier:

-- 8< -

diff --git a/mm/kmemleak.c b/mm/kmemleak.c
index 5ec8b71..4455bb8 100644
--- a/mm/kmemleak.c
+++ b/mm/kmemleak.c
@@ -959,7 +959,7 @@ void __ref kmemleak_free(const void *ptr)
 {
pr_debug("%s(0x%p)\n", __func__, ptr);

-   if (kmemleak_enabled && ptr && !IS_ERR(ptr))
+   if (kmemleak_enabled && ptr && !IS_ERR(ptr) && !kmemleak_error)
delete_object_full((unsigned long)ptr);
else if (kmemleak_early_log)
log_early(KMEMLEAK_FREE, ptr, 0, 0);
@@ -1019,7 +1019,7 @@ void __ref kmemleak_not_leak(const void *ptr)
 {
pr_debug("%s(0x%p)\n", __func__, ptr);

-   if (k

Re: [RFD] linux-firmware key arrangement for firmware signing

2015-05-20 Thread Petko Manolov
On 15-05-20 21:41:04, Greg Kroah-Hartman wrote:
> On Wed, May 20, 2015 at 07:46:13PM +0300, Petko Manolov wrote:
> > On 15-05-20 17:24:46, One Thousand Gnomes wrote:
> > > 
> > > More to the point why do you want to sign firmware files ? Leaving aside 
> > > the 
> > > fact that someone will produce a device with GPLv3 firmware just to p*ss 
> > > you 
> > > off there's the rather more relevant fact that firmware for devices on a 
> > > so 
> > > called "trusted" platform already have signed firmware.
> > 
> > For "trusted" systems one would like to make sure everything that goes in 
> > has 
> > known provenance.  Maybe this was the idea?
> 
> If so, then just do what people do today, verify their known valid disk image 
> before mounting it and then they know they can trust the data on it to be use 
> for whatever (including firmware.)  No kernel changes needed, distro support 
> is already there for this.

I do agree, the infrastructure is already in place.  The project i am working 
on 
has very strict security requirements, quite unlike regular Linux box.  I was 
pleasantly surprised that it didn't take much kernel hacking to get to the 
point 
where stuff is working to our liking.

> I too don't understand this need to sign something that you don't really know 
> what it is from some other company, just to send it to a separate device that 
> is going to do whatever it wants with it if it is signed or not.

This is not the point.  What you need to know is _where_ the firmware came 
from, 
not _what_ it does once it reach your system.  If you don't care about such 
things, just ignore the signature. :)


Petko
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] usb: ulpi: ulpi_init should be used in subsys_initcall

2015-05-20 Thread Lu Baolu
The intention of this change is to fix below kernel panic when
USB_ULPI_BUS was configured as buildin.

[0.746856] kernel BUG at drivers/base/driver.c:153!
[0.752418] invalid opcode:  [#1] PREEMPT SMP
[0.757804] Modules linked in:
[0.893985] Call Trace:
[0.896729]  [] ? ulpi_register_driver+0x21/0x30
[0.903654]  [] tusb1210_driver_init+0x10/0x12
[0.910386]  [] do_one_initcall+0xd8/0x200
[0.916729]  [] kernel_init_freeable+0x196/0x21e
[0.923655]  [] ? rest_init+0x90/0x90
[0.929509]  [] kernel_init+0xe/0xf0
[0.935266]  [] ret_from_fork+0x42/0x70
[0.941315]  [] ? rest_init+0x90/0x90

Reported-by: Zhuo Qiuxu 
Signed-off-by: Lu Baolu 
---
 drivers/usb/common/ulpi.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/usb/common/ulpi.c b/drivers/usb/common/ulpi.c
index 0e6f968..01c0c04 100644
--- a/drivers/usb/common/ulpi.c
+++ b/drivers/usb/common/ulpi.c
@@ -242,7 +242,7 @@ static int __init ulpi_init(void)
 {
return bus_register(&ulpi_bus);
 }
-module_init(ulpi_init);
+subsys_initcall(ulpi_init);
 
 static void __exit ulpi_exit(void)
 {
-- 
2.1.4

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


Re: [PATCH v8 01/16] scripts: link-vmlinux: Don't pass page offset to kallsyms if XIP Kernel

2015-05-20 Thread Michal Marek
Dne 21.5.2015 v 07:04 Andreas Färber napsal(a):
> Am 18.05.2015 um 13:47 schrieb Maxime Coquelin:
> But this is definitely an improvement for ARMv7-M debugging,
> 
> Tested-by: Andreas Färber 
> 
>> [Hi Michal, ...] could you consider
>> taking it for v4.2?

I applied it to kbuild.git#kbuild now.

Thanks,
Michal

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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/RFT v2 0/2] power_supply: Fix NULL pointer dereference from uevent

2015-05-20 Thread Dr. H. Nikolaus Schaller

Am 21.05.2015 um 00:20 schrieb Sebastian Reichel :

> Hi,
> 
> On Tue, May 19, 2015 at 10:28:39AM +0200, Dr. H. Nikolaus Schaller wrote:
>> Am 19.05.2015 um 09:13 schrieb Krzysztof Kozlowski :
>>> Changes since v1:
>>> =
>>> 1. Patch 2: fix invalid member used for container_of().
>>> 2. Patch 2: Replace WARN with pr_warn() in __power_supply_register()
>>>  if parent is missing.
>>> 
>>> 
>>> Description:
>>> 
>>> This is an idea to fix issue in bq27x00 driver (and probably in others)
>>> reported by H. Nikolaus Schaller [0].
>>> 
>>> The fixes are marked RFC/RFT because:
>>> 1. I do not have bq27x00-like device. I confirmed this and tested on
>>>  modified drivers (max77693, ACPI AC). These drivers are not
>>>  impacted by the issue but one can easily adjust them to reproduce
>>>  the problem.
>>> 2. The first uevent coming from power_supply_register() is now
>>>  different because it won't contain device properties. I am
>>>  not sure how this impacts userspace.
>>> 
>>> Comments are welcomed.
>> 
>> appears to work! bq27000 is coming up now without hickups.
>> 
>> What I can’t test is if the uevent is reasonable because we do not
>> have a specific rule triggered by it in our system.
>> 
>> So from my side we are now happy with the solution.
> 
> So you would be ok with the following added to the patches?
> 
> Tested-By: Dr. H. Nikolaus Schaller 

Yes, please add.

BR,
Nikolaus

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


Re: [GIT PULL] ARM: EXYNOS: Improvements for 4.2, second try

2015-05-20 Thread Kukjin Kim
On 05/19/15 15:21, Kukjin Kim wrote:
> On 05/17/15 17:52, Krzysztof Kozlowski wrote:
>> 2015-05-11 12:14 GMT+09:00 Krzysztof Kozlowski :
>>> Dear Kukjin,
>>>
>>> Updated pull request, replacing also the usage of soc_is_exynos4()
>>> with of_machine_is_compatible(). You requested this in comments
>>> for "ARM: EXYNOS: Fix failed second suspend on Exynos4".
>>>
>>> This adds coupled cpuidle for Exynos3250 and improves the Exynos
>>> code in few places. Everything for upcoming 4.2 merge window.
>>> Description along with a tag.
>>>
>>> Best regards,
>>> Krzysztof
>>>
>>>
>>> The following changes since commit b82f3a05ff0b5eaf2c9900eeb34e58a6624db8d9:
>>>
>>>   ARM: EXYNOS: Fix failed second suspend on Exynos4 (2015-05-11 11:03:09 
>>> +0900)
>>>
>>> are available in the git repository at:
>>>
>>>   https://github.com/krzk/linux.git tags/samsung-for-next-4.2-2
>>>
>>> for you to fetch changes up to c91889378098ff0bb5fe6f422a3c0eb554b34930:
>>>
>>>   ARM: plat-samsung: Constify platform_device_id (2015-05-11 11:05:31 +0900)
>>>
>>> 
>>> Extending cpuidle driver and improvements for Exynos based boards:
>>> 1. Replace soc_is_exynos4() with of_machine_is_compatible().
>>> 2. Add missing return-value checks and of_node_put() for power domain
>>>driver.
>>> 3. Fix missing clk_prepare in S3C24XX ADC driver.
>>> 4. Rework clock handling when switching power domains on/off. Instead
>>>of settting fixed parent in DTS we grab the parent clock before
>>>turning the domain off.
>>> 5. Add coupled cpuidle support for Exynos3250 to an existing
>>>cpuidle-exynos driver. As a result it enables AFTR mode
>>>(ARM-Off Top-Running) to be used by default on Exynos3250
>>>without the need to hot unplug CPU1 first.
>>> 6. Constify irq_domain_ops and platform_device_id.
>>
>> Dear Kukjin,
>>
>> Just humbly reminding - this stuff still waits for you :).
>>
> Sure, why not. I'll update it soon ;-)
> 
Done, thanks.

- Kukjin
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] serial: tegra: Fix memory leak on DMA setup failure

2015-05-20 Thread Alexandre Courbot
On Wed, May 20, 2015 at 8:21 PM, Jon Hunter  wrote:
> If the call to dmaengine_slave_config() fails, then the DMA buffer will
> not be freed/unmapped. Fix this by moving the code that stores the
> address of the buffer in the tegra_uart_port structure to before the
> call to dmaengine_slave_config().
>
> Reported-by: Alexandre Courbot 
> Signed-off-by: Jon Hunter 

Looks good, we had the same if/else condition appearing three times in
this function for no real reason anyway. This considerably simplifies
the code.

>  drivers/tty/serial/serial-tegra.c | 32 +++-
>  1 file changed, 11 insertions(+), 21 deletions(-)

Negative number of lines, another good point for this patch!

Reviewed-by: Alexandre Courbot 
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] arm, imx6, dts: add DT for aristainetos2 board

2015-05-20 Thread Heiko Schocher

Hello Shawn,

Am 21.05.2015 03:04, schrieb Shawn Guo:

On Wed, May 20, 2015 at 01:13:54PM +0200, Heiko Schocher wrote:

+ * Copyright (C) 2015 Heiko Schocher 
+ *
+ * This file is dual-licensed: you can use it either under the terms
+ * of the GPL or the X11 license, at your option. Note that this dual
+ * licensing only applies to this file, and not this project as a
+ * whole.
+ *
+ *  a) This file is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License as
+ * published by the Free Software Foundation; either version 2 of
+ * the License, or (at your option) any later version.
+ *
+ * This file is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public
+ * License along with this file; if not, write to the Free
+ * Software Foundation, Inc., 51 Franklin St, Fifth Floor, Boston,
+ * MA 02110-1301 USA


checkpatch warns that you should not include this paragraph because the
mail address might change in the future and it is contained in COPYING.


Hmm... Shawn mentioned to change it to the "GPL/X11 dual licence"
as in the arch/arm/boot/dts/imx6sl-warp.dts file ... so I copied this
from there ... is there a better option for this?


It seems I pointed you to a bad example.  Let me try again, see
arch/arm/boot/dts/imx6q-hummingboard.dts for example.


Ok, changed, thanks!

Hmm.. why not using the SPDX license identifier? This would save a
lot of lines ...

I try the changes Philipp suggested for the 7" display (using the
panel-simple driver for it) and post a v4.

bye,
Heiko
--
DENX Software Engineering GmbH,  Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


Re: [PATCH 3/4] perf: Use pmu_events_map table to create event aliases

2015-05-20 Thread Sukadev Bhattiprolu
Andi Kleen [a...@linux.intel.com] wrote:
| If you need something else in vfm to identify the CPU 
| can't you just add it there? I wouldn't really call it vfm, it's
| really a "abstract cpu identifier per architecture". So if you
| need pvr just add it there.

Ok. I will change vfm to cpuid_str and include pvr in it.

Sukadev

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


[EDT][PATCH] kernel/exit.c : Fix missing read_unlock

2015-05-20 Thread Maninder Singh
 EP-F6AA0618C49C4AEDA73BFF1B39950BAB
Hi,

From: Maninder Singh 

Subject: [PATCH 1/1] kernel/exit.c : Fix missing task_unlock

This patch adds missing read_unlock if do_wait_thread or ptrace_do_wait 
returns non zero.

Signed-off-by: Maninder Singh 
Signed-off-by: Vaneet Narang 
Reviewd-by: Akhilesh Kumar 
---
 kernel/exit.c |8 ++--
 1 files changed, 6 insertions(+), 2 deletions(-)

diff --git a/kernel/exit.c b/kernel/exit.c
index 22fcc05..31a061f 100644
--- a/kernel/exit.c
+++ b/kernel/exit.c
@@ -1486,12 +1486,16 @@ repeat:
tsk = current;
do {
retval = do_wait_thread(wo, tsk);
-   if (retval)
+   if (retval) {
+   read_unlock(&tasklist_lock);
goto end;
+   }
 
retval = ptrace_do_wait(wo, tsk);
-   if (retval)
+   if (retval) {
+   read_unlock(&tasklist_lock);
goto end;
+   }
 
if (wo->wo_flags & __WNOTHREAD)
break;
-- 
1.7.1

Thanks 
Maninder SinghN‹§²æìr¸›yúèšØb²X¬¶Ç§vØ^–)Þº{.nÇ+‰·¥Š{±‘êçzX§¶›¡Ü¨}©ž²Æ 
zÚ&j:+v‰¨¾«‘êçzZ+€Ê+zf£¢·hšˆ§~†­†Ûiÿûàz¹®w¥¢¸?™¨è­Ú&¢)ߢf”ù^jÇ«y§m…á@A«a¶Úÿ
0¶ìh®å’i

Re: [PATCH v6 3/6] arm64: Kprobes with single stepping support

2015-05-20 Thread David Long

On 05/20/15 12:39, Catalin Marinas wrote:

On Mon, Apr 20, 2015 at 04:19:44PM -0400, David Long wrote:

Add support for basic kernel probes(kprobes) and jump probes
(jprobes) for ARM64.

Kprobes utilizes software breakpoint and single step debug
exceptions supported on ARM v8.

A software breakpoint is placed at the probe address to trap the
kernel execution into the kprobe handler.

ARM v8 supports enabling single stepping before the break exception
return (ERET), with next PC in exception return address (ELR_EL1). The
kprobe handler prepares an executable memory slot for out-of-line
execution with a copy of the original instruction being probed, and
enables single stepping. The PC is set to the out-of-line slot address
before the ERET. With this scheme, the instruction is executed with the
exact same register context except for the PC (and DAIF) registers.


I wonder whether it would be simpler to use another software breakpoint
after the out of line instruction copy. You won't run the instructions
that change the PC anyway.


We put quite a bit of work into making single-step work.  I don't see 
any obvious advantage to trying to switch to a software breakpoint. 
Both are debug exceptions but SS does leave open the possibility of 
maybe eventually running some instructions that do change the PC.




Since an unconditional branch instruction within the kernel address
space can reach any point in the kernel (and modules), could we go a
step further and avoid the software breakpoint altogether, just generate
a branch instruction to the original location (after the software
breakpoint)?


Wouldn't a branch instruction have to make use of a register in order to 
span the whole address space?  How could you do that and have all the 
registers unmolested when you land back after the original probe point? 
 The thing that really kills this though is the fact we need to be able 
to run the pre and post functions before and *after* the XOL stepping.




As for simulating/emulating instructions, could we actually avoid it for
most of them where we can generate a similar instruction with the
corrected offset? If the out of line slot is somewhere within the kernel
data section, I think many of them can be re-encoded (e.g. branches).



Again, do we get enough displacement for this to always work?  A quick 
look at the ARMv8 ARM makes me think we get +/-128M offset for a branch 
and only +/-1M for a load literal.  For any given instruction type I 
don't think it works unless it works for all possible offsets.


-dl

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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: [RFD] linux-firmware key arrangement for firmware signing

2015-05-20 Thread Greg Kroah-Hartman
On Wed, May 20, 2015 at 07:46:13PM +0300, Petko Manolov wrote:
> On 15-05-20 17:24:46, One Thousand Gnomes wrote:
> > 
> > More to the point why do you want to sign firmware files ? Leaving aside 
> > the 
> > fact that someone will produce a device with GPLv3 firmware just to p*ss 
> > you 
> > off there's the rather more relevant fact that firmware for devices on a so 
> > called "trusted" platform already have signed firmware.
> 
> For "trusted" systems one would like to make sure everything that goes in has 
> known provenance.  Maybe this was the idea?

If so, then just do what people do today, verify their known valid disk
image before mounting it and then they know they can trust the data on
it to be use for whatever (including firmware.)  No kernel changes
needed, distro support is already there for this.

I too don't understand this need to sign something that you don't really
know what it is from some other company, just to send it to a separate
device that is going to do whatever it wants with it if it is signed or
not.

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 8/8] driver-core: allow enabling async probing for all modules and builtins

2015-05-20 Thread Greg Kroah-Hartman
On Wed, May 20, 2015 at 09:44:59AM -0700, Dmitry Torokhov wrote:
> On Wed, May 20, 2015 at 12:27:34AM -0700, Greg Kroah-Hartman wrote:
> > On Mon, Mar 30, 2015 at 04:20:10PM -0700, Dmitry Torokhov wrote:
> > > From: "Luis R. Rodriguez" 
> > > 
> > > Folks wishing to test enabling async probe for all built-in drivers
> > > and/or for all modules can use
> > > __DEBUG__kernel_force_builtin_async_probe or
> > > __DEBUG__kernel_force_modules_async_probe kernel parameters.
> > > 
> > > Activating either one will taint your kernel.
> > > 
> > > Signed-off-by: Luis R. Rodriguez 
> > > [Dmitry: split off from another patch, split into 2 parameters, moved
> > > over to core_param_unsafe()]
> > > Signed-off-by: Dmitry Torokhov 
> > 
> > I've dropped this from my tree as I don't want to add these options,
> > only to have to remove them later on when it's found out that these were
> > a bad idea.
> 
> OK.
> 
> >
> > I don't want to create a user api that we have to keep around for
> > forever, and this would be such a thing (specifying how the kernel
> > probing works.)
> 
> Given that they are marked as __DEBUG and taint the kernel I do not
> believe they shoudl be considered as an API/ABI. We can emphasise this
> in docs and/or kernel messages.

But they are options a user can set on the command line, and changing
command lines is a pain.  Yes, it's a bit odd name, but we don't have
any other such naming scheme for command line options, so I don't know
what to suggest here.

> >  For debugging, can't you just patch up your kernel and
> 
> I can, but I do not have all hardware in my possession to validate the
> behavior.
> 
> > test this out?  What's the real use of this?  Who do you want to enable
> > these?  And why?  What will you do with the information?
> 
> The expectation was that distribution developers might use these
> switches when evaluating whether they are ready to switch to
> asynchronous probing.

Distro developers will never do that, they have to support just too many
different hardware types.  And there's no real gain here for them.

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 v4 1/2] serial_core: add pci uart early console support

2015-05-20 Thread Greg Kroah-Hartman
On Wed, May 20, 2015 at 02:17:40PM -0700, Bin Gao wrote:
> On some Intel Atom SoCs, the legacy IO port UART(0x3F8) is not available.
> Instead, a 8250 compatible PCI uart can be used as early console.
> This patch adds pci support to the 8250 early console driver uart8250.
> For example, to enable pci uart(00:21.3) as early console on these
> platforms, append the following line to the kernel command line
> (assume baud rate is 115200):
> earlyprintk=uart8250,pci32,0:24.2,115200n8
> 
> Signed-off-by: Bin Gao 
> ---
>  arch/x86/Kconfig |   1 +
>  drivers/pci/Kconfig  |  11 +++
>  drivers/tty/serial/earlycon.c|   9 +++
>  drivers/tty/serial/serial_core.c | 145 
> ++-
>  4 files changed, 164 insertions(+), 2 deletions(-)

What changed in this version?

You can't just put "v4" without giving us some hint as to the
differences here, sorry.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


[PATCH 1/2] devicetree:bindings: add devicetree bindings for ceva ahci

2015-05-20 Thread Suneel Garapati
adds bindings for CEVA AHCI SATA controller. optional property
broken-gen2 is useful incase of hardware speed limitation.

Signed-off-by: Suneel Garapati 
---
 Documentation/devicetree/bindings/ata/ahci-ceva.txt | 20 
 1 file changed, 20 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/ata/ahci-ceva.txt

diff --git a/Documentation/devicetree/bindings/ata/ahci-ceva.txt 
b/Documentation/devicetree/bindings/ata/ahci-ceva.txt
new file mode 100644
index 000..7ca8b97
--- /dev/null
+++ b/Documentation/devicetree/bindings/ata/ahci-ceva.txt
@@ -0,0 +1,20 @@
+Binding for CEVA AHCI SATA Controller
+
+Required properties:
+  - reg: Physical base address and size of the controller's register area.
+  - compatible: Compatibility string. Must be 'ceva,ahci-1v84'.
+  - clocks: Input clock specifier. Refer to common clock bindings.
+  - interrupts: Interrupt specifier. Refer to interrupt binding.
+
+Optional properties:
+  - ceva,broken-gen2: limit to gen1 speed instead of gen2.
+
+Examples:
+   ahci@fd0c {
+   compatible = "ceva,ahci-1v84";
+   reg = <0xfd0c 0x200>;
+   interrupt-parent = <&gic>;
+   interrupts = <0 133 4>;
+   clocks = <&clkc SATA_CLK_ID>;
+   ceva,broken-gen2;
+   };
--
2.1.2
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


[PATCH 0/2] Support for CEVA SATA Host controller

2015-05-20 Thread Suneel Garapati
Adds support for CEVA SATA Host controller found on Xilinx Zynq
Ultrascale+ MPSoC.

Suneel Garapati (2):
  devicetree:bindings: add devicetree bindings for ceva ahci
  drivers: ata: add support for Ceva sata host controller

 .../devicetree/bindings/ata/ahci-ceva.txt  |  20 ++
 drivers/ata/Kconfig|   9 +
 drivers/ata/Makefile   |   1 +
 drivers/ata/ahci_ceva.c| 225 +
 4 files changed, 255 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/ata/ahci-ceva.txt
 create mode 100644 drivers/ata/ahci_ceva.c

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


Re: [REGRESSION] 4.1-rc4: Sound muted after boot

2015-05-20 Thread Takashi Iwai
At Wed, 20 May 2015 16:31:55 +0200,
Martin Steigerwald wrote:
> 
> Hello!
> 
> On ThinkPad T520 (Intel Sandybridge) with 4.14-rc4 + two BTRFS patches and 
> one Intel P-State debug patch I have no sound output on internal Intel HD 
> audio codec.
> 
> According to ThinkPad T520 LED with striked-through speaker the loud speaker 
> is in disabled state. Also KDE´s Phonon says a soundcard is missing. In 
> alsa-mixer I see nothing as MM for muted. If I press the key next to the LED 
> I get a notification on the desktop that loud speaker has been enabled / 
> disabled, but the LED still is on for it being disabled.
> 
> I do not hear anything in Amarok or with aplay. alsa-mixer sound volumes are 
> 100 for master and PCM. I also tried with disabling "Auto-Mute Mod", but 
> still no sound.
>  
> When I reboot and in BIOS or GRUB press the key then the LED toggles state.
> 
> When I reboot into Linux 4.0.1 sound is working fine and loud speaker 
> disabled LED is toggled off, so I bet this is a regression 4.1-rc4 compared 
> to 4.0.1.

Please run alsa-info.sh at both working and non-working cases (with
old and new kernels), and attach the outputs. Run the script with
--no-upload option.

Also, such a problem is rather the device permissions problem.
Check the device permissions of /dev/snd/* files (also check getfacl
/dev/snd/*, too).


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


Re: [PATCH v2 2/3] fbcon: use the cursor blink interval provided by vt

2015-05-20 Thread Greg Kroah-Hartman
On Wed, May 20, 2015 at 02:36:17PM +0200, Thierry Reding wrote:
> On Tue, May 19, 2015 at 04:41:12PM -0700, Greg Kroah-Hartman wrote:
> > On Tue, May 19, 2015 at 11:52:29PM +0200, Thierry Reding wrote:
> > > On Tue, May 19, 2015 at 02:45:19PM -0700, Kevin Hilman wrote:
> > > > On Tue, May 19, 2015 at 2:40 PM, Thierry Reding
> > > >  wrote:
> > > > > On Tue, May 19, 2015 at 02:15:41PM -0700, Kevin Hilman wrote:
> > > > >> On Thu, Mar 26, 2015 at 6:56 AM, Scot Doyle  
> > > > >> wrote:
> > > > >> > vt now provides a cursor blink interval via vc_data. Use this
> > > > >> > interval instead of the currently hardcoded 200 msecs. Store it in
> > > > >> > fbcon_ops to avoid locking the console in cursor_timer_handler().
> > > > >> >
> > > > >> > Signed-off-by: Scot Doyle 
> > > > >> > Acked-by: Pavel Machek 
> > > > >>
> > > > >> This patch hit next-20150519 in the form of commit 27a4c827c34a
> > > > >> (fbcon: use the cursor blink interval provided by vt) and has caused
> > > > >> boot failure on a handful of ARM platforms when booting a MMC root
> > > > >> filesystem.  This error was spotted by the kernelci.org bot on
> > > > >> exynos5800-peach-pi[1] and Thierry and Daniel (Cc'd) have seen it on
> > > > >> some tegra platforms too.
> > > > >>
> > > > >> Thierry spotted this commit as a potential cause, and both Daniel and
> > > > >> I have reverted and boot tested on exynos5 and tegra respectively and
> > > > >> the boot panics disappear.
> > > > >
> > > > > FWIW, if I apply the below on top of next-20150519 things seem to be
> > > > > back to normal as well:
> > > > >
> > > > > diff --git a/drivers/video/console/fbcon.c 
> > > > > b/drivers/video/console/fbcon.c
> > > > > index 05b1d1a71ef9..658c34bb9076 100644
> > > > > --- a/drivers/video/console/fbcon.c
> > > > > +++ b/drivers/video/console/fbcon.c
> > > > > @@ -1310,8 +1310,9 @@ static void fbcon_cursor(struct vc_data *vc, 
> > > > > int mode)
> > > > > return;
> > > > >
> > > > > ops->cur_blink_jiffies = 
> > > > > msecs_to_jiffies(vc->vc_cur_blink_ms);
> > > > > -   fbcon_del_cursor_timer(info);
> > > > > -   if (!(vc->vc_cursor_type & 0x10))
> > > > > +   if (vc->vc_cursor_type & 0x10)
> > > > > +   fbcon_del_cursor_timer(info);
> > > > > +   else
> > > > > fbcon_add_cursor_timer(info);
> > > > >
> > > > > ops->cursor_flash = (mode == CM_ERASE) ? 0 : 1;
> > > > 
> > > > Applying this on next-20150519 makes my exynos board happily boot again 
> > > > as well.
> > > > 
> > > > Tested-by: Kevin Hilman 
> > > 
> > > Excellent. Greg, Scot, any opinions on whether or not this is the right
> > > thing to do? It restores a bit that looks suspiciously like it snuck in
> > > in the original (at least it isn't documented in the commit message).
> > > 
> > > Greg, feel free to squash this in if everybody agrees this is good to
> > > go. If you prefer a patch on top let me know and I'll come up with a
> > > proper commit message.
> > 
> > Please send a real patch and I'll apply it on top, as I can't rebase my
> > public tree.
> 
> Attached.

Ugh, no, please resend it as a stand-alone patch, I can't easily apply
attachments.

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: [RESEND][PATCH] Bluetooth: Make request workqueue freezable

2015-05-20 Thread Takashi Iwai
At Wed, 20 May 2015 16:42:44 -0700,
Laura Abbott wrote:
> 
> On 05/20/2015 05:44 AM, Takashi Iwai wrote:
> > At Wed, 20 May 2015 11:46:31 +0200,
> > Marcel Holtmann wrote:
> >>
> >> Hi Oliver,
> >>
>  The data is cached in RAM.  More specifically, the former loaded
>  firmware files are reloaded and saved at suspend for each device
>  object.  See fw_pm_notify() in firmware_class.c.
> >>>
> >>> OK, this may be a stupid idea, but do we know the firmware
> >>> was successfully loaded in the first place?
> >>> Also btusb is in the habit of falling back to a generic
> >>> firmware in some places. It seems to me that caching
> >>> firmware is conceptually not enough, but we'd also need
> >>> to record the absence of firmware images.
> >>
> >> in a lot of cases the firmware is optional. The device will operate fine 
> >> without the firmware. There are a few devices where the firmware is 
> >> required, but for many it just contains patches.
> >>
> >> It would be nice if we could tell request_firmware() if it is optional or 
> >> mandatory firmware. Or if it should just cache the status of a missing 
> >> firmware as well.
> >
> > OK, below is a quick hack to record the failed f/w files, too.
> > Not sure whether this helps, though.  Proper tests are appreciated.
> >
> >
> 
> This doesn't quite work. We end up with the name on fw_names but
> the firmware isn't actually on the firmware cache list.
> 
> If request_firmware fails to get the firmware from the filesystem,
> release firmware will be called which is going to free the
> firmware_buf which has been marked as failed anyway. The only
> way to make this work would be to always piggy back and increase
> the ref so it always stays around. But this also marks the firmware
> as a permanent failure. There would need to be a hook somewhere
> to force a cache drop, else there would be no way to add new
> firmware to a running system without a reboot.
> 
> Perhaps we split the difference: keep a list of firmware images
> that failed to load in the past and if one is requested during
> a time when usermodehelper isn't available, silently return an
> error? This way, if correct firmware is loaded at a regular time
> the item can be removed from the list.

Well, IMO, it's way too much expectation for the generic f/w loader.
The driver itself must know already which should be really loaded.
The fact is that it's the driver who calls the function that might not
work in the resume path.  So the driver can deal with such exceptions
at best.

This can be either delaying the f/w loading via proper UMH lock (like
my former patch or your patch) or avoiding the f/w request of
non-existing files that the driver already knows of.


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


[PATCH 6/6] perf, tools: Add a --no-desc flag to perf list

2015-05-20 Thread Andi Kleen
From: Andi Kleen 

Add a --no-desc flag to perf list to not print the event descriptions
that were earlier added for JSON events. This may be useful to
get a less crowded listing.

It's still default to print descriptions as that is the more useful
default for most users.

v2: Rename --quiet to --no-desc. Add option to man page.
Signed-off-by: Andi Kleen 
---
 tools/perf/Documentation/perf-list.txt |  8 +++-
 tools/perf/builtin-list.c  | 12 
 tools/perf/util/parse-events.c |  4 ++--
 tools/perf/util/parse-events.h |  2 +-
 tools/perf/util/pmu.c  |  4 ++--
 tools/perf/util/pmu.h  |  2 +-
 6 files changed, 21 insertions(+), 11 deletions(-)

diff --git a/tools/perf/Documentation/perf-list.txt 
b/tools/perf/Documentation/perf-list.txt
index bada893..9507552 100644
--- a/tools/perf/Documentation/perf-list.txt
+++ b/tools/perf/Documentation/perf-list.txt
@@ -8,13 +8,19 @@ perf-list - List all symbolic event types
 SYNOPSIS
 
 [verse]
-'perf list' [hw|sw|cache|tracepoint|pmu|event_glob]
+'perf list' [--no-desc] [hw|sw|cache|tracepoint|pmu|event_glob]
 
 DESCRIPTION
 ---
 This command displays the symbolic event types which can be selected in the
 various perf commands with the -e option.
 
+OPTIONS
+---
+--no-desc::
+Don't print descriptions.
+
+
 [[EVENT_MODIFIERS]]
 EVENT MODIFIERS
 ---
diff --git a/tools/perf/builtin-list.c b/tools/perf/builtin-list.c
index af5bd05..3f058f7 100644
--- a/tools/perf/builtin-list.c
+++ b/tools/perf/builtin-list.c
@@ -16,16 +16,20 @@
 #include "util/pmu.h"
 #include "util/parse-options.h"
 
+static bool desc_flag = true;
+
 int cmd_list(int argc, const char **argv, const char *prefix __maybe_unused)
 {
int i;
bool raw_dump = false;
struct option list_options[] = {
OPT_BOOLEAN(0, "raw-dump", &raw_dump, "Dump raw events"),
+   OPT_BOOLEAN('d', "desc", &desc_flag,
+   "Print extra event descriptions. --no-desc to not 
print."),
OPT_END()
};
const char * const list_usage[] = {
-   "perf list [hw|sw|cache|tracepoint|pmu|event_glob]",
+   "perf list [--no-desc] [hw|sw|cache|tracepoint|pmu|event_glob]",
NULL
};
 
@@ -40,7 +44,7 @@ int cmd_list(int argc, const char **argv, const char *prefix 
__maybe_unused)
printf("\nList of pre-defined events (to be used in -e):\n\n");
 
if (argc == 0) {
-   print_events(NULL, raw_dump);
+   print_events(NULL, raw_dump, !desc_flag);
return 0;
}
 
@@ -59,13 +63,13 @@ int cmd_list(int argc, const char **argv, const char 
*prefix __maybe_unused)
 strcmp(argv[i], "hwcache") == 0)
print_hwcache_events(NULL, raw_dump);
else if (strcmp(argv[i], "pmu") == 0)
-   print_pmu_events(NULL, raw_dump);
+   print_pmu_events(NULL, raw_dump, !desc_flag);
else {
char *sep = strchr(argv[i], ':'), *s;
int sep_idx;
 
if (sep == NULL) {
-   print_events(argv[i], raw_dump);
+   print_events(argv[i], raw_dump, !desc_flag);
continue;
}
sep_idx = sep - argv[i];
diff --git a/tools/perf/util/parse-events.c b/tools/perf/util/parse-events.c
index 80a50fd..750dbd7 100644
--- a/tools/perf/util/parse-events.c
+++ b/tools/perf/util/parse-events.c
@@ -1527,7 +1527,7 @@ out_enomem:
 /*
  * Print the help text for the event symbols:
  */
-void print_events(const char *event_glob, bool name_only)
+void print_events(const char *event_glob, bool name_only, bool quiet_flag)
 {
print_symbol_events(event_glob, PERF_TYPE_HARDWARE,
event_symbols_hw, PERF_COUNT_HW_MAX, name_only);
@@ -1537,7 +1537,7 @@ void print_events(const char *event_glob, bool name_only)
 
print_hwcache_events(event_glob, name_only);
 
-   print_pmu_events(event_glob, name_only);
+   print_pmu_events(event_glob, name_only, quiet_flag);
 
if (event_glob != NULL)
return;
diff --git a/tools/perf/util/parse-events.h b/tools/perf/util/parse-events.h
index e236f1b..9f2b57d 100644
--- a/tools/perf/util/parse-events.h
+++ b/tools/perf/util/parse-events.h
@@ -127,7 +127,7 @@ void parse_events_update_lists(struct list_head *list_event,
 void parse_events_evlist_error(struct parse_events_evlist *data,
   int idx, const char *str);
 
-void print_events(const char *event_glob, bool name_only);
+void print_events(const char *event_glob, bool name_only, bool quiet);
 
 struct event_symbol {
const char  *symbol;
diff --git a/tools/perf/util/pmu.c b/tools/perf/util/pmu.c
index a3

[PATCH 2/6] perf, tools: Allow events with dot

2015-05-20 Thread Andi Kleen
From: Andi Kleen 

The Intel events use a dot to separate event name and unit mask.
Allow dot in names in the scanner, and remove special handling
of dot as EOF. Also remove the hack in jevents to replace dot
with underscore. This way dotted events can be specified
directly by the user.

I'm not fully sure this change to the scanner is correct
(what was the dot special case good for?), but I haven't
found anything that breaks with it so far at least.

V2: Add the dot to name too, to handle events outside cpu//
Acked-by: Namhyung Kim 
Signed-off-by: Andi Kleen 
---
 tools/perf/util/parse-events.l | 5 ++---
 1 file changed, 2 insertions(+), 3 deletions(-)

diff --git a/tools/perf/util/parse-events.l b/tools/perf/util/parse-events.l
index 09e738f..13cef3c 100644
--- a/tools/perf/util/parse-events.l
+++ b/tools/perf/util/parse-events.l
@@ -119,8 +119,8 @@ event   [^,{}/]+
 num_dec[0-9]+
 num_hex0x[a-fA-F0-9]+
 num_raw_hex[a-fA-F0-9]+
-name   [a-zA-Z_*?][a-zA-Z0-9_*?]*
-name_minus [a-zA-Z_*?][a-zA-Z0-9\-_*?]*
+name   [a-zA-Z_*?][a-zA-Z0-9_*?.]*
+name_minus [a-zA-Z_*?][a-zA-Z0-9\-_*?.]*
 /* If you add a modifier you need to update check_modifier() */
 modifier_event [ukhpGHSDI]+
 modifier_bp[rwx]{1,3}
@@ -165,7 +165,6 @@ modifier_bp [rwx]{1,3}
return PE_EVENT_NAME;
}
 
-.  |
 <>{
BEGIN(INITIAL);
REWIND(0);
-- 
2.1.0

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


[PATCH 1/6] perf, tools: Handle header line in mapfile

2015-05-20 Thread Andi Kleen
From: Andi Kleen 

Support a header line in the mapfile.csv, to match the existing
mapfiles

Signed-off-by: Andi Kleen 
---
 tools/perf/pmu-events/jevents.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/tools/perf/pmu-events/jevents.c b/tools/perf/pmu-events/jevents.c
index 3afa6e9..0ad5574 100644
--- a/tools/perf/pmu-events/jevents.c
+++ b/tools/perf/pmu-events/jevents.c
@@ -453,6 +453,8 @@ static int process_mapfile(FILE *outfp, char *fpath)
 
if (line[0] == '#')
continue;
+   if (!strncmp(line, "Family", 6))
+   continue;
 
if (line[strlen(line)-1] != '\n') {
/* TODO Deal with lines longer than 16K */
-- 
2.1.0

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


[PATCH 3/6] perf, tools: Support CPU id matching for x86

2015-05-20 Thread Andi Kleen
From: Andi Kleen 

Implement the code to match CPU types to mapfile types for x86
based on CPUID. This extends an existing similar function,
but changes it to use the x86 mapfile cpu description.
This allows to resolve event lists generated by jevents.

Signed-off-by: Andi Kleen 
---
 tools/perf/arch/x86/util/header.c | 23 ---
 1 file changed, 20 insertions(+), 3 deletions(-)

diff --git a/tools/perf/arch/x86/util/header.c 
b/tools/perf/arch/x86/util/header.c
index 146d12a..28d8c08 100644
--- a/tools/perf/arch/x86/util/header.c
+++ b/tools/perf/arch/x86/util/header.c
@@ -19,8 +19,8 @@ cpuid(unsigned int op, unsigned int *a, unsigned int *b, 
unsigned int *c,
: "a" (op));
 }
 
-int
-get_cpuid(char *buffer, size_t sz)
+static int
+__get_cpuid(char *buffer, size_t sz, const char *fmt)
 {
unsigned int a, b, c, d, lvl;
int family = -1, model = -1, step = -1;
@@ -48,7 +48,7 @@ get_cpuid(char *buffer, size_t sz)
if (family >= 0x6)
model += ((a >> 16) & 0xf) << 4;
}
-   nb = scnprintf(buffer, sz, "%s,%u,%u,%u$", vendor, family, model, step);
+   nb = scnprintf(buffer, sz, fmt, vendor, family, model, step);
 
/* look for end marker to ensure the entire data fit */
if (strchr(buffer, '$')) {
@@ -57,3 +57,20 @@ get_cpuid(char *buffer, size_t sz)
}
return -1;
 }
+
+int
+get_cpuid(char *buffer, size_t sz)
+{
+   return __get_cpuid(buffer, sz, "%s,%u,%u,%u$");
+}
+
+bool arch_pmu_events_match_cpu(const char *vfm,
+  const char *version __maybe_unused,
+  const char *type __maybe_unused)
+{
+   char buf[128];
+
+   if (__get_cpuid(buf, sizeof buf, "%s-%u-%X$") < 0)
+   return false;
+   return !strcmp(vfm, buf);
+}
-- 
2.1.0

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


perf, tools: Event files for Intel x86

2015-05-20 Thread Andi Kleen
This patchkit extends Sukadev builtin event list patches for Intel x86.
With that perf can build in event lists.

This also adds some missing features from the older JSON patchkits,
in particular the ability to print descriptions.

I am not posting the actual event files, because they are gigantic
(several MB) but you can get them from git here:

git://git.kernel.org/pub/scm/linux/kernel/git/ak/linux-misc.git 
perf/builtion-json-1

Currently only core events are included, not uncore.

-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 5/6] perf, tools: Query terminal width and use in perf list

2015-05-20 Thread Andi Kleen
From: Andi Kleen 

Automatically adapt the now wider and word wrapped perf list
output to wider terminals. This requires querying the terminal
before the auto pager takes over, and exporting this
information from the pager subsystem.

Acked-by: Namhyung Kim 
Signed-off-by: Andi Kleen 
---
 tools/perf/util/cache.h |  1 +
 tools/perf/util/pager.c | 15 +++
 tools/perf/util/pmu.c   |  3 ++-
 3 files changed, 18 insertions(+), 1 deletion(-)

diff --git a/tools/perf/util/cache.h b/tools/perf/util/cache.h
index fbcca21..edf0398 100644
--- a/tools/perf/util/cache.h
+++ b/tools/perf/util/cache.h
@@ -33,6 +33,7 @@ extern void setup_pager(void);
 extern const char *pager_program;
 extern int pager_in_use(void);
 extern int pager_use_color;
+int pager_get_columns(void);
 
 char *alias_lookup(const char *alias);
 int split_cmdline(char *cmdline, const char ***argv);
diff --git a/tools/perf/util/pager.c b/tools/perf/util/pager.c
index 31ee02d..9761202 100644
--- a/tools/perf/util/pager.c
+++ b/tools/perf/util/pager.c
@@ -1,6 +1,7 @@
 #include "cache.h"
 #include "run-command.h"
 #include "sigchain.h"
+#include 
 
 /*
  * This is split up from the rest of git so that we can do
@@ -8,6 +9,7 @@
  */
 
 static int spawned_pager;
+static int pager_columns;
 
 static void pager_preexec(void)
 {
@@ -47,9 +49,12 @@ static void wait_for_pager_signal(int signo)
 void setup_pager(void)
 {
const char *pager = getenv("PERF_PAGER");
+   struct winsize sz;
 
if (!isatty(1))
return;
+   if (ioctl(1, TIOCGWINSZ, &sz) == 0)
+   pager_columns = sz.ws_col;
if (!pager) {
if (!pager_program)
perf_config(perf_default_config, NULL);
@@ -98,3 +103,13 @@ int pager_in_use(void)
env = getenv("PERF_PAGER_IN_USE");
return env ? perf_config_bool("PERF_PAGER_IN_USE", env) : 0;
 }
+
+int pager_get_columns(void)
+{
+   char *s;
+
+   s = getenv("COLUMNS");
+   if (s)
+   return atoi(s);
+   return (pager_columns ? pager_columns : 80) - 2;
+}
diff --git a/tools/perf/util/pmu.c b/tools/perf/util/pmu.c
index a90a8ee..a34cbdb 100644
--- a/tools/perf/util/pmu.c
+++ b/tools/perf/util/pmu.c
@@ -13,6 +13,7 @@
 #include "pmu-events/pmu-events.h" // Move to global file???
 #include "cpumap.h"
 #include "header.h"
+#include "cache.h"
 
 struct perf_pmu_format {
char *name;
@@ -1026,7 +1027,7 @@ void print_pmu_events(const char *event_glob, bool 
name_only)
int len, j;
struct pair *aliases;
int numdesc = 0;
-   int columns = 78;
+   int columns = pager_get_columns();
 
pmu = NULL;
len = 0;
-- 
2.1.0

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


[PATCH 4/6] perf, tools: Support alias descriptions

2015-05-20 Thread Andi Kleen
From: Andi Kleen 

Add support to print alias descriptions in perf list, which
are taken from the generated event files.

The sorting code is changed to put the events with descriptions
at the end. The descriptions are printed as possibly multiple word
wrapped lines.

Example output:

% perf list
...
  arith.fpu_div
   [Divide operations executed]
  arith.fpu_div_active
   [Cycles when divider is busy executing divide operations]

Signed-off-by: Andi Kleen 
---
 tools/perf/util/pmu.c | 84 +++
 tools/perf/util/pmu.h |  1 +
 2 files changed, 65 insertions(+), 20 deletions(-)

diff --git a/tools/perf/util/pmu.c b/tools/perf/util/pmu.c
index 99af5d4..a90a8ee 100644
--- a/tools/perf/util/pmu.c
+++ b/tools/perf/util/pmu.c
@@ -232,10 +232,7 @@ static int __perf_pmu__new_alias(struct list_head *list, 
char *name, char *dir,
perf_pmu__parse_snapshot(alias, dir, name);
}
 
-   /*
-* TODO: pickup description from Andi's patchset
-*/
-   //alias->desc = desc ? strdpu(desc) : NULL;
+   alias->desc = desc ? strdup(desc) : NULL;
 
list_add_tail(&alias->list, list);
 
@@ -982,11 +979,42 @@ static char *format_alias_or(char *buf, int len, struct 
perf_pmu *pmu,
return buf;
 }
 
-static int cmp_string(const void *a, const void *b)
+struct pair {
+   char *name;
+   char *desc;
+};
+
+static int cmp_pair(const void *a, const void *b)
 {
-   const char * const *as = a;
-   const char * const *bs = b;
-   return strcmp(*as, *bs);
+   const struct pair *as = a;
+   const struct pair *bs = b;
+
+   /* Put extra events last */
+   if (!!as->desc != !!bs->desc)
+   return !!as->desc - !!bs->desc;
+   return strcmp(as->name, bs->name);
+}
+
+static void wordwrap(char *s, int start, int max, int corr)
+{
+   int column = start;
+   int n;
+
+   while (*s) {
+   int wlen = strcspn(s, " \t");
+
+   if (column + wlen >= max && column > start) {
+   printf("\n%*s", start, "");
+   column = start + corr;
+   }
+   n = printf("%s%.*s", column > start ? " " : "", wlen, s);
+   if (n <= 0)
+   break;
+   s += wlen;
+   column += n;
+   while (isspace(*s))
+   s++;
+   }
 }
 
 void print_pmu_events(const char *event_glob, bool name_only)
@@ -996,7 +1024,9 @@ void print_pmu_events(const char *event_glob, bool 
name_only)
char buf[1024];
int printed = 0;
int len, j;
-   char **aliases;
+   struct pair *aliases;
+   int numdesc = 0;
+   int columns = 78;
 
pmu = NULL;
len = 0;
@@ -1006,14 +1036,15 @@ void print_pmu_events(const char *event_glob, bool 
name_only)
if (pmu->selectable)
len++;
}
-   aliases = zalloc(sizeof(char *) * len);
+   aliases = zalloc(sizeof(struct pair) * len);
if (!aliases)
goto out_enomem;
pmu = NULL;
j = 0;
while ((pmu = perf_pmu__scan(pmu)) != NULL) {
list_for_each_entry(alias, &pmu->aliases, list) {
-   char *name = format_alias(buf, sizeof(buf), pmu, alias);
+   char *name = alias->desc ? alias->name :
+   format_alias(buf, sizeof(buf), pmu, alias);
bool is_cpu = !strcmp(pmu->name, "cpu");
 
if (event_glob != NULL &&
@@ -1022,37 +1053,50 @@ void print_pmu_events(const char *event_glob, bool 
name_only)
   event_glob
continue;
 
-   if (is_cpu && !name_only)
+   if (is_cpu && !name_only && !alias->desc)
name = format_alias_or(buf, sizeof(buf), pmu, 
alias);
 
-   aliases[j] = strdup(name);
-   if (aliases[j] == NULL)
-   goto out_enomem;
+   aliases[j].name = name;
+   if (is_cpu && !name_only && !alias->desc)
+   aliases[j].name = format_alias_or(buf, 
sizeof(buf),
+ pmu, alias);
+   aliases[j].name = strdup(aliases[j].name);
+   /* failure harmless */
+   aliases[j].desc = alias->desc;
j++;
}
if (pmu->selectable) {
char *s;
if (asprintf(&s, "%s//", pmu->name) < 0)
goto out_enomem;
-   aliases[j] = s;
+   aliases[j].name = s;
j++;
}
}
   

Re: [PATCH v3 1/2] perf/kvm: Port perf kvm to powerpc

2015-05-20 Thread Hemant Kumar

Hi Scott,

On 05/13/2015 08:52 AM, Scott Wood wrote:

On Tue, 2015-05-12 at 21:34 +0530, Hemant Kumar wrote:

Hi Scott,

On 05/12/2015 03:38 AM, Scott Wood wrote:

On Fri, 2015-05-08 at 06:37 +0530, Hemant Kumar wrote:

diff --git a/arch/powerpc/include/uapi/asm/kvm_perf.h 
b/arch/powerpc/include/uapi/asm/kvm_perf.h
new file mode 100644
index 000..30fa670
--- /dev/null
+++ b/arch/powerpc/include/uapi/asm/kvm_perf.h
@@ -0,0 +1,15 @@
+#ifndef _ASM_POWERPC_KVM_PERF_H
+#define _ASM_POWERPC_KVM_PERF_H
+
+#include 
+#include 
+
+#define DECODE_STR_LEN 20
+
+#define VCPU_ID "vcpu_id"
+
+#define KVM_ENTRY_TRACE "kvm_hv:kvm_guest_enter"
+#define KVM_EXIT_TRACE "kvm_hv:kvm_guest_exit"
+#define KVM_EXIT_REASON "trap"
+
+#endif /* _ASM_POWERPC_KVM_PERF_H */

Please make sure that anything book3s-specific is named that way.

Are you suggesting to name it to something like _ASM_POWERPC_BOOK3S_PERF_H ?

My concern is seeing a generically named "kvm_perf.h" include a file
called "trace_book3s.h" which defines "kvm_trace_symbol_hcall" with
presumably book3s-specific content, as well as wondering how much of the
rest of the file would be applicable if booke PPC were to implement perf
kvm.

I don't know enough about perf kvm to answer that question, but I've
seen enough cases of book3s or pseries specific code that was apparently
written with the belief that no other ppc64 implementations exist, or
that no other ppc implementations would want to implement a certain
feature, to be suspicous.  Usually such cases can be dealt with after
the fact (albeit not as easily as if things were organized/namespaced
properly from the beginning), but this is uapi...

-Scott



___
Linuxppc-dev mailing list
linuxppc-...@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev


Tried to address your comments in v4 :
http://www.mail-archive.com/linuxppc-dev@lists.ozlabs.org/msg89490.html
and
http://www.mail-archive.com/linuxppc-dev@lists.ozlabs.org/msg89485.html

--
Thanks,
Hemant Kumar

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


Re: [PATCH v7 6/7] clk: hi6220: Clock driver support for Hisilicon hi6220 SoC

2015-05-20 Thread Bintian

Hello Stephen, Arnd,

On 2015/5/21 6:25, Stephen Boyd wrote:

On 05/20/15 03:29, Bintian Wang wrote:

Add clock drivers for hi6220 SoC, this driver controls the SoC
registers to supply different clocks to different IPs in the SoC.

We add one divider clock for hi6220 because the divider in hi6220
also has a mask bit but it doesnot obey the rule defined by flag
"CLK_DIVIDER_HIWORD_MASK", we can not get index of the mask bit by
left shift fixed bits (e.g. 16 bits), so we add this divider clock
to handle it.

Signed-off-by: Jorge Ramirez-Ortiz 
Signed-off-by: Bintian Wang 
Acked-by: Haojian Zhuang 
Reviewed-by: Zhangfei Gao 
Tested-by: Will Deacon 
Tested-by: Tyler Baker 
---
  drivers/clk/Kconfig   |2 +
  drivers/clk/Makefile  |4 +-
  drivers/clk/hisilicon/Kconfig |6 +
  drivers/clk/hisilicon/Makefile|3 +-
  drivers/clk/hisilicon/clk-hi6220.c|  291 +
  drivers/clk/hisilicon/clk.c   |   29 +++
  drivers/clk/hisilicon/clk.h   |   17 ++
  drivers/clk/hisilicon/clkdivider-hi6220.c |  156 
  include/dt-bindings/clock/hi6220-clock.h  |  173 +
  9 files changed, 677 insertions(+), 4 deletions(-)
  create mode 100644 drivers/clk/hisilicon/Kconfig
  create mode 100644 drivers/clk/hisilicon/clk-hi6220.c
  create mode 100644 drivers/clk/hisilicon/clkdivider-hi6220.c
  create mode 100644 include/dt-bindings/clock/hi6220-clock.h

diff --git a/drivers/clk/Kconfig b/drivers/clk/Kconfig
index 9897f35..18bb930 100644
--- a/drivers/clk/Kconfig
+++ b/drivers/clk/Kconfig
@@ -150,6 +150,8 @@ config COMMON_CLK_CDCE706
---help---
  This driver supports TI CDCE706 programmable 3-PLL clock synthesizer.

+source "drivers/clk/hisilicon/Kconfig"
+
  source "drivers/clk/qcom/Kconfig"



There's going to be a merge conflict here if this doesn't go through the
clk tree.

Hello Arnd, how about the clk driver of hi6220 goes through the clk
tree and those dts and arch patches go through arm-soc?

If there is no problem, I will split the clock header file to a
single patch for your convenience.




+
+static void __init hi6220_clk_sys_init(struct device_node *np)
+{
+   struct hisi_clock_data *clk_data;
+
+   clk_data = hisi_clk_init(np, HI6220_SYS_NR_CLKS);
+   if (!clk_data)
+   return;
+
+   hisi_clk_register_gate_sep(hi6220_separated_gate_clks_sys,
+   ARRAY_SIZE(hi6220_separated_gate_clks_sys), clk_data);
+
+   hisi_clk_register_mux(hi6220_mux_clks_sys,
+   ARRAY_SIZE(hi6220_mux_clks_sys), clk_data);
+
+   hi6220_clk_register_divider(hi6220_div_clks_sys,
+   ARRAY_SIZE(hi6220_div_clks_sys), clk_data);
+
+   if (!clk_data_ao)
+   return;
+
+   /* enable high speed clock on UART1 mux */
+   clk_set_parent(clk_data->clk_data.clks[HI6220_UART1_SRC],
+   clk_data_ao->clk_data.clks[HI6220_150M]);


Sorry I missed this one earlier. Can we do this clk_set_parent() through
assigned-parents instead?

Uart1 has two clock parents in hi6220, and use "clk_tcxo" by default,
we use uart1 to connect BT in HiKey, and switch to "clk_150m" for high 
speed mode of BT, but pl011 has no code to set clock rate or set clock

parents operation, so it's a easy way to do that here.

I expected an #include  for the

usage of clk_set_parent() here so I didn't look hard to see if consumer
APIs were being used.

OK, I will add in next version 8.

Thanks,

Bintian


Otherwise the patch looks fine.



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


Re: [PATCH v2 0/3] gpiolib: debugfs: update to show more info for gpios requested as irq

2015-05-20 Thread Alexandre Courbot
On Wed, May 20, 2015 at 7:30 PM, Grygorii Strashko
 wrote:
> This series updates gpiolib debugfs code to show more information about
> GPIOs requested as IRQ.
>
> First patch ensures that information about GPIOs requested as IRQ only
> will be provided through GPIO debugfs.
>
> Other two patches extend information for GPIOs requested as IRQ
> - show Linux irq number
> - show marker '' for GPIOs requested as IRQ only
>
> After this series sys/kernel/debug/gpio will produce following output:
>   ...
>  GPIOs 160-191, platform/4805d000.gpio, gpio:
>   gpio-171 ((null)  ) in  hi IRQ-209 
>  ^^^ GPIO requested as IRQ only and its Linux IRQ number is 209
>   gpio-172 (xxyy  ) in  hi IRQ-210
>  ^^^ GPIO requested as IRQ and as GPIO and its Linux IRQ number is 209
>
>  GPIOs 192-223, platform/48051000.gpio, gpio:
>   gpio-203 (vtt_fixed   ) out hi
>  ^^^ GPIO requested as GPIO only
>
> Changes in v2:
> - split original patch on three patcehs
> - apply comments from Linus and Johan

This looks like useful information indeed.

The series,

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


[PATCH 2/2] drivers: ata: add support for Ceva sata host controller

2015-05-20 Thread Suneel Garapati
Adds support for Ceva sata host controller on Xilinx
Zynq UltraScale+ MPSoC.

Signed-off-by: Suneel Garapati 
---
 drivers/ata/Kconfig |   9 ++
 drivers/ata/Makefile|   1 +
 drivers/ata/ahci_ceva.c | 225 
 3 files changed, 235 insertions(+)
 create mode 100644 drivers/ata/ahci_ceva.c

diff --git a/drivers/ata/Kconfig b/drivers/ata/Kconfig
index 9dca4b9..ef3cfde 100644
--- a/drivers/ata/Kconfig
+++ b/drivers/ata/Kconfig
@@ -124,6 +124,15 @@ config AHCI_IMX

  If unsure, say N.

+config AHCI_CEVA
+   tristate "CEVA AHCI SATA support"
+   depends on OF
+   help
+ This option enables support for the CEVA AHCI SATA.
+ It can be found on the Xilinx Zynq UltraScale+ MPSoC.
+
+ If unsure, say N.
+
 config AHCI_MVEBU
tristate "Marvell EBU AHCI SATA support"
depends on ARCH_MVEBU
diff --git a/drivers/ata/Makefile b/drivers/ata/Makefile
index 40f7865..dc3a320 100644
--- a/drivers/ata/Makefile
+++ b/drivers/ata/Makefile
@@ -10,6 +10,7 @@ obj-$(CONFIG_SATA_INIC162X)   += sata_inic162x.o
 obj-$(CONFIG_SATA_SIL24)   += sata_sil24.o
 obj-$(CONFIG_SATA_DWC) += sata_dwc_460ex.o
 obj-$(CONFIG_SATA_HIGHBANK)+= sata_highbank.o libahci.o
+obj-$(CONFIG_AHCI_CEVA)+= ahci_ceva.o libahci.o 
libahci_platform.o
 obj-$(CONFIG_AHCI_DA850)   += ahci_da850.o libahci.o libahci_platform.o
 obj-$(CONFIG_AHCI_IMX) += ahci_imx.o libahci.o libahci_platform.o
 obj-$(CONFIG_AHCI_MVEBU)   += ahci_mvebu.o libahci.o libahci_platform.o
diff --git a/drivers/ata/ahci_ceva.c b/drivers/ata/ahci_ceva.c
new file mode 100644
index 000..dfcd2f4
--- /dev/null
+++ b/drivers/ata/ahci_ceva.c
@@ -0,0 +1,225 @@
+/*
+ * Copyright (C) 2015 Xilinx, Inc.
+ * CEVA AHCI SATA platform driver
+ *
+ * based on the AHCI SATA platform driver by Jeff Garzik and Anton Vorontsov
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms and conditions of the GNU General Public License,
+ * version 2, as published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope it will be useful, but WITHOUT
+ * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
+ * FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License for
+ * more details.
+ *
+ * You should have received a copy of the GNU General Public License along with
+ * this program. If not, see .
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include "ahci.h"
+
+/* Vendor Specific Register Offsets */
+#define AHCI_VEND_PCFG  0xA4
+#define AHCI_VEND_PPCFG 0xA8
+#define AHCI_VEND_PP2C  0xAC
+#define AHCI_VEND_PP3C  0xB0
+#define AHCI_VEND_PP4C  0xB4
+#define AHCI_VEND_PP5C  0xB8
+#define AHCI_VEND_PAXIC 0xC0
+#define AHCI_VEND_PTC   0xC8
+
+/* Vendor Specific Register bit definitions */
+#define PAXIC_ADBW_BW64 0x1
+#define PAXIC_MAWIDD   (1 << 8)
+#define PAXIC_MARIDD   (1 << 16)
+#define PAXIC_OTL  (0x4 << 20)
+
+#define PCFG_TPSS_VAL  (0x32 << 16)
+#define PCFG_TPRS_VAL  (0x2 << 12)
+#define PCFG_PAD_VAL   0x2
+
+#define PPCFG_TTA  0x1FFFE
+#define PPCFG_PSSO_EN  (1 << 28)
+#define PPCFG_PSS_EN   (1 << 29)
+#define PPCFG_ESDF_EN  (1 << 31)
+
+#define PP2C_CIBGMN0x0F
+#define PP2C_CIBGMX(0x25 << 8)
+#define PP2C_CIBGN (0x18 << 16)
+#define PP2C_CINMP (0x29 << 24)
+
+#define PP3C_CWBGMN0x04
+#define PP3C_CWBGMX(0x0B << 8)
+#define PP3C_CWBGN (0x08 << 16)
+#define PP3C_CWNMP (0x0F << 24)
+
+#define PP4C_BMX   0x0a
+#define PP4C_BNM   (0x08 << 8)
+#define PP4C_SFD   (0x4a << 16)
+#define PP4C_PTST  (0x06 << 24)
+
+#define PP5C_RIT   0x60216
+#define PP5C_RCT   (0x7f0 << 20)
+
+#define PTC_RX_WM_VAL  0x40
+#define PTC_RSVD   (1 << 27)
+
+#define PORT0_BASE 0x100
+#define PORT1_BASE 0x180
+
+/* Port Control Register Bit Definitions */
+#define PORT_SCTL_SPD_GEN2 (0x2 << 4)
+#define PORT_SCTL_SPD_GEN1 (0x1 << 4)
+#define PORT_SCTL_IPM  (0x3 << 8)
+
+#define PORT_BASE  0x100
+#define PORT_OFFSET0x80
+#define NR_PORTS   2
+#define DRV_NAME   "ahci-ceva"
+#define CEVA_FLAG_BROKEN_GEN2  1
+
+struct ceva_ahci_priv {
+   struct platform_device *ahci_pdev;
+   int flags;
+};
+
+static struct ata_port_operations ahci_ceva_ops = {
+   .inherits = &ahci_platform_ops,
+};
+
+static const struct ata_port_info ahci_ceva_port_info = {
+   .flags  = AHCI_FLAG_COMMON,
+   .pio_mask   = ATA_PIO4,
+   .udma_mask  = ATA_UDMA6,
+   .port_ops   = &ahci_ceva_ops,
+};
+
+static void ahci_ceva_setup(struct ahci_host_priv *hpriv)
+{
+   void __iomem *mmio = hpriv->mmio;
+   struct ceva_ahci_priv *cevapriv = hpriv->plat_data;
+   u32 tmp;
+   int i;
+
+   /*
+* AXI Data bus width to 64
+* Set Mem Addr Read, Write ID for data transfers
+* Trans

[PATCH v4 2/2] perf/kvm: Support HCALL events

2015-05-20 Thread Hemant Kumar
powerpc provides hcall events that also provides insights into guest
behaviour. Enhance perf kvm to record and analyze hcall events.

 - To trace hcall events :
  perf kvm stat record

 - To show the results :
  perf kvm stat report --event=hcall

The result shows the number of hypervisor calls from the guest grouped
by their respective reasons displayed with the frequency.

This patch makes use of two additional tracepoints
"kvm_hv:kvm_hcall_enter" and "kvm_hv:kvm_hcall_exit". It uses the
pSeries hypervisor codes exported through uapi to classify the hcalls
into their respective reasons.

Note : This patch has a dependency on "kvm/powerpc: Export HCALL reason
codes" which exports HCALL reasons through uapi.

 # pgrep qemu
A sample output :
19378
60515

2 VMs running.

 # perf kvm stat record -a
^C[ perf record: Woken up 1 times to write data ]
[ perf record: Captured and wrote 4.153 MB perf.data.guest (39624 samples) ]

 # perf kvm stat report -p 60515 --event=hcall
Analyze events for pid(s) 60515, all VCPUs:

 HCALL-EVENTSamples  Samples% Time%Min TimeMax Time 
Avg time

H_VIO_SIGNAL   103438.44%15.77%  0.36us  1.59us 
 0.44us ( +-   0.66% )
  H_SEND_CRQ65224.24%10.97%  0.39us  1.84us 
 0.49us ( +-   1.20% )
   H_IPI52319.44%62.05%  1.35us 19.70us 
 3.44us ( +-   2.88% )
 H_PUT_TERM_CHAR41115.28% 8.03%  0.38us  3.77us 
 0.57us ( +-   1.61% )
 H_GET_TERM_CHAR 50 1.86% 0.99%  0.40us  0.98us 
 0.57us ( +-   3.37% )
   H_EOI 20 0.74% 2.19%  2.22us  4.72us 
 3.17us ( +-   5.96% )

Total Samples:2690, Total events handled time:2896.94us.

Signed-off-by: Hemant Kumar 
---
Changes:
- Moved the uapi related changes to arch/powerpc side patchset.

This patch has a dependency on :
http://www.mail-archive.com/linuxppc-dev@lists.ozlabs.org/msg89487.html
which export hcall reasons through uapi.

 tools/perf/arch/powerpc/util/kvm-stat.c | 61 +
 1 file changed, 61 insertions(+)

diff --git a/tools/perf/arch/powerpc/util/kvm-stat.c 
b/tools/perf/arch/powerpc/util/kvm-stat.c
index 24e06bf..0d3ea47 100644
--- a/tools/perf/arch/powerpc/util/kvm-stat.c
+++ b/tools/perf/arch/powerpc/util/kvm-stat.c
@@ -1,7 +1,9 @@
 #include "../../util/kvm-stat.h"
 #include 
+#include "../../util/debug.h"
 
 define_exit_reasons_table(hv_exit_reasons, kvm_trace_symbol_exit);
+define_exit_reasons_table(hcall_reasons, kvm_trace_symbol_hcall);
 
 static struct kvm_events_ops exit_events = {
.is_begin_event = exit_event_begin,
@@ -10,14 +12,73 @@ static struct kvm_events_ops exit_events = {
.name = "VM-EXIT"
 };
 
+static void hcall_event_get_key(struct perf_evsel *evsel,
+   struct perf_sample *sample,
+   struct event_key *key)
+{
+   key->info = 0;
+   key->key = perf_evsel__intval(evsel, sample, KVM_HCALL_REASON);
+}
+
+static const char *get_exit_reason(u64 exit_code)
+{
+   struct exit_reasons_table *tbl = hcall_reasons;
+
+   while (tbl->reason != NULL) {
+   if (tbl->exit_code == exit_code)
+   return tbl->reason;
+   tbl++;
+   }
+
+   pr_err("Unknown kvm hcall exit code: %lld\n",
+  (unsigned long long)exit_code);
+   return "UNKNOWN";
+}
+
+static bool hcall_event_end(struct perf_evsel *evsel,
+   struct perf_sample *sample __maybe_unused,
+   struct event_key *key __maybe_unused)
+{
+   return (!strcmp(evsel->name, KVM_HCALL_EXIT_TRACE));
+}
+
+static bool hcall_event_begin(struct perf_evsel *evsel,
+ struct perf_sample *sample, struct event_key *key)
+{
+   if (!strcmp(evsel->name, KVM_HCALL_ENTRY_TRACE)) {
+   hcall_event_get_key(evsel, sample, key);
+   return true;
+   }
+
+return false;
+}
+static void hcall_event_decode_key(struct perf_kvm_stat *kvm __maybe_unused,
+  struct event_key *key,
+  char *decode)
+{
+   const char *hcall_reason = get_exit_reason(key->key);
+
+   scnprintf(decode, DECODE_STR_LEN, "%s", hcall_reason);
+}
+
+static struct kvm_events_ops hcall_events = {
+   .is_begin_event = hcall_event_begin,
+   .is_end_event = hcall_event_end,
+   .decode_key = hcall_event_decode_key,
+   .name = "HCALL-EVENT",
+};
+
 const char *const kvm_events_tp[] = {
"kvm_hv:kvm_guest_exit",
"kvm_hv:kvm_guest_enter",
+   "kvm_hv:kvm_hcall_enter",
+   "kvm_hv:kvm_hcall_exit",
NULL,
 };
 
 struct kvm_reg_events_ops kvm_reg_events_ops[] = {
{ .name = "vmexit", .ops = &exit_events },
+   { .name = "hcall", .ops = &hcall_events },
{ NULL, NULL },
 };
 
-- 

[PATCH v4 1/2] perf/kvm: Port perf kvm to powerpc

2015-05-20 Thread Hemant Kumar
From: Srikar Dronamraju 

perf kvm can be used to analyze guest exit reasons. This support already
exists in x86. Hence, porting it to powerpc.

 - To trace KVM events :
  perf kvm stat record
  If many guests are running, we can track for a specific guest by using
  --pid as in : perf kvm stat record --pid 

 - To see the results :
  perf kvm stat report

The result shows the number of exits (from the guest context to
host/hypervisor context) grouped by their respective exit reasons with
their frequency.

This patch makes use of the guest exit reasons available in
"trace_book3s.h". It records on two already available tracepoints :
"kvm_hv:kvm_guest_exit" and "kvm_hv:kvm_guest_enter".

Note : This patch has a dependency on the patch "kvm/powerpc: Export
kvm exit reasons" which exports the KVM exit reasons through the uapi.

Here is a sample o/p:
 # pgrep qemu
19378
60515

2 Guests are running on the host.

 # perf kvm stat record -a
^C[ perf record: Woken up 1 times to write data ]
[ perf record: Captured and wrote 4.153 MB perf.data.guest (39624 samples) ]

 # perf kvm stat report -p 60515
Analyze events for pid(s) 60515, all VCPUs:

   VM-EXITSamples  Samples% Time%Min Time Max
Time Avg time

H_DATA_STORAGE   500635.30% 0.13%  1.94us 49.46us 
12.37us ( +-   0.52% )
HV_DECREMENTER   445731.43% 0.02%  0.72us 16.14us  
1.91us ( +-   0.96% )
   SYSCALL   269018.97% 0.10%  2.84us528.24us 
18.29us ( +-   3.75% )
RETURN_TO_HOST   178912.61%99.76%  1.58us 672791.91us  
27470.23us ( +-   3.00% )
  EXTERNAL240 1.69% 0.00%  0.69us 10.67us  
1.33us ( +-   5.34% )

Total Samples:14182, Total events handled time:49264158.30us.

Signed-off-by: Srikar Dronamraju 
Signed-off-by: Hemant Kumar 
---
Changes :
- Moved the uapi related changes to arch/powerpc patchset.

This patch has a dependency on :
http://www.mail-archive.com/linuxppc-dev@lists.ozlabs.org/msg89485.html
which exports the kvm exit reasons.

 tools/perf/arch/powerpc/Makefile|  1 +
 tools/perf/arch/powerpc/util/Build  |  1 +
 tools/perf/arch/powerpc/util/kvm-stat.c | 33 +
 3 files changed, 35 insertions(+)
 create mode 100644 tools/perf/arch/powerpc/util/kvm-stat.c

diff --git a/tools/perf/arch/powerpc/Makefile b/tools/perf/arch/powerpc/Makefile
index 7fbca17..21322e0 100644
--- a/tools/perf/arch/powerpc/Makefile
+++ b/tools/perf/arch/powerpc/Makefile
@@ -1,3 +1,4 @@
 ifndef NO_DWARF
 PERF_HAVE_DWARF_REGS := 1
 endif
+HAVE_KVM_STAT_SUPPORT := 1
diff --git a/tools/perf/arch/powerpc/util/Build 
b/tools/perf/arch/powerpc/util/Build
index 7b8b0d1..c8fe207 100644
--- a/tools/perf/arch/powerpc/util/Build
+++ b/tools/perf/arch/powerpc/util/Build
@@ -1,5 +1,6 @@
 libperf-y += header.o
 libperf-y += sym-handling.o
+libperf-y += kvm-stat.o
 
 libperf-$(CONFIG_DWARF) += dwarf-regs.o
 libperf-$(CONFIG_DWARF) += skip-callchain-idx.o
diff --git a/tools/perf/arch/powerpc/util/kvm-stat.c 
b/tools/perf/arch/powerpc/util/kvm-stat.c
new file mode 100644
index 000..24e06bf
--- /dev/null
+++ b/tools/perf/arch/powerpc/util/kvm-stat.c
@@ -0,0 +1,33 @@
+#include "../../util/kvm-stat.h"
+#include 
+
+define_exit_reasons_table(hv_exit_reasons, kvm_trace_symbol_exit);
+
+static struct kvm_events_ops exit_events = {
+   .is_begin_event = exit_event_begin,
+   .is_end_event = exit_event_end,
+   .decode_key = exit_event_decode_key,
+   .name = "VM-EXIT"
+};
+
+const char *const kvm_events_tp[] = {
+   "kvm_hv:kvm_guest_exit",
+   "kvm_hv:kvm_guest_enter",
+   NULL,
+};
+
+struct kvm_reg_events_ops kvm_reg_events_ops[] = {
+   { .name = "vmexit", .ops = &exit_events },
+   { NULL, NULL },
+};
+
+const char * const kvm_skip_events[] = {
+   NULL,
+};
+
+int cpu_isa_init(struct perf_kvm_stat *kvm, const char *cpuid __maybe_unused)
+{
+   kvm->exit_reasons = hv_exit_reasons;
+   kvm->exit_reasons_isa = "HV";
+   return 0;
+}
-- 
1.9.3

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


Re: [PATCH V4 00/13] POWER DSCR fixes, improvements, docs and tests

2015-05-20 Thread Michael Ellerman
On Mon, 2015-05-18 at 16:26 +0530, Anshuman Khandual wrote:
>   This patch series has patches for POWER DSCR fixes, improvements,
> in code documentaion, kernel support user documentation and selftest based
> test cases. It has got five test cases which are derived from Anton's DSCR
> test bucket which can be listed as follows.
> 
> (1) http://ozlabs.org/~anton/junkcode/dscr_default_test.c
> (2) http://ozlabs.org/~anton/junkcode/dscr_explicit_test.c
> (3) http://ozlabs.org/~anton/junkcode/dscr_inherit_exec_test.c
> (4) http://ozlabs.org/~anton/junkcode/dscr_inherit_test.c
> (5) http://ozlabs.org/~anton/junkcode/user_dscr_test.c
> 
> NOTE1: Anton's original inherit exec test expected the child to have system
> default DSCR value instead of the inherited DSCR value from it's parent.
> But looks like thats not the case when we execute the test, it always
> inherits it's parent's DSCR value over the exec call as well. So I have
> changed the test program assuming its correct to have the inherited DSCR
> value in the fork/execed child program. Please let me know if thats not
> correct and I am missing something there.

The selftests still fail to build:

  cc -Wall -O2 -flto -Wall -Werror -DGIT_VERSION='"v4.0-rc1-13631-gdfcba4b"' 
-I/home/buildbot/buildbot/slave/selftests-ppc64-gcc-ubuntu-be/build/tools/testing/selftests/powerpc
  -lpthreaddscr_default_test.c ../harness.c   -o dscr_default_test
  In file included from dscr_default_test.c:16:0:
  dscr.h: In function ‘get_default_dscr’:
  dscr.h:93:6: error: ignoring return value of ‘read’, declared with attribute 
warn_unused_result [-Werror=unused-result]
read(fd, buf, sizeof(buf));
^
  dscr.h: In function ‘set_default_dscr’:
  dscr.h:112:7: error: ignoring return value of ‘write’, declared with 
attribute warn_unused_result [-Werror=unused-result]
write(fd, buf, strlen(buf));
 ^
  cc1: all warnings being treated as errors
  make[1]: *** [dscr_default_test] Error 1


I'm happy for you to call perror() and exit(1) if either fail.

Please fix and resend.

cheers


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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: [FYI] tux3: Core changes

2015-05-20 Thread David Lang

On Wed, 20 May 2015, Daniel Phillips wrote:


On 05/20/2015 03:51 PM, Daniel Phillips wrote:

On 05/20/2015 12:53 PM, Rik van Riel wrote:

How does tux3 prevent a user of find_get_page() from reading from
or writing into the pre-COW page, instead of the current page?


Careful control of the dirty bits (we have two of them, one each
for front and back). That is what pagefork_for_blockdirty is about.


Ah, and of course it does not matter if a reader is on the
pre-cow page. It would be reading the earlier copy, which might
no longer be the current copy, but it raced with the write so
nobody should be surprised. That is a race even without page fork.


how do you prevent it from continuing to interact with the old version of the 
page and never see updates or have it's changes reflected on the current page?


David Lang
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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 net-next] bridge: allow setting hash_max + multicast_router if interface is down

2015-05-20 Thread Herbert Xu
On Thu, May 21, 2015 at 04:59:22AM +0200, Linus Lüssing wrote:
> 
> * For i=br_multicast_init(), e=br_multicast_enable() and
>   s=br_multicast_stop() is the order i->e->s->e->s->e->... always
>   ensured by the netdev API? Will this work even if I have

br_multicast_init always happens first obviously.  But there is
no ordering requirement between e and s.

>   many fast and wild calls to "ip link set up dev br0" and
>   "ip link set down dev br0" and some changes to hash_max and
>   multicast_router in between?

The timer operations are all supposed to be idempotent.  So enabling
a port twice or stopping it twice should be OK.

> * Might calls to br_multicast_add_router() via br_multicast_enable_port()
>   cause unintended side-effects?

What do you mean? How does add_router get called from enable_port?

> * (maybe independent of this patch: )
>   Can fast changes to the multicast_router attribute of a bridge (port)
>   cause race conditions because a del_timer() instead of a
>   del_timer_sync() is used in br_multicast_set_{port,}router()?
>   (or: why does br_multicast_stop() use del_timer_sync() while
>br_multicast_disable_port() doesn't?)

I don't think so.  Firstly everything should happen under the
multicast lock except for stop/del_port.  The latter rely on
those adding timers to check netif_running and port != disabled
to avoid races.

Apart from that you can always mod_timer twice or del_timer
twice so that's not really an issue.

> * @Herbert: Do you remember whether there was a reason for
>   checking netif_running() or the bridge port state which
>   I might have overlooked?

See above.  It's there so that you don't readd a timer when we're
calling del_timer_sync.  del_timer_sync has to be called without
the multicast lock so that's why we need another mechanism to
prevent the timers from being readded.

AFAICS the spots you patched aren't adding timers so they *should*
be OK.

Cheers,
-- 
Email: Herbert Xu 
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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 6/6] usb: chipidea: add work-around for Marvell HSIC PHY startup

2015-05-20 Thread Rob Herring
On Wed, May 20, 2015 at 10:13 PM, Peter Chen  wrote:
> On Tue, May 19, 2015 at 09:10:05PM -0500, Rob Herring wrote:
>> The Marvell 28nm HSIC PHY requires the port to be forced to HS mode after
>> the port power is applied. This is done using the test mode in the PORTSC
>> register.
>>
>> As HSIC is always HS, this work-around should be safe to do with all HSIC
>> PHYs. If not, a flag can also be added.
>
> I think a flag is needed, not sure all vendors can work well with that.

Only i.MX6Sx uses HSIC in mainline. Is that something you can test? It
would be better to not add flags unless they are really needed.
Otherwise you end up with dozens of flags like SDHCI drivers have.

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


[PATCH v6 5/5] trace, ras: move ras_event.h under include/trace/events

2015-05-20 Thread Xie XiuQi
From: Naoya Horiguchi 

Most of header files for tracepoints are located to include/trace/events or
their relevant subdirectories under drivers/. One exception is
include/ras/ras_events.h, which looks inconsistent. So let's move it to the
default places for such headers.

Signed-off-by: Naoya Horiguchi 
Cc: Randy Dunlap 
Cc: Stephen Rothwell 
Cc: Andrew Morton 
Cc: Jim Davis 
Cc: Chen, Gong 
Signed-off-by: Xie XiuQi 
---
 drivers/acpi/acpi_extlog.c |2 +-
 drivers/edac/edac_mc.c |2 +-
 drivers/edac/ghes_edac.c   |2 +-
 drivers/pci/pcie/aer/aerdrv_errprint.c |2 +-
 drivers/ras/ras.c  |3 +-
 include/ras/ras_event.h|  323 
 include/trace/events/ras.h |  322 +++
 mm/memory-failure.c|2 +-
 8 files changed, 328 insertions(+), 330 deletions(-)
 delete mode 100644 include/ras/ras_event.h
 create mode 100644 include/trace/events/ras.h

diff --git a/drivers/acpi/acpi_extlog.c b/drivers/acpi/acpi_extlog.c
index b3842ff..b04bfd9 100644
--- a/drivers/acpi/acpi_extlog.c
+++ b/drivers/acpi/acpi_extlog.c
@@ -17,7 +17,7 @@
 #include 
 
 #include "apei/apei-internal.h"
-#include 
+#include 
 
 #define EXT_ELOG_ENTRY_MASKGENMASK_ULL(51, 0) /* elog entry address mask */
 
diff --git a/drivers/edac/edac_mc.c b/drivers/edac/edac_mc.c
index af3be19..c95ecb7 100644
--- a/drivers/edac/edac_mc.c
+++ b/drivers/edac/edac_mc.c
@@ -33,7 +33,7 @@
 #include 
 #include "edac_core.h"
 #include "edac_module.h"
-#include 
+#include 
 
 /* lock to memory controller's control array */
 static DEFINE_MUTEX(mem_ctls_mutex);
diff --git a/drivers/edac/ghes_edac.c b/drivers/edac/ghes_edac.c
index b246819..2230057 100644
--- a/drivers/edac/ghes_edac.c
+++ b/drivers/edac/ghes_edac.c
@@ -15,7 +15,7 @@
 #include 
 #include 
 #include "edac_core.h"
-#include 
+#include 
 
 #define GHES_EDAC_REVISION " Ver: 1.0.0"
 
diff --git a/drivers/pci/pcie/aer/aerdrv_errprint.c 
b/drivers/pci/pcie/aer/aerdrv_errprint.c
index 167fe41..b5d4c0d 100644
--- a/drivers/pci/pcie/aer/aerdrv_errprint.c
+++ b/drivers/pci/pcie/aer/aerdrv_errprint.c
@@ -22,7 +22,7 @@
 #include 
 
 #include "aerdrv.h"
-#include 
+#include 
 
 #define AER_AGENT_RECEIVER 0
 #define AER_AGENT_REQUESTER1
diff --git a/drivers/ras/ras.c b/drivers/ras/ras.c
index b67dd36..d155768 100644
--- a/drivers/ras/ras.c
+++ b/drivers/ras/ras.c
@@ -9,8 +9,7 @@
 #include 
 
 #define CREATE_TRACE_POINTS
-#define TRACE_INCLUDE_PATH ../../include/ras
-#include 
+#include 
 
 static int __init ras_init(void)
 {
diff --git a/include/ras/ras_event.h b/include/ras/ras_event.h
deleted file mode 100644
index 1443d79..000
--- a/include/ras/ras_event.h
+++ /dev/null
@@ -1,323 +0,0 @@
-#undef TRACE_SYSTEM
-#define TRACE_SYSTEM ras
-#define TRACE_INCLUDE_FILE ras_event
-
-#if !defined(_TRACE_HW_EVENT_MC_H) || defined(TRACE_HEADER_MULTI_READ)
-#define _TRACE_HW_EVENT_MC_H
-
-#include 
-#include 
-#include 
-#include 
-#include 
-#include 
-#include 
-
-/*
- * MCE Extended Error Log trace event
- *
- * These events are generated when hardware detects a corrected or
- * uncorrected event.
- */
-
-/* memory trace event */
-
-#if defined(CONFIG_ACPI_EXTLOG) || defined(CONFIG_ACPI_EXTLOG_MODULE)
-TRACE_EVENT(extlog_mem_event,
-   TP_PROTO(struct cper_sec_mem_err *mem,
-u32 err_seq,
-const uuid_le *fru_id,
-const char *fru_text,
-u8 sev),
-
-   TP_ARGS(mem, err_seq, fru_id, fru_text, sev),
-
-   TP_STRUCT__entry(
-   __field(u32, err_seq)
-   __field(u8, etype)
-   __field(u8, sev)
-   __field(u64, pa)
-   __field(u8, pa_mask_lsb)
-   __field_struct(uuid_le, fru_id)
-   __string(fru_text, fru_text)
-   __field_struct(struct cper_mem_err_compact, data)
-   ),
-
-   TP_fast_assign(
-   __entry->err_seq = err_seq;
-   if (mem->validation_bits & CPER_MEM_VALID_ERROR_TYPE)
-   __entry->etype = mem->error_type;
-   else
-   __entry->etype = ~0;
-   __entry->sev = sev;
-   if (mem->validation_bits & CPER_MEM_VALID_PA)
-   __entry->pa = mem->physical_addr;
-   else
-   __entry->pa = ~0ull;
-
-   if (mem->validation_bits & CPER_MEM_VALID_PA_MASK)
-   __entry->pa_mask_lsb = 
(u8)__ffs64(mem->physical_addr_mask);
-   else
-   __entry->pa_mask_lsb = ~0;
-   __entry->fru_id = *fru_id;
-   __assign_str(fru_text, fru_text);
-   cper_mem_err_pack(mem, &__entry->data);
-   ),
-
-   TP_printk("{%d} %s error: %s physical addr: %016llx (mask lsb: %x) 
%sFRU: %pUl %.20s",
- __entry->err_s

[PATCH v6 1/5] memory-failure: export page_type and action result

2015-05-20 Thread Xie XiuQi
Export 'outcome' and 'action_page_type' to mm.h, so we could use
this emnus outside.

This patch is preparation for adding trace events for memory-failure
recovery action.

Acked-by: Naoya Horiguchi 
Signed-off-by: Xie XiuQi 
---
 include/linux/mm.h  |   34 ++
 mm/memory-failure.c |  168 --
 2 files changed, 101 insertions(+), 101 deletions(-)

diff --git a/include/linux/mm.h b/include/linux/mm.h
index 0755b9f..3abf13c 100644
--- a/include/linux/mm.h
+++ b/include/linux/mm.h
@@ -2152,6 +2152,40 @@ extern void shake_page(struct page *p, int access);
 extern atomic_long_t num_poisoned_pages;
 extern int soft_offline_page(struct page *page, int flags);
 
+
+/*
+ * Error handlers for various types of pages.
+ */
+enum mf_outcome {
+   MF_IGNORED, /* Error: cannot be handled */
+   MF_FAILED,  /* Error: handling failed */
+   MF_DELAYED, /* Will be handled later */
+   MF_RECOVERED,   /* Successfully recovered */
+};
+
+enum mf_action_page_type {
+   MF_MSG_KERNEL,
+   MF_MSG_KERNEL_HIGH_ORDER,
+   MF_MSG_SLAB,
+   MF_MSG_DIFFERENT_COMPOUND,
+   MF_MSG_POISONED_HUGE,
+   MF_MSG_HUGE,
+   MF_MSG_FREE_HUGE,
+   MF_MSG_UNMAP_FAILED,
+   MF_MSG_DIRTY_SWAPCACHE,
+   MF_MSG_CLEAN_SWAPCACHE,
+   MF_MSG_DIRTY_MLOCKED_LRU,
+   MF_MSG_CLEAN_MLOCKED_LRU,
+   MF_MSG_DIRTY_UNEVICTABLE_LRU,
+   MF_MSG_CLEAN_UNEVICTABLE_LRU,
+   MF_MSG_DIRTY_LRU,
+   MF_MSG_CLEAN_LRU,
+   MF_MSG_TRUNCATED_LRU,
+   MF_MSG_BUDDY,
+   MF_MSG_BUDDY_2ND,
+   MF_MSG_UNKNOWN,
+};
+
 #if defined(CONFIG_TRANSPARENT_HUGEPAGE) || defined(CONFIG_HUGETLBFS)
 extern void clear_huge_page(struct page *page,
unsigned long addr,
diff --git a/mm/memory-failure.c b/mm/memory-failure.c
index 501820c..5650dec 100644
--- a/mm/memory-failure.c
+++ b/mm/memory-failure.c
@@ -503,68 +503,34 @@ static void collect_procs(struct page *page, struct 
list_head *tokill,
kfree(tk);
 }
 
-/*
- * Error handlers for various types of pages.
- */
-
-enum outcome {
-   IGNORED,/* Error: cannot be handled */
-   FAILED, /* Error: handling failed */
-   DELAYED,/* Will be handled later */
-   RECOVERED,  /* Successfully recovered */
-};
-
 static const char *action_name[] = {
-   [IGNORED] = "Ignored",
-   [FAILED] = "Failed",
-   [DELAYED] = "Delayed",
-   [RECOVERED] = "Recovered",
-};
-
-enum action_page_type {
-   MSG_KERNEL,
-   MSG_KERNEL_HIGH_ORDER,
-   MSG_SLAB,
-   MSG_DIFFERENT_COMPOUND,
-   MSG_POISONED_HUGE,
-   MSG_HUGE,
-   MSG_FREE_HUGE,
-   MSG_UNMAP_FAILED,
-   MSG_DIRTY_SWAPCACHE,
-   MSG_CLEAN_SWAPCACHE,
-   MSG_DIRTY_MLOCKED_LRU,
-   MSG_CLEAN_MLOCKED_LRU,
-   MSG_DIRTY_UNEVICTABLE_LRU,
-   MSG_CLEAN_UNEVICTABLE_LRU,
-   MSG_DIRTY_LRU,
-   MSG_CLEAN_LRU,
-   MSG_TRUNCATED_LRU,
-   MSG_BUDDY,
-   MSG_BUDDY_2ND,
-   MSG_UNKNOWN,
+   [MF_IGNORED] = "Ignored",
+   [MF_FAILED] = "Failed",
+   [MF_DELAYED] = "Delayed",
+   [MF_RECOVERED] = "Recovered",
 };
 
 static const char * const action_page_types[] = {
-   [MSG_KERNEL]= "reserved kernel page",
-   [MSG_KERNEL_HIGH_ORDER] = "high-order kernel page",
-   [MSG_SLAB]  = "kernel slab page",
-   [MSG_DIFFERENT_COMPOUND]= "different compound page after 
locking",
-   [MSG_POISONED_HUGE] = "huge page already hardware poisoned",
-   [MSG_HUGE]  = "huge page",
-   [MSG_FREE_HUGE] = "free huge page",
-   [MSG_UNMAP_FAILED]  = "unmapping failed page",
-   [MSG_DIRTY_SWAPCACHE]   = "dirty swapcache page",
-   [MSG_CLEAN_SWAPCACHE]   = "clean swapcache page",
-   [MSG_DIRTY_MLOCKED_LRU] = "dirty mlocked LRU page",
-   [MSG_CLEAN_MLOCKED_LRU] = "clean mlocked LRU page",
-   [MSG_DIRTY_UNEVICTABLE_LRU] = "dirty unevictable LRU page",
-   [MSG_CLEAN_UNEVICTABLE_LRU] = "clean unevictable LRU page",
-   [MSG_DIRTY_LRU] = "dirty LRU page",
-   [MSG_CLEAN_LRU] = "clean LRU page",
-   [MSG_TRUNCATED_LRU] = "already truncated LRU page",
-   [MSG_BUDDY] = "free buddy page",
-   [MSG_BUDDY_2ND] = "free buddy page (2nd try)",
-   [MSG_UNKNOWN]   = "unknown page",
+   [MF_MSG_KERNEL] = "reserved kernel page",
+   [MF_MSG_KERNEL_HIGH_ORDER]  = "high-order kernel page",
+   [MF_MSG_SLAB]   = "kernel slab page",
+   [MF_MSG_DIFFERENT_COMPOUND] = "different compound page after 
locking",
+   [MF_MSG_POISONED_HUGE]  = "huge page already hardware poisoned",
+   [MF_MSG_HUGE]   = "huge 

[PATCH v6 4/5] tracing: fix build error in mm/memory-failure.c

2015-05-20 Thread Xie XiuQi
next-20150515 fails to build on i386 with the following error:

mm/built-in.o: In function `action_result':
memory-failure.c:(.text+0x344a5): undefined reference to 
`__tracepoint_memory_failure_event'
memory-failure.c:(.text+0x344d5): undefined reference to 
`__tracepoint_memory_failure_event'
memory-failure.c:(.text+0x3450c): undefined reference to 
`__tracepoint_memory_failure_event'

trace_memory_failure_event depends on CONFIG_RAS,
so add 'select RAS' in mm/Kconfig to avoid this error.

Reported-by: Randy Dunlap 
Reported-by: Jim Davis 
Cc: Steven Rostedt 
Cc: Chen Gong 
Acked-by: Naoya Horiguchi 
Signed-off-by: Xie XiuQi 
---
 mm/Kconfig |1 +
 1 files changed, 1 insertions(+), 0 deletions(-)

diff --git a/mm/Kconfig b/mm/Kconfig
index 390214d..c180af8 100644
--- a/mm/Kconfig
+++ b/mm/Kconfig
@@ -368,6 +368,7 @@ config MEMORY_FAILURE
depends on ARCH_SUPPORTS_MEMORY_FAILURE
bool "Enable recovery from hardware memory errors"
select MEMORY_ISOLATION
+   select RAS
help
  Enables code to recover from some memory failures on systems
  with MCA recovery. This allows a system to continue running
-- 
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 v6 0/5] tracing: add trace event for memory-failure

2015-05-20 Thread Xie XiuQi
RAS user space tools like rasdaemon which base on trace event, could
receive mce error event, but no memory recovery result event. So, I
want to add this event to make this scenario complete.

This patchset add a event at ras group for memory-failure.

The output like below:
#  tracer: nop
#
#  entries-in-buffer/entries-written: 2/2   #P:24
#
#   _-=> irqs-off
#  / _=> need-resched
# | / _---=> hardirq/softirq
# || / _--=> preempt-depth
# ||| / delay
#TASK-PID   CPU#  TIMESTAMP  FUNCTION
#   | |   |      | |
   mce-inject-13150 [001]    277.019359: memory_failure_event: pfn 
0x19869: recovery action for free buddy page: Delayed

--
v5->v6:
 - fix a build error
 - move ras_event.h under include/trace/events
 - rebase on top of latest mainline

v4->v5:
 - fix a typo
 - rebase on top of latest mainline

v3->v4:
 - rebase on top of latest linux-next
 - update comments as Naoya's suggestion
 - add #ifdef CONFIG_MEMORY_FAILURE for this trace event
 - change type of action_result's param 3 to enum

v2->v3:
 - rebase on top of linux-next
 - based on Steven Rostedt's "tracing: Add TRACE_DEFINE_ENUM() macro
   to map enums to their values" patch set v1.

v1->v2:
 - Comment update
 - Just passing 'result' instead of 'action_name[result]',
   suggested by Steve. And hard coded there because trace-cmd
   and perf do not have a way to process enums.

Naoya Horiguchi (1):
  trace, ras: move ras_event.h under include/trace/events

Xie XiuQi (4):
  memory-failure: export page_type and action result
  memory-failure: change type of action_result's param 3 to enum
  tracing: add trace event for memory-failure
  tracing: fix build error in mm/memory-failure.c

 drivers/acpi/acpi_extlog.c |2 +-
 drivers/edac/edac_mc.c |2 +-
 drivers/edac/ghes_edac.c   |2 +-
 drivers/pci/pcie/aer/aerdrv_errprint.c |2 +-
 drivers/ras/ras.c  |3 +-
 include/linux/mm.h |   34 
 include/ras/ras_event.h|  238 ---
 include/trace/events/ras.h |  322 
 mm/Kconfig |1 +
 mm/memory-failure.c|  172 +++--
 10 files changed, 433 insertions(+), 345 deletions(-)
 delete mode 100644 include/ras/ras_event.h
 create mode 100644 include/trace/events/ras.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 v6 3/5] tracing: add trace event for memory-failure

2015-05-20 Thread Xie XiuQi
RAS user space tools like rasdaemon which base on trace event, could
receive mce error event, but no memory recovery result event. So, I
want to add this event to make this scenario complete.

This patch add a event at ras group for memory-failure.

The output like below:
#  tracer: nop
#
#  entries-in-buffer/entries-written: 2/2   #P:24
#
#   _-=> irqs-off
#  / _=> need-resched
# | / _---=> hardirq/softirq
# || / _--=> preempt-depth
# ||| / delay
#TASK-PID   CPU#  TIMESTAMP  FUNCTION
#   | |   |      | |
   mce-inject-13150 [001]    277.019359: memory_failure_event: pfn 
0x19869: recovery action for free buddy page: Delayed

Cc: Tony Luck 
Reviewed-by: Naoya Horiguchi 
Acked-by: Steven Rostedt 
Signed-off-by: Xie XiuQi 
---
 include/ras/ras_event.h |   85 +++
 mm/memory-failure.c |3 ++
 2 files changed, 88 insertions(+), 0 deletions(-)

diff --git a/include/ras/ras_event.h b/include/ras/ras_event.h
index 79abb9c..1443d79 100644
--- a/include/ras/ras_event.h
+++ b/include/ras/ras_event.h
@@ -11,6 +11,7 @@
 #include 
 #include 
 #include 
+#include 
 
 /*
  * MCE Extended Error Log trace event
@@ -232,6 +233,90 @@ TRACE_EVENT(aer_event,
__print_flags(__entry->status, "|", aer_uncorrectable_errors))
 );
 
+/*
+ * memory-failure recovery action result event
+ *
+ * unsigned long pfn - Page Frame Number of the corrupted page
+ * int type-   Page types of the corrupted page
+ * int result  -   Result of recovery action
+ */
+
+#ifdef CONFIG_MEMORY_FAILURE
+#define MF_ACTION_RESULT   \
+   EM ( MF_IGNORED, "Ignored" )\
+   EM ( MF_FAILED,  "Failed" ) \
+   EM ( MF_DELAYED, "Delayed" )\
+   EMe ( MF_RECOVERED, "Recovered" )
+
+#define MF_PAGE_TYPE   \
+   EM ( MF_MSG_KERNEL, "reserved kernel page" )\
+   EM ( MF_MSG_KERNEL_HIGH_ORDER, "high-order kernel page" )   \
+   EM ( MF_MSG_SLAB, "kernel slab page" )  \
+   EM ( MF_MSG_DIFFERENT_COMPOUND, "different compound page after locking" 
) \
+   EM ( MF_MSG_POISONED_HUGE, "huge page already hardware poisoned" )  
\
+   EM ( MF_MSG_HUGE, "huge page" ) \
+   EM ( MF_MSG_FREE_HUGE, "free huge page" )   \
+   EM ( MF_MSG_UNMAP_FAILED, "unmapping failed page" ) \
+   EM ( MF_MSG_DIRTY_SWAPCACHE, "dirty swapcache page" )   \
+   EM ( MF_MSG_CLEAN_SWAPCACHE, "clean swapcache page" )   \
+   EM ( MF_MSG_DIRTY_MLOCKED_LRU, "dirty mlocked LRU page" )   \
+   EM ( MF_MSG_CLEAN_MLOCKED_LRU, "clean mlocked LRU page" )   \
+   EM ( MF_MSG_DIRTY_UNEVICTABLE_LRU, "dirty unevictable LRU page" )   
\
+   EM ( MF_MSG_CLEAN_UNEVICTABLE_LRU, "clean unevictable LRU page" )   
\
+   EM ( MF_MSG_DIRTY_LRU, "dirty LRU page" )   \
+   EM ( MF_MSG_CLEAN_LRU, "clean LRU page" )   \
+   EM ( MF_MSG_TRUNCATED_LRU, "already truncated LRU page" )   \
+   EM ( MF_MSG_BUDDY, "free buddy page" )  \
+   EM ( MF_MSG_BUDDY_2ND, "free buddy page (2nd try)" )\
+   EMe ( MF_MSG_UNKNOWN, "unknown page" )
+
+/*
+ * First define the enums in MM_ACTION_RESULT to be exported to userspace
+ * via TRACE_DEFINE_ENUM().
+ */
+#undef EM
+#undef EMe
+#define EM(a, b) TRACE_DEFINE_ENUM(a);
+#define EMe(a, b)  TRACE_DEFINE_ENUM(a);
+
+MF_ACTION_RESULT
+MF_PAGE_TYPE
+
+/*
+ * Now redefine the EM() and EMe() macros to map the enums to the strings
+ * that will be printed in the output.
+ */
+#undef EM
+#undef EMe
+#define EM(a, b)   { a, b },
+#define EMe(a, b)  { a, b }
+
+TRACE_EVENT(memory_failure_event,
+   TP_PROTO(unsigned long pfn,
+int type,
+int result),
+
+   TP_ARGS(pfn, type, result),
+
+   TP_STRUCT__entry(
+   __field(unsigned long, pfn)
+   __field(int, type)
+   __field(int, result)
+   ),
+
+   TP_fast_assign(
+   __entry->pfn= pfn;
+   __entry->type   = type;
+   __entry->result = result;
+   ),
+
+   TP_printk("pfn %#lx: recovery action for %s: %s",
+   __entry->pfn,
+   __print_symbolic(__entry->type, MF_PAGE_TYPE),
+   __print_symbolic(__entry->result, MF_ACTION_RESULT)
+   )
+);
+#endif /* CONFIG_MEMORY_FAILURE */
 #endif /* _TRACE_HW_EVENT_MC_H */
 
 /* This part must be outside protection */
diff --git a/mm/memory-failure.c b/mm/memory-failure.c
index a3f7ea2..9e9d048 100644
--- a/mm/memory-failure.c
+++ b/mm/memory-failure.c
@@ -56,6 +56,7 @@
 #include 
 #include 
 #include "

[PATCH v6 2/5] memory-failure: change type of action_result's param 3 to enum

2015-05-20 Thread Xie XiuQi
Change type of action_result's param 3 to enum for type consistency,
and rename mf_outcome to mf_result for clearly.

Acked-by: Naoya Horiguchi 
Signed-off-by: Xie XiuQi 
---
 include/linux/mm.h  |2 +-
 mm/memory-failure.c |3 ++-
 2 files changed, 3 insertions(+), 2 deletions(-)

diff --git a/include/linux/mm.h b/include/linux/mm.h
index 3abf13c..0632dea 100644
--- a/include/linux/mm.h
+++ b/include/linux/mm.h
@@ -2156,7 +2156,7 @@ extern int soft_offline_page(struct page *page, int 
flags);
 /*
  * Error handlers for various types of pages.
  */
-enum mf_outcome {
+enum mf_result {
MF_IGNORED, /* Error: cannot be handled */
MF_FAILED,  /* Error: handling failed */
MF_DELAYED, /* Will be handled later */
diff --git a/mm/memory-failure.c b/mm/memory-failure.c
index 5650dec..a3f7ea2 100644
--- a/mm/memory-failure.c
+++ b/mm/memory-failure.c
@@ -847,7 +847,8 @@ static struct page_state {
  * "Dirty/Clean" indication is not 100% accurate due to the possibility of
  * setting PG_dirty outside page lock. See also comment above set_page_dirty().
  */
-static void action_result(unsigned long pfn, enum mf_action_page_type type, 
int result)
+static void action_result(unsigned long pfn, enum mf_action_page_type type,
+ enum mf_result result)
 {
pr_err("MCE %#lx: recovery action for %s: %s\n",
pfn, action_page_types[type], action_name[result]);
-- 
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 v4 3/3] kvm/powerpc: Export HCALL reason codes

2015-05-20 Thread Hemant Kumar
For perf to analyze the KVM events like hcalls, we need the
hypervisor calls and their codes to be exported through uapi.

This patch moves most of the pSeries hcall codes from
arch/powerpc/include/asm/hvcall.h to
arch/powerpc/include/uapi/asm/pseries_hcalls.h.
It also moves the mapping  from
arch/powerpc/kvm/trace_hv.h to
arch/powerpc/include/uapi/asm/trace_hcall_pseries.h.

Signed-off-by: Hemant Kumar 
---
Changes :
- Made name space changes to indicate changes related to pseries
  (Suggested by Scott Wood)

 arch/powerpc/include/asm/hvcall.h  | 120 +---
 arch/powerpc/include/uapi/asm/kvm_perf_book3s.h|   4 +
 arch/powerpc/include/uapi/asm/pseries_hcalls.h | 123 +
 .../powerpc/include/uapi/asm/trace_hcall_pseries.h | 122 
 arch/powerpc/kvm/trace_hv.h| 117 +---
 5 files changed, 252 insertions(+), 234 deletions(-)
 create mode 100644 arch/powerpc/include/uapi/asm/pseries_hcalls.h
 create mode 100644 arch/powerpc/include/uapi/asm/trace_hcall_pseries.h

diff --git a/arch/powerpc/include/asm/hvcall.h 
b/arch/powerpc/include/asm/hvcall.h
index 85bc8c0..6e38210 100644
--- a/arch/powerpc/include/asm/hvcall.h
+++ b/arch/powerpc/include/asm/hvcall.h
@@ -155,124 +155,8 @@
 /* Each control block has to be on a 4K boundary */
 #define H_CB_ALIGNMENT  4096
 
-/* pSeries hypervisor opcodes */
-#define H_REMOVE   0x04
-#define H_ENTER0x08
-#define H_READ 0x0c
-#define H_CLEAR_MOD0x10
-#define H_CLEAR_REF0x14
-#define H_PROTECT  0x18
-#define H_GET_TCE  0x1c
-#define H_PUT_TCE  0x20
-#define H_SET_SPRG00x24
-#define H_SET_DABR 0x28
-#define H_PAGE_INIT0x2c
-#define H_SET_ASR  0x30
-#define H_ASR_ON   0x34
-#define H_ASR_OFF  0x38
-#define H_LOGICAL_CI_LOAD  0x3c
-#define H_LOGICAL_CI_STORE 0x40
-#define H_LOGICAL_CACHE_LOAD   0x44
-#define H_LOGICAL_CACHE_STORE  0x48
-#define H_LOGICAL_ICBI 0x4c
-#define H_LOGICAL_DCBF 0x50
-#define H_GET_TERM_CHAR0x54
-#define H_PUT_TERM_CHAR0x58
-#define H_REAL_TO_LOGICAL  0x5c
-#define H_HYPERVISOR_DATA  0x60
-#define H_EOI  0x64
-#define H_CPPR 0x68
-#define H_IPI  0x6c
-#define H_IPOLL0x70
-#define H_XIRR 0x74
-#define H_PERFMON  0x7c
-#define H_MIGRATE_DMA  0x78
-#define H_REGISTER_VPA 0xDC
-#define H_CEDE 0xE0
-#define H_CONFER   0xE4
-#define H_PROD 0xE8
-#define H_GET_PPP  0xEC
-#define H_SET_PPP  0xF0
-#define H_PURR 0xF4
-#define H_PIC  0xF8
-#define H_REG_CRQ  0xFC
-#define H_FREE_CRQ 0x100
-#define H_VIO_SIGNAL   0x104
-#define H_SEND_CRQ 0x108
-#define H_COPY_RDMA0x110
-#define H_REGISTER_LOGICAL_LAN 0x114
-#define H_FREE_LOGICAL_LAN 0x118
-#define H_ADD_LOGICAL_LAN_BUFFER 0x11C
-#define H_SEND_LOGICAL_LAN 0x120
-#define H_BULK_REMOVE  0x124
-#define H_MULTICAST_CTRL   0x130
-#define H_SET_XDABR0x134
-#define H_STUFF_TCE0x138
-#define H_PUT_TCE_INDIRECT 0x13C
-#define H_CHANGE_LOGICAL_LAN_MAC 0x14C
-#define H_VTERM_PARTNER_INFO   0x150
-#define H_REGISTER_VTERM   0x154
-#define H_FREE_VTERM   0x158
-#define H_RESET_EVENTS  0x15C
-#define H_ALLOC_RESOURCE0x160
-#define H_FREE_RESOURCE 0x164
-#define H_MODIFY_QP 0x168
-#define H_QUERY_QP  0x16C
-#define H_REREGISTER_PMR0x170
-#define H_REGISTER_SMR  0x174
-#define H_QUERY_MR  0x178
-#define H_QUERY_MW  0x17C
-#define H_QUERY_HCA 0x180
-#define H_QUERY_PORT0x184
-#define H_MODIFY_PORT   0x188
-#define H_DEFINE_AQP1   0x18C
-#define H_GET_TRACE_BUFFER  0x190
-#define H_DEFINE_AQP0   0x194
-#define H_RESIZE_MR 0x198
-#define H_ATTACH_MCQP   0x19C
-#define H_DETACH_MCQP   0x1A0
-#define H_CREATE_RPT0x1A4
-#define H_REMOVE_RPT0x1A8
-#define H_REGISTER_RPAGES   0x1AC
-#define H_DISABLE_AND_GETC  0x1B0
-#define H_ERROR_DATA0x1B4
-#define H_GET_HCA_INFO  0x1B8
-#define H_GET_PERF_COUNT0x1BC
-#define H_MANAGE_TRACE  0x1C0
-#define H_FREE_LOGICAL_LAN_BUFFER 0x1D4
-#define H_QUERY_INT_STATE   0x1E4
-#define H_POLL_PENDING 0x1D8
-#define H_ILLAN_ATTRIBUTES 0x244
-#define H_MODIFY_HEA_QP0x250
-#define H_QUERY_HEA_QP 0x254
-#define H_QUERY_HEA0x258
-#define H_QUERY_HEA_PORT   0x25C
-#define H_MODIFY_HEA_PORT  0x260
-#define H_REG_BCMC 0x264
-

[PATCH v4 1/3] kvm/powerpc: Export kvm exit reasons

2015-05-20 Thread Hemant Kumar
To analyze the kvm exits with perf, we will need to map the exit codes
with the exit reasons. Such a mapping exists today in trace_book3s.h.
Currently its not exported to perf.

This patch moves these kvm exit reasons and their mapping from
"arch/powerpc/kvm/trace_book3s.h" to
"arch/powerpc/include/uapi/asm/trace_book3s.h".
Accordingly change the include files in "trace_hv.h" and "trace_pr.h".

Also, add a file kvm_perf_book3s.h which defines the kvm tracepoints to
trace for kvm exit events. This is added to indicate that the
tracepoints are book3s specific. Generic "kvm_perf.h" then can just
include "kvm_perf_book3s.h".

Signed-off-by: Hemant Kumar 
---
Changes :
- Moved the uapi related changes from the perf side patchset to this
  patchset.
- Made name space changes to indicate changes specific to book3s
  (Suggested by Scott Wood)

 arch/powerpc/include/uapi/asm/kvm_perf.h|  6 +
 arch/powerpc/include/uapi/asm/kvm_perf_book3s.h | 15 
 arch/powerpc/include/uapi/asm/trace_book3s.h| 32 +
 arch/powerpc/kvm/trace_book3s.h | 32 -
 arch/powerpc/kvm/trace_hv.h |  2 +-
 arch/powerpc/kvm/trace_pr.h |  2 +-
 6 files changed, 55 insertions(+), 34 deletions(-)
 create mode 100644 arch/powerpc/include/uapi/asm/kvm_perf.h
 create mode 100644 arch/powerpc/include/uapi/asm/kvm_perf_book3s.h
 create mode 100644 arch/powerpc/include/uapi/asm/trace_book3s.h
 delete mode 100644 arch/powerpc/kvm/trace_book3s.h

diff --git a/arch/powerpc/include/uapi/asm/kvm_perf.h 
b/arch/powerpc/include/uapi/asm/kvm_perf.h
new file mode 100644
index 000..5ed2ff3
--- /dev/null
+++ b/arch/powerpc/include/uapi/asm/kvm_perf.h
@@ -0,0 +1,6 @@
+#ifndef _ASM_POWERPC_KVM_PERF_H
+#define _ASM_POWERPC_KVM_PERF_H
+
+#include 
+
+#endif
diff --git a/arch/powerpc/include/uapi/asm/kvm_perf_book3s.h 
b/arch/powerpc/include/uapi/asm/kvm_perf_book3s.h
new file mode 100644
index 000..735901f
--- /dev/null
+++ b/arch/powerpc/include/uapi/asm/kvm_perf_book3s.h
@@ -0,0 +1,15 @@
+#ifndef _ASM_POWERPC_KVM_PERF_BOOK3S_H
+#define _ASM_POWERPC_KVM_PERF_BOOK3S_H
+
+#include 
+#include 
+
+#define DECODE_STR_LEN 20
+
+#define VCPU_ID "vcpu_id"
+
+#define KVM_ENTRY_TRACE "kvm_hv:kvm_guest_enter"
+#define KVM_EXIT_TRACE "kvm_hv:kvm_guest_exit"
+#define KVM_EXIT_REASON "trap"
+
+#endif /* _ASM_POWERPC_KVM_PERF_BOOK3S_H */
diff --git a/arch/powerpc/include/uapi/asm/trace_book3s.h 
b/arch/powerpc/include/uapi/asm/trace_book3s.h
new file mode 100644
index 000..f647ce0
--- /dev/null
+++ b/arch/powerpc/include/uapi/asm/trace_book3s.h
@@ -0,0 +1,32 @@
+#if !defined(_TRACE_KVM_BOOK3S_H)
+#define _TRACE_KVM_BOOK3S_H
+
+/*
+ * Common defines used by the trace macros in trace_pr.h and trace_hv.h
+ */
+
+#define kvm_trace_symbol_exit \
+   {0x100, "SYSTEM_RESET"}, \
+   {0x200, "MACHINE_CHECK"}, \
+   {0x300, "DATA_STORAGE"}, \
+   {0x380, "DATA_SEGMENT"}, \
+   {0x400, "INST_STORAGE"}, \
+   {0x480, "INST_SEGMENT"}, \
+   {0x500, "EXTERNAL"}, \
+   {0x501, "EXTERNAL_LEVEL"}, \
+   {0x502, "EXTERNAL_HV"}, \
+   {0x600, "ALIGNMENT"}, \
+   {0x700, "PROGRAM"}, \
+   {0x800, "FP_UNAVAIL"}, \
+   {0x900, "DECREMENTER"}, \
+   {0x980, "HV_DECREMENTER"}, \
+   {0xc00, "SYSCALL"}, \
+   {0xd00, "TRACE"}, \
+   {0xe00, "H_DATA_STORAGE"}, \
+   {0xe20, "H_INST_STORAGE"}, \
+   {0xe40, "H_EMUL_ASSIST"}, \
+   {0xf00, "PERFMON"}, \
+   {0xf20, "ALTIVEC"}, \
+   {0xf40, "VSX"}
+
+#endif
diff --git a/arch/powerpc/kvm/trace_book3s.h b/arch/powerpc/kvm/trace_book3s.h
deleted file mode 100644
index f647ce0..000
--- a/arch/powerpc/kvm/trace_book3s.h
+++ /dev/null
@@ -1,32 +0,0 @@
-#if !defined(_TRACE_KVM_BOOK3S_H)
-#define _TRACE_KVM_BOOK3S_H
-
-/*
- * Common defines used by the trace macros in trace_pr.h and trace_hv.h
- */
-
-#define kvm_trace_symbol_exit \
-   {0x100, "SYSTEM_RESET"}, \
-   {0x200, "MACHINE_CHECK"}, \
-   {0x300, "DATA_STORAGE"}, \
-   {0x380, "DATA_SEGMENT"}, \
-   {0x400, "INST_STORAGE"}, \
-   {0x480, "INST_SEGMENT"}, \
-   {0x500, "EXTERNAL"}, \
-   {0x501, "EXTERNAL_LEVEL"}, \
-   {0x502, "EXTERNAL_HV"}, \
-   {0x600, "ALIGNMENT"}, \
-   {0x700, "PROGRAM"}, \
-   {0x800, "FP_UNAVAIL"}, \
-   {0x900, "DECREMENTER"}, \
-   {0x980, "HV_DECREMENTER"}, \
-   {0xc00, "SYSCALL"}, \
-   {0xd00, "TRACE"}, \
-   {0xe00, "H_DATA_STORAGE"}, \
-   {0xe20, "H_INST_STORAGE"}, \
-   {0xe40, "H_EMUL_ASSIST"}, \
-   {0xf00, "PERFMON"}, \
-   {0xf20, "ALTIVEC"}, \
-   {0xf40, "VSX"}
-
-#endif
diff --git a/arch/powerpc/kvm/trace_hv.h b/arch/powerpc/kvm/trace_hv.h
index 33d9daf..02d0a07 100644
--- a/arch/powerpc/kvm/trace_hv.h
+++ b/arch/powerpc/kvm/trace_hv.h
@@ -2,7 +2,7 @@
 #define _TRACE_KVM_HV_H
 
 #include 
-#include "trace_book3s.h"
+#include 
 #include 
 #include 
 
di

[PATCH v4 2/3] kvm/powerpc: Add exit reason for return code 0x0

2015-05-20 Thread Hemant Kumar
This patch adds an exit reason "RETURN_TO_HOST" for the return code
0x0. Note that this is not related to any interrupt vector address, but
this is added just to make sure that perf doesn't complain if and when a
kvm exit happens with a trap code as 0x0.

Signed-off-by: Hemant Kumar 
---
 arch/powerpc/include/uapi/asm/trace_book3s.h | 1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/powerpc/include/uapi/asm/trace_book3s.h 
b/arch/powerpc/include/uapi/asm/trace_book3s.h
index f647ce0..8635005 100644
--- a/arch/powerpc/include/uapi/asm/trace_book3s.h
+++ b/arch/powerpc/include/uapi/asm/trace_book3s.h
@@ -6,6 +6,7 @@
  */
 
 #define kvm_trace_symbol_exit \
+   {0x0,   "RETURN_TO_HOST"}, \
{0x100, "SYSTEM_RESET"}, \
{0x200, "MACHINE_CHECK"}, \
{0x300, "DATA_STORAGE"}, \
-- 
1.9.3

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


[RFC][PATCH 1/2] cgroup: Add generic cgroup subsystem permission checks

2015-05-20 Thread John Stultz
From: Colin Cross 

Rather than using explicit euid == 0 checks when trying to move
tasks into a cgroup, move permission checks into each specific
cgroup subsystem. If a subsystem does not specify a 'allow_attach'
handler, then we fall back to doing the checks the old way.

This patch adds a 'allow_attach' handler instead of reusing the
'can_attach' handler, since if the 'can_attach' handler was
reused, a new cgroup that implements 'can_attach' but not the
permission checks could end up with no permission checks at all.

Cc: Tejun Heo 
Cc: Li Zefan 
Cc: Jonathan Corbet 
Cc: cgro...@vger.kernel.org
Cc: Android Kernel Team 
Cc: Rom Lemarchand 
Cc: Colin Cross 
Original-Author: San Mehat 
Signed-off-by: Colin Cross 
[jstultz: Rewording of commit message]
Signed-off-by: John Stultz 
---
 Documentation/cgroups/cgroups.txt |  9 +
 include/linux/cgroup.h|  2 ++
 kernel/cgroup.c   | 39 ---
 3 files changed, 47 insertions(+), 3 deletions(-)

diff --git a/Documentation/cgroups/cgroups.txt 
b/Documentation/cgroups/cgroups.txt
index f935fac..88af0f0 100644
--- a/Documentation/cgroups/cgroups.txt
+++ b/Documentation/cgroups/cgroups.txt
@@ -578,6 +578,15 @@ is completely unused; @cgrp->parent is still valid. (Note 
- can also
 be called for a newly-created cgroup if an error occurs after this
 subsystem's create() method has been called for the new cgroup).
 
+int allow_attach(struct cgroup *cgrp, struct cgroup_taskset *tset)
+(cgroup_mutex held by caller)
+
+Called prior to moving a task into a cgroup; if the subsystem
+returns an error, this will abort the attach operation.  Used
+to extend the permission checks - if all subsystems in a cgroup
+return 0, the attach will be allowed to proceed, even if the
+default permission check (root or same user) fails.
+
 int can_attach(struct cgroup *cgrp, struct cgroup_taskset *tset)
 (cgroup_mutex held by caller)
 
diff --git a/include/linux/cgroup.h b/include/linux/cgroup.h
index b9cb94c..0ea785d 100644
--- a/include/linux/cgroup.h
+++ b/include/linux/cgroup.h
@@ -643,6 +643,8 @@ struct cgroup_subsys {
void (*css_reset)(struct cgroup_subsys_state *css);
void (*css_e_css_changed)(struct cgroup_subsys_state *css);
 
+   int (*allow_attach)(struct cgroup_subsys_state *css,
+   struct cgroup_taskset *tset);
int (*can_attach)(struct cgroup_subsys_state *css,
  struct cgroup_taskset *tset);
void (*cancel_attach)(struct cgroup_subsys_state *css,
diff --git a/kernel/cgroup.c b/kernel/cgroup.c
index 29a7b2c..57e0fd7 100644
--- a/kernel/cgroup.c
+++ b/kernel/cgroup.c
@@ -2376,6 +2376,25 @@ static int cgroup_attach_task(struct cgroup *dst_cgrp,
return ret;
 }
 
+static int cgroup_allow_attach(struct cgroup *cgrp, struct cgroup_taskset 
*tset)
+{
+   struct cgroup_subsys_state *css;
+   int i;
+   int ret;
+
+   for_each_css(css, i, cgrp) {
+   if (css->ss->allow_attach) {
+   ret = css->ss->allow_attach(css, tset);
+   if (ret)
+   return ret;
+   } else {
+   return -EACCES;
+   }
+   }
+
+   return 0;
+}
+
 /*
  * Find the task_struct of the task to attach by vpid and pass it along to the
  * function to attach either it or all tasks in its threadgroup. Will lock
@@ -2414,9 +2433,23 @@ retry_find_task:
if (!uid_eq(cred->euid, GLOBAL_ROOT_UID) &&
!uid_eq(cred->euid, tcred->uid) &&
!uid_eq(cred->euid, tcred->suid)) {
-   rcu_read_unlock();
-   ret = -EACCES;
-   goto out_unlock_cgroup;
+   /*
+* if the default permission check fails, give each
+* cgroup a chance to extend the permission check
+*/
+   struct cgroup_taskset tset = {
+   .src_csets = LIST_HEAD_INIT(tset.src_csets),
+   .dst_csets = LIST_HEAD_INIT(tset.dst_csets),
+   .csets = &tset.src_csets,
+   };
+   struct css_set *cset;
+   cset = task_css_set(tsk);
+   list_add(&cset->mg_node, &tset.src_csets);
+   ret = cgroup_allow_attach(cgrp, &tset);
+   if (ret) {
+   rcu_read_unlock();
+   goto out_unlock_cgroup;
+   }
}
} else
tsk = current;
-- 
1.9.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.o

[RFC][PATCH 0/2] Android style loosening of cgroup attach permissions

2015-05-20 Thread John Stultz
As a heads up, this is just a first RFC and not a submission.

Android currently loosens the cgroup attchment permissions, allowing
tasks with CAP_SYS_NICE to be able to allow tasks to move arbitrary
tasks across cgroups.

At first glance, overloading CAP_SYS_NICE seems a bit hackish, but this
shows that there is a active and widely deployed use for different cgroup
attachment rules then what is currently available.

I've tried to rework the patches so this attachment policy is build
time configurable, and wanted to send them out for review so folks
might give their thoughts on this implementation and what they might
see as a better way to go about achieving the same goal.

Thoughts and feedback would be appriciated!

thanks
-john

Cc: Tejun Heo 
Cc: Li Zefan 
Cc: Jonathan Corbet 
Cc: cgro...@vger.kernel.org
Cc: Android Kernel Team 
Cc: Rom Lemarchand 
Cc: Colin Cross 

Colin Cross (1):
  cgroup: Add generic cgroup subsystem permission checks

Rom Lemarchand (1):
  cgroup: Add a memcg and cpu cg allow_attach policy for Android

 Documentation/cgroups/cgroups.txt |  9 +
 include/linux/cgroup.h| 14 ++
 init/Kconfig  |  7 +++
 kernel/Makefile   |  1 +
 kernel/cgroup.c   | 39 ---
 kernel/cgroup_nice_attach.c   | 29 +
 kernel/sched/core.c   |  3 +++
 mm/memcontrol.c   |  3 +++
 8 files changed, 102 insertions(+), 3 deletions(-)
 create mode 100644 kernel/cgroup_nice_attach.c

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


[RFC][PATCH 2/2] cgroup: Add a memcg and cpu cg allow_attach policy for Android

2015-05-20 Thread John Stultz
From: Rom Lemarchand 

If CONFIG_CGROUP_NICE_ATTACH is enabled, this implements an
allow_attach policy for Android, which allows any process with
CAP_SYS_NICE to move tasks across mem and cpu cgroups.

Cc: Tejun Heo 
Cc: Li Zefan 
Cc: Jonathan Corbet 
Cc: cgro...@vger.kernel.org
Cc: Android Kernel Team 
Cc: Rom Lemarchand 
Cc: Colin Cross 
Signed-off-by: Rom Lemarchand 
[jstultz: Majorly reworked to make this policy function
 configurable, also squished in cpu and mem cgroup enablement.]
Signed-off-by: John Stultz 
---
 include/linux/cgroup.h  | 12 
 init/Kconfig|  7 +++
 kernel/Makefile |  1 +
 kernel/cgroup_nice_attach.c | 29 +
 kernel/sched/core.c |  3 +++
 mm/memcontrol.c |  3 +++
 6 files changed, 55 insertions(+)
 create mode 100644 kernel/cgroup_nice_attach.c

diff --git a/include/linux/cgroup.h b/include/linux/cgroup.h
index 0ea785d..d584d31 100644
--- a/include/linux/cgroup.h
+++ b/include/linux/cgroup.h
@@ -943,6 +943,18 @@ struct cgroup_subsys_state *cgroup_get_e_css(struct cgroup 
*cgroup,
 struct cgroup_subsys_state *css_tryget_online_from_dir(struct dentry *dentry,
   struct cgroup_subsys 
*ss);
 
+#ifdef CONFIG_CGROUP_NICE_ATTACH
+/*
+ * Default Android check for whether the current process is allowed to move a
+ * task across cgroups, either because CAP_SYS_NICE is set or because the uid
+ * of the calling process is the same as the moved task or because we are
+ * running as root.
+ * Returns 0 if this is allowed, or -EACCES otherwise.
+ */
+int cgroup_nice_allow_attach(struct cgroup_subsys_state *css,
+   struct cgroup_taskset *tset);
+#endif
+
 #else /* !CONFIG_CGROUPS */
 
 struct cgroup_subsys_state;
diff --git a/init/Kconfig b/init/Kconfig
index f5dbc6d..0e66e44 100644
--- a/init/Kconfig
+++ b/init/Kconfig
@@ -1132,6 +1132,13 @@ config DEBUG_BLK_CGROUP
Enable some debugging help. Currently it exports additional stat
files in a cgroup which can be useful for debugging.
 
+config CGROUP_NICE_ATTACH
+   bool "Enabled Android-style loosening of perm checks for attachment"
+   default n
+   ---help---
+   Allows non-root processes to add arbitrary processes to mem and cpu
+   cgroups if they have CAP_SYS_NICE set. This is useful for Android.
+
 endif # CGROUPS
 
 config CHECKPOINT_RESTORE
diff --git a/kernel/Makefile b/kernel/Makefile
index 1408b33..c81256b 100644
--- a/kernel/Makefile
+++ b/kernel/Makefile
@@ -52,6 +52,7 @@ obj-$(CONFIG_KEXEC) += kexec.o
 obj-$(CONFIG_BACKTRACE_SELF_TEST) += backtracetest.o
 obj-$(CONFIG_COMPAT) += compat.o
 obj-$(CONFIG_CGROUPS) += cgroup.o
+obj-$(CONFIG_CGROUP_NICE_ATTACH) += cgroup_nice_attach.o
 obj-$(CONFIG_CGROUP_FREEZER) += cgroup_freezer.o
 obj-$(CONFIG_CPUSETS) += cpuset.o
 obj-$(CONFIG_UTS_NS) += utsname.o
diff --git a/kernel/cgroup_nice_attach.c b/kernel/cgroup_nice_attach.c
new file mode 100644
index 000..b94c68e
--- /dev/null
+++ b/kernel/cgroup_nice_attach.c
@@ -0,0 +1,29 @@
+#include 
+#include 
+
+/*
+ * Default Android check for whether the current process is allowed to move a
+ * task across cgroups, either because CAP_SYS_NICE is set or because the uid
+ * of the calling process is the same as the moved task or because we are
+ * running as root.
+ */
+int cgroup_nice_allow_attach(struct cgroup_subsys_state *css,
+   struct cgroup_taskset *tset)
+{
+   const struct cred *cred = current_cred(), *tcred;
+   struct task_struct *task;
+
+   if (capable(CAP_SYS_NICE))
+   return 0;
+
+   cgroup_taskset_for_each(task, tset) {
+   tcred = __task_cred(task);
+
+   if (current != task && !uid_eq(cred->euid, tcred->uid) &&
+   !uid_eq(cred->euid, tcred->suid))
+   return -EACCES;
+   }
+
+   return 0;
+}
+
diff --git a/kernel/sched/core.c b/kernel/sched/core.c
index 62671f5..51dc86f 100644
--- a/kernel/sched/core.c
+++ b/kernel/sched/core.c
@@ -8368,6 +8368,9 @@ struct cgroup_subsys cpu_cgrp_subsys = {
.fork   = cpu_cgroup_fork,
.can_attach = cpu_cgroup_can_attach,
.attach = cpu_cgroup_attach,
+#ifdef CONFIG_CGROUP_NICE_ATTACH
+   .allow_attach   = cgroup_nice_allow_attach,
+#endif
.exit   = cpu_cgroup_exit,
.legacy_cftypes = cpu_files,
.early_init = 1,
diff --git a/mm/memcontrol.c b/mm/memcontrol.c
index b34ef4a..6287697 100644
--- a/mm/memcontrol.c
+++ b/mm/memcontrol.c
@@ -5387,6 +5387,9 @@ struct cgroup_subsys memory_cgrp_subsys = {
.can_attach = mem_cgroup_can_attach,
.cancel_attach = mem_cgroup_cancel_attach,
.attach = mem_cgroup_move_task,
+#ifdef CONFIG_CGROUP_NICE_ATTACH
+   .allow_attach = cgroup_nice_allow_attach,
+#endif
.bind = mem_cgroup_bind,
.dfl_cftypes = memory_

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

2015-05-20 Thread Florian Fainelli
2015-05-20 19:59 GMT-07:00 Stephen Rothwell :
> Hi all,
>
> Today's linux-next merge of the net-next tree got a conflict in
> drivers/net/phy/phy.c between commit c15e10e71ce3 ("net: phy: Make sure
> phy_start() always re-enables the phy interrupts") from the net tree
> and commit 3e2186e02112 ("net: phy: Add state machine state transitions
> debug prints") from the net-next tree.
>
> I fixed it up (see below) and can carry the fix as necessary (no action
> is required).

Looks correct to me, thanks Stephen!

>
> --
> Cheers,
> Stephen Rothwells...@canb.auug.org.au
>
> diff --cc drivers/net/phy/phy.c
> index 47cd578052fc,1457ecf75dcc..
> --- a/drivers/net/phy/phy.c
> +++ b/drivers/net/phy/phy.c
> @@@ -783,7 -794,8 +808,8 @@@ void phy_state_machine(struct work_stru
> struct delayed_work *dwork = to_delayed_work(work);
> struct phy_device *phydev =
> container_of(dwork, struct phy_device, state_queue);
>  -  bool needs_aneg = false, do_suspend = false, do_resume = false;
>  +  bool needs_aneg = false, do_suspend = false;
> +   enum phy_state old_state;
> int err = 0;
>
> mutex_lock(&phydev->lock);



-- 
Florian
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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 v6 1/6] arm64: Add HAVE_REGS_AND_STACK_ACCESS_API feature

2015-05-20 Thread David Long

On 05/20/15 09:39, Catalin Marinas wrote:

On Mon, Apr 20, 2015 at 04:19:42PM -0400, David Long wrote:

diff --git a/arch/arm64/include/uapi/asm/ptrace.h 
b/arch/arm64/include/uapi/asm/ptrace.h
index 6913643..58c0223 100644
--- a/arch/arm64/include/uapi/asm/ptrace.h
+++ b/arch/arm64/include/uapi/asm/ptrace.h
@@ -61,6 +61,42 @@

  #ifndef __ASSEMBLY__

+#define ARM_pstate pstate
+#define ARM_pc pc
+#define ARM_sp sp
+#define ARM_lr regs[30]
+#define ARM_fp regs[29]
+#define ARM_x28regs[28]
+#define ARM_x27regs[27]
+#define ARM_x26regs[26]
+#define ARM_x25regs[25]
+#define ARM_x24regs[24]
+#define ARM_x23regs[23]
+#define ARM_x22regs[22]
+#define ARM_x21regs[21]
+#define ARM_x20regs[20]
+#define ARM_x19regs[19]
+#define ARM_x18regs[18]
+#define ARM_ip1regs[17]
+#define ARM_ip0regs[16]
+#define ARM_x15regs[15]
+#define ARM_x14regs[14]
+#define ARM_x13regs[13]
+#define ARM_x12regs[12]
+#define ARM_x11regs[11]
+#define ARM_x10regs[10]
+#define ARM_x9 regs[9]
+#define ARM_x8 regs[8]
+#define ARM_x7 regs[7]
+#define ARM_x6 regs[6]
+#define ARM_x5 regs[5]
+#define ARM_x4 regs[4]
+#define ARM_x3 regs[3]
+#define ARM_x2 regs[2]
+#define ARM_x1 regs[1]
+#define ARM_x0 regs[0]
+#define ARM_ORIG_x0orig_x0


I replied some time ago on this part. I don't see the point these
macros.



I replied belatedly on April 20 saying what I did matches (more or less) 
how it's done on various other platforms, including arm and powerpc.  It 
looks like this comes from the pt_regs structure defining the registers 
as an array instead of a list of structure fields. It looks to me like 
that design choice is pretty widely depended upon now and would be quite 
disruptive to change.  It also seems to me a relatively clean way to do 
it on systems with a uniform register set.



+
  /*
   * User structures for general purpose, floating point and debug registers.
   */
diff --git a/arch/arm64/kernel/ptrace.c b/arch/arm64/kernel/ptrace.c
index d882b83..a889f79 100644
--- a/arch/arm64/kernel/ptrace.c
+++ b/arch/arm64/kernel/ptrace.c
@@ -48,6 +48,122 @@
  #define CREATE_TRACE_POINTS
  #include 

+struct pt_regs_offset {
+   const char *name;
+   int offset;
+};
+
+#define REG_OFFSET_NAME(r) \
+   {.name = #r, .offset = offsetof(struct pt_regs, ARM_##r)}


Can you not just use "offsetof(struct pt_regs, r)" here? That would be
the same as x86, powerpc.



The registers (except for pc, pstate, and sp) are not separate structure 
fields, they are slots in a single array. To reference them the symbolic 
name has to be converted to an index (integer register number) somehow.



+#define REG_OFFSET_END {.name = NULL, .offset = 0}
+
+static const struct pt_regs_offset regoffset_table[] = {
+   REG_OFFSET_NAME(x0),
+   REG_OFFSET_NAME(x1),
+   REG_OFFSET_NAME(x2),
+   REG_OFFSET_NAME(x3),
+   REG_OFFSET_NAME(x4),
+   REG_OFFSET_NAME(x5),
+   REG_OFFSET_NAME(x6),
+   REG_OFFSET_NAME(x7),
+   REG_OFFSET_NAME(x8),
+   REG_OFFSET_NAME(x9),
+   REG_OFFSET_NAME(x10),
+   REG_OFFSET_NAME(x11),
+   REG_OFFSET_NAME(x12),
+   REG_OFFSET_NAME(x13),
+   REG_OFFSET_NAME(x14),
+   REG_OFFSET_NAME(x15),
+   REG_OFFSET_NAME(ip0),
+   REG_OFFSET_NAME(ip1),
+   REG_OFFSET_NAME(x18),
+   REG_OFFSET_NAME(x19),
+   REG_OFFSET_NAME(x20),
+   REG_OFFSET_NAME(x21),
+   REG_OFFSET_NAME(x22),
+   REG_OFFSET_NAME(x23),
+   REG_OFFSET_NAME(x24),
+   REG_OFFSET_NAME(x25),
+   REG_OFFSET_NAME(x26),
+   REG_OFFSET_NAME(x27),
+   REG_OFFSET_NAME(x28),
+   REG_OFFSET_NAME(fp),
+   REG_OFFSET_NAME(lr),
+   REG_OFFSET_NAME(sp),
+   REG_OFFSET_NAME(pc),


and stick to x16, x17, x29, x30 instead of the ip0 etc.



OK.


+   REG_OFFSET_NAME(pstate),
+   REG_OFFSET_NAME(ORIG_x0),
+   REG_OFFSET_END,


Do we need orig_x0 of MAX_REG_OFFSET doesn't include it?



I think this should indeed be removed.


+};
+
+/**
+ * regs_query_register_offset() - query register offset from its name
+ * @name:  the name of a register
+ *
+ * regs_query_register_offset() returns the offset of a register in struct
+ * pt_regs from its name. If the name is invalid, this returns -EINVAL;
+ */
+int regs_query_register_offset(const char *name)
+{
+   const struct pt_regs_offset *roff;
+
+   for (roff = regoffset_table; roff->name != NULL; roff++)
+   if (!strcmp(roff->name, name))
+   return roff->offset;
+   return -EINVAL;
+}
+
+/**
+ * regs_query_register_name() - query register name from its o

Re: linux-next: manual merge of the samsung tree with the arm-soc andat91 trees

2015-05-20 Thread Kukjin Kim
On 05/21/15 10:20, Krzysztof Kozlowski wrote:
> 2015-05-20 18:47 GMT+09:00 Geert Uytterhoeven :
>> On Wed, May 20, 2015 at 11:16 AM, Alexandre Belloni
>>  wrote:
>>> On 20/05/2015 at 09:35:36 +0900, Krzysztof Kozlowski wrote :
 2015-05-20 9:27 GMT+09:00 Stephen Rothwell :
> Today's linux-next merge of the samsung tree got a conflict in
> arch/arm/configs/multi_v7_defconfig between various commits from the
> arm-soc and at91 trees and various commits from the samsung tree.
>
> I fixed it up (see below) and can carry the fix as necessary (no action
> is required).

 Hi,

 Thanks for the merge.

 The parts coming from samsung-soc related to manually toggling stuff
 (by me and Javier) look fine. The rest (coming from Kukjin's
 savedefconfig) I don't know - too much of them.

>>>
>>> Hum, last time I asked, we were not supposed to do a savedefconfig on
>>> multi_v7...
>>
>> Yeah, IMHO it's something the arm-soc maintainers should do only right
>> after rc1.
>>
>> Doing it at any other point in time may remove options that have just been
>> added to multi_v7_defconfig by an arm-soc submaintainer, and that depend on
>> a Kconfig change queued in another maintainer's for-next branch.
> 
> It also depends on which tree and branch the savedefconfig was
> performed. If on Linus' master then probably it is not a good idea at
> any time.
> 
>> Personally, I think no arm-soc submaintainer should touch multi_v7_defconfig,
>> and all changes should be applied by the arm-soc maintainers.
> 
> Actually Arnd suggested this:
> https://lkml.org/lkml/2015/5/15/303
> [PATCH 0/9] multi_v7_defconfig: Enable options for Exynos Chromebooks
> 
Thanks you guys.

I've sent a pull-request for the update of multi_v7_defconfig just now.
And IMHO need to keep it with savedefconfig from now on...

- Kukjin
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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   3   4   5   6   7   8   9   10   >