Re: [PATCH 04/42] rtc: rtc-ab8500: remove unnecessary platform_set_drvdata()

[Srinidhi Kasagar]

On Fri, May 03, 2013 at 08:24:24 +0200, Jingoo Han wrote:
> The driver core clears the driver data to NULL after device_release
> or on probe failure, since commit 0998d0631001288a5974afc0b2a5f568bcdecb4d
> (device-core: Ensure drvdata = NULL when no driver is bound).
> Thus, it is not needed to manually clear the device driver data to NULL.
> 
> Signed-off-by: Jingoo Han 
> ---
>  drivers/rtc/rtc-ab8500.c |2 --
>  1 files changed, 0 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/rtc/rtc-ab8500.c b/drivers/rtc/rtc-ab8500.c
> index 63cfa31..c5b62d4 100644
> --- a/drivers/rtc/rtc-ab8500.c
> +++ b/drivers/rtc/rtc-ab8500.c
> @@ -451,8 +451,6 @@ static int ab8500_rtc_remove(struct platform_device *pdev)
>  {
>   ab8500_sysfs_rtc_unregister(&pdev->dev);
>  
> - platform_set_drvdata(pdev, NULL);
> -
>   return 0;
>  }
Ok, thanks. Hope you have taken care for the ab3100 too...

Acked-by:srinidhi kasagar 

regards/srinidhi 
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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: [GIT PULL] Removal of GENERIC_GPIO

[Grant Likely]

On Fri, May 3, 2013 at 2:03 AM, Stephen Rothwell  wrote:
> Hi Guys,
>
> On Fri, 3 May 2013 10:52:34 +1000 Stephen Rothwell  
> wrote:
>>
>> I currently have 3 merge fix patches for the gen-cpio tree:
>>
>> gen-gpio: GPIOLIB merge fix up
>> merge fix for Convert selectors of GENERIC_GPIO to GPIOLIB
>> merge fix 2 for Convert selectors of GENERIC_GPIO to GPIOLIB
>>
>> I have attached them.  All three are now applicable to Linus' tree.
>
> Just to absolutely clear, I *do not* expect either of you to rebase your
> trees or backmerge Linus' tree to fix these, I *do* expect whoever send
> this stuff to Linus to mention the necessary fixes to him.

Yes, that is exactly what I'm going to do

g.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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 RFC v3] media: i2c: mt9p031: add OF support

[Prabhakar Lad]

From: Lad, Prabhakar 

add OF support for the mt9p031 sensor driver.
Alongside this patch sorts the header inclusion alphabetically.

Signed-off-by: Lad, Prabhakar 
Cc: Hans Verkuil 
Cc: Laurent Pinchart 
Cc: Mauro Carvalho Chehab 
Cc: Guennadi Liakhovetski 
Cc: Sylwester Nawrocki 
Cc: Sakari Ailus 
Cc: Grant Likely 
Cc: Sascha Hauer 
Cc: Rob Herring 
Cc: Rob Landley 
Cc: Arnd Bergmann 
Cc: devicetree-disc...@lists.ozlabs.org
Cc: davinci-linux-open-sou...@linux.davincidsp.com
Cc: linux-...@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
---
 Changes for v2:
 1: Used '-' instead of '_' for device properties.
 2: Specified gpio reset pin as phandle in device node.
 3: Handle platform data properly even if kernel is compiled with
devicetree support.
 4: Used dev_* for messages in drivers instead of pr_*.
 5: Changed compatible property to "aptina,mt9p031" and "aptina,mt9p031m".
 6: Sorted the header inclusion alphabetically and fixed some minor code nits.

Changes for v3:
 1: Dropped check if gpio-reset is valid.
 2: Fixed some code nits.
 3: Included a reference to the V4L2 DT bindings documentation.

 .../devicetree/bindings/media/i2c/mt9p031.txt  |   40 +
 drivers/media/i2c/mt9p031.c|   60 +++-
 2 files changed, 97 insertions(+), 3 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/media/i2c/mt9p031.txt

diff --git a/Documentation/devicetree/bindings/media/i2c/mt9p031.txt 
b/Documentation/devicetree/bindings/media/i2c/mt9p031.txt
new file mode 100644
index 000..e740541
--- /dev/null
+++ b/Documentation/devicetree/bindings/media/i2c/mt9p031.txt
@@ -0,0 +1,40 @@
+* Aptina 1/2.5-Inch 5Mp CMOS Digital Image Sensor
+
+The Aptina MT9P031 is a 1/2.5-inch CMOS active pixel digital image sensor with
+an active array size of 2592H x 1944V. It is programmable through a simple
+two-wire serial interface.
+
+Required Properties :
+- compatible : value should be either one among the following
+   (a) "aptina,mt9p031" for mt9p031 sensor
+   (b) "aptina,mt9p031m" for mt9p031m sensor
+
+- input-clock-frequency : Input clock frequency.
+
+- pixel-clock-frequency : Pixel clock frequency.
+
+Optional Properties :
+-gpio-reset: Chip reset GPIO
+
+For further reading of port node refer Documentation/devicetree/bindings/media/
+video-interfaces.txt.
+
+Example:
+
+   i2c0@1c22000 {
+   ...
+   ...
+   mt9p031@5d {
+   compatible = "aptina,mt9p031";
+   reg = <0x5d>;
+   gpio-reset = <&gpio3 30 0>;
+
+   port {
+   mt9p031_1: endpoint {
+   input-clock-frequency = <600>;
+   pixel-clock-frequency = <9600>;
+   };
+   };
+   };
+   ...
+   };
diff --git a/drivers/media/i2c/mt9p031.c b/drivers/media/i2c/mt9p031.c
index 28cf95b..4514f8f 100644
--- a/drivers/media/i2c/mt9p031.c
+++ b/drivers/media/i2c/mt9p031.c
@@ -16,9 +16,11 @@
 #include 
 #include 
 #include 
-#include 
 #include 
 #include 
+#include 
+#include 
+#include 
 #include 
 #include 
 #include 
@@ -28,6 +30,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 
 #include "aptina-pll.h"
@@ -928,10 +931,50 @@ static const struct v4l2_subdev_internal_ops 
mt9p031_subdev_internal_ops = {
  * Driver initialization and probing
  */
 
+static struct mt9p031_platform_data *
+mt9p031_get_pdata(struct i2c_client *client)
+{
+   struct device_node *np;
+   struct mt9p031_platform_data *pdata;
+
+   if (!IS_ENABLED(CONFIG_OF) || !client->dev.of_node)
+   return client->dev.platform_data;
+
+   np = v4l2_of_get_next_endpoint(client->dev.of_node, NULL);
+   if (!np)
+   return NULL;
+
+   pdata = devm_kzalloc(&client->dev, sizeof(struct mt9p031_platform_data),
+GFP_KERNEL);
+   if (!pdata)
+   return NULL;
+
+   pdata->reset = of_get_named_gpio(client->dev.of_node, "gpio-reset", 0);
+   of_property_read_u32(np, "input-clock-frequency", &pdata->ext_freq);
+   of_property_read_u32(np, "pixel-clock-frequency", &pdata->target_freq);
+
+   return pdata;
+}
+
+#if IS_ENABLED(CONFIG_OF)
+static const struct of_device_id mt9p031_of_match[] = {
+   {
+   .compatible = "aptina,mt9p031",
+   .data = (void *)MT9P031_MODEL_COLOR,
+   }, {
+   .compatible = "aptina,mt9p031m",
+   .data = (void *)MT9P031_MODEL_MONOCHROME,
+   }, {
+   /* sentinel */
+   },
+};
+MODULE_DEVICE_TABLE(of, mt9p031_of_match);
+#endif
+
 static int mt9p031_probe(struct i2c_client *client,
 const struct i2c_device_id *did)
 {
-   struct mt9p031_platform_data *pdata = client->dev.platform_data;
+   struct mt9p031_platf

[PATCH 42/42] rtc: rtc-tile: remove unnecessary platform_set_drvdata()

[Jingoo Han]

The driver core clears the driver data to NULL after device_release
or on probe failure, since commit 0998d0631001288a5974afc0b2a5f568bcdecb4d
(device-core: Ensure drvdata = NULL when no driver is bound).
Thus, it is not needed to manually clear the device driver data to NULL.

Signed-off-by: Jingoo Han 
---
 drivers/rtc/rtc-tile.c |2 --
 1 files changed, 0 insertions(+), 2 deletions(-)

diff --git a/drivers/rtc/rtc-tile.c b/drivers/rtc/rtc-tile.c
index 249b653..add4a7e 100644
--- a/drivers/rtc/rtc-tile.c
+++ b/drivers/rtc/rtc-tile.c
@@ -96,8 +96,6 @@ static int tile_rtc_probe(struct platform_device *dev)
  */
 static int tile_rtc_remove(struct platform_device *dev)
 {
-   platform_set_drvdata(dev, NULL);
-
return 0;
 }
 
-- 
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 41/42] rtc: rtc-rp5c01: remove unnecessary platform_set_drvdata()

[Jingoo Han]

The driver core clears the driver data to NULL after device_release
or on probe failure, since commit 0998d0631001288a5974afc0b2a5f568bcdecb4d
(device-core: Ensure drvdata = NULL when no driver is bound).
Thus, it is not needed to manually clear the device driver data to NULL.

Signed-off-by: Jingoo Han 
---
 drivers/rtc/rtc-rp5c01.c |   12 +++-
 1 files changed, 3 insertions(+), 9 deletions(-)

diff --git a/drivers/rtc/rtc-rp5c01.c b/drivers/rtc/rtc-rp5c01.c
index 873c689..89d0736 100644
--- a/drivers/rtc/rtc-rp5c01.c
+++ b/drivers/rtc/rtc-rp5c01.c
@@ -251,21 +251,15 @@ static int __init rp5c01_rtc_probe(struct platform_device 
*dev)
 
rtc = devm_rtc_device_register(&dev->dev, "rtc-rp5c01", &rp5c01_rtc_ops,
  THIS_MODULE);
-   if (IS_ERR(rtc)) {
-   error = PTR_ERR(rtc);
-   goto out;
-   }
+   if (IS_ERR(rtc))
+   return PTR_ERR(rtc);
priv->rtc = rtc;
 
error = sysfs_create_bin_file(&dev->dev.kobj, &priv->nvram_attr);
if (error)
-   goto out;
+   return error;
 
return 0;
-
-out:
-   platform_set_drvdata(dev, NULL);
-   return error;
 }
 
 static int __exit rp5c01_rtc_remove(struct platform_device *dev)
-- 
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 40/42] rtc: rtc-puv3: remove unnecessary platform_set_drvdata()

[Jingoo Han]

The driver core clears the driver data to NULL after device_release
or on probe failure, since commit 0998d0631001288a5974afc0b2a5f568bcdecb4d
(device-core: Ensure drvdata = NULL when no driver is bound).
Thus, it is not needed to manually clear the device driver data to NULL.

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

diff --git a/drivers/rtc/rtc-puv3.c b/drivers/rtc/rtc-puv3.c
index 72f4371..402732c 100644
--- a/drivers/rtc/rtc-puv3.c
+++ b/drivers/rtc/rtc-puv3.c
@@ -224,7 +224,6 @@ static int puv3_rtc_remove(struct platform_device *dev)
 {
struct rtc_device *rtc = platform_get_drvdata(dev);
 
-   platform_set_drvdata(dev, NULL);
rtc_device_unregister(rtc);
 
puv3_rtc_setpie(&dev->dev, 0);
-- 
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 34/42] rtc: rtc-spear: remove unnecessary platform_set_drvdata()

[Jingoo Han]

The driver core clears the driver data to NULL after device_release
or on probe failure, since commit 0998d0631001288a5974afc0b2a5f568bcdecb4d
(device-core: Ensure drvdata = NULL when no driver is bound).
Thus, it is not needed to manually clear the device driver data to NULL.

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

diff --git a/drivers/rtc/rtc-spear.c b/drivers/rtc/rtc-spear.c
index 574359c..c492cf0 100644
--- a/drivers/rtc/rtc-spear.c
+++ b/drivers/rtc/rtc-spear.c
@@ -417,7 +417,6 @@ static int spear_rtc_probe(struct platform_device *pdev)
return 0;
 
 err_disable_clock:
-   platform_set_drvdata(pdev, NULL);
clk_disable_unprepare(config->clk);
 
return status;
-- 
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 39/42] rtc: rtc-m48t86: remove unnecessary platform_set_drvdata()

[Jingoo Han]

The driver core clears the driver data to NULL after device_release
or on probe failure, since commit 0998d0631001288a5974afc0b2a5f568bcdecb4d
(device-core: Ensure drvdata = NULL when no driver is bound).
Thus, it is not needed to manually clear the device driver data to NULL.

Signed-off-by: Jingoo Han 
---
 drivers/rtc/rtc-m48t86.c |2 --
 1 files changed, 0 insertions(+), 2 deletions(-)

diff --git a/drivers/rtc/rtc-m48t86.c b/drivers/rtc/rtc-m48t86.c
index 33a91c4..d1fe7f5 100644
--- a/drivers/rtc/rtc-m48t86.c
+++ b/drivers/rtc/rtc-m48t86.c
@@ -168,8 +168,6 @@ static int m48t86_rtc_probe(struct platform_device *dev)
 
 static int m48t86_rtc_remove(struct platform_device *dev)
 {
-   platform_set_drvdata(dev, NULL);
-
return 0;
 }
 
-- 
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 4/4] mtd: gpmi: update the ecc step size for mtd_info{}

[Huang Shijie]

update the ecc step size when we have already get the right value.

Signed-off-by: Huang Shijie 
---
 drivers/mtd/nand/gpmi-nand/gpmi-nand.c |1 +
 1 files changed, 1 insertions(+), 0 deletions(-)

diff --git a/drivers/mtd/nand/gpmi-nand/gpmi-nand.c 
b/drivers/mtd/nand/gpmi-nand/gpmi-nand.c
index 0451a1d..b9e05df 100644
--- a/drivers/mtd/nand/gpmi-nand/gpmi-nand.c
+++ b/drivers/mtd/nand/gpmi-nand/gpmi-nand.c
@@ -1644,6 +1644,7 @@ static int gpmi_pre_bbt_scan(struct gpmi_nand_data  *this)
/* Adjust the ECC strength according to the chip. */
this->nand.ecc.strength = this->bch_geometry.ecc_strength;
this->mtd.ecc_strength = this->bch_geometry.ecc_strength;
+   this->mtd.ecc_size = this->bch_geometry.ecc_chunk_size;
this->mtd.bitflip_threshold = this->bch_geometry.ecc_strength;
 
/* NAND boot init, depends on the gpmi_set_geometry(). */
-- 
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 38/42] rtc: rtc-vt8500: remove unnecessary platform_set_drvdata()

[Jingoo Han]

The driver core clears the driver data to NULL after device_release
or on probe failure, since commit 0998d0631001288a5974afc0b2a5f568bcdecb4d
(device-core: Ensure drvdata = NULL when no driver is bound).
Thus, it is not needed to manually clear the device driver data to NULL.

Signed-off-by: Jingoo Han 
---
 drivers/rtc/rtc-vt8500.c |2 --
 1 files changed, 0 insertions(+), 2 deletions(-)

diff --git a/drivers/rtc/rtc-vt8500.c b/drivers/rtc/rtc-vt8500.c
index d89efee..c2d6331 100644
--- a/drivers/rtc/rtc-vt8500.c
+++ b/drivers/rtc/rtc-vt8500.c
@@ -282,8 +282,6 @@ static int vt8500_rtc_remove(struct platform_device *pdev)
/* Disable alarm matching */
writel(0, vt8500_rtc->regbase + VT8500_RTC_IS);
 
-   platform_set_drvdata(pdev, NULL);
-
return 0;
 }
 
-- 
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 37/42] rtc: rtc-vr41xx: remove unnecessary platform_set_drvdata()

[Jingoo Han]

The driver core clears the driver data to NULL after device_release
or on probe failure, since commit 0998d0631001288a5974afc0b2a5f568bcdecb4d
(device-core: Ensure drvdata = NULL when no driver is bound).
Thus, it is not needed to manually clear the device driver data to NULL.

Signed-off-by: Jingoo Han 
---
 drivers/rtc/rtc-vr41xx.c |2 --
 1 files changed, 0 insertions(+), 2 deletions(-)

diff --git a/drivers/rtc/rtc-vr41xx.c b/drivers/rtc/rtc-vr41xx.c
index f91be04..30dd89b 100644
--- a/drivers/rtc/rtc-vr41xx.c
+++ b/drivers/rtc/rtc-vr41xx.c
@@ -381,8 +381,6 @@ static int rtc_remove(struct platform_device *pdev)
if (rtc)
rtc_device_unregister(rtc);
 
-   platform_set_drvdata(pdev, NULL);
-
free_irq(aie_irq, pdev);
free_irq(pie_irq, pdev);
if (rtc1_base)
-- 
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 36/42] rtc: rtc-twl: remove unnecessary platform_set_drvdata()

[Jingoo Han]

The driver core clears the driver data to NULL after device_release
or on probe failure, since commit 0998d0631001288a5974afc0b2a5f568bcdecb4d
(device-core: Ensure drvdata = NULL when no driver is bound).
Thus, it is not needed to manually clear the device driver data to NULL.

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

diff --git a/drivers/rtc/rtc-twl.c b/drivers/rtc/rtc-twl.c
index 8751a52..103fea2 100644
--- a/drivers/rtc/rtc-twl.c
+++ b/drivers/rtc/rtc-twl.c
@@ -555,7 +555,6 @@ static int twl_rtc_remove(struct platform_device *pdev)
free_irq(irq, rtc);
 
rtc_device_unregister(rtc);
-   platform_set_drvdata(pdev, NULL);
return 0;
 }
 
-- 
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 V2] Staging: add USB MTK bluetooth driver

[Cho, Yu-Chen]

From: "Cho, Yu-Chen" 

This driver is for the Mediatek Bluetooth that can be found in many
different laptops.  It was written by Mediatek, but cleaned up to
work properly in the kernel tree by SUSE.

--
Changes since v1:
 1.fixed built error , because build path typo.
 2.change to correct version number.
--

Signed-off-by: Cho, Yu-Chen 
---
 drivers/staging/Kconfig   |2 +
 drivers/staging/Makefile  |1 +
 drivers/staging/btmtk_usb/Kconfig |   11 +
 drivers/staging/btmtk_usb/Makefile|1 +
 drivers/staging/btmtk_usb/README  |   14 +
 drivers/staging/btmtk_usb/TODO|9 +
 drivers/staging/btmtk_usb/btmtk_usb.c | 1793 +
 drivers/staging/btmtk_usb/btmtk_usb.h |  138 +++
 8 files changed, 1969 insertions(+)
 create mode 100644 drivers/staging/btmtk_usb/Kconfig
 create mode 100644 drivers/staging/btmtk_usb/Makefile
 create mode 100644 drivers/staging/btmtk_usb/README
 create mode 100644 drivers/staging/btmtk_usb/TODO
 create mode 100644 drivers/staging/btmtk_usb/btmtk_usb.c
 create mode 100644 drivers/staging/btmtk_usb/btmtk_usb.h

diff --git a/drivers/staging/Kconfig b/drivers/staging/Kconfig
index 093f10c..fe8dec0 100644
--- a/drivers/staging/Kconfig
+++ b/drivers/staging/Kconfig
@@ -140,4 +140,6 @@ source "drivers/staging/zcache/Kconfig"
 
 source "drivers/staging/goldfish/Kconfig"
 
+source "drivers/staging/btmtk_usb/Kconfig"
+
 endif # STAGING
diff --git a/drivers/staging/Makefile b/drivers/staging/Makefile
index fa41b04..14c30dd 100644
--- a/drivers/staging/Makefile
+++ b/drivers/staging/Makefile
@@ -62,3 +62,4 @@ obj-$(CONFIG_SB105X)  += sb105x/
 obj-$(CONFIG_FIREWIRE_SERIAL)  += fwserial/
 obj-$(CONFIG_ZCACHE)   += zcache/
 obj-$(CONFIG_GOLDFISH) += goldfish/
+obj-$(CONFIG_USB_BTMTK)+= btmtk_usb/
diff --git a/drivers/staging/btmtk_usb/Kconfig 
b/drivers/staging/btmtk_usb/Kconfig
new file mode 100644
index 000..a425ebd
--- /dev/null
+++ b/drivers/staging/btmtk_usb/Kconfig
@@ -0,0 +1,11 @@
+config USB_BTMTK
+   tristate "Mediatek Bluetooth support"
+   depends on USB && BT && m
+   ---help---
+ Say Y here if you wish to control a MTK USB Bluetooth.
+
+ This option depends on 'USB' support being enabled
+
+ To compile this driver as a module, choose M here: the
+ module will be called btmtk_usb.
+
diff --git a/drivers/staging/btmtk_usb/Makefile 
b/drivers/staging/btmtk_usb/Makefile
new file mode 100644
index 000..4d6c9d7
--- /dev/null
+++ b/drivers/staging/btmtk_usb/Makefile
@@ -0,0 +1 @@
+obj-$(CONFIG_USB_BTMTK)+= btmtk_usb.o
diff --git a/drivers/staging/btmtk_usb/README b/drivers/staging/btmtk_usb/README
new file mode 100644
index 000..c046c8e
--- /dev/null
+++ b/drivers/staging/btmtk_usb/README
@@ -0,0 +1,14 @@
+-build driver modules
+   make
+
+-install driver modules
+   make install
+
+-remove driver modules
+   make clean
+
+-dynamic debug message
+   turn on CONFIG_DYNAMIC_DEBUG compiler flag for current kernel
+   mount -t debugfs none /sys/kernel/debug/
+   echo "module module_name +p" > 
/sys/kernel/debug/dynamic_debug/control(turn on debug messages, module name 
such as btmtk_usb)
+   echo "module module_name -p" > 
/sys/kernel/debug/dynamic_debug/control(turn off debug messages, module name 
such as btmtk_usb)
diff --git a/drivers/staging/btmtk_usb/TODO b/drivers/staging/btmtk_usb/TODO
new file mode 100644
index 000..30fddde
--- /dev/null
+++ b/drivers/staging/btmtk_usb/TODO
@@ -0,0 +1,9 @@
+TODO:
+- checkpatch.pl clean
+   - determine if the driver should not be using a duplicate
+  version of the usb-bluetooth interface code, but should
+  be merged into the drivers/bluetooth/ directory and
+  infrastructure instead.
+   - review by the bluetooth developer community
+
+Please send any patches for this driver to Yu-Chen, Cho  and
diff --git a/drivers/staging/btmtk_usb/btmtk_usb.c 
b/drivers/staging/btmtk_usb/btmtk_usb.c
new file mode 100644
index 000..6b01f61
--- /dev/null
+++ b/drivers/staging/btmtk_usb/btmtk_usb.c
@@ -0,0 +1,1793 @@
+/*
+ *  MediaTek Bluetooth USB Driver
+ *
+ *  Copyright (C) 2013, MediaTek co.
+ *
+ *  This program is free software; you can redistribute it and/or modify
+ *  it under the terms of the GNU General Public License as published by
+ *  the Free Software Foundation; either version 2 of the License, or
+ *  (at your option) any later version.
+ *
+ *  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-1

[PATCH 2/4] mtd: add a new sys node to show the ecc step size

[Huang Shijie]

Add a new sys node to show the ecc step size.
The application then can uses this node to get the ecc step
size.

Signed-off-by: Huang Shijie 
---
 drivers/mtd/mtdcore.c |   11 +++
 1 files changed, 11 insertions(+), 0 deletions(-)

diff --git a/drivers/mtd/mtdcore.c b/drivers/mtd/mtdcore.c
index e513fc4..2ed2827 100644
--- a/drivers/mtd/mtdcore.c
+++ b/drivers/mtd/mtdcore.c
@@ -287,6 +287,16 @@ static DEVICE_ATTR(bitflip_threshold, S_IRUGO | S_IWUSR,
   mtd_bitflip_threshold_show,
   mtd_bitflip_threshold_store);
 
+static ssize_t mtd_ecc_size_show(struct device *dev,
+   struct device_attribute *attr, char *buf)
+{
+   struct mtd_info *mtd = dev_get_drvdata(dev);
+
+   return snprintf(buf, PAGE_SIZE, "%lu\n", (unsigned long)mtd->ecc_size);
+
+}
+static DEVICE_ATTR(ecc_size, S_IRUGO, mtd_ecc_size_show, NULL);
+
 static struct attribute *mtd_attrs[] = {
&dev_attr_type.attr,
&dev_attr_flags.attr,
@@ -298,6 +308,7 @@ static struct attribute *mtd_attrs[] = {
&dev_attr_numeraseregions.attr,
&dev_attr_name.attr,
&dev_attr_ecc_strength.attr,
+   &dev_attr_ecc_size.attr,
&dev_attr_bitflip_threshold.attr,
NULL,
 };
-- 
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 35/42] rtc: rtc-stmp3xxx: remove unnecessary platform_set_drvdata()

[Jingoo Han]

The driver core clears the driver data to NULL after device_release
or on probe failure, since commit 0998d0631001288a5974afc0b2a5f568bcdecb4d
(device-core: Ensure drvdata = NULL when no driver is bound).
Thus, it is not needed to manually clear the device driver data to NULL.

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

diff --git a/drivers/rtc/rtc-stmp3xxx.c b/drivers/rtc/rtc-stmp3xxx.c
index 483ce08..90a3e86 100644
--- a/drivers/rtc/rtc-stmp3xxx.c
+++ b/drivers/rtc/rtc-stmp3xxx.c
@@ -225,7 +225,6 @@ static int stmp3xxx_rtc_remove(struct platform_device *pdev)
 
writel(STMP3XXX_RTC_CTRL_ALARM_IRQ_EN,
rtc_data->io + STMP3XXX_RTC_CTRL_CLR);
-   platform_set_drvdata(pdev, NULL);
 
return 0;
 }
@@ -274,25 +273,19 @@ static int stmp3xxx_rtc_probe(struct platform_device 
*pdev)
 
rtc_data->rtc = devm_rtc_device_register(&pdev->dev, pdev->name,
&stmp3xxx_rtc_ops, THIS_MODULE);
-   if (IS_ERR(rtc_data->rtc)) {
-   err = PTR_ERR(rtc_data->rtc);
-   goto out;
-   }
+   if (IS_ERR(rtc_data->rtc))
+   return PTR_ERR(rtc_data->rtc);
 
err = devm_request_irq(&pdev->dev, rtc_data->irq_alarm,
stmp3xxx_rtc_interrupt, 0, "RTC alarm", &pdev->dev);
if (err) {
dev_err(&pdev->dev, "Cannot claim IRQ%d\n",
rtc_data->irq_alarm);
-   goto out;
+   return err;
}
 
stmp3xxx_wdt_register(pdev);
return 0;
-
-out:
-   platform_set_drvdata(pdev, NULL);
-   return err;
 }
 
 #ifdef CONFIG_PM_SLEEP
-- 
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 33/42] rtc: rtc-sh: remove unnecessary platform_set_drvdata()

[Jingoo Han]

The driver core clears the driver data to NULL after device_release
or on probe failure, since commit 0998d0631001288a5974afc0b2a5f568bcdecb4d
(device-core: Ensure drvdata = NULL when no driver is bound).
Thus, it is not needed to manually clear the device driver data to NULL.

Signed-off-by: Jingoo Han 
---
 drivers/rtc/rtc-sh.c |2 --
 1 files changed, 0 insertions(+), 2 deletions(-)

diff --git a/drivers/rtc/rtc-sh.c b/drivers/rtc/rtc-sh.c
index 8d5bd2e..cb2f839 100644
--- a/drivers/rtc/rtc-sh.c
+++ b/drivers/rtc/rtc-sh.c
@@ -770,8 +770,6 @@ static int __exit sh_rtc_remove(struct platform_device 
*pdev)
clk_disable(rtc->clk);
clk_put(rtc->clk);
 
-   platform_set_drvdata(pdev, NULL);
-
kfree(rtc);
 
return 0;
-- 
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 31/42] rtc: rtc-s3c: remove unnecessary platform_set_drvdata()

[Jingoo Han]

The driver core clears the driver data to NULL after device_release
or on probe failure, since commit 0998d0631001288a5974afc0b2a5f568bcdecb4d
(device-core: Ensure drvdata = NULL when no driver is bound).
Thus, it is not needed to manually clear the device driver data to NULL.

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

diff --git a/drivers/rtc/rtc-s3c.c b/drivers/rtc/rtc-s3c.c
index 14040b2..4d38c6b 100644
--- a/drivers/rtc/rtc-s3c.c
+++ b/drivers/rtc/rtc-s3c.c
@@ -421,8 +421,6 @@ static void s3c_rtc_enable(struct platform_device *pdev, 
int en)
 
 static int s3c_rtc_remove(struct platform_device *dev)
 {
-   platform_set_drvdata(dev, NULL);
-
s3c_rtc_setaie(&dev->dev, 0);
 
clk_unprepare(rtc_clk);
@@ -554,23 +552,20 @@ static int s3c_rtc_probe(struct platform_device *pdev)
  0,  "s3c2410-rtc alarm", rtc);
if (ret) {
dev_err(&pdev->dev, "IRQ%d error %d\n", s3c_rtc_alarmno, ret);
-   goto err_alarm_irq;
+   goto err_nortc;
}
 
ret = devm_request_irq(&pdev->dev, s3c_rtc_tickno, s3c_rtc_tickirq,
  0,  "s3c2410-rtc tick", rtc);
if (ret) {
dev_err(&pdev->dev, "IRQ%d error %d\n", s3c_rtc_tickno, ret);
-   goto err_alarm_irq;
+   goto err_nortc;
}
 
clk_disable(rtc_clk);
 
return 0;
 
- err_alarm_irq:
-   platform_set_drvdata(pdev, NULL);
-
  err_nortc:
s3c_rtc_enable(pdev, 0);
clk_disable_unprepare(rtc_clk);
-- 
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 32/42] rtc: rtc-sa1100: remove unnecessary platform_set_drvdata()

[Jingoo Han]

The driver core clears the driver data to NULL after device_release
or on probe failure, since commit 0998d0631001288a5974afc0b2a5f568bcdecb4d
(device-core: Ensure drvdata = NULL when no driver is bound).
Thus, it is not needed to manually clear the device driver data to NULL.

Signed-off-by: Jingoo Han 
---
 drivers/rtc/rtc-sa1100.c |8 ++--
 1 files changed, 2 insertions(+), 6 deletions(-)

diff --git a/drivers/rtc/rtc-sa1100.c b/drivers/rtc/rtc-sa1100.c
index 0060560..0f7adeb 100644
--- a/drivers/rtc/rtc-sa1100.c
+++ b/drivers/rtc/rtc-sa1100.c
@@ -249,7 +249,7 @@ static int sa1100_rtc_probe(struct platform_device *pdev)
 
ret = clk_prepare_enable(info->clk);
if (ret)
-   goto err_enable_clk;
+   return ret;
/*
 * According to the manual we should be able to let RTTR be zero
 * and then a default diviser for a 32.768KHz clock is used.
@@ -303,8 +303,6 @@ static int sa1100_rtc_probe(struct platform_device *pdev)
return 0;
 err_dev:
clk_disable_unprepare(info->clk);
-err_enable_clk:
-   platform_set_drvdata(pdev, NULL);
return ret;
 }
 
@@ -312,10 +310,8 @@ static int sa1100_rtc_remove(struct platform_device *pdev)
 {
struct sa1100_rtc *info = platform_get_drvdata(pdev);
 
-   if (info) {
+   if (info)
clk_disable_unprepare(info->clk);
-   platform_set_drvdata(pdev, NULL);
-   }
 
return 0;
 }
-- 
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 29/42] rtc: rtc-pcap: remove unnecessary platform_set_drvdata()

[Jingoo Han]

The driver core clears the driver data to NULL after device_release
or on probe failure, since commit 0998d0631001288a5974afc0b2a5f568bcdecb4d
(device-core: Ensure drvdata = NULL when no driver is bound).
Thus, it is not needed to manually clear the device driver data to NULL.

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

diff --git a/drivers/rtc/rtc-pcap.c b/drivers/rtc/rtc-pcap.c
index 539a90b..40b5c63 100644
--- a/drivers/rtc/rtc-pcap.c
+++ b/drivers/rtc/rtc-pcap.c
@@ -156,10 +156,8 @@ static int __init pcap_rtc_probe(struct platform_device 
*pdev)
 
pcap_rtc->rtc = devm_rtc_device_register(&pdev->dev, "pcap",
&pcap_rtc_ops, THIS_MODULE);
-   if (IS_ERR(pcap_rtc->rtc)) {
-   err = PTR_ERR(pcap_rtc->rtc);
-   goto fail;
-   }
+   if (IS_ERR(pcap_rtc->rtc))
+   return PTR_ERR(pcap_rtc->rtc);
 
timer_irq = pcap_to_irq(pcap_rtc->pcap, PCAP_IRQ_1HZ);
alarm_irq = pcap_to_irq(pcap_rtc->pcap, PCAP_IRQ_TODA);
@@ -167,17 +165,14 @@ static int __init pcap_rtc_probe(struct platform_device 
*pdev)
err = devm_request_irq(&pdev->dev, timer_irq, pcap_rtc_irq, 0,
"RTC Timer", pcap_rtc);
if (err)
-   goto fail;
+   return err;
 
err = devm_request_irq(&pdev->dev, alarm_irq, pcap_rtc_irq, 0,
"RTC Alarm", pcap_rtc);
if (err)
-   goto fail;
+   return err;
 
return 0;
-fail:
-   platform_set_drvdata(pdev, NULL);
-   return err;
 }
 
 static int __exit pcap_rtc_remove(struct platform_device *pdev)
-- 
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 30/42] rtc: rtc-pm8xxx: remove unnecessary platform_set_drvdata()

[Jingoo Han]

The driver core clears the driver data to NULL after device_release
or on probe failure, since commit 0998d0631001288a5974afc0b2a5f568bcdecb4d
(device-core: Ensure drvdata = NULL when no driver is bound).
Thus, it is not needed to manually clear the device driver data to NULL.

Signed-off-by: Jingoo Han 
---
 drivers/rtc/rtc-pm8xxx.c |2 --
 1 files changed, 0 insertions(+), 2 deletions(-)

diff --git a/drivers/rtc/rtc-pm8xxx.c b/drivers/rtc/rtc-pm8xxx.c
index f1a6557..14ee860 100644
--- a/drivers/rtc/rtc-pm8xxx.c
+++ b/drivers/rtc/rtc-pm8xxx.c
@@ -480,7 +480,6 @@ static int pm8xxx_rtc_probe(struct platform_device *pdev)
 fail_req_irq:
rtc_device_unregister(rtc_dd->rtc);
 fail_rtc_enable:
-   platform_set_drvdata(pdev, NULL);
kfree(rtc_dd);
return rc;
 }
@@ -492,7 +491,6 @@ static int pm8xxx_rtc_remove(struct platform_device *pdev)
device_init_wakeup(&pdev->dev, 0);
free_irq(rtc_dd->rtc_alarm_irq, rtc_dd);
rtc_device_unregister(rtc_dd->rtc);
-   platform_set_drvdata(pdev, NULL);
kfree(rtc_dd);
 
return 0;
-- 
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 0/4] Export the ecc step size to user applications

[Huang Shijie]

In order to implement the NAND boot for some Freescale's chips, such as
imx23/imx28/imx50/imx6, we use a tool (called kobs-ng) to burn the uboot
and some metadata to nand chip. And the ROM code will use the metadata to
configrate the BCH, and to find the uboot.

The ECC information(ecc step size, ecc strength) which is used to configrate
the BCH is part of the metadata. The kobs-ng can gets the ecc strength from
the sys node /sys/*/mtdX/ecc_strength now. But it can't gets the ecc step size.

This patch set is used to export the ecc step size to user applications.
With this patch set, the kobs-ng can gets the ecc step size now.


Huang Shijie (4):
  mtd: add a new field to mtd_info{}
  mtd: add a new sys node to show the ecc step size
  mtd: set the ecc step size for master/slave mtd_info
  mtd: gpmi: update the ecc step size for mtd_info{}

 drivers/mtd/mtdcore.c  |   11 +++
 drivers/mtd/mtdpart.c  |1 +
 drivers/mtd/nand/gpmi-nand/gpmi-nand.c |1 +
 drivers/mtd/nand/nand_base.c   |1 +
 include/linux/mtd/mtd.h|3 +++
 5 files changed, 17 insertions(+), 0 deletions(-)


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

[PATCH 3/4] mtd: set the ecc step size for master/slave mtd_info

[Huang Shijie]

Set the ecc step size for master/slave mtd_info{}.

Signed-off-by: Huang Shijie 
---
 drivers/mtd/mtdpart.c|1 +
 drivers/mtd/nand/nand_base.c |1 +
 2 files changed, 2 insertions(+), 0 deletions(-)

diff --git a/drivers/mtd/mtdpart.c b/drivers/mtd/mtdpart.c
index 3014933..e948eb6 100644
--- a/drivers/mtd/mtdpart.c
+++ b/drivers/mtd/mtdpart.c
@@ -516,6 +516,7 @@ static struct mtd_part *allocate_partition(struct mtd_info 
*master,
}
 
slave->mtd.ecclayout = master->ecclayout;
+   slave->mtd.ecc_size = master->ecc_size;
slave->mtd.ecc_strength = master->ecc_strength;
slave->mtd.bitflip_threshold = master->bitflip_threshold;
 
diff --git a/drivers/mtd/nand/nand_base.c b/drivers/mtd/nand/nand_base.c
index 92d0548..9de7cda 100644
--- a/drivers/mtd/nand/nand_base.c
+++ b/drivers/mtd/nand/nand_base.c
@@ -3760,6 +3760,7 @@ int nand_scan_tail(struct mtd_info *mtd)
/* propagate ecc info to mtd_info */
mtd->ecclayout = chip->ecc.layout;
mtd->ecc_strength = chip->ecc.strength;
+   mtd->ecc_size = chip->ecc.size;
/*
 * Initialize bitflip_threshold to its default prior scan_bbt() call.
 * scan_bbt() might invoke mtd_read(), thus bitflip_threshold must be
-- 
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 1/4] mtd: add a new field to mtd_info{}

[Huang Shijie]

In order to implement the NAND boot for some Freescale's chips, such as
imx23/imx28/imx50/imx6, we use a tool (called kobs-ng) to burn the uboot
and some metadata to nand chip. And the ROM code will use the metadata to
configrate the BCH, and to find the uboot.

The ECC information(ecc step size, ecc strength) which is used to configrate
the BCH is part of the metadata. The kobs-ng can gets the ecc strength from
the sys node /sys/*/ecc_strength now. But it can not gets the ecc step size.

This patch adds a new field to store the ecc step size in mtd_info{}, and
it makes preparation for the next patches.

Signed-off-by: Huang Shijie 
---
 include/linux/mtd/mtd.h |3 +++
 1 files changed, 3 insertions(+), 0 deletions(-)

diff --git a/include/linux/mtd/mtd.h b/include/linux/mtd/mtd.h
index 183a304..b93035f 100644
--- a/include/linux/mtd/mtd.h
+++ b/include/linux/mtd/mtd.h
@@ -173,6 +173,9 @@ struct mtd_info {
/* ECC layout structure pointer - read only! */
struct nand_ecclayout *ecclayout;
 
+   /* the ecc step size. */
+   unsigned int ecc_size;
+
/* max number of correctible bit errors per ecc step */
unsigned int ecc_strength;
 
-- 
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 28/42] rtc: rtc-nuc900: remove unnecessary platform_set_drvdata()

[Jingoo Han]

The driver core clears the driver data to NULL after device_release
or on probe failure, since commit 0998d0631001288a5974afc0b2a5f568bcdecb4d
(device-core: Ensure drvdata = NULL when no driver is bound).
Thus, it is not needed to manually clear the device driver data to NULL.

Signed-off-by: Jingoo Han 
---
 drivers/rtc/rtc-nuc900.c |2 --
 1 files changed, 0 insertions(+), 2 deletions(-)

diff --git a/drivers/rtc/rtc-nuc900.c b/drivers/rtc/rtc-nuc900.c
index f5dfb6e..90ca8aa 100644
--- a/drivers/rtc/rtc-nuc900.c
+++ b/drivers/rtc/rtc-nuc900.c
@@ -267,8 +267,6 @@ static int __init nuc900_rtc_probe(struct platform_device 
*pdev)
 
 static int __exit nuc900_rtc_remove(struct platform_device *pdev)
 {
-   platform_set_drvdata(pdev, NULL);
-
return 0;
 }
 
-- 
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 27/42] rtc: rtc-mxc: remove unnecessary platform_set_drvdata()

[Jingoo Han]

The driver core clears the driver data to NULL after device_release
or on probe failure, since commit 0998d0631001288a5974afc0b2a5f568bcdecb4d
(device-core: Ensure drvdata = NULL when no driver is bound).
Thus, it is not needed to manually clear the device driver data to NULL.

Signed-off-by: Jingoo Han 
---
 drivers/rtc/rtc-mxc.c |5 +
 1 files changed, 1 insertions(+), 4 deletions(-)

diff --git a/drivers/rtc/rtc-mxc.c b/drivers/rtc/rtc-mxc.c
index 9a3895b..57192c7 100644
--- a/drivers/rtc/rtc-mxc.c
+++ b/drivers/rtc/rtc-mxc.c
@@ -443,15 +443,13 @@ static int mxc_rtc_probe(struct platform_device *pdev)
  THIS_MODULE);
if (IS_ERR(rtc)) {
ret = PTR_ERR(rtc);
-   goto exit_clr_drvdata;
+   goto exit_put_clk;
}
 
pdata->rtc = rtc;
 
return 0;
 
-exit_clr_drvdata:
-   platform_set_drvdata(pdev, NULL);
 exit_put_clk:
clk_disable_unprepare(pdata->clk);
 
@@ -465,7 +463,6 @@ static int mxc_rtc_remove(struct platform_device *pdev)
struct rtc_plat_data *pdata = platform_get_drvdata(pdev);
 
clk_disable_unprepare(pdata->clk);
-   platform_set_drvdata(pdev, NULL);
 
return 0;
 }
-- 
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 25/42] rtc: rtc-mc13xxx: remove unnecessary platform_set_drvdata()

[Jingoo Han]

The driver core clears the driver data to NULL after device_release
or on probe failure, since commit 0998d0631001288a5974afc0b2a5f568bcdecb4d
(device-core: Ensure drvdata = NULL when no driver is bound).
Thus, it is not needed to manually clear the device driver data to NULL.

Signed-off-by: Jingoo Han 
---
 drivers/rtc/rtc-mc13xxx.c |4 
 1 files changed, 0 insertions(+), 4 deletions(-)

diff --git a/drivers/rtc/rtc-mc13xxx.c b/drivers/rtc/rtc-mc13xxx.c
index 7a8ed27..77ea989 100644
--- a/drivers/rtc/rtc-mc13xxx.c
+++ b/drivers/rtc/rtc-mc13xxx.c
@@ -370,8 +370,6 @@ err_reset_irq_status:
 err_reset_irq_request:
 
mc13xxx_unlock(mc13xxx);
-
-   platform_set_drvdata(pdev, NULL);
}
 
return ret;
@@ -389,8 +387,6 @@ static int __exit mc13xxx_rtc_remove(struct platform_device 
*pdev)
 
mc13xxx_unlock(priv->mc13xxx);
 
-   platform_set_drvdata(pdev, NULL);
-
return 0;
 }
 
-- 
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 26/42] rtc: rtc-msm6242: remove unnecessary platform_set_drvdata()

[Jingoo Han]

The driver core clears the driver data to NULL after device_release
or on probe failure, since commit 0998d0631001288a5974afc0b2a5f568bcdecb4d
(device-core: Ensure drvdata = NULL when no driver is bound).
Thus, it is not needed to manually clear the device driver data to NULL.

Signed-off-by: Jingoo Han 
---
 drivers/rtc/rtc-msm6242.c |   11 ++-
 1 files changed, 2 insertions(+), 9 deletions(-)

diff --git a/drivers/rtc/rtc-msm6242.c b/drivers/rtc/rtc-msm6242.c
index 771f86a..3b300ec 100644
--- a/drivers/rtc/rtc-msm6242.c
+++ b/drivers/rtc/rtc-msm6242.c
@@ -199,7 +199,6 @@ static int __init msm6242_rtc_probe(struct platform_device 
*pdev)
struct resource *res;
struct msm6242_priv *priv;
struct rtc_device *rtc;
-   int error;
 
res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
if (!res)
@@ -216,17 +215,11 @@ static int __init msm6242_rtc_probe(struct 
platform_device *pdev)
 
rtc = devm_rtc_device_register(&pdev->dev, "rtc-msm6242",
&msm6242_rtc_ops, THIS_MODULE);
-   if (IS_ERR(rtc)) {
-   error = PTR_ERR(rtc);
-   goto out_unmap;
-   }
+   if (IS_ERR(rtc))
+   return PTR_ERR(rtc);
 
priv->rtc = rtc;
return 0;
-
-out_unmap:
-   platform_set_drvdata(pdev, NULL);
-   return error;
 }
 
 static int __exit msm6242_rtc_remove(struct platform_device *pdev)
-- 
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 24/42] rtc: rtc-max8998: remove unnecessary platform_set_drvdata()

[Jingoo Han]

The driver core clears the driver data to NULL after device_release
or on probe failure, since commit 0998d0631001288a5974afc0b2a5f568bcdecb4d
(device-core: Ensure drvdata = NULL when no driver is bound).
Thus, it is not needed to manually clear the device driver data to NULL.

Signed-off-by: Jingoo Han 
---
 drivers/rtc/rtc-max8998.c |6 +-
 1 files changed, 1 insertions(+), 5 deletions(-)

diff --git a/drivers/rtc/rtc-max8998.c b/drivers/rtc/rtc-max8998.c
index 48b6612..b93842d 100644
--- a/drivers/rtc/rtc-max8998.c
+++ b/drivers/rtc/rtc-max8998.c
@@ -274,7 +274,7 @@ static int max8998_rtc_probe(struct platform_device *pdev)
if (IS_ERR(info->rtc_dev)) {
ret = PTR_ERR(info->rtc_dev);
dev_err(&pdev->dev, "Failed to register RTC device: %d\n", ret);
-   goto out_rtc;
+   return ret;
}
 
ret = devm_request_threaded_irq(&pdev->dev, info->irq, NULL,
@@ -292,10 +292,6 @@ static int max8998_rtc_probe(struct platform_device *pdev)
}
 
return 0;
-
-out_rtc:
-   platform_set_drvdata(pdev, NULL);
-   return ret;
 }
 
 static int max8998_rtc_remove(struct platform_device *pdev)
-- 
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 23/42] rtc: rtc-max8925: remove unnecessary platform_set_drvdata()

[Jingoo Han]

The driver core clears the driver data to NULL after device_release
or on probe failure, since commit 0998d0631001288a5974afc0b2a5f568bcdecb4d
(device-core: Ensure drvdata = NULL when no driver is bound).
Thus, it is not needed to manually clear the device driver data to NULL.

Signed-off-by: Jingoo Han 
---
 drivers/rtc/rtc-max8925.c |7 ++-
 1 files changed, 2 insertions(+), 5 deletions(-)

diff --git a/drivers/rtc/rtc-max8925.c b/drivers/rtc/rtc-max8925.c
index 7c90f4e..981b654 100644
--- a/drivers/rtc/rtc-max8925.c
+++ b/drivers/rtc/rtc-max8925.c
@@ -268,7 +268,7 @@ static int max8925_rtc_probe(struct platform_device *pdev)
if (ret < 0) {
dev_err(chip->dev, "Failed to request IRQ: #%d: %d\n",
info->irq, ret);
-   goto err;
+   return ret;
}
 
dev_set_drvdata(&pdev->dev, info);
@@ -282,13 +282,10 @@ static int max8925_rtc_probe(struct platform_device *pdev)
ret = PTR_ERR(info->rtc_dev);
if (IS_ERR(info->rtc_dev)) {
dev_err(&pdev->dev, "Failed to register RTC device: %d\n", ret);
-   goto err;
+   return ret;
}
 
return 0;
-err:
-   platform_set_drvdata(pdev, NULL);
-   return ret;
 }
 
 static int max8925_rtc_remove(struct platform_device *pdev)
-- 
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 22/42] rtc: rtc-m48t59: remove unnecessary platform_set_drvdata()

[Jingoo Han]

The driver core clears the driver data to NULL after device_release
or on probe failure, since commit 0998d0631001288a5974afc0b2a5f568bcdecb4d
(device-core: Ensure drvdata = NULL when no driver is bound).
Thus, it is not needed to manually clear the device driver data to NULL.

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

diff --git a/drivers/rtc/rtc-m48t59.c b/drivers/rtc/rtc-m48t59.c
index 130f29a..d4d31fa 100644
--- a/drivers/rtc/rtc-m48t59.c
+++ b/drivers/rtc/rtc-m48t59.c
@@ -513,7 +513,6 @@ static int m48t59_rtc_remove(struct platform_device *pdev)
iounmap(m48t59->ioaddr);
if (m48t59->irq != NO_IRQ)
free_irq(m48t59->irq, &pdev->dev);
-   platform_set_drvdata(pdev, NULL);
kfree(m48t59);
return 0;
 }
-- 
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 20/42] rtc: rtc-lpc32xx: remove unnecessary platform_set_drvdata()

[Jingoo Han]

The driver core clears the driver data to NULL after device_release
or on probe failure, since commit 0998d0631001288a5974afc0b2a5f568bcdecb4d
(device-core: Ensure drvdata = NULL when no driver is bound).
Thus, it is not needed to manually clear the device driver data to NULL.

Signed-off-by: Jingoo Han 
---
 drivers/rtc/rtc-lpc32xx.c |3 ---
 1 files changed, 0 insertions(+), 3 deletions(-)

diff --git a/drivers/rtc/rtc-lpc32xx.c b/drivers/rtc/rtc-lpc32xx.c
index 787550d..8276ae9 100644
--- a/drivers/rtc/rtc-lpc32xx.c
+++ b/drivers/rtc/rtc-lpc32xx.c
@@ -277,7 +277,6 @@ static int lpc32xx_rtc_probe(struct platform_device *pdev)
&lpc32xx_rtc_ops, THIS_MODULE);
if (IS_ERR(rtc->rtc)) {
dev_err(&pdev->dev, "Can't get RTC\n");
-   platform_set_drvdata(pdev, NULL);
return PTR_ERR(rtc->rtc);
}
 
@@ -306,8 +305,6 @@ static int lpc32xx_rtc_remove(struct platform_device *pdev)
if (rtc->irq >= 0)
device_init_wakeup(&pdev->dev, 0);
 
-   platform_set_drvdata(pdev, NULL);
-
return 0;
 }
 
-- 
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 21/42] rtc: rtc-ls1x: remove unnecessary platform_set_drvdata()

[Jingoo Han]

The driver core clears the driver data to NULL after device_release
or on probe failure, since commit 0998d0631001288a5974afc0b2a5f568bcdecb4d
(device-core: Ensure drvdata = NULL when no driver is bound).
Thus, it is not needed to manually clear the device driver data to NULL.

Signed-off-by: Jingoo Han 
---
 drivers/rtc/rtc-ls1x.c |2 --
 1 files changed, 0 insertions(+), 2 deletions(-)

diff --git a/drivers/rtc/rtc-ls1x.c b/drivers/rtc/rtc-ls1x.c
index db82f91..e913f38 100644
--- a/drivers/rtc/rtc-ls1x.c
+++ b/drivers/rtc/rtc-ls1x.c
@@ -187,8 +187,6 @@ err:
 
 static int ls1x_rtc_remove(struct platform_device *pdev)
 {
-   platform_set_drvdata(pdev, NULL);
-
return 0;
 }
 
-- 
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 19/42] rtc: rtc-lp8788: remove unnecessary platform_set_drvdata()

[Jingoo Han]

The driver core clears the driver data to NULL after device_release
or on probe failure, since commit 0998d0631001288a5974afc0b2a5f568bcdecb4d
(device-core: Ensure drvdata = NULL when no driver is bound).
Thus, it is not needed to manually clear the device driver data to NULL.

Signed-off-by: Jingoo Han 
---
 drivers/rtc/rtc-lp8788.c |2 --
 1 files changed, 0 insertions(+), 2 deletions(-)

diff --git a/drivers/rtc/rtc-lp8788.c b/drivers/rtc/rtc-lp8788.c
index 9853ac1..76a82dc 100644
--- a/drivers/rtc/rtc-lp8788.c
+++ b/drivers/rtc/rtc-lp8788.c
@@ -314,8 +314,6 @@ static int lp8788_rtc_probe(struct platform_device *pdev)
 
 static int lp8788_rtc_remove(struct platform_device *pdev)
 {
-   platform_set_drvdata(pdev, NULL);
-
return 0;
 }
 
-- 
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 18/42] rtc: rtc-jz4740: remove unnecessary platform_set_drvdata()

[Jingoo Han]

The driver core clears the driver data to NULL after device_release
or on probe failure, since commit 0998d0631001288a5974afc0b2a5f568bcdecb4d
(device-core: Ensure drvdata = NULL when no driver is bound).
Thus, it is not needed to manually clear the device driver data to NULL.

Signed-off-by: Jingoo Han 
---
 drivers/rtc/rtc-jz4740.c |3 ---
 1 files changed, 0 insertions(+), 3 deletions(-)

diff --git a/drivers/rtc/rtc-jz4740.c b/drivers/rtc/rtc-jz4740.c
index 1e48686..c6573585 100644
--- a/drivers/rtc/rtc-jz4740.c
+++ b/drivers/rtc/rtc-jz4740.c
@@ -287,7 +287,6 @@ err_free_irq:
 err_unregister_rtc:
rtc_device_unregister(rtc->rtc);
 err_iounmap:
-   platform_set_drvdata(pdev, NULL);
iounmap(rtc->base);
 err_release_mem_region:
release_mem_region(rtc->mem->start, resource_size(rtc->mem));
@@ -310,8 +309,6 @@ static int jz4740_rtc_remove(struct platform_device *pdev)
 
kfree(rtc);
 
-   platform_set_drvdata(pdev, NULL);
-
return 0;
 }
 
-- 
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 17/42] rtc: rtc-ep93xx: remove unnecessary platform_set_drvdata()

[Jingoo Han]

The driver core clears the driver data to NULL after device_release
or on probe failure, since commit 0998d0631001288a5974afc0b2a5f568bcdecb4d
(device-core: Ensure drvdata = NULL when no driver is bound).
Thus, it is not needed to manually clear the device driver data to NULL.

Signed-off-by: Jingoo Han 
---
 drivers/rtc/rtc-ep93xx.c |2 --
 1 files changed, 0 insertions(+), 2 deletions(-)

diff --git a/drivers/rtc/rtc-ep93xx.c b/drivers/rtc/rtc-ep93xx.c
index 5807b77..549b3c3 100644
--- a/drivers/rtc/rtc-ep93xx.c
+++ b/drivers/rtc/rtc-ep93xx.c
@@ -167,7 +167,6 @@ static int ep93xx_rtc_probe(struct platform_device *pdev)
return 0;
 
 exit:
-   platform_set_drvdata(pdev, NULL);
pdev->dev.platform_data = NULL;
return err;
 }
@@ -175,7 +174,6 @@ exit:
 static int ep93xx_rtc_remove(struct platform_device *pdev)
 {
sysfs_remove_group(&pdev->dev.kobj, &ep93xx_rtc_sysfs_files);
-   platform_set_drvdata(pdev, NULL);
pdev->dev.platform_data = NULL;
 
return 0;
-- 
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 15/42] rtc: rtc-dm355evm: remove unnecessary platform_set_drvdata()

[Jingoo Han]

The driver core clears the driver data to NULL after device_release
or on probe failure, since commit 0998d0631001288a5974afc0b2a5f568bcdecb4d
(device-core: Ensure drvdata = NULL when no driver is bound).
Thus, it is not needed to manually clear the device driver data to NULL.

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

diff --git a/drivers/rtc/rtc-dm355evm.c b/drivers/rtc/rtc-dm355evm.c
index 1e1ca63..1855581 100644
--- a/drivers/rtc/rtc-dm355evm.c
+++ b/drivers/rtc/rtc-dm355evm.c
@@ -141,7 +141,6 @@ static int dm355evm_rtc_probe(struct platform_device *pdev)
 
 static int dm355evm_rtc_remove(struct platform_device *pdev)
 {
-   platform_set_drvdata(pdev, NULL);
return 0;
 }
 
-- 
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 16/42] rtc: rtc-ds1302: remove unnecessary platform_set_drvdata()

[Jingoo Han]

The driver core clears the driver data to NULL after device_release
or on probe failure, since commit 0998d0631001288a5974afc0b2a5f568bcdecb4d
(device-core: Ensure drvdata = NULL when no driver is bound).
Thus, it is not needed to manually clear the device driver data to NULL.

Signed-off-by: Jingoo Han 
---
 drivers/rtc/rtc-ds1302.c |2 --
 1 files changed, 0 insertions(+), 2 deletions(-)

diff --git a/drivers/rtc/rtc-ds1302.c b/drivers/rtc/rtc-ds1302.c
index d139543..1f8ee63 100644
--- a/drivers/rtc/rtc-ds1302.c
+++ b/drivers/rtc/rtc-ds1302.c
@@ -236,8 +236,6 @@ static int __init ds1302_rtc_probe(struct platform_device 
*pdev)
 
 static int __exit ds1302_rtc_remove(struct platform_device *pdev)
 {
-   platform_set_drvdata(pdev, NULL);
-
return 0;
 }
 
-- 
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 14/42] rtc: rtc-davinci: remove unnecessary platform_set_drvdata()

[Jingoo Han]

The driver core clears the driver data to NULL after device_release
or on probe failure, since commit 0998d0631001288a5974afc0b2a5f568bcdecb4d
(device-core: Ensure drvdata = NULL when no driver is bound).
Thus, it is not needed to manually clear the device driver data to NULL.

Signed-off-by: Jingoo Han 
---
 drivers/rtc/rtc-davinci.c |   11 ++-
 1 files changed, 2 insertions(+), 9 deletions(-)

diff --git a/drivers/rtc/rtc-davinci.c b/drivers/rtc/rtc-davinci.c
index a55048c..ca62118 100644
--- a/drivers/rtc/rtc-davinci.c
+++ b/drivers/rtc/rtc-davinci.c
@@ -526,10 +526,9 @@ static int __init davinci_rtc_probe(struct platform_device 
*pdev)
davinci_rtc->rtc = devm_rtc_device_register(&pdev->dev, pdev->name,
&davinci_rtc_ops, THIS_MODULE);
if (IS_ERR(davinci_rtc->rtc)) {
-   ret = PTR_ERR(davinci_rtc->rtc);
dev_err(dev, "unable to register RTC device, err %d\n",
ret);
-   goto fail1;
+   return PTR_ERR(davinci_rtc->rtc);
}
 
rtcif_write(davinci_rtc, PRTCIF_INTFLG_RTCSS, PRTCIF_INTFLG);
@@ -543,7 +542,7 @@ static int __init davinci_rtc_probe(struct platform_device 
*pdev)
  0, "davinci_rtc", davinci_rtc);
if (ret < 0) {
dev_err(dev, "unable to register davinci RTC interrupt\n");
-   goto fail1;
+   return ret;
}
 
/* Enable interrupts */
@@ -556,10 +555,6 @@ static int __init davinci_rtc_probe(struct platform_device 
*pdev)
device_init_wakeup(&pdev->dev, 0);
 
return 0;
-
-fail1:
-   platform_set_drvdata(pdev, NULL);
-   return ret;
 }
 
 static int __exit davinci_rtc_remove(struct platform_device *pdev)
@@ -570,8 +565,6 @@ static int __exit davinci_rtc_remove(struct platform_device 
*pdev)
 
rtcif_write(davinci_rtc, 0, PRTCIF_INTEN);
 
-   platform_set_drvdata(pdev, NULL);
-
return 0;
 }
 
-- 
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/42] rtc: rtc-da9055: remove unnecessary platform_set_drvdata()

[Jingoo Han]

The driver core clears the driver data to NULL after device_release
or on probe failure, since commit 0998d0631001288a5974afc0b2a5f568bcdecb4d
(device-core: Ensure drvdata = NULL when no driver is bound).
Thus, it is not needed to manually clear the device driver data to NULL.

Signed-off-by: Jingoo Han 
---
 drivers/rtc/rtc-da9055.c |2 --
 1 files changed, 0 insertions(+), 2 deletions(-)

diff --git a/drivers/rtc/rtc-da9055.c b/drivers/rtc/rtc-da9055.c
index 73858ca..df4cf16 100644
--- a/drivers/rtc/rtc-da9055.c
+++ b/drivers/rtc/rtc-da9055.c
@@ -317,8 +317,6 @@ err_rtc:
 
 static int da9055_rtc_remove(struct platform_device *pdev)
 {
-   platform_set_drvdata(pdev, NULL);
-
return 0;
 }
 
-- 
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/42] rtc: rtc-da9052: remove unnecessary platform_set_drvdata()

[Jingoo Han]

The driver core clears the driver data to NULL after device_release
or on probe failure, since commit 0998d0631001288a5974afc0b2a5f568bcdecb4d
(device-core: Ensure drvdata = NULL when no driver is bound).
Thus, it is not needed to manually clear the device driver data to NULL.

Signed-off-by: Jingoo Han 
---
 drivers/rtc/rtc-da9052.c |2 --
 1 files changed, 0 insertions(+), 2 deletions(-)

diff --git a/drivers/rtc/rtc-da9052.c b/drivers/rtc/rtc-da9052.c
index 7286b27..a61ab7f 100644
--- a/drivers/rtc/rtc-da9052.c
+++ b/drivers/rtc/rtc-da9052.c
@@ -257,8 +257,6 @@ static int da9052_rtc_probe(struct platform_device *pdev)
 
 static int da9052_rtc_remove(struct platform_device *pdev)
 {
-   platform_set_drvdata(pdev, NULL);
-
return 0;
 }
 
-- 
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/42] rtc: rtc-coh901331: remove unnecessary platform_set_drvdata()

[Jingoo Han]

The driver core clears the driver data to NULL after device_release
or on probe failure, since commit 0998d0631001288a5974afc0b2a5f568bcdecb4d
(device-core: Ensure drvdata = NULL when no driver is bound).
Thus, it is not needed to manually clear the device driver data to NULL.

Signed-off-by: Jingoo Han 
---
 drivers/rtc/rtc-coh901331.c |5 +
 1 files changed, 1 insertions(+), 4 deletions(-)

diff --git a/drivers/rtc/rtc-coh901331.c b/drivers/rtc/rtc-coh901331.c
index 93c0658..9ad5891 100644
--- a/drivers/rtc/rtc-coh901331.c
+++ b/drivers/rtc/rtc-coh901331.c
@@ -154,10 +154,8 @@ static int __exit coh901331_remove(struct platform_device 
*pdev)
 {
struct coh901331_port *rtap = dev_get_drvdata(&pdev->dev);
 
-   if (rtap) {
+   if (rtap)
clk_unprepare(rtap->clk);
-   platform_set_drvdata(pdev, NULL);
-   }
 
return 0;
 }
@@ -220,7 +218,6 @@ static int __init coh901331_probe(struct platform_device 
*pdev)
return 0;
 
  out_no_rtc:
-   platform_set_drvdata(pdev, NULL);
clk_unprepare(rtap->clk);
return ret;
 }
-- 
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/42] rtc: rtc-bq4802: remove unnecessary platform_set_drvdata()

[Jingoo Han]

The driver core clears the driver data to NULL after device_release
or on probe failure, since commit 0998d0631001288a5974afc0b2a5f568bcdecb4d
(device-core: Ensure drvdata = NULL when no driver is bound).
Thus, it is not needed to manually clear the device driver data to NULL.

Signed-off-by: Jingoo Han 
---
 drivers/rtc/rtc-bq4802.c |2 --
 1 files changed, 0 insertions(+), 2 deletions(-)

diff --git a/drivers/rtc/rtc-bq4802.c b/drivers/rtc/rtc-bq4802.c
index af28867..b919168 100644
--- a/drivers/rtc/rtc-bq4802.c
+++ b/drivers/rtc/rtc-bq4802.c
@@ -188,8 +188,6 @@ out:
 
 static int bq4802_remove(struct platform_device *pdev)
 {
-   platform_set_drvdata(pdev, NULL);
-
return 0;
 }
 
-- 
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: [PATCH 1/1] powerpc: mpc512x_dma: add support for data transfers between memory and i/o memory

[Alexander Popov]

Hello Vinod,

Thanks for the review.
I will return with improved and tested version 2.

Best regards,
Alexander
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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/42] rtc: rtc-bfin: remove unnecessary platform_set_drvdata()

[Jingoo Han]

The driver core clears the driver data to NULL after device_release
or on probe failure, since commit 0998d0631001288a5974afc0b2a5f568bcdecb4d
(device-core: Ensure drvdata = NULL when no driver is bound).
Thus, it is not needed to manually clear the device driver data to NULL.

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

diff --git a/drivers/rtc/rtc-bfin.c b/drivers/rtc/rtc-bfin.c
index ad44ec5..0c53f45 100644
--- a/drivers/rtc/rtc-bfin.c
+++ b/drivers/rtc/rtc-bfin.c
@@ -391,7 +391,6 @@ static int bfin_rtc_remove(struct platform_device *pdev)
struct device *dev = &pdev->dev;
 
bfin_rtc_reset(dev, 0);
-   platform_set_drvdata(pdev, NULL);
 
return 0;
 }
-- 
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/42] rtc: rtc-au1xxx: remove unnecessary platform_set_drvdata()

[Jingoo Han]

The driver core clears the driver data to NULL after device_release
or on probe failure, since commit 0998d0631001288a5974afc0b2a5f568bcdecb4d
(device-core: Ensure drvdata = NULL when no driver is bound).
Thus, it is not needed to manually clear the device driver data to NULL.

Signed-off-by: Jingoo Han 
---
 drivers/rtc/rtc-au1xxx.c |2 --
 1 files changed, 0 insertions(+), 2 deletions(-)

diff --git a/drivers/rtc/rtc-au1xxx.c b/drivers/rtc/rtc-au1xxx.c
index 7995abc..7c6e7bb 100644
--- a/drivers/rtc/rtc-au1xxx.c
+++ b/drivers/rtc/rtc-au1xxx.c
@@ -118,8 +118,6 @@ out_err:
 
 static int au1xtoy_rtc_remove(struct platform_device *pdev)
 {
-   platform_set_drvdata(pdev, NULL);
-
return 0;
 }
 
-- 
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/42] rtc: rtc-at91sam9: remove unnecessary platform_set_drvdata()

[Jingoo Han]

The driver core clears the driver data to NULL after device_release
or on probe failure, since commit 0998d0631001288a5974afc0b2a5f568bcdecb4d
(device-core: Ensure drvdata = NULL when no driver is bound).
Thus, it is not needed to manually clear the device driver data to NULL.

Signed-off-by: Jingoo Han 
---
 drivers/rtc/rtc-at91sam9.c |   19 +--
 1 files changed, 5 insertions(+), 14 deletions(-)

diff --git a/drivers/rtc/rtc-at91sam9.c b/drivers/rtc/rtc-at91sam9.c
index b60a34c..309b8b3 100644
--- a/drivers/rtc/rtc-at91sam9.c
+++ b/drivers/rtc/rtc-at91sam9.c
@@ -324,16 +324,14 @@ static int at91_rtc_probe(struct platform_device *pdev)
rtc->rtt = devm_ioremap(&pdev->dev, r->start, resource_size(r));
if (!rtc->rtt) {
dev_err(&pdev->dev, "failed to map registers, aborting.\n");
-   ret = -ENOMEM;
-   goto fail;
+   return -ENOMEM;
}
 
rtc->gpbr = devm_ioremap(&pdev->dev, r_gpbr->start,
resource_size(r_gpbr));
if (!rtc->gpbr) {
dev_err(&pdev->dev, "failed to map gpbr registers, 
aborting.\n");
-   ret = -ENOMEM;
-   goto fail;
+   return -ENOMEM;
}
 
mr = rtt_readl(rtc, MR);
@@ -350,17 +348,15 @@ static int at91_rtc_probe(struct platform_device *pdev)
 
rtc->rtcdev = devm_rtc_device_register(&pdev->dev, pdev->name,
&at91_rtc_ops, THIS_MODULE);
-   if (IS_ERR(rtc->rtcdev)) {
-   ret = PTR_ERR(rtc->rtcdev);
-   goto fail;
-   }
+   if (IS_ERR(rtc->rtcdev))
+   return PTR_ERR(rtc->rtcdev);
 
/* register irq handler after we know what name we'll use */
ret = devm_request_irq(&pdev->dev, rtc->irq, at91_rtc_interrupt,
IRQF_SHARED, dev_name(&rtc->rtcdev->dev), rtc);
if (ret) {
dev_dbg(&pdev->dev, "can't share IRQ %d?\n", rtc->irq);
-   goto fail;
+   return ret;
}
 
/* NOTE:  sam9260 rev A silicon has a ROM bug which resets the
@@ -374,10 +370,6 @@ static int at91_rtc_probe(struct platform_device *pdev)
dev_name(&rtc->rtcdev->dev));
 
return 0;
-
-fail:
-   platform_set_drvdata(pdev, NULL);
-   return ret;
 }
 
 /*
@@ -391,7 +383,6 @@ static int at91_rtc_remove(struct platform_device *pdev)
/* disable all interrupts */
rtt_writel(rtc, MR, mr & ~(AT91_RTT_ALMIEN | AT91_RTT_RTTINCIEN));
 
-   platform_set_drvdata(pdev, NULL);
return 0;
 }
 
-- 
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/42] rtc: rtc-at91rm9200: remove unnecessary platform_set_drvdata()

[Jingoo Han]

The driver core clears the driver data to NULL after device_release
or on probe failure, since commit 0998d0631001288a5974afc0b2a5f568bcdecb4d
(device-core: Ensure drvdata = NULL when no driver is bound).
Thus, it is not needed to manually clear the device driver data to NULL.

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

diff --git a/drivers/rtc/rtc-at91rm9200.c b/drivers/rtc/rtc-at91rm9200.c
index 0eab77b..5a04b16 100644
--- a/drivers/rtc/rtc-at91rm9200.c
+++ b/drivers/rtc/rtc-at91rm9200.c
@@ -342,7 +342,6 @@ static int __exit at91_rtc_remove(struct platform_device 
*pdev)
 
rtc_device_unregister(rtc);
iounmap(at91_rtc_regs);
-   platform_set_drvdata(pdev, NULL);
 
return 0;
 }
-- 
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/42] rtc: rtc-at32ap700x: remove unnecessary platform_set_drvdata()

[Jingoo Han]

The driver core clears the driver data to NULL after device_release
or on probe failure, since commit 0998d0631001288a5974afc0b2a5f568bcdecb4d
(device-core: Ensure drvdata = NULL when no driver is bound).
Thus, it is not needed to manually clear the device driver data to NULL.

Signed-off-by: Jingoo Han 
---
 drivers/rtc/rtc-at32ap700x.c |   20 +---
 1 files changed, 5 insertions(+), 15 deletions(-)

diff --git a/drivers/rtc/rtc-at32ap700x.c b/drivers/rtc/rtc-at32ap700x.c
index f47fbb5..4a5ccf1 100644
--- a/drivers/rtc/rtc-at32ap700x.c
+++ b/drivers/rtc/rtc-at32ap700x.c
@@ -212,23 +212,20 @@ static int __init at32_rtc_probe(struct platform_device 
*pdev)
regs = platform_get_resource(pdev, IORESOURCE_MEM, 0);
if (!regs) {
dev_dbg(&pdev->dev, "no mmio resource defined\n");
-   ret = -ENXIO;
-   goto out;
+   return -ENXIO;
}
 
irq = platform_get_irq(pdev, 0);
if (irq <= 0) {
dev_dbg(&pdev->dev, "could not get irq\n");
-   ret = -ENXIO;
-   goto out;
+   return -ENXIO;
}
 
rtc->irq = irq;
rtc->regs = devm_ioremap(&pdev->dev, regs->start, resource_size(regs));
if (!rtc->regs) {
-   ret = -ENOMEM;
dev_dbg(&pdev->dev, "could not map I/O memory\n");
-   goto out;
+   return -ENOMEM;
}
spin_lock_init(&rtc->lock);
 
@@ -249,7 +246,7 @@ static int __init at32_rtc_probe(struct platform_device 
*pdev)
"rtc", rtc);
if (ret) {
dev_dbg(&pdev->dev, "could not request irq %d\n", irq);
-   goto out;
+   return ret;
}
 
platform_set_drvdata(pdev, rtc);
@@ -258,8 +255,7 @@ static int __init at32_rtc_probe(struct platform_device 
*pdev)
&at32_rtc_ops, THIS_MODULE);
if (IS_ERR(rtc->rtc)) {
dev_dbg(&pdev->dev, "could not register rtc device\n");
-   ret = PTR_ERR(rtc->rtc);
-   goto out;
+   return PTR_ERR(rtc->rtc);
}
 
device_init_wakeup(&pdev->dev, 1);
@@ -268,18 +264,12 @@ static int __init at32_rtc_probe(struct platform_device 
*pdev)
(unsigned long)rtc->regs, rtc->irq);
 
return 0;
-
-out:
-   platform_set_drvdata(pdev, NULL);
-   return ret;
 }
 
 static int __exit at32_rtc_remove(struct platform_device *pdev)
 {
device_init_wakeup(&pdev->dev, 0);
 
-   platform_set_drvdata(pdev, NULL);
-
return 0;
 }
 
-- 
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/42] rtc: rtc-ab8500: remove unnecessary platform_set_drvdata()

[Jingoo Han]

The driver core clears the driver data to NULL after device_release
or on probe failure, since commit 0998d0631001288a5974afc0b2a5f568bcdecb4d
(device-core: Ensure drvdata = NULL when no driver is bound).
Thus, it is not needed to manually clear the device driver data to NULL.

Signed-off-by: Jingoo Han 
---
 drivers/rtc/rtc-ab8500.c |2 --
 1 files changed, 0 insertions(+), 2 deletions(-)

diff --git a/drivers/rtc/rtc-ab8500.c b/drivers/rtc/rtc-ab8500.c
index 63cfa31..c5b62d4 100644
--- a/drivers/rtc/rtc-ab8500.c
+++ b/drivers/rtc/rtc-ab8500.c
@@ -451,8 +451,6 @@ static int ab8500_rtc_remove(struct platform_device *pdev)
 {
ab8500_sysfs_rtc_unregister(&pdev->dev);
 
-   platform_set_drvdata(pdev, NULL);
-
return 0;
 }
 
-- 
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/42] rtc: rtc-ab3100: remove unnecessary platform_set_drvdata()

[Jingoo Han]

The driver core clears the driver data to NULL after device_release
or on probe failure, since commit 0998d0631001288a5974afc0b2a5f568bcdecb4d
(device-core: Ensure drvdata = NULL when no driver is bound).
Thus, it is not needed to manually clear the device driver data to NULL.

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

diff --git a/drivers/rtc/rtc-ab3100.c b/drivers/rtc/rtc-ab3100.c
index 47a4f2c..572208d 100644
--- a/drivers/rtc/rtc-ab3100.c
+++ b/drivers/rtc/rtc-ab3100.c
@@ -242,7 +242,6 @@ static int __init ab3100_rtc_probe(struct platform_device 
*pdev)
 
 static int __exit ab3100_rtc_remove(struct platform_device *pdev)
 {
-   platform_set_drvdata(pdev, NULL);
return 0;
 }
 
-- 
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/42] rtc: rtc-88pm860x: remove unnecessary platform_set_drvdata()

[Jingoo Han]

The driver core clears the driver data to NULL after device_release
or on probe failure, since commit 0998d0631001288a5974afc0b2a5f568bcdecb4d
(device-core: Ensure drvdata = NULL when no driver is bound).
Thus, it is not needed to manually clear the device driver data to NULL.

Signed-off-by: Jingoo Han 
---
 drivers/rtc/rtc-88pm860x.c |1 -
 1 files changed, 0 insertions(+), 1 deletions(-)

diff --git a/drivers/rtc/rtc-88pm860x.c b/drivers/rtc/rtc-88pm860x.c
index 0f2b91b..4e30c85 100644
--- a/drivers/rtc/rtc-88pm860x.c
+++ b/drivers/rtc/rtc-88pm860x.c
@@ -418,7 +418,6 @@ static int pm860x_rtc_remove(struct platform_device *pdev)
pm860x_set_bits(info->i2c, PM8607_MEAS_EN2, MEAS2_VRTC, 0);
 #endif /* VRTC_CALIBRATION */
 
-   platform_set_drvdata(pdev, NULL);
return 0;
 }
 
-- 
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/42] rtc: rtc-88pm80x: remove unnecessary platform_set_drvdata()

[Jingoo Han]

The driver core clears the driver data to NULL after device_release
or on probe failure, since commit 0998d0631001288a5974afc0b2a5f568bcdecb4d
(device-core: Ensure drvdata = NULL when no driver is bound).
Thus, it is not needed to manually clear the device driver data to NULL.

Signed-off-by: Jingoo Han 
---
 drivers/rtc/rtc-88pm80x.c |1 -
 1 files changed, 0 insertions(+), 1 deletions(-)

diff --git a/drivers/rtc/rtc-88pm80x.c b/drivers/rtc/rtc-88pm80x.c
index f3742f3..354c937 100644
--- a/drivers/rtc/rtc-88pm80x.c
+++ b/drivers/rtc/rtc-88pm80x.c
@@ -345,7 +345,6 @@ out:
 static int pm80x_rtc_remove(struct platform_device *pdev)
 {
struct pm80x_rtc_info *info = platform_get_drvdata(pdev);
-   platform_set_drvdata(pdev, NULL);
pm80x_free_irq(info->chip, info->irq, info);
return 0;
 }
-- 
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 4/4] backlight: pcf50633: remove unnecessary platform_set_drvdata()

[Jingoo Han]

The driver core clears the driver data to NULL after device_release
or on probe failure, since commit 0998d0631001288a5974afc0b2a5f568bcdecb4d
(device-core: Ensure drvdata = NULL when no driver is bound).
Thus, it is not needed to manually clear the device driver data to NULL.

Signed-off-by: Jingoo Han 
---
 drivers/video/backlight/pcf50633-backlight.c |2 --
 1 files changed, 0 insertions(+), 2 deletions(-)

diff --git a/drivers/video/backlight/pcf50633-backlight.c 
b/drivers/video/backlight/pcf50633-backlight.c
index e87c7a3..6ed76be 100644
--- a/drivers/video/backlight/pcf50633-backlight.c
+++ b/drivers/video/backlight/pcf50633-backlight.c
@@ -153,8 +153,6 @@ static int pcf50633_bl_remove(struct platform_device *pdev)
 
backlight_device_unregister(pcf_bl->bl);
 
-   platform_set_drvdata(pdev, NULL);
-
return 0;
 }
 
-- 
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 3/4] backlight: lp8788: remove unnecessary platform_set_drvdata()

[Jingoo Han]

The driver core clears the driver data to NULL after device_release
or on probe failure, since commit 0998d0631001288a5974afc0b2a5f568bcdecb4d
(device-core: Ensure drvdata = NULL when no driver is bound).
Thus, it is not needed to manually clear the device driver data to NULL.

Signed-off-by: Jingoo Han 
---
 drivers/video/backlight/lp8788_bl.c |1 -
 1 files changed, 0 insertions(+), 1 deletions(-)

diff --git a/drivers/video/backlight/lp8788_bl.c 
b/drivers/video/backlight/lp8788_bl.c
index 4bb8b4f..980855e 100644
--- a/drivers/video/backlight/lp8788_bl.c
+++ b/drivers/video/backlight/lp8788_bl.c
@@ -312,7 +312,6 @@ static int lp8788_backlight_remove(struct platform_device 
*pdev)
backlight_update_status(bl_dev);
sysfs_remove_group(&pdev->dev.kobj, &lp8788_attr_group);
lp8788_backlight_unregister(bl);
-   platform_set_drvdata(pdev, NULL);
 
return 0;
 }
-- 
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 2/4] backlight: ep93xx: remove unnecessary platform_set_drvdata()

[Jingoo Han]

The driver core clears the driver data to NULL after device_release
or on probe failure, since commit 0998d0631001288a5974afc0b2a5f568bcdecb4d
(device-core: Ensure drvdata = NULL when no driver is bound).
Thus, it is not needed to manually clear the device driver data to NULL.

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

diff --git a/drivers/video/backlight/ep93xx_bl.c 
b/drivers/video/backlight/ep93xx_bl.c
index 3345582..018368b 100644
--- a/drivers/video/backlight/ep93xx_bl.c
+++ b/drivers/video/backlight/ep93xx_bl.c
@@ -111,7 +111,6 @@ static int ep93xxbl_remove(struct platform_device *dev)
struct backlight_device *bl = platform_get_drvdata(dev);
 
backlight_device_unregister(bl);
-   platform_set_drvdata(dev, NULL);
return 0;
 }
 
-- 
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 1/4] backlight: atmel-pwm-bl: remove unnecessary platform_set_drvdata()

[Jingoo Han]

The driver core clears the driver data to NULL after device_release
or on probe failure, since commit 0998d0631001288a5974afc0b2a5f568bcdecb4d
(device-core: Ensure drvdata = NULL when no driver is bound).
Thus, it is not needed to manually clear the device driver data to NULL.

Signed-off-by: Jingoo Han 
---
 drivers/video/backlight/atmel-pwm-bl.c |2 --
 1 files changed, 0 insertions(+), 2 deletions(-)

diff --git a/drivers/video/backlight/atmel-pwm-bl.c 
b/drivers/video/backlight/atmel-pwm-bl.c
index a60d6af..0393d82 100644
--- a/drivers/video/backlight/atmel-pwm-bl.c
+++ b/drivers/video/backlight/atmel-pwm-bl.c
@@ -195,7 +195,6 @@ static int __init atmel_pwm_bl_probe(struct platform_device 
*pdev)
return 0;
 
 err_free_bl_dev:
-   platform_set_drvdata(pdev, NULL);
backlight_device_unregister(bldev);
 err_free_pwm:
pwm_channel_free(&pwmbl->pwmc);
@@ -212,7 +211,6 @@ static int __exit atmel_pwm_bl_remove(struct 
platform_device *pdev)
pwm_channel_disable(&pwmbl->pwmc);
pwm_channel_free(&pwmbl->pwmc);
backlight_device_unregister(pwmbl->bldev);
-   platform_set_drvdata(pdev, NULL);
 
return 0;
 }
-- 
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: [PATCH] sched: wake-affine throttle

[Mike Galbraith]

On Fri, 2013-05-03 at 13:57 +0800, Michael Wang wrote: 
> Hi, Mike
> 
> Thanks for your reply.
> 
> On 05/03/2013 01:01 PM, Mike Galbraith wrote:
> [snip]
> >>
> >> If this approach caused any concerns, please let me know ;-)
> > 
> > I wonder if throttling on failure is the way to go.  Note the minimal
> > gain for pgbench with the default 1ms throttle interval.  It's not very
> > effective out of the box for the load type it's targeted to help, and
> > people generally don't twiddle scheduler knobs.  If you throttle on
> > success, you directly restrict migration frequency without that being
> > affected by what other tasks are doing.  Seems that would be a bit more
> > effective.
> 
> This is a good timing to make some conclusion for this problem ;-)
> 
> Let's suppose when wake-affine failed, next time slice got a higher
> failure chance, then whether throttle on failure could be the question like:
> 
>   throttle interval should cover more failure timing
>   or more success timing?
> 
> Obviously we should cover more failure timing, since it's just wasting
> cycle and change nothing.
> 
> However, I used to concern about the damage of succeed wake-affine at
> that rapid, sure it also contain the benefit, but which one is bigger?
> 
> Now if we look at the RFC version which throttle on succeed, for
> pgbench, we could find that the default 1ms benefit is < 5%, while the
> current version which throttle on failure bring 7% at most.

OK, so scratch that thought.  Would still be good to find a dirt simple
dirt cheap way to increase effectiveness a bit, and eliminate the knob.
Until a better idea comes along, this helps pgbench some, and will also
help fast movers ala tbench on AMD, where select_idle_sibling() wasn't
particularly wonderful per my measurements.

-Mike

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

Re: [PATCH V2] cpufreq: cpu0: Free parent node for error cases

[Shawn Guo]

On Fri, May 03, 2013 at 10:14:25AM +0530, Viresh Kumar wrote:
> We are freeing parent node in success cases but not in failure cases. Lets do
> it.
> 
> Signed-off-by: Viresh Kumar 

Acked-by: Shawn Guo 

> ---
>  drivers/cpufreq/cpufreq-cpu0.c | 5 -
>  1 file changed, 4 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/cpufreq/cpufreq-cpu0.c b/drivers/cpufreq/cpufreq-cpu0.c
> index 3ab8294..8565d41 100644
> --- a/drivers/cpufreq/cpufreq-cpu0.c
> +++ b/drivers/cpufreq/cpufreq-cpu0.c
> @@ -189,7 +189,8 @@ static int cpu0_cpufreq_probe(struct platform_device 
> *pdev)
>  
>   if (!np) {
>   pr_err("failed to find cpu0 node\n");
> - return -ENOENT;
> + ret = -ENOENT;
> + goto out_put_parent;
>   }
>  
>   cpu_dev = &pdev->dev;
> @@ -264,6 +265,8 @@ out_free_table:
>   opp_free_cpufreq_table(cpu_dev, &freq_table);
>  out_put_node:
>   of_node_put(np);
> +out_put_parent:
> + of_node_put(parent);
>   return ret;
>  }
>  
> -- 
> 1.7.12.rc2.18.g61b472e
> 

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

Re: [PATCH v4 4/6] KVM: MMU: fast invalid all shadow pages

[Xiao Guangrong]

On 05/03/2013 10:27 AM, Takuya Yoshikawa wrote:
> On Sat, 27 Apr 2013 11:13:20 +0800
> Xiao Guangrong  wrote:
> 
>> +/*
>> + * Fast invalid all shadow pages belong to @slot.
>> + *
>> + * @slot != NULL means the invalidation is caused the memslot specified
>> + * by @slot is being deleted, in this case, we should ensure that rmap
>> + * and lpage-info of the @slot can not be used after calling the function.
>> + *
>> + * @slot == NULL means the invalidation due to other reasons, we need
> 
> The comment should explain what the "other reasons" are.
> But this API may better be split into two separate functions; it depends
> on the "other reasons".

NO.

> 
>> + * not care rmap and lpage-info since they are still valid after calling
>> + * the function.
>> + */
>> +void kvm_mmu_invalid_memslot_pages(struct kvm *kvm,
>> +   struct kvm_memory_slot *slot)
> 
> You yourself is explaining this as "invalidation" in the comment.
> kvm_mmu_invalidate_shadow_pages_memslot() or something...

Umm, invalidate is a better name. Will update after collecting Marcelo, Gleb
and other guy's comments.

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

Re: [PATCH v4 3/6] KVM: MMU: introduce kvm_clear_all_lpage_info

[Xiao Guangrong]

On 05/03/2013 10:15 AM, Takuya Yoshikawa wrote:
> On Sat, 27 Apr 2013 11:13:19 +0800
> Xiao Guangrong  wrote:
> 
>> This function is used to reset the large page info of all guest pages
>> which will be used in later patch
>>
>> Signed-off-by: Xiao Guangrong 
>> ---
>>  arch/x86/kvm/x86.c |   25 +
>>  arch/x86/kvm/x86.h |2 ++
>>  2 files changed, 27 insertions(+), 0 deletions(-)
>>
>> diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c
>> index 52b4e97..8e4494c 100644
>> --- a/arch/x86/kvm/x86.c
>> +++ b/arch/x86/kvm/x86.c
>> @@ -6951,6 +6951,31 @@ static void memslot_set_lpage_disallowed(struct 
>> kvm_memory_slot *slot,
>>  }
>>  }
>>  
>> +static void clear_memslot_lpage_info(struct kvm_memory_slot *slot)
>> +{
>> +int i;
>> +
>> +for (i = 1; i < KVM_NR_PAGE_SIZES; ++i) {
>> +int lpages;
>> +int level = i + 1;
>> +
>> +lpages = gfn_to_index(slot->base_gfn + slot->npages - 1,
>> +  slot->base_gfn, level) + 1;
>> +
>> +memset(slot->arch.lpage_info[i - 1], 0,
>> +   sizeof(*slot->arch.lpage_info[i - 1]));
>> +memslot_set_lpage_disallowed(slot, slot->npages, i, lpages);
> 
> This does something other than clearing.

Aha, this API *clears* the count set by kvm mmu. It is meaningful enough,
i think.



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

[Michael Wang]

Hi, Mike

Thanks for your reply.

On 05/03/2013 01:01 PM, Mike Galbraith wrote:
[snip]
>>
>> If this approach caused any concerns, please let me know ;-)
> 
> I wonder if throttling on failure is the way to go.  Note the minimal
> gain for pgbench with the default 1ms throttle interval.  It's not very
> effective out of the box for the load type it's targeted to help, and
> people generally don't twiddle scheduler knobs.  If you throttle on
> success, you directly restrict migration frequency without that being
> affected by what other tasks are doing.  Seems that would be a bit more
> effective.

This is a good timing to make some conclusion for this problem ;-)

Let's suppose when wake-affine failed, next time slice got a higher
failure chance, then whether throttle on failure could be the question like:

throttle interval should cover more failure timing
or more success timing?

Obviously we should cover more failure timing, since it's just wasting
cycle and change nothing.

However, I used to concern about the damage of succeed wake-affine at
that rapid, sure it also contain the benefit, but which one is bigger?

Now if we look at the RFC version which throttle on succeed, for
pgbench, we could find that the default 1ms benefit is < 5%, while the
current version which throttle on failure bring 7% at most.

And that eliminate my concern :)

> 
> (I still like the wakeup buddy thing, it's more effective because it
> adds and uses knowledge, though without the knob, cache domain size.
> Peter is right about the interrupt wakeups though, that could very
> easily cause regressions, dirt simple throttle is much safer).

Exactly, dark issue deserve dark solution, let darkness guide him...

Regards,
Michael Wang

> 
> -Mike
> 

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

Re: [PATCH v4 2/6] KVM: x86: introduce memslot_set_lpage_disallowed

[Xiao Guangrong]

On 05/03/2013 10:10 AM, Takuya Yoshikawa wrote:
> On Sat, 27 Apr 2013 11:13:18 +0800
> Xiao Guangrong  wrote:
> 
>> It is used to set disallowed large page on the specified level, can be
>> used in later patch
>>
>> Signed-off-by: Xiao Guangrong 
>> ---
>>  arch/x86/kvm/x86.c |   53 
>> ++-
>>  1 files changed, 35 insertions(+), 18 deletions(-)
>>
>> diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c
>> index 91dd9f4..52b4e97 100644
>> --- a/arch/x86/kvm/x86.c
>> +++ b/arch/x86/kvm/x86.c
>> @@ -6917,12 +6917,45 @@ void kvm_arch_free_memslot(struct kvm_memory_slot 
>> *free,
>>  }
>>  }
>>  
>> +static void memslot_set_lpage_disallowed(struct kvm_memory_slot *slot,
>> + unsigned long npages,
>> + int lpage_size, int lpages)
> 
> What this function does is to disable large page support for this slot
> as can be seen in the comment below.
> 
> Since setting lpage_info to something ("disallowed" ?) is an implementation
> detail, we'd better hide such a thing from the function name.
> 
> Taking into account that we have "kvm_largepages_enabled()", something like
> disable_largepages_memslot() may be a candidate.
> 

No.

kvm_largepages_enabled effects on largepages_enabled, it is not related
with this function. Actually, I really do not care the different between
"disallowed" and "disabled".


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

[PATCH v2 2/2] clk: si5351: Set initial clkout rate when defined in platform data.

[Marek Belisko]

Signed-off-by: Marek Belisko 
---
Changes v1->v2:
- update commit message and comment to refer to platform data not DT

 drivers/clk/clk-si5351.c |   10 ++
 1 file changed, 10 insertions(+)

diff --git a/drivers/clk/clk-si5351.c b/drivers/clk/clk-si5351.c
index cf39e53..24f5536 100644
--- a/drivers/clk/clk-si5351.c
+++ b/drivers/clk/clk-si5351.c
@@ -1477,6 +1477,16 @@ static int si5351_i2c_probe(struct i2c_client *client,
return -EINVAL;
}
drvdata->onecell.clks[n] = clk;
+
+   /* set initial clkout rate */
+   if (pdata->clkout[n].rate != 0) {
+   int ret;
+   ret = clk_set_rate(clk, pdata->clkout[n].rate);
+   if (ret != 0) {
+   dev_err(&client->dev, "Cannot set rate : %d\n",
+   ret);
+   }
+   }
}
 
ret = of_clk_add_provider(client->dev.of_node, of_clk_src_onecell_get,
-- 
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 v2 1/2] clk: si5351: Fix clkout rate computation.

[Marek Belisko]

Rate was incorrectly computed because we read from wrong divider register.

Signed-off-by: Marek Belisko 
Acked-by: Sebastian Hesselbarth 
---
 drivers/clk/clk-si5351.c |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/clk/clk-si5351.c b/drivers/clk/clk-si5351.c
index 8927284..cf39e53 100644
--- a/drivers/clk/clk-si5351.c
+++ b/drivers/clk/clk-si5351.c
@@ -932,7 +932,7 @@ static unsigned long si5351_clkout_recalc_rate(struct 
clk_hw *hw,
unsigned char reg;
unsigned char rdiv;
 
-   if (hwdata->num > 5)
+   if (hwdata->num <= 5)
reg = si5351_msynth_params_address(hwdata->num) + 2;
else
reg = SI5351_CLK6_7_OUTPUT_DIVIDER;
-- 
1.7.9.5

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

Re: [PATCH v4 4/6] KVM: MMU: fast invalid all shadow pages

[Xiao Guangrong]

On 05/03/2013 09:05 AM, Marcelo Tosatti wrote:

>> +
>> +/*
>> + * Fast invalid all shadow pages belong to @slot.
>> + *
>> + * @slot != NULL means the invalidation is caused the memslot specified
>> + * by @slot is being deleted, in this case, we should ensure that rmap
>> + * and lpage-info of the @slot can not be used after calling the function.
>> + *
>> + * @slot == NULL means the invalidation due to other reasons, we need
>> + * not care rmap and lpage-info since they are still valid after calling
>> + * the function.
>> + */
>> +void kvm_mmu_invalid_memslot_pages(struct kvm *kvm,
>> +   struct kvm_memory_slot *slot)
>> +{
>> +spin_lock(&kvm->mmu_lock);
>> +kvm->arch.mmu_valid_gen++;
>> +
>> +/*
>> + * All shadow paes are invalid, reset the large page info,
>> + * then we can safely desotry the memslot, it is also good
>> + * for large page used.
>> + */
>> +kvm_clear_all_lpage_info(kvm);
> 
> Xiao,
> 
> I understood it was agreed that simple mmu_lock lockbreak while
> avoiding zapping of newly instantiated pages upon a
> 
>   if(spin_needbreak)
>   cond_resched_lock()
> 
> cycle was enough as a first step? And then later introduce root zapping
> along with measurements.
> 
> https://lkml.org/lkml/2013/4/22/544

Yes, it is.

See the changelog in 0/0:

" we use lock-break technique to zap all sptes linked on the
invalid rmap, it is not very effective but good for the first step."

Thanks!


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

[PATCH] ASoC: McASP: Fix receive clock polarity in DAIFMT_NB_NF mode.

[Marek Belisko]

According documentation bit ACLKRPOL is set to 0 (receiver samples data
on falling edge) and when set to 1 (receiver samples data on rising edge).

I2S data are always sampled on falling edge and valid during rising edge
of bit clock. So in case of capture data transmitter sample data on falling
edge and macsp must read then on rising edge.

Signed-off-by: Marek Belisko 
---
 sound/soc/davinci/davinci-mcasp.c |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/sound/soc/davinci/davinci-mcasp.c 
b/sound/soc/davinci/davinci-mcasp.c
index 849a187..c46112e 100644
--- a/sound/soc/davinci/davinci-mcasp.c
+++ b/sound/soc/davinci/davinci-mcasp.c
@@ -568,7 +568,7 @@ static int davinci_mcasp_set_dai_fmt(struct snd_soc_dai 
*cpu_dai,
mcasp_set_bits(base + DAVINCI_MCASP_ACLKXCTL_REG, ACLKXPOL);
mcasp_clr_bits(base + DAVINCI_MCASP_TXFMCTL_REG, FSXPOL);
 
-   mcasp_clr_bits(base + DAVINCI_MCASP_ACLKRCTL_REG, ACLKRPOL);
+   mcasp_set_bits(base + DAVINCI_MCASP_ACLKRCTL_REG, ACLKRPOL);
mcasp_clr_bits(base + DAVINCI_MCASP_RXFMCTL_REG, FSRPOL);
break;
 
-- 
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 v2] clk: si5351: Allow user to define disabled state for every clock output

[Marek Belisko]

From: Sebastian Hesselbarth 

This patch adds platform data and DT bindings to allow to overwrite
the stored disabled state for each clock output.

Signed-off-by: Marek Belisko 
Signed-off-by: Sebastian Hesselbarth 
---
Changes from v1->v2:
Sebastian Hesselbarth send me updated version of patch which was based
on v1. Resending with updates.

 .../devicetree/bindings/clock/silabs,si5351.txt|5 ++
 drivers/clk/clk-si5351.c   |   74 +++-
 drivers/clk/clk-si5351.h   |1 +
 include/linux/platform_data/si5351.h   |   18 +
 4 files changed, 95 insertions(+), 3 deletions(-)

diff --git a/Documentation/devicetree/bindings/clock/silabs,si5351.txt 
b/Documentation/devicetree/bindings/clock/silabs,si5351.txt
index cc37465..66c75b2 100644
--- a/Documentation/devicetree/bindings/clock/silabs,si5351.txt
+++ b/Documentation/devicetree/bindings/clock/silabs,si5351.txt
@@ -44,6 +44,11 @@ Optional child node properties:
 - silabs,multisynth-source: source pll A(0) or B(1) of corresponding multisynth
   divider.
 - silabs,pll-master: boolean, multisynth can change pll frequency.
+- silabs,disable-state : clock output disable state, shall be
+  0 = clock output is driven LOW when disabled
+  1 = clock output is driven HIGH when disabled
+  2 = clock output is FLOATING (HIGH-Z) when disabled
+  3 = clock output is NEVER disabled
 
 ==Example==
 
diff --git a/drivers/clk/clk-si5351.c b/drivers/clk/clk-si5351.c
index 8323c31..098f28b 100644
--- a/drivers/clk/clk-si5351.c
+++ b/drivers/clk/clk-si5351.c
@@ -851,6 +851,41 @@ static int _si5351_clkout_set_drive_strength(
return 0;
 }
 
+static int _si5351_clkout_set_disable_state(
+   struct si5351_driver_data *drvdata, int num,
+   enum si5351_disable_state state)
+{
+   u8 reg = (num < 4) ? SI5351_CLK3_0_DISABLE_STATE :
+   SI5351_CLK7_4_DISABLE_STATE;
+   u8 shift = (num < 4) ? (2 * num) : (2 * (num-4));
+   u8 mask = SI5351_CLK_DISABLE_STATE_MASK << shift;
+   u8 val;
+
+   if (num > 8)
+   return -EINVAL;
+
+   switch (state) {
+   case SI5351_DISABLE_LOW:
+   val = SI5351_CLK_DISABLE_STATE_LOW;
+   break;
+   case SI5351_DISABLE_HIGH:
+   val = SI5351_CLK_DISABLE_STATE_HIGH;
+   break;
+   case SI5351_DISABLE_FLOATING:
+   val = SI5351_CLK_DISABLE_STATE_FLOAT;
+   break;
+   case SI5351_DISABLE_NEVER:
+   val = SI5351_CLK_DISABLE_STATE_NEVER;
+   break;
+   default:
+   return 0;
+   }
+
+   si5351_set_bits(drvdata, reg, mask, val << shift);
+
+   return 0;
+}
+
 static int si5351_clkout_prepare(struct clk_hw *hw)
 {
struct si5351_hw_data *hwdata =
@@ -1225,6 +1260,33 @@ static int si5351_dt_parse(struct i2c_client *client)
}
}
 
+   if (!of_property_read_u32(child, "silabs,disable-state",
+ &val)) {
+   switch (val) {
+   case 0:
+   pdata->clkout[num].disable_state =
+   SI5351_DISABLE_LOW;
+   break;
+   case 1:
+   pdata->clkout[num].disable_state =
+   SI5351_DISABLE_HIGH;
+   break;
+   case 2:
+   pdata->clkout[num].disable_state =
+   SI5351_DISABLE_FLOATING;
+   break;
+   case 3:
+   pdata->clkout[num].disable_state =
+   SI5351_DISABLE_NEVER;
+   break;
+   default:
+   dev_err(&client->dev,
+   "invalid disable state %d for clkout 
%d\n",
+   val, num);
+   return -EINVAL;
+   }
+   }
+
if (!of_property_read_u32(child, "clock-frequency", &val))
pdata->clkout[num].rate = val;
 
@@ -1281,9 +1343,6 @@ static int si5351_i2c_probe(struct i2c_client *client,
 
/* Disable interrupts */
si5351_reg_write(drvdata, SI5351_INTERRUPT_MASK, 0xf0);
-   /* Set disabled output drivers to drive low */
-   si5351_reg_write(drvdata, SI5351_CLK3_0_DISABLE_STATE, 0x00);
-   si5351_reg_write(drvdata, SI5351_CLK7_4_DISABLE_STATE, 0x00);
/* Ensure pll select is on XTAL for Si5351A/B */
if (drvdata->variant != SI5351_VARIANT_C)
si5351_set_bits(drvdata, SI5351_PLL_INPUT_SOURCE,
@@ -1327,6 +1386,15 @@ static int si5351_i2c_probe(struct i2c_client *client,
  

Re: [PATCH -next] power: fix lp8788-charger kconfig & build

[Anton Vorontsov]

On Wed, May 01, 2013 at 11:04:38PM +, Kim, Milo wrote:
> > Subject: [PATCH -next] power: fix lp8788-charger kconfig & build
> > 
> > From: Randy Dunlap 
> > 
> Acked-by: Milo Kim 

Applied, thanks a lot!

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

Re: [PATCH v2 2/5] ARM: dove: add DT parsing for legacy mv643xx_eth

[Andrew Lunn]

On Fri, May 03, 2013 at 01:48:36AM +0200, Sebastian Hesselbarth wrote:
> To allow to move to orion irqchip driver, existing legacy devices
> have to map their irqs. This patch adds init code to map the
> corresponding irqs. It will vanish as soon as there is true device tree
> support for mv643xx_eth.
> 
> Signed-off-by: Sebastian Hesselbarth 
> ---
> Changelog:
> v1->v2:
> - split off DT changes (Suggested by Jason Cooper)
> 
> Cc: Grant Likely 
> Cc: Rob Herring 
> Cc: Rob Landley 
> Cc: Thomas Gleixner 
> Cc: Russell King 
> Cc: Arnd Bergmann 
> Cc: Jason Cooper 
> Cc: Andrew Lunn 
> Cc: Jason Gunthorpe 
> Cc: Thomas Petazzoni 
> Cc: Gregory Clement 
> Cc: Ezequiel Garcia 
> Cc: Jean-Francois Moine 
> Cc: devicetree-disc...@lists.ozlabs.org
> Cc: linux-...@vger.kernel.org
> Cc: linux-arm-ker...@lists.infradead.org
> Cc: linux-kernel@vger.kernel.org
> ---
>  arch/arm/mach-dove/board-dt.c |   31 ++-
>  1 file changed, 30 insertions(+), 1 deletion(-)
> 
> diff --git a/arch/arm/mach-dove/board-dt.c b/arch/arm/mach-dove/board-dt.c
> index fbde1dd..9df6dd7 100644
> --- a/arch/arm/mach-dove/board-dt.c
> +++ b/arch/arm/mach-dove/board-dt.c
> @@ -12,6 +12,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  #include 
>  #include 
>  #include 
> @@ -57,6 +58,34 @@ static struct mv643xx_eth_platform_data dove_dt_ge00_data 
> = {
>   .phy_addr = MV643XX_ETH_PHY_ADDR_DEFAULT,
>  };
>  
> +#define DOVE_GE00_PHYS_BASE  0xf107
> +
> +static void __init dove_legacy_ge00_init(void)
> +{
> + struct device_node *np = of_find_compatible_node(NULL, NULL,
> +  "marvell,mv643xx-eth-block");
> + int irq_sum, irq_err;
> +
> + if (!np)
> + return;
> +
> + irq_sum = irq_of_parse_and_map(np, 0);
> + if (!irq_sum) {
> + pr_err("%s: missing sum irq\n", np->full_name);
> + return;
> + }
> +
> + irq_err = irq_of_parse_and_map(np, 1);
> + if (!irq_err) {
> + pr_err("%s: missing err irq\n", np->full_name);
> + return;
> + }
> +
> + /* legacy ge00_init wants phys base */
> + orion_ge00_init(&dove_dt_ge00_data, DOVE_GE00_PHYS_BASE,
> + irq_sum, irq_err, 1600);
> +}

Hi Sebastian

I know the above code is throw away, but it might help with getting
Kirkwood, Orion5x, mv78xx00 supported if we refactor this code and
move most of it into plat-orion/common.c. I could imaging a function

orion_ge00_irq_init(struct mv643xx_eth_platform_data *eth_data,
unsigned long mapbase, unsigned int tx_csum_limit)

which does the irq lookup and then calls orion_ge00_init().


Jason: what is the status of the ethernet driver conversion to DT?
Will it get merged this week, or is it material for the next merge
window?

  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/

Re: [PATCH] sched: wake-affine throttle

[Mike Galbraith]

On Fri, 2013-05-03 at 11:46 +0800, Michael Wang wrote: 
> On 04/10/2013 11:30 AM, Michael Wang wrote:
> 
> Now long time has been passed since the first version, I'd like to 
> do some summary about current states:
> 
> On a 12 cpu box with tip 3.9.0-rc7, test show that:
> 
> 1. remove wake-affine stuff cause regression on hackbench (could be 15%).
> 2. reserve wake-affine stuff cause regression on pgbench (could be 45%).
> 
> And since neither remove or reserve is acceptable, this patch introduced a
> knob to throttle wake-affine stuff.
> 
> By turning the knob, we could benefit both hackbench and pgbench, or sacrifice
> one to significantly benefit another.
> 
> All similar workload which prefer or hate wake-affine behaviour could
> been cared.
> 
> If this approach caused any concerns, please let me know ;-)

I wonder if throttling on failure is the way to go.  Note the minimal
gain for pgbench with the default 1ms throttle interval.  It's not very
effective out of the box for the load type it's targeted to help, and
people generally don't twiddle scheduler knobs.  If you throttle on
success, you directly restrict migration frequency without that being
affected by what other tasks are doing.  Seems that would be a bit more
effective.

(I still like the wakeup buddy thing, it's more effective because it
adds and uses knowledge, though without the knob, cache domain size.
Peter is right about the interrupt wakeups though, that could very
easily cause regressions, dirt simple throttle is much safer).

-Mike

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

[GIT PULL] linux-pstore.git

[Anton Vorontsov]

Hello Linus,

Please pull a few updates for the pstore subsystem. Here is what is in:

- A new platform data parameter to specify ECC configuration;
- Rounding fixup to not waste memory in ecc_blocks;
- Restore ECC information printouts;
- A small code cleanup: use kmemdup where appropriate.

Thank you!

The following changes since commit a937536b868b8369b98967929045f1df54234323:

  Linux 3.9-rc3 (2013-03-17 15:59:32 -0700)

are available in the git repository at:

  git://git.infradead.org/users/cbou/linux-pstore.git tags/for-v3.10

for you to fetch changes up to bd08ec33b5c23833581e5a36b2a69ccae6b39a28:

  pstore/ram: Restore ecc information block (2013-04-03 21:50:10 -0700)


Alexandru Gheorghiu (1):
  pstore: Replace calls to kmalloc and memcpy with kmemdup

Arve Hjønnevåg (3):
  pstore/ram: Include ecc_size when calculating ecc_block
  pstore/ram: Allow specifying ecc parameters in platform data
  pstore/ram: Restore ecc information block

 fs/pstore/ram.c| 26 +++---
 fs/pstore/ram_core.c   | 66 ++
 include/linux/pstore_ram.h | 14 +++---
 3 files changed, 64 insertions(+), 42 deletions(-)
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH, RFC 02/22] cpufreq: ARM_DT_BL_CPUFREQ needs ARM_CPU_TOPOLOGY

[Viresh Kumar]

On 2 May 2013 20:46, Arnd Bergmann  wrote:
> The big.LITTLE cpufreq driver uses the CPU topology API, which
> needs to be reflected in Kconfig to prevent broken configurations.
>
> warning: (ARM_DT_BL_CPUFREQ) selects ARM_BIG_LITTLE_CPUFREQ which
> has unmet direct dependencies (ARCH_HAS_CPUFREQ && CPU_FREQ && ARM && 
> ARM_CPU_TOPOLOGY)
>
> Cc: Rafael J. Wysocki 
> Cc: Viresh Kumar 
> Cc: cpuf...@vger.kernel.org
> Cc: linux...@vger.kernel.org
> Signed-off-by: Arnd Bergmann 
> ---
>  drivers/cpufreq/Kconfig.arm | 1 +
>  1 file changed, 1 insertion(+)
>
> diff --git a/drivers/cpufreq/Kconfig.arm b/drivers/cpufreq/Kconfig.arm
> index f3af18b..3fd6bdf 100644
> --- a/drivers/cpufreq/Kconfig.arm
> +++ b/drivers/cpufreq/Kconfig.arm
> @@ -10,6 +10,7 @@ config ARM_DT_BL_CPUFREQ
> tristate "Generic ARM big LITTLE CPUfreq driver probed via DT"
> select ARM_BIG_LITTLE_CPUFREQ
> depends on OF && HAVE_CLK
> +   depends on ARM_CPU_TOPOLOGY
> help
>   This enables the Generic CPUfreq driver for ARM big.LITTLE platform.
>   This gets frequency tables from DT.

This Kconfig thing has always been confusing to me. This is how the code looks
currently.

config ARM_BIG_LITTLE_CPUFREQ
tristate
depends on ARM_CPU_TOPOLOGY

config ARM_DT_BL_CPUFREQ
tristate "Generic ARM big LITTLE CPUfreq driver probed via DT"
select ARM_BIG_LITTLE_CPUFREQ
depends on OF && HAVE_CLK
help
  This enables the Generic CPUfreq driver for ARM big.LITTLE platform.
  This gets frequency tables from DT.

Because all ARM big LITTLE cpufreq stuff have dependency on
ARM_CPU_TOPOLOGY, i have added dependency at a common place. So that
we don't end up adding this in every glue layer driver. How should this be done?
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH 2/7] posix-cpu-timers: fix acounting delta_exec twice

[kosaki . motohiro]

From: KOSAKI Motohiro 

Currently glibc rt/tst-cpuclock2 test(*) sporadically fails because
scheduler delta can be accounted twice from thread_group_cputimer()
and account_group_exec_runtime().

Finally, clock_nanosleep() wakes up before an argument. This is posix
violation. This issue was introduced by commit d670ec1317 (posix-cpu-timers:
Cure SMP wobbles).

(*) 
http://sourceware.org/git/?p=glibc.git;a=blob;f=rt/tst-cpuclock2.c;h=6752721717f959e89c0d692b3f1ee082d507eec2;hb=HEAD

Cc: Olivier Langlois 
Cc: Thomas Gleixner 
Cc: Frederic Weisbecker 
Cc: Ingo Molnar 
Signed-off-by: Peter Zijlstra 
Signed-off-by: KOSAKI Motohiro 
---
 fs/binfmt_elf.c   |2 +-
 fs/binfmt_elf_fdpic.c |2 +-
 include/linux/sched.h |4 ++--
 kernel/posix-cpu-timers.c |   15 ++-
 kernel/sched/core.c   |6 --
 kernel/sched/cputime.c|8 
 6 files changed, 22 insertions(+), 15 deletions(-)

diff --git a/fs/binfmt_elf.c b/fs/binfmt_elf.c
index 86af964..fea51e7 100644
--- a/fs/binfmt_elf.c
+++ b/fs/binfmt_elf.c
@@ -1322,7 +1322,7 @@ static void fill_prstatus(struct elf_prstatus *prstatus,
 * This is the record for the group leader.  It shows the
 * group-wide total, not its individual thread total.
 */
-   thread_group_cputime(p, &cputime);
+   thread_group_cputime(p, true, &cputime);
cputime_to_timeval(cputime.utime, &prstatus->pr_utime);
cputime_to_timeval(cputime.stime, &prstatus->pr_stime);
} else {
diff --git a/fs/binfmt_elf_fdpic.c b/fs/binfmt_elf_fdpic.c
index 9c13e02..ab5b508 100644
--- a/fs/binfmt_elf_fdpic.c
+++ b/fs/binfmt_elf_fdpic.c
@@ -1371,7 +1371,7 @@ static void fill_prstatus(struct elf_prstatus *prstatus,
 * This is the record for the group leader.  It shows the
 * group-wide total, not its individual thread total.
 */
-   thread_group_cputime(p, &cputime);
+   thread_group_cputime(p, true, &cputime);
cputime_to_timeval(cputime.utime, &prstatus->pr_utime);
cputime_to_timeval(cputime.stime, &prstatus->pr_stime);
} else {
diff --git a/include/linux/sched.h b/include/linux/sched.h
index e692a02..7863d4b 100644
--- a/include/linux/sched.h
+++ b/include/linux/sched.h
@@ -2002,7 +2002,7 @@ static inline void disable_sched_clock_irqtime(void) {}
 #endif
 
 extern unsigned long long
-task_sched_runtime(struct task_struct *task);
+task_sched_runtime(struct task_struct *task, bool add_delta);
 
 /* sched_exec is called by processes performing an exec */
 #ifdef CONFIG_SMP
@@ -2625,7 +2625,7 @@ static inline int spin_needbreak(spinlock_t *lock)
 /*
  * Thread group CPU time accounting.
  */
-void thread_group_cputime(struct task_struct *tsk, struct task_cputime *times);
+void thread_group_cputime(struct task_struct *tsk, bool add_delta, struct 
task_cputime *times);
 void thread_group_cputimer(struct task_struct *tsk, struct task_cputime 
*times);
 
 static inline void thread_group_cputime_init(struct signal_struct *sig)
diff --git a/kernel/posix-cpu-timers.c b/kernel/posix-cpu-timers.c
index 8fd709c..e56be4c 100644
--- a/kernel/posix-cpu-timers.c
+++ b/kernel/posix-cpu-timers.c
@@ -220,7 +220,7 @@ static int cpu_clock_sample(const clockid_t which_clock, 
struct task_struct *p,
cpu->cpu = virt_ticks(p);
break;
case CPUCLOCK_SCHED:
-   cpu->sched = task_sched_runtime(p);
+   cpu->sched = task_sched_runtime(p, true);
break;
}
return 0;
@@ -250,8 +250,13 @@ void thread_group_cputimer(struct task_struct *tsk, struct 
task_cputime *times)
 * values through the TIMER_ABSTIME flag, therefore we have
 * to synchronize the timer to the clock every time we start
 * it.
+*
+* Do not add the current delta, because
+* account_group_exec_runtime() will also this delta and we
+* wouldn't want to double account time and get ahead of
+* ourselves.
 */
-   thread_group_cputime(tsk, &sum);
+   thread_group_cputime(tsk, false, &sum);
raw_spin_lock_irqsave(&cputimer->lock, flags);
cputimer->running = 1;
update_gt_cputime(&cputimer->cputime, &sum);
@@ -275,15 +280,15 @@ static int cpu_clock_sample_group(const clockid_t 
which_clock,
default:
return -EINVAL;
case CPUCLOCK_PROF:
-   thread_group_cputime(p, &cputime);
+   thread_group_cputime(p, true, &cputime);
cpu->cpu = cputime.utime + cputime.stime;
break;
case CPUCLOCK_VIRT:
-   thread_group_cputime(p, &cputime);
+   thread_group_cputime(p, true, &cputime);
cpu->cpu = cputime.ut

[PATCH 6/7] sched: task_sched_runtime introduce micro optimization

[kosaki . motohiro]

From: KOSAKI Motohiro 

rq lock in task_sched_runtime() is necessary for two reasons. 1)
accessing se.sum_exec_runtime is not atomic on 32bit and 2)
do_task_delta_exec() require it.

So, 64bit can avoid holding rq lock when add_delta is false and
delta_exec is 0.

Cc: Olivier Langlois 
Cc: Thomas Gleixner 
Cc: Frederic Weisbecker 
Cc: Ingo Molnar 
Suggested-by: Paul Turner 
Acked-by: Peter Zijlstra 
Signed-off-by: KOSAKI Motohiro 
---
 kernel/sched/core.c |   15 +++
 1 files changed, 15 insertions(+), 0 deletions(-)

diff --git a/kernel/sched/core.c b/kernel/sched/core.c
index b817e6d..75872c3 100644
--- a/kernel/sched/core.c
+++ b/kernel/sched/core.c
@@ -2657,6 +2657,21 @@ unsigned long long task_sched_runtime(struct task_struct 
*p, bool add_delta)
struct rq *rq;
u64 ns = 0;
 
+#ifdef CONFIG_64BIT
+   /*
+* 64-bit doesn't need locks to atomically read a 64bit value. So we
+* have two optimization chances, 1) when caller doesn't need
+* delta_exec and 2) when the task's delta_exec is 0. The former is
+* obvious. The latter is complicated. reading ->on_cpu is racy, but
+* this is ok. If we race with it leaving cpu, we'll take a lock. So
+* we're correct. If we race with it entering cpu, unaccounted time
+* is 0. This is indistinguishable from the read occurring a few
+* cycles earlier.
+*/
+   if (!add_delta || !p->on_cpu)
+   return p->se.sum_exec_runtime;
+#endif
+
rq = task_rq_lock(p, &flags);
ns = p->se.sum_exec_runtime;
if (add_delta)
-- 
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 7/7] posix-cpu-timers: cleanup cpu_{clock,timer}_sample{,_group}

[kosaki . motohiro]

From: KOSAKI Motohiro 

Now we have four similar timer related functions, cpu_clock_sample(),
cpu_clock_sample_group(), cpu_timer_sample() and cpu_timer_sample_group().

For readability, make do_cpu_clock_timer_sample() and thread_cputime()
helper functions and all *_sample functions use these.

Cc: Olivier Langlois 
Cc: Thomas Gleixner 
Cc: Frederic Weisbecker 
Cc: Ingo Molnar 
Acked-by: Peter Zijlstra 
Signed-off-by: KOSAKI Motohiro 
---
 include/linux/sched.h |1 +
 kernel/posix-cpu-timers.c |  132 +++-
 kernel/sched/cputime.c|   11 
 3 files changed, 69 insertions(+), 75 deletions(-)

diff --git a/include/linux/sched.h b/include/linux/sched.h
index 7863d4b..73ac8fa 100644
--- a/include/linux/sched.h
+++ b/include/linux/sched.h
@@ -2622,6 +2622,7 @@ static inline int spin_needbreak(spinlock_t *lock)
 #endif
 }
 
+void thread_cputime(struct task_struct *tsk, bool add_delta, struct 
task_cputime *times);
 /*
  * Thread group CPU time accounting.
  */
diff --git a/kernel/posix-cpu-timers.c b/kernel/posix-cpu-timers.c
index 4043282..b33290d 100644
--- a/kernel/posix-cpu-timers.c
+++ b/kernel/posix-cpu-timers.c
@@ -203,46 +203,6 @@ posix_cpu_clock_set(const clockid_t which_clock, const 
struct timespec *tp)
return error;
 }
 
-
-static int do_cpu_clock_timer_sample(const clockid_t which_clock,
-struct task_struct *p,
-bool add_delta,
-union cpu_time_count *cpu)
-{
-   switch (CPUCLOCK_WHICH(which_clock)) {
-   default:
-   return -EINVAL;
-   case CPUCLOCK_PROF:
-   cpu->cpu = prof_ticks(p);
-   break;
-   case CPUCLOCK_VIRT:
-   cpu->cpu = virt_ticks(p);
-   break;
-   case CPUCLOCK_SCHED:
-   cpu->sched = task_sched_runtime(p, add_delta);
-   break;
-   }
-   return 0;
-}
-
-/*
- * Sample a per-thread clock for the given task.
- */
-static int cpu_clock_sample(const clockid_t which_clock, struct task_struct *p,
-   union cpu_time_count *cpu)
-{
-   return do_cpu_clock_timer_sample(which_clock, p, true, cpu);
-}
-
-/*
- * Sample a per-thread timer clock for the given task.
- */
-static int cpu_timer_sample(const clockid_t which_clock, struct task_struct *p,
-   union cpu_time_count *cpu)
-{
-   return do_cpu_clock_timer_sample(which_clock, p, false, cpu);
-}
-
 static void update_gt_cputime(struct task_cputime *a, struct task_cputime *b)
 {
if (b->utime > a->utime)
@@ -284,34 +244,83 @@ void thread_group_cputimer(struct task_struct *tsk, 
struct task_cputime *times)
 }
 
 /*
- * Sample a process (thread group) clock for the given group_leader task.
- * Must be called with tasklist_lock held for reading.
+ * Sample time for the given task.
+ * @which_clock:   Clock id.
+ * @p: Target task. Must be thread group leader when
+ * thread_group is true.
+ * @thread_group:  True if want to get process time.
+ * @add_delta: True if want to get clock time,
+ * otherwise, get timer time.
  */
-static int cpu_clock_sample_group(const clockid_t which_clock,
- struct task_struct *p,
- union cpu_time_count *cpu)
+static int do_cpu_clock_timer_sample(const clockid_t which_clock,
+struct task_struct *p,
+bool thread_group,
+bool clock_time,
+union cpu_time_count *cpu)
 {
struct task_cputime cputime;
 
+   if (thread_group) {
+   if (clock_time)
+   thread_group_cputime(p, true, &cputime);
+   else
+   thread_group_cputimer(p, &cputime);
+   } else
+   thread_cputime(p, clock_time, &cputime);
+
switch (CPUCLOCK_WHICH(which_clock)) {
default:
return -EINVAL;
case CPUCLOCK_PROF:
-   thread_group_cputime(p, true, &cputime);
cpu->cpu = cputime.utime + cputime.stime;
break;
case CPUCLOCK_VIRT:
-   thread_group_cputime(p, true, &cputime);
cpu->cpu = cputime.utime;
break;
case CPUCLOCK_SCHED:
-   thread_group_cputime(p, true, &cputime);
cpu->sched = cputime.sum_exec_runtime;
break;
}
return 0;
 }
 
+/*
+ * Sample a per-thread clock time for the given task.
+ */
+static int cpu_clock_sample(const clockid_t which_clock, struct task_struct *p,
+   union cpu_time_count *cpu)
+{
+   return do_cpu_clock_timer_sample(which_clock, p, false, true, cpu);
+}
+
+/*
+ * Sample a per-process clock time for the gi

[PATCH 5/7] posix-cpu-timers: check_thread_timers() uses task_sched_runtime()

[kosaki . motohiro]

From: KOSAKI Motohiro 

A type of tsk->se.sum_exec_runtime is u64. Thus, reading it is racy when
running 32bit. We should use task_sched_runtime().

Cc: Olivier Langlois 
Cc: Thomas Gleixner 
Cc: Frederic Weisbecker 
Cc: Ingo Molnar 
Acked-by: Peter Zijlstra 
Signed-off-by: KOSAKI Motohiro 
---
 kernel/posix-cpu-timers.c |3 ++-
 1 files changed, 2 insertions(+), 1 deletions(-)

diff --git a/kernel/posix-cpu-timers.c b/kernel/posix-cpu-timers.c
index c69b8d8..4043282 100644
--- a/kernel/posix-cpu-timers.c
+++ b/kernel/posix-cpu-timers.c
@@ -958,7 +958,8 @@ static void check_thread_timers(struct task_struct *tsk,
struct cpu_timer_list *t = list_first_entry(timers,
  struct cpu_timer_list,
  entry);
-   if (!--maxfire || tsk->se.sum_exec_runtime < t->expires.sched) {
+   unsigned long long runtime = task_sched_runtime(tsk, false);
+   if (!--maxfire || runtime < t->expires.sched) {
tsk->cputime_expires.sched_exp = t->expires.sched;
break;
}
-- 
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 3/7] posix-cpu-timers: fix wrong timer initialization

[kosaki . motohiro]

From: KOSAKI Motohiro 

Currently glibc's rt/tst-cputimer1 testcase sporadically fails because
a timer created by timer_create() may fire earlier than specified.

posix_cpu_timer_set() uses "val" as current time for three purpose. 1)
initialize sig->cputimer. 2) calculation "old" val. 3) calculations an
expires.

(1) and (2) should only use committed time (i.e. without delta_exec)
because run_posix_cpu_timers() don't care of delta_exec and we need
consistency, but (3) need exact current time (aka cpu clock time) because
an expires should be "now + timeout" by definition.

This patch distinguishes between two kinds of "now".

Cc: Olivier Langlois 
Cc: Thomas Gleixner 
Cc: Frederic Weisbecker 
Cc: Ingo Molnar 
Acked-by: Peter Zijlstra 
Signed-off-by: KOSAKI Motohiro 
---
 include/linux/kernel_stat.h |5 -
 kernel/posix-cpu-timers.c   |   14 --
 kernel/sched/core.c |   13 -
 3 files changed, 12 insertions(+), 20 deletions(-)

diff --git a/include/linux/kernel_stat.h b/include/linux/kernel_stat.h
index ed5f6ed..f5d4fdf 100644
--- a/include/linux/kernel_stat.h
+++ b/include/linux/kernel_stat.h
@@ -117,11 +117,6 @@ static inline unsigned int kstat_cpu_irqs_sum(unsigned int 
cpu)
return kstat_cpu(cpu).irqs_sum;
 }
 
-/*
- * Lock/unlock the current runqueue - to extract task statistics:
- */
-extern unsigned long long task_delta_exec(struct task_struct *);
-
 extern void account_user_time(struct task_struct *, cputime_t, cputime_t);
 extern void account_system_time(struct task_struct *, int, cputime_t, 
cputime_t);
 extern void account_steal_time(cputime_t);
diff --git a/kernel/posix-cpu-timers.c b/kernel/posix-cpu-timers.c
index e56be4c..98f354e 100644
--- a/kernel/posix-cpu-timers.c
+++ b/kernel/posix-cpu-timers.c
@@ -635,7 +635,7 @@ static int cpu_timer_sample_group(const clockid_t 
which_clock,
cpu->cpu = cputime.utime;
break;
case CPUCLOCK_SCHED:
-   cpu->sched = cputime.sum_exec_runtime + task_delta_exec(p);
+   cpu->sched = cputime.sum_exec_runtime;
break;
}
return 0;
@@ -749,7 +749,17 @@ static int posix_cpu_timer_set(struct k_itimer *timer, int 
flags,
}
 
if (new_expires.sched != 0 && !(flags & TIMER_ABSTIME)) {
-   cpu_time_add(timer->it_clock, &new_expires, val);
+   union cpu_time_count now;
+
+   /*
+* The expires is "now + timeout" by definition. So,
+* we need exact current time.
+*/
+   if (CPUCLOCK_PERTHREAD(timer->it_clock))
+   now = val;
+   else
+   cpu_clock_sample_group(timer->it_clock, p, &now);
+   cpu_time_add(timer->it_clock, &new_expires, now);
}
 
/*
diff --git a/kernel/sched/core.c b/kernel/sched/core.c
index ad3339f..b817e6d 100644
--- a/kernel/sched/core.c
+++ b/kernel/sched/core.c
@@ -2646,19 +2646,6 @@ static u64 do_task_delta_exec(struct task_struct *p, 
struct rq *rq)
return ns;
 }
 
-unsigned long long task_delta_exec(struct task_struct *p)
-{
-   unsigned long flags;
-   struct rq *rq;
-   u64 ns = 0;
-
-   rq = task_rq_lock(p, &flags);
-   ns = do_task_delta_exec(p, rq);
-   task_rq_unlock(rq, p, &flags);
-
-   return ns;
-}
-
 /*
  * Return accounted runtime for the task.
  * In case the task is currently running, return the runtime plus current's
-- 
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 4/7] posix-cpu-timers: timer functions should use timer time instead of clock time

[kosaki . motohiro]

From: KOSAKI Motohiro 

For process timers, we use cpu_clock_sample_group() and cpu_timer_sample_group()
correctly. However, for thread timers, we always use cpu_clock_sample(). This is
wrong because a cpu_clock_sample() accounts uncommitted delta_exec too. And this
is inconsistent against run_posix_cpu_tiemrs().

This is not big matter because the following workaround code in
posix_cpu_timer_get() hides the timer miscalculation issue. However, it makes
rq lock held wrongly and it would be better to fix it.

  if (cpu_time_before(timer->it_clock, now, timer->it.cpu.expires)) {
...
  } else {
/*
 * The timer should have expired already, but the firing
 * hasn't taken place yet.  Say it's just about to expire.
 */
 itp->it_value.tv_nsec = 1;
 itp->it_value.tv_sec = 0;

Cc: Olivier Langlois 
Cc: Thomas Gleixner 
Cc: Frederic Weisbecker 
Cc: Ingo Molnar 
Acked-by: Peter Zijlstra 
Signed-off-by: KOSAKI Motohiro 
---
 kernel/posix-cpu-timers.c |   37 +++--
 1 files changed, 27 insertions(+), 10 deletions(-)

diff --git a/kernel/posix-cpu-timers.c b/kernel/posix-cpu-timers.c
index 98f354e..c69b8d8 100644
--- a/kernel/posix-cpu-timers.c
+++ b/kernel/posix-cpu-timers.c
@@ -204,11 +204,10 @@ posix_cpu_clock_set(const clockid_t which_clock, const 
struct timespec *tp)
 }
 
 
-/*
- * Sample a per-thread clock for the given task.
- */
-static int cpu_clock_sample(const clockid_t which_clock, struct task_struct *p,
-   union cpu_time_count *cpu)
+static int do_cpu_clock_timer_sample(const clockid_t which_clock,
+struct task_struct *p,
+bool add_delta,
+union cpu_time_count *cpu)
 {
switch (CPUCLOCK_WHICH(which_clock)) {
default:
@@ -220,12 +219,30 @@ static int cpu_clock_sample(const clockid_t which_clock, 
struct task_struct *p,
cpu->cpu = virt_ticks(p);
break;
case CPUCLOCK_SCHED:
-   cpu->sched = task_sched_runtime(p, true);
+   cpu->sched = task_sched_runtime(p, add_delta);
break;
}
return 0;
 }
 
+/*
+ * Sample a per-thread clock for the given task.
+ */
+static int cpu_clock_sample(const clockid_t which_clock, struct task_struct *p,
+   union cpu_time_count *cpu)
+{
+   return do_cpu_clock_timer_sample(which_clock, p, true, cpu);
+}
+
+/*
+ * Sample a per-thread timer clock for the given task.
+ */
+static int cpu_timer_sample(const clockid_t which_clock, struct task_struct *p,
+   union cpu_time_count *cpu)
+{
+   return do_cpu_clock_timer_sample(which_clock, p, false, cpu);
+}
+
 static void update_gt_cputime(struct task_cputime *a, struct task_cputime *b)
 {
if (b->utime > a->utime)
@@ -700,7 +717,7 @@ static int posix_cpu_timer_set(struct k_itimer *timer, int 
flags,
 * check if it's already passed.  In short, we need a sample.
 */
if (CPUCLOCK_PERTHREAD(timer->it_clock)) {
-   cpu_clock_sample(timer->it_clock, p, &val);
+   cpu_timer_sample(timer->it_clock, p, &val);
} else {
cpu_timer_sample_group(timer->it_clock, p, &val);
}
@@ -756,7 +773,7 @@ static int posix_cpu_timer_set(struct k_itimer *timer, int 
flags,
 * we need exact current time.
 */
if (CPUCLOCK_PERTHREAD(timer->it_clock))
-   now = val;
+   cpu_clock_sample(timer->it_clock, p, &now);
else
cpu_clock_sample_group(timer->it_clock, p, &now);
cpu_time_add(timer->it_clock, &new_expires, now);
@@ -844,7 +861,7 @@ static void posix_cpu_timer_get(struct k_itimer *timer, 
struct itimerspec *itp)
 * Sample the clock to take the difference with the expiry time.
 */
if (CPUCLOCK_PERTHREAD(timer->it_clock)) {
-   cpu_clock_sample(timer->it_clock, p, &now);
+   cpu_timer_sample(timer->it_clock, p, &now);
clear_dead = p->exit_state;
} else {
read_lock(&tasklist_lock);
@@ -1168,7 +1185,7 @@ void posix_cpu_timer_schedule(struct k_itimer *timer)
 * Fetch the current sample and update the timer's expiry time.
 */
if (CPUCLOCK_PERTHREAD(timer->it_clock)) {
-   cpu_clock_sample(timer->it_clock, p, &now);
+   cpu_timer_sample(timer->it_clock, p, &now);
bump_cpu_timer(timer, now);
if (unlikely(p->exit_state)) {
clear_dead_task(timer, now);
-- 
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 1/7] posix-cpu-timers: don't account cpu timer after stopped thread runtime accounting

[kosaki . motohiro]

From: KOSAKI Motohiro 

When tsk->signal->cputimer->running is 1, signal->cputimer and
tsk->sum_sched_runtime increase at the same pace because update_curr()
increases both accounting.

However, there is one exception. When thread exiting, __exit_signal() turns
over task's sum_shced_runtime to sig->sum_sched_runtime, but it doesn't stop
signal->cputimer accounting.

This inconsistency makes POSIX timer wake up too early. This patch fixes it.

Cc: Thomas Gleixner 
Cc: Frederic Weisbecker 
Cc: Ingo Molnar 
Acked-by: Peter Zijlstra 
Signed-off-by: Olivier Langlois 
Signed-off-by: KOSAKI Motohiro 
---
 kernel/sched/stats.h |7 +++
 1 files changed, 7 insertions(+), 0 deletions(-)

diff --git a/kernel/sched/stats.h b/kernel/sched/stats.h
index 2ef90a5..5a0cfc4 100644
--- a/kernel/sched/stats.h
+++ b/kernel/sched/stats.h
@@ -225,6 +225,13 @@ static inline void account_group_exec_runtime(struct 
task_struct *tsk,
if (!cputimer->running)
return;
 
+   /*
+* After turning over se.sum_exec_runtime to sig->sum_sched_runtime
+* in __exit_signal(), we must not account exec_runtime for consistency.
+*/
+   if (unlikely(!tsk->sighand))
+   return;
+
raw_spin_lock(&cputimer->lock);
cputimer->cputime.sum_exec_runtime += ns;
raw_spin_unlock(&cputimer->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/

[PATCH v4 0/7] posix timers fixlet

[kosaki . motohiro]

From: KOSAKI Motohiro 

Glibc's posix timer testcase found a lot of bugs in posix timer code.
This series, hopefully, fixes all of them. All patches are independent 
each other logically.

Changes from v3
 - task_sched_runtime() micro optimization add to care tsk->on_cpu.
   suggested Paul Turner.
 - fixed several typo in changelogs.


KOSAKI Motohiro (7):
  posix-cpu-timers: don't account cpu timer after stopped thread
runtime accounting
  posix-cpu-timers: fix acounting delta_exec twice
  posix-cpu-timers: fix wrong timer initialization
  posix-cpu-timers: timer functions should use timer time instead of
clock time
  posix-cpu-timers: check_thread_timers() uses task_sched_runtime()
  sched: task_sched_runtime introduce micro optimization
  posix-cpu-timers: cleanup cpu_{clock,timer}_sample{,_group}

 fs/binfmt_elf.c |2 +-
 fs/binfmt_elf_fdpic.c   |2 +-
 include/linux/kernel_stat.h |5 --
 include/linux/sched.h   |5 +-
 kernel/posix-cpu-timers.c   |  143 ---
 kernel/sched/core.c |   34 ++-
 kernel/sched/cputime.c  |   19 +-
 kernel/sched/stats.h|7 ++
 8 files changed, 125 insertions(+), 92 deletions(-)

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

[PATCH V2] cpufreq: cpu0: Free parent node for error cases

[Viresh Kumar]

We are freeing parent node in success cases but not in failure cases. Lets do
it.

Signed-off-by: Viresh Kumar 
---
 drivers/cpufreq/cpufreq-cpu0.c | 5 -
 1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/drivers/cpufreq/cpufreq-cpu0.c b/drivers/cpufreq/cpufreq-cpu0.c
index 3ab8294..8565d41 100644
--- a/drivers/cpufreq/cpufreq-cpu0.c
+++ b/drivers/cpufreq/cpufreq-cpu0.c
@@ -189,7 +189,8 @@ static int cpu0_cpufreq_probe(struct platform_device *pdev)
 
if (!np) {
pr_err("failed to find cpu0 node\n");
-   return -ENOENT;
+   ret = -ENOENT;
+   goto out_put_parent;
}
 
cpu_dev = &pdev->dev;
@@ -264,6 +265,8 @@ out_free_table:
opp_free_cpufreq_table(cpu_dev, &freq_table);
 out_put_node:
of_node_put(np);
+out_put_parent:
+   of_node_put(parent);
return ret;
 }
 
-- 
1.7.12.rc2.18.g61b472e

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

[Jain Priyanka-B32167]

Hello Sebastian,

It is mentioned below that SLxB is broken.
I assume it means bit SLUB and SLAB is broken?
Can you please share the error-details/logs/scenario/steps-to-reproduce.

Regards
Priyanka

> -Original Message-
> From: linux-rt-users-ow...@vger.kernel.org [mailto:linux-rt-users-
> ow...@vger.kernel.org] On Behalf Of Sebastian Andrzej Siewior
> Sent: Tuesday, April 30, 2013 1:42 AM
> To: linux-rt-users
> Cc: LKML; Thomas Gleixner; rost...@goodmis.org
> Subject: [ANNOUNCE] 3.8.10-rt6
> 
> Dear RT Folks,
> 
> I'm pleased to announce the 3.8.10-rt6 release.
> 
> changes since v3.8.10-rt5:
> - the i915 compiles again after I broke it in the last release. A patch
>   was sent by Carsten Emde.
> 
> Known issues:
> 
> - SLxB is broken on PowerPC.
> - suspend / resume seems to program program the timer wrong and wait
>   ages until it continues.
> 
> The delta patch against v3.8.10-rt5 is appended below and can be found
> here:
> 
>   https://www.kernel.org/pub/linux/kernel/projects/rt/3.8/incr/patch-
> 3.8.10-rt5-rt6.patch.xz
> 
> The RT patch against 3.8.9 can be found here:
> 
>   https://www.kernel.org/pub/linux/kernel/projects/rt/3.8/patch-3.8.10-
> rt6.patch.xz
> 
> The split quilt queue is available at:
> 
>   https://www.kernel.org/pub/linux/kernel/projects/rt/3.8/patches-3.8.10-
> rt6.tar.xz
> 
> Sebastian
> 
> diff --git a/drivers/gpu/drm/i915/i915_gem_execbuffer.c
> b/drivers/gpu/drm/i915/i915_gem_execbuffer.c
> index 81125de..eabd3dd 100644
> --- a/drivers/gpu/drm/i915/i915_gem_execbuffer.c
> +++ b/drivers/gpu/drm/i915/i915_gem_execbuffer.c
> @@ -814,6 +814,7 @@ i915_gem_do_execbuffer(struct drm_device *dev, void
> *data,
>   struct intel_ring_buffer *ring;
>   u32 ctx_id = i915_execbuffer2_get_context_id(*args);
>   u32 exec_start, exec_len;
> + u32 seqno;
>   u32 mask;
>   u32 flags;
>   int ret, mode, i;
> @@ -1068,7 +1069,8 @@ i915_gem_do_execbuffer(struct drm_device *dev, void
> *data,
>   goto err;
>   }
> 
> - trace_i915_gem_ring_dispatch(ring, intel_ring_get_seqno(ring),
> flags);
> + seqno = intel_ring_get_seqno(ring);
> + trace_i915_gem_ring_dispatch(ring, seqno, flags);
>   i915_trace_irq_get(ring, seqno);
> 
>   i915_gem_execbuffer_move_to_active(&objects, ring); diff --git
> a/localversion-rt b/localversion-rt index 0efe7ba..8fc605d 100644
> --- a/localversion-rt
> +++ b/localversion-rt
> @@ -1 +1 @@
> --rt5
> +-rt6
> --
> To unsubscribe from this list: send the line "unsubscribe linux-rt-users"
> in the body of a message to majord...@vger.kernel.org More majordomo info
> at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] dma: tegra: implement suspend/resume callbacks

[Vinod Koul]

On Thu, May 02, 2013 at 12:42:30PM -0600, Stephen Warren wrote:
> On 04/30/2013 04:30 AM, Vinod Koul wrote:
> > On Wed, Apr 24, 2013 at 03:24:27PM +0530, Laxman Dewangan wrote:
> >> Implement suspend/resume callbacks to store APB DMA channel's
> >> register on suspend and restore APB DMA channel's register on
> >> resume.
> ...
> > You dont seem to handle suspend when DMA is active? Otherwise looks fine.
> > Stephen, you okay with this patch?
> 
> Yes, I think this looks fine. Sorry for the slow response; I was on
> vacation.
> 
> One question though: Laxman mentioned that DMA clients were responsible
> for suspending their DMA accesses themselves. Does the dmaengine core
> define the semantics here; are DMA drivers supposed to handle suspend
> with active DMAs, or should DMA clients suspend their DMA accesses
> themselves as Laxman suggests? If the latter, I wonder if we actually
> need to save/restore all the registers, since after resume, a new DMA
> access would be started in all cases, which would then reprogram the HW.
No dmaengine doesnt define semantics.

so in case of suspend being invoked when dma is active then driver would need to
stop ongoing DMA and then save. 
But in embedded systems this is not a very typical case, so if your usage
guarantees that this wont happen then it should be okay, but I think it is a
better idea to handle this case.

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

Re: [PATCH v2 03/10] freezer: add new freezable helpers using freezer_do_not_count()

[Tejun Heo]

On Thu, May 02, 2013 at 09:17:21PM -0700, Colin Cross wrote:
> > And I *hope* the lockdep annotation is stricter than what was added
> > before.  I think it better be "no lock ever should be held at this
> > point" rather than "consider this a big lock".
> 
> The previous patch (6aa9707099c4b25700940eb3d016f16c4434360d in Linus'
> tree) already required that no locks be held, it wasn't using a lock
> annotation.

Ooh, cool.  Thanks for the pointer.  Forget about my rambling and
let's just add an unsafe version of try_to_freeze() and be done with
it.  :)

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

Re: [PATCH v2 03/10] freezer: add new freezable helpers using freezer_do_not_count()

[Colin Cross]

On Thu, May 2, 2013 at 9:09 PM, Tejun Heo  wrote:
> Hello,
>
> On Thu, May 02, 2013 at 07:41:39PM -0700, Colin Cross wrote:
>> On Thu, May 2, 2013 at 7:16 PM, Colin Cross  wrote:
>> > This sounds the same as what ended up getting reverted in
>> > https://lkml.org/lkml/2013/3/4/221
>> > I can add the WARN_ON_ONCE to all my new calls, and leave them out of
>> > existing calls, but that seems a little odd, and will be redundant if
>> > the lockdep call in try_to_freeze goes back in in 3.11.  Do you still
>> > want it in the new apis?
> ...
>> I could also put the lockdep check that was reveted back into
>> try_to_freeze(), and add a freezable_schedule_unsafe() that skips it
>> for use in the known-unsafe users in nfs, with a big comment not to
>> add new users of it.
>
> Oh yeah, that sounds like a good idea, and as for the non-ugly
> variants, at least in the mid/long term, I think it'd be best to add
> the lockdep annotation to try_to_freeze() with
> __try_to_freeze_unsafe_youre_gonna_burn_in_hell_if_you_use_this() for
> the existing users which should be gradually converted, but if that's
> too burdensome, adding warnings to the wrappers should do for now, I
> guess.
>
> And I *hope* the lockdep annotation is stricter than what was added
> before.  I think it better be "no lock ever should be held at this
> point" rather than "consider this a big lock".

The previous patch (6aa9707099c4b25700940eb3d016f16c4434360d in Linus'
tree) already required that no locks be held, it wasn't using a lock
annotation.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v2 03/10] freezer: add new freezable helpers using freezer_do_not_count()

[Tejun Heo]

On Thu, May 02, 2013 at 09:09:34PM -0700, Tejun Heo wrote:
> But that conflicts with what you're doing here which seems pretty
> useful, so, to satisfy both goals, when somebody needs to put a
> pseudo-frozen task into the actual frozen jobctl stop, those spots
> which are currently using try_to_stop() would have to return an error,
> most likely -EINTR with TIF_SIGPENDING set, and the control should

Let's make that -ERESTART*.

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

linux-next: Tree for May 3

[Stephen Rothwell]

Hi all,

Please do not add any v3.11 destined work to your linux-next included
branches until after v3.10-rc1 is released.

Changes since 20130502:





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 224 trees (counting Linus' and 31 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 (0279b3c Merge branch 'sched-urgent-for-linus' of 
git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip)
Merging fixes/master (0279b3c Merge branch 'sched-urgent-for-linus' of 
git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip)
Merging kbuild-current/rc-fixes (a54292f kbuild: generate generic headers 
before recursing into scripts)
Merging arc-current/for-curr (561daec ARC: [mm] Lazy D-cache flush (non 
aliasing VIPT))
Merging arm-current/fixes (1783d45 ARM: 7700/2: Make cpu_init() notrace)
Merging m68k-current/for-linus (e00c73e m68k: Remove inline strlen() 
implementation)
Merging powerpc-merge/merge (5676005 powerpc/pseries/lparcfg: Fix possible 
overflow are more than 1026)
Merging sparc/master (0fbd067 Merge 
git://git.kernel.org/pub/scm/linux/kernel/git/davem/sparc)
Merging net/master (af5c6df drivers: net: cpsw: irq not disabled in cpsw isr in 
particular sequence)
Applying: drivers:net: fix up for code movement from rt2x00pci.c
Merging ipsec/master (da241ef Merge 
git://git.kernel.org/pub/scm/linux/kernel/git/davem/net)
Merging sound-current/for-linus (c5a4698 Merge tag 'asoc-maintainers-v3.9-rc6' 
of git://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound into for-linus)
Merging pci-current/for-linus (d46fc8b x86/pci/mrst: Use configuration 
mechanism 1 for 00:00.0, 00:02.0, 00:03.0)
Merging wireless/master (a8a48e6 Merge tag 'nfc-next-3.10-4' of 
git://git.kernel.org/pub/scm/linux/kernel/git/sameo/nfc-next)
Merging driver-core.current/driver-core-linus (c1be5a5 Linux 3.9)
Merging tty.current/tty-linus (c1be5a5 Linux 3.9)
Merging usb.current/usb-linus (c1be5a5 Linux 3.9)
Merging staging.current/staging-linus (c1be5a5 Linux 3.9)
Merging char-misc.current/char-misc-linus (c1be5a5 Linux 3.9)
Merging input-current/for-linus (bf61c88 Merge branch 'next' into for-linus)
Merging md-current/for-linus (32f9f57 MD: ignore discard request for hard disks 
of hybid raid1/raid10 array)
Merging audit-current/for-linus (c158a35 audit: no leading space in 
audit_log_d_path prefix)
Merging crypto-current/master (3862de1 crypto: caam - fix job ring cleanup code)
Merging ide/master (bf6b438 ide: gayle: use module_platform_driver_probe())
Merging dwmw2/master (5950f08 pcmcia: remove RPX board stuff)
Merging sh-current/sh-fixes-for-linus (4403310 SH: Convert out[bwl] macros to 
inline functions)
Merging irqdomain-current/irqdomain/merge (a0d271c Linux 3.6)
Merging devicetree-current/devicetree/merge (ab28698 of: define struct device 
in of_platform.h if !OF_DEVICE and !OF_ADDRESS)
Merging spi-current/spi/merge (0d2d0cc spi/davinci: fix module build error)
Merging gpio-current/gpio/merge (e97f9b5 gpio/gpio-ich: fix 
ichx_gpio_check_available() return what callers expect)
Merging rr-fixes/fixes (c1be5a5 Linux 3.9)
Merging mfd-fixes/master (3

Re: [PATCH v2 03/10] freezer: add new freezable helpers using freezer_do_not_count()

[Tejun Heo]

Hello,

On Thu, May 02, 2013 at 07:41:39PM -0700, Colin Cross wrote:
> On Thu, May 2, 2013 at 7:16 PM, Colin Cross  wrote:
> > This sounds the same as what ended up getting reverted in
> > https://lkml.org/lkml/2013/3/4/221
> > I can add the WARN_ON_ONCE to all my new calls, and leave them out of
> > existing calls, but that seems a little odd, and will be redundant if
> > the lockdep call in try_to_freeze goes back in in 3.11.  Do you still
> > want it in the new apis?
...
> I could also put the lockdep check that was reveted back into
> try_to_freeze(), and add a freezable_schedule_unsafe() that skips it
> for use in the known-unsafe users in nfs, with a big comment not to
> add new users of it.

Oh yeah, that sounds like a good idea, and as for the non-ugly
variants, at least in the mid/long term, I think it'd be best to add
the lockdep annotation to try_to_freeze() with
__try_to_freeze_unsafe_youre_gonna_burn_in_hell_if_you_use_this() for
the existing users which should be gradually converted, but if that's
too burdensome, adding warnings to the wrappers should do for now, I
guess.

And I *hope* the lockdep annotation is stricter than what was added
before.  I think it better be "no lock ever should be held at this
point" rather than "consider this a big lock".  I'm not sure how much
consensus we have on this but I'd like to, in the longer term, merge
freezer into job control stop so that frozen tasks don't appear as
being in uninterruptible sleep.  Currently, the frozen tasks are
essentially in UNINTERRUPTIBLE sleep which is okay for suspend but for
cgroup freezer, it sucks.  You end up with tasks which you can't even
kill.

Combined with the locking problems, I was planning to update the
freezer such that the frozen state is implemented as a form of jobctl
stop, so that things like ptrace / kill -9 could work on them and we
also have the clear definition of the frozen state rather than the
current "it may get stuck somewhere in the kernel".

But that conflicts with what you're doing here which seems pretty
useful, so, to satisfy both goals, when somebody needs to put a
pseudo-frozen task into the actual frozen jobctl stop, those spots
which are currently using try_to_stop() would have to return an error,
most likely -EINTR with TIF_SIGPENDING set, and the control should
return towards userland so that signal handling path can be invoked.
ie. It should be possible to steer the tasks which are considered
frozen but not in the frozen jobctl stop into the jobctl stop without
any side effect.  To do that, those spots basically have to be pretty
close to the userland boundary where it can easily leave the kernel
with -EINTR and AFAICS all the spots that you converted are like that
(which I think is natural).  While not holding any locks doesn't
guarantee that, I think there'd be a fairly high correlation at least
and it'd be able to drive people towards finding out what's going on.

So, that's my agenda.  Not sure how many actually agree with it.
Rafael, Oleg, Jeff?

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/

KVM VM(rhel-5.5) %si is too high when TX/RX packets

[Zhanghaoyu (A)]

I running a VM(RHEL-5.5) on KVM hypervisor(linux-3.8 + QEMU-1.4.1), and 
direct-assign intel 82576 VF to the VM. When TX/RX packets on VM to the other 
host via iperf tool, top tool result on VM shown that the %si is too high, 
approximately 95% ~ 100%, but from the view of host, the VM's total CPU usage 
is about 20% - 30%. And the throughput rate is approximately 200Mb/s, far from 
the line rate 1Gb/s, 
And, I found  the hardirq rate is lower than normal by running "watch -d -n 1 
cat /proc/interrupts", I think it's caused by the too high %si, because the 
NIC's hardirq was disabled during the softirq process.
Then, I direct-assign the intel 82576 to the VM, the same case happened too. 
I found the intel 82576 and intel 82576 VF's interrupt mode are both PCI-MSI-X.

And,
I rmmod the igb driver, and, re-insmod the igb driver(igb-4.1.2) with the 
parameter IntMode=0/1(0:legacy, 1:MSI, 2:MSI-x), the problem then gone, the %si 
is approximately 20% -30%, and the throughput rate came to the line rate, about 
940Mb/s.
I update the VM to RHEL-6.1, the problem disappeared too.
And, I found a very strange thing, the VM's 82576VF's irq routing is set one 
time on Vf's one interrupt received, so frequently.

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

Re: [PATCH v3 net-next] net/usb: new driver for RTL8152

[David Miller]

From: 'Greg KH' 
Date: Thu, 2 May 2013 20:23:15 -0700

> On Fri, May 03, 2013 at 11:11:47AM +0800, hayeswang wrote:
>> Greg KH [mailto:gre...@linuxfoundation.org] 
>> > Sent: Friday, May 03, 2013 10:33 AM
>> > To: Hayeswang
>> > Cc: oli...@neukum.org; net...@vger.kernel.org; 
>> > linux-kernel@vger.kernel.org; linux-...@vger.kernel.org; nic_swsd
>> > Subject: Re: [PATCH v3 net-next] net/usb: new driver for RTL8152
>> > 
>> > On Fri, May 03, 2013 at 10:01:25AM +0800, Hayes Wang wrote:
>> > > Add new driver for supporting Realtek RTL8152 Based USB 2.0 
>> > Ethernet Adapters
>> > > 
>> > > Signed-off-by: Hayes Wang 
>> > > Cc: Realtek linux nic maintainers 
>> > 
>> > You removed the wording I had questions about last time, does 
>> > that mean
>> > the previous wording was not correct, or that you no longer are
>> > publicising the fact that this driver reads on some patents that you
>> > own?
>> > 
>> > You also failed to answer my previous questions, why?
>> 
>> That description is about the patent for the hw design, not for
>> software. It indicates that the design of the hw uses those patents
>> from the other compnay. I have no idea about how to deal with those
>> patents. What should I do for sending a patch? 
> 
> That makes sense to me, removing it is correct.  It's now up to the
> netdev developers to accept this, thanks for the quick response.

I think this clears things up and that specific issue is no longer a
blocker for inclusion.

I'll let this sit on the list so that it may be reviewed on it's
technical merits.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v3 net-next] net/usb: new driver for RTL8152

['Greg KH']

On Fri, May 03, 2013 at 11:11:47AM +0800, hayeswang wrote:
> Greg KH [mailto:gre...@linuxfoundation.org] 
> > Sent: Friday, May 03, 2013 10:33 AM
> > To: Hayeswang
> > Cc: oli...@neukum.org; net...@vger.kernel.org; 
> > linux-kernel@vger.kernel.org; linux-...@vger.kernel.org; nic_swsd
> > Subject: Re: [PATCH v3 net-next] net/usb: new driver for RTL8152
> > 
> > On Fri, May 03, 2013 at 10:01:25AM +0800, Hayes Wang wrote:
> > > Add new driver for supporting Realtek RTL8152 Based USB 2.0 
> > Ethernet Adapters
> > > 
> > > Signed-off-by: Hayes Wang 
> > > Cc: Realtek linux nic maintainers 
> > 
> > You removed the wording I had questions about last time, does 
> > that mean
> > the previous wording was not correct, or that you no longer are
> > publicising the fact that this driver reads on some patents that you
> > own?
> > 
> > You also failed to answer my previous questions, why?
> 
> That description is about the patent for the hw design, not for
> software. It indicates that the design of the hw uses those patents
> from the other compnay. I have no idea about how to deal with those
> patents. What should I do for sending a patch? 

That makes sense to me, removing it is correct.  It's now up to the
netdev developers to accept this, thanks for the quick response.

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

Re: [PATCH] sched: wake-affine throttle

[Michael Wang]

On 04/10/2013 11:30 AM, Michael Wang wrote:

Now long time has been passed since the first version, I'd like to 
do some summary about current states:

On a 12 cpu box with tip 3.9.0-rc7, test show that:

1. remove wake-affine stuff cause regression on hackbench (could be 15%).
2. reserve wake-affine stuff cause regression on pgbench (could be 45%).

And since neither remove or reserve is acceptable, this patch introduced a
knob to throttle wake-affine stuff.

By turning the knob, we could benefit both hackbench and pgbench, or sacrifice
one to significantly benefit another.

All similar workload which prefer or hate wake-affine behaviour could
been cared.

If this approach caused any concerns, please let me know ;-)

Regards,
Michael Wang

> 
> Recently testing show that wake-affine stuff cause regression on pgbench, the
> hiding rat was finally catched out.
> 
> wake-affine stuff is always trying to pull wakee close to waker, by theory,
> this will benefit us if waker's cpu cached hot data for wakee, or the extreme
> ping-pong case.
> 
> However, the whole stuff is somewhat blindly, load balance is the only factor
> to be guaranteed, and since the stuff itself is time-consuming, some workload
> suffered, pgbench is just the one who has been found.
> 
> Thus, throttle the wake-affine stuff for such workload is necessary.
> 
> This patch introduced a new knob 'sysctl_sched_wake_affine_interval' with the
> default value 1ms (default minimum balance interval), which means wake-affine
> will keep silent for 1ms after it returned false.
> 
> By turning the new knob, those workload who suffered will have the chance to
> stop the regression.
> 
> Test:
>   Test with 12 cpu X86 server and tip 3.9.0-rc2.
> 
>   default
>   base1ms interval 10ms interval   100ms interval
> | db_size | clients |  tps  | |  tps  ||  tps  | |  tps  |
> +-+-+---+-  +---++---+ +---+
> | 21 MB   |   1 | 10572 |   | 10804 || 10802 | | 10801 |
> | 21 MB   |   2 | 21275 |   | 21533 || 21400 | | 21498 |
> | 21 MB   |   4 | 41866 |   | 42158 || 42410 | | 42306 |
> | 21 MB   |   8 | 53931 |   | 55796 || 58608 | +8.67%  | 59916 | 
> +11.10%
> | 21 MB   |  12 | 50956 |   | 52266 || 54586 | +7.12%  | 55982 | 
> +9.86%
> | 21 MB   |  16 | 49911 |   | 52862 | +5.91% | 55668 | +11.53% | 57255 | 
> +14.71%
> | 21 MB   |  24 | 46046 |   | 48820 | +6.02% | 54269 | +17.86% | 58113 | 
> +26.21%
> | 21 MB   |  32 | 43405 |   | 46635 | +7.44% | 53690 | +23.70% | 57729 | 
> +33.00%
> | 7483 MB |   1 |  7734 |   |  8013 ||  8046 | |  7879 |
> | 7483 MB |   2 | 19375 |   | 19459 || 19448 | | 19421 |
> | 7483 MB |   4 | 37408 |   | 37780 || 37937 | | 37819 |
> | 7483 MB |   8 | 49033 |   | 50389 || 51636 | +5.31%  | 52294 | 
> +6.65%
> | 7483 MB |  12 | 45525 |   | 47794 | +4.98% | 49828 | +9.45%  | 50571 | 
> +11.08%
> | 7483 MB |  16 | 45731 |   | 47921 | +4.79% | 50203 | +9.78%  | 52033 | 
> +13.78%
> | 7483 MB |  24 | 41533 |   | 44301 | +6.67% | 49697 | +19.66% | 53833 | 
> +29.62%
> | 7483 MB |  32 | 36370 |   | 38301 | +5.31% | 48146 | +32.38% | 52795 | 
> +45.16%
> | 15 GB   |   1 |  7576 |   |  7926 ||  7722 | |  7969 |
> | 15 GB   |   2 | 19157 |   | 19284 || 19294 | | 19304 |
> | 15 GB   |   4 | 37285 |   | 37539 || 37281 | | 37508 |
> | 15 GB   |   8 | 48718 |   | 49176 || 50836 | +4.35%  | 51239 | 
> +5.17%
> | 15 GB   |  12 | 45167 |   | 47180 | +4.45% | 49206 | +8.94%  | 50126 | 
> +10.98%
> | 15 GB   |  16 | 45270 |   | 47293 | +4.47% | 49638 | +9.65%  | 51748 | 
> +14.31%
> | 15 GB   |  24 | 40984 |   | 43366 | +5.81% | 49356 | +20.43% | 53157 | 
> +29.70%
> | 15 GB   |  32 | 35918 |   | 37632 | +4.77% | 47923 | +33.42% | 52241 | 
> +45.45%
> 
> Suggested-by: Peter Zijlstra 
> Signed-off-by: Michael Wang 
> ---
>  include/linux/sched.h |5 +
>  kernel/sched/fair.c   |   31 +++
>  kernel/sysctl.c   |   10 ++
>  3 files changed, 46 insertions(+), 0 deletions(-)
> 
> diff --git a/include/linux/sched.h b/include/linux/sched.h
> index d35d2b6..e9efd3a 100644
> --- a/include/linux/sched.h
> +++ b/include/linux/sched.h
> @@ -1197,6 +1197,10 @@ enum perf_event_task_context {
>   perf_nr_task_contexts,
>  };
> 
> +#ifdef CONFIG_SMP
> +extern unsigned int sysctl_sched_wake_affine_interval;
> +#endif
> +
>  struct task_struct {
>   volatile long state;/* -1 unrunnable, 0 runnable, >0 stopped */
>   void *stack;
> @@ -1207,6 +1211,7 @@ struct task_struct {
>  #ifdef CONFIG_SMP
>   struct llist_node wake_entry;
>   int on_cpu;
> + unsigned long next_wake_affine;
>  #endif
>   int on_rq;
> 

Re: Re: Re: [PATCH] UBI: fix memory leak when use fastmap

[wang . bo116]

richard -rw- weinberger  write 2013-05-03 
03:21:33:

> On Thu, May 2, 2013 at 10:30 AM,   wrote:
> >> Hi!
> >>
> >> On Tue, Apr 16, 2013 at 10:53 AM,   wrote:
> >> > Hello,
> >> > Sorry, there is still something wrong with the previous
> > patch's
> >> > format, try to submit it again. When use ubi fastmap, there is a
> > memory
> >> > leak which will make destroy_ai() fail to free the slab alloced in
> >> > scan_fast(). The following patch fix this problem by use a 
temporary
> >> > "ubi_attach_info" variable in scan_fast().
> >>
> >> Thanks a lot for your patch!
> >>
> >> Did you test it well?
> >> We need to make sure that it does the right thing for the following
> > cases:
> >> 1. fastmap disabled, attaching a non-fastmap volume
> >> 1. fastmap disabled, attaching a fastmap volume
> >> 3. fastmap enabled, attaching a non-fastmap volume
> >> 4. fastmap enablled, attaching a fastmap volume
> >>
> >> --
> >> Thanks,
> >> //richard
> >
> >
> > Thanks for your advice. I consider this problem like this:
> > 1: if fastmap not config, ubi_attach() just call scan_all(ubi, ai, 0),
> > there is nothing changed, so there is all right.
> >
> > 2: if fastmap config, and force_scan is 0, ubi_attach() will call
> > scan_fast(), when scan_fast() return, temp ai used in scan_fast() has 
been
> > free, and there will be two conditions:
> > A: scan_fast() return UBI_NO_FASTMAP(may be flash is empty or 
attaching a
> > non-fastmap volume), all ubi_attach() need is to call scan_all(ubi, 
ai, 0)
> > to scan all blocks.
> > B: scan_fast() return UBI_BAD_FASTMAP, ubi_attach() first free ai used 
in
> > ubi_scan_fastmap(), then alloc a clean ai, at last call scan_all(ubi, 
ai,
> > 0) to scan all blocks.
> >
> > 3: if fastmap config, and force_scan is 1, just call scan_all(ubi, ai, 
0).
> >
> > This patch pass the following cases(include attach and detach):
> > 1. fastmap config, flash is empty,fm_autoconvert is 1.
> > 2. fastmap config, flash is empty,fm_autoconvert is 0.
> > 3. fastmap config, attaching a fastmap volume
> > 4. fastmap config, attaching a bad fastmap volume
> > 5. fastmap config, attaching a non-fastmap volume
> > 6. fastmap not config, attaching a fastmap volume
> > 7. fastmap not config, attaching a non-fastmap volume
> > 8. fastmap not config, flash is empty.
> 
> Good. :)
> 
> > By the way, the problem may cause ubi_attach() fail after ubi detach 
when
> > CONFIG_DEBUG_VM config.
> > The reason is that ubi_attach() will alloc a slab cache, but the
> > kmem_cache_sanity_check() will find the slab cache is already 
exist(not
> > been free after last detach), so slab cache alloc fail, and 
ubi_attach()
> > fail, too.
> 
> Doesn't your patch address this issue too?
> If not, we should fix this.Th

The patch had already fix the above problem mentioned. 
Now, all the slabs belong to the slab-cache named "ubi_aeb_slab_cache" can 
be rightly freed, so the slab-cache can be rightly freed when ubi_attach() 
return.
When ubi attach again after detach, ubi can alloc a slab-cache named "
ubi_aeb_slab_cache" again.
 

Thanks
---wangbo
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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: X86 fpu registers in a signal handler's ucontext

[H. Peter Anvin]

On 04/29/2013 07:34 AM, Warlich, Christof wrote:
> Second, only FP state seems to be available through ucontext_t, and I would
> need to clear exceptions for SSE as well.

Not true.

> Can anyone give me some advice on how to I could proceed?

To optimize the common case, if the signal handler doesn't touch the FPU
the state is not reloaded from the signal stack.  Therefore you need to
execute an FPU instruction -- pretty much any FPU instruction -- in your
signal handler in order to force the reload.

-hpa

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

Re: [PATCH v2 07/10] futex: use freezable blocking call

[Darren Hart]

On 05/02/2013 12:45 PM, Thomas Gleixner wrote:
> On Wed, 1 May 2013, Colin Cross wrote:
> 
>> Avoid waking up every thread sleeping in a futex_wait call during
>> suspend and resume by calling a freezable blocking call.  Previous
>> patches modified the freezer to avoid sending wakeups to threads
>> that are blocked in freezable blocking calls.
>>
>> This call was selected to be converted to a freezable call because
>> it doesn't hold any locks or release any resources when interrupted
>> that might be needed by another freezing task or a kernel driver
>> during suspend, and is a common site where idle userspace tasks are
>> blocked.
>>
>> Signed-off-by: Colin Cross 
> 
> Acked-by: Thomas Gleixner 

Beat me to it :-) Also agreed.

Acked-by: Darren Hart 

> 
>> ---
>>  kernel/futex.c | 3 ++-
>>  1 file changed, 2 insertions(+), 1 deletion(-)
>>
>> diff --git a/kernel/futex.c b/kernel/futex.c
>> index b26dcfc..d710fae 100644
>> --- a/kernel/futex.c
>> +++ b/kernel/futex.c
>> @@ -61,6 +61,7 @@
>>  #include 
>>  #include 
>>  #include 
>> +#include 
>>  
>>  #include 
>>  
>> @@ -1807,7 +1808,7 @@ static void futex_wait_queue_me(struct 
>> futex_hash_bucket *hb, struct futex_q *q,
>>   * is no timeout, or if it has yet to expire.
>>   */
>>  if (!timeout || timeout->task)
>> -schedule();
>> +freezable_schedule();
>>  }
>>  __set_current_state(TASK_RUNNING);
>>  }
>> -- 
>> 1.8.2.1
>>
>>

-- 
Darren Hart
Intel Open Source Technology Center
Yocto Project - Technical Lead - Linux Kernel
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

RE: [PATCH v3 net-next] net/usb: new driver for RTL8152

[hayeswang]

Greg KH [mailto:gre...@linuxfoundation.org] 
> Sent: Friday, May 03, 2013 10:33 AM
> To: Hayeswang
> Cc: oli...@neukum.org; net...@vger.kernel.org; 
> linux-kernel@vger.kernel.org; linux-...@vger.kernel.org; nic_swsd
> Subject: Re: [PATCH v3 net-next] net/usb: new driver for RTL8152
> 
> On Fri, May 03, 2013 at 10:01:25AM +0800, Hayes Wang wrote:
> > Add new driver for supporting Realtek RTL8152 Based USB 2.0 
> Ethernet Adapters
> > 
> > Signed-off-by: Hayes Wang 
> > Cc: Realtek linux nic maintainers 
> 
> You removed the wording I had questions about last time, does 
> that mean
> the previous wording was not correct, or that you no longer are
> publicising the fact that this driver reads on some patents that you
> own?
> 
> You also failed to answer my previous questions, why?

That description is about the patent for the hw design, not for software. It
indicates that the design of the hw uses those patents from the other compnay. I
have no idea about how to deal with those patents. What should I do for sending
a patch? 

Best Regards,
Hayes

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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: Subject : [ PATCH ] pci-reset-error_state-to-pci_channel_io_normal-at-report_slot_reset

[Yanmin Zhang]

On Thu, 2013-05-02 at 19:00 -0700, Greg Kroah-Hartman wrote:
> On Fri, May 03, 2013 at 08:33:00AM +0800, Yanmin Zhang wrote:
> > On Wed, 2013-05-01 at 20:20 -0500, Linas Vepstas wrote:
> > > Hi,
> > > 
> > > On 1 May 2013 19:30, Yanmin Zhang 
> > > wrote:
> > > On Fri, 2013-04-26 at 06:28 +, Zhang, LongX wrote:
> > > > From: Zhang Long 
> > > >
> > > > Specific pci device drivers might have many functions to
> > > call
> > > > pci_channel_offline to check device states. When slot_reset
> > > happens,
> > > > drivers' slot_reset callback might call such functions and
> > > eventually
> > > > abort the reset.
> > > >
> > > > The patch resets pdev->error_state to pci_channel_io_normal
> > > at
> > > > the begining of report_slot_reset.
> > > >
> > > > Thank Liu Joseph for pointing it out.
> > > 
> > > Linas, Bjorn,
> > > 
> > > Would you like to merge the patch to your testing tree?
> > > The patch resolves one issue pointed out by Joseph.
> > > 
> > > 
> > > I'm not maintaining a tree at this time, and am not able to test.
> > > Sorry.
> > Thanks Linas.
> > 
> > Greg,
> > 
> > Would you like to merge it into your testing tree? Joseph Liu tested
> > the patch and it does work.
> 
> You do know about the scripts/get_maintainer.pl script, right?
> 
> Hint, try it out :)
Greg,

Thanks. We did send to the right people, Linas and Bjorn.

scripts/get_maintainer.pl 
0001-pci-reset-error_state-to-pci_channel_io_normal-at-re.patch
Bjorn Helgaas  (supporter:PCI 
SUBSYSTEM,commit_signer:7/8=88%,commit_signer:10/11=91%)
Linas Vepstas  (commit_signer:2/8=25%)
Yijing Wang  
(commit_signer:2/8=25%,commit_signer:2/11=18%)
Jiang Liu  (commit_signer:2/8=25%,commit_signer:2/11=18%)
Stephen Hemminger  (commit_signer:1/8=12%)
"Rafael J. Wysocki"  (commit_signer:6/11=55%)
Huang Ying  (commit_signer:5/11=45%)
linux-...@vger.kernel.org (open list:PCI SUBSYSTEM)
linux-kernel@vger.kernel.org (open list)


I remember Jesse was maintaining PCI subsystem and he responded quickly.

Yanmin


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] trivial: beautify code, let 'inline' in front of 'void'

[Chen Gang]

Let 'inline' in front of 'void' to make code more beautiful.

It also can avoid the related warnings when EXTRA_CFLAGS=-W.


Signed-off-by: Chen Gang 
---
 arch/ia64/kernel/mca.c |2 +-
 arch/ia64/sn/pci/pcibr/pcibr_ate.c |2 +-
 arch/ia64/sn/pci/tioce_provider.c  |4 ++--
 arch/mips/emma/markeins/setup.c|2 +-
 arch/mips/sgi-ip32/ip32-irq.c  |4 ++--
 arch/sh/mm/cache-sh5.c |2 +-
 arch/sparc/include/asm/spinlock_32.h   |2 +-
 arch/sparc/include/asm/spinlock_64.h   |8 
 arch/xtensa/platforms/iss/network.c|2 +-
 drivers/edac/amd64_edac.h  |2 +-
 drivers/net/ethernet/freescale/gianfar.c   |2 +-
 drivers/net/wireless/ipw2x00/ipw2200.c |2 +-
 drivers/platform/x86/thinkpad_acpi.c   |2 +-
 drivers/scsi/tmscsim.c |2 +-
 drivers/video/omap/lcdc.c  |6 +++---
 fs/btrfs/delayed-ref.c |2 +-
 include/linux/platform_data/usb-ohci-s3c2410.h |2 +-
 sound/drivers/opl4/opl4_lib.c  |2 +-
 18 files changed, 25 insertions(+), 25 deletions(-)

diff --git a/arch/ia64/kernel/mca.c b/arch/ia64/kernel/mca.c
index d7396db..f34627f 100644
--- a/arch/ia64/kernel/mca.c
+++ b/arch/ia64/kernel/mca.c
@@ -332,7 +332,7 @@ static void ia64_mlogbuf_dump_from_init(void)
ia64_mlogbuf_dump();
 }
 
-static void inline
+static inline void
 ia64_mca_spin(const char *func)
 {
if (monarch_cpu == smp_processor_id())
diff --git a/arch/ia64/sn/pci/pcibr/pcibr_ate.c 
b/arch/ia64/sn/pci/pcibr/pcibr_ate.c
index 5bc34ea..b67bb4c 100644
--- a/arch/ia64/sn/pci/pcibr/pcibr_ate.c
+++ b/arch/ia64/sn/pci/pcibr/pcibr_ate.c
@@ -140,7 +140,7 @@ static inline u64 __iomem *pcibr_ate_addr(struct 
pcibus_info *pcibus_info,
 /*
  * Update the ate.
  */
-void inline
+inline void
 ate_write(struct pcibus_info *pcibus_info, int ate_index, int count,
  volatile u64 ate)
 {
diff --git a/arch/ia64/sn/pci/tioce_provider.c 
b/arch/ia64/sn/pci/tioce_provider.c
index 46d3df4..3bd9abc 100644
--- a/arch/ia64/sn/pci/tioce_provider.c
+++ b/arch/ia64/sn/pci/tioce_provider.c
@@ -52,7 +52,7 @@
  * All registers defined in struct tioce will meet that criteria.
  */
 
-static void inline
+static inline void
 tioce_mmr_war_pre(struct tioce_kernel *kern, void __iomem *mmr_addr)
 {
u64 mmr_base;
@@ -78,7 +78,7 @@ tioce_mmr_war_pre(struct tioce_kernel *kern, void __iomem 
*mmr_addr)
}
 }
 
-static void inline
+static inline void
 tioce_mmr_war_post(struct tioce_kernel *kern, void __iomem *mmr_addr)
 {
u64 mmr_base;
diff --git a/arch/mips/emma/markeins/setup.c b/arch/mips/emma/markeins/setup.c
index d710058..a965266 100644
--- a/arch/mips/emma/markeins/setup.c
+++ b/arch/mips/emma/markeins/setup.c
@@ -90,7 +90,7 @@ void __init plat_time_init(void)
 static void markeins_board_init(void);
 extern void markeins_irq_setup(void);
 
-static void inline __init markeins_sio_setup(void)
+static inline void __init markeins_sio_setup(void)
 {
 }
 
diff --git a/arch/mips/sgi-ip32/ip32-irq.c b/arch/mips/sgi-ip32/ip32-irq.c
index e0c7d9e..838d858 100644
--- a/arch/mips/sgi-ip32/ip32-irq.c
+++ b/arch/mips/sgi-ip32/ip32-irq.c
@@ -28,12 +28,12 @@
 #include 
 
 /* issue a PIO read to make sure no PIO writes are pending */
-static void inline flush_crime_bus(void)
+static inline void flush_crime_bus(void)
 {
crime->control;
 }
 
-static void inline flush_mace_bus(void)
+static inline void flush_mace_bus(void)
 {
mace->perif.ctrl.misc;
 }
diff --git a/arch/sh/mm/cache-sh5.c b/arch/sh/mm/cache-sh5.c
index d1bffbc..dca8cf5 100644
--- a/arch/sh/mm/cache-sh5.c
+++ b/arch/sh/mm/cache-sh5.c
@@ -234,7 +234,7 @@ static void sh64_icache_inv_current_user_range(unsigned 
long start, unsigned lon
 #define DUMMY_ALLOCO_AREA_SIZE ((L1_CACHE_BYTES << 10) + (1024 * 4))
 static unsigned char dummy_alloco_area[DUMMY_ALLOCO_AREA_SIZE] 
__cacheline_aligned = { 0, };
 
-static void inline sh64_dcache_purge_sets(int sets_to_purge_base, int n_sets)
+static inline void sh64_dcache_purge_sets(int sets_to_purge_base, int n_sets)
 {
/* Purge all ways in a particular block of sets, specified by the base
   set number and number of sets.  Can handle wrap-around, if that's
diff --git a/arch/sparc/include/asm/spinlock_32.h 
b/arch/sparc/include/asm/spinlock_32.h
index bcc98fc..56637a2 100644
--- a/arch/sparc/include/asm/spinlock_32.h
+++ b/arch/sparc/include/asm/spinlock_32.h
@@ -131,7 +131,7 @@ static inline void arch_write_lock(arch_rwlock_t *rw)
*(volatile __u32 *)&lp->lock = ~0U;
 }
 
-static void inline arch_write_unlock(arch_rwlock_t *lock)
+static inline void arch_write_unlock(arch_rwlock_t *lock)
 {
__asm__ __volatile__(
 "  st  %%g0, [%0]"
diff --git a/arch/sparc/include/asm/spinlock_64.h 
b/arch/spa

Re: OOM-killer and strange RSS value in 3.9-rc7

[Han Pingtian]

On Thu, May 02, 2013 at 03:10:15PM +, Christoph Lameter wrote:
> On Thu, 2 May 2013, Han Pingtian wrote:
> 
> > Looks like "ibmvscsi" + "slub" can trigger this problem.
> 
> And the next merge of the slab-next tree will also cause SLAB to trigger
> this issue. I would like to have this fixes. The slab allocator purpose is
> to servr objects that are a fraction of a page and not objects that are
> larger than the maximum allowed sizes of the page allocator.

So the problem is in memory management code, not in ibmvscis? And looks
like there is a fix already?

Thanks.

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

Re: [PATCH V4 4/9] mtd: get the ECC info from the Extended Parameter Page

[Huang Shijie]

于 2013年05月03日 07:39, Brian Norris 写道:

only run the extended parameter page function after that point.
sorry, I prefer to run the extended parameter page function here just 
following the case
"p-> ecc_bits != 0xff". IMHO, the two cases should be put together as 
the onfi spec tells, rather be split out
far away. The extended parameter page function is just the case 
"p->ecc_bits == 0xff".


If we put the nand_flash_detect_ext_param_page() after the point we 
reassign the chip->cmdfunc,

It's a little discrete in logic which makes the code not compact enough.

btw: Could you check you email client? I failed several times for the 
HTML issue.


thanks
Huang Shijie


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