[PATCH v2 06/10] pwm: pwm-tiehrpwm: Add device-tree binding support for EHRPWM driver

[Philip, Avinash]

This patch
1. Add support for device-tree binding for EHRWPM driver.
2. Set size of pwm-cells set to 3 to support PWM channel number, PWM
   period & polarity configuration from device tree.
3. Add enable/disable clock gating in PWM subsystem common config space.
4. When here set .owner member in platform_driver structure to
   THIS_MODULE.

Signed-off-by: Philip, Avinash 
Cc: Grant Likely 
Cc: Rob Herring 
Cc: Rob Landley 
---
Changes since v1:
- Add separate patch for pinctrl support
- Add conditional check for PWM subsystem clock enable.
- Combined with HWMOD changes & DT bindings.
- Remove the custom of xlate support.

:00 100644 000... aa2ed0a... A  
Documentation/devicetree/bindings/pwm/pwm-tiehrpwm.txt
:100644 100644 d3c1dff... fba7f9b... M  drivers/pwm/pwm-tiehrpwm.c
 .../devicetree/bindings/pwm/pwm-tiehrpwm.txt   |   25 ++
 drivers/pwm/pwm-tiehrpwm.c |   49 +++-
 2 files changed, 72 insertions(+), 2 deletions(-)

diff --git a/Documentation/devicetree/bindings/pwm/pwm-tiehrpwm.txt 
b/Documentation/devicetree/bindings/pwm/pwm-tiehrpwm.txt
new file mode 100644
index 000..aa2ed0a
--- /dev/null
+++ b/Documentation/devicetree/bindings/pwm/pwm-tiehrpwm.txt
@@ -0,0 +1,25 @@
+TI SOC EHRPWM based PWM controller
+
+Required properties:
+- compatible : Must be "ti,am33xx-ehrpwm"
+- #pwm-cells: Should be 3. Number of cells being used to specify PWM property.
+  First cell specifies the per-chip index of the PWM to use, the second
+  cell is the period cycle in nanoseconds and bit 0 in the third cell is
+  used to encode the polarity of PWM output.
+- reg: physical base address and size of the registers map.
+
+Optional properties:
+- ti,hwmods: Name of the hwmod associated to the EHRPWM:
+  "ehrpwm",  being the 0-based instance number from the HW spec
+- tbclkgating: platforms require tbclk gating from control module
+  should populate
+
+Example:
+
+ehrpwm0: ehrpwm@0 {
+   compatible = "ti,am33xx-ehrpwm";
+   #pwm-cells = <3>;
+   reg = <0x48300200 0x100>;
+   ti,hwmods = "ehrpwm0";
+   tbclkgating;
+};
diff --git a/drivers/pwm/pwm-tiehrpwm.c b/drivers/pwm/pwm-tiehrpwm.c
index d3c1dff..fba7f9b 100644
--- a/drivers/pwm/pwm-tiehrpwm.c
+++ b/drivers/pwm/pwm-tiehrpwm.c
@@ -25,6 +25,9 @@
 #include 
 #include 
 #include 
+#include 
+
+#include "tipwmss.h"
 
 /* EHRPWM registers and bits definitions */
 
@@ -107,6 +110,13 @@
 #define AQCSFRC_CSFA_FRCHIGH   BIT(1)
 #define AQCSFRC_CSFA_DISSWFRC  (BIT(1) | BIT(0))
 
+#define EPWMCLK_EN BIT(8)
+#define EPWMCLK_STOP_REQ   BIT(9)
+
+#define EPWMCLK_EN_ACK BIT(8)
+
+#define PWM_CELL_SIZE  3
+
 #define NUM_PWM_CHANNEL2   /* EHRPWM channels */
 
 struct ehrpwm_pwm_chip {
@@ -392,6 +402,16 @@ static const struct pwm_ops ehrpwm_pwm_ops = {
.owner  = THIS_MODULE,
 };
 
+#ifdef CONFIG_OF
+static const struct of_device_id ehrpwm_of_match[] = {
+   {
+   .compatible = "ti,am33xx-ehrpwm",
+   },
+   {},
+};
+MODULE_DEVICE_TABLE(of, ehrpwm_of_match);
+#endif
+
 static int __devinit ehrpwm_pwm_probe(struct platform_device *pdev)
 {
int ret;
@@ -419,6 +439,7 @@ static int __devinit ehrpwm_pwm_probe(struct 
platform_device *pdev)
 
pc->chip.dev = >dev;
pc->chip.ops = _pwm_ops;
+   pc->chip.of_pwm_n_cells = PWM_CELL_SIZE;
pc->chip.base = -1;
pc->chip.npwm = NUM_PWM_CHANNEL;
 
@@ -437,16 +458,38 @@ static int __devinit ehrpwm_pwm_probe(struct 
platform_device *pdev)
dev_err(>dev, "pwmchip_add() failed: %d\n", ret);
return ret;
}
-
pm_runtime_enable(>dev);
+   pm_runtime_get_sync(>dev);
+   if (!(pwmss_submodule_state_change(pdev->dev.parent, EPWMCLK_EN) &
+   EPWMCLK_EN_ACK)) {
+   dev_err(>dev, "PWMSS config space clock enable 
failure\n");
+   ret = -EINVAL;
+   goto pwmss_clk_failure;
+   }
+   pm_runtime_put_sync(>dev);
+
platform_set_drvdata(pdev, pc);
return 0;
+
+pwmss_clk_failure:
+   pm_runtime_put_sync(>dev);
+   pm_runtime_disable(>dev);
+   pwmchip_remove(>chip);
+   return ret;
 }
 
 static int __devexit ehrpwm_pwm_remove(struct platform_device *pdev)
 {
struct ehrpwm_pwm_chip *pc = platform_get_drvdata(pdev);
 
+   pm_runtime_get_sync(>dev);
+   /*
+* Due to hardware misbehaviour, acknowledge of the stop_req
+* is missing. Hence checking of the status bit skipped.
+*/
+   pwmss_submodule_state_change(pdev->dev.parent, EPWMCLK_STOP_REQ);
+   pm_runtime_put_sync(>dev);
+
pm_runtime_put_sync(>dev);
pm_runtime_disable(>dev);
return pwmchip_remove(>chip);
@@ -454,7 +497,9 @@ static int __devexit ehrpwm_pwm_remove(struct 
platform_device *pdev)
 
 static struct platform_driver 

[PATCH v2 05/10] pwm: pwm-tiecap: pinctrl support

[Philip, Avinash]

Enable pinctrl for pwm-tiecap

Signed-off-by: Philip, Avinash 
---
:100644 100644 0d43266... 6071f7a... M  drivers/pwm/pwm-tiecap.c
 drivers/pwm/pwm-tiecap.c |6 ++
 1 files changed, 6 insertions(+), 0 deletions(-)

diff --git a/drivers/pwm/pwm-tiecap.c b/drivers/pwm/pwm-tiecap.c
index 0d43266..6071f7a 100644
--- a/drivers/pwm/pwm-tiecap.c
+++ b/drivers/pwm/pwm-tiecap.c
@@ -26,6 +26,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include "tipwmss.h"
 
@@ -210,6 +211,11 @@ static int __devinit ecap_pwm_probe(struct platform_device 
*pdev)
struct resource *r;
struct clk *clk;
struct ecap_pwm_chip *pc;
+   struct pinctrl *pinctrl;
+
+   pinctrl = devm_pinctrl_get_select_default(>dev);
+   if (IS_ERR(pinctrl))
+   dev_warn(>dev, "failed to configure pins from driver\n");
 
pc = devm_kzalloc(>dev, sizeof(*pc), GFP_KERNEL);
if (!pc) {
-- 
1.7.0.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 v2 04/10] pwm: pwm-tiecap: Add device-tree binding support for APWM driver

[Philip, Avinash]

This patch
1. Add support for device-tree binding for ECAP APWM driver.
2. Set size of pwm-cells set to 3 to support PWM channel number, PWM
   period & polarity configuration from device tree.
3. Add enable/disable clock gating in PWM subsystem common config space.
4. When here set .owner member in platform_driver structure to
   THIS_MODULE.

Signed-off-by: Philip, Avinash 
Cc: Grant Likely 
Cc: Rob Herring 
Cc: Rob Landley 
---
Changes since v1:
- Add separate patch for pinctrl support
- Add conditional check for PWM subsystem clock enable.
- Combined with HWMOD changes & DT bindings.
- Remove the custom of xlate support.

:00 100644 000... fe24cac... A  
Documentation/devicetree/bindings/pwm/pwm-tiecap.txt
:100644 100644 d6d4cf0... 0d43266... M  drivers/pwm/pwm-tiecap.c
 .../devicetree/bindings/pwm/pwm-tiecap.txt |   22 +
 drivers/pwm/pwm-tiecap.c   |   48 +++-
 2 files changed, 69 insertions(+), 1 deletions(-)

diff --git a/Documentation/devicetree/bindings/pwm/pwm-tiecap.txt 
b/Documentation/devicetree/bindings/pwm/pwm-tiecap.txt
new file mode 100644
index 000..fe24cac
--- /dev/null
+++ b/Documentation/devicetree/bindings/pwm/pwm-tiecap.txt
@@ -0,0 +1,22 @@
+TI SOC ECAP based APWM controller
+
+Required properties:
+- compatible: Must be "ti,am33xx-ecap"
+- #pwm-cells: Should be 3. Number of cells being used to specify PWM property.
+  First cell specifies the per-chip index of the PWM to use, the second
+  cell is the period cycle in nanoseconds and bit 0 in the third cell is
+  used to encode the polarity of PWM output.
+- reg: physical base address and size of the registers map.
+
+Optional properties:
+- ti,hwmods: Name of the hwmod associated to the ECAP:
+  "ecap",  being the 0-based instance number from the HW spec
+
+Example:
+
+ecap0: ecap@0 {
+   compatible = "ti,am33xx-ecap";
+   #pwm-cells = <3>;
+   reg = <0x48300100 0x80>;
+   ti,hwmods = "ecap0";
+};
diff --git a/drivers/pwm/pwm-tiecap.c b/drivers/pwm/pwm-tiecap.c
index d6d4cf0..0d43266 100644
--- a/drivers/pwm/pwm-tiecap.c
+++ b/drivers/pwm/pwm-tiecap.c
@@ -25,6 +25,9 @@
 #include 
 #include 
 #include 
+#include 
+
+#include "tipwmss.h"
 
 /* ECAP registers and bits definitions */
 #define CAP1   0x08
@@ -37,6 +40,13 @@
 #define ECCTL2_SYNC_SEL_DISA   (BIT(7) | BIT(6))
 #define ECCTL2_TSCTR_FREERUN   BIT(4)
 
+#define ECAPCLK_EN BIT(0)
+#define ECAPCLK_STOP_REQ   BIT(1)
+
+#define ECAPCLK_EN_ACK BIT(0)
+
+#define PWM_CELL_SIZE  3
+
 struct ecap_pwm_chip {
struct pwm_chip chip;
unsigned intclk_rate;
@@ -184,6 +194,16 @@ static const struct pwm_ops ecap_pwm_ops = {
.owner  = THIS_MODULE,
 };
 
+#ifdef CONFIG_OF
+static const struct of_device_id ecap_of_match[] = {
+   {
+   .compatible = "ti,am33xx-ecap",
+   },
+   {},
+};
+MODULE_DEVICE_TABLE(of, ecap_of_match);
+#endif
+
 static int __devinit ecap_pwm_probe(struct platform_device *pdev)
 {
int ret;
@@ -211,6 +231,7 @@ static int __devinit ecap_pwm_probe(struct platform_device 
*pdev)
 
pc->chip.dev = >dev;
pc->chip.ops = _pwm_ops;
+   pc->chip.of_pwm_n_cells = PWM_CELL_SIZE;
pc->chip.base = -1;
pc->chip.npwm = 1;
 
@@ -231,14 +252,37 @@ static int __devinit ecap_pwm_probe(struct 
platform_device *pdev)
}
 
pm_runtime_enable(>dev);
+   pm_runtime_get_sync(>dev);
+   if (!(pwmss_submodule_state_change(pdev->dev.parent, ECAPCLK_EN) &
+   ECAPCLK_EN_ACK)) {
+   dev_err(>dev, "PWMSS config space clock enable 
failure\n");
+   ret = -EINVAL;
+   goto pwmss_clk_failure;
+   }
+   pm_runtime_put_sync(>dev);
+
platform_set_drvdata(pdev, pc);
return 0;
+
+pwmss_clk_failure:
+   pm_runtime_put_sync(>dev);
+   pm_runtime_disable(>dev);
+   pwmchip_remove(>chip);
+   return ret;
 }
 
 static int __devexit ecap_pwm_remove(struct platform_device *pdev)
 {
struct ecap_pwm_chip *pc = platform_get_drvdata(pdev);
 
+   pm_runtime_get_sync(>dev);
+   /*
+* Due to hardware misbehaviour, acknowledge of the stop_req
+* is missing. Hence checking of the status bit skipped.
+*/
+   pwmss_submodule_state_change(pdev->dev.parent, ECAPCLK_STOP_REQ);
+   pm_runtime_put_sync(>dev);
+
pm_runtime_put_sync(>dev);
pm_runtime_disable(>dev);
return pwmchip_remove(>chip);
@@ -246,7 +290,9 @@ static int __devexit ecap_pwm_remove(struct platform_device 
*pdev)
 
 static struct platform_driver ecap_pwm_driver = {
.driver = {
-   .name = "ecap",
+   .name   = "ecap",
+   .owner  = THIS_MODULE,
+   .of_match_table = of_match_ptr(ecap_of_match),
},
.probe = ecap_pwm_probe,
  

[PATCH v2 03/10] ARM: OMAP: AM33xx hwmod: Add parent-child relationship for PWM subsystem

[Philip, Avinash]

As part of PWM subsystem integration, PWM subsystem are sharing
resources like clock across submodules (ECAP, EQEP & EHRPWM).
To handle resource sharing & IP integration
1. Rework on parent child relation between PWMSS and
   ECAP, EQEP & EHRPWM child devices to support runtime PM.
2. Add support for opt_clks in EHRPWM HWMOD entry to handle additional
   clock gating from control module.
3. Add HWMOD entries for EQEP PWM submodule.

Signed-off-by: Philip, Avinash 
---
Changes since v1:
- Remove ADDR_TYPE_RT for PWM sub module register entries.

:100644 100644 ad8d43b... de2301c... M  
arch/arm/mach-omap2/omap_hwmod_33xx_data.c
 arch/arm/mach-omap2/omap_hwmod_33xx_data.c |  419 ++--
 1 files changed, 276 insertions(+), 143 deletions(-)

diff --git a/arch/arm/mach-omap2/omap_hwmod_33xx_data.c 
b/arch/arm/mach-omap2/omap_hwmod_33xx_data.c
index ad8d43b..de2301c 100644
--- a/arch/arm/mach-omap2/omap_hwmod_33xx_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_33xx_data.c
@@ -768,9 +768,7 @@ static struct omap_hwmod am33xx_elm_hwmod = {
},
 };
 
-/*
- * 'epwmss' class: ecap0,1,2,  ehrpwm0,1,2
- */
+/* pwmss */
 static struct omap_hwmod_class_sysconfig am33xx_epwmss_sysc = {
.rev_offs   = 0x0,
.sysc_offs  = 0x4,
@@ -786,18 +784,23 @@ static struct omap_hwmod_class am33xx_epwmss_hwmod_class 
= {
.sysc   = _epwmss_sysc,
 };
 
-/* ehrpwm0 */
-static struct omap_hwmod_irq_info am33xx_ehrpwm0_irqs[] = {
-   { .name = "int", .irq = 86 + OMAP_INTC_START, },
-   { .name = "tzint", .irq = 58 + OMAP_INTC_START, },
-   { .irq = -1 },
+
+static struct omap_hwmod_class am33xx_ecap_hwmod_class = {
+   .name   = "ecap",
 };
 
-static struct omap_hwmod am33xx_ehrpwm0_hwmod = {
-   .name   = "ehrpwm0",
+static struct omap_hwmod_class am33xx_eqep_hwmod_class = {
+   .name   = "eqep",
+};
+
+static struct omap_hwmod_class am33xx_ehrpwm_hwmod_class = {
+   .name   = "ehrpwm",
+};
+/* epwmss0 */
+static struct omap_hwmod am33xx_epwmss0_hwmod = {
+   .name   = "epwmss0",
.class  = _epwmss_hwmod_class,
.clkdm_name = "l4ls_clkdm",
-   .mpu_irqs   = am33xx_ehrpwm0_irqs,
.main_clk   = "l4ls_gclk",
.prcm   = {
.omap4  = {
@@ -807,63 +810,68 @@ static struct omap_hwmod am33xx_ehrpwm0_hwmod = {
},
 };
 
-/* ehrpwm1 */
-static struct omap_hwmod_irq_info am33xx_ehrpwm1_irqs[] = {
-   { .name = "int", .irq = 87 + OMAP_INTC_START, },
-   { .name = "tzint", .irq = 59 + OMAP_INTC_START, },
+/* ecap0 */
+static struct omap_hwmod_irq_info am33xx_ecap0_irqs[] = {
+   { .irq = 31 + OMAP_INTC_START, },
{ .irq = -1 },
 };
 
-static struct omap_hwmod am33xx_ehrpwm1_hwmod = {
-   .name   = "ehrpwm1",
-   .class  = _epwmss_hwmod_class,
+static struct omap_hwmod am33xx_ecap0_hwmod = {
+   .name   = "ecap0",
+   .class  = _ecap_hwmod_class,
.clkdm_name = "l4ls_clkdm",
-   .mpu_irqs   = am33xx_ehrpwm1_irqs,
+   .mpu_irqs   = am33xx_ecap0_irqs,
.main_clk   = "l4ls_gclk",
-   .prcm   = {
-   .omap4  = {
-   .clkctrl_offs   = AM33XX_CM_PER_EPWMSS1_CLKCTRL_OFFSET,
-   .modulemode = MODULEMODE_SWCTRL,
-   },
-   },
 };
 
-/* ehrpwm2 */
-static struct omap_hwmod_irq_info am33xx_ehrpwm2_irqs[] = {
-   { .name = "int", .irq = 39 + OMAP_INTC_START, },
-   { .name = "tzint", .irq = 60 + OMAP_INTC_START, },
+/* eqep0 */
+static struct omap_hwmod_irq_info am33xx_eqep0_irqs[] = {
+   { .irq = 79 + OMAP_INTC_START, },
{ .irq = -1 },
 };
 
-static struct omap_hwmod am33xx_ehrpwm2_hwmod = {
-   .name   = "ehrpwm2",
-   .class  = _epwmss_hwmod_class,
+static struct omap_hwmod am33xx_eqep0_hwmod = {
+   .name   = "eqep0",
+   .class  = _eqep_hwmod_class,
.clkdm_name = "l4ls_clkdm",
-   .mpu_irqs   = am33xx_ehrpwm2_irqs,
+   .mpu_irqs   = am33xx_eqep0_irqs,
.main_clk   = "l4ls_gclk",
-   .prcm   = {
-   .omap4  = {
-   .clkctrl_offs   = AM33XX_CM_PER_EPWMSS2_CLKCTRL_OFFSET,
-   .modulemode = MODULEMODE_SWCTRL,
-   },
-   },
 };
 
-/* ecap0 */
-static struct omap_hwmod_irq_info am33xx_ecap0_irqs[] = {
-   { .irq = 31 + OMAP_INTC_START, },
+/* ehrpwm0 */
+static struct omap_hwmod_irq_info am33xx_ehrpwm0_irqs[] = {
+   { .name = "int", .irq = 86 + OMAP_INTC_START, },
+   { .name = "tzint", .irq = 58 + OMAP_INTC_START, },
{ .irq = -1 },
 };
 
-static struct omap_hwmod am33xx_ecap0_hwmod = {
-   .name   = "ecap0",
+/*
+ * Optional clock entry is provided to support additional clock
+ * gating for EHRPWM module functional from control module.
+ 

[PATCH v2 02/10] ARM: am33xx: clk: Add optional clock for EHRPWM

[Philip, Avinash]

EHRPWM module requires explicit clock gating from control module.
Hence add clock node in clock tree for EHRPWM modules.

Signed-off-by: Philip, Avinash 
---
:100644 100644 17e3de5... 833260f... M  arch/arm/mach-omap2/clock33xx_data.c
:100644 100644 a89e825... c0e34e6... M  arch/arm/mach-omap2/control.h
 arch/arm/mach-omap2/clock33xx_data.c |   37 ++
 arch/arm/mach-omap2/control.h|8 +++
 2 files changed, 45 insertions(+), 0 deletions(-)

diff --git a/arch/arm/mach-omap2/clock33xx_data.c 
b/arch/arm/mach-omap2/clock33xx_data.c
index 17e3de5..833260f 100644
--- a/arch/arm/mach-omap2/clock33xx_data.c
+++ b/arch/arm/mach-omap2/clock33xx_data.c
@@ -995,6 +995,40 @@ static struct clk wdt1_fck = {
 };
 
 /*
+ * PWMSS Time based module clock node. This node is
+ * requred to enable clock gating for EHRPWM TBCLK.
+ */
+static struct clk ehrpwm0_tbclk = {
+   .name   = "ehrpwm0_tbclk",
+   .clkdm_name = "l4ls_clkdm",
+   .enable_reg = AM33XX_CTRL_REGADDR(AM33XX_PWMSS_TBCLK_CLKCTRL),
+   .enable_bit = AM33XX_PWMSS0_TBCLKEN_SHIFT,
+   .ops= _omap2_dflt,
+   .parent = _gclk,
+   .recalc = _recalc,
+};
+
+static struct clk ehrpwm1_tbclk = {
+   .name   = "ehrpwm1_tbclk",
+   .clkdm_name = "l4ls_clkdm",
+   .enable_reg = AM33XX_CTRL_REGADDR(AM33XX_PWMSS_TBCLK_CLKCTRL),
+   .enable_bit = AM33XX_PWMSS1_TBCLKEN_SHIFT,
+   .ops= _omap2_dflt,
+   .parent = _gclk,
+   .recalc = _recalc,
+};
+
+static struct clk ehrpwm2_tbclk = {
+   .name   = "ehrpwm2_tbclk",
+   .clkdm_name = "l4ls_clkdm",
+   .enable_reg = AM33XX_CTRL_REGADDR(AM33XX_PWMSS_TBCLK_CLKCTRL),
+   .enable_bit = AM33XX_PWMSS2_TBCLKEN_SHIFT,
+   .ops= _omap2_dflt,
+   .parent = _gclk,
+   .recalc = _recalc,
+};
+
+/*
  * clkdev
  */
 static struct omap_clk am33xx_clks[] = {
@@ -1074,6 +1108,9 @@ static struct omap_clk am33xx_clks[] = {
CLK(NULL,   "clkout2_ck",   _ck,CK_AM33XX),
CLK(NULL,   "timer_32k_ck", _ick, CK_AM33XX),
CLK(NULL,   "timer_sys_ck", _clkin_ck,  CK_AM33XX),
+   CLK(NULL,   "ehrpwm0_tbclk",_tbclk, CK_AM33XX),
+   CLK(NULL,   "ehrpwm1_tbclk",_tbclk, CK_AM33XX),
+   CLK(NULL,   "ehrpwm2_tbclk",_tbclk, CK_AM33XX),
 };
 
 int __init am33xx_clk_init(void)
diff --git a/arch/arm/mach-omap2/control.h b/arch/arm/mach-omap2/control.h
index a89e825..c0e34e6 100644
--- a/arch/arm/mach-omap2/control.h
+++ b/arch/arm/mach-omap2/control.h
@@ -357,6 +357,14 @@
 #define AM33XX_CONTROL_STATUS_SYSBOOT1_WIDTH   0x2
 #define AM33XX_CONTROL_STATUS_SYSBOOT1_MASK(0x3 << 22)
 
+/* AM33XX PWMSS Control register */
+#define AM33XX_PWMSS_TBCLK_CLKCTRL 0x664
+
+/* AM33XX  PWMSS Control bitfields */
+#define AM33XX_PWMSS0_TBCLKEN_SHIFT0
+#define AM33XX_PWMSS1_TBCLKEN_SHIFT1
+#define AM33XX_PWMSS2_TBCLKEN_SHIFT2
+
 /* CONTROL OMAP STATUS register to identify OMAP3 features */
 #define OMAP3_CONTROL_OMAP_STATUS  0x044c
 
-- 
1.7.0.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 v2 01/10] PWMSS: Add PWM Subsystem driver for parent<->child relationship

[Philip, Avinash]

In some platforms (like am33xx), PWM sub modules (ECAP, EHRPWM, EQEP)
are integrated to PWM subsystem. These PWM submodules has resources
shared and only one register bit-field is provided to control
module/clock enable/disable, makes it difficult to handle common
resources from independent PWMSS submodule drivers.

So the solution here implemented in this patch is, to create driver for
PWMSS and take the role of parent driver for PWM submodules. PWMSS
parent driver enumerates all the child nodes under PWMSS module. Also
symbol "pwmss_submodule_state_change" exported to enable clock gating
for individual PWMSS submodules, and submodule drivers has to enable
clock gating from their drivers.

As this is only supported during DT boot, the parent<->child relationship
is created and populated in DT execution flow. The only required change
is inside DTS file, making EHRPWM & ECAP as a child to PWMSS node.

Signed-off-by: Philip, Avinash 
---
Changes since v1:
- Add conditional check for PWM susbsystem clock enabling.
- Add context save/restore for PWM subsystem clock config register.

:00 100644 000... b6c2814... A  
Documentation/devicetree/bindings/pwm/tipwmss.txt
:100644 100644 6e556c7... 384a346... M  drivers/pwm/Kconfig
:100644 100644 3b3f4c9a.. 55f6fb2... M  drivers/pwm/Makefile
:00 100644 000... c188348... A  drivers/pwm/tipwmss.c
:00 100644 000... f9cb2e2... A  drivers/pwm/tipwmss.h
 Documentation/devicetree/bindings/pwm/tipwmss.txt |   30 +
 drivers/pwm/Kconfig   |   11 ++
 drivers/pwm/Makefile  |1 +
 drivers/pwm/tipwmss.c |  142 +
 drivers/pwm/tipwmss.h |   30 +
 5 files changed, 214 insertions(+), 0 deletions(-)

diff --git a/Documentation/devicetree/bindings/pwm/tipwmss.txt 
b/Documentation/devicetree/bindings/pwm/tipwmss.txt
new file mode 100644
index 000..b6c2814
--- /dev/null
+++ b/Documentation/devicetree/bindings/pwm/tipwmss.txt
@@ -0,0 +1,30 @@
+TI SOC based PWM Subsystem
+
+Required properties:
+- compatible: Must be "ti,am33xx-pwmss";
+- reg: physical base address and size of the registers map. For am33xx,
+   4 set of register maps present, PWMSS config space, ECAP register space,
+   EQEP register space, EHRPWM register space.
+- address-cells: Specify the number of u32 entries needed in child nodes.
+Should set to 1.
+- size-cells: specify inumber of u32 entries needed to specify child nodes size
+   in reg property. Should set to 1.
+- ranges: describes the address mapping of a memory-mapped bus. Should set to 
empty
+ as parent and child address space is identical.
+
+Also child nodes should also populated under PWMSS DT node.
+Example:
+pwmss0: pwmss@4830 {
+   compatible = "ti,am33xx-pwmss";
+   reg = <0x4830 0x10
+   0x48300100 0x80
+   0x48300180 0x80
+   0x48300200 0x80>;
+   ti,hwmods = "epwmss0";
+   #address-cells = <1>;
+   #size-cells = <1>;
+   status = "disabled";
+   ranges;
+
+   /* child nodes go here */
+};
diff --git a/drivers/pwm/Kconfig b/drivers/pwm/Kconfig
index 6e556c7..384a346 100644
--- a/drivers/pwm/Kconfig
+++ b/drivers/pwm/Kconfig
@@ -136,6 +136,7 @@ config PWM_TEGRA
 config  PWM_TIECAP
tristate "ECAP PWM support"
depends on SOC_AM33XX
+   select PWM_TIPWMSS
help
  PWM driver support for the ECAP APWM controller found on AM33XX
  TI SOC
@@ -146,6 +147,7 @@ config  PWM_TIECAP
 config  PWM_TIEHRPWM
tristate "EHRPWM PWM support"
depends on SOC_AM33XX
+   select PWM_TIPWMSS
help
  PWM driver support for the EHRPWM controller found on AM33XX
  TI SOC
@@ -153,6 +155,15 @@ config  PWM_TIEHRPWM
  To compile this driver as a module, choose M here: the module
  will be called pwm-tiehrpwm.
 
+config  PWM_TIPWMSS
+   tristate "TI PWM Subsytem parent support"
+   depends on SOC_AM33XX && (PWM_TIEHRPWM || PWM_TIECAP)
+   help
+ PWM Subsystem driver support for AM33xx SOC.
+
+ PWM submodules require PWM config space access from submodule
+ drivers and require common parent driver support.
+
 config PWM_TWL6030
tristate "TWL6030 PWM support"
depends on TWL4030_CORE
diff --git a/drivers/pwm/Makefile b/drivers/pwm/Makefile
index 3b3f4c9..55f6fb2 100644
--- a/drivers/pwm/Makefile
+++ b/drivers/pwm/Makefile
@@ -12,5 +12,6 @@ obj-$(CONFIG_PWM_SPEAR)   += pwm-spear.o
 obj-$(CONFIG_PWM_TEGRA)+= pwm-tegra.o
 obj-$(CONFIG_PWM_TIECAP)   += pwm-tiecap.o
 obj-$(CONFIG_PWM_TIEHRPWM) += pwm-tiehrpwm.o
+obj-$(CONFIG_PWM_TIPWMSS)  += tipwmss.o
 obj-$(CONFIG_PWM_TWL6030)  += pwm-twl6030.o
 obj-$(CONFIG_PWM_VT8500)   += pwm-vt8500.o
diff --git a/drivers/pwm/tipwmss.c b/drivers/pwm/tipwmss.c

[PATCH v2 00/10] Support for AM33xx PWM Susbsytem

[Philip, Avinash]

In AM33xx PWM sub modules like ECAP, EHRPWM & EQEP are  integrated to
PWM subsystem. All these submodules shares the resources (clock) & has
a clock gating register in PWM Subsystem. This patch series creates a
parent PWM Subsystem driver to handle access synchronization of shared
resources & clock gating from PWM Subsystem configuration space.
Also Device tree nodes populated to support parent child relation
between PWMSS, ECAP & EHRPWM submodules.
In addition EHRPWM module requires explicit clock gating from control
module & is handled by patch #2 & 8.

Patch #4 & 5 submitted is a second revision as suggested by  Thierry
for handling clock gating with a global function . This requires config
space handling done independent from driver and is done at parent driver.
So the parent<->child relation adopted to handle
1. pm runtime synchronization
2. PWM subsystem common config space clock gating for PWM submodules.

Patches supports
- Driver support for parent child relation handled patch #1
- Optional EHRPWM tb clock in patch #2
- Parent child in HWMOD handled at patch #3
- Device tree binding support handled in patch #4, 6 &8
- pinctrl support in patch #5 & 7.
- DT node populated in patch #9 & 10.

This patch series based on linux-next/20121031 and tested on AM33xx.
It depends on [1]

1. https://lkml.org/lkml/2012/10/29/589
pwm: Device tree support for PWM polarity

Philip, Avinash (10):
  PWMSS: Add PWM Subsystem driver for parent<->child relationship
  ARM: am33xx: clk: Add optional clock for EHRPWM
  ARM: OMAP: AM33xx hwmod: Add parent-child relationship for PWM
subsystem
  pwm: pwm-tiecap: Add device-tree binding support for APWM driver
  pwm: pwm-tiecap: pinctrl support
  pwm: pwm-tiehrpwm: Add device-tree binding support for EHRPWM driver
  pwm: pwm-tiehrpwm: pinctrl support
  pwm: pwm-tiehrpwm: Adding TBCLK gating support.
  ARM: dts: AM33XX: Add PWMSS device tree nodes
  ARM: dts: AM33XX: Add PWM backlight DT data to am335x-evm

 .../devicetree/bindings/pwm/pwm-tiecap.txt |   22 +
 .../devicetree/bindings/pwm/pwm-tiehrpwm.txt   |   25 ++
 Documentation/devicetree/bindings/pwm/tipwmss.txt  |   30 ++
 arch/arm/boot/dts/am335x-evm.dts   |   21 +
 arch/arm/boot/dts/am33xx.dtsi  |   90 +
 arch/arm/mach-omap2/clock33xx_data.c   |   37 ++
 arch/arm/mach-omap2/control.h  |8 +
 arch/arm/mach-omap2/omap_hwmod_33xx_data.c |  419 +---
 drivers/pwm/Kconfig|   11 +
 drivers/pwm/Makefile   |1 +
 drivers/pwm/pwm-tiecap.c   |   54 +++-
 drivers/pwm/pwm-tiehrpwm.c |   75 -
 drivers/pwm/tipwmss.c  |  142 +++
 drivers/pwm/tipwmss.h  |   30 ++
 14 files changed, 820 insertions(+), 145 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/pwm/pwm-tiecap.txt
 create mode 100644 Documentation/devicetree/bindings/pwm/pwm-tiehrpwm.txt
 create mode 100644 Documentation/devicetree/bindings/pwm/tipwmss.txt
 create mode 100644 drivers/pwm/tipwmss.c
 create mode 100644 drivers/pwm/tipwmss.h

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

Re: [PATCH 3/3] pwm: New driver to support PWM driven LEDs on TWL4030/6030 series of PMICs

[Péter Ujfalusi]

On 11/07/2012 07:12 PM, Grazvydas Ignotas wrote:
>> +static int twl4030_pwmled_config(struct pwm_chip *chip, struct pwm_device 
>> *pwm,
>> + int duty_ns, int period_ns)
>> +{
>> +   int duty_cycle = (duty_ns * TWL4030_LED_MAX) / period_ns;
>> +   u8 on_time;
>> +   u8 pwm_config[2];
>> +   int base, ret;
>> +
>> +   if (duty_cycle >= TWL4030_LED_MAX)
>> +   on_time = TWL4030_LED_MAX;
>> +   else if (!duty_cycle)
>> +   on_time = TWL4030_LED_MAX - 1;
>> +   else
>> +   on_time = TWL4030_LED_MAX - duty_cycle;
>> +
>> +   base = pwm->hwpwm * 2 + TWL4030_PWMA_REG;
>> +
>> +   pwm_config[0] = on_time;
>> +   pwm_config[1] = TWL4030_LED_MAX;
>> +
>> +   ret = twl_i2c_write(TWL4030_MODULE_LED, pwm_config, base, 2);
> 
> Shouldn't this use TWL4030_MODULE_PWMA and TWL4030_MODULE_PWMB as
> first argument? I can guess it works your way too, but
> TWL4030_MODULE_PWMx would match the TRM better.

I don't have strong opinion regarding to this. You mean changing from:

base = pwm->hwpwm * 2 + TWL4030_PWMA_REG;
ret = twl_i2c_write(TWL4030_MODULE_LED, pwm_config, base, 2);

to:

if (pwm->hwpwm)
module = TWL4030_MODULE_PWMB;
else
module = TWL4030_MODULE_PWMA;
ret = twl_i2c_write(module, pwm_config, 0, 2);

But I want to note that I'm currently trying to clean up the mess around
twl-core. In my view we have quite a bit of redundancy in there. The PWM A/B
is for driving the LED A/B outputs. We should have only these modules for
PWM/LED in twl-core:
TWL_MODULE_PWM - offset for PWM0ON register in twl4030 and PWM1ON for twl6030
TWL_MODULE_LED - offset for LEDEN register in twl4030 and LED_PWM_CTRL1
 for twl6030

>From here the driver can figure out what to do IMHO.

There's no need to have separate TWL 'modules' for:
TWL4030_BASEADD_PWM0
TWL4030_BASEADD_PWM1
TWL4030_BASEADD_PWMA
TWL4030_BASEADD_PWMB

-- 
Péter
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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: A reliable kernel panic (3.6.2) and system crash when visiting a particular website

[Daniel Mack]

On 08.11.2012 07:43, Takashi Iwai wrote:
> At Thu, 08 Nov 2012 01:42:59 +0100,
> Daniel Mack wrote:
>>
>> On 07.11.2012 20:19, Takashi Iwai wrote:
>>> At Wed, 7 Nov 2012 12:34:43 -0500 (EST),
>>> Alan Stern wrote:

 On Mon, 5 Nov 2012, Christof Meerwald wrote:

> BTW, I have been able to reproduce the problem on a completely
> different machine (also running Ubuntu 12.10, but different hardware).
> The important thing appears to be that the USB audio device is
> connected via a USB 2.0 hub (and then using the test code posted in
> http://pastebin.com/aHGe1S1X specifying the audio device as
> "plughw:Set" (or whatever it's called) seems to trigger the freeze).

 Christof: Thank you for that reference, it was a big help.  After
 crashing my system many times I have tracked the problem, at least in
 part.  The patch below should prevent your system from freezing.


 Takashi: It turns out the the problem is triggered when the audio
 subsystem calls snd_usb_endpoint_stop() with wait == 0 and then calls
 snd_usb_endpoint_start().  Since the driver doesn't wait for the
 outstanding URBs to finish, it tries to submit them again while they
 are still active.

 Normally the USB core would realize this and fail the submission, but a
 bug in ehci-hcd prevented this from happening.  (That bug is what the
 patch below fixes.)  The URB gets added to the active list twice,
 resulting in list corruption and an oops in interrupt context, which
 freezes the system.

 The user program that triggers the problem basically looks like this:

   snd_pcm_prepare(rec_pcm);
   snd_pcm_start(rec_pcm);
   snd_pcm_drop(rec_pcm);

   snd_pcm_prepare(rec_pcm);
   snd_pcm_start(rec_pcm);

 The snd_pcm_drop call unlinks the URBs but does not wait for them to
 finish.  Then the second snd_pcm_start call submits the URBs before
 they have finished.
>>
>>
>> Thanks for investigating on this and to everyone who so quickyl tested
>> the provided patch. Seems like we got the right idea where the problem
>> really is.
>>
>> However, the proposed patch seems wrong to me (see below).
>>
 What is the right solution for this problem?
>>>
>>> How about the patch below?  (It's for 3.6, and won't be applied cleanly
>>> to 3.7, but easy to adapt.)
>>>
>>>
>>> Takashi
>>>
>>> ---
>>> diff --git a/sound/usb/endpoint.c b/sound/usb/endpoint.c
>>> index d9de667..38830e2 100644
>>> --- a/sound/usb/endpoint.c
>>> +++ b/sound/usb/endpoint.c
>>> @@ -35,6 +35,7 @@
>>>  
>>>  #define EP_FLAG_ACTIVATED  0
>>>  #define EP_FLAG_RUNNING1
>>> +#define EP_FLAG_STOPPING   2
>>>  
>>>  /*
>>>   * snd_usb_endpoint is a model that abstracts everything related to an
>>> @@ -502,10 +503,19 @@ static int wait_clear_urbs(struct snd_usb_endpoint 
>>> *ep)
>>> if (alive)
>>> snd_printk(KERN_ERR "timeout: still %d active urbs on EP #%x\n",
>>> alive, ep->ep_num);
>>> +   clear_bit(EP_FLAG_STOPPING, >flags);
>>>  
>>> return 0;
>>>  }
>>>  
>>> +/* wait until urbs are really dropped */
>>> +void snd_usb_endpoint_sync_stop(struct snd_usb_endpoint *ep)
>>> +{
>>> +   if (test_bit(EP_FLAG_STOPPING, >flags))
>>> +   wait_clear_urbs(ep);
>>> +}
>>> +
>>> +
>>>  /*
>>>   * unlink active urbs.
>>>   */
>>> @@ -913,6 +923,8 @@ void snd_usb_endpoint_stop(struct snd_usb_endpoint *ep,
>>>  
>>> if (wait)
>>> wait_clear_urbs(ep);
>>> +   else
>>> +   set_bit(EP_FLAG_STOPPING, >flags);
>>> }
>>>  }
>>>  
>>> diff --git a/sound/usb/endpoint.h b/sound/usb/endpoint.h
>>> index cbbbdf2..c1540a4 100644
>>> --- a/sound/usb/endpoint.h
>>> +++ b/sound/usb/endpoint.h
>>> @@ -16,6 +16,7 @@ int snd_usb_endpoint_set_params(struct snd_usb_endpoint 
>>> *ep,
>>>  int  snd_usb_endpoint_start(struct snd_usb_endpoint *ep, int can_sleep);
>>>  void snd_usb_endpoint_stop(struct snd_usb_endpoint *ep,
>>>int force, int can_sleep, int wait);
>>> +void snd_usb_endpoint_sync_stop(struct snd_usb_endpoint *ep);
>>>  int  snd_usb_endpoint_activate(struct snd_usb_endpoint *ep);
>>>  int  snd_usb_endpoint_deactivate(struct snd_usb_endpoint *ep);
>>>  void snd_usb_endpoint_free(struct list_head *head);
>>> diff --git a/sound/usb/pcm.c b/sound/usb/pcm.c
>>> index f782ce1..aee3ab0 100644
>>> --- a/sound/usb/pcm.c
>>> +++ b/sound/usb/pcm.c
>>> @@ -546,6 +546,11 @@ static int snd_usb_pcm_prepare(struct 
>>> snd_pcm_substream *substream)
>>> if (snd_BUG_ON(!subs->data_endpoint))
>>> return -EIO;
>>>  
>>> +   if (subs->sync_endpoint)
>>> +   snd_usb_endpoint_sync_stop(subs->sync_endpoint);
>>> +   if (subs->data_endpoint)
>>> +   snd_usb_endpoint_sync_stop(subs->data_endpoint);
>>
>> We can't simply stop both endpoints in the prepare callback.
> 
> The new function doesn't stop the 

Re: [PATCH 4/4] Staging: winbond: wb35rx_s: Fixed coding style issue

[Dan Carpenter]

It's better to use more descriptive subjects on the patches.

This one could probably have been broken into smaller patches
[patch 4/x] Staging: winbond: wb35rx_s: fix white space
[patch 5/x] Staging: winbond: wb35rx_s: fix comments
[patch 6/x] Staging: winbond: wb35rx_s: allow header to be included twice

It's small enough that I don't have strong feelings about it, but
in general that's how you should do it.

regards,
dan carpenter

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

Re: [PATCH 2/3] pwm: New driver to support PWMs on TWL4030/6030 series of PMICs

[Péter Ujfalusi]

On 11/07/2012 06:50 PM, Grazvydas Ignotas wrote:
>> +static int twl4030_pwm_enable(struct pwm_chip *chip, struct pwm_device *pwm)
>> +{
>> +   int ret;
>> +   u8 val;
>> +
>> +   ret = twl_i2c_read_u8(TWL4030_MODULE_INTBR, , TWL4030_GPBR1_REG);
>> +   if (ret < 0) {
>> +   dev_err(chip->dev, "%s: Failed to read GPBR1\n", pwm->label);
>> +   return ret;
>> +   }
>> +
>> +   val |= TWL4030_PWM_TOGGLE(pwm->hwpwm, TWL4030_PWMX_BITS);
> 
> In my experience doing it like this doesn't work reliably, i.e.
> sometimes it just won't enable. I had to first set CLK_ENABLE bit, and
> then ENABLE bit with separate i2c write. Perhaps it needs a cycle or
> two of 32k clock or something (that doesn't seem to be documented
> though).

Thanks, I'll change to the reliable sequence. I do not have HW where I can
test the twl4030 PWMs.

> 
>> +
>> +   ret = twl_i2c_write_u8(TWL4030_MODULE_INTBR, val, TWL4030_GPBR1_REG);
>> +   if (ret < 0)
>> +   dev_err(chip->dev, "%s: Failed to enable PWM\n", pwm->label);
>> +
>> +   return ret;
>> +}
>> +
>> +static void twl4030_pwm_disable(struct pwm_chip *chip, struct pwm_device 
>> *pwm)
>> +{
>> +   int ret;
>> +   u8 val;
>> +
>> +   ret = twl_i2c_read_u8(TWL4030_MODULE_INTBR, , TWL4030_GPBR1_REG);
>> +   if (ret < 0) {
>> +   dev_err(chip->dev, "%s: Failed to read GPBR1\n", pwm->label);
>> +   return;
>> +   }
>> +
>> +   val &= ~TWL4030_PWM_TOGGLE(pwm->hwpwm, TWL4030_PWMX_BITS);
> 
> Same problem here, I would sometimes get LED stuck at full brightness
> after this, first clearing ENABLE and then CLK_ENABLE fixed it (we
> have charger LED connected to PWM1 on pandora).

I would guessed that if we need special care we should have turned off CLK
followed by disabling the PWM.
I'll use the sequence you described in the next version.

> 
>> +
>> +   ret = twl_i2c_write_u8(TWL4030_MODULE_INTBR, val, TWL4030_GPBR1_REG);
>> +   if (ret < 0)
>> +   dev_err(chip->dev, "%s: Failed to disable PWM\n", 
>> pwm->label);
>> +}
>> +
>> +static int twl4030_pwm_request(struct pwm_chip *chip, struct pwm_device 
>> *pwm)
>> +{
>> +   struct twl_pwm_chip *twl = container_of(chip, struct twl_pwm_chip,
>> +   chip);
>> +   int ret;
>> +   u8 val, mask, bits;
>> +
>> +   ret = twl_i2c_read_u8(TWL4030_MODULE_INTBR, , TWL4030_PMBR1_REG);
>> +   if (ret < 0) {
>> +   dev_err(chip->dev, "%s: Failed to read PMBR1\n", pwm->label);
>> +   return ret;
>> +   }
>> +
>> +   if (pwm->hwpwm) {
>> +   /* PWM 1 */
>> +   mask = TWL4030_GPIO7_VIBRASYNC_PWM1_MASK;
>> +   bits = TWL4030_GPIO7_VIBRASYNC_PWM1_PWM1;
>> +   } else {
>> +   /* PWM 0 */
>> +   mask = TWL4030_GPIO6_PWM0_MUTE_MASK;
>> +   bits = TWL4030_GPIO6_PWM0_MUTE_PWM0;
>> +   }
>> +
>> +   /* Save the current MUX configuration for the PWM */
>> +   twl->twl4030_pwm_mux &= ~mask;
>> +   twl->twl4030_pwm_mux |= (val & mask);
> 
> Do we really need this mask clearing here? After probe twl4030_pwm_mux
> should be zero, and if twl4030_pwm_request is called twice you don't
> clear the important bits before |=, I think 'twl4030_pwm_mux = val &
> mask' would be better here.

I'm storing both PWM's state in the same variable, but in different offsets:
PWM0: bits 2-3
PWM1: bits 4-5
Probably it is over engineering to clear the relevant bits in the backup
storage, but better to be safe IMHO.
I would leave this part as it is.

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

Re: [PATCH v6 25/29] memcg/sl[au]b: shrink dead caches

[Glauber Costa]

On 11/07/2012 11:46 PM, Andrew Morton wrote:
> On Wed, 7 Nov 2012 10:22:17 +0100
> Glauber Costa  wrote:
> 
> container synchronously.  If those objects are normally left floating
> around in an allocated but reclaimable state then we can address that
> by synchronously freeing them if their container has been destroyed.
>
> Or something like that.  If it's something else then fine, but not this.
>
> What do we need to do to fix this?
>
 The original patch had a unlikely() test in the free path, conditional
 on whether or not the cache is dead, that would then call this is the
 cache would now be empty.

 I got several requests to remove it and change it to something like
 this, because that is a fast path (I myself think an unlikely branch is
 not that bad)

 If you think such a test is acceptable, I can bring it back and argue in
 the basis of "akpm made me do it!". But meanwhile I will give this extra
 though to see if there is any alternative way I can do it...
>>>
>>> OK, thanks, please do take a look at it.
>>>
>>> I'd be interested in seeing the old version of the patch which had this
>>> test-n-branch.  Perhaps there's some trick we can pull to lessen its cost.
>>>
>> Attached.
>>
>> This is the last version that used it (well, I believe it is). There is
>> other unrelated things in this patch, that I got rid of. Look for
>> kmem_cache_verify_dead().
>>
>> In a summary, all calls to the free function would as a last step do:
>> kmem_cache_verify_dead() that would either be an empty placeholder, or:
>>
>> +static inline void kmem_cache_verify_dead(struct kmem_cache *s)
>> +{
>> +   if (unlikely(s->memcg_params.dead))
>> +   schedule_work(>memcg_params.cache_shrinker);
>> +}
> 
> hm, a few things.
> 
> What's up with kmem_cache_shrink?  It's global and exported to modules
> but its only external caller is some weird and hopelessly poorly
> documented site down in drivers/acpi/osl.c.  slab and slob implement
> kmem_cache_shrink() *only* for acpi!  wtf?  Let's work out what acpi is
> trying to actually do there, then do it properly, then killkillkill!
> 
> Secondly, as slab and slub (at least) have the ability to shed cached
> memory, why aren't they hooked into the core cache-shinking machinery. 
> After all, it's called "shrink_slab"!
> 
> 
> If we can fix all that up then I wonder whether this particular patch
> needs to exist at all.  If the kmem_cache is no longer used then we
> can simply leave it floating around in memory and the regular cache
> shrinking code out of shrink_slab() will clean up any remaining pages. 
> The kmem_cache itself can be reclaimed via another shrinker, if
> necessary?
> 

So my motivation here, is that when you free the last object on a cache,
or even the last object on a specific page, it won't necessarily free
the page.

The page is left there in the system, until kmem_cache_shrink is called.
Because I am taking action on pages, not objects, I would like them to
be released, so I know the cache went down,  and I can destroy it. As a
matter of fact, at least the slub, when kmem_cache_destroy is explicitly
called, will call flush_slab, which is pretty much the core of
kmem_cache_shrink().

shrink_slab() will only call into caches with a registered shrinker, so
my fear was that if I don't call kmem_cache_shrink() explicitly, that
memory may not ever be released.

If you have any idea about to fix that, I am all years. I don't actually
like this patch very much, it was a PITA to get right =(
I will love to ditch it.

Maybe we can do this from vmscan.c? It would be still calling the same
function, we don't get any beauty points for that, but at least it is
done in a place that makes sense
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [RFC PATCH v1 08/31] ARC: Fundamental ARCH data-types/defines

[Jonas Bonn]

On 7 November 2012 10:47, Vineet Gupta  wrote:
> diff --git a/arch/arc/include/asm/ptrace.h b/arch/arc/include/asm/ptrace.h
> new file mode 100644
> index 000..c178357
> --- /dev/null
> +++ b/arch/arc/include/asm/ptrace.h
> @@ -0,0 +1,120 @@
> +/* THE pt_regs: Defines how regs are saved during entry into kernel */
> +
> +struct pt_regs {

I'd recommend not exporting the pt_regs structure to userspace.  This
struct is used heavily within the kernel and it's nice to have the
leeway to be able to modify it as things evolve.  GDB doesn't need to
know about this struct anymore as it should be using regset's for any
recent architectures anyway, so it's the regset layout that should be
ABI stable instead of pt_regs.

You can check the openrisc architecture as an example of how to do this.

/Jonas
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] gpio: mvebu: Set free callback for gpio_chip

[Thomas Petazzoni]

On Thu, 08 Nov 2012 10:27:29 +0800, Axel Lin wrote:
> We call pinctrl_request_gpio() in request callback, thus we need to call
> pinctrl_free_gpio() in free callback.
> 
> Both mvebu_gpio_request() and mvebu_gpio_free() are not referenced outside of
> this file, make them static.

Indeed, thanks.

> Signed-off-by: Axel Lin 

Acked-by: Thomas Petazzoni 
-- 
Thomas Petazzoni, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.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 v5] staging: ste_rmi4: Convert to Type-B support

[Alexandra Chin]

Convert to MT-B because Synaptics touch devices are capable
of tracking identifiable fingers.

Signed-off-by: Alexandra Chin 
---
Changes from v5:
- Incorporated Henrik's review comments
  *rollback to v3 from v4
  *fix odd line break in v3
- Include Alexandra in the list of authors

Changes from v4:
- Incorporated Henrik's review comments
  *split function synpatics_rmi4_touchscreen_report
  *split function synaptics_rmi4_i2c_query_device

Changes from v3:
- Incorporated Henrik's review comments
  *remove 'else' after an error path return
  *add input_mt_sync_frame() for pointer emulation effects
  *correct names of touchscreen
- Replace printk with dev_err

Changes from v2:
- Incorporated Henrik's review comments
  *directly report finger state with Type-B
- Against 3.7-rcX
  *call input_mt_init_slots with INPUT_MT_DIRECT flag
---
 drivers/staging/ste_rmi4/synaptics_i2c_rmi4.c |  245 -
 1 files changed, 114 insertions(+), 131 deletions(-)

diff --git a/drivers/staging/ste_rmi4/synaptics_i2c_rmi4.c 
b/drivers/staging/ste_rmi4/synaptics_i2c_rmi4.c
index 277491a..7b636c7 100644
--- a/drivers/staging/ste_rmi4/synaptics_i2c_rmi4.c
+++ b/drivers/staging/ste_rmi4/synaptics_i2c_rmi4.c
@@ -1,10 +1,11 @@
 /**
  *
- * Synaptics Register Mapped Interface (RMI4) I2C Physical Layer Driver.
- * Copyright (c) 2007-2010, Synaptics Incorporated
+ * Synaptics Register Mapped Interface (RMI4) I2C Touchscreen Driver.
+ * Copyright (c) 2007-2012, Synaptics Incorporated
  *
  * Author: Js HA  for ST-Ericsson
  * Author: Naveen Kumar G  for ST-Ericsson
+ * Author: Alexandra Chin 
  * Copyright 2010 (c) ST-Ericsson AB
  */
 /*
@@ -31,6 +32,7 @@
 #include 
 #include 
 #include 
+#include 
 #include "synaptics_i2c_rmi4.h"
 
 /* TODO: for multiple device support will need a per-device mutex */
@@ -63,12 +65,11 @@
 #define MASK_4BIT  0x0F
 #define MASK_3BIT  0x07
 #define MASK_2BIT  0x03
-#define TOUCHPAD_CTRL_INTR 0x8
+#define TOUCHSCREEN_CTRL_INTR  0x8
 #define PDT_START_SCAN_LOCATION (0x00E9)
 #define PDT_END_SCAN_LOCATION  (0x000A)
 #define PDT_ENTRY_SIZE (0x0006)
-#define RMI4_NUMBER_OF_MAX_FINGERS (8)
-#define SYNAPTICS_RMI4_TOUCHPAD_FUNC_NUM   (0x11)
+#define SYNAPTICS_RMI4_TOUCHSCREEN_FUNC_NUM(0x11)
 #define SYNAPTICS_RMI4_DEVICE_CONTROL_FUNC_NUM (0x01)
 
 /**
@@ -164,6 +165,7 @@ struct synaptics_rmi4_device_info {
  * @regulator: pointer to the regulator structure
  * @wait: wait queue structure variable
  * @touch_stopped: flag to stop the thread function
+ * @fingers_supported: maximum supported fingers
  *
  * This structure gives the device data information.
  */
@@ -184,6 +186,7 @@ struct synaptics_rmi4_data {
struct regulator*regulator;
wait_queue_head_t   wait;
booltouch_stopped;
+   unsigned char   fingers_supported;
 };
 
 /**
@@ -291,34 +294,33 @@ exit:
 }
 
 /**
- * synpatics_rmi4_touchpad_report() - reports for the rmi4 touchpad device
+ * synpatics_rmi4_touchscreen_report() - reports for the rmi4 touchscreen 
device
  * @pdata: pointer to synaptics_rmi4_data structure
  * @rfi: pointer to synaptics_rmi4_fn structure
  *
- * This function calls to reports for the rmi4 touchpad device
+ * This function calls to reports for the rmi4 touchscreen device
  */
-static int synpatics_rmi4_touchpad_report(struct synaptics_rmi4_data *pdata,
+static int synpatics_rmi4_touchscreen_report(struct synaptics_rmi4_data *pdata,
struct synaptics_rmi4_fn *rfi)
 {
/* number of touch points - fingers down in this case */
int touch_count = 0;
int finger;
-   int fingers_supported;
int finger_registers;
int reg;
int finger_shift;
int finger_status;
int retval;
+   int x, y;
+   int wx, wy;
unsigned short  data_base_addr;
unsigned short  data_offset;
unsigned char   data_reg_blk_size;
unsigned char   values[2];
unsigned char   data[DATA_LEN];
-   int x[RMI4_NUMBER_OF_MAX_FINGERS];
-   int y[RMI4_NUMBER_OF_MAX_FINGERS];
-   int wx[RMI4_NUMBER_OF_MAX_FINGERS];
-   int wy[RMI4_NUMBER_OF_MAX_FINGERS];
+   unsigned char   fingers_supported = pdata->fingers_supported;
struct  i2c_client *client = pdata->i2c_client;
+   struct  input_dev *input_dev = pdata->input_dev;
 
/* get 2D sensor finger data */
/*
@@ -333,7 +335,6 @@ static int synpatics_rmi4_touchpad_report(struct 
synaptics_rmi4_data *pdata,
 *  10 = finger present but data may not be accurate,
 *  11 = reserved for product use.
 */
-   fingers_supported   = rfi->num_of_data_points;

Re: [RFC PATCH 00/19] Foundation for automatic NUMA balancing

[Zhouping Liu]

On 11/08/2012 02:39 PM, 杨竹 wrote:
> Hi all:
>   I got a problem：
>   1. on intel cpu xeon E5000 family which support xapic ，one NIC
> irq  can share on the CPUs basic on smp_affinity.
>   2. but on intel cpu xeon E5-2600 family which support x2apic, one
> NIC irq only on CPU0 whatever  i set the smp_affinfiy like as "aa"; "55";
> "ff".
>  My OS is CentOS 6.2  x32 ，i test 4 cpus。 the result is which only
> support apic can share one irq to all cpus，which support x2apic only make
> the irq to one cpu。

richard, I'm not sure whether your problem is occurred with the
patch-set or not,
if it's not related to the patches, you should report it on a *new* subject.

Thanks,
Zhouping

>
>
> want help me
>
>  richard
>
>
> 2012/11/8 Zhouping Liu 
>
>> On 11/07/2012 11:25 PM, Mel Gorman wrote:
>>
>>> On Wed, Nov 07, 2012 at 05:27:12PM +0800, Zhouping Liu wrote:
>>>
 Hello Mel,

 my 2 nodes machine hit a panic fault after applied the patch
 set(based on kernel-3.7.0-rc4), please review it:

 

>>> Early initialisation problem by the looks of things. Try this please
>>>
>> Tested the patch, and the issue is gone.
>>
>>
>>> ---8<---
>>> mm: numa: Check that preferred_node_policy is initialised
>>>
>>> Zhouping Liu reported the following
>>>
>>> [ 0.00] [ cut here ]
>>> [ 0.00] kernel BUG at mm/mempolicy.c:1785!
>>> [ 0.00] invalid opcode:  [#1] SMP
>>> [ 0.00] Modules linked in:
>>> [ 0.00] CPU 0
>>> 
>>> [0.00] Call Trace:
>>> [0.00] [] alloc_pages_current+0xa6/0x170
>>> [0.00] [] __get_free_pages+0x14/0x50
>>> [0.00] [] kmem_cache_init+0x53/0x2d2
>>> [0.00] [] start_kernel+0x1e0/0x3c7
>>>
>>> Problem is that early in boot preferred_nod_policy and SLUB
>>> initialisation trips up. Check it is initialised.
>>>
>>> Signed-off-by: Mel Gorman 
>>>
>> Tested-by: Zhouping Liu 
>>
>> Thanks,
>> Zhouping
>>
>>  ---
>>>   mm/mempolicy.c |4 
>>>   1 file changed, 4 insertions(+)
>>>
>>> diff --git a/mm/mempolicy.c b/mm/mempolicy.c
>>> index 11d4b6b..8cfa6dc 100644
>>> --- a/mm/mempolicy.c
>>> +++ b/mm/mempolicy.c
>>> @@ -129,6 +129,10 @@ static struct mempolicy *get_task_policy(struct
>>> task_struct *p)
>>> node = numa_node_id();
>>> if (node != -1)
>>> pol = _node_policy[node];
>>> +
>>> +   /* preferred_node_policy is not initialised early in boot
>>> */
>>> +   if (!pol->mode)
>>> +   pol = NULL;
>>> }
>>> return pol;
>>>
>>> --
>>> To unsubscribe, send a message with 'unsubscribe linux-mm' in
>>> the body to majord...@kvack.org.  For more info on Linux MM,
>>> see: http://www.linux-mm.org/ .
>>> Don't email: mailto:"d...@kvack.org;> em...@kvack.org 
>>>
>> --
>> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
>> the body of a message to majord...@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/

[PATCH] mm: remove watermark hacks for CMA

[Marek Szyprowski]

Commits 2139cbe627b89 ("cma: fix counting of isolated pages") and
d95ea5d18e69951 ("cma: fix watermark checking") introduced a reliable
method of free page accounting when memory is being allocated from CMA
regions, so the workaround introduced earlier by commit 49f223a9cd96c72
("mm: trigger page reclaim in alloc_contig_range() to stabilise
watermarks") can be finally removed.

Signed-off-by: Marek Szyprowski 
---
 include/linux/mmzone.h |9 
 mm/page_alloc.c|   57 
 2 files changed, 66 deletions(-)

diff --git a/include/linux/mmzone.h b/include/linux/mmzone.h
index c9fcd8f..f010b23 100644
--- a/include/linux/mmzone.h
+++ b/include/linux/mmzone.h
@@ -63,10 +63,8 @@ enum {
 
 #ifdef CONFIG_CMA
 #  define is_migrate_cma(migratetype) unlikely((migratetype) == MIGRATE_CMA)
-#  define cma_wmark_pages(zone)zone->min_cma_pages
 #else
 #  define is_migrate_cma(migratetype) false
-#  define cma_wmark_pages(zone) 0
 #endif
 
 #define for_each_migratetype_order(order, type) \
@@ -372,13 +370,6 @@ struct zone {
/* see spanned/present_pages for more description */
seqlock_t   span_seqlock;
 #endif
-#ifdef CONFIG_CMA
-   /*
-* CMA needs to increase watermark levels during the allocation
-* process to make sure that the system is not starved.
-*/
-   unsigned long   min_cma_pages;
-#endif
struct free_areafree_area[MAX_ORDER];
 
 #ifndef CONFIG_SPARSEMEM
diff --git a/mm/page_alloc.c b/mm/page_alloc.c
index 43ab09f..5028a18 100644
--- a/mm/page_alloc.c
+++ b/mm/page_alloc.c
@@ -5217,10 +5217,6 @@ static void __setup_per_zone_wmarks(void)
zone->watermark[WMARK_LOW]  = min_wmark_pages(zone) + (tmp >> 
2);
zone->watermark[WMARK_HIGH] = min_wmark_pages(zone) + (tmp >> 
1);
 
-   zone->watermark[WMARK_MIN] += cma_wmark_pages(zone);
-   zone->watermark[WMARK_LOW] += cma_wmark_pages(zone);
-   zone->watermark[WMARK_HIGH] += cma_wmark_pages(zone);
-
setup_zone_migrate_reserve(zone);
spin_unlock_irqrestore(>lock, flags);
}
@@ -5765,54 +5761,6 @@ static int __alloc_contig_migrate_range(struct 
compact_control *cc,
return ret > 0 ? 0 : ret;
 }
 
-/*
- * Update zone's cma pages counter used for watermark level calculation.
- */
-static inline void __update_cma_watermarks(struct zone *zone, int count)
-{
-   unsigned long flags;
-   spin_lock_irqsave(>lock, flags);
-   zone->min_cma_pages += count;
-   spin_unlock_irqrestore(>lock, flags);
-   setup_per_zone_wmarks();
-}
-
-/*
- * Trigger memory pressure bump to reclaim some pages in order to be able to
- * allocate 'count' pages in single page units. Does similar work as
- *__alloc_pages_slowpath() function.
- */
-static int __reclaim_pages(struct zone *zone, gfp_t gfp_mask, int count)
-{
-   enum zone_type high_zoneidx = gfp_zone(gfp_mask);
-   struct zonelist *zonelist = node_zonelist(0, gfp_mask);
-   int did_some_progress = 0;
-   int order = 1;
-
-   /*
-* Increase level of watermarks to force kswapd do his job
-* to stabilise at new watermark level.
-*/
-   __update_cma_watermarks(zone, count);
-
-   /* Obey watermarks as if the page was being allocated */
-   while (!zone_watermark_ok(zone, 0, low_wmark_pages(zone), 0, 0)) {
-   wake_all_kswapd(order, zonelist, high_zoneidx, zone_idx(zone));
-
-   did_some_progress = __perform_reclaim(gfp_mask, order, zonelist,
- NULL);
-   if (!did_some_progress) {
-   /* Exhausted what can be done so it's blamo time */
-   out_of_memory(zonelist, gfp_mask, order, NULL, false);
-   }
-   }
-
-   /* Restore original watermark levels. */
-   __update_cma_watermarks(zone, -count);
-
-   return count;
-}
-
 /**
  * alloc_contig_range() -- tries to allocate given range of pages
  * @start: start PFN to allocate
@@ -5921,11 +5869,6 @@ int alloc_contig_range(unsigned long start, unsigned 
long end,
goto done;
}
 
-   /*
-* Reclaim enough pages to make sure that contiguous allocation
-* will not starve the system.
-*/
-   __reclaim_pages(zone, GFP_HIGHUSER_MOVABLE, end-start);
 
/* Grab isolated pages from freelists. */
outer_end = isolate_freepages_range(, outer_start, end);
-- 
1.7.9.5

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

[PATCH] mm: skip watermarks check for already isolated blocks in split_free_page()

[Marek Szyprowski]

Since commit 2139cbe627b8 ("cma: fix counting of isolated pages") free
pages in isolated pageblocks are not accounted to NR_FREE_PAGES counters,
so watermarks check is not required if one operates on a free page in
isolated pageblock.

Signed-off-by: Marek Szyprowski 
---
 mm/page_alloc.c |   10 ++
 1 file changed, 6 insertions(+), 4 deletions(-)

diff --git a/mm/page_alloc.c b/mm/page_alloc.c
index fd154fe..43ab09f 100644
--- a/mm/page_alloc.c
+++ b/mm/page_alloc.c
@@ -1394,10 +1394,12 @@ int capture_free_page(struct page *page, int 
alloc_order, int migratetype)
zone = page_zone(page);
order = page_order(page);
 
-   /* Obey watermarks as if the page was being allocated */
-   watermark = low_wmark_pages(zone) + (1 << order);
-   if (!zone_watermark_ok(zone, 0, watermark, 0, 0))
-   return 0;
+   if (get_pageblock_migratetype(page) != MIGRATE_ISOLATE) {
+   /* Obey watermarks as if the page was being allocated */
+   watermark = low_wmark_pages(zone) + (1 << order);
+   if (!zone_watermark_ok(zone, 0, watermark, 0, 0))
+   return 0;
+   }
 
/* Remove page from free list */
list_del(>lru);
-- 
1.7.9.5

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

[PATCH 1/1] v3.0.x: mtd: check partition count not partition array pointer

[Anthony Foiani]

mtd: check partition count not partition array pointer

The documentation claims that "nr_parts" is the determining factor,
while the code originally tested whether "parts" is non-null.

In at least one driver (fsl_elbc_nand), parts is never initialized to
0; even though nr_parts is correctly 0, add_mtd_partitions still tries
to create 0 partitions.)

Make the code adhere to the documentation.

A quick scan of all uses in the 3.0.51 kernel show that they correctly
rely on nr_parts rather than parts.

The current kernel has retired this function; I have not examined its
replacement to see if it has the same issue.

Signed-Off-By: Anthony Foiani 
---
 drivers/mtd/mtdcore.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/mtd/mtdcore.c b/drivers/mtd/mtdcore.c
index c510aff..ac624df 100644
--- a/drivers/mtd/mtdcore.c
+++ b/drivers/mtd/mtdcore.c
@@ -446,7 +446,7 @@ int mtd_device_register(struct mtd_info *master,
const struct mtd_partition *parts,
int nr_parts)
 {
-   return parts ? add_mtd_partitions(master, parts, nr_parts) :
+   return nr_parts ? add_mtd_partitions(master, parts, nr_parts) :
add_mtd_device(master);
 }
 EXPORT_SYMBOL_GPL(mtd_device_register);
--
1.7.11.7

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

Re: [PATCH v6 28/29] slub: slub-specific propagation changes.

[Glauber Costa]

On 11/07/2012 04:53 PM, Sasha Levin wrote:
> On 11/01/2012 08:07 AM, Glauber Costa wrote:
>> SLUB allows us to tune a particular cache behavior with sysfs-based
>> tunables.  When creating a new memcg cache copy, we'd like to preserve
>> any tunables the parent cache already had.
>>
>> This can be done by tapping into the store attribute function provided
>> by the allocator. We of course don't need to mess with read-only
>> fields. Since the attributes can have multiple types and are stored
>> internally by sysfs, the best strategy is to issue a ->show() in the
>> root cache, and then ->store() in the memcg cache.
>>
>> The drawback of that, is that sysfs can allocate up to a page in
>> buffering for show(), that we are likely not to need, but also can't
>> guarantee. To avoid always allocating a page for that, we can update the
>> caches at store time with the maximum attribute size ever stored to the
>> root cache. We will then get a buffer big enough to hold it. The
>> corolary to this, is that if no stores happened, nothing will be
>> propagated.
>>
>> It can also happen that a root cache has its tunables updated during
>> normal system operation. In this case, we will propagate the change to
>> all caches that are already active.
>>
>> Signed-off-by: Glauber Costa 
>> CC: Christoph Lameter 
>> CC: Pekka Enberg 
>> CC: Michal Hocko 
>> CC: Kamezawa Hiroyuki 
>> CC: Johannes Weiner 
>> CC: Suleiman Souhlal 
>> CC: Tejun Heo 
>> ---
> 
> Hi guys,
> 
> This patch is making lockdep angry! *bark bark*
> 
> [  351.935003] ==
> [  351.937693] [ INFO: possible circular locking dependency detected ]
> [  351.939720] 3.7.0-rc4-next-20121106-sasha-8-g353b62f #117 Tainted: G   
>  W
> [  351.942444] ---
> [  351.943528] trinity-child13/6961 is trying to acquire lock:
> [  351.943528]  (s_active#43){.+}, at: [] 
> sysfs_addrm_finish+0x31/0x60
> [  351.943528]
> [  351.943528] but task is already holding lock:
> [  351.943528]  (slab_mutex){+.+.+.}, at: [] 
> kmem_cache_destroy+0x22/0xe0
> [  351.943528]
> [  351.943528] which lock already depends on the new lock.
> [  351.943528]
> [  351.943528]
> [  351.943528] the existing dependency chain (in reverse order) is:
> [  351.943528]
> -> #1 (slab_mutex){+.+.+.}:
> [  351.960334][] lock_acquire+0x1aa/0x240
> [  351.960334][] __mutex_lock_common+0x59/0x5a0
> [  351.960334][] mutex_lock_nested+0x3f/0x50
> [  351.960334][] slab_attr_store+0xde/0x110
> [  351.960334][] sysfs_write_file+0xfa/0x150
> [  351.960334][] vfs_write+0xb0/0x180
> [  351.960334][] sys_pwrite64+0x60/0xb0
> [  351.960334][] tracesys+0xe1/0xe6
> [  351.960334]
> -> #0 (s_active#43){.+}:
> [  351.960334][] __lock_acquire+0x14df/0x1ca0
> [  351.960334][] lock_acquire+0x1aa/0x240
> [  351.960334][] sysfs_deactivate+0x122/0x1a0
> [  351.960334][] sysfs_addrm_finish+0x31/0x60
> [  351.960334][] sysfs_remove_dir+0x89/0xd0
> [  351.960334][] kobject_del+0x16/0x40
> [  351.960334][] __kmem_cache_shutdown+0x40/0x60
> [  351.960334][] kmem_cache_destroy+0x40/0xe0
> [  351.960334][] mon_text_release+0x78/0xe0
> [  351.960334][] __fput+0x122/0x2d0
> [  351.960334][] fput+0x9/0x10
> [  351.960334][] task_work_run+0xbe/0x100
> [  351.960334][] do_exit+0x432/0xbd0
> [  351.960334][] do_group_exit+0x84/0xd0
> [  351.960334][] get_signal_to_deliver+0x81d/0x930
> [  351.960334][] do_signal+0x3a/0x950
> [  351.960334][] do_notify_resume+0x3e/0x90
> [  351.960334][] int_signal+0x12/0x17
> [  351.960334]
> [  351.960334] other info that might help us debug this:
> [  351.960334]
> [  351.960334]  Possible unsafe locking scenario:
> [  351.960334]
> [  351.960334]CPU0CPU1
> [  351.960334]
> [  351.960334]   lock(slab_mutex);
> [  351.960334]lock(s_active#43);
> [  351.960334]lock(slab_mutex);
> [  351.960334]   lock(s_active#43);
> [  351.960334]
> [  351.960334]  *** DEADLOCK ***
> [  351.960334]
> [  351.960334] 2 locks held by trinity-child13/6961:
> [  351.960334]  #0:  (mon_lock){+.+.+.}, at: [] 
> mon_text_release+0x25/0xe0
> [  351.960334]  #1:  (slab_mutex){+.+.+.}, at: [] 
> kmem_cache_destroy+0x22/0xe0
> [  351.960334]
> [  351.960334] stack backtrace:
> [  351.960334] Pid: 6961, comm: trinity-child13 Tainted: GW
> 3.7.0-rc4-next-20121106-sasha-8-g353b62f #117
> [  351.960334] Call Trace:
> [  351.960334]  [] print_circular_bug+0x1fb/0x20c
> [  351.960334]  [] __lock_acquire+0x14df/0x1ca0
> [  351.960334]  [] ? debug_check_no_locks_freed+0x185/0x1e0
> [  351.960334]  [] lock_acquire+0x1aa/0x240
> [  351.960334]  [] ? 

Re: A reliable kernel panic (3.6.2) and system crash when visiting a particular website

[Takashi Iwai]

At Wed, 7 Nov 2012 15:37:17 -0500 (EST),
Alan Stern wrote:
> 
> On Wed, 7 Nov 2012, Takashi Iwai wrote:
> 
> > > What is the right solution for this problem?
> > 
> > How about the patch below?  (It's for 3.6, and won't be applied cleanly
> > to 3.7, but easy to adapt.)
> 
> I simplified your patch a little.

You can't drop the check of stopping endpoint.  As Daniel pointed,
endpoints might be still running when it's called.  I already did a
similar failure in the past, so this patch is a revised version with
the check for pending operations.

>  This is for 3.7, not 3.6.  I 
> verified that it does fix the problem raised by the test program.
> 
> If you think this is okay, I'll submit it officially.

Don't worry, my patch is also based on 3.7, too :)  3.6 patch was
provided just for convenience, testers seemed to have 3.6 systems.


thanks,

Takashi

> 
> Alan Stern
> 
> 
> 
> Index: usb-3.7/sound/usb/endpoint.h
> ===
> --- usb-3.7.orig/sound/usb/endpoint.h
> +++ usb-3.7/sound/usb/endpoint.h
> @@ -19,6 +19,7 @@ int snd_usb_endpoint_set_params(struct s
>  int  snd_usb_endpoint_start(struct snd_usb_endpoint *ep, int can_sleep);
>  void snd_usb_endpoint_stop(struct snd_usb_endpoint *ep,
>  int force, int can_sleep, int wait);
> +void snd_usb_endpoint_sync_stop(struct snd_usb_endpoint *ep);
>  int  snd_usb_endpoint_activate(struct snd_usb_endpoint *ep);
>  int  snd_usb_endpoint_deactivate(struct snd_usb_endpoint *ep);
>  void snd_usb_endpoint_free(struct list_head *head);
> Index: usb-3.7/sound/usb/pcm.c
> ===
> --- usb-3.7.orig/sound/usb/pcm.c
> +++ usb-3.7/sound/usb/pcm.c
> @@ -576,6 +576,11 @@ static int snd_usb_pcm_prepare(struct sn
>   subs->need_setup_ep = false;
>   }
>  
> + if (subs->sync_endpoint)
> + snd_usb_endpoint_sync_stop(subs->sync_endpoint);
> + if (subs->data_endpoint)
> + snd_usb_endpoint_sync_stop(subs->data_endpoint);
> +
>   /* some unit conversions in runtime */
>   subs->data_endpoint->maxframesize =
>   bytes_to_frames(runtime, subs->data_endpoint->maxpacksize);
> Index: usb-3.7/sound/usb/endpoint.c
> ===
> --- usb-3.7.orig/sound/usb/endpoint.c
> +++ usb-3.7/sound/usb/endpoint.c
> @@ -481,7 +481,7 @@ __exit_unlock:
>  /*
>   *  wait until all urbs are processed.
>   */
> -static int wait_clear_urbs(struct snd_usb_endpoint *ep)
> +void snd_usb_endpoint_sync_stop(struct snd_usb_endpoint *ep)
>  {
>   unsigned long end_time = jiffies + msecs_to_jiffies(1000);
>   unsigned int i;
> @@ -502,8 +502,6 @@ static int wait_clear_urbs(struct snd_us
>   if (alive)
>   snd_printk(KERN_ERR "timeout: still %d active urbs on EP #%x\n",
>   alive, ep->ep_num);
> -
> - return 0;
>  }
>  
>  /*
> @@ -556,7 +554,7 @@ static void release_urbs(struct snd_usb_
>  
>   /* stop urbs */
>   deactivate_urbs(ep, force, 1);
> - wait_clear_urbs(ep);
> + snd_usb_endpoint_sync_stop(ep);
>  
>   for (i = 0; i < ep->nurbs; i++)
>   release_urb_ctx(>urb[i]);
> @@ -833,7 +831,7 @@ int snd_usb_endpoint_start(struct snd_us
>   /* just to be sure */
>   deactivate_urbs(ep, 0, can_sleep);
>   if (can_sleep)
> - wait_clear_urbs(ep);
> + snd_usb_endpoint_sync_stop(ep);
>  
>   ep->active_mask = 0;
>   ep->unlink_mask = 0;
> @@ -917,7 +915,7 @@ void snd_usb_endpoint_stop(struct snd_us
>   ep->prepare_data_urb = NULL;
>  
>   if (wait)
> - wait_clear_urbs(ep);
> + snd_usb_endpoint_sync_stop(ep);
>   }
>  }
>  
> @@ -940,7 +938,7 @@ int snd_usb_endpoint_deactivate(struct s
>   return -EINVAL;
>  
>   deactivate_urbs(ep, 1, 1);
> - wait_clear_urbs(ep);
> + snd_usb_endpoint_sync_stop(ep);
>  
>   if (ep->use_count != 0)
>   return 0;
> 
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH]backlight: lm3639: fix coccinelle warning.

[G.Shark Jeong]

From: "G.Shark Jeong" 

Fix coccinelle warning.

Signed-off-by: G.Shark Jeong 
---
 drivers/video/backlight/lm3639_bl.c |4 ++--
 1 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/video/backlight/lm3639_bl.c 
b/drivers/video/backlight/lm3639_bl.c
index 585949b..868a9da 100644
--- a/drivers/video/backlight/lm3639_bl.c
+++ b/drivers/video/backlight/lm3639_bl.c
@@ -403,9 +403,9 @@ static int __devexit lm3639_remove(struct i2c_client 
*client)
 
regmap_write(pchip->regmap, REG_ENABLE, 0x00);
 
-   if (>cdev_torch)
+   if ((>cdev_torch)!=NULL)
led_classdev_unregister(>cdev_torch);
-   if (>cdev_flash)
+   if ((>cdev_flash)!=NULL)
led_classdev_unregister(>cdev_flash);
if (pchip->bled) {
device_remove_file(&(pchip->bled->dev), _attr_bled_mode);
-- 
1.7.5.4

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

Re: A reliable kernel panic (3.6.2) and system crash when visiting a particular website

[Takashi Iwai]

At Thu, 08 Nov 2012 01:42:59 +0100,
Daniel Mack wrote:
> 
> On 07.11.2012 20:19, Takashi Iwai wrote:
> > At Wed, 7 Nov 2012 12:34:43 -0500 (EST),
> > Alan Stern wrote:
> >>
> >> On Mon, 5 Nov 2012, Christof Meerwald wrote:
> >>
> >>> BTW, I have been able to reproduce the problem on a completely
> >>> different machine (also running Ubuntu 12.10, but different hardware).
> >>> The important thing appears to be that the USB audio device is
> >>> connected via a USB 2.0 hub (and then using the test code posted in
> >>> http://pastebin.com/aHGe1S1X specifying the audio device as
> >>> "plughw:Set" (or whatever it's called) seems to trigger the freeze).
> >>
> >> Christof: Thank you for that reference, it was a big help.  After
> >> crashing my system many times I have tracked the problem, at least in
> >> part.  The patch below should prevent your system from freezing.
> >>
> >>
> >> Takashi: It turns out the the problem is triggered when the audio
> >> subsystem calls snd_usb_endpoint_stop() with wait == 0 and then calls
> >> snd_usb_endpoint_start().  Since the driver doesn't wait for the
> >> outstanding URBs to finish, it tries to submit them again while they
> >> are still active.
> >>
> >> Normally the USB core would realize this and fail the submission, but a
> >> bug in ehci-hcd prevented this from happening.  (That bug is what the
> >> patch below fixes.)  The URB gets added to the active list twice,
> >> resulting in list corruption and an oops in interrupt context, which
> >> freezes the system.
> >>
> >> The user program that triggers the problem basically looks like this:
> >>
> >>   snd_pcm_prepare(rec_pcm);
> >>   snd_pcm_start(rec_pcm);
> >>   snd_pcm_drop(rec_pcm);
> >>
> >>   snd_pcm_prepare(rec_pcm);
> >>   snd_pcm_start(rec_pcm);
> >>
> >> The snd_pcm_drop call unlinks the URBs but does not wait for them to
> >> finish.  Then the second snd_pcm_start call submits the URBs before
> >> they have finished.
> 
> 
> Thanks for investigating on this and to everyone who so quickyl tested
> the provided patch. Seems like we got the right idea where the problem
> really is.
> 
> However, the proposed patch seems wrong to me (see below).
> 
> >> What is the right solution for this problem?
> > 
> > How about the patch below?  (It's for 3.6, and won't be applied cleanly
> > to 3.7, but easy to adapt.)
> > 
> > 
> > Takashi
> > 
> > ---
> > diff --git a/sound/usb/endpoint.c b/sound/usb/endpoint.c
> > index d9de667..38830e2 100644
> > --- a/sound/usb/endpoint.c
> > +++ b/sound/usb/endpoint.c
> > @@ -35,6 +35,7 @@
> >  
> >  #define EP_FLAG_ACTIVATED  0
> >  #define EP_FLAG_RUNNING1
> > +#define EP_FLAG_STOPPING   2
> >  
> >  /*
> >   * snd_usb_endpoint is a model that abstracts everything related to an
> > @@ -502,10 +503,19 @@ static int wait_clear_urbs(struct snd_usb_endpoint 
> > *ep)
> > if (alive)
> > snd_printk(KERN_ERR "timeout: still %d active urbs on EP #%x\n",
> > alive, ep->ep_num);
> > +   clear_bit(EP_FLAG_STOPPING, >flags);
> >  
> > return 0;
> >  }
> >  
> > +/* wait until urbs are really dropped */
> > +void snd_usb_endpoint_sync_stop(struct snd_usb_endpoint *ep)
> > +{
> > +   if (test_bit(EP_FLAG_STOPPING, >flags))
> > +   wait_clear_urbs(ep);
> > +}
> > +
> > +
> >  /*
> >   * unlink active urbs.
> >   */
> > @@ -913,6 +923,8 @@ void snd_usb_endpoint_stop(struct snd_usb_endpoint *ep,
> >  
> > if (wait)
> > wait_clear_urbs(ep);
> > +   else
> > +   set_bit(EP_FLAG_STOPPING, >flags);
> > }
> >  }
> >  
> > diff --git a/sound/usb/endpoint.h b/sound/usb/endpoint.h
> > index cbbbdf2..c1540a4 100644
> > --- a/sound/usb/endpoint.h
> > +++ b/sound/usb/endpoint.h
> > @@ -16,6 +16,7 @@ int snd_usb_endpoint_set_params(struct snd_usb_endpoint 
> > *ep,
> >  int  snd_usb_endpoint_start(struct snd_usb_endpoint *ep, int can_sleep);
> >  void snd_usb_endpoint_stop(struct snd_usb_endpoint *ep,
> >int force, int can_sleep, int wait);
> > +void snd_usb_endpoint_sync_stop(struct snd_usb_endpoint *ep);
> >  int  snd_usb_endpoint_activate(struct snd_usb_endpoint *ep);
> >  int  snd_usb_endpoint_deactivate(struct snd_usb_endpoint *ep);
> >  void snd_usb_endpoint_free(struct list_head *head);
> > diff --git a/sound/usb/pcm.c b/sound/usb/pcm.c
> > index f782ce1..aee3ab0 100644
> > --- a/sound/usb/pcm.c
> > +++ b/sound/usb/pcm.c
> > @@ -546,6 +546,11 @@ static int snd_usb_pcm_prepare(struct 
> > snd_pcm_substream *substream)
> > if (snd_BUG_ON(!subs->data_endpoint))
> > return -EIO;
> >  
> > +   if (subs->sync_endpoint)
> > +   snd_usb_endpoint_sync_stop(subs->sync_endpoint);
> > +   if (subs->data_endpoint)
> > +   snd_usb_endpoint_sync_stop(subs->data_endpoint);
> 
> We can't simply stop both endpoints in the prepare callback.

The new function doesn't stop the stream by itself but it just syncs
if the stream is 

Re: PT_EXITKILL (Was: pdeath_signal)

[Amnon Shiloh]

Dear Oleg,

Thanks for the patch, I tried it and it works nicely!

(except that I have no "include/uapi/" directory for
"include/uapi/linux/ptrace.h", so I applied that part
of the patch to "include/linux/ptrace.h" as well).

Also, I just noticed that this new option (PTRACE_O_EXITKILL) is not
safe with ptrace(PTRACE_TRACEME)+execve, because the parent may die
before even having a chance to set PTRACE_O_EXITKILL!

However, that's easy to fix by using PTRACE_ATTACH instead.

On that other matter:

> > What I wish is that I could request (using "prctl" or whatever):
> > "If a non-privileged user sends me a SIGSTOP, then let it be converted 
> > into...",
> 
> I hope we won't do this ;) But I am not going to argue if you convince
> other people.
> 
> To me it would be better to simply allow to catch SIGSTOP, but I hope
> we won't do this too.

I don't think anyone should seriously contemplate catching SIGSTOP -
that would break so many applications, including mine.

Now about "convincing", I have that application that really needs this
feature, and I believe that others may be in the same predicament, which is:

1. The application is a SUID-root service, available to ordinary users.
2. Users who started this application are allowed at any time to signal
   or kill their instance(s) of this application.
3. It is alright for the application to be killed by SIGKILL.
4. The application catches and does something useful and positive with
   all other signals sent to it by the invoking user, including SIGTSTP,
   SIGTTIN and SIGTTOU.
5. If the application is unpreparedly stopped by SIGSTOP, which it cannot
   catch, then this may disrupt other instances of this application by
   other users (including, in my case, on other computers connected with
   the application by TCP/IP sockets).

What I ask is simple and can be so easily implemented, essentially in
"kernel/signal.c":

static int check_kill_permission(int sig, struct siginfo *info,
 struct task_struct *t)
{
struct pid *sid;
int error;

if (!valid_signal(sig))
return -EINVAL;

if (!si_fromuser(info))
return 0;

error = audit_signal_info(sig, t); /* Let audit system see the signal */
if (error)
return error;

+   if (sig == SIGSTOP && (t->flags & PF_NO_SIGSTOP) && !capable(CAP_KILL))
+   return -EPERM;
+
if (!same_thread_group(current, t) &&
!kill_ok_by_cred(t)) {
switch (sig) {
...

In addition, only the super-user (or CAP_SYS_ADMIN, etc.) should be
allowed to set/reset PF_NO_SIGSTOP (and if taking up a precious PF_xxx
flag is a problem, then the flag could be somewhere else).

Thanks,
Amnon.


Oleg Nesterov wrote:
> 
> (add lkml/cc's)
> 
> On 11/07, Amnon Shiloh wrote:
> >
> > > Quoting Oleg Nesterov (o...@redhat.com):
> > > >
> > > > On 11/06, Amnon Shiloh wrote:
> > > > >
> > > > > What I would IDEALLY like to have is a call, probably a ptrace option,
> > > > > where the parent can request: "If I am ever to terminate or be killed,
> > > > > then my ptraced son MUST die as well".
> > > >
> > > > Perhaps this makes sense...
> > > >
> > > > Chris, iirc you also suggested something like this? And the patch is
> > > > trivial.
> > > >
> > > > Oleg.
> > > >
> > > > --- x/kernel/ptrace.c
> > > > +++ x/kernel/ptrace.c
> > > > @@ -393,8 +393,12 @@ static bool __ptrace_detach(struct task_
> > > >
> > > > __ptrace_unlink(p);
> > > >
> > > > -   if (p->exit_state != EXIT_ZOMBIE)
> > > > +   if (p->exit_state != EXIT_ZOMBIE) {
> > > > +   if ((tracer->flags & PF_EXITING) &&
> > > > +   (p->ptrace & PT_KILL_IF_TRACER_EXITS))
> > > > +   send_sig_info(SIGKILL, SEND_SIG_FORCED, p);
> 
> No. This is wrong.
> 
> We should send SIGKILL before __ptrace_unlink() which clears ->ptrace.
> Otherwise (in theory) the tracee can raise its capabilities in between.
> 
> Lets change exit_ptrace() to do this, see the patch at the end.
> 
> > That would be just wonderful, just what I need
> > - it will solve me so much pain!
> 
> OK. Please see the untested/uncompiled (but trivial) patch below
> 
>   - it adds PTRACE_O_EXITKILL. A better name?
> 
>   - A better numeric value? Note that the new option is not equal to
> the last-ptrace-option << 1. Because currently all options have
> the event, and the new one starts the eventless group. 1 << 16
> means we have the room for 8 more events.
> 
>   - it needs the convincing changelog for akpm
> 
> > Speaking of things I need, here is another:
> >
> > I have a SUID-root service, which ordinary users can launch.
> > This service keeps its original real-UID so that its calling user
> > can send it signals, which is fine because it catches them all and
> > handles them appropriately.
> >
> > It is not even a problem if the user kills my service using SIGKILL
> > (because 

[PATCH] mm: dmapool: use provided gfp flags for all dma_alloc_coherent() calls

[Marek Szyprowski]

dmapool always calls dma_alloc_coherent() with GFP_ATOMIC flag, regardless
the flags provided by the caller. This causes excessive pruning of
emergency memory pools without any good reason. This patch changes the code
to correctly use gfp flags provided by the dmapool caller. This should
solve the dmapool usage on ARM architecture, where GFP_ATOMIC DMA
allocations can be served only from the special, very limited memory pool.

Reported-by: Soren Moch 
Reported-by: Thomas Petazzoni 
Signed-off-by: Marek Szyprowski 
---
 mm/dmapool.c |   27 +++
 1 file changed, 7 insertions(+), 20 deletions(-)

diff --git a/mm/dmapool.c b/mm/dmapool.c
index c5ab33b..86de9b2 100644
--- a/mm/dmapool.c
+++ b/mm/dmapool.c
@@ -62,8 +62,6 @@ struct dma_page { /* cacheable header for 
'allocation' bytes */
unsigned int offset;
 };
 
-#definePOOL_TIMEOUT_JIFFIES((100 /* msec */ * HZ) / 1000)
-
 static DEFINE_MUTEX(pools_lock);
 
 static ssize_t
@@ -227,7 +225,6 @@ static struct dma_page *pool_alloc_page(struct dma_pool 
*pool, gfp_t mem_flags)
memset(page->vaddr, POOL_POISON_FREED, pool->allocation);
 #endif
pool_initialise_page(pool, page);
-   list_add(>page_list, >page_list);
page->in_use = 0;
page->offset = 0;
} else {
@@ -315,30 +312,21 @@ void *dma_pool_alloc(struct dma_pool *pool, gfp_t 
mem_flags,
might_sleep_if(mem_flags & __GFP_WAIT);
 
spin_lock_irqsave(>lock, flags);
- restart:
list_for_each_entry(page, >page_list, page_list) {
if (page->offset < pool->allocation)
goto ready;
}
-   page = pool_alloc_page(pool, GFP_ATOMIC);
-   if (!page) {
-   if (mem_flags & __GFP_WAIT) {
-   DECLARE_WAITQUEUE(wait, current);
 
-   __set_current_state(TASK_UNINTERRUPTIBLE);
-   __add_wait_queue(>waitq, );
-   spin_unlock_irqrestore(>lock, flags);
+   /* pool_alloc_page() might sleep, so temporarily drop >lock */
+   spin_unlock_irqrestore(>lock, flags);
 
-   schedule_timeout(POOL_TIMEOUT_JIFFIES);
+   page = pool_alloc_page(pool, mem_flags);
+   if (!page)
+   return NULL;
 
-   spin_lock_irqsave(>lock, flags);
-   __remove_wait_queue(>waitq, );
-   goto restart;
-   }
-   retval = NULL;
-   goto done;
-   }
+   spin_lock_irqsave(>lock, flags);
 
+   list_add(>page_list, >page_list);
  ready:
page->in_use++;
offset = page->offset;
@@ -348,7 +336,6 @@ void *dma_pool_alloc(struct dma_pool *pool, gfp_t mem_flags,
 #ifdef DMAPOOL_DEBUG
memset(retval, POOL_POISON_ALLOCATED, pool->size);
 #endif
- done:
spin_unlock_irqrestore(>lock, flags);
return retval;
 }
-- 
1.7.9.5

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

Re: [RFC PATCH 00/19] Foundation for automatic NUMA balancing

[Zhouping Liu]

On 11/07/2012 11:25 PM, Mel Gorman wrote:

On Wed, Nov 07, 2012 at 05:27:12PM +0800, Zhouping Liu wrote:

Hello Mel,

my 2 nodes machine hit a panic fault after applied the patch
set(based on kernel-3.7.0-rc4), please review it:



Early initialisation problem by the looks of things. Try this please


Tested the patch, and the issue is gone.



---8<---
mm: numa: Check that preferred_node_policy is initialised

Zhouping Liu reported the following

[ 0.00] [ cut here ]
[ 0.00] kernel BUG at mm/mempolicy.c:1785!
[ 0.00] invalid opcode:  [#1] SMP
[ 0.00] Modules linked in:
[ 0.00] CPU 0

[0.00] Call Trace:
[0.00] [] alloc_pages_current+0xa6/0x170
[0.00] [] __get_free_pages+0x14/0x50
[0.00] [] kmem_cache_init+0x53/0x2d2
[0.00] [] start_kernel+0x1e0/0x3c7

Problem is that early in boot preferred_nod_policy and SLUB
initialisation trips up. Check it is initialised.

Signed-off-by: Mel Gorman 


Tested-by: Zhouping Liu 

Thanks,
Zhouping


---
  mm/mempolicy.c |4 
  1 file changed, 4 insertions(+)

diff --git a/mm/mempolicy.c b/mm/mempolicy.c
index 11d4b6b..8cfa6dc 100644
--- a/mm/mempolicy.c
+++ b/mm/mempolicy.c
@@ -129,6 +129,10 @@ static struct mempolicy *get_task_policy(struct 
task_struct *p)
node = numa_node_id();
if (node != -1)
pol = _node_policy[node];
+
+   /* preferred_node_policy is not initialised early in boot */
+   if (!pol->mode)
+   pol = NULL;
}
  
  	return pol;


--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majord...@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: mailto:"d...@kvack.org;> em...@kvack.org 


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] gpio: tegra: read output value when gpio is set in direction_out

[Laxman Dewangan]

Read the output value when gpio is set for the output mode for
gpio_get_value(). Reading input value in direction out does not
give correct value.

Signed-off-by: Laxman Dewangan 
---
 drivers/gpio/gpio-tegra.c |6 ++
 1 files changed, 6 insertions(+), 0 deletions(-)

diff --git a/drivers/gpio/gpio-tegra.c b/drivers/gpio/gpio-tegra.c
index c7c175a..0fb2ce7 100644
--- a/drivers/gpio/gpio-tegra.c
+++ b/drivers/gpio/gpio-tegra.c
@@ -135,6 +135,12 @@ static void tegra_gpio_set(struct gpio_chip *chip, 
unsigned offset, int value)
 
 static int tegra_gpio_get(struct gpio_chip *chip, unsigned offset)
 {
+   int bit_val = BIT(GPIO_BIT(offset));
+
+   /* If gpio is in output mode then read from the out value */
+   if (tegra_gpio_readl(GPIO_OE(offset)) & bit_val)
+   return !!(tegra_gpio_readl(GPIO_OUT(offset)) & bit_val);
+
return (tegra_gpio_readl(GPIO_IN(offset)) >> GPIO_BIT(offset)) & 0x1;
 }
 
-- 
1.7.1.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/4] thermal: Add new thermal trend type to support quick cooling

[Amit Kachhap]

On 8 November 2012 11:31, Zhang Rui  wrote:
> On Thu, 2012-11-08 at 09:56 +0530, Amit Daniel Kachhap wrote:
>> This modification adds 2 new thermal trend type THERMAL_TREND_RAISE_FULL
>> and THERMAL_TREND_DROP_FULL. This thermal trend can be used to quickly
>> jump to the upper or lower cooling level instead of incremental increase
>> or decrease.
>
> IMO, what we need is a new more aggressive cooling governor which always
> uses upper limit when the temperature is raising and lower limit when
> the temperature is dropping.
Yes I agree that a new aggressive governor is the best approach but
then i thought adding a new trend type is a simple solution to achieve
this and since most of the governor logic might be same as the
step-wise governor. I have no objection in doing it through governor.
>
> I can write such a governor if you do not have time to.
ok. thanks
>
> thanks,
> rui
>>  This is needed for temperature sensors which support rising/falling
>> threshold interrupts and polling can be totally avoided.
>>
>
>
>> Signed-off-by: Amit Daniel Kachhap 
>> Signed-off-by: Amit Daniel Kachhap 
>> ---
>>  drivers/thermal/step_wise.c |   19 +++
>>  include/linux/thermal.h |2 ++
>>  2 files changed, 17 insertions(+), 4 deletions(-)
>>
>> diff --git a/drivers/thermal/step_wise.c b/drivers/thermal/step_wise.c
>> index 1242cff..0d2d8d6 100644
>> --- a/drivers/thermal/step_wise.c
>> +++ b/drivers/thermal/step_wise.c
>> @@ -35,6 +35,10 @@
>>   *   state for this trip point
>>   *b. if the trend is THERMAL_TREND_DROPPING, use lower cooling
>>   *   state for this trip point
>> + *c. if the trend is THERMAL_TREND_RAISE_FULL, use highest cooling
>> + *   state for this trip point
>> + *d. if the trend is THERMAL_TREND_DROP_FULL, use lowest cooling
>> + *   state for this trip point
>>   */
>>  static unsigned long get_target_state(struct thermal_instance *instance,
>>   enum thermal_trend trend)
>> @@ -50,7 +54,10 @@ static unsigned long get_target_state(struct 
>> thermal_instance *instance,
>>   } else if (trend == THERMAL_TREND_DROPPING) {
>>   cur_state = cur_state > instance->lower ?
>>   (cur_state - 1) : instance->lower;
>> - }
>> + } else if (trend == THERMAL_TREND_RAISE_FULL)
>> + cur_state = instance->upper;
>> + else if (trend == THERMAL_TREND_DROP_FULL)
>> + cur_state = instance->lower;
>>
>>   return cur_state;
>>  }
>> @@ -87,7 +94,8 @@ static void update_instance_for_throttle(struct 
>> thermal_zone_device *tz,
>>  }
>>
>>  static void update_instance_for_dethrottle(struct thermal_zone_device *tz,
>> - int trip, enum thermal_trip_type trip_type)
>> + int trip, enum thermal_trip_type trip_type,
>> + enum thermal_trend trend)
>>  {
>>   struct thermal_instance *instance;
>>   struct thermal_cooling_device *cdev;
>> @@ -101,7 +109,10 @@ static void update_instance_for_dethrottle(struct 
>> thermal_zone_device *tz,
>>   cdev = instance->cdev;
>>   cdev->ops->get_cur_state(cdev, _state);
>>
>> - instance->target = cur_state > instance->lower ?
>> + if (trend == THERMAL_TREND_DROP_FULL)
>> + instance->target = instance->lower;
>> + else
>> + instance->target = cur_state > instance->lower ?
>>   (cur_state - 1) : THERMAL_NO_TARGET;
>>
>>   /* Deactivate a passive thermal instance */
>> @@ -133,7 +144,7 @@ static void thermal_zone_trip_update(struct 
>> thermal_zone_device *tz, int trip)
>>   if (tz->temperature >= trip_temp)
>>   update_instance_for_throttle(tz, trip, trip_type, trend);
>>   else
>> - update_instance_for_dethrottle(tz, trip, trip_type);
>> + update_instance_for_dethrottle(tz, trip, trip_type, trend);
>>
>>   mutex_unlock(>lock);
>>  }
>> diff --git a/include/linux/thermal.h b/include/linux/thermal.h
>> index 807f214..8bce3ec 100644
>> --- a/include/linux/thermal.h
>> +++ b/include/linux/thermal.h
>> @@ -68,6 +68,8 @@ enum thermal_trend {
>>   THERMAL_TREND_STABLE, /* temperature is stable */
>>   THERMAL_TREND_RAISING, /* temperature is raising */
>>   THERMAL_TREND_DROPPING, /* temperature is dropping */
>> + THERMAL_TREND_RAISE_FULL, /* Apply highest cooling action*/
>> + THERMAL_TREND_DROP_FULL, /* Apply lowest cooling action*/
>>  };
>>
>>  /* Events supported by Thermal Netlink */
>
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

82571EB: Detected Hardware Unit Hang

[Joe Jin]

Hi list,

IHAC reported "82571EB Detected Hardware Unit Hang" on HP ProLiant DL360 G6, and
have to reboot the server to recover:

e1000e :06:00.1: eth3: Detected Hardware Unit Hang:
  TDH  <1a>
  TDT  <1a>
  next_to_use  <1a>
  next_to_clean<18>
buffer_info[next_to_clean]:
  time_stamp   <10047a74e>
  next_to_watch<18>
  jiffies  <10047a88c>
  next_to_watch.status <1>
MAC Status <80383>
PHY Status <792d>
PHY 1000BASE-T Status  <3800>
PHY Extended Status<3000>
PCI Status <10>

With newer kernel 2.0.0.1 the issue still reproducible.

Device info:
06:00.1 Ethernet controller: Intel Corporation 82571EB Gigabit Ethernet 
Controller (Copper) (rev 06)
06:00.1 0200: 8086:10bc (rev 06)

I compared lspci output before and after the issue, different as below:
 06:00.1 Ethernet controller: Intel Corporation 82571EB Gigabit Ethernet 
Controller (Copper) (rev 06)
Subsystem: Hewlett-Packard Company NC364T PCI Express Quad Port Gigabit 
Server Adapter
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr+ 
Stepping- SERR- FastB2B- DisINTx-
-   Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- SERR- TAbort- SERR- http://www.oracle.com>
Joe Jin | Software Development Senior Manager | +8610.6106.5624
ORACLE | Linux and Virtualization
No. 24 Zhongguancun Software Park, Haidian District | 100193 Beijing 
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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: + binfmt_elfc-use-get_random_int-to-fix-entropy-depleting.patch added to -mm tree

[Jeff Liu]

On 11/07/2012 11:10 PM, Kees Cook wrote:
> On Wed, Nov 7, 2012 at 1:32 AM, Theodore Ts'o  wrote:
>> On Tue, Nov 06, 2012 at 05:11:17PM -0800, Kees Cook wrote:
>>> Hrm, I don't like this. get_random_int() specifically says: "Get a
>>> random word for internal kernel use only." The intent of AT_RANDOM is
>>> for userspace pRNG seeding (though glibc currently uses it directly
>>> for stack protector and pointer mangling), which is not "internal
>>> kernel use only". :) Though I suppose this is already being used for
>>> the randomize_stack_top(), but I think it'd still be better to use
>>> higher quality bits.
>>
>> Well, in practice, right now, get_random_int() is only being used for
>> different cases of ASLR of one variety or another (either by the
>> kernel in exec or mmap, or in userspace).  So I'm not sure it really
>> is a major issue.
> 
> Hrm, yes. I see that the network code uses random32, not
> get_random_int(). How are these different? Is one demonstrably better?
I also have the same question in this point.
Both generators are NOT considered safe for cryptographic use, but the
comments of get_random_int() indicates that it could be used for several
uses the cost of depleting entropy is too high, that's why I chose it.
> 
>> If we also change get_random_int() to use a more secure cryptographic
>> random generator (i.e., maybe AES instead of MD5), would that be
>> sufficient to address your concerns?  We're not using get_random_int()
>> for anything that's timing sensitive, so that shouldn't be a problem.
> 
> I wonder if using AES would have a measurable impact on fork speeds?
> 
>> Or maybe we should just add an explicit CRNG set of routines (like the
>> similar discussions to make an explicitly named PRNG set of routines),
>> so callers can use whatever random number generator is appropriate for
>> their performance and security needs.
> 
> If we do use get_random_int() here, I'd at least like to see its
> comment changed to reflect its actual purpose (since it's not
> "internal use only") as well as its expected unpredictability. (This
> would help document the utility of get_random_bytes() vs
> get_random_int() vs random32().)
> 
> -Kees
Thanks,
-Jeff


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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: How about a gpio_get(device *, char *) function?

[Alex Courbot]

On Thursday 08 November 2012 05:24:19 Linus Walleij wrote:
> On Tue, Nov 6, 2012 at 2:33 AM, Alex Courbot  wrote:
> > How about, in a first time (and because I'd also like to get the power
> > seqs
> > moving on), a typedef from int to gpio_handle_t and a first implementation
> > of the gpio_handle_*() API that would just call the existing
> > integer-based API (apart from gpio_handle_get())? That way things will
> > not break when we switch to a real handle.
> 
> I'm afraid of typedef:ing gpio_handle_t to int because it sort of
> encourages non-handlers to be used mixed with the old integers.
> 
> I would prefer to create, e.g. in 
> something like:
> 
> struct gpio;
> 
> struct gpio *gpio_get(struct device *dev, const char *name);
> 
> int gpio_get_value(struct gpio *g);
> 
> Nothing more! I.e. struct gpio is an opaque cookie, nothing to be known
> about it.

However these is already a struct gpio declared in linux/gpio.h. Shall the 
opaque handler be renamed something like "struct gpioh", or is your idea to 
make both APIs mutually exclusive?

Alex.

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

Re: [PATCH] rtc: avoid calling platform_device_put() twice in test_init()

[Wei Yongjun]

On 11/07/2012 08:51 AM, Andrew Morton wrote:
> On Tue, 23 Oct 2012 13:08:41 +0800
> Wei Yongjun  wrote:
>
>> From: Wei Yongjun 
>>
>> In case of error, the function test_init() need to call
>> platform_device_del() instead of platform_device_unregister().
>> Otherwise, we may call platform_device_put() twice.
>>
> Is platform_device_del() the partner to platform_device_add()?  If so
> then yes, this looks right.  But I think the labels can be improved:
>
> _
>
>
> However, take a look at test_exit().  it does
> platform_device_unregister(test0) when test0 is in the same state.  Is
> that code wrong as well?  Presumably it's working OK?

platform_device_unregister() is a warp of platform_device_del()
and platform_device_put(), if platform_device_add() success, we
can use platform_device_unregister() to do this, so that code
is OK.
 


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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: How about a gpio_get(device *, char *) function?

[Alex Courbot]

On Thursday 08 November 2012 05:24:19 Linus Walleij wrote:
> I would prefer to create, e.g. in 
> something like:
> 
> struct gpio;
> 
> struct gpio *gpio_get(struct device *dev, const char *name);
> 
> int gpio_get_value(struct gpio *g);
> 
> Nothing more! I.e. struct gpio is an opaque cookie, nothing to be known
> about it.
> 
> And then have the drivers using this *ONLY* include 
> and not . So drivers have no clue what struct gpio is and
> will only operate on it using functions.
> 
> This follows the pattern set by Thomas Gleixner for e.g. IRQ descriptors,
> and the style was also used in the redesign of the struct clk *.

Also pretty similar to the regulator framework, which might itself have been 
inspired by IRQs and clocks.

> Of course the cross-referencing implementation can in e.g.
> drivers/gpio/gpiodev.c internally define that like this:
> 
> #include 
> 
> /**
>   * @gpio: pointer to global GPIO number
>   */
> struct gpio {
> int gpio;
> };
> 
> struct gpio *gpio_get(struct device *dev, const char *name)
> {
>/* Lookup in cross-ref table etc */
> }
> 
> int gpioh_get_value(struct gpio *g)
> {
>return gpio_get_value(g->gpio);
> }
> 
> (...)
> 
> Then we can work from there. I think it adds the proper
> opaqueness factor.

Looks nice, simple and to the point! Let's see if I can find the time to cook 
something based on this.

Thanks!
Alex.

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

Re: [PATCH 1/4] thermal: Add new thermal trend type to support quick cooling

[Zhang Rui]

On Thu, 2012-11-08 at 09:56 +0530, Amit Daniel Kachhap wrote:
> This modification adds 2 new thermal trend type THERMAL_TREND_RAISE_FULL
> and THERMAL_TREND_DROP_FULL. This thermal trend can be used to quickly
> jump to the upper or lower cooling level instead of incremental increase
> or decrease.

IMO, what we need is a new more aggressive cooling governor which always
uses upper limit when the temperature is raising and lower limit when
the temperature is dropping.

I can write such a governor if you do not have time to.

thanks,
rui
>  This is needed for temperature sensors which support rising/falling
> threshold interrupts and polling can be totally avoided.
> 


> Signed-off-by: Amit Daniel Kachhap 
> Signed-off-by: Amit Daniel Kachhap 
> ---
>  drivers/thermal/step_wise.c |   19 +++
>  include/linux/thermal.h |2 ++
>  2 files changed, 17 insertions(+), 4 deletions(-)
> 
> diff --git a/drivers/thermal/step_wise.c b/drivers/thermal/step_wise.c
> index 1242cff..0d2d8d6 100644
> --- a/drivers/thermal/step_wise.c
> +++ b/drivers/thermal/step_wise.c
> @@ -35,6 +35,10 @@
>   *   state for this trip point
>   *b. if the trend is THERMAL_TREND_DROPPING, use lower cooling
>   *   state for this trip point
> + *c. if the trend is THERMAL_TREND_RAISE_FULL, use highest cooling
> + *   state for this trip point
> + *d. if the trend is THERMAL_TREND_DROP_FULL, use lowest cooling
> + *   state for this trip point
>   */
>  static unsigned long get_target_state(struct thermal_instance *instance,
>   enum thermal_trend trend)
> @@ -50,7 +54,10 @@ static unsigned long get_target_state(struct 
> thermal_instance *instance,
>   } else if (trend == THERMAL_TREND_DROPPING) {
>   cur_state = cur_state > instance->lower ?
>   (cur_state - 1) : instance->lower;
> - }
> + } else if (trend == THERMAL_TREND_RAISE_FULL)
> + cur_state = instance->upper;
> + else if (trend == THERMAL_TREND_DROP_FULL)
> + cur_state = instance->lower;
>  
>   return cur_state;
>  }
> @@ -87,7 +94,8 @@ static void update_instance_for_throttle(struct 
> thermal_zone_device *tz,
>  }
>  
>  static void update_instance_for_dethrottle(struct thermal_zone_device *tz,
> - int trip, enum thermal_trip_type trip_type)
> + int trip, enum thermal_trip_type trip_type,
> + enum thermal_trend trend)
>  {
>   struct thermal_instance *instance;
>   struct thermal_cooling_device *cdev;
> @@ -101,7 +109,10 @@ static void update_instance_for_dethrottle(struct 
> thermal_zone_device *tz,
>   cdev = instance->cdev;
>   cdev->ops->get_cur_state(cdev, _state);
>  
> - instance->target = cur_state > instance->lower ?
> + if (trend == THERMAL_TREND_DROP_FULL)
> + instance->target = instance->lower;
> + else
> + instance->target = cur_state > instance->lower ?
>   (cur_state - 1) : THERMAL_NO_TARGET;
>  
>   /* Deactivate a passive thermal instance */
> @@ -133,7 +144,7 @@ static void thermal_zone_trip_update(struct 
> thermal_zone_device *tz, int trip)
>   if (tz->temperature >= trip_temp)
>   update_instance_for_throttle(tz, trip, trip_type, trend);
>   else
> - update_instance_for_dethrottle(tz, trip, trip_type);
> + update_instance_for_dethrottle(tz, trip, trip_type, trend);
>  
>   mutex_unlock(>lock);
>  }
> diff --git a/include/linux/thermal.h b/include/linux/thermal.h
> index 807f214..8bce3ec 100644
> --- a/include/linux/thermal.h
> +++ b/include/linux/thermal.h
> @@ -68,6 +68,8 @@ enum thermal_trend {
>   THERMAL_TREND_STABLE, /* temperature is stable */
>   THERMAL_TREND_RAISING, /* temperature is raising */
>   THERMAL_TREND_DROPPING, /* temperature is dropping */
> + THERMAL_TREND_RAISE_FULL, /* Apply highest cooling action*/
> + THERMAL_TREND_DROP_FULL, /* Apply lowest cooling action*/
>  };
>  
>  /* Events supported by Thermal Netlink */


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] Xen/acpi: revert pad config check in xen_check_mwait

[Liu, Jinsong]

With Xen acpi pad logic added into kernel, we can now revert xen mwait related
patch df88b2d96e36d9a9e325bfcd12eb45671cbbc937. The reason is, when running 
under
newer Xen platform, Xen pad driver would be early loaded, so native pad driver
would fail to be loaded, and hence no mwait/monitor #UD risk again.

Another point is, only Xen4.2 or later support Xen acpi pad, so we won't expose
mwait cpuid capability when running under older Xen platform.

Signed-off-by: Liu, Jinsong 
---
 arch/x86/xen/enlighten.c |   10 --
 1 files changed, 8 insertions(+), 2 deletions(-)

diff --git a/arch/x86/xen/enlighten.c b/arch/x86/xen/enlighten.c
index 586d838..548296f 100644
--- a/arch/x86/xen/enlighten.c
+++ b/arch/x86/xen/enlighten.c
@@ -287,8 +287,7 @@ static void xen_cpuid(unsigned int *ax, unsigned int *bx,
 
 static bool __init xen_check_mwait(void)
 {
-#if defined(CONFIG_ACPI) && !defined(CONFIG_ACPI_PROCESSOR_AGGREGATOR) && \
-   !defined(CONFIG_ACPI_PROCESSOR_AGGREGATOR_MODULE)
+#ifdef CONFIG_ACPI
struct xen_platform_op op = {
.cmd= XENPF_set_processor_pminfo,
.u.set_pminfo.id= -1,
@@ -309,6 +308,13 @@ static bool __init xen_check_mwait(void)
if (!xen_initial_domain())
return false;
 
+   /*
+* When running under platform earlier than Xen4.2, do not expose
+* mwait, to avoid the risk of loading native acpi pad driver
+*/
+   if (!xen_running_on_version_or_later(4, 2))
+   return false;
+
ax = 1;
cx = 0;
 
-- 
1.7.1


0002-Xen-acpi-revert-pad-config-check-in-xen_check_mwait.patch
Description: 0002-Xen-acpi-revert-pad-config-check-in-xen_check_mwait.patch

[PATCH v2 1/2] Xen/acpi: ACPI PAD driver

[Liu, Jinsong]

PAD is acpi Processor Aggregator Device which provides a control point
that enables the platform to perform specific processor configuration
and control that applies to all processors in the platform.

This patch is to implement Xen acpi pad logic. When running under Xen
virt platform, native pad driver would not work. Instead Xen pad driver,
a self-contained and thin logic level, would take over acpi pad logic.

When acpi pad notify OSPM, xen pad logic intercept and parse _PUR object
to get the expected idle cpu number, and then hypercall to hypervisor.
Xen hypervisor would then do the rest work, say, core parking, to idle
specific number of cpus on its own policy.

Signed-off-by: Jan Beulich 
Signed-off-by: Liu Jinsong 
---
 drivers/xen/Makefile |3 +-
 drivers/xen/xen-acpi-pad.c   |  181 ++
 include/xen/interface/platform.h |   17 
 include/xen/interface/version.h  |   15 +++
 4 files changed, 215 insertions(+), 1 deletions(-)
 create mode 100644 drivers/xen/xen-acpi-pad.c

diff --git a/drivers/xen/Makefile b/drivers/xen/Makefile
index 0e86370..3c39717 100644
--- a/drivers/xen/Makefile
+++ b/drivers/xen/Makefile
@@ -10,7 +10,8 @@ CFLAGS_features.o := $(nostackp)
 
 dom0-$(CONFIG_PCI) += pci.o
 dom0-$(CONFIG_USB_SUPPORT) += dbgp.o
-dom0-$(CONFIG_ACPI) += acpi.o
+dom0-$(CONFIG_ACPI) += acpi.o $(xen-pad-y)
+xen-pad-$(CONFIG_X86) += xen-acpi-pad.o
 dom0-$(CONFIG_X86) += pcpu.o
 obj-$(CONFIG_XEN_DOM0) += $(dom0-y)
 obj-$(CONFIG_BLOCK)+= biomerge.o
diff --git a/drivers/xen/xen-acpi-pad.c b/drivers/xen/xen-acpi-pad.c
new file mode 100644
index 000..f23ecf3
--- /dev/null
+++ b/drivers/xen/xen-acpi-pad.c
@@ -0,0 +1,181 @@
+/*
+ * xen-acpi-pad.c - Xen pad interface
+ *
+ * Copyright (c) 2012, Intel Corporation.
+ *Author: Liu, Jinsong 
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms and conditions of the GNU General Public License,
+ * version 2, as published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope it will be useful, but WITHOUT
+ * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
+ * FITNESS FOR A PARTICULAR PURPOSE.  See the GNU General Public License for
+ * more details.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#define ACPI_PROCESSOR_AGGREGATOR_CLASS"acpi_pad"
+#define ACPI_PROCESSOR_AGGREGATOR_DEVICE_NAME "Processor Aggregator"
+#define ACPI_PROCESSOR_AGGREGATOR_NOTIFY 0x80
+static DEFINE_MUTEX(xen_cpu_lock);
+
+static int xen_acpi_pad_idle_cpus(unsigned int idle_nums)
+{
+   struct xen_platform_op op;
+
+   op.cmd = XENPF_core_parking;
+   op.u.core_parking.type = XEN_CORE_PARKING_SET;
+   op.u.core_parking.idle_nums = idle_nums;
+
+   return HYPERVISOR_dom0_op();
+}
+
+static int xen_acpi_pad_idle_cpus_num(void)
+{
+   struct xen_platform_op op;
+
+   op.cmd = XENPF_core_parking;
+   op.u.core_parking.type = XEN_CORE_PARKING_GET;
+
+   return HYPERVISOR_dom0_op()
+  ?: op.u.core_parking.idle_nums;
+}
+
+/*
+ * Query firmware how many CPUs should be idle
+ * return -1 on failure
+ */
+static int acpi_pad_pur(acpi_handle handle)
+{
+   struct acpi_buffer buffer = {ACPI_ALLOCATE_BUFFER, NULL};
+   union acpi_object *package;
+   int num = -1;
+
+   if (ACPI_FAILURE(acpi_evaluate_object(handle, "_PUR", NULL, )))
+   return num;
+
+   if (!buffer.length || !buffer.pointer)
+   return num;
+
+   package = buffer.pointer;
+
+   if (package->type == ACPI_TYPE_PACKAGE &&
+   package->package.count == 2 &&
+   package->package.elements[0].integer.value == 1) /* rev 1 */
+   num = package->package.elements[1].integer.value;
+
+   kfree(buffer.pointer);
+   return num;
+}
+
+/* Notify firmware how many CPUs are idle */
+static void acpi_pad_ost(acpi_handle handle, int stat,
+   uint32_t idle_nums)
+{
+   union acpi_object params[3] = {
+   {.type = ACPI_TYPE_INTEGER,},
+   {.type = ACPI_TYPE_INTEGER,},
+   {.type = ACPI_TYPE_BUFFER,},
+   };
+   struct acpi_object_list arg_list = {3, params};
+
+   params[0].integer.value = ACPI_PROCESSOR_AGGREGATOR_NOTIFY;
+   params[1].integer.value =  stat;
+   params[2].buffer.length = 4;
+   params[2].buffer.pointer = (void *)_nums;
+   acpi_evaluate_object(handle, "_OST", _list, NULL);
+}
+
+static void acpi_pad_handle_notify(acpi_handle handle)
+{
+   int idle_nums;
+
+   mutex_lock(_cpu_lock);
+   idle_nums = acpi_pad_pur(handle);
+   if (idle_nums < 0) {
+   mutex_unlock(_cpu_lock);
+   return;
+   }
+
+   idle_nums = xen_acpi_pad_idle_cpus(idle_nums)
+   ?: xen_acpi_pad_idle_cpus_num();
+   if (idle_nums >= 0)
+  

Re: [PATCH v7 0/3] Add modules to support realtek PCIE card reader

[wwang]

于 2012年11月08日 12:01, Alex Dubov 写道:

Hi,

Do you have any comment on the MEMSTICK part in this v7 patchset? Can
you help to merge the patch to the kernel tree?


I'm afraid that presently I don't have much time to look at the memstick 
related stuff any further. Hopefully, somebody else can step in and take a look 
at your submission.

Sorry for that.


Hi Greg & Arnd:

Can you help to review the MEMSTICK part in my patch and merge it to the 
kernel tree? Alex is a little busy now and I can't find any other 
maintainer who can take care of MEMSTICK subsystem.


Best regards,
Wei WANG

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] gpio: tegra: Staticize non-exported symbols

[Stephen Warren]

On 11/07/2012 07:45 PM, Axel Lin wrote:
> Both tegra_gpio_request() and tegra_gpio_free() are not referenced outside of
> this file, make them static.

Both patches,
Acked-by: Stephen Warren 

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] mmc: core: Add support for idle time BKOPS

[Jaehoon Chung]

Hi Maya, 

I tested with dw-mmc controller.
It's look good to me.

Tested-by: Jaehoon Chung 

On 11/07/2012 01:28 PM, me...@codeaurora.org wrote:
> Hi Jaehoon,
> 
> Any update on this patch review and testing?
> 
> Thanks,
> Maya
> On Mon, October 15, 2012 11:53 pm, Jaehoon Chung wrote:
>> Hi Maya,
>>
>> I'm testing with your patch..but i need to have the more time for testing.
>> In now, it looks good to me. Thank you for working the idle bkops.
>>
>> Best Regards,
>> Jaehoon Chung
>>
>>> ---
>>> diff --git a/drivers/mmc/card/block.c b/drivers/mmc/card/block.c
>>> index 172a768..ed040d5 100644
>>> --- a/drivers/mmc/card/block.c
>>> +++ b/drivers/mmc/card/block.c
>>> @@ -827,6 +827,9 @@ static int mmc_blk_issue_discard_rq(struct mmc_queue
>>> *mq, struct request *req)
>>> from = blk_rq_pos(req);
>>> nr = blk_rq_sectors(req);
>>>
>>> +   if (card->ext_csd.bkops_en)
>>> +   card->bkops_info.sectors_changed += blk_rq_sectors(req);
>> using nr?
>>> +
>>> if (mmc_can_discard(card))
>>> arg = MMC_DISCARD_ARG;
>>> else if (mmc_can_trim(card))
>>> @@ -1268,6 +1271,9 @@ static int mmc_blk_issue_rw_rq(struct mmc_queue
>>> *mq, struct request *rqc)
>>> if (!rqc && !mq->mqrq_prev->req)
>>> return 0;
>>>
>>> +   if (rqc && (card->ext_csd.bkops_en) && (rq_data_dir(rqc) == WRITE))
>>> +   card->bkops_info.sectors_changed += blk_rq_sectors(rqc);
>> Fix the indent.
>>> +
>>> do {
>>> if (rqc) {
>>> /*
>>> diff --git a/drivers/mmc/card/queue.c b/drivers/mmc/card/queue.c
>>> index e360a97..e96f5cf 100644
>>> --- a/drivers/mmc/card/queue.c
>>> +++ b/drivers/mmc/card/queue.c
>>> @@ -51,6 +51,7 @@ static int mmc_queue_thread(void *d)
>>>  {
>>> struct mmc_queue *mq = d;
>>> struct request_queue *q = mq->queue;
>>> +   struct mmc_card *card = mq->card;
>>>
>>> current->flags |= PF_MEMALLOC;
>>>
>>> @@ -66,6 +67,17 @@ static int mmc_queue_thread(void *d)
>>> spin_unlock_irq(q->queue_lock);
>>>
>>> if (req || mq->mqrq_prev->req) {
>>> +   /*
>>> +* If this is the first request, BKOPs might be in
>>> +* progress and needs to be stopped before issuing the
>>> +* request
>>> +*/
>>> +   if (card->ext_csd.bkops_en &&
>>> +   card->bkops_info.started_delayed_bkops) {
>>> +   card->bkops_info.started_delayed_bkops = false;
>>> +   mmc_stop_bkops(card);
>> if mmc_stop_bkops is failed..?
>>> +   }
>>> +
>>> set_current_state(TASK_RUNNING);
>>> mq->issue_fn(mq, req);
>>> } else {
>>> @@ -73,6 +85,7 @@ static int mmc_queue_thread(void *d)
>>> set_current_state(TASK_RUNNING);
>>> break;
>>> }
>>> +   mmc_start_delayed_bkops(card);
>>> up(>thread_sem);
>>> schedule();
>>> down(>thread_sem);
>>> diff --git a/drivers/mmc/core/core.c b/drivers/mmc/core/core.c
>>> index 6612163..fd8783d 100644
>>> --- a/drivers/mmc/core/core.c
>>> +++ b/drivers/mmc/core/core.c
>>> @@ -253,9 +253,42 @@ mmc_start_request(struct mmc_host *host, struct
>>> mmc_request *mrq)
>>>  }
>>>
>>>  /**
>>> + * mmc_start_delayed_bkops() - Start a delayed work to check for
>>> + *  the need of non urgent BKOPS
>>> + *
>>> + * @card: MMC card to start BKOPS on
>>> + */
>>> +void mmc_start_delayed_bkops(struct mmc_card *card)
>>> +{
>>> +   if (!card || !card->ext_csd.bkops_en || mmc_card_doing_bkops(card))
>>> +   return;
>>> +
>>> +   if (card->bkops_info.sectors_changed <
>>> +   BKOPS_MIN_SECTORS_TO_QUEUE_DELAYED_WORK)
>>> +   return;
>>> +
>>> +   pr_debug("%s: %s: queueing delayed_bkops_work\n",
>>> +mmc_hostname(card->host), __func__);
>>> +
>>> +   card->bkops_info.sectors_changed = 0;
>>> +
>>> +   /*
>>> +* cancel_delayed_bkops_work will prevent a race condition between
>>> +* fetching a request by the mmcqd and the delayed work, in case
>>> +* it was removed from the queue work but not started yet
>>> +*/
>>> +   card->bkops_info.cancel_delayed_work = false;
>>> +   card->bkops_info.started_delayed_bkops = true;
>>> +   queue_delayed_work(system_nrt_wq, >bkops_info.dw,
>>> +  msecs_to_jiffies(
>>> +  card->bkops_info.delay_ms));
>>> +}
>>> +EXPORT_SYMBOL(mmc_start_delayed_bkops);
>>> +
>>> +/**
>>>   * mmc_start_bkops - start BKOPS for supported cards
>>>   * @card: MMC card to start BKOPS
>>> - * @form_exception: A flag to indicate if this function was
>>> + * @from_exception: A flag to indicate if this function was
>>>   *  called due to an exception raised by the card
>>>   *
>>>   * Start background operations whenever 

Re: crash in rb_insert_color()

[xrjrunning]

i

在 2008年2月2日星期六UTC+8上午1时27分50秒，Zoltan Menyhart写道：
> I have got a crash on an 8 processor ia64 machine with the kernel 2.6.18.8:
> 
> [] ia64_fault+0x14b0/0x1600
> sp=e0019ea5f930 bsp=e0019ea51408
> r32 : 001a r33 : 00040020 r34 : 0010
> r35 : 0003800f r36 : e0019ea5fbb8 r37 : e0019ea5fbb0
> r38 : a0010027f2e0 r39 : e0019ea5f9c0 r40 : 000b
> r41 : a001c4e0 r42 : 0005 r43 : a00100a90050
>  [] ia64_leave_kernel+0x0/0x280
> sp=e0019ea5fb60 bsp=e0019ea51408
>  [] rb_insert_color+0x60/0x380
> sp=e0019ea5fd30 bsp=e0019ea513b8
> r32 : e004acb19448 r33 : e0052a7ba100 r34 : e002799a5908
> r35 :  r36 : a002046f7810 r37 : 0690
> r38 : 6f732e7365725f73 r39 : e004acb1c708 r40 : e0052a7ba100
>  [] ext3_htree_store_dirent+0x270/0x2e0 [ext3]
> sp=e0019ea5fd30 bsp=e0019ea51350
> r32 : e0052a7ba100 r33 : 59bf4f42 r34 : 26f5c228
> r35 : e0082bb9063c r36 : e004acb19440 r37 : e002799a5918
> r38 : 003d r39 : e0082bb90642 r40 : e004acb19444
> r41 : e002799a5908 r42 : a00204708a70 r43 : 0611
> r44 : a00204716448
>  [] htree_dirblock_to_tree+0x1b0/0x280 [ext3]
> sp=e0019ea5fd30 bsp=e0019ea512f0
> r32 : e00126191780 r33 : e0082bb907f8 r34 : e0082bb9063c
> r35 : e0019ea5fd50 r36 :  r37 : 
> r38 : e0014ff15b68 r39 : 0018 r40 : e0019ea5fd54
> r41 : a00204708c40 r42 : 0795 r43 : a00204716448
>  [] ext3_htree_fill_tree+0x100/0x460 [ext3]
> sp=e0019ea5fd40 bsp=e0019ea51278
> r32 : e00126191780 r33 :  r34 : 
> r35 : e0052a7ba128 r36 : a002046f82b0 r37 : e0014ff060b8
> r38 :  r39 : 00d0 r40 : 600101cc
> r41 : 600ffa5ff5b0 r42 : 600ffa5ff618 r43 : f000
> r44 : a002046f82f0 r45 : 0fa6 r46 : a00204716448
>  [] ext3_readdir+0x890/0xcc0 [ext3]
> sp=e0019ea5fda0 bsp=e0019ea51178
> r32 : e00126191780 r33 : e0019ea5fe20 r34 : a00100656570
> r35 : e0052a7ba108 r36 : e0052a7ba100 r37 : e0052a7ba124
> r38 : e0052a7ba120 r39 : e0014ff06160 r40 : e00126191830
> r41 : e001261917b8 r42 : e0052a7ba128 r43 : e00126191790
> r44 : e0052a7ba118 r45 : e0014ff060b8 r46 : e0052a7ba124
> r47 : e0087a0b5980 r48 : e0087a0b59a0 r49 : e0052a7ba108
> r50 :  r51 :  r52 : 
> r53 : 0793 r54 : e0019ea5fe00 r55 : 0001
> r56 : 0793 r57 :  r58 : 2003cc7c
> r59 : a0010017bd60 r60 : 058e r61 : a00204716448
> r62 : 1555a559
>  [] vfs_readdir+0x1a0/0x200
> sp=e0019ea5fe10 bsp=e0019ea51120
> r32 : e00126191780 r33 : a00100656570 r34 : e0019ea5fe20
> r35 : fffe r36 : e001261917a0 r37 : e0014ff060b8
> r38 : e00126191790 r39 : e0014ff06178 r40 : a0010017c540
> r41 : 0915 r42 : a00100a90050
> 
> Here is the beginning of rb_insert_color():
> 
> void rb_insert_color(struct rb_node *node, struct rb_root *root)
> {
> struct rb_node *parent, *gparent;
> 
> while ((parent = rb_parent(node)) && rb_is_red(parent)) {
> gparent = rb_parent(parent);
> if (parent == gparent->rb_left) {
> 
> When it crashes, I've got the following nodes:
> 
> p/x *((struct rb_node *) 0xe004acb19448)// node
> {
>   rb_parent_color = 0xe002799a5908,
>   rb_right = 0x0,
>   rb_left = 0x0
> }
> p/x *((struct rb_node *) 0xe002799a5908)// parent = rb_parent(node)
> {
>   rb_parent_color = 0x0,
>   rb_right = 0x0,
>   rb_left = 0xa0010065// seems to be valid
> }
> 
> Note that "node" is not necessarily the same as the argument of
> rb_insert_color() was.
> 
> gparent = rb_parent(parent) is NULL, and the kernel obviously traps
> at if (parent == gparent->rb_left).
> 
> Does the algorithm guarantee that if a node is red, it must have a parent?
> I guess yes.
> (I have not seen any modification in rb_insert_color() since my 2.6.18.8.)
> 
> Is mutex_lock(>i_mutex) in vfs_readdir() enough to protect the tree?
> I guess yes.
> 
> I have got no idea how it can happen.
> Has something been corrected since?
> 
> Regards,
> 
> Zoltan Menyhart
> 
> 
> --
> To unsubscribe from this 

Re: [PATCH] xfs: add hot tracking support.

[Dave Chinner]

On Wed, Nov 07, 2012 at 04:38:23PM +0800, Zhi Yong Wu wrote:
> HI, Dave,
> 
> I guess that you should add some hot tracking stuff in some
> xfs_show_xxx function, right?

Yes, it should - I thought I did that. I recall seeing int
/proc/mounts, but maybe I was just hallucinating. I'll send an
updated version when I get to fixing it.

Cheers,

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

Re: [PATCH] eCryptfs: Avoid unnecessary disk read and data decryption during writing

[Tyler Hicks]

On 2012-10-30 19:52:40, Li Wang wrote:
> ecryptfs_write_begin grabs a page from page cache for writing.
> If the page contains invalid data, or data older than the
> counterpart on the disk, eCryptfs will read out the
> corresponing data from the disk into the page, decrypt them,
> then perform writing. However, for this page, if the length
> of the data to be written into is equal to page size,
> that means the whole page of data will be overwritten,
> in which case, it does not matter whatever the data were before,
> it is beneficial to perform writing directly rather than bothering
> to read and decrypt first.
> 
> With this optimization, according to our test on a machine with
> Intel Core 2 Duo processor, iozone 'write' operation on an existing
> file with write size being multiple of page size will enjoy a steady
> 3x speedup.
> 
> Signed-off-by: Li Wang 
> Signed-off-by: Yunchuan Wen 
> Reviewed-by: Tyler Hicks 

Thanks again, Li. I've pushed this to my next branch.

I lost track of it last time. Sorry about that!

Tyler

> ---
>  fs/ecryptfs/mmap.c |   12 ++--
>  1 files changed, 10 insertions(+), 2 deletions(-)
> 
> diff --git a/fs/ecryptfs/mmap.c b/fs/ecryptfs/mmap.c
> index bd1d57f..564a1fa 100644
> --- a/fs/ecryptfs/mmap.c
> +++ b/fs/ecryptfs/mmap.c
> @@ -338,7 +338,8 @@ static int ecryptfs_write_begin(struct file *file,
>   if (prev_page_end_size
>   >= i_size_read(page->mapping->host)) {
>   zero_user(page, 0, PAGE_CACHE_SIZE);
> - } else {
> + SetPageUptodate(page);
> + } else if (len < PAGE_CACHE_SIZE) {
>   rc = ecryptfs_decrypt_page(page);
>   if (rc) {
>   printk(KERN_ERR "%s: Error decrypting "
> @@ -348,8 +349,8 @@ static int ecryptfs_write_begin(struct file *file,
>   ClearPageUptodate(page);
>   goto out;
>   }
> + SetPageUptodate(page);
>   }
> - SetPageUptodate(page);
>   }
>   }
>   /* If creating a page or more of holes, zero them out via truncate.
> @@ -499,6 +500,13 @@ static int ecryptfs_write_end(struct file *file,
>   }
>   goto out;
>   }
> + if (!PageUptodate(page)) {
> + if (copied < PAGE_CACHE_SIZE) {
> + rc = 0;
> + goto out;
> + }
> + SetPageUptodate(page);
> + }
>   /* Fills in zeros if 'to' goes beyond inode size */
>   rc = fill_zeros_to_end_of_page(page, to);
>   if (rc) {
> -- 
> 1.7.6.5
> 
> --
> To unsubscribe from this list: send the line "unsubscribe ecryptfs" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html


signature.asc
Description: Digital signature

[ANNOUNCE] kmod 11

[Lucas De Marchi]

kmod 11 is out:

ftp://ftp.kernel.org/pub/linux/utils/kernel/kmod/kmod-11.tar.xz
ftp://ftp.kernel.org/pub/linux/utils/kernel/kmod/kmod-11.tar.sign

This is the greatest release ever for those using compressed modules
(I'd like to rather remove it, but some distros are using it so it's
unlikely to happen soon). When using compressed modules there was a
bug regarding modules.order since forever. Now distros don't have to
tweak this file anymore and user can freely mix compressed and
non-compressed modules.

The time needed for running depmod has been greatly reduced with this
release. And this is not exclusive to those using compressed modules.
For non-compressed modules there were reports of a speedup of 3x in
depmod. Check 
http://git.kernel.org/?p=utils/kernel/kmod/kmod.git;a=commit;h=1eff942e37adda55bd8c506d4e2a7970fdbf7a74
for details... the timings got improved even more after that commit.

Testsuite also got bug fixes and is now capable of comparing output
files to decide if a test succeeded. Other projects using our
testsuite should upgrade to this new version.

Due to the major refactor in depmod needed to accomplish the speedup
mentioned above, I thought about releasing a -rc1 but then decided to
go straight with a release since it would probably not help a lot.
Please give it more time than usual in your distro testing repository.
If a major bug is found I'll just release another version sooner than
usual.

Last but not least, "--wait" option to rmmod is gone. Or at least it's
now hidden and causing a sleep of 10s if user decides to use it. The
reason is that this feature is being deprecated on kernel side since
it doesn't have any good reason to exist and causes some pain to
maintain.

Take a look in NEWS file for more details on changes. Shortlog is below.

Cheers!
Lucas De Marchi

---

Dave Reisner (5):
  Revert "build-sys: disable jobserver for rootfs target"
  Define rootfs as dependency of check-am
  Makefile: remove redundant flags to $(RM)
  modinfo: clarify verbiage for field shortcuts
  build-sys: Remove --with-rootprefix option

Jan Engelhardt (1):
  NEWS: language corrections

Leandro Pereira (1):
  libkmod-hash: Plug possible memory leak when free_value is defined

Lucas De Marchi (38):
  testsuite: Fix double definition of 64-bits variant
  build-sys: Append -Werror when testing flags
  depmod: fix parsing of modules.order with compressed modules
  testsuite: allow to check generated files
  testsuite: add depmod test for modules.alias
  libkmod: Add support for '.' in module parameter on kcmdline
  rmmod: Deprecate --wait option
  libkmod: cache open file for later access
  build-sys: use AS_IF autoconf macro
  depmod: do not create a hole in struct depmod
  depmod: cache info_list in struct mod
  depmod: cache dependency_symbol list in struct mod
  depmod: use our copy of modname instead of calling libkmod
  depmod: unref kmod_module once we don't need it anymore
  modprobe: exit in one place
  modprobe: use prio_to_str() helper
  modprobe: prefix libkmod messages to stderr with modprobe:
  modprobe: move log function
  modprobe: prefix log messages to stderr with modprobe
  modprobe: use ERR() instead of fprintf(stderr, ...)
  depmod: prefer ERR and WRN over plain fprintf
  TODO: update file with tasks
  depmod: remove inline from _log
  depmod: add depmod prefix to log messages
  insmod: prefer ERR over plain fprintf
  modinfo: prefer ERR over plain fprintf
  rmmod: prefer ERR over plain fprintf
  rmmod: route all messages to syslog if told to
  tools: share getting program name from argv for all tools
  tools: share function to convert prio to string
  tools: make usage() messages go to stdout rather than stderr
  tools: use a single function for logging libkmod output
  tools: share setting up libkmod log
  tools: share function for logging
  tools: staticize functions that are now only used in log.c
  tools: use program_invocation_short_name provided by libc
  TODO: remove completed action
  kmod 11

Sami Kerola (1):
  build-sys: require xsltproc when manpages are enabled
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 6/9] cgroup_freezer: make freezer->state mask of flags

[Kamezawa Hiroyuki]

(2012/11/08 13:42), Tejun Heo wrote:

Hello, Kame.

On Thu, Nov 08, 2012 at 01:37:50PM +0900, Kamezawa Hiroyuki wrote:

How about
enum {
__CGROUP_FREEZING,
__CGROUP_FROZEN,
};

#define CGROUP_FREEZER_STATE_MASK  0x3
#define CGROUP_FREEZER_STATE(state) ((state) & CGROUP_FREEZER_STATE_MASK)
#define CGROUP_THAW(state)  (CGROUP_FREEZER_STATE(state) == 0)
#define CGROUP_FREEZING(state)  (CGROUP_FREEZER_STATE(state) == 
__CGROUP_FREEZING)
#define CGROUP_FROZEN(state)\
(CGROUP_FREEZER_STATE(state) == (__CGROUP_FREEZING | __CGROUP_FROZEN))


I think it's a bit overdone and we have cases where we test for
FREEZING regardless of FROZEN and cases where test for FREEZING &&
!FROZEN.  We can have, say, CGROUP_FREZING() and then
CGROUP_FREEZING_BUT_NOT_FROZEN(), but it feels more like obfuscation
than anything else.



Hm, then, I'm glad if I can see what combinations of flags are valid and
meanings of them in source code comments.

Anyway,
Reviewed-by: KAMEZAWA Hiroyuki 


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

Re: [PATCH 7/9] cgroup_freezer: introduce CGROUP_FREEZING_[SELF|PARENT]

[Kamezawa Hiroyuki]

(2012/11/08 13:45), Tejun Heo wrote:

Hello,

On Thu, Nov 08, 2012 at 01:42:22PM +0900, Kamezawa Hiroyuki wrote:

(2012/11/03 17:38), Tejun Heo wrote:

Introduce FREEZING_SELF and FREEZING_PARENT and make FREEZING OR of
the two flags.  This is to prepare for full hierarchy support.

freezer_apply_date() is updated such that it can handle setting and
clearing of both flags.  The two flags are also exposed to userland
via read-only files self_freezing and parent_freezing.

Other than the added cgroupfs files, this patch doesn't introduce any
behavior change.

Signed-off-by: Tejun Heo 


What is the purpose of FREEZING_SELG/PARENT, having 2 flags and
make it visible to users ?


SELF is the configuration of the current cgroup, PARENT is freezing
state inherited from an ancestor.  If either is set, the cgroup is
freezing.  Without the two conditions visible to userland, it can get
a bit confusing as echoing "THAWED" to state may not do anything to
the cgroup.


Got it, thank you. I'm glad if you add some more explanation in comments
and considered use-case in changelog.

Reviewed-by: KAMEZAWA Hiroyuki 

Thanks,
-Kame





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

[Stephen Rothwell]

Hi all,

Changes since 20121107:

The pci tree still has its build failure for which I applied a merge fix patch.

The v4l-dvb tree still has its build failure so I used the version from
next-20121026.

The pinctrl tree still has its build failure for which I applied a patch.



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" as mentioned in the FAQ on the wiki
(see below).

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. After the
final fixups (if any), it is also built with powerpc allnoconfig (32 and
64 bit), ppc44x_defconfig and allyesconfig (minus
CONFIG_PROFILE_ALL_BRANCHES - this fails its final link) and i386, sparc,
sparc64 and arm defconfig. These builds also have
CONFIG_ENABLE_WARN_DEPRECATED, CONFIG_ENABLE_MUST_CHECK and
CONFIG_DEBUG_INFO disabled when necessary.

Below is a summary of the state of the merge.

We are up to 209 trees (counting Linus' and 28 trees of patches pending
for Linus' tree), more are welcome (even if they are currently empty).
Thanks to those who have contributed, and to those who haven't, please do.

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.

There is a wiki covering stuff to do with linux-next at
http://linux.f-seidel.de/linux-next/pmwiki/ .  Thanks to Frank Seidel.

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

$ git checkout master
$ git reset --hard stable
Merging origin/master (0e4a43e Merge 
git://git.kernel.org/pub/scm/linux/kernel/git/steve/gfs2-3.0-fixes)
Merging fixes/master (12250d8 Merge branch 'i2c-embedded/for-next' of 
git://git.pengutronix.de/git/wsa/linux)
Merging kbuild-current/rc-fixes (bad9955 menuconfig: Replace CIRCLEQ by 
list_head-style lists.)
Merging arm-current/fixes (6404f0b ARM: 7569/1: mm: uninitialized warning 
corrections)
Merging m68k-current/for-linus (8a745ee m68k: Wire up kcmp)
Merging powerpc-merge/merge (8c23f40 Merge 
git://git.kernel.org/pub/scm/virt/kvm/kvm)
Merging sparc/master (afe760e sparc: Allow OF_GPIO on sparc.)
Merging net/master (a3d744e af-packet: fix oops when socket is not present)
Merging sound-current/for-linus (d1a3c98 ALSA: hdspm - Fix sync check reporting 
on RME RayDAT)
Merging pci-current/for-linus (ff8e59b PCI/portdrv: Don't create hotplug slots 
unless port supports hotplug)
Merging wireless/master (6fe7cc7 ath9k: Test for TID only in BlockAcks while 
checking tx status)
Merging driver-core.current/driver-core-linus (8f0d816 Linux 3.7-rc3)
Merging tty.current/tty-linus (8f0d816 Linux 3.7-rc3)
Merging usb.current/usb-linus (d99e65b USB: fix build with XEN and 
EARLY_PRINTK_DBGP enabled but USB_SUPPORT disabled)
Merging staging.current/staging-linus (8f0d816 Linux 3.7-rc3)
Merging char-misc.current/char-misc-linus (8f0d816 Linux 3.7-rc3)
Merging input-current/for-linus (32ed191 Input: tsc40 - remove wrong 
announcement of pressure support)
Merging md-current/for-linus (ed30be0 MD RAID10: Fix oops when creating RAID10 
arrays via dm-raid.c)
Merging audit-current/for-linus (c158a35 audit: no leading space in 
audit_log_d_path prefix)
Merging crypto-current/master (9efade1 crypto: cryptd - disable softirqs in 
cryptd_queue_worker to prevent data corruption)
Merging ide/master (9974e43 ide: fix generic_ide_suspend/resume Oops)
Merging dwmw2/master (244dc4e Merge 
git://git.infradead.org/users/dwmw2/random-2.6)
Merging sh-current/sh-fixes-for-linus (4403310 SH: Convert out[bwl] macros to 
inline functions)
Merging irqdomain-current/irqdomain/merge (15e06bf irqdomain: Fix debugfs 
formatting)
Merging devicetree-current/devicetree/merge (4e8383b of: release node fix for 
of_parse_phandle_with_args)
Merging spi-current/spi/merge (d1c185b of/spi: Fix SPI module loading by using 
proper "spi:" modalias prefixes.)
Merging gpio-current/gpio/merge (96b7064 gpio/tca6424: merge I2C transactions, 
remove cast)
Merging rr-fixes/fixes (f6a79af modules: don't break modules_install on 
external modules with no key.)
Merging asm-generic/master (9b04ebd asm-generic/io.h: remove asm/cacheflush.h 
include)
Merging arm/for-next (ee05d61 Merge remote-tracking branch 'wildea/asids' into 
for-next)
Merging arm-perf/for-n

RE: [PATCH 2/4] ARM: EXYNOS: PL330 MDMA1 fix for revision 0 of Exynos4210 SOC

[Kukjin Kim]

Bartlomiej Zolnierkiewicz wrote:
> 
> > Hmm...above change and adding definition of EXYNOS_PA_S_MDMA1 address
> > can fix the problem you commented on EXYNOS4210 Rev0 without others?...
> 
> The problem is affecting only EXYNOS4210 Rev0 and the fix is applied only
> for case when soc_is_exynos4210() && samsung_rev() == EXYNOS4210_REV_0,
> or did you mean something else?
> 
Yeah, I know. I mean just adding secure mdma1 address is enough for
exynos4210 rev0.

8<-
@@ -275,6 +275,9 @@ static int __init exynos_dma_init(void)
exynos_pdma1_pdata.nr_valid_peri =
ARRAY_SIZE(exynos4210_pdma1_peri);
exynos_pdma1_pdata.peri_id = exynos4210_pdma1_peri;
+
+   if (samsung_rev() == EXYNOS4210_REV_0)
+   exynos_mdma1_device.res.start = EXYNOS4_PA_S_MDMA1;
} else if (soc_is_exynos4212() || soc_is_exynos4412()) {
exynos_pdma0_pdata.nr_valid_peri =
ARRAY_SIZE(exynos4212_pdma0_peri);
diff --git a/arch/arm/mach-exynos/include/mach/map.h
b/arch/arm/mach-exynos/include/mach/map.h
index 8480849..0abfe78 100644
--- a/arch/arm/mach-exynos/include/mach/map.h
+++ b/arch/arm/mach-exynos/include/mach/map.h
@@ -90,6 +90,7 @@
 
 #define EXYNOS4_PA_MDMA0   0x1081
 #define EXYNOS4_PA_MDMA1   0x1285
+#define EXYNOS4_PA_S_MDMA1 0x1284
 #define EXYNOS4_PA_PDMA0   0x1268
 #define EXYNOS4_PA_PDMA1   0x1269
 #define EXYNOS5_PA_MDMA0   0x1080
8<

Thanks.

Best regards,
Kgene.
--
Kukjin Kim , Senior Engineer,
SW Solution Development Team, Samsung Electronics Co., Ltd.

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

Re: [PATCH 8/9] cgroup_freezer: add ->post_create() and ->pre_destroy() and track online state

[Kamezawa Hiroyuki]

(2012/11/03 17:38), Tejun Heo wrote:
> A cgroup is online and visible to iteration between ->post_create()
> and ->pre_destroy().  This patch introduces CGROUP_FREEZER_ONLINE and
> toggles it from the newly added freezer_post_create() and
> freezer_pre_destroy() while holding freezer->lock such that a
> cgroup_freezer can be reilably distinguished to be online.  This will
> be used by full hierarchy support.
> 
> ONLINE test is added to freezer_apply_state() but it currently doesn't
> make any difference as freezer_write() can only be called for an
> online cgroup.
> 
> Adjusting system_freezing_cnt on destruction is moved from
> freezer_destroy() to the new freezer_pre_destroy() for consistency.
> 
> This patch doesn't introduce any noticeable behavior change.
> 
> Signed-off-by: Tejun Heo 
> ---
>   kernel/cgroup_freezer.c | 42 --
>   1 file changed, 40 insertions(+), 2 deletions(-)
> 
> diff --git a/kernel/cgroup_freezer.c b/kernel/cgroup_freezer.c
> index b8ad93c..4f12d31 100644
> --- a/kernel/cgroup_freezer.c
> +++ b/kernel/cgroup_freezer.c
> @@ -23,6 +23,7 @@
>   #include 
>   
>   enum freezer_state_flags {
> + CGROUP_FREEZER_ONLINE   = (1 << 0), /* freezer is fully online */

Could you explain what 'online' means here again, rather than changelog ?
BTW, 'online' is a shared concept, between post_create() and pre_destroy(), 
among
developpers ? Is it new ?

Anyway, the patch itself is simple.

Reviewed-by: KAMEZAWA Hiroyuki 


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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: ACPI errors with 3.7-rc3

[Greg KH]

On Wed, Nov 07, 2012 at 10:49:40PM +0100, Rafael J. Wysocki wrote:
> On Tuesday, November 06, 2012 01:48:26 PM Greg KH wrote:
> > On Tue, Nov 06, 2012 at 04:42:24PM +0400, Azat Khuzhin wrote:
> > > I'v also have such errors on my macbook pro.
> > > 
> > > $ dmesg | tail
> > > [17056.008564] ACPI Error: Method parse/execution failed
> > > [\_SB_.PCI0.LPCB.EC__.SMB0.SBRW] (Node 88026547ea10), AE_TIME
> > > (20120711/psparse-536)
> > > [17056.011194] ACPI Error: Method parse/execution failed
> > > [\_SB_.BAT0.UBST] (Node 88026547e678), AE_TIME
> > > (20120711/psparse-536)
> > > [17056.013793] ACPI Error: Method parse/execution failed
> > > [\_SB_.BAT0._BST] (Node 88026547e740), AE_TIME
> > > (20120711/psparse-536)
> > > [17056.016383] ACPI Exception: AE_TIME, Evaluating _BST 
> > > (20120711/battery-464)
> > > [17056.511373] ACPI: EC: input buffer is not empty, aborting transaction
> > > [17056.512672] ACPI Exception: AE_TIME, Returned by Handler for
> > > [EmbeddedControl] (20120711/evregion-501)
> > > [17056.515256] ACPI Error: Method parse/execution failed
> > > [\_SB_.PCI0.LPCB.EC__.SMB0.SBRW] (Node 88026547ea10), AE_TIME
> > > (20120711/psparse-536)
> > > [17056.517886] ACPI Error: Method parse/execution failed
> > > [\_SB_.BAT0.UBST] (Node 88026547e678), AE_TIME
> > > (20120711/psparse-536)
> > > [17056.520479] ACPI Error: Method parse/execution failed
> > > [\_SB_.BAT0._BST] (Node 88026547e740), AE_TIME
> > > (20120711/psparse-536)
> > > [17056.523070] ACPI Exception: AE_TIME, Evaluating _BST 
> > > (20120711/battery-464)
> > 
> > I'm seeing this again right now.  I'm wondering if it's because I'm
> > running on battery power at the moment:
> > 
> > [41694.309264] ACPI Exception: AE_TIME, Returned by Handler for 
> > [EmbeddedControl] (20120913/evregion-501)
> > [41694.309282] ACPI Error: Method parse/execution failed 
> > [\_SB_.PCI0.LPCB.EC__.SMB0.SBRW] (Node 88045cc64618), AE_TIME 
> > (20120913/psparse-536)
> > [41694.309300] ACPI Error: Method parse/execution failed [\_SB_.BAT0.UBST] 
> > (Node 88045cc64988), AE_TIME (20120913/psparse-536)
> > [41694.309310] ACPI Error: Method parse/execution failed [\_SB_.BAT0._BST] 
> > (Node 88045cc648c0), AE_TIME (20120913/psparse-536)
> > [41694.309324] ACPI Exception: AE_TIME, Evaluating _BST 
> > (20120913/battery-464)
> > [41694.809093] ACPI: EC: input buffer is not empty, aborting transaction
> > 
> > ec_storm_threshold is still set to 8 in /sys/module/acpi/parameters/ so 
> > that's
> > not the issue here.
> > 
> > > And also loadavg is too high ~ 10
> > > While there is no process that load CPU up to 100% or like that.
> > > I think that this because of processes that is done in kernel space.
> > > (basically that one who write such errors)
> > > 
> > > $ uname -a
> > > Linux macbook-pro-sq 3.6.5macbook-pro-custom-v0.1 #4 SMP Sun Nov 4
> > > 12:39:03 UTC 2012 x86_64 GNU/Linux
> > 
> > Ah, ok, that means it's not something new in 3.7-rc, so maybe it's just 
> > never
> > worked properly for this hardware :)
> > 
> > So it's not a regression, just an ACPI issue, any ACPI developer have an 
> > idea
> > about this?
> 
> Can you please send the output of acpidump from the affected machine(s)?

# ./acpidump
ACPI tables were not found. If you know location of RSD PTR table (from dmesg, 
etc), supply it with either --addr or -a option

What am I doing wrong here?

Is there a newer version of pmtools than the one labled pmtools-20071116
that I should be using?  A link to download it would be appreciated.

thanks,

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

Re: [PATCH 7/9] cgroup_freezer: introduce CGROUP_FREEZING_[SELF|PARENT]

[Tejun Heo]

Hello,

On Thu, Nov 08, 2012 at 01:42:22PM +0900, Kamezawa Hiroyuki wrote:
> (2012/11/03 17:38), Tejun Heo wrote:
> >Introduce FREEZING_SELF and FREEZING_PARENT and make FREEZING OR of
> >the two flags.  This is to prepare for full hierarchy support.
> >
> >freezer_apply_date() is updated such that it can handle setting and
> >clearing of both flags.  The two flags are also exposed to userland
> >via read-only files self_freezing and parent_freezing.
> >
> >Other than the added cgroupfs files, this patch doesn't introduce any
> >behavior change.
> >
> >Signed-off-by: Tejun Heo 
> 
> What is the purpose of FREEZING_SELG/PARENT, having 2 flags and
> make it visible to users ?

SELF is the configuration of the current cgroup, PARENT is freezing
state inherited from an ancestor.  If either is set, the cgroup is
freezing.  Without the two conditions visible to userland, it can get
a bit confusing as echoing "THAWED" to state may not do anything to
the cgroup.

Thanks.

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

Re: [PATCH] Thermal: exynos: Add support for temperature falling interrupt.

[Amit Kachhap]

Hi Jonghwa Lee,

Adding Zhang Rui and Durgadoss.

I reviewed and tested this patch. This is a nice feature to have but
this will not call the cpufreq cooling device properly as thermal
framework calls the frequency states in a step wise fashion which is
not possible if we disable polling completely. I submitted a patch to
fix this issue.
Also some minor review comments below which I have already fixed in my
patchset.

Thanks,
Amit

On 1 November 2012 13:17, Jonghwa Lee  wrote:
> This patch introduces using temperature falling interrupt in exynos
> thermal driver. Former patch, it only use polling way to check
> whether if system themperature is fallen. However, exynos SOC also
> provides temperature falling interrupt way to do same things by hw.
> This feature is not supported in exynos4210.
>
> Signed-off-by: Jonghwa Lee 
> ---
>  drivers/thermal/exynos_thermal.c |   81 
> +++---
>  include/linux/platform_data/exynos_thermal.h |3 +
>  2 files changed, 49 insertions(+), 35 deletions(-)
>
> diff --git a/drivers/thermal/exynos_thermal.c 
> b/drivers/thermal/exynos_thermal.c
> index 4bdd1eb..f91a699 100644
> --- a/drivers/thermal/exynos_thermal.c
> +++ b/drivers/thermal/exynos_thermal.c
> @@ -94,6 +94,7 @@
>  #define SENSOR_NAME_LEN16
>  #define MAX_TRIP_COUNT 8
>  #define MAX_COOLING_DEVICE 4
> +#define MAX_THRESHOLD_LEVS 4
>
>  #define ACTIVE_INTERVAL 500
>  #define IDLE_INTERVAL 1
> @@ -133,6 +134,7 @@ struct exynos_tmu_data {
>  struct thermal_trip_point_conf {
> int trip_val[MAX_TRIP_COUNT];
> int trip_count;
> +   u8 trigger_falling;
>  };
>
>  struct thermal_cooling_conf {
> @@ -182,7 +184,8 @@ static int exynos_set_mode(struct thermal_zone_device 
> *thermal,
>
> mutex_lock(_zone->therm_dev->lock);
>
> -   if (mode == THERMAL_DEVICE_ENABLED)
> +   if (mode == THERMAL_DEVICE_ENABLED &&
> +   !th_zone->sensor_conf->trip_data.trigger_falling)
> th_zone->therm_dev->polling_delay = IDLE_INTERVAL;
> else
> th_zone->therm_dev->polling_delay = 0;
> @@ -421,7 +424,8 @@ static void exynos_report_trigger(void)
> break;
> }
>
> -   if (th_zone->mode == THERMAL_DEVICE_ENABLED) {
> +   if (th_zone->mode == THERMAL_DEVICE_ENABLED &&
> +   !th_zone->sensor_conf->trip_data.trigger_falling) {
> if (i > 0)
> th_zone->therm_dev->polling_delay = ACTIVE_INTERVAL;
> else
> @@ -460,7 +464,8 @@ static int exynos_register_thermal(struct 
> thermal_sensor_conf *sensor_conf)
>
> th_zone->therm_dev = thermal_zone_device_register(sensor_conf->name,
> EXYNOS_ZONE_COUNT, 0, NULL, _dev_ops, 0,
> -   IDLE_INTERVAL);
> +   sensor_conf->trip_data.trigger_falling ?
> +   0 : IDLE_INTERVAL);
>
> if (IS_ERR(th_zone->therm_dev)) {
> pr_err("Failed to register thermal zone device\n");
> @@ -567,8 +572,9 @@ static int exynos_tmu_initialize(struct platform_device 
> *pdev)
>  {
> struct exynos_tmu_data *data = platform_get_drvdata(pdev);
> struct exynos_tmu_platform_data *pdata = data->pdata;
> -   unsigned int status, trim_info, rising_threshold;
> -   int ret = 0, threshold_code;
> +   unsigned int status, trim_info;
> +   unsigned int rising_threshold = 0, falling_threshold = 0;
> +   int ret = 0, threshold_code, i, trigger_levs = 0;
>
> mutex_lock(>lock);
> clk_enable(data->clk);
> @@ -593,6 +599,11 @@ static int exynos_tmu_initialize(struct platform_device 
> *pdev)
> (data->temp_error2 != 0))
> data->temp_error1 = pdata->efuse_value;
>
> +   /* Count trigger levels to be enabled */
> +   for (i = 0; i < MAX_THRESHOLD_LEVS; i++)
> +   if (pdata->trigger_levels[i])
> +   trigger_levs++;
> +
> if (data->soc == SOC_ARCH_EXYNOS4210) {
> /* Write temperature code for threshold */
> threshold_code = temp_to_code(data, pdata->threshold);
> @@ -602,44 +613,38 @@ static int exynos_tmu_initialize(struct platform_device 
> *pdev)
> }
> writeb(threshold_code,
> data->base + EXYNOS4210_TMU_REG_THRESHOLD_TEMP);
> -
> -   writeb(pdata->trigger_levels[0],
> -   data->base + EXYNOS4210_TMU_REG_TRIG_LEVEL0);
> -   writeb(pdata->trigger_levels[1],
> -   data->base + EXYNOS4210_TMU_REG_TRIG_LEVEL1);
> -   writeb(pdata->trigger_levels[2],
> -   data->base + EXYNOS4210_TMU_REG_TRIG_LEVEL2);
> -   writeb(pdata->trigger_levels[3],
> -   data->base + EXYNOS4210_TMU_REG_TRIG_LEVEL3);
> +   for (i = 0; i < trigger_levs; i++)
> +   

Re: [PATCH 6/9] cgroup_freezer: make freezer->state mask of flags

[Tejun Heo]

Hello, Kame.

On Thu, Nov 08, 2012 at 01:37:50PM +0900, Kamezawa Hiroyuki wrote:
> How about
> enum {
>__CGROUP_FREEZING,
>__CGROUP_FROZEN,
> };
> 
> #define CGROUP_FREEZER_STATE_MASK  0x3
> #define CGROUP_FREEZER_STATE(state)   ((state) & CGROUP_FREEZER_STATE_MASK)
> #define CGROUP_THAW(state)(CGROUP_FREEZER_STATE(state) == 0)
> #define CGROUP_FREEZING(state)(CGROUP_FREEZER_STATE(state) == 
> __CGROUP_FREEZING)
> #define CGROUP_FROZEN(state)\
>   (CGROUP_FREEZER_STATE(state) == (__CGROUP_FREEZING | __CGROUP_FROZEN))

I think it's a bit overdone and we have cases where we test for
FREEZING regardless of FROZEN and cases where test for FREEZING &&
!FROZEN.  We can have, say, CGROUP_FREZING() and then
CGROUP_FREEZING_BUT_NOT_FROZEN(), but it feels more like obfuscation
than anything else.

> >@@ -290,9 +284,9 @@ static int freezer_write(struct cgroup *cgroup, struct 
> >cftype *cft,
> >  {
> > bool freeze;
> >
> >-if (strcmp(buffer, freezer_state_strs[CGROUP_THAWED]) == 0)
> >+if (strcmp(buffer, freezer_state_strs(0)) == 0)
> 
> Can't we have a name for "0" ?

We can define CGROUP_THAWED to be zero.  I'd rather keep it explicitly
zero tho.  freezer state is mask of freezing and frozen flags and no
flag set means thawed.

Thanks.

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

Re: [PATCH 7/9] cgroup_freezer: introduce CGROUP_FREEZING_[SELF|PARENT]

[Kamezawa Hiroyuki]

(2012/11/03 17:38), Tejun Heo wrote:

Introduce FREEZING_SELF and FREEZING_PARENT and make FREEZING OR of
the two flags.  This is to prepare for full hierarchy support.

freezer_apply_date() is updated such that it can handle setting and
clearing of both flags.  The two flags are also exposed to userland
via read-only files self_freezing and parent_freezing.

Other than the added cgroupfs files, this patch doesn't introduce any
behavior change.

Signed-off-by: Tejun Heo 


What is the purpose of FREEZING_SELG/PARENT, having 2 flags and
make it visible to users ?

Thanks,
-Kame




---
  kernel/cgroup_freezer.c | 55 ++---
  1 file changed, 47 insertions(+), 8 deletions(-)

diff --git a/kernel/cgroup_freezer.c b/kernel/cgroup_freezer.c
index e76aa9f..b8ad93c 100644
--- a/kernel/cgroup_freezer.c
+++ b/kernel/cgroup_freezer.c
@@ -23,8 +23,12 @@
  #include 

  enum freezer_state_flags {
-   CGROUP_FREEZING = (1 << 1), /* this freezer is freezing */
+   CGROUP_FREEZING_SELF= (1 << 1), /* this freezer is freezing */
+   CGROUP_FREEZING_PARENT  = (1 << 2), /* the parent freezer is freezing */
CGROUP_FROZEN   = (1 << 3), /* this and its descendants frozen 
*/
+
+   /* mask for all FREEZING flags */
+   CGROUP_FREEZING = CGROUP_FREEZING_SELF | CGROUP_FREEZING_PARENT,
  };

  struct freezer {
@@ -245,8 +249,13 @@ static void unfreeze_cgroup(struct freezer *freezer)
   * freezer_apply_state - apply state change to a single cgroup_freezer
   * @freezer: freezer to apply state change to
   * @freeze: whether to freeze or unfreeze
+ * @state: CGROUP_FREEZING_* flag to set or clear
+ *
+ * Set or clear @state on @cgroup according to @freeze, and perform
+ * freezing or thawing as necessary.
   */
-static void freezer_apply_state(struct freezer *freezer, bool freeze)
+static void freezer_apply_state(struct freezer *freezer, bool freeze,
+   unsigned int state)
  {
/* also synchronizes against task migration, see freezer_attach() */
lockdep_assert_held(>lock);
@@ -254,13 +263,19 @@ static void freezer_apply_state(struct freezer *freezer, 
bool freeze)
if (freeze) {
if (!(freezer->state & CGROUP_FREEZING))
atomic_inc(_freezing_cnt);
-   freezer->state |= CGROUP_FREEZING;
+   freezer->state |= state;
freeze_cgroup(freezer);
} else {
-   if (freezer->state & CGROUP_FREEZING)
-   atomic_dec(_freezing_cnt);
-   freezer->state &= ~(CGROUP_FREEZING | CGROUP_FROZEN);
-   unfreeze_cgroup(freezer);
+   bool was_freezing = freezer->state & CGROUP_FREEZING;
+
+   freezer->state &= ~state;
+
+   if (!(freezer->state & CGROUP_FREEZING)) {
+   if (was_freezing)
+   atomic_dec(_freezing_cnt);
+   freezer->state &= ~CGROUP_FROZEN;
+   unfreeze_cgroup(freezer);
+   }
}
  }

@@ -275,7 +290,7 @@ static void freezer_change_state(struct freezer *freezer, 
bool freeze)
  {
/* update @freezer */
spin_lock_irq(>lock);
-   freezer_apply_state(freezer, freeze);
+   freezer_apply_state(freezer, freeze, CGROUP_FREEZING_SELF);
spin_unlock_irq(>lock);
  }

@@ -295,6 +310,20 @@ static int freezer_write(struct cgroup *cgroup, struct 
cftype *cft,
return 0;
  }

+static u64 freezer_self_freezing_read(struct cgroup *cgroup, struct cftype 
*cft)
+{
+   struct freezer *freezer = cgroup_freezer(cgroup);
+
+   return (bool)(freezer->state & CGROUP_FREEZING_SELF);
+}
+
+static u64 freezer_parent_freezing_read(struct cgroup *cgroup, struct cftype 
*cft)
+{
+   struct freezer *freezer = cgroup_freezer(cgroup);
+
+   return (bool)(freezer->state & CGROUP_FREEZING_PARENT);
+}
+
  static struct cftype files[] = {
{
.name = "state",
@@ -302,6 +331,16 @@ static struct cftype files[] = {
.read_seq_string = freezer_read,
.write_string = freezer_write,
},
+   {
+   .name = "self_freezing",
+   .flags = CFTYPE_NOT_ON_ROOT,
+   .read_u64 = freezer_self_freezing_read,
+   },
+   {
+   .name = "parent_freezing",
+   .flags = CFTYPE_NOT_ON_ROOT,
+   .read_u64 = freezer_parent_freezing_read,
+   },
{ } /* terminate */
  };





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

Re: [PATCH 6/9] cgroup_freezer: make freezer->state mask of flags

[Kamezawa Hiroyuki]

(2012/11/03 17:38), Tejun Heo wrote:

freezer->state was an enum value - one of THAWED, FREEZING and FROZEN.
As the scheduled full hierarchy support requires more than one
freezing condition, switch it to mask of flags.  If FREEZING is not
set, it's thawed.  FREEZING is set if freezing or frozen.  If frozen,
both FREEZING and FROZEN are set.  Now that tasks can be attached to
an already frozen cgroup, this also makes freezing condition checks
more natural.

This patch doesn't introduce any behavior change.

Signed-off-by: Tejun Heo 
---
  kernel/cgroup_freezer.c | 60 ++---
  1 file changed, 27 insertions(+), 33 deletions(-)

diff --git a/kernel/cgroup_freezer.c b/kernel/cgroup_freezer.c
index 2690830..e76aa9f 100644
--- a/kernel/cgroup_freezer.c
+++ b/kernel/cgroup_freezer.c
@@ -22,15 +22,14 @@
  #include 
  #include 

-enum freezer_state {
-   CGROUP_THAWED = 0,
-   CGROUP_FREEZING,
-   CGROUP_FROZEN,
+enum freezer_state_flags {
+   CGROUP_FREEZING = (1 << 1), /* this freezer is freezing */
+   CGROUP_FROZEN   = (1 << 3), /* this and its descendants frozen 
*/
  };

  struct freezer {
struct cgroup_subsys_state  css;
-   enum freezer_state  state;
+   unsigned intstate;
spinlock_t  lock;
  };

@@ -48,12 +47,10 @@ static inline struct freezer *task_freezer(struct 
task_struct *task)

  bool cgroup_freezing(struct task_struct *task)
  {
-   enum freezer_state state;
bool ret;

rcu_read_lock();
-   state = task_freezer(task)->state;
-   ret = state == CGROUP_FREEZING || state == CGROUP_FROZEN;
+   ret = task_freezer(task)->state & CGROUP_FREEZING;
rcu_read_unlock();

return ret;
@@ -63,10 +60,13 @@ bool cgroup_freezing(struct task_struct *task)
   * cgroups_write_string() limits the size of freezer state strings to
   * CGROUP_LOCAL_BUFFER_SIZE
   */
-static const char *freezer_state_strs[] = {
-   "THAWED",
-   "FREEZING",
-   "FROZEN",
+static const char *freezer_state_strs(unsigned int state)
+{
+   if (state & CGROUP_FROZEN)
+   return "FROZEN";
+   if (state & CGROUP_FREEZING)
+   return "FREEZING";
+   return "THAWED";
  };

  /*
@@ -91,7 +91,6 @@ static struct cgroup_subsys_state *freezer_create(struct 
cgroup *cgroup)
return ERR_PTR(-ENOMEM);

spin_lock_init(>lock);
-   freezer->state = CGROUP_THAWED;
return >css;
  }

@@ -99,7 +98,7 @@ static void freezer_destroy(struct cgroup *cgroup)
  {
struct freezer *freezer = cgroup_freezer(cgroup);

-   if (freezer->state != CGROUP_THAWED)
+   if (freezer->state & CGROUP_FREEZING)
atomic_dec(_freezing_cnt);
kfree(freezer);
  }
@@ -129,15 +128,13 @@ static void freezer_attach(struct cgroup *new_cgrp, 
struct cgroup_taskset *tset)
 * Tasks in @tset are on @new_cgrp but may not conform to its
 * current state before executing the following - !frozen tasks may
 * be visible in a FROZEN cgroup and frozen tasks in a THAWED one.
-* This means that, to determine whether to freeze, one should test
-* whether the state equals THAWED.
 */
cgroup_taskset_for_each(task, new_cgrp, tset) {
-   if (freezer->state == CGROUP_THAWED) {
+   if (!(freezer->state & CGROUP_FREEZING)) {
__thaw_task(task);
} else {
freeze_task(task);
-   freezer->state = CGROUP_FREEZING;
+   freezer->state &= ~CGROUP_FROZEN;
}
}

@@ -159,11 +156,7 @@ static void freezer_fork(struct task_struct *task)
goto out;

spin_lock_irq(>lock);
-   /*
-* @task might have been just migrated into a FROZEN cgroup.  Test
-* equality with THAWED.  Read the comment in freezer_attach().
-*/
-   if (freezer->state != CGROUP_THAWED)
+   if (freezer->state & CGROUP_FREEZING)
freeze_task(task);
spin_unlock_irq(>lock);
  out:
@@ -184,7 +177,8 @@ static void update_if_frozen(struct freezer *freezer)
struct cgroup_iter it;
struct task_struct *task;

-   if (freezer->state != CGROUP_FREEZING)
+   if (!(freezer->state & CGROUP_FREEZING) ||
+   (freezer->state & CGROUP_FROZEN))
return;


Hmm

How about
enum {
   __CGROUP_FREEZING,
   __CGROUP_FROZEN,
};

#define CGROUP_FREEZER_STATE_MASK  0x3
#define CGROUP_FREEZER_STATE(state) ((state) & CGROUP_FREEZER_STATE_MASK)
#define CGROUP_THAW(state)  (CGROUP_FREEZER_STATE(state) == 0)
#define CGROUP_FREEZING(state)  (CGROUP_FREEZER_STATE(state) == 
__CGROUP_FREEZING)
#define CGROUP_FROZEN(state)\
(CGROUP_FREEZER_STATE(state) == (__CGROUP_FREEZING | __CGROUP_FROZEN))


cgroup_iter_start(cgroup, );

Re: [PATCH -next] ACPI: fix missing unlock on error in acpi_memory_remove_memory()

[Wei Yongjun]

Hi Wen,

On 11/08/2012 09:31 AM, Wen Congyang wrote:
> Hi, wei
>
> At 11/07/2012 08:38 PM, Wei Yongjun Wrote:
>> From: Wei Yongjun 
>>
>> Add the missing mutex_unlock() before return from function
>> acpi_memory_remove_memory() in the error handling case.
>>
>> Introduce by commit 85fcb3758c10e063a2a30dfad75017097999deed
>> 'ACPI / memory-hotplug: introduce a mutex lock to protect the list in 
>> acpi_memory_device'
>>
>> dpatch engine is used to auto generate this patch.
>> (https://github.com/weiyj/dpatch)
>>
>> Signed-off-by: Wei Yongjun 
> Thanks for your patch.
>
> Dan Carpenter has told me this problem. I fix it, but don't
> resend it because it is in test now.

I saw your patchset has already applied to linux-pm.git tree:
http://git.kernel.org/?p=linux/kernel/git/rafael/linux-pm.git;a=shortlog;h=refs/heads/linux-next

So I think what need is to send a new patch to fix it, not
resend the full patchset.

Regards,
Yongjun Wei

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] gpio: tegra: create irq mapping in gpio_to_irq

[Laxman Dewangan]

On Wednesday 07 November 2012 10:38 PM, Stephen Warren wrote:

On 11/07/2012 08:01 AM, Laxman Dewangan wrote:

The gpio interrupts get mapped linearly and hence the mapping
of irq need to be created by irq_create_mapping().

The function gpio_to_irq() returns the irq by irq_find_mapping()
and so returns 0 as there is no mapping created. Fix the function
to create mapping when gpio_to_irq() get called.

I'm not convinced this should be needed. tegra_gpio_probe() contains:



Oh, yes, I did not observe this code in my review. So this change is not 
resolving any issue.



I think we should move the mapping to gpio_to_irq() rather than doing 
this in probe.


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

[PATCH 3/4] thermal: exynos: Miscellaneous fixes to support falling threshold interrupt

[Amit Daniel Kachhap]

Below fixes are done to support falling threshold interrupt,
* Falling interrupt status macro corrected according to exynos5 data sheet.
* The get trend function modified to calculate trip temperature correctly.
* The clearing of interrupt status in the isr is now done after handling
  the the event that caused the interrupt.

Signed-off-by: Amit Daniel Kachhap 
Signed-off-by: Amit Daniel Kachhap 
---
 drivers/thermal/exynos_thermal.c |   18 +++---
 1 files changed, 11 insertions(+), 7 deletions(-)

diff --git a/drivers/thermal/exynos_thermal.c b/drivers/thermal/exynos_thermal.c
index f6667e8..bbaff56 100644
--- a/drivers/thermal/exynos_thermal.c
+++ b/drivers/thermal/exynos_thermal.c
@@ -82,7 +82,7 @@
 
 #define EXYNOS_TRIMINFO_RELOAD 0x1
 #define EXYNOS_TMU_CLEAR_RISE_INT  0x111
-#define EXYNOS_TMU_CLEAR_FALL_INT  (0x111 << 16)
+#define EXYNOS_TMU_CLEAR_FALL_INT  (0x111 << 12)
 #define EXYNOS_MUX_ADDR_VALUE  6
 #define EXYNOS_MUX_ADDR_SHIFT  20
 #define EXYNOS_TMU_TRIP_MODE_SHIFT 13
@@ -365,12 +365,19 @@ static int exynos_get_temp(struct thermal_zone_device 
*thermal,
 static int exynos_get_trend(struct thermal_zone_device *thermal,
int trip, enum thermal_trend *trend)
 {
-   if (thermal->temperature >= trip)
+   int ret = 0;
+   unsigned long trip_temp;
+
+   ret = exynos_get_trip_temp(thermal, trip, _temp);
+   if (ret < 0)
+   return ret;
+
+   if (thermal->temperature >= trip_temp)
*trend = THERMAL_TREND_RAISING;
else
*trend = THERMAL_TREND_DROPPING;
 
-   return 0;
+   return ret;
 }
 /* Operation callback functions for thermal zone */
 static struct thermal_zone_device_ops const exynos_dev_ops = {
@@ -704,10 +711,9 @@ static void exynos_tmu_work(struct work_struct *work)
struct exynos_tmu_data *data = container_of(work,
struct exynos_tmu_data, irq_work);
 
+   exynos_report_trigger();
mutex_lock(>lock);
clk_enable(data->clk);
-
-
if (data->soc == SOC_ARCH_EXYNOS)
writel(EXYNOS_TMU_CLEAR_RISE_INT |
EXYNOS_TMU_CLEAR_FALL_INT,
@@ -715,10 +721,8 @@ static void exynos_tmu_work(struct work_struct *work)
else
writel(EXYNOS4210_TMU_INTCLEAR_VAL,
data->base + EXYNOS_TMU_REG_INTCLEAR);
-
clk_disable(data->clk);
mutex_unlock(>lock);
-   exynos_report_trigger();
enable_irq(data->irq);
 }
 
-- 
1.7.1

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

[PATCH 2/4] Thermal: exynos: Add support for temperature falling interrupt.

[Amit Daniel Kachhap]

From: Jonghwa Lee 

This patch introduces using temperature falling interrupt in exynos
thermal driver. Former patch, it only use polling way to check
whether if system themperature is fallen. However, exynos SOC also
provides temperature falling interrupt way to do same things by hw.
This feature is not supported in exynos4210.

Signed-off-by: Jonghwa Lee 
Signed-off-by: Amit Daniel Kachhap 
---
 drivers/thermal/exynos_thermal.c |   81 +++---
 include/linux/platform_data/exynos_thermal.h |3 +
 2 files changed, 49 insertions(+), 35 deletions(-)

diff --git a/drivers/thermal/exynos_thermal.c b/drivers/thermal/exynos_thermal.c
index 7772d16..f6667e8 100644
--- a/drivers/thermal/exynos_thermal.c
+++ b/drivers/thermal/exynos_thermal.c
@@ -94,6 +94,7 @@
 #define SENSOR_NAME_LEN16
 #define MAX_TRIP_COUNT 8
 #define MAX_COOLING_DEVICE 4
+#define MAX_THRESHOLD_LEVS 4
 
 #define ACTIVE_INTERVAL 500
 #define IDLE_INTERVAL 1
@@ -125,6 +126,7 @@ struct exynos_tmu_data {
 struct thermal_trip_point_conf {
int trip_val[MAX_TRIP_COUNT];
int trip_count;
+   u8 trigger_falling;
 };
 
 struct thermal_cooling_conf {
@@ -174,7 +176,8 @@ static int exynos_set_mode(struct thermal_zone_device 
*thermal,
 
mutex_lock(_zone->therm_dev->lock);
 
-   if (mode == THERMAL_DEVICE_ENABLED)
+   if (mode == THERMAL_DEVICE_ENABLED &&
+   !th_zone->sensor_conf->trip_data.trigger_falling)
th_zone->therm_dev->polling_delay = IDLE_INTERVAL;
else
th_zone->therm_dev->polling_delay = 0;
@@ -413,7 +416,8 @@ static void exynos_report_trigger(void)
break;
}
 
-   if (th_zone->mode == THERMAL_DEVICE_ENABLED) {
+   if (th_zone->mode == THERMAL_DEVICE_ENABLED &&
+   !th_zone->sensor_conf->trip_data.trigger_falling) {
if (i > 0)
th_zone->therm_dev->polling_delay = ACTIVE_INTERVAL;
else
@@ -452,7 +456,8 @@ static int exynos_register_thermal(struct 
thermal_sensor_conf *sensor_conf)
 
th_zone->therm_dev = thermal_zone_device_register(sensor_conf->name,
EXYNOS_ZONE_COUNT, 0, NULL, _dev_ops, NULL, 0,
-   IDLE_INTERVAL);
+   sensor_conf->trip_data.trigger_falling ?
+   0 : IDLE_INTERVAL);
 
if (IS_ERR(th_zone->therm_dev)) {
pr_err("Failed to register thermal zone device\n");
@@ -559,8 +564,9 @@ static int exynos_tmu_initialize(struct platform_device 
*pdev)
 {
struct exynos_tmu_data *data = platform_get_drvdata(pdev);
struct exynos_tmu_platform_data *pdata = data->pdata;
-   unsigned int status, trim_info, rising_threshold;
-   int ret = 0, threshold_code;
+   unsigned int status, trim_info;
+   unsigned int rising_threshold = 0, falling_threshold = 0;
+   int ret = 0, threshold_code, i, trigger_levs = 0;
 
mutex_lock(>lock);
clk_enable(data->clk);
@@ -585,6 +591,11 @@ static int exynos_tmu_initialize(struct platform_device 
*pdev)
(data->temp_error2 != 0))
data->temp_error1 = pdata->efuse_value;
 
+   /* Count trigger levels to be enabled */
+   for (i = 0; i < MAX_THRESHOLD_LEVS; i++)
+   if (pdata->trigger_levels[i])
+   trigger_levs++;
+
if (data->soc == SOC_ARCH_EXYNOS4210) {
/* Write temperature code for threshold */
threshold_code = temp_to_code(data, pdata->threshold);
@@ -594,44 +605,38 @@ static int exynos_tmu_initialize(struct platform_device 
*pdev)
}
writeb(threshold_code,
data->base + EXYNOS4210_TMU_REG_THRESHOLD_TEMP);
-
-   writeb(pdata->trigger_levels[0],
-   data->base + EXYNOS4210_TMU_REG_TRIG_LEVEL0);
-   writeb(pdata->trigger_levels[1],
-   data->base + EXYNOS4210_TMU_REG_TRIG_LEVEL1);
-   writeb(pdata->trigger_levels[2],
-   data->base + EXYNOS4210_TMU_REG_TRIG_LEVEL2);
-   writeb(pdata->trigger_levels[3],
-   data->base + EXYNOS4210_TMU_REG_TRIG_LEVEL3);
+   for (i = 0; i < trigger_levs; i++)
+   writeb(pdata->trigger_levels[i],
+   data->base + EXYNOS4210_TMU_REG_TRIG_LEVEL0 + i * 4);
 
writel(EXYNOS4210_TMU_INTCLEAR_VAL,
data->base + EXYNOS_TMU_REG_INTCLEAR);
} else if (data->soc == SOC_ARCH_EXYNOS) {
-   /* Write temperature code for threshold */
-   threshold_code = temp_to_code(data, pdata->trigger_levels[0]);
-   if (threshold_code < 0) {
-   ret = threshold_code;
-   goto out;
-   }
-   rising_threshold = threshold_code;
- 

[PATCH 1/4] thermal: Add new thermal trend type to support quick cooling

[Amit Daniel Kachhap]

This modification adds 2 new thermal trend type THERMAL_TREND_RAISE_FULL
and THERMAL_TREND_DROP_FULL. This thermal trend can be used to quickly
jump to the upper or lower cooling level instead of incremental increase
or decrease. This is needed for temperature sensors which support rising/falling
threshold interrupts and polling can be totally avoided.

Signed-off-by: Amit Daniel Kachhap 
Signed-off-by: Amit Daniel Kachhap 
---
 drivers/thermal/step_wise.c |   19 +++
 include/linux/thermal.h |2 ++
 2 files changed, 17 insertions(+), 4 deletions(-)

diff --git a/drivers/thermal/step_wise.c b/drivers/thermal/step_wise.c
index 1242cff..0d2d8d6 100644
--- a/drivers/thermal/step_wise.c
+++ b/drivers/thermal/step_wise.c
@@ -35,6 +35,10 @@
  *   state for this trip point
  *b. if the trend is THERMAL_TREND_DROPPING, use lower cooling
  *   state for this trip point
+ *c. if the trend is THERMAL_TREND_RAISE_FULL, use highest cooling
+ *   state for this trip point
+ *d. if the trend is THERMAL_TREND_DROP_FULL, use lowest cooling
+ *   state for this trip point
  */
 static unsigned long get_target_state(struct thermal_instance *instance,
enum thermal_trend trend)
@@ -50,7 +54,10 @@ static unsigned long get_target_state(struct 
thermal_instance *instance,
} else if (trend == THERMAL_TREND_DROPPING) {
cur_state = cur_state > instance->lower ?
(cur_state - 1) : instance->lower;
-   }
+   } else if (trend == THERMAL_TREND_RAISE_FULL)
+   cur_state = instance->upper;
+   else if (trend == THERMAL_TREND_DROP_FULL)
+   cur_state = instance->lower;
 
return cur_state;
 }
@@ -87,7 +94,8 @@ static void update_instance_for_throttle(struct 
thermal_zone_device *tz,
 }
 
 static void update_instance_for_dethrottle(struct thermal_zone_device *tz,
-   int trip, enum thermal_trip_type trip_type)
+   int trip, enum thermal_trip_type trip_type,
+   enum thermal_trend trend)
 {
struct thermal_instance *instance;
struct thermal_cooling_device *cdev;
@@ -101,7 +109,10 @@ static void update_instance_for_dethrottle(struct 
thermal_zone_device *tz,
cdev = instance->cdev;
cdev->ops->get_cur_state(cdev, _state);
 
-   instance->target = cur_state > instance->lower ?
+   if (trend == THERMAL_TREND_DROP_FULL)
+   instance->target = instance->lower;
+   else
+   instance->target = cur_state > instance->lower ?
(cur_state - 1) : THERMAL_NO_TARGET;
 
/* Deactivate a passive thermal instance */
@@ -133,7 +144,7 @@ static void thermal_zone_trip_update(struct 
thermal_zone_device *tz, int trip)
if (tz->temperature >= trip_temp)
update_instance_for_throttle(tz, trip, trip_type, trend);
else
-   update_instance_for_dethrottle(tz, trip, trip_type);
+   update_instance_for_dethrottle(tz, trip, trip_type, trend);
 
mutex_unlock(>lock);
 }
diff --git a/include/linux/thermal.h b/include/linux/thermal.h
index 807f214..8bce3ec 100644
--- a/include/linux/thermal.h
+++ b/include/linux/thermal.h
@@ -68,6 +68,8 @@ enum thermal_trend {
THERMAL_TREND_STABLE, /* temperature is stable */
THERMAL_TREND_RAISING, /* temperature is raising */
THERMAL_TREND_DROPPING, /* temperature is dropping */
+   THERMAL_TREND_RAISE_FULL, /* Apply highest cooling action*/
+   THERMAL_TREND_DROP_FULL, /* Apply lowest cooling action*/
 };
 
 /* Events supported by Thermal Netlink */
-- 
1.7.1

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

[PATCH 0/4] thermal: Add support for interrupt based notification to thermal layer

[Amit Daniel Kachhap]

The patch submitted by Jonghwa Lee (https://patchwork.kernel.org/patch/1683441/)
adds support for interrupt based notification to thermal layer. This is a good
feature but the current thermal framework needs polling/regular notification for
invoking suitable cooling action. So adding 2 new thermal trend type to 
implement
this feature.

All these patches are based on thermal maintainer next tree.
git://git.kernel.org/pub/scm/linux/kernel/git/rzhang/linux.git next

Amit Daniel Kachhap (3):
  thermal: Add new thermal trend type to support quick cooling
  thermal: exynos: Miscellaneous fixes to support falling threshold
interrupt
  thermal: exynos: Use the new thermal trend type for quick cooling
action.

Jonghwa Lee (1):
  Thermal: exynos: Add support for temperature falling interrupt.

 drivers/thermal/exynos_thermal.c |  105 +++---
 drivers/thermal/step_wise.c  |   19 -
 include/linux/platform_data/exynos_thermal.h |3 +
 include/linux/thermal.h  |2 +
 4 files changed, 80 insertions(+), 49 deletions(-)

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

Re: [PATCH 5/9] cgroup_freezer: prepare freezer_change_state() for full hierarchy support

[Kamezawa Hiroyuki]

(2012/11/03 17:38), Tejun Heo wrote:

* Make freezer_change_state() take bool @freeze instead of enum
   freezer_state.

* Separate out freezer_apply_state() out of freezer_change_state().
   This makes freezer_change_state() a rather silly thin wrapper.  It
   will be filled with hierarchy handling later on.

This patch doesn't introduce any behavior change.

Signed-off-by: Tejun Heo 


Reviewed-by: KAMEZAWA Hiroyuki 


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] gpio: tegra: fix suspend/resume apis

[Laxman Dewangan]

Following are changes done to fix the suspend/resume
functionality of tegra gpio driver:
- Protect suspend/resume callbacks with CONFIG_PM_SLEEP
  because CONFIG_PM doesn't actually enable any of the PM callbacks, it
  only allows to enable CONFIG_PM_SLEEP and CONFIG_PM_RUNTIME.
  This means if CONFIG_PM is used to protect system sleep callbacks
  then it may end up unreferenced if only runtime PM is enabled.

- Fix the suspend/resume APIs declaration as per callback prototype.

Signed-off-by: Laxman Dewangan 
Acked-by: Stephen Warren 
---
Changes from V1:
- It was 2/2/ for prev patch and dropping 1/2.
- nit cleanup in change.
- Added ack from Stephen as it is acked in 2/2.

 drivers/gpio/gpio-tegra.c |   18 +-
 1 files changed, 13 insertions(+), 5 deletions(-)

diff --git a/drivers/gpio/gpio-tegra.c b/drivers/gpio/gpio-tegra.c
index c7c175a..da32754 100644
--- a/drivers/gpio/gpio-tegra.c
+++ b/drivers/gpio/gpio-tegra.c
@@ -27,6 +27,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include 
 
@@ -64,7 +65,7 @@ struct tegra_gpio_bank {
int bank;
int irq;
spinlock_t lvl_lock[4];
-#ifdef CONFIG_PM
+#ifdef CONFIG_PM_SLEEP
u32 cnf[4];
u32 out[4];
u32 oe[4];
@@ -285,8 +286,8 @@ static void tegra_gpio_irq_handler(unsigned int irq, struct 
irq_desc *desc)
 
 }
 
-#ifdef CONFIG_PM
-void tegra_gpio_resume(void)
+#ifdef CONFIG_PM_SLEEP
+static int tegra_gpio_resume(struct device *dev)
 {
unsigned long flags;
int b;
@@ -308,9 +309,10 @@ void tegra_gpio_resume(void)
}
 
local_irq_restore(flags);
+   return 0;
 }
 
-void tegra_gpio_suspend(void)
+static int tegra_gpio_suspend(struct device *dev)
 {
unsigned long flags;
int b;
@@ -330,6 +332,7 @@ void tegra_gpio_suspend(void)
}
}
local_irq_restore(flags);
+   return 0;
 }
 
 static int tegra_gpio_wake_enable(struct irq_data *d, unsigned int enable)
@@ -345,11 +348,15 @@ static struct irq_chip tegra_gpio_irq_chip = {
.irq_mask   = tegra_gpio_irq_mask,
.irq_unmask = tegra_gpio_irq_unmask,
.irq_set_type   = tegra_gpio_irq_set_type,
-#ifdef CONFIG_PM
+#ifdef CONFIG_PM_SLEEP
.irq_set_wake   = tegra_gpio_wake_enable,
 #endif
 };
 
+static const struct dev_pm_ops tegra_gpio_pm_ops = {
+   SET_SYSTEM_SLEEP_PM_OPS(tegra_gpio_suspend, tegra_gpio_resume)
+};
+
 struct tegra_gpio_soc_config {
u32 bank_stride;
u32 upper_offset;
@@ -489,6 +496,7 @@ static struct platform_driver tegra_gpio_driver = {
.driver = {
.name   = "tegra-gpio",
.owner  = THIS_MODULE,
+   .pm = _gpio_pm_ops,
.of_match_table = tegra_gpio_of_match,
},
.probe  = tegra_gpio_probe,
-- 
1.7.1.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 v7 0/3] Add modules to support realtek PCIE card reader

[Alex Dubov]

> 

> 
> Hi Alex:

Hi,

> 
> Do you have any comment on the MEMSTICK part in this v7 patchset? Can 
> you help to merge the patch to the kernel tree?


I'm afraid that presently I don't have much time to look at the memstick 
related stuff any further. Hopefully, somebody else can step in and take a look 
at your submission.

Sorry for that.

> 
> Thanks.
> Wei WANG
>

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

Re: [PATCH -v3 0/7] x86: Use BRK to pre mapping page table to make xen happy

[Yinghai Lu]

On Wed, Nov 7, 2012 at 5:40 PM, Konrad Rzeszutek Wilk
 wrote:
>
> I ran in a problem with launching an 8GB guest. When launching a 4GB it worked
> fine, but with 8GB I get:
>
> .00] init_memory_mapping: [mem 0x1f400-0x1f47f]
> [0.00]  [mem 0x1f400-0x1f47f] page 4k
> [0.00] memblock_reserve: [0x01f311c000-0x01f311d000] 
> alloc_low_pages+0x103/0x130
> [0.00] memblock_reserve: [0x01f311b000-0x01f311c000] 
> alloc_low_pages+0x103/0x130
> [0.00] memblock_reserve: [0x01f311a000-0x01f311b000] 
> alloc_low_pages+0x103/0x130
> [0.00] memblock_reserve: [0x01f3119000-0x01f311a000] 
> alloc_low_pages+0x103/0x130
> [0.00] Kernel panic - not syncing: initrd too large to handle, 
> disabling initrd (348401664 needed, 524288 available)
> [0.00]
> [0.00] Pid: 0, comm: swapper Not tainted 
> 3.7.0-rc4upstream-00042-g1b66ccf #1
> [0.00] Call Trace:
> [0.00]  [] panic+0xbf/0x1df
> [0.00]  [] setup_arch+0x728/0xb29
> [0.00]  [] ? printk+0x48/0x4a
> [0.00]  [] start_kernel+0x90/0x39e
> [0.00]  [] x86_64_start_reservations+0x131/0x136
> [0.00]  [] xen_start_kernel+0x546/0x548
>

xen memmap

[0.00] Xen: [mem 0x-0x0009] usable
[0.00] Xen: [mem 0x000a-0x000f] reserved
[0.00] Xen: [mem 0x0010-0x0001f47f] usable

there is no hole under 4G, trigger the bug about max_low_pfn_mapped updating in
add_pfn_range_mapped().

please check attached patch, that should fix the problem.

then I will fold it into corresponding commit that instroduce
add_pfn_range_mapped().

Thanks

Yinghai


fix_max_low_pfn_mapped.patch
Description: Binary data

RE: [PATCH v4] staging: ste_rmi4: Convert to Type-B support

[Alexandra Chin]

Hi Henrik.

> > Convert to MT-B because Synaptics touch devices are capable of tracking
> > identifiable fingers.
> >
> > Signed-off-by: Alexandra Chin 
> > ---
> > Changes from v4:
> > - Incorporated Henrik's review comments
> >   *split function synpatics_rmi4_touchscreen_report
> >   *split function synaptics_rmi4_i2c_query_device
> 
> Thanks for the changes. The patch looks cleaner, but also much larger,
> containing many changes irrelevant to the commit message (and to what
> has hitherto been reviewed). Please resend a minimum patch, there is
> plenty of room for additional patches after this one. :-)
> 
> Thanks,
> Henrik

Appreciate your review!
I think there is not much of change in patch v4, but git diff tool makes it 
look larger.
Since patch v4 is considered too large, let me resubmit a minimum patch,
and update changes of v4 in future patch.
Thank you for your advice.

Alexandra
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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:If you need, call me pls then we talk details.

[Shibakawa ink]

High quality color ink, good price, close to the original one. 


Duplicator ink and master, copier toner and printer cartridge, spare parts and 
used machineone package service

If you need, call me pls then we talk details.

(*^__^*).



Skype:  luckyme991
Yahoo! Messenger:  luckyme991
Tel:   0086 15989081521



*
If you hate this email, pls reject it. 
Sorry.N�Р骒r��yb�X�肚�v�^�)藓{.n�+�伐�{��赙zXФ�≤�}��财�z�:+v�����赙zZ+��+zf＂�h���~i���z��wア�?�ㄨ��&�)撷f��^j谦y�m��@A�a囤�
0鹅h���i

Re: [PATCH 4/9] cgroup_freezer: trivial cleanups

[Kamezawa Hiroyuki]

(2012/11/03 17:38), Tejun Heo wrote:

* Clean-up indentation and line-breaks.  Drop the invalid comment
   about freezer->lock.

* Make all internal functions take @freezer instead of both @cgroup
   and @freezer.

Signed-off-by: Tejun Heo 


Reviewed-by: KAMEZAWA Hiroyuki 


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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/9] cgroup: implement generic child / descendant walk macros

[Kamezawa Hiroyuki]

(2012/11/03 17:38), Tejun Heo wrote:
> Currently, cgroup doesn't provide any generic helper for walking a
> given cgroup's children or descendants.  This patch adds the following
> three macros.
> 
> * cgroup_for_each_child() - walk immediate children of a cgroup.
> 
> * cgroup_for_each_descendant_pre() - visit all descendants of a cgroup
>in pre-order tree traversal.
> 
> * cgroup_for_each_descendant_post() - visit all descendants of a
>cgroup in post-order tree traversal.
> 
> All three only require the user to hold RCU read lock during
> traversal.  Verifying that each iterated cgroup is online is the
> responsibility of the user.  When used with proper synchronization,
> cgroup_for_each_descendant_pre() can be used to propagate config
> updates to descendants in reliable way.  See comments for details.
> 
> Signed-off-by: Tejun Heo 

maybe better than using css->id in some(many) case.

Reviewed-by: KAMEZAWA Hiroyuki 



--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] MODSIGN: Only sign modules if built in-tree

[Bruno Wolff III]

On Wed, Nov 07, 2012 at 13:21:41 -0600,
  Bruno Wolff III  wrote:


I tested building dahdi-linux with kernel-3.7.0-0.rc4.git1.1.fc19 
which has this patch and the build went fine. I won't be able to test 
that the module works until tonight, but even if it ends up being 
broken the signing patch is unlikely to be the cause.


The module seems to be working correctly. So everything looks good.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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/9] cgroup: Use rculist ops for cgroup->children

[Kamezawa Hiroyuki]

(2012/11/03 17:38), Tejun Heo wrote:

Use RCU safe list operations for cgroup->children.  This will be used
to implement cgroup children / descendant walking which can be used by
controllers.

Note that cgroup_create() now puts a new cgroup at the end of the
->children list instead of head.  This isn't strictly necessary but is
done so that the iteration order is more conventional.

Signed-off-by: Tejun Heo 


Reviewed-by: KAMEZAWA Hiroyuki 


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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/9 v2] cgroup: add cgroup_subsys->post_create()

[Kamezawa Hiroyuki]

(2012/11/08 2:15), Tejun Heo wrote:

Currently, there's no way for a controller to find out whether a new
cgroup finished all ->create() allocatinos successfully and is
considered "live" by cgroup.

This becomes a problem later when we add generic descendants walking
to cgroup which can be used by controllers as controllers don't have a
synchronization point where it can synchronize against new cgroups
appearing in such walks.

This patch adds ->post_create().  It's called after all ->create()
succeeded and the cgroup is linked into the generic cgroup hierarchy.
This plays the counterpart of ->pre_destroy().

When used in combination with the to-be-added generic descendant
iterators, ->post_create() can be used to implement reliable state
inheritance.  It will be explained with the descendant iterators.

v2: Added a paragraph about its future use w/ descendant iterators per
 Michal.

Signed-off-by: Tejun Heo 
Acked-by: Michal Hocko 
Cc: Glauber Costa 



Reviewed-by: KAMEZAWA Hiroyuki 


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

Re: [PATCH v7 0/3] Add modules to support realtek PCIE card reader

[wwang]

于 2012年11月08日 03:41, Chris Ball 写道:


On Mon, Oct 29 2012, wwang wrote:

Hi Chris, Samuel and Alex:

Can you help to review this patchset, please?

I have asked Greg to remove rts_pstor from the staging tree. So this
driver have to be merged into 3.8 kernel, or else Realtek'sPCI-E card
reader can not be accessed easily.

I'm happy with the MMC portion.  I think we're mainly waiting for the
MFD patch -- Samuel, do you have any remaining review comments that need
to be fixed?

Thanks,

- Chris.


Hi Chris:

Thank you for your comment.  :-)


Hi Alex:

Do you have any comment on the MEMSTICK part in this v7 patchset? Can 
you help to merge the patch to the kernel tree?


Thanks.
Wei WANG


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

Re: [RFC v4+ hot_track 10/19] vfs: introduce hot func register framework

[Zhi Yong Wu]

On Thu, Nov 8, 2012 at 2:58 AM, Darrick J. Wong  wrote:
> On Wed, Nov 07, 2012 at 04:34:35PM +0800, Zhi Yong Wu wrote:
>> On Wed, Nov 7, 2012 at 7:30 AM, Darrick J. Wong  
>> wrote:
>> > On Mon, Oct 29, 2012 at 12:30:52PM +0800, zwu.ker...@gmail.com wrote:
>> >> From: Zhi Yong Wu 
>> >>
>> >>   Introduce one framwork to enable that specific FS
>> >> can register its own hot tracking functions.
>> >>
>> >> Signed-off-by: Zhi Yong Wu 
>> >> ---
>> >>  fs/hot_tracking.c|   78 
>> >> ++
>> >>  include/linux/hot_tracking.h |   25 +
>> >>  2 files changed, 96 insertions(+), 7 deletions(-)
>> >>
>> >> diff --git a/fs/hot_tracking.c b/fs/hot_tracking.c
>> >> index 0ef9cad..c6c6138 100644
>> >> --- a/fs/hot_tracking.c
>> >> +++ b/fs/hot_tracking.c
>> >> @@ -24,6 +24,9 @@
>> >>  #include 
>> >>  #include "hot_tracking.h"
>> >>
>> >> +static DEFINE_SPINLOCK(hot_func_list_lock);
>> >> +static LIST_HEAD(hot_func_list);
>> >> +
>> >>  /* kmem_cache pointers for slab caches */
>> >>  static struct kmem_cache *hot_inode_item_cachep __read_mostly;
>> >>  static struct kmem_cache *hot_range_item_cachep __read_mostly;
>> >> @@ -305,20 +308,23 @@ static u64 hot_average_update(struct timespec 
>> >> old_atime,
>> >>   return new_avg;
>> >>  }
>> >>
>> >> -static void hot_freq_data_update(struct hot_freq_data *freq_data, bool 
>> >> write)
>> >> +static void hot_freq_data_update(struct hot_info *root,
>> >> + struct hot_freq_data *freq_data, bool write)
>> >>  {
>> >>   struct timespec cur_time = current_kernel_time();
>> >>
>> >>   if (write) {
>> >>   freq_data->nr_writes += 1;
>> >> - freq_data->avg_delta_writes = hot_average_update(
>> >> + freq_data->avg_delta_writes =
>> >> + root->hot_func_type->ops.hot_rw_freq_calc_fn(
>> >>   freq_data->last_write_time,
>> >>   cur_time,
>> >>   freq_data->avg_delta_writes);
>> >>   freq_data->last_write_time = cur_time;
>> >>   } else {
>> >>   freq_data->nr_reads += 1;
>> >> - freq_data->avg_delta_reads = hot_average_update(
>> >> + freq_data->avg_delta_reads =
>> >> + root->hot_func_type->ops.hot_rw_freq_calc_fn(
>> >>   freq_data->last_read_time,
>> >>   cur_time,
>> >>   freq_data->avg_delta_reads);
>> >> @@ -430,7 +436,7 @@ static void hot_map_array_update(struct hot_freq_data 
>> >> *freq_data,
>> >>   struct hot_comm_item *comm_item;
>> >>   struct hot_inode_item *he;
>> >>   struct hot_range_item *hr;
>> >> - u32 temp = hot_temp_calc(freq_data);
>> >> + u32 temp = root->hot_func_type->ops.hot_temp_calc_fn(freq_data);
>> >>   u8 a_temp = temp >> (32 - HEAT_MAP_BITS);
>> >>   u8 b_temp = freq_data->last_temp >> (32 - HEAT_MAP_BITS);
>> >>
>> >> @@ -511,7 +517,7 @@ static void hot_range_update(struct hot_inode_item 
>> >> *he,
>> >>   _nodes[i]->hot_range.hot_freq_data, 
>> >> root);
>> >>
>> >>   spin_lock(_nodes[i]->hot_range.lock);
>> >> - obsolete = hot_is_obsolete(
>> >> + obsolete = 
>> >> root->hot_func_type->ops.hot_is_obsolete_fn(
>> >>   
>> >> _nodes[i]->hot_range.hot_freq_data);
>> >>   spin_unlock(_nodes[i]->hot_range.lock);
>> >>
>> >> @@ -668,7 +674,7 @@ void hot_update_freqs(struct inode *inode, u64 start,
>> >>   }
>> >>
>> >>   spin_lock(>hot_inode.lock);
>> >> - hot_freq_data_update(>hot_inode.hot_freq_data, rw);
>> >> + hot_freq_data_update(root, >hot_inode.hot_freq_data, rw);
>> >>   spin_unlock(>hot_inode.lock);
>> >>
>> >>   /*
>> >> @@ -685,7 +691,7 @@ void hot_update_freqs(struct inode *inode, u64 start,
>> >>   }
>> >>
>> >>   spin_lock(>hot_range.lock);
>> >> - hot_freq_data_update(>hot_range.hot_freq_data, rw);
>> >> + hot_freq_data_update(root, >hot_range.hot_freq_data, 
>> >> rw);
>> >>   spin_unlock(>hot_range.lock);
>> >>
>> >>   hot_range_item_put(hr);
>> >> @@ -695,6 +701,61 @@ void hot_update_freqs(struct inode *inode, u64 start,
>> >>  }
>> >>  EXPORT_SYMBOL_GPL(hot_update_freqs);
>> >>
>> >> +static struct hot_func_type hot_func_def = {
>> >> + .hot_func_name = "hot_type_def",
>> >> + .ops = {
>> >> + .hot_rw_freq_calc_fn = hot_average_update,
>> >> + .hot_temp_calc_fn= hot_temp_calc,
>> >> + .hot_is_obsolete_fn  = hot_is_obsolete,
>> >> + },
>> >> +};
>> >
>> > If these hot_ops are per-filesystem, why not just embed a struct 
>> > hot_func_ops
>> > inside of struct file_system_type?  That eliminates this _get function,
>> this _get function is very 

[PATCH 5/5] drivers: mfd: Fix resource request for [mem 0x00000000]

[Peter Hurley]

The older southbridges supported by the lpc_ich driver do not
provide memory-mapped space of the root complex. The driver
correctly avoids computing the iomem address in this case, yet
submits a zeroed resource request anyway (via mfd_add_devices()).

Remove the iomem resource from the resource array submitted to the
mfd core for the older southbridges.

Cc: Aaron Sierra 
Cc: Peter Tyser 
Cc: Samuel Ortiz 
Signed-off-by: Peter Hurley 
---
 drivers/mfd/lpc_ich.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/drivers/mfd/lpc_ich.c b/drivers/mfd/lpc_ich.c
index a22544f..a46095b 100644
--- a/drivers/mfd/lpc_ich.c
+++ b/drivers/mfd/lpc_ich.c
@@ -842,6 +842,9 @@ static int __devinit lpc_ich_init_wdt(struct pci_dev *dev,
res = wdt_mem_res(ICH_RES_MEM_GCS);
res->start = base_addr + ACPIBASE_GCS_OFF;
res->end = base_addr + ACPIBASE_GCS_END;
+   } else {
+   /* So don't register iomem for TCO ver 1 */
+   --lpc_ich_cells[LPC_WDT].num_resources;
}
 
lpc_ich_finalize_cell(_ich_cells[LPC_WDT], id);
-- 
1.7.12.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 4/5] x86: acpi: Print warning for malformed host bridge resources

[Peter Hurley]

An incorrectly specified host bridge window may prevent
other devices from claiming assigned resources. For example,
this flawed _CRS resource descriptor from a Dell T5400:
 DWordMemory (ResourceProducer, PosDecode, MinFixed, MaxFixed, 
NonCacheable, ReadWrite,
 0x, // Granularity
 0xF000, // Range Minimum
 0xFE00, // Range Maximum
 0x, // Translation Offset
 0x0E00, // Length
 ,, , AddressRangeMemory, TypeStatic)
prevents the adjacent device from claiming [mem 0xfe000-0xfe01]

Sanity check that the resource at least conforms to a valid
PCI BAR; if not, emit a diagnostic warning.

Cc: Bjorn Helgaas 
Cc: Thomas Gleixner 
Cc: Ingo Molnar 
Cc: H. Peter Anvin 
Cc: x...@kernel.org
Signed-off-by: Peter Hurley 
---
 arch/x86/pci/acpi.c | 4 
 1 file changed, 4 insertions(+)

diff --git a/arch/x86/pci/acpi.c b/arch/x86/pci/acpi.c
index 192397c..3468d16 100644
--- a/arch/x86/pci/acpi.c
+++ b/arch/x86/pci/acpi.c
@@ -298,6 +298,10 @@ setup_resource(struct acpi_resource *acpi_res, void *data)
"host bridge window [%#llx-%#llx] "
"([%#llx-%#llx] ignored, not CPU addressable)\n", 
start, orig_end, end + 1, orig_end);
+   } else if (flags & IORESOURCE_MEM && (start & 0x0f || ~end & 0x0f)) {
+   dev_warn(>bridge->dev,
+"invalid host bridge window [%#llx-%#llx]\n",
+start, end);
}
 
res = >res[info->res_num];
-- 
1.7.12.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 3/5] resources: Print warning when inserting resource [mem 0x00000000]

[Peter Hurley]

Inserting iomem resource [0x0-0x0] is most likely a bug; at least
print a warning message. Eg.,
  resource: inserting NULL resource iTCO_wdt [mem 0x]

Cc: Bjorn Helgaas 
Signed-off-by: Peter Hurley 
---
 kernel/resource.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/kernel/resource.c b/kernel/resource.c
index 268b5fa..ab758bb 100644
--- a/kernel/resource.c
+++ b/kernel/resource.c
@@ -589,6 +589,9 @@ static struct resource * __insert_resource(struct resource 
*parent, struct resou
 {
struct resource *first, *next;
 
+   if (new->flags & IORESOURCE_MEM && !new->start && !new->end)
+   pr_warn("inserting NULL resource %s %pR", new->name, new);
+
for (;; parent = first) {
first = __request_resource(parent, new);
if (!first)
-- 
1.7.12.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 2/5] resources: Print resource conflicts for failed requests

[Peter Hurley]

When resource requests fail, the conflicting resource is not
always apparent. Emit diagnostic print when resource conflicts prevent
resource requests. For example,
  kernel: resource: Requested i5k_amb [mem 0xfe00-0xfe01 flags 
0x8000] conflicts with PCI Bus :00 [mem 0xf000-0xfe00 flags 
0x200]

Cc: Bjorn Helgaas 
Signed-off-by: Peter Hurley 
---
 kernel/resource.c | 4 
 1 file changed, 4 insertions(+)

diff --git a/kernel/resource.c b/kernel/resource.c
index 461c2e0..268b5fa 100644
--- a/kernel/resource.c
+++ b/kernel/resource.c
@@ -924,6 +924,10 @@ struct resource * __request_region(struct resource *parent,
write_lock(_lock);
continue;
}
+
+   pr_debug("Requested %s %pr conflicts with %s %pr\n",
+res->name, res, conflict->name, conflict);
+
/* Uhhuh, that didn't work out.. */
kfree(res);
res = NULL;
-- 
1.7.12.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 1/5] resources: Print resource ranges when expanding overlaps

[Peter Hurley]

Resource names can be too generic to distinguish which resources
overlap; eg.,
  kernel: Expanded resource reserved due to conflict with PCI Bus :00
  kernel: Expanded resource reserved due to conflict with PCI Bus :00

Rather, print decoded resource info as well; eg.,
  kernel: resource: Expanding reserved [mem 0xcfe5ec00-0xcfff]; overlaps 
PCI Bus :00 [mem 0xcff0-0xdfff]
  kernel: resource: Expanding reserved [mem 0xfe00-0xfeff]; overlaps 
PCI Bus :00 [mem 0xf000-0xfe00]

Cc: Bjorn Helgaas 
Signed-off-by: Peter Hurley 
---
 kernel/resource.c | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/kernel/resource.c b/kernel/resource.c
index 73f35d4..461c2e0 100644
--- a/kernel/resource.c
+++ b/kernel/resource.c
@@ -696,12 +696,13 @@ void insert_resource_expand_to_fit(struct resource *root, 
struct resource *new)
break;
 
/* Ok, expand resource to cover the conflict, then try again .. 
*/
+   pr_warn("Expanding %s %pR; overlaps %s %pR\n",
+   new->name, new, conflict->name, conflict);
+
if (conflict->start < new->start)
new->start = conflict->start;
if (conflict->end > new->end)
new->end = conflict->end;
-
-   printk("Expanded resource %s due to conflict with %s\n", 
new->name, conflict->name);
}
write_unlock(_lock);
 }
-- 
1.7.12.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 0/5] Add diagnostics for iomem resources

[Peter Hurley]

The first 3 patches add diagnostics to iomem resource management.
The x86 patch adds a diagnostic for bogus ACPI resource definitions.
Lastly, the issue addressed by the mfd driver patch emerged while
testing the other patches in this series.

Peter Hurley (5):
  kernel: Print resource ranges when expanding overlaps
  kernel: Print resource conflicts for failed requests
  kernel: Print warning when inserting resource [mem 0x]
  x86: acpi: Print warning for malformed host bridge resources
  drivers: mfd: Fix resource request for [mem 0x]

 arch/x86/pci/acpi.c   |  4 
 drivers/mfd/lpc_ich.c |  3 +++
 kernel/resource.c | 12 ++--
 3 files changed, 17 insertions(+), 2 deletions(-)

-- 
1.7.12.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: [RFC v4+ hot_track 03/19] vfs: add I/O frequency update function

[Zhi Yong Wu]

On Thu, Nov 8, 2012 at 2:49 AM, Darrick J. Wong  wrote:
> On Wed, Nov 07, 2012 at 04:27:05PM +0800, Zhi Yong Wu wrote:
>> On Wed, Nov 7, 2012 at 6:45 AM, Darrick J. Wong  
>> wrote:
>> > On Mon, Oct 29, 2012 at 12:30:45PM +0800, zwu.ker...@gmail.com wrote:
>> >> From: Zhi Yong Wu 
>> >>
>> >>   Add some util helpers to update access frequencies
>> >> for one file or its range.
>> >>
>> >> Signed-off-by: Zhi Yong Wu 
>> >> ---
>> >>  fs/hot_tracking.c|  179 
>> >> ++
>> >>  fs/hot_tracking.h|7 ++
>> >>  include/linux/hot_tracking.h |2 +
>> >>  3 files changed, 188 insertions(+), 0 deletions(-)
>> >>
>> >> diff --git a/fs/hot_tracking.c b/fs/hot_tracking.c
>> >> index 68591f0..0a7d9a3 100644
>> >> --- a/fs/hot_tracking.c
>> >> +++ b/fs/hot_tracking.c
>> >> @@ -172,6 +172,137 @@ static void hot_inode_tree_exit(struct hot_info 
>> >> *root)
>> >>   }
>> >>  }
>> >>
>> >> +struct hot_inode_item
>> >> +*hot_inode_item_find(struct hot_info *root, u64 ino)
>> >> +{
>> >> + struct hot_inode_item *he;
>> >> + int ret;
>> >> +
>> >> +again:
>> >> + spin_lock(>lock);
>> >> + he = radix_tree_lookup(>hot_inode_tree, ino);
>> >> + if (he) {
>> >> + kref_get(>hot_inode.refs);
>> >> + spin_unlock(>lock);
>> >> + return he;
>> >> + }
>> >> + spin_unlock(>lock);
>> >> +
>> >> + he = kmem_cache_zalloc(hot_inode_item_cachep,
>> >> + GFP_KERNEL | GFP_NOFS);
>> >> + if (!he)
>> >> + return ERR_PTR(-ENOMEM);
>> >> +
>> >> + hot_inode_item_init(he, ino, >hot_inode_tree);
>> >> +
>> >> + ret = radix_tree_preload(GFP_NOFS & ~__GFP_HIGHMEM);
>> >> + if (ret) {
>> >> + kmem_cache_free(hot_inode_item_cachep, he);
>> >> + return ERR_PTR(ret);
>> >> + }
>> >> +
>> >> + spin_lock(>lock);
>> >> + ret = radix_tree_insert(>hot_inode_tree, ino, he);
>> >> + if (ret == -EEXIST) {
>> >> + kmem_cache_free(hot_inode_item_cachep, he);
>> >> + spin_unlock(>lock);
>> >> + radix_tree_preload_end();
>> >> + goto again;
>> >> + }
>> >> + spin_unlock(>lock);
>> >> + radix_tree_preload_end();
>> >> +
>> >> + kref_get(>hot_inode.refs);
>> >> + return he;
>> >> +}
>> >> +EXPORT_SYMBOL_GPL(hot_inode_item_find);
>> >> +
>> >> +static struct hot_range_item
>> >> +*hot_range_item_find(struct hot_inode_item *he,
>> >> + u32 start)
>> >> +{
>> >> + struct hot_range_item *hr;
>> >> + int ret;
>> >> +
>> >> +again:
>> >> + spin_lock(>lock);
>> >> + hr = radix_tree_lookup(>hot_range_tree, start);
>> >> + if (hr) {
>> >> + kref_get(>hot_range.refs);
>> >> + spin_unlock(>lock);
>> >> + return hr;
>> >> + }
>> >> + spin_unlock(>lock);
>> >> +
>> >> + hr = kmem_cache_zalloc(hot_range_item_cachep,
>> >> + GFP_KERNEL | GFP_NOFS);
>> >> + if (!hr)
>> >> + return ERR_PTR(-ENOMEM);
>> >> +
>> >> + hot_range_item_init(hr, start, he);
>> >> +
>> >> + ret = radix_tree_preload(GFP_NOFS & ~__GFP_HIGHMEM);
>> >> + if (ret) {
>> >> + kmem_cache_free(hot_range_item_cachep, hr);
>> >> + return ERR_PTR(ret);
>> >> + }
>> >> +
>> >> + spin_lock(>lock);
>> >> + ret = radix_tree_insert(>hot_range_tree, start, hr);
>> >> + if (ret == -EEXIST) {
>> >> + kmem_cache_free(hot_range_item_cachep, hr);
>> >> + spin_unlock(>lock);
>> >> + radix_tree_preload_end();
>> >> + goto again;
>> >> + }
>> >> + spin_unlock(>lock);
>> >> + radix_tree_preload_end();
>> >> +
>> >> + kref_get(>hot_range.refs);
>> >> + return hr;
>> >> +}
>> >> +
>> >> +/*
>> >> + * This function does the actual work of updating
>> >> + * the frequency numbers, whatever they turn out to be.
>> >> + */
>> >> +static u64 hot_average_update(struct timespec old_atime,
>> >> + struct timespec cur_time, u64 old_avg)
>> >> +{
>> >> + struct timespec delta_ts;
>> >> + u64 new_avg;
>> >> + u64 new_delta;
>> >> +
>> >> + delta_ts = timespec_sub(cur_time, old_atime);
>> >> + new_delta = timespec_to_ns(_ts) >> FREQ_POWER;
>> >> +
>> >> + new_avg = (old_avg << FREQ_POWER) - old_avg + new_delta;
>> >> + new_avg = new_avg >> FREQ_POWER;
>> >> +
>> >> + return new_avg;
>> >> +}
>> >> +
>> >> +static void hot_freq_data_update(struct hot_freq_data *freq_data, bool 
>> >> write)
>> >> +{
>> >> + struct timespec cur_time = current_kernel_time();
>> >> +
>> >> + if (write) {
>> >> + freq_data->nr_writes += 1;
>> >> + freq_data->avg_delta_writes = hot_average_update(
>> >> + freq_data->last_write_time,
>> >> + cur_time,
>> >> + 

[PATCH 2/2] gpio: tegra: Drop exporting static functions

[Axel Lin]

Both tegra_gpio_enable() and tegra_gpio_disable() are static functions, it does
not make sense to export them.

Signed-off-by: Axel Lin 
---
 drivers/gpio/gpio-tegra.c |2 --
 1 file changed, 2 deletions(-)

diff --git a/drivers/gpio/gpio-tegra.c b/drivers/gpio/gpio-tegra.c
index d5c01f0..f6cf98f 100644
--- a/drivers/gpio/gpio-tegra.c
+++ b/drivers/gpio/gpio-tegra.c
@@ -109,13 +109,11 @@ static void tegra_gpio_enable(int gpio)
 {
tegra_gpio_mask_write(GPIO_MSK_CNF(gpio), gpio, 1);
 }
-EXPORT_SYMBOL_GPL(tegra_gpio_enable);
 
 static void tegra_gpio_disable(int gpio)
 {
tegra_gpio_mask_write(GPIO_MSK_CNF(gpio), gpio, 0);
 }
-EXPORT_SYMBOL_GPL(tegra_gpio_disable);
 
 static int tegra_gpio_request(struct gpio_chip *chip, unsigned offset)
 {
-- 
1.7.9.5



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

Re: [PATCH V2 1/3] mmc: esdhc: enable polling to detect card by itself

[yongd]

On 2012年11月06日 20:52, Shawn Guo wrote:

On Tue, Nov 06, 2012 at 04:49:42PM +0800, yongd wrote:

 From your info, we can see that on your platform, those pins (including
power, clk, DATA) necessary for MMC_SEND_STATUS transaction still keep
connected for some time just after the GPIO's level changes due to card
removable. And if we remove the card very slowly, such time duration can be
such long that the MMC_SEND_STATUS query can still succeed.


I was not removing the card as slowly as you think. It's actually
a normal speed.  That's why I thought your patch breaks the
card-detection functionality before I found the cause.


So I think we can add a proper delay(maybe 100ms) before the gpio interrupt
triggers the MMC_SEND_STATUS query, and maybe this can probably fix this 
issue:-)


I do not think it's a proper fixing.

Anyway, u can try such delay like msleep(100) in cd_irq() before calling
tasklet_schedule(>card_tasklet). Yes, this is not a proper fix even
it works:-)





Anyway, I 100% agree with you that for a ESDHC_CD_GPIO card, we shall query gpio
state to know such card's presence rather than sending MMC_SEND_STATUS rudely.

But just as I mentioned before, I don't think using 
SDHCI_QUIRK_BROKEN_CARD_DETECTION
as the flag to determine whether and how we can know card's presence before 
sending
command is a proper way.

I haven't gotten any good idea. Do u have any idea on this?


I guess what we need is to call mmc_gpio_get_cd() trying to know card's
presence before sending MMC_SEND_STATUS command.  sdhci-esdhc-imx
driver will surely need some changes to cope with that.

Shawn

Yes, gpio card detection should better use the existing framework 
offered by slot-gpio.
Then the fake-card-present will be unnecessary. BTW, sdhci-s3c.c also 
dose not use slot-gpio,
and then it also adds some tricky logic for gpio detection. U can check 
sdhci_s3c_notify_change(),
which dynamically set/clear SDHCI_QUIRK_BROKEN_CARD_DETECTION. This 
patch adding
mmc_gpio_get_cd(), bec9d4e5939987053169a9bb48fc58b6a2d3e237, mentioned 
this 1stly.


But using SDHCI_QUIRK_BROKEN_CARD_DETECTION to do such judging in 
sdhci_request()
is still not proper. I think this is the root causing such above 
workarounds.


So I am thinking of adding a new operation like get_card_presence into 
sdhci_ops,
and then different host drivers can implement differently by themselves, 
eg, for

sdhci-esdhc-imx.c,

static bool esdhc_get_card_presence(struct sdhci_host *host)
{
bool present = true;

if (detection_type == ESDHC_CD_CONTROLLER)
present = sdhci_readl(host, SDHCI_PRESENT_STATE) & SDHCI_CARD_PRESENT;
else if (detection_type == ESDHC_CD_GPIO) {
if (gpio_get_value(boarddata->cd_gpio))
/* no card, if a valid gpio says so... */
present = false;
}

return present;
}


But this will also cause lots of host drivers corresponding changes. Oh, 
still inconvenient:-(

Any better ideas?

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] gpio: tegra: Staticize non-exported symbols

[Axel Lin]

Both tegra_gpio_request() and tegra_gpio_free() are not referenced outside of
this file, make them static.

Signed-off-by: Axel Lin 
---
 drivers/gpio/gpio-tegra.c |4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/gpio/gpio-tegra.c b/drivers/gpio/gpio-tegra.c
index c7c175a..d5c01f0 100644
--- a/drivers/gpio/gpio-tegra.c
+++ b/drivers/gpio/gpio-tegra.c
@@ -117,12 +117,12 @@ static void tegra_gpio_disable(int gpio)
 }
 EXPORT_SYMBOL_GPL(tegra_gpio_disable);
 
-int tegra_gpio_request(struct gpio_chip *chip, unsigned offset)
+static int tegra_gpio_request(struct gpio_chip *chip, unsigned offset)
 {
return pinctrl_request_gpio(offset);
 }
 
-void tegra_gpio_free(struct gpio_chip *chip, unsigned offset)
+static void tegra_gpio_free(struct gpio_chip *chip, unsigned offset)
 {
pinctrl_free_gpio(offset);
tegra_gpio_disable(offset);
-- 
1.7.9.5



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

Re: [PATCH v4 5/7] mfd: max8925: support dt for regulator

[Qing Xu]

On 11/07/2012 10:20 PM, Mark Brown wrote:

On Wed, Nov 07, 2012 at 06:09:53PM +0800, Qing Xu wrote:

From: Qing Xu 

Signed-off-by: Qing Xu 

Applied, thanks.


+max8925 regulator device register is still handled by mfd_add_devices, not by
+of_xxx, so, it is not necessary to add compatible name. Also, those reg
+offset and id info is stored in mfd_cell(see max8925-core.c), as a result
+there is not private properties in dts.
+node's name should match with the definition in max8925_regulator_matches
+(see max8925-regulator.c)

Please submit a followup which removes all the Linux-specific references
and just enumerates the supported regulators.  Please do also use a
subject line appropriate for the subsystem - this is for the regulator
driver so it should be regulator:

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

[PATCH] mfd: max8925: update dt regulator binding doc

[Qing Xu]

From: Qing Xu 

remove linux specific references, enumerates all supported
regulators

Signed-off-by: Qing Xu 
---
 .../bindings/regulator/max8925-regulator.txt   |   51 
 1 files changed, 31 insertions(+), 20 deletions(-)

diff --git a/Documentation/devicetree/bindings/regulator/max8925-regulator.txt 
b/Documentation/devicetree/bindings/regulator/max8925-regulator.txt
index 073b41d..0057695 100644
--- a/Documentation/devicetree/bindings/regulator/max8925-regulator.txt
+++ b/Documentation/devicetree/bindings/regulator/max8925-regulator.txt
@@ -1,29 +1,40 @@
 Max8925 Voltage regulators
 
-max8925 regulator device register is still handled by mfd_add_devices, not by
-of_xxx, so, it is not necessary to add compatible name. Also, those reg
-offset and id info is stored in mfd_cell(see max8925-core.c), as a result
-there is not private properties in dts.
-
-node's name should match with the definition in max8925_regulator_matches
-(see max8925-regulator.c)
-
+Required nodes:
+-nodes:
+  - SDV1 for SDV SDV1
+  - SDV2 for SDV SDV2
+  - SDV3 for SDV SDV3
+  - LDO1 for LDO LDO1
+  - LDO2 for LDO LDO2
+  - LDO3 for LDO LDO3
+  - LDO4 for LDO LDO4
+  - LDO5 for LDO LDO5
+  - LDO6 for LDO LDO6
+  - LDO7 for LDO LDO7
+  - LDO8 for LDO LDO8
+  - LDO9 for LDO LDO9
+  - LDO10 for LDO LDO10
+  - LDO11 for LDO LDO11
+  - LDO12 for LDO LDO12
+  - LDO13 for LDO LDO13
+  - LDO14 for LDO LDO14
+  - LDO15 for LDO LDO15
+  - LDO16 for LDO LDO16
+  - LDO17 for LDO LDO17
+  - LDO18 for LDO LDO18
+  - LDO19 for LDO LDO19
+  - LDO20 for LDO LDO20
 
 Optional properties:
 - Any optional property defined in bindings/regulator/regulator.txt
 
-
 Example:
 
+   SDV1 {
+   regulator-min-microvolt = <637500>;
+   regulator-max-microvolt = <1425000>;
+   regulator-boot-on;
+   regulator-always-on;
+   };
 
-   regulators {
-   SDV1 {
-   regulator-min-microvolt = <637500>;
-   regulator-max-microvolt = <1425000>;
-   regulator-boot-on;
-   regulator-always-on;
-   };
-
-   ...
-   ...
-   }
-- 
1.7.0.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] gpio: mvebu: Set free callback for gpio_chip

[Axel Lin]

We call pinctrl_request_gpio() in request callback, thus we need to call
pinctrl_free_gpio() in free callback.

Both mvebu_gpio_request() and mvebu_gpio_free() are not referenced outside of
this file, make them static.

Signed-off-by: Axel Lin 
---
 drivers/gpio/gpio-mvebu.c |5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/drivers/gpio/gpio-mvebu.c b/drivers/gpio/gpio-mvebu.c
index 325c3de..a515b92 100644
--- a/drivers/gpio/gpio-mvebu.c
+++ b/drivers/gpio/gpio-mvebu.c
@@ -168,12 +168,12 @@ static void __iomem *mvebu_gpioreg_level_mask(struct 
mvebu_gpio_chip *mvchip)
  * Functions implementing the gpio_chip methods
  */
 
-int mvebu_gpio_request(struct gpio_chip *chip, unsigned pin)
+static int mvebu_gpio_request(struct gpio_chip *chip, unsigned pin)
 {
return pinctrl_request_gpio(chip->base + pin);
 }
 
-void mvebu_gpio_free(struct gpio_chip *chip, unsigned pin)
+static void mvebu_gpio_free(struct gpio_chip *chip, unsigned pin)
 {
pinctrl_free_gpio(chip->base + pin);
 }
@@ -546,6 +546,7 @@ static int __devinit mvebu_gpio_probe(struct 
platform_device *pdev)
mvchip->chip.label = dev_name(>dev);
mvchip->chip.dev = >dev;
mvchip->chip.request = mvebu_gpio_request;
+   mvchip->chip.free = mvebu_gpio_free;
mvchip->chip.direction_input = mvebu_gpio_direction_input;
mvchip->chip.get = mvebu_gpio_get;
mvchip->chip.direction_output = mvebu_gpio_direction_output;
-- 
1.7.9.5



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

Re: [PATCH] tcp: Avoid infinite loop on recvmsg bug

[Julius Werner]

> So you probably are fighting a bug we already fixed in upstream kernel.
>
> (commit c8628155ece363 "tcp: reduce out_of_order memory use" did not
> played well with cloned skbs.)
>
> This issue was already discussed on netdev in the past.

Thanks for the hint. Unfortunately, we have not pulled c8628 into our
tree yet, so that's not it. Is there another point where the cloned
skb or the faked truesize might make it break? We have been running
this test with that hardware some 30 times in the last months and only
seen it once, so it cannot be that common.

I have noticed that you have already proposed a patch to repair
smsc95xx (replacing the clone with a copy) on this list a few times...
what's the status on that? Will it be committed eventually or did you
abandon that approach?

Regardless of that, I still think that the bug handling in tcp_recvmsg
should be updated in one way or the other.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] Revert "Staging: Android alarm: IOCTL command encoding fix"

[Colin Cross]

Commit 6bd4a5d96c08dc2380f8053b1bd4f879f55cd3c9 changed the
ANDROID_ALARM_GET_TIME ioctls from IOW to IOR.  While technically
correct, the _IOC_DIR bits are ignored by alarm_ioctl, so the
commit breaks a userspace ABI used by all existing Android devices
for a purely cosmetic reason.  Revert it.

Cc: stable 
Cc: Dae S. Kim 
Signed-off-by: Colin Cross 
---
 drivers/staging/android/android_alarm.h |4 +---
 1 files changed, 1 insertions(+), 3 deletions(-)

diff --git a/drivers/staging/android/android_alarm.h 
b/drivers/staging/android/android_alarm.h
index f2ffd96..d0cafd6 100644
--- a/drivers/staging/android/android_alarm.h
+++ b/drivers/staging/android/android_alarm.h
@@ -51,12 +51,10 @@ enum android_alarm_return_flags {
 #define ANDROID_ALARM_WAIT  _IO('a', 1)
 
 #define ALARM_IOW(c, type, size)_IOW('a', (c) | ((type) << 4), 
size)
-#define ALARM_IOR(c, type, size)_IOR('a', (c) | ((type) << 4), 
size)
-
 /* Set alarm */
 #define ANDROID_ALARM_SET(type) ALARM_IOW(2, type, struct timespec)
 #define ANDROID_ALARM_SET_AND_WAIT(type)ALARM_IOW(3, type, struct timespec)
-#define ANDROID_ALARM_GET_TIME(type)ALARM_IOR(4, type, struct timespec)
+#define ANDROID_ALARM_GET_TIME(type)ALARM_IOW(4, type, struct timespec)
 #define ANDROID_ALARM_SET_RTC   _IOW('a', 5, struct timespec)
 #define ANDROID_ALARM_BASE_CMD(cmd) (cmd & ~(_IOC(0, 0, 0xf0, 0)))
 #define ANDROID_ALARM_IOCTL_TO_TYPE(cmd)(_IOC_NR(cmd) >> 4)
-- 
1.7.7.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 V3] firmware loader: Fix the race FW_STATUS_DONE is followed by class_timeout

[Chuansheng Liu]

There is a race as below when calling request_firmware():
CPU1   CPU2
write 0 > loading
mutex_lock(_lock)
...
set_bit FW_STATUS_DONE class_timeout is coming
   set_bit FW_STATUS_ABORT
complete_all 
...
mutex_unlock(_lock)

In this time, the bit FW_STATUS_DONE and FW_STATUS_ABORT are set,
and request_firmware() will return failure due to condition in
_request_firmware_load():
if (!buf->size || test_bit(FW_STATUS_ABORT, >status))
retval = -ENOENT;

But from the above scenerio, it should be a successful requesting.
So we need judge if the bit FW_STATUS_DONE is already set before
calling fw_load_abort() in timeout function.

As Ming's proposal, we need change the timer into sched_work to
benefit from using _lock mutex also.

Signed-off-by: liu chuansheng 
---
 drivers/base/firmware_class.c |   24 
 1 files changed, 16 insertions(+), 8 deletions(-)

diff --git a/drivers/base/firmware_class.c b/drivers/base/firmware_class.c
index 8945f4e..b44ed35 100644
--- a/drivers/base/firmware_class.c
+++ b/drivers/base/firmware_class.c
@@ -143,7 +143,7 @@ struct fw_cache_entry {
 };
 
 struct firmware_priv {
-   struct timer_list timeout;
+   struct delayed_work timeout_work;
bool nowait;
struct device dev;
struct firmware_buf *buf;
@@ -667,11 +667,18 @@ static struct bin_attribute firmware_attr_data = {
.write = firmware_data_write,
 };
 
-static void firmware_class_timeout(u_long data)
+static void firmware_class_timeout_work(struct work_struct *work)
 {
-   struct firmware_priv *fw_priv = (struct firmware_priv *) data;
+   struct firmware_priv *fw_priv = container_of(work,
+   struct firmware_priv, timeout_work.work);
 
+   mutex_lock(_lock);
+   if (test_bit(FW_STATUS_DONE, &(fw_priv->buf->status))) {
+   mutex_unlock(_lock);
+   return;
+   }
fw_load_abort(fw_priv);
+   mutex_unlock(_lock);
 }
 
 static struct firmware_priv *
@@ -690,8 +697,8 @@ fw_create_instance(struct firmware *firmware, const char 
*fw_name,
 
fw_priv->nowait = nowait;
fw_priv->fw = firmware;
-   setup_timer(_priv->timeout,
-   firmware_class_timeout, (u_long) fw_priv);
+   INIT_DELAYED_WORK(_priv->timeout_work,
+   firmware_class_timeout_work);
 
f_dev = _priv->dev;
 
@@ -858,7 +865,9 @@ static int _request_firmware_load(struct firmware_priv 
*fw_priv, bool uevent,
dev_dbg(f_dev->parent, "firmware: direct-loading"
" firmware %s\n", buf->fw_id);
 
+   mutex_lock(_lock);
set_bit(FW_STATUS_DONE, >status);
+   mutex_unlock(_lock);
complete_all(>completion);
direct_load = 1;
goto handle_fw;
@@ -894,15 +903,14 @@ static int _request_firmware_load(struct firmware_priv 
*fw_priv, bool uevent,
dev_set_uevent_suppress(f_dev, false);
dev_dbg(f_dev, "firmware: requesting %s\n", buf->fw_id);
if (timeout != MAX_SCHEDULE_TIMEOUT)
-   mod_timer(_priv->timeout,
- round_jiffies_up(jiffies + timeout));
+   schedule_delayed_work(_priv->timeout_work, timeout);
 
kobject_uevent(_priv->dev.kobj, KOBJ_ADD);
}
 
wait_for_completion(>completion);
 
-   del_timer_sync(_priv->timeout);
+   cancel_delayed_work_sync(_priv->timeout_work);
 
 handle_fw:
mutex_lock(_lock);
-- 
1.7.0.4



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

RE: [PATCH V2] firmware loader: Fix the race FW_STATUS_DONE is followed by class_timeout

[Liu, Chuansheng]

> -Original Message-
> From: Ming Lei [mailto:ming@canonical.com]
> Sent: Thursday, November 08, 2012 10:02 AM
> To: Liu, Chuansheng
> Cc: gre...@linuxfoundation.org; linux-kernel@vger.kernel.org
> Subject: Re: [PATCH V2] firmware loader: Fix the race FW_STATUS_DONE is
> followed by class_timeout
> 
> On Thu, Nov 8, 2012 at 6:29 PM, Chuansheng Liu 
> wrote:
> >
> > There is a race as below when calling request_firmware():
> > CPU1   CPU2
> > write 0 > loading
> > mutex_lock(_lock)
> > ...
> > set_bit FW_STATUS_DONE class_timeout is coming
> >set_bit FW_STATUS_ABORT
> > complete_all 
> > ...
> > mutex_unlock(_lock)
> >
> > In this time, the bit FW_STATUS_DONE and FW_STATUS_ABORT are set,
> > and request_firmware() will return failure due to condition in
> > _request_firmware_load():
> > if (!buf->size || test_bit(FW_STATUS_ABORT, >status))
> > retval = -ENOENT;
> >
> > But from the above scenerio, it should be a successful requesting.
> > So we need judge if the bit FW_STATUS_DONE is already set before
> > calling fw_load_abort() in timeout function.
> >
> > As Ming's proposal, we need change the timer into sched_work to
> > benefit from using _lock mutex also.
> >
> > Signed-off-by: liu chuansheng 
> > ---
> >  drivers/base/firmware_class.c |   25 +
> >  1 files changed, 17 insertions(+), 8 deletions(-)
> >
> > diff --git a/drivers/base/firmware_class.c b/drivers/base/firmware_class.c
> > index 8945f4e..f2caa0a 100644
> > --- a/drivers/base/firmware_class.c
> > +++ b/drivers/base/firmware_class.c
> > @@ -143,7 +143,7 @@ struct fw_cache_entry {
> >  };
> >
> >  struct firmware_priv {
> > -   struct timer_list timeout;
> > +   struct delayed_work timeout_work;
> > bool nowait;
> > struct device dev;
> > struct firmware_buf *buf;
> > @@ -667,10 +667,17 @@ static struct bin_attribute firmware_attr_data = {
> > .write = firmware_data_write,
> >  };
> >
> > -static void firmware_class_timeout(u_long data)
> > +static void firmware_class_timeout_work(struct work_struct *work)
> >  {
> > -   struct firmware_priv *fw_priv = (struct firmware_priv *) data;
> > +   struct firmware_priv *fw_priv = container_of(work,
> > +   struct firmware_priv, timeout_work.work);
> >
> > +   mutex_lock(_lock);
> > +   if (test_bit(FW_STATUS_DONE, &(fw_priv->buf->status))) {
> > +   mutex_unlock(_lock);
> > +   return;
> > +   }
> > +   mutex_unlock(_lock);
> > fw_load_abort(fw_priv);
> 
> fw_lock should be held when fw_load_abort(fw_priv) is running.
OK.

> 
> >  }
> >
> > @@ -690,8 +697,8 @@ fw_create_instance(struct firmware *firmware,
> const char *fw_name,
> >
> > fw_priv->nowait = nowait;
> > fw_priv->fw = firmware;
> > -   setup_timer(_priv->timeout,
> > -   firmware_class_timeout, (u_long) fw_priv);
> > +   INIT_DELAYED_WORK(_priv->timeout_work,
> > +   firmware_class_timeout_work);
> >
> > f_dev = _priv->dev;
> >
> > @@ -858,7 +865,9 @@ static int _request_firmware_load(struct
> firmware_priv *fw_priv, bool uevent,
> > dev_dbg(f_dev->parent, "firmware: direct-loading"
> > " firmware %s\n", buf->fw_id);
> >
> > +   mutex_lock(_lock);
> > set_bit(FW_STATUS_DONE, >status);
> > +   mutex_unlock(_lock);
> > complete_all(>completion);
> > direct_load = 1;
> > goto handle_fw;
> > @@ -894,15 +903,15 @@ static int _request_firmware_load(struct
> firmware_priv *fw_priv, bool uevent,
> > dev_set_uevent_suppress(f_dev, false);
> > dev_dbg(f_dev, "firmware: requesting %s\n",
> buf->fw_id);
> > if (timeout != MAX_SCHEDULE_TIMEOUT)
> > -   mod_timer(_priv->timeout,
> > - round_jiffies_up(jiffies + timeout));
> > +
> schedule_delayed_work(_priv->timeout_work,
> > +   timeout * HZ);
> 
> timeout is in unit of jiffies already, so multiplying by 'HZ' isn't needed.
Oh, sorry for that, I just tested it in one old version.
Will update the patch soon.

> 
> >
> > kobject_uevent(_priv->dev.kobj, KOBJ_ADD);
> > }
> >
> > wait_for_completion(>completion);
> >
> > -   del_timer_sync(_priv->timeout);
> > +   cancel_delayed_work_sync(_priv->timeout_work);
> >
> >  handle_fw:
> > mutex_lock(_lock);
> > --
> > 1.7.0.4
> >
> >
> >
> 
> Thanks,
> --
> Ming Lei
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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: [BUGFIX] PM: Fix active child counting when disabled and forbidden

[Huang Ying]

On Thu, 2012-11-08 at 02:35 +0100, Rafael J. Wysocki wrote:
> On Thursday, November 08, 2012 09:15:08 AM Huang Ying wrote:
> > On Thu, 2012-11-08 at 00:09 +0100, Rafael J. Wysocki wrote:
> > > On Wednesday, November 07, 2012 11:51:15 PM Rafael J. Wysocki wrote:
> > > > On Wednesday, November 07, 2012 04:56:49 PM Alan Stern wrote:
> > > > > On Wed, 7 Nov 2012, Rafael J. Wysocki wrote:
> > > > > 
> > > > > > > Right.  The reasoning behind my proposal goes like this: When 
> > > > > > > there's
> > > > > > > no driver, the subsystem can let userspace directly control the
> > > > > > > device's power level through the power/control attribute.
> > > > > > 
> > > > > > Well, we might as well just leave the runtime PM of PCI devices 
> > > > > > enabled, even
> > > > > > if they have no drivers, but modify the PCI bus type's runtime PM 
> > > > > > callbacks
> > > > > > to ignore devices with no drivers.
> > > > > > 
> > > > > > IIRC the reason why we decided to disable runtime PM for PCI device 
> > > > > > with no
> > > > > > drivers was that some of them refused to work again after being put 
> > > > > > by the
> > > > > > core into D3.  By making the PCI bus type's runtime PM callbacks 
> > > > > > ignore them
> > > > > > we'd avoid this problem without modifying the core's behavior.
> > > > > 
> > > > > It comes down to a question of the parent.  If a driverless PCI device
> > > > > isn't being used, shouldn't its parent be allowed to go into runtime
> > > > > suspend?  As things stand now, we do allow it.
> > > > > 
> > > > > The problem is that we don't disallow it when the driverless device
> > > > > _is_ being used.
> > > > 
> > > > We can make it depend on what's there in the control file.  Let's say 
> > > > if that's
> > > > "on" (ie. the devices usage counter is not zero), we won't allow the 
> > > > parent
> > > > to be suspended.
> > > > 
> > > > So, as I said, why don't we keep the runtime PM of PCI devices always 
> > > > enabled,
> > > > regardless of whether or not there is a driver, and arrange things in 
> > > > such a
> > > > way that the device is automatically "suspended" if user space writes 
> > > > "auto"
> > > > to the control file.  IOW, I suppose we can do something like this:
> > > 
> > > It probably is better to treat the "no driver" case in a special way, 
> > > though:
> > > 
> > > ---
> > >  drivers/pci/pci-driver.c |   45 
> > > +
> > >  drivers/pci/pci.c|2 ++
> > >  2 files changed, 27 insertions(+), 20 deletions(-)
> > > 
> > > Index: linux-pm/drivers/pci/pci-driver.c
> > > ===
> > > --- linux-pm.orig/drivers/pci/pci-driver.c
> > > +++ linux-pm/drivers/pci/pci-driver.c
> > > @@ -263,22 +263,17 @@ static long local_pci_probe(void *_ddi)
> > >   /* The parent bridge must be in active state when probing */
> > >   if (parent)
> > >   pm_runtime_get_sync(parent);
> > > - /* Unbound PCI devices are always set to disabled and suspended.
> > > -  * During probe, the device is set to enabled and active and the
> > > -  * usage count is incremented.  If the driver supports runtime PM,
> > > -  * it should call pm_runtime_put_noidle() in its probe routine and
> > > + /*
> > > +  * During probe, the device is set to active and the usage count is
> > > +  * incremented.  If the driver supports runtime PM, it should call
> > > +  * pm_runtime_put_noidle() in its probe routine and
> > >* pm_runtime_get_noresume() in its remove routine.
> > >*/
> > > - pm_runtime_get_noresume(dev);
> > > - pm_runtime_set_active(dev);
> > > - pm_runtime_enable(dev);
> > > -
> > > + pm_runtime_get_sync(dev);
> > >   rc = ddi->drv->probe(ddi->dev, ddi->id);
> > > - if (rc) {
> > > - pm_runtime_disable(dev);
> > > - pm_runtime_set_suspended(dev);
> > > - pm_runtime_put_noidle(dev);
> > > - }
> > > + if (rc)
> > > + pm_runtime_put_sync(dev);
> > > +
> > >   if (parent)
> > >   pm_runtime_put(parent);
> > >   return rc;
> > > @@ -369,9 +364,7 @@ static int pci_device_remove(struct devi
> > >   }
> > >  
> > >   /* Undo the runtime PM settings in local_pci_probe() */
> > > - pm_runtime_disable(dev);
> > > - pm_runtime_set_suspended(dev);
> > > - pm_runtime_put_noidle(dev);
> > > + pm_runtime_put_sync(dev);
> > >  
> > >   /*
> > >* If the device is still on, set the power state as "unknown",
> > > @@ -998,10 +991,14 @@ static int pci_pm_restore(struct device
> > >  static int pci_pm_runtime_suspend(struct device *dev)
> > >  {
> > >   struct pci_dev *pci_dev = to_pci_dev(dev);
> > > - const struct dev_pm_ops *pm = dev->driver ? dev->driver->pm : NULL;
> > > + const struct dev_pm_ops *pm;
> > >   pci_power_t prev = pci_dev->current_state;
> > >   int error;
> > >  
> > > + if (!dev->driver)
> > > + return 0;
> > > +
> > > + pm = dev->driver->pm;
> > >   if (!pm || !pm->runtime_suspend)
> > >   return -ENOSYS;
> > >  
> > 

Re: [PATCH V2] firmware loader: Fix the race FW_STATUS_DONE is followed by class_timeout

[Ming Lei]

On Thu, Nov 8, 2012 at 6:29 PM, Chuansheng Liu  wrote:
>
> There is a race as below when calling request_firmware():
> CPU1   CPU2
> write 0 > loading
> mutex_lock(_lock)
> ...
> set_bit FW_STATUS_DONE class_timeout is coming
>set_bit FW_STATUS_ABORT
> complete_all 
> ...
> mutex_unlock(_lock)
>
> In this time, the bit FW_STATUS_DONE and FW_STATUS_ABORT are set,
> and request_firmware() will return failure due to condition in
> _request_firmware_load():
> if (!buf->size || test_bit(FW_STATUS_ABORT, >status))
> retval = -ENOENT;
>
> But from the above scenerio, it should be a successful requesting.
> So we need judge if the bit FW_STATUS_DONE is already set before
> calling fw_load_abort() in timeout function.
>
> As Ming's proposal, we need change the timer into sched_work to
> benefit from using _lock mutex also.
>
> Signed-off-by: liu chuansheng 
> ---
>  drivers/base/firmware_class.c |   25 +
>  1 files changed, 17 insertions(+), 8 deletions(-)
>
> diff --git a/drivers/base/firmware_class.c b/drivers/base/firmware_class.c
> index 8945f4e..f2caa0a 100644
> --- a/drivers/base/firmware_class.c
> +++ b/drivers/base/firmware_class.c
> @@ -143,7 +143,7 @@ struct fw_cache_entry {
>  };
>
>  struct firmware_priv {
> -   struct timer_list timeout;
> +   struct delayed_work timeout_work;
> bool nowait;
> struct device dev;
> struct firmware_buf *buf;
> @@ -667,10 +667,17 @@ static struct bin_attribute firmware_attr_data = {
> .write = firmware_data_write,
>  };
>
> -static void firmware_class_timeout(u_long data)
> +static void firmware_class_timeout_work(struct work_struct *work)
>  {
> -   struct firmware_priv *fw_priv = (struct firmware_priv *) data;
> +   struct firmware_priv *fw_priv = container_of(work,
> +   struct firmware_priv, timeout_work.work);
>
> +   mutex_lock(_lock);
> +   if (test_bit(FW_STATUS_DONE, &(fw_priv->buf->status))) {
> +   mutex_unlock(_lock);
> +   return;
> +   }
> +   mutex_unlock(_lock);
> fw_load_abort(fw_priv);

fw_lock should be held when fw_load_abort(fw_priv) is running.

>  }
>
> @@ -690,8 +697,8 @@ fw_create_instance(struct firmware *firmware, const char 
> *fw_name,
>
> fw_priv->nowait = nowait;
> fw_priv->fw = firmware;
> -   setup_timer(_priv->timeout,
> -   firmware_class_timeout, (u_long) fw_priv);
> +   INIT_DELAYED_WORK(_priv->timeout_work,
> +   firmware_class_timeout_work);
>
> f_dev = _priv->dev;
>
> @@ -858,7 +865,9 @@ static int _request_firmware_load(struct firmware_priv 
> *fw_priv, bool uevent,
> dev_dbg(f_dev->parent, "firmware: direct-loading"
> " firmware %s\n", buf->fw_id);
>
> +   mutex_lock(_lock);
> set_bit(FW_STATUS_DONE, >status);
> +   mutex_unlock(_lock);
> complete_all(>completion);
> direct_load = 1;
> goto handle_fw;
> @@ -894,15 +903,15 @@ static int _request_firmware_load(struct firmware_priv 
> *fw_priv, bool uevent,
> dev_set_uevent_suppress(f_dev, false);
> dev_dbg(f_dev, "firmware: requesting %s\n", buf->fw_id);
> if (timeout != MAX_SCHEDULE_TIMEOUT)
> -   mod_timer(_priv->timeout,
> - round_jiffies_up(jiffies + timeout));
> +   schedule_delayed_work(_priv->timeout_work,
> +   timeout * HZ);

timeout is in unit of jiffies already, so multiplying by 'HZ' isn't needed.

>
> kobject_uevent(_priv->dev.kobj, KOBJ_ADD);
> }
>
> wait_for_completion(>completion);
>
> -   del_timer_sync(_priv->timeout);
> +   cancel_delayed_work_sync(_priv->timeout_work);
>
>  handle_fw:
> mutex_lock(_lock);
> --
> 1.7.0.4
>
>
>

Thanks,
--
Ming Lei
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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: scsi target, likely GPL violation

[Chris Friesen]

On 11/07/2012 07:02 PM, Jon Mason wrote:

I'm not a lawyer, nor do I play one on TV, but if
I understand the GPL correctly, RTS only needs to provide the relevant
source to their customers upon request.


Not quite.

Assuming the GPL applies, and that they have modified the code, then 
they must either:


1) include the source with the distributed binary

or

2) include with the binary an offer to provide the source to *any* third 
party


Chris
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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 -next] ACPI: fix missing unlock on error in acpi_memory_remove_memory()

[Wen Congyang]

Hi, wei

At 11/07/2012 08:38 PM, Wei Yongjun Wrote:
> From: Wei Yongjun 
> 
> Add the missing mutex_unlock() before return from function
> acpi_memory_remove_memory() in the error handling case.
> 
> Introduce by commit 85fcb3758c10e063a2a30dfad75017097999deed
> 'ACPI / memory-hotplug: introduce a mutex lock to protect the list in 
> acpi_memory_device'
> 
> dpatch engine is used to auto generate this patch.
> (https://github.com/weiyj/dpatch)
> 
> Signed-off-by: Wei Yongjun 

Thanks for your patch.

Dan Carpenter has told me this problem. I fix it, but don't
resend it because it is in test now.

Thanks
Wen Congyang

> ---
>  drivers/acpi/acpi_memhotplug.c | 4 +++-
>  1 file changed, 3 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/acpi/acpi_memhotplug.c b/drivers/acpi/acpi_memhotplug.c
> index 92c973a..e573e87 100644
> --- a/drivers/acpi/acpi_memhotplug.c
> +++ b/drivers/acpi/acpi_memhotplug.c
> @@ -325,8 +325,10 @@ static int acpi_memory_remove_memory(struct 
> acpi_memory_device *mem_device)
>   list_for_each_entry_safe(info, n, _device->res_list, list) {
>   if (info->enabled) {
>   result = remove_memory(info->start_addr, info->length);
> - if (result)
> + if (result) {
> + mutex_unlock(_device->list_lock);
>   return result;
> + }
>   }
>  
>   list_del(>list);
> 
> 
> 

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

Re: [PATCH v3 1/1] percpu_rw_semaphore: reimplement to not block the readers unnecessarily

[Paul E. McKenney]

On Wed, Nov 07, 2012 at 12:04:48PM -0500, Mikulas Patocka wrote:
> It looks sensible.
> 
> Here I'm sending an improvement of the patch - I changed it so that there 
> are not two-level nested functions for the fast path and so that both 
> percpu_down_read and percpu_up_read use the same piece of code (to reduce 
> cache footprint).
> 
> ---
> 
> Currently the writer does msleep() plus synchronize_sched() 3 times
> to acquire/release the semaphore, and during this time the readers
> are blocked completely. Even if the "write" section was not actually
> started or if it was already finished.
> 
> With this patch down_write/up_write does synchronize_sched() twice
> and down_read/up_read are still possible during this time, just they
> use the slow path.
> 
> percpu_down_write() first forces the readers to use rw_semaphore and
> increment the "slow" counter to take the lock for reading, then it
> takes that rw_semaphore for writing and blocks the readers.
> 
> Also. With this patch the code relies on the documented behaviour of
> synchronize_sched(), it doesn't try to pair synchronize_sched() with
> barrier.
> 
> Signed-off-by: Oleg Nesterov 
> Signed-off-by: Mikulas Patocka 

>From a memory-ordering viewpoint, this looks to me to work the same
way that Oleg's does.  Oleg's approach looks better to me, though that
might be because I have looked at it quite a few times over the past
several days.

Thanx, Paul

> ---
>  include/linux/percpu-rwsem.h |   80 ++-
>  lib/Makefile |2 
>  lib/percpu-rwsem.c   |  110 
> +++
>  3 files changed, 127 insertions(+), 65 deletions(-)
>  create mode 100644 lib/percpu-rwsem.c
> 
> Index: linux-3.6.6-fast/include/linux/percpu-rwsem.h
> ===
> --- linux-3.6.6-fast.orig/include/linux/percpu-rwsem.h2012-11-05 
> 16:21:29.0 +0100
> +++ linux-3.6.6-fast/include/linux/percpu-rwsem.h 2012-11-07 
> 16:44:04.0 +0100
> @@ -2,82 +2,34 @@
>  #define _LINUX_PERCPU_RWSEM_H
> 
>  #include 
> +#include 
>  #include 
> -#include 
> -#include 
> +#include 
> 
>  struct percpu_rw_semaphore {
> - unsigned __percpu *counters;
> - bool locked;
> - struct mutex mtx;
> + unsigned int __percpu   *fast_read_ctr;
> + struct mutexwriter_mutex;
> + struct rw_semaphore rw_sem;
> + atomic_tslow_read_ctr;
> + wait_queue_head_t   write_waitq;
>  };
> 
> -#define light_mb()   barrier()
> -#define heavy_mb()   synchronize_sched()
> +extern void __percpu_down_up_read(struct percpu_rw_semaphore *, int);
> 
> -static inline void percpu_down_read(struct percpu_rw_semaphore *p)
> -{
> - rcu_read_lock_sched();
> - if (unlikely(p->locked)) {
> - rcu_read_unlock_sched();
> - mutex_lock(>mtx);
> - this_cpu_inc(*p->counters);
> - mutex_unlock(>mtx);
> - return;
> - }
> - this_cpu_inc(*p->counters);
> - rcu_read_unlock_sched();
> - light_mb(); /* A, between read of p->locked and read of data, paired 
> with D */
> -}
> -
> -static inline void percpu_up_read(struct percpu_rw_semaphore *p)
> -{
> - light_mb(); /* B, between read of the data and write to p->counter, 
> paired with C */
> - this_cpu_dec(*p->counters);
> -}
> -
> -static inline unsigned __percpu_count(unsigned __percpu *counters)
> -{
> - unsigned total = 0;
> - int cpu;
> -
> - for_each_possible_cpu(cpu)
> - total += ACCESS_ONCE(*per_cpu_ptr(counters, cpu));
> +extern void percpu_down_write(struct percpu_rw_semaphore *);
> +extern void percpu_up_write(struct percpu_rw_semaphore *);
> 
> - return total;
> -}
> -
> -static inline void percpu_down_write(struct percpu_rw_semaphore *p)
> -{
> - mutex_lock(>mtx);
> - p->locked = true;
> - synchronize_sched(); /* make sure that all readers exit the 
> rcu_read_lock_sched region */
> - while (__percpu_count(p->counters))
> - msleep(1);
> - heavy_mb(); /* C, between read of p->counter and write to data, paired 
> with B */
> -}
> -
> -static inline void percpu_up_write(struct percpu_rw_semaphore *p)
> -{
> - heavy_mb(); /* D, between write to data and write to p->locked, paired 
> with A */
> - p->locked = false;
> - mutex_unlock(>mtx);
> -}
> +extern int percpu_init_rwsem(struct percpu_rw_semaphore *);
> +extern void percpu_free_rwsem(struct percpu_rw_semaphore *);
> 
> -static inline int percpu_init_rwsem(struct percpu_rw_semaphore *p)
> +static inline void percpu_down_read(struct percpu_rw_semaphore *s)
>  {
> - p->counters = alloc_percpu(unsigned);
> - if (unlikely(!p->counters))
> - return -ENOMEM;
> - p->locked = false;
> - mutex_init(>mtx);
> - return 0;
> + __percpu_down_up_read(s, 1);
>  }
> 
> -static 

RE: [PATCH] firmware loader: Fix the race FW_STATUS_DONE is followed by class_timeout

[Liu, Chuansheng]

> -Original Message-
> From: Ming Lei [mailto:ming@canonical.com]
> Sent: Wednesday, November 07, 2012 6:40 PM
> To: Liu, Chuansheng
> Cc: gre...@linuxfoundation.org; linux-kernel@vger.kernel.org
> Subject: Re: [PATCH] firmware loader: Fix the race FW_STATUS_DONE is
> followed by class_timeout
> 
> On Thu, Nov 8, 2012 at 12:45 AM, Chuansheng Liu
>  wrote:
> >
> > There is a race condition as below when calling request_firmware():
> >
> > CPU1CPU2
> > write 0 > loading
> > mutex_lock(_lock);
> > ...
> > set_bit FW_STATUS_DONE  class_timeout is coming
> > set_bit
> FW_STATUS_ABORT
> > complete_all 
> > ...
> > mutex_unlock(_lock)
> 
> Good catch, but your fix isn't correct.
> 
> >
> > In this time, the bit FW_STATUS_DONE and FW_STATUS_ABORT are set,
> > and request_firmware() will return failure due to condition in
> > _request_firmware_load():
> >
> > if (!buf->size || test_bit(FW_STATUS_ABORT, >status))
> > retval = -ENOENT;
> >
> > But from the above scenerio, it should be a succcessful requesting.
> > So we need judge if the FW_STATUS_DONE is set before calling abort
> > in timeout function firmware_class_timeout().
> >
> > Signed-off-by: liu chuansheng 
> > ---
> >  drivers/base/firmware_class.c |7 +++
> >  1 files changed, 7 insertions(+), 0 deletions(-)
> >
> > diff --git a/drivers/base/firmware_class.c b/drivers/base/firmware_class.c
> > index 8945f4e..35fffd8 100644
> > --- a/drivers/base/firmware_class.c
> > +++ b/drivers/base/firmware_class.c
> > @@ -671,6 +671,13 @@ static void firmware_class_timeout(u_long data)
> >  {
> > struct firmware_priv *fw_priv = (struct firmware_priv *) data;
> >
> > +   mutex_lock(_lock);
> 
> mutex can't be used in interrupt context, so one candidate fix is
> to convert the timeout timer into delayed work, and hold the
> 'fw_lock' during the work function.
> 
> > +   if (test_bit(FW_STATUS_DONE, &(fw_priv->buf->status))) {
> > +   mutex_unlock(_lock);
> > +   return;
> > +   }
> > +   mutex_unlock(_lock);
> > +
> > fw_load_abort(fw_priv);
> >  }
> 
> Also the lock of 'fw_lock' should be held when setting 'FW_STATUS_DONE'
> in _request_firmware_load().
> 
> Could you send out a new patch to fix the race?
Thanks your review and proposal, has sent the patch V2 to be reviewed.
> 
> Thanks,
> --
> Ming Lei
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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: [BUGFIX] PM: Fix active child counting when disabled and forbidden

[Rafael J. Wysocki]

On Thursday, November 08, 2012 09:15:08 AM Huang Ying wrote:
> On Thu, 2012-11-08 at 00:09 +0100, Rafael J. Wysocki wrote:
> > On Wednesday, November 07, 2012 11:51:15 PM Rafael J. Wysocki wrote:
> > > On Wednesday, November 07, 2012 04:56:49 PM Alan Stern wrote:
> > > > On Wed, 7 Nov 2012, Rafael J. Wysocki wrote:
> > > > 
> > > > > > Right.  The reasoning behind my proposal goes like this: When 
> > > > > > there's
> > > > > > no driver, the subsystem can let userspace directly control the
> > > > > > device's power level through the power/control attribute.
> > > > > 
> > > > > Well, we might as well just leave the runtime PM of PCI devices 
> > > > > enabled, even
> > > > > if they have no drivers, but modify the PCI bus type's runtime PM 
> > > > > callbacks
> > > > > to ignore devices with no drivers.
> > > > > 
> > > > > IIRC the reason why we decided to disable runtime PM for PCI device 
> > > > > with no
> > > > > drivers was that some of them refused to work again after being put 
> > > > > by the
> > > > > core into D3.  By making the PCI bus type's runtime PM callbacks 
> > > > > ignore them
> > > > > we'd avoid this problem without modifying the core's behavior.
> > > > 
> > > > It comes down to a question of the parent.  If a driverless PCI device
> > > > isn't being used, shouldn't its parent be allowed to go into runtime
> > > > suspend?  As things stand now, we do allow it.
> > > > 
> > > > The problem is that we don't disallow it when the driverless device
> > > > _is_ being used.
> > > 
> > > We can make it depend on what's there in the control file.  Let's say if 
> > > that's
> > > "on" (ie. the devices usage counter is not zero), we won't allow the 
> > > parent
> > > to be suspended.
> > > 
> > > So, as I said, why don't we keep the runtime PM of PCI devices always 
> > > enabled,
> > > regardless of whether or not there is a driver, and arrange things in 
> > > such a
> > > way that the device is automatically "suspended" if user space writes 
> > > "auto"
> > > to the control file.  IOW, I suppose we can do something like this:
> > 
> > It probably is better to treat the "no driver" case in a special way, 
> > though:
> > 
> > ---
> >  drivers/pci/pci-driver.c |   45 
> > +
> >  drivers/pci/pci.c|2 ++
> >  2 files changed, 27 insertions(+), 20 deletions(-)
> > 
> > Index: linux-pm/drivers/pci/pci-driver.c
> > ===
> > --- linux-pm.orig/drivers/pci/pci-driver.c
> > +++ linux-pm/drivers/pci/pci-driver.c
> > @@ -263,22 +263,17 @@ static long local_pci_probe(void *_ddi)
> > /* The parent bridge must be in active state when probing */
> > if (parent)
> > pm_runtime_get_sync(parent);
> > -   /* Unbound PCI devices are always set to disabled and suspended.
> > -* During probe, the device is set to enabled and active and the
> > -* usage count is incremented.  If the driver supports runtime PM,
> > -* it should call pm_runtime_put_noidle() in its probe routine and
> > +   /*
> > +* During probe, the device is set to active and the usage count is
> > +* incremented.  If the driver supports runtime PM, it should call
> > +* pm_runtime_put_noidle() in its probe routine and
> >  * pm_runtime_get_noresume() in its remove routine.
> >  */
> > -   pm_runtime_get_noresume(dev);
> > -   pm_runtime_set_active(dev);
> > -   pm_runtime_enable(dev);
> > -
> > +   pm_runtime_get_sync(dev);
> > rc = ddi->drv->probe(ddi->dev, ddi->id);
> > -   if (rc) {
> > -   pm_runtime_disable(dev);
> > -   pm_runtime_set_suspended(dev);
> > -   pm_runtime_put_noidle(dev);
> > -   }
> > +   if (rc)
> > +   pm_runtime_put_sync(dev);
> > +
> > if (parent)
> > pm_runtime_put(parent);
> > return rc;
> > @@ -369,9 +364,7 @@ static int pci_device_remove(struct devi
> > }
> >  
> > /* Undo the runtime PM settings in local_pci_probe() */
> > -   pm_runtime_disable(dev);
> > -   pm_runtime_set_suspended(dev);
> > -   pm_runtime_put_noidle(dev);
> > +   pm_runtime_put_sync(dev);
> >  
> > /*
> >  * If the device is still on, set the power state as "unknown",
> > @@ -998,10 +991,14 @@ static int pci_pm_restore(struct device
> >  static int pci_pm_runtime_suspend(struct device *dev)
> >  {
> > struct pci_dev *pci_dev = to_pci_dev(dev);
> > -   const struct dev_pm_ops *pm = dev->driver ? dev->driver->pm : NULL;
> > +   const struct dev_pm_ops *pm;
> > pci_power_t prev = pci_dev->current_state;
> > int error;
> >  
> > +   if (!dev->driver)
> > +   return 0;
> > +
> > +   pm = dev->driver->pm;
> > if (!pm || !pm->runtime_suspend)
> > return -ENOSYS;
> >  
> > @@ -1035,8 +1032,12 @@ static int pci_pm_runtime_resume(struct
> >  {
> > int rc;
> > struct pci_dev *pci_dev = to_pci_dev(dev);
> > -   const struct dev_pm_ops *pm = dev->driver ? 

[PATCH V2] firmware loader: Fix the race FW_STATUS_DONE is followed by class_timeout

[Chuansheng Liu]

There is a race as below when calling request_firmware():
CPU1   CPU2
write 0 > loading
mutex_lock(_lock)
...
set_bit FW_STATUS_DONE class_timeout is coming
   set_bit FW_STATUS_ABORT
complete_all 
...
mutex_unlock(_lock)

In this time, the bit FW_STATUS_DONE and FW_STATUS_ABORT are set,
and request_firmware() will return failure due to condition in
_request_firmware_load():
if (!buf->size || test_bit(FW_STATUS_ABORT, >status))
retval = -ENOENT;

But from the above scenerio, it should be a successful requesting.
So we need judge if the bit FW_STATUS_DONE is already set before
calling fw_load_abort() in timeout function.

As Ming's proposal, we need change the timer into sched_work to
benefit from using _lock mutex also.

Signed-off-by: liu chuansheng 
---
 drivers/base/firmware_class.c |   25 +
 1 files changed, 17 insertions(+), 8 deletions(-)

diff --git a/drivers/base/firmware_class.c b/drivers/base/firmware_class.c
index 8945f4e..f2caa0a 100644
--- a/drivers/base/firmware_class.c
+++ b/drivers/base/firmware_class.c
@@ -143,7 +143,7 @@ struct fw_cache_entry {
 };
 
 struct firmware_priv {
-   struct timer_list timeout;
+   struct delayed_work timeout_work;
bool nowait;
struct device dev;
struct firmware_buf *buf;
@@ -667,10 +667,17 @@ static struct bin_attribute firmware_attr_data = {
.write = firmware_data_write,
 };
 
-static void firmware_class_timeout(u_long data)
+static void firmware_class_timeout_work(struct work_struct *work)
 {
-   struct firmware_priv *fw_priv = (struct firmware_priv *) data;
+   struct firmware_priv *fw_priv = container_of(work,
+   struct firmware_priv, timeout_work.work);
 
+   mutex_lock(_lock);
+   if (test_bit(FW_STATUS_DONE, &(fw_priv->buf->status))) {
+   mutex_unlock(_lock);
+   return;
+   }
+   mutex_unlock(_lock);
fw_load_abort(fw_priv);
 }
 
@@ -690,8 +697,8 @@ fw_create_instance(struct firmware *firmware, const char 
*fw_name,
 
fw_priv->nowait = nowait;
fw_priv->fw = firmware;
-   setup_timer(_priv->timeout,
-   firmware_class_timeout, (u_long) fw_priv);
+   INIT_DELAYED_WORK(_priv->timeout_work,
+   firmware_class_timeout_work);
 
f_dev = _priv->dev;
 
@@ -858,7 +865,9 @@ static int _request_firmware_load(struct firmware_priv 
*fw_priv, bool uevent,
dev_dbg(f_dev->parent, "firmware: direct-loading"
" firmware %s\n", buf->fw_id);
 
+   mutex_lock(_lock);
set_bit(FW_STATUS_DONE, >status);
+   mutex_unlock(_lock);
complete_all(>completion);
direct_load = 1;
goto handle_fw;
@@ -894,15 +903,15 @@ static int _request_firmware_load(struct firmware_priv 
*fw_priv, bool uevent,
dev_set_uevent_suppress(f_dev, false);
dev_dbg(f_dev, "firmware: requesting %s\n", buf->fw_id);
if (timeout != MAX_SCHEDULE_TIMEOUT)
-   mod_timer(_priv->timeout,
- round_jiffies_up(jiffies + timeout));
+   schedule_delayed_work(_priv->timeout_work,
+   timeout * HZ);
 
kobject_uevent(_priv->dev.kobj, KOBJ_ADD);
}
 
wait_for_completion(>completion);
 
-   del_timer_sync(_priv->timeout);
+   cancel_delayed_work_sync(_priv->timeout_work);
 
 handle_fw:
mutex_lock(_lock);
-- 
1.7.0.4



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

Re: [PATCH] extcon : callback function to read cable property

[Chanwoo Choi]

On 10/17/2012 03:34 PM, Tc, Jenny wrote:
 Subject: Re: [PATCH] extcon : callback function to read cable
 property

 I think the reason why we have extcon is in first place is to only
 notify the clients of cable connection and disconnection and it is
 up to the client to decide what else to do with the cable such as
 finding which state it is in and other details.
 So I feel this should not be handled in the extcon.

 However it is up to the maintainer to decide.
>>>
>>> Once the consumer gets the notification, it needs to take some action.
>>> One of the action is to read the cable properties. This can be done by
>>> proprietary calls which is known both to the consumer and the provider.
>>> My intention is to avoid this proprietary calls. Since both the
>>> provider and consumer are communicating with the extcon subsystem , I
>>> feel having a callback function of this kind would help to avoid the
>>> use of proprietary calls. Also I agree that extcon notifier chains are
>>> used to notify the cable state (attach/detach). But if a cable has
>>> more than two states (like the charger cable) how do we support it without
>> having a callback function like this?
>>> Let the maintainer take the final decision.
>> Well this use case will keep on growing if we start factor in this kind of
>> changes and that is why I am opposed to adding any other state.
>> Maintainer?
>>>

I think that the role of extcon subsystem notify changed 
state(attached/detached)
of cable to notifiee, but if you want to add property feature of cable,
you should solve ambiguous issues.

First,
This patch only support the properties of charger cable but, never
support property of other cable. The following structure depend on
only charger cable. We can check it the following structure:
struct extcon_chrg_cbl_props {
enum extcon_chrgr_cbl_stat cable_state;
unsigned long mA;
};

I think that the patch have to support all of cables for property feature.

Second,
Certainly, you should define common properties of all cables and
specific properties of each cable. The properties of charger cable
should never be defined only.

Third,
If we finish to decide the properties for all cables, I'd like to see a example 
code.

You explained following changed state of USB according to Host state on other 
patch.
---
For USB2.0
1) CONNECT (100mA)->UPDATE(500mA)->DISCONNECT(0mA)
2) CONNECT (100mA)->UPDATE(500mA)->HOST SUSPEND(2.5mA/500mA)->DISCONNECT(0mA)
3) CONNECT (100mA)->UPDATE(500mA)->HOST SUSPEND(2.5mA/500mA)->HOST 
RESUME(500mA)->DISCONNECT(0mA)

For USB 3.0
4) CONNECT (150mA)->UPDATE(900mA)->DISCONNECT(0mA)
5) CONNECT (150mA)->UPDATE(900mA)-> HOST SUSPEND(2.5mA/900mA)->DISCONNECT(0mA)
6) CONNECT (100mA)->UPDATE(900mA)->HOST SUSPEND(2.5mA/900mA)->HOST 
RESUME(900mA)->DISCONNECT(0mA)
---

I have a question. Can the provider device driver(e.g., extcon-max77693.c/
extcon-max8997.c) detect the changed state of host? I'd like to see the
example device driver that the provider device driver detect changed state of 
host.
Could you provide example device driver?

Thanks,
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] add tpm_xenu.ko: Xen Virtual TPM frontend driver

[Konrad Rzeszutek Wilk]

On Wed, Nov 07, 2012 at 01:14:25PM -0500, Matthew Fioravante wrote:
> On 11/07/2012 09:46 AM, Kent Yoder wrote:
> >Hi Matthew,
> >
> >On Mon, Nov 05, 2012 at 10:09:57AM -0500, Matthew Fioravante wrote:
> >>This patch ports the xen vtpm frontend driver for linux
> >>from the linux-2.6.18-xen.hg tree to linux-stable.
> >>
> >>Signed-off-by: Matthew Fioravante 
> >>---
> >>  drivers/char/tpm/Kconfig |9 +
> >>  drivers/char/tpm/Makefile|2 +
> >>  drivers/char/tpm/tpm.h   |   15 +
> >>  drivers/char/tpm/tpm_vtpm.c  |  543 ++
> >>  drivers/char/tpm/tpm_vtpm.h  |   55 +++
> >>  drivers/char/tpm/tpm_xen.c   |  690 
> >> ++
> >>  include/xen/interface/io/tpmif.h |   77 +
> >>  7 files changed, 1391 insertions(+)
> >>  create mode 100644 drivers/char/tpm/tpm_vtpm.c
> >>  create mode 100644 drivers/char/tpm/tpm_vtpm.h
> >>  create mode 100644 drivers/char/tpm/tpm_xen.c
> >>  create mode 100644 include/xen/interface/io/tpmif.h
> >>
> >>diff --git a/drivers/char/tpm/Kconfig b/drivers/char/tpm/Kconfig
> >>index 915875e..08c1010 100644
> >>--- a/drivers/char/tpm/Kconfig
> >>+++ b/drivers/char/tpm/Kconfig
> >>@@ -81,4 +81,13 @@ config TCG_IBMVTPM
> >>  will be accessible from within Linux.  To compile this driver
> >>  as a module, choose M here; the module will be called tpm_ibmvtpm.
> >>
> >>+config TCG_XEN
> >>+   tristate "XEN TPM Interface"
> >>+   depends on TCG_TPM && XEN
> >>+   ---help---
> >>+ If you want to make TPM support available to a Xen user domain,
> >>+ say Yes and it will be accessible from within Linux.
> >>+ To compile this driver as a module, choose M here; the module
> >>+ will be called tpm_xenu.
> >>+
> >>  endif # TCG_TPM
> >>diff --git a/drivers/char/tpm/Makefile b/drivers/char/tpm/Makefile
> >>index 5b3fc8b..16911c5 100644
> >>--- a/drivers/char/tpm/Makefile
> >>+++ b/drivers/char/tpm/Makefile
> >>@@ -17,3 +17,5 @@ obj-$(CONFIG_TCG_NSC) += tpm_nsc.o
> >>  obj-$(CONFIG_TCG_ATMEL) += tpm_atmel.o
> >>  obj-$(CONFIG_TCG_INFINEON) += tpm_infineon.o
> >>  obj-$(CONFIG_TCG_IBMVTPM) += tpm_ibmvtpm.o
> >>+obj-$(CONFIG_TCG_XEN) += tpm_xenu.o
> >>+tpm_xenu-y = tpm_xen.o tpm_vtpm.o
> >  Let's match the naming convention of the other drivers if we can, so this
> >would be something like tpm_xenvtpm.c. tpm_vtpm is too generic...
> Makes sense, fixed.
> >
> >>diff --git a/drivers/char/tpm/tpm.h b/drivers/char/tpm/tpm.h
> >>index 8ef7649..2e5a47a 100644
> >>--- a/drivers/char/tpm/tpm.h
> >>+++ b/drivers/char/tpm/tpm.h
> >>@@ -130,6 +130,9 @@ struct tpm_chip {
> >>
> >>struct list_head list;
> >>void (*release) (struct device *);
> >>+#if CONFIG_XEN
> >>+   void *priv;
> >>+#endif
> >  Can you use the chip->vendor.data pointer here instead? tpm_ibmvtpm is
> >already using that as a priv pointer. I should probably change that name
> >to make it more obvious what that's used for.
> That makes more sense. I'm guessing your data pointer didn't exist
> during the 2.6.18 kernel which is why they added their own priv
> pointer.
> >
> >>  };
> >>
> >>  #define to_tpm_chip(n) container_of(n, struct tpm_chip, vendor)
> >>@@ -310,6 +313,18 @@ struct tpm_cmd_t {
> >>
> >>  ssize_t   tpm_getcap(struct device *, __be32, cap_t *, const char *);
> >>
> >>+#ifdef CONFIG_XEN
> >>+static inline void *chip_get_private(const struct tpm_chip *chip)
> >>+{
> >>+   return chip->priv;
> >>+}
> >>+
> >>+static inline void chip_set_private(struct tpm_chip *chip, void *priv)
> >>+{
> >>+   chip->priv = priv;
> >>+}
> >>+#endif
> >  Can you put these in tpm_vtpm.c please?  One less #define. :-)
> Agreed, I'd rather not have to modify your shared tpm.h interface at all.
> >
> >[cut]
> >>+#ifndef __XEN_PUBLIC_IO_TPMIF_H__
> >>+#define __XEN_PUBLIC_IO_TPMIF_H__
> >>+
> >>+#include "../grant_table.h"
> >>+
> >>+struct tpmif_tx_request {
> >>+   unsigned long addr;   /* Machine address of packet.   */
> >>+   grant_ref_t ref;  /* grant table access reference */
> >>+   uint16_t unused;
> >>+   uint16_t size;/* Packet size in bytes.*/
> >>+};
> >>+typedef struct tpmif_tx_request tpmif_tx_request_t;
> >   checkpatch warned on this new typedef - please run through checkpatch
> >and fix up that stuff.
> tpmif.h has a couple of typedefs which do trigger checkpatch
> warnings. However it looks like the paradigm for xen is to have
> these interface/io/if.h files and all of them have typedefs. I
> think in this case the typedef should probably stay.
> 
> Konrad your thoughts here?

Rip them out plea

> >
> >>+
> >>+/*
> >>+ * The TPMIF_TX_RING_SIZE defines the number of pages the
> >>+ * front-end and backend can exchange (= size of array).
> >>+ */
> >>+typedef uint32_t TPMIF_RING_IDX;
> >>+
> >>+#define TPMIF_TX_RING_SIZE 1
> >>+
> >>+/* This structure must fit in a memory page. */
> >>+
> >>+struct tpmif_ring {
> >>+   struct tpmif_tx_request req;
> >>+};
> >>+typedef struct tpmif_ring