[PATCH v2 1/5] usb: dwc3: add Fujitsu Specific Glue layer

[Sneeker Yeh]

This patch adds support for Synopsis DesignWare USB3 IP Core found
on Fujitsu Socs.

Signed-off-by: Sneeker Yeh 
---
 .../devicetree/bindings/usb/fujitsu-dwc3.txt   |   33 
 drivers/usb/dwc3/Kconfig   |   11 ++
 drivers/usb/dwc3/Makefile  |1 +
 drivers/usb/dwc3/dwc3-mb86s70.c|  206 
 4 files changed, 251 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/usb/fujitsu-dwc3.txt
 create mode 100644 drivers/usb/dwc3/dwc3-mb86s70.c

diff --git a/Documentation/devicetree/bindings/usb/fujitsu-dwc3.txt 
b/Documentation/devicetree/bindings/usb/fujitsu-dwc3.txt
new file mode 100644
index 000..be091eb
--- /dev/null
+++ b/Documentation/devicetree/bindings/usb/fujitsu-dwc3.txt
@@ -0,0 +1,33 @@
+FUJITSU GLUE COMPONENTS
+
+MB86S7x DWC3 GLUE
+- compatible:  Should be "fujitsu,mb86s70-dwc3"
+- clocks:  from common clock binding, handle to usb clock.
+- clock-names: Should contain the following:
+  "core"   Master/Core clock needs to run at a minimum of 125 MHz to
+   support a 4 Gbps IN or 4 Gbps OUT
+   transfer at a given time.
+
+Sub-nodes:
+The dwc3 core should be added as subnode to MB86S7x dwc3 glue.
+- dwc3 :
+   The binding details of dwc3 can be found in:
+   Documentation/devicetree/bindings/usb/dwc3.txt
+
+Example device nodes:
+
+   usb3host: mb86s70_usb3host {
+   compatible = "fujitsu,mb86s70-dwc3";
+   clocks = <&clk_alw_1_1>;
+   clock-names = "core";
+   #address-cells = <2>;
+   #size-cells = <1>;
+   ranges;
+
+   dwc3@3220 {
+   compatible = "synopsys,dwc3";
+   reg = <0 0x3230 0x10>;
+   interrupts = <0 412 0x4>,
+   <0 414 0x4>;
+   };
+   };
diff --git a/drivers/usb/dwc3/Kconfig b/drivers/usb/dwc3/Kconfig
index 58b5b2c..3390d42 100644
--- a/drivers/usb/dwc3/Kconfig
+++ b/drivers/usb/dwc3/Kconfig
@@ -61,6 +61,17 @@ config USB_DWC3_EXYNOS
  Recent Exynos5 SoCs ship with one DesignWare Core USB3 IP inside,
  say 'Y' or 'M' if you have one such device.
 
+config USB_DWC3_MB86S70
+   tristate "MB86S70 Designware USB3 Platform code"
+   default USB_DWC3
+   help
+ MB86S7X SOC ship with DesignWare Core USB3 IP inside,
+ this implementation also integrated Fujitsu USB PHY inside
+ this Core USB3 IP.
+
+ say 'Y' or 'M' if you have one such device.
+
+
 config USB_DWC3_PCI
tristate "PCIe-based Platforms"
depends on PCI
diff --git a/drivers/usb/dwc3/Makefile b/drivers/usb/dwc3/Makefile
index bb34fbc..05d1de2 100644
--- a/drivers/usb/dwc3/Makefile
+++ b/drivers/usb/dwc3/Makefile
@@ -38,3 +38,4 @@ obj-$(CONFIG_USB_DWC3_PCI)+= dwc3-pci.o
 obj-$(CONFIG_USB_DWC3_KEYSTONE)+= dwc3-keystone.o
 obj-$(CONFIG_USB_DWC3_QCOM)+= dwc3-qcom.o
 obj-$(CONFIG_USB_DWC3_ST)  += dwc3-st.o
+obj-$(CONFIG_USB_DWC3_MB86S70) += dwc3-mb86s70.o
diff --git a/drivers/usb/dwc3/dwc3-mb86s70.c b/drivers/usb/dwc3/dwc3-mb86s70.c
new file mode 100644
index 000..301be76
--- /dev/null
+++ b/drivers/usb/dwc3/dwc3-mb86s70.c
@@ -0,0 +1,206 @@
+/**
+ * dwc3-mb86s70.c - Fujitsu mb86s70 DWC3 Specific Glue layer
+ *
+ * Copyright (c) 2013 - 2014 FUJITSU SEMICONDUCTOR LIMITED
+ * http://jp.fujitsu.com/group/fsl
+ *
+ * Authors: Alice Chan 
+ * Sneeker Yeh 
+ * based on dwc3-exynos.c
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+struct dwc3_mb86s70 {
+   struct device   *dev;
+   struct clk  *clks[5];
+   u8  clk_cnt;
+};
+
+static int dwc3_mb86s70_clk_control(struct device *dev, bool on)
+{
+   struct dwc3_mb86s70 *priv = dev_get_drvdata(dev);
+   int ret, i = priv->clk_cnt;
+
+   if (!on)
+   goto clock_off;
+
+   for (i = 0; i < priv->clk_cnt; i++) {
+   ret = clk_prepare_enable(priv->clks[i]);
+   if (ret) {
+   dev_err(dev, "failed to enable clock[%d]\n", i);
+   on = ret;
+   goto clock_off;
+   }
+   }
+
+   return 0;
+
+clock_off:
+   for (; i > 0;)
+   clk_disable_unprepare(priv->clks[--i]);
+
+   return on;
+}
+
+static int dwc3_mb86s70_remove_child(struct device *dev, void *unused)
+{
+   struct platform_device *pdev = to_platform_device(dev);
+
+   of_device_unregister(pdev);
+
+   return 0;
+}
+
+static int dwc3_mb86s70_pro

Re: [PATCH 1/2] cpufreq-dt: check CPU clock/power domain during initializing

[Viresh Kumar]

On 9 January 2015 at 15:24, pi-cheng.chen  wrote:
> Currently the DT based cpufreq driver is missing some way to check which
> CPUs share clocks. In the 1st patch, CPU clock/power domain information is
> added to the platform_data of cpufreq-dt so that cpufreq-dt driver could
> check which CPUs share clock/power.
>
> Signed-off-by: pi-cheng.chen 
> ---
>  drivers/cpufreq/cpufreq-dt.c | 15 +++
>  include/linux/cpufreq-dt.h   |  6 ++
>  2 files changed, 21 insertions(+)
>
> diff --git a/drivers/cpufreq/cpufreq-dt.c b/drivers/cpufreq/cpufreq-dt.c
> index fde97d6..ff8c266 100644
> --- a/drivers/cpufreq/cpufreq-dt.c
> +++ b/drivers/cpufreq/cpufreq-dt.c
> @@ -296,6 +296,21 @@ static int cpufreq_init(struct cpufreq_policy *policy)
> pd = cpufreq_get_driver_data();
> if (!pd || !pd->independent_clocks)
> cpumask_setall(policy->cpus);
> +   else if (pd && !list_empty(&pd->domain_list)) {
> +   struct list_head *domain_node;
> +
> +   list_for_each(domain_node, &pd->domain_list) {
> +   struct cpufreq_cpu_domain *domain;

Define this with domain_node.

> +
> +   domain = container_of(domain_node,
> + struct cpufreq_cpu_domain, 
> node);
> +   if (!cpumask_test_cpu(policy->cpu, &domain->cpus))
> +   continue;
> +
> +   cpumask_copy(policy->cpus, &domain->cpus);
> +   break;
> +   }
> +   }
>
> of_node_put(np);
>
> diff --git a/include/linux/cpufreq-dt.h b/include/linux/cpufreq-dt.h
> index 0414009..92bffd3 100644
> --- a/include/linux/cpufreq-dt.h
> +++ b/include/linux/cpufreq-dt.h
> @@ -10,6 +10,11 @@
>  #ifndef __CPUFREQ_DT_H__
>  #define __CPUFREQ_DT_H__
>
> +struct cpufreq_cpu_domain {
> +   struct list_head node;
> +   cpumask_t cpus;
> +};
> +
>  struct cpufreq_dt_platform_data {
> /*
>  * True when each CPU has its own clock to control its
> @@ -17,6 +22,7 @@ struct cpufreq_dt_platform_data {
>  * clock.
>  */
> bool independent_clocks;
> +   struct list_head domain_list;
>  };

Though we need to keep only one of these two, but I don't think
any of these will stay for long time. So, its okay..

Looks fine. 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 1/7] r8152: adjust rx_bottom

[Scott Feldman]

On Sun, Jan 18, 2015 at 11:13 PM, Hayes Wang  wrote:
> If a error occurs when submitting rx, skip the remaining submissions
> and try to submit them again next time.
>
> Signed-off-by: Hayes Wang 
> ---
>  drivers/net/usb/r8152.c | 15 +--
>  1 file changed, 13 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/net/usb/r8152.c b/drivers/net/usb/r8152.c
> index 2e22442..78a8917 100644
> --- a/drivers/net/usb/r8152.c
> +++ b/drivers/net/usb/r8152.c
> @@ -1655,7 +1655,7 @@ static int rx_bottom(struct r8152 *tp, int budget)
>  {
> unsigned long flags;
> struct list_head *cursor, *next, rx_queue;
> -   int work_done = 0;
> +   int ret = 0, work_done = 0;
>
> if (!skb_queue_empty(&tp->rx_queue)) {
> while (work_done < budget) {
> @@ -1746,7 +1746,18 @@ find_next_rx:
> }
>
>  submit:
> -   r8152_submit_rx(tp, agg, GFP_ATOMIC);
> +   if (!ret) {
> +   ret = r8152_submit_rx(tp, agg, GFP_ATOMIC);
> +   } else {
> +   urb->actual_length = 0;
> +   list_add_tail(&agg->list, next);

Do you need a spin_lock_irqsave(&tp->rx_lock, flags) around this?

> +   }
> +   }
> +
> +   if (!list_empty(&rx_queue)) {
> +   spin_lock_irqsave(&tp->rx_lock, flags);
> +   list_splice_tail(&rx_queue, &tp->rx_done);
> +   spin_unlock_irqrestore(&tp->rx_lock, flags);
> }
>
>  out1:
> --
> 2.1.0
>
> --
> To unsubscribe from this list: send the line "unsubscribe netdev" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH v2 2/2] powerpc: powernv: winkle: Restore LPCR with LPCR_PECE1 cleared

[Shreyas B. Prabhu]

LPCR_PECE1 bit controls whether decrementer interrupts are allowed to
cause exit from power-saving mode. While waking up from winkle, restoring
LPCR with LPCR_PECE1 set (i.e Decrementer interrupts allowed) can cause
issue in the following scenario:

- All the threads in a core are offlined. The core enters deep winkle.
- Spurious interrupt wakes up a thread in the core. Here LPCR is restored
  with LPCR_PECE1 bit set.
- Since it was a spurious interrupt on a offline thread, the thread clears
  the interrupt and goes back to winkle.
- Here before the thread executes winkle and puts the core into deep winkle,
  if a decrementer interrupt occurs on any of the sibling threads in the core
  that thread wakes up.
- Since in offline loop we are flushing interrupt only in case of external
  interrupt, the decrementer interrupt does not get flushed. So at this stage
  the thread is stuck in this is loop of waking up at 0x100 due to decrementer
  interrupt, not flushing the interrupt as only external interrupts get flushed,
  entering winkle, waking up at 0x100 again.

Fix this by programming PORE to restore LPCR with LPCR_PECE1 bit
cleared when waking up from winkle.

Signed-off-by: Shreyas B. Prabhu 
Cc: Michael Ellerman 
Cc: Paul Mackerras 
Cc: Benjamin Herrenschmidt 
Cc: linuxppc-...@lists.ozlabs.org
---
Changes is v2:
==
Using the helper function introduced in the previous patch.

 arch/powerpc/platforms/powernv/setup.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/powerpc/platforms/powernv/setup.c 
b/arch/powerpc/platforms/powernv/setup.c
index ad0e32e..ded7fc8 100644
--- a/arch/powerpc/platforms/powernv/setup.c
+++ b/arch/powerpc/platforms/powernv/setup.c
@@ -298,7 +298,7 @@ int pnv_save_sprs_for_winkle(void)
 * all cpus at boot. Get these reg values of current cpu and use the
 * same accross all cpus.
 */
-   uint64_t lpcr_val = mfspr(SPRN_LPCR);
+   uint64_t lpcr_val = LPCR_CLEAR_PECE1(mfspr(SPRN_LPCR));
uint64_t hid0_val = mfspr(SPRN_HID0);
uint64_t hid1_val = mfspr(SPRN_HID1);
uint64_t hid4_val = mfspr(SPRN_HID4);
-- 
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/

[PATCH v2 1/2] powerpc: Add helpers for LPCR PECE1 operations

[Shreyas B. Prabhu]

PECE1 bit in LPCR is used to control whether decrementer can cause exit
from powersaving states. PECE1 bit is cleared before entering fastsleep
or deeper powersaving state and it is set on waking up. Since both
cpuidle and cpu offline operations use these powersaving states, add
helper functions to be used in both these places.

Signed-off-by: Shreyas B. Prabhu 
Cc: Michael Ellerman 
Cc: linuxppc-...@lists.ozlabs.org
---
 arch/powerpc/include/asm/reg.h   | 4 
 arch/powerpc/platforms/powernv/smp.c | 4 ++--
 drivers/cpuidle/cpuidle-powernv.c| 3 +--
 3 files changed, 7 insertions(+), 4 deletions(-)

diff --git a/arch/powerpc/include/asm/reg.h b/arch/powerpc/include/asm/reg.h
index c870e38..0847303 100644
--- a/arch/powerpc/include/asm/reg.h
+++ b/arch/powerpc/include/asm/reg.h
@@ -339,6 +339,10 @@
 #define   LPCR_LPES_SH 2
 #define   LPCR_RMI 0x0002  /* real mode is cache inhibit */
 #define   LPCR_HDICE   0x0001  /* Hyp Decr enable (HV,PR,EE) */
+/* LPCR PECE1 helpers. Used to disable/enable wake up due to decrementer */
+#define   LPCR_CLEAR_PECE1(old)(old & ~(u64)LPCR_PECE1)
+#define   LPCR_SET_PECE1(old)  (old | (u64)LPCR_PECE1)
+
 #ifndef SPRN_LPID
 #define SPRN_LPID  0x13F   /* Logical Partition Identifier */
 #endif
diff --git a/arch/powerpc/platforms/powernv/smp.c 
b/arch/powerpc/platforms/powernv/smp.c
index 781ec45..ab61cb0 100644
--- a/arch/powerpc/platforms/powernv/smp.c
+++ b/arch/powerpc/platforms/powernv/smp.c
@@ -165,7 +165,7 @@ static void pnv_smp_cpu_kill_self(void)
/* We don't want to take decrementer interrupts while we are offline,
 * so clear LPCR:PECE1. We keep PECE2 enabled.
 */
-   mtspr(SPRN_LPCR, mfspr(SPRN_LPCR) & ~(u64)LPCR_PECE1);
+   mtspr(SPRN_LPCR, LPCR_CLEAR_PECE1(mfspr(SPRN_LPCR)));
while (!generic_check_cpu_restart(cpu)) {
 
ppc64_runlatch_off();
@@ -203,7 +203,7 @@ static void pnv_smp_cpu_kill_self(void)
if (!generic_check_cpu_restart(cpu))
DBG("CPU%d Unexpected exit while offline !\n", cpu);
}
-   mtspr(SPRN_LPCR, mfspr(SPRN_LPCR) | LPCR_PECE1);
+   mtspr(SPRN_LPCR, LPCR_SET_PECE1(mfspr(SPRN_LPCR)));
DBG("CPU%d coming online...\n", cpu);
 }
 
diff --git a/drivers/cpuidle/cpuidle-powernv.c 
b/drivers/cpuidle/cpuidle-powernv.c
index de61b9a..ed0be4c 100644
--- a/drivers/cpuidle/cpuidle-powernv.c
+++ b/drivers/cpuidle/cpuidle-powernv.c
@@ -69,11 +69,10 @@ static int fastsleep_loop(struct cpuidle_device *dev,
if (unlikely(system_state < SYSTEM_RUNNING))
return index;
 
-   new_lpcr = old_lpcr;
/* Do not exit powersave upon decrementer as we've setup the timer
 * offload.
 */
-   new_lpcr &= ~LPCR_PECE1;
+   new_lpcr = LPCR_CLEAR_PECE1(old_lpcr);
 
mtspr(SPRN_LPCR, new_lpcr);
power7_sleep();
-- 
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 07/10] mfd: rtsx: remove LCTLR defination

[Lee Jones]

On Mon, 19 Jan 2015, 敬锐 wrote:

> 
> On 01/18/2015 08:28 PM, Lee Jones wrote:
> > On Thu, 15 Jan 2015, micky_ch...@realsil.com.cn wrote:
> >
> >> From: Micky Ching 
> >>
> >> To enable/disable ASPM we should find LINK CONTROL register
> >> in PCI config space. All old chip use 0x80 address, but new
> >> chip may use another address, so we using pci_find_capability()
> >> to get LINK CONTROL address.
> >>
> >> rtsx_gops.c was removed, we consider to put some common operations
> >> to this file, but the actual thing is, only a group of chips
> >> are in common ops1, and another group of chips in common ops2,
> >> it is hard to decide put which ops into generic ops file.
> >>
> >> Signed-off-by: Micky Ching 
> >> ---
> >>   drivers/mfd/Makefile |  2 +-
> >>   drivers/mfd/rts5227.c|  2 +-
> >>   drivers/mfd/rts5249.c|  3 +--
> >>   drivers/mfd/rtsx_gops.c  | 37 -
> >>   drivers/mfd/rtsx_pcr.c   | 25 -
> >>   include/linux/mfd/rtsx_pci.h |  9 -
> >>   6 files changed, 23 insertions(+), 55 deletions(-)
> >>   delete mode 100644 drivers/mfd/rtsx_gops.c
> >>
> >> diff --git a/drivers/mfd/Makefile b/drivers/mfd/Makefile
> >> index 53467e2..2cd7e74 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 rtsx_gops.o rts5209.o 
> >> rts5229.o rtl8411.o rts5227.o rts5249.o
> >> +rtsx_pci-objs := rtsx_pcr.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 1f387d4..0c02831 100644
> >> --- a/drivers/mfd/rts5227.c
> >> +++ b/drivers/mfd/rts5227.c
> >> @@ -130,7 +130,7 @@ static int rts5227_optimize_phy(struct rtsx_pcr *pcr)
> >>   {
> >>int err;
> >>   
> >> -  err = rtsx_gops_pm_reset(pcr);
> >> +  err = rtsx_pci_write_register(pcr, PM_CTRL3, D3_DELINK_MODE_EN, 0x00);
> >>if (err < 0)
> >>return err;
> >>   
> >> diff --git a/drivers/mfd/rts5249.c b/drivers/mfd/rts5249.c
> >> index 00208d1..5eb9819 100644
> >> --- a/drivers/mfd/rts5249.c
> >> +++ b/drivers/mfd/rts5249.c
> >> @@ -119,7 +119,6 @@ static int rts5249_extra_init_hw(struct rtsx_pcr *pcr)
> >>rtsx_pci_add_cmd(pcr, WRITE_REG_CMD, PETXCFG, 0xB0, 0xB0);
> >>else
> >>rtsx_pci_add_cmd(pcr, WRITE_REG_CMD, PETXCFG, 0xB0, 0x80);
> >> -  rtsx_pci_add_cmd(pcr, WRITE_REG_CMD, PM_CTRL3, 0x10, 0x00);
> > What's this doing?  Why is it not required anymore?
> PM_CTRL3 have been set in rts5249_optimize_phy, this function
> rts5249_extra_init will be call for rts524A/rts525A, but their PM_CTRL3
> address is redefined to RTS524A_PM_CTRL3, using a different address.
> if we set PM_CTRL3 here, the rts524A/rts525A will also set,
> but it's not a right address.

Okay.

> >>return rtsx_pci_send_cmd(pcr, 100);
> >>   }
> >> @@ -128,7 +127,7 @@ static int rts5249_optimize_phy(struct rtsx_pcr *pcr)
> >>   {
> >>int err;
> >>   
> >> -  err = rtsx_gops_pm_reset(pcr);
> >> +  err = rtsx_pci_write_register(pcr, PM_CTRL3, D3_DELINK_MODE_EN, 0x00);
> >>if (err < 0)
> >>return err;
> >>   
> >> diff --git a/drivers/mfd/rtsx_gops.c b/drivers/mfd/rtsx_gops.c
> >> deleted file mode 100644
> >> index b1a98c6..000
> >> --- a/drivers/mfd/rtsx_gops.c
> >> +++ /dev/null
> >> @@ -1,37 +0,0 @@
> >> -/* 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;
> >> -
> >> -  /* re

RCU CPU stall console spews leads to soft lockup disabled is reasonable ?

[Zhang Zhen]

Hi,

On my x86_64 qemu virtual machine, RCU CPU stall console spews may
lead to soft lockup disabled.

If softlockup_thresh > rcu_cpu_stall_timeout (softlockup_thresh = 2 * 
watchdog_thresh):

/ #
/ # busybox cat /sys/module/rcupdate/parameters/rcu_cpu_stall_timeout
21
/ # echo 60 > /proc/sys/kernel/watchdog_thresh
/ # busybox insmod softlockup_test.ko
[   44.959044] INFO: rcu_preempt detected stalls on CPUs/tasks: {} (detected by 
0, t=21002 jiffies, g=85, c=84, q=4)
[   44.959044] INFO: Stall ended before state dump start
[  107.964045] INFO: rcu_preempt detected stalls on CPUs/tasks: {} (detected by 
0, t=84007 jiffies, g=85, c=84, q=4)
[  107.964045] INFO: Stall ended before state dump start
[  170.969060] INFO: rcu_preempt detected stalls on CPUs/tasks: {} (detected by 
0, t=147012 jiffies, g=85, c=84, q=4)
[  170.969060] INFO: Stall ended before state dump start
[  233.974057] INFO: rcu_preempt detected stalls on CPUs/tasks: {} (detected by 
0, t=210017 jiffies, g=85, c=84, q=4)
[  233.974057] INFO: Stall ended before state dump start
[  296.979059] INFO: rcu_preempt detected stalls on CPUs/tasks: {} (detected by 
0, t=273022 jiffies, g=85, c=84, q=4)
[  296.979059] INFO: Stall ended before state dump start
[  359.984058] INFO: rcu_preempt detected stalls on CPUs/tasks: {} (detected by 
0, t=336027 jiffies, g=85, c=84, q=4)
[  359.984058] INFO: Stall ended before state dump start
[  422.989059] INFO: rcu_preempt detected stalls on CPUs/tasks: {} (detected by 
0, t=399032 jiffies, g=85, c=84, q=4)
[  422.989059] INFO: Stall ended before state dump start
[  485.994056] INFO: rcu_preempt detected stalls on CPUs/tasks: {} (detected by 
0, t=462037 jiffies, g=85, c=84, q=4)
[  485.994056] INFO: Stall ended before state dump start
[  548.999059] INFO: rcu_preempt detected stalls on CPUs/tasks: {} (detected by 
0, t=525042 jiffies, g=85, c=84, q=4)
[  548.999059] INFO: Stall ended before state dump start
[  612.004061] INFO: rcu_preempt detected stalls on CPUs/tasks: {} (detected by 
0, t=588047 jiffies, g=85, c=84, q=4)
[  612.004061] INFO: Stall ended before state dump start
[  675.009058] INFO: rcu_preempt detected stalls on CPUs/tasks: {} (detected by 
0, t=651052 jiffies, g=85, c=84, q=4)
[  675.009058] INFO: Stall ended before state dump start

If softlockup_thresh < rcu_cpu_stall_timeout:

/ #
/ # busybox cat /sys/module/rcupdate/parameters/rcu_cpu_stall_timeout
21
/ # echo 5 > /proc/sys/kernel/watchdog_thresh
/ # busybox insmod softlockup_test.ko
[   38.450061] BUG: soft lockup - CPU#0 stuck for 11s! [busybox:53]
[   52.450061] BUG: soft lockup - CPU#0 stuck for 11s! [busybox:53]
[   66.450073] BUG: soft lockup - CPU#0 stuck for 11s! [busybox:53]
[   80.450060] BUG: soft lockup - CPU#0 stuck for 11s! [busybox:53]
[   94.450061] BUG: soft lockup - CPU#0 stuck for 11s! [busybox:53]

The softlockup_test.ko source code is:
//
#include 
#include 
#include 
#include 

static int hello_start(void)
{
DEFINE_SPINLOCK(hello_lock);
spin_lock_init(&hello_lock);
spin_lock(&hello_lock);
spin_lock(&hello_lock);
return 0;
}

static int __init test_init(void)
{
hello_start();

printk(KERN_INFO "Module init\n");
return 0;
}

static void __exit test_exit(void)
{
printk(KERN_INFO "Module exit!\n");
}

module_init(test_init)
module_exit(test_exit)
MODULE_LICENSE("GPL");
//

My kernel version is v3.10.63, and i checked the kernel source code,

update_process_times
-> run_local_timers
-> hrtimer_run_queues
-> __run_hrtimer
-> watchdog_timer_fn
-> is_softlockup

-> rcu_check_callbacks
-> __rcu_pending
-> check_cpu_stall
-> print_cpu_stall

If softlockup_thresh > rcu_cpu_stall_timeout, print_cpu_stall will print log to 
serial port.

The 8250 serial driver will call serial8250_console_write => 
touch_nmi_watchdog() which reset
watchdog_touch_ts to 0. So the softlockup will not be triggered.

Is this reasonable? Why?
If it is not reasonable, we should adjust the printk loglevel from *KERN_ERR* 
to *KERN_INFO*
in print_cpu_stall.


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] gpu: ipu-v3: wait_for_completion_timeout does not return negativ status

[Philipp Zabel]

Hi Nicholas,

thank you for the patch.

Am Freitag, den 16.01.2015, 11:48 +0100 schrieb Nicholas Mc Guire:
> Signed-off-by: Nicholas Mc Guire 
> ---
> 
> Patch is against 3.19.0-rc3 -next-20150109
> 
> This patch was compiletested with imx_v6_v7_defconfig + 
> CONFIG_RESET_CONTROLLER=y, CONFIG_IMX_IPUV3_CORE=m
> 
>  drivers/gpu/ipu-v3/ipu-dc.c |2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/gpu/ipu-v3/ipu-dc.c b/drivers/gpu/ipu-v3/ipu-dc.c
> index 2326c75..0ffa659 100644
> --- a/drivers/gpu/ipu-v3/ipu-dc.c
> +++ b/drivers/gpu/ipu-v3/ipu-dc.c
> @@ -282,7 +282,7 @@ void ipu_dc_disable_channel(struct ipu_dc *dc)
>   enable_irq(irq);
>   ret = wait_for_completion_timeout(&priv->comp, msecs_to_jiffies(50));
>   disable_irq(irq);
> - if (ret <= 0) {
> + if (ret == 0) {

In addition to this, I think ret should be changed to unsigned long.

regards
Philipp

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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 v10 0/6] Add Skyworks SKY81452 device drivers

[Lee Jones]

On Mon, 19 Jan 2015, Gyungoh Yoo wrote:

> On Sun, Jan 18, 2015 at 05:40:37PM +, Lee Jones wrote:
> > > From: Gyungoh Yoo 
> > > 
> > > This patch set includes regulator and backlight driver for SKY81452.
> > > Also it includes documents for device tree and module.
> > > sky81452-regulator was already applied. So this series doesn't
> > > include it.
> > 
> > Tell us what you need?  What's missing?
> 
> I need DT's Ack for 3/6 and 4/6.

Patch 3 looks simple enough.

Patch 4 _does_ need a DT ack though.

> > > v10:
> > > Removed trivial get_brightness implementations for sky81452-backlight
> > > 
> > > v9:
> > > Removed the change to remove MODULE_VERSION() for sky81452-regulator
> > > 
> > > v8:
> > > Renamed property names for backlight with vendor prefix
> > > Modified gpio-enable property to generic property for GPIO
> > > Made up the example for backlight DT
> > > Changed the DT parsing of regulator using regulator_node and of_match
> > > 
> > > v7:
> > > Modified licensing text to GPLv2
> > > Splitted Kconfig renaming from DT patch
> > > 
> > > v6:
> > > Added new line character at the end of line of dev_err()
> > > 
> > > v5:
> > > Changed DT for regulator : 'lout' node should be defined under 'regulator'
> > > Removed compatible string from sky81452-regulator driver
> > > Modified sky81452-regulator to return EINVAL when of_node is NULL
> > > Move sky81452-backlight.h to include/linux/platform_data
> > > 
> > > v4:
> > > Removed MODULE_VERSION()
> > > Modified license to GPLv2
> > > Removed calling to backlight_device_unregister() in sky81452-backlight
> > > 
> > > v3:
> > > Cleaned-up DBG messages
> > > Cleaned-up DT
> > > Fixed the backlight name from 'sky81452-bl' to 'sky81452-backlight'
> > > Assigned mfd_cell.of_compatible for binding device node
> > > Modified error messages
> > > Modified sky81452-regulator to return ENODATA when of_node is NULL
> > > 
> > > v2:
> > > Split the patches for each sub-system
> > > Added 'reg' attribute for I2C address in device tree documents
> > > Added 'compatible' attribute in child drivers
> > > Renamed CONFIG_SKY81452 to CONFIG_MFD_SKY81452
> > > Changed the dependency from I2C=y to I2C, for CONFIG_MFD_SKY81452
> > > Added message for exception or errors.
> > > Added vendor prefix for Skyworks Solutions, Inc.
> > > Add SKY81452 to the Trivial Devices list
> > > 
> > > Gyungoh Yoo (6):
> > >   mfd: Add support for Skyworks SKY81452 driver
> > >   backlight: Add support Skyworks SKY81452 backlight driver
> > >   devicetree: mfd: Add new SKY81452 mfd binding
> > >   devicetree: backlight: Add new SKY81452 backlight binding
> > >   devicetree: Add vendor prefix for Skyworks Solutions, Inc.
> > >   devicetree: i2c: Add SKY81452 to the Trivial Devices list
> > > 
> > >  .../devicetree/bindings/i2c/trivial-devices.txt|   1 +
> > >  Documentation/devicetree/bindings/mfd/sky81452.txt |  36 +++
> > >  .../devicetree/bindings/vendor-prefixes.txt|   1 +
> > >  .../video/backlight/sky81452-backlight.txt |  29 ++
> > >  drivers/mfd/Kconfig|  12 +
> > >  drivers/mfd/Makefile   |   1 +
> > >  drivers/mfd/sky81452.c | 108 +++
> > >  drivers/video/backlight/Kconfig|  10 +
> > >  drivers/video/backlight/Makefile   |   1 +
> > >  drivers/video/backlight/sky81452-backlight.c   | 334 
> > > +
> > >  include/linux/mfd/sky81452.h   |  31 ++
> > >  include/linux/platform_data/sky81452-backlight.h   |  46 +++
> > >  12 files changed, 610 insertions(+)
> > >  create mode 100644 Documentation/devicetree/bindings/mfd/sky81452.txt
> > >  create mode 100644 
> > > Documentation/devicetree/bindings/video/backlight/sky81452-backlight.txt
> > >  create mode 100644 drivers/mfd/sky81452.c
> > >  create mode 100644 drivers/video/backlight/sky81452-backlight.c
> > >  create mode 100644 include/linux/mfd/sky81452.h
> > >  create mode 100644 include/linux/platform_data/sky81452-backlight.h
> > > 
> > 

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

[PATCH v2 2/7] staging: sm7xxfb: update TODO file

[Sudip Mukherjee]

update the email addresses in the TODO file, also update the final
destination of this driver.

Signed-off-by: Sudip Mukherjee 
---
 drivers/staging/sm7xxfb/TODO | 9 ++---
 1 file changed, 6 insertions(+), 3 deletions(-)

diff --git a/drivers/staging/sm7xxfb/TODO b/drivers/staging/sm7xxfb/TODO
index 1fcead5..7cb0b24 100644
--- a/drivers/staging/sm7xxfb/TODO
+++ b/drivers/staging/sm7xxfb/TODO
@@ -3,7 +3,10 @@ TODO:
 - 2D acceleration support
 - use kernel coding style
 - refine the code and remove unused code
-- move it to drivers/video/sm7xxfb.c
+- move it to drivers/video/fbdev/sm7xxfb.c
 
-Please send any patches to Greg Kroah-Hartman  and
-Teddy Wang .
+Please send any patches to
+   Greg Kroah-Hartman 
+   Sudip Mukherjee 
+   Teddy Wang 
+   Sudip Mukherjee 
-- 
1.8.1.2

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

[PATCH v2 1/7] Revert "staging: sm7xxfb: remove driver"

[Sudip Mukherjee]

This reverts commit "dc93c85235efa5201e9a3c116bc3fbd1afc1a182"

Signed-off-by: Sudip Mukherjee 
---

v2: checkpatch cleanup has been added to the series.
after this series CamelCase is the only pending style related issue.

i have two doubts:
1) will it be easier if i have a git tree somewhere?
2) one of my next patch will have documentation file, that file
should be placed in this folder or the Documentation/fb folder?

 drivers/staging/Kconfig   |2 +
 drivers/staging/Makefile  |1 +
 drivers/staging/sm7xxfb/Kconfig   |   13 +
 drivers/staging/sm7xxfb/Makefile  |1 +
 drivers/staging/sm7xxfb/TODO  |9 +
 drivers/staging/sm7xxfb/sm7xx.h   |  779 
 drivers/staging/sm7xxfb/sm7xxfb.c | 1026 +
 7 files changed, 1831 insertions(+)
 create mode 100644 drivers/staging/sm7xxfb/Kconfig
 create mode 100644 drivers/staging/sm7xxfb/Makefile
 create mode 100644 drivers/staging/sm7xxfb/TODO
 create mode 100644 drivers/staging/sm7xxfb/sm7xx.h
 create mode 100644 drivers/staging/sm7xxfb/sm7xxfb.c

diff --git a/drivers/staging/Kconfig b/drivers/staging/Kconfig
index 9049dd9..06d159d 100644
--- a/drivers/staging/Kconfig
+++ b/drivers/staging/Kconfig
@@ -56,6 +56,8 @@ source "drivers/staging/vt6656/Kconfig"
 
 source "drivers/staging/iio/Kconfig"
 
+source "drivers/staging/sm7xxfb/Kconfig"
+
 source "drivers/staging/xgifb/Kconfig"
 
 source "drivers/staging/emxx_udc/Kconfig"
diff --git a/drivers/staging/Makefile b/drivers/staging/Makefile
index fe26ff1..c31ffbb 100644
--- a/drivers/staging/Makefile
+++ b/drivers/staging/Makefile
@@ -22,6 +22,7 @@ obj-$(CONFIG_VT6655)  += vt6655/
 obj-$(CONFIG_VT6656)   += vt6656/
 obj-$(CONFIG_VME_BUS)  += vme/
 obj-$(CONFIG_IIO)  += iio/
+obj-$(CONFIG_FB_SM7XX) += sm7xxfb/
 obj-$(CONFIG_FB_XGI)   += xgifb/
 obj-$(CONFIG_USB_EMXX) += emxx_udc/
 obj-$(CONFIG_FT1000)   += ft1000/
diff --git a/drivers/staging/sm7xxfb/Kconfig b/drivers/staging/sm7xxfb/Kconfig
new file mode 100644
index 000..e2922ae
--- /dev/null
+++ b/drivers/staging/sm7xxfb/Kconfig
@@ -0,0 +1,13 @@
+config FB_SM7XX
+   tristate "Silicon Motion SM7XX framebuffer support"
+   depends on FB && PCI
+   select FB_CFB_FILLRECT
+   select FB_CFB_COPYAREA
+   select FB_CFB_IMAGEBLIT
+   help
+ Frame buffer driver for the Silicon Motion SM710, SM712, SM721
+ and SM722 chips.
+
+ This driver is also available as a module. The module will be
+ called sm7xxfb. If you want to compile it as a module, say M
+ here and read .
diff --git a/drivers/staging/sm7xxfb/Makefile b/drivers/staging/sm7xxfb/Makefile
new file mode 100644
index 000..48f471c
--- /dev/null
+++ b/drivers/staging/sm7xxfb/Makefile
@@ -0,0 +1 @@
+obj-$(CONFIG_FB_SM7XX) += sm7xxfb.o
diff --git a/drivers/staging/sm7xxfb/TODO b/drivers/staging/sm7xxfb/TODO
new file mode 100644
index 000..1fcead5
--- /dev/null
+++ b/drivers/staging/sm7xxfb/TODO
@@ -0,0 +1,9 @@
+TODO:
+- Dual head support
+- 2D acceleration support
+- use kernel coding style
+- refine the code and remove unused code
+- move it to drivers/video/sm7xxfb.c
+
+Please send any patches to Greg Kroah-Hartman  and
+Teddy Wang .
diff --git a/drivers/staging/sm7xxfb/sm7xx.h b/drivers/staging/sm7xxfb/sm7xx.h
new file mode 100644
index 000..8599861
--- /dev/null
+++ b/drivers/staging/sm7xxfb/sm7xx.h
@@ -0,0 +1,779 @@
+/*
+ * Silicon Motion SM712 frame buffer device
+ *
+ * Copyright (C) 2006 Silicon Motion Technology Corp.
+ * Authors:Ge Wang, gew...@siliconmotion.com
+ * Boyod boyod.y...@siliconmotion.com.cn
+ *
+ * Copyright (C) 2009 Lemote, Inc.
+ * Author: Wu Zhangjin, wuzhang...@gmail.com
+ *
+ *  This file is subject to the terms and conditions of the GNU General Public
+ *  License. See the file COPYING in the main directory of this archive for
+ *  more details.
+ */
+
+#define NR_PALETTE256
+
+#define FB_ACCEL_SMI_LYNX 88
+
+#define SCREEN_X_RES  1024
+#define SCREEN_Y_RES  600
+#define SCREEN_BPP16
+
+/*Assume SM712 graphics chip has 4MB VRAM */
+#define SM712_VIDEOMEMORYSIZE0x0040
+/*Assume SM722 graphics chip has 8MB VRAM */
+#define SM722_VIDEOMEMORYSIZE0x0080
+
+#define dac_reg(0x3c8)
+#define dac_val(0x3c9)
+
+extern void __iomem *smtc_RegBaseAddress;
+#define smtc_mmiowb(dat, reg)  writeb(dat, smtc_RegBaseAddress + reg)
+#define smtc_mmioww(dat, reg)  writew(dat, smtc_RegBaseAddress + reg)
+#define smtc_mmiowl(dat, reg)  writel(dat, smtc_RegBaseAddress + reg)
+
+#define smtc_mmiorb(reg)   readb(smtc_RegBaseAddress + reg)
+#define smtc_mmiorw(reg)   readw(smtc_RegBaseAddress + reg)
+#define smtc_mmiorl(reg)   readl(smtc_RegBaseAddress + reg)
+
+#define SIZE_SR00_SR04  (0x04 - 0x00 + 1)
+#define SIZE_SR10_SR24  (0x24 - 0x10 + 1)
+#define SIZE_SR30_SR75  (0x75 - 0x30 + 1)
+#define 

[PATCH v2 7/7] staging: sm7xxfb: fix alignment

[Sudip Mukherjee]

checkpatch cleanup: alignment should match open parenthesis

Signed-off-by: Sudip Mukherjee 
---
 drivers/staging/sm7xxfb/sm7xxfb.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/drivers/staging/sm7xxfb/sm7xxfb.c 
b/drivers/staging/sm7xxfb/sm7xxfb.c
index 097747c..2ae9fd0 100644
--- a/drivers/staging/sm7xxfb/sm7xxfb.c
+++ b/drivers/staging/sm7xxfb/sm7xxfb.c
@@ -509,7 +509,7 @@ static void sm7xx_set_timing(struct smtcfb_info *sfb)
(i + 0x30) != 0x6a &&
(i + 0x30) != 0x6b)
smtc_seqw(i + 0x30,
-   VGAMode[j].Init_SR30_SR75[i]);
+ VGAMode[j].Init_SR30_SR75[i]);
 
/* init SEQ register SR80 - SR93 */
for (i = 0; i < SIZE_SR80_SR93; i++)
@@ -720,7 +720,7 @@ static void smtc_unmap_mmio(struct smtcfb_info *sfb)
  */
 
 static int smtc_map_smem(struct smtcfb_info *sfb,
-   struct pci_dev *pdev, u_long smem_len)
+struct pci_dev *pdev, u_long smem_len)
 {
sfb->fb.fix.smem_start = pci_resource_start(pdev, 0);
 
@@ -764,7 +764,7 @@ static inline void sm7xx_init_hw(void)
 }
 
 static int smtcfb_pci_probe(struct pci_dev *pdev,
-  const struct pci_device_id *ent)
+   const struct pci_device_id *ent)
 {
struct smtcfb_info *sfb;
u_long smem_size = 0x0080;  /* default 8MB */
-- 
1.8.1.2

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

[PATCH v2 6/7] staging: sm7xxfb: remove unnecessary blank lines

[Sudip Mukherjee]

checkpatch cleanup: blank lines are not necessary before closing brace
and after opening brace.

Signed-off-by: Sudip Mukherjee 
---

these are actually two different checkpatch warning, but am sending
them together as they are of similar type.

 drivers/staging/sm7xxfb/sm7xxfb.c | 4 
 1 file changed, 4 deletions(-)

diff --git a/drivers/staging/sm7xxfb/sm7xxfb.c 
b/drivers/staging/sm7xxfb/sm7xxfb.c
index 6f0469a..097747c 100644
--- a/drivers/staging/sm7xxfb/sm7xxfb.c
+++ b/drivers/staging/sm7xxfb/sm7xxfb.c
@@ -298,7 +298,6 @@ static int smtc_setcolreg(unsigned regno, unsigned red, 
unsigned green,
}
 
return 0;
-
 }
 
 #ifdef __BIG_ENDIAN
@@ -482,7 +481,6 @@ static void sm7xx_set_timing(struct smtcfb_info *sfb)
VGAMode[j].mmSizeY == sfb->height &&
VGAMode[j].bpp == sfb->fb.var.bits_per_pixel &&
VGAMode[j].hz == sfb->hz) {
-
dev_dbg(&sfb->pdev->dev,
"VGAMode[j].mmSizeX=%d VGAMode[j].mmSizeY=%d 
VGAMode[j].bpp=%d VGAMode[j].hz=%d\n",
VGAMode[j].mmSizeX, VGAMode[j].mmSizeY,
@@ -571,7 +569,6 @@ static void sm7xx_set_timing(struct smtcfb_info *sfb)
}
writel((u32) (((m_nScreenStride + 2) << 16) | m_nScreenStride),
   sfb->vp_regs + 0x10);
-
 }
 
 static void smtc_set_timing(struct smtcfb_info *sfb)
@@ -725,7 +722,6 @@ static void smtc_unmap_mmio(struct smtcfb_info *sfb)
 static int smtc_map_smem(struct smtcfb_info *sfb,
struct pci_dev *pdev, u_long smem_len)
 {
-
sfb->fb.fix.smem_start = pci_resource_start(pdev, 0);
 
 #ifdef __BIG_ENDIAN
-- 
1.8.1.2

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

[PATCH v2 5/7] staging: sm7xxfb: no space is necessary after a cast

[Sudip Mukherjee]

checkpatch cleanup: space is not necessary after cast

Signed-off-by: Sudip Mukherjee 
---
 drivers/staging/sm7xxfb/sm7xxfb.c | 12 ++--
 1 file changed, 6 insertions(+), 6 deletions(-)

diff --git a/drivers/staging/sm7xxfb/sm7xxfb.c 
b/drivers/staging/sm7xxfb/sm7xxfb.c
index 6bce9f1..6f0469a 100644
--- a/drivers/staging/sm7xxfb/sm7xxfb.c
+++ b/drivers/staging/sm7xxfb/sm7xxfb.c
@@ -352,8 +352,8 @@ static ssize_t smtcfb_read(struct fb_info *info, char 
__user *buf, size_t
dst++;
}
if (c & 3) {
-   u8 *dst8 = (u8 *) dst;
-   u8 __iomem *src8 = (u8 __iomem *) src;
+   u8 *dst8 = (u8 *)dst;
+   u8 __iomem *src8 = (u8 __iomem *)src;
 
for (i = c & 3; i--;) {
if (i & 1) {
@@ -363,7 +363,7 @@ static ssize_t smtcfb_read(struct fb_info *info, char 
__user *buf, size_t
src8 += 2;
}
}
-   src = (u32 __iomem *) src8;
+   src = (u32 __iomem *)src8;
}
 
if (copy_to_user(buf, buffer, c)) {
@@ -442,8 +442,8 @@ smtcfb_write(struct fb_info *info, const char __user *buf, 
size_t count,
src++;
}
if (c & 3) {
-   u8 *src8 = (u8 *) src;
-   u8 __iomem *dst8 = (u8 __iomem *) dst;
+   u8 *src8 = (u8 *)src;
+   u8 __iomem *dst8 = (u8 __iomem *)dst;
 
for (i = c & 3; i--;) {
if (i & 1) {
@@ -453,7 +453,7 @@ smtcfb_write(struct fb_info *info, const char __user *buf, 
size_t count,
dst8 += 2;
}
}
-   dst = (u32 __iomem *) dst8;
+   dst = (u32 __iomem *)dst8;
}
 
*ppos += c;
-- 
1.8.1.2

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

[PATCH v2 4/7] staging: sm7xxfb: add missing blank line

[Sudip Mukherjee]

checkpatch cleanup to add missing blank line after declaration

Signed-off-by: Sudip Mukherjee 
---
 drivers/staging/sm7xxfb/sm7xxfb.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/drivers/staging/sm7xxfb/sm7xxfb.c 
b/drivers/staging/sm7xxfb/sm7xxfb.c
index c550b71..6bce9f1 100644
--- a/drivers/staging/sm7xxfb/sm7xxfb.c
+++ b/drivers/staging/sm7xxfb/sm7xxfb.c
@@ -259,6 +259,7 @@ static int smtc_setcolreg(unsigned regno, unsigned red, 
unsigned green,
if (regno < 16) {
if (sfb->fb.var.bits_per_pixel == 16) {
u32 *pal = sfb->fb.pseudo_palette;
+
val = chan_to_field(red, &sfb->fb.var.red);
val |= chan_to_field(green, &sfb->fb.var.green);
val |= chan_to_field(blue, &sfb->fb.var.blue);
@@ -273,6 +274,7 @@ static int smtc_setcolreg(unsigned regno, unsigned red, 
unsigned green,
 #endif
} else {
u32 *pal = sfb->fb.pseudo_palette;
+
val = chan_to_field(red, &sfb->fb.var.red);
val |= chan_to_field(green, &sfb->fb.var.green);
val |= chan_to_field(blue, &sfb->fb.var.blue);
-- 
1.8.1.2

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

[PATCH v2 3/7] MAINTAINERS: update for SM7XX driver

[Sudip Mukherjee]

add myself and Teddy Wang as the Maintainer of the
SM7XX FRAME BUFFER DRIVER.

Signed-off-by: Sudip Mukherjee 
---
 MAINTAINERS | 8 
 1 file changed, 8 insertions(+)

diff --git a/MAINTAINERS b/MAINTAINERS
index dbc17b3..4fd647e 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -9220,6 +9220,14 @@ L:   linux-wirel...@vger.kernel.org
 S: Maintained
 F: drivers/staging/rtl8723au/
 
+STAGING - SILICON MOTION SM7XX FRAME BUFFER DRIVER
+M: Sudip Mukherjee 
+M: Teddy Wang 
+M: Sudip Mukherjee 
+L: linux-fb...@vger.kernel.org
+S: Maintained
+F: drivers/staging/sm7xxfb/
+
 STAGING - SLICOSS
 M: Lior Dotan 
 M: Christopher Harrer 
-- 
1.8.1.2

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

Re: [PATCH v2 3/3] Documentation: Add documentation for rt5033 multifunction device

[Lee Jones]

DT Ack please gents.

> This patch device tree binding documentation for rt5033 multifunction device.
> 
> Cc: Sebastian Reichel 
> Cc: Lee Jones 
> Cc: Mark Brown 
> Cc: Rob Herring 
> Cc: Pawel Moll 
> Cc: Mark Rutland 
> Cc: Ian campbell 
> Cc: Kumar Gala 
> Signed-off-by: Beomho Seo 
> Acked-by: Chanwoo Choi 
> ---
> Changes in v2
> - Fix incorrect typo.
> - Align -uamp and -uvolt names with regulator binding suffixes.
> - Drop incorrect phandle.
> - Fix incorrect example.
> ---
>  Documentation/devicetree/bindings/mfd/rt5033.txt   |  101 
> 
>  .../devicetree/bindings/vendor-prefixes.txt|1 +
>  2 files changed, 102 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/mfd/rt5033.txt
> 
> diff --git a/Documentation/devicetree/bindings/mfd/rt5033.txt 
> b/Documentation/devicetree/bindings/mfd/rt5033.txt
> new file mode 100644
> index 000..64b23e8
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/mfd/rt5033.txt
> @@ -0,0 +1,101 @@
> +Richtek RT5033 Power management Integrated Circuit
> +
> +RT5033 is a Multifunction device which includes battery charger, fuel gauge,
> +flash LED current source, LDO and synchronous Buck converter for portable
> +applications. It is interfaced to host controller using i2c interface.
> +
> +Required properties:
> +- compatible : Must be "richtek,rt5033"
> +- reg : Specifies the i2c slave address of general part.
> +- interrupts : This i2c devices has an IRQ line connected to the main SoC.
> +- interrupt-parent : The parent interrupt controller.
> +
> +Optional node:
> +Regulators: The regulators of RT5033 have to be instantiated under sub-node
> +named "regulators" using the following format.
> +
> + regulators {
> + regulator-name {
> + regulator-name = LDO/BUCK
> + regulator subnodes called X, Y and Z
> + };
> + };
> + refer Documentation/devicetree/bindings/regulator/regulator.txt
> +
> +
> +Battery charger: There battery charger of RT5033 have to be instantiated 
> under
> +sub-node named "charger" using the following format.
> +
> +Required properties:
> +- compatible : Must be "richtek,rt5033-charger".
> +- richtek,pre-uamp : Current of pre-charge mode. The pre-charge current 
> levels
> +  are 350 mA to 650 mA programmed by I2C per 100 mA.
> +- richtek,fast-uamp : Current of fast-charge mode. The fast-charge current
> +  levels are 700 mA to 2000 mA programmed by I2C per 100 mA.
> +- richtek,eoc-uamp : This property is end of charge current. Its level 150 mA
> +  to 200 mA.
> +- richtek,pre-threshold-uvolt : Voltage of threshold pre-charge mode. Battery
> +  voltage is below pre-charge threshold voltage, the charger is in pre-charge
> +  mode with pre-charge current. Its levels are 2.3 V  to 3.8 V programmed
> +  by I2C per 0.1 V.
> +- richtek,const-uvolt :  Battery regulation voltage of constant voltage mode.
> +  This voltage level 3.65 V to 4.4 V bye I2C per 0.025 V.
> +
> + charger {
> + compatible = "richtek,rt5033-charger";
> + richtek,pre-uamp = <35>;
> + richtek,fast-uamp = <200>;
> + richtek,eoc-uamp = <25>;
> + richtek,pre-threshold-uvolt = <340>;
> + richtek,const-uvolt = <435>;
> +
> + };
> +
> +
> +Fuelgauge: There fuelgauge of RT5033 to be instantiated node named 
> "fuelgauge"
> +using the following format.
> +
> +Required properties:
> +- compatible = Must be "richtek,rt5033-battery".
> +
> + rt5033@35 {
> + compatible = "richtek,rt5033-battery";
> + interrupt-parent = <&gpx2>;
> + interrupts = <3 0>;
> + reg = <0x35>;
> + };
> +
> +Example:
> +
> + rt5033@34 {
> + compatible = "richtek,rt5033";
> + reg = <0x34>;
> + interrupt-parent = <&gpx1>;
> + interrupts = <5 0>;
> +
> + regulators {
> + buck_reg: BUCK {
> + regulator-name = "BUCK";
> + regulator-min-microvolt = <120>;
> + regulator-max-microvolt = <120>;
> + regulator-always-on;
> + };
> + };
> +
> + charger {
> + compatible = "richtek,rt5033-charger";
> + richtek,pre-uamp = <35>;
> + richtek,fast-uamp = <200>;
> + richtek,eoc-uamp = <25>;
> + richtek,pre-threshold-uvolt = <340>;
> + richtek,const-uvolt = <435>;
> + };
> +
> + };
> +
> + rt5033@35 {
> + compatible = "richtek,rt5033-battery";
> +  

Re: [PATCH 01/12] mfd: syscon: Add atmel-matrix registers definition

[Lee Jones]

On Sun, 18 Jan 2015, Boris Brezillon wrote:

> Hi Lee,
> 
> On Sun, 18 Jan 2015 12:52:59 +
> Lee Jones  wrote:
> 
> > On Wed, 14 Jan 2015, Alexandre Belloni wrote:
> > 
> > > From: Boris Brezillon 
> > > 
> > > AT91 SoCs have a memory range reserved for internal bus configuration.
> > > Expose those registers so that drivers can make use of the matrix syscon
> > > declared in at91 DTs.
> > > 
> > > Signed-off-by: Boris Brezillon 
> > > Acked-by: Lee Jones 
> > > ---
> > >  include/linux/mfd/syscon/atmel-matrix.h | 117 
> > > 
> > >  1 file changed, 117 insertions(+)
> > >  create mode 100644 include/linux/mfd/syscon/atmel-matrix.h
> > 
> > Applied, thanks.
> 
> Actually Nicolas took all the patches in his tree and already sent a PR
> to the arm-soc maintainers [1].
> 
> [1]https://lkml.org/lkml/2015/1/15/542

Very well.  All unapplied.

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

linux-next: build failure after merge of the akpm-current tree

[Stephen Rothwell]

Hi Andrew,

After merging the akpm tree, today's linux-next build (sparc defconfig)
failed like this:

In file included from arch/sparc/include/asm/bug.h:20:0,
 from include/linux/bug.h:4,
 from include/linux/thread_info.h:11,
 from include/asm-generic/preempt.h:4,
 from arch/sparc/include/generated/asm/preempt.h:1,
 from include/linux/preempt.h:18,
 from include/linux/spinlock.h:50,
 from include/linux/mmzone.h:7,
 from include/linux/gfp.h:5,
 from include/linux/slab.h:14,
 from mm/mmap.c:12:
mm/mmap.c: In function 'exit_mmap':
mm/mmap.c:2858:46: error: 'PUD_SHIFT' undeclared (first use in this function)
round_up(FIRST_USER_ADDRESS, PUD_SIZE) >> PUD_SHIFT);
  ^
include/asm-generic/bug.h:86:25: note: in definition of macro 'WARN_ON'
  int __ret_warn_on = !!(condition);\
 ^
mm/mmap.c:2858:46: note: each undeclared identifier is reported only once for 
each function it appears in
round_up(FIRST_USER_ADDRESS, PUD_SIZE) >> PUD_SHIFT);
  ^
include/asm-generic/bug.h:86:25: note: in definition of macro 'WARN_ON'
  int __ret_warn_on = !!(condition);\
 ^

Caused by commit b316feb3c37f ("mm: account pmd page tables to the
process").  32 bit sparc does not seem to define PUD_SHIFT ...

I am not sure what the correct fix is here, so I just did the following
patch for today.

From: Stephen Rothwell 
Date: Mon, 19 Jan 2015 19:10:53 +1100
Subject: [PATCH] mm: account pmd page tables to the process fix

Signed-off-by: Stephen Rothwell 
---
 mm/mmap.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/mm/mmap.c b/mm/mmap.c
index 6a7d36d133fb..25271805ab39 100644
--- a/mm/mmap.c
+++ b/mm/mmap.c
@@ -2854,8 +2854,10 @@ void exit_mmap(struct mm_struct *mm)
 
WARN_ON(atomic_long_read(&mm->nr_ptes) >
round_up(FIRST_USER_ADDRESS, PMD_SIZE) >> PMD_SHIFT);
+#ifdef PUD_SHIFT
WARN_ON(mm_nr_pmds(mm) >
round_up(FIRST_USER_ADDRESS, PUD_SIZE) >> PUD_SHIFT);
+#endif
 }
 
 /* Insert vm structure into process list sorted by address
-- 
2.1.4

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


pgp5V1IAF_FgT.pgp
Description: OpenPGP digital signature

[PATCH] mm/util.c: add a none zero check of "len"

[Pan Xinhui]

Although this check should have been done by caller. But as it's exported to 
others,
It's better to add a none zero check of "len" like other functions.

Signed-off-by: xinhuix.pan 
---
 mm/util.c | 5 +
 1 file changed, 5 insertions(+)

diff --git a/mm/util.c b/mm/util.c
index fec39d4..3dc2873 100644
--- a/mm/util.c
+++ b/mm/util.c
@@ -72,6 +72,9 @@ void *kmemdup(const void *src, size_t len, gfp_t gfp)
 {
void *p;
 
+	if (unlikely(!len))

+   return ERR_PTR(-EINVAL);
+
p = kmalloc_track_caller(len, gfp);
if (p)
memcpy(p, src, len);
@@ -91,6 +94,8 @@ void *memdup_user(const void __user *src, size_t len)
 {
void *p;
 
+	if (unlikely(!len))

+   return ERR_PTR(-EINVAL);
/*
 * Always use GFP_KERNEL, since copy_from_user() can sleep and
 * cause pagefault, which makes it pointless to use GFP_NOFS
--
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-next: Tree for Jan 19

[Stephen Rothwell]

Hi all,

Changes since 20150116:

The i2c tree lost its build failure.

The net-next tree gained a build failure so I used the version from
next-20150116 for today.

The luto-misc tree gained a conflict against the tip tree.

The akpm-current tree gained two build failures for which I added fix
patches.

The akpm tree lost a patch that turned up elsewhere.

Non-merge commits (relative to Linus' tree): 3428
 3316 files changed, 110203 insertions(+), 57548 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 234 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 (ec6f34e5b552 Linux 3.19-rc5)
Merging fixes/master (b94d525e58dc Merge 
git://git.kernel.org/pub/scm/linux/kernel/git/davem/net)
Merging kbuild-current/rc-fixes (a16c5f99a28c kbuild: Fix removal of the 
debian/ directory)
Merging arc-current/for-curr (2ce7598c9a45 Linux 3.17-rc4)
Merging arm-current/fixes (2d9ed7406fd2 ARM: 8255/1: perf: Prevent wraparound 
during overflow)
Merging m68k-current/for-linus (f27bd5bfeda5 m68k: Wire up execveat)
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 (31345e1a071e powerpc/pci: Remove unused 
force_32bit_msi quirk)
Merging powerpc-merge-mpe/fixes (a87e810f61b4 powerpc: Work around gcc bug in 
current_thread_info())
Merging sparc/master (66d0f7ec9f10 sparc32: destroy_context() and switch_mm() 
needs to disable interrupts.)
Merging net/master (2061dcd6bff8 net: sctp: fix race for one-to-many sockets in 
sendmsg's auto associate)
Merging ipsec/master (f855691975bb xfrm6: Fix the nexthdr offset in 
_decode_session6.)
Merging sound-current/for-linus (6455931186bf ALSA: usb-audio: Add mic volume 
fix quirk for Logitech Webcam C210)
Merging pci-current/for-linus (d63e2e1f3df9 sparc/PCI: Clip bridge windows to 
fit in upstream windows)
Merging wireless-drivers/master (781f51d4c203 Merge tag 
'iwlwifi-for-kalle-2015-01-13' of 
https://git.kernel.org/pub/scm/linux/kernel/git/iwlwifi/iwlwifi-fixes)
Merging driver-core.current/driver-core-linus (72392ed0eb6f kernfs: Fix 
kernfs_name_compare)
Merging tty.current/tty-linus (31ec77aca72e serial: samsung: Add the support 
for Exynos5433 SoC)
Merging usb.current/usb-linus (f8359dae68bd Merge tag 'fixes-for-v3.19-rc6' of 
git://git.kernel.org/pub/scm/linux/kernel/git/balbi/usb into usb-linus)
Merging usb-gadget-fixes/fixes (39e60635a015 usb: dwc3: gadget: Stop TRB 
preparation after limit is reached)
Merging usb-serial-fixes/usb-linus (04f9c6e6d175 usb: serial: handle -ENODEV 
quietly in generic_submit_read_urb)
Merging staging.current/staging-linus (a307d1d6d4cf staging: vt6655: fix sparse 
warning: argument type)
Merging char-misc.current/char-misc-linus (7b7c54914f73 mcb: mcb-pci: Only 
remap the 1st 0x200 bytes of BAR 0)
Merging input-current/for-linus (029b18361921 Input: uinput - fix ioctl nr 
overflow for UI_GET_SYSNAME/VERSION)
Merging md-current/for-linus (d47648fcf061 raid5: avoid finding "discard" 
stripe)
Merging crypto-current/master (3e14dcf7cb80 crypto: add missing crypto module 
aliases)
Merging ide/master (f96fe225677b Merge 
git://git.kernel.org/pub/scm/linux/kernel/git/davem/net)
Merging dwmw2/master (5950f0803ca9 pcmcia: remove RPX board stuff)
Merging devicetree-current/devicetree/merge (094cb98179f1 of/fdt: 
memblock_reserve /memreserve/ regions in the case of partial overlap)
Merging rr-f

Re: [PATCH 01/28] PCI: Rip out pci_bus_add_devices() from pci_scan_bus()

[Arnd Bergmann]

On Friday 16 January 2015 15:16:28 Yinghai Lu wrote:
> On Fri, Jan 16, 2015 at 3:15 PM, Yinghai Lu  wrote:
> > On Thu, Jan 15, 2015 at 5:43 PM, Yijing Wang  wrote:
> >> Pci_bus_add_devices() should not be placed in pci_scan_bus().
> >> Now pci device will be added to driver core once its
> >> creation. All things left in pci_bus_add_devices() are
> >> driver attachment and other trivial sysfs things.
> >> Pci_scan_bus() should be the function responsible for
> >> scanning PCI devices, not including driver attachment.
> >> Other, some callers(m68k,unicore32,alpha) of pci_scan_bus()
> >> will call pci_bus_size_bridges() and pci_bus_assign_resources()
> >> after pci_scan_bus().
> >>
> >> E.g.
> >> In m68k
> >> mcf_pci_init()
> >> pci_scan_bus()
> >> ...
> >> pci_bus_add_devices() --- try to attach driver
> >> pci_fixup_irqs()
> >> pci_bus_size_bridges()
> >> pci_bus_assign_resources()
> >>
> >> It is not correct, resources should be assigned correctly
> >> before attaching driver.
> >
> No, for booting path, at that time pci drivers are *NOT* loaded yet.

This may be true for the m68k example, and traditionally for all
PCI hosts, but as we move to a more modular architecture with
drivers/pci/hosts, you can have PCI host drivers that are loadable
modules and get loaded after the built-in drivers are initialized,
or you can have host drivers that depend on a resource (clock,
regulator, reset, gpio, ...) that in turn comes from a driver
that gets initialized later.

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

[PATCH] media: i2c: add new driver for single string flash.

[Daniel Jeong]

This patch adds the driver for the single string flash products of TI.
Several single string flash controllers of TI have similar register map
and bit data. This driver supports four products,lm3556, lm3561, lm3642
and lm3648.

Signed-off-by: Daniel Jeong 
---
 drivers/media/i2c/Kconfig   |9 +
 drivers/media/i2c/Makefile  |1 +
 drivers/media/i2c/ti-ss-flash.c |  744 +++
 include/media/ti-ss-flash.h |   33 ++
 4 files changed, 787 insertions(+)
 create mode 100644 drivers/media/i2c/ti-ss-flash.c
 create mode 100644 include/media/ti-ss-flash.h

diff --git a/drivers/media/i2c/Kconfig b/drivers/media/i2c/Kconfig
index 205d713..886c1fb 100644
--- a/drivers/media/i2c/Kconfig
+++ b/drivers/media/i2c/Kconfig
@@ -638,6 +638,15 @@ config VIDEO_LM3646
  This is a driver for the lm3646 dual flash controllers. It controls
  flash, torch LEDs.
 
+config VIDEO_TI_SS_FLASH
+   tristate "TI Single String Flash driver support"
+   depends on I2C && VIDEO_V4L2 && MEDIA_CONTROLLER
+   depends on MEDIA_CAMERA_SUPPORT
+   select REGMAP_I2C
+   ---help---
+ This is a driver for the signle string flash controllers of TI.
+ It supports LM3556, LM3561, LM3642 and LM3648.
+
 comment "Video improvement chips"
 
 config VIDEO_UPD64031A
diff --git a/drivers/media/i2c/Makefile b/drivers/media/i2c/Makefile
index 98589001..0e523ec 100644
--- a/drivers/media/i2c/Makefile
+++ b/drivers/media/i2c/Makefile
@@ -73,6 +73,7 @@ obj-$(CONFIG_VIDEO_ADP1653)   += adp1653.o
 obj-$(CONFIG_VIDEO_AS3645A)+= as3645a.o
 obj-$(CONFIG_VIDEO_LM3560) += lm3560.o
 obj-$(CONFIG_VIDEO_LM3646) += lm3646.o
+obj-$(CONFIG_VIDEO_TI_SS_FLASH)+= ti-ss-flash.o
 obj-$(CONFIG_VIDEO_SMIAPP_PLL) += smiapp-pll.o
 obj-$(CONFIG_VIDEO_AK881X) += ak881x.o
 obj-$(CONFIG_VIDEO_IR_I2C)  += ir-kbd-i2c.o
diff --git a/drivers/media/i2c/ti-ss-flash.c b/drivers/media/i2c/ti-ss-flash.c
new file mode 100644
index 000..035aeba
--- /dev/null
+++ b/drivers/media/i2c/ti-ss-flash.c
@@ -0,0 +1,744 @@
+/*
+ * drivers/media/i2c/ti-ss-flash.c
+ * General device driver for Single String FLASH LED Drivers of TI
+ * It covers lm3556, lm3561, lm3642 and lm3648.
+ *
+ * Copyright (C) 2015 Texas Instruments
+ *
+ * Contact: Daniel Jeong 
+ * Ldd-Mlp 
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License
+ * version 2 as published by the Free Software Foundation.
+ *
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+/* operation mode */
+enum led_opmode {
+   OPMODE_SHDN = 0x0,
+   OPMODE_INDI_IR,
+   OPMODE_TORCH,
+   OPMODE_FLASH,
+};
+
+/*
+ * register data
+ * @reg : register
+ * @mask : mask bits
+ * @shift : bit shift of data
+ */
+struct ctrl_reg {
+   unsigned int reg;
+   unsigned int mask;
+   unsigned int shift;
+};
+
+/*
+ * unit data
+ * @min : min value of brightness or timeout
+ *brightness : uA
+ *   timeout: ms
+ * @step : step value of brightness or timeout
+ *brightness : uA
+ *   timeout: ms
+ * @knee: knee point of step of brightness/timeout
+ *brightness : uA
+ *   timeout: ms
+ * @knee_step : step value of brightness or timeout after knee point
+ *brightness : uA
+ *   timeout: ms
+ * @max : max value of brightness or timeout
+ *brightness : uA
+ *   timeout: ms
+ * @ctrl : register info to control brightness or timeout
+ */
+struct ssflash_config {
+   unsigned int min;
+   unsigned int step;
+   unsigned int knee;
+   unsigned int knee_step;
+   unsigned int max;
+   struct ctrl_reg ctrl;
+};
+
+/*
+ * @reg : fault register
+ * @mask : fault mask bit
+ * @v4l2_fault : bit mapping to V4L2_FLASH_FAULT_
+ *   refer to include//uapi/linux/v4l2-controls.h
+ */
+struct ssflash_fault {
+   unsigned int reg;
+   unsigned int mask;
+   unsigned int v4l2_fault;
+};
+
+#define NUM_V4L2_FAULT 9
+
+/*
+ * ssflash data
+ * @name: device name
+ * @mode: operation mode control data
+ * @flash_br: flash brightness register and bit data
+ * @timeout: timeout control data
+ * @strobe: strobe control data
+ * @torch_br: torch brightness register and bit data
+ * @fault: fault data
+ * @func: initialize function
+ */
+struct ssflash_data {
+   char *name;
+   struct ctrl_reg mode;
+   struct ssflash_config flash_br;
+   struct ssflash_config timeout;
+   struct ctrl_reg strobe;
+
+   struct ssflash_config torch_br;
+   struct ssflash_fault fault[NUM_V4L2_FAULT];
+
+   int (*func)(struct regmap *regmap);
+};
+
+/*
+ * struct ssflash_flash
+ * @dev: device
+ * @regmap: reg map for interface
+ * @ctrls_led: V4L2 contols
+ * @subdev_led: V4L2 subdev
+ * @data : chip contro

Re: [PATCH 1/1] scripts/recordmcount.pl: There is no -m32 option on Super-H

[John Paul Adrian Glaubitz]

Hi Steven!

>> The Super-H architecure seems to be without any maintainer.
>> Maybe Steven cares to pick this patch up. Dunno...

> Yeah, I remember when the SH maintainer left.

> I can pick it up. How urgent is it? Does it need to go in before the
> next merge window? And does it need to be tagged for stable?

I am one of the Debian porters of the SH port. Currently, the kernel
package fails to build from source on our automatic build machines
due to this bug. Here is the full build log where you can see it
fail with gcc-4.8:

>
http://buildd.debian-ports.org/status/fetch.php?pkg=linux&arch=sh4&ver=3.16.7-ckt4-1&stamp=1421425783

Since the SH port of Debian was long time poorly maintained, this
issue hasn't got any attention for quite a while which means the
most current kernel version we have at the moment on SH is 3.2.0
something. I asked Michael to submit this change on my behalf since
he has submitted kernel patches in the past.

Thus, it would be nice if this fix could be merged ASAP upstream
and included in all stable releases as well such that we get a
working up-to-date kernel on SH soon.

Thanks!
Adrian

-- 
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer - glaub...@debian.org
`. `'   Freie Universitaet Berlin - glaub...@physik.fu-berlin.de
  `-GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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: module: fix module_refcount() return when running in a module exit routine

[Christoph Hellwig]

On Mon, Jan 19, 2015 at 04:21:15PM +1030, Rusty Russell wrote:
> The first one I think should be eliminated, and the second one is simply
> an assertion before calling module_put() (which should probably be
> eliminated).  The others are just printing information.

FYI, I've got a pathcset to eliminate the use of module_refcount in
SCSI, which was a horrible hack to start with, but it needs a little more
clarification / work, so I'd prefer to do it for 3.20.  Bart has a fix
that eliminates it for 3.19, which piles aother bandaid over the bandaid
that introduced the use module_refcount, and James doesn't seem to like
it.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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: File sealing man pages for review (memfd_create(2), fcntl(2))

[Michael Kerrisk (man-pages)]

Hello David,

Thanks for reviewing the pages! I'll trim everything that we agree 
on, and just comment on a few remaining points.

On 01/18/2015 11:28 PM, David Herrmann wrote:
> Hi
> 
> On Fri, Jan 9, 2015 at 1:49 PM, Michael Kerrisk (man-pages)
>  wrote:

[...]

>>  memfd_create.2 
>>
>> .\" Copyright (C) 2014 Michael Kerrisk 
>> .\" and Copyright (C) 2014 David Herrmann 
>> .\"
>> .\" %%%LICENSE_START(GPLv2+_SW_3_PARA)
>> .\"
>> .\" FIXME What is _SW_3_PARA?
> 
> No idea.. if that's due to my initial version, please feel free to drop it.

Dropped.

[...]

>> Therefore, files created by
>> .BR memfd_create ()
>> are subject to the same restrictions as other anonymous
>> .\" FIXME Can you give some examples of some of the restrictions please.
> 
> memfd uses VM_NORESERVE so each page is accounted on first access.
> This means, the overcommit-limits (see __vm_enough_memory()) and the
> memory-cgroup limits (mem_cgroup_try_charge()) are applied. Note that
> those are accounted on "current" and "current->mm", that is, the
> process doing the first page access.

Thanks for the info. That's probably more detail than we need to go 
into here. I've reworded the text more openly as:

"have the same semantics as other anonymous memory allocations"

>> memory allocations such as those allocated using
>> .BR mmap (2)
>> with the
>> .BR MAP_ANONYMOUS
>> flag.
>>
>> The initial size of the file is set to 0.
>> .\" FIXME I added the following sentence. Please review.
> 
> Looks good. It's not needed if you use write(), as it adjusts the size
> accordingly. But people usually use mmap() so the recommendation
> sounds useful.

I added mention of "write(2) (and similar)" as well.

[...]

>> Names do not affect the behavior of the memfd,
>> .\" FIXME The term "memfd" appears here without having previously been
>> .\"   defined. Would the correct definition of "the memfd" be
>> .\"   "the file descriptor created by memfd_create"?
> 
> Yes.

Okay -- I've reworded two instances of the work "memfd" away,
replacing them with fuller wording such as my definition above.

[...]

>> .TP
>> .BR MFD_ALLOW_SEALING
>> Allow sealing operations on this file.
>> See the discussion of the
>> .B F_ADD_SEALS
>> and
>> .BR F_GET_SEALS
>> operations in
>> .BR fcntl (2),
>> and also NOTES, below.
>> The initial set of seals is empty.
>> If this flag is not set, the initial set of seals will be
>> .BR F_SEAL_SEAL ,
>> meaning that no other seals can be set on the file.
>> .\" FIXME Why is the MFD_ALLOW_SEALING behavior not simply the default?
>> .\"   Is it worth adding some text explaining this?
> 
> memfds are quite useful without sealing. It's a replacement for files
> in /tmp or O_TMPFILE if you never intended to actually link the file
> anywhere. Therefore, sealing is not enabled by default.

Good stuff! I've added those details to the page.

[...]

>> An example of the usage of the sealing mechanism is as follows:
>>
>> .IP 1. 3
>> The first process creates a
>> .I tmpfs
>> file using
>> .BR memfd_create ().
>> The call yields a file descriptor used in subsequent steps.
>> .IP 2.
>> The first process
>> sizes the file created in the previous step using
>> .BR ftruncate (2),
>> maps it using
>> .BR mmap (2),
>> and populates the shared memory with the desired data.
>> .IP 3.
>> The first process uses the
>> .BR fcntl (2)
>> .B F_ADD_SEALS
>> operation to place one or more seals on the file,
>> in order to restrict further modifications on the file.
>> (If placing the seal
>> .BR F_SEAL_WRITE ,
>> then it will be necessary to first unmap the shared writable mapping
>> created in the previous step.)
>> .IP 4.
>> A second process obtains a file descriptor for the
>> .I tmpfs
>> file and maps it.
>> This could happen in one of two ways:
> 
> 3rd case: file-descriptor passing via AF_UNIX. Further mechanisms
> (like kdbus) might allow fd-passing in the future, so I would reword
> this to an example, not a definite list.

Thanks. I reworded to indicate that these are examples, and also
added FD passing (as the first item in the list of examples).

> Also note that in you examples (opening /proc or fork()) you have a
> natural trust-relationship as you run as the same uid. So in those
> cases sealing is usually not needed.

Good point. I added that point, pretty much using your words.

[...]

>> .SH SEE ALSO
>> .BR fcntl (2),
>> .BR ftruncate (2),
>> .BR mmap (2),
>> .\" FIXME Why the reference to shmget(2) in particular (and not,
>> .\"   e.g., shm_open(3))?
> 
> No particular reason.

Okay -- for completeness, I added shm_open(3).

>> .BR shmget (2)
>>
>>  fcntl.2 (partial) 
>> ...
>> .SH DESCRIPTION
>> ...
>> .SS File Sealing

[...]

>> and
>> .BR fallocate (2).
>> These calls will fail with
>> .B EPERM
>> if you use them to increase the file size or write beyond size boundaries.
>> .\" FIXME What does "size boundaries" mean here?
> 
> It means wr

Re: [PATCH v3 1/3] dt-bindings: mfd: add lubbock-io binding

[Lee Jones]

On Fri, 16 Jan 2015, Robert Jarzmik wrote:

> Add a binding for lubbock motherboard IO board.
> 
> Signed-off-by: Robert Jarzmik 
> ---
>  .../devicetree/bindings/mfd/lubbock-io.txt | 26 
> ++
>  1 file changed, 26 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/mfd/lubbock-io.txt
> 
> diff --git a/Documentation/devicetree/bindings/mfd/lubbock-io.txt 
> b/Documentation/devicetree/bindings/mfd/lubbock-io.txt
> new file mode 100644
> index 000..33c9e21
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/mfd/lubbock-io.txt
> @@ -0,0 +1,26 @@
> +Intel's pxa255 system development platform motherboard.

s/pxa25/PXA25/

"system development platform motherboard" doesn't quite sit right with me.

How about "Intel Xscale PXA255 development platform (Lubbock)"?

> +This is the motherboard, or IO board, of the pxa25x development system,
> +supporting a lubbock pxa25x SoC board.

Again, this sounds weird.

> +Required properties:
> +  - compatible : One of the following chip-specific strings:
> +"intel,lubbock-io"

An odd thing to say with only one entry.

Also, please line it up to the right of the ':' above.

> +  - interrupts : The first interrupt is the line the /IRQ signal the IO board
> + multiplex is connected to. The only known case is GPIO0 on 
> the
> + pxa25x SoC.

Can you get someone to help you re-word this into a more fluid
sentence?

> +Optional properties:
> +  - interrupts : The second optional interrupt is the base of the interrupts
> + multiplexed by the lubbock motherboard. If unspecified, the
> + range is fully dynamic, and the irqdomain will generate its
> + interrupt base on the fly.
> +
> +Example:
> +
> +mb: lubbock-mb@0 {
> + compatible = "intel,lubbock-io";
> + interrupts = <0 IRQ_TYPE_EDGE_FALLING 400 IRQ_TYPE_NONE>;
> + #interrupt-cells = <2>;
> +interrupt-parent = <&pxairq>;

Whitespace error.

> +};

I'm guessing mb means motherboard?  I think it's unusual for a
motherboard to have it's own driver.  Usually we provide drivers for
the individual components/peripherals situated on the board.

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

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

[Cyrill Gorcunov]

On Mon, Jan 19, 2015 at 07:17:18PM +1100, Stephen Rothwell wrote:
> Hi Andrew,
> 
> After merging the akpm tree, today's linux-next build (sparc defconfig)
> failed like this:
> 
> In file included from arch/sparc/include/asm/bug.h:20:0,
>  from include/linux/bug.h:4,
>  from include/linux/thread_info.h:11,
>  from include/asm-generic/preempt.h:4,
>  from arch/sparc/include/generated/asm/preempt.h:1,
>  from include/linux/preempt.h:18,
>  from include/linux/spinlock.h:50,
>  from include/linux/mmzone.h:7,
>  from include/linux/gfp.h:5,
>  from include/linux/slab.h:14,
>  from mm/mmap.c:12:
> mm/mmap.c: In function 'exit_mmap':
> mm/mmap.c:2858:46: error: 'PUD_SHIFT' undeclared (first use in this function)
> round_up(FIRST_USER_ADDRESS, PUD_SIZE) >> PUD_SHIFT);
>   ^
> include/asm-generic/bug.h:86:25: note: in definition of macro 'WARN_ON'
>   int __ret_warn_on = !!(condition);\
>  ^
> mm/mmap.c:2858:46: note: each undeclared identifier is reported only once for 
> each function it appears in
> round_up(FIRST_USER_ADDRESS, PUD_SIZE) >> PUD_SHIFT);
>   ^
> include/asm-generic/bug.h:86:25: note: in definition of macro 'WARN_ON'
>   int __ret_warn_on = !!(condition);\
>  ^
> 
> Caused by commit b316feb3c37f ("mm: account pmd page tables to the
> process").  32 bit sparc does not seem to define PUD_SHIFT ...
> 
> I am not sure what the correct fix is here, so I just did the following
> patch for today.
> 
> From: Stephen Rothwell 
> Date: Mon, 19 Jan 2015 19:10:53 +1100
> Subject: [PATCH] mm: account pmd page tables to the process fix
> 
> Signed-off-by: Stephen Rothwell 
> ---
>  mm/mmap.c | 2 ++
>  1 file changed, 2 insertions(+)
> 
> diff --git a/mm/mmap.c b/mm/mmap.c
> index 6a7d36d133fb..25271805ab39 100644
> --- a/mm/mmap.c
> +++ b/mm/mmap.c
> @@ -2854,8 +2854,10 @@ void exit_mmap(struct mm_struct *mm)
>  
>   WARN_ON(atomic_long_read(&mm->nr_ptes) >
>   round_up(FIRST_USER_ADDRESS, PMD_SIZE) >> PMD_SHIFT);
> +#ifdef PUD_SHIFT
>   WARN_ON(mm_nr_pmds(mm) >
>   round_up(FIRST_USER_ADDRESS, PUD_SIZE) >> PUD_SHIFT);
> +#endif
>  }
>  
>  /* Insert vm structure into process list sorted by address

Looks like it should be #ifdef CONFIG_MMU, Kirill?
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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: RCU CPU stall console spews leads to soft lockup disabled is reasonable ?

[Paul E. McKenney]

On Mon, Jan 19, 2015 at 04:07:15PM +0800, Zhang Zhen wrote:
> Hi,
> 
> On my x86_64 qemu virtual machine, RCU CPU stall console spews may
> lead to soft lockup disabled.
> 
> If softlockup_thresh > rcu_cpu_stall_timeout (softlockup_thresh = 2 * 
> watchdog_thresh):
> 
> / #
> / # busybox cat /sys/module/rcupdate/parameters/rcu_cpu_stall_timeout
> 21
> / # echo 60 > /proc/sys/kernel/watchdog_thresh
> / # busybox insmod softlockup_test.ko
> [   44.959044] INFO: rcu_preempt detected stalls on CPUs/tasks: {} (detected 
> by 0, t=21002 jiffies, g=85, c=84, q=4)
> [   44.959044] INFO: Stall ended before state dump start
> [  107.964045] INFO: rcu_preempt detected stalls on CPUs/tasks: {} (detected 
> by 0, t=84007 jiffies, g=85, c=84, q=4)
> [  107.964045] INFO: Stall ended before state dump start
> [  170.969060] INFO: rcu_preempt detected stalls on CPUs/tasks: {} (detected 
> by 0, t=147012 jiffies, g=85, c=84, q=4)
> [  170.969060] INFO: Stall ended before state dump start
> [  233.974057] INFO: rcu_preempt detected stalls on CPUs/tasks: {} (detected 
> by 0, t=210017 jiffies, g=85, c=84, q=4)
> [  233.974057] INFO: Stall ended before state dump start
> [  296.979059] INFO: rcu_preempt detected stalls on CPUs/tasks: {} (detected 
> by 0, t=273022 jiffies, g=85, c=84, q=4)
> [  296.979059] INFO: Stall ended before state dump start
> [  359.984058] INFO: rcu_preempt detected stalls on CPUs/tasks: {} (detected 
> by 0, t=336027 jiffies, g=85, c=84, q=4)
> [  359.984058] INFO: Stall ended before state dump start
> [  422.989059] INFO: rcu_preempt detected stalls on CPUs/tasks: {} (detected 
> by 0, t=399032 jiffies, g=85, c=84, q=4)
> [  422.989059] INFO: Stall ended before state dump start
> [  485.994056] INFO: rcu_preempt detected stalls on CPUs/tasks: {} (detected 
> by 0, t=462037 jiffies, g=85, c=84, q=4)
> [  485.994056] INFO: Stall ended before state dump start
> [  548.999059] INFO: rcu_preempt detected stalls on CPUs/tasks: {} (detected 
> by 0, t=525042 jiffies, g=85, c=84, q=4)
> [  548.999059] INFO: Stall ended before state dump start
> [  612.004061] INFO: rcu_preempt detected stalls on CPUs/tasks: {} (detected 
> by 0, t=588047 jiffies, g=85, c=84, q=4)
> [  612.004061] INFO: Stall ended before state dump start
> [  675.009058] INFO: rcu_preempt detected stalls on CPUs/tasks: {} (detected 
> by 0, t=651052 jiffies, g=85, c=84, q=4)
> [  675.009058] INFO: Stall ended before state dump start
> 
> If softlockup_thresh < rcu_cpu_stall_timeout:
> 
> / #
> / # busybox cat /sys/module/rcupdate/parameters/rcu_cpu_stall_timeout
> 21
> / # echo 5 > /proc/sys/kernel/watchdog_thresh
> / # busybox insmod softlockup_test.ko
> [   38.450061] BUG: soft lockup - CPU#0 stuck for 11s! [busybox:53]
> [   52.450061] BUG: soft lockup - CPU#0 stuck for 11s! [busybox:53]
> [   66.450073] BUG: soft lockup - CPU#0 stuck for 11s! [busybox:53]
> [   80.450060] BUG: soft lockup - CPU#0 stuck for 11s! [busybox:53]
> [   94.450061] BUG: soft lockup - CPU#0 stuck for 11s! [busybox:53]
> 
> The softlockup_test.ko source code is:
> //
> #include 
> #include 
> #include 
> #include 
> 
> static int hello_start(void)
> {
> DEFINE_SPINLOCK(hello_lock);
> spin_lock_init(&hello_lock);
> spin_lock(&hello_lock);
> spin_lock(&hello_lock);

Did you really intend to acquire the same spinlock twice in a row,
forcing a self-deadlock?  If not, I of course suggest changing the second
"spin_lock()" to "spin_unlock()".

If your .config has CONFIG_TREE_RCU=y, the above is quite likely to
give you an RCU CPU stall warning.

> return 0;
> }
> 
> static int __init test_init(void)
> {
> hello_start();
> 
> printk(KERN_INFO "Module init\n");
> return 0;
> }
> 
> static void __exit test_exit(void)
> {
> printk(KERN_INFO "Module exit!\n");
> }
> 
> module_init(test_init)
> module_exit(test_exit)
> MODULE_LICENSE("GPL");
> //
> 
> My kernel version is v3.10.63, and i checked the kernel source code,
> 
> update_process_times
>   -> run_local_timers
>   -> hrtimer_run_queues
>   -> __run_hrtimer
>   -> watchdog_timer_fn
>   -> is_softlockup
>   
>   -> rcu_check_callbacks
>   -> __rcu_pending
>   -> check_cpu_stall
>   -> print_cpu_stall
> 
> If softlockup_thresh > rcu_cpu_stall_timeout, print_cpu_stall will print log 
> to serial port.
> 
> The 8250 serial driver will call serial8250_console_write => 
> touch_nmi_watchdog() which reset
> watchdog_touch_ts to 0. So the softlockup will not be triggered.
> 
> Is this reasonable? Why?

Is exactly what reasonable?  ;-)

Yes, it is reasonable that your code triggers an RCU CPU stall warning.

No, it is not reasonable that the RCU CPU stall warning does not include
a stack trace, and the fix for that bug will be going into the next merge
window.

[PATCH] tpm, tpm_crb: fix build error

[Jarkko Sakkinen]

SIMPLE_DEV_PM_OPS() was inside #ifdef CONFIG_PM_SLEEP.

Signed-off-by: Jarkko Sakkinen 
---
 drivers/char/tpm/tpm_crb.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/char/tpm/tpm_crb.c b/drivers/char/tpm/tpm_crb.c
index c248a35..3dd23cf 100644
--- a/drivers/char/tpm/tpm_crb.c
+++ b/drivers/char/tpm/tpm_crb.c
@@ -107,9 +107,9 @@ static int crb_resume(struct device *dev)
 
return rc;
 }
+#endif
 
 static SIMPLE_DEV_PM_OPS(crb_pm, tpm_pm_suspend, crb_resume);
-#endif
 
 static u8 crb_status(struct tpm_chip *chip)
 {
-- 
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 18/28] PCI/sparc: Use pci_scan_root_bridge() for simplicity

[Arnd Bergmann]

On Monday 19 January 2015 11:17:02 Yijing Wang wrote:
> On 2015/1/16 18:01, Arnd Bergmann wrote:
> > On Friday 16 January 2015 09:44:16 Yijing Wang wrote:
> >> +static void pci_host_bridge_probe_mode(
> >> +   struct pci_host_bridge *host)
> >> +{
> >> +   host->of_scan = true;
> >> +}
> >>
> > 
> > I probably missed something here, but where does host->of_scan
> > get used?
> > 
> 
> It is used in __pci_scan_root_bus() to detect whether of scan bus is needed 
> in patch 11.

Ok, I see it now.

> @@ -2051,10 +2053,17 @@ static struct pci_bus *__pci_scan_root_bus(
>   pci_bus_insert_busn_res(b, host->busnum, 255);
>   }
> 
> - max = pci_scan_child_bus(b);
> + if (host->ops && host->ops->phb_probe_mode)
> + host->ops->phb_probe_mode(host);
> 
> - if (!found)
> - pci_bus_update_busn_res_end(b, max);
> + if (host->of_scan) {
> + if (host->ops &&host->ops->phb_of_scan_bus)
> + host->ops->phb_of_scan_bus(host);
> + } else {
> + max = pci_scan_child_bus(b);
> + if (!found)
> + pci_bus_update_busn_res_end(b, max);
> + }
> 

I think we can simplify this based on the knowledge that this code
will remain powerpc specific. How about removing the phb_probe_mode()
callback and replacing it with just a phb_scan_bus() callback that
will always get set on sparc, and do this on powerpc:

+static void pci_host_bridge_of_scan_bus(struct pci_host_bridge *host)
+{
+   int mode = PCI_PROBE_NORMAL;
+   struct pci_bus *bus = host->bus;
+   struct pci_controller *hose = dev_get_drvdata(&host->dev);
+
+   /* Get probe mode and perform scan */
+   if (hose->dn && ppc_md.pci_probe_mode)
+   mode = ppc_md.pci_probe_mode(bus);
+
+   pr_debug("probe mode: %d\n", mode);
+   if (mode == PCI_PROBE_DEVTREE) {
+   of_scan_bus(host->dn, bus);
+   return max; // XXX need to get this from somewhere
+   }
+   return pci_scan_child_bus(b);
+}

Would that work?

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

Re: [PATCH v4] gpio: lib-sysfs: Add 'wakeup' attribute

[Linus Walleij]

On Mon, Jan 19, 2015 at 5:20 AM, Alexandre Courbot  wrote:
> On Sat, Jan 17, 2015 at 1:49 AM, Sören Brinkmann  
> wrote:
>> On Fri, 2015-01-16 at 12:11PM +0100, Johan Hovold wrote:

>>> Implementing proper wakeup support for unclaimed GPIOs would take some
>>> work (if at all desired), but that is not a reason to be adding custom
>>> implementations that violates the kernel's power policies and new ABIs
>>> that would need to be maintained forever.
(...)
>>> Meanwhile you can (should) use gpio-keys if you need to wake your system
>>> on gpio events.
>>
>> We had that discussion and I don't think GPIO keys is the right solution
>> for every use-case.
>
> Sorry, it has been a while - can you remind us of why?

There are such cases. Of course keys should be handled by GPIO-keys
and these will trigger the right wakeup events in such cases.

This is for more esoteric cases: we cannot have a kernel module for
everything people want to do with GPIOs, and the use case I accept
is GPIOs used in automatic control etc, think factory lines or doors.
We can't have a "door" driver or "punch arm" or "fire alarm" driver
in the kernel. Those are userspace things.

Still such embedded systems need to be able to go to idle and
sleep to conerve power, and then they need to put wakeups on
these GPIOs.

So it is a feature userspace needs, though as with much of the
sysfs ABI it is very often abused for things like keys and LEDs which
is an abomination but we can't do much about it :(

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

[PATCH v2] pci: Fix infinite loop with ROM image of size 0

[Michel Dänzer]

From: Michel Dänzer 

If the image size would ever read as 0, pci_get_rom_size could keep
processing the same image over and over again.

Reported-by: Federico 
Cc: sta...@vger.kernel.org
Signed-off-by: Michel Dänzer 
---

v2:
* Use unsigned instead of u16 for the local length variable (not sure if
  the multiplication by 512 could overflow otherwise)
* Integrate length condition into while statement
* Add stable tag

 drivers/pci/rom.c | 7 ---
 1 file changed, 4 insertions(+), 3 deletions(-)

diff --git a/drivers/pci/rom.c b/drivers/pci/rom.c
index f955edb..eb0ad53 100644
--- a/drivers/pci/rom.c
+++ b/drivers/pci/rom.c
@@ -71,6 +71,7 @@ size_t pci_get_rom_size(struct pci_dev *pdev, void __iomem 
*rom, size_t size)
 {
void __iomem *image;
int last_image;
+   unsigned length;
 
image = rom;
do {
@@ -93,9 +94,9 @@ size_t pci_get_rom_size(struct pci_dev *pdev, void __iomem 
*rom, size_t size)
if (readb(pds + 3) != 'R')
break;
last_image = readb(pds + 21) & 0x80;
-   /* this length is reliable */
-   image += readw(pds + 16) * 512;
-   } while (!last_image);
+   length = readw(pds + 16);
+   image += length * 512;
+   } while (length && !last_image);
 
/* never return a size larger than the PCI resource window */
/* there are known ROMs that get the size wrong */
-- 
2.1.4

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

[PATCH net 2/2] r8152: remove sram_read

[Hayes Wang]

Read OCP register 0xa43a~0xa43b would clear some flags which the hw
would use, and it may let the device lost. However, the unit of
reading is 4 bytes. That is, it would read 0xa438~0xa43b when calling
sram_read() to read OCP_SRAM_DATA.

Signed-off-by: Hayes Wang 
---
 drivers/net/usb/r8152.c | 24 ++--
 1 file changed, 6 insertions(+), 18 deletions(-)

diff --git a/drivers/net/usb/r8152.c b/drivers/net/usb/r8152.c
index 0aa83fb..bf405f1 100644
--- a/drivers/net/usb/r8152.c
+++ b/drivers/net/usb/r8152.c
@@ -920,12 +920,6 @@ static void sram_write(struct r8152 *tp, u16 addr, u16 
data)
ocp_reg_write(tp, OCP_SRAM_DATA, data);
 }
 
-static u16 sram_read(struct r8152 *tp, u16 addr)
-{
-   ocp_reg_write(tp, OCP_SRAM_ADDR, addr);
-   return ocp_reg_read(tp, OCP_SRAM_DATA);
-}
-
 static int read_mii_word(struct net_device *netdev, int phy_id, int reg)
 {
struct r8152 *tp = netdev_priv(netdev);
@@ -2512,24 +2506,18 @@ static void r8153_hw_phy_cfg(struct r8152 *tp)
data = ocp_reg_read(tp, OCP_POWER_CFG);
data |= EN_10M_PLLOFF;
ocp_reg_write(tp, OCP_POWER_CFG, data);
-   data = sram_read(tp, SRAM_IMPEDANCE);
-   data &= ~RX_DRIVING_MASK;
-   sram_write(tp, SRAM_IMPEDANCE, data);
+   sram_write(tp, SRAM_IMPEDANCE, 0x0b13);
 
ocp_data = ocp_read_word(tp, MCU_TYPE_PLA, PLA_PHY_PWR);
ocp_data |= PFM_PWM_SWITCH;
ocp_write_word(tp, MCU_TYPE_PLA, PLA_PHY_PWR, ocp_data);
 
-   data = sram_read(tp, SRAM_LPF_CFG);
-   data |= LPF_AUTO_TUNE;
-   sram_write(tp, SRAM_LPF_CFG, data);
+   /* Enable LPF corner auto tune */
+   sram_write(tp, SRAM_LPF_CFG, 0xf70f);
 
-   data = sram_read(tp, SRAM_10M_AMP1);
-   data |= GDAC_IB_UPALL;
-   sram_write(tp, SRAM_10M_AMP1, data);
-   data = sram_read(tp, SRAM_10M_AMP2);
-   data |= AMP_DN;
-   sram_write(tp, SRAM_10M_AMP2, data);
+   /* Adjust 10M Amplitude */
+   sram_write(tp, SRAM_10M_AMP1, 0x00af);
+   sram_write(tp, SRAM_10M_AMP2, 0x0208);
 
set_bit(PHY_RESET, &tp->flags);
 }
-- 
2.1.0

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

[PATCH 0/2] x86: earlyprintk cleanup

[Alexander Kuleshov]

The following two patches remove unused macro definitions from 
early_serial_console and early_printk x86 code.

Alexander Kuleshov (2):
  x86/early_serial_console: remove unused definitions
  x86/early_printk: remove unused definitions

 arch/x86/boot/early_serial_console.c | 5 -
 arch/x86/kernel/early_printk.c   | 3 ---
 2 files changed, 8 deletions(-)

-- 
2.3.0.rc0.44.ga94655d.dirty

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

[PATCH 1/2] x86/early_serial_console: remove unused definitions

[Alexander Kuleshov]

TXR, RXR, IIR, LSR and MSR are not used anywhere

Signed-off-by: Alexander Kuleshov 
---
 arch/x86/boot/early_serial_console.c | 5 -
 1 file changed, 5 deletions(-)

diff --git a/arch/x86/boot/early_serial_console.c 
b/arch/x86/boot/early_serial_console.c
index 5df2869..9176135 100644
--- a/arch/x86/boot/early_serial_console.c
+++ b/arch/x86/boot/early_serial_console.c
@@ -6,15 +6,10 @@
 
 #define DLAB   0x80
 
-#define TXR 0   /*  Transmit register (WRITE) */
-#define RXR 0   /*  Receive register  (READ)  */
 #define IER 1   /*  Interrupt Enable  */
-#define IIR 2   /*  Interrupt ID  */
 #define FCR 2   /*  FIFO control  */
 #define LCR 3   /*  Line control  */
 #define MCR 4   /*  Modem control */
-#define LSR 5   /*  Line Status   */
-#define MSR 6   /*  Modem Status  */
 #define DLL 0   /*  Divisor Latch Low */
 #define DLH 1   /*  Divisor latch High*/
 
-- 
2.3.0.rc0.44.ga94655d.dirty

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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 0/2] r8152: couldn't read OCP_SRAM_DATA

[Hayes Wang]

Read OCP_SRAM_DATA would read additional bytes and may let
the hw abnormal.

Hayes Wang (2):
  r8152: remove generic_ocp_read before writing
  r8152: remove sram_read

 drivers/net/usb/r8152.c | 30 ++
 1 file changed, 6 insertions(+), 24 deletions(-)

-- 
2.1.0

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

[PATCH 2/2] x86/early_printk: remove unused definitions

[Alexander Kuleshov]

RXR, IIR and MSR are not used

Signed-off-by: Alexander Kuleshov 
---
 arch/x86/kernel/early_printk.c | 3 ---
 1 file changed, 3 deletions(-)

diff --git a/arch/x86/kernel/early_printk.c b/arch/x86/kernel/early_printk.c
index 01d1c18..e8f317f 100644
--- a/arch/x86/kernel/early_printk.c
+++ b/arch/x86/kernel/early_printk.c
@@ -83,14 +83,11 @@ static int early_serial_base = 0x3f8;  /* ttyS0 */
 #define DLAB   0x80
 
 #define TXR 0   /*  Transmit register (WRITE) */
-#define RXR 0   /*  Receive register  (READ)  */
 #define IER 1   /*  Interrupt Enable  */
-#define IIR 2   /*  Interrupt ID  */
 #define FCR 2   /*  FIFO control  */
 #define LCR 3   /*  Line control  */
 #define MCR 4   /*  Modem control */
 #define LSR 5   /*  Line Status   */
-#define MSR 6   /*  Modem Status  */
 #define DLL 0   /*  Divisor Latch Low */
 #define DLH 1   /*  Divisor latch High*/
 
-- 
2.3.0.rc0.44.ga94655d.dirty

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] kprobes: bugfix: checks kprobes_all_disarmed in unoptimized_kprobe().

[Masami Hiramatsu]

Hi Wang,

I've found a problem on this patch, since kprobes calls unoptioize_kprobe
with kprobes_all_disarmed=true when trying to disable all kprobes, this
cause a serious problem.

Moreover, I couldn't reproduce your reported bug on my 3.19-rc4 kernel.
Could you test it again?

Unless I could reproduce this bug, I'd like to keep this uncommitted.

Thank you,

(2015/01/19 12:04), Wang Nan wrote:
> Hi Masami Hiramatsu,
> 
> I can't find this patch and '[PATCH] kprobes: bugfix: checks 
> kprobes_all_disarmed
> in unoptimized_kprobe().' in current mainline. How do these patches get there?
> Should they be merged into Russell King's tree first?
> 
> Thank you!
> 
> On 2015/1/12 20:52, Masami Hiramatsu wrote:
>> (2015/01/12 21:09), Wang Nan wrote:
>>> Original code failed to disarm the probed instruction after
>>>
>>> echo 0 > /sys/kernel/debug/kprobes/enabled
>>>
>>> if OPTPROBE is enabled.
>>>
>>> This patch checks kprobes_all_disarmed in unoptimized_kprobe().
>>>
>>
>> Looks good :)
>>
>> Acked-by: Masami Hiramatsu 
>>
>> Thank you!
>>
>>> Signed-off-by: Wang Nan 
>>> ---
>>>  kernel/kprobes.c | 3 +++
>>>  1 file changed, 3 insertions(+)
>>>
>>> diff --git a/kernel/kprobes.c b/kernel/kprobes.c
>>> index 9471710..f16936b 100644
>>> --- a/kernel/kprobes.c
>>> +++ b/kernel/kprobes.c
>>> @@ -630,6 +630,9 @@ static void unoptimize_kprobe(struct kprobe *p, bool 
>>> force)
>>>  {
>>> struct optimized_kprobe *op;
>>>  
>>> +   if (kprobes_all_disarmed)
>>> +   return;
>>> +
>>> if (!kprobe_aggrprobe(p) || kprobe_disarmed(p))
>>> return; /* This is not an optprobe nor optimized */
>>>  
>>>
>>
>>
> 
> 
> 


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

[PATCH net 1/2] r8152: remove generic_ocp_read before writing

[Hayes Wang]

For ocp_write_word() and ocp_write_byte(), there is a generic_ocp_read()
which is used to read the whole 4 byte data, keep the unchanged bytes,
and modify the expected bytes. However, the "byen" could be used to
determine which bytes of the 4 bytes to write, so the action could be
removed.

Signed-off-by: Hayes Wang 
---
 drivers/net/usb/r8152.c | 6 --
 1 file changed, 6 deletions(-)

diff --git a/drivers/net/usb/r8152.c b/drivers/net/usb/r8152.c
index 57ec23e..0aa83fb 100644
--- a/drivers/net/usb/r8152.c
+++ b/drivers/net/usb/r8152.c
@@ -833,9 +833,6 @@ static void ocp_write_word(struct r8152 *tp, u16 type, u16 
index, u32 data)
index &= ~3;
}
 
-   generic_ocp_read(tp, index, sizeof(tmp), &tmp, type);
-
-   data |= __le32_to_cpu(tmp) & ~mask;
tmp = __cpu_to_le32(data);
 
generic_ocp_write(tp, index, byen, sizeof(tmp), &tmp, type);
@@ -874,9 +871,6 @@ static void ocp_write_byte(struct r8152 *tp, u16 type, u16 
index, u32 data)
index &= ~3;
}
 
-   generic_ocp_read(tp, index, sizeof(tmp), &tmp, type);
-
-   data |= __le32_to_cpu(tmp) & ~mask;
tmp = __cpu_to_le32(data);
 
generic_ocp_write(tp, index, byen, sizeof(tmp), &tmp, type);
-- 
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 v4 3/6] arm64: Kprobes with single stepping support

[Pratyush Anand]

On Saturday 17 January 2015 12:58 AM, David Long wrote:

+static bool aarch64_insn_is_steppable(u32 insn)
+{
+   if (aarch64_get_insn_class(insn) == AARCH64_INSN_CLS_BR_SYS) {
+   if (aarch64_insn_is_branch(insn))
+   return false;
+
+   /* modification of daif creates issues */
+   if (aarch64_insn_is_msr_daif(insn))
+   return false;
+
+   if (aarch64_insn_is_hint(insn))
+   return aarch64_insn_is_nop(insn);
+
+   return true;
+   }
+
+   if (aarch64_insn_uses_literal(insn))
+   return false;
+
+   if (aarch64_insn_is_exclusive(insn))
+   return false;
+
+   return true;


Default true return may not be a good idea until we are sure that we
are returning false for all possible
simulation and rejection cases. In my opinion, its better to return
true only for steppable and false for
all remaining.



I struggled a little with this when I did it but I decided if the
question was:  "should we have to recognize every instruction before
deciding it was single-steppable or should we only recognize
instructions that are *not* single-steppable", maybe it was OK to do the
latter while recognizing extensions to the instruction set *could* end
up (temporarly) allowing us to try and fail (badly) at single-stepping
any problematic new instructions.  Certainly opinions could differ.  If


Lets see what others say, but I see that this approach will result in 
undesired behavior. For example: a probe has been tried to insert to svc 
instruction. SVC or any other exception generation instruction is 
expected to be rejected. But, current aarch64_insn_is_steppable will 
return true for it and then kprobe/uprobe code will allow to insert 
probe at that instruction, which will be wrong, no? I mean, I do not see 
a way to get into last else (INSN_REJECTED) of arm_kprobe_decode_insn.


So, if we go with this approach we need to insure that we cover all 
simulation-able and reject-able cases in aarch64_insn_is_steppable.


~Pratyush




the consensus is that we can't allow this to ever happen (because old
kprobe code is running on new hardware) then I think the only choice is
to return to parsing binary tables.  Hopefully I could still find a way
to leverage insn.c in that case.

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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: rcu, sched: WARNING: CPU: 30 PID: 23771 at kernel/rcu/tree_plugin.h:337 rcu_read_unlock_special+0x369/0x550()

[Paul E. McKenney]

On Sun, Jan 18, 2015 at 09:17:40AM -0500, Sasha Levin wrote:
> Hi Paul, Lai,
> 
> While fuzzing with trinity inside a KVM tools guest running the latest -next
> kernel, I've stumbled on the following spew:
> 
> [  598.188036] WARNING: CPU: 30 PID: 23771 at kernel/rcu/tree_plugin.h:337 
> rcu_read_unlock_special+0x369/0x550()
> [  598.188036] Modules linked in:
> [  598.188036] CPU: 30 PID: 23771 Comm: trinity-c118 Not tainted 
> 3.19.0-rc4-next-20150116-sasha-00055-gb8e1507-dirty #1745
> [  598.188036]  926e52dc 8801b4403c38 91439fb2 
> 
> [  598.188036]   8801b4403c78 8e159e1a 
> 8801b4403c58
> [  598.188036]   88002f093000  
> 8801b23b9290
> [  598.188036] Call Trace:
> [  598.188036]  dump_stack (lib/dump_stack.c:52)
> [  598.212152] warn_slowpath_common (kernel/panic.c:447)
> [  598.212152] warn_slowpath_null (kernel/panic.c:481)
> [  598.212152] rcu_read_unlock_special (kernel/rcu/tree_plugin.h:337 
> (discriminator 9))
> [  598.212152] ? select_task_rq_fair (include/linux/rcupdate.h:889 
> kernel/sched/fair.c:4740)
> [  598.212152] __rcu_read_unlock (kernel/rcu/update.c:97)
> [  598.212152] select_task_rq_fair (kernel/sched/fair.c:4805)
> [  598.212152] ? select_task_rq_fair (include/linux/rcupdate.h:889 
> kernel/sched/fair.c:4740)
> [  598.212152] ? try_to_wake_up (kernel/sched/core.c:1701)
> [  598.212152] try_to_wake_up (kernel/sched/core.c:1415 
> kernel/sched/core.c:1729)
> [  598.212152] wake_up_process (kernel/sched/core.c:1797 (discriminator 3))
> [  598.212152] hrtimer_wakeup (kernel/time/hrtimer.c:1490)
> [  598.212152] __run_hrtimer (kernel/time/hrtimer.c:1218 (discriminator 3))
> [  598.212152] ? hrtimer_interrupt (kernel/time/hrtimer.c:622 
> kernel/time/hrtimer.c:1254)
> [  598.212152] ? hrtimer_get_res (kernel/time/hrtimer.c:1480)
> [  598.212152] hrtimer_interrupt (kernel/time/hrtimer.c:1307)
> [  598.212152] local_apic_timer_interrupt (arch/x86/kernel/apic/apic.c:921)
> [  598.212152] smp_apic_timer_interrupt (./arch/x86/include/asm/apic.h:660 
> arch/x86/kernel/apic/apic.c:945)
> [  598.212152] apic_timer_interrupt (arch/x86/kernel/entry_64.S:983)
> [  598.212152]  ? context_tracking_user_enter 
> (./arch/x86/include/asm/paravirt.h:809 kernel/context_tracking.c:106)
> [  598.212152] syscall_trace_leave (arch/x86/kernel/ptrace.c:1640)
> [  598.212152] int_check_syscall_exit_work (arch/x86/kernel/entry_64.S:577)

So RCU believes that an RCU read-side critical section that ended within
an interrupt handler (in this case, an hrtimer) somehow got preempted.
Which is not supposed to happen.

Do you have CONFIG_PROVE_RCU enabled?  If not, could you please enable it
and retry?

Thanx, Paul

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

Re: [Intel-gfx] [BUG, bisect] drm/i915: mouse pointer lags and overshoots

[Ville Syrjälä]

On Sat, Jan 17, 2015 at 02:06:35AM -0800, Jeremiah Mahler wrote:
> Matt, all,
> 
> Commit ea2c67bb4aff introduces a bug which causes the mouse to move in a
> very unusual way, as if it has a lot of inertia.  It will lag behind and
> then overshoot the expected position.
> 
> I reproduced this bug on all my machines which use the drm/i915 drivers
> and it affects all forms of mouse pointers including both touchpads and
> usb mice.  The patch is present in linux-next 20150116.
> 
>   commit ea2c67bb4affa84080c616920f3899f123786e56
>   Author: Matt Roper 
>   Date:   Tue Dec 23 10:41:52 2014 -0800
>   
>   drm/i915: Move to atomic plane helpers (v9)

I guess this is caused by the atomic code refusing to update the plane
more than once per vrefresh. So we need to allow the fps>vrefresh rate
case to remove the regression.

The old cursor code had basically a gross hack to allow this. It just
unpinned the old fb before the display engine was done with it, and
_after_ unpinning it flipped to the new buffer (with the obvious extra
delay of the flip happening on the next vblank). So there was no
guarantee the old buffer was still around (or had the correct content)
while the display engine was still scanning it out. So to fix this
properly we need a vblank worker of some sort.

The other issues we nee to know which fb is being scanned out at which
point to unpin the correct old buffer. For that we can use the hardware
frame counter. We could use some other mechanims too (SURFLIVE, flip
counter etc.) but the frame counter is the most ubiqitious method we
have.

The one extra problem is gen2 doesn't have even the frame counter, so
some extra care would be needed there. I'm thinking for gen2 we might
allow the driver to call into the vblank core code to update the cooked
counter at any time based on the scanline counter and monotonic timestamp.
That combined with the vblank evade mechanism should make reasonably sure
we have an up to date notion of which frame is currently getting scanned
out.

We need the extra call into the vblank core since just after the vblank
start, the vblank interrupt handler may not have executed yet (especially
since gen2 vblank irq fires actually at the frame start which is a delayed
version of the vblank start, even though the flip happes at vblank start).
So we need an explicit call to make sure the cooked counter is already
updated before the irq handler has executed. I have some changes lined
up for the vblank code which I think could help make sure he extra call
won't increment the counter spuriously, but I have to clean those up a
bit before sending them out.

-- 
Ville Syrjälä
Intel OTC
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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: RCU CPU stall console spews leads to soft lockup disabled is reasonable ?

[Zhang Zhen]

On 2015/1/19 16:42, Paul E. McKenney wrote:
> On Mon, Jan 19, 2015 at 04:07:15PM +0800, Zhang Zhen wrote:
>> Hi,
>>
>> On my x86_64 qemu virtual machine, RCU CPU stall console spews may
>> lead to soft lockup disabled.
>>
>> If softlockup_thresh > rcu_cpu_stall_timeout (softlockup_thresh = 2 * 
>> watchdog_thresh):
>>
>> / #
>> / # busybox cat /sys/module/rcupdate/parameters/rcu_cpu_stall_timeout
>> 21
>> / # echo 60 > /proc/sys/kernel/watchdog_thresh
>> / # busybox insmod softlockup_test.ko
>> [   44.959044] INFO: rcu_preempt detected stalls on CPUs/tasks: {} (detected 
>> by 0, t=21002 jiffies, g=85, c=84, q=4)
>> [   44.959044] INFO: Stall ended before state dump start
>> [  107.964045] INFO: rcu_preempt detected stalls on CPUs/tasks: {} (detected 
>> by 0, t=84007 jiffies, g=85, c=84, q=4)
>> [  107.964045] INFO: Stall ended before state dump start
>> [  170.969060] INFO: rcu_preempt detected stalls on CPUs/tasks: {} (detected 
>> by 0, t=147012 jiffies, g=85, c=84, q=4)
>> [  170.969060] INFO: Stall ended before state dump start
>> [  233.974057] INFO: rcu_preempt detected stalls on CPUs/tasks: {} (detected 
>> by 0, t=210017 jiffies, g=85, c=84, q=4)
>> [  233.974057] INFO: Stall ended before state dump start
>> [  296.979059] INFO: rcu_preempt detected stalls on CPUs/tasks: {} (detected 
>> by 0, t=273022 jiffies, g=85, c=84, q=4)
>> [  296.979059] INFO: Stall ended before state dump start
>> [  359.984058] INFO: rcu_preempt detected stalls on CPUs/tasks: {} (detected 
>> by 0, t=336027 jiffies, g=85, c=84, q=4)
>> [  359.984058] INFO: Stall ended before state dump start
>> [  422.989059] INFO: rcu_preempt detected stalls on CPUs/tasks: {} (detected 
>> by 0, t=399032 jiffies, g=85, c=84, q=4)
>> [  422.989059] INFO: Stall ended before state dump start
>> [  485.994056] INFO: rcu_preempt detected stalls on CPUs/tasks: {} (detected 
>> by 0, t=462037 jiffies, g=85, c=84, q=4)
>> [  485.994056] INFO: Stall ended before state dump start
>> [  548.999059] INFO: rcu_preempt detected stalls on CPUs/tasks: {} (detected 
>> by 0, t=525042 jiffies, g=85, c=84, q=4)
>> [  548.999059] INFO: Stall ended before state dump start
>> [  612.004061] INFO: rcu_preempt detected stalls on CPUs/tasks: {} (detected 
>> by 0, t=588047 jiffies, g=85, c=84, q=4)
>> [  612.004061] INFO: Stall ended before state dump start
>> [  675.009058] INFO: rcu_preempt detected stalls on CPUs/tasks: {} (detected 
>> by 0, t=651052 jiffies, g=85, c=84, q=4)
>> [  675.009058] INFO: Stall ended before state dump start
>>
>> If softlockup_thresh < rcu_cpu_stall_timeout:
>>
>> / #
>> / # busybox cat /sys/module/rcupdate/parameters/rcu_cpu_stall_timeout
>> 21
>> / # echo 5 > /proc/sys/kernel/watchdog_thresh
>> / # busybox insmod softlockup_test.ko
>> [   38.450061] BUG: soft lockup - CPU#0 stuck for 11s! [busybox:53]
>> [   52.450061] BUG: soft lockup - CPU#0 stuck for 11s! [busybox:53]
>> [   66.450073] BUG: soft lockup - CPU#0 stuck for 11s! [busybox:53]
>> [   80.450060] BUG: soft lockup - CPU#0 stuck for 11s! [busybox:53]
>> [   94.450061] BUG: soft lockup - CPU#0 stuck for 11s! [busybox:53]
>>
>> The softlockup_test.ko source code is:
>> //
>> #include 
>> #include 
>> #include 
>> #include 
>>
>> static int hello_start(void)
>> {
>> DEFINE_SPINLOCK(hello_lock);
>> spin_lock_init(&hello_lock);
>> spin_lock(&hello_lock);
>> spin_lock(&hello_lock);
> 
> Did you really intend to acquire the same spinlock twice in a row,
> forcing a self-deadlock?  If not, I of course suggest changing the second
> "spin_lock()" to "spin_unlock()".
> 

Yes, i acquire the same spinlock twice in order to reproduce the problem.

> If your .config has CONFIG_TREE_RCU=y, the above is quite likely to
> give you an RCU CPU stall warning.
> 

In my .config CONFIG_TREE_RCU=y.

If softlockup_thresh < rcu_cpu_stall_timeout, it will give soft lockup warning.
If softlockup_thresh > rcu_cpu_stall_timeout, it will likely to give RCU CPU 
stall warning
just like above and no give soft lockup warning.

It means that RCU CPU stall console spews leads to soft lockup disabled.
Is this reasonable ?

Thanks!

>> return 0;
>> }
>>
>> static int __init test_init(void)
>> {
>> hello_start();
>>
>> printk(KERN_INFO "Module init\n");
>> return 0;
>> }
>>
>> static void __exit test_exit(void)
>> {
>> printk(KERN_INFO "Module exit!\n");
>> }
>>
>> module_init(test_init)
>> module_exit(test_exit)
>> MODULE_LICENSE("GPL");
>> //
>>
>> My kernel version is v3.10.63, and i checked the kernel source code,
>>
>> update_process_times
>>  -> run_local_timers
>>  -> hrtimer_run_queues
>>  -> __run_hrtimer
>>  -> watchdog_timer_fn
>>  -> is_softlockup
>>  
>>  -> rcu_check_callbacks
>>  -> __rcu_pending
>>  -> check_cpu_stall
>>  

Re: [PATCH v3 2/3] mfd: lubbock_io: add lubbock_io board

[Lee Jones]

On Fri, 16 Jan 2015, Robert Jarzmik wrote:

> Lubbock () board is the IO motherboard of the Intel PXA25x Development
> Platform, which supports the Lubbock pxa25x soc board.
> 
> Historically, this support was in arch/arm/mach-pxa/lubbock.c. When
> gpio-pxa was moved to drivers/pxa, it became a driver, and its
> initialization and probing happened at postcore initcall. The lubbock
> code used to install the chained lubbock interrupt handler at init_irq()
> time.
> 
> The consequence of the gpio-pxa change is that the installed chained irq
> handler lubbock_irq_handler() was overwritten in pxa_gpio_probe(_dt)(),
> removing :
>  - the handler
>  - the falling edge detection setting of GPIO0, which revealed the
>interrupt request from the lubbock IO board.
> 
> As a fix, move the gpio0 chained handler setup to a place where we have
> the guarantee that pxa_gpio_probe() was called before, so that lubbock
> handler becomes the true IRQ chained handler of GPIO0, demuxing the
> lubbock IO board interrupts.

How is this guaranteed?

> This patch moves all that handling to a mfd driver. It's only purpose
> for the time being is the interrupt handling, but in the future it
> should encompass all the motherboard CPLDs handling :
>  - leds
>  - switches
>  - hexleds
> 
> Signed-off-by: Robert Jarzmik 
> ---
> Since v1: change the name from cottula to lubbock_io
> Dmitry pointed out the Cottula was the pxa25x family name,
>   lubbock was the pxa25x development board name. Therefore the
>   name was changed to lubbock_io (lubbock IO board)
> change the resources to bi-irq ioresource
>   Discussion between Arnd and Robert to change the gpio
>   request by a irq request.
> Since v2: take into account Mark's review
>   Use irq flags from resources (DT case and pdata case).
>   Change of name from lubbock_io to lubbock-io
> ---
>  drivers/mfd/Kconfig   |  10 +++
>  drivers/mfd/Makefile  |   1 +
>  drivers/mfd/lubbock.c | 196 
> ++
>  3 files changed, 207 insertions(+)
>  create mode 100644 drivers/mfd/lubbock.c
> 
> diff --git a/drivers/mfd/Kconfig b/drivers/mfd/Kconfig
> index 2e6b731..4d8939f 100644
> --- a/drivers/mfd/Kconfig
> +++ b/drivers/mfd/Kconfig
> @@ -91,6 +91,16 @@ config MFD_AXP20X
> components like regulators or the PEK (Power Enable Key) under the
> corresponding menus.
>  
> +config MFD_LUBBOCK
> + bool "Lubbock Motherboard"
> + def_bool ARCH_LUBBOCK
> + select MFD_CORE
> + help
> +   This driver supports the Lubbock multifunction chip found on the
> +   pxa25x development platform system (named Lubbock). This IO board
> +   supports the interrupts handling, ethernet controller, flash chips,
> +   etc ...
> +
>  config MFD_CROS_EC
>   tristate "ChromeOS Embedded Controller"
>   select MFD_CORE
> diff --git a/drivers/mfd/Makefile b/drivers/mfd/Makefile
> index 53467e2..aff1f4f 100644
> --- a/drivers/mfd/Makefile
> +++ b/drivers/mfd/Makefile
> @@ -9,6 +9,7 @@ obj-$(CONFIG_MFD_88PM805) += 88pm805.o 88pm80x.o
>  obj-$(CONFIG_MFD_SM501)  += sm501.o
>  obj-$(CONFIG_MFD_ASIC3)  += asic3.o tmio_core.o
>  obj-$(CONFIG_MFD_BCM590XX)   += bcm590xx.o
> +obj-$(CONFIG_MFD_LUBBOCK)+= lubbock.o
>  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
> diff --git a/drivers/mfd/lubbock.c b/drivers/mfd/lubbock.c
> new file mode 100644
> index 000..6025135
> --- /dev/null
> +++ b/drivers/mfd/lubbock.c
> @@ -0,0 +1,196 @@
> +/*
> + * Intel Cotulla MFD - lubbock motherboard
> + *
> + * Copyright (C) 2014 Robert Jarzmik
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License as published by
> + * the Free Software Foundation; either version 2 of the License, or
> + * (at your option) any later version.
> + *
> + * Lubbock motherboard driver, supporting lubbock (aka. pxa25x) soc board.

Please use uppercase characters i.e. Lubbock, PXA25X, SoC, etc.

> + *

Superfluous '\n'.

> + */
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 

Can this be built as a module?

If so, why isn't it a tristate?

> +#include 
> +
> +#define COT_IRQ_MASK_EN 0xc0
> +#define COT_IRQ_SET_CLR 0xd0
> +
> +#define LUBBOCK_NB_IRQ   8
> +
> +struct lubbock {
> + void __iomem*base;

Random spacing.

> + int irq;
> + unsigned int irq_mask;
> + struct gpio_desc *gpio0;
> + struct irq_domain *irqdomain;
> +};
> +
> +static irqreturn_t lubbock_irq_handler(int in_irq, void *d)
> +{
> + struct lubbock *cot = d;
> + unsigned long pending;
> + unsigned int bit;
> +
> + pending = readl(cot->base + COT_IRQ_SET_CLR) & cot->irq_mask;
> + for_each_set_bit

Re: [PATCH v4 1/9] devfreq: exynos: Add generic exynos memory bus frequency driver

[MyungJoo Ham]

>   
>  This patch adds the generic exynos bus frequency driver for memory bus
> with DEVFREQ framework. The Samsung Exynos SoCs have the common architecture
> for memory bus between DRAM memory and MMC/sub IP in SoC. This driver can
> support the memory bus frequency driver for Exynos SoCs.
> 
> Each memory bus block has a clock for memory bus speed and frequency
> table which is changed according to the utilization of memory bus on runtime.
> And then each memory bus group has the one more memory bus blocks and
> OPP table (including frequency and voltage), regulator, devfreq-event
> devices.
> 
> There are a little difference about the number of memory bus because each 
> Exynos
> SoC have the different sub-IP and different memory bus speed. In spite of this
> difference among Exynos SoCs, we can support almost Exynos SoC by adding
> unique data of memory bus to devicetree file.
> 
> Cc: Myungjoo Ham 
> Cc: Kyungmin Park 
> Cc: Kukjin Kim 
> Signed-off-by: Chanwoo Choi 
> ---
>  drivers/devfreq/Kconfig |  15 +
>  drivers/devfreq/Makefile|   1 +
>  drivers/devfreq/exynos/Makefile |   1 +
>  drivers/devfreq/exynos/exynos-bus.c | 598 
> 
>  4 files changed, 615 insertions(+)
>  create mode 100644 drivers/devfreq/exynos/exynos-bus.c
> 

[]

> +static void exynos_bus_exit(struct device *dev)
> +{
> + struct exynos_memory_bus *bus = dev_get_drvdata(dev);
> + int i, ret;
> +
> + ret = exynos_bus_disable_edev(bus);
> + if (ret < 0)
> + dev_warn(dev, "failed to disable the devfreq-event devices\n");
> +
> + for (i = 0; i < bus->block_count; i++)
> + clk_disable_unprepare(bus->block[i].clk);
> +
> + if (regulator_is_enabled(bus->regulator))
> + regulator_disable(bus->regulator);

This is_enabled check is itchy.

Why do you need this here?
Please let me know what kind of errors here.
(note that this may simply hide errors made by other drivers)

Adding this condition does not introduce additional error, but
could you please let me know why it is here? This is supposed to be
paired with probe.


Except this point (valid if addressed or {explained and understood}),
Acked-by: MyungJoo Ham 


Cheers,
MyungJoo

> +
> + of_free_opp_table(dev);
> +}
> +
> +static struct devfreq_dev_profile exynos_memory_bus_profile = {
> + .polling_ms = 100,
> + .target = exynos_bus_target,
> + .get_dev_status = exynos_bus_get_dev_status,
> + .exit   = exynos_bus_exit,
> +};
> +

[]

Re: [PATCH 1/2] ARM: entry-common: fix forgotten set of thread_info->syscall

[Will Deacon]

On Fri, Jan 16, 2015 at 11:54:45PM +, Kees Cook wrote:
> On Fri, Jan 16, 2015 at 11:57 AM, Kees Cook  wrote:
> > On Fri, Jan 16, 2015 at 8:17 AM, Russell King - ARM Linux
> >  wrote:
> >> On Sat, Jan 17, 2015 at 01:08:11AM +0900, Roman Peniaev wrote:
> >>> On Sat, Jan 17, 2015 at 12:59 AM, Russell King - ARM Linux
> >>>  wrote:
> >>> > On Sat, Jan 17, 2015 at 12:57:02AM +0900, Roman Peniaev wrote:
> >>> >> On Fri, Jan 16, 2015 at 7:54 AM, Kees Cook  
> >>> >> wrote:
> >>> >> > One interesting thing I noticed (which is unchanged by this series),
> >>> >> > but pulling ARM_r7 during the seccomp ptrace event shows __NR_poll,
> >>> >> > not __NR_restart_syscall, even though it was a __NR_restart_syscall
> >>> >> > trap from seccomp. Is there a better place to see the actual syscall?
> >>> >>
> >>> >> As I understand we do not push new r7 to the stack, and ptrace uses the
> >>> >> old value.
> >>> >
> >>> > And why should we push r7 to the stack?  ptrace should be using the
> >>> > recorded system call number, rather than poking about on the stack
> >>> > itself.
> >>>
> >>> Probably we should not, but the behaviour comparing arm to x86 is 
> >>> different.
> >>
> >> We definitely should not, because changing the stacked value changes the
> >> value in r7 after the syscall has returned.  We have guaranteed that the
> >> value will be preserved across syscalls for years, so we really should
> >> not be changing that.
> >
> > Yeah, we can't mess with the registers. I was just asking for
> > clarification on how this is visible to userspace.
> >
> >>
> >>> Also there is no any way from userspace to figure out what syscall was
> >>> restarted, if you do not trace each syscall enter and exit from the
> >>> very beginning.
> >>
> >> Thinking about ptrace, that's been true for years.
> >>
> >> It really depends whether you consider the restart syscall a userspace
> >> thing or a kernelspace thing.  When you consider that the vast majority
> >> of syscall restarts are done internally in the kernel, and we just
> >> re-issue the syscall, it immediately brings up the question "why is
> >> the restart block method different?" and "should the restart block
> >> method be visible to userspace?"
> >>
> >> IMHO, it is prudent not to expose kernel internals to userspace unless
> >> there is a real reason to, otherwise they become part of the userspace
> >> API.
> >
> > I couldn't agree more, but restart_syscall is already visible to
> > userspace: it can be called directly, for example. And it's visible to
> > tracers.
> >
> > Unfortunately, the difference here is the visibility during trace
> > trap. On x86, it's exposed but on ARM, there's no way (that I can
> > find) to query the "true" syscall, even though the true syscall is
> > what triggers the tracer. The syscall number isn't provided by any
> > element of the ptrace event system, nor through siginfo, and must be
> > examined on a per-arch basis from registers.
> >
> > Seccomp does, however, provide a mechanism to pass arbitrary event
> > data on a TRACE event, so poll vs restart_syscall can be distinguished
> > that way.
> >
> > It seems even strace doesn't know how to find this information. For example:
> >
> > x86:
> > poll([{fd=3, events=POLLIN}], 1, 4294967295
> > ) = ? ERESTART_RESTARTBLOCK (Interrupted by signal)
> > --- SIGSTOP {si_signo=SIGSTOP, si_code=SI_USER, si_pid=994, si_uid=1000} ---
> > --- stopped by SIGSTOP ---
> > --- SIGCONT {si_signo=SIGCONT, si_code=SI_USER, si_pid=994, si_uid=1000} ---
> > restart_syscall(<... resuming interrupted call ...>
> >
> > ARM:
> > poll([{fd=3, events=POLLIN}], 1, -1
> > )= ? ERESTART_RESTARTBLOCK (Interrupted by signal)
> > --- SIGSTOP {si_signo=SIGSTOP, si_code=SI_USER, si_pid=20563, si_uid=0} ---
> > --- stopped by SIGSTOP ---
> > --- SIGCONT {si_signo=SIGCONT, si_code=SI_USER, si_pid=20563, si_uid=0} ---
> > poll([{fd=3, events=POLLIN}], 1, -1
> >
> > Would it make sense to add REGSET_SYSTEM_CALL to ARM? (Though this
> > begs the question, "Is restart_syscall visible during a trace on
> > arm64?", which I'll have to go check...)
> 
> So, some further testing:
> - native arm64 presents "poll" again even to seccomp when
> restart_syscall is triggered (both via regs[8] and
> NT_ARM_SYSTEM_CALL).

I'm fine either way for the native case, but we should stick with whetever
we end up with. Being compatible with ARM is probably a good idea. Do you
have a preference?

> - compat mode on arm64 _does_ show syscall_restart (via ARM_r7).

That sounds like a bug, then. Any chance you could look into a patch?

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

Re: [PATCHv10 1/2] pwm: Add Allwinner SoC support

[Chen-Yu Tsai]

On Thu, Dec 18, 2014 at 5:15 AM, Alexandre Belloni
 wrote:
> This adds a generic PWM framework driver for the PWM controller
> found on Allwinner SoCs.

Hi,

Any news on this series?

ChenYu

> Signed-off-by: Alexandre Belloni 
> Acked-by: Maxime Ripard 
> ---
>  drivers/pwm/Kconfig |  10 ++
>  drivers/pwm/Makefile|   1 +
>  drivers/pwm/pwm-sun4i.c | 366 
> 
>  3 files changed, 377 insertions(+)
>  create mode 100644 drivers/pwm/pwm-sun4i.c
>
> diff --git a/drivers/pwm/Kconfig b/drivers/pwm/Kconfig
> index ef2dd2e4754b..07f533d2b5be 100644
> --- a/drivers/pwm/Kconfig
> +++ b/drivers/pwm/Kconfig
> @@ -263,6 +263,16 @@ config PWM_STI
>   To compile this driver as a module, choose M here: the module
>   will be called pwm-sti.
>
> +config PWM_SUN4I
> +   tristate "Allwinner PWM support"
> +   depends on ARCH_SUNXI || COMPILE_TEST
> +   depends on HAS_IOMEM && COMMON_CLK
> +   help
> + Generic PWM framework driver for Allwinner SoCs.
> +
> + To compile this driver as a module, choose M here: the module
> + will be called pwm-sun4i.
> +
>  config PWM_TEGRA
> tristate "NVIDIA Tegra PWM support"
> depends on ARCH_TEGRA
> diff --git a/drivers/pwm/Makefile b/drivers/pwm/Makefile
> index c458606c3755..d607804deea1 100644
> --- a/drivers/pwm/Makefile
> +++ b/drivers/pwm/Makefile
> @@ -24,6 +24,7 @@ obj-$(CONFIG_PWM_ROCKCHIP)+= pwm-rockchip.o
>  obj-$(CONFIG_PWM_SAMSUNG)  += pwm-samsung.o
>  obj-$(CONFIG_PWM_SPEAR)+= pwm-spear.o
>  obj-$(CONFIG_PWM_STI)  += pwm-sti.o
> +obj-$(CONFIG_PWM_SUN4I)+= pwm-sun4i.o
>  obj-$(CONFIG_PWM_TEGRA)+= pwm-tegra.o
>  obj-$(CONFIG_PWM_TIECAP)   += pwm-tiecap.o
>  obj-$(CONFIG_PWM_TIEHRPWM) += pwm-tiehrpwm.o
> diff --git a/drivers/pwm/pwm-sun4i.c b/drivers/pwm/pwm-sun4i.c
> new file mode 100644
> index ..cd9dde563018
> --- /dev/null
> +++ b/drivers/pwm/pwm-sun4i.c
> @@ -0,0 +1,366 @@
> +/*
> + * Driver for Allwinner sun4i Pulse Width Modulation Controller
> + *
> + * Copyright (C) 2014 Alexandre Belloni 
> 
> + *
> + * Licensed under GPLv2.
> + */
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +#define PWM_CTRL_REG   0x0
> +
> +#define PWM_CH_PRD_BASE0x4
> +#define PWM_CH_PRD_OFFSET  0x4
> +#define PWM_CH_PRD(ch) (PWM_CH_PRD_BASE + PWM_CH_PRD_OFFSET * (ch))
> +
> +#define PWMCH_OFFSET   15
> +#define PWM_PRESCAL_MASK   GENMASK(3, 0)
> +#define PWM_PRESCAL_OFF0
> +#define PWM_EN BIT(4)
> +#define PWM_ACT_STATE  BIT(5)
> +#define PWM_CLK_GATING BIT(6)
> +#define PWM_MODE   BIT(7)
> +#define PWM_PULSE  BIT(8)
> +#define PWM_BYPASS BIT(9)
> +
> +#define PWM_RDY_BASE   28
> +#define PWM_RDY_OFFSET 1
> +#define PWM_RDY(ch)BIT(PWM_RDY_BASE + PWM_RDY_OFFSET * (ch))
> +
> +#define PWM_PRD(prd)   (((prd) - 1) << 16)
> +#define PWM_PRD_MASK   GENMASK(15, 0)
> +
> +#define PWM_DTY_MASK   GENMASK(15, 0)
> +
> +#define BIT_CH(bit, chan)  ((bit) << ((chan) * PWMCH_OFFSET))
> +
> +static const u32 prescaler_table[] = {
> +   120,
> +   180,
> +   240,
> +   360,
> +   480,
> +   0,
> +   0,
> +   0,
> +   12000,
> +   24000,
> +   36000,
> +   48000,
> +   72000,
> +   0,
> +   0,
> +   0, /* Actually 1 but tested separately */
> +};
> +
> +struct sun4i_pwm_data {
> +   bool has_prescaler_bypass;
> +   bool has_rdy;
> +};
> +
> +struct sun4i_pwm_chip {
> +   struct pwm_chip chip;
> +   struct clk *clk;
> +   void __iomem *base;
> +   spinlock_t ctrl_lock;
> +   const struct sun4i_pwm_data *data;
> +};
> +
> +static inline struct sun4i_pwm_chip *to_sun4i_pwm_chip(struct pwm_chip *chip)
> +{
> +   return container_of(chip, struct sun4i_pwm_chip, chip);
> +}
> +
> +static inline u32 sun4i_pwm_readl(struct sun4i_pwm_chip *chip,
> + unsigned long offset)
> +{
> +   return readl(chip->base + offset);
> +}
> +
> +static inline void sun4i_pwm_writel(struct sun4i_pwm_chip *chip,
> +   u32 val, unsigned long offset)
> +{
> +   writel(val, chip->base + offset);
> +}
> +
> +static int sun4i_pwm_config(struct pwm_chip *chip, struct pwm_device *pwm,
> +   int duty_ns, int period_ns)
> +{
> +   struct sun4i_pwm_chip *sun4i_pwm = to_sun4i_pwm_chip(chip);
> +   u32 prd, dty, val, clk_gate;
> +   u64 clk_rate, div = 0;
> +   unsigned int prescaler = 0;
> +   int err;
> +
> +   clk_rate = clk_get_rate(sun4i_pwm->clk);
> +
> +   if (sun4i_pwm->data->has_prescaler_bypass) {
> +   /* Fir

Re: [PATCH -mm 0/6] memcg: release kmemcg_id on css offline

[Vladimir Davydov]

Drop this patch please. It needs a rebase. Will resend soon.

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

Re: [RESEND PATCH v3] clocksource: exynos_mct: Add the support for Exynos 64bit SoC

[Daniel Lezcano]

On 01/19/2015 01:54 AM, Chanwoo Choi wrote:

Dear Daniel and Kukjin,

On 01/15/2015 01:02 AM, Daniel Lezcano wrote:

On 01/14/2015 04:51 PM, Kukjin Kim wrote:

On 01/14/15 14:33, Chanwoo Choi wrote:

Hi,

+ Doug, Olof


This patch adds the support for Exynos 64bit SoC. The delay_timer is only used
for Exynos 32bit SoC.


Yes, the Exynos MCT(Multi-Core Timer) is 64bit timer and it is available
on 64bit exynos SoC such as exynos7. But basically ARMv8 architecture is
including ARM ARCH timer (ARM Generic Timer) and exynos7 also has
implemented it and additionally its access is faster than using memory
mapped register called SFR for MCT...so Doug submitted patch to use MCT
on 32bit exynos SoCs before.

I know using MCT on 64bit exynos is usefulness for Power Management and
I need to talk to relevant guys in office again. If anything, I'll let
you know.


I will wait for your answer before digging more the patch.


Hi Chanwoo,

[ ... ]


Do you have any comment about this patch?


Yes, a similar patch has been posted for the tegra2 timer to run on 
arm64. The patch in question put macros #ifdef CONFIG_ARM64 to disable 
some parts of the code. That ended, the tegra2 timer was not needed for 
the moment because of the arch timer present, so it has been disabled 
from the compilation until a proper fix without macros could be proposed.


It is happening exactly the same with this patch. As Kukjin pointed it, 
the exynos_mct may not be needed (at least until a backup timer is 
needed at PM time).


I suggest you look at a nicer way to fix that instead of introducing 
macros (which is by the way valid but not recommended by the CodingStyle 
rules) and perhaps sync with Paul and Thierry [cc'ed] to find a common 
solution.


  -- Daniel


--
  Linaro.org │ Open source software for ARM SoCs

Follow Linaro:   Facebook |
 Twitter |
 Blog

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

Re: [PATCH] media: i2c: add new driver for single string flash.

[Andy Shevchenko]

On Mon, 2015-01-19 at 17:25 +0900, Daniel Jeong wrote:
> This patch adds the driver for the single string flash products of TI.
> Several single string flash controllers of TI have similar register map
> and bit data. This driver supports four products,lm3556, lm3561, lm3642
> and lm3648.

Why not to name it as lm3648 to be in align with other drivers?

Or even better solution (I suppose) to create a "library" and on top of
that one driver per each device?

Sakari, what do you think?

> 
> Signed-off-by: Daniel Jeong 
> ---
>  drivers/media/i2c/Kconfig   |9 +
>  drivers/media/i2c/Makefile  |1 +
>  drivers/media/i2c/ti-ss-flash.c |  744 
> +++
>  include/media/ti-ss-flash.h |   33 ++
>  4 files changed, 787 insertions(+)
>  create mode 100644 drivers/media/i2c/ti-ss-flash.c
>  create mode 100644 include/media/ti-ss-flash.h
> 
> diff --git a/drivers/media/i2c/Kconfig b/drivers/media/i2c/Kconfig
> index 205d713..886c1fb 100644
> --- a/drivers/media/i2c/Kconfig
> +++ b/drivers/media/i2c/Kconfig
> @@ -638,6 +638,15 @@ config VIDEO_LM3646
> This is a driver for the lm3646 dual flash controllers. It controls
> flash, torch LEDs.
>  
> +config VIDEO_TI_SS_FLASH
> + tristate "TI Single String Flash driver support"
> + depends on I2C && VIDEO_V4L2 && MEDIA_CONTROLLER
> + depends on MEDIA_CAMERA_SUPPORT
> + select REGMAP_I2C
> + ---help---
> +   This is a driver for the signle string flash controllers of TI.
> +   It supports LM3556, LM3561, LM3642 and LM3648.
> +
>  comment "Video improvement chips"
>  
>  config VIDEO_UPD64031A
> diff --git a/drivers/media/i2c/Makefile b/drivers/media/i2c/Makefile
> index 98589001..0e523ec 100644
> --- a/drivers/media/i2c/Makefile
> +++ b/drivers/media/i2c/Makefile
> @@ -73,6 +73,7 @@ obj-$(CONFIG_VIDEO_ADP1653) += adp1653.o
>  obj-$(CONFIG_VIDEO_AS3645A)  += as3645a.o
>  obj-$(CONFIG_VIDEO_LM3560)   += lm3560.o
>  obj-$(CONFIG_VIDEO_LM3646)   += lm3646.o
> +obj-$(CONFIG_VIDEO_TI_SS_FLASH)  += ti-ss-flash.o
>  obj-$(CONFIG_VIDEO_SMIAPP_PLL)   += smiapp-pll.o
>  obj-$(CONFIG_VIDEO_AK881X)   += ak881x.o
>  obj-$(CONFIG_VIDEO_IR_I2C)  += ir-kbd-i2c.o
> diff --git a/drivers/media/i2c/ti-ss-flash.c b/drivers/media/i2c/ti-ss-flash.c
> new file mode 100644
> index 000..035aeba
> --- /dev/null
> +++ b/drivers/media/i2c/ti-ss-flash.c
> @@ -0,0 +1,744 @@
> +/*
> + * drivers/media/i2c/ti-ss-flash.c
> + * General device driver for Single String FLASH LED Drivers of TI
> + * It covers lm3556, lm3561, lm3642 and lm3648.
> + *
> + * Copyright (C) 2015 Texas Instruments
> + *
> + * Contact: Daniel Jeong 
> + *   Ldd-Mlp 
> + *
> + * This program is free software; you can redistribute it and/or
> + * modify it under the terms of the GNU General Public License
> + * version 2 as published by the Free Software Foundation.
> + *
> + */
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +/* operation mode */
> +enum led_opmode {
> + OPMODE_SHDN = 0x0,
> + OPMODE_INDI_IR,
> + OPMODE_TORCH,
> + OPMODE_FLASH,
> +};
> +
> +/*
> + * register data
> + * @reg : register
> + * @mask : mask bits
> + * @shift : bit shift of data
> + */
> +struct ctrl_reg {
> + unsigned int reg;
> + unsigned int mask;
> + unsigned int shift;
> +};
> +
> +/*
> + * unit data
> + * @min : min value of brightness or timeout
> + *brightness : uA
> + * timeout: ms
> + * @step : step value of brightness or timeout
> + *brightness : uA
> + * timeout: ms
> + * @knee: knee point of step of brightness/timeout
> + *brightness : uA
> + * timeout: ms
> + * @knee_step : step value of brightness or timeout after knee point
> + *brightness : uA
> + * timeout: ms
> + * @max : max value of brightness or timeout
> + *brightness : uA
> + * timeout: ms
> + * @ctrl : register info to control brightness or timeout
> + */
> +struct ssflash_config {
> + unsigned int min;
> + unsigned int step;
> + unsigned int knee;
> + unsigned int knee_step;
> + unsigned int max;
> + struct ctrl_reg ctrl;
> +};
> +
> +/*
> + * @reg : fault register
> + * @mask : fault mask bit
> + * @v4l2_fault : bit mapping to V4L2_FLASH_FAULT_
> + *   refer to include//uapi/linux/v4l2-controls.h
> + */
> +struct ssflash_fault {
> + unsigned int reg;
> + unsigned int mask;
> + unsigned int v4l2_fault;
> +};
> +
> +#define NUM_V4L2_FAULT 9
> +
> +/*
> + * ssflash data
> + * @name: device name
> + * @mode: operation mode control data
> + * @flash_br: flash brightness register and bit data
> + * @timeout: timeout control data
> + * @strobe: strobe control data
> + * @torch_br: torch brightness register and bit data
> + * @fault: fault data
> + * @func: initialize function
> +

Re: [RFC 2/3] regmap: Use the enhancement of i2c API to address circular dependency problem

[Paul Osmialowski]

On Fri, 16 Jan 2015, Mark Brown wrote:


On Fri, Jan 16, 2015 at 06:36:14PM +0100, Paul Osmialowski wrote:

On Fri, 16 Jan 2015, Mark Brown wrote:



I don't know what this means, sorry.  I'm also very worried about the
fact that this is being discussed purely in terms of I2C - why would
this not affect other buses?



I tried to open some gate for further extension to any bus that is used for
regmap communications. Currently it goes down to regmap-i2c.c since I
enhanced i2c API for this. Anyone who feels it is useful or saves oneself
from locking troubles can voluntarily adapt other regmap-i2c.* places (as
needed?).



My whole point is that I proposed a way to solve nasty deadlock which is
better to fix than just leave as it is. I got a feeling that situation I
adressed here may occur others too, so I proposed this extension that allows
future adaptations. I don't expect it to be accepted easily (i.e. I'm new
here and have mixed feelins about proposing changes that go so far),
therefore I prepared other solution for this particular deadlock that occurs
on this particular device.


What I'm saying is that I want to understand this change from a point of
view that isn't tied to I2C - at the regmap level what is this doing,


From the regmap point of view, it allows its functions to have a chance to 
prepare transfer medium for (synchronous) transfer (no matter what bus 
handles it) before it actually start to happen (then unprepare it when 
it's done) and crucially before any lock is obtained in functions like 
regmap_write(), regmap_read() or regmap_update_bits.


Maybe adding a pair of callbacks (map->reg_write_sync_prepared(), 
map->reg_read_sync_prepared()) would make situation clearer.



I2C is a bus that has some properties which you're saying needs some
changes, what are those properties and those changes?


I'm not saying I2C as a bus requires changes. What I'm saying is that I2C 
API can be extended to allow more detailed control on what happens with 
the transfer.





+   void (*reg_unprepare_sync_io)(void *context);



The first question here is why this only affects synchronous I/O or
alternatively why these operations have _sync in the name if they aren't
for synchronous I/O.



IMHO this whole idea is against asynchronous I/O.


Can you be more specific please?  If something needs preparing it seems
like it'd need preparing over an async transaction just as much as over
a synchronous one.



Even with those preparation and unpreparation stages, this transfer is 
still synchronous. For example, it starts when regmap_read() starts and 
ends when regmap_read() ends. Nothing is queued or deferred. Namely, when 
max_gen_clk_unprepare() function calls regmap_update_bits() it expects 
that when regmap_update_bits() returned, no outstanding transfer are 
happening nor waiting to proceed. Everything must be completed before 
returning to max_gen_clk_unprepare().



+   if (bus) {
+   map->reg_prepare_sync_io = regmap_bus_prepare_sync_io;
+   map->reg_unprepare_sync_io = regmap_bus_unprepare_sync_io;
+   }



Why are we using these indirections instead of assigning the operation
directly?  They...



I followed the pattern used throughout this file.


Not in this pattern where the caller needs to check too.



I don't persist on that. Apparently, you're the author of this file, 
though regmap_init() function was later expanded by other guys. They never 
assigned bus callback function pointers directly to map operation 
callbacks. It is possible to replace 'map->reg_prepare_sync_io = 
regmap_bus_prepare_sync_io' with 'map->reg_prepare_sync_io = 
map->bus->prepare_sync_io' - this will compile and this will work 
properly. But IMHO it wouldn't match with what the others did.

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

[PATCH v4] ARM: mvebu: remove two selects of ARM_ERRATA_753970

[Paul Bolle]

ARM_ERRATA_753970 was renamed to PL310_ERRATA_753970 in v3.2, through
commit fa0ce4035d48 ("ARM: 7162/1: errata: tidy up Kconfig options for
PL310 errata workarounds"). Still, two selects were added in v3.15 that
used the previous name. So these selects have always been nops.

It is clear that the intention here was to select PL310_ERRATA_753970.
But as, apparently, nothing broke for four releases we can assume
PL310_ERRATA_753970 isn't actually needed. So let's not rename these two
selects but just drop them instead.

Signed-off-by: Paul Bolle 
---
v4: Do no bother anymore to rename these selects. I've tried to do that
a few times ever since v3.15-rc1 was released. Last time, v3, was in
https://lkml.org/lkml/2014/9/12/231 . And since the people who
intruduced this issue apparently aren't bothered by it, neither should
I. So just do the safe and easy thing, which is removing these two
selects, as they are nops now.

Done on top of next-20150119.

 arch/arm/mach-mvebu/Kconfig | 2 --
 1 file changed, 2 deletions(-)

diff --git a/arch/arm/mach-mvebu/Kconfig b/arch/arm/mach-mvebu/Kconfig
index c1e4567a5ab3..e8e5fa25121c 100644
--- a/arch/arm/mach-mvebu/Kconfig
+++ b/arch/arm/mach-mvebu/Kconfig
@@ -37,7 +37,6 @@ config MACH_ARMADA_370
 config MACH_ARMADA_375
bool "Marvell Armada 375 boards" if ARCH_MULTI_V7
select ARM_ERRATA_720789
-   select ARM_ERRATA_753970
select ARM_GIC
select ARMADA_375_CLK
select HAVE_ARM_SCU
@@ -52,7 +51,6 @@ config MACH_ARMADA_375
 config MACH_ARMADA_38X
bool "Marvell Armada 380/385 boards" if ARCH_MULTI_V7
select ARM_ERRATA_720789
-   select ARM_ERRATA_753970
select ARM_GIC
select ARMADA_38X_CLK
select HAVE_ARM_SCU
-- 
1.9.3

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

Re: [PATCH v4 4/9] clk: samsung: exynos4: Add divider clock id for memory bus frequency

[MyungJoo Ham]

>   
>  This patch adds the divider clock id for Exynos4 memory bus frequency.
> The clock id is used fo DVFS (Dynamic Voltage/Frequency Scaling)
> feature of exynos memory bus frequency.
> 
> Cc: Sylwester Nawrocki 
> Cc: Tomasz Figa 
> Signed-off-by: Chanwoo Choi 

Acked-by: MyungJoo Ham 

Anyway, you will need reviews from Sylwester and/or Tomasz for this one.



Cheers,
MyungJoo

Re: [PATCH v4 6/9] ARM: dts: Add memory bus node for Exynos4210

[MyungJoo Ham]

>   
>  This patch adds the memory bus node for Exynos4210 SoC. Exynos4210 SoC has
> one memory bus to translate data between DRAM and eMMC/sub-IPs because
> Exynos4210 must need only one regulator for memory bus.
> 
> Following list specifies the detailed relation between memory bus clock and
> sub-IPs:
> - DMC/ACP clock : DMC (Dynamic Memory Controller)
> - ACLK200 clock : LCD0
> - ACLK100 clock : PERIL/PERIR/MFC(PCLK)
> - ACLK160 clock : CAM/TV/LCD0/LCD1
> - ACLK133 clock : FSYS/GPS
> - GDL/GDR clock : leftbus/rightbus
> - SCLK_MFC clock : MFC
> 
> Cc: Kukjin Kim 
> Cc: Myungjoo Ham 
> Cc: Kyungmin Park 
> Signed-off-by: Chanwoo Choi 

Acked-by: MyungJoo Ham 


Revisiting good old days..?
(good to see the first busfreq driver experimented with is
being DT-nized... :)  )


Cheers,
MyungJoo

Re: linux-next: manual merge of the luto-misc tree with the tip tree

[Borislav Petkov]

On Mon, Jan 19, 2015 at 05:08:39PM +1100, Stephen Rothwell wrote:
> Hi Andy,
> 
> Today's linux-next merge of the luto-misc tree got a conflict in
> arch/x86/kernel/cpu/mcheck/mce.c between commit 83737691e586 ("x86,
> mce: Fix sparse errors") from the tip tree and commit d4812e169de4
> ("x86, mce: Get rid of TIF_MCE_NOTIFY and associated mce tricks") from
> the luto-misc tree.
> 
> I fixed it up (the latter removed some of the code changed by the
> former) and can carry the fix as necessary (no action is required).

That must be the piece of the hunk touching mce_info. Yes, the correct
solution is to follow what d4812e169de4 does.

Thanks Stephen :)

---
diff --git a/arch/x86/kernel/cpu/mcheck/mce.c b/arch/x86/kernel/cpu/mcheck/mce.c
index 800d423f1e92..d23179900755 100644
--- a/arch/x86/kernel/cpu/mcheck/mce.c
+++ b/arch/x86/kernel/cpu/mcheck/mce.c
@@ -1004,51 +1004,6 @@ static void mce_clear_state(unsigned long *toclear)
 }
 
 /*
- * Need to save faulting physical address associated with a process
- * in the machine check handler some place where we can grab it back
- * later in mce_notify_process()
- */
-#defineMCE_INFO_MAX16
-
-struct mce_info {
-   atomic_tinuse;
-   struct task_struct  *t;
-   __u64   paddr;
-   int restartable;
-} mce_info[MCE_INFO_MAX];

-- 
Regards/Gruss,
Boris.

ECO tip #101: Trim your mails when you reply.
--
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v4 1/9] devfreq: exynos: Add generic exynos memory bus frequency driver

[Chanwoo Choi]

Dear Myungjoo,

On 01/19/2015 06:20 PM, MyungJoo Ham wrote:
>>   
>>  This patch adds the generic exynos bus frequency driver for memory bus
>> with DEVFREQ framework. The Samsung Exynos SoCs have the common architecture
>> for memory bus between DRAM memory and MMC/sub IP in SoC. This driver can
>> support the memory bus frequency driver for Exynos SoCs.
>>
>> Each memory bus block has a clock for memory bus speed and frequency
>> table which is changed according to the utilization of memory bus on runtime.
>> And then each memory bus group has the one more memory bus blocks and
>> OPP table (including frequency and voltage), regulator, devfreq-event
>> devices.
>>
>> There are a little difference about the number of memory bus because each 
>> Exynos
>> SoC have the different sub-IP and different memory bus speed. In spite of 
>> this
>> difference among Exynos SoCs, we can support almost Exynos SoC by adding
>> unique data of memory bus to devicetree file.
>>
>> Cc: Myungjoo Ham 
>> Cc: Kyungmin Park 
>> Cc: Kukjin Kim 
>> Signed-off-by: Chanwoo Choi 
>> ---
>>  drivers/devfreq/Kconfig |  15 +
>>  drivers/devfreq/Makefile|   1 +
>>  drivers/devfreq/exynos/Makefile |   1 +
>>  drivers/devfreq/exynos/exynos-bus.c | 598 
>> 
>>  4 files changed, 615 insertions(+)
>>  create mode 100644 drivers/devfreq/exynos/exynos-bus.c
>>
> 
> []
> 
>> +static void exynos_bus_exit(struct device *dev)
>> +{
>> +struct exynos_memory_bus *bus = dev_get_drvdata(dev);
>> +int i, ret;
>> +
>> +ret = exynos_bus_disable_edev(bus);
>> +if (ret < 0)
>> +dev_warn(dev, "failed to disable the devfreq-event devices\n");
>> +
>> +for (i = 0; i < bus->block_count; i++)
>> +clk_disable_unprepare(bus->block[i].clk);
>> +
>> +if (regulator_is_enabled(bus->regulator))
>> +regulator_disable(bus->regulator);
> 
> This is_enabled check is itchy.
> 
> Why do you need this here?
> Please let me know what kind of errors here.
> (note that this may simply hide errors made by other drivers)
> 
> Adding this condition does not introduce additional error, but
> could you please let me know why it is here? This is supposed to be
> paired with probe.

The regulator_is_enabled() is not necessary according to your comment.
I'll remove it.

> 
> 
> Except this point (valid if addressed or {explained and understood}),
> Acked-by: MyungJoo Ham 

Thanks for your review.

Best Regards,
Chanwoo Choi

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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 7/9] ARM: dts: Add the support for exynos busfreq on Exynos3250-based Rinato/Monk board

[MyungJoo Ham]

>   
>  This patch adds the Exynos3250 memory-bus node which includes the regulator
> and devfreq-event phandle. The devfreq-event phandle is used for the
> governor of devfreq device and provide the current usage state of
> MIF (Memory Interface) / INT (Internal) memory bus group.
> 
> Cc: Kukjin Kim 
> Cc: Myungjoo Ham 
> Cc: Kyungmin Park 
> Cc: Youngjun Cho 
> Signed-off-by: Chanwoo Choi 
> Acked-by: Kyungmin Park 

I am not so confident with this SoC as I didn't write any kernel codes
for Exynos3250 devices. Anyway, as the syntax and usage appears good to me.

Acked-by: MyungJoo Ham 

> ---
>  arch/arm/boot/dts/exynos3250-monk.dts   | 12 
>  arch/arm/boot/dts/exynos3250-rinato.dts | 12 
>  2 files changed, 24 insertions(+)
> 
N�r��yb�X��ǧv�^�)޺{.n�+{zX����ܨ}���Ơz�&j:+v���zZ+��+zf���h���~i���z��w���?�&�)ߢf��^jǫy�m��@A�a���
0��h���i

Re: [PATCH v4 8/9] ARM: dts: Add the support for exynos busfreq on Exynos4412-based TRATS2 board

[MyungJoo Ham]

>   
>  This patch adds the Exynos4412 memory-bus node which includes the regulator
> and devfreq-event phandle. The devfreq-event phandle is used for the
> governor of devfreq device and provide the current usage state of
> MIF (Memory Interface) / INT (Internal) memory bus group.
> 
> Cc: Kukjin Kim 
> Cc: Myungjoo Ham 
> Cc: Kyungmin Park 
> Signed-off-by: Chanwoo Choi 

Acked-by: MyungJoo Ham 


N�r��yb�X��ǧv�^�)޺{.n�+{zX����ܨ}���Ơz�&j:+v���zZ+��+zf���h���~i���z��w���?�&�)ߢf��^jǫy�m��@A�a���
0��h���i

Re: [PATCH v4 9/9] devfreq: exynos: Remove unused exynos4 memory busfreq driver

[MyungJoo Ham]

>   
>  This patch removes the unused exynos4 memory busfreq driver by adding generic
> exynos memory bus frequency driver.
> 
> Cc: Myungjoo Ham 
> Cc: Kyungmin Park 
> Signed-off-by: Chanwoo Choi 

Reviewed-by: MyungJoo Ham 

> ---
>  drivers/devfreq/Kconfig  |   12 -
>  drivers/devfreq/exynos/Makefile  |1 -
>  drivers/devfreq/exynos/exynos4_bus.c | 1055 
> --
>  drivers/devfreq/exynos/exynos4_bus.h |  110 
>  4 files changed, 1178 deletions(-)
>  delete mode 100644 drivers/devfreq/exynos/exynos4_bus.c
>  delete mode 100644 drivers/devfreq/exynos/exynos4_bus.h
> 

Re: [PATCH v4] ARM: mvebu: remove two selects of ARM_ERRATA_753970

[Paul Bolle]

Andy, Joe,

On Mon, 2015-01-19 at 10:32 +0100, Paul Bolle wrote:
> ARM_ERRATA_753970 was renamed to PL310_ERRATA_753970 in v3.2, through
> commit fa0ce4035d48 ("ARM: 7162/1: errata: tidy up Kconfig options for
> PL310 errata workarounds"). Still, two selects were added in v3.15 that
> used the previous name. So these selects have always been nops.
> 
> It is clear that the intention here was to select PL310_ERRATA_753970.
> But as, apparently, nothing broke for four releases we can assume
> PL310_ERRATA_753970 isn't actually needed. So let's not rename these two
> selects but just drop them instead.
> 
> Signed-off-by: Paul Bolle 

Checkpatch in next-21050119 complains:
ERROR: Please use git commit description style 'commit <12+ chars of sha1> 
("")' - ie: 'commit fa0ce4035d48 ("ARM: 7162/1: errata: tidy up 
Kconfig options for PL310 errata workarounds")'
#7: 
commit fa0ce4035d48 ("ARM: 7162/1: errata: tidy up Kconfig options for

total: 1 errors, 0 warnings, 14 lines checked

Your patch has style problems, please review.

Perhaps it doesn't notice the quote spans two lines. Can this be fixed
please?

Thanks,


Paul Bolle

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] arm64: Track system support for mixed endian EL0

[Suzuki K. Poulose]

On 16/01/15 16:15, Suzuki K. Poulose wrote:

On 16/01/15 15:53, Will Deacon wrote:

On Thu, Jan 15, 2015 at 12:36:04PM +, Suzuki K. Poulose wrote:

From: "Suzuki K. Poulose" 

This patch keeps track of the mixed endian EL0 support across
the system and provides helper functions to export it. The status
is a boolean indicating whether all the CPUs on the system supports
mixed endian at EL0.

Signed-off-by: Suzuki K. Poulose 
---
   arch/arm64/include/asm/cpufeature.h |   10 ++
   arch/arm64/kernel/cpuinfo.c |   22 ++
   2 files changed, 32 insertions(+)

diff --git a/arch/arm64/include/asm/cpufeature.h 
b/arch/arm64/include/asm/cpufeature.h
index 07547cc..c7f68d1 100644
--- a/arch/arm64/include/asm/cpufeature.h
+++ b/arch/arm64/include/asm/cpufeature.h
@@ -26,6 +26,9 @@

   #define ARM64_NCAPS  2

+#define ID_AA64MMFR0_EL1_BigEndEL0 (0x1UL << 16)
+#define ID_AA64MMFR0_EL1_BigEnd(0x1UL << 8)


I don't like the CaMeLcAsE. Also, perhaps these definitions should be
somewhere like cputype.h?

Yeah, I tried to keep it aligned withe ARMv8 architecture definition of
those bits. Will change it.
Things are a bit messy w.r.t the definitions. We have cpu.h,
cpufeature.h and cputype.h. I could move it to cputype.h, where we
already have MIDR_ defintions.




+
   #ifndef __ASSEMBLY__

   extern DECLARE_BITMAP(cpu_hwcaps, ARM64_NCAPS);
@@ -51,7 +54,14 @@ static inline void cpus_set_cap(unsigned int num)
__set_bit(num, cpu_hwcaps);
   }

+static inline bool id_aa64mmfr0_mixed_endian_el0(unsigned long mmfr0)
+{
+   return !!(mmfr0 & (ID_AA64MMFR0_EL1_BigEndEL0 | 
ID_AA64MMFR0_EL1_BigEnd));
+}


These are 4-bit fields and I think you think you should be treating them
as such.

OK




+
   void check_local_cpu_errata(void);
+bool system_supports_mixed_endian_el0(void);
+bool cpu_supports_mixed_endian_el0(void);

   #endif /* __ASSEMBLY__ */

diff --git a/arch/arm64/kernel/cpuinfo.c b/arch/arm64/kernel/cpuinfo.c
index 07d435c..b6d1135 100644
--- a/arch/arm64/kernel/cpuinfo.c
+++ b/arch/arm64/kernel/cpuinfo.c
@@ -35,6 +35,7 @@
*/
   DEFINE_PER_CPU(struct cpuinfo_arm64, cpu_data);
   static struct cpuinfo_arm64 boot_cpu_data;
+static bool mixed_endian_el0 = true;

   static char *icache_policy_str[] = {
[ICACHE_POLICY_RESERVED] = "RESERVED/UNKNOWN",
@@ -68,6 +69,26 @@ static void cpuinfo_detect_icache_policy(struct 
cpuinfo_arm64 *info)
pr_info("Detected %s I-cache on CPU%d\n", icache_policy_str[l1ip], cpu);
   }

+bool cpu_supports_mixed_endian_el0(void)
+{
+   return id_aa64mmfr0_mixed_endian_el0(read_cpuid(ID_AA64MMFR0_EL1));
+}


Can we not just define a mask/value pair and have code do the MMFR0 access
inline? It also feels a bit over-engineered like this.

Sure, will change this.


On a second thought, we need the id_aa64mmfr0_mixed_endian_el0() for 
another code path. For a new CPU detected at boot time via 
cpuinfo_store_cpu(), where we get the 'filled' cpuinfo_arm64 which 
already has the id_aa64mmfr0. So we do:


+
+static void update_mixed_endian_el0_support(struct cpuinfo_arm64 *info)
+{
+   mixed_endian_el0 &= 
id_aa64mmfr0_mixed_endian_el0(info->reg_id_aa64mmfr0);
+}

So, having a helper to extract the support from the id_aa64mmfr0 makes 
it a bit more ordered.


But yes, we could switch to mask/value pair.

Thanks
Suzuki


Thanks
Suzuki


Will




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




--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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 2/8] mfd: Add atmel-st driver

[Lee Jones]

On Mon, 12 Jan 2015, Alexandre Belloni wrote:

> The Atmel System Timer IP available on the at91rm9200 exposes both a timer 
> and a
> watchdog.
> 
> Signed-off-by: Alexandre Belloni 
> Acked-by: Boris Brezillon 
> ---
>  drivers/mfd/Kconfig  |  7 
>  drivers/mfd/Makefile |  1 +
>  drivers/mfd/atmel-st.c   | 77 
> 
>  include/linux/mfd/atmel-st.h | 47 +++
>  4 files changed, 132 insertions(+)
>  create mode 100644 drivers/mfd/atmel-st.c
>  create mode 100644 include/linux/mfd/atmel-st.h

This driver looks pretty pointless.  Why can't you request the sysconf
registers from within the drivers themselves?

> diff --git a/drivers/mfd/Kconfig b/drivers/mfd/Kconfig
> index 2e6b7311fabc..3c5185c0cf06 100644
> --- a/drivers/mfd/Kconfig
> +++ b/drivers/mfd/Kconfig
> @@ -78,6 +78,13 @@ config MFD_BCM590XX
>   help
> Support for the BCM590xx PMUs from Broadcom
>  
> +config MFD_ATMEL_ST
> + bool "Atmel System Timer"
> + select MFD_CORE
> + default SOC_AT91RM9200
> + help
> +   If you say Y here you get support for the Atmel System Timer.
> +
>  config MFD_AXP20X
>   bool "X-Powers AXP20X"
>   select MFD_CORE
> diff --git a/drivers/mfd/Makefile b/drivers/mfd/Makefile
> index 53467e211381..1ecd416f25c5 100644
> --- a/drivers/mfd/Makefile
> +++ b/drivers/mfd/Makefile
> @@ -104,6 +104,7 @@ obj-$(CONFIG_PMIC_DA9052) += da9052-core.o
>  obj-$(CONFIG_MFD_DA9052_SPI) += da9052-spi.o
>  obj-$(CONFIG_MFD_DA9052_I2C) += da9052-i2c.o
>  obj-$(CONFIG_MFD_AXP20X) += axp20x.o
> +obj-$(CONFIG_MFD_ATMEL_ST)   += atmel-st.o
>  
>  obj-$(CONFIG_MFD_LP3943) += lp3943.o
>  obj-$(CONFIG_MFD_LP8788) += lp8788.o lp8788-irq.o
> diff --git a/drivers/mfd/atmel-st.c b/drivers/mfd/atmel-st.c
> new file mode 100644
> index ..54106fcfe898
> --- /dev/null
> +++ b/drivers/mfd/atmel-st.c
> @@ -0,0 +1,77 @@
> +/*
> + * Copyright (C) 2014 Free Electrons
> + * Copyright (C) 2014 Atmel
> + *
> + * Author: Alexandre Belloni 
> + *
> + * This program is free software; you can redistribute it and/or modify it
> + * under the terms of the GNU General Public License version 2 as published 
> by
> + * the Free Software Foundation.
> + *
> + * 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 .
> + */
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +static const struct mfd_cell atmel_st_cells[] = {
> + {
> + .name = "atmel_st_timer",
> + },
> + {
> + .name = "atmel_st_watchdog",
> + },
> +};
> +
> +static int atmel_st_probe(struct platform_device *pdev)
> +{
> + struct device *dev = &pdev->dev;
> + struct regmap *regmap_st;
> +
> + regmap_st = syscon_node_to_regmap(dev->of_node);
> + if (IS_ERR(regmap_st))
> + return PTR_ERR(regmap_st);
> + dev_set_drvdata(dev, regmap_st);
> +
> + return mfd_add_devices(dev, -1, atmel_st_cells,
> +ARRAY_SIZE(atmel_st_cells),
> +NULL, 0, NULL);
> +}
> +
> +static int atmel_st_remove(struct platform_device *pdev)
> +{
> + mfd_remove_devices(&pdev->dev);
> +
> + return 0;
> +}
> +
> +static const struct of_device_id atmel_st_match[] = {
> + { .compatible = "atmel,at91rm9200-st" },
> + { /* sentinel */ },
> +};
> +
> +static struct platform_driver atmel_st_driver = {
> + .probe = atmel_st_probe,
> + .remove = atmel_st_remove,
> + .driver = {
> + .name = "atmel-system-timer",
> + .owner = THIS_MODULE,
> + .of_match_table = atmel_st_match,
> + },
> +};
> +module_platform_driver(atmel_st_driver);
> +
> +MODULE_ALIAS("platform:atmel-st");
> +MODULE_AUTHOR("Alexandre Belloni ");
> +MODULE_DESCRIPTION("Atmel ST (System Timer) driver");
> +MODULE_LICENSE("GPL");
> diff --git a/include/linux/mfd/atmel-st.h b/include/linux/mfd/atmel-st.h
> new file mode 100644
> index ..88c6cf8eeb2b
> --- /dev/null
> +++ b/include/linux/mfd/atmel-st.h
> @@ -0,0 +1,47 @@
> +/*
> + * Copyright (C) 2005 Ivan Kokshaysky
> + * Copyright (C) SAN People
> + *
> + * System Timer (ST) - System peripherals registers.
> + * Based on AT91RM9200 datasheet revision E.
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License as published by
> + * the Free Software Foundation; either version 2 of the License, or
> + * (at your option) any later version.
> + */
> +
> +#ifndef __LINUX_MFD_ATMEL_ST_H
> +#define __LINUX_MFD_ATMEL_ST_H
> +
> +

[PATCH 2/3] sound: dummy, use del_timer_sync

[Jiri Slaby]

Wait for the timer to really quit, not only by ensuring it is not in
the critical section.

BTW the spin_lock in here does not disable BH, so that it could
deadlock.

Signed-off-by: Jiri Slaby 
Cc: Jaroslav Kysela 
Cc: Takashi Iwai 
Cc: alsa-de...@alsa-project.org
---
 sound/drivers/dummy.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/sound/drivers/dummy.c b/sound/drivers/dummy.c
index d11baaf0f0b4..6d6bf4093583 100644
--- a/sound/drivers/dummy.c
+++ b/sound/drivers/dummy.c
@@ -281,9 +281,9 @@ static int dummy_systimer_start(struct snd_pcm_substream 
*substream)
 static int dummy_systimer_stop(struct snd_pcm_substream *substream)
 {
struct dummy_systimer_pcm *dpcm = substream->runtime->private_data;
-   spin_lock(&dpcm->lock);
-   del_timer(&dpcm->timer);
-   spin_unlock(&dpcm->lock);
+
+   del_timer_sync(&dpcm->timer);
+
return 0;
 }
 
-- 
2.2.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 1/3] sound: dummy, use setup_timer and mod_timer

[Jiri Slaby]

From: Roman Kollar 

Use setup_timer and mod_timer instead of structure assignments as it
is the preferred way to setup and set the timer.

Signed-off-by: Roman Kollar 
Signed-off-by: Jiri Slaby 
Cc: Jaroslav Kysela 
Cc: Takashi Iwai 
Cc: alsa-de...@alsa-project.org
---
 sound/drivers/dummy.c | 10 --
 1 file changed, 4 insertions(+), 6 deletions(-)

diff --git a/sound/drivers/dummy.c b/sound/drivers/dummy.c
index 5d0dfb787cec..d11baaf0f0b4 100644
--- a/sound/drivers/dummy.c
+++ b/sound/drivers/dummy.c
@@ -245,9 +245,8 @@ struct dummy_systimer_pcm {
 
 static void dummy_systimer_rearm(struct dummy_systimer_pcm *dpcm)
 {
-   dpcm->timer.expires = jiffies +
-   (dpcm->frac_period_rest + dpcm->rate - 1) / dpcm->rate;
-   add_timer(&dpcm->timer);
+   mod_timer(&dpcm->timer, jiffies +
+   (dpcm->frac_period_rest + dpcm->rate - 1) / dpcm->rate);
 }
 
 static void dummy_systimer_update(struct dummy_systimer_pcm *dpcm)
@@ -340,9 +339,8 @@ static int dummy_systimer_create(struct snd_pcm_substream 
*substream)
if (!dpcm)
return -ENOMEM;
substream->runtime->private_data = dpcm;
-   init_timer(&dpcm->timer);
-   dpcm->timer.data = (unsigned long) dpcm;
-   dpcm->timer.function = dummy_systimer_callback;
+   setup_timer(&dpcm->timer, dummy_systimer_callback,
+   (unsigned long) dpcm);
spin_lock_init(&dpcm->lock);
dpcm->substream = substream;
return 0;
-- 
2.2.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/3] sound: dummy, avoid races with timer

[Jiri Slaby]

There is a race between timer and process contexts. Process context
does not disable irqs, so when a timer ticks inside process' critical
section, the system can deadlock. Fix this by a traditional _irqsave
variant of spin_lock.

Signed-off-by: Jiri Slaby 
Cc: Jaroslav Kysela 
Cc: Takashi Iwai 
Cc: alsa-de...@alsa-project.org
---
 sound/drivers/dummy.c | 13 +
 1 file changed, 9 insertions(+), 4 deletions(-)

diff --git a/sound/drivers/dummy.c b/sound/drivers/dummy.c
index 6d6bf4093583..18a7cfc99078 100644
--- a/sound/drivers/dummy.c
+++ b/sound/drivers/dummy.c
@@ -271,10 +271,13 @@ static void dummy_systimer_update(struct 
dummy_systimer_pcm *dpcm)
 static int dummy_systimer_start(struct snd_pcm_substream *substream)
 {
struct dummy_systimer_pcm *dpcm = substream->runtime->private_data;
-   spin_lock(&dpcm->lock);
+   unsigned long flags;
+
+   spin_lock_irqsave(&dpcm->lock, flags);
dpcm->base_time = jiffies;
dummy_systimer_rearm(dpcm);
-   spin_unlock(&dpcm->lock);
+   spin_unlock_irqrestore(&dpcm->lock, flags);
+
return 0;
 }
 
@@ -322,12 +325,14 @@ static snd_pcm_uframes_t
 dummy_systimer_pointer(struct snd_pcm_substream *substream)
 {
struct dummy_systimer_pcm *dpcm = substream->runtime->private_data;
+   unsigned long flags;
snd_pcm_uframes_t pos;
 
-   spin_lock(&dpcm->lock);
+   spin_lock_irqsave(&dpcm->lock, flags);
dummy_systimer_update(dpcm);
pos = dpcm->frac_pos / HZ;
-   spin_unlock(&dpcm->lock);
+   spin_unlock_irqrestore(&dpcm->lock, flags);
+
return pos;
 }
 
-- 
2.2.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 1/2] mfd: rtsx_usb: Fix runtime PM deadlock

[Lee Jones]

On Thu, 15 Jan 2015, Roger Tseng wrote:

> sd_set_power_mode() in derived module drivers/mmc/host/rtsx_usb_sdmmc.c
> acquires dev_mutex and then calls pm_runtime_get_sync() to make sure the
> device is awake while initializing a newly inserted card. Once it is
> called during suspending state and explicitly before rtsx_usb_suspend()
> acquires the same dev_mutex, both routine deadlock and further hang the
> driver because pm_runtime_get_sync() waits the pending PM operations.
> 
> Fix this by using an empty suspend method. mmc_core always turns the
> LED off after a request is done and thus it is ok to remove the only
> rtsx_usb_turn_off_led() here.
> 
> Cc:  # v3.16+
> Fixes: 730876be2566 ("mfd: Add realtek USB card reader driver")
> Signed-off-by: Roger Tseng 
> ---
>  drivers/mfd/rtsx_usb.c | 9 -
>  1 file changed, 9 deletions(-)

Applied, thanks.

> diff --git a/drivers/mfd/rtsx_usb.c b/drivers/mfd/rtsx_usb.c
> index dbdd0faeb6ce..076694126e5d 100644
> --- a/drivers/mfd/rtsx_usb.c
> +++ b/drivers/mfd/rtsx_usb.c
> @@ -687,15 +687,6 @@ static int rtsx_usb_suspend(struct usb_interface *intf, 
> pm_message_t message)
>   dev_dbg(&intf->dev, "%s called with pm message 0x%04x\n",
>   __func__, message.event);
>  
> - /*
> -  * Call to make sure LED is off during suspend to save more power.
> -  * It is NOT a permanent state and could be turned on anytime later.
> -  * Thus no need to call turn_on when resunming.
> -  */
> - mutex_lock(&ucr->dev_mutex);
> - rtsx_usb_turn_off_led(ucr);
> - mutex_unlock(&ucr->dev_mutex);
> -
>   return 0;
>  }
>  

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

Re: [PATCH] BLACKFIN MEDIA DRIVER: rewrite the blackfin style of read/write into common style

[Hans Verkuil]

On 01/19/2015 04:13 AM, Hao Liang wrote:
> Hi Hans,
> 
> Thank you for your reply.
> This change comes largely from a non-blackfin architecture dsp processor of 
> ADI want to reuse this driver.
> And i have tested common read/write function on blackfin board to ensure 
> usability and stability.

Well, looking at arch/blackfin/include/asm/def_LPBlackfin.h it seems that for 
certain
blackfin variants the bfin_read/write functions insert an extra nop, so unless 
you
test on one of those variants you wouldn't see any problems relating to this 
change
(and possibly not even then if this is a rare race condition).

You will have to check this with the blackfin architecture maintainer, Steven 
Miao
(added to the CC list). Without the OK of someone who actually understands that
architecture and the 'ANOMALY_05000198' issues I am not going to merge this.

If the bfin_read/write functions are really needed for the blackfin 
architecture,
then you can always make ppi_read/write functions that check the architecture 
and use
bfin_read/write if it is a blackfin and readw/writew otherwise.

That should be safe.

Regards,

Hans

> 
> BR
> Hao
> 
> 2015-01-16 19:34 GMT+08:00 Hans Verkuil  >:
> 
> Hi Hao,
> 
> Why would you do this? read/writew() is AFAICT not the same as 
> bfin_read/write16
> (defined in arch/blackfin/include/asm/def_LPBlackfin.h). And all other 
> blackfin
> sources I've seen all use bfin_read/write.
> 
> So unless there is a good reason for this change I am not going to accept 
> this.
> 
> Regards,
> 
> Hans
> 
> On 01/14/2015 07:57 AM, Hao Liang wrote:
> > Signed-off-by: Hao Liang  >
> > ---
> >  drivers/media/platform/blackfin/ppi.c |   72 
> -
> >  1 file changed, 35 insertions(+), 37 deletions(-)
> >
> > diff --git a/drivers/media/platform/blackfin/ppi.c 
> b/drivers/media/platform/blackfin/ppi.c
> > index cff63e5..de4b5c7 100644
> > --- a/drivers/media/platform/blackfin/ppi.c
> > +++ b/drivers/media/platform/blackfin/ppi.c
> > @@ -20,6 +20,7 @@
> >  #include 
> >  #include 
> >  #include 
> > +#include 
> >
> >  #include 
> >  #include 
> > @@ -59,10 +60,10 @@ static irqreturn_t ppi_irq_err(int irq, void 
> *dev_id)
> >   /* register on bf561 is cleared when read
> >* others are W1C
> >*/
> > - status = bfin_read16(®->status);
> > + status = readw(®->status);
> >   if (status & 0x3000)
> >   ppi->err = true;
> > - bfin_write16(®->status, 0xff00);
> > + writew(0xff00, ®->status);
> >   break;
> >   }
> >   case PPI_TYPE_EPPI:
> > @@ -70,10 +71,10 @@ static irqreturn_t ppi_irq_err(int irq, void 
> *dev_id)
> >   struct bfin_eppi_regs *reg = info->base;
> >   unsigned short status;
> >
> > - status = bfin_read16(®->status);
> > + status = readw(®->status);
> >   if (status & 0x2)
> >   ppi->err = true;
> > - bfin_write16(®->status, 0x);
> > + writew(0x, ®->status);
> >   break;
> >   }
> >   case PPI_TYPE_EPPI3:
> > @@ -81,10 +82,10 @@ static irqreturn_t ppi_irq_err(int irq, void 
> *dev_id)
> >   struct bfin_eppi3_regs *reg = info->base;
> >   unsigned long stat;
> >
> > - stat = bfin_read32(®->stat);
> > + stat = readl(®->stat);
> >   if (stat & 0x2)
> >   ppi->err = true;
> > - bfin_write32(®->stat, 0xc0ff);
> > + writel(0xc0ff, ®->stat);
> >   break;
> >   }
> >   default:
> > @@ -139,26 +140,25 @@ static int ppi_start(struct ppi_if *ppi)
> >   case PPI_TYPE_PPI:
> >   {
> >   struct bfin_ppi_regs *reg = info->base;
> > - bfin_write16(®->control, ppi->ppi_control);
> > + writew(ppi->ppi_control, ®->control);
> >   break;
> >   }
> >   case PPI_TYPE_EPPI:
> >   {
> >   struct bfin_eppi_regs *reg = info->base;
> > - bfin_write32(®->control, ppi->ppi_control);
> > + writel(ppi->ppi_control, ®->control);
> >   break;
> >   }
> >   case PPI_TYPE_EPPI3:
> >   {
> >   struct bfin_eppi3_regs *reg = info->base;
> > - bfin_write32(®->ctl, ppi->ppi_control);
> > + writel(ppi->ppi_control, ®->ctl);
> >   break;
> >   }
> >   default:
> >   return -EINVAL;
> >   }
> 

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

[Kirill A. Shutemov]

On Mon, Jan 19, 2015 at 11:38:17AM +0300, Cyrill Gorcunov wrote:
> On Mon, Jan 19, 2015 at 07:17:18PM +1100, Stephen Rothwell wrote:
> > Hi Andrew,
> > 
> > After merging the akpm tree, today's linux-next build (sparc defconfig)
> > failed like this:
> > 
> > In file included from arch/sparc/include/asm/bug.h:20:0,
> >  from include/linux/bug.h:4,
> >  from include/linux/thread_info.h:11,
> >  from include/asm-generic/preempt.h:4,
> >  from arch/sparc/include/generated/asm/preempt.h:1,
> >  from include/linux/preempt.h:18,
> >  from include/linux/spinlock.h:50,
> >  from include/linux/mmzone.h:7,
> >  from include/linux/gfp.h:5,
> >  from include/linux/slab.h:14,
> >  from mm/mmap.c:12:
> > mm/mmap.c: In function 'exit_mmap':
> > mm/mmap.c:2858:46: error: 'PUD_SHIFT' undeclared (first use in this 
> > function)
> > round_up(FIRST_USER_ADDRESS, PUD_SIZE) >> PUD_SHIFT);
> >   ^
> > include/asm-generic/bug.h:86:25: note: in definition of macro 'WARN_ON'
> >   int __ret_warn_on = !!(condition);\
> >  ^
> > mm/mmap.c:2858:46: note: each undeclared identifier is reported only once 
> > for each function it appears in
> > round_up(FIRST_USER_ADDRESS, PUD_SIZE) >> PUD_SHIFT);
> >   ^
> > include/asm-generic/bug.h:86:25: note: in definition of macro 'WARN_ON'
> >   int __ret_warn_on = !!(condition);\
> >  ^
> > 
> > Caused by commit b316feb3c37f ("mm: account pmd page tables to the
> > process").  32 bit sparc does not seem to define PUD_SHIFT ...
> > 
> > I am not sure what the correct fix is here, so I just did the following
> > patch for today.
> > 
> > From: Stephen Rothwell 
> > Date: Mon, 19 Jan 2015 19:10:53 +1100
> > Subject: [PATCH] mm: account pmd page tables to the process fix
> > 
> > Signed-off-by: Stephen Rothwell 
> > ---
> >  mm/mmap.c | 2 ++
> >  1 file changed, 2 insertions(+)
> > 
> > diff --git a/mm/mmap.c b/mm/mmap.c
> > index 6a7d36d133fb..25271805ab39 100644
> > --- a/mm/mmap.c
> > +++ b/mm/mmap.c
> > @@ -2854,8 +2854,10 @@ void exit_mmap(struct mm_struct *mm)
> >  
> > WARN_ON(atomic_long_read(&mm->nr_ptes) >
> > round_up(FIRST_USER_ADDRESS, PMD_SIZE) >> PMD_SHIFT);
> > +#ifdef PUD_SHIFT
> > WARN_ON(mm_nr_pmds(mm) >
> > round_up(FIRST_USER_ADDRESS, PUD_SIZE) >> PUD_SHIFT);
> > +#endif
> >  }
> >  
> >  /* Insert vm structure into process list sorted by address
> 
> Looks like it should be #ifdef CONFIG_MMU, Kirill?

No. The problem is that  doesn't define
PUD_SHIFT. The fix is proposed:

http://www.spinics.net/lists/linux-mm/msg83249.html

-- 
 Kirill A. Shutemov
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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: does the semantics of MAP_LOCKED is equal to mlock() function?

[Michal Hocko]

See http://marc.info/?l=linux-mm&m=142122902313315&w=2 for more
information.

On Mon 19-01-15 14:17:43, long.wanglong wrote:
> Hi all:
> 
> In the latest kernel, i set the memory limit (4096) in a test cgroup. and add 
> the test task.
> the test code code is:
> 
> testcase 1: mmap with MAP_LOCKED flag(memsize = 8192)
> 
> 185 p = mmap(NULL, memsize, PROT_WRITE | PROT_READ,
> 186  MAP_PRIVATE | MAP_ANONYMOUS | MAP_LOCKED, 0, 0);
> 187 if (p == MAP_FAILED)
> 188 err(1, "mmap(lock) failed");
>   
> expect: invoke OOM killer.
> result: not invoke OOM killer.
> 
> 
> testcase 2: mmap without MAP_LOCKED flag and the call mlock (memsize = 8192)
> 
> 185 p = mmap(NULL, memsize, PROT_WRITE | PROT_READ,
> 186  MAP_PRIVATE | MAP_ANONYMOUS, 0, 0);
> 187 if (p == MAP_FAILED)
> 188 err(1, "mmap(lock) failed");
> 189
> 190 if (mlock(p, memsize) == -1)
> 191 err(1, "mlock failed")
> 
> expect: invoke OOM killer.
> result: invoke OOM killer.
> 
> in the Linux Programmer's Manual:
> 
> MAP_LOCKED (since Linux 2.5.37)
>   Lock the pages of the mapped region into memory in the manner
>   of mlock(2).  This flag is ignored in older kernels.
>   
> and
>mlock() locks pages in the address range starting at addr and
>continuing for len bytes.  All pages that contain a part of the
>specified address range are guaranteed to be resident in RAM when the
>call returns successfully; the pages are guaranteed to stay in RAM
>until later unlocked.
>   
> According to the description in the manual, the two testcases are equivalent.
> 
> why the first testcase does not invoke OOM killer?
> does the mmap with MAP_LOCKED flag will not immediately allocate physical 
> memory?
> 
> 
> Best Regards
> Wang Long
> 

-- 
Michal Hocko
SUSE Labs
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] mfd: rtsx_usb: Defer autosuspend while card exists

[Lee Jones]

On Thu, 15 Jan 2015, Roger Tseng wrote:

> A card insertion happens after the lastest polling before reader is
> suspended may never have a chance to be detected. Under current 1-HZ
> polling interval setting in mmc_core, the worst case of such
> undetectablility is about 1 second.
> 
> To further reduce the undetectability, detect card slot again in suspend
> method and defer the autosuspend if the slot is loaded. The default 2
> second autosuspend delay of USB subsystem should let the next polling
> detects the card.
> 
> Signed-off-by: Roger Tseng 
> ---
>  drivers/mfd/rtsx_usb.c | 14 ++
>  1 file changed, 14 insertions(+)

Applied, thanks.

> diff --git a/drivers/mfd/rtsx_usb.c b/drivers/mfd/rtsx_usb.c
> index 076694126e5d..63883fd025c0 100644
> --- a/drivers/mfd/rtsx_usb.c
> +++ b/drivers/mfd/rtsx_usb.c
> @@ -687,6 +687,20 @@ static int rtsx_usb_suspend(struct usb_interface *intf, 
> pm_message_t message)
>   dev_dbg(&intf->dev, "%s called with pm message 0x%04x\n",
>   __func__, message.event);
>  
> + if (PMSG_IS_AUTO(message)) {
> + if (mutex_trylock(&ucr->dev_mutex)) {
> + rtsx_usb_get_card_status(ucr, &val);
> + mutex_unlock(&ucr->dev_mutex);
> +
> + /* Defer the autosuspend if card exists */
> + if (val & (SD_CD | MS_CD))
> + return -EAGAIN;
> + } else {
> + /* There is an ongoing operation*/
> + return -EAGAIN;
> + }
> + }
> +
>   return 0;
>  }
>  

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

Re: [PATCH 3/3] sound: dummy, avoid races with timer

[Takashi Iwai]

At Mon, 19 Jan 2015 10:42:56 +0100,
Jiri Slaby wrote:
> 
> There is a race between timer and process contexts. Process context
> does not disable irqs, so when a timer ticks inside process' critical
> section, the system can deadlock. Fix this by a traditional _irqsave
> variant of spin_lock.
> 
> Signed-off-by: Jiri Slaby 
> Cc: Jaroslav Kysela 
> Cc: Takashi Iwai 
> Cc: alsa-de...@alsa-project.org
> ---
>  sound/drivers/dummy.c | 13 +
>  1 file changed, 9 insertions(+), 4 deletions(-)
> 
> diff --git a/sound/drivers/dummy.c b/sound/drivers/dummy.c
> index 6d6bf4093583..18a7cfc99078 100644
> --- a/sound/drivers/dummy.c
> +++ b/sound/drivers/dummy.c
> @@ -271,10 +271,13 @@ static void dummy_systimer_update(struct 
> dummy_systimer_pcm *dpcm)
>  static int dummy_systimer_start(struct snd_pcm_substream *substream)
>  {
>   struct dummy_systimer_pcm *dpcm = substream->runtime->private_data;
> - spin_lock(&dpcm->lock);
> + unsigned long flags;
> +
> + spin_lock_irqsave(&dpcm->lock, flags);
>   dpcm->base_time = jiffies;
>   dummy_systimer_rearm(dpcm);
> - spin_unlock(&dpcm->lock);
> + spin_unlock_irqrestore(&dpcm->lock, flags);
> +

This looks correct, but...


>   return 0;
>  }
>  
> @@ -322,12 +325,14 @@ static snd_pcm_uframes_t
>  dummy_systimer_pointer(struct snd_pcm_substream *substream)
>  {
>   struct dummy_systimer_pcm *dpcm = substream->runtime->private_data;
> + unsigned long flags;
>   snd_pcm_uframes_t pos;
>  
> - spin_lock(&dpcm->lock);
> + spin_lock_irqsave(&dpcm->lock, flags);
>   dummy_systimer_update(dpcm);
>   pos = dpcm->frac_pos / HZ;
> - spin_unlock(&dpcm->lock);
> + spin_unlock_irqrestore(&dpcm->lock, flags);
> +

This chunk is superfluous.  The pointer callback is guaranteed to be
called in the irq-disabled context.


thanks,

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

[alsa-devel] [PATCH v2 2/3] ASoC: samsung: Document Trats2 audio subsystem bindings

[Inha Song]

This patch add Trats2 audio subsystem bindings document.

Signed-off-by: Inha Song 
---
 .../bindings/sound/samsung,trats2-wm1811.txt   | 25 ++
 1 file changed, 25 insertions(+)
 create mode 100644 
Documentation/devicetree/bindings/sound/samsung,trats2-wm1811.txt

diff --git a/Documentation/devicetree/bindings/sound/samsung,trats2-wm1811.txt 
b/Documentation/devicetree/bindings/sound/samsung,trats2-wm1811.txt
new file mode 100644
index 000..319ff07
--- /dev/null
+++ b/Documentation/devicetree/bindings/sound/samsung,trats2-wm1811.txt
@@ -0,0 +1,25 @@
+Samsung Exynos Trats2 audio with WM1811 codec
+
+Required properties:
+
+ - compatible : Must be "samsung,trats2-audio"
+ - samsung,i2s-controller : The phandle of the I2S controller
+ - samsung,model : The user visible name of this sound
+ - samsung,audio-codec : The phandle of the WM1811 audio codec
+ - samsung,audio-routing : A list of the connections between audio
+   components. each entry is a pair of strings, the first being the
+   connection's sink, the second being the connection's source
+
+Example:
+
+sound {
+   compatible = "samsung,trats2-audio";
+   samsung,i2s-controller = <&i2s0>;
+   samsung,model = "Trats2";
+   samsung,audio-codec = <&wm1811>;
+   samsung,audio-routing =
+   "SPK", "SPKOUTLN",
+   "SPK", "SPKOUTLP",
+   "SPK", "SPKOUTRN",
+   "SPK", "SPKOUTRP";
+};
-- 
2.0.0.390.gcb682f8

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

[alsa-devel] [PATCH v2 3/3] ARM: dts: Add sound nodes for exynos4412-trats2

[Inha Song]

This patch add WM1811 audio codec, I2S interface and the sound
machine nodes to enable audio on exynos4412-trats2 board.

Signed-off-by: Inha Song 
---
 arch/arm/boot/dts/exynos4412-trats2.dts | 39 +
 1 file changed, 39 insertions(+)

diff --git a/arch/arm/boot/dts/exynos4412-trats2.dts 
b/arch/arm/boot/dts/exynos4412-trats2.dts
index 29231b4..7a52cca 100644
--- a/arch/arm/boot/dts/exynos4412-trats2.dts
+++ b/arch/arm/boot/dts/exynos4412-trats2.dts
@@ -203,6 +203,25 @@
};
};
 
+   i2c@138A {
+   samsung,i2c-sda-delay = <100>;
+   samsung,i2c-slave-addr = <0x10>;
+   samsung,i2c-max-bus-freq = <10>;
+   pinctrl-0 = <&i2c4_bus>;
+   pinctrl-names = "default";
+   status = "okay";
+
+   wm1811: wm1811@1a {
+   compatible = "wlf,wm1811";
+   reg = <0x1a>;
+   clocks = <&pmu_system_controller 0>;
+   clock-names = "MCLK1";
+   DCVDD-supply = <&ldo3_reg>;
+   DBVDD1-supply = <&ldo3_reg>;
+   wlf,ldo1ena = <&gpj0 4 0>;
+   };
+   };
+
i2c@138D {
samsung,i2c-sda-delay = <100>;
samsung,i2c-slave-addr = <0x10>;
@@ -838,6 +857,26 @@
};
};
 
+   i2s0: i2s@0383 {
+   pinctrl-0 = <&i2s0_bus>;
+   pinctrl-names = "default";
+   status = "okay";
+   };
+
+   sound {
+   compatible = "samsung,trats2-audio";
+   assigned-clocks = <&pmu_system_controller 0>;
+   assigned-clock-parents =  <&clock CLK_XUSBXTI>;
+   samsung,i2s-controller = <&i2s0>;
+   samsung,model = "Trats2";
+   samsung,audio-codec = <&wm1811>;
+   samsung,audio-routing =
+   "SPK", "SPKOUTLN",
+   "SPK", "SPKOUTLP",
+   "SPK", "SPKOUTRN",
+   "SPK", "SPKOUTRP";
+   };
+
exynos-usbphy@125B {
status = "okay";
};
-- 
2.0.0.390.gcb682f8

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

[alsa-devel] [PATCH v2 1/3] ASoC: samsung: Add machine driver for Trats2

[Inha Song]

This patch add the sound machine driver for Trats2 board.
The codec operate in master mode.

Signed-off-by: Inha Song 
---
 sound/soc/samsung/Kconfig |   8 ++
 sound/soc/samsung/Makefile|   2 +
 sound/soc/samsung/trats2_wm1811.c | 218 ++
 3 files changed, 228 insertions(+)
 create mode 100644 sound/soc/samsung/trats2_wm1811.c

diff --git a/sound/soc/samsung/Kconfig b/sound/soc/samsung/Kconfig
index fc67f97..8031423 100644
--- a/sound/soc/samsung/Kconfig
+++ b/sound/soc/samsung/Kconfig
@@ -245,3 +245,11 @@ config SND_SOC_ARNDALE_RT5631_ALC5631
 depends on SND_SOC_SAMSUNG
 select SND_SAMSUNG_I2S
 select SND_SOC_RT5631
+
+config SND_SOC_SAMSUNG_TRATS2_WM1811
+   tristate "SoC I2S Audio support for WM1811 on Tizen Trats2 board"
+   depends on SND_SOC_SAMSUNG
+   select SND_SOC_WM8994
+   select SND_SAMSUNG_I2S
+   help
+ Say Y if you want to add support for SoC audio on the Tizen Trats2 
board.
diff --git a/sound/soc/samsung/Makefile b/sound/soc/samsung/Makefile
index 31e3dba..e2b7b1b 100644
--- a/sound/soc/samsung/Makefile
+++ b/sound/soc/samsung/Makefile
@@ -46,6 +46,7 @@ snd-soc-littlemill-objs := littlemill.o
 snd-soc-bells-objs := bells.o
 snd-soc-odroidx2-max98090-objs := odroidx2_max98090.o
 snd-soc-arndale-rt5631-objs := arndale_rt5631.o
+snd-soc-trats2-wm1811-objs := trats2_wm1811.o
 
 obj-$(CONFIG_SND_SOC_SAMSUNG_JIVE_WM8750) += snd-soc-jive-wm8750.o
 obj-$(CONFIG_SND_SOC_SAMSUNG_NEO1973_WM8753) += snd-soc-neo1973-wm8753.o
@@ -73,3 +74,4 @@ obj-$(CONFIG_SND_SOC_LITTLEMILL) += snd-soc-littlemill.o
 obj-$(CONFIG_SND_SOC_BELLS) += snd-soc-bells.o
 obj-$(CONFIG_SND_SOC_ODROIDX2) += snd-soc-odroidx2-max98090.o
 obj-$(CONFIG_SND_SOC_ARNDALE_RT5631_ALC5631) += snd-soc-arndale-rt5631.o
+obj-$(CONFIG_SND_SOC_SAMSUNG_TRATS2_WM1811) += snd-soc-trats2-wm1811.o
diff --git a/sound/soc/samsung/trats2_wm1811.c 
b/sound/soc/samsung/trats2_wm1811.c
new file mode 100644
index 000..b937612
--- /dev/null
+++ b/sound/soc/samsung/trats2_wm1811.c
@@ -0,0 +1,218 @@
+/*
+ * Copyright (C) 2015 Samsung Electronics Co., Ltd.
+ *
+ * This program is free software; you can redistribute  it and/or modify it
+ * under  the terms of  the GNU General  Public License as published by the
+ * Free Software Foundation;  either version 2 of the  License, or (at your
+ * option) any later version.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include "i2s.h"
+#include "../codecs/wm8994.h"
+
+struct trats2_machine_priv {
+   struct clk *clk_mclk;
+};
+
+static struct trats2_machine_priv trats2_wm1811_priv;
+
+static const struct snd_kcontrol_new trats2_controls[] = {
+   SOC_DAPM_PIN_SWITCH("SPK"),
+};
+
+static const struct snd_soc_dapm_widget trats2_dapm_widgets[] = {
+   SND_SOC_DAPM_SPK("SPK", NULL),
+};
+
+static int trats2_aif1_hw_params(struct snd_pcm_substream *substream,
+struct snd_pcm_hw_params *params)
+{
+   struct snd_soc_pcm_runtime *rtd = substream->private_data;
+   struct snd_soc_dai *codec_dai = rtd->codec_dai;
+   struct trats2_machine_priv *priv = snd_soc_card_get_drvdata(rtd->card);
+   unsigned int sysclk_rate;
+   unsigned int mclk_rate =
+   (unsigned int)clk_get_rate(priv->clk_mclk);
+   int ret;
+
+   /* SYSCLK must be greater than 4.096MHz */
+   if (params_rate(params) == 8000 || params_rate(params) == 11025)
+   sysclk_rate = params_rate(params) * 512;
+   else
+   sysclk_rate = params_rate(params) * 256;
+
+   /* Set the codec FLL1 */
+   ret = snd_soc_dai_set_pll(codec_dai, WM8994_FLL1, WM8994_FLL_SRC_MCLK1,
+ mclk_rate, sysclk_rate);
+   if (ret < 0) {
+   dev_err(codec_dai->dev, "Failed to set FLL1: %d\n", ret);
+   return ret;
+   }
+
+   /* Set the codec SYSCLK */
+   ret = snd_soc_dai_set_sysclk(codec_dai, WM8994_SYSCLK_FLL1,
+sysclk_rate, SND_SOC_CLOCK_IN);
+   if (ret < 0) {
+   dev_err(codec_dai->dev, "Failed to set SYSCLK: %d\n", ret);
+   return ret;
+   }
+
+   return 0;
+}
+
+static int trats2_aif1_startup(struct snd_pcm_substream *substream)
+{
+   struct snd_soc_pcm_runtime *rtd = substream->private_data;
+   struct trats2_machine_priv *priv = snd_soc_card_get_drvdata(rtd->card);
+   int ret;
+
+   ret = clk_prepare_enable(priv->clk_mclk);
+   if (ret) {
+   dev_err(rtd->card->dev, "Failed to enable mclk: %d\n", ret);
+   return ret;
+   }
+
+   return 0;
+}
+
+static void trats2_aif1_shutdown(struct snd_pcm_substream *substream)
+{
+   struct snd_soc_pcm_runtime *rtd = substream->private_data;
+   struct trats2_machine_priv *priv = snd_soc_card_get_drvdata(rtd->card);
+
+   clk_disable_unprepare(priv->clk_mclk);
+}
+
+static const struct 

[alsa-devel] [PATCH v2 0/3] Sound support for Exynos4412 Trats2 board

[Inha Song]

This patch-set adds basic sound support for the Trats2 boards.
It just support primary I2s and external speaker playback.

Changes in v2:
  - Remove unnecessary lines in Trats2 machine driver
  - move clock enable/disable to .startup / .shutdown
  - Fix code style issues
  - Remove mclk DT property in Trats2 sound and add MCLK1 property in WM1811 
node.
(MCLK1 is optional property in WM8994 node - refer: 
Document/devicetree/bindings/sound/wm8994.txt)
  - Use mclk that defined in WM1811 DT node.
  - Add "samsung,audio-codec" property to required properties.

Inha Song (3):
  ASoC: samsung: Add machine driver for Trats2
  ASoC: samsung: Document Trats2 audio subsystem bindings
  ARM: dts: Add sound nodes for exynos4412-trats2

 .../bindings/sound/samsung,trats2-wm1811.txt   |  25 +++
 arch/arm/boot/dts/exynos4412-trats2.dts|  39 
 sound/soc/samsung/Kconfig  |   8 +
 sound/soc/samsung/Makefile |   2 +
 sound/soc/samsung/trats2_wm1811.c  | 218 +
 5 files changed, 292 insertions(+)
 create mode 100644 
Documentation/devicetree/bindings/sound/samsung,trats2-wm1811.txt
 create mode 100644 sound/soc/samsung/trats2_wm1811.c

-- 
2.0.0.390.gcb682f8

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

[PATCH 1/1] ARM: dts: dra72-evm: Add qspi device

[Mugunthan V N]

These add device tree entry for qspi device on dra72-evm.

Signed-off-by: Mugunthan V N 
---

This patch is tested on linux-next and the boot logs is here [1]

[1] - http://pastebin.ubuntu.com/9783555/ 

---
 arch/arm/boot/dts/dra72-evm.dts | 77 +
 1 file changed, 77 insertions(+)

diff --git a/arch/arm/boot/dts/dra72-evm.dts b/arch/arm/boot/dts/dra72-evm.dts
index 89085d0..cacddd7 100644
--- a/arch/arm/boot/dts/dra72-evm.dts
+++ b/arch/arm/boot/dts/dra72-evm.dts
@@ -121,6 +121,18 @@
0x418   (MUX_MODE15)/* wakeup0.off */
>;
};
+
+   qspi1_pins: pinmux_qspi1_pins {
+   pinctrl-single,pins = <
+   0x74 (PIN_OUTPUT | MUX_MODE1)   /* gpmc_a13.qspi1_rtclk 
*/
+   0x78 (PIN_INPUT | MUX_MODE1)/* gpmc_a14.qspi1_d3 */
+   0x7c (PIN_INPUT | MUX_MODE1)/* gpmc_a15.qspi1_d2 */
+   0x80 (PIN_INPUT | MUX_MODE1)/* gpmc_a16.qspi1_d1 */
+   0x84 (PIN_INPUT | MUX_MODE1)/* gpmc_a17.qspi1_d0 */
+   0x88 (PIN_OUTPUT | MUX_MODE1)   /* qpmc_a18.qspi1_sclk 
*/
+   0xb8 (PIN_OUTPUT | MUX_MODE1)   /* gpmc_cs2.qspi1_cs0 */
+   >;
+   };
 };
 
 &i2c1 {
@@ -461,3 +473,68 @@
pinctrl-0 = <&dcan1_pins_default>;
pinctrl-1 = <&dcan1_pins_sleep>;
 };
+
+&qspi {
+   status = "okay";
+   pinctrl-names = "default";
+   pinctrl-0 = <&qspi1_pins>;
+
+   spi-max-frequency = <4800>;
+   m25p80@0 {
+   compatible = "s25fl256s1";
+   spi-max-frequency = <4800>;
+   reg = <0>;
+   spi-tx-bus-width = <1>;
+   spi-rx-bus-width = <4>;
+   spi-cpol;
+   spi-cpha;
+   #address-cells = <1>;
+   #size-cells = <1>;
+
+   /* MTD partition table.
+* The ROM checks the first four physical blocks
+* for a valid file to boot and the flash here is
+* 64KiB block size.
+*/
+   partition@0 {
+   label = "QSPI.SPL";
+   reg = <0x 0x1>;
+   };
+   partition@1 {
+   label = "QSPI.SPL.backup1";
+   reg = <0x0001 0x0001>;
+   };
+   partition@2 {
+   label = "QSPI.SPL.backup2";
+   reg = <0x0002 0x0001>;
+   };
+   partition@3 {
+   label = "QSPI.SPL.backup3";
+   reg = <0x0003 0x0001>;
+   };
+   partition@4 {
+   label = "QSPI.u-boot";
+   reg = <0x0004 0x0010>;
+   };
+   partition@5 {
+   label = "QSPI.u-boot-spl-os";
+   reg = <0x0014 0x0008>;
+   };
+   partition@6 {
+   label = "QSPI.u-boot-env";
+   reg = <0x001c 0x0001>;
+   };
+   partition@7 {
+   label = "QSPI.u-boot-env.backup1";
+   reg = <0x001d 0x001>;
+   };
+   partition@8 {
+   label = "QSPI.kernel";
+   reg = <0x001e 0x080>;
+   };
+   partition@9 {
+   label = "QSPI.file-system";
+   reg = <0x009e 0x0162>;
+   };
+   };
+};
-- 
2.2.1.62.g3f15098

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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 08/28] PCI: Introduce pci_host_assign_domain_nr() to assign domain

[Arnd Bergmann]

On Monday 19 January 2015 10:14:44 Yijing Wang wrote:
> >> I'm confused: the same code is already part of the PCI tree, but with
> >> Lorenzo Pieralisi listed as the patch author. The code is good,
> >> and I acked it in the past, but one of you is (probably by accident)
> >> misattributing the patch.
> >>
> >> Assuming that the patch that is already merged in next is the right
> >> one, I think you should rebase your series on top of
> >>
> >> git://git.kernel.org/pub/scm/linux/kernel/git/helgaas/pci.git#next
> >>
> >> to avoid conflicts like this one.
> >>
> > 
> > I think I just got confused because the code duplicates most of
> > pci_bus_assign_domain_nr(). Maybe this can be done in a better way
> > by splitting the existing function into 
> > 
> > static int pci_assign_domain_nr(struct device *)
> > {
> >   ... /* most of pci_bus_assign_domain_nr */
> > 
> >   return domain;
> > }
> > 
> > void pci_host_assign_domain_nr(struct pci_host_bridge *host)
> > {
> >   host->domain = pci_assign_domain_nr(host->dev.parent);
> > }
> > 
> > void pci_bus_assign_domain_nr(struct pci_bus *bus, struct device *parent)
> > {
> >   bus->domain_nr = pci_assign_domain_nr(parent);
> > }
> > 
> 
> Hi Arnd,
>I kept the almost duplicated pci_host_assign_domain_nr() and
> pci_bus_assign_domain_nr() here for building happy, because now
> platform specific pci_domain_nr() still exists which may get domain
> number from pci_bus. pci_bus_assign_domain_nr() will be removed in
> the last patch.
> 

I'm not sure I get your point: the approach I showed above seems to have
the same effect, except it doesn't duplicate code temporarily, which
makes it less error-prone in case your patch gets merged at the
same time as another patch that modifies pci_bus_assign_domain_nr.

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

Re: [PATCHv10 1/2] pwm: Add Allwinner SoC support

[Olliver Schinagl]

Hey Alexandre,

I'll pull your v10 and start testing that hopefully this week. I've been 
using an older version, v8 I think, without any trouble so far.


On 19-01-15 10:21, Chen-Yu Tsai wrote:

On Thu, Dec 18, 2014 at 5:15 AM, Alexandre Belloni
 wrote:

This adds a generic PWM framework driver for the PWM controller
found on Allwinner SoCs.

Hi,

Any news on this series?

ChenYu


Signed-off-by: Alexandre Belloni 
Acked-by: Maxime Ripard 
---
  drivers/pwm/Kconfig |  10 ++
  drivers/pwm/Makefile|   1 +
  drivers/pwm/pwm-sun4i.c | 366 
  3 files changed, 377 insertions(+)
  create mode 100644 drivers/pwm/pwm-sun4i.c

diff --git a/drivers/pwm/Kconfig b/drivers/pwm/Kconfig
index ef2dd2e4754b..07f533d2b5be 100644
--- a/drivers/pwm/Kconfig
+++ b/drivers/pwm/Kconfig
@@ -263,6 +263,16 @@ config PWM_STI
   To compile this driver as a module, choose M here: the module
   will be called pwm-sti.

+config PWM_SUN4I
+   tristate "Allwinner PWM support"
+   depends on ARCH_SUNXI || COMPILE_TEST
+   depends on HAS_IOMEM && COMMON_CLK
+   help
+ Generic PWM framework driver for Allwinner SoCs.
+
+ To compile this driver as a module, choose M here: the module
+ will be called pwm-sun4i.
+
  config PWM_TEGRA
 tristate "NVIDIA Tegra PWM support"
 depends on ARCH_TEGRA
diff --git a/drivers/pwm/Makefile b/drivers/pwm/Makefile
index c458606c3755..d607804deea1 100644
--- a/drivers/pwm/Makefile
+++ b/drivers/pwm/Makefile
@@ -24,6 +24,7 @@ obj-$(CONFIG_PWM_ROCKCHIP)+= pwm-rockchip.o
  obj-$(CONFIG_PWM_SAMSUNG)  += pwm-samsung.o
  obj-$(CONFIG_PWM_SPEAR)+= pwm-spear.o
  obj-$(CONFIG_PWM_STI)  += pwm-sti.o
+obj-$(CONFIG_PWM_SUN4I)+= pwm-sun4i.o
  obj-$(CONFIG_PWM_TEGRA)+= pwm-tegra.o
  obj-$(CONFIG_PWM_TIECAP)   += pwm-tiecap.o
  obj-$(CONFIG_PWM_TIEHRPWM) += pwm-tiehrpwm.o
diff --git a/drivers/pwm/pwm-sun4i.c b/drivers/pwm/pwm-sun4i.c
new file mode 100644
index ..cd9dde563018
--- /dev/null
+++ b/drivers/pwm/pwm-sun4i.c
@@ -0,0 +1,366 @@
+/*
+ * Driver for Allwinner sun4i Pulse Width Modulation Controller
+ *
+ * Copyright (C) 2014 Alexandre Belloni 
+ *
+ * Licensed under GPLv2.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#define PWM_CTRL_REG   0x0
+
+#define PWM_CH_PRD_BASE0x4
+#define PWM_CH_PRD_OFFSET  0x4
+#define PWM_CH_PRD(ch) (PWM_CH_PRD_BASE + PWM_CH_PRD_OFFSET * (ch))
+
+#define PWMCH_OFFSET   15
+#define PWM_PRESCAL_MASK   GENMASK(3, 0)
+#define PWM_PRESCAL_OFF0
+#define PWM_EN BIT(4)
+#define PWM_ACT_STATE  BIT(5)
+#define PWM_CLK_GATING BIT(6)
+#define PWM_MODE   BIT(7)
+#define PWM_PULSE  BIT(8)
+#define PWM_BYPASS BIT(9)
+
+#define PWM_RDY_BASE   28
+#define PWM_RDY_OFFSET 1
+#define PWM_RDY(ch)BIT(PWM_RDY_BASE + PWM_RDY_OFFSET * (ch))
+
+#define PWM_PRD(prd)   (((prd) - 1) << 16)
+#define PWM_PRD_MASK   GENMASK(15, 0)
+
+#define PWM_DTY_MASK   GENMASK(15, 0)
+
+#define BIT_CH(bit, chan)  ((bit) << ((chan) * PWMCH_OFFSET))
+
+static const u32 prescaler_table[] = {
+   120,
+   180,
+   240,
+   360,
+   480,
+   0,
+   0,
+   0,
+   12000,
+   24000,
+   36000,
+   48000,
+   72000,
+   0,
+   0,
+   0, /* Actually 1 but tested separately */
+};
+
+struct sun4i_pwm_data {
+   bool has_prescaler_bypass;
+   bool has_rdy;
+};
+
+struct sun4i_pwm_chip {
+   struct pwm_chip chip;
+   struct clk *clk;
+   void __iomem *base;
+   spinlock_t ctrl_lock;
+   const struct sun4i_pwm_data *data;
+};
+
+static inline struct sun4i_pwm_chip *to_sun4i_pwm_chip(struct pwm_chip *chip)
+{
+   return container_of(chip, struct sun4i_pwm_chip, chip);
+}
+
+static inline u32 sun4i_pwm_readl(struct sun4i_pwm_chip *chip,
+ unsigned long offset)
+{
+   return readl(chip->base + offset);
+}
+
+static inline void sun4i_pwm_writel(struct sun4i_pwm_chip *chip,
+   u32 val, unsigned long offset)
+{
+   writel(val, chip->base + offset);
+}
+
+static int sun4i_pwm_config(struct pwm_chip *chip, struct pwm_device *pwm,
+   int duty_ns, int period_ns)
+{
+   struct sun4i_pwm_chip *sun4i_pwm = to_sun4i_pwm_chip(chip);
+   u32 prd, dty, val, clk_gate;
+   u64 clk_rate, div = 0;
+   unsigned int prescaler = 0;
+   int err;
+
+   clk_rate = clk_get_rate(sun4i_pwm->clk);
+
+   if (sun4i_pwm->data->has_prescaler_bypass) {
+   /* First, test without any prescaler when available */
+   prescaler = PWM_PRESCAL_MASK;
+ 

Re: [PATCH tip 0/9] tracing: attach eBPF programs to tracepoints/syscalls/kprobe

[Masami Hiramatsu]

(2015/01/16 13:16), Alexei Starovoitov wrote:
> Hi Ingo, Steven,
> 
> This patch set is based on tip/master.
> It adds ability to attach eBPF programs to tracepoints, syscalls and kprobes.
> 
> Mechanism of attaching:
> - load program via bpf() syscall and receive program_fd
> - event_fd = open("/sys/kernel/debug/tracing/events/.../filter")
> - write 'bpf-123' to event_fd where 123 is program_fd
> - program will be attached to particular event and event automatically enabled
> - close(event_fd) will detach bpf program from event and event disabled
> 
> Program attach point and input arguments:
> - programs attached to kprobes receive 'struct pt_regs *' as an input.
>   See tracex4_kern.c that demonstrates how users can write a C program like:
>   SEC("events/kprobes/sys_write")
>   int bpf_prog4(struct pt_regs *regs)
>   {
>  long write_size = regs->dx; 
>  // here user need to know the proto of sys_write() from kernel
>  // sources and x64 calling convention to know that register $rdx
>  // contains 3rd argument to sys_write() which is 'size_t count'
> 
>   it's obviously architecture dependent, but allows building sophisticated
>   user tools on top, that can see from debug info of vmlinux which variables
>   are in which registers or stack locations and fetch it from there.
>   'perf probe' can potentialy use this hook to generate programs in user space
>   and insert them instead of letting kernel parse string during kprobe 
> creation.

Actually, this program just shows raw pt_regs for handlers, but I guess it is 
also
possible to pass event arguments from perf probe which given by user and 
perf-probe.
If we can write the script as

int bpf_prog4(s64 write_size)
{
   ...
}

This will be much easier to play with.

> - programs attached to tracepoints and syscalls receive 'struct bpf_context 
> *':
>   u64 arg1, arg2, ..., arg6;
>   for syscalls they match syscall arguments.
>   for tracepoints these args match arguments passed to tracepoint.
>   For example:
>   trace_sched_migrate_task(p, new_cpu); from sched/core.c
>   arg1 <- pwhich is 'struct task_struct *'
>   arg2 <- new_cpu  which is 'unsigned int'
>   arg3..arg6 = 0
>   the program can use bpf_fetch_u8/16/32/64/ptr() helpers to walk 
> 'task_struct'
>   or any other kernel data structures.
>   These helpers are using probe_kernel_read() similar to 'perf probe' which is
>   not 100% safe in both cases, but good enough.
>   To access task_struct's pid inside 'sched_migrate_task' tracepoint
>   the program can do:
>   struct task_struct *task = (struct task_struct *)ctx->arg1;
>   u32 pid = bpf_fetch_u32(&task->pid);
>   Since struct layout is kernel configuration specific such programs are not
>   portable and require access to kernel headers to be compiled,
>   but in this case we don't need debug info.
>   llvm with bpf backend will statically compute task->pid offset as a constant
>   based on kernel headers only.
>   The example of this arbitrary pointer walking is tracex1_kern.c
>   which does skb->dev->name == "lo" filtering.

At least I would like to see this way on kprobes event too, since it should be
treated as a traceevent.

> In all cases the programs are called before trace buffer is allocated to
> minimize the overhead, since we want to filter huge number of events, but
> buffer alloc/free and argument copy for every event is too costly.
> Theoretically we can invoke programs after buffer is allocated, but it
> doesn't seem needed, since above approach is faster and achieves the same.
> 
> Note, tracepoint/syscall and kprobe programs are two different types:
> BPF_PROG_TYPE_TRACING_FILTER and BPF_PROG_TYPE_KPROBE_FILTER,
> since they expect different input.
> Both use the same set of helper functions:
> - map access (lookup/update/delete)
> - fetch (probe_kernel_read wrappers)
> - memcmp (probe_kernel_read + memcmp)
> - dump_stack
> - trace_printk
> The last two are mainly to debug the programs and to print data for user
> space consumptions.
> 
> Portability:
> - kprobe programs are architecture dependent and need user scripting
>   language like ktap/stap/dtrace/perf that will dynamically generate
>   them based on debug info in vmlinux

If we can use kprobe event as a normal traceevent, user scripting can be
architecture independent too. Only perf-probe fills the gap. All other
userspace tools can collaborate with perf-probe to setup the events.
If so, we can avoid redundant works on debuginfo. That is my point.

Thank you,

> - tracepoint programs are architecture independent, but if arbitrary pointer
>   walking (with fetch() helpers) is used, they need data struct layout to 
> match.
>   Debug info is not necessary
> - for networking use case we need to access 'struct sk_buff' fields in 
> portable
>   way (user space needs to fetch packet length without knowing skb->len 
> offset),
>   so for some frequently used data structures we will add helper functions
>   or pseudo instructions to access them. I

Re: [PATCH 1/3] sound: dummy, use setup_timer and mod_timer

[Takashi Iwai]

At Mon, 19 Jan 2015 10:42:54 +0100,
Jiri Slaby wrote:
> 
> From: Roman Kollar 
> 
> Use setup_timer and mod_timer instead of structure assignments as it
> is the preferred way to setup and set the timer.
> 
> Signed-off-by: Roman Kollar 
> Signed-off-by: Jiri Slaby 
> Cc: Jaroslav Kysela 
> Cc: Takashi Iwai 
> Cc: alsa-de...@alsa-project.org

Applied this one, thanks.


Takashi

> ---
>  sound/drivers/dummy.c | 10 --
>  1 file changed, 4 insertions(+), 6 deletions(-)
> 
> diff --git a/sound/drivers/dummy.c b/sound/drivers/dummy.c
> index 5d0dfb787cec..d11baaf0f0b4 100644
> --- a/sound/drivers/dummy.c
> +++ b/sound/drivers/dummy.c
> @@ -245,9 +245,8 @@ struct dummy_systimer_pcm {
>  
>  static void dummy_systimer_rearm(struct dummy_systimer_pcm *dpcm)
>  {
> - dpcm->timer.expires = jiffies +
> - (dpcm->frac_period_rest + dpcm->rate - 1) / dpcm->rate;
> - add_timer(&dpcm->timer);
> + mod_timer(&dpcm->timer, jiffies +
> + (dpcm->frac_period_rest + dpcm->rate - 1) / dpcm->rate);
>  }
>  
>  static void dummy_systimer_update(struct dummy_systimer_pcm *dpcm)
> @@ -340,9 +339,8 @@ static int dummy_systimer_create(struct snd_pcm_substream 
> *substream)
>   if (!dpcm)
>   return -ENOMEM;
>   substream->runtime->private_data = dpcm;
> - init_timer(&dpcm->timer);
> - dpcm->timer.data = (unsigned long) dpcm;
> - dpcm->timer.function = dummy_systimer_callback;
> + setup_timer(&dpcm->timer, dummy_systimer_callback,
> + (unsigned long) dpcm);
>   spin_lock_init(&dpcm->lock);
>   dpcm->substream = substream;
>   return 0;
> -- 
> 2.2.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 2/3] sound: dummy, use del_timer_sync

[Takashi Iwai]

At Mon, 19 Jan 2015 10:42:55 +0100,
Jiri Slaby wrote:
> 
> Wait for the timer to really quit, not only by ensuring it is not in
> the critical section.
> 
> BTW the spin_lock in here does not disable BH, so that it could
> deadlock.

The stop function is called from the PCM trigger callback which is
irq-disabled.  So, you can't use del_timer_sync() here.


thanks,

Takashi

> 
> Signed-off-by: Jiri Slaby 
> Cc: Jaroslav Kysela 
> Cc: Takashi Iwai 
> Cc: alsa-de...@alsa-project.org
> ---
>  sound/drivers/dummy.c | 6 +++---
>  1 file changed, 3 insertions(+), 3 deletions(-)
> 
> diff --git a/sound/drivers/dummy.c b/sound/drivers/dummy.c
> index d11baaf0f0b4..6d6bf4093583 100644
> --- a/sound/drivers/dummy.c
> +++ b/sound/drivers/dummy.c
> @@ -281,9 +281,9 @@ static int dummy_systimer_start(struct snd_pcm_substream 
> *substream)
>  static int dummy_systimer_stop(struct snd_pcm_substream *substream)
>  {
>   struct dummy_systimer_pcm *dpcm = substream->runtime->private_data;
> - spin_lock(&dpcm->lock);
> - del_timer(&dpcm->timer);
> - spin_unlock(&dpcm->lock);
> +
> + del_timer_sync(&dpcm->timer);
> +
>   return 0;
>  }
>  
> -- 
> 2.2.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 v4] virtio-scsi: Fix the race condition in virtscsi_handle_event

[Christoph Hellwig]

Michael,

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

Re: [PATCH 3/3] sound: dummy, avoid races with timer

[Jiri Slaby]

On 01/19/2015, 10:49 AM, Takashi Iwai wrote:
>> @@ -322,12 +325,14 @@ static snd_pcm_uframes_t
>>  dummy_systimer_pointer(struct snd_pcm_substream *substream)
>>  {
>>  struct dummy_systimer_pcm *dpcm = substream->runtime->private_data;
>> +unsigned long flags;
>>  snd_pcm_uframes_t pos;
>>  
>> -spin_lock(&dpcm->lock);
>> +spin_lock_irqsave(&dpcm->lock, flags);
>>  dummy_systimer_update(dpcm);
>>  pos = dpcm->frac_pos / HZ;
>> -spin_unlock(&dpcm->lock);
>> +spin_unlock_irqrestore(&dpcm->lock, flags);
>> +
> 
> This chunk is superfluous.  The pointer callback is guaranteed to be
> called in the irq-disabled context.

Oh, my bad, I was looking at snd_compr_ops->pointer which is not the case.

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

Re: [PATCH V1] mfd: da9063: Add device tree support

[Lee Jones]

On Wed, 14 Jan 2015, Steve Twiss wrote:

> From: Steve Twiss 
> 
> Add device tree support for DA9063 regulators; Real-Time Clock
> and Watchdog.
> 
> 
> Signed-off-by: Steve Twiss 
> 
> ---
> Checks performed with linux-next/v3.19-rc4/scripts/checkpatch.pl
>  da9063.txttotal: 0 errors, 0 warnings, 94 lines checked
>  da9063-core.c total: 0 errors, 0 warnings, 192 lines checked
>  da9063-i2c.c  total: 0 errors, 0 warnings, 277 lines checked
>  core.htotal: 0 errors, 0 warnings, 99 lines checked

There is no need to put this in here really.  It is assumed that
checkpatch.pl has been run and that no warnings/errors exists.

> This patch applies against linux-next and v3.19-rc4 
> 
> 
> 
>  Documentation/devicetree/bindings/mfd/da9063.txt | 94 
> 
>  drivers/mfd/da9063-core.c|  2 +
>  drivers/mfd/da9063-i2c.c | 11 +++
>  include/linux/mfd/da9063/core.h  |  1 +
>  4 files changed, 108 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/mfd/da9063.txt
> 
> diff --git a/Documentation/devicetree/bindings/mfd/da9063.txt 
> b/Documentation/devicetree/bindings/mfd/da9063.txt
> new file mode 100644
> index 000..ac26af4
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/mfd/da9063.txt
> @@ -0,0 +1,94 @@
> +* Dialog DA9063 Power Management Integrated Circuit (PMIC)
> +
> +DA9093 consists of a large and varied group of sub-devices (I2C Only):
> +
> +Device   Supply NamesDescription
> +--   ---
> +da9063-regulator:   : LDOs & BUCKs
> +da9063-rtc  :   : Real-Time Clock
> +da9063-watchdog :   : Watchdog
> +
> +==
> +
> +Required properties:
> +
> +- compatible : Should be "dlg,da9063-ca", "dlg,da9063-bb" or/and
> +  "dlg,da9063-ad".

What are 'ca', 'bb' and 'ad'?

> +- reg : Specifies the I2C slave address (this defaults to 0x58 but it can be
> +  modified to match the chip's OTP settings).
> +- interrupt-parent : Specifies the reference to the interrupt controller for
> +  the DA9063.
> +- interrupts : IRQ line information.
> +- interrupt-controller
> +
> +Sub-nodes:
> +
> +- regulators : This node defines the settings for the LDOs and BUCKs. The
> +  DA9063 regulators are bound using their names listed below:
> +
> +bcore1: BUCK CORE1
> +bcore2: BUCK CORE2
> +bpro  : BUCK PRO
> +bmem  : BUCK MEM
> +bio   : BUCK IO
> +bperi : BUCK PERI
> +ldo1  : LDO_1
> +ldo2  : LDO_2
> +ldo3  : LDO_3
> +ldo4  : LDO_4
> +ldo5  : LDO_5
> +ldo6  : LDO_6
> +ldo7  : LDO_7
> +ldo8  : LDO_8
> +ldo9  : LDO_9
> +ldo10 : LDO_10
> +ldo11 : LDO_11
> +
> +  The component follows the standard regulator framework and the bindings
> +  details of individual regulator device can be found in:
> +  Documentation/devicetree/bindings/regulator/regulator.txt
> +
> +- rtc : This node defines settings for the Real-Time Clock associated with
> +  the DA9063. There are currently no entries in this binding, however
> +  compatible = "dlg,da9063-rtc" should be added if a node is created.
> +
> +- watchdog : This node defines settings for the Watchdog timer associated
> +  with the DA9063. There are currently no entries in this binding, however
> +  compatible = "dlg,da9063-watchdog" should be added if a node is created.
> +
> +
> +Example:
> +
> + pmic0: da9063@58 {
> + compatible = "dlg,da9063-ca", "dlg,da9063-bb", "dlg,da9063-ad";
> + reg = <0x58>;
> + interrupt-parent = <&gpio6>;
> + interrupts = <11 IRQ_TYPE_LEVEL_LOW>;
> + interrupt-controller;
> +
> + rtc {
> + compatible = "dlg,da9063-rtc";
> + };
> +
> + wdt {
> + compatible = "dlg,da9063-watchdog";
> + };
> +
> + regulators {
> + DA9063_BCORE1: bcore1 {
> + regulator-name = "BCORE1";
> + regulator-min-microvolt = <30>;
> + regulator-max-microvolt = <157>;
> + regulator-min-microamp = <50>;
> + regulator-max-microamp = <200>;
> + regulator-boot-on;
> + };
> + DA9063_LDO11: ldo11 {
> + regulator-name = "LDO_11";
> + regulator-min-microvolt = <90>;
> + regulator-max-microvolt = <360>;
> + regulator-boot-on;
> + };
> + };
> + };
> +
> diff --git a/drivers/mfd/da9063-core.c b/drivers/mfd/da9063-core.c
> index f38bc98..17

Re: [PATCH v5 5/5] tty/serial: Add Spreadtrum sc9836-uart driver support

[Lyra Zhang]

On Sat, Jan 17, 2015 at 12:41 AM, Rob Herring  wrote:
> On Fri, Jan 16, 2015 at 4:00 AM, Chunyan Zhang
>  wrote:
>> Add a full sc9836-uart driver for SC9836 SoC which is based on the
>> spreadtrum sharkl64 platform.
>> This driver also support earlycon.
>> This patch also replaced the spaces between the macros and their
>> values with the tabs in serial_core.h
>>
>> Signed-off-by: Chunyan Zhang 
>> Signed-off-by: Orson Zhai 
>> Originally-by: Lanqing Liu 
>> ---
>>  drivers/tty/serial/Kconfig   |   18 +
>>  drivers/tty/serial/Makefile  |1 +
>>  drivers/tty/serial/sprd_serial.c |  772 
>> ++
>>  include/uapi/linux/serial_core.h |3 +
>>  4 files changed, 794 insertions(+)
>>  create mode 100644 drivers/tty/serial/sprd_serial.c
>>
>> diff --git a/drivers/tty/serial/Kconfig b/drivers/tty/serial/Kconfig
>> index c79b43c..969d3cd 100644
>> --- a/drivers/tty/serial/Kconfig
>> +++ b/drivers/tty/serial/Kconfig
>> @@ -1577,6 +1577,24 @@ config SERIAL_MEN_Z135
>>   This driver can also be build as a module. If so, the module will 
>> be called
>>   men_z135_uart.ko
>>
>> +config SERIAL_SPRD
>> +   tristate "Support for SPRD serial"
>
> Can the menu text spell out Spreadtrum. What SPRD means is not obvious.
>

Ok, I'll address it.

>> +   depends on ARCH_SPRD
>> +   select SERIAL_CORE
>> +   help
>> + This enables the driver for the Spreadtrum's serial.
>> +
>> +config SERIAL_SPRD_CONSOLE
>> +   bool "SPRD UART console support"
>
> Same here.
>
>> +   depends on SERIAL_SPRD=y
>> +   select SERIAL_CORE_CONSOLE
>> +   select SERIAL_EARLYCON
>> +   help
>> + Support for early debug console using Spreadtrum's serial. This 
>> enables
>> + the console before standard serial driver is probed. This is 
>> enabled
>> + with "earlycon" on the kernel command line. The console is
>> + enabled when early_param is processed.
>> +
>>  endmenu
>>
>>  config SERIAL_MCTRL_GPIO
>> diff --git a/drivers/tty/serial/Makefile b/drivers/tty/serial/Makefile
>> index 9a548ac..4801aca 100644
>> --- a/drivers/tty/serial/Makefile
>> +++ b/drivers/tty/serial/Makefile
>> @@ -93,6 +93,7 @@ obj-$(CONFIG_SERIAL_ARC)  += arc_uart.o
>>  obj-$(CONFIG_SERIAL_RP2)   += rp2.o
>>  obj-$(CONFIG_SERIAL_FSL_LPUART)+= fsl_lpuart.o
>>  obj-$(CONFIG_SERIAL_MEN_Z135)  += men_z135_uart.o
>> +obj-$(CONFIG_SERIAL_SPRD) += sprd_serial.o
>>
>>  # GPIOLIB helpers for modem control lines
>>  obj-$(CONFIG_SERIAL_MCTRL_GPIO)+= serial_mctrl_gpio.o
>> diff --git a/drivers/tty/serial/sprd_serial.c 
>> b/drivers/tty/serial/sprd_serial.c
>> new file mode 100644
>> index 000..81839e4
>> --- /dev/null
>> +++ b/drivers/tty/serial/sprd_serial.c
>> @@ -0,0 +1,772 @@
>> +/*
>> + * Copyright (C) 2012 Spreadtrum Communications Inc.
>
> This is unchanged in 3 years?
>

ok, I'll change it to 2012-2015.

>> + *
>> + * This software is licensed under the terms of the GNU General Public
>> + * License version 2, as published by the Free Software Foundation, and
>> + * may be copied, distributed, and modified under those terms.
>> + *
>> + * 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.
>> + */
>> +
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +
>> +/* device name */
>> +#define UART_NR_MAX8
>> +#define SPRD_TTY_NAME  "ttySPX"
>
> We really want to get away from per SOC serial names and use ttyS for
> serial port /dev names. There's issues switching existing drivers
> because this creates an ABI, so we can only have new drivers follow
> this.
>

ok. i see. I'll convert it to ttyS in the next version.

> [...]
>
>> +static struct platform_driver sprd_platform_driver = {
>> +   .probe  = sprd_probe,
>> +   .remove = sprd_remove,
>> +   .driver = {
>> +   .name   = "sprd_serial",
>> +   .of_match_table = of_match_ptr(serial_ids),
>> +   .pm = &sprd_pm_ops,
>> +   },
>> +};
>> +
>> +static int __init sprd_serial_init(void)
>> +{
>> +   int ret = 0;
>> +
>> +   ret = uart_register_driver(&sprd_uart_driver);
>
> This can be done in probe now. Then you can use module_platform_driver().
>

Question:
1. there are 4 uart ports configured in dt for sprd_serial, so probe
will be called 4 times, but uart_register_driver only needs to be
called one time, so can we use uart_driver.state to check if
uart_register_driver has already been called ?

2. if I use module_platform_driver() instead of
module_init(sprd_serial_init)  and  module_exit(sprd_serial_exit) , I
must move uart_

Re: [PATCH] mfd: db8500-prcmu: Remove unused function

[Lee Jones]

On Thu, 01 Jan 2015, Rickard Strandqvist wrote:

> Remove the function prcmu_get_boot_status() that is not used anywhere.
> 
> This was partially found by using a static code analysis program called 
> cppcheck.
> 
> Signed-off-by: Rickard Strandqvist 
> ---
>  drivers/mfd/db8500-prcmu.c |9 -
>  1 file changed, 9 deletions(-)

Applied, thanks.

> diff --git a/drivers/mfd/db8500-prcmu.c b/drivers/mfd/db8500-prcmu.c
> index 193cf16..b517501 100644
> --- a/drivers/mfd/db8500-prcmu.c
> +++ b/drivers/mfd/db8500-prcmu.c
> @@ -675,15 +675,6 @@ bool prcmu_has_arm_maxopp(void)
>  }
>  
>  /**
> - * prcmu_get_boot_status - PRCMU boot status checking
> - * Returns: the current PRCMU boot status
> - */
> -int prcmu_get_boot_status(void)
> -{
> - return readb(tcdm_base + PRCM_BOOT_STATUS);
> -}
> -
> -/**
>   * prcmu_set_rc_a2p - This function is used to run few power state sequences
>   * @val: Value to be set, i.e. transition requested
>   * Returns: 0 on success, -EINVAL on invalid argument

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

Re: [PATCH RESEND v8 1/2] clk: Make clk API return per-user struct clk instances

[Tomeu Vizoso]

On 17 January 2015 at 02:02, Stephen Boyd  wrote:
> On 01/12, Tomeu Vizoso wrote:
>> Moves clock state to struct clk_core, but takes care to change as little API 
>> as
>> possible.
>>
>> struct clk_hw still has a pointer to a struct clk, which is the
>> implementation's per-user clk instance, for backwards compatibility.
>>
>> The struct clk that clk_get_parent() returns isn't owned by the caller, but 
>> by
>> the clock implementation, so the former shouldn't call clk_put() on it.
>>
>> Because some boards in mach-omap2 still register clocks statically, their 
>> clock
>> registration had to be updated to take into account that the clock 
>> information
>> is stored in struct clk_core now.
>>
>> Signed-off-by: Tomeu Vizoso 
>>
>
> Looks mostly good. Missing some NULL checks mostly.

Sorry about that, I should have been more careful there.

>> diff --git a/drivers/clk/clk.c b/drivers/clk/clk.c
>> index f4963b7..7eddfd8 100644
>> --- a/drivers/clk/clk.c
>> +++ b/drivers/clk/clk.c
>> @@ -114,7 +123,7 @@ static struct hlist_head *orphan_list[] = {
>> +static void clk_summary_show_one(struct seq_file *s, struct clk_core *c, 
>> int level)
>>  {
>>   if (!c)
>>   return;
>> @@ -122,14 +131,14 @@ static void clk_summary_show_one(struct seq_file *s, 
>> struct clk *c, int level)
> [...]
>> -static void clk_summary_show_subtree(struct seq_file *s, struct clk *c,
>> +static void clk_summary_show_subtree(struct seq_file *s, struct clk_core *c,
>>int level)
>>  {
>> - struct clk *child;
>> + struct clk_core *child;
>>
>>   if (!c)
>>   return;
>> @@ -172,7 +181,7 @@ static const struct file_operations clk_summary_fops = {
>>   .release= single_release,
>>  };
>>
>> -static void clk_dump_one(struct seq_file *s, struct clk *c, int level)
>> +static void clk_dump_one(struct seq_file *s, struct clk_core *c, int level)
>>  {
>>   if (!c)
>>   return;
>> @@ -180,14 +189,14 @@ static void clk_dump_one(struct seq_file *s, struct 
>> clk *c, int level)
> [...]
>> -static void clk_dump_subtree(struct seq_file *s, struct clk *c, int level)
>> +static void clk_dump_subtree(struct seq_file *s, struct clk_core *c, int 
>> level)
>>  {
>> - struct clk *child;
>> + struct clk_core *child;
>>
>>   if (!c)
>>   return;
>> @@ -418,19 +427,20 @@ static int __init clk_debug_init(void)
> [...]
>>
>>  /* caller must hold prepare_lock */
>> -static void clk_unprepare_unused_subtree(struct clk *clk)
>> +static void clk_unprepare_unused_subtree(struct clk_core *clk)
>>  {
>> - struct clk *child;
>> + struct clk_core *child;
>>
>>   if (!clk)
>>   return;
>> @@ -453,9 +463,9 @@ static void clk_unprepare_unused_subtree(struct clk *clk)
>>  }
>>
>>  /* caller must hold prepare_lock */
>> -static void clk_disable_unused_subtree(struct clk *clk)
>> +static void clk_disable_unused_subtree(struct clk_core *clk)
>>  {
>> - struct clk *child;
>> + struct clk_core *child;
>>   unsigned long flags;
>>
>>   if (!clk)
>
> Note: These NULL checks look bogus. No need to fix them here, but
> a patch to remove them would be nice.

Indeed.

>> @@ -532,48 +542,59 @@ late_initcall_sync(clk_disable_unused);
> [...]
>> +
>> +struct clk *clk_get_parent_by_index(struct clk *clk, u8 index)
>> +{
>> + struct clk_core *parent;
>> +
>> + parent = clk_core_get_parent_by_index(clk->core, index);
>
> I suppose clk could be NULL here (although this is mostly a
> clk-provider function). At least before we would return NULL in
> such a case so we should keep the same behavior instead of NULL
> deref.

Agreed.

>> +
>> + return !parent ? NULL : parent->hw->clk;
>> +}
>>  EXPORT_SYMBOL_GPL(clk_get_parent_by_index);
>>
>> @@ -593,9 +614,14 @@ unsigned long __clk_get_rate(struct clk *clk)
>>  out:
>>   return ret;
>>  }
>> +
>> +unsigned long __clk_get_rate(struct clk *clk)
>> +{
>> + return clk_core_get_rate_nolock(clk->core);
>
> Oops. clk can be NULL here. We should check for that and return
> 0.

Agreed.

>> +}
>>  EXPORT_SYMBOL_GPL(__clk_get_rate);
>>
>> @@ -630,7 +656,12 @@ out:
>>   return !!ret;
>>  }
>>
>> -bool __clk_is_enabled(struct clk *clk)
>> +bool __clk_is_prepared(struct clk *clk)
>> +{
>> + return clk_core_is_prepared(clk->core);
>
> Oops. clk can be NULL here. Return false if so. Or drop the
> function entirely? It looks like it may become unused.

Are you thinking of anything specific that the alchemy arch can do
instead of calling __clk_is_prepared?

>> +}
>> @@ -650,12 +681,17 @@ bool __clk_is_enabled(struct clk *clk)
>>  out:
>>   return !!ret;
>>  }
>> +
>> +bool __clk_is_enabled(struct clk *clk)
>> +{
>> + return clk_core_is_enabled(clk->core);
>
> Oops. clk can be NULL here. Return false if so.

Agreed.

>> +}
>>  EXPORT_SYMBOL_GPL(__clk_is_enabled);
>>
>> @@ -762,7 +805,12 @@ void __clk_unprepare(struct clk *clk)
>>   if (clk->ops->unprepare)
>>   

[PATCH v2 2/2] sound: dummy, avoid race with timer

[Jiri Slaby]

There is a race between timer and process contexts. Process context
does not disable irqs, so when a timer ticks inside process' critical
section, the system can deadlock. Fix this by a traditional _irqsave
variant of spin_lock.

[v2] removed ->pointer change as it is called with BH off

Signed-off-by: Jiri Slaby 
Cc: Jaroslav Kysela 
Cc: Takashi Iwai 
Cc: alsa-de...@alsa-project.org
---
 sound/drivers/dummy.c | 7 +--
 1 file changed, 5 insertions(+), 2 deletions(-)

diff --git a/sound/drivers/dummy.c b/sound/drivers/dummy.c
index d11baaf0f0b4..0791210cb4e7 100644
--- a/sound/drivers/dummy.c
+++ b/sound/drivers/dummy.c
@@ -271,10 +271,13 @@ static void dummy_systimer_update(struct 
dummy_systimer_pcm *dpcm)
 static int dummy_systimer_start(struct snd_pcm_substream *substream)
 {
struct dummy_systimer_pcm *dpcm = substream->runtime->private_data;
-   spin_lock(&dpcm->lock);
+   unsigned long flags;
+
+   spin_lock_irqsave(&dpcm->lock, flags);
dpcm->base_time = jiffies;
dummy_systimer_rearm(dpcm);
-   spin_unlock(&dpcm->lock);
+   spin_unlock_irqrestore(&dpcm->lock, flags);
+
return 0;
 }
 
-- 
2.2.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 V1] mfd: da9063: Add device tree support

[Lee Jones]

On Wed, 14 Jan 2015, Steve Twiss wrote:

> From: Steve Twiss 
> 
> Add device tree support for DA9063 regulators; Real-Time Clock
> and Watchdog.
> 
> 
> Signed-off-by: Steve Twiss 
> 
> ---
> Checks performed with linux-next/v3.19-rc4/scripts/checkpatch.pl
>  da9063.txttotal: 0 errors, 0 warnings, 94 lines checked
>  da9063-core.c total: 0 errors, 0 warnings, 192 lines checked
>  da9063-i2c.c  total: 0 errors, 0 warnings, 277 lines checked
>  core.htotal: 0 errors, 0 warnings, 99 lines checked
> This patch applies against linux-next and v3.19-rc4 
> 
> 
> 
>  Documentation/devicetree/bindings/mfd/da9063.txt | 94 
> 

Ah, and this should be in a separate patch.

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

[PATCH] clk: Fix debugfs clk removal before inited

[Srinivas Kandagatla]

Some of the clks can be registered & unregistered before the clk related debugfs
entries are initialized at late_initcall. In the unregister path checking for 
only
dentry before clk_debug_init() would lead dangling pointers in the debug clk 
list,
because the list is already populated in register path and the clk pointer 
freed in
unregister path.
The side effect of not removing it from the list is either a null pointer
dereference or if lucky to boot the system, the number of clk entries in
debugfs disappear.

We could add more checks like if (inited && !clk->dentry) but just removing
the check for dentry made more sense as debugfs_remove_recursive() seems to be
safe with null pointers. This will ensure that the unregistering clk would be
removed from the debug list in all the code paths.

Without this patch kernel would crash with log:
Unable to handle kernel NULL pointer dereference at virtual address 
pgd = c0204000
[] *pgd=
Internal error: Oops: 5 [#1] SMP ARM
Modules linked in:
CPU: 1 PID: 1 Comm: swapper/0 Tainted: GB  
3.19.0-rc3-7-g412f9ba-dirty #840
Hardware name: Qualcomm (Flattened Device Tree)
task: ed948000 ti: ed944000 task.ti: ed944000
PC is at strlen+0xc/0x40
LR is at __create_file+0x64/0x1dc
pc : []lr : []psr: 6013
sp : ed945e40  ip : ed945e50  fp : ed945e4c
r10:   r9 : c1006094  r8 : 
r7 : 41ed  r6 :   r5 : ed4af998  r4 : c11b5e28
r3 :   r2 : ed945e38  r1 : a013  r0 : 
Flags: nZCv  IRQs on  FIQs on  Mode SVC_32  ISA ARM  Segment kernel
Control: 10c5787d  Table: 8020406a  DAC: 0015
Process swapper/0 (pid: 1, stack limit = 0xed944248)
Stack: (0xed945e40 to 0xed946000)
5e40: ed945e7c ed945e50 c049f1c4 c04ee604 c0fc2fa4  ecb748c0 c11c2b80
5e60: c0beec04 011c c0fc2fa4  ed945e94 ed945e80 c049f3e0 c049f16c
5e80:   ed945eac ed945e98 c08cbc50 c049f3c0 ecb748c0 c11c2b80
5ea0: ed945ed4 ed945eb0 c0fc3080 c08cbc30 c0beec04 c107e1d8 ecdf0600 c107e1d8
5ec0: c107e1d8 ecdf0600 ed945f54 ed945ed8 c0208ed4 c0fc2fb0 c026a784 c04ee628
5ee0: ed945f0c ed945ef0 c0f5d600 c04ee604 c0f5d5ec ef7fcc7d c0b40ecc 011c
5f00: ed945f54 ed945f10 c026a994 c0f5d5f8 c04ecc00 0007 ef7fcc95 0007
5f20: c0e90744 c0dd0884 ed945f54 c106cde0 0007 c117f8c0 011c c0f5d5ec
5f40: c1006094 c100609c ed945f94 ed945f58 c0f5de34 c0208e50 0007 0007
5f60: c0f5d5ec be9b5ae0  c117f8c0 c0af1680   
5f80:   ed945fac ed945f98 c0af169c c0f5dd2c ed944000 
5fa0:  ed945fb0 c020f298 c0af168c    
5fc0:        
5fe0:     0013  ebcc6d33 bfffca73
[] (strlen) from [] (__create_file+0x64/0x1dc)
[] (__create_file) from [] (debugfs_create_dir+0x2c/0x34)
[] (debugfs_create_dir) from [] 
(clk_debug_create_one+0x2c/0x16c)
[] (clk_debug_create_one) from [] 
(clk_debug_init+0xdc/0x144)
[] (clk_debug_init) from [] (do_one_initcall+0x90/0x1e0)
[] (do_one_initcall) from [] 
(kernel_init_freeable+0x114/0x1e0)
[] (kernel_init_freeable) from [] (kernel_init+0x1c/0xfc)
[] (kernel_init) from [] (ret_from_fork+0x14/0x3c)
Code: c0b40ecc e1a0c00d e92dd800 e24cb004 (e5d02000)
---[ end trace b940e45b5e25c1e7 ]---

Signed-off-by: Srinivas Kandagatla 
---
 drivers/clk/clk.c | 4 
 1 file changed, 4 deletions(-)

diff --git a/drivers/clk/clk.c b/drivers/clk/clk.c
index f4963b7..e310691 100644
--- a/drivers/clk/clk.c
+++ b/drivers/clk/clk.c
@@ -343,13 +343,9 @@ unlock:
 static void clk_debug_unregister(struct clk *clk)
 {
mutex_lock(&clk_debug_lock);
-   if (!clk->dentry)
-   goto out;
-
hlist_del_init(&clk->debug_node);
debugfs_remove_recursive(clk->dentry);
clk->dentry = NULL;
-out:
mutex_unlock(&clk_debug_lock);
 }
 
-- 
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 2/3] sound: dummy, use del_timer_sync

[Jiri Slaby]

On 01/19/2015, 10:52 AM, Takashi Iwai wrote:
> At Mon, 19 Jan 2015 10:42:55 +0100,
> Jiri Slaby wrote:
>>
>> Wait for the timer to really quit, not only by ensuring it is not in
>> the critical section.
>>
>> BTW the spin_lock in here does not disable BH, so that it could
>> deadlock.
> 
> The stop function is called from the PCM trigger callback which is
> irq-disabled.  So, you can't use del_timer_sync() here.

The same as 3/3 I was looking at compr* :(. Ignore this one, then.

thanks,
-- 
js
suse labs
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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/2] sound: dummy, avoid race with timer

[Takashi Iwai]

At Mon, 19 Jan 2015 10:56:41 +0100,
Jiri Slaby wrote:
> 
> There is a race between timer and process contexts. Process context
> does not disable irqs, so when a timer ticks inside process' critical
> section, the system can deadlock. Fix this by a traditional _irqsave
> variant of spin_lock.
> 
> [v2] removed ->pointer change as it is called with BH off

Sorry, my previous comment was incorrect.  The start function here is
also called from PCM trigger callback that is already irq-disabled.
So, this is also superfluous.


thanks,

Takashi

> 
> Signed-off-by: Jiri Slaby 
> Cc: Jaroslav Kysela 
> Cc: Takashi Iwai 
> Cc: alsa-de...@alsa-project.org
> ---
>  sound/drivers/dummy.c | 7 +--
>  1 file changed, 5 insertions(+), 2 deletions(-)
> 
> diff --git a/sound/drivers/dummy.c b/sound/drivers/dummy.c
> index d11baaf0f0b4..0791210cb4e7 100644
> --- a/sound/drivers/dummy.c
> +++ b/sound/drivers/dummy.c
> @@ -271,10 +271,13 @@ static void dummy_systimer_update(struct 
> dummy_systimer_pcm *dpcm)
>  static int dummy_systimer_start(struct snd_pcm_substream *substream)
>  {
>   struct dummy_systimer_pcm *dpcm = substream->runtime->private_data;
> - spin_lock(&dpcm->lock);
> + unsigned long flags;
> +
> + spin_lock_irqsave(&dpcm->lock, flags);
>   dpcm->base_time = jiffies;
>   dummy_systimer_rearm(dpcm);
> - spin_unlock(&dpcm->lock);
> + spin_unlock_irqrestore(&dpcm->lock, flags);
> +
>   return 0;
>  }
>  
> -- 
> 2.2.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: [PATCHv8 7/9] ARM: dts: Add PPMU dt node for Exynos5260 SoC

[Chanwoo Choi]

Dear all,

I'll drop this patch because I can't test it on Exynos5260-based board.

Best Regards,
Chanwoo Choi

On 01/12/2015 09:34 PM, Chanwoo Choi wrote:
> This patch adds PPMU (Performance Profiling Monitoring Unit) dt node
> Exynos5260 SoC.
> 
> Exynos5260 SoC has following PPMU IPs:
> - PPMU_DREX0_S0 0x10c6
> - PPMU_DREX0_S1 0x10c7
> - PPMU_DREX1_S0 0x10c8
> - PPMU_DREX1_S1 0x10c9
> - PPMU_EAGLE0x10cc
> - PPMU_KFC  0x10cd
> - PPMU_MFC  0x1104
> - PPMU_G3D  0x1188
> - PPMU_FSYS 0x1222
> - PPMU_ISP  0x1337
> - PPMU_FICM 0x13cb
> - PPMU_GSCL 0x13e6
> - PPMU_MSCL 0x13ee
> - PPMU_FIMD0X   0x145b
> - PPMU_FIMD1X   0x145c
> 
> The drivers/devfreq/exynos/exynos5_bus.c supports the memory bus frequency/
> voltage scaling of Exynos5260 SoC with DEVFREQ framework.
> 
> Cc: Kukjin Kim 
> Cc: Abhilash Kesavan 
> Cc: Jonghwan Choi 
> Signed-off-by: Chanwoo Choi 
> ---
>  arch/arm/boot/dts/exynos5260.dtsi | 90 
> +++
>  1 file changed, 90 insertions(+)
> 
> diff --git a/arch/arm/boot/dts/exynos5260.dtsi 
> b/arch/arm/boot/dts/exynos5260.dtsi
> index 36da38e..26f3074 100644
> --- a/arch/arm/boot/dts/exynos5260.dtsi
> +++ b/arch/arm/boot/dts/exynos5260.dtsi
> @@ -307,6 +307,96 @@
>   fifo-depth = <64>;
>   status = "disabled";
>   };
> +
> + ppmu_drex0_s0: ppmu_drex0_s0@10c6 {
> + compatible = "samsung,exynos-ppmu";
> + reg = <0x10c6 0x2000>;
> + status = "disabled";
> + };
> +
> + ppmu_drex0_s1: ppmu_drex0_s1@10c7 {
> + compatible = "samsung,exynos-ppmu";
> + reg = <0x10c7 0x2000>;
> + status = "disabled";
> + };
> +
> + ppmu_drex1_s0: ppmu_drex1_s0@10c8 {
> + compatible = "samsung,exynos-ppmu";
> + reg = <0x10c8 0x2000>;
> + status = "disabled";
> + };
> +
> + ppmu_drex1_s1: ppmu_drex1_s1@10c9 {
> + compatible = "samsung,exynos-ppmu";
> + reg = <0x10c9 0x2000>;
> + status = "disabled";
> + };
> +
> + ppmu_eagle: ppmu_eagle@10cc {
> + compatible = "samsung,exynos-ppmu";
> + reg = <0x10cc 0x2000>;
> + status = "disabled";
> + };
> +
> + ppmu_kfc: ppmu_kfc@10cd {
> + compatible = "samsung,exynos-ppmu";
> + reg = <0x10cd 0x2000>;
> + status = "disabled";
> + };
> +
> + ppmu_mfc: ppmu_mfc@1104 {
> + compatible = "samsung,exynos-ppmu";
> + reg = <0x1104 0x2000>;
> + status = "disabled";
> + };
> +
> + ppmu_g3d: ppmu_g3d@1188 {
> + compatible = "samsung,exynos-ppmu";
> + reg = <0x1188 0x2000>;
> + status = "disabled";
> + };
> +
> + ppmu_fsys: ppmu_fsys@1222 {
> + compatible = "samsung,exynos-ppmu";
> + reg = <0x1222 0x2000>;
> + status = "disabled";
> + };
> +
> + ppmu_isp: ppmu_isp@1337 {
> + compatible = "samsung,exynos-ppmu";
> + reg = <0x1337 0x2000>;
> + status = "disabled";
> + };
> +
> + ppmu_fimc: ppmu_fimc@13cb {
> + compatible = "samsung,exynos-ppmu";
> + reg = <0x13cb 0x2000>;
> + status = "disabled";
> + };
> +
> + ppmu_gscl: ppmu_gscl@13e6 {
> + compatible = "samsung,exynos-ppmu";
> + reg = <0x13e6 0x2000>;
> + status = "disabled";
> + };
> +
> + ppmu_mscl: ppmu_gscl@13ee {
> + compatible = "samsung,exynos-ppmu";
> + reg = <0x13ee 0x2000>;
> + status = "disabled";
> + };
> +
> + ppmu_fimd0x: ppmu_fimd0x@145b {
> + compatible = "samsung,exynos-ppmu";
> + reg = <0x145b 0x2000>;
> + status = "disabled";
> + };
> +
> + ppmu_fimd1x: ppmu_fimd1x@145c {
> + compatible = "samsung,exynos-ppmu";
> + reg = <0x145c 0x2000>;
> + status = "disabled";
> + };
>   };
>  };
>  
> 

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord

[PATCH 2/5] mm, compaction: simplify handling restart position in free pages scanner

[Vlastimil Babka]

Handling the position where compaction free scanner should restart (stored in
cc->free_pfn) got more complex with commit e14c720efdd7 ("mm, compaction:
remember position within pageblock in free pages scanner"). Currently the
position is updated in each loop iteration isolate_freepages(), although it's
enough to update it only when exiting the loop when we have found enough free
pages, or detected contention in async compaction. Then an extra check outside
the loop updates the position in case we have met the migration scanner.

This can be simplified if we move the test for having isolated enough from
for loop header next to the test for contention, and determining the restart
position only in these cases. We can reuse the isolate_start_pfn variable for
this instead of setting cc->free_pfn directly. Outside the loop, we can simply
set cc->free_pfn to value of isolate_start_pfn without extra check.

We also add VM_BUG_ON to future-proof the code, in case somebody adds a new
condition that terminates isolate_freepages_block() prematurely, which
wouldn't be also considered in isolate_freepages().

Signed-off-by: Vlastimil Babka 
Cc: Minchan Kim 
Cc: Mel Gorman 
Cc: Joonsoo Kim 
Cc: Michal Nazarewicz 
Cc: Naoya Horiguchi 
Cc: Christoph Lameter 
Cc: Rik van Riel 
Cc: David Rientjes 
---
 mm/compaction.c | 34 +++---
 1 file changed, 19 insertions(+), 15 deletions(-)

diff --git a/mm/compaction.c b/mm/compaction.c
index 5fdbdb8..45799a4 100644
--- a/mm/compaction.c
+++ b/mm/compaction.c
@@ -849,7 +849,7 @@ static void isolate_freepages(struct compact_control *cc)
 * pages on cc->migratepages. We stop searching if the migrate
 * and free page scanners meet or enough free pages are isolated.
 */
-   for (; block_start_pfn >= low_pfn && cc->nr_migratepages > nr_freepages;
+   for (; block_start_pfn >= low_pfn;
block_end_pfn = block_start_pfn,
block_start_pfn -= pageblock_nr_pages,
isolate_start_pfn = block_start_pfn) {
@@ -883,6 +883,8 @@ static void isolate_freepages(struct compact_control *cc)
nr_freepages += isolated;
 
/*
+* If we isolated enough freepages, or aborted due to async
+* compaction being contended, terminate the loop.
 * Remember where the free scanner should restart next time,
 * which is where isolate_freepages_block() left off.
 * But if it scanned the whole pageblock, isolate_start_pfn
@@ -891,28 +893,30 @@ static void isolate_freepages(struct compact_control *cc)
 * In that case we will however want to restart at the start
 * of the previous pageblock.
 */
-   cc->free_pfn = (isolate_start_pfn < block_end_pfn) ?
-   isolate_start_pfn :
-   block_start_pfn - pageblock_nr_pages;
-
-   /*
-* isolate_freepages_block() might have aborted due to async
-* compaction being contended
-*/
-   if (cc->contended)
+   if ((nr_freepages > cc->nr_migratepages) || cc->contended) {
+   if (isolate_start_pfn >= block_end_pfn)
+   isolate_start_pfn =
+   block_start_pfn - pageblock_nr_pages;
break;
+   } else {
+   /*
+* isolate_freepages_block() should not terminate
+* prematurely unless contended, or isolated enough
+*/
+   VM_BUG_ON(isolate_start_pfn < block_end_pfn);
+   }
}
 
/* split_free_page does not map the pages */
map_pages(freelist);
 
/*
-* If we crossed the migrate scanner, we want to keep it that way
-* so that compact_finished() may detect this
+* Record where the free scanner will restart next time. Either we
+* broke from the loop and set isolate_start_pfn based on the last
+* call to isolate_freepages_block(), or we met the migration scanner
+* and the loop terminated due to isolate_start_pfn < low_pfn
 */
-   if (block_start_pfn < low_pfn)
-   cc->free_pfn = cc->migrate_pfn;
-
+   cc->free_pfn = isolate_start_pfn;
cc->nr_freepages = nr_freepages;
 }
 
-- 
2.1.2

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

Re: [tip:core/types] bitops: Add sign_extend8(), 16 and 64 functions

[Peter Zijlstra]

On Mon, Jan 19, 2015 at 07:54:22AM +1200, Linus Torvalds wrote:
> Why?
> 
> The 8- and 16- bit versions are the same as the 32-bit one. This seems
> pointless. If you want something where the sign is in bit 3, they all
> return the same value, just the return type differs, but that's really a
> *caller* thing, no?

Even for the 8bit ones? Since we have the *H and *L register we have
more 8 bit regs than we have 16/32 bit regs and it might just be worth
it.

Since these are inlines the whole calling convention which would clobber
the whole of eax can go away.

Now granted, this is all very tenuous at best. A more convincing
argument might be that of documentation; calling sign_extend32() on
something you know to be a byte might be less intuitive.

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

[RFC PATCH 5/5] mm, compaction: set pivot pfn to the pfn when scanners met last time

[Vlastimil Babka]

The previous patch has prepared compaction scanners to start at arbitrary
pivot pfn within the zone, but left the pivot at the first pfn of the zone.
This patch introduces actual changing of the pivot pfn.

Our goal is to remove the bias in compaction under memory pressure, where
the migration scanner scans only the first half (or less) of the zone where
it cannot succeed anymore. At the same time we want to avoid frequent changes
of the pivot which would result in migrating pages back and forth without much
benefit. So the question is how often to change the pivot, and to which pfn
it should be set.

Another thing to consider is that the scanners mark pageblocks as unsuitable
for scanning via update_pageblock_skip(), which is a single bit per pageblock.
However, pageblock being unsuitable as a source of free pages is completely
different condition from pageblock being unsuitable as the source of
migratable pages. Thus, changing the pivot should be accompanied with
resetting the skip bits. The resetting is currently done either when kswapd
goes to sleep, or when compaction is being restarted from the longest possible
deferred compaction period.

Thus as a conservative first step, this patch does not increase the frequency
of skip bits resetting, and ties changing the pivot only to the situations
where compaction is restarted from being deferred. This happens when
compaction has failed a lot with the previous pivot, and most pageblocks were
already marked as unsuitable. Thus, most migrations occured relatively long
ago and we are not going to frequently migrate back and forth.

The pivot position is simply set to the pageblock where the scanners have met
during the last finished compaction. This means that migration scanner will
immediately scan pageblocks that it couldn't reach with the previous pivot.

Signed-off-by: Vlastimil Babka 
Cc: Minchan Kim 
Cc: Mel Gorman 
Cc: Joonsoo Kim 
Cc: Michal Nazarewicz 
Cc: Naoya Horiguchi 
Cc: Christoph Lameter 
Cc: Rik van Riel 
Cc: David Rientjes 
---
 include/linux/mmzone.h |  2 ++
 mm/compaction.c| 22 +-
 2 files changed, 19 insertions(+), 5 deletions(-)

diff --git a/include/linux/mmzone.h b/include/linux/mmzone.h
index 47aa181..7801886 100644
--- a/include/linux/mmzone.h
+++ b/include/linux/mmzone.h
@@ -505,6 +505,8 @@ struct zone {
 #if defined CONFIG_COMPACTION || defined CONFIG_CMA
/* pfn where compaction scanners have initially started last time */
unsigned long   compact_cached_pivot_pfn;
+   /* pfn where compaction scanners have met last time */
+   unsigned long   compact_cached_last_met_pfn;
/* pfn where compaction free scanner should start */
unsigned long   compact_cached_free_pfn;
/* pfn where async and sync compaction migration scanner should start */
diff --git a/mm/compaction.c b/mm/compaction.c
index abae89a..70792c5 100644
--- a/mm/compaction.c
+++ b/mm/compaction.c
@@ -125,10 +125,16 @@ static inline bool isolation_suitable(struct 
compact_control *cc,
 
 /*
  * Invalidate cached compaction scanner positions, so that compact_zone()
- * will reinitialize them on the next compaction.
+ * will reinitialize them on the next compaction. Optionally reset the
+ * initial pivot position for the scanners to the position where the scanners
+ * have met the last time.
  */
-static void reset_cached_positions(struct zone *zone)
+static void reset_cached_positions(struct zone *zone, bool update_pivot)
 {
+   if (update_pivot)
+   zone->compact_cached_pivot_pfn =
+   zone->compact_cached_last_met_pfn;
+
/* Invalid values are re-initialized in compact_zone */
zone->compact_cached_migrate_pfn[0] = 0;
zone->compact_cached_migrate_pfn[1] = 0;
@@ -1193,7 +1199,13 @@ static int compact_finished(struct zone *zone, struct 
compact_control *cc,
/* Compaction run completes if the migrate and free scanner meet */
if (compact_scanners_met(cc)) {
/* Let the next compaction start anew. */
-   reset_cached_positions(zone);
+   reset_cached_positions(zone, false);
+   /* 
+* Remember where compaction scanners met for the next time
+* the pivot pfn is changed.
+*/
+   zone->compact_cached_last_met_pfn =
+   cc->migrate_pfn & ~(pageblock_nr_pages-1);
 
/*
 * Mark that the PG_migrate_skip information should be cleared
@@ -1321,7 +1333,7 @@ static int compact_zone(struct zone *zone, struct 
compact_control *cc)
 */
if (compaction_restarting(zone, cc->order) && !current_is_kswapd()) {
__reset_isolation_suitable(zone);
-   reset_cached_positions(zone);
+   reset_cached_positions(zone, true);
}
 
/*
@@ -1334,7 +1346,7 @@ static int compact_zone(struct zon

[PATCH 1/5] mm, compaction: more robust check for scanners meeting

[Vlastimil Babka]

Compaction should finish when the migration and free scanner meet, i.e. they
reach the same pageblock. Currently however, the test in compact_finished()
simply just compares the exact pfns, which may yield a false negative when the
free scanner position is in the middle of a pageblock and the migration
scanner reaches the begining of the same pageblock.

This hasn't been a problem until commit e14c720efdd7 ("mm, compaction:
remember position within pageblock in free pages scanner") allowed the free
scanner position to be in the middle of a pageblock between invocations.
The hot-fix 1d5bfe1ffb5b ("mm, compaction: prevent infinite loop in
compact_zone") prevented the issue by adding a special check in the migration
scanner to satisfy the current detection of scanners meeting.

However, the proper fix is to make the detection more robust. This patch
introduces the compact_scanners_met() function that returns true when the free
scanner position is in the same or lower pageblock than the migration scanner.
The special case in isolate_migratepages() introduced by 1d5bfe1ffb5b is
removed.

Suggested-by: Joonsoo Kim 
Signed-off-by: Vlastimil Babka 
Cc: Minchan Kim 
Cc: Mel Gorman 
Cc: Joonsoo Kim 
Cc: Michal Nazarewicz 
Cc: Naoya Horiguchi 
Cc: Christoph Lameter 
Cc: Rik van Riel 
Cc: David Rientjes 
---
 mm/compaction.c | 22 ++
 1 file changed, 14 insertions(+), 8 deletions(-)

diff --git a/mm/compaction.c b/mm/compaction.c
index 546e571..5fdbdb8 100644
--- a/mm/compaction.c
+++ b/mm/compaction.c
@@ -803,6 +803,16 @@ isolate_migratepages_range(struct compact_control *cc, 
unsigned long start_pfn,
 #endif /* CONFIG_COMPACTION || CONFIG_CMA */
 #ifdef CONFIG_COMPACTION
 /*
+ * Test whether the free scanner has reached the same or lower pageblock than
+ * the migration scanner, and compaction should thus terminate.
+ */
+static inline bool compact_scanners_met(struct compact_control *cc)
+{
+   return (cc->free_pfn >> pageblock_order)
+   <= (cc->migrate_pfn >> pageblock_order);
+}
+
+/*
  * Based on information in the current compact_control, find blocks
  * suitable for isolating free pages from and then isolate them.
  */
@@ -1027,12 +1037,8 @@ static isolate_migrate_t isolate_migratepages(struct 
zone *zone,
}
 
acct_isolated(zone, cc);
-   /*
-* Record where migration scanner will be restarted. If we end up in
-* the same pageblock as the free scanner, make the scanners fully
-* meet so that compact_finished() terminates compaction.
-*/
-   cc->migrate_pfn = (end_pfn <= cc->free_pfn) ? low_pfn : cc->free_pfn;
+   /* Record where migration scanner will be restarted. */
+   cc->migrate_pfn = low_pfn;
 
return cc->nr_migratepages ? ISOLATE_SUCCESS : ISOLATE_NONE;
 }
@@ -1047,7 +1053,7 @@ static int compact_finished(struct zone *zone, struct 
compact_control *cc,
return COMPACT_PARTIAL;
 
/* Compaction run completes if the migrate and free scanner meet */
-   if (cc->free_pfn <= cc->migrate_pfn) {
+   if (compact_scanners_met(cc)) {
/* Let the next compaction start anew. */
zone->compact_cached_migrate_pfn[0] = zone->zone_start_pfn;
zone->compact_cached_migrate_pfn[1] = zone->zone_start_pfn;
@@ -1238,7 +1244,7 @@ static int compact_zone(struct zone *zone, struct 
compact_control *cc)
 * migrate_pages() may return -ENOMEM when scanners meet
 * and we want compact_finished() to detect it
 */
-   if (err == -ENOMEM && cc->free_pfn > cc->migrate_pfn) {
+   if (err == -ENOMEM && !compact_scanners_met(cc)) {
ret = COMPACT_PARTIAL;
goto out;
}
-- 
2.1.2

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

[RFC PATCH 0/5] compaction: changing initial position of scanners

[Vlastimil Babka]

Even after all the patches compaction received in last several versions, it
turns out that its effectivneess degrades considerably as the system ages
after reboot. For example, see how success rates of stress-highalloc from
mmtests degrades when we re-execute it several times, first time being after
fresh reboot:
 3.19-rc4  3.19-rc4  
3.19-rc4
4-nothp-1 4-nothp-2 
4-nothp-3
Success 1 Min 25.00 (  0.00%)   13.00 ( 48.00%)9.00 ( 
64.00%)
Success 1 Mean36.20 (  0.00%)   23.40 ( 35.36%)   16.40 ( 
54.70%)
Success 1 Max 41.00 (  0.00%)   34.00 ( 17.07%)   25.00 ( 
39.02%)
Success 2 Min 25.00 (  0.00%)   15.00 ( 40.00%)   10.00 ( 
60.00%)
Success 2 Mean37.20 (  0.00%)   25.00 ( 32.80%)   17.20 ( 
53.76%)
Success 2 Max 44.00 (  0.00%)   36.00 ( 18.18%)   25.00 ( 
43.18%)
Success 3 Min 84.00 (  0.00%)   81.00 (  3.57%)   78.00 (  
7.14%)
Success 3 Mean85.80 (  0.00%)   82.80 (  3.50%)   80.40 (  
6.29%)
Success 3 Max 87.00 (  0.00%)   84.00 (  3.45%)   82.00 (  
5.75%)

Wouldn't it be much better, if it looked like this?

   3.18  3.18  3.18
 3.19-rc4  3.19-rc4  
3.19-rc4
5-nothp-1 5-nothp-2 
5-nothp-3
Success 1 Min 49.00 (  0.00%)   42.00 ( 14.29%)   41.00 ( 
16.33%)
Success 1 Mean51.00 (  0.00%)   45.00 ( 11.76%)   42.60 ( 
16.47%)
Success 1 Max 55.00 (  0.00%)   51.00 (  7.27%)   46.00 ( 
16.36%)
Success 2 Min 53.00 (  0.00%)   47.00 ( 11.32%)   44.00 ( 
16.98%)
Success 2 Mean59.60 (  0.00%)   50.80 ( 14.77%)   48.20 ( 
19.13%)
Success 2 Max 64.00 (  0.00%)   56.00 ( 12.50%)   52.00 ( 
18.75%)
Success 3 Min 84.00 (  0.00%)   82.00 (  2.38%)   78.00 (  
7.14%)
Success 3 Mean85.60 (  0.00%)   82.80 (  3.27%)   79.40 (  
7.24%)
Success 3 Max 86.00 (  0.00%)   83.00 (  3.49%)   80.00 (  
6.98%)

In my humble opinion, it would :) Much lower degradation, and a nice
improvement in the first iteration as a bonus.

So what sorcery is this? Nothing much, just a fundamental change of the
compaction scanners operation...

As everyone knows [1] the migration scanner starts at the first pageblock
of a zone, and goes towards the end, and the free scanner starts at the
last pageblock and goes towards the beginning. Somewhere in the middle of the
zone, the scanners meet:

   zone_start   zone_end
   |   |
   -
   M| =><= |
   migrate_pfn free_pfn

In my tests, the scanners meet around the middle of the pageblock on the first
iteration, and around the 1/3 on subsequent iterations. Which means the
migration scanner doesn't see the larger part of the zone at all. For more
details why it's bad, see Patch 4 description.

To make sure we eventually scan the whole zone with the migration scanner, we
could e.g. reverse the directions after each run. But that would still be
biased, and with 1/3 of zone reachable from each side, we would still omit the
middle 1/3 of a zone.

Or we could stop terminating compaction when the scanners meet, and let them
continue to scan the whole zone. Mel told me it used to be the case long ago,
but that approach would result in migrating pages back and forth during single
compaction run, which wouldn't be cool.

So the approach taken by this patchset is to let scanners start at any
so-called pivot pfn within the zone, and keep their direction:

   zone_start pivot zone_end
   ||  |
   -
 <= |FFFMM| =>
free_pfn migrate_pfn

Eventually, one of the scanners will reach the zone boundary and wrap around,
e.g. the in the case of the free scanner:

   zone_start pivot zone_end
   ||  |
   -
   F| =>   <= |F
   migrate_pfnfree_pfn

Compaction will again terminate when the scanners meet.


As you can imagine, the required code changes made the termination detection
and the scanners themselves quite hairy. There are lots of 

[PATCH 3/5] mm, compaction: encapsulate resetting cached scanner positions

[Vlastimil Babka]

Reseting the cached compaction scanner positions is now done implicitly in
__reset_isolation_suitable() and compact_finished(). Encapsulate the
functionality in a new function reset_cached_positions() and call it
explicitly where needed.

Signed-off-by: Vlastimil Babka 
Cc: Minchan Kim 
Cc: Mel Gorman 
Cc: Joonsoo Kim 
Cc: Michal Nazarewicz 
Cc: Naoya Horiguchi 
Cc: Christoph Lameter 
Cc: Rik van Riel 
Cc: David Rientjes 
---
 mm/compaction.c | 22 ++
 1 file changed, 14 insertions(+), 8 deletions(-)

diff --git a/mm/compaction.c b/mm/compaction.c
index 45799a4..5626220 100644
--- a/mm/compaction.c
+++ b/mm/compaction.c
@@ -123,6 +123,13 @@ static inline bool isolation_suitable(struct 
compact_control *cc,
return !get_pageblock_skip(page);
 }
 
+static void reset_cached_positions(struct zone *zone)
+{
+   zone->compact_cached_migrate_pfn[0] = zone->zone_start_pfn;
+   zone->compact_cached_migrate_pfn[1] = zone->zone_start_pfn;
+   zone->compact_cached_free_pfn = zone_end_pfn(zone);
+}
+
 /*
  * This function is called to clear all cached information on pageblocks that
  * should be skipped for page isolation when the migrate and free page scanner
@@ -134,9 +141,6 @@ static void __reset_isolation_suitable(struct zone *zone)
unsigned long end_pfn = zone_end_pfn(zone);
unsigned long pfn;
 
-   zone->compact_cached_migrate_pfn[0] = start_pfn;
-   zone->compact_cached_migrate_pfn[1] = start_pfn;
-   zone->compact_cached_free_pfn = end_pfn;
zone->compact_blockskip_flush = false;
 
/* Walk the zone and mark every pageblock as suitable for isolation */
@@ -166,8 +170,10 @@ void reset_isolation_suitable(pg_data_t *pgdat)
continue;
 
/* Only flush if a full compaction finished recently */
-   if (zone->compact_blockskip_flush)
+   if (zone->compact_blockskip_flush) {
__reset_isolation_suitable(zone);
+   reset_cached_positions(zone);
+   }
}
 }
 
@@ -1059,9 +1065,7 @@ static int compact_finished(struct zone *zone, struct 
compact_control *cc,
/* Compaction run completes if the migrate and free scanner meet */
if (compact_scanners_met(cc)) {
/* Let the next compaction start anew. */
-   zone->compact_cached_migrate_pfn[0] = zone->zone_start_pfn;
-   zone->compact_cached_migrate_pfn[1] = zone->zone_start_pfn;
-   zone->compact_cached_free_pfn = zone_end_pfn(zone);
+   reset_cached_positions(zone);
 
/*
 * Mark that the PG_migrate_skip information should be cleared
@@ -1187,8 +1191,10 @@ static int compact_zone(struct zone *zone, struct 
compact_control *cc)
 * is about to be retried after being deferred. kswapd does not do
 * this reset as it'll reset the cached information when going to sleep.
 */
-   if (compaction_restarting(zone, cc->order) && !current_is_kswapd())
+   if (compaction_restarting(zone, cc->order) && !current_is_kswapd()) {
__reset_isolation_suitable(zone);
+   reset_cached_positions(zone);
+   }
 
/*
 * Setup to move all movable pages to the end of the zone. Used cached
-- 
2.1.2

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