[PATCH v11 3/8] usb: phy: twl4030: use the new generic PHY framework

[Kishon Vijay Abraham I]

Used the generic PHY framework API to create the PHY. For powering on
and powering off the PHY, power_on and power_off ops are used. Once the
MUSB OMAP glue is adapted to the new framework, the suspend and resume
ops of usb phy library will be removed. Also twl4030-usb driver is moved
to drivers/phy/.

However using the old usb phy library cannot be completely removed
because otg is intertwined with phy and moving to the new
framework completely will break otg. Once we have a separate otg state machine,
we can get rid of the usb phy library.

Signed-off-by: Kishon Vijay Abraham I 
Acked-by: Felipe Balbi 
Reviewed-by: Sylwester Nawrocki 
---
 drivers/phy/Kconfig |   11 ++
 drivers/phy/Makefile|1 +
 drivers/{usb => }/phy/phy-twl4030-usb.c |   56 +--
 drivers/usb/phy/Kconfig |9 -
 drivers/usb/phy/Makefile|1 -
 include/linux/i2c/twl.h |2 ++
 6 files changed, 67 insertions(+), 13 deletions(-)
 rename drivers/{usb => }/phy/phy-twl4030-usb.c (95%)

diff --git a/drivers/phy/Kconfig b/drivers/phy/Kconfig
index 38c3477..ac239ac 100644
--- a/drivers/phy/Kconfig
+++ b/drivers/phy/Kconfig
@@ -27,4 +27,15 @@ config OMAP_USB2
  The USB OTG controller communicates with the comparator using this
  driver.
 
+config TWL4030_USB
+   tristate "TWL4030 USB Transceiver Driver"
+   depends on TWL4030_CORE && REGULATOR_TWL4030 && USB_MUSB_OMAP2PLUS
+   select GENERIC_PHY
+   select USB_PHY
+   help
+ Enable this to support the USB OTG transceiver on TWL4030
+ family chips (including the TWL5030 and TPS659x0 devices).
+ This transceiver supports high and full speed devices plus,
+ in host mode, low speed.
+
 endmenu
diff --git a/drivers/phy/Makefile b/drivers/phy/Makefile
index ed5b088..0dd8a98 100644
--- a/drivers/phy/Makefile
+++ b/drivers/phy/Makefile
@@ -4,3 +4,4 @@
 
 obj-$(CONFIG_GENERIC_PHY)  += phy-core.o
 obj-$(CONFIG_OMAP_USB2)+= phy-omap-usb2.o
+obj-$(CONFIG_TWL4030_USB)  += phy-twl4030-usb.o
diff --git a/drivers/usb/phy/phy-twl4030-usb.c b/drivers/phy/phy-twl4030-usb.c
similarity index 95%
rename from drivers/usb/phy/phy-twl4030-usb.c
rename to drivers/phy/phy-twl4030-usb.c
index 8f78d2d..494f107 100644
--- a/drivers/usb/phy/phy-twl4030-usb.c
+++ b/drivers/phy/phy-twl4030-usb.c
@@ -33,6 +33,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -431,6 +432,14 @@ static void twl4030_phy_suspend(struct twl4030_usb *twl, 
int controller_off)
dev_dbg(twl->dev, "%s\n", __func__);
 }
 
+static int twl4030_phy_power_off(struct phy *phy)
+{
+   struct twl4030_usb *twl = phy_get_drvdata(phy);
+
+   twl4030_phy_suspend(twl, 0);
+   return 0;
+}
+
 static void __twl4030_phy_resume(struct twl4030_usb *twl)
 {
twl4030_phy_power(twl, 1);
@@ -459,6 +468,14 @@ static void twl4030_phy_resume(struct twl4030_usb *twl)
}
 }
 
+static int twl4030_phy_power_on(struct phy *phy)
+{
+   struct twl4030_usb *twl = phy_get_drvdata(phy);
+
+   twl4030_phy_resume(twl);
+   return 0;
+}
+
 static int twl4030_usb_ldo_init(struct twl4030_usb *twl)
 {
/* Enable writing to power configuration registers */
@@ -602,13 +619,22 @@ static int twl4030_usb_phy_init(struct usb_phy *phy)
status = twl4030_usb_linkstat(twl);
twl->linkstat = status;
 
-   if (status == OMAP_MUSB_ID_GROUND || status == OMAP_MUSB_VBUS_VALID)
+   if (status == OMAP_MUSB_ID_GROUND || status == OMAP_MUSB_VBUS_VALID) {
omap_musb_mailbox(twl->linkstat);
+   twl4030_phy_resume(twl);
+   }
 
sysfs_notify(>dev->kobj, NULL, "vbus");
return 0;
 }
 
+static int twl4030_phy_init(struct phy *phy)
+{
+   struct twl4030_usb *twl = phy_get_drvdata(phy);
+
+   return twl4030_usb_phy_init(>phy);
+}
+
 static int twl4030_set_suspend(struct usb_phy *x, int suspend)
 {
struct twl4030_usb *twl = phy_to_twl(x);
@@ -646,13 +672,23 @@ static int twl4030_set_host(struct usb_otg *otg, struct 
usb_bus *host)
return 0;
 }
 
+static const struct phy_ops ops = {
+   .init   = twl4030_phy_init,
+   .power_on   = twl4030_phy_power_on,
+   .power_off  = twl4030_phy_power_off,
+   .owner  = THIS_MODULE,
+};
+
 static int twl4030_usb_probe(struct platform_device *pdev)
 {
struct twl4030_usb_data *pdata = pdev->dev.platform_data;
struct twl4030_usb  *twl;
+   struct phy  *phy;
int status, err;
struct usb_otg  *otg;
struct device_node  *np = pdev->dev.of_node;
+   struct phy_provider *phy_provider;
+   struct phy_init_data*init_data = NULL;
 
twl = devm_kzalloc(>dev, sizeof *twl, GFP_KERNEL);
if (!twl)
@@ -661,9 +697,10 @@ static int 

[PATCH v11 5/8] ARM: dts: omap: update usb_otg_hs data

[Kishon Vijay Abraham I]

Updated the usb_otg_hs dt data to include the *phy* and *phy-names*
binding in order for the driver to use the new generic PHY framework.
Also updated the Documentation to include the binding information.
The PHY binding information can be found at
Documentation/devicetree/bindings/phy/phy-bindings.txt

Signed-off-by: Kishon Vijay Abraham I 
Acked-by: Felipe Balbi 
Acked-by: Tony Lindgren 
Reviewed-by: Sylwester Nawrocki 
---
 Documentation/devicetree/bindings/usb/omap-usb.txt |5 +
 Documentation/devicetree/bindings/usb/usb-phy.txt  |6 ++
 arch/arm/boot/dts/omap3-beagle-xm.dts  |2 ++
 arch/arm/boot/dts/omap3-evm.dts|2 ++
 arch/arm/boot/dts/omap3-overo.dtsi |2 ++
 arch/arm/boot/dts/omap4.dtsi   |3 +++
 arch/arm/boot/dts/twl4030.dtsi |1 +
 7 files changed, 21 insertions(+)

diff --git a/Documentation/devicetree/bindings/usb/omap-usb.txt 
b/Documentation/devicetree/bindings/usb/omap-usb.txt
index 57e71f6..825790d 100644
--- a/Documentation/devicetree/bindings/usb/omap-usb.txt
+++ b/Documentation/devicetree/bindings/usb/omap-usb.txt
@@ -19,6 +19,9 @@ OMAP MUSB GLUE
  - power : Should be "50". This signifies the controller can supply up to
100mA when operating in host mode.
  - usb-phy : the phandle for the PHY device
+ - phys : the phandle for the PHY device (used by generic PHY framework)
+ - phy-names : the names of the PHY corresponding to the PHYs present in the
+   *phy* phandle.
 
 Optional properties:
  - ctrl-module : phandle of the control module this glue uses to write to
@@ -33,6 +36,8 @@ usb_otg_hs: usb_otg_hs@4a0ab000 {
num-eps = <16>;
ram-bits = <12>;
ctrl-module = <_control_usb>;
+   phys = <_phy>;
+   phy-names = "usb2-phy";
 };
 
 Board specific device node entry
diff --git a/Documentation/devicetree/bindings/usb/usb-phy.txt 
b/Documentation/devicetree/bindings/usb/usb-phy.txt
index 61496f5..c0245c8 100644
--- a/Documentation/devicetree/bindings/usb/usb-phy.txt
+++ b/Documentation/devicetree/bindings/usb/usb-phy.txt
@@ -5,6 +5,8 @@ OMAP USB2 PHY
 Required properties:
  - compatible: Should be "ti,omap-usb2"
  - reg : Address and length of the register set for the device.
+ - #phy-cells: determine the number of cells that should be given in the
+   phandle while referencing this phy.
 
 Optional properties:
  - ctrl-module : phandle of the control module used by PHY driver to power on
@@ -16,6 +18,7 @@ usb2phy@4a0ad080 {
compatible = "ti,omap-usb2";
reg = <0x4a0ad080 0x58>;
ctrl-module = <_control_usb>;
+   #phy-cells = <0>;
 };
 
 OMAP USB3 PHY
@@ -25,6 +28,8 @@ Required properties:
  - reg : Address and length of the register set for the device.
  - reg-names: The names of the register addresses corresponding to the 
registers
filled in "reg".
+ - #phy-cells: determine the number of cells that should be given in the
+   phandle while referencing this phy.
 
 Optional properties:
  - ctrl-module : phandle of the control module used by PHY driver to power on
@@ -39,4 +44,5 @@ usb3phy@4a084400 {
  <0x4a084c00 0x40>;
reg-names = "phy_rx", "phy_tx", "pll_ctrl";
ctrl-module = <_control_usb>;
+   #phy-cells = <0>;
 };
diff --git a/arch/arm/boot/dts/omap3-beagle-xm.dts 
b/arch/arm/boot/dts/omap3-beagle-xm.dts
index afdb164..533b2da 100644
--- a/arch/arm/boot/dts/omap3-beagle-xm.dts
+++ b/arch/arm/boot/dts/omap3-beagle-xm.dts
@@ -144,6 +144,8 @@
 _otg_hs {
interface-type = <0>;
usb-phy = <_phy>;
+   phys = <_phy>;
+   phy-names = "usb2-phy";
mode = <3>;
power = <50>;
 };
diff --git a/arch/arm/boot/dts/omap3-evm.dts b/arch/arm/boot/dts/omap3-evm.dts
index 7d4329d..4134dd0 100644
--- a/arch/arm/boot/dts/omap3-evm.dts
+++ b/arch/arm/boot/dts/omap3-evm.dts
@@ -70,6 +70,8 @@
 _otg_hs {
interface-type = <0>;
usb-phy = <_phy>;
+   phys = <_phy>;
+   phy-names = "usb2-phy";
mode = <3>;
power = <50>;
 };
diff --git a/arch/arm/boot/dts/omap3-overo.dtsi 
b/arch/arm/boot/dts/omap3-overo.dtsi
index 8f1abec..a461d2f 100644
--- a/arch/arm/boot/dts/omap3-overo.dtsi
+++ b/arch/arm/boot/dts/omap3-overo.dtsi
@@ -76,6 +76,8 @@
 _otg_hs {
interface-type = <0>;
usb-phy = <_phy>;
+   phys = <_phy>;
+   phy-names = "usb2-phy";
mode = <3>;
power = <50>;
 };
diff --git a/arch/arm/boot/dts/omap4.dtsi b/arch/arm/boot/dts/omap4.dtsi
index 22d9f2b..1e8e2fe 100644
--- a/arch/arm/boot/dts/omap4.dtsi
+++ b/arch/arm/boot/dts/omap4.dtsi
@@ -520,6 +520,7 @@
compatible = "ti,omap-usb2";
reg = <0x4a0ad080 0x58>;
ctrl-module = <_control_usb>;
+   #phy-cells = <0>;
};
};
 
@@ -658,6 +659,8 @@
interrupt-names = "mc", 

[PATCH v11 4/8] arm: omap3: twl: add phy consumer data in twl4030_usb_data

[Kishon Vijay Abraham I]

The PHY framework uses the phy consumer data populated in platform data in the
case of non-dt boot to return the reference to the PHY when the controller
(PHY consumer) requests for it. So populated the phy consumer data in the 
platform
data of twl usb.

Signed-off-by: Kishon Vijay Abraham I 
---
 arch/arm/mach-omap2/twl-common.c |   11 +++
 1 file changed, 11 insertions(+)

diff --git a/arch/arm/mach-omap2/twl-common.c b/arch/arm/mach-omap2/twl-common.c
index c05898f..b0d54da 100644
--- a/arch/arm/mach-omap2/twl-common.c
+++ b/arch/arm/mach-omap2/twl-common.c
@@ -24,6 +24,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 
@@ -90,8 +91,18 @@ void __init omap_pmic_late_init(void)
 }
 
 #if defined(CONFIG_ARCH_OMAP3)
+struct phy_consumer consumers[] = {
+   PHY_CONSUMER("musb-hdrc.0", "usb"),
+};
+
+struct phy_init_data init_data = {
+   .consumers = consumers,
+   .num_consumers = ARRAY_SIZE(consumers),
+};
+
 static struct twl4030_usb_data omap3_usb_pdata = {
.usb_mode   = T2_USB_MODE_ULPI,
+   .init_data  = _data,
 };
 
 static int omap3_batt_table[] = {
-- 
1.7.10.4

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

[PATCH v11 2/8] usb: phy: omap-usb2: use the new generic PHY framework

[Kishon Vijay Abraham I]

Used the generic PHY framework API to create the PHY. Now the power off and
power on are done in omap_usb_power_off and omap_usb_power_on respectively.
The omap-usb2 driver is also moved to driver/phy.

However using the old USB PHY library cannot be completely removed
because OTG is intertwined with PHY and moving to the new framework
will break OTG. Once we have a separate OTG state machine, we
can get rid of the USB PHY library.

Signed-off-by: Kishon Vijay Abraham I 
Reviewed-by: Sylwester Nawrocki 
Acked-by: Felipe Balbi 
---
 drivers/phy/Kconfig   |   12 +
 drivers/phy/Makefile  |1 +
 drivers/{usb => }/phy/phy-omap-usb2.c |   45 ++---
 drivers/usb/phy/Kconfig   |   10 
 drivers/usb/phy/Makefile  |1 -
 5 files changed, 54 insertions(+), 15 deletions(-)
 rename drivers/{usb => }/phy/phy-omap-usb2.c (88%)

diff --git a/drivers/phy/Kconfig b/drivers/phy/Kconfig
index 349bef2..38c3477 100644
--- a/drivers/phy/Kconfig
+++ b/drivers/phy/Kconfig
@@ -15,4 +15,16 @@ config GENERIC_PHY
  phy users can obtain reference to the PHY. All the users of this
  framework should select this config.
 
+config OMAP_USB2
+   tristate "OMAP USB2 PHY Driver"
+   depends on ARCH_OMAP2PLUS
+   select GENERIC_PHY
+   select USB_PHY
+   select OMAP_CONTROL_USB
+   help
+ Enable this to support the transceiver that is part of SOC. This
+ driver takes care of all the PHY functionality apart from comparator.
+ The USB OTG controller communicates with the comparator using this
+ driver.
+
 endmenu
diff --git a/drivers/phy/Makefile b/drivers/phy/Makefile
index 9e9560f..ed5b088 100644
--- a/drivers/phy/Makefile
+++ b/drivers/phy/Makefile
@@ -3,3 +3,4 @@
 #
 
 obj-$(CONFIG_GENERIC_PHY)  += phy-core.o
+obj-$(CONFIG_OMAP_USB2)+= phy-omap-usb2.o
diff --git a/drivers/usb/phy/phy-omap-usb2.c b/drivers/phy/phy-omap-usb2.c
similarity index 88%
rename from drivers/usb/phy/phy-omap-usb2.c
rename to drivers/phy/phy-omap-usb2.c
index 844ab68..25e0f3c 100644
--- a/drivers/usb/phy/phy-omap-usb2.c
+++ b/drivers/phy/phy-omap-usb2.c
@@ -28,6 +28,7 @@
 #include 
 #include 
 #include 
+#include 
 
 /**
  * omap_usb2_set_comparator - links the comparator present in the sytem with
@@ -119,10 +120,36 @@ static int omap_usb2_suspend(struct usb_phy *x, int 
suspend)
return 0;
 }
 
+static int omap_usb_power_off(struct phy *x)
+{
+   struct omap_usb *phy = phy_get_drvdata(x);
+
+   omap_control_usb_phy_power(phy->control_dev, 0);
+
+   return 0;
+}
+
+static int omap_usb_power_on(struct phy *x)
+{
+   struct omap_usb *phy = phy_get_drvdata(x);
+
+   omap_control_usb_phy_power(phy->control_dev, 1);
+
+   return 0;
+}
+
+static struct phy_ops ops = {
+   .power_on   = omap_usb_power_on,
+   .power_off  = omap_usb_power_off,
+   .owner  = THIS_MODULE,
+};
+
 static int omap_usb2_probe(struct platform_device *pdev)
 {
struct omap_usb *phy;
+   struct phy  *generic_phy;
struct usb_otg  *otg;
+   struct phy_provider *phy_provider;
 
phy = devm_kzalloc(>dev, sizeof(*phy), GFP_KERNEL);
if (!phy) {
@@ -144,6 +171,11 @@ static int omap_usb2_probe(struct platform_device *pdev)
phy->phy.otg= otg;
phy->phy.type   = USB_PHY_TYPE_USB2;
 
+   phy_provider = devm_of_phy_provider_register(phy->dev,
+   of_phy_simple_xlate);
+   if (IS_ERR(phy_provider))
+   return PTR_ERR(phy_provider);
+
phy->control_dev = omap_get_control_dev();
if (IS_ERR(phy->control_dev)) {
dev_dbg(>dev, "Failed to get control device\n");
@@ -159,6 +191,15 @@ static int omap_usb2_probe(struct platform_device *pdev)
otg->start_srp  = omap_usb_start_srp;
otg->phy= >phy;
 
+   platform_set_drvdata(pdev, phy);
+   pm_runtime_enable(phy->dev);
+
+   generic_phy = devm_phy_create(phy->dev, , NULL);
+   if (IS_ERR(generic_phy))
+   return PTR_ERR(generic_phy);
+
+   phy_set_drvdata(generic_phy, phy);
+
phy->wkupclk = devm_clk_get(phy->dev, "usb_phy_cm_clk32k");
if (IS_ERR(phy->wkupclk)) {
dev_err(>dev, "unable to get usb_phy_cm_clk32k\n");
@@ -174,10 +215,6 @@ static int omap_usb2_probe(struct platform_device *pdev)
 
usb_add_phy_dev(>phy);
 
-   platform_set_drvdata(pdev, phy);
-
-   pm_runtime_enable(phy->dev);
-
return 0;
 }
 
diff --git a/drivers/usb/phy/Kconfig b/drivers/usb/phy/Kconfig
index 3622fff..7813238 100644
--- a/drivers/usb/phy/Kconfig
+++ b/drivers/usb/phy/Kconfig
@@ -72,16 +72,6 @@ config OMAP_CONTROL_USB
  power on the USB2 PHY is present in OMAP4 and OMAP5. OMAP5 has an
  additional 

Re: [PATCH 0/3] mm: shmem: check the return value of mpol_to_str()

[Chen Gang]

On 08/21/2013 01:31 PM, Cyrill Gorcunov wrote:
> On Wed, Aug 21, 2013 at 10:21:22AM +0800, Chen Gang wrote:
>> mpol_to_str() may fail, and not fill the buffer (e.g. -EINVAL), so need
>> check about it, or buffer may not be zero based, and next seq_printf()
>> will cause issue.
>>
>> Signed-off-by: Chen Gang 
>> Cc: Cyrill Gorcunov 
> 
> Looks good to me, thanks!
> 
> Reviewed-by: Cyrill Gorcunov 
> 

Thanks.

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


-- 
Chen Gang
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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 v11 7/8] usb: phy: omap-usb2: remove *set_suspend* callback from omap-usb2

[Kishon Vijay Abraham I]

Now that omap-usb2 is adapted to the new generic PHY framework,
*set_suspend* ops can be removed from omap-usb2 driver.

Signed-off-by: Kishon Vijay Abraham I 
Acked-by: Felipe Balbi 
Reviewed-by: Sylwester Nawrocki 
---
 drivers/phy/phy-omap-usb2.c |   25 -
 1 file changed, 25 deletions(-)

diff --git a/drivers/phy/phy-omap-usb2.c b/drivers/phy/phy-omap-usb2.c
index 25e0f3c..dec3fab 100644
--- a/drivers/phy/phy-omap-usb2.c
+++ b/drivers/phy/phy-omap-usb2.c
@@ -97,29 +97,6 @@ static int omap_usb_set_peripheral(struct usb_otg *otg,
return 0;
 }
 
-static int omap_usb2_suspend(struct usb_phy *x, int suspend)
-{
-   u32 ret;
-   struct omap_usb *phy = phy_to_omapusb(x);
-
-   if (suspend && !phy->is_suspended) {
-   omap_control_usb_phy_power(phy->control_dev, 0);
-   pm_runtime_put_sync(phy->dev);
-   phy->is_suspended = 1;
-   } else if (!suspend && phy->is_suspended) {
-   ret = pm_runtime_get_sync(phy->dev);
-   if (ret < 0) {
-   dev_err(phy->dev, "get_sync failed with err %d\n",
-   ret);
-   return ret;
-   }
-   omap_control_usb_phy_power(phy->control_dev, 1);
-   phy->is_suspended = 0;
-   }
-
-   return 0;
-}
-
 static int omap_usb_power_off(struct phy *x)
 {
struct omap_usb *phy = phy_get_drvdata(x);
@@ -167,7 +144,6 @@ static int omap_usb2_probe(struct platform_device *pdev)
 
phy->phy.dev= phy->dev;
phy->phy.label  = "omap-usb2";
-   phy->phy.set_suspend= omap_usb2_suspend;
phy->phy.otg= otg;
phy->phy.type   = USB_PHY_TYPE_USB2;
 
@@ -182,7 +158,6 @@ static int omap_usb2_probe(struct platform_device *pdev)
return -ENODEV;
}
 
-   phy->is_suspended   = 1;
omap_control_usb_phy_power(phy->control_dev, 0);
 
otg->set_host   = omap_usb_set_host;
-- 
1.7.10.4

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

[PATCH v11 1/8] drivers: phy: add generic PHY framework

[Kishon Vijay Abraham I]

The PHY framework provides a set of APIs for the PHY drivers to
create/destroy a PHY and APIs for the PHY users to obtain a reference to the
PHY with or without using phandle. For dt-boot, the PHY drivers should
also register *PHY provider* with the framework.

PHY drivers should create the PHY by passing id and ops like init, exit,
power_on and power_off. This framework is also pm runtime enabled.

The documentation for the generic PHY framework is added in
Documentation/phy.txt and the documentation for dt binding can be found at
Documentation/devicetree/bindings/phy/phy-bindings.txt

Cc: Tomasz Figa 
Cc: Greg Kroah-Hartman 
Signed-off-by: Kishon Vijay Abraham I 
Acked-by: Felipe Balbi 
Tested-by: Sylwester Nawrocki 
---
 .../devicetree/bindings/phy/phy-bindings.txt   |   66 ++
 Documentation/phy.txt  |  166 +
 MAINTAINERS|8 +
 drivers/Kconfig|2 +
 drivers/Makefile   |2 +
 drivers/phy/Kconfig|   18 +
 drivers/phy/Makefile   |5 +
 drivers/phy/phy-core.c |  698 
 include/linux/phy/phy.h|  270 
 9 files changed, 1235 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/phy/phy-bindings.txt
 create mode 100644 Documentation/phy.txt
 create mode 100644 drivers/phy/Kconfig
 create mode 100644 drivers/phy/Makefile
 create mode 100644 drivers/phy/phy-core.c
 create mode 100644 include/linux/phy/phy.h

diff --git a/Documentation/devicetree/bindings/phy/phy-bindings.txt 
b/Documentation/devicetree/bindings/phy/phy-bindings.txt
new file mode 100644
index 000..8ae844f
--- /dev/null
+++ b/Documentation/devicetree/bindings/phy/phy-bindings.txt
@@ -0,0 +1,66 @@
+This document explains only the device tree data binding. For general
+information about PHY subsystem refer to Documentation/phy.txt
+
+PHY device node
+===
+
+Required Properties:
+#phy-cells:Number of cells in a PHY specifier;  The meaning of all those
+   cells is defined by the binding for the phy node. The PHY
+   provider can use the values in cells to find the appropriate
+   PHY.
+
+For example:
+
+phys: phy {
+compatible = "xxx";
+reg = <...>;
+.
+.
+#phy-cells = <1>;
+.
+.
+};
+
+That node describes an IP block (PHY provider) that implements 2 different 
PHYs.
+In order to differentiate between these 2 PHYs, an additonal specifier should 
be
+given while trying to get a reference to it.
+
+PHY user node
+=
+
+Required Properties:
+phys : the phandle for the PHY device (used by the PHY subsystem)
+phy-names : the names of the PHY corresponding to the PHYs present in the
+   *phys* phandle
+
+Example 1:
+usb1: usb_otg_ss@xxx {
+compatible = "xxx";
+reg = ;
+.
+.
+phys = <_phy>, <_phy>;
+phy-names = "usb2phy", "usb3phy";
+.
+.
+};
+
+This node represents a controller that uses two PHYs, one for usb2 and one for
+usb3.
+
+Example 2:
+usb2: usb_otg_ss@xxx {
+compatible = "xxx";
+reg = ;
+.
+.
+phys = < 1>;
+phy-names = "usbphy";
+.
+.
+};
+
+This node represents a controller that uses one of the PHYs of the PHY provider
+device defined previously. Note that the phy handle has an additional specifier
+"1" to differentiate between the two PHYs.
diff --git a/Documentation/phy.txt b/Documentation/phy.txt
new file mode 100644
index 000..0103e4b
--- /dev/null
+++ b/Documentation/phy.txt
@@ -0,0 +1,166 @@
+   PHY SUBSYSTEM
+ Kishon Vijay Abraham I 
+
+This document explains the Generic PHY Framework along with the APIs provided,
+and how-to-use.
+
+1. Introduction
+
+*PHY* is the abbreviation for physical layer. It is used to connect a device
+to the physical medium e.g., the USB controller has a PHY to provide functions
+such as serialization, de-serialization, encoding, decoding and is responsible
+for obtaining the required data transmission rate. Note that some USB
+controllers have PHY functionality embedded into it and others use an external
+PHY. Other peripherals that use PHY include Wireless LAN, Ethernet,
+SATA etc.
+
+The intention of creating this framework is to bring the PHY drivers spread
+all over the Linux kernel to drivers/phy to increase code re-use and for
+better code maintainability.
+
+This framework will be of use only to devices that use external PHY (PHY
+functionality is not embedded within the controller).
+
+2. Registering/Unregistering the PHY provider
+
+PHY provider refers to an entity that implements one or more PHY instances.
+For the simple case where the PHY provider implements only a single instance of
+the PHY, the framework provides its own implementation of of_xlate in
+of_phy_simple_xlate. If the PHY 

[PATCH v11 6/8] usb: musb: omap2430: use the new generic PHY framework

[Kishon Vijay Abraham I]

Use the generic PHY framework API to get the PHY. The usb_phy_set_resume
and usb_phy_set_suspend is replaced with power_on and
power_off to align with the new PHY framework.

musb->xceiv can't be removed as of now because musb core uses xceiv.state and
xceiv.otg. Once there is a separate state machine to handle otg, these can be
moved out of xceiv and then we can start using the generic PHY framework.

Signed-off-by: Kishon Vijay Abraham I 
Reviewed-by: Sylwester Nawrocki 
Acked-by: Felipe Balbi 
---
 drivers/usb/musb/Kconfig |1 +
 drivers/usb/musb/musb_core.h |2 ++
 drivers/usb/musb/omap2430.c  |   26 --
 3 files changed, 23 insertions(+), 6 deletions(-)

diff --git a/drivers/usb/musb/Kconfig b/drivers/usb/musb/Kconfig
index 797e3fd..25e2e57 100644
--- a/drivers/usb/musb/Kconfig
+++ b/drivers/usb/musb/Kconfig
@@ -76,6 +76,7 @@ config USB_MUSB_TUSB6010
 config USB_MUSB_OMAP2PLUS
tristate "OMAP2430 and onwards"
depends on ARCH_OMAP2PLUS
+   select GENERIC_PHY
 
 config USB_MUSB_AM35X
tristate "AM35x"
diff --git a/drivers/usb/musb/musb_core.h b/drivers/usb/musb/musb_core.h
index 7d341c3..6e567bd 100644
--- a/drivers/usb/musb/musb_core.h
+++ b/drivers/usb/musb/musb_core.h
@@ -46,6 +46,7 @@
 #include 
 #include 
 #include 
+#include 
 
 struct musb;
 struct musb_hw_ep;
@@ -346,6 +347,7 @@ struct musb {
u16 int_tx;
 
struct usb_phy  *xceiv;
+   struct phy  *phy;
 
int nIrq;
unsignedirq_wake:1;
diff --git a/drivers/usb/musb/omap2430.c b/drivers/usb/musb/omap2430.c
index f44e8b5..063773a 100644
--- a/drivers/usb/musb/omap2430.c
+++ b/drivers/usb/musb/omap2430.c
@@ -348,11 +348,21 @@ static int omap2430_musb_init(struct musb *musb)
 * up through ULPI.  TWL4030-family PMICs include one,
 * which needs a driver, drivers aren't always needed.
 */
-   if (dev->parent->of_node)
+   if (dev->parent->of_node) {
+   musb->phy = devm_phy_get(dev->parent, "usb2-phy");
+
+   /* We can't totally remove musb->xceiv as of now because
+* musb core uses xceiv.state and xceiv.otg. Once we have
+* a separate state machine to handle otg, these can be moved
+* out of xceiv and then we can start using the generic PHY
+* framework
+*/
musb->xceiv = devm_usb_get_phy_by_phandle(dev->parent,
"usb-phy", 0);
-   else
+   } else {
musb->xceiv = devm_usb_get_phy_dev(dev, 0);
+   musb->phy = devm_phy_get(dev, "usb");
+   }
 
if (IS_ERR(musb->xceiv)) {
status = PTR_ERR(musb->xceiv);
@@ -364,6 +374,10 @@ static int omap2430_musb_init(struct musb *musb)
return -EPROBE_DEFER;
}
 
+   if (IS_ERR(musb->phy)) {
+   pr_err("HS USB OTG: no PHY configured\n");
+   return PTR_ERR(musb->phy);
+   }
musb->isr = omap2430_musb_interrupt;
 
status = pm_runtime_get_sync(dev);
@@ -397,7 +411,7 @@ static int omap2430_musb_init(struct musb *musb)
if (glue->status != OMAP_MUSB_UNKNOWN)
omap_musb_set_mailbox(glue);
 
-   usb_phy_init(musb->xceiv);
+   phy_init(musb->phy);
 
pm_runtime_put_noidle(musb->controller);
return 0;
@@ -460,6 +474,7 @@ static int omap2430_musb_exit(struct musb *musb)
del_timer_sync(_idle_timer);
 
omap2430_low_level_exit(musb);
+   phy_exit(musb->phy);
 
return 0;
 }
@@ -638,7 +653,7 @@ static int omap2430_runtime_suspend(struct device *dev)
OTG_INTERFSEL);
 
omap2430_low_level_exit(musb);
-   usb_phy_set_suspend(musb->xceiv, 1);
+   phy_power_off(musb->phy);
}
 
return 0;
@@ -653,8 +668,7 @@ static int omap2430_runtime_resume(struct device *dev)
omap2430_low_level_init(musb);
musb_writel(musb->mregs, OTG_INTERFSEL,
musb->context.otg_interfsel);
-
-   usb_phy_set_suspend(musb->xceiv, 0);
+   phy_power_on(musb->phy);
}
 
return 0;
-- 
1.7.10.4

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

[PATCH v11 8/8] usb: phy: twl4030-usb: remove *set_suspend* and *phy_init* ops

[Kishon Vijay Abraham I]

Now that twl4030-usb is adapted to the new generic PHY framework,
*set_suspend* and *phy_init* ops can be removed from twl4030-usb driver.

Signed-off-by: Kishon Vijay Abraham I 
Acked-by: Felipe Balbi 
Reviewed-by: Sylwester Nawrocki 
---
 drivers/phy/phy-twl4030-usb.c |   57 ++---
 1 file changed, 13 insertions(+), 44 deletions(-)

diff --git a/drivers/phy/phy-twl4030-usb.c b/drivers/phy/phy-twl4030-usb.c
index 494f107..c437211 100644
--- a/drivers/phy/phy-twl4030-usb.c
+++ b/drivers/phy/phy-twl4030-usb.c
@@ -422,25 +422,20 @@ static void twl4030_phy_power(struct twl4030_usb *twl, 
int on)
}
 }
 
-static void twl4030_phy_suspend(struct twl4030_usb *twl, int controller_off)
+static int twl4030_phy_power_off(struct phy *phy)
 {
+   struct twl4030_usb *twl = phy_get_drvdata(phy);
+
if (twl->asleep)
-   return;
+   return 0;
 
twl4030_phy_power(twl, 0);
twl->asleep = 1;
dev_dbg(twl->dev, "%s\n", __func__);
-}
-
-static int twl4030_phy_power_off(struct phy *phy)
-{
-   struct twl4030_usb *twl = phy_get_drvdata(phy);
-
-   twl4030_phy_suspend(twl, 0);
return 0;
 }
 
-static void __twl4030_phy_resume(struct twl4030_usb *twl)
+static void __twl4030_phy_power_on(struct twl4030_usb *twl)
 {
twl4030_phy_power(twl, 1);
twl4030_i2c_access(twl, 1);
@@ -449,11 +444,13 @@ static void __twl4030_phy_resume(struct twl4030_usb *twl)
twl4030_i2c_access(twl, 0);
 }
 
-static void twl4030_phy_resume(struct twl4030_usb *twl)
+static int twl4030_phy_power_on(struct phy *phy)
 {
+   struct twl4030_usb *twl = phy_get_drvdata(phy);
+
if (!twl->asleep)
-   return;
-   __twl4030_phy_resume(twl);
+   return 0;
+   __twl4030_phy_power_on(twl);
twl->asleep = 0;
dev_dbg(twl->dev, "%s\n", __func__);
 
@@ -466,13 +463,6 @@ static void twl4030_phy_resume(struct twl4030_usb *twl)
cancel_delayed_work(>id_workaround_work);
schedule_delayed_work(>id_workaround_work, HZ);
}
-}
-
-static int twl4030_phy_power_on(struct phy *phy)
-{
-   struct twl4030_usb *twl = phy_get_drvdata(phy);
-
-   twl4030_phy_resume(twl);
return 0;
 }
 
@@ -604,9 +594,9 @@ static void twl4030_id_workaround_work(struct work_struct 
*work)
}
 }
 
-static int twl4030_usb_phy_init(struct usb_phy *phy)
+static int twl4030_phy_init(struct phy *phy)
 {
-   struct twl4030_usb *twl = phy_to_twl(phy);
+   struct twl4030_usb *twl = phy_get_drvdata(phy);
enum omap_musb_vbus_id_status status;
 
/*
@@ -621,32 +611,13 @@ static int twl4030_usb_phy_init(struct usb_phy *phy)
 
if (status == OMAP_MUSB_ID_GROUND || status == OMAP_MUSB_VBUS_VALID) {
omap_musb_mailbox(twl->linkstat);
-   twl4030_phy_resume(twl);
+   twl4030_phy_power_on(phy);
}
 
sysfs_notify(>dev->kobj, NULL, "vbus");
return 0;
 }
 
-static int twl4030_phy_init(struct phy *phy)
-{
-   struct twl4030_usb *twl = phy_get_drvdata(phy);
-
-   return twl4030_usb_phy_init(>phy);
-}
-
-static int twl4030_set_suspend(struct usb_phy *x, int suspend)
-{
-   struct twl4030_usb *twl = phy_to_twl(x);
-
-   if (suspend)
-   twl4030_phy_suspend(twl, 1);
-   else
-   twl4030_phy_resume(twl);
-
-   return 0;
-}
-
 static int twl4030_set_peripheral(struct usb_otg *otg,
struct usb_gadget *gadget)
 {
@@ -719,8 +690,6 @@ static int twl4030_usb_probe(struct platform_device *pdev)
twl->phy.label  = "twl4030";
twl->phy.otg= otg;
twl->phy.type   = USB_PHY_TYPE_USB2;
-   twl->phy.set_suspend= twl4030_set_suspend;
-   twl->phy.init   = twl4030_usb_phy_init;
 
otg->phy= >phy;
otg->set_host   = twl4030_set_host;
-- 
1.7.10.4

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

[PATCH v11 0/8] PHY framework

[Kishon Vijay Abraham I]

Added a generic PHY framework that provides a set of APIs for the PHY drivers
to create/destroy a PHY and APIs for the PHY users to obtain a reference to
the PHY with or without using phandle.

This framework will be of use only to devices that uses external PHY (PHY
functionality is not embedded within the controller).

The intention of creating this framework is to bring the phy drivers spread
all over the Linux kernel to drivers/phy to increase code re-use and to
increase code maintainability.

Comments to make PHY as bus wasn't done because PHY devices can be part of
other bus and making a same device attached to multiple bus leads to bad
design.

If the PHY driver has to send notification on connect/disconnect, the PHY
driver should make use of the extcon framework. Using this susbsystem
to use extcon framwork will have to be analysed.

You can find this patch series @
git://git.kernel.org/pub/scm/linux/kernel/git/kishon/linux-phy.git testing

I'll create a new branch *next* once this patch series is finalized. All the
PHY driver development that depends on PHY framework can be based on this
branch.

Did USB enumeration testing in panda and beagle after applying [1]

[1] -> https://lkml.org/lkml/2013/7/26/88

Changes from v10:
* fixed a mistake in devm_of_phy_provider_register macro which was carried over 
from earlier version.
* used ida_simple_get for obtaining the id.

Changes from v9:
* Fixed Greg's concern on having *find PHY by string* and changed it to Tomasz
  pseudo code.
* move omap-usb2 phy and twl4030-usb phy to drivers/phy
* made all the dependent drivers select GENERIC_PHY instead of having depends
  on
* Made PHY core to assign the id's (so changed the phy_create API).
* Adapted twl4030-usb to the new design.

Changes from v8:
* Added phy_set_drvdata and phy_get_drvdata in phy.h.
* Changed phy_create API not to take void *priv. private data should now be set
  using phy_set_drvdata now.
Changes from v7:
* Fixed Documentation
* Added to_phy, of_phy_provider_register and devm_of_phy_provider_register
* modified runtime_pm usage in phy_init, phy_exit, phy_power_on and
  phy_power_off. Now phy_power_on will enable the clocks and phy_power_off will
  disable the clocks.
* pm_runtime_no_callbacks() is added so that pm_runtime_get_sync doesn't fail
* modified other patches to adhere to the changes in the PHY framework
* removed usb: phy: twl4030: twl4030 shouldn't be subsys_initcall as it will
  be merged separately.
* reference counting has been added to protect phy ops when the PHY is shared
  by multiple consumers.

Changes from v6
* corrected few typos in Documentation
* Changed PHY Subsystem to *bool* in Kconfig (to avoid compilation errors when
  PHY Subsystem is kept as module and the dependent modules are built-in)
* Added if pm_runtime_enabled check before runtime pm calls.

Changes from v5:
* removed the new sysfs entries as it dint have any new information other than
  what is already there in /sys/devices/...
* removed a bunch of APIs added to get the PHY and now only phy_get and
  devm_phy_get are used.
* Added new APIs to register/unregister the PHY provider. This is needed for
  dt boot case.
* Enabled pm runtime and incorporated the comments given by Alan Stern in a
  different patch series by Gautam.
* Removed the *phy_bind* API. Now the phy binding information should be passed
  using the platform data to the controller devices.
* Fixed a few typos.

Changes from v4:
* removed of_phy_get_with_args/devm_of_phy_get_with_args. Now the *phy 
providers*
  should use their custom implementation of of_xlate or use of_phy_xlate to get
  *phy instance* from *phy providers*.
* Added of_phy_xlate to be used by *phy providers* if it provides only one PHY.
* changed phy_core from having subsys_initcall to module_init.
* other minor fixes.

Changes from v3:
* Changed the return value of PHY APIs to ENOSYS
* Added APIs of_phy_get_with_args/devm_of_phy_get_with_args to support getting
  PHYs if the same IP implements multiple PHYs.
* modified phy_bind API so that the binding information can now be _updated_.
  In effect of this removed the binding information added in board files and
  added only in usb-musb.c. If a particular board uses a different phy binding,
  it can update it in board file after usb_musb_init().
* Added Documentation/devicetree/bindings/phy/phy-bindings.txt for dt binding
  information.

Changes from v2:
* removed phy_descriptor structure completely so changed the APIs which were
  taking phy_descriptor as parameters
* Added 2 more APIs *of_phy_get_byname* and *devm_of_phy_get_byname* to be used
  by PHY user drivers which has *phy* and *phy-names* binding in the dt data
* Fixed a few typos
* Removed phy_list and we now use class_dev_iter_init, class_dev_iter_next and
  class_dev_iter_exit for traversing through the phy list. (Note we still need
  phy_bind list and phy_bind_mutex).
* Changed the sysfs entry name from *bind* to *phy_bind*.

Changes from v1:
* Added 

Re: [PATCH 0/9] [RFC v2] safely drop directory dentry on failed revalidate

[Al Viro]

On Thu, Aug 08, 2013 at 05:24:41PM +0200, Miklos Szeredi wrote:
> Here's a series for fixing issues with d_drop on a directory dentry with
> children and adding support for such dropped directories in fuse.
> 
> This one fixes a couple of issues I found with the previous incarnation and
> split out the filesystem parts into individual patches.

OK in general, but I'm not happy with the proliferation of such iterators in
fs/dcache.c ;-/  

We have have_submounts(), select_parent() and d_genocide(), with one more
such sucker added to the pile.  Sure, most of the callers of have_submounts()
are gone after that patchset, but we still have several left:
fs/autofs4/dev-ioctl.c:542: err = have_submounts(path.dentry);
fs/autofs4/root.c:381:  if (have_submounts(dentry)) {
fs/autofs4/waitq.c:338: if (have_submounts(dentry))
fs/nilfs2/super.c:1010: if (have_submounts(root_dentry))

The thing is, the same race with mount() does, AFAICS, apply at least to
autofs4 call sites.

And I would like to understand what nilfs one is trying to do...
Unless I'm seriously misreading that code, it's *not* on any kind of a hot
path, so I really wonder why don't we simply do shrink_dcache_parent() +
check if d_count has dropped to 1, without trying to look for submounts
first - if we have any, shrink_dcache_parent() is simply going to leave
us with d_count > 1 and that's it.  Actually, it's cheaper that way -
no need to walk the tree twice.  Moreover, checking for d_count == 1
case first is also pointless - in that case we have no children at all
and shrink_dcache_parent() will return immediately.  Could nilfs folks
explain why (and if) we need to bother with all that complexity there?

We are really getting too many tree walkers in fs/dcache.c and
all that duplication is the prime breeding ground for bugs ;-/
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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: Proposed stable release changes

[Willy Tarreau]

On Tue, Aug 20, 2013 at 05:49:24PM -0700, Greg KH wrote:
> On Tue, Aug 20, 2013 at 08:41:23PM -0400, Josh Boyer wrote:
> > On Tue, Aug 20, 2013 at 7:57 PM, Greg KH  wrote:
> > >> I like this overall.  The only thing I might change is "wait for -rc2"
> > >> for patches tagged with CC: stable that go in during the merge window.
> > >>  It seems those are the ones that tend to bite us.
> > >
> > > Maintainers can always tag their patches to have me hold off until -rc2
> > > for that.
> > 
> > They can (not immediately sure how though?)
> 
> Some do:
>   Cc: stable  # after -rc5 is out
> or
>   Cc: stable  # wait a -rc cycle
> or
>   Cc: stable  # wait a few weeks to bake

That's where I think that the default one (with no indication) should
be the higher delay. If the author has no clue about the emergency of
his patch, who else can guess for him ?

It's too optimistic to consider that some code authors will be
realist about the impacts of their code. We all create bugs and
regressions everywhere because we're sure about what we do, until
someone says "hey dude you broke this". So if we expect authors to
say "look, I managed to get this merged into mainline but I'm still
not sure about the risks", I suspect only a small fraction of the
patches will be tagged this way. But I may be wrong, after all it
already works well with -net.

Willy

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

Re: [PATCH V8 00/33] loop: Issue O_DIRECT aio using bio_vec

[Sedat Dilek]

On Wed, Aug 21, 2013 at 2:14 AM, Stephen Rothwell  wrote:
> Hi Dave,
>
> On Tue, 20 Aug 2013 14:13:15 -0500 Dave Kleikamp  
> wrote:
>>
>> Would you be willing to pick up
>> git://github.com/kleikamp/linux-shaggy.git for-next
>> into linux-next?
>
> I have added that from today.
>
>> There will be some unclean merges, and I can send you updated patches
>> created against your latest tree. I'm not exactly sure of your process
>> wrt cleaning up merges, but I guess they would help.
>
> Since I will merge your tree into linux-next, I only need to fix merge
> conflicts, so while those patches can be a guide, they are mostly not
> needed.
>
>> On 08/20/2013 08:00 AM, Christoph Hellwig wrote:
>> > As I've seen very few replies to this:  how do we ensure this gets
>> > picked up for the 3.12 merge window?  The series has been a reposted
>> > a few times without complaints or major changes, but the ball still
>> > doesn't seem to get rolling.
>> >
>> > I'd really like to do some ecryptfs and scsi target work that is going
>> > to rely on this soon.
>
> If this happens, then it is important that your (Dave's) tree is not
> rebased/rewritten and that any other tree that depend on it merges your
> tree.
>
> I will merge your tree relatively early, that way the merge conflicts will
> be spread over several other merges and hopefully each be fairly minor.
>
> I gave called your tree "aio-direct", please let me know fi you think
> there is a better name.
>

Cool, to see Dave's work in Linux-next!

Dave named his GIT branch "aio_loop".
( If you (Stephen) prefer "hyphen" for your GIT branches, use
"aio-loop", but that's up to the Dave. )

Anyway, I am glad to see this getting pushed.

( Hmmm, OverlayFS
..).

- Sedat -

[1] https://github.com/kleikamp/linux-shaggy/tree/aio_loop

> Thanks for adding your subsystem tree as a participant of linux-next.  As
> you may know, this is not a judgment of your code.  The purpose of
> linux-next is for integration testing and to lower the impact of
> conflicts between subsystems in the next merge window.
>
> You will need to ensure that the patches/commits in your tree/series have
> been:
>  * submitted under GPL v2 (or later) and include the Contributor's
> Signed-off-by,
>  * posted to the relevant mailing list,
>  * reviewed by you (or another maintainer of your subsystem tree),
>  * successfully unit tested, and
>  * destined for the current or next Linux merge window.
>
> Basically, this should be just what you would send to Linus (or ask him
> to fetch).  It is allowed to be rebased if you deem it necessary.
>
> --
> Cheers,
> Stephen Rothwell
> s...@canb.auug.org.au
>
> Legal Stuff:
> By participating in linux-next, your subsystem tree contributions are
> public and will be included in the linux-next trees.  You may be sent
> e-mail messages indicating errors or other issues when the
> patches/commits from your subsystem tree are merged and tested in
> linux-next.  These messages may also be cross-posted to the linux-next
> mailing list, the linux-kernel mailing list, etc.  The linux-next tree
> project and IBM (my employer) make no warranties regarding the linux-next
> project, the testing procedures, the results, the e-mails, etc.  If you
> don't agree to these ground rules, let me know and I'll remove your tree
> from participation in linux-next.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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 0/3] mm: shmem: check the return value of mpol_to_str()

[Cyrill Gorcunov]

On Wed, Aug 21, 2013 at 10:21:22AM +0800, Chen Gang wrote:
> mpol_to_str() may fail, and not fill the buffer (e.g. -EINVAL), so need
> check about it, or buffer may not be zero based, and next seq_printf()
> will cause issue.
> 
> Signed-off-by: Chen Gang 
> Cc: Cyrill Gorcunov 

Looks good to me, thanks!

Reviewed-by: Cyrill Gorcunov 
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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: Proposed stable release changes

[Willy Tarreau]

On Tue, Aug 20, 2013 at 04:12:32PM -0700, Greg KH wrote:
> On Wed, Aug 21, 2013 at 12:58:15AM +0200, Willy Tarreau wrote:
> > Hi Greg,
> > 
> > On Tue, Aug 20, 2013 at 03:40:32PM -0700, Greg KH wrote:
> > > Hi all,
> > > 
> > > Given that I had to just revert a patch in the recent stable releases
> > > that didn't get enough time to "bake" in Linus's tree (or in -next), I
> > > figured it was worth discussing some possible changes with how "fast" I
> > > pick up patches for stable releases.
> > > 
> > > So, how about this proposal:
> > > 
> > > - I will wait for a -rc to come out with the patch in it before putting
> > >   it into a stable release, unless:
> > >   - the maintainer ACKs it, or sends it directly (like DaveM does
> > > for networking patches)
> > >   - I have seen enough discussion about a patch to show that it
> > > really does fix something / is good / doesn't cause problems.
> > >   - obviously safe, i.e. "add a device id" type thing.
> > > 
> > > Given that we have -rc releases every week, except for the initial -rc1
> > > release, I don't think this will really cause any major delays.
> > 
> > In the last discussion you initiated on the subject, I proposed something
> > even more conservative which was the same as above except instead of
> > "wait for a -rc", it was "wait for rc1 after a full release containing
> > the patch", unless one of the conditions you proposed, or another one
> > which would be a tag "urgent" or something like this in the patch.
> 
> Waiting 3 months is too long, in my opinion, sorry.

I meant only for the non-important ones. Their authors will qualify the
ones that are important and must not wait. The same way as now many patches
are correctly tagged "cc: stable", I suspect that we could end up with maybe
80% of patches tagged as "must not wait", and the remaining 20% would indeed
wait up to 3 months, but if their authors think they should wait maybe we
should trust them.

Willy

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

[PATCH v8 1/1] input: ideapad_slidebar: new input driver

[Andrey Moiseev]

v8: added `extended = false;` line

ideapad_slidebar is a new driver which enables slidebars on some
Lenovo IdeaPad laptops (the slidebars work with SlideNav/Desktop
Navigator under Windows)

Fixes this: https://bugzilla.kernel.org/show_bug.cgi?id=16004

Registers 'IdeaPad Slidebar' input device and
/sys/devices/platform/ideapad_slidebar/slidebar_mode
for switching slidebar's modes.

Now works on:
IdeaPad Y550, Y550P.

May work on (testing and adding new models is needed):
Ideapad Y560, Y460, Y450, Y650,
and, probably, some others.

Driver source: https://github.com/o2genum/ideapad-slidebar.git

Patch is generated against current mainline kernel.

Signed-off-by: Andrey Moiseev 
---
 MAINTAINERS   |   7 +
 drivers/input/misc/Kconfig|   9 +
 drivers/input/misc/Makefile   |   1 +
 drivers/input/misc/ideapad_slidebar.c | 332 ++
 4 files changed, 349 insertions(+)
 create mode 100644 drivers/input/misc/ideapad_slidebar.c

diff --git a/MAINTAINERS b/MAINTAINERS
index defc053..2ff3dd8 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -4096,6 +4096,13 @@ W:   http://launchpad.net/ideapad-laptop
 S: Maintained
 F: drivers/platform/x86/ideapad-laptop.c
 
+IDEAPAD LAPTOP SLIDEBAR DRIVER
+M: Andrey Moiseev 
+L: linux-in...@vger.kernel.org
+W: https://github.com/o2genum/ideapad-slidebar
+S: Maintained
+F: drivers/input/misc/ideapad_slidebar.c
+
 IDE/ATAPI DRIVERS
 M: Borislav Petkov 
 L: linux-...@vger.kernel.org
diff --git a/drivers/input/misc/Kconfig b/drivers/input/misc/Kconfig
index 0b541cd..45729a9 100644
--- a/drivers/input/misc/Kconfig
+++ b/drivers/input/misc/Kconfig
@@ -647,4 +647,13 @@ config INPUT_SIRFSOC_ONKEY
 
  If unsure, say N.
 
+config INPUT_IDEAPAD_SLIDEBAR
+   tristate "IdeaPad Laptop Slidebar"
+   depends on INPUT
+   help
+ Input driver for slidebars on some Lenovo IdeaPad laptops.
+
+ If you have an IdeaPad laptop with a slidebar, say Y or M here.
+ Module name is ideapad_slidebar.
+
 endif
diff --git a/drivers/input/misc/Makefile b/drivers/input/misc/Makefile
index 829de43..0ebfb6d 100644
--- a/drivers/input/misc/Makefile
+++ b/drivers/input/misc/Makefile
@@ -61,3 +61,4 @@ obj-$(CONFIG_INPUT_WISTRON_BTNS)  += wistron_btns.o
 obj-$(CONFIG_INPUT_WM831X_ON)  += wm831x-on.o
 obj-$(CONFIG_INPUT_XEN_KBDDEV_FRONTEND)+= xen-kbdfront.o
 obj-$(CONFIG_INPUT_YEALINK)+= yealink.o
+obj-$(CONFIG_INPUT_IDEAPAD_SLIDEBAR)   += ideapad_slidebar.o
diff --git a/drivers/input/misc/ideapad_slidebar.c 
b/drivers/input/misc/ideapad_slidebar.c
new file mode 100644
index 000..1dc090d
--- /dev/null
+++ b/drivers/input/misc/ideapad_slidebar.c
@@ -0,0 +1,332 @@
+/*
+ * Input driver for slidebars on some Lenovo IdeaPad laptops
+ *
+ * Copyright (C) 2013 Andrey Moiseev 
+ *
+ * Reverse-engineered from Lenovo SlideNav software (SBarHook.dll).
+ *
+ * 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.
+ *
+ * Trademarks are the property of their respective owners.
+ */
+
+/*
+ * Currently tested and works on:
+ * Lenovo IdeaPad Y550
+ * Lenovo IdeaPad Y550P
+ *
+ * Other models can be added easily. To test,
+ * load with 'force' parameter set 'true'.
+ *
+ * LEDs blinking and input mode are managed via sysfs,
+ * (hex, unsigned byte value):
+ * /sys/devices/platform/ideapad_slidebar/slidebar_mode
+ *
+ * The value is in byte range, however, I only figured out
+ * how bits 0b10011001 work. Some other bits, probably,
+ * are meaningfull too.
+ *
+ * Possible states:
+ *
+ * STD_INT, ONMOV_INT, OFF_INT, LAST_POLL, OFF_POLL
+ *
+ * Meaning:
+ *   released  touched
+ * STD   'heartbeat'   lights follow the finger
+ * ONMOV no lights lights follow the finger
+ * LAST  at last pos   lights follow the finger
+ * OFF   no lights no lights
+ *
+ * INT   all input events are generated, interrupts are used
+ * POLL  no input events by default, to get them,
+ *  send 0b1000 (read below)
+ *
+ * Commands: write
+ *
+ * All  |  0b01001 -> STD_INT
+ * possible |  0b10001 -> ONMOV_INT
+ * states   |  0b01000 -> OFF_INT
+ *
+ *  |  0b0 -> LAST_POLL
+ * STD_INT or ONMOV_INT |
+ *  |  0b1 -> STD_INT
+ *
+ *  |  0b0 -> OFF_POLL
+ * OFF_INT or OFF_POLL  |
+ *  |  0b1 -> OFF_INT
+ *
+ * Any state |   0b1000 ->  if the slidebar has updated data,
+ * produce one input event (last position),
+ * switch to respective POLL mode
+ * (like 0x0), if not in POLL mode yet.
+ *
+ * Get current state: read
+ *
+ * masked by 0x11 read value 

Re: [RFC PATCH 2/4] openrisc: remove undefined of_get_cpu_node declaration

[Jonas Bonn]

On 08/16/13 11:41, Sudeep KarkadaNagesha wrote:

On 15/08/13 18:09, Sudeep KarkadaNagesha wrote:

From: Sudeep KarkadaNagesha 

This patch removes the declaration of the function 'of_get_cpu_node'
which is not defined for openrisc. This is in preparation to move
it's definition from PPC to DT common code.

Again it could be there as it was originally copied from powerpc.

Signed-off-by: Sudeep KarkadaNagesha 
Cc: Jonas Bonn 

Hi Jonas,

Since both microblaze and openrisc have moderated lists which I am not
member of, these patches were blocked. Michal Simek agreed to remove
this for microblaze. Do you see any concern with this patch for openrisc
? Can I have you ACK if it looks fine ?


Hi Sudeep,
Yes, thanks, the patch looks good.

Acked-by: Jonas Bonn 

/Jonas



Regards,
Sudeep

---
  arch/openrisc/include/asm/prom.h | 3 ---
  1 file changed, 3 deletions(-)

diff --git a/arch/openrisc/include/asm/prom.h b/arch/openrisc/include/asm/prom.h
index bbb34e5..eb59bfe 100644
--- a/arch/openrisc/include/asm/prom.h
+++ b/arch/openrisc/include/asm/prom.h
@@ -44,9 +44,6 @@ void of_parse_dma_window(struct device_node *dn, const void 
*dma_window_prop,
  
  extern void kdump_move_device_tree(void);
  
-/* CPU OF node matching */

-struct device_node *of_get_cpu_node(int cpu, unsigned int *thread);
-
  /* Get the MAC address */
  extern const void *of_get_mac_address(struct device_node *np);
  





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

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

[Dwight Engen]

On Tue, 20 Aug 2013 22:46:30 +0200
Arnd Bergmann  wrote:

> On Tuesday 20 August 2013, Dwight Engen wrote:
> > diff --git a/arch/powerpc/platforms/cell/spufs/inode.c
> > b/arch/powerpc/platforms/cell/spufs/inode.c index f390042..90fb308
> > 100644 --- a/arch/powerpc/platforms/cell/spufs/inode.c
> > +++ b/arch/powerpc/platforms/cell/spufs/inode.c
> > @@ -620,12 +620,12 @@ spufs_parse_options(struct super_block *sb,
> > char *options, struct inode *root) case Opt_uid:
> > if (match_int([0], ))
> > return 0;
> > -   root->i_uid = option;
> > +   root->i_uid = make_kuid(_user_ns,
> > option); break;
> > case Opt_gid:
> > if (match_int([0], ))
> > return 0;
> > -   root->i_gid = option;
> > +   root->i_gid = make_kgid(_user_ns,
> > option); break;
> > case Opt_mode:
> > if (match_octal([0], ))
> 
> Doesn't this mean the uid/gid is taken from the initial namespace
> rather than from the namespace of the 'mount' process calling this? I
> think the logical choice would be to have the UID be the one that
> gets passed here in the caller's namespace.

Yes, I agree. The other filesystems that take an Opt_uid as well do use
current_user_ns() and not init_user_ns. They also do a uid_valid()
check and fail the mount (or fallback to GLOBAL_ROOT_UID). So I think
that would look like this:

diff --git a/arch/powerpc/platforms/cell/spufs/inode.c 
b/arch/powerpc/platforms/cell/spufs/inode.c
index f390042..87ba7cf 100644
--- a/arch/powerpc/platforms/cell/spufs/inode.c
+++ b/arch/powerpc/platforms/cell/spufs/inode.c
@@ -620,12 +620,16 @@ spufs_parse_options(struct super_block *sb, char 
*options, struct inode *root)
case Opt_uid:
if (match_int([0], ))
return 0;
-   root->i_uid = option;
+   root->i_uid = make_kuid(current_user_ns(), option);
+   if (!uid_valid(root->i_uid))
+   return 0;
break;
case Opt_gid:
if (match_int([0], ))
return 0;
-   root->i_gid = option;
+   root->i_gid = make_kgid(current_user_ns(), option);
+   if (!gid_valid(root->i_gid))
+   return 0;
break;
case Opt_mode:
if (match_octal([0], ))

Again, I have not run tested this so we may just want to disable SPU_FS
with USER_NS until they can be tested together.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v2 0/8] turbostat: Build fixes, 32-bit support, and cleanups

[Mike Frysinger]

Acked-by: Mike Frysinger 
-mik
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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 6/8] turbostat: Factor out common function to open file and exit on failure

[Mike Frysinger]

On Tue, Aug 20, 2013 at 8:20 PM, Josh Triplett  wrote:
> +FILE *fopen_or_die(const char *path, const char *mode)
> +{
> +   FILE *filep = fopen(path, "r");

not a big deal, but would be nice to add the "e" flag
-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: [BUG REPORT]kernel panic with kmemcheck config

[Dave Hansen]

On 08/20/2013 07:45 PM, Libin wrote:
> [3.158023] [ cut here ]
> [3.162626] WARNING: CPU: 0 PID: 1 at 
> arch/x86/mm/kmemcheck/kmemcheck.c:634 kmemcheck_fault+0xb1/0xc0()
...
> [3.314877]  [] ? kmemcheck_trap+0x17/0x30
> [3.320507]  <>  <#DB>  [] do_debug+0x16a/0x1c0
> [3.327029]  [] debug+0x25/0x40
> [3.331714]  [] ? rb_insert_color+0xcc/0x150
> [3.337518]  <>  [] sysfs_link_sibling+0xa8/0xf0
> [3.344124]  [] ? __sysfs_add_one+0x6a/0x120
> [3.349931]  [] __sysfs_add_one+0x77/0x120
> [3.355563]  [] sysfs_add_one+0x26/0xe0
> [3.360937]  [] create_dir+0x7c/0xd0
> [3.366050]  [] sysfs_create_dir+0x93/0xd0
> [3.371684]  [] kobject_add_internal+0xe9/0x270
> [3.377748]  [] kobject_add_varg+0x38/0x60
> [3.383380]  [] ? kobject_add+0x1e/0x70
> [3.388751]  [] kobject_add+0x44/0x70
> [3.393954]  [] ? device_add+0xc2/0x580
> [3.399328]  [] device_add+0xd3/0x580
> [3.404529]  [] ? device_initialize+0xab/0xc0
> [3.410422]  [] device_register+0x19/0x20
> [3.415971]  [] init_memory_block+0xfb/0x120
> [3.421776]  [] add_memory_section+0xdc/0x140
> [3.427672]  [] memory_dev_init+0xa3/0xc1
> [3.433264]  [] driver_init+0x2f/0x31
> [3.438466]  [] do_basic_setup+0x29/0xce
> [3.443929]  [] ? sched_init_smp+0x14f/0x156
> [3.449735]  [] kernel_init_freeable+0x20d/0x291
> [3.455886]  [] ? rest_init+0x80/0x80
> [3.461084]  [] kernel_init+0x9/0x180
> [3.466285]  [] ret_from_fork+0x7c/0xb0
> [3.471659]  [] ? rest_init+0x80/0x80
> [3.476865] ---[ end trace bae4d98dd36296b7 ]---

So it's a kmemcheck trap while poking sysfs in the middle of the memory
kobjects getting created.  This code gets run at boot on a *LOT* of
systems, so it's probably something specific to your hardware.  I'd
suspect something like a memory section getting added twice, or a bug in
some error handling path.

You might want to double-check that all the calls to
add_memory_section() look sane.  It's also a bummer that kmemcheck
doesn't dump out the actual faulting address.


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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/4] mm/sparse: introduce alloc_usemap_and_memmap

[Yinghai Lu]

On Tue, Aug 20, 2013 at 8:11 PM, Wanpeng Li  wrote:
> Hi Yinghai,
> On Tue, Aug 20, 2013 at 05:02:17PM -0700, Yinghai Lu wrote:
 - /* ok, last chunk */
 - sparse_early_usemaps_alloc_node(usemap_map, pnum_begin, 
 NR_MEM_SECTIONS,
 -  usemap_count, nodeid_begin);
 + alloc_usemap_and_memmap(usemap_map, true);
>>
>>alloc_usemap_and_memmap() is somehow confusing.
>>
>>Please check if you can pass function pointer instead of true/false.
>>
>
> sparse_early_usemaps_alloc_node and sparse_early_mem_maps_alloc_node is
> similar, however, one has a parameter unsigned long ** and the other has
> struct page **. function pointer can't help, isn't it? ;-)

you could have one generic function pointer like
void *alloc_func(void *data);

and in the every alloc function, have own struct data to pass in/out...

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

linux-next: manual merge of the trivial tree with the wireless tree

[Stephen Rothwell]

Hi Jiri,

Today's linux-next merge of the trivial tree got a conflict in
drivers/net/wireless/iwlwifi/mvm/time-event.c between commit 057397943eee
("iwlwifi: mvm: disconnect if time event scheduling fails") from the
wireless tree and commit 0b1587b18bfe ("treewide: Fix typo in printk")
from the trivial tree.

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

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

diff --cc drivers/net/wireless/iwlwifi/mvm/time-event.c
index c17b74c,39b3ffb..000
--- a/drivers/net/wireless/iwlwifi/mvm/time-event.c
+++ b/drivers/net/wireless/iwlwifi/mvm/time-event.c
@@@ -198,12 -180,19 +198,12 @@@ static void iwl_mvm_te_handle_notif(str
 * By now, we should have finished association
 * and know the dtim period.
 */
 -  if (te_data->vif->type == NL80211_IFTYPE_STATION &&
 -  (!te_data->vif->bss_conf.assoc ||
 -   !te_data->vif->bss_conf.dtim_period)) {
 -  IWL_ERR(mvm,
 -  "No association and the time event is over 
already...\n");
 -  ieee80211_connection_loss(te_data->vif);
 -  }
 -
 +  iwl_mvm_te_check_disconnect(mvm, te_data->vif,
-   "No assocation and the time event is over already...");
++  "No association and the time event is over already...");
iwl_mvm_te_clear_data(mvm, te_data);
 -  } else if (le32_to_cpu(notif->action) & TE_NOTIF_HOST_EVENT_START) {
 +  } else if (le32_to_cpu(notif->action) & TE_V2_NOTIF_HOST_EVENT_START) {
te_data->running = true;
 -  te_data->end_jiffies = jiffies +
 -  TU_TO_JIFFIES(te_data->duration);
 +  te_data->end_jiffies = TU_TO_EXP_TIME(te_data->duration);
  
if (te_data->vif->type == NL80211_IFTYPE_P2P_DEVICE) {
set_bit(IWL_MVM_STATUS_ROC_RUNNING, >status);


pgpxAhAb4TfTi.pgp
Description: PGP signature

Re: [PATCH 1/3] ARM: imx6q: refactor some ldb related clocks

[Liu Ying]

On 08/20/2013 11:40 PM, Fabio Estevam wrote:
> On Tue, Aug 20, 2013 at 5:38 AM, Liu Ying  wrote:
> 
>> diff --git a/Documentation/devicetree/bindings/clock/imx6q-clock.txt 
>> b/Documentation/devicetree/bindings/clock/imx6q-clock.txt
>> index 5a90a72..90e923e 100644
>> --- a/Documentation/devicetree/bindings/clock/imx6q-clock.txt
>> +++ b/Documentation/devicetree/bindings/clock/imx6q-clock.txt
>> @@ -89,8 +89,6 @@ clocks and IDs.
>> gpu3d_shader74
>> ipu1_podf   75
>> ipu2_podf   76
>> -   ldb_di0_podf77
>> -   ldb_di1_podf78
>> ipu1_di0_pre79
>> ipu1_di1_pre80
>> ipu2_di0_pre81
> 
> This causes a 'hole' in the clock numbering scheme: 74, 75, 76, 79, 80, etc
> 

I find there is a 'hole' in 
Documentation/devicetree/bindings/clock/imx5-clock.txt as well.
The 'hole' was taken by tve_di(26) clock before.

Is this more acceptable?

ldb_di0_podf_unused77
ldb_di1_podf_unused78

Liu Ying

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

linux-next: manual merge of the trivial tree with the net-next tree

[Stephen Rothwell]

Hi Jiri,

Today's linux-next merge of the trivial tree got a conflict in
drivers/net/ethernet/qlogic/qlcnic/qlcnic_83xx_hw.c between commit
068a8d197e00 ("qlcnic: Replace poll mode mailbox interface with interrupt
based mailbox interface") from the  tree and commit 0b1587b18bfe
("treewide: Fix typo in printk") from the trivial tree.

I fixed it up (the former removed the line fixed by the latter, so I used
that) and can carry the fix as necessary (no action is required).

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


pgpdujatx5phN.pgp
Description: PGP signature

Re: [PATCH] kernel: user_namespace: always set the return parameter 'new_cred' when call unshare_userns() successfully.

[Chen Gang]

On 08/20/2013 10:37 PM, Oleg Nesterov wrote:
> On 08/20, Serge Hallyn wrote:
>>
>> Quoting Chen Gang (gang.c...@asianux.com):
>>> When unshare_userns() succeed, recommend to always set the return
>>> parameter which may be used by caller.
>>>
>>> The caller has rights to call it with 'new_cred' uninitialized, if
>>> succeed, the caller can assume the 'new_cred' has been initialized.
>>
>> But the only existing caller (sys_unshare) does in fact initialize it to
>> NULL.  So while this patch does no harm, is it necessary?
> 
> Agreed.
> 
> Plus, with this patch unshare_userns() becomes "inconsistent" compared
> to other unshare_ helpers.
> 
> Oleg.
> 
> 
> 

Hmm... for static functions, they don't need, but for extern functions,
recommend to do so.


For "unshare_ helpers", I find 3 extern functions:

  unshare_files() which already set value.
  unshare_userns() and unshare_nsproxy_namespaces() which not set.

In my opinion, recommend to always set the return parameter when
succeed, for the 2 left extern functions.


Thanks.
-- 
Chen Gang
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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 0/3] refactor some ldb related clocks

[Liu Ying]

On 08/21/2013 09:59 AM, Shawn Guo wrote:
> Hi Ying,
> 
> On Tue, Aug 20, 2013 at 06:08:48PM +0800, Liu Ying wrote:
>>> While I admit to having introduced the combination of 1/3.5 fixed
>>> divider and configurable 1/1,1/2 divder clocks to describe this
>>> fractional divider for the reasons you state, I think the correct
>>> solution would be to improve the table divider to support fractional
>>> values and get rid of the virtual ldb_di_div_3_5 clocks, not
>>> introduce more virtual clocks.
>>
>> Yes, it's good to support fractional values for the table divider(not sure 
>> if there is any plan for this).
>> I see there is something similar in 'include/linux/sh_clk.h'.
> 
> Yeah, I agree with Philipp on improving table divider to support
> fractional values.  Would you like to work on that?
> 
> Shawn
> 

I don't have a plan to work on that now.

Liu Ying

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

Re: rfc: trivial patches and slow deaths?

[Joe Perches]

On Tue, 2013-08-20 at 20:36 -0500, Rob Landley wrote:
> On 08/20/2013 07:22:36 PM, Joe Perches wrote:
> > I'm also saying that the trivial tree should
> > have some visibility about whether or not a
> > patch or series will be handled by the trivial
> > maintainer or not.
[]
> > Jiri has not responded to this point.
> He did. Twice.

Not really.

> > Silence about the status of patches that extends
> > for months is not good.
> 
> He has a public git tree.

Yes, I know.

> I've found that if a patch isn't in there, he hasn't picked
> it up yet.

It's the visibility of if/yet/when for the trivial
patches submitted and unresponded to that's the question.

And no, Jiri hasn't responded with any intention of
making any such scheme public.

I think a public patchwork queue like netdev's could
work reasonably well.

http://patchwork.ozlabs.org/project/netdev/list/


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

linux-next: manual merge of the trivial tree with the crypto tree

[Stephen Rothwell]

Hi Jiri,

Today's linux-next merge of the trivial tree got a conflict in
drivers/crypto/ux500/hash/hash_core.c between commit 69d2884debaa
("crypto: ux500 - Fix logging, make arrays const, neatening") from the
crypto tree and commit 0b1587b18bfe ("treewide: Fix typo in printk") from
the trivial tree.

I fixed it up (the former is a superset of the latter, so I used that)
and can carry the fix as necessary (no action is required).

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


pgpi6jtsGmJIc.pgp
Description: PGP signature

Re: [PATCH] kernel/futex.c: notice the return value after rt_mutex_finish_proxy_lock() fails

[Chen Gang]

On 08/21/2013 12:19 AM, Darren Hart wrote:
> HopingOn Tue, 2013-08-20 at 11:07 +0800, Chen Gang wrote:
> 
> 
> Hi Chen,
> 
>> rt_mutex_finish_proxy_lock() can return failure code (e.g. -EINTR,
>> -ETIMEDOUT).
>>
>> Original implementation has already noticed about it, but not check it
>> before next work.
>>
>> Also let coments within 80 columns to pass "./scripts/checkpatch.pl".
>>
>>
>> Signed-off-by: Chen Gang 
>> ---
>>  kernel/futex.c |   30 --
>>  1 files changed, 16 insertions(+), 14 deletions(-)
>>
>> diff --git a/kernel/futex.c b/kernel/futex.c
>> index c3a1a55..1a94e7d 100644
>> --- a/kernel/futex.c
>> +++ b/kernel/futex.c
>> @@ -2373,21 +2373,23 @@ static int futex_wait_requeue_pi(u32 __user *uaddr, 
>> unsigned int flags,
>>  ret = rt_mutex_finish_proxy_lock(pi_mutex, to, _waiter, 1);
>>  debug_rt_mutex_free_waiter(_waiter);
>>  
>> -spin_lock(q.lock_ptr);
>> -/*
>> - * Fixup the pi_state owner and possibly acquire the lock if we
>> - * haven't already.
>> - */
>> -res = fixup_owner(uaddr2, , !ret);
> 
> 
> This call catches a corner case which appears to be skipped now. Or am I
> missing how you accounted for that?
> 
> 

Pardon ?

Hmm... this patch lets related code block in "if(!ret) {...}", should
not remove any code.

Please help check again for whether what I have done is correct or not.

Thanks.

>> -/*
>> - * If fixup_owner() returned an error, proprogate that.  If it
>> - * acquired the lock, clear -ETIMEDOUT or -EINTR.
>> - */
>> -if (res)
>> -ret = (res < 0) ? res : 0;
>> +if (!ret) {
>> +spin_lock(q.lock_ptr);
>> +/*
>> + * Fixup the pi_state owner and possibly acquire the
>> + * lock if we haven't already.
>> + */
>> +res = fixup_owner(uaddr2, , !ret);
>> +/*
>> + * If fixup_owner() returned an error, proprogate that.
>> + * If it acquired the lock, clear -ETIMEDOUT or -EINTR.
>> + */
>> +if (res)
>> +ret = (res < 0) ? res : 0;
>>  
>> -/* Unqueue and drop the lock. */
>> -unqueue_me_pi();
>> +/* Unqueue and drop the lock. */
>> +unqueue_me_pi();
>> +}
>>  }
>>  
>>  /*
> 
> Thanks,
> 


-- 
Chen Gang
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] irq: add irq handler function name in ftrace

[Li Fei]

At present, irq handler function name is not printed out when
irq_handler_entry is added into trace event, which is inconvenient
for debugging.
In order to improve the debugging efficiency, print out the handler
function name in irq_handler_entry.

Signed-off-by: Li Fei 
Acked-by: Liu Chuansheng 
---
 Documentation/trace/ftrace.txt |8 
 include/trace/events/irq.h |5 -
 2 files changed, 8 insertions(+), 5 deletions(-)

diff --git a/Documentation/trace/ftrace.txt b/Documentation/trace/ftrace.txt
index b937c6e..907ecbd 100644
--- a/Documentation/trace/ftrace.txt
+++ b/Documentation/trace/ftrace.txt
@@ -2701,10 +2701,10 @@ CPU:2 [LOST 11745 EVENTS]
 bash-1998  [000] ..s2   138.733106: softirq_exit: vec=1 
[action=TIMER]
 bash-1998  [000] ..s2   138.733106: softirq_entry: vec=9 
[action=RCU]
 bash-1998  [000] ..s2   138.733109: softirq_exit: vec=9 
[action=RCU]
-sshd-1995  [001] d.h1   138.733278: irq_handler_entry: irq=21 
name=uhci_hcd:usb4
-sshd-1995  [001] d.h1   138.733280: irq_handler_exit: irq=21 
ret=unhandled
-sshd-1995  [001] d.h1   138.733281: irq_handler_entry: irq=21 
name=eth0
-sshd-1995  [001] d.h1   138.733283: irq_handler_exit: irq=21 
ret=handled
+kworker/0:2-161  [001] d.h1   138.733278: irq_handler_entry: 
irq=17 name=i2c-designware-pci-7 func=i2c_dw_isr
+kworker/0:2-161  [001] d.h1   138.733280: irq_handler_exit: irq=17 
ret=unhandled
+kworker/0:2-161  [001] d.h1   138.733281: irq_handler_entry: 
irq=17 name=mmc0 func=sdhci_irq
+kworker/0:2-161  [001] d.h1   138.733283: irq_handler_exit: irq=17 
ret=handled
 [...]
 
  # cat instances/zoot/trace
diff --git a/include/trace/events/irq.h b/include/trace/events/irq.h
index 1c09820..3497eb3 100644
--- a/include/trace/events/irq.h
+++ b/include/trace/events/irq.h
@@ -43,14 +43,17 @@ TRACE_EVENT(irq_handler_entry,
TP_STRUCT__entry(
__field(int,irq )
__string(   name,   action->name)
+   __field(irq_handler_t, func)
),
 
TP_fast_assign(
__entry->irq = irq;
__assign_str(name, action->name);
+   __entry->func = action->handler;
),
 
-   TP_printk("irq=%d name=%s", __entry->irq, __get_str(name))
+   TP_printk("irq=%d name=%s func=%pf",
+   __entry->irq, __get_str(name), __entry->func)
 );
 
 /**
-- 
1.7.4.1



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

Re: [PATCH] bcache: Remove use of down/up_read_non_owner()

[Kent Overstreet]

On Tue, Aug 20, 2013 at 10:41:53PM -0400, Steven Rostedt wrote:
> > I get that there's a problem, but the bcache code REALLY IS USING THE
> > RWSEM AS A LOCK; the answer isn't to open code the lock!
> 
> Actually, it is using it as a semaphore. The problem with Linux
> was that it only had spin locks and semaphores. People would use the
> semaphore as either a completion or a mutex. Luckily, we created both
> of those and replaced 90% of all semaphores with either a mutex or a
> completion.
> 
> The rwsem, sorta has the same issue. But it was pretty much always used
> as a read/write sleeping lock. It was not used as a semaphore. But it
> seems that the bcache really does use it as a semaphore here as it
> isn't just a mutex location. It's a special kind of completion, but the
> completion is in a strange way.

I think we're mostly quibbling over semantics here, and it's not that
big a deal - that said, I don't really get your distinction between a
semaphore and a mutex; I'd distinguish them by saying a semaphore can
count an arbitrary number of resources (the number it's initialized to),
and a mutex is always initialized to one - the fact that in the kernel
mutexes must be released by the same process that took them (while
important for PI and debugging) is not fundamental.

"rw semaphore" never made any sense to me; they're not counting
anything, like regular semaphores. They're just sleepable rw locks.

So it _sounds_ like you're saying bcache is using it as a semaphore,
beacuse it's using it as a lock we don't release in the original
context? in analogy to linux mutexes and semaphores? Not quite sure what
you mean.

> > Apologies to Christoph for getting distracted and not responding when
> > you started to explain what the issues were for RT. I'm not really
> > convinced they're that insurmountable (one of the issues was debugging,
> > which the _non_owner() stuff always handled just fine), but I'll take it
> > on faith that this usage is incompatible with rwsems + the RT
> > functionality since I haven't actually had time to dig into it.
> 
> The thing is, RT requires priority inheritance. When a task blocks on a
> rwsem, it has to boost the owner of that rwsem otherwise it risks
> unbounded priority inversion.
> 
> I have a hack that actually implements a work around for non_owner, but
> it adds overhead to all locks to do so.

Ok - I'd just be curious why the PI bit can't be factored out into a
wrapper like how the debug stuff is handled with the _non_owner bits,
but I can certainly believe that.

> > So assuming that's the case, IMO the sanest thing to do is make a new
> > type of lock - "rwsem_non_process" or somesuch - and use _that_ in
> > bcache. Not open coding the lock.
> 
> I actually started that, but decided this was the easier patch to send.
> Don't worry, I was expecting this email. No surprises here ;-)
> 
> This email was taken from Andrew Morton's play book (I see you Cc'd
> him, I forgot to). It's one of these patches of "It's so bad that the
> owner of the code will fix the issue out of fear that this patch may
> make it in".

Ah, I see :)

> > It can even live in the bcache code if we want since there currently
> > wouldn't be any other users, I don't really care. But open coding it?
> > Come on... makes me wonder what other code in the kernel is open coding
> > locks because it couldn't release it in the same process context that
> > took the lock for whatever reason.
> 
> Most cases just have completions. This looks like a case where "don't
> do something while transaction is taking place". Which can usually get
> away with a wait event.

Eh, only in sense that it's easy to implement mutexes and rwlocks with
wait_event().

To simplify the algorithm just a bit (only leaving out some
optimizations), bcache is using it to protect a rb tree, which containts
"things that are undergoing background writeback".

For foreground writes, we've got to check if the write overlaps with
anything in this rb tree. If so, we force _this_ write to writeback;
background writeback will write stale data to the backing device, but
that's fine because the data in the cache will still be marked as dirty.

To add stuff to this rb tree - i.e. for background writeback to start
flushing some dirty data - it's got to make sure it's not going to
overwrite some in progress foreground writethrough write.

Tracking every outstanding foreground write would be expensive, so
foreground writes take a read lock on the rb tree (both to check it for
anything they overlap with, and for their duration), and background
writeback takes a write lock when it goes to scan for dirty data to add
to the rb tree.

Even if you complain it's not _just_ protecting the rb tree, we're still
using it for mutual exclusion, plain and simple, and that's all a lock
is.


> > Also, nack this patch because increasing the number of atomic ops to
> > shared cachelines in our fast path. If it does end up being open coded,
> > I'll make a more 

Re: [PATCH v3 trivial 0/7] Miscellaneous Trivialities

[Michael Witten]

On Tue, 20 Aug 2013 19:19:37 -0500, Rob Landley wrote:

> Because some people actually read the commit logs and changes that
> don't do anything add noise for no benefit? (Your fourth change was a
> single typo fix. The previous three changes _combined_ were less
> valuable than that single typo fix. Hence asking if we really needed
> three separate commits to accomplish something that didn't actually
> need to be done in the first place.)
> ...
> Actually my objection is that it's not worth the churn in the commit logs.

Naturally, we don't NEED three separate commits! Squash all of them
into one commit if that's something worth hissing about.

Do you need help with the relevant commands?

Because you are the former and current maintainer of large and active
projects, I'd expect you to *appreciate* the value of taking in
fine-grained patches for REVIEW (even if you don't appreciate their
sum total).

The patches have been written in a way to *ease* the job of the
maintainer in understanding the changes. The fact that you find each
patch ludicrously trivial is a GREAT sign, especially considering
that I sent them mainly to the maintainer of... *TRIVIAL* changes.

> But yeah, why would a guy listed in MAINTAINERS as caring about the
> Documentation directory pay attention to proposed changes to the
> Documentation directory? Madness. I'll butt out now...

Madness is thinking that it means something to have your name listed in
some file. You are the maintainer when people send you patches and pull
from your repo---that is, when people *like* working with you. That's it.
A name in a file is simply a starting point for those contributors who
may not know any better.

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

Re: [PATCH 5/8] rcu: eliminate deadlock for rcu read site

[Lai Jiangshan]

On 08/21/2013 11:17 AM, Paul E. McKenney wrote:
> On Sat, Aug 10, 2013 at 08:07:15AM -0700, Paul E. McKenney wrote:
>> On Sat, Aug 10, 2013 at 11:43:59AM +0800, Lai Jiangshan wrote:
> 
> [ . . . ]
> 
>>> So I have to narrow the range of suspect locks. Two choices:
>>> A) don't call rt_mutex_unlock() from rcu_read_unlock(), only call it
>>>from rcu_preempt_not_context_switch(). we need to rework these
>>>two functions and it will add complexity to RCU, and it also still
>>>adds some probability of deferring.
>>
>> One advantage of bh-disable locks is that enabling bh checks
>> TIF_NEED_RESCHED, so that there is no deferring beyond that
>> needed by bh disable.  The same of course applies to preempt_disable().
>>
>> So one approach is to defer when rcu_read_unlock_special() is entered
>> with either preemption or bh disabled.  Your current set_need_resched()
>> trick would work fine in this case.  Unfortunately, re-enabling interrupts
>> does -not- check TIF_NEED_RESCHED, which is why we have latency problems
>> in that case.  (Hence my earlier question about making self-IPI safe
>> on all arches, which would result in an interrupt as soon as interrupts
>> were re-enabled.)
>>
>> Another possibility is to defer only when preemption or bh are disabled
>> on entry ro rcu_read_unlock_special(), but to retain the current
>> (admittedly ugly) nesting rules for the scheduler locks.
> 
> Would you be willing to do a patch that deferred rt_mutex_unlock() in
> the preempt/bh cases?  This of course does not solve the irq-disable
> case, but it should at least narrow the problem to the scheduler locks.
> 
> Not a big hurry, given the testing required, this is 3.13 or 3.14 material,
> I think.
> 
> If you are busy, no problem, I can do it, just figured you have priority
> if you want it.
> 
>   


I'm writing a special rt_mutex_unlock() for rcu deboost only.
I hope Steven accept it.

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

Re: [PATCH 5/8] rcu: eliminate deadlock for rcu read site

[Paul E. McKenney]

On Sat, Aug 10, 2013 at 08:07:15AM -0700, Paul E. McKenney wrote:
> On Sat, Aug 10, 2013 at 11:43:59AM +0800, Lai Jiangshan wrote:

[ . . . ]

> > So I have to narrow the range of suspect locks. Two choices:
> > A) don't call rt_mutex_unlock() from rcu_read_unlock(), only call it
> >from rcu_preempt_not_context_switch(). we need to rework these
> >two functions and it will add complexity to RCU, and it also still
> >adds some probability of deferring.
> 
> One advantage of bh-disable locks is that enabling bh checks
> TIF_NEED_RESCHED, so that there is no deferring beyond that
> needed by bh disable.  The same of course applies to preempt_disable().
> 
> So one approach is to defer when rcu_read_unlock_special() is entered
> with either preemption or bh disabled.  Your current set_need_resched()
> trick would work fine in this case.  Unfortunately, re-enabling interrupts
> does -not- check TIF_NEED_RESCHED, which is why we have latency problems
> in that case.  (Hence my earlier question about making self-IPI safe
> on all arches, which would result in an interrupt as soon as interrupts
> were re-enabled.)
> 
> Another possibility is to defer only when preemption or bh are disabled
> on entry ro rcu_read_unlock_special(), but to retain the current
> (admittedly ugly) nesting rules for the scheduler locks.

Would you be willing to do a patch that deferred rt_mutex_unlock() in
the preempt/bh cases?  This of course does not solve the irq-disable
case, but it should at least narrow the problem to the scheduler locks.

Not a big hurry, given the testing required, this is 3.13 or 3.14 material,
I think.

If you are busy, no problem, I can do it, just figured you have priority
if you want it.

Thanx, Paul

> > B) change rtmutex's lock->wait_lock to irqs-disabled.
> 
> I have to defer to Steven on this one.
> 
>   Thanx, Paul
> 
> > 4) In the view of rtmutex, I think it will be better if ->wait_lock is 
> > irqs-disabled.
> >A) like trylock of mutex/rw_sem, we may call rt_mutex_trylock() in irq 
> > in future.
> >B) the critical section of ->wait_lock is short,
> >   making it irqs-disabled don't hurts responsibility/latency.
> >C) almost all time of the critical section of ->wait_lock is 
> > irqs-disabled
> >   (due to task->pi_lock), I think converting whole time of the critical 
> > section
> >   of ->wait_lock to irqs-disabled is OK.
> > 
> > So I hope you change rtmutex's lock->wait_lock.
> > 
> > Any feedback from anyone is welcome.
> > 
> > Thanks,
> > Lai
> > 
> > On 08/09/2013 04:40 AM, Paul E. McKenney wrote:
> > > On Wed, Aug 07, 2013 at 06:25:01PM +0800, Lai Jiangshan wrote:
> > >> Background)
> > >>
> > >> Although all articles declare that rcu read site is deadlock-immunity.
> > >> It is not true for rcu-preempt, it will be deadlock if rcu read site
> > >> overlaps with scheduler lock.
> > >>
> > >> ec433f0c, 10f39bb1 and 016a8d5b just partially solve it. But rcu read 
> > >> site
> > >> is still not deadlock-immunity. And the problem described in 016a8d5b
> > >> is still existed(rcu_read_unlock_special() calls wake_up).
> > >>
> > >> Aim)
> > >>
> > >> We want to fix the problem forever, we want to keep rcu read site
> > >> is deadlock-immunity as books say.
> > >>
> > >> How)
> > >>
> > >> The problem is solved by "if rcu_read_unlock_special() is called inside
> > >> any lock which can be (chained) nested in rcu_read_unlock_special(),
> > >> we defer rcu_read_unlock_special()".
> > >> This kind locks include rnp->lock, scheduler locks, perf ctx->lock, locks
> > >> in printk()/WARN_ON() and all locks nested in these locks or chained 
> > >> nested
> > >> in these locks.
> > >>
> > >> The problem is reduced to "how to distinguish all these locks(context)",
> > >> We don't distinguish all these locks, we know that all these locks
> > >> should be nested in local_irqs_disable().
> > >>
> > >> we just consider if rcu_read_unlock_special() is called in irqs-disabled
> > >> context, it may be called in these suspect locks, we should defer
> > >> rcu_read_unlock_special().
> > >>
> > >> The algorithm enlarges the probability of deferring, but the probability
> > >> is still very very low.
> > >>
> > >> Deferring does add a small overhead, but it offers us:
> > >>  1) really deadlock-immunity for rcu read site
> > >>  2) remove the overhead of the irq-work(250 times per second in avg.)
> > > 
> > > One problem here -- it may take quite some time for a set_need_resched()
> > > to take effect.  This is especially a problem for RCU priority boosting,
> > > but can also needlessly delay preemptible-RCU grace periods because
> > > local_irq_restore() and friends don't check the TIF_NEED_RESCHED bit.
> > > 
> > > OK, alternatives...
> > > 
> > > o Keep the current rule saying that if the scheduler is going
> > >   to exit an RCU read-side critical section while holding

[PATCH 2/4] ARM: dts: Add Freescale ftm pwm node for VF610.

[Xiubo Li]

Signed-off-by: Xiubo Li 
---
 arch/arm/boot/dts/vf610.dtsi | 83 +++-
 1 file changed, 82 insertions(+), 1 deletion(-)

diff --git a/arch/arm/boot/dts/vf610.dtsi b/arch/arm/boot/dts/vf610.dtsi
index 67d929c..b3a0b6e 100644
--- a/arch/arm/boot/dts/vf610.dtsi
+++ b/arch/arm/boot/dts/vf610.dtsi
@@ -140,6 +140,17 @@
clock-names = "pit";
};
 
+   pwm0: pwm@40038000 {
+   compatible = "fsl,vf610-ftm-pwm";
+   #pwm-cells = <3>;
+   reg = <0x40038000 0x1000>;
+   clocks = < VF610_CLK_FTM0_EXT_FIX_EN>,
+   < VF610_CLK_FTM0_EXT_SEL>,
+   < VF610_CLK_FTM0>;
+   clock-names = "ftm0_ext_fix_en", 
"ftm0_ext_sel", "ftm0";
+   status = "disabled";
+   };
+
wdog@4003e000 {
compatible = "fsl,vf610-wdt", "fsl,imx21-wdt";
reg = <0x4003e000 0x1000>;
@@ -270,16 +281,86 @@
};
 
pwm0 {
-   pinctrl_pwm0_1: pwm0grp_1 {
+   pinctrl_pwm0_ch0_en: pwm0grp_ch0_en {
fsl,pins = <
VF610_PAD_PTB0__FTM0_CH0
0x1582
+   >;
+   };
+   pinctrl_pwm0_ch0_ds: pwm0grp_ch0_ds {
+   fsl,pins = <
+   VF610_PAD_PTB0__FTM0_CH0
0x
+   >;
+   };
+   pinctrl_pwm0_ch1_en: pwm0grp_ch1_en {
+   fsl,pins = <
VF610_PAD_PTB1__FTM0_CH1
0x1582
+   >;
+   };
+   pinctrl_pwm0_ch1_ds: pwm0grp_ch1_ds {
+   fsl,pins = <
+   VF610_PAD_PTB1__FTM0_CH1
0x
+   >;
+   };
+   pinctrl_pwm0_ch2_en: pwm0grp_ch2_en {
+   fsl,pins = <
VF610_PAD_PTB2__FTM0_CH2
0x1582
+   >;
+   };
+   pinctrl_pwm0_ch2_ds: pwm0grp_ch2_ds {
+   fsl,pins = <
+   VF610_PAD_PTB2__FTM0_CH2
0x
+   >;
+   };
+   pinctrl_pwm0_ch3_en: pwm0grp_ch3_en {
+   fsl,pins = <
VF610_PAD_PTB3__FTM0_CH3
0x1582
+   >;
+   };
+   pinctrl_pwm0_ch3_ds: pwm0grp_ch3_ds {
+   fsl,pins = <
+   VF610_PAD_PTB3__FTM0_CH3
0x
+   >;
+   };
+   pinctrl_pwm0_ch4_en: pwm0grp_ch4_en {
+   fsl,pins = <
+   VF610_PAD_PTB4__FTM0_CH4
0x1582
+   >;
+   };
+   pinctrl_pwm0_ch4_ds: pwm0grp_ch4_ds {
+   fsl,pins = <
+   VF610_PAD_PTB4__FTM0_CH4
0x
+   >;
+   };
+   pinctrl_pwm0_ch5_en: pwm0grp_ch5_en {
+   fsl,pins = <
+   VF610_PAD_PTB5__FTM0_CH5
0x1582
+   >;
+   };
+   pinctrl_pwm0_ch5_ds: pwm0grp_ch5_ds {
+ 

[PATCH 3/4] ARM: dts: Enables ftm pwm device for Vybrid VF610 TOWER board.

[Xiubo Li]

Signed-off-by: Xiubo Li 
---
 arch/arm/boot/dts/vf610-twr.dts | 17 +
 1 file changed, 17 insertions(+)

diff --git a/arch/arm/boot/dts/vf610-twr.dts b/arch/arm/boot/dts/vf610-twr.dts
index b3905f5..6f93d8d 100644
--- a/arch/arm/boot/dts/vf610-twr.dts
+++ b/arch/arm/boot/dts/vf610-twr.dts
@@ -50,6 +50,23 @@
status = "okay";
 };
 
+ {
+   pinctrl-names = "en0", "ds0", "en1", "ds1", "en2", "ds2", "en3", "ds3";
+   pinctrl-0 = <_pwm0_ch0_en>;
+   pinctrl-1 = <_pwm0_ch0_ds>;
+   pinctrl-2 = <_pwm0_ch1_en>;
+   pinctrl-3 = <_pwm0_ch1_ds>;
+   pinctrl-4 = <_pwm0_ch2_en>;
+   pinctrl-5 = <_pwm0_ch2_ds>;
+   pinctrl-6 = <_pwm0_ch3_en>;
+   pinctrl-7 = <_pwm0_ch3_ds>;
+   fsl,pwm-clk-ps = <7>;
+   fsl,pwm-cpwm = <0>;
+   fsl,pwm-number = <4>;
+   fsl,pwm-channels = <0 1 2 3>;
+   status = "okay";
+};
+
  {
pinctrl-names = "default";
pinctrl-0 = <_uart1_1>;
-- 
1.8.0


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

[PATCH 4/4] Documentation: Add device tree bindings for Freescale FTM PWM

[Xiubo Li]

Signed-off-by: Xiubo Li 
---
 .../devicetree/bindings/pwm/fsl-ftm-pwm.txt| 52 ++
 1 file changed, 52 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/pwm/fsl-ftm-pwm.txt

diff --git a/Documentation/devicetree/bindings/pwm/fsl-ftm-pwm.txt 
b/Documentation/devicetree/bindings/pwm/fsl-ftm-pwm.txt
new file mode 100644
index 000..698965b
--- /dev/null
+++ b/Documentation/devicetree/bindings/pwm/fsl-ftm-pwm.txt
@@ -0,0 +1,52 @@
+Freescale FTM PWM controller
+
+Required properties:
+- compatible: should be "fsl,vf610-ftm-pwm"
+- reg: physical base address and length of the controller's registers
+- #pwm-cells: Should be 3. Number of cells being used to specify PWM property.
+  First cell specifies the per-chip channel index of the PWM to use, the
+  second cell is the period in nanoseconds and bit 0 in the third cell is
+  used to encode the polarity of PWM output. Set bit 0 of the third in PWM
+  specifier to 1 for inverse polarity & set to 0 for normal polarity.
+- fsl,pwm-clk-ps: the ftm0 pwm clock's prescaler, divide-by 2^n(n = 0 ~ 7).
+- fsl,pwm-cpwm: Center-Aligned PWM (CPWM) mode.
+- fsl,pwm-number: the number of PWM devices, and is must equal to the number
+  of "fsl,pwm-channels".
+- fsl,pwm-channels: the channels' order which is be used for pwm in ftm0
+  module, and they must be one or some of 0 ~ 7, because the ftm0 only has
+  8 channels can be used.
+- for very channel, the revlatived the pinctrl should be at least two state
+  {"enN", "dsN"}, which "en" means "enable", "ds" means "disable" and "N"
+  means the order of the channel.
+
+Example:
+
+pwm0: pwm@40038000 {
+ compatible = "fsl,vf610-ftm-pwm";
+ reg = <0x40038000 0x1000>;
+ #pwm-cells = <3>;
+ pinctrl-names = "en0", "ds0", "en3", "ds3";
+ pinctrl-0 = <_pwm0_ch0_en>;
+ pinctrl-1 = <_pwm0_ch0_ds>;
+ pinctrl-2 = <_pwm0_ch3_en>;
+ pinctrl-3 = <_pwm0_ch3_ds>;
+ fsl,pwm-clk-ps = <7>;
+ fsl,pwm-cpwm = <0>;
+ fsl,pwm-number = <2>;
+ fsl,pwm-channels = <0 3>;
+ ...
+  };
+
+leds {
+   compatible = "pwm-leds";
+   led {
+   label = "fsl_led";
+   pwms = < 0 1000 0>;
+   max-brightness = <127>;
+   };
+   backlight {
+   label = "fsl_backlight";
+   pwms = < 3 1000 1>;
+   max-brightness = <100>;
+   };
+};
-- 
1.8.0


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

[PATCH 1/4] pwm: add freescale ftm pwm driver support

[Xiubo Li]

Add freescale ftm pwm driver support. The ftm pwm device
can be found on Vybrid VF610 and Layerscape LS-1 SoCs.

Signed-off-by: Xiubo Li 
Signed-off-by: Jingchang Lu 
---
 drivers/pwm/Kconfig   |  10 +
 drivers/pwm/Makefile  |   1 +
 drivers/pwm/pwm-fsl-ftm.c | 586 ++
 3 files changed, 597 insertions(+)
 create mode 100644 drivers/pwm/pwm-fsl-ftm.c

diff --git a/drivers/pwm/Kconfig b/drivers/pwm/Kconfig
index 75840b5..247b4c3 100644
--- a/drivers/pwm/Kconfig
+++ b/drivers/pwm/Kconfig
@@ -62,6 +62,16 @@ config PWM_BFIN
  To compile this driver as a module, choose M here: the module
  will be called pwm-bfin.
 
+config PWM_FTM
+   tristate "Freescale FTM PWM support"
+   depends on OF
+   help
+ Generic FTM PWM framework driver for Freescale VF610 and
+ Layerscape LS-1 SoCs.
+
+ To compile this driver as a module, choose M here: the module
+ will be called pwm-ftm.
+
 config PWM_IMX
tristate "i.MX PWM support"
depends on ARCH_MXC
diff --git a/drivers/pwm/Makefile b/drivers/pwm/Makefile
index 77a8c18..0e7f6ae 100644
--- a/drivers/pwm/Makefile
+++ b/drivers/pwm/Makefile
@@ -3,6 +3,7 @@ obj-$(CONFIG_PWM_SYSFS) += sysfs.o
 obj-$(CONFIG_PWM_AB8500)   += pwm-ab8500.o
 obj-$(CONFIG_PWM_ATMEL_TCB)+= pwm-atmel-tcb.o
 obj-$(CONFIG_PWM_BFIN) += pwm-bfin.o
+obj-$(CONFIG_PWM_FTM)  += pwm-fsl-ftm.o
 obj-$(CONFIG_PWM_IMX)  += pwm-imx.o
 obj-$(CONFIG_PWM_JZ4740)   += pwm-jz4740.o
 obj-$(CONFIG_PWM_LPC32XX)  += pwm-lpc32xx.o
diff --git a/drivers/pwm/pwm-fsl-ftm.c b/drivers/pwm/pwm-fsl-ftm.c
new file mode 100644
index 000..f10ed34
--- /dev/null
+++ b/drivers/pwm/pwm-fsl-ftm.c
@@ -0,0 +1,586 @@
+/*
+ *  Freescale FTM PWM Driver
+ *
+ *  Copyright 2013 Freescale Semiconductor, Inc.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#define FTM_SC  0x00
+#define FTMSC_CPWMS (0x1 << 5)
+#define FTMSC_CLK_MASK  0x03
+#define FTMSC_CLK_OFFSET0x03
+#define FTMSC_CLKSYS(0x01 << 3)
+#define FTMSC_CLKFIX(0x02 << 3)
+#define FTMSC_CLKEXT(0x03 << 3)
+#define FTMSC_PS_MASK   0x07
+#define FTMSC_PS_OFFSET 0x00
+
+#define FTM_CNT 0x04
+#define FTM_MOD 0x08
+
+#define FTM_CSC_BASE0x0C
+#define FTM_CSC(_CHANNEL) \
+   (FTM_CSC_BASE + (_CHANNEL * 0x08))
+#define FTMCnSC_MSB (0x01 << 5)
+#define FTMCnSC_MSA (0x01 << 4)
+#define FTMCnSC_ELSB(0x01 << 3)
+#define FTMCnSC_ELSA(0x01 << 2)
+#define FTM_PWMMODE (FTMCnSC_MSB)
+#define FTM_HIGH_TRUE   (FTMCnSC_ELSB)
+#define FTM_LOW_TRUE(FTMCnSC_ELSA)
+
+#define FTM_CV_BASE 0x10
+#define FTM_CV(_CHANNEL) \
+   (FTM_CV_BASE + (_CHANNEL * 0x08))
+
+#define FTM_CNTIN   0x4C
+#define FTM_STATUS  0x50
+
+#define FTM_MODE0x54
+#define FTMMODE_FTMEN   (0x01 << 0)
+#define FTMMODE_INIT(0x01 << 2)
+#define FTMMODE_PWMSYNC (0x01 << 3)
+
+#define FTM_SYNC0x58
+#define FTM_OUTINIT 0x5C
+#define FTM_OUTMASK 0x60
+#define FTM_COMBINE 0x64
+#define FTM_DEADTIME0x68
+#define FTM_EXTTRIG 0x6C
+#define FTM_POL 0x70
+#define FTM_FMS 0x74
+#define FTM_FILTER  0x78
+#define FTM_FLTCTRL 0x7C
+#define FTM_QDCTRL  0x80
+#define FTM_CONF0x84
+#define FTM_FLTPOL  0x88
+#define FTM_SYNCONF 0x8C
+#define FTM_INVCTRL 0x90
+#define FTM_SWOCTRL 0x94
+#define FTM_PWMLOAD 0x98
+
+#define FTM_MAX_CHANNEL 0x08
+#define FTM_CNTIN_VAL   0x00
+
+struct fsl_pwm {
+   unsigned long period_cycles;
+   unsigned long duty_cycles;
+};
+
+struct fsl_pwm_chip {
+   struct mutex lock;
+
+   struct platform_device *pdev;
+   struct pwm_chip chip;
+
+   unsigned intclk_ps;
+   struct clk  *clk;
+
+   void __iomem*base;
+
+   unsigned intcpwm;
+   struct fsl_pwm fpwms[FTM_MAX_CHANNEL];
+
+   /* pinctrl handles */
+   struct pinctrl  *pinctrl;
+};
+
+static inline struct fsl_pwm_chip *to_fsl_chip(struct pwm_chip *chip)
+{
+   return container_of(chip, struct fsl_pwm_chip, chip);
+}
+
+static int fsl_pwm_request_channel(struct pwm_chip *chip,
+  struct pwm_device *pwm)
+{
+   int ret = 0;
+   struct fsl_pwm_chip *fpc;
+
+   fpc = to_fsl_chip(chip);
+
+   ret = clk_prepare_enable(fpc->clk);
+   if (ret) {
+   dev_err(>pdev->dev,
+   

[PATCH 0/4] Add freescale ftm pwm driver for Vybrid VF610 TOWER

[Xiubo Li]

Hello,

This patch series is the freescale ftm pwm implementation.
There are 8 channels most supported by the ftm pwm,
and there are two pwm modes:
- Center-Aligned PWM (CPWM) mode
- Edge-Aligned PWM (EPWM) mode

This implementation is only compatible with device tree definition.

Please feel free to comment the dt bindinds.

This patch series is based on linux-next and has been tested on Vybrid VF610TWR 
board using device tree.

Best Regards,
Xiubo Li



--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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 tip/core/rcu 1/5] rcu: Add duplicate-callback tests to rcutorture

[Paul E. McKenney]

On Wed, Aug 21, 2013 at 10:40:15AM +0800, Lai Jiangshan wrote:
> On 08/21/2013 02:38 AM, Paul E. McKenney wrote:
> > On Tue, Aug 20, 2013 at 06:02:39PM +0800, Lai Jiangshan wrote:
> >> On 08/20/2013 10:51 AM, Paul E. McKenney wrote:
> >>> From: "Paul E. McKenney" 
> >>>
> >>> This commit adds a object_debug option to rcutorture to allow the
> >>> debug-object-based checks for duplicate call_rcu() invocations to
> >>> be deterministically tested.
> >>>
> >>> Signed-off-by: Paul E. McKenney 
> >>> Cc: Mathieu Desnoyers 
> >>> Cc: Sedat Dilek 
> >>> Cc: Davidlohr Bueso 
> >>> Cc: Rik van Riel 
> >>> Cc: Thomas Gleixner 
> >>> Cc: Linus Torvalds 
> >>> Tested-by: Sedat Dilek 
> >>> [ paulmck: Banish mid-function ifdef, more or less per Josh Triplett. ]
> >>> ---
> >>>  kernel/rcutorture.c | 45 +
> >>>  1 file changed, 45 insertions(+)
> >>>
> >>> diff --git a/kernel/rcutorture.c b/kernel/rcutorture.c
> >>> index 3d936f0f..f5cf2bb 100644
> >>> --- a/kernel/rcutorture.c
> >>> +++ b/kernel/rcutorture.c
> >>> @@ -66,6 +66,7 @@ static int fqs_duration;/* Duration of bursts 
> >>> (us), 0 to disable. */
> >>>  static int fqs_holdoff;  /* Hold time within burst (us). */
> >>>  static int fqs_stutter = 3;  /* Wait time between bursts (s). */
> >>>  static int n_barrier_cbs;/* Number of callbacks to test RCU 
> >>> barriers. */
> >>> +static int object_debug; /* Test object-debug double call_rcu()?. */
> >>>  static int onoff_interval;   /* Wait time between CPU hotplugs, 
> >>> 0=disable. */
> >>>  static int onoff_holdoff;/* Seconds after boot before CPU 
> >>> hotplugs. */
> >>>  static int shutdown_secs;/* Shutdown time (s).  <=0 for no 
> >>> shutdown. */
> >>> @@ -100,6 +101,8 @@ module_param(fqs_stutter, int, 0444);
> >>>  MODULE_PARM_DESC(fqs_stutter, "Wait time between fqs bursts (s)");
> >>>  module_param(n_barrier_cbs, int, 0444);
> >>>  MODULE_PARM_DESC(n_barrier_cbs, "# of callbacks/kthreads for barrier 
> >>> testing");
> >>> +module_param(object_debug, int, 0444);
> >>> +MODULE_PARM_DESC(object_debug, "Enable debug-object double call_rcu() 
> >>> testing");
> >>>  module_param(onoff_interval, int, 0444);
> >>>  MODULE_PARM_DESC(onoff_interval, "Time between CPU hotplugs (s), 
> >>> 0=disable");
> >>>  module_param(onoff_holdoff, int, 0444);
> >>> @@ -1934,6 +1937,46 @@ rcu_torture_cleanup(void)
> >>>   rcu_torture_print_module_parms(cur_ops, "End of test: SUCCESS");
> >>>  }
> >>>  
> >>> +#ifdef CONFIG_DEBUG_OBJECTS_RCU_HEAD
> >>> +static void rcu_torture_leak_cb(struct rcu_head *rhp)
> >>> +{
> >>> +}
> >>> +
> >>> +static void rcu_torture_err_cb(struct rcu_head *rhp)
> >>> +{
> >>> + /* This -might- happen due to race conditions, but is unlikely. */
> >>> + pr_alert("rcutorture: duplicated callback was invoked.\n");
> >>> +}
> >>> +#endif /* #ifdef CONFIG_DEBUG_OBJECTS_RCU_HEAD */
> >>> +
> >>> +/*
> >>> + * Verify that double-free causes debug-objects to complain, but only
> >>> + * if CONFIG_DEBUG_OBJECTS_RCU_HEAD=y.  Otherwise, say that the test
> >>> + * cannot be carried out.
> >>> + */
> >>> +static void rcu_test_debug_objects(void)
> >>> +{
> >>> +#ifdef CONFIG_DEBUG_OBJECTS_RCU_HEAD
> >>> + struct rcu_head rh1;
> >>> + struct rcu_head rh2;
> >>> +
> >>> + init_rcu_head_on_stack();
> >>> + init_rcu_head_on_stack();
> >>> + pr_alert("rcutorture: WARN: Duplicate call_rcu() test starting.\n");
> >>> + local_irq_disable(); /* Make it hard to finish grace period. */
> >>
> >> you can use rcu_read_lock() directly.
> > 
> > I could do that as well, but it doesn't do everything that 
> > local_irq_disable()
> > does.
> > 
> > Right, which means that my comment is bad.  Fixing both, thank you!
> > 
> >>> + call_rcu(, rcu_torture_leak_cb); /* start grace period. */
> > 
> > And the one above cannot start a grace period due to irqs being enabled.
> > Which is -almost- always OK, but...
> > 
> >>> + call_rcu(, rcu_torture_err_cb);
> > 
> > And this one should invoke rcu_torture_leak_cb instead of
> > rcu_torture_err_cb().  Just results in a confusing error message, but...
> 
> I still don't understand why rcu_torture_err_cb() will be called when:
> 
> rcu_read_lock();
> call_rcu(, rcu_torture_leak_cb);
> call_rcu(, rcu_torture_err_cb); // rh2 will be still queued here,
>   // debug-objects will find it and
>   // change it to rcu_leak_callback()
> rcu_read_unlock();

Fair point, no chance of the second rh2 callback being queued after the
first one is invoked!  I will leave the message.  Whoever sees it with
the current code will have something to tell their grandchildren.

Thanx, Paul

> > OK, a few more fixes, then!
> > 
> >>> + call_rcu(, rcu_torture_err_cb); /* duplicate callback. */
> >>> + local_irq_enable();
> >>> + rcu_barrier();
> >>> + pr_alert("rcutorture: WARN: Duplicate 

Re: [PATCH RFC v2 1/2] qspinlock: Introducing a 4-byte queue spinlock implementation

[Waiman Long]

On 08/20/2013 11:31 AM, Alexander Fyodorov wrote:

Hi Waiman,

I'm not subscribed to the lkml so I'm writing to you instead. In your patch you 
put smp_wmb() at the end of spin_unlock():

+static __always_inline void queue_spin_unlock(struct qspinlock *lock)
+{
+   /*
+* This unlock function may get inlined into the caller. The
+* compiler barrier is needed to make sure that the lock will
+* not be released before changes to the critical section is done.
+* The ending smp_wmb() allows queue head process to get the lock ASAP.
+*/
+   barrier();
+#ifndef QSPINLOCK_MANYCPUS
+   {
+   u16 qcode = ACCESS_ONCE(lock->locked);
+   if (unlikely(qcode != QSPINLOCK_LOCKED))
+   queue_spin_unlock_slowpath(lock, qcode);
+   }
+#endif
+   ACCESS_ONCE(lock->locked) = 0;
+   smp_wmb();
+}

Isn't a race possible if another thread acquires the spinlock in the window between 
setting lock->locked to 0 and issuing smp_wmb()? Writes from the critical section 
from our thread might be delayed behind the write to lock->locked if the 
corresponding cache bank is busy.


The purpose of smp_wmb() is to make sure that content in the cache will 
be flushed out to the memory in case the cache coherency protocol cannot 
guarantee a single view of memory content on all processor. In other 
word, smp_wmb() is used to make other processors see that the lock has 
been freed ASAP. If another processor see that before smp_wmb(), it will 
be even better as the latency is reduced. As the lock holder is the only 
one that can release the lock, there is no race condition here.



And shouldn't it be a full memory barrier (smp_mb()) instead? Because we want 
loads from critical section to finish too before giving spinlock to another 
thread (which might change memory contents).


That is a legitimate question. I don't think it is a problem on x86 as 
the x86 spinlock code doesn't do a full mb() in the lock and unlock 
paths. However, other architectures like ARM do requires a full mb() in 
the lock and unlock paths. A full mb() will be costly in x86. A possible 
solution is to make ARCH_QSPINLOCK a tri-state variable whose value can 
be off, on with mb, on without mb. The QSPINLOCK parameter will then 
become a hidden one.



Comment in queue_spin_unlock() says: "The ending smp_wmb() allows queue head process 
to get the lock ASAP". But memory barriers can be costly on some architectures so 
issuing one just to empty write buffers might result in performance loss on them. Such 
things should be left to hardware IMHO.

So I think unlock() should look like this:

+static __always_inline void queue_spin_unlock(struct qspinlock *lock)
+{
+   /*
+* Wait for the critical section to finish memory accesses.
+*/
+   smp_mb();
+
+#ifndef QSPINLOCK_MANYCPUS
+   {
+   u16 qcode = ACCESS_ONCE(lock->locked);
+   if (unlikely(qcode != QSPINLOCK_LOCKED))
+   queue_spin_unlock_slowpath(lock, qcode);
+   }
+#endif
+   ACCESS_ONCE(lock->locked) = 0;
+}


The smp_mb() will be conditionalized depending on the ARCH_QSPINLOCK 
setting. The smp_wmb() may not be needed, but a compiler barrier should 
still be there.



Also I don't understand why there are so many uses of ACCESS_ONCE() macro. It 
does not guarantee memory ordering with regard to other CPUs, so probably most 
of the uses can be removed (with exception of lock_is_contended(), where it 
prohibits gcc from optimizing the loop away).


All the lock/unlock code can be inlined and we don't know what the 
compiler will do to optimize code. The ACCESS_ONCE() macro is used to 
make sure that the compiler won't optimize away the actual fetch or 
write of the memory. Even if the compiler won't optimize away the memory 
access, adding the ACCESS_ONCE() macro won't have any extra overhead. So 
a more liberal use of it won't hurt performance.


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

[PATCH 3/3] mm/shmem.c: check the return value of mpol_to_str()

[Chen Gang]

mpol_to_str() may fail, and not fill the buffer (e.g. -EINVAL), so need
check about it, or buffer may not be zero based, and next seq_printf()
will cause issue.


Signed-off-by: Chen Gang 
Cc: Cyrill Gorcunov 
---
 mm/shmem.c |5 -
 1 files changed, 4 insertions(+), 1 deletions(-)

diff --git a/mm/shmem.c b/mm/shmem.c
index e59d332..ae5112f 100644
--- a/mm/shmem.c
+++ b/mm/shmem.c
@@ -886,11 +886,14 @@ redirty:
 static int shmem_show_mpol(struct seq_file *seq, struct mempolicy *mpol)
 {
char buffer[64];
+   int ret;
 
if (!mpol || mpol->mode == MPOL_DEFAULT)
return 0;   /* show nothing */
 
-   mpol_to_str(buffer, sizeof(buffer), mpol);
+   ret = mpol_to_str(buffer, sizeof(buffer), mpol);
+   if (ret < 0)
+   return ret;
 
seq_printf(seq, ",mpol=%s", buffer);
return 0;
-- 
1.7.7.6
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] bcache: Remove use of down/up_read_non_owner()

[Steven Rostedt]

On Tue, 20 Aug 2013 19:19:00 -0700
Kent Overstreet  wrote:

> On Tue, Aug 20, 2013 at 11:16:02AM -0400, Steven Rostedt wrote:
> > 

> I _really_ disagree with this approach.

I had a feeling you would love it.

> 
> I get that there's a problem, but the bcache code REALLY IS USING THE
> RWSEM AS A LOCK; the answer isn't to open code the lock!

Actually, it is using it as a semaphore. The problem with Linux
was that it only had spin locks and semaphores. People would use the
semaphore as either a completion or a mutex. Luckily, we created both
of those and replaced 90% of all semaphores with either a mutex or a
completion.

The rwsem, sorta has the same issue. But it was pretty much always used
as a read/write sleeping lock. It was not used as a semaphore. But it
seems that the bcache really does use it as a semaphore here as it
isn't just a mutex location. It's a special kind of completion, but the
completion is in a strange way.

> 
> Apologies to Christoph for getting distracted and not responding when
> you started to explain what the issues were for RT. I'm not really
> convinced they're that insurmountable (one of the issues was debugging,
> which the _non_owner() stuff always handled just fine), but I'll take it
> on faith that this usage is incompatible with rwsems + the RT
> functionality since I haven't actually had time to dig into it.

The thing is, RT requires priority inheritance. When a task blocks on a
rwsem, it has to boost the owner of that rwsem otherwise it risks
unbounded priority inversion.

I have a hack that actually implements a work around for non_owner, but
it adds overhead to all locks to do so.

> 
> So assuming that's the case, IMO the sanest thing to do is make a new
> type of lock - "rwsem_non_process" or somesuch - and use _that_ in
> bcache. Not open coding the lock.

I actually started that, but decided this was the easier patch to send.
Don't worry, I was expecting this email. No surprises here ;-)

This email was taken from Andrew Morton's play book (I see you Cc'd
him, I forgot to). It's one of these patches of "It's so bad that the
owner of the code will fix the issue out of fear that this patch may
make it in".


> 
> It can even live in the bcache code if we want since there currently
> wouldn't be any other users, I don't really care. But open coding it?
> Come on... makes me wonder what other code in the kernel is open coding
> locks because it couldn't release it in the same process context that
> took the lock for whatever reason.

Most cases just have completions. This looks like a case where "don't
do something while transaction is taking place". Which can usually get
away with a wait event.

> 
> Also, nack this patch because increasing the number of atomic ops to
> shared cachelines in our fast path. If it does end up being open coded,
> I'll make a more efficient version.

Perhaps I can whip up a "struct rwsem_non_owner" and have a very
limited API for that, and then you can use that.

Thanks,

-- Steve
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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 tip/core/rcu 1/5] rcu: Add duplicate-callback tests to rcutorture

[Lai Jiangshan]

On 08/21/2013 02:38 AM, Paul E. McKenney wrote:
> On Tue, Aug 20, 2013 at 06:02:39PM +0800, Lai Jiangshan wrote:
>> On 08/20/2013 10:51 AM, Paul E. McKenney wrote:
>>> From: "Paul E. McKenney" 
>>>
>>> This commit adds a object_debug option to rcutorture to allow the
>>> debug-object-based checks for duplicate call_rcu() invocations to
>>> be deterministically tested.
>>>
>>> Signed-off-by: Paul E. McKenney 
>>> Cc: Mathieu Desnoyers 
>>> Cc: Sedat Dilek 
>>> Cc: Davidlohr Bueso 
>>> Cc: Rik van Riel 
>>> Cc: Thomas Gleixner 
>>> Cc: Linus Torvalds 
>>> Tested-by: Sedat Dilek 
>>> [ paulmck: Banish mid-function ifdef, more or less per Josh Triplett. ]
>>> ---
>>>  kernel/rcutorture.c | 45 +
>>>  1 file changed, 45 insertions(+)
>>>
>>> diff --git a/kernel/rcutorture.c b/kernel/rcutorture.c
>>> index 3d936f0f..f5cf2bb 100644
>>> --- a/kernel/rcutorture.c
>>> +++ b/kernel/rcutorture.c
>>> @@ -66,6 +66,7 @@ static int fqs_duration;  /* Duration of bursts (us), 0 
>>> to disable. */
>>>  static int fqs_holdoff;/* Hold time within burst (us). */
>>>  static int fqs_stutter = 3;/* Wait time between bursts (s). */
>>>  static int n_barrier_cbs;  /* Number of callbacks to test RCU barriers. */
>>> +static int object_debug;   /* Test object-debug double call_rcu()?. */
>>>  static int onoff_interval; /* Wait time between CPU hotplugs, 0=disable. */
>>>  static int onoff_holdoff;  /* Seconds after boot before CPU hotplugs. */
>>>  static int shutdown_secs;  /* Shutdown time (s).  <=0 for no shutdown. */
>>> @@ -100,6 +101,8 @@ module_param(fqs_stutter, int, 0444);
>>>  MODULE_PARM_DESC(fqs_stutter, "Wait time between fqs bursts (s)");
>>>  module_param(n_barrier_cbs, int, 0444);
>>>  MODULE_PARM_DESC(n_barrier_cbs, "# of callbacks/kthreads for barrier 
>>> testing");
>>> +module_param(object_debug, int, 0444);
>>> +MODULE_PARM_DESC(object_debug, "Enable debug-object double call_rcu() 
>>> testing");
>>>  module_param(onoff_interval, int, 0444);
>>>  MODULE_PARM_DESC(onoff_interval, "Time between CPU hotplugs (s), 
>>> 0=disable");
>>>  module_param(onoff_holdoff, int, 0444);
>>> @@ -1934,6 +1937,46 @@ rcu_torture_cleanup(void)
>>> rcu_torture_print_module_parms(cur_ops, "End of test: SUCCESS");
>>>  }
>>>  
>>> +#ifdef CONFIG_DEBUG_OBJECTS_RCU_HEAD
>>> +static void rcu_torture_leak_cb(struct rcu_head *rhp)
>>> +{
>>> +}
>>> +
>>> +static void rcu_torture_err_cb(struct rcu_head *rhp)
>>> +{
>>> +   /* This -might- happen due to race conditions, but is unlikely. */
>>> +   pr_alert("rcutorture: duplicated callback was invoked.\n");
>>> +}
>>> +#endif /* #ifdef CONFIG_DEBUG_OBJECTS_RCU_HEAD */
>>> +
>>> +/*
>>> + * Verify that double-free causes debug-objects to complain, but only
>>> + * if CONFIG_DEBUG_OBJECTS_RCU_HEAD=y.  Otherwise, say that the test
>>> + * cannot be carried out.
>>> + */
>>> +static void rcu_test_debug_objects(void)
>>> +{
>>> +#ifdef CONFIG_DEBUG_OBJECTS_RCU_HEAD
>>> +   struct rcu_head rh1;
>>> +   struct rcu_head rh2;
>>> +
>>> +   init_rcu_head_on_stack();
>>> +   init_rcu_head_on_stack();
>>> +   pr_alert("rcutorture: WARN: Duplicate call_rcu() test starting.\n");
>>> +   local_irq_disable(); /* Make it hard to finish grace period. */
>>
>> you can use rcu_read_lock() directly.
> 
> I could do that as well, but it doesn't do everything that local_irq_disable()
> does.
> 
> Right, which means that my comment is bad.  Fixing both, thank you!
> 
>>> +   call_rcu(, rcu_torture_leak_cb); /* start grace period. */
> 
> And the one above cannot start a grace period due to irqs being enabled.
> Which is -almost- always OK, but...
> 
>>> +   call_rcu(, rcu_torture_err_cb);
> 
> And this one should invoke rcu_torture_leak_cb instead of
> rcu_torture_err_cb().  Just results in a confusing error message, but...

I still don't understand why rcu_torture_err_cb() will be called when:

rcu_read_lock();
call_rcu(, rcu_torture_leak_cb);
call_rcu(, rcu_torture_err_cb); // rh2 will be still queued here,
// debug-objects will find it and
// change it to rcu_leak_callback()
rcu_read_unlock();

> 
> OK, a few more fixes, then!
> 
>>> +   call_rcu(, rcu_torture_err_cb); /* duplicate callback. */
>>> +   local_irq_enable();
>>> +   rcu_barrier();
>>> +   pr_alert("rcutorture: WARN: Duplicate call_rcu() test complete.\n");
>>> +   destroy_rcu_head_on_stack();
>>> +   destroy_rcu_head_on_stack();
>>> +#else /* #ifdef CONFIG_DEBUG_OBJECTS_RCU_HEAD */
>>> +   pr_alert("rcutorture: !CONFIG_DEBUG_OBJECTS_RCU_HEAD, not testing 
>>> duplicate call_rcu()\n");
>>> +#endif /* #else #ifdef CONFIG_DEBUG_OBJECTS_RCU_HEAD */
>>> +}
> 
> The result is as follows.  Better?
> 
>   Thanx, Paul
> 
> #ifdef CONFIG_DEBUG_OBJECTS_RCU_HEAD
> static void rcu_torture_leak_cb(struct rcu_head *rhp)
> {
> }
> 
> static void 

Re: [PATCH] idr: Use this_cpu_ptr() for percpu_ida

[Kent Overstreet]

On Tue, Aug 20, 2013 at 10:07:42PM -0400, Tejun Heo wrote:
> Hello, Kent.
> 
> On Tue, Aug 20, 2013 at 07:01:32PM -0700, Kent Overstreet wrote:
> > I think Tejun and I might be at a bit of an impasse with the ida rewrite
> > itself, but I don't think there were any outstanding objections to the
> > percpu ida code itself - and this is a standalone version.
> 
> The percpu ida code can be applied separately from the ida rewrite?

Yes - at the cost of using significantly more memory for the global
freelist

> > I was meaning to ask you Andrew, if you could take a look at the ida
> > discussion and lend your opinion - I don't think there's any _specific_
> > technical objections left to my ida code, and it's now on a more
> > philisophical "complexity vs. ..." level.
> 
> Hmmm... the objection was pretty specific - don't depend on high-order
> or vmalloc allocations when it can be easily avoided by using proper
> radix tree.

We only do vmalloc allocations for CONFIG_COMPACTION=n, and then only
when we need to allocate more than almost 1 _billion_ ids from a single
ida (twice than on 32 bit, so never because that gets us just about to
INT_MAX) - and then it's only 32k of vmalloc memory, for the entire ida.

This is with max allocation order of 4 for COMPACTION=y, 2 for
COMPACTION=n. 

All this for a performance improvement of 10x to 50x (or more), for the
ida sizes I measured.

So I could see your point if we were allocating gobs of vmalloc memory,
or high order allocations big enough to realistically be problematic (I
honestly don't think these will be) - but to me, this seems like a
pretty reasonable tradeoff for those performance gains.

(And the performance gains do substantially come from using more
contiguous memory and treating the whole data structure as an array, and
doing less pointer chasing/looping)
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH 1/3] fs/proc/task_mmu.c: check the return value of mpol_to_str()

[Chen Gang]

mpol_to_str() may fail, and not fill the buffer (e.g. -EINVAL), so need
check about it, or buffer may not be zero based, and next seq_printf()
will cause issue.

The failure return need after mpol_cond_put() to match get_vma_policy().


Signed-off-by: Chen Gang 
Cc: Cyrill Gorcunov 
---
 fs/proc/task_mmu.c |4 +++-
 1 files changed, 3 insertions(+), 1 deletions(-)

diff --git a/fs/proc/task_mmu.c b/fs/proc/task_mmu.c
index 107d026..d87f5da 100644
--- a/fs/proc/task_mmu.c
+++ b/fs/proc/task_mmu.c
@@ -1376,8 +1376,10 @@ static int show_numa_map(struct seq_file *m, void *v, 
int is_pid)
walk.mm = mm;
 
pol = get_vma_policy(task, vma, vma->vm_start);
-   mpol_to_str(buffer, sizeof(buffer), pol);
+   n = mpol_to_str(buffer, sizeof(buffer), pol);
mpol_cond_put(pol);
+   if (n < 0)
+   return n;
 
seq_printf(m, "%08lx %s", vma->vm_start, buffer);
 
-- 
1.7.7.6
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] pinctrl: rockchip: Simplify for loop iteration

[Axel Lin]

Just return once a match found makes the code simpler and shorter.

Signed-off-by: Axel Lin 
---
 drivers/pinctrl/pinctrl-rockchip.c | 21 ++---
 1 file changed, 6 insertions(+), 15 deletions(-)

diff --git a/drivers/pinctrl/pinctrl-rockchip.c 
b/drivers/pinctrl/pinctrl-rockchip.c
index c22457d..64ad0c0 100644
--- a/drivers/pinctrl/pinctrl-rockchip.c
+++ b/drivers/pinctrl/pinctrl-rockchip.c
@@ -167,18 +167,14 @@ static const inline struct rockchip_pin_group 
*pinctrl_name_to_group(
const struct rockchip_pinctrl *info,
const char *name)
 {
-   const struct rockchip_pin_group *grp = NULL;
int i;
 
for (i = 0; i < info->ngroups; i++) {
-   if (strcmp(info->groups[i].name, name))
-   continue;
-
-   grp = >groups[i];
-   break;
+   if (!strcmp(info->groups[i].name, name))
+   return >groups[i];
}
 
-   return grp;
+   return NULL;
 }
 
 /*
@@ -204,17 +200,12 @@ static struct rockchip_pin_bank *bank_num_to_bank(
struct rockchip_pin_bank *b = info->ctrl->pin_banks;
int i;
 
-   for (i = 0; i < info->ctrl->nr_banks; i++) {
+   for (i = 0; i < info->ctrl->nr_banks; i++, b++) {
if (b->bank_num == num)
-   break;
-
-   b++;
+   return b;
}
 
-   if (b->bank_num != num)
-   return ERR_PTR(-EINVAL);
-
-   return b;
+   return ERR_PTR(-EINVAL);
 }
 
 /*
-- 
1.8.1.2



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

Re: [PATCH] kernel/module.c: use scnprintf() instead of sprintf()

[Chen Gang]

On 08/20/2013 02:04 PM, Rusty Russell wrote:
> Chen Gang  writes:
> 
>> For some strings, they are permitted to be larger than PAGE_SIZE, so
>> need use scnprintf() instead of sprintf(), or it will cause issue.
>>
>> One case is:
>>
>>   if a module version is crazy defined (length more than PAGE_SIZE),
>>   'modinfo' command is still OK (print full contents),
>>   but for "cat /sys/modules/'modname'/version", will cause issue in kernel.
> 
> Applied!
> 

Thanks.

> Thanks,
> Rusty.
> 
>>
>> Signed-off-by: Chen Gang 
>> ---
>>  kernel/module.c |2 +-
>>  1 files changed, 1 insertions(+), 1 deletions(-)
>>
>> diff --git a/kernel/module.c b/kernel/module.c
>> index 2069158..0618e63 100644
>> --- a/kernel/module.c
>> +++ b/kernel/module.c
>> @@ -603,7 +603,7 @@ static void setup_modinfo_##field(struct module *mod, 
>> const char *s)  \
>>  static ssize_t show_modinfo_##field(struct module_attribute *mattr,   \
>>  struct module_kobject *mk, char *buffer)  \
>>  { \
>> -return sprintf(buffer, "%s\n", mk->mod->field);   \
>> +return scnprintf(buffer, PAGE_SIZE, "%s\n", mk->mod->field);  \
>>  } \
>>  static int modinfo_##field##_exists(struct module *mod)   \
>>  { \
>> -- 
>> 1.7.7.6
>> --
>> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
>> the body of a message to majord...@vger.kernel.org
>> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>> Please read the FAQ at  http://www.tux.org/lkml/
> 
> 


-- 
Chen Gang
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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/3] mm/shmem.c: let shmem_show_mpol() return value.

[Chen Gang]

Let shmem_show_mpol() return value, since it may fail.

Signed-off-by: Chen Gang 
Cc: Cyrill Gorcunov 
---
 mm/shmem.c |   11 ++-
 1 files changed, 6 insertions(+), 5 deletions(-)

diff --git a/mm/shmem.c b/mm/shmem.c
index 75010ba..e59d332 100644
--- a/mm/shmem.c
+++ b/mm/shmem.c
@@ -883,16 +883,17 @@ redirty:
 
 #ifdef CONFIG_NUMA
 #ifdef CONFIG_TMPFS
-static void shmem_show_mpol(struct seq_file *seq, struct mempolicy *mpol)
+static int shmem_show_mpol(struct seq_file *seq, struct mempolicy *mpol)
 {
char buffer[64];
 
if (!mpol || mpol->mode == MPOL_DEFAULT)
-   return; /* show nothing */
+   return 0;   /* show nothing */
 
mpol_to_str(buffer, sizeof(buffer), mpol);
 
seq_printf(seq, ",mpol=%s", buffer);
+   return 0;
 }
 
 static struct mempolicy *shmem_get_sbmpol(struct shmem_sb_info *sbinfo)
@@ -951,8 +952,9 @@ static struct page *shmem_alloc_page(gfp_t gfp,
 }
 #else /* !CONFIG_NUMA */
 #ifdef CONFIG_TMPFS
-static inline void shmem_show_mpol(struct seq_file *seq, struct mempolicy 
*mpol)
+static inline int shmem_show_mpol(struct seq_file *seq, struct mempolicy *mpol)
 {
+   return 0;
 }
 #endif /* CONFIG_TMPFS */
 
@@ -2578,8 +2580,7 @@ static int shmem_show_options(struct seq_file *seq, 
struct dentry *root)
if (!gid_eq(sbinfo->gid, GLOBAL_ROOT_GID))
seq_printf(seq, ",gid=%u",
from_kgid_munged(_user_ns, sbinfo->gid));
-   shmem_show_mpol(seq, sbinfo->mpol);
-   return 0;
+   return shmem_show_mpol(seq, sbinfo->mpol);
 }
 #endif /* CONFIG_TMPFS */
 
-- 
1.7.7.6
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[Device-tree] mailing list responsiveness and discoverability

[Brian Norris]

Hello device tree maintainers,

I (sub)maintain the Linux MTD subsystem and hang out on the
linux-...@infradead.org mailing list. I have been seeing an increasing
number of submissions that involve device-tree changes. Many of these
changes are ill thought out and may even cause ABI breakage.

According to discussions I've seen on LKML, you want to see better
bindings merged into the kernel, and you want to maintain more control
over the acceptance of bindings in general. However, I see a few
problems that have inhibited this.

(1) Mailing list change: it just so happens that you recently moved
your mailing list to @vger.kernel.org. Some people are still CC'ing
the old one (if they CC any DT list at all). I'm not sure what can be
done about this, exactly. Perhaps a forwarding rule + a warning
response would have been better for a transition period, rather than
just shutting down and rejecting from the old one.

(2) Responsiveness: when we finally do CC devicet...@vger.kernel.org,
I don't see much feedback, even for those which (when I get around to
reviewing them myself) look like they have obvious issues that
device-tree maintainers should care about.

(3) Archives: Archives for devicet...@vger.kernel.org are not easy to
find. I recently subscribed to the mailing list, so general
device-tree activity doesn't get lost in oblivion (to me). But if no
one has done so yet, I'd like to see this mailing list archived on at
least one of gmane (gmane has the old devicetree list and not the new
one.), marc.info (I "devicetree" is this the new one?), etc. and
linked at:

http://vger.kernel.org/vger-lists.html#devicetree

(there are no listed archives as of this email)

Admittedly, (2) is exacerbated by (1) when submitters send to the
wrong address and don't bother correcting and resending, so maybe
discoverability ((1) and (3)) is the only real issue.

Thanks for considering my complaints.

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

[PATCH] cpuset: fix a regression in validating config change

[Li Zefan]

It's not allowed to clear masks of a cpuset if there're tasks in it,
but it's broken:

  # mkdir /cgroup/sub
  # echo 0 > /cgroup/sub/cpuset.cpus
  # echo 0 > /cgroup/sub/cpuset.mems
  # echo $$ > /cgroup/sub/tasks
  # echo > /cgroup/sub/cpuset.cpus
  (should fail)

This bug was introduced by commit 88fa523bff295f1d60244a54833480b02f775152
("cpuset: allow to move tasks to empty cpusets").

Signed-off-by: Li Zefan 
---
 kernel/cpuset.c | 11 ---
 1 file changed, 8 insertions(+), 3 deletions(-)

diff --git a/kernel/cpuset.c b/kernel/cpuset.c
index 0b5b9a3..70ab3fd 100644
--- a/kernel/cpuset.c
+++ b/kernel/cpuset.c
@@ -425,6 +425,8 @@ static int validate_change(struct cpuset *cur, struct 
cpuset *trial)
struct cgroup_subsys_state *css;
struct cpuset *c, *par;
int ret;
+   bool make_cpus_empty;
+   bool make_mems_empty;
 
rcu_read_lock();
 
@@ -464,12 +466,15 @@ static int validate_change(struct cpuset *cur, struct 
cpuset *trial)
 
/*
 * Cpusets with tasks - existing or newly being attached - can't
-* have empty cpus_allowed or mems_allowed.
+* be changed to have empty cpus_allowed or mems_allowed.
 */
ret = -ENOSPC;
+   make_cpus_empty = !cpumask_empty(cur->cpus_allowed) &&
+ cpumask_empty(trial->cpus_allowed);
+   make_mems_empty = !nodes_empty(cur->mems_allowed) &&
+ nodes_empty(trial->mems_allowed);
if ((cgroup_task_count(cur->css.cgroup) || cur->attach_in_progress) &&
-   (cpumask_empty(trial->cpus_allowed) &&
-nodes_empty(trial->mems_allowed)))
+   (make_cpus_empty || make_mems_empty))
goto out;
 
ret = 0;
-- 
1.8.0.2
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH 0/3] mm: shmem: check the return value of mpol_to_str()

[Chen Gang]

mpol_to_str() may fail, and not fill the buffer (e.g. -EINVAL), so need
check about it, or buffer may not be zero based, and next seq_printf()
will cause issue.

Signed-off-by: Chen Gang 
Cc: Cyrill Gorcunov 
---
 fs/proc/task_mmu.c |4 +++-
 mm/shmem.c |   16 ++--
 2 files changed, 13 insertions(+), 7 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 04/10] sched, fair: Shrink sg_lb_stats and play memset games

[Joonsoo Kim]

On Wed, Aug 21, 2013 at 11:08:29AM +0900, Joonsoo Kim wrote:
> On Mon, Aug 19, 2013 at 06:01:02PM +0200, Peter Zijlstra wrote:
> > +static inline void init_sd_lb_stats(struct sd_lb_stats *sds)
> > +{
> > +   /*
> > +* struct sd_lb_stats {
> > +* struct sched_group *   busiest; // 0  8
> > +* struct sched_group *   this;// 8  8
> > +* long unsigned int  total_load;  //16  8
> > +* long unsigned int  total_pwr;   //24  8
> > +* long unsigned int  avg_load;//32  8
> > +* struct sg_lb_stats {
> > +* long unsigned int  avg_load;//40  8
> > +* long unsigned int  group_load;  //48  8
> > +* ...
> > +* } busiest_stat; //40 56
> > +* struct sg_lb_stats this_stat;   //96 56
> > +*
> > +* // size: 152, cachelines: 3, members: 7
> > +* // last cacheline: 24 bytes
> > +* };
> > +*
> > +* Skimp on the clearing to avoid duplicate work. We can avoid clearing
> > +* this_stat because update_sg_lb_stats() does a full clear/assignment.
> > +* We must however clear busiest_stat::avg_load because
> > +* update_sd_pick_busiest() reads this before assignment.
> > +*/
> > +   memset(sds, 0, offsetof(struct sd_lb_stats, busiest_stat.group_load));
> 
> Hello, Peter.
> 
> IMHO, this is so tricky.
> With below change, we can simply do 'offsetof(struct sd_lb_stats, 
> busiest_stat)'.
> 
> @@ -4546,7 +4546,7 @@ static bool update_sd_pick_busiest(struct lb_env *env,
>struct sched_group *sg,
>struct sg_lb_stats *sgs)
>  {
> -   if (sgs->avg_load <= sds->busiest_stat.avg_load)
> +   if (!sds->busiest && sgs->avg_load <= sds->busiest_stat.avg_load)
> return false;
>  
> if (sgs->sum_nr_running > sgs->group_capacity)
> 

Sorry, instead of !sds->busiest, it should be sds->busiest. :)

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] bcache: Remove use of down/up_read_non_owner()

[Kent Overstreet]

On Tue, Aug 20, 2013 at 11:16:02AM -0400, Steven Rostedt wrote:
> 
> The down/up_read_non_owner() is a nasty hack in the API of the rwsem
> operations. It was once removed, but then resurrected for use with
> bcache. Not only is the API an abomination to the rwsem API, it also
> prevents bcache from ever being compiled with PREEMPT_RT, as the RT
> kernel requires all rwsems to have an owner.
> 
> Instead of keeping the down/up_read_non_owner() around, it is better to
> modify the one user of it and have it do something a bit differently.
> 
> From reading the bcache code, the reason for the non_owner usage is
> that a request is made, and writers must wait for that request to
> finish before they can continue. But because the request is completed
> by another task, the rwsem can not be held for read and then released
> on completion.
> 
> Instead of abusing the rwsem code for this, I added a refcount
> "nr_requests" to the cached_dev structure as well as a "write_waiters"
> wait queue. When a request is to be made, the rwsem is still taken for
> read, but this time with an owner. The refcount is incremented and
> before exiting the function, the rwsem is released.
> 
> The writer will then take the rwsem for write, check the refcount, if
> it is not zero, it will release the rwsem, add itself to a wait_event()
> waiting for refcount to become zero, and then try again.

I _really_ disagree with this approach.

I get that there's a problem, but the bcache code REALLY IS USING THE
RWSEM AS A LOCK; the answer isn't to open code the lock!

Apologies to Christoph for getting distracted and not responding when
you started to explain what the issues were for RT. I'm not really
convinced they're that insurmountable (one of the issues was debugging,
which the _non_owner() stuff always handled just fine), but I'll take it
on faith that this usage is incompatible with rwsems + the RT
functionality since I haven't actually had time to dig into it.

So assuming that's the case, IMO the sanest thing to do is make a new
type of lock - "rwsem_non_process" or somesuch - and use _that_ in
bcache. Not open coding the lock.

It can even live in the bcache code if we want since there currently
wouldn't be any other users, I don't really care. But open coding it?
Come on... makes me wonder what other code in the kernel is open coding
locks because it couldn't release it in the same process context that
took the lock for whatever reason.

Also, nack this patch because increasing the number of atomic ops to
shared cachelines in our fast path. If it does end up being open coded,
I'll make a more efficient version.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 00/10] Various load-balance cleanups/optimizations -v2

[Joonsoo Kim]

On Mon, Aug 19, 2013 at 06:00:58PM +0200, Peter Zijlstra wrote:
> 
> After poking at them a little more I feel somewhat more confident.
> 
> I found one more bug, but this one was my own fault, we should also clear
> sds->busiest_stat.avg_load because update_sd_pick_busiest() reads that before
> we set it.
> 
> Moved the memset optimization and the fix for that into a separate patch.
> 
> Other than that, there's a sched_domain degenerate fix; and a new way to 
> detect
> group_imb (which relies on the sched_domain fix).

I'm fine to my patches with your changes.

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] LMK: Optimize lowmem_shrink

[Ma, Xindong]

> -Original Message-
> From: Dan Carpenter [mailto:dan.carpen...@oracle.com]
> Sent: Tuesday, August 20, 2013 4:30 PM
> To: Ma, Xindong
> Cc: gre...@linuxfoundation.org; ccr...@android.com;
> de...@driverdev.osuosl.org; linux-kernel@vger.kernel.org
> Subject: Re: [PATCH] LMK: Optimize lowmem_shrink
> 
> On Tue, Aug 20, 2013 at 09:16:33AM +0800, Leon Ma wrote:
> > From: Leon Ma 
> > Date: Mon, 19 Aug 2013 14:22:38 +0800
> > Subject: [PATCH] LMK: Optimize lowmem_shrink.
> >
> > By comparing with selected_oom_score_adj instead of min_score_adj, we
> > may do less calculation.
> >
> 
> The patch is line wrapped and doesn't apply.
> Read Documentation/email-clients.txt.  Send it to yourself first.
> Save the whole email as raw text (including headers and everything).
> cat email.txt | git am.
> When that works, then resend.
Sorry for the trouble. I forgot to click "Prefomatted" in Evolution. I've 
resend the patch
https://lkml.org/lkml/2013/8/20/754
Please have a review.
> 
> regards,
> dan carpenter

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

Re: [PATCH 04/10] sched, fair: Shrink sg_lb_stats and play memset games

[Joonsoo Kim]

On Mon, Aug 19, 2013 at 06:01:02PM +0200, Peter Zijlstra wrote:
> +static inline void init_sd_lb_stats(struct sd_lb_stats *sds)
> +{
> + /*
> +  * struct sd_lb_stats {
> +  * struct sched_group *   busiest; // 0  8
> +  * struct sched_group *   this;// 8  8
> +  * long unsigned int  total_load;  //16  8
> +  * long unsigned int  total_pwr;   //24  8
> +  * long unsigned int  avg_load;//32  8
> +  * struct sg_lb_stats {
> +  * long unsigned int  avg_load;//40  8
> +  * long unsigned int  group_load;  //48  8
> +  * ...
> +  * } busiest_stat; //40 56
> +  * struct sg_lb_stats this_stat;   //96 56
> +  *
> +  * // size: 152, cachelines: 3, members: 7
> +  * // last cacheline: 24 bytes
> +  * };
> +  *
> +  * Skimp on the clearing to avoid duplicate work. We can avoid clearing
> +  * this_stat because update_sg_lb_stats() does a full clear/assignment.
> +  * We must however clear busiest_stat::avg_load because
> +  * update_sd_pick_busiest() reads this before assignment.
> +  */
> + memset(sds, 0, offsetof(struct sd_lb_stats, busiest_stat.group_load));

Hello, Peter.

IMHO, this is so tricky.
With below change, we can simply do 'offsetof(struct sd_lb_stats, 
busiest_stat)'.

@@ -4546,7 +4546,7 @@ static bool update_sd_pick_busiest(struct lb_env *env,
   struct sched_group *sg,
   struct sg_lb_stats *sgs)
 {
-   if (sgs->avg_load <= sds->busiest_stat.avg_load)
+   if (!sds->busiest && sgs->avg_load <= sds->busiest_stat.avg_load)
return false;
 
if (sgs->sum_nr_running > sgs->group_capacity)

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] idr: Use this_cpu_ptr() for percpu_ida

[Tejun Heo]

Hello, Kent.

On Tue, Aug 20, 2013 at 07:01:32PM -0700, Kent Overstreet wrote:
> I think Tejun and I might be at a bit of an impasse with the ida rewrite
> itself, but I don't think there were any outstanding objections to the
> percpu ida code itself - and this is a standalone version.

The percpu ida code can be applied separately from the ida rewrite?

> I was meaning to ask you Andrew, if you could take a look at the ida
> discussion and lend your opinion - I don't think there's any _specific_
> technical objections left to my ida code, and it's now on a more
> philisophical "complexity vs. ..." level.

Hmmm... the objection was pretty specific - don't depend on high-order
or vmalloc allocations when it can be easily avoided by using proper
radix tree.

Thanks.

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

Re: [PATCH] kernel/params.c: use scnprintf() instead of sprintf()

[Chen Gang]

On 08/20/2013 02:05 PM, Rusty Russell wrote:
> Chen Gang  writes:
> 
>> For some strings (e.g. version string), they are permitted to be larger
>> than PAGE_SIZE (although meaningless), so recommend to use scnprintf()
>> instead of sprintf().
> 
> Applied.
> 

Thanks.

> Thanks,
> Rusty.
> 
>>
>> Signed-off-by: Chen Gang 
>> ---
>>  kernel/params.c |7 ---
>>  1 files changed, 4 insertions(+), 3 deletions(-)
>>
>> diff --git a/kernel/params.c b/kernel/params.c
>> index 1f228a3..4da300f 100644
>> --- a/kernel/params.c
>> +++ b/kernel/params.c
>> @@ -241,7 +241,8 @@ int parse_args(const char *doing,
>>  }   \
>>  int param_get_##name(char *buffer, const struct kernel_param *kp) \
>>  {   \
>> -return sprintf(buffer, format, *((type *)kp->arg)); \
>> +return scnprintf(buffer, PAGE_SIZE, format, \
>> +*((type *)kp->arg));\
>>  }   \
>>  struct kernel_param_ops param_ops_##name = {\
>>  .set = param_set_##name,\
>> @@ -285,7 +286,7 @@ EXPORT_SYMBOL(param_set_charp);
>>  
>>  int param_get_charp(char *buffer, const struct kernel_param *kp)
>>  {
>> -return sprintf(buffer, "%s", *((char **)kp->arg));
>> +return scnprintf(buffer, PAGE_SIZE, "%s", *((char **)kp->arg));
>>  }
>>  EXPORT_SYMBOL(param_get_charp);
>>  
>> @@ -827,7 +828,7 @@ ssize_t __modver_version_show(struct module_attribute 
>> *mattr,
>>  struct module_version_attribute *vattr =
>>  container_of(mattr, struct module_version_attribute, mattr);
>>  
>> -return sprintf(buf, "%s\n", vattr->version);
>> +return scnprintf(buf, PAGE_SIZE, "%s\n", vattr->version);
>>  }
>>  
>>  extern const struct module_version_attribute *__start___modver[];
>> -- 
>> 1.7.7.6
> 
> 


-- 
Chen Gang
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] idr: Use this_cpu_ptr() for percpu_ida

[Kent Overstreet]

On Tue, Aug 20, 2013 at 02:29:56PM -0700, Andrew Morton wrote:
> On Tue, 20 Aug 2013 14:19:06 -0700 "Nicholas A. Bellinger" 
>  wrote:
> 
> > On Thu, 2013-08-08 at 14:32 +, Christoph Lameter wrote:
> > > On Wed, 7 Aug 2013, Kent Overstreet wrote:
> > > 
> > > > One thing that was bugging me - I was never able to figure out for sure
> > > > if smp_processor_id() returns a number in the range [0, nr_cpu_ids), at
> > > > least I couldn't find where it was documented - could you tell me if
> > > > that's true?
> > > 
> > > I always assumed that it was in the range 0 ... nr_cpu_ids - 1 and that is
> > > the assumption under which the kernel code was written. Things would break
> > > horribly if smp_process_id would return nr_cpu_ids or higher.
> > > 
> > 
> > Hi guys,
> > 
> > Just a heads up that I've put Kent's standalone percpu-ida patch (with
> > Christoph's recommend changes) into target-pending/for-next here:
> > 
> > https://git.kernel.org/cgit/linux/kernel/git/nab/target-pending.git/commit/?h=for-next=47bd524a5b3eb6429b058b8b562b45329ab2c9e7
> > 
> > I've got a number of target patches that depend on this code for v3.12,
> > and a delay on this particular piece would be painful to endure..
> > 
> > Sooo, please yell loudly if there is an objection to percpu-ida merge as
> > a completely standalone item, that does not effect any existing ida
> > code.
> 
> Was hoping that Tejun had time.  I'll take a look...

I think Tejun and I might be at a bit of an impasse with the ida rewrite
itself, but I don't think there were any outstanding objections to the
percpu ida code itself - and this is a standalone version.

I was meaning to ask you Andrew, if you could take a look at the ida
discussion and lend your opinion - I don't think there's any _specific_
technical objections left to my ida code, and it's now on a more
philisophical "complexity vs. ..." level.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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 0/3] refactor some ldb related clocks

[Shawn Guo]

Hi Ying,

On Tue, Aug 20, 2013 at 06:08:48PM +0800, Liu Ying wrote:
> > While I admit to having introduced the combination of 1/3.5 fixed
> > divider and configurable 1/1,1/2 divder clocks to describe this
> > fractional divider for the reasons you state, I think the correct
> > solution would be to improve the table divider to support fractional
> > values and get rid of the virtual ldb_di_div_3_5 clocks, not
> > introduce more virtual clocks.
> 
> Yes, it's good to support fractional values for the table divider(not sure if 
> there is any plan for this).
> I see there is something similar in 'include/linux/sh_clk.h'.

Yeah, I agree with Philipp on improving table divider to support
fractional values.  Would you like to work on that?

Shawn

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] reboot: perform warm/cold reset correctly for CF9 type

[Li Fei]

In current implementation for reboot type CF9 and CF9_COND,
warm and cold reset are not differentiated, and both are
performed by writing 0x06 to port 0xCF9 as warm reset. It's not
correct.

This commit will differentiate warm and cold reset, and perform
them correctly as below:
For warm reset, write 0x06 to port 0xCF9;
For cold reset, write 0x0E to port 0xCF9.

From: Liu Chuansheng 
Signed-off-by: Li Fei 
---
 arch/x86/kernel/reboot.c |9 +++--
 1 files changed, 7 insertions(+), 2 deletions(-)

diff --git a/arch/x86/kernel/reboot.c b/arch/x86/kernel/reboot.c
index 563ed91..6e06299 100644
--- a/arch/x86/kernel/reboot.c
+++ b/arch/x86/kernel/reboot.c
@@ -511,10 +511,15 @@ static void native_machine_emergency_restart(void)
 
case BOOT_CF9_COND:
if (port_cf9_safe) {
-   u8 cf9 = inb(0xcf9) & ~6;
+   u8 cf9 = inb(0xcf9) &
+   ~(reboot_mode == REBOOT_WARM ?
+   0x06 : 0x0E);
outb(cf9|2, 0xcf9); /* Request hard reset */
udelay(50);
-   outb(cf9|6, 0xcf9); /* Actually do the reset */
+   /* Actually do the reset */
+   outb(cf9|(reboot_mode == REBOOT_WARM ?
+   0x06 : 0x0E),
+   0xcf9);
udelay(50);
}
reboot_type = BOOT_KBD;
-- 
1.7.4.1



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

[PATCH 3/3] mmc:memstick:rtsx: Modify copyright comments

[wei_wang]

From: Wei WANG 

Update copyright date, and remove author address.

Signed-off-by: Wei WANG 
---
 drivers/memstick/host/rtsx_pci_ms.c |3 +--
 drivers/mmc/host/rtsx_pci_sdmmc.c   |3 +--
 2 files changed, 2 insertions(+), 4 deletions(-)

diff --git a/drivers/memstick/host/rtsx_pci_ms.c 
b/drivers/memstick/host/rtsx_pci_ms.c
index 64a779c..cf8bd72 100644
--- a/drivers/memstick/host/rtsx_pci_ms.c
+++ b/drivers/memstick/host/rtsx_pci_ms.c
@@ -1,6 +1,6 @@
 /* Realtek PCI-Express Memstick Card Interface driver
  *
- * Copyright(c) 2009 Realtek Semiconductor Corp. All rights reserved.
+ * Copyright(c) 2009-2013 Realtek Semiconductor Corp. All rights reserved.
  *
  * This program is free software; you can redistribute it and/or modify it
  * under the terms of the GNU General Public License as published by the
@@ -17,7 +17,6 @@
  *
  * Author:
  *   Wei WANG 
- *   No. 450, Shenhu Road, Suzhou Industry Park, Suzhou, China
  */
 
 #include 
diff --git a/drivers/mmc/host/rtsx_pci_sdmmc.c 
b/drivers/mmc/host/rtsx_pci_sdmmc.c
index 0fefe4e..375a880e 100644
--- a/drivers/mmc/host/rtsx_pci_sdmmc.c
+++ b/drivers/mmc/host/rtsx_pci_sdmmc.c
@@ -1,6 +1,6 @@
 /* Realtek PCI-Express SD/MMC Card Interface driver
  *
- * Copyright(c) 2009 Realtek Semiconductor Corp. All rights reserved.
+ * Copyright(c) 2009-2013 Realtek Semiconductor Corp. All rights reserved.
  *
  * This program is free software; you can redistribute it and/or modify it
  * under the terms of the GNU General Public License as published by the
@@ -17,7 +17,6 @@
  *
  * Author:
  *   Wei WANG 
- *   No. 450, Shenhu Road, Suzhou Industry Park, Suzhou, China
  */
 
 #include 
-- 
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] LMK: Optimize lowmem_shrink

[Leon Ma]

From: Leon Ma 
Date: Mon, 19 Aug 2013 14:22:38 +0800
Subject: [PATCH] LMK: Optimize lowmem_shrink.

By comparing with selected_oom_score_adj instead of min_score_adj,
we may do less calculation.

Signed-off-by: Leon Ma 
---
 drivers/staging/android/lowmemorykiller.c |   12 
 1 files changed, 4 insertions(+), 8 deletions(-)

diff --git a/drivers/staging/android/lowmemorykiller.c 
b/drivers/staging/android/lowmemorykiller.c
index f6c05c9..cb944c5 100644
--- a/drivers/staging/android/lowmemorykiller.c
+++ b/drivers/staging/android/lowmemorykiller.c
@@ -126,7 +126,7 @@ static int lowmem_shrink(struct shrinker *s, struct 
shrink_control *sc)
return 0;
}
oom_score_adj = p->signal->oom_score_adj;
-   if (oom_score_adj < min_score_adj) {
+   if (oom_score_adj < selected_oom_score_adj) {
task_unlock(p);
continue;
}
@@ -134,13 +134,9 @@ static int lowmem_shrink(struct shrinker *s, struct 
shrink_control *sc)
task_unlock(p);
if (tasksize <= 0)
continue;
-   if (selected) {
-   if (oom_score_adj < selected_oom_score_adj)
-   continue;
-   if (oom_score_adj == selected_oom_score_adj &&
-   tasksize <= selected_tasksize)
-   continue;
-   }
+   if (selected && oom_score_adj == selected_oom_score_adj &&
+   tasksize <= selected_tasksize)
+   continue;
selected = p;
selected_tasksize = tasksize;
selected_oom_score_adj = oom_score_adj;
-- 
1.7.4.1



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

[PATCH 2/3] mmc:rtsx:Clear SD_CLK toggle enable bit if switching voltage fail

[wei_wang]

From: Wei WANG 

If switching voltage fails, SD_CLK toggle enable bit should been cleared
so that SD host can control SD clock automatically.

Signed-off-by: Wei WANG 
---
 drivers/mmc/host/rtsx_pci_sdmmc.c |9 -
 1 file changed, 8 insertions(+), 1 deletion(-)

diff --git a/drivers/mmc/host/rtsx_pci_sdmmc.c 
b/drivers/mmc/host/rtsx_pci_sdmmc.c
index fcb368e..0fefe4e 100644
--- a/drivers/mmc/host/rtsx_pci_sdmmc.c
+++ b/drivers/mmc/host/rtsx_pci_sdmmc.c
@@ -227,6 +227,7 @@ static void sd_send_cmd_get_rsp(struct realtek_pci_sdmmc 
*host,
int stat_idx = 0;
u8 rsp_type;
int rsp_len = 5;
+   bool clock_toggled = false;
 
dev_dbg(sdmmc_dev(host), "%s: SD/MMC CMD %d, arg = 0x%08x\n",
__func__, cmd_idx, arg);
@@ -270,6 +271,8 @@ static void sd_send_cmd_get_rsp(struct realtek_pci_sdmmc 
*host,
0xFF, SD_CLK_TOGGLE_EN);
if (err < 0)
goto out;
+
+   clock_toggled = true;
}
 
rtsx_pci_init_cmd(pcr);
@@ -350,6 +353,10 @@ static void sd_send_cmd_get_rsp(struct realtek_pci_sdmmc 
*host,
 
 out:
cmd->error = err;
+
+   if (err && clock_toggled)
+   rtsx_pci_write_register(pcr, SD_BUS_STAT,
+   SD_CLK_TOGGLE_EN | SD_CLK_FORCE_STOP, 0);
 }
 
 static int sd_rw_multi(struct realtek_pci_sdmmc *host, struct mmc_request *mrq)
@@ -1121,11 +1128,11 @@ static int sdmmc_switch_voltage(struct mmc_host *mmc, 
struct mmc_ios *ios)
goto out;
}
 
+out:
/* Stop toggle SD clock in idle */
err = rtsx_pci_write_register(pcr, SD_BUS_STAT,
SD_CLK_TOGGLE_EN | SD_CLK_FORCE_STOP, 0);
 
-out:
mutex_unlock(>pcr_mutex);
 
return err;
-- 
1.7.9.5

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

[PATCH 1/3] mfd:mmc:rtsx: Change default tx phase

[wei_wang]

From: Wei WANG 

The default phase can meet most cards' requirement, but it is not the
optimal one. In some extreme situation, the rx phase point produced by
the following tuning process will drift quite a distance.
Before tuning UHS card, this patch will set a more proper initial tx
phase point, which is calculated from statistic data, and can achieve
a much better tx signal quality.

Signed-off-by: Wei WANG 
---
 drivers/mfd/rtl8411.c |4 +++
 drivers/mfd/rts5209.c |2 ++
 drivers/mfd/rts5227.c |2 ++
 drivers/mfd/rts5229.c |2 ++
 drivers/mfd/rts5249.c |2 ++
 drivers/mmc/host/rtsx_pci_sdmmc.c |   58 +++--
 include/linux/mfd/rtsx_pci.h  |   15 ++
 7 files changed, 69 insertions(+), 16 deletions(-)

diff --git a/drivers/mfd/rtl8411.c b/drivers/mfd/rtl8411.c
index e4c1833..5280135 100644
--- a/drivers/mfd/rtl8411.c
+++ b/drivers/mfd/rtl8411.c
@@ -452,6 +452,8 @@ void rtl8411_init_params(struct rtsx_pcr *pcr)
pcr->sd30_drive_sel_1v8 = DRIVER_TYPE_B;
pcr->sd30_drive_sel_3v3 = DRIVER_TYPE_D;
pcr->aspm_en = ASPM_L1_EN;
+   pcr->tx_initial_phase = SET_CLOCK_PHASE(23, 7, 14);
+   pcr->rx_initial_phase = SET_CLOCK_PHASE(4, 3, 10);
 
pcr->ic_version = rtl8411_get_ic_version(pcr);
pcr->sd_pull_ctl_enable_tbl = rtl8411_sd_pull_ctl_enable_tbl;
@@ -471,6 +473,8 @@ void rtl8411b_init_params(struct rtsx_pcr *pcr)
pcr->sd30_drive_sel_1v8 = DRIVER_TYPE_B;
pcr->sd30_drive_sel_3v3 = DRIVER_TYPE_D;
pcr->aspm_en = ASPM_L1_EN;
+   pcr->tx_initial_phase = SET_CLOCK_PHASE(23, 7, 14);
+   pcr->rx_initial_phase = SET_CLOCK_PHASE(4, 3, 10);
 
pcr->ic_version = rtl8411_get_ic_version(pcr);
 
diff --git a/drivers/mfd/rts5209.c b/drivers/mfd/rts5209.c
index 4026e1f..cb04174 100644
--- a/drivers/mfd/rts5209.c
+++ b/drivers/mfd/rts5209.c
@@ -270,6 +270,8 @@ void rts5209_init_params(struct rtsx_pcr *pcr)
pcr->sd30_drive_sel_1v8 = DRIVER_TYPE_B;
pcr->sd30_drive_sel_3v3 = DRIVER_TYPE_D;
pcr->aspm_en = ASPM_L1_EN;
+   pcr->tx_initial_phase = SET_CLOCK_PHASE(27, 27, 16);
+   pcr->rx_initial_phase = SET_CLOCK_PHASE(24, 6, 5);
 
pcr->ic_version = rts5209_get_ic_version(pcr);
pcr->sd_pull_ctl_enable_tbl = rts5209_sd_pull_ctl_enable_tbl;
diff --git a/drivers/mfd/rts5227.c b/drivers/mfd/rts5227.c
index d7cae82..c001151 100644
--- a/drivers/mfd/rts5227.c
+++ b/drivers/mfd/rts5227.c
@@ -291,6 +291,8 @@ void rts5227_init_params(struct rtsx_pcr *pcr)
pcr->sd30_drive_sel_1v8 = CFG_DRIVER_TYPE_B;
pcr->sd30_drive_sel_3v3 = CFG_DRIVER_TYPE_B;
pcr->aspm_en = ASPM_L1_EN;
+   pcr->tx_initial_phase = SET_CLOCK_PHASE(27, 27, 15);
+   pcr->rx_initial_phase = SET_CLOCK_PHASE(30, 7, 7);
 
pcr->sd_pull_ctl_enable_tbl = rts5227_sd_pull_ctl_enable_tbl;
pcr->sd_pull_ctl_disable_tbl = rts5227_sd_pull_ctl_disable_tbl;
diff --git a/drivers/mfd/rts5229.c b/drivers/mfd/rts5229.c
index 620e7fa..6353f5d 100644
--- a/drivers/mfd/rts5229.c
+++ b/drivers/mfd/rts5229.c
@@ -261,6 +261,8 @@ void rts5229_init_params(struct rtsx_pcr *pcr)
pcr->sd30_drive_sel_1v8 = DRIVER_TYPE_B;
pcr->sd30_drive_sel_3v3 = DRIVER_TYPE_D;
pcr->aspm_en = ASPM_L1_EN;
+   pcr->tx_initial_phase = SET_CLOCK_PHASE(27, 27, 15);
+   pcr->rx_initial_phase = SET_CLOCK_PHASE(30, 6, 6);
 
pcr->ic_version = rts5229_get_ic_version(pcr);
if (pcr->ic_version == IC_VER_C) {
diff --git a/drivers/mfd/rts5249.c b/drivers/mfd/rts5249.c
index ea90f8f..3b835f5 100644
--- a/drivers/mfd/rts5249.c
+++ b/drivers/mfd/rts5249.c
@@ -298,6 +298,8 @@ void rts5249_init_params(struct rtsx_pcr *pcr)
pcr->sd30_drive_sel_1v8 = CFG_DRIVER_TYPE_C;
pcr->sd30_drive_sel_3v3 = CFG_DRIVER_TYPE_B;
pcr->aspm_en = ASPM_L1_EN;
+   pcr->tx_initial_phase = SET_CLOCK_PHASE(1, 29, 16);
+   pcr->rx_initial_phase = SET_CLOCK_PHASE(24, 6, 5);
 
pcr->ic_version = rts5249_get_ic_version(pcr);
pcr->sd_pull_ctl_enable_tbl = rts5249_sd_pull_ctl_enable_tbl;
diff --git a/drivers/mmc/host/rtsx_pci_sdmmc.c 
b/drivers/mmc/host/rtsx_pci_sdmmc.c
index 82a35b9..fcb368e 100644
--- a/drivers/mmc/host/rtsx_pci_sdmmc.c
+++ b/drivers/mmc/host/rtsx_pci_sdmmc.c
@@ -56,7 +56,6 @@ struct realtek_pci_sdmmc {
booldouble_clk;
booleject;
boolinitial_mode;
-   boolddr_mode;
int power_state;
 #define SDMMC_POWER_ON 1
 #define SDMMC_POWER_OFF0
@@ -475,18 +474,24 @@ static void sd_normal_rw(struct realtek_pci_sdmmc *host,
kfree(buf);
 }
 
-static int sd_change_phase(struct realtek_pci_sdmmc *host, u8 sample_point)
+static int sd_change_phase(struct realtek_pci_sdmmc *host,
+   u8 sample_point, bool rx)
 {

[PATCH 0/3] Fix sd3.0 issues for Realtek card reader

[wei_wang]

From: Wei WANG 

Wei WANG (3):
  mfd:mmc:rtsx: Change default tx phase
  mmc:rtsx:Clear SD_CLK toggle enable bit if switching voltage fail
  mmc:memstick:rtsx: Modify copyright comments

 drivers/memstick/host/rtsx_pci_ms.c |3 +-
 drivers/mfd/rtl8411.c   |4 ++
 drivers/mfd/rts5209.c   |2 +
 drivers/mfd/rts5227.c   |2 +
 drivers/mfd/rts5229.c   |2 +
 drivers/mfd/rts5249.c   |2 +
 drivers/mmc/host/rtsx_pci_sdmmc.c   |   70 +--
 include/linux/mfd/rtsx_pci.h|   15 
 8 files changed, 79 insertions(+), 21 deletions(-)

-- 
1.7.9.5

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

Re: [PATCH 1/3] ARM: imx6q: refactor some ldb related clocks

[Shawn Guo]

On Tue, Aug 20, 2013 at 02:18:27PM -0700, Mike Turquette wrote:
> Quoting Fabio Estevam (2013-08-20 08:40:52)
> > On Tue, Aug 20, 2013 at 5:38 AM, Liu Ying  wrote:
> > 
> > > diff --git a/Documentation/devicetree/bindings/clock/imx6q-clock.txt 
> > > b/Documentation/devicetree/bindings/clock/imx6q-clock.txt
> > > index 5a90a72..90e923e 100644
> > > --- a/Documentation/devicetree/bindings/clock/imx6q-clock.txt
> > > +++ b/Documentation/devicetree/bindings/clock/imx6q-clock.txt
> > > @@ -89,8 +89,6 @@ clocks and IDs.
> > > gpu3d_shader74
> > > ipu1_podf   75
> > > ipu2_podf   76
> > > -   ldb_di0_podf77
> > > -   ldb_di1_podf78
> > > ipu1_di0_pre79
> > > ipu1_di1_pre80
> > > ipu2_di0_pre81
> > 
> > This causes a 'hole' in the clock numbering scheme: 74, 75, 76, 79, 80, etc
> 
> How does this fit in with the idea of having a stable binding/ABI? Seems
> like changing this would be a bad idea for devices in the field that
> have older DTBs.

We should be safe since none of existing DTBs refers to the clocks (they
are not leaf clocks in the whole clock tree but some interconnection
ones).

Shawn

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

Re: rfc: trivial patches and slow deaths?

[Rob Landley]

On 08/20/2013 07:22:36 PM, Joe Perches wrote:

On Tue, 2013-08-20 at 19:10 -0500, Rob Landley wrote:
> The important question is does he want to handle patches that you're
> flipping out about not going in before the next merge window because
> they are SO IMPORTANT that the trivial tree must promote them out of
> sequence.

You're misreading.  I see no flipping out here.

I'm simply saying that obvious defects should be
corrected sooner rather than later.

I'm also saying that the trivial tree should
have some visibility about whether or not a
patch or series will be handled by the trivial
maintainer or not.


I fetch his git and look at the log of the branch to see which of the  
documentation patches I forwarded are there. That said, there's no  
guarantee they'll go in from there because other maintainers often grab  
them and put them in through their trees.



Jiri has not responded to this point.


He did. Twice.


Silence about the status of patches that extends
for months is not good.


He has a public git tree. It's listed in his MAINTAINERS entry. I've  
found that if a patch isn't in there, he hasn't picked it up yet. (I've  
been feeding Documentation patches through his tree, hence my interest  
in this thread.)


Rob--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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 3/5] mm: Notify filesystems when it's time to apply a deferred cmtime update

[Dave Chinner]

On Tue, Aug 20, 2013 at 05:47:10PM -0700, Andy Lutomirski wrote:
> On Tue, Aug 20, 2013 at 3:43 PM, Dave Chinner  wrote:
> > On Tue, Aug 20, 2013 at 02:54:01PM -0700, Andy Lutomirski wrote:
> >> On Tue, Aug 20, 2013 at 2:48 PM, Dave Chinner  wrote:
> >> > On Tue, Aug 20, 2013 at 09:42:34AM -0700, Andy Lutomirski wrote:
> >> >> On Tue, Aug 20, 2013 at 9:00 AM, Jan Kara  wrote:
> >> >> > On Mon 19-08-13 21:14:44, Andy Lutomirski wrote:
> >> >> >> >> I could require ->writepages *and* ->flush_cmtime to handle the 
> >> >> >> >> time
> >> >> >> >> update, but that would complicate non-transactional filesystems.
> >> >> >> >> Those filesystems should just flush cmtime at the end of 
> >> >> >> >> writepages.
> >> >> >> >
> >> >> >> > do_writepages() is the wrong place to do such updates - we can get
> >> >> >> > writeback directly through .writepage, so the time updates need to
> >> >> >> > be in .writepage. That first .writepage call will clear the bit on
> >> >> >> > the mapping, so it's only done on the first call to .writepage on
> >> >> >> > the given mapping.
> >> >> >>
> >> >> >> Last time I checked, all the paths that actually needed the timestamp
> >> >> >> update went through .writepages.  I'll double-check.
> >> >> >   kswapd can call just .writepage to do the writeout so timestamp 
> >> >> > update
> >> >> > should be handled there as well. Otherwise all pages in a mapping can 
> >> >> > be
> >> >> > cleaned without timestamp being updated.
> >> >>
> >> >> OK, I'll fix that.
> >> >>
> >> >> >
> >> >> > Which btw made me realize that even your scheme doesn't completely 
> >> >> > make
> >> >> > sure timestamp is updated after mmap write - if you have pages 0 and 
> >> >> > 1, you
> >> >> > write to both of them - CMTIME flag gets set. Then fsync_range(fd, 0, 
> >> >> > 4096)
> >> >> > is called. We write the page 0, writeprotect it, update timestamps. 
> >> >> > But
> >> >> > page 1 is still writeable so writes to it won't set CMTIME flag, 
> >> >> > neither
> >> >> > update the timestamp... Not that I think this can be reasonably 
> >> >> > solved but
> >> >> > it is a food for thought.
> >> >>
> >> >> This should already work.  AS_CMTIME is set when the pte goes from
> >> >> dirty to clean, not when the pte goes from wp to writable.  So
> >> >> whenever clear_page_dirty_for_io is called on page 1, AS_CMTIME will
> >> >> be set and a subsequent writepages call will update the timestamp.
> >> >
> >> > Oh, I missed that - I thought you were setting AS_CMTIME during
> >> > .page_mkwrite.
> >> >
> >> > Setting it in clear_page_dirty_for_io() is too late for filesystems
> >> > to include it in their existing transactions during .writepage, (at
> >> > least for XFs and ext4) because they do their delayed allocation
> >> > transactions before changing page state
> >>
> >> Couldn't it go between mpage_map_and_submit_extent and
> >> ext4_journal_stop in ext4_writepages?
> >
> > Maybe - I'm not an ext4 expert - but even if you can make it work
> > for ext4 in some way, that doesn't mean it is possible for any other
> > filesystem to use the same method. You're adding code to generic,
> > non-filesystem specific code paths and so the solutions need to be
> > generic rather not tied to how a specific filesystem is implemented.
> >
> 
> I don't see the problem for xfs or btrfs either.
> 
> xfs uses generic_writepages, which already does the right thing.  (xfs
> with my updated patches passes my tests.)  xfs_vm_writepage calls
> xfs_start_page_writeback(..., 1, ...), so clear_page_dirty_for_io is
> called.  At that point (I presume), it would still be possible to add
> metadata to a transaction (assuming there's a transaction open -- I
> don't have a clue here). 

That's my point - there isn't a transaction in XFS at this point,
and so if we gather that flag from clear_page_dirty_for_io() we'd
need a second transaction and therefore the optimisation you want
filesystems to use to mitigate the additional overhead can't be done
for all commonly used filesystems.

> Even if this is too late, xfs_vm_writepage
> could call page_mkwrite to for AS_CMTIME to be set if needed.
> page_mkwrite will be fast if the page isn't mmapped.  What am I
> missing?

That it leads to different behaviour for different filesystems.

i.e. page_mkwrite on page A sets the flag. writeback on a range that
doesn't include page A occurs, sees the flag, clears it after
updating the timestamp. Some time later writeback on page A occurs,
no timestamp update occurs.

The behaviour needs to be consistent across filesystems.

Cheers,

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

Re: [PATCH 1/3] ARM: OMAP2+: hwmod-data: Add SSI information

[Paul Walmsley]

Hi Sebastian

On Sun, 11 Aug 2013, Sebastian Reichel wrote:

> From: Sebastian Reichel 
> 
> This patch adds Synchronous Serial Interface (SSI) hwmod support for
> OMAP34xx SoCs.

a few comments:

- please add your Signed-off-by: to the patch description, per 
Documentation/SubmittingPatches

- please drop "omap34xx_ssi_irqs" and "omap34xx_ssi_addrs" - that data 
should go into DT now

The rest looks OK to me, based on a brief look.

... 

FYI, this is stretching my recollection, and is not directly related to 
this patch, but I seem to recall that there was a problem with auto-idle 
when SSI was active on the 3430.  Basically, if the SSI was active, but 
other CORE_L3/CORE_L4 clockdomain devices weren't, I think that DPLL3 
would be incorrectly shut down.  You'll probably need to check the Nokia 
kernel source for details.  I thought we had a hwmod flag for this, but I 
guess not.  Anyway, in case you notice odd behavior...


- Paul

> ---
>  arch/arm/mach-omap2/omap_hwmod_3xxx_data.c |  104 
> 
>  1 file changed, 104 insertions(+)
> 
> diff --git a/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c 
> b/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
> index 0c3a427..74006c4 100644
> --- a/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
> +++ b/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
> @@ -3693,6 +3693,109 @@ static struct omap_hwmod_ocp_if omap3xxx_l4_core__aes 
> = {
>   .user   = OCP_USER_MPU | OCP_USER_SDMA,
>  };
>  
> +/*
> + * 'ssi' class
> + * synchronous serial interface (multichannel and full-duplex serial if)
> + */
> +
> +static struct omap_hwmod_class_sysconfig omap34xx_ssi_sysc = {
> + .rev_offs   = 0x,
> + .sysc_offs  = 0x0010,
> + .syss_offs  = 0x0014,
> + .sysc_flags = (SYSC_HAS_AUTOIDLE | SYSC_HAS_EMUFREE |
> +SYSC_HAS_MIDLEMODE | SYSC_HAS_SIDLEMODE |
> +SYSC_HAS_SOFTRESET | SYSS_HAS_RESET_STATUS),
> + .idlemodes  = (SIDLE_FORCE | SIDLE_NO | SIDLE_SMART |
> +SIDLE_SMART_WKUP | MSTANDBY_FORCE | MSTANDBY_NO |
> +MSTANDBY_SMART | MSTANDBY_SMART_WKUP),
> + .sysc_fields= _hwmod_sysc_type1,
> +};
> +
> +static struct omap_hwmod_class omap34xx_ssi_hwmod_class = {
> + .name   = "ssi",
> + .sysc   = _ssi_sysc,
> +};
> +
> +static struct omap_hwmod_irq_info omap34xx_ssi_irqs[] = {
> + { .name = "ssi_p1_mpu_irq0", .irq = 67 },
> + { .name = "ssi_p1_mpu_irq1", .irq = 68 },
> + { .name = "ssi_p2_mpu_irq0", .irq = 69 },
> + { .name = "ssi_p2_mpu_irq1", .irq = 70 },
> + { .name = "ssi_gdd_mpu", .irq = 71 },
> + { .irq = -1 },
> +};
> +
> +static struct omap_hwmod_addr_space omap34xx_ssi_addrs[] = {
> + {
> + .name   = "sys",
> + .pa_start   = 0x48058000,
> + .pa_end = 0x48058fff,
> + .flags  = ADDR_TYPE_RT,
> + },
> + {
> + /* generic distributed DMA */
> + .name   = "gdd",
> + .pa_start   = 0x48059000,
> + .pa_end = 0x48059fff,
> + .flags  = ADDR_TYPE_RT,
> + },
> + {
> + /* port 1: synchronous serial transmitter */
> + .name   = "p1_sst",
> + .pa_start   = 0x4805a000,
> + .pa_end = 0x4805a7ff,
> + .flags  = ADDR_TYPE_RT,
> + },
> + {
> + /* port 1: synchronous serial receiver */
> + .name   = "p1_ssr",
> + .pa_start   = 0x4805a800,
> + .pa_end = 0x4805afff,
> + .flags  = ADDR_TYPE_RT,
> + },
> + {
> + /* port 2: synchronous serial transmitter */
> + .name   = "p2_sst",
> + .pa_start   = 0x4805b000,
> + .pa_end = 0x4805b7ff,
> + .flags  = ADDR_TYPE_RT,
> + },
> + {
> + /* port 2: synchronous serial receiver */
> + .name   = "p2_ssr",
> + .pa_start   = 0x4805b800,
> + .pa_end = 0x4805bfff,
> + .flags  = ADDR_TYPE_RT,
> + },
> + {}
> +};
> +
> +static struct omap_hwmod omap34xx_ssi_hwmod = {
> + .name   = "ssi",
> + .class  = _ssi_hwmod_class,
> + .clkdm_name = "l3_init_clkdm",
> + .mpu_irqs   = omap34xx_ssi_irqs,
> + .main_clk   = "ssi_ssr_fck",
> + .prcm   = {
> + .omap2 = {
> + .prcm_reg_id= 1,
> + .module_bit = OMAP3430_EN_SSI_SHIFT,
> + .module_offs= WKUP_MOD,
> + .idlest_reg_id  = 1,
> + .idlest_idle_bit= OMAP3430ES2_ST_SSI_IDLE_SHIFT,
> + },
> + },
> +};
> +
> +/* SSI -> l3 */
> +static struct 

Re: [PATCH] kernel/module.c: use scnprintf() instead of sprintf()

[Rusty Russell]

Chen Gang  writes:

> For some strings, they are permitted to be larger than PAGE_SIZE, so
> need use scnprintf() instead of sprintf(), or it will cause issue.
>
> One case is:
>
>   if a module version is crazy defined (length more than PAGE_SIZE),
>   'modinfo' command is still OK (print full contents),
>   but for "cat /sys/modules/'modname'/version", will cause issue in kernel.

Applied!

Thanks,
Rusty.

>
> Signed-off-by: Chen Gang 
> ---
>  kernel/module.c |2 +-
>  1 files changed, 1 insertions(+), 1 deletions(-)
>
> diff --git a/kernel/module.c b/kernel/module.c
> index 2069158..0618e63 100644
> --- a/kernel/module.c
> +++ b/kernel/module.c
> @@ -603,7 +603,7 @@ static void setup_modinfo_##field(struct module *mod, 
> const char *s)  \
>  static ssize_t show_modinfo_##field(struct module_attribute *mattr,   \
>   struct module_kobject *mk, char *buffer)  \
>  { \
> - return sprintf(buffer, "%s\n", mk->mod->field);   \
> + return scnprintf(buffer, PAGE_SIZE, "%s\n", mk->mod->field);  \
>  } \
>  static int modinfo_##field##_exists(struct module *mod)   \
>  { \
> -- 
> 1.7.7.6
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] kernel/params.c: use scnprintf() instead of sprintf()

[Rusty Russell]

Chen Gang  writes:

> For some strings (e.g. version string), they are permitted to be larger
> than PAGE_SIZE (although meaningless), so recommend to use scnprintf()
> instead of sprintf().

Applied.

Thanks,
Rusty.

>
> Signed-off-by: Chen Gang 
> ---
>  kernel/params.c |7 ---
>  1 files changed, 4 insertions(+), 3 deletions(-)
>
> diff --git a/kernel/params.c b/kernel/params.c
> index 1f228a3..4da300f 100644
> --- a/kernel/params.c
> +++ b/kernel/params.c
> @@ -241,7 +241,8 @@ int parse_args(const char *doing,
>   }   \
>   int param_get_##name(char *buffer, const struct kernel_param *kp) \
>   {   \
> - return sprintf(buffer, format, *((type *)kp->arg)); \
> + return scnprintf(buffer, PAGE_SIZE, format, \
> + *((type *)kp->arg));\
>   }   \
>   struct kernel_param_ops param_ops_##name = {\
>   .set = param_set_##name,\
> @@ -285,7 +286,7 @@ EXPORT_SYMBOL(param_set_charp);
>  
>  int param_get_charp(char *buffer, const struct kernel_param *kp)
>  {
> - return sprintf(buffer, "%s", *((char **)kp->arg));
> + return scnprintf(buffer, PAGE_SIZE, "%s", *((char **)kp->arg));
>  }
>  EXPORT_SYMBOL(param_get_charp);
>  
> @@ -827,7 +828,7 @@ ssize_t __modver_version_show(struct module_attribute 
> *mattr,
>   struct module_version_attribute *vattr =
>   container_of(mattr, struct module_version_attribute, mattr);
>  
> - return sprintf(buf, "%s\n", vattr->version);
> + return scnprintf(buf, PAGE_SIZE, "%s\n", vattr->version);
>  }
>  
>  extern const struct module_version_attribute *__start___modver[];
> -- 
> 1.7.7.6
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] Kconfig: Remove hotplug enable hints in CONFIG_KEXEC help texts

[Stephen Rothwell]

Hi Geert,

On Tue, 20 Aug 2013 21:38:03 +0200 Geert Uytterhoeven  
wrote:
>
> commit 40b313608ad4ea655addd2ec6cdd106477ae8e15 ("Finally eradicate
> CONFIG_HOTPLUG") removed remaining references to CONFIG_HOTPLUG, but missed
> a few plain English references in the CONFIG_KEXEC help texts.
> 
> Remove them, too.
> 
> Signed-off-by: Geert Uytterhoeven 

Looks good to me.  Thanks.

Acked-by: Stephen Rothwell 

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


pgpsua15ev7xG.pgp
Description: PGP signature

Re: Proposed stable release changes

[Guenter Roeck]

On Tue, Aug 20, 2013 at 09:03:12PM -0400, Josh Boyer wrote:
[ ... ]

> 
> Suspend/Resume is broken on a variety of Thinkpad T400 and T500
> machines in 3.10.  This was true with 3.10.0 afaik.  Current thinking
> is that it's related to the Intel mei/mei_me driver(s).  Blacklisting

Reminds me ... I had to disable MEI on my servers at home because 
it caused some instability (random system hangs) and the watchdog
didn't work. I thought that was only me, but maybe not.

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

Re: Proposed stable release changes

[Josh Boyer]

On Tue, Aug 20, 2013 at 8:49 PM, Greg KH  wrote:
> On Tue, Aug 20, 2013 at 08:41:23PM -0400, Josh Boyer wrote:
>> On Tue, Aug 20, 2013 at 7:57 PM, Greg KH  wrote:
>> >> I like this overall.  The only thing I might change is "wait for -rc2"
>> >> for patches tagged with CC: stable that go in during the merge window.
>> >>  It seems those are the ones that tend to bite us.
>> >
>> > Maintainers can always tag their patches to have me hold off until -rc2
>> > for that.
>>
>> They can (not immediately sure how though?)
>
> Some do:
> Cc: stable  # after -rc5 is out
> or
> Cc: stable  # wait a -rc cycle
> or
> Cc: stable  # wait a few weeks to bake
>
>> , but they don't with the
>> exception of the few that don't tag at all and send you patches in
>> bundles.  I mean, that's what the huge thread about the stable trees
>> that hopefully leads to a conversation at KS is about, right?
>
> Hopefully, yes, but I don't know about that yet.
>
>> Let me phrase this as a question instead.  Is there something we can
>> do to help catch the patches that get sucked into stable during the
>> merge window and then wind up causing issues and reverted/fixed after
>> things settle down in the -rc releases?
>
> Test linux-next and Linus's tree-of-the-day better.  If problems happen,
> and a patch has a cc: stable@ on it, let stable@ know about it.

Ah, yes.  I forgot about the "look through linux-next for CC: stable".
 That could probably be automated to a degree even.

We already build a Linus kernel in rawhide at least once a day.  Two
flavors even, once with debug options enabled and once without.  The
three of us run it and have an autotest setup going and being
improved, but there is no substitute for wide-spread user testing.
Unfortunately, we have problems getting that with rawhide for various
reasons.

>> I'm offering to help in whatever way you think is best.  It's your
>> workflow (and sanity) that are the most impacted.  However, I share
>> the pain whenever something breaks in stable through the wonderful
>> place that is Fedora bugzilla so I'm looking for ways to reduce that.
>
> Letting me know when something breaks is always good as well.  Right now
> that doesn't seem to happen much, so either not much is breaking, or I'm
> just not told about it, I don't know which.

There's no need to reply specifically to these, but off the top of my
head just for 3.10.y:

brcmsmac explodes in 3.10.{6,7,8,9}.  I think you know about that one
already and Felix and Arend are working on it.

Suspend/Resume is broken on a variety of Thinkpad T400 and T500
machines in 3.10.  This was true with 3.10.0 afaik.  Current thinking
is that it's related to the Intel mei/mei_me driver(s).  Blacklisting
those seems to fix things for a number of users.  There are patches in
3.11-rcX, but the "fix" highlighted doesn't fix it.

There were various i915 backlight issues reported with 3.10.3/4.  I
believe they were fixed with 3.10.5.

USB storage was broken because of the mishandled VPD stuff.  Fixed in 3.10.7.

I'm aware I'm reporting issues that you either already knew about or
were already fixed.  The problem we have is that we roll out a new
stable release and then we get bug reports for 2 weeks because not
everyone updates as frequently as stable releases, etc.  So something
that may seem to impact a small number of users at the time winds up
actually impacting lots of users once it rolls out in a distro.  As
far as I know, Fedora is possibly the only distro actually pushing
stable release kernels out on a normal basis.  I'd love to be wrong on
that point.

In the future, if we can get the information from the end user in
time, I'll be happy to forward issues that aren't already reported
onwards.  Or if you still want to hear about it, I can chime in on the
existing threads with bugzilla numbers.  I'm also willing to do a
monthly "patches we're carrying not in stable" report if people find
that helpful.  I'll likely be doing that within Fedora already and I'm
happy to send it to stable@, even if those patches aren't exactly
stable-rules matching.  We did that when kernel.org went down and it
helped then, just not sure how much it would help now or if people
care.

josh
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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 04/14] crypto: omap-aes: Simplify DMA usage by using direct SGs

[Joel Fernandes]

On 08/20/2013 07:57 AM, Lokesh Vutla wrote:
> Hi Joel,
> 
> On Sunday 18 August 2013 08:12 AM, Joel Fernandes wrote:
>> In early version of this driver, assumptions were made such as DMA layer
>> requires contiguous buffers etc. Due to this, new buffers were allocated,
>> mapped and used for DMA. These assumptions are no longer true and DMAEngine
>> scatter-gather DMA doesn't have such requirements. We simply the DMA 
>> operations
>> by directly using the scatter-gather buffers provided by the crypto layer
>> instead of creating our own.
>>
>> Lot of logic that handled DMA'ing only X number of bytes of the total, or as
>> much as fitted into a 3rd party buffer is removed and is no longer required.
>>
>> Also, good performance improvement of atleast ~20% seen with encrypting a
>> buffer size of 8K (1800 ops/sec vs 1400 ops/sec).  Improvement will be higher
>> for much larger blocks though such benchmarking is left as an exercise for 
>> the
>> reader.  Also DMA usage is much more simplified and coherent with rest of the
>> code.
>>
>> Signed-off-by: Joel Fernandes 
>> ---
>>  drivers/crypto/omap-aes.c |  147 
>> -
>>  1 file changed, 25 insertions(+), 122 deletions(-)
>>
>> diff --git a/drivers/crypto/omap-aes.c b/drivers/crypto/omap-aes.c
>> index e369e6e..64dd5c1 100644
>> --- a/drivers/crypto/omap-aes.c
>> +++ b/drivers/crypto/omap-aes.c
>> @@ -480,22 +480,14 @@ static int sg_copy(struct scatterlist **sg, size_t 
>> *offset, void *buf,
>>  }
>>  
>>  static int omap_aes_crypt_dma(struct crypto_tfm *tfm,
>> -struct scatterlist *in_sg, struct scatterlist *out_sg)
>> +struct scatterlist *in_sg, struct scatterlist *out_sg,
>> +int in_sg_len, int out_sg_len)
>>  {
>>  struct omap_aes_ctx *ctx = crypto_tfm_ctx(tfm);
>>  struct omap_aes_dev *dd = ctx->dd;
>>  struct dma_async_tx_descriptor *tx_in, *tx_out;
>>  struct dma_slave_config cfg;
>> -dma_addr_t dma_addr_in = sg_dma_address(in_sg);
>> -int ret, length = sg_dma_len(in_sg);
>> -
>> -pr_debug("len: %d\n", length);
>> -
>> -dd->dma_size = length;
>> -
>> -if (!(dd->flags & FLAGS_FAST))
>> -dma_sync_single_for_device(dd->dev, dma_addr_in, length,
>> -   DMA_TO_DEVICE);
>> +int ret;
> By this change FLAGS_FAST is unsed, it can be cleaned right?
> or Am I missing something?

Yes, FLAGS_FAST would be unused now and can go away. Since it is very trivial
change, I will make this change in the not-immediate future and submit.

Thanks,

-Joel


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] amilo-rfkill: add Kconfig depends on i8042

[Xiong Zhou]

From: Xiong Zhou 

Fix randconfig build failure for Amilo x86 platform driver.
AMILO_RFKILL requires SERIO_I8042 being available.

amilo-rfkill.c:(.text+0x108b5b): undefined reference to `i8042_lock_chip'
amilo-rfkill.c:(.text+0x108b69): undefined reference to `i8042_command'
amilo-rfkill.c:(.text+0x108b71): undefined reference to `i8042_unlock_chip'

Reported-by: Jim Davis 
Signed-off-by: Xiong Zhou 
Acked-by: Ben Hutchings 
---
 drivers/platform/x86/Kconfig |1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/platform/x86/Kconfig b/drivers/platform/x86/Kconfig
index 8577261..37645b9 100644
--- a/drivers/platform/x86/Kconfig
+++ b/drivers/platform/x86/Kconfig
@@ -176,6 +176,7 @@ config FUJITSU_TABLET
 config AMILO_RFKILL
tristate "Fujitsu-Siemens Amilo rfkill support"
depends on RFKILL
+   depends on SERIO_I8042
---help---
  This is a driver for enabling wifi on some Fujitsu-Siemens Amilo
  laptops.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH v2 0/3] workqueue: Comment/Doc correction with no functional change

[Libin]

This patch set doesn't make any functional differences.

Libin (3):
  workqueue: Comment correction in file header
  workqueue: Fix manage_workers() RETURNS description
  workqueue: Correct/Drop references to gcwq in Documentation

 Documentation/workqueue.txt | 72 ++---
 kernel/workqueue.c  | 14 +
 2 files changed, 45 insertions(+), 41 deletions(-)

-- 
1.8.2.1


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

[PATCH v2 3/3] workqueue: Correct/Drop references to gcwq in Documentation

[Libin]

No functional changes. This patch fixes the post gcwq comments in
Documentation/workqueue.txt.

Signed-off-by: Libin 
---
 Documentation/workqueue.txt | 72 ++---
 1 file changed, 36 insertions(+), 36 deletions(-)

diff --git a/Documentation/workqueue.txt b/Documentation/workqueue.txt
index a6ab4b6..5e65b1c 100644
--- a/Documentation/workqueue.txt
+++ b/Documentation/workqueue.txt
@@ -85,16 +85,16 @@ workqueue.
 Special purpose threads, called worker threads, execute the functions
 off of the queue, one after the other.  If no work is queued, the
 worker threads become idle.  These worker threads are managed in so
-called thread-pools.
+called worker-pools.
 
 The cmwq design differentiates between the user-facing workqueues that
 subsystems and drivers queue work items on and the backend mechanism
-which manages thread-pools and processes the queued work items.
+which manages worker-pools and processes the queued work items.
 
-The backend is called gcwq.  There is one gcwq for each possible CPU
-and one gcwq to serve work items queued on unbound workqueues.  Each
-gcwq has two thread-pools - one for normal work items and the other
-for high priority ones.
+There are two worker-pools, one for normal work items and the other
+for high priority ones, for each possible CPU and some extra worker-pools
+to serve work items queued on unbound workqueues - the number of these
+baking pools is dynamic.
 
 Subsystems and drivers can create and queue work items through special
 workqueue API functions as they see fit. They can influence some
@@ -104,13 +104,12 @@ things like CPU locality, reentrancy, concurrency limits, 
priority and
 more.  To get a detailed overview refer to the API description of
 alloc_workqueue() below.
 
-When a work item is queued to a workqueue, the target gcwq and
-thread-pool is determined according to the queue parameters and
-workqueue attributes and appended on the shared worklist of the
-thread-pool.  For example, unless specifically overridden, a work item
-of a bound workqueue will be queued on the worklist of either normal
-or highpri thread-pool of the gcwq that is associated to the CPU the
-issuer is running on.
+When a work item is queued to a workqueue, the target worker-pool is
+determined according to the queue parameters and workqueue attributes
+and appended on the shared worklist of the worker-pool.  For example,
+unless specifically overridden, a work item of a bound workqueue will
+be queued on the worklist of either normal or highpri worker-pool that
+is associated to the CPU the issuer is running on.
 
 For any worker pool implementation, managing the concurrency level
 (how many execution contexts are active) is an important issue.  cmwq
@@ -118,14 +117,14 @@ tries to keep the concurrency at a minimal but sufficient 
level.
 Minimal to save resources and sufficient in that the system is used at
 its full capacity.
 
-Each thread-pool bound to an actual CPU implements concurrency
-management by hooking into the scheduler.  The thread-pool is notified
+Each worker-pool bound to an actual CPU implements concurrency
+management by hooking into the scheduler.  The worker-pool is notified
 whenever an active worker wakes up or sleeps and keeps track of the
 number of the currently runnable workers.  Generally, work items are
 not expected to hog a CPU and consume many cycles.  That means
 maintaining just enough concurrency to prevent work processing from
 stalling should be optimal.  As long as there are one or more runnable
-workers on the CPU, the thread-pool doesn't start execution of a new
+workers on the CPU, the worker-pool doesn't start execution of a new
 work, but, when the last running worker goes to sleep, it immediately
 schedules a new worker so that the CPU doesn't sit idle while there
 are pending work items.  This allows using a minimal number of workers
@@ -135,19 +134,20 @@ Keeping idle workers around doesn't cost other than the 
memory space
 for kthreads, so cmwq holds onto idle ones for a while before killing
 them.
 
-For an unbound wq, the above concurrency management doesn't apply and
-the thread-pools for the pseudo unbound CPU try to start executing all
-work items as soon as possible.  The responsibility of regulating
-concurrency level is on the users.  There is also a flag to mark a
-bound wq to ignore the concurrency management.  Please refer to the
-API section for details.
+For unbound workqueues, the number of backing pools is dynamic.
+Unbound workqueue can be assigned custom attributes using
+apply_workqueue_attrs() and workqueue will automatically create
+backing worker pools matching the attributes. The responsibility of
+regulating concurrency level is on the users.  There is also a flag
+to mark a bound wq to ignore the concurrency management.  Please refer
+to the API section for details.
 
 Forward progress guarantee relies on that workers can be created when
 more execution contexts are 

[PATCH v2 1/3] workqueue: Comment correction in file header

[Libin]

No functional change. There are two worker pools for each cpu in
current implementation(one for normal work items and the other for
high priority ones).

Signed-off-by: Libin 
---
 kernel/workqueue.c | 7 ---
 1 file changed, 4 insertions(+), 3 deletions(-)

diff --git a/kernel/workqueue.c b/kernel/workqueue.c
index 7f5d4be..26644ce 100644
--- a/kernel/workqueue.c
+++ b/kernel/workqueue.c
@@ -16,9 +16,10 @@
  *
  * This is the generic async execution mechanism.  Work items as are
  * executed in process context.  The worker pool is shared and
- * automatically managed.  There is one worker pool for each CPU and
- * one extra for works which are better served by workers which are
- * not bound to any specific CPU.
+ * automatically managed.  There are two worker pools for each CPU(one
+ * for normal work items and the other for high priority ones) and
+ * some extra pools for workqueues which are not bound to any specific
+ * CPU - the number of these backing pools is dynamic.
  *
  * Please read Documentation/workqueue.txt for details.
  */
-- 
1.8.2.1


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

[PATCH v2 2/3] workqueue: Fix manage_workers() RETURNS description

[Libin]

No functional change. The comment of function manage_workers()
RETURNS description is obvious wrong, same as the CONTEXT.
Fix it.

Signed-off-by: Libin 
---
 kernel/workqueue.c | 7 +--
 1 file changed, 5 insertions(+), 2 deletions(-)

diff --git a/kernel/workqueue.c b/kernel/workqueue.c
index 26644ce..46a0de0 100644
--- a/kernel/workqueue.c
+++ b/kernel/workqueue.c
@@ -2034,8 +2034,11 @@ static bool maybe_destroy_workers(struct worker_pool 
*pool)
  * multiple times.  Does GFP_KERNEL allocations.
  *
  * RETURNS:
- * spin_lock_irq(pool->lock) which may be released and regrabbed
- * multiple times.  Does GFP_KERNEL allocations.
+ * %false if the pool don't need management and the caller can safely
+ * start processing works, %true indicates that the function released
+ * pool->lock and reacquired it to perform some management function
+ * and that the conditions that the caller verified while holding the
+ * lock before calling the function might no longer be true.
  */
 static bool manage_workers(struct worker *worker)
 {
-- 
1.8.2.1


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

Re: [PATCH v3 3/5] mm: Notify filesystems when it's time to apply a deferred cmtime update

[Andy Lutomirski]

On Tue, Aug 20, 2013 at 3:43 PM, Dave Chinner  wrote:
> On Tue, Aug 20, 2013 at 02:54:01PM -0700, Andy Lutomirski wrote:
>> On Tue, Aug 20, 2013 at 2:48 PM, Dave Chinner  wrote:
>> > On Tue, Aug 20, 2013 at 09:42:34AM -0700, Andy Lutomirski wrote:
>> >> On Tue, Aug 20, 2013 at 9:00 AM, Jan Kara  wrote:
>> >> > On Mon 19-08-13 21:14:44, Andy Lutomirski wrote:
>> >> >> >> I could require ->writepages *and* ->flush_cmtime to handle the time
>> >> >> >> update, but that would complicate non-transactional filesystems.
>> >> >> >> Those filesystems should just flush cmtime at the end of writepages.
>> >> >> >
>> >> >> > do_writepages() is the wrong place to do such updates - we can get
>> >> >> > writeback directly through .writepage, so the time updates need to
>> >> >> > be in .writepage. That first .writepage call will clear the bit on
>> >> >> > the mapping, so it's only done on the first call to .writepage on
>> >> >> > the given mapping.
>> >> >>
>> >> >> Last time I checked, all the paths that actually needed the timestamp
>> >> >> update went through .writepages.  I'll double-check.
>> >> >   kswapd can call just .writepage to do the writeout so timestamp update
>> >> > should be handled there as well. Otherwise all pages in a mapping can be
>> >> > cleaned without timestamp being updated.
>> >>
>> >> OK, I'll fix that.
>> >>
>> >> >
>> >> > Which btw made me realize that even your scheme doesn't completely make
>> >> > sure timestamp is updated after mmap write - if you have pages 0 and 1, 
>> >> > you
>> >> > write to both of them - CMTIME flag gets set. Then fsync_range(fd, 0, 
>> >> > 4096)
>> >> > is called. We write the page 0, writeprotect it, update timestamps. But
>> >> > page 1 is still writeable so writes to it won't set CMTIME flag, neither
>> >> > update the timestamp... Not that I think this can be reasonably solved 
>> >> > but
>> >> > it is a food for thought.
>> >>
>> >> This should already work.  AS_CMTIME is set when the pte goes from
>> >> dirty to clean, not when the pte goes from wp to writable.  So
>> >> whenever clear_page_dirty_for_io is called on page 1, AS_CMTIME will
>> >> be set and a subsequent writepages call will update the timestamp.
>> >
>> > Oh, I missed that - I thought you were setting AS_CMTIME during
>> > .page_mkwrite.
>> >
>> > Setting it in clear_page_dirty_for_io() is too late for filesystems
>> > to include it in their existing transactions during .writepage, (at
>> > least for XFs and ext4) because they do their delayed allocation
>> > transactions before changing page state
>>
>> Couldn't it go between mpage_map_and_submit_extent and
>> ext4_journal_stop in ext4_writepages?
>
> Maybe - I'm not an ext4 expert - but even if you can make it work
> for ext4 in some way, that doesn't mean it is possible for any other
> filesystem to use the same method. You're adding code to generic,
> non-filesystem specific code paths and so the solutions need to be
> generic rather not tied to how a specific filesystem is implemented.
>

I don't see the problem for xfs or btrfs either.

xfs uses generic_writepages, which already does the right thing.  (xfs
with my updated patches passes my tests.)  xfs_vm_writepage calls
xfs_start_page_writeback(..., 1, ...), so clear_page_dirty_for_io is
called.  At that point (I presume), it would still be possible to add
metadata to a transaction (assuming there's a transaction open -- I
don't have a clue here).  Even if this is too late, xfs_vm_writepage
could call page_mkwrite to for AS_CMTIME to be set if needed.
page_mkwrite will be fast if the page isn't mmapped.  What am I
missing?

btrfs seems to do much the same thing.

--Andy


> Cheers,
>
> Dave.
> --
> Dave Chinner
> da...@fromorbit.com



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

Re: Proposed stable release changes

[Greg KH]

On Tue, Aug 20, 2013 at 08:41:23PM -0400, Josh Boyer wrote:
> On Tue, Aug 20, 2013 at 7:57 PM, Greg KH  wrote:
> >> I like this overall.  The only thing I might change is "wait for -rc2"
> >> for patches tagged with CC: stable that go in during the merge window.
> >>  It seems those are the ones that tend to bite us.
> >
> > Maintainers can always tag their patches to have me hold off until -rc2
> > for that.
> 
> They can (not immediately sure how though?)

Some do:
Cc: stable  # after -rc5 is out
or
Cc: stable  # wait a -rc cycle
or
Cc: stable  # wait a few weeks to bake

> , but they don't with the
> exception of the few that don't tag at all and send you patches in
> bundles.  I mean, that's what the huge thread about the stable trees
> that hopefully leads to a conversation at KS is about, right?

Hopefully, yes, but I don't know about that yet.

> Let me phrase this as a question instead.  Is there something we can
> do to help catch the patches that get sucked into stable during the
> merge window and then wind up causing issues and reverted/fixed after
> things settle down in the -rc releases?

Test linux-next and Linus's tree-of-the-day better.  If problems happen,
and a patch has a cc: stable@ on it, let stable@ know about it.

> I'm offering to help in whatever way you think is best.  It's your
> workflow (and sanity) that are the most impacted.  However, I share
> the pain whenever something breaks in stable through the wonderful
> place that is Fedora bugzilla so I'm looking for ways to reduce that.

Letting me know when something breaks is always good as well.  Right now
that doesn't seem to happen much, so either not much is breaking, or I'm
just not told about it, I don't know which.

thanks,

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

[PATCH] block: trace all devices plug operation.

[majianpeng]

In func blk_queue_bio, if list of plug is empty,it will call
blk_trace_plug.
If process deal with a single device,it't ok.But if process deal with
multi devices,it only trace the first device.
Using request_count to judge, it can soleve this problem.

In addition, i modify the comment.

Signed-off-by: Jianpeng Ma 
---
 block/blk-core.c | 6 ++
 1 file changed, 2 insertions(+), 4 deletions(-)

diff --git a/block/blk-core.c b/block/blk-core.c
index 93a18d1..91037f7 100644
--- a/block/blk-core.c
+++ b/block/blk-core.c
@@ -1549,11 +1549,9 @@ get_rq:
if (plug) {
/*
 * If this is the first request added after a plug, fire
-* of a plug trace. If others have been added before, check
-* if we have multiple devices in this plug. If so, make a
-* note to sort the list before dispatch.
+* of a plug trace.
 */
-   if (list_empty(>list))
+   if (!request_count)
trace_block_plug(q);
else {
if (request_count >= BLK_MAX_REQUEST_COUNT) {
-- 
1.8.3

Re: Proposed stable release changes

[Josh Boyer]

On Tue, Aug 20, 2013 at 7:57 PM, Greg KH  wrote:
> On Tue, Aug 20, 2013 at 07:40:49PM -0400, Josh Boyer wrote:
>> On Tue, Aug 20, 2013 at 6:40 PM, Greg KH  wrote:
>> > Hi all,
>> >
>> > Given that I had to just revert a patch in the recent stable releases
>> > that didn't get enough time to "bake" in Linus's tree (or in -next), I
>> > figured it was worth discussing some possible changes with how "fast" I
>> > pick up patches for stable releases.
>> >
>> > So, how about this proposal:
>> >
>> > - I will wait for a -rc to come out with the patch in it before putting
>> >   it into a stable release, unless:
>> > - the maintainer ACKs it, or sends it directly (like DaveM does
>> >   for networking patches)
>> > - I have seen enough discussion about a patch to show that it
>> >   really does fix something / is good / doesn't cause problems.
>> > - obviously safe, i.e. "add a device id" type thing.
>> >
>> > Given that we have -rc releases every week, except for the initial -rc1
>> > release, I don't think this will really cause any major delays.
>> >
>> > Also, now that we are about to head into my busy "travel season", odds
>> > are, I'll be at least a week behind anyway, so this would probably start
>> > happening without an "official" change.  It's been a boring summer, I've
>> > been able to keep up with the stable stuff really easily, causing
>> > problems like this :)
>> >
>> > Objections?  Comments?
>>
>> I like this overall.  The only thing I might change is "wait for -rc2"
>> for patches tagged with CC: stable that go in during the merge window.
>>  It seems those are the ones that tend to bite us.
>
> Maintainers can always tag their patches to have me hold off until -rc2
> for that.

They can (not immediately sure how though?), but they don't with the
exception of the few that don't tag at all and send you patches in
bundles.  I mean, that's what the huge thread about the stable trees
that hopefully leads to a conversation at KS is about, right?

> And, given the huge number of patches for stable that come in during
> the -rc1 merge window, there's no way I can get to them all before -rc2
> comes out, so this will probably end up being the case for most of them
> anyway.

Sheer numbers forcing some to be pushed out isn't really that great
when the problem is spread across the whole window.  I'm not saying
you aren't correct that a lot of them don't get pushed to stable
releases until post -rc2, but at that point you're playing catch up.
I was suggesting just sitting on them until -rc2 entirely.  Basically,
don't release a stable kernel until the next version is at -rc2.

Let me phrase this as a question instead.  Is there something we can
do to help catch the patches that get sucked into stable during the
merge window and then wind up causing issues and reverted/fixed after
things settle down in the -rc releases?

Reviewing the patches submitted for those stable kernels isn't
necessarily sufficient, since the issues I'm concerned about aren't
spotted until after the release anyway.  It's a two-fold problem.  The
first is one we're never going to fix in that people are human and
make mistakes and sometimes patches don't get tested well enough
before they're tagged for stable.  The second issue is a combination
of timing and volume.  I doubt we're going to fix the volume since we
keep touting the increasing change rate as a sign of success, but
could we fix the timing by forcing things to bake more in the -rc
releases?

I'm offering to help in whatever way you think is best.  It's your
workflow (and sanity) that are the most impacted.  However, I share
the pain whenever something breaks in stable through the wonderful
place that is Fedora bugzilla so I'm looking for ways to reduce that.

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

[Greg KH]

On Tue, Aug 20, 2013 at 05:11:11PM -0700, Guenter Roeck wrote:
> On Tue, Aug 20, 2013 at 04:17:43PM -0700, Greg KH wrote:
> > On Tue, Aug 20, 2013 at 04:11:17PM -0700, Guenter Roeck wrote:
> > > It would be even better if you could find the time to push -rc releases
> > > into the stable repository before you accept patches into a stable branch.
> > 
> > What do you mean by this?
> >
> > The git tree?  I could do that, but when I have to drop a patch, it
> > would cause a mess if I had to always go forwards.
> > 
> That is not what I mean. I referred to the master branch of the stable
> repository, which you normally update to the most recent -rc when you
> publish a new -stable release.

Ah, ok, that makes sense.  I've updated it to 3.11-rc6 now.  Sorry for
the confusion.

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 05/13] ARM: ux500: Apply a ste-* prefix onto snowball.dts

[Olof Johansson]

On Fri, Jul 19, 2013 at 7:13 AM, Lee Jones  wrote:
> Signed-off-by: Lee Jones 
> ---
>  arch/arm/boot/dts/{snowball.dts => ste-snowball.dts} | 0
>  1 file changed, 0 insertions(+), 0 deletions(-)
>  rename arch/arm/boot/dts/{snowball.dts => ste-snowball.dts} (100%)
>
> diff --git a/arch/arm/boot/dts/snowball.dts 
> b/arch/arm/boot/dts/ste-snowball.dts
> similarity index 100%
> rename from arch/arm/boot/dts/snowball.dts
> rename to arch/arm/boot/dts/ste-snowball.dts

Grmbl, grmbl, grmbl. This now breaks any script that knows to use
snowball.dtb. :(

It's good to get the prefixes added, but it's annoying to have to deal
with both during an overlap period. Maybe generate both dtb filenames
for a while but rename the source?


-Olof
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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: pull request: wireless 2013-08-19

[David Miller]

From: "John W. Linville" 
Date: Mon, 19 Aug 2013 14:59:40 -0400

> This is a batch of fixes intended for the 3.11 stream...
> 
> Regarding the iwlwifi bits, Johannes says:
> 
> "We revert an rfkill bugfix that unfortunately caused more bugs, shuffle
> some code to avoid touching the PCIe device before it's enabled and
> disconnect if firmware fails to do our bidding. I also have Stanislaw's
> fix to not crash in some channel switch scenarios."
> 
> As for the mac80211 bits, Johannes says:
> 
> "This time, I have one fix from Dan Carpenter for users of
> nl80211hdr_put(), and one fix from myself fixing a regression with the
> libertas driver."
> 
> Along with the above...
> 
> Dan Carpenter fixes some incorrectly placed "address of" operators
> in hostap that caused copying of junk data.
> 
> Jussi Kivilinna corrects zd1201 to use an allocated buffer rather
> than the stack for a URB operation.
> 
> Please let me know if there are problems!

Pulled, thanks John.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] nouveau: fix reclocking on nv40

[Ben Skeggs]

On Mon, Aug 19, 2013 at 4:59 PM, Pali Rohár  wrote:
> On Friday 16 August 2013 14:57:07 Pali Rohár wrote:
>> In commit 77145f1cbdf8d28b46ff8070ca749bad821e0774 was
>> introduced error which cause that reclocking on nv40 not
>> working anymore. There is missing assigment of return value
>> from pll_calc to ret.
>>
>> Signed-off-by: Pali Rohár 
>> Signed-off-by: Martin Peres 
>> ---
>>  drivers/gpu/drm/nouveau/nv40_pm.c |2 +-
>>  1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/drivers/gpu/drm/nouveau/nv40_pm.c
>> b/drivers/gpu/drm/nouveau/nv40_pm.c index 3af5bcd..625f80d
>> 100644
>> --- a/drivers/gpu/drm/nouveau/nv40_pm.c
>> +++ b/drivers/gpu/drm/nouveau/nv40_pm.c
>> @@ -131,7 +131,7 @@ nv40_calc_pll(struct drm_device *dev, u32
>> reg, struct nvbios_pll *pll, if (clk < pll->vco1.max_freq)
>>   pll->vco2.max_freq = 0;
>>
>> - pclk->pll_calc(pclk, pll, clk, );
>> + ret = pclk->pll_calc(pclk, pll, clk, );
>>   if (ret == 0)
>>   return -ERANGE;
>
> Hello, it is possible to include this patch in 3.11?
> Or it is too late now and need to wait for 3.12?
I've picked up the patch and will submit it in my next 3.11-fixes pull request.

Thanks,
Ben.

>
> --
> Pali Rohár
> pali.ro...@gmail.com
>
> ___
> dri-devel mailing list
> dri-de...@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

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

[Stephen Rothwell]

Hi Ben,

On Tue, 20 Aug 2013 14:28:44 -0500 Ben Myers  wrote:
>
> I'd prefer not to break Stephen's tree two days in a row.  We could just 
> revert
> d6970d4b726c in the xfs tree for the time being as Stephen has done, but given
> the choice would prefer the fix.  Do you have a preference between the two
> approaches that Dwight has posted?  The first seems more conservative...

I will automatically revert that commit when I merge the xfs tree until
some other solution is forthcoming (so you don't have to do the revert in
the xfs tree).  This does need to be fixed fairly soon, though.

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


pgpVpo_Qqgigl.pgp
Description: PGP signature

Re: rfc: trivial patches and slow deaths?

[Joe Perches]

On Tue, 2013-08-20 at 19:10 -0500, Rob Landley wrote:
> The important question is does he want to handle patches that you're  
> flipping out about not going in before the next merge window because  
> they are SO IMPORTANT that the trivial tree must promote them out of  
> sequence.

You're misreading.  I see no flipping out here.

I'm simply saying that obvious defects should be
corrected sooner rather than later.

I'm also saying that the trivial tree should
have some visibility about whether or not a
patch or series will be handled by the trivial
maintainer or not.

Jiri has not responded to this point.

Silence about the status of patches that extends
for months is not good.


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

[PATCH v2 2/8] turbostat: Don't attempt to printf an off_t with %zx

[Josh Triplett]

turbostat uses the format %zx to print an off_t.  However, %zx wants a
size_t, not an off_t.  On 32-bit targets, those refer to different
types, potentially even with different sizes.  Use %llx and a cast
instead, since printf does not have a length modifier for off_t.

Without this patch, when compiling for a 32-bit target:

turbostat.c: In function 'get_msr':
turbostat.c:231:3: warning: format '%zx' expects argument of type 'size_t', but 
argument 4 has type 'off_t' [-Wformat]

Signed-off-by: Josh Triplett 
---
 tools/power/x86/turbostat/turbostat.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/tools/power/x86/turbostat/turbostat.c 
b/tools/power/x86/turbostat/turbostat.c
index 5bf4a67..b10b8d2 100644
--- a/tools/power/x86/turbostat/turbostat.c
+++ b/tools/power/x86/turbostat/turbostat.c
@@ -230,7 +230,7 @@ int get_msr(int cpu, off_t offset, unsigned long long *msr)
close(fd);
 
if (retval != sizeof *msr) {
-   fprintf(stderr, "%s offset 0x%zx read failed\n", pathname, 
offset);
+   fprintf(stderr, "%s offset 0x%llx read failed\n", pathname, 
(unsigned long long)offset);
return -1;
}
 
-- 
1.8.4.rc3

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

[PATCH v2 6/8] turbostat: Factor out common function to open file and exit on failure

[Josh Triplett]

Several different functions in turbostat contain the same pattern of
opening a file and exiting on failure.  Factor out a common fopen_or_die
function for that.

Signed-off-by: Josh Triplett 
---
 tools/power/x86/turbostat/turbostat.c | 31 ---
 1 file changed, 16 insertions(+), 15 deletions(-)

diff --git a/tools/power/x86/turbostat/turbostat.c 
b/tools/power/x86/turbostat/turbostat.c
index e0dbada..aa80db9 100644
--- a/tools/power/x86/turbostat/turbostat.c
+++ b/tools/power/x86/turbostat/turbostat.c
@@ -1153,6 +1153,19 @@ void free_all_buffers(void)
 }
 
 /*
+ * Open a file, and exit on failure
+ */
+FILE *fopen_or_die(const char *path, const char *mode)
+{
+   FILE *filep = fopen(path, "r");
+   if (!filep) {
+   perror(path);
+   exit(1);
+   }
+   return filep;
+}
+
+/*
  * Parse a file containing a single int.
  */
 int parse_int_file(const char *fmt, ...)
@@ -1165,11 +1178,7 @@ int parse_int_file(const char *fmt, ...)
va_start(args, fmt);
vsnprintf(path, sizeof(path), fmt, args);
va_end(args);
-   filep = fopen(path, "r");
-   if (!filep) {
-   perror(path);
-   exit(1);
-   }
+   filep = fopen_or_die(path, "r");
if (fscanf(filep, "%d", ) != 1) {
perror(path);
exit(1);
@@ -1215,11 +1224,7 @@ int get_num_ht_siblings(int cpu)
char character;
 
sprintf(path, 
"/sys/devices/system/cpu/cpu%d/topology/thread_siblings_list", cpu);
-   filep = fopen(path, "r");
-   if (filep == NULL) {
-   perror(path);
-   exit(1);
-   }
+   filep = fopen_or_die(path, "r");
/*
 * file format:
 * if a pair of number with a character between: 2 siblings (eg. 1-2, 
or 1,4)
@@ -1289,11 +1294,7 @@ int for_all_proc_cpus(int (func)(int))
int cpu_num;
int retval;
 
-   fp = fopen(proc_stat, "r");
-   if (fp == NULL) {
-   perror(proc_stat);
-   exit(1);
-   }
+   fp = fopen_or_die(proc_stat, "r");
 
retval = fscanf(fp, "cpu %*d %*d %*d %*d %*d %*d %*d %*d %*d %*d\n");
if (retval != 0) {
-- 
1.8.4.rc3

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

[PATCH v2 4/8] turbostat: Check return value of fscanf

[Josh Triplett]

Some systems declare fscanf with the warn_unused_result attribute.  On
such systems, turbostat generates the following warnings:

turbostat.c: In function 'get_core_id':
turbostat.c:1203:8: warning: ignoring return value of 'fscanf', declared with 
attribute warn_unused_result [-Wunused-result]
turbostat.c: In function 'get_physical_package_id':
turbostat.c:1186:8: warning: ignoring return value of 'fscanf', declared with 
attribute warn_unused_result [-Wunused-result]
turbostat.c: In function 'cpu_is_first_core_in_package':
turbostat.c:1169:8: warning: ignoring return value of 'fscanf', declared with 
attribute warn_unused_result [-Wunused-result]
turbostat.c: In function 'cpu_is_first_sibling_in_core':
turbostat.c:1148:8: warning: ignoring return value of 'fscanf', declared with 
attribute warn_unused_result [-Wunused-result]

Fix these by checking the return value of those four calls to fscanf.

Signed-off-by: Josh Triplett 
---
 tools/power/x86/turbostat/turbostat.c | 20 
 1 file changed, 16 insertions(+), 4 deletions(-)

diff --git a/tools/power/x86/turbostat/turbostat.c 
b/tools/power/x86/turbostat/turbostat.c
index dc30f1b..514adba 100644
--- a/tools/power/x86/turbostat/turbostat.c
+++ b/tools/power/x86/turbostat/turbostat.c
@@ -1167,7 +1167,10 @@ int cpu_is_first_sibling_in_core(int cpu)
perror(path);
exit(1);
}
-   fscanf(filep, "%d", _cpu);
+   if (fscanf(filep, "%d", _cpu) != 1) {
+   perror(path);
+   exit(1);
+   }
fclose(filep);
return (cpu == first_cpu);
 }
@@ -1188,7 +1191,10 @@ int cpu_is_first_core_in_package(int cpu)
perror(path);
exit(1);
}
-   fscanf(filep, "%d", _cpu);
+   if (fscanf(filep, "%d", _cpu) != 1) {
+   perror(path);
+   exit(1);
+   }
fclose(filep);
return (cpu == first_cpu);
 }
@@ -1205,7 +1211,10 @@ int get_physical_package_id(int cpu)
perror(path);
exit(1);
}
-   fscanf(filep, "%d", );
+   if (fscanf(filep, "%d", ) != 1) {
+   perror(path);
+   exit(1);
+   }
fclose(filep);
return pkg;
 }
@@ -1222,7 +1231,10 @@ int get_core_id(int cpu)
perror(path);
exit(1);
}
-   fscanf(filep, "%d", );
+   if (fscanf(filep, "%d", ) != 1) {
+   perror(path);
+   exit(1);
+   }
fclose(filep);
return core;
 }
-- 
1.8.4.rc3

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

[PATCH v2 3/8] turbostat: Use GCC's CPUID functions to support PIC

[Josh Triplett]

turbostat uses inline assembly to call cpuid.  On 32-bit x86, on systems
that have certain security features enabled by default that make -fPIC
the default, this causes a build error:

turbostat.c: In function ‘check_cpuid’:
turbostat.c:1906:2: error: PIC register clobbered by ‘ebx’ in ‘asm’
  asm("cpuid" : "=a" (fms), "=c" (ecx), "=d" (edx) : "a" (1) : "ebx");
  ^

GCC provides a header cpuid.h, containing a __get_cpuid function that
works with both PIC and non-PIC.  (On PIC, it saves and restores ebx
around the cpuid instruction.)  Use that instead.

Signed-off-by: Josh Triplett 
Cc: sta...@vger.kernel.org
---
 tools/power/x86/turbostat/turbostat.c | 11 ++-
 1 file changed, 6 insertions(+), 5 deletions(-)

diff --git a/tools/power/x86/turbostat/turbostat.c 
b/tools/power/x86/turbostat/turbostat.c
index b10b8d2..dc30f1b 100644
--- a/tools/power/x86/turbostat/turbostat.c
+++ b/tools/power/x86/turbostat/turbostat.c
@@ -35,6 +35,7 @@
 #include 
 #include 
 #include 
+#include 
 
 char *proc_stat = "/proc/stat";
 unsigned int interval_sec = 5; /* set with -i interval_sec */
@@ -1894,7 +1895,7 @@ void check_cpuid()
 
eax = ebx = ecx = edx = 0;
 
-   asm("cpuid" : "=a" (max_level), "=b" (ebx), "=c" (ecx), "=d" (edx) : 
"a" (0));
+   __get_cpuid(0, _level, , , );
 
if (ebx == 0x756e6547 && edx == 0x49656e69 && ecx == 0x6c65746e)
genuine_intel = 1;
@@ -1903,7 +1904,7 @@ void check_cpuid()
fprintf(stderr, "CPUID(0): %.4s%.4s%.4s ",
(char *), (char *), (char *));
 
-   asm("cpuid" : "=a" (fms), "=c" (ecx), "=d" (edx) : "a" (1) : "ebx");
+   __get_cpuid(1, , , , );
family = (fms >> 8) & 0xf;
model = (fms >> 4) & 0xf;
stepping = fms & 0xf;
@@ -1925,7 +1926,7 @@ void check_cpuid()
 * This check is valid for both Intel and AMD.
 */
ebx = ecx = edx = 0;
-   asm("cpuid" : "=a" (max_level), "=b" (ebx), "=c" (ecx), "=d" (edx) : 
"a" (0x8000));
+   __get_cpuid(0x8000, _level, , , );
 
if (max_level < 0x8007) {
fprintf(stderr, "CPUID: no invariant TSC (max_level 0x%x)\n", 
max_level);
@@ -1936,7 +1937,7 @@ void check_cpuid()
 * Non-Stop TSC is advertised by CPUID.EAX=0x8007: EDX.bit8
 * this check is valid for both Intel and AMD
 */
-   asm("cpuid" : "=a" (eax), "=b" (ebx), "=c" (ecx), "=d" (edx) : "a" 
(0x8007));
+   __get_cpuid(0x8007, , , , );
has_invariant_tsc = edx & (1 << 8);
 
if (!has_invariant_tsc) {
@@ -1949,7 +1950,7 @@ void check_cpuid()
 * this check is valid for both Intel and AMD
 */
 
-   asm("cpuid" : "=a" (eax), "=b" (ebx), "=c" (ecx), "=d" (edx) : "a" 
(0x6));
+   __get_cpuid(0x6, , , , );
has_aperf = ecx & (1 << 0);
do_dts = eax & (1 << 0);
do_ptm = eax & (1 << 6);
-- 
1.8.4.rc3

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

[PATCH v2 5/8] turbostat: Add a helper to parse a single int out of a file

[Josh Triplett]

Many different chunks of code in turbostat open a file, parse a single
int out of it, and close it.  Factor that out into a common function.

Signed-off-by: Josh Triplett 
---
 tools/power/x86/turbostat/turbostat.c | 81 +++
 1 file changed, 24 insertions(+), 57 deletions(-)

diff --git a/tools/power/x86/turbostat/turbostat.c 
b/tools/power/x86/turbostat/turbostat.c
index 514adba..e0dbada 100644
--- a/tools/power/x86/turbostat/turbostat.c
+++ b/tools/power/x86/turbostat/turbostat.c
@@ -21,6 +21,7 @@
 
 #define _GNU_SOURCE
 #include MSRHEADER
+#include 
 #include 
 #include 
 #include 
@@ -1152,27 +1153,38 @@ void free_all_buffers(void)
 }
 
 /*
- * cpu_is_first_sibling_in_core(cpu)
- * return 1 if given CPU is 1st HT sibling in the core
+ * Parse a file containing a single int.
  */
-int cpu_is_first_sibling_in_core(int cpu)
+int parse_int_file(const char *fmt, ...)
 {
-   char path[64];
+   va_list args;
+   char path[PATH_MAX];
FILE *filep;
-   int first_cpu;
+   int value;
 
-   sprintf(path, 
"/sys/devices/system/cpu/cpu%d/topology/thread_siblings_list", cpu);
+   va_start(args, fmt);
+   vsnprintf(path, sizeof(path), fmt, args);
+   va_end(args);
filep = fopen(path, "r");
-   if (filep == NULL) {
+   if (!filep) {
perror(path);
exit(1);
}
-   if (fscanf(filep, "%d", _cpu) != 1) {
+   if (fscanf(filep, "%d", ) != 1) {
perror(path);
exit(1);
}
fclose(filep);
-   return (cpu == first_cpu);
+   return value;
+}
+
+/*
+ * cpu_is_first_sibling_in_core(cpu)
+ * return 1 if given CPU is 1st HT sibling in the core
+ */
+int cpu_is_first_sibling_in_core(int cpu)
+{
+   return cpu == 
parse_int_file("/sys/devices/system/cpu/cpu%d/topology/thread_siblings_list", 
cpu);
 }
 
 /*
@@ -1181,62 +1193,17 @@ int cpu_is_first_sibling_in_core(int cpu)
  */
 int cpu_is_first_core_in_package(int cpu)
 {
-   char path[64];
-   FILE *filep;
-   int first_cpu;
-
-   sprintf(path, 
"/sys/devices/system/cpu/cpu%d/topology/core_siblings_list", cpu);
-   filep = fopen(path, "r");
-   if (filep == NULL) {
-   perror(path);
-   exit(1);
-   }
-   if (fscanf(filep, "%d", _cpu) != 1) {
-   perror(path);
-   exit(1);
-   }
-   fclose(filep);
-   return (cpu == first_cpu);
+   return cpu == 
parse_int_file("/sys/devices/system/cpu/cpu%d/topology/core_siblings_list", 
cpu);
 }
 
 int get_physical_package_id(int cpu)
 {
-   char path[80];
-   FILE *filep;
-   int pkg;
-
-   sprintf(path, 
"/sys/devices/system/cpu/cpu%d/topology/physical_package_id", cpu);
-   filep = fopen(path, "r");
-   if (filep == NULL) {
-   perror(path);
-   exit(1);
-   }
-   if (fscanf(filep, "%d", ) != 1) {
-   perror(path);
-   exit(1);
-   }
-   fclose(filep);
-   return pkg;
+   return 
parse_int_file("/sys/devices/system/cpu/cpu%d/topology/physical_package_id", 
cpu);
 }
 
 int get_core_id(int cpu)
 {
-   char path[80];
-   FILE *filep;
-   int core;
-
-   sprintf(path, "/sys/devices/system/cpu/cpu%d/topology/core_id", cpu);
-   filep = fopen(path, "r");
-   if (filep == NULL) {
-   perror(path);
-   exit(1);
-   }
-   if (fscanf(filep, "%d", ) != 1) {
-   perror(path);
-   exit(1);
-   }
-   fclose(filep);
-   return core;
+   return parse_int_file("/sys/devices/system/cpu/cpu%d/topology/core_id", 
cpu);
 }
 
 int get_num_ht_siblings(int cpu)
-- 
1.8.4.rc3

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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/8] turbostat: Don't put unprocessed uapi headers in the include path

[Josh Triplett]

turbostat's Makefile puts arch/x86/include/uapi/ in the include path, so
that it can include  from it.  It isn't in general safe to
include even uapi headers directly from the kernel tree without
processing them through scripts/headers_install.sh, but asm/msr.h
happens to work.

However, that include path can break with some versions of system
headers, by overriding some system headers with the unprocessed versions
directly from the kernel source.  For instance:

In file included from /build/x86-generic/usr/include/bits/sigcontext.h:28:0,
 from /build/x86-generic/usr/include/signal.h:339,
 from /build/x86-generic/usr/include/sys/wait.h:31,
 from turbostat.c:27:
../../../../arch/x86/include/uapi/asm/sigcontext.h:4:28: fatal error: 
linux/compiler.h: No such file or directory

This occurs because the system bits/sigcontext.h on that build system
includes , and asm/sigcontext.h in the kernel source
includes , which scripts/headers_install.sh would have
filtered out.

Since turbostat really only wants a single header, just include that one
header rather than putting an entire directory of kernel headers on the
include path.

In the process, switch from msr.h to msr-index.h, since turbostat just
wants the MSR numbers.

Signed-off-by: Josh Triplett 
Cc: sta...@vger.kernel.org
---
 tools/power/x86/turbostat/Makefile| 2 +-
 tools/power/x86/turbostat/turbostat.c | 2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/tools/power/x86/turbostat/Makefile 
b/tools/power/x86/turbostat/Makefile
index f09641d..d1b3a36 100644
--- a/tools/power/x86/turbostat/Makefile
+++ b/tools/power/x86/turbostat/Makefile
@@ -5,7 +5,7 @@ DESTDIR :=
 
 turbostat : turbostat.c
 CFLAGS +=  -Wall
-CFLAGS +=  -I../../../../arch/x86/include/uapi/
+CFLAGS +=  
-DMSRHEADER='"../../../../arch/x86/include/uapi/asm/msr-index.h"'
 
 %: %.c
@mkdir -p $(BUILD_OUTPUT)
diff --git a/tools/power/x86/turbostat/turbostat.c 
b/tools/power/x86/turbostat/turbostat.c
index fe70207..5bf4a67 100644
--- a/tools/power/x86/turbostat/turbostat.c
+++ b/tools/power/x86/turbostat/turbostat.c
@@ -20,7 +20,7 @@
  */
 
 #define _GNU_SOURCE
-#include 
+#include MSRHEADER
 #include 
 #include 
 #include 
-- 
1.8.4.rc3

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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 8/8] turbostat: Add a .gitignore to ignore the compiled turbostat binary

[Josh Triplett]

Signed-off-by: Josh Triplett 
---
 tools/power/x86/turbostat/.gitignore | 1 +
 1 file changed, 1 insertion(+)
 create mode 100644 tools/power/x86/turbostat/.gitignore

diff --git a/tools/power/x86/turbostat/.gitignore 
b/tools/power/x86/turbostat/.gitignore
new file mode 100644
index 000..7521370
--- /dev/null
+++ b/tools/power/x86/turbostat/.gitignore
@@ -0,0 +1 @@
+turbostat
-- 
1.8.4.rc3

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