[PATCH 5/9] regulator: max8660: Use devm_regulator_register

[Sachin Kamat]

devm_* simplifies the code.

Signed-off-by: Sachin Kamat 
---
 drivers/regulator/max8660.c |   29 ++---
 1 file changed, 6 insertions(+), 23 deletions(-)

diff --git a/drivers/regulator/max8660.c b/drivers/regulator/max8660.c
index d428ef9..a057342 100644
--- a/drivers/regulator/max8660.c
+++ b/drivers/regulator/max8660.c
@@ -352,7 +352,7 @@ static int max8660_probe(struct i2c_client *client,
for (i = 0; i < pdata->num_subdevs; i++) {
 
if (!pdata->subdevs[i].platform_data)
-   goto err_out;
+   return ret;
 
boot_on = pdata->subdevs[i].platform_data->constraints.boot_on;
 
@@ -378,7 +378,7 @@ static int max8660_probe(struct i2c_client *client,
case MAX8660_V7:
if (!strcmp(i2c_id->name, "max8661")) {
dev_err(>dev, "Regulator not on this 
chip!\n");
-   goto err_out;
+   return ret;
}
 
if (boot_on)
@@ -388,7 +388,7 @@ static int max8660_probe(struct i2c_client *client,
default:
dev_err(>dev, "invalid regulator %s\n",
 pdata->subdevs[i].name);
-   goto err_out;
+   return ret;
}
}
 
@@ -401,33 +401,17 @@ static int max8660_probe(struct i2c_client *client,
config.init_data = pdata->subdevs[i].platform_data;
config.driver_data = max8660;
 
-   rdev[i] = regulator_register(_reg[id], );
+   rdev[i] = devm_regulator_register(>dev,
+ _reg[id], );
if (IS_ERR(rdev[i])) {
-   ret = PTR_ERR(rdev[i]);
dev_err(>dev, "failed to register %s\n",
max8660_reg[id].name);
-   goto err_unregister;
+   return PTR_ERR(rdev[i]);
}
}
 
i2c_set_clientdata(client, max8660);
return 0;
-
-err_unregister:
-   while (--i >= 0)
-   regulator_unregister(rdev[i]);
-err_out:
-   return ret;
-}
-
-static int max8660_remove(struct i2c_client *client)
-{
-   struct max8660 *max8660 = i2c_get_clientdata(client);
-   int i;
-
-   for (i = 0; i < MAX8660_V_END; i++)
-   regulator_unregister(max8660->rdev[i]);
-   return 0;
 }
 
 static const struct i2c_device_id max8660_id[] = {
@@ -439,7 +423,6 @@ MODULE_DEVICE_TABLE(i2c, max8660_id);
 
 static struct i2c_driver max8660_driver = {
.probe = max8660_probe,
-   .remove = max8660_remove,
.driver = {
.name   = "max8660",
.owner  = THIS_MODULE,
-- 
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 2/9] regulator: max1586: Use devm_regulator_register

[Sachin Kamat]

devm_* simplifies the code.

Signed-off-by: Sachin Kamat 
---
 drivers/regulator/max1586.c |   26 +-
 1 file changed, 5 insertions(+), 21 deletions(-)

diff --git a/drivers/regulator/max1586.c b/drivers/regulator/max1586.c
index 54af610..3abf76a 100644
--- a/drivers/regulator/max1586.c
+++ b/drivers/regulator/max1586.c
@@ -166,7 +166,7 @@ static int max1586_pmic_probe(struct i2c_client *client,
struct max1586_platform_data *pdata = client->dev.platform_data;
struct regulator_config config = { };
struct max1586_data *max1586;
-   int i, id, ret = -ENOMEM;
+   int i, id;
 
max1586 = devm_kzalloc(>dev, sizeof(struct max1586_data) +
sizeof(struct regulator_dev *) * (MAX1586_V6 + 1),
@@ -193,7 +193,7 @@ static int max1586_pmic_probe(struct i2c_client *client,
continue;
if (id < MAX1586_V3 || id > MAX1586_V6) {
dev_err(>dev, "invalid regulator id %d\n", id);
-   goto err;
+   return -EINVAL;
}
 
if (id == MAX1586_V3) {
@@ -207,33 +207,18 @@ static int max1586_pmic_probe(struct i2c_client *client,
config.init_data = pdata->subdevs[i].platform_data;
config.driver_data = max1586;
 
-   rdev[i] = regulator_register(_reg[id], );
+   rdev[i] = devm_regulator_register(>dev,
+ _reg[id], );
if (IS_ERR(rdev[i])) {
-   ret = PTR_ERR(rdev[i]);
dev_err(>dev, "failed to register %s\n",
max1586_reg[id].name);
-   goto err;
+   return PTR_ERR(rdev[i]);
}
}
 
i2c_set_clientdata(client, max1586);
dev_info(>dev, "Maxim 1586 regulator driver loaded\n");
return 0;
-
-err:
-   while (--i >= 0)
-   regulator_unregister(rdev[i]);
-   return ret;
-}
-
-static int max1586_pmic_remove(struct i2c_client *client)
-{
-   struct max1586_data *max1586 = i2c_get_clientdata(client);
-   int i;
-
-   for (i = 0; i <= MAX1586_V6; i++)
-   regulator_unregister(max1586->rdev[i]);
-   return 0;
 }
 
 static const struct i2c_device_id max1586_id[] = {
@@ -244,7 +229,6 @@ MODULE_DEVICE_TABLE(i2c, max1586_id);
 
 static struct i2c_driver max1586_pmic_driver = {
.probe = max1586_pmic_probe,
-   .remove = max1586_pmic_remove,
.driver = {
.name   = "max1586",
.owner  = THIS_MODULE,
-- 
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/9] regulator: max8649: Use devm_regulator_register

[Sachin Kamat]

devm_* simplifies the code.

Signed-off-by: Sachin Kamat 
---
 drivers/regulator/max8649.c |   14 ++
 1 file changed, 2 insertions(+), 12 deletions(-)

diff --git a/drivers/regulator/max8649.c b/drivers/regulator/max8649.c
index db6c9be..b2a808c 100644
--- a/drivers/regulator/max8649.c
+++ b/drivers/regulator/max8649.c
@@ -234,7 +234,8 @@ static int max8649_regulator_probe(struct i2c_client 
*client,
config.driver_data = info;
config.regmap = info->regmap;
 
-   info->regulator = regulator_register(_desc, );
+   info->regulator = devm_regulator_register(>dev, _desc,
+ );
if (IS_ERR(info->regulator)) {
dev_err(info->dev, "failed to register regulator %s\n",
dcdc_desc.name);
@@ -244,16 +245,6 @@ static int max8649_regulator_probe(struct i2c_client 
*client,
return 0;
 }
 
-static int max8649_regulator_remove(struct i2c_client *client)
-{
-   struct max8649_regulator_info *info = i2c_get_clientdata(client);
-
-   if (info)
-   regulator_unregister(info->regulator);
-
-   return 0;
-}
-
 static const struct i2c_device_id max8649_id[] = {
{ "max8649", 0 },
{ }
@@ -262,7 +253,6 @@ MODULE_DEVICE_TABLE(i2c, max8649_id);
 
 static struct i2c_driver max8649_driver = {
.probe  = max8649_regulator_probe,
-   .remove = max8649_regulator_remove,
.driver = {
.name   = "max8649",
},
-- 
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 9/9] regulator: max8998: Use devm_regulator_register

[Sachin Kamat]

devm_* simplifies the code.

Signed-off-by: Sachin Kamat 
---
 drivers/regulator/max8998.c |   35 ---
 1 file changed, 8 insertions(+), 27 deletions(-)

diff --git a/drivers/regulator/max8998.c b/drivers/regulator/max8998.c
index a4c53b2..ae3f065 100644
--- a/drivers/regulator/max8998.c
+++ b/drivers/regulator/max8998.c
@@ -790,16 +790,14 @@ static int max8998_pmic_probe(struct platform_device 
*pdev)
dev_err(>dev,
"MAX8998 SET1 GPIO defined as 0 !\n");
WARN_ON(!pdata->buck1_set1);
-   ret = -EIO;
-   goto err_out;
+   return -EIO;
}
/* Check if SET2 is not equal to 0 */
if (!pdata->buck1_set2) {
dev_err(>dev,
"MAX8998 SET2 GPIO defined as 0 !\n");
WARN_ON(!pdata->buck1_set2);
-   ret = -EIO;
-   goto err_out;
+   return -EIO;
}
 
gpio_request(pdata->buck1_set1, "MAX8998 BUCK1_SET1");
@@ -823,7 +821,7 @@ static int max8998_pmic_probe(struct platform_device *pdev)
ret = max8998_write_reg(i2c,
MAX8998_REG_BUCK1_VOLTAGE1 + v, i);
if (ret)
-   goto err_out;
+   return ret;
}
}
 
@@ -833,8 +831,7 @@ static int max8998_pmic_probe(struct platform_device *pdev)
dev_err(>dev,
"MAX8998 SET3 GPIO defined as 0 !\n");
WARN_ON(!pdata->buck2_set3);
-   ret = -EIO;
-   goto err_out;
+   return -EIO;
}
gpio_request(pdata->buck2_set3, "MAX8998 BUCK2_SET3");
gpio_direction_output(pdata->buck2_set3,
@@ -852,7 +849,7 @@ static int max8998_pmic_probe(struct platform_device *pdev)
ret = max8998_write_reg(i2c,
MAX8998_REG_BUCK2_VOLTAGE1 + v, i);
if (ret)
-   goto err_out;
+   return ret;
}
}
 
@@ -875,34 +872,19 @@ static int max8998_pmic_probe(struct platform_device 
*pdev)
config.init_data = pdata->regulators[i].initdata;
config.driver_data = max8998;
 
-   rdev[i] = regulator_register([index], );
+   rdev[i] = devm_regulator_register(>dev,
+ [index], );
if (IS_ERR(rdev[i])) {
ret = PTR_ERR(rdev[i]);
dev_err(max8998->dev, "regulator %s init failed (%d)\n",
regulators[index].name, ret);
rdev[i] = NULL;
-   goto err;
+   return ret;
}
}
 
 
return 0;
-err:
-   while (--i >= 0)
-   regulator_unregister(rdev[i]);
-err_out:
-   return ret;
-}
-
-static int max8998_pmic_remove(struct platform_device *pdev)
-{
-   struct max8998_data *max8998 = platform_get_drvdata(pdev);
-   struct regulator_dev **rdev = max8998->rdev;
-   int i;
-
-   for (i = 0; i < max8998->num_regulators; i++)
-   regulator_unregister(rdev[i]);
-   return 0;
 }
 
 static const struct platform_device_id max8998_pmic_id[] = {
@@ -918,7 +900,6 @@ static struct platform_driver max8998_pmic_driver = {
.owner = THIS_MODULE,
},
.probe = max8998_pmic_probe,
-   .remove = max8998_pmic_remove,
.id_table = max8998_pmic_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 3/9] regulator: max77693: Use devm_regulator_register

[Sachin Kamat]

devm_* simplifies the code.

Signed-off-by: Sachin Kamat 
---
 drivers/regulator/max77693.c |   28 
 1 file changed, 4 insertions(+), 24 deletions(-)

diff --git a/drivers/regulator/max77693.c b/drivers/regulator/max77693.c
index ce4b96c..2054ae1 100644
--- a/drivers/regulator/max77693.c
+++ b/drivers/regulator/max77693.c
@@ -230,7 +230,7 @@ static int max77693_pmic_probe(struct platform_device *pdev)
struct max77693_dev *iodev = dev_get_drvdata(pdev->dev.parent);
struct max77693_pmic_dev *max77693_pmic;
struct max77693_regulator_data *rdata = NULL;
-   int num_rdata, i, ret;
+   int num_rdata, i;
struct regulator_config config;
 
num_rdata = max77693_pmic_init_rdata(>dev, );
@@ -266,36 +266,17 @@ static int max77693_pmic_probe(struct platform_device 
*pdev)
config.init_data = rdata[i].initdata;
config.of_node = rdata[i].of_node;
 
-   max77693_pmic->rdev[i] = regulator_register([id],
-   );
+   max77693_pmic->rdev[i] = devm_regulator_register(>dev,
+   [id], );
if (IS_ERR(max77693_pmic->rdev[i])) {
-   ret = PTR_ERR(max77693_pmic->rdev[i]);
dev_err(max77693_pmic->dev,
"Failed to initialize regulator-%d\n", id);
max77693_pmic->rdev[i] = NULL;
-   goto err;
+   return PTR_ERR(max77693_pmic->rdev[i]);
}
}
 
return 0;
- err:
-   while (--i >= 0)
-   regulator_unregister(max77693_pmic->rdev[i]);
-
-   return ret;
-}
-
-static int max77693_pmic_remove(struct platform_device *pdev)
-{
-   struct max77693_pmic_dev *max77693_pmic = platform_get_drvdata(pdev);
-   struct regulator_dev **rdev = max77693_pmic->rdev;
-   int i;
-
-   for (i = 0; i < max77693_pmic->num_regulators; i++)
-   if (rdev[i])
-   regulator_unregister(rdev[i]);
-
-   return 0;
 }
 
 static const struct platform_device_id max77693_pmic_id[] = {
@@ -311,7 +292,6 @@ static struct platform_driver max77693_pmic_driver = {
   .owner = THIS_MODULE,
   },
.probe = max77693_pmic_probe,
-   .remove = max77693_pmic_remove,
.id_table = max77693_pmic_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 8/9] regulator: max8997: Use devm_regulator_register

[Sachin Kamat]

devm_* simplifies the code.

Signed-off-by: Sachin Kamat 
---
 drivers/regulator/max8997.c |   38 ++
 1 file changed, 10 insertions(+), 28 deletions(-)

diff --git a/drivers/regulator/max8997.c b/drivers/regulator/max8997.c
index df20069..059e8ed 100644
--- a/drivers/regulator/max8997.c
+++ b/drivers/regulator/max8997.c
@@ -1081,7 +1081,7 @@ static int max8997_pmic_probe(struct platform_device 
*pdev)
pdata->buck1_voltage[i] +
buck1245_voltage_map_desc.step);
if (ret < 0)
-   goto err_out;
+   return ret;
 
max8997->buck2_vol[i] = ret =
max8997_get_voltage_proper_val(
@@ -1090,7 +1090,7 @@ static int max8997_pmic_probe(struct platform_device 
*pdev)
pdata->buck2_voltage[i] +
buck1245_voltage_map_desc.step);
if (ret < 0)
-   goto err_out;
+   return ret;
 
max8997->buck5_vol[i] = ret =
max8997_get_voltage_proper_val(
@@ -1099,7 +1099,7 @@ static int max8997_pmic_probe(struct platform_device 
*pdev)
pdata->buck5_voltage[i] +
buck1245_voltage_map_desc.step);
if (ret < 0)
-   goto err_out;
+   return ret;
 
if (max_buck1 < max8997->buck1_vol[i])
max_buck1 = max8997->buck1_vol[i];
@@ -1143,24 +1143,23 @@ static int max8997_pmic_probe(struct platform_device 
*pdev)
!gpio_is_valid(pdata->buck125_gpios[1]) ||
!gpio_is_valid(pdata->buck125_gpios[2])) {
dev_err(>dev, "GPIO NOT VALID\n");
-   ret = -EINVAL;
-   goto err_out;
+   return -EINVAL;
}
 
ret = devm_gpio_request(>dev, pdata->buck125_gpios[0],
"MAX8997 SET1");
if (ret)
-   goto err_out;
+   return ret;
 
ret = devm_gpio_request(>dev, pdata->buck125_gpios[1],
"MAX8997 SET2");
if (ret)
-   goto err_out;
+   return ret;
 
ret = devm_gpio_request(>dev, pdata->buck125_gpios[2],
"MAX8997 SET3");
if (ret)
-   goto err_out;
+   return ret;
 
gpio_direction_output(pdata->buck125_gpios[0],
(max8997->buck125_gpioindex >> 2)
@@ -1205,33 +1204,17 @@ static int max8997_pmic_probe(struct platform_device 
*pdev)
config.driver_data = max8997;
config.of_node = pdata->regulators[i].reg_node;
 
-   rdev[i] = regulator_register([id], );
+   rdev[i] = devm_regulator_register(>dev, [id],
+ );
if (IS_ERR(rdev[i])) {
-   ret = PTR_ERR(rdev[i]);
dev_err(max8997->dev, "regulator init failed for %d\n",
id);
rdev[i] = NULL;
-   goto err;
+   return PTR_ERR(rdev[i]);
}
}
 
return 0;
-err:
-   while (--i >= 0)
-   regulator_unregister(rdev[i]);
-err_out:
-   return ret;
-}
-
-static int max8997_pmic_remove(struct platform_device *pdev)
-{
-   struct max8997_data *max8997 = platform_get_drvdata(pdev);
-   struct regulator_dev **rdev = max8997->rdev;
-   int i;
-
-   for (i = 0; i < max8997->num_regulators; i++)
-   regulator_unregister(rdev[i]);
-   return 0;
 }
 
 static const struct platform_device_id max8997_pmic_id[] = {
@@ -1246,7 +1229,6 @@ static struct platform_driver max8997_pmic_driver = {
.owner = THIS_MODULE,
},
.probe = max8997_pmic_probe,
-   .remove = max8997_pmic_remove,
.id_table = max8997_pmic_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 7/9] regulator: max8973-regulator: Use devm_regulator_register

[Sachin Kamat]

devm_* simplifies the code.

Signed-off-by: Sachin Kamat 
---
 drivers/regulator/max8973-regulator.c |   11 +--
 1 file changed, 1 insertion(+), 10 deletions(-)

diff --git a/drivers/regulator/max8973-regulator.c 
b/drivers/regulator/max8973-regulator.c
index 0c5195a..04de63d 100644
--- a/drivers/regulator/max8973-regulator.c
+++ b/drivers/regulator/max8973-regulator.c
@@ -467,7 +467,7 @@ static int max8973_probe(struct i2c_client *client,
config.regmap = max->regmap;
 
/* Register the regulators */
-   rdev = regulator_register(>desc, );
+   rdev = devm_regulator_register(>dev, >desc, );
if (IS_ERR(rdev)) {
ret = PTR_ERR(rdev);
dev_err(max->dev, "regulator register failed, err %d\n", ret);
@@ -478,14 +478,6 @@ static int max8973_probe(struct i2c_client *client,
return 0;
 }
 
-static int max8973_remove(struct i2c_client *client)
-{
-   struct max8973_chip *max = i2c_get_clientdata(client);
-
-   regulator_unregister(max->rdev);
-   return 0;
-}
-
 static const struct i2c_device_id max8973_id[] = {
{.name = "max8973",},
{},
@@ -499,7 +491,6 @@ static struct i2c_driver max8973_i2c_driver = {
.owner = THIS_MODULE,
},
.probe = max8973_probe,
-   .remove = max8973_remove,
.id_table = max8973_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/

Re: [PATCH 1/2] Move and rename HP watchdog timer driver

[Guenter Roeck]

On 09/03/2013 10:51 PM, Matthew Garrett wrote:

On Tue, 2013-09-03 at 22:43 -0700, Guenter Roeck wrote:


If that is the case, wouldn't it make more sense to have separate drivers,
one per functionality, plus an mfd driver to bind them all together ?


It'd be an option, but I don't think there's a huge benefit - the
functionality's reasonably related and there's no real internal bus
architecture on the device.


On the other side it is much cleaner. drivers/mfd/lpc_sch.c and 
drivers/mfd/lpc_ich.c
are good examples.

Guenter

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

[PATCH 6/9] regulator: max8907-regulator: Use devm_regulator_register

[Sachin Kamat]

devm_* simplifies the code.

Signed-off-by: Sachin Kamat 
---
 drivers/regulator/max8907-regulator.c |   23 +++
 1 file changed, 3 insertions(+), 20 deletions(-)

diff --git a/drivers/regulator/max8907-regulator.c 
b/drivers/regulator/max8907-regulator.c
index 4568c15..0c5fe6c 100644
--- a/drivers/regulator/max8907-regulator.c
+++ b/drivers/regulator/max8907-regulator.c
@@ -350,33 +350,17 @@ static int max8907_regulator_probe(struct platform_device 
*pdev)
pmic->desc[i].ops = _out5v_hwctl_ops;
}
 
-   pmic->rdev[i] = regulator_register(>desc[i], );
+   pmic->rdev[i] = devm_regulator_register(>dev,
+   >desc[i], );
if (IS_ERR(pmic->rdev[i])) {
dev_err(>dev,
"failed to register %s regulator\n",
pmic->desc[i].name);
-   ret = PTR_ERR(pmic->rdev[i]);
-   goto err_unregister_regulator;
+   return PTR_ERR(pmic->rdev[i]);
}
}
 
return 0;
-
-err_unregister_regulator:
-   while (--i >= 0)
-   regulator_unregister(pmic->rdev[i]);
-   return ret;
-}
-
-static int max8907_regulator_remove(struct platform_device *pdev)
-{
-   struct max8907_regulator *pmic = platform_get_drvdata(pdev);
-   int i;
-
-   for (i = 0; i < MAX8907_NUM_REGULATORS; i++)
-   regulator_unregister(pmic->rdev[i]);
-
-   return 0;
 }
 
 static struct platform_driver max8907_regulator_driver = {
@@ -385,7 +369,6 @@ static struct platform_driver max8907_regulator_driver = {
   .owner = THIS_MODULE,
   },
.probe = max8907_regulator_probe,
-   .remove = max8907_regulator_remove,
 };
 
 static int __init max8907_regulator_init(void)
-- 
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/9] regulator: max77686: Use devm_regulator_register

[Sachin Kamat]

devm_* simplifies the code.

Signed-off-by: Sachin Kamat 
---
This series is compile tested.
---
 drivers/regulator/max77686.c |   22 +++---
 1 file changed, 3 insertions(+), 19 deletions(-)

diff --git a/drivers/regulator/max77686.c b/drivers/regulator/max77686.c
index f563057..de5b30e 100644
--- a/drivers/regulator/max77686.c
+++ b/drivers/regulator/max77686.c
@@ -478,32 +478,17 @@ static int max77686_pmic_probe(struct platform_device 
*pdev)
config.of_node = pdata->regulators[i].of_node;
 
max77686->opmode[i] = regulators[i].enable_mask;
-   max77686->rdev[i] = regulator_register([i], );
+   max77686->rdev[i] = devm_regulator_register(>dev,
+   [i], );
if (IS_ERR(max77686->rdev[i])) {
-   ret = PTR_ERR(max77686->rdev[i]);
dev_err(>dev,
"regulator init failed for %d\n", i);
max77686->rdev[i] = NULL;
-   goto err;
+   return PTR_ERR(max77686->rdev[i]);
}
}
 
return 0;
-err:
-   while (--i >= 0)
-   regulator_unregister(max77686->rdev[i]);
-   return ret;
-}
-
-static int max77686_pmic_remove(struct platform_device *pdev)
-{
-   struct max77686_data *max77686 = platform_get_drvdata(pdev);
-   int i;
-
-   for (i = 0; i < MAX77686_REGULATORS; i++)
-   regulator_unregister(max77686->rdev[i]);
-
-   return 0;
 }
 
 static const struct platform_device_id max77686_pmic_id[] = {
@@ -518,7 +503,6 @@ static struct platform_driver max77686_pmic_driver = {
.owner = THIS_MODULE,
},
.probe = max77686_pmic_probe,
-   .remove = max77686_pmic_remove,
.id_table = max77686_pmic_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/

Re: [PATCH 1/2] Move and rename HP watchdog timer driver

[Matthew Garrett]

On Tue, 2013-09-03 at 22:43 -0700, Guenter Roeck wrote:

> If that is the case, wouldn't it make more sense to have separate drivers,
> one per functionality, plus an mfd driver to bind them all together ?

It'd be an option, but I don't think there's a huge benefit - the
functionality's reasonably related and there's no real internal bus
architecture on the device.

-- 
Matthew Garrett 

[PATCH net-next 3/5] driver/net: enic: Try DMA 64 first, then failover to DMA

[Govindarajulu Varadarajan]

In servers with more than 1.1 TB of RAM, the existing 40/32 bit DMA
could cause failure as the DMA-able address could go outside the range
addressable using 40/32 bits.

The following patch first tried 64 bit DMA if possible, failover to 32
bit.

Signed-off-by: Sujith Sankar 
Signed-off-by: Christian Benvenuti 
Signed-off-by: Govindarajulu Varadarajan 
---
 drivers/net/ethernet/cisco/enic/enic_main.c | 8 
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/drivers/net/ethernet/cisco/enic/enic_main.c 
b/drivers/net/ethernet/cisco/enic/enic_main.c
index 93898ba..7b756cf9 100644
--- a/drivers/net/ethernet/cisco/enic/enic_main.c
+++ b/drivers/net/ethernet/cisco/enic/enic_main.c
@@ -2080,11 +2080,11 @@ static int enic_probe(struct pci_dev *pdev, const 
struct pci_device_id *ent)
pci_set_master(pdev);
 
/* Query PCI controller on system for DMA addressing
-* limitation for the device.  Try 40-bit first, and
+* limitation for the device.  Try 64-bit first, and
 * fail to 32-bit.
 */
 
-   err = pci_set_dma_mask(pdev, DMA_BIT_MASK(40));
+   err = pci_set_dma_mask(pdev, DMA_BIT_MASK(64));
if (err) {
err = pci_set_dma_mask(pdev, DMA_BIT_MASK(32));
if (err) {
@@ -2098,10 +2098,10 @@ static int enic_probe(struct pci_dev *pdev, const 
struct pci_device_id *ent)
goto err_out_release_regions;
}
} else {
-   err = pci_set_consistent_dma_mask(pdev, DMA_BIT_MASK(40));
+   err = pci_set_consistent_dma_mask(pdev, DMA_BIT_MASK(64));
if (err) {
dev_err(dev, "Unable to obtain %u-bit DMA "
-   "for consistent allocations, aborting\n", 40);
+   "for consistent allocations, aborting\n", 64);
goto err_out_release_regions;
}
using_dac = 1;
-- 
1.8.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 net-next 4/5] driver/net: enic: Exposing symbols for Cisco's low latency driver

[Govindarajulu Varadarajan]

This patch exposes symbols for usnic low latency driver that can be used to 
register and unregister vNics as well to traverse the resources on vNics.

Signed-off-by: Upinder Malhi 
Signed-off-by: Nishank Trivedi 
Signed-off-by: Christian Benvenuti 
---
 drivers/net/ethernet/cisco/enic/vnic_dev.c | 10 ++
 drivers/net/ethernet/cisco/enic/vnic_dev.h |  1 +
 2 files changed, 11 insertions(+)

diff --git a/drivers/net/ethernet/cisco/enic/vnic_dev.c 
b/drivers/net/ethernet/cisco/enic/vnic_dev.c
index 97455c5..69dd925 100644
--- a/drivers/net/ethernet/cisco/enic/vnic_dev.c
+++ b/drivers/net/ethernet/cisco/enic/vnic_dev.c
@@ -175,6 +175,7 @@ unsigned int vnic_dev_get_res_count(struct vnic_dev *vdev,
 {
return vdev->res[type].count;
 }
+EXPORT_SYMBOL(vnic_dev_get_res_count);
 
 void __iomem *vnic_dev_get_res(struct vnic_dev *vdev, enum vnic_res_type type,
unsigned int index)
@@ -193,6 +194,7 @@ void __iomem *vnic_dev_get_res(struct vnic_dev *vdev, enum 
vnic_res_type type,
return (char __iomem *)vdev->res[type].vaddr;
}
 }
+EXPORT_SYMBOL(vnic_dev_get_res);
 
 static unsigned int vnic_dev_desc_ring_size(struct vnic_dev_ring *ring,
unsigned int desc_count, unsigned int desc_size)
@@ -942,6 +944,7 @@ void vnic_dev_unregister(struct vnic_dev *vdev)
kfree(vdev);
}
 }
+EXPORT_SYMBOL(vnic_dev_unregister);
 
 struct vnic_dev *vnic_dev_register(struct vnic_dev *vdev,
void *priv, struct pci_dev *pdev, struct vnic_dev_bar *bar,
@@ -969,6 +972,13 @@ err_out:
vnic_dev_unregister(vdev);
return NULL;
 }
+EXPORT_SYMBOL(vnic_dev_register);
+
+struct pci_dev *vnic_dev_get_pdev(struct vnic_dev *vdev)
+{
+   return vdev->pdev;
+}
+EXPORT_SYMBOL(vnic_dev_get_pdev);
 
 int vnic_dev_init_prov2(struct vnic_dev *vdev, u8 *buf, u32 len)
 {
diff --git a/drivers/net/ethernet/cisco/enic/vnic_dev.h 
b/drivers/net/ethernet/cisco/enic/vnic_dev.h
index f3d9b79..e670029 100644
--- a/drivers/net/ethernet/cisco/enic/vnic_dev.h
+++ b/drivers/net/ethernet/cisco/enic/vnic_dev.h
@@ -127,6 +127,7 @@ int vnic_dev_set_ig_vlan_rewrite_mode(struct vnic_dev *vdev,
 struct vnic_dev *vnic_dev_register(struct vnic_dev *vdev,
void *priv, struct pci_dev *pdev, struct vnic_dev_bar *bar,
unsigned int num_bars);
+struct pci_dev *vnic_dev_get_pdev(struct vnic_dev *vdev);
 int vnic_dev_init_prov2(struct vnic_dev *vdev, u8 *buf, u32 len);
 int vnic_dev_enable2(struct vnic_dev *vdev, int active);
 int vnic_dev_enable2_done(struct vnic_dev *vdev, int *status);
-- 
1.8.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 net-next 2/5] driver/net: enic: record q_number and rss_hash for skb

[Govindarajulu Varadarajan]

The following patch sets the skb->rxhash and skb->q_number.
This is used by RPS and RFS. Kernel can make use of hw provided hash
instead of calculating the hash.

Signed-off-by: Govindarajulu Varadarajan 
Signed-off-by: Nishank Trivedi 
Signed-off-by: Christian Benvenuti 
---
 drivers/net/ethernet/cisco/enic/enic_main.c | 11 +++
 1 file changed, 11 insertions(+)

diff --git a/drivers/net/ethernet/cisco/enic/enic_main.c 
b/drivers/net/ethernet/cisco/enic/enic_main.c
index 1ab3f18..93898ba 100644
--- a/drivers/net/ethernet/cisco/enic/enic_main.c
+++ b/drivers/net/ethernet/cisco/enic/enic_main.c
@@ -1034,6 +1034,14 @@ static void enic_rq_indicate_buf(struct vnic_rq *rq,
 
skb_put(skb, bytes_written);
skb->protocol = eth_type_trans(skb, netdev);
+   skb_record_rx_queue(skb, q_number);
+   if (netdev->features & NETIF_F_RXHASH) {
+   skb->rxhash = rss_hash;
+   if (rss_type & (NIC_CFG_RSS_HASH_TYPE_TCP_IPV6_EX |
+   NIC_CFG_RSS_HASH_TYPE_TCP_IPV6 |
+   NIC_CFG_RSS_HASH_TYPE_TCP_IPV4))
+   skb->l4_rxhash = true;
+   }
 
if ((netdev->features & NETIF_F_RXCSUM) && !csum_not_calc) {
skb->csum = htons(checksum);
@@ -2209,6 +2217,7 @@ static int enic_probe(struct pci_dev *pdev, const struct 
pci_device_id *ent)
}
 
netif_set_real_num_tx_queues(netdev, enic->wq_count);
+   netif_set_real_num_rx_queues(netdev, enic->rq_count);
 
/* Setup notification timer, HW reset task, and wq locks
 */
@@ -2258,6 +2267,8 @@ static int enic_probe(struct pci_dev *pdev, const struct 
pci_device_id *ent)
if (ENIC_SETTING(enic, TSO))
netdev->hw_features |= NETIF_F_TSO |
NETIF_F_TSO6 | NETIF_F_TSO_ECN;
+   if (ENIC_SETTING(enic, RSS))
+   netdev->hw_features |= NETIF_F_RXHASH;
if (ENIC_SETTING(enic, RXCSUM))
netdev->hw_features |= NETIF_F_RXCSUM;
 
-- 
1.8.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 net-next 5/5] driver/net: enic: update enic maintainers and driver

[Govindarajulu Varadarajan]

Signed-off-by: Govindarajulu Varadarajan 
Signed-off-by: Sujith Sankar 
Signed-off-by: Nishank Trivedi 
Signed-off-by: Christian Benvenuti 
---
 MAINTAINERS| 3 ++-
 drivers/net/ethernet/cisco/enic/enic.h | 2 +-
 2 files changed, 3 insertions(+), 2 deletions(-)

diff --git a/MAINTAINERS b/MAINTAINERS
index 705bb96..ecb83cd 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -2076,7 +2076,8 @@ F:drivers/usb/chipidea/
 
 CISCO VIC ETHERNET NIC DRIVER
 M: Christian Benvenuti 
-M: Roopa Prabhu 
+M: Sujith Sankar 
+M: Govindarajulu Varadarajan 
 M: Neel Patel 
 M: Nishank Trivedi 
 S: Supported
diff --git a/drivers/net/ethernet/cisco/enic/enic.h 
b/drivers/net/ethernet/cisco/enic/enic.h
index 34b637a..e9f7c65 100644
--- a/drivers/net/ethernet/cisco/enic/enic.h
+++ b/drivers/net/ethernet/cisco/enic/enic.h
@@ -32,7 +32,7 @@
 
 #define DRV_NAME   "enic"
 #define DRV_DESCRIPTION"Cisco VIC Ethernet NIC Driver"
-#define DRV_VERSION"2.1.1.43"
+#define DRV_VERSION"2.1.1.50"
 #define DRV_COPYRIGHT  "Copyright 2008-2013 Cisco Systems, Inc"
 
 #define ENIC_BARS_MAX  6
-- 
1.8.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 net-next 1/5] driver/net: enic: Add multi tx support for enic

[Govindarajulu Varadarajan]

The following patch adds multi tx support for enic.

Signed-off-by: Nishank Trivedi 
Signed-off-by: Christian Benvenuti 
Signed-off-by: Govindarajulu Varadarajan 
---
 drivers/net/ethernet/cisco/enic/enic.h  |  2 +-
 drivers/net/ethernet/cisco/enic/enic_main.c | 36 +++--
 2 files changed, 25 insertions(+), 13 deletions(-)

diff --git a/drivers/net/ethernet/cisco/enic/enic.h 
b/drivers/net/ethernet/cisco/enic/enic.h
index be16731..34b637a 100644
--- a/drivers/net/ethernet/cisco/enic/enic.h
+++ b/drivers/net/ethernet/cisco/enic/enic.h
@@ -37,7 +37,7 @@
 
 #define ENIC_BARS_MAX  6
 
-#define ENIC_WQ_MAX1
+#define ENIC_WQ_MAX8
 #define ENIC_RQ_MAX8
 #define ENIC_CQ_MAX(ENIC_WQ_MAX + ENIC_RQ_MAX)
 #define ENIC_INTR_MAX  (ENIC_CQ_MAX + 2)
diff --git a/drivers/net/ethernet/cisco/enic/enic_main.c 
b/drivers/net/ethernet/cisco/enic/enic_main.c
index bcf15b1..1ab3f18 100644
--- a/drivers/net/ethernet/cisco/enic/enic_main.c
+++ b/drivers/net/ethernet/cisco/enic/enic_main.c
@@ -128,10 +128,10 @@ static int enic_wq_service(struct vnic_dev *vdev, struct 
cq_desc *cq_desc,
completed_index, enic_wq_free_buf,
opaque);
 
-   if (netif_queue_stopped(enic->netdev) &&
+   if (netif_tx_queue_stopped(netdev_get_tx_queue(enic->netdev, q_number)) 
&&
vnic_wq_desc_avail(>wq[q_number]) >=
(MAX_SKB_FRAGS + ENIC_DESC_MAX_SPLITS))
-   netif_wake_queue(enic->netdev);
+   netif_wake_subqueue(enic->netdev, q_number);
 
spin_unlock(>wq_lock[q_number]);
 
@@ -292,10 +292,15 @@ static irqreturn_t enic_isr_msix_rq(int irq, void *data)
 static irqreturn_t enic_isr_msix_wq(int irq, void *data)
 {
struct enic *enic = data;
-   unsigned int cq = enic_cq_wq(enic, 0);
-   unsigned int intr = enic_msix_wq_intr(enic, 0);
+   unsigned int cq;
+   unsigned int intr;
unsigned int wq_work_to_do = -1; /* no limit */
unsigned int wq_work_done;
+   unsigned int wq_irq;
+
+   wq_irq = (u32)irq - enic->msix_entry[enic_msix_wq_intr(enic, 0)].vector;
+   cq = enic_cq_wq(enic, wq_irq);
+   intr = enic_msix_wq_intr(enic, wq_irq);
 
wq_work_done = vnic_cq_service(>cq[cq],
wq_work_to_do, enic_wq_service, NULL);
@@ -511,14 +516,18 @@ static netdev_tx_t enic_hard_start_xmit(struct sk_buff 
*skb,
struct net_device *netdev)
 {
struct enic *enic = netdev_priv(netdev);
-   struct vnic_wq *wq = >wq[0];
+   struct vnic_wq *wq;
unsigned long flags;
+   unsigned int txq_map;
 
if (skb->len <= 0) {
dev_kfree_skb(skb);
return NETDEV_TX_OK;
}
 
+   txq_map = skb_get_queue_mapping(skb) % enic->wq_count;
+   wq = >wq[txq_map];
+
/* Non-TSO sends must fit within ENIC_NON_TSO_MAX_DESC descs,
 * which is very likely.  In the off chance it's going to take
 * more than * ENIC_NON_TSO_MAX_DESC, linearize the skb.
@@ -531,23 +540,23 @@ static netdev_tx_t enic_hard_start_xmit(struct sk_buff 
*skb,
return NETDEV_TX_OK;
}
 
-   spin_lock_irqsave(>wq_lock[0], flags);
+   spin_lock_irqsave(>wq_lock[txq_map], flags);
 
if (vnic_wq_desc_avail(wq) <
skb_shinfo(skb)->nr_frags + ENIC_DESC_MAX_SPLITS) {
-   netif_stop_queue(netdev);
+   netif_tx_stop_queue(netdev_get_tx_queue(netdev, txq_map));
/* This is a hard error, log it */
netdev_err(netdev, "BUG! Tx ring full when queue awake!\n");
-   spin_unlock_irqrestore(>wq_lock[0], flags);
+   spin_unlock_irqrestore(>wq_lock[txq_map], flags);
return NETDEV_TX_BUSY;
}
 
enic_queue_wq_skb(enic, wq, skb);
 
if (vnic_wq_desc_avail(wq) < MAX_SKB_FRAGS + ENIC_DESC_MAX_SPLITS)
-   netif_stop_queue(netdev);
+   netif_tx_stop_queue(netdev_get_tx_queue(netdev, txq_map));
 
-   spin_unlock_irqrestore(>wq_lock[0], flags);
+   spin_unlock_irqrestore(>wq_lock[txq_map], flags);
 
return NETDEV_TX_OK;
 }
@@ -1369,7 +1378,7 @@ static int enic_open(struct net_device *netdev)
 
enic_set_rx_mode(netdev);
 
-   netif_wake_queue(netdev);
+   netif_tx_wake_all_queues(netdev);
 
for (i = 0; i < enic->rq_count; i++)
napi_enable(>napi[i]);
@@ -2032,7 +2041,8 @@ static int enic_probe(struct pci_dev *pdev, const struct 
pci_device_id *ent)
 * instance data is initialized to zero.
 */
 
-   netdev = alloc_etherdev(sizeof(struct enic));
+   netdev = alloc_etherdev_mqs(sizeof(struct enic),
+   ENIC_RQ_MAX, ENIC_WQ_MAX);
if (!netdev)
return -ENOMEM;
 
@@ -2198,6 +2208,8 @@ static int enic_probe(struct pci_dev *pdev, const struct 
pci_device_id *ent)
goto 

[PATCH net-next 0/5] driver/net: enic: enic driver updates

[Govindarajulu Varadarajan]

This series includes support for multi-tx, rss_hash, RPS, RFS, DMA64, 
export symbols for cisco low latency driver and update the driver version and 
driver maintainers.

Govindarajulu Varadarajan (5):
  driver/net: enic: Add multi tx support for enic
  driver/net: enic: record q_number and rss_hash for skb
  driver/net: enic: Try DMA 64 first, then failover to DMA
  driver/net: enic: Exposing symbols for Cisco's low latency driver
  driver/net: enic: update enic maintainers and driver

 MAINTAINERS |  3 +-
 drivers/net/ethernet/cisco/enic/enic.h  |  4 +--
 drivers/net/ethernet/cisco/enic/enic_main.c | 55 -
 drivers/net/ethernet/cisco/enic/vnic_dev.c  | 10 ++
 drivers/net/ethernet/cisco/enic/vnic_dev.h  |  1 +
 5 files changed, 54 insertions(+), 19 deletions(-)

-- 
1.8.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] Move and rename HP watchdog timer driver

[Guenter Roeck]

On 09/03/2013 10:29 PM, Matthew Garrett wrote:

The HP watchdog timer driver binds to the HP iLO system support controller
PCI device. This PCI device actually supports a wider range of
functionality, so give the driver a more generic name and move it to the x86
platform driver directory in preparation for the following changes.



If that is the case, wouldn't it make more sense to have separate drivers,
one per functionality, plus an mfd driver to bind them all together ?

Guenter


Signed-off-by: Matthew Garrett 
---
  drivers/platform/x86/Kconfig |  20 +
  drivers/platform/x86/Makefile|   1 +
  drivers/platform/x86/hpilo_support.c | 890 +++
  drivers/watchdog/Kconfig |  18 -
  drivers/watchdog/Makefile|   1 -
  drivers/watchdog/hpwdt.c | 890 ---
  6 files changed, 911 insertions(+), 909 deletions(-)
  create mode 100644 drivers/platform/x86/hpilo_support.c
  delete mode 100644 drivers/watchdog/hpwdt.c

diff --git a/drivers/platform/x86/Kconfig b/drivers/platform/x86/Kconfig
index 36a9e60..34e6a47 100644
--- a/drivers/platform/x86/Kconfig
+++ b/drivers/platform/x86/Kconfig
@@ -817,4 +817,24 @@ config PVPANIC
  a paravirtualized device provided by QEMU; it lets a virtual machine
  (guest) communicate panic events to the host.

+config HP_ILO_SUPPORT
+tristate "HP ProLiant iLO2+ Hardware Watchdog Timer"
+depends on X86 && PCI
+help
+  A software monitoring watchdog and NMI sourcing driver. This driver
+  will detect lockups and provide a stack trace. This is a driver that
+  will only load on an HP ProLiant system with a minimum of iLO2 
support.
+
+  To compile this driver as a module, choose M here: the module will be
+  called hpilo_support.
+
+config HPWDT_NMI_DECODING
+bool "NMI decoding support for the HP ProLiant iLO2+ Hardware Watchdog 
Timer"
+depends on HP_ILO_SUPPORT
+default y
+help
+  When an NMI occurs this feature will make the necessary BIOS calls to
+  log the cause of the NMI.
+
+
  endif # X86_PLATFORM_DEVICES
diff --git a/drivers/platform/x86/Makefile b/drivers/platform/x86/Makefile
index 5dbe193..9198df2 100644
--- a/drivers/platform/x86/Makefile
+++ b/drivers/platform/x86/Makefile
@@ -16,6 +16,7 @@ obj-$(CONFIG_DELL_WMI_AIO)+= dell-wmi-aio.o
  obj-$(CONFIG_ACER_WMI)+= acer-wmi.o
  obj-$(CONFIG_ACERHDF) += acerhdf.o
  obj-$(CONFIG_HP_ACCEL)+= hp_accel.o
+obj-$(CONFIG_HPILO_SUPPORT)+= hpilo_support.o
  obj-$(CONFIG_HP_WMI)  += hp-wmi.o
  obj-$(CONFIG_AMILO_RFKILL)+= amilo-rfkill.o
  obj-$(CONFIG_TC1100_WMI)  += tc1100-wmi.o
diff --git a/drivers/platform/x86/hpilo_support.c 
b/drivers/platform/x86/hpilo_support.c
new file mode 100644
index 000..de7e4f4
--- /dev/null
+++ b/drivers/platform/x86/hpilo_support.c
@@ -0,0 +1,890 @@
+/*
+ * HP WatchDog Driver
+ * based on
+ *
+ * SoftDog 0.05:   A Software Watchdog Device
+ *
+ * (c) Copyright 2007 Hewlett-Packard Development Company, L.P.
+ * Thomas Mingarelli 
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License
+ * version 2 as published by the Free Software Foundation
+ *
+ */
+
+#define pr_fmt(fmt) KBUILD_MODNAME ": " fmt
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#ifdef CONFIG_HPWDT_NMI_DECODING
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#endif /* CONFIG_HPWDT_NMI_DECODING */
+#include 
+
+#define HPWDT_VERSION  "1.3.2"
+#define SECS_TO_TICKS(secs)((secs) * 1000 / 128)
+#define TICKS_TO_SECS(ticks)   ((ticks) * 128 / 1000)
+#define HPWDT_MAX_TIMERTICKS_TO_SECS(65535)
+#define DEFAULT_MARGIN 30
+
+static unsigned int soft_margin = DEFAULT_MARGIN;  /* in seconds */
+static unsigned int reload;/* the computed soft_margin */
+static bool nowayout = WATCHDOG_NOWAYOUT;
+static char expect_release;
+static unsigned long hpwdt_is_open;
+
+static void __iomem *pci_mem_addr; /* the PCI-memory address */
+static unsigned long __iomem *hpwdt_timer_reg;
+static unsigned long __iomem *hpwdt_timer_con;
+
+static DEFINE_PCI_DEVICE_TABLE(hpwdt_devices) = {
+   { PCI_DEVICE(PCI_VENDOR_ID_COMPAQ, 0xB203) },   /* iLO2 */
+   { PCI_DEVICE(PCI_VENDOR_ID_HP, 0x3306) },   /* iLO3 */
+   {0},/* terminate list */
+};
+MODULE_DEVICE_TABLE(pci, hpwdt_devices);
+
+#ifdef CONFIG_HPWDT_NMI_DECODING
+#define PCI_BIOS32_SD_VALUE0x5F32335F  /* "_32_" */
+#define CRU_BIOS_SIGNATURE_VALUE   0x55524324
+#define PCI_BIOS32_PARAGRAPH_LEN   16
+#define 

Re: kobject: delayed kobject release: help find buggy drivers

[Rusty Russell]

Greg KH  writes:
> On Tue, Sep 03, 2013 at 04:44:42PM -0400, Dave Jones wrote:
>> On Tue, Sep 03, 2013 at 06:59:24PM +, Linux Kernel wrote:
>>  > Gitweb: 
>> http://git.kernel.org/linus/;a=commit;h=c817a67ecba7c3c2aaa104796d78f160af60920d
>>  > Commit: c817a67ecba7c3c2aaa104796d78f160af60920d
>>  > Parent: 7c42721fe0c58a848849b43ff558cf2fb86aa35a
>>  > Author: Russell King 
>>  > AuthorDate: Thu Jun 27 15:06:14 2013 +0100
>>  > Committer:  Greg Kroah-Hartman 
>>  > CommitDate: Thu Jul 25 15:39:04 2013 -0700
>>  > 
>>  > kobject: delayed kobject release: help find buggy drivers
>>  > 
>>  > Implement debugging for kobject release functions.  kobjects are
>>  > reference counted, so the drop of the last reference to them is not
>>  > predictable. However, the common case is for the last reference to be
>>  > the kobject's removal from a subsystem, which results in the release
>>  > function being immediately called.
>>  > 
>>  > This can hide subtle bugs, which can occur when another thread holds a
>>  > reference to the kobject at the same time that a kobject is removed.
>>  > This results in the release method being delayed.
>>  > 
>>  > In order to make these kinds of problems more visible, the following
>>  > patch implements a delayed release; this has the effect that the
>>  > release function will be out of order with respect to the removal of
>>  > the kobject in the same manner that it would be if a reference was
>>  > being held.
>>  > 
>>  > This provides us with an easy way to allow driver writers to debug
>>  > their drivers and fix otherwise hidden problems.
>>  > 
>>  > Signed-off-by: Russell King 
>>  > Signed-off-by: Greg Kroah-Hartman 
>> 
>> With this enabled, I get a bunch of scrolling oopses immediately after
>> exiting the bootloader. It happens so early I can't even capture them
>> over usb-serial, or earlyprintk=dbgp.
>> 
>> And for whatever reason, the printk path while oopsing ignores boot_delay 
>> parameter,
>> so I can't even use that.
>> 
>> any ideas ?
>
> The first big bug found with this was with the module kobject code, and
> a fix for that should be going in through Rusty's tree to Linus for this
> merge window (right Rusty?)

Yep, just sent pull request.  The fix was the final commit there...

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 2/2] Add support for modifying firmware configuration via HP iLO

[Matthew Garrett]

Recent HP iLO systems provide support for modifying the firmware
configuration at runtime via accesses to the iLO hardware. This patch adds
support for exposing the available firmware configuration options via sysfs
and permits userspace to modify them, taking effect after the next reboot.
This has been implemented based on tracing register accesses from the HP
userspace utility that performs the same job - the userspace driver performs
direct hardware access via port IO, which honestly seems like an amazingly
bad idea. Moving this in-kernel is massively safer.

Signed-off-by: Matthew Garrett 
---
 .../ABI/testing/sysfs-firmware-hp_bios_config  |  27 +
 drivers/platform/x86/Kconfig   |  14 +-
 drivers/platform/x86/hpilo_support.c   | 777 -
 3 files changed, 811 insertions(+), 7 deletions(-)
 create mode 100644 Documentation/ABI/testing/sysfs-firmware-hp_bios_config

diff --git a/Documentation/ABI/testing/sysfs-firmware-hp_bios_config 
b/Documentation/ABI/testing/sysfs-firmware-hp_bios_config
new file mode 100644
index 000..69ad11b
--- /dev/null
+++ b/Documentation/ABI/testing/sysfs-firmware-hp_bios_config
@@ -0,0 +1,27 @@
+What:  /sys/firmware/hpilo_bios_config
+Date:  July 2013
+Contact:   Matthew Garrett 
+Description:
+   This directory exposes the HP iLO interface for manipulating
+   firmware configuration options. One subdirectory is present
+   for each configuration option, and contains the following
+   files:
+
+   active: The currently active value for the
+   configuration option.
+
+   choices:The available choices for the configuration
+   option with human-readable descriptions of
+   each option.
+
+   description:The human-readable description of the
+   configuration option.
+
+   new:Read/write attribute for setting the value
+   of the configuration option. Writing an integer
+   will configure the firmware to use this choice
+   on the next reboot. Reading will return the
+   value that has been chosen, if any.
+
+   warning:Human-readable text describing any caveats
+   associated with the configuration option.
\ No newline at end of file
diff --git a/drivers/platform/x86/Kconfig b/drivers/platform/x86/Kconfig
index 34e6a47..e880a37 100644
--- a/drivers/platform/x86/Kconfig
+++ b/drivers/platform/x86/Kconfig
@@ -818,12 +818,18 @@ config PVPANIC
  (guest) communicate panic events to the host.
 
 config HP_ILO_SUPPORT
-tristate "HP ProLiant iLO2+ Hardware Watchdog Timer"
+tristate "HP ProLiant iLO2+ System Support driver"
 depends on X86 && PCI
 help
-  A software monitoring watchdog and NMI sourcing driver. This driver
-  will detect lockups and provide a stack trace. This is a driver that
-  will only load on an HP ProLiant system with a minimum of iLO2 
support.
+ This driver provides support for the System Support functionality of
+ the HP ProLiant iLO2 and later devices. It implements two main
+ functions:
+
+ 1) A software monitoring watchdog and NMI sourcing driver. This
+ driver will detect lockups and provide a stack trace.
+
+ 2) On systems with appropriate support, an interface to allow
+ runtime configuration of system firmware configuration options.
 
   To compile this driver as a module, choose M here: the module will be
   called hpilo_support.
diff --git a/drivers/platform/x86/hpilo_support.c 
b/drivers/platform/x86/hpilo_support.c
index de7e4f4..d8788fd 100644
--- a/drivers/platform/x86/hpilo_support.c
+++ b/drivers/platform/x86/hpilo_support.c
@@ -16,22 +16,26 @@
 #define pr_fmt(fmt) KBUILD_MODNAME ": " fmt
 
 #include 
+#include 
 #include 
 #include 
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
+#include 
+#include 
+#include 
 #include 
 #include 
 #include 
 #ifdef CONFIG_HPWDT_NMI_DECODING
-#include 
-#include 
 #include 
 #include 
 #include 
@@ -51,9 +55,13 @@ static bool nowayout = WATCHDOG_NOWAYOUT;
 static char expect_release;
 static unsigned long hpwdt_is_open;
 
+static struct kobject *hpilo_kobj;
+static struct pci_dev *hpilo_dev;
 static void __iomem *pci_mem_addr; /* the PCI-memory address */
 static unsigned long __iomem *hpwdt_timer_reg;
 static unsigned long __iomem *hpwdt_timer_con;
+static unsigned long rcu_address;
+static int rcu_size;
 
 static DEFINE_PCI_DEVICE_TABLE(hpwdt_devices) = {
{ PCI_DEVICE(PCI_VENDOR_ID_COMPAQ, 0xB203) },   /* iLO2 */
@@ -62,6 

[PATCH 1/2] Move and rename HP watchdog timer driver

[Matthew Garrett]

The HP watchdog timer driver binds to the HP iLO system support controller
PCI device. This PCI device actually supports a wider range of
functionality, so give the driver a more generic name and move it to the x86
platform driver directory in preparation for the following changes.

Signed-off-by: Matthew Garrett 
---
 drivers/platform/x86/Kconfig |  20 +
 drivers/platform/x86/Makefile|   1 +
 drivers/platform/x86/hpilo_support.c | 890 +++
 drivers/watchdog/Kconfig |  18 -
 drivers/watchdog/Makefile|   1 -
 drivers/watchdog/hpwdt.c | 890 ---
 6 files changed, 911 insertions(+), 909 deletions(-)
 create mode 100644 drivers/platform/x86/hpilo_support.c
 delete mode 100644 drivers/watchdog/hpwdt.c

diff --git a/drivers/platform/x86/Kconfig b/drivers/platform/x86/Kconfig
index 36a9e60..34e6a47 100644
--- a/drivers/platform/x86/Kconfig
+++ b/drivers/platform/x86/Kconfig
@@ -817,4 +817,24 @@ config PVPANIC
  a paravirtualized device provided by QEMU; it lets a virtual machine
  (guest) communicate panic events to the host.
 
+config HP_ILO_SUPPORT
+tristate "HP ProLiant iLO2+ Hardware Watchdog Timer"
+depends on X86 && PCI
+help
+  A software monitoring watchdog and NMI sourcing driver. This driver
+  will detect lockups and provide a stack trace. This is a driver that
+  will only load on an HP ProLiant system with a minimum of iLO2 
support.
+
+  To compile this driver as a module, choose M here: the module will be
+  called hpilo_support.
+
+config HPWDT_NMI_DECODING
+bool "NMI decoding support for the HP ProLiant iLO2+ Hardware Watchdog 
Timer"
+depends on HP_ILO_SUPPORT
+default y
+help
+  When an NMI occurs this feature will make the necessary BIOS calls to
+  log the cause of the NMI.
+
+
 endif # X86_PLATFORM_DEVICES
diff --git a/drivers/platform/x86/Makefile b/drivers/platform/x86/Makefile
index 5dbe193..9198df2 100644
--- a/drivers/platform/x86/Makefile
+++ b/drivers/platform/x86/Makefile
@@ -16,6 +16,7 @@ obj-$(CONFIG_DELL_WMI_AIO)+= dell-wmi-aio.o
 obj-$(CONFIG_ACER_WMI) += acer-wmi.o
 obj-$(CONFIG_ACERHDF)  += acerhdf.o
 obj-$(CONFIG_HP_ACCEL) += hp_accel.o
+obj-$(CONFIG_HPILO_SUPPORT)+= hpilo_support.o
 obj-$(CONFIG_HP_WMI)   += hp-wmi.o
 obj-$(CONFIG_AMILO_RFKILL) += amilo-rfkill.o
 obj-$(CONFIG_TC1100_WMI)   += tc1100-wmi.o
diff --git a/drivers/platform/x86/hpilo_support.c 
b/drivers/platform/x86/hpilo_support.c
new file mode 100644
index 000..de7e4f4
--- /dev/null
+++ b/drivers/platform/x86/hpilo_support.c
@@ -0,0 +1,890 @@
+/*
+ * HP WatchDog Driver
+ * based on
+ *
+ * SoftDog 0.05:   A Software Watchdog Device
+ *
+ * (c) Copyright 2007 Hewlett-Packard Development Company, L.P.
+ * Thomas Mingarelli 
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License
+ * version 2 as published by the Free Software Foundation
+ *
+ */
+
+#define pr_fmt(fmt) KBUILD_MODNAME ": " fmt
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#ifdef CONFIG_HPWDT_NMI_DECODING
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#endif /* CONFIG_HPWDT_NMI_DECODING */
+#include 
+
+#define HPWDT_VERSION  "1.3.2"
+#define SECS_TO_TICKS(secs)((secs) * 1000 / 128)
+#define TICKS_TO_SECS(ticks)   ((ticks) * 128 / 1000)
+#define HPWDT_MAX_TIMERTICKS_TO_SECS(65535)
+#define DEFAULT_MARGIN 30
+
+static unsigned int soft_margin = DEFAULT_MARGIN;  /* in seconds */
+static unsigned int reload;/* the computed soft_margin */
+static bool nowayout = WATCHDOG_NOWAYOUT;
+static char expect_release;
+static unsigned long hpwdt_is_open;
+
+static void __iomem *pci_mem_addr; /* the PCI-memory address */
+static unsigned long __iomem *hpwdt_timer_reg;
+static unsigned long __iomem *hpwdt_timer_con;
+
+static DEFINE_PCI_DEVICE_TABLE(hpwdt_devices) = {
+   { PCI_DEVICE(PCI_VENDOR_ID_COMPAQ, 0xB203) },   /* iLO2 */
+   { PCI_DEVICE(PCI_VENDOR_ID_HP, 0x3306) },   /* iLO3 */
+   {0},/* terminate list */
+};
+MODULE_DEVICE_TABLE(pci, hpwdt_devices);
+
+#ifdef CONFIG_HPWDT_NMI_DECODING
+#define PCI_BIOS32_SD_VALUE0x5F32335F  /* "_32_" */
+#define CRU_BIOS_SIGNATURE_VALUE   0x55524324
+#define PCI_BIOS32_PARAGRAPH_LEN   16
+#define PCI_ROM_BASE1  0x000F
+#define ROM_SIZE   0x1
+
+struct bios32_service_dir {
+   u32 signature;
+   u32 entry_point;
+   u8 revision;
+   u8 length;
+   u8 checksum;
+   

Re: Linux 3.11

[Willy Tarreau]

On Mon, Sep 02, 2013 at 04:46:18PM -0700, Guenter Roeck wrote:
> I can only recommend for everyone to send pull requests through a gmail 
> account.

The problem I'm seeing with this method to combat abusive filtering from
e-mail providers is that we'll quickly end up needing to have one account
per provider depending on whom we want to send mail. It's not e-mail anymore
if you need to transfer them from inside the recipient's network, really...

Willy

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

Re: [PATCH 3/3] extcon: Simplify extcon_dev_register() prototype by removing unnecessary parameter

[Chanwoo Choi]

On 09/04/2013 10:16 AM, Greg KH wrote:
> On Wed, Sep 04, 2013 at 09:17:02AM +0900, Chanwoo Choi wrote:
>> On 09/04/2013 12:57 AM, Greg KH wrote:
>>> On Mon, Sep 02, 2013 at 10:13:44AM +0900, Chanwoo Choi wrote:
 Hi Greg,

 On 09/02/2013 09:40 AM, Greg KH wrote:
> On Mon, Sep 02, 2013 at 09:20:08AM +0900, Chanwoo Choi wrote:
>> This patch remove extcon_dev_register()'s second parameter which means
>> the pointer of parent device to simplify prototype of this function.
>
> No, please don't.  You want the parent to be passed in, as the core
> needs it when it is registered with the system, otherwise it will not
> show up in sysfs properly (i.e. you can't set it afterwards.)

 Currently, each extcon driver have allocated memory for extcon device
 by using devm_kzalloc() in each extcon device driver.
>>>
>>> That seems backwards, the extcon core should be the one doing the
>>> allocation, and ownership of the device, like all other subsystem cores
>>> do.  That makes the driver logic much simpler, and the lifetime
>>> ownership correct (i.e. what happens when a device is unbound from a
>>> driver by userspace?  The driver can't control the device memory
>>> anymore...)
>>>
>>
>> OK,
>> The extcon core will control memory allocation instead of extcon device 
>> driver
>> as following.
>> - devm_extcon_allocate_device(struct device *dev)
> 
> Huh?  Why do you need a devm allocator?  This is a "real" child device,
> just create it with a "extcon_create_device()" or some such call, like
> all other busses do?

I refer Input/IIO subsystem to check the process of device registration.
Input subsystem has following functions for memory allocation of input device
and input device registration.

Input subsystem
- struct input_dev *devm_input_allocate_device(struct device *device)
- struct input_dev *input_allocate_device(void)
- int input_register_device(struct input_dev *dev)
drivers/input/input.c

devm_input_allocate_device()/input_allocate_device() can allocate
memory for input device in input core. And then created input device
pass input_register_device() as parameter.

So, input device driver haven't executed kmalloc() or devm_kmalloc()
to allocate memory of input device by using input_allocate_device()/
devm_input_allocate_device().


Also,IIO subsystem has separate iio_device_alloc() function
to allocate memory for iio device. But IIO subsystem hasn't
"devm_" allocator. So, If iio device driver fail initialization
in *_probe, should execute iio_device_free() to free allocated memory.

IIO Subsystem
- iio_device_alloc(int sizeof_priv)
- iio_device_register(struct iio_dev *indio_dev);
drivers/iio/industrialio-core.c


So, I think extcon subsystem need 
extcon_allocate_device()/devm_extcon_allocate_device()
to allocate for memory extcon device. To implement 
devm_extcon_allocate_device() function
, extcon subsystem need extcon_allocate_device() because 
devm_extcon_allocate_device()
must call extcon_allocate_device for memory allocation.

If extcon_allocate_device()/devm_extcon_allocate_device() is implemented to 
extcon core,
I think extcon core can control the memory operation of extcon device.

EXTCON Subsystem
- devm_extcon_allocate_device(struct device *dev)
- extcon_allocate_device(void)
- extcon_dev_register(struct extcon_dev *edev)

If I'm wrong, please correct me. Thanks.

Best Regards,
Chanwoo Choi








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

[PATCH][RESEND] cris: remove deprecated IRQF_DISABLED

[Michael Opdenacker]

This patch proposes to remove the IRQF_DISABLED flag from CRIS
architecture code. It's a NOOP since 2.6.35 and it will be removed
one day.

Comments mentioning IRQF_DISABLED are also updated, knowing
that all interrupts are now "fast interrupts", their handlers
running with interrupts disabled.

Don't hesitate to let me know if you have other ways of
rephrasing the comments!

This is an update for 3.11 of a patch already sent for 3.10

Signed-off-by: Michael Opdenacker 
---
 arch/cris/arch-v10/drivers/gpio.c |  4 ++--
 arch/cris/arch-v10/drivers/sync_serial.c  |  4 ++--
 arch/cris/arch-v10/kernel/time.c  |  6 ++
 arch/cris/arch-v32/drivers/mach-a3/gpio.c |  2 +-
 arch/cris/arch-v32/drivers/mach-fs/gpio.c |  4 ++--
 arch/cris/arch-v32/kernel/fasttimer.c |  2 +-
 arch/cris/arch-v32/kernel/irq.c   | 10 +-
 arch/cris/arch-v32/kernel/smp.c   |  2 +-
 arch/cris/arch-v32/kernel/time.c  |  6 ++
 arch/cris/arch-v32/mach-a3/arbiter.c  |  4 ++--
 arch/cris/arch-v32/mach-fs/arbiter.c  |  2 +-
 arch/cris/include/arch-v10/arch/irq.h |  6 +++---
 arch/cris/include/arch-v32/arch/irq.h |  6 +++---
 arch/cris/kernel/irq.c|  3 ---
 14 files changed, 27 insertions(+), 34 deletions(-)

diff --git a/arch/cris/arch-v10/drivers/gpio.c 
b/arch/cris/arch-v10/drivers/gpio.c
index 609d551..f4374ba 100644
--- a/arch/cris/arch-v10/drivers/gpio.c
+++ b/arch/cris/arch-v10/drivers/gpio.c
@@ -838,13 +838,13 @@ static int __init gpio_init(void)
 * in some tests.
 */
res = request_irq(TIMER0_IRQ_NBR, gpio_poll_timer_interrupt,
-   IRQF_SHARED | IRQF_DISABLED, "gpio poll", gpio_name);
+   IRQF_SHARED, "gpio poll", gpio_name);
if (res) {
printk(KERN_CRIT "err: timer0 irq for gpio\n");
return res;
}
res = request_irq(PA_IRQ_NBR, gpio_interrupt,
-   IRQF_SHARED | IRQF_DISABLED, "gpio PA", gpio_name);
+   IRQF_SHARED, "gpio PA", gpio_name);
if (res)
printk(KERN_CRIT "err: PA irq for gpio\n");
 
diff --git a/arch/cris/arch-v10/drivers/sync_serial.c 
b/arch/cris/arch-v10/drivers/sync_serial.c
index a1c498d..04d39e0 100644
--- a/arch/cris/arch-v10/drivers/sync_serial.c
+++ b/arch/cris/arch-v10/drivers/sync_serial.c
@@ -580,7 +580,7 @@ static int sync_serial_open(struct inode *inode, struct 
file *file)
if (port == [0]) {
if (request_irq(8,
manual_interrupt,
-   IRQF_SHARED | IRQF_DISABLED,
+   IRQF_SHARED,
"synchronous serial manual irq",
[0])) {
printk(KERN_CRIT "Can't alloc "
@@ -590,7 +590,7 @@ static int sync_serial_open(struct inode *inode, struct 
file *file)
} else if (port == [1]) {
if (request_irq(8,
manual_interrupt,
-   IRQF_SHARED | IRQF_DISABLED,
+   IRQF_SHARED,
"synchronous serial manual irq",
[1])) {
printk(KERN_CRIT "Can't alloc "
diff --git a/arch/cris/arch-v10/kernel/time.c b/arch/cris/arch-v10/kernel/time.c
index fce7c54..e6a7227 100644
--- a/arch/cris/arch-v10/kernel/time.c
+++ b/arch/cris/arch-v10/kernel/time.c
@@ -178,13 +178,11 @@ timer_interrupt(int irq, void *dev_id)
 return IRQ_HANDLED;
 }
 
-/* timer is IRQF_SHARED so drivers can add stuff to the timer irq chain
- * it needs to be IRQF_DISABLED to make the jiffies update work properly
- */
+/* timer is IRQF_SHARED so drivers can add stuff to the timer irq chain */
 
 static struct irqaction irq2  = {
.handler = timer_interrupt,
-   .flags = IRQF_SHARED | IRQF_DISABLED,
+   .flags = IRQF_SHARED,
.name = "timer",
 };
 
diff --git a/arch/cris/arch-v32/drivers/mach-a3/gpio.c 
b/arch/cris/arch-v32/drivers/mach-a3/gpio.c
index 0b86dee..74f9fe8 100644
--- a/arch/cris/arch-v32/drivers/mach-a3/gpio.c
+++ b/arch/cris/arch-v32/drivers/mach-a3/gpio.c
@@ -978,7 +978,7 @@ static int __init gpio_init(void)
CRIS_LED_DISK_WRITE(0);
 
int res2 = request_irq(GIO_INTR_VECT, gpio_interrupt,
-   IRQF_SHARED | IRQF_DISABLED, "gpio", );
+   IRQF_SHARED, "gpio", );
if (res2) {
printk(KERN_ERR "err: irq for gpio\n");
return res2;
diff --git a/arch/cris/arch-v32/drivers/mach-fs/gpio.c 
b/arch/cris/arch-v32/drivers/mach-fs/gpio.c
index a2ac091..9e54273 100644
--- 

[PATCH][RESEND] blackfin: remove unused parameters in Kconfig

[Michael Opdenacker]

This patch proposes to remove kernel configuration parameters
defined in arch/blackfin/Kconfig, but used nowhere
in the makefiles and source code.

This is an update for 3.11 of a patch already sent for 3.10

Signed-off-by: Michael Opdenacker 
---
 arch/blackfin/Kconfig | 15 ---
 1 file changed, 15 deletions(-)

diff --git a/arch/blackfin/Kconfig b/arch/blackfin/Kconfig
index 3b6abc5..4445758 100644
--- a/arch/blackfin/Kconfig
+++ b/arch/blackfin/Kconfig
@@ -861,14 +861,6 @@ config SYS_BFIN_SPINLOCK_L1
  If enabled, sys_bfin_spinlock function is linked
  into L1 instruction memory. (less latency)
 
-config IP_CHECKSUM_L1
-   bool "Locate IP Checksum function in L1 Memory"
-   default n
-   depends on !SMP
-   help
- If enabled, the IP Checksum function is linked
- into L1 instruction memory. (less latency)
-
 config CACHELINE_ALIGNED_L1
bool "Locate cacheline_aligned data to L1 Data Memory"
default y if !BF54x
@@ -1330,13 +1322,6 @@ config PM_BFIN_WAKE_PB15
help
  Enable PB15 Wake-Up
 
-config PM_BFIN_WAKE_PB15_POL
-   int "Wake-up priority"
-   depends on PM_BFIN_WAKE_PB15
-   default 0
-   help
- Wake-Up priority 0(low) 1(high)
-
 config PM_BFIN_WAKE_PC15
bool "Allow Wake-Up from PC15"
depends on PM && BF60x
-- 
1.8.1.2

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

[PATCH][RESEND] ARM: imx: remove IRQF_DISABLED

[Michael Opdenacker]

This flag is a NOOP since 2.6.35 and can be removed.

This is an update for 3.11 of a patch already sent for 3.10

Signed-off-by: Michael Opdenacker 
---
 arch/arm/mach-imx/Kconfig | 2 +-
 arch/arm/mach-imx/epit.c  | 2 +-
 arch/arm/mach-imx/mach-armadillo5x0.c | 3 +--
 arch/arm/mach-imx/mach-mx31_3ds.c | 2 +-
 arch/arm/mach-imx/mach-pcm037.c   | 3 +--
 arch/arm/mach-imx/mx31lilly-db.c  | 3 +--
 arch/arm/mach-imx/time.c  | 2 +-
 7 files changed, 7 insertions(+), 10 deletions(-)

diff --git a/arch/arm/mach-imx/Kconfig b/arch/arm/mach-imx/Kconfig
index f546560..799a92f 100644
--- a/arch/arm/mach-imx/Kconfig
+++ b/arch/arm/mach-imx/Kconfig
@@ -22,7 +22,7 @@ config MXC_IRQ_PRIOR
help
  Select this if you want to use prioritized IRQ handling.
  This feature prevents higher priority ISR to be interrupted
- by lower priority IRQ even IRQF_DISABLED flag is not set.
+ by lower priority IRQ.
  This may be useful in embedded applications, where are strong
  requirements for timing.
  Say N here, unless you have a specialized requirement.
diff --git a/arch/arm/mach-imx/epit.c b/arch/arm/mach-imx/epit.c
index e02de18..074b1a8 100644
--- a/arch/arm/mach-imx/epit.c
+++ b/arch/arm/mach-imx/epit.c
@@ -171,7 +171,7 @@ static irqreturn_t epit_timer_interrupt(int irq, void 
*dev_id)
 
 static struct irqaction epit_timer_irq = {
.name   = "i.MX EPIT Timer Tick",
-   .flags  = IRQF_DISABLED | IRQF_TIMER | IRQF_IRQPOLL,
+   .flags  = IRQF_TIMER | IRQF_IRQPOLL,
.handler= epit_timer_interrupt,
 };
 
diff --git a/arch/arm/mach-imx/mach-armadillo5x0.c 
b/arch/arm/mach-imx/mach-armadillo5x0.c
index 368a6e3..58b864a 100644
--- a/arch/arm/mach-imx/mach-armadillo5x0.c
+++ b/arch/arm/mach-imx/mach-armadillo5x0.c
@@ -404,8 +404,7 @@ static int armadillo5x0_sdhc1_init(struct device *dev,
 
/* When supported the trigger type have to be BOTH */
ret = request_irq(gpio_to_irq(IOMUX_TO_GPIO(MX31_PIN_ATA_DMACK)),
- detect_irq,
- IRQF_DISABLED | IRQF_TRIGGER_FALLING,
+ detect_irq, IRQF_TRIGGER_FALLING,
  "sdhc-detect", data);
 
if (ret)
diff --git a/arch/arm/mach-imx/mach-mx31_3ds.c 
b/arch/arm/mach-imx/mach-mx31_3ds.c
index 1ed9161..50044a2 100644
--- a/arch/arm/mach-imx/mach-mx31_3ds.c
+++ b/arch/arm/mach-imx/mach-mx31_3ds.c
@@ -311,7 +311,7 @@ static int mx31_3ds_sdhc1_init(struct device *dev,
}
 
ret = request_irq(gpio_to_irq(IOMUX_TO_GPIO(MX31_PIN_GPIO3_1)),
- detect_irq, IRQF_DISABLED |
+ detect_irq,
  IRQF_TRIGGER_FALLING | IRQF_TRIGGER_RISING,
  "sdhc1-detect", data);
if (ret) {
diff --git a/arch/arm/mach-imx/mach-pcm037.c b/arch/arm/mach-imx/mach-pcm037.c
index bc0261e..45303bd6 100644
--- a/arch/arm/mach-imx/mach-pcm037.c
+++ b/arch/arm/mach-imx/mach-pcm037.c
@@ -371,8 +371,7 @@ static int pcm970_sdhc1_init(struct device *dev, 
irq_handler_t detect_irq,
 #endif
 
ret = request_irq(gpio_to_irq(IOMUX_TO_GPIO(MX31_PIN_SCK6)), detect_irq,
-   IRQF_DISABLED | IRQF_TRIGGER_FALLING,
-   "sdhc-detect", data);
+   IRQF_TRIGGER_FALLING, "sdhc-detect", data);
if (ret)
goto err_gpio_free_2;
 
diff --git a/arch/arm/mach-imx/mx31lilly-db.c b/arch/arm/mach-imx/mx31lilly-db.c
index d4361b8..649fe49 100644
--- a/arch/arm/mach-imx/mx31lilly-db.c
+++ b/arch/arm/mach-imx/mx31lilly-db.c
@@ -130,8 +130,7 @@ static int mxc_mmc1_init(struct device *dev,
gpio_direction_input(gpio_wp);
 
ret = request_irq(gpio_to_irq(IOMUX_TO_GPIO(MX31_PIN_GPIO1_1)),
- detect_irq,
- IRQF_DISABLED | IRQF_TRIGGER_FALLING,
+ detect_irq, IRQF_TRIGGER_FALLING,
  "MMC detect", data);
if (ret)
goto exit_free_wp;
diff --git a/arch/arm/mach-imx/time.c b/arch/arm/mach-imx/time.c
index cd46529..9b6638a 100644
--- a/arch/arm/mach-imx/time.c
+++ b/arch/arm/mach-imx/time.c
@@ -250,7 +250,7 @@ static irqreturn_t mxc_timer_interrupt(int irq, void 
*dev_id)
 
 static struct irqaction mxc_timer_irq = {
.name   = "i.MX Timer Tick",
-   .flags  = IRQF_DISABLED | IRQF_TIMER | IRQF_IRQPOLL,
+   .flags  = IRQF_TIMER | IRQF_IRQPOLL,
.handler= mxc_timer_interrupt,
 };
 
-- 
1.8.1.2

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

[PATCH][RESEND] ARM: footbridge: remove obsolete IRQF_DISABLED

[Michael Opdenacker]

This patch proposes to remove the IRQF_DISABLED flag from footbridge
code. It's a NOOP since 2.6.35.

This is an update for 3.11 of a patch already sent for 3.10

Signed-off-by: Michael Opdenacker 
---
 arch/arm/mach-footbridge/dc21285-timer.c |  2 +-
 arch/arm/mach-footbridge/dc21285.c   | 10 +-
 arch/arm/mach-footbridge/isa-timer.c |  2 +-
 3 files changed, 7 insertions(+), 7 deletions(-)

diff --git a/arch/arm/mach-footbridge/dc21285-timer.c 
b/arch/arm/mach-footbridge/dc21285-timer.c
index 9ee78f7..892d550 100644
--- a/arch/arm/mach-footbridge/dc21285-timer.c
+++ b/arch/arm/mach-footbridge/dc21285-timer.c
@@ -86,7 +86,7 @@ static irqreturn_t timer1_interrupt(int irq, void *dev_id)
 static struct irqaction footbridge_timer_irq = {
.name   = "dc21285_timer1",
.handler= timer1_interrupt,
-   .flags  = IRQF_DISABLED | IRQF_TIMER | IRQF_IRQPOLL,
+   .flags  = IRQF_TIMER | IRQF_IRQPOLL,
.dev_id = _dc21285,
 };
 
diff --git a/arch/arm/mach-footbridge/dc21285.c 
b/arch/arm/mach-footbridge/dc21285.c
index 3490a24..cc52e6c 100644
--- a/arch/arm/mach-footbridge/dc21285.c
+++ b/arch/arm/mach-footbridge/dc21285.c
@@ -336,15 +336,15 @@ void __init dc21285_preinit(void)
/*
 * We don't care if these fail.
 */
-   dc21285_request_irq(IRQ_PCI_SERR, dc21285_serr_irq, IRQF_DISABLED,
+   dc21285_request_irq(IRQ_PCI_SERR, dc21285_serr_irq, 0,
"PCI system error", _timer);
-   dc21285_request_irq(IRQ_PCI_PERR, dc21285_parity_irq, IRQF_DISABLED,
+   dc21285_request_irq(IRQ_PCI_PERR, dc21285_parity_irq, 0,
"PCI parity error", _timer);
-   dc21285_request_irq(IRQ_PCI_ABORT, dc21285_abort_irq, IRQF_DISABLED,
+   dc21285_request_irq(IRQ_PCI_ABORT, dc21285_abort_irq, 0,
"PCI abort", NULL);
-   dc21285_request_irq(IRQ_DISCARD_TIMER, dc21285_discard_irq, 
IRQF_DISABLED,
+   dc21285_request_irq(IRQ_DISCARD_TIMER, dc21285_discard_irq, 0,
"Discard timer", NULL);
-   dc21285_request_irq(IRQ_PCI_DPERR, dc21285_dparity_irq, IRQF_DISABLED,
+   dc21285_request_irq(IRQ_PCI_DPERR, dc21285_dparity_irq, 0,
"PCI data parity", NULL);
 
if (cfn_mode) {
diff --git a/arch/arm/mach-footbridge/isa-timer.c 
b/arch/arm/mach-footbridge/isa-timer.c
index d9301dd..b73f52e 100644
--- a/arch/arm/mach-footbridge/isa-timer.c
+++ b/arch/arm/mach-footbridge/isa-timer.c
@@ -27,7 +27,7 @@ static irqreturn_t pit_timer_interrupt(int irq, void *dev_id)
 static struct irqaction pit_timer_irq = {
.name   = "pit",
.handler= pit_timer_interrupt,
-   .flags  = IRQF_DISABLED | IRQF_TIMER | IRQF_IRQPOLL,
+   .flags  = IRQF_TIMER | IRQF_IRQPOLL,
.dev_id = _clockevent,
 };
 
-- 
1.8.1.2

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

Re: Potential use-after-free in ____call_usermodehelper

[Dan Aloni]

On Wed, Sep 04, 2013 at 12:49:58AM +0400, Dmitry Vyukov wrote:
> On Wed, Sep 4, 2013 at 12:27 AM, Dan Aloni  wrote:
> > Your work and contribution is appreciated nonetheless, but your bug
> > report needs to pertain closer to the work the core kernel hackers
> > are doing.
> 
> What exactly do you mean?

The kernel hackers are more likely to look into the issue when it is based
on their development trees or stable tree. i.e the minimal 'git diff' from 
one of their versions is the smallest.

> Btw, is it better to report such things here or file on bugzilla.kernel.org?

See the REPORTING-BUGS file in the source tree.

-- 
Dan Aloni
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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][RESEND] ARM: at91: remove IRQF_DISABLED

[Michael Opdenacker]

This flag is a NOOP since 2.6.36 and can be removed.

This is an update for 3.11 of a patch already sent for 3.10

Signed-off-by: Michael Opdenacker 
---
 arch/arm/mach-at91/at91rm9200_time.c  | 2 +-
 arch/arm/mach-at91/at91sam926x_time.c | 2 +-
 arch/arm/mach-at91/at91x40_time.c | 2 +-
 3 files changed, 3 insertions(+), 3 deletions(-)

diff --git a/arch/arm/mach-at91/at91rm9200_time.c 
b/arch/arm/mach-at91/at91rm9200_time.c
index 180b302..f607deb 100644
--- a/arch/arm/mach-at91/at91rm9200_time.c
+++ b/arch/arm/mach-at91/at91rm9200_time.c
@@ -93,7 +93,7 @@ static irqreturn_t at91rm9200_timer_interrupt(int irq, void 
*dev_id)
 
 static struct irqaction at91rm9200_timer_irq = {
.name   = "at91_tick",
-   .flags  = IRQF_SHARED | IRQF_DISABLED | IRQF_TIMER | 
IRQF_IRQPOLL,
+   .flags  = IRQF_SHARED | IRQF_TIMER | IRQF_IRQPOLL,
.handler= at91rm9200_timer_interrupt,
.irq= NR_IRQS_LEGACY + AT91_ID_SYS,
 };
diff --git a/arch/arm/mach-at91/at91sam926x_time.c 
b/arch/arm/mach-at91/at91sam926x_time.c
index 3a4bc2e..bb39232 100644
--- a/arch/arm/mach-at91/at91sam926x_time.c
+++ b/arch/arm/mach-at91/at91sam926x_time.c
@@ -171,7 +171,7 @@ static irqreturn_t at91sam926x_pit_interrupt(int irq, void 
*dev_id)
 
 static struct irqaction at91sam926x_pit_irq = {
.name   = "at91_tick",
-   .flags  = IRQF_SHARED | IRQF_DISABLED | IRQF_TIMER | 
IRQF_IRQPOLL,
+   .flags  = IRQF_SHARED | IRQF_TIMER | IRQF_IRQPOLL,
.handler= at91sam926x_pit_interrupt,
.irq= NR_IRQS_LEGACY + AT91_ID_SYS,
 };
diff --git a/arch/arm/mach-at91/at91x40_time.c 
b/arch/arm/mach-at91/at91x40_time.c
index 2919eba..c0e637a 100644
--- a/arch/arm/mach-at91/at91x40_time.c
+++ b/arch/arm/mach-at91/at91x40_time.c
@@ -57,7 +57,7 @@ static irqreturn_t at91x40_timer_interrupt(int irq, void 
*dev_id)
 
 static struct irqaction at91x40_timer_irq = {
.name   = "at91_tick",
-   .flags  = IRQF_DISABLED | IRQF_TIMER,
+   .flags  = IRQF_TIMER,
.handler= at91x40_timer_interrupt
 };
 
-- 
1.8.1.2

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

[PATCH net-next 2/2] tuntap: orphan frags before trying to set tx timestamp

[Jason Wang]

sock_tx_timestamp() will clear all zerocopy flags of skb which may lead the
frags never to be orphaned. This will break guest to guest traffic when zerocopy
is enabled. Fix this by orphaning the frags before trying to set tx time stamp.

The issue were introduced by commit eda297729171fe16bf34fe5b0419dfb69060f623
(tun: Support software transmit time stamping).

Cc: Richard Cochran 
Signed-off-by: Jason Wang 
---
 drivers/net/tun.c |9 +
 1 files changed, 5 insertions(+), 4 deletions(-)

diff --git a/drivers/net/tun.c b/drivers/net/tun.c
index 2dddb1b..af9a096 100644
--- a/drivers/net/tun.c
+++ b/drivers/net/tun.c
@@ -749,15 +749,16 @@ static netdev_tx_t tun_net_xmit(struct sk_buff *skb, 
struct net_device *dev)
  >= dev->tx_queue_len / tun->numqueues)
goto drop;
 
+   /* Orphan the skb - required as we might hang on to it
+* for indefinite time. */
+   if (unlikely(skb_orphan_frags(skb, GFP_ATOMIC)))
+   goto drop;
+
if (skb->sk) {
sock_tx_timestamp(skb->sk, _shinfo(skb)->tx_flags);
sw_tx_timestamp(skb);
}
 
-   /* Orphan the skb - required as we might hang on to it
-* for indefinite time. */
-   if (unlikely(skb_orphan_frags(skb, GFP_ATOMIC)))
-   goto drop;
skb_orphan(skb);
 
nf_reset(skb);
-- 
1.7.1

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

[PATCH net-next 1/2] tuntap: purge socket error queue on detach

[Jason Wang]

Commit eda297729171fe16bf34fe5b0419dfb69060f623
(tun: Support software transmit time stamping) will queue skbs into error queue
when tx stamping is enabled. But it forgets to purge the error queue during
detach. This patch fixes this.

Cc: Richard Cochran 
Signed-off-by: Jason Wang 
---
 drivers/net/tun.c |   12 +---
 1 files changed, 9 insertions(+), 3 deletions(-)

diff --git a/drivers/net/tun.c b/drivers/net/tun.c
index 60a1e93..2dddb1b 100644
--- a/drivers/net/tun.c
+++ b/drivers/net/tun.c
@@ -409,6 +409,12 @@ static struct tun_struct *tun_enable_queue(struct tun_file 
*tfile)
return tun;
 }
 
+static void tun_queue_purge(struct tun_file *tfile)
+{
+   skb_queue_purge(>sk.sk_receive_queue);
+   skb_queue_purge(>sk.sk_error_queue);
+}
+
 static void __tun_detach(struct tun_file *tfile, bool clean)
 {
struct tun_file *ntfile;
@@ -435,7 +441,7 @@ static void __tun_detach(struct tun_file *tfile, bool clean)
synchronize_net();
tun_flow_delete_by_queue(tun, tun->numqueues + 1);
/* Drop read queue */
-   skb_queue_purge(>sk.sk_receive_queue);
+   tun_queue_purge(tfile);
tun_set_real_num_queues(tun);
} else if (tfile->detached && clean) {
tun = tun_enable_queue(tfile);
@@ -487,12 +493,12 @@ static void tun_detach_all(struct net_device *dev)
for (i = 0; i < n; i++) {
tfile = rtnl_dereference(tun->tfiles[i]);
/* Drop read queue */
-   skb_queue_purge(>sk.sk_receive_queue);
+   tun_queue_purge(tfile);
sock_put(>sk);
}
list_for_each_entry_safe(tfile, tmp, >disabled, next) {
tun_enable_queue(tfile);
-   skb_queue_purge(>sk.sk_receive_queue);
+   tun_queue_purge(tfile);
sock_put(>sk);
}
BUG_ON(tun->numdisabled != 0);
-- 
1.7.1

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

Re: [PATCH v2] MIPS: Reduce _NSIG from 128 to 127 to avoid BUG_ON

[Rich Felker]

On Fri, Jun 28, 2013 at 11:03:33PM +0100, James Hogan wrote:
> On 28 June 2013 20:28, Denys Vlasenko  wrote:
> > On Monday 17 June 2013 12:36, James Hogan wrote:
> >> On 14/06/13 17:03, James Hogan wrote:
> >> > MIPS has 128 signals, the highest of which has the number 128 (they
> >> > start from 1). The following command causes get_signal_to_deliver() to
> >> > pass this signal number straight through to do_group_exit() as the exit
> >> > code:
> >> >
> >> >   strace sleep 10 & sleep 1 && kill -128 `pidof sleep`
> >> >
> >> > However do_group_exit() checks for the core dump bit (0x80) in the exit
> >> > code which matches in this particular case and the kernel panics:
> >> >
> >> >   BUG_ON(exit_code & 0x80); /* core dumps don't get here */
> >> >
> >> > Lets avoid this by changing the ABI by reducing the number of signals to
> >> > 127 (so that the maximum signal number is 127). Glibc incorrectly sets
> >> > [__]SIGRTMAX to 127 already. uClibc sets it to 128 so it's conceivable
> >> > that programs built against uClibc which intentionally uses RT signals
> >> > from the top (SIGRTMAX-n, n>=0) would need an updated uClibc (and a
> >> > rebuild if it's crazy enough to use __SIGRTMAX).
> >>
> >> Hmm, although this works around the BUG_ON, this doesn't actually seem
> >> to be sufficient to behave correctly.
> >>
> >> So it appears the exit status is constructed like this:
> >> bits  purpose
> >> 0x007fsignal number (0-127)
> >> 0x0080core dump
> >> 0xff00exit status
> >>
> >> but the macros in waitstatus.h and wait.h in libc
> >> (see also "man 2 wait"):
> >> WIFEXITED:   status & 0x7f == 0
> >> WIFSIGNALED: status & 0x7f in [1..126] (i.e. not 0 or 127)
> >> WIFSTOPPED:  status & 0xff == 127
> >>
> >> So termination due to SIG127 looks like it's been stopped instead of
> >> terminated via a signal, unless a core dump occurs in which case none of
> >> the above match.
> >>
> >> (And termination due to SIG128 hits BUG_ON, otherwise would appear to
> >> have exited normally with core dump).
> >>
> >>
> >> Reducing number of signals to 126 to avoid this will change the glibc
> >> ABI too, in which case we may as well reduce to 64 to match other
> >> arches, which is more likely to break something (I'm not really
> >> comfortable making that change).
> >>
> >> Reducing to 127 (this patch) still leaves incorrect exit status codes
> >> for SIG127 ...
> >>
> >> Any further thoughts/opinions?
> >
> > Strictly speaking, exit status of 0x007f isn't ambiguous.
> >
> > Currently userspace uses the following rules
> > (assuming that status is 16-bit (IOW, dropping PTRACE_EVENT bits)):
> >
> > WIFEXITED(status)= (status & 0x7f) == 0
> > WIFSIGNALED(status)  = (status & 0x7f) != 0 && (status & 0x7f) < 0x7f
> > WIFSTOPPED(status)   = (status & 0xff) == 0x7f
> > WIFCONTINUED(status) = (status == 0x)
> >
> > WEXITSTATUS(status)  = status >> 8
> > WSTOPSIG(status) = status >> 8
> > WCOREDUMP(status)= status & 0x80
> > WTERMSIG(status) = status & 0x7f
> >
> > When process dies from signal 127, status is 0x007f and it is not a valid
> > "stopped by signal" indicator, since WSTOPSIG == 0 is an impossibility.
> >
> > Status 0x007f get misinterpreted by the rules above, namely,
> > WIFSTOPPED is true, WIFSIGNALED is false.
> >
> > But an alternative definition exists which works correctly with
> > all previous status codes, treats 0x007f as "killed by signal 127"
> > and isn't more convoluted.
> > In fact, while WIFSTOPPED needs one additional check,
> > WIFSIGNALED gets simpler (loses one AND'ing operation):
> >
> > WIFSTOPPED(status)   = (status & 0xff) == 0x7f && (status >> 8) != 0
> > WIFSIGNALED(status)  = status != 0 && status <= 0xff
> >
> > All other rules need no change.
> >
> > I think it's feasible to ask {g,uc}libc to change their defines
> > (on MIPS as a minimum), and live with 127 signals.
> 
> Thanks for the explanation. This makes a lot of sense and if I
> understand correctly it already describes the current behaviour of the
> kernel up to SIG127 (I hadn't twigged WIFSTOPPED should imply
> WSTOPSIG!=0 for some reason). I like it.

One other note on this issue: SIG128 also aliases CLONE_VM, and it
would be very bad if a program requesting SIG128 as its exit signal
when calling clone instead ended up with the effects of CLONE_VM...

Also, I have some improved macros for WIFSTOPPED and WIFSIGNALED which
avoid multiple evaluation of their arguments:

#define WIFSTOPPED(s) ((short)s)&0x)*0x10001)>>8) > 0x7f00)
#define WIFSIGNALED(s) (((s)&0x)-1 < 0xffu)

These are what we are using in musl libc now.

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

Re: [PATCH-v5 1/6] idr: Percpu ida

[Nicholas A. Bellinger]

On Tue, 2013-09-03 at 18:27 -0700, Andrew Morton wrote:
> On Tue, 03 Sep 2013 09:06:58 -0700 "Nicholas A. Bellinger" 
>  wrote:
> 
> > Are there any other review comments to be addressed for this patch..?
> > 
> > If not, please kindly give your Reviewed-by if your OK for an initial
> > standalone merge.
> 
> Sorry, I'm largely offline for the next week...
> 
> It looks OK to me (that's as close as I get to an ack :))
> 

Thanks.  That quote is going in the commit log btw.  ;)

> Nit:
> 
> > +   if (cpu >= nr_cpu_ids)
> > +   cpu = cpumask_first(>cpus_have_tags);
> > +
> > +   if (cpu >= nr_cpu_ids)
> > +   BUG();
> 
> The second `if' can be moved inside the first, but hopefully the
> compiler already did that.

Fixed.

> 
> I have dim memories that doing
> 
>   local_irq_save()
>   spin_lock()
> 
> is not equivalent to
> 
>   spin_lock_irqsave()
> 
> in some circumstances.  Perhaps a lockdep thing.  Or perhaps this was fixed in
> the intervening years and this is no longer the case.

Mmmm, I had wondered the same thing on the release side with
kref_put_spinlock_irqsave() here before:

https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/include/linux/kref.h?id=ccf5ae83a6cf3d9cfe9a7038bfe7cd38ab03d5e1

but at some point was convinced it was not a issue anymore..
 
> 
> Such things probably won't be detected during 3.12-rcX because few
> people will test iscsi, I expect.  So please be sure that you've
> runtime tested it with all the lockdeppy things enabled. 
> Documentation/SubmitChecklist section 12 has a list, but it might be
> dated.



FYI, my v3.11-rc5 kernel has been running with CONFIG_LOCKDEP_SUPPORT=y
using vhost/iscsi/iser fabrics on the -v5 patch, and not generated any
warnings (yet).

I'll double check against the other debug options in Section 12.

Thank you,

--nab

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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: [E1000-devel] [PATCH 0/4] i40e: Neatening and object size reductions

[Joe Perches]

On Wed, 2013-09-04 at 01:00 +000, Nelson, Shannon wrote:
> we hadn't noticed the new experimental "--fix" option before.  There
> are a lot of good suggestions there, but obviously it needs a lot of
> reading and tweaking before it can be used.

Yes, I think --fix works best on patches.

When you use -f and --fix together, it can do inappropriate things.

Using multiple passes of -f --fix --types= and
changing the "ONE_SPECIFIC_TYPE" can produce more reasonable patch
sequences.

If you do try it, and please remember it is experimental, do let me
know how well it works or doesn't work for you all.

Bug reports (and patches) welcome.

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/

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

[Stephen Rothwell]

Hi all,

Today's linux-next merge of the tip tree got a conflict in
arch/x86/include/asm/spinlock.h between commit bc08b449ee14 ("lockref:
implement lockless reference count updates using cmpxchg()") from Linus'
tree and commit 545ac13892ab ("x86, spinlock: Replace pv spinlocks with
pv ticketlocks") from the tip tree.

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

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

diff --cc arch/x86/include/asm/spinlock.h
index e0e6684,8963bfe..000
--- a/arch/x86/include/asm/spinlock.h
+++ b/arch/x86/include/asm/spinlock.h
@@@ -34,11 -37,31 +37,36 @@@
  # define UNLOCK_LOCK_PREFIX
  #endif
  
 +static __always_inline int arch_spin_value_unlocked(arch_spinlock_t lock)
 +{
 +  return lock.tickets.head == lock.tickets.tail;
 +}
 +
+ /* How long a lock should spin before we consider blocking */
+ #define SPIN_THRESHOLD(1 << 15)
+ 
+ extern struct static_key paravirt_ticketlocks_enabled;
+ static __always_inline bool static_key_false(struct static_key *key);
+ 
+ #ifdef CONFIG_PARAVIRT_SPINLOCKS
+ 
+ static inline void __ticket_enter_slowpath(arch_spinlock_t *lock)
+ {
+   set_bit(0, (volatile unsigned long *)>tickets.tail);
+ }
+ 
+ #else  /* !CONFIG_PARAVIRT_SPINLOCKS */
+ static __always_inline void __ticket_lock_spinning(arch_spinlock_t *lock,
+   __ticket_t ticket)
+ {
+ }
+ static inline void __ticket_unlock_kick(arch_spinlock_t *lock,
+   __ticket_t ticket)
+ {
+ }
+ 
+ #endif /* CONFIG_PARAVIRT_SPINLOCKS */
+ 
  /*
   * Ticket locks are conceptually two parts, one indicating the current head of
   * the queue, and the other indicating the current tail. The lock is acquired


pgpIH71TunXTN.pgp
Description: PGP signature

[PATCH 1/3] thermal: samsung: correct the fall interrupt en, status bit fields

[Naveen Krishna Chatradhi]

The FALL interrupt related en, status bits are available at an offset of
16 on INTEN, INTSTAT registers and at an offset of
12 on INTCLEAR register.

This patch corrects the same for exyns5250 and exynos5440

Signed-off-by: Naveen Krishna Chatradhi 
---

Changes since v1:
  None

 drivers/thermal/samsung/exynos_tmu.c  |2 +-
 drivers/thermal/samsung/exynos_tmu.h  |2 ++
 drivers/thermal/samsung/exynos_tmu_data.c |2 ++
 drivers/thermal/samsung/exynos_tmu_data.h |3 ++-
 4 files changed, 7 insertions(+), 2 deletions(-)

diff --git a/drivers/thermal/samsung/exynos_tmu.c 
b/drivers/thermal/samsung/exynos_tmu.c
index ec01dfe..d201ed8 100644
--- a/drivers/thermal/samsung/exynos_tmu.c
+++ b/drivers/thermal/samsung/exynos_tmu.c
@@ -265,7 +265,7 @@ skip_calib_data:
data->base + reg->threshold_th1);
 
writel((reg->inten_rise_mask << reg->inten_rise_shift) |
-   (reg->inten_fall_mask << reg->inten_fall_shift),
+   (reg->inten_fall_mask << reg->intclr_fall_shift),
data->base + reg->tmu_intclear);
 
/* if last threshold limit is also present */
diff --git a/drivers/thermal/samsung/exynos_tmu.h 
b/drivers/thermal/samsung/exynos_tmu.h
index b364c9e..7c6c34a 100644
--- a/drivers/thermal/samsung/exynos_tmu.h
+++ b/drivers/thermal/samsung/exynos_tmu.h
@@ -134,6 +134,7 @@ enum soc_type {
  * @inten_fall3_shift: shift bits of falling 3 interrupt bits.
  * @tmu_intstat: Register containing the interrupt status values.
  * @tmu_intclear: Register for clearing the raised interrupt status.
+ * @intclr_fall_shift: shift bits for interrupt clear fall 0
  * @emul_con: TMU emulation controller register.
  * @emul_temp_shift: shift bits of emulation temperature.
  * @emul_time_shift: shift bits of emulation time.
@@ -204,6 +205,7 @@ struct exynos_tmu_registers {
u32 tmu_intstat;
 
u32 tmu_intclear;
+   u32 intclr_fall_shift;
 
u32 emul_con;
u32 emul_temp_shift;
diff --git a/drivers/thermal/samsung/exynos_tmu_data.c 
b/drivers/thermal/samsung/exynos_tmu_data.c
index 9002499..23fea23 100644
--- a/drivers/thermal/samsung/exynos_tmu_data.c
+++ b/drivers/thermal/samsung/exynos_tmu_data.c
@@ -122,6 +122,7 @@ static const struct exynos_tmu_registers 
exynos5250_tmu_registers = {
.inten_fall0_shift = EXYNOS_TMU_INTEN_FALL0_SHIFT,
.tmu_intstat = EXYNOS_TMU_REG_INTSTAT,
.tmu_intclear = EXYNOS_TMU_REG_INTCLEAR,
+   .intclr_fall_shift = EXYNOS_TMU_CLEAR_FALL_INT_SHIFT,
.emul_con = EXYNOS_EMUL_CON,
.emul_temp_shift = EXYNOS_EMUL_DATA_SHIFT,
.emul_time_shift = EXYNOS_EMUL_TIME_SHIFT,
@@ -210,6 +211,7 @@ static const struct exynos_tmu_registers 
exynos5440_tmu_registers = {
.inten_fall0_shift = EXYNOS5440_TMU_INTEN_FALL0_SHIFT,
.tmu_intstat = EXYNOS5440_TMU_S0_7_IRQ,
.tmu_intclear = EXYNOS5440_TMU_S0_7_IRQ,
+   .intclr_fall_shift = EXYNOS_TMU_CLEAR_FALL_INT_SHIFT,
.tmu_irqstatus = EXYNOS5440_TMU_IRQ_STATUS,
.emul_con = EXYNOS5440_TMU_S0_7_DEBUG,
.emul_temp_shift = EXYNOS_EMUL_DATA_SHIFT,
diff --git a/drivers/thermal/samsung/exynos_tmu_data.h 
b/drivers/thermal/samsung/exynos_tmu_data.h
index dc7feb5..8788a87 100644
--- a/drivers/thermal/samsung/exynos_tmu_data.h
+++ b/drivers/thermal/samsung/exynos_tmu_data.h
@@ -69,9 +69,10 @@
 #define EXYNOS_TMU_RISE_INT_MASK   0x111
 #define EXYNOS_TMU_RISE_INT_SHIFT  0
 #define EXYNOS_TMU_FALL_INT_MASK   0x111
-#define EXYNOS_TMU_FALL_INT_SHIFT  12
+#define EXYNOS_TMU_FALL_INT_SHIFT  16
 #define EXYNOS_TMU_CLEAR_RISE_INT  0x111
 #define EXYNOS_TMU_CLEAR_FALL_INT  (0x111 << 12)
+#define EXYNOS_TMU_CLEAR_FALL_INT_SHIFT12
 #define EXYNOS_TMU_TRIP_MODE_SHIFT 13
 #define EXYNOS_TMU_TRIP_MODE_MASK  0x7
 #define EXYNOS_TMU_THERM_TRIP_EN_SHIFT 12
-- 
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 2/3] thermal: samsung: change base_common to more meaningful base_second

[Naveen Krishna Chatradhi]

On Exynos5440 and Exynos5420 there are registers common
across the TMU channels.

To support that, we introduced a ADDRESS_MULTIPLE flag in the
driver and the 2nd set of register base and size are provided
in the "reg" property of the node.

As per Amit's suggestion, this patch changes the base_common
to base_second and SHARED_MEMORY to ADDRESS_MULTIPLE.

Signed-off-by: Naveen Krishna Chatradhi 
---
Changes since v2:
Changed the flag name from SHARED_MEMORY to ADDRESS_MULTIPLE.
https://lkml.org/lkml/2013/8/1/38

 .../devicetree/bindings/thermal/exynos-thermal.txt |4 ++--
 drivers/thermal/samsung/exynos_tmu.c   |   12 ++--
 drivers/thermal/samsung/exynos_tmu.h   |4 ++--
 drivers/thermal/samsung/exynos_tmu_data.c  |2 +-
 4 files changed, 11 insertions(+), 11 deletions(-)

diff --git a/Documentation/devicetree/bindings/thermal/exynos-thermal.txt 
b/Documentation/devicetree/bindings/thermal/exynos-thermal.txt
index 284f530..116cca0 100644
--- a/Documentation/devicetree/bindings/thermal/exynos-thermal.txt
+++ b/Documentation/devicetree/bindings/thermal/exynos-thermal.txt
@@ -11,8 +11,8 @@
 - reg : Address range of the thermal registers. For soc's which has multiple
instances of TMU and some registers are shared across all TMU's like
interrupt related then 2 set of register has to supplied. First set
-   belongs to each instance of TMU and second set belongs to common TMU
-   registers.
+   belongs to each instance of TMU and second set belongs to second set
+   of common TMU registers.
 - interrupts : Should contain interrupt for thermal system
 - clocks : The main clock for TMU device
 - clock-names : Thermal system clock name
diff --git a/drivers/thermal/samsung/exynos_tmu.c 
b/drivers/thermal/samsung/exynos_tmu.c
index d201ed8..3a55caf 100644
--- a/drivers/thermal/samsung/exynos_tmu.c
+++ b/drivers/thermal/samsung/exynos_tmu.c
@@ -41,7 +41,7 @@
  * @id: identifier of the one instance of the TMU controller.
  * @pdata: pointer to the tmu platform/configuration data
  * @base: base address of the single instance of the TMU controller.
- * @base_common: base address of the common registers of the TMU controller.
+ * @base_second: base address of the common registers of the TMU controller.
  * @irq: irq number of the TMU controller.
  * @soc: id of the SOC type.
  * @irq_work: pointer to the irq work structure.
@@ -56,7 +56,7 @@ struct exynos_tmu_data {
int id;
struct exynos_tmu_platform_data *pdata;
void __iomem *base;
-   void __iomem *base_common;
+   void __iomem *base_second;
int irq;
enum soc_type soc;
struct work_struct irq_work;
@@ -297,7 +297,7 @@ skip_calib_data:
}
/*Clear the PMIN in the common TMU register*/
if (reg->tmu_pmin && !data->id)
-   writel(0, data->base_common + reg->tmu_pmin);
+   writel(0, data->base_second + reg->tmu_pmin);
 out:
clk_disable(data->clk);
mutex_unlock(>lock);
@@ -451,7 +451,7 @@ static void exynos_tmu_work(struct work_struct *work)
 
/* Find which sensor generated this interrupt */
if (reg->tmu_irqstatus) {
-   val_type = readl(data->base_common + reg->tmu_irqstatus);
+   val_type = readl(data->base_second + reg->tmu_irqstatus);
if (!((val_type >> data->id) & 0x1))
goto out;
}
@@ -582,7 +582,7 @@ static int exynos_map_dt_data(struct platform_device *pdev)
 * Check if the TMU shares some registers and then try to map the
 * memory of common registers.
 */
-   if (!TMU_SUPPORTS(pdata, SHARED_MEMORY))
+   if (!TMU_SUPPORTS(pdata, ADDRESS_MULTIPLE))
return 0;
 
if (of_address_to_resource(pdev->dev.of_node, 1, )) {
@@ -590,7 +590,7 @@ static int exynos_map_dt_data(struct platform_device *pdev)
return -ENODEV;
}
 
-   data->base_common = devm_ioremap(>dev, res.start,
+   data->base_second = devm_ioremap(>dev, res.start,
resource_size());
if (!data->base) {
dev_err(>dev, "Failed to ioremap memory\n");
diff --git a/drivers/thermal/samsung/exynos_tmu.h 
b/drivers/thermal/samsung/exynos_tmu.h
index 7c6c34a..ebd2ec1 100644
--- a/drivers/thermal/samsung/exynos_tmu.h
+++ b/drivers/thermal/samsung/exynos_tmu.h
@@ -59,7 +59,7 @@ enum soc_type {
  * state(active/idle) can be checked.
  * TMU_SUPPORT_EMUL_TIME - This features allows to set next temp emulation
  * sample time.
- * TMU_SUPPORT_SHARED_MEMORY - This feature tells that the different TMU
+ * TMU_SUPPORT_ADDRESS_MULTIPLE - This feature tells that the different TMU
  * sensors shares some common registers.
  * TMU_SUPPORT - macro to compare the above features with the supplied.
  */
@@ -69,7 +69,7 @@ enum soc_type {
 #define 

[PATCH 3/3] thermal: samsung: Add TMU support for Exynos5420 SoCs

[Naveen Krishna Chatradhi]

This patch adds the neccessary register changes and arch information
to support Exynos5420 SoCs
Exynos5420 has 5 TMU channels one for each CPU 0, 1, 2 and 3 and GPU

Also updated the Documentation at
Documentation/devicetree/bindings/thermal/exynos-thermal.txt

Note: The platform data structure will be handled properly once the driver
 moves to complete device driver solution.

Signed-off-by: Naveen Krishna Chatradhi 
---
Changes since v1:
1. modified the platform data structure in order to pass SHARED flag
   for channels that need sharing of address space.
2. https://lkml.org/lkml/2013/8/1/38 is merged into this patch.
   As the changes are minimum and can be added here.

 .../devicetree/bindings/thermal/exynos-thermal.txt |   39 ++
 drivers/thermal/samsung/exynos_tmu.c   |   14 ++-
 drivers/thermal/samsung/exynos_tmu.h   |1 +
 drivers/thermal/samsung/exynos_tmu_data.c  |  130 
 drivers/thermal/samsung/exynos_tmu_data.h  |7 ++
 5 files changed, 189 insertions(+), 2 deletions(-)

diff --git a/Documentation/devicetree/bindings/thermal/exynos-thermal.txt 
b/Documentation/devicetree/bindings/thermal/exynos-thermal.txt
index 116cca0..d70f2a4 100644
--- a/Documentation/devicetree/bindings/thermal/exynos-thermal.txt
+++ b/Documentation/devicetree/bindings/thermal/exynos-thermal.txt
@@ -7,12 +7,23 @@
   "samsung,exynos4210-tmu"
   "samsung,exynos5250-tmu"
   "samsung,exynos5440-tmu"
+  "samsung,exynos5420-tmu"
 - interrupt-parent : The phandle for the interrupt controller
 - reg : Address range of the thermal registers. For soc's which has multiple
instances of TMU and some registers are shared across all TMU's like
interrupt related then 2 set of register has to supplied. First set
belongs to each instance of TMU and second set belongs to second set
of common TMU registers.
+  NOTE: On Exynos5420, the TRIMINFO register is misplaced for TMU
+   channels 2, 3 and 4
+
+   TRIMINFO at 0x1006c000 contains data for TMU channel 3
+   TRIMINFO at 0x100a contains data for TMU channel 4
+   TRIMINFO at 0x10068000 contains data for TMU channel 2
+
+   The misplaced register address is passed through devicetree as the
+   second base
+
 - interrupts : Should contain interrupt for thermal system
 - clocks : The main clock for TMU device
 - clock-names : Thermal system clock name
@@ -43,6 +54,34 @@ Example 2):
clock-names = "tmu_apbif";
};
 
+Example 3): (In case of Exynos5420)
+   /* tmu for CPU2 */
+   tmu@10068000 {
+   compatible = "samsung,exynos5420-tmu";
+   reg = <0x10068000 0x100>, <0x1006c000 0x4>;
+   interrupts = <0 184 0>;
+   clocks = < 318>;
+   clock-names = "tmu_apbif";
+   };
+
+   /* tmu for CPU3 */
+   tmu@1006c000 {
+   compatible = "samsung,exynos5420-tmu";
+   reg = <0x1006c000 0x100>, <0x100a 0x4>;
+   interrupts = <0 185 0>;
+   clocks = < 318>;
+   clock-names = "tmu_apbif";
+   };
+
+   /* tmu for GPU */
+   tmu@100a {
+   compatible = "samsung,exynos5420-tmu";
+   reg = <0x100a 0x100>, <0x10068000 0x4>;
+   interrupts = <0 215 0>;
+   clocks = < 318>;
+   clock-names = "tmu_apbif";
+   };
+
 Note: For multi-instance tmu each instance should have an alias correctly
 numbered in "aliases" node.
 
diff --git a/drivers/thermal/samsung/exynos_tmu.c 
b/drivers/thermal/samsung/exynos_tmu.c
index 3a55caf..6d34652 100644
--- a/drivers/thermal/samsung/exynos_tmu.c
+++ b/drivers/thermal/samsung/exynos_tmu.c
@@ -186,7 +186,12 @@ static int exynos_tmu_initialize(struct platform_device 
*pdev)
EXYNOS5440_EFUSE_SWAP_OFFSET + reg->triminfo_data);
}
} else {
-   trim_info = readl(data->base + reg->triminfo_data);
+   /* On exynos5420 the triminfo register is in the shared space */
+   if (data->base_second && (data->soc == SOC_ARCH_EXYNOS5420))
+   trim_info = readl(data->base_second +
+   reg->triminfo_data);
+   else
+   trim_info = readl(data->base + reg->triminfo_data);
}
data->temp_error1 = trim_info & EXYNOS_TMU_TEMP_MASK;
data->temp_error2 = ((trim_info >> reg->triminfo_85_shift) &
@@ -499,6 +504,10 @@ static const struct of_device_id exynos_tmu_match[] = {
.compatible = "samsung,exynos5440-tmu",
.data = (void *)EXYNOS5440_TMU_DRV_DATA,
},
+   {
+   .compatible = "samsung,exynos5420-tmu",
+   .data = (void *)EXYNOS5420_TMU_DRV_DATA,
+   },
{},
 };
 MODULE_DEVICE_TABLE(of, exynos_tmu_match);
@@ 

Re: [PATCH] Remove support for score architecture

[Guenter Roeck]

On 09/02/2013 09:54 PM, Liqin Chen wrote:


2013/9/3 Guenter Roeck mailto:li...@roeck-us.net>>

On 09/02/2013 08:18 AM, Lennox Wu wrote:

Before we start the development of the S+core, Sunplus had licensed
ARM and MIPS. We develop S+core for other reason such as the price.
Some products on the web of Sunplus adopt S+core , for example
the SPV7050.(http://w3.sunplus.__com/products/spv7050.asp 
) These products
could still be bought from the market. Some high-end products adopt
ARM or MIPS. So, there is no conflict for a company adopts multiple
architectures.

As I said, we recognize that we rarely update because of the limited
applications and rare requests from customers. Maybe we don’t
understand the culture enough; we think that it is unnecessary if we
have no new bugs or new functions, the thought seems wrong. We can
commit some patches in the near future.


The point is not about submitting patches, it is about maintaining the code.
Even if you don't add functionality, one would expect that you ensure that
new kernel versions compile and run on your hardware.

Since January 2012, 68 patches have been applied to arch/score, pretty
much all of them addressing kernel API changes or global cleanup.
Only two of them got an Ack by one of the score maintainers.
This strongly suggests that you don't keep track of what is going on,
and at the very least raises the question if you do compile and test
new kernel versions on a regular basis. Even if you do, no one knows
about it, because 

As part of this process, I would expect the architecture maintainer to
accept incoming patches, test the same, and send pull requests to Linus.
The last time this happened was early 2011; since then all score patches
were sent to Linus through Andrew and a few other maintainers.
Actually, I don't see many signoffs from a score maintainer at all,
even from the very beginning.

As pointed out, the MAINTAINERS entry for score points to a
non-existing domain, as does the e-mail address of one of the
maintainers.

I would not call that "maintained".



Hi Al Viro, Guenter Roeck, Arnd Bergmann and all,

I still supports the S+core team to maintain their codes, although I
left sunplus co. in 2011.

I keep reading the mailing list and testing these patches for S+core,
I think the main problems are they have not echoed to any comments on
score's questions. Maybe they think the current situation is good
enough for their customers, and they don’t understand the rules of the
group enough. Even so, they should update score code to the latest
status, include my mail address.

We will discuss how to maintain the code of S+core. However, if all of
you and Linus also think the S+core should be removed from the
upstream, we will do it.



Trying to build gcc for score says:

*** Configuration score-unknown-elf is obsolete.
*** Specify --enable-obsolete to build it anyway.
*** Support will be REMOVED in the next major release of GCC,
*** unless a maintainer comes forward.

That does not sound very encouraging.

Guenter

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

Re: [RFC][PATCH 01/18 v2] ftrace: Add hash list to save RCU unsafe functions

[Paul E. McKenney]

On Tue, Sep 03, 2013 at 10:03:25PM -0400, Steven Rostedt wrote:
> On Tue, 3 Sep 2013 22:01:15 -0400
> Steven Rostedt  wrote:
> 
> > On Tue, 3 Sep 2013 18:24:04 -0700
> > "Paul E. McKenney"  wrote:
> > 
> > 
> > > >  static DEFINE_PER_CPU(unsigned long, ftrace_rcu_func);
> > > > @@ -588,15 +593,14 @@ static void
> > > >  ftrace_unsafe_callback(unsigned long ip, unsigned long parent_ip,
> > > >struct ftrace_ops *op, struct pt_regs *pt_regs)
> > > >  {
> > > > -   int bit;
> > > > -
> > > > +   /* Make sure we see disabled or not first */
> > > > +   smp_rmb();
> > > 
> > >   smp_mb__before_atomic_inc()?
> > > 
> > 
> > Ah, but this is before an atomic_read(), and not an atomic_inc(), thus
> > the normal smp_rmb() is still required.
> > 
> 
> Here's the changes against this one: 
> 
> diff --git a/kernel/trace/trace_functions.c b/kernel/trace/trace_functions.c
> index cdcf187..9e6902a 100644
> --- a/kernel/trace/trace_functions.c
> +++ b/kernel/trace/trace_functions.c
> @@ -569,14 +569,14 @@ void ftrace_unsafe_rcu_checker_disable(void)
>  {
>   atomic_inc(_unsafe_rcu_disabled);
>   /* Make sure the update is seen immediately */
> - smp_wmb();
> + smp_mb__after_atomic_inc();
>  }
> 
>  void ftrace_unsafe_rcu_checker_enable(void)
>  {
>   atomic_dec(_unsafe_rcu_disabled);
>   /* Make sure the update is seen immediately */
> - smp_wmb();
> + smp_mb__after_atomic_dec();
>  }
> 
>  static void
> 
> 
> 
> Which is nice, because the smp_mb() are now in the really slow path.

Looks good!

But now that I look at it more carefully, including the comments...
The smp_mb__after_atomic_dec() isn't going to make the update be seen
faster -- instead, it will guarantee that if some other CPU sees this
CPU's later write, then that CPU will also see the results of the
atomic_dec().

Thanx, Paul

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

Re: [RFC][PATCH 01/18 v2] ftrace: Add hash list to save RCU unsafe functions

[Paul E. McKenney]

On Tue, Sep 03, 2013 at 10:01:15PM -0400, Steven Rostedt wrote:
> On Tue, 3 Sep 2013 18:24:04 -0700
> "Paul E. McKenney"  wrote:
> 
> 
> > >  static DEFINE_PER_CPU(unsigned long, ftrace_rcu_func);
> > > @@ -588,15 +593,14 @@ static void
> > >  ftrace_unsafe_callback(unsigned long ip, unsigned long parent_ip,
> > >  struct ftrace_ops *op, struct pt_regs *pt_regs)
> > >  {
> > > - int bit;
> > > -
> > > + /* Make sure we see disabled or not first */
> > > + smp_rmb();
> > 
> > smp_mb__before_atomic_inc()?
> > 
> 
> Ah, but this is before an atomic_read(), and not an atomic_inc(), thus
> the normal smp_rmb() is still required.

Good point, color me blind, dazed, and confused.

Thanx, Paul

> -- Steve
> 
> > >   if (atomic_read(_unsafe_rcu_disabled))
> > >   return;
> > > 
> > >   preempt_disable_notrace();
> > > 
> 

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

Re: [PATCH 1/3] autofs4 - fix device ioctl mount lookup

[Ian Kent]

On Wed, 2013-09-04 at 11:53 +0800, Ian Kent wrote:
> On Wed, 2013-09-04 at 03:42 +0100, Al Viro wrote:
> > On Wed, Sep 04, 2013 at 03:26:17AM +0100, Al Viro wrote:
> > > I've applied slightly modified variant of Jeff's "vfs: allow umount to 
> > > handle
> > > mountpoints without revalidating them" (modified by just leaving the
> > > struct path filled with mountpoint and leaving the equivalent of 
> > > follow_mount()
> > > to caller) to the local queue and I'm pretty sure that it's what we want
> > > here as well.
> > 
> > ... and killed the modifications since the result ends up uglier for
> > caller(s) anyway.  Reapplied as-is.
> 
> But isn't that what's needed anyway?

Except for the question of following symlinks which is still bugging me.

Granted, the initial implementation (8d7b48e0) didn't check for a
symlink but probably should have and returned EINVAL if it found one.

That's because the whole process is driven by automount maps that have
specific paths, so needing to follow a symlink is an indication the
caller is doing something wrong.

It's probably not actually harmful to cater for it in kernel  though
the user will likely crash and burn some time later.

> 
> Looks like it fits with the existing code that walks back down looking
> for a match.
> 
> And that fits in with fixing the bug where we want the first match just
> means breaking out early. The match should be close to the top, if not
> the first then the second, for the common case.
> 
> Ian


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

Re: [PATCH 1/3] autofs4 - fix device ioctl mount lookup

[Ian Kent]

On Wed, 2013-09-04 at 03:42 +0100, Al Viro wrote:
> On Wed, Sep 04, 2013 at 03:26:17AM +0100, Al Viro wrote:
> > I've applied slightly modified variant of Jeff's "vfs: allow umount to 
> > handle
> > mountpoints without revalidating them" (modified by just leaving the
> > struct path filled with mountpoint and leaving the equivalent of 
> > follow_mount()
> > to caller) to the local queue and I'm pretty sure that it's what we want
> > here as well.
> 
> ... and killed the modifications since the result ends up uglier for
> caller(s) anyway.  Reapplied as-is.

But isn't that what's needed anyway?

Looks like it fits with the existing code that walks back down looking
for a match.

And that fits in with fixing the bug where we want the first match just
means breaking out early. The match should be close to the top, if not
the first then the second, for the common case.

Ian

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] dma-buf: Expose buffer size to userspace (v2)

[Christopher James Halse Rogers]

Each dma-buf has an associated size and it's reasonable for userspace
to want to know what it is.

Since userspace already has an fd, expose the size using the
size = lseek(fd, SEEK_END, 0); lseek(fd, SEEK_CUR, 0);
idiom.

v2: Added Daniel's sugeested documentation, with minor fixups

Signed-off-by: Christopher James Halse Rogers 

Reviewed-by: Daniel Vetter 
Tested-by: Daniel Vetter 
---
 Documentation/dma-buf-sharing.txt | 12 
 drivers/base/dma-buf.c| 28 
 2 files changed, 40 insertions(+)

diff --git a/Documentation/dma-buf-sharing.txt 
b/Documentation/dma-buf-sharing.txt
index 0b23261..849e982 100644
--- a/Documentation/dma-buf-sharing.txt
+++ b/Documentation/dma-buf-sharing.txt
@@ -407,6 +407,18 @@ Being able to mmap an export dma-buf buffer object has 2 
main use-cases:
interesting ways depending upong the exporter (if userspace starts depending
upon this implicit synchronization).
 
+Other Interfaces Exposed to Userspace on the dma-buf FD
+--
+
+- Since kernel 3.12 the dma-buf FD supports the llseek system call, but only
+  with offset=0 and whence=SEEK_END|SEEK_SET. SEEK_SET is supported to allow
+  the usual size discover pattern size = SEEK_END(0); SEEK_SET(0). Every other
+  llseek operation will report -EINVAL.
+
+  If llseek on dma-buf FDs isn't support the kernel will report -ESPIPE for all
+  cases. Userspace can use this to detect support for discovering the dma-buf
+  size using llseek.
+
 Miscellaneous notes
 ---
 
diff --git a/drivers/base/dma-buf.c b/drivers/base/dma-buf.c
index 6687ba7..c33a857 100644
--- a/drivers/base/dma-buf.c
+++ b/drivers/base/dma-buf.c
@@ -77,9 +77,36 @@ static int dma_buf_mmap_internal(struct file *file, struct 
vm_area_struct *vma)
return dmabuf->ops->mmap(dmabuf, vma);
 }
 
+static loff_t dma_buf_llseek(struct file *file, loff_t offset, int whence)
+{
+   struct dma_buf *dmabuf;
+   loff_t base;
+
+   if (!is_dma_buf_file(file))
+   return -EBADF;
+
+   dmabuf = file->private_data;
+
+   /* only support discovering the end of the buffer,
+  but also allow SEEK_SET to maintain the idiomatic
+  SEEK_END(0), SEEK_CUR(0) pattern */
+   if (whence == SEEK_END)
+   base = dmabuf->size;
+   else if (whence == SEEK_SET)
+   base = 0;
+   else
+   return -EINVAL;
+
+   if (offset != 0)
+   return -EINVAL;
+
+   return base + offset;
+}
+
 static const struct file_operations dma_buf_fops = {
.release= dma_buf_release,
.mmap   = dma_buf_mmap_internal,
+   .llseek = dma_buf_llseek,
 };
 
 /*
@@ -133,6 +160,7 @@ struct dma_buf *dma_buf_export_named(void *priv, const 
struct dma_buf_ops *ops,
dmabuf->exp_name = exp_name;
 
file = anon_inode_getfile("dmabuf", _buf_fops, dmabuf, flags);
+   file->f_mode |= FMODE_LSEEK;
 
dmabuf->file = file;
 
-- 
1.8.3.2

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

Re: [PATCH v4 5/5] clk: dt: binding for basic gate clock

[Haojian Zhuang]

On 31 August 2013 04:06, Stephen Warren  wrote:
> On 08/29/2013 07:45 PM, Haojian Zhuang wrote:
>> On 22 August 2013 13:53, Mike Turquette  wrote:
>>> Device Tree binding for the basic clock gate, plus the setup function to
>>> register the clock.  Based on the existing fixed-clock binding.
>>>
>>> A different approach to this was proposed in 2012[1] and a similar
>>> binding was proposed more recently[2] if anyone wants some extra
>>> reading.
>
>>> diff --git a/Documentation/devicetree/bindings/clock/gate-clock.txt 
>>> b/Documentation/devicetree/bindings/clock/gate-clock.txt
>
>>> +Binding for simple gate clock.
> ...
>>> +   clock_foo: clock_foo@4a008100 {
>>> +   compatible = "gate-clock";
>>> +   #clock-cells = <0>;
>>> +   clocks = <_bar>;
>>> +   reg = <0x4a008100 0x4>
>>> +   bit-shift = <3>
>>
>> There's some argument on my clock binding patch set of Hi3620.
>>
>> I defined each clock as one clock node and some of them are sharing one
>> register. Stephen attacked on this since it means multiple clock node sharing
>> one register.
>
> s/attacked/disagreed with/ I think:-)
>
>> Now the same thing also exists in Mike's patch. Mike's patch could also
>> support this behavior. And it's very common that one register is sharing 
>> among
>> multiple clocks in every SoC. Which one should I follow?
>
> I believe it's a matter of how the HW is structured.
>
> If the HW truly has segregated register regions for each individual
> clock, and is documented in a way that implies each individual clock is
> a separate HW module, then it makes sense to describe each clock as a
> separate DT node.
>
> However, if the HW simply has a "clock module" that provides many
> clocks, with inter-mingled registers all over the place, and is
> documented as a single module that generates lots of clocks, then it
> makes sense to describe that one module as a single DT node.
>
> In other words, the DT representation should match the HW design and
> documentation.
>
> This is exactly why we have the #clock-cells property in DT; so that a
> clock provider can provide multiple clocks if that's the way the HW is
> designed.
>
>>> diff --git a/drivers/clk/clk-gate.c b/drivers/clk/clk-gate.c
>
>>> +void of_gate_clk_setup(struct device_node *node)
>>> +{
>>> +   struct clk *clk;
>>> +   const char *clk_name = node->name;
>>> +   void __iomem *reg;
>>> +   const char *parent_name;
>>> +   u8 clk_gate_flags = 0;
>>> +   u32 bit_idx = 0;
>>> +
>>> +   of_property_read_string(node, "clock-output-names", _name);
>>> +
>>> +   parent_name = of_clk_get_parent_name(node, 0);
>>> +
>>> +   reg = of_iomap(node, 0);
>>
>> I suggest not using of_iomap for each clock node.
>>
>> If each clock is one node, it means hundreds of clock node existing in
>> device tree. Hundreds of mapping page only cost unnecessary mapping.
>
> The page table entries will get re-used. I'm not familiar with the mm
> code, but multiple of_iomap() for the exact same range probably just map
> down to incrementing a refcount on some kernel data structure, so
> actually has zero overhead?

I think it's not right. Let check the implemenation in ioremap().

__arm_ioremap_pfn_caller():

/* try to reuse one of the static mapping whenever possible. */
svm = find_static_vm_paddr();
if (svm) {
 addr = svm->vm.addr;
 addr += paddr - svm->vm.phys_addr;
 return (void __iomem *)(offset + addr);
}
...

area = get_vm_area_caller(size, VM_IOREMAP, caller);
addr = area->addr;
ioremap_page_range(addr, addr+size, paddr, ..);

We can see that it'll try to find static mapping. What's the static mapping?
If we define iotable in machine driver, we have the static mapping, just like
debug_ll. If we parse everything from DTS file, it'll always get a new virtual
address from vm area. So it always create a new page mapping even for one
register.

>
>
>> Maybe we can resolve it by this way.
>>
>> DTS file:
>> clock register bank {
>
> You need a compatible value here, in order to instantiate the top-level
> driver for the "clock generator" HW block.
>
>> reg = <{start} {size}>;
>> #address-cells = <1>;
>> #size-cells = <0>; /* each clock only
>> exists in one register */
>
> You would need a ranges property here, to map the child reg properties
> into the parent node's address space.
>
>> clock node {
>> compatible = "xxx";
>> #clock-cells = <0>;
>> clock-output-names = yyy";
>> reg = <{offset}>;
>> ... other properties ...
>> };
>>  };
>
> That could be a reasonable solution; the existence of a single "clock
> generator" HW block is clearly called out by the existing of the
> top-level DT node, yet the internals of that 

Re: [PATCH 4/7] x86/pci: use pcie_cap to simplify code

[Bjorn Helgaas]

On Tue, Sep 03, 2013 at 03:35:12PM +0800, Yijing Wang wrote:
> PCI core saves PCIe Cap offset in pcie_cap,
> use pcie_cap to simplify code.
> 
> Signed-off-by: Yijing Wang 
> ---
>  arch/x86/pci/fixup.c |2 +-
>  1 files changed, 1 insertions(+), 1 deletions(-)
> 
> diff --git a/arch/x86/pci/fixup.c b/arch/x86/pci/fixup.c
> index f5809fa..ee8330d 100644
> --- a/arch/x86/pci/fixup.c
> +++ b/arch/x86/pci/fixup.c
> @@ -288,7 +288,7 @@ static void pcie_rootport_aspm_quirk(struct pci_dev *pdev)
>*/
>   list_for_each_entry(dev, >devices, bus_list) {
>   /* There are 0 to 8 devices attached to this bus */
> - cap_base = pci_find_capability(dev, PCI_CAP_ID_EXP);
> + cap_base = dev->pcie_cap;
>   quirk_aspm_offset[GET_INDEX(pdev->device, dev->devfn)] 
> = cap_base + 0x10;

This should use PCI_EXP_LNKCTL instead of "0x10".

>   }
>   pbus->ops = _pcie_aspm_ops;

This quirk replaces the config accessors with ones that silently ignore
writes to ASPM control bits.  That really warrants at least a dev_info()
note here, and we should be using pci_bus_set_ops().

Even that is a little bit dubious because I don't think this is really
safe -- what happens if this quirk replaces the ops, then somebody
else replaces the ops again?  aer_inject.c at least keeps track of
the old ops and seems to fall back to them, but it seems fragile to
depend on every caller of pci_bus_set_ops() to do the right thing
there.

But this is beyond the scope of your patch, so if you just
add a dev_info() note and use pci_bus_set_ops(), that should be
enough for now.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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: Re: [PATCH] USB2NET : SR9700 : One chip USB 1.1 USB2NETSR9700Device Driver Support

[liujunliang_ljl]

Dear David Miller ：

Thanks a lot.

I'm sorry that I just wonder to know which kernel 
version will release this driver, thanks again. 


2013-09-04 



liujunliang_ljl 



发件人： David Miller 
发送时间： 2013-09-04  10:27:14 
收件人： liujunliang_ljl 
抄送： horms; joe; romieu; gregkh; netdev; linux-usb; linux-kernel; sunhecheng 
主题： Re: [PATCH] USB2NET : SR9700 : One chip USB 1.1 USB2NETSR9700Device Driver 
Support 
 
From: liujunliang_...@163.com
Date: Sun,  1 Sep 2013 19:38:08 +0800
> From: Liu Junliang 
> 
> Signed-off-by: Liu Junliang 
Applied, thanks.
N�Р骒r��yb�X�肚�v�^�)藓{.n�+�伐�{��赙zXФ�≤�}��财�z�:+v�����赙zZ+��+zf＂�h���~i���z��wア�?�ㄨ��&�)撷f��^j谦y�m��@A�a囤�
0鹅h���i

Re: [PATCH V3 0/6] vhost code cleanup and minor enhancement

[David Miller]

From: Jason Wang 
Date: Mon,  2 Sep 2013 16:40:55 +0800

> This series tries to unify and simplify vhost codes especially for
> zerocopy. With this series, 5% - 10% improvement for per cpu throughput were
> seen during netperf guest sending test.
> 
> Plase review.

Applied and patch #5 queued up for -stable, thanks.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 1/3] autofs4 - fix device ioctl mount lookup

[Ian Kent]

On Tue, 2013-09-03 at 19:18 -0700, Linus Torvalds wrote:
> On Tue, Sep 3, 2013 at 7:00 PM, Al Viro  wrote:
> >
> > That aside, I'm really not happy with this kind of games; this stuff clearly
> > belongs in fs/namei.c where we can simply see the last component.  Doing 
> > that
> > on the level of "let's scan the pathname for slashes, etc." is just plain
> > wrong.  Let's step back for a minute here; what are you trying to do?
> > You have a pathname that should resolve to a mountpoint, without triggering
> > automount (or crossing into the mountpoint, for that matter) and you want
> > struct path for the bottom of that mount stack?  Or is it something
> > completely different?
> 
> Can we add a LOOKUP_NOAUTOMNT bit or something (not exposed to user
> space, only used for this particular kern_path() call). Then, if/when
> automount gets called recursively (through autofs4_lookup? Or is it
> just the autofs4_d_automount() interface?) it can just decide to not
> follow that last path.
> 
> Hmm? I don't think we pass in the lookup-flags to d_automount, but
> that could be changed. Yes?

We don't need to.

Al is completely right, Jeff's umount path lookup patch will cover all
the needed cases, AFAICS.

That's a relief.

> 
>  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 1/3] autofs4 - fix device ioctl mount lookup

[Al Viro]

On Wed, Sep 04, 2013 at 03:26:17AM +0100, Al Viro wrote:
> I've applied slightly modified variant of Jeff's "vfs: allow umount to handle
> mountpoints without revalidating them" (modified by just leaving the
> struct path filled with mountpoint and leaving the equivalent of 
> follow_mount()
> to caller) to the local queue and I'm pretty sure that it's what we want
> here as well.

... and killed the modifications since the result ends up uglier for
caller(s) anyway.  Reapplied as-is.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] kernel/rcutree.c: deem to be lazy if there are no callbacks.

[Chen Gang F T]

On 09/04/2013 03:36 AM, Paul E. McKenney wrote:
> On Mon, Aug 26, 2013 at 10:21:18AM +0800, Chen Gang F T wrote:
>>
>> Firstly, thank you for your reply with these details. 
>>
>> On 08/26/2013 03:18 AM, Paul E. McKenney wrote:
>>> On Thu, Aug 22, 2013 at 11:01:53AM +0800, Chen Gang wrote:
 On 08/21/2013 10:23 PM, Paul E. McKenney wrote:
> On Wed, Aug 21, 2013 at 01:59:29PM +0800, Chen Gang wrote:
>>>
>>> [ . . . ]
>>>
> Don't get me wrong, I do welcome appropriate patches.  In fact, if
> you look at RCU's git history, you will see that I frequently accept
> patches from a fair number of people.  And if you were willing to
> invest some time and thought, you might eventually be able to generate
> an appropriate (albeit low priority) patch to this function.  However,
> you seem to be motivated to submit small patches with a minimum of
> thought and preparation, perhaps because you need to meet some external
> or self-imposed quota of accepted patches.  And if you are in fact driven
> by a quota that prevents you from taking the time required to carefully
> think things through, you are wasting your time with RCU.

 Hmm... at least, some contents you said above is correct to me.

 At least, I should provide 10 patches per month, it is a necessary
 basic requirement to me.
>>>
>>> OK, that does help explain the otherwise inexplicable approach you have
>>> been taking.  Let's see how you have been doing, based on committer date
>>> in Linus's tree:
>>>
>>>   1 2012-11
>>>  15 2013-01
>>>   7 2013-02
>>>  20 2013-03
>>>  21 2013-04
>>>  12 2013-05
>>>  17 2013-06
>>>  10 2013-07
>>>
>>> The last few months might be understated a bit due to patches
>>> still being in maintainer trees.  This is a nice contrast from my
>>> first impression of you from https://lkml.org/lkml/2013/6/9/64 and
>>> https://lkml.org/lkml/2013/8/19/650, neither of which gave me any
>>> reason to trust your work, to put it mildly.  And if I cannot trust
>>> your work, I obviously cannot accept your patches.
>>>
>>
>> Hmm... better to check patches independent personal feelings (trust
>> some one, or not).
>>
>> ;-)
> 
> Believe me, I judged based on your first two patches!  Those were my
> first impression of you.
> 

OK, I can understand.


>>> You do seem to select for localized bug fixes, which require less work
>>> than the performance-motivated patches you were putting forward earlier
>>> in this thread.  With a localized bug, you demonstrate the bug, show the
>>> fix, and that is that.  From what I can see, part of the problem with
>>> your patches in this email thread is that you are trying to move from
>>> localized bug fixes to performance issues without doing the additional
>>> work required.  Please see below for a rough outline of this additional
>>> work.
>>>
>>
>> Hmm... it seems I need describe my work flow for fixing bugs in details.
>>
>>   1. Is it a bug ?
>>  if so, I can be marked as Reported-by and continue to 2nd.
>>  else, it is a waste mail.
>>
>>   2. Try to fix it in simple ways (so can save the maintainers time 
>> resource).
>>  if it can be accepted by maintainers, it is OK (I can be Signed-off-by).
>>  else need continue to 3rd.
>>
>>exception: if I can not find a simple way to fix it, I will send 
>> [Suggestion] mail.
>>
>>   3. Do the maintainers know how to fix it ?
>>  if yes, fix it together with maintainers (may mark me only as 
>> Reported-by).
>>  else need continue to Last.
>>
>>   Last: I should analyze it and fix it (it is my duty to fix it).
>>
>>
>> How do you feel about this work flow ? welcome any suggestions or
>> completions.
> 
> I am surprised that there are no testing or validation steps.
> 

Hmm... "fix it together" in 3rd step, may include test.

And for the 'Last' (I should analyze it and fix it, if maintainers do
not know either or lack of maintainers), your original information is
very good reference.

Our mailing list is also developing mailing list (it is not only result
report mailing list, or integration mailing list), so I can develop and
test with anther maintainers in mailing list (not only myself).


Thanks.

> Especially if you ever want to progress to more complex fixes, your life
> will be easier if you do some testing where feasible.  As might your
> maintainers' lives: Any bug your testing catches is one buggy patch that
> the maintainers do not need to look at.
> 

Yeah. that the reason why I have planned to do something for LTP (Linux
Test Project) in 2nd half of 2013 (some of my original mails mentioned
it).

  It will let "life will be more easier" especially for finding and solving 
more issues.

  my internal things within my company is also can be improved by more familiar 
with LTP.

  the precise time point for starting LTP: I have planned to start at 4th 
quarter of 2013 (2013-10-01).


"LTP + GCC + Reading code" will be my mainly 

Re: [PATCH 1/7] scsi/bfa: use pcie_capability_xxx to simplify code

[Bjorn Helgaas]

On Tue, Sep 3, 2013 at 5:34 PM, Bjorn Helgaas  wrote:
> On Tue, Sep 03, 2013 at 03:35:09PM +0800, Yijing Wang wrote:
>> Pcie_capability_xxx() interfaces were introudced to
>> simplify code to access PCIe Cap config space. And
>> because PCI core saves the PCIe Cap offset in
>> set_pcie_port_type() when device is enumerated.
>> So we can use pci_is_pcie() instead.
>>
>> Signed-off-by: Yijing Wang 
>> Cc: Jiang Liu 
>> Cc: Anil Gurumurthy 
>> Cc: Vijaya Mohan Guvva 
>> Cc: "James E.J. Bottomley" 
>> Cc: linux-s...@vger.kernel.org
>> Cc: linux-kernel@vger.kernel.org
>> ---
>>  drivers/scsi/bfa/bfad.c |9 +++--
>>  1 files changed, 3 insertions(+), 6 deletions(-)
>>
>> diff --git a/drivers/scsi/bfa/bfad.c b/drivers/scsi/bfa/bfad.c
>> index 9611195..d726b81 100644
>> --- a/drivers/scsi/bfa/bfad.c
>> +++ b/drivers/scsi/bfa/bfad.c
>> @@ -767,7 +767,6 @@ bfad_pci_init(struct pci_dev *pdev, struct bfad_s *bfad)
>>
>>   /* Adjust PCIe Maximum Read Request Size */
>>   if (pcie_max_read_reqsz > 0) {
>> - int pcie_cap_reg;
>>   u16 pcie_dev_ctl;
>>   u16 mask = 0x;
>>
>> @@ -794,10 +793,8 @@ bfad_pci_init(struct pci_dev *pdev, struct bfad_s *bfad)
>>   break;
>>   }
>>
>> - pcie_cap_reg = pci_find_capability(pdev, PCI_CAP_ID_EXP);
>> - if (mask != 0x && pcie_cap_reg) {
>> - pcie_cap_reg += 0x08;
>> - pci_read_config_word(pdev, pcie_cap_reg, 
>> _dev_ctl);
>> + if (mask != 0x && pci_is_pcie(pdev)) {
>
> Please move the pci_is_pcie() test up to the
> "if (pcie_mas_read_reqsz ..." statement.  There's no point in doing
> the switch statement if this isn't a PCIe device.
>
>> + pcie_capability_read_word(pdev, PCI_EXP_DEVCTL, 
>> _dev_ctl);
>>   if ((pcie_dev_ctl & 0x7000) != mask) {

I forgot to mention that this 0x7000 constant should be
PCI_EXP_DEVCTL_READRQ instead.

>>   printk(KERN_WARNING "BFA[%s]: "
>>   "pcie_max_read_request_size is %d, "
>> @@ -806,7 +803,7 @@ bfad_pci_init(struct pci_dev *pdev, struct bfad_s *bfad)
>>   pcie_max_read_reqsz);
>>
>>   pcie_dev_ctl &= ~0x7000;
>> - pci_write_config_word(pdev, pcie_cap_reg,
>> + pcie_capability_write_word(pdev, 
>> PCI_EXP_DEVCTL,
>>   pcie_dev_ctl | mask);
>
> Please rework this to use pcie_set_readrq() instead of writing
> the capability directly.  If we write the capability directly, we
> risk writing a value that is incompatible with the MPS
> configuration done by the PCI core.
>
>>   }
>>   }
>> --
>> 1.7.1
>>
>>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH net-hext] wireless: scan: Remove comment to compare_ether_addr

[David Miller]

From: Joe Perches 
Date: Sun, 01 Sep 2013 15:48:27 -0700

> This function is being removed, so remove the reference to it.
> 
> Signed-off-by: Joe Perches 

Applied.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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-next] llc: Use normal etherdevice.h tests

[David Miller]

From: Joe Perches 
Date: Sun, 01 Sep 2013 13:11:55 -0700

> Convert the llc_ static inlines to the
> equivalents from etherdevice.h and remove
> the llc_ static inline functions.
> 
> llc_mac_null -> is_zero_ether_addr
> llc_mac_multicast -> is_multicast_ether_addr
> llc_mac_match -> ether_addr_equal
> 
> Signed-off-by: Joe Perches 

Applied.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] batman: Remove reference to compare_ether_addr

[David Miller]

From: Joe Perches 
Date: Sun, 01 Sep 2013 15:45:08 -0700

> This function is being removed, rename the reference.
> 
> Signed-off-by: Joe Perches 

Applied.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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 0/5] ARM: tegra: support for Trusted Foundations

[Alex Courbot]

On 09/04/2013 03:42 AM, Stephen Warren wrote:

On 08/29/2013 03:57 AM, Alexandre Courbot wrote:

New version revised according to comments received for v3. Hopefully
it will be good enough to be merged.


Aside from the small issue in patch 1/5, the series,
Reviewed-by: Stephen Warren 


Thanks! I have adressed the issues you mentioned and will submit v5 
soon. Despite the fact this adds some non-Tegra stuff, will you be able 
to take it into your tree, or should I ask someone else?

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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-next] drivers/net: Convert uses of compare_ether_addr to ether_addr_equal

[David Miller]

From: Joe Perches 
Date: Sun, 01 Sep 2013 11:51:23 -0700

> Use the new bool function ether_addr_equal to add
> some clarity and reduce the likelihood for misuse
> of compare_ether_addr for sorting.
> 
> Done via cocci script: (and a little typing)
 ...
> Signed-off-by: Joe Perches 

Applied, thanks 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/

Re: [PATCH] USB2NET : SR9700 : One chip USB 1.1 USB2NET SR9700Device Driver Support

[David Miller]

From: liujunliang_...@163.com
Date: Sun,  1 Sep 2013 19:38:08 +0800

> From: Liu Junliang 
> 
> Signed-off-by: Liu Junliang 

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

Re: [PATCH 1/3] autofs4 - fix device ioctl mount lookup

[Al Viro]

On Tue, Sep 03, 2013 at 07:18:42PM -0700, Linus Torvalds wrote:
> On Tue, Sep 3, 2013 at 7:00 PM, Al Viro  wrote:
> >
> > That aside, I'm really not happy with this kind of games; this stuff clearly
> > belongs in fs/namei.c where we can simply see the last component.  Doing 
> > that
> > on the level of "let's scan the pathname for slashes, etc." is just plain
> > wrong.  Let's step back for a minute here; what are you trying to do?
> > You have a pathname that should resolve to a mountpoint, without triggering
> > automount (or crossing into the mountpoint, for that matter) and you want
> > struct path for the bottom of that mount stack?  Or is it something
> > completely different?
> 
> Can we add a LOOKUP_NOAUTOMNT bit or something (not exposed to user
> space, only used for this particular kern_path() call). Then, if/when
> automount gets called recursively (through autofs4_lookup? Or is it
> just the autofs4_d_automount() interface?) it can just decide to not
> follow that last path.
> 
> Hmm? I don't think we pass in the lookup-flags to d_automount, but
> that could be changed. Yes?

No need, really - what we ought to do, AFAICS, is what umount(2) needs.
I've applied slightly modified variant of Jeff's "vfs: allow umount to handle
mountpoints without revalidating them" (modified by just leaving the
struct path filled with mountpoint and leaving the equivalent of follow_mount()
to caller) to the local queue and I'm pretty sure that it's what we want
here as well.

I'll push for-next tonight and send a pull request your way tomorrow, if you
are OK with that.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 1/3] autofs4 - fix device ioctl mount lookup

[Linus Torvalds]

On Tue, Sep 3, 2013 at 7:00 PM, Al Viro  wrote:
>
> That aside, I'm really not happy with this kind of games; this stuff clearly
> belongs in fs/namei.c where we can simply see the last component.  Doing that
> on the level of "let's scan the pathname for slashes, etc." is just plain
> wrong.  Let's step back for a minute here; what are you trying to do?
> You have a pathname that should resolve to a mountpoint, without triggering
> automount (or crossing into the mountpoint, for that matter) and you want
> struct path for the bottom of that mount stack?  Or is it something
> completely different?

Can we add a LOOKUP_NOAUTOMNT bit or something (not exposed to user
space, only used for this particular kern_path() call). Then, if/when
automount gets called recursively (through autofs4_lookup? Or is it
just the autofs4_d_automount() interface?) it can just decide to not
follow that last path.

Hmm? I don't think we pass in the lookup-flags to d_automount, but
that could be changed. Yes?

 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] ipv6: ipv6_create_tempaddr cleanup

[David Miller]

From: Petr Holasek 
Date: Fri, 30 Aug 2013 17:02:38 +0200

> This two-liner removes max_addresses variable which is now unecessary related
> to patch [ipv6: remove max_addresses check from ipv6_create_tempaddr].
> 
> Signed-off-by: Petr Holasek 

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

Re: [PATCH net-next] netconsole: avoid a crash with multiple sysfs writers

[David Miller]

From: Dan Aloni 
Date: Fri, 30 Aug 2013 13:59:46 +0300

> When my 'ifup eth' script was fired multiple times and ran concurrent on
> my laptop, for some obscure /etc scripting reason, it was revealed
> that the store_enabled() function in netconsole doesn't handle it nicely,
> as recorded by the Oops below (a syslog paste, but not mangled too much
> to prevent from discerning the traceback).
> 
> On Linux 3.10.4, this patch seeks to remedy the problem, and it has been
> running stable on my laptop for a few days.
 ...
> Signed-off-by: Dan Aloni 
> Signed-off-by: Neil Horman 

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

Re: [PATCH 07/11] x86, memblock: Set lowest limit for memblock_alloc_base_nid().

[Tang Chen]

On 09/04/2013 08:37 AM, Toshi Kani wrote:

On Tue, 2013-08-27 at 17:37 +0800, Tang Chen wrote:

memblock_alloc_base_nid() is a common API of memblock. And it calls
memblock_find_in_range_node() with %start = 0, which means it has no
limit for the lowest address by default.

memblock_find_in_range_node(0, max_addr, size, align, nid);

Since we introduced current_limit_low to memblock, if we have no limit
for the lowest address or we are not sure, we should pass
MEMBLOCK_ALLOC_ACCESSIBLE to %start so that it will be limited by the
default low limit.

dma_contiguous_reserve() and setup_log_buf() will eventually call
memblock_alloc_base_nid() to allocate memory. So if the allocation order
is from low to high, they will allocate memory from the lowest limit
to higher memory.


This requires the callers to use MEMBLOCK_ALLOC_ACCESSIBLE instead of 0.
Is there a good way to make sure that all callers will follow this rule
going forward?  Perhaps, memblock_find_in_range_node() should emit some
message if 0 is passed when current_order is low to high and the boot
option is specified?


How about set this as the default rule:

When using from low to high order, always allocate memory from
current_limit_low.

So far, I think only movablenode boot option will use this order.



Similarly, I wonder if we should have a check to the allocation size to
make sure that all allocations will stay small in this case.



We can check the size. But what is the stragety after we found that the 
size

is too large ?  Do we refuse to allocate memory ?  I don't think so.

I think only relocate_initrd() and reserve_crachkernel() could allocate 
large
memory. reserve_crachkernel() is easy to reorder, but reordering 
relocate_initrd()

is difficult because acpi_initrd_override() need to access to it with va.

I think on most servers, we don't need to do relocate_initrd(). initrd 
will be

loaded to mapped memory in normal situation. Can we just leave it there ?

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

Re: [RFC][PATCH 01/18 v2] ftrace: Add hash list to save RCU unsafe functions

[Steven Rostedt]

On Tue, 3 Sep 2013 22:01:15 -0400
Steven Rostedt  wrote:

> On Tue, 3 Sep 2013 18:24:04 -0700
> "Paul E. McKenney"  wrote:
> 
> 
> > >  static DEFINE_PER_CPU(unsigned long, ftrace_rcu_func);
> > > @@ -588,15 +593,14 @@ static void
> > >  ftrace_unsafe_callback(unsigned long ip, unsigned long parent_ip,
> > >  struct ftrace_ops *op, struct pt_regs *pt_regs)
> > >  {
> > > - int bit;
> > > -
> > > + /* Make sure we see disabled or not first */
> > > + smp_rmb();
> > 
> > smp_mb__before_atomic_inc()?
> > 
> 
> Ah, but this is before an atomic_read(), and not an atomic_inc(), thus
> the normal smp_rmb() is still required.
> 

Here's the changes against this one: 

diff --git a/kernel/trace/trace_functions.c b/kernel/trace/trace_functions.c
index cdcf187..9e6902a 100644
--- a/kernel/trace/trace_functions.c
+++ b/kernel/trace/trace_functions.c
@@ -569,14 +569,14 @@ void ftrace_unsafe_rcu_checker_disable(void)
 {
atomic_inc(_unsafe_rcu_disabled);
/* Make sure the update is seen immediately */
-   smp_wmb();
+   smp_mb__after_atomic_inc();
 }
 
 void ftrace_unsafe_rcu_checker_enable(void)
 {
atomic_dec(_unsafe_rcu_disabled);
/* Make sure the update is seen immediately */
-   smp_wmb();
+   smp_mb__after_atomic_dec();
 }
 
 static void



Which is nice, because the smp_mb() are now in the really slow path.

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

RE: [PATCH v4 3/3] dma: Add Freescale eDMA engine driver support

[Lu Jingchang-B35083]

> -Original Message-
> From: Vinod Koul [mailto:vinod.k...@intel.com]
> Sent: Tuesday, September 03, 2013 7:32 PM
> To: Lu Jingchang-B35083
> Cc: shawn@linaro.org; linux-kernel@vger.kernel.org; linux-arm-
> ker...@lists.infradead.org; devicet...@vger.kernel.org
> Subject: Re: [PATCH v4 3/3] dma: Add Freescale eDMA engine driver support
> 
> On Tue, Sep 03, 2013 at 05:43:21AM +, Lu Jingchang-B35083 wrote:
> >   Do you mean the DMA_SLAVE_CONFIG device_control? Yeah, the slave
> driver could pass
> > the slave_id. But the DMA_SLAVE_CONFIG may be called more than once,
> and the eDMA
> > driver just needs to set the slave id once for any given channel, after
> that the
> > transfer is transparent to the device.
> It depends, for a channel requested, if you are only tranferring to a
> particular
> slave device then it can be confugured once.
> so
> 1. allocate channel
> 2. dmaengine_slave_config()
> 
> then you cnan do preare etc multiple times based on need.
Yeah, I think we should just configure the slave id once and this would make the
configuration simply. But by debugging, I find the dmaengine_slave_config() may 
be
called more one times after requested by on user. So I put the slave id 
configuration
in the channel request phase. And the effect is the same for exclusive channel.
Thanks!


Best Regards,
Jingchang

Re: [RFC][PATCH 01/18 v2] ftrace: Add hash list to save RCU unsafe functions

[Steven Rostedt]

On Tue, 3 Sep 2013 18:24:04 -0700
"Paul E. McKenney"  wrote:


> >  static DEFINE_PER_CPU(unsigned long, ftrace_rcu_func);
> > @@ -588,15 +593,14 @@ static void
> >  ftrace_unsafe_callback(unsigned long ip, unsigned long parent_ip,
> >struct ftrace_ops *op, struct pt_regs *pt_regs)
> >  {
> > -   int bit;
> > -
> > +   /* Make sure we see disabled or not first */
> > +   smp_rmb();
> 
>   smp_mb__before_atomic_inc()?
> 

Ah, but this is before an atomic_read(), and not an atomic_inc(), thus
the normal smp_rmb() is still required.

-- Steve

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

Re: [PATCH 1/3] autofs4 - fix device ioctl mount lookup

[Al Viro]

On Wed, Sep 04, 2013 at 02:03:02AM +0100, Al Viro wrote:

> E...   NAK in that form.  Just what will happen if the last component
> given to that sucker will be . or .., for starters?  Or a symlink, with
> '/' added to it to force following the damn thing?

OK, in more details:
* we are changing a user-visible ABI here - kern_path() with
LOOKUP_FOLLOW had been there since the introduction of that misc
device (OK, it used to be path_lookup(), but that changes nothing).
IOW, we used to follow symlinks there, now we do not.
* pathname may end on more than one slash.  Modified that
way, the code won't do anything good (not to mention that d_lookup()
on an empty string is an interesting torture test for fs/dcache.c;
probably you'll just find nothing, but normally the function is never
called with such arguments, so...).  In any case it's an ABI change.
* pathname may end with something/. or something/..; again,
d_lookup() won't find you anything now, so we have an ABI change.

That aside, I'm really not happy with this kind of games; this stuff clearly
belongs in fs/namei.c where we can simply see the last component.  Doing that
on the level of "let's scan the pathname for slashes, etc." is just plain
wrong.  Let's step back for a minute here; what are you trying to do?
You have a pathname that should resolve to a mountpoint, without triggering
automount (or crossing into the mountpoint, for that matter) and you want
struct path for the bottom of that mount stack?  Or is it something
completely different?
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] kernel/rcutree.c: deem to be lazy if there are no callbacks.

[Chen Gang]

On 09/04/2013 01:59 AM, Paul E. McKenney wrote:
> On Tue, Sep 03, 2013 at 01:41:03PM +0800, Chen Gang wrote:
>> Hello Maintainers:
>>
>> Is this issue finished ?
>>
>> If need additional help from me (e.g. some test things, or others, if
>> you have no time, can let me try), please let me know, I should try.
> 
> Ah, sorry, here is the patch.
> 

Thanks.

:-)

>   Thanx, Paul
> 
> 
> 
> rcu: Micro-optimize rcu_cpu_has_callbacks()
> 
> The for_each_rcu_flavor() loop unconditionally scans all flavors, even
> when the first flavor might have some non-lazy callbacks.  Once the
> loop has seen a non-lazy callback, further passes through the loop
> cannot change the state.  This is not a huge problem, given that there
> can be at most three RCU flavors (RCU-bh, RCU-preempt, and RCU-sched),
> but this code is on the path to idle, so speeding it up even a small
> amount would have some benefit.
> 
> This commit therefore does two things:
> 
> 1.Rearranges the order of the list of RCU flavors in order to
>   place the most active flavor first in the list.  The most active
>   RCU flavor is RCU-preempt, or, if there is no RCU-preempt,
>   RCU-sched.
> 
> 2.Reworks the for_each_rcu_flavor() to exit early when the first
>   non-lazy callback is seen, or, in the case where the caller
>   does not care about non-lazy callbacks (RCU_FAST_NO_HZ=n),
>   when the first callback is seen.
> 
> Reported-by: Chen Gang 
> Signed-off-by: Paul E. McKenney 
> 
> diff --git a/kernel/rcutree.c b/kernel/rcutree.c
> index b1b959d..38596be 100644
> --- a/kernel/rcutree.c
> +++ b/kernel/rcutree.c
> @@ -2756,10 +2756,13 @@ static int rcu_cpu_has_callbacks(int cpu, bool 
> *all_lazy)
>  
>   for_each_rcu_flavor(rsp) {
>   rdp = per_cpu_ptr(rsp->rda, cpu);
> - if (rdp->qlen != rdp->qlen_lazy)
> + if (!rdp->nxtlist)
> + continue;
> + hc = true;
> + if (rdp->qlen != rdp->qlen_lazy || !all_lazy) {
>   al = false;
> - if (rdp->nxtlist)
> - hc = true;
> + break;
> + }
>   }
>   if (all_lazy)
>   *all_lazy = al;
> @@ -3326,8 +3329,8 @@ void __init rcu_init(void)
>  
>   rcu_bootup_announce();
>   rcu_init_geometry();
> - rcu_init_one(_sched_state, _sched_data);
>   rcu_init_one(_bh_state, _bh_data);
> + rcu_init_one(_sched_state, _sched_data);
>   __rcu_init_preempt();
>   open_softirq(RCU_SOFTIRQ, rcu_process_callbacks);
>  
> 
> 
> 


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

Re: [RFC][PATCH 01/18 v2] ftrace: Add hash list to save RCU unsafe functions

[Steven Rostedt]

On Tue, 3 Sep 2013 21:51:52 -0400
Steven Rostedt  wrote:
 
> > >  void ftrace_unsafe_rcu_checker_disable(void)
> > >  {
> > >   atomic_inc(_unsafe_rcu_disabled);
> > > + /* Make sure the update is seen immediately */
> > > + smp_wmb();
> > 
> > smp_mb__after_atomic_inc()?
> 
> Yep.
> 
> > 
> > >  }
> > > 
> > >  void ftrace_unsafe_rcu_checker_enable(void)
> > >  {
> > >   atomic_dec(_unsafe_rcu_disabled);
> > > + /* Make sure the update is seen immediately */
> > > + smp_wmb();
> > 
> > smp_mb__after_atomic_dec()?
> 
> Yep.
> 
> > 
> > >  }
> > > 
> > >  static DEFINE_PER_CPU(unsigned long, ftrace_rcu_func);
> > > @@ -588,15 +593,14 @@ static void
> > >  ftrace_unsafe_callback(unsigned long ip, unsigned long parent_ip,
> > >  struct ftrace_ops *op, struct pt_regs *pt_regs)
> > >  {
> > > - int bit;
> > > -
> > > + /* Make sure we see disabled or not first */
> > > + smp_rmb();
> > 
> > smp_mb__before_atomic_inc()?
> 
> Yep.
> 
> I'll update it and restart my tests.
> 

Although, this will punish archs that need the mb(), as IIUC, smp_mb()
is heavier weight than smp_wmb() or smp_rmb().

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

Re: [tip:x86/smap] Introduce [compat_]save_altstack_ex() to unbreak x86 SMAP

[Stephen Rothwell]

On Tue, 03 Sep 2013 18:12:47 -0700 "H. Peter Anvin"  wrote:
>
> Header file dependency hell.

Ah, ok, thanks.

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


pgpCaVKqbKvqL.pgp
Description: PGP signature

Re: [PATCH v2 0/8] Drop support for Renesas H8/300 architecture

[Chen Gang F T]

Thank you for your valuable information: it will let kernel waste mails
less, and also can save my time resources.


On 09/04/2013 04:59 AM, Guenter Roeck wrote:
> On Tue, Sep 03, 2013 at 08:39:38PM +0100, Al Viro wrote:
>> On Tue, Sep 03, 2013 at 11:52:17AM +0800, Chen Gang F T wrote:
>>
>>>   extreme sample: let 'kernel code style' and 'gcc code style' in one file, 
>>> that will make the code very ugly.
>>
>> gcc style will make any code very ugly, no matter what (if anything) else is
>> in the same file...
>>

Hmm... for me, I don't check/judge the 'coding style' of different
products, what I focus on is to follow the original product 'coding
style'.

  e.g. Windows, gcc, Linux kernel, their 'coding styles' are quite different 
with each other.

  Originally I worked under Windows, I followed Windows coding style.
  Now I worked under Linux kernel, I follow Linux kernel coding style.
  I plan to make patch for gcc, I will follow gcc coding style.
(hope this month I can, but I am not sure, I have no experience for gcc 
development).

And excuse me, I will be silent during 2013-09-05 - 2013-09-20 (but can
response mail). During these days, I will focus on gcc issues (wish can
fix one), and also do some company's internal things.

Thanks.

>> [digs out the ports history table]
>> x86: 0.01[alive]
>>  i386:   0.01..2.6.24-rc1 [folded into x86]
>>  x86_64: 2.5.5-pre1..2.6.24-rc1 [folded into x86]
>>  x86:2.6.24-rc1  [alive]
>> alpha:   1.1.67  [alive]
>> sparc:   1.1.77  [alive]
>>  sparc64:2.1.19..2.6.28 [folded into sparc]
>> mips:1.1.82  [alive]
>>  mips64: 2.3.48-pre2..2.6.0-test2 [folded into mips]
>> powerpc: 1.3.45  [alive]
>>  ppc:1.3.45..2.6.26 [folded into powerpc]
>>  ppc64:  2.5.5..2.6.15-rc1 [folded into powerpc]
>>  powerpc:2.6.15-rc1  [alive]
>> m68k:1.3.94  [alive]
>>  m68knommu:  2.5.46..2.6.38 [folded into m68k]
>> arm: 2.1.80  [alive]
>>  arm26:  2.5.71..2.6.23-rc2 [gone]
>>  arm64:  3.7-rc1 [alive][might eventually fold]
>> sh:  2.3.16  [alive]
>>  sh64:   2.6.8-rc1..2.6.24 [folded into sh, nearly dead there]
>> ia64:2.3.43-pre1 [alive]
>> s390:2.3.99pre8  [alive]
>>  s390x:  2.5.0..2.5.67 [folded into s390]
>> parisc:  2.4.0-test12[alive]
>> cris:2.5.0   [alive]
>> um:  2.5.35  [alive]
>> v850:2.5.46..2.6.26 [gone]
>> h8300:   2.5.68  [moderately responsive]
>> m32r:2.6.9-rc3   [alive]
>> frv: 2.6.11-rc1  [alive]
>> xtensa:  2.6.13-rc1  [alive]
>> avr32:   2.6.19-rc1  [alive]
>> blackfin:2.6.22-rc1  [alive]
>> mn10300: 2.6.25-rc1  [alive]
>> microblaze:  2.6.30-rc2  [alive]
>> score:   2.6.32-rc1  [abandoned][cloned off mips]
>> tile:2.6.36-rc1  [alive]
>> unicore32:   2.6.39-rc1  [alive][cloned off arm]
>> openrisc:3.1-rc1 [alive]
>> hexagon: 3.2-rc1 [alive]
>> c6x: 3.3-rc1 [alive]
>> arc: 3.9-rc1 [alive]
>> metag:   3.9-rc1 [alive]
>>
>> Frankly, I would've expected score and lefotvers of sh64 (aka sh5) to be
>> the first against the wall - h8300 was a bit surprising...
>>
> 
> Great summary.
> 
> There seemed to be a consensus to remove h8300, at least so far and 
> sufficiently
> enough for me to ask Stephen to add the removal branch to linux-next.
> We'll see if that triggers any further responses.
> 
> With score, I am not entirely sure. I got one Ack for the removal, but
> on the other side the score maintainers came back and claimed they would
> still support it. We'll see if anything changes in practice. I am still
> not sure if I should ask for the removal branch to be added to linux-next.
> Frankly I thought I might jump the gun here more than with h8300.
> 
> Either case, what to ultimately do with those two architectures will be
> up to the community to decide.
> 
> Guenter
> 

Thanks again.

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

Re: [RFC][PATCH 01/18 v2] ftrace: Add hash list to save RCU unsafe functions

[Steven Rostedt]

On Tue, 3 Sep 2013 18:24:04 -0700
"Paul E. McKenney"  wrote:

> On Tue, Sep 03, 2013 at 07:57:05PM -0400, Steven Rostedt wrote:

> > Paul, can I still keep all your acks and reviewed-bys on this?
> 
> Yep, but some questions below.
> 
>   Thanx, Paul
> 
> > -- Steve
> > 
> > diff --git a/kernel/trace/ftrace.c b/kernel/trace/ftrace.c
> > index 310b727..899c8c1 100644
> > --- a/kernel/trace/ftrace.c
> > +++ b/kernel/trace/ftrace.c
> > @@ -1373,7 +1373,7 @@ ftrace_hash_rec_enable(struct ftrace_ops *ops, int 
> > filter_hash);
> > 
> >  static int ftrace_convert_size_to_bits(int size)
> >  {
> > -   int bits;
> > +   int bits = 0;
> > 
> > /*
> >  * Make the hash size about 1/2 the # found
> > diff --git a/kernel/trace/trace_functions.c b/kernel/trace/trace_functions.c
> > index f5a9031..0883069 100644
> > --- a/kernel/trace/trace_functions.c
> > +++ b/kernel/trace/trace_functions.c
> > @@ -561,16 +561,21 @@ static inline int init_func_cmd_traceon(void)
> > 
> >  #ifdef CONFIG_FTRACE_UNSAFE_RCU_CHECKER
> > 
> > +static DEFINE_PER_CPU(int, ftrace_rcu_running);
> >  static atomic_t ftrace_unsafe_rcu_disabled;
> > 
> >  void ftrace_unsafe_rcu_checker_disable(void)
> >  {
> > atomic_inc(_unsafe_rcu_disabled);
> > +   /* Make sure the update is seen immediately */
> > +   smp_wmb();
> 
>   smp_mb__after_atomic_inc()?

Yep.

> 
> >  }
> > 
> >  void ftrace_unsafe_rcu_checker_enable(void)
> >  {
> > atomic_dec(_unsafe_rcu_disabled);
> > +   /* Make sure the update is seen immediately */
> > +   smp_wmb();
> 
>   smp_mb__after_atomic_dec()?

Yep.

> 
> >  }
> > 
> >  static DEFINE_PER_CPU(unsigned long, ftrace_rcu_func);
> > @@ -588,15 +593,14 @@ static void
> >  ftrace_unsafe_callback(unsigned long ip, unsigned long parent_ip,
> >struct ftrace_ops *op, struct pt_regs *pt_regs)
> >  {
> > -   int bit;
> > -
> > +   /* Make sure we see disabled or not first */
> > +   smp_rmb();
> 
>   smp_mb__before_atomic_inc()?

Yep.

I'll update it and restart my tests.

Thanks!

-- Steve

> 
> > if (atomic_read(_unsafe_rcu_disabled))
> > return;
> > 
> > preempt_disable_notrace();
> > 
> > -   bit = trace_test_and_set_recursion(TRACE_FTRACE_START, 
> > TRACE_FTRACE_MAX);
> > -   if (bit < 0)
> > +   if (this_cpu_read(ftrace_rcu_running))
> > goto out;
> > 
> > if (WARN_ONCE(ftrace_rcu_unsafe(ip),
> > @@ -604,13 +608,15 @@ ftrace_unsafe_callback(unsigned long ip, unsigned 
> > long parent_ip,
> >   (void *)ip))
> > goto out;
> > 
> > +   this_cpu_write(ftrace_rcu_running, 1);
> > this_cpu_write(ftrace_rcu_func, ip);
> > +
> > /* Should trigger a RCU splat if called from unsafe RCU function */
> > rcu_read_lock();
> > rcu_read_unlock();
> > this_cpu_write(ftrace_rcu_func, 0);
> > 
> > -   trace_clear_recursion(bit);
> > +   this_cpu_write(ftrace_rcu_running, 0);
> >   out:
> > preempt_enable_notrace();
> >  }
> > 

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

Re: [RFC PATCH v1 1/1] powerpc/85xx: Wakeup kexec smp slave cpus in second kernel

[Yang,Wei]

On 08/31/2013 05:12 PM, Yu Chen wrote:

>From 1ccf579b871dfd5938ce958f729361a203485c74 Mon Sep 17 00:00:00 2001
From: Yu Chen 
Date: Sat, 31 Aug 2013 23:52:31 +0800
Subject: [PATCH]  powerpc/85xx: Wakeup kexec smp slave cpus in second kernel

In current 85xx smp kexec implementation,master cpu reset slave cpus
by mpic_reset_core,
before jump to second kernel.In order to wake slave cpus up in second
kernel,we debug
this patch on p2041rdb.


What problem causes that you do the modification? I am just curious as 
kexec feature always is fine on our

P2041RDB board.:-)

Wei


The main principle of this patch,is to get slave cpus polling for flag
to change,
thus waiting for master cpu to set it with non-zero cpu number(see misc_32.S).
This flag is placed in kexec control page,so it would not be
overlapped when copying kimage.
The master cpu put flag's physical address in r28 as a parameter
passed to second kernel,
so the latter knows how to wake slave cpus up in smp_85xx_kick_cpu.
The pseudo-code may be like:
void slave_cpu_spin(void)
{
 int cpu = smp_processor_id();
 while (*kexec_poll != cpu)
 ;
 /*slave wakeup and jump*/
 jump(*(kexec_poll+1));
}

void master_cpu_wakeup(unsigned long *kexec_poll, int cpu)
{
 *(kexec_poll+1) = __early_start;
 mb();
 *kexec_poll = cpu;
}

However,after applied this patch,we got some kernel exception during
booting second kernel,
I'm not sure if it's caused by improper treament of cache,or tlb,or
other.So I put this
patch here hoping someone can check and review it.

Signed-off-by: Yu Chen 
---
  arch/powerpc/kernel/head_fsl_booke.S |7 ++
  arch/powerpc/kernel/misc_32.S|   66 +-
  arch/powerpc/platforms/85xx/smp.c|  166 ++
  3 files changed, 222 insertions(+), 17 deletions(-)
  mode change 100644 => 100755 arch/powerpc/kernel/head_fsl_booke.S
  mode change 100644 => 100755 arch/powerpc/kernel/misc_32.S
  mode change 100644 => 100755 arch/powerpc/platforms/85xx/smp.c

diff --git a/arch/powerpc/kernel/head_fsl_booke.S
b/arch/powerpc/kernel/head_fsl_booke.S
old mode 100644
new mode 100755
index d10a7ca..63c8392
--- a/arch/powerpc/kernel/head_fsl_booke.S
+++ b/arch/powerpc/kernel/head_fsl_booke.S
@@ -178,6 +178,13 @@ _ENTRY(__early_start)
   * This is where the main kernel code starts.
   */

+#if defined(CONFIG_KEXEC) && defined(CONFIG_SMP)
+/* r28 contain position where slave cpus spin*/
+lisr1,kexec_poll_phy@h
+orir1,r1,kexec_poll_phy@l
+stwr28,0(r1)
+#endif
+
  /* ptr to current */
  lisr2,init_task@h
  orir2,r2,init_task@l
diff --git a/arch/powerpc/kernel/misc_32.S b/arch/powerpc/kernel/misc_32.S
old mode 100644
new mode 100755
index e469f30..d9eefc2
--- a/arch/powerpc/kernel/misc_32.S
+++ b/arch/powerpc/kernel/misc_32.S
@@ -120,7 +120,7 @@ _GLOBAL(reloc_got2)
  addir4,r4,1b@l
  subfr0,r4,r0
  addr7,r0,r7
-2:lwzr0,0(r7)
+2:lwzr0,0(r7)
  addr0,r0,r3
  stwr0,0(r7)
  addir7,r7,4
@@ -692,6 +692,7 @@ _GLOBAL(__main)
  blr

  #ifdef CONFIG_KEXEC
+#define KEXEC_MAGIC 0xdeadbeef
  /*
   * Must be relocatable PIC code callable as a C function.
   */
@@ -707,6 +708,16 @@ relocate_new_kernel:
  mrr30, r4
  mrr31, r5

+#ifdef CONFIG_SMP
+bl1f
+1:mflrr8
+addir8,r8,kexec_flag-1b
+lis r7,PAGE_OFFSET@h
+ori r7,r7,PAGE_OFFSET@l
+/*r28 contain slave cpu spin physical address */
+subfr28, r7, r8
+#endif
+
  #define ENTRY_MAPPING_KEXEC_SETUP
  #include "fsl_booke_entry_mapping.S"
  #undef ENTRY_MAPPING_KEXEC_SETUP
@@ -1172,4 +1183,57 @@ relocate_new_kernel_end:
  .globl relocate_new_kernel_size
  relocate_new_kernel_size:
  .long relocate_new_kernel_end - relocate_new_kernel
+#ifdef CONFIG_FSL_BOOKE
+/**
+* Slave cpus wait for kexec_flag to change
+*/
+.globl relocate_smp_cpu_offset
+relocate_smp_cpu_offset:
+.long relocate_smp_cpu_wait-relocate_new_kernel
+
+.globl relocate_smp_cpu_wait
+relocate_smp_cpu_wait:
+
+bl1f
+1:mflrr5
+addir5,r5,kexec_flag-1b
+/*see if anyone calls me?*/
+mfspr   r24,SPRN_PIR
+99:lwzr4,4(r5)
+cmpwr4,r24
+msync
+bne99b
+
+msync
+/*r4 contains jump address*/
+lwzr4,8(r5)
+msync
+lisr5,MSR_KERNEL@h
+orir5,r5,MSR_KERNEL@l
+msync
+isync
+mtsprSPRN_SRR1, r5
+mtsprSPRN_SRR0, r4
+msync
+isync
+rfi
+isync
+1:b1b
+
+/**
+* kexec_flag indicates a kexec magic
+* kexec_flag+4 bytes supposed to be set with cpu number
+* kexec_flag+8 countain addr for slave cpu to jump into
+*/
+.globl kexec_flag
+kexec_flag:
+.long   KEXEC_MAGIC
+.long0
+.long0
+relocate_smp_cpu_wait_end:
+.globl relocate_smp_cpu_size

[PULL] PTR_RET -> PTR_ERR_OR_ZERO

[Rusty Russell]

The following changes since commit ad81f0545ef01ea651886dddac4bef6cec930092:

  Linux 3.11-rc1 (2013-07-14 15:18:27 -0700)

are available in the git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/rusty/linux.git 
tags/PTR_RET-for-linus

for you to fetch changes up to ad151d544475df40ee0d18be7d5c945e29c1b545:

  GFS2: Replace PTR_RET with PTR_ERR_OR_ZERO (2013-07-22 11:11:46 +0930)


PTR_RET() is a weird name, and led to some confusing usage.  We ended
up with PTR_ERR_OR_ZERO(), and replacing or fixing all the usages.

This has been sitting in linux-next for a whole cycle.

Thanks,
Rusty.


Rusty Russell (8):
  PTR_RET is now PTR_ERR_OR_ZERO
  PTR_RET is now PTR_ERR_OR_ZERO(): Replace most.
  s390: Replace weird use of PTR_RET.
  acpi: Replace weird use of PTR_RET.
  pinctrl: don't use PTR_RET().
  remoteproc: don't use PTR_RET().
  staging/zcache: don't use PTR_RET().
  mm/oom_kill: remove weird use of ERR_PTR()/PTR_ERR().

Sachin Kamat (5):
  drivers/rtc: Replace PTR_RET with PTR_ERR_OR_ZERO
  dma-buf: Replace PTR_RET with PTR_ERR_OR_ZERO
  sh_veu: Replace PTR_RET with PTR_ERR_OR_ZERO
  drm/cma: Replace PTR_RET with PTR_ERR_OR_ZERO
  Btrfs: volume: Replace PTR_RET with PTR_ERR_OR_ZERO

Steven Whitehouse (1):
  GFS2: Replace PTR_RET with PTR_ERR_OR_ZERO

 arch/arm/mach-omap2/i2c.c |  2 +-
 arch/m68k/amiga/platform.c|  2 +-
 arch/m68k/kernel/time.c   |  2 +-
 arch/m68k/q40/config.c|  2 +-
 arch/powerpc/kernel/iommu.c   |  2 +-
 arch/powerpc/kernel/time.c|  2 +-
 arch/powerpc/platforms/ps3/time.c |  2 +-
 arch/powerpc/sysdev/rtc_cmos_setup.c  |  2 +-
 arch/s390/hypfs/hypfs_dbfs.c  |  2 +-
 arch/s390/kvm/gaccess.h   | 12 
 drivers/acpi/acpi_pad.c   | 13 -
 drivers/base/dma-buf.c|  2 +-
 drivers/char/tile-srom.c  |  2 +-
 drivers/gpu/drm/drm_gem_cma_helper.c  |  2 +-
 drivers/infiniband/core/cma.c |  2 +-
 drivers/media/platform/sh_veu.c   |  2 +-
 drivers/net/appletalk/cops.c  |  2 +-
 drivers/net/appletalk/ltpc.c  |  2 +-
 drivers/net/ethernet/amd/atarilance.c |  2 +-
 drivers/net/ethernet/amd/mvme147.c|  2 +-
 drivers/net/ethernet/amd/ni65.c   |  2 +-
 drivers/net/ethernet/amd/sun3lance.c  |  2 +-
 drivers/net/wireless/brcm80211/brcmfmac/dhd_dbg.c |  2 +-
 drivers/net/wireless/brcm80211/brcmsmac/debug.c   |  2 +-
 drivers/pinctrl/mvebu/pinctrl-dove.c  |  2 +-
 drivers/platform/x86/samsung-q10.c|  2 +-
 drivers/regulator/fan53555.c  |  2 +-
 drivers/remoteproc/da8xx_remoteproc.c |  2 +-
 drivers/rtc/rtc-da9052.c  |  2 +-
 drivers/rtc/rtc-isl12022.c|  2 +-
 drivers/rtc/rtc-m48t35.c  |  2 +-
 drivers/rtc/rtc-pcf8563.c |  2 +-
 drivers/rtc/rtc-pcf8583.c |  2 +-
 drivers/spi/spi-fsl-spi.c |  2 +-
 drivers/spi/spidev.c  |  2 +-
 drivers/staging/zcache/zcache-main.c  |  2 +-
 drivers/video/omap2/dss/core.c|  2 +-
 fs/btrfs/dev-replace.c|  2 +-
 fs/btrfs/inode.c  |  2 +-
 fs/btrfs/volumes.c|  2 +-
 fs/gfs2/inode.c   |  2 +-
 include/linux/err.h   |  5 -
 mm/oom_kill.c |  6 +++---
 net/bluetooth/hci_sysfs.c |  2 +-
 net/bridge/netfilter/ebtable_broute.c |  2 +-
 net/bridge/netfilter/ebtable_filter.c |  2 +-
 net/bridge/netfilter/ebtable_nat.c|  2 +-
 net/ipv4/netfilter/arptable_filter.c  |  2 +-
 net/ipv4/netfilter/iptable_filter.c   |  2 +-
 net/ipv4/netfilter/iptable_mangle.c   |  2 +-
 net/ipv4/netfilter/iptable_nat.c  |  2 +-
 net/ipv4/netfilter/iptable_raw.c  |  2 +-
 net/ipv4/netfilter/iptable_security.c |  2 +-
 net/ipv6/netfilter/ip6table_filter.c  |  2 +-
 net/ipv6/netfilter/ip6table_mangle.c  |  2 +-
 net/ipv6/netfilter/ip6table_nat.c |  2 +-
 net/ipv6/netfilter/ip6table_raw.c |  2 +-
 net/ipv6/netfilter/ip6table_security.c|  2 +-
 scripts/coccinelle/api/ptr_ret.cocci  | 10 +-
 

RE: [RFC PATCH v2 04/11] pstore: Add compression support to pstore

[Seiji Aguchi]

Aruna,

Sorry for the late response.

> Seiji,
> 
> Could you let us know the efivars buffer size with which the pstore is
> registered when
> the failure occurred.

I looked into the issue today.

I added some debug message just before pstore_compress().
As you can see below, the buffer size is a fixed value(1024).
Therefore, the size doesn't seem to be related to the failure directly.

Also, in the failure case, zlib_deflate() returns Z_OK and stream.avail_out is 
zero.
So, I thought big_oops_buf_sz is too big in my environment.
And then, I tuned  big_oops_buf_sz to (psinfo->bufsize * 100) / 53.

At the same time, while looking into this issue, I had two concerns about 
current cording.

1) In pstore_decompress(), why not use zlib_inflateInit2() instead of 
zlib_inflateInit()?
 If you use zlib_deflateInit2()  for specifying window_bit at compressing 
time, 
 zlib_inflateInit2() seems to be appropriate for decompressing.
 (Please see a comment about inflateInit2() in include/linux/zlib.h and 
source code of crypto/deflate.c)

2) As looking at crypto/deflate.c, stream->workspace is kzalloced at the 
beginning of 
   compressing/decompressing time.
So, in pstore case,  stream.workspace must be initialized to 0 with 
memset() in pstore_compress()/decompress().

I did three things above, tuning big_oops_buf_sz, using zlib_inflateInit2() and 
initializing stream.workspace , in my environment.
As a result, compressions/decmpressions of all entries succeeded with efivars 
driver.


Panic#2 Part1
<4>[   75.665020]  [] SyS_write+0x4c/0xa0
<4>[   75.665020]  [] system_call_fastpath+0x16/0x1b
<4>[   75.665020] Code: ef e8 ff f7 ff ff eb d8 66 2e 0f 1f 84 00 00 00 00 00 
0f 1f 00 0f 1f 44 00 00 55 c7 05 cc f3 c9 00 01 00 00 00 48 89 e5 0f ae f8  
04 25 00 00 00 00 01 5d c3 0f 1f 44 00 00 55 31 c0 c7 05 5e 
<1>[   75.665020] RIP  [] sysrq_handle_crash+0x16/0x20
<4>[   75.665020]  RSP 
<4>[   75.665020] CR2: 
<4>[   75.665020] ---[ end trace 97bb4a1f8d3fe7b2 ]---
<3>[   75.665020] pstore_dump hsize=13 len=2155 big_oops_buf_sz=2275 
psinfo->bufsize=1024
<3>[   75.665020] pstore_dump hsize=13 len=2246 big_oops_buf_sz=2275 
psinfo->bufsize=1024
<3>[   75.665020] pstore: compression failed for Part 2 returned -5
<3>[   75.665020] pstore: Capture uncompressed oops/panic report of Part 2
<3>[   75.665020] pstore_dump hsize=13 len=2239 big_oops_buf_sz=2275 
psinfo->bufsize=1024
<3>[   75.665020] pstore_dump hsize=13 len=2231 big_oops_buf_sz=2275 
psinfo->bufsize=1024
<3>[   75.665020] pstore_dump hsize=13 len=2185 big_oops_buf_sz=2275 
psinfo->bufsize=1024
<3>[   75.665020] pstore: compression failed for Part 5 returned -5
<3>[   75.665020] pstore: Capture uncompressed oops/panic report of Part 5
<3>[   75.665020] pstore_dump hsize=13 len=2234 big_oops_buf_sz=2275 
psinfo->bufsize=1024
<3>[   75.665020] pstore_dump hsize=13 len=2208 big_oops_buf_sz=2275 
psinfo->bufsize=1024
<3>[   75.665020] pstore_dump hsize=13 len=2218 big_oops_buf_sz=2275 
psinfo->bufsize=1024
<3>[   75.665020] pstore_dump hsize=13 len= big_oops_buf_sz=2275 
psinfo->bufsize=1024
<3>[   75.665020] pstore: compression failed for Part 9 returned -5
<3>[   75.665020] pstore: Capture uncompressed oops/panic report of Part 9
<3>[   75.665020] pstore_dump hsize=14 len=2256 big_oops_buf_sz=2275 
psinfo->bufsize=1024
<3>[   75.665020] pstore_dump hsize=14 len=2219 big_oops_buf_sz=2275 
psinfo->bufsize=1024
<3>[   75.665020] pstore_dump hsize=14 len=2226 big_oops_buf_sz=2275 
psinfo->bufsize=1024
<0>[   75.665020] Kernel panic - not syncing: Fatal exception
<3>[   75.665020] drm_kms_helper: panic occurred, switching back to text console


Seiji
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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-next v2] net: neighbour: Remove CONFIG_ARPD

[David Miller]

From: Tim Gardner 
Date: Thu, 29 Aug 2013 06:38:47 -0600

> This config option is superfluous in that it only guards a call
> to neigh_app_ns(). Enabling CONFIG_ARPD by default has no
> change in behavior. There will now be call to __neigh_notify()
> for each ARP resolution, which has no impact unless there is a
> user space daemon waiting to receive the notification, i.e.,
> the case for which CONFIG_ARPD was designed anyways.
> 
> Suggested-by: Eric W. Biederman 
 ...
> Signed-off-by: Tim Gardner 

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

Re: [PATCH V3 11/11] Add option to automatically enforce module signatures when in Secure Boot mode

[Matthew Garrett]

On Wed, 2013-09-04 at 11:42 +1000, James Morris wrote:
> On Tue, 3 Sep 2013, Matthew Garrett wrote:
> 
> > +   status = efi_call_phys5(sys_table->runtime->get_variable,
> > +   L"SecureBoot", _guid, NULL, , );
> > +
> 
> 
> What's 'L' ?

Wide-character string constant. UEFI variable names are 16-bits per
character.

-- 
Matthew Garrett 

Re: [PATCH V3 11/11] Add option to automatically enforce module signatures when in Secure Boot mode

[James Morris]

On Tue, 3 Sep 2013, Matthew Garrett wrote:

> + status = efi_call_phys5(sys_table->runtime->get_variable,
> + L"SecureBoot", _guid, NULL, , );
> +


What's 'L' ?


-- 
James Morris

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

RE: [E1000-devel] [PATCH 0/4] i40e: Neatening and object size reductions

[Nelson, Shannon]

> -Original Message-
> From: Joe Perches [mailto:j...@perches.com]
> Sent: Tuesday, September 03, 2013 6:31 PM
> 
> On Wed, 2013-09-04 at 01:00 +, Nelson, Shannon wrote:
> 
> Hi Shannon.
> 
> > > -Original Message- > From: Joe Perches
> > [mailto:j...@perches.com] > Sent: Friday, August 30, 2013 4:06 PM > >
> > Just some potential cleanings...
> >
> > >   i40e: Whitespace cleaning
> >
> > Hmmm, we hadn't noticed the new experimental "--fix" option before.
> > There are a lot of good suggestions there, but obviously it needs a
> lot
> > of reading and tweaking before it can be used.  There are cases here
> > where function call parameters are adjusted to line up with the
> opening
> > '(' but that pushes the parameter(s) beyond 80 columns - we're trying
> > to stay within the 80 column line and checkpatch clean.  Also, there
> > are several where the first continued parameter line indent is changed
> > but the next line or two are not.
> >
> > We'll spend time going through these and try to take care of what
> makes
> > sense.
> 
> Swell.  All these are your choice to fix as you want.
> 
> Exceeding 80 columns doesn't bother me much.

We should perhaps become a little more flexible ourselves, but we've finally 
got a good process going internally, including this as a check.  I don't dare 
disturb the machine now that it is working :-).

> Keeping alignment appropriate for multi-line statements
> needs work inside checkpatch.  I played with it a bit
> but it's unfortunately complicated by intermixed
> insertions and deletions.

Yeah, it all gets a little funky after a while.

> 
> > >   i40e: Add and use pf_
> >
> > We had considered this kind of macro awhile ago, but nixed it for a
> few
> > different reasons, but primarily because it seems like
> > yet-another-print-macro and not necessarily worth the effort.
> >
> > >   i40e: pf_ remove "%s: " ... __func__
> >
> > We're beginning to remove many of the __func__ uses, so these prints
> > are no longer all doing the __func__ thing.  We originally had them
> > there for early development and debugging and are currently removing
> > them from the normal path messages.
> 
> Fine by me.  I think __func__ is nearly always pretty
> useless myself.

It was useful for a while, but it is time to be pulling it out.

> 
> > >   i40e: Convert pf_ macros to functions
> >
> > Doesn't this create a problem with polluting the kernel namespace?
> > These don't apply to any other driver.  I suppose we could lessen the
> > namespace problem with i40e_ prefix, but I'm still not sold on it.  I
> > suspect we can still get much of the text savings replacing the
> > __func__ with __builtin_return_address(0) where needed, and remove
> them
> > where no longer needed.  Does that work for you?
> 
> I think you could just as soon whatever combinations of the
> other standard logging mechanisms without using pf_
> 
>   wiphy_
>   netif_
>   netdev_
>   dev_
>   pr_
> 
> as appropriate.  I did that only because there was ~10K
> of what I think of as not too useful function names out
> of a defconfig size of 140k.

Yes, and I think removing much of the __func__ or using 
__builtin_return_address(0) will help.

> 
> > >   i40e: Fix 32 bit shift compilation warnings
> >
> > Sure.
> 
> I think you should use the kernel.h standard macros
> for lower_32_bits and upper_32_bits instead.

Yep.

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

Re: [E1000-devel] [PATCH 0/4] i40e: Neatening and object size reductions

[Joe Perches]

On Wed, 2013-09-04 at 01:00 +, Nelson, Shannon wrote:

Hi Shannon.

> > -Original Message- > From: Joe Perches
> [mailto:j...@perches.com] > Sent: Friday, August 30, 2013 4:06 PM > >
> Just some potential cleanings...
> 
> >   i40e: Whitespace cleaning
> 
> Hmmm, we hadn't noticed the new experimental "--fix" option before. 
> There are a lot of good suggestions there, but obviously it needs a lot
> of reading and tweaking before it can be used.  There are cases here
> where function call parameters are adjusted to line up with the opening
> '(' but that pushes the parameter(s) beyond 80 columns - we're trying
> to stay within the 80 column line and checkpatch clean.  Also, there
> are several where the first continued parameter line indent is changed
> but the next line or two are not.
>
> We'll spend time going through these and try to take care of what makes
> sense.

Swell.  All these are your choice to fix as you want.

Exceeding 80 columns doesn't bother me much.
Keeping alignment appropriate for multi-line statements
needs work inside checkpatch.  I played with it a bit
but it's unfortunately complicated by intermixed
insertions and deletions.

> >   i40e: Add and use pf_
> 
> We had considered this kind of macro awhile ago, but nixed it for a few
> different reasons, but primarily because it seems like
> yet-another-print-macro and not necessarily worth the effort.
> 
> >   i40e: pf_ remove "%s: " ... __func__
> 
> We're beginning to remove many of the __func__ uses, so these prints
> are no longer all doing the __func__ thing.  We originally had them
> there for early development and debugging and are currently removing
> them from the normal path messages.

Fine by me.  I think __func__ is nearly always pretty
useless myself.

> >   i40e: Convert pf_ macros to functions
> 
> Doesn't this create a problem with polluting the kernel namespace? 
> These don't apply to any other driver.  I suppose we could lessen the
> namespace problem with i40e_ prefix, but I'm still not sold on it.  I
> suspect we can still get much of the text savings replacing the
> __func__ with __builtin_return_address(0) where needed, and remove them
> where no longer needed.  Does that work for you? 

I think you could just as soon whatever combinations of the
other standard logging mechanisms without using pf_

wiphy_
netif_
netdev_
dev_
pr_

as appropriate.  I did that only because there was ~10K
of what I think of as not too useful function names out
of a defconfig size of 140k.

> >   i40e: Fix 32 bit shift compilation warnings
> 
> Sure.

I think you should use the kernel.h standard macros
for lower_32_bits and upper_32_bits instead.

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/

[RELEASE] LTTng modules 2.3.0

[Mathieu Desnoyers]

The LTTng modules provide Linux kernel tracing capability to the LTTng
2.x tracer toolset.

Noteworthy changes:
- Support for Linux kernels up to (including) 3.11,
- Flight recorder (snapshot) support,
- Updated ARM, x86 system call instrumentation,
- Add 32-bit PowerPC system call instrumentation.

Changelog since 2.3.0-rc2:
2013-09-03 LTTng modules 2.3.0
* Fix: metadata stream should not reference session
* Fix: btrfs: support 3.11 Linux kernel
* statedump: remove KERN_DEBUG messages
* Fix: ext4: add missing tracepoints for 3.11 kernel
* Fix: ext4: Linux 3.11 support
* Fix: ext3: 3.11 Linux support
* Fix: statedump nsproxy 3.11 Linux support

Project website: http://lttng.org
Download link: http://lttng.org/download
(please refer to the README files for installation instructions and
lttng-tools doc/quickstart.txt for usage information)

-- 
Mathieu Desnoyers
EfficiOS Inc.
http://www.efficios.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-v5 1/6] idr: Percpu ida

[Andrew Morton]

On Tue, 03 Sep 2013 09:06:58 -0700 "Nicholas A. Bellinger" 
 wrote:

> Are there any other review comments to be addressed for this patch..?
> 
> If not, please kindly give your Reviewed-by if your OK for an initial
> standalone merge.

Sorry, I'm largely offline for the next week...

It looks OK to me (that's as close as I get to an ack :))

Nit:

> + if (cpu >= nr_cpu_ids)
> + cpu = cpumask_first(>cpus_have_tags);
> +
> + if (cpu >= nr_cpu_ids)
> + BUG();

The second `if' can be moved inside the first, but hopefully the
compiler already did that.

I have dim memories that doing

local_irq_save()
spin_lock()

is not equivalent to

spin_lock_irqsave()

in some circumstances.  Perhaps a lockdep thing.  Or perhaps this was fixed in
the intervening years and this is no longer the case.

Such things probably won't be detected during 3.12-rcX because few
people will test iscsi, I expect.  So please be sure that you've
runtime tested it with all the lockdeppy things enabled. 
Documentation/SubmitChecklist section 12 has a list, but it might be
dated.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [RFC][PATCH 19/18] ftrace: Print a message when the rcu checker is disabled

[Paul E. McKenney]

On Tue, Sep 03, 2013 at 09:11:27PM -0400, Steven Rostedt wrote:
> From f8f5d278e272c42349b3cd32485faf426d0c459e Mon Sep 17 00:00:00 2001
> From: "Steven Rostedt (Red Hat)" 
> Date: Tue, 3 Sep 2013 20:47:59 -0400
> Subject: [PATCH] ftrace: Print a message when the rcu checker is disabled
> 
> Let the user know that the RCU safety checker for function tracing
> has been disabled. The checker only runs when the user specifically
> configures it in the kernel, and this is done to search for locations
> in the kernel that may be unsafe for a function trace callback to
> use rcu_read_lock()s. But if things like function graph tracing is
> started, which can live lock the machine when the checker is running,
> it is disabled. It would be nice if the kernel let the user know that
> the checker is disabled, and when it is re-enabled again.
> 
> As the checker only gets disabled and re-enabled by user actions
> (starting and stoping the function graph tracer or the irqsoff tracer)
> it is fine to have a printk display that it is disabled or not.
> 
> Suggested-by: Paul E. McKenney 
> Signed-off-by: Steven Rostedt 

Reviewed-by: Paul E. McKenney 

> ---
>  kernel/trace/trace_functions.c | 4 
>  1 file changed, 4 insertions(+)
> 
> diff --git a/kernel/trace/trace_functions.c b/kernel/trace/trace_functions.c
> index 0883069..dd59827 100644
> --- a/kernel/trace/trace_functions.c
> +++ b/kernel/trace/trace_functions.c
> @@ -569,6 +569,8 @@ void ftrace_unsafe_rcu_checker_disable(void)
>   atomic_inc(_unsafe_rcu_disabled);
>   /* Make sure the update is seen immediately */
>   smp_wmb();
> + pr_info("Disabled FTRACE RCU checker (%pS)\n",
> + __builtin_return_address(0));
>  }
>  
>  void ftrace_unsafe_rcu_checker_enable(void)
> @@ -576,6 +578,8 @@ void ftrace_unsafe_rcu_checker_enable(void)
>   atomic_dec(_unsafe_rcu_disabled);
>   /* Make sure the update is seen immediately */
>   smp_wmb();
> + pr_info("Enabled FTRACE RCU checker (%pS)\n",
> + __builtin_return_address(0));
>  }
>  
>  static DEFINE_PER_CPU(unsigned long, ftrace_rcu_func);
> -- 
> 1.8.1.4
> 

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

Re: [RFC][PATCH 01/18 v2] ftrace: Add hash list to save RCU unsafe functions

[Paul E. McKenney]

On Tue, Sep 03, 2013 at 07:57:05PM -0400, Steven Rostedt wrote:
> On Tue, 3 Sep 2013 15:18:08 -0700
> "Paul E. McKenney"  wrote:
> 
> 
> > > Just found this bug. Strange that gcc never gave me a warning :-/
> > 
> > I can't give gcc too much trouble, as I also didn't give you an
> > uninitialized-variable warning.
> 
> I was also chasing down a nasty bug that looked to be a pointer
> corruption somewhere. Still never found exactly where it happened, but
> it always happened with the following conditions:
> 
> synchronize_sched() was in progress
> 
> The ftrace_unsafe_callback() was preempted by an interrupt
> 
> lockdep was processing a lock
> 
> 
> A crash would happen which had memory corruption involved. But the
> above seemed always to be in play.
> 
> Now, I changed the logic from disabling context level recursion to
> disabling recursion at all. That is, the original code had used a
> series of bits to test for recursion (via helper functions) that would
> allow for the callback to be preempted by an interrupt, and then be
> called again.
> 
> The new code sets a per_cpu flag, and will not allow the callback to
> recurse if it were preempted by an interrupt. No real need to allow for
> that anyway.
> 
> I can go and debug this further, because I'm nervous that lockdep may
> have some kind of bug that the function tracer can trigger. But I'm not
> too concerned about it.
> 
> Here's the diff of the new code against the previous code.
> 
> Paul, can I still keep all your acks and reviewed-bys on this?

Yep, but some questions below.

Thanx, Paul

> -- Steve
> 
> diff --git a/kernel/trace/ftrace.c b/kernel/trace/ftrace.c
> index 310b727..899c8c1 100644
> --- a/kernel/trace/ftrace.c
> +++ b/kernel/trace/ftrace.c
> @@ -1373,7 +1373,7 @@ ftrace_hash_rec_enable(struct ftrace_ops *ops, int 
> filter_hash);
> 
>  static int ftrace_convert_size_to_bits(int size)
>  {
> - int bits;
> + int bits = 0;
> 
>   /*
>* Make the hash size about 1/2 the # found
> diff --git a/kernel/trace/trace_functions.c b/kernel/trace/trace_functions.c
> index f5a9031..0883069 100644
> --- a/kernel/trace/trace_functions.c
> +++ b/kernel/trace/trace_functions.c
> @@ -561,16 +561,21 @@ static inline int init_func_cmd_traceon(void)
> 
>  #ifdef CONFIG_FTRACE_UNSAFE_RCU_CHECKER
> 
> +static DEFINE_PER_CPU(int, ftrace_rcu_running);
>  static atomic_t ftrace_unsafe_rcu_disabled;
> 
>  void ftrace_unsafe_rcu_checker_disable(void)
>  {
>   atomic_inc(_unsafe_rcu_disabled);
> + /* Make sure the update is seen immediately */
> + smp_wmb();

smp_mb__after_atomic_inc()?

>  }
> 
>  void ftrace_unsafe_rcu_checker_enable(void)
>  {
>   atomic_dec(_unsafe_rcu_disabled);
> + /* Make sure the update is seen immediately */
> + smp_wmb();

smp_mb__after_atomic_dec()?

>  }
> 
>  static DEFINE_PER_CPU(unsigned long, ftrace_rcu_func);
> @@ -588,15 +593,14 @@ static void
>  ftrace_unsafe_callback(unsigned long ip, unsigned long parent_ip,
>  struct ftrace_ops *op, struct pt_regs *pt_regs)
>  {
> - int bit;
> -
> + /* Make sure we see disabled or not first */
> + smp_rmb();

smp_mb__before_atomic_inc()?

>   if (atomic_read(_unsafe_rcu_disabled))
>   return;
> 
>   preempt_disable_notrace();
> 
> - bit = trace_test_and_set_recursion(TRACE_FTRACE_START, 
> TRACE_FTRACE_MAX);
> - if (bit < 0)
> + if (this_cpu_read(ftrace_rcu_running))
>   goto out;
> 
>   if (WARN_ONCE(ftrace_rcu_unsafe(ip),
> @@ -604,13 +608,15 @@ ftrace_unsafe_callback(unsigned long ip, unsigned long 
> parent_ip,
> (void *)ip))
>   goto out;
> 
> + this_cpu_write(ftrace_rcu_running, 1);
>   this_cpu_write(ftrace_rcu_func, ip);
> +
>   /* Should trigger a RCU splat if called from unsafe RCU function */
>   rcu_read_lock();
>   rcu_read_unlock();
>   this_cpu_write(ftrace_rcu_func, 0);
> 
> - trace_clear_recursion(bit);
> + this_cpu_write(ftrace_rcu_running, 0);
>   out:
>   preempt_enable_notrace();
>  }
> 

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] x86/irq: correct comment about i8259 initialization

[Yanchuan Nian]

From: Yanchuan Nian 

0x30-0x3f have been used for ISA interrupts on i386 since 5 years ago,
but some comments about i8259 initialization were missed to update
at the same time.

Signed-off-by: Yanchuan Nian 
---
 arch/x86/kernel/i8259.c | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/arch/x86/kernel/i8259.c b/arch/x86/kernel/i8259.c
index 9a5c460..2e977b5 100644
--- a/arch/x86/kernel/i8259.c
+++ b/arch/x86/kernel/i8259.c
@@ -312,8 +312,7 @@ static void init_8259A(int auto_eoi)
 */
outb_pic(0x11, PIC_MASTER_CMD); /* ICW1: select 8259A-1 init */
 
-   /* ICW2: 8259A-1 IR0-7 mapped to 0x30-0x37 on x86-64,
-  to 0x20-0x27 on i386 */
+   /* ICW2: 8259A-1 IR0-7 mapped to 0x30-0x37 */
outb_pic(IRQ0_VECTOR, PIC_MASTER_IMR);
 
/* 8259A-1 (the master) has a slave on IR2 */
-- 
1.8.1.4

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

Re: [PATCH 3/3] extcon: Simplify extcon_dev_register() prototype by removing unnecessary parameter

[Greg KH]

On Wed, Sep 04, 2013 at 09:17:02AM +0900, Chanwoo Choi wrote:
> On 09/04/2013 12:57 AM, Greg KH wrote:
> > On Mon, Sep 02, 2013 at 10:13:44AM +0900, Chanwoo Choi wrote:
> >> Hi Greg,
> >>
> >> On 09/02/2013 09:40 AM, Greg KH wrote:
> >>> On Mon, Sep 02, 2013 at 09:20:08AM +0900, Chanwoo Choi wrote:
>  This patch remove extcon_dev_register()'s second parameter which means
>  the pointer of parent device to simplify prototype of this function.
> >>>
> >>> No, please don't.  You want the parent to be passed in, as the core
> >>> needs it when it is registered with the system, otherwise it will not
> >>> show up in sysfs properly (i.e. you can't set it afterwards.)
> >>
> >> Currently, each extcon driver have allocated memory for extcon device
> >> by using devm_kzalloc() in each extcon device driver.
> > 
> > That seems backwards, the extcon core should be the one doing the
> > allocation, and ownership of the device, like all other subsystem cores
> > do.  That makes the driver logic much simpler, and the lifetime
> > ownership correct (i.e. what happens when a device is unbound from a
> > driver by userspace?  The driver can't control the device memory
> > anymore...)
> > 
> 
> OK,
> The extcon core will control memory allocation instead of extcon device driver
> as following.
> - devm_extcon_allocate_device(struct device *dev)

Huh?  Why do you need a devm allocator?  This is a "real" child device,
just create it with a "extcon_create_device()" or some such call, like
all other busses do?

thanks,

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

[RFC][PATCH 19/18] ftrace: Print a message when the rcu checker is disabled

[Steven Rostedt]

>From f8f5d278e272c42349b3cd32485faf426d0c459e Mon Sep 17 00:00:00 2001
From: "Steven Rostedt (Red Hat)" 
Date: Tue, 3 Sep 2013 20:47:59 -0400
Subject: [PATCH] ftrace: Print a message when the rcu checker is disabled

Let the user know that the RCU safety checker for function tracing
has been disabled. The checker only runs when the user specifically
configures it in the kernel, and this is done to search for locations
in the kernel that may be unsafe for a function trace callback to
use rcu_read_lock()s. But if things like function graph tracing is
started, which can live lock the machine when the checker is running,
it is disabled. It would be nice if the kernel let the user know that
the checker is disabled, and when it is re-enabled again.

As the checker only gets disabled and re-enabled by user actions
(starting and stoping the function graph tracer or the irqsoff tracer)
it is fine to have a printk display that it is disabled or not.

Suggested-by: Paul E. McKenney 
Signed-off-by: Steven Rostedt 
---
 kernel/trace/trace_functions.c | 4 
 1 file changed, 4 insertions(+)

diff --git a/kernel/trace/trace_functions.c b/kernel/trace/trace_functions.c
index 0883069..dd59827 100644
--- a/kernel/trace/trace_functions.c
+++ b/kernel/trace/trace_functions.c
@@ -569,6 +569,8 @@ void ftrace_unsafe_rcu_checker_disable(void)
atomic_inc(_unsafe_rcu_disabled);
/* Make sure the update is seen immediately */
smp_wmb();
+   pr_info("Disabled FTRACE RCU checker (%pS)\n",
+   __builtin_return_address(0));
 }
 
 void ftrace_unsafe_rcu_checker_enable(void)
@@ -576,6 +578,8 @@ void ftrace_unsafe_rcu_checker_enable(void)
atomic_dec(_unsafe_rcu_disabled);
/* Make sure the update is seen immediately */
smp_wmb();
+   pr_info("Enabled FTRACE RCU checker (%pS)\n",
+   __builtin_return_address(0));
 }
 
 static DEFINE_PER_CPU(unsigned long, ftrace_rcu_func);
-- 
1.8.1.4

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

Re: [tip:x86/smap] Introduce [compat_]save_altstack_ex() to unbreak x86 SMAP

[Stephen Rothwell]

On Sun, 1 Sep 2013 14:45:56 -0700 tip-bot for Al Viro  wrote:
>
> Commit-ID:  bd1c149aa9915b9abb6d83d0f01dfd2ace0680b5
> Gitweb: http://git.kernel.org/tip/bd1c149aa9915b9abb6d83d0f01dfd2ace0680b5
> Author: Al Viro 
> AuthorDate: Sun, 1 Sep 2013 20:35:01 +0100
> Committer:  H. Peter Anvin 
> CommitDate: Sun, 1 Sep 2013 14:16:33 -0700
> 
> Introduce [compat_]save_altstack_ex() to unbreak x86 SMAP
> 
> For performance reasons, when SMAP is in use, SMAP is left open for an
> entire put_user_try { ... } put_user_catch(); block, however, calling
> __put_user() in the middle of that block will close SMAP as the
> STAC..CLAC constructs intentionally do not nest.
> 
> Furthermore, using __put_user() rather than put_user_ex() here is bad
> for performance.
> 
> Thus, introduce new [compat_]save_altstack_ex() helpers that replace
> __[compat_]save_altstack() for x86, being currently the only
> architecture which supports put_user_try { ... } put_user_catch().
> 
> Reported-by: H. Peter Anvin 
> Signed-off-by: Al Viro 
> Signed-off-by: H. Peter Anvin 
> Cc:  # v3.8+
> Link: http://lkml.kernel.org/n/tip-es5p6y64if71k8p5u08ag...@git.kernel.org
> diff --git a/include/linux/compat.h b/include/linux/compat.h
> index 7f0c1dd..ec1aee4 100644
> --- a/include/linux/compat.h
> +++ b/include/linux/compat.h
> @@ -669,6 +669,13 @@ asmlinkage long compat_sys_sigaltstack(const 
> compat_stack_t __user *uss_ptr,
>  
>  int compat_restore_altstack(const compat_stack_t __user *uss);
>  int __compat_save_altstack(compat_stack_t __user *, unsigned long);
> +#define compat_save_altstack_ex(uss, sp) do { \
> + compat_stack_t __user *__uss = uss; \
> + struct task_struct *t = current; \
> + put_user_ex(ptr_to_compat((void __user *)t->sas_ss_sp), &__uss->ss_sp); 
> \
> + put_user_ex(sas_ss_flags(sp), &__uss->ss_flags); \
> + put_user_ex(t->sas_ss_size, &__uss->ss_size); \
> +} while (0);

I am just wondering if there is some reason that these macros are not
implemented as (static inline) C functions?

> +#define save_altstack_ex(uss, sp) do { \
> + stack_t __user *__uss = uss; \
> + struct task_struct *t = current; \
> + put_user_ex((void __user *)t->sas_ss_sp, &__uss->ss_sp); \
> + put_user_ex(sas_ss_flags(sp), &__uss->ss_flags); \
> + put_user_ex(t->sas_ss_size, &__uss->ss_size); \
> +} while (0);
> +
-- 
Cheers,
Stephen Rothwells...@canb.auug.org.au


pgpONKeAS4AIL.pgp
Description: PGP signature

Re: [RFC, 14/18, v2] ftrace/lockdep: Have the RCU lockdep splat show what function triggered

[Steven Rostedt]

On Sun, 01 Sep 2013 16:28:36 +0800
Wang Shilong  wrote:

> Hello, Using checkpatch.pl, i get the following warnings(errors):
> WARNING: printk() should include KERN_ facility level
> #90: FILE: kernel/trace/trace_functions.c:583:
> + printk("ftrace_rcu_func: %pS\n",
> 
> total: 0 errors, 1 warnings, 53 lines checked
> 
> patch has style problems, please review.  If any of these errors
> are false positives report them to the maintainer, see
> CHECKPATCH in MAINTAINERS.
> 

The code is called by lockdep, which uses printk() directly as well.
This will stay a printk() until lockdep changes.

And please, do not send a patch to change lockdep.

-- Steve

> Thanks, Wang
> 
> Notic: this is an automated generated by shell script
> Any problems please contact: wangshilong1...@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 trivial] UAPI: Kbuild: add/modify comments for "uapi/Kbuild" and "uapi/linux/Kbuild"

[Chen Gang]

On 09/04/2013 12:41 AM, Geert Uytterhoeven wrote:
> On Tue, Aug 6, 2013 at 3:46 AM, Chen Gang  wrote:
>> --- a/include/uapi/Kbuild
>> +++ b/include/uapi/Kbuild
>> @@ -1,7 +1,6 @@
>>  # UAPI Header export list
>> -# Top-level Makefile calls into asm-$(ARCH)
>> -# List only non-arch directories below
>> -
>> +# Except "linux/", UAPI means Universal API.
> 
> Sorry for my silly question, but what's the purpose of this "Universal
> API" comment?
> 

Firstly, at least for me, I don't think it is a silly question (maybe
it means I should give additional explanations).  :-)

I 'guess' the "Universal API" means:

  "the API which can be used under multiple OS (independent from Linux), it may 
be used under kernel mode or user mode".

It is just my 'guess', welcome additional suggestions or completions by
any members.

When we get this correct additional explanation after discussing, if
suitable, I should add the final explanation to current patch.


Thanks.

>> +# For "linux/", UAPI means User API which can be used by user mode.
>>
>>  header-y += asm-generic/
>>  header-y += linux/
> 
> Gr{oetje,eeting}s,
> 
> Geert
> 
> --
> Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- 
> ge...@linux-m68k.org
> 
> In personal conversations with technical people, I call myself a hacker. But
> when I'm talking to journalists I just say "programmer" or something like 
> that.
> -- Linus Torvalds
> 
> 


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

Re: [PATCH 1/3] autofs4 - fix device ioctl mount lookup

[Al Viro]

On Wed, Sep 04, 2013 at 08:54:57AM +0800, Ian Kent wrote:
> +static int kern_path_top(const char *pathname,
> +  unsigned int flags, struct path *path)
> +{
> + struct dentry *dentry;
> + struct qstr name;
> + const char *tmp;
> + unsigned int len;
> + int err;
> +
> + len = strlen(pathname);
> + if (len <= 1)
> + return -EINVAL;
> +
> + tmp = pathname + len - 1;
> + len = 0;
> + if (*tmp == '/')
> + tmp--;
> + do {
> + if (*tmp == '/')
> + break;
> + len++;
> + } while (--tmp >= pathname);
> + tmp++;
> +
> + err = kern_path(pathname, flags | LOOKUP_PARENT, path);
> + if (err)
> + return err;
> +
> + name.name = tmp;
> + name.len = len;
> + name.hash = full_name_hash(tmp, len);
> +
> + dentry = d_lookup(path->dentry, );
> + if (!dentry) {
> + path_put(path);
> + return -ENOENT;
> + }
> + dput(path->dentry);
> + path->dentry = dentry;
> +
> + while (follow_down_one(path))
> + ;
> +
> + return 0;
> +}

E...   NAK in that form.  Just what will happen if the last component
given to that sucker will be . or .., for starters?  Or a symlink, with
'/' added to it to force following the damn thing?
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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 06/11] memblock: Improve memblock to support allocation from lower address.

[Tang Chen]

On 09/04/2013 08:24 AM, Toshi Kani wrote:
..

+phys_addr_t __init_memblock
+__memblock_find_range(phys_addr_t start, phys_addr_t end,
+ phys_addr_t size, phys_addr_t align, int nid)


This func should be static as it must be an internal func.


..

+phys_addr_t __init_memblock
+__memblock_find_range_rev(phys_addr_t start, phys_addr_t end,
+ phys_addr_t size, phys_addr_t align, int nid)


Ditto.

..

+   if (memblock.current_order == MEMBLOCK_ORDER_DEFAULT)


This needs to use MEMBLOCK_ORDER_HIGH_TO_LOW since the code should be
independent from the value of MEMBLOCK_ORDER_DEFAULT.



OK, followed.

Thanks.

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

RE: [E1000-devel] [PATCH 0/4] i40e: Neatening and object size reductions

[Nelson, Shannon]

> -Original Message-
> From: Joe Perches [mailto:j...@perches.com]
> Sent: Friday, August 30, 2013 4:06 PM
> 
> Just some potential cleanings...

>   i40e: Whitespace cleaning

Hmmm, we hadn't noticed the new experimental "--fix" option before.  There are 
a lot of good suggestions there, but obviously it needs a lot of reading and 
tweaking before it can be used.  There are cases here where function call 
parameters are adjusted to line up with the opening '(' but that pushes the 
parameter(s) beyond 80 columns - we're trying to stay within the 80 column line 
and checkpatch clean.  Also, there are several where the first continued 
parameter line indent is changed but the next line or two are not.

We'll spend time going through these and try to take care of what makes sense.

>   i40e: Add and use pf_

We had considered this kind of macro awhile ago, but nixed it for a few 
different reasons, but primarily because it seems like yet-another-print-macro 
and not necessarily worth the effort.

>   i40e: pf_ remove "%s: " ... __func__

We're beginning to remove many of the __func__ uses, so these prints are no 
longer all doing the __func__ thing.  We originally had them there for early 
development and debugging and are currently removing them from the normal path 
messages.

>   i40e: Convert pf_ macros to functions

Doesn't this create a problem with polluting the kernel namespace?  These don't 
apply to any other driver.  I suppose we could lessen the namespace problem 
with i40e_ prefix, but I'm still not sold on it.  I suspect we can still get 
much of the text savings replacing the __func__ with 
__builtin_return_address(0) where needed, and remove them where no longer 
needed.  Does that work for you? 

>   i40e: Fix 32 bit shift compilation warnings

Sure.

sln



--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] autofs: use IS_ROOT to replace root dentry checks

[Ian Kent]

From: Rui Xiang 

Use the helper macro !IS_ROOT to replace parent != dentry->d_parent.
Just clean up.

Signed-off-by: Rui Xiang 
Acked-by: Ian Kent 
---
 fs/autofs4/root.c |6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/fs/autofs4/root.c b/fs/autofs4/root.c
index 92ef341..2caf36a 100644
--- a/fs/autofs4/root.c
+++ b/fs/autofs4/root.c
@@ -558,7 +558,7 @@ static int autofs4_dir_symlink(struct inode *dir,
dget(dentry);
atomic_inc(>count);
p_ino = autofs4_dentry_ino(dentry->d_parent);
-   if (p_ino && dentry->d_parent != dentry)
+   if (p_ino && !IS_ROOT(dentry))
atomic_inc(_ino->count);
 
dir->i_mtime = CURRENT_TIME;
@@ -593,7 +593,7 @@ static int autofs4_dir_unlink(struct inode *dir, struct 
dentry *dentry)
 
if (atomic_dec_and_test(>count)) {
p_ino = autofs4_dentry_ino(dentry->d_parent);
-   if (p_ino && dentry->d_parent != dentry)
+   if (p_ino && !IS_ROOT(dentry))
atomic_dec(_ino->count);
}
dput(ino->dentry);
@@ -732,7 +732,7 @@ static int autofs4_dir_mkdir(struct inode *dir, struct 
dentry *dentry, umode_t m
dget(dentry);
atomic_inc(>count);
p_ino = autofs4_dentry_ino(dentry->d_parent);
-   if (p_ino && dentry->d_parent != dentry)
+   if (p_ino && !IS_ROOT(dentry))
atomic_inc(_ino->count);
inc_nlink(dir);
dir->i_mtime = CURRENT_TIME;

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] autofs: fix the return value of autofs4_fill_super

[Ian Kent]

From: Rui Xiang 

While kzallocing sbi/ino fails, it should return -ENOMEM.

And it should return the err value from autofs_prepare_pipe.

Signed-off-by: Rui Xiang 
Acked-by: Ian Kent 
---
 fs/autofs4/inode.c |   13 -
 1 file changed, 8 insertions(+), 5 deletions(-)

diff --git a/fs/autofs4/inode.c b/fs/autofs4/inode.c
index b104726..fe390ed 100644
--- a/fs/autofs4/inode.c
+++ b/fs/autofs4/inode.c
@@ -211,10 +211,11 @@ int autofs4_fill_super(struct super_block *s, void *data, 
int silent)
int pipefd;
struct autofs_sb_info *sbi;
struct autofs_info *ino;
+   int ret = -EINVAL;
 
sbi = kzalloc(sizeof(*sbi), GFP_KERNEL);
if (!sbi)
-   goto fail_unlock;
+   return -ENOMEM;
DPRINTK("starting up, sbi = %p",sbi);
 
s->s_fs_info = sbi;
@@ -248,8 +249,10 @@ int autofs4_fill_super(struct super_block *s, void *data, 
int silent)
 * Get the root inode and dentry, but defer checking for errors.
 */
ino = autofs4_new_ino(sbi);
-   if (!ino)
+   if (!ino) {
+   ret = -ENOMEM;
goto fail_free;
+   }
root_inode = autofs4_get_inode(s, S_IFDIR | 0755);
root = d_make_root(root_inode);
if (!root)
@@ -296,7 +299,8 @@ int autofs4_fill_super(struct super_block *s, void *data, 
int silent)
printk("autofs: could not open pipe file descriptor\n");
goto fail_dput;
}
-   if (autofs_prepare_pipe(pipe) < 0)
+   ret = autofs_prepare_pipe(pipe);
+   if (ret < 0)
goto fail_fput;
sbi->pipe = pipe;
sbi->pipefd = pipefd;
@@ -323,8 +327,7 @@ fail_ino:
 fail_free:
kfree(sbi);
s->s_fs_info = NULL;
-fail_unlock:
-   return -EINVAL;
+   return ret;
 }
 
 struct inode *autofs4_get_inode(struct super_block *sb, umode_t mode)

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] autofs4 - fix device ioctl mount lookup

[Ian Kent]

When reconnecting to automounts at startup an autofs ioctl is used
to find the device and inode of existing mounts so they can be used
to open a file descriptor of possibly covered mounts.

At this time the the caller might not yet "own" the mount so it can
trigger calling ->d_automount(). This causes automount to hang when
trying to reconnect to direct or offset mount types.

Consequently kern_path() can't be used.

Signed-off-by: Ian Kent 
---
 fs/autofs4/dev-ioctl.c |   72 +---
 1 file changed, 62 insertions(+), 10 deletions(-)

diff --git a/fs/autofs4/dev-ioctl.c b/fs/autofs4/dev-ioctl.c
index 743c7c2..1d24e42 100644
--- a/fs/autofs4/dev-ioctl.c
+++ b/fs/autofs4/dev-ioctl.c
@@ -183,13 +183,67 @@ static int autofs_dev_ioctl_protosubver(struct file *fp,
return 0;
 }
 
+/*
+ * Lookup the the topmost path of a (possible) mount stack.
+ *
+ * kern_path() can't be used here because the caller might not
+ * "own" the automount dentry yet and we would end up calling
+ * back to ourself.
+ */
+static int kern_path_top(const char *pathname,
+unsigned int flags, struct path *path)
+{
+   struct dentry *dentry;
+   struct qstr name;
+   const char *tmp;
+   unsigned int len;
+   int err;
+
+   len = strlen(pathname);
+   if (len <= 1)
+   return -EINVAL;
+
+   tmp = pathname + len - 1;
+   len = 0;
+   if (*tmp == '/')
+   tmp--;
+   do {
+   if (*tmp == '/')
+   break;
+   len++;
+   } while (--tmp >= pathname);
+   tmp++;
+
+   err = kern_path(pathname, flags | LOOKUP_PARENT, path);
+   if (err)
+   return err;
+
+   name.name = tmp;
+   name.len = len;
+   name.hash = full_name_hash(tmp, len);
+
+   dentry = d_lookup(path->dentry, );
+   if (!dentry) {
+   path_put(path);
+   return -ENOENT;
+   }
+   dput(path->dentry);
+   path->dentry = dentry;
+
+   while (follow_down_one(path))
+   ;
+
+   return 0;
+}
+
+/* Find the topmost mount satisfying test() */
 static int find_autofs_mount(const char *pathname,
 struct path *res,
 int test(struct path *path, void *data),
 void *data)
 {
struct path path;
-   int err = kern_path(pathname, 0, );
+   int err = kern_path_top(pathname, 0, );
if (err)
return err;
err = -ENOENT;
@@ -197,10 +251,9 @@ static int find_autofs_mount(const char *pathname,
if (path.dentry->d_sb->s_magic == AUTOFS_SUPER_MAGIC) {
if (test(, data)) {
path_get();
-   if (!err) /* already found some */
-   path_put(res);
*res = path;
err = 0;
+   break;
}
}
if (!follow_up())
@@ -486,12 +539,11 @@ static int autofs_dev_ioctl_askumount(struct file *fp,
  * mount if there is one or 0 if it isn't a mountpoint.
  *
  * If we aren't supplied with a file descriptor then we
- * lookup the nameidata of the path and check if it is the
- * root of a mount. If a type is given we are looking for
- * a particular autofs mount and if we don't find a match
- * we return fail. If the located nameidata path is the
- * root of a mount we return 1 along with the super magic
- * of the mount or 0 otherwise.
+ * lookup the path and check if it is the root of a mount.
+ * If a type is given we are looking for a particular autofs
+ * mount and if we don't find a match we return fail. If the
+ * located path is the root of a mount we return 1 along with
+ * the super magic of the mount or 0 otherwise.
  *
  * In both cases the the device number (as returned by
  * new_encode_dev()) is also returned.
@@ -519,7 +571,7 @@ static int autofs_dev_ioctl_ismountpoint(struct file *fp,
 
if (!fp || param->ioctlfd == -1) {
if (autofs_type_any(type))
-   err = kern_path(name, LOOKUP_FOLLOW, );
+   err = kern_path_top(name, LOOKUP_FOLLOW, );
else
err = find_autofs_mount(name, , test_by_type, 
);
if (err)

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

Re: [PATCH 4/4] clk: tegra114: table driven PMC clock init

[Joseph Lo]

On Tue, 2013-09-03 at 21:31 +0800, Peter De Schrijver wrote:
> This patch converts the Tegra114 audio clock registration to be table driven
> like the periph clocks.
s/audio/PMC/ :)
> 
> Signed-off-by: Peter De Schrijver 
> ---
>  drivers/clk/tegra/clk-tegra114.c |   58 
> +++---
>  1 files changed, 23 insertions(+), 35 deletions(-)
> 
[snip]


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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: [Ksummit-2013-discuss] [PATCH] checkpatch: Add comment about updating Documentation/CodingStyle

[Fengguang Wu]

On Tue, Sep 03, 2013 at 12:09:31PM -0600, Bjorn Helgaas wrote:
> On Mon, Sep 2, 2013 at 6:39 PM, Fengguang Wu  wrote:
> 
> > Thanks! Yes I'm now running checkpatch these days because some people
> > suggested to me that some of the checkpatch warnings do help catch
> > real bugs.
> >
> > However I do try to avoid upsetting people with maybe-subjective
> > warnings. A checkpatch report will only be sent when a small fraction
> > of error types are detected. Comments are very welcome on how to
> > improve this list:
> 
> How hard would it be to make this configurable per-git tree?

It'd be trivial to do.

> I think the robot is quite useful and I don't push branches very
> often, so I'd probably be OK with just getting all the checkpatch
> warnings along with the build warnings and filtering the noise
> myself.  But I know other people have different styles and opinions.

Would you tell me the git tree/branches that would like to receive all
checkpatch warnings? It'll should be useful for our internal kernel
team, too.

Thanks,
Fengguang

> > MEMSET
> > IN_ATOMIC
> > UAPI_INCLUDE
> > MALFORMED_INCLUDE
> > SIZEOF_ADDRESS
> > KREALLOC_ARG_REUSE
> > EXECUTE_PERMISSIONS
> > ERROR:BAD_SIGN_OFF
> > LO_MACRO
> > HI_MACRO
> > CSYNC
> > SSYNC
> > HOTPLUG_SECTION
> > INDENTED_LABEL
> > INLINE_LOCATION
> > STORAGE_CLASS
> > USLEEP_RANGE
> > UNNECESSARY_CASTS
> > ALLOC_SIZEOF_STRUCT
> > KREALLOC_ARG_REUSE
> > USE_FUNC
> > LOCKDEP
> > EXPORTED_WORLD_WRITABLE
> > WHITESPACE_AFTER_LINE_CONTINUATION
> > MISSING_VMLINUX_SYMBOL
> > NEEDLESS_IF
> > PRINTF_L
> >
> > Once the decision is made to send a checkpatch error/warning, the
> > report email will use the triggering error (the one that matters) as
> > the email subject, with the complete output of checkpatch.pl included
> > in email body.
> >
> > Thanks,
> > Fengguang
> > ___
> > Ksummit-2013-discuss mailing list
> > ksummit-2013-disc...@lists.linuxfoundation.org
> > https://lists.linuxfoundation.org/mailman/listinfo/ksummit-2013-discuss
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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 10/11] x86: Restrict MSR access when module loading is restricted

[James Morris]

On Tue, 3 Sep 2013, Matthew Garrett wrote:

> Writing to MSRs should not be allowed if module loading is restricted,
> since it could lead to execution of arbitrary code in kernel mode. Based
> on a patch by Kees Cook.
> 
> Cc: Kees Cook 
> Signed-off-by: Matthew Garrett 


Reviewed-by: James Morris 



-- 
James Morris

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

Re: [PATCH V3 08/11] kexec: Disable at runtime if the kernel enforces module loading restrictions

[James Morris]

On Tue, 3 Sep 2013, Matthew Garrett wrote:

> kexec permits the loading and execution of arbitrary code in ring 0, which
> is something that module signing enforcement is meant to prevent. It makes
> sense to disable kexec in this situation.
> 
> Signed-off-by: Matthew Garrett 

Reviewed-by: James Morris 


-- 
James Morris

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