Re: [PATCH v1 05/11] drivers: usb: twl6030: Add dt support for twl6030 usb

[Rajendra Nayak]

On Thursday 28 June 2012 05:21 PM, Kishon Vijay Abraham I wrote:

Add device tree support for twl6030 usb driver.
Update the Documentation with device tree binding information.

Signed-off-by: Kishon Vijay Abraham I
---
  .../devicetree/bindings/usb/twl-usb.txt|   18 
  drivers/usb/otg/twl6030-usb.c  |   45 ++--
  2 files changed, 50 insertions(+), 13 deletions(-)
  create mode 100644 Documentation/devicetree/bindings/usb/twl-usb.txt

diff --git a/Documentation/devicetree/bindings/usb/twl-usb.txt 
b/Documentation/devicetree/bindings/usb/twl-usb.txt
new file mode 100644
index 000..f293271
--- /dev/null
+++ b/Documentation/devicetree/bindings/usb/twl-usb.txt
@@ -0,0 +1,18 @@
+USB COMPARATOR OF TWL CHIPS
+
+TWL6030 USB COMPARATOR
+ - compatible : Should be "ti,twl6030-usb"
+ - interrupts : Two interrupt numbers to the cpu should be specified. First
+   interrupt number is the otg interrupt number that raises ID interrupts when
+   the controller has to act as host and the second interrupt number is the
+   usb interrupt number that raises VBUS interrupts when the controller has to
+   act as device
+ - regulator :  can be "vusb" or "ldousb"
+ --supply : phandle to the regulator device tree node
+
+twl6030-usb {
+   compatible = "ti,twl6030-usb";
+   interrupts =<  4 10>;
+   regulator = "vusb";
+   vusb-supply =<>;


This doesn't seem right. Why do you ned a 'regulator' string along
with the phandle?


+};
diff --git a/drivers/usb/otg/twl6030-usb.c b/drivers/usb/otg/twl6030-usb.c
index 6a361d2..20b7abe 100644
--- a/drivers/usb/otg/twl6030-usb.c
+++ b/drivers/usb/otg/twl6030-usb.c
@@ -105,7 +105,7 @@ struct twl6030_usb {
u8  asleep;
boolirq_enabled;
boolvbus_enable;
-   unsigned long   features;
+   const char  *regulator;
  };

  #define   comparator_to_twl(x) container_of((x), struct twl6030_usb, 
comparator)
@@ -153,13 +153,6 @@ static int twl6030_start_srp(struct phy_companion 
*comparator)

  static int twl6030_usb_ldo_init(struct twl6030_usb *twl)
  {
-   char *regulator_name;
-
-   if (twl->features&  TWL6025_SUBCLASS)
-   regulator_name = "ldousb";
-   else
-   regulator_name = "vusb";
-
/* Set to OTG_REV 1.3 and turn on the ID_WAKEUP_COMP */
twl6030_writeb(twl, TWL6030_MODULE_ID0 , 0x1, TWL6030_BACKUP_REG);

@@ -169,7 +162,7 @@ static int twl6030_usb_ldo_init(struct twl6030_usb *twl)
/* Program MISC2 register and set bit VUSB_IN_VBAT */
twl6030_writeb(twl, TWL6030_MODULE_ID0 , 0x10, TWL6030_MISC2);

-   twl->usb3v3 = regulator_get(twl->dev, regulator_name);
+   twl->usb3v3 = regulator_get(twl->dev, twl->regulator);
if (IS_ERR(twl->usb3v3))
return -ENODEV;

@@ -324,9 +317,9 @@ static int __devinit twl6030_usb_probe(struct 
platform_device *pdev)
  {
struct twl6030_usb  *twl;
int status, err;
-   struct twl4030_usb_data *pdata;
-   struct device *dev =>dev;
-   pdata = dev->platform_data;
+   struct device_node  *np = pdev->dev.of_node;
+   struct device   *dev =>dev;
+   struct twl4030_usb_data *pdata = dev->platform_data;

twl = devm_kzalloc(dev, sizeof *twl, GFP_KERNEL);
if (!twl)
@@ -335,13 +328,28 @@ static int __devinit twl6030_usb_probe(struct 
platform_device *pdev)
twl->dev =>dev;
twl->irq1= platform_get_irq(pdev, 0);
twl->irq2= platform_get_irq(pdev, 1);
-   twl->features= pdata->features;
twl->linkstat= OMAP_MUSB_UNKNOWN;

twl->comparator.set_vbus = twl6030_set_vbus;
twl->comparator.start_srp= twl6030_start_srp;
omap_usb2_set_comparator(>comparator);

+   if (np) {
+   err = of_property_read_string(np, "regulator",>regulator);
+   if (err<  0) {
+   dev_err(>dev, "unable to get regulator\n");
+   return err;
+   }


Isn't there a better way for the driver to know which supply to use 
instead of DT passing the supply name?


regards,
Rajendra


+   } else if (pdata) {
+   if (pdata->features&  TWL6025_SUBCLASS)
+   twl->regulator = "ldousb";
+   else
+   twl->regulator = "vusb";
+   } else {
+   dev_err(>dev, "twl6030 initialized without pdata\n");
+   return -EINVAL;
+   }
+
/* init spinlock for workqueue */
spin_lock_init(>lock);

@@ -403,12 +411,23 @@ static int __exit twl6030_usb_remove(struct 
platform_device *pdev)
return 0;
  }

+#ifdef CONFIG_OF
+static const struct of_device_id twl6030_usb_id_table[] = {
+   { .compatible = "ti,twl6030-usb" },
+   

linux-next: manual merge of the usb tree with the mfd tree

[Stephen Rothwell]

Hi Greg,

Today's linux-next merge of the usb tree got a conflict in
drivers/usb/host/ehci-omap.c between commit 2761a6394516 ("mfd: USB: Fix
the omap-usb EHCI ULPI PHY reset fix issues") from the mfd tree and
commit 1a49e2ac9651 ("EHCI: centralize controller initialization") from
the usb tree.

I am not sure how to fix this up, I have just effectively reverted the
effect of the former commit on this file.
-- 
Cheers,
Stephen Rothwells...@canb.auug.org.au


pgpU4aI9TFqgw.pgp
Description: PGP signature

[PATCH 2/2] staging/sm7xxfb: return a proper err for smtc_alloc_fb_info failure

[Devendra Naga]

as smtc_alloc_fb_info can fail, but we are returning the 0,
how? because the pci_enable_device succeeded, which makes the probe
return 0, and may cause panics or some strange problems at remove
when driver unloaded by modprobe -r.

so return err properly as smtc_alloc_fb_info is doing kzallocs its
good to do -ENOMEM

Signed-off-by: Devendra Naga 
---
 drivers/staging/sm7xxfb/sm7xxfb.c |4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/drivers/staging/sm7xxfb/sm7xxfb.c 
b/drivers/staging/sm7xxfb/sm7xxfb.c
index 0c0b603..7395196 100644
--- a/drivers/staging/sm7xxfb/sm7xxfb.c
+++ b/drivers/staging/sm7xxfb/sm7xxfb.c
@@ -808,8 +808,10 @@ static int __devinit smtcfb_pci_probe(struct pci_dev *pdev,
 
sfb = smtc_alloc_fb_info(pdev, name);
 
-   if (!sfb)
+   if (!sfb) {
+   err = -ENOMEM;
goto failed_free;
+   }
 
sfb->chip_id = ent->device;
sprintf(name, "sm%Xfb", sfb->chip_id);
-- 
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/2] staging/sm7xxfb: use module_pci_driver macro

[Devendra Naga]

as the manual of module_pci_driver says that
it can be used when the init and exit functions of
the module does nothing but the pci_register_driver
and pci_unregister_driver.

use it for the sm7xxfb driver, as the driver does nothing in
its _init and _exit functions but the register and unregister.

Signed-off-by: Devendra Naga 
---
 drivers/staging/sm7xxfb/sm7xxfb.c |   13 +
 1 file changed, 1 insertion(+), 12 deletions(-)

diff --git a/drivers/staging/sm7xxfb/sm7xxfb.c 
b/drivers/staging/sm7xxfb/sm7xxfb.c
index e3511ec..0c0b603 100644
--- a/drivers/staging/sm7xxfb/sm7xxfb.c
+++ b/drivers/staging/sm7xxfb/sm7xxfb.c
@@ -1058,18 +1058,7 @@ static struct pci_driver smtcfb_driver = {
.driver.pm  = SM7XX_PM_OPS,
 };
 
-static int __init smtcfb_init(void)
-{
-   return pci_register_driver(_driver);
-}
-
-static void __exit smtcfb_exit(void)
-{
-   pci_unregister_driver(_driver);
-}
-
-module_init(smtcfb_init);
-module_exit(smtcfb_exit);
+module_pci_driver(smtcfb_driver);
 
 MODULE_AUTHOR("Siliconmotion ");
 MODULE_DESCRIPTION("Framebuffer driver for SMI Graphic Cards");
-- 
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 v1 01/11] drivers: usb: otg: add a new driver for omap usb2 phy

[Rajendra Nayak]

diff --git a/Documentation/devicetree/bindings/usb/omap-usb.txt 
b/Documentation/devicetree/bindings/usb/omap-usb.txt
new file mode 100644
index 000..80a28c9
--- /dev/null
+++ b/Documentation/devicetree/bindings/usb/omap-usb.txt
@@ -0,0 +1,16 @@
+OMAP USB PHY
+
+OMAP USB2 PHY
+
+Required properties:
+ - compatible: Should be "ti,omap-usb2"
+ - reg : Address and length of the register set for the device. Also
+add the address of control module dev conf register until a driver for
+control module is added
+
+This is usually a subnode of ocp2scp to which it is connected.
+
+usb2phy@0x4a0ad080 {
+   compatible = "ti,omap-usb2";
+   reg =<0x4a0ad080 0x58>;


Don;t you need a 'ti,hwmods' entry for this one?


--- /dev/null
+++ b/drivers/usb/otg/omap-usb2.c
@@ -0,0 +1,273 @@
+/*
+ * omap-usb2.c - USB PHY, talking to musb controller in OMAP.
+ *
+ * Copyright (C) 2011 Texas Instruments Incorporated - http://www.ti.com


Copyright (C) 2012? Same for the couple of headers below.


+ * 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.
+ *
+ * Author: Kishon Vijay Abraham I
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ *
+ */
+



+
+static int __devinit omap_usb2_probe(struct platform_device *pdev)
+{
+   struct omap_usb *phy;
+   struct usb_otg  *otg;
+   struct resource *res;
+
+   phy = devm_kzalloc(>dev, sizeof(*phy), GFP_KERNEL);
+   if (!phy) {
+   dev_err(>dev, "unable to allocate memory for USB2 PHY\n");
+   return -ENOMEM;
+   }
+
+   otg = devm_kzalloc(>dev, sizeof(*otg), GFP_KERNEL);
+   if (!otg) {
+   dev_err(>dev, "unable to allocate memory for USB OTG\n");
+   return -ENOMEM;
+   }
+
+   phy->dev =>dev;
+
+   phy->phy.dev = phy->dev;
+   phy->phy.label   = "omap-usb2";
+   phy->phy.set_suspend = omap_usb2_suspend;
+   phy->phy.otg = otg;
+
+   res = platform_get_resource(pdev, IORESOURCE_MEM, 1);
+
+   phy->control_dev_conf = devm_request_and_ioremap(>dev, res);
+   if (phy->control_dev_conf == NULL) {
+   dev_err(>dev, "Failed to obtain io memory\n");
+   return -ENXIO;
+   }
+
+   phy->is_suspended= 1;
+   omap_usb_phy_power(phy, 0);
+
+   otg->set_host= omap_usb_set_host;
+   otg->set_peripheral  = omap_usb_set_peripheral;
+   otg->set_vbus= omap_usb_set_vbus;
+   otg->start_srp   = omap_usb_start_srp;
+   otg->phy =>phy;
+
+   phy->wkupclk = devm_clk_get(phy->dev, "usb_phy_cm_clk32k");


Why not just use clk_get()? What does devm_clk_get() do?


+   if (IS_ERR(phy->wkupclk)) {
+   dev_err(>dev, "unable to get usb_phy_cm_clk32k\n");
+   return PTR_ERR(phy->wkupclk);
+   }
+   clk_prepare(phy->wkupclk);


Ideally clk_prepare() is an extension of clk_enable() and is expected
to be used that way. Not to be clubbed with clk_get(). Same with
clk_unprepare(). Do you do a clk_enable()/_disable() in interrupt/
atomic context?


+
+   usb_add_phy(>phy, USB_PHY_TYPE_USB2);
+
+   platform_set_drvdata(pdev, phy);
+
+   pm_runtime_enable(phy->dev);
+
+   return 0;
+}
+
+static int __devexit omap_usb2_remove(struct platform_device *pdev)
+{
+   struct omap_usb *phy = platform_get_drvdata(pdev);
+
+   clk_unprepare(phy->wkupclk);
+   usb_remove_phy(>phy);
+   platform_set_drvdata(pdev, NULL);
+
+   return 0;
+}
+
+#ifdef CONFIG_PM
+
+static int omap_usb2_runtime_suspend(struct device *dev)
+{
+   struct platform_device  *pdev = to_platform_device(dev);
+   struct omap_usb *phy = platform_get_drvdata(pdev);
+
+   clk_disable(phy->wkupclk);
+
+   return 0;
+}
+
+static int omap_usb2_runtime_resume(struct device *dev)
+{
+   struct platform_device  *pdev = to_platform_device(dev);
+   struct omap_usb *phy = platform_get_drvdata(pdev);
+
+   clk_enable(phy->wkupclk);
+
+   return 0;
+}
+
+static const struct dev_pm_ops omap_usb2_pm_ops = {
+   SET_RUNTIME_PM_OPS(omap_usb2_runtime_suspend, omap_usb2_runtime_resume,
+   NULL)
+};
+
+#define DEV_PM_OPS (_usb2_pm_ops)
+#else
+#define DEV_PM_OPS NULL
+#endif
+
+#ifdef CONFIG_OF
+static const struct of_device_id omap_usb2_id_table[] = {
+   { .compatible = "ti,omap-usb2" },
+   {}
+};
+MODULE_DEVICE_TABLE(of, omap_usb2_id_table);
+#else
+#define omap_usb2_id_table NULL;
+#endif
+
+static struct 

Re: [PATCH net-next 6/6] r8169: support RTL8168G

[Hayes Wang]

fix incorrct argument in rtl_hw_init_8168g.

Signed-off-by: Hayes Wang 
---
 drivers/net/ethernet/realtek/r8169.c |4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/net/ethernet/realtek/r8169.c 
b/drivers/net/ethernet/realtek/r8169.c
index 7ff3423..c29c5fb 100644
--- a/drivers/net/ethernet/realtek/r8169.c
+++ b/drivers/net/ethernet/realtek/r8169.c
@@ -6753,14 +6753,14 @@ static void __devinit rtl_hw_init_8168g(struct 
rtl8169_private *tp)
msleep(1);
RTL_W8(MCU, RTL_R8(MCU) & ~NOW_IS_OOB);
 
-   data = r8168_mac_ocp_read(ioaddr, 0xe8de);
+   data = r8168_mac_ocp_read(tp, 0xe8de);
data &= ~(1 << 14);
r8168_mac_ocp_write(tp, 0xe8de, data);
 
if (!rtl_udelay_loop_wait_high(tp, _link_list_ready_cond, 100, 42))
return;
 
-   data = r8168_mac_ocp_read(ioaddr, 0xe8de);
+   data = r8168_mac_ocp_read(tp, 0xe8de);
data |= (1 << 15);
r8168_mac_ocp_write(tp, 0xe8de, data);
 
-- 
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/

Re: [PATCH 2/2 v2] memory-hotplug: fix kswapd looping forever problem

[Aaditya Kumar]

On Mon, Jul 9, 2012 at 7:59 PM, Minchan Kim  wrote:

Hello Minchan,

> May I add your tested-by in next spin which will include automatic type 
> conversion
> problem ?

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

linux-next: build failure after merge of the driver-core tree

[Stephen Rothwell]

Hi Greg,

After merging the driver-core tree, today's linux-next build (x86_64
allmodconfig) failed like this:

ERROR: "devm_gpio_request_one" [drivers/extcon/extcon-arizona.ko] undefined!

Caused by commit 01eaf2458773 ("extcon: Convert extcon_gpio to
devm_gpio_request_one").  devm_gpio_request_one is not currently exported
to modules.

This has not been seen earlier because CONFIG_MFD_ARIZONA only got added
today :-(

I have added the following merge fix patch for today:

From: Stephen Rothwell 
Date: Tue, 10 Jul 2012 15:25:14 +1000
Subject: [PATCH] extcon: extcon-arizone can not be built as a module for now

fixes this build error:

ERROR: "devm_gpio_request_one" [drivers/extcon/extcon-arizona.ko] undefined!

Signed-off-by: Stephen Rothwell 
---
 drivers/extcon/Kconfig |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/extcon/Kconfig b/drivers/extcon/Kconfig
index dbd96af..a2071e4 100644
--- a/drivers/extcon/Kconfig
+++ b/drivers/extcon/Kconfig
@@ -30,7 +30,7 @@ config EXTCON_MAX8997
  detector and switch.
 
 config EXTCON_ARIZONA
-   tristate "Wolfson Arizona EXTCON support"
+   bool "Wolfson Arizona EXTCON support"
depends on MFD_ARIZONA
help
  Say Y here to enable support for external accessory detection
-- 
1.7.10.280.gaa39

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


pgptsFj8Layv8.pgp
Description: PGP signature

[PATCH] thermal: add Renesas R-Car thermal sensor support

[Kuninori Morimoto]

This patch add basic Renesas R-Car thermal sensor support.
It was tested on R-Car H1 Marzen board.

Signed-off-by: Kuninori Morimoto 
---
 drivers/thermal/Kconfig|8 ++
 drivers/thermal/Makefile   |3 +-
 drivers/thermal/rcar_thermal.c |  239 
 3 files changed, 249 insertions(+), 1 deletions(-)
 create mode 100644 drivers/thermal/rcar_thermal.c

diff --git a/drivers/thermal/Kconfig b/drivers/thermal/Kconfig
index 514a691..22bef98 100644
--- a/drivers/thermal/Kconfig
+++ b/drivers/thermal/Kconfig
@@ -26,3 +26,11 @@ config SPEAR_THERMAL
help
  Enable this to plug the SPEAr thermal sensor driver into the Linux
  thermal framework
+
+config RCAR_THERMAL
+   tristate "Renesas R-Car thermal driver"
+   depends on THERMAL
+   depends on ARCH_SHMOBILE
+   help
+ Enable this to plug the R-Car thermal sensor driver into the Linux
+ thermal framework
diff --git a/drivers/thermal/Makefile b/drivers/thermal/Makefile
index a9fff0b..fd9369a 100644
--- a/drivers/thermal/Makefile
+++ b/drivers/thermal/Makefile
@@ -3,4 +3,5 @@
 #
 
 obj-$(CONFIG_THERMAL)  += thermal_sys.o
-obj-$(CONFIG_SPEAR_THERMAL)+= spear_thermal.o
\ No newline at end of file
+obj-$(CONFIG_SPEAR_THERMAL)+= spear_thermal.o
+obj-$(CONFIG_RCAR_THERMAL) += rcar_thermal.o
diff --git a/drivers/thermal/rcar_thermal.c b/drivers/thermal/rcar_thermal.c
new file mode 100644
index 000..4319b02
--- /dev/null
+++ b/drivers/thermal/rcar_thermal.c
@@ -0,0 +1,239 @@
+/*
+ *  R-Car THS/TSC thermal sensor driver
+ *
+ * Copyright (C) 2012 Renesas Solutions Corp.
+ * Kuninori Morimoto 
+ *
+ *  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; version 2 of the License.
+ *
+ *  This program is distributed in the hope that it will be useful, but
+ *  WITHOUT ANY WARRANTY; without even the implied warranty of
+ *  MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
+ *  General Public License for more details.
+ *
+ *  You should have received a copy of the GNU General Public License along
+ *  with this program; if not, write to the Free Software Foundation, Inc.,
+ *  59 Temple Place, Suite 330, Boston, MA 02111-1307 USA.
+ */
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#define THSCR  0x2c
+#define THSSR  0x30
+
+/* THSCR */
+#define CPTAP  0xf
+
+/* THSSR */
+#define CTEMP  0x3f
+
+
+struct rcar_thermal_priv {
+   void __iomem *base;
+   struct device *dev;
+   u32 comp;
+};
+
+/*
+ * basic functions
+ */
+static u32 rcar_thermal_read(struct rcar_thermal_priv *priv, u32 reg)
+{
+   return ioread32(priv->base + reg);
+}
+
+static void rcar_thermal_write(struct rcar_thermal_priv *priv,
+  u32 reg, u32 data)
+{
+   iowrite32(data, priv->base + reg);
+}
+
+static void rcar_thermal_bset(struct rcar_thermal_priv *priv, u32 reg,
+ u32 mask, u32 data)
+{
+   u32 val = rcar_thermal_read(priv, reg);
+
+   val &= ~mask;
+   val |= (data & mask);
+
+   rcar_thermal_write(priv, reg, val);
+}
+
+/*
+ * zone device functions
+ */
+static int rcar_thermal_get_temp(struct thermal_zone_device *zone,
+  unsigned long *temp)
+{
+   struct rcar_thermal_priv *priv = zone->devdata;
+   int val, min, max, tmp;
+
+   tmp = -200; /* default */
+   while (1) {
+   if (priv->comp < 1 || priv->comp > 12) {
+   dev_err(priv->dev,
+   "THSSR invalid data (%d)\n", priv->comp);
+   priv->comp = 4; /* for next thermal */
+   return -EINVAL;
+   }
+
+   /*
+* THS comparator offset and the reference temperature
+*
+* Comparator   | reference | Temperature field
+* offset   | temperature   | measurement
+*  | (degrees C)   | (degrees C)
+* -+---+---
+*  1   |  -45  |  -45 to  -30
+*  2   |  -30  |  -30 to  -15
+*  3   |  -15  |  -15 to0
+*  4   |0  |0 to  +15
+*  5   |  +15  |  +15 to  +30
+*  6   |  +30  |  +30 to  +45
+*  7   |  +45  |  +45 to  +60
+*  8   |  +60  |  +60 to  +75
+*  9   |  +75  |  +75 to  +90
+* 10   |  +90  |  +90 to +105
+* 11   | +105  | +105 to +120
+* 12  

Re: [linux-pm] [PATCH v4 0/5] thermal: exynos: Add kernel thermal support for exynos platform

[amit daniel kachhap]

Hi Len,

These set of patches were accepted by you for 3.5 merge window. Can
you again apply them on your for-next branch for 3.6 merge? I have
some arch enablement and clean up patches based on them. It is really
important for me to mainline everything in this merge window.

Thanks,
Amit Daniel

On Sat, May 12, 2012 at 3:10 PM, Amit Daniel Kachhap
 wrote:
> Hi Andrew/Rui,
>
> As discussed with Rui Zhang, I dropped the patch for new trip type
> THERMAL_TRIP_STATE_INSTANCE and made the necessary state magnagement changes
> in cpufreq cooling functions. Also I fixed all the review comments suggested
> by Andrew. If any other changes please let me know.
>
> This patchset introduces a new generic cooling device based on cpufreq that
> can be used on non-ACPI platforms. As a proof of concept, we have drivers for
> the following platforms using this mechanism now:
>
>  * Samsung Exynos (Exynos4 and Exynos5) in the current patchset.
>  * TI OMAP (git://git.linaro.org/people/amitdanielk/linux.git 
> omap4460_thermal)
>  * Freescale i.MX (git://git.linaro.org/people/amitdanielk/linux.git 
> imx6q_thermal)
>
> The is a small change in cpufreq cooling registration APIs, so a minor change 
> is
> needed for OMAP and Freescale platforms.
>
> Thanks,
> Amit Daniel
>
> Changes since V3:
> * Dropped the concept of using new trip type THERMAL_TRIP_STATE_INSTANCE as
>  discussed with Rui Zhang. This requires adding some state management logic
>  in cpufreq cooling implementation.
> * Many review comments suggested by Andrew Morton
> * More documentation added in cpufreq cooling codes.
>
> Changes since V2:
> *Added Exynos5 TMU sensor support by enhancing the exynos4 tmu driver. 
> Exynos5 TMU
>  driver was internally developed by SangWook Ju .
> *Removed cpuhotplug cooling code in this patchset.
> *Rebased the patches against 3.4-rc6 kernel.
>
> Changes since V1:
> *Moved the sensor driver to driver/thermal folder from driver/hwmon folder
>  as suggested by Mark Brown and Guenter Roeck
> *Added notifier support to notify the registered drivers of any cpu cooling
>  action. The driver can modify the default cooling behaviour(eg set different
>  max clip frequency).
> *The percentage based frequency replaced with absolute clipped frequency.
> *Some more conditional checks when setting max frequency.
> *Renamed the new trip type THERMAL_TRIP_STATE_ACTIVE to
>  THERMAL_TRIP_STATE_INSTANCE
> *Many review comments from R, Durgadoss  and
>  eduardo.valen...@ti.com implemented.
> *Removed cooling stats through debugfs patch
> *The V1 based can be found here,
>  https://lkml.org/lkml/2012/2/22/123
>  http://lkml.org/lkml/2012/3/3/32
>
> Changes since RFC:
> *Changed the cpu cooling registration/unregistration API's to instance based
> *Changed the STATE_ACTIVE trip type to pass correct instance id
> *Adding support to restore back the policy->max_freq after doing frequency
>   clipping.
> *Moved the trip cooling stats from sysfs node to debugfs node as suggested
>   by Greg KH g...@kroah.com
> *Incorporated several review comments from eduardo.valen...@ti.com
> *Moved the Temperature sensor driver from driver/hwmon/ to driver/mfd
>  as discussed with Guenter Roeck  and
>  Donggeun Kim  (https://lkml.org/lkml/2012/1/5/7)
> *Some changes according to the changes in common cpu cooling APIs
> *The RFC based patches can be found here,
>  https://lkml.org/lkml/2011/12/13/186
>  https://lkml.org/lkml/2011/12/21/169
>
>
> Brief Description:
>
> 1) The generic cooling devices code is placed inside driver/thermal/* as
> placing inside acpi folder will need un-necessary enabling of acpi code. This
> codes is architecture independent.
>
> 2) This patchset adds generic cpu cooling low level implementation through
> frequency clipping. In future, other cpu related cooling devices may be added
> here. An ACPI version of this already exists 
> (drivers/acpi/processor_thermal.c)
> . But this will be useful for platforms like ARM using the generic
> thermal interface along with the generic cpu cooling devices. The cooling
> device registration API's return cooling device pointers which can be easily
> binded with the thermal zone trip points. The important APIs exposed are,
>a)struct thermal_cooling_device *cpufreq_cooling_register(
> struct freq_clip_table *tab_ptr, unsigned int tab_size)
>b)void cpufreq_cooling_unregister(struct thermal_cooling_device *cdev)
>
> 3) Samsung exynos platform thermal implementation is done using the generic
> cpu cooling APIs and the new trip type. The temperature sensor driver present
> in the hwmon folder(registered as hwmon driver) is moved to thermal folder
> and registered as a thermal driver.
>
> All this patchset is based on Kernel version 3.4-rc6
>
> A simple data/control flow diagrams is shown below,
>
> Core Linux thermal <->  Exynos thermal interface <- Temperature Sensor
>   | |
>  \|/|
>   Cpufreq cooling 

[PATCH] gpio/gpio-tps65910: gpio_chip.of_node referenced without CONFIG_OF_GPIO defined

[Gerard Snitselaar]

From: Jerry Snitselaar 

commit 626f9914 added code to initialize gpio_chip.of_node, but if
CONFIG_OF_GPIO is not defined gps-tps65910 fails to build with an
error complaining gpio_chip has no member of_node. I ran into this
while doing a allyesconfig build on linux-next.

Signed-off-by: Gerard Snitselaar 
---
 drivers/gpio/gpio-tps65910.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/drivers/gpio/gpio-tps65910.c b/drivers/gpio/gpio-tps65910.c
index 0749f96..11f29c8 100644
--- a/drivers/gpio/gpio-tps65910.c
+++ b/drivers/gpio/gpio-tps65910.c
@@ -149,7 +149,9 @@ static int __devinit tps65910_gpio_probe(struct 
platform_device *pdev)
tps65910_gpio->gpio_chip.set= tps65910_gpio_set;
tps65910_gpio->gpio_chip.get= tps65910_gpio_get;
tps65910_gpio->gpio_chip.dev = >dev;
+#ifdef CONFIG_OF_GPIO
tps65910_gpio->gpio_chip.of_node = tps65910->dev->of_node;
+#endif
if (pdata && pdata->gpio_base)
tps65910_gpio->gpio_chip.base = pdata->gpio_base;
else
-- 
1.7.11.1.165.g299666c

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

Re: [PATCH 1/2] acpi : cpu hot-remove returns error number when cpu_down() fails

[Yasuaki Ishimatsu]

Hi Srivatsa,

2012/07/10 9:13, Yasuaki Ishimatsu wrote:
> Hi Srivatsa,
> 
> 2012/07/09 20:25, Srivatsa S. Bhat wrote:
>> On 07/09/2012 08:01 AM, Yasuaki Ishimatsu wrote:
>>> Hi Srivatsa,
>>>
>>> Thank you for your reviewing.
>>>
>>> 2012/07/06 18:51, Srivatsa S. Bhat wrote:
 On 07/06/2012 08:46 AM, Yasuaki Ishimatsu wrote:
> Even if cpu_down() fails, acpi_processor_remove() continues to remove the 
> cpu.

 Ouch!

> But in this case, it should return error number since some process may 
> run on
> the cpu. If the cpu has a running process and the cpu is turned the power 
> off,
> the system cannot work well.
>
> Signed-off-by: Yasuaki Ishimatsu 
>
> ---
> drivers/acpi/processor_driver.c |   18 --
> 1 file changed, 12 insertions(+), 6 deletions(-)
>
> Index: linux-3.5-rc4/drivers/acpi/processor_driver.c
> ===
> --- linux-3.5-rc4.orig/drivers/acpi/processor_driver.c2012-06-25 
> 04:53:04.0 +0900
> +++ linux-3.5-rc4/drivers/acpi/processor_driver.c 2012-07-05 
> 21:02:58.711285382 +0900
> @@ -610,7 +610,7 @@ err_free_pr:
> static int acpi_processor_remove(struct acpi_device *device, int type)
> {
>   struct acpi_processor *pr = NULL;
> -
> + int ret;
>
>   if (!device || !acpi_driver_data(device))
>   return -EINVAL;
> @@ -621,8 +621,9 @@ static int acpi_processor_remove(struct
>   goto free;
>
>   if (type == ACPI_BUS_REMOVAL_EJECT) {
> - if (acpi_processor_handle_eject(pr))
> - return -EINVAL;
> + ret = acpi_processor_handle_eject(pr);
> + if (ret)
> + return ret;
>   }
>
>   acpi_processor_power_exit(pr, device);
> @@ -841,12 +842,17 @@ static acpi_status acpi_processor_hotadd
>
> static int acpi_processor_handle_eject(struct acpi_processor *pr)
> {
> - if (cpu_online(pr->id))
> - cpu_down(pr->id);
> + int ret;
> +
> + if (cpu_online(pr->id)) {
> + ret = cpu_down(pr->id);
> + if (ret)
> + return ret;
> + }
>

 Strictly speaking, this is not thorough enough. What prevents someone
 from onlining that same cpu again, at this point?
 So, IMHO, you need to wrap the contents of this function inside a
 get_online_cpus()/put_online_cpus() block, to prevent anyone else
 from messing with CPU hotplug at the same time.
>>>
>>> If I understand your comment by mistake, please let me know.
>>> If the contents is wrapped a inside get_online_cpus()/put_online_cpus() 
>>> block
>>> as below, cpu_down() will stop since cpu_down() calls cpu_hotplug_begin() 
>>> and
>>> cpu_hotplug_begin() waits for cpu_hotplug.refcount to become 0.
>>>
>>
>> You are right. Sorry, I overlooked that.
>>
>>> +   get_online_cpus()
>>> +   if (cpu_online(pr->id)) {
>>> +   ret = cpu_down(pr->id);
>>> +   if (ret)
>>> +   return ret;
>>> +   }
>>> +   put_online_cpus()
>>>
>>> I think following patch can prevent it correctly. How about the patch?
>>>
>>> ---
>>>drivers/acpi/processor_driver.c |   12 
>>>kernel/cpu.c|8 +---
>>>2 files changed, 17 insertions(+), 3 deletions(-)
>>>
>>> Index: linux-3.5-rc4/drivers/acpi/processor_driver.c
>>> ===
>>> --- linux-3.5-rc4.orig/drivers/acpi/processor_driver.c  2012-07-09 
>>> 09:59:01.280211202 +0900
>>> +++ linux-3.5-rc4/drivers/acpi/processor_driver.c   2012-07-09 
>>> 11:05:34.559859236 +0900
>>> @@ -844,14 +844,26 @@ static int acpi_processor_handle_eject(s
>>>{
>>> int ret;
>>>
>>> +retry:
>>> if (cpu_online(pr->id)) {
>>> ret = cpu_down(pr->id);
>>> if (ret)
>>> return ret;
>>> }
>>>
>>> +   get_online_cpus();
>>> +   /*
>>> +* Someone might online the cpu again at this point. So we check that
>>> +* cpu has been onlined or not. If cpu is online, we try to offline
>>> +* the cpu again.
>>> +*/
>>> +   if (cpu_online(pr->id)) {
>>
>> How about this:
>>  if (unlikely(cpu_online(pr->id)) {
>> since the probability of this happening is quite small...
> 
> Thanks. I'll update it.
> 
>>> +   put_online_cpus();
>>> +   goto retry;
>>> +   }
>>> arch_unregister_cpu(pr->id);
>>> acpi_unmap_lsapic(pr->id);
>>> +   put_online_cpus();
>>> return ret;
>>>}
>>
>> This retry logic doesn't look elegant, but I don't see any better method :-(
>>
>>>#else
>>> Index: linux-3.5-rc4/kernel/cpu.c
>>> ===
>>> --- linux-3.5-rc4.orig/kernel/cpu.c 2012-07-09 

Re: + checkpatch-add-check-for-use-of-sizeof-without-parenthesis.patch added to -mm tree

[Joe Perches]

On Mon, 2012-07-09 at 19:21 -0700, David Rientjes wrote:
> On Mon, 9 Jul 2012, Joe Perches wrote:
> 
> > I don't really care what style a large block of code
> > uses.  I care that it mostly has the same form.

> Same form??  The sizeof operator has two forms depending on whether it's a 
> unary expression or a type as specified by the standard.

> The issue here is that you're mandating they all use the same form because 
> you're quoting an email from Linus four years ago that you dug up but 
> isn't required in the coding style and is already used in over 1000 places 
> in the kernel.

$ git grep -E "\bsizeof\s*\*"|wc -l
935
$ git grep -E "\bsizeof\s*\(\s*\*"|wc -l
12762

> If you want the output of checkpatch.pl to be useful, I would think you 
> would want to eliminate this kind of garbage.

You are using high emotion words for little purpose.

checkpatch is useful, but it's not all that useful for those
quite familiar with kernel style.

Except maybe to generate flame emails...

It does have some use for reviewing patches.

> > "Another example of this is "sizeof". The kernel universally (I hope) has 
> > parenthesis around the sizeof argument, even though it's clearly not 
> > required by the C language."
> 
> He's obviously addressing a single form of the sizeof operator, i.e. those 
> on unary expressions; sizeof used on a type CLEARLY DOES require the 
> parenthesis.

That's one opinion, though I doubt it's his.
  Maybe he'll reply.  (edit: he did)

> you're talking purely about style preferences here.

_All_ of checkpatch is style preference.
None if it is a mandate.  Those that care to use it can.
You can ignore it.  I don't mind.

Otherwise, just read and write the code and do what you
think best.  I'm not a particular style zealot.  I'm not
going to nack a patch just because you or anyone else uses
a style that isn't the predominate one.

cheers, Joe

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

[PATCH V2] staging/ft1000: remove all spaces, tabs issue in while loop of ft1000_interrupt

[Devendra Naga]

all spaces in the main while loop of ft1000_interrupt are converted
to tabs.

Signed-off-by: Devendra Naga 
---
Greg,

You mean to say this only right?

drivers/staging/ft1000/ft1000-pcmcia/ft1000_hw.c |   60 +++---
 1 file changed, 31 insertions(+), 29 deletions(-)

diff --git a/drivers/staging/ft1000/ft1000-pcmcia/ft1000_hw.c 
b/drivers/staging/ft1000/ft1000-pcmcia/ft1000_hw.c
index 0059cac..86a680c 100644
--- a/drivers/staging/ft1000/ft1000-pcmcia/ft1000_hw.c
+++ b/drivers/staging/ft1000/ft1000-pcmcia/ft1000_hw.c
@@ -1996,41 +1996,43 @@ static irqreturn_t ft1000_interrupt(int irq, void 
*dev_id)
inttype = ft1000_read_reg(dev, FT1000_REG_SUP_ISR);
 
 // Make sure we process all interrupt before leaving the ISR due to the 
edge trigger interrupt type
-while (inttype) {
+   while (inttype) {
if (inttype & ISR_DOORBELL_PEND)
ft1000_parse_dpram_msg(dev);
 
-   if (inttype & ISR_RCV) {
-   DEBUG(1, "Data in FIFO\n");
+   if (inttype & ISR_RCV) {
+   DEBUG(1, "Data in FIFO\n");
 
-   cnt = 0;
-   do {
-   // Check if we have packets in the Downlink FIFO
-   if (info->AsicID == ELECTRABUZZ_ID) {
-   tempword =
-   ft1000_read_reg(dev, 
FT1000_REG_DFIFO_STAT);
-   } else {
-   tempword =
-   ft1000_read_reg(dev, 
FT1000_REG_MAG_DFSR);
-   }
-   if (tempword & 0x1f) {
-   ft1000_copy_up_pkt(dev);
-   } else {
-   break;
-   }
-   cnt++;
-   } while (cnt < MAX_RCV_LOOP);
+   cnt = 0;
+   do {
+   // Check if we have packets in the Downlink FIFO
+   if (info->AsicID == ELECTRABUZZ_ID) {
+   tempword =
+   ft1000_read_reg(dev,
+   FT1000_REG_DFIFO_STAT);
+   } else {
+   tempword =
+   ft1000_read_reg(dev,
+   FT1000_REG_MAG_DFSR);
+   }
+   if (tempword & 0x1f) {
+   ft1000_copy_up_pkt(dev);
+   } else {
+   break;
+   }
+   cnt++;
+   } while (cnt < MAX_RCV_LOOP);
 
+   }
+   // clear interrupts
+   tempword = ft1000_read_reg(dev, FT1000_REG_SUP_ISR);
+   DEBUG(1, "ft1000_hw: interrupt status register = 0x%x\n", 
tempword);
+   ft1000_write_reg(dev, FT1000_REG_SUP_ISR, tempword);
+
+   // Read interrupt type
+   inttype = ft1000_read_reg (dev, FT1000_REG_SUP_ISR);
+   DEBUG(1,"ft1000_hw: interrupt status register after clear = 
0x%x\n",inttype);
}
-   // clear interrupts
-   tempword = ft1000_read_reg(dev, FT1000_REG_SUP_ISR);
-   DEBUG(1, "ft1000_hw: interrupt status register = 0x%x\n", tempword);
-   ft1000_write_reg(dev, FT1000_REG_SUP_ISR, tempword);
-
-// Read interrupt type
-inttype = ft1000_read_reg (dev, FT1000_REG_SUP_ISR);
-DEBUG(1,"ft1000_hw: interrupt status register after clear = 
0x%x\n",inttype);
-}
ft1000_enable_interrupts(dev);
return IRQ_HANDLED;
 }
-- 
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]block: stack unplug

[Shaohua Li]

MD raid1 prepares to dispatch request in unplug callback. If make_request in
low level queue also uses unplug callback to dispatch request, the low level
queue's unplug callback will not be called. Recheck the callback list helps
this case.

Signed-off-by: Shaohua Li 

diff --git a/block/blk-core.c b/block/blk-core.c
index 93eb3e4..700cbfa 100644
--- a/block/blk-core.c
+++ b/block/blk-core.c
@@ -2900,17 +2900,16 @@ static void flush_plug_callbacks(struct blk_plug *plug)
 {
LIST_HEAD(callbacks);
 
-   if (list_empty(>cb_list))
-   return;
-
-   list_splice_init(>cb_list, );
+   while (!list_empty(>cb_list)) {
+   list_splice_init(>cb_list, );
 
-   while (!list_empty()) {
-   struct blk_plug_cb *cb = list_first_entry(,
+   while (!list_empty()) {
+   struct blk_plug_cb *cb = list_first_entry(,
  struct blk_plug_cb,
  list);
-   list_del(>list);
-   cb->callback(cb);
+   list_del(>list);
+   cb->callback(cb);
+   }
}
 }
 
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 1/2] acpi : cpu hot-remove returns error number when cpu_down() fails

[Yasuaki Ishimatsu]

Hi Toshi,

2012/07/10 6:15, Toshi Kani wrote:

On Mon, 2012-07-09 at 16:55 +0530, Srivatsa S. Bhat wrote:

On 07/09/2012 08:01 AM, Yasuaki Ishimatsu wrote:

Hi Srivatsa,

Thank you for your reviewing.

2012/07/06 18:51, Srivatsa S. Bhat wrote:

On 07/06/2012 08:46 AM, Yasuaki Ishimatsu wrote:

Even if cpu_down() fails, acpi_processor_remove() continues to remove the cpu.


Ouch!


But in this case, it should return error number since some process may run on
the cpu. If the cpu has a running process and the cpu is turned the power off,
the system cannot work well.

Signed-off-by: Yasuaki Ishimatsu 

---
   drivers/acpi/processor_driver.c |   18 --
   1 file changed, 12 insertions(+), 6 deletions(-)

Index: linux-3.5-rc4/drivers/acpi/processor_driver.c
===
--- linux-3.5-rc4.orig/drivers/acpi/processor_driver.c  2012-06-25 
04:53:04.0 +0900
+++ linux-3.5-rc4/drivers/acpi/processor_driver.c   2012-07-05 
21:02:58.711285382 +0900
@@ -610,7 +610,7 @@ err_free_pr:
   static int acpi_processor_remove(struct acpi_device *device, int type)
   {
struct acpi_processor *pr = NULL;
-
+   int ret;

if (!device || !acpi_driver_data(device))
return -EINVAL;
@@ -621,8 +621,9 @@ static int acpi_processor_remove(struct
goto free;

if (type == ACPI_BUS_REMOVAL_EJECT) {
-   if (acpi_processor_handle_eject(pr))
-   return -EINVAL;
+   ret = acpi_processor_handle_eject(pr);
+   if (ret)
+   return ret;
}

acpi_processor_power_exit(pr, device);
@@ -841,12 +842,17 @@ static acpi_status acpi_processor_hotadd

   static int acpi_processor_handle_eject(struct acpi_processor *pr)
   {
-   if (cpu_online(pr->id))
-   cpu_down(pr->id);
+   int ret;
+
+   if (cpu_online(pr->id)) {
+   ret = cpu_down(pr->id);
+   if (ret)
+   return ret;
+   }



Strictly speaking, this is not thorough enough. What prevents someone
from onlining that same cpu again, at this point?
So, IMHO, you need to wrap the contents of this function inside a
get_online_cpus()/put_online_cpus() block, to prevent anyone else
from messing with CPU hotplug at the same time.


If I understand your comment by mistake, please let me know.
If the contents is wrapped a inside get_online_cpus()/put_online_cpus() block
as below, cpu_down() will stop since cpu_down() calls cpu_hotplug_begin() and
cpu_hotplug_begin() waits for cpu_hotplug.refcount to become 0.



You are right. Sorry, I overlooked that.


+   get_online_cpus()
+   if (cpu_online(pr->id)) {
+   ret = cpu_down(pr->id);
+   if (ret)
+   return ret;
+   }
+   put_online_cpus()

I think following patch can prevent it correctly. How about the patch?

---
  drivers/acpi/processor_driver.c |   12 
  kernel/cpu.c|8 +---
  2 files changed, 17 insertions(+), 3 deletions(-)

Index: linux-3.5-rc4/drivers/acpi/processor_driver.c
===
--- linux-3.5-rc4.orig/drivers/acpi/processor_driver.c  2012-07-09 
09:59:01.280211202 +0900
+++ linux-3.5-rc4/drivers/acpi/processor_driver.c   2012-07-09 
11:05:34.559859236 +0900
@@ -844,14 +844,26 @@ static int acpi_processor_handle_eject(s
  {
int ret;

+retry:
if (cpu_online(pr->id)) {
ret = cpu_down(pr->id);
if (ret)
return ret;
}

+   get_online_cpus();
+   /*
+* Someone might online the cpu again at this point. So we check that
+* cpu has been onlined or not. If cpu is online, we try to offline
+* the cpu again.
+*/
+   if (cpu_online(pr->id)) {


How about this:
if (unlikely(cpu_online(pr->id)) {
since the probability of this happening is quite small...


+   put_online_cpus();
+   goto retry;
+   }
arch_unregister_cpu(pr->id);
acpi_unmap_lsapic(pr->id);
+   put_online_cpus();
return ret;
  }


This retry logic doesn't look elegant, but I don't see any better method :-(


Another possible option is to fail the request instead of retrying it.


Good idea!! I'll update it.



It would be quite challenging to allow on-lining and off-lining
operations to run concurrently.  In fact, even if we close this window,
there is yet another window right after the new put_online_cpus() call.


I think if we close the window, another window does not open.
acpi_unmap_lsapic() sets cpu_present mask to false before new put_online_cpus()
is called. So even if _cpu_up() is called, the function returns -EINAVL by
following added code.

@@ -343,11 +343,13 @@ static int __cpuinit _cpu_up(unsigned in
unsigned long mod = tasks_frozen ? 

Re: Subject: [PATCH] tty ldisc: Close/Reopen race prevention should check the proper flag

[Shachar Shemesh]

On 07/09/2012 07:44 PM, Greg KH wrote:

Yes, that worked, but then I would have to edit the body to include the
above information in the patch properly.

So, care to resend it all in a "clean" format that I can apply it in?

thanks,

greg k-h


After a few tests, it seems the only reliable way to get my mailer to 
not munge the tabs is an attachment. I've included the entire details 
inside the attachment. Hopefully, that will be parsable to everyone.


Shachar
From: Shachar Shemesh 

Commit acfa747b introduced the TTY_HUPPING flag to distinguish
closed TTY from currently closing ones. The test in tty_set_ldisc
still remained pointing at the old flag. This causes pppd to
sometimes lapse into uninterruptible sleep when killed and
restarted.

Signed-off-by: Shachar Shemesh 
---
Tested with 3.2.20 kernel.

diff --git a/drivers/tty/tty_ldisc.c b/drivers/tty/tty_ldisc.c
index 24b95db..a662a24 100644
--- a/drivers/tty/tty_ldisc.c
+++ b/drivers/tty/tty_ldisc.c
@@ -658,7 +658,7 @@ int tty_set_ldisc(struct tty_struct *tty, int ldisc)
 		goto enable;
 	}
 
-	if (test_bit(TTY_HUPPED, >flags)) {
+	if (test_bit(TTY_HUPPING, >flags)) {
 		/* We were raced by the hangup method. It will have stomped
 		   the ldisc data and closed the ldisc down */
 		clear_bit(TTY_LDISC_CHANGING, >flags);

Re: [PATCH 2/6] workqueue: factor out worker_pool from global_cwq

[Namhyung Kim]

Hi, Tejun

Just nitpicks..


On Mon,  9 Jul 2012 11:41:51 -0700, Tejun Heo wrote:
> Move worklist and all worker management fields from global_cwq into
> the new struct worker_pool.  worker_pool points back to the containing
> gcwq.  worker and cpu_workqueue_struct are updated to point to
> worker_pool instead of gcwq too.
>
> This change is mechanical and doesn't introduce any functional
> difference other than rearranging of fields and an added level of
> indirection in some places.  This is to prepare for multiple pools per
> gcwq.
>
> Signed-off-by: Tejun Heo 
> ---
>  include/trace/events/workqueue.h |2 +-
>  kernel/workqueue.c   |  216 -
>  2 files changed, 118 insertions(+), 100 deletions(-)
>
> diff --git a/include/trace/events/workqueue.h 
> b/include/trace/events/workqueue.h
> index 4018f50..f28d1b6 100644
> --- a/include/trace/events/workqueue.h
> +++ b/include/trace/events/workqueue.h
> @@ -54,7 +54,7 @@ TRACE_EVENT(workqueue_queue_work,
>   __entry->function   = work->func;
>   __entry->workqueue  = cwq->wq;
>   __entry->req_cpu= req_cpu;
> - __entry->cpu= cwq->gcwq->cpu;
> + __entry->cpu= cwq->pool->gcwq->cpu;
>   ),
>  
>   TP_printk("work struct=%p function=%pf workqueue=%p req_cpu=%u cpu=%u",
> diff --git a/kernel/workqueue.c b/kernel/workqueue.c
> index 27637c2..bc43a0c 100644
> --- a/kernel/workqueue.c
> +++ b/kernel/workqueue.c
> @@ -115,6 +115,7 @@ enum {
>   */
>  
>  struct global_cwq;
> +struct worker_pool;
>  
>  /*
>   * The poor guys doing the actual heavy lifting.  All on-duty workers
> @@ -131,7 +132,7 @@ struct worker {
>   struct cpu_workqueue_struct *current_cwq; /* L: current_work's cwq */
>   struct list_headscheduled;  /* L: scheduled works */
>   struct task_struct  *task;  /* I: worker task */
> - struct global_cwq   *gcwq;  /* I: the associated gcwq */
> + struct worker_pool  *pool;  /* I: the associated pool */
>   /* 64 bytes boundary on 64bit, 32 on 32bit */
>   unsigned long   last_active;/* L: last active timestamp */
>   unsigned intflags;  /* X: flags */
> @@ -139,6 +140,21 @@ struct worker {
>   struct work_struct  rebind_work;/* L: rebind worker to cpu */
>  };
>  
> +struct worker_pool {
> + struct global_cwq   *gcwq;  /* I: the owning gcwq */
> +
> + struct list_headworklist;   /* L: list of pending works */
> + int nr_workers; /* L: total number of workers */
> + int nr_idle;/* L: currently idle ones */
> +
> + struct list_headidle_list;  /* X: list of idle workers */
> + struct timer_list   idle_timer; /* L: worker idle timeout */
> + struct timer_list   mayday_timer;   /* L: SOS timer for dworkers */

What is 'dworkers'?


> +
> + struct ida  worker_ida; /* L: for worker IDs */
> + struct worker   *first_idle;/* L: first idle worker */
> +};
> +
>  /*
>   * Global per-cpu workqueue.  There's one and only one for each cpu
>   * and all works are queued and processed here regardless of their
> @@ -146,27 +162,18 @@ struct worker {
>   */
>  struct global_cwq {
>   spinlock_t  lock;   /* the gcwq lock */
> - struct list_headworklist;   /* L: list of pending works */
>   unsigned intcpu;/* I: the associated cpu */
>   unsigned intflags;  /* L: GCWQ_* flags */
>  
> - int nr_workers; /* L: total number of workers */
> - int nr_idle;/* L: currently idle ones */
> -
> - /* workers are chained either in the idle_list or busy_hash */
> - struct list_headidle_list;  /* X: list of idle workers */
> + /* workers are chained either in busy_head or pool idle_list */

s/busy_head/busy_hash/ ?

Thanks,
Namhyung


>   struct hlist_head   busy_hash[BUSY_WORKER_HASH_SIZE];
>   /* L: hash of busy workers */
>  
> - struct timer_list   idle_timer; /* L: worker idle timeout */
> - struct timer_list   mayday_timer;   /* L: SOS timer for dworkers */
> -
> - struct ida  worker_ida; /* L: for worker IDs */
> + struct worker_pool  pool;   /* the worker pools */
>  
>   struct task_struct  *trustee;   /* L: for gcwq shutdown */
>   unsigned inttrustee_state;  /* L: trustee state */
>   wait_queue_head_t   trustee_wait;   /* trustee wait */
> - struct worker   *first_idle;/* L: first idle worker */
>  } cacheline_aligned_in_smp;
>  
>  /*
--
To unsubscribe from this list: send the line "unsubscribe 

Re: rcu_dyntick and suspicious RCU usage

[Fengguang Wu]

Hi Paul,

Fortunately this bug is bisectable and the first bad commit is:

commit 9b2e4f1880b789be1f24f9684f7a54b90310b5c0
Author: Paul E. McKenney 
Date:   Fri Sep 30 12:10:22 2011 -0700

rcu: Track idleness independent of idle tasks

However, at that commit, the error messages are a bit different:

[1.665656] WARNING: at /c/wfg/linux/kernel/rcutiny.c:67 
rcu_idle_enter_common+0x103/0x1b2()
[1.668811] WARNING: at /c/wfg/linux/kernel/rcutiny.c:112 
rcu_idle_exit_common+0xfa/0x18c()
[4.758670] WARNING: at /c/wfg/linux/kernel/trace/trace_events.c:1720 
event_trace_self_tests_init+0x87/0x11b()

Here is the first back trace:

[1.660165] Testing tracer function: 
[1.664825] [ cut here ]
[1.665656] WARNING: at /c/wfg/linux/kernel/rcutiny.c:67 
rcu_idle_enter_common+0x103/0x1b2()
[1.667006] Hardware name: Bochs
[1.667583] Modules linked in:
[1.668106] Pid: 0, comm: swapper Not tainted 3.2.0-rc5+ #41
[1.668811] Call Trace:
[1.668811]  [] ? printk+0x2b/0x3b
[1.668811]  [] warn_slowpath_common+0xfc/0x13b
[1.668811]  [] ? rcu_idle_enter_common+0x103/0x1b2
[1.668811]  [] ? rcu_idle_enter_common+0x103/0x1b2
[1.668811]  [] warn_slowpath_null+0x3e/0x4e
[1.668811]  [] rcu_idle_enter_common+0x103/0x1b2
[1.668811]  [] rcu_irq_exit+0x1f8/0x20f
[1.668811]  [] irq_exit+0x117/0x14d
[1.668811]  [] do_IRQ+0xe5/0x106
[1.668811]  [] ? trace_hardirqs_off_caller+0x97/0x167
[1.668811]  [] common_interrupt+0x35/0x3c
[1.668811]  [] ? print_shortest_lock_dependencies+0xec/0x292
[1.668811]  [] ? native_safe_halt+0x18/0x28
[1.668811]  [] default_idle+0xd7/0x1f0
[1.668811]  [] cpu_idle+0x1c4/0x2c8
[1.668811]  [] rest_init+0x1db/0x1ef
[1.668811]  [] ? reciprocal_value+0x64/0x64
[1.668811]  [] start_kernel+0x8e5/0x8f9
[1.668811]  [] ? loglevel+0x55/0x55
[1.668811]  [] ? reserve_ebda_region+0xb9/0xc9
[1.668811]  [] i386_start_kernel+0x13a/0x14f

Thanks,
Fengguang
[0.00] Initializing cgroup subsys cpuset
[0.00] Initializing cgroup subsys cpu
[0.00] Linux version 3.2.0-rc5+ (wfg@bee) (gcc version 4.7.0 (Debian 
4.7.1-1) ) #41 PREEMPT Tue Jul 10 12:38:54 CST 2012
[0.00] KERNEL supported cpus:
[0.00]   AMD AuthenticAMD
[0.00]   Centaur CentaurHauls
[0.00]   Transmeta GenuineTMx86
[0.00]   Transmeta TransmetaCPU
[0.00] CPU: vendor_id 'GenuineIntel' unknown, using generic init.
[0.00] CPU: Your system may be unstable.
[0.00] BIOS-provided physical RAM map:
[0.00]  BIOS-e820:  - 0009f400 (usable)
[0.00]  BIOS-e820: 0009f400 - 000a (reserved)
[0.00]  BIOS-e820: 000f - 0010 (reserved)
[0.00]  BIOS-e820: 0010 - 0fffd000 (usable)
[0.00]  BIOS-e820: 0fffd000 - 1000 (reserved)
[0.00]  BIOS-e820: fffbc000 - 0001 (reserved)
[0.00] debug: ignoring loglevel setting.
[0.00] Notice: NX (Execute Disable) protection cannot be enabled: 
non-PAE kernel!
[0.00] DMI 2.4 present.
[0.00] DMI: Bochs Bochs, BIOS Bochs 01/01/2007
[0.00] e820 update range:  - 0001 (usable) 
==> (reserved)
[0.00] e820 remove range: 000a - 0010 (usable)
[0.00] last_pfn = 0xfffd max_arch_pfn = 0x10
[0.00] initial memory mapped : 0 - 0240
[0.00] Base memory trampoline at [c009e000] 9e000 size 4096
[0.00] init_memory_mapping: -0fffd000
[0.00]  00 - 40 page 4k
[0.00]  40 - 000fc0 page 2M
[0.00]  000fc0 - 000fffd000 page 4k
[0.00] kernel direct mapping tables up to fffd000 @ 23fb000-240
[0.00] log_buf_len: 8388608
[0.00] early log buf free: 129089(98%)
[0.00] RAMDISK: 0e73f000 - 0fff
[0.00] 0MB HIGHMEM available.
[0.00] 255MB LOWMEM available.
[0.00]   mapped low ram: 0 - 0fffd000
[0.00]   low ram: 0 - 0fffd000
[0.00] kvm-clock: Using msrs 12 and 11
[0.00] kvm-clock: cpu 0, msr 0:15ed781, boot clock
[0.00] Zone PFN ranges:
[0.00]   Normal   0x0010 -> 0xfffd
[0.00]   HighMem  empty
[0.00] Movable zone start PFN for each node
[0.00] early_node_map[2] active PFN ranges
[0.00] 0: 0x0010 -> 0x009f
[0.00] 0: 0x0100 -> 0xfffd
[0.00] On node 0 totalpages: 65420
[0.00] free_area_init_node: node 0, pgdat c16ac510, node_mem_map 
cdd3f200
[0.00]   Normal zone: 512 pages used for memmap
[0.00]   Normal zone: 0 pages reserved
[0.00]   Normal zone: 64908 pages, LIFO batch:15
[0.00] SFI: Simple Firmware Interface v0.81 

Re: [PATCH v4 1/5] thermal: Add generic cpufreq cooling implementation

[amit kachhap]

Hi Rob/Eduardo,

As these patches have still not made into mainline. I will rebase the
whole set along with your suggestion and send them shortly.
Sorry for late reply.

Thanks,
Amit Daniel

On Tue, Jun 26, 2012 at 1:12 PM, Valentin, Eduardo
 wrote:
> Hey Rob and Amit,
>
> On Tue, Jun 26, 2012 at 6:12 AM, Rob Lee  wrote:
>> Hey Amit,
>>
>> I was just re-organizing the imx thermal driver that uses this cpu
>> cooling interface and noticed a couple of small issues here.   If
>
> While rewriting the OMAP BG driver on top of this series I noticed
> similar issues. Apart from those pointed by Rob, I have another minor
> fix.
>
>> these suggestions are agreed upon and if it's too late for these
>> issues be changed with this patchset, I can submit them separately
>> unless you'd prefer to.
>>
>> On Sat, May 12, 2012 at 4:40 AM, Amit Daniel Kachhap
>>  wrote:
>>> This patch adds support for generic cpu thermal cooling low level
>>> implementations using frequency scaling up/down based on the registration
>>> parameters. Different cpu related cooling devices can be registered by the
>>> user and the binding of these cooling devices to the corresponding
>>> trip points can be easily done as the registration APIs return the
>>> cooling device pointer. The user of these APIs are responsible for
>>> passing clipping frequency . The drivers can also register to recieve
>>> notification about any cooling action called.
>>>
>>> Signed-off-by: Amit Daniel Kachhap 
>>> ---
>>>  Documentation/thermal/cpu-cooling-api.txt |   60 
>>>  drivers/thermal/Kconfig   |   11 +
>>>  drivers/thermal/Makefile  |3 +-
>>>  drivers/thermal/cpu_cooling.c |  483 
>>> +
>>>  include/linux/cpu_cooling.h   |   99 ++
>>>  5 files changed, 655 insertions(+), 1 deletions(-)
>>>  create mode 100644 Documentation/thermal/cpu-cooling-api.txt
>>>  create mode 100644 drivers/thermal/cpu_cooling.c
>>>  create mode 100644 include/linux/cpu_cooling.h
>>>
>>> diff --git a/Documentation/thermal/cpu-cooling-api.txt 
>>> b/Documentation/thermal/cpu-cooling-api.txt
>>> new file mode 100644
>>> index 000..557adb8
>>> --- /dev/null
>>> +++ b/Documentation/thermal/cpu-cooling-api.txt
>>> @@ -0,0 +1,60 @@
>>> +CPU cooling APIs How To
>>> +===
>>> +
>>> +Written by Amit Daniel Kachhap 
>>> +
>>> +Updated: 12 May 2012
>>> +
>>> +Copyright (c)  2012 Samsung Electronics Co., Ltd(http://www.samsung.com)
>>> +
>>> +0. Introduction
>>> +
>>> +The generic cpu cooling(freq clipping, cpuhotplug etc) provides
>>> +registration/unregistration APIs to the caller. The binding of the cooling
>>> +devices to the trip point is left for the user. The registration APIs 
>>> returns
>>> +the cooling device pointer.
>>> +
>>> +1. cpu cooling APIs
>>> +
>>> +1.1 cpufreq registration/unregistration APIs
>>> +1.1.1 struct thermal_cooling_device *cpufreq_cooling_register(
>>> +   struct freq_clip_table *tab_ptr, unsigned int tab_size)
>>> +
>>> +This interface function registers the cpufreq cooling device with the 
>>> name
>>> +"thermal-cpufreq-%x". This api can support multiple instances of 
>>> cpufreq
>>> +cooling devices.
>>> +
>>> +tab_ptr: The table containing the maximum value of frequency to be 
>>> clipped
>>> +for each cooling state.
>>> +   .freq_clip_max: Value of frequency to be clipped for each allowed
>>> +cpus.
>>> +   .temp_level: Temperature level at which the frequency clamping will
>>> +   happen.
>>> +   .mask_val: cpumask of the allowed cpu's
>>> +tab_size: the total number of cpufreq cooling states.
>>> +
>>> +1.1.2 void cpufreq_cooling_unregister(struct thermal_cooling_device *cdev)
>>> +
>>> +This interface function unregisters the "thermal-cpufreq-%x" cooling 
>>> device.
>>> +
>>> +cdev: Cooling device pointer which has to be unregistered.
>>> +
>>> +
>>> +1.2 CPU cooling action notifier register/unregister interface
>>> +1.2.1 int cputherm_register_notifier(struct notifier_block *nb,
>>> +   unsigned int list)
>>> +
>>> +This interface registers a driver with cpu cooling layer. The driver 
>>> will
>>> +be notified when any cpu cooling action is called.
>>> +
>>> +nb: notifier function to register
>>> +list: CPUFREQ_COOLING_START or CPUFREQ_COOLING_STOP
>>> +
>>> +1.2.2 int cputherm_unregister_notifier(struct notifier_block *nb,
>>> +   unsigned int list)
>>> +
>>> +This interface registers a driver with cpu cooling layer. The driver 
>>> will
>>> +be notified when any cpu cooling action is called.
>>> +
>>> +nb: notifier function to register
>>> +list: CPUFREQ_COOLING_START or CPUFREQ_COOLING_STOP
>>> diff --git a/drivers/thermal/Kconfig b/drivers/thermal/Kconfig
>>> index 514a691..d9c529f 100644
>>> --- a/drivers/thermal/Kconfig
>>> +++ b/drivers/thermal/Kconfig
>>> @@ -19,6 +19,17 @@ config THERMAL_HWMON
>>>depends on 

Re: why Linux kernel will update BIOS's interrupt remapping table base address ? why does Linux Kernel create a new table instead of the one that BIOS provided ?

[Yinghai Lu]

On Mon, Jul 9, 2012 at 8:17 PM, Lin-Bao Zhang <2004.zh...@gmail.com> wrote:
> for this thing , we have known that , we can append "x2apic_phys" to
> tell linux kernel we support x2apic physical mode.
> but I found that x2apic_phys is not enough .we still found panic info
> in RHEL6.2(2.6.32) kernel,but on linux kernel-3.4.4 ,no this issue
> again.  any comment for this bug ?

please post full boot log with kernel 3.4.4 and acpidump.

Thanks

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/

Re: [PATCH v3] ext4: fix hole punch failure when depth is greater than 0

[Ashish Sangwan]

Please ignore the last sent mail.
I will re-send the patch in new mail chain.

Thanks,
Ashish
On Tue, Jul 10, 2012 at 6:13 AM, Ashish Sangwan
 wrote:
> Whether to continue removing extents or not is decided by the return value
> of function ext4_ext_more_to_rm() which checks 2 conditions:
> a) if there are no more indexes to process.
> b) if the number of entries are decreased in the header of "depth -1".
>
> In case of hole punch, if the last block to be removed is not part of the
> last extent index than this index will not be deleted, hence the number of
> valid entries in the extent header of "depth - 1" will remain as it is and
> ext4_ext_more_to_rm will return 0 although the required blocks are not
> yet removed.
>
> This patch fixes the above mentioned problem as instead of removing the
> extents from the end of file, it starts removing the blocks from the
> particular extent from which removing blocks is actually required and
> continue backward until done.
>
> Signed-off-by: Ashish Sangwan 
> Signed-off-by: Namjae Jeon 
> Reviewed-by: Lukas Czerner 
> ---
>  fs/ext4/extents.c |   46 +-
>  1 file changed, 29 insertions(+), 17 deletions(-)
>
> diff --git a/fs/ext4/extents.c b/fs/ext4/extents.c
> index 91341ec..45ac45d 100644
> --- a/fs/ext4/extents.c
> +++ b/fs/ext4/extents.c
> @@ -2570,10 +2570,10 @@ static int ext4_ext_remove_space(struct inode *inode, 
> ext4_lblk_t start,
>  {
> struct super_block *sb = inode->i_sb;
> int depth = ext_depth(inode);
> -   struct ext4_ext_path *path;
> +   struct ext4_ext_path *path = NULL;
> ext4_fsblk_t partial_cluster = 0;
> handle_t *handle;
> -   int i, err;
> +   int i = 0, err;
>
> ext_debug("truncate since %u to %u\n", start, end);
>
> @@ -2606,8 +2606,12 @@ again:
> }
> depth = ext_depth(inode);
> ex = path[depth].p_ext;
> -   if (!ex)
> +   if (!ex) {
> +   ext4_ext_drop_refs(path);
> +   kfree(path);
> +   path = NULL;
> goto cont;
> +   }
>
> ee_block = le32_to_cpu(ex->ee_block);
>
> @@ -2637,8 +2641,6 @@ again:
> if (err < 0)
> goto out;
> }
> -   ext4_ext_drop_refs(path);
> -   kfree(path);
> }
>  cont:
>
> @@ -2647,19 +2649,27 @@ cont:
>  * after i_size and walking into the tree depth-wise.
>  */
> depth = ext_depth(inode);
> -   path = kzalloc(sizeof(struct ext4_ext_path) * (depth + 1), GFP_NOFS);
> -   if (path == NULL) {
> -   ext4_journal_stop(handle);
> -   return -ENOMEM;
> -   }
> -   path[0].p_depth = depth;
> -   path[0].p_hdr = ext_inode_hdr(inode);
> +   if (path) {
> +   int k = i = depth;
> +   while (--k > 0)
> +   path[k].p_block =
> +   le16_to_cpu(path[k].p_hdr->eh_entries)+1;
> +   } else {
> +   path = kzalloc(sizeof(struct ext4_ext_path) * (depth + 1),
> +  GFP_NOFS);
> +   if (path == NULL) {
> +   ext4_journal_stop(handle);
> +   return -ENOMEM;
> +   }
> +   path[0].p_depth = depth;
> +   path[0].p_hdr = ext_inode_hdr(inode);
>
> -   if (ext4_ext_check(inode, path[0].p_hdr, depth)) {
> -   err = -EIO;
> -   goto out;
> +   if (ext4_ext_check(inode, path[0].p_hdr, depth)) {
> +   err = -EIO;
> +   goto out;
> +   }
> }
> -   i = err = 0;
> +   err = 0;
>
> while (i >= 0 && err == 0) {
> if (i == depth) {
> @@ -2773,8 +2783,10 @@ cont:
>  out:
> ext4_ext_drop_refs(path);
> kfree(path);
> -   if (err == -EAGAIN)
> +   if (err == -EAGAIN) {
> +   path = NULL
> goto again;
> +   }
> ext4_journal_stop(handle);
>
> return err;
> --
> 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/

Re: [PATCH v1] usb: host: Fix possible kernel crash

[Venu Byravarasu]

Thanks Alan for your comments.

On Monday 09 July 2012 08:04 PM, Alan Stern wrote:

On Mon, 9 Jul 2012, Venu Byravarasu wrote:


In functions itd_complete &  sitd_complete, a pointer
by name stream may get dereferenced after freeing it, when
iso_stream_put is called with stream->refcount = 2.

I don't understand the problem.  Did you actually see this happen or is
it only theoretical?


Yes it is a theoretical problem, as complained by Coverity.


/* for each uframe with a packet */
for (uframe = 0; uframe < 8; uframe++) {
@@ -1783,7 +1784,8 @@ itd_complete (
dev->devpath, stream->bEndpointAddress & 0x0f,
(stream->bEndpointAddress & USB_DIR_IN) ? "in" : "out");
}
-   iso_stream_put (ehci, stream);
+   stream_ref_count = stream->refcount;
+   iso_stream_put(ehci, stream);
This iso_stream_put removes the reference held by the URB.  Before it
is called, stream->refcount must be >= 3:

refcount is set to 1 when the stream is created;

each active URB holds a reference;

each itd holds a reference.

So after the call, the refcount value must be >= 2 and the stream could
not have been deallocated.


  done:
itd->urb = NULL;
@@ -1797,7 +1799,7 @@ done:
 * Move it to a safe place until a new frame starts.
 */
list_move(>itd_list, >cached_itd_list);
-   if (stream->refcount == 2) {
+   if (stream_ref_count == 3) {

Therefore this seems unnecessary.


As per the logic you explained above, this change is not needed.
However coverity was complaining as below:

/kernel/drivers/usb/host/ehci-sched.c 1777 USE_AFTER_FREE Dereferencing 
freed pointer "stream"


Hence to pacify coverity, this change is done.
Please let me know if you see any other better way to handle it.


/* If iso_stream_put() were called here, stream
 * would be freed.  Instead, just prevent reuse.
 */

Alan Stern



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

Re: [PATCH] net: cgroup: fix access the unallocated memory in netprio cgroup

[Eric Dumazet]

On Tue, 2012-07-10 at 10:31 +0800, Gao feng wrote:
> there are some out of bound accesses in netprio cgroup.
> when creating a new netprio cgroup,we only set a prioidx for
> the new cgroup,without allocate memory for dev->priomap.
> 
> because we don't want to see additional bound checkings in
> fast path, so I think the best way is to allocate memory when we
> creating a new netprio cgroup.
> 
> and because netdev can be created or registered after cgroup being
> created, so extend_netdev_table is also needed in write_priomap.
> 
> this patch add a return value for update_netdev_tables & extend_netdev_table,
> so when new_priomap is allocated failed,write_priomap will stop to access
> the priomap,and return -ENOMEM back to the userspace to tell the user
> what happend.
> 
> Signed-off-by: Gao feng 
> Cc: Neil Horman 
> Cc: Eric Dumazet 
> ---

>  static void cgrp_destroy(struct cgroup *cgrp)
> @@ -221,7 +233,10 @@ static int write_priomap(struct cgroup *cgrp, struct 
> cftype *cft,
>   if (!dev)
>   goto out_free_devname;
>  
> - update_netdev_tables();
> + ret = update_netdev_tables();
> + if (ret < 0)
> + goto out_free_devname;
> +
>   ret = 0;
>   rcu_read_lock();
>   map = rcu_dereference(dev->priomap);

Hi Gao

Is it still needed to call update_netdev_tables() from write_priomap() ?



--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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: Boot regression on Mackerel with current mainline

[Chris Ball]

Hi Guennadi,

On Wed, Jul 04 2012, Guennadi Liakhovetski wrote:
> On Tue, 3 Jul 2012, Rafael J. Wysocki wrote:
>
>> On Tuesday, July 03, 2012, Guennadi Liakhovetski wrote:
>> > Hi Rafael
>> > 
>> > On Tue, 3 Jul 2012, Rafael J. Wysocki wrote:
>> > 
>> > > Hi,
>> > > 
>> > > We seem to have a functional regression on Mackerel with 3.5-rc5 which
>> > > seems to be related to SDHI.  Namely, the SDHI driver appears to wait 
>> > > forever
>> > > for the devices to appear and commenting out all of the sdhi devices in 
>> > > the
>> > > board file works around the problem.
>> > > 
>> > > I can investigate some more later today if need be.
>> > 
>> > Have you checked the logs? Are you seeing any of these in the kernel log:
>> > 
>> > genirq: Threaded irq requested with handler=NULL and !ONESHOT for irq 
>> 
>> I see this only once per boot, but then sh_mobile_sdhi is saying "timeout
>> waiting for hardware interrupt" pretty much continuously.
>
> Yes, that's the one. Ok, let's fix it in the driver. In fact, a fix has 
> already been submitted, but for 3.6. I hoped, 3.5 would resort to a softer 
> form of the ONESHOT failing, so, I didn't push it for -rc. I think, the 
> easiest would be to apply these two patches:
>
> "mmc: tmio: use MMC opcode defines instead of numbers"
> http://git.kernel.org/?p=linux/kernel/git/cjb/mmc.git;a=commit;h=598cd9cc217b0aa46089a3838a8b1c37b97aa08b
>
> and
>
> "mmc: extend and rename cd-gpio helpers to handle more slot GPIO functions"
> http://git.kernel.org/?p=linux/kernel/git/cjb/mmc.git;a=commit;h=d8e60fb51effc83e6f53de191a8440f46e5a3f2c
>
> The latter one looks big because of a rename, but with "-M" it's pretty 
> trivial. Chris, do you agree?

Is the minimal fix to just add "| IRQF_ONESHOT" to the request_threaded_irq
argument?  If so, I'd rather push just that for 3.5, and I can take care of
having that change appear simultaneously in linux-next so that there aren't
any conflicts.  Is that okay with you?

Thanks,

- Chris.
-- 
Chris Ball  
One Laptop Per Child
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] apple-gmux: Restore switch registers on suspend/resume

[Arun Raghavan]

After suspend and resume, the values of these registers seem to change
from what they were at suspend time, potentially preventing the actual
output lines from being enabled post-resume. This saves relevant state
at suspend and restores it when resumed.

This is at least required on the MacBook Pro 8.2 when the Intel GPU is
manually selected in GRUB config before the kernel is loaded.

Signed-off-by: Arun Raghavan 
---
 drivers/platform/x86/apple-gmux.c |   29 -
 1 files changed, 28 insertions(+), 1 deletions(-)

diff --git a/drivers/platform/x86/apple-gmux.c 
b/drivers/platform/x86/apple-gmux.c
index 694a15a..5a5d005 100644
--- a/drivers/platform/x86/apple-gmux.c
+++ b/drivers/platform/x86/apple-gmux.c
@@ -26,6 +26,11 @@ struct apple_gmux_data {
unsigned long iolen;
 
struct backlight_device *bdev;
+
+   bool was_suspended;
+   u8 save_switch_ddc;
+   u8 save_switch_disp;
+   u8 save_switch_ext;
 };
 
 /*
@@ -87,8 +92,30 @@ static int gmux_update_status(struct backlight_device *bd)
struct apple_gmux_data *gmux_data = bl_get_data(bd);
u32 brightness = bd->props.brightness;
 
-   if (bd->props.state & BL_CORE_SUSPENDED)
+   if (bd->props.state & BL_CORE_SUSPENDED) {
+   /* Save mux settings for output lines since they get reset on
+* suspend */
+   gmux_data->was_suspended = TRUE;
+   gmux_data->save_switch_ddc = gmux_read8(gmux_data,
+   GMUX_PORT_SWITCH_DDC);
+   gmux_data->save_switch_disp = gmux_read8(gmux_data,
+   GMUX_PORT_SWITCH_DISPLAY);
+   gmux_data->save_switch_ext = gmux_read8(gmux_data,
+   GMUX_PORT_SWITCH_EXTERNAL);
+
return 0;
+   }
+
+   if (gmux_data->was_suspended) {
+   /* Restore pre-suspend values for output lines */
+   gmux_data->was_suspended = FALSE;
+   gmux_write8(gmux_data, GMUX_PORT_SWITCH_DDC,
+   gmux_data->save_switch_ddc);
+   gmux_write8(gmux_data, GMUX_PORT_SWITCH_DISPLAY,
+   gmux_data->save_switch_disp);
+   gmux_write8(gmux_data, GMUX_PORT_SWITCH_EXTERNAL,
+   gmux_data->save_switch_ext);
+   }
 
/*
 * Older gmux versions require writing out lower bytes first then
-- 
1.7.8.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 0/3] PCI: P2P bridge window fixes

[Bjorn Helgaas]

On Mon, Jul 9, 2012 at 2:31 PM, Bjorn Helgaas  wrote:
> Two fixes here:
>
> 1) Zero is a legal P2P bridge window base and BAR value and is likely to
> occur when there is an offset between bus addresses and CPU addresses.
> Stop disallowing it.
>
> 2) The Intel-specific 1K I/O window granularity for P2P bridges was
> implemented in a way that precluded reassignment of the window after
> FINAL quirks.  Fix that.
>
> And also replace the sparc pci_cfg_fake_ranges() with the functionally
> equivalent generic version.
>
> ---
>
> Bjorn Helgaas (3):
>   PCI: allow P2P bridge windows starting at PCI bus address zero
>   PCI: reimplement P2P bridge 1K I/O windows (Intel P64H2)
>   sparc/PCI: replace pci_cfg_fake_ranges() with pci_read_bridge_bases()
>
>
>  arch/sparc/kernel/pci.c  |   89 
> +-
>  drivers/pci/probe.c  |   31 +---
>  drivers/pci/quirks.c |   39 +---
>  drivers/pci/setup-bus.c  |   11 +-
>  include/linux/pci.h  |1 +
>  include/linux/pci_regs.h |3 +-
>  6 files changed, 31 insertions(+), 143 deletions(-)

I applied these, as well as Yinghai's patch for 1K support in
pbus_size_io(), to my "next" branch.  Thanks, Yinghai!

Bjorn
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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/2] PCI: decode disable fixes

[Bjorn Helgaas]

On Mon, Jul 9, 2012 at 12:20 PM, Bjorn Helgaas  wrote:
> Since 2.6.36 (253d2e5498), we've disabled MEM & IO decoding while we size
> BARs (except for host bridge devices).  These patches tweak this in two
> ways:
>
> 1) We only kept decoding disabled while sizing the low-order dword
> of 64-bit BARs.  I think we should keep it disabled while we do the
> high-order dword also.
>
> 2) I think we should also disable decoding while updating 64-bit BARs,
> e.g., when we move a device into an aperture of an upstream bridge.  I'm
> only proposing to disable decoding for 64-bit BAR updates because 32-bit
> ones can be done atomically, while 64-bit updates require two writes and
> the half-written state is a potential problem.
>
> I'm considering these changes for the 3.6 merge window, which is
> approaching fast, so let me know if you see issues with either of these.
>
> ---
>
> Bjorn Helgaas (2):
>   PCI: leave MEM and IO decoding disabled during 64-bit BAR sizing, too
>   PCI: disable MEM decoding while updating 64-bit MEM BARs
>
>
>  drivers/pci/probe.c |6 +++---
>  drivers/pci/setup-res.c |   18 ++
>  2 files changed, 21 insertions(+), 3 deletions(-)

I applied these to my "next" branch.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] PCI: Add 'pci_fixup_final' quirks into hot-plug paths

[Bjorn Helgaas]

On Mon, Jul 9, 2012 at 3:35 PM, Myron Stowe  wrote:
> PCI's final quirks (pci_fixup_final) are currently invoked by
> pci_apply_final_quirk() which traverses the platform's list of PCI
> devices.  The calling mechanism, and to some point the use of the device
> list, limits the quirk invocations to a single instance during boot.  As
> such, hot-plugable devices do not have their associated final quirks
> called upon hot-plug events.
>
> This series implements a interim solution to integrate pci_fixup_final
> quirks into the various hot-plug event paths[1].
>
> The series basis is
> git://git.kernel.org/pub/scm/linux/kernel/git/helgaas/pci.git next
>
>   -v2: Re-worked PATCH 1/9 based on Bjorn's suggestion:
>http://marc.info/?l=linux-pci=134074984925361=2
>There is some more opportunity to clean this up even further
>if we re-work the script that gathers initcall data to accept
>'dev_dbg()' structured output.
>
>Replaced PATCHes 3/9-8/9 with 3/8-7/8 (I don't know what I
>was thinking with the original set).
>
>
> [1] I intended to come up with a single, uniform, solution that would
> satisfy both the boot path and the various hot-plug event paths with
> respect to final quirks.  From an architectural perspective, the proper
> placement for the final quirks is somewhere just prior to when drivers can
> probe and attach which would be the device_add path: pci_bus_add_devices
> or pci_bus_add device.
>
> I originally started with that approach but eventually realized that there
> are issues with moving the quirks into the device_add path with respect to
> booting.  Using the 'initcall_debug' boot command instrumentation, one
> can see that moving the final quirks into the device_add path would cause
> the quirks to be called substantially earlier during boot.  While there
> may be additional issues, two that were especially concerning were that
> the final quirks would be called *before* both 'pci_subsys_init' and
> 'pcibios_assign_resources'.
>
> Calling the quirks prior to resource assignment seems fraught with
> potential issues so I started looking into the various hot-plug paths and
> quickly noticed asymmetry with respect to PCI device setup between the
> boot path and the hot-plug paths.
>
> Currently, the boot path scans the PCI devices, adds the devices, assigns
> resources, and then call the final quirks whereas the hot-plug paths scan,
> assign resources, and then add the devices which is better sequencing with
> respect to the assignment of resources and the addition of devices (i.e.
> resource assignment occurs *before* a driver can probe and attach).
>
> All of this suggests that we should change PCI device setup in the boot
> path to be more like hot-plug: scan, assign resources, (final fixups,)
> then add.  While I think that is the correct approach, and something that
> we should be addressing, it will require a lot of work.  So until that
> occurs, this series should serve as a stop-gap solution for the interim.
>
> When the boot path's PCI device setup is addressed we should end up with a
> single, uniform, device_add based solution for applying final quirks
> after:
>   o  removing 'fs_initcall_sync(pci_apply_final_quirks);',
>   o  removing the global variable 'pci_fixup_final_inited' and all
>  of its usages,
>   o  renaming, and moving, the 'pci_cache_line_size' related code
>  currently embedded in 'pci_apply_final_quirks()'.
>
> Note: I do not have a cross-compile environment so I have only tested x86.
> ---
>
> Myron Stowe (8):
>   PCI: Integrate 'pci_fixup_final' quirks into hot-plug paths
>   PCI: Move final fixup quirks from __init to __devinit
>   x86/PCI: Move final fixup quirks from __init to __devinit
>   MIPS/PCI: Move final fixup quirks from __init to __devinit
>   alpha/PCI: Move final fixup quirks from __init to __devinit
>   PCI: Adjust section annotations of various quirks
>   PCI: release temporary reference in __nv_msi_ht_cap_quirk()
>   PCI: Restructure 'pci_do_fixups()'
>
>
>  arch/alpha/kernel/pci.c |2 -
>  arch/mips/mti-malta/malta-pci.c |2 -
>  arch/mips/pci/ops-tx4927.c  |2 -
>  arch/mips/txx9/generic/pci.c|4 +
>  arch/x86/kernel/quirks.c|2 -
>  drivers/pci/bus.c   |4 +
>  drivers/pci/quirks.c|  107 
> ++-
>  7 files changed, 81 insertions(+), 42 deletions(-)
>
> --

Thanks, I added this to my "next" branch and pushed it.

The alpha quirks fix was already in my "next" branch, so I dropped that patch:
http://git.kernel.org/?p=linux/kernel/git/helgaas/pci.git;a=commitdiff;h=8ff255afb022b8e183c7aa1ecc4ba8d0563e1e17

Bjorn
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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: why Linux kernel will update BIOS's interrupt remapping table base address ? why does Linux Kernel create a new table instead of the one that BIOS provided ?

[Lin-Bao Zhang]

for this thing , we have known that , we can append "x2apic_phys" to
tell linux kernel we support x2apic physical mode.
but I found that x2apic_phys is not enough .we still found panic info
in RHEL6.2(2.6.32) kernel,but on linux kernel-3.4.4 ,no this issue
again.  any comment for this bug ?

Initializing cgroup subsys ns
Initializing cgroup subsys cpuacct
Initializing cgroup subsys memory
Initializing cgroup subsys devices
Initializing cgroup subsys freezer
Initializing cgroup subsys net_cls
Initializing cgroup subsys blkio
Initializing cgroup subsys perf_event
CPU: Physical Processor ID: 0
CPU: Processor Core ID: 0
mce: CPU supports 24 MCE banks
CPU0: Thermal monitoring enabled (TM1)
using mwait in idle threads.
ACPI: Core revision 20090903
ftrace: converting mcount calls to 0f 1f 44 00 00
ftrace: allocating 20776 entries in 82 pages
DMAR: Host address width 40
DMAR: DRHD base: 0x00ace0 flags: 0x0
IOMMU ace0: ver 1:0 cap c90780106f0462 ecap f0207e
DMAR: DRHD base: 0x00a800 flags: 0x1
IOMMU a800: ver 1:0 cap c90780106f0462 ecap f0207e
DMAR: RMRR base: 0x007f7ee000 end: 0x007f7e
DMAR: RMRR base: 0x007f7e7000 end: 0x007f7ecfff
DMAR: RMRR base: 0x007f61e000 end: 0x007f61
DMAR: ATSR flags: 0x0
DMAR: ATSR flags: 0x0
IOAPIC id 10 under DRHD base 0xace0
IOAPIC id 8 under DRHD base 0xa800
IOAPIC id 0 under DRHD base 0xa800
Enabled IRQ remapping in x2apic modef
NMI: IOCK error (debug interrupt?)
CPU 0
Modules linked in:

Pid: 1, comm: swapper Not tainted 2.6.32-220.el6.x86_64 #1 HP ProLiant DL980 G7
RIP: 0010:[]  []
mask_and_ack_8259A+0x57/0x110
RSP: 0018:880045603f08  EFLAGS: 0046
RAX: 00ff RBX:  RCX: 01c0
RDX: 0082 RSI: 81a83240 RDI: 81dd65e0
RBP: 880045603f28 R08: 88086c42e000 R09: 88086c42fe30
R10: 0001 R11:  R12: 
R13: 0082 R14: 88086c42fd88 R15: 00015e40
FS:  () GS:88004560() knlGS:
CS:  0010 DS: 0018 ES: 0018 CR0: 8005003b
CR2:  CR3: 01a85000 CR4: 06f0
DR0:  DR1:  DR2: 
DR3:  DR6: 0ff0 DR7: 0400
Process swapper (pid: 1, threadinfo 88086c42e000, task 88e7ecdc4040)
Stack:
 0046 81a83240 81a832ac 
<0> 880045603f58 810dc3ca 8100c24c 
<0> 0030  880045603f78 8100df09
Call Trace:
 
 [] handle_level_irq+0x3a/0x130
 [] ? call_softirq+0x1c/0x30
 [] handle_irq+0x49/0xa0
 [] do_IRQ+0x6c/0xf0
 [] ret_from_intr+0x0/0x11
 
 [] ? enable_IR_x2apic+0x18a/0x221
 [] native_smp_prepareus+0x143/0x389
 [] kernel_init+0x112/0x2f9
 [] child_rip+0xa/0x20
 [] ? kernel_init+0x0/0x2f9
 [] ? child_rip+0x0/0x20
Code: e8 ef f8 4d 00 49 89 c5 8b 05 16 f7 a7 00 85 c3 75 42 09 c3 89
1d 0a f7 a7 00 41 f6 c4 08 75 6d e4 21 0f b6 05 fb f6 a7 00 e6 21 <41>
8d 44 24 60 e6 20 4c 89 ee 48 c7 c7 e0 65 dd 81 e8 23 fa 4d
NMI: IOCK error (debug interrupt?)
CPU 0
Modules linked in:
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

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

[Stephen Rothwell]

Hi all,

After merging the net-next tree, today's linux-next build (x86_64
allmodconfig) failed like this:

drivers/net/usb/qmi_wwan.c:381:13: error: 'qmi_wwan_unbind_shared' undeclared 
here (not in a function)

Caused by a bad automatic merge between commit 6fecd35d4cd7 ("net:
qmi_wwan: add ZTE MF60") from the net tree and commit 230718bda1be ("net:
qmi_wwan: bind to both control and data interface") from the net-next
tree.

I added the following merge fix patch:

From: Stephen Rothwell 
Date: Tue, 10 Jul 2012 13:06:01 +1000
Subject: [PATCH] net: fix for qmi_wwan_unbind_shared changes

Signed-off-by: Stephen Rothwell 
---
 drivers/net/usb/qmi_wwan.c |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/net/usb/qmi_wwan.c b/drivers/net/usb/qmi_wwan.c
index 06cfcc7..85c983d 100644
--- a/drivers/net/usb/qmi_wwan.c
+++ b/drivers/net/usb/qmi_wwan.c
@@ -378,7 +378,7 @@ static const struct driver_info qmi_wwan_force_int2 = {
.description= "Qualcomm WWAN/QMI device",
.flags  = FLAG_WWAN,
.bind   = qmi_wwan_bind_shared,
-   .unbind = qmi_wwan_unbind_shared,
+   .unbind = qmi_wwan_unbind,
.manage_power   = qmi_wwan_manage_power,
.data   = BIT(2), /* interface whitelist bitmap */
 };
-- 
1.7.10.280.gaa39

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


pgp5qPrPhMfyH.pgp
Description: PGP signature

Re: + checkpatch-add-check-for-use-of-sizeof-without-parenthesis.patch added to -mm tree

[David Rientjes]

On Mon, 9 Jul 2012, Linus Torvalds wrote:

> sizeof without parenthesis is an abomination, and should never be used.
> 
> Sure, you don't need to have the parenthesis (except when you do - for
> actual types), but it's a parsing oddity.
> 
> The sane solution is: just add the f*cking parenthesis, and don't use
> the parsing oddity.
> 
> The parenthesis are *required* when it is a type, and they are a nice
> clarification (and makes the code easier to read) when it's an
> expression. Not having them is insane, because it just makes it clear
> how odd the parsing rules are for the two different cases.
> 

It's only strange looking because Documentation/CodingStyle doesn't use 
the gcc, glibc, C99, K, etc, style of doing "sizeof (struct foo)" and 
rather requires "sizeof(struct foo)".

> Think of it as a function, and get over your idiotic pissing match
> over how long you've both known C. That's irrelevant. It's a C builtin
> function with (unnecessarily) odd parsing rules that the kernel tries
> to standardize. The fact that it can take a type is the least odd part
> of it (there are other built-in C extensions that look like functions
> and do special things with the arguments they get -
> __builtin_constant_p(), __builtin_choose_expr() etc - they don't
> evaluate the *value* of the argument either).
> 

The only thing I've asked for is that something like this be added to 
Documentation/CodingStyle and not just in checkpatch.pl since hardly 
anybody uses that perl script.  You've chosen to mandate 
"sizeof(struct foo)" over "sizeof (struct foo)" in that document, which 
makes parenthesis for all unary expressions of the sizeof operator 
stylistically better as well, so it's only reasonable to ask that it 
mandates them for all unary expressions of sizeof.  It's your kernel.  
(That will be an exception for sizeof unary expressions, though, since we 
certainly don't want to mandate (i++).)

So, as I've been saying the whole thread, please either mandate it kernel-
wide in the CodingStyle or don't do it in checkpatch.  Checkpatch 
continually acts as a backdoor way of people enforcing their own 
preferences over others.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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 5/5] staging: csr: Remove unused macros

[Marcos Paulo de Souza]

These macros are not used, so remove it.

Signed-off-by: Marcos Paulo de Souza 
---
 drivers/staging/csr/csr_wifi_hip_card_sdio.c |3 ---
 drivers/staging/csr/drv.c|1 -
 drivers/staging/csr/firmware.c   |1 -
 drivers/staging/csr/mlme.c   |5 -
 drivers/staging/csr/monitor.c|2 --
 drivers/staging/csr/sme_sys.c|1 -
 6 files changed, 13 deletions(-)

diff --git a/drivers/staging/csr/csr_wifi_hip_card_sdio.c 
b/drivers/staging/csr/csr_wifi_hip_card_sdio.c
index 91976b8..5a86ff9 100644
--- a/drivers/staging/csr/csr_wifi_hip_card_sdio.c
+++ b/drivers/staging/csr/csr_wifi_hip_card_sdio.c
@@ -36,9 +36,6 @@
 #define MAILBOX2_TIMEOUT5   /* in millisecs */
 #define MAILBOX2_ATTEMPTS   10  /* 50ms */
 
-#define MAILBOX2_RESET_ATTEMPTS 10
-#define MAILBOX2_RESET_TIMEOUT  5   /* in millisecs */
-
 #define RESET_SETTLE_DELAY  25  /* in millisecs */
 
 static CsrResult card_init_slots(card_t *card);
diff --git a/drivers/staging/csr/drv.c b/drivers/staging/csr/drv.c
index fbe8630..4be6d95 100644
--- a/drivers/staging/csr/drv.c
+++ b/drivers/staging/csr/drv.c
@@ -63,7 +63,6 @@ int coredump_max = CSR_WIFI_HIP_NUM_COREDUMP_BUFFERS;
 int run_bh_once = -1;  /* Set for scheduled interrupt mode, -1 = 
default */
 int bh_priority = -1;
 #ifdef CSR_WIFI_HIP_DEBUG_OFFLINE
-#define UNIFI_LOG_HIP_SIGNALS_FILTER_SIGNAL (1 << 0)
 #define UNIFI_LOG_HIP_SIGNALS_FILTER_BULKDATA   (1 << 1)
 #define UNIFI_LOG_HIP_SIGNALS_FILTER_TIMESTAMP  (1 << 2)
 int log_hip_signals = 0;
diff --git a/drivers/staging/csr/firmware.c b/drivers/staging/csr/firmware.c
index 03da0d5..98e27d6 100644
--- a/drivers/staging/csr/firmware.c
+++ b/drivers/staging/csr/firmware.c
@@ -220,7 +220,6 @@ unifi_fw_read(void *ospriv, void *arg, CsrUint32 offset, 
void *buf, CsrUint32 le
 
 
 
-#define UNIFIHELPER_INIT_MODE_SMEEMB0
 #define UNIFIHELPER_INIT_MODE_SMEUSER   2
 #define UNIFIHELPER_INIT_MODE_NATIVE1
 
diff --git a/drivers/staging/csr/mlme.c b/drivers/staging/csr/mlme.c
index 790d5d7..ed767ec 100644
--- a/drivers/staging/csr/mlme.c
+++ b/drivers/staging/csr/mlme.c
@@ -15,11 +15,6 @@
 #include "csr_wifi_hip_unifi.h"
 #include "unifi_priv.h"
 
-
-/* The additional time taken by the UniFi to do a scan per channel */
-#define SCAN_STARTUP_TIME   300 /* in millisecs */
-
-
 /*
  * ---
  * unifi_mlme_wait_for_reply
diff --git a/drivers/staging/csr/monitor.c b/drivers/staging/csr/monitor.c
index 8c35b7e..628782a 100644
--- a/drivers/staging/csr/monitor.c
+++ b/drivers/staging/csr/monitor.c
@@ -242,9 +242,7 @@ netrx_prism(unifi_priv_t *priv,
 unsigned char *ptr;
 unsigned char *base;
 int ind_data_len = skb_orig->len - 2 - ETH_HLEN;
-#define WLANCAP_MAGIC_COOKIE_BASE 0x80211000
 #define WLANCAP_MAGIC_COOKIE_V1 0x80211001
-#define WLANCAP_MAGIC_COOKIE_V2 0x80211002
 struct avs_header_v1 {
 uint32  version;
 uint32  length;
diff --git a/drivers/staging/csr/sme_sys.c b/drivers/staging/csr/sme_sys.c
index 9c3aa74..5f38f9d 100644
--- a/drivers/staging/csr/sme_sys.c
+++ b/drivers/staging/csr/sme_sys.c
@@ -1572,7 +1572,6 @@ void CsrWifiRouterMaPacketReqHandler(void* drvpriv, 
CsrWifiFsmEvent* msg)
 r = _sys_packet_req(priv, , mareq->subscriptionHandle,
 mareq->frameLength, mareq->frame, snap_protocol);
 
-#define MAX_RETRY 2
 if (r && mareq->cfmRequested)
 {
 CsrWifiRouterMaPacketCfmSend(msg->source,interfaceTag,
-- 
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 4/5] staging: csr: unifi_sme.c: Remove unused macros

[Marcos Paulo de Souza]

These macros are not used, so remove it.

Signed-off-by: Marcos Paulo de Souza 
---
 drivers/staging/csr/unifi_sme.c |6 --
 1 file changed, 6 deletions(-)

diff --git a/drivers/staging/csr/unifi_sme.c b/drivers/staging/csr/unifi_sme.c
index 6e7cbbf..5ad1d5f 100644
--- a/drivers/staging/csr/unifi_sme.c
+++ b/drivers/staging/csr/unifi_sme.c
@@ -78,12 +78,6 @@ sme_log_event(ul_client_t *pcli,
 CsrResult result = CSR_RESULT_SUCCESS;
 int r;
 
-/* Following bits are encoded in hostTag These are there to ensure that 
hostTags are unique*/
-#define CSR_SME_DATA 0x  /* Frames Sent by SME */
-#define CSR_PAL_DATA 0X1000  /* Frames Sent by PAL-D*/
-#define CSR_NME_DATA 0x2000  /* Frames Sent by NME*/
-#define APPLICATION_DATA 0x3000  /* Frames Sent by Application*/
-
 func_enter();
 /* Just a sanity check */
 if ((signal == NULL) || (signal_len <= 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 2/5] staging: csr: csr_util.h: Remove commented macros

[Marcos Paulo de Souza]

All these macros are commented, so we can removed it.

Signed-off-by: Marcos Paulo de Souza 
---
 drivers/staging/csr/csr_util.h |7 ---
 1 file changed, 7 deletions(-)

diff --git a/drivers/staging/csr/csr_util.h b/drivers/staging/csr/csr_util.h
index ce39c7e..5cd6cb4 100644
--- a/drivers/staging/csr/csr_util.h
+++ b/drivers/staging/csr/csr_util.h
@@ -47,17 +47,10 @@ void CsrUInt32ToHex(CsrUint32 number, CsrCharString *str);
 #define CsrMemCmp(s1, s2, n) ((CsrInt32) memcmp((s1), (s2), (n)))
 #define CsrStrCmp(s1, s2) ((CsrInt32) strcmp((s1), (s2)))
 #define CsrStrNCmp(s1, s2, n) ((CsrInt32) strncmp((s1), (s2), (n)))
-/*#define CsrMemChr memchr*/
 #define CsrStrChr strchr
-/*#define CsrStrCSpn strcspn*/
-/*#define CsrStrPBrk strpbrk*/
-/*#define CsrStrRChr strrchr*/
-/*#define CsrStrSpn strspn*/
 #define CsrStrStr strstr
-/*#define CsrStrTok strtok*/
 #define CsrMemSet memset
 #define CsrStrLen strlen
-/*#define CsrVsnprintf(s, n, format, arg) ((CsrInt32) vsnprintf((s), (n), 
(format), (arg)))*/
 #else /* !CSR_USE_STDC_LIB */
 void *CsrMemCpy(void *dest, const void *src, CsrSize count);
 void *CsrMemMove(void *dest, const void *src, CsrSize count);
-- 
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/

Re: [PATCH 0/3] staging: bcm: Cleanup bcm driver

[Marcos Souza]

2012/7/9 Kevin McKinney :
> On Mon, Jul 09, 2012 at 10:32:37PM -0300, Marcos Paulo de Souza wrote:
>> Hi Kernel guys!
>>
>> This new patchset tries to clean a little the bcm driver, removing
>> some unused macros and some dead code.
>>
>> These macros and dead code were reported by the forgotten-macros tool
>> (https://github.com/marcosps/forgotten_macros).
>>
>> The tool is under development, but all the patches looks like OK.
>>
>> This patchset is based in staging-next.
>>
>> Thanks guys!
>
> The patchset looks good!

Thanks for the answer Kevin!!

So, do I have your ack?

> Thanks,
> Kevin



-- 
Att,

Marcos Paulo de Souza
Acadêmico de Ciencia da Computação - FURB - SC
"Uma vida sem desafios é uma vida sem razão"
"A life without challenges, is a non reason life"
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH 3/5] staging: csr: netdev.c: Remove unused macros

[Marcos Paulo de Souza]

These macros are not used, so we can remove it.

Signed-off-by: Marcos Paulo de Souza 
---
 drivers/staging/csr/netdev.c |5 -
 1 file changed, 5 deletions(-)

diff --git a/drivers/staging/csr/netdev.c b/drivers/staging/csr/netdev.c
index cf19f11..55149df 100644
--- a/drivers/staging/csr/netdev.c
+++ b/drivers/staging/csr/netdev.c
@@ -70,11 +70,6 @@
  */
 #define ALLOW_Q_PAUSE
 
-#define ieee2host16(n)  __le16_to_cpu(n)
-#define ieee2host32(n)  __le32_to_cpu(n)
-#define host2ieee16(n)  __cpu_to_le16(n)
-#define host2ieee32(n)  __cpu_to_le32(n)
-
 #if LINUX_VERSION_CODE >= KERNEL_VERSION(2,6,28)
 #ifdef UNIFI_NET_NAME
 #define UF_ALLOC_NETDEV(_dev, _size, _name, _setup, _num_of_queues) \
-- 
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 1/5] staging: csr: Remove dead code

[Marcos Paulo de Souza]

All this code is dead, so remove it.

Signed-off-by: Marcos Paulo de Souza 
---
 drivers/staging/csr/monitor.c  |   57 
 drivers/staging/csr/unifi_native.h |   19 
 2 files changed, 76 deletions(-)

diff --git a/drivers/staging/csr/monitor.c b/drivers/staging/csr/monitor.c
index 7648d2b..8c35b7e 100644
--- a/drivers/staging/csr/monitor.c
+++ b/drivers/staging/csr/monitor.c
@@ -51,13 +51,6 @@ uf_start_sniff(unifi_priv_t *priv)
 req->Channel = priv->wext_conf.channel;
 req->ChannelStartingFactor = 0;
 
-#if 0
-printk("SniffJoin: Ifindex=%d, Channel=%d, ChannelStartingFactor=%d\n",
-   req->Ifindex,
-   req->Channel,
-   req->ChannelStartingFactor);
-#endif
-
 signal.SignalPrimitiveHeader.SignalId = CSR_MLME_SNIFFJOIN_REQUEST_ID;
 
 r = unifi_mlme_blocking_request(priv, pcli, , NULL, timeout);
@@ -198,11 +191,6 @@ netrx_radiotap(unifi_priv_t *priv,
 unifi_rt->rt_antenna = ind->AntennaId;
 
 
-#if 0
-printk("skb datalen=%d\n", skb->len);
-dump(skb->data, 48);
-#endif
-
 skb->dev = dev;
 #if LINUX_VERSION_CODE >= KERNEL_VERSION(2,6,22)
 skb->mac_header = skb->data;
@@ -282,24 +270,6 @@ netrx_prism(unifi_priv_t *priv,
 return;
 }
 
-#if 0
-printk("MA-SINFFDATA.ind: DataLen=%d bytes, TSF %02X %02X %02X %02X %02X 
%02X %02X %02X, Rate=%d, Antenna=%d\n",
-   ind->Data.DataLength,
-   ind->Timestamp.x[0],
-   ind->Timestamp.x[1],
-   ind->Timestamp.x[2],
-   ind->Timestamp.x[3],
-   ind->Timestamp.x[4],
-   ind->Timestamp.x[5],
-   ind->Timestamp.x[6],
-   ind->Timestamp.x[7],
-   ind->Rate,
-   ind->Antenna);
-
-printk("payload, len %d\n", length);
-dump((unsigned char *)payload, 32);
-#endif
-
 /*
  * Allocate a SKB for the received data packet, including radiotap
  * header.
@@ -341,11 +311,6 @@ netrx_prism(unifi_priv_t *priv,
 avs->encoding   = htonl(0); /* unknown */
 
 
-#if 0
-printk("skb datalen=%d\n", skb->len);
-dump(skb->data, 48);
-#endif
-
 skb->dev = dev;
 skb->mac.raw = skb->data;
 skb->pkt_type = PACKET_OTHERHOST;
@@ -402,33 +367,11 @@ ma_sniffdata_ind(void *ospriv,
 }
 
 skb->len = bulkdata->d[0].data_length;
-#if 0
-printk("MA-SNIFFDATA.ind: DataLen=%d bytes, TSF %02X %02X %02X %02X %02X 
%02X %02X %02X, Rate=%d, Antenna=%d\n",
-   ind->Data.DataLength,
-   ind->Timestamp.x[0],
-   ind->Timestamp.x[1],
-   ind->Timestamp.x[2],
-   ind->Timestamp.x[3],
-   ind->Timestamp.x[4],
-   ind->Timestamp.x[5],
-   ind->Timestamp.x[6],
-   ind->Timestamp.x[7],
-   ind->Rate,
-   ind->AntennaId);
-
-printk("payload, len %lu\n", bulkdata->d[0].data_length);
-if (bulkdata->d[0].os_data_ptr && (bulkdata->d[0].data_length >= 32)) {
-dump((unsigned char *)bulkdata->d[0].os_data_ptr, 32);
-}
-#endif
 
 /* We only process data packets if the interface is open */
 if (unlikely(!netif_running(dev))) {
 priv->stats.rx_dropped++;
 priv->wext_conf.wireless_stats.discard.misc++;
-#if 0
-printk("Dropping packet while interface is not up.\n");
-#endif
 dev_kfree_skb(skb);
 return;
 }
diff --git a/drivers/staging/csr/unifi_native.h 
b/drivers/staging/csr/unifi_native.h
index a480c9e..a73b38e 100644
--- a/drivers/staging/csr/unifi_native.h
+++ b/drivers/staging/csr/unifi_native.h
@@ -242,25 +242,6 @@ void uf_native_process_udi_signal(ul_client_t *pcli,
   const u8 *packed_signal,
   int packed_signal_len,
   const bulk_data_param_t *bulkdata, int dir);
-#if 0
-/*
- * Choose one of these if available in linux/if_arp.h:
- *  #define UNIFI_SNIFF_ARPHRD ARPHRD_IEEE80211_RADIOTAP
- *  #define UNIFI_SNIFF_ARPHRD ARPHRD_IEEE80211_PRISM
- *
- * Radiotap is the newer standard for softmac WLAN devices, it works with
- * Wireshark but not Ethereal (due to a bug in the Ethereal dissector).
- * Prism is an older (less desirable) format but it does work with Ethereal.
- */
-#ifdef ARPHRD_IEEE80211_RADIOTAP
-#define UNIFI_SNIFF_ARPHRD ARPHRD_IEEE80211_RADIOTAP
-#else
-#ifdef ARPHRD_IEEE80211_PRISM
-#define UNIFI_SNIFF_ARPHRD ARPHRD_IEEE80211_PRISM
-#endif
-#endif
-#endif
-
 #ifdef UNIFI_SNIFF_ARPHRD
 /*
  * monitor.c
-- 
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 0/5] staging: csr: Cleanup driver

[Marcos Paulo de Souza]

Hi kernel guys!

This patchset aims to clean a little the csr driver by removing dead code and
unused/commented macros.

All the macros and dead code was reported by the forgotten-macros tool
(https://github.com/marcosps/forgotten_macros).

This patchset is against staging-next.

I hope you like it :)

Marcos Paulo de Souza (5):
  staging: csr: Remove dead code
  staging: csr: csr_util.h: Remove commented macros
  staging: csr: netdev.c: Remove unused macros
  staging: csr: unifi_sme.c: Remove unused macros
  staging: csr: Remove unused macros

 drivers/staging/csr/csr_util.h   |7 ---
 drivers/staging/csr/csr_wifi_hip_card_sdio.c |3 --
 drivers/staging/csr/drv.c|1 -
 drivers/staging/csr/firmware.c   |1 -
 drivers/staging/csr/mlme.c   |5 ---
 drivers/staging/csr/monitor.c|   59 --
 drivers/staging/csr/netdev.c |5 ---
 drivers/staging/csr/sme_sys.c|1 -
 drivers/staging/csr/unifi_native.h   |   19 -
 drivers/staging/csr/unifi_sme.c  |6 ---
 10 files changed, 107 deletions(-)

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

Re: [PATCH 0/3] staging: bcm: Cleanup bcm driver

[Kevin McKinney]

On Mon, Jul 09, 2012 at 10:32:37PM -0300, Marcos Paulo de Souza wrote:
> Hi Kernel guys!
>
> This new patchset tries to clean a little the bcm driver, removing
> some unused macros and some dead code.
>   
> These macros and dead code were reported by the forgotten-macros tool
> (https://github.com/marcosps/forgotten_macros).
>   
> The tool is under development, but all the patches looks like OK.   
>
> This patchset is based in staging-next.
>   
> Thanks guys!

The patchset looks good!

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

Re: [PATCH] net: cgroup: fix out of bounds accesses

[David Miller]

From: Gao feng 
Date: Tue, 10 Jul 2012 10:33:23 +0800

> Please see my patch in this thread, I think it's a better way to fix this bug.

You'll need to work that out with Eric, fwiw I think his patch was
clean and just fine and it's staying in my tree.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 3/4] zsmalloc: add details to zs_map_object boiler plate

[Minchan Kim]

On 07/03/2012 06:15 AM, Seth Jennings wrote:
> Add information on the usage limits of zs_map_object()
> 
> Signed-off-by: Seth Jennings 
> ---
>  drivers/staging/zsmalloc/zsmalloc-main.c |7 ++-
>  1 file changed, 6 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/staging/zsmalloc/zsmalloc-main.c 
> b/drivers/staging/zsmalloc/zsmalloc-main.c
> index 4942d41..abf7c13 100644
> --- a/drivers/staging/zsmalloc/zsmalloc-main.c
> +++ b/drivers/staging/zsmalloc/zsmalloc-main.c
> @@ -747,7 +747,12 @@ EXPORT_SYMBOL_GPL(zs_free);
>   *
>   * Before using an object allocated from zs_malloc, it must be mapped using
>   * this function. When done with the object, it must be unmapped using
> - * zs_unmap_object
> + * zs_unmap_object.
> + *
> + * Only one object can be mapped per cpu at a time. There is no protection
> + * against nested mappings.
> + *
> + * This function returns with preemption and page faults disabled.
>  */
>  void *zs_map_object(struct zs_pool *pool, unsigned long handle)
>  {
> 

The comment is good but I hope we can detect it automatically with DEBUG
option. It wouldn't be hard but it's a debug patch so not critical
until we receive some report about the bug.

The possibility for nesting is that it is used by irq context.

A uses the mapping
.
.
.
IRQ happen
B uses the mapping in IRQ context
.
.
.

Maybe we need local_irq_save/restore in zs_[un]map_object path.

-- 
Kind regards,
Minchan Kim


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

Re: [PATCH] net: cgroup: fix out of bounds accesses

[Gao feng]

于 2012年07月10日 05:51, David Miller 写道:
> From: Gao feng 
> Date: Mon, 09 Jul 2012 16:15:29 +0800
> 
>> 于 2012年07月09日 15:45, Eric Dumazet 写道:
>>> From: Eric Dumazet 
>>>
>>> dev->priomap is allocated by extend_netdev_table() called from
>>> update_netdev_tables().
>>> And this is only called if write_priomap() is called.
>>>
>>> But if write_priomap() is not called, it seems we can have out of bounds
>>> accesses in cgrp_destroy(), read_priomap() & skb_update_prio()
>>>
>>> With help from Gao Feng
>>>
>>> Signed-off-by: Eric Dumazet 
>>> Cc: Neil Horman 
>>> Cc: Gao feng 
>>> ---
>>> net/core/dev.c|8 ++--
>>> net/core/netprio_cgroup.c |4 ++--
>>> 2 files changed, 8 insertions(+), 4 deletions(-)
>>
>> Acked-by: Gao feng 
> 
> Applied.
> 

Hi David

Please see my patch in this thread, I think it's a better way to fix this bug.

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

[PATCH] net: cgroup: fix access the unallocated memory in netprio cgroup

[Gao feng]

there are some out of bound accesses in netprio cgroup.
when creating a new netprio cgroup,we only set a prioidx for
the new cgroup,without allocate memory for dev->priomap.

because we don't want to see additional bound checkings in
fast path, so I think the best way is to allocate memory when we
creating a new netprio cgroup.

and because netdev can be created or registered after cgroup being
created, so extend_netdev_table is also needed in write_priomap.

this patch add a return value for update_netdev_tables & extend_netdev_table,
so when new_priomap is allocated failed,write_priomap will stop to access
the priomap,and return -ENOMEM back to the userspace to tell the user
what happend.

Signed-off-by: Gao feng 
Cc: Neil Horman 
Cc: Eric Dumazet 
---
 net/core/netprio_cgroup.c |   43 +--
 1 files changed, 29 insertions(+), 14 deletions(-)

diff --git a/net/core/netprio_cgroup.c b/net/core/netprio_cgroup.c
index aa907ed..3554f28 100644
--- a/net/core/netprio_cgroup.c
+++ b/net/core/netprio_cgroup.c
@@ -65,7 +65,7 @@ static void put_prioidx(u32 idx)
spin_unlock_irqrestore(_map_lock, flags);
 }
 
-static void extend_netdev_table(struct net_device *dev, u32 new_len)
+static int extend_netdev_table(struct net_device *dev, u32 new_len)
 {
size_t new_size = sizeof(struct netprio_map) +
   ((sizeof(u32) * new_len));
@@ -77,7 +77,7 @@ static void extend_netdev_table(struct net_device *dev, u32 
new_len)
 
if (!new_priomap) {
pr_warn("Unable to alloc new priomap!\n");
-   return;
+   return -ENOMEM;
}
 
for (i = 0;
@@ -90,10 +90,12 @@ static void extend_netdev_table(struct net_device *dev, u32 
new_len)
rcu_assign_pointer(dev->priomap, new_priomap);
if (old_priomap)
kfree_rcu(old_priomap, rcu);
+   return 0;
 }
 
-static void update_netdev_tables(void)
+static int update_netdev_tables(void)
 {
+   int ret = 0;
struct net_device *dev;
u32 max_len = atomic_read(_prioidx) + 1;
struct netprio_map *map;
@@ -102,34 +104,44 @@ static void update_netdev_tables(void)
for_each_netdev(_net, dev) {
map = rtnl_dereference(dev->priomap);
if ((!map) ||
-   (map->priomap_len < max_len))
-   extend_netdev_table(dev, max_len);
+   (map->priomap_len < max_len)) {
+   ret = extend_netdev_table(dev, max_len);
+   if (ret < 0)
+   break;
+   }
}
rtnl_unlock();
+   return ret;
 }
 
 static struct cgroup_subsys_state *cgrp_create(struct cgroup *cgrp)
 {
struct cgroup_netprio_state *cs;
-   int ret;
+   int ret = -EINVAL;
 
cs = kzalloc(sizeof(*cs), GFP_KERNEL);
if (!cs)
return ERR_PTR(-ENOMEM);
 
-   if (cgrp->parent && cgrp_netprio_state(cgrp->parent)->prioidx) {
-   kfree(cs);
-   return ERR_PTR(-EINVAL);
-   }
+   if (cgrp->parent && cgrp_netprio_state(cgrp->parent)->prioidx)
+   goto out;
 
ret = get_prioidx(>prioidx);
-   if (ret != 0) {
+   if (ret < 0) {
pr_warn("No space in priority index array\n");
-   kfree(cs);
-   return ERR_PTR(ret);
+   goto out;
+   }
+
+   ret = update_netdev_tables();
+   if (ret < 0) {
+   put_prioidx(cs->prioidx);
+   goto out;
}
 
return >css;
+out:
+   kfree(cs);
+   return ERR_PTR(ret);
 }
 
 static void cgrp_destroy(struct cgroup *cgrp)
@@ -221,7 +233,10 @@ static int write_priomap(struct cgroup *cgrp, struct 
cftype *cft,
if (!dev)
goto out_free_devname;
 
-   update_netdev_tables();
+   ret = update_netdev_tables();
+   if (ret < 0)
+   goto out_free_devname;
+
ret = 0;
rcu_read_lock();
map = rcu_dereference(dev->priomap);
-- 
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 V3 5/6] Avoid duplicate probe for of platform devices

[Jia Hongtao-B38951]

> -Original Message-
> From: Rob Herring [mailto:robherri...@gmail.com]
> Sent: Monday, July 09, 2012 9:58 PM
> To: Li Yang-R58472
> Cc: Jia Hongtao-B38951; Greg KH; devicetree-disc...@lists.ozlabs.org;
> linux-kernel@vger.kernel.org
> Subject: Re: [PATCH V3 5/6] Avoid duplicate probe for of platform devices
> 
> On 07/08/2012 10:46 PM, Li Yang-R58472 wrote:
> >>> I don't understand, why is this just showing up now?  What
> >>> changed to cause this?  Couldn't that be the real problem here?
> >>>
> >>
> >> The issue is showing up because we now probe devices twice.
> >> Previously, we just probe devices once. But now we changed the way
> >> of pci init which makes pci controllers should be probed earlier
> >> than other devices. So we have to probe pci nodes separately. Probe
> >> more than once is the root cause of this issue.
> >>
> >> The pci patchset I mentioned please refer to:
> >> http://patchwork.ozlabs.org/patch/163742/
> >
> > Let me try to clarify a little bit.  The of platform bus normally
> > traverse the device tree to add all the devices.  The change which
> > caused problem is that we need to probe PCIe RC devices at a earlier
> > stage of initialization.  So we added these PCIe RC devices earlier
> > than the normal device tree traversal process.  These PCIe RC devices
> > will be scanned again during the normal traversal and cause
> > duplicated devices being added.  Our proposal is to deal with
> > duplicated devices automatically and make it possible to scan the
> > device tree multiple times for devices to be added.
> 
> What is making PCI need to be probed earlier? Perhaps deferred probe
> would work?

Pci initialization fsl_add_bridge() should be called earlier as they used
to be called in board specific code xx_setup_arch(). Now we put this init
part in the probe function of pci controller to make the code infrastructure
better. That make pci bus should be probed earlier.


> 
> Perhaps giving of_platform_populate an exclude list of compatible
> strings to skip would work.
> 
> Rob

Yes, this would work and we actually already implemented this solution.
But I think it looks hackish and will influence the other API users.

Thanks.
-Jia Hongtao.

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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: + checkpatch-add-check-for-use-of-sizeof-without-parenthesis.patch added to -mm tree

[Linus Torvalds]

On Mon, Jul 9, 2012 at 6:50 PM, David Rientjes  wrote:
>
> This doesn't suggest parenthesis for sizeof at all times

sizeof without parenthesis is an abomination, and should never be used.

Sure, you don't need to have the parenthesis (except when you do - for
actual types), but it's a parsing oddity.

The sane solution is: just add the f*cking parenthesis, and don't use
the parsing oddity.

The parenthesis are *required* when it is a type, and they are a nice
clarification (and makes the code easier to read) when it's an
expression. Not having them is insane, because it just makes it clear
how odd the parsing rules are for the two different cases.

And talking about "prefix operators" is a moronic thing to do. It does
*not* look like a prefix operator, and it does not even *act* like a
prefix operator (look at types, where it really does require the
parenthesis). But most importantly, it's not how sane people think
about it.

Think of it as a function, and get over your idiotic pissing match
over how long you've both known C. That's irrelevant. It's a C builtin
function with (unnecessarily) odd parsing rules that the kernel tries
to standardize. The fact that it can take a type is the least odd part
of it (there are other built-in C extensions that look like functions
and do special things with the arguments they get -
__builtin_constant_p(), __builtin_choose_expr() etc - they don't
evaluate the *value* of the argument either).

Btw, the spacing rule is separate, and the "3.1 Spaces" thing was
added later and is in fact somewhat misleading. The spacing rules have
nothing to do with "function-vs-keyword", and everything to do with
"function-vs-control-flow". So "sizeof()" is not actually an exception
at all, like the docs state: it's perfectly regular. It looks and acts
as a function, not as a control flow operation.

What makes if/while/else/do/for stand out is that they are the native
C control flow operators, and they have spaces around them. They fact
that they are keywords is irrelevant. OF COURSE they are keywords,
since they are the native control flow ops, but that is not why they
have special spacing rules. The reason they have special spacing rules
is that

for (x; y; z) {

is a control flow construct, while

function(x, y, z);

is just a normal function expression. And in *no* case do we put
spaces after the parenthesis, we do it after the comma (or semicolon
for "for (a; b; c)").

We do have some control flow macros ("list_for_each()" etc), and they
could logically have the space, but hey, they are also normal macros,
so whatever. The kernel special-cases the native control-flow stuff,
not the random control flow macro oddities we've created for special
occasions.

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

Re: [PATCH 2/4] zsmalloc: add single-page object fastpath in unmap

[Minchan Kim]

On 07/03/2012 06:15 AM, Seth Jennings wrote:
> Improve zs_unmap_object() performance by adding a fast path for
> objects that don't span pages.
> 
> Signed-off-by: Seth Jennings 
> ---
>  drivers/staging/zsmalloc/zsmalloc-main.c |   15 ++-
>  1 file changed, 10 insertions(+), 5 deletions(-)
> 
> diff --git a/drivers/staging/zsmalloc/zsmalloc-main.c 
> b/drivers/staging/zsmalloc/zsmalloc-main.c
> index a7a6f22..4942d41 100644
> --- a/drivers/staging/zsmalloc/zsmalloc-main.c
> +++ b/drivers/staging/zsmalloc/zsmalloc-main.c
> @@ -774,6 +774,7 @@ void *zs_map_object(struct zs_pool *pool, unsigned long 
> handle)
>   }
>  
>   zs_copy_map_object(area->vm_buf, page, off, class->size);
> + area->vm_addr = NULL;
>   return area->vm_buf;
>  }
>  EXPORT_SYMBOL_GPL(zs_map_object);
> @@ -788,6 +789,14 @@ void zs_unmap_object(struct zs_pool *pool, unsigned long 
> handle)
>   struct size_class *class;
>   struct mapping_area *area;
>  
> + area = &__get_cpu_var(zs_map_area);
> + if (area->vm_addr) {
> + /* single-page object fastpath */
> + kunmap_atomic(area->vm_addr);
> + put_cpu_var(zs_map_area);
> + return;
> + }
> +

Please locate this after below BUG_ON.
The BUG check is still effective regardless of your fast path patch.

>   BUG_ON(!handle);
>  
>   obj_handle_to_location(handle, , _idx);
> @@ -795,11 +804,7 @@ void zs_unmap_object(struct zs_pool *pool, unsigned long 
> handle)
>   class = >size_class[class_idx];
>   off = obj_idx_to_offset(page, obj_idx, class->size);
>  
> - area = &__get_cpu_var(zs_map_area);
> - if (off + class->size <= PAGE_SIZE)
> - kunmap_atomic(area->vm_addr);
> - else
> - zs_copy_unmap_object(area->vm_buf, page, off, class->size);
> + zs_copy_unmap_object(area->vm_buf, page, off, class->size);
>   put_cpu_var(zs_map_area);
>  }
>  EXPORT_SYMBOL_GPL(zs_unmap_object);
> 


-- 
Kind regards,
Minchan Kim


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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: + checkpatch-add-check-for-use-of-sizeof-without-parenthesis.patch added to -mm tree

[David Rientjes]

On Mon, 9 Jul 2012, Joe Perches wrote:

> I don't really care what style a large block of code
> uses.  I care that it mostly has the same form.
> 

Same form??  The sizeof operator has two forms depending on whether it's a 
unary expression or a type as specified by the standard.

The issue here is that you're mandating they all use the same form because 
you're quoting an email from Linus four years ago that you dug up but 
isn't required in the coding style and is already used in over 1000 places 
in the kernel.

If you want the output of checkpatch.pl to be useful, I would think you 
would want to eliminate this kind of garbage.

> > I guarantee you that those who learned from K don't 
> > think sizeof(unsigned long) "looks like a function".
> 
> Tell that to Linus. He wrote the email I referenced
> which you so apparently blithely elided.
> 
> Repeating it:
> 
> "Another example of this is "sizeof". The kernel universally (I hope) has 
> parenthesis around the sizeof argument, even though it's clearly not 
> required by the C language."
> 

He's obviously addressing a single form of the sizeof operator, i.e. those 
on unary expressions; sizeof used on a type CLEARLY DOES require the 
parenthesis.

Anyway, since this is my last email on the matter since I've already 
showed how your patch is completely busted, you're talking purely about 
style preferences here.  Don't convolute that by talking about the C 
standard or Linus' email where he says "it's a coding standard."  It's 
not.  I've layed out the two forms of the sizeof operator in every email 
I've written in this thread.  If you want to enforce a _style_ preference 
because you saw an email four years ago that Linus wrote, then add it to 
CodingStyle first and get him to mandate it.  That's how you effect a 
kernel-wide change; the _only_ person I know that uses checkpatch is 
Andrew and you'll notice the mm directory is the one where "sizeof ..." 
isn't used so just changing checkpatch here won't do much good.

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

Re: [PATCH 1/4] zsmalloc: remove x86 dependency

[Minchan Kim]

On 07/03/2012 06:15 AM, Seth Jennings wrote:
> This patch replaces the page table assisted object mapping
> method, which has x86 dependencies, with a arch-independent
> method that does a simple copy into a temporary per-cpu
> buffer.
> 
> While a copy seems like it would be worse than mapping the pages,
> tests demonstrate the copying is always faster and, in the case of
> running inside a KVM guest, roughly 4x faster.
> 
> Signed-off-by: Seth Jennings 
> ---
>  drivers/staging/zsmalloc/Kconfig |4 --
>  drivers/staging/zsmalloc/zsmalloc-main.c |   99 
> +-
>  drivers/staging/zsmalloc/zsmalloc_int.h  |5 +-
>  3 files changed, 72 insertions(+), 36 deletions(-)
> 
> diff --git a/drivers/staging/zsmalloc/Kconfig 
> b/drivers/staging/zsmalloc/Kconfig
> index a5ab720..9084565 100644
> --- a/drivers/staging/zsmalloc/Kconfig
> +++ b/drivers/staging/zsmalloc/Kconfig
> @@ -1,9 +1,5 @@
>  config ZSMALLOC
>   tristate "Memory allocator for compressed pages"
> - # X86 dependency is because of the use of __flush_tlb_one and set_pte
> - # in zsmalloc-main.c.
> - # TODO: convert these to portable functions
> - depends on X86
>   default n
>   help
> zsmalloc is a slab-based memory allocator designed to store
> diff --git a/drivers/staging/zsmalloc/zsmalloc-main.c 
> b/drivers/staging/zsmalloc/zsmalloc-main.c
> index 10b0d60..a7a6f22 100644
> --- a/drivers/staging/zsmalloc/zsmalloc-main.c
> +++ b/drivers/staging/zsmalloc/zsmalloc-main.c
> @@ -470,6 +470,57 @@ static struct page *find_get_zspage(struct size_class 
> *class)
>   return page;
>  }
>  
> +static void zs_copy_map_object(char *buf, struct page *firstpage,
> + int off, int size)

firstpage is rather misleading.
As you know, we use firstpage term for real firstpage of zspage but
in case of zs_copy_map_object, it could be a middle page of zspage.
So I would like to use "page" instead of firstpage.

> +{
> + struct page *pages[2];
> + int sizes[2];
> + void *addr;
> +
> + pages[0] = firstpage;
> + pages[1] = get_next_page(firstpage);
> + BUG_ON(!pages[1]);
> +
> + sizes[0] = PAGE_SIZE - off;
> + sizes[1] = size - sizes[0];
> +
> + /* disable page faults to match kmap_atomic() return conditions */
> + pagefault_disable();

If I understand your intention correctly, you want to prevent calling
this function on non-atomic context. Right?
Please write down description more clearly as point of view what's happen
if we didn't.

> +
> + /* copy object to per-cpu buffer */
> + addr = kmap_atomic(pages[0]);
> + memcpy(buf, addr + off, sizes[0]);
> + kunmap_atomic(addr);
> + addr = kmap_atomic(pages[1]);
> + memcpy(buf + sizes[0], addr, sizes[1]);
> + kunmap_atomic(addr);
> +}
> +
> +static void zs_copy_unmap_object(char *buf, struct page *firstpage,
> + int off, int size)

Ditto firstpage.

Otherwise, Looks good to me.

-- 
Kind regards,
Minchan Kim


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] fail dentry revalidation after namespace change

[Andrew Morton]

On Mon, 09 Jul 2012 18:51:37 -0700 ebied...@xmission.com (Eric W. Biederman) 
wrote:

> Andrew Morton  writes:
> 
> > On Mon, 09 Jul 2012 17:30:48 -0700 ebied...@xmission.com (Eric W. 
> > Biederman) wrote:
> >
> >> Andrew Morton  writes:
> >> 
> >> >>  {
> >> >> struct sysfs_dirent *sd;
> >> >> int is_dir;
> >> >> +   int type;
> >> >>  
> >> >> if (nd->flags & LOOKUP_RCU)
> >> >> return -ECHILD;
> >> >> @@ -326,6 +327,13 @@ static int sysfs_dentry_revalidate(struct dentry 
> >> >> *dentry, struct nameidata *nd)
> >> >> if (strcmp(dentry->d_name.name, sd->s_name) != 0)
> >> >> goto out_bad;
> >> >>  
> >> >> +   /* The sysfs dirent has been moved to a different namespace */
> >> >> +   type = KOBJ_NS_TYPE_NONE;
> >> >> +   if (sd->s_parent)
> >> >> +   type = sysfs_ns_type(sd->s_parent);
> >> >> +   if (type && (sysfs_info(dentry->d_sb)->ns[type] != sd->s_ns))
> >> >
> >> > eww, the code is assuming that KOBJ_NS_TYPE_NONE has a value of zero. 
> >> > Don't do that; it smells bad.
> >> 
> >> Gag.  An incomplete change in idiom.
> >> 
> >> KOBJ_NS_TYPE_NONE is explicitly defined as 0 so that it can be used
> >> this way, and every where else in fs/sysfs/dir.c uses this idiom.
> >
> > One man's idiom is another man's idiocy.
> 
> And code that uses inconsistent idioms is even harder to read.

Not true.  That patch is more readable when it is changed to use
correct types.  If only because readers don't need to go in and check
that KOBJ_NS_TYPE_NONE has value zero.

> > Seriously.  What sort of idea is that?  Create an enumerated type and
> > then just ignore it?
> 
> It isn't ignored.  It just has a well defined NULL value. That is hardly
> controversial.

If it's uncontroversial, why are we talking about it?  Why did I, an
experienced C and kernel developer, think that it looked stupid and
possibly buggy?

I'm uncomfortable with propagating this idiotic and unnecessary trick
any further.  It's better to fix it.

> >> Pray tell in what parallel universe is that monstrosity above more
> >> readable than the line it replaces?
> >
> > Don't be silly, it is not a "monstrosity".  The code it is modifying
> > contains an unneeded test-and-branch.  It's a test and branch which the
> > compiler might be able to avoid.  If we can demonstrate that the
> > compiler does indeed optimise it, or if we can find a less monstrous
> > way of implementing it then fine.  Otherwise, efficiency wins.
> 
> Efficiency wins?  In a rarely used function?  Which kernel are you
> working on?

One in which we frequently optimise uncommon code paths.

> Readable maintainable code wins.  Unreadable code causes regressions.

Dude, the whole reason for having enums and enumerated types is for
readability and maintainability.  If we didn't care about that, we'd
use literal constants everywhere.  And here you are arguing against
that readability and maintainability.

If you want to say "yes, the sysfs code is bad but I can't be bothered
fixing it all" then grumble, but OK.  But for heavens sake, don't go
and *defend* what that code is doing.

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

RE: [PATCH V2 3/7] regulator: s5m8767: Modify function and variable name

[Sangbeom Kim]

Hi
Monday, July 09, 2012 10:03 PM +0900, Mark Brown wrote:

> This needs to be squashed down into the patch doing the rename in the
> core to avoid build breakage.  Otherwise looks good.
Ok, I will squash and resend it.

Thanks,
Sangbeom.


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] cgroup: fix dentry still in use bug when dropping css refs after umount

[Li Zefan]

On 2012/7/8 14:35, Tejun Heo wrote:

> Hello, Li.
> 
> On Wed, Jul 04, 2012 at 02:19:15PM +0800, Li Zefan wrote:
>>> I think we're horridly broken for
>>> root cgroup tho - and it has been broken for very long time.  I think
>>> it's mostly hidden because most (all?) controllers short-circuit root
>>> cgroup.  Eh, well
>>>
>>
>> Could you elaborate a bit on what's broken for root cgroup?
> 
> If someone holds css ref of a root cgroup, AFAICS nothing is
> preventing the cgroup hierarchy from being unmounted and root cgroup
> destroyed.
> 


Right, but that should be safe. The css objects of the root cgroup are
allocated at boot, and won't be destroyed at umount.

Furthermore when a cgroup hierarchy is going to be unmounted, those css's
will be made to point to a cgroup named dummytop in rebind_subsystems(),
and there's a syncronize_rcu() in the end of the function, so accessing
css->cgroup is always safe.

In this case, dummytop->dentry is NULL, and that's safe too, because
cgroup_path() is aware of this case.

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

Re: [PATCH v2] mm/hugetlb: fix error code in hugetlbfs_alloc_inode

[Wanpeng Li]

On Mon, Jul 09, 2012 at 07:02:39PM -0700, David Rientjes wrote:
>On Tue, 10 Jul 2012, Wanpeng Li wrote:
>
>> diff --git a/fs/hugetlbfs/inode.c b/fs/hugetlbfs/inode.c
>> index c4b85d0..79a0f33 100644
>> --- a/fs/hugetlbfs/inode.c
>> +++ b/fs/hugetlbfs/inode.c
>> @@ -696,7 +696,7 @@ static struct inode *hugetlbfs_alloc_inode(struct 
>> super_block *sb)
>>  p = kmem_cache_alloc(hugetlbfs_inode_cachep, GFP_KERNEL);
>>  if (unlikely(!p)) {
>>  hugetlbfs_inc_free_inodes(sbinfo);
>> -return NULL;
>> +return ERR_PTR(-ENOMEM);
>>  }
>>  return >vfs_inode;
>>  }
>
>So now you've removed Gavin Shan who already told you that it was correct 
>as written and propose yet another bogus patch which will break.  This 
>isn't professional.
>
>alloc_inode() tests for a NULL return value, not for PTR_ERR(), so you 
>would be introducing a bug if this patch were merged.  It's completely 
>correct the way it's written.

Thank you for your comments David, please ignore the patch.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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: + checkpatch-add-check-for-use-of-sizeof-without-parenthesis.patch added to -mm tree

[Joe Perches]

On Mon, 2012-07-09 at 18:50 -0700, David Rientjes wrote:
> On Mon, 9 Jul 2012, Joe Perches wrote:
> 
> > CodingStyle already does suggest parenthesis around sizeof
> > 
> > 3.1:  Spaces
> > 
> > Linux kernel style for use of spaces depends (mostly) on
> > function-versus-keyword usage.  Use a space after (most) keywords.  The
> > notable exceptions are sizeof, typeof, alignof, and __attribute__, which 
> > look
> > somewhat like functions (and are usually used with parentheses in Linux,
> > although they are not required in the language, as in: "sizeof info" after
> > "struct fileinfo info;" is declared).
> > 
> > So use a space after these keywords:
> > if, switch, case, for, do, while
> > but not with sizeof, typeof, alignof, or __attribute__.  E.g.,
> > s = sizeof(struct file);
> > 
> 
> This doesn't suggest parenthesis for sizeof at all times,

Depends on interpretation.  Linus' email from 2008 is pretty clear.

> it's saying that 
> Linux doesn't use the gcc, glibc, C99 way of doing "sizeof (struct file)" 
> for type names as I've already said three times and rather prefers 
> "sizeof(struct file)".  That's fine.
> 
> I'm talking about the C99 specification that says the sizeof operator act 
> on unary expressions, i.e. not type names that you keep talking about and 
> apparently don't understand the difference between.  Casts are done with 
> type names, you can't do "unsigned long ptr", you do "(unsigned long)ptr".  
> Sizeof operators using type names do the same thing: 
> "sizeof (unsigned long)".  The space is just a stylistic difference.
> 
> You may not understand the difference between a type and a unary 
> expression, but other C programmers do, i.e. those who have implemented 
> the over 1000 places in the kernel that already do this because they 
> learned from K

I don't really care what style a large block of code
uses.  I care that it mostly has the same form.

fyi:  I learned C from K and Bill Joy in the mid 70's.

> I guarantee you that those who learned from K don't 
> think sizeof(unsigned long) "looks like a function".

Tell that to Linus. He wrote the email I referenced
which you so apparently blithely elided.

Repeating it:

"Another example of this is "sizeof". The kernel universally (I hope) has 
parenthesis around the sizeof argument, even though it's clearly not 
required by the C language."

> And typeof is a gnu extension, it's not part of the C99 standard.

Irrelevant as Linux uses it.

> You realize your patch doesn't catch kmalloc(sizeof *p, ...) since it's 
> checking for lval and the unary operator '*' is not considered part of an 
> identifier, right?

Oh look, useful feedback instead of useless carping about
how much I know or don't know c.

> Perhaps you should propose a patch that actually works 
> first because yours is busted.

I have one here.  I'll forward it soonish.

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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/7] Initial release of Samsung S2MPS11 pmic driver

[Sangbeom Kim]

Hi!
On Mon, Jul 09, 2012 at 08:13PM +0900, Samuel Ortiz wrote:
> Hi Sangbeom,
> 
> On Sat, Jul 07, 2012 at 06:39:12PM +0900, Sangbeom Kim wrote:
> > The S2MPS11 is comprised of high efficient Buck converters,
> > various LDOs, and an RTC and tightly coupled with Multi Core Samsung
> > Application Processors, which is used in a wide variety of mobile 
> > applications
> > such as smart phones and tablet PCs.
> > S2MPS11 provide 10 high efficiency buck converters and 38 LDO regulators.
> > Especially, Buck2 can support 7.0A current capacity for high performance
> > samsung application processor.
> > Most of S2MPS11 feature are similar to S5M series.
> > and Instead of using s5m prefix, Samsung decide to use s2m prefix.
> > So, I try to make common mfd driver for S2M and S5M series.
> > Most of s5m prefix is changed into sec prefix.
> >
> > Changes since V1:
> > 1. Replace list_voltage with standard framework
> > 2. Apply regmap_irq
> > 3. Minor changes.
> I was trying to apply this patchset to my for-next branch, but it doesn't
> apply properly.
> Could you please rebase it against this branch and send it to me ?
> 
> Cheers,
> Samuel.

Sorry, After rebase it, I will send again.

Thanks,
Sangbeom.

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] mm/hugetlb: fix error code in hugetlbfs_alloc_inode

[David Rientjes]

On Tue, 10 Jul 2012, Wanpeng Li wrote:

> diff --git a/fs/hugetlbfs/inode.c b/fs/hugetlbfs/inode.c
> index c4b85d0..79a0f33 100644
> --- a/fs/hugetlbfs/inode.c
> +++ b/fs/hugetlbfs/inode.c
> @@ -696,7 +696,7 @@ static struct inode *hugetlbfs_alloc_inode(struct 
> super_block *sb)
>   p = kmem_cache_alloc(hugetlbfs_inode_cachep, GFP_KERNEL);
>   if (unlikely(!p)) {
>   hugetlbfs_inc_free_inodes(sbinfo);
> - return NULL;
> + return ERR_PTR(-ENOMEM);
>   }
>   return >vfs_inode;
>  }

So now you've removed Gavin Shan who already told you that it was correct 
as written and propose yet another bogus patch which will break.  This 
isn't professional.

alloc_inode() tests for a NULL return value, not for PTR_ERR(), so you 
would be introducing a bug if this patch were merged.  It's completely 
correct the way it's written.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] mm/hugetlb: fix error code in hugetlbfs_alloc_inode

[David Rientjes]

On Tue, 10 Jul 2012, Wanpeng Li wrote:

> >>diff --git a/fs/hugetlbfs/inode.c b/fs/hugetlbfs/inode.c
> >>index c4b85d0..79a0f33 100644
> >>--- a/fs/hugetlbfs/inode.c
> >>+++ b/fs/hugetlbfs/inode.c
> >>@@ -696,7 +696,7 @@ static struct inode *hugetlbfs_alloc_inode(struct 
> >>super_block *sb)
> >>p = kmem_cache_alloc(hugetlbfs_inode_cachep, GFP_KERNEL);
> >>if (unlikely(!p)) {
> >>hugetlbfs_inc_free_inodes(sbinfo);
> >>-   return NULL;
> >>+   return -ENOMEM;
> >
> >The function is expecting "struct inode *", man.
> >
> >static struct inode *hugetlbfs_alloc_inode(struct super_block *sb)
> >
> Hmm, replace it by ERR_PTR(-ENOMEM). 
> 

Please listen to the feedback you're getting before you reply.

This function is called by alloc_inode().  It tests whether the return 
value is NULL or not, it doesn't check for PTR_ERR().  It's correct the 
way it's written and you would have broken it.

In the future, please demonstrate how you've tested your patches before 
proposing them.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] fail dentry revalidation after namespace change

[Eric W. Biederman]

Andrew Morton  writes:

> On Mon, 09 Jul 2012 17:30:48 -0700 ebied...@xmission.com (Eric W. Biederman) 
> wrote:
>
>> Andrew Morton  writes:
>> 
>> >>  {
>> >>   struct sysfs_dirent *sd;
>> >>   int is_dir;
>> >> + int type;
>> >>  
>> >>   if (nd->flags & LOOKUP_RCU)
>> >>   return -ECHILD;
>> >> @@ -326,6 +327,13 @@ static int sysfs_dentry_revalidate(struct dentry 
>> >> *dentry, struct nameidata *nd)
>> >>   if (strcmp(dentry->d_name.name, sd->s_name) != 0)
>> >>   goto out_bad;
>> >>  
>> >> + /* The sysfs dirent has been moved to a different namespace */
>> >> + type = KOBJ_NS_TYPE_NONE;
>> >> + if (sd->s_parent)
>> >> + type = sysfs_ns_type(sd->s_parent);
>> >> + if (type && (sysfs_info(dentry->d_sb)->ns[type] != sd->s_ns))
>> >
>> > eww, the code is assuming that KOBJ_NS_TYPE_NONE has a value of zero. 
>> > Don't do that; it smells bad.
>> 
>> Gag.  An incomplete change in idiom.
>> 
>> KOBJ_NS_TYPE_NONE is explicitly defined as 0 so that it can be used
>> this way, and every where else in fs/sysfs/dir.c uses this idiom.
>
> One man's idiom is another man's idiocy.

And code that uses inconsistent idioms is even harder to read.

A half assed cleanup is worse than no cleanup.

> Seriously.  What sort of idea is that?  Create an enumerated type and
> then just ignore it?

It isn't ignored.  It just has a well defined NULL value. That is hardly
controversial.

>> Pray tell in what parallel universe is that monstrosity above more
>> readable than the line it replaces?
>
> Don't be silly, it is not a "monstrosity".  The code it is modifying
> contains an unneeded test-and-branch.  It's a test and branch which the
> compiler might be able to avoid.  If we can demonstrate that the
> compiler does indeed optimise it, or if we can find a less monstrous
> way of implementing it then fine.  Otherwise, efficiency wins.

Efficiency wins?  In a rarely used function?  Which kernel are you
working on?

Readable maintainable code wins.  Unreadable code causes regressions.

Your addition while it may not be monstrous is most definitely less
readable.

Eric
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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: + checkpatch-add-check-for-use-of-sizeof-without-parenthesis.patch added to -mm tree

[David Rientjes]

On Mon, 9 Jul 2012, Joe Perches wrote:

> CodingStyle already does suggest parenthesis around sizeof
> 
> 3.1:  Spaces
> 
> Linux kernel style for use of spaces depends (mostly) on
> function-versus-keyword usage.  Use a space after (most) keywords.  The
> notable exceptions are sizeof, typeof, alignof, and __attribute__, which look
> somewhat like functions (and are usually used with parentheses in Linux,
> although they are not required in the language, as in: "sizeof info" after
> "struct fileinfo info;" is declared).
> 
> So use a space after these keywords:
>   if, switch, case, for, do, while
> but not with sizeof, typeof, alignof, or __attribute__.  E.g.,
>   s = sizeof(struct file);
> 

This doesn't suggest parenthesis for sizeof at all times, it's saying that 
Linux doesn't use the gcc, glibc, C99 way of doing "sizeof (struct file)" 
for type names as I've already said three times and rather prefers 
"sizeof(struct file)".  That's fine.

I'm talking about the C99 specification that says the sizeof operator act 
on unary expressions, i.e. not type names that you keep talking about and 
apparently don't understand the difference between.  Casts are done with 
type names, you can't do "unsigned long ptr", you do "(unsigned long)ptr".  
Sizeof operators using type names do the same thing: 
"sizeof (unsigned long)".  The space is just a stylistic difference.

You may not understand the difference between a type and a unary 
expression, but other C programmers do, i.e. those who have implemented 
the over 1000 places in the kernel that already do this because they 
learned from K  I guarantee you that those who learned from K don't 
think sizeof(unsigned long) "looks like a function".

And typeof is a gnu extension, it's not part of the C99 standard.

> and
> 
> Chapter 14: Allocating memory
> []
> The preferred form for passing a size of a struct is the following:
> 
>   p = kmalloc(sizeof(*p), ...);
> 

You realize your patch doesn't catch kmalloc(sizeof *p, ...) since it's 
checking for lval and the unary operator '*' is not considered part of an 
identifier, right?  Perhaps you should propose a patch that actually works 
first because yours is busted.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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 ext4 tree

[Aditya Kali]

Sorry for the trouble. The following patch should fix the build.


From: Aditya Kali 
Date: Mon, 9 Jul 2012 18:42:28 -0700
Subject: [PATCH] ext4: Fix compilation error for ext4_enable_quotas

ext4_enable_quotas should only be called under CONFIG_QUOTA
block.

Signed-off-by: Aditya Kali 
---
 fs/ext4/super.c |2 ++
 1 files changed, 2 insertions(+), 0 deletions(-)

diff --git a/fs/ext4/super.c b/fs/ext4/super.c
index a9b87c3..e4b79fc 100644
--- a/fs/ext4/super.c
+++ b/fs/ext4/super.c
@@ -4734,6 +4734,7 @@ static int ext4_remount(struct super_block *sb,
int *flags, char *data)
if (enable_quota) {
if (sb_any_quota_suspended(sb))
dquot_resume(sb, -1);
+#ifdef CONFIG_QUOTA
else if (EXT4_HAS_RO_COMPAT_FEATURE(sb,
EXT4_FEATURE_RO_COMPAT_QUOTA)) {
err = ext4_enable_quotas(sb);
@@ -4742,6 +4743,7 @@ static int ext4_remount(struct super_block *sb,
int *flags, char *data)
goto restore_opts;
}
}
+#endif
}

ext4_msg(sb, KERN_INFO, "re-mounted. Opts: %s", orig_data);
-- 
1.7.7.3


On Mon, Jul 9, 2012 at 6:23 PM, Stephen Rothwell  wrote:
> Hi Ted,
>
> After merging the ext4 tree, today's linux-next build (powerpc
> ppc64_defconfig) failed like this:
>
> fs/ext4/super.c: In function 'ext4_remount':
> fs/ext4/super.c:4739:4: error: implicit declaration of function 
> 'ext4_enable_quotas' [-Werror=implicit-function-declaration]
>
> Caused by commit 182bb8fec8f5 ("ext4: make quota as first class supported
> feature").  The quota code needs to be protected by CONFIG_QUOTA.
>
> I have used the ext4 tree from next-20120709 for today.
> --
> Cheers,
> Stephen Rothwells...@canb.auug.org.au



-- 

Aditya
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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 01/13] rbtree: reference Documentation/rbtree.txt for usage instructions

[Rik van Riel]

On 07/09/2012 07:35 PM, Michel Lespinasse wrote:

include/linux/rbtree.h included some basic usage instructions, while
Documentation/rbtree.txt had some more complete and easier to follow
instructions.  Replacing the former with a reference to the latter.

Signed-off-by: Michel Lespinasse


Acked-by: Rik van Riel 

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

btrfs_inode.h and Oracle

[Chris Jones]

Just checking out some btrfs stuff and notices the copyright notes in 
btfrs_inode.h belong to Oracle. I had no idea that btrfs had anything to 
do with Oracle. What's the link with Oracle?



Regards

--
Chris Jones @ kernel.devproj...@gmail.com
also on oracle.kernel...@gmail.com and netbsd.kernel...@gmail.com

OpenSUSE 12.1 (Primary)|TinyCore|Parabola|OpenIndiana|NetBSD (PC)
Android 4.0.3 (Smartphone)|Windows 7 (Laptop)|Windows XP (Gaming)
Linux kernel developer|Solaris kernel developer|BSD kernel developer
Lead Developer of SDL|Lead Developer of Nest Linux|Gamer and Emulator nut|Web 
Services|Digital Imaging Services
Controllers: Rapier V2 Gaming mouse|Logitech Precision|PS3 controller|XB360 
controller|Logitech Attack 3 j/stick
Emulators: Fusion|Gens|ZSNES|Project64|PCSX-R|Stella|WinVICE|WinUAE|DOSBox

PGP Fingerprint: 4E38 0776 B380 63C8 F64F
A7D6 736C CF56 42A4 FB35

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] staging: bcm: Misc.c: Remove unused macros

[Marcos Paulo de Souza]

These macros were reported by forgotten-macros tool
(https://github.com/marcosps/forgotten_macros).

Signed-off-by: Marcos Paulo de Souza 
---
 drivers/staging/bcm/Misc.c |3 ---
 1 file changed, 3 deletions(-)

diff --git a/drivers/staging/bcm/Misc.c b/drivers/staging/bcm/Misc.c
index d7c662d..9a60d4c 100644
--- a/drivers/staging/bcm/Misc.c
+++ b/drivers/staging/bcm/Misc.c
@@ -1206,9 +1206,6 @@ static void convertEndian(B_UINT8 rwFlag, PUINT 
puiBuffer, UINT uiByteCount)
}
 }
 
-#define CACHE_ADDRESS_MASK 0x8000
-#define UNCACHE_ADDRESS_MASK 0xa000
-
 int rdm(struct bcm_mini_adapter *Adapter, UINT uiAddress, PCHAR pucBuff, 
size_t sSize)
 {
return Adapter->interface_rdm(Adapter->pvInterfaceAdapter,
-- 
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/

Re: [PATCH SLAB 1/2 v3] duplicate the cache name in SLUB's saved_alias list, SLAB, and SLOB

[Li Zhong]

On Mon, 2012-07-09 at 09:01 -0500, Christoph Lameter wrote:
> > I was pointed by Glauber to the slab common code patches. I need some
> > more time to read the patches. Now I think the slab/slot changes in this
> > v3 are not needed, and can be ignored.
> 
> That may take some kernel cycles. You have a current issue here that needs
> to be fixed.

I'm a little confused ... and what need I do for the next step? 

> 
> > >   down_write(_lock);
> > > - s = find_mergeable(size, align, flags, name, ctor);
> > > + s = find_mergeable(size, align, flags, n, ctor);
> > >   if (s) {
> > >   s->refcount++;
> > >   /*
> >
> > ..
> > up_write(_lock);
> > return s;
> > }
> >
> > Here, the function returns without name string n be kfreed.
> 
> That is intentional since the string n is still referenced by the entry
> that sysfs_slab_alias has created.

I'm not sure whether the "referenced by ..." you mentioned is what I
understood. From my understanding:

if slab_state == SYS_FS, after 
return sysfs_create_link(_kset->kobj, >kobj, name); 
is called, the name string passed in sysfs_slab_alias is no longer
referenced (sysfs_new_dirent duplicates the string for sysfs to use).

else, the name sting is referenced by 
al->name = name;
temporarily. After slab_sysfs_init is finished, the name is not
referenced any more.

So in my patch (slub part), the string is duplicated here, and kfreed in
slab_sysfs_init.

> > But we couldn't kfree n here, because in sysfs_slab_alias(), if
> > (slab_state < SYS_FS), the name need to be kept valid until
> > slab_sysfs_init() is finished adding the entry into sysfs.
> 
> Right that is why it is not freed and that is what fixes the issue you
> see.
> 


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] staging: bcm: Remove all commented macros

[Marcos Paulo de Souza]

All these macros are commented, and can be removed.

Signed-off-by: Marcos Paulo de Souza 
---
 drivers/staging/bcm/CmHost.c |1 -
 drivers/staging/bcm/Debug.h  |5 -
 drivers/staging/bcm/Macros.h |1 -
 drivers/staging/bcm/PHSDefines.h |1 -
 4 files changed, 8 deletions(-)

diff --git a/drivers/staging/bcm/CmHost.c b/drivers/staging/bcm/CmHost.c
index 9c8c9b1..b54ec97 100644
--- a/drivers/staging/bcm/CmHost.c
+++ b/drivers/staging/bcm/CmHost.c
@@ -4,7 +4,6 @@
  * Management.
  /
 
-/* #define CONN_MSG */
 #include "headers.h"
 
 enum E_CLASSIFIER_ACTION {
diff --git a/drivers/staging/bcm/Debug.h b/drivers/staging/bcm/Debug.h
index 420382d..8018a18 100644
--- a/drivers/staging/bcm/Debug.h
+++ b/drivers/staging/bcm/Debug.h
@@ -42,10 +42,6 @@
 #define ARP_REQ(TX<<5)
 #define ARP_RESP   (TX<<6)
 
-// dhcp.c
-//#define DHCP TX
-//#define DHCP_REQ (DHCP<<7)
-
 // Leakybucket.c
 #define TOKEN_COUNTS (TX<<8)
 #define CHECK_TOKENS (TX<<9)
@@ -147,7 +143,6 @@ DriverEntry.c, bcmfwup.c, ChipDetectTask.c, HaltnReset.c, 
InterfaceDDR.c */
 
 #define HOST_MIBS  (OTHERS << 28)
 #define CONN_MSG   (CMHOST << 29)
-//#define OTHERS_MISC  (OTHERS << 29)  // ProcSupport.c
 /*-END SUBTYPEs--*/
 
 
diff --git a/drivers/staging/bcm/Macros.h b/drivers/staging/bcm/Macros.h
index b5ca6f6..46f5f0f 100644
--- a/drivers/staging/bcm/Macros.h
+++ b/drivers/staging/bcm/Macros.h
@@ -6,7 +6,6 @@
 
 #define TX_TIMER_PERIOD 10 /*10 msec*/
 #define MAX_CLASSIFIERS 100
-/* #define MAX_CLASSIFIERS_PER_SF  20 */
 #define MAX_TARGET_DSX_BUFFERS 24
 
 #define MAX_CNTRL_PKTS100
diff --git a/drivers/staging/bcm/PHSDefines.h b/drivers/staging/bcm/PHSDefines.h
index eed4cfc..6016fc5 100644
--- a/drivers/staging/bcm/PHSDefines.h
+++ b/drivers/staging/bcm/PHSDefines.h
@@ -27,7 +27,6 @@
 #define PHS_BUFFER_SIZE 1532
 
 
-//#define MAX_PHS_LENGTHS 100
 #define MAX_PHSRULE_PER_SF   20
 #define MAX_SERVICEFLOWS17
 
-- 
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 1/3] staging: bcm: Remove code that will never execute

[Marcos Paulo de Souza]

This patch removes all references of "if 0" blocks in the bcm drivers.

Signed-off-by: Marcos Paulo de Souza 
---
 drivers/staging/bcm/Misc.c |   63 
 1 file changed, 63 deletions(-)

diff --git a/drivers/staging/bcm/Misc.c b/drivers/staging/bcm/Misc.c
index c36fd76..d7c662d 100644
--- a/drivers/staging/bcm/Misc.c
+++ b/drivers/staging/bcm/Misc.c
@@ -402,30 +402,6 @@ INT CopyBufferToControlPacket(struct bcm_mini_adapter 
*Adapter, PVOID ioBuffer)
return Status;
 }
 
-#if 0
-/*
-* Function- SendStatisticsPointerRequest()
-*
-* Description - This function builds and forwards the Statistics
-* Pointer Request control Packet.
-*
-* Parameters  - Adapter: Pointer to 
Adapter structure.
-* - pstStatisticsPtrRequest : Pointer to link request.
-*
-* Returns - None.
-*/
-static VOID SendStatisticsPointerRequest(struct bcm_mini_adapter *Adapter, 
struct bcm_link_request *pstStatisticsPtrRequest)
-{
-   BCM_DEBUG_PRINT(Adapter, DBG_TYPE_RX, RX_DPC, DBG_LVL_ALL, "==>");
-   pstStatisticsPtrRequest->Leader.Status = STATS_POINTER_REQ_STATUS;
-   pstStatisticsPtrRequest->Leader.PLength = sizeof(ULONG); /* minimum 4 
bytes */
-   pstStatisticsPtrRequest->szData[0] = STATISTICS_POINTER_REQ;
-   CopyBufferToControlPacket(Adapter, pstStatisticsPtrRequest);
-   BCM_DEBUG_PRINT(Adapter, DBG_TYPE_RX, RX_DPC, DBG_LVL_ALL, "<=");
-   return;
-}
-#endif
-
 /**
 * Function- LinkMessage()
 *
@@ -1217,45 +1193,6 @@ static VOID doPowerAutoCorrection(struct 
bcm_mini_adapter *psAdapter)
}
 }
 
-#if 0
-static unsigned char *ReadMacAddrEEPROM(struct bcm_mini_adapter *Adapter, 
ulong dwAddress)
-{
-   int status = 0, i = 0;
-   unsigned int temp = 0;
-   unsigned char *pucmacaddr = kmalloc(MAC_ADDRESS_SIZE, GFP_KERNEL);
-   int bytes;
-
-   if (!pucmacaddr) {
-   BCM_DEBUG_PRINT(Adapter, DBG_TYPE_PRINTK, 0, 0, "No Buffers to 
Read the EEPROM Address\n");
-   return NULL;
-   }
-
-   dwAddress |= 0x5b00;
-   status = wrmalt(Adapter, EEPROM_COMMAND_Q_REG, (PUINT), 
sizeof(UINT));
-   if (status != STATUS_SUCCESS) {
-   BCM_DEBUG_PRINT(Adapter, DBG_TYPE_PRINTK, 0, 0, "wrm 
Failed..\n");
-   kfree(pucmacaddr);
-   pucmacaddr = NULL;
-   goto OUT;
-   }
-
-   for (i = 0; i < MAC_ADDRESS_SIZE; i++) {
-   bytes = rdmalt(Adapter, EEPROM_READ_DATA_Q_REG, , 
sizeof(temp));
-   if (bytes < 0) {
-   status = bytes;
-   BCM_DEBUG_PRINT(Adapter, DBG_TYPE_PRINTK, 0, 0, "rdm 
Failed..\n");
-   kfree(pucmacaddr);
-   pucmacaddr = NULL;
-   goto OUT;
-   }
-   pucmacaddr[i] = temp & 0xff;
-   BCM_DEBUG_PRINT(Adapter, DBG_TYPE_INITEXIT, DRV_ENTRY, 
DBG_LVL_ALL, "%x\n", pucmacaddr[i]);
-   }
-OUT:
-   return pucmacaddr;
-}
-#endif
-
 static void convertEndian(B_UINT8 rwFlag, PUINT puiBuffer, UINT uiByteCount)
 {
UINT uiIndex = 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 0/3] staging: bcm: Cleanup bcm driver

[Marcos Paulo de Souza]

Hi Kernel guys!
   
This new patchset tries to clean a little the bcm driver, removing
some unused macros and some dead code.
  
These macros and dead code were reported by the forgotten-macros tool
(https://github.com/marcosps/forgotten_macros).
  
The tool is under development, but all the patches looks like OK.   
   
This patchset is based in staging-next.
  
Thanks guys!

Marcos Paulo de Souza (3):
  staging: bcm: Remove code that will never execute
  staging: bcm: Remove all commented macros
  staging: bcm: Misc.c: Remove unused macros

 drivers/staging/bcm/CmHost.c |1 -
 drivers/staging/bcm/Debug.h  |5 ---
 drivers/staging/bcm/Macros.h |1 -
 drivers/staging/bcm/Misc.c   |   66 --
 drivers/staging/bcm/PHSDefines.h |1 -
 5 files changed, 74 deletions(-)

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

Re: [PATCH v4 2/3] KVM-INTEL: Add new module vmcsinfo-intel to fill VMCSINFO

[HATAYAMA Daisuke]

From: Yanfei Zhang 
Subject: [PATCH v4 2/3] KVM-INTEL: Add new module vmcsinfo-intel to fill 
VMCSINFO
Date: Wed, 4 Jul 2012 18:05:19 +0800

> 
> Besides, this patch also exports vmcs revision identifier via
> /sys/devices/system/cpu/vmcs_id and offsets of fields via
> /sys/devices/system/cpu/vmcs/.

I think /sys/devices/system/cpu/vmcs/id is more natural, which also
belongs to vmcs.


> +/*
> + * vmcs field offsets.
> + */
> +static struct vmcsinfo {
> + u32 vmcs_revision_id;
> + u16 vmcs_field_to_offset_table[HOST_RIP + 1];
> +} vmcsinfo;

This is what I said previously. HOST_RIP is 0x6c16 => 27670. This
means sizeof (struct vmcsinfo) => 55346 bytes == 54 kbytes. But
actually exported fields are only 153, so 4 + 2 * 153 => 310 bytes are
enough.

How about getting the number of attributes from vmcs_attrs array? I
guess this is exactly the number of vmcs fields exported; here 153.

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

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

[Stephen Rothwell]

Hi Ted,

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

fs/ext4/super.c: In function 'ext4_remount':
fs/ext4/super.c:4739:4: error: implicit declaration of function 
'ext4_enable_quotas' [-Werror=implicit-function-declaration]

Caused by commit 182bb8fec8f5 ("ext4: make quota as first class supported
feature").  The quota code needs to be protected by CONFIG_QUOTA.

I have used the ext4 tree from next-20120709 for today.
-- 
Cheers,
Stephen Rothwells...@canb.auug.org.au


pgpxgdssHA4WH.pgp
Description: PGP signature

Re: [PATCH] mm/hugetlb: fix error code in hugetlbfs_alloc_inode

[Wanpeng Li]

On Tue, Jul 10, 2012 at 09:09:10AM +0800, Gavin Shan wrote:
>On Tue, Jul 10, 2012 at 09:03:04AM +0800, Wanpeng Li wrote:
>>From: Wanpeng Li 
>>
>>When kmem_cache_alloc fails alloc slab object from
>>hugetlbfs_inode_cachep, return -ENOMEM in usual. But
>>hugetlbfs_alloc_inode implementation has inconsitency
>>with it and returns NULL. Fix it to return -ENOMEM.
>>
>>Signed-off-by: Wanpeng Li 
>>---
>> fs/hugetlbfs/inode.c |2 +-
>> 1 files changed, 1 insertions(+), 1 deletions(-)
>>
>>diff --git a/fs/hugetlbfs/inode.c b/fs/hugetlbfs/inode.c
>>index c4b85d0..79a0f33 100644
>>--- a/fs/hugetlbfs/inode.c
>>+++ b/fs/hugetlbfs/inode.c
>>@@ -696,7 +696,7 @@ static struct inode *hugetlbfs_alloc_inode(struct 
>>super_block *sb)
>>  p = kmem_cache_alloc(hugetlbfs_inode_cachep, GFP_KERNEL);
>>  if (unlikely(!p)) {
>>  hugetlbfs_inc_free_inodes(sbinfo);
>>- return NULL;
>>+ return -ENOMEM;
>
>The function is expecting "struct inode *", man.
>
>static struct inode *hugetlbfs_alloc_inode(struct super_block *sb)
>
Hmm, replace it by ERR_PTR(-ENOMEM). 

Regards,
Wanpeng Li

>Thanks,
>Gavin
>
>>  }
>>  return >vfs_inode;
>> }
>>-- 
>>1.7.5.4
>>
>>--
>>To unsubscribe, send a message with 'unsubscribe linux-mm' in
>>the body to majord...@kvack.org.  For more info on Linux MM,
>>see: http://www.linux-mm.org/ .
>>Don't email: mailto:"d...@kvack.org;> em...@kvack.org 
>>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH v2] mm/hugetlb: fix error code in hugetlbfs_alloc_inode

[Wanpeng Li]

From: Wanpeng Li 

Changelog:
*v2 change -ENOMEM to ERR_PTR(-ENOMEM);

When kmem_cache_alloc fails alloc slab object from
hugetlbfs_inode_cachep, return -ENOMEM in usual. But
hugetlbfs_alloc_inode implementation has inconsitency
with it and returns NULL. Fix it to return -ENOMEM.

Signed-off-by: Wanpeng Li 
---
 fs/hugetlbfs/inode.c |2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/fs/hugetlbfs/inode.c b/fs/hugetlbfs/inode.c
index c4b85d0..79a0f33 100644
--- a/fs/hugetlbfs/inode.c
+++ b/fs/hugetlbfs/inode.c
@@ -696,7 +696,7 @@ static struct inode *hugetlbfs_alloc_inode(struct 
super_block *sb)
p = kmem_cache_alloc(hugetlbfs_inode_cachep, GFP_KERNEL);
if (unlikely(!p)) {
hugetlbfs_inc_free_inodes(sbinfo);
-   return NULL;
+   return ERR_PTR(-ENOMEM);
}
return >vfs_inode;
 }
-- 
1.7.5.4

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

Re: [PATCH] mm/hugetlb: fix error code in hugetlbfs_alloc_inode

[Gavin Shan]

On Tue, Jul 10, 2012 at 09:03:04AM +0800, Wanpeng Li wrote:
>From: Wanpeng Li 
>
>When kmem_cache_alloc fails alloc slab object from
>hugetlbfs_inode_cachep, return -ENOMEM in usual. But
>hugetlbfs_alloc_inode implementation has inconsitency
>with it and returns NULL. Fix it to return -ENOMEM.
>
>Signed-off-by: Wanpeng Li 
>---
> fs/hugetlbfs/inode.c |2 +-
> 1 files changed, 1 insertions(+), 1 deletions(-)
>
>diff --git a/fs/hugetlbfs/inode.c b/fs/hugetlbfs/inode.c
>index c4b85d0..79a0f33 100644
>--- a/fs/hugetlbfs/inode.c
>+++ b/fs/hugetlbfs/inode.c
>@@ -696,7 +696,7 @@ static struct inode *hugetlbfs_alloc_inode(struct 
>super_block *sb)
>   p = kmem_cache_alloc(hugetlbfs_inode_cachep, GFP_KERNEL);
>   if (unlikely(!p)) {
>   hugetlbfs_inc_free_inodes(sbinfo);
>-  return NULL;
>+  return -ENOMEM;

The function is expecting "struct inode *", man.

static struct inode *hugetlbfs_alloc_inode(struct super_block *sb)

Thanks,
Gavin

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

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

Re: [PATCH v4 2/3] KVM-INTEL: Add new module vmcsinfo-intel to fill VMCSINFO

[HATAYAMA Daisuke]

From: Wen Congyang 
Subject: Re: [PATCH v4 2/3] KVM-INTEL: Add new module vmcsinfo-intel to fill 
VMCSINFO
Date: Fri, 6 Jul 2012 16:25:23 +0800

> At 07/06/2012 04:04 PM, HATAYAMA Daisuke Wrote:
>> From: Yanfei Zhang 
>> Subject: [PATCH v4 2/3] KVM-INTEL: Add new module vmcsinfo-intel to fill 
>> VMCSINFO
>> Date: Wed, 4 Jul 2012 18:05:19 +0800
>> 
>>> Besides, this patch also exports vmcs revision identifier via
>>> /sys/devices/system/cpu/vmcs_id and offsets of fields via
>>> /sys/devices/system/cpu/vmcs/.
>>> Individual offsets are contained in subfiles named by the filed's
>>> encoding, e.g.: /sys/devices/cpu/vmcs/0800
>> 
>> According to the discussion starting from
>> 
>> http://lkml.indiana.edu/hypermail/linux/kernel/1105.3/00749.html
> 
> IIRC, kvm can not work in such environment. The vcpu can run on
> different cpu. If the cpu's vmcs is different, I don't know what
> will happen. So do we need to support for such environment now?
> I think that if kvm can not work in such environment, we should
> not provide vmcs information for each physical cpu.
> 

Ah, I noticed my basic confusion: if it --- vcpu can run on cpus with
differnet VMCS revision --- were possible, this vmcsinfo would be
unnecessary because it would mean processer could read VMCS data with
revision different from its own one or some kind of reverse
engineering for convertion of differnet VMCS data were done.

I think kvm could probably work if only processors that have the same
VMCS revision are assigned to a single guest. But considering the VMCS
nature, such processor with differnet revision seems unlikely to be
used on host machine.

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

[PATCH] mm/hugetlb: fix error code in hugetlbfs_alloc_inode

[Wanpeng Li]

From: Wanpeng Li 

When kmem_cache_alloc fails alloc slab object from
hugetlbfs_inode_cachep, return -ENOMEM in usual. But
hugetlbfs_alloc_inode implementation has inconsitency
with it and returns NULL. Fix it to return -ENOMEM.

Signed-off-by: Wanpeng Li 
---
 fs/hugetlbfs/inode.c |2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/fs/hugetlbfs/inode.c b/fs/hugetlbfs/inode.c
index c4b85d0..79a0f33 100644
--- a/fs/hugetlbfs/inode.c
+++ b/fs/hugetlbfs/inode.c
@@ -696,7 +696,7 @@ static struct inode *hugetlbfs_alloc_inode(struct 
super_block *sb)
p = kmem_cache_alloc(hugetlbfs_inode_cachep, GFP_KERNEL);
if (unlikely(!p)) {
hugetlbfs_inc_free_inodes(sbinfo);
-   return NULL;
+   return -ENOMEM;
}
return >vfs_inode;
 }
-- 
1.7.5.4

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

[PATCH v2] mm: Warn about costly page allocation

[Minchan Kim]

Since lumpy reclaim was introduced at 2.6.23, it helped higher
order allocation.
Recently, we removed it at 3.4 and we didn't enable compaction
forcingly[1]. The reason makes sense that compaction.o + migration.o
isn't trivial for system doesn't use higher order allocation.
But the problem is that we have to enable compaction explicitly
while lumpy reclaim enabled unconditionally.

Normally, admin doesn't know his system have used higher order
allocation and even lumpy reclaim have helped it.
Admin in embdded system have a tendency to minimise code size so that
they can disable compaction. In this case, we can see page allocation
failure we can never see in the past. It's critical on embedded side
because...

Let's think this scenario.

There is QA team in embedded company and they have tested their product.
In test scenario, they can allocate 100 high order allocation.
(they don't matter how many high order allocations in kernel are needed
during test. their concern is just only working well or fail of their
middleware/application) High order allocation will be serviced well
by natural buddy allocation without lumpy's help. So they released
the product and sold out all over the world.
Unfortunately, in real practice, sometime, 105 high order allocation was
needed rarely and fortunately, lumpy reclaim could help it so the product
doesn't have a problem until now.

If they use latest kernel, they will see the new config CONFIG_COMPACTION
which is very poor documentation, and they can't know it's replacement of
lumpy reclaim(even, they don't know lumpy reclaim) so they simply disable
that option for size optimization. Of course, QA team still test it but they
can't find the problem if they don't do test stronger than old.
It ends up release the product and sold out all over the world, again.
But in this time, we don't have both lumpy and compaction so the problem
would happen in real practice. A poor enginner from Korea have to flight
to the USA for the fix a ton of products. Otherwise, should recall products
from all over the world. Maybe he can lose a job. :(

This patch adds warning for notice. If the system try to allocate
PAGE_ALLOC_COSTLY_ORDER above page and system enters reclaim path,
it emits the warning. At least, it gives a chance to look into their
system before the relase.

Please keep in mind. It's not a good idea to depend lumpy/compaction
for regular high-order allocations. Both depends on being able to move
MIGRATE_MOVABLE allocations to satisfy the high-order allocation. If used
reregularly for high-order kernel allocations and tehy are long-lived,
the system will eventually be unable to grant these allocations, with or
without compaction or lumpy reclaim. Hatchet jobs that work around this problem
include forcing MIGRATE_RESERVE to be only used for high-order allocations
and tuning its size. It's a major hack though and is unlikely to be merged
to mainline but might suit an embedded product.

This patch avoids false positive by alloc_large_system_hash which
allocates with GFP_ATOMIC and a fallback mechanism so it can make
this warning useless.

[1] c53919ad(mm: vmscan: remove lumpy reclaim)

Signed-off-by: Minchan Kim 
---
Changelog

* from v1
 - add more description about warning failure of high-order allocation
 - use printk_ratelimited/pr_warn and dump stack - [Mel, Andrew]
 - noinline/__always_inline optimization - Andrew
 - modify warning message - Andrew

 mm/page_alloc.c |   37 +
 1 file changed, 37 insertions(+)

diff --git a/mm/page_alloc.c b/mm/page_alloc.c
index a4d3a19..a8f60d0 100644
--- a/mm/page_alloc.c
+++ b/mm/page_alloc.c
@@ -2276,6 +2276,41 @@ gfp_to_alloc_flags(gfp_t gfp_mask)
return alloc_flags;
 }
 
+#if defined(CONFIG_DEBUG_VM) && !defined(CONFIG_COMPACTION)
+
+static DEFINE_RATELIMIT_STATE(highorderalloc_rs,
+   DEFAULT_RATELIMIT_INTERVAL,
+   DEFAULT_RATELIMIT_BURST);
+
+static noinline void __check_page_alloc_costly_order(unsigned int order,
+   gfp_t flags)
+{
+   if ((flags & __GFP_NOWARN) || !__ratelimit(_rs))
+   return;
+
+   pr_warn("%s: try allocating high-order allocation: "
+   "order:%d, mode:0x%x\n", current->comm, order, flags);
+   pr_warn("Enable CONFIG_COMPACTION if high-order allocations are "
+   "very few and rare.\n");
+   pr_warn("If you see this message frequently and regularly, "
+   "CONFIG_COMPACTION wouldn't help it. Then, please send "
+   "an email to linux...@kvack.org\n");
+   dump_stack();
+}
+
+static __always_inline void check_page_alloc_costly_order(unsigned int order,
+   gfp_t flags)
+{
+   if (unlikely(order > PAGE_ALLOC_COSTLY_ORDER))
+   __check_page_alloc_costly_order(order, flags);
+}
+#else
+static inline void check_page_alloc_costly_order(unsigned int order,

Re: [GIT PULL] sound updates for 3.5-rc1

[Joseph Salisbury]

On 05/23/2012 05:25 AM, Takashi Iwai wrote:
> Linus,
> 
> please pull the first sound updates for v3.5-rc1 from:
> 
>   git://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound.git sound-3.5
> 
> The topmost commit is 85e184e4c3cd3e2285ceab91ff8f0cac094e8a85
> 
> Note that the pull to the current your tree will give some trivial
> conflicts in regmap, sound/soc/imx and sound/soc/mxs.
> 
> This is the first big chunk of sound updates for 3.5-rc1 merge.
> There are a few big changes in different areas.  First off, the
> streaming logic of USB-audio endpoints has been largely rewritten
> for the better support of "implicit feedback".  If anything about USB
> got broken, this change has to be checked.
> 
> For HD-audio, the resume procedure was changed; instead of delaying
> the resume of the hardware until the first use, now waking up immediately
> at resume.  This is for buggy BIOS.
> 
> For ASoC, dynamic PCM support and the improved support for digital links
> between off-SoC devices are major framework changes.
> 
> Some highlights below:
> 
> * HD-audio
> - Avoid the accesses of invalid pin-control bits that may stall the codec
> - V-ref setup cleanups
> - Fix the races in power-saving code
> - Fix the races in codec cache hashes and connection lists
> - Split some common codes for BIOS auto-parser to hda_auto_parser.c
> - Changed the PM resume code to wake up immediately for buggy BIOS
> - Creative SoundCore3D support
> - Add Conexant CX20751/2/3/4 codec support
> 
> * ASoC
> - Dynamic PCM support, allowing support for SoCs with internal routing
>   through components with tight sequencing and formatting constraints
>   within their internal paths or where there are multiple components
>   connected with CPU managed DMA controllers inside the SoC.
> - Greatly improved support for direct digital links between off-SoC
>   devices, providing a much simpler way of connecting things like digital
>   basebands to CODECs.
> - Much more fine grained and robust locking, cleaning up some of the
>   confusion that crept in with multi-component.
> - CPU support for nVidia Tegra 30 I2S and audio hub controllers and
>   ST-Ericsson MSP I2S controolers
> - New CODEC drivers for Cirrus CS42L52, LAPIS Semiconductor ML26124, Texas
>   Instruments LM49453.
> - Some regmap changes needed by the Tegra I2S driver.
> - mc13783 audio support.
> 
> * Misc
> - Rewrite with module_pci_driver()
> - Xonar DGX support for snd-oxygen
> - Improvement of packet handling in snd-firewire driver
> - New USB-endpoint streaming logic
> - Enhanced M-audio FTU quirks and relevant cleanups
> - Increment the support of OSS devices to 256
> - snd-aloop accuracy improvement
> 
> There are a few more pending changes for 3.5, but they will be
> sent later (likely in the next week) after DRM changes are merged,
> as they depend on VGA-switcheroo changes.
> 
> Thanks!
> 
> 
> Takashi
> 
> ===
> 
> Andrew Morton (1):
>   ALSA: usb-audio: sound/usb/endpoint.c: suppress warning
> 
> Ashish Chavan (5):
>   ASoC: da7210: Add support for spi regmap
>   ASoC: da7210: Add support for PLL and SRM
>   ASoC: da7210: Minor update for PLL and SRM
>   ASoC: da7210: Minor bugfix for non pll slave mode
>   ASoC: da7210: Minor improvements and a bugfix
> 
> Axel Lin (3):
>   ASoC: alc5623: Convert to module_i2c_driver()
>   ASoC: alc5632: Convert to module_i2c_driver()
>   ASoC: alc5632: Convert to devm_regmap_init_i2c()
> 
> Bo Shen (1):
>   ALSA: atmel/ac97c: correct the unexpected behavior when using uninitial 
> value for reset pin
> 
> Brian Austin (6):
>   ASoC: core: Rework SOC_DOUBLE_R_SX_TLV add SOC_SINGLE_SX_TLV
>   ASoC: core: Initialize err for snd_soc_put_volsw_sx
>   ASoC: Add support for CS42L52 Codec
>   ASoC: cs42l73: Convert to module_i2c_driver()
>   ASoC: cs42l73: Remove Chip ID's from reg_default
>   ASoC: cs42l73: Use DAPM routes to hook AIF widgets to DAI's
> 
> Clemens Ladisch (4):
>   ALSA: oxygen: add Xonar DGX support
>   ALSA: firewire-lib: taskletize the snd_pcm_period_elapsed() call
>   ALSA: firewire-lib: flush completed packets when reading PCM position
>   ALSA: firewire-lib: optimize packet flushing
> 
> Dan Carpenter (1):
>   ASoC: dapm: release lock on error paths
> 
> Daniel Mack (9):
>   ALSA: snd-usb: add snd_usb_audio-wide mutex
>   ALSA: snd-usb: implement new endpoint streaming model
>   ALSA: snd-usb: switch over to new endpoint streaming logic
>   ALSA: snd-usb: remove old streaming logic
>   ALSA: snd-usb: add support for implicit feedback
>   ALSA: snd-usb: add some documentation
>   ALSA: snd-usb: remove refactorization left-overs
>   ALSA: snd-usb: fix some typos in endpoint.c documentation
>   ALSA: snd-usb: fix stream info output in /proc
> 
> David Henningsson (2):
>   ALSA: hda - Fix internal mic for Lenovo Ideapad U300s
>   ALSA: hda - Fix oops caused by recent commit "Fix internal mic 

Re: + checkpatch-add-check-for-use-of-sizeof-without-parenthesis.patch added to -mm tree

[Joe Perches]

On Mon, 2012-07-09 at 16:47 -0700, David Rientjes wrote:
> On Mon, 9 Jul 2012, Joe Perches wrote:
> 
> > > So, nack, don't start enforcing your own coding style and preferences in 
> > > checkpatch.pl.
> > 
> > Not just my opinion.
> > 
> > https://lkml.org/lkml/2008/12/23/138
> > 
> > Date: Tue, 23 Dec 2008 10:08:50 -0800 (PST)
> > From: Linus Torvalds <>
> > []
> > Another example of this is "sizeof". The kernel universally (I hope) has 
> > parenthesis around the sizeof argument, even though it's clearly not 
> > required by the C language. 
> > 
> 
> Well, let's add Linus to the cc then because it's certainly not a C 
> standard.  The sizeof operator requires parenthesis for type names, you 
> can't do "sizeof unsigned long", for example, it requires 
> "sizeof (unsigned long)".  All other unary operators do not need the 
> parenthesis by ANY C standard.
> 
> Documentation/CodingStyle does not ask for the parenthesis to be added 
> just like it doesn't ask for parenthesis to do things like (i++); which is 
> another unary operator.

CodingStyle already does suggest parenthesis around sizeof

3.1:  Spaces

Linux kernel style for use of spaces depends (mostly) on
function-versus-keyword usage.  Use a space after (most) keywords.  The
notable exceptions are sizeof, typeof, alignof, and __attribute__, which look
somewhat like functions (and are usually used with parentheses in Linux,
although they are not required in the language, as in: "sizeof info" after
"struct fileinfo info;" is declared).

So use a space after these keywords:
if, switch, case, for, do, while
but not with sizeof, typeof, alignof, or __attribute__.  E.g.,
s = sizeof(struct file);

and

Chapter 14: Allocating memory
[]
The preferred form for passing a size of a struct is the following:

p = kmalloc(sizeof(*p), ...);


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

[PATCH v3] ext4: fix hole punch failure when depth is greater than 0

[Ashish Sangwan]

Whether to continue removing extents or not is decided by the return value
of function ext4_ext_more_to_rm() which checks 2 conditions:
a) if there are no more indexes to process.
b) if the number of entries are decreased in the header of "depth -1".

In case of hole punch, if the last block to be removed is not part of the
last extent index than this index will not be deleted, hence the number of
valid entries in the extent header of "depth - 1" will remain as it is and
ext4_ext_more_to_rm will return 0 although the required blocks are not
yet removed.

This patch fixes the above mentioned problem as instead of removing the
extents from the end of file, it starts removing the blocks from the
particular extent from which removing blocks is actually required and
continue backward until done.

Signed-off-by: Ashish Sangwan 
Signed-off-by: Namjae Jeon 
Reviewed-by: Lukas Czerner 
---
 fs/ext4/extents.c |   46 +-
 1 file changed, 29 insertions(+), 17 deletions(-)

diff --git a/fs/ext4/extents.c b/fs/ext4/extents.c
index 91341ec..45ac45d 100644
--- a/fs/ext4/extents.c
+++ b/fs/ext4/extents.c
@@ -2570,10 +2570,10 @@ static int ext4_ext_remove_space(struct inode *inode, 
ext4_lblk_t start,
 {
struct super_block *sb = inode->i_sb;
int depth = ext_depth(inode);
-   struct ext4_ext_path *path;
+   struct ext4_ext_path *path = NULL;
ext4_fsblk_t partial_cluster = 0;
handle_t *handle;
-   int i, err;
+   int i = 0, err;
 
ext_debug("truncate since %u to %u\n", start, end);
 
@@ -2606,8 +2606,12 @@ again:
}
depth = ext_depth(inode);
ex = path[depth].p_ext;
-   if (!ex)
+   if (!ex) {
+   ext4_ext_drop_refs(path);
+   kfree(path);
+   path = NULL;
goto cont;
+   }
 
ee_block = le32_to_cpu(ex->ee_block);
 
@@ -2637,8 +2641,6 @@ again:
if (err < 0)
goto out;
}
-   ext4_ext_drop_refs(path);
-   kfree(path);
}
 cont:
 
@@ -2647,19 +2649,27 @@ cont:
 * after i_size and walking into the tree depth-wise.
 */
depth = ext_depth(inode);
-   path = kzalloc(sizeof(struct ext4_ext_path) * (depth + 1), GFP_NOFS);
-   if (path == NULL) {
-   ext4_journal_stop(handle);
-   return -ENOMEM;
-   }
-   path[0].p_depth = depth;
-   path[0].p_hdr = ext_inode_hdr(inode);
+   if (path) {
+   int k = i = depth;
+   while (--k > 0)
+   path[k].p_block =
+   le16_to_cpu(path[k].p_hdr->eh_entries)+1;
+   } else {
+   path = kzalloc(sizeof(struct ext4_ext_path) * (depth + 1),
+  GFP_NOFS);
+   if (path == NULL) {
+   ext4_journal_stop(handle);
+   return -ENOMEM;
+   }
+   path[0].p_depth = depth;
+   path[0].p_hdr = ext_inode_hdr(inode);
 
-   if (ext4_ext_check(inode, path[0].p_hdr, depth)) {
-   err = -EIO;
-   goto out;
+   if (ext4_ext_check(inode, path[0].p_hdr, depth)) {
+   err = -EIO;
+   goto out;
+   }
}
-   i = err = 0;
+   err = 0;
 
while (i >= 0 && err == 0) {
if (i == depth) {
@@ -2773,8 +2783,10 @@ cont:
 out:
ext4_ext_drop_refs(path);
kfree(path);
-   if (err == -EAGAIN)
+   if (err == -EAGAIN) {
+   path = NULL
goto again;
+   }
ext4_journal_stop(handle);
 
return err;
-- 
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/

Re: [PATCH v2] fail dentry revalidation after namespace change

[Andrew Morton]

On Mon, 09 Jul 2012 17:30:48 -0700 ebied...@xmission.com (Eric W. Biederman) 
wrote:

> Andrew Morton  writes:
> 
> >>  {
> >>struct sysfs_dirent *sd;
> >>int is_dir;
> >> +  int type;
> >>  
> >>if (nd->flags & LOOKUP_RCU)
> >>return -ECHILD;
> >> @@ -326,6 +327,13 @@ static int sysfs_dentry_revalidate(struct dentry 
> >> *dentry, struct nameidata *nd)
> >>if (strcmp(dentry->d_name.name, sd->s_name) != 0)
> >>goto out_bad;
> >>  
> >> +  /* The sysfs dirent has been moved to a different namespace */
> >> +  type = KOBJ_NS_TYPE_NONE;
> >> +  if (sd->s_parent)
> >> +  type = sysfs_ns_type(sd->s_parent);
> >> +  if (type && (sysfs_info(dentry->d_sb)->ns[type] != sd->s_ns))
> >
> > eww, the code is assuming that KOBJ_NS_TYPE_NONE has a value of zero. 
> > Don't do that; it smells bad.
> 
> Gag.  An incomplete change in idiom.
> 
> KOBJ_NS_TYPE_NONE is explicitly defined as 0 so that it can be used
> this way, and every where else in fs/sysfs/dir.c uses this idiom.

One man's idiom is another man's idiocy.

Seriously.  What sort of idea is that?  Create an enumerated type and
then just ignore it?

> Pray tell in what parallel universe is that monstrosity above more
> readable than the line it replaces?

Don't be silly, it is not a "monstrosity".  The code it is modifying
contains an unneeded test-and-branch.  It's a test and branch which the
compiler might be able to avoid.  If we can demonstrate that the
compiler does indeed optimise it, or if we can find a less monstrous
way of implementing it then fine.  Otherwise, efficiency wins.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] fail dentry revalidation after namespace change

[Eric W. Biederman]

Andrew Morton  writes:

>>  {
>>  struct sysfs_dirent *sd;
>>  int is_dir;
>> +int type;
>>  
>>  if (nd->flags & LOOKUP_RCU)
>>  return -ECHILD;
>> @@ -326,6 +327,13 @@ static int sysfs_dentry_revalidate(struct dentry 
>> *dentry, struct nameidata *nd)
>>  if (strcmp(dentry->d_name.name, sd->s_name) != 0)
>>  goto out_bad;
>>  
>> +/* The sysfs dirent has been moved to a different namespace */
>> +type = KOBJ_NS_TYPE_NONE;
>> +if (sd->s_parent)
>> +type = sysfs_ns_type(sd->s_parent);
>> +if (type && (sysfs_info(dentry->d_sb)->ns[type] != sd->s_ns))
>
> eww, the code is assuming that KOBJ_NS_TYPE_NONE has a value of zero. 
> Don't do that; it smells bad.

Gag.  An incomplete change in idiom.

KOBJ_NS_TYPE_NONE is explicitly defined as 0 so that it can be used
this way, and every where else in fs/sysfs/dir.c uses this idiom.

Furthermore your change below takes one line of readable code and turns
it into something inappropriate to talk about in polite company.

If you want the code to be perfect type should be defined as
"enum kobj_ns_type type" instead of "int kobj_ns_type".

Of course the truly perfect solution is to rework the sysfs
code in a manner similar to proc, with magic internal symlinks
and multiple parallel tress for the different namespaces.
For the users of sysfs semantically there would be no changes
but in the implementation there would many fewer special cases
for namespaces.   The only special case would be reduced to
the internal sysfs symlink that lookup would have to know
about.

> @@ -329,10 +329,12 @@ static int sysfs_dentry_revalidate(struc
>  
>   /* The sysfs dirent has been moved to a different namespace */
>   type = KOBJ_NS_TYPE_NONE;
> - if (sd->s_parent)
> + if (sd->s_parent) {
>   type = sysfs_ns_type(sd->s_parent);
> - if (type && (sysfs_info(dentry->d_sb)->ns[type] != sd->s_ns))
> - goto out_bad;
> + if (type != KOBJ_NS_TYPE_NONE &&
> + sysfs_info(dentry->d_sb)->ns[type] != sd->s_ns)
> + goto out_bad;
> + }

Pray tell in what parallel universe is that monstrosity above more
readable than the line it replaces?

Eric

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] mm: Warn about costly page allocation

[Minchan Kim]

Hi Andrew,

On Mon, Jul 09, 2012 at 05:08:56PM -0700, Andrew Morton wrote:
> On Tue, 10 Jul 2012 08:55:53 +0900
> Minchan Kim  wrote:
> 
> > ...
> >
> > --- a/mm/page_alloc.c
> > +++ b/mm/page_alloc.c
> > @@ -2276,6 +2276,29 @@ gfp_to_alloc_flags(gfp_t gfp_mask)
> > return alloc_flags;
> >  }
> >  
> > +#if defined(CONFIG_DEBUG_VM) && !defined(CONFIG_COMPACTION)
> > +static inline void check_page_alloc_costly_order(unsigned int order, gfp_t 
> > flags)
> > +{
> > +   if (likely(order <= PAGE_ALLOC_COSTLY_ORDER))
> > +   return;
> > +
> > +   if (!printk_ratelimited())
> > +   return;
> > +
> > +   pr_warn("%s: page allocation high-order stupidity: "
> > +   "order:%d, mode:0x%x\n", current->comm, order, flags);
> > +   pr_warn("Enable compaction if high-order allocations are "
> > +   "very few and rare.\n");
> > +   pr_warn("If you need regular high-order allocation, "
> > +   "compaction wouldn't help it.\n");
> > +   dump_stack();
> > +}
> > +#else
> > +static inline void check_page_alloc_costly_order(unsigned int order)
> > +{
> > +}
> > +#endif
> 
> Let's remember that plain old "inline" is ignored by the compiler.  If
> we really really want to inline something then we should use
> __always_inline.

I didn't know about that. Thanks for the pointing out.

> 
> And inlining this function would be a bad thing to do - it causes the
> outer function to have an increased cache footprint.  A good way to
> optimise this function is probably to move the unlikely stuff
> out-of-line:

Okay. will do.

> 
>   if (unlikely(order > PAGE_ALLOC_COSTLY_ORDER))
>   check_page_alloc_costly_order(...);
> 
> or
> 
> static noinline void __check_page_alloc_costly_order(...)
> {
> }
> 
> static __always_inline void check_page_alloc_costly_order(...)
> {
>   if (unlikely(order > PAGE_ALLOC_COSTLY_ORDER))
>   __check_page_alloc_costly_order(...);
> }
>   
> 
> Also, the displayed messages don't seem very, umm, professional.  Who
> was stupid - us or the kernel-configurer?  And "Enable
> CONFIG_COMPACTION" would be more specific (and hence helpful) than
> "Enable compaction").

Okay.

> 
> And how on earth is the user, or the person who is configuring kernels
> for customers to determine whether the kernel will be frequently
> performing higher-order allocations?
> 
> 
> So I dunno, this all looks like we have a kernel problem and we're
> throwing our problem onto hopelessly ill-equipped users of that kernel?

As you know, this patch isn't for solving regular high-order allocations.
As I wrote down, The problem is that we removed lumpy reclaim without any
notification for user who might have used it implicitly.
If such user disable compaction which is a replacement of lumpy reclaim,
their system might be broken in real practice while test is passing.
So, the goal is that let them know it in advance so that I expect they can
test it stronger than old.

Although they see the page allocation failure with compaction, it would
be very helpful reports. It means we need to make compaction more
aggressive about reclaiming pages.

> 
> --
> To unsubscribe, send a message with 'unsubscribe linux-mm' in
> the body to majord...@kvack.org.  For more info on Linux MM,
> see: http://www.linux-mm.org/ .
> Don't email: mailto:"d...@kvack.org;> em...@kvack.org 
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [ 35/48] dummy: fix rcu_sched self-detected stalls

[Ben Hutchings]

On Mon, 2012-07-09 at 16:49 -0700, David Miller wrote:
> From: Ben Hutchings 
> Date: Tue, 10 Jul 2012 00:47:06 +0100
> 
> > I built on x86_64...
> 
> As did I :-)
> 
> > But it's not an important bug in mainline (yet) so perhaps we can treat
> > it as only required in stable.
> 
> I think this is the best thing to do for now.

OK, done.

Ben.

-- 
Ben Hutchings
The generation of random numbers is too important to be left to chance.
- Robert Coveyou


signature.asc
Description: This is a digitally signed message part

[PATCH 2/4] net: calxedaxgmac: fix hang on rx refill

[Rob Herring]

From: Rob Herring 

Fix intermittent hangs in xgmac_rx_refill. If a ring buffer entry already
had an skb allocated, then xgmac_rx_refill would get stuck in a loop. This
can happen on a rx error when we just leave the skb allocated to the entry.

[ 7884.51] INFO: rcu_preempt detected stall on CPU 0 (t=727315 jiffies)
[ 7884.51] [] (unwind_backtrace+0x1/0x98) from [] 
(__rcu_pending+0x11b/0x2c4)
[ 7884.51] [] (__rcu_pending+0x11b/0x2c4) from [] 
(rcu_check_callbacks+0xed/0x1a8)
[ 7884.51] [] (rcu_check_callbacks+0xed/0x1a8) from [] 
(update_process_times+0x2b/0x48)
[ 7884.51] [] (update_process_times+0x2b/0x48) from [] 
(tick_sched_timer+0x51/0x94)
[ 7884.51] [] (tick_sched_timer+0x51/0x94) from [] 
(__run_hrtimer+0x4f/0x1e8)
[ 7884.51] [] (__run_hrtimer+0x4f/0x1e8) from [] 
(hrtimer_interrupt+0xd7/0x1e4)
[ 7884.51] [] (hrtimer_interrupt+0xd7/0x1e4) from [] 
(twd_handler+0x17/0x24)
[ 7884.51] [] (twd_handler+0x17/0x24) from [] 
(handle_percpu_devid_irq+0x59/0x114)
[ 7884.51] [] (handle_percpu_devid_irq+0x59/0x114) from 
[] (generic_handle_irq+0x17/0x2c)
[ 7884.51] [] (generic_handle_irq+0x17/0x2c) from [] 
(handle_IRQ+0x35/0x7c)
[ 7884.51] [] (handle_IRQ+0x35/0x7c) from [] 
(__irq_svc+0x33/0xb8)
[ 7884.51] [] (__irq_svc+0x33/0xb8) from [] 
(xgmac_rx_refill+0x3a/0x140)
[ 7884.51] [] (xgmac_rx_refill+0x3a/0x140) from [] 
(xgmac_poll+0x265/0x3bc)
[ 7884.51] [] (xgmac_poll+0x265/0x3bc) from [] 
(net_rx_action+0xc3/0x200)
[ 7884.51] [] (net_rx_action+0xc3/0x200) from [] 
(__do_softirq+0xa3/0x1bc)

Signed-off-by: Rob Herring 
---
 drivers/net/ethernet/calxeda/xgmac.c |   27 ---
 1 file changed, 12 insertions(+), 15 deletions(-)

diff --git a/drivers/net/ethernet/calxeda/xgmac.c 
b/drivers/net/ethernet/calxeda/xgmac.c
index c4fd2e3..3ca1d79 100644
--- a/drivers/net/ethernet/calxeda/xgmac.c
+++ b/drivers/net/ethernet/calxeda/xgmac.c
@@ -671,26 +671,23 @@ static void xgmac_rx_refill(struct xgmac_priv *priv)
 
p = priv->dma_rx + entry;
 
-   if (priv->rx_skbuff[entry] != NULL)
-   continue;
-
-   skb = __skb_dequeue(>rx_recycle);
-   if (skb == NULL)
-   skb = netdev_alloc_skb(priv->dev, priv->dma_buf_sz);
-   if (unlikely(skb == NULL))
-   break;
-
-   priv->rx_skbuff[entry] = skb;
-   paddr = dma_map_single(priv->device, skb->data,
-priv->dma_buf_sz, DMA_FROM_DEVICE);
-   desc_set_buf_addr(p, paddr, priv->dma_buf_sz);
+   if (priv->rx_skbuff[entry] == NULL) {
+   skb = __skb_dequeue(>rx_recycle);
+   if (skb == NULL)
+   skb = netdev_alloc_skb(priv->dev, 
priv->dma_buf_sz);
+   if (unlikely(skb == NULL))
+   break;
+
+   priv->rx_skbuff[entry] = skb;
+   paddr = dma_map_single(priv->device, skb->data,
+  priv->dma_buf_sz, 
DMA_FROM_DEVICE);
+   desc_set_buf_addr(p, paddr, priv->dma_buf_sz);
+   }
 
netdev_dbg(priv->dev, "rx ring: head %d, tail %d\n",
priv->rx_head, priv->rx_tail);
 
priv->rx_head = dma_ring_incr(priv->rx_head, DMA_RX_RING_SZ);
-   /* Ensure descriptor is in memory before handing to h/w */
-   wmb();
desc_set_rx_owner(p);
}
 }
-- 
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 3/4] net: calxedaxgmac: set outstanding AXI bus transactions to 8

[Rob Herring]

From: Rob Herring 

Increase the number of outstanding read and write AXI transactions from 1
to 8 for better performance.

Signed-off-by: Rob Herring 
---
 drivers/net/ethernet/calxeda/xgmac.c |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/net/ethernet/calxeda/xgmac.c 
b/drivers/net/ethernet/calxeda/xgmac.c
index 3ca1d79..abb8f40 100644
--- a/drivers/net/ethernet/calxeda/xgmac.c
+++ b/drivers/net/ethernet/calxeda/xgmac.c
@@ -970,7 +970,7 @@ static int xgmac_hw_init(struct net_device *dev)
writel(DMA_INTR_DEFAULT_MASK, ioaddr + XGMAC_DMA_INTR_ENA);
 
/* XGMAC requires AXI bus init. This is a 'magic number' for now */
-   writel(0x000100E, ioaddr + XGMAC_DMA_AXI_BUS);
+   writel(0x0077000E, ioaddr + XGMAC_DMA_AXI_BUS);
 
ctrl |= XGMAC_CONTROL_DDIC | XGMAC_CONTROL_JE | XGMAC_CONTROL_ACS |
XGMAC_CONTROL_CAR;
-- 
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 4/4] net: calxedaxgmac: enable rx cut-thru mode

[Rob Herring]

From: Rob Herring 

Enabling RX cut-thru mode yields better performance as received frames
start getting written to memory before a whole frame is received.

Signed-off-by: Rob Herring 
---
 drivers/net/ethernet/calxeda/xgmac.c |5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/drivers/net/ethernet/calxeda/xgmac.c 
b/drivers/net/ethernet/calxeda/xgmac.c
index abb8f40..2b4b4f5 100644
--- a/drivers/net/ethernet/calxeda/xgmac.c
+++ b/drivers/net/ethernet/calxeda/xgmac.c
@@ -264,7 +264,7 @@
 #define XGMAC_OMR_FEF  0x0080  /* Forward Error Frames */
 #define XGMAC_OMR_DT   0x0040  /* Drop TCP/IP csum Errors */
 #define XGMAC_OMR_RSF  0x0020  /* RX FIFO Store and Forward */
-#define XGMAC_OMR_RTC  0x0010  /* RX Threshhold Ctrl */
+#define XGMAC_OMR_RTC_256  0x0018  /* RX Threshhold Ctrl */
 #define XGMAC_OMR_RTC_MASK 0x0018  /* RX Threshhold Ctrl MASK */
 
 /* XGMAC HW Features Register */
@@ -982,7 +982,8 @@ static int xgmac_hw_init(struct net_device *dev)
writel(value, ioaddr + XGMAC_DMA_CONTROL);
 
/* Set the HW DMA mode and the COE */
-   writel(XGMAC_OMR_TSF | XGMAC_OMR_RSF | XGMAC_OMR_RFD | XGMAC_OMR_RFA,
+   writel(XGMAC_OMR_TSF | XGMAC_OMR_RFD | XGMAC_OMR_RFA |
+   XGMAC_OMR_RTC_256,
ioaddr + XGMAC_OMR);
 
/* Reset the MMC counters */
-- 
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/4] net: calxedaxgmac: fix net timeout recovery

[Rob Herring]

From: Rob Herring 

Fix net tx watchdog timeout recovery. The descriptor ring was reset,
but the DMA engine was not reset to the beginning of the ring.

Signed-off-by: Rob Herring 
---
 drivers/net/ethernet/calxeda/xgmac.c |1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/net/ethernet/calxeda/xgmac.c 
b/drivers/net/ethernet/calxeda/xgmac.c
index 11f667f..c4fd2e3 100644
--- a/drivers/net/ethernet/calxeda/xgmac.c
+++ b/drivers/net/ethernet/calxeda/xgmac.c
@@ -933,6 +933,7 @@ static void xgmac_tx_err(struct xgmac_priv *priv)
desc_init_tx_desc(priv->dma_tx, DMA_TX_RING_SZ);
priv->tx_tail = 0;
priv->tx_head = 0;
+   writel(priv->dma_tx_phy, priv->base + XGMAC_DMA_TX_BASE_ADDR);
writel(reg | DMA_CONTROL_ST, priv->base + XGMAC_DMA_CONTROL);
 
writel(DMA_STATUS_TU | DMA_STATUS_TPS | DMA_STATUS_NIS | DMA_STATUS_AIS,
-- 
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 0/4] Calxeda xgmac fixes and performance improvements

[Rob Herring]

From: Rob Herring 

A few fixes and performance improvements for the Calxeda xgmac driver for
3.6. It would be nice to get the 2 fixes into 3.5, but since it is a bit
late in the cycle they can wait.

Rob

Rob Herring (4):
  net: calxedaxgmac: fix net timeout recovery
  net: calxedaxgmac: fix hang on rx refill
  net: calxedaxgmac: set outstanding AXI bus transactions to 8
  net: calxedaxgmac: enable rx cut-thru mode

 drivers/net/ethernet/calxeda/xgmac.c |   35 +-
 1 file changed, 17 insertions(+), 18 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/

[PATCH 5/8] pstore/ram: Convert to write_buf callback

[Anton Vorontsov]

Don't use pstore.buf directly, instead convert the code to write_buf callback
which passes a pointer to a buffer as an argument.

Signed-off-by: Anton Vorontsov 
---
 fs/pstore/ram.c |   17 +
 1 file changed, 9 insertions(+), 8 deletions(-)

diff --git a/fs/pstore/ram.c b/fs/pstore/ram.c
index b39aebb..74f4111 100644
--- a/fs/pstore/ram.c
+++ b/fs/pstore/ram.c
@@ -170,11 +170,12 @@ static size_t ramoops_write_kmsg_hdr(struct 
persistent_ram_zone *prz)
return len;
 }
 
-static int ramoops_pstore_write(enum pstore_type_id type,
-   enum kmsg_dump_reason reason,
-   u64 *id,
-   unsigned int part,
-   size_t size, struct pstore_info *psi)
+
+static int ramoops_pstore_write_buf(enum pstore_type_id type,
+   enum kmsg_dump_reason reason,
+   u64 *id, unsigned int part,
+   const char *buf, size_t size,
+   struct pstore_info *psi)
 {
struct ramoops_context *cxt = psi->data;
struct persistent_ram_zone *prz = cxt->przs[cxt->dump_write_cnt];
@@ -183,7 +184,7 @@ static int ramoops_pstore_write(enum pstore_type_id type,
if (type == PSTORE_TYPE_CONSOLE) {
if (!cxt->cprz)
return -ENOMEM;
-   persistent_ram_write(cxt->cprz, cxt->pstore.buf, size);
+   persistent_ram_write(cxt->cprz, buf, size);
return 0;
}
 
@@ -212,7 +213,7 @@ static int ramoops_pstore_write(enum pstore_type_id type,
hlen = ramoops_write_kmsg_hdr(prz);
if (size + hlen > prz->buffer_size)
size = prz->buffer_size - hlen;
-   persistent_ram_write(prz, cxt->pstore.buf, size);
+   persistent_ram_write(prz, buf, size);
 
cxt->dump_write_cnt = (cxt->dump_write_cnt + 1) % cxt->max_dump_cnt;
 
@@ -250,7 +251,7 @@ static struct ramoops_context oops_cxt = {
.name   = "ramoops",
.open   = ramoops_pstore_open,
.read   = ramoops_pstore_read,
-   .write  = ramoops_pstore_write,
+   .write_buf  = ramoops_pstore_write_buf,
.erase  = ramoops_pstore_erase,
},
 };
-- 
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 4/8] tracing/function: Introduce persistent trace option

[Anton Vorontsov]

This patch introduces 'func_ptrace' option, now available in
/sys/kernel/debug/tracing/options when function tracer
is selected.

The patch also adds some tiny code that calls back to pstore
to record the trace. The callback is no-op when PSTORE=n.

Signed-off-by: Anton Vorontsov 
---
 kernel/trace/trace_functions.c |   25 -
 1 file changed, 20 insertions(+), 5 deletions(-)

diff --git a/kernel/trace/trace_functions.c b/kernel/trace/trace_functions.c
index c7b0c6a..13770ab 100644
--- a/kernel/trace/trace_functions.c
+++ b/kernel/trace/trace_functions.c
@@ -13,6 +13,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 
 #include "trace.h"
@@ -74,6 +75,14 @@ function_trace_call_preempt_only(unsigned long ip, unsigned 
long parent_ip)
preempt_enable_notrace();
 }
 
+/* Our two options */
+enum {
+   TRACE_FUNC_OPT_STACK= 0x1,
+   TRACE_FUNC_OPT_PSTORE   = 0x2,
+};
+
+static struct tracer_flags func_flags;
+
 static void
 function_trace_call(unsigned long ip, unsigned long parent_ip)
 {
@@ -97,6 +106,12 @@ function_trace_call(unsigned long ip, unsigned long 
parent_ip)
disabled = atomic_inc_return(>disabled);
 
if (likely(disabled == 1)) {
+   /*
+* So far tracing doesn't support multiple buffers, so
+* we make an explicit call for now.
+*/
+   if (unlikely(func_flags.val & TRACE_FUNC_OPT_PSTORE))
+   pstore_ftrace_call(ip, parent_ip);
pc = preempt_count();
trace_function(tr, ip, parent_ip, flags, pc);
}
@@ -158,15 +173,13 @@ static struct ftrace_ops trace_stack_ops __read_mostly =
.flags = FTRACE_OPS_FL_GLOBAL,
 };
 
-/* Our two options */
-enum {
-   TRACE_FUNC_OPT_STACK = 0x1,
-};
-
 static struct tracer_opt func_opts[] = {
 #ifdef CONFIG_STACKTRACE
{ TRACER_OPT(func_stack_trace, TRACE_FUNC_OPT_STACK) },
 #endif
+#ifdef CONFIG_PSTORE_FTRACE
+   { TRACER_OPT(func_pstore, TRACE_FUNC_OPT_PSTORE) },
+#endif
{ } /* Always set a last empty entry */
 };
 
@@ -218,6 +231,8 @@ static int func_set_flag(u32 old_flags, u32 bit, int set)
}
 
return 0;
+   } else if (bit == TRACE_FUNC_OPT_PSTORE) {
+   return 0;
}
 
return -EINVAL;
-- 
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/

Re: [PATCH 1/2] acpi : cpu hot-remove returns error number when cpu_down() fails

[Yasuaki Ishimatsu]

Hi Srivatsa,

2012/07/09 20:25, Srivatsa S. Bhat wrote:
> On 07/09/2012 08:01 AM, Yasuaki Ishimatsu wrote:
>> Hi Srivatsa,
>>
>> Thank you for your reviewing.
>>
>> 2012/07/06 18:51, Srivatsa S. Bhat wrote:
>>> On 07/06/2012 08:46 AM, Yasuaki Ishimatsu wrote:
 Even if cpu_down() fails, acpi_processor_remove() continues to remove the 
 cpu.
>>>
>>> Ouch!
>>>
 But in this case, it should return error number since some process may run 
 on
 the cpu. If the cpu has a running process and the cpu is turned the power 
 off,
 the system cannot work well.

 Signed-off-by: Yasuaki Ishimatsu 

 ---
drivers/acpi/processor_driver.c |   18 --
1 file changed, 12 insertions(+), 6 deletions(-)

 Index: linux-3.5-rc4/drivers/acpi/processor_driver.c
 ===
 --- linux-3.5-rc4.orig/drivers/acpi/processor_driver.c 2012-06-25 
 04:53:04.0 +0900
 +++ linux-3.5-rc4/drivers/acpi/processor_driver.c  2012-07-05 
 21:02:58.711285382 +0900
 @@ -610,7 +610,7 @@ err_free_pr:
static int acpi_processor_remove(struct acpi_device *device, int type)
{
struct acpi_processor *pr = NULL;
 -
 +  int ret;

if (!device || !acpi_driver_data(device))
return -EINVAL;
 @@ -621,8 +621,9 @@ static int acpi_processor_remove(struct
goto free;

if (type == ACPI_BUS_REMOVAL_EJECT) {
 -  if (acpi_processor_handle_eject(pr))
 -  return -EINVAL;
 +  ret = acpi_processor_handle_eject(pr);
 +  if (ret)
 +  return ret;
}

acpi_processor_power_exit(pr, device);
 @@ -841,12 +842,17 @@ static acpi_status acpi_processor_hotadd

static int acpi_processor_handle_eject(struct acpi_processor *pr)
{
 -  if (cpu_online(pr->id))
 -  cpu_down(pr->id);
 +  int ret;
 +
 +  if (cpu_online(pr->id)) {
 +  ret = cpu_down(pr->id);
 +  if (ret)
 +  return ret;
 +  }

>>>
>>> Strictly speaking, this is not thorough enough. What prevents someone
>>> from onlining that same cpu again, at this point?
>>> So, IMHO, you need to wrap the contents of this function inside a
>>> get_online_cpus()/put_online_cpus() block, to prevent anyone else
>>> from messing with CPU hotplug at the same time.
>>
>> If I understand your comment by mistake, please let me know.
>> If the contents is wrapped a inside get_online_cpus()/put_online_cpus() block
>> as below, cpu_down() will stop since cpu_down() calls cpu_hotplug_begin() and
>> cpu_hotplug_begin() waits for cpu_hotplug.refcount to become 0.
>>
> 
> You are right. Sorry, I overlooked that.
> 
>> +get_online_cpus()
>> +if (cpu_online(pr->id)) {
>> +ret = cpu_down(pr->id);
>> +if (ret)
>> +return ret;
>> +}
>> +put_online_cpus()
>>
>> I think following patch can prevent it correctly. How about the patch?
>>
>> ---
>>   drivers/acpi/processor_driver.c |   12 
>>   kernel/cpu.c|8 +---
>>   2 files changed, 17 insertions(+), 3 deletions(-)
>>
>> Index: linux-3.5-rc4/drivers/acpi/processor_driver.c
>> ===
>> --- linux-3.5-rc4.orig/drivers/acpi/processor_driver.c   2012-07-09 
>> 09:59:01.280211202 +0900
>> +++ linux-3.5-rc4/drivers/acpi/processor_driver.c2012-07-09 
>> 11:05:34.559859236 +0900
>> @@ -844,14 +844,26 @@ static int acpi_processor_handle_eject(s
>>   {
>>  int ret;
>>
>> +retry:
>>  if (cpu_online(pr->id)) {
>>  ret = cpu_down(pr->id);
>>  if (ret)
>>  return ret;
>>  }
>>
>> +get_online_cpus();
>> +/*
>> + * Someone might online the cpu again at this point. So we check that
>> + * cpu has been onlined or not. If cpu is online, we try to offline
>> + * the cpu again.
>> + */
>> +if (cpu_online(pr->id)) {
> 
> How about this:
>   if (unlikely(cpu_online(pr->id)) {
> since the probability of this happening is quite small...

Thanks. I'll update it.

>> +put_online_cpus();
>> +goto retry;
>> +}
>>  arch_unregister_cpu(pr->id);
>>  acpi_unmap_lsapic(pr->id);
>> +put_online_cpus();
>>  return ret;
>>   }
> 
> This retry logic doesn't look elegant, but I don't see any better method :-(
> 
>>   #else
>> Index: linux-3.5-rc4/kernel/cpu.c
>> ===
>> --- linux-3.5-rc4.orig/kernel/cpu.c  2012-07-09 09:59:01.280211202 +0900
>> +++ linux-3.5-rc4/kernel/cpu.c   2012-07-09 09:59:02.903190965 +0900
>> @@ -343,11 +343,13 @@ static int __cpuinit _cpu_up(unsigned in
>>  

[PATCH 7/8] pstore/ram: Make tracing log versioned

[Anton Vorontsov]

Decoding the binary trace w/ a different kernel might be troublesome
since we convert addresses to symbols. For kernels with minimal changes,
the mappings would probably match, but it's not guaranteed at all.
(But still we could convert the addresses by hand, since we do print
raw addresses.)

If we use modules, the symbols could be loaded at different addresses
from the previously booted kernel, and so this would also fail, but
there's nothing we can do about it.

Also, the binary data format that pstore/ram is using in its ringbuffer
may change between the kernels, so here we too must ensure that we're
running the same kernel.

So, there are two questions really:

1. How to compute the unique kernel tag;
2. Where to store it.

In this patch we're just passing linux_banner through CRC32. This
way we are protecting from the kernel version mismatch, making sure
that we're running the same image. We could also add CRC of a symbol
table (as suggested by Tony Luck), but for now let's not be that
strict.

And as for storing, we are using a small trick here. Instead of
allocating a dedicated buffer for the tag (i.e. another prz), or
hacking ram_core routines to "reserve" some control data in the
buffer, we are just encoding the tag into the buffer signature
(and XOR'ing it with the actual signature value, so that buffers
not needing a tag can just pass zero, which will result into the
plain old PRZ signature).

Suggested-by: Steven Rostedt 
Suggested-by: Tony Luck 
Suggested-by: Colin Cross 
Signed-off-by: Anton Vorontsov 
---
 fs/pstore/Kconfig  |1 +
 fs/pstore/ram.c|   13 -
 fs/pstore/ram_core.c   |   12 +++-
 include/linux/pstore_ram.h |2 +-
 4 files changed, 17 insertions(+), 11 deletions(-)

diff --git a/fs/pstore/Kconfig b/fs/pstore/Kconfig
index d39bb5c..a123754 100644
--- a/fs/pstore/Kconfig
+++ b/fs/pstore/Kconfig
@@ -36,6 +36,7 @@ config PSTORE_RAM
depends on PSTORE
depends on HAS_IOMEM
depends on HAVE_MEMBLOCK
+   select CRC32
select REED_SOLOMON
select REED_SOLOMON_ENC8
select REED_SOLOMON_DEC8
diff --git a/fs/pstore/ram.c b/fs/pstore/ram.c
index 1dd108e..a7610a1 100644
--- a/fs/pstore/ram.c
+++ b/fs/pstore/ram.c
@@ -31,6 +31,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 
 #define RAMOOPS_KERNMSG_HDR ""
@@ -309,7 +310,7 @@ static int ramoops_init_przs(struct device *dev, struct 
ramoops_context *cxt,
for (i = 0; i < cxt->max_dump_cnt; i++) {
size_t sz = cxt->record_size;
 
-   cxt->przs[i] = persistent_ram_new(*paddr, sz, cxt->ecc_size);
+   cxt->przs[i] = persistent_ram_new(*paddr, sz, 0, cxt->ecc_size);
if (IS_ERR(cxt->przs[i])) {
err = PTR_ERR(cxt->przs[i]);
dev_err(dev, "failed to request mem region 
(0x%zx@0x%llx): %d\n",
@@ -327,7 +328,7 @@ fail_prz:
 
 static int ramoops_init_prz(struct device *dev, struct ramoops_context *cxt,
struct persistent_ram_zone **prz,
-   phys_addr_t *paddr, size_t sz)
+   phys_addr_t *paddr, size_t sz, u32 sig)
 {
if (!sz)
return 0;
@@ -335,7 +336,7 @@ static int ramoops_init_prz(struct device *dev, struct 
ramoops_context *cxt,
if (*paddr + sz > *paddr + cxt->size)
return -ENOMEM;
 
-   *prz = persistent_ram_new(*paddr, sz, cxt->ecc_size);
+   *prz = persistent_ram_new(*paddr, sz, sig, cxt->ecc_size);
if (IS_ERR(*prz)) {
int err = PTR_ERR(*prz);
 
@@ -394,11 +395,13 @@ static int __devinit ramoops_probe(struct platform_device 
*pdev)
if (err)
goto fail_out;
 
-   err = ramoops_init_prz(dev, cxt, >cprz, , cxt->console_size);
+   err = ramoops_init_prz(dev, cxt, >cprz, ,
+  cxt->console_size, 0);
if (err)
goto fail_init_cprz;
 
-   err = ramoops_init_prz(dev, cxt, >fprz, , cxt->ftrace_size);
+   err = ramoops_init_prz(dev, cxt, >fprz, , cxt->ftrace_size,
+  crc32_le(0, linux_banner, strlen(linux_banner)));
if (err)
goto fail_init_fprz;
 
diff --git a/fs/pstore/ram_core.c b/fs/pstore/ram_core.c
index 4dabbb8..eecd2a8 100644
--- a/fs/pstore/ram_core.c
+++ b/fs/pstore/ram_core.c
@@ -391,7 +391,7 @@ static int persistent_ram_buffer_map(phys_addr_t start, 
phys_addr_t size,
 }
 
 static int __devinit persistent_ram_post_init(struct persistent_ram_zone *prz,
- int ecc_size)
+ u32 sig, int ecc_size)
 {
int ret;
 
@@ -399,7 +399,9 @@ static int __devinit persistent_ram_post_init(struct 
persistent_ram_zone *prz,
if (ret)
return ret;
 
-   if (prz->buffer->sig == PERSISTENT_RAM_SIG) {
+   sig ^= PERSISTENT_RAM_SIG;
+
+   

[PATCH 8/8] tracing/function: Convert func_set_flag() to a switch statement

[Anton Vorontsov]

Since the function accepts just one bit, we can use the switch
construction instead of if/else if/...

Just a cosmetic change, there should be no functional changes.

Suggested-by: Steven Rostedt 
Signed-off-by: Anton Vorontsov 
---
 kernel/trace/trace_functions.c |   15 +--
 1 file changed, 9 insertions(+), 6 deletions(-)

diff --git a/kernel/trace/trace_functions.c b/kernel/trace/trace_functions.c
index 13770ab..a426f41 100644
--- a/kernel/trace/trace_functions.c
+++ b/kernel/trace/trace_functions.c
@@ -217,10 +217,11 @@ static void tracing_stop_function_trace(void)
 
 static int func_set_flag(u32 old_flags, u32 bit, int set)
 {
-   if (bit == TRACE_FUNC_OPT_STACK) {
+   switch (bit) {
+   case TRACE_FUNC_OPT_STACK:
/* do nothing if already set */
if (!!set == !!(func_flags.val & TRACE_FUNC_OPT_STACK))
-   return 0;
+   break;
 
if (set) {
unregister_ftrace_function(_ops);
@@ -230,12 +231,14 @@ static int func_set_flag(u32 old_flags, u32 bit, int set)
register_ftrace_function(_ops);
}
 
-   return 0;
-   } else if (bit == TRACE_FUNC_OPT_PSTORE) {
-   return 0;
+   break;
+   case TRACE_FUNC_OPT_PSTORE:
+   break;
+   default:
+   return -EINVAL;
}
 
-   return -EINVAL;
+   return 0;
 }
 
 static struct tracer function_trace __read_mostly =
-- 
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 6/8] pstore/ram: Add ftrace messages handling

[Anton Vorontsov]

The ftrace log size is configurable via ramoops.ftrace_size
module option, and the log itself is available via
/ftrace-ramoops file.

Signed-off-by: Anton Vorontsov 
---
 Documentation/ramoops.txt  |   25 +
 fs/pstore/ram.c|   37 +
 include/linux/pstore_ram.h |1 +
 3 files changed, 59 insertions(+), 4 deletions(-)

diff --git a/Documentation/ramoops.txt b/Documentation/ramoops.txt
index 59a74a8..197ad59 100644
--- a/Documentation/ramoops.txt
+++ b/Documentation/ramoops.txt
@@ -94,3 +94,28 @@ timestamp and a new line. The dump then continues with the 
actual data.
 The dump data can be read from the pstore filesystem. The format for these
 files is "dmesg-ramoops-N", where N is the record number in memory. To delete
 a stored record from RAM, simply unlink the respective pstore file.
+
+5. Persistent function tracing
+
+Persistent function tracing might be useful for debugging software or hardware
+related hangs. The functions call chain log is stored in a "ftrace-ramoops"
+file. Here is an example of usage:
+
+ # mount -t debugfs debugfs /sys/kernel/debug/
+ # cd /sys/kernel/debug/tracing
+ # echo function > current_tracer
+ # echo 1 > options/func_pstore
+ # reboot -f
+ [...]
+ # mount -t pstore pstore /mnt/
+ # tail /mnt/ftrace-ramoops
+ 0 8101ea64  8101bcda  native_apic_mem_read <- 
disconnect_bsp_APIC+0x6a/0xc0
+ 0 8101ea44  8101bcf6  native_apic_mem_write <- 
disconnect_bsp_APIC+0x86/0xc0
+ 0 81020084  8101a4b5  hpet_disable <- 
native_machine_shutdown+0x75/0x90
+ 0 81005f94  8101a4bb  iommu_shutdown_noop <- 
native_machine_shutdown+0x7b/0x90
+ 0 8101a6a1  8101a437  native_machine_emergency_restart <- 
native_machine_restart+0x37/0x40
+ 0 811f9876  8101a73a  acpi_reboot <- 
native_machine_emergency_restart+0xaa/0x1e0
+ 0 8101a514  8101a772  mach_reboot_fixups <- 
native_machine_emergency_restart+0xe2/0x1e0
+ 0 811d9c54  8101a7a0  __const_udelay <- 
native_machine_emergency_restart+0x110/0x1e0
+ 0 811d9c34  811d9c80  __delay <- __const_udelay+0x30/0x40
+ 0 811d9d14  811d9c3f  delay_tsc <- __delay+0xf/0x20
diff --git a/fs/pstore/ram.c b/fs/pstore/ram.c
index 74f4111..1dd108e 100644
--- a/fs/pstore/ram.c
+++ b/fs/pstore/ram.c
@@ -45,6 +45,10 @@ static ulong ramoops_console_size = MIN_MEM_SIZE;
 module_param_named(console_size, ramoops_console_size, ulong, 0400);
 MODULE_PARM_DESC(console_size, "size of kernel console log");
 
+static ulong ramoops_ftrace_size = MIN_MEM_SIZE;
+module_param_named(ftrace_size, ramoops_ftrace_size, ulong, 0400);
+MODULE_PARM_DESC(ftrace_size, "size of ftrace log");
+
 static ulong mem_address;
 module_param(mem_address, ulong, 0400);
 MODULE_PARM_DESC(mem_address,
@@ -70,16 +74,19 @@ MODULE_PARM_DESC(ramoops_ecc,
 struct ramoops_context {
struct persistent_ram_zone **przs;
struct persistent_ram_zone *cprz;
+   struct persistent_ram_zone *fprz;
phys_addr_t phys_addr;
unsigned long size;
size_t record_size;
size_t console_size;
+   size_t ftrace_size;
int dump_oops;
int ecc_size;
unsigned int max_dump_cnt;
unsigned int dump_write_cnt;
unsigned int dump_read_cnt;
unsigned int console_read_cnt;
+   unsigned int ftrace_read_cnt;
struct pstore_info pstore;
 };
 
@@ -138,6 +145,9 @@ static ssize_t ramoops_pstore_read(u64 *id, enum 
pstore_type_id *type,
prz = ramoops_get_next_prz(>cprz, >console_read_cnt,
   1, id, type, PSTORE_TYPE_CONSOLE, 0);
if (!prz)
+   prz = ramoops_get_next_prz(>fprz, >ftrace_read_cnt,
+  1, id, type, PSTORE_TYPE_FTRACE, 0);
+   if (!prz)
return 0;
 
/* TODO(kees): Bogus time for the moment. */
@@ -186,6 +196,11 @@ static int ramoops_pstore_write_buf(enum pstore_type_id 
type,
return -ENOMEM;
persistent_ram_write(cxt->cprz, buf, size);
return 0;
+   } else if (type == PSTORE_TYPE_FTRACE) {
+   if (!cxt->fprz)
+   return -ENOMEM;
+   persistent_ram_write(cxt->fprz, buf, size);
+   return 0;
}
 
if (type != PSTORE_TYPE_DMESG)
@@ -235,6 +250,9 @@ static int ramoops_pstore_erase(enum pstore_type_id type, 
u64 id,
case PSTORE_TYPE_CONSOLE:
prz = cxt->cprz;
break;
+   case PSTORE_TYPE_FTRACE:
+   prz = cxt->fprz;
+   break;
default:
return -EINVAL;
}
@@ -348,7 +366,8 @@ static int __devinit ramoops_probe(struct platform_device 
*pdev)
if (cxt->max_dump_cnt)
goto fail_out;
 
-   if (!pdata->mem_size || 

[PATCH 3/8] pstore: Add persistent function tracing

[Anton Vorontsov]

With this support kernel can save function call chain log into a
persistent ram buffer that can be decoded and dumped after reboot
through pstore filesystem. It can be used to determine what function
was last called before a reset or panic.

We store the log in a binary format and then decode it at read time.

p.s.
Mostly the code comes from trace_persistent.c driver found in the
Android git tree, written by Colin Cross 
(according to sign-off history). I reworked the driver a little bit,
and ported it to pstore.

Signed-off-by: Anton Vorontsov 
---
 fs/pstore/Kconfig  |   12 ++
 fs/pstore/Makefile |1 +
 fs/pstore/ftrace.c |   35 +++
 fs/pstore/inode.c  |  111 ++--
 fs/pstore/internal.h   |   43 +++
 fs/pstore/platform.c   |2 +-
 include/linux/pstore.h |9 
 7 files changed, 208 insertions(+), 5 deletions(-)
 create mode 100644 fs/pstore/ftrace.c

diff --git a/fs/pstore/Kconfig b/fs/pstore/Kconfig
index d044de6..d39bb5c 100644
--- a/fs/pstore/Kconfig
+++ b/fs/pstore/Kconfig
@@ -19,6 +19,18 @@ config PSTORE_CONSOLE
  When the option is enabled, pstore will log all kernel
  messages, even if no oops or panic happened.
 
+config PSTORE_FTRACE
+   bool "Persistent function tracer"
+   depends on PSTORE
+   depends on FUNCTION_TRACER
+   help
+ With this option kernel traces function calls into a persistent
+ ram buffer that can be decoded and dumped after reboot through
+ pstore filesystem. It can be used to determine what function
+ was last called before a reset or panic.
+
+ If unsure, say N.
+
 config PSTORE_RAM
tristate "Log panic/oops to a RAM buffer"
depends on PSTORE
diff --git a/fs/pstore/Makefile b/fs/pstore/Makefile
index 278a44e..4c9095c 100644
--- a/fs/pstore/Makefile
+++ b/fs/pstore/Makefile
@@ -5,6 +5,7 @@
 obj-y += pstore.o
 
 pstore-objs += inode.o platform.o
+obj-$(CONFIG_PSTORE_FTRACE)+= ftrace.o
 
 ramoops-objs += ram.o ram_core.o
 obj-$(CONFIG_PSTORE_RAM)   += ramoops.o
diff --git a/fs/pstore/ftrace.c b/fs/pstore/ftrace.c
new file mode 100644
index 000..a130d48
--- /dev/null
+++ b/fs/pstore/ftrace.c
@@ -0,0 +1,35 @@
+/*
+ * Copyright 2012  Google, Inc.
+ *
+ * This software is licensed under the terms of the GNU General Public
+ * License version 2, as published by the Free Software Foundation, and
+ * may be copied, distributed, and modified under those terms.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include "internal.h"
+
+void notrace pstore_ftrace_call(unsigned long ip, unsigned long parent_ip)
+{
+   struct pstore_ftrace_record rec = {};
+
+   if (unlikely(oops_in_progress))
+   return;
+
+   rec.ip = ip;
+   rec.parent_ip = parent_ip;
+   pstore_ftrace_encode_cpu(, raw_smp_processor_id());
+   psinfo->write_buf(PSTORE_TYPE_FTRACE, 0, NULL, 0, (void *),
+ sizeof(rec), psinfo);
+}
diff --git a/fs/pstore/inode.c b/fs/pstore/inode.c
index 45bff54..4ab572e 100644
--- a/fs/pstore/inode.c
+++ b/fs/pstore/inode.c
@@ -27,6 +27,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -52,18 +53,117 @@ struct pstore_private {
chardata[];
 };
 
+struct pstore_ftrace_seq_data {
+   const void *ptr;
+   size_t off;
+   size_t size;
+};
+
+#define REC_SIZE sizeof(struct pstore_ftrace_record)
+
+static void *pstore_ftrace_seq_start(struct seq_file *s, loff_t *pos)
+{
+   struct pstore_private *ps = s->private;
+   struct pstore_ftrace_seq_data *data;
+
+   data = kzalloc(sizeof(*data), GFP_KERNEL);
+   if (!data)
+   return NULL;
+
+   data->off = ps->size % REC_SIZE;
+   data->off += *pos * REC_SIZE;
+   if (data->off + REC_SIZE > ps->size) {
+   kfree(data);
+   return NULL;
+   }
+
+   return data;
+
+}
+
+static void pstore_ftrace_seq_stop(struct seq_file *s, void *v)
+{
+   kfree(v);
+}
+
+static void *pstore_ftrace_seq_next(struct seq_file *s, void *v, loff_t *pos)
+{
+   struct pstore_private *ps = s->private;
+   struct pstore_ftrace_seq_data *data = v;
+
+   data->off += REC_SIZE;
+   if (data->off + REC_SIZE > ps->size)
+   return NULL;
+
+   (*pos)++;
+   return data;
+}
+
+static int pstore_ftrace_seq_show(struct seq_file *s, void *v)
+{
+   struct pstore_private *ps = s->private;
+   struct pstore_ftrace_seq_data *data = v;
+   struct pstore_ftrace_record *rec = (void *)(ps->data + data->off);
+
+   seq_printf(s, "%d %08lx  %08lx  %pf <- %pF\n",
+

[PATCH 2/8] pstore: Introduce write_buf backend callback

[Anton Vorontsov]

For function tracing we need to stop using pstore.buf directly, since
in a tracing callback we can't use spinlocks, and thus we can't safely
use the global buffer.

With write_buf callback, backends no longer need to access pstore.buf
directly, and thus we can pass any buffers (e.g. allocated on stack).

Signed-off-by: Anton Vorontsov 
---
 fs/pstore/platform.c   |   10 ++
 include/linux/pstore.h |4 
 2 files changed, 14 insertions(+)

diff --git a/fs/pstore/platform.c b/fs/pstore/platform.c
index 6b3ff04..ef5ca8a 100644
--- a/fs/pstore/platform.c
+++ b/fs/pstore/platform.c
@@ -188,6 +188,14 @@ static void pstore_register_console(void)
 static void pstore_register_console(void) {}
 #endif
 
+static int pstore_write_compat(enum pstore_type_id type,
+  enum kmsg_dump_reason reason,
+  u64 *id, unsigned int part,
+  size_t size, struct pstore_info *psi)
+{
+   return psi->write_buf(type, reason, id, part, psinfo->buf, size, psi);
+}
+
 /*
  * platform specific persistent storage driver registers with
  * us here. If pstore is already mounted, call the platform
@@ -212,6 +220,8 @@ int pstore_register(struct pstore_info *psi)
return -EINVAL;
}
 
+   if (!psi->write)
+   psi->write = pstore_write_compat;
psinfo = psi;
mutex_init(>read_mutex);
spin_unlock(_lock);
diff --git a/include/linux/pstore.h b/include/linux/pstore.h
index 1bd014b..b107484 100644
--- a/include/linux/pstore.h
+++ b/include/linux/pstore.h
@@ -48,6 +48,10 @@ struct pstore_info {
int (*write)(enum pstore_type_id type,
enum kmsg_dump_reason reason, u64 *id,
unsigned int part, size_t size, struct pstore_info 
*psi);
+   int (*write_buf)(enum pstore_type_id type,
+   enum kmsg_dump_reason reason, u64 *id,
+   unsigned int part, const char *buf, size_t size,
+   struct pstore_info *psi);
int (*erase)(enum pstore_type_id type, u64 id,
struct pstore_info *psi);
void*data;
-- 
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 1/8] tracing: Fix initialization failure path in tracing_set_tracer()

[Anton Vorontsov]

If tracer->init() fails, current code will leave current_tracer pointing
to an unusable tracer, which at best makes 'current_tracer' report
inaccurate value.

Fix the issue by pointing current_tracer to nop tracer, and only update
current_tracer with the new one after all the initialization succeeds.

Signed-off-by: Anton Vorontsov 
Acked-by: Steven Rostedt 
---
 kernel/trace/trace.c |7 ---
 1 file changed, 4 insertions(+), 3 deletions(-)

diff --git a/kernel/trace/trace.c b/kernel/trace/trace.c
index 814ff30..954f7d7 100644
--- a/kernel/trace/trace.c
+++ b/kernel/trace/trace.c
@@ -3183,10 +3183,10 @@ static int tracing_set_tracer(const char *buf)
}
destroy_trace_option_files(topts);
 
-   current_trace = t;
+   current_trace = _trace;
 
-   topts = create_trace_option_files(current_trace);
-   if (current_trace->use_max_tr) {
+   topts = create_trace_option_files(t);
+   if (t->use_max_tr) {
int cpu;
/* we need to make per cpu buffer sizes equivalent */
for_each_tracing_cpu(cpu) {
@@ -3206,6 +3206,7 @@ static int tracing_set_tracer(const char *buf)
goto out;
}
 
+   current_trace = t;
trace_branch_enable(tr);
  out:
mutex_unlock(_types_lock);
-- 
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/

Re: [PATCH: 1/1] ACPI: make evaluation of thermal trip points before temperature or vice versa dependant on new "temp_b4_trip" module parameter to support older AMD x86_64s

[Rusty Russell]

On Mon, 9 Jul 2012 19:16:24 +0100, Jason Vas Dias  
wrote:
> Thanks Rusty - sorry I didn't see your email until now - revised patch
> addressing your comments attached -
> BTW,  sorry about the word wrap on the initial posting - should I
> attach a '.patch' file or inline ?  Trying both .

The inline one was wrapped.

> +static int thermal_temp_b4_trip(const struct dmi_system_id *d) {
> +
> +   printk(KERN_NOTICE "ACPI: %s detected: : "
> +   "getting temperature before trip point
> initialisation\n", d->ident);
> +   temp_b4_trip = TRUE;
> +   return 0;
> +}

TRUE?  true is standard with stdbool.h.

The patch itself looks reasonable, but it's not my area: I just spotted
the module_param() abuse :)

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

[PATCH v4 0/8] Function tracing support for pstore

[Anton Vorontsov]

Hi all,

In v4:
- A few cosmetic changes in func_set_flag(), as suggested by Steven
  Rostedt. Firstly, in the patch that adds pstore option, I use
  'else if' for the new bit (it keeps changes minimal), but then there
  is a new separate patch (the last in the series) that converts the
  whole thing into a switch construction.

In v3:
- Make traces versioned, as suggested by Steven, Tony and Colin. (The
  version tag is stored in the PRZ signature, see the last patch for
  the implementation details).
- Add Steven's Ack on the first patch.

In v2:
- Do not introduce a separate 'persistent' tracer, but introduce an
  option to the existing 'function' tracer.

Rationale for this patch set:

With this support kernel can save functions call chain log into a
persistent ram buffer that can be decoded and dumped after reboot
through pstore filesystem. It can be used to determine what function
was last called before a hang or an unexpected reset (caused by, for
example, a buggy driver that abuses HW).

Here's a "nano howto", to get the idea:

 # mount -t debugfs debugfs /sys/kernel/debug/
 # cd /sys/kernel/debug/tracing
 # echo function > current_tracer
 # echo 1 > options/func_pstore
 # reboot -f
 [...]
 # mount -t pstore pstore /mnt/
 # tail /mnt/ftrace-ramoops
 0 8101ea64  8101bcda  native_apic_mem_read <- 
disconnect_bsp_APIC+0x6a/0xc0
 0 8101ea44  8101bcf6  native_apic_mem_write <- 
disconnect_bsp_APIC+0x86/0xc0
 0 81020084  8101a4b5  hpet_disable <- 
native_machine_shutdown+0x75/0x90
 0 81005f94  8101a4bb  iommu_shutdown_noop <- 
native_machine_shutdown+0x7b/0x90
 0 8101a6a1  8101a437  native_machine_emergency_restart <- 
native_machine_restart+0x37/0x40
 0 811f9876  8101a73a  acpi_reboot <- 
native_machine_emergency_restart+0xaa/0x1e0
 0 8101a514  8101a772  mach_reboot_fixups <- 
native_machine_emergency_restart+0xe2/0x1e0
 0 811d9c54  8101a7a0  __const_udelay <- 
native_machine_emergency_restart+0x110/0x1e0
 0 811d9c34  811d9c80  __delay <- __const_udelay+0x30/0x40
 0 811d9d14  811d9c3f  delay_tsc <- __delay+0xf/0x20

Mostly the code comes from trace_persistent.c driver found in the
Android git tree, written by Colin Cross 
(according to sign-off history). I reworked the driver a little bit,
and ported it to pstore subsystem.

---
 Documentation/ramoops.txt  |   25 +
 fs/pstore/Kconfig  |   13 +
 fs/pstore/Makefile |1 +
 fs/pstore/ftrace.c |   35 +
 fs/pstore/inode.c  |  111 ++--
 fs/pstore/internal.h   |   43 
 fs/pstore/platform.c   |   12 -
 fs/pstore/ram.c|   65 +--
 fs/pstore/ram_core.c   |   12 +++--
 include/linux/pstore.h |   13 +
 include/linux/pstore_ram.h |3 +-
 kernel/trace/trace.c   |7 +--
 kernel/trace/trace_functions.c |   36 +
 13 files changed, 337 insertions(+), 39 deletions(-)

-- 
Anton Vorontsov
Email: cbouatmai...@gmail.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 firmware 4/4] rtl_nic: add new firmware for RTL8168G

[Ben Hutchings]

On Mon, 2012-07-09 at 11:11 +0800, Hayes Wang wrote:
> File: rtl_nic/rtl8168g-1.fw
> Version: 0.0.1
[...]

Also had the encoding problem, but also applied.

Ben.

-- 
Ben Hutchings
The generation of random numbers is too important to be left to chance.
- Robert Coveyou


signature.asc
Description: This is a digitally signed message part

Re: [PATCH v2] mm: Warn about costly page allocation

[Andrew Morton]

On Tue, 10 Jul 2012 08:55:53 +0900
Minchan Kim  wrote:

> ...
>
> --- a/mm/page_alloc.c
> +++ b/mm/page_alloc.c
> @@ -2276,6 +2276,29 @@ gfp_to_alloc_flags(gfp_t gfp_mask)
>   return alloc_flags;
>  }
>  
> +#if defined(CONFIG_DEBUG_VM) && !defined(CONFIG_COMPACTION)
> +static inline void check_page_alloc_costly_order(unsigned int order, gfp_t 
> flags)
> +{
> + if (likely(order <= PAGE_ALLOC_COSTLY_ORDER))
> + return;
> +
> + if (!printk_ratelimited())
> + return;
> +
> + pr_warn("%s: page allocation high-order stupidity: "
> + "order:%d, mode:0x%x\n", current->comm, order, flags);
> + pr_warn("Enable compaction if high-order allocations are "
> + "very few and rare.\n");
> + pr_warn("If you need regular high-order allocation, "
> + "compaction wouldn't help it.\n");
> + dump_stack();
> +}
> +#else
> +static inline void check_page_alloc_costly_order(unsigned int order)
> +{
> +}
> +#endif

Let's remember that plain old "inline" is ignored by the compiler.  If
we really really want to inline something then we should use
__always_inline.

And inlining this function would be a bad thing to do - it causes the
outer function to have an increased cache footprint.  A good way to
optimise this function is probably to move the unlikely stuff
out-of-line:

if (unlikely(order > PAGE_ALLOC_COSTLY_ORDER))
check_page_alloc_costly_order(...);

or

static noinline void __check_page_alloc_costly_order(...)
{
}

static __always_inline void check_page_alloc_costly_order(...)
{
if (unlikely(order > PAGE_ALLOC_COSTLY_ORDER))
__check_page_alloc_costly_order(...);
}


Also, the displayed messages don't seem very, umm, professional.  Who
was stupid - us or the kernel-configurer?  And "Enable
CONFIG_COMPACTION" would be more specific (and hence helpful) than
"Enable compaction").

And how on earth is the user, or the person who is configuring kernels
for customers to determine whether the kernel will be frequently
performing higher-order allocations?


So I dunno, this all looks like we have a kernel problem and we're
throwing our problem onto hopelessly ill-equipped users of that kernel?

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