Re: [ANNOUNCE] 3.12.1-rt4
[ cut here ] WARNING: CPU: 1 PID: 10 at kernel/time/tick-sched.c:191 0x8107bac6() NO_HZ FULL will not work with unstable sched clock Modules linked in: CPU: 1 PID: 10 Comm: rcuop/0 Not tainted 3.12.2-rt4 #3 Hardware name: TYAN Computer Corp. S2895/S2895, BIOS 2004Q3 11/18/2008 0009 88027fc83ea8 81501a58 0039 88027fc83ef8 88027fc83ee8 8102f992 00012700 ata3.00: configured for UDMA/100 88027fc8d580 0001 880272894020 88027fc0d700 Call Trace: IRQ [81501a58] 0x81501a58 [8102f992] 0x8102f992 [8102fa61] 0x8102fa61 [8107bac6] 0x8107bac6 [8107c8f4] 0x8107c8f4 [8103405d] 0x8103405d [81006fff] 0x81006fff [815085f7] 0x815085f7 EOI [81007083] ? 0x81007083 [81506865] ? 0x81506865 [81095961] ? 0x81095961 [81095860] ? 0x81095860 [8104d0dd] 0x8104d0dd [8104d030] ? 0x8104d030 [8150763c] 0x8150763c [8104d030] ? 0x8104d030 ---[ end trace 53ca152639ff2a59 ]--- -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@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 1/3] power_supply: Add power_supply notifier
On Tue, Nov 19, 2013 at 11:18:03AM +0100, Pali Rohár wrote:
This patch adds a notifier chain to the power_supply.
This notifier helps drivers in other subsystem to listen to
changes in power supply subsystem. This would help to take some
actions in those drivers on changing the power supply properties.
One such scenario is to increase/decrease system performance based
on the battery capacity/voltage. Another scenario is to adjust the
h/w peak current detection voltage/current thresholds based on battery
voltage/capacity. The notifier helps drivers to listen to changes
in power_suppy susbystem without polling the power_supply properties
Signed-off-by: Jenny TC jenny...@intel.com
Signed-off-by: Pali Rohár pali.ro...@gmail.com
...
+enum power_supply_notifier_events {
+ PSY_EVENT_NONE,
This one is not needed.
+ PSY_EVENT_PROP_CHANGED,
+ PSY_EVENT_BATTERY,
+ PSY_EVENT_CABLE,
+};
The only event that is currently used in your patch series is
EVENT_PROP_CHANGED... So, I applied the patch with the following changes:
diff --git a/include/linux/power_supply.h b/include/linux/power_supply.h
index c6f52c0..0c2a260 100644
--- a/include/linux/power_supply.h
+++ b/include/linux/power_supply.h
@@ -15,6 +15,7 @@
#include linux/init.h
#include linux/slab.h
#include linux/device.h
+#include linux/notifier.h
#include linux/err.h
#include linux/power_supply.h
#include linux/thermal.h
@@ -159,10 +159,7 @@ enum power_supply_type {
};
enum power_supply_notifier_events {
- PSY_EVENT_NONE,
PSY_EVENT_PROP_CHANGED,
- PSY_EVENT_BATTERY,
- PSY_EVENT_CABLE,
};
union power_supply_propval {
@@ -242,7 +239,7 @@ struct power_supply_info {
int use_for_apm;
};
-extern struct atomic_notifier_headpower_supply_notifier;
+extern struct atomic_notifier_head power_supply_notifier;
extern int power_supply_reg_notifier(struct notifier_block *nb);
extern void power_supply_unreg_notifier(struct notifier_block *nb);
extern struct power_supply *power_supply_get_by_name(const char *name);
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@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] max17042: Fix build errors caused by missing REGMAP_I2C config
On Mon, Nov 25, 2013 at 09:40:04AM +0900, jonghwa3@samsung.com wrote: max17042 now uses regmap interface but does not enable config option. This patch fixes the following build errors: drivers/power/max17042_battery.c:661:15: error: variable ‘max17042_regmap_config’ has initializer but incomplete type Signed-off-by: Austin Boyle boyle.aus...@gmail.com --- diff --git a/drivers/power/Kconfig b/drivers/power/Kconfig index 5e2054a..85ad58c 100644 --- a/drivers/power/Kconfig +++ b/drivers/power/Kconfig @@ -196,6 +196,7 @@ config BATTERY_MAX17040 config BATTERY_MAX17042 tristate Maxim MAX17042/17047/17050/8997/8966 Fuel Gauge depends on I2C + select REGMAP_I2C help MAX17042 is fuel-gauge systems for lithium-ion (Li+) batteries in handheld and portable equipment. The MAX17042 is configured Sorry, It's my fault. Thanks. Acked-by: Jonghwa Lee jonghwa3@samsung.com 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 v2] irqchip: exynos-combiner: remove hard-coded irq_base value
On 11/25/13 15:37, Chander Kashyap wrote: Hi Kikjin, Hi Chander, On 21 October 2013 02:32, Kukjin Kimkgene@samsung.com wrote: On 10/18/13 02:53, Tomasz Figa wrote: Hi Kukjin, On Thursday 26 of September 2013 14:05:09 Kukjin Kim wrote: Chander Kashyap wrote: Replace irq_domain_add_simple with irq_domain_add_linear in order to use linear irq domain, and to remove hardcoded irq_base_value. Signed-off-by: Chander Kashyapchander.kash...@linaro.org --- Changes since v1: - Replaced irq_domain_add_simple with irq_domain_add_linear, as suggested by Tomasz drivers/irqchip/exynos-combiner.c | 15 +++ 1 file changed, 3 insertions(+), 12 deletions(-) [snip] Looks nice to me, applied with Tomasz's review. I don't see this patch in your tree. Did you apply it in the end? Thanks for your gentle reminder. I still can not see these patches in yours branches ? Oops, sorry for missing. This should be queued in next. Thanks. Kukjin -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@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: mac80211: tx.c: be sure of 'sdata-vif.type' must be NL80211_IFTYPE_AP when be in NL80211_IFTYPE_AP case
On Sun, 2013-12-01 at 10:35 +0100, Johannes Berg wrote: Good try, but no, now ap_sdata isn't even assigned. :) Right. Oh well. There's no improving this without significant rewrite. Even then, there may not be much overall improvement. btw: Chen, I think fall-throughs are fine as long as they are commented appropriately. -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2 2/3] bq2415x_charger: Use power_supply notifier for automode
On Mon, Nov 25, 2013 at 08:16:34PM +0100, Michael Trimarchi wrote: ... So you can read this value without any type of synchronization with the power_supply_core and sysfs implementation? ... https://lists.ubuntu.com/archives/kernel-team/2013-January/025206.html I found and equivalent scenario that I was trying to said That's a good question, actually. Even though in Pali's case the notifier is atomic (so that we are pretty confident that the object won't be unregistered), there is still a possiblity of a dead lock, for example. So notifiers should be careful to not hold any locks, because the other driver might call get_property(), which might acquire locks. Thanks, Anton -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
300,000.00 Eur
Congratulation Confirm your 300,000,00 Eur. Contact claims office via wucla...@126.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] Staging: TIDSPBRIDGE: Remove UUID helper
On 01.12.2013 21:06, Joe Perches wrote:
On Sun, 2013-12-01 at 19:07 +0200, Ivaylo DImitrov wrote:
From: Ivaylo Dimitrov freemangor...@abv.bg
Custom uuid helper function is needed only in rmgr/dbdcd.c and doesn't
need to be exported. It can also be made way simpler by using sscanf.
[]
diff --git a/drivers/staging/tidspbridge/rmgr/dbdcd.c
b/drivers/staging/tidspbridge/rmgr/dbdcd.c
[]
@@ -74,6 +74,40 @@ static int get_dep_lib_info(struct dcd_manager *hdcd_mgr,
enum nldr_phase phase);
/*
+ * dcd_uuid_from_string
+ * Purpose:
+ * Converts an ANSI string to a dsp_uuid.
+ * Parameters:
+ * sz_uuid:Pointer to a string that represents a dsp_uuid object.
+ * uuid_obj: Pointer to a dsp_uuid object.
+ * Returns:
+ * Requires:
+ * uuid_obj sz_uuid are non-NULL values.
+ * Ensures:
+ * Details:
+ * We assume the string representation of a UUID has the following format:
+ * 12345678_1234_1234_1234_123456789abc.
+ */
+static void dcd_uuid_from_string(char *sz_uuid, struct dsp_uuid *uuid_obj)
+{
+ char c;
+ u64 t;
+
+ /*
+* sscanf implementation cannot deal with hh format modifier
+* if the converted value doesn't fit in u32. So, convert the
+* last six bytes to u64 and memcpy what is needed
+*/
+ sscanf(sz_uuid, %8x%c%4hx%c%4hx%c%2hhx%2hhx%c%llx,
+ uuid_obj-data1, c, uuid_obj-data2, c,
+ uuid_obj-data3, c, uuid_obj-data4,
+ uuid_obj-data5, c, t);
+
+ t = cpu_to_be64(t);
+ memcpy(uuid_obj-data6[0], ((char*)t) + 2, 6);
+}
It'd probably be better to return true or false on
successful conversion, use a temporary struct dsp_uuid,
check the sscanf return is 10 and only copy to uuid_obj
on success.
Something like:
static bool dcd_uuid_from_string(char *sz_uuid, struct dsp_uuid *uuid_obj)
{
char c;
u64 t;
struct dsp_uuid tmp;
/*
* sscanf implementation cannot deal with hh format modifier
* if the converted value doesn't fit in u32. So, convert the
* last six bytes to u64 and memcpy what is needed
*/
if (sscanf(sz_uuid, %8x%c%4hx%c%4hx%c%2hhx%2hhx%c%llx,
tmp.data1, c, tmp.data2, c,
tmp.data3, c, tmp.data4,
tmp.data5, c, t) != 10)
return false;
t = cpu_to_be64(t);
memcpy(tmp.data6[0], ((char*)t) + 2, 6);
*uuid_obj = tmp;
return true;
}
If there is to be a return value from that function, it is better to be
int (-EINVAL/0), IMO. And I am not sure that makes much of a sense, as
(afaik) uuids are read from baseimage.dof and codec nodes, if those are
broken I suspect wrong uuids will be our least problem.
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@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/8] backlight: hp680_bl: use devm_backlight_device_register()
Use devm_backlight_device_register() to make cleanup paths simpler. Signed-off-by: Jingoo Han jg1@samsung.com --- drivers/video/backlight/hp680_bl.c |6 ++ 1 file changed, 2 insertions(+), 4 deletions(-) diff --git a/drivers/video/backlight/hp680_bl.c b/drivers/video/backlight/hp680_bl.c index 00076ec..8ea42b8 100644 --- a/drivers/video/backlight/hp680_bl.c +++ b/drivers/video/backlight/hp680_bl.c @@ -110,8 +110,8 @@ static int hp680bl_probe(struct platform_device *pdev) memset(props, 0, sizeof(struct backlight_properties)); props.type = BACKLIGHT_RAW; props.max_brightness = HP680_MAX_INTENSITY; - bd = backlight_device_register(hp680-bl, pdev-dev, NULL, - hp680bl_ops, props); + bd = devm_backlight_device_register(pdev-dev, hp680-bl, pdev-dev, + NULL, hp680bl_ops, props); if (IS_ERR(bd)) return PTR_ERR(bd); @@ -131,8 +131,6 @@ static int hp680bl_remove(struct platform_device *pdev) bd-props.power = 0; hp680bl_send_intensity(bd); - backlight_device_unregister(bd); - return 0; } -- 1.7.10.4 -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 1/8] backlight: jornada720: use devm_backlight_device_register()
Use devm_backlight_device_register() to make cleanup paths simpler,
and remove unnecessary remove().
Signed-off-by: Jingoo Han jg1@samsung.com
---
drivers/video/backlight/jornada720_bl.c | 15 +++
1 file changed, 3 insertions(+), 12 deletions(-)
diff --git a/drivers/video/backlight/jornada720_bl.c
b/drivers/video/backlight/jornada720_bl.c
index 3ccb893..6ce96b4 100644
--- a/drivers/video/backlight/jornada720_bl.c
+++ b/drivers/video/backlight/jornada720_bl.c
@@ -115,9 +115,10 @@ static int jornada_bl_probe(struct platform_device *pdev)
memset(props, 0, sizeof(struct backlight_properties));
props.type = BACKLIGHT_RAW;
props.max_brightness = BL_MAX_BRIGHT;
- bd = backlight_device_register(S1D_DEVICENAME, pdev-dev, NULL,
- jornada_bl_ops, props);
+ bd = devm_backlight_device_register(pdev-dev, S1D_DEVICENAME,
+ pdev-dev, NULL, jornada_bl_ops,
+ props);
if (IS_ERR(bd)) {
ret = PTR_ERR(bd);
dev_err(pdev-dev, failed to register device, err=%x\n, ret);
@@ -139,18 +140,8 @@ static int jornada_bl_probe(struct platform_device *pdev)
return 0;
}
-static int jornada_bl_remove(struct platform_device *pdev)
-{
- struct backlight_device *bd = platform_get_drvdata(pdev);
-
- backlight_device_unregister(bd);
-
- return 0;
-}
-
static struct platform_driver jornada_bl_driver = {
.probe = jornada_bl_probe,
- .remove = jornada_bl_remove,
.driver = {
.name = jornada_bl,
},
--
1.7.10.4
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 3/8] backlight: omap1: use devm_backlight_device_register()
Use devm_backlight_device_register() to make cleanup paths simpler,
and remove unnecessary remove().
Signed-off-by: Jingoo Han jg1@samsung.com
---
drivers/video/backlight/omap1_bl.c | 14 ++
1 file changed, 2 insertions(+), 12 deletions(-)
diff --git a/drivers/video/backlight/omap1_bl.c
b/drivers/video/backlight/omap1_bl.c
index ac11a46..a0dcd88 100644
--- a/drivers/video/backlight/omap1_bl.c
+++ b/drivers/video/backlight/omap1_bl.c
@@ -146,8 +146,8 @@ static int omapbl_probe(struct platform_device *pdev)
memset(props, 0, sizeof(struct backlight_properties));
props.type = BACKLIGHT_RAW;
props.max_brightness = OMAPBL_MAX_INTENSITY;
- dev = backlight_device_register(omap-bl, pdev-dev, bl, omapbl_ops,
- props);
+ dev = devm_backlight_device_register(pdev-dev, omap-bl, pdev-dev,
+ bl, omapbl_ops, props);
if (IS_ERR(dev))
return PTR_ERR(dev);
@@ -170,20 +170,10 @@ static int omapbl_probe(struct platform_device *pdev)
return 0;
}
-static int omapbl_remove(struct platform_device *pdev)
-{
- struct backlight_device *dev = platform_get_drvdata(pdev);
-
- backlight_device_unregister(dev);
-
- return 0;
-}
-
static SIMPLE_DEV_PM_OPS(omapbl_pm_ops, omapbl_suspend, omapbl_resume);
static struct platform_driver omapbl_driver = {
.probe = omapbl_probe,
- .remove = omapbl_remove,
.driver = {
.name = omap-bl,
.pm = omapbl_pm_ops,
--
1.7.10.4
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 5/8] backlight: tosa: use devm_backlight_device_register()
Use devm_backlight_device_register() to make cleanup paths simpler.
Signed-off-by: Jingoo Han jg1@samsung.com
---
drivers/video/backlight/tosa_bl.c |7 +++
1 file changed, 3 insertions(+), 4 deletions(-)
diff --git a/drivers/video/backlight/tosa_bl.c
b/drivers/video/backlight/tosa_bl.c
index b8db933..3ad6765 100644
--- a/drivers/video/backlight/tosa_bl.c
+++ b/drivers/video/backlight/tosa_bl.c
@@ -105,8 +105,9 @@ static int tosa_bl_probe(struct i2c_client *client,
memset(props, 0, sizeof(struct backlight_properties));
props.type = BACKLIGHT_RAW;
props.max_brightness = 512 - 1;
- data-bl = backlight_device_register(tosa-bl, client-dev, data,
-bl_ops, props);
+ data-bl = devm_backlight_device_register(client-dev, tosa-bl,
+ client-dev, data, bl_ops,
+ props);
if (IS_ERR(data-bl)) {
ret = PTR_ERR(data-bl);
goto err_reg;
@@ -128,9 +129,7 @@ static int tosa_bl_remove(struct i2c_client *client)
{
struct tosa_bl_data *data = i2c_get_clientdata(client);
- backlight_device_unregister(data-bl);
data-bl = NULL;
-
return 0;
}
--
1.7.10.4
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 4/8] backlight: ot200_bl: use devm_backlight_device_register()
Use devm_backlight_device_register() to make cleanup paths simpler.
Signed-off-by: Jingoo Han jg1@samsung.com
---
drivers/video/backlight/ot200_bl.c |9 +++--
1 file changed, 3 insertions(+), 6 deletions(-)
diff --git a/drivers/video/backlight/ot200_bl.c
b/drivers/video/backlight/ot200_bl.c
index fdbb6ee..f5a5202 100644
--- a/drivers/video/backlight/ot200_bl.c
+++ b/drivers/video/backlight/ot200_bl.c
@@ -118,8 +118,9 @@ static int ot200_backlight_probe(struct platform_device
*pdev)
props.brightness = 100;
props.type = BACKLIGHT_RAW;
- bl = backlight_device_register(dev_name(pdev-dev), pdev-dev, data,
- ot200_backlight_ops, props);
+ bl = devm_backlight_device_register(pdev-dev, dev_name(pdev-dev),
+ pdev-dev, data, ot200_backlight_ops,
+ props);
if (IS_ERR(bl)) {
dev_err(pdev-dev, failed to register backlight\n);
retval = PTR_ERR(bl);
@@ -137,10 +138,6 @@ error_devm_kzalloc:
static int ot200_backlight_remove(struct platform_device *pdev)
{
- struct backlight_device *bl = platform_get_drvdata(pdev);
-
- backlight_device_unregister(bl);
-
/* on module unload set brightness to 100% */
cs5535_mfgpt_write(pwm_timer, MFGPT_REG_COUNTER, 0);
cs5535_mfgpt_write(pwm_timer, MFGPT_REG_SETUP, MFGPT_SETUP_CNTEN);
--
1.7.10.4
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 6/8] backlight: jornada720: use devm_lcd_device_register()
Use devm_lcd_device_register() to make cleanup paths simpler,
and remove unnecessary remove().
Signed-off-by: Jingoo Han jg1@samsung.com
---
drivers/video/backlight/jornada720_lcd.c | 13 ++---
1 file changed, 2 insertions(+), 11 deletions(-)
diff --git a/drivers/video/backlight/jornada720_lcd.c
b/drivers/video/backlight/jornada720_lcd.c
index b061413..da3876c 100644
--- a/drivers/video/backlight/jornada720_lcd.c
+++ b/drivers/video/backlight/jornada720_lcd.c
@@ -100,7 +100,8 @@ static int jornada_lcd_probe(struct platform_device *pdev)
struct lcd_device *lcd_device;
int ret;
- lcd_device = lcd_device_register(S1D_DEVICENAME, pdev-dev, NULL,
jornada_lcd_props);
+ lcd_device = devm_lcd_device_register(pdev-dev, S1D_DEVICENAME,
+ pdev-dev, NULL, jornada_lcd_props);
if (IS_ERR(lcd_device)) {
ret = PTR_ERR(lcd_device);
@@ -119,18 +120,8 @@ static int jornada_lcd_probe(struct platform_device *pdev)
return 0;
}
-static int jornada_lcd_remove(struct platform_device *pdev)
-{
- struct lcd_device *lcd_device = platform_get_drvdata(pdev);
-
- lcd_device_unregister(lcd_device);
-
- return 0;
-}
-
static struct platform_driver jornada_lcd_driver = {
.probe = jornada_lcd_probe,
- .remove = jornada_lcd_remove,
.driver = {
.name = jornada_lcd,
},
--
1.7.10.4
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 8/8] backlight: tosa: use devm_lcd_device_register()
Use devm_lcd_device_register() to make cleanup paths simpler.
Signed-off-by: Jingoo Han jg1@samsung.com
---
drivers/video/backlight/tosa_lcd.c |6 ++
1 file changed, 2 insertions(+), 4 deletions(-)
diff --git a/drivers/video/backlight/tosa_lcd.c
b/drivers/video/backlight/tosa_lcd.c
index be5d636..f08d641 100644
--- a/drivers/video/backlight/tosa_lcd.c
+++ b/drivers/video/backlight/tosa_lcd.c
@@ -206,8 +206,8 @@ static int tosa_lcd_probe(struct spi_device *spi)
tosa_lcd_tg_on(data);
- data-lcd = lcd_device_register(tosa-lcd, spi-dev, data,
- tosa_lcd_ops);
+ data-lcd = devm_lcd_device_register(spi-dev, tosa-lcd, spi-dev,
+ data, tosa_lcd_ops);
if (IS_ERR(data-lcd)) {
ret = PTR_ERR(data-lcd);
@@ -226,8 +226,6 @@ static int tosa_lcd_remove(struct spi_device *spi)
{
struct tosa_lcd_data *data = spi_get_drvdata(spi);
- lcd_device_unregister(data-lcd);
-
if (data-i2c)
i2c_unregister_device(data-i2c);
--
1.7.10.4
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 7/8] backlight: l4f00242t03: use devm_lcd_device_register()
Use devm_lcd_device_register() to make cleanup paths simpler. Signed-off-by: Jingoo Han jg1@samsung.com --- drivers/video/backlight/l4f00242t03.c |6 ++ 1 file changed, 2 insertions(+), 4 deletions(-) diff --git a/drivers/video/backlight/l4f00242t03.c b/drivers/video/backlight/l4f00242t03.c index b5fc13b..63e7638 100644 --- a/drivers/video/backlight/l4f00242t03.c +++ b/drivers/video/backlight/l4f00242t03.c @@ -223,8 +223,8 @@ static int l4f00242t03_probe(struct spi_device *spi) return PTR_ERR(priv-core_reg); } - priv-ld = lcd_device_register(l4f00242t03, - spi-dev, priv, l4f_ops); + priv-ld = devm_lcd_device_register(spi-dev, l4f00242t03, spi-dev, + priv, l4f_ops); if (IS_ERR(priv-ld)) return PTR_ERR(priv-ld); @@ -243,8 +243,6 @@ static int l4f00242t03_remove(struct spi_device *spi) struct l4f00242t03_priv *priv = spi_get_drvdata(spi); l4f00242t03_lcd_power_set(priv-ld, FB_BLANK_POWERDOWN); - lcd_device_unregister(priv-ld); - return 0; } -- 1.7.10.4 -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2 2/3] bq2415x_charger: Use power_supply notifier for automode
Hi Anton On Sun, Dec 1, 2013 at 11:37 PM, Anton Vorontsov an...@enomsg.org wrote: On Mon, Nov 25, 2013 at 08:16:34PM +0100, Michael Trimarchi wrote: ... So you can read this value without any type of synchronization with the power_supply_core and sysfs implementation? ... https://lists.ubuntu.com/archives/kernel-team/2013-January/025206.html I found and equivalent scenario that I was trying to said That's a good question, actually. Even though in Pali's case the notifier is atomic (so that we are pretty confident that the object won't be unregistered), there is still a possiblity of a dead lock, for example. So So if the get_property is a sleeping function it will be a deadlock. Right? Michael notifiers should be careful to not hold any locks, because the other driver might call get_property(), which might acquire locks. Thanks, Anton -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] perf tool: Ensure forward progress unwinding frames
The dwarf option for callstacks is getting stuck on the unwind and showing
repeated frames. For example,
qemu-system-x86 13759 [001] 287663.084957: syscalls:sys_enter_futex: uaddr:
0x7f770a958700, op: 0x0081, val: 0x0001, utime: 0x7f75ea
7f7705fd23ea __lll_unlock_wake (/lib64/libpthread-2.14.90.so)
7f7705fcf045 _L_unlock_649 (/lib64/libpthread-2.14.90.so)
7f7705fcf045 _L_unlock_649 (/lib64/libpthread-2.14.90.so)
7f7705fcf045 _L_unlock_649 (/lib64/libpthread-2.14.90.so)
7f7705fcf045 _L_unlock_649 (/lib64/libpthread-2.14.90.so)
7f7705fcf045 _L_unlock_649 (/lib64/libpthread-2.14.90.so)
...
(Last frame repeats 126 times)
Catch that the same frame is hit multiple times and break out of the loop.
With this patch:
qemu-system-x86 13759 [001] 287663.084967: syscalls:sys_exit_futex: 0x1
7f7705fd23ea __lll_unlock_wake (/lib64/libpthread-2.14.90.so)
7f7705fcf045 _L_unlock_649 (/lib64/libpthread-2.14.90.so)
Signed-off-by: David Ahern dsah...@gmail.com
Cc: Jiri Olsa jo...@redhat.com
---
tools/perf/util/unwind.c | 5 +
1 file changed, 5 insertions(+)
diff --git a/tools/perf/util/unwind.c b/tools/perf/util/unwind.c
index 0efd5393de85..817ffc1f3a00 100644
--- a/tools/perf/util/unwind.c
+++ b/tools/perf/util/unwind.c
@@ -563,6 +563,7 @@ static int get_entries(struct unwind_info *ui,
unwind_entry_cb_t cb,
{
unw_addr_space_t addr_space;
unw_cursor_t c;
+ unw_word_t prev_ip = 0;
int ret;
addr_space = unw_create_addr_space(accessors, 0);
@@ -579,6 +580,10 @@ static int get_entries(struct unwind_info *ui,
unwind_entry_cb_t cb,
unw_word_t ip;
unw_get_reg(c, UNW_REG_IP, ip);
+ if (ip == prev_ip)
+ break;
+ prev_ip = ip;
+
ret = entry(ip, ui-thread, ui-machine, cb, arg);
}
--
1.8.3.4 (Apple Git-47)
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@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] perf probe: Allow user to specify address within executable
Allow user to specify an address within an executable. This is useful, for
example, in probing local functions. If the function name begins with 0x
then try to convert the supplied name to an address. If succuessful then
treat the function name as the address within the executable to be probed.
Signed-off-by: David Ahern dsah...@gmail.com
Cc: Masami Hiramatsu masami.hiramatsu...@hitachi.com
Cc: Srikar Dronamraju sri...@linux.vnet.ibm.com
---
tools/perf/Documentation/perf-probe.txt | 2 +-
tools/perf/util/probe-event.c | 37 +
2 files changed, 29 insertions(+), 10 deletions(-)
diff --git a/tools/perf/Documentation/perf-probe.txt
b/tools/perf/Documentation/perf-probe.txt
index b715cb71592b..ed500b311176 100644
--- a/tools/perf/Documentation/perf-probe.txt
+++ b/tools/perf/Documentation/perf-probe.txt
@@ -123,7 +123,7 @@ Probe points are defined by following syntax.
'EVENT' specifies the name of new event, if omitted, it will be set the name
of the probed function. Currently, event group name is set as 'probe'.
-'FUNC' specifies a probed function name, and it may have one of the following
options; '+OFFS' is the offset from function entry address in bytes, ':RLN' is
the relative-line number from function entry line, and '%return' means that it
probes function return. And ';PTN' means lazy matching pattern (see LAZY
MATCHING). Note that ';PTN' must be the end of the probe point definition. In
addition, '@SRC' specifies a source file which has that function.
+'FUNC' specifies a probed function name, and it may have one of the following
options; '+OFFS' is the offset from function entry address in bytes, ':RLN' is
the relative-line number from function entry line, and '%return' means that it
probes function return. And ';PTN' means lazy matching pattern (see LAZY
MATCHING). Note that ';PTN' must be the end of the probe point definition. In
addition, '@SRC' specifies a source file which has that function. If 'FUNC'
starts with 0x and the entire string converts to an unsigned long it is treated
as an address.
It is also possible to specify a probe point by the source line number or lazy
matching by using 'SRC:ALN' or 'SRC;PTN' syntax, where 'SRC' is the source file
path, ':ALN' is the line number and ';PTN' is the lazy matching pattern.
'ARG' specifies the arguments of this probe point, (see PROBE ARGUMENT).
diff --git a/tools/perf/util/probe-event.c b/tools/perf/util/probe-event.c
index 638071b7bdd2..000e535b3df2 100644
--- a/tools/perf/util/probe-event.c
+++ b/tools/perf/util/probe-event.c
@@ -2208,6 +2208,9 @@ static struct strfilter *available_func_filter;
static int filter_available_functions(struct map *map __maybe_unused,
struct symbol *sym)
{
+ if (available_func_filter == NULL)
+ return 0;
+
if (sym-binding == STB_GLOBAL
strfilter__compare(available_func_filter, sym-name))
return 0;
@@ -2281,9 +2284,10 @@ static int convert_name_to_addr(struct perf_probe_event
*pev, const char *exec)
struct perf_probe_point *pp = pev-point;
struct symbol *sym;
struct map *map = NULL;
- char *function = NULL, *name = NULL;
+ char *function = NULL, *name = NULL, *endptr;
int ret = -EINVAL;
unsigned long long vaddr = 0;
+ unsigned long fcn_addr = 0;
if (!pp-function) {
pr_warning(No function specified for uprobes);
@@ -2297,6 +2301,13 @@ static int convert_name_to_addr(struct perf_probe_event
*pev, const char *exec)
goto out;
}
+ /* perhaps an address was given instead of a function name */
+ if (strncmp(function, 0x, 2) == 0) {
+ fcn_addr = strtoul(function, endptr, 0);
+ if (endptr *endptr != '\0')
+ fcn_addr = 0;
+ }
+
name = realpath(exec, NULL);
if (!name) {
pr_warning(Cannot find realpath for %s.\n, exec);
@@ -2307,22 +2318,30 @@ static int convert_name_to_addr(struct perf_probe_event
*pev, const char *exec)
pr_warning(Cannot find appropriate DSO for %s.\n, exec);
goto out;
}
- available_func_filter = strfilter__new(function, NULL);
+
+ if (fcn_addr == 0)
+ available_func_filter = strfilter__new(function, NULL);
+
if (map__load(map, filter_available_functions)) {
pr_err(Failed to find requested function in %s. Perhaps it is
a local variable?\n,
name);
goto out;
}
- sym = map__find_symbol_by_name(map, function, NULL);
- if (!sym) {
- pr_warning(Cannot find %s in DSO %s\n, function, exec);
- goto out;
+ if (fcn_addr) {
+ vaddr = fcn_addr + pp-offset + map-pgoff;
+ } else {
+ sym = map__find_symbol_by_name(map, function, NULL);
Re: [PATCH 1/5] serial: 8250_pci: use DEFINE_PCI_DEVICE_TABLE macro
On Friday, November 29, 2013 10:34 AM, Jingoo Han wrote:
On Thursday, November 28, 2013 3:24 PM, Joe Perches wrote:
On Wed, 2013-11-27 at 21:53 -0800, 'Greg Kroah-Hartman' wrote:
On Wed, Nov 27, 2013 at 09:40:13PM -0800, Joe Perches wrote:
On Thu, 2013-11-28 at 14:29 +0900, Jingoo Han wrote:
On Thursday, November 28, 2013 1:08 PM, Greg Kroah-Hartman wrote:
On Thu, Nov 28, 2013 at 10:55:35AM +0900, Jingoo Han wrote:
This macro is used to create a struct pci_device_id array.
Yeah, and it's a horrid macro that deserves to be removed, please don't
use it in more places.
Actually, if you could just remove it, that would be best, sorry, I'm
not going to take these patches.
(+cc Joe Perches, Andrew Morton, Andy Whitcroft)
Hi Joe Perches,
Would you fix checkpatch.pl about DEFINE_PCI_DEVICE_TABLE?
Currently, checkpatch.pl guides to use DEFINE_PCI_DEVICE_TABLE
as below.
WARNING: Use DEFINE_PCI_DEVICE_TABLE for struct pci_device_id
#331: FILE: drivers/usb/host/ehci-pci.c:331:
+static const struct pci_device_id pci_ids [] = { {
However, Greg Kroah-Hartman mentioned that DEFINE_PCI_DEVICE_TABLE
shouldn't be used anymore.
So, would you change checkpatch.pl in order to guide to use
struct pci_device_id instead of DEFINE_PCI_DEVICE_TABLE?
For example,
WARNING: Use struct pci_device_id instead of DEFINE_PCI_DEVICE_TABLE
The documentation doesn't agree with Greg.
[]
I say just remove it, I should have done that years ago when I was the
PCI maintainer, just never got around to it. No other bus has something
like this for their device ids, why should PCI be special?
Anyone else have an opinion?
I don't care one way or another, but please, one way
not two.
(+cc Bjorn Helgaas, linux-pci)
Then, how about the following steps?
1. Fix ./Documentation/PCI/pci.txt as below.
(Jingoo Han)
The ID table is an array of struct pci_device_id entries ending with an
-all-zero entry; use of the macro DEFINE_PCI_DEVICE_TABLE is the preferred
-method of declaring the table. Each entry consists of:
+all-zero entry; Each entry consists of:
2. Fix ./scripts/checkpatch.pl in order to guide to use
struct pci_device_id instead of DEFINE_PCI_DEVICE_TABLE.
(Joe Perches)
If all DEFINE_PCI_DEVICE_TABLEs are replaced with 'const struct pci_device_id'
and these patches are merged through 'driver-core.git', it will be not
necessary to fix ./scripts/checkpatch.pl.
Then, I will send patches to Greg Kroah-Hartman, with CC'ing each subsystem
maintainer.
Best regards,
Jingoo Han
3. Replace DEFINE_PCI_DEVICE_TABLE of ./drivers/*
with 'const struct pci_device_id'.
(Jingoo Han)
4. These patches will be merged through 'driver-core.git'
with 'Acked-by' of each subsystem maintainer.
(Greg Kroah-Hartman)
Best regards,
Jingoo Han
Changing checkpatch is a trifle, but there are a _lot_
of maintainers to work through if it's to be removed.
It'll probably take several releases.
$ git grep --name-only -w DEFINE_PCI_DEVICE_TABLE | \
cut -f1,2 -d/ | uniq -c
1 Documentation/PCI
1 arch/x86
1 drivers/bcma
3 drivers/block
1 drivers/char
1 drivers/cpufreq
2 drivers/dma
18 drivers/edac
6 drivers/gpio
6 drivers/gpu
6 drivers/hwmon
20 drivers/i2c
2 drivers/infiniband
1 drivers/ipack
1 drivers/leds
3 drivers/media
10 drivers/mfd
2 drivers/misc
1 drivers/mmc
1 drivers/mtd
132 drivers/net
1 drivers/ntb
1 drivers/pci
5 drivers/pcmcia
2 drivers/platform
1 drivers/ptp
1 drivers/rapidio
7 drivers/scsi
3 drivers/spi
65 drivers/staging
3 drivers/tty
1 drivers/uio
5 drivers/usb
1 drivers/video
1 drivers/virtio
3 drivers/vme
9 drivers/watchdog
1 drivers/xen
1 include/linux
1 scripts/checkpatch.pl
1 scripts/tags.sh
1 sound/oss
67 sound/pci
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 1/2] perf probe: Improve error message when function not found
When requesting a function from a userspace library the error message to
the user is less than helpful. e.g.,
perf probe -x /lib64/libpthread-2.14.90.so -a
'lock_full=__pthread_mutex_lock_full'
no symbols found in /lib64/libpthread-2.14.90.so, maybe install a debug
package?
Failed to load map.
Error: Failed to add events. (-22)
In this cae the symbol really does exist but is a local symbol which is
filtered:
nm /lib64/libpthread-2.14.90.so | grep __pthread_mutex_lock_full
5700 t __pthread_mutex_lock_full
With this patch:
perf probe -x /lib64/libpthread-2.14.90.so -a
'lock_full=__pthread_mutex_lock_full'
no symbols found in /lib64/libpthread-2.14.90.so, maybe install a debug
package?
Failed to find function in /lib64/libpthread-2.14.90.so. Perhaps it is a
local variable?
Error: Failed to add events. (-22)
Signed-off-by: David Ahern dsah...@gmail.com
Cc: Masami Hiramatsu masami.hiramatsu...@hitachi.com
Cc: Srikar Dronamraju sri...@linux.vnet.ibm.com
---
tools/perf/util/probe-event.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/tools/perf/util/probe-event.c b/tools/perf/util/probe-event.c
index 9c6989ca2bea..638071b7bdd2 100644
--- a/tools/perf/util/probe-event.c
+++ b/tools/perf/util/probe-event.c
@@ -2309,7 +2309,8 @@ static int convert_name_to_addr(struct perf_probe_event
*pev, const char *exec)
}
available_func_filter = strfilter__new(function, NULL);
if (map__load(map, filter_available_functions)) {
- pr_err(Failed to load map.\n);
+ pr_err(Failed to find requested function in %s. Perhaps it is
a local variable?\n,
+ name);
goto out;
}
--
1.8.3.4 (Apple Git-47)
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 0/2] perf: sched timehist command - v2
Addressed comments by Namhyung (thank you!). David Ahern (2): perf sched: Introduce timehist command - v2 perf sched: Add documentation for timehist options tools/perf/Documentation/perf-sched.txt | 61 ++- tools/perf/builtin-sched.c | 932 +++- tools/perf/perf.h | 3 + 3 files changed, 994 insertions(+), 2 deletions(-) -- 1.8.3.4 (Apple Git-47) -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@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] perf sched: Add documentation for timehist options
Add entry to perf-sched documentation for timehist command and its
options.
v2: Addressed comments by Namhyung
Signed-off-by: David Ahern dsah...@gmail.com
Cc: Ingo Molnar mi...@kernel.org
Cc: Frederic Weisbecker fweis...@gmail.com
Cc: Peter Zijlstra a.p.zijls...@chello.nl
Cc: Mike Galbraith efa...@gmx.de
Cc: Jiri Olsa jo...@redhat.com
Cc: Namhyung Kim namhy...@kernel.org
Cc: Stephane Eranian eran...@google.com
Cc: Pekka Enberg penb...@kernel.org
---
tools/perf/Documentation/perf-sched.txt | 61 -
1 file changed, 60 insertions(+), 1 deletion(-)
diff --git a/tools/perf/Documentation/perf-sched.txt
b/tools/perf/Documentation/perf-sched.txt
index 8ff4df956951..e7bb19fcdbff 100644
--- a/tools/perf/Documentation/perf-sched.txt
+++ b/tools/perf/Documentation/perf-sched.txt
@@ -8,7 +8,7 @@ perf-sched - Tool to trace/measure scheduler properties
(latencies)
SYNOPSIS
[verse]
-'perf sched' {record|latency|map|replay|script}
+'perf sched' {record|latency|map|replay|script|timehist}
DESCRIPTION
---
@@ -36,6 +36,11 @@ There are five variants of perf sched:
are running on a CPU. A '*' denotes the CPU that had the event, and
a dot signals an idle CPU.
+ 'perf sched timehist' to show context-switching analysis with times
+ between schedule-in, schedule delay, and run time. If callchains are
+ present stack trace is dumped at the end of the line. A summary of
+ run times can be shown as well.
+
OPTIONS
---
-i::
@@ -50,6 +55,60 @@ OPTIONS
--dump-raw-trace=::
Display verbose dump of the sched data.
+TIMEHIST OPTIONS
+
+-k::
+--vmlinux=file::
+vmlinux pathname
+
+--kallsyms=file::
+kallsyms pathname
+
+-s::
+--summary::
+Show only a summary of scheduling by thread with min, max, and average
+run times (in sec) and relative stddev.
+
+-S::
+--with-summary::
+Show all scheduling events followed by a summary by thread with min,
+max, and average run times (in sec) and relative stddev.
+
+-w::
+--wakeups::
+Show wakeup events.
+
+-c::
+--comms=::
+Only show events for given comms (comma separated list)
+
+-p::
+--pid=::
+Only show events for given process ID (comma separated list).
+
+-t::
+--tid=::
+Only show events for given thread ID (comma separated list).
+
+--call-graph::
+Display call chains. Default is on. Use --no-call-graph to suppress
+
+--max-stack::
+Set the stack depth limit when showing the callchains. Default: 127
+
+-x::
+--exclude-sym::
+Symbols to skip in backtrace. Useful to compact repetitive or
+uninteresting frames to pull more useful frames into view.
+
+--symfs=directory::
+Look for files with symbols relative to this directory.
+
+-V::
+--cpu-visual::
+Add a visual that better emphasizes activity by cpu. Idle times
+are denoted with 'i'; schedule events with an 's'.
+
SEE ALSO
linkperf:perf-record[1]
--
1.8.3.4 (Apple Git-47)
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 1/2] perf sched: Introduce timehist command - v2
'perf sched timehist' provides an analysis of scheduling events.
Example usage:
perf sched record -- sleep 1
perf sched timehist
By default it shows the individual schedule events, including the time between
sched-in events for the task, the task scheduling delay (time between wakeup
and actually running) and run time for the task:
time cpu task name[tid/pid]b/n time sch delay run time
- - - -
79371.874569 [11] gcc[31949] 0.014 0.000 1.148
79371.874591 [10] gcc[31951] 0.000 0.000 0.024
79371.874603 [10] migration/10[59] 3.350 0.004 0.011
79371.874604 [11] idle 1.148 0.000 0.035
79371.874723 [05] idle 0.016 0.000 1.383
79371.874746 [05] gcc[31949] 0.153 0.078 0.022
...
Times are in msec.usec.
If callchains were recorded they are appended to the line with a default stack
depth of 5:
79371.874569 [11] gcc[31949] 0.14 0.00 0.001148
wait_for_completion_killable do_fork sys_vfork stub_vfork __vfork
79371.874591 [10] gcc[31951] 0.00 0.00 0.24
__cond_resched _cond_resched wait_for_completion stop_one_cpu sched_exec
79371.874603 [10] migration/10[59]0.003350 0.04 0.11
smpboot_thread_fn kthread ret_from_fork
79371.874604 [11] idle 0.001148 0.00 0.35
cpu_startup_entry start_secondary
79371.874723 [05] idle 0.16 0.00 0.001383
cpu_startup_entry start_secondary
79371.874746 [05] gcc[31949] 0.000153 0.78 0.22
do_wait sys_wait4 system_call_fastpath __GI___waitpid
--no-call-graph can be used to not show the callchains. --max-stack is used
to control the number of frames shown (default of 5). -x/--excl options can
be used to collapse redundant callchains to get more relevant data on screen.
Similar to perf-trace -s and -S can be used to dump a statistical summary
without or with events (respectively). Statistics include min run time,
average run time and max run time. Stats are also shown for run time by
cpu.
The cpu-visual option provides a visual aid for sched switches by cpu:
...
79371.874569 [11]s gcc[31949] 0.14
0.00 0.001148
79371.874591 [10] s gcc[31951] 0.00
0.00 0.24
79371.874603 [10] s migration/10[59]0.003350
0.04 0.11
79371.874604 [11]i idle 0.001148
0.00 0.35
79371.874723 [05] iidle 0.16
0.00 0.001383
79371.874746 [05] sgcc[31949] 0.000153
0.78 0.22
...
Additional options:
- -w option can be used to include a dump of wakeup events
- -c comm to only display events and stats for the given comm (csv list)
- -p/-t to only display events and stats for given pid/tid (csv list)
v2:
- Addressed Namhyung's comments
- changed times to be in msec.usec versus sec.usec to be consistent with
other perf commands
Signed-off-by: David Ahern dsah...@gmail.com
Cc: Ingo Molnar mi...@kernel.org
Cc: Frederic Weisbecker fweis...@gmail.com
Cc: Peter Zijlstra a.p.zijls...@chello.nl
Cc: Mike Galbraith efa...@gmx.de
Cc: Jiri Olsa jo...@redhat.com
Cc: Namhyung Kim namhy...@kernel.org
Cc: Stephane Eranian eran...@google.com
Cc: Pekka Enberg penb...@kernel.org
---
tools/perf/builtin-sched.c | 932 -
tools/perf/perf.h | 3 +
2 files changed, 934 insertions(+), 1 deletion(-)
diff --git a/tools/perf/builtin-sched.c b/tools/perf/builtin-sched.c
index 0f3c65518a2c..abcb40a44151 100644
--- a/tools/perf/builtin-sched.c
+++ b/tools/perf/builtin-sched.c
@@ -16,6 +16,9 @@
#include util/debug.h
+#include util/strlist.h
+#include util/intlist.h
+#include asm/bug.h
#include sys/prctl.h
#include sys/resource.h
@@ -169,8 +172,49 @@ struct perf_sched {
u64 cpu_last_switched[MAX_CPUS];
struct rb_root atom_root, sorted_atom_root;
struct list_head sort_list, cmp_pid;
+
+ /* options for timehist command */
+ boolsummary;
+ boolsummary_only;
+ boolshow_callchain;
+ unsigned intmax_stack;
+ boolshow_cpu_visual;
+ boolshow_wakeups;
+ /* process and task id's of interest */
+ struct target target;
+ struct intlist *pid, *tid;
+};
+
+/* used in symbol filter */
+static const char *excl_sym_list_str;
+static struct strlist *excl_sym_list;
+
+/* per thread run time data */
+struct thread_runtime {
+ u64 last_time; /* time of previous sched in/out event */
+ u64 dt_run; /* run
Re: [PATCH v2 2/3] bq2415x_charger: Use power_supply notifier for automode
On Mon, Dec 02, 2013 at 01:02:40AM +0100, Michael Trimarchi wrote: On Sun, Dec 1, 2013 at 11:37 PM, Anton Vorontsov an...@enomsg.org wrote: On Mon, Nov 25, 2013 at 08:16:34PM +0100, Michael Trimarchi wrote: ... So you can read this value without any type of synchronization with the power_supply_core and sysfs implementation? ... https://lists.ubuntu.com/archives/kernel-team/2013-January/025206.html I found and equivalent scenario that I was trying to said That's a good question, actually. Even though in Pali's case the notifier is atomic (so that we are pretty confident that the object won't be unregistered), there is still a possiblity of a dead lock, for example. So So if the get_property is a sleeping function it will be a deadlock. Right? All kind of bad things might happen, yes. But before that I would expect a bunch of warnings from might_sleep() stuff. I would recommend to test the patches using preempt/smp kernels + various DEBUG_ kernel options set. Thanks, Anton -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] drivers: scsi: scsi_lib.c: add prefix SCSILIB_ to macro SP
On 12/02/2013 12:17 AM, Bart Van Assche wrote:
On 11/27/13 03:29, Chen Gang wrote:
the macro SP is too common to make conflict with some architectures,
so recommend to add prefix for it.
The related warning (with allmodconfig for hexagon):
CC [M] drivers/scsi/scsi_lib.o
drivers/scsi/scsi_lib.c:46:0: warning: SP redefined [enabled by default]
arch/hexagon/include/uapi/asm/registers.h:9:0: note: this is the location
of the previous definition
Signed-off-by: Chen Gang gang.chen.5...@gmail.com
---
drivers/scsi/scsi_lib.c | 16
1 files changed, 8 insertions(+), 8 deletions(-)
diff --git a/drivers/scsi/scsi_lib.c b/drivers/scsi/scsi_lib.c
index 7bd7f0d..f78e21b 100644
--- a/drivers/scsi/scsi_lib.c
+++ b/drivers/scsi/scsi_lib.c
@@ -43,28 +43,28 @@ struct scsi_host_sg_pool {
mempool_t *pool;
};
-#define SP(x) { x, sgpool- __stringify(x) }
+#define SCSILIB_SP(x) { x, sgpool- __stringify(x) }
#if (SCSI_MAX_SG_SEGMENTS 32)
#error SCSI_MAX_SG_SEGMENTS is too small (must be 32 or greater)
#endif
static struct scsi_host_sg_pool scsi_sg_pools[] = {
-SP(8),
-SP(16),
+SCSILIB_SP(8),
+SCSILIB_SP(16),
#if (SCSI_MAX_SG_SEGMENTS 32)
-SP(32),
+SCSILIB_SP(32),
#if (SCSI_MAX_SG_SEGMENTS 64)
-SP(64),
+SCSILIB_SP(64),
#if (SCSI_MAX_SG_SEGMENTS 128)
-SP(128),
+SCSILIB_SP(128),
#if (SCSI_MAX_SG_SEGMENTS 256)
#error SCSI_MAX_SG_SEGMENTS is too large (256 MAX)
#endif
#endif
#endif
#endif
-SP(SCSI_MAX_SG_SEGMENTS)
+SCSILIB_SP(SCSI_MAX_SG_SEGMENTS)
};
-#undef SP
+#undef SCSILIB_SP
struct kmem_cache *scsi_sdb_cache;
Sorry but the SCSILIB_SP name doesn't look very descriptive to me.
There are probably better choices possible. How about using e.g.
SG_POOL() instead ?
That sounds good to me, I will send patch v2, tomorrow (today I have
to do some another urgent things, if this patch is also urgent, please
help send). :-)
Thanks.
--
Chen Gang
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] net: mac80211: tx.c: be sure of 'sdata-vif.type' must be NL80211_IFTYPE_AP when be in NL80211_IFTYPE_AP case
On 12/02/2013 06:38 AM, Joe Perches wrote: On Sun, 2013-12-01 at 10:35 +0100, Johannes Berg wrote: Good try, but no, now ap_sdata isn't even assigned. :) Right. Oh well. There's no improving this without significant rewrite. Even then, there may not be much overall improvement. btw: Chen, I think fall-throughs are fine as long as they are commented appropriately. Hmm... for me, when use fall-through, need 2 things: - need a comment. - next case need not notice about prev case which fall-through. If we can not fit the 2 things above, either can not use sub functions or macros for it because of performance reason, 'goto' is better than 'fall-through'. For me, in most cases, when a function becomes a long function, it is always better to use sub-fuctions or macros instead of some blocks (but it is really not urgent :-) ). Thanks. -- Chen Gang -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] drivers: scsi: scsi_lib.c: add prefix SCSILIB_ to macro SP
On Mon, 2013-12-02 at 08:34 +0800, Chen Gang wrote:
On 12/02/2013 12:17 AM, Bart Van Assche wrote:
On 11/27/13 03:29, Chen Gang wrote:
the macro SP is too common to make conflict with some architectures,
so recommend to add prefix for it.
The related warning (with allmodconfig for hexagon):
CC [M] drivers/scsi/scsi_lib.o
drivers/scsi/scsi_lib.c:46:0: warning: SP redefined [enabled by
default]
arch/hexagon/include/uapi/asm/registers.h:9:0: note: this is the
location of the previous definition
Signed-off-by: Chen Gang gang.chen.5...@gmail.com
---
drivers/scsi/scsi_lib.c | 16
1 files changed, 8 insertions(+), 8 deletions(-)
diff --git a/drivers/scsi/scsi_lib.c b/drivers/scsi/scsi_lib.c
index 7bd7f0d..f78e21b 100644
--- a/drivers/scsi/scsi_lib.c
+++ b/drivers/scsi/scsi_lib.c
@@ -43,28 +43,28 @@ struct scsi_host_sg_pool {
mempool_t *pool;
};
-#define SP(x) { x, sgpool- __stringify(x) }
+#define SCSILIB_SP(x) { x, sgpool- __stringify(x) }
#if (SCSI_MAX_SG_SEGMENTS 32)
#error SCSI_MAX_SG_SEGMENTS is too small (must be 32 or greater)
#endif
static struct scsi_host_sg_pool scsi_sg_pools[] = {
- SP(8),
- SP(16),
+ SCSILIB_SP(8),
+ SCSILIB_SP(16),
#if (SCSI_MAX_SG_SEGMENTS 32)
- SP(32),
+ SCSILIB_SP(32),
#if (SCSI_MAX_SG_SEGMENTS 64)
- SP(64),
+ SCSILIB_SP(64),
#if (SCSI_MAX_SG_SEGMENTS 128)
- SP(128),
+ SCSILIB_SP(128),
#if (SCSI_MAX_SG_SEGMENTS 256)
#error SCSI_MAX_SG_SEGMENTS is too large (256 MAX)
#endif
#endif
#endif
#endif
- SP(SCSI_MAX_SG_SEGMENTS)
+ SCSILIB_SP(SCSI_MAX_SG_SEGMENTS)
};
-#undef SP
+#undef SCSILIB_SP
struct kmem_cache *scsi_sdb_cache;
Sorry but the SCSILIB_SP name doesn't look very descriptive to me.
There are probably better choices possible. How about using e.g.
SG_POOL() instead ?
That sounds good to me, I will send patch v2, tomorrow (today I have
to do some another urgent things, if this patch is also urgent, please
help send). :-)
No, this is the wrong thing to do. Exported headers should be namespace
protected, so the thing wrong is what's exporting the problem to us,
namely hexagon.
James
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@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 drm-intel tree with the drm-intel-fixes tree
Hi all, Today's linux-next merge of the drm-intel tree got a conflict in drivers/gpu/drm/i915/intel_display.c between commit a1216444283e (drm/i915: use the correct force_wake function at the PC8 code) from the drm-intel-fixes tree and commit c8d9a5905e45 (drm/i915: Add power well arguments to force wake routines) from the drm-intel tree. I fixed it up (I just used the drm-intel-fixes version) and can carry the fix as necessary (no action is required). -- Cheers, Stephen Rothwells...@canb.auug.org.au pgpeoWOtiXT5q.pgp Description: PGP signature
Re: [PATCH] PCI / tg3: Give up chip reset and carrier loss handling if PCI device is not present
On Sunday, December 01, 2013 12:39:19 PM Michael Chan wrote: On Sun, 2013-12-01 at 02:34 +0100, Rafael J. Wysocki wrote: From: Rafael J. Wysocki rafael.j.wyso...@intel.com Modify tg3_chip_reset() and tg3_close() to check if the PCI network adapter device is accessible at all in order to skip poking it or trying to handle a carrier loss in vain when that's not the case. Introduce a special PCI helper function pci_device_is_present() for this purpose. Of course, this uncovers the lack of the appropriate RTNL locking in tg3_suspend() and tg3_resume(), so add that locking in there too. These changes prevent tg3 from burning a CPU at 100% load level for solid several seconds after the Thunderbolt link is disconnected from a Matrox DS1 docking station. I'm not familiar with the DS1. Does the tg3 device get removed through tg3_remove_one() in this case? Yes, this is a normal removal except that the device is gone physically when it happens. Thunderbolt cable disconnect is like a power failure for all devices on the link (that is, all devices in the DS1 in this particular case). What happens when you reconnect the DS1? Well, it works. ACPIPHP just waits for the removal to complete and then it handles the hot-add event and the device works normally after that. The only problem is that without the patch the hot-removal takes a few seconds and quite a lot of CPU power due to the tight loop spinning in tg3_carrier_off() called by tg3_close(), while with the patch it just happens almost instantaneously. And in the Thunderbolt disconnect case doing the entire tg3_chip_reset() is pointless anyway, because the config space of the device is not available then. Thanks! -- I speak only for myself. Rafael J. Wysocki, Intel Open Source Technology Center. -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@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] perf Makefile: Correct the message in feature-libnuma checking.
ccing linux-kernel@vger.kernel.org On 11/29/2013 01:14 PM, Arnaldo Carvalho de Melo wrote: Em Fri, Nov 29, 2013 at 04:05:52PM -0500, Dongsheng Yang escreveu: The package required for numa is named numactl-devel in Fedora and RHEL and libnuma-devel in OpenSuSE. This patch correct the package name in warning message. Applying, but please always CC linux-kernel@vger.kernel.org, so that others can review it as well. Okey!! Thanx Arnaldo. - Arnaldo Signed-off-by: Dongsheng Yang yangds.f...@cn.fujitsu.com --- tools/perf/config/Makefile | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/tools/perf/config/Makefile b/tools/perf/config/Makefile index 80ea6d8..2e615d8 100644 --- a/tools/perf/config/Makefile +++ b/tools/perf/config/Makefile @@ -537,7 +537,7 @@ endif ifndef NO_LIBNUMA ifeq ($(feature-libnuma), 0) -msg := $(warning No numa.h found, disables 'perf bench numa mem' benchmark, please install numa-libs-devel or libnuma-dev); +msg := $(warning No numa.h found, disables 'perf bench numa mem' benchmark, please install numactl-devel or libnuma-devel); NO_LIBNUMA := 1 else CFLAGS += -DHAVE_LIBNUMA_SUPPORT -- 1.8.2.1 -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: linux-next: manual merge of the drm-intel tree with the drm-intel-fixes tree
On Mon, 2 Dec 2013 12:04:37 +1100 Stephen Rothwell s...@canb.auug.org.au
wrote:
Today's linux-next merge of the drm-intel tree got a conflict in
drivers/gpu/drm/i915/intel_display.c between commit a1216444283e
(drm/i915: use the correct force_wake function at the PC8 code) from
the drm-intel-fixes tree and commit c8d9a5905e45 (drm/i915: Add power
well arguments to force wake routines) from the drm-intel tree.
I fixed it up (I just used the drm-intel-fixes version) and can carry the
fix as necessary (no action is required).
Actually, I ended up doing the below.
--
Cheers,
Stephen Rothwells...@canb.auug.org.au
diff --cc drivers/gpu/drm/i915/intel_display.c
index 080f6fd4e839,0332d7ca892d..
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@@ -6402,7 -6583,7 +6583,7 @@@ static void hsw_restore_lcpll(struct dr
/* Make sure we're not on PC8 state before disabling PC8, otherwise
* we'll hang the machine! */
- gen6_gt_force_wake_get(dev_priv);
- dev_priv-uncore.funcs.force_wake_get(dev_priv, FORCEWAKE_ALL);
++ gen6_gt_force_wake_get(dev_priv, FORCEWAKE_ALL);
if (val LCPLL_POWER_DOWN_ALLOW) {
val = ~LCPLL_POWER_DOWN_ALLOW;
@@@ -6436,7 -6617,7 +6617,7 @@@
DRM_ERROR(Switching back to LCPLL failed\n);
}
- gen6_gt_force_wake_put(dev_priv);
- dev_priv-uncore.funcs.force_wake_put(dev_priv, FORCEWAKE_ALL);
++ gen6_gt_force_wake_put(dev_priv, FORCEWAKE_ALL);
}
void hsw_enable_pc8_work(struct work_struct *__work)
pgpNHm_MzB43R.pgp
Description: PGP signature
Re: [PATCH v2 04/10] PCI: Destroy pci dev only once
On Sunday, December 01, 2013 02:24:33 AM Rafael J. Wysocki wrote: On Saturday, November 30, 2013 02:27:15 PM Yinghai Lu wrote: On Sat, Nov 30, 2013 at 1:37 PM, Rafael J. Wysocki r...@rjwysocki.net wrote: On Saturday, November 30, 2013 01:31:33 AM Rafael J. Wysocki wrote: On Saturday, November 30, 2013 12:45:55 AM Rafael J. Wysocki wrote: On Saturday, November 30, 2013 12:38:26 AM Rafael J. Wysocki wrote: On Tuesday, November 26, 2013 06:26:54 PM Yinghai Lu wrote: On Tue, Nov 26, 2013 at 5:24 PM, Rafael J. Wysocki r...@rjwysocki.net wrote: So assume pci_destroy_dev() is called twice in parallel for the same dev by two different threads. Thread 1 does the atomic_inc_and_test() and finds that it is OK to do the device_del() and put_device() which causes the device object to be freed. Then thread 2 does the atomic_inc_and_test() on the already freed device object and crashes the kernel. thread2 should still hold one extra reference. that is in device_schedule_callback == sysfs_schedule_callback == kobject_get(kobj) pci_destroy_dev for thread2 is called at this point. and that reference will be released from sysfs_schedule_callback == kobject_put()... Well, that would be the case if thread 2 was started by device_schedule_callback(), but again, for example, it may be trim_stale_devices() started by acpiphp_check_bridge() that doesn't hold extra references to the pci_dev. [Well, that piece of code is racy anyway, because it walks bus-devices without locking. Which is my fault too, because I overlooked that. Shame, shame.] can you add extra reference to that path? hotplug_event_work() hotplug_event() acpiphp_check_bridge() trim_stale_devices() pci_stop_and_remove_bus_device() Yes, it should hold a reference to dev, but adding it there doesn't really help, because there are list walks over bus-devices in acpiphp_check_bridge() and trim_stale_devices() that are racy with respect to pci_stop_and_remove_bus_device() run from device_schedule_callback(). Perhaps we can do something like the (untested) patch below (in addition to the $subject patch). Do you see any immediate problems with it? Ah, I see one. It will break pci_stop_bus_device() and pci_remove_bus_device(). So much for being clever. Moreover, it looks like those two routines above are racy too for the same reason? The (still untested) patch below is what I have come up with for now. The is_gone flag is now only operated under pci_remove_rescan_mutex, so it need not be atomic. Of course, whoever calls pci_stop_and_remove_bus_device() (the locked one) should hold a ref to the device being removed to avoid use-after-free (the callers need to be audited for that). if you can use device_schedule_..., No, I can't. I need to hold acpi_scan_lock taken in hotplug_event_work() throughout all bus trimming/scanning and I need to protect list walks over bus-devices too. should have hold reference may be atomic would be better than lock/unlock everywhere? The locking is necessary not only for the device removal itself, but also for the safety of the bus-devices list walks. Besides, remove_callback() in remove.c already holds pci_remove_rescan_mutex around pci_stop_and_remove_bus_device() and I don't see how it would be safe to run pci_stop_and_remove_bus_device() without holding that mutex from anywhere else. For one example, pci_stop_and_remove_bus_device() that is not run under pci_remove_rescan_mutex can race with the stuff called under that mutex in dev_bus_rescan_store() (and elsewhere in pci-sysfs.c). So either pci_remove_rescan_mutex is useless and should be dropped, or it is there for a purpose, in which case it needs to be used around pci_stop_and_remove_bus_device() everywhere. There's no other possibility and to my eyes that mutex is necessary. So below is a new version of the patch (which has been tested on my Thunderbolt rig without visibly breaking anything) with the description of all the problems it attempts to address. If any of the scenarios described in the changelog are not possible for some reason, please tell me why that is the case. I couldn't find such reasons myself. Thanks, Rafael --- From: Rafael J. Wysocki rafael.j.wyso...@intel.com Subject: PCI / hotplug / ACPI: Fix concurrency problems related to device removal The following are concurrency problems related to the PCI device removal code in pci-sysfs.c and in ACPIPHP present in the current mainline kernel: Scenario 1: pci_stop_and_remove_bus_device() run concurrently for the same top device from
Re: [PATCH v2 1/2] virtio_net: fix error handling for mergeable buffers
From: Michael S. Tsirkin m...@redhat.com Date: Thu, 28 Nov 2013 13:30:55 +0200 Eric Dumazet noticed that if we encounter an error when processing a mergeable buffer, we don't dequeue all of the buffers from this packet, the result is almost sure to be loss of networking. Jason Wang noticed that we also leak a page and that we don't decrement the rq buf count, so we won't repost buffers (a resource leak). Fix both issues. Cc: Rusty Russell ru...@rustcorp.com.au Cc: Michael Dalton mwdal...@google.com Reported-by: Eric Dumazet eduma...@google.com Reported-by: Jason Wang jasow...@redhat.com Signed-off-by: Michael S. Tsirkin m...@redhat.com 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 v2 2/2] virtio-net: make all RX paths handle erors consistently
From: Michael S. Tsirkin m...@redhat.com Date: Thu, 28 Nov 2013 13:30:59 +0200 receive mergeable now handles errors internally. Do same for big and small packet paths, otherwise the logic is too hard to follow. Signed-off-by: Michael S. Tsirkin m...@redhat.com Acked-by: Jason Wang jasow...@redhat.com Applied and I fixed the subject text to use an underscore '_' instead of a dash '-' for virtio_net: . -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@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] perf Makefile: Correct the message in feature-libnuma checking.
On 12/02/2013 09:11 AM, Dongsheng Yang wrote: ccing linux-kernel@vger.kernel.org On 11/29/2013 01:14 PM, Arnaldo Carvalho de Melo wrote: Em Fri, Nov 29, 2013 at 04:05:52PM -0500, Dongsheng Yang escreveu: The package required for numa is named numactl-devel in Fedora and RHEL and libnuma-devel in OpenSuSE. This patch correct the package name in warning message. and libnuma-dev in Ubuntu. Applying, but please always CC linux-kernel@vger.kernel.org, so that others can review it as well. Okey!! Thanx Arnaldo. - Arnaldo Signed-off-by: Dongsheng Yang yangds.f...@cn.fujitsu.com --- tools/perf/config/Makefile | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/tools/perf/config/Makefile b/tools/perf/config/Makefile index 80ea6d8..2e615d8 100644 --- a/tools/perf/config/Makefile +++ b/tools/perf/config/Makefile @@ -537,7 +537,7 @@ endif ifndef NO_LIBNUMA ifeq ($(feature-libnuma), 0) -msg := $(warning No numa.h found, disables 'perf bench numa mem' benchmark, please install numa-libs-devel or libnuma-dev); +msg := $(warning No numa.h found, disables 'perf bench numa mem' benchmark, please install numactl-devel or libnuma-devel); NO_LIBNUMA := 1 else CFLAGS += -DHAVE_LIBNUMA_SUPPORT -- 1.8.2.1 -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [Patch Part1 V2 01/17] iommu/vt-d: use dedicated bitmap to track remapping entry allocation status
Tested-and-reviewed-by: Yijing Wang wangyij...@huawei.com
On 2013/11/29 16:50, Jiang Liu wrote:
Currently Intel interrupt remapping drivers uses the present flag bit
in remapping entry to track whether an entry is allocated or not.
It works as follow:
1) allocate a remapping entry and set its present flag bit to 1
2) compose other fields for the entry
3) update the remapping entry with the composed value
The remapping hardware may access the entry between step 1 and step 3,
which then obervers an entry with the present flag set but random
values in all other fields.
This patch introduces a dedicated bitmap to track remapping entry
allocation status instead of sharing the present flag with hardware,
thus eliminate the race window. It also simplifies the implementation.
Signed-off-by: Jiang Liu jiang@linux.intel.com
---
drivers/iommu/intel_irq_remapping.c | 51
+--
include/linux/intel-iommu.h |1 +
2 files changed, 25 insertions(+), 27 deletions(-)
diff --git a/drivers/iommu/intel_irq_remapping.c
b/drivers/iommu/intel_irq_remapping.c
index bab10b1..282d392 100644
--- a/drivers/iommu/intel_irq_remapping.c
+++ b/drivers/iommu/intel_irq_remapping.c
@@ -72,7 +72,6 @@ static int alloc_irte(struct intel_iommu *iommu, int irq,
u16 count)
u16 index, start_index;
unsigned int mask = 0;
unsigned long flags;
- int i;
if (!count || !irq_iommu)
return -1;
@@ -96,32 +95,17 @@ static int alloc_irte(struct intel_iommu *iommu, int irq,
u16 count)
}
raw_spin_lock_irqsave(irq_2_ir_lock, flags);
- do {
- for (i = index; i index + count; i++)
- if (table-base[i].present)
- break;
- /* empty index found */
- if (i == index + count)
- break;
-
- index = (index + count) % INTR_REMAP_TABLE_ENTRIES;
-
- if (index == start_index) {
- raw_spin_unlock_irqrestore(irq_2_ir_lock, flags);
- printk(KERN_ERR can't allocate an IRTE\n);
- return -1;
- }
- } while (1);
-
- for (i = index; i index + count; i++)
- table-base[i].present = 1;
-
- cfg-remapped = 1;
- irq_iommu-iommu = iommu;
- irq_iommu-irte_index = index;
- irq_iommu-sub_handle = 0;
- irq_iommu-irte_mask = mask;
-
+ index = bitmap_find_free_region(table-bitmap,
+ INTR_REMAP_TABLE_ENTRIES, mask);
+ if (index 0) {
+ printk(KERN_ERR can't allocate an IRTE\n);
+ } else {
+ cfg-remapped = 1;
+ irq_iommu-iommu = iommu;
+ irq_iommu-irte_index = index;
+ irq_iommu-sub_handle = 0;
+ irq_iommu-irte_mask = mask;
+ }
raw_spin_unlock_irqrestore(irq_2_ir_lock, flags);
return index;
@@ -254,6 +238,8 @@ static int clear_entries(struct irq_2_iommu *irq_iommu)
set_64bit(entry-low, 0);
set_64bit(entry-high, 0);
}
+ bitmap_release_region(iommu-ir_table-bitmap, index,
+ irq_iommu-irte_mask);
return qi_flush_iec(iommu, index, irq_iommu-irte_mask);
}
@@ -453,6 +439,7 @@ static int intel_setup_irq_remapping(struct intel_iommu
*iommu, int mode)
{
struct ir_table *ir_table;
struct page *pages;
+ unsigned long *bitmap;
ir_table = iommu-ir_table = kzalloc(sizeof(struct ir_table),
GFP_ATOMIC);
@@ -470,7 +457,17 @@ static int intel_setup_irq_remapping(struct intel_iommu
*iommu, int mode)
return -ENOMEM;
}
+ bitmap = kcalloc(BITS_TO_LONGS(INTR_REMAP_TABLE_ENTRIES),
+ sizeof(long), GFP_ATOMIC);
+ if (bitmap == NULL) {
+ printk(KERN_ERR failed to allocate bitmap\n);
+ __free_pages(pages, INTR_REMAP_PAGE_ORDER);
+ kfree(ir_table);
+ return -ENOMEM;
+ }
+
ir_table-base = page_address(pages);
+ ir_table-bitmap = bitmap;
iommu_set_irq_remapping(iommu, mode);
return 0;
diff --git a/include/linux/intel-iommu.h b/include/linux/intel-iommu.h
index d380c5e..de1e5e9 100644
--- a/include/linux/intel-iommu.h
+++ b/include/linux/intel-iommu.h
@@ -288,6 +288,7 @@ struct q_inval {
struct ir_table {
struct irte *base;
+ unsigned long *bitmap;
};
#endif
--
Thanks!
Yijing
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@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 Part1 V2 02/17] iommu/vt-d: fix PCI device reference leakage on error recovery path
Reviewed-by: Yijing Wang wangyij...@huawei.com
On 2013/11/29 16:50, Jiang Liu wrote:
Function dmar_parse_dev_scope() should release the PCI device reference
count gained in function dmar_parse_one_dev_scope() on error recovery,
otherwise will cause PCI device object leakage.
This patch also introduces dmar_free_dev_scope(), which will be used
to support DMAR device hotplug.
Signed-off-by: Jiang Liu jiang@linux.intel.com
---
drivers/iommu/dmar.c | 15 +--
include/linux/dmar.h |1 +
2 files changed, 14 insertions(+), 2 deletions(-)
diff --git a/drivers/iommu/dmar.c b/drivers/iommu/dmar.c
index 8b452c9..f3043a2 100644
--- a/drivers/iommu/dmar.c
+++ b/drivers/iommu/dmar.c
@@ -72,6 +72,7 @@ static int __init dmar_parse_one_dev_scope(struct
acpi_dmar_device_scope *scope,
struct acpi_dmar_pci_path *path;
int count;
+ *dev = NULL;
bus = pci_find_bus(segment, scope-bus);
path = (struct acpi_dmar_pci_path *)(scope + 1);
count = (scope-length - sizeof(struct acpi_dmar_device_scope))
@@ -100,7 +101,6 @@ static int __init dmar_parse_one_dev_scope(struct
acpi_dmar_device_scope *scope,
if (!pdev) {
pr_warn(Device scope device [%04x:%02x:%02x.%02x] not found\n,
segment, scope-bus, path-device, path-function);
- *dev = NULL;
return 0;
}
if ((scope-entry_type == ACPI_DMAR_SCOPE_TYPE_ENDPOINT \
@@ -151,7 +151,7 @@ int __init dmar_parse_dev_scope(void *start, void *end,
int *cnt,
ret = dmar_parse_one_dev_scope(scope,
(*devices)[index], segment);
if (ret) {
- kfree(*devices);
+ dmar_free_dev_scope(devices, cnt);
return ret;
}
index ++;
@@ -162,6 +162,17 @@ int __init dmar_parse_dev_scope(void *start, void *end,
int *cnt,
return 0;
}
+void dmar_free_dev_scope(struct pci_dev ***devices, int *cnt)
+{
+ if (*devices *cnt) {
+ while (--*cnt = 0)
+ pci_dev_put((*devices)[*cnt]);
+ kfree(*devices);
+ *devices = NULL;
+ *cnt = 0;
+ }
+}
+
/**
* dmar_parse_one_drhd - parses exactly one DMA remapping hardware definition
* structure which uniquely represent one DMA remapping hardware unit
diff --git a/include/linux/dmar.h b/include/linux/dmar.h
index b029d1a..8adfce0 100644
--- a/include/linux/dmar.h
+++ b/include/linux/dmar.h
@@ -159,6 +159,7 @@ extern int dmar_parse_one_rmrr(struct acpi_dmar_header
*header);
extern int dmar_parse_one_atsr(struct acpi_dmar_header *header);
extern int dmar_parse_dev_scope(void *start, void *end, int *cnt,
struct pci_dev ***devices, u16 segment);
+extern void dmar_free_dev_scope(struct pci_dev ***devices, int *cnt);
extern int intel_iommu_init(void);
#else /* !CONFIG_INTEL_IOMMU: */
static inline int intel_iommu_init(void) { return -ENODEV; }
--
Thanks!
Yijing
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@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 Part1 V2 04/17] iommu/vt-d: fix resource leakage on error recovery path in iommu_init_domains()
On 2013/11/29 16:50, Jiang Liu wrote:
Release allocated resources on error recovery path in function
iommu_init_domains().
Signed-off-by: Jiang Liu jiang@linux.intel.com
---
drivers/iommu/intel-iommu.c |2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/iommu/intel-iommu.c b/drivers/iommu/intel-iommu.c
index b8e3b48..2398876 100644
--- a/drivers/iommu/intel-iommu.c
+++ b/drivers/iommu/intel-iommu.c
@@ -1273,6 +1273,8 @@ static int iommu_init_domains(struct intel_iommu *iommu)
GFP_KERNEL);
if (!iommu-domains) {
printk(KERN_ERR Allocating domain array failed\n);
+ kfree(iommu-domain_ids);
+ iommu-domain_ids = NULL;
return -ENOMEM;
}
Acked-by: Yijing Wang wangyij...@huawei.com
--
Thanks!
Yijing
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@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 Part1 V2 07/17] iommu/vt-d. trivial: check suitable flag in function detect_intel_iommu()
This patch is the same as the last.:) On 2013/11/29 16:50, Jiang Liu wrote: Flag irq_remapping_enabled is only set by intel_enable_irq_remapping(), which is called after detect_intel_iommu(). So we should check flag disable_irq_remap instead of irq_remapping_enabled in function detect_intel_iommu(). Signed-off-by: Jiang Liu jiang@linux.intel.com --- drivers/iommu/dmar.c |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/iommu/dmar.c b/drivers/iommu/dmar.c index f3043a2..77a066b 100644 --- a/drivers/iommu/dmar.c +++ b/drivers/iommu/dmar.c @@ -561,7 +561,7 @@ int __init detect_intel_iommu(void) dmar = (struct acpi_table_dmar *) dmar_tbl; - if (ret irq_remapping_enabled cpu_has_x2apic + if (ret !disable_irq_remap cpu_has_x2apic dmar-flags 0x1) pr_info(Queued invalidation will be enabled to support x2apic and Intr-remapping.\n); -- Thanks! Yijing -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2 2/3] bq2415x_charger: Use power_supply notifier for automode
Hi On Mon, Dec 2, 2013 at 1:24 AM, Anton Vorontsov an...@enomsg.org wrote: On Mon, Dec 02, 2013 at 01:02:40AM +0100, Michael Trimarchi wrote: On Sun, Dec 1, 2013 at 11:37 PM, Anton Vorontsov an...@enomsg.org wrote: On Mon, Nov 25, 2013 at 08:16:34PM +0100, Michael Trimarchi wrote: ... So you can read this value without any type of synchronization with the power_supply_core and sysfs implementation? ... https://lists.ubuntu.com/archives/kernel-team/2013-January/025206.html I found and equivalent scenario that I was trying to said That's a good question, actually. Even though in Pali's case the notifier is atomic (so that we are pretty confident that the object won't be unregistered), there is still a possiblity of a dead lock, for example. So So if the get_property is a sleeping function it will be a deadlock. Right? All kind of bad things might happen, yes. But before that I would expect a bunch of warnings from might_sleep() stuff. I would recommend to test the patches using preempt/smp kernels + various DEBUG_ kernel options set. Is it more simple to make it not atomic and use a mutex in get_property? Michael Thanks, Anton -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [Patch Part1 V2 07/17] iommu/vt-d, trivial: check suitable flag in function detect_intel_iommu()
On 2013/11/29 16:50, Jiang Liu wrote: Flag irq_remapping_enabled is only set by intel_enable_irq_remapping(), which is called after detect_intel_iommu(). So we should check flag disable_irq_remap instead of irq_remapping_enabled in function detect_intel_iommu(). Signed-off-by: Jiang Liu jiang@linux.intel.com --- drivers/iommu/dmar.c |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/iommu/dmar.c b/drivers/iommu/dmar.c index f3043a2..77a066b 100644 --- a/drivers/iommu/dmar.c +++ b/drivers/iommu/dmar.c @@ -561,7 +561,7 @@ int __init detect_intel_iommu(void) dmar = (struct acpi_table_dmar *) dmar_tbl; - if (ret irq_remapping_enabled cpu_has_x2apic + if (ret !disable_irq_remap cpu_has_x2apic dmar-flags 0x1) pr_info(Queued invalidation will be enabled to support x2apic and Intr-remapping.\n); Reviewed-by: Yijing Wang wangyij...@huawei.com -- Thanks! Yijing -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@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 Part1 V2 12/17] iommu/vt-d: fix invalid memory access when freeing DMAR irq
Reviewed-by: Yijing Wang wangyij...@huawei.com
On 2013/11/29 16:50, Jiang Liu wrote:
In function free_dmar_iommu(), it sets IRQ handler data to NULL
before calling free_irq(), which will cause invalid memory access
because free_irq() will access IRQ handler data when calling
function dmar_msi_mask(). So only set IRQ handler data to NULL
after calling free_irq().
Sample stack dump:
[ 13.094010] BUG: unable to handle kernel NULL pointer dereference at
0048
[ 13.103215] IP: [810a97cd] __lock_acquire+0x4d/0x12a0
[ 13.110104] PGD 0
[ 13.112614] Oops: [#1] SMP
[ 13.116585] Modules linked in:
[ 13.120260] CPU: 60 PID: 1 Comm: swapper/0 Tainted: GW
3.13.0-rc1-gerry+ #9
[ 13.129367] Hardware name: Intel Corporation LH Pass
../SVRBD-ROW_T, BIOS SE5C600.86B.99.99.x059.091020121352 09/10/2012
[ 13.142555] task: 88042dd38010 ti: 88042dd32000 task.ti:
88042dd32000
[ 13.151179] RIP: 0010:[810a97cd] [810a97cd]
__lock_acquire+0x4d/0x12a0
[ 13.160867] RSP: :88042dd33b78 EFLAGS: 00010046
[ 13.166969] RAX: 0046 RBX: 0002 RCX:
[ 13.175122] RDX: RSI: RDI:
0048
[ 13.183274] RBP: 88042dd33bd8 R08: 0002 R09:
0001
[ 13.191417] R10: R11: 0001 R12:
88042dd38010
[ 13.199571] R13: R14: 0048 R15:
[ 13.207725] FS: () GS:88103f20()
knlGS:
[ 13.217014] CS: 0010 DS: ES: CR0: 80050033
[ 13.223596] CR2: 0048 CR3: 01a0b000 CR4:
000407e0
[ 13.231747] Stack:
[ 13.234160] 0004 0046 88042dd33b98
810a567d
[ 13.243059] 88042dd33c08 810bb14c 828995a0
0046
[ 13.251969] 0002
[ 13.260862] Call Trace:
[ 13.263775] [810a567d] ? trace_hardirqs_off+0xd/0x10
[ 13.270571] [810bb14c] ? vprintk_emit+0x23c/0x570
[ 13.277058] [810ab1e3] lock_acquire+0x93/0x120
[ 13.283269] [814623f7] ? dmar_msi_mask+0x47/0x70
[ 13.289677] [8156b449] _raw_spin_lock_irqsave+0x49/0x90
[ 13.296748] [814623f7] ? dmar_msi_mask+0x47/0x70
[ 13.303153] [814623f7] dmar_msi_mask+0x47/0x70
[ 13.309354] [810c0d93] irq_shutdown+0x53/0x60
[ 13.315467] [810bdd9d] __free_irq+0x26d/0x280
[ 13.321580] [810be920] free_irq+0xf0/0x180
[ 13.327395] [81466591] free_dmar_iommu+0x271/0x2b0
[ 13.333996] [810a947d] ? trace_hardirqs_on+0xd/0x10
[ 13.340696] [81461a17] free_iommu+0x17/0x50
[ 13.346597] [81dc75a5] init_dmars+0x691/0x77a
[ 13.352711] [81dc7afd] intel_iommu_init+0x351/0x438
[ 13.359400] [81d8a711] ? iommu_setup+0x27d/0x27d
[ 13.365806] [81d8a739] pci_iommu_init+0x28/0x52
[ 13.372114] [81000342] do_one_initcall+0x122/0x180
[ 13.378707] [81077738] ? parse_args+0x1e8/0x320
[ 13.385016] [81d850e8] kernel_init_freeable+0x1e1/0x26c
[ 13.392100] [81d84833] ? do_early_param+0x88/0x88
[ 13.398596] [8154f8b0] ? rest_init+0xd0/0xd0
[ 13.404614] [8154f8be] kernel_init+0xe/0x130
[ 13.410626] [81574d6c] ret_from_fork+0x7c/0xb0
[ 13.416829] [8154f8b0] ? rest_init+0xd0/0xd0
[ 13.422842] Code: ec 99 00 85 c0 8b 05 53 05 a5 00 41 0f 45 d8 85 c0 0f 84
ff 00 00 00 8b 05 99 f9 7e 01 49 89 fe 41 89 f7 85 c0 0f 84 03 01 00 00 49
8b 06 be 01 00 00 00 48 3d c0 0e 01 82 0f 44 de 41 83 ff 01
[ 13.450191] RIP [810a97cd] __lock_acquire+0x4d/0x12a0
[ 13.458598] RSP 88042dd33b78
[ 13.462671] CR2: 0048
[ 13.466551] ---[ end trace c5bd26a37c81d760 ]---
Signed-off-by: Jiang Liu jiang@linux.intel.com
---
drivers/iommu/intel-iommu.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/iommu/intel-iommu.c b/drivers/iommu/intel-iommu.c
index 0ec49da..426095e 100644
--- a/drivers/iommu/intel-iommu.c
+++ b/drivers/iommu/intel-iommu.c
@@ -1289,9 +1289,9 @@ void free_dmar_iommu(struct intel_iommu *iommu)
iommu_disable_translation(iommu);
if (iommu-irq) {
- irq_set_handler_data(iommu-irq, NULL);
/* This will mask the irq */
free_irq(iommu-irq, iommu);
+ irq_set_handler_data(iommu-irq, NULL);
destroy_irq(iommu-irq);
}
--
Thanks!
Yijing
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ
Re: [PATCH 2/3 v3] usb: chipidea: Fix Internal error: : 808 [#1] ARM related to STS flag
On Saturday, November 30, 2013 06:20 PM, Peter Chen wrote:
usb: chipidea: Fix Internal error: : 808 [#1] ARM related to STS flag
* init the sts flag to 0 (missed)
* Set PORTCS_STS only if VUSB_HS_PHY_TYPE 1
otherwise the register is ReadOnly
* Set/Reset correct BIT(28)/BIT(29) for STS
Signed-off-by: Chris Ruehlchris.ru...@gtsys.com.hk
---
drivers/usb/chipidea/core.c | 20 +---
1 file changed, 17 insertions(+), 3 deletions(-)
diff --git a/drivers/usb/chipidea/core.c b/drivers/usb/chipidea/core.c
index 5075407..2c634c1 100644
--- a/drivers/usb/chipidea/core.c
+++ b/drivers/usb/chipidea/core.c
@@ -243,7 +243,7 @@ static int hw_device_init(struct ci_hdrc *ci, void
__iomem *base)
static void hw_phymode_configure(struct ci_hdrc *ci)
{
- u32 portsc, lpm, sts;
+ u32 portsc, lpm, sts = 0;
switch (ci-platdata-phy_mode) {
case USBPHY_INTERFACE_MODE_UTMI:
@@ -273,10 +273,24 @@ static void hw_phymode_configure(struct ci_hdrc *ci)
if (ci-hw_bank.lpm) {
hw_write(ci, OP_DEVLC, DEVLC_PTS(7) | DEVLC_PTW, lpm);
- hw_write(ci, OP_DEVLC, DEVLC_STS, sts);
+ if ( sts )
+ hw_write(ci, OP_DEVLC, DEVLC_STS, BIT(28));
+ else
+ hw_write(ci, OP_DEVLC, DEVLC_STS, ~BIT(28));
} else {
hw_write(ci, OP_PORTSC, PORTSC_PTS(7) | PORTSC_PTW, portsc);
- hw_write(ci, OP_PORTSC, PORTSC_STS, sts);
+ if (((portsc 30) 0x3) 1) {
+ if (sts) {
+ hw_write(ci, OP_PORTSC, PORTSC_STS, BIT(29));
+ }
+ else {
+ portsc =
(ioread32(ci-hw_bank.regmap[OP_PORTSC])
+ PORTSC_STS);
+ if (portsc)
+ hw_write(ci, OP_PORTSC, PORTSC_STS,
+ ~BIT(29));
+ }
+ }
}
}
--
At my chipidea datasheet, the VUSB_HS_PHY_SERIAL is at HWGENERAL (bit[10..11]),
We are still not sure the portsc_sts is needed to set or clear, and how to do
it. My suggestion is just use v2 patch (except fixing one code style problem)
Peter
Peter,
Thanks you for your comments.
If you have a look into the function hw_write() you will see that there is no
effect if hw_write(...,sts) is called with sts=0/1, because the mask will cut
off all bits beside BIT(29).
I used BIT(29) rather then PORTCS_STS to make it more clear what going on.
A write to PORTCS will always be 0 for the STS Register no matter if sts is 1
or 0 within Patch v2. Patch v3 will take care of the registers bit position and
set 1 or 0 to PORTCS_STS.
I used the imx27 reference manual Capital 30.8.1.5.12 PORTSCx.
Please comment.
Chris
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 1/1] dell_laptop: add disable_backlight module parameter
I have a Dell Inspiron N7010 Laptop with Intel graphics. When the dell-laptop
module is loaded,
two backlight device devices are created; dell_backlight, and intel_backlight
from the Intel
graphics driver. The dell_backlight device is non-functional, but the graphics
subsystem uses
it instead of the functioning intel_backlight device. The result is that, when
running KDE,
screen dimming does not work. I've added a module parameter, disable_backlight,
which when
true will disable the dell_backlight device, and leave only the
intel_backlight: with this,
screen dimming works.
Signed-off-by: Alex Davis alex14...@yahoo.com
--- dell-laptop.c.orig 2013-12-01 19:05:39.693149050 -0500
+++ dell-laptop.c 2013-12-01 17:29:27.613372482 -0500
@@ -35,6 +35,9 @@
/* This structure will be modified by the firmware when we enter
* system management mode, hence the volatiles */
+static bool disable_backlight;
+module_param(disable_backlight, bool, 0644);
+
struct calling_interface_buffer {
u16 class;
u16 select;
@@ -561,6 +564,9 @@ static int __init dell_init(void)
dell_laptop_dir = debugfs_create_dir(dell_laptop, NULL);
+ if (disable_backlight)
+ return 0;
+
#ifdef CONFIG_ACPI
/* In the event of an ACPI backlight being available, don't
* register the platform controller.
I code, therefore I am
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@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] perf Makefile: Correct the message in feature-libnuma checking.
On 12/01/2013 08:33 PM, Peter Hurley wrote: On 12/02/2013 09:11 AM, Dongsheng Yang wrote: ccing linux-kernel@vger.kernel.org On 11/29/2013 01:14 PM, Arnaldo Carvalho de Melo wrote: Em Fri, Nov 29, 2013 at 04:05:52PM -0500, Dongsheng Yang escreveu: The package required for numa is named numactl-devel in Fedora and RHEL and libnuma-devel in OpenSuSE. This patch correct the package name in warning message. and libnuma-dev in Ubuntu. Right, I will send v2 with 'numactl-devel/libnuma-dev/libnuma-devel'. Thanx Peter. Applying, but please always CC linux-kernel@vger.kernel.org, so that others can review it as well. Okey!! Thanx Arnaldo. - Arnaldo Signed-off-by: Dongsheng Yang yangds.f...@cn.fujitsu.com --- tools/perf/config/Makefile | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/tools/perf/config/Makefile b/tools/perf/config/Makefile index 80ea6d8..2e615d8 100644 --- a/tools/perf/config/Makefile +++ b/tools/perf/config/Makefile @@ -537,7 +537,7 @@ endif ifndef NO_LIBNUMA ifeq ($(feature-libnuma), 0) -msg := $(warning No numa.h found, disables 'perf bench numa mem' benchmark, please install numa-libs-devel or libnuma-dev); +msg := $(warning No numa.h found, disables 'perf bench numa mem' benchmark, please install numactl-devel or libnuma-devel); NO_LIBNUMA := 1 else CFLAGS += -DHAVE_LIBNUMA_SUPPORT -- 1.8.2.1 -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2/3 v3] usb: chipidea: Fix Internal error: : 808 [#1] ARM related to STS flag
Hi On Sunday, December 01, 2013 01:28 AM, Sergei Shtylyov wrote: Hello. On 30-11-2013 7:51, Chris Ruehl wrote: usb: chipidea: Fix Internal error: : 808 [#1] ARM related to STS flag * init the sts flag to 0 (missed) * Set PORTCS_STS only if VUSB_HS_PHY_TYPE 1 otherwise the register is ReadOnly * Set/Reset correct BIT(28)/BIT(29) for STS Signed-off-by: Chris Ruehl chris.ru...@gtsys.com.hk The coding style is still wrong at places... .. - hw_write(ci, OP_DEVLC, DEVLC_STS, sts); + if ( sts ) Remove spaces around 'sts', please. ... + portsc = (ioread32(ci-hw_bank.regmap[OP_PORTSC]) + PORTSC_STS); No need for outer (). And it's preferred that an operator is left at the end of a first line, not starts the continuation line. WBR, Sergei Sergei, Thanks, I will take care of and have a question about style portsc = ioread32(ci-hw_bank.regmap[OP_PORTSC] PORTSC_STS; the line in the if/else alignment extent the 80char barrier and should be splitted in this case '' is at 81 .. how serious I should follow this one? portsc = ioread32(ci-hw_bank.regmap[OP_PORTSC] PORTSC_STS; I keep this mail private don't want make too much noise on the list. regards Chris -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@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: kernel BUG at kernel/kallsyms.c:222!
2013/11/13 Ming Lei tom.leim...@gmail.com: Hi Axel, On Wed, Nov 13, 2013 at 5:58 PM, Axel Lin axel@ingics.com wrote: Hi Ming, You missed ; then in the end of if statement in your patch. So I got below error with your patch: scripts/link-vmlinux.sh: line 87: syntax error near unexpected token `fi' make: *** [vmlinuxclean] Error 2 Thanks for your test, and I have fixed it and post a formal one for merge, and you can find these two patches on arm list, but forget to Cc you, sorry for that. Hi Ming, Both your patch and Jonathan's patch are still not in linux-next. Any chance to resend the patchs to RMK's patch system? Thanks, Axel -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@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] f2fs: remove the own bi_private allocation
On 11/30/2013 09:48 AM, Jaegeuk Kim wrote:
Previously f2fs allocates its own bi_private data structure all the time even
though we don't use it. But, can we remove this bi_private allocation?
This patch removes such the additional bi_private allocation.
1. Retrieve f2fs_sb_info from its page-mapping-host-i_sb.
- This removes the usecases of bi_private in end_io.
2. Use bi_private only when we really need it.
- The bi_private is used only when the checkpoint procedure is conducted.
- When conducting the checkpoint, f2fs submits a META_FLUSH bio to wait its
bio
completion.
- Since we have no dependancies to remove bi_private now, let's just use
bi_private pointer as the completion pointer.
Cool, looks good to me.:)
Signed-off-by: Jaegeuk Kim jaegeuk@samsung.com
Reviewed-by: Gu Zheng guz.f...@cn.fujitsu.com
---
fs/f2fs/segment.c | 43 ---
fs/f2fs/segment.h | 7 ---
2 files changed, 16 insertions(+), 34 deletions(-)
diff --git a/fs/f2fs/segment.c b/fs/f2fs/segment.c
index 0387863..0db4027 100644
--- a/fs/f2fs/segment.c
+++ b/fs/f2fs/segment.c
@@ -791,7 +791,7 @@ static void f2fs_end_io_write(struct bio *bio, int err)
{
const int uptodate = test_bit(BIO_UPTODATE, bio-bi_flags);
struct bio_vec *bvec = bio-bi_io_vec + bio-bi_vcnt - 1;
- struct bio_private *p = bio-bi_private;
+ struct f2fs_sb_info *sbi = F2FS_SB(bvec-bv_page-mapping-host-i_sb);
do {
struct page *page = bvec-bv_page;
@@ -802,21 +802,21 @@ static void f2fs_end_io_write(struct bio *bio, int err)
SetPageError(page);
if (page-mapping)
set_bit(AS_EIO, page-mapping-flags);
- set_ckpt_flags(p-sbi-ckpt, CP_ERROR_FLAG);
- p-sbi-sb-s_flags |= MS_RDONLY;
+
+ set_ckpt_flags(sbi-ckpt, CP_ERROR_FLAG);
+ sbi-sb-s_flags |= MS_RDONLY;
}
end_page_writeback(page);
- dec_page_count(p-sbi, F2FS_WRITEBACK);
+ dec_page_count(sbi, F2FS_WRITEBACK);
} while (bvec = bio-bi_io_vec);
- if (p-is_sync)
- complete(p-wait);
+ if (bio-bi_private)
+ complete(bio-bi_private);
- if (!get_pages(p-sbi, F2FS_WRITEBACK)
- !list_empty(p-sbi-cp_wait.task_list))
- wake_up(p-sbi-cp_wait);
+ if (!get_pages(sbi, F2FS_WRITEBACK)
+ !list_empty(sbi-cp_wait.task_list))
+ wake_up(sbi-cp_wait);
- kfree(p);
bio_put(bio);
}
@@ -838,7 +838,6 @@ static void do_submit_bio(struct f2fs_sb_info *sbi,
int rw = sync ? WRITE_SYNC : WRITE;
enum page_type btype = PAGE_TYPE_OF_BIO(type);
struct f2fs_bio_info *io = sbi-write_io[btype];
- struct bio_private *p;
if (!io-bio)
return;
@@ -851,18 +850,16 @@ static void do_submit_bio(struct f2fs_sb_info *sbi,
trace_f2fs_submit_write_bio(sbi-sb, rw, btype, io-bio);
- p = io-bio-bi_private;
- p-sbi = sbi;
- io-bio-bi_end_io = f2fs_end_io_write;
-
+ /*
+ * META_FLUSH is only from the checkpoint procedure, and we should wait
+ * this metadata bio for FS consistency.
+ */
if (type == META_FLUSH) {
DECLARE_COMPLETION_ONSTACK(wait);
- p-is_sync = true;
- p-wait = wait;
+ io-bio-bi_private = wait;
submit_bio(rw, io-bio);
wait_for_completion(wait);
} else {
- p-is_sync = false;
submit_bio(rw, io-bio);
}
io-bio = NULL;
@@ -897,18 +894,10 @@ static void submit_write_page(struct f2fs_sb_info *sbi,
struct page *page,
do_submit_bio(sbi, type, false);
alloc_new:
if (io-bio == NULL) {
- struct bio_private *priv;
-retry:
- priv = kmalloc(sizeof(struct bio_private), GFP_NOFS);
- if (!priv) {
- cond_resched();
- goto retry;
- }
-
bio_blocks = MAX_BIO_BLOCKS(max_hw_blocks(sbi));
io-bio = f2fs_bio_alloc(bdev, bio_blocks);
io-bio-bi_sector = SECTOR_FROM_BLOCK(sbi, blk_addr);
- io-bio-bi_private = priv;
+ io-bio-bi_end_io = f2fs_end_io_write;
/*
* The end_io will be assigned at the sumbission phase.
* Until then, let bio_add_page() merge consecutive IOs as much
diff --git a/fs/f2fs/segment.h b/fs/f2fs/segment.h
index 7fea2ee..26812fc 100644
--- a/fs/f2fs/segment.h
+++ b/fs/f2fs/segment.h
@@ -92,13 +92,6 @@
#define MAX_BIO_BLOCKS(max_hw_blocks)
\
(min((int)max_hw_blocks, BIO_MAX_PAGES))
-/* during checkpoint, bio_private is used to synchronize the last
Re: kernel BUG at kernel/kallsyms.c:222!
Hi Axel, I am fine to resend it to RMK's patch system, but I am not sure if Russell would like to host it. Maybe it is better to push it via Rusty's tree since the change is only on scripts/, and it doesn't depend on the 1st one. Rusty, could you pick up the patch with title of scripts/link-vmlinux.sh: only filter kernel symbols for arm? Thanks, -- Ming Lei On Mon, Dec 2, 2013 at 9:57 AM, Axel Lin axel@ingics.com wrote: 2013/11/13 Ming Lei tom.leim...@gmail.com: Hi Axel, On Wed, Nov 13, 2013 at 5:58 PM, Axel Lin axel@ingics.com wrote: Hi Ming, You missed ; then in the end of if statement in your patch. So I got below error with your patch: scripts/link-vmlinux.sh: line 87: syntax error near unexpected token `fi' make: *** [vmlinuxclean] Error 2 Thanks for your test, and I have fixed it and post a formal one for merge, and you can find these two patches on arm list, but forget to Cc you, sorry for that. Hi Ming, Both your patch and Jonathan's patch are still not in linux-next. Any chance to resend the patchs to RMK's patch system? Thanks, Axel -- Ming Lei -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v1 1/2] lib/scatterlist: export sg_miter_skip()
On Sat, Nov 30, 2013 at 6:23 AM, Tejun Heo t...@kernel.org wrote: On Tue, Nov 26, 2013 at 12:43:37PM +0800, Ming Lei wrote: sg_copy_buffer() can't meet demand for some drrivers(such usb mass storage), so we have to use the sg_miter_* APIs to access sg buffer, then need export sg_miter_skip() for these drivers. The API is needed for converting to sg_miter_* APIs in USB storage driver for accessing sg buffer. Acked-by: Andrew Morton a...@linux-foundation.org Cc: FUJITA Tomonori fujita.tomon...@lab.ntt.co.jp Cc: Tejun Heo t...@kernel.org Cc: Jens Axboe ax...@kernel.dk Signed-off-by: Ming Lei ming@canonical.com Reviewed-by: Tejun Heo t...@kernel.org Thanks. I suppose this should go through -mm? Last round, Andrew said it can be though whatever tree, so given dependency reason, it is better to merge via greg's tree. Greg, could you merge these two patches via your usb-next tree? Thanks, -- Ming Lei -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2 3/3] ARM: shmobile: kzm9d: Use common clock framework
On Tue, Oct 29, 2013 at 01:42:41PM +0900, Simon Horman wrote: On Wed, Oct 09, 2013 at 07:39:18PM +0900, Simon Horman wrote: On Wed, Oct 09, 2013 at 04:29:56PM +0900, Magnus Damm wrote: Hi Simon, On Wed, Oct 9, 2013 at 3:54 PM, Simon Horman ho...@verge.net.au wrote: On Wed, Oct 09, 2013 at 01:59:46PM +0900, Magnus Damm wrote: Hi Simon, On Wed, Oct 9, 2013 at 12:40 PM, Simon Horman ho...@verge.net.au wrote: On Tue, Oct 08, 2013 at 02:34:03PM +0900, takas...@ops.dti.ne.jp wrote: Use common clock framework version of clock drivers/clk/shmobile/clk-emev2.c instead of sh-clkfwk version arch/arm/mach-shmobile/clock-emev2.c when it is configured as a part of multi-platform. Signed-off-by: Takashi Yoshii takas...@ops.dti.ne.jp Thanks. I plan to add this patch to a new topic branch, topic/emev2-common-clock, in the renesas tree and queue it up from there for inclusion in mainline if/when the first patch of this series is accepted by Mike Turquette. Thanks for picking up patches, Simon. I think you can simply merge this patch after the following series: [PATCH 00/05] ARM: shmobile: KZM9D Multiplatform update This is already queued up. Yes, I know, thanks for that. I tried to explain the dependency in the 00/00 cover letter but I will try to be more clear next time! There are no build time dependencies on patch 1 and 2 so this patch can be merged independently. Regarding run-time operation, the multiplatform series above makes KZM9D DT reference only build for multiplatform, and in such case CCF is required. So if you want to keep KZM9D DT reference working until Mike Turquette accepts the CCF bits, then I recommend you to wait with [PATCH 00/05] ARM: shmobile: KZM9D Multiplatform update until all EMEV2 CCF bits have been merged. Another way is to merge [PATCH 00/05] ARM: shmobile: KZM9D Multiplatform update before the EMEV2 CCF bits, but if so you may as well merge this patch as well IMO. This multiplatform-update-series-merge-before-CCF plan will result in untestable KZM9D DT reference until EMEV2 CCF is merged. Either way is fine with me. I am mainly concerned that the bindings may change before they are finally merged. And I thought it would be nice to avoid having to fix up the usage of the bindings if they change. Sure, but the code in this patch looks like it simply starts DT CCF probing regardless of what the bindings look like. So I don't think you will have to worry about actual bindings detail. But I'm happy to just queue-up patches 2 and 3 of this series now if you prefer. Well, I meant patch 3 only. Patch 1 and 2 are tied together by dependencies. =) Thanks, I understand now. I'll queue-up 3/3. Which I did. Then some time passed... Mike has accepted my pull-request for patch 1 of this series and accordingly I have queued-up this patch for v3.14. It should appear in the devel branch the next time that I push it. I was mistaken. It was not queued up for v3.14. And still has not been queued up. I have un-queued this patch accordingly. -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH V2] perf Makefile: Correct the message in feature-libnuma checking.
The package required for numa is named numactl-devel in Fedora or RHEL, and libnuma-devel in OpenSuSE, and libnuma-dev in Ubuntu. This patch corrects the package name in warning message in feature-libnuma checking. Signed-off-by: Dongsheng Yang yangds.f...@cn.fujitsu.com --- Changes since v1 - Add libnuma-dev for Ubuntu. tools/perf/config/Makefile | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/tools/perf/config/Makefile b/tools/perf/config/Makefile index 80ea6d8..acd3684 100644 --- a/tools/perf/config/Makefile +++ b/tools/perf/config/Makefile @@ -537,7 +537,7 @@ endif ifndef NO_LIBNUMA ifeq ($(feature-libnuma), 0) -msg := $(warning No numa.h found, disables 'perf bench numa mem' benchmark, please install numa-libs-devel or libnuma-dev); +msg := $(warning No numa.h found, disables 'perf bench numa mem' benchmark, please install numactl-devel/libnuma-devel/libnuma-dev); NO_LIBNUMA := 1 else CFLAGS += -DHAVE_LIBNUMA_SUPPORT -- 1.8.2.1 -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[GIT] Networking
Here is a pile of bug fixes that accumulated while I was in Europe.
1) In fixing kernel leaks to userspace during copying of socket
addresses, we broke a case that used to work, namely the user
providing a buffer larger than the in-kernel generic socket address
structure. This broke Ruby amongst other things. Fix from Dan
Carpenter.
2) Fix regression added by byte queue limit support in 8139cp driver,
from Yang Yingliang.
3) The addition of MSG_SENDPAGE_NOTLAST buggered up a few sendpage
implementations, they should just treat it the same as MSG_MORE.
Fix from Richard Weinberger and Shawn Landden.
4) Handle icmpv4 errors received on ipv6 SIT tunnels correctly,
from Oussama Ghorbel. In particular we should send an ICMPv6
unreachable in such situations.
5) Fix some regressions in the recent genetlink fixes, in particular
get the pmcraid driver to use the new safer interfaces correctly.
From Johannes Berg.
6) macvtap was converted to use a per-cpu set of statistics, but some
code was still bumping tx_dropped elsewhere. From Jason Wang.
7) Fix build failure of xen-netback due to missing include on some
architectures, from Andy Whitecroft.
8) macvtap double counts received packets in statistics, fix from
Vlad Yasevich.
9) Fix various cases of using *_STATS_BH() when *_STATS() is more
appropriate. From Eric Dumazet and Hannes Frederic Sowa.
10) Pktgen ipsec mode doesn't update the ipv4 header length and
checksum properly after encapsulation. Fix from Fan Du.
Please pull, thanks a lot!
The following changes since commit 9d8506cc2d7ea1f911c72c100193a3677f6668c3:
gso: handle new frag_list of frags GRO packets (2013-11-21 14:11:50 -0500)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/davem/net.git master
for you to fetch changes up to 833846e8fa0c51fb3e47bca8adfdd7b10643b737:
net/mlx4_en: Remove selftest TX queues empty condition (2013-12-01 20:36:07
-0500)
Ajit Khaparde (3):
be2net: Disabling and enabling interrupts in suspend and resume
be2net: set coalesce-wm in CQ_CREATE_V2 cmd
be2net: Avoid programming permenant MAC by BE3-R VFs
Akeem G Abodunrin (1):
igb: Fixed Wake On LAN support
Andy Whitcroft (1):
xen-netback: include definition of csum_ipv6_magic
Arvid Brodin (3):
MAINTAINERS: Added net/hsr/ maintainer
net/hsr: Very small fix of comment style.
net/hsr: Support iproute print_opt ('ip -details ...')
Baker Zhang (1):
net: remove outdated comment for ipv4 and ipv6 protocol handler
Chang Xiangzhong (1):
net: sctp: find the correct highest_new_tsn in sack
Dan Carpenter (1):
net: clamp -msg_namelen instead of returning an error
David Chang (1):
r8169: check ALDPS bit and disable it if enabled for the 8168g
David S. Miller (4):
Merge branch 'fixes-for-3.13-20131127' of
git://gitorious.org/linux-can/linux-can
Revert be2net: call napi_disable() for all event queues
Revert net: smc91: fix crash regression on the versatile
Merge branch 'master' of git://git.kernel.org/.../jkirsher/net
Eric Dumazet (2):
sch_tbf: handle too small burst
inet: fix possible seqlock deadlocks
Eugenia Emantayev (1):
net/mlx4_en: Remove selftest TX queues empty condition
Gao feng (2):
tcp_memcg: remove useless var old_lim
sit: use kfree_skb to replace dev_kfree_skb
Geert Uytterhoeven (1):
genetlink: Fix uninitialized variable in genl_validate_assign_mc_groups()
Guenter Roeck (2):
tg3: Convert to use hwmon_device_register_with_groups
sfc: Convert to use hwmon_device_register_with_groups
Hannes Frederic Sowa (3):
inet: fix addr_len/msg-msg_namelen assignment in recv_error and rxpmtu
functions
ipv6: fix leaking uninitialized port number of offender sockaddr
ipv6: fix possible seqlock deadlock in ip6_finish_output2
Herbert Xu (2):
gro: Only verify TCP checksums for candidates
gro: Clean up tcpX_gro_receive checksum verification
Holger Bechtold (1):
can: c_can: fix calculation of transmitted bytes on tx complete
Ivan Vecera (2):
be2net: call napi_disable() for all event queues
be2net: call napi_disable() for all event queues
Jason Wang (1):
macvtap: fix tx_dropped counting error
Jiri Pirko (1):
team: fix master carrier set when user linkup is enabled
Johannes Berg (1):
genetlink/pmcraid: use proper genetlink multicast API
John Fastabend (2):
ixgbe: ixgbe_fwd_ring_down needs to be static
ixgbe: turn NETIF_F_HW_L2FW_DOFFLOAD off by default
Linus Walleij (2):
net: smc91: fix crash regression on the versatile
net: smc91: fix crash regression on the versatile
Marc Kleine-Budde (2):
can: c_can: don't call pm_runtime_get_sync() from interrupt context
can: flexcan: use correct clock as base for bit rate
Re: [PATCH V2] perf Makefile: Correct the message in feature-libnuma checking.
On 12/02/2013 10:26 AM, Dongsheng Yang wrote: The package required for numa is named numactl-devel in Fedora or RHEL, and libnuma-devel in OpenSuSE, and libnuma-dev in Ubuntu. This patch corrects the package name in warning message in feature-libnuma checking. Thanks (and thanks for correcting the other lib names). Regards, Peter Hurley -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@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 00/12] kexec kernel efi runtime support
On 11/29/13 at 06:02pm, Borislav Petkov wrote: On Fri, Nov 29, 2013 at 04:28:22PM +0800, Dave Young wrote: I think for anyone who are using early_memremap should know this is a normal kernel memory instead of real __iomem You can never ever assume that people are using kernel interfaces correctly. But the semantic of early_memreamp should be that it will just return a normal memory pointer instead of iomem so the fix to convert the internal implementation to return a __force __kernel make sense to me. For iounmap I think since we have early_memremap, we have reason to add early_memunmap() so sparse will be happy. Thanks Dave -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@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 08/12] efi: only print saved efi runtime maps instead of all memmap ranges for kexec
On 11/29/13 at 05:47pm, Borislav Petkov wrote: On Fri, Nov 29, 2013 at 04:50:50PM +0800, Dave Young wrote: It's for debugging purpose, I think it's helpful. Why? The first kernel did dump it already. As for the efi printk though 1st kernel already printed them out, but kexec kernel context is diffrent from 1st kernel, it's a fresh reboot we do need reprint them. I think kexec reboot is just like a normal reboot from user's point of view. Thanks Dave -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@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: [PATCHv6 1/4] pwm: Add Freescale FTM PWM driver support
+#define FTM_CNTIN_VAL 0x00
Do we really need this?
Maybe not, I think that the initial value maybe modified in the future.
And this can be more easy to ajust it.
Why would it need to be modified?
Well, for the PWM function modifying it make no sense, so I'll remove this.
+ writel(period_cycles + cntin - 1, fpc-base + FTM_MOD);
+ writel(duty_cycles + cntin, fpc-base + FTM_CV(pwm-hwpwm));
And these:
writel(period - 1, fpc-base + FTM_MOD);
writel(duty, fpc-base + FTM_CV(pwm-hwpwm));
Although now that I think about it, this seems broken. The period is
set in a global register, so I assume it is valid for all channels.
What if you want to use different periods for individual channels?
The way I read this the last one to be configured will win and
change the period to whatever it wants. Other channels won't even
notice.
That's right. And all the 8 channels share the same period settings.
Is there a way to set the period per channel?
Not yet. Only could we do is to set the duty value individually for
each channel. So here is a limitation for the cusumers that all the 8
channels'
period values should be the same.
That will need to be handled some way. Perhaps the easiest would be to
check whether or not another channel is already running and check that
indeed the period as requested by the new channel matches that of any
running channels. If it doesn't match, then pwm_config() should fail.
When you do that you can also optimize this a bit by only setting the
frequency once. Whenever a new channel is configured it will have the same
period and therefore the register doesn't need to be reprogrammed.
Yes, if it dosen't match it should fail, or nothing to do with the period
register if it's not the first channel to be configured.
+static void fsl_pwm_disable(struct pwm_chip *chip, struct
+pwm_device
*pwm)
+{
+ struct fsl_pwm_chip *fpc;
+
+ fpc = to_fsl_chip(chip);
+
+ fsl_counter_clock_disable(fpc);
+}
Same here. Since you can't propagate the error, perhaps an error
message would be appropriate here?
Well, in fsl_counter_clock_disable(fpc); only '0' could be returned,
maybe let it a void type value to return is better.
Just like:
static void fsl_counter_clock_disable(struct fsl_pwm_chip *fpc)
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@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 07/12] efi: passing kexec necessary efi data via setup_data
On 11/29/13 at 05:46pm, Borislav Petkov wrote: On Fri, Nov 29, 2013 at 05:14:16PM +0800, Dave Young wrote: That's reserved for future extension use, who knows if we will need to pass other fields in the future. Hrrmmm, 8*64 = 64 Bytes?? And you can't change it later because of the situation where machines might be using older kexec-tools? Right, compatibility is the reason. Static function - no need for efi_ prefix. Ok. I'm not very satisfied with the function name, any better suggestion? reuse_config use_old_config_phys_addr update_config_entry_with_phys_addr Looks like we're applying quirks so apply_quirks()? Ok, it looks better, will use apply_quirks, thank you. And those kexec-specific quirks need to be behind CONFIG_KEXEC too, btw. All these setup_data passing, remapping etc. is mostly for kexec, add a lot of contiditional #if #endif makes the code a mess. I would prefer to not do this if you are not strongly object. Since Matt suggest to extend the function for other possible field other than smbios, so I would like to move comment to the front of the function like below: /* * For kexec kernel there's some special config table entries which will be * converted to virtual addresses after entering virtual mode. In kexec kernel * we need the physical addresses instead, thus passing them via setup_data * and update the entries to physical addresses in this function. * * Currently only handles smbios which is necessary for HP z420. */ That's better. Is there any idea in your mind how to add the code for HP only? DMI? I'm confused how to connect this with DMI.. Yes, __map_region return an error code will be better. Will you send a patch for __map_region? or I can add one more patch along with next version. I was going to wait for your patches to settle down first so that I don't disturb your work. But if you want to fix this, I certainly wouldn't want to stop you :) but please do so in a prepatch before your series which addresses only this issue. Ok, so I will leave this to you after this series settle down. Thanks Dave -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 00/12] Thunderbolt hotplug support for Apple hardware (testers needed)
On Friday, 29 November 2013 09:40:02 UTC+8, Andreas Noever wrote:
Thunderbolt hotplug is supposed to be implemented by the firmware. But Apple's
firmeware only initializes devices during boot and ignores hotplugged devices.
This patch series adds a driver for the Intel Cactus Ridge Thunderbolt
controller. The driver supports hotplug operations of simple (one PCI device,
no chaining) thunderbolt devices.
[...]
(1) and (2) should be solveable given some time. I also have a pretty good
idea
on how chaining should work. The main problem is that I have yet to see any
Thunderbolt device besides the Apple ethernet adapter. If someone with a
MacBook and access to more complicated TB hardware is willing to run some
tests: Please contact me.
I will try to debug (4) further and write a seperate bug report for the issue.
Booting with 3.12.2, your patch series, with acpi_osi=Darwin and no
thunderbolt devices plugged, I run into this oops:
dsl3510 :07:00.0: dma_pool_free dls3510 cfg,
8000/ee2429b8 (bad data)
kernel BUG at mm/slub.c:3338!
invalid opcode: [#1] SMP
tb_ctl_free_packet.isra.0+0x21/0x30
tb_cfg_rx_callback+0xbc/0x300
ring_drain_and_free+0x2c2/0x360
tb_cfg_free+0x1b/0x80
thunderbolt_shutdown_and_free
thunderbolt_alloc_and_start
dsl3510_probe
pci_device_probe
driver_probe_device
__driver_attach
? __device_attach
bus_for_each_dev
driver_attach
bus_add_driver
? extcon_class_init
driver_register
? extcon_class_init
__pci_register_driver
dsl3510_init
do_one_initcall
(gdb) list *(tb_ctl_free_packet+0x21)
0x815bb221 is in tb_ctl_free_packet (drivers/thunderbolt/tb_cfg.c:243).
238
239static void tb_ctl_free_packet(struct tb_cfg *cfg, struct
ring_packet *pkg)
240{
241dma_pool_free(cfg-packet_pool, pkg-buffer, pkg-buffer_phy);
242kfree(pkg);
243}
244
245/**
246 * tb_ctl_alloc_packets() - allocate multiple packets safely
247 *
Later, I'll add debug to see which path is being taken in
thunderbolt_alloc_and_start, as I guess that wasn't expected to fail,
though it looks like there's this teardown issue.
Thanks,
Daniel
--
Daniel J Blueman
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v1 1/2] lib/scatterlist: export sg_miter_skip()
On Mon, Dec 02, 2013 at 10:11:21AM +0800, Ming Lei wrote: On Sat, Nov 30, 2013 at 6:23 AM, Tejun Heo t...@kernel.org wrote: On Tue, Nov 26, 2013 at 12:43:37PM +0800, Ming Lei wrote: sg_copy_buffer() can't meet demand for some drrivers(such usb mass storage), so we have to use the sg_miter_* APIs to access sg buffer, then need export sg_miter_skip() for these drivers. The API is needed for converting to sg_miter_* APIs in USB storage driver for accessing sg buffer. Acked-by: Andrew Morton a...@linux-foundation.org Cc: FUJITA Tomonori fujita.tomon...@lab.ntt.co.jp Cc: Tejun Heo t...@kernel.org Cc: Jens Axboe ax...@kernel.dk Signed-off-by: Ming Lei ming@canonical.com Reviewed-by: Tejun Heo t...@kernel.org Thanks. I suppose this should go through -mm? Last round, Andrew said it can be though whatever tree, so given dependency reason, it is better to merge via greg's tree. Greg, could you merge these two patches via your usb-next tree? Yes, will do. -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@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 06/12] efi: export efi runtime memory mapping to sysfs
On 11/29/13 at 11:59am, Matt Fleming wrote: On Fri, 29 Nov, at 12:50:29PM, Borislav Petkov wrote: I did not add KEXEC because I thought it can be used for debugging purpose. mfleming is thinking about it :) I finally finished my thought. The sysfs code should be automatically enabled only if CONFIG_KEXEC is enabled, and not on my default because it is a debug interface. While it's true that the code may be useful for debugging the memory mappings of EFI systems, it doesn't make sense to always turn it on just for CONFIG_X86 and CONFIG_EFI. Ok, will enable it only for CONFIG_X86 and CONFIG_EFI and CONFIG_KEXEC -- Matt Fleming, Intel Open Source Technology Center -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@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 06/12] efi: export efi runtime memory mapping to sysfs
On 11/29/13 at 12:50pm, Borislav Petkov wrote: No need for the list - I actually meant you simply use a tmp pointer for each krealloc invocation - just look around the tree for examples. Also think about what happens to the pointed-to memory when krealloc returns NULL. Ok, thanks for the explaination. suppose kexec runtime map preparing fails we still can get 1st kernel boot ok. Yeah, nothing stops that - especially if you iterate over the mapped regions a second time separately, for kexec. Which reminds me, all that save_runtime_map code needs to be behind CONFIG_KEXEC. We don't want to be doing this if KEXEC is not enabled. They are only called if there's setup_data SETUP_EFI passed in. Yes, I think only kexec need that part of code. But I hesitated to mess the code with a lot of #if. Will think about it. Thanks Dave -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@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] f2fs: refactor bio-related operations
On 11/30/2013 02:25 PM, Jaegeuk Kim wrote:
This patch integrates redundant bio operations on read and write IOs.
1. Move bio-related codes to the top of data.c.
2. Replace f2fs_submit_bio with f2fs_submit_merged_bio, which handles read
bios additionally.
3. Introduce __submit_merged_bio to submit the merged bio.
4. Change f2fs_readpage to f2fs_submit_page_bio.
5. Introduce f2fs_submit_page_mbio to integrate previous submit_read_page and
submit_write_page.
Signed-off-by: Jaegeuk Kim jaegeuk@samsung.com
Reviewed-by: Gu Zheng guz.f...@cn.fujitsu.com
---
fs/f2fs/checkpoint.c| 14 +-
fs/f2fs/data.c | 317
+---
fs/f2fs/f2fs.h | 13 +-
fs/f2fs/gc.c| 2 +-
fs/f2fs/node.c | 14 +-
fs/f2fs/recovery.c | 4 +-
fs/f2fs/segment.c | 164 +++
include/trace/events/f2fs.h | 30 ++---
8 files changed, 259 insertions(+), 299 deletions(-)
diff --git a/fs/f2fs/checkpoint.c b/fs/f2fs/checkpoint.c
index 40eea42..38f4a224 100644
--- a/fs/f2fs/checkpoint.c
+++ b/fs/f2fs/checkpoint.c
@@ -61,7 +61,8 @@ repeat:
if (PageUptodate(page))
goto out;
- if (f2fs_readpage(sbi, page, index, READ_SYNC | REQ_META | REQ_PRIO))
+ if (f2fs_submit_page_bio(sbi, page, index,
+ READ_SYNC | REQ_META | REQ_PRIO))
goto repeat;
lock_page(page);
@@ -157,7 +158,8 @@ long sync_meta_pages(struct f2fs_sb_info *sbi, enum
page_type type,
}
if (nwritten)
- f2fs_submit_bio(sbi, type, nr_to_write == LONG_MAX);
+ f2fs_submit_merged_bio(sbi, type, nr_to_write == LONG_MAX,
+ WRITE);
return nwritten;
}
@@ -590,7 +592,7 @@ retry:
* We should submit bio, since it exists several
* wribacking dentry pages in the freeing inode.
*/
- f2fs_submit_bio(sbi, DATA, true);
+ f2fs_submit_merged_bio(sbi, DATA, true, WRITE);
}
goto retry;
}
@@ -796,9 +798,9 @@ void write_checkpoint(struct f2fs_sb_info *sbi, bool
is_umount)
trace_f2fs_write_checkpoint(sbi-sb, is_umount, finish block_ops);
- f2fs_submit_bio(sbi, DATA, true);
- f2fs_submit_bio(sbi, NODE, true);
- f2fs_submit_bio(sbi, META, true);
+ f2fs_submit_merged_bio(sbi, DATA, true, WRITE);
+ f2fs_submit_merged_bio(sbi, NODE, true, WRITE);
+ f2fs_submit_merged_bio(sbi, META, true, WRITE);
/*
* update checkpoint pack index
diff --git a/fs/f2fs/data.c b/fs/f2fs/data.c
index c9a76f8..53e3bbb 100644
--- a/fs/f2fs/data.c
+++ b/fs/f2fs/data.c
@@ -25,6 +25,205 @@
#include trace/events/f2fs.h
/*
+ * Low-level block read/write IO operations.
+ */
+static struct bio *__bio_alloc(struct block_device *bdev, int npages)
+{
+ struct bio *bio;
+
+ /* No failure on bio allocation */
+ bio = bio_alloc(GFP_NOIO, npages);
+ bio-bi_bdev = bdev;
+ bio-bi_private = NULL;
+ return bio;
+}
+
+static void f2fs_read_end_io(struct bio *bio, int err)
+{
+ const int uptodate = test_bit(BIO_UPTODATE, bio-bi_flags);
+ struct bio_vec *bvec = bio-bi_io_vec + bio-bi_vcnt - 1;
+
+ do {
+ struct page *page = bvec-bv_page;
+
+ if (--bvec = bio-bi_io_vec)
+ prefetchw(bvec-bv_page-flags);
+
+ if (uptodate) {
+ SetPageUptodate(page);
+ } else {
+ ClearPageUptodate(page);
+ SetPageError(page);
+ }
+ unlock_page(page);
+ } while (bvec = bio-bi_io_vec);
+
+ bio_put(bio);
+}
+
+static void f2fs_write_end_io(struct bio *bio, int err)
+{
+ const int uptodate = test_bit(BIO_UPTODATE, bio-bi_flags);
+ struct bio_vec *bvec = bio-bi_io_vec + bio-bi_vcnt - 1;
+ struct f2fs_sb_info *sbi = F2FS_SB(bvec-bv_page-mapping-host-i_sb);
+
+ do {
+ struct page *page = bvec-bv_page;
+
+ if (--bvec = bio-bi_io_vec)
+ prefetchw(bvec-bv_page-flags);
+
+ if (!uptodate) {
+ SetPageError(page);
+ set_bit(AS_EIO, page-mapping-flags);
+ set_ckpt_flags(sbi-ckpt, CP_ERROR_FLAG);
+ sbi-sb-s_flags |= MS_RDONLY;
+ }
+ end_page_writeback(page);
+ dec_page_count(sbi, F2FS_WRITEBACK);
+ } while (bvec = bio-bi_io_vec);
+
+ if (bio-bi_private)
+ complete(bio-bi_private);
+
+ if (!get_pages(sbi, F2FS_WRITEBACK)
+ !list_empty(sbi-cp_wait.task_list))
+ wake_up(sbi-cp_wait);
+
+ bio_put(bio);
+}
+
+static void __submit_merged_bio(struct
Re: [PATCH v2 2/2] clk: add accuracy support for fixed clock
Boris, Sorry for the delay. On Wed, Nov 27, 2013 at 06:19:08PM +0100, boris brezillon wrote: On 27/11/2013 15:56, Jason Cooper wrote: On Wed, Nov 27, 2013 at 01:44:45PM +0100, Boris BREZILLON wrote: This patch adds support for accuracy retrieval on fixed clocks. It also adds a new dt property called 'clock-accuracy' to define the clock accuracy. This can be usefull for oscillator (RC, crystal, ...) definitions which are always given an accuracy characteristic. I think we need to be more explicit in the binding and the API, especially when providing a method to recalculate the accuracy. I presume this recalculated value would be relative against the root clock? Yes, indirectly. Actually the clk accuracy depends on the whole clock chain, and is calculated either by comparing the real clk rate to the theorical clk rate (accuracy = absolute_value((theorical_clk_rate - real_clk_rate)) / theorical_clk_rate), or by adding all the accuracies (expressed in ppm, ppb or ppt) of the clk chain (accuracy = current_clk_accuracy + parent_clk_accuracy). Say you have a root clk with a +-1 ppb accuracy, then a pll multiplying this root clk by 40 and introducing a possible drift of +- 1000 ppb and eventually a system clk based on this pll with a perfect div by 2 prescaler (accuracy = 0 ppb). If I understand correctly how accuracy propagates accross the clk tree, you'll end up with a system clk with a +- 11000 ppb accuracy. e.g.: root clk = 12MHz +- 1 ppb = 12 MHz * (1 - (1 / 10^9)) root clk 12 MHz * (1 + (1 / 10^9)) = 11,99988 MHz root clk 12,00012 MHz pll clk = ((root clk) * 40) +- 1000 ppb = (11,99988 MHz * 40) * (1 - (1000 / 10^9)) pll clk (12,00012 MHz * 40) * (1 + (1000 / 10^9)) = 479,994720005 MHz pll clk 480,005280005 MHz system clk = ((pll clk) / 2) +- XXX ppb = 479,994720005 MHz / 2 system clk 480,005280005 MHz / 2 = 239,997360002 MHz system clk 240,002640002 MHz = system clk accuracy = 0,002640002 / 240 = 11000 ppb Please tell me if my assumptions are false. Nope, it looks fine by me afaict. Thanks for the clear walk through. There really needs to be two attributes here: the rated accuracy from the manufacturer, and the calculated accuracy wrt another clock in the system. We only need a binding for the manufacturer rating since the calculated accuracy is determined at runtime. Actually when I proposed this new functionnality I only had the theorical (or manufacturer rated) accuracy in mind. Yes, I see we are concerned about two different things. You need to get the theoretical accuracy to assist with clock selection. I was concerned that the recalc function was attempting to measure the real accuracy of a given clock from a tree. Since we're only talking theoretical accuracy, that makes things a lot simpler. :) But providing an estimated accuracy (based on another clk) sounds interresting if your reference clk is an extremly accurate one. Yes, I was thinking against a GPS PPS signal, but again, not relevant to this patch series. Also, it would be complicated by the fact that there is no high-speed counter on ARM. I would also prefer to see an unknown accuracy be -1. I decided to keep 0 as a default value for unimplemented recalc_accuracy (or unspecified fixed accuracy) to keep existing implementation coherent. 0 means the clk is perfect, and I thought it would be easier to handle a perfect clk (even if this is not really the case) than handling an error case. Another aspect is the propagation of the clk accuracy accross the clk tree. Returning -1 in the middle of the clk chain will drop the previous clk accuracy calculation. Anyway, I can change this if you think this is more appropriate. No, in light of this being purely theoretical accuracy, I'm fine with it if Mike is. There are already clocks on the market (PPS reference clocks) with accuracies of 0.1ppb/day [1]. Obviously, these aren't system clocks. So the limit on accuracy may be a non-issue. However, it may be worth changing the binding property to express the units. Wow, 0.1 ppb, this is impressive :-). This needs more than changing the dt bindings: I currently store the accuracy value in an unsigned long field, and expressing this in ppt (parts per trillion) may implies storing this in an u64 field (or store a unit field). No, let's not derail this series. ;-) You've addressed my concerns. Thanks for taking the time to bring me up to speed. thx, Jason. -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at
[PATCH 2/2] rtc: rtc-mxc: Check the return value from clk_prepare_enable()
From: Fabio Estevam fabio.este...@freescale.com clk_prepare_enable() may fail, so let's check its return value and propagate it in the case of error. Signed-off-by: Fabio Estevam fabio.este...@freescale.com --- drivers/rtc/rtc-mxc.c | 5 - 1 file changed, 4 insertions(+), 1 deletion(-) diff --git a/drivers/rtc/rtc-mxc.c b/drivers/rtc/rtc-mxc.c index a3ed1cf..419874f 100644 --- a/drivers/rtc/rtc-mxc.c +++ b/drivers/rtc/rtc-mxc.c @@ -394,7 +394,10 @@ static int mxc_rtc_probe(struct platform_device *pdev) return PTR_ERR(pdata-clk); } - clk_prepare_enable(pdata-clk); + ret = clk_prepare_enable(pdata-clk); + if (ret) + return ret; + rate = clk_get_rate(pdata-clk); if (rate == 32768) -- 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 1/2] rtc: rtc-mxc: Remove unneeded label
From: Fabio Estevam fabio.este...@freescale.com
There is no need to jump to the 'exit_free_pdata' label when devm_clk_get()
fails, as we can directly return the error and simplify the code a bit.
Signed-off-by: Fabio Estevam fabio.este...@freescale.com
---
drivers/rtc/rtc-mxc.c | 5 +
1 file changed, 1 insertion(+), 4 deletions(-)
diff --git a/drivers/rtc/rtc-mxc.c b/drivers/rtc/rtc-mxc.c
index 50c5726..a3ed1cf 100644
--- a/drivers/rtc/rtc-mxc.c
+++ b/drivers/rtc/rtc-mxc.c
@@ -391,8 +391,7 @@ static int mxc_rtc_probe(struct platform_device *pdev)
pdata-clk = devm_clk_get(pdev-dev, NULL);
if (IS_ERR(pdata-clk)) {
dev_err(pdev-dev, unable to get clock!\n);
- ret = PTR_ERR(pdata-clk);
- goto exit_free_pdata;
+ return PTR_ERR(pdata-clk);
}
clk_prepare_enable(pdata-clk);
@@ -447,8 +446,6 @@ static int mxc_rtc_probe(struct platform_device *pdev)
exit_put_clk:
clk_disable_unprepare(pdata-clk);
-exit_free_pdata:
-
return ret;
}
--
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/
ping: re: [PATCH 1/1] kernel code that do not handle NULL return of kmem_cache_zalloc
ping
I do a grep for kmem_cache_zalloc and kmem_cache_alloc
in kernel tree, and find some code do not handle NULL
return of kmem_cache_zalloc correctly
Signed-off-by: Zhouyi Zhou yizhouz...@ict.ac.cn
---
arch/powerpc/kvm/book3s_32_mmu_host.c |5 +
drivers/iommu/omap-iommu.c|3 ++-
fs/jffs2/malloc.c |4
3 files changed, 11 insertions(+), 1 deletion(-)
diff --git a/arch/powerpc/kvm/book3s_32_mmu_host.c
b/arch/powerpc/kvm/book3s_32_mmu_host.c
index 3a0abd2..5fac89d 100644
--- a/arch/powerpc/kvm/book3s_32_mmu_host.c
+++ b/arch/powerpc/kvm/book3s_32_mmu_host.c
@@ -243,6 +243,11 @@ next_pteg:
/* Now tell our Shadow PTE code about the new page */
pte = kvmppc_mmu_hpte_cache_next(vcpu);
+ if (!pte) {
+ kvm_release_pfn_clean(hpaddr PAGE_SHIFT);
+ r = -EAGAIN;
+ goto out;
+ }
dprintk_mmu(KVM: %c%c Map 0x%llx: [%lx] 0x%llx (0x%llx) - %lx\n,
orig_pte-may_write ? 'w' : '-',
diff --git a/drivers/iommu/omap-iommu.c b/drivers/iommu/omap-iommu.c
index bcd78a7..5155714 100644
--- a/drivers/iommu/omap-iommu.c
+++ b/drivers/iommu/omap-iommu.c
@@ -551,7 +551,8 @@ static u32 *iopte_alloc(struct omap_iommu *obj, u32
*iopgd, u32 da)
dev_vdbg(obj-dev, %s: a new pte:%p\n, __func__, iopte);
} else {
/* We raced, free the reduniovant table */
- iopte_free(iopte);
+ if (iopte)
+ iopte_free(iopte);
}
pte_ready:
diff --git a/fs/jffs2/malloc.c b/fs/jffs2/malloc.c
index 4f47aa2..58e2336 100644
--- a/fs/jffs2/malloc.c
+++ b/fs/jffs2/malloc.c
@@ -287,6 +287,8 @@ struct jffs2_xattr_datum *jffs2_alloc_xattr_datum(void)
{
struct jffs2_xattr_datum *xd;
xd = kmem_cache_zalloc(xattr_datum_cache, GFP_KERNEL);
+ if (!xd)
+ return NULL;
dbg_memalloc(%p\n, xd);
xd-class = RAWNODE_CLASS_XATTR_DATUM;
@@ -305,6 +307,8 @@ struct jffs2_xattr_ref *jffs2_alloc_xattr_ref(void)
{
struct jffs2_xattr_ref *ref;
ref = kmem_cache_zalloc(xattr_ref_cache, GFP_KERNEL);
+ if (!ref)
+ return NULL;
dbg_memalloc(%p\n, ref);
ref-class = RAWNODE_CLASS_XATTR_REF;
--
1.7.10.4
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2 2/2] clk: add accuracy support for fixed clock
On Thu, Nov 28, 2013 at 09:02:58AM +0100, boris brezillon wrote: On 27/11/2013 19:10, Mike Turquette wrote: Quoting boris brezillon (2013-11-27 09:19:08) On Wed, Nov 27, 2013 at 01:44:45PM +0100, Boris BREZILLON wrote: ... I would also prefer to see an unknown accuracy be -1. I decided to keep 0 as a default value for unimplemented recalc_accuracy (or unspecified fixed accuracy) to keep existing implementation coherent. 0 means the clk is perfect, and I thought it would be easier to handle a perfect clk (even if this is not really the case) than handling an error case. Another aspect is the propagation of the clk accuracy accross the clk tree. Returning -1 in the middle of the clk chain will drop the previous clk accuracy calculation. Anyway, I can change this if you think this is more appropriate. What about the absence of the property? Instead of requiring a -1 value can we simply detect that the property does not exist? This is nicer for backwards compatibility with existing DTS. I already handle the absence of the clock-accuracy property. In this case the clock is considered perfect (accuracy = 0 ppb). Yeah, in order to calculate the theoretical accuracy of a leaf node, a missing accuracy in the middle of the chain really derails things. Since my previous concern (modelling the real accuracy of the clocks) is not an issue here, I think assuming the absent accuracy is 0 is fine. Especially since all Boris is trying to do is avoid the RC clocks. thx, Jason. -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@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/5] serial: 8250_pci: use DEFINE_PCI_DEVICE_TABLE macro
On 12/01/2013 04:07 PM, Jingoo Han wrote:
On Friday, November 29, 2013 10:34 AM, Jingoo Han wrote:
On Thursday, November 28, 2013 3:24 PM, Joe Perches wrote:
On Wed, 2013-11-27 at 21:53 -0800, 'Greg Kroah-Hartman' wrote:
On Wed, Nov 27, 2013 at 09:40:13PM -0800, Joe Perches wrote:
On Thu, 2013-11-28 at 14:29 +0900, Jingoo Han wrote:
On Thursday, November 28, 2013 1:08 PM, Greg Kroah-Hartman wrote:
On Thu, Nov 28, 2013 at 10:55:35AM +0900, Jingoo Han wrote:
This macro is used to create a struct pci_device_id array.
Yeah, and it's a horrid macro that deserves to be removed, please don't
use it in more places.
Actually, if you could just remove it, that would be best, sorry, I'm
not going to take these patches.
(+cc Joe Perches, Andrew Morton, Andy Whitcroft)
Hi Joe Perches,
Would you fix checkpatch.pl about DEFINE_PCI_DEVICE_TABLE?
Currently, checkpatch.pl guides to use DEFINE_PCI_DEVICE_TABLE
as below.
WARNING: Use DEFINE_PCI_DEVICE_TABLE for struct pci_device_id
#331: FILE: drivers/usb/host/ehci-pci.c:331:
+static const struct pci_device_id pci_ids [] = { {
However, Greg Kroah-Hartman mentioned that DEFINE_PCI_DEVICE_TABLE
shouldn't be used anymore.
So, would you change checkpatch.pl in order to guide to use
struct pci_device_id instead of DEFINE_PCI_DEVICE_TABLE?
For example,
WARNING: Use struct pci_device_id instead of DEFINE_PCI_DEVICE_TABLE
The documentation doesn't agree with Greg.
[]
I say just remove it, I should have done that years ago when I was the
PCI maintainer, just never got around to it. No other bus has something
like this for their device ids, why should PCI be special?
Anyone else have an opinion?
I don't care one way or another, but please, one way
not two.
Same here.
(+cc Bjorn Helgaas, linux-pci)
Then, how about the following steps?
1. Fix ./Documentation/PCI/pci.txt as below.
(Jingoo Han)
The ID table is an array of struct pci_device_id entries ending with an
-all-zero entry; use of the macro DEFINE_PCI_DEVICE_TABLE is the preferred
-method of declaring the table. Each entry consists of:
+all-zero entry; Each entry consists of:
2. Fix ./scripts/checkpatch.pl in order to guide to use
struct pci_device_id instead of DEFINE_PCI_DEVICE_TABLE.
(Joe Perches)
If all DEFINE_PCI_DEVICE_TABLEs are replaced with 'const struct pci_device_id'
and these patches are merged through 'driver-core.git', it will be not
necessary to fix ./scripts/checkpatch.pl.
Why not ?
Guenter
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/5] serial: 8250_pci: use DEFINE_PCI_DEVICE_TABLE macro
On Monday, December 02, 2013 12:46 PM, Guenter Roeck wrote:
On 12/01/2013 04:07 PM, Jingoo Han wrote:
On Friday, November 29, 2013 10:34 AM, Jingoo Han wrote:
On Thursday, November 28, 2013 3:24 PM, Joe Perches wrote:
On Wed, 2013-11-27 at 21:53 -0800, 'Greg Kroah-Hartman' wrote:
On Wed, Nov 27, 2013 at 09:40:13PM -0800, Joe Perches wrote:
On Thu, 2013-11-28 at 14:29 +0900, Jingoo Han wrote:
On Thursday, November 28, 2013 1:08 PM, Greg Kroah-Hartman wrote:
On Thu, Nov 28, 2013 at 10:55:35AM +0900, Jingoo Han wrote:
This macro is used to create a struct pci_device_id array.
Yeah, and it's a horrid macro that deserves to be removed, please
don't
use it in more places.
Actually, if you could just remove it, that would be best, sorry, I'm
not going to take these patches.
(+cc Joe Perches, Andrew Morton, Andy Whitcroft)
Hi Joe Perches,
Would you fix checkpatch.pl about DEFINE_PCI_DEVICE_TABLE?
Currently, checkpatch.pl guides to use DEFINE_PCI_DEVICE_TABLE
as below.
WARNING: Use DEFINE_PCI_DEVICE_TABLE for struct pci_device_id
#331: FILE: drivers/usb/host/ehci-pci.c:331:
+static const struct pci_device_id pci_ids [] = { {
However, Greg Kroah-Hartman mentioned that DEFINE_PCI_DEVICE_TABLE
shouldn't be used anymore.
So, would you change checkpatch.pl in order to guide to use
struct pci_device_id instead of DEFINE_PCI_DEVICE_TABLE?
For example,
WARNING: Use struct pci_device_id instead of DEFINE_PCI_DEVICE_TABLE
The documentation doesn't agree with Greg.
[]
I say just remove it, I should have done that years ago when I was the
PCI maintainer, just never got around to it. No other bus has something
like this for their device ids, why should PCI be special?
Anyone else have an opinion?
I don't care one way or another, but please, one way
not two.
Same here.
(+cc Bjorn Helgaas, linux-pci)
Then, how about the following steps?
1. Fix ./Documentation/PCI/pci.txt as below.
(Jingoo Han)
The ID table is an array of struct pci_device_id entries ending with an
-all-zero entry; use of the macro DEFINE_PCI_DEVICE_TABLE is the
preferred
-method of declaring the table. Each entry consists of:
+all-zero entry; Each entry consists of:
2. Fix ./scripts/checkpatch.pl in order to guide to use
struct pci_device_id instead of DEFINE_PCI_DEVICE_TABLE.
(Joe Perches)
If all DEFINE_PCI_DEVICE_TABLEs are replaced with 'const struct
pci_device_id'
and these patches are merged through 'driver-core.git', it will be not
necessary to fix ./scripts/checkpatch.pl.
Why not ?
I will replace all DEFINE_PCI_DEVICE_TABLEs with 'const struct pci_device_id',
and remove the definition of DEFINE_PCI_DEVICE_TABLE macro.
--- a/include/linux/pci.h
+++ b/include/linux/pci.h
@@ -631,16 +631,6 @@ struct pci_driver {
#defineto_pci_driver(drv) container_of(drv, struct pci_driver, driver)
/**
- * DEFINE_PCI_DEVICE_TABLE - macro used to describe a pci device table
- * @_table: device table name
- *
- * This macro is used to create a struct pci_device_id array (a device table)
- * in a generic manner.
- */
-#define DEFINE_PCI_DEVICE_TABLE(_table) \
- const struct pci_device_id _table[]
-
-/**
In this case, there is no DEFINE_PCI_DEVICE_TABLE usage
in the kernel. If someone uses DEFINE_PCI_DEVICE_TABLE macro,
it will make build error.
Best regards,
Jingoo Han
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@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/5] serial: 8250_pci: use DEFINE_PCI_DEVICE_TABLE macro
On 12/01/2013 07:50 PM, Jingoo Han wrote:
On Monday, December 02, 2013 12:46 PM, Guenter Roeck wrote:
On 12/01/2013 04:07 PM, Jingoo Han wrote:
On Friday, November 29, 2013 10:34 AM, Jingoo Han wrote:
On Thursday, November 28, 2013 3:24 PM, Joe Perches wrote:
On Wed, 2013-11-27 at 21:53 -0800, 'Greg Kroah-Hartman' wrote:
On Wed, Nov 27, 2013 at 09:40:13PM -0800, Joe Perches wrote:
On Thu, 2013-11-28 at 14:29 +0900, Jingoo Han wrote:
On Thursday, November 28, 2013 1:08 PM, Greg Kroah-Hartman wrote:
On Thu, Nov 28, 2013 at 10:55:35AM +0900, Jingoo Han wrote:
This macro is used to create a struct pci_device_id array.
Yeah, and it's a horrid macro that deserves to be removed, please don't
use it in more places.
Actually, if you could just remove it, that would be best, sorry, I'm
not going to take these patches.
(+cc Joe Perches, Andrew Morton, Andy Whitcroft)
Hi Joe Perches,
Would you fix checkpatch.pl about DEFINE_PCI_DEVICE_TABLE?
Currently, checkpatch.pl guides to use DEFINE_PCI_DEVICE_TABLE
as below.
WARNING: Use DEFINE_PCI_DEVICE_TABLE for struct pci_device_id
#331: FILE: drivers/usb/host/ehci-pci.c:331:
+static const struct pci_device_id pci_ids [] = { {
However, Greg Kroah-Hartman mentioned that DEFINE_PCI_DEVICE_TABLE
shouldn't be used anymore.
So, would you change checkpatch.pl in order to guide to use
struct pci_device_id instead of DEFINE_PCI_DEVICE_TABLE?
For example,
WARNING: Use struct pci_device_id instead of DEFINE_PCI_DEVICE_TABLE
The documentation doesn't agree with Greg.
[]
I say just remove it, I should have done that years ago when I was the
PCI maintainer, just never got around to it. No other bus has something
like this for their device ids, why should PCI be special?
Anyone else have an opinion?
I don't care one way or another, but please, one way
not two.
Same here.
(+cc Bjorn Helgaas, linux-pci)
Then, how about the following steps?
1. Fix ./Documentation/PCI/pci.txt as below.
(Jingoo Han)
The ID table is an array of struct pci_device_id entries ending with an
-all-zero entry; use of the macro DEFINE_PCI_DEVICE_TABLE is the preferred
-method of declaring the table. Each entry consists of:
+all-zero entry; Each entry consists of:
2. Fix ./scripts/checkpatch.pl in order to guide to use
struct pci_device_id instead of DEFINE_PCI_DEVICE_TABLE.
(Joe Perches)
If all DEFINE_PCI_DEVICE_TABLEs are replaced with 'const struct pci_device_id'
and these patches are merged through 'driver-core.git', it will be not
necessary to fix ./scripts/checkpatch.pl.
Why not ?
I will replace all DEFINE_PCI_DEVICE_TABLEs with 'const struct pci_device_id',
and remove the definition of DEFINE_PCI_DEVICE_TABLE macro.
--- a/include/linux/pci.h
+++ b/include/linux/pci.h
@@ -631,16 +631,6 @@ struct pci_driver {
#defineto_pci_driver(drv) container_of(drv, struct pci_driver, driver)
/**
- * DEFINE_PCI_DEVICE_TABLE - macro used to describe a pci device table
- * @_table: device table name
- *
- * This macro is used to create a struct pci_device_id array (a device table)
- * in a generic manner.
- */
-#define DEFINE_PCI_DEVICE_TABLE(_table) \
- const struct pci_device_id _table[]
-
-/**
In this case, there is no DEFINE_PCI_DEVICE_TABLE usage
in the kernel. If someone uses DEFINE_PCI_DEVICE_TABLE macro,
it will make build error.
And that will make the checkpatch warning go away ?
That seems to be very unlikely.
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/
linux-next: manual merge of the block tree with the f2fs tree
Hi Jens,
Today's linux-next merge of the block tree got conflicts in
fs/f2fs/data.c and fs/f2fs/segment.c between commits 0626804cd9a6 (f2fs:
remove the own bi_private allocation) and 899d7625d85a (f2fs: refactor
bio-related operations) from the f2fs tree and commits 2c30c71bd653
(block: Convert various code to bio_for_each_segment()) and (block:
Abstract out bvec iterator) from the block tree.
I fixed it up (hopefully - see below - the handling of sbi in
f2fs_end_io_write is not the best) and can carry the fix as necessary (no
action is required).
--
Cheers,
Stephen Rothwells...@canb.auug.org.au
diff --cc fs/f2fs/data.c
index 53e3a7ed,a2c8de8ba6ce..b62a99cf6561
--- a/fs/f2fs/data.c
+++ b/fs/f2fs/data.c
@@@ -25,205 -25,6 +25,201 @@@
#include trace/events/f2fs.h
/*
+ * Low-level block read/write IO operations.
+ */
+static struct bio *__bio_alloc(struct block_device *bdev, int npages)
+{
+ struct bio *bio;
+
+ /* No failure on bio allocation */
+ bio = bio_alloc(GFP_NOIO, npages);
+ bio-bi_bdev = bdev;
+ bio-bi_private = NULL;
+ return bio;
+}
+
+static void f2fs_read_end_io(struct bio *bio, int err)
+{
- const int uptodate = test_bit(BIO_UPTODATE, bio-bi_flags);
- struct bio_vec *bvec = bio-bi_io_vec + bio-bi_vcnt - 1;
++ struct bio_vec *bvec;
++ int i;
+
- do {
++ bio_for_each_segment_all(bvec, bio, i) {
+ struct page *page = bvec-bv_page;
+
- if (--bvec = bio-bi_io_vec)
- prefetchw(bvec-bv_page-flags);
-
- if (uptodate) {
++ if (!err) {
+ SetPageUptodate(page);
+ } else {
+ ClearPageUptodate(page);
+ SetPageError(page);
+ }
+ unlock_page(page);
- } while (bvec = bio-bi_io_vec);
++ }
+
+ bio_put(bio);
+}
+
+static void f2fs_write_end_io(struct bio *bio, int err)
+{
- const int uptodate = test_bit(BIO_UPTODATE, bio-bi_flags);
- struct bio_vec *bvec = bio-bi_io_vec + bio-bi_vcnt - 1;
- struct f2fs_sb_info *sbi = F2FS_SB(bvec-bv_page-mapping-host-i_sb);
++ struct f2fs_sb_info *sbi = NULL;
++ struct bio_vec *bvec;
++ int i;
+
- do {
++ bio_for_each_segment_all(bvec, bio, i) {
+ struct page *page = bvec-bv_page;
+
- if (--bvec = bio-bi_io_vec)
- prefetchw(bvec-bv_page-flags);
-
- if (!uptodate) {
++ if (!sbi)
++ sbi = F2FS_SB(bvec-bv_page-mapping-host-i_sb);
++ if (err) {
+ SetPageError(page);
+ set_bit(AS_EIO, page-mapping-flags);
+ set_ckpt_flags(sbi-ckpt, CP_ERROR_FLAG);
+ sbi-sb-s_flags |= MS_RDONLY;
+ }
+ end_page_writeback(page);
+ dec_page_count(sbi, F2FS_WRITEBACK);
- } while (bvec = bio-bi_io_vec);
++ }
+
+ if (bio-bi_private)
+ complete(bio-bi_private);
+
+ if (!get_pages(sbi, F2FS_WRITEBACK)
+ !list_empty(sbi-cp_wait.task_list))
+ wake_up(sbi-cp_wait);
+
+ bio_put(bio);
+}
+
+static void __submit_merged_bio(struct f2fs_sb_info *sbi,
+ struct f2fs_bio_info *io,
+ enum page_type type, bool sync, int rw)
+{
+ enum page_type btype = PAGE_TYPE_OF_BIO(type);
+
+ if (!io-bio)
+ return;
+
+ if (btype == META)
+ rw |= REQ_META;
+
+ if (is_read_io(rw)) {
+ if (sync)
+ rw |= READ_SYNC;
+ submit_bio(rw, io-bio);
+ trace_f2fs_submit_read_bio(sbi-sb, rw, type, io-bio);
+ io-bio = NULL;
+ return;
+ }
+
+ if (sync)
+ rw |= WRITE_SYNC;
+ if (type = META_FLUSH)
+ rw |= WRITE_FLUSH_FUA;
+
+ /*
+ * META_FLUSH is only from the checkpoint procedure, and we should wait
+ * this metadata bio for FS consistency.
+ */
+ if (type == META_FLUSH) {
+ DECLARE_COMPLETION_ONSTACK(wait);
+ io-bio-bi_private = wait;
+ submit_bio(rw, io-bio);
+ wait_for_completion(wait);
+ } else {
+ submit_bio(rw, io-bio);
+ }
+ trace_f2fs_submit_write_bio(sbi-sb, rw, btype, io-bio);
+ io-bio = NULL;
+}
+
+void f2fs_submit_merged_bio(struct f2fs_sb_info *sbi,
+ enum page_type type, bool sync, int rw)
+{
+ enum page_type btype = PAGE_TYPE_OF_BIO(type);
+ struct f2fs_bio_info *io;
+
+ io = is_read_io(rw) ? sbi-read_io : sbi-write_io[btype];
+
+ mutex_lock(io-io_mutex);
+ __submit_merged_bio(sbi, io, type, sync, rw);
+
Re: [PATCH 1/5] serial: 8250_pci: use DEFINE_PCI_DEVICE_TABLE macro
On Monday, December 02, 2013 12:56 PM, Guenter Roeck wrote:
On 12/01/2013 07:50 PM, Jingoo Han wrote:
On Monday, December 02, 2013 12:46 PM, Guenter Roeck wrote:
On 12/01/2013 04:07 PM, Jingoo Han wrote:
On Friday, November 29, 2013 10:34 AM, Jingoo Han wrote:
On Thursday, November 28, 2013 3:24 PM, Joe Perches wrote:
On Wed, 2013-11-27 at 21:53 -0800, 'Greg Kroah-Hartman' wrote:
On Wed, Nov 27, 2013 at 09:40:13PM -0800, Joe Perches wrote:
On Thu, 2013-11-28 at 14:29 +0900, Jingoo Han wrote:
On Thursday, November 28, 2013 1:08 PM, Greg Kroah-Hartman wrote:
On Thu, Nov 28, 2013 at 10:55:35AM +0900, Jingoo Han wrote:
This macro is used to create a struct pci_device_id array.
Yeah, and it's a horrid macro that deserves to be removed, please
don't
use it in more places.
Actually, if you could just remove it, that would be best, sorry,
I'm
not going to take these patches.
(+cc Joe Perches, Andrew Morton, Andy Whitcroft)
Hi Joe Perches,
Would you fix checkpatch.pl about DEFINE_PCI_DEVICE_TABLE?
Currently, checkpatch.pl guides to use DEFINE_PCI_DEVICE_TABLE
as below.
WARNING: Use DEFINE_PCI_DEVICE_TABLE for struct pci_device_id
#331: FILE: drivers/usb/host/ehci-pci.c:331:
+static const struct pci_device_id pci_ids [] = { {
However, Greg Kroah-Hartman mentioned that DEFINE_PCI_DEVICE_TABLE
shouldn't be used anymore.
So, would you change checkpatch.pl in order to guide to use
struct pci_device_id instead of DEFINE_PCI_DEVICE_TABLE?
For example,
WARNING: Use struct pci_device_id instead of
DEFINE_PCI_DEVICE_TABLE
The documentation doesn't agree with Greg.
[]
I say just remove it, I should have done that years ago when I was the
PCI maintainer, just never got around to it. No other bus has
something
like this for their device ids, why should PCI be special?
Anyone else have an opinion?
I don't care one way or another, but please, one way
not two.
Same here.
(+cc Bjorn Helgaas, linux-pci)
Then, how about the following steps?
1. Fix ./Documentation/PCI/pci.txt as below.
(Jingoo Han)
The ID table is an array of struct pci_device_id entries ending
with an
-all-zero entry; use of the macro DEFINE_PCI_DEVICE_TABLE is the
preferred
-method of declaring the table. Each entry consists of:
+all-zero entry; Each entry consists of:
2. Fix ./scripts/checkpatch.pl in order to guide to use
struct pci_device_id instead of DEFINE_PCI_DEVICE_TABLE.
(Joe Perches)
If all DEFINE_PCI_DEVICE_TABLEs are replaced with 'const struct
pci_device_id'
and these patches are merged through 'driver-core.git', it will be not
necessary to fix ./scripts/checkpatch.pl.
Why not ?
I will replace all DEFINE_PCI_DEVICE_TABLEs with 'const struct
pci_device_id',
and remove the definition of DEFINE_PCI_DEVICE_TABLE macro.
--- a/include/linux/pci.h
+++ b/include/linux/pci.h
@@ -631,16 +631,6 @@ struct pci_driver {
#defineto_pci_driver(drv) container_of(drv, struct pci_driver,
driver)
/**
- * DEFINE_PCI_DEVICE_TABLE - macro used to describe a pci device table
- * @_table: device table name
- *
- * This macro is used to create a struct pci_device_id array (a device
table)
- * in a generic manner.
- */
-#define DEFINE_PCI_DEVICE_TABLE(_table) \
- const struct pci_device_id _table[]
-
-/**
In this case, there is no DEFINE_PCI_DEVICE_TABLE usage
in the kernel. If someone uses DEFINE_PCI_DEVICE_TABLE macro,
it will make build error.
And that will make the checkpatch warning go away ?
That seems to be very unlikely.
OK, I will ask Joe Perches to remove the following checkpatch
warning.
WARNING: Use DEFINE_PCI_DEVICE_TABLE for struct pci_device_id
Best regards,
Jingoo Han
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@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: [f2fs-dev] [PATCH 2/5] f2fs: add unlikely macro for compiler optimization
Hi Kim,
-Original Message-
From: Jaegeuk Kim [mailto:jaegeuk@samsung.com]
Sent: Friday, November 29, 2013 6:14 PM
To: Chao Yu
Cc: linux-fsde...@vger.kernel.org; linux-kernel@vger.kernel.org;
linux-f2fs-de...@lists.sourceforge.net; 谭姝
Subject: Re: [f2fs-dev] [PATCH 2/5] f2fs: add unlikely macro for compiler
optimization
Hi,
Could you make a patch to add *unlikely* as many as possible across the
whole source files at once?
It is wasteful to add it with a bunch of patches at multiple times.
Alright, I will work on this.
And please write descriptions for all the patches even if nothing is
special.
In this case, why should we set *unlikely* for checking this condition?
Got it.
Regards,
Yu
Thanks,
2013-11-28 (목), 15:42 +0800, Chao Yu:
Signed-off-by: Chao Yu chao2...@samsung.com
---
fs/f2fs/node.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/fs/f2fs/node.c b/fs/f2fs/node.c
index 0fe9a97..954155b 100644
--- a/fs/f2fs/node.c
+++ b/fs/f2fs/node.c
@@ -1160,7 +1160,7 @@ int wait_on_node_pages_writeback(struct f2fs_sb_info
*sbi, nid_t ino)
struct page *page = pvec.pages[i];
/* until radix tree lookup accepts end_index */
- if (page-index end)
+ if (unlikely(page-index end))
continue;
if (ino ino_of_node(page) == ino) {
--
Jaegeuk Kim
Samsung
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@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: [f2fs-dev] [PATCH] f2fs: refactor bio-related operations
Hi,
Some comments as following.
-Original Message-
From: Jaegeuk Kim [mailto:jaegeuk@samsung.com]
Sent: Saturday, November 30, 2013 2:26 PM
Cc: linux-fsde...@vger.kernel.org; linux-kernel@vger.kernel.org;
linux-f2fs-de...@lists.sourceforge.net
Subject: [f2fs-dev] [PATCH] f2fs: refactor bio-related operations
[snip]
+void f2fs_submit_page_mbio(struct f2fs_sb_info *sbi, struct page *page,
+ block_t blk_addr, enum page_type type, int rw)
+{
+ enum page_type btype = PAGE_TYPE_OF_BIO(type);
+ struct block_device *bdev = sbi-sb-s_bdev;
+ struct f2fs_bio_info *io;
+ int bio_blocks;
+
+ io = is_read_io(rw) ? sbi-read_io : sbi-write_io[btype];
+
+ verify_block_addr(sbi, blk_addr);
+
+ mutex_lock(io-io_mutex);
+
+ if (!is_read_io(rw))
+ inc_page_count(sbi, F2FS_WRITEBACK);
+
+ if (io-bio io-last_block_in_bio != blk_addr - 1)
+ __submit_merged_bio(sbi, io, type, true, rw);
+alloc_new:
+ if (io-bio == NULL) {
+ bio_blocks = MAX_BIO_BLOCKS(max_hw_blocks(sbi));
+ io-bio = __bio_alloc(bdev, bio_blocks);
+ io-bio-bi_sector = SECTOR_FROM_BLOCK(sbi, blk_addr);
+ io-bio-bi_end_io = is_read_io(rw) ? f2fs_read_end_io :
+ f2fs_write_end_io;
+ /*
+ * The end_io will be assigned at the sumbission phase.
+ * Until then, let bio_add_page() merge consecutive IOs as much
+ * as possible.
+ */
+ }
+
+ if (bio_add_page(io-bio, page, PAGE_CACHE_SIZE, 0)
+ PAGE_CACHE_SIZE) {
+ __submit_merged_bio(sbi, io, type, true, rw);
+ io-bio = NULL;
We should remove the redundant code io-bio = NULL; here,
because __submit_merged_bio does the same job.
[snip]
/*
* data.c
*/
+void f2fs_submit_merged_bio(struct f2fs_sb_info *, enum page_type, bool,
int);
+int f2fs_submit_page_bio(struct f2fs_sb_info *, struct page *, block_t, int);
Redundant to the following code.
+void f2fs_submit_page_mbio(struct f2fs_sb_info *, struct page *, block_t,
+ enum page_type, int);
int reserve_new_block(struct dnode_of_data *);
int f2fs_reserve_block(struct dnode_of_data *, pgoff_t);
void update_extent_cache(block_t, struct dnode_of_data *);
struct page *find_data_page(struct inode *, pgoff_t, bool);
struct page *get_lock_data_page(struct inode *, pgoff_t);
struct page *get_new_data_page(struct inode *, struct page *, pgoff_t, bool);
-int f2fs_readpage(struct f2fs_sb_info *, struct page *, block_t, int);
-void f2fs_submit_read_bio(struct f2fs_sb_info *, int);
-void submit_read_page(struct f2fs_sb_info *, struct page *, block_t, int);
+int f2fs_submit_page_bio(struct f2fs_sb_info *, struct page *, block_t, int);
Here.
[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: [PATCH/v3] [trivial] doc: Fix typo in Documentation/devicetree
On 11/30/13 06:59, Masanari Iida wrote: Correct spelling typo in Documentation/devicetree Signed-off-by: Masanari Iida standby2...@gmail.com Reviewed-By: Levente Kurusa le...@linux.com Has Levente replied to this patch with his Reviewed-by: tag? You should not add it just because he has reviewed the patch. It is up to him to send his Reviewed-by: comment explicitly. --- Documentation/devicetree/bindings/arm/omap/timer.txt| 2 +- Documentation/devicetree/bindings/bus/mvebu-mbus.txt| 2 +- Documentation/devicetree/bindings/crypto/fsl-sec6.txt | 2 +- Documentation/devicetree/bindings/gpio/mrvl-gpio.txt| 2 +- Documentation/devicetree/bindings/mfd/s2mps11.txt | 2 +- Documentation/devicetree/bindings/mmc/samsung-sdhci.txt | 2 +- Documentation/devicetree/bindings/mmc/synopsys-dw-mshc.txt | 4 ++-- Documentation/devicetree/bindings/phy/phy-bindings.txt | 2 +- Documentation/devicetree/bindings/spi/spi-bus.txt | 2 +- Documentation/devicetree/bindings/timer/lsi,zevio-timer.txt | 2 +- Documentation/devicetree/bindings/video/atmel,lcdc.txt | 4 ++-- 11 files changed, 13 insertions(+), 13 deletions(-) -- ~Randy -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: [PATCH 2/3 v3] usb: chipidea: Fix Internal error: : 808 [#1] ARM related to STS flag
If you have a look into the function hw_write() you will see that there
is no
effect if hw_write(...,sts) is called with sts=0/1, because the mask will
cut
off all bits beside BIT(29).
Yes, it is my careless. I thought sts is PORTCS_STS.
I used BIT(29) rather then PORTCS_STS to make it more clear what going on.
It is not a good coding style, you do need use MACRO to instead of raw number
directly.
A write to PORTCS will always be 0 for the STS Register no matter if
sts is 1
or 0 within Patch v2. Patch v3 will take care of the registers bit
position and
set 1 or 0 to PORTCS_STS.
My suggestion like below:
if (ci-hw_bank.lpm) {
hw_write(ci, OP_DEVLC, DEVLC_PTS(7) | DEVLC_PTW, lpm);
- hw_write(ci, OP_DEVLC, DEVLC_STS, sts);
+ if (sts)
+ hw_write(ci, OP_DEVLC, DEVLC_STS, DEVLC_STS);
} else {
hw_write(ci, OP_PORTSC, PORTSC_PTS(7) | PORTSC_PTW, portsc);
- hw_write(ci, OP_PORTSC, PORTSC_STS, sts);
+ if (sts)
+ hw_write(ci, OP_PORTSC, PORTSC_STS, PORTSC_STS);
}
I think we just need to fix the original bug, and do not add any new fixes
since we don't know which one is correct for every platform. My proposal is
just set PORTSC_STS (DEVLC_STS is lpm) if it is serial PHY. For any other PHYS,
just keep
the reset value.
Peter
I used the imx27 reference manual Capital 30.8.1.5.12 PORTSCx.
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@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 v10 1/3] aerdrv: Trace Event for AER
On 1/17/13, Lance Ortiz lance.or...@hp.com wrote:
This header file will define a new trace event that will be triggered when
a AER event occurs. The following data will be provided to the trace
event.
char * dev_name - The name of the slot where the device resides
([domain:]bus:device.function).
u32 status - Either the correctable or uncorrectable register
indicating what error or errors have been see.
u8 severity - error severity 0:NONFATAL 1:FATAL 2:CORRECTED
The trace event will also provide a trace string that may look like:
:05:00.0 PCIe Bus Error:severity=Uncorrected (Non-Fatal), Poisoned
TLP
v1-v2 Move header from include/ras/aer_event.h to
include/trace/events/ras.h
v3-v4 Cleaned up comments and commit header
v4-v5 More cleanup remove () from if statement in print.
Renamed string define to be more specific.
v5-v6 change TRACE_SYSTEM define to be ras and not aer.
Signed-off-by: Lance Ortiz lance.or...@hp.com
Acked-by: Mauro Carvalho Chehab mche...@redhat.com
Acked-by: Tony Luck tony.l...@intel.com
---
include/trace/events/ras.h | 77
1 files changed, 77 insertions(+), 0 deletions(-)
create mode 100644 include/trace/events/ras.h
diff --git a/include/trace/events/ras.h b/include/trace/events/ras.h
new file mode 100644
index 000..88b8783
--- /dev/null
+++ b/include/trace/events/ras.h
@@ -0,0 +1,77 @@
+#undef TRACE_SYSTEM
+#define TRACE_SYSTEM ras
+
+#if !defined(_TRACE_AER_H) || defined(TRACE_HEADER_MULTI_READ)
+#define _TRACE_AER_H
+
+#include linux/tracepoint.h
+#include linux/edac.h
+
+
+/*
+ * PCIe AER Trace event
+ *
+ * These events are generated when hardware detects a corrected or
+ * uncorrected event on a PCIe device. The event report has
+ * the following structure:
+ *
+ * char * dev_name - The name of the slot where the device resides
+ * ([domain:]bus:device.function).
+ * u32 status - Either the correctable or uncorrectable register
+ * indicating what error or errors have been seen
+ * u8 severity - error severity 0:NONFATAL 1:FATAL 2:CORRECTED
+ */
+
+#define aer_correctable_errors \
+ {BIT(0),Receiver Error}, \
+ {BIT(6),Bad TLP}, \
+ {BIT(7),Bad DLLP},\
+ {BIT(8),RELAY_NUM Rollover}, \
+ {BIT(12), Replay Timer Timeout},\
+ {BIT(13), Advisory Non-Fatal}
+
+#define aer_uncorrectable_errors \
+ {BIT(4),Data Link Protocol}, \
+ {BIT(12), Poisoned TLP},\
+ {BIT(13), Flow Control Protocol}, \
+ {BIT(14), Completion Timeout}, \
+ {BIT(15), Completer Abort}, \
+ {BIT(16), Unexpected Completion}, \
+ {BIT(17), Receiver Overflow}, \
+ {BIT(18), Malformed TLP}, \
+ {BIT(19), ECRC},\
+ {BIT(20), Unsupported Request}
+
+TRACE_EVENT(aer_event,
+ TP_PROTO(const char *dev_name,
+ const u32 status,
+ const u8 severity),
+
+ TP_ARGS(dev_name, status, severity),
+
+ TP_STRUCT__entry(
+ __string( dev_name, dev_name)
+ __field(u32,status )
+ __field(u8, severity)
+ ),
+
+ TP_fast_assign(
+ __assign_str(dev_name, dev_name);
+ __entry-status = status;
+ __entry-severity = severity;
+ ),
+
+ TP_printk(%s PCIe Bus Error: severity=%s, %s\n,
+ __get_str(dev_name),
+ __entry-severity == HW_EVENT_ERR_CORRECTED ? Corrected :
+ __entry-severity == HW_EVENT_ERR_FATAL ?
+ Fatal : Uncorrected,
+ __entry-severity == HW_EVENT_ERR_CORRECTED ?
+ __print_flags(__entry-status, |, aer_correctable_errors) :
+ __print_flags(__entry-status, |, aer_uncorrectable_errors))
+);
This causes inconsistency between dmesg and the trace event output.
When dmesg says severity=Corrected, the trace event says
severity=Fatal. What happens is that HW_EVENT_ERR_CORRECTED is
defined in edac.h:
enum hw_event_mc_err_type {
HW_EVENT_ERR_CORRECTED,
HW_EVENT_ERR_UNCORRECTED,
HW_EVENT_ERR_FATAL,
HW_EVENT_ERR_INFO,
};
while aer_print_error() uses aer_error_severity_string[] defined as:
static const char *aer_error_severity_string[] = {
Uncorrected (Non-Fatal),
Uncorrected (Fatal),
Corrected
};
In this case dmesg is correct because info-severity is assigned in
aer_isr_one_error() using the definitions in include/linux/ras.h:
#define AER_NONFATAL
Re: [PATCH 2/3 v3] usb: chipidea: Fix Internal error: : 808 [#1] ARM related to STS flag
On Monday, December 02, 2013 01:10 PM, Peter Chen wrote:
If you have a look into the function hw_write() you will see that there
is no
effect if hw_write(...,sts) is called with sts=0/1, because the mask will
cut
off all bits beside BIT(29).
Yes, it is my careless. I thought sts is PORTCS_STS.
I used BIT(29) rather then PORTCS_STS to make it more clear what going on.
It is not a good coding style, you do need use MACRO to instead of raw number
directly.
A write to PORTCS will always be 0 for the STS Register no matter if
sts is 1
or 0 within Patch v2. Patch v3 will take care of the registers bit
position and
set 1 or 0 to PORTCS_STS.
My suggestion like below:
if (ci-hw_bank.lpm) {
hw_write(ci, OP_DEVLC, DEVLC_PTS(7) | DEVLC_PTW, lpm);
- hw_write(ci, OP_DEVLC, DEVLC_STS, sts);
+ if (sts)
+ hw_write(ci, OP_DEVLC, DEVLC_STS, DEVLC_STS);
} else {
hw_write(ci, OP_PORTSC, PORTSC_PTS(7) | PORTSC_PTW, portsc);
- hw_write(ci, OP_PORTSC, PORTSC_STS, sts);
+ if (sts)
+ hw_write(ci, OP_PORTSC, PORTSC_STS, PORTSC_STS);
}
I think we just need to fix the original bug, and do not add any new fixes
since we don't know which one is correct for every platform. My proposal is
just set PORTSC_STS (DEVLC_STS is lpm) if it is serial PHY. For any other PHYS,
just keep
the reset value.
Peter
I used the imx27 reference manual Capital 30.8.1.5.12 PORTSCx.
I can follow your arguments, ACK.
I prepare a patch set with this solution if not other people have better
ideas.
Chris
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Welding Electrode/Welding Wire/Sintered Flux
Dear Sir, Good day! We had dealing welding materials for many years . And supplied high quality different type Welding Electrode/Welding Wire/Sintered Flux to our old and new customers. Should any of the items be of interest to you, please let me know. We shall be glad to give you our lowest quotations upon receipt of your detailed requirements. Thanks, Iris Email: iris20111...@hotmail.com Skype:iris.song12
linux-next: Tree for Dec 2
Hi all, Changes since 20131129: The drm-intel tree gained a conflict against the drm-intel-fixes tree. The sound-asoc tree lost its build failure. The block tree gained conflicts against the f2fs tree. Non-merge commits (relative to Linus' tree): 2243 2091 files changed, 81369 insertions(+), 38624 deletions(-) I have created today's linux-next tree at git://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git (patches at http://www.kernel.org/pub/linux/kernel/next/ ). If you are tracking the linux-next tree using git, you should not use git pull to do so as that will try to merge the new linux-next release with the old one. You should use git fetch as mentioned in the FAQ on the wiki (see below). You can see which trees have been included by looking in the Next/Trees file in the source. There are also quilt-import.log and merge.log files in the Next directory. Between each merge, the tree was built with a ppc64_defconfig for powerpc and an allmodconfig for x86_64 and a multi_v7_defconfig for arm. After the final fixups (if any), it is also built with powerpc allnoconfig (32 and 64 bit), ppc44x_defconfig and allyesconfig (minus CONFIG_PROFILE_ALL_BRANCHES - this fails its final link) and i386, sparc, sparc64 and arm defconfig. These builds also have CONFIG_ENABLE_WARN_DEPRECATED, CONFIG_ENABLE_MUST_CHECK and CONFIG_DEBUG_INFO disabled when necessary. Below is a summary of the state of the merge. I am currently merging 210 trees (counting Linus' and 29 trees of patches pending for Linus' tree). Stats about the size of the tree over time can be seen at http://neuling.org/linux-next-size.html . Status of my local build tests will be at http://kisskb.ellerman.id.au/linux-next . If maintainers want to give advice about cross compilers/configs that work, we are always open to add more builds. Thanks to Randy Dunlap for doing many randconfig builds. And to Paul Gortmaker for triage and bug fixes. There is a wiki covering stuff to do with linux-next at http://linux.f-seidel.de/linux-next/pmwiki/ . Thanks to Frank Seidel. -- Cheers, Stephen Rothwells...@canb.auug.org.au $ git checkout master $ git reset --hard stable Merging origin/master (af91706d5dde ima: store address of template_fmt_copy in a pointer before calling strsep) Merging fixes/master (8ae516aa8b81 Merge tag 'trace-fixes-v3.13-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/rostedt/linux-trace) Merging kbuild-current/rc-fixes (19514fc665ff arm, kbuild: make make install not depend on vmlinux) Merging arc-current/for-curr (da990a4f2d5a ARC: [perf] Fix a few thinkos) Merging arm-current/fixes (11d4bb1bd067 ARM: 7907/1: lib: delay-loop: Add align directive to fix BogoMIPS calculation) Merging m68k-current/for-linus (77a42796786c m68k: Remove deprecated IRQF_DISABLED) Merging metag-fixes/fixes (3b2f64d00c46 Linux 3.11-rc2) Merging powerpc-merge/merge (721cb59e9d95 powerpc/windfarm: Fix XServe G5 fan control Makefile issue) Merging sparc/master (b4789b8e6be3 aacraid: prevent invalid pointer dereference) Merging net/master (99e872ae1eac virtio_net: Fixed a trivial typo (fitler -- filter)) Merging ipsec/master (dff345c5c85d be2net: call napi_disable() for all event queues) Merging sound-current/for-linus (6ddf0fd1c462 ALSA: hda - Fix silent output on ASUS W7J laptop) Merging pci-current/for-linus (4bff6749905d PCI: Move device_del() from pci_stop_dev() to pci_destroy_dev()) Merging wireless/master (d5aedd7e1b2f Merge branch 'for-john' of git://git.kernel.org/pub/scm/linux/kernel/git/jberg/mac80211) Merging driver-core.current/driver-core-linus (dc1ccc48159d Linux 3.13-rc2) Merging tty.current/tty-linus (39434abd942c n_tty: Fix missing newline echo) Merging usb.current/usb-linus (c24cb6c8b501 Merge tag 'fixes-for-v3.13-rc2' of git://git.kernel.org/pub/scm/linux/kernel/git/balbi/usb into usb-linus) Merging staging.current/staging-linus (930ba4a374b9 Staging: tidspbridge: disable driver) Merging char-misc.current/char-misc-linus (d0b00d3fb96d Merge tag 'extcon-linus-for-3.13-rc2' of git://git.kernel.org/pub/scm/linux/kernel/git/chanwoo/extcon into char-misc-linus) Merging input-current/for-linus (358f24704f2f Input: add key code for ambient light sensor button) Merging md-current/for-linus (d47648fcf061 raid5: avoid finding discard stripe) Merging crypto-current/master (8ec25c512916 crypto: testmgr - fix sglen in test_aead for case 'dst != src') Merging ide/master (c2f7d1e103ef ide: pmac: remove unnecessary pci_set_drvdata()) Merging dwmw2/master (5950f0803ca9 pcmcia: remove RPX board stuff) Merging sh-current/sh-fixes-for-linus (44033109e99c SH: Convert out[bwl] macros to inline functions) Merging devicetree-current/devicetree/merge (1931ee143b0a Revert drivers: of: add initialization code for dma reserved memory) Merging rr-fixes/fixes (f6537f2f0eba scripts/kallsyms: filter symbols not in kernel address
[PATCH V2 1/5] cpufreq: Introduce cpufreq_notify_post_transition()
This introduces another routine cpufreq_notify_post_transition() which can be
used to send POSTCHANGE notification for new freq with or without both
{PRE|POST}CHANGE notifications for last freq. This is useful at multiple places,
specially for sending transition failure notifications.
Signed-off-by: Viresh Kumar viresh.ku...@linaro.org
---
V1-V2:
- Not required to push it for 3.13 anymore and can go in 3.14.
- Rebased over following patchset as there were conflicts in unicore2 driver if
following patchset is applied first (which should be the case):
https://lkml.org/lkml/2013/10/30/553 (create cpufreq_generic_get() routine)
drivers/cpufreq/cpufreq.c | 14 ++
include/linux/cpufreq.h | 2 ++
2 files changed, 16 insertions(+)
diff --git a/drivers/cpufreq/cpufreq.c b/drivers/cpufreq/cpufreq.c
index 5e27def..3b877d4 100644
--- a/drivers/cpufreq/cpufreq.c
+++ b/drivers/cpufreq/cpufreq.c
@@ -338,6 +338,20 @@ void cpufreq_notify_transition(struct cpufreq_policy
*policy,
}
EXPORT_SYMBOL_GPL(cpufreq_notify_transition);
+/* Do post notifications when there are chances that transition has failed */
+void cpufreq_notify_post_transition(struct cpufreq_policy *policy,
+ struct cpufreq_freqs *freqs, int transition_failed)
+{
+ cpufreq_notify_transition(policy, freqs, CPUFREQ_POSTCHANGE);
+ if (!transition_failed)
+ return;
+
+ swap(freqs-old, freqs-new);
+ cpufreq_notify_transition(policy, freqs, CPUFREQ_PRECHANGE);
+ cpufreq_notify_transition(policy, freqs, CPUFREQ_POSTCHANGE);
+}
+EXPORT_SYMBOL_GPL(cpufreq_notify_post_transition);
+
/*
* SYSFS INTERFACE *
diff --git a/include/linux/cpufreq.h b/include/linux/cpufreq.h
index 276e646..b26bfab 100644
--- a/include/linux/cpufreq.h
+++ b/include/linux/cpufreq.h
@@ -316,6 +316,8 @@ int cpufreq_unregister_notifier(struct notifier_block *nb,
unsigned int list);
void cpufreq_notify_transition(struct cpufreq_policy *policy,
struct cpufreq_freqs *freqs, unsigned int state);
+void cpufreq_notify_post_transition(struct cpufreq_policy *policy,
+ struct cpufreq_freqs *freqs, int transition_failed);
#else /* CONFIG_CPU_FREQ */
static inline int cpufreq_register_notifier(struct notifier_block *nb,
--
1.7.12.rc2.18.g61b472e
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH V2 5/5] cpufreq: unicore2: send new set of notification for transition failures
In the current code, if we fail during a frequency transition we simply send the
POSTCHANGE notification with old frequency. This isn't enough.
One of the core user of these notifications is the code responsible for keeping
loops_per_jiffy aligned with frequency change. And mostly it is written as:
if ((val == CPUFREQ_PRECHANGE freq-old freq-new) ||
(val == CPUFREQ_POSTCHANGE freq-old freq-new)) {
update-loops-per-jiffy...
}
So, suppose we are changing to a higher frequency and failed during transition,
then following will happen:
- CPUFREQ_PRECHANGE notification with freq-new freq-old
- CPUFREQ_POSTCHANGE notification with freq-new == freq-old
The first one will update loops_per_jiffy and second one will do nothing. Even
if we send the 2nd notification by exchanging values of freq-new and old, some
users of these notifications might get unstable.
This can be fixed by simply calling cpufreq_notify_post_transition() with error
code and this routine will take care of sending notifications in correct order.
Also it returns a proper error message in case frequency transition failed.
Signed-off-by: Viresh Kumar viresh.ku...@linaro.org
---
drivers/cpufreq/unicore2-cpufreq.c | 16 +++-
1 file changed, 7 insertions(+), 9 deletions(-)
diff --git a/drivers/cpufreq/unicore2-cpufreq.c
b/drivers/cpufreq/unicore2-cpufreq.c
index 951152f..99d280d6 100644
--- a/drivers/cpufreq/unicore2-cpufreq.c
+++ b/drivers/cpufreq/unicore2-cpufreq.c
@@ -38,19 +38,17 @@ static int ucv2_target(struct cpufreq_policy *policy,
unsigned int target_freq,
unsigned int relation)
{
- unsigned int cur = policy-cur;
struct cpufreq_freqs freqs;
+ int ret;
- cpufreq_notify_transition(policy, freqs, CPUFREQ_PRECHANGE);
-
- if (!clk_set_rate(policy-clk, target_freq * 1000)) {
- freqs.old = cur;
- freqs.new = target_freq;
- }
+ freqs.old = policy-cur;
+ freqs.new = target_freq;
- cpufreq_notify_transition(policy, freqs, CPUFREQ_POSTCHANGE);
+ cpufreq_notify_transition(policy, freqs, CPUFREQ_PRECHANGE);
+ ret = clk_set_rate(policy-clk, target_freq * 1000);
+ cpufreq_notify_post_transition(policy, freqs, ret);
- return 0;
+ return ret;
}
static int __init ucv2_cpu_init(struct cpufreq_policy *policy)
--
1.7.12.rc2.18.g61b472e
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH V2 4/5] cpufreq: powernow-k8: send new set of notification for transition failures
In the current code, if we fail during a frequency transition we simply send the
POSTCHANGE notification with old frequency. This isn't enough.
One of the core user of these notifications is the code responsible for keeping
loops_per_jiffy aligned with frequency change. And mostly it is written as:
if ((val == CPUFREQ_PRECHANGE freq-old freq-new) ||
(val == CPUFREQ_POSTCHANGE freq-old freq-new)) {
update-loops-per-jiffy...
}
So, suppose we are changing to a higher frequency and failed during transition,
then following will happen:
- CPUFREQ_PRECHANGE notification with freq-new freq-old
- CPUFREQ_POSTCHANGE notification with freq-new == freq-old
The first one will update loops_per_jiffy and second one will do nothing. Even
if we send the 2nd notification by exchanging values of freq-new and old, some
users of these notifications might get unstable.
This can be fixed by simply calling cpufreq_notify_post_transition() with error
code and this routine will take care of sending notifications in correct order.
Signed-off-by: Viresh Kumar viresh.ku...@linaro.org
---
drivers/cpufreq/powernow-k8.c | 7 +--
1 file changed, 1 insertion(+), 6 deletions(-)
diff --git a/drivers/cpufreq/powernow-k8.c b/drivers/cpufreq/powernow-k8.c
index 0023c7d..e10b646 100644
--- a/drivers/cpufreq/powernow-k8.c
+++ b/drivers/cpufreq/powernow-k8.c
@@ -964,14 +964,9 @@ static int transition_frequency_fidvid(struct
powernow_k8_data *data,
cpufreq_cpu_put(policy);
cpufreq_notify_transition(policy, freqs, CPUFREQ_PRECHANGE);
-
res = transition_fid_vid(data, fid, vid);
- if (res)
- freqs.new = freqs.old;
- else
- freqs.new = find_khz_freq_from_fid(data-currfid);
+ cpufreq_notify_post_transition(policy, freqs, res);
- cpufreq_notify_transition(policy, freqs, CPUFREQ_POSTCHANGE);
return res;
}
--
1.7.12.rc2.18.g61b472e
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH V2 3/5] cpufreq: pcc: send new set of notification for transition failures
In the current code, if we fail during a frequency transition we simply send the
POSTCHANGE notification with old frequency. This isn't enough.
One of the core user of these notifications is the code responsible for keeping
loops_per_jiffy aligned with frequency change. And mostly it is written as:
if ((val == CPUFREQ_PRECHANGE freq-old freq-new) ||
(val == CPUFREQ_POSTCHANGE freq-old freq-new)) {
update-loops-per-jiffy...
}
So, suppose we are changing to a higher frequency and failed during transition,
then following will happen:
- CPUFREQ_PRECHANGE notification with freq-new freq-old
- CPUFREQ_POSTCHANGE notification with freq-new == freq-old
The first one will update loops_per_jiffy and second one will do nothing. Even
if we send the 2nd notification by exchanging values of freq-new and old, some
users of these notifications might get unstable.
This can be fixed by simply calling cpufreq_notify_post_transition() with error
code and this routine will take care of sending notifications in correct order.
Also it fills freqs.old before starting the first notification, this was missing
since ever.
Signed-off-by: Viresh Kumar viresh.ku...@linaro.org
---
drivers/cpufreq/pcc-cpufreq.c | 18 +++---
1 file changed, 7 insertions(+), 11 deletions(-)
diff --git a/drivers/cpufreq/pcc-cpufreq.c b/drivers/cpufreq/pcc-cpufreq.c
index e2b4f40..1c0f106 100644
--- a/drivers/cpufreq/pcc-cpufreq.c
+++ b/drivers/cpufreq/pcc-cpufreq.c
@@ -213,6 +213,7 @@ static int pcc_cpufreq_target(struct cpufreq_policy *policy,
cpu, target_freq,
(pcch_virt_addr + pcc_cpu_data-input_offset));
+ freqs.old = policy-cur;
freqs.new = target_freq;
cpufreq_notify_transition(policy, freqs, CPUFREQ_PRECHANGE);
@@ -228,25 +229,20 @@ static int pcc_cpufreq_target(struct cpufreq_policy
*policy,
memset_io((pcch_virt_addr + pcc_cpu_data-input_offset), 0, BUF_SZ);
status = ioread16(pcch_hdr-status);
+ iowrite16(0, pcch_hdr-status);
+
+ cpufreq_notify_post_transition(policy, freqs, status != CMD_COMPLETE);
+ spin_unlock(pcc_lock);
+
if (status != CMD_COMPLETE) {
pr_debug(target: FAILED for cpu %d, with status: 0x%x\n,
cpu, status);
- goto cmd_incomplete;
+ return -EINVAL;
}
- iowrite16(0, pcch_hdr-status);
- cpufreq_notify_transition(policy, freqs, CPUFREQ_POSTCHANGE);
pr_debug(target: was SUCCESSFUL for cpu %d\n, cpu);
- spin_unlock(pcc_lock);
return 0;
-
-cmd_incomplete:
- freqs.new = freqs.old;
- cpufreq_notify_transition(policy, freqs, CPUFREQ_POSTCHANGE);
- iowrite16(0, pcch_hdr-status);
- spin_unlock(pcc_lock);
- return -EINVAL;
}
static int pcc_get_offset(int cpu)
--
1.7.12.rc2.18.g61b472e
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH V2 2/5] cpufreq: send new set of notification for transition failures
In the current code, if we fail during a frequency transition we simply send the
POSTCHANGE notification with old frequency. This isn't enough.
One of the core user of these notifications is the code responsible for keeping
loops_per_jiffy aligned with frequency change. And mostly it is written as:
if ((val == CPUFREQ_PRECHANGE freq-old freq-new) ||
(val == CPUFREQ_POSTCHANGE freq-old freq-new)) {
update-loops-per-jiffy...
}
So, suppose we are changing to a higher frequency and failed during transition,
then following will happen:
- CPUFREQ_PRECHANGE notification with freq-new freq-old
- CPUFREQ_POSTCHANGE notification with freq-new == freq-old
The first one will update loops_per_jiffy and second one will do nothing. Even
if we send the 2nd notification by exchanging values of freq-new and old, some
users of these notifications might get unstable.
This can be fixed by simply calling cpufreq_notify_post_transition() with error
code and this routine will take care of sending notifications in correct order.
Signed-off-by: Viresh Kumar viresh.ku...@linaro.org
---
drivers/cpufreq/cpufreq.c | 13 ++---
1 file changed, 2 insertions(+), 11 deletions(-)
diff --git a/drivers/cpufreq/cpufreq.c b/drivers/cpufreq/cpufreq.c
index 3b877d4..a7fcb84 100644
--- a/drivers/cpufreq/cpufreq.c
+++ b/drivers/cpufreq/cpufreq.c
@@ -1815,17 +1815,8 @@ int __cpufreq_driver_target(struct cpufreq_policy
*policy,
pr_err(%s: Failed to change cpu frequency: %d\n,
__func__, retval);
- if (notify) {
- /*
-* Notify with old freq in case we failed to change
-* frequency
-*/
- if (retval)
- freqs.new = freqs.old;
-
- cpufreq_notify_transition(policy, freqs,
- CPUFREQ_POSTCHANGE);
- }
+ if (notify)
+ cpufreq_notify_post_transition(policy, freqs, retval);
}
out:
--
1.7.12.rc2.18.g61b472e
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/5] serial: 8250_pci: use DEFINE_PCI_DEVICE_TABLE macro
(Adding Jonas Bonn to list as he added the macro in the first place...)
On Mon, 2013-12-02 at 13:03 +0900, Jingoo Han wrote:
On Monday, December 02, 2013 12:56 PM, Guenter Roeck wrote:
On 12/01/2013 07:50 PM, Jingoo Han wrote:
On Monday, December 02, 2013 12:46 PM, Guenter Roeck wrote:
On 12/01/2013 04:07 PM, Jingoo Han wrote:
On Friday, November 29, 2013 10:34 AM, Jingoo Han wrote:
On Thursday, November 28, 2013 3:24 PM, Joe Perches wrote:
On Wed, 2013-11-27 at 21:53 -0800, 'Greg Kroah-Hartman' wrote:
On Wed, Nov 27, 2013 at 09:40:13PM -0800, Joe Perches wrote:
On Thu, 2013-11-28 at 14:29 +0900, Jingoo Han wrote:
On Thursday, November 28, 2013 1:08 PM, Greg Kroah-Hartman wrote:
On Thu, Nov 28, 2013 at 10:55:35AM +0900, Jingoo Han wrote:
This macro is used to create a struct pci_device_id array.
Yeah, and it's a horrid macro that deserves to be removed, please
don't
use it in more places.
Actually, if you could just remove it, that would be best, sorry,
I'm
not going to take these patches.
(+cc Joe Perches, Andrew Morton, Andy Whitcroft)
Hi Joe Perches,
Would you fix checkpatch.pl about DEFINE_PCI_DEVICE_TABLE?
Currently, checkpatch.pl guides to use DEFINE_PCI_DEVICE_TABLE
as below.
WARNING: Use DEFINE_PCI_DEVICE_TABLE for struct pci_device_id
#331: FILE: drivers/usb/host/ehci-pci.c:331:
+static const struct pci_device_id pci_ids [] = { {
However, Greg Kroah-Hartman mentioned that DEFINE_PCI_DEVICE_TABLE
shouldn't be used anymore.
So, would you change checkpatch.pl in order to guide to use
struct pci_device_id instead of DEFINE_PCI_DEVICE_TABLE?
For example,
WARNING: Use struct pci_device_id instead of
DEFINE_PCI_DEVICE_TABLE
The documentation doesn't agree with Greg.
[]
I say just remove it, I should have done that years ago when I was
the
PCI maintainer, just never got around to it. No other bus has
something
like this for their device ids, why should PCI be special?
Anyone else have an opinion?
I don't care one way or another, but please, one way
not two.
Same here.
(+cc Bjorn Helgaas, linux-pci)
Then, how about the following steps?
1. Fix ./Documentation/PCI/pci.txt as below.
(Jingoo Han)
The ID table is an array of struct pci_device_id entries ending
with an
-all-zero entry; use of the macro DEFINE_PCI_DEVICE_TABLE is the
preferred
-method of declaring the table. Each entry consists of:
+all-zero entry; Each entry consists of:
2. Fix ./scripts/checkpatch.pl in order to guide to use
struct pci_device_id instead of DEFINE_PCI_DEVICE_TABLE.
(Joe Perches)
If all DEFINE_PCI_DEVICE_TABLEs are replaced with 'const struct
pci_device_id'
and these patches are merged through 'driver-core.git', it will be not
necessary to fix ./scripts/checkpatch.pl.
Why not ?
I will replace all DEFINE_PCI_DEVICE_TABLEs with 'const struct
pci_device_id',
and remove the definition of DEFINE_PCI_DEVICE_TABLE macro.
--- a/include/linux/pci.h
+++ b/include/linux/pci.h
@@ -631,16 +631,6 @@ struct pci_driver {
#defineto_pci_driver(drv) container_of(drv, struct pci_driver,
driver)
/**
- * DEFINE_PCI_DEVICE_TABLE - macro used to describe a pci device table
- * @_table: device table name
- *
- * This macro is used to create a struct pci_device_id array (a device
table)
- * in a generic manner.
- */
-#define DEFINE_PCI_DEVICE_TABLE(_table) \
- const struct pci_device_id _table[]
-
-/**
In this case, there is no DEFINE_PCI_DEVICE_TABLE usage
in the kernel. If someone uses DEFINE_PCI_DEVICE_TABLE macro,
it will make build error.
And that will make the checkpatch warning go away ?
That seems to be very unlikely.
OK, I will ask Joe Perches to remove the following checkpatch
warning.
WARNING: Use DEFINE_PCI_DEVICE_TABLE for struct pci_device_id
Best regards,
Jingoo Han
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH V4 1/6] cpufreq: suspend governors from dpm_{suspend|resume}()
Recently support for suspending governors has been added in cpufreq and
callbacks are called from dpm_{suspend|resume}_noirq(). The problem here is that
most of the devices (i.e. devices with -suspend() callbacks) have already been
suspended by now and so if drivers want to change frequency before suspending,
then it might not be possible for many platforms (which depend on other
peripherals like i2c, regulators, etc).
So, we actually need to do this from dpm_{suspend|resume}() instead. This patch
does it.
Tested-by: Lan Tianyu tianyu@intel.com
Tested-by: Nishanth Menon n...@ti.com
Tested-by: Stephen Warren swar...@nvidia.com
Signed-off-by: Viresh Kumar viresh.ku...@linaro.org
---
drivers/base/power/main.c | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/drivers/base/power/main.c b/drivers/base/power/main.c
index e3219df..c9fbb9d 100644
--- a/drivers/base/power/main.c
+++ b/drivers/base/power/main.c
@@ -541,7 +541,6 @@ static void dpm_resume_noirq(pm_message_t state)
dpm_show_time(starttime, state, noirq);
resume_device_irqs();
cpuidle_resume();
- cpufreq_resume();
}
/**
@@ -791,6 +790,8 @@ void dpm_resume(pm_message_t state)
mutex_unlock(dpm_list_mtx);
async_synchronize_full();
dpm_show_time(starttime, state, NULL);
+
+ cpufreq_resume();
}
/**
@@ -957,7 +958,6 @@ static int dpm_suspend_noirq(pm_message_t state)
ktime_t starttime = ktime_get();
int error = 0;
- cpufreq_suspend();
cpuidle_pause();
suspend_device_irqs();
mutex_lock(dpm_list_mtx);
@@ -1262,6 +1262,8 @@ int dpm_suspend(pm_message_t state)
might_sleep();
+ cpufreq_suspend();
+
mutex_lock(dpm_list_mtx);
pm_transition = state;
async_error = 0;
--
1.7.12.rc2.18.g61b472e
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH V4 0/6] cpufreq: suspend early/resume late: dpm_{suspend|resume}()
This patchset moves cpufreq callbacks to dpm_{suspend|resume}() from
dpm_{suspend|resume}_noirq() for handling suspend/resume of cpufreq governors
and core. This is required for early suspend and late resume of governors as
there are drivers which want to change cpu frequency before suspending governors
and they want to do it before devices get suspended, as some of them might be
required to change frequency.
Following patch is already pushed for v3.13 as it was required for fixing some
bugs in there. And the remaining was decided to be pushed for v3.14.
commit 5a87182aa21d6d5d306840feab9321818dd3e2a3
Author: Viresh Kumar viresh.ku...@linaro.org
Date: Wed Nov 27 09:09:42 2013 +0530
cpufreq: suspend governors on system suspend/hibernate
This is already tested by few people and so incorporating their Tested-by as
well.
For: v3.14.
Viresh Kumar (6):
cpufreq: suspend governors from dpm_{suspend|resume}()
cpufreq: call driver's suspend/resume for each policy
cpufreq: Implement cpufreq_generic_suspend()
cpufreq: exynos: Use cpufreq_generic_suspend()
cpufreq: s5pv210: Use cpufreq_generic_suspend()
cpufreq: Tegra: Use cpufreq_generic_suspend()
drivers/base/power/main.c | 6 +-
drivers/cpufreq/cpufreq.c | 137 --
drivers/cpufreq/exynos-cpufreq.c | 96 ++
drivers/cpufreq/s5pv210-cpufreq.c | 49 +-
drivers/cpufreq/tegra-cpufreq.c | 46 ++---
include/linux/cpufreq.h | 3 +
6 files changed, 79 insertions(+), 258 deletions(-)
--
1.7.12.rc2.18.g61b472e
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH V4 5/6] cpufreq: s5pv210: Use cpufreq_generic_suspend()
Currently we have implemented PM notifiers to disable/enable -target() routines
functionality during suspend/resume.
Now we have support present in cpufreq core, lets use it.
Signed-off-by: Viresh Kumar viresh.ku...@linaro.org
---
drivers/cpufreq/s5pv210-cpufreq.c | 49 +++
1 file changed, 3 insertions(+), 46 deletions(-)
diff --git a/drivers/cpufreq/s5pv210-cpufreq.c
b/drivers/cpufreq/s5pv210-cpufreq.c
index da0e291..72e77eb 100644
--- a/drivers/cpufreq/s5pv210-cpufreq.c
+++ b/drivers/cpufreq/s5pv210-cpufreq.c
@@ -18,7 +18,6 @@
#include linux/cpufreq.h
#include linux/reboot.h
#include linux/regulator/consumer.h
-#include linux/suspend.h
#include mach/map.h
#include mach/regs-clock.h
@@ -435,18 +434,6 @@ exit:
return ret;
}
-#ifdef CONFIG_PM
-static int s5pv210_cpufreq_suspend(struct cpufreq_policy *policy)
-{
- return 0;
-}
-
-static int s5pv210_cpufreq_resume(struct cpufreq_policy *policy)
-{
- return 0;
-}
-#endif
-
static int check_mem_type(void __iomem *dmc_reg)
{
unsigned long val;
@@ -502,6 +489,7 @@ static int __init s5pv210_cpu_init(struct cpufreq_policy
*policy)
s5pv210_dram_conf[1].refresh = (__raw_readl(S5P_VA_DMC1 + 0x30) * 1000);
s5pv210_dram_conf[1].freq = clk_get_rate(dmc1_clk);
+ policy-suspend_freq = SLEEP_FREQ;
return cpufreq_generic_init(policy, s5pv210_freq_table, 4);
out_dmc1:
@@ -511,32 +499,6 @@ out_dmc0:
return ret;
}
-static int s5pv210_cpufreq_notifier_event(struct notifier_block *this,
- unsigned long event, void *ptr)
-{
- int ret;
-
- switch (event) {
- case PM_SUSPEND_PREPARE:
- ret = cpufreq_driver_target(cpufreq_cpu_get(0), SLEEP_FREQ, 0);
- if (ret 0)
- return NOTIFY_BAD;
-
- /* Disable updation of cpu frequency */
- no_cpufreq_access = true;
- return NOTIFY_OK;
- case PM_POST_RESTORE:
- case PM_POST_SUSPEND:
- /* Enable updation of cpu frequency */
- no_cpufreq_access = false;
- cpufreq_driver_target(cpufreq_cpu_get(0), SLEEP_FREQ, 0);
-
- return NOTIFY_OK;
- }
-
- return NOTIFY_DONE;
-}
-
static int s5pv210_cpufreq_reboot_notifier_event(struct notifier_block *this,
unsigned long event, void *ptr)
{
@@ -558,15 +520,11 @@ static struct cpufreq_driver s5pv210_driver = {
.init = s5pv210_cpu_init,
.name = s5pv210,
#ifdef CONFIG_PM
- .suspend= s5pv210_cpufreq_suspend,
- .resume = s5pv210_cpufreq_resume,
+ .suspend= cpufreq_generic_suspend,
+ .resume = cpufreq_generic_suspend, /* We need to set SLEEP FREQ
again */
#endif
};
-static struct notifier_block s5pv210_cpufreq_notifier = {
- .notifier_call = s5pv210_cpufreq_notifier_event,
-};
-
static struct notifier_block s5pv210_cpufreq_reboot_notifier = {
.notifier_call = s5pv210_cpufreq_reboot_notifier_event,
};
@@ -586,7 +544,6 @@ static int __init s5pv210_cpufreq_init(void)
return PTR_ERR(int_regulator);
}
- register_pm_notifier(s5pv210_cpufreq_notifier);
register_reboot_notifier(s5pv210_cpufreq_reboot_notifier);
return cpufreq_register_driver(s5pv210_driver);
--
1.7.12.rc2.18.g61b472e
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH V4 3/6] cpufreq: Implement cpufreq_generic_suspend()
Multiple platforms need to set CPU to a particular frequency before suspending
system. And so they need a common infrastructure which is provided by this
patch. Those platforms just need to initialize their -suspend() pointers with
the generic routine.
Tested-by: Stephen Warren swar...@nvidia.com
Signed-off-by: Viresh Kumar viresh.ku...@linaro.org
---
drivers/cpufreq/cpufreq.c | 25 +
include/linux/cpufreq.h | 3 +++
2 files changed, 28 insertions(+)
diff --git a/drivers/cpufreq/cpufreq.c b/drivers/cpufreq/cpufreq.c
index 443c053..ae4923e 100644
--- a/drivers/cpufreq/cpufreq.c
+++ b/drivers/cpufreq/cpufreq.c
@@ -1530,6 +1530,31 @@ static struct subsys_interface cpufreq_interface = {
.remove_dev = cpufreq_remove_dev,
};
+/*
+ * In case platform wants some specific frequency to be configured
+ * during suspend..
+ */
+int cpufreq_generic_suspend(struct cpufreq_policy *policy)
+{
+ int ret;
+
+ if (!policy-suspend_freq) {
+ pr_err(%s: suspend_freq can't be zero\n, __func__);
+ return -EINVAL;
+ }
+
+ pr_debug(%s: Setting suspend-freq: %u\n, __func__,
+ policy-suspend_freq);
+
+ ret = __cpufreq_driver_target(policy, policy-suspend_freq,
+ CPUFREQ_RELATION_H);
+ if (ret)
+ pr_err(%s: unable to set suspend-freq: %u. err: %d\n,
+ __func__, policy-suspend_freq, ret);
+
+ return ret;
+}
+
/**
* cpufreq_suspend() - Suspend CPUFreq governors
*
diff --git a/include/linux/cpufreq.h b/include/linux/cpufreq.h
index b26bfab..ce6f06f 100644
--- a/include/linux/cpufreq.h
+++ b/include/linux/cpufreq.h
@@ -74,6 +74,8 @@ struct cpufreq_policy {
unsigned intmax;/* in kHz */
unsigned intcur;/* in kHz, only needed if cpufreq
* governors are used */
+ unsigned intsuspend_freq; /* freq to set during suspend */
+
unsigned intpolicy; /* see above */
struct cpufreq_governor *governor; /* see below */
void*governor_data;
@@ -285,6 +287,7 @@ cpufreq_verify_within_cpu_limits(struct cpufreq_policy
*policy)
#ifdef CONFIG_CPU_FREQ
void cpufreq_suspend(void);
void cpufreq_resume(void);
+int cpufreq_generic_suspend(struct cpufreq_policy *policy);
#else
static inline void cpufreq_suspend(void) {}
static inline void cpufreq_resume(void) {}
--
1.7.12.rc2.18.g61b472e
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH V4 4/6] cpufreq: exynos: Use cpufreq_generic_suspend()
Currently we have implemented PM notifiers to disable/enable -target() routines
functionality during suspend/resume.
Now we have support present in cpufreq core, lets use it.
Signed-off-by: Viresh Kumar viresh.ku...@linaro.org
---
drivers/cpufreq/exynos-cpufreq.c | 96 +++-
1 file changed, 7 insertions(+), 89 deletions(-)
diff --git a/drivers/cpufreq/exynos-cpufreq.c b/drivers/cpufreq/exynos-cpufreq.c
index 0b3689c..ded4cf8 100644
--- a/drivers/cpufreq/exynos-cpufreq.c
+++ b/drivers/cpufreq/exynos-cpufreq.c
@@ -16,19 +16,14 @@
#include linux/slab.h
#include linux/regulator/consumer.h
#include linux/cpufreq.h
-#include linux/suspend.h
#include plat/cpu.h
#include exynos-cpufreq.h
static struct exynos_dvfs_info *exynos_info;
-
static struct regulator *arm_regulator;
-
static unsigned int locking_frequency;
-static bool frequency_locked;
-static DEFINE_MUTEX(cpufreq_lock);
static int exynos_cpufreq_get_index(unsigned int freq)
{
@@ -133,83 +128,13 @@ out:
static int exynos_target(struct cpufreq_policy *policy, unsigned int index)
{
- struct cpufreq_frequency_table *freq_table = exynos_info-freq_table;
- int ret = 0;
-
- mutex_lock(cpufreq_lock);
-
- if (frequency_locked)
- goto out;
-
- ret = exynos_cpufreq_scale(freq_table[index].frequency);
-
-out:
- mutex_unlock(cpufreq_lock);
-
- return ret;
-}
-
-#ifdef CONFIG_PM
-static int exynos_cpufreq_suspend(struct cpufreq_policy *policy)
-{
- return 0;
-}
-
-static int exynos_cpufreq_resume(struct cpufreq_policy *policy)
-{
- return 0;
-}
-#endif
-
-/**
- * exynos_cpufreq_pm_notifier - block CPUFREQ's activities in suspend-resume
- * context
- * @notifier
- * @pm_event
- * @v
- *
- * While frequency_locked == true, target() ignores every frequency but
- * locking_frequency. The locking_frequency value is the initial frequency,
- * which is set by the bootloader. In order to eliminate possible
- * inconsistency in clock values, we save and restore frequencies during
- * suspend and resume and block CPUFREQ activities. Note that the standard
- * suspend/resume cannot be used as they are too deep (syscore_ops) for
- * regulator actions.
- */
-static int exynos_cpufreq_pm_notifier(struct notifier_block *notifier,
- unsigned long pm_event, void *v)
-{
- int ret;
-
- switch (pm_event) {
- case PM_SUSPEND_PREPARE:
- mutex_lock(cpufreq_lock);
- frequency_locked = true;
- mutex_unlock(cpufreq_lock);
-
- ret = exynos_cpufreq_scale(locking_frequency);
- if (ret 0)
- return NOTIFY_BAD;
-
- break;
-
- case PM_POST_SUSPEND:
- mutex_lock(cpufreq_lock);
- frequency_locked = false;
- mutex_unlock(cpufreq_lock);
- break;
- }
-
- return NOTIFY_OK;
+ return exynos_cpufreq_scale(exynos_info-freq_table[index].frequency);
}
-static struct notifier_block exynos_cpufreq_nb = {
- .notifier_call = exynos_cpufreq_pm_notifier,
-};
-
static int exynos_cpufreq_cpu_init(struct cpufreq_policy *policy)
{
policy-clk = exynos_info-cpu_clk;
+ policy-suspend_freq = locking_frequency;
return cpufreq_generic_init(policy, exynos_info-freq_table, 10);
}
@@ -223,8 +148,7 @@ static struct cpufreq_driver exynos_driver = {
.name = exynos_cpufreq,
.attr = cpufreq_generic_attr,
#ifdef CONFIG_PM
- .suspend= exynos_cpufreq_suspend,
- .resume = exynos_cpufreq_resume,
+ .suspend= cpufreq_generic_suspend,
#endif
};
@@ -259,19 +183,13 @@ static int __init exynos_cpufreq_init(void)
goto err_vdd_arm;
}
+ /* Done here as we want to capture boot frequency */
locking_frequency = clk_get_rate(exynos_info-cpu_clk) / 1000;
- register_pm_notifier(exynos_cpufreq_nb);
-
- if (cpufreq_register_driver(exynos_driver)) {
- pr_err(%s: failed to register cpufreq driver\n, __func__);
- goto err_cpufreq;
- }
-
- return 0;
-err_cpufreq:
- unregister_pm_notifier(exynos_cpufreq_nb);
+ if (!cpufreq_register_driver(exynos_driver))
+ return 0;
+ pr_err(%s: failed to register cpufreq driver\n, __func__);
regulator_put(arm_regulator);
err_vdd_arm:
kfree(exynos_info);
--
1.7.12.rc2.18.g61b472e
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2/2] perf probe: Allow user to specify address within executable
(2013/12/02 9:07), David Ahern wrote: Allow user to specify an address within an executable. This is useful, for example, in probing local functions. If the function name begins with 0x then try to convert the supplied name to an address. If succuessful then treat the function name as the address within the executable to be probed. Hmm, IMHO, this kind of functionality is only good for debugging. In that case, you should use uprobe_events interface directly. I recommend you to try enabing dwarf support in user space. Perf probe is a user-friendly interface of dynamic events. Thank you, -- Masami HIRAMATSU IT Management Research Dept. Linux Technology Center Hitachi, Ltd., Yokohama Research Laboratory E-mail: masami.hiramatsu...@hitachi.com -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH V4 6/6] cpufreq: Tegra: Use cpufreq_generic_suspend()
Currently we have implemented PM notifiers to disable/enable -target() routines
functionality during suspend/resume.
Now we have support present in cpufreq core, lets use it.
Acked-and-tested-by: Stephen Warren swar...@nvidia.com
Signed-off-by: Viresh Kumar viresh.ku...@linaro.org
---
drivers/cpufreq/tegra-cpufreq.c | 46 +
1 file changed, 5 insertions(+), 41 deletions(-)
diff --git a/drivers/cpufreq/tegra-cpufreq.c b/drivers/cpufreq/tegra-cpufreq.c
index 360d1a7..9e4f0a2b 100644
--- a/drivers/cpufreq/tegra-cpufreq.c
+++ b/drivers/cpufreq/tegra-cpufreq.c
@@ -26,7 +26,6 @@
#include linux/err.h
#include linux/clk.h
#include linux/io.h
-#include linux/suspend.h
static struct cpufreq_frequency_table freq_table[] = {
{ .frequency = 216000 },
@@ -47,9 +46,6 @@ static struct clk *pll_x_clk;
static struct clk *pll_p_clk;
static struct clk *emc_clk;
-static DEFINE_MUTEX(tegra_cpu_lock);
-static bool is_suspended;
-
static int tegra_cpu_clk_set_rate(unsigned long rate)
{
int ret;
@@ -112,42 +108,9 @@ static int tegra_update_cpu_speed(struct cpufreq_policy
*policy,
static int tegra_target(struct cpufreq_policy *policy, unsigned int index)
{
- int ret = -EBUSY;
-
- mutex_lock(tegra_cpu_lock);
-
- if (!is_suspended)
- ret = tegra_update_cpu_speed(policy,
- freq_table[index].frequency);
-
- mutex_unlock(tegra_cpu_lock);
- return ret;
+ return tegra_update_cpu_speed(policy, freq_table[index].frequency);
}
-static int tegra_pm_notify(struct notifier_block *nb, unsigned long event,
- void *dummy)
-{
- mutex_lock(tegra_cpu_lock);
- if (event == PM_SUSPEND_PREPARE) {
- struct cpufreq_policy *policy = cpufreq_cpu_get(0);
- is_suspended = true;
- pr_info(Tegra cpufreq suspend: setting frequency to %d kHz\n,
- freq_table[0].frequency);
- if (clk_get_rate(cpu_clk) / 1000 != freq_table[0].frequency)
- tegra_update_cpu_speed(policy, freq_table[0].frequency);
- cpufreq_cpu_put(policy);
- } else if (event == PM_POST_SUSPEND) {
- is_suspended = false;
- }
- mutex_unlock(tegra_cpu_lock);
-
- return NOTIFY_OK;
-}
-
-static struct notifier_block tegra_cpu_pm_notifier = {
- .notifier_call = tegra_pm_notify,
-};
-
static int tegra_cpu_init(struct cpufreq_policy *policy)
{
int ret;
@@ -166,10 +129,8 @@ static int tegra_cpu_init(struct cpufreq_policy *policy)
return ret;
}
- if (policy-cpu == 0)
- register_pm_notifier(tegra_cpu_pm_notifier);
-
policy-clk = cpu_clk;
+ policy-suspend_freq = freq_table[0].frequency;
return 0;
}
@@ -189,6 +150,9 @@ static struct cpufreq_driver tegra_cpufreq_driver = {
.exit = tegra_cpu_exit,
.name = tegra,
.attr = cpufreq_generic_attr,
+#ifdef CONFIG_PM
+ .suspend= cpufreq_generic_suspend,
+#endif
};
static int __init tegra_cpufreq_init(void)
--
1.7.12.rc2.18.g61b472e
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH V4 2/6] cpufreq: call driver's suspend/resume for each policy
Earlier cpufreq suspend/resume callbacks into drivers were getting called only
for the boot CPU, as by the time callbacks were called non-boot CPUs were
already removed. Because we might still need driver specific actions on
suspend/resume, its better to use earlier infrastructure from the early
suspend/late resume calls.
In effect, we call suspend/resume for each policy. The resume part also takes
care of synchronising frequency for boot CPU, which might turn out be different
than what cpufreq core believes.
Hence, the earlier syscore infrastructure is getting removed now.
Tested-by: Lan Tianyu tianyu@intel.com
Tested-by: Nishanth Menon n...@ti.com
Tested-by: Stephen Warren swar...@nvidia.com
Signed-off-by: Viresh Kumar viresh.ku...@linaro.org
---
drivers/cpufreq/cpufreq.c | 112 +-
1 file changed, 32 insertions(+), 80 deletions(-)
diff --git a/drivers/cpufreq/cpufreq.c b/drivers/cpufreq/cpufreq.c
index a7fcb84..443c053 100644
--- a/drivers/cpufreq/cpufreq.c
+++ b/drivers/cpufreq/cpufreq.c
@@ -27,7 +27,6 @@
#include linux/mutex.h
#include linux/slab.h
#include linux/suspend.h
-#include linux/syscore_ops.h
#include linux/tick.h
#include trace/events/power.h
@@ -1531,6 +1530,14 @@ static struct subsys_interface cpufreq_interface = {
.remove_dev = cpufreq_remove_dev,
};
+/**
+ * cpufreq_suspend() - Suspend CPUFreq governors
+ *
+ * Called during system wide Suspend/Hibernate cycles for suspending governors
+ * as some platforms can't change frequency after this point in suspend cycle.
+ * Because some of the devices (like: i2c, regulators, etc) they use for
+ * changing frequency are suspended quickly after this point.
+ */
void cpufreq_suspend(void)
{
struct cpufreq_policy *policy;
@@ -1540,14 +1547,25 @@ void cpufreq_suspend(void)
pr_debug(%s: Suspending Governors\n, __func__);
- list_for_each_entry(policy, cpufreq_policy_list, policy_list)
+ list_for_each_entry(policy, cpufreq_policy_list, policy_list) {
if (__cpufreq_governor(policy, CPUFREQ_GOV_STOP))
pr_err(%s: Failed to stop governor for policy: %p\n,
__func__, policy);
+ else if (cpufreq_driver-suspend
+cpufreq_driver-suspend(policy))
+ pr_err(%s: Failed to suspend driver: %p\n, __func__,
+ policy);
+ }
cpufreq_suspended = true;
}
+/**
+ * cpufreq_resume() - Resume CPUFreq governors
+ *
+ * Called during system wide Suspend/Hibernate cycle for resuming governors
that
+ * are suspended with cpufreq_suspend().
+ */
void cpufreq_resume(void)
{
struct cpufreq_policy *policy;
@@ -1559,91 +1577,26 @@ void cpufreq_resume(void)
cpufreq_suspended = false;
- list_for_each_entry(policy, cpufreq_policy_list, policy_list)
+ list_for_each_entry(policy, cpufreq_policy_list, policy_list) {
if (__cpufreq_governor(policy, CPUFREQ_GOV_START)
|| __cpufreq_governor(policy, CPUFREQ_GOV_LIMITS))
pr_err(%s: Failed to start governor for policy: %p\n,
__func__, policy);
-}
-
-/**
- * cpufreq_bp_suspend - Prepare the boot CPU for system suspend.
- *
- * This function is only executed for the boot processor. The other CPUs
- * have been put offline by means of CPU hotplug.
- */
-static int cpufreq_bp_suspend(void)
-{
- int ret = 0;
-
- int cpu = smp_processor_id();
- struct cpufreq_policy *policy;
-
- pr_debug(suspending cpu %u\n, cpu);
-
- /* If there's no policy for the boot CPU, we have nothing to do. */
- policy = cpufreq_cpu_get(cpu);
- if (!policy)
- return 0;
-
- if (cpufreq_driver-suspend) {
- ret = cpufreq_driver-suspend(policy);
- if (ret)
- printk(KERN_ERR cpufreq: suspend failed in -suspend
- step on CPU %u\n, policy-cpu);
- }
-
- cpufreq_cpu_put(policy);
- return ret;
-}
-
-/**
- * cpufreq_bp_resume - Restore proper frequency handling of the boot CPU.
- *
- * 1.) resume CPUfreq hardware support (cpufreq_driver-resume())
- * 2.) schedule call cpufreq_update_policy() ASAP as interrupts are
- * restored. It will verify that the current freq is in sync with
- * what we believe it to be. This is a bit later than when it
- * should be, but nonethteless it's better than calling
- * cpufreq_driver-get() here which might re-enable interrupts...
- *
- * This function is only executed for the boot CPU. The other CPUs have not
- * been turned on yet.
- */
-static void cpufreq_bp_resume(void)
-{
- int ret = 0;
-
- int cpu = smp_processor_id();
- struct cpufreq_policy *policy;
-
- pr_debug(resuming cpu %u\n, cpu);
-
- /* If there's no
Re: [PATCH 1/2] perf probe: Improve error message when function not found
(2013/12/02 9:07), David Ahern wrote: When requesting a function from a userspace library the error message to the user is less than helpful. e.g., perf probe -x /lib64/libpthread-2.14.90.so -a 'lock_full=__pthread_mutex_lock_full' no symbols found in /lib64/libpthread-2.14.90.so, maybe install a debug package? Failed to load map. Error: Failed to add events. (-22) In this cae the symbol really does exist but is a local symbol which is filtered: nm /lib64/libpthread-2.14.90.so | grep __pthread_mutex_lock_full 5700 t __pthread_mutex_lock_full With this patch: perf probe -x /lib64/libpthread-2.14.90.so -a 'lock_full=__pthread_mutex_lock_full' no symbols found in /lib64/libpthread-2.14.90.so, maybe install a debug package? Failed to find function in /lib64/libpthread-2.14.90.so. Perhaps it is a local variable? Hmm, indeed current message is too less information, but your message looks wired. I think just showing Failed to find requested symbol in %s is enough. :) Thank you, -- Masami HIRAMATSU IT Management Research Dept. Linux Technology Center Hitachi, Ltd., Yokohama Research Laboratory E-mail: masami.hiramatsu...@hitachi.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 2/2] perf sched: Add documentation for timehist options
* David Ahern dsah...@gmail.com [2013-12-01 17:23:15]:
Add entry to perf-sched documentation for timehist command and its
options.
v2: Addressed comments by Namhyung
Signed-off-by: David Ahern dsah...@gmail.com
Cc: Ingo Molnar mi...@kernel.org
Cc: Frederic Weisbecker fweis...@gmail.com
Cc: Peter Zijlstra a.p.zijls...@chello.nl
Cc: Mike Galbraith efa...@gmx.de
Cc: Jiri Olsa jo...@redhat.com
Cc: Namhyung Kim namhy...@kernel.org
Cc: Stephane Eranian eran...@google.com
Cc: Pekka Enberg penb...@kernel.org
---
tools/perf/Documentation/perf-sched.txt | 61
-
1 file changed, 60 insertions(+), 1 deletion(-)
diff --git a/tools/perf/Documentation/perf-sched.txt
b/tools/perf/Documentation/perf-sched.txt
index 8ff4df956951..e7bb19fcdbff 100644
--- a/tools/perf/Documentation/perf-sched.txt
+++ b/tools/perf/Documentation/perf-sched.txt
@@ -8,7 +8,7 @@ perf-sched - Tool to trace/measure scheduler properties
(latencies)
SYNOPSIS
[verse]
-'perf sched' {record|latency|map|replay|script}
+'perf sched' {record|latency|map|replay|script|timehist}
DESCRIPTION
---
@@ -36,6 +36,11 @@ There are five variants of perf sched:
Nit: There are six variants now.
--
Thanks and Regards
Srikar Dronamraju
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@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] watchdog: mpc8xxx_wdt: MPC8xx is HW enabled
Dear Guenter, In message 529b9152.9090...@roeck-us.net you wrote: On 11/30/2013 07:45 AM, Christophe Leroy wrote: MPC8xx watchdog is enabled at startup by HW. If the bootloader disables it, it cannot be reenabled. Is that true for all variants of 8xx, especially for 823 ? I am a bit concerned about breaking compatibility with some chips ... assuming there was a reason for not setting this flag originally. This is correct, and applies for all variants of the MPC8xx, including the MPC823 / MPC823E. From the UM: The software watchdog timer can be disabled or its timeout period can be changed in the SYPCR. Once the SYPCR is written, it cannot be written again until a system reset. Actually this is the only correct behaviour. Any watchdog that can be disabled by software is not worth it's name, and unsuitable for any kind of aplications where security / reliability are required. Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de Ninety-Ninety Rule of Project Schedules: The first ninety percent of the task takes ninety percent of the time, and the last ten percent takes the other ninety percent. -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@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: [f2fs-dev] [PATCH] f2fs: remove the own bi_private allocation
Hi Kim,
-Original Message-
From: Jaegeuk Kim [mailto:jaegeuk@samsung.com]
Sent: Saturday, November 30, 2013 9:48 AM
Cc: linux-fsde...@vger.kernel.org; linux-kernel@vger.kernel.org;
linux-f2fs-de...@lists.sourceforge.net
Subject: [f2fs-dev] [PATCH] f2fs: remove the own bi_private allocation
Previously f2fs allocates its own bi_private data structure all the time even
though we don't use it. But, can we remove this bi_private allocation?
This patch removes such the additional bi_private allocation.
1. Retrieve f2fs_sb_info from its page-mapping-host-i_sb.
- This removes the usecases of bi_private in end_io.
2. Use bi_private only when we really need it.
- The bi_private is used only when the checkpoint procedure is conducted.
- When conducting the checkpoint, f2fs submits a META_FLUSH bio to wait its
bio
completion.
- Since we have no dependancies to remove bi_private now, let's just use
bi_private pointer as the completion pointer.
Signed-off-by: Jaegeuk Kim jaegeuk@samsung.com
---
fs/f2fs/segment.c | 43 ---
fs/f2fs/segment.h | 7 ---
2 files changed, 16 insertions(+), 34 deletions(-)
diff --git a/fs/f2fs/segment.c b/fs/f2fs/segment.c
index 0387863..0db4027 100644
--- a/fs/f2fs/segment.c
+++ b/fs/f2fs/segment.c
@@ -791,7 +791,7 @@ static void f2fs_end_io_write(struct bio *bio, int err)
{
const int uptodate = test_bit(BIO_UPTODATE, bio-bi_flags);
struct bio_vec *bvec = bio-bi_io_vec + bio-bi_vcnt - 1;
- struct bio_private *p = bio-bi_private;
+ struct f2fs_sb_info *sbi = F2FS_SB(bvec-bv_page-mapping-host-i_sb);
I'm not sure whether bvec-bv_page-mapping will be set to NULL in the flow
where may not check WRITEBACK flag of page. Is it possible?
do {
struct page *page = bvec-bv_page;
@@ -802,21 +802,21 @@ static void f2fs_end_io_write(struct bio *bio, int err)
SetPageError(page);
if (page-mapping)
set_bit(AS_EIO, page-mapping-flags);
- set_ckpt_flags(p-sbi-ckpt, CP_ERROR_FLAG);
- p-sbi-sb-s_flags |= MS_RDONLY;
+
+ set_ckpt_flags(sbi-ckpt, CP_ERROR_FLAG);
+ sbi-sb-s_flags |= MS_RDONLY;
}
end_page_writeback(page);
- dec_page_count(p-sbi, F2FS_WRITEBACK);
+ dec_page_count(sbi, F2FS_WRITEBACK);
} while (bvec = bio-bi_io_vec);
- if (p-is_sync)
- complete(p-wait);
+ if (bio-bi_private)
+ complete(bio-bi_private);
- if (!get_pages(p-sbi, F2FS_WRITEBACK)
- !list_empty(p-sbi-cp_wait.task_list))
- wake_up(p-sbi-cp_wait);
+ if (!get_pages(sbi, F2FS_WRITEBACK)
+ !list_empty(sbi-cp_wait.task_list))
+ wake_up(sbi-cp_wait);
- kfree(p);
bio_put(bio);
}
@@ -838,7 +838,6 @@ static void do_submit_bio(struct f2fs_sb_info *sbi,
int rw = sync ? WRITE_SYNC : WRITE;
enum page_type btype = PAGE_TYPE_OF_BIO(type);
struct f2fs_bio_info *io = sbi-write_io[btype];
- struct bio_private *p;
if (!io-bio)
return;
@@ -851,18 +850,16 @@ static void do_submit_bio(struct f2fs_sb_info *sbi,
trace_f2fs_submit_write_bio(sbi-sb, rw, btype, io-bio);
- p = io-bio-bi_private;
- p-sbi = sbi;
- io-bio-bi_end_io = f2fs_end_io_write;
-
+ /*
+ * META_FLUSH is only from the checkpoint procedure, and we should wait
+ * this metadata bio for FS consistency.
+ */
if (type == META_FLUSH) {
DECLARE_COMPLETION_ONSTACK(wait);
- p-is_sync = true;
- p-wait = wait;
+ io-bio-bi_private = wait;
submit_bio(rw, io-bio);
wait_for_completion(wait);
} else {
- p-is_sync = false;
submit_bio(rw, io-bio);
}
io-bio = NULL;
@@ -897,18 +894,10 @@ static void submit_write_page(struct f2fs_sb_info *sbi,
struct page *page,
do_submit_bio(sbi, type, false);
alloc_new:
if (io-bio == NULL) {
- struct bio_private *priv;
-retry:
- priv = kmalloc(sizeof(struct bio_private), GFP_NOFS);
- if (!priv) {
- cond_resched();
- goto retry;
- }
-
bio_blocks = MAX_BIO_BLOCKS(max_hw_blocks(sbi));
io-bio = f2fs_bio_alloc(bdev, bio_blocks);
io-bio-bi_sector = SECTOR_FROM_BLOCK(sbi, blk_addr);
- io-bio-bi_private = priv;
+ io-bio-bi_end_io = f2fs_end_io_write;
/*
* The end_io will be assigned at the sumbission phase.
* Until then, let bio_add_page() merge consecutive IOs as much
diff --git a/fs/f2fs/segment.h
