[PATCH 14/14] backlight: tdo24m: convert tdo24m to dev_pm_ops

[Jingoo Han]

Instead of using legacy suspend/resume methods, using newer dev_pm_ops
structure allows better control over power management.

Signed-off-by: Jingoo Han 
---
 drivers/video/backlight/tdo24m.c |   18 --
 1 files changed, 8 insertions(+), 10 deletions(-)

diff --git a/drivers/video/backlight/tdo24m.c b/drivers/video/backlight/tdo24m.c
index 0016208..18cdf46 100644
--- a/drivers/video/backlight/tdo24m.c
+++ b/drivers/video/backlight/tdo24m.c
@@ -412,25 +412,24 @@ static int tdo24m_remove(struct spi_device *spi)
return 0;
 }
 
-#ifdef CONFIG_PM
-static int tdo24m_suspend(struct spi_device *spi, pm_message_t state)
+#ifdef CONFIG_PM_SLEEP
+static int tdo24m_suspend(struct device *dev)
 {
-   struct tdo24m *lcd = spi_get_drvdata(spi);
+   struct tdo24m *lcd = dev_get_drvdata(dev);
 
return tdo24m_power(lcd, FB_BLANK_POWERDOWN);
 }
 
-static int tdo24m_resume(struct spi_device *spi)
+static int tdo24m_resume(struct device *dev)
 {
-   struct tdo24m *lcd = spi_get_drvdata(spi);
+   struct tdo24m *lcd = dev_get_drvdata(dev);
 
return tdo24m_power(lcd, FB_BLANK_UNBLANK);
 }
-#else
-#define tdo24m_suspend NULL
-#define tdo24m_resume  NULL
 #endif
 
+static SIMPLE_DEV_PM_OPS(tdo24m_pm_ops, tdo24m_suspend, tdo24m_resume);
+
 /* Power down all displays on reboot, poweroff or halt */
 static void tdo24m_shutdown(struct spi_device *spi)
 {
@@ -443,12 +442,11 @@ static struct spi_driver tdo24m_driver = {
.driver = {
.name   = "tdo24m",
.owner  = THIS_MODULE,
+   .pm = _pm_ops,
},
.probe  = tdo24m_probe,
.remove = tdo24m_remove,
.shutdown   = tdo24m_shutdown,
-   .suspend= tdo24m_suspend,
-   .resume = tdo24m_resume,
 };
 
 module_spi_driver(tdo24m_driver);
-- 
1.7.2.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 13/14] backlight: ltv350qv: convert ltv350qv to dev_pm_ops

[Jingoo Han]

Instead of using legacy suspend/resume methods, using newer dev_pm_ops
structure allows better control over power management.

Signed-off-by: Jingoo Han 
---
 drivers/video/backlight/ltv350qv.c |   18 --
 1 files changed, 8 insertions(+), 10 deletions(-)

diff --git a/drivers/video/backlight/ltv350qv.c 
b/drivers/video/backlight/ltv350qv.c
index c0b4b8f..ed1b392 100644
--- a/drivers/video/backlight/ltv350qv.c
+++ b/drivers/video/backlight/ltv350qv.c
@@ -271,25 +271,24 @@ static int ltv350qv_remove(struct spi_device *spi)
return 0;
 }
 
-#ifdef CONFIG_PM
-static int ltv350qv_suspend(struct spi_device *spi, pm_message_t state)
+#ifdef CONFIG_PM_SLEEP
+static int ltv350qv_suspend(struct device *dev)
 {
-   struct ltv350qv *lcd = spi_get_drvdata(spi);
+   struct ltv350qv *lcd = dev_get_drvdata(dev);
 
return ltv350qv_power(lcd, FB_BLANK_POWERDOWN);
 }
 
-static int ltv350qv_resume(struct spi_device *spi)
+static int ltv350qv_resume(struct device *dev)
 {
-   struct ltv350qv *lcd = spi_get_drvdata(spi);
+   struct ltv350qv *lcd = dev_get_drvdata(dev);
 
return ltv350qv_power(lcd, FB_BLANK_UNBLANK);
 }
-#else
-#define ltv350qv_suspend   NULL
-#define ltv350qv_resumeNULL
 #endif
 
+static SIMPLE_DEV_PM_OPS(ltv350qv_pm_ops, ltv350qv_suspend, ltv350qv_resume);
+
 /* Power down all displays on reboot, poweroff or halt */
 static void ltv350qv_shutdown(struct spi_device *spi)
 {
@@ -302,13 +301,12 @@ static struct spi_driver ltv350qv_driver = {
.driver = {
.name   = "ltv350qv",
.owner  = THIS_MODULE,
+   .pm = _pm_ops,
},
 
.probe  = ltv350qv_probe,
.remove = ltv350qv_remove,
.shutdown   = ltv350qv_shutdown,
-   .suspend= ltv350qv_suspend,
-   .resume = ltv350qv_resume,
 };
 
 module_spi_driver(ltv350qv_driver);
-- 
1.7.2.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 12/14] backlight: locomolcd: convert locomolcd to dev_pm_ops

[Jingoo Han]

Instead of using legacy suspend/resume methods, using newer dev_pm_ops
structure allows better control over power management.

Signed-off-by: Jingoo Han 
---
 drivers/video/backlight/locomolcd.c |   16 +++-
 1 files changed, 7 insertions(+), 9 deletions(-)

diff --git a/drivers/video/backlight/locomolcd.c 
b/drivers/video/backlight/locomolcd.c
index 146fea8..6c3ec42 100644
--- a/drivers/video/backlight/locomolcd.c
+++ b/drivers/video/backlight/locomolcd.c
@@ -157,25 +157,24 @@ static const struct backlight_ops locomobl_data = {
.update_status  = locomolcd_set_intensity,
 };
 
-#ifdef CONFIG_PM
-static int locomolcd_suspend(struct locomo_dev *dev, pm_message_t state)
+#ifdef CONFIG_PM_SLEEP
+static int locomolcd_suspend(struct device *dev)
 {
locomolcd_flags |= LOCOMOLCD_SUSPENDED;
locomolcd_set_intensity(locomolcd_bl_device);
return 0;
 }
 
-static int locomolcd_resume(struct locomo_dev *dev)
+static int locomolcd_resume(struct device *dev)
 {
locomolcd_flags &= ~LOCOMOLCD_SUSPENDED;
locomolcd_set_intensity(locomolcd_bl_device);
return 0;
 }
-#else
-#define locomolcd_suspend  NULL
-#define locomolcd_resume   NULL
 #endif
 
+static SIMPLE_DEV_PM_OPS(locomolcd_pm_ops, locomolcd_suspend, 
locomolcd_resume);
+
 static int locomolcd_probe(struct locomo_dev *ldev)
 {
struct backlight_properties props;
@@ -230,13 +229,12 @@ static int locomolcd_remove(struct locomo_dev *dev)
 
 static struct locomo_driver poodle_lcd_driver = {
.drv = {
-   .name = "locomo-backlight",
+   .name   = "locomo-backlight",
+   .pm = _pm_ops,
},
.devid  = LOCOMO_DEVID_BACKLIGHT,
.probe  = locomolcd_probe,
.remove = locomolcd_remove,
-   .suspend = locomolcd_suspend,
-   .resume = locomolcd_resume,
 };
 
 static int __init locomolcd_init(void)
-- 
1.7.2.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 11/14] backlight: lm3533_bl: convert lm3533_bl to dev_pm_ops

[Jingoo Han]

Instead of using legacy suspend/resume methods, using newer dev_pm_ops
structure allows better control over power management.

Signed-off-by: Jingoo Han 
---
 drivers/video/backlight/lm3533_bl.c |   22 ++
 1 files changed, 10 insertions(+), 12 deletions(-)

diff --git a/drivers/video/backlight/lm3533_bl.c 
b/drivers/video/backlight/lm3533_bl.c
index 5d18d4d..1d1dbfb 100644
--- a/drivers/video/backlight/lm3533_bl.c
+++ b/drivers/video/backlight/lm3533_bl.c
@@ -368,29 +368,28 @@ static int lm3533_bl_remove(struct platform_device *pdev)
return 0;
 }
 
-#ifdef CONFIG_PM
-static int lm3533_bl_suspend(struct platform_device *pdev, pm_message_t state)
+#ifdef CONFIG_PM_SLEEP
+static int lm3533_bl_suspend(struct device *dev)
 {
-   struct lm3533_bl *bl = platform_get_drvdata(pdev);
+   struct lm3533_bl *bl = dev_get_drvdata(dev);
 
-   dev_dbg(>dev, "%s\n", __func__);
+   dev_dbg(dev, "%s\n", __func__);
 
return lm3533_ctrlbank_disable(>cb);
 }
 
-static int lm3533_bl_resume(struct platform_device *pdev)
+static int lm3533_bl_resume(struct device *dev)
 {
-   struct lm3533_bl *bl = platform_get_drvdata(pdev);
+   struct lm3533_bl *bl = dev_get_drvdata(dev);
 
-   dev_dbg(>dev, "%s\n", __func__);
+   dev_dbg(dev, "%s\n", __func__);
 
return lm3533_ctrlbank_enable(>cb);
 }
-#else
-#define lm3533_bl_suspend  NULL
-#define lm3533_bl_resume   NULL
 #endif
 
+static SIMPLE_DEV_PM_OPS(lm3533_bl_pm_ops, lm3533_bl_suspend, 
lm3533_bl_resume);
+
 static void lm3533_bl_shutdown(struct platform_device *pdev)
 {
struct lm3533_bl *bl = platform_get_drvdata(pdev);
@@ -404,12 +403,11 @@ static struct platform_driver lm3533_bl_driver = {
.driver = {
.name   = "lm3533-backlight",
.owner  = THIS_MODULE,
+   .pm = _bl_pm_ops,
},
.probe  = lm3533_bl_probe,
.remove = lm3533_bl_remove,
.shutdown   = lm3533_bl_shutdown,
-   .suspend= lm3533_bl_suspend,
-   .resume = lm3533_bl_resume,
 };
 module_platform_driver(lm3533_bl_driver);
 
-- 
1.7.2.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 10/14] backlight: kb3886_bl: convert kb3886bl to dev_pm_ops

[Jingoo Han]

Instead of using legacy suspend/resume methods, using newer dev_pm_ops
structure allows better control over power management.

Signed-off-by: Jingoo Han 
---
 drivers/video/backlight/kb3886_bl.c |   18 --
 1 files changed, 8 insertions(+), 10 deletions(-)

diff --git a/drivers/video/backlight/kb3886_bl.c 
b/drivers/video/backlight/kb3886_bl.c
index 6c5ed6b..bca6ccc 100644
--- a/drivers/video/backlight/kb3886_bl.c
+++ b/drivers/video/backlight/kb3886_bl.c
@@ -106,29 +106,28 @@ static int kb3886bl_send_intensity(struct 
backlight_device *bd)
return 0;
 }
 
-#ifdef CONFIG_PM
-static int kb3886bl_suspend(struct platform_device *pdev, pm_message_t state)
+#ifdef CONFIG_PM_SLEEP
+static int kb3886bl_suspend(struct device *dev)
 {
-   struct backlight_device *bd = platform_get_drvdata(pdev);
+   struct backlight_device *bd = dev_get_drvdata(dev);
 
kb3886bl_flags |= KB3886BL_SUSPENDED;
backlight_update_status(bd);
return 0;
 }
 
-static int kb3886bl_resume(struct platform_device *pdev)
+static int kb3886bl_resume(struct device *dev)
 {
-   struct backlight_device *bd = platform_get_drvdata(pdev);
+   struct backlight_device *bd = dev_get_drvdata(dev);
 
kb3886bl_flags &= ~KB3886BL_SUSPENDED;
backlight_update_status(bd);
return 0;
 }
-#else
-#define kb3886bl_suspend   NULL
-#define kb3886bl_resumeNULL
 #endif
 
+static SIMPLE_DEV_PM_OPS(kb3886bl_pm_ops, kb3886bl_suspend, kb3886bl_resume);
+
 static int kb3886bl_get_intensity(struct backlight_device *bd)
 {
return kb3886bl_intensity;
@@ -179,10 +178,9 @@ static int kb3886bl_remove(struct platform_device *pdev)
 static struct platform_driver kb3886bl_driver = {
.probe  = kb3886bl_probe,
.remove = kb3886bl_remove,
-   .suspend= kb3886bl_suspend,
-   .resume = kb3886bl_resume,
.driver = {
.name   = "kb3886-bl",
+   .pm = _pm_ops,
},
 };
 
-- 
1.7.2.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 09/14] backlight: hp680_bl: convert hp680bl to dev_pm_ops

[Jingoo Han]

Instead of using legacy suspend/resume methods, using newer dev_pm_ops
structure allows better control over power management.

Signed-off-by: Jingoo Han 
---
 drivers/video/backlight/hp680_bl.c |   18 --
 1 files changed, 8 insertions(+), 10 deletions(-)

diff --git a/drivers/video/backlight/hp680_bl.c 
b/drivers/video/backlight/hp680_bl.c
index 5cefd73..00076ec 100644
--- a/drivers/video/backlight/hp680_bl.c
+++ b/drivers/video/backlight/hp680_bl.c
@@ -64,29 +64,28 @@ static void hp680bl_send_intensity(struct backlight_device 
*bd)
 }
 
 
-#ifdef CONFIG_PM
-static int hp680bl_suspend(struct platform_device *pdev, pm_message_t state)
+#ifdef CONFIG_PM_SLEEP
+static int hp680bl_suspend(struct device *dev)
 {
-   struct backlight_device *bd = platform_get_drvdata(pdev);
+   struct backlight_device *bd = dev_get_drvdata(dev);
 
hp680bl_suspended = 1;
hp680bl_send_intensity(bd);
return 0;
 }
 
-static int hp680bl_resume(struct platform_device *pdev)
+static int hp680bl_resume(struct device *dev)
 {
-   struct backlight_device *bd = platform_get_drvdata(pdev);
+   struct backlight_device *bd = dev_get_drvdata(dev);
 
hp680bl_suspended = 0;
hp680bl_send_intensity(bd);
return 0;
 }
-#else
-#define hp680bl_suspendNULL
-#define hp680bl_resume NULL
 #endif
 
+static SIMPLE_DEV_PM_OPS(hp680bl_pm_ops, hp680bl_suspend, hp680bl_resume);
+
 static int hp680bl_set_intensity(struct backlight_device *bd)
 {
hp680bl_send_intensity(bd);
@@ -140,10 +139,9 @@ static int hp680bl_remove(struct platform_device *pdev)
 static struct platform_driver hp680bl_driver = {
.probe  = hp680bl_probe,
.remove = hp680bl_remove,
-   .suspend= hp680bl_suspend,
-   .resume = hp680bl_resume,
.driver = {
.name   = "hp680-bl",
+   .pm = _pm_ops,
},
 };
 
-- 
1.7.2.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 08/14] backlight: ep93xx: convert ep93xx to dev_pm_ops

[Jingoo Han]

Instead of using legacy suspend/resume methods, using newer dev_pm_ops
structure allows better control over power management.

Signed-off-by: Jingoo Han 
---
 drivers/video/backlight/ep93xx_bl.c |   18 --
 1 files changed, 8 insertions(+), 10 deletions(-)

diff --git a/drivers/video/backlight/ep93xx_bl.c 
b/drivers/video/backlight/ep93xx_bl.c
index ef3e21e..734b7fe 100644
--- a/drivers/video/backlight/ep93xx_bl.c
+++ b/drivers/video/backlight/ep93xx_bl.c
@@ -115,35 +115,33 @@ static int ep93xxbl_remove(struct platform_device *dev)
return 0;
 }
 
-#ifdef CONFIG_PM
-static int ep93xxbl_suspend(struct platform_device *dev, pm_message_t state)
+#ifdef CONFIG_PM_SLEEP
+static int ep93xxbl_suspend(struct device *dev)
 {
-   struct backlight_device *bl = platform_get_drvdata(dev);
+   struct backlight_device *bl = dev_get_drvdata(dev);
 
return ep93xxbl_set(bl, 0);
 }
 
-static int ep93xxbl_resume(struct platform_device *dev)
+static int ep93xxbl_resume(struct device *dev)
 {
-   struct backlight_device *bl = platform_get_drvdata(dev);
+   struct backlight_device *bl = dev_get_drvdata(dev);
 
backlight_update_status(bl);
return 0;
 }
-#else
-#define ep93xxbl_suspend   NULL
-#define ep93xxbl_resumeNULL
 #endif
 
+static SIMPLE_DEV_PM_OPS(ep93xxbl_pm_ops, ep93xxbl_suspend, ep93xxbl_resume);
+
 static struct platform_driver ep93xxbl_driver = {
.driver = {
.name   = "ep93xx-bl",
.owner  = THIS_MODULE,
+   .pm = _pm_ops,
},
.probe  = ep93xxbl_probe,
.remove = ep93xxbl_remove,
-   .suspend= ep93xxbl_suspend,
-   .resume = ep93xxbl_resume,
 };
 
 module_platform_driver(ep93xxbl_driver);
-- 
1.7.2.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 07/14] backlight: corgi_lcd: convert corgi_lcd to dev_pm_ops

[Jingoo Han]

Instead of using legacy suspend/resume methods, using newer dev_pm_ops
structure allows better control over power management.

Signed-off-by: Jingoo Han 
---
 drivers/video/backlight/corgi_lcd.c |   18 --
 1 files changed, 8 insertions(+), 10 deletions(-)

diff --git a/drivers/video/backlight/corgi_lcd.c 
b/drivers/video/backlight/corgi_lcd.c
index aa782f3..c97867a 100644
--- a/drivers/video/backlight/corgi_lcd.c
+++ b/drivers/video/backlight/corgi_lcd.c
@@ -457,10 +457,10 @@ static const struct backlight_ops corgi_bl_ops = {
.update_status  = corgi_bl_update_status,
 };
 
-#ifdef CONFIG_PM
-static int corgi_lcd_suspend(struct spi_device *spi, pm_message_t state)
+#ifdef CONFIG_PM_SLEEP
+static int corgi_lcd_suspend(struct device *dev)
 {
-   struct corgi_lcd *lcd = spi_get_drvdata(spi);
+   struct corgi_lcd *lcd = dev_get_drvdata(dev);
 
corgibl_flags |= CORGIBL_SUSPENDED;
corgi_bl_set_intensity(lcd, 0);
@@ -468,20 +468,19 @@ static int corgi_lcd_suspend(struct spi_device *spi, 
pm_message_t state)
return 0;
 }
 
-static int corgi_lcd_resume(struct spi_device *spi)
+static int corgi_lcd_resume(struct device *dev)
 {
-   struct corgi_lcd *lcd = spi_get_drvdata(spi);
+   struct corgi_lcd *lcd = dev_get_drvdata(dev);
 
corgibl_flags &= ~CORGIBL_SUSPENDED;
corgi_lcd_set_power(lcd->lcd_dev, FB_BLANK_UNBLANK);
backlight_update_status(lcd->bl_dev);
return 0;
 }
-#else
-#define corgi_lcd_suspend  NULL
-#define corgi_lcd_resume   NULL
 #endif
 
+static SIMPLE_DEV_PM_OPS(corgi_lcd_pm_ops, corgi_lcd_suspend, 
corgi_lcd_resume);
+
 static int setup_gpio_backlight(struct corgi_lcd *lcd,
struct corgi_lcd_platform_data *pdata)
 {
@@ -611,11 +610,10 @@ static struct spi_driver corgi_lcd_driver = {
.driver = {
.name   = "corgi-lcd",
.owner  = THIS_MODULE,
+   .pm = _lcd_pm_ops,
},
.probe  = corgi_lcd_probe,
.remove = corgi_lcd_remove,
-   .suspend= corgi_lcd_suspend,
-   .resume = corgi_lcd_resume,
 };
 
 module_spi_driver(corgi_lcd_driver);
-- 
1.7.2.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 06/14] backlight: adp8870: convert adp8870 to dev_pm_ops

[Jingoo Han]

Instead of using legacy suspend/resume methods, using newer dev_pm_ops
structure allows better control over power management.

Signed-off-by: Jingoo Han 
---
 drivers/video/backlight/adp8870_bl.c |   21 -
 1 files changed, 12 insertions(+), 9 deletions(-)

diff --git a/drivers/video/backlight/adp8870_bl.c 
b/drivers/video/backlight/adp8870_bl.c
index 712c25a..b71c4a2 100644
--- a/drivers/video/backlight/adp8870_bl.c
+++ b/drivers/video/backlight/adp8870_bl.c
@@ -947,25 +947,29 @@ static int adp8870_remove(struct i2c_client *client)
return 0;
 }
 
-#ifdef CONFIG_PM
-static int adp8870_i2c_suspend(struct i2c_client *client, pm_message_t message)
+#ifdef CONFIG_PM_SLEEP
+static int adp8870_i2c_suspend(struct device *dev)
 {
+   struct i2c_client *client = to_i2c_client(dev);
+
adp8870_clr_bits(client, ADP8870_MDCR, NSTBY);
 
return 0;
 }
 
-static int adp8870_i2c_resume(struct i2c_client *client)
+static int adp8870_i2c_resume(struct device *dev)
 {
+   struct i2c_client *client = to_i2c_client(dev);
+
adp8870_set_bits(client, ADP8870_MDCR, NSTBY | BLEN);
 
return 0;
 }
-#else
-#define adp8870_i2c_suspend NULL
-#define adp8870_i2c_resume NULL
 #endif
 
+static SIMPLE_DEV_PM_OPS(adp8870_i2c_pm_ops, adp8870_i2c_suspend,
+   adp8870_i2c_resume);
+
 static const struct i2c_device_id adp8870_id[] = {
{ "adp8870", 0 },
{ }
@@ -974,12 +978,11 @@ MODULE_DEVICE_TABLE(i2c, adp8870_id);
 
 static struct i2c_driver adp8870_driver = {
.driver = {
-   .name = KBUILD_MODNAME,
+   .name   = KBUILD_MODNAME,
+   .pm = _i2c_pm_ops,
},
.probe= adp8870_probe,
.remove   = adp8870_remove,
-   .suspend = adp8870_i2c_suspend,
-   .resume  = adp8870_i2c_resume,
.id_table = adp8870_id,
 };
 
-- 
1.7.2.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 05/14] backlight: adp8860: convert adp8860 to dev_pm_ops

[Jingoo Han]

Instead of using legacy suspend/resume methods, using newer dev_pm_ops
structure allows better control over power management.

Signed-off-by: Jingoo Han 
---
 drivers/video/backlight/adp8860_bl.c |   21 -
 1 files changed, 12 insertions(+), 9 deletions(-)

diff --git a/drivers/video/backlight/adp8860_bl.c 
b/drivers/video/backlight/adp8860_bl.c
index a77c9ca..6bb7f36 100644
--- a/drivers/video/backlight/adp8860_bl.c
+++ b/drivers/video/backlight/adp8860_bl.c
@@ -773,25 +773,29 @@ static int adp8860_remove(struct i2c_client *client)
return 0;
 }
 
-#ifdef CONFIG_PM
-static int adp8860_i2c_suspend(struct i2c_client *client, pm_message_t message)
+#ifdef CONFIG_PM_SLEEP
+static int adp8860_i2c_suspend(struct device *dev)
 {
+   struct i2c_client *client = to_i2c_client(dev);
+
adp8860_clr_bits(client, ADP8860_MDCR, NSTBY);
 
return 0;
 }
 
-static int adp8860_i2c_resume(struct i2c_client *client)
+static int adp8860_i2c_resume(struct device *dev)
 {
+   struct i2c_client *client = to_i2c_client(dev);
+
adp8860_set_bits(client, ADP8860_MDCR, NSTBY | BLEN);
 
return 0;
 }
-#else
-#define adp8860_i2c_suspend NULL
-#define adp8860_i2c_resume NULL
 #endif
 
+static SIMPLE_DEV_PM_OPS(adp8860_i2c_pm_ops, adp8860_i2c_suspend,
+   adp8860_i2c_resume);
+
 static const struct i2c_device_id adp8860_id[] = {
{ "adp8860", adp8860 },
{ "adp8861", adp8861 },
@@ -802,12 +806,11 @@ MODULE_DEVICE_TABLE(i2c, adp8860_id);
 
 static struct i2c_driver adp8860_driver = {
.driver = {
-   .name = KBUILD_MODNAME,
+   .name   = KBUILD_MODNAME,
+   .pm = _i2c_pm_ops,
},
.probe= adp8860_probe,
.remove   = adp8860_remove,
-   .suspend = adp8860_i2c_suspend,
-   .resume  = adp8860_i2c_resume,
.id_table = adp8860_id,
 };
 
-- 
1.7.2.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 04/14] backlight: adp5520: convert adp5520_bl to dev_pm_ops

[Jingoo Han]

Instead of using legacy suspend/resume methods, using newer dev_pm_ops
structure allows better control over power management.

Signed-off-by: Jingoo Han 
---
 drivers/video/backlight/adp5520_bl.c |   21 ++---
 1 files changed, 10 insertions(+), 11 deletions(-)

diff --git a/drivers/video/backlight/adp5520_bl.c 
b/drivers/video/backlight/adp5520_bl.c
index a1e41d4..962d120 100644
--- a/drivers/video/backlight/adp5520_bl.c
+++ b/drivers/video/backlight/adp5520_bl.c
@@ -349,35 +349,34 @@ static int adp5520_bl_remove(struct platform_device *pdev)
return 0;
 }
 
-#ifdef CONFIG_PM
-static int adp5520_bl_suspend(struct platform_device *pdev,
-pm_message_t state)
+#ifdef CONFIG_PM_SLEEP
+static int adp5520_bl_suspend(struct device *dev)
 {
-   struct backlight_device *bl = platform_get_drvdata(pdev);
+   struct backlight_device *bl = dev_get_drvdata(dev);
+
return adp5520_bl_set(bl, 0);
 }
 
-static int adp5520_bl_resume(struct platform_device *pdev)
+static int adp5520_bl_resume(struct device *dev)
 {
-   struct backlight_device *bl = platform_get_drvdata(pdev);
+   struct backlight_device *bl = dev_get_drvdata(dev);
 
backlight_update_status(bl);
return 0;
 }
-#else
-#define adp5520_bl_suspend NULL
-#define adp5520_bl_resume  NULL
 #endif
 
+static SIMPLE_DEV_PM_OPS(adp5520_bl_pm_ops, adp5520_bl_suspend,
+   adp5520_bl_resume);
+
 static struct platform_driver adp5520_bl_driver = {
.driver = {
.name   = "adp5520-backlight",
.owner  = THIS_MODULE,
+   .pm = _bl_pm_ops,
},
.probe  = adp5520_bl_probe,
.remove = adp5520_bl_remove,
-   .suspend= adp5520_bl_suspend,
-   .resume = adp5520_bl_resume,
 };
 
 module_platform_driver(adp5520_bl_driver);
-- 
1.7.2.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 03/14] backlight: s6e63m0: convert s6e63m0 to dev_pm_ops

[Jingoo Han]

Instead of using legacy suspend/resume methods, using newer dev_pm_ops
structure allows better control over power management.

Signed-off-by: Jingoo Han 
---
 drivers/video/backlight/s6e63m0.c |   20 +---
 1 files changed, 9 insertions(+), 11 deletions(-)

diff --git a/drivers/video/backlight/s6e63m0.c 
b/drivers/video/backlight/s6e63m0.c
index 9c2677f..b37bb18 100644
--- a/drivers/video/backlight/s6e63m0.c
+++ b/drivers/video/backlight/s6e63m0.c
@@ -817,12 +817,12 @@ static int s6e63m0_remove(struct spi_device *spi)
return 0;
 }
 
-#if defined(CONFIG_PM)
-static int s6e63m0_suspend(struct spi_device *spi, pm_message_t mesg)
+#ifdef CONFIG_PM_SLEEP
+static int s6e63m0_suspend(struct device *dev)
 {
-   struct s6e63m0 *lcd = spi_get_drvdata(spi);
+   struct s6e63m0 *lcd = dev_get_drvdata(dev);
 
-   dev_dbg(>dev, "lcd->power = %d\n", lcd->power);
+   dev_dbg(dev, "lcd->power = %d\n", lcd->power);
 
/*
 * when lcd panel is suspend, lcd panel becomes off
@@ -831,19 +831,18 @@ static int s6e63m0_suspend(struct spi_device *spi, 
pm_message_t mesg)
return s6e63m0_power(lcd, FB_BLANK_POWERDOWN);
 }
 
-static int s6e63m0_resume(struct spi_device *spi)
+static int s6e63m0_resume(struct device *dev)
 {
-   struct s6e63m0 *lcd = spi_get_drvdata(spi);
+   struct s6e63m0 *lcd = dev_get_drvdata(dev);
 
lcd->power = FB_BLANK_POWERDOWN;
 
return s6e63m0_power(lcd, FB_BLANK_UNBLANK);
 }
-#else
-#define s6e63m0_suspendNULL
-#define s6e63m0_resume NULL
 #endif
 
+static SIMPLE_DEV_PM_OPS(s6e63m0_pm_ops, s6e63m0_suspend, s6e63m0_resume);
+
 /* Power down all displays on reboot, poweroff or halt. */
 static void s6e63m0_shutdown(struct spi_device *spi)
 {
@@ -856,12 +855,11 @@ static struct spi_driver s6e63m0_driver = {
.driver = {
.name   = "s6e63m0",
.owner  = THIS_MODULE,
+   .pm = _pm_ops,
},
.probe  = s6e63m0_probe,
.remove = s6e63m0_remove,
.shutdown   = s6e63m0_shutdown,
-   .suspend= s6e63m0_suspend,
-   .resume = s6e63m0_resume,
 };
 
 module_spi_driver(s6e63m0_driver);
-- 
1.7.2.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 02/14] backlight: lms501kf03: convert lms501kf03 to dev_pm_ops

[Jingoo Han]

Instead of using legacy suspend/resume methods, using newer dev_pm_ops
structure allows better control over power management.

Signed-off-by: Jingoo Han 
---
 drivers/video/backlight/lms501kf03.c |   22 ++
 1 files changed, 10 insertions(+), 12 deletions(-)

diff --git a/drivers/video/backlight/lms501kf03.c 
b/drivers/video/backlight/lms501kf03.c
index b43882a..cf01b9a 100644
--- a/drivers/video/backlight/lms501kf03.c
+++ b/drivers/video/backlight/lms501kf03.c
@@ -387,13 +387,12 @@ static int lms501kf03_remove(struct spi_device *spi)
return 0;
 }
 
-#if defined(CONFIG_PM)
-
-static int lms501kf03_suspend(struct spi_device *spi, pm_message_t mesg)
+#ifdef CONFIG_PM_SLEEP
+static int lms501kf03_suspend(struct device *dev)
 {
-   struct lms501kf03 *lcd = spi_get_drvdata(spi);
+   struct lms501kf03 *lcd = dev_get_drvdata(dev);
 
-   dev_dbg(>dev, "lcd->power = %d\n", lcd->power);
+   dev_dbg(dev, "lcd->power = %d\n", lcd->power);
 
/*
 * when lcd panel is suspend, lcd panel becomes off
@@ -402,19 +401,19 @@ static int lms501kf03_suspend(struct spi_device *spi, 
pm_message_t mesg)
return lms501kf03_power(lcd, FB_BLANK_POWERDOWN);
 }
 
-static int lms501kf03_resume(struct spi_device *spi)
+static int lms501kf03_resume(struct device *dev)
 {
-   struct lms501kf03 *lcd = spi_get_drvdata(spi);
+   struct lms501kf03 *lcd = dev_get_drvdata(dev);
 
lcd->power = FB_BLANK_POWERDOWN;
 
return lms501kf03_power(lcd, FB_BLANK_UNBLANK);
 }
-#else
-#define lms501kf03_suspend NULL
-#define lms501kf03_resume  NULL
 #endif
 
+static SIMPLE_DEV_PM_OPS(lms501kf03_pm_ops, lms501kf03_suspend,
+   lms501kf03_resume);
+
 static void lms501kf03_shutdown(struct spi_device *spi)
 {
struct lms501kf03 *lcd = spi_get_drvdata(spi);
@@ -426,12 +425,11 @@ static struct spi_driver lms501kf03_driver = {
.driver = {
.name   = "lms501kf03",
.owner  = THIS_MODULE,
+   .pm = _pm_ops,
},
.probe  = lms501kf03_probe,
.remove = lms501kf03_remove,
.shutdown   = lms501kf03_shutdown,
-   .suspend= lms501kf03_suspend,
-   .resume = lms501kf03_resume,
 };
 
 module_spi_driver(lms501kf03_driver);
-- 
1.7.2.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 01/14] backlight: ld9040: convert ld9040 to dev_pm_ops

[Jingoo Han]

Instead of using legacy suspend/resume methods, using newer dev_pm_ops
structure allows better control over power management.

Signed-off-by: Jingoo Han 
---
 drivers/video/backlight/ld9040.c |   20 +---
 1 files changed, 9 insertions(+), 11 deletions(-)

diff --git a/drivers/video/backlight/ld9040.c b/drivers/video/backlight/ld9040.c
index 1b642f5f..1e0a309 100644
--- a/drivers/video/backlight/ld9040.c
+++ b/drivers/video/backlight/ld9040.c
@@ -775,12 +775,12 @@ static int ld9040_remove(struct spi_device *spi)
return 0;
 }
 
-#if defined(CONFIG_PM)
-static int ld9040_suspend(struct spi_device *spi, pm_message_t mesg)
+#ifdef CONFIG_PM_SLEEP
+static int ld9040_suspend(struct device *dev)
 {
-   struct ld9040 *lcd = spi_get_drvdata(spi);
+   struct ld9040 *lcd = dev_get_drvdata(dev);
 
-   dev_dbg(>dev, "lcd->power = %d\n", lcd->power);
+   dev_dbg(dev, "lcd->power = %d\n", lcd->power);
 
/*
 * when lcd panel is suspend, lcd panel becomes off
@@ -789,19 +789,18 @@ static int ld9040_suspend(struct spi_device *spi, 
pm_message_t mesg)
return ld9040_power(lcd, FB_BLANK_POWERDOWN);
 }
 
-static int ld9040_resume(struct spi_device *spi)
+static int ld9040_resume(struct device *dev)
 {
-   struct ld9040 *lcd = spi_get_drvdata(spi);
+   struct ld9040 *lcd = dev_get_drvdata(dev);
 
lcd->power = FB_BLANK_POWERDOWN;
 
return ld9040_power(lcd, FB_BLANK_UNBLANK);
 }
-#else
-#define ld9040_suspend NULL
-#define ld9040_resume  NULL
 #endif
 
+static SIMPLE_DEV_PM_OPS(ld9040_pm_ops, ld9040_suspend, ld9040_resume);
+
 /* Power down all displays on reboot, poweroff or halt. */
 static void ld9040_shutdown(struct spi_device *spi)
 {
@@ -814,12 +813,11 @@ static struct spi_driver ld9040_driver = {
.driver = {
.name   = "ld9040",
.owner  = THIS_MODULE,
+   .pm = _pm_ops,
},
.probe  = ld9040_probe,
.remove = ld9040_remove,
.shutdown   = ld9040_shutdown,
-   .suspend= ld9040_suspend,
-   .resume = ld9040_resume,
 };
 
 module_spi_driver(ld9040_driver);
-- 
1.7.2.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] backlight: da903x_bl: switch to using SIMPLE_DEV_PM_OPS

[Jingoo Han]

This reduces #ifdefs in the code. Also, CONFIG_PM_SLEEP is used
to avoid warnings of unused functions if CONFIG_PM_SLEEP is not
defined.

Signed-off-by: Jingoo Han 
---
 drivers/video/backlight/da903x_bl.c |   12 
 1 files changed, 4 insertions(+), 8 deletions(-)

diff --git a/drivers/video/backlight/da903x_bl.c 
b/drivers/video/backlight/da903x_bl.c
index 8179cef..c625f6d 100644
--- a/drivers/video/backlight/da903x_bl.c
+++ b/drivers/video/backlight/da903x_bl.c
@@ -161,7 +161,7 @@ static int da903x_backlight_remove(struct platform_device 
*pdev)
return 0;
 }
 
-#ifdef CONFIG_PM
+#ifdef CONFIG_PM_SLEEP
 static int da903x_backlight_suspend(struct device *dev)
 {
struct backlight_device *bl = dev_get_drvdata(dev);
@@ -176,20 +176,16 @@ static int da903x_backlight_resume(struct device *dev)
backlight_update_status(bl);
return 0;
 }
-
-static const struct dev_pm_ops da903x_backlight_pm_ops = {
-   .suspend= da903x_backlight_suspend,
-   .resume = da903x_backlight_resume,
-};
 #endif
 
+static SIMPLE_DEV_PM_OPS(da903x_backlight_pm_ops, da903x_backlight_suspend,
+   da903x_backlight_resume);
+
 static struct platform_driver da903x_backlight_driver = {
.driver = {
.name   = "da903x-backlight",
.owner  = THIS_MODULE,
-#ifdef CONFIG_PM
.pm = _backlight_pm_ops,
-#endif
},
.probe  = da903x_backlight_probe,
.remove = da903x_backlight_remove,
-- 
1.7.2.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] rtc: rtc-s3c: convert s3c_rtc to dev_pm_ops

[Jingoo Han]

Instead of using legacy suspend/resume methods, using newer
dev_pm_ops structure allows better control over power management.
Also, 'wake_en' variable is moved, because it is only used when
CONFIG_PM_SLEEP is enabled.

Signed-off-by: Jingoo Han 
---
 drivers/rtc/rtc-s3c.c |   26 +-
 1 files changed, 13 insertions(+), 13 deletions(-)

diff --git a/drivers/rtc/rtc-s3c.c b/drivers/rtc/rtc-s3c.c
index fb994e9..c863a93 100644
--- a/drivers/rtc/rtc-s3c.c
+++ b/drivers/rtc/rtc-s3c.c
@@ -51,7 +51,6 @@ static struct clk *rtc_clk;
 static void __iomem *s3c_rtc_base;
 static int s3c_rtc_alarmno = NO_IRQ;
 static int s3c_rtc_tickno  = NO_IRQ;
-static bool wake_en;
 static enum s3c_cpu_type s3c_rtc_cpu_type;
 
 static DEFINE_SPINLOCK(s3c_rtc_pie_lock);
@@ -583,14 +582,16 @@ static int s3c_rtc_probe(struct platform_device *pdev)
return ret;
 }
 
-#ifdef CONFIG_PM
-
+#ifdef CONFIG_PM_SLEEP
 /* RTC Power management control */
 
 static int ticnt_save, ticnt_en_save;
+static bool wake_en;
 
-static int s3c_rtc_suspend(struct platform_device *pdev, pm_message_t state)
+static int s3c_rtc_suspend(struct device *dev)
 {
+   struct platform_device *pdev = to_platform_device(dev);
+
clk_enable(rtc_clk);
/* save TICNT for anyone using periodic interrupts */
ticnt_save = readb(s3c_rtc_base + S3C2410_TICNT);
@@ -600,19 +601,20 @@ static int s3c_rtc_suspend(struct platform_device *pdev, 
pm_message_t state)
}
s3c_rtc_enable(pdev, 0);
 
-   if (device_may_wakeup(>dev) && !wake_en) {
+   if (device_may_wakeup(dev) && !wake_en) {
if (enable_irq_wake(s3c_rtc_alarmno) == 0)
wake_en = true;
else
-   dev_err(>dev, "enable_irq_wake failed\n");
+   dev_err(dev, "enable_irq_wake failed\n");
}
clk_disable(rtc_clk);
 
return 0;
 }
 
-static int s3c_rtc_resume(struct platform_device *pdev)
+static int s3c_rtc_resume(struct device *dev)
 {
+   struct platform_device *pdev = to_platform_device(dev);
unsigned int tmp;
 
clk_enable(rtc_clk);
@@ -623,7 +625,7 @@ static int s3c_rtc_resume(struct platform_device *pdev)
writew(tmp | ticnt_en_save, s3c_rtc_base + S3C2410_RTCCON);
}
 
-   if (device_may_wakeup(>dev) && wake_en) {
+   if (device_may_wakeup(dev) && wake_en) {
disable_irq_wake(s3c_rtc_alarmno);
wake_en = false;
}
@@ -631,11 +633,10 @@ static int s3c_rtc_resume(struct platform_device *pdev)
 
return 0;
 }
-#else
-#define s3c_rtc_suspend NULL
-#define s3c_rtc_resume  NULL
 #endif
 
+static SIMPLE_DEV_PM_OPS(s3c_rtc_pm_ops, s3c_rtc_suspend, s3c_rtc_resume);
+
 #ifdef CONFIG_OF
 static struct s3c_rtc_drv_data s3c_rtc_drv_data_array[] = {
[TYPE_S3C2410] = { TYPE_S3C2410 },
@@ -685,12 +686,11 @@ MODULE_DEVICE_TABLE(platform, s3c_rtc_driver_ids);
 static struct platform_driver s3c_rtc_driver = {
.probe  = s3c_rtc_probe,
.remove = s3c_rtc_remove,
-   .suspend= s3c_rtc_suspend,
-   .resume = s3c_rtc_resume,
.id_table   = s3c_rtc_driver_ids,
.driver = {
.name   = "s3c-rtc",
.owner  = THIS_MODULE,
+   .pm = _rtc_pm_ops,
.of_match_table = of_match_ptr(s3c_rtc_dt_match),
},
 };
-- 
1.7.2.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: linux-next: build failure after merge of the final tree (drm-intel tree related)

[Kees Cook]

On Mon, Mar 11, 2013 at 9:22 PM, Stephen Rothwell  wrote:
> Hi all,
>
> After merging the final tree, today's linux-next build (i386 defconfig)
> failed like this:
>
> drivers/built-in.o: In function `i915_min_freq_set':
> i915_debugfs.c:(.text+0xb1adc): undefined reference to `__udivdi3'
> drivers/built-in.o: In function `i915_max_freq_set':
> i915_debugfs.c:(.text+0xb1bac): undefined reference to `__udivdi3'
>
> Caused by commit 2389cc500686 ("drm/i915: use simple attribute in debugfs
> routines") from the drm-intel tree.
>
> I have reverted that commit for today.

Ah-ha, thanks. I've sent a follow-up patch to fix this.

-Kees

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

[PATCH] drm/i915: use do_div() as needed in debugfs code

[Kees Cook]

This replaces the open-coded divisions in the debugfs code by calls
to do_div().

Signed-off-by: Kees Cook 
Cc: Daniel Vetter 
---
 drivers/gpu/drm/i915/i915_debugfs.c |   12 ++--
 1 file changed, 6 insertions(+), 6 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_debugfs.c 
b/drivers/gpu/drm/i915/i915_debugfs.c
index d86c304..6f3cbf8 100644
--- a/drivers/gpu/drm/i915/i915_debugfs.c
+++ b/drivers/gpu/drm/i915/i915_debugfs.c
@@ -1814,9 +1814,9 @@ i915_max_freq_set(void *data, u64 val)
/*
 * Turbo will still be enabled, but won't go above the set value.
 */
-   dev_priv->rps.max_delay = val / GT_FREQUENCY_MULTIPLIER;
-
-   gen6_set_rps(dev, val / GT_FREQUENCY_MULTIPLIER);
+   do_div(val, GT_FREQUENCY_MULTIPLIER);
+   dev_priv->rps.max_delay = val;
+   gen6_set_rps(dev, val);
mutex_unlock(_priv->rps.hw_lock);
 
return 0;
@@ -1865,9 +1865,9 @@ i915_min_freq_set(void *data, u64 val)
/*
 * Turbo will still be enabled, but won't go below the set value.
 */
-   dev_priv->rps.min_delay = val / GT_FREQUENCY_MULTIPLIER;
-
-   gen6_set_rps(dev, val / GT_FREQUENCY_MULTIPLIER);
+   do_div(val, GT_FREQUENCY_MULTIPLIER);
+   dev_priv->rps.min_delay = val;
+   gen6_set_rps(dev, val);
mutex_unlock(_priv->rps.hw_lock);
 
return 0;
-- 
1.7.9.5


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

Re: linux-next: build warning after merge of the final tree (tip tree related)

[Stephen Rothwell]

Hi,

On Tue, 12 Mar 2013 13:16:21 +0800 Li Zefan  wrote:
>
> Should be fixed by this, and it has been queued in tip:sched/core
> 
> Commit-ID:  b719203b846284e77f5c50fca04b458b6484aeae
> Gitweb: http://git.kernel.org/tip/b719203b846284e77f5c50fca04b458b6484aeae
> Author: Li Zefan 
> AuthorDate: Thu, 7 Mar 2013 10:00:26 +0800
> Committer:  Ingo Molnar 
> CommitDate: Mon, 11 Mar 2013 09:07:24 +0100
> 
> sched: Fix update_group_power() prototype placement to fix build warning when 
> !CONFIG_SMP

Good, thanks.

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


pgpxqRaSnlg47.pgp
Description: PGP signature

[PATCH] hwrng: exynos - add CONFIG_PM_SLEEP to suspend/resume functions

[Jingoo Han]

This patch adds CONFIG_PM_SLEEP to suspend/resume functions to fix
the following build warning when CONFIG_PM_SLEEP is not selected.

drivers/char/hw_random/exynos-rng.c:147:12: warning: 
'exynos_rng_runtime_suspend' defined but not used [-Wunused-function]
drivers/char/hw_random/exynos-rng.c:157:12: warning: 
'exynos_rng_runtime_resume' defined but not used [-Wunused-function]

Signed-off-by: Jingoo Han 
---
 drivers/char/hw_random/exynos-rng.c |3 ++-
 1 files changed, 2 insertions(+), 1 deletions(-)

diff --git a/drivers/char/hw_random/exynos-rng.c 
b/drivers/char/hw_random/exynos-rng.c
index ac47631..b7e48a2 100644
--- a/drivers/char/hw_random/exynos-rng.c
+++ b/drivers/char/hw_random/exynos-rng.c
@@ -144,6 +144,7 @@ static int exynos_rng_remove(struct platform_device *pdev)
return 0;
 }
 
+#ifdef CONFIG_PM_SLEEP
 static int exynos_rng_runtime_suspend(struct device *dev)
 {
struct platform_device *pdev = to_platform_device(dev);
@@ -161,7 +162,7 @@ static int exynos_rng_runtime_resume(struct device *dev)
 
return clk_prepare_enable(exynos_rng->clk);
 }
-
+#endif
 
 static UNIVERSAL_DEV_PM_OPS(exynos_rng_pm_ops, exynos_rng_runtime_suspend,
exynos_rng_runtime_resume, NULL);
-- 
1.7.2.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] CIFS: fix module loading regression

[Cristian Rodríguez]

Since commit:

7f78e0351394052e1a6293e175825eb5c7869507
fs: Limit sys_mount to only request filesystem modules.

cifs module no longer loads when issuing the mount command
due to the lack of a MODULE_ALIAS_FS.

Signed-off-by: Cristian Rodríguez 
---
 fs/cifs/cifsfs.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/fs/cifs/cifsfs.c b/fs/cifs/cifsfs.c
index 1a052c0..81ebb98 100644
--- a/fs/cifs/cifsfs.c
+++ b/fs/cifs/cifsfs.c
@@ -777,6 +777,8 @@ struct file_system_type cifs_fs_type = {
.kill_sb = cifs_kill_sb,
/*  .fs_flags */
 };
+MODULE_ALIAS_FS("cifs");
+
 const struct inode_operations cifs_dir_inode_ops = {
.create = cifs_create,
.atomic_open = cifs_atomic_open,
-- 
1.8.1.4

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

[PATCH 18/18] net: sctp: remove cast for kmalloc/kzalloc return value

[Zhang Yanfei]

remove cast for kmalloc/kzalloc return value.

Signed-off-by: Zhang Yanfei 
Cc: Vlad Yasevich 
Cc: Sridhar Samudrala 
Cc: Neil Horman 
Cc: Andrew Morton 
Cc: linux-s...@vger.kernel.org
---
 include/net/sctp/sctp.h |2 +-
 net/sctp/protocol.c |2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/include/net/sctp/sctp.h b/include/net/sctp/sctp.h
index df85a0c..cd89510 100644
--- a/include/net/sctp/sctp.h
+++ b/include/net/sctp/sctp.h
@@ -576,7 +576,7 @@ for (pos = chunk->subh.fwdtsn_hdr->skip;\
 #define WORD_ROUND(s) (((s)+3)&~3)
 
 /* Make a new instance of type.  */
-#define t_new(type, flags) (type *)kzalloc(sizeof(type), flags)
+#define t_new(type, flags) kzalloc(sizeof(type), flags)
 
 /* Compare two timevals.  */
 #define tv_lt(s, t) \
diff --git a/net/sctp/protocol.c b/net/sctp/protocol.c
index 1c2e46c..eaee00c 100644
--- a/net/sctp/protocol.c
+++ b/net/sctp/protocol.c
@@ -1403,7 +1403,7 @@ SCTP_STATIC __init int sctp_init(void)
 
/* Allocate and initialize the endpoint hash table.  */
sctp_ep_hashsize = 64;
-   sctp_ep_hashtable = (struct sctp_hashbucket *)
+   sctp_ep_hashtable =
kmalloc(64 * sizeof(struct sctp_hashbucket), GFP_KERNEL);
if (!sctp_ep_hashtable) {
pr_err("Failed endpoint_hash alloc\n");
-- 
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/

Re: workqueue panic in 3.4 kernel

[Tejun Heo]

On Tue, Mar 12, 2013 at 01:34:56PM +0800, Lei Wen wrote:
> > Memory areas aren't always zero on allocation.
> 
> Shouldn't work structure be allocated with kzalloc?

It's not required to. work_struct can also be on stack. It's "init"
after all. Also, if you require clearing the memory before initing,
you would be just shifting problem from INIT to memory clearing.

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

[PATCH 1/1] drivers/gpio: Altera soft IP GPIO driver

[thloh]

From: Tien Hock Loh 

Adds a new driver for Altera soft GPIO IP. The driver is able to
do read/write and allows GPIO to be a interrupt controller.

Tested on Altera GHRD on interrupt handling and IO.

Signed-off-by: Tien Hock Loh 
---
 .../devicetree/bindings/gpio/gpio-altera.txt   |  37 +++
 drivers/gpio/Kconfig   |   7 +
 drivers/gpio/Makefile  |   1 +
 drivers/gpio/gpio-altera.c | 363 +
 4 files changed, 408 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/gpio/gpio-altera.txt
 create mode 100644 drivers/gpio/gpio-altera.c

diff --git a/Documentation/devicetree/bindings/gpio/gpio-altera.txt 
b/Documentation/devicetree/bindings/gpio/gpio-altera.txt
new file mode 100644
index 000..3bdb8b6
--- /dev/null
+++ b/Documentation/devicetree/bindings/gpio/gpio-altera.txt
@@ -0,0 +1,37 @@
+Altera GPIO controller bindings
+
+Required properties:
+- compatible:
+  - "altr,pio-1.0"
+- reg: Physical base address and length of the controller's registers.
+- #gpio-cells : Should be two.
+  - first cell is the pin number
+  - second cell is used to specify optional parameters (unused)
+- gpio-controller : Marks the device node as a GPIO controller.
+- #interrupt-cells : Should be 1.
+- interrupts: Specify the interrupt.
+- interrupt-controller: Mark the device node as an interrupt controller
+  The first cell is the GPIO number.
+
+Altera GPIO specific properties:
+- width: Width of the GPIO bank, range from 1-32
+- level_trigger: Specifies whether the GPIO interrupt is level trigger.
+  This field is required if the Altera GPIO controller used has IRQ enabled.
+
+Note: If the Altera GPIO is set to be built as a module, peripherals that uses
+Altera GPIO as interrupt-parent should be a module so that the peripheral
+doesn't get initialized before Altera GPIO is initialized.
+
+Example:
+
+gpio_altr: gpio_altr {
+compatible = "altr,pio-1.0";
+reg = <0xff20 0x10>;
+interrupts = <0 45 4>;
+width = <32>;
+level_trigger = <0>;
+#gpio-cells = <2>;
+gpio-controller;
+#interrupt-cells = <1>;
+interrupt-controller;
+};
diff --git a/drivers/gpio/Kconfig b/drivers/gpio/Kconfig
index 93aaadf..953e9f2 100644
--- a/drivers/gpio/Kconfig
+++ b/drivers/gpio/Kconfig
@@ -119,6 +119,13 @@ config GPIO_GENERIC_PLATFORM
help
  Say yes here to support basic platform_device memory-mapped GPIO 
controllers.
 
+config GPIO_ALTERA
+   tristate "Altera GPIO"
+   select IRQ_DOMAIN
+   depends on OF_GPIO
+   help
+ Say yes here to support the Altera PIO device.
+
 config GPIO_IT8761E
tristate "IT8761E GPIO support"
depends on X86  # unconditional access to IO space.
diff --git a/drivers/gpio/Makefile b/drivers/gpio/Makefile
index 22e07bc..c57449c 100644
--- a/drivers/gpio/Makefile
+++ b/drivers/gpio/Makefile
@@ -14,6 +14,7 @@ obj-$(CONFIG_GPIO_74X164) += gpio-74x164.o
 obj-$(CONFIG_GPIO_ADNP)+= gpio-adnp.o
 obj-$(CONFIG_GPIO_ADP5520) += gpio-adp5520.o
 obj-$(CONFIG_GPIO_ADP5588) += gpio-adp5588.o
+obj-$(CONFIG_GPIO_ALTERA)  += gpio-altera.o
 obj-$(CONFIG_GPIO_AMD8111) += gpio-amd8111.o
 obj-$(CONFIG_GPIO_ARIZONA) += gpio-arizona.o
 obj-$(CONFIG_GPIO_BT8XX)   += gpio-bt8xx.o
diff --git a/drivers/gpio/gpio-altera.c b/drivers/gpio/gpio-altera.c
new file mode 100644
index 000..b832a3a
--- /dev/null
+++ b/drivers/gpio/gpio-altera.c
@@ -0,0 +1,363 @@
+/*
+ * Copyright (C) 2013 Altera Corporation
+ * Based on gpio-mpc8xxx.c
+ *
+ * This program is free software: you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation, either version 3 of the License, or
+ * (at your option) any later version.
+ *
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program.  If not, see 
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#define ALTERA_GPIO_DATA   0x0
+#define ALTERA_GPIO_DIR0x4
+#define ALTERA_GPIO_IRQ_MASK   0x8
+#define ALTERA_GPIO_EDGE_CAP   0xc
+#define ALTERA_GPIO_OUTSET 0x10
+#define ALTERA_GPIO_OUTCLEAR   0x14
+
+struct altera_gpio_chip {
+   struct of_mm_gpio_chip mmchip;
+   struct irq_domain *irq; /* GPIO controller IRQ number */
+   spinlock_t gpio_lock;   /* Lock used for synchronization */
+   int level_trigger;
+   int hwirq;
+};
+
+static void altera_gpio_irq_unmask(struct irq_data *d)
+{
+   struct 

[PATCH 17/18] fs: ufs: remove cast for kmalloc return value

[Zhang Yanfei]

remove cast for kmalloc return value.

Signed-off-by: Zhang Yanfei 
Cc: Evgeniy Dushistov 
Cc: Andrew Morton 
---
 fs/ufs/util.c |3 +--
 1 files changed, 1 insertions(+), 2 deletions(-)

diff --git a/fs/ufs/util.c b/fs/ufs/util.c
index 95425b5..b6c2f94 100644
--- a/fs/ufs/util.c
+++ b/fs/ufs/util.c
@@ -26,8 +26,7 @@ struct ufs_buffer_head * _ubh_bread_ (struct 
ufs_sb_private_info * uspi,
count = size >> uspi->s_fshift;
if (count > UFS_MAXFRAG)
return NULL;
-   ubh = (struct ufs_buffer_head *)
-   kmalloc (sizeof (struct ufs_buffer_head), GFP_NOFS);
+   ubh = kmalloc (sizeof (struct ufs_buffer_head), GFP_NOFS);
if (!ubh)
return NULL;
ubh->fragment = fragment;
-- 
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 16/18] fs: befs: remove cast for kmalloc return value

[Zhang Yanfei]

remove cast for kmalloc return value.

Signed-off-by: Zhang Yanfei 
Cc: Andrew Morton 
---
 fs/befs/btree.c |3 +--
 1 files changed, 1 insertions(+), 2 deletions(-)

diff --git a/fs/befs/btree.c b/fs/befs/btree.c
index a66c9b1..74e397d 100644
--- a/fs/befs/btree.c
+++ b/fs/befs/btree.c
@@ -436,8 +436,7 @@ befs_btree_read(struct super_block *sb, befs_data_stream * 
ds,
goto error;
}
 
-   if ((this_node = (befs_btree_node *)
-kmalloc(sizeof (befs_btree_node), GFP_NOFS)) == NULL) {
+   if ((this_node = kmalloc(sizeof (befs_btree_node), GFP_NOFS)) == NULL) {
befs_error(sb, "befs_btree_read() failed to allocate %u "
   "bytes of memory", sizeof (befs_btree_node));
goto error;
-- 
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 15/18] driver: usb: storage: remove cast for kmalloc return value

[Zhang Yanfei]

remove cast for kmalloc return value.

Signed-off-by: Zhang Yanfei 
Cc: Matthew Dharm 
Cc: Greg Kroah-Hartman 
Cc: Andrew Morton 
Cc: linux-...@vger.kernel.org
Cc: usb-stor...@lists.one-eyed-alien.net
---
 drivers/usb/storage/isd200.c |3 +--
 1 files changed, 1 insertions(+), 2 deletions(-)

diff --git a/drivers/usb/storage/isd200.c b/drivers/usb/storage/isd200.c
index ecea478..06a3d22 100644
--- a/drivers/usb/storage/isd200.c
+++ b/drivers/usb/storage/isd200.c
@@ -1457,8 +1457,7 @@ static int isd200_init_info(struct us_data *us)
retStatus = ISD200_ERROR;
else {
info->id = kzalloc(ATA_ID_WORDS * 2, GFP_KERNEL);
-   info->RegsBuf = (unsigned char *)
-   kmalloc(sizeof(info->ATARegs), GFP_KERNEL);
+   info->RegsBuf = kmalloc(sizeof(info->ATARegs), GFP_KERNEL);
info->srb.sense_buffer =
kmalloc(SCSI_SENSE_BUFFERSIZE, GFP_KERNEL);
if (!info->id || !info->RegsBuf || !info->srb.sense_buffer) {
-- 
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/

Re: workqueue panic in 3.4 kernel

[Lei Wen]

On Tue, Mar 12, 2013 at 1:24 PM, Tejun Heo  wrote:
> On Tue, Mar 12, 2013 at 01:18:01PM +0800, Lei Wen wrote:
>> > You're initializing random piece of memory which may contain any
>> > garbage and triggering BUG if some bit is set on it. No, you can't do
>> > that. debugobj is the right tool for debugging object lifetime issues
>> > and is already supported.
>>
>> The debugobj is not helping on this issue, I have enabled both
>> CONFIG_DEBUG_OBJECTS_WORK and CONFIG_DEBUG_OBJECTS.
>> But find they didn't report any issue at all.
>
> It should. No idea why it didn't. Would be interesting to find out
> why.

No idea about it also...

>
>> And I am not init random memory, original issue is call init multi-times
>> for one structure and that piece of memory already been allocated.
>> And __INIT_WORK shouldn't call over random memory, right?
>
> Memory areas aren't always zero on allocation.


Shouldn't work structure be allocated with kzalloc?

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

powerpc/eeh: Fix compile error due to missing include file

[Michael Neuling]

Ben Hutchings  wrote:

> On Fri, 2013-03-08 at 13:51 +1100, Michael Neuling wrote:
> > This patch is breaking the celleb_defconfig on powerpc with:
> > 
> > arch/powerpc/kernel/of_platform.c: In function 'of_pci_phb_probe':
> > arch/powerpc/kernel/of_platform.c:95:2: error: implicit declaration of
> > function 'eeh_add_sysfs_files' [-Werror=implicit-function-declaration]
> 
> In 3.2 this file doesn't (directly) include  which is where
> the definition was added.  In mainline it does.
> 
> Assuming that this change is actually required for 3.2 (which I'm not
> sure about), I suppose we just need to add the #include.

Yep that fixes it.  Patch below (for stable 3.2 only)


From: Michael Neuling 
Subject: powerpc/eeh: Fix compile error due to missing include file

3.2.40 fails to compile the celleb_defconfig with the following error:

  arch/powerpc/kernel/of_platform.c: In function 'of_pci_phb_probe':
  arch/powerpc/kernel/of_platform.c:95:2: error: implicit declaration of 
function 'eeh_add_sysfs_files' [-Werror=implicit-function-declaration]

The following adds the required include file to fix this.

Signed-off-by: Michael Neuling 

diff --git a/arch/powerpc/kernel/of_platform.c 
b/arch/powerpc/kernel/of_platform.c
index b10beef..601650f 100644
--- a/arch/powerpc/kernel/of_platform.c
+++ b/arch/powerpc/kernel/of_platform.c
@@ -26,6 +26,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 
 #ifdef CONFIG_PPC_OF_PLATFORM_PCI
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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 14/18] driver: tty: vt: remove cast for kmalloc return value

[Zhang Yanfei]

remove cast for kmalloc return value.

Signed-off-by: Zhang Yanfei 
Cc: Greg Kroah-Hartman 
Cc: Jiri Slaby 
Cc: Andrew Morton 
---
 drivers/tty/vt/consolemap.c |3 +--
 1 files changed, 1 insertions(+), 2 deletions(-)

diff --git a/drivers/tty/vt/consolemap.c b/drivers/tty/vt/consolemap.c
index 248381b..2978ca5 100644
--- a/drivers/tty/vt/consolemap.c
+++ b/drivers/tty/vt/consolemap.c
@@ -194,8 +194,7 @@ static void set_inverse_transl(struct vc_data *conp, struct 
uni_pagedir *p, int
q = p->inverse_translations[i];
 
if (!q) {
-   q = p->inverse_translations[i] = (unsigned char *) 
-   kmalloc(MAX_GLYPH, GFP_KERNEL);
+   q = p->inverse_translations[i] = kmalloc(MAX_GLYPH, GFP_KERNEL);
if (!q) return;
}
memset(q, 0, MAX_GLYPH);
-- 
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/

Re: [PATCH 4/6 v5] arm highbank: add support for pl320 IPC

[liuhuan123]

Hermes replica totes are actually ambrosial in accretion to about apprenticed
that you acquire complete admiring for those who acquire 1. Irrespective of
your breadth activity to, accepting a afflicted by  hermes belt kit women
  , you
should not all-overs any bootless affliction. Every abandoned afflicted will
be anxiously bogus to accomplish it abide best than it's competitors on the
market. This can be a haversack an abandoned broker by appliance delight. If
you're a sweetheart with out them these these reproductions, that you are
accepting larboard aback with the assets of Hermes. There're below than this
18-carat ones and the identical axial development. Hermes won't discriminate
rolling about in its carriers.



--
View this message in context: 
http://linux-kernel.2935.n7.nabble.com/PATCH-0-6-cpufreq-add-support-for-Calxeda-ECX-1000-highbank-tp380026p614406.html
Sent from the Linux Kernel mailing list archive at Nabble.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 13/18] driver: tty: serial: remove cast for kzalloc return value

[Zhang Yanfei]

remove cast for kzalloc return value.

Signed-off-by: Zhang Yanfei 
Cc: Greg Kroah-Hartman 
Cc: Jiri Slaby 
Cc: Andrew Morton 
Cc: linux-ser...@vger.kernel.org
---
 drivers/tty/serial/icom.c |3 +--
 1 files changed, 1 insertions(+), 2 deletions(-)

diff --git a/drivers/tty/serial/icom.c b/drivers/tty/serial/icom.c
index bc9e6b0..18ed5ae 100644
--- a/drivers/tty/serial/icom.c
+++ b/drivers/tty/serial/icom.c
@@ -1415,8 +1415,7 @@ static int icom_alloc_adapter(struct icom_adapter
struct icom_adapter *cur_adapter_entry;
struct list_head *tmp;
 
-   icom_adapter = (struct icom_adapter *)
-   kzalloc(sizeof(struct icom_adapter), GFP_KERNEL);
+   icom_adapter = kzalloc(sizeof(struct icom_adapter), GFP_KERNEL);
 
if (!icom_adapter) {
return -ENOMEM;
-- 
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/

Re: [PATCH] gpio: Renesas R-Car GPIO driver

[Magnus Damm]

HI Laurent,

On Sun, Mar 10, 2013 at 3:16 AM, Laurent Pinchart
 wrote:
> Hi Magnus,
>
> Thank you for the patch.

Thanks for your review!

> On Tuesday 05 March 2013 09:32:19 Magnus Damm wrote:
>> From: Magnus Damm 
>>
>> This patch implements a GPIO driver for the R-Car series
>> of SoCs from Renesas. This driver is designed to be reusable
>> between multiple SoCs that share the same basic building block,
>> but so far it has only been used on R-Car H1 (r8a7779).
>>
>> Each driver instance handles 32 GPIOs with individually
>> maskable IRQs. The driver operates on a single I/O memory
>> range and the 32 GPIOs are hooked up a single interrupt.
>>
>> In the case of R-Car H1 either external IRQ pins or GPIOs
>> with interrupts can be used for on-board interupts. For
>> external IRQs 4 pins are supported, and in the case of GPIO
>> there are 202 GPIOS as 202 interrupts hooked up via 6 driver
>> instances and to the GIC and the Cortex-A9 Quad.
>>
>> At this point this driver is interfacing as a regular
>> platform device driver. In the future DT support will be
>> submitted as an incremental feature patch.
>>
>> Signed-off-by: Magnus Damm 
>> ---
>>
>>  drivers/gpio/Kconfig|6
>>  drivers/gpio/Makefile   |1
>>  drivers/gpio/gpio-rcar.c|  406 
>>  include/linux/platform_data/gpio-rcar.h |   29 ++
>>  4 files changed, 442 insertions(+)
>>
>> --- 0001/drivers/gpio/Kconfig
>> +++ work/drivers/gpio/Kconfig 2013-03-05 09:07:34.0 +0900
>> @@ -201,6 +201,12 @@ config GPIO_PXA
>>   help
>> Say yes here to support the PXA GPIO device
>>
>> +config GPIO_RCAR
>> + tristate "Renesas R-Car GPIO"
>> + depends on ARM
>> + help
>> +   Say yes here to support GPIO on Renesas R-Car SoCs.
>> +
>>  config GPIO_SPEAR_SPICS
>>   bool "ST SPEAr13xx SPI Chip Select as GPIO support"
>>   depends on PLAT_SPEAR
>> --- 0001/drivers/gpio/Makefile
>> +++ work/drivers/gpio/Makefile2013-03-05 09:07:34.0 +0900
>> @@ -56,6 +56,7 @@ obj-$(CONFIG_GPIO_PL061)+= gpio-pl061.o
>>  obj-$(CONFIG_GPIO_PXA)   += gpio-pxa.o
>>  obj-$(CONFIG_GPIO_RC5T583)   += gpio-rc5t583.o
>>  obj-$(CONFIG_GPIO_RDC321X)   += gpio-rdc321x.o
>> +obj-$(CONFIG_GPIO_RCAR)  += gpio-rcar.o
>>  obj-$(CONFIG_PLAT_SAMSUNG)   += gpio-samsung.o
>>  obj-$(CONFIG_ARCH_SA1100)+= gpio-sa1100.o
>>  obj-$(CONFIG_GPIO_SCH)   += gpio-sch.o
>> --- /dev/null
>> +++ work/drivers/gpio/gpio-rcar.c 2013-03-05 09:13:23.0 +0900
>> @@ -0,0 +1,406 @@
>> +/*
>> + * Renesas R-Car GPIO Support
>> + *
>> + *  Copyright (C) 2013 Magnus Damm
>> + *
>> + * This program is free software; you can redistribute it and/or modify
>> + * it under the terms of the GNU General Public License as published by
>> + * the Free Software Foundation; either version 2 of the License
>> + *
>> + * This program is distributed in the hope that it will be useful,
>> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
>> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
>> + * GNU General Public License for more details.
>> + *
>> + * You should have received a copy of the GNU General Public License
>> + * along with this program; if not, write to the Free Software
>> + * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA  02111-1307
>> USA + */
>
> You can remove the last paragraph.

Sure!

>> +
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>
> Could you please sort the headers alphabetically ?

Uhm, ok, if that makes you happy! =)

>> +
>> +struct gpio_rcar_priv {
>> + void __iomem *base;
>> + spinlock_t lock;
>> + struct gpio_rcar_config config;
>> + struct platform_device *pdev;
>> + struct gpio_chip gpio_chip;
>> + struct irq_chip irq_chip;
>> + struct irq_domain *irq_domain;
>> +};
>> +
>> +#define IOINTSEL 0x00
>> +#define INOUTSEL 0x04
>> +#define OUTDT 0x08
>> +#define INDT 0x0c
>> +#define INTDT 0x10
>> +#define INTCLR 0x14
>> +#define INTMSK 0x18
>> +#define MSKCLR 0x1c
>> +#define POSNEG 0x20
>> +#define EDGLEVEL 0x24
>> +#define FILONOFF 0x28
>
> #define'd values are usually tab-aligned, but that's up to you.
>
>> +static inline unsigned long gpio_rcar_read(struct gpio_rcar_priv *p, int
>> offs)
>> +{
>> + return ioread32(p->base + offs);
>> +}
>> +
>> +static inline void gpio_rcar_write(struct gpio_rcar_priv *p, int offs,
>> +unsigned long value)
>> +{
>> + iowrite32(value, p->base + offs);
>> +}
>
> You often perform read-update-write operations, would it make sense to define
> gpio_rcar_clr() and gpio_rcar_set() functions ?

Good idea, I'll check and see if it reduces the code size.

>> +static void gpio_rcar_irq_disable(struct irq_data *d)
>> +{
>> + struct 

[PATCH 12/18] driver: scsi: remove cast for kmalloc/kzalloc return value

[Zhang Yanfei]

remove cast for kmalloc/kzalloc return value.

Signed-off-by: Zhang Yanfei 
Cc: "James E.J. Bottomley" 
Cc: Andrew Morton 
Cc: linux-s...@vger.kernel.org
---
 drivers/scsi/hpsa.c   |3 +--
 drivers/scsi/lpfc/lpfc_init.c |2 +-
 2 files changed, 2 insertions(+), 3 deletions(-)

diff --git a/drivers/scsi/hpsa.c b/drivers/scsi/hpsa.c
index 7f4f790..7a5a002 100644
--- a/drivers/scsi/hpsa.c
+++ b/drivers/scsi/hpsa.c
@@ -3071,8 +3071,7 @@ static int hpsa_big_passthru_ioctl(struct ctlr_info *h, 
void __user *argp)
return -EINVAL;
if (!capable(CAP_SYS_RAWIO))
return -EPERM;
-   ioc = (BIG_IOCTL_Command_struct *)
-   kmalloc(sizeof(*ioc), GFP_KERNEL);
+   ioc = kmalloc(sizeof(*ioc), GFP_KERNEL);
if (!ioc) {
status = -ENOMEM;
goto cleanup1;
diff --git a/drivers/scsi/lpfc/lpfc_init.c b/drivers/scsi/lpfc/lpfc_init.c
index 314b4f6..f9a3b30 100644
--- a/drivers/scsi/lpfc/lpfc_init.c
+++ b/drivers/scsi/lpfc/lpfc_init.c
@@ -4674,7 +4674,7 @@ lpfc_sli_driver_resource_setup(struct lpfc_hba *phba)
}
 
if (!phba->sli.ring)
-   phba->sli.ring = (struct lpfc_sli_ring *)
+   phba->sli.ring =
kzalloc(LPFC_SLI3_MAX_RING *
sizeof(struct lpfc_sli_ring), GFP_KERNEL);
if (!phba->sli.ring)
-- 
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/

Re: workqueue panic in 3.4 kernel

[Tejun Heo]

On Tue, Mar 12, 2013 at 01:18:01PM +0800, Lei Wen wrote:
> > You're initializing random piece of memory which may contain any
> > garbage and triggering BUG if some bit is set on it. No, you can't do
> > that. debugobj is the right tool for debugging object lifetime issues
> > and is already supported.
> 
> The debugobj is not helping on this issue, I have enabled both
> CONFIG_DEBUG_OBJECTS_WORK and CONFIG_DEBUG_OBJECTS.
> But find they didn't report any issue at all.

It should. No idea why it didn't. Would be interesting to find out
why.

> And I am not init random memory, original issue is call init multi-times
> for one structure and that piece of memory already been allocated.
> And __INIT_WORK shouldn't call over random memory, right?

Memory areas aren't always zero on allocation.

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

[PATCH 11/18] driver: s390: net: remove cast for kzalloc return value

[Zhang Yanfei]

remove cast for kzalloc return value.

Signed-off-by: Zhang Yanfei 
Cc: Ursula Braun 
Cc: Frank Blaschka 
Cc: Martin Schwidefsky 
Cc: Heiko Carstens 
Cc: Andrew Morton 
Cc: linux...@de.ibm.com
Cc: linux-s...@vger.kernel.org
---
 drivers/s390/net/qeth_core_main.c |2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/drivers/s390/net/qeth_core_main.c 
b/drivers/s390/net/qeth_core_main.c
index 0d8cdff..754a54f 100644
--- a/drivers/s390/net/qeth_core_main.c
+++ b/drivers/s390/net/qeth_core_main.c
@@ -316,7 +316,7 @@ static inline int qeth_alloc_cq(struct qeth_card *card)
 
card->qdio.no_in_queues = 2;
 
-   card->qdio.out_bufstates = (struct qdio_outbuf_state *)
+   card->qdio.out_bufstates =
kzalloc(card->qdio.no_out_queues *
QDIO_MAX_BUFFERS_PER_Q *
sizeof(struct qdio_outbuf_state), GFP_KERNEL);
-- 
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/

Re: [PATCH 1/2] PCI: define macro for marvell vendor ID

[Andrew Cooks]

On Fri, Mar 8, 2013 at 12:24 AM, Bjorn Helgaas  wrote:
> On Thu, Mar 7, 2013 at 7:28 AM,   wrote:
>> From: Xiangliang Yu 
>>
>> Define PCI_VENDOR_MARVELL_ID_EXT macro for 0x1b4b vendor ID
>
> "PCI_VENDOR_MARVELL_ID_EXT" is not actually the symbol you defined below.
>
> Per the comment at the top of pci_ids.h, we don't add things here
> unless they are shared between multiple drivers.
>
> That said, the 0x1b4b vendor ID is used in mv_init.c, mvumi.h,
> mvumi.c, and ahci.c.  If you want to unify all those so they all use
> same symbol, and define that symbol here in pci_ids.h, that would be
> fine with me.
>

This symbol will also be useful for the quirk that creates iommu
context entries for Marvell devices that use incorrect dma source
tags. I'll update and resend that patch when this change has been
merged.

Thanks
Andrew
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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 10/18] driver: s390: block: remove cast for kzalloc return value

[Zhang Yanfei]

remove cast for kzalloc return value.

Signed-off-by: Zhang Yanfei 
Cc: Martin Schwidefsky 
Cc: Heiko Carstens 
Cc: Andrew Morton 
Cc: linux...@de.ibm.com
---
 drivers/s390/block/dasd_devmap.c |3 +--
 1 files changed, 1 insertions(+), 2 deletions(-)

diff --git a/drivers/s390/block/dasd_devmap.c b/drivers/s390/block/dasd_devmap.c
index c196827..a71bb8a 100644
--- a/drivers/s390/block/dasd_devmap.c
+++ b/drivers/s390/block/dasd_devmap.c
@@ -410,8 +410,7 @@ dasd_add_busid(const char *bus_id, int features)
struct dasd_devmap *devmap, *new, *tmp;
int hash;
 
-   new = (struct dasd_devmap *)
-   kzalloc(sizeof(struct dasd_devmap), GFP_KERNEL);
+   new = kzalloc(sizeof(struct dasd_devmap), GFP_KERNEL);
if (!new)
return ERR_PTR(-ENOMEM);
spin_lock(_devmap_lock);
-- 
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/

Re: linux-next: unneeded merge in the security tree

[Stephen Rothwell]

On Tue, 12 Mar 2013 00:16:41 -0400 Theodore Ts'o  wrote:
>
> On Tue, Mar 12, 2013 at 03:10:53PM +1100, James Morris wrote:
> > On Tue, 12 Mar 2013, Stephen Rothwell wrote:
> > > The top commit in the security tree today is a merge of v3.9-rc2.  This
> > > is a completely unnecessary merge as the tree before the merge was a
> > > subset of v3.9-rc1 and so if the merge had been done using anything but
> > > the tag, it would have just been a fast forward.  I know that this is now
> > > deliberate behaviour on git's behalf, but isn't there some way we can
> > > make this easier on maintainers who are just really just trying to pick a
> > > new starting point for their trees after a release?  (at least I assume
> > > that is what James was trying to do)
> > 
> > Yes, and I was merging to a tag as required by Linus.
> 
> Why not just force the head of the security tree to be v3.9-rc2?  Then
> you don't end up creating a completely unnecessary merge commit, and
> users who were at the previous head of the security tree will
> experience a fast forward when they pull your new head.

Well, you used to be able to merge a tag and it would just fast forward
if possible.  That was changed (for good reason), but now gives us this
outcome.   Also, "git merge --ff" does not override that behaviour, but
"git merge --ff-only" does.  Also, of course, if (say) origin/master had
been v3.9-rc2, then "git merge origin/master" would have also just done a
fast forward.

I wonder if "git merge v3.9-rc2^{}" should work (git says "fatal: v3.9-rc2{}
 - not something we can merge").

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


pgpOsafkPa4Ab.pgp
Description: PGP signature

Re: workqueue panic in 3.4 kernel

[Lei Wen]

Tejun,

On Tue, Mar 12, 2013 at 1:12 PM, Tejun Heo  wrote:
> Hello,
>
> On Tue, Mar 12, 2013 at 01:08:15PM +0800, Lei Wen wrote:
>> diff --git a/include/linux/workqueue.h b/include/linux/workqueue.h
>> index 8afab27..425d5a2 100644
>> --- a/include/linux/workqueue.h
>> +++ b/include/linux/workqueue.h
>> @@ -189,12 +189,16 @@ static inline unsigned int work_static(struct
>> work_struct *work) { return 0; }
>>   * NOTE! No point in using "atomic_long_set()": using a direct
>>   * assignment of the work data initializer allows the compiler
>>   * to generate better code.
>> + *
>> + * We take the assumption that work should not be inited if it already
>> + * hold the pending bit, or bug would be reported.
>>   */
>>  #ifdef CONFIG_LOCKDEP
>>  #define __INIT_WORK(_work, _func, _onstack)\
>> do {\
>> static struct lock_class_key __key; \
>> \
>> +   BUG_ON(work_pending(_work));\
>
> You're initializing random piece of memory which may contain any
> garbage and triggering BUG if some bit is set on it. No, you can't do
> that. debugobj is the right tool for debugging object lifetime issues
> and is already supported.

The debugobj is not helping on this issue, I have enabled both
CONFIG_DEBUG_OBJECTS_WORK and CONFIG_DEBUG_OBJECTS.
But find they didn't report any issue at all.

And I am not init random memory, original issue is call init multi-times
for one structure and that piece of memory already been allocated.
And __INIT_WORK shouldn't call over random memory, right?

All this patch is adding a check here.

Thanks,
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: linux-next: build warning after merge of the final tree (tip tree related)

[Li Zefan]

On 2013/3/12 12:42, Stephen Rothwell wrote:
> Hi all,
> 
> After merging the final tree, today's linux-next build (sparc defconfig)
> produced this warning:
> 
> In file included from kernel/sched/core.c:85:0:
> kernel/sched/sched.h:1043:39: warning: 'struct sched_domain' declared inside 
> parameter list [enabled by default]
> kernel/sched/sched.h:1043:39: warning: its scope is only this definition or 
> declaration, which is probably not what you want [enabled by default]
> In file included from kernel/sched/cputime.c:7:0:
> kernel/sched/sched.h:1043:39: warning: 'struct sched_domain' declared inside 
> parameter list [enabled by default]
> kernel/sched/sched.h:1043:39: warning: its scope is only this definition or 
> declaration, which is probably not what you want [enabled by default]
> In file included from kernel/sched/idle_task.c:1:0:
> kernel/sched/sched.h:1043:39: warning: 'struct sched_domain' declared inside 
> parameter list [enabled by default]
> kernel/sched/sched.h:1043:39: warning: its scope is only this definition or 
> declaration, which is probably not what you want [enabled by default]
> In file included from kernel/sched/fair.c:35:0:
> kernel/sched/sched.h:1043:39: warning: 'struct sched_domain' declared inside 
> parameter list [enabled by default]
> kernel/sched/sched.h:1043:39: warning: its scope is only this definition or 
> declaration, which is probably not what you want [enabled by default]
> In file included from kernel/sched/stop_task.c:1:0:
> kernel/sched/sched.h:1043:39: warning: 'struct sched_domain' declared inside 
> parameter list [enabled by default]
> kernel/sched/sched.h:1043:39: warning: its scope is only this definition or 
> declaration, which is probably not what you want [enabled by default]
> In file included from kernel/sched/rt.c:6:0:
> kernel/sched/sched.h:1043:39: warning: 'struct sched_domain' declared inside 
> parameter list [enabled by default]
> kernel/sched/sched.h:1043:39: warning: its scope is only this definition or 
> declaration, which is probably not what you want [enabled by default]
> 
> Probably caused by commit c82ba9fa7588 ("sched: Move struct sched_class
> to kernel/sched/sched.h") from the tip tree which removed a forward
> declaration of "struct sched_domain" from include/linux/sched.h - the
> read declaration is protected by CONFIG_SMP (which is not set for this
> build).
> 

Should be fixed by this, and it has been queued in tip:sched/core

Commit-ID:  b719203b846284e77f5c50fca04b458b6484aeae
Gitweb: http://git.kernel.org/tip/b719203b846284e77f5c50fca04b458b6484aeae
Author: Li Zefan 
AuthorDate: Thu, 7 Mar 2013 10:00:26 +0800
Committer:  Ingo Molnar 
CommitDate: Mon, 11 Mar 2013 09:07:24 +0100

sched: Fix update_group_power() prototype placement to fix build warning when 
!CONFIG_SMP

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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 09/18] driver: isdn: hisax: remove cast for kmalloc/kzalloc return value

[Zhang Yanfei]

remove cast for kmalloc/kzalloc return value.

Signed-off-by: Zhang Yanfei 
Cc: Andrew Morton 
Cc: Karsten Keil 
Cc: net...@vger.kernel.org
---
 drivers/isdn/hisax/fsm.c|2 +-
 drivers/isdn/hisax/hfc_sx.c |2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/isdn/hisax/fsm.c b/drivers/isdn/hisax/fsm.c
index 1bb2910..c7a9471 100644
--- a/drivers/isdn/hisax/fsm.c
+++ b/drivers/isdn/hisax/fsm.c
@@ -26,7 +26,7 @@ FsmNew(struct Fsm *fsm, struct FsmNode *fnlist, int fncount)
 {
int i;
 
-   fsm->jumpmatrix = (FSMFNPTR *)
+   fsm->jumpmatrix =
kzalloc(sizeof(FSMFNPTR) * fsm->state_count * fsm->event_count, 
GFP_KERNEL);
if (!fsm->jumpmatrix)
return -ENOMEM;
diff --git a/drivers/isdn/hisax/hfc_sx.c b/drivers/isdn/hisax/hfc_sx.c
index 90f34ae..dc4574f 100644
--- a/drivers/isdn/hisax/hfc_sx.c
+++ b/drivers/isdn/hisax/hfc_sx.c
@@ -1479,7 +1479,7 @@ int setup_hfcsx(struct IsdnCard *card)
release_region(cs->hw.hfcsx.base, 2);
return (0);
}
-   if (!(cs->hw.hfcsx.extra = (void *)
+   if (!(cs->hw.hfcsx.extra =
  kmalloc(sizeof(struct hfcsx_extra), GFP_ATOMIC))) {
release_region(cs->hw.hfcsx.base, 2);
printk(KERN_WARNING "HFC-SX: unable to allocate 
memory\n");
-- 
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 08/18] driver: isdn: capi: remove cast for kmalloc return value

[Zhang Yanfei]

remove cast for kmalloc return value.

Signed-off-by: Zhang Yanfei 
Cc: Andrew Morton 
Cc: Karsten Keil 
Cc: net...@vger.kernel.org
---
 drivers/isdn/capi/capidrv.c |3 +--
 1 files changed, 1 insertions(+), 2 deletions(-)

diff --git a/drivers/isdn/capi/capidrv.c b/drivers/isdn/capi/capidrv.c
index 832bc80..cc9f192 100644
--- a/drivers/isdn/capi/capidrv.c
+++ b/drivers/isdn/capi/capidrv.c
@@ -469,8 +469,7 @@ static int capidrv_add_ack(struct capidrv_ncci *nccip,
 {
struct ncci_datahandle_queue *n, **pp;
 
-   n = (struct ncci_datahandle_queue *)
-   kmalloc(sizeof(struct ncci_datahandle_queue), GFP_ATOMIC);
+   n = kmalloc(sizeof(struct ncci_datahandle_queue), GFP_ATOMIC);
if (!n) {
printk(KERN_ERR "capidrv: kmalloc ncci_datahandle failed\n");
return -1;
-- 
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 07/18] driver: hv: remove cast for kmalloc return value

[Zhang Yanfei]

remove cast for kmalloc return value.

Signed-off-by: Zhang Yanfei 
Cc: "K. Y. Srinivasan" 
Cc: Haiyang Zhang 
Cc: Andrew Morton 
Cc: de...@linuxdriverproject.org
---
 drivers/hv/hv.c |5 ++---
 1 files changed, 2 insertions(+), 3 deletions(-)

diff --git a/drivers/hv/hv.c b/drivers/hv/hv.c
index 7311589..ae49237 100644
--- a/drivers/hv/hv.c
+++ b/drivers/hv/hv.c
@@ -289,9 +289,8 @@ void hv_synic_init(void *arg)
/* Check the version */
rdmsrl(HV_X64_MSR_SVERSION, version);
 
-   hv_context.event_dpc[cpu] = (struct tasklet_struct *)
-   kmalloc(sizeof(struct tasklet_struct),
-   GFP_ATOMIC);
+   hv_context.event_dpc[cpu] = kmalloc(sizeof(struct tasklet_struct),
+   GFP_ATOMIC);
if (hv_context.event_dpc[cpu] == NULL) {
pr_err("Unable to allocate event dpc\n");
goto cleanup;
-- 
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/

Re: workqueue panic in 3.4 kernel

[Tejun Heo]

Hello,

On Tue, Mar 12, 2013 at 01:08:15PM +0800, Lei Wen wrote:
> diff --git a/include/linux/workqueue.h b/include/linux/workqueue.h
> index 8afab27..425d5a2 100644
> --- a/include/linux/workqueue.h
> +++ b/include/linux/workqueue.h
> @@ -189,12 +189,16 @@ static inline unsigned int work_static(struct
> work_struct *work) { return 0; }
>   * NOTE! No point in using "atomic_long_set()": using a direct
>   * assignment of the work data initializer allows the compiler
>   * to generate better code.
> + *
> + * We take the assumption that work should not be inited if it already
> + * hold the pending bit, or bug would be reported.
>   */
>  #ifdef CONFIG_LOCKDEP
>  #define __INIT_WORK(_work, _func, _onstack)\
> do {\
> static struct lock_class_key __key; \
> \
> +   BUG_ON(work_pending(_work));\

You're initializing random piece of memory which may contain any
garbage and triggering BUG if some bit is set on it. No, you can't do
that. debugobj is the right tool for debugging object lifetime issues
and is already supported.

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: Regulator API ignored return values

[Jingoo Han]

On Tuesday, March 12, 2013 5:44 AM, Arnd Bergmann wrote:
> 
> Hi all,
> 
> Mark Brown has added a patch to Linux-next that warns about certain regulator
> API functions being called without checking the results, which seems to have
> uncovered a number of bugs.
> 
> I've added a few people to Cc that might be interested in the reports and
> in fixing these bugs. Below you can find a list of all instances I found
> building the ARM defconfigs.
> 
>   Arnd
> 
[...]
> /git/arm-soc/drivers/video/backlight/l4f00242t03.c: In function 
> 'l4f00242t03_lcd_init':
> /git/arm-soc/drivers/video/backlight/l4f00242t03.c:58:18: warning: ignoring 
> return value of
> 'regulator_enable', declared with attribute warn_unused_result 
> [-Wunused-result]
> /git/arm-soc/drivers/video/backlight/l4f00242t03.c:61:18: warning: ignoring 
> return value of
> 'regulator_enable', declared with attribute warn_unused_result 
> [-Wunused-result]

Hi Arnd Bergmann,

I fixed these warnings and the patch was added to mm-tree.
(http://www.spinics.net/lists/mm-commits/msg95324.html)
Thank you for reporting :)

Best regards,
Jingoo Han
N떑꿩�r툤y鉉싕b쾊Ф푤v�^�)頻{.n�+돴쪐{콗喩zX㎍썳變}찠꼿쟺�:+v돣�쳭喩zZ+€�+zf＂톒쉱�~넮녬i鎬z�췿ⅱ�?솳鈺�&�)刪f뷌^j푹y쬶끷@A첺뛴
0띠h��뭝

[PATCH 06/18] driver: gpu: drm: i915: remove cast for kzalloc return value

[Zhang Yanfei]

remove cast for kzalloc return value.

Signed-off-by: Zhang Yanfei 
Cc: Andrew Morton 
Cc: David Airlie 
Cc: dri-de...@lists.freedesktop.org
---
 drivers/gpu/drm/i915/intel_sdvo.c |2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_sdvo.c 
b/drivers/gpu/drm/i915/intel_sdvo.c
index d07a8cd..78413ec 100644
--- a/drivers/gpu/drm/i915/intel_sdvo.c
+++ b/drivers/gpu/drm/i915/intel_sdvo.c
@@ -451,7 +451,7 @@ static bool intel_sdvo_write_cmd(struct intel_sdvo 
*intel_sdvo, u8 cmd,
int i, ret = true;
 
 /* Would be simpler to allocate both in one go ? */
-   buf = (u8 *)kzalloc(args_len * 2 + 2, GFP_KERNEL);
+   buf = kzalloc(args_len * 2 + 2, GFP_KERNEL);
if (!buf)
return false;
 
-- 
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 05/18] driver: staging: csr: remove cast for kmalloc return value

[Zhang Yanfei]

remove cast for kmalloc return value.

Signed-off-by: Zhang Yanfei 
Cc: Greg Kroah-Hartman 
Cc: Andrew Morton 
Cc: de...@driverdev.osuosl.org
---
 drivers/staging/csr/drv.c  |4 ++--
 drivers/staging/csr/netdev.c   |2 +-
 drivers/staging/csr/sdio_mmc.c |3 +--
 drivers/staging/csr/sme_native.c   |2 +-
 drivers/staging/csr/unifi_pdu_processing.c |4 ++--
 5 files changed, 7 insertions(+), 8 deletions(-)

diff --git a/drivers/staging/csr/drv.c b/drivers/staging/csr/drv.c
index 3bd52fd..5520d65 100644
--- a/drivers/staging/csr/drv.c
+++ b/drivers/staging/csr/drv.c
@@ -1815,7 +1815,7 @@ udi_log_event(ul_client_t *pcli,
 }
 
 /* Allocate log structure plus actual signal. */
-logptr = (udi_log_t *)kmalloc(sizeof(udi_log_t) + total_len, GFP_KERNEL);
+logptr = kmalloc(sizeof(udi_log_t) + total_len, GFP_KERNEL);
 
 if (logptr == NULL) {
 printk(KERN_ERR
@@ -1890,7 +1890,7 @@ uf_sme_queue_message(unifi_priv_t *priv, u8 *buffer, int 
length)
 }
 
 /* Allocate log structure plus actual signal. */
-logptr = (udi_log_t *)kmalloc(sizeof(udi_log_t) + length, GFP_ATOMIC);
+logptr = kmalloc(sizeof(udi_log_t) + length, GFP_ATOMIC);
 if (logptr == NULL) {
 unifi_error(priv, "Failed to allocate %d bytes for an SME message\n",
 sizeof(udi_log_t) + length);
diff --git a/drivers/staging/csr/netdev.c b/drivers/staging/csr/netdev.c
index 7dad26f..a0177d9 100644
--- a/drivers/staging/csr/netdev.c
+++ b/drivers/staging/csr/netdev.c
@@ -2365,7 +2365,7 @@ unifi_rx(unifi_priv_t *priv, CSR_SIGNAL *signal, 
bulk_data_param_t *bulkdata)
 rx_buffered_packets_t *rx_q_item;
 struct list_head *rx_list;
 
-rx_q_item = (rx_buffered_packets_t 
*)kmalloc(sizeof(rx_buffered_packets_t),
+rx_q_item = kmalloc(sizeof(rx_buffered_packets_t),
 GFP_KERNEL);
 if (rx_q_item == NULL) {
 unifi_error(priv, "%s: Failed to allocate %d bytes for rx packet 
record\n",
diff --git a/drivers/staging/csr/sdio_mmc.c b/drivers/staging/csr/sdio_mmc.c
index b6a16de..30271d3 100644
--- a/drivers/staging/csr/sdio_mmc.c
+++ b/drivers/staging/csr/sdio_mmc.c
@@ -1031,8 +1031,7 @@ uf_glue_sdio_probe(struct sdio_func *func,
sdio_func_id(func), instance);
 
 /* Allocate context */
-sdio_ctx = (CsrSdioFunction *)kmalloc(sizeof(CsrSdioFunction),
-  GFP_KERNEL);
+sdio_ctx = kmalloc(sizeof(CsrSdioFunction), GFP_KERNEL);
 if (sdio_ctx == NULL) {
 sdio_release_host(func);
 return -ENOMEM;
diff --git a/drivers/staging/csr/sme_native.c b/drivers/staging/csr/sme_native.c
index 525fe1b..ca55249 100644
--- a/drivers/staging/csr/sme_native.c
+++ b/drivers/staging/csr/sme_native.c
@@ -273,7 +273,7 @@ sme_native_log_event(ul_client_t *pcli,
 }
 
 /* Allocate log structure plus actual signal. */
-logptr = (udi_log_t *)kmalloc(sizeof(udi_log_t) + total_len, GFP_KERNEL);
+logptr = kmalloc(sizeof(udi_log_t) + total_len, GFP_KERNEL);
 
 if (logptr == NULL) {
 unifi_error(priv,
diff --git a/drivers/staging/csr/unifi_pdu_processing.c 
b/drivers/staging/csr/unifi_pdu_processing.c
index 95efc36..bf7c00a 100644
--- a/drivers/staging/csr/unifi_pdu_processing.c
+++ b/drivers/staging/csr/unifi_pdu_processing.c
@@ -403,7 +403,7 @@ CsrResult enque_tx_data_pdu(unifi_priv_t *priv, 
bulk_data_param_t *bulkdata,
 
 
 
-tx_q_item = (tx_buffered_packets_t 
*)kmalloc(sizeof(tx_buffered_packets_t), GFP_ATOMIC);
+tx_q_item = kmalloc(sizeof(tx_buffered_packets_t), GFP_ATOMIC);
 if (tx_q_item == NULL) {
 unifi_error(priv,
 "Failed to allocate %d bytes for tx packet record\n",
@@ -3282,7 +3282,7 @@ void add_to_send_cfm_list(unifi_priv_t * priv,
 {
 tx_buffered_packets_t *send_cfm_list_item = NULL;
 
-send_cfm_list_item = (tx_buffered_packets_t *) 
kmalloc(sizeof(tx_buffered_packets_t), GFP_ATOMIC);
+send_cfm_list_item = kmalloc(sizeof(tx_buffered_packets_t), GFP_ATOMIC);
 
 if(send_cfm_list_item == NULL){
 unifi_warning(priv, "%s: Failed to allocate memory for new list item 
\n");
-- 
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/

Re: [PATCH 4/9] mm: use mm_populate() for blocking remap_file_pages()

[Michel Lespinasse]

On Mon, Mar 11, 2013 at 9:23 PM, Hillf Danton  wrote:
> Is it still necessary to populate mm if bail out due
> to a linear mapping encountered?

Yes. mmap_region() doesn't do it on its own, and we want the emulated
linear case to behave similarly to the true nonlinear case.

-- 
Michel "Walken" Lespinasse
A program is never fully debugged until the last user dies.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] cpufreq: cpufreq-cpu0: support for clock which are not in DT yet.

[Santosh Shilimkar]

On Tuesday 12 March 2013 04:35 AM, Nishanth Menon wrote:
> On certain SoCs like variants of OMAP, the clock conversion to DT
> is not complete. In short, the ability to:
> cpus {
> cpu@0 {
>   clocks = < 0>;
> };
>  };
> is not possible. However, the clock node is registered.
> Allow for clk names to be provided as string so as to be used when needed.
> Example (for OMAP3630):
> cpus {
> cpu@0 {
>   clock-name = "cpufreq_ck";
> };
>  };
> 
> Cc: "Rafael J. Wysocki" 
> Cc: Santosh Shilimkar 
> Cc: Shawn Guo 
> Cc: linux-kernel@vger.kernel.org
> Cc: cpuf...@vger.kernel.org
> Cc: linux...@vger.kernel.org
> Cc: linux-o...@vger.kernel.org
> 
> Signed-off-by: Nishanth Menon 
> ---
Seems a reasonable to me.
Acked-by: Santosh Shilimkar 


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] perf trace: Get rid of a duplicate code

[Namhyung Kim]

From: Namhyung Kim 

Checking of sample.raw_data is duplicated and seems an artifact of
some git auto merging stuff.  Kill it.

Signed-off-by: Namhyung Kim 
---
 tools/perf/builtin-trace.c | 7 ---
 1 file changed, 7 deletions(-)

diff --git a/tools/perf/builtin-trace.c b/tools/perf/builtin-trace.c
index f0c20ef0cd1c..49fedb51d569 100644
--- a/tools/perf/builtin-trace.c
+++ b/tools/perf/builtin-trace.c
@@ -527,13 +527,6 @@ again:
continue;
}
 
-   if (sample.raw_data == NULL) {
-   printf("%s sample with no payload for tid: %d, 
cpu %d, raw_size=%d, skipping...\n",
-  perf_evsel__name(evsel), sample.tid,
-  sample.cpu, sample.raw_size);
-   continue;
-   }
-
handler = evsel->handler.func;
handler(trace, evsel, );
}
-- 
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/

[PATCH 04/18] x86: platform: mrst: remove cast for kmalloc return value

[Zhang Yanfei]

remove cast for kmalloc return value.

Signed-off-by: Zhang Yanfei 
Cc: Thomas Gleixner 
Cc: Ingo Molnar 
Cc: "H. Peter Anvin" 
Cc: Andrew Morton 
Cc: "x...@kernel.org" 
---
 arch/x86/platform/mrst/mrst.c |3 +--
 1 files changed, 1 insertions(+), 2 deletions(-)

diff --git a/arch/x86/platform/mrst/mrst.c b/arch/x86/platform/mrst/mrst.c
index e31bcd8..a0a0a43 100644
--- a/arch/x86/platform/mrst/mrst.c
+++ b/arch/x86/platform/mrst/mrst.c
@@ -356,8 +356,7 @@ static int __init sfi_parse_gpio(struct sfi_table_header 
*table)
num = SFI_GET_NUM_ENTRIES(sb, struct sfi_gpio_table_entry);
pentry = (struct sfi_gpio_table_entry *)sb->pentry;
 
-   gpio_table = (struct sfi_gpio_table_entry *)
-   kmalloc(num * sizeof(*pentry), GFP_KERNEL);
+   gpio_table = kmalloc(num * sizeof(*pentry), GFP_KERNEL);
if (!gpio_table)
return -1;
memcpy(gpio_table, pentry, num * sizeof(*pentry));
-- 
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 03/18] powerpc: remove cast for kmalloc/kzalloc return value

[Zhang Yanfei]

remove cast for kmalloc/kzalloc return value.

Signed-off-by: Zhang Yanfei 
Cc: Benjamin Herrenschmidt 
Cc: Paul Mackerras 
Cc: Andrew Morton 
Cc: linuxppc-...@lists.ozlabs.org
---
 arch/powerpc/kernel/nvram_64.c |3 +--
 arch/powerpc/kvm/book3s_pr.c   |2 +-
 2 files changed, 2 insertions(+), 3 deletions(-)

diff --git a/arch/powerpc/kernel/nvram_64.c b/arch/powerpc/kernel/nvram_64.c
index bec1e93..48fbc2b 100644
--- a/arch/powerpc/kernel/nvram_64.c
+++ b/arch/powerpc/kernel/nvram_64.c
@@ -511,8 +511,7 @@ int __init nvram_scan_partitions(void)
   "detected: 0-length partition\n");
goto out;
}
-   tmp_part = (struct nvram_partition *)
-   kmalloc(sizeof(struct nvram_partition), GFP_KERNEL);
+   tmp_part = kmalloc(sizeof(struct nvram_partition), GFP_KERNEL);
err = -ENOMEM;
if (!tmp_part) {
printk(KERN_ERR "nvram_scan_partitions: kmalloc 
failed\n");
diff --git a/arch/powerpc/kvm/book3s_pr.c b/arch/powerpc/kvm/book3s_pr.c
index 5e93438..dbdc15a 100644
--- a/arch/powerpc/kvm/book3s_pr.c
+++ b/arch/powerpc/kvm/book3s_pr.c
@@ -1039,7 +1039,7 @@ struct kvm_vcpu *kvmppc_core_vcpu_create(struct kvm *kvm, 
unsigned int id)
if (!vcpu_book3s)
goto out;
 
-   vcpu_book3s->shadow_vcpu = (struct kvmppc_book3s_shadow_vcpu *)
+   vcpu_book3s->shadow_vcpu =
kzalloc(sizeof(*vcpu_book3s->shadow_vcpu), GFP_KERNEL);
if (!vcpu_book3s->shadow_vcpu)
goto free_vcpu;
-- 
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/

linux-next: Tree for Mar 12

[Stephen Rothwell]

Hi all,

Changes since 20130307:

New tree: arc-next

Removed tree: modem_shm (at maintainers request)

The net-next tree gained a conflict against Linus' tree.

The wireless-next tree gained a conflict against the wireless tree.

The input tree gained a build failure for which I reverted a commit.

The drivers-x86 tree gained a conflict against Linus' tree.

The drm-intel tree gained a build failure for which I reverted a commit.

The gpio tree still had its build failure for which I reverted a commit.

The renesas tree gained a conflict against Linus' tree.

The signal tree gained conflicts against the mips tree and Linus' tree.

The akpm tree gained a conflict against the arm-soc tree and lost several
patches that turned up elsewhere.



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 217 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 (7c6baa3 Merge branch 'perf-urgent-for-linus' of 
git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip)
Merging fixes/master (d287b87 Merge branch 'for-linus' of 
git://git.kernel.org/pub/scm/linux/kernel/git/viro/vfs)
Merging kbuild-current/rc-fixes (02f3e53 Merge branch 'yem-kconfig-rc-fixes' of 
git://gitorious.org/linux-kconfig/linux-kconfig into kbuild/rc-fixes)
Merging arc-current/for-curr (180d406 ARC: ABIv3: fork/vfork wrappers not 
needed in "no-legacy-syscall" ABI)
Merging arm-current/fixes (455bd4c ARM: 7668/1: fix memset-related crashes 
caused by recent GCC (4.7.2) optimizations)
Merging m68k-current/for-linus (5618395 m68k: Sort out !CONFIG_MMU_SUN3 vs. 
CONFIG_HAS_DMA)
Merging powerpc-merge/merge (54c9b225 powerpc: Set DSCR bit in FSCR setup)
Merging sparc/master (76950e6 sparc64: correctly recognize SPARC64-X chips)
Merging net/master (7c6baa3 Merge branch 'perf-urgent-for-linus' of 
git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip)
Merging ipsec/master (85dfb74 af_key: initialize satype in 
key_notify_policy_flush())
Merging sound-current/for-linus (66efdc7 ALSA: seq: Fix missing error handling 
in snd_seq_timer_open())
Merging pci-current/for-linus (249bfb8 PCI/PM: Clean up PME state when removing 
a device)
Merging wireless/master (de12198 Merge tag 'nfc-fixes-3.9-1' of 
git://git.kernel.org/pub/scm/linux/kernel/git/sameo/nfc-fixes)
Merging driver-core.current/driver-core-linus (f6161aa Linux 3.9-rc2)
Merging tty.current/tty-linus (34dcfb8 TTY: disable debugging warning)
Merging usb.current/usb-linus (2d90e63 qcaux: add Franklin U600)
Merging staging.current/staging-linus (564c526 staging: comedi: dt9812: use 
CR_CHAN() for channel number)
Merging char-misc.current/char-misc-linus (f6161aa Linux 3.9-rc2)
Merging input-current/for-linus (4b7d293 Input: mms114 - Fix regulator enable 
and disable paths)
Merging md-current/for-linus (f3378b4 md: expedite metadata update when 
switching  read-auto -> active)
Merging audit-current/for-linus (c158a35 audit: no leading space in 
audit_log_d_path prefix)
Merging crypto-current/master (8fd61d3 crypto: user - ensure user supplied 
strings are nul-terminated)
Merging ide/master (bf6b438 ide: gayle: use module_platform_driver_probe())
Merging dwmw2/master (084a0ec x86: add 

[PATCH 02/18] ia64: remove cast for kmalloc return value

[Zhang Yanfei]

remove cast for kmalloc return value.

Signed-off-by: Zhang Yanfei 
Cc: Tony Luck 
Cc: Fenghua Yu 
Cc: Andrew Morton 
Cc: linux-i...@vger.kernel.org
---
 arch/ia64/kernel/mca_drv.c |2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/arch/ia64/kernel/mca_drv.c b/arch/ia64/kernel/mca_drv.c
index 9392e02..94f8bf7 100644
--- a/arch/ia64/kernel/mca_drv.c
+++ b/arch/ia64/kernel/mca_drv.c
@@ -349,7 +349,7 @@ init_record_index_pools(void)
 
/* - 3 - */
slidx_pool.max_idx = (rec_max_size/sect_min_size) * 2 + 1;
-   slidx_pool.buffer = (slidx_list_t *)
+   slidx_pool.buffer =
kmalloc(slidx_pool.max_idx * sizeof(slidx_list_t), GFP_KERNEL);
 
return slidx_pool.buffer ? 0 : -ENOMEM;
-- 
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 01/18] arm: remove cast for kzalloc return value

[Zhang Yanfei]

remove cast for kzalloc return value.

Signed-off-by: Zhang Yanfei 
Cc: Andrew Morton 
Cc: Russell King 
Cc: linux-arm-ker...@lists.infradead.org
---
 arch/arm/kernel/topology.c |2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/arch/arm/kernel/topology.c b/arch/arm/kernel/topology.c
index 79282eb..f10316b 100644
--- a/arch/arm/kernel/topology.c
+++ b/arch/arm/kernel/topology.c
@@ -100,7 +100,7 @@ static void __init parse_dt_topology(void)
int alloc_size, cpu = 0;
 
alloc_size = nr_cpu_ids * sizeof(struct cpu_capacity);
-   cpu_capacity = (struct cpu_capacity *)kzalloc(alloc_size, GFP_NOWAIT);
+   cpu_capacity = kzalloc(alloc_size, GFP_NOWAIT);
 
while ((cn = of_find_node_by_type(cn, "cpu"))) {
const u32 *rate, *reg;
-- 
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/

linux-next: build warning after merge of the final tree (tip tree related)

[Stephen Rothwell]

Hi all,

After merging the final tree, today's linux-next build (sparc defconfig)
produced this warning:

In file included from kernel/sched/core.c:85:0:
kernel/sched/sched.h:1043:39: warning: 'struct sched_domain' declared inside 
parameter list [enabled by default]
kernel/sched/sched.h:1043:39: warning: its scope is only this definition or 
declaration, which is probably not what you want [enabled by default]
In file included from kernel/sched/cputime.c:7:0:
kernel/sched/sched.h:1043:39: warning: 'struct sched_domain' declared inside 
parameter list [enabled by default]
kernel/sched/sched.h:1043:39: warning: its scope is only this definition or 
declaration, which is probably not what you want [enabled by default]
In file included from kernel/sched/idle_task.c:1:0:
kernel/sched/sched.h:1043:39: warning: 'struct sched_domain' declared inside 
parameter list [enabled by default]
kernel/sched/sched.h:1043:39: warning: its scope is only this definition or 
declaration, which is probably not what you want [enabled by default]
In file included from kernel/sched/fair.c:35:0:
kernel/sched/sched.h:1043:39: warning: 'struct sched_domain' declared inside 
parameter list [enabled by default]
kernel/sched/sched.h:1043:39: warning: its scope is only this definition or 
declaration, which is probably not what you want [enabled by default]
In file included from kernel/sched/stop_task.c:1:0:
kernel/sched/sched.h:1043:39: warning: 'struct sched_domain' declared inside 
parameter list [enabled by default]
kernel/sched/sched.h:1043:39: warning: its scope is only this definition or 
declaration, which is probably not what you want [enabled by default]
In file included from kernel/sched/rt.c:6:0:
kernel/sched/sched.h:1043:39: warning: 'struct sched_domain' declared inside 
parameter list [enabled by default]
kernel/sched/sched.h:1043:39: warning: its scope is only this definition or 
declaration, which is probably not what you want [enabled by default]

Probably caused by commit c82ba9fa7588 ("sched: Move struct sched_class
to kernel/sched/sched.h") from the tip tree which removed a forward
declaration of "struct sched_domain" from include/linux/sched.h - the
read declaration is protected by CONFIG_SMP (which is not set for this
build).

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


pgp_vRDxSDOU9.pgp
Description: PGP signature

Re: [PATCH -tip ] [BUGFIX] kprobes: Move hash_64() into .text.kprobe section

[Ananth N Mavinakayanahalli]

On Mon, Mar 11, 2013 at 11:22:33PM +0900, Masami Hiramatsu wrote:
> Beacuse hash_64() is called from the get_kprobe() inside
> int3 handler, kernel causes int3 recursion and crashes if
> kprobes user puts a probe on it.
> 
> Usually hash_64() is inlined into caller function, but in
> some cases, it has instances by gcc's interprocedural
> constant propagation.
> 
> This patch adds __kprobes tag on the hash_64() and moves
> all those instances into .text.kprobe section so that
> kprobes can refuse probing on the instances.
> 
> I've ensured that all hash_64 instances moves to the
> address between __kprobes_text_start and __kprobes_text_end
> with this patch as below.
> 
> 8138bea0 T __kprobes_text_start
> 8138bec0 t hash_64.constprop.8
> 8138ef98 t hash_64.constprop.26
> 8138efae t hash_64
> 8138f066 t hash_64.constprop.43
> 8138f649 t hash_64.constprop.25
> 8139103a t hash_64.constprop.77
> 81391050 t hash_64.constprop.24
> 81391066 t hash_64.constprop.40
> 8139107c t hash_64.constprop.15
> 81391092 T __kprobes_text_end
> 
> Signed-off-by: Masami Hiramatsu 
> Reported-by: Timo Juhani Lindfors 
> Cc: "David S. Miller" 
> Cc: Nadia Yvette Chambers 
> Cc: Pavel Emelyanov 
> Cc: Jiri Kosina 
> Cc: Ananth N Mavinakayanahalli 

Acked-by: Ananth N Mavinakayanahalli 

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] i2c: exynos5: add High Speed I2C controller driver

[Naveen Krishna Chatradhi]

Adds support for High Speed I2C driver found in Exynos5 and later
SoCs from Samsung. This driver currently supports Auto mode.

Driver only supports Device Tree method.
Note: Added debugfs support for registers view, not tested.

Signed-off-by: Taekgyun Ko 
Signed-off-by: Naveen Krishna Chatradhi 
Cc: R. Chandrasekar 
---
Changes since v3: http://lkml.org/lkml/2012/12/28/46
1. Added Documentation for DT bindings
2. Removed the bus_num, as Doug's pick id from DT is merged in i2c/for-next
3. Split the xfer function for better clarity.
4. Streamlined code flow in isr, handled trans_status register in xfer_msg call.

 .../devicetree/bindings/i2c/i2c-exynos5.txt|   50 ++
 drivers/i2c/busses/Kconfig |7 +
 drivers/i2c/busses/Makefile|1 +
 drivers/i2c/busses/i2c-exynos5.c   |  743 
 4 files changed, 801 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/i2c/i2c-exynos5.txt
 create mode 100644 drivers/i2c/busses/i2c-exynos5.c

diff --git a/Documentation/devicetree/bindings/i2c/i2c-exynos5.txt 
b/Documentation/devicetree/bindings/i2c/i2c-exynos5.txt
new file mode 100644
index 000..0bc9347
--- /dev/null
+++ b/Documentation/devicetree/bindings/i2c/i2c-exynos5.txt
@@ -0,0 +1,50 @@
+* Samsung's High Speed I2C controller
+
+The Samsung's High Speed I2C controller is used to interface with I2C devices
+at various speeds ranging from 100khz to 3.4Mhz.
+
+Required properties:
+  - compatible: value should be.
+  (a) "samsung,exynos5-hsi2c", for i2c compatible with exynos5 hsi2c.
+  - reg: physical base address of the controller and length of memory mapped
+region.
+  - interrupts: interrupt number to the cpu.
+
+  - Samsung GPIO variant (deprecated):
+- gpios: The order of the gpios should be the following: .
+  The gpio specifier depends on the gpio controller.
+  - Pinctrl variant (preferred, if available):
+- pinctrl-0: Pin control group to be used for this controller.
+- pinctrl-names: Should contain only one value - "default".
+
+Optional properties:
+  - samsung,hs-mode: Mode of operation, High speed or Fast speed mode. If not
+specified, default value is 0.
+  - samsung,hs-clock-freq: Desired operating frequency in Hz of the bus.
+If not specified, the default value in Hz is 10.
+  - samsung,fs-clock-freq: Desired operarting frequency in Hz of the bus.
+If not specified, the default value in Hz is 10.
+
+Example:
+
+   hsi2c@12ca {
+   compatible = "samsung,exynos5-hsi2c";
+   reg = <0x12ca 0x100>;
+   interrupts = <56>;
+   samsung,fs-clock-freq = <10>;
+   /* Samsung GPIO variant begins here */
+   gpios = < 2 0 /* SDA */
+ 3 0 /* SCL */>;
+   /* Samsung GPIO variant ends here */
+   /* Pinctrl variant begins here */
+   pinctrl-0 = <_bus>;
+   pinctrl-names = "default";
+   /* Pinctrl variant ends here */
+   #address-cells = <1>;
+   #size-cells = <0>;
+
+   s2mps11_pmic@66 {
+   compatible = "samsung,s2mps11-pmic";
+   reg = <0x66>;
+   };
+   };
diff --git a/drivers/i2c/busses/Kconfig b/drivers/i2c/busses/Kconfig
index a3725de..78b4936 100644
--- a/drivers/i2c/busses/Kconfig
+++ b/drivers/i2c/busses/Kconfig
@@ -434,6 +434,13 @@ config I2C_EG20T
  ML7213/ML7223/ML7831 is companion chip for Intel Atom E6xx series.
  ML7213/ML7223/ML7831 is completely compatible for Intel EG20T PCH.
 
+config I2C_EXYNOS5
+   tristate "Exynos5 high-speed I2C driver"
+   depends on ARCH_EXYNOS5 && OF
+   help
+ Say Y here to include support for High-speed I2C controller in the
+ Exynos5 based Samsung SoCs.
+
 config I2C_GPIO
tristate "GPIO-based bitbanging I2C"
depends on GENERIC_GPIO
diff --git a/drivers/i2c/busses/Makefile b/drivers/i2c/busses/Makefile
index 8f4fc23..b19366c 100644
--- a/drivers/i2c/busses/Makefile
+++ b/drivers/i2c/busses/Makefile
@@ -42,6 +42,7 @@ i2c-designware-platform-objs := i2c-designware-platdrv.o
 obj-$(CONFIG_I2C_DESIGNWARE_PCI)   += i2c-designware-pci.o
 i2c-designware-pci-objs := i2c-designware-pcidrv.o
 obj-$(CONFIG_I2C_EG20T)+= i2c-eg20t.o
+obj-$(CONFIG_I2C_EXYNOS5)  += i2c-exynos5.o
 obj-$(CONFIG_I2C_GPIO) += i2c-gpio.o
 obj-$(CONFIG_I2C_HIGHLANDER)   += i2c-highlander.o
 obj-$(CONFIG_I2C_IBM_IIC)  += i2c-ibm_iic.o
diff --git a/drivers/i2c/busses/i2c-exynos5.c b/drivers/i2c/busses/i2c-exynos5.c
new file mode 100644
index 000..fe30b0b
--- /dev/null
+++ b/drivers/i2c/busses/i2c-exynos5.c
@@ -0,0 +1,743 @@
+/**
+ * i2c-exynos5.c - Samsung Exynos5 I2C Controller Driver
+ *
+ * Copyright (C) 2013 Samsung Electronics Co., Ltd.
+ *
+ * This program is free software; you can redistribute 

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

[Stephen Rothwell]

Hi all,

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

drivers/input/serio/apbps2.c: In function 'apbps2_of_probe':
drivers/input/serio/apbps2.c:176:2: error: implicit declaration of function 
'kzalloc' [-Werror=implicit-function-declaration]
drivers/input/serio/apbps2.c:176:11: warning: assignment makes pointer from 
integer without a cast [enabled by default]

Caused by commit 928a48c9e40e ("Input: add support for GRLIB APBPS2 PS/2
Keyboard/Mouse") from the input tree.

I have reverted that commit for today.
-- 
Cheers,
Stephen Rothwells...@canb.auug.org.au


pgprbp4zC0Utu.pgp
Description: PGP signature

Re: [PATCH 4/9] mm: use mm_populate() for blocking remap_file_pages()

[Hillf Danton]

On Tue, Mar 12, 2013 at 8:24 AM, Michel Lespinasse  wrote:
> (Sorry for the late reply)
>
> On Mon, Mar 11, 2013 at 4:03 PM, Andrew Morton  
> wrote:
>> On Sun, 10 Mar 2013 20:55:21 +0200 Tommi Rantala  
>> wrote:
>>
>>> 2012/12/21 Michel Lespinasse :
>>> > Signed-off-by: Michel Lespinasse 
>>>
>>> Hello, this patch introduced the following bug, seen while fuzzing with 
>>> trinity:
>>>
>>> [  396.825414] BUG: unable to handle kernel NULL pointer dereference
>>> at 0050
>
> Good catch...
>
>> From: Andrew Morton 
>> Subject: mm/fremap.c: fix oops on error path
>>
>> If find_vma() fails, sys_remap_file_pages() will dereference `vma', which
>> contains NULL.  Fix it by checking the pointer.
>>
>> (We could alternatively check for err==0, but this seems more direct)
>>
>> (The vm_flags change is to squish a bogus used-uninitialised warning
>> without adding extra code).
>>
>> Reported-by: Tommi Rantala 
>> Cc: Michel Lespinasse 
>> Signed-off-by: Andrew Morton 
>> ---
>>
>>  mm/fremap.c |6 --
>>  1 file changed, 4 insertions(+), 2 deletions(-)
>>
>> diff -puN mm/fremap.c~mm-fremapc-fix-oops-on-error-path mm/fremap.c
>> --- a/mm/fremap.c~mm-fremapc-fix-oops-on-error-path
>> +++ a/mm/fremap.c
>> @@ -163,7 +163,8 @@ SYSCALL_DEFINE5(remap_file_pages, unsign
>>  * and that the remapped range is valid and fully within
>>  * the single existing vma.
>>  */
>> -   if (!vma || !(vma->vm_flags & VM_SHARED))
>> +   vm_flags = vma->vm_flags;
>> +   if (!vma || !(vm_flags & VM_SHARED))
>> goto out;
>
> Your commit message indicates the vm_flags load here doesn't generate any 
> code, but this seems very brittle and compiler dependent. If the compiler was 
> to generate an actual load here, the issue with vma == NULL would reappear.
>
>> if (!vma->vm_ops || !vma->vm_ops->remap_pages)
>> @@ -254,7 +255,8 @@ get_write_lock:
>>  */
>>
>>  out:
>> -   vm_flags = vma->vm_flags;
>> +   if (vma)
>> +   vm_flags = vma->vm_flags;
>> if (likely(!has_write_lock))
>> up_read(>mmap_sem);
>> else
>
>
>
> Would the following work ? I think it's simpler, and with the compiler
> I'm using here it doesn't emit warnings:
>
> diff --git a/mm/fremap.c b/mm/fremap.c
> index 0cd4c11488ed..329507e832fb 100644
> --- a/mm/fremap.c
> +++ b/mm/fremap.c
> @@ -254,7 +254,8 @@ get_write_lock:
>  */
>
>  out:
> -   vm_flags = vma->vm_flags;
> +   if (!err)
> +   vm_flags = vma->vm_flags;
> if (likely(!has_write_lock))
> up_read(>mmap_sem);
> else
>
Is it still necessary to populate mm if bail out due
to a linear mapping encountered?

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

linux-next: build failure after merge of the final tree (drm-intel tree related)

[Stephen Rothwell]

Hi all,

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

drivers/built-in.o: In function `i915_min_freq_set':
i915_debugfs.c:(.text+0xb1adc): undefined reference to `__udivdi3'
drivers/built-in.o: In function `i915_max_freq_set':
i915_debugfs.c:(.text+0xb1bac): undefined reference to `__udivdi3'

Caused by commit 2389cc500686 ("drm/i915: use simple attribute in debugfs
routines") from the drm-intel tree.

I have reverted that commit for today.
-- 
Cheers,
Stephen Rothwells...@canb.auug.org.au


pgpp7zZiwUhYB.pgp
Description: PGP signature

Re: linux-next: unneeded merge in the security tree

[Theodore Ts'o]

On Tue, Mar 12, 2013 at 03:10:53PM +1100, James Morris wrote:
> On Tue, 12 Mar 2013, Stephen Rothwell wrote:
> > The top commit in the security tree today is a merge of v3.9-rc2.  This
> > is a completely unnecessary merge as the tree before the merge was a
> > subset of v3.9-rc1 and so if the merge had been done using anything but
> > the tag, it would have just been a fast forward.  I know that this is now
> > deliberate behaviour on git's behalf, but isn't there some way we can
> > make this easier on maintainers who are just really just trying to pick a
> > new starting point for their trees after a release?  (at least I assume
> > that is what James was trying to do)
> 
> Yes, and I was merging to a tag as required by Linus.

Why not just force the head of the security tree to be v3.9-rc2?  Then
you don't end up creating a completely unnecessary merge commit, and
users who were at the previous head of the security tree will
experience a fast forward when they pull your new head.

  - Ted
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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: FW: Regulator API ignored return values

[Kevin Liu]

> -Original Message-
> From: linux-mmc-ow...@vger.kernel.org 
> [mailto:linux-mmc-ow...@vger.kernel.org] On Behalf Of Chris Ball
> Sent: Tuesday, March 12, 2013 5:56 AM
> To: Arnd Bergmann
> Cc: linux-kernel@vger.kernel.org; Stephen Warren; 
> linux-arm-ker...@lists.infradead.org; Mark Brown; Linus Walleij; Axel Lin; 
> Jingoo Han; Felipe Balbi; Dmitry Torokhov; linux-...@vger.kernel.org
> Subject: Re: Regulator API ignored return values
>
> Hi,
>
> On Mon, Mar 11 2013, Arnd Bergmann wrote:
>> ==> build/dove_defconfig/faillog <==
>> /git/arm-soc/drivers/mmc/host/sdhci.c: In function 'sdhci_add_host':
>> /git/arm-soc/drivers/mmc/host/sdhci.c:2910:19: warning: ignoring
>> return value of 'regulator_enable', declared with attribute
>> warn_unused_result [-Wunused-result]
>
> Thanks, this looks like the right fix to me:
>
>
> Subject: [PATCH] mmc: sdhci: Don't ignore regulator_enable() return value
>
> Fixes:
> /git/arm-soc/drivers/mmc/host/sdhci.c: In function 'sdhci_add_host':
> /git/arm-soc/drivers/mmc/host/sdhci.c:2910:19: warning: ignoring
> return value of 'regulator_enable', declared with attribute
> warn_unused_result [-Wunused-result]
>
> Reported-by: Arnd Bergmann 
> Signed-off-by: Chris Ball 
> ---
>  drivers/mmc/host/sdhci.c | 7 ++-
>  1 file changed, 6 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/mmc/host/sdhci.c b/drivers/mmc/host/sdhci.c
> index 51bbba4..fbf0b93 100644
> --- a/drivers/mmc/host/sdhci.c
> +++ b/drivers/mmc/host/sdhci.c
> @@ -2907,12 +2907,17 @@ int sdhci_add_host(struct sdhci_host *host)
> host->vqmmc = NULL;
> }
> } else {
> -   regulator_enable(host->vqmmc);
> +   ret = regulator_enable(host->vqmmc);
> if (!regulator_is_supported_voltage(host->vqmmc, 170,
> 195))
> caps[1] &= ~(SDHCI_SUPPORT_SDR104 |
> SDHCI_SUPPORT_SDR50 |
> SDHCI_SUPPORT_DDR50);
> +   if (ret) {
> +   pr_warn("%s: Failed to enable vqmmc regulator: %d\n",
> +   mmc_hostname(mmc), ret);

Need add regulator_put here since regulator_get has succeed?

> +   host->vqmmc = NULL;
> +   }
> }
>
> if (host->quirks2 & SDHCI_QUIRK2_NO_1_8_V)
> --
> Chris Ball  
> One Laptop Per Child
> --
> To unsubscribe from this list: send the line "unsubscribe linux-mmc" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] drivers: gpu: drm: exynos: Replaced kzalloc & memcpy with kmemdup

[Inki Dae]

Applied.

Thanks,
Inki Dae

2013/3/12 Alexandru Gheorghiu :
> Replaced calls to kzalloc followed by memcpy with call to kmemdup.
> Patch found using coccinelle.
>
> Signed-off-by: Alexandru Gheorghiu 
> ---
>  drivers/gpu/drm/exynos/exynos_drm_vidi.c |6 ++
>  1 file changed, 2 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/gpu/drm/exynos/exynos_drm_vidi.c 
> b/drivers/gpu/drm/exynos/exynos_drm_vidi.c
> index 13ccbd4..9504b0c 100644
> --- a/drivers/gpu/drm/exynos/exynos_drm_vidi.c
> +++ b/drivers/gpu/drm/exynos/exynos_drm_vidi.c
> @@ -117,13 +117,12 @@ static struct edid *vidi_get_edid(struct device *dev,
> }
>
> edid_len = (1 + ctx->raw_edid->extensions) * EDID_LENGTH;
> -   edid = kzalloc(edid_len, GFP_KERNEL);
> +   edid = kmemdup(ctx->raw_edid, edid_len, GFP_KERNEL);
> if (!edid) {
> DRM_DEBUG_KMS("failed to allocate edid\n");
> return ERR_PTR(-ENOMEM);
> }
>
> -   memcpy(edid, ctx->raw_edid, edid_len);
> return edid;
>  }
>
> @@ -563,12 +562,11 @@ int vidi_connection_ioctl(struct drm_device *drm_dev, 
> void *data,
> return -EINVAL;
> }
> edid_len = (1 + raw_edid->extensions) * EDID_LENGTH;
> -   ctx->raw_edid = kzalloc(edid_len, GFP_KERNEL);
> +   ctx->raw_edid = kmemdup(raw_edid, edid_len, GFP_KERNEL);
> if (!ctx->raw_edid) {
> DRM_DEBUG_KMS("failed to allocate raw_edid.\n");
> return -ENOMEM;
> }
> -   memcpy(ctx->raw_edid, raw_edid, edid_len);
> } else {
> /*
>  * with connection = 0, free raw_edid
> --
> 1.7.9.5
>
> ___
> dri-devel mailing list
> dri-de...@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: linux-next: unneeded merge in the security tree

[James Morris]

On Tue, 12 Mar 2013, Stephen Rothwell wrote:

> Hi all,
> 
> [James, I am not picking on you, just using your tree to illustrate a
> point.]
> 
> The top commit in the security tree today is a merge of v3.9-rc2.  This
> is a completely unnecessary merge as the tree before the merge was a
> subset of v3.9-rc1 and so if the merge had been done using anything but
> the tag, it would have just been a fast forward.  I know that this is now
> deliberate behaviour on git's behalf, but isn't there some way we can
> make this easier on maintainers who are just really just trying to pick a
> new starting point for their trees after a release?  (at least I assume
> that is what James was trying to do)

Yes, and I was merging to a tag as required by Linus.


-- 
James Morris

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] KEYS: Fix race with concurrent install_user_keyrings()

[James Morris]

On Mon, 11 Mar 2013, Greg KH wrote:

> On Thu, Mar 07, 2013 at 03:59:09PM +1100, James Morris wrote:
> > On Wed, 6 Mar 2013, David Howells wrote:
> > 
> > > Reported-by: Mateusz Guzik 
> > > Signed-off-by: David Howells 
> > 
> > Acked-by: James Morris 
> 
> What happened to this patch?  I don't see it in Linus's tree, James, did
> you pick it up?

I'll push it to Linus.


-- 
James Morris

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] atomic: improve atomic_inc_unless_negative/atomic_dec_unless_positive

[Ming Lei]

On Tue, Mar 12, 2013 at 11:39 AM, Paul E. McKenney
 wrote:
>
> Atomic operations that return a value are required to act as full memory
> barriers.  This means that code relying on ordering provided by these
> atomic operations must also do ordering, either by using an explicit
> memory barrier or by relying on guarantees from atomic operations.
>
> For example:
>
> CPU 0   CPU 1
>
> X = 1;  r1 = Z;
> if (atomic_inc_unless_negative()  smp_mb();
> do_something();
> Z = 1;  r2 = X;
>
> Assuming X and Z are initially zero, if r1==1, we are guaranteed
> that r2==1.  However, CPU 1 needs its smp_mb() in order to pair with
> the barrier implicit in atomic_inc_unless_negative().
>
> Make sense?

Yes, it does, and thanks for the explanation.

But looks the above example is not what Frederic described:

"the above atomic_read() might return -1 because there is no
guarantee it's seeing the recent update on the remote CPU."

Even I am not sure if adding one smp_mb() around atomic_read()
can guarantee that too.

Andrew, please ignore the patch, thanks.

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/

[PATCH v4 1/4] x86: Add cpu capability flag X86_FEATURE_NONSTOP_TSC_S3

[Feng Tang]

On some new Intel Atom processors (Penwell and Cloverview), there is
a feature that the TSC won't stop in S3 state, say the TSC value
won't be reset to 0 after resume. This feature makes TSC a more reliable
clocksource and could benefit the timekeeping code during system
suspend/resume cycle, so add a flag for it.

Signed-off-by: Feng Tang 
---
 arch/x86/include/asm/cpufeature.h |1 +
 arch/x86/kernel/cpu/intel.c   |   12 
 2 files changed, 13 insertions(+)

diff --git a/arch/x86/include/asm/cpufeature.h 
b/arch/x86/include/asm/cpufeature.h
index 93fe929..a8466f2 100644
--- a/arch/x86/include/asm/cpufeature.h
+++ b/arch/x86/include/asm/cpufeature.h
@@ -100,6 +100,7 @@
 #define X86_FEATURE_AMD_DCM (3*32+27) /* multi-node processor */
 #define X86_FEATURE_APERFMPERF (3*32+28) /* APERFMPERF */
 #define X86_FEATURE_EAGER_FPU  (3*32+29) /* "eagerfpu" Non lazy FPU restore */
+#define X86_FEATURE_NONSTOP_TSC_S3 (3*32+30) /* TSC doesn't stop in S3 state */
 
 /* Intel-defined CPU features, CPUID level 0x0001 (ecx), word 4 */
 #define X86_FEATURE_XMM3   (4*32+ 0) /* "pni" SSE-3 */
diff --git a/arch/x86/kernel/cpu/intel.c b/arch/x86/kernel/cpu/intel.c
index 1905ce9..fe57544 100644
--- a/arch/x86/kernel/cpu/intel.c
+++ b/arch/x86/kernel/cpu/intel.c
@@ -96,6 +96,18 @@ static void __cpuinit early_init_intel(struct cpuinfo_x86 *c)
sched_clock_stable = 1;
}
 
+   /* Penwell and Cloverview have the TSC which doesn't sleep on S3 */
+   if (c->x86 == 6) {
+   switch (c->x86_model) {
+   case 0x27:  /* Penwell */
+   case 0x35:  /* Cloverview */
+   set_cpu_cap(c, X86_FEATURE_NONSTOP_TSC_S3);
+   break;
+   default:
+   ;
+   }
+   }
+
/*
 * There is a known erratum on Pentium III and Core Solo
 * and Core Duo CPUs.
-- 
1.7.9.5

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

[PATCH v4 4/4] timekeeping: utilize the suspend-nonstop clocksource to count suspended time

[Feng Tang]

There are some new processors whose TSC clocksource won't stop during
suspend. Currently, after system resumes, kernel will use persistent
clock or RTC to compensate the sleep time, but with these nonstop
clocksources, we could skip the special compensation from external
sources, and just use current clocksource for time recounting.

This can solve some time drift bugs caused by some not-so-accurate or
error-prone RTC devices.

The current way to count suspended time is first try to use the persistent
clock, and then try the RTC if persistent clock can't be used. This
patch will change the trying order to:
suspend-nonstop clocksource -> persistent clock -> RTC

When counting the sleep time with nonstop clocksource, use an accurate way
suggested by Jason Gunthorpe to cover very large delta cycles.

Signed-off-by: Feng Tang 
---
 kernel/time/timekeeping.c |   58 +++--
 1 file changed, 51 insertions(+), 7 deletions(-)

diff --git a/kernel/time/timekeeping.c b/kernel/time/timekeeping.c
index 9a0bc98..6d7ea93 100644
--- a/kernel/time/timekeeping.c
+++ b/kernel/time/timekeeping.c
@@ -788,22 +788,66 @@ void timekeeping_inject_sleeptime(struct timespec *delta)
 static void timekeeping_resume(void)
 {
struct timekeeper *tk = 
+   struct clocksource *clock = tk->clock;
unsigned long flags;
-   struct timespec ts;
+   struct timespec ts_new, ts_delta;
+   cycle_t cycle_now, cycle_delta;
+   bool suspendtime_found = false;
 
-   read_persistent_clock();
+   read_persistent_clock(_new);
 
clockevents_resume();
clocksource_resume();
 
write_seqlock_irqsave(>lock, flags);
 
-   if (timespec_compare(, _suspend_time) > 0) {
-   ts = timespec_sub(ts, timekeeping_suspend_time);
-   __timekeeping_inject_sleeptime(tk, );
+   /*
+* After system resumes, we need to calculate the suspended time and
+* compensate it for the OS time. There are 3 sources that could be
+* used: Nonstop clocksource during suspend, persistent clock and rtc
+* device.
+*
+* One specific platform may have 1 or 2 or all of them, and the
+* preference will be:
+*  suspend-nonstop clocksource -> persistent clock -> rtc
+* The less preferred source will only be tried if there is no better
+* usable source. The rtc part is handled separately in rtc core code.
+*/
+   cycle_now = clock->read(clock);
+   if ((clock->flags & CLOCK_SOURCE_SUSPEND_NONSTOP) &&
+   cycle_now > clock->cycle_last) {
+   u64 num, max = ULLONG_MAX;
+   u32 mult = clock->mult;
+   u32 shift = clock->shift;
+   s64 nsec = 0;
+
+   cycle_delta = (cycle_now - clock->cycle_last) & clock->mask;
+
+   /*
+* "cycle_delta * mutl" may cause 64 bits overflow, if the
+* suspended time is too long. In that case we need do the
+* 64 bits math carefully
+*/
+   do_div(max, mult);
+   if (cycle_delta > max) {
+   num = div64_u64(cycle_delta, max);
+   nsec = (((u64) max * mult) >> shift) * num;
+   cycle_delta -= num * max;
+   }
+   nsec += ((u64) cycle_delta * mult) >> shift;
+
+   ts_delta = ns_to_timespec(nsec);
+   suspendtime_found = true;
+   } else if (timespec_compare(_new, _suspend_time) > 0) {
+   ts_delta = timespec_sub(ts_new, timekeeping_suspend_time);
+   suspendtime_found = true;
}
-   /* re-base the last cycle value */
-   tk->clock->cycle_last = tk->clock->read(tk->clock);
+
+   if (suspendtime_found)
+   __timekeeping_inject_sleeptime(tk, _delta);
+
+   /* Re-base the last cycle value */
+   clock->cycle_last = clock->read(clock);
tk->ntp_error = 0;
timekeeping_suspended = 0;
timekeeping_update(tk, false);
-- 
1.7.9.5

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

[PATCH v4 3/4] x86: tsc: Add support for new S3_NONSTOP feature

[Feng Tang]

Signed-off-by: Feng Tang 
---
 arch/x86/kernel/tsc.c |6 +-
 1 file changed, 5 insertions(+), 1 deletion(-)

diff --git a/arch/x86/kernel/tsc.c b/arch/x86/kernel/tsc.c
index 4b9ea10..098b3cf 100644
--- a/arch/x86/kernel/tsc.c
+++ b/arch/x86/kernel/tsc.c
@@ -768,7 +768,8 @@ static cycle_t read_tsc(struct clocksource *cs)
 
 static void resume_tsc(struct clocksource *cs)
 {
-   clocksource_tsc.cycle_last = 0;
+   if (!boot_cpu_has(X86_FEATURE_NONSTOP_TSC_S3))
+   clocksource_tsc.cycle_last = 0;
 }
 
 static struct clocksource clocksource_tsc = {
@@ -939,6 +940,9 @@ static int __init init_tsc_clocksource(void)
clocksource_tsc.flags &= ~CLOCK_SOURCE_IS_CONTINUOUS;
}
 
+   if (boot_cpu_has(X86_FEATURE_NONSTOP_TSC_S3))
+   clocksource_tsc.flags |= CLOCK_SOURCE_SUSPEND_NONSTOP;
+
/*
 * Trust the results of the earlier calibration on systems
 * exporting a reliable TSC.
-- 
1.7.9.5

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

[PATCH v4 2/4] clocksource: Add new feature flag CLOCK_SOURCE_SUSPEND_NONSTOP

[Feng Tang]

Some x86 processors have a TSC clocksource, which continues to run
even when system is suspended. Also most OMAP platforms have a
32 KHz timer which has similar capability. Add a feature flag so that
it could be utilized.

Signed-off-by: Feng Tang 
---
 include/linux/clocksource.h |1 +
 1 file changed, 1 insertion(+)

diff --git a/include/linux/clocksource.h b/include/linux/clocksource.h
index 27cfda4..aa7032c 100644
--- a/include/linux/clocksource.h
+++ b/include/linux/clocksource.h
@@ -206,6 +206,7 @@ struct clocksource {
 #define CLOCK_SOURCE_WATCHDOG  0x10
 #define CLOCK_SOURCE_VALID_FOR_HRES0x20
 #define CLOCK_SOURCE_UNSTABLE  0x40
+#define CLOCK_SOURCE_SUSPEND_NONSTOP   0x80
 
 /* simplify initialization of mask field */
 #define CLOCKSOURCE_MASK(bits) (cycle_t)((bits) < 64 ? ((1ULL<<(bits))-1) : -1)
-- 
1.7.9.5

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

[PATCH v4 0/4] Add support for S3 non-stop TSC support.

[Feng Tang]

Hi All,

On some new Intel Atom processors (Penwell and Cloverview), there is
a feature that the TSC won't stop in S3, say the TSC value won't be
reset to 0 after resume. This feature makes TSC a more reliable
clocksource and could benefit the timekeeping code during system
suspend/resume cycles.

The enabling efforts include adding new flags for this feature, 
modifying clocksource.h and timekeeping.c to support and utilizing
it.

The major change to timekeeping is the way to count suspended time,
current way is trying to use the persistent clock first, and then
try the rtc if persistent clock can't do it. This patch will change
the trying order to:
suspend-nonstop clocksource -> persistent clock -> rtc

Please help to review them, thanks a lot!

Changelog:
v4:
* Don't touch clocksource_cyc2ns() API which is under
  changes
* add an explicit flag for if the suspend time has been
  calculated by nonstop clocksource or persistent clock 
v3:
* Adopt Jason Gunthorpe's way to convert large cycles to
  nsec. And put it into clocksource_cyc2ns()
* Small change in flag name
v2:
* Dump the code changing a clocksource's mult and shit,
  as suggested by John to not hurt accuracy
* Modify the CPU feature flag name to be consistent with
  other flags
* Solve the problem of judging S3/S4, as the clocksource
  counter will be reset after coming out S4.

- Feng

-

Feng Tang (4):
  x86: Add cpu capability flag X86_FEATURE_NONSTOP_TSC_S3
  clocksource: Add new feature flag CLOCK_SOURCE_SUSPEND_NONSTOP
  x86: tsc: Add support for new S3_NONSTOP feature
  timekeeping: utilize the suspend-nonstop clocksource to count
suspended time

 arch/x86/include/asm/cpufeature.h |1 +
 arch/x86/kernel/cpu/intel.c   |   12 
 arch/x86/kernel/tsc.c |6 +++-
 include/linux/clocksource.h   |1 +
 kernel/time/timekeeping.c |   58 -
 5 files changed, 70 insertions(+), 8 deletions(-)

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

linux-next: manual merge of the akpm tree with the arm-soc tree

[Stephen Rothwell]

Hi Andrew,

Today's linux-next merge of the akpm tree got a conflict in
drivers/rtc/rtc-mv.c between commit 89c58c198b25 ("rtc: rtc-mv: Add
support for clk to avoid lockups") from the arm-soc tree and commit "rtc:
rtc-mv: use devm_rtc_device_register()" from the akpm tree.

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

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

diff --cc drivers/rtc/rtc-mv.c
index f378e17,1ee8551..000
--- a/drivers/rtc/rtc-mv.c
+++ b/drivers/rtc/rtc-mv.c
@@@ -272,16 -262,15 +272,17 @@@ static int __init mv_rtc_probe(struct p
  
if (pdata->irq >= 0) {
device_init_wakeup(>dev, 1);
-   pdata->rtc = rtc_device_register(pdev->name, >dev,
+   pdata->rtc = devm_rtc_device_register(>dev, pdev->name,
 _rtc_alarm_ops,
 THIS_MODULE);
-   } else
-   pdata->rtc = rtc_device_register(pdev->name, >dev,
+   } else {
+   pdata->rtc = devm_rtc_device_register(>dev, pdev->name,
 _rtc_ops, THIS_MODULE);
+   }
 -  if (IS_ERR(pdata->rtc))
 -  return PTR_ERR(pdata->rtc);
 +  if (IS_ERR(pdata->rtc)) {
 +  ret = PTR_ERR(pdata->rtc);
 +  goto out;
 +  }
  
if (pdata->irq >= 0) {
writel(0, pdata->ioaddr + RTC_ALARM_INTERRUPT_MASK_REG_OFFS);
@@@ -308,10 -292,6 +309,9 @@@ static int __exit mv_rtc_remove(struct 
if (pdata->irq >= 0)
device_init_wakeup(>dev, 0);
  
-   rtc_device_unregister(pdata->rtc);
 +  if (!IS_ERR(pdata->clk))
 +  clk_disable_unprepare(pdata->clk);
 +
return 0;
  }
  


pgp1d1e7ZaDp0.pgp
Description: PGP signature

Re: torrent hash failures since 3.9.0-rc1

[Theodore Ts'o]

On Mon, Mar 11, 2013 at 11:30:54PM -0400, Theodore Ts'o wrote:
> > As Ted suggested, could you please try to use ext4 git tree?  I want to
> > make sure whether this bug has been fixed by my lastest patch series or
> > not.
> 
> It's definitely worth a try to compile the master branch of the ext4
> tree and see if it reproduces or not.

Sorry, what you should try is the dev branch of the ext4 tree.  That
has the new patches that we are currently QA'ing for 3.9-rc3
(hopefully).

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

compat-drivers based on v3.9-rc2

[Luis R. Rodriguez]

I've kicked out compat-drivers releases based on v3.9-rc2 [0], be sure
to use the temporary release page [1] while we get one in place on
kernel.org. We are on rc2 now... please test and report any issues!
Please submit your patches for anything you think is critical but not
'stable' material for inclusion of those patches into their respective
directory, if unclear please read the additional-patches documentation
[2]. This should allow us developers to focus on convincing PHBs to
always work upstream without having them to persuade their own
'private' releases to customers / your mom that typically do carry
these patches but they never get merged back upstream.

[0] https://www.kernel.org/pub/linux/kernel/projects/backports/stable/v3.9-rc2/
[1] http://drvbp1.linux-foundation.org/~mcgrof/rel-html/compat-drivers/
[2] 
https://backports.wiki.kernel.org/index.php/Documentation/compat-drivers/additional-patches

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

Re: [PATCH linux-next v3] SUNRPC: rpcrdma_register_default_external: Dynamically allocate ib_phys_buf

[Tom Tucker]

AhOk

On 3/11/13 9:53 PM, Tim Gardner wrote:

On 03/11/2013 05:02 PM, Tom Tucker wrote:

On 3/11/13 4:25 PM, J. Bruce Fields wrote:





Looks good to me; wish we could get it tested


I will test it. Tim could you please send me a final version that you'd
like tested as a single message?



I'm a little confused about what you are asking. I think v3 of the patch 
is the final version (unless you find bugs with it).



Would someone (like Tim maybe ... hint hint) look at tearing out all
those dead registration strategies? I don't think we need or will ever
use bounce-buffers, memory windows, or mlnx fmr.  The only two that are
used and tested are all-phys and FRMR (the default).



Dunno if I'll get time for that. I had a one day window where I could 
hack out some simple patches. Now I'm back to the usual grindstone.


rtg


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] atomic: improve atomic_inc_unless_negative/atomic_dec_unless_positive

[Paul E. McKenney]

On Tue, Mar 12, 2013 at 10:15:42AM +0800, Ming Lei wrote:
> On Tue, Mar 12, 2013 at 7:59 AM, Frederic Weisbecker  
> wrote:
> > 2013/3/9 Ming Lei :
> >> Generally, both atomic_inc_unless_negative() and
> >> atomic_dec_unless_positive() need at least two atomic_cmpxchg()
> >> to complete the atomic operation. In fact, the 1st atomic_cmpxchg()
> >> is just used to read current value of the atomic variable at most times.
> >>
> >> Considered memory barrier, bus lock, cache walking, etc. things may be
> >> involved in atomic_cmpxchg(), it is much expensive than atomic_read(),
> >> which is just the simple below:
> >>
> >> (*(volatile int *)&(v)->counter)
> >>
> >> so this patch can save one extra atomic_cmpxchg() for the two
> >> helpers under general situation, and should improve them a bit.
> >>
> >> Cc: Andrew Morton 
> >> Cc: Shaohua Li 
> >> Cc: Al Viro 
> >> Signed-off-by: Ming Lei 
> >> ---
> >>  include/linux/atomic.h |   28 ++--
> >>  1 file changed, 18 insertions(+), 10 deletions(-)
> >>
> >> diff --git a/include/linux/atomic.h b/include/linux/atomic.h
> >> index 5b08a85..aa951d8 100644
> >> --- a/include/linux/atomic.h
> >> +++ b/include/linux/atomic.h
> >> @@ -63,26 +63,34 @@ static inline int atomic_inc_not_zero_hint(atomic_t 
> >> *v, int hint)
> >>  #ifndef atomic_inc_unless_negative
> >>  static inline int atomic_inc_unless_negative(atomic_t *p)
> >>  {
> >> -   int v, v1;
> >> -   for (v = 0; v >= 0; v = v1) {
> >> -   v1 = atomic_cmpxchg(p, v, v + 1);
> >> -   if (likely(v1 == v))
> >> +   int v, t;
> >> +
> >> +   v = atomic_read(p);
> >> +   while (1) {
> >> +   if (unlikely(v < 0))
> >> +   return 0;
> >
> > But atomic_read() lacks the full memory barrier that is needed for
> > proper atomicity here.
> >
> > For example if the initial value of p is -1 and another CPU just did
> > an atomic_inc() that resulted in the new value to be 0, the above
> > atomic_read() might return -1 because there is no guarantee it's
> > seeing the recent update on the remote CPU.
> 
> Yes, you are right. Also looks memory barrier is needed around
> atomic_inc() too.

The atomic_inc() primitive makes no guarantees about ordering (see
Documentation/atomic_ops.txt), so, yes, if the caller needs ordering
around an atomic_inc(), the caller must supply the needed memory
barriers, for example, by using smp_mb__before_atomic_inc() or
smp_mb__after_atomic_inc().

> But I have a question, why a memory barrier can guarantee that
> remote CPU can see the recent update?  I understand that memory
> barrier only orders consecutive memory access, and but here
> not see this kind of pattern. Sorry for a possibly stupid question.

Atomic operations that return a value are required to act as full memory
barriers.  This means that code relying on ordering provided by these
atomic operations must also do ordering, either by using an explicit
memory barrier or by relying on guarantees from atomic operations.

For example:

CPU 0   CPU 1

X = 1;  r1 = Z;
if (atomic_inc_unless_negative()  smp_mb();
do_something();
Z = 1;  r2 = X;

Assuming X and Z are initially zero, if r1==1, we are guaranteed
that r2==1.  However, CPU 1 needs its smp_mb() in order to pair with
the barrier implicit in atomic_inc_unless_negative().

Make sense?

Thanx, Paul

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

compat-drivers v3.8.2 release

[Luis R. Rodriguez]

compat-drivers gets a series of v3.8.2 based releases kicked out [0].
Below is the ChangeLog relevant to the backport effort, thanks to
everyone who contributed! For the full ChangeLog that includes all
kernel components updated refer to the upstream file [1]. Be sure to
use the new release page for now [2]. Interesting to note was there
are a slew of pending-stable patches not yet merged into linux-3.8.y
for the networking subsystem but nothing for DRM, we get these merged
in on the -s releases, as a short cut, instead of having to wait for
them to be merged.

[0] https://www.kernel.org/pub/linux/kernel/projects/backports/stable/v3.8.2/
[1] 
https://www.kernel.org/pub/linux/kernel/projects/backports/stable/v3.8.2/ChangeLog-3.8.2-2
[2] http://drvbp1.linux-foundation.org/~mcgrof/rel-html/compat-drivers/

  Luis


ChangeLog for compat-drivers-v3.8.2-2 based on linux-3.8.2


This is the ChangeLog for the Linux kernel project compat-drivers.
It provides a backport of a few Linux kernel subsystems down to
older kernels:

  * 802.11
  * Bluetooth
  * Ethernet
  * DRM

For more details refer to the home pages:

https://backports.wiki.kernel.org

The compat-drivers project consists of code from three projects:

  * The Linux kernel: linux-stable.git
  * Compat-wirelesS: compat-drivers.git
  * Compat: compat.git

The compat-drivers stable releases incorporates code from from
each of these git trees for the respective upstream Linux kernel
stable release. A branch called linux-3.x.y exists for each
stable release. Below we provide the ChangeLog of changes from
the previous branched release to the new branched release.

Release: linux-3.8


Updates from the compat.git project:


git shortlog linux-3.7.y..linux-3.8.y

Felix Fietkau (1):
  compat: fix compile errors when assembly is built into modules

Hauke Mehrtens (21):
  compat: update list of kernel headers
  compat: add USB_SUBCLASS_VENDOR_SPEC
  compat: make compat load without CONFIG_CPU_FREQ
  compat: add eth_zero_addr()
  compat: add kref_get_unless_zero()
  compat: move config_enabled to compat-3.4.h
  compat: fix compiler warning in nla_get_s64()
  compat: export platform_device_register_data()
  compat: fix warning of missing struct netdev_queue
  compat: add missing return value to netif_set_real_num_tx_queues
  compat: add simple_write_to_buffer
  compat: add ETHTOOL_FWVERS_LEN
  compat: fix warning in usb_autopm_get_interface_no_{resume,suspend}
  compat: do not access default_ethtool_ops
  compat: ckmake: make return code 2 is error
  compat: ckmake: remove lots of warning spam for the log
  compat: ckmake: do not start all build at the same time
  compat: add efi_enabled()
  compat: netdev_set_default_ethtool_ops() is not in kernel 3.7.5
  compat: check if efi_enabled() was already backported
  compat: deactivate netdev_set_default_ethtool_ops() for some 3.7 kernels

Johannes Berg (1):
  compat: backport unsigned netlink attribute accessors

Luis R. Rodriguez (41):
  compat: fix libc dependency on bin/get-compat-kernels
  compat: fix typo in bin/get-compat-kernels
  compat: run ckmake with num cpu threads
  compat: fix get-compat-kernels for libc issue again
  compat: change count to 4 for glibc kernel fix
  compat: add gpio header for kernels older than 2.6.24
  compat: backport ethtool_rxfh_indir_default()
  compat: backport ethtool to mii advertisment conversion helpers
  compat: backport BQL helpers
  compat: define NETIF_F_RXCSUM
  compat: fix addition of NETIF_F_RXCSUM
  compat: backport PCI MSI-X entry definitions
  compat: backport alloc_etherdev_mqs()
  compat: backport definition of PCI_MSIX_ENTRY_CTRL_MASKBIT
  compat: backport PTR_RET()
  compat: backport netif_set_real_num_tx_queues()
  compat: backport netif_set_real_num_rx_queues()
  compat: rename MDIO exported symbols
  compat: backplane mode negotiation ethtool definitions
  compat: backport napi_gro_receive()
  compat: generate CONFIG_COMPAT_KERNEL_3_8
  compat: backport hid_ignore()
  compat: backport PCI_EXP_LNKCTL_ASPM_L0S and PCI_EXP_LNKCTL_ASPM_L1
  compat: backport definition of HID_TYPE_USBNONE
  compat: add HID_QUIRK_HIDDEV_FORCE and HID_QUIRK_NO_IGNORE
  compat: add HID_QUIRK_IGNORE
  compat: backport HID_USB_DEVICE() and HID_BLUETOOTH_DEVICE()
  compat: backport struct hid_device_id
  compat: fix compilation on hid_ignore()
  compat: backport platform_device_register_data()
  compat: adjust get-compat-kernels for root usage
  compat: adjust get-compat-kernels for root users
  compat: add v3.7 to get-compat-kernels
  compat: add support for forcing get-compat-kernels
  compat: fix 

Re: torrent hash failures since 3.9.0-rc1

[Theodore Ts'o]

On Tue, Mar 12, 2013 at 11:00:58AM +0800, Zheng Liu wrote:
> 
> Thanks for reporting this problem.  My deepest apologies.
> 
> As Ted suggested, could you please try to use ext4 git tree?  I want to
> make sure whether this bug has been fixed by my lastest patch series or
> not.

It's definitely worth a try to compile the master branch of the ext4
tree and see if it reproduces or not.

However, I suspect the problem will still be there.  Based on the
commit which Markus has identified, I'm guessing it's a race between
the extents_status shrinker and writing into uninitialized region of
the file (since apprently compiling rtorrent with
--with-posix-fallocate is required).

Markus, how much memory do you have in your system?  That may be the
other reason why I haven't been able to reproduce it to date; I had a
lot of free memory when I tried to reproduce the problem, so the slab
shrinker didn't engage.

Regards,

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

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

[Stephen Rothwell]

Hi Al,

Today's linux-next merge of the signal tree got a conflict in
arch/tile/kernel/compat.c between commit 87c319a2c3c2 ("tile: properly
use COMPAT_SYSCALL_DEFINEx") from Linus' tree and commit d5dc77bfeeab
("consolidate compat lookup_dcookie()") from the signal tree.

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

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

diff --cc arch/tile/kernel/compat.c
index 6ea4cdb,c262a02..000
--- a/arch/tile/kernel/compat.c
+++ b/arch/tile/kernel/compat.c
@@@ -56,15 -54,9 +56,9 @@@ COMPAT_SYSCALL_DEFINE6(pwrite64, unsign
return sys_pwrite64(fd, ubuf, count, ((loff_t)high << 32) | low);
  }
  
- COMPAT_SYSCALL_DEFINE4(lookup_dcookie, u32, low, u32, high,
-char __user *, buf, size_t, len)
- {
-   return sys_lookup_dcookie(((loff_t)high << 32) | low, buf, len);
- }
- 
 -long compat_sys_sync_file_range2(int fd, unsigned int flags,
 -   u32 offset_lo, u32 offset_hi,
 -   u32 nbytes_lo, u32 nbytes_hi)
 +COMPAT_SYSCALL_DEFINE6(sync_file_range2, int, fd, unsigned int, flags,
 +   u32, offset_lo, u32, offset_hi,
 +   u32, nbytes_lo, u32, nbytes_hi)
  {
return sys_sync_file_range(fd, ((loff_t)offset_hi << 32) | offset_lo,
   ((loff_t)nbytes_hi << 32) | nbytes_lo,


pgp3hv4GT28Xc.pgp
Description: PGP signature

Regression with orderly_poweroff()

[Benjamin Herrenschmidt]

Hi Linus !

A couple of weeks ago, David sent an email that went unanswered about a
regression concerning orderly_poweroff(). I think the original patch
causing it should be reverted, here's the actual email with the
explanation:

<<<
Subject: orderly_poweroff() is no longer safe in atomic context

Commit 6c0c0d4d1080840eabb3d055d2fd8191c5fd "poweroff: fix bug in
orderly_poweroff()" apparently fixes one bug in orderly_poweroff(),
but introduces another.  The comments on orderly_poweroff() claim it
can be called from any context - and indeed we call it from interrupt
context in arch/powerpc/platforms/pseries/ras.c for example.  But
since that commit this is no longer safe, since
call_usermodehelper_fns() is not safe in interrupt context without the
UMH_NO_WAIT option.

I'm having trouble understanding the commit message to see what the
original bug being fixed was.  Specifically I can't make sense of:

  |  The bug here is, step 1 is always successful with param
  |  UMH_NO_WAIT, which obey the design goal of orderly_poweroff.

And without understanding the original bug, I'm not sure what the
correct fix is.
>>>

Cheers,
Ben.


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

[Michael Wang]

On 03/11/2013 06:36 PM, Peter Zijlstra wrote:
> On Fri, 2013-03-08 at 10:50 +0800, Michael Wang wrote:
> 
>>> OK, so there's two issues I have with all this are:
>>>
>>>  - it completely wrecks task placement for things like interrupts (sadly I 
>>> don't
>>>  have a good idea about a benchmark where this matters).
>>
>> I don't get this point...could you please give more details?
> 
> Take for instance a network workload, the hardirq notifies us there's
> data buffered, then softirq does a ton of network layer demuxing and
> eventually wakes one (or more) tasks to process data. You want these
> tasks to move to the waking cpu, it has lots of this data in cache.
> 
> Now, neither hard- nor softirq runs in task context (except for -rt) so
> it completely fails on what you propose.

I got it, exactly, the new feature with current ref limit will miss this
optimize timing, if the data not related to current...

However, we are still gambling here, and some workload suffered.

Actually this feature's purpose is to provide a way for user who want to
balance the risk and benefit on self demand, it providing flexible, not
restriction...

So what about make the default sysctl_sched_wakeup_buddy_ref to be 0 and
make every thing just like the old world.

And for those who want to make the decision more carefully, they could
turn the knob to make it bigger, and gain the benefit.

> 
> We could simply add something like in_softirq() || in_irq() etc.. to
> re-enable wake_affine() for those cases unconditionally, but not sure
> that's the right thing either.
> 
>>>  - yet another random number.. :/
>>
>> Correct...well, but that also means flexibility, I suppose different
>> system and workload will need some tuning on this knob to gain more
>> benefit, by default, they will gain some benefit, small or big.
> 
> Nah, it just means another knob nobody knows how to twiddle.

Right, and we already have many such kind of knob...since some formular
is impossible to be written down.

Mysterious knob, I twiddle it and wait for something to drop from sky,
candy, cake or rock, whatever, there are adventures there ;-)

And I believe if once the cake drop from sky, there will be more
adventurers, and it won't be a mysterious knob any more.

> 
>>> Also, I'm starting to dislike the buddy name; its somewhat over-used.
>>
>> I have to agree :), any suggestions?
> 
> Nah.. I suppose it depends a bit on the shape the final solution takes,

What about default sysctl_sched_wakeup_buddy_ref = 0 and keep the old
logical?

Regards,
Michael Wang


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

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

linux-next: manual merge of the signal tree with the mips tree

[Stephen Rothwell]

Hi Al,

Today's linux-next merge of the signal tree got a conflict in
arch/mips/kernel/linux32.c between commit 63981a409608 ("MIPS: compat:
Return same error ENOSYS as native for invalid operation") from the mips
tree and commit 56e41d3c5aa8 ("merge compat sys_ipc instances") from the
signal tree.

The latter removed the code fixed by the former, so I did that and can
carry the fix as necessary (no action is required).

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


pgpeN7D_9mOxH.pgp
Description: PGP signature

Re: [PATCH 00/12] perf annotate: Add support for event group view (v2)

[Namhyung Kim]

Hi Arnaldo,

On Mon, 11 Mar 2013 17:53:16 -0300, Arnaldo Carvalho de Melo wrote:
> Em Tue, Mar 05, 2013 at 02:53:20PM +0900, Namhyung Kim escreveu:
>> This patchset implements event group view on perf annotate.  It's
>> basically a rebased version and major difference to prior version is
>> the GTK annotation browser support.
>
>> Here goes an example:
>
>>  $ perf annotate --group --stdio
>
>>   crtstuff.c:0
>>  8.082.405.29 :387dc0aa50:   mov%rdi,%rdx
>
>
> I applied this series minus the TUI enabling one, as it is not working,
> so right now my perf/core has --group --stdio and --group --gtk working,
> please take a look at --group --tui.

Thanks, I took a look at the TUI code and found some missing pieces and
bugs.  Those code were in the original version but seems to get lost
during the cherry-picking and I tested wrong version. :(

>
> I need to go thru this more thoroughly, as at least one thing caught my
> attention, in some cases ->nr_pcnt is used and in others
> evsel->nr_members, do we need both?

Probably not.  I was thought keeping an array and its length together is
better.  But it's rather a waste to save the same information to every
date structure so I move it to the struct annotate_browser->nr_events.

For evsel->nr_members, current code sets it only for grouping is enabled
so the individual events will have value of 0.  Also it's not pass the
evsel to every function need it.  But if you think it should really be
fixed that way I can make the change to pass and use evsel->nr_members.

Anyway, below is a fixed version that could survived my testing.



>From 9d2948c274c4958ebde866adb28951f44e0595eb Mon Sep 17 00:00:00 2001
From: Namhyung Kim 
Date: Sat, 10 Nov 2012 01:21:02 +0900
Subject: [PATCH] perf annotate browser: Support event group view on TUI

Dynamically allocate browser_disasm_line according to a number of
group members.  This way we can handle multiple events in a general
manner.

Signed-off-by: Namhyung Kim 
---
 tools/perf/ui/browsers/annotate.c | 93 +++
 1 file changed, 75 insertions(+), 18 deletions(-)

diff --git a/tools/perf/ui/browsers/annotate.c 
b/tools/perf/ui/browsers/annotate.c
index 8b16926dd56e..f56247a03a22 100644
--- a/tools/perf/ui/browsers/annotate.c
+++ b/tools/perf/ui/browsers/annotate.c
@@ -17,6 +17,10 @@ struct browser_disasm_line {
u32 idx;
int idx_asm;
int jump_sources;
+   /*
+* actual length of this array is saved on the nr_events field
+* of the struct annotate_browser
+*/
double  percent[1];
 };
 
@@ -34,8 +38,9 @@ struct annotate_browser {
struct ui_browser b;
struct rb_rootentries;
struct rb_node*curr_hot;
-   struct disasm_line*selection;
+   struct disasm_line  *selection;
struct disasm_line  **offsets;
+   int nr_events;
u64 start;
int nr_asm_entries;
int nr_entries;
@@ -95,14 +100,24 @@ static void annotate_browser__write(struct ui_browser 
*browser, void *entry, int
 (!current_entry || (browser->use_navkeypressed &&
 !browser->navkeypressed)));
int width = browser->width, printed;
+   int i, pcnt_width = 7 * ab->nr_events;
+   double percent_max = 0.0;
char bf[256];
 
-   if (dl->offset != -1 && bdl->percent[0] != 0.0) {
-   ui_browser__set_percent_color(browser, bdl->percent[0], 
current_entry);
-   slsmg_printf("%6.2f ", bdl->percent[0]);
+   for (i = 0; i < ab->nr_events; i++) {
+   if (bdl->percent[i] > percent_max)
+   percent_max = bdl->percent[i];
+   }
+
+   if (dl->offset != -1 && percent_max != 0.0) {
+   for (i = 0; i < ab->nr_events; i++) {
+   ui_browser__set_percent_color(browser, bdl->percent[i],
+ current_entry);
+   slsmg_printf("%6.2f ", bdl->percent[i]);
+   }
} else {
ui_browser__set_percent_color(browser, 0, current_entry);
-   slsmg_write_nstring(" ", 7);
+   slsmg_write_nstring(" ", pcnt_width);
}
 
SLsmg_write_char(' ');
@@ -112,12 +127,12 @@ static void annotate_browser__write(struct ui_browser 
*browser, void *entry, int
width += 1;
 
if (!*dl->line)
-   slsmg_write_nstring(" ", width - 7);
+   slsmg_write_nstring(" ", width - pcnt_width);
else if (dl->offset == -1) {
printed = scnprintf(bf, sizeof(bf), "%*s  ",
ab->addr_width, " ");
slsmg_write_nstring(bf, printed);
-   slsmg_write_nstring(dl->line, width - printed - 6);
+   

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

[Stephen Rothwell]

Hi Simon,

Today's linux-next merge of the renesas tree got a conflict in
arch/arm/mach-shmobile/setup-sh73a0.c between commit 9a27dee73f55 ("ARM:
mach-shmobile: sh73a0: Add IPMMU device") from the  tree and commits
73b21f40b61c ("ARM: shmobile: sh73a0: Do not use early devices with DT
reference") and 2a2b1f1bb063 ("ARM: shmobile: INTC External IRQ pin
driver on sh73a0") from the renesas tree.

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

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

diff --cc arch/arm/mach-shmobile/setup-sh73a0.c
index bdab575,95a75af..000
--- a/arch/arm/mach-shmobile/setup-sh73a0.c
+++ b/arch/arm/mach-shmobile/setup-sh73a0.c
@@@ -31,7 -32,7 +32,8 @@@
  #include 
  #include 
  #include 
 +#include 
+ #include 
  #include 
  #include 
  #include 
@@@ -781,36 -782,128 +783,157 @@@ static struct platform_device pmu_devic
.resource   = pmu_resources,
  };
  
 +/* an IPMMU module for ICB */
 +static struct resource ipmmu_resources[] = {
 +  [0] = {
 +  .name   = "IPMMU",
 +  .start  = 0xfe951000,
 +  .end= 0xfe9510ff,
 +  .flags  = IORESOURCE_MEM,
 +  },
 +};
 +
 +static const char * const ipmmu_dev_names[] = {
 +  "sh_mobile_lcdc_fb.0",
 +};
 +
 +static struct shmobile_ipmmu_platform_data ipmmu_platform_data = {
 +  .dev_names = ipmmu_dev_names,
 +  .num_dev_names = ARRAY_SIZE(ipmmu_dev_names),
 +};
 +
 +static struct platform_device ipmmu_device = {
 +  .name   = "ipmmu",
 +  .id = -1,
 +  .dev = {
 +  .platform_data = _platform_data,
 +  },
 +  .resource   = ipmmu_resources,
 +  .num_resources  = ARRAY_SIZE(ipmmu_resources),
 +};
 +
- static struct platform_device *sh73a0_early_devices_dt[] __initdata = {
+ static struct renesas_intc_irqpin_config irqpin0_platform_data = {
+   .irq_base = irq_pin(0), /* IRQ0 -> IRQ7 */
+ };
+ 
+ static struct resource irqpin0_resources[] = {
+   DEFINE_RES_MEM(0xe690, 4), /* ICR1A */
+   DEFINE_RES_MEM(0xe6900010, 4), /* INTPRI00A */
+   DEFINE_RES_MEM(0xe6900020, 1), /* INTREQ00A */
+   DEFINE_RES_MEM(0xe6900040, 1), /* INTMSK00A */
+   DEFINE_RES_MEM(0xe6900060, 1), /* INTMSKCLR00A */
+   DEFINE_RES_IRQ(gic_spi(1)), /* IRQ0 */
+   DEFINE_RES_IRQ(gic_spi(2)), /* IRQ1 */
+   DEFINE_RES_IRQ(gic_spi(3)), /* IRQ2 */
+   DEFINE_RES_IRQ(gic_spi(4)), /* IRQ3 */
+   DEFINE_RES_IRQ(gic_spi(5)), /* IRQ4 */
+   DEFINE_RES_IRQ(gic_spi(6)), /* IRQ5 */
+   DEFINE_RES_IRQ(gic_spi(7)), /* IRQ6 */
+   DEFINE_RES_IRQ(gic_spi(8)), /* IRQ7 */
+ };
+ 
+ static struct platform_device irqpin0_device = {
+   .name   = "renesas_intc_irqpin",
+   .id = 0,
+   .resource   = irqpin0_resources,
+   .num_resources  = ARRAY_SIZE(irqpin0_resources),
+   .dev= {
+   .platform_data  = _platform_data,
+   },
+ };
+ 
+ static struct renesas_intc_irqpin_config irqpin1_platform_data = {
+   .irq_base = irq_pin(8), /* IRQ8 -> IRQ15 */
+   .control_parent = true, /* Disable spurious IRQ10 */
+ };
+ 
+ static struct resource irqpin1_resources[] = {
+   DEFINE_RES_MEM(0xe694, 4), /* ICR2A */
+   DEFINE_RES_MEM(0xe6900014, 4), /* INTPRI10A */
+   DEFINE_RES_MEM(0xe6900024, 1), /* INTREQ10A */
+   DEFINE_RES_MEM(0xe6900044, 1), /* INTMSK10A */
+   DEFINE_RES_MEM(0xe6900064, 1), /* INTMSKCLR10A */
+   DEFINE_RES_IRQ(gic_spi(9)), /* IRQ8 */
+   DEFINE_RES_IRQ(gic_spi(10)), /* IRQ9 */
+   DEFINE_RES_IRQ(gic_spi(11)), /* IRQ10 */
+   DEFINE_RES_IRQ(gic_spi(12)), /* IRQ11 */
+   DEFINE_RES_IRQ(gic_spi(13)), /* IRQ12 */
+   DEFINE_RES_IRQ(gic_spi(14)), /* IRQ13 */
+   DEFINE_RES_IRQ(gic_spi(15)), /* IRQ14 */
+   DEFINE_RES_IRQ(gic_spi(16)), /* IRQ15 */
+ };
+ 
+ static struct platform_device irqpin1_device = {
+   .name   = "renesas_intc_irqpin",
+   .id = 1,
+   .resource   = irqpin1_resources,
+   .num_resources  = ARRAY_SIZE(irqpin1_resources),
+   .dev= {
+   .platform_data  = _platform_data,
+   },
+ };
+ 
+ static struct renesas_intc_irqpin_config irqpin2_platform_data = {
+   .irq_base = irq_pin(16), /* IRQ16 -> IRQ23 */
+ };
+ 
+ static struct resource irqpin2_resources[] = {
+   DEFINE_RES_MEM(0xe698, 4), /* ICR3A */
+   DEFINE_RES_MEM(0xe6900018, 4), /* INTPRI20A */
+   DEFINE_RES_MEM(0xe6900028, 1), /* INTREQ20A */
+   DEFINE_RES_MEM(0xe6900048, 1), /* INTMSK20A */
+   DEFINE_RES_MEM(0xe6900068, 1), /* INTMSKCLR20A */
+   DEFINE_RES_IRQ(gic_spi(17)), /* IRQ16 */
+   DEFINE_RES_IRQ(gic_spi(18)), /* IRQ17 */
+   DEFINE_RES_IRQ(gic_spi(19)), /* IRQ18 */
+   DEFINE_RES_IRQ(gic_spi(20)), /* IRQ19 */
+   DEFINE_RES_IRQ(gic_spi(21)), /* IRQ20 */
+   

Re: [PATCH] efivars: allow efi pstore variable when validate filename

[joeyli]

Hi Matt, 

Sorry for I didn't aware your 123abd76edf patch fixed issue.
Please ignore my patch.


Thanks a lot!
Joey Lee

於 二，2013-03-12 於 03:00 +0800，Lee, Chun-Yi 提到：
> We mount efivarfs fail after pstore generated 'dump-type*' variables and
> reboot.
> 
> This issue introduced by commit 47f531e8ba3bc3901a0c493f4252826c41dea1a1
> (efivarfs: Validate filenames much more aggressively)
> 
> The pstore variable is 'dump-type*-*-*-*-GUID'style, it could not pass
> the "GUID should be right after the first '-'" check. This patch allow
> the variable name that has 'dump-type' pass the name check.
> 
> Cc: Matt Fleming 
> Cc: Seiji Aguchi 
> Cc: Matthew Garrett 
> Cc: Al Viro 
> Cc: Lingzhu Xiang 
> Signed-off-by: Lee, Chun-Yi 
> ---
>  drivers/firmware/efivars.c |2 +-
>  1 files changed, 1 insertions(+), 1 deletions(-)
> 
> diff --git a/drivers/firmware/efivars.c b/drivers/firmware/efivars.c
> index 3edade0..ab07f7f 100644
> --- a/drivers/firmware/efivars.c
> +++ b/drivers/firmware/efivars.c
> @@ -930,7 +930,7 @@ static bool efivarfs_valid_name(const char *str, int len)
>   return false;
>  
>   /* GUID should be right after the first '-' */
> - if (s - 1 != strchr(str, '-'))
> + if (s - 1 != strchr(str, '-') && !strstarts(str, "dump-type"))
>   return false;
>  
>   /*


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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/6] Drivers: hv: balloon: Implement hot-add functionality

[KY Srinivasan]

> -Original Message-
> From: K. Y. Srinivasan [mailto:k...@microsoft.com]
> Sent: Friday, March 08, 2013 5:16 PM
> To: gre...@linuxfoundation.org; linux-kernel@vger.kernel.org;
> de...@linuxdriverproject.org; o...@aepfle.de; a...@canonical.com;
> jasow...@redhat.com
> Cc: KY Srinivasan
> Subject: [PATCH 5/6] Drivers: hv: balloon: Implement hot-add functionality
> 
> Implement the memory hot-add functionality. With this, Linux guests can fully
> participate in the Dynamic Memory protocol implemented in the Windows hosts.

Greg,

I forgot to modify the Kconfig file to include the new dependency of the 
balloon driver on
MEMORY_HOTPLUG. Should I send a separate patch for  Kconfig, or resend this one 
patch
with the Kconfig changes folded in. Or, do you want me to resend the whole 
series.

Regards,

K. Y
> 
> Signed-off-by: K. Y. Srinivasan 
> Reviewed-by: Haiyang Zhang 
> ---
>  drivers/hv/hv_balloon.c |  393
> ---
>  1 files changed, 372 insertions(+), 21 deletions(-)
> 
> diff --git a/drivers/hv/hv_balloon.c b/drivers/hv/hv_balloon.c
> index 4743db9..232120d 100644
> --- a/drivers/hv/hv_balloon.c
> +++ b/drivers/hv/hv_balloon.c
> @@ -412,6 +412,27 @@ struct dm_info_msg {
>   * End protocol definitions.
>   */
> 
> +/*
> + * State to manage hot adding memory into the guest.
> + * The range start_pfn : end_pfn specifies the range
> + * that the host has asked us to hot add. The range
> + * start_pfn : ha_end_pfn specifies the range that we have
> + * currently hot added. We hot add in multiples of 128M
> + * chunks; it is possible that we may not be able to bring
> + * online all the pages in the region. The range
> + * covered_start_pfn : covered_end_pfn defines the pages that can
> + * be brough online.
> + */
> +
> +struct hv_hotadd_state {
> + struct list_head list;
> + unsigned long start_pfn;
> + unsigned long covered_start_pfn;
> + unsigned long covered_end_pfn;
> + unsigned long ha_end_pfn;
> + unsigned long end_pfn;
> +};
> +
>  struct balloon_state {
>   __u32 num_pages;
>   struct work_struct wrk;
> @@ -419,16 +440,17 @@ struct balloon_state {
> 
>  struct hot_add_wrk {
>   union dm_mem_page_range ha_page_range;
> + union dm_mem_page_range ha_region_range;
>   struct work_struct wrk;
>  };
> 
> -static bool hot_add;
> +static bool hot_add = true;
>  static bool do_hot_add;
>  /*
>   * Delay reporting memory pressure by
>   * the specified number of seconds.
>   */
> -static uint pressure_report_delay = 30;
> +static uint pressure_report_delay = 45;
> 
>  module_param(hot_add, bool, (S_IRUGO | S_IWUSR));
>  MODULE_PARM_DESC(hot_add, "If set attempt memory hot_add");
> @@ -456,6 +478,7 @@ enum hv_dm_state {
>  static __u8 recv_buffer[PAGE_SIZE];
>  static __u8 *send_buffer;
>  #define PAGES_IN_2M  512
> +#define HA_CHUNK (32 * 1024)
> 
>  struct hv_dynmem_device {
>   struct hv_device *dev;
> @@ -479,6 +502,17 @@ struct hv_dynmem_device {
>   struct hot_add_wrk ha_wrk;
> 
>   /*
> +  * This state tracks if the host has specified a hot-add
> +  * region.
> +  */
> + bool host_specified_ha_region;
> +
> + /*
> +  * State to synchronize hot-add.
> +  */
> + struct completion  ol_waitevent;
> + bool ha_waiting;
> + /*
>* This thread handles hot-add
>* requests from the host as well as notifying
>* the host with regards to memory pressure in
> @@ -487,6 +521,11 @@ struct hv_dynmem_device {
>   struct task_struct *thread;
> 
>   /*
> +  * A list of hot-add regions.
> +  */
> + struct list_head ha_region_list;
> +
> + /*
>* We start with the highest version we can support
>* and downgrade based on the host; we save here the
>* next version to try.
> @@ -496,35 +535,321 @@ struct hv_dynmem_device {
> 
>  static struct hv_dynmem_device dm_device;
> 
> -static void hot_add_req(struct work_struct *dummy)
> +void hv_bring_pgs_online(unsigned long start_pfn, unsigned long size)
>  {
> + int i;
> 
> - struct dm_hot_add_response resp;
> + for (i = 0; i < size; i++) {
> + struct page *pg;
> + pg = pfn_to_page(start_pfn + i);
> + __online_page_set_limits(pg);
> + __online_page_increment_counters(pg);
> + __online_page_free(pg);
> + }
> +}
> +
> +static void hv_mem_hot_add(unsigned long start, unsigned long size,
> + unsigned long pfn_count,
> + struct hv_hotadd_state *has)
> +{
> + int ret = 0;
> + int i, nid, t;
> + unsigned long start_pfn;
> + unsigned long processed_pfn;
> + unsigned long total_pfn = pfn_count;
> +
> + for (i = 0; i < (size/HA_CHUNK); i++) {
> + start_pfn = start + (i * HA_CHUNK);
> + has->ha_end_pfn +=  HA_CHUNK;
> +
> + if (total_pfn > HA_CHUNK) {
> + processed_pfn = 

Re: [Nepomuk] Better support for (desktop) file search / indexing applications

[Andreas Dilger]

On 2013-03-10, at 6:06, Lijo Antony  wrote:
> On 03/10/2013 08:51 AM, Simeon Bird wrote:
>> 
>> We (nepomuk) recently looked at using fanotify, and indeed we would
>> need user watches, support for moves and recursive directory watches
>> (we need to support the case where /home is not a separate filesystem)
>> before it would be useful to us. If you are interested in adding
>> these, we would be delighted to use nepomuk as a test-case for them.
>> 
>> We were wondering also if it would be possible to extend inotify a
>> little? Our wishlist is:
>> 
>> 1) Recursive folder watches
>> 2) When a file moves, some way to get the destination without watching
>> the directory it moved to, so moves can be tracked without watching
>> every file on the system.
> 
> I am also interested in these features. As of now, my solutions are,
> 
> 1) When the limit is reached, ask the user to increase the limit and restart 
> the application.
> 
> 2) When top level directory move is detected, do a file system search based 
> on inode to find out the new location. Very slow and not fool proof.

For Lustre, we implemented something similar to inotify with some
improvements that are possible because we limit the backend
filesystems that it runs on (ext4 and ZFS currently, but would also be
possible on Btrfs as well). 

For #1 (event recording) we have a persistent transactional ChangeLog
that is updated atomically with the metadata operation (create, rename,
unlink, etc).  This allows external applications to be notified of changes
in the whole filesystem, even if there are modifications while the watcher was
not running (to some limited extent). It is possible to limit the types of 
events
that are recorded in the ChangeLog, but not necessarily by pathname yet.
This is used for HSM and remote filesystem replication today.

For #2, we have a function "fid2path" that will generate in O(1) each
pathname of a file given the FID (essentially the inode number). This is
possible because each inode keeps an xattr ("link") that is updated for each 
link 
or rename of the inode with the parent directory FID and directory entry name. 

The "link" xattr is relatively low cost, since the inode needs to be updated 
for 
each link/rename/unlink anyway (nlinks and ctime), and in the overwhelmingly
common case if a single link on a file there is only a single entry in the 
xattr,
so it can fit inside the inode.

>From the list of links, we can walk the namespace in reverse order with
fid2path() to generate all if the pathnames of an inode. Something
similar would also allow you to find the target directory of a renamed file
without having to watch all of the directories. 

Cheers, Andreas

> I would also like to any other solutions for these problems. I am yet to look 
> into fanotify.
> 
> -lijo
> 
> [leaving the rest for reference]
> 
>> 
>> I understand that there are reasons of security and performance why
>> you cannot implement 1), but is 2) possible? Maybe by extending
>> IN_MOVED_TO, or adding a new event type?
>> 
>> 2) is actually in some ways the more severe problem for us. As well as
>> being an indexer, nepomuk is a system that allows you to store file
>> metadata such as ratings. When users move the files, they want the
>> metadata to move too, so we need to track where the file moved, and
>> thus at the moment we recursively watch everything. This is
>> particularly problematic with removable media; because a lot of people
>> will plug in an external drive and then move files onto it, we have to
>> watch every drive as soon as it is plugged in. If we were able to get
>> the destination of move events without watching the destination
>> directory, we could watch only those directories with interesting
>> metadata in, which would make things a lot easier.
>> 
>> inotify move tracking would also be useful for other things - eg, a
>> text editor could use inotify to see if a file it has open has moved
>> and offer to re-open the file in its new location, which is impossible
>> at the moment.
>> 
>> Since the lack of recursive watches is really a problem because we
>> have a tendency to run out of watches, it would also really help if
>> the default limit was a bit higher -  most people seem to have > 8000
>> folders, but I suspect far fewer have > 32000 (probably excepting
>> those who are indexing kernel source trees: I have 21000, and half of
>> that is KDE source).
>> 
>> Would any of this be possible? If you happen to know of a better way
>> to track moves using existing tools, that would be even better.
>> 
>> Thanks,
>> Simeon
>> --
>> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
>> the body of a message to majord...@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-fsdevel" in
> the body of a message to majord...@vger.kernel.org
> More 

Re: [PATCH] mv643xx_eth: Fix a possible deadlock upon ifdown

[Lennert Buytenhek]

On Fri, Mar 01, 2013 at 06:30:13PM +0100, Alexander Holler wrote:

> >>From: Lubomir Rintel 
> >>
> >>=
> >>[ INFO: inconsistent lock state ]
> >>3.7.0-6.luboskovo.fc19.armv5tel.kirkwood #1 Tainted: GW
> >>-
> >>inconsistent {IN-SOFTIRQ-W} -> {SOFTIRQ-ON-W} usage.
> >>NetworkManager/337 [HC0[0]:SC0[0]:HE1:SE1] takes:
> >>  (_xmit_ETHER#2){+.?...}, at: [] txq_reclaim+0x54/0x264 
> >> [mv643xx_eth]
> 
> I get the same annoying warning when the MTU gets changed (through dhcp).

That is actually an issue.


> >Maybe I'm not reading it right, but I doubt that this is an actual
> >deadlock or that the patch is needed.
> >
> >txq_reclaim() indeed doesn't disable BHs, but that's because it's
> >always called in BH context.  Almost always -- the only exception is
> >txq_deinit(), called from ->ndo_stop(), but by that time we've
> >already napi_disable()'d and netif_carrier_off()'d and free_irq()'d.
> 
> Agreed. I've just read me through that too and don't think a
> deadlock is possible.
> 
> >How to explain that to lockdep, though, I don't know.
> 
> The patch helps with that. ;)

It fixes a bug (the MTU change thing) and a non-bug (the lockdep
warning) at the expense of slowing down the much more common path,
and I don't like it for that reason.

Can you make a __txq_reclaim() which is basically txq_reclaim()
without grabbing the tx queue lock, and then move the lock grabbing
to the caller?

E.g. make __txq_reclaim() have two callers, txq_reclaim() and
txq_reclaim_bh(), and then use the appropriate wrapper depending on
the context.  (tx queue lock but no BH disable when called from
mv643xx_eth_poll(), tx queue lock plus BH disable for MTU change,
and no locking at all when called from ->ndo_stop().  Something
like that.)
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH linux-next v3] SUNRPC: rpcrdma_register_default_external: Dynamically allocate ib_phys_buf

[Tim Gardner]

On 03/11/2013 05:02 PM, Tom Tucker wrote:

On 3/11/13 4:25 PM, J. Bruce Fields wrote:





Looks good to me; wish we could get it tested


I will test it. Tim could you please send me a final version that you'd
like tested as a single message?



I'm a little confused about what you are asking. I think v3 of the patch 
is the final version (unless you find bugs with it).



Would someone (like Tim maybe ... hint hint) look at tearing out all
those dead registration strategies? I don't think we need or will ever
use bounce-buffers, memory windows, or mlnx fmr.  The only two that are
used and tested are all-phys and FRMR (the default).



Dunno if I'll get time for that. I had a one day window where I could 
hack out some simple patches. Now I'm back to the usual grindstone.


rtg
--
Tim Gardner tim.gard...@canonical.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: torrent hash failures since 3.9.0-rc1

[Zheng Liu]

On Tue, Mar 12, 2013 at 12:12:27AM +0100, Markus Trippelsdorf wrote:
> On 2013.03.11 at 22:38 +0100, Markus Trippelsdorf wrote:
> > On 2013.03.11 at 17:18 -0400, Theodore Ts'o wrote:
> > > On Mon, Mar 11, 2013 at 09:46:25PM +0100, Markus Trippelsdorf wrote:
> > > > > BTW, I'm currently running 3.9-rc2 with some additional fixes from the
> > > > > ext4 dev branch, and I'm not able to reproduce the problem using
> > > > > rtorrent on my laptop.  How reliably is it reproducing for you?  Are
> > > > > you seeing the problem every time you try this?
> > > > 
> > > > Yes, it's 100% reproducible for me. If I boot a 3.8 kernel the issue
> > > > vanishes.
> > > 
> > > Would you be willing to try an experiment? 
> > > 
> > > Try pulling down the master branch from the ext4 git tree here:
> > > 
> > > git://git.kernel.org/pub/scm/linux/kernel/git/tytso/ext4.git
> > > 
> > > This contains all of the ext4 changes which are in 3.9-rc1, based on
> > > top of 3.8-rc3.  See if it reproduces there.  If it does, then it
> > > would tend to confirm the hypothesis that the issue was introduced by
> > > one of the ext4 patches that we merged during the 3.9-rc1 merge
> > > window... and then, since if you can reproduce the problem, if you
> > > could do a git bisect to find the guilty commit, that would really
> > > greatly appreciated.
> > > 
> > > If you can't reproduce it from the ext4.git tree, then the problem is
> > > probably caused by some other change that was introduced between 3.8
> > > and 3.9-rc1.
> > 
> > I've started a full bisection from v3.8 to todays git tree. It will take
> > ~13 steps. However it's already late here in Germany. I will continue
> > the bisection tomorrow and report back.
> 
> The issue started with:
> 
> 74cd15cd02708c7188581f279f33a98b2ae8d322 is the first bad commit
> commit 74cd15cd02708c7188581f279f33a98b2ae8d322
> Author: Zheng Liu 
> Date:   Mon Feb 18 00:32:55 2013 -0500
> 
> ext4: reclaim extents from extent status tree
> 
> Please note that my local rtorrent version was configured with
> "--with-posix-fallocate". I'm not sure if distributions also enable this
> flag, but it could explain why Ted and Dave weren't able to reproduce
> the problem so far.

Hi Markus,

Thanks for reporting this problem.  My deepest apologies.

As Ted suggested, could you please try to use ext4 git tree?  I want to
make sure whether this bug has been fixed by my lastest patch series or
not.

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

mm/hotplug: fix build warning when CONFIG_MEMORY_HOTREMOVE=n

[Jianguo Wu]

There is a warning while building kernel with
CONFIG_MEMORY_HOTPLUG=y && CONFIG_MEMORY_HOTREMOVE=n:
arch/x86/mm/init_64.c:1024: warning:kernel_physical_mapping_remove defined but 
not used

So move kernel_physical_mapping_remove() into "#ifdef CONFIG_MEMORY_HOTREMOVE" 
block

Signed-off-by: Jianguo Wu 
---
 arch/x86/mm/init_64.c |2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/arch/x86/mm/init_64.c b/arch/x86/mm/init_64.c
index 474e28f..dafdeb2 100644
--- a/arch/x86/mm/init_64.c
+++ b/arch/x86/mm/init_64.c
@@ -1019,6 +1019,7 @@ void __ref vmemmap_free(struct page *memmap, unsigned 
long nr_pages)
remove_pagetable(start, end, false);
 }
 
+#ifdef CONFIG_MEMORY_HOTREMOVE
 static void __meminit
 kernel_physical_mapping_remove(unsigned long start, unsigned long end)
 {
@@ -1028,7 +1029,6 @@ kernel_physical_mapping_remove(unsigned long start, 
unsigned long end)
remove_pagetable(start, end, true);
 }
 
-#ifdef CONFIG_MEMORY_HOTREMOVE
 int __ref arch_remove_memory(u64 start, u64 size)
 {
unsigned long start_pfn = start >> PAGE_SHIFT;
-- 
1.7.6.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 11/12] rwsem: wake all readers when first waiter is a reader

[Dave Chinner]

On Sun, Mar 10, 2013 at 10:17:42PM -0700, Michel Lespinasse wrote:
> On Sun, Mar 10, 2013 at 5:16 PM, Dave Chinner  wrote:
> > On Fri, Mar 08, 2013 at 05:20:34PM -0800, Michel Lespinasse wrote:
> >> On Fri, Mar 8, 2013 at 4:32 PM, Dave Chinner  wrote:
> >> > Isn't this a significant change of semantics for the rwsem? i.e.
> >> > that read lock requests that come after a write lock request now
> >> > jump ahead of the write lock request? i.e.the write lock request is
> >> > no longer a barrier in the queue?
> >>
> >> Yes, I am allowing readers to skip ahead of writers in the queue (but
> >> only if they can run with another reader that was already ahead).
> >>
> >> I don't see that this is a change of observable semantics for correct
> >> programs. If a reader and a writer both block on the rwsem, how do you
> >> known for sure which one got queued first ? rwsem API doesn't give you
> >> any easy way to know whether a thread is currently queued on the rwsem
> >> (it could also be descheduled before it gets onto the rwsem queue).
> >
> > There are algorithms that rely on write locks to act as read-side
> > barriers to prevent write side starvation. i.e. if you keep queuing
> > up read locks, the writer never gets the lock, thereby starving the
> > writer.
> 
> What I propose actually isn't as bad as a reader preference rwlock
> like rwlock_t. When a reader makes it to the head of the queue, all
> readers gets woken. At that point there are only writers left in the
> queue, and new readers will get queued after them and won't be able to
> skip over them (since they have no earlier reader to join up with).
> So, I am not throwing reader/writer fairness out the window here.

OK, but

> > My point isn't that XFS gets the serialisation wrong - my point is
> > that the change of queuing order will change the userspace visible
> > behaviour of the filesystem *significantly*.
> >
> > For example: - direct IO only takes read locks, while truncate takes
> > a write lock.  Right now we can drop a truncate, preallocation or
> > hole punch operation into a stream of concurrent direct IO and have
> > it execute almost immediately - the barrier mechanism in the rwsem
> > ensures that it will be executed ahead of any future IO that is
> > issued by the application. With your proposed change, that operation
> > won't take place until all current *and all future* IOs stop and the
> > read lock is no longer held by anyone.
> 
> You actually wouldn't get such starvation with my proposal.
> 
> What you might see would be:
> 
> - Assuming you have up to N concurrent reads in progress, a writer
> might see up to 2N-1 readers proceed in front of it. This limit is
> reached if you first had N-1 readers grabbing the rwsem with an empty
> queue, then another writer W1 got queued,

So something like

RW1

> then a reader RN (note that
> it will get queued after W1 and not run concurrently with the existing
> N-1 readers), then our writer W2 gets queued.

So:

RW1W2
>
> As our N-1 readers
> complete their IO operations, they might get queued again after W2,

So:
W1W2R

> and then skip ahead of W2 when RN reaches the front of the queue. So,
> W2 is still guaranteed to run eventually, but with a worst case
> latency that is ~2x worse than before

So, when W1 is released, the queue is treated as though it was:

RW2

yes? Ok, so I can see where your latency figure comes from, but it's
still a change of ordering in that W2 is no longer a barrier to the
reads queued after it.

And if we extend that to WN, we have an interleaved queue
similar to this:

W1R1W2R2W3R3.WnRm

By my reading of the algorithm you are proposing, after W1 is
released, we end up with the queue being treated like this:

R1R2R3RmW2W3Wn

Right?

If so, that is definitely a change of lock ordering semantics -
writes do not have barrier properties anymore.

> - since all readers are woken at once, you might see burst of direct
> IO operations followed by bursts of truncate operations, instead of
> having them interleaved in smaller groups as before.

And this will result in the same application IO pattern giving
vastly different results. e.g. a read IO promoted ahead of a
truncate will now return data instead of -1 (beyond EOF).

> I'm not sure if these characteristics are good enough for the XFS use
> case. It seems tougher than many rwsem use cases, since the benefits
> of increased reader parallelism are not as clear here (i.e. the IO

Well defined, predictable, deterministc ordering of operations takes
far more precedence over parallelism when it comes to filesystem
behaviour. The rwsems already have enough parallelism to allow us to
drive more than 2 million 4k IOPS to a single file via
multi-threaded direct IO(*), so we aren't limited by parallelism and
concurrency in rwsems.

> So if
> this explanation still didn't made 

linux-next: manual merge of the drivers-x86 tree with the tree

[Stephen Rothwell]

Hi Matthew,

Today's linux-next merge of the drivers-x86 tree got a conflict in
drivers/platform/x86/chromeos_laptop.c between a series of patches from
Linus' tree and the same series of patches from the drivers-x86 tree.

There was an extra patch merged into Linus tree affecting this file, so I
used that version.

Please, when you rebase/rewrite stuff before sending it to Linus, also
update your -next included tree (or just *don't do that* :-().

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


pgpxT4udQSe5Z.pgp
Description: PGP signature

Re: [PATCH v1] ARM: keep __my_cpu_offset consistent with generic one

[Ming Lei]

On Thu, Mar 7, 2013 at 9:35 PM, Ming Lei  wrote:
> Commit 14318efb(ARM: 7587/1: implement optimized percpu variable access)
> introduces arm's __my_cpu_offset to optimize percpu vaiable access,
> which really works well on hackbench, but will cause __my_cpu_offset
> to return garbage value before it is initialized in cpu_init() called
> by setup_arch, so accessing percpu variable before setup_arch may cause
> kernel hang. But generic __my_cpu_offset always returns zero before
> percpu area is brought up, and won't hang kernel.
>
> So the patch tries to clear __my_cpu_offset on boot CPU early
> to avoid boot hang.
>
> At least now percpu variable is accessed by lockdep before
> setup_arch(), and enabling CONFIG_LOCK_STAT or CONFIG_DEBUG_LOCKDEP
> can trigger kernel hang.
>
> Cc: Peter Zijlstra 
> Cc: Ingo Molnar 
> Cc: Rob Herring 
> Cc: Will Deacon 
> Cc: Nicolas Pitre 
> Cc: Russell King 
> Signed-off-by: Ming Lei 
> ---
> V1:
> - documents lockdep uses percpu variable early

Looks no one objects the patch, so I has submitted it into Russell's
patch system, and hope it can be pushed to linus tree soon and
make LOCK_STAT/DEBUG_LOCKDEP usable on ARMv7.


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/

[PATCH] cpuset: fix RCU lockdep splat in cpuset_print_task_mems_allowed()

[Li Zefan]

Sasha reported a lockdep warning when OOM was triggered. The reason
is cgroup_name() should be called with rcu_read_lock() held.

Reported-by: Sasha Levin 
Signed-off-by: Li Zefan 
---

This fix is for 3.10

---
 kernel/cpuset.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/kernel/cpuset.c b/kernel/cpuset.c
index c55763b..98d458a 100644
--- a/kernel/cpuset.c
+++ b/kernel/cpuset.c
@@ -2599,6 +2599,7 @@ void cpuset_print_task_mems_allowed(struct task_struct 
*tsk)
 
struct cgroup *cgrp = task_cs(tsk)->css.cgroup;
 
+   rcu_read_lock();
spin_lock(_buffer_lock);
 
nodelist_scnprintf(cpuset_nodelist, CPUSET_NODELIST_LEN,
@@ -2607,6 +2608,7 @@ void cpuset_print_task_mems_allowed(struct task_struct 
*tsk)
   tsk->comm, cgroup_name(cgrp), cpuset_nodelist);
 
spin_unlock(_buffer_lock);
+   rcu_read_unlock();
 }
 
 /*
-- 
1.8.0.2
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Bug involving dynamic_debug and '-p' modifier

[Andrew Cooks]

On Tue, Mar 12, 2013 at 9:14 AM, Andrew Cooks  wrote:
> Hi Jason
>
> When I specify a '-p' modifier in the dynamic debug options in the
> kernel command line, I get a kernel panic during boot. The panic
> happens after userspace starts doing graphical stuff, but I haven't
> been able to pinpoint exactly what.
>
> If I use '=_' instead of '-p', or boot to a recovery mode, or change
> the modifier after booting using debugfs, the panic doesn't occur. For
> example, booting to runlevel 3 with '=_', then flipping the same
> modifier to first to '+p' and then to '-p', before starting X does not
> result in a panic.
>
> Booting to runlevel 3 (or even 1!), with '-p' results in a panic, but
> 'rdshell' is OK.
>
> I also tried the Red Hat kernel (just because it's installed - I
> haven't figured out how to tell the package manager that I don't want
> a kernel). This also panics, but it says that '-p' is not supported.
>
> Please let me know if you need me to do any other tests.
>
> '-p', panic: http://pastebin.com/8yAcBQdY
> '-p', rdshell, no panic: http://pastebin.com/Hi2a7BZA
>
> --
> a.

Jason's mail bounced, so redirecting to Jim Cromie, who made the most
recent significant changes to dynamic_debug...
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v5 00/44] ldisc patchset

[Michel Lespinasse]

On Mon, Mar 11, 2013 at 1:44 PM, Peter Hurley  wrote:
> Greg,
> This patchset includes
>   'tty: Drop lock contention stat from ldsem trylocks'
> so no need to apply that on this series. Also, I noticed you
> kept the 'tty is NULL' removal on a different branch so I left
> my patch in this series that removes it.
>
> This series applies cleanly to tty-next.
>
> v5 changes:
>
> After completing an audit of the recursive use of ldisc
> references, I discovered the _blocking_ recursive acquisition
> of ldisc references was limited to line disciplines misusing
> the tty_perform_flush() function.
> With that now resolved in,
>   'tty: Fix recursive deadlock in tty_perform_flush()'
> the recursion design in ldsem has been removed.
>
> The recursion removal is in its own patch,
>   'tty: Remove ldsem recursion support'
> to ease review for those that have already reviewed the
> ldsem implementation.
>
> In addition, this patchset implements lock stealing derived
> from the work of Michel Lespinasse  on
> writer lock stealing in rwsem.
>
> Although the rwsem write lock stealing changes are motivated
> by performance criteria, these changes are motivated by reduced
> code line count and simplicity of design.
>
> *** Edited below to remove recursion discussion ***
>
> Back in early December I realized that a classic read/write semaphore
> with writer priority was the ideal mechanism for handling the
> line discipline referencing.
>
> Line discipline references act as "readers"; closing or changing the
> line discipline is prevented while these references are outstanding.
> Conversely, line discipline references should not be granted while
> the line discipline is closing or changing; these are the "writers".
>
> Unfortunately, the existing rwsem uses a FIFO priority for
> waiting threads and does not support timeouts.
>
> So this implements just that: a writer-priority
> read/write semaphore with timed waits.

Thanks for eliminating the recursion requirement. I think this really
helps - I didn't like that multiple readers with a colliding current
hash could basically starve out a writer forever.

Not knowing anything about the tty layer, I am curious about the
context for your other requirements. What are ldisc references taken
for and for how long are they held ? I am surprised that the writers
may hit a 5 second timeout (because I didn't expect the references to
be held for very long).

Also why the write-priority requirement rather than reader-writer
fairness ? Is it to make it less likely to hit the writer timeouts ?

In short: I am worried about the introduciton of a new lock type, and
would be happier if rwsem could be made to fit. BTW, extending rwsem
itself to add writer timeouts seems quite doable (but making it work
as a write priority lock would seem like a bad idea).

-- 
Michel "Walken" Lespinasse
A program is never fully debugged until the last user dies.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] sctp: don't break the loop while meeting the active_path so as to find the matched transport

[Xufeng Zhang]

>>
>> Thanks for your review, Neil!
>>
>> I know what you mean, yes, it's most probably that the searched TSN was
>> transmitted in the currently active_path, but what should we do if not.
>>
>> Check the comment in sctp_assoc_lookup_tsn() function:
>> /* Let's be hopeful and check the active_path first. */
>> /* If not found, go search all the other transports. */
>>
>> It has checked the active_path first and then traverse all the other
>> transports in
>> the transport_addr_list except the active_path.
>>
>> So what I want to fix here is the inconsistency between the function
>> should do and
>> the code actually does.
>>
> I understand what you're doing, and I agree that the fix is functional
> (Hence
> my "This works" statement in my last note).  What I'm suggesting is that,
> since
> you're messing about in that code anyway that you clean it up while your at
> it,
> so that we don't need to have the if (transport == active) check at all.
> We
> trade in some extra work in a non-critical path (sctp_assoc_set_primary),
> for
> the removal of an extra for loop operation and a conditional check in a
> much
> hotter path.  Something like this (completely untested), is what I was
> thinking

Aha, seems I have some misunderstanding previously, now I got your point.
Yeah, it's better to do the clean up by this way, and this fix looks fine to me,
but I didn't have a test case to test this, actually this problem was detected
by code review, so I would like to leave the rest of this work to
determine by you.

Thank you very much for your clarification!


Thanks,
Xufeng

>
>
> diff --git a/net/sctp/associola.c b/net/sctp/associola.c
> index 43cd0dd..8ae873c 100644
> --- a/net/sctp/associola.c
> +++ b/net/sctp/associola.c
> @@ -505,6 +505,9 @@ void sctp_assoc_set_primary(struct sctp_association
> *asoc,
>
>   asoc->peer.primary_path = transport;
>
> + list_del_rcu(>transports);
> + list_add_rcu(>transports, >peer.transport_addr_list);
> +
>   /* Set a default msg_name for events. */
>   memcpy(>peer.primary_addr, >ipaddr,
>  sizeof(union sctp_addr));
> @@ -1040,7 +1043,6 @@ struct sctp_chunk *sctp_get_ecne_prepend(struct
> sctp_association *asoc)
>  struct sctp_transport *sctp_assoc_lookup_tsn(struct sctp_association
> *asoc,
>__u32 tsn)
>  {
> - struct sctp_transport *active;
>   struct sctp_transport *match;
>   struct sctp_transport *transport;
>   struct sctp_chunk *chunk;
> @@ -1057,29 +1059,16 @@ struct sctp_transport *sctp_assoc_lookup_tsn(struct
> sctp_association *asoc,
>* The general strategy is to search each transport's transmitted
>* list.   Return which transport this TSN lives on.
>*
> -  * Let's be hopeful and check the active_path first.
> -  * Another optimization would be to know if there is only one
> -  * outbound path and not have to look for the TSN at all.
> +  * Note, that sctp_assoc_set_primary does a move to front operation
> +  * on the active_path transport, so this code implicitly checks
> +  * the active_path first, as we most commonly expect to find our TSN
> +  * there.
>*
>*/
>
> - active = asoc->peer.active_path;
> -
> - list_for_each_entry(chunk, >transmitted,
> - transmitted_list) {
> -
> - if (key == chunk->subh.data_hdr->tsn) {
> - match = active;
> - goto out;
> - }
> - }
> -
> - /* If not found, go search all the other transports. */
>   list_for_each_entry(transport, >peer.transport_addr_list,
>   transports) {
>
> - if (transport == active)
> - break;
>   list_for_each_entry(chunk, >transmitted,
>   transmitted_list) {
>   if (key == chunk->subh.data_hdr->tsn) {
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/