[PATCH 5/6] mtd: nand: gpmi: correct bitflip for erased NAND page

[Han Xu]

i.MX6QP and i.MX7D BCH module integrated a new feature to detect the
bitflip number for erased NAND page. So for these two platform, set the
erase threshold to gf/2 and if bitflip detected, GPMI driver will
correct the data to all 0xFF.

Signed-off-by: Han Xu 
---
 drivers/mtd/nand/gpmi-nand/bch-regs.h  | 10 ++
 drivers/mtd/nand/gpmi-nand/gpmi-lib.c  |  5 +
 drivers/mtd/nand/gpmi-nand/gpmi-nand.c | 24 +++-
 drivers/mtd/nand/gpmi-nand/gpmi-nand.h |  5 -
 4 files changed, 42 insertions(+), 2 deletions(-)

diff --git a/drivers/mtd/nand/gpmi-nand/bch-regs.h 
b/drivers/mtd/nand/gpmi-nand/bch-regs.h
index 53e58bc..a84d72b 100644
--- a/drivers/mtd/nand/gpmi-nand/bch-regs.h
+++ b/drivers/mtd/nand/gpmi-nand/bch-regs.h
@@ -30,7 +30,13 @@
 #define BM_BCH_CTRL_COMPLETE_IRQ   (1 << 0)
 
 #define HW_BCH_STATUS0 0x0010
+
 #define HW_BCH_MODE0x0020
+#define BP_BCH_MODE_ERASE_THRESHOLD0
+#define BM_BCH_MODE_ERASE_THRESHOLD(0xff << BP_BCH_MODE_ERASE_THRESHOLD)
+#define BF_BCH_MODE_ERASE_THRESHOLD(v) \
+   (((v) << BP_BCH_MODE_ERASE_THRESHOLD) & BM_BCH_MODE_ERASE_THRESHOLD)
+
 #define HW_BCH_ENCODEPTR   0x0030
 #define HW_BCH_DATAPTR 0x0040
 #define HW_BCH_METAPTR 0x0050
@@ -125,4 +131,8 @@
)
 
 #define HW_BCH_VERSION 0x0160
+#define HW_BCH_DEBUG1  0x0170
+#define BP_BCH_DEBUG1_ERASED_ZERO_COUNT0
+#define BM_BCH_DEBUG1_ERASED_ZERO_COUNT\
+   (0x1ff << BP_BCH_DEBUG1_ERASED_ZERO_COUNT)
 #endif
diff --git a/drivers/mtd/nand/gpmi-nand/gpmi-lib.c 
b/drivers/mtd/nand/gpmi-nand/gpmi-lib.c
index 6b37414..44433da 100644
--- a/drivers/mtd/nand/gpmi-nand/gpmi-lib.c
+++ b/drivers/mtd/nand/gpmi-nand/gpmi-lib.c
@@ -298,6 +298,11 @@ int bch_set_geometry(struct gpmi_nand_data *this)
| BF_BCH_FLASH0LAYOUT1_DATAN_SIZE(block_size, this),
r->bch_regs + HW_BCH_FLASH0LAYOUT1);
 
+   /* Set erase threshold to gf/2 for mx6qp and mx7 */
+   if (GPMI_IS_MX6QP(this) || GPMI_IS_MX7(this))
+   writel(BF_BCH_MODE_ERASE_THRESHOLD(gf_len/2),
+   r->bch_regs + HW_BCH_MODE);
+
/* Set *all* chip selects to use layout 0. */
writel(0, r->bch_regs + HW_BCH_LAYOUTSELECT);
 
diff --git a/drivers/mtd/nand/gpmi-nand/gpmi-nand.c 
b/drivers/mtd/nand/gpmi-nand/gpmi-nand.c
index 0462103..362cf4c 100644
--- a/drivers/mtd/nand/gpmi-nand/gpmi-nand.c
+++ b/drivers/mtd/nand/gpmi-nand/gpmi-nand.c
@@ -71,6 +71,12 @@ static const struct gpmi_devdata gpmi_devdata_imx6q = {
.max_chain_delay = 12,
 };
 
+static const struct gpmi_devdata gpmi_devdata_imx6qp = {
+   .type = IS_MX6QP,
+   .bch_max_ecc_strength = 40,
+   .max_chain_delay = 12,
+};
+
 static const struct gpmi_devdata gpmi_devdata_imx6sx = {
.type = IS_MX6SX,
.bch_max_ecc_strength = 62,
@@ -1010,6 +1016,7 @@ static int gpmi_ecc_read_page(struct mtd_info *mtd, 
struct nand_chip *chip,
 {
struct gpmi_nand_data *this = chip->priv;
struct bch_geometry *nfc_geo = &this->bch_geometry;
+   void __iomem *bch_regs = this->resources.bch_regs;
void  *payload_virt;
dma_addr_tpayload_phys;
void  *auxiliary_virt;
@@ -1018,6 +1025,7 @@ static int gpmi_ecc_read_page(struct mtd_info *mtd, 
struct nand_chip *chip,
unsigned char *status;
unsigned int  max_bitflips = 0;
int   ret;
+   int flag = 0;
 
dev_dbg(this->dev, "page number is : %d\n", page);
ret = read_page_prepare(this, buf, nfc_geo->payload_size,
@@ -1050,9 +1058,16 @@ static int gpmi_ecc_read_page(struct mtd_info *mtd, 
struct nand_chip *chip,
status = auxiliary_virt + nfc_geo->auxiliary_status_offset;
 
for (i = 0; i < nfc_geo->ecc_chunk_count; i++, status++) {
-   if ((*status == STATUS_GOOD) || (*status == STATUS_ERASED))
+   if (*status == STATUS_GOOD)
continue;
 
+   if (*status == STATUS_ERASED) {
+   if (GPMI_IS_MX6QP(this) || GPMI_IS_MX7(this))
+   if (readl(bch_regs + HW_BCH_DEBUG1))
+   flag = 1;
+   continue;
+   }
+
if (*status == STATUS_UNCORRECTABLE) {
mtd->ecc_stats.failed++;
continue;
@@ -1081,6 +1096,10 @@ static int gpmi_ecc_read_page(struct mtd_info *mtd, 
struct nand_chip *chip,
nfc_geo->payload_size,
payload_virt, payload_phys);
 
+   /* if bitflip occurred in erased page, change data to all 0xff */
+   if (flag)
+   memset(buf, 0xff, nfc_geo->payload_size);
+
return max

[PATCH 6/6] mtd: nand: gpmi: support NAND on i.MX6UL

[Han Xu]

support GPMI NAND on i.MX6UL

Signed-off-by: Han Xu 
---
 drivers/mtd/nand/gpmi-nand/gpmi-nand.c | 9 +
 drivers/mtd/nand/gpmi-nand/gpmi-nand.h | 6 --
 2 files changed, 13 insertions(+), 2 deletions(-)

diff --git a/drivers/mtd/nand/gpmi-nand/gpmi-nand.c 
b/drivers/mtd/nand/gpmi-nand/gpmi-nand.c
index 362cf4c..adadac2 100644
--- a/drivers/mtd/nand/gpmi-nand/gpmi-nand.c
+++ b/drivers/mtd/nand/gpmi-nand/gpmi-nand.c
@@ -89,6 +89,12 @@ static const struct gpmi_devdata gpmi_devdata_imx7d = {
.max_chain_delay = 12,
 };
 
+static const struct gpmi_devdata gpmi_devdata_imx6ul = {
+   .type = IS_MX6UL,
+   .bch_max_ecc_strength = 40,
+   .max_chain_delay = 12,
+};
+
 static irqreturn_t bch_irq(int irq, void *cookie)
 {
struct gpmi_nand_data *this = cookie;
@@ -2016,6 +2022,9 @@ static const struct of_device_id gpmi_nand_id_table[] = {
.compatible = "fsl,imx6sx-gpmi-nand",
.data = &gpmi_devdata_imx6sx,
}, {
+   .compatible = "fsl,imx6ul-gpmi-nand",
+   .data = (void *)&gpmi_devdata_imx6ul,
+   }, {
.compatible = "fsl,imx7d-gpmi-nand",
.data = (void *)&gpmi_devdata_imx7d,
}
diff --git a/drivers/mtd/nand/gpmi-nand/gpmi-nand.h 
b/drivers/mtd/nand/gpmi-nand/gpmi-nand.h
index 36ffeda..8428637 100644
--- a/drivers/mtd/nand/gpmi-nand/gpmi-nand.h
+++ b/drivers/mtd/nand/gpmi-nand/gpmi-nand.h
@@ -125,7 +125,8 @@ enum gpmi_type {
IS_MX6Q,
IS_MX6QP,
IS_MX6SX,
-   IS_MX7D
+   IS_MX7D,
+   IS_MX6UL
 };
 
 struct gpmi_devdata {
@@ -310,8 +311,9 @@ void gpmi_copy_bits(u8 *dst, size_t dst_bit_off,
 #define GPMI_IS_MX6QP(x)   ((x)->devdata->type == IS_MX6QP)
 #define GPMI_IS_MX6SX(x)   ((x)->devdata->type == IS_MX6SX)
 #define GPMI_IS_MX7D(x)((x)->devdata->type == IS_MX7D)
+#define GPMI_IS_MX6UL(x)   ((x)->devdata->type == IS_MX6UL)
 
 #define GPMI_IS_MX6(x) (GPMI_IS_MX6Q(x) || GPMI_IS_MX6QP(x)\
-  || GPMI_IS_MX6SX(x))
+  || GPMI_IS_MX6SX(x) || GPMI_IS_MX6UL(x))
 #define GPMI_IS_MX7(x) (GPMI_IS_MX7D(x))
 #endif
-- 
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/

Re: [PATCH 4/6] pci: altera: Add Altera PCIe MSI driver

[Marc Zyngier]

Hi Ley,

On 28/07/15 11:45, Ley Foon Tan wrote:
> This patch adds Altera PCIe MSI driver. This soft IP supports configurable
> number of vectors, which is a dts parameter.

Can't you read this configuration from the HW?

> 
> Signed-off-by: Ley Foon Tan 
> ---
>  drivers/pci/host/Kconfig   |   7 +
>  drivers/pci/host/Makefile  |   1 +
>  drivers/pci/host/pcie-altera-msi.c | 318 
> +
>  3 files changed, 326 insertions(+)
>  create mode 100644 drivers/pci/host/pcie-altera-msi.c
> 
> diff --git a/drivers/pci/host/Kconfig b/drivers/pci/host/Kconfig
> index af19039..a8b87fd 100644
> --- a/drivers/pci/host/Kconfig
> +++ b/drivers/pci/host/Kconfig
> @@ -154,4 +154,11 @@ config PCIE_ALTERA
> Say Y here if you want to enable PCIe controller support for Altera
> SoCFPGA family of SoCs.
>  
> +config PCIE_ALTERA_MSI
> + bool "Altera PCIe MSI feature"
> + depends on PCI_MSI && PCIE_ALTERA

What is the dependency with PCIE_ALTERA? Isn't that module standalone?

> + help
> +   Say Y here if you want PCIe MSI support for the Altera SocFPGA SoC.
> +   This MSI driver supports Altera MSI to GIC controller IP.
> +
>  endmenu
> diff --git a/drivers/pci/host/Makefile b/drivers/pci/host/Makefile
> index 6954f76..6c4913d 100644
> --- a/drivers/pci/host/Makefile
> +++ b/drivers/pci/host/Makefile
> @@ -18,3 +18,4 @@ obj-$(CONFIG_PCIE_IPROC) += pcie-iproc.o
>  obj-$(CONFIG_PCIE_IPROC_PLATFORM) += pcie-iproc-platform.o
>  obj-$(CONFIG_PCIE_IPROC_BCMA) += pcie-iproc-bcma.o
>  obj-$(CONFIG_PCIE_ALTERA) += pcie-altera.o
> +obj-$(CONFIG_PCIE_ALTERA_MSI) += pcie-altera-msi.o
> diff --git a/drivers/pci/host/pcie-altera-msi.c 
> b/drivers/pci/host/pcie-altera-msi.c
> new file mode 100644
> index 000..b852b51
> --- /dev/null
> +++ b/drivers/pci/host/pcie-altera-msi.c
> @@ -0,0 +1,318 @@
> +/*
> + * Copyright Altera Corporation (C) 2013-2015. All rights reserved
> + *
> + * 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 
> +#include 
> +#include 
> +
> +#define MSI_STATUS   0x0
> +#define MSI_ERROR0x4
> +#define MSI_INTMASK  0x8
> +
> +#define MAX_MSI_VECTORS  32
> +struct altera_msi {
> + DECLARE_BITMAP(used, MAX_MSI_VECTORS);
> + struct mutexlock;   /* proctect used variable */
> + struct platform_device  *pdev;
> + struct irq_domain   *msi_domain;
> + void __iomem*csr_base;
> + void __iomem*vector_base;
> + u32 vector_phy;

This should be a phys_addr_t. Not everything is 32bit.

> + u32 num_of_vectors;
> + int irq;
> +};
> +
> +static inline void msi_writel(struct altera_msi *msi, u32 value, u32 reg)
> +{
> + writel(value, msi->csr_base + reg);

You should be able to use the relaxed accessors.

> +}
> +
> +static inline u32 msi_readl(struct altera_msi *msi, u32 reg)
> +{
> + return readl(msi->csr_base + reg);

Same here.

> +}
> +
> +static irqreturn_t altera_msi_isr(int irq, void *data)
> +{
> + struct altera_msi *msi = data;
> + unsigned long status;
> + u32 num_of_vectors = msi->num_of_vectors;
> + u32 processed = 0;
> + u32 offset;
> +
> + do {
> + status = msi_readl(msi, MSI_STATUS);
> + if (!status)
> + break;
> +
> + do {
> + offset = find_first_bit(&status, num_of_vectors);
> + /* Dummy read from vector to clear the interrupt */
> + readl(msi->vector_base + (offset * sizeof(u32)));

readl_relaxed

> +
> + irq = irq_find_mapping(msi->msi_domain->parent, offset);

This would tend to indicate that you don't really need to store the
msi_domain pointer, but the inner_domain pointer instead.

> + if (irq) {
> + if (test_bit(offset, msi->used))
> + generic_handle_irq(irq);
> + else
> + dev_info(&msi->pdev->dev, "unhandled 
> MSI\n");
> + } else
> + dev_info(&msi->pdev->dev, "unexpected MSI\n");
> +
> + /* Clear the bit from statu

[PATCH v2 02/10] cgroup: introduce cgroup_subsys->legacy_name

[Tejun Heo]

This allows cgroup subsystems to use a different name on the unified
hierarchy.  cgroup_subsys->name is used on the unified hierarchy,
->legacy_name elsewhere.  If ->legacy_name is not explicitly set, it's
automatically set to ->name and the userland visible behavior remains
unchanged.

v2: Make parse_cgroupfs_options() only consider ->legacy_name as mount
options are used only on legacy hierarchies.  Suggested by Li
Zefan.

Signed-off-by: Tejun Heo 
Cc: Li Zefan 
Cc: Johannes Weiner 
Cc: cgro...@vger.kernel.org
---
git branch updated accordingly.  Thanks.

 include/linux/cgroup-defs.h |  3 +++
 kernel/cgroup.c | 29 ++---
 2 files changed, 21 insertions(+), 11 deletions(-)

diff --git a/include/linux/cgroup-defs.h b/include/linux/cgroup-defs.h
index 8f5770a..7d0bb53 100644
--- a/include/linux/cgroup-defs.h
+++ b/include/linux/cgroup-defs.h
@@ -434,6 +434,9 @@ struct cgroup_subsys {
int id;
const char *name;
 
+   /* optional, initialized automatically during boot if not set */
+   const char *legacy_name;
+
/* link to parent, protected by cgroup_lock() */
struct cgroup_root *root;
 
diff --git a/kernel/cgroup.c b/kernel/cgroup.c
index 6c85e6d..1276569 100644
--- a/kernel/cgroup.c
+++ b/kernel/cgroup.c
@@ -1027,10 +1027,13 @@ static const struct file_operations 
proc_cgroupstats_operations;
 static char *cgroup_file_name(struct cgroup *cgrp, const struct cftype *cft,
  char *buf)
 {
+   struct cgroup_subsys *ss = cft->ss;
+
if (cft->ss && !(cft->flags & CFTYPE_NO_PREFIX) &&
!(cgrp->root->flags & CGRP_ROOT_NOPREFIX))
snprintf(buf, CGROUP_FILE_NAME_MAX, "%s.%s",
-cft->ss->name, cft->name);
+cgroup_on_dfl(cgrp) ? ss->name : ss->legacy_name,
+cft->name);
else
strncpy(buf, cft->name, CGROUP_FILE_NAME_MAX);
return buf;
@@ -1335,7 +1338,7 @@ static int cgroup_show_options(struct seq_file *seq,
if (root != &cgrp_dfl_root)
for_each_subsys(ss, ssid)
if (root->subsys_mask & (1 << ssid))
-   seq_printf(seq, ",%s", ss->name);
+   seq_printf(seq, ",%s", ss->legacy_name);
if (root->flags & CGRP_ROOT_NOPREFIX)
seq_puts(seq, ",noprefix");
if (root->flags & CGRP_ROOT_XATTR)
@@ -1448,7 +1451,7 @@ static int parse_cgroupfs_options(char *data, struct 
cgroup_sb_opts *opts)
}
 
for_each_subsys(ss, i) {
-   if (strcmp(token, ss->name))
+   if (strcmp(token, ss->legacy_name))
continue;
if (ss->disabled)
continue;
@@ -4994,6 +4997,8 @@ int __init cgroup_init_early(void)
 
ss->id = i;
ss->name = cgroup_subsys_name[i];
+   if (!ss->legacy_name)
+   ss->legacy_name = cgroup_subsys_name[i];
 
if (ss->early_init)
cgroup_init_subsys(ss, true);
@@ -5141,7 +5146,7 @@ int proc_cgroup_show(struct seq_file *m, struct 
pid_namespace *ns,
for_each_subsys(ss, ssid)
if (root->subsys_mask & (1 << ssid))
seq_printf(m, "%s%s", count++ ? "," : 
"",
-  ss->name);
+  ss->legacy_name);
if (strlen(root->name))
seq_printf(m, "%sname=%s", count ? "," : "",
   root->name);
@@ -5181,7 +5186,7 @@ static int proc_cgroupstats_show(struct seq_file *m, void 
*v)
 
for_each_subsys(ss, i)
seq_printf(m, "%s\t%d\t%d\t%d\n",
-  ss->name, ss->root->hierarchy_id,
+  ss->legacy_name, ss->root->hierarchy_id,
   atomic_read(&ss->root->nr_cgrps), !ss->disabled);
 
mutex_unlock(&cgroup_mutex);
@@ -5403,12 +5408,14 @@ static int __init cgroup_disable(char *str)
continue;
 
for_each_subsys(ss, i) {
-   if (!strcmp(token, ss->name)) {
-   ss->disabled = 1;
-   printk(KERN_INFO "Disabling %s control group"
-   " subsystem\n", ss->name);
-   break;
-   }
+   if (strcmp(token, ss->name) &&
+   strcmp(token, ss->legacy_name))
+   continue;
+
+   ss->disabled = 1;
+   printk(KERN_INFO "Disabling %s control group 
subsystem\n",
+  ss->name);
+   

[PATCH 1/6] mtd: nand: gpmi: add gpmi dsm supend/resume support

[Han Xu]

From: Huang Shijie 

i.MX6SX supports deep sleep mode(DSM) that may turn off GPMI/BCH power
during suspend, add gpmi nand suspend/resume function to release DMA
channel in suspend function and re-init GPMI/BCH controller during
resume function.

Although it is not necessary to restore GPMI/BCH registers value for
i.MX6QDL, the code doesn't distinguish different platforms to keep the
code simple.

Signed-off-by: Huang Shijie 
Signed-off-by: Han Xu 
---
 drivers/mtd/nand/gpmi-nand/gpmi-nand.c | 45 +-
 1 file changed, 44 insertions(+), 1 deletion(-)

diff --git a/drivers/mtd/nand/gpmi-nand/gpmi-nand.c 
b/drivers/mtd/nand/gpmi-nand/gpmi-nand.c
index 1b8f350..dfd0ba1 100644
--- a/drivers/mtd/nand/gpmi-nand/gpmi-nand.c
+++ b/drivers/mtd/nand/gpmi-nand/gpmi-nand.c
@@ -1,7 +1,7 @@
 /*
  * Freescale GPMI NAND Flash Driver
  *
- * Copyright (C) 2010-2011 Freescale Semiconductor, Inc.
+ * Copyright (C) 2010-2015 Freescale Semiconductor, Inc.
  * Copyright (C) 2008 Embedded Alley Solutions, Inc.
  *
  * This program is free software; you can redistribute it and/or modify
@@ -2036,9 +2036,52 @@ static int gpmi_nand_remove(struct platform_device *pdev)
return 0;
 }
 
+static int gpmi_pm_suspend(struct device *dev)
+{
+   struct gpmi_nand_data *this = dev_get_drvdata(dev);
+
+   release_dma_channels(this);
+   return 0;
+}
+
+static int gpmi_pm_resume(struct device *dev)
+{
+   struct gpmi_nand_data *this = dev_get_drvdata(dev);
+   int ret;
+
+   ret = acquire_dma_channels(this);
+   if (ret < 0)
+   return ret;
+
+   /* re-init the GPMI registers */
+   this->flags &= ~GPMI_TIMING_INIT_OK;
+   ret = gpmi_init(this);
+   if (ret) {
+   dev_err(this->dev, "Error setting GPMI : %d\n", ret);
+   return ret;
+   }
+
+   /* re-init the BCH registers */
+   ret = bch_set_geometry(this);
+   if (ret) {
+   dev_err(this->dev, "Error setting BCH : %d\n", ret);
+   return ret;
+   }
+
+   /* re-init others */
+   gpmi_extra_init(this);
+
+   return 0;
+}
+
+static const struct dev_pm_ops gpmi_pm_ops = {
+   SET_SYSTEM_SLEEP_PM_OPS(gpmi_pm_suspend, gpmi_pm_resume)
+};
+
 static struct platform_driver gpmi_nand_driver = {
.driver = {
.name = "gpmi-nand",
+   .pm = &gpmi_pm_ops,
.of_match_table = gpmi_nand_id_table,
},
.probe   = gpmi_nand_probe,
-- 
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 1/1] iommu: Detach device from domain when removed from group

[Gerald Schaefer]

This patch adds a call to __iommu_detach_device() to the
iommu_group_remove_device() function, which will trigger a missing
detach_dev callback in (at least) the following scenario:

When a user completes the VFIO_SET_IOMMU ioctl for a vfio-pci device,
and the corresponding device is removed thereafter (before any other
ioctl like VFIO_GROUP_GET_DEVICE_FD), then the detach_dev callback of
the underlying IOMMU API is never called.

This also fixes an asymmetry with iommu_group_add_device() and
iommu_group_remove_device(), where the former did an "attach_dev" but
the latter did no "detach_dev".

Signed-off-by: Gerald Schaefer 
---
 drivers/iommu/iommu.c | 5 +
 1 file changed, 5 insertions(+)

diff --git a/drivers/iommu/iommu.c b/drivers/iommu/iommu.c
index f286090..82ac8b3 100644
--- a/drivers/iommu/iommu.c
+++ b/drivers/iommu/iommu.c
@@ -447,6 +447,9 @@ rename:
 }
 EXPORT_SYMBOL_GPL(iommu_group_add_device);
 
+static void __iommu_detach_device(struct iommu_domain *domain,
+ struct device *dev);
+
 /**
  * iommu_group_remove_device - remove a device from it's current group
  * @dev: device to be removed
@@ -466,6 +469,8 @@ void iommu_group_remove_device(struct device *dev)
 IOMMU_GROUP_NOTIFY_DEL_DEVICE, dev);
 
mutex_lock(&group->mutex);
+   if (group->domain)
+   __iommu_detach_device(group->domain, dev);
list_for_each_entry(tmp_device, &group->devices, list) {
if (tmp_device->dev == dev) {
device = tmp_device;
-- 
2.3.8

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] mtd: spi-nor: Bindings for Cadence Quad SPI Flash Controller driver.

[Marek Vasut]

On Tuesday, July 28, 2015 at 07:38:02 PM, Graham Moore wrote:

A commit message would be really nice :-)

> Signed-off-by: Graham Moore 
> ---
> V2: Add cdns prefix to driver-specific bindings.
> V3: Use existing property "is-decoded-cs" instead of creating a duplicate,
> "ext-decoder".  Timing parameters are in nanoseconds, not master reference
> clocks.  Remove bus-num completely.
> V4: Add new properties fifo-width and trigger-address
> ---
>  .../devicetree/bindings/mtd/cadence_quadspi.txt|   54
>  1 file changed, 54 insertions(+)
>  create mode 100644
> Documentation/devicetree/bindings/mtd/cadence_quadspi.txt
> 
> diff --git a/Documentation/devicetree/bindings/mtd/cadence_quadspi.txt
> b/Documentation/devicetree/bindings/mtd/cadence_quadspi.txt new file mode
> 100644
> index 000..d7e6fdd
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/mtd/cadence_quadspi.txt
> @@ -0,0 +1,54 @@
> +* Cadence Quad SPI controller
> +
> +Required properties:
> +- compatible : Should be "cdns,qspi-nor".
> +- reg : Contains two entries, each of which is a tuple consisting of a
> + physical address and length.  The first entry is the address and
> + length of the controller register set.  The second entry is the
> + address and length of the QSPI Controller data area.
> +- interrupts : Unit interrupt specifier for the controller interrupt.
> +- clocks : phandle to the Quad SPI clock.
> +- fifo-depth : Size of the data FIFO in words.

This and the following two are absolutelly Cadence specific, so prefix
them that way please:

cdns,fifo-depth

> +- fifo-width: Bus width of the data FIFO in bytes.

cdns,fifo-width

> +- trigger-address : 32-bit indirect AHB trigger address.

cdns,trigger-address

What is this address exactly? Is this documented somewhere what the value
should be precisely ?

[...]
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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 0/1] iommu: Detach device from domain when removed from group

[Gerald Schaefer]

Hi,

during IOMMU API function testing on s390 I hit the following scenario:

After binding a device to vfio-pci, the user completes the VFIO_SET_IOMMU
ioctl and stops, see the sample C program below. Now the device is manually
removed via "echo 1 > /sys/bus/pci/devices/.../remove".

Although the SET_IOMMU ioctl triggered the attach_dev callback in the
underlying IOMMU API, removing the device in this way won't trigger the
detach_dev callback, neither during remove nor when the user program
continues with closing group/container.

On s390, this eventually leads to a kernel panic when binding the device
again to its non-vfio PCI driver, because of the missing arch-specific
cleanup in detach_dev. On x86, the detach_dev callback will also not be
called directly, but there is a notifier that will catch
BUS_NOTIFY_REMOVED_DEVICE and eventually do the cleanup. Other
architectures w/o the notifier probably have at least some kind of memory
leak in this scenario, so a general fix would be nice.

My first approach was to try and fix this in VFIO code, but Alex Williamson
pointed me to some asymmetry in the IOMMU code: iommu_group_add_device()
will invoke the attach_dev callback, but iommu_group_remove_device() won't
trigger detach_dev. Fixing this asymmetry would fix the issue for me, but
is this the correct fix? Any thoughts?

Regards,
Gerald


Here is the sample C program to trigger the ioctl:

#include 
#include 
#include 

int main(void)
{
int container, group, rc;

container = open("/dev/vfio/vfio", O_RDWR);
if (container < 0) {
perror("open /dev/vfio/vfio\n");
return -1;
}

group = open("/dev/vfio/0", O_RDWR);
if (group < 0) {
perror("open /dev/vfio/0\n");
return -1;
}

rc = ioctl(group, VFIO_GROUP_SET_CONTAINER, &container);
if (rc) {
perror("ioctl VFIO_GROUP_SET_CONTAINER\n");
return -1;
}

rc = ioctl(container, VFIO_SET_IOMMU, VFIO_TYPE1_IOMMU);
if (rc) {
perror("ioctl VFIO_SET_IOMMU\n");
return -1;
}

printf("Try device remove...\n");
getchar();

close(group);
close(container);
return 0;
}

Gerald Schaefer (1):
  iommu: Detach device from domain when removed from group

 drivers/iommu/iommu.c | 5 +
 1 file changed, 5 insertions(+)

-- 
2.3.8

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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: Revised futex(2) man page for review

[Davidlohr Bueso]

On Tue, 2015-07-28 at 09:44 +0200, Michael Kerrisk (man-pages) wrote:
> Maybe you still have some further improvements for the paragraph?

Nah, this is fine enough. Looks good.

Thanks,
Davidlohr

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

Re: [PATCH 0/2 RESEND] power: reset: Add syscon reboot/poweroff device nodes for APM X-Gene platform

[Duc Dang]

On Sun, Jul 26, 2015 at 11:37 AM, Olof Johansson  wrote:
> On Sat, Jul 25, 2015 at 11:34:42AM -0700, Duc Dang wrote:
>> Hi Olof,
>>
>> We are debating whether we should setup a company server (where we can
>> have full control about storage, user permissions, backup, ...) or
>> just use github.com to host our X-Gene kernel tree.
>>
>> Github seems already provide everything we need for a public source
>> tree. Per your experience, what is your (and probably other
>> maintainers) reference in git hosting server? Is there any
>> inconvenience or difficulty for the maintainers to pull/merge code
>> from Github versus from a company server?
>
> Hosting on github is fine with us in general. We do prefer to get
> signed pull requests in particular when they come from other sources
> than kernel.org, mostly because there's another third party involved in
> hosting the repo and by using signed tags there's less room for anyone
> to do bad stuff with the repository without someone noticing.
>
> If you host on github, please still use native git pull requests and not the
> ones that github provides via the web interface.
>
> Note however, that given the total volume of patches there's no strong need 
> for
> you to have a public repo just to send code to us -- we're happy applying
> patches at the volumes we're currently looking at. I can imagine other reasons
> for why you would like to have a public repo though.
>

Thanks for the information, Olof.

We are setting up a public repo on Github. I will make sure that
native git pull request is used.

I will need your help in signing the PGP key when the repo is ready.

>
> Thanks,
>
> -Olof

-- 
Regards,
Duc Dang.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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 v1 7/7] ARM: dts: ifc6410: add inforce LVDS panel support

[Andreas Färber]

Am 28.07.2015 um 14:54 schrieb Srinivas Kandagatla:
> This patch adds LVDS panel for IFC6410.
> 
> Signed-off-by: Rob Clark 
> [Rob Clark: WIP patch]
> Signed-off-by: Srinivas Kandagatla 
> ---
>  arch/arm/boot/dts/qcom-apq8064-ifc6410.dts | 66 
> ++
>  1 file changed, 66 insertions(+)
> 
> diff --git a/arch/arm/boot/dts/qcom-apq8064-ifc6410.dts 
> b/arch/arm/boot/dts/qcom-apq8064-ifc6410.dts
> index 1ab71f1..3bdac02 100644
> --- a/arch/arm/boot/dts/qcom-apq8064-ifc6410.dts
> +++ b/arch/arm/boot/dts/qcom-apq8064-ifc6410.dts
> @@ -63,6 +63,12 @@
>   qcom,switch-mode-frequency = <320>;
>   };
>  
> + pm8921_l2: l2 {
> + regulator-min-microvolt = <120>;
> + regulator-max-microvolt = <120>;
> + bias-pull-down;
> + };
> +
>   pm8921_l3: l3 {
>   regulator-min-microvolt = <305>;
>   regulator-max-microvolt = <330>;
> @@ -96,6 +102,10 @@
>   pm8921_lvs1: lvs1 {
>   bias-pull-down;
>   };
> +
> + pm8921_lvs7: lvs7 {
> + bias-pull-down;
> + };
>   };
>   };
>  
> @@ -119,6 +129,41 @@
>  
>   mdp: qcom,mdp@510 {
>   status = "okay";
> + qcom,lvds-panel = <&panel>;

In my testing this broke/uglified HDMI output. Since not everyone has
that LVDS panel attached, or might have a different panel type, I don't
think the panel node belongs in the generic -ifc6410.dts file.
I suggest you add an -ifc6410+inforce-lvds.dts or so for that.

> + lvds-vccs-3p3v-supply = <&ext_3p3v>;
> + lvds-pll-vdda-supply = <&pm8921_l2>;
> + lvds-vdda-supply = <&pm8921_lvs7>;
> + };
> +
> + panel_3p3v: panel_3p3v {

s/_/-/ ?

> + compatible = "regulator-fixed";
> + pinctrl-0 = <&disp_en_gpios>;
> + pinctrl-names = "default";
> + regulator-min-microvolt = <330>;
> + regulator-max-microvolt = <330>;
> + regulator-name = "panel_en_3p3v";
> + regulator-type = "voltage";
> + startup-delay-us = <0>;
> + gpio = <&pm8921_gpio 36 GPIO_ACTIVE_HIGH>;
> + enable-active-high;
> + regulator-boot-on;
> + };
> +
> + backlight: backlight{
> + pinctrl-0 = <&pwm_bl_gpios>;
> + pinctrl-names = "default";
> + compatible = "gpio-backlight";
> + gpios = <&pm8921_gpio 26 GPIO_ACTIVE_HIGH>;
> + default-on;
> + };
> +
> + panel: auo,b101xtn01 {

panel: panel { ?

Regards,
Andreas

> + status = "okay";
> + compatible = "auo,b101xtn01";
> +
> + ddc-i2c-bus = <&i2c3>;
> + backlight = <&backlight>;
> + power-supply = <&panel_3p3v>;
>   };
>  
>   gsbi3: gsbi@1620 {
> @@ -235,6 +280,27 @@
>   pm8921_gpio: gpio@150 {
>   pinctrl-names = "default";
>   pinctrl-0 = <&wlan_default_gpios>;
> +
> + pwm_bl_gpios: pwm-bl-gpios {
> + pios {
> + pins = "gpio26";
> + bias-disable;
> + function = "normal";
> + qcom,drive-strength = 
> ;
> + power-source = 
> ;
> + };
> + };
> +
> + disp_en_gpios: disp-en-gpios {
> + pios {
> + pins = "gpio36";
> + bias-disable;
> + function = "normal";
> + qcom,drive-strength = 
> ;
> + power-source = 
> ;
> + };
> + };

Re: [PATCH V3 RESEND 8/8] staging: rtl8712: change SupportedRates to rates

[Joshua Clayton]

On Tuesday, July 28, 2015 06:56:38 PM Dan Carpenter wrote:
> On Tue, Jul 28, 2015 at 08:50:04AM -0700, Joshua Clayton wrote:
> > On Tuesday, July 28, 2015 05:37:16 PM Julia Lawall wrote:
> > > > diff --git a/drivers/staging/rtl8712/rtl871x_ioctl_linux.c 
> > > > b/drivers/staging/rtl8712/rtl871x_ioctl_linux.c
> > > > index 83d4bca..1ded691 100644
> > > > --- a/drivers/staging/rtl8712/rtl871x_ioctl_linux.c
> > > > +++ b/drivers/staging/rtl8712/rtl871x_ioctl_linux.c
> > > > @@ -204,13 +204,13 @@ static inline char *translate_scan(struct 
> > > > _adapter *padapter,
> > > > /* Add the protocol name */
> > > > iwe.cmd = SIOCGIWNAME;
> > > > if ((r8712_is_cckratesonly_included(pnetwork->network.
> > > > -SupportedRates)) == true) {
> > > > +rates)) == true) {
> > > > if (ht_cap == true)
> > > > snprintf(iwe.u.name, IFNAMSIZ, "IEEE 802.11bn");
> > > > else
> > > > snprintf(iwe.u.name, IFNAMSIZ, "IEEE 802.11b");
> > > > } else if ((r8712_is_cckrates_included(pnetwork->network.
> > > > -   SupportedRates)) == true) {
> > > > +   rates)) == true) {
> > > > if (ht_cap == true)
> > > > snprintf(iwe.u.name, IFNAMSIZ, "IEEE 
> > > > 802.11bgn");
> > > > else
> > > 
> > > The placement of the line breaks here is partucularly unpleasant.  Perhaps
> > > that could be adjusted now that the field name is shorter.  Theer may be
> > > some other cases in the patch where the line breaks could be adjusted to
> > > improve readability.
> > > 
> > > julia
> > I agree. Dan Carpenter earlier complained about me fixing up the lines
> > while changing the variable name. Should that be a separate patch?
> > 
> 
> Changing the line breaks here is a tiny change on the same line and so
> it's fine.  It fits into the one thing per patch rule.

This is the style I prefer (getting rid of the explicit == true)

-   if ((r8712_is_cckratesonly_included(pnetwork->network.
-SupportedRates)) == true) {
+   if (r8712_is_cckratesonly_included(pnetwork->network.rates)) {
if (ht_cap == true)
snprintf(iwe.u.name, IFNAMSIZ, "IEEE 802.11bn");
else
snprintf(iwe.u.name, IFNAMSIZ, "IEEE 802.11b");
-   } else if ((r8712_is_cckrates_included(pnetwork->network.
-   SupportedRates)) == true) {
+   } else if (r8712_is_cckrates_included(pnetwork->network.rates)) {
if (ht_cap == true)
snprintf(iwe.u.name, IFNAMSIZ, "IEEE 802.11bgn");

Does that look ok?
If we keep the "== true" and the extra set of parentheses, the "else if" case 
goes over 80 lines.
I will happily submit the change as follow up patch if that is too much to 
change at once. 
> 
> regards,
> dan carpenter
> 

-- 
~Joshua Clayton
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] of/irq: introduce of_has_named_irqs helper

[R, Vignesh]

Hi,

On 7/28/2015 10:53 PM, Dmitry Torokhov wrote:
> On Tue, Jul 28, 2015 at 06:53:52PM +0530, Vignesh R wrote:
>> Hi Dmitry,
>>
>> On 07/25/2015 01:46 AM, Dmitry Torokhov wrote:
>>> On Fri, Jul 24, 2015 at 12:26:19PM -0700, Dmitry Torokhov wrote:
 On Fri, Jul 24, 2015 at 02:14:57PM -0500, Rob Herring wrote:
> On Fri, Jul 24, 2015 at 1:26 PM, Dmitry Torokhov
>  wrote:
>> Sometimes drivers might wish to transition from index-based to named
>> interrupt descriptions. To aid in decision-making when parsing device
>> tree data let's provide a helper that will indicate the scheme that is
>> being used.
>
> Generally, IRQs are retrieved by platform_get_irq or
> platform_get_irq_byname. Drivers should not call the of_irq_*
> functions directly in most cases.

 That would be true for platform drivers, but not all devices are
 platform devices.

>
>>
>> Signed-off-by: Dmitry Torokhov 
>> ---
>>
>> The intent is to it like this:
>>
>> if (of_has_named_irqs(np) {
>> /* Wake IRQ is optional */
>> dev->wakeirq = of_irq_get_byname(np, "wakeup");
>> if (dev->wakeirq < 0 && dev->wakeirq != -ENODATA)
>> return dev->wakeirq;
>> }
>
> of_irq_get_byname will already return an error if the property is not
> present. Use that.

 I do not like that it returns -EINVAL when property is missing, can we
 change it to return -ENODATA (so it is the same as when the property is
 defined but such name is missing)?
>>>
>>> So here is what I had in mind.. It is based on recent patch by Vignesh
>>> for pixcir touchscreen, but I think it should be made available to all
>>> I2C devices. Completely untested at the moment.
>>>
>>
>> Thanks for the patch! I tested this on am437x-gp-evm and the
>> suspend/resume worked fine (below patch + $subject patch). I was able to
>> wake the system from low power state using touchscreen. Also verified
>> module insertion and removal. One comment though, please see below.
>>
>>> ---
>>>  drivers/i2c/i2c-core.c |   43 +--
>>>  1 file changed, 37 insertions(+), 6 deletions(-)
>>>
>>> diff --git a/drivers/i2c/i2c-core.c b/drivers/i2c/i2c-core.c
>>> index e6d4935..3971461 100644
>>> --- a/drivers/i2c/i2c-core.c
>>> +++ b/drivers/i2c/i2c-core.c
>>> @@ -47,6 +47,7 @@
>>>  #include 
>>>  #include 
>>>  #include 
>>> +#include 
>>>  #include 
>>>  #include 
>>>  #include 
>>> @@ -631,6 +632,7 @@ static int i2c_device_probe(struct device *dev)
>>>  {
>>> struct i2c_client   *client = i2c_verify_client(dev);
>>> struct i2c_driver   *driver;
>>> +   int wakeirq = 0;
>>> int status;
>>>  
>>> if (!client)
>>> @@ -639,11 +641,13 @@ static int i2c_device_probe(struct device *dev)
>>> if (!client->irq) {
>>> int irq = -ENOENT;
>>>  
>>> -   if (dev->of_node)
>>> -   irq = of_irq_get(dev->of_node, 0);
>>> -   else if (ACPI_COMPANION(dev))
>>> +   if (dev->of_node) {
>>> +   irq = of_has_named_irqs(dev->of_node) ?
>>> +   of_irq_get_byname(dev->of_node, "irq") :
>>> +   of_irq_get(dev->of_node, 0);
>>> +   } else if (ACPI_COMPANION(dev)) {
>>> irq = acpi_dev_gpio_irq_get(ACPI_COMPANION(dev), 0);
>>> -
>>> +   }
>>> if (irq == -EPROBE_DEFER)
>>> return irq;
>>> if (irq < 0)
>>> @@ -652,6 +656,15 @@ static int i2c_device_probe(struct device *dev)
>>> client->irq = irq;
>>> }
>>>  
>>> +   if (dev->of_node && of_has_named_irqs(dev->of_node)) {
>>> +   wakeirq = of_irq_get_byname(dev->of_node, "wakeup");
>>> +   if (wakeirq < 0) {
>>> +   if (wakeirq != -ENODATA)
>>> +   return wakeirq;
>>> +   wakeirq = 0;
>>> +   }
>>> +   }
>>> +
>>> driver = to_i2c_driver(dev->driver);
>>> if (!driver->probe || !driver->id_table)
>>> return -ENODEV;diff --git 
>>> a/drivers/input/touchscreen/pixcir_i2c_ts.c 
>>> b/drivers/input/touchscreen/pixcir_i2c_ts.c
index 8f3e243a62bf..6bd1d1ca9883 100644
--- a/drivers/input/touchscreen/pixcir_i2c_ts.c
+++ b/drivers/input/touchscreen/pixcir_i2c_ts.c
@@ -365,7 +365,6 @@ static int __maybe_unused
pixcir_i2c_ts_suspend(struct device *dev)
}
}

-   enable_irq_wake(client->irq);
} else if (input->users) {
ret = pixcir_stop(ts);
}
@@ -386,7 +385,6 @@ static int __maybe_unused
pixcir_i2c_ts_resume(struct device *dev)
mutex_lock(&input->mutex);

if (device_may_wakeup(&client->dev)) {
-   disable_irq_wake(client->irq);

if (!input->users) {
ret = pixcir_stop(ts);
@

Re: X-Gene: Unhandled fault: synchronous external abort in pci_generic_config_read32

[Duc Dang]

On Tue, Jul 28, 2015 at 9:43 AM, Bjorn Helgaas  wrote:
> On Fri, Jul 24, 2015 at 7:05 PM, Duc Dang  wrote:
>> Hi Bjorn,
>>
>> On Fri, Jul 24, 2015 at 3:42 PM, Bjorn Helgaas  wrote:
>>>
>>> I regularly see faults like this on an APM X-Gene:
>>>
>>>   U-Boot 2013.04-mustang_sw_1.14.14 (Dec 16 2014 - 15:59:33)
>>>   CPU0: APM ARM 64-bit Potenza Rev B0 2400MHz PCP 2400MHz
>>>32 KB ICACHE, 32 KB DCACHE
>>>SOC 2000MHz IOBAXI 400MHz AXI 250MHz AHB 200MHz GFC 125MHz
>>>   ...
>>>   Unhandled fault: synchronous external abort (0x9610) at 
>>> 0xff8000110034
>>>   Internal error: : 9610 [#1] SMP
>>>   Modules linked in:
>>>   CPU: 0 PID: 3723 Comm: ... 4.1.0-smp-DEV #3
>>>   Hardware name: APM X-Gene Mustang board (DT)
>>>   task: ffc7dc1a4140 ti: ffc7dc118000 task.ti: ffc7dc118000
>>>   PC is at pci_generic_config_read32+0x4c/0xb8
>>>   LR is at pci_generic_config_read32+0x40/0xb8
>>>   pc : [] lr : [] pstate: 61c5
>>>   ...
>>>   Call trace:
>>>   [] pci_generic_config_read32+0x4c/0xb8
>>>   [] pci_user_read_config_byte+0x60/0xc4
>>>   [] pci_read_config+0x15c/0x238
>>>   [] sysfs_kf_bin_read+0x68/0xa0
>>>   [] kernfs_fop_read+0x9c/0x1ac
>>>   [] __vfs_read+0x44/0x128
>>>   [] vfs_read+0x84/0x144
>>>   [] SyS_read+0x50/0xb0
>>
>> The log shows kernel gets an exception when trying to access Mellanox
>> card configuration space. This is usually due to suboptimal PCIe
>> SerDes parameters are using in your board, which will cause bad link
>> quality.
>> The PCIe SerDes programming is done in U-Boot, so I suggest you do a
>> U-Boot upgrade to our latest X-Gene U-Boot release.
>
> I installed U-Boot 1.15.12, which I thought was the latest.  I'm still
> seeing this issue regularly, approx once/hour.

Our latest U-Boot is 1.15.15, but U-Boot 1.15.12 is already a good
version to use. Are you running any PCIe traffic test when the error
happens? I will try to reproduce the issue with my Mustang board as
well.

And it will be useful if you can share your "lspci -vvv" output when
the board is running, we can check to see if there is any error status
reported.

-- 
Regards,
Duc Dang.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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 1/2] mtd: spi-nor: Bindings for Cadence Quad SPI Flash Controller driver.

[Graham Moore]

Signed-off-by: Graham Moore 
---
V2: Add cdns prefix to driver-specific bindings.
V3: Use existing property "is-decoded-cs" instead of creating a duplicate,
"ext-decoder".  Timing parameters are in nanoseconds, not master reference
clocks.  Remove bus-num completely.
V4: Add new properties fifo-width and trigger-address
---
 .../devicetree/bindings/mtd/cadence_quadspi.txt|   54 
 1 file changed, 54 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/mtd/cadence_quadspi.txt

diff --git a/Documentation/devicetree/bindings/mtd/cadence_quadspi.txt 
b/Documentation/devicetree/bindings/mtd/cadence_quadspi.txt
new file mode 100644
index 000..d7e6fdd
--- /dev/null
+++ b/Documentation/devicetree/bindings/mtd/cadence_quadspi.txt
@@ -0,0 +1,54 @@
+* Cadence Quad SPI controller
+
+Required properties:
+- compatible : Should be "cdns,qspi-nor".
+- reg : Contains two entries, each of which is a tuple consisting of a
+   physical address and length.  The first entry is the address and
+   length of the controller register set.  The second entry is the
+   address and length of the QSPI Controller data area.
+- interrupts : Unit interrupt specifier for the controller interrupt.
+- clocks : phandle to the Quad SPI clock.
+- fifo-depth : Size of the data FIFO in words.
+- fifo-width: Bus width of the data FIFO in bytes.
+- trigger-address : 32-bit indirect AHB trigger address.
+
+Optional properties:
+- is-decoded-cs : Flag to indicate whether decoder is used or not.
+
+Optional subnodes:
+Subnodes of the Cadence Quad SPI controller are spi slave nodes with additional
+custom properties:
+- cdns,page-size : Size, in bytes, of the device's write page
+- cdns,block-size : Size of the device's erase block
+- cdns,read-delay : Delay for read capture logic, in clock cycles
+- cdns,tshsl-ns : Delay in nanoseconds for the length that the master mode 
chip select outputs are de-asserted between transactions.
+- cdns,tsd2d-ns : Delay in nanoseconds between one chip select being 
de-activated and the activation of another.
+- cdns,tchsh-ns : Delay in nanoseconds between last bit of current transaction 
and deasserting the device chip select (qspi_n_ss_out).
+- cdns,tslch-ns : Delay in nanoseconds between setting qspi_n_ss_out low and 
first bit transfer.
+
+Example:
+
+   qspi: spi@ff705000 {
+   compatible = "cdns,qspi-nor";
+   #address-cells = <1>;
+   #size-cells = <0>;
+   reg = <0xff705000 0x1000>,
+   <0xffa0 0x1000>;
+   interrupts = <0 151 4>;
+   clocks = <&qspi_clk>;
+   is-decoded-cs = <1>;
+   fifo-depth = <128>;
+   fifo-width = <4>;
+   trigger-address = <0x>;
+
+   flash0: n25q00@0 {
+   ...
+   cdns,page-size = <256>;
+   cdns,block-size = <16>;
+   cdns,read-delay = <4>;
+   cdns,tshsl-ns = <50>;
+   cdns,tsd2d-ns = <50>;
+   cdns,tchsh-ns = <4>;
+   cdns,tslch-ns = <4>;
+   }
+   }
-- 
1.7.9.5

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

[PATCH V6 2/2] mtd: spi-nor: Add driver for Cadence Quad SPI Flash Controller.

[Graham Moore]

Signed-off-by: Graham Moore 
---
V2: use NULL instead of modalias in spi_nor_scan call
V3: Use existing property is-decoded-cs instead of creating duplicate.
V4: Support Micron quad mode by snooping command stream for EVCR command
and subsequently configuring Cadence controller for quad mode.
V5: Clean up sparse and smatch complaints.  Remove snooping of Micron
quad mode.  Add comment on XIP mode bit and dummy clock cycles.  Set
up SRAM partition at 1:1 during init.
V6: Remove dts patch that was included by mistake.  Incorporate Vikas's
comments regarding fifo width, SRAM partition setting, and trigger
address.  Trigger address was added as an unsigned int, as it is not
an IO resource per se, and does not need to be mapped. Also add
Marek Vasut's workaround for picking up OF properties on subnodes.
---
 drivers/mtd/spi-nor/Kconfig   |6 +
 drivers/mtd/spi-nor/Makefile  |1 +
 drivers/mtd/spi-nor/cadence-quadspi.c | 1276 +
 3 files changed, 1283 insertions(+)
 create mode 100644 drivers/mtd/spi-nor/cadence-quadspi.c

diff --git a/drivers/mtd/spi-nor/Kconfig b/drivers/mtd/spi-nor/Kconfig
index 64a4f0e..9485481 100644
--- a/drivers/mtd/spi-nor/Kconfig
+++ b/drivers/mtd/spi-nor/Kconfig
@@ -28,4 +28,10 @@ config SPI_FSL_QUADSPI
  This enables support for the Quad SPI controller in master mode.
  We only connect the NOR to this controller now.
 
+config SPI_CADENCE_QUADSPI
+   tristate "Cadence Quad SPI controller"
+   depends on ARCH_SOCFPGA
+   help
+ This enables support for the Cadence Quad SPI controller and NOR 
flash.
+
 endif # MTD_SPI_NOR
diff --git a/drivers/mtd/spi-nor/Makefile b/drivers/mtd/spi-nor/Makefile
index 6a7ce14..372628c 100644
--- a/drivers/mtd/spi-nor/Makefile
+++ b/drivers/mtd/spi-nor/Makefile
@@ -1,2 +1,3 @@
 obj-$(CONFIG_MTD_SPI_NOR)  += spi-nor.o
+obj-$(CONFIG_SPI_CADENCE_QUADSPI)  += cadence-quadspi.o
 obj-$(CONFIG_SPI_FSL_QUADSPI)  += fsl-quadspi.o
diff --git a/drivers/mtd/spi-nor/cadence-quadspi.c 
b/drivers/mtd/spi-nor/cadence-quadspi.c
new file mode 100644
index 000..076e9c9
--- /dev/null
+++ b/drivers/mtd/spi-nor/cadence-quadspi.c
@@ -0,0 +1,1276 @@
+/*
+ * Driver for Cadence QSPI Controller
+ *
+ * Copyright Altera Corporation (C) 2012-2014. All rights reserved.
+ *
+ * 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 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#define CQSPI_NAME "cadence-qspi"
+#define CQSPI_MAX_CHIPSELECT   16
+
+struct cqspi_flash_pdata {
+   struct mtd_info mtd;
+   struct spi_nor nor;
+   u32 clk_rate;
+   unsigned int read_delay;
+   unsigned int tshsl_ns;
+   unsigned int tsd2d_ns;
+   unsigned int tchsh_ns;
+   unsigned int tslch_ns;
+};
+
+struct cqspi_st {
+   struct platform_device *pdev;
+
+   struct clk *clk;
+   unsigned int sclk;
+
+   void __iomem *iobase;
+   void __iomem *ahb_base;
+   struct completion transfer_complete;
+   unsigned int irq_mask;
+   int current_cs;
+   unsigned int ahb_phy_addr;
+   unsigned int master_ref_clk_hz;
+   u32 is_decoded_cs;
+   unsigned int fifo_depth;
+   unsigned int fifo_width;
+   unsigned int trigger_address;
+   struct cqspi_flash_pdata f_pdata[CQSPI_MAX_CHIPSELECT];
+};
+
+/* Operation timeout value */
+#define CQSPI_TIMEOUT_MS   500
+#define CQSPI_READ_TIMEOUT_MS  10
+#define CQSPI_POLL_IDLE_RETRY  3
+
+#define CQSPI_REG_SRAM_RESV_WORDS  2
+#define CQSPI_REG_SRAM_PARTITION_WR1
+#define CQSPI_REG_SRAM_THRESHOLD_BYTES 50
+
+/* Instruction type */
+#define CQSPI_INST_TYPE_SINGLE 0
+#define CQSPI_INST_TYPE_DUAL   1
+#define CQSPI_INST_TYPE_QUAD   2
+
+#define CQSPI_DUMMY_CLKS_MAX   31
+
+#define CQSPI_STIG_DATA_LEN_MAX8
+
+/* Register map */
+#define CQSPI_REG_CONFIG   0x00
+#define CQSPI_REG_CONFIG_ENABLE_MASK   BIT(0)
+#define CQSPI_REG_CONFIG_DECODE_MASK   BIT(9)
+#define CQSPI_REG_CONFIG_CHIPSELECT_LSB10
+#define CQSPI_REG_CONFIG_DMA_MASK  BIT(1

Re: [RFC PATCH 14/14] kthread_worker: Add set_kthread_worker_scheduler*()

[Tejun Heo]

On Tue, Jul 28, 2015 at 04:39:31PM +0200, Petr Mladek wrote:
> +/**
> + * set_kthread_worker_scheduler - change the scheduling policy and/or RT
> + *   priority of a kthread worker.
> + * @worker: target kthread_worker
> + * @policy: new policy
> + * @sched_priority: new RT priority
> + *
> + * Return: 0 on success. An error code otherwise.
> + */
> +int set_kthread_worker_scheduler(struct kthread_worker *worker,
> +  int policy, int sched_priority)
> +{
> + return __set_kthread_worker_scheduler(worker, policy, sched_priority,
> +   true);
> +}

Ditto.  I don't get why we would want these thin wrappers.

Thanks.

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

Re: [RFC PATCH 08/14] rcu: Convert RCU gp kthreads into kthread worker API

[Tejun Heo]

On Tue, Jul 28, 2015 at 04:39:25PM +0200, Petr Mladek wrote:
...
> -static int __noreturn rcu_gp_kthread(void *arg)
> +static void rcu_gp_kthread_func(struct kthread_work *work)
>  {
>   int fqs_state;
>   int gf;
>   unsigned long j;
>   int ret;
> - struct rcu_state *rsp = arg;
> + struct rcu_state *rsp = container_of(work, struct rcu_state, gp_work);
>   struct rcu_node *rnp = rcu_get_root(rsp);
>  
> - rcu_bind_gp_kthread();
> + /* Handle grace-period start. */
>   for (;;) {
> + trace_rcu_grace_period(rsp->name,
> +READ_ONCE(rsp->gpnum),
> +TPS("reqwait"));
> + rsp->gp_state = RCU_GP_WAIT_GPS;
> + wait_event_interruptible(rsp->gp_wq,
> +  READ_ONCE(rsp->gp_flags) &
> +  RCU_GP_FLAG_INIT);

Same here.  Why not convert the waker into a queueing event?

> + /* Locking provides needed memory barrier. */
> + if (rcu_gp_init(rsp))
> + break;
> + cond_resched_rcu_qs();
> + WRITE_ONCE(rsp->gp_activity, jiffies);
> + WARN_ON(signal_pending(current));
> + trace_rcu_grace_period(rsp->name,
> +READ_ONCE(rsp->gpnum),
> +TPS("reqwaitsig"));
> + }

Thanks.

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

Re: [RFC PATCH 13/14] kthread_worker: Add set_kthread_worker_user_nice()

[Tejun Heo]

On Tue, Jul 28, 2015 at 04:39:30PM +0200, Petr Mladek wrote:
...
> +/*
> + * set_kthread_worker_user_nice - set scheduling priority for the kthread 
> worker
> + * @worker: target kthread_worker
> + * @nice: niceness value
> + */
> +void set_kthread_worker_user_nice(struct kthread_worker *worker, long nice)
> +{
> + struct task_struct *task = worker->task;
> +
> + WARN_ON(!task);
> + set_user_nice(task, nice);
> +}
> +EXPORT_SYMBOL(set_kthread_worker_user_nice);

kthread_worker is explcitly associated with a single kthread.  Why do
we want to create explicit wrappers for kthread operations?  This is
encapsulation for encapsulation's sake.  It doesn't buy us anything at
all.  Just let the user access the associated kthread and operate on
it.

Thanks.

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

Re: X-Gene: Unhandled fault: synchronous external abort in pci_generic_config_read32

[Duc Dang]

On Mon, Jul 27, 2015 at 4:36 AM, Catalin Marinas
 wrote:
> On Fri, Jul 24, 2015 at 05:05:19PM -0700, Duc Dang wrote:
>> On Fri, Jul 24, 2015 at 3:42 PM, Bjorn Helgaas  wrote:
>> > I regularly see faults like this on an APM X-Gene:
>> >
>> >   U-Boot 2013.04-mustang_sw_1.14.14 (Dec 16 2014 - 15:59:33)
>> >   CPU0: APM ARM 64-bit Potenza Rev B0 2400MHz PCP 2400MHz
>> >32 KB ICACHE, 32 KB DCACHE
>> >SOC 2000MHz IOBAXI 400MHz AXI 250MHz AHB 200MHz GFC 125MHz
>> >   ...
>> >   Unhandled fault: synchronous external abort (0x9610) at 
>> > 0xff8000110034
>
> That's generated by an external device (PCIe root complex, card etc.)
> and some mis-configured CPU setting.
>
>> >   Internal error: : 9610 [#1] SMP
>> >   Modules linked in:
>> >   CPU: 0 PID: 3723 Comm: ... 4.1.0-smp-DEV #3
>> >   Hardware name: APM X-Gene Mustang board (DT)
>> >   task: ffc7dc1a4140 ti: ffc7dc118000 task.ti: ffc7dc118000
>> >   PC is at pci_generic_config_read32+0x4c/0xb8
>> >   LR is at pci_generic_config_read32+0x40/0xb8
>> >   pc : [] lr : [] pstate: 61c5
>> >   ...
>> >   Call trace:
>> >   [] pci_generic_config_read32+0x4c/0xb8
>> >   [] pci_user_read_config_byte+0x60/0xc4
>> >   [] pci_read_config+0x15c/0x238
>> >   [] sysfs_kf_bin_read+0x68/0xa0
>> >   [] kernfs_fop_read+0x9c/0x1ac
>> >   [] __vfs_read+0x44/0x128
>> >   [] vfs_read+0x84/0x144
>> >   [] SyS_read+0x50/0xb0
>>
>> The log shows kernel gets an exception when trying to access Mellanox
>> card configuration space. This is usually due to suboptimal PCIe
>> SerDes parameters are using in your board, which will cause bad link
>> quality.
>
> I would have hoped that "suboptimal" means that it still works, albeit
> not fully optimal ;).

Yes, it should still work, but you may see crashes occasionally due to
link quality.

>
>> The PCIe SerDes programming is done in U-Boot, so I suggest you do a
>> U-Boot upgrade to our latest X-Gene U-Boot release.
>>
>> In order to access latest X-Gene U-Boot release, please use APM
>> official support channel:
>> https://myapm.apm.com
>>
>> Please register an account at myapm.apm.com if you don't have one
>> using following link:
>> https://myapm.apm.com/user/register
>
> Isn't the latest U-Boot source for X-Gene publicly available anywhere?
> It's GPL code anyway, so it shouldn't have proprietary code to require
> registration, click-through agreements.

APM X-Gene U-Boot isn't available publicly yet. Though, if this is
required, we can make a public GIT which will be hosted with APM
server.

As of now, customer who has a board from APM will have to use MyAPM to
get U-Boot source and binary.
>
> --
> Catalin



-- 
Regards,
Duc Dang.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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 v1 3/7] ARM: dts: apq8064-ifc6410: add heart-beat led support.

[Andreas Färber]

Am 28.07.2015 um 14:54 schrieb Srinivas Kandagatla:
> This patch adds heart-beat led support on IFC6410.
> 
> Signed-off-by: Srinivas Kandagatla 
> ---
>  arch/arm/boot/dts/qcom-apq8064-ifc6410.dts | 22 ++
>  1 file changed, 22 insertions(+)
> 
> diff --git a/arch/arm/boot/dts/qcom-apq8064-ifc6410.dts 
> b/arch/arm/boot/dts/qcom-apq8064-ifc6410.dts
> index df560cf..1fc2ea5 100644
> --- a/arch/arm/boot/dts/qcom-apq8064-ifc6410.dts
> +++ b/arch/arm/boot/dts/qcom-apq8064-ifc6410.dts
> @@ -207,6 +207,19 @@
>   status = "okay";
>   };
>  
> + leds {
> + compatible = "gpio-leds";
> + pinctrl-names = "default";
> + pinctrl-0 = <¬ify_led>;
> +
> + led@1 {
> + label = "apq8064:green:user1";
> + gpios = <&pm8921_gpio 18 GPIO_ACTIVE_HIGH>;
> + linux,default-trigger = "heartbeat";

Can we please drop the heartbeat default? While that's nice as proof of
concept, it's annoying to deliver it that way in Linux distros. Users
can enable that trigger with a simple boot script writing to /sys.

Thanks,
Andreas

> + default-state = "on";
> + };
> + };
> +
>   qcom,ssbi@50 {
>   pmicintc: pmic@0 {
>   pm8921_gpio: gpio@150 {
[snip]

-- 
SUSE Linux GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
GF: Felix Imendörffer, Jane Smithard, Dilip Upmanyu, Graham Norton; HRB
21284 (AG Nürnberg)
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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 07/14] mm/huge_page: Convert khugepaged() into kthread worker API

[Tejun Heo]

Hello,

On Tue, Jul 28, 2015 at 04:39:24PM +0200, Petr Mladek wrote:
> -static void khugepaged_wait_work(void)
> +static void khugepaged_wait_func(struct kthread_work *dummy)
>  {
>   if (khugepaged_has_work()) {
>   if (!khugepaged_scan_sleep_millisecs)
> - return;
> + goto out;
>  
>   wait_event_freezable_timeout(khugepaged_wait,
> -  kthread_should_stop(),
> +  !khugepaged_enabled(),
>   msecs_to_jiffies(khugepaged_scan_sleep_millisecs));
> - return;
> + goto out;
>   }
>  
>   if (khugepaged_enabled())
>   wait_event_freezable(khugepaged_wait, khugepaged_wait_event());
> +
> +out:
> + if (khugepaged_enabled())
> + queue_kthread_work(&khugepaged_worker,
> +&khugepaged_do_scan_work);
>  }

There gotta be a better way to do this.  It's outright weird to
convert it over to work item based interface and then handle idle
periods by injecting wait work items.  If there's an external event
which wakes up the worker, convert that to a queueing event.  If it's
a timed event, implement a delayed work and queue that with delay.

Thanks.

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

Re: Requesting inclusion of mtd/nand patches in linux-3.14.y

[Greg KH]

On Tue, Jul 28, 2015 at 03:40:46PM +0200, Mason wrote:
> Hello everyone,
> 
> This is my second time requesting inclusion of a patch, please
> point out any breach of protocol :-)

I never saw your first request, where did you send that?

> I have cherry-picked two mtd/nand patches on my local branch
> of linux-3.14.y and I realized that these fixes might benefit
> other users. (As far as I can tell, they landed in 3.15)
> 
> bd9c6e99b582 mtd: nand: don't use read_buf for 8-bit ONFI transfers
> 60c3bc1fd6f1 mtd: nand: fix erroneous read_buf call in 
> nand_write_page_raw_syndrome

both now queued up, 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 1/5] iTCO_wdt: Expose watchdog properties using platform data

[Lee Jones]

On Tue, 28 Jul 2015, Guenter Roeck wrote:

> On 07/28/2015 08:28 AM, Lee Jones wrote:
> >On Tue, 28 Jul 2015, Guenter Roeck wrote:
> >
> >>On 07/28/2015 08:00 AM, Lee Jones wrote:
> >>>On Tue, 28 Jul 2015, Matt Fleming wrote:
> On Tue, 28 Jul, at 12:37:21PM, Lee Jones wrote:
> >
> >The driver shouldn't be called that either.
> >
> >You are the only one.  What makes iTCO 'special'?
> 
> I don't know, I didn't write it. It looks like Wim did ~9 years ago, so
> it must have made sense to him at the time.
> 
> >>
> >>Coding style wasn't as strict then as it is today. iTCO has just been kept
> >>for historic reasons.
> >
> >For sure, I get that, but it doesn't mean we can't do-the-right-thing
> >(tm) now does it?
> >
> >>Sure, we could have changed it to lowercase, but so far no one bothered.
> >>Plus, of course, there is always the element that some maintainers hate
> >>that kind of cleanup,
> >
> >Really?  Surely any kind of clean-up is good clean-up.  Especially as
> >Greg KH et. al, have been doing public presentations telling everyone
> >that there is always kernel work for anyone who has the time; spelling
> >corrections and all.
> >
> 
> Yes, really. Just try to submit cleanup patches to maintainers other than
> Greg and myself, and you'll see. It is a minefield.

Admittedly some of us have our quirks, but I'm happy to challenge
anyone that won't accept clean-up patches that make things better.

-- 
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v1 4/7] ARM: dts: apq8064: Add MDP support

[Andreas Färber]

Hi,

Am 28.07.2015 um 14:54 schrieb Srinivas Kandagatla:
> From: Rob Clark 
> 
> This patch adds MDP node to APQ8064 dt.
> 
> Signed-off-by: Rob Clark 
> [Srinivas Kandagatla] : updated with new style rpm regulators
> Signed-off-by: Srinivas Kandagatla 
> ---
>  arch/arm/boot/dts/qcom-apq8064.dtsi | 87 
> +
>  1 file changed, 87 insertions(+)
> 
> diff --git a/arch/arm/boot/dts/qcom-apq8064.dtsi 
> b/arch/arm/boot/dts/qcom-apq8064.dtsi
> index cba4ccb..7d2cc45 100644
> --- a/arch/arm/boot/dts/qcom-apq8064.dtsi
> +++ b/arch/arm/boot/dts/qcom-apq8064.dtsi
[...]
> + gpu: qcom,adreno-3xx@430 {
> + compatible = "qcom,adreno-3xx";

I thought that wildcards were forbidden in compatible strings? Then this
should be replaced by the real number, with a fallback to the first
compatible one.

And can't we just name the node qcom,adreno without version suffix?

Regards,
Andreas

> + reg = <0x0430 0x2>;
> + reg-names = "kgsl_3d0_reg_memory";
> + interrupts = ;
> + interrupt-names = "kgsl_3d0_irq";
> + clock-names =
> + "core_clk",
> + "iface_clk",
> + "mem_clk",
> + "mem_iface_clk";
> + clocks =
> + <&mmcc GFX3D_CLK>,
> + <&mmcc GFX3D_AHB_CLK>,
> + <&mmcc GFX3D_AXI_CLK>,
> + <&mmcc MMSS_IMEM_AHB_CLK>;
> + qcom,chipid = <0x03020002>;
> + qcom,gpu-pwrlevels {
> + compatible = "qcom,gpu-pwrlevels";
> + qcom,gpu-pwrlevel@0 {
> + qcom,gpu-freq = <45000>;
> + };
> + qcom,gpu-pwrlevel@1 {
> + qcom,gpu-freq = <2700>;
> + };
> + };
> + };
> +
> + mdp: qcom,mdp@510 {
> + compatible = "qcom,mdp";
> + reg = <0x0510 0xf>;
> + interrupts = ;
> + connectors = <&hdmi>;
> + gpus = <&gpu>;
> + clock-names =
> + "core_clk",
> + "iface_clk",
> + "lut_clk",
> + "src_clk",
> + "hdmi_clk",
> + "mdp_clk",
> + "mdp_axi_clk";
> + clocks =
> + <&mmcc MDP_CLK>,
> + <&mmcc MDP_AHB_CLK>,
> + <&mmcc MDP_LUT_CLK>,
> + <&mmcc TV_SRC>,
> + <&mmcc HDMI_TV_CLK>,
> + <&mmcc MDP_TV_CLK>,
> + <&mmcc MDP_AXI_CLK>;
> + };
>   };
>  };

-- 
SUSE Linux GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
GF: Felix Imendörffer, Jane Smithard, Dilip Upmanyu, Graham Norton; HRB
21284 (AG Nürnberg)
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH V3 3/3] devicetree: da9062: Add device tree bindings for DA9062 OnKey

[Lee Jones]

On Tue, 28 Jul 2015, Dmitry Torokhov wrote:

> On Tue, Jul 28, 2015 at 09:40:19AM +0100, Lee Jones wrote:
> > On Mon, 27 Jul 2015, Dmitry Torokhov wrote:
> > 
> > > On Mon, Jul 27, 2015 at 03:43:00PM -0700, Dmitry Torokhov wrote:
> > > > On Thu, Jul 23, 2015 at 05:17:41PM +0100, S Twiss wrote:
> > > > > From: S Twiss 
> > > > > 
> > > > > Add device tree bindings for the DA9062 OnKey driver component
> > > > > 
> > > > > Signed-off-by: Steve Twiss 
> > > > > 
> > > > > ---
> > > > > Changes in V3:
> > > > >  - Child driver specifics separated out into separate document
> > > > >in this case ../input/da9062-onkey.txt
> > > > > Changes in V2:
> > > > >  - No change
> > > > > 
> > > > > This patch applies against linux-next and next-20150708 
> > > > > 
> > > > > 
> > > > >  .../devicetree/bindings/input/da9062-onkey.txt | 36 
> > > > > ++
> > > > >  Documentation/devicetree/bindings/mfd/da9062.txt   |  3 ++
> > > > 
> > > > I dropped bits for mfd/da9062.txt, changed to mention both 9062 and
> > > > 9063, folded into the onkey patch and applied.
> > > 
> > > Argh, da9062 core is not in mainline yet... OK, below is the patch I
> > > had; if Lee does not pick it up I'll re-apply it when da9062 core hits
> > > mainline.
> > 
> > Hmm... that's annoying.  You've put the patch below your signature
> > '--', so my mailer cuts it off.
> 
> OK, sorry, I'll make sure to put in before the signature next time.

Appreciated.

> > [pasting]
> > 
> > > Input: add DA9062 OnKey capability to DA9063 OnKey driver
> > > 
> > > From: S Twiss 
> > > 
> > > Add DA9062 OnKey support into the existing DA9063 OnKey driver component 
> > > by
> > > using generic access tables for common register and bit mask definitions.
> > > 
> > > The following change will add generic register and bit mask support to the
> > > DA9063 OnKey.
> > > 
> > > The following alterations have been made to the DA9063 OnKey:
> > > 
> > > - Addition of a da906x_chip_config structure to hold all
> > >   generic registers and bitmasks for this type of OnKey component.
> > > - Addition of an struct of_device_id table for DA9063 and DA9062
> > >   defaults
> > > - Refactoring functions to use struct da9063_onkey accesses to generic
> > >   registers/masks instead of using defines from registers.h
> > > - Re-work of da9063_onkey_probe() to use of_match_node() and
> > >   dev_get_regmap() to provide initialisation of generic registers and
> > >   masks and access to regmap
> > > 
> > > Signed-off-by: Steve Twiss 
> > > Signed-off-by: Dmitry Torokhov 
> > > ---
> > >  .../devicetree/bindings/input/da9062-onkey.txt |   32 +
> > >  drivers/input/misc/Kconfig |8 +
> > >  drivers/input/misc/da9063_onkey.c  |  129 
> > > 
> > >  3 files changed, 140 insertions(+), 29 deletions(-)
> > >  create mode 100644 
> > > Documentation/devicetree/bindings/input/da9062-onkey.txt
> >  
> > I'm confused.  What's the dependency?
> > 
> > There shouldn't be any issue applying input patches, just because
> > there isn't an MFD counterpart.  In fact, I would take prior
> > acceptance of the child into consideration (would be like a +1 vote)
> > when reviewing the MFD part.
> 
> It's this chunk:
> 
> +#include 
> +#include 
> 
> and these header files are not in mainline yet.

Ah, thanks for the clarification.

I will apply the other patches.

> > One suggestion however, I would ask for the DT binding and the driver
> > to be separated, as per [0].
> > 
> > [0] Documentation/devicetree/bindings/submitting-patches.txt
> 
> Right, but that says about submitting patches, not applying them ;)
> 
> When I chatted with Grant he said that the policy of separating binding
> and code into separate patches is done so not to overwhelm devicetree
> list and that is is perfectly fine to actually apply them as a single
> commit. I try to combine them together so that when looking through
> history they show up as one.

Got you. :)

-- 
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [RFC PATCH 06/14] kthread: Add kthread_worker_created()

[Tejun Heo]

Hello,

On Tue, Jul 28, 2015 at 04:39:23PM +0200, Petr Mladek wrote:
> I would like to make cleaner kthread worker API and hide the definition
> of struct kthread_worker. It will prevent any custom hacks and make
> the API more secure.
> 
> This patch provides an API to check if the worker has been created
> and hides the implementation details.

Maybe it'd be a better idea to make create_kthread_worker() allocate
and return pointer to struct kthread_worker?  You're adding
create/destroy interface anyway, it won't need a separate created
query function and the synchronization rules would be self-evident.

Thanks.

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

Re: [RFC 0/2] VFIO: Add virtual MSI doorbell support.

[Alex Williamson]

On Tue, 2015-07-28 at 17:55 +0100, Marc Zyngier wrote:
> Hi Alex,
> 
> On 28/07/15 17:21, Alex Williamson wrote:
> > On Fri, 2015-07-24 at 14:33 +0530, Pranavkumar Sawargaonkar wrote:
> >> In current VFIO MSI/MSI-X implementation, linux host kernel
> >> allocates MSI/MSI-X vectors when userspace requests through vfio ioctls.
> >> Vfio creates irqfd mappings to notify MSI/MSI-X interrupts
> >> to the userspace when raised.
> >> Guest OS will see emulated MSI/MSI-X controller and receives an interrupt
> >> when kernel notifies the same via irqfd.
> >>
> >> Host kernel allocates MSI/MSI-X using standard linux routines
> >> like pci_enable_msix_range() and pci_enable_msi_range(). 
> >> These routines along with requset_irq() in host kernel sets up 
> >> MSI/MSI-X vectors with Physical MSI/MSI-X addresses provided by
> >> interrupt controller driver in host kernel.
> >>
> >> This means when a device is assigned with the guest OS, MSI/MSI-X addresses
> >> present in PCIe EP are the PAs programmed by the host linux kernel.
> >>
> >> In x86 MSI/MSI-X physical address range is reserved and iommu is aware
> >> about these addreses and transalation is bypassed for these address range.
> >>
> >> Unlike x86, ARM/ARM64 does not reserve MSI/MSI-X Physical address range and
> >> all the transactions including MSI go through iommu/smmu without bypass.
> >> This requires extending current vfio MSI layer with additional 
> >> functionality
> >> for ARM/ARM64 by
> >> 1. Programing IOVA (referred as a MSI virtual doorbell address)
> >>in device's MSI vector as a MSI address.
> >>This IOVA will be provided by the userspace based on the
> >>MSI/MSI-X addresses reserved for the guest.
> >> 2. Create an IOMMU mapping between this IOVA and
> >>Physical address (PA) assigned to the MSI vector.
> >>
> >> This RFC is proposing a solution for MSI/MSI-X passthrough for ARM/ARM64.
> > 
> > 
> > Hi Pranavkumar,
> > 
> > Freescale has the same, or very similar, need, so any solution in this
> > space will need to work for both ARM and powerpc.  I'm not a big fan of
> > this approach as it seems to require the user to configure MSI/X via
> > ioctl and then call a separate ioctl mapping the doorbells.  That's more
> > code for the user, more code to get wrong and potentially a gap between
> > configuring MSI/X and enabling mappings where we could see IOMMU faults.
> > 
> > If we know that doorbell mappings are required, why can't we set aside a
> > bank of IOVA space and have them mapped automatically as MSI/X is being
> > configured?  Then the user's need for special knowledge and handling of
> > this case is limited to setup.  The IOVA space will be mapped and used
> > as needed, we only need the user to specify the IOVA space reserved for
> > this.  Thanks,
> 
> I guess my immediate worry is that it seems to impose a fixed mapping
> for all the guests, which would restrict the "shape" of the mappings we
> give to a guest. Or did you intend for that IOVA mapping to be defined
> on a "per userspace instance" basis?

Hi Marc,

Right, I'm not suggesting a fixed mapping imposed on the user, I'm
suggesting the user can set aside a range of IOVA space for VFIO to make
use of for this purpose.  The user would be explicitly defining that
range of reserved IOVA space.

We effectively have your first scenario on x86, where the platform
restriction shapes the VM.  When we have an x86 guest on x86 host, the
guest and host implicit reserved regions align and we don't have any
problems.  However if we wanted to run an ARM64 guest with an assigned
device on an x86 host, we'd need to "shape" the VM to avoid memory
overlapping the implicitly reserved range.

Ideally we could extend the interfaces to support both of these, a
mechanism to discover implicitly reserved ranges and for the user to set
explicitly reserved ranges.  Thanks,

Alex

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

Re: [PATCH] perf, tools, stat: Fix perf stat -T

[Andi Kleen]

> > I'm not talking about it being urgent or not, I'm talking about it being
> > a bug present only in perf/core or if this is something that is in
> > perf/urgent, i.e. affects what is in Linus's upstream tree, etc.
> 
> ah ok, it affects perf/urgent as well

I think there are some more typos in the cache statistics. 
Compare perf stat -d -d -d -d output with an old perf.

-Andi

-- 
a...@linux.intel.com -- Speaking for myself only
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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 0/2] VFIO: Add virtual MSI doorbell support.

[Bhushan Bharat]

Hi Alex,

> -Original Message-
> From: Alex Williamson [mailto:alex.william...@redhat.com]
> Sent: Tuesday, July 28, 2015 9:52 PM
> To: Pranavkumar Sawargaonkar
> Cc: k...@vger.kernel.org; kvm...@lists.cs.columbia.edu; linux-arm-
> ker...@lists.infradead.org; linux-kernel@vger.kernel.org;
> christoffer.d...@linaro.org; marc.zyng...@arm.com; will.dea...@arm.com;
> bhelg...@google.com; a...@arndb.de; rob.herr...@linaro.org;
> eric.au...@linaro.org; patc...@apm.com; Bhushan Bharat-R65777; Yoder
> Stuart-B08248
> Subject: Re: [RFC 0/2] VFIO: Add virtual MSI doorbell support.
> 
> On Fri, 2015-07-24 at 14:33 +0530, Pranavkumar Sawargaonkar wrote:
> > In current VFIO MSI/MSI-X implementation, linux host kernel allocates
> > MSI/MSI-X vectors when userspace requests through vfio ioctls.
> > Vfio creates irqfd mappings to notify MSI/MSI-X interrupts to the
> > userspace when raised.
> > Guest OS will see emulated MSI/MSI-X controller and receives an
> > interrupt when kernel notifies the same via irqfd.
> >
> > Host kernel allocates MSI/MSI-X using standard linux routines like
> > pci_enable_msix_range() and pci_enable_msi_range().
> > These routines along with requset_irq() in host kernel sets up
> > MSI/MSI-X vectors with Physical MSI/MSI-X addresses provided by
> > interrupt controller driver in host kernel.
> >
> > This means when a device is assigned with the guest OS, MSI/MSI-X
> > addresses present in PCIe EP are the PAs programmed by the host linux
> kernel.
> >
> > In x86 MSI/MSI-X physical address range is reserved and iommu is aware
> > about these addreses and transalation is bypassed for these address range.
> >
> > Unlike x86, ARM/ARM64 does not reserve MSI/MSI-X Physical address
> > range and all the transactions including MSI go through iommu/smmu
> without bypass.
> > This requires extending current vfio MSI layer with additional
> > functionality for ARM/ARM64 by 1. Programing IOVA (referred as a MSI
> > virtual doorbell address)
> >in device's MSI vector as a MSI address.
> >This IOVA will be provided by the userspace based on the
> >MSI/MSI-X addresses reserved for the guest.
> > 2. Create an IOMMU mapping between this IOVA and
> >Physical address (PA) assigned to the MSI vector.
> >
> > This RFC is proposing a solution for MSI/MSI-X passthrough for
> ARM/ARM64.
> 
> 
> Hi Pranavkumar,
> 
> Freescale has the same, or very similar, need, so any solution in this space
> will need to work for both ARM and powerpc.  I'm not a big fan of this
> approach as it seems to require the user to configure MSI/X via ioctl and then
> call a separate ioctl mapping the doorbells.  That's more code for the user,
> more code to get wrong and potentially a gap between configuring MSI/X
> and enabling mappings where we could see IOMMU faults.
> 
> If we know that doorbell mappings are required, why can't we set aside a
> bank of IOVA space and have them mapped automatically as MSI/X is being
> configured?  Then the user's need for special knowledge and handling of this
> case is limited to setup.  The IOVA space will be mapped and used as needed,
> we only need the user to specify the IOVA space reserved for this.  Thanks,

We probably need a mix of both to support Freescale PowerPC and ARM based 
machines.
In this mix mode kernel vfio driver will reserve some IOVA for mapping MSI 
page/s. If any other iova mapping will overlap with this then it will return 
error and user-space. Ideally this should be choosen in such a way that it 
never overlap, which is easy on some systems but can be tricky on some other 
system like Freescale PowerPC. This is not sufficient for at-least Freescale 
PowerPC based SOC. This is because of hardware limitation, where we need to fit 
this reserved iova address within aperture decided by user-space. So if we 
allow user-space to change this reserved iova address to a value decided by 
user-spece itself then we can support both ARM/PowerPC based solutions.

I have some implementation ready/tested with this approach and if this approach 
looks good then I can submit a RFC patch.

Thanks
-Bharat
> 
> Alex

Re: [PATCH] of/irq: introduce of_has_named_irqs helper

[Dmitry Torokhov]

On Tue, Jul 28, 2015 at 06:53:52PM +0530, Vignesh R wrote:
> Hi Dmitry,
> 
> On 07/25/2015 01:46 AM, Dmitry Torokhov wrote:
> > On Fri, Jul 24, 2015 at 12:26:19PM -0700, Dmitry Torokhov wrote:
> >> On Fri, Jul 24, 2015 at 02:14:57PM -0500, Rob Herring wrote:
> >>> On Fri, Jul 24, 2015 at 1:26 PM, Dmitry Torokhov
> >>>  wrote:
>  Sometimes drivers might wish to transition from index-based to named
>  interrupt descriptions. To aid in decision-making when parsing device
>  tree data let's provide a helper that will indicate the scheme that is
>  being used.
> >>>
> >>> Generally, IRQs are retrieved by platform_get_irq or
> >>> platform_get_irq_byname. Drivers should not call the of_irq_*
> >>> functions directly in most cases.
> >>
> >> That would be true for platform drivers, but not all devices are
> >> platform devices.
> >>
> >>>
> 
>  Signed-off-by: Dmitry Torokhov 
>  ---
> 
>  The intent is to it like this:
> 
>  if (of_has_named_irqs(np) {
>  /* Wake IRQ is optional */
>  dev->wakeirq = of_irq_get_byname(np, "wakeup");
>  if (dev->wakeirq < 0 && dev->wakeirq != -ENODATA)
>  return dev->wakeirq;
>  }
> >>>
> >>> of_irq_get_byname will already return an error if the property is not
> >>> present. Use that.
> >>
> >> I do not like that it returns -EINVAL when property is missing, can we
> >> change it to return -ENODATA (so it is the same as when the property is
> >> defined but such name is missing)?
> > 
> > So here is what I had in mind.. It is based on recent patch by Vignesh
> > for pixcir touchscreen, but I think it should be made available to all
> > I2C devices. Completely untested at the moment.
> > 
> 
> Thanks for the patch! I tested this on am437x-gp-evm and the
> suspend/resume worked fine (below patch + $subject patch). I was able to
> wake the system from low power state using touchscreen. Also verified
> module insertion and removal. One comment though, please see below.
> 
> > ---
> >  drivers/i2c/i2c-core.c |   43 +--
> >  1 file changed, 37 insertions(+), 6 deletions(-)
> > 
> > diff --git a/drivers/i2c/i2c-core.c b/drivers/i2c/i2c-core.c
> > index e6d4935..3971461 100644
> > --- a/drivers/i2c/i2c-core.c
> > +++ b/drivers/i2c/i2c-core.c
> > @@ -47,6 +47,7 @@
> >  #include 
> >  #include 
> >  #include 
> > +#include 
> >  #include 
> >  #include 
> >  #include 
> > @@ -631,6 +632,7 @@ static int i2c_device_probe(struct device *dev)
> >  {
> > struct i2c_client   *client = i2c_verify_client(dev);
> > struct i2c_driver   *driver;
> > +   int wakeirq = 0;
> > int status;
> >  
> > if (!client)
> > @@ -639,11 +641,13 @@ static int i2c_device_probe(struct device *dev)
> > if (!client->irq) {
> > int irq = -ENOENT;
> >  
> > -   if (dev->of_node)
> > -   irq = of_irq_get(dev->of_node, 0);
> > -   else if (ACPI_COMPANION(dev))
> > +   if (dev->of_node) {
> > +   irq = of_has_named_irqs(dev->of_node) ?
> > +   of_irq_get_byname(dev->of_node, "irq") :
> > +   of_irq_get(dev->of_node, 0);
> > +   } else if (ACPI_COMPANION(dev)) {
> > irq = acpi_dev_gpio_irq_get(ACPI_COMPANION(dev), 0);
> > -
> > +   }
> > if (irq == -EPROBE_DEFER)
> > return irq;
> > if (irq < 0)
> > @@ -652,6 +656,15 @@ static int i2c_device_probe(struct device *dev)
> > client->irq = irq;
> > }
> >  
> > +   if (dev->of_node && of_has_named_irqs(dev->of_node)) {
> > +   wakeirq = of_irq_get_byname(dev->of_node, "wakeup");
> > +   if (wakeirq < 0) {
> > +   if (wakeirq != -ENODATA)
> > +   return wakeirq;
> > +   wakeirq = 0;
> > +   }
> > +   }
> > +
> > driver = to_i2c_driver(dev->driver);
> > if (!driver->probe || !driver->id_table)
> > return -ENODEV;
> > @@ -659,20 +672,34 @@ static int i2c_device_probe(struct device *dev)
> > if (!device_can_wakeup(&client->dev))
> > device_init_wakeup(&client->dev,
> > client->flags & I2C_CLIENT_WAKE);
> > +
> > +   status = wakeirq > 0 ?
> > +   dev_pm_set_dedicated_wake_irq(dev, wakeirq) :
> > +   (client->irq > 0 ?
> > +   dev_pm_set_wake_irq(dev, client->irq) : 0);
> 
> Above code tries to register wakeirq irrespective of whether the device
> is specified as wakeup-source in the dt or not. Hence, I see warn
> messages from every i2c device that has irq line but hasn't declared
> itself as wakeup-source:
> For example tps is on i2c:
> [1.961613] tps65218 0-0024: forgot to call call device_init_wakeup?
> [1.968340] tps65218 0-0024: failed to set up 

Re: [RFC PATCH 05/14] kthread: Add wakeup_and_destroy_kthread_worker()

[Tejun Heo]

Hello,

On Tue, Jul 28, 2015 at 04:39:22PM +0200, Petr Mladek wrote:
...
> +void wakeup_and_destroy_kthread_worker(struct kthread_worker *worker)
> +{
> + struct task_struct *task = worker->task;
> +
> + if (WARN_ON(!task))
> + return;
> +
> + spin_lock_irq(&worker->lock);
> + if (worker->current_work)
> + wake_up_process(worker->task);
> + spin_unlock_irq(&worker->lock);
> +
> + destroy_kthread_worker(worker);
> +}

I don't know.  Wouldn't it make far more sense to convert those wake
up events with queueings?  It seems backwards to be converting things
to work item based interface and then insert work items which wait for
external events.  More on this later.

Thanks.

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

[PATCH] x86, fpu: correct XSAVE xstate size calculation

[Dave Hansen]

From: Dave Hansen 

Note: our xsaves support is currently broken and disabled.  This
patch does not fix it, but it is an incremental improvement.  It
might be useful to someone backporting the entire set of XSAVES
patches at some point, but it should not be backported alone.

There are currently two xsave buffer formats: standard and
compacted.  The standard format is waht 'XSAVE' and 'XSAVEOPT'
produce while 'XSAVES' and 'XSAVEC' produce a compacted-formet
buffer.  (The kernel never uses XSAVEC)

But, the XSAVES buffer *ALSO* contains "system state components"
which are never saved by a plain XSAVE.  So, XSAVES has two
things that might make its buffer differently-sized from an
XSAVE-produced one.

The current code assumes that an XSAVES buffer's size is simply
the sum of the sizes of the (user) states which are supported.
This seems to work in most cases, but it is not consistent with
what the SDM says, and it breaks if we 'align' a component in the
buffer.  The calculation is also unnecessary work since the CPU
*tells* us the size of the buffer directly.

This patch just reads the size of the buffer right out of the
CPUID leaf instead of trying to derive it.

Signed-off-by: Dave Hansen 
Cc: Ingo Molnar 
Cc: Linux Kernel Mailing List 
Cc: Borislav Petkov 
Cc: Fenghua Yu 
Cc: "H. Peter Anvin" 
Cc: x...@kernel.org
---

 b/arch/x86/kernel/fpu/xstate.c |   36 ++--
 1 file changed, 26 insertions(+), 10 deletions(-)

diff -puN arch/x86/kernel/fpu/xstate.c~fix-xstate_size-calculation 
arch/x86/kernel/fpu/xstate.c
--- a/arch/x86/kernel/fpu/xstate.c~fix-xstate_size-calculation  2015-07-24 
09:50:36.418385438 -0700
+++ b/arch/x86/kernel/fpu/xstate.c  2015-07-27 11:02:13.305376883 -0700
@@ -292,24 +292,40 @@ static void __init setup_init_fpu_buf(vo
 
 /*
  * Calculate total size of enabled xstates in XCR0/xfeatures_mask.
+ *
+ * Note the SDM's wording here.  "sub-function 0" only enumerates
+ * the size of the *user* states.  If we use it to size a buffer
+ * that we use 'XSAVES' on, we could potentially overflow the
+ * buffer because 'XSAVES' saves system states too.
+ *
+ * Note that we do not currently set any bits on IA32_XSS so
+ * 'XCR0 | IA32_XSS == XCR0' for now.
  */
 static void __init init_xstate_size(void)
 {
unsigned int eax, ebx, ecx, edx;
-   int i;
 
if (!cpu_has_xsaves) {
+   /*
+* - CPUID function 0DH, sub-function 0:
+*EBX enumerates the size (in bytes) required by
+*the XSAVE instruction for an XSAVE area
+*containing all the *user* state components
+*corresponding to bits currently set in XCR0.
+*/
cpuid_count(XSTATE_CPUID, 0, &eax, &ebx, &ecx, &edx);
xstate_size = ebx;
-   return;
-   }
-
-   xstate_size = FXSAVE_SIZE + XSAVE_HDR_SIZE;
-   for (i = 2; i < 64; i++) {
-   if (test_bit(i, (unsigned long *)&xfeatures_mask)) {
-   cpuid_count(XSTATE_CPUID, i, &eax, &ebx, &ecx, &edx);
-   xstate_size += eax;
-   }
+   } else {
+   /*
+* - CPUID function 0DH, sub-function 1:
+*EBX enumerates the size (in bytes) required by
+*the XSAVES instruction for an XSAVE area
+*containing all the state components
+*corresponding to bits currently set in
+*XCR0 | IA32_XSS.
+*/
+   cpuid_count(XSTATE_CPUID, 1, &eax, &ebx, &ecx, &edx);
+   xstate_size = ebx;
}
 }
 
_
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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/8] jump_label: Add a new static_key interface

[Peter Zijlstra]

On Tue, Jul 28, 2015 at 07:00:55PM +0200, Rabin Vincent wrote:

> 
> This is missing an include of asm/unified.h for the WASM():
> 
> diff --git a/arch/arm/include/asm/jump_label.h 
> b/arch/arm/include/asm/jump_label.h
> index f8bc12f..34f7b69 100644
> --- a/arch/arm/include/asm/jump_label.h
> +++ b/arch/arm/include/asm/jump_label.h
> @@ -4,6 +4,7 @@
>  #ifndef __ASSEMBLY__
>  
>  #include 
> +#include 
>  
>  #define JUMP_LABEL_NOP_SIZE 4
> 
> With that added, it builds and works fine on ARM.

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

Re: [PATCH V3 3/3] devicetree: da9062: Add device tree bindings for DA9062 OnKey

[Dmitry Torokhov]

On Tue, Jul 28, 2015 at 09:40:19AM +0100, Lee Jones wrote:
> On Mon, 27 Jul 2015, Dmitry Torokhov wrote:
> 
> > On Mon, Jul 27, 2015 at 03:43:00PM -0700, Dmitry Torokhov wrote:
> > > On Thu, Jul 23, 2015 at 05:17:41PM +0100, S Twiss wrote:
> > > > From: S Twiss 
> > > > 
> > > > Add device tree bindings for the DA9062 OnKey driver component
> > > > 
> > > > Signed-off-by: Steve Twiss 
> > > > 
> > > > ---
> > > > Changes in V3:
> > > >  - Child driver specifics separated out into separate document
> > > >in this case ../input/da9062-onkey.txt
> > > > Changes in V2:
> > > >  - No change
> > > > 
> > > > This patch applies against linux-next and next-20150708 
> > > > 
> > > > 
> > > >  .../devicetree/bindings/input/da9062-onkey.txt | 36 
> > > > ++
> > > >  Documentation/devicetree/bindings/mfd/da9062.txt   |  3 ++
> > > 
> > > I dropped bits for mfd/da9062.txt, changed to mention both 9062 and
> > > 9063, folded into the onkey patch and applied.
> > 
> > Argh, da9062 core is not in mainline yet... OK, below is the patch I
> > had; if Lee does not pick it up I'll re-apply it when da9062 core hits
> > mainline.
> 
> Hmm... that's annoying.  You've put the patch below your signature
> '--', so my mailer cuts it off.

OK, sorry, I'll make sure to put in before the signature next time.

> 
> [pasting]
> 
> > Input: add DA9062 OnKey capability to DA9063 OnKey driver
> > 
> > From: S Twiss 
> > 
> > Add DA9062 OnKey support into the existing DA9063 OnKey driver component by
> > using generic access tables for common register and bit mask definitions.
> > 
> > The following change will add generic register and bit mask support to the
> > DA9063 OnKey.
> > 
> > The following alterations have been made to the DA9063 OnKey:
> > 
> > - Addition of a da906x_chip_config structure to hold all
> >   generic registers and bitmasks for this type of OnKey component.
> > - Addition of an struct of_device_id table for DA9063 and DA9062
> >   defaults
> > - Refactoring functions to use struct da9063_onkey accesses to generic
> >   registers/masks instead of using defines from registers.h
> > - Re-work of da9063_onkey_probe() to use of_match_node() and
> >   dev_get_regmap() to provide initialisation of generic registers and
> >   masks and access to regmap
> > 
> > Signed-off-by: Steve Twiss 
> > Signed-off-by: Dmitry Torokhov 
> > ---
> >  .../devicetree/bindings/input/da9062-onkey.txt |   32 +
> >  drivers/input/misc/Kconfig |8 +
> >  drivers/input/misc/da9063_onkey.c  |  129 
> > 
> >  3 files changed, 140 insertions(+), 29 deletions(-)
> >  create mode 100644 Documentation/devicetree/bindings/input/da9062-onkey.txt
>  
> I'm confused.  What's the dependency?
> 
> There shouldn't be any issue applying input patches, just because
> there isn't an MFD counterpart.  In fact, I would take prior
> acceptance of the child into consideration (would be like a +1 vote)
> when reviewing the MFD part.

It's this chunk:

+#include 
+#include 

and these header files are not in mainline yet.

> 
> One suggestion however, I would ask for the DT binding and the driver
> to be separated, as per [0].
> 
> [0] Documentation/devicetree/bindings/submitting-patches.txt

Right, but that says about submitting patches, not applying them ;)

When I chatted with Grant he said that the policy of separating binding
and code into separate patches is done so not to overwhelm devicetree
list and that is is perfectly fine to actually apply them as a single
commit. I try to combine them together so that when looking through
history they show up as one.

Thanks.

-- 
Dmitry
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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: [Xen-devel] [PATCH 8/8] xen/privcmd: Further s/MFN/GFN/ clean-up

[David Vrabel]

On 28/07/15 16:02, Julien Grall wrote:
> The privcmd code is mixing the usage of GFN and MFN within the same
> functions which make the code difficult to understand when you only work
> with auto-translated guests.
> 
> The privcmd driver is only dealing with GFN so replace all the mention
> of MFN into GFN.
> 
> The ioctl structure used to map foreign change has been left unchanged
> given that the userspace is using it. Nonetheless, add a comment to
> explain the expected value within the "mfn" field.

Reviewed-by: David Vrabel 

David
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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/9] x86/intel_rdt: Add new cgroup and Class of service management

[Peter Zijlstra]

On Wed, Jul 01, 2015 at 03:21:06PM -0700, Vikas Shivappa wrote:
>  static int __init intel_rdt_late_init(void)
>  {
>   struct cpuinfo_x86 *c = &boot_cpu_data;
> + static struct clos_cbm_map *ccm;
> + u32 maxid, max_cbm_len;
> + size_t sizeb;

Why 'sizeb' ? 'size' is still available, right?

> + int err = 0;
>  
> - if (!cpu_has(c, X86_FEATURE_CAT_L3))
> + if (!cpu_has(c, X86_FEATURE_CAT_L3)) {
> + rdt_root_group.css.ss->disabled = 1;
>   return -ENODEV;
> + }
> + maxid = c->x86_cache_max_closid;
> + max_cbm_len = c->x86_cache_max_cbm_len;
> +
> + sizeb = BITS_TO_LONGS(maxid) * sizeof(long);
> + rdtss_info.closmap = kzalloc(sizeb, GFP_KERNEL);
> + if (!rdtss_info.closmap) {
> + err = -ENOMEM;
> + goto out_err;
> + }
> +
> + sizeb = maxid * sizeof(struct clos_cbm_map);
> + ccmap = kzalloc(sizeb, GFP_KERNEL);
> + if (!ccmap) {
> + kfree(rdtss_info.closmap);
> + err = -ENOMEM;
> + goto out_err;
> + }

What's the expected size of max_closid? iow, how big of an array are you
in fact allocating here?
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [RFC PATCH 03/14] kthread: Add drain_kthread_worker()

[Tejun Heo]

Hello,

On Tue, Jul 28, 2015 at 04:39:20PM +0200, Petr Mladek wrote:
> +/*
> + * Test whether @work is being queued from another work
> + * executing on the same kthread.
> + */
> +static bool is_chained_work(struct kthread_worker *worker)
> +{
> + struct kthread_worker *current_worker;
> +
> + current_worker = current_kthread_worker();
> + /*
> +  * Return %true if I'm a kthread worker executing a work item on
> +  * the given @worker.
> +  */
> + return current_worker && current_worker == worker;
> +}

I'm not sure full-on chained work detection is necessary here.
kthread worker's usages tend to be significantly simpler and draining
is only gonna be used for destruction.

> +void drain_kthread_worker(struct kthread_worker *worker)
> +{
> + int flush_cnt = 0;
> +
> + spin_lock_irq(&worker->lock);
> + worker->nr_drainers++;
> +
> + while (!list_empty(&worker->work_list)) {
> + /*
> +  * Unlock, so we could move forward. Note that queuing
> +  * is limited by @nr_drainers > 0.
> +  */
> + spin_unlock_irq(&worker->lock);
> +
> + flush_kthread_worker(worker);
> +
> + if (++flush_cnt == 10 ||
> + (flush_cnt % 100 == 0 && flush_cnt <= 1000))
> + pr_warn("kthread worker %s: drain_kthread_worker() 
> isn't complete after %u tries\n",
> + worker->task->comm, flush_cnt);
> +
> + spin_lock_irq(&worker->lock);
> + }

I'd just do something like WARN_ONCE(flush_cnt++ > 10, "kthread worker: ...").

Thanks.

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

Re: [PATCH RFC 1/1] Documentation: describe how to add a system call

[Kees Cook]

On Tue, Jul 28, 2015 at 10:13 AM, David Drysdale  wrote:
> On Tue, Jul 28, 2015 at 5:43 PM, Kees Cook  wrote:
>> On Tue, Jul 28, 2015 at 4:41 AM, David Drysdale  wrote:
>>> Add a document describing the process of adding a new system call,
>>> including the need for a flags argument for future compatibility, and
>>> covering 32-bit/64-bit concerns (albeit in an x86-centric way).
>>>
>>> Signed-off-by: David Drysdale 
>>> Reviewed-by: Michael Kerrisk 
>>
>> This is great!
>>
>> Reviewed-by: Kees Cook 
>>
>> I have a few minor suggestions below...
>
> Thanks, I've applied all bar one -- a query below.
>
>>> ---
>>>  Documentation/adding-syscalls.txt | 454 
>>> ++
>>>  1 file changed, 454 insertions(+)
>>>  create mode 100644 Documentation/adding-syscalls.txt
>>>
>>> diff --git a/Documentation/adding-syscalls.txt 
>>> b/Documentation/adding-syscalls.txt
>>> new file mode 100644
>>> index ..5f52edda8951
>>> --- /dev/null
>>> +++ b/Documentation/adding-syscalls.txt
>
> [snip]
>
>>> + - If there is an existing capability that governs related functionality, 
>>> then
>>> +   use that.  However, avoid combining lots of only vaguely related 
>>> functions
>>> +   together under the same bit, as this goes against capabilities' purpose 
>>> of
>>> +   splitting the power of root.  In particular, avoid adding new uses of 
>>> the
>>> +   already overly-general CAP_SYS_ADMIN capability.
>>> + - If there is no related capability, then consider adding a new capability
>>> +   bit -- but bear in mind that the numbering space is limited, and each 
>>> new
>>> +   bit needs to be understood and administered by sysadmins.
>>
>> Perhaps mention alternative mechanisms for access control when working
>> on file descriptors, like avoiding security issues by looking at fd
>> _opener_ credentials, rather than current's credentials?
>
> I'm struggling to cope up with text about this that doesn't feel either
> too vague or much too detailed / internal, so maybe I'm misunderstanding
> what you're after.  Could you clarify or maybe suggest a sentence or two?

Hm, yes, I think you're right: my suggestion here was too specific.
Please ignore! :)

-Kees

-- 
Kees Cook
Chrome OS Security
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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: [Xen-devel] [PATCH 7/8] hvc/xen: Further s/MFN/GFN clean-up

[David Vrabel]

On 28/07/15 16:02, Julien Grall wrote:
> HVM_PARAM_CONSOLE_PFN is used to retrieved the console PFN for HVM
> guest. It returns a PFN (aka GFN) and not a MFN.
> 
> Furthermore, use directly virt_to_gfn for both PV and HVM domain rather
> than doing a special case for each of the them.

Reviewed-by: David Vrabel 

David
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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: [Xen-devel] [PATCH 4/8] xen: Use the correctly the Xen memory terminologies

[David Vrabel]

On 28/07/15 16:02, Julien Grall wrote:
> Based on include/xen/mm.h [1], Linux is mistakenly using MFN when GFN
> is meant, I suspect this is because the first support for Xen was for
> PV. This brough some misimplementation of helpers on ARM and make the
> developper confused the expected behavior.

For the benefit of other subsystem maintainers, this is a purely
mechanical change in Xen-specific terminology.  It doesn't need reviews
or acks from non-Xen people (IMO).

> For instance, with pfn_to_mfn, we expect to get an MFN based on the name.
> Although, if we look at the implementation on x86, it's returning a GFN.
> 
> For clarity and avoid new confusion, replace any reference of mfn into
> gnf in any helpers used by PV drivers.
> 
> Take also the opportunity to simplify simple construction such
> as pfn_to_mfn(page_to_pfn(page)) into page_to_gfn. More complex clean up
> will come in follow-up patches.
> 
> I think it may be possible to do further clean up in the x86 code to
> ensure that helpers returning machine address (such as virt_address) is
> not used by no auto-translated guests. I will let x86 xen expert doing
> it.

Reviewed-by: David Vrabel 

It looks a bit odd to use GFN in some of the PV code where the
hypervisor API uses MFN but overall I think using the correct
terminology where possible is best.  But I'd like to have Boris's or
Konrad's opinion on this.

David
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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: [Xen-devel] [PATCH 6/8] video/xen-fbfront: Further s/MFN/GFN clean-up

[David Vrabel]

On 28/07/15 16:02, Julien Grall wrote:
> The PV driver xen-fbfront is only dealing with GFN and not MFN. Rename
> all the occurence of MFN to GFN.
> 
> Also take the opportunity to replace to usage of pfn_to_gfn by
> page_to_pfn.

Reviewed-by: David Vrabel 

David
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] user_ns: use correct check for single-threadedness

[Kees Cook]

From: Ricky Zhou 

Checking mm_users > 1 does not mean a process is multithreaded. For
example, reading /proc/PID/maps temporarily increments mm_users, allowing
other processes to (accidentally) interfere with unshare() calls.

This fixes observed failures of unshare(CLONE_NEWUSER) incorrectly
returning EINVAL if another processes happened to be simultaneously
reading the maps file.

Signed-off-by: Ricky Zhou 
Signed-off-by: Kees Cook 
Cc: sta...@vger.kernel.org
---
 kernel/fork.c   | 4 ++--
 kernel/user_namespace.c | 3 ++-
 2 files changed, 4 insertions(+), 3 deletions(-)

diff --git a/kernel/fork.c b/kernel/fork.c
index dbd9b8d7b7cc..7d138f152dcd 100644
--- a/kernel/fork.c
+++ b/kernel/fork.c
@@ -75,6 +75,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include 
 #include 
@@ -1876,8 +1877,7 @@ static int check_unshare_flags(unsigned long 
unshare_flags)
 * needs to unshare vm.
 */
if (unshare_flags & (CLONE_THREAD | CLONE_SIGHAND | CLONE_VM)) {
-   /* FIXME: get_task_mm() increments ->mm_users */
-   if (atomic_read(¤t->mm->mm_users) > 1)
+   if (!current_is_single_threaded())
return -EINVAL;
}
 
diff --git a/kernel/user_namespace.c b/kernel/user_namespace.c
index 4109f8320684..7e0e021e4304 100644
--- a/kernel/user_namespace.c
+++ b/kernel/user_namespace.c
@@ -22,6 +22,7 @@
 #include 
 #include 
 #include 
+#include 
 
 static struct kmem_cache *user_ns_cachep __read_mostly;
 static DEFINE_MUTEX(userns_state_mutex);
@@ -977,7 +978,7 @@ static int userns_install(struct nsproxy *nsproxy, struct 
ns_common *ns)
return -EINVAL;
 
/* Threaded processes may not enter a different user namespace */
-   if (atomic_read(¤t->mm->mm_users) > 1)
+   if (!current_is_single_threaded())
return -EINVAL;
 
if (current->fs->users != 1)
-- 
1.9.1


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

Re: [PATCH RFC 1/1] Documentation: describe how to add a system call

[David Drysdale]

On Tue, Jul 28, 2015 at 5:43 PM, Kees Cook  wrote:
> On Tue, Jul 28, 2015 at 4:41 AM, David Drysdale  wrote:
>> Add a document describing the process of adding a new system call,
>> including the need for a flags argument for future compatibility, and
>> covering 32-bit/64-bit concerns (albeit in an x86-centric way).
>>
>> Signed-off-by: David Drysdale 
>> Reviewed-by: Michael Kerrisk 
>
> This is great!
>
> Reviewed-by: Kees Cook 
>
> I have a few minor suggestions below...

Thanks, I've applied all bar one -- a query below.

>> ---
>>  Documentation/adding-syscalls.txt | 454 
>> ++
>>  1 file changed, 454 insertions(+)
>>  create mode 100644 Documentation/adding-syscalls.txt
>>
>> diff --git a/Documentation/adding-syscalls.txt 
>> b/Documentation/adding-syscalls.txt
>> new file mode 100644
>> index ..5f52edda8951
>> --- /dev/null
>> +++ b/Documentation/adding-syscalls.txt

[snip]

>> + - If there is an existing capability that governs related functionality, 
>> then
>> +   use that.  However, avoid combining lots of only vaguely related 
>> functions
>> +   together under the same bit, as this goes against capabilities' purpose 
>> of
>> +   splitting the power of root.  In particular, avoid adding new uses of the
>> +   already overly-general CAP_SYS_ADMIN capability.
>> + - If there is no related capability, then consider adding a new capability
>> +   bit -- but bear in mind that the numbering space is limited, and each new
>> +   bit needs to be understood and administered by sysadmins.
>
> Perhaps mention alternative mechanisms for access control when working
> on file descriptors, like avoiding security issues by looking at fd
> _opener_ credentials, rather than current's credentials?

I'm struggling to cope up with text about this that doesn't feel either
too vague or much too detailed / internal, so maybe I'm misunderstanding
what you're after.  Could you clarify or maybe suggest a sentence or two?

Thanks,
David
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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: [Xen-devel] [PATCH v4 0/3] x86: modify_ldt improvement, test, and config option

[Boris Ostrovsky]

On 07/28/2015 01:07 PM, Andy Lutomirski wrote:

On Tue, Jul 28, 2015 at 9:30 AM, Andrew Cooper
 wrote:

I suspect that the set_ldt(NULL, 0) call hasn't reached Xen before
xen_free_ldt() is attempting to nab back the pages which Xen still has
mapped as an LDT.


I just instrumented it with yet more LSL instructions.  I'm pretty
sure that set_ldt really is clearing at least LDT entry zero.
Nonetheless the free_ldt call still oopses.



Yes, I added some instrumentation to the hypervisor and we definitely 
set LDT to NULL before failing.


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

[ANNOUNCE] Git v2.4.7

[Junio C Hamano]

The latest maintenance release Git v2.4.7 is now available at
the usual places.

The tarballs are found at:

https://www.kernel.org/pub/software/scm/git/

The following public repositories all have a copy of the 'v2.4.7'
tag and the 'maint' branch that the tag points at:

  url = https://kernel.googlesource.com/pub/scm/git/git
  url = git://repo.or.cz/alt-git.git
  url = https://code.google.com/p/git-core/
  url = git://git.sourceforge.jp/gitroot/git-core/git.git
  url = git://git-core.git.sourceforge.net/gitroot/git-core/git-core
  url = https://github.com/gitster/git



Git v2.4.7 Release Notes


Fixes since v2.4.6
--

 * A minor regression to "git fsck" in v2.2 era was fixed; it
   complained about a body-less tag object when it lacked a
   separator empty line after its header to separate it with a
   non-existent body.

 * We used to ask libCURL to use the most secure authentication method
   available when talking to an HTTP proxy only when we were told to
   talk to one via configuration variables.  We now ask libCURL to
   always use the most secure authentication method, because the user
   can tell libCURL to use an HTTP proxy via an environment variable
   without using configuration variables.

 * When you say "!" while running say "git log", you'd confuse
   yourself in the resulting shell, that may look as if you took
   control back to the original shell you spawned "git log" from but
   that isn't what is happening.  To that new shell, we leaked
   GIT_PAGER_IN_USE environment variable that was meant as a local
   communication between the original "Git" and subprocesses that was
   spawned by it after we launched the pager, which caused many
   "interesting" things to happen, e.g. "git diff | cat" still paints
   its output in color by default.

   Stop leaking that environment variable to the pager's half of the
   fork; we only need it on "Git" side when we spawn the pager.

 * Avoid possible ssize_t to int truncation.

 * "git config" failed to update the configuration file when the
   underlying filesystem is incapable of renaming a file that is still
   open.

 * A minor bugfix when pack bitmap is used with "rev-list --count".

 * An ancient test framework enhancement to allow color was not
   entirely correct; this makes it work even when tput needs to read
   from the ~/.terminfo under the user's real HOME directory.

 * Fix a small bug in our use of umask() return value.

 * "git rebase" did not exit with failure when format-patch it invoked
   failed for whatever reason.

 * Disable "have we lost a race with competing repack?" check while
   receiving a huge object transfer that runs index-pack.

Also contains typofixes, documentation updates and trivial code
clean-ups.



Changes since v2.4.6 are as follows:

Clemens Buchacher (1):
  rebase: return non-zero error code if format-patch fails

Enrique Tobis (1):
  http: always use any proxy auth method available

Jeff King (4):
  index-pack: avoid excessive re-reading of pack directory
  docs: clarify that --encoding can produce invalid sequences
  rev-list: disable --use-bitmap-index when pruning commits
  check_and_freshen_file: fix reversed success-check

Junio C Hamano (3):
  fsck: it is OK for a tag and a commit to lack the body
  pager: do not leak "GIT_PAGER_IN_USE" to the pager
  Git 2.4.7

Karsten Blees (1):
  config.c: fix writing config files on Windows network shares

Lawrence Siebert (1):
  rev-list: add --count to usage guide

Matthieu Moy (2):
  Documentation/branch: document -d --force and -m --force
  Documentation/branch: document -M and -D in terms of --force

Michael Haggerty (1):
  strbuf: strbuf_read_file() should return ssize_t

Richard Hansen (2):
  Revert "test-lib.sh: do tests for color support after changing HOME"
  test-lib.sh: fix color support when tput needs ~/.terminfo

Torsten Bögershausen (1):
  git-checkout.txt: document "git checkout " better

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] Generic VME UIO

[Martyn Welch]

Hi Dmitry,

On 22/07/15 19:09, Dmitry Kalinkin wrote:

Linux kernel has supported VME bus since 2009. The support comes in a form
of kernel driver API that is backed by a couple drivers for PCI-VME
bridges.  There is also a vme_user driver that provides a generic userpsace
interface to do data transfer and generate interrupts on the bus. Due to
specifics of the VME bus, this interface doesn't fit into the UIO
framework. The other useful feature is to be able to receive VME interrupts
in the userspace can, on the other hand, benefit from reusing UIO.

VME bus offers seven interrupt request lines IRQ1-IRQ7 corresponding to
seven interrupt levels.  In the event of interrupt, the interrupt handler
board is to prioritize interrupts in accordance to their levels.  The
interrupt handler then takes ownership over the data bus to perform an
interrupt acknowledge cycle where it supplies an interrupt level to be
acknowledged. When multiple interrupters are producing interrupt at the
same level, only one interrupt gets acknowledged based on interrupters
position in IACKIN/IACKOUT daisy- chain.  The response of the interrupter
to a relevant interrupt will contain a 8, 16 or 32 bit interrupt vector
(also called STATUS/ID). After the interrupt acknowledge cycle, the
interrupter is to remove it's interrupt request from the bus. Such
standartized scheme is called "Release On AcKnowledge" (ROAK).

Like PCI, VME has it's own corner case where interrupt request is removed
on VME device register access. VME specification acknowledges this
behaviour and calls it "Release On Register Access" (RORA) and requires
RORA devices to still provide interrupt vector value in acknowledge cycles.
I'm not aware how widespread the RORA devices are.



From memory all the hardware I've seen is RORA, but from talking to 
you, it seems you've had the opposite experience, so I suspect it might 
be quite market dependent.



The driver below provides a generic userspace interface to handle ROAK VME
device interrupts.

The user is to enable interrupt vectors through a sysfs interface. For
example, enabling handler for interrupt vector 0x6b at the level 1 will
look like:

   echo 1 > /sys/bus/vme/devices/vme_uio.0-0/irq/1/6b/enabled

A separate UIO device is created for each handler. Waiting for event can be
done as:

   dd if=/dev/uio0 bs=4 count=1

In response for this RFC I would like to hear your comments or suggestions
on the proposed sysfs interface, about the idea in general. Some tips on
how to better handle kobject cleanup are also very welcome.



Looks like a good start to me, please provide some documentation under 
Documentation/ before submitting (and please clearly state that it will 
only work for ROAK hardware!).



The vme_uio driver is provided separately for the ease of review, it's code
is intended for the merge into vme_user.

Signed-off-by: Dmitry Kalinkin 
Cc: Igor Alekseev 

---
  drivers/staging/vme/devices/Kconfig   |  10 +++
  drivers/staging/vme/devices/Makefile  |   1 +
  drivers/staging/vme/devices/vme_uio.c | 158 ++
  drivers/vme/vme_bridge.h  |   4 +-
  include/linux/vme.h   |   3 +
  5 files changed, 175 insertions(+), 1 deletion(-)
  create mode 100644 drivers/staging/vme/devices/vme_uio.c

diff --git a/drivers/staging/vme/devices/Kconfig 
b/drivers/staging/vme/devices/Kconfig
index 1d2ff0c..0300226 100644
--- a/drivers/staging/vme/devices/Kconfig
+++ b/drivers/staging/vme/devices/Kconfig
@@ -1,5 +1,15 @@
  comment "VME Device Drivers"

+config VME_UIO
+   tristate "VME UIO user space access driver"
+   depends on STAGING && VME_BUS && UIO
+   help
+Say Y here to include UIO interface to VME. This module currently
+allows you to deliver VME interrupts to user space.
+
+To compile this driver as a module, choose M here. The module will
+be called vme_uio. If unsure, say N.
+
  config VME_USER
tristate "VME user space access driver"
depends on STAGING
diff --git a/drivers/staging/vme/devices/Makefile 
b/drivers/staging/vme/devices/Makefile
index 172512c..c198004 100644
--- a/drivers/staging/vme/devices/Makefile
+++ b/drivers/staging/vme/devices/Makefile
@@ -2,6 +2,7 @@
  # Makefile for the VME device drivers.
  #

+obj-$(CONFIG_VME_UIO)  += vme_uio.o
  obj-$(CONFIG_VME_USER)+= vme_user.o

  vme_pio2-objs := vme_pio2_cntr.o vme_pio2_gpio.o vme_pio2_core.o
diff --git a/drivers/staging/vme/devices/vme_uio.c 
b/drivers/staging/vme/devices/vme_uio.c
new file mode 100644
index 000..4c55a23
--- /dev/null
+++ b/drivers/staging/vme/devices/vme_uio.c
@@ -0,0 +1,158 @@
+#include 
+#include 
+#include 
+#include 
+#include 
+
+static void vme_uio_int(int level, int status_id, void *priv)
+{
+   struct uio_info *info = priv;
+
+   uio_event_notify(info);
+}
+
+struct int_sysfs_entry {
+   struct kobj_attribute kobj_attr;
+   struct vme_dev *vdev;
+   struct uio_i

Re: vmemmap_verify() BUGs during memory hotplug (4.2-rc1 regression)

[David Vrabel]

On 27/07/15 16:41, Mel Gorman wrote:
> On Mon, Jul 27, 2015 at 04:32:45PM +0100, David Vrabel wrote:
>> Mel,
>>
>> As of commit 8a942fdea560d4ac0e9d9fabcd5201ad20e0c382 (mm: meminit: make
>> __early_pfn_to_nid SMP-safe and introduce meminit_pfn_in_nid)
>> vmemmap_verify() will BUG_ON() during memory hotplug because of its use
>> of early_pfn_to_nid().  Previously, it would have reported bogus (or
>> failed to report valid) warnings.
>>
> 
> Please test "mm, meminit: Allow early_pfn_to_nid to be used during
> runtime"

That fixed the BUG_ON() thanks.  But I still can't only the new sections
because their first page is not reserved, but I've not had time to
investigate why this is yet.

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

Re: [PATCH] mm: add resched points to remap_pmd_range/ioremap_pmd_range

[Jörn Engel]

On Tue, Jul 28, 2015 at 03:32:55PM +0200, Michal Hocko wrote:
> > 
> > We have kernel preemption disabled.  A lower-priority task in a system
> > call will block higher-priority tasks.
> 
> This is an inherent problem of !PREEMPT, though. There are many
> loops which can take quite some time but we do not want to sprinkle
> cond_resched all over the kernel. On the other hand these io/remap resp.
> vunmap page table walks do not have any cond_resched points AFAICS so we
> can at least mimic zap_pmd_range which does cond_resched.

Even for !PREEMPT we don't want infinite scheduler latencies.  Real
question is how much we are willing to accept and at what point we
should start sprinkling cond_resched.  I would pick 100ms, but that is
just a personal choice.  If we decide on 200ms or 500ms, I can live with
that too.

But whatever value we pick, I suspect these resched points need to go in
eventually.  As memory sizes grow, people will also start mapping bigger
regions and the scheduler latency will eventually exceed whatever value
we picked.

Jörn

--
Fools ignore complexity.  Pragmatists suffer it.
Some can avoid it.  Geniuses remove it.
-- Perlis's Programming Proverb #58, SIGPLAN Notices, Sept.  1982
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 1/5] iTCO_wdt: Expose watchdog properties using platform data

[Guenter Roeck]

On 07/28/2015 08:28 AM, Lee Jones wrote:

On Tue, 28 Jul 2015, Guenter Roeck wrote:


On 07/28/2015 08:00 AM, Lee Jones wrote:

On Tue, 28 Jul 2015, Matt Fleming wrote:

On Tue, 28 Jul, at 12:37:21PM, Lee Jones wrote:


The driver shouldn't be called that either.

You are the only one.  What makes iTCO 'special'?


I don't know, I didn't write it. It looks like Wim did ~9 years ago, so
it must have made sense to him at the time.



Coding style wasn't as strict then as it is today. iTCO has just been kept
for historic reasons.


For sure, I get that, but it doesn't mean we can't do-the-right-thing
(tm) now does it?


Sure, we could have changed it to lowercase, but so far no one bothered.
Plus, of course, there is always the element that some maintainers hate
that kind of cleanup,


Really?  Surely any kind of clean-up is good clean-up.  Especially as
Greg KH et. al, have been doing public presentations telling everyone
that there is always kernel work for anyone who has the time; spelling
corrections and all.



Yes, really. Just try to submit cleanup patches to maintainers other than
Greg and myself, and you'll see. It is a minefield.

Guenter

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

Re: [PATCH 4/6] pci: altera: Add Altera PCIe MSI driver

[Dinh Nguyen]

On Tue, Jul 28, 2015 at 5:45 AM, Ley Foon Tan  wrote:
> This patch adds Altera PCIe MSI driver. This soft IP supports configurable
> number of vectors, which is a dts parameter.
>
> Signed-off-by: Ley Foon Tan 
> ---
>  drivers/pci/host/Kconfig   |   7 +
>  drivers/pci/host/Makefile  |   1 +
>  drivers/pci/host/pcie-altera-msi.c | 318 
> +
>  3 files changed, 326 insertions(+)
>  create mode 100644 drivers/pci/host/pcie-altera-msi.c
>
> diff --git a/drivers/pci/host/Kconfig b/drivers/pci/host/Kconfig
> index af19039..a8b87fd 100644
> --- a/drivers/pci/host/Kconfig
> +++ b/drivers/pci/host/Kconfig
> @@ -154,4 +154,11 @@ config PCIE_ALTERA
>   Say Y here if you want to enable PCIe controller support for Altera
>   SoCFPGA family of SoCs.
>
> +config PCIE_ALTERA_MSI
> +   bool "Altera PCIe MSI feature"
> +   depends on PCI_MSI && PCIE_ALTERA
> +   help
> + Say Y here if you want PCIe MSI support for the Altera SocFPGA SoC.
> + This MSI driver supports Altera MSI to GIC controller IP.
> +

Couldn't this driver get combined with the pcie-altera driver?

Dinh
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] Doc: x86: Fix typo in intel_mpx.txt

[Randy Dunlap]

On 07/28/15 04:00, Masanari Iida wrote:
> This patch fix some spelling typos in intel_mpx.txt
> 
> Signed-off-by: Masanari Iida 
> ---
>  Documentation/x86/intel_mpx.txt | 8 
>  1 file changed, 4 insertions(+), 4 deletions(-)
> 
> diff --git a/Documentation/x86/intel_mpx.txt b/Documentation/x86/intel_mpx.txt
> index 818518a..5cc98d5 100644
> --- a/Documentation/x86/intel_mpx.txt
> +++ b/Documentation/x86/intel_mpx.txt
> @@ -45,7 +45,7 @@ is how we expect the compiler, application and kernel to 
> work together.
> MPX-instrumented.
>  3) The kernel detects that the CPU has MPX, allows the new prctl() to
> succeed, and notes the location of the bounds directory. Userspace is
> -   expected to keep the bounds directory at that locationWe note it
> +   expected to keep the bounds directory at that location We note it

at that location. We

> instead of reading it each time because the 'xsave' operation needed
> to access the bounds directory register is an expensive operation.
>  4) If the application needs to spill bounds out of the 4 registers, it
> @@ -151,7 +151,7 @@ A: This would work if we could hook the site of each and 
> every memory
> these calls.
>  
>  Q: Could a bounds fault be handed to userspace and the tables allocated
> -   there in a signal handler intead of in the kernel?
> +   there in a signal handler instead of in the kernel?
>  A: mmap() is not on the list of safe async handler functions and even
> if mmap() would work it still requires locking or nasty tricks to
> keep track of the allocation state there.
> @@ -167,7 +167,7 @@ If a #BR is generated due to a bounds violation caused by 
> MPX.
>  We need to decode MPX instructions to get violation address and
>  set this address into extended struct siginfo.
>  
> -The _sigfault feild of struct siginfo is extended as follow:
> +The _sigfault field of struct siginfo is extended as follow:

 as follows:

>  
>  87   /* SIGILL, SIGFPE, SIGSEGV, SIGBUS */
>  88   struct {
> @@ -240,5 +240,5 @@ them at the same bounds table.
>  This is allowed architecturally.  See more information "Intel(R) Architecture
>  Instruction Set Extensions Programming Reference" (9.3.4).
>  
> -However, if users did this, the kernel might be fooled in to unmaping an
> +However, if users did this, the kernel might be fooled in to unmapping an

  into

>  in-use bounds table since it does not recognize sharing.
> 


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

Re: [PATCH v4 0/3] x86: modify_ldt improvement, test, and config option

[Andy Lutomirski]

On Tue, Jul 28, 2015 at 9:30 AM, Andrew Cooper
 wrote:
> I suspect that the set_ldt(NULL, 0) call hasn't reached Xen before
> xen_free_ldt() is attempting to nab back the pages which Xen still has
> mapped as an LDT.
>

I just instrumented it with yet more LSL instructions.  I'm pretty
sure that set_ldt really is clearing at least LDT entry zero.
Nonetheless the free_ldt call still oopses.

--Andy

> ~Andrew



-- 
Andy Lutomirski
AMA Capital Management, LLC
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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/9] x86/intel_rdt: Add new cgroup and Class of service management

[Peter Zijlstra]

On Wed, Jul 01, 2015 at 03:21:06PM -0700, Vikas Shivappa wrote:
> +struct clos_cbm_map {
> + unsigned long cache_mask;
> + unsigned int clos_refcnt;
> +};

This structure is not a map at all, its the map value. Furthermore,
cache_mask seems a confusing name for the capacity bitmask (CBM).
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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: Is devm_* broken ?

[Laurent Pinchart]

On Tuesday 28 July 2015 11:22:25 Tejun Heo wrote:
> On Tue, Jul 28, 2015 at 05:16:16PM +0300, Laurent Pinchart wrote:
> > Using devm_kzalloc() in such a way has value though, and reverting drivers
> > to the pre-devm memory allocation code would make error handling and
> > cleanup code paths more complex again. Should we introduce a managed
> > allocator for that purpose that would have a lifespan explicitly handled
> > by drivers ?
>
> I don't know.  Sure, we can have memory allocations which are tied to
> open file; however, the distinction between that and regular devm
> resources, which can't linger on no matter what, would be subtle and
> confusing.  IMHO, a better approach would be implmenting generic
> revoke feature and sever open files on driver detach so that
> everything can be shutdown then.

Sounds like a topic for the kernel summit :-) I'll send a proposal.

-- 
Regards,

Laurent Pinchart

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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 char-misc-next 10/19] lib: convert iova.c into a library

[Sudeep Dutt]

On Tue, 2015-07-28 at 15:38 +0100, David Woodhouse wrote:
> On Tue, 2015-07-28 at 11:41 +0100, Robin Murphy wrote:
> > On 28/07/15 11:03, Joerg Roedel wrote:
> > > On Mon, Jul 27, 2015 at 04:57:32PM -0700, Ashutosh Dixit wrote:
> > > > From: Harish Chegondi 
> > > > 
> > > > This patch converts iova.c into a library, moving it from
> > > > drivers/iommu/ to lib/, and exports its virtual address 
> > > > allocation and
> > > > management functions so that other modules can reuse them.
> > > > 
> > > > Cc: Joerg Roedel 
> > > > Reviewed-by: Anil S Keshavamurthy  > > > >
> > > > Reviewed-by: Sudeep Dutt 
> > > > Signed-off-by: Harish Chegondi 
> > > 
> > > Where is this going to be used outside of the IOMMU world?
> > > 

We are using the IOVA generator in the SCIF driver posted @
http://thread.gmane.org/gmane.linux.kernel/2005895 under
drivers/misc/mic/scif

> > 
> > ...and how does it relate to the patches from Sakari (+CC) doing much 
> > the same thing[1]?
> 

The patch series from Sakari does the right thing by moving the IOVA
cache management to the IOVA library. We will simply drop this current
patch as it is incorrect.

> I merged Sakari's patches into the intel-iommu git tree today, FWIW.
> 
> If there's really a need to move it from drivers/iommu/ to lib/ then we
> could feasibly do that too.
> 

The patch series from Sakari should work perfectly for us. We will post
a v2 of the current SCIF patch series without this IOVA patch and modify
the SCIF driver to use the newly added iova_cache_get(..) and
iova_cache_put(..) APIs once it is available in Linus's tree. It would
make it easier for us to integrate if Sakari's patches reach mainline
soon.

It might be cleaner to move IOVA to lib/ in the longer term since we
will have multiple driver subsystems using it, but it should work just
fine for now.

Thanks for the review!

Sudeep Dutt

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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/8] jump_label: Add a new static_key interface

[Rabin Vincent]

On Tue, Jul 28, 2015 at 03:21:01PM +0200, Peter Zijlstra wrote:
> --- a/arch/arm/include/asm/jump_label.h
> +++ b/arch/arm/include/asm/jump_label.h
> @@ -7,20 +7,28 @@
>  
>  #define JUMP_LABEL_NOP_SIZE 4
>  
> -#ifdef CONFIG_THUMB2_KERNEL
> -#define JUMP_LABEL_NOP   "nop.w"
> -#else
> -#define JUMP_LABEL_NOP   "nop"
> -#endif
> +static __always_inline bool arch_static_branch(struct static_key *key, bool 
> branch)
> +{
> + asm_volatile_goto("1:\n\t"
> +  WASM(nop) "\n\t"
> +  ".pushsection __jump_table,  \"aw\"\n\t"
> +  ".word 1b, %l[l_yes], %c0\n\t"
> +  ".popsection\n\t"
> +  : :  "i" (&((char *)key)[branch]) :  : l_yes);
> +
> + return false;
> +l_yes:
> + return true;
> +}
>  
> -static __always_inline bool arch_static_branch(struct static_key *key)
> +static __always_inline bool arch_static_branch_jump(struct static_key *key, 
> bool branch)
>  {
>   asm_volatile_goto("1:\n\t"
> -  JUMP_LABEL_NOP "\n\t"
> +  WASM(b) " %l[l_yes]\n\t"
>".pushsection __jump_table,  \"aw\"\n\t"
>".word 1b, %l[l_yes], %c0\n\t"
>".popsection\n\t"
> -  : :  "i" (key) :  : l_yes);
> +  : :  "i" (&((char *)key)[branch]) :  : l_yes);
>  
>   return false;
>  l_yes:

This is missing an include of asm/unified.h for the WASM():

diff --git a/arch/arm/include/asm/jump_label.h 
b/arch/arm/include/asm/jump_label.h
index f8bc12f..34f7b69 100644
--- a/arch/arm/include/asm/jump_label.h
+++ b/arch/arm/include/asm/jump_label.h
@@ -4,6 +4,7 @@
 #ifndef __ASSEMBLY__
 
 #include 
+#include 
 
 #define JUMP_LABEL_NOP_SIZE 4

With that added, it builds and works fine on ARM.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Please can I trust you?

[Brice Adams]

My Dear Friend,

I am Mr. Brice Adams, staff and auditor of a Bank in Lome, Togo
Republic. I am the Account Officer to (Late Mr. Daniel I. Glade) whose
account is presently dormant, I advise you to keep this as a "top
secret" as I am still in service and intend to retire from service
after I conclude this deal with you. I have an important
Message/discussion with you about his death and his funds, the sum of
(6.5 Million Euros) left without a heir. If you can be of an
assistance to me, I will be pleased to offer to you 25% of the total
fund. Please I got your email contact through internet email directory
when I was searching for a trust worthy partner. If you are willing to
help me, I need the following information below from you;

Your full name.
Nationality
Telephone number..
Profession.
Age.

I will be humbly waiting your soonest response. Please contact direct
to my email address (brice2ad...@yahoo.fr) for more information.

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

Re: [PATCH v5 4/4] x86/ldt: Make modify_ldt optional

[Kees Cook]

On Mon, Jul 27, 2015 at 10:29 PM, Andy Lutomirski  wrote:
> The modify_ldt syscall exposes a large attack surface and is
> unnecessary for modern userspace.  Make it optional.
>
> Signed-off-by: Andy Lutomirski 

Reviewed-by: Kees Cook 

> ---
>  arch/x86/Kconfig   | 17 +
>  arch/x86/include/asm/mmu.h |  2 ++
>  arch/x86/include/asm/mmu_context.h | 31 +++
>  arch/x86/kernel/Makefile   |  3 ++-
>  arch/x86/kernel/cpu/perf_event.c   |  4 
>  arch/x86/kernel/process_64.c   |  2 ++
>  arch/x86/kernel/step.c |  2 ++
>  kernel/sys_ni.c|  1 +
>  8 files changed, 53 insertions(+), 9 deletions(-)
>
> diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig
> index b3a1a5d77d92..ede52be845db 100644
> --- a/arch/x86/Kconfig
> +++ b/arch/x86/Kconfig
> @@ -1015,6 +1015,7 @@ config VM86
>  config X86_16BIT
> bool "Enable support for 16-bit segments" if EXPERT
> default y
> +   depends on MODIFY_LDT_SYSCALL
> ---help---
>   This option is required by programs like Wine to run 16-bit
>   protected mode legacy code on x86 processors.  Disabling
> @@ -2053,6 +2054,22 @@ config CMDLINE_OVERRIDE
>   This is used to work around broken boot loaders.  This should
>   be set to 'N' under normal conditions.
>
> +config MODIFY_LDT_SYSCALL
> +   bool "Enable the LDT (local descriptor table)" if EXPERT
> +   default y
> +   ---help---
> + Linux can allow user programs to install a per-process x86

nit: looks like a spaces vs tabs issue in the line above?

> +Local Descriptor Table (LDT) using the modify_ldt(2) system
> +call.  This is required to run 16-bit or segmented code such as
> +DOSEMU or some Wine programs.  It is also used by some very old
> +threading libraries.
> +
> +Enabling this feature adds a small amount of overhead to
> +context switches and increases the low-level kernel attack
> +surface.  Disabling it removes the modify_ldt(2) system call.
> +
> +Saying 'N' here may make sense for embedded or server kernels.
> +
>  source "kernel/livepatch/Kconfig"
>
>  endmenu
> diff --git a/arch/x86/include/asm/mmu.h b/arch/x86/include/asm/mmu.h
> index 364d27481a52..55234d5e7160 100644
> --- a/arch/x86/include/asm/mmu.h
> +++ b/arch/x86/include/asm/mmu.h
> @@ -9,7 +9,9 @@
>   * we put the segment information here.
>   */
>  typedef struct {
> +#ifdef CONFIG_MODIFY_LDT_SYSCALL
> struct ldt_struct *ldt;
> +#endif
>
>  #ifdef CONFIG_X86_64
> /* True if mm supports a task running in 32 bit compatibility mode. */
> diff --git a/arch/x86/include/asm/mmu_context.h 
> b/arch/x86/include/asm/mmu_context.h
> index 3fcff70c398e..08094eded318 100644
> --- a/arch/x86/include/asm/mmu_context.h
> +++ b/arch/x86/include/asm/mmu_context.h
> @@ -33,6 +33,7 @@ static inline void load_mm_cr4(struct mm_struct *mm)
>  static inline void load_mm_cr4(struct mm_struct *mm) {}
>  #endif
>
> +#ifdef CONFIG_MODIFY_LDT_SYSCALL
>  /*
>   * ldt_structs can be allocated, used, and freed, but they are never
>   * modified while live.
> @@ -48,10 +49,24 @@ struct ldt_struct {
> int size;
>  };
>
> +/*
> + * Used for LDT copy/destruction.
> + */
> +int init_new_context(struct task_struct *tsk, struct mm_struct *mm);
> +void destroy_context(struct mm_struct *mm);
> +#else  /* CONFIG_MODIFY_LDT_SYSCALL */
> +static inline int init_new_context(struct task_struct *tsk,
> +  struct mm_struct *mm)
> +{
> +   return 0;
> +}
> +static inline void destroy_context(struct mm_struct *mm) {}
> +#endif
> +
>  static inline void load_mm_ldt(struct mm_struct *mm)
>  {
> +#ifdef CONFIG_MODIFY_LDT_SYSCALL
> struct ldt_struct *ldt;
> -   DEBUG_LOCKS_WARN_ON(!irqs_disabled());
>
> /* lockless_dereference synchronizes with smp_store_release */
> ldt = lockless_dereference(mm->context.ldt);
> @@ -74,14 +89,12 @@ static inline void load_mm_ldt(struct mm_struct *mm)
> set_ldt(ldt->entries, ldt->size);
> else
> clear_LDT();
> -}
> -
> -/*
> - * Used for LDT copy/destruction.
> - */
> -int init_new_context(struct task_struct *tsk, struct mm_struct *mm);
> -void destroy_context(struct mm_struct *mm);
> +#else
> +   clear_LDT();
> +#endif
>
> +   DEBUG_LOCKS_WARN_ON(!irqs_disabled());
> +}
>
>  static inline void enter_lazy_tlb(struct mm_struct *mm, struct task_struct 
> *tsk)
>  {
> @@ -113,6 +126,7 @@ static inline void switch_mm(struct mm_struct *prev, 
> struct mm_struct *next,
> /* Load per-mm CR4 state */
> load_mm_cr4(next);
>
> +#ifdef CONFIG_MODIFY_LDT_SYSCALL
> /*
>  * Load the LDT, if the LDT is different.
>  *
> @@ -127,6 +141,7 @@ static inline void switch_mm(struct mm_struct *prev, 
> struct mm_struct *next,
>   

Please can I trust you?

[Brice Adams]

My Dear Friend,

I am Mr. Brice Adams, staff and auditor of a Bank in Lome, Togo
Republic. I am the Account Officer to (Late Mr. Daniel I. Glade) whose
account is presently dormant, I advise you to keep this as a "top
secret" as I am still in service and intend to retire from service
after I conclude this deal with you. I have an important
Message/discussion with you about his death and his funds, the sum of
(6.5 Million Euros) left without a heir. If you can be of an
assistance to me, I will be pleased to offer to you 25% of the total
fund. Please I got your email contact through internet email directory
when I was searching for a trust worthy partner. If you are willing to
help me, I need the following information below from you;

Your full name.
Nationality
Telephone number..
Profession.
Age.

I will be humbly waiting your soonest response. Please contact direct
to my email address (brice2ad...@yahoo.fr) for more information.

With Respect,
Mr. Brice Adams.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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 0/2] VFIO: Add virtual MSI doorbell support.

[Marc Zyngier]

Hi Alex,

On 28/07/15 17:21, Alex Williamson wrote:
> On Fri, 2015-07-24 at 14:33 +0530, Pranavkumar Sawargaonkar wrote:
>> In current VFIO MSI/MSI-X implementation, linux host kernel
>> allocates MSI/MSI-X vectors when userspace requests through vfio ioctls.
>> Vfio creates irqfd mappings to notify MSI/MSI-X interrupts
>> to the userspace when raised.
>> Guest OS will see emulated MSI/MSI-X controller and receives an interrupt
>> when kernel notifies the same via irqfd.
>>
>> Host kernel allocates MSI/MSI-X using standard linux routines
>> like pci_enable_msix_range() and pci_enable_msi_range(). 
>> These routines along with requset_irq() in host kernel sets up 
>> MSI/MSI-X vectors with Physical MSI/MSI-X addresses provided by
>> interrupt controller driver in host kernel.
>>
>> This means when a device is assigned with the guest OS, MSI/MSI-X addresses
>> present in PCIe EP are the PAs programmed by the host linux kernel.
>>
>> In x86 MSI/MSI-X physical address range is reserved and iommu is aware
>> about these addreses and transalation is bypassed for these address range.
>>
>> Unlike x86, ARM/ARM64 does not reserve MSI/MSI-X Physical address range and
>> all the transactions including MSI go through iommu/smmu without bypass.
>> This requires extending current vfio MSI layer with additional functionality
>> for ARM/ARM64 by
>> 1. Programing IOVA (referred as a MSI virtual doorbell address)
>>in device's MSI vector as a MSI address.
>>This IOVA will be provided by the userspace based on the
>>MSI/MSI-X addresses reserved for the guest.
>> 2. Create an IOMMU mapping between this IOVA and
>>Physical address (PA) assigned to the MSI vector.
>>
>> This RFC is proposing a solution for MSI/MSI-X passthrough for ARM/ARM64.
> 
> 
> Hi Pranavkumar,
> 
> Freescale has the same, or very similar, need, so any solution in this
> space will need to work for both ARM and powerpc.  I'm not a big fan of
> this approach as it seems to require the user to configure MSI/X via
> ioctl and then call a separate ioctl mapping the doorbells.  That's more
> code for the user, more code to get wrong and potentially a gap between
> configuring MSI/X and enabling mappings where we could see IOMMU faults.
> 
> If we know that doorbell mappings are required, why can't we set aside a
> bank of IOVA space and have them mapped automatically as MSI/X is being
> configured?  Then the user's need for special knowledge and handling of
> this case is limited to setup.  The IOVA space will be mapped and used
> as needed, we only need the user to specify the IOVA space reserved for
> this.  Thanks,

I guess my immediate worry is that it seems to impose a fixed mapping
for all the guests, which would restrict the "shape" of the mappings we
give to a guest. Or did you intend for that IOVA mapping to be defined
on a "per userspace instance" basis?

Thanks,

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

Re: [PATCH v5 3/4] selftests/x86, x86/ldt: Add a selftest for modify_ldt

[Kees Cook]

On Mon, Jul 27, 2015 at 10:29 PM, Andy Lutomirski  wrote:
> This tests general modify_ldt behavior (only writes, so far) as
> well as synchronous updates via IPI.  It fails on old kernels.
>
> I called this ldt_gdt because I'll add set_thread_area tests to
> it at some point.
>
> Signed-off-by: Andy Lutomirski 

Looks great!

Reviewed-by: Kees Cook 

-Kees

> ---
>  tools/testing/selftests/x86/Makefile  |   2 +-
>  tools/testing/selftests/x86/ldt_gdt.c | 520 
> ++
>  2 files changed, 521 insertions(+), 1 deletion(-)
>  create mode 100644 tools/testing/selftests/x86/ldt_gdt.c
>
> diff --git a/tools/testing/selftests/x86/Makefile 
> b/tools/testing/selftests/x86/Makefile
> index caa60d56d7d1..4138387b892c 100644
> --- a/tools/testing/selftests/x86/Makefile
> +++ b/tools/testing/selftests/x86/Makefile
> @@ -4,7 +4,7 @@ include ../lib.mk
>
>  .PHONY: all all_32 all_64 warn_32bit_failure clean
>
> -TARGETS_C_BOTHBITS := sigreturn single_step_syscall sysret_ss_attrs
> +TARGETS_C_BOTHBITS := sigreturn single_step_syscall sysret_ss_attrs ldt_gdt
>  TARGETS_C_32BIT_ONLY := entry_from_vm86
>
>  TARGETS_C_32BIT_ALL := $(TARGETS_C_BOTHBITS) $(TARGETS_C_32BIT_ONLY)
> diff --git a/tools/testing/selftests/x86/ldt_gdt.c 
> b/tools/testing/selftests/x86/ldt_gdt.c
> new file mode 100644
> index ..c27adfc9ae72
> --- /dev/null
> +++ b/tools/testing/selftests/x86/ldt_gdt.c
> @@ -0,0 +1,520 @@
> +/*
> + * ldt_gdt.c - Test cases for LDT and GDT access
> + * Copyright (c) 2015 Andrew Lutomirski
> + */
> +
> +#define _GNU_SOURCE
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +#define AR_ACCESSED(1<<8)
> +
> +#define AR_TYPE_RODATA (0 * (1<<9))
> +#define AR_TYPE_RWDATA (1 * (1<<9))
> +#define AR_TYPE_RODATA_EXPDOWN (2 * (1<<9))
> +#define AR_TYPE_RWDATA_EXPDOWN (3 * (1<<9))
> +#define AR_TYPE_XOCODE (4 * (1<<9))
> +#define AR_TYPE_XRCODE (5 * (1<<9))
> +#define AR_TYPE_XOCODE_CONF(6 * (1<<9))
> +#define AR_TYPE_XRCODE_CONF(7 * (1<<9))
> +
> +#define AR_DPL3(3 * (1<<13))
> +
> +#define AR_S   (1 << 12)
> +#define AR_P   (1 << 15)
> +#define AR_AVL (1 << 20)
> +#define AR_L   (1 << 21)
> +#define AR_DB  (1 << 22)
> +#define AR_G   (1 << 23)
> +
> +static int nerrs;
> +
> +static void check_invalid_segment(uint16_t index, int ldt)
> +{
> +   uint32_t has_limit = 0, has_ar = 0, limit, ar;
> +   uint32_t selector = (index << 3) | (ldt << 2) | 3;
> +
> +   asm ("lsl %[selector], %[limit]\n\t"
> +"jnz 1f\n\t"
> +"movl $1, %[has_limit]\n\t"
> +"1:"
> +: [limit] "=r" (limit), [has_limit] "+rm" (has_limit)
> +: [selector] "r" (selector));
> +   asm ("larl %[selector], %[ar]\n\t"
> +"jnz 1f\n\t"
> +"movl $1, %[has_ar]\n\t"
> +"1:"
> +: [ar] "=r" (ar), [has_ar] "+rm" (has_ar)
> +: [selector] "r" (selector));
> +
> +   if (has_limit || has_ar) {
> +   printf("[FAIL]\t%s entry %hu is valid but should be 
> invalid\n",
> +  (ldt ? "LDT" : "GDT"), index);
> +   nerrs++;
> +   } else {
> +   printf("[OK]\t%s entry %hu is invalid\n",
> +  (ldt ? "LDT" : "GDT"), index);
> +   }
> +}
> +
> +static void check_valid_segment(uint16_t index, int ldt,
> +   uint32_t expected_ar, uint32_t expected_limit,
> +   bool verbose)
> +{
> +   uint32_t has_limit = 0, has_ar = 0, limit, ar;
> +   uint32_t selector = (index << 3) | (ldt << 2) | 3;
> +
> +   asm ("lsl %[selector], %[limit]\n\t"
> +"jnz 1f\n\t"
> +"movl $1, %[has_limit]\n\t"
> +"1:"
> +: [limit] "=r" (limit), [has_limit] "+rm" (has_limit)
> +: [selector] "r" (selector));
> +   asm ("larl %[selector], %[ar]\n\t"
> +"jnz 1f\n\t"
> +"movl $1, %[has_ar]\n\t"
> +"1:"
> +: [ar] "=r" (ar), [has_ar] "+rm" (has_ar)
> +: [selector] "r" (selector));
> +
> +   if (!has_limit || !has_ar) {
> +   printf("[FAIL]\t%s entry %hu is invalid but should be 
> valid\n",
> +  (ldt ? "LDT" : "GDT"), index);
> +   nerrs++;
> +   return;
> +   }
> +
> +   if (ar != expected_ar) {
> +   printf("[FAIL]\t%s entry %hu has AR 0x%08X but expected 
> 0x%08X\n",
> +  (ldt ? "LDT" : "GDT"), index, ar, expected_ar);
> +   nerrs++;
> +   } else if (limit != expected_limit) {
> +   printf("[FAIL]\t%s entry %hu has lim

[3.13.y-ckt stable] Linux 3.13.11-ckt24

[Kamal Mostafa]

I am announcing the release of the Linux 3.13.11-ckt24 kernel.

The updated 3.13.y-ckt tree can be found at: 
  git://kernel.ubuntu.com/ubuntu/linux.git linux-3.13.y
and can be browsed at:
http://kernel.ubuntu.com/git/ubuntu/linux.git/log/?h=linux-3.13.y

The diff from v3.13.11-ckt23 is posted as a follow-up to this email.

The 3.13.y-ckt extended stable tree is maintained by the Canonical Kernel Team.
For more info, see https://wiki.ubuntu.com/Kernel/Dev/ExtendedStable

 -Kamal

-- 
 .../bindings/net/marvell-armada-370-neta.txt   |   2 +-
 .../pinctrl/marvell,armada-370-pinctrl.txt |   4 +-
 .../bindings/pinctrl/marvell,armada-xp-pinctrl.txt |  32 ++--
 Makefile   |   2 +-
 arch/arc/include/asm/cmpxchg.h |   9 +-
 arch/arm/kvm/interrupts.S  |  10 +-
 arch/arm/kvm/interrupts_head.S |  20 ++-
 arch/arm64/kernel/vdso/Makefile|   4 +
 arch/arm64/mm/context.c|   8 +
 arch/arm64/mm/hugetlbpage.c|   4 +-
 arch/arm64/mm/init.c   |   2 +-
 arch/mips/include/asm/mach-generic/spaces.h|   4 +
 arch/mips/kvm/kvm_mips.c   |   2 +-
 arch/powerpc/perf/core-book3s.c|  11 +-
 arch/powerpc/platforms/pseries/dlpar.c |   3 +-
 arch/sparc/kernel/ldc.c|   2 +-
 arch/x86/include/asm/kvm_host.h|   2 +-
 arch/x86/kvm/i8254.c   |   2 +-
 arch/x86/kvm/lapic.c   |   5 +-
 arch/x86/pci/acpi.c|  11 ++
 drivers/acpi/acpica/utxfinit.c |  10 +-
 drivers/acpi/osl.c |   6 +-
 drivers/acpi/resource.c| 162 +
 drivers/ata/libata-core.c  |   2 +-
 drivers/base/regmap/regmap.c   |   5 +-
 drivers/block/rbd.c|   4 +-
 drivers/bluetooth/ath3k.c  |  12 ++
 drivers/bluetooth/btusb.c  |   8 +
 drivers/char/agp/intel-gtt.c   |   2 +-
 drivers/char/tpm/tpm_ibmvtpm.c |   5 +-
 drivers/clocksource/exynos_mct.c   |  43 --
 drivers/crypto/talitos.c   |   4 +-
 drivers/dma/mv_xor.c   |  72 +
 drivers/dma/mv_xor.h   |   1 +
 drivers/gpu/drm/qxl/qxl_cmd.c  |   1 +
 drivers/gpu/drm/qxl/qxl_ioctl.c|   4 +-
 drivers/gpu/drm/radeon/cik.c   |  34 +
 drivers/gpu/drm/radeon/cik_sdma.c  |  11 ++
 drivers/gpu/drm/radeon/radeon_irq_kms.c|   2 +
 drivers/hid/i2c-hid/i2c-hid.c  |   6 +-
 drivers/hwmon/mcp3021.c|  14 +-
 drivers/i2c/busses/i2c-at91.c  |  70 ++---
 drivers/i2c/i2c-mux.c  |   2 +-
 drivers/i2c/muxes/i2c-mux-pca9541.c|   4 +-
 drivers/i2c/muxes/i2c-mux-pca954x.c|   2 +-
 drivers/iommu/amd_iommu.c  |   6 +
 drivers/leds/led-class.c   |   7 +-
 drivers/md/dm-stats.c  |   2 +
 drivers/md/persistent-data/dm-space-map-metadata.c |  50 +--
 drivers/media/dvb-frontends/af9013.c   |   4 +
 drivers/media/dvb-frontends/cx24116.c  |   8 +-
 drivers/media/dvb-frontends/cx24117.c  |   2 +-
 drivers/media/dvb-frontends/s5h1420.c  |   2 +-
 drivers/mmc/card/block.c   |   8 +-
 drivers/mtd/maps/dc21285.c |   4 +-
 drivers/mtd/mtd_blkdevs.c  |   5 +
 drivers/net/ethernet/marvell/mvneta.c  |  27 +++-
 drivers/net/wireless/ath/ath9k/main.c  |  12 +-
 drivers/net/wireless/rndis_wlan.c  |   6 +-
 drivers/of/base.c  |   2 +-
 drivers/pcmcia/topic.h |  16 ++
 drivers/pinctrl/mvebu/pinctrl-armada-370.c |   4 +-
 drivers/pinctrl/mvebu/pinctrl-armada-xp.c  |  37 ++---
 drivers/platform/x86/dell-laptop.c |   8 +-
 drivers/platform/x86/ideapad-laptop.c  |   3 +-
 drivers/pnp/system.c   |  35 +++--
 drivers/regulator/core.c   |   2 +-
 drivers/s390/kvm/virtio_ccw.c  |  11 +-
 drivers/scsi/ipr.h |   2 +-
 drivers/scsi/scsi_transport_srp.c  |  57 +---
 drivers/spi/spi.c  |  11 +-
 drivers/staging/rtl8712/rtl8712_recv.c |   3 +-
 drivers/staging/vt6655/device_main.c   |   4 +
 dr

Re: [3.13.y-ckt stable] Linux 3.13.11-ckt24

[Kamal Mostafa]

diff --git a/Documentation/devicetree/bindings/net/marvell-armada-370-neta.txt 
b/Documentation/devicetree/bindings/net/marvell-armada-370-neta.txt
index 859a6fa..0856c9a 100644
--- a/Documentation/devicetree/bindings/net/marvell-armada-370-neta.txt
+++ b/Documentation/devicetree/bindings/net/marvell-armada-370-neta.txt
@@ -1,7 +1,7 @@
 * Marvell Armada 370 / Armada XP Ethernet Controller (NETA)
 
 Required properties:
-- compatible: should be "marvell,armada-370-neta".
+- compatible: "marvell,armada-370-neta" or "marvell,armada-xp-neta".
 - reg: address and length of the register set for the device.
 - interrupts: interrupt for the device
 - phy: A phandle to a phy node defining the PHY address (as the reg
diff --git 
a/Documentation/devicetree/bindings/pinctrl/marvell,armada-370-pinctrl.txt 
b/Documentation/devicetree/bindings/pinctrl/marvell,armada-370-pinctrl.txt
index 01ef408..8faff12 100644
--- a/Documentation/devicetree/bindings/pinctrl/marvell,armada-370-pinctrl.txt
+++ b/Documentation/devicetree/bindings/pinctrl/marvell,armada-370-pinctrl.txt
@@ -91,5 +91,5 @@ mpp61 61   gpo, dev(wen1), uart1(txd), audio(rclk)
 mpp62 62   gpio, dev(a2), uart1(cts), tdm(drx), pcie(clkreq0),
audio(mclk), uart0(cts)
 mpp63 63   gpo, spi0(sck), tclk
-mpp64 64   gpio, spi0(miso), spi0-1(cs1)
-mpp65 65   gpio, spi0(mosi), spi0-1(cs2)
+mpp64 64   gpio, spi0(miso), spi0(cs1)
+mpp65 65   gpio, spi0(mosi), spi0(cs2)
diff --git 
a/Documentation/devicetree/bindings/pinctrl/marvell,armada-xp-pinctrl.txt 
b/Documentation/devicetree/bindings/pinctrl/marvell,armada-xp-pinctrl.txt
index bfa0a2e..86dec67 100644
--- a/Documentation/devicetree/bindings/pinctrl/marvell,armada-xp-pinctrl.txt
+++ b/Documentation/devicetree/bindings/pinctrl/marvell,armada-xp-pinctrl.txt
@@ -41,15 +41,15 @@ mpp20 20   gpio, ge0(rxd4), ge1(rxd2), 
lcd(d20), ptp(clk)
 mpp21 21   gpio, ge0(rxd5), ge1(rxd3), lcd(d21), mem(bat)
 mpp22 22   gpio, ge0(rxd6), ge1(rxctl), lcd(d22), sata0(prsnt)
 mpp23 23   gpio, ge0(rxd7), ge1(rxclk), lcd(d23), sata1(prsnt)
-mpp24 24   gpio, lcd(hsync), sata1(prsnt), nf(bootcs-re), tdm(rst)
-mpp25 25   gpio, lcd(vsync), sata0(prsnt), nf(bootcs-we), tdm(pclk)
-mpp26 26   gpio, lcd(clk), tdm(fsync), vdd(cpu1-pd)
+mpp24 24   gpio, lcd(hsync), sata1(prsnt), tdm(rst)
+mpp25 25   gpio, lcd(vsync), sata0(prsnt), tdm(pclk)
+mpp26 26   gpio, lcd(clk), tdm(fsync)
 mpp27 27   gpio, lcd(e), tdm(dtx), ptp(trig)
 mpp28 28   gpio, lcd(pwm), tdm(drx), ptp(evreq)
-mpp29 29   gpio, lcd(ref-clk), tdm(int0), ptp(clk), vdd(cpu0-pd)
+mpp29 29   gpio, lcd(ref-clk), tdm(int0), ptp(clk)
 mpp30 30   gpio, tdm(int1), sd0(clk)
-mpp31 31   gpio, tdm(int2), sd0(cmd), vdd(cpu0-pd)
-mpp32 32   gpio, tdm(int3), sd0(d0), vdd(cpu1-pd)
+mpp31 31   gpio, tdm(int2), sd0(cmd)
+mpp32 32   gpio, tdm(int3), sd0(d0)
 mpp33 33   gpio, tdm(int4), sd0(d1), mem(bat)
 mpp34 34   gpio, tdm(int5), sd0(d2), sata0(prsnt)
 mpp35 35   gpio, tdm(int6), sd0(d3), sata1(prsnt)
@@ -57,21 +57,18 @@ mpp36 36   gpio, spi(mosi)
 mpp37 37   gpio, spi(miso)
 mpp38 38   gpio, spi(sck)
 mpp39 39   gpio, spi(cs0)
-mpp40 40   gpio, spi(cs1), uart2(cts), lcd(vga-hsync), 
vdd(cpu1-pd),
-   pcie(clkreq0)
+mpp40 40   gpio, spi(cs1), uart2(cts), lcd(vga-hsync), 
pcie(clkreq0)
 mpp41 41   gpio, spi(cs2), uart2(rts), lcd(vga-vsync), 
sata1(prsnt),
pcie(clkreq1)
-mpp42 42   gpio, uart2(rxd), uart0(cts), tdm(int7), tdm-1(timer),
-   vdd(cpu0-pd)
-mpp43 43   gpio, uart2(txd), uart0(rts), spi(cs3), pcie(rstout),
-   vdd(cpu2-3-pd){1}
+mpp42 42   gpio, uart2(rxd), uart0(cts), tdm(int7), tdm-1(timer)
+mpp43 43   gpio, uart2(txd), uart0(rts), spi(cs3), pcie(rstout)
 mpp44 44   gpio, uart2(cts), uart3(rxd), spi(cs4), pcie(clkreq2),
mem(bat)
 mpp45 45   gpio, uart2(rts), uart3(txd), spi(cs5), sata1(prsnt)
 mpp46 46   gpio, uart3(rts), uart1(rts), spi(cs6), sata0(prsnt)
 mpp47 47   gpio, uart3(cts), uart1(cts), spi(cs7), pcie(clkreq3),
ref(clkout)
-mpp48 48   gpio, tclk, dev(burst/last)
+mpp48 48   gpio, dev(clkout), dev(burst/last)
 
 * Marvell Armada XP (mv78260 and mv78460 only)
 
@@ -83,9 +80,9 @@ mpp51 51   gpio, dev(ad16)
 mpp52 52   gpio, dev(ad17)
 mpp53 53   gpio, dev(ad18)
 mpp54 54   gpio, dev(ad19)
-mpp55 55   gpio, dev(ad20), vdd(cpu0-pd)
-mpp56

Re: [PATCH 3/6] pci:host: Add Altera PCIe host controller driver

[Dinh Nguyen]

On Tue, Jul 28, 2015 at 5:45 AM, Ley Foon Tan  wrote:
> This patch adds the Altera PCIe host controller driver.
>
> Signed-off-by: Ley Foon Tan 
> ---
>  drivers/pci/host/Kconfig   |   9 +
>  drivers/pci/host/Makefile  |   1 +
>  drivers/pci/host/pcie-altera.c | 576 
> +
>  3 files changed, 586 insertions(+)
>  create mode 100644 drivers/pci/host/pcie-altera.c
>
> diff --git a/drivers/pci/host/Kconfig b/drivers/pci/host/Kconfig
> index 675c2d1..af19039 100644
> --- a/drivers/pci/host/Kconfig
> +++ b/drivers/pci/host/Kconfig
> @@ -145,4 +145,13 @@ config PCIE_IPROC_BCMA
>   Say Y here if you want to use the Broadcom iProc PCIe controller
>   through the BCMA bus interface
>
> +config PCIE_ALTERA
> +   bool "Altera PCIe controller"
> +   depends on ARCH_SOCFPGA
> +   depends on OF

I don't think you need this, "depends on ARCH_SOCFPGA" should already
have taken care of this.

> +   select PCI_MSI_IRQ_DOMAIN if PCI_MSI
> +   help
> + Say Y here if you want to enable PCIe controller support for Altera
> + SoCFPGA family of SoCs.
> +
>  endmenu



> +
> +static int tlp_read_packet(struct altera_pcie *pcie, u32 *value)
> +{
> +   u8 loop;
> +   struct tlp_rp_regpair_t tlp_rp_regdata;
> +
> +   for (loop = TLP_LOOP; loop > 0; loop--) {
> +
> +   tlp_read_rx(pcie, &tlp_rp_regdata);
> +
> +   if (tlp_rp_regdata.ctrl & RP_RXCPL_EOP) {
> +
> +   if (value)
> +   *value = tlp_rp_regdata.reg0;
> +
> +   return PCIBIOS_SUCCESSFUL;
> +   }

Remove all the unnecessary newlines in this function.
> +   }
> +
> +   return -ENOENT;
> +}
> +



> +
> +static struct platform_driver altera_pcie_driver = {
> +   .probe  = altera_pcie_probe,
> +   .remove = altera_pcie_remove,
> +   .driver = {
> +   .name   = "altera-pcie",
> +   .owner  = THIS_MODULE,

Don't need to set owner anymore as this will get populated by the driver core.

Dinh
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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: X-Gene: Unhandled fault: synchronous external abort in pci_generic_config_read32

[Bjorn Helgaas]

On Fri, Jul 24, 2015 at 7:05 PM, Duc Dang  wrote:
> Hi Bjorn,
>
> On Fri, Jul 24, 2015 at 3:42 PM, Bjorn Helgaas  wrote:
>>
>> I regularly see faults like this on an APM X-Gene:
>>
>>   U-Boot 2013.04-mustang_sw_1.14.14 (Dec 16 2014 - 15:59:33)
>>   CPU0: APM ARM 64-bit Potenza Rev B0 2400MHz PCP 2400MHz
>>32 KB ICACHE, 32 KB DCACHE
>>SOC 2000MHz IOBAXI 400MHz AXI 250MHz AHB 200MHz GFC 125MHz
>>   ...
>>   Unhandled fault: synchronous external abort (0x9610) at 
>> 0xff8000110034
>>   Internal error: : 9610 [#1] SMP
>>   Modules linked in:
>>   CPU: 0 PID: 3723 Comm: ... 4.1.0-smp-DEV #3
>>   Hardware name: APM X-Gene Mustang board (DT)
>>   task: ffc7dc1a4140 ti: ffc7dc118000 task.ti: ffc7dc118000
>>   PC is at pci_generic_config_read32+0x4c/0xb8
>>   LR is at pci_generic_config_read32+0x40/0xb8
>>   pc : [] lr : [] pstate: 61c5
>>   ...
>>   Call trace:
>>   [] pci_generic_config_read32+0x4c/0xb8
>>   [] pci_user_read_config_byte+0x60/0xc4
>>   [] pci_read_config+0x15c/0x238
>>   [] sysfs_kf_bin_read+0x68/0xa0
>>   [] kernfs_fop_read+0x9c/0x1ac
>>   [] __vfs_read+0x44/0x128
>>   [] vfs_read+0x84/0x144
>>   [] SyS_read+0x50/0xb0
>
> The log shows kernel gets an exception when trying to access Mellanox
> card configuration space. This is usually due to suboptimal PCIe
> SerDes parameters are using in your board, which will cause bad link
> quality.
> The PCIe SerDes programming is done in U-Boot, so I suggest you do a
> U-Boot upgrade to our latest X-Gene U-Boot release.

I installed U-Boot 1.15.12, which I thought was the latest.  I'm still
seeing this issue regularly, approx once/hour.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH RFC 1/1] Documentation: describe how to add a system call

[Kees Cook]

On Tue, Jul 28, 2015 at 4:41 AM, David Drysdale  wrote:
> Add a document describing the process of adding a new system call,
> including the need for a flags argument for future compatibility, and
> covering 32-bit/64-bit concerns (albeit in an x86-centric way).
>
> Signed-off-by: David Drysdale 
> Reviewed-by: Michael Kerrisk 

This is great!

Reviewed-by: Kees Cook 

I have a few minor suggestions below...

>
> ---
>  Documentation/adding-syscalls.txt | 454 
> ++
>  1 file changed, 454 insertions(+)
>  create mode 100644 Documentation/adding-syscalls.txt
>
> diff --git a/Documentation/adding-syscalls.txt 
> b/Documentation/adding-syscalls.txt
> new file mode 100644
> index ..5f52edda8951
> --- /dev/null
> +++ b/Documentation/adding-syscalls.txt
> @@ -0,0 +1,454 @@
> +Adding a New System Call
> +
> +
> +This document describes what's involved in adding a new system call to the
> +Linux kernel, over and above the normal submission advice in
> +Documentation/SubmittingPatches.
> +
> +
> +System Call Alternatives
> +
> +
> +The first thing to consider when adding a new system call is whether one of
> +the alternatives might be suitable instead.  Although system calls are the
> +most traditional and most obvious interaction points between userspace and 
> the
> +kernel, there are other possibilities -- choose what fits best for your
> +interface.
> +
> + - If the operations involved can be made to look like a filesystem-like
> +   object, it may make more sense to create a new filesystem or device.  This
> +   also makes it easier to encapsulate the new functionality in a kernel 
> module
> +   rather than requiring it to be built into the main kernel.
> + - If the new functionality involves operations where the kernel notifies
> +   userspace that something has happened, then returning a new file
> +   descriptor for the relevant object allows userspace to use
> +   poll/select/epoll to receive that notification.
> + - However, operations that don't map to read(2)/write(2)-like operations
> +   have to be implemented as ioctl(2) requests, which can lead to a
> +   somewhat opaque API.
> + - If you're just exposing runtime system information, a new node in sysfs
> +   (see Documentation/filesystems/sysfs.txt) or the /proc filesystem may be
> +   more appropriate.  However, access to these mechanisms requires that the
> +   relevant filesystem is mounted, which might not always be the case (e.g.
> +   in a namespaced/sandboxed/chrooted environment).

I would add "Avoid adding anything to debugfs, as this is not
considered a 'production' interface to userspace."

> + - If the operation is specific to a particular file or file descriptor, then
> +   an additional fcntl(2) command option may be more appropriate.  However,
> +   fcntl(2) is a multiplexing system call that hides a lot of complexity, so
> +   this option is best for when the new function is closely analogous to
> +   existing fcntl(2) functionality, or the new functionality is very simple
> +   (for example, getting/setting a simple flag related to a file descriptor).
> + - If the operation is specific to a particular task or process, then an
> +   additional prctl(2) command option may be more appropriate.  As with
> +   fcntl(2), this system call is a complicated multiplexor so is best 
> reserved
> +   for near-analogs of existing prctl() commands or getting/setting a simple
> +   flag related to a process.
> +
> +
> +Designing the API
> +-
> +
> +A new system call forms part of the API of the kernel, and has to be 
> supported
> +indefinitely.  As such, it's a very good idea to explicitly discuss the
> +interface on the kernel mailing list, and to plan for future extensions of 
> the
> +interface.  In particular:
> +
> +  **Include a flags argument for every new system call**
> +
> +The syscall table is littered with historical examples where this wasn't 
> done,
> +together with the corresponding follow-up system calls (eventfd/eventfd2,
> +dup2/dup3, inotify_init/inotify_init1,  pipe/pipe2, renameat/renameat2), so
> +learn from the history of the kernel and include a flags argument from the
> +start.
> +
> +Also, to make sure that userspace programs can safely use flags between 
> kernel
> +versions, check whether the flags value holds any unknown flags, and reject 
> the
> +sycall (with EINVAL) if it does:
> +
> +if (flags & ~(THING_FLAG1 | THING_FLAG2 | THING_FLAG3))
> +return -EINVAL;

Perhaps mention, "Even if no flags will be used, make sure the flags
argument is zero."

> +
> +If your new xyzzy(2) system call returns a new file descriptor, then the 
> flags
> +argument should include a value that is equivalent to setting O_CLOEXEC on 
> the
> +new FD.  This makes it possible for userspace to close the timing window
> +between xyzzy() and calling fcntl(fd, F_SETFD, FD_CLOEXEC), where an
> 

Re: [PATCH RFC 0/1] Document how to add a new syscall

[Shuah Khan]

On 07/28/2015 10:02 AM, David Drysdale wrote:
> On Tue, Jul 28, 2015 at 3:19 PM, Peter Zijlstra  wrote:
>> On Tue, Jul 28, 2015 at 07:59:16AM -0600, Shuah Khan wrote:
>>> On 07/28/2015 05:41 AM, David Drysdale wrote:
 Given that I've gotten some of the details wrong in the past (and I've
 seen others do likewise), I thought it might be helpful to collate the
 best practices for adding a new system call to the kernel.

 Apologies for the wide circulation -- I've tried to include folk who've
 recently added or proposed a system call, as they're most likely to
 have opinions on:
  - whether this a useful addition to Documentation/
  - whether the details of the advice are correct and complete.

 Shuah, is there anything more that should be added for the Testing
 section in particular?

>>>
>>> David,
>>>
>>> Looks good. You could add a one liner on in some cases, it might be
>>> necessary to install headers before test compiles. Other than that,
>>> the information looks good.
>>
>> For perf we still use the syscall() wrapper and we have hardcoded
>> (fallback) syscall numbers in there in case they've not yet reached
>> unistd.h.
>>
>> People update their kernels far more often than their userspace headers.
> 
> How about:
> 
> diff --git a/Documentation/adding-syscalls.txt
> b/Documentation/adding-syscalls.txt
> index 5f52edda8951..b274c3d01edb 100644
> --- a/Documentation/adding-syscalls.txt
> +++ b/Documentation/adding-syscalls.txt
> @@ -389,6 +389,11 @@ reviewers with a demonstration of how user space
> programs will use the system
>  call.  A good way to combine these aims is to include a simple self-test
>  program in a new directory under tools/testing/selftests/.
> 
> +For a new system call, there will obviously be no libc wrapper function and 
> so
> +the test will need to invoke it using syscall(); also, if the system call
> +involves a new userspace-visible structure, the corresponding header will 
> need
> +to be installed to compile the test.
> +

This looks good.

thanks,
-- Shuah


-- 
Shuah Khan
Sr. Linux Kernel Developer
Open Source Innovation Group
Samsung Research America (Silicon Valley)
shua...@osg.samsung.com | (970) 217-8978
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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 2/2] ARM: imx: Add suspend codes for imx7D

[Zhi Li]

On Tue, Jul 28, 2015 at 9:30 AM, Shawn Guo  wrote:
> On Tue, Jul 28, 2015 at 02:16:20PM +, Shenwei Wang wrote:
>> > The files are named with "-imx7".  It's a clear sign that the build of the 
>> > files
>> > should be controlled by something like related to "imx7".
>> > Ideally, it should be CONFIG_SOC_IMX7.  Since imx7d is the only supported 
>> > imx7
>> > soc and there is no CONFIG_SOC_IMX7 available so far, it falls on
>> > CONFIG_SOC_IMX7D.
>>
>> We can also interpret "-imx7" is the first SoC which has the GPCv2 block.
>
> In that case you should name the block gpc-imx7d rather than gpcv2 and
> symbol as GPC_IMX7D rather than IMX_GPCV2.

So far, only IMX7D use this GPC.
i.MX8 will use system controller to control power.

best regards
Frank Li

>
>> > > > > +extern struct imx_gpcv2_irq *gpcv2_irq_instance;
>> > > >
>> > > > Will this give a checkpatch warning?
>> > >
>> > > Yes. Any suggestion for that? Move it to a header file?
>> >
>> > Get rid of it.
>>
>> Then you may resolve the following compile error:
>
> You didn't get my point.  Rather than defining it as a global variable,
> we should try to keep imx_gpcv2_irq as an internal data structure to
> irqchip driver, and use well-defined interface to access the data from
> pm driver when necessary.
>
> Shawn
>
>>
>> CC  arch/arm/mach-imx/pm-imx7.o
>> arch/arm/mach-imx/pm-imx7.c: In function ‘imx_gpcv2_pm_init’:
>> arch/arm/mach-imx/pm-imx7.c:836:7: error: ‘gpcv2_irq_instance’ undeclared 
>> (first use in this function)
>>   cd = gpcv2_irq_instance;
>>^
>> arch/arm/mach-imx/pm-imx7.c:836:7: note: each undeclared identifier is 
>> reported only once for each function it appears in
>> make[1]: *** [arch/arm/mach-imx/pm-imx7.o] Error 1
>
> ___
> linux-arm-kernel mailing list
> linux-arm-ker...@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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/9] x86/intel_rdt: Add support for cache bit mask management

[Peter Zijlstra]

On Wed, Jul 01, 2015 at 03:21:07PM -0700, Vikas Shivappa wrote:
> +static int cbm_validate(struct intel_rdt *ir, unsigned long cbmvalue)
> +{
> + struct cgroup_subsys_state *css;
> + struct intel_rdt *par, *c;
> + unsigned long *cbm_tmp;
> + int err = 0;
> +
> + if (!cbm_is_contiguous(cbmvalue)) {
> + pr_err("bitmask should have >= 1 bit and be contiguous\n");
> + err = -EINVAL;
> + goto out_err;
> + }

> +static struct cftype rdt_files[] = {
> + {
> + .name   = "l3_cache_mask",
> + .seq_show   = intel_cache_alloc_cbm_read,
> + .write_u64  = intel_cache_alloc_cbm_write,
> + .mode   = 0666,

So this file is world writable? How is the above pr_err() not a DoS ?

> + },
> + { } /* terminate */
> +};
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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/9] x86/intel_rdt: Add support for cache bit mask management

[Peter Zijlstra]

On Wed, Jul 01, 2015 at 03:21:07PM -0700, Vikas Shivappa wrote:
> +static inline bool cbm_is_contiguous(unsigned long var)
> +{
> + unsigned long maxcbm = MAX_CBM_LENGTH;
> + unsigned long first_bit, zero_bit;
> +
> + if (!var)
> + return false;
> +
> + first_bit = find_next_bit(&var, maxcbm, 0);

We actually have: find_first_bit().

> + zero_bit = find_next_zero_bit(&var, maxcbm, first_bit);
> +
> + if (find_next_bit(&var, maxcbm, zero_bit) < maxcbm)
> + return false;
> +
> + return true;
> +}
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

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

[Luis R. Rodriguez]

On Tue, Jul 28, 2015 at 03:33:03PM +1000, Stephen Rothwell wrote:
> Hi all,
> 
> After merging the tip tree, today's linux-next build (powerpc
> allyesconfig) failed like this:
> 
> drivers/video/fbdev/aty/atyfb_base.c: In function 'atyfb_setup_generic':
> drivers/video/fbdev/aty/atyfb_base.c:3447:2: error: implicit declaration of 
> function 'ioremap_uc' [-Werror=implicit-function-declaration]
>   par->ati_regbase = ioremap_uc(info->fix.mmio_start, 0x1000);
>   ^
> drivers/video/fbdev/aty/atyfb_base.c:3447:19: warning: assignment makes 
> pointer from integer without a cast
>   par->ati_regbase = ioremap_uc(info->fix.mmio_start, 0x1000);
>^
> 
> Caused by commits
> 
>   3cc2dac5be3f ("drivers/video/fbdev/atyfb: Replace MTRR UC hole with strong 
> UC")
>   8c7ea50c010b ("x86/mm, asm-generic: Add IOMMU ioremap_uc() variant default")
> 
> The latter defines ioremap_uc() for x86 and those architectures that
> use asm-generic/io.h - which is not all of them :-( .  The former commit
> then uses ioremap_uc().
> 
> I have reverted commit 3cc2dac5be3f (and 7d89a3cb159a that follows it)
> for today.

This should be fixed by:

http://git.kernel.org/tip/8c7ea50c010b2f1e006ad37c43f98202a31de2cb

The way it was defined was to return NULL if an arch does not have it,
*but* if the asm-generic io.h header is not included on some archs it will still
fail, which leaves us no option but to then poke and define its implementaiton
for archs which opt-out of asm-generic io.h

Benh, in this case I believe its OK to to just map it to ioremap(), let me know
what you think.

diff --git a/arch/powerpc/include/asm/io.h b/arch/powerpc/include/asm/io.h
index a8d2ef30d473..91db9153cd44 100644
--- a/arch/powerpc/include/asm/io.h
+++ b/arch/powerpc/include/asm/io.h
@@ -721,6 +721,7 @@ extern void __iomem *ioremap_prot(phys_addr_t address, 
unsigned long size,
  unsigned long flags);
 extern void __iomem *ioremap_wc(phys_addr_t address, unsigned long size);
 #define ioremap_nocache(addr, size)ioremap((addr), (size))
+#define ioremap_uc(addr, size) ioremap((addr), (size))
 
 extern void iounmap(volatile void __iomem *addr);
 

  Luis
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] Input: zforce_ts - fix playload length check

[Dmitry Torokhov]

On Tue, Jul 28, 2015 at 01:28:32PM +0200, Dirk Behme wrote:
> On 28.07.2015 12:23, Geert Uytterhoeven wrote:
> >On Mon, Jul 27, 2015 at 11:06 PM, Dmitry Torokhov
> > wrote:
> >>Commit 7d01cd261c76f95913c81554a751968a1d282d3a ("Input: zforce - don't
> >>overwrite the stack") attempted to add a check for payload size being too
> >>large for the supplied buffer. Unfortunately with the currently selected
> >>buffer size the comparison is always false as buffer size is larger than
> >>the value a single byte can hold, and that results in compiler warnings.
> >>Additionally the check was incorrect as it was not accounting for the
> >>already read 2 bytes of data stored in the buffer.
> >
> >The check was indeed incorrect.
> >
> >>Fixes: 7d01cd261c76f95913c81554a751968a1d282d3a
> >>Reported-by: kbuild test robot 
> >>Signed-off-by: Dmitry Torokhov 
> >>---
> >>
> >>This seems to shut up my GCC, I wonder if it is going to work gfor
> >>everyone or we better add BUILD_BUG_ON(FRAME_MAXSIZE < 257) and a
> >>comment and remove check.
> >>
> >>  drivers/input/touchscreen/zforce_ts.c | 4 +++-
> >>  1 file changed, 3 insertions(+), 1 deletion(-)
> >>
> >>diff --git a/drivers/input/touchscreen/zforce_ts.c 
> >>b/drivers/input/touchscreen/zforce_ts.c
> >>index 2554efd..542ff02 100644
> >>--- a/drivers/input/touchscreen/zforce_ts.c
> >>+++ b/drivers/input/touchscreen/zforce_ts.c
> >>@@ -441,7 +441,9 @@ static int zforce_read_packet(struct zforce_ts *ts, u8 
> >>*buf)
> >> goto unlock;
> >> }
> >>
> >>-   if (buf[PAYLOAD_LENGTH] == 0 || buf[PAYLOAD_LENGTH] > 
> >>FRAME_MAXSIZE) {
> >>+   if (buf[PAYLOAD_LENGTH] == 0 ||
> >>+   (FRAME_MAXSIZE - 2 < 255 &&
> >>+buf[PAYLOAD_LENGTH] > FRAME_MAXSIZE - 2)) {
> >
> >Doesn't help with gcc 4.1.2 :-(
> >
> >Before:
> >
> >drivers/input/touchscreen/zforce_ts.c: In function ‘zforce_read_packet’:
> >drivers/input/touchscreen/zforce_ts.c:432: warning: comparison is
> >always false due to limited range of data type
> >
> >After:
> >
> >drivers/input/touchscreen/zforce_ts.c: In function ‘zforce_read_packet’:
> >drivers/input/touchscreen/zforce_ts.c:434: warning: comparison is
> >always false due to limited range of data type
> 
> 
> If it's easier, then just revert 7d01cd261c76f95913c81.
> 
> Sorry! It seems that at least 4 people have overlooked this issue :(

Yes, I guess that is an example where unified diff provides too little
of a context...

> 
> Best regards
> 
> Dirk
> 
> Btw: Could anybody give me a hint how to get this warning? My GCC
> 4.8.1 with kernel default ARM Cortex A9 kernel options doesn't give
> me anything about this.

make KBUILD_CFLAGS="-Wtype-limits" drivers/input/touchscreen/zforce_ts.o

may trigger it.

-- 
Dmitry
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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 0/3] x86: modify_ldt improvement, test, and config option

[Andrew Cooper]

On 28/07/15 16:43, Andy Lutomirski wrote:
>
 After forward-porting my virtio patches, I got this thing to run on
 Xen.  After several tries, I got:

 [   53.985707] [ cut here ]
 [   53.986314] kernel BUG at arch/x86/xen/enlighten.c:496!
 [   53.986677] invalid opcode:  [#1] SMP
 [   53.986677] Modules linked in:
 [   53.986677] CPU: 0 PID: 1400 Comm: bash Not tainted 4.2.0-rc4+ #4
 [   53.986677] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996),
 BIOS rel-1.7.5-0-ge51488c-20140602_164612-nilsson.home.kraxel.org
 04/01/2014
 [   53.986677] task: c2376180 ti: c0874000 task.ti: c0874000
 [   53.986677] EIP: 0061:[] EFLAGS: 00010282 CPU: 0
 [   53.986677] EIP is at set_aliased_prot+0xb2/0xc0
 [   53.986677] EAX: ffea EBX: cc3d1000 ECX: 0672e063 EDX: 8000
 [   53.986677] ESI:  EDI: 8000 EBP: c0875e94 ESP: c0875e74
 [   53.986677]  DS: 007b ES: 007b FS: 00d8 GS: 0033 SS: 0069
 [   53.986677] CR0: 80050033 CR2: b77404d4 CR3: 020b6000 CR4: 00042660
 [   53.986677] Stack:
 [   53.986677]  8000 0672e063 21c0 cc3d1000 0001 cc3d2000
 0b4a 0200
 [   53.986677]  c0875ea8 c105312d c2317940 c2373a80  c0875eb4
 c1062310 c01861c0
 [   53.986677]  c0875ec0 c1062735 c01861c0 c0875ed4 c10a764e c7007a00
 c2373a80 
 [   53.986677] Call Trace:
 [   53.986677]  [] xen_free_ldt+0x2d/0x40
 [   53.986677]  [] free_ldt_struct.part.1+0x10/0x40
 [   53.986677]  [] destroy_context+0x25/0x40
 [   53.986677]  [] __mmdrop+0x1e/0xc0
 [   53.986677]  [] finish_task_switch+0xd8/0x1a0
 [   53.986677]  [] __schedule+0x316/0x950
 [   53.986677]  [] schedule+0x26/0x70
 [   53.986677]  [] do_wait+0x1b3/0x200
 [   53.986677]  [] SyS_waitpid+0x67/0xd0
 [   53.986677]  [] ? task_stopped_code+0x50/0x50
 [   53.986677]  [] syscall_call+0x7/0x7
 [   53.986677] Code: e8 c1 e3 0c 81 eb 00 00 00 40 39 5d ec 74 11 8b
 4d e4 8b 55 e0 31 f6 e8 dd e0 fa ff 85 c0 75 0d 83 c4 14 5b 5e 5f 5d
 c3 90 0f 0b <0f> 0b 0f 0b 8d 76 00 8d bc 27 00 00 00 00 85 d2 74 31 55
 89 e5
 [   53.986677] EIP: [] set_aliased_prot+0xb2/0xc0 SS:ESP 
 0069:c0875e74
 [   54.010069] ---[ end trace 89ac35b29c1c59bb ]---

 Is that the error you're seeing?

 If I change xen_free_ldt to:

 static void xen_free_ldt(struct desc_struct *ldt, unsigned entries)
 {
 const unsigned entries_per_page = PAGE_SIZE / LDT_ENTRY_SIZE;
 int i;

 vm_unmap_aliases();
 xen_mc_flush();

 for(i = 0; i < entries; i += entries_per_page)
 set_aliased_prot(ldt + i, PAGE_KERNEL);
 }

 then it works.  I don't know why this makes a difference.
 (xen_mc_flush makes a little bit of sense to me.  vm_unmap_aliases
 doesn't.)

>>> That fix makes sense if there's some way that the vmalloc area we're
>>> freeing has an extra alias somewhere, which is very much possible.  On
>>> the other hand, I don't see how this happens without first doing an
>>> MMUEXT_SET_LDT with an unexpectedly aliased address, and I would have
>>> expected that to blow up and/or result in test case failures.
>>>
>>> But I'm still confused, because it seems like Xen will never populate
>>> the actual (hidden) LDT mapping unless the pages backing it are
>>> unaliased and well-formed, which make me wonder why this stuff ever
>>> worked.  Wouldn't LDT access with pre-existing vmalloc aliases result
>>> in segfaults?
>>>
>>> The semantics seem to be very odd.  xen_free_ldt with an aliased
>>> address might fail (and OOPS), but actual access to the LDT with an
>>> aliased address page faults.
>>>
>>> Also, using kzalloc for everything fixes the problem, which suggests
>>> that there really is something to my theory that the problem involves
>>> unexpected aliases.
>> Xen does lazily populate the LDT frames.  The first time a page is ever
>> referenced via the LDT, Xen will perform a typechange.
>>
>> Under Xen, guest mappings are reference counted with both a plain
>> reference, and a type count.  Types of writeable, segdec and pagetables
>> are mutually exclusive.  This prevents the guest from having writeable
>> mappings of interesting datastructures, but readable mappings are fine.
>> Typechanges may only occur when the type reference count is 0.
> Makes sense.
>
>> At the point of the typechange, no writeable mappings of the frame may
>> exist (and it must not be referenced by a L2 or greater page directory),
>> or the typechange will fail.  Additionally the descriptors are audited
>> at this point, so if Xen objects to any of the descriptors in the same
>> page, the typechange will also fail.
>>
>> If the typechange fails, the pagefault gets propagated back to the guest.
> The part I don't understand is that I didn't observe any page faults.
>
>> The corollary to this is that, for xe

Re: [PATCH 4/9] x86/intel_rdt: Add support for Cache Allocation detection

[Peter Zijlstra]

On Wed, Jul 01, 2015 at 03:21:05PM -0700, Vikas Shivappa wrote:
> +static int __init intel_rdt_late_init(void)
> +{
> + struct cpuinfo_x86 *c = &boot_cpu_data;
> +
> + if (!cpu_has(c, X86_FEATURE_CAT_L3))
> + return -ENODEV;
> +
> + pr_info("Intel cache allocation enabled\n");

s/enabled/detected/ ? This hardly enables anything.

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

Re: [RFC 0/2] VFIO: Add virtual MSI doorbell support.

[Alex Williamson]

On Fri, 2015-07-24 at 14:33 +0530, Pranavkumar Sawargaonkar wrote:
> In current VFIO MSI/MSI-X implementation, linux host kernel
> allocates MSI/MSI-X vectors when userspace requests through vfio ioctls.
> Vfio creates irqfd mappings to notify MSI/MSI-X interrupts
> to the userspace when raised.
> Guest OS will see emulated MSI/MSI-X controller and receives an interrupt
> when kernel notifies the same via irqfd.
> 
> Host kernel allocates MSI/MSI-X using standard linux routines
> like pci_enable_msix_range() and pci_enable_msi_range(). 
> These routines along with requset_irq() in host kernel sets up 
> MSI/MSI-X vectors with Physical MSI/MSI-X addresses provided by
> interrupt controller driver in host kernel.
> 
> This means when a device is assigned with the guest OS, MSI/MSI-X addresses
> present in PCIe EP are the PAs programmed by the host linux kernel.
> 
> In x86 MSI/MSI-X physical address range is reserved and iommu is aware
> about these addreses and transalation is bypassed for these address range.
> 
> Unlike x86, ARM/ARM64 does not reserve MSI/MSI-X Physical address range and
> all the transactions including MSI go through iommu/smmu without bypass.
> This requires extending current vfio MSI layer with additional functionality
> for ARM/ARM64 by
> 1. Programing IOVA (referred as a MSI virtual doorbell address)
>in device's MSI vector as a MSI address.
>This IOVA will be provided by the userspace based on the
>MSI/MSI-X addresses reserved for the guest.
> 2. Create an IOMMU mapping between this IOVA and
>Physical address (PA) assigned to the MSI vector.
> 
> This RFC is proposing a solution for MSI/MSI-X passthrough for ARM/ARM64.


Hi Pranavkumar,

Freescale has the same, or very similar, need, so any solution in this
space will need to work for both ARM and powerpc.  I'm not a big fan of
this approach as it seems to require the user to configure MSI/X via
ioctl and then call a separate ioctl mapping the doorbells.  That's more
code for the user, more code to get wrong and potentially a gap between
configuring MSI/X and enabling mappings where we could see IOMMU faults.

If we know that doorbell mappings are required, why can't we set aside a
bank of IOVA space and have them mapped automatically as MSI/X is being
configured?  Then the user's need for special knowledge and handling of
this case is limited to setup.  The IOVA space will be mapped and used
as needed, we only need the user to specify the IOVA space reserved for
this.  Thanks,

Alex

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

Re: [RFC PATCH 0/3] clocksource: exynos_mct: allow mct to use 64-bit counter from coprocessor

[Alexey Klimov]

Hi Doug,

On Tue, Jul 28, 2015 at 6:24 PM, Doug Anderson  wrote:
> Alexey,
>
> On Mon, Jul 27, 2015 at 2:28 PM, Alexey Klimov  wrote:
>> Hi all,
>>
>> year(s) ago it was discovered that MCT timer and ARM architectured
>> timer
>> are the same hardware with different interface. Here [1].
>>
>> I followed mail-list discussions about removing MCT and using arch
>> timer for Exynos5-based SoCs but things aren't moving at least latest
>> upstream kernel on odroid-xu3 will use MCT as default timers.
>> Maybe the reason are some power-management related things that very
>> specific to Samsung. I don't know.
>>
>>
>> Idea of this draft patchset comes from Doug patches when he tried to
>> optimize read of 64-bit counter located in mmio. [2]
>> Why not using cp15 counter instead if possible?
>
> I hate to burst your bubble here, but...
>
> ...I think it would be a bad idea to use the cp15 counter on exynos
> 5422.  According to Samsung, there are issues where using cp15 could
> sometimes return the wrong value, especially if you happen to read it
> while on an A7 instead of an A15.  It will tend to work pretty well,
> but Samsung claimed that it might not work right on some CPUs or at
> some temperatures.

I think this is right time when I can say "If only I had known about
it before!".
That's quite interesting especially about temperature issues.
Maybe it's worth to insert comments in driver/docs about this.

> I've added Alim who provided this information to me (in the private
> http://crosbug.com/p/29556).  He may be able to elaborate more.

Alim, could you please add details if any?

> Generally I'd say that if the arch timer works for you: use the arch
> timer.  If the arch timer doesn't work for you, use the MCT.
>
> -Doug

I possess no knowledge if there're any different hw revisions of
odroid-xu3 on the field
but looks like arch timer works fine for me on odroid-xu3 Exynos5422
SoC with upstream kernel.
Is it right direction to switch xu3 to arch timer?
Do you have any info or ideas about enabling MCT G_TCON register to
start arch timer
and what's the best way to do it?

Thanks.

-- 
Best regards, Klimov Alexey
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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: [Intel-gfx] [PATCH 2/3] drm/i915: hide errors when probing for a reverse display port

[Chris Wilson]

On Tue, Jul 28, 2015 at 12:03:28PM -0400, Benjamin Tissoires wrote:
> We check the polarity of the attached dp, so it is normal to fail.
> Do not send errors to the users.

if (probe) DRM_DEBUG else DRM_ERROR is fairly offensive.

It strikes me that you could make each of these functions report the
failure to the caller (have the caller even do so error handling!) and
as part of that have the caller report an error and so demote all of
these to DRM_DEBUG_KMS().

Who knows, actually doing some error handling may make monitor training
more reliable! Or we may even get carried away and report the failure
all the way back to userspace.
-Chris

-- 
Chris Wilson, Intel Open Source Technology Centre
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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/BUG] perf tools: static build fails

[Arnaldo Carvalho de Melo]

Em Tue, Jul 28, 2015 at 05:13:47PM +0200, Jiri Olsa escreveu:
> hi,
> it's failing on perf-read-vdso32 tool..
> attached patch fixes that for me

To build it statically:

  make -C tools/perf O=/tmp/build/perf LDFLAGS=-static install-bin

Adrian, I wonder if building just these utilities non-statically when we
ask for a static build of the main tool is ok, is it?

- Arnaldo


 
> jirka
> 
> 
> ---
> diff --git a/tools/perf/Makefile.perf b/tools/perf/Makefile.perf
> index 4b58daeff881..a72f790f05e8 100644
> --- a/tools/perf/Makefile.perf
> +++ b/tools/perf/Makefile.perf
> @@ -370,12 +370,12 @@ $(OUTPUT)perf-%: %.o $(PERFLIBS)
>  
>  ifndef NO_PERF_READ_VDSO32
>  $(OUTPUT)perf-read-vdso32: perf-read-vdso.c util/find-vdso-map.c
> - $(QUIET_CC)$(CC) -m32 $(filter -static,$(LDFLAGS)) -Wall -Werror -o $@ 
> perf-read-vdso.c
> + $(QUIET_CC)$(CC) -m32 $(filter-out -static,$(LDFLAGS)) -Wall -Werror -o 
> $@ perf-read-vdso.c
>  endif
>  
>  ifndef NO_PERF_READ_VDSOX32
>  $(OUTPUT)perf-read-vdsox32: perf-read-vdso.c util/find-vdso-map.c
> - $(QUIET_CC)$(CC) -mx32 $(filter -static,$(LDFLAGS)) -Wall -Werror -o $@ 
> perf-read-vdso.c
> + $(QUIET_CC)$(CC) -mx32 $(filter-out -static,$(LDFLAGS)) -Wall -Werror 
> -o $@ perf-read-vdso.c
>  endif
>  
>  $(patsubst perf-%,%.o,$(PROGRAMS)): $(wildcard */*.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] Smack: replace capable() with ns_capable()

[Casey Schaufler]

On 7/28/2015 8:06 AM, Serge E. Hallyn wrote:
> On Tue, Jul 28, 2015 at 07:36:30AM -0700, Casey Schaufler wrote:
>> On 7/26/2015 6:27 PM, Sungbae Yoo wrote:
>>> So, Do you agree to allow the process to change its own labels?
>> No. This requires CAP_MAC_ADMIN. Smack is mandatory access control.
>> Being in a namespace (as they are implemented today) is not sufficient.
> "requires CAP_MAC_ADMIN" should probably read "requires
> CAP_MAC_ADMIN against initial user namespace."  Any unprivileged
> user can unshare a user_ns and get CAP_MAC_ADMIN.

As you say. Since the inode's xattrs are common you need
privilege relative to the initial namespace.

>
> I'm terribly sorry I'm not yet caught up on the smack-lsm thread.
> But intuitively I'd think that you'd want a way for smack policy
> to say "this label is allowed to create a user-ns which will be
> allowed to CAP_MAC_ADMIN", so then smack_capable() can use that
> information to cleanly deny CAP_MAC_ADMIN in namespaces.
>
> -serge
>

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] perf stat: Fix transaction lenght metrics

[Arnaldo Carvalho de Melo]

From: Andi Kleen 

The transaction length metrics in perf stat -T broke recently.

It would not match the metric correctly and always print K/sec.

This was caused by a incorrect update of the cycles_in_tx statistics.

Update the correct variable.

Also the check for zero division was reversed, which resulted in K/sec
being printed for no transactions. Fix this also up.

Signed-off-by: Andi Kleen 
Acked-by: Jiri Olsa 
Link: 
http://lkml.kernel.org/r/1438039491-22091-1-git-send-email-a...@firstfloor.org
Signed-off-by: Arnaldo Carvalho de Melo 
---
 tools/perf/util/stat-shadow.c | 8 +++-
 1 file changed, 3 insertions(+), 5 deletions(-)

diff --git a/tools/perf/util/stat-shadow.c b/tools/perf/util/stat-shadow.c
index 53e8bb7bc852..2a5d8d7698ae 100644
--- a/tools/perf/util/stat-shadow.c
+++ b/tools/perf/util/stat-shadow.c
@@ -85,7 +85,7 @@ void perf_stat__update_shadow_stats(struct perf_evsel 
*counter, u64 *count,
else if (perf_evsel__match(counter, HARDWARE, HW_CPU_CYCLES))
update_stats(&runtime_cycles_stats[ctx][cpu], count[0]);
else if (perf_stat_evsel__is(counter, CYCLES_IN_TX))
-   update_stats(&runtime_transaction_stats[ctx][cpu], count[0]);
+   update_stats(&runtime_cycles_in_tx_stats[ctx][cpu], count[0]);
else if (perf_stat_evsel__is(counter, TRANSACTION_START))
update_stats(&runtime_transaction_stats[ctx][cpu], count[0]);
else if (perf_stat_evsel__is(counter, ELISION_START))
@@ -398,20 +398,18 @@ void perf_stat__print_shadow_stats(FILE *out, struct 
perf_evsel *evsel,
" #   %5.2f%% aborted cycles ",
100.0 * ((total2-avg) / total));
} else if (perf_stat_evsel__is(evsel, TRANSACTION_START) &&
-  avg > 0 &&
   runtime_cycles_in_tx_stats[ctx][cpu].n != 0) {
total = avg_stats(&runtime_cycles_in_tx_stats[ctx][cpu]);
 
-   if (total)
+   if (avg)
ratio = total / avg;
 
fprintf(out, " # %8.0f cycles / transaction   ", ratio);
} else if (perf_stat_evsel__is(evsel, ELISION_START) &&
-  avg > 0 &&
   runtime_cycles_in_tx_stats[ctx][cpu].n != 0) {
total = avg_stats(&runtime_cycles_in_tx_stats[ctx][cpu]);
 
-   if (total)
+   if (avg)
ratio = total / avg;
 
fprintf(out, " # %8.0f cycles / elision   ", ratio);
-- 
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/

[GIT PULL 0/2] perf/urgent fixes

[Arnaldo Carvalho de Melo]

Hi Ingo,

Please consider pulling,

- Arnaldo

The following changes since commit 00a2916f7f82c348a2a94dbb572874173bc308a3:

  perf: Fix running time accounting (2015-07-27 13:52:19 +0200)

are available in the git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/acme/linux.git 
tags/perf-urgent-for-mingo

for you to fetch changes up to 0927beeca5f9d1a7978f8da9c9d28647859816d3:

  perf tools: Fix test build error when bindir contains double slash 
(2015-07-28 13:03:49 -0300)


perf/urgent fixes:

User visible:

- Fix 'perf stat' transaction lenght metrics (Andi Kleen)

Developer visible:

- Fix test build error when bindir contains double slash (Pawel Moll)

Signed-off-by: Arnaldo Carvalho de Melo 


Andi Kleen (1):
  perf stat: Fix transaction lenght metrics

Pawel Moll (1):
  perf tools: Fix test build error when bindir contains double slash

 tools/perf/config/Makefile| 2 +-
 tools/perf/util/stat-shadow.c | 8 +++-
 2 files changed, 4 insertions(+), 6 deletions(-)
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH 2/2] perf tools: Fix test build error when bindir contains double slash

[Arnaldo Carvalho de Melo]

From: Pawel Moll 

When building with a prefix ending with a slash, for example:

$ make prefix=/usr/local/

one of the perf tests fail to compile due to BUILD_STR macro mishandling
bindir_SQ string containing with two slashes:

-DBINDIR="BUILD_STR(/usr/local//bin)"

with the following error:

  CC   tests/attr.o
tests/attr.c: In function ‘test__attr’:
tests/attr.c:168:50: error: expected ‘)’ before ‘;’ token
  snprintf(path_perf, PATH_MAX, "%s/perf", BINDIR);
  ^
tests/attr.c:176:1: error: expected ‘;’ before ‘}’ token
 }
 ^
tests/attr.c:176:1: error: control reaches end of non-void function 
[-Werror=return-type]
 }
 ^
cc1: all warnings being treated as errors

This patch works around the problem by "cleaning" the bindir string
using make's abspath function.

Signed-off-by: Pawel Moll 
Acked-by: Jiri Olsa 
Cc: Adrian Hunter 
Cc: Namhyung Kim 
Cc: Peter Zijlstra 
Link: 
http://lkml.kernel.org/r/1438092613-21014-1-git-send-email-pawel.m...@arm.com
Signed-off-by: Arnaldo Carvalho de Melo 
---
 tools/perf/config/Makefile | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/tools/perf/config/Makefile b/tools/perf/config/Makefile
index 094ddaee104c..d31fac19c30b 100644
--- a/tools/perf/config/Makefile
+++ b/tools/perf/config/Makefile
@@ -638,7 +638,7 @@ ifndef DESTDIR
 prefix ?= $(HOME)
 endif
 bindir_relative = bin
-bindir = $(prefix)/$(bindir_relative)
+bindir = $(abspath $(prefix)/$(bindir_relative))
 mandir = share/man
 infodir = share/info
 perfexecdir = libexec/perf-core
-- 
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 v4] clk: at91: add generated clock driver

[Nicolas Ferre]

Add a new type of clocks that can be provided to a peripheral.
In addition to the peripheral clock, this new clock that can use several
input clocks as parents can generate divided rates.
This would allow a peripheral to have finer grained clocks for generating
a baud rate, clocking an asynchronous part or having more
options in frequency.

Signed-off-by: Nicolas Ferre 
Acked-by: Boris Brezillon 
---

Changes in v4:
- protect stored parent_id from incoherency
- use of of_count_phandle_with_args()
- collect Ack tag from Boris

Changes in v3:
- rebase on top of next-20150727
- make use of of_clk_parent_fill helper function
- change determine_rate() according to new prototype

Changes in v2:
- adapt to new xxx_determine_rate() callback prototype
- fix checkpatch errors and use __func__
- fix handling of clocks without clk-output-range property specified.
  Test if range.max is present before using it
- test clock id only at probe time instead of at each API call
- remove useless tests in clk_generated_set_rate()
- change the meaningless config HAVE_AT91_GENERATED to HAVE_AT91_GENERATED_CLK
- wrap some lines over 80 characters

 .../devicetree/bindings/clock/at91-clock.txt   |  35 +++
 arch/arm/mach-at91/Kconfig |   3 +
 drivers/clk/at91/Makefile  |   1 +
 drivers/clk/at91/clk-generated.c   | 313 +
 drivers/clk/at91/pmc.c |   6 +
 drivers/clk/at91/pmc.h |   3 +
 include/linux/clk/at91_pmc.h   |   7 +
 7 files changed, 368 insertions(+)
 create mode 100644 drivers/clk/at91/clk-generated.c

diff --git a/Documentation/devicetree/bindings/clock/at91-clock.txt 
b/Documentation/devicetree/bindings/clock/at91-clock.txt
index 5ba6450693b9..5e737d2cd05d 100644
--- a/Documentation/devicetree/bindings/clock/at91-clock.txt
+++ b/Documentation/devicetree/bindings/clock/at91-clock.txt
@@ -77,6 +77,9 @@ Required properties:
"atmel,sama5d4-clk-h32mx":
at91 h32mx clock
 
+   "atmel,sama5d2-clk-generated":
+   at91 generated clock
+
 Required properties for SCKC node:
 - reg : defines the IO memory reserved for the SCKC.
 - #size-cells : shall be 0 (reg is used to encode clk id).
@@ -461,3 +464,35 @@ For example:
compatible = "atmel,sama5d4-clk-h32mx";
clocks = <&mck>;
};
+
+Required properties for generated clocks:
+- #size-cells : shall be 0 (reg is used to encode clk id).
+- #address-cells : shall be 1 (reg is used to encode clk id).
+- clocks : shall be the generated clock source phandles.
+   e.g. clocks = <&clk32k>, <&main>, <&plladiv>, <&utmi>, <&mck>;
+- name: device tree node describing a specific generated clock.
+   * #clock-cells : from common clock binding; shall be set to 0.
+   * reg: peripheral id. See Atmel's datasheets to get a full
+ list of peripheral ids.
+   * atmel,clk-output-range : minimum and maximum clock frequency
+ (two u32 fields).
+
+For example:
+   gck {
+   compatible = "atmel,sama5d2-clk-generated";
+   #address-cells = <1>;
+   #size-cells = <0>;
+   clocks = <&clk32k>, <&main>, <&plladiv>, <&utmi>, <&mck>;
+
+   tcb0_gclk: tcb0_gclk {
+   #clock-cells = <0>;
+   reg = <35>;
+   atmel,clk-output-range = <0 8300>;
+   };
+
+   pwm_gclk: pwm_gclk {
+   #clock-cells = <0>;
+   reg = <38>;
+   atmel,clk-output-range = <0 8300>;
+   };
+   };
diff --git a/arch/arm/mach-at91/Kconfig b/arch/arm/mach-at91/Kconfig
index fd95f34945f4..e8273e79f6ba 100644
--- a/arch/arm/mach-at91/Kconfig
+++ b/arch/arm/mach-at91/Kconfig
@@ -90,6 +90,9 @@ config HAVE_AT91_SMD
 config HAVE_AT91_H32MX
bool
 
+config HAVE_AT91_GENERATED_CLK
+   bool
+
 config SOC_SAM_V4_V5
bool
 
diff --git a/drivers/clk/at91/Makefile b/drivers/clk/at91/Makefile
index 89a48a7bd5df..13e67bd35cff 100644
--- a/drivers/clk/at91/Makefile
+++ b/drivers/clk/at91/Makefile
@@ -10,3 +10,4 @@ obj-$(CONFIG_HAVE_AT91_UTMI)  += clk-utmi.o
 obj-$(CONFIG_HAVE_AT91_USB_CLK)+= clk-usb.o
 obj-$(CONFIG_HAVE_AT91_SMD)+= clk-smd.o
 obj-$(CONFIG_HAVE_AT91_H32MX)  += clk-h32mx.o
+obj-$(CONFIG_HAVE_AT91_GENERATED_CLK)  += clk-generated.o
diff --git a/drivers/clk/at91/clk-generated.c b/drivers/clk/at91/clk-generated.c
new file mode 100644
index ..642366f45742
--- /dev/null
+++ b/drivers/clk/at91/clk-generated.c
@@ -0,0 +1,313 @@
+/*
+ *  Copyright (C) 2015 Atmel Corporation,
+ * Nicolas Ferre 
+ *
+ * Based on clk-programmable & clk-peripheral drivers by Boris BREZILLON.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of t

Re: [Xen-devel] [PATCH 2/8] xen: Make clear that swiotlb and biomerge are dealing with DMA address

[Julien Grall]

Hi David,

On 28/07/15 16:52, David Vrabel wrote:
> On 28/07/15 16:02, Julien Grall wrote:
>>
>> +/* Pseudo-physical <-> DMA conversion */
>> +static inline unsigned long pfn_to_dfn(unsigned long pfn)
> 
> Use BFN for bus frame number.  This is the terminology that is used in
> the (proposed) pv-iommu hypercall.

Good idea, I will use them in the next version.

Regards,

-- 
Julien Grall
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] kthread: Export kthread functions

[David Kershner]

The s-Par visornic driver, currently in staging, processes a queue
being serviced by the an s-Par service partition. We can get a message
that something has happened with the Service Partition, when that
happens, we must not access the channel until we get a message that the
service partition is back again.

The visornic driver has a thread for processing the channel, when we
get the message, we need to be able to park the thread and then resume
it when the problem clears.

We can do this with kthread_park and unpark but they are not exported
from the kernel, this patch exports the needed functions.

Signed-off-by: David Kershner 
---
 kernel/kthread.c | 4 
 1 file changed, 4 insertions(+)

diff --git a/kernel/kthread.c b/kernel/kthread.c
index 10e489c..fdea0be 100644
--- a/kernel/kthread.c
+++ b/kernel/kthread.c
@@ -97,6 +97,7 @@ bool kthread_should_park(void)
 {
return test_bit(KTHREAD_SHOULD_PARK, &to_kthread(current)->flags);
 }
+EXPORT_SYMBOL_GPL(kthread_should_park);
 
 /**
  * kthread_freezable_should_stop - should this freezable kthread return now?
@@ -171,6 +172,7 @@ void kthread_parkme(void)
 {
__kthread_parkme(to_kthread(current));
 }
+EXPORT_SYMBOL_GPL(kthread_parkme);
 
 static int kthread(void *_create)
 {
@@ -411,6 +413,7 @@ void kthread_unpark(struct task_struct *k)
if (kthread)
__kthread_unpark(k, kthread);
 }
+EXPORT_SYMBOL_GPL(kthread_unpark);
 
 /**
  * kthread_park - park a thread created by kthread_create().
@@ -441,6 +444,7 @@ int kthread_park(struct task_struct *k)
}
return ret;
 }
+EXPORT_SYMBOL_GPL(kthread_park);
 
 /**
  * kthread_stop - stop a thread created by kthread_create().
-- 
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/

Re: [PATCH v2] tools: perf: Fix test build error when bindir contains double slash

[Arnaldo Carvalho de Melo]

Em Tue, Jul 28, 2015 at 04:46:00PM +0200, Jiri Olsa escreveu:
> On Tue, Jul 28, 2015 at 03:10:13PM +0100, Pawel Moll wrote:
> > When building with a prefix ending with a slash, for example:
> > 
> > This patch works around the problem by "cleaning" the bindir string
> > using make's abspath function.
> 
> nice ;-)
> 
> Acked-by: Jiri Olsa 

Applied.

- Arnaldo
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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/3] drm/i915: fix USB Type-C reversed connector

[Benjamin Tissoires]

Hi,

plugging a USB Type-C to HDMI adapter on a Chromebook Pixel 2015 works
only if the HDMI port is in its normal (not reverted) state.
Theorically, the USB chip should provide the information whether or not
the lane are resversed, but I could not find anything in the Intel PRM
regarding this.

So use the technical solution implemented in ChromeOS by Stéphane and
Todd: try to train one lane in the normal setting, if it doesn't work,
then chances are that the lane are reverted.

The ChromeOS commits are:
https://chromium.googlesource.com/chromiumos/third_party/kernel/+/e8c654a0a6d466b3a7b0e84fd27e3a7236a2243e
https://chromium.googlesource.com/chromiumos/third_party/kernel/+/4fed50fad79ba3fde782d913bac2968b2d0262bc

If I could have a Signed-off-by by Stéphane and Todd, that would be even
better :)

I should also note that while testing this, I discovered 2 regressions
in drm-intel-nightly:
- b432e5cfd (drm/i915: BDW clock change support):
  this one prevents the Broadwell-U GPU to correctly set the clock when
  we connect a 4K monitor over HDMI (30.0 Hz)
  Using a lower resolution works (the internal display is 2560x1700)
  I ended up disabling in intel_display.c all of the codes that are
  broadwell specific, and the default are just working.
- aaf5ec2e5 (drm/i915: Handle HPD when it has actually occurred):
  this one raises a storm of errors:
[drm:gen8_irq_handler [i915]] *ERROR* The master control interrupt lied 
(SDE)!
  This doesn't seems to affect the DP output, but having that many
  errors is not always a good sign IMO :)
  Reverting this commit makes them go away.

Cheers,
Benjamin

Benjamin Tissoires (3):
  drm/i915: add parameters to dp_start_link_train and
dp_complete_link_train
  drm/i915: hide errors when probing for a reverse display port
  drm/i915: Support DDI lane reversal for DP

 drivers/gpu/drm/i915/intel_ddi.c |  13 +++
 drivers/gpu/drm/i915/intel_dp.c  | 173 ++-
 drivers/gpu/drm/i915/intel_drv.h |   1 +
 3 files changed, 149 insertions(+), 38 deletions(-)

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

[GIT PULL] Please pull NFS client bugfixes

[Trond Myklebust]

Hi Linus,

The following changes since commit b4839ebe21fc5d543b933d83644981ea73e9ba36:

  nfs: Remove invalid tk_pid from debug message (2015-07-01 11:31:25 -0400)

are available in the git repository at:

  git://git.linux-nfs.org/projects/trondmy/linux-nfs.git tags/nfs-for-4.2-2

for you to fetch changes up to a49c269111a5b3c1fd2a98f36fa27423b94549f8:

  nfs: Fix an oops caused by using other thread's stack space in ASYNC mode 
(2015-07-28 09:07:03 -0400)


NFS client bugfixes for Linux 4.2

Highlights include:

Stable patches:
- Fix a situation where the client uses the wrong (zero) stateid.
- Fix a memory leak in nfs_do_recoalesce

Bugfixes:
- Plug a memory leak when ->prepare_layoutcommit fails
- Fix an Oops in the NFSv4 open code
- Fix a backchannel deadlock
- Fix a livelock in sunrpc when sendmsg fails due to low memory availability
- Don't revalidate the mapping if both size and change attr are up to date
- Ensure we don't miss a file extension when doing pNFS
- Several fixes to handle NFSv4.1 sequence operation status bits correctly
- Several pNFS layout return bugfixes


J. Bruce Fields (1):
  NFSv4.2: handle NFS-specific llseek errors

Jeff Layton (1):
  nfs: plug memory leak when ->prepare_layoutcommit fails

Kinglong Mee (1):
  nfs: Fix an oops caused by using other thread's stack space in ASYNC mode

NeilBrown (1):
  sunrpc: translate -EAGAIN to -ENOBUFS when socket is writable.

Trond Myklebust (24):
  SUNRPC: Don't reencode message if transmission failed with ENOBUFS
  SUNRPC: Don't confuse ENOBUFS with a write_space issue
  NFSv4.1: Handle SEQ4_STATUS_EXPIRED_SOME_STATE_REVOKED status bit 
correctly.
  NFSv4.1: Handle SEQ4_STATUS_RECALLABLE_STATE_REVOKED status bit correctly
  NFSv4.1: Handle SEQ4_STATUS_BACKCHANNEL_FAULT correctly
  NFSv4.1: nfs41_sequence_done should handle sequence flag errors
  NFSv4: Leases are renewed in sequence_done when we have sessions
  NFSv4.2/flexfiles: Fix a typo in the flexfiles layoutstats code
  pNFS: Layoutreturn must invalidate all existing layout segments.
  pNFS: pnfs_roc_drain should return 'true' when sleeping
  pNFS: Fix races between return-on-close and layoutreturn.
  pNFS: pnfs_roc_drain() fix a race with open
  pNFS: Don't throw out valid layout segments
  SUNRPC: Fix a backchannel deadlock
  SUNRPC: xprt_complete_bc_request must also decrement the free slot count
  NFSv4: We must set NFS_OPEN_STATE flag in nfs_resync_open_stateid_locked
  NFSv4/pnfs: Ensure we don't miss a file extension
  NFS: Don't revalidate the mapping if both size and change attr are up to 
date
  NFS: Set NFS_INO_REVAL_PAGECACHE if the change attribute is uninitialised
  NFS: Remove the "NFS_CAP_CHANGE_ATTR" capability
  NFS: nfs_mark_for_revalidate should always set NFS_INO_REVAL_PAGECACHE
  NFS: Fix a memory leak in nfs_do_recoalesce
  NFS: Don't clear desc->pg_moreio in nfs_do_recoalesce()
  SUNRPC: Report TCP errors to the caller

 fs/nfs/client.c|   2 +-
 fs/nfs/flexfilelayout/flexfilelayout.c |   2 +-
 fs/nfs/inode.c |  15 ++---
 fs/nfs/internal.h  |  21 +++
 fs/nfs/nfs42proc.c |  19 ++-
 fs/nfs/nfs4proc.c  |  36 +++-
 fs/nfs/nfs4state.c |  29 +++---
 fs/nfs/pagelist.c  |   7 ++-
 fs/nfs/pnfs.c  | 101 +++--
 fs/nfs/write.c |  15 +++--
 include/linux/nfs_fs.h |   7 ++-
 include/linux/nfs_fs_sb.h  |   2 +-
 net/sunrpc/backchannel_rqst.c  |   6 +-
 net/sunrpc/clnt.c  |   5 +-
 net/sunrpc/xprtsock.c  |  25 +---
 15 files changed, 189 insertions(+), 103 deletions(-)
-- 
Trond Myklebust
Linux NFS client maintainer, PrimaryData
trond.mykleb...@primarydata.com


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

[PATCH 1/3] drm/i915: add parameters to dp_start_link_train and dp_complete_link_train

[Benjamin Tissoires]

In order to detect if the Display Port is reversed or not (when connected
to a USC type-C connector), we need to probe the training with one lane
to check if the polarity is correct.
Factor out the code that we need later on.

This commit has no functional change

Signed-off-by: Benjamin Tissoires 
---
 drivers/gpu/drm/i915/intel_dp.c | 75 ++---
 1 file changed, 47 insertions(+), 28 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index f1b9f93..f2352d8 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -3566,15 +3566,15 @@ static void intel_dp_set_idle_link_train(struct 
intel_dp *intel_dp)
 }
 
 /* Enable corresponding port and start training pattern 1 */
-void
-intel_dp_start_link_train(struct intel_dp *intel_dp)
+static bool
+_intel_dp_start_link_train(struct intel_dp *intel_dp, uint8_t lane_count,
+  uint32_t *DP)
 {
struct drm_encoder *encoder = &dp_to_dig_port(intel_dp)->base.base;
struct drm_device *dev = encoder->dev;
int i;
uint8_t voltage;
int voltage_tries, loop_tries;
-   uint32_t DP = intel_dp->DP;
uint8_t link_config[2];
 
if (HAS_DDI(dev))
@@ -3582,7 +3582,7 @@ intel_dp_start_link_train(struct intel_dp *intel_dp)
 
/* Write the link configuration data */
link_config[0] = intel_dp->link_bw;
-   link_config[1] = intel_dp->lane_count;
+   link_config[1] = lane_count;
if (drm_dp_enhanced_frame_cap(intel_dp->dpcd))
link_config[1] |= DP_LANE_COUNT_ENHANCED_FRAME_EN;
drm_dp_dpcd_write(&intel_dp->aux, DP_LINK_BW_SET, link_config, 2);
@@ -3594,14 +3594,14 @@ intel_dp_start_link_train(struct intel_dp *intel_dp)
link_config[1] = DP_SET_ANSI_8B10B;
drm_dp_dpcd_write(&intel_dp->aux, DP_DOWNSPREAD_CTRL, link_config, 2);
 
-   DP |= DP_PORT_EN;
+   *DP |= DP_PORT_EN;
 
/* clock recovery */
-   if (!intel_dp_reset_link_train(intel_dp, &DP,
+   if (!intel_dp_reset_link_train(intel_dp, DP,
   DP_TRAINING_PATTERN_1 |
   DP_LINK_SCRAMBLING_DISABLE)) {
DRM_ERROR("failed to enable link training\n");
-   return;
+   return false;
}
 
voltage = 0xff;
@@ -3616,7 +3616,7 @@ intel_dp_start_link_train(struct intel_dp *intel_dp)
break;
}
 
-   if (drm_dp_clock_recovery_ok(link_status, 
intel_dp->lane_count)) {
+   if (drm_dp_clock_recovery_ok(link_status, lane_count)) {
DRM_DEBUG_KMS("clock recovery OK\n");
break;
}
@@ -3629,26 +3629,26 @@ intel_dp_start_link_train(struct intel_dp *intel_dp)
DRM_DEBUG_KMS("clock recovery not ok, reset");
/* clear the flag as we are not reusing train set */
intel_dp->train_set_valid = false;
-   if (!intel_dp_reset_link_train(intel_dp, &DP,
+   if (!intel_dp_reset_link_train(intel_dp, DP,
   DP_TRAINING_PATTERN_1 |
   
DP_LINK_SCRAMBLING_DISABLE)) {
DRM_ERROR("failed to enable link training\n");
-   return;
+   return false;
}
continue;
}
 
/* Check to see if we've tried the max voltage */
-   for (i = 0; i < intel_dp->lane_count; i++)
+   for (i = 0; i < lane_count; i++)
if ((intel_dp->train_set[i] & 
DP_TRAIN_MAX_SWING_REACHED) == 0)
break;
-   if (i == intel_dp->lane_count) {
+   if (i == lane_count) {
++loop_tries;
if (loop_tries == 5) {
DRM_ERROR("too many full retries, give up\n");
break;
}
-   intel_dp_reset_link_train(intel_dp, &DP,
+   intel_dp_reset_link_train(intel_dp, DP,
  DP_TRAINING_PATTERN_1 |
  DP_LINK_SCRAMBLING_DISABLE);
voltage_tries = 0;
@@ -3667,21 +3667,31 @@ intel_dp_start_link_train(struct intel_dp *intel_dp)
voltage = intel_dp->train_set[0] & DP_TRAIN_VOLTAGE_SWING_MASK;
 
/* Update training set as requested by target */
-   if (!intel_dp_update_link_train(intel_dp, &DP, link_status)) {
+   if (!intel_dp_update_link_train(intel_dp, DP, link_status)) {
DRM_ERROR("failed to u

[PATCH 2/3] drm/i915: hide errors when probing for a reverse display port

[Benjamin Tissoires]

We check the polarity of the attached dp, so it is normal to fail.
Do not send errors to the users.

Signed-off-by: Benjamin Tissoires 
---
 drivers/gpu/drm/i915/intel_dp.c | 74 -
 1 file changed, 58 insertions(+), 16 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index f2352d8..b740987 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -3568,7 +3568,7 @@ static void intel_dp_set_idle_link_train(struct intel_dp 
*intel_dp)
 /* Enable corresponding port and start training pattern 1 */
 static bool
 _intel_dp_start_link_train(struct intel_dp *intel_dp, uint8_t lane_count,
-  uint32_t *DP)
+  uint32_t *DP, bool probing)
 {
struct drm_encoder *encoder = &dp_to_dig_port(intel_dp)->base.base;
struct drm_device *dev = encoder->dev;
@@ -3576,6 +3576,7 @@ _intel_dp_start_link_train(struct intel_dp *intel_dp, 
uint8_t lane_count,
uint8_t voltage;
int voltage_tries, loop_tries;
uint8_t link_config[2];
+   char *error_str;
 
if (HAS_DDI(dev))
intel_ddi_prepare_link_retrain(encoder);
@@ -3600,7 +3601,11 @@ _intel_dp_start_link_train(struct intel_dp *intel_dp, 
uint8_t lane_count,
if (!intel_dp_reset_link_train(intel_dp, DP,
   DP_TRAINING_PATTERN_1 |
   DP_LINK_SCRAMBLING_DISABLE)) {
-   DRM_ERROR("failed to enable link training\n");
+   error_str = "failed to enable link training\n";
+   if (!probing)
+   DRM_ERROR(error_str);
+   else
+   DRM_DEBUG(error_str);
return false;
}
 
@@ -3612,7 +3617,11 @@ _intel_dp_start_link_train(struct intel_dp *intel_dp, 
uint8_t lane_count,
 
drm_dp_link_train_clock_recovery_delay(intel_dp->dpcd);
if (!intel_dp_get_link_status(intel_dp, link_status)) {
-   DRM_ERROR("failed to get link status\n");
+   error_str = "failed to get link status\n";
+   if (!probing)
+   DRM_ERROR(error_str);
+   else
+   DRM_DEBUG(error_str);
break;
}
 
@@ -3632,7 +3641,11 @@ _intel_dp_start_link_train(struct intel_dp *intel_dp, 
uint8_t lane_count,
if (!intel_dp_reset_link_train(intel_dp, DP,
   DP_TRAINING_PATTERN_1 |
   
DP_LINK_SCRAMBLING_DISABLE)) {
-   DRM_ERROR("failed to enable link training\n");
+   error_str = "failed to enable link training\n";
+   if (!probing)
+   DRM_ERROR(error_str);
+   else
+   DRM_DEBUG(error_str);
return false;
}
continue;
@@ -3645,7 +3658,11 @@ _intel_dp_start_link_train(struct intel_dp *intel_dp, 
uint8_t lane_count,
if (i == lane_count) {
++loop_tries;
if (loop_tries == 5) {
-   DRM_ERROR("too many full retries, give up\n");
+   error_str = "too many full retries, give up\n";
+   if (!probing)
+   DRM_ERROR(error_str);
+   else
+   DRM_DEBUG(error_str);
break;
}
intel_dp_reset_link_train(intel_dp, DP,
@@ -3659,7 +3676,11 @@ _intel_dp_start_link_train(struct intel_dp *intel_dp, 
uint8_t lane_count,
if ((intel_dp->train_set[0] & DP_TRAIN_VOLTAGE_SWING_MASK) == 
voltage) {
++voltage_tries;
if (voltage_tries == 5) {
-   DRM_ERROR("too many voltage retries, give 
up\n");
+   error_str = "too many voltage retries, give 
up\n";
+   if (!probing)
+   DRM_ERROR(error_str);
+   else
+   DRM_DEBUG(error_str);
break;
}
} else
@@ -3668,7 +3689,11 @@ _intel_dp_start_link_train(struct intel_dp *intel_dp, 
uint8_t lane_count,
 
/* Update training set as requested by target */
if (!intel_dp_update_link_train(intel_dp, DP, link_status)) {
-   DRM_ERROR("failed to update link training\n");

[PATCH 3/3] drm/i915: Support DDI lane reversal for DP

[Benjamin Tissoires]

The DP outputs connected through a USB Type-C port can have inverted
lanes. To detect that case, we implement autodetection by training only
the first lane if it doesn't work, we assume that we need to invert
the lanes.

Tested on a Chromebook Pixel 2015 (samus) with a USB Type-C to HDMI
adapter and a Dell 4K and some various regular monitors.

Based on 2 patches from the ChromeOS tree by:
Stéphane Marchesin 
Todd Broch 

Signed-off-by: Benjamin Tissoires 
---
 drivers/gpu/drm/i915/intel_ddi.c | 13 +
 drivers/gpu/drm/i915/intel_dp.c  | 36 
 drivers/gpu/drm/i915/intel_drv.h |  1 +
 3 files changed, 50 insertions(+)

diff --git a/drivers/gpu/drm/i915/intel_ddi.c b/drivers/gpu/drm/i915/intel_ddi.c
index 9a40bfb..0b0c1ec 100644
--- a/drivers/gpu/drm/i915/intel_ddi.c
+++ b/drivers/gpu/drm/i915/intel_ddi.c
@@ -2249,6 +2249,7 @@ static void intel_ddi_pre_enable(struct intel_encoder 
*intel_encoder)
enum port port = intel_ddi_get_encoder_port(intel_encoder);
int type = intel_encoder->type;
int hdmi_level;
+   bool reversed = false;
 
if (type == INTEL_OUTPUT_EDP) {
struct intel_dp *intel_dp = enc_to_intel_dp(encoder);
@@ -2295,8 +2296,20 @@ static void intel_ddi_pre_enable(struct intel_encoder 
*intel_encoder)
if (type == INTEL_OUTPUT_DISPLAYPORT || type == INTEL_OUTPUT_EDP) {
struct intel_dp *intel_dp = enc_to_intel_dp(encoder);
 
+   if (IS_BROADWELL(dev) && type == INTEL_OUTPUT_DISPLAYPORT) {
+   intel_ddi_init_dp_buf_reg(intel_encoder);
+   reversed = intel_dp_is_reversed(intel_dp);
+   }
+
intel_ddi_init_dp_buf_reg(intel_encoder);
 
+   if (IS_BROADWELL(dev)) {
+   if (reversed)
+   intel_dp->DP |= DDI_BUF_PORT_REVERSAL;
+   else
+   intel_dp->DP &= ~DDI_BUF_PORT_REVERSAL;
+   }
+
intel_dp_sink_dpms(intel_dp, DRM_MODE_DPMS_ON);
intel_dp_start_link_train(intel_dp);
intel_dp_complete_link_train(intel_dp);
diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index b740987..18280cc 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -3820,6 +3820,42 @@ intel_dp_complete_link_train(struct intel_dp *intel_dp)
intel_dp->DP = DP;
 }
 
+bool intel_dp_is_reversed(struct intel_dp *intel_dp)
+{
+   struct drm_encoder *encoder = &dp_to_dig_port(intel_dp)->base.base;
+   struct drm_device *dev = encoder->dev;
+   struct drm_i915_private *dev_priv = dev->dev_private;
+   uint32_t DP = intel_dp->DP;
+
+   /*
+* Train with 1 lane. There is no guarantee that the monitor supports
+* 2 or 4 lanes, and we wouldn't see any asymetricity with 4 lanes.
+*/
+   const uint8_t lane_count = 1;
+   bool reversed;
+
+   if (!HAS_DDI(dev))
+   return false;
+
+   DP &= ~(DDI_BUF_PORT_REVERSAL | DDI_PORT_WIDTH(4));
+   DP |= DDI_PORT_WIDTH(lane_count);
+
+   I915_WRITE(intel_dp->output_reg, DP);
+   POSTING_READ(intel_dp->output_reg);
+   udelay(600);
+
+   if (!_intel_dp_start_link_train(intel_dp, lane_count, &DP, true))
+   return true;
+
+   reversed = !_intel_dp_complete_link_train(intel_dp, lane_count, &DP, 
true);
+
+   /* clear training, we had only one lane */
+   intel_dp->train_set_valid = false;
+
+   return reversed;
+
+}
+
 void intel_dp_stop_link_train(struct intel_dp *intel_dp)
 {
intel_dp_set_link_train(intel_dp, &intel_dp->DP,
diff --git a/drivers/gpu/drm/i915/intel_drv.h b/drivers/gpu/drm/i915/intel_drv.h
index 320c9e6..cba00c6 100644
--- a/drivers/gpu/drm/i915/intel_drv.h
+++ b/drivers/gpu/drm/i915/intel_drv.h
@@ -1169,6 +1169,7 @@ int intel_dp_sink_crc(struct intel_dp *intel_dp, u8 *crc);
 bool intel_dp_compute_config(struct intel_encoder *encoder,
 struct intel_crtc_state *pipe_config);
 bool intel_dp_is_edp(struct drm_device *dev, enum port port);
+bool intel_dp_is_reversed(struct intel_dp *intel_dp);
 enum irqreturn intel_dp_hpd_pulse(struct intel_digital_port *intel_dig_port,
  bool long_hpd);
 void intel_edp_backlight_on(struct intel_dp *intel_dp);
-- 
2.4.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] of: Drop owner assignment from platform and i2c driver

[Rob Herring]

On Fri, Jul 10, 2015 at 1:26 AM, Krzysztof Kozlowski
 wrote:
> platform_driver and i2c_driver do not need to set an owner because core
> will set it.
>
> Signed-off-by: Krzysztof Kozlowski 

Applied. Thanks.

Rob

>
> ---
>
> The coccinelle script which generated the patch was sent here:
> http://www.spinics.net/lists/kernel/msg2029903.html
> ---
>  drivers/of/unittest.c | 3 ---
>  1 file changed, 3 deletions(-)
>
> diff --git a/drivers/of/unittest.c b/drivers/of/unittest.c
> index 18016341d5a9..9f71770b6226 100644
> --- a/drivers/of/unittest.c
> +++ b/drivers/of/unittest.c
> @@ -979,7 +979,6 @@ static struct platform_driver unittest_driver = {
> .remove = unittest_remove,
> .driver = {
> .name   = "unittest",
> -   .owner  = THIS_MODULE,
> .of_match_table = of_match_ptr(unittest_match),
> },
>  };
> @@ -1666,7 +1665,6 @@ static const struct i2c_device_id unittest_i2c_dev_id[] 
> = {
>  static struct i2c_driver unittest_i2c_dev_driver = {
> .driver = {
> .name = "unittest-i2c-dev",
> -   .owner = THIS_MODULE,
> },
> .probe = unittest_i2c_dev_probe,
> .remove = unittest_i2c_dev_remove,
> @@ -1761,7 +1759,6 @@ static const struct i2c_device_id unittest_i2c_mux_id[] 
> = {
>  static struct i2c_driver unittest_i2c_mux_driver = {
> .driver = {
> .name = "unittest-i2c-mux",
> -   .owner = THIS_MODULE,
> },
> .probe = unittest_i2c_mux_probe,
> .remove = unittest_i2c_mux_remove,
> --
> 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/

Re: [PATCH RFC 0/1] Document how to add a new syscall

[David Drysdale]

On Tue, Jul 28, 2015 at 3:19 PM, Peter Zijlstra  wrote:
> On Tue, Jul 28, 2015 at 07:59:16AM -0600, Shuah Khan wrote:
>> On 07/28/2015 05:41 AM, David Drysdale wrote:
>> > Given that I've gotten some of the details wrong in the past (and I've
>> > seen others do likewise), I thought it might be helpful to collate the
>> > best practices for adding a new system call to the kernel.
>> >
>> > Apologies for the wide circulation -- I've tried to include folk who've
>> > recently added or proposed a system call, as they're most likely to
>> > have opinions on:
>> >  - whether this a useful addition to Documentation/
>> >  - whether the details of the advice are correct and complete.
>> >
>> > Shuah, is there anything more that should be added for the Testing
>> > section in particular?
>> >
>>
>> David,
>>
>> Looks good. You could add a one liner on in some cases, it might be
>> necessary to install headers before test compiles. Other than that,
>> the information looks good.
>
> For perf we still use the syscall() wrapper and we have hardcoded
> (fallback) syscall numbers in there in case they've not yet reached
> unistd.h.
>
> People update their kernels far more often than their userspace headers.

How about:

diff --git a/Documentation/adding-syscalls.txt
b/Documentation/adding-syscalls.txt
index 5f52edda8951..b274c3d01edb 100644
--- a/Documentation/adding-syscalls.txt
+++ b/Documentation/adding-syscalls.txt
@@ -389,6 +389,11 @@ reviewers with a demonstration of how user space
programs will use the system
 call.  A good way to combine these aims is to include a simple self-test
 program in a new directory under tools/testing/selftests/.

+For a new system call, there will obviously be no libc wrapper function and so
+the test will need to invoke it using syscall(); also, if the system call
+involves a new userspace-visible structure, the corresponding header will need
+to be installed to compile the test.
+
 Make sure the selftest runs successfully on all supported architectures.  For
 example, check that it works when compiled as an x86_64 (-m64), x86_32 (-m32)
 and x32 (-mx32) ABI program.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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: [Xen-devel] [PATCH v4 0/3] x86: modify_ldt improvement, test, and config option

[Boris Ostrovsky]

On 07/28/2015 11:23 AM, Andrew Cooper wrote:

On 28/07/15 15:50, Boris Ostrovsky wrote:

On 07/28/2015 10:35 AM, Andrew Cooper wrote:

On 28/07/15 15:05, Boris Ostrovsky wrote:

On 07/28/2015 06:29 AM, Andrew Cooper wrote:

After forward-porting my virtio patches, I got this thing to run on
Xen.  After several tries, I got:

[   53.985707] [ cut here ]
[   53.986314] kernel BUG at arch/x86/xen/enlighten.c:496!
[   53.986677] invalid opcode:  [#1] SMP
[   53.986677] Modules linked in:
[   53.986677] CPU: 0 PID: 1400 Comm: bash Not tainted 4.2.0-rc4+ #4
[   53.986677] Hardware name: QEMU Standard PC (i440FX + PIIX,
1996),
BIOS rel-1.7.5-0-ge51488c-20140602_164612-nilsson.home.kraxel.org
04/01/2014
[   53.986677] task: c2376180 ti: c0874000 task.ti: c0874000
[   53.986677] EIP: 0061:[] EFLAGS: 00010282 CPU: 0
[   53.986677] EIP is at set_aliased_prot+0xb2/0xc0
[   53.986677] EAX: ffea EBX: cc3d1000 ECX: 0672e063 EDX:
8000
[   53.986677] ESI:  EDI: 8000 EBP: c0875e94 ESP:
c0875e74
[   53.986677]  DS: 007b ES: 007b FS: 00d8 GS: 0033 SS: 0069
[   53.986677] CR0: 80050033 CR2: b77404d4 CR3: 020b6000 CR4:
00042660
[   53.986677] Stack:
[   53.986677]  8000 0672e063 21c0 cc3d1000 0001
cc3d2000
0b4a 0200
[   53.986677]  c0875ea8 c105312d c2317940 c2373a80 
c0875eb4
c1062310 c01861c0
[   53.986677]  c0875ec0 c1062735 c01861c0 c0875ed4 c10a764e
c7007a00
c2373a80 
[   53.986677] Call Trace:
[   53.986677]  [] xen_free_ldt+0x2d/0x40
[   53.986677]  [] free_ldt_struct.part.1+0x10/0x40
[   53.986677]  [] destroy_context+0x25/0x40
[   53.986677]  [] __mmdrop+0x1e/0xc0
[   53.986677]  [] finish_task_switch+0xd8/0x1a0
[   53.986677]  [] __schedule+0x316/0x950
[   53.986677]  [] schedule+0x26/0x70
[   53.986677]  [] do_wait+0x1b3/0x200
[   53.986677]  [] SyS_waitpid+0x67/0xd0
[   53.986677]  [] ? task_stopped_code+0x50/0x50
[   53.986677]  [] syscall_call+0x7/0x7
[   53.986677] Code: e8 c1 e3 0c 81 eb 00 00 00 40 39 5d ec 74 11 8b
4d e4 8b 55 e0 31 f6 e8 dd e0 fa ff 85 c0 75 0d 83 c4 14 5b 5e 5f 5d
c3 90 0f 0b <0f> 0b 0f 0b 8d 76 00 8d bc 27 00 00 00 00 85 d2 74
31 55
89 e5
[   53.986677] EIP: [] set_aliased_prot+0xb2/0xc0 SS:ESP
0069:c0875e74
[   54.010069] ---[ end trace 89ac35b29c1c59bb ]---

Is that the error you're seeing?

If I change xen_free_ldt to:

static void xen_free_ldt(struct desc_struct *ldt, unsigned entries)
{
   const unsigned entries_per_page = PAGE_SIZE / LDT_ENTRY_SIZE;
   int i;

   vm_unmap_aliases();
   xen_mc_flush();

   for(i = 0; i < entries; i += entries_per_page)
   set_aliased_prot(ldt + i, PAGE_KERNEL);
}

then it works.  I don't know why this makes a difference.
(xen_mc_flush makes a little bit of sense to me.  vm_unmap_aliases
doesn't.)


That fix makes sense if there's some way that the vmalloc area we're
freeing has an extra alias somewhere, which is very much
possible.  On
the other hand, I don't see how this happens without first doing an
MMUEXT_SET_LDT with an unexpectedly aliased address, and I would have
expected that to blow up and/or result in test case failures.

But I'm still confused, because it seems like Xen will never populate
the actual (hidden) LDT mapping unless the pages backing it are
unaliased and well-formed, which make me wonder why this stuff ever
worked.  Wouldn't LDT access with pre-existing vmalloc aliases result
in segfaults?

The semantics seem to be very odd.  xen_free_ldt with an aliased
address might fail (and OOPS), but actual access to the LDT with an
aliased address page faults.

Also, using kzalloc for everything fixes the problem, which suggests
that there really is something to my theory that the problem involves
unexpected aliases.

Xen does lazily populate the LDT frames.  The first time a page is
ever
referenced via the LDT, Xen will perform a typechange.

Under Xen, guest mappings are reference counted with both a plain
reference, and a type count.  Types of writeable, segdec and
pagetables
are mutually exclusive.  This prevents the guest from having writeable
mappings of interesting datastructures, but readable mappings are
fine.
Typechanges may only occur when the type reference count is 0.

At the point of the typechange, no writeable mappings of the frame may
exist (and it must not be referenced by a L2 or greater page
directory),
or the typechange will fail.  Additionally the descriptors are audited
at this point, so if Xen objects to any of the descriptors in the same
page, the typechange will also fail.

If the typechange fails, the pagefault gets propagated back to the
guest.

The corollary to this is that, for xen_free_ldt() to create writeable
mappings again, a typechange back to writeable is needed.  This will
fail if the LDT frames are still referenced in any vcpus LDT.

It would be interesting to know which of the two BUG()s in
set_aliased_prot() tripped.

The first one (i.e. not the alias)


In which case the page in question 

Re: [PATCH V3 RESEND 8/8] staging: rtl8712: change SupportedRates to rates

[Dan Carpenter]

On Tue, Jul 28, 2015 at 08:50:04AM -0700, Joshua Clayton wrote:
> On Tuesday, July 28, 2015 05:37:16 PM Julia Lawall wrote:
> > > diff --git a/drivers/staging/rtl8712/rtl871x_ioctl_linux.c 
> > > b/drivers/staging/rtl8712/rtl871x_ioctl_linux.c
> > > index 83d4bca..1ded691 100644
> > > --- a/drivers/staging/rtl8712/rtl871x_ioctl_linux.c
> > > +++ b/drivers/staging/rtl8712/rtl871x_ioctl_linux.c
> > > @@ -204,13 +204,13 @@ static inline char *translate_scan(struct _adapter 
> > > *padapter,
> > >   /* Add the protocol name */
> > >   iwe.cmd = SIOCGIWNAME;
> > >   if ((r8712_is_cckratesonly_included(pnetwork->network.
> > > -  SupportedRates)) == true) {
> > > +  rates)) == true) {
> > >   if (ht_cap == true)
> > >   snprintf(iwe.u.name, IFNAMSIZ, "IEEE 802.11bn");
> > >   else
> > >   snprintf(iwe.u.name, IFNAMSIZ, "IEEE 802.11b");
> > >   } else if ((r8712_is_cckrates_included(pnetwork->network.
> > > - SupportedRates)) == true) {
> > > + rates)) == true) {
> > >   if (ht_cap == true)
> > >   snprintf(iwe.u.name, IFNAMSIZ, "IEEE 802.11bgn");
> > >   else
> > 
> > The placement of the line breaks here is partucularly unpleasant.  Perhaps
> > that could be adjusted now that the field name is shorter.  Theer may be
> > some other cases in the patch where the line breaks could be adjusted to
> > improve readability.
> > 
> > julia
> I agree. Dan Carpenter earlier complained about me fixing up the lines
> while changing the variable name. Should that be a separate patch?
> 

Changing the line breaks here is a tiny change on the same line and so
it's fine.  It fits into the one thing per patch rule.

regards,
dan carpenter

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

Re: [PATCH] of: constify drv arg of of_driver_match_device stub

[Rob Herring]

On Wed, Jul 1, 2015 at 2:10 AM, Tomeu Vizoso  wrote:
> With this change the stub has the same signature as the actual function,
> preventing this compiler warning when building without CONFIG_OF:
>
>drivers/base/property.c: In function 'fwnode_driver_match_device':
>>> drivers/base/property.c:608:38: warning: passing argument 2 of 
>>> 'of_driver_match_device' discards 'const' qualifier from pointer target type
>   return of_driver_match_device(dev, drv);
>  ^
>In file included from drivers/base/property.c:18:0:
>include/linux/of_device.h:61:19: note: expected 'struct device_driver *' 
> but argument is of type 'const struct device_driver *'
> static inline int of_driver_match_device(struct device *dev,
>   ^
>
> Signed-off-by: Tomeu Vizoso 

Applied. Thanks.

Rob

> ---
>  include/linux/of_device.h | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/include/linux/of_device.h b/include/linux/of_device.h
> index 4c50854..cc7dd687 100644
> --- a/include/linux/of_device.h
> +++ b/include/linux/of_device.h
> @@ -59,7 +59,7 @@ void of_dma_configure(struct device *dev, struct 
> device_node *np);
>  #else /* CONFIG_OF */
>
>  static inline int of_driver_match_device(struct device *dev,
> -struct device_driver *drv)
> +const struct device_driver *drv)
>  {
> return 0;
>  }
> --
> 2.4.1
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [f2fs-dev] [PATCH 2/2] f2fs: handle error cases in commit_inmem_pages

[Jaegeuk Kim]

On Tue, Jul 28, 2015 at 06:25:26PM +0800, Chao Yu wrote:
> Hi Jaegeuk,
> 
> > -Original Message-
> > From: Jaegeuk Kim [mailto:jaeg...@kernel.org]
> > Sent: Sunday, July 26, 2015 8:21 AM
> > To: linux-kernel@vger.kernel.org; linux-fsde...@vger.kernel.org;
> > linux-f2fs-de...@lists.sourceforge.net
> > Cc: Jaegeuk Kim
> > Subject: [f2fs-dev] [PATCH 2/2] f2fs: handle error cases in 
> > commit_inmem_pages
> > 
> > This patch adds to handle error cases in commit_inmem_pages.
> > If an error occurs, it stops to write the pages and return the error right
> > away.
> > 
> > Signed-off-by: Jaegeuk Kim 
> > ---
> >  fs/f2fs/f2fs.h|  2 +-
> >  fs/f2fs/file.c|  6 --
> >  fs/f2fs/segment.c | 10 --
> >  3 files changed, 13 insertions(+), 5 deletions(-)
> > 
> > diff --git a/fs/f2fs/f2fs.h b/fs/f2fs/f2fs.h
> > index e73f2e2..58b05b5 100644
> > --- a/fs/f2fs/f2fs.h
> > +++ b/fs/f2fs/f2fs.h
> > @@ -1697,7 +1697,7 @@ void destroy_node_manager_caches(void);
> >   * segment.c
> >   */
> >  void register_inmem_page(struct inode *, struct page *);
> > -void commit_inmem_pages(struct inode *, bool);
> > +int commit_inmem_pages(struct inode *, bool);
> >  void f2fs_balance_fs(struct f2fs_sb_info *);
> >  void f2fs_balance_fs_bg(struct f2fs_sb_info *);
> >  int f2fs_issue_flush(struct f2fs_sb_info *);
> > diff --git a/fs/f2fs/file.c b/fs/f2fs/file.c
> > index 25d1a2f..a2b3656 100644
> > --- a/fs/f2fs/file.c
> > +++ b/fs/f2fs/file.c
> > @@ -1358,7 +1358,9 @@ static int f2fs_ioc_commit_atomic_write(struct file 
> > *filp)
> > 
> > if (f2fs_is_atomic_file(inode)) {
> > clear_inode_flag(F2FS_I(inode), FI_ATOMIC_FILE);
> > -   commit_inmem_pages(inode, false);
> > +   ret = commit_inmem_pages(inode, false);
> > +   if (ret)
> > +   return ret;
> > }
> > 
> > ret = f2fs_sync_file(filp, 0, LLONG_MAX, 0);
> > @@ -1418,7 +1420,7 @@ static int f2fs_ioc_abort_volatile_write(struct file 
> > *filp)
> > 
> > if (f2fs_is_atomic_file(inode)) {
> > clear_inode_flag(F2FS_I(inode), FI_ATOMIC_FILE);
> > -   commit_inmem_pages(inode, false);
> > +   commit_inmem_pages(inode, true);
> > }
> > 
> > if (f2fs_is_volatile_file(inode))
> > diff --git a/fs/f2fs/segment.c b/fs/f2fs/segment.c
> > index f7bfc3b..509a2c4 100644
> > --- a/fs/f2fs/segment.c
> > +++ b/fs/f2fs/segment.c
> > @@ -227,7 +227,7 @@ retry:
> > trace_f2fs_register_inmem_page(page, INMEM);
> >  }
> > 
> > -void commit_inmem_pages(struct inode *inode, bool abort)
> > +int commit_inmem_pages(struct inode *inode, bool abort)
> >  {
> > struct f2fs_sb_info *sbi = F2FS_I_SB(inode);
> > struct f2fs_inode_info *fi = F2FS_I(inode);
> > @@ -239,6 +239,7 @@ void commit_inmem_pages(struct inode *inode, bool abort)
> > .rw = WRITE_SYNC | REQ_PRIO,
> > .encrypted_page = NULL,
> > };
> > +   int err = 0;
> > 
> > /*
> >  * The abort is true only when f2fs_evict_inode is called.
> > @@ -263,8 +264,12 @@ void commit_inmem_pages(struct inode *inode, bool 
> > abort)
> > inode_dec_dirty_pages(inode);
> > trace_f2fs_commit_inmem_page(cur->page, INMEM);
> > fio.page = cur->page;
> > -   do_write_data_page(&fio);
> > +   err = do_write_data_page(&fio);
> > submit_bio = true;
> > +   if (err) {
> > +   unlock_page(cur->page);
> 
> Shouldn't we invoke f2fs_put_page(,1) here?

This entry is not removed from the list.
So, after failure, the abort path will put the page and remove it from the list.

Thanks,

> 
> > +   break;
> > +   }
> > }
> > f2fs_put_page(cur->page, 1);
> > } else {
> > @@ -283,6 +288,7 @@ void commit_inmem_pages(struct inode *inode, bool abort)
> > if (submit_bio)
> > f2fs_submit_merged_bio(sbi, DATA, WRITE);
> > }
> > +   return err;
> >  }
> > 
> >  /*
> > --
> > 2.1.1
> > 
> > 
> > --
> > ___
> > Linux-f2fs-devel mailing list
> > linux-f2fs-de...@lists.sourceforge.net
> > https://lists.sourceforge.net/lists/listinfo/linux-f2fs-devel
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] DEVICETREE: Misc fix for the AR7100 SPI controller binding

[Rob Herring]

On Fri, Jul 3, 2015 at 3:14 AM, Alban Bedel  wrote:
> Fix the clocks property documentation and use lower case for
> hex values in the example.
>
> Signed-off-by: Alban Bedel 

Applied. Thanks.

Rob

> ---
>  Documentation/devicetree/bindings/spi/spi-ath79.txt | 6 +++---
>  1 file changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/Documentation/devicetree/bindings/spi/spi-ath79.txt 
> b/Documentation/devicetree/bindings/spi/spi-ath79.txt
> index f1ad9c3..9c696fa 100644
> --- a/Documentation/devicetree/bindings/spi/spi-ath79.txt
> +++ b/Documentation/devicetree/bindings/spi/spi-ath79.txt
> @@ -3,7 +3,7 @@ Binding for Qualcomm Atheros AR7xxx/AR9xxx SPI controller
>  Required properties:
>  - compatible: has to be "qca,-spi", "qca,ar7100-spi" as fallback.
>  - reg: Base address and size of the controllers memory area
> -- clocks: phandle to the AHB clock.
> +- clocks: phandle of the AHB clock.
>  - clock-names: has to be "ahb".
>  - #address-cells: <1>, as required by generic SPI binding.
>  - #size-cells: <0>, also as required by generic SPI binding.
> @@ -12,9 +12,9 @@ Child nodes as per the generic SPI binding.
>
>  Example:
>
> -   spi@1F00 {
> +   spi@1f00 {
> compatible = "qca,ar9132-spi", "qca,ar7100-spi";
> -   reg = <0x1F00 0x10>;
> +   reg = <0x1f00 0x10>;
>
> clocks = <&pll 2>;
> clock-names = "ahb";
> --
> 2.0.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 1/5] iTCO_wdt: Expose watchdog properties using platform data

[Lee Jones]

On Tue, 28 Jul 2015, Matt Fleming wrote:

> On Tue, 28 Jul, at 04:28:32PM, Lee Jones wrote:
> > On Tue, 28 Jul 2015, Guenter Roeck wrote:
> > 
> > > On 07/28/2015 08:00 AM, Lee Jones wrote:
> > > >On Tue, 28 Jul 2015, Matt Fleming wrote:
> > > >>On Tue, 28 Jul, at 12:37:21PM, Lee Jones wrote:
> > > >>>
> > > >>>The driver shouldn't be called that either.
> > > >>>
> > > >>>You are the only one.  What makes iTCO 'special'?
> > > >>
> > > >>I don't know, I didn't write it. It looks like Wim did ~9 years ago, so
> > > >>it must have made sense to him at the time.
> > > >>
> > > 
> > > Coding style wasn't as strict then as it is today. iTCO has just been kept
> > > for historic reasons.
> > 
> > For sure, I get that, but it doesn't mean we can't do-the-right-thing
> > (tm) now does it?
> > 
> > > Sure, we could have changed it to lowercase, but so far no one bothered.
> > > Plus, of course, there is always the element that some maintainers hate
> > > that kind of cleanup,
> > 
> > Really?
> 
> Yes, really. 

Well then they are silly (replace silly with something less ML
friendly if you like).

> > Surely any kind of clean-up is good clean-up.  Especially as Greg KH
> > et. al, have been doing public presentations telling everyone that
> > there is always kernel work for anyone who has the time; spelling
> > corrections and all.
>  
> That's what staging/ was invented for ;-) Greg is quite happy to take
> those patches, other maintainers are less so.

No, staging was designed to take drivers which are either
controversial or still in a state of flux.  Not to over-rule
maintainers which didn't think a clean-up was important enough for
acceptance.

> > Either do the 5min clean-up or don't, no biggy.  If you don't then I
> > can do it.
> 
> Go for it.
> 
> > At the very least please don't add any _new_ camel case variables or
> > filenames.
> 
> OK, sure.

Great.  Resubmit when ready.

-- 
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/