Re: [PATCH] make CONFIG_EXPERIMENTAL invisible and default
On Mon, Oct 8, 2012 at 7:47 PM, Stephen Rothwell s...@canb.auug.org.au wrote: Hi Kees, On Mon, 8 Oct 2012 18:57:51 -0700 Kees Cook keesc...@chromium.org wrote: On Mon, Oct 8, 2012 at 6:20 PM, Greg Kroah-Hartman gre...@linuxfoundation.org wrote: On Mon, Oct 08, 2012 at 05:46:08PM -0700, Kees Cook wrote: On Mon, Oct 8, 2012 at 4:53 PM, Greg Kroah-Hartman gre...@linuxfoundation.org wrote: On Mon, Oct 08, 2012 at 03:08:40PM -0700, Kees Cook wrote: Who is going to carry this initial patch, btw? You? :) Do you mean to say I should ask Stephen to pull from one of my trees for linux-next? If so, I've made this now: git://git.kernel.org/pub/scm/linux/kernel/git/kees/linux.git linux-next Sounds good to me, good luck. Stephen, can you add this tree to your pulls for linux-next? For this single commit, if you want it to go in during this merge window, I suggest you send it as a patch to Linus.If there is going to be ongoing work on this topic, then I will be happy to add your tree after v3.7-rc1 is released (since the further work should be destined for v3.8, right?). I'm intending it for 3.8, so waiting is fine. Thanks! -Kees -- Kees Cook Chrome OS Security -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
ACPI Thermal patches for Linux-3.7-merge
Here is my 3.7 queue of Thermal pathces (from Zhang-Rui's release tree) plus a few misc fixes. I fixed two merge issues when pulling rui's tree, the TC1/TC2 vs OMAP and the MAX_IDR_MASK rename issue. Please let me know if you see troubles with any of these patches, they are currently on my next branch. thanks, Len Brown, 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/
[PATCH 01/30] Thermal: Introduce multiple cooling states support
From: Zhang Rui rui.zh...@intel.com This is because general active cooling devices, like fans, may have multiple speeds, which can be mapped to different cooling states. Signed-off-by: Zhang Rui rui.zh...@intel.com Reviewed-by: Rafael J. Wysocki r...@sisk.pl Reviewed-by: Valentin, Eduardo eduardo.valen...@ti.com --- drivers/thermal/thermal_sys.c | 12 ++-- 1 file changed, 10 insertions(+), 2 deletions(-) diff --git a/drivers/thermal/thermal_sys.c b/drivers/thermal/thermal_sys.c index 2ab31e4..dc4044b 100644 --- a/drivers/thermal/thermal_sys.c +++ b/drivers/thermal/thermal_sys.c @@ -1059,6 +1059,7 @@ void thermal_zone_device_update(struct thermal_zone_device *tz) enum thermal_trip_type trip_type; struct thermal_cooling_device_instance *instance; struct thermal_cooling_device *cdev; + unsigned long cur_state, max_state; mutex_lock(tz-lock); @@ -1098,10 +1099,17 @@ void thermal_zone_device_update(struct thermal_zone_device *tz) cdev = instance-cdev; + cdev-ops-get_cur_state(cdev, cur_state); + cdev-ops-get_max_state(cdev, max_state); + if (temp = trip_temp) - cdev-ops-set_cur_state(cdev, 1); + cur_state = cur_state max_state ? + (cur_state + 1) : max_state; else - cdev-ops-set_cur_state(cdev, 0); + cur_state = cur_state 0 ? + (cur_state - 1) : 0; + + cdev-ops-set_cur_state(cdev, cur_state); } break; case THERMAL_TRIP_PASSIVE: -- 1.8.0.rc1 -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 05/30] Thermal: Remove tc1/tc2 in generic thermal layer.
From: Zhang Rui rui.zh...@intel.com
Remove tc1/tc2 in generic thermal layer.
.get_trend() callback starts to take effect from this patch.
Signed-off-by: Zhang Rui rui.zh...@intel.com
Reviewed-by: Rafael J. Wysocki r...@sisk.pl
Reviewed-by: Valentin, Eduardo eduardo.valen...@ti.com
---
drivers/acpi/thermal.c | 5 +
drivers/platform/x86/acerhdf.c | 2 +-
drivers/platform/x86/intel_mid_thermal.c | 2 +-
drivers/power/power_supply_core.c | 2 +-
drivers/staging/omap-thermal/omap-thermal-common.c | 2 +-
drivers/thermal/spear_thermal.c| 2 +-
drivers/thermal/thermal_sys.c | 24 ++
include/linux/thermal.h| 5 +
8 files changed, 13 insertions(+), 31 deletions(-)
diff --git a/drivers/acpi/thermal.c b/drivers/acpi/thermal.c
index bb95709..07cb217 100644
--- a/drivers/acpi/thermal.c
+++ b/drivers/acpi/thermal.c
@@ -897,15 +897,12 @@ static int acpi_thermal_register_thermal_zone(struct
acpi_thermal *tz)
tz-thermal_zone =
thermal_zone_device_register(acpitz, trips, 0, tz,
acpi_thermal_zone_ops,
-tz-trips.passive.tc1,
-tz-trips.passive.tc2,
tz-trips.passive.tsp*100,
tz-polling_frequency*100);
else
tz-thermal_zone =
thermal_zone_device_register(acpitz, trips, 0, tz,
-acpi_thermal_zone_ops,
-0, 0, 0,
+acpi_thermal_zone_ops, 0,
tz-polling_frequency*100);
if (IS_ERR(tz-thermal_zone))
return -ENODEV;
diff --git a/drivers/platform/x86/acerhdf.c b/drivers/platform/x86/acerhdf.c
index a207466..84c5688 100644
--- a/drivers/platform/x86/acerhdf.c
+++ b/drivers/platform/x86/acerhdf.c
@@ -662,7 +662,7 @@ static int acerhdf_register_thermal(void)
return -EINVAL;
thz_dev = thermal_zone_device_register(acerhdf, 1, 0, NULL,
- acerhdf_dev_ops, 0, 0, 0,
+ acerhdf_dev_ops, 0,
(kernelmode) ? interval*1000 : 0);
if (IS_ERR(thz_dev))
return -EINVAL;
diff --git a/drivers/platform/x86/intel_mid_thermal.c
b/drivers/platform/x86/intel_mid_thermal.c
index 3a27113..c809761 100644
--- a/drivers/platform/x86/intel_mid_thermal.c
+++ b/drivers/platform/x86/intel_mid_thermal.c
@@ -502,7 +502,7 @@ static int mid_thermal_probe(struct platform_device *pdev)
goto err;
}
pinfo-tzd[i] = thermal_zone_device_register(name[i],
- 0, 0, td_info, tzd_ops, 0, 0, 0, 0);
+ 0, 0, td_info, tzd_ops, 0, 0);
if (IS_ERR(pinfo-tzd[i])) {
kfree(td_info);
ret = PTR_ERR(pinfo-tzd[i]);
diff --git a/drivers/power/power_supply_core.c
b/drivers/power/power_supply_core.c
index 08cc8a3..2436f13 100644
--- a/drivers/power/power_supply_core.c
+++ b/drivers/power/power_supply_core.c
@@ -201,7 +201,7 @@ static int psy_register_thermal(struct power_supply *psy)
for (i = 0; i psy-num_properties; i++) {
if (psy-properties[i] == POWER_SUPPLY_PROP_TEMP) {
psy-tzd = thermal_zone_device_register(psy-name, 0, 0,
- psy, psy_tzd_ops, 0, 0, 0, 0);
+ psy, psy_tzd_ops, 0, 0);
if (IS_ERR(psy-tzd))
return PTR_ERR(psy-tzd);
break;
diff --git a/drivers/staging/omap-thermal/omap-thermal-common.c
b/drivers/staging/omap-thermal/omap-thermal-common.c
index 0675a5e..d543d5c 100644
--- a/drivers/staging/omap-thermal/omap-thermal-common.c
+++ b/drivers/staging/omap-thermal/omap-thermal-common.c
@@ -246,7 +246,7 @@ int omap_thermal_expose_sensor(struct omap_bandgap *bg_ptr,
int id,
/* Create thermal zone */
data-omap_thermal = thermal_zone_device_register(domain,
OMAP_TRIP_NUMBER, 0, data, omap_thermal_ops,
- 0, FAST_TEMP_MONITORING_RATE, 0, 0);
+ 0, FAST_TEMP_MONITORING_RATE);
if (IS_ERR_OR_NULL(data-omap_thermal)) {
dev_err(bg_ptr-dev, thermal zone device is NULL\n);
return PTR_ERR(data-omap_thermal);
diff --git a/drivers/thermal/spear_thermal.c
[PATCH 09/30] Thermal: Rename thermal_instance.node to thermal_instance.tz_node.
From: Zhang Rui rui.zh...@intel.com
thermal_instance should be referenced by both thermal zone devices
and thermal cooling devices.
Rename thermal_instance.node to thermal_instance.tz_node in this patch
and thermal_instanace.cdev_node will be introduced in next patch.
Signed-off-by: Zhang Rui rui.zh...@intel.com
Reviewed-by: Rafael J. Wysocki r...@sisk.pl
Reviewed-by: Eduardo Valentin eduardo.valen...@ti.com
---
drivers/thermal/thermal_sys.c | 20 ++--
1 file changed, 10 insertions(+), 10 deletions(-)
diff --git a/drivers/thermal/thermal_sys.c b/drivers/thermal/thermal_sys.c
index 797d148..2884376 100644
--- a/drivers/thermal/thermal_sys.c
+++ b/drivers/thermal/thermal_sys.c
@@ -56,7 +56,7 @@ struct thermal_instance {
unsigned long lower;/* Lowest cooling state for this trip point */
char attr_name[THERMAL_NAME_LENGTH];
struct device_attribute attr;
- struct list_head node;
+ struct list_head tz_node; /* node in tz-thermal_instances */
};
static DEFINE_IDR(thermal_tz_idr);
@@ -746,7 +746,7 @@ static void thermal_zone_device_passive(struct
thermal_zone_device *tz,
/* Heating up? */
if (trend == THERMAL_TREND_RAISING) {
list_for_each_entry(instance, tz-thermal_instances,
- node) {
+ tz_node) {
if (instance-trip != trip)
continue;
cdev = instance-cdev;
@@ -757,7 +757,7 @@ static void thermal_zone_device_passive(struct
thermal_zone_device *tz,
}
} else if (trend == THERMAL_TREND_DROPPING) { /* Cooling off? */
list_for_each_entry(instance, tz-thermal_instances,
- node) {
+ tz_node) {
if (instance-trip != trip)
continue;
cdev = instance-cdev;
@@ -777,7 +777,7 @@ static void thermal_zone_device_passive(struct
thermal_zone_device *tz,
* and avoid thrashing around the passive trip point. Note that we
* assume symmetry.
*/
- list_for_each_entry(instance, tz-thermal_instances, node) {
+ list_for_each_entry(instance, tz-thermal_instances, tz_node) {
if (instance-trip != trip)
continue;
cdev = instance-cdev;
@@ -873,13 +873,13 @@ int thermal_zone_bind_cooling_device(struct
thermal_zone_device *tz,
goto remove_symbol_link;
mutex_lock(tz-lock);
- list_for_each_entry(pos, tz-thermal_instances, node)
+ list_for_each_entry(pos, tz-thermal_instances, tz_node)
if (pos-tz == tz pos-trip == trip pos-cdev == cdev) {
result = -EEXIST;
break;
}
if (!result)
- list_add_tail(dev-node, tz-thermal_instances);
+ list_add_tail(dev-tz_node, tz-thermal_instances);
mutex_unlock(tz-lock);
if (!result)
@@ -912,9 +912,9 @@ int thermal_zone_unbind_cooling_device(struct
thermal_zone_device *tz,
struct thermal_instance *pos, *next;
mutex_lock(tz-lock);
- list_for_each_entry_safe(pos, next, tz-thermal_instances, node) {
+ list_for_each_entry_safe(pos, next, tz-thermal_instances, tz_node) {
if (pos-tz == tz pos-trip == trip pos-cdev == cdev) {
- list_del(pos-node);
+ list_del(pos-tz_node);
mutex_unlock(tz-lock);
goto unbind;
}
@@ -1117,7 +1117,7 @@ static void thermal_zone_trip_update(struct
thermal_zone_device *tz,
}
if (temp = trip_temp) {
- list_for_each_entry(instance, tz-thermal_instances, node) {
+ list_for_each_entry(instance, tz-thermal_instances, tz_node) {
if (instance-trip != trip)
continue;
@@ -1136,7 +1136,7 @@ static void thermal_zone_trip_update(struct
thermal_zone_device *tz,
cdev-ops-set_cur_state(cdev, cur_state);
}
} else {/* below trip */
- list_for_each_entry(instance, tz-thermal_instances, node) {
+ list_for_each_entry(instance, tz-thermal_instances, tz_node) {
if (instance-trip != trip)
continue;
--
1.8.0.rc1
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 11/30] Thermal: Introduce simple arbitrator for setting device cooling state
From: Zhang Rui rui.zh...@intel.com
This fixes the problem that a cooling device may be referenced by
by multiple trip points in multiple thermal zones.
With this patch, we have two stages for updating a thermal zone,
1. check if a thermal_instance needs to be updated or not
2. update the cooling device, based on the target cooling state
of all its instances.
Note that, currently, the cooling device is set to the deepest
cooling state required.
Signed-off-by: Zhang Rui rui.zh...@intel.com
Reviewed-by: Rafael J. Wysocki r...@sisk.pl
Reviewed-by: Eduardo Valentin eduardo.valen...@ti.com
---
drivers/thermal/thermal_sys.c | 44 ---
include/linux/thermal.h | 1 +
2 files changed, 42 insertions(+), 3 deletions(-)
diff --git a/drivers/thermal/thermal_sys.c b/drivers/thermal/thermal_sys.c
index 70045c1..36ae2f4 100644
--- a/drivers/thermal/thermal_sys.c
+++ b/drivers/thermal/thermal_sys.c
@@ -41,6 +41,7 @@ MODULE_AUTHOR(Zhang Rui);
MODULE_DESCRIPTION(Generic thermal management sysfs support);
MODULE_LICENSE(GPL);
+#define THERMAL_NO_TARGET -1UL
/*
* This structure is used to describe the behavior of
* a certain cooling device on a certain trip point
@@ -54,6 +55,7 @@ struct thermal_instance {
int trip;
unsigned long upper;/* Highest cooling state for this trip point */
unsigned long lower;/* Lowest cooling state for this trip point */
+ unsigned long target; /* expected cooling state */
char attr_name[THERMAL_NAME_LENGTH];
struct device_attribute attr;
struct list_head tz_node; /* node in tz-thermal_instances */
@@ -853,6 +855,7 @@ int thermal_zone_bind_cooling_device(struct
thermal_zone_device *tz,
dev-trip = trip;
dev-upper = upper;
dev-lower = lower;
+ dev-target = THERMAL_NO_TARGET;
result = get_idr(tz-idr, tz-lock, dev-id);
if (result)
@@ -990,6 +993,7 @@ thermal_cooling_device_register(char *type, void *devdata,
strcpy(cdev-type, type);
INIT_LIST_HEAD(cdev-thermal_instances);
cdev-ops = ops;
+ cdev-updated = true;
cdev-device.class = thermal_class;
cdev-devdata = devdata;
dev_set_name(cdev-device, cooling_device%d, cdev-id);
@@ -1081,6 +1085,34 @@ void thermal_cooling_device_unregister(struct
}
EXPORT_SYMBOL(thermal_cooling_device_unregister);
+static void thermal_cdev_do_update(struct thermal_cooling_device *cdev)
+{
+ struct thermal_instance *instance;
+ unsigned long target = 0;
+
+ /* cooling device is updated*/
+ if (cdev-updated)
+ return;
+
+ /* Make sure cdev enters the deepest cooling state */
+ list_for_each_entry(instance, cdev-thermal_instances, cdev_node) {
+ if (instance-target == THERMAL_NO_TARGET)
+ continue;
+ if (instance-target target)
+ target = instance-target;
+ }
+ cdev-ops-set_cur_state(cdev, target);
+ cdev-updated = true;
+}
+
+static void thermal_zone_do_update(struct thermal_zone_device *tz)
+{
+ struct thermal_instance *instance;
+
+ list_for_each_entry(instance, tz-thermal_instances, tz_node)
+ thermal_cdev_do_update(instance-cdev);
+}
+
/*
* Cooling algorithm for active trip points
*
@@ -1138,19 +1170,24 @@ static void thermal_zone_trip_update(struct
thermal_zone_device *tz,
cur_state = cur_state instance-lower ?
(cur_state - 1) : instance-lower;
}
- cdev-ops-set_cur_state(cdev, cur_state);
+ instance-target = cur_state;
+ cdev-updated = false; /* cooling device needs update */
}
} else {/* below trip */
list_for_each_entry(instance, tz-thermal_instances, tz_node) {
if (instance-trip != trip)
continue;
+ /* Do not use the inactive thermal instance */
+ if (instance-target == THERMAL_NO_TARGET)
+ continue;
cdev = instance-cdev;
cdev-ops-get_cur_state(cdev, cur_state);
cur_state = cur_state instance-lower ?
- (cur_state - 1) : instance-lower;
- cdev-ops-set_cur_state(cdev, cur_state);
+ (cur_state - 1) : THERMAL_NO_TARGET;
+ instance-target = cur_state;
+ cdev-updated = false; /* cooling device needs update */
}
}
@@ -1211,6 +1248,7 @@ void thermal_zone_device_update(struct
thermal_zone_device *tz)
}
}
+ thermal_zone_do_update(tz);
if (tz-forced_passive)
[PATCH 13/30] Thermal: Introduce locking for cdev.thermal_instances list.
From: Zhang Rui rui.zh...@intel.com
we need to go over all the thermal_instance list of a cooling device
to decide which cooling state to put the cooling device to.
But at this time, as a cooling device may be referenced in multiple
thermal zones, we need to lock the list first in case
another thermal zone is updating this cooling device.
Signed-off-by: Zhang Rui rui.zh...@intel.com
Reviewed-by: Rafael J. Wysocki r...@sisk.pl
Reviewed-by: Eduardo Valentin eduardo.valen...@ti.com
---
drivers/thermal/thermal_sys.c | 8
include/linux/thermal.h | 1 +
2 files changed, 9 insertions(+)
diff --git a/drivers/thermal/thermal_sys.c b/drivers/thermal/thermal_sys.c
index 6e9d3dc..5be8728 100644
--- a/drivers/thermal/thermal_sys.c
+++ b/drivers/thermal/thermal_sys.c
@@ -799,6 +799,7 @@ int thermal_zone_bind_cooling_device(struct
thermal_zone_device *tz,
goto remove_symbol_link;
mutex_lock(tz-lock);
+ mutex_lock(cdev-lock);
list_for_each_entry(pos, tz-thermal_instances, tz_node)
if (pos-tz == tz pos-trip == trip pos-cdev == cdev) {
result = -EEXIST;
@@ -808,6 +809,7 @@ int thermal_zone_bind_cooling_device(struct
thermal_zone_device *tz,
list_add_tail(dev-tz_node, tz-thermal_instances);
list_add_tail(dev-cdev_node, cdev-thermal_instances);
}
+ mutex_unlock(cdev-lock);
mutex_unlock(tz-lock);
if (!result)
@@ -840,14 +842,17 @@ int thermal_zone_unbind_cooling_device(struct
thermal_zone_device *tz,
struct thermal_instance *pos, *next;
mutex_lock(tz-lock);
+ mutex_lock(cdev-lock);
list_for_each_entry_safe(pos, next, tz-thermal_instances, tz_node) {
if (pos-tz == tz pos-trip == trip pos-cdev == cdev) {
list_del(pos-tz_node);
list_del(pos-cdev_node);
+ mutex_unlock(cdev-lock);
mutex_unlock(tz-lock);
goto unbind;
}
}
+ mutex_unlock(cdev-lock);
mutex_unlock(tz-lock);
return -ENODEV;
@@ -913,6 +918,7 @@ thermal_cooling_device_register(char *type, void *devdata,
}
strcpy(cdev-type, type);
+ mutex_init(cdev-lock);
INIT_LIST_HEAD(cdev-thermal_instances);
cdev-ops = ops;
cdev-updated = true;
@@ -1016,6 +1022,7 @@ static void thermal_cdev_do_update(struct
thermal_cooling_device *cdev)
if (cdev-updated)
return;
+ mutex_lock(cdev-lock);
/* Make sure cdev enters the deepest cooling state */
list_for_each_entry(instance, cdev-thermal_instances, cdev_node) {
if (instance-target == THERMAL_NO_TARGET)
@@ -1023,6 +1030,7 @@ static void thermal_cdev_do_update(struct
thermal_cooling_device *cdev)
if (instance-target target)
target = instance-target;
}
+ mutex_unlock(cdev-lock);
cdev-ops-set_cur_state(cdev, target);
cdev-updated = true;
}
diff --git a/include/linux/thermal.h b/include/linux/thermal.h
index 76d0fe8..91b3481 100644
--- a/include/linux/thermal.h
+++ b/include/linux/thermal.h
@@ -95,6 +95,7 @@ struct thermal_cooling_device {
void *devdata;
const struct thermal_cooling_device_ops *ops;
bool updated; /* true if the cooling device does not need update */
+ struct mutex lock; /* protect thermal_instances list */
struct list_head thermal_instances;
struct list_head node;
};
--
1.8.0.rc1
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 19/30] hwmon: exynos4: move thermal sensor driver to driver/thermal directory
From: Amit Daniel Kachhap amit.kach...@linaro.org
This movement is needed because the hwmon entries and corresponding sysfs
interface is a duplicate of utilities already provided by
driver/thermal/thermal_sys.c. The goal is to place it in thermal folder
and add necessary functions to use the in-kernel thermal interfaces.
Signed-off-by: Amit Daniel Kachhap amit.kach...@linaro.org
Acked-by: Guenter Roeck guenter.ro...@ericsson.com
Cc: SangWook Ju sw...@samsung.com
Cc: Durgadoss durgados...@intel.com
Cc: Len Brown l...@kernel.org
Cc: Jean Delvare kh...@linux-fr.org
Cc: Kyungmin Park kmp...@infradead.org
Cc: Kukjin Kim kgene@samsung.com
Signed-off-by: Andrew Morton a...@linux-foundation.org
Signed-off-by: Amit Daniel Kachhap amit.dan...@samsung.com
Signed-off-by: Zhang Rui rui.zh...@intel.com
---
.../{hwmon/exynos4_tmu = thermal/exynos_thermal} | 35 +--
drivers/hwmon/Kconfig | 10 --
drivers/hwmon/Makefile | 1 -
drivers/thermal/Kconfig| 7 ++
drivers/thermal/Makefile | 1 +
.../exynos4_tmu.c = thermal/exynos_thermal.c} | 113 +
.../{exynos4_tmu.h = exynos_thermal.h}| 8 +-
7 files changed, 19 insertions(+), 156 deletions(-)
rename Documentation/{hwmon/exynos4_tmu = thermal/exynos_thermal} (71%)
rename drivers/{hwmon/exynos4_tmu.c = thermal/exynos_thermal.c} (74%)
rename include/linux/platform_data/{exynos4_tmu.h = exynos_thermal.h} (94%)
diff --git a/Documentation/hwmon/exynos4_tmu
b/Documentation/thermal/exynos_thermal
similarity index 71%
rename from Documentation/hwmon/exynos4_tmu
rename to Documentation/thermal/exynos_thermal
index c3c6b41..2b46f67 100644
--- a/Documentation/hwmon/exynos4_tmu
+++ b/Documentation/thermal/exynos_thermal
@@ -46,36 +46,7 @@ The threshold levels are defined as follows:
The threshold and each trigger_level are set
through the corresponding registers.
-When an interrupt occurs, this driver notify user space of
-one of four threshold levels for the interrupt
-through kobject_uevent_env and sysfs_notify functions.
+When an interrupt occurs, this driver notify kernel thermal framework
+with the function exynos4_report_trigger.
Although an interrupt condition for level_0 can be set,
-it is not notified to user space through sysfs_notify function.
-
-Sysfs Interface
-name name of the temperature sensor
- RO
-
-temp1_inputtemperature
- RO
-
-temp1_max temperature for level_1 interrupt
- RO
-
-temp1_crit temperature for level_2 interrupt
- RO
-
-temp1_emergencytemperature for level_3 interrupt
- RO
-
-temp1_max_alarmalarm for level_1 interrupt
- RO
-
-temp1_crit_alarm
- alarm for level_2 interrupt
- RO
-
-temp1_emergency_alarm
- alarm for level_3 interrupt
- RO
+it can be used to synchronize the cooling action.
diff --git a/drivers/hwmon/Kconfig b/drivers/hwmon/Kconfig
index b0a2e4c..84e02b4 100644
--- a/drivers/hwmon/Kconfig
+++ b/drivers/hwmon/Kconfig
@@ -324,16 +324,6 @@ config SENSORS_DA9052_ADC
This driver can also be built as module. If so, the module
will be called da9052-hwmon.
-config SENSORS_EXYNOS4_TMU
- tristate Temperature sensor on Samsung EXYNOS4
- depends on ARCH_EXYNOS4
- help
- If you say yes here you get support for TMU (Thermal Management
- Unit) on SAMSUNG EXYNOS4 series of SoC.
-
- This driver can also be built as a module. If so, the module
- will be called exynos4-tmu.
-
config SENSORS_I5K_AMB
tristate FB-DIMM AMB temperature sensor on Intel 5000 series chipsets
depends on PCI EXPERIMENTAL
diff --git a/drivers/hwmon/Makefile b/drivers/hwmon/Makefile
index 7aa9811..3eafe48 100644
--- a/drivers/hwmon/Makefile
+++ b/drivers/hwmon/Makefile
@@ -49,7 +49,6 @@ obj-$(CONFIG_SENSORS_DS1621) += ds1621.o
obj-$(CONFIG_SENSORS_EMC1403) += emc1403.o
obj-$(CONFIG_SENSORS_EMC2103) += emc2103.o
obj-$(CONFIG_SENSORS_EMC6W201) += emc6w201.o
-obj-$(CONFIG_SENSORS_EXYNOS4_TMU) += exynos4_tmu.o
obj-$(CONFIG_SENSORS_F71805F) += f71805f.o
obj-$(CONFIG_SENSORS_F71882FG) += f71882fg.o
obj-$(CONFIG_SENSORS_F75375S) += f75375s.o
diff --git a/drivers/thermal/Kconfig b/drivers/thermal/Kconfig
index 996003b..8f2b6ea 100644
--- a/drivers/thermal/Kconfig
+++ b/drivers/thermal/Kconfig
@@ -46,3 +46,10 @@ config RCAR_THERMAL
help
Enable this to plug the R-Car thermal sensor driver into the Linux
thermal framework
+
+config EXYNOS_THERMAL
+ tristate Temperature sensor on Samsung EXYNOS
+ depends on ARCH_EXYNOS4 THERMAL
+ help
+ If you say yes here you get support for TMU (Thermal Managment
+ Unit) on SAMSUNG EXYNOS series of SoC.
diff --git
[PATCH 25/30] thermal: Exynos: Fix NULL pointer dereference in exynos_unregister_thermal()
From: Sachin Kamat sachin.ka...@linaro.org
exynos_unregister_thermal() is functional only when 'th_zone' is not
NULL (ensured by the NULL checks). However, in the event it is NULL, it
gets dereferenced in the for loop. This patch fixes this issue.
Signed-off-by: Sachin Kamat sachin.ka...@linaro.org
---
drivers/thermal/exynos_thermal.c | 7 +--
1 file changed, 5 insertions(+), 2 deletions(-)
diff --git a/drivers/thermal/exynos_thermal.c b/drivers/thermal/exynos_thermal.c
index e84acde..fd03e85 100644
--- a/drivers/thermal/exynos_thermal.c
+++ b/drivers/thermal/exynos_thermal.c
@@ -475,11 +475,14 @@ static void exynos_unregister_thermal(void)
{
int i;
- if (th_zone th_zone-therm_dev)
+ if (!th_zone)
+ return;
+
+ if (th_zone-therm_dev)
thermal_zone_device_unregister(th_zone-therm_dev);
for (i = 0; i th_zone-cool_dev_size; i++) {
- if (th_zone th_zone-cool_dev[i])
+ if (th_zone-cool_dev[i])
cpufreq_cooling_unregister(th_zone-cool_dev[i]);
}
--
1.8.0.rc1
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 28/30] cpuidle / ACPI: fix potential NULL pointer dereference
From: Wei Yongjun yongjun_...@trendmicro.com.cn
The dereference should be moved below the NULL test.
dpatch engine is used to auto generate this patch.
(https://github.com/weiyj/dpatch)
Signed-off-by: Wei Yongjun yongjun_...@trendmicro.com.cn
Signed-off-by: Len Brown len.br...@intel.com
---
drivers/acpi/processor_idle.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/acpi/processor_idle.c b/drivers/acpi/processor_idle.c
index 3655ab9..e8086c7 100644
--- a/drivers/acpi/processor_idle.c
+++ b/drivers/acpi/processor_idle.c
@@ -1132,7 +1132,7 @@ static int acpi_processor_setup_cpuidle_states(struct
acpi_processor *pr)
int acpi_processor_hotplug(struct acpi_processor *pr)
{
int ret = 0;
- struct cpuidle_device *dev = per_cpu(acpi_cpuidle_device, pr-id);
+ struct cpuidle_device *dev;
if (disabled_by_idle_boot_param())
return 0;
@@ -1147,6 +1147,7 @@ int acpi_processor_hotplug(struct acpi_processor *pr)
if (!pr-flags.power_setup_done)
return -ENODEV;
+ dev = per_cpu(acpi_cpuidle_device, pr-id);
cpuidle_pause_and_lock();
cpuidle_disable_device(dev);
acpi_processor_get_power_info(pr);
--
1.8.0.rc1
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 27/30] ACPI: EC: Add a quirk for CLEVO M720T/M730T laptop
From: Feng Tang feng.t...@intel.com
By enlarging the GPE storm threshold back to 20, that laptop's
EC works fine with interrupt mode instead of polling mode.
https://bugzilla.kernel.org/show_bug.cgi?id=45151
Reported-and-Tested-by: Francesco trent...@dei.unipd.it
Signed-off-by: Feng Tang feng.t...@intel.com
Signed-off-by: Len Brown len.br...@intel.com
cc: sta...@vger.kernel.org
---
drivers/acpi/ec.c | 16 +++-
1 file changed, 15 insertions(+), 1 deletion(-)
diff --git a/drivers/acpi/ec.c b/drivers/acpi/ec.c
index 615264c..a51df96 100644
--- a/drivers/acpi/ec.c
+++ b/drivers/acpi/ec.c
@@ -930,6 +930,17 @@ static int ec_flag_msi(const struct dmi_system_id *id)
return 0;
}
+/*
+ * Clevo M720 notebook actually works ok with IRQ mode, if we lifted
+ * the GPE storm threshold back to 20
+ */
+static int ec_enlarge_storm_threshold(const struct dmi_system_id *id)
+{
+ pr_debug(Setting the EC GPE storm threshold to 20\n);
+ ec_storm_threshold = 20;
+ return 0;
+}
+
static struct dmi_system_id __initdata ec_dmi_table[] = {
{
ec_skip_dsdt_scan, Compal JFL92, {
@@ -961,10 +972,13 @@ static struct dmi_system_id __initdata ec_dmi_table[] = {
{
ec_validate_ecdt, ASUS hardware, {
DMI_MATCH(DMI_BOARD_VENDOR, ASUSTeK Computer Inc.) }, NULL},
+ {
+ ec_enlarge_storm_threshold, CLEVO hardware, {
+ DMI_MATCH(DMI_SYS_VENDOR, CLEVO Co.),
+ DMI_MATCH(DMI_PRODUCT_NAME, M720T/M730T),}, NULL},
{},
};
-
int __init acpi_ec_ecdt_probe(void)
{
acpi_status status;
--
1.8.0.rc1
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 29/30] ACPI idle, CPU hotplug: Fix NULL pointer dereference during hotplug
From: Srivatsa S. Bhat srivatsa.b...@linux.vnet.ibm.com
On a KVM guest, when a CPU is taken offline and brought back online, we hit
the following NULL pointer dereference:
[ 45.400843] Unregister pv shared memory for cpu 1
[ 45.412331] smpboot: CPU 1 is now offline
[ 45.529894] SMP alternatives: lockdep: fixing up alternatives
[ 45.533472] smpboot: Booting Node 0 Processor 1 APIC 0x1
[ 45.411526] kvm-clock: cpu 1, msr 0:7d14601, secondary cpu clock
[ 45.571370] KVM setup async PF for cpu 1
[ 45.572331] kvm-stealtime: cpu 1, msr 7d0e040
[ 45.575031] BUG: unable to handle kernel NULL pointer dereference at
(null)
[ 45.576017] IP: [81519f98] cpuidle_disable_device+0x18/0x80
[ 45.576017] PGD 5dfb067 PUD 5da8067 PMD 0
[ 45.576017] Oops: [#1] SMP
[ 45.576017] Modules linked in:
[ 45.576017] CPU 0
[ 45.576017] Pid: 607, comm: stress_cpu_hotp Not tainted
3.6.0-padata-tp-debug #3 Bochs Bochs
[ 45.576017] RIP: 0010:[81519f98] [81519f98]
cpuidle_disable_device+0x18/0x80
[ 45.576017] RSP: 0018:880005d93ce8 EFLAGS: 00010286
[ 45.576017] RAX: 880005d93fd8 RBX: RCX: 0006
[ 45.576017] RDX: 0006 RSI: RDI:
[ 45.576017] RBP: 880005d93cf8 R08: R09:
[ 45.576017] R10: R11: R12:
[ 45.576017] R13: R14: 81c8cca0 R15: 0001
[ 45.576017] FS: 7f91936ae700() GS:880007c0()
knlGS:
[ 45.576017] CS: 0010 DS: ES: CR0: 8005003b
[ 45.576017] CR2: CR3: 05db3000 CR4: 06f0
[ 45.576017] DR0: DR1: DR2:
[ 45.576017] DR3: DR6: 0ff0 DR7: 0400
[ 45.576017] Process stress_cpu_hotp (pid: 607, threadinfo 880005d92000,
task 8800066bbf40)
[ 45.576017] Stack:
[ 45.576017] 880007a96400 880005d93d28
813ac689
[ 45.576017] 880007a96400 880007a96400 0002
81cd8d01
[ 45.576017] 880005d93d58 813aa498 0001
ffdd
[ 45.576017] Call Trace:
[ 45.576017] [813ac689] acpi_processor_hotplug+0x55/0x97
[ 45.576017] [813aa498] acpi_cpu_soft_notify+0x93/0xce
[ 45.576017] [816ae47d] notifier_call_chain+0x5d/0x110
[ 45.576017] [8109730e] __raw_notifier_call_chain+0xe/0x10
[ 45.576017] [81069050] __cpu_notify+0x20/0x40
[ 45.576017] [81069085] cpu_notify+0x15/0x20
[ 45.576017] [816978f1] _cpu_up+0xee/0x137
[ 45.576017] [81697983] cpu_up+0x49/0x59
[ 45.576017] [8168758d] store_online+0x9d/0xe0
[ 45.576017] [8140a9f8] dev_attr_store+0x18/0x30
[ 45.576017] [812322c0] sysfs_write_file+0xe0/0x150
[ 45.576017] [811b389c] vfs_write+0xac/0x180
[ 45.576017] [811b3be2] sys_write+0x52/0xa0
[ 45.576017] [816b31e9] system_call_fastpath+0x16/0x1b
[ 45.576017] Code: 48 c7 c7 40 e5 ca 81 e8 07 d0 18 00 5d c3 0f 1f 44 00 00
0f 1f 44 00 00 55 48 89 e5 48 83 ec 10 48 89 5d f0 4c 89 65 f8 48 89 fb f6 07
02 75 13 48 8b 5d f0 4c 8b 65 f8 c9 c3 66 0f 1f 84 00 00
[ 45.576017] RIP [81519f98] cpuidle_disable_device+0x18/0x80
[ 45.576017] RSP 880005d93ce8
[ 45.576017] CR2:
[ 45.656079] ---[ end trace 433d6c9ac0b02cef ]---
Analysis:
Commit 3d339dc (cpuidle / ACPI : move cpuidle_device field out of the
acpi_processor_power structure()) made the allocation of the dev structure
(struct cpuidle) of a CPU dynamic, whereas previously it was statically
allocated. And this dynamic allocation occurs in acpi_processor_power_init()
if pr-flags.power evaluates to non-zero.
On KVM guests, pr-flags.power evaluates to zero, hence dev is never
allocated. This causes the NULL pointer (dev) dereference in
cpuidle_disable_device() during a subsequent CPU online operation. Fix this
by ensuring that dev is non-NULL before dereferencing.
Signed-off-by: Srivatsa S. Bhat srivatsa.b...@linux.vnet.ibm.com
Signed-off-by: Len Brown len.br...@intel.com
---
drivers/cpuidle/cpuidle.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/cpuidle/cpuidle.c b/drivers/cpuidle/cpuidle.c
index e28f6ea..7f15b85 100644
--- a/drivers/cpuidle/cpuidle.c
+++ b/drivers/cpuidle/cpuidle.c
@@ -368,7 +368,7 @@ EXPORT_SYMBOL_GPL(cpuidle_enable_device);
*/
void cpuidle_disable_device(struct cpuidle_device *dev)
{
- if (!dev-enabled)
+ if (!dev || !dev-enabled)
return;
if (!cpuidle_get_driver() || !cpuidle_curr_governor)
return;
--
1.8.0.rc1
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More
[PATCH 30/30] tools/power/acpi/acpidump: remove duplicated include from acpidump.c
From: Wei Yongjun yongjun_...@trendmicro.com.cn Remove duplicated include. dpatch engine is used to auto generate this patch. (https://github.com/weiyj/dpatch) Signed-off-by: Wei Yongjun yongjun_...@trendmicro.com.cn Signed-off-by: Len Brown len.br...@intel.com --- tools/power/acpi/acpidump.c | 1 - 1 file changed, 1 deletion(-) diff --git a/tools/power/acpi/acpidump.c b/tools/power/acpi/acpidump.c index 0777987..a84553a 100644 --- a/tools/power/acpi/acpidump.c +++ b/tools/power/acpi/acpidump.c @@ -62,7 +62,6 @@ typedef long long s64; #include unistd.h #include getopt.h -#include sys/types.h #include dirent.h #include acpi/acconfig.h -- 1.8.0.rc1 -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 18/30] thermal: add generic cpufreq cooling implementation
From: Amit Daniel Kachhap amit.kach...@linaro.org This patchset introduces a new generic cooling device based on cpufreq that can be used on non-ACPI platforms. As a proof of concept, we have drivers for the following platforms using this mechanism now: * Samsung Exynos (Exynos4 and Exynos5) in the current patchset. * Freescale i.MX (git://git.linaro.org/people/amitdanielk/linux.git imx6q_thermal) There is a small change in cpufreq cooling registration APIs, so a minor change is needed for Freescale platforms. Brief Description: 1) The generic cooling devices code is placed inside driver/thermal/* as placing inside acpi folder will need un-necessary enabling of acpi code. This code is architecture independent. 2) This patchset adds generic cpu cooling low level implementation through frequency clipping. In future, other cpu related cooling devices may be added here. An ACPI version of this already exists (drivers/acpi/processor_thermal.c) .But this will be useful for platforms like ARM using the generic thermal interface along with the generic cpu cooling devices. The cooling device registration API's return cooling device pointers which can be easily binded with the thermal zone trip points. The important APIs exposed are, a) struct thermal_cooling_device *cpufreq_cooling_register( struct cpumask *clip_cpus) b) void cpufreq_cooling_unregister(struct thermal_cooling_device *cdev) 3) Samsung exynos platform thermal implementation is done using the generic cpu cooling APIs and the new trip type. The temperature sensor driver present in the hwmon folder(registered as hwmon driver) is moved to thermal folder and registered as a thermal driver. A simple data/control flow diagrams is shown below, Core Linux thermal - Exynos thermal interface - Temperature Sensor | | \|/| Cpufreq cooling device --- TODO: *Will send the DT enablement patches later after the driver is merged. This patch: Add support for generic cpu thermal cooling low level implementations using frequency scaling up/down based on the registration parameters. Different cpu related cooling devices can be registered by the user and the binding of these cooling devices to the corresponding trip points can be easily done as the registration APIs return the cooling device pointer. The user of these APIs are responsible for passing clipping frequency . The drivers can also register to recieve notification about any cooling action called. [a...@linux-foundation.org: fix comment layout] Signed-off-by: Amit Daniel Kachhap amit.kach...@linaro.org Cc: Guenter Roeck guenter.ro...@ericsson.com Cc: SangWook Ju sw...@samsung.com Cc: Durgadoss durgados...@intel.com Cc: Len Brown l...@kernel.org Cc: Jean Delvare kh...@linux-fr.org Cc: Kyungmin Park kmp...@infradead.org Cc: Kukjin Kim kgene@samsung.com Signed-off-by: Andrew Morton a...@linux-foundation.org Signed-off-by: Amit Daniel Kachhap amit.dan...@samsung.com Signed-off-by: Zhang Rui rui.zh...@intel.com --- Documentation/thermal/cpu-cooling-api.txt | 32 +++ drivers/thermal/Kconfig | 11 + drivers/thermal/Makefile | 1 + drivers/thermal/cpu_cooling.c | 450 ++ include/linux/cpu_cooling.h | 58 5 files changed, 552 insertions(+) create mode 100644 Documentation/thermal/cpu-cooling-api.txt create mode 100644 drivers/thermal/cpu_cooling.c create mode 100644 include/linux/cpu_cooling.h diff --git a/Documentation/thermal/cpu-cooling-api.txt b/Documentation/thermal/cpu-cooling-api.txt new file mode 100644 index 000..fca24c9 --- /dev/null +++ b/Documentation/thermal/cpu-cooling-api.txt @@ -0,0 +1,32 @@ +CPU cooling APIs How To +=== + +Written by Amit Daniel Kachhap amit.kach...@linaro.org + +Updated: 12 May 2012 + +Copyright (c) 2012 Samsung Electronics Co., Ltd(http://www.samsung.com) + +0. Introduction + +The generic cpu cooling(freq clipping) provides registration/unregistration APIs +to the caller. The binding of the cooling devices to the trip point is left for +the user. The registration APIs returns the cooling device pointer. + +1. cpu cooling APIs + +1.1 cpufreq registration/unregistration APIs +1.1.1 struct thermal_cooling_device *cpufreq_cooling_register( + struct cpumask *clip_cpus) + +This interface function registers the cpufreq cooling device with the name +thermal-cpufreq-%x. This api can support multiple instances of cpufreq +cooling devices. + + clip_cpus: cpumask of cpus where the frequency constraints will happen. + +1.1.2 void cpufreq_cooling_unregister(struct thermal_cooling_device *cdev) + +This interface function unregisters the thermal-cpufreq-%x cooling device. + +cdev: Cooling device pointer which has to be unregistered. diff --git
[PATCH 20/30] thermal: exynos5: add exynos5250 thermal sensor driver support
From: Amit Daniel Kachhap amit.kach...@linaro.org
Insert exynos5 TMU sensor changes into the thermal driver. Some exynos4
changes are made generic for exynos series.
[a...@linux-foundation.org: fix comment layout]
Signed-off-by: SangWook Ju sw...@samsung.com
Signed-off-by: Amit Daniel Kachhap amit.kach...@linaro.org
Acked-by: Guenter Roeck guenter.ro...@ericsson.com
Cc: Durgadoss durgados...@intel.com
Cc: Len Brown l...@kernel.org
Cc: Jean Delvare kh...@linux-fr.org
Cc: Kyungmin Park kmp...@infradead.org
Cc: Kukjin Kim kgene@samsung.com
Signed-off-by: Andrew Morton a...@linux-foundation.org
Signed-off-by: Amit Daniel Kachhap amit.dan...@samsung.com
Signed-off-by: Zhang Rui rui.zh...@intel.com
---
drivers/thermal/Kconfig | 2 +-
drivers/thermal/exynos_thermal.c | 351 +--
include/linux/platform_data/exynos_thermal.h | 19 +-
3 files changed, 240 insertions(+), 132 deletions(-)
diff --git a/drivers/thermal/Kconfig b/drivers/thermal/Kconfig
index 8f2b6ea..edfd67d 100644
--- a/drivers/thermal/Kconfig
+++ b/drivers/thermal/Kconfig
@@ -49,7 +49,7 @@ config RCAR_THERMAL
config EXYNOS_THERMAL
tristate Temperature sensor on Samsung EXYNOS
- depends on ARCH_EXYNOS4 THERMAL
+ depends on (ARCH_EXYNOS4 || ARCH_EXYNOS5) THERMAL
help
If you say yes here you get support for TMU (Thermal Managment
Unit) on SAMSUNG EXYNOS series of SoC.
diff --git a/drivers/thermal/exynos_thermal.c b/drivers/thermal/exynos_thermal.c
index 556d15b..c9a33dd 100644
--- a/drivers/thermal/exynos_thermal.c
+++ b/drivers/thermal/exynos_thermal.c
@@ -33,44 +33,83 @@
#include linux/kobject.h
#include linux/io.h
#include linux/mutex.h
-
#include linux/platform_data/exynos_thermal.h
-
-#define EXYNOS4_TMU_REG_TRIMINFO 0x0
-#define EXYNOS4_TMU_REG_CONTROL0x20
-#define EXYNOS4_TMU_REG_STATUS 0x28
-#define EXYNOS4_TMU_REG_CURRENT_TEMP 0x40
-#define EXYNOS4_TMU_REG_THRESHOLD_TEMP 0x44
-#define EXYNOS4_TMU_REG_TRIG_LEVEL00x50
-#define EXYNOS4_TMU_REG_TRIG_LEVEL10x54
-#define EXYNOS4_TMU_REG_TRIG_LEVEL20x58
-#define EXYNOS4_TMU_REG_TRIG_LEVEL30x5C
-#define EXYNOS4_TMU_REG_PAST_TEMP0 0x60
-#define EXYNOS4_TMU_REG_PAST_TEMP1 0x64
-#define EXYNOS4_TMU_REG_PAST_TEMP2 0x68
-#define EXYNOS4_TMU_REG_PAST_TEMP3 0x6C
-#define EXYNOS4_TMU_REG_INTEN 0x70
-#define EXYNOS4_TMU_REG_INTSTAT0x74
-#define EXYNOS4_TMU_REG_INTCLEAR 0x78
-
-#define EXYNOS4_TMU_GAIN_SHIFT 8
-#define EXYNOS4_TMU_REF_VOLTAGE_SHIFT 24
-
-#define EXYNOS4_TMU_TRIM_TEMP_MASK 0xff
-#define EXYNOS4_TMU_CORE_ON3
-#define EXYNOS4_TMU_CORE_OFF 2
-#define EXYNOS4_TMU_DEF_CODE_TO_TEMP_OFFSET50
-#define EXYNOS4_TMU_TRIG_LEVEL0_MASK 0x1
-#define EXYNOS4_TMU_TRIG_LEVEL1_MASK 0x10
-#define EXYNOS4_TMU_TRIG_LEVEL2_MASK 0x100
-#define EXYNOS4_TMU_TRIG_LEVEL3_MASK 0x1000
-#define EXYNOS4_TMU_INTCLEAR_VAL 0x
-
-struct exynos4_tmu_data {
- struct exynos4_tmu_platform_data *pdata;
+#include linux/of.h
+
+#include plat/cpu.h
+
+/* Exynos generic registers */
+#define EXYNOS_TMU_REG_TRIMINFO0x0
+#define EXYNOS_TMU_REG_CONTROL 0x20
+#define EXYNOS_TMU_REG_STATUS 0x28
+#define EXYNOS_TMU_REG_CURRENT_TEMP0x40
+#define EXYNOS_TMU_REG_INTEN 0x70
+#define EXYNOS_TMU_REG_INTSTAT 0x74
+#define EXYNOS_TMU_REG_INTCLEAR0x78
+
+#define EXYNOS_TMU_TRIM_TEMP_MASK 0xff
+#define EXYNOS_TMU_GAIN_SHIFT 8
+#define EXYNOS_TMU_REF_VOLTAGE_SHIFT 24
+#define EXYNOS_TMU_CORE_ON 3
+#define EXYNOS_TMU_CORE_OFF2
+#define EXYNOS_TMU_DEF_CODE_TO_TEMP_OFFSET 50
+
+/* Exynos4210 specific registers */
+#define EXYNOS4210_TMU_REG_THRESHOLD_TEMP 0x44
+#define EXYNOS4210_TMU_REG_TRIG_LEVEL0 0x50
+#define EXYNOS4210_TMU_REG_TRIG_LEVEL1 0x54
+#define EXYNOS4210_TMU_REG_TRIG_LEVEL2 0x58
+#define EXYNOS4210_TMU_REG_TRIG_LEVEL3 0x5C
+#define EXYNOS4210_TMU_REG_PAST_TEMP0 0x60
+#define EXYNOS4210_TMU_REG_PAST_TEMP1 0x64
+#define EXYNOS4210_TMU_REG_PAST_TEMP2 0x68
+#define EXYNOS4210_TMU_REG_PAST_TEMP3 0x6C
+
+#define EXYNOS4210_TMU_TRIG_LEVEL0_MASK0x1
+#define EXYNOS4210_TMU_TRIG_LEVEL1_MASK0x10
+#define EXYNOS4210_TMU_TRIG_LEVEL2_MASK0x100
+#define EXYNOS4210_TMU_TRIG_LEVEL3_MASK0x1000
+#define EXYNOS4210_TMU_INTCLEAR_VAL0x
+
+/* Exynos5250 and Exynos4412 specific registers */
+#define EXYNOS_TMU_TRIMINFO_CON0x14
+#define EXYNOS_THD_TEMP_RISE 0x50
+#define EXYNOS_THD_TEMP_FALL 0x54
+#define EXYNOS_EMUL_CON0x80
+
+#define EXYNOS_TRIMINFO_RELOAD 0x1
+#define EXYNOS_TMU_CLEAR_RISE_INT 0x111
+#define EXYNOS_TMU_CLEAR_FALL_INT (0x111 16)
+#define EXYNOS_MUX_ADDR_VALUE 6
+#define EXYNOS_MUX_ADDR_SHIFT 20
+#define EXYNOS_TMU_TRIP_MODE_SHIFT 13
+
+#define
[PATCH 24/30] Thermal: Fix bug on cpu_cooling, cooling device's id conflict problem.
From: Jonghwa Lee jonghwa3@samsung.com This patch fixes small bug on cpu_cooling. CPU cooling device has own id generated with idr mathod. However in the previous version, it swapped to all same id at last stage of probing as 0. This makes id's collision and also occures error when it releases that id. Signed-off-by: Jonghwa Lee jonghwa3@samsung.com --- drivers/thermal/cpu_cooling.c | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/drivers/thermal/cpu_cooling.c b/drivers/thermal/cpu_cooling.c index 99a5d75..9050c1b 100644 --- a/drivers/thermal/cpu_cooling.c +++ b/drivers/thermal/cpu_cooling.c @@ -351,7 +351,7 @@ struct thermal_cooling_device *cpufreq_cooling_register( struct cpufreq_cooling_device *cpufreq_dev = NULL; unsigned int cpufreq_dev_count = 0, min = 0, max = 0; char dev_name[THERMAL_NAME_LENGTH]; - int ret = 0, id = 0, i; + int ret = 0, i; struct cpufreq_policy policy; list_for_each_entry(cpufreq_dev, cooling_cpufreq_list, node) @@ -396,7 +396,6 @@ struct thermal_cooling_device *cpufreq_cooling_register( kfree(cpufreq_dev); return ERR_PTR(-EINVAL); } - cpufreq_dev-id = id; cpufreq_dev-cool_dev = cool_dev; cpufreq_dev-cpufreq_state = 0; mutex_lock(cooling_cpufreq_lock); -- 1.8.0.rc1 -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@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: net: fix typo in freescale/ucc_geth.c
On Tue, 2012-10-09 at 10:52 +1100, Michael Neuling wrote: The following patch: acb600d net: remove skb recycling added dev_free_skb() to drivers/net/ethernet/freescale/ucc_geth.c This is a typo and should be dev_kfree_skb(). This fixes this. Signed-off-by: Michael Neuling mi...@neuling.org --- This hit as a compile error in next-20121008 with mpc85xx_defconfig. diff --git a/drivers/net/ethernet/freescale/ucc_geth.c b/drivers/net/ethernet/freescale/ucc_geth.c index dfa0aaa..0a70bb5 100644 --- a/drivers/net/ethernet/freescale/ucc_geth.c +++ b/drivers/net/ethernet/freescale/ucc_geth.c @@ -3268,7 +3268,7 @@ static int ucc_geth_rx(struct ucc_geth_private *ugeth, u8 rxQ, int rx_work_limit if (netif_msg_rx_err(ugeth)) ugeth_err(%s, %d: ERROR!!! skb - 0x%08x, __func__, __LINE__, (u32) skb); - dev_free_skb(skb); + dev_kfree_skb(skb); ugeth-rx_skbuff[rxQ][ugeth-skb_currx[rxQ]] = NULL; Oops, thanks Michael ! -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 26/30] ACPI: EC: Make the GPE storm threshold a module parameter
From: Feng Tang feng.t...@intel.com
The Linux EC driver includes a mechanism to detect GPE storms,
and switch from interrupt-mode to polling mode. However, polling
mode sometimes doesn't work, so the workaround is problematic.
Also, different systems seem to need the threshold for detecting
the GPE storm at different levels.
ACPI_EC_STORM_THRESHOLD was initially 20 when it's created, and
was changed to 8 in 2.6.28 commit 06cf7d3c7 ACPI: EC: lower interrupt storm
threshold to fix kernel bug 11892 by forcing the laptop in that bug to
work in polling mode. However in bug 45151, it works fine in interrupt
mode if we lift the threshold back to 20.
This patch makes the threshold a module parameter so that user has a
flexible option to debug/workaround this issue.
The default is unchanged.
This is also a preparation patch to fix specific systems:
https://bugzilla.kernel.org/show_bug.cgi?id=45151
Signed-off-by: Feng Tang feng.t...@intel.com
Signed-off-by: Len Brown len.br...@intel.com
cc: sta...@vger.kernel.org
---
drivers/acpi/ec.c | 14 ++
1 file changed, 10 insertions(+), 4 deletions(-)
diff --git a/drivers/acpi/ec.c b/drivers/acpi/ec.c
index 7edaccc..615264c 100644
--- a/drivers/acpi/ec.c
+++ b/drivers/acpi/ec.c
@@ -71,9 +71,6 @@ enum ec_command {
#define ACPI_EC_UDELAY_GLK 1000/* Wait 1ms max. to get global lock */
#define ACPI_EC_MSI_UDELAY 550 /* Wait 550us for MSI EC */
-#define ACPI_EC_STORM_THRESHOLD 8 /* number of false interrupts
- per one transaction */
-
enum {
EC_FLAGS_QUERY_PENDING, /* Query is pending */
EC_FLAGS_GPE_STORM, /* GPE storm detected */
@@ -87,6 +84,15 @@ static unsigned int ec_delay __read_mostly = ACPI_EC_DELAY;
module_param(ec_delay, uint, 0644);
MODULE_PARM_DESC(ec_delay, Timeout(ms) waited until an EC command completes);
+/*
+ * If the number of false interrupts per one transaction exceeds
+ * this threshold, will think there is a GPE storm happened and
+ * will disable the GPE for normal transaction.
+ */
+static unsigned int ec_storm_threshold __read_mostly = 8;
+module_param(ec_storm_threshold, uint, 0644);
+MODULE_PARM_DESC(ec_storm_threshold, Maxim false GPE numbers not considered
as GPE storm);
+
/* If we find an EC via the ECDT, we need to keep a ptr to its context */
/* External interfaces use first EC only, so remember */
typedef int (*acpi_ec_query_func) (void *data);
@@ -319,7 +325,7 @@ static int acpi_ec_transaction(struct acpi_ec *ec, struct
transaction *t)
msleep(1);
/* It is safe to enable the GPE outside of the transaction. */
acpi_enable_gpe(NULL, ec-gpe);
- } else if (t-irq_count ACPI_EC_STORM_THRESHOLD) {
+ } else if (t-irq_count ec_storm_threshold) {
pr_info(PREFIX GPE storm detected,
transactions will use polling mode\n);
set_bit(EC_FLAGS_GPE_STORM, ec-flags);
--
1.8.0.rc1
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 23/30] thermal: exynos: Use devm_* functions
From: Amit Daniel Kachhap amit.kach...@linaro.org
devm_* functions are used to replace kzalloc, request_mem_region, ioremap
and request_irq functions in probe call. With the usage of devm_* functions
explicit freeing and unmapping is not required.
Signed-off-by: Sachin Kamat sachin.ka...@linaro.org
Signed-off-by: Sachin Kamat sachin.ka...@samsung.com
Signed-off-by: Amit Daniel Kachhap amit.kach...@linaro.org
Signed-off-by: Zhang Rui rui.zh...@intel.com
---
drivers/thermal/exynos_thermal.c | 45
1 file changed, 9 insertions(+), 36 deletions(-)
diff --git a/drivers/thermal/exynos_thermal.c b/drivers/thermal/exynos_thermal.c
index 03a99e4..e84acde 100644
--- a/drivers/thermal/exynos_thermal.c
+++ b/drivers/thermal/exynos_thermal.c
@@ -842,7 +842,8 @@ static int __devinit exynos_tmu_probe(struct
platform_device *pdev)
dev_err(pdev-dev, No platform init data supplied.\n);
return -ENODEV;
}
- data = kzalloc(sizeof(struct exynos_tmu_data), GFP_KERNEL);
+ data = devm_kzalloc(pdev-dev, sizeof(struct exynos_tmu_data),
+ GFP_KERNEL);
if (!data) {
dev_err(pdev-dev, Failed to allocate driver structure\n);
return -ENOMEM;
@@ -850,47 +851,35 @@ static int __devinit exynos_tmu_probe(struct
platform_device *pdev)
data-irq = platform_get_irq(pdev, 0);
if (data-irq 0) {
- ret = data-irq;
dev_err(pdev-dev, Failed to get platform irq\n);
- goto err_free;
+ return data-irq;
}
INIT_WORK(data-irq_work, exynos_tmu_work);
data-mem = platform_get_resource(pdev, IORESOURCE_MEM, 0);
if (!data-mem) {
- ret = -ENOENT;
dev_err(pdev-dev, Failed to get platform resource\n);
- goto err_free;
+ return -ENOENT;
}
- data-mem = request_mem_region(data-mem-start,
- resource_size(data-mem), pdev-name);
- if (!data-mem) {
- ret = -ENODEV;
- dev_err(pdev-dev, Failed to request memory region\n);
- goto err_free;
- }
-
- data-base = ioremap(data-mem-start, resource_size(data-mem));
+ data-base = devm_request_and_ioremap(pdev-dev, data-mem);
if (!data-base) {
- ret = -ENODEV;
dev_err(pdev-dev, Failed to ioremap memory\n);
- goto err_mem_region;
+ return -ENODEV;
}
- ret = request_irq(data-irq, exynos_tmu_irq,
+ ret = devm_request_irq(pdev-dev, data-irq, exynos_tmu_irq,
IRQF_TRIGGER_RISING, exynos-tmu, data);
if (ret) {
dev_err(pdev-dev, Failed to request irq: %d\n, data-irq);
- goto err_io_remap;
+ return ret;
}
data-clk = clk_get(NULL, tmu_apbif);
if (IS_ERR(data-clk)) {
- ret = PTR_ERR(data-clk);
dev_err(pdev-dev, Failed to get clock\n);
- goto err_irq;
+ return PTR_ERR(data-clk);
}
if (pdata-type == SOC_ARCH_EXYNOS ||
@@ -942,15 +931,6 @@ static int __devinit exynos_tmu_probe(struct
platform_device *pdev)
err_clk:
platform_set_drvdata(pdev, NULL);
clk_put(data-clk);
-err_irq:
- free_irq(data-irq, data);
-err_io_remap:
- iounmap(data-base);
-err_mem_region:
- release_mem_region(data-mem-start, resource_size(data-mem));
-err_free:
- kfree(data);
-
return ret;
}
@@ -964,15 +944,8 @@ static int __devexit exynos_tmu_remove(struct
platform_device *pdev)
clk_put(data-clk);
- free_irq(data-irq, data);
-
- iounmap(data-base);
- release_mem_region(data-mem-start, resource_size(data-mem));
-
platform_set_drvdata(pdev, NULL);
- kfree(data);
-
return 0;
}
--
1.8.0.rc1
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 21/30] thermal: exynos: register the tmu sensor with the kernel thermal layer
From: Amit Daniel Kachhap amit.kach...@linaro.org
This code added creates a link between temperature sensors, linux thermal
framework and cooling devices for samsung exynos platform. This layer
monitors the temperature from the sensor and informs the generic thermal
layer to take the necessary cooling action.
[a...@linux-foundation.org: fix comment layout]
Signed-off-by: Amit Daniel Kachhap amit.kach...@linaro.org
Acked-by: Guenter Roeck guenter.ro...@ericsson.com
Cc: SangWook Ju sw...@samsung.com
Cc: Durgadoss durgados...@intel.com
Cc: Len Brown l...@kernel.org
Cc: Jean Delvare kh...@linux-fr.org
Cc: Kyungmin Park kmp...@infradead.org
Cc: Kukjin Kim kgene@samsung.com
Signed-off-by: Andrew Morton a...@linux-foundation.org
Signed-off-by: Amit Daniel Kachhap amit.dan...@samsung.com
Signed-off-by: Zhang Rui rui.zh...@intel.com
---
drivers/thermal/exynos_thermal.c | 406 ++-
include/linux/platform_data/exynos_thermal.h | 22 ++
2 files changed, 426 insertions(+), 2 deletions(-)
diff --git a/drivers/thermal/exynos_thermal.c b/drivers/thermal/exynos_thermal.c
index c9a33dd..e79cdc9 100644
--- a/drivers/thermal/exynos_thermal.c
+++ b/drivers/thermal/exynos_thermal.c
@@ -34,6 +34,9 @@
#include linux/io.h
#include linux/mutex.h
#include linux/platform_data/exynos_thermal.h
+#include linux/thermal.h
+#include linux/cpufreq.h
+#include linux/cpu_cooling.h
#include linux/of.h
#include plat/cpu.h
@@ -94,6 +97,7 @@
#define ACTIVE_INTERVAL 500
#define IDLE_INTERVAL 1
+#define MCELSIUS 1000
/* CPU Zone information */
#define PANIC_ZONE 4
@@ -104,6 +108,8 @@
#define GET_ZONE(trip) (trip + 2)
#define GET_TRIP(zone) (zone - 2)
+#define EXYNOS_ZONE_COUNT 3
+
struct exynos_tmu_data {
struct exynos_tmu_platform_data *pdata;
struct resource *mem;
@@ -116,6 +122,371 @@ struct exynos_tmu_data {
u8 temp_error1, temp_error2;
};
+struct thermal_trip_point_conf {
+ int trip_val[MAX_TRIP_COUNT];
+ int trip_count;
+};
+
+struct thermal_cooling_conf {
+ struct freq_clip_table freq_data[MAX_TRIP_COUNT];
+ int freq_clip_count;
+};
+
+struct thermal_sensor_conf {
+ char name[SENSOR_NAME_LEN];
+ int (*read_temperature)(void *data);
+ struct thermal_trip_point_conf trip_data;
+ struct thermal_cooling_conf cooling_data;
+ void *private_data;
+};
+
+struct exynos_thermal_zone {
+ enum thermal_device_mode mode;
+ struct thermal_zone_device *therm_dev;
+ struct thermal_cooling_device *cool_dev[MAX_COOLING_DEVICE];
+ unsigned int cool_dev_size;
+ struct platform_device *exynos4_dev;
+ struct thermal_sensor_conf *sensor_conf;
+ bool bind;
+};
+
+static struct exynos_thermal_zone *th_zone;
+static void exynos_unregister_thermal(void);
+static int exynos_register_thermal(struct thermal_sensor_conf *sensor_conf);
+
+/* Get mode callback functions for thermal zone */
+static int exynos_get_mode(struct thermal_zone_device *thermal,
+ enum thermal_device_mode *mode)
+{
+ if (th_zone)
+ *mode = th_zone-mode;
+ return 0;
+}
+
+/* Set mode callback functions for thermal zone */
+static int exynos_set_mode(struct thermal_zone_device *thermal,
+ enum thermal_device_mode mode)
+{
+ if (!th_zone-therm_dev) {
+ pr_notice(thermal zone not registered\n);
+ return 0;
+ }
+
+ mutex_lock(th_zone-therm_dev-lock);
+
+ if (mode == THERMAL_DEVICE_ENABLED)
+ th_zone-therm_dev-polling_delay = IDLE_INTERVAL;
+ else
+ th_zone-therm_dev-polling_delay = 0;
+
+ mutex_unlock(th_zone-therm_dev-lock);
+
+ th_zone-mode = mode;
+ thermal_zone_device_update(th_zone-therm_dev);
+ pr_info(thermal polling set for duration=%d msec\n,
+ th_zone-therm_dev-polling_delay);
+ return 0;
+}
+
+
+/* Get trip type callback functions for thermal zone */
+static int exynos_get_trip_type(struct thermal_zone_device *thermal, int trip,
+enum thermal_trip_type *type)
+{
+ switch (GET_ZONE(trip)) {
+ case MONITOR_ZONE:
+ case WARN_ZONE:
+ *type = THERMAL_TRIP_ACTIVE;
+ break;
+ case PANIC_ZONE:
+ *type = THERMAL_TRIP_CRITICAL;
+ break;
+ default:
+ return -EINVAL;
+ }
+ return 0;
+}
+
+/* Get trip temperature callback functions for thermal zone */
+static int exynos_get_trip_temp(struct thermal_zone_device *thermal, int trip,
+ unsigned long *temp)
+{
+ if (trip GET_TRIP(MONITOR_ZONE) || trip GET_TRIP(PANIC_ZONE))
+ return -EINVAL;
+
+ *temp = th_zone-sensor_conf-trip_data.trip_val[trip];
+ /* convert the temperature into millicelsius */
+ *temp = *temp * MCELSIUS;
+
+
[PATCH 22/30] ARM: exynos: add thermal sensor driver platform data support
From: Amit Daniel Kachhap amit.kach...@linaro.org
Add necessary default platform data support needed for TMU driver. The
supplied dt/non-dt values are tested for origen exynos4210 and smdk exynos5250
platforms and only compile tested for exynos4412.
Signed-off-by: Amit Daniel Kachhap amit.kach...@linaro.org
Acked-by: Guenter Roeck guenter.ro...@ericsson.com
Cc: SangWook Ju sw...@samsung.com
Cc: Durgadoss durgados...@intel.com
Cc: Len Brown l...@kernel.org
Cc: Jean Delvare kh...@linux-fr.org
Cc: jonghwa lee jonghwa3@samsung.com
Cc: Kyungmin Park kmp...@infradead.org
Cc: Kukjin Kim kgene@samsung.com
Signed-off-by: Andrew Morton a...@linux-foundation.org
Signed-off-by: Amit Daniel Kachhap amit.dan...@samsung.com
Signed-off-by: Zhang Rui rui.zh...@intel.com
---
drivers/thermal/exynos_thermal.c | 111 ++-
1 file changed, 110 insertions(+), 1 deletion(-)
diff --git a/drivers/thermal/exynos_thermal.c b/drivers/thermal/exynos_thermal.c
index e79cdc9..03a99e4 100644
--- a/drivers/thermal/exynos_thermal.c
+++ b/drivers/thermal/exynos_thermal.c
@@ -723,14 +723,121 @@ static irqreturn_t exynos_tmu_irq(int irq, void *id)
static struct thermal_sensor_conf exynos_sensor_conf = {
.name = exynos-therm,
.read_temperature = (int (*)(void *))exynos_tmu_read,
+};
+
+#if defined(CONFIG_CPU_EXYNOS4210)
+static struct exynos_tmu_platform_data const exynos4210_default_tmu_data = {
+ .threshold = 80,
+ .trigger_levels[0] = 5,
+ .trigger_levels[1] = 20,
+ .trigger_levels[2] = 30,
+ .trigger_level0_en = 1,
+ .trigger_level1_en = 1,
+ .trigger_level2_en = 1,
+ .trigger_level3_en = 0,
+ .gain = 15,
+ .reference_voltage = 7,
+ .cal_type = TYPE_ONE_POINT_TRIMMING,
+ .freq_tab[0] = {
+ .freq_clip_max = 800 * 1000,
+ .temp_level = 85,
+ },
+ .freq_tab[1] = {
+ .freq_clip_max = 200 * 1000,
+ .temp_level = 100,
+ },
+ .freq_tab_count = 2,
+ .type = SOC_ARCH_EXYNOS4210,
+};
+#define EXYNOS4210_TMU_DRV_DATA (exynos4210_default_tmu_data)
+#else
+#define EXYNOS4210_TMU_DRV_DATA (NULL)
+#endif
+
+#if defined(CONFIG_SOC_EXYNOS5250) || defined(CONFIG_SOC_EXYNOS4412)
+static struct exynos_tmu_platform_data const exynos_default_tmu_data = {
+ .trigger_levels[0] = 85,
+ .trigger_levels[1] = 103,
+ .trigger_levels[2] = 110,
+ .trigger_level0_en = 1,
+ .trigger_level1_en = 1,
+ .trigger_level2_en = 1,
+ .trigger_level3_en = 0,
+ .gain = 8,
+ .reference_voltage = 16,
+ .noise_cancel_mode = 4,
+ .cal_type = TYPE_ONE_POINT_TRIMMING,
+ .efuse_value = 55,
+ .freq_tab[0] = {
+ .freq_clip_max = 800 * 1000,
+ .temp_level = 85,
+ },
+ .freq_tab[1] = {
+ .freq_clip_max = 200 * 1000,
+ .temp_level = 103,
+ },
+ .freq_tab_count = 2,
+ .type = SOC_ARCH_EXYNOS,
+};
+#define EXYNOS_TMU_DRV_DATA (exynos_default_tmu_data)
+#else
+#define EXYNOS_TMU_DRV_DATA (NULL)
+#endif
+
+#ifdef CONFIG_OF
+static const struct of_device_id exynos_tmu_match[] = {
+ {
+ .compatible = samsung,exynos4210-tmu,
+ .data = (void *)EXYNOS4210_TMU_DRV_DATA,
+ },
+ {
+ .compatible = samsung,exynos5250-tmu,
+ .data = (void *)EXYNOS_TMU_DRV_DATA,
+ },
+ {},
+};
+MODULE_DEVICE_TABLE(of, exynos_tmu_match);
+#else
+#define exynos_tmu_match NULL
+#endif
+
+static struct platform_device_id exynos_tmu_driver_ids[] = {
+ {
+ .name = exynos4210-tmu,
+ .driver_data= (kernel_ulong_t)EXYNOS4210_TMU_DRV_DATA,
+ },
+ {
+ .name = exynos5250-tmu,
+ .driver_data= (kernel_ulong_t)EXYNOS_TMU_DRV_DATA,
+ },
+ { },
+};
+MODULE_DEVICE_TABLE(platform, exynos4_tmu_driver_ids);
+
+static inline struct exynos_tmu_platform_data *exynos_get_driver_data(
+ struct platform_device *pdev)
+{
+#ifdef CONFIG_OF
+ if (pdev-dev.of_node) {
+ const struct of_device_id *match;
+ match = of_match_node(exynos_tmu_match, pdev-dev.of_node);
+ if (!match)
+ return NULL;
+ return (struct exynos_tmu_platform_data *) match-data;
+ }
+#endif
+ return (struct exynos_tmu_platform_data *)
+ platform_get_device_id(pdev)-driver_data;
}
-;
static int __devinit exynos_tmu_probe(struct platform_device *pdev)
{
struct exynos_tmu_data *data;
struct exynos_tmu_platform_data *pdata = pdev-dev.platform_data;
int ret, i;
+ if (!pdata)
+ pdata = exynos_get_driver_data(pdev);
+
if (!pdata) {
dev_err(pdev-dev, No platform init data supplied.\n);
Re: [PATCH 1/3] mfd: Convert tps6586x to irq_domain
On Mon, Oct 08, 2012 at 09:43:23PM +0530, Laxman Dewangan wrote: Allocate the irq base if it base is not porvided i.e. in case of device tree invocation of this driver. Convert the tps6586x driver to irq domain, using a legacy IRQ mapping if an irq_base is specified in platform data or dynamically allocated and otherwise using a linear mapping. Reviewed-by: Mark Brown broo...@opensource.wolfsonmicro.com but can you convert to regmap_irq? -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 17/30] Fix a build error.
From: Eduardo Valentin eduardo.valen...@ti.com Signed-off-by: Eduardo Valentin eduardo.valen...@ti.com Signed-off-by: Zhang Rui rui.zh...@intel.com --- drivers/staging/omap-thermal/omap-thermal-common.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/drivers/staging/omap-thermal/omap-thermal-common.c b/drivers/staging/omap-thermal/omap-thermal-common.c index d543d5c..b4cd6cc 100644 --- a/drivers/staging/omap-thermal/omap-thermal-common.c +++ b/drivers/staging/omap-thermal/omap-thermal-common.c @@ -120,7 +120,9 @@ static int omap_thermal_bind(struct thermal_zone_device *thermal, /* TODO: bind with min and max states */ /* Simple thing, two trips, one passive another critical */ - return thermal_zone_bind_cooling_device(thermal, 0, cdev); + return thermal_zone_bind_cooling_device(thermal, 0, cdev, + THERMAL_NO_LIMIT, + THERMAL_NO_LIMIT); } /* Unbind callback functions for thermal zone */ -- 1.8.0.rc1 -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@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] mfd: tps6586x: add irq io-resource for rtc sub driver
On Mon, Oct 08, 2012 at 09:43:24PM +0530, Laxman Dewangan wrote: Add IRQ IORESOURCE for rtc sub driver of this device. The rtc driver can get the irq by calling platform_get_irq(). Signed-off-by: Laxman Dewangan ldewan...@nvidia.com Reviewed-by: Mark Brown broo...@opensource.wolfsonmicro.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 -v2 00/10] x86: Use BRK to pre mapping page table to make xen happy
On 10/09/2012 12:39 PM, Yinghai Lu wrote: on top of tip/x86/mm2 Hi Yinghai, This patchset doesn't apply on top of tip:x86/mm2, starting at patch 08/10. Furthermore, a lot of the descriptions are both incomplete and incomprehensible, which makes the patchset very very hard to review. You should think of the descriptions as writing a (short) paper on your patchset, where you describe not just what you are doing, but how you accomplish the objective and why that objective is the right thing do accomplish. Overall, this patchset seems to be going in the right direction, but I have several concerns with details. -hpa -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 3/3] mfd: tps6586x: implement gpio_to_irq
On Mon, Oct 08, 2012 at 09:43:25PM +0530, Laxman Dewangan wrote: The TPS6586x adds the interrupt of this device using linear mapping on irq domain. Hence, implement gpio_to_irq to get the irq number corresponding to TPS6586x GPIOs which is created dynamically. Reviewed-by: Mark Brown broo...@opensource.wolfsonmicro.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 06/30] Thermal: Introduce thermal_zone_trip_update()
From: Zhang Rui rui.zh...@intel.com
This function is used to update the cooling state of
all the cooling devices that are bound to an active trip point.
This will be used for passive cooling as well, in the future patches.
as both active and passive cooling can share the same algorithm,
which is
1. if the temperature is higher than a trip point,
a. if the trend is THERMAL_TREND_RAISING, use higher cooling
state for this trip point
b. if the trend is THERMAL_TREND_DROPPING, use lower cooling
state for this trip point
2. if the temperature is lower than a trip point, use lower
cooling state for this trip point.
Signed-off-by: Zhang Rui rui.zh...@intel.com
Reviewed-by: Rafael J. Wysocki r...@sisk.pl
Reviewed-by: Eduardo Valentin eduardo.valen...@ti.com
---
drivers/acpi/thermal.c| 8 ++--
drivers/thermal/thermal_sys.c | 102 +++---
2 files changed, 81 insertions(+), 29 deletions(-)
diff --git a/drivers/acpi/thermal.c b/drivers/acpi/thermal.c
index 07cb217..bd66bd2 100644
--- a/drivers/acpi/thermal.c
+++ b/drivers/acpi/thermal.c
@@ -716,9 +716,11 @@ static int thermal_get_trend(struct thermal_zone_device
*thermal,
if (thermal_get_trip_type(thermal, trip, type))
return -EINVAL;
- /* Only PASSIVE trip points need TREND */
- if (type != THERMAL_TRIP_PASSIVE)
- return -EINVAL;
+ if (type == THERMAL_TRIP_ACTIVE) {
+ /* aggressive active cooling */
+ *trend = THERMAL_TREND_RAISING;
+ return 0;
+ }
/*
* tz-temperature has already been updated by generic thermal layer,
diff --git a/drivers/thermal/thermal_sys.c b/drivers/thermal/thermal_sys.c
index 0cf3dce..735e6e6 100644
--- a/drivers/thermal/thermal_sys.c
+++ b/drivers/thermal/thermal_sys.c
@@ -1076,6 +1076,81 @@ void thermal_cooling_device_unregister(struct
}
EXPORT_SYMBOL(thermal_cooling_device_unregister);
+/*
+ * Cooling algorithm for active trip points
+ *
+ * 1. if the temperature is higher than a trip point,
+ *a. if the trend is THERMAL_TREND_RAISING, use higher cooling
+ * state for this trip point
+ *b. if the trend is THERMAL_TREND_DROPPING, use lower cooling
+ * state for this trip point
+ *
+ * 2. if the temperature is lower than a trip point, use lower
+ *cooling state for this trip point
+ *
+ * Note that this behaves the same as the previous passive cooling
+ * algorithm.
+ */
+
+static void thermal_zone_trip_update(struct thermal_zone_device *tz,
+int trip, long temp)
+{
+ struct thermal_cooling_device_instance *instance;
+ struct thermal_cooling_device *cdev = NULL;
+ unsigned long cur_state, max_state;
+ long trip_temp;
+ enum thermal_trend trend;
+
+ tz-ops-get_trip_temp(tz, trip, trip_temp);
+
+ if (!tz-ops-get_trend || tz-ops-get_trend(tz, trip, trend)) {
+ /*
+* compare the current temperature and previous temperature
+* to get the thermal trend, if no special requirement
+*/
+ if (tz-temperature tz-last_temperature)
+ trend = THERMAL_TREND_RAISING;
+ else if (tz-temperature tz-last_temperature)
+ trend = THERMAL_TREND_DROPPING;
+ else
+ trend = THERMAL_TREND_STABLE;
+ }
+
+ if (temp = trip_temp) {
+ list_for_each_entry(instance, tz-cooling_devices, node) {
+ if (instance-trip != trip)
+ continue;
+
+ cdev = instance-cdev;
+
+ cdev-ops-get_cur_state(cdev, cur_state);
+ cdev-ops-get_max_state(cdev, max_state);
+
+ if (trend == THERMAL_TREND_RAISING) {
+ cur_state = cur_state instance-upper ?
+ (cur_state + 1) : instance-upper;
+ } else if (trend == THERMAL_TREND_DROPPING) {
+ cur_state = cur_state instance-lower ?
+ (cur_state - 1) : instance-lower;
+ }
+ cdev-ops-set_cur_state(cdev, cur_state);
+ }
+ } else {/* below trip */
+ list_for_each_entry(instance, tz-cooling_devices, node) {
+ if (instance-trip != trip)
+ continue;
+
+ cdev = instance-cdev;
+ cdev-ops-get_cur_state(cdev, cur_state);
+
+ cur_state = cur_state instance-lower ?
+ (cur_state - 1) : instance-lower;
+ cdev-ops-set_cur_state(cdev, cur_state);
+ }
+ }
+
+ return;
+}
/**
* thermal_zone_device_update -
[PATCH 10/30] Thermal: List thermal_instance in thermal_cooling_device.
From: Zhang Rui rui.zh...@intel.com
List thermal_instance in thermal_cooling_device so that
cooling device can know the cooling state requirement
of all the thermal instances.
Signed-off-by: Zhang Rui rui.zh...@intel.com
Reviewed-by: Rafael J. Wysocki r...@sisk.pl
Reviewed-by: Eduardo Valentin eduardo.valen...@ti.com
---
drivers/thermal/thermal_sys.c | 7 ++-
include/linux/thermal.h | 1 +
2 files changed, 7 insertions(+), 1 deletion(-)
diff --git a/drivers/thermal/thermal_sys.c b/drivers/thermal/thermal_sys.c
index 2884376..70045c1 100644
--- a/drivers/thermal/thermal_sys.c
+++ b/drivers/thermal/thermal_sys.c
@@ -57,6 +57,7 @@ struct thermal_instance {
char attr_name[THERMAL_NAME_LENGTH];
struct device_attribute attr;
struct list_head tz_node; /* node in tz-thermal_instances */
+ struct list_head cdev_node; /* node in cdev-thermal_instances */
};
static DEFINE_IDR(thermal_tz_idr);
@@ -878,8 +879,10 @@ int thermal_zone_bind_cooling_device(struct
thermal_zone_device *tz,
result = -EEXIST;
break;
}
- if (!result)
+ if (!result) {
list_add_tail(dev-tz_node, tz-thermal_instances);
+ list_add_tail(dev-cdev_node, cdev-thermal_instances);
+ }
mutex_unlock(tz-lock);
if (!result)
@@ -915,6 +918,7 @@ int thermal_zone_unbind_cooling_device(struct
thermal_zone_device *tz,
list_for_each_entry_safe(pos, next, tz-thermal_instances, tz_node) {
if (pos-tz == tz pos-trip == trip pos-cdev == cdev) {
list_del(pos-tz_node);
+ list_del(pos-cdev_node);
mutex_unlock(tz-lock);
goto unbind;
}
@@ -984,6 +988,7 @@ thermal_cooling_device_register(char *type, void *devdata,
}
strcpy(cdev-type, type);
+ INIT_LIST_HEAD(cdev-thermal_instances);
cdev-ops = ops;
cdev-device.class = thermal_class;
cdev-devdata = devdata;
diff --git a/include/linux/thermal.h b/include/linux/thermal.h
index cb0b0e3..9ae378a 100644
--- a/include/linux/thermal.h
+++ b/include/linux/thermal.h
@@ -94,6 +94,7 @@ struct thermal_cooling_device {
struct device device;
void *devdata;
const struct thermal_cooling_device_ops *ops;
+ struct list_head thermal_instances;
struct list_head node;
};
--
1.8.0.rc1
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 16/30] thermal: Fix potential NULL pointer accesses
From: Guenter Roeck li...@roeck-us.net The type parameter in thermal_zone_device_register and thermal_cooling_device_register can be NULL, indicating that no sysfs attribute for the type should be created. Only call strlen() and strcpy() on type if it is not NULL. This patch addresses Coverity #102180 and #102182: Dereference before null check Signed-off-by: Guenter Roeck li...@roeck-us.net Signed-off-by: Zhang Rui rui.zh...@intel.com --- drivers/thermal/thermal_sys.c | 8 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/drivers/thermal/thermal_sys.c b/drivers/thermal/thermal_sys.c index 36e6f4d..47498b8 100644 --- a/drivers/thermal/thermal_sys.c +++ b/drivers/thermal/thermal_sys.c @@ -901,7 +901,7 @@ thermal_cooling_device_register(char *type, void *devdata, struct thermal_zone_device *pos; int result; - if (strlen(type) = THERMAL_NAME_LENGTH) + if (type strlen(type) = THERMAL_NAME_LENGTH) return ERR_PTR(-EINVAL); if (!ops || !ops-get_max_state || !ops-get_cur_state || @@ -918,7 +918,7 @@ thermal_cooling_device_register(char *type, void *devdata, return ERR_PTR(result); } - strcpy(cdev-type, type); + strcpy(cdev-type, type ? : ); mutex_init(cdev-lock); INIT_LIST_HEAD(cdev-thermal_instances); cdev-ops = ops; @@ -1344,7 +1344,7 @@ struct thermal_zone_device *thermal_zone_device_register(const char *type, int count; int passive = 0; - if (strlen(type) = THERMAL_NAME_LENGTH) + if (type strlen(type) = THERMAL_NAME_LENGTH) return ERR_PTR(-EINVAL); if (trips THERMAL_MAX_TRIPS || trips 0 || mask trips) @@ -1366,7 +1366,7 @@ struct thermal_zone_device *thermal_zone_device_register(const char *type, return ERR_PTR(result); } - strcpy(tz-type, type); + strcpy(tz-type, type ? : ); tz-ops = ops; tz-device.class = thermal_class; tz-devdata = devdata; -- 1.8.0.rc1 -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 15/30] thermal: add Renesas R-Car thermal sensor support
From: Kuninori Morimoto kuninori.morimoto...@renesas.com
This patch add basic Renesas R-Car thermal sensor support.
It was tested on R-Car H1 Marzen board.
Signed-off-by: Kuninori Morimoto kuninori.morimoto...@renesas.com
Cc: Len Brown len.br...@intel.com
Cc: Joe Perches j...@perches.com
Cc: Jean Delvare kh...@linux-fr.org
Cc: Guenter Roeck guenter.ro...@ericsson.com
Cc: Magnus Damm magnus.d...@gmail.com
Signed-off-by: Andrew Morton a...@linux-foundation.org
Signed-off-by: Zhang Rui rui.zh...@intel.com
---
drivers/thermal/Kconfig| 8 ++
drivers/thermal/Makefile | 3 +-
drivers/thermal/rcar_thermal.c | 260 +
3 files changed, 270 insertions(+), 1 deletion(-)
create mode 100644 drivers/thermal/rcar_thermal.c
diff --git a/drivers/thermal/Kconfig b/drivers/thermal/Kconfig
index 3ab2bd5..7dd8c34 100644
--- a/drivers/thermal/Kconfig
+++ b/drivers/thermal/Kconfig
@@ -27,3 +27,11 @@ config SPEAR_THERMAL
help
Enable this to plug the SPEAr thermal sensor driver into the Linux
thermal framework
+
+config RCAR_THERMAL
+ tristate Renesas R-Car thermal driver
+ depends on THERMAL
+ depends on ARCH_SHMOBILE
+ help
+ Enable this to plug the R-Car thermal sensor driver into the Linux
+ thermal framework
diff --git a/drivers/thermal/Makefile b/drivers/thermal/Makefile
index a9fff0b..fd9369a 100644
--- a/drivers/thermal/Makefile
+++ b/drivers/thermal/Makefile
@@ -3,4 +3,5 @@
#
obj-$(CONFIG_THERMAL) += thermal_sys.o
-obj-$(CONFIG_SPEAR_THERMAL)+= spear_thermal.o
\ No newline at end of file
+obj-$(CONFIG_SPEAR_THERMAL)+= spear_thermal.o
+obj-$(CONFIG_RCAR_THERMAL) += rcar_thermal.o
diff --git a/drivers/thermal/rcar_thermal.c b/drivers/thermal/rcar_thermal.c
new file mode 100644
index 000..d445271
--- /dev/null
+++ b/drivers/thermal/rcar_thermal.c
@@ -0,0 +1,260 @@
+/*
+ * R-Car THS/TSC thermal sensor driver
+ *
+ * Copyright (C) 2012 Renesas Solutions Corp.
+ * Kuninori Morimoto kuninori.morimoto...@renesas.com
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; version 2 of the License.
+ *
+ * This program is distributed in the hope that it will be useful, but
+ * WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
+ * General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License along
+ * with this program; if not, write to the Free Software Foundation, Inc.,
+ * 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA.
+ */
+#include linux/delay.h
+#include linux/err.h
+#include linux/io.h
+#include linux/module.h
+#include linux/platform_device.h
+#include linux/slab.h
+#include linux/spinlock.h
+#include linux/thermal.h
+
+#define THSCR 0x2c
+#define THSSR 0x30
+
+/* THSCR */
+#define CPTAP 0xf
+
+/* THSSR */
+#define CTEMP 0x3f
+
+
+struct rcar_thermal_priv {
+ void __iomem *base;
+ struct device *dev;
+ spinlock_t lock;
+ u32 comp;
+};
+
+/*
+ * basic functions
+ */
+static u32 rcar_thermal_read(struct rcar_thermal_priv *priv, u32 reg)
+{
+ unsigned long flags;
+ u32 ret;
+
+ spin_lock_irqsave(priv-lock, flags);
+
+ ret = ioread32(priv-base + reg);
+
+ spin_unlock_irqrestore(priv-lock, flags);
+
+ return ret;
+}
+
+#if 0 /* no user at this point */
+static void rcar_thermal_write(struct rcar_thermal_priv *priv,
+ u32 reg, u32 data)
+{
+ unsigned long flags;
+
+ spin_lock_irqsave(priv-lock, flags);
+
+ iowrite32(data, priv-base + reg);
+
+ spin_unlock_irqrestore(priv-lock, flags);
+}
+#endif
+
+static void rcar_thermal_bset(struct rcar_thermal_priv *priv, u32 reg,
+ u32 mask, u32 data)
+{
+ unsigned long flags;
+ u32 val;
+
+ spin_lock_irqsave(priv-lock, flags);
+
+ val = ioread32(priv-base + reg);
+ val = ~mask;
+ val |= (data mask);
+ iowrite32(val, priv-base + reg);
+
+ spin_unlock_irqrestore(priv-lock, flags);
+}
+
+/*
+ * zone device functions
+ */
+static int rcar_thermal_get_temp(struct thermal_zone_device *zone,
+ unsigned long *temp)
+{
+ struct rcar_thermal_priv *priv = zone-devdata;
+ int val, min, max, tmp;
+
+ tmp = -200; /* default */
+ while (1) {
+ if (priv-comp 1 || priv-comp 12) {
+ dev_err(priv-dev,
+ THSSR invalid data (%d)\n, priv-comp);
+ priv-comp = 4; /* for next thermal */
+ return -EINVAL;
+ }
+
+ /*
+* THS comparator offset and the
[PATCH 14/30] thermal: fix potential out-of-bounds memory access
From: Guenter Roeck li...@roeck-us.net
temp_crit.name and temp_input.name have a length of 16 bytes. Using
THERMAL_NAME_LENGTH (20) as length parameter for snprintf() may result in
out-of-bounds memory accesses. Replace it with sizeof().
Addresses Coverity #115679
Signed-off-by: Guenter Roeck li...@roeck-us.net
Cc: Len Brown l...@kernel.org
Cc: Brown, Len len.br...@intel.com
Signed-off-by: Andrew Morton a...@linux-foundation.org
Signed-off-by: Zhang Rui rui.zh...@intel.com
---
drivers/thermal/thermal_sys.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/drivers/thermal/thermal_sys.c b/drivers/thermal/thermal_sys.c
index 5be8728..36e6f4d 100644
--- a/drivers/thermal/thermal_sys.c
+++ b/drivers/thermal/thermal_sys.c
@@ -598,7 +598,7 @@ thermal_add_hwmon_sysfs(struct thermal_zone_device *tz)
temp-tz = tz;
hwmon-count++;
- snprintf(temp-temp_input.name, THERMAL_NAME_LENGTH,
+ snprintf(temp-temp_input.name, sizeof(temp-temp_input.name),
temp%d_input, hwmon-count);
temp-temp_input.attr.attr.name = temp-temp_input.name;
temp-temp_input.attr.attr.mode = 0444;
@@ -611,7 +611,8 @@ thermal_add_hwmon_sysfs(struct thermal_zone_device *tz)
if (tz-ops-get_crit_temp) {
unsigned long temperature;
if (!tz-ops-get_crit_temp(tz, temperature)) {
- snprintf(temp-temp_crit.name, THERMAL_NAME_LENGTH,
+ snprintf(temp-temp_crit.name,
+sizeof(temp-temp_crit.name),
temp%d_crit, hwmon-count);
temp-temp_crit.attr.attr.name = temp-temp_crit.name;
temp-temp_crit.attr.attr.mode = 0444;
--
1.8.0.rc1
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 12/30] Thermal: Unify the code for both active and passive cooling
From: Zhang Rui rui.zh...@intel.com
Remove thermal_zone_device_passive(). And use
thermal_zone_trip_update() and thermal_zone_do_update()
for both active and passive cooling.
Signed-off-by: Zhang Rui rui.zh...@intel.com
Reviewed-by: Rafael J. Wysocki r...@sisk.pl
Reviewed-by: Eduardo Valentin eduardo.valen...@ti.com
---
drivers/thermal/thermal_sys.c | 110 ++
include/linux/thermal.h | 2 +-
2 files changed, 26 insertions(+), 86 deletions(-)
diff --git a/drivers/thermal/thermal_sys.c b/drivers/thermal/thermal_sys.c
index 36ae2f4..6e9d3dc 100644
--- a/drivers/thermal/thermal_sys.c
+++ b/drivers/thermal/thermal_sys.c
@@ -715,84 +715,6 @@ static void thermal_zone_device_set_polling(struct
thermal_zone_device *tz,
msecs_to_jiffies(delay));
}
-static void thermal_zone_device_passive(struct thermal_zone_device *tz,
- int temp, int trip_temp, int trip)
-{
- enum thermal_trend trend;
- struct thermal_instance *instance;
- struct thermal_cooling_device *cdev;
- long state, max_state;
-
- if (!tz-ops-get_trend || tz-ops-get_trend(tz, trip, trend)) {
- /*
-* compare the current temperature and previous temperature
-* to get the thermal trend, if no special requirement
-*/
- if (tz-temperature tz-last_temperature)
- trend = THERMAL_TREND_RAISING;
- else if (tz-temperature tz-last_temperature)
- trend = THERMAL_TREND_DROPPING;
- else
- trend = THERMAL_TREND_STABLE;
- }
-
- /*
-* Above Trip?
-* ---
-* Calculate the thermal trend (using the passive cooling equation)
-* and modify the performance limit for all passive cooling devices
-* accordingly. Note that we assume symmetry.
-*/
- if (temp = trip_temp) {
- tz-passive = true;
-
- /* Heating up? */
- if (trend == THERMAL_TREND_RAISING) {
- list_for_each_entry(instance, tz-thermal_instances,
- tz_node) {
- if (instance-trip != trip)
- continue;
- cdev = instance-cdev;
- cdev-ops-get_cur_state(cdev, state);
- cdev-ops-get_max_state(cdev, max_state);
- if (state++ max_state)
- cdev-ops-set_cur_state(cdev, state);
- }
- } else if (trend == THERMAL_TREND_DROPPING) { /* Cooling off? */
- list_for_each_entry(instance, tz-thermal_instances,
- tz_node) {
- if (instance-trip != trip)
- continue;
- cdev = instance-cdev;
- cdev-ops-get_cur_state(cdev, state);
- cdev-ops-get_max_state(cdev, max_state);
- if (state 0)
- cdev-ops-set_cur_state(cdev, --state);
- }
- }
- return;
- }
-
- /*
-* Below Trip?
-* ---
-* Implement passive cooling hysteresis to slowly increase performance
-* and avoid thrashing around the passive trip point. Note that we
-* assume symmetry.
-*/
- list_for_each_entry(instance, tz-thermal_instances, tz_node) {
- if (instance-trip != trip)
- continue;
- cdev = instance-cdev;
- cdev-ops-get_cur_state(cdev, state);
- cdev-ops-get_max_state(cdev, max_state);
- if (state 0)
- cdev-ops-set_cur_state(cdev, --state);
- if (state == 0)
- tz-passive = false;
- }
-}
-
static void thermal_zone_device_check(struct work_struct *work)
{
struct thermal_zone_device *tz = container_of(work, struct
@@ -1114,7 +1036,7 @@ static void thermal_zone_do_update(struct
thermal_zone_device *tz)
}
/*
- * Cooling algorithm for active trip points
+ * Cooling algorithm for both active and passive cooling
*
* 1. if the temperature is higher than a trip point,
*a. if the trend is THERMAL_TREND_RAISING, use higher cooling
@@ -1136,9 +1058,16 @@ static void thermal_zone_trip_update(struct
thermal_zone_device *tz,
struct thermal_cooling_device *cdev = NULL;
unsigned long cur_state, max_state;
long trip_temp;
+ enum thermal_trip_type trip_type;
enum thermal_trend trend;
- tz-ops-get_trip_temp(tz, trip,
[PATCH 08/30] Thermal: Rename thermal_zone_device.cooling_devices
From: Zhang Rui rui.zh...@intel.com
Rename thermal_zone_device.cooling_devices
to thermal_zone_device.thermal_instances
thermal_zone_device.cooling_devices is not accurate
as this is a list for thermal instances, rather than cooling devices.
Signed-off-by: Zhang Rui rui.zh...@intel.com
Reviewed-by: Rafael J. Wysocki r...@sisk.pl
Reviewed-by: Eduardo Valentin eduardo.valen...@ti.com
---
drivers/thermal/thermal_sys.c | 18 +-
include/linux/thermal.h | 4 ++--
2 files changed, 11 insertions(+), 11 deletions(-)
diff --git a/drivers/thermal/thermal_sys.c b/drivers/thermal/thermal_sys.c
index 3eba397..797d148 100644
--- a/drivers/thermal/thermal_sys.c
+++ b/drivers/thermal/thermal_sys.c
@@ -745,7 +745,7 @@ static void thermal_zone_device_passive(struct
thermal_zone_device *tz,
/* Heating up? */
if (trend == THERMAL_TREND_RAISING) {
- list_for_each_entry(instance, tz-cooling_devices,
+ list_for_each_entry(instance, tz-thermal_instances,
node) {
if (instance-trip != trip)
continue;
@@ -756,7 +756,7 @@ static void thermal_zone_device_passive(struct
thermal_zone_device *tz,
cdev-ops-set_cur_state(cdev, state);
}
} else if (trend == THERMAL_TREND_DROPPING) { /* Cooling off? */
- list_for_each_entry(instance, tz-cooling_devices,
+ list_for_each_entry(instance, tz-thermal_instances,
node) {
if (instance-trip != trip)
continue;
@@ -777,7 +777,7 @@ static void thermal_zone_device_passive(struct
thermal_zone_device *tz,
* and avoid thrashing around the passive trip point. Note that we
* assume symmetry.
*/
- list_for_each_entry(instance, tz-cooling_devices, node) {
+ list_for_each_entry(instance, tz-thermal_instances, node) {
if (instance-trip != trip)
continue;
cdev = instance-cdev;
@@ -873,13 +873,13 @@ int thermal_zone_bind_cooling_device(struct
thermal_zone_device *tz,
goto remove_symbol_link;
mutex_lock(tz-lock);
- list_for_each_entry(pos, tz-cooling_devices, node)
+ list_for_each_entry(pos, tz-thermal_instances, node)
if (pos-tz == tz pos-trip == trip pos-cdev == cdev) {
result = -EEXIST;
break;
}
if (!result)
- list_add_tail(dev-node, tz-cooling_devices);
+ list_add_tail(dev-node, tz-thermal_instances);
mutex_unlock(tz-lock);
if (!result)
@@ -912,7 +912,7 @@ int thermal_zone_unbind_cooling_device(struct
thermal_zone_device *tz,
struct thermal_instance *pos, *next;
mutex_lock(tz-lock);
- list_for_each_entry_safe(pos, next, tz-cooling_devices, node) {
+ list_for_each_entry_safe(pos, next, tz-thermal_instances, node) {
if (pos-tz == tz pos-trip == trip pos-cdev == cdev) {
list_del(pos-node);
mutex_unlock(tz-lock);
@@ -1117,7 +1117,7 @@ static void thermal_zone_trip_update(struct
thermal_zone_device *tz,
}
if (temp = trip_temp) {
- list_for_each_entry(instance, tz-cooling_devices, node) {
+ list_for_each_entry(instance, tz-thermal_instances, node) {
if (instance-trip != trip)
continue;
@@ -1136,7 +1136,7 @@ static void thermal_zone_trip_update(struct
thermal_zone_device *tz,
cdev-ops-set_cur_state(cdev, cur_state);
}
} else {/* below trip */
- list_for_each_entry(instance, tz-cooling_devices, node) {
+ list_for_each_entry(instance, tz-thermal_instances, node) {
if (instance-trip != trip)
continue;
@@ -1365,7 +1365,7 @@ struct thermal_zone_device
*thermal_zone_device_register(const char *type,
if (!tz)
return ERR_PTR(-ENOMEM);
- INIT_LIST_HEAD(tz-cooling_devices);
+ INIT_LIST_HEAD(tz-thermal_instances);
idr_init(tz-idr);
mutex_init(tz-lock);
result = get_idr(thermal_tz_idr, thermal_idr_lock, tz-id);
diff --git a/include/linux/thermal.h b/include/linux/thermal.h
index 38267a5..cb0b0e3 100644
--- a/include/linux/thermal.h
+++ b/include/linux/thermal.h
@@ -122,9 +122,9 @@ struct thermal_zone_device {
bool passive;
unsigned int forced_passive;
const struct thermal_zone_device_ops *ops;
- struct list_head cooling_devices;
+ struct list_head thermal_instances;
struct idr idr;
-
[PATCH 07/30] Thermal: rename structure thermal_cooling_device_instance to thermal_instance
From: Zhang Rui rui.zh...@intel.com
This struct is used to describe the behavior for a thermal
cooling device on a certain trip point for a certain thremal zone.
thermal_cooling_device_instance is not accurate, as a cooling device
can be used for more than one trip point in one thermal zone device.
Signed-off-by: Zhang Rui rui.zh...@intel.com
Reviewed-by: Rafael J. Wysocki r...@sisk.pl
Reviewed-by: Eduardo Valentin eduardo.valen...@ti.com
---
drivers/thermal/thermal_sys.c | 18 +-
1 file changed, 9 insertions(+), 9 deletions(-)
diff --git a/drivers/thermal/thermal_sys.c b/drivers/thermal/thermal_sys.c
index 735e6e6..3eba397 100644
--- a/drivers/thermal/thermal_sys.c
+++ b/drivers/thermal/thermal_sys.c
@@ -46,7 +46,7 @@ MODULE_LICENSE(GPL);
* a certain cooling device on a certain trip point
* in a certain thermal zone
*/
-struct thermal_cooling_device_instance {
+struct thermal_instance {
int id;
char name[THERMAL_NAME_LENGTH];
struct thermal_zone_device *tz;
@@ -430,10 +430,10 @@ static ssize_t
thermal_cooling_device_trip_point_show(struct device *dev,
struct device_attribute *attr, char *buf)
{
- struct thermal_cooling_device_instance *instance;
+ struct thermal_instance *instance;
instance =
- container_of(attr, struct thermal_cooling_device_instance, attr);
+ container_of(attr, struct thermal_instance, attr);
if (instance-trip == THERMAL_TRIPS_NONE)
return sprintf(buf, -1\n);
@@ -716,7 +716,7 @@ static void thermal_zone_device_passive(struct
thermal_zone_device *tz,
int temp, int trip_temp, int trip)
{
enum thermal_trend trend;
- struct thermal_cooling_device_instance *instance;
+ struct thermal_instance *instance;
struct thermal_cooling_device *cdev;
long state, max_state;
@@ -812,8 +812,8 @@ int thermal_zone_bind_cooling_device(struct
thermal_zone_device *tz,
struct thermal_cooling_device *cdev,
unsigned long upper, unsigned long lower)
{
- struct thermal_cooling_device_instance *dev;
- struct thermal_cooling_device_instance *pos;
+ struct thermal_instance *dev;
+ struct thermal_instance *pos;
struct thermal_zone_device *pos1;
struct thermal_cooling_device *pos2;
unsigned long max_state;
@@ -844,7 +844,7 @@ int thermal_zone_bind_cooling_device(struct
thermal_zone_device *tz,
return -EINVAL;
dev =
- kzalloc(sizeof(struct thermal_cooling_device_instance), GFP_KERNEL);
+ kzalloc(sizeof(struct thermal_instance), GFP_KERNEL);
if (!dev)
return -ENOMEM;
dev-tz = tz;
@@ -909,7 +909,7 @@ int thermal_zone_unbind_cooling_device(struct
thermal_zone_device *tz,
int trip,
struct thermal_cooling_device *cdev)
{
- struct thermal_cooling_device_instance *pos, *next;
+ struct thermal_instance *pos, *next;
mutex_lock(tz-lock);
list_for_each_entry_safe(pos, next, tz-cooling_devices, node) {
@@ -1095,7 +1095,7 @@ EXPORT_SYMBOL(thermal_cooling_device_unregister);
static void thermal_zone_trip_update(struct thermal_zone_device *tz,
int trip, long temp)
{
- struct thermal_cooling_device_instance *instance;
+ struct thermal_instance *instance;
struct thermal_cooling_device *cdev = NULL;
unsigned long cur_state, max_state;
long trip_temp;
--
1.8.0.rc1
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 02/30] Thermal: Introduce cooling states range support
From: Zhang Rui rui.zh...@intel.com
As the active cooling devices can have multiple cooling states,
we may want only several cooling states for a certain trip point,
and other cooling states for other active trip points.
To do this, we should be able to describe the cooling device
behavior for a certain trip point, rather than for the entire thermal zone.
And when updating thermal zone, we need to check the upper and lower limit
to make sure the cooling device is set to the proper cooling state.
Note that this patch will not bring any different behavior as
upper limit is set to max_state and lower limit is set to 0
in this patch, for now.
Next patch will set these to real values.
Signed-off-by: Zhang Rui rui.zh...@intel.com
Reviewed-by: Rafael J. Wysocki r...@sisk.pl
Reviewed-by: Eduardo Valentin eduardo.valen...@ti.com
---
drivers/thermal/thermal_sys.c | 25 +
1 file changed, 21 insertions(+), 4 deletions(-)
diff --git a/drivers/thermal/thermal_sys.c b/drivers/thermal/thermal_sys.c
index dc4044b..d78c6dc 100644
--- a/drivers/thermal/thermal_sys.c
+++ b/drivers/thermal/thermal_sys.c
@@ -41,12 +41,19 @@ MODULE_AUTHOR(Zhang Rui);
MODULE_DESCRIPTION(Generic thermal management sysfs support);
MODULE_LICENSE(GPL);
+/*
+ * This structure is used to describe the behavior of
+ * a certain cooling device on a certain trip point
+ * in a certain thermal zone
+ */
struct thermal_cooling_device_instance {
int id;
char name[THERMAL_NAME_LENGTH];
struct thermal_zone_device *tz;
struct thermal_cooling_device *cdev;
int trip;
+ unsigned long upper;/* Highest cooling state for this trip point */
+ unsigned long lower;/* Lowest cooling state for this trip point */
char attr_name[THERMAL_NAME_LENGTH];
struct device_attribute attr;
struct list_head node;
@@ -800,6 +807,7 @@ int thermal_zone_bind_cooling_device(struct
thermal_zone_device *tz,
struct thermal_cooling_device_instance *pos;
struct thermal_zone_device *pos1;
struct thermal_cooling_device *pos2;
+ unsigned long max_state;
int result;
if (trip = tz-trips || (trip 0 trip != THERMAL_TRIPS_NONE))
@@ -824,6 +832,11 @@ int thermal_zone_bind_cooling_device(struct
thermal_zone_device *tz,
dev-tz = tz;
dev-cdev = cdev;
dev-trip = trip;
+
+ cdev-ops-get_max_state(cdev, max_state);
+ dev-upper = max_state;
+ dev-lower = 0;
+
result = get_idr(tz-idr, tz-lock, dev-id);
if (result)
goto free_mem;
@@ -1103,11 +1116,15 @@ void thermal_zone_device_update(struct
thermal_zone_device *tz)
cdev-ops-get_max_state(cdev, max_state);
if (temp = trip_temp)
- cur_state = cur_state max_state ?
- (cur_state + 1) : max_state;
+ cur_state =
+ cur_state instance-upper ?
+ (cur_state + 1) :
+ instance-upper;
else
- cur_state = cur_state 0 ?
- (cur_state - 1) : 0;
+ cur_state =
+ cur_state instance-lower ?
+ (cur_state - 1) :
+ instance-lower;
cdev-ops-set_cur_state(cdev, cur_state);
}
--
1.8.0.rc1
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 04/30] Thermal: Introduce .get_trend() callback.
From: Zhang Rui rui.zh...@intel.com
According to ACPI spec, tc1 and tc2 are used by OSPM
to anticipate the temperature trends.
We introduced the same concept to the generic thermal layer
for passive cooling, but now it seems that these values
are hard to be used on other platforms.
So We introduce .get_trend() as a more general solution.
For the platform thermal drivers that have their own way to
anticipate the temperature trends, they should provide
their own .get_trend() callback.
Or else, we will calculate the temperature trends by simply
comparing the current temperature and the cached previous
temperature reading.
Signed-off-by: Zhang Rui rui.zh...@intel.com
Reviewed-by: Rafael J. Wysocki r...@sisk.pl
Reviewed-by: Valentin, Eduardo eduardo.valen...@ti.com
---
drivers/acpi/thermal.c| 33 +
drivers/thermal/thermal_sys.c | 19 +--
include/linux/thermal.h | 9 +
3 files changed, 59 insertions(+), 2 deletions(-)
diff --git a/drivers/acpi/thermal.c b/drivers/acpi/thermal.c
index d7ef69d..bb95709 100644
--- a/drivers/acpi/thermal.c
+++ b/drivers/acpi/thermal.c
@@ -706,6 +706,38 @@ static int thermal_get_crit_temp(struct
thermal_zone_device *thermal,
return -EINVAL;
}
+static int thermal_get_trend(struct thermal_zone_device *thermal,
+ int trip, enum thermal_trend *trend)
+{
+ struct acpi_thermal *tz = thermal-devdata;
+ enum thermal_trip_type type;
+ int i;
+
+ if (thermal_get_trip_type(thermal, trip, type))
+ return -EINVAL;
+
+ /* Only PASSIVE trip points need TREND */
+ if (type != THERMAL_TRIP_PASSIVE)
+ return -EINVAL;
+
+ /*
+* tz-temperature has already been updated by generic thermal layer,
+* before this callback being invoked
+*/
+ i = (tz-trips.passive.tc1 * (tz-temperature - tz-last_temperature))
+ + (tz-trips.passive.tc2
+ * (tz-temperature - tz-trips.passive.temperature));
+
+ if (i 0)
+ *trend = THERMAL_TREND_RAISING;
+ else if (i 0)
+ *trend = THERMAL_TREND_DROPPING;
+ else
+ *trend = THERMAL_TREND_STABLE;
+ return 0;
+}
+
+
static int thermal_notify(struct thermal_zone_device *thermal, int trip,
enum thermal_trip_type trip_type)
{
@@ -838,6 +870,7 @@ static const struct thermal_zone_device_ops
acpi_thermal_zone_ops = {
.get_trip_type = thermal_get_trip_type,
.get_trip_temp = thermal_get_trip_temp,
.get_crit_temp = thermal_get_crit_temp,
+ .get_trend = thermal_get_trend,
.notify = thermal_notify,
};
diff --git a/drivers/thermal/thermal_sys.c b/drivers/thermal/thermal_sys.c
index b04fe2c..146aa04 100644
--- a/drivers/thermal/thermal_sys.c
+++ b/drivers/thermal/thermal_sys.c
@@ -723,6 +723,20 @@ static void thermal_zone_device_passive(struct
thermal_zone_device *tz,
struct thermal_cooling_device *cdev;
long state, max_state;
+ if (!tz-ops-get_trend ||
+ tz-ops-get_trend(tz, trip, (enum thermal_trend *)trend)) {
+ /*
+* compare the current temperature and previous temperature
+* to get the thermal trend, if no special requirement
+*/
+ if (tz-temperature tz-last_temperature)
+ trend = THERMAL_TREND_RAISING;
+ else if (tz-temperature tz-last_temperature)
+ trend = THERMAL_TREND_DROPPING;
+ else
+ trend = THERMAL_TREND_STABLE;
+ }
+
/*
* Above Trip?
* ---
@@ -1091,6 +1105,9 @@ void thermal_zone_device_update(struct
thermal_zone_device *tz)
goto leave;
}
+ tz-last_temperature = tz-temperature;
+ tz-temperature = temp;
+
for (count = 0; count tz-trips; count++) {
tz-ops-get_trip_type(tz, count, trip_type);
tz-ops-get_trip_temp(tz, count, trip_temp);
@@ -1150,8 +1167,6 @@ void thermal_zone_device_update(struct
thermal_zone_device *tz)
thermal_zone_device_passive(tz, temp, tz-forced_passive,
THERMAL_TRIPS_NONE);
- tz-last_temperature = temp;
-
leave:
if (tz-passive)
thermal_zone_device_set_polling(tz, tz-passive_delay);
diff --git a/include/linux/thermal.h b/include/linux/thermal.h
index 5946a3b..6a1d43d 100644
--- a/include/linux/thermal.h
+++ b/include/linux/thermal.h
@@ -44,6 +44,12 @@ enum thermal_trip_type {
THERMAL_TRIP_CRITICAL,
};
+enum thermal_trend {
+ THERMAL_TREND_STABLE, /* temperature is stable */
+ THERMAL_TREND_RAISING, /* temperature is raising */
+ THERMAL_TREND_DROPPING, /* temperature is dropping */
+};
+
struct thermal_zone_device_ops {
int
Re: [RFC v9 PATCH 00/21] memory-hotplug: hot-remove physical memory
At 09/27/2012 12:46 AM, Vasilis Liaskovitis Wrote: Hi, I am testing 3.6.0-rc7 with this v9 patchset plus more recent fixes [1],[2],[3] Running in a guest (qemu+seabios from [4]). CONFIG_SLAB=y CONFIG_DEBUG_SLAB=y After succesfull hot-add and online, I am doing a hot-remove with echo 1 /sys/bus/acpi/devices/PNP/eject When I do the OSPM-eject, I often get slab corruption in acpi-state cache, or in other caches I found the reason: when you do OSPM-eject, the kernel will auto offline and remove the memory. But, offlining memory fails, and the memory is still used by the kernel. But device_release_driver() doesn't tell this error to the caller acpi_bus_remove(). The kernel will poweroff and eject the device by emulate _PS3 and _EJ0. The kernel uses some memory which doesn't exist. It's very dangerous. Thanks Wen Conyang [ 170.566995] Slab corruption (Not tainted): Acpi-State start=88009fc1e548, len=80 [ 170.567265] Redzone: 0x0/0x0. [ 170.567399] Last user: [ (null)](0x0) [ 170.567667] 000: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [ 170.568078] 010: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [ 170.568487] 020: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [ 170.568894] 030: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [ 170.569302] 040: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [ 170.569712] Prev obj: start=9fc1e4d0, len=80 [ 170.569869] BUG: unable to handle kernel paging request at 9fc1e520 [ 170.570171] IP: [8112803c] print_objinfo+0x9c/0x110 [ 170.570397] PGD 7cf37067 PUD 0 [ 170.570619] Oops: [#1] SMP [ 170.570843] Modules linked in: netconsole acpiphp pci_hotplug acpi_memhotplug loop kvm_amd kvm tpm_tis microcode tpm tpm_bios psmouse parport_pc serio_raw evdev parport i2c_piix4 processor thermal_sys i2c_core button ext3 jbd mbcache sg sr_mod cdrom ata_generic virtio_net virtio_blk ata_piix libata scsi_mod virtio_pci virtio_ring virtio [ 170.573474] CPU 0 [ 170.573568] Pid: 29, comm: kworker/0:1 Not tainted 3.6.0-rc7-guest #12 Bochs Bochs [ 170.573830] RIP: 0010:[8112803c] [8112803c] print_objinfo+0x9c/0x110 [ 170.574106] RSP: 0018:88003eaf3a70 EFLAGS: 00010202 [ 170.574268] RAX: 9fc1e4c8 RBX: 0002 RCX: 24b8 [ 170.574468] RDX: 9fc1e4c8 RSI: 9fc1e4c8 RDI: 88003e9bb980 [ 170.574668] RBP: 88003e9bb980 R08: 880037964078 R09: [ 170.574870] R10: 021e R11: 0002 R12: 9fc1e4c8 [ 170.575070] R13: 9fc1e520 R14: 004f R15: ffa5 [ 170.575274] FS: 7fc6b7530700() GS:88003fc0() knlGS: [ 170.575494] CS: 0010 DS: ES: CR0: 8005003b [ 170.575665] CR2: 9fc1e520 CR3: 7c9c1000 CR4: 06f0 [ 170.575870] DR0: DR1: DR2: [ 170.576075] DR3: DR6: 0ff0 DR7: 0400 [ 170.576276] Process kworker/0:1 (pid: 29, threadinfo 88003eaf2000, task 88003ea941c0) [ 170.576507] Stack: [ 170.576599] 0010 01893fbe 88009fc1e000 0050 [ 170.576938] 9fc1e4c8 004f ffa5 8112899f [ 170.576938] 88003eb309d8 81712d6d 88003e9bb980 88009fc1e540 [ 170.576938] Call Trace: [ 170.576938] [8112899f] ? check_poison_obj+0x1df/0x1f0 [ 170.576938] [813047d0] ? acpi_ut_create_generic_state+0x2f/0x4c [ 170.576938] [813047d0] ? acpi_ut_create_generic_state+0x2f/0x4c [ 170.576938] [81128a9d] ? cache_alloc_debugcheck_after.isra.52+0xed/0x220 [ 170.576938] [813047d0] ? acpi_ut_create_generic_state+0x2f/0x4c [ 170.576938] [8112beb5] ? kmem_cache_alloc+0xb5/0x1e0 [ 170.576938] [813047d0] ? acpi_ut_create_generic_state+0x2f/0x4c [ 170.576938] [812edf2d] ? acpi_ds_result_push+0x5d/0x12e [ 170.576938] [812ed127] ? acpi_ds_exec_end_op+0x28e/0x3d3 [ 170.576938] [812fd86a] ? acpi_ps_parse_loop+0x79f/0x931 [ 170.576938] [812fdd6c] ? acpi_ps_parse_aml+0x89/0x261 [ 170.576938] [812fe50c] ? acpi_ps_execute_method+0x1be/0x266 [ 170.576938] [812f91f7] ? acpi_ns_evaluate+0xd3/0x19a [ 170.576938] [812fb93e] ? acpi_evaluate_object+0xf3/0x1f4 [ 170.576938] [812e1104] ? acpi_os_wait_events_complete+0x1b/0x1b [ 170.576938] [812e4782] ? acpi_bus_hot_remove_device+0xeb/0x123 [ 170.576938] [812e1121] ? acpi_os_execute_deferred+0x1d/0x29 [ 170.576938] [81058ec5] ? process_one_work+0x125/0x560 [ 170.576938] [81059e7a] ? worker_thread+0x16a/0x4e0 [ 170.576938]
[PATCH 03/30] Thermal: set upper and lower limits
From: Zhang Rui rui.zh...@intel.com
set upper and lower limits when binding
a thermal cooling device to a thermal zone device.
Signed-off-by: Zhang Rui rui.zh...@intel.com
Reviewed-by: Rafael J. Wysocki r...@sisk.pl
Reviewed-by: Eduardo Valentin eduardo.valen...@ti.com
---
Documentation/thermal/sysfs-api.txt | 9 ++-
drivers/acpi/thermal.c | 53 -
drivers/platform/x86/acerhdf.c | 3 ++-
drivers/thermal/thermal_sys.c | 23 +++-
include/linux/thermal.h | 5 +++-
5 files changed, 65 insertions(+), 28 deletions(-)
diff --git a/Documentation/thermal/sysfs-api.txt
b/Documentation/thermal/sysfs-api.txt
index c087dbc..ca1a1a3 100644
--- a/Documentation/thermal/sysfs-api.txt
+++ b/Documentation/thermal/sysfs-api.txt
@@ -84,7 +84,8 @@ temperature) and throttle appropriate devices.
1.3 interface for binding a thermal zone device with a thermal cooling device
1.3.1 int thermal_zone_bind_cooling_device(struct thermal_zone_device *tz,
- int trip, struct thermal_cooling_device *cdev);
+ int trip, struct thermal_cooling_device *cdev,
+ unsigned long upper, unsigned long lower);
This interface function bind a thermal cooling device to the certain trip
point of a thermal zone device.
@@ -93,6 +94,12 @@ temperature) and throttle appropriate devices.
cdev: thermal cooling device
trip: indicates which trip point the cooling devices is associated with
in this thermal zone.
+upper:the Maximum cooling state for this trip point.
+ THERMAL_NO_LIMIT means no upper limit,
+ and the cooling device can be in max_state.
+lower:the Minimum cooling state can be used for this trip point.
+ THERMAL_NO_LIMIT means no lower limit,
+ and the cooling device can be in cooling state 0.
1.3.2 int thermal_zone_unbind_cooling_device(struct thermal_zone_device *tz,
int trip, struct thermal_cooling_device *cdev);
diff --git a/drivers/acpi/thermal.c b/drivers/acpi/thermal.c
index 9fe90e9..d7ef69d 100644
--- a/drivers/acpi/thermal.c
+++ b/drivers/acpi/thermal.c
@@ -729,11 +729,9 @@ static int thermal_notify(struct thermal_zone_device
*thermal, int trip,
return 0;
}
-typedef int (*cb)(struct thermal_zone_device *, int,
- struct thermal_cooling_device *);
static int acpi_thermal_cooling_device_cb(struct thermal_zone_device *thermal,
struct thermal_cooling_device *cdev,
- cb action)
+ bool bind)
{
struct acpi_device *device = cdev-devdata;
struct acpi_thermal *tz = thermal-devdata;
@@ -757,11 +755,19 @@ static int acpi_thermal_cooling_device_cb(struct
thermal_zone_device *thermal,
i++) {
handle = tz-trips.passive.devices.handles[i];
status = acpi_bus_get_device(handle, dev);
- if (ACPI_SUCCESS(status) (dev == device)) {
- result = action(thermal, trip, cdev);
- if (result)
- goto failed;
- }
+ if (ACPI_FAILURE(status) || dev != device)
+ continue;
+ if (bind)
+ result =
+ thermal_zone_bind_cooling_device
+ (thermal, trip, cdev,
+THERMAL_NO_LIMIT, THERMAL_NO_LIMIT);
+ else
+ result =
+ thermal_zone_unbind_cooling_device
+ (thermal, trip, cdev);
+ if (result)
+ goto failed;
}
}
@@ -774,11 +780,17 @@ static int acpi_thermal_cooling_device_cb(struct
thermal_zone_device *thermal,
j++) {
handle = tz-trips.active[i].devices.handles[j];
status = acpi_bus_get_device(handle, dev);
- if (ACPI_SUCCESS(status) (dev == device)) {
- result = action(thermal, trip, cdev);
- if (result)
- goto failed;
- }
+ if (ACPI_FAILURE(status) || dev != device)
+ continue;
+ if (bind)
+ result = thermal_zone_bind_cooling_device
+ (thermal, trip, cdev,
+THERMAL_NO_LIMIT, THERMAL_NO_LIMIT);
+ else
+ result = thermal_zone_unbind_cooling_device
+
Re: [PATCH 08/10] x86, xen, mm: fix mapping_pagetable_reserve logic
On 10/09/2012 12:39 PM, Yinghai Lu wrote:
*/
struct x86_init_mapping {
- void (*pagetable_reserve)(u64 start, u64 end);
+ void (*make_range_readwrite)(u64 start, u64 end);
};
Here you go from one misleading name to another. Another classic case
of why hooks suck.
make_range_readwrite is particularly toxic, though, because it makes it
sound like it something along the lines of set_memory_rw(), which it
most distinctly is not.
Furthermore, the naming makes me really puzzled why it is there at all.
It makes me suspect, but because the patchset is so messy, it is hard
for me to immediately prove, that you're still missing something important.
However, for example:
unsigned long __initdata pgt_buf_start;
unsigned long __meminitdata pgt_buf_end;
unsigned long __meminitdata pgt_buf_top;
+unsigned long __initdata early_pgt_buf_start;
+unsigned long __meminitdata early_pgt_buf_end;
+unsigned long __meminitdata early_pgt_buf_top;
bool __init is_pfn_in_early_pgt_buf(unsigned long pfn)
{
- return pfn = pgt_buf_start pfn pgt_buf_top;
+ return (pfn = early_pgt_buf_start pfn early_pgt_buf_top) ||
+(pfn = pgt_buf_start pfn pgt_buf_top);
}
Magic variables augmented with more magic variables. Why? This also
seems to assume that we still do all the kernel page tables in one
chunk, which is exactly what we don't want to do.
-hpa
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH] ubi: use list_move_tail instead of list_del/list_add_tail
From: Wei Yongjun yongjun_...@trendmicro.com.cn
Using list_move_tail() instead of list_del() + list_add_tail().
dpatch engine is used to auto generate this patch.
(https://github.com/weiyj/dpatch)
Signed-off-by: Wei Yongjun yongjun_...@trendmicro.com.cn
---
drivers/mtd/ubi/fastmap.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/drivers/mtd/ubi/fastmap.c b/drivers/mtd/ubi/fastmap.c
index 1a5f53c..5f540c5 100644
--- a/drivers/mtd/ubi/fastmap.c
+++ b/drivers/mtd/ubi/fastmap.c
@@ -815,8 +815,7 @@ static int ubi_attach_fastmap(struct ubi_device *ubi,
ai-max_sqnum = max_sqnum;
list_for_each_entry_safe(tmp_aeb, _tmp_aeb, free, u.list) {
- list_del(tmp_aeb-u.list);
- list_add_tail(tmp_aeb-u.list, ai-free);
+ list_move_tail(tmp_aeb-u.list, ai-free);
}
/*
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@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] regulator: TPS51632: Add tps51632 regulator driver
On Sat, Oct 06, 2012 at 08:47:46PM +0530, Laxman Dewangan wrote: Actually... + if (pdata-dvfs_step_20mV) + control |= TPS51632_DVFS_STEP_20; + tps-desc.uV_step = TPS51632_VOLATGE_STEP_10mV; Shouldn't the dvfs_step_20mV setting affect the uV_step size? -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@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 27/30] ACPI: EC: Add a quirk for CLEVO M720T/M730T laptop
Len Brown wrote: By enlarging the GPE storm threshold back to 20, that laptop's EC works fine with interrupt mode instead of polling mode. What would go wrong if the threshold were just increased to 20 on all models? Thanks, Jonathan -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@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: [bisected] PS/2 keyboard and mouse dead on resume on Intel D845BG
On Tuesday 09 October 2012, Len Brown wrote: On 10/08/2012 10:42 AM, Matthew Garrett wrote: On Sun, Oct 07, 2012 at 09:00:09PM +0200, Ondrej Zary wrote: Added acpi_read_bit_register there and it seems that SCI_EN is already set! This patch fixes the problem here. I wonder how this affects systems that require SCI_EN to be set. I /think/ that this will be safe, but it doesn't match my recollection of how Windows behaves so it may break something. Any chance you can find someone with one of the machines mentioned in https://bugzilla.kernel.org/show_bug.cgi?id=13745 and make sure that they still work with your patch? yikes. we started with a white-list, then we made setting SCI_EN the default, and here is at least one box that wants to be on a black list so that we don't set SCI_EN:-( I wonder what Windows does here. Haven't tested it on this machine but I assume that it works. -- Ondrej Zary -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 0/6] AMD MCE injection improvs
On Mon, Oct 08, 2012 at 04:58:34PM -0700, Tony Luck wrote: On Mon, Oct 8, 2012 at 10:11 AM, Borislav Petkov b...@amd64.org wrote: create mode 100644 arch/x86/ras/ras.c Overall it looks good - but I'm a bit puzzled by this ras.c file that gets created as an empty file in part1, and is still empty at the end of the series. What is going to go into it? Yeah, maybe it should be called core.c and all the shared functionality would go there. I put it there initially for the first patch but I realize now, we won't need it just yet - I'll drop it. Thanks. -- Regards/Gruss, Boris. Advanced Micro Devices GmbH Einsteinring 24, 85609 Dornach GM: Alberto Bozzo Reg: Dornach, Landkreis Muenchen HRB Nr. 43632 WEEE Registernr: 129 19551 -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@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] ext3: fix return values on parse_options() failure
On Tue, 9 Oct 2012, Zhao Hongjiang wrote:
Date: Tue, 09 Oct 2012 13:48:47 +0800
From: Zhao Hongjiang zhaohongjian...@gmail.com
To: j...@suse.cz
Cc: a...@linux-foundation.org, adilger.ker...@dilger.ca,
linux-e...@vger.kernel.org, linux-kernel@vger.kernel.org,
Eric W. Biederman ebied...@xmission.com, serge.hal...@canonical.com,
contain...@lists.linux-foundation.org
Subject: [PATCH] ext3: fix return values on parse_options() failure
From: Zhao Hongjiang zhaohongji...@huawei.com
parse_options() in ext3 should return 0 when parse the mount options fails.
Ah, it really is a joy to read the parse_options() :). But this fix
makes sense, thanks for catching it.
Reviewed-by: Lukas Czerner lczer...@redhat.com
-Lukas
Signed-off-by: Zhao Hongjiang zhaohongji...@huawei.com
---
fs/ext3/super.c |4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/fs/ext3/super.c b/fs/ext3/super.c
index 17ae5c8..ebf8312 100644
--- a/fs/ext3/super.c
+++ b/fs/ext3/super.c
@@ -1001,7 +1001,7 @@ static int parse_options (char *options, struct
super_block *sb,
uid = make_kuid(current_user_ns(), option);
if (!uid_valid(uid)) {
ext3_msg(sb, KERN_ERR, Invalid uid value %d,
option);
- return -1;
+ return 0;
}
sbi-s_resuid = uid;
@@ -1012,7 +1012,7 @@ static int parse_options (char *options, struct
super_block *sb,
gid = make_kgid(current_user_ns(), option);
if (!gid_valid(gid)) {
ext3_msg(sb, KERN_ERR, Invalid gid value %d,
option);
- return -1;
+ return 0;
}
sbi-s_resgid = gid;
break;
-- 1.7.1
--
To unsubscribe from this list: send the line unsubscribe linux-ext4 in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/2] ARM: OMAP: Trivial driver changes to remove include plat/cpu.h
On Mon, 08 Oct 2012 10:35:57 -0700 Tony Lindgren t...@atomide.com wrote: - omap-dma.c and omap-pcm.c can test the arch locally as omap1 and omap2 cannot be compiled together because of conflicting compiler flags ... sound/soc/omap/omap-pcm.c |9 +++-- Build tested above for omap1 and omap2+. Acked-by: Jarkko Nikula jarkko.nik...@bitmer.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 -v2 00/10] x86: Use BRK to pre mapping page table to make xen happy
On Mon, Oct 8, 2012 at 11:07 PM, H. Peter Anvin h...@zytor.com wrote: On 10/09/2012 12:39 PM, Yinghai Lu wrote: on top of tip/x86/mm2 Hi Yinghai, This patchset doesn't apply on top of tip:x86/mm2, starting at patch 08/10. sorry for that. I refresh my base to current linus/master and tip/master. could be some change there. could solve it: 1. update x86/mm2 to linus/master 2. or i resend the patch again with x86/mm2 as base. please let me know which one you like. Furthermore, a lot of the descriptions are both incomplete and incomprehensible, which makes the patchset very very hard to review. You should think of the descriptions as writing a (short) paper on your patchset, where you describe not just what you are doing, but how you accomplish the objective and why that objective is the right thing do accomplish. Actually I spent a while on the changelog of this patchset. will spend more time for next reversion. Overall, this patchset seems to be going in the right direction, but I have several concerns with details. good, will update the patches accordingly. Thanks Yinghai -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Do not use cpu_to_node() to find an offlined cpu's node.
On Mon, 8 Oct 2012, Tang Chen wrote:
diff --git a/kernel/sched/core.c b/kernel/sched/core.c
index 66b36ab..e76dce9 100644
--- a/kernel/sched/core.c
+++ b/kernel/sched/core.c
@@ -1263,18 +1263,24 @@ EXPORT_SYMBOL_GPL(kick_process);
*/
static int select_fallback_rq(int cpu, struct task_struct *p)
{
- const struct cpumask *nodemask = cpumask_of_node(cpu_to_node(cpu));
+ int nid = cpu_to_node(cpu);
+ const struct cpumask *nodemask = NULL;
enum { cpuset, possible, fail } state = cpuset;
int dest_cpu;
- /* Look for allowed, online CPU in same node. */
- for_each_cpu(dest_cpu, nodemask) {
- if (!cpu_online(dest_cpu))
- continue;
- if (!cpu_active(dest_cpu))
- continue;
- if (cpumask_test_cpu(dest_cpu, tsk_cpus_allowed(p)))
- return dest_cpu;
+ /* If the cpu has been offlined, its nid was set to -1. */
+ if (nid != -1) {
NUMA_NO_NODE.
Eek, the nid shouldn't be -1 yet, though, for cpu hotplug since this
should be called at CPU_DYING level and migrate_tasks() still sees a valid
cpu.
On x86, cpumask_of_node() is always guaranteed to return a valid cpumask
after boot so presumably this is a problem in some non-x86 arch code and
isn't actually a sched problem.
+ nodemask = cpumask_of_node(nid);
+
+ /* Look for allowed, online CPU in same node. */
+ for_each_cpu(dest_cpu, nodemask) {
+ if (!cpu_online(dest_cpu))
+ continue;
+ if (!cpu_active(dest_cpu))
+ continue;
+ if (cpumask_test_cpu(dest_cpu, tsk_cpus_allowed(p)))
+ return dest_cpu;
+ }
}
for (;;) {
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/3] mfd: Convert tps6586x to irq_domain
On Tuesday 09 October 2012 11:36 AM, Mark Brown wrote: On Mon, Oct 08, 2012 at 09:43:23PM +0530, Laxman Dewangan wrote: Allocate the irq base if it base is not porvided i.e. in case of device tree invocation of this driver. Convert the tps6586x driver to irq domain, using a legacy IRQ mapping if an irq_base is specified in platform data or dynamically allocated and otherwise using a linear mapping. Reviewed-by: Mark Brownbroo...@opensource.wolfsonmicro.com but can you convert to regmap_irq? Yes, the motivation was this when I started this cleanups but found that there is 4 interrupt status and 5 interrupt mask register. Probably we need to pass the number of interrupt status and interrupt mask register to expand the regmap-irq framework to handle this case also. If it is fine then I can work towards that. -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2/5] regulator; tps65090: Register all regulators in single probe call
On Sat, Oct 06, 2012 at 08:47:48PM +0530, Laxman Dewangan wrote:
MFD drier registers the regulator driver once per device and
hence it is require to register all regulators in single probe
call.
Following are details of changes done to achieve this:
- Add max regulator and register all regulators even if there
is no regulator init data from platform.
- Convert regulator init data to pointer type in platform data.
- Add input supply name in regulator desc to provide input supply.
- Separate desc information from driver information.
Shouldn't this be the first commit in the series? Also...
+ for (num = 0; num TPS65090_REGULATOR_MAX; num++) {
+ tps_pdata = tps65090_pdata-reg_pdata[num];
struct tps65090_regulator_platform_data {
- struct regulator_init_data regulator;
+ struct regulator_init_data *reg_init_data;
};
I can't help but think that if we're going to require the full array
here the array should just be declared immediately - perhaps as an array
of pointers:
struct regulator_init_data *reg_init_data[TPS65090_REGULATOR_MAX];
to allow things to be missed out. Otherwise we're likely to crash if
the user misses a regulator or something.
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/3] mfd: Convert tps6586x to irq_domain
On Tue, Oct 09, 2012 at 11:18:24AM +0530, Laxman Dewangan wrote: On Tuesday 09 October 2012 11:36 AM, Mark Brown wrote: but can you convert to regmap_irq? Yes, the motivation was this when I started this cleanups but found that there is 4 interrupt status and 5 interrupt mask register. Probably we need to pass the number of interrupt status and interrupt mask register to expand the regmap-irq framework to handle this case also. If it is fine then I can work towards that. Can you explain in more detail - I guess there's a different mapping of the bits into the registers for mask and status (in which case the generic code just won't work anyway). -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@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 00/10] x86: Use BRK to pre mapping page table to make xen happy
On 10/09/2012 02:21 PM, Yinghai Lu wrote: Hi Yinghai, This patchset doesn't apply on top of tip:x86/mm2, starting at patch 08/10. sorry for that. I refresh my base to current linus/master and tip/master. could be some change there. could solve it: 1. update x86/mm2 to linus/master 2. or i resend the patch again with x86/mm2 as base. please let me know which one you like. If it doesn't have cross-dependencies on other code, x86/mm2 is probably the best base; if there are other dependencies then that's fine, but we need to know what they are. We don't want to create unnecessary tangles among topic branches, it makes Linus very unhappy. -hpa -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 4/5] regulator: tps65090: Add voltage out level in platform data
On Sat, Oct 06, 2012 at 08:47:50PM +0530, Laxman Dewangan wrote: TPS65090's DCDCs and FETs act as switch and so output voltage can be enable or disable only. The output voltage of this regulators depends on the input voltage. Add the voltage parameter to tell the output voltage value of these rails. This should be using the recently added bypass support - the regualtors should arrange to always report themselves as bypass (in the case of the FETs, I'm not 100% sure what you mean for the DCDCs...) and the framework should be reporting the input voltage for regulators in bypass mode. -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 5/5] regulator: tps65090: add external control support for DCDC
On Sat, Oct 06, 2012 at 08:47:51PM +0530, Laxman Dewangan wrote: The TPS65090's DCDC outut can also be enable/disable through the external digital input signal. Add support for enable/disable either through register access via I2C or through external control inputs. The external control inputs can be driven through GPIOs also and hence adding support for passing the GPIO number. There's support for GPIO driven enable lines in the framework already, this driver should be able to use this happily, this sort of hardware is exactly the use case it was written for. -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@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 27/30] ACPI: EC: Add a quirk for CLEVO M720T/M730T laptop
Hi Jonathan, On Tue, 9 Oct 2012 14:16:33 +0800 Jonathan Nieder jrnie...@gmail.com wrote: Len Brown wrote: By enlarging the GPE storm threshold back to 20, that laptop's EC works fine with interrupt mode instead of polling mode. What would go wrong if the threshold were just increased to 20 on all models? Then some other platform will stop to work. https://bugzilla.kernel.org/show_bug.cgi?id=11892 The 26/30 and 27/30 patches are bound together to fix one bug. Some quote from description from the 26th patch: ACPI_EC_STORM_THRESHOLD was initially 20 when it's created, and was changed to 8 in 2.6.28 commit 06cf7d3c7 ACPI: EC: lower interrupt storm threshold to fix kernel bug 11892 by forcing the laptop in that bug to work in polling mode. Hope this answers your question. Thanks, Feng -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@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 08/10] x86, xen, mm: fix mapping_pagetable_reserve logic
On Mon, Oct 8, 2012 at 11:12 PM, H. Peter Anvin h...@zytor.com wrote:
On 10/09/2012 12:39 PM, Yinghai Lu wrote:
*/
struct x86_init_mapping {
- void (*pagetable_reserve)(u64 start, u64 end);
+ void (*make_range_readwrite)(u64 start, u64 end);
};
Here you go from one misleading name to another. Another classic case
of why hooks suck.
Run out of idea to have name for it.
make_range_readwrite is particularly toxic, though, because it makes it
sound like it something along the lines of set_memory_rw(), which it
most distinctly is not.
it just change some page range from RO back to RW.
so how about update_range_ro_to_rw?
Furthermore, the naming makes me really puzzled why it is there at all.
It makes me suspect, but because the patchset is so messy, it is hard
for me to immediately prove, that you're still missing something important.
However, for example:
unsigned long __initdata pgt_buf_start;
unsigned long __meminitdata pgt_buf_end;
unsigned long __meminitdata pgt_buf_top;
+unsigned long __initdata early_pgt_buf_start;
+unsigned long __meminitdata early_pgt_buf_end;
+unsigned long __meminitdata early_pgt_buf_top;
bool __init is_pfn_in_early_pgt_buf(unsigned long pfn)
{
- return pfn = pgt_buf_start pfn pgt_buf_top;
+ return (pfn = early_pgt_buf_start pfn early_pgt_buf_top) ||
+(pfn = pgt_buf_start pfn pgt_buf_top);
}
Magic variables augmented with more magic variables. Why? This also
seems to assume that we still do all the kernel page tables in one
chunk, which is exactly what we don't want to do.
for 64bit, page table will be three parts
1. initial page table from arch/x86/kernel/head_64.S
2. page table from BRK.
3. page near end of RAM.
verified from /sys/kernel/debug/kernel_page_tables
only range E820_RAM is mapped.
all initial page table for hole between [0, 1G) get cleared too.
Thanks
Yinghai
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2 2/6] Add the main bulk of core driver for SI476x code
On Fri, Oct 05, 2012 at 06:54:58PM -0700, Andrey Smirnov wrote: + err = regulator_enable(core-supplies.va); + if (err 0) + break; + + err = regulator_enable(core-supplies.vio2); + if (err 0) + goto disable_va; + + err = regulator_enable(core-supplies.vd); + if (err 0) + goto disable_vio2; + + err = regulator_enable(core-supplies.vio1); + if (err 0) + goto disable_vd; If the sequencing is critical here you should have comments explaining what the requirement is, otherwise this looks like a prime candidate for conversion to regulator_bulk_enable() (and similarly for all the other regulator usage, it appears that all the regulators are worked with in a bulk fashion). -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2 6/6] Add a codec driver for SI476X MFD
On Fri, Oct 05, 2012 at 06:55:02PM -0700, Andrey Smirnov wrote: This commit add a sound codec driver for Silicon Laboratories 476x series of AM/FM radio chips. Applied, thanks. -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/3] mfd: Convert tps6586x to irq_domain
On Tuesday 09 October 2012 11:53 AM, Mark Brown wrote: On Tue, Oct 09, 2012 at 11:18:24AM +0530, Laxman Dewangan wrote: On Tuesday 09 October 2012 11:36 AM, Mark Brown wrote: but can you convert to regmap_irq? Yes, the motivation was this when I started this cleanups but found that there is 4 interrupt status and 5 interrupt mask register. Probably we need to pass the number of interrupt status and interrupt mask register to expand the regmap-irq framework to handle this case also. If it is fine then I can work towards that. Can you explain in more detail - I guess there's a different mapping of the bits into the registers for mask and status (in which case the generic code just won't work anyway). The bit definitions are also different in status and mask register and yes, this will be again problem as we do in isr thread data-status_buf[i] = ~data-mask_buf[i]; So given the constraint, generic will not work here. -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 1/5] aio: Kill return value of aio_complete()
Nothing used the return value, and it probably wasn't possible to use it
safely for the locked versions (aio_complete(), aio_put_req()). Just
kill it.
Signed-off-by: Kent Overstreet koverstr...@google.com
---
fs/aio.c| 19 +++
include/linux/aio.h |8
2 files changed, 11 insertions(+), 16 deletions(-)
diff --git a/fs/aio.c b/fs/aio.c
index 71f613c..1ad2d97 100644
--- a/fs/aio.c
+++ b/fs/aio.c
@@ -548,7 +548,7 @@ static inline void really_put_req(struct kioctx *ctx,
struct kiocb *req)
/* __aio_put_req
* Returns true if this put was the last user of the request.
*/
-static int __aio_put_req(struct kioctx *ctx, struct kiocb *req)
+static void __aio_put_req(struct kioctx *ctx, struct kiocb *req)
{
dprintk(KERN_DEBUG aio_put(%p): f_count=%ld\n,
req, atomic_long_read(req-ki_filp-f_count));
@@ -558,7 +558,7 @@ static int __aio_put_req(struct kioctx *ctx, struct kiocb
*req)
req-ki_users--;
BUG_ON(req-ki_users 0);
if (likely(req-ki_users))
- return 0;
+ return;
list_del(req-ki_list);/* remove from active_reqs */
req-ki_cancel = NULL;
req-ki_retry = NULL;
@@ -566,21 +566,18 @@ static int __aio_put_req(struct kioctx *ctx, struct kiocb
*req)
fput(req-ki_filp);
req-ki_filp = NULL;
really_put_req(ctx, req);
- return 1;
}
/* aio_put_req
* Returns true if this put was the last user of the kiocb,
* false if the request is still in use.
*/
-int aio_put_req(struct kiocb *req)
+void aio_put_req(struct kiocb *req)
{
struct kioctx *ctx = req-ki_ctx;
- int ret;
spin_lock_irq(ctx-ctx_lock);
- ret = __aio_put_req(ctx, req);
+ __aio_put_req(ctx, req);
spin_unlock_irq(ctx-ctx_lock);
- return ret;
}
EXPORT_SYMBOL(aio_put_req);
@@ -889,7 +886,7 @@ EXPORT_SYMBOL(kick_iocb);
* Returns true if this is the last user of the request. The
* only other user of the request can be the cancellation code.
*/
-int aio_complete(struct kiocb *iocb, long res, long res2)
+void aio_complete(struct kiocb *iocb, long res, long res2)
{
struct kioctx *ctx = iocb-ki_ctx;
struct aio_ring_info*info;
@@ -897,7 +894,6 @@ int aio_complete(struct kiocb *iocb, long res, long res2)
struct io_event *event;
unsigned long flags;
unsigned long tail;
- int ret;
/*
* Special case handling for sync iocbs:
@@ -911,7 +907,7 @@ int aio_complete(struct kiocb *iocb, long res, long res2)
iocb-ki_user_data = res;
iocb-ki_users = 0;
wake_up_process(iocb-ki_obj.tsk);
- return 1;
+ return;
}
info = ctx-ring_info;
@@ -973,7 +969,7 @@ int aio_complete(struct kiocb *iocb, long res, long res2)
put_rq:
/* everything turned out well, dispose of the aiocb. */
- ret = __aio_put_req(ctx, iocb);
+ __aio_put_req(ctx, iocb);
/*
* We have to order our ring_info tail store above and test
@@ -987,7 +983,6 @@ put_rq:
wake_up(ctx-wait);
spin_unlock_irqrestore(ctx-ctx_lock, flags);
- return ret;
}
EXPORT_SYMBOL(aio_complete);
diff --git a/include/linux/aio.h b/include/linux/aio.h
index 31ff6db..4cde86d 100644
--- a/include/linux/aio.h
+++ b/include/linux/aio.h
@@ -211,18 +211,18 @@ extern unsigned aio_max_size;
#ifdef CONFIG_AIO
extern ssize_t wait_on_sync_kiocb(struct kiocb *iocb);
-extern int aio_put_req(struct kiocb *iocb);
+extern void aio_put_req(struct kiocb *iocb);
extern void kick_iocb(struct kiocb *iocb);
-extern int aio_complete(struct kiocb *iocb, long res, long res2);
+extern void aio_complete(struct kiocb *iocb, long res, long res2);
struct mm_struct;
extern void exit_aio(struct mm_struct *mm);
extern long do_io_submit(aio_context_t ctx_id, long nr,
struct iocb __user *__user *iocbpp, bool compat);
#else
static inline ssize_t wait_on_sync_kiocb(struct kiocb *iocb) { return 0; }
-static inline int aio_put_req(struct kiocb *iocb) { return 0; }
+static inline void aio_put_req(struct kiocb *iocb) { }
static inline void kick_iocb(struct kiocb *iocb) { }
-static inline int aio_complete(struct kiocb *iocb, long res, long res2) {
return 0; }
+static inline void aio_complete(struct kiocb *iocb, long res, long res2) { }
struct mm_struct;
static inline void exit_aio(struct mm_struct *mm) { }
static inline long do_io_submit(aio_context_t ctx_id, long nr,
--
1.7.10.4
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 4/5] aio: vmap ringbuffer
It simplifies a lot of stuff if the ringbuffer is contiguously mapped
into kernel space, and we can delete a lot of code - in particular, this
is useful for converting read_events() to cmpxchg.
It'd make more sense if the ringbuffer was allocated with
__get_free_pages() and then mapped into userspace, but I couldn't figure
out how to sanely do that... so vmap works for now.
Signed-off-by: Kent Overstreet koverstr...@google.com
---
fs/aio.c| 85 +--
include/linux/aio.h |7 +++--
2 files changed, 32 insertions(+), 60 deletions(-)
diff --git a/fs/aio.c b/fs/aio.c
index 3ab12f6..c3d97d1 100644
--- a/fs/aio.c
+++ b/fs/aio.c
@@ -82,6 +82,9 @@ static void aio_free_ring(struct kioctx *ctx)
struct aio_ring_info *info = ctx-ring_info;
long i;
+ if (info-ring)
+ vunmap(info-ring);
+
for (i=0; iinfo-nr_pages; i++)
put_page(info-ring_pages[i]);
@@ -99,7 +102,6 @@ static void aio_free_ring(struct kioctx *ctx)
static int aio_setup_ring(struct kioctx *ctx)
{
- struct aio_ring *ring;
struct aio_ring_info *info = ctx-ring_info;
unsigned nr_events = ctx-max_reqs;
unsigned long size;
@@ -149,46 +151,27 @@ static int aio_setup_ring(struct kioctx *ctx)
return -EAGAIN;
}
+ info-ring = vmap(info-ring_pages, nr_pages, VM_MAP, PAGE_KERNEL);
+ if (!info-ring) {
+ aio_free_ring(ctx);
+ return -ENOMEM;
+ }
+
ctx-user_id = info-mmap_base;
info-nr = nr_events; /* trusted copy */
- ring = kmap_atomic(info-ring_pages[0]);
- ring-nr = nr_events; /* user copy */
- ring-id = ctx-user_id;
- ring-head = ring-tail = 0;
- ring-magic = AIO_RING_MAGIC;
- ring-compat_features = AIO_RING_COMPAT_FEATURES;
- ring-incompat_features = AIO_RING_INCOMPAT_FEATURES;
- ring-header_length = sizeof(struct aio_ring);
- kunmap_atomic(ring);
+ info-ring-nr = nr_events; /* user copy */
+ info-ring-id = ctx-user_id;
+ info-ring-head = info-ring-tail = 0;
+ info-ring-magic = AIO_RING_MAGIC;
+ info-ring-compat_features = AIO_RING_COMPAT_FEATURES;
+ info-ring-incompat_features = AIO_RING_INCOMPAT_FEATURES;
+ info-ring-header_length = sizeof(struct aio_ring);
return 0;
}
-
-/* aio_ring_event: returns a pointer to the event at the given index from
- * kmap_atomic(). Release the pointer with put_aio_ring_event();
- */
-#define AIO_EVENTS_PER_PAGE(PAGE_SIZE / sizeof(struct io_event))
-#define AIO_EVENTS_FIRST_PAGE ((PAGE_SIZE - sizeof(struct aio_ring)) /
sizeof(struct io_event))
-#define AIO_EVENTS_OFFSET (AIO_EVENTS_PER_PAGE - AIO_EVENTS_FIRST_PAGE)
-
-#define aio_ring_event(info, nr) ({\
- unsigned pos = (nr) + AIO_EVENTS_OFFSET;\
- struct io_event *__event; \
- __event = kmap_atomic( \
- (info)-ring_pages[pos / AIO_EVENTS_PER_PAGE]); \
- __event += pos % AIO_EVENTS_PER_PAGE; \
- __event;\
-})
-
-#define put_aio_ring_event(event) do { \
- struct io_event *__event = (event); \
- (void)__event; \
- kunmap_atomic((void *)((unsigned long)__event PAGE_MASK)); \
-} while(0)
-
static void free_ioctx(struct work_struct *work)
{
struct kioctx *ctx = container_of(work, struct kioctx, free_work);
@@ -465,7 +448,6 @@ static int kiocb_batch_refill(struct kioctx *ctx, struct
kiocb_batch *batch)
unsigned short allocated, to_alloc;
long avail;
struct kiocb *req, *n;
- struct aio_ring *ring;
to_alloc = min(batch-count, KIOCB_BATCH_SIZE);
for (allocated = 0; allocated to_alloc; allocated++) {
@@ -480,9 +462,8 @@ static int kiocb_batch_refill(struct kioctx *ctx, struct
kiocb_batch *batch)
goto out;
spin_lock_irq(ctx-ctx_lock);
- ring = kmap_atomic(ctx-ring_info.ring_pages[0]);
- avail = aio_ring_avail(ctx-ring_info, ring) -
atomic_read(ctx-reqs_active);
+ avail = aio_ring_avail(ctx-ring_info) -
atomic_read(ctx-reqs_active);
BUG_ON(avail 0);
if (avail allocated) {
/* Trim back the number of requests. */
@@ -500,7 +481,6 @@ static int kiocb_batch_refill(struct kioctx *ctx, struct
kiocb_batch *batch)
atomic_inc(ctx-reqs_active);
}
- kunmap_atomic(ring);
spin_unlock_irq(ctx-ctx_lock);
out:
@@ -870,10 +850,9 @@ void aio_complete(struct kiocb *iocb, long res, long res2)
{
struct kioctx *ctx = iocb-ki_ctx;
struct aio_ring_info*info;
- struct aio_ring *ring;
[PATCH 5/5] aio: Refactor aio_read_evt, use cmxchg(), fix bug
Bunch of cleanup, and make it lockless so that userspace can safely pull
events off the ringbuffer without racing with io_getevents().
Signed-off-by: Kent Overstreet koverstr...@google.com
---
fs/aio.c | 220 +-
1 file changed, 73 insertions(+), 147 deletions(-)
diff --git a/fs/aio.c b/fs/aio.c
index c3d97d1..1efc8a3 100644
--- a/fs/aio.c
+++ b/fs/aio.c
@@ -259,7 +259,6 @@ static struct kioctx *ioctx_alloc(unsigned nr_events)
atomic_set(ctx-reqs_active, 1);
spin_lock_init(ctx-ctx_lock);
- spin_lock_init(ctx-ring_info.ring_lock);
init_waitqueue_head(ctx-wait);
INIT_LIST_HEAD(ctx-active_reqs);
@@ -941,194 +940,121 @@ put_rq:
}
EXPORT_SYMBOL(aio_complete);
-/* aio_read_evt
- * Pull an event off of the ioctx's event ring. Returns the number of
- * events fetched (0 or 1 ;-)
- * FIXME: make this use cmpxchg.
- * TODO: make the ringbuffer user mmap()able (requires FIXME).
+/* aio_read_events
+ * Pull an event off of the ioctx's event ring. Returns the number of
+ * events fetched
*/
-static int aio_read_evt(struct kioctx *ioctx, struct io_event *ent)
+static int aio_read_events(struct kioctx *ctx, struct io_event __user *event,
+ long nr)
{
- struct aio_ring_info *info = ioctx-ring_info;
+ struct aio_ring_info *info = ctx-ring_info;
struct aio_ring *ring = info-ring;
- unsigned long head;
- int ret = 0;
-
- dprintk(in aio_read_evt h%lu t%lu m%lu\n,
-(unsigned long)ring-head, (unsigned long)ring-tail,
-(unsigned long)ring-nr);
-
- if (ring-head == ring-tail)
- goto out;
-
- spin_lock(info-ring_lock);
+ unsigned old, new;
+ int ret;
- head = ring-head % info-nr;
- if (head != ring-tail) {
- *ent = ring-io_events[head];
- head = (head + 1) % info-nr;
- smp_mb(); /* finish reading the event before updatng the head */
- ring-head = head;
- ret = 1;
- }
- spin_unlock(info-ring_lock);
+ pr_debug(h%lu t%lu m%lu\n,
+(unsigned long) ring-head,
+(unsigned long) ring-tail,
+(unsigned long) ring-nr);
+retry:
+ ret = 0;
+ old = new = ring-head;
-out:
- dprintk(leaving aio_read_evt: %d h%lu t%lu\n, ret,
-(unsigned long)ring-head, (unsigned long)ring-tail);
- return ret;
-}
+ while (ret nr new != ring-tail) {
+ struct io_event *ev = ring-io_events[new];
+ unsigned i = (new ring-tail ? ring-tail : info-nr) - new;
-struct aio_timeout {
- struct timer_list timer;
- int timed_out;
- struct task_struct *p;
-};
+ i = min_t(int, i, nr - ret);
-static void timeout_func(unsigned long data)
-{
- struct aio_timeout *to = (struct aio_timeout *)data;
+ if (unlikely(copy_to_user(event + ret, ev, sizeof(*ev) * i)))
+ return -EFAULT;
- to-timed_out = 1;
- wake_up_process(to-p);
-}
+ ret += i;
+ new += i;
+ new %= info-nr;
+ }
-static inline void init_timeout(struct aio_timeout *to)
-{
- setup_timer_on_stack(to-timer, timeout_func, (unsigned long) to);
- to-timed_out = 0;
- to-p = current;
-}
+ if (new != old) {
+ smp_mb(); /* finish reading the event before updatng the head */
-static inline void set_timeout(long start_jiffies, struct aio_timeout *to,
- const struct timespec *ts)
-{
- to-timer.expires = start_jiffies + timespec_to_jiffies(ts);
- if (time_after(to-timer.expires, jiffies))
- add_timer(to-timer);
- else
- to-timed_out = 1;
-}
+ if (cmpxchg(ring-head, old, new) != old)
+ goto retry;
+ }
-static inline void clear_timeout(struct aio_timeout *to)
-{
- del_singleshot_timer_sync(to-timer);
+ pr_debug(ret %d h%lu t%lu\n, ret,
+(unsigned long)ring-head,
+(unsigned long)ring-tail);
+ return ret;
}
-static int read_events(struct kioctx *ctx,
- long min_nr, long nr,
- struct io_event __user *event,
- struct timespec __user *timeout)
+static int read_events(struct kioctx *ctx, long min_nr, long nr,
+ struct io_event __user *event,
+ struct timespec __user *timeout)
{
- longstart_jiffies = jiffies;
- struct task_struct *tsk = current;
- DECLARE_WAITQUEUE(wait, tsk);
- int ret;
- int i = 0;
- struct io_event ent;
- struct aio_timeout to;
-
[PATCH 3/5] aio: Rewrite refcounting
The refcounting before wasn't very clear; there are two refcounts in
struct kioctx, with an unclear relationship between them (or between
them and ctx-dead).
Now, reqs_active holds a refcount on users (when reqs_active is
nonzero), and the initial refcount is taken on reqs_active - when
ctx-dead goes to 1, we drop that initial refcount.
Some other semi related cleanup too.
Signed-off-by: Kent Overstreet koverstr...@google.com
---
fs/aio.c| 187 +--
include/linux/aio.h |5 +-
2 files changed, 63 insertions(+), 129 deletions(-)
diff --git a/fs/aio.c b/fs/aio.c
index 95419c4..3ab12f6 100644
--- a/fs/aio.c
+++ b/fs/aio.c
@@ -86,8 +86,9 @@ static void aio_free_ring(struct kioctx *ctx)
put_page(info-ring_pages[i]);
if (info-mmap_size) {
- BUG_ON(ctx-mm != current-mm);
- vm_munmap(info-mmap_base, info-mmap_size);
+ down_write(ctx-mm-mmap_sem);
+ do_munmap(ctx-mm, info-mmap_base, info-mmap_size);
+ up_write(ctx-mm-mmap_sem);
}
if (info-ring_pages info-ring_pages != info-internal_pages)
@@ -188,45 +189,37 @@ static int aio_setup_ring(struct kioctx *ctx)
kunmap_atomic((void *)((unsigned long)__event PAGE_MASK)); \
} while(0)
-static void ctx_rcu_free(struct rcu_head *head)
-{
- struct kioctx *ctx = container_of(head, struct kioctx, rcu_head);
- kmem_cache_free(kioctx_cachep, ctx);
-}
-
-/* __put_ioctx
- * Called when the last user of an aio context has gone away,
- * and the struct needs to be freed.
- */
-static void __put_ioctx(struct kioctx *ctx)
+static void free_ioctx(struct work_struct *work)
{
- unsigned nr_events = ctx-max_reqs;
- BUG_ON(ctx-reqs_active);
+ struct kioctx *ctx = container_of(work, struct kioctx, free_work);
cancel_delayed_work_sync(ctx-wq);
aio_free_ring(ctx);
mmdrop(ctx-mm);
- ctx-mm = NULL;
- if (nr_events) {
- spin_lock(aio_nr_lock);
- BUG_ON(aio_nr - nr_events aio_nr);
- aio_nr -= nr_events;
- spin_unlock(aio_nr_lock);
- }
- pr_debug(__put_ioctx: freeing %p\n, ctx);
- call_rcu(ctx-rcu_head, ctx_rcu_free);
-}
-static inline int try_get_ioctx(struct kioctx *kioctx)
-{
- return atomic_inc_not_zero(kioctx-users);
+ spin_lock(aio_nr_lock);
+ BUG_ON(aio_nr - ctx-max_reqs aio_nr);
+ aio_nr -= ctx-max_reqs;
+ spin_unlock(aio_nr_lock);
+
+ synchronize_rcu();
+
+ pr_debug(__put_ioctx: freeing %p\n, ctx);
+ kmem_cache_free(kioctx_cachep, ctx);
}
static inline void put_ioctx(struct kioctx *kioctx)
{
BUG_ON(atomic_read(kioctx-users) = 0);
if (unlikely(atomic_dec_and_test(kioctx-users)))
- __put_ioctx(kioctx);
+ schedule_work(kioctx-free_work);
+}
+
+static inline void req_put_ioctx(struct kioctx *kioctx)
+{
+ BUG_ON(atomic_read(kioctx-reqs_active) = 0);
+ if (unlikely(atomic_dec_and_test(kioctx-reqs_active)))
+ put_ioctx(kioctx);
}
static int kiocb_cancel(struct kioctx *ctx, struct kiocb *kiocb,
@@ -280,12 +273,15 @@ static struct kioctx *ioctx_alloc(unsigned nr_events)
atomic_inc(mm-mm_count);
atomic_set(ctx-users, 2);
+ atomic_set(ctx-reqs_active, 1);
+
spin_lock_init(ctx-ctx_lock);
spin_lock_init(ctx-ring_info.ring_lock);
init_waitqueue_head(ctx-wait);
INIT_LIST_HEAD(ctx-active_reqs);
INIT_LIST_HEAD(ctx-run_list);
+ INIT_WORK(ctx-free_work, free_ioctx);
INIT_DELAYED_WORK(ctx-wq, aio_kick_handler);
if (aio_setup_ring(ctx) 0)
@@ -327,36 +323,25 @@ out_freectx:
*/
static void kill_ctx(struct kioctx *ctx)
{
- struct task_struct *tsk = current;
- DECLARE_WAITQUEUE(wait, tsk);
+ struct kiocb *iocb, *t;
struct io_event res;
+ int put = 0;
spin_lock_irq(ctx-ctx_lock);
- ctx-dead = 1;
- while (!list_empty(ctx-active_reqs)) {
- struct list_head *pos = ctx-active_reqs.next;
- struct kiocb *iocb = list_kiocb(pos);
- list_del_init(iocb-ki_list);
- kiocb_cancel(ctx, iocb, res);
+ if (!ctx-dead) {
+ put = 1;
+ ctx-dead = 1;
+ hlist_del_rcu(ctx-list);
}
- if (!ctx-reqs_active)
- goto out;
-
- add_wait_queue(ctx-wait, wait);
- set_task_state(tsk, TASK_UNINTERRUPTIBLE);
- while (ctx-reqs_active) {
- spin_unlock_irq(ctx-ctx_lock);
- io_schedule();
- set_task_state(tsk, TASK_UNINTERRUPTIBLE);
- spin_lock_irq(ctx-ctx_lock);
- }
- __set_task_state(tsk, TASK_RUNNING);
- remove_wait_queue(ctx-wait, wait);
+ list_for_each_entry_safe(iocb, t, ctx-active_reqs, ki_list)
+
Re: [PATCH 1/3] mfd: Convert tps6586x to irq_domain
On Tue, Oct 09, 2012 at 11:34:47AM +0530, Laxman Dewangan wrote: The bit definitions are also different in status and mask register and yes, this will be again problem as we do in isr thread data-status_buf[i] = ~data-mask_buf[i]; So given the constraint, generic will not work here. OK, that's a good reason not to use the generic code. -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 2/5] aio: kiocb_cancel()
Minor refactoring, to get rid of some duplicated code
Signed-off-by: Kent Overstreet koverstr...@google.com
---
fs/aio.c | 72 ++
1 file changed, 39 insertions(+), 33 deletions(-)
diff --git a/fs/aio.c b/fs/aio.c
index 1ad2d97..95419c4 100644
--- a/fs/aio.c
+++ b/fs/aio.c
@@ -229,6 +229,29 @@ static inline void put_ioctx(struct kioctx *kioctx)
__put_ioctx(kioctx);
}
+static int kiocb_cancel(struct kioctx *ctx, struct kiocb *kiocb,
+ struct io_event *res)
+{
+ int (*cancel)(struct kiocb *, struct io_event *);
+ int ret = -EINVAL;
+
+ cancel = kiocb-ki_cancel;
+ kiocbSetCancelled(kiocb);
+ if (cancel) {
+ kiocb-ki_users++;
+ spin_unlock_irq(ctx-ctx_lock);
+
+ memset(res, 0, sizeof(*res));
+ res-obj = (u64) kiocb-ki_obj.user;
+ res-data = kiocb-ki_user_data;
+ ret = cancel(kiocb, res);
+
+ spin_lock_irq(ctx-ctx_lock);
+ }
+
+ return ret;
+}
+
/* ioctx_alloc
* Allocates and initializes an ioctx. Returns an ERR_PTR if it failed.
*/
@@ -304,7 +327,6 @@ out_freectx:
*/
static void kill_ctx(struct kioctx *ctx)
{
- int (*cancel)(struct kiocb *, struct io_event *);
struct task_struct *tsk = current;
DECLARE_WAITQUEUE(wait, tsk);
struct io_event res;
@@ -315,14 +337,8 @@ static void kill_ctx(struct kioctx *ctx)
struct list_head *pos = ctx-active_reqs.next;
struct kiocb *iocb = list_kiocb(pos);
list_del_init(iocb-ki_list);
- cancel = iocb-ki_cancel;
- kiocbSetCancelled(iocb);
- if (cancel) {
- iocb-ki_users++;
- spin_unlock_irq(ctx-ctx_lock);
- cancel(iocb, res);
- spin_lock_irq(ctx-ctx_lock);
- }
+
+ kiocb_cancel(ctx, iocb, res);
}
if (!ctx-reqs_active)
@@ -1709,7 +1725,7 @@ static struct kiocb *lookup_kiocb(struct kioctx *ctx,
struct iocb __user *iocb,
SYSCALL_DEFINE3(io_cancel, aio_context_t, ctx_id, struct iocb __user *, iocb,
struct io_event __user *, result)
{
- int (*cancel)(struct kiocb *iocb, struct io_event *res);
+ struct io_event res;
struct kioctx *ctx;
struct kiocb *kiocb;
u32 key;
@@ -1724,32 +1740,22 @@ SYSCALL_DEFINE3(io_cancel, aio_context_t, ctx_id,
struct iocb __user *, iocb,
return -EINVAL;
spin_lock_irq(ctx-ctx_lock);
- ret = -EAGAIN;
+
kiocb = lookup_kiocb(ctx, iocb, key);
- if (kiocb kiocb-ki_cancel) {
- cancel = kiocb-ki_cancel;
- kiocb-ki_users ++;
- kiocbSetCancelled(kiocb);
- } else
- cancel = NULL;
+ if (kiocb)
+ ret = kiocb_cancel(ctx, kiocb, res);
+ else
+ ret = -EAGAIN;
+
spin_unlock_irq(ctx-ctx_lock);
- if (NULL != cancel) {
- struct io_event tmp;
- pr_debug(calling cancel\n);
- memset(tmp, 0, sizeof(tmp));
- tmp.obj = (u64)(unsigned long)kiocb-ki_obj.user;
- tmp.data = kiocb-ki_user_data;
- ret = cancel(kiocb, tmp);
- if (!ret) {
- /* Cancellation succeeded -- copy the result
-* into the user's buffer.
-*/
- if (copy_to_user(result, tmp, sizeof(tmp)))
- ret = -EFAULT;
- }
- } else
- ret = -EINVAL;
+ if (!ret) {
+ /* Cancellation succeeded -- copy the result
+* into the user's buffer.
+*/
+ if (copy_to_user(result, res, sizeof(res)))
+ ret = -EFAULT;
+ }
put_ioctx(ctx);
--
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] regulator: TPS51632: Add tps51632 regulator driver
On Tuesday 09 October 2012 11:44 AM, Mark Brown wrote: On Sat, Oct 06, 2012 at 08:47:46PM +0530, Laxman Dewangan wrote: Actually... + if (pdata-dvfs_step_20mV) + control |= TPS51632_DVFS_STEP_20; + tps-desc.uV_step = TPS51632_VOLATGE_STEP_10mV; Shouldn't the dvfs_step_20mV setting affect the uV_step size? The dvfs_step_20mV will only effect for the control through DVFS (PWM). The voltage control an voltage base register will till use the 10mV steps. -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@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 00/10] x86: Use BRK to pre mapping page table to make xen happy
On Mon, Oct 8, 2012 at 11:25 PM, H. Peter Anvin h...@zytor.com wrote:
On 10/09/2012 02:21 PM, Yinghai Lu wrote:
Hi Yinghai,
This patchset doesn't apply on top of tip:x86/mm2, starting at patch 08/10.
sorry for that. I refresh my base to current linus/master and tip/master.
could be some change there.
could solve it:
1. update x86/mm2 to linus/master
2. or i resend the patch again with x86/mm2 as base.
please let me know which one you like.
If it doesn't have cross-dependencies on other code, x86/mm2 is probably
the best base; if there are other dependencies then that's fine, but we
need to know what they are. We don't want to create unnecessary tangles
among topic branches, it makes Linus very unhappy.
old one in tip/x86/mm2:
void __init xen_init_mmu_ops(void)
{
x86_init.mapping.pagetable_reserve = xen_mapping_pagetable_reserve;
x86_init.paging.pagetable_setup_start = xen_pagetable_setup_start;
x86_init.paging.pagetable_setup_done = xen_pagetable_setup_done;
pv_mmu_ops = xen_mmu_ops;
in linus/master
2178 void __init xen_init_mmu_ops(void)
2179 {
2180 x86_init.mapping.pagetable_reserve = xen_mapping_pagetable_reserve;
2181 x86_init.paging.pagetable_init = xen_pagetable_init;
2182 pv_mmu_ops = xen_mmu_ops;
2183
2184 memset(dummy_mapping, 0xff, PAGE_SIZE);
2185 }
cause by commit:
http://git.kernel.org/?p=linux/kernel/git/torvalds/linux.git;a=commitdiff;h=c711288727a62f74d48032e56e51333dd104bf58
rej:
--- arch/x86/xen/mmu.c
+++ arch/x86/xen/mmu.c
@@ -2169,7 +2165,7 @@
void __init xen_init_mmu_ops(void)
{
- x86_init.mapping.pagetable_reserve = xen_mapping_pagetable_reserve;
+ x86_init.mapping.make_range_readwrite = xen_make_range_readwrite;
x86_init.paging.pagetable_init = xen_pagetable_init;
pv_mmu_ops = xen_mmu_ops;
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@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 v5] create sun sysfs file
_SUN method provides the slot unique-ID in the ACPI namespace. And The value
is written in Advanced Configuration and Power Interface Specification as
follows:
The _SUN value is required to be unique among the slots ofthe same type.
It is also recommended that this number match the slot number printed on
the physical slot whenever possible.
So if we can know the value, we can identify the physical position of the
slot in the system.
The patch creates sun file in sysfs for identifying physical position
of the slot.
Reviewed-by: Toshi Kani toshi.k...@hp.com
Signed-off-by: Yasuaki Ishimatsu isimatu.yasu...@jp.fujitsu.com
---
Documentation/ABI/testing/sysfs-devices-sun | 14 ++
drivers/acpi/scan.c | 24
include/acpi/acpi_bus.h |1 +
3 files changed, 39 insertions(+)
Index: linux-3.6/include/acpi/acpi_bus.h
===
--- linux-3.6.orig/include/acpi/acpi_bus.h 2012-10-09 11:54:17.690072343
+0900
+++ linux-3.6/include/acpi/acpi_bus.h 2012-10-09 14:15:49.207794671 +0900
@@ -208,6 +208,7 @@ struct acpi_device_pnp {
struct list_head ids; /* _HID and _CIDs */
acpi_device_name device_name; /* Driver-determined */
acpi_device_class device_class; /* */
+ unsigned long sun; /* _SUN */
};
#define acpi_device_bid(d) ((d)-pnp.bus_id)
Index: linux-3.6/drivers/acpi/scan.c
===
--- linux-3.6.orig/drivers/acpi/scan.c 2012-10-09 11:54:17.688072343 +0900
+++ linux-3.6/drivers/acpi/scan.c 2012-10-09 14:15:49.211794675 +0900
@@ -232,10 +232,20 @@ end:
}
static DEVICE_ATTR(path, 0444, acpi_device_path_show, NULL);
+static ssize_t
+acpi_device_sun_show(struct device *dev, struct device_attribute *attr,
+char *buf) {
+ struct acpi_device *acpi_dev = to_acpi_device(dev);
+
+ return sprintf(buf, %lu\n, acpi_dev-pnp.sun);
+}
+static DEVICE_ATTR(sun, 0444, acpi_device_sun_show, NULL);
+
static int acpi_device_setup_files(struct acpi_device *dev)
{
acpi_status status;
acpi_handle temp;
+ unsigned long long sun;
int result = 0;
/*
@@ -257,6 +267,16 @@ static int acpi_device_setup_files(struc
goto end;
}
+ status = acpi_evaluate_integer(dev-handle, _SUN, NULL, sun);
+ if (ACPI_SUCCESS(status)) {
+ dev-pnp.sun = (unsigned long)sun;
+ result = device_create_file(dev-dev, dev_attr_sun);
+ if (result)
+ goto end;
+ } else {
+ dev-pnp.sun = (unsigned long)-1;
+ }
+
/*
* If device has _EJ0, 'eject' file is created that is used to trigger
* hot-removal function from userland.
@@ -281,6 +301,10 @@ static void acpi_device_remove_files(str
if (ACPI_SUCCESS(status))
device_remove_file(dev-dev, dev_attr_eject);
+ status = acpi_get_handle(dev-handle, _SUN, temp);
+ if (ACPI_SUCCESS(status))
+ device_remove_file(dev-dev, dev_attr_sun);
+
device_remove_file(dev-dev, dev_attr_modalias);
device_remove_file(dev-dev, dev_attr_hid);
if (dev-handle)
Index: linux-3.6/Documentation/ABI/testing/sysfs-devices-sun
===
--- /dev/null 1970-01-01 00:00:00.0 +
+++ linux-3.6/Documentation/ABI/testing/sysfs-devices-sun 2012-10-09
15:47:02.333245246 +0900
@@ -0,0 +1,14 @@
+Whatt: /sys/devices/.../sun
+Date: October 2012
+Contact: Yasuaki Ishimatsu isimatu.yasu...@jp.fujitsu.com
+Description:
+ The file contains a Slot-unique ID which provided by the _SUN
+ method in the ACPI namespace. The value is written in Advanced
+ Configuration and Power Interface Specification as follows:
+
+ The _SUN value is required to be unique among the slots of
+ the same type. It is also recommended that this number match
+ the slot number printed on the physical slot whenever possible.
+
+ So reading the sysfs file, we can identify a physical position
+ of the slot in the system.
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@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/5] regulator; tps65090: Register all regulators in single probe call
On Tuesday 09 October 2012 11:52 AM, Mark Brown wrote: On Sat, Oct 06, 2012 at 08:47:48PM +0530, Laxman Dewangan wrote: MFD drier registers the regulator driver once per device and Shouldn't this be the first commit in the series? Also... Ok, will make this as first commit. to allow things to be missed out. Otherwise we're likely to crash if the user misses a regulator or something. Agree with your suggestion and for this either I need to move all the defs of regulator/tps65090-regulator.h to mfd/tps65090.h or include the regulator header in mfd header. I will move all this to the mfd header and get rid of regulator header. -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@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] ext3: fix return values on parse_options() failure
Lukáš Czerner lczer...@redhat.com writes: On Tue, 9 Oct 2012, Zhao Hongjiang wrote: Date: Tue, 09 Oct 2012 13:48:47 +0800 From: Zhao Hongjiang zhaohongjian...@gmail.com To: j...@suse.cz Cc: a...@linux-foundation.org, adilger.ker...@dilger.ca, linux-e...@vger.kernel.org, linux-kernel@vger.kernel.org, Eric W. Biederman ebied...@xmission.com, serge.hal...@canonical.com, contain...@lists.linux-foundation.org Subject: [PATCH] ext3: fix return values on parse_options() failure From: Zhao Hongjiang zhaohongji...@huawei.com parse_options() in ext3 should return 0 when parse the mount options fails. Ah, it really is a joy to read the parse_options() :). But this fix makes sense, thanks for catching it. Reviewed-by: Lukas Czerner lczer...@redhat.com Ugh. I goofed that up. How annoying that ext4 is different than ext3 and ext2 in this regard. Acked-by: Eric W. Biederman ebied...@xmission.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 V3] block/throttle: Add IO throttled information in blkio.throttle
From: Robin Dong san...@taobao.com
Currently, if the IO is throttled by io-throttle, the SA has no idea of
the situation and can't report it to the real application user about
that he/she has to do something. So this patch adds a new interface
named blkio.throttle.io_queued which indicates how many IOs are
currently throttled.
The nr_queued[] of struct throtl_grp is of type unsigned int and updates
to it are atomic both at 32bit and 64bit platforms, so we could just
read tg-nr_queued only under blkcg-lock.
Changelog from v2:
Use nr-queued[] of struct throtl_grp for stats instaed of adding new
blkg_rwstat.
Cc: Tejun Heo t...@kernel.org
Cc: Vivek Goyal vgo...@redhat.com
Cc: Jens Axboe ax...@kernel.dk
Signed-off-by: Tao Ma boyu...@taobao.com
Signed-off-by: Robin Dong san...@taobao.com
---
block/blk-throttle.c | 40
1 files changed, 40 insertions(+), 0 deletions(-)
diff --git a/block/blk-throttle.c b/block/blk-throttle.c
index a9664fa..e410448 100644
--- a/block/blk-throttle.c
+++ b/block/blk-throttle.c
@@ -953,6 +953,32 @@ static u64 tg_prfill_cpu_rwstat(struct seq_file *sf,
return __blkg_prfill_rwstat(sf, pd, rwstat);
}
+static u64 tg_prfill_io_queued(struct seq_file *sf,
+ struct blkg_policy_data *pd, int off)
+{
+ static const char *rwstr[] = {
+ [READ] = Read,
+ [WRITE] = Write,
+ };
+ struct throtl_grp *tg = pd_to_tg(pd);
+ const char *dname = NULL;
+ unsigned int v;
+ int i;
+
+ if (pd-blkg-q-backing_dev_info.dev)
+ dname = dev_name(pd-blkg-q-backing_dev_info.dev);
+
+ if (!dname)
+ return 0;
+
+ for (i = 0; i = WRITE; i++)
+ seq_printf(sf, %s %s %u\n, dname, rwstr[i], tg-nr_queued[i]);
+
+ v = tg-nr_queued[READ] + tg-nr_queued[WRITE];
+ seq_printf(sf, %s Total %u\n, dname, v);
+ return v;
+}
+
static int tg_print_cpu_rwstat(struct cgroup *cgrp, struct cftype *cft,
struct seq_file *sf)
{
@@ -963,6 +989,16 @@ static int tg_print_cpu_rwstat(struct cgroup *cgrp, struct
cftype *cft,
return 0;
}
+static int tg_print_io_queued(struct cgroup *cgrp, struct cftype *cft,
+ struct seq_file *sf)
+{
+ struct blkcg *blkcg = cgroup_to_blkcg(cgrp);
+
+ blkcg_print_blkgs(sf, blkcg, tg_prfill_io_queued, blkcg_policy_throtl,
+ cft-private, true);
+ return 0;
+}
+
static u64 tg_prfill_conf_u64(struct seq_file *sf, struct blkg_policy_data *pd,
int off)
{
@@ -1085,6 +1121,10 @@ static struct cftype throtl_files[] = {
.private = offsetof(struct tg_stats_cpu, serviced),
.read_seq_string = tg_print_cpu_rwstat,
},
+ {
+ .name = throttle.io_queued,
+ .read_seq_string = tg_print_io_queued,
+ },
{ } /* terminate */
};
--
1.7.1
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 5/5] regulator: tps65090: add external control support for DCDC
On Tuesday 09 October 2012 11:58 AM, Mark Brown wrote: On Sat, Oct 06, 2012 at 08:47:51PM +0530, Laxman Dewangan wrote: The TPS65090's DCDC outut can also be enable/disable through the external digital input signal. Add support for enable/disable either through register access via I2C or through external control inputs. The external control inputs can be driven through GPIOs also and hence adding support for passing the GPIO number. There's support for GPIO driven enable lines in the framework already, this driver should be able to use this happily, this sort of hardware is exactly the use case it was written for. yes, I am using the gpio driven enable lines in the framework. This patch does the some configuration in register to enable external control and configure the regulator_config (fill gpio related stuff in config) before registering the regulator. There is no call of gpio libs from the driver. -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@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] ext2: fix return values on parse_options() failure
On Tue, 9 Oct 2012, Zhao Hongjiang wrote:
Date: Tue, 09 Oct 2012 13:44:36 +0800
From: Zhao Hongjiang zhaohongjian...@gmail.com
To: j...@suse.cz
Cc: linux-e...@vger.kernel.org, linux-kernel@vger.kernel.org,
Eric W. Biederman ebied...@xmission.com, serge.hal...@canonical.com,
contain...@lists.linux-foundation.org
Subject: [PATCH] ext2: fix return values on parse_options() failure
From: Zhao Hongjiang zhaohongji...@huawei.com
parse_options() in ext2 should return 0 when parse the mount options fails.
Signed-off-by: Zhao Hongjiang zhaohongji...@huawei.com
Reviewed-by: Lukas Czerner lczer...@redhat.com
Thanks!
-Lukas
---
fs/ext2/super.c |4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/fs/ext2/super.c b/fs/ext2/super.c
index 6c205d0..fa04d02 100644
--- a/fs/ext2/super.c
+++ b/fs/ext2/super.c
@@ -469,7 +469,7 @@ static int parse_options(char *options, struct
super_block *sb)
uid = make_kuid(current_user_ns(), option);
if (!uid_valid(uid)) {
ext2_msg(sb, KERN_ERR, Invalid uid value %d,
option);
- return -1;
+ return 0;
}
sbi-s_resuid = uid;
@@ -480,7 +480,7 @@ static int parse_options(char *options, struct
super_block *sb)
gid = make_kgid(current_user_ns(), option);
if (!gid_valid(gid)) {
ext2_msg(sb, KERN_ERR, Invalid gid value %d,
option);
- return -1;
+ return 0;
}
sbi-s_resgid = gid;
break;
-- 1.7.1
--
To unsubscribe from this list: send the line unsubscribe linux-ext4 in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@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 27/30] ACPI: EC: Add a quirk for CLEVO M720T/M730T laptop
Feng Tang wrote: Jonathan Nieder jrnie...@gmail.com wrote: What would go wrong if the threshold were just increased to 20 on all models? Then some other platform will stop to work. https://bugzilla.kernel.org/show_bug.cgi?id=11892 The 26/30 and 27/30 patches are bound together to fix one bug. Some quote from description from the 26th patch: ACPI_EC_STORM_THRESHOLD was initially 20 when it's created, and was changed to 8 in 2.6.28 commit 06cf7d3c7 ACPI: EC: lower interrupt storm threshold to fix kernel bug 11892 by forcing the laptop in that bug to work in polling mode. Hope this answers your question. Thanks much. Yes, that clarifies. The magic numbers are not too thrilling. If the polling mode just doesn't work on the Clevo M720, why isn't the appropriate storm threshold 99 or infinity rather than 20? Do we know why the polling mode doesn't work? Jonathan -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@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] cpufreq: core: Fix typo in comment describing show_bios_limit()
show_bios_limit is mistakenly written as show_scaling_driver in a comment
describing purpose of show_bios_limit() routine.
Fix it.
Signed-off-by: Viresh Kumar viresh.ku...@linaro.org
---
drivers/cpufreq/cpufreq.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/cpufreq/cpufreq.c b/drivers/cpufreq/cpufreq.c
index fb8a527..021973b 100644
--- a/drivers/cpufreq/cpufreq.c
+++ b/drivers/cpufreq/cpufreq.c
@@ -581,7 +581,7 @@ static ssize_t show_scaling_setspeed(struct cpufreq_policy
*policy, char *buf)
}
/**
- * show_scaling_driver - show the current cpufreq HW/BIOS limitation
+ * show_bios_limit - show the current cpufreq HW/BIOS limitation
*/
static ssize_t show_bios_limit(struct cpufreq_policy *policy, char *buf)
{
--
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 5/5] regulator: tps65090: add external control support for DCDC
On Tue, Oct 09, 2012 at 11:51:19AM +0530, Laxman Dewangan wrote: On Tuesday 09 October 2012 11:58 AM, Mark Brown wrote: There's support for GPIO driven enable lines in the framework already, this driver should be able to use this happily, this sort of hardware is exactly the use case it was written for. yes, I am using the gpio driven enable lines in the framework. This patch does the some configuration in register to enable external control and configure the regulator_config (fill gpio related stuff in config) before registering the regulator. There is no call of gpio libs from the driver. The code seemed way more complex than that... did you notice the fact that if a GPIO is specified then the register enable/disable control will be ignored if provided? -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] firmware: Don't attempt to allocate zero bytes with vmalloc()
On Tue, Oct 9, 2012 at 12:19 PM, Mark Brown It seems better to punt that decision to callers - for example, the case In fact, -ENOENT is returned to caller for non-direct loading situation, see_request_firmware_load(). I understand drivers(caller) may be cheated if a zero-length firmware image is obtained. In normal situation, one firmware image should include something, instead of nothing, :-) I ran into this with was a driver that was using a zero length firmware to say that it didn't want to load an optional image but also didn't want to have to time out if that was the case. That doesn't seem If so, I am wondering why the driver has to call request_firmware()? Looks just bypassing request_firmware() is fine for the driver, doesn't it? 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: [3.5 regression / mcs7830 / bisected] bridge constantly toggeling between disabled and forwarding
On Tuesday 09 October 2012, Michael Leun wrote: On Thu, 27 Sep 2012 10:39:05 -0700 Greg KH gre...@linuxfoundation.org wrote: On Tue, Jul 24, 2012 at 01:36:34AM +0200, Michael Leun wrote: On Mon, 23 Jul 2012 09:15:04 +0200 Michael Leun lkml20120...@newton.leun.net wrote: [see issue description below] Bisecting yielded b1ff4f96fd1c63890d78d8939c6e0f2b44ce3113 is the first bad commit commit b1ff4f96fd1c63890d78d8939c6e0f2b44ce3113 Author: Ondrej Zary li...@rainbow-software.org Date: Fri Jun 1 10:29:08 2012 + mcs7830: Implement link state detection Add .status callback that detects link state changes. Tested with MCS7832CV-AA chip (9710:7830, identified as rev.C by the driver). Fixes https://bugzilla.kernel.org/show_bug.cgi?id=28532 Signed-off-by: Ondrej Zary li...@rainbow-software.org Signed-off-by: David S. Miller da...@davemloft.net :04 04 5480780cb5e75c57122a621fc3bab0108c16be27 d97efd9cc0a465dff76bcd3a3c547f718f2a5345 Mdrivers Reverting that from 3.5 makes the issue go away. Did this ever get resolved in 3.6-rc7 or any older kernel? I can't revert the patch from 3.5.y unless it's also fixed in Linus's tree. Please excuse me for answering a bit late. No, that never got resolved, I still have the problem with 3.6 but I'm not shure about the correct solution. Maybe link state detection just does not work with some of that devices and we should have an possibility to enable/disable it per device, maybe it can be handeled with an blacklist of not working devices, maybe it could be fixed - I do not know and also do not know how to find out. But I'm willing to test. Does the problem appear only in a bridge? Or the link state detection is completely wrong? -- Ondrej Zary -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@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/16] f2fs: introduce flash-friendly file system
-Original Message- From: Vyacheslav Dubeyko [mailto:sl...@dubeyko.com] Sent: Tuesday, October 09, 2012 4:23 AM To: Jaegeuk Kim Cc: 'Marco Stornelli'; 'Jaegeuk Kim'; 'Al Viro'; ty...@mit.edu; gre...@linuxfoundation.org; linux- ker...@vger.kernel.org; chur@samsung.com; cm224@samsung.com; jooyoung.hw...@samsung.com; linux-fsde...@vger.kernel.org Subject: Re: [PATCH 00/16] f2fs: introduce flash-friendly file system Hi, On Oct 8, 2012, at 12:25 PM, Jaegeuk Kim wrote: -Original Message- From: Vyacheslav Dubeyko [mailto:sl...@dubeyko.com] Sent: Sunday, October 07, 2012 9:09 PM To: Jaegeuk Kim Cc: 'Marco Stornelli'; 'Jaegeuk Kim'; 'Al Viro'; ty...@mit.edu; gre...@linuxfoundation.org; linux- ker...@vger.kernel.org; chur@samsung.com; cm224@samsung.com; jooyoung.hw...@samsung.com; linux-fsde...@vger.kernel.org Subject: Re: [PATCH 00/16] f2fs: introduce flash-friendly file system Hi, On Oct 7, 2012, at 1:31 PM, Jaegeuk Kim wrote: -Original Message- From: Marco Stornelli [mailto:marco.storne...@gmail.com] Sent: Sunday, October 07, 2012 4:10 PM To: Jaegeuk Kim Cc: Vyacheslav Dubeyko; jaegeuk@samsung.com; Al Viro; ty...@mit.edu; gre...@linuxfoundation.org; linux-kernel@vger.kernel.org; chur@samsung.com; cm224@samsung.com; jooyoung.hw...@samsung.com; linux-fsde...@vger.kernel.org Subject: Re: [PATCH 00/16] f2fs: introduce flash-friendly file system Il 06/10/2012 22:06, Jaegeuk Kim ha scritto: 2012-10-06 (토), 17:54 +0400, Vyacheslav Dubeyko: Hi Jaegeuk, Hi. We know each other, right? :) From: 김재극 jaegeuk@samsung.com To: v...@zeniv.linux.org.uk, 'Theodore Ts'o' ty...@mit.edu, gre...@linuxfoundation.org, linux-kernel@vger.kernel.org, chur@samsung.com, cm224@samsung.com, jaegeuk@samsung.com, jooyoung.hw...@samsung.com Subject: [PATCH 00/16] f2fs: introduce flash-friendly file system Date: Fri, 05 Oct 2012 20:55:07 +0900 This is a new patch set for the f2fs file system. What is F2FS? = NAND flash memory-based storage devices, such as SSD, eMMC, and SD cards, have been widely being used for ranging from mobile to server systems. Since they are known to have different characteristics from the conventional rotational disks, a file system, an upper layer to the storage device, should adapt to the changes from the sketch. F2FS is a new file system carefully designed for the NAND flash memory-based storage devices. We chose a log structure file system approach, but we tried to adapt it to the new form of storage. Also we remedy some known issues of the very old log structured file system, such as snowball effect of wandering tree and high cleaning overhead. Because a NAND-based storage device shows different characteristics according to its internal geometry or flash memory management scheme aka FTL, we add various parameters not only for configuring on-disk layout, but also for selecting allocation and cleaning algorithms. What about F2FS performance? Could you share benchmarking results of the new file system? It is very interesting the case of aged file system. How is GC's implementation efficient? Could you share benchmarking results for the very aged file system state? Although I have benchmark results, currently I'd like to see the results measured by community as a black-box. As you know, the results are very dependent on the workloads and parameters, so I think it would be better to see other results for a while. Thanks, 1) Actually it's a strange approach. If you have got any results you should share them with the community explaining how (the workload, hw and so on) your benchmark works and the specific condition. I really don't like the approach I've got the results but I don't say anything, if you want a number, do it yourself. It's definitely right, and I meant *for a while*. I just wanted to avoid arguing with how to age file system in this time. Before then, I share the primitive results as follows. 1. iozone in Panda board - ARM A9 - DRAM : 1GB - Kernel: Linux 3.3 - Partition: 12GB (64GB Samsung eMMC) - Tested on 2GB file seq. read, seq. write, rand. read, rand. write - ext4:30.753 17.066 5.06 4.15 - f2fs:30.71 16.906 5.073 15.204 2. iozone in Galaxy Nexus - DRAM : 1GB - Android 4.0.4_r1.2 - Kernel omap 3.0.8 - Partition: /data, 12GB - Tested on 2GB file seq. read, seq. write, rand. read, rand. write - ext4:29.8812.83 11.43 0.56 - f2fs:29.7013.34 10.79 12.82 This is results for non-aged filesystem state. Am I correct? Yes, right. Due to the company secret, I expect to
Re: [Patch v2 2/7] Regulator: DA9055 Regulator driver
On Mon, Oct 08, 2012 at 07:00:39PM +0530, Ashish Jangam wrote:
Mostly OK, but there's a few issues including yet more reimplementation
of framework features.
+static int da9055_list_voltage(struct regulator_dev *rdev,
+ unsigned int selector)
+{
+ struct da9055_regulator *regulator = rdev_get_drvdata(rdev);
+ struct da9055_regulator_info *info = regulator-info;
+ int volt_uV;
+
+ volt_uV = (selector * info-step_uV) + info-min_uV;
+
+ if (volt_uV info-max_uV)
+ return -EINVAL;
+
+ return volt_uV;
+}
This is regulator_list_voltage_linear()
+static int da9055_map_voltage(struct regulator_dev *rdev,
+ int min_uV, int max_uV)
+{
+ struct da9055_regulator *regulator = rdev_get_drvdata(rdev);
+ struct da9055_regulator_info *info = regulator-info;
+ int ret, sel;
+
+ ret = verify_range(info, min_uV, max_uV);
+ if (ret 0)
+ return ret;
+
+ if (min_uV info-min_uV)
+ min_uV = info-min_uV;
+
+ sel = DIV_ROUND_UP(min_uV - info-min_uV, info-step_uV);
+
+ ret = da9055_list_voltage(rdev, sel);
+ if (ret 0)
+ return ret;
+
+ return sel;
+}
This is regulator_map_voltage_linear().
+ int gpio = pdata-gpio_base + pdata-gpio_ren[id];
+ sprintf(name, DA9055 REG %d STATE, id);
snprintf().
+ /* Set the GPIO I/P pin for controlling the regulator state. */
+ ret = devm_gpio_request_one(config-dev, gpio, GPIOF_DIR_IN,
+ name);
+ if (ret 0)
+ goto err;
We never actually appear to use this GPIO anywhere... why are we
requesting it? Also, why is the ability to read the regulator state via
a GPIO associated with controlling it via a GPIO, it's unusual for these
things to be tied together.
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] firmware: Don't attempt to allocate zero bytes with vmalloc()
On Tue, Oct 09, 2012 at 03:05:30PM +0800, Ming Lei wrote: On Tue, Oct 9, 2012 at 12:19 PM, Mark Brown It seems better to punt that decision to callers - for example, the case In fact, -ENOENT is returned to caller for non-direct loading situation, see_request_firmware_load(). I understand drivers(caller) may be cheated if a zero-length firmware image is obtained. In normal situation, one firmware image should include something, instead of nothing, :-) Hrm, that didn't seem to be happening for me - the firmware load completed successfully. Have to check how that happened. I ran into this with was a driver that was using a zero length firmware to say that it didn't want to load an optional image but also didn't want to have to time out if that was the case. That doesn't seem If so, I am wondering why the driver has to call request_firmware()? Looks just bypassing request_firmware() is fine for the driver, doesn't it? A driver has no way to tell if the firmware is there or not without asking for it. -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@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] time: cast -raw_interval to u64 to avoid shift overflow
We fixed a bunch of integer overflows in timekeeping code during the 3.6
cycle. I did an audit based on that and found this potential overflow.
Signed-off-by: Dan Carpenter dan.carpen...@oracle.com
---
I'm not super familiar with this code so please review my work
carefully.
diff --git a/kernel/time/timekeeping.c b/kernel/time/timekeeping.c
index 5ce06a3..1d1ee67 100644
--- a/kernel/time/timekeeping.c
+++ b/kernel/time/timekeeping.c
@@ -1113,7 +1113,7 @@ static cycle_t logarithmic_accumulation(struct timekeeper
*tk, cycle_t offset,
accumulate_nsecs_to_secs(tk);
/* Accumulate raw time */
- raw_nsecs = tk-raw_interval shift;
+ raw_nsecs = (u64)tk-raw_interval shift;
raw_nsecs += tk-raw_time.tv_nsec;
if (raw_nsecs = NSEC_PER_SEC) {
u64 raw_secs = raw_nsecs;
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@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: [3.5 regression / mcs7830 / bisected] bridge constantly toggeling between disabled and forwarding
On Tuesday 09 October 2012, Michael Leun wrote:
On Thu, 27 Sep 2012 10:39:05 -0700
Greg KH gre...@linuxfoundation.org wrote:
On Tue, Jul 24, 2012 at 01:36:34AM +0200, Michael Leun wrote:
On Mon, 23 Jul 2012 09:15:04 +0200
Michael Leun lkml20120...@newton.leun.net wrote:
[see issue description below]
Bisecting yielded
b1ff4f96fd1c63890d78d8939c6e0f2b44ce3113 is the first bad commit
commit b1ff4f96fd1c63890d78d8939c6e0f2b44ce3113
Author: Ondrej Zary li...@rainbow-software.org
Date: Fri Jun 1 10:29:08 2012 +
mcs7830: Implement link state detection
Add .status callback that detects link state changes.
Tested with MCS7832CV-AA chip (9710:7830, identified as rev.C
by the driver). Fixes
https://bugzilla.kernel.org/show_bug.cgi?id=28532
Signed-off-by: Ondrej Zary li...@rainbow-software.org
Signed-off-by: David S. Miller da...@davemloft.net
:04 04 5480780cb5e75c57122a621fc3bab0108c16be27
d97efd9cc0a465dff76bcd3a3c547f718f2a5345 Mdrivers
Reverting that from 3.5 makes the issue go away.
Did this ever get resolved in 3.6-rc7 or any older kernel? I can't
revert the patch from 3.5.y unless it's also fixed in Linus's tree.
Please excuse me for answering a bit late.
No, that never got resolved, I still have the problem with 3.6 but I'm
not shure about the correct solution.
Maybe link state detection just does not work with some of that devices
and we should have an possibility to enable/disable it per device,
maybe it can be handeled with an blacklist of not working devices,
maybe it could be fixed - I do not know and also do not know how to
find out.
But I'm willing to test.
Can you please apply this debug patch and provide the output?
--- a/drivers/net/usb/mcs7830.c
+++ b/drivers/net/usb/mcs7830.c
@@ -638,6 +638,7 @@ static void mcs7830_status(struct usbnet *dev, struct urb
*urb)
return;
link = !(buf[1] 0x20);
+ printk(netif_carrier_ok=%d, link=%d, buf[0]=0x%02x, buf[1]=0x%02x\n,
netif_carrier_ok(dev-net), link, buf[0], buf[1]);
if (netif_carrier_ok(dev-net) != link) {
if (link) {
netif_carrier_on(dev-net);
--
Ondrej Zary
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@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 08/10] x86, xen, mm: fix mapping_pagetable_reserve logic
On 10/09/2012 02:33 PM, Yinghai Lu wrote: make_range_readwrite is particularly toxic, though, because it makes it sound like it something along the lines of set_memory_rw(), which it most distinctly is not. it just change some page range from RO back to RW. so how about update_range_ro_to_rw? You're focusing on what the low-level mechanics of one particular implementation (Xen) of the hook, and then try to make it describe the hook itself. What the hook does, if I am reading it correctly, is take a range that used to be page tables and turn it back to ordinary memory. As such, assuming I'm following the logic correctly, something like pagetable_unreserve() seems like a reasonable name. However, why during initialization, why do we have to unreserve memory that has already been reserved for pagetables? (Keep in mind there may very well be an entirely sensible answer for that question -- I just can't tell from the patchset without a much more in-depth analysis. Keep in mind that that in-depth analysis sucks up time, and it doesn't scale to expect the maintainer to have to do that.) Magic variables augmented with more magic variables. Why? This also seems to assume that we still do all the kernel page tables in one chunk, which is exactly what we don't want to do. for 64bit, page table will be three parts 1. initial page table from arch/x86/kernel/head_64.S 2. page table from BRK. 3. page near end of RAM. verified from /sys/kernel/debug/kernel_page_tables only range E820_RAM is mapped. all initial page table for hole between [0, 1G) get cleared too. No, this is wrong, and more importantly, your choice of data structures encode this. There should not be any requirement for the page tables near the end of RAM to be contiguous -- consider the case of a memory hole near the end of RAM, or a large-memory machine where memory is highly discontiguous and we have to use more than one chunk before we run out. Then the questions become: 1. do we *have* to have this tracking at all? Obviously we have to know this memory is in use, but memblock reserve should take care of that. 2. if we do, please use a data structure which can handle an arbitrary number of ranges. -hpa -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 27/30] ACPI: EC: Add a quirk for CLEVO M720T/M730T laptop
On Mon, 8 Oct 2012 23:59:07 -0700 Jonathan Nieder jrnie...@gmail.com wrote: Feng Tang wrote: Jonathan Nieder jrnie...@gmail.com wrote: What would go wrong if the threshold were just increased to 20 on all models? Then some other platform will stop to work. https://bugzilla.kernel.org/show_bug.cgi?id=11892 The 26/30 and 27/30 patches are bound together to fix one bug. Some quote from description from the 26th patch: ACPI_EC_STORM_THRESHOLD was initially 20 when it's created, and was changed to 8 in 2.6.28 commit 06cf7d3c7 ACPI: EC: lower interrupt storm threshold to fix kernel bug 11892 by forcing the laptop in that bug to work in polling mode. Hope this answers your question. Thanks much. Yes, that clarifies. The magic numbers are not too thrilling. If the polling mode just doesn't work on the Clevo M720, why isn't the appropriate storm threshold 99 or infinity rather than 20? Do we know why the polling mode doesn't work? I don't know why it doesn't work, if you check the https://bugzilla.kernel.org/show_bug.cgi?id=45151 you'll see the debugging model is test result -- patch -- 1-2 weeks + result -- patch -- 1-2 weeks + result ... over and over, which makes it difficult to root cause it but provide a workaround. And frankly speaking, I'm not sure if I can figure it out 100% even if I had that HW at hand. As per my understanding, EC is very tricky, as OS, ACPI FW, EC FW, BIOS will all access it without a global lock (in most cases), which makes it hard to work properly without race condition. Not mentioning its hardware may be broken. Thanks, Feng -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 0/3] virtio-net: inline header support
Il 09/10/2012 06:59, Rusty Russell ha scritto: Paolo Bonzini pbonz...@redhat.com writes: Il 05/10/2012 07:43, Rusty Russell ha scritto: That's good. But virtio_blk's scsi command is insoluble AFAICT. As I said to Anthony, the best rules are always and never, so I'd really rather not have to grandfather that in. It is, but we can add a rule that if the (transport) flag VIRTIO_RING_F_ANY_HEADER_SG is set, the cdb field is always 32 bytes in virtio-blk. Could we do that? It's the cmd length I'm concerned about; is it always 32 in practice for some reason? It is always 32 or less except in very obscure cases that are pretty much confined to iSCSI. We don't care about the obscure cases, and the extra bytes don't hurt. BTW, 32 is the default cdb_size used by virtio-scsi. Currently qemu does: struct sg_io_hdr hdr; memset(hdr, 0, sizeof(struct sg_io_hdr)); hdr.interface_id = 'S'; hdr.cmd_len = req-elem.out_sg[1].iov_len; hdr.cmdp = req-elem.out_sg[1].iov_base; hdr.dxfer_len = 0; If it's a command which expects more output data, there's no way to guess where the boundary is between that command and the data. Yep, so I understood the problem right. Paolo -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] firmware: Don't attempt to allocate zero bytes with vmalloc()
On Tue, Oct 9, 2012 at 3:13 PM, Mark Brown broo...@opensource.wolfsonmicro.com wrote: If so, I am wondering why the driver has to call request_firmware()? Looks just bypassing request_firmware() is fine for the driver, doesn't it? A driver has no way to tell if the firmware is there or not without asking for it. Yes, I agree, and my question is only on what you mentioned: it didn't want to load an optional image maybe I misunderstood the above, never mind, :-) So one driver should suppose the firmware is there, and the firmware shouldn't be zero length, because the driver always expects getting some bytes by calling request_firmware(). 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: [RFC PATCH 01/06] input/rmi4: Public header and documentation
On Sat, Oct 6, 2012 at 6:09 AM, Christopher Heiny che...@synaptics.com wrote: As requested in the feedback from the previous patch, we've documented the debugfs and sysfs attributes in files in Documentation/ABI/testing. There's two files, one for debugfs and one for sysfs. This is a massive improvement! Atleast as far as I've read... If you fix the below remarks I think I'm ready to accept this file, but that's just me and doesn't say anything about what Dmitry et al will comment on... (...) + The RMI4 driver implementation exposes a set of informational and control + parameters via debugs. These parameters are those that typically are only s/debugs/debugfs (...) + comms_debug - (rw) Write 1 to this dump information about register + reads and writes to the console. Write 0 to this to turn + this feature off. WARNING: Imposes a major performance + penalty when turned on. + irq_debug - (rw) Write 1 to this dump information about interrupts + to the console. Write 0 to this to turn this feature off. + WARNIG: Imposes a major performance penalty when turned on. Hm. Usually we control dynamic debug prints by standard kernel frameworks, can you tell what is wrong with this and why you need a custom mechanism? See the following: Documentation/dynamic-debug-howto.txt http://lwn.net/Articles/434833/ (...) +++ b/Documentation/ABI/testing/sysfs-rmi4 (...) + chargerinput ... (rw) User space programs can use this to tell the + sensor that the system is plugged into an external power + source (as opposed to running on batteries). This allows + the sensor firmware to make necessary adjustments for the + current capacitence regime. Write 1 to this when the + system is using external power, write 0 to this when the + system is running on batteries. See spec for full details. I remember discussing in-kernel notifiers for this. I don't really see the point in tunnelling a notification from the drivers/power subsystem to the drivers/input subsystem through userspace for no good. It's no blocker though, I don't expect you to fix this as part of this driver submission. Maybe Anton can comment? (...) + interrupt_enable ... (ro) This represents the current RMI4 interrupt + mask (F01_RMI_Ctrl1 registers). See spec for full details. What does the userspace have to do with this stuff? Seems way too low-level, but whatever. (...) + sleepmode ... (rw) Controls power management on the device. Writing + 0 to this parameter puts the device into its normal operating + mode. Writing 1 to this parameter fully disables touch + sensors and similar inputs - no touch data will be reported + from the device in this mode. Writing 2 or 3 to this device + may or may not have an effect, depending on the particular + device - see the product specification for your sensor for + details. Usually power management is controlled from kernelspace, but no big deal, maybe userspace knows even more details in some cases. + unconfigured ... (ro) This is the opposite of the configured bit, + described above. So why is it needed? Isn't it implicit from the configured property if this is 0 then it's unconfigured? Seems superfluous. (...) +++ b/include/linux/rmi.h (...) +#ifdef CONFIG_RMI4_DEBUG +#include linux/debugfs.h +#endif Don't include it conditionally, always just include it whether you use it or not. It doesn't hurt, and doesn't cause compile problems. (...) +/** + * struct rmi_device_platform_data_spi - provides paramters used in SPI s/paramters/parameters/ + * communitcations. All Synaptics SPI products support a standard SPI s/communitcations/communications + * @cs_assert - For systems where the SPI subsystem does not control the CS/SSB + * line, or where such control is broken, you can provide a custom routine to + * handle a GPIO as CS/SSB. This routine will be called at the beginning and + * end of each SPI transaction. The RMI SPI implementation will wait + * pre_delay_us after this routine returns before starting the SPI transfer; + * and post_delay_us after completion of the SPI transfer(s) before calling it + * with assert==FALSE. Hm hm, can you describe the case where this happens? Usually we don't avoid fixes for broken drivers by duct-taping solutions into other drivers, instead we fix the SPI driver. I can think of systems where CS is asserted not by using GPIO but by poking some special register for example, which is a valid reason for including this, but working around broken SPI drivers is not a valid reason to include this. (Paging Mark about it.)
Re: [PATCH] video: imxfb: Do not crash on reboot
On Mon, Oct 08, 2012 at 10:35:36AM -0300, Fabio Estevam wrote:
Issuing a reboot command after the LCD times out causes the following
warnings:
Requesting system reboot
[ cut here ]
WARNING: at drivers/clk/clk.c:471 clk_disable+0x24/0x50()
Modules linked in:
[c001ad90] (unwind_backtrace+0x0/0xf4) from [c0025aac]
(warn_slowpath_common+0x48/0x60)
[c0025aac] (warn_slowpath_common+0x48/0x60) from [c0025ae0]
(warn_slowpath_null+0x1c/0x24)
[c0025ae0] (warn_slowpath_null+0x1c/0x24) from [c03960a0]
(clk_disable+0x24/0x50)
[c03960a0] (clk_disable+0x24/0x50) from [c02695a0]
(imxfb_disable_controller+0x48/0x7c)
[c02695a0] (imxfb_disable_controller+0x48/0x7c) from [c029d838]
(platform_drv_shutdown+0x18/0x1c)
[c029d838] (platform_drv_shutdown+0x18/0x1c) from [c02990fc]
(device_shutdown+0x48/0x14c)
[c02990fc] (device_shutdown+0x48/0x14c) from [c003d09c]
(kernel_restart_prepare+0x2c/0x3c)
[c003d09c] (kernel_restart_prepare+0x2c/0x3c) from [c003d0e4]
(kernel_restart+0xc/0x48)
[c003d0e4] (kernel_restart+0xc/0x48) from [c003d1e8]
(sys_reboot+0xc0/0x1bc)
[c003d1e8] (sys_reboot+0xc0/0x1bc) from [c0014ca0]
(ret_fast_syscall+0x0/0x2c)
---[ end trace da6b502ca79c854f ]---
[ cut here ]
WARNING: at drivers/clk/clk.c:380 clk_unprepare+0x1c/0x2c()
Modules linked in:
[c001ad90] (unwind_backtrace+0x0/0xf4) from [c0025aac]
(warn_slowpath_common+0x48/0x60)
[c0025aac] (warn_slowpath_common+0x48/0x60) from [c0025ae0]
(warn_slowpath_null+0x1c/0x24)
[c0025ae0] (warn_slowpath_null+0x1c/0x24) from [c0396338]
(clk_unprepare+0x1c/0x2c)
[c0396338] (clk_unprepare+0x1c/0x2c) from [c02695a8]
(imxfb_disable_controller+0x50/0x7c)
[c02695a8] (imxfb_disable_controller+0x50/0x7c) from [c029d838]
(platform_drv_shutdown+0x18/0x1c)
[c029d838] (platform_drv_shutdown+0x18/0x1c) from [c02990fc]
(device_shutdown+0x48/0x14c)
[c02990fc] (device_shutdown+0x48/0x14c) from [c003d09c]
(kernel_restart_prepare+0x2c/0x3c)
[c003d09c] (kernel_restart_prepare+0x2c/0x3c) from [c003d0e4]
(kernel_restart+0xc/0x48)
[c003d0e4] (kernel_restart+0xc/0x48) from [c003d1e8]
(sys_reboot+0xc0/0x1bc)
[c003d1e8] (sys_reboot+0xc0/0x1bc) from [c0014ca0]
(ret_fast_syscall+0x0/0x2c)
---[ end trace da6b502ca79c8550 ]---
[ cut here ]
This happens because reboot triggers imxfb_shutdown(), which calls
imxfb_disable_controller with the clocks already disabled.
To prevent this, add a clock enabled status so that we can check if the clocks
are enabled before disabling them.
Signed-off-by: Fabio Estevam fabio.este...@freescale.com
---
drivers/video/imxfb.c | 19 +--
1 file changed, 13 insertions(+), 6 deletions(-)
diff --git a/drivers/video/imxfb.c b/drivers/video/imxfb.c
index f3363b2..6acf98a 100644
--- a/drivers/video/imxfb.c
+++ b/drivers/video/imxfb.c
@@ -134,6 +134,7 @@ struct imxfb_info {
struct clk *clk_ipg;
struct clk *clk_ahb;
struct clk *clk_per;
+ int enabled;
I didn't really know the driver, but I wonder if the name enabled is a
tad too generic. Maybe better clks_enabled?
Uwe
--
Pengutronix e.K. | Uwe Kleine-König|
Industrial Linux Solutions | http://www.pengutronix.de/ |
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@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] mfd: use module_i2c_driver to simplify the code
On 10/08/2012 04:09 PM, Wei Yongjun wrote:
From: Wei Yongjun yongjun_...@trendmicro.com.cn
Use the module_i2c_driver() macro to make the code smaller
and a bit simpler.
dpatch engine is used to auto generate this patch.
(https://github.com/weiyj/dpatch)
Signed-off-by: Wei Yongjun yongjun_...@trendmicro.com.cn
Acked-by: Michael Hennerich michael.henner...@analog.com
---
drivers/mfd/adp5520.c | 12 +---
1 file changed, 1 insertion(+), 11 deletions(-)
diff --git a/drivers/mfd/adp5520.c b/drivers/mfd/adp5520.c
index ea8b947..94e7a6d 100644
--- a/drivers/mfd/adp5520.c
+++ b/drivers/mfd/adp5520.c
@@ -360,17 +360,7 @@ static struct i2c_driver adp5520_driver = {
.id_table = adp5520_id,
};
-static int __init adp5520_init(void)
-{
- return i2c_add_driver(adp5520_driver);
-}
-module_init(adp5520_init);
-
-static void __exit adp5520_exit(void)
-{
- i2c_del_driver(adp5520_driver);
-}
-module_exit(adp5520_exit);
+module_i2c_driver(adp5520_driver);
MODULE_AUTHOR(Michael Hennerich henner...@blackfin.uclinux.org);
MODULE_DESCRIPTION(ADP5520(01) PMIC-MFD Driver);
--
Greetings,
Michael
--
Analog Devices GmbH Wilhelm-Wagenfeld-Str. 6 80807 Muenchen
Sitz der Gesellschaft: Muenchen; Registergericht: Muenchen HRB 40368;
Geschaeftsfuehrer:Dr.Carsten Suckrow, Thomas Wessel, William A. Martin,
Margaret Seif
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH RFC] mm/swap: automatic tuning for swapin readahead
Hugh Dickins wrote: On Thu, 4 Oct 2012, Konstantin Khlebnikov wrote: Here results of my test. Workload isn't very realistic, but at least it threaded: compiling linux-3.6 with defconfig in 16 threads on tmpfs, 512mb ram, dualcore cpu, ordinary hard disk. (test script in attachment) average results for ten runs: RA=3RA=0RA=1RA=2RA=4HughShaohua real time 500 542 528 519 500 523 522 user time 738 737 735 737 739 737 739 sys time93 93 91 92 96 92 93 pgmajfault 62918 110533 92454 78221 54342 86601 77229 pgpgin 2070372 795228 1034046 1471010 3177192 1154532 1599388 pgpgout 2597278 2022037 2110020 2350380 2802670 2286671 2526570 pswpin 462747 138873 202148 310969 739431 232710 341320 pswpout 646363 502599 524613 584731 697797 568784 628677 So, last two columns shows mostly equal results: +4.6% and +4.4% in comparison to vanilla kernel with RA=3, but your version shows more stable results (std-error 2.7% against 4.8%) (all this numbers in huge table in attachment) Thanks for doing this, Konstantin, but I'm stuck for anything much to say! Shaohua and I are both about 4.5% bad for this particular test, but I'm more consistently bad - hurrah! I suspect (not a convincing argument) that if the test were just slightly different (a little more or a little less memory, SSD instead of hard disk, diskcache instead of tmpfs), then it would come out differently. Yes, results depends mostly on tmpfs. Did you draw any conclusions from the numbers you found? Yeah, I have some ideas: Numbers for vanilla kernel shows strong dependence between time and readahead size. Seems like main problem is that tmpfs does not have it's own readahead, it can only rely on swap-in readahead. There are about 25% readahead hits for RA=3. As pswpin row shows both your and Shaohua patches makes readahead smaller. Plus tmpfs doesn't keeps copy for clean pages in the swap (unlike to anon pages). On swapin path it always marks page dirty and releases swap-entry. I didn't have any measurements but this particular test definitely re-reads some files multiple times and writes them back to the swap after that. I haven't done any more on this in the last few days, except to verify that once an anon_vma is judged random with Shaohua's, then it appears to be condemned to no-readahead ever after. That's probably something that a hack like I had in mine would fix, but that addition might change its balance further (and increase vma or anon_vma size) - not tried yet. All I want to do right now, is suggest to Andrew that he hold Shaohua's patch back from 3.7 for the moment: I'll send a response to Sep 7th's mm-commits mail to suggest that - but no great disaster if he ignores me. Hugh Numbers from your tests formatted into table for better readability HDD Vanilla Shaohua RA=3RA=0RA=4 SEQ, ANON 73921 76210 75611 121542 77950 SEQ, SHMEM 73601 73176 73855 118322 73534 RND, ANON 895392 831243 871569 841680 863871 RND, SHMEM 1058375 1053486 827935 756489 834804 SDD Vanilla Shaohua RA=3RA=0RA=4 SEQ, ANON 24634 24198 24673 70018 21125 SEQ, SHMEM 24959 24932 25052 69678 21387 RND, ANON 43014 26146 28075 25901 28686 RND, SHMEM 45349 45215 28249 24332 28226 -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@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: PROBLEM: 3.6.0 kernel BUG at fs/dcache.c:967 during shutdown / restart
On Mon 08-10-12 17:10:52, Neil Salstrom wrote:
On 10/08/2012 10:14 AM, Jan Kara wrote:
On Sat 06-10-12 10:20:26, Neil Salstrom wrote:
I've not submitted a kernel bug before but I've read the bug
reporting pages. I'll try to do my best and if you need more
information please let me know. Please feel free to cc me on the
answer or if you have questions.
I'm using Linux Mint 13 (64 bit) on AMD hardware with a self
compiled 3.6.0 kernel for my MythTV HTPC.
Kernel version: Linux version 3.6.0 (gcc version 4.6.3
(Ubuntu/Linaro 4.6.3-1ubuntu5) ) #1 SMP Tue Oct 2 15:34:46 PDT 2012
CPU: model name : AMD A6-3500 APU with Radeon(tm) HD Graphics
If you need any other system variables please let me know and I can
get those as well.
Upon shutdown or restart (from either the hard button on the case or
a sudo shutdown -r now the system crashes and does not actually
shut down. I can ssh in to the system and a dmesg shows the
following:
There should be a line like:
BUG: Dentry ... still in use (%d) [unmount of %s %s]
just before the oops. Can you please post that one as well? Also I see that
you are using nvidia module which taints the kernel. Can you try
reproducing the issue without the module loaded?
Honza
Here is the full output with no nvidia module. I also have the full
dmeg from start to finish if you would like it.
Thanks for the new report. Since the use count of the problematic dentry
is 1, I guess this is really some bug in rpc_pipefs. Bruce, any idea?
Honza
[ 237.186167] BUG: Dentry 880118772540{i=6e,n=info} still in
use (1) [unmount of rpc_pipefs rpc_pipefs]
[ 237.186179] [ cut here ]
[ 237.186181] kernel BUG at fs/dcache.c:967!
[ 237.186182] invalid opcode: [#1] SMP
[ 237.186185] Modules linked in: nls_utf8 udf crc_itu_t nfsv4
binfmt_misc nfsd nfs_acl auth_rpcgss nfs fscache lockd sunrpc
snd_hda_codec_hdmi snd_hda_codec_realtek xfs snd_hda_intel
snd_hda_codec snd_seq_midi snd_hwdep snd_rawmidi snd_pcm psmouse
snd_seq_midi_event rc_imon_mce serio_raw snd_seq imon rc_core
snd_timer snd_seq_device snd soundcore snd_page_alloc f71882fg r8169
ahci libahci
[ 237.186203] CPU 2
[ 237.186206] Pid: 3063, comm: umount Not tainted 3.6.0 #1 System
manufacturer System Product Name/F1A55-M LX PLUS
[ 237.186208] RIP: 0010:[8116c606] [8116c606]
shrink_dcache_for_umount_subtree+0x1e6/0x1f0
[ 237.186214] RSP: 0018:8801181afd98 EFLAGS: 00010296
[ 237.186215] RAX: 005d RBX: 880118772540 RCX:
14bd
[ 237.186217] RDX: 3256 RSI: 0046 RDI:
81bbf9bc
[ 237.186218] RBP: 8801181afdb8 R08: 000a R09:
[ 237.186219] R10: 0383 R11: 0382 R12:
88011873b9c0
[ 237.186220] R13: 8801177a2b80 R14: 8801177a2bb0 R15:
88011287d800
[ 237.186222] FS: 7f67049b1800() GS:88011ed0()
knlGS:
[ 237.186223] CS: 0010 DS: ES: CR0: 8005003b
[ 237.186225] CR2: 7f3e1de8 CR3: 000118a18000 CR4:
07e0
[ 237.186226] DR0: DR1: DR2:
[ 237.186227] DR3: DR6: 0ff0 DR7:
0400
[ 237.186229] Process umount (pid: 3063, threadinfo
8801181ae000, task 880110fbc440)
[ 237.186230] Stack:
[ 237.186231] 88011287db50 88011873b780 88011287d800
a021d3c0
[ 237.186233] 8801181afdd8 8116de93 0001
88011287d800
[ 237.186235] 8801181afe08 811583bc 88011873b820
0015
[ 237.186238] Call Trace:
[ 237.186241] [8116de93] shrink_dcache_for_umount+0x33/0x60
[ 237.186244] [811583bc] generic_shutdown_super+0x2c/0xf0
[ 237.186247] [81158516] kill_anon_super+0x16/0x30
[ 237.186249] [81158557] kill_litter_super+0x27/0x30
[ 237.186265] [a02174a9] rpc_kill_sb+0x99/0xc0 [sunrpc]
[ 237.186268] [8115877c] deactivate_locked_super+0x3c/0xa0
[ 237.186270] [8115938e] deactivate_super+0x4e/0x70
[ 237.186273] [81174416] mntput_no_expire+0x106/0x160
[ 237.186276] [8117543e] sys_umount+0x6e/0x3b0
[ 237.186279] [81583d96] system_call_fastpath+0x1a/0x1f
[ 237.186280] Code: 00 00 48 8b 40 28 4c 8b 08 48 8b 43 30 48 85 c0
74 04 48 8b 50 40 48 89 34 24 48 c7 c7 48 69 7c 81 48 89 de 31 c0 e8
09 62 40 00 0f 0b 0f 0b 66 0f 1f 44 00 00 55 48 89 e5 41 54 53 66
66 66 66
[ 237.186301] RIP [8116c606]
shrink_dcache_for_umount_subtree+0x1e6/0x1f0
[ 237.186303] RSP 8801181afd98
[ 237.186320] ---[ end trace 74629a120592ec3c ]---
[ 238.707925] mtrr: no MTRR for f900,e0 found
[ 245.162939] imon:send_packet:
Re: [PATCH v3 3/3] acpi : acpi_bus_trim() stops removing devices when failing to remove the device
Hi, ishimatsu:
At 07/12/2012 07:28 PM, Yasuaki Ishimatsu Wrote:
acpi_bus_trim() stops removing devices, when acpi_bus_remove() return error
number. But acpi_bus_remove() cannot return error number correctly.
acpi_bus_remove() only return -EINVAL, when dev argument is NULL. Thus even if
device cannot be removed correctly, acpi_bus_trim() ignores and continues to
remove devices. acpi_bus_hot_remove_device() uses acpi_bus_trim() for removing
devices. Therefore acpi_bus_hot_remove_device() can send _EJ0 to firmware,
even if the device is running on the system. In this case, the system cannot
work well. So acpi_bus_trim() should check whether device was removed or not
correctly. The patch adds error check into some functions to remove the
device.
What is the status about this patch?
Vasilis Liaskovitis found a similar bug about the memory hotplug, and this patch
can fix this problem:
https://lkml.org/lkml/2012/9/26/318
Thanks
Wen Congyang
Signed-off-by: Yasuaki Ishimatsu isimatu.yasu...@jp.fujitsu.com
---
drivers/acpi/scan.c| 15 ---
drivers/base/dd.c | 22 +-
include/linux/device.h |2 +-
3 files changed, 30 insertions(+), 9 deletions(-)
Index: linux-3.5-rc6/drivers/acpi/scan.c
===
--- linux-3.5-rc6.orig/drivers/acpi/scan.c2012-07-12 20:11:37.316443808
+0900
+++ linux-3.5-rc6/drivers/acpi/scan.c 2012-07-12 20:17:17.927185231 +0900
@@ -425,12 +425,17 @@ static int acpi_device_remove(struct dev
{
struct acpi_device *acpi_dev = to_acpi_device(dev);
struct acpi_driver *acpi_drv = acpi_dev-driver;
+ int ret;
if (acpi_drv) {
if (acpi_drv-ops.notify)
acpi_device_remove_notify_handler(acpi_dev);
- if (acpi_drv-ops.remove)
- acpi_drv-ops.remove(acpi_dev, acpi_dev-removal_type);
+ if (acpi_drv-ops.remove) {
+ ret = acpi_drv-ops.remove(acpi_dev,
+acpi_dev-removal_type);
+ if (ret)
+ return ret;
+ }
}
acpi_dev-driver = NULL;
acpi_dev-driver_data = NULL;
@@ -1208,11 +1213,15 @@ static int acpi_device_set_context(struc
static int acpi_bus_remove(struct acpi_device *dev, int rmdevice)
{
+ int ret;
+
if (!dev)
return -EINVAL;
dev-removal_type = ACPI_BUS_REMOVAL_EJECT;
- device_release_driver(dev-dev);
+ ret = device_release_driver(dev-dev);
+ if (ret)
+ return ret;
if (!rmdevice)
return 0;
Index: linux-3.5-rc6/drivers/base/dd.c
===
--- linux-3.5-rc6.orig/drivers/base/dd.c 2012-07-12 20:11:37.316443808
+0900
+++ linux-3.5-rc6/drivers/base/dd.c 2012-07-12 20:17:17.928185218 +0900
@@ -464,9 +464,10 @@ EXPORT_SYMBOL_GPL(driver_attach);
* __device_release_driver() must be called with @dev lock held.
* When called for a USB interface, @dev-parent lock must be held as well.
*/
-static void __device_release_driver(struct device *dev)
+static int __device_release_driver(struct device *dev)
{
struct device_driver *drv;
+ int ret;
drv = dev-driver;
if (drv) {
@@ -482,9 +483,11 @@ static void __device_release_driver(stru
pm_runtime_put_sync(dev);
if (dev-bus dev-bus-remove)
- dev-bus-remove(dev);
+ ret = dev-bus-remove(dev);
else if (drv-remove)
- drv-remove(dev);
+ ret = drv-remove(dev);
+ if (ret)
+ goto rollback;
devres_release_all(dev);
dev-driver = NULL;
klist_remove(dev-p-knode_driver);
@@ -494,6 +497,12 @@ static void __device_release_driver(stru
dev);
}
+
+ return ret;
+
+rollback:
+ driver_sysfs_add(dev);
+ return ret;
}
/**
@@ -503,16 +512,19 @@ static void __device_release_driver(stru
* Manually detach device from driver.
* When called for a USB interface, @dev-parent lock must be held.
*/
-void device_release_driver(struct device *dev)
+int device_release_driver(struct device *dev)
{
+ int ret;
/*
* If anyone calls device_release_driver() recursively from
* within their -remove callback for the same device, they
* will deadlock right here.
*/
device_lock(dev);
- __device_release_driver(dev);
+ ret = __device_release_driver(dev);
device_unlock(dev);
+
+ return ret;
}
EXPORT_SYMBOL_GPL(device_release_driver);
Index: linux-3.5-rc6/include/linux/device.h
RE: [PATCH 00/16] f2fs: introduce flash-friendly file system
--- Jaegeuk Kim Samsung -Original Message- From: Namjae Jeon [mailto:linkinj...@gmail.com] Sent: Tuesday, October 09, 2012 12:52 PM To: Jaegeuk Kim Cc: Vyacheslav Dubeyko; Marco Stornelli; Jaegeuk Kim; Al Viro; ty...@mit.edu; gre...@linuxfoundation.org; linux-kernel@vger.kernel.org; chur@samsung.com; cm224@samsung.com; jooyoung.hw...@samsung.com; linux-fsde...@vger.kernel.org Subject: Re: [PATCH 00/16] f2fs: introduce flash-friendly file system 2012/10/8, Jaegeuk Kim jaegeuk@samsung.com: -Original Message- From: Namjae Jeon [mailto:linkinj...@gmail.com] Sent: Monday, October 08, 2012 8:22 PM To: Jaegeuk Kim Cc: Vyacheslav Dubeyko; Marco Stornelli; Jaegeuk Kim; Al Viro; ty...@mit.edu; gre...@linuxfoundation.org; linux-kernel@vger.kernel.org; chur@samsung.com; cm224@samsung.com; jooyoung.hw...@samsung.com; linux-fsde...@vger.kernel.org Subject: Re: [PATCH 00/16] f2fs: introduce flash-friendly file system 2012/10/8, Jaegeuk Kim jaegeuk@samsung.com: -Original Message- From: Namjae Jeon [mailto:linkinj...@gmail.com] Sent: Monday, October 08, 2012 7:00 PM To: Jaegeuk Kim Cc: Vyacheslav Dubeyko; Marco Stornelli; Jaegeuk Kim; Al Viro; ty...@mit.edu; gre...@linuxfoundation.org; linux-kernel@vger.kernel.org; chur@samsung.com; cm224@samsung.com; jooyoung.hw...@samsung.com; linux-fsde...@vger.kernel.org Subject: Re: [PATCH 00/16] f2fs: introduce flash-friendly file system 2012/10/8, Jaegeuk Kim jaegeuk@samsung.com: -Original Message- From: Vyacheslav Dubeyko [mailto:sl...@dubeyko.com] Sent: Sunday, October 07, 2012 9:09 PM To: Jaegeuk Kim Cc: 'Marco Stornelli'; 'Jaegeuk Kim'; 'Al Viro'; ty...@mit.edu; gre...@linuxfoundation.org; linux- ker...@vger.kernel.org; chur@samsung.com; cm224@samsung.com; jooyoung.hw...@samsung.com; linux-fsde...@vger.kernel.org Subject: Re: [PATCH 00/16] f2fs: introduce flash-friendly file system Hi, On Oct 7, 2012, at 1:31 PM, Jaegeuk Kim wrote: -Original Message- From: Marco Stornelli [mailto:marco.storne...@gmail.com] Sent: Sunday, October 07, 2012 4:10 PM To: Jaegeuk Kim Cc: Vyacheslav Dubeyko; jaegeuk@samsung.com; Al Viro; ty...@mit.edu; gre...@linuxfoundation.org; linux-kernel@vger.kernel.org; chur@samsung.com; cm224@samsung.com; jooyoung.hw...@samsung.com; linux-fsde...@vger.kernel.org Subject: Re: [PATCH 00/16] f2fs: introduce flash-friendly file system Il 06/10/2012 22:06, Jaegeuk Kim ha scritto: 2012-10-06 (토), 17:54 +0400, Vyacheslav Dubeyko: Hi Jaegeuk, Hi. We know each other, right? :) From: 김재극 jaegeuk@samsung.com To:v...@zeniv.linux.org.uk, 'Theodore Ts'o' ty...@mit.edu, gre...@linuxfoundation.org, linux-kernel@vger.kernel.org, chur@samsung.com, cm224@samsung.com, jaegeuk@samsung.com, jooyoung.hw...@samsung.com Subject: [PATCH 00/16] f2fs: introduce flash-friendly file system Date: Fri, 05 Oct 2012 20:55:07 +0900 This is a new patch set for the f2fs file system. What is F2FS? = NAND flash memory-based storage devices, such as SSD, eMMC, and SD cards, have been widely being used for ranging from mobile to server systems. Since they are known to have different characteristics from the conventional rotational disks, a file system, an upper layer to the storage device, should adapt to the changes from the sketch. F2FS is a new file system carefully designed for the NAND flash memory-based storage devices. We chose a log structure file system approach, but we tried to adapt it to the new form of storage. Also we remedy some known issues of the very old log structured file system, such as snowball effect of wandering tree and high cleaning overhead. Because a NAND-based storage device shows different characteristics according to its internal geometry or flash memory management scheme aka FTL, we add various parameters not only for configuring on-disk layout, but also for selecting allocation and cleaning algorithms. What about F2FS performance? Could you share benchmarking results of the new file system? It is very interesting the case of aged file system. How is GC's implementation efficient? Could you share benchmarking results for the very aged file system state? Although I have benchmark results, currently I'd like to see the results measured by community as a black-box. As you know, the
Re: [RFC v9 PATCH 00/21] memory-hotplug: hot-remove physical memory
At 09/27/2012 12:46 AM, Vasilis Liaskovitis Wrote: Hi, I am testing 3.6.0-rc7 with this v9 patchset plus more recent fixes [1],[2],[3] Running in a guest (qemu+seabios from [4]). CONFIG_SLAB=y CONFIG_DEBUG_SLAB=y After succesfull hot-add and online, I am doing a hot-remove with echo 1 /sys/bus/acpi/devices/PNP/eject When I do the OSPM-eject, I often get slab corruption in acpi-state cache, or in other caches The following patch can fix this problem: https://lkml.org/lkml/2012/7/12/186 Thanks Wen Congyang [ 170.566995] Slab corruption (Not tainted): Acpi-State start=88009fc1e548, len=80 [ 170.567265] Redzone: 0x0/0x0. [ 170.567399] Last user: [ (null)](0x0) [ 170.567667] 000: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [ 170.568078] 010: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [ 170.568487] 020: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [ 170.568894] 030: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [ 170.569302] 040: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [ 170.569712] Prev obj: start=9fc1e4d0, len=80 [ 170.569869] BUG: unable to handle kernel paging request at 9fc1e520 [ 170.570171] IP: [8112803c] print_objinfo+0x9c/0x110 [ 170.570397] PGD 7cf37067 PUD 0 [ 170.570619] Oops: [#1] SMP [ 170.570843] Modules linked in: netconsole acpiphp pci_hotplug acpi_memhotplug loop kvm_amd kvm tpm_tis microcode tpm tpm_bios psmouse parport_pc serio_raw evdev parport i2c_piix4 processor thermal_sys i2c_core button ext3 jbd mbcache sg sr_mod cdrom ata_generic virtio_net virtio_blk ata_piix libata scsi_mod virtio_pci virtio_ring virtio [ 170.573474] CPU 0 [ 170.573568] Pid: 29, comm: kworker/0:1 Not tainted 3.6.0-rc7-guest #12 Bochs Bochs [ 170.573830] RIP: 0010:[8112803c] [8112803c] print_objinfo+0x9c/0x110 [ 170.574106] RSP: 0018:88003eaf3a70 EFLAGS: 00010202 [ 170.574268] RAX: 9fc1e4c8 RBX: 0002 RCX: 24b8 [ 170.574468] RDX: 9fc1e4c8 RSI: 9fc1e4c8 RDI: 88003e9bb980 [ 170.574668] RBP: 88003e9bb980 R08: 880037964078 R09: [ 170.574870] R10: 021e R11: 0002 R12: 9fc1e4c8 [ 170.575070] R13: 9fc1e520 R14: 004f R15: ffa5 [ 170.575274] FS: 7fc6b7530700() GS:88003fc0() knlGS: [ 170.575494] CS: 0010 DS: ES: CR0: 8005003b [ 170.575665] CR2: 9fc1e520 CR3: 7c9c1000 CR4: 06f0 [ 170.575870] DR0: DR1: DR2: [ 170.576075] DR3: DR6: 0ff0 DR7: 0400 [ 170.576276] Process kworker/0:1 (pid: 29, threadinfo 88003eaf2000, task 88003ea941c0) [ 170.576507] Stack: [ 170.576599] 0010 01893fbe 88009fc1e000 0050 [ 170.576938] 9fc1e4c8 004f ffa5 8112899f [ 170.576938] 88003eb309d8 81712d6d 88003e9bb980 88009fc1e540 [ 170.576938] Call Trace: [ 170.576938] [8112899f] ? check_poison_obj+0x1df/0x1f0 [ 170.576938] [813047d0] ? acpi_ut_create_generic_state+0x2f/0x4c [ 170.576938] [813047d0] ? acpi_ut_create_generic_state+0x2f/0x4c [ 170.576938] [81128a9d] ? cache_alloc_debugcheck_after.isra.52+0xed/0x220 [ 170.576938] [813047d0] ? acpi_ut_create_generic_state+0x2f/0x4c [ 170.576938] [8112beb5] ? kmem_cache_alloc+0xb5/0x1e0 [ 170.576938] [813047d0] ? acpi_ut_create_generic_state+0x2f/0x4c [ 170.576938] [812edf2d] ? acpi_ds_result_push+0x5d/0x12e [ 170.576938] [812ed127] ? acpi_ds_exec_end_op+0x28e/0x3d3 [ 170.576938] [812fd86a] ? acpi_ps_parse_loop+0x79f/0x931 [ 170.576938] [812fdd6c] ? acpi_ps_parse_aml+0x89/0x261 [ 170.576938] [812fe50c] ? acpi_ps_execute_method+0x1be/0x266 [ 170.576938] [812f91f7] ? acpi_ns_evaluate+0xd3/0x19a [ 170.576938] [812fb93e] ? acpi_evaluate_object+0xf3/0x1f4 [ 170.576938] [812e1104] ? acpi_os_wait_events_complete+0x1b/0x1b [ 170.576938] [812e4782] ? acpi_bus_hot_remove_device+0xeb/0x123 [ 170.576938] [812e1121] ? acpi_os_execute_deferred+0x1d/0x29 [ 170.576938] [81058ec5] ? process_one_work+0x125/0x560 [ 170.576938] [81059e7a] ? worker_thread+0x16a/0x4e0 [ 170.576938] [81059d10] ? manage_workers+0x310/0x310 [ 170.576938] [8105e6c5] ? kthread+0x85/0x90 [ 170.576938] [814eb2c4] ? kernel_thread_helper+0x4/0x10 [ 170.576938] [8105e640] ? flush_kthread_worker+0xa0/0xa0 [ 170.576938] [814eb2c0] ? gs_change+0x13/0x13 [ 170.576938] Code:
Re: PROBLEM: 3.6.0 kernel BUG at fs/dcache.c:967 during shutdown / restart
09.10.2012 11:54, Jan Kara пишет:
On Mon 08-10-12 17:10:52, Neil Salstrom wrote:
On 10/08/2012 10:14 AM, Jan Kara wrote:
On Sat 06-10-12 10:20:26, Neil Salstrom wrote:
I've not submitted a kernel bug before but I've read the bug
reporting pages. I'll try to do my best and if you need more
information please let me know. Please feel free to cc me on the
answer or if you have questions.
I'm using Linux Mint 13 (64 bit) on AMD hardware with a self
compiled 3.6.0 kernel for my MythTV HTPC.
Kernel version: Linux version 3.6.0 (gcc version 4.6.3
(Ubuntu/Linaro 4.6.3-1ubuntu5) ) #1 SMP Tue Oct 2 15:34:46 PDT 2012
CPU: model name : AMD A6-3500 APU with Radeon(tm) HD Graphics
If you need any other system variables please let me know and I can
get those as well.
Upon shutdown or restart (from either the hard button on the case or
a sudo shutdown -r now the system crashes and does not actually
shut down. I can ssh in to the system and a dmesg shows the
following:
There should be a line like:
BUG: Dentry ... still in use (%d) [unmount of %s %s]
just before the oops. Can you please post that one as well? Also I see that
you are using nvidia module which taints the kernel. Can you try
reproducing the issue without the module loaded?
Honza
Here is the full output with no nvidia module. I also have the full
dmeg from start to finish if you would like it.
Thanks for the new report. Since the use count of the problematic dentry
is 1, I guess this is really some bug in rpc_pipefs. Bruce, any idea?
Hi.
Could you, please, give more details about your configuration.
Currently, PipeFS is mounted on SUNRPC module install.
Would be great to understand, what process tries to umount it and when.
Also, do you have NFS mounts on the node, then Pipefs is umounting?
Is systemd is active on your node?
Could you trigger this panic manually?
Honza
[ 237.186167] BUG: Dentry 880118772540{i=6e,n=info} still in
use (1) [unmount of rpc_pipefs rpc_pipefs]
[ 237.186179] [ cut here ]
[ 237.186181] kernel BUG at fs/dcache.c:967!
[ 237.186182] invalid opcode: [#1] SMP
[ 237.186185] Modules linked in: nls_utf8 udf crc_itu_t nfsv4
binfmt_misc nfsd nfs_acl auth_rpcgss nfs fscache lockd sunrpc
snd_hda_codec_hdmi snd_hda_codec_realtek xfs snd_hda_intel
snd_hda_codec snd_seq_midi snd_hwdep snd_rawmidi snd_pcm psmouse
snd_seq_midi_event rc_imon_mce serio_raw snd_seq imon rc_core
snd_timer snd_seq_device snd soundcore snd_page_alloc f71882fg r8169
ahci libahci
[ 237.186203] CPU 2
[ 237.186206] Pid: 3063, comm: umount Not tainted 3.6.0 #1 System
manufacturer System Product Name/F1A55-M LX PLUS
[ 237.186208] RIP: 0010:[8116c606] [8116c606]
shrink_dcache_for_umount_subtree+0x1e6/0x1f0
[ 237.186214] RSP: 0018:8801181afd98 EFLAGS: 00010296
[ 237.186215] RAX: 005d RBX: 880118772540 RCX:
14bd
[ 237.186217] RDX: 3256 RSI: 0046 RDI:
81bbf9bc
[ 237.186218] RBP: 8801181afdb8 R08: 000a R09:
[ 237.186219] R10: 0383 R11: 0382 R12:
88011873b9c0
[ 237.186220] R13: 8801177a2b80 R14: 8801177a2bb0 R15:
88011287d800
[ 237.186222] FS: 7f67049b1800() GS:88011ed0()
knlGS:
[ 237.186223] CS: 0010 DS: ES: CR0: 8005003b
[ 237.186225] CR2: 7f3e1de8 CR3: 000118a18000 CR4:
07e0
[ 237.186226] DR0: DR1: DR2:
[ 237.186227] DR3: DR6: 0ff0 DR7:
0400
[ 237.186229] Process umount (pid: 3063, threadinfo
8801181ae000, task 880110fbc440)
[ 237.186230] Stack:
[ 237.186231] 88011287db50 88011873b780 88011287d800
a021d3c0
[ 237.186233] 8801181afdd8 8116de93 0001
88011287d800
[ 237.186235] 8801181afe08 811583bc 88011873b820
0015
[ 237.186238] Call Trace:
[ 237.186241] [8116de93] shrink_dcache_for_umount+0x33/0x60
[ 237.186244] [811583bc] generic_shutdown_super+0x2c/0xf0
[ 237.186247] [81158516] kill_anon_super+0x16/0x30
[ 237.186249] [81158557] kill_litter_super+0x27/0x30
[ 237.186265] [a02174a9] rpc_kill_sb+0x99/0xc0 [sunrpc]
[ 237.186268] [8115877c] deactivate_locked_super+0x3c/0xa0
[ 237.186270] [8115938e] deactivate_super+0x4e/0x70
[ 237.186273] [81174416] mntput_no_expire+0x106/0x160
[ 237.186276] [8117543e] sys_umount+0x6e/0x3b0
[ 237.186279] [81583d96] system_call_fastpath+0x1a/0x1f
[ 237.186280] Code: 00 00 48 8b 40 28 4c 8b 08 48 8b 43 30 48 85 c0
74 04 48 8b 50 40 48 89 34 24 48 c7 c7 48 69 7c 81 48 89 de 31 c0 e8
09 62 40 00 0f 0b 0f 0b 66 0f 1f 44 00 00 55 48 89
[PATCH] thermal: rcar: fixup compilation errors
This patch fixup following error
${LINUX}/drivers/thermal/rcar_thermal.c: In function 'rcar_thermal_probe':
${LINUX}/drivers/thermal/rcar_thermal.c:214:9: warning: passing argument 3 \
of 'thermal_zone_device_register' makes integer from pointer without\
a cast [enabled by default]
${LINUX}/include/linux/thermal.h:215:29: note: expected 'int' but argument \
is of type 'struct rcar_thermal_priv *'
${LINUX}/drivers/thermal/rcar_thermal.c:214:9:\
error: too few arguments to function 'thermal_zone_device_register'
Signed-off-by: Devendra Naga develkernel412...@gmail.com
Signed-off-by: Kuninori Morimoto kuninori.morimoto...@renesas.com
---
for linus/master branch
drivers/thermal/rcar_thermal.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/thermal/rcar_thermal.c b/drivers/thermal/rcar_thermal.c
index b13fe5d..762f637 100644
--- a/drivers/thermal/rcar_thermal.c
+++ b/drivers/thermal/rcar_thermal.c
@@ -210,7 +210,7 @@ static int rcar_thermal_probe(struct platform_device *pdev)
goto error_free_priv;
}
- zone = thermal_zone_device_register(rcar_thermal, 0, priv,
+ zone = thermal_zone_device_register(rcar_thermal, 0, 0, priv,
rcar_thermal_zone_ops, NULL, 0, 0);
if (IS_ERR(zone)) {
dev_err(pdev-dev, thermal zone device is NULL\n);
--
1.7.9.5
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] firmware: Don't attempt to allocate zero bytes with vmalloc()
On Tue, Oct 09, 2012 at 03:34:52PM +0800, Ming Lei wrote: Yes, I agree, and my question is only on what you mentioned: it didn't want to load an optional image maybe I misunderstood the above, never mind, :-) So one driver should suppose the firmware is there, and the firmware shouldn't be zero length, because the driver always expects getting some bytes by calling request_firmware(). The point is that there's some firmware which the driver wants to load but where it's happy to continue if the user didn't provide one and doesn't want to introduce needless delays. -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v3 3/3] acpi : acpi_bus_trim() stops removing devices when failing to remove the device
Hi Wen,
2012/10/09 17:02, Wen Congyang wrote:
Hi, ishimatsu:
At 07/12/2012 07:28 PM, Yasuaki Ishimatsu Wrote:
acpi_bus_trim() stops removing devices, when acpi_bus_remove() return error
number. But acpi_bus_remove() cannot return error number correctly.
acpi_bus_remove() only return -EINVAL, when dev argument is NULL. Thus even if
device cannot be removed correctly, acpi_bus_trim() ignores and continues to
remove devices. acpi_bus_hot_remove_device() uses acpi_bus_trim() for removing
devices. Therefore acpi_bus_hot_remove_device() can send _EJ0 to firmware,
even if the device is running on the system. In this case, the system cannot
work well. So acpi_bus_trim() should check whether device was removed or not
correctly. The patch adds error check into some functions to remove the device.
What is the status about this patch?
I need to update the description against Toshi's comment as follows:
I agree with this change as driver's remove interface can fail.
However, there are other callers to this function, which do not check
the return value. I suppose there is no impact to the other paths since
you only changed the CPU hotplug path to fail properly, but please
confirm this is the case. I recommend documenting this change to the
change log.
I have already checked that the patch does not impact the other path
with the exception of CPU and Memory hotplug path. So I will adds the
result of investigation and following Vasislis's problem into the patch
and resend to lklml.
Vasilis Liaskovitis found a similar bug about the memory hotplug, and this patch
can fix this problem:
https://lkml.org/lkml/2012/9/26/318
Thanks,
Yasuaki Ishimatsu
Thanks
Wen Congyang
Signed-off-by: Yasuaki Ishimatsu isimatu.yasu...@jp.fujitsu.com
---
drivers/acpi/scan.c| 15 ---
drivers/base/dd.c | 22 +-
include/linux/device.h |2 +-
3 files changed, 30 insertions(+), 9 deletions(-)
Index: linux-3.5-rc6/drivers/acpi/scan.c
===
--- linux-3.5-rc6.orig/drivers/acpi/scan.c 2012-07-12 20:11:37.316443808
+0900
+++ linux-3.5-rc6/drivers/acpi/scan.c 2012-07-12 20:17:17.927185231 +0900
@@ -425,12 +425,17 @@ static int acpi_device_remove(struct dev
{
struct acpi_device *acpi_dev = to_acpi_device(dev);
struct acpi_driver *acpi_drv = acpi_dev-driver;
+ int ret;
if (acpi_drv) {
if (acpi_drv-ops.notify)
acpi_device_remove_notify_handler(acpi_dev);
- if (acpi_drv-ops.remove)
- acpi_drv-ops.remove(acpi_dev, acpi_dev-removal_type);
+ if (acpi_drv-ops.remove) {
+ ret = acpi_drv-ops.remove(acpi_dev,
+ acpi_dev-removal_type);
+ if (ret)
+ return ret;
+ }
}
acpi_dev-driver = NULL;
acpi_dev-driver_data = NULL;
@@ -1208,11 +1213,15 @@ static int acpi_device_set_context(struc
static int acpi_bus_remove(struct acpi_device *dev, int rmdevice)
{
+ int ret;
+
if (!dev)
return -EINVAL;
dev-removal_type = ACPI_BUS_REMOVAL_EJECT;
- device_release_driver(dev-dev);
+ ret = device_release_driver(dev-dev);
+ if (ret)
+ return ret;
if (!rmdevice)
return 0;
Index: linux-3.5-rc6/drivers/base/dd.c
===
--- linux-3.5-rc6.orig/drivers/base/dd.c2012-07-12 20:11:37.316443808
+0900
+++ linux-3.5-rc6/drivers/base/dd.c 2012-07-12 20:17:17.928185218 +0900
@@ -464,9 +464,10 @@ EXPORT_SYMBOL_GPL(driver_attach);
* __device_release_driver() must be called with @dev lock held.
* When called for a USB interface, @dev-parent lock must be held as well.
*/
-static void __device_release_driver(struct device *dev)
+static int __device_release_driver(struct device *dev)
{
struct device_driver *drv;
+ int ret;
drv = dev-driver;
if (drv) {
@@ -482,9 +483,11 @@ static void __device_release_driver(stru
pm_runtime_put_sync(dev);
if (dev-bus dev-bus-remove)
- dev-bus-remove(dev);
+ ret = dev-bus-remove(dev);
else if (drv-remove)
- drv-remove(dev);
+ ret = drv-remove(dev);
+ if (ret)
+ goto rollback;
devres_release_all(dev);
dev-driver = NULL;
klist_remove(dev-p-knode_driver);
@@ -494,6 +497,12 @@ static void __device_release_driver(stru
dev);
}
+
+ return ret;
+
+rollback:
+ driver_sysfs_add(dev);
+ return ret;
}
/**
@@ -503,16 +512,19 @@ static void
Re: [PATCH 8/10] memory-hotplug : remove page table of x86_64 architecture
Hi Congyang,
I think we should also free pages which are used by page tables after
removing
page tables of the memory.
From: Jianguo Wu wujian...@huawei.com
Signed-off-by: Jianguo Wu wujian...@huawei.com
Signed-off-by: Jiang Liu jiang@huawei.com
---
arch/x86/mm/init_64.c | 110 +++-
1 files changed, 89 insertions(+), 21 deletions(-)
diff --git a/arch/x86/mm/init_64.c b/arch/x86/mm/init_64.c
index 5596dfa..81f9c3b 100644
--- a/arch/x86/mm/init_64.c
+++ b/arch/x86/mm/init_64.c
@@ -675,6 +675,74 @@ int arch_add_memory(int nid, u64 start, u64 size)
}
EXPORT_SYMBOL_GPL(arch_add_memory);
+static inline void free_pagetable(struct page *page)
+{
+ struct zone *zone;
+
+ __ClearPageReserved(page);
+ __free_page(page);
+
+ zone = page_zone(page);
+ zone_span_writelock(zone);
+ zone-present_pages++;
+ zone_span_writeunlock(zone);
+ totalram_pages++;
+}
+
+static void free_pte_table(pte_t *pte_start, pmd_t *pmd)
+{
+ pte_t *pte;
+ int i;
+
+ for (i = 0; i PTRS_PER_PTE; i++) {
+ pte = pte_start + i;
+ if (pte_val(*pte))
+ break;
+ }
+
+ /* free a pte talbe */
+ if (i == PTRS_PER_PTE) {
+ free_pagetable(pmd_page(*pmd));
+ pmd_clear(pmd);
+ }
+}
+
+static void free_pmd_table(pmd_t *pmd_start, pud_t *pud)
+{
+ pmd_t *pmd;
+ int i;
+
+ for (i = 0; i PTRS_PER_PMD; i++) {
+ pmd = pmd_start + i;
+ if (pmd_val(*pmd))
+ break;
+ }
+
+ /* free a pmd talbe */
+ if (i == PTRS_PER_PMD) {
+ free_pagetable(pud_page(*pud));
+ pud_clear(pud);
+ }
+}
+
+static void free_pud_table(pud_t *pud_start, pgd_t *pgd)
+{
+ pud_t *pud;
+ int i;
+
+ for (i = 0; i PTRS_PER_PUD; i++) {
+ pud = pud_start + i;
+ if (pud_val(*pud))
+ break;
+ }
+
+ /* free a pud table */
+ if (i == PTRS_PER_PUD) {
+ free_pagetable(pgd_page(*pgd));
+ pgd_clear(pgd);
+ }
+}
+
static void __meminit
phys_pte_remove(pte_t *pte_page, unsigned long addr, unsigned long end)
{
@@ -704,21 +772,19 @@ phys_pmd_remove(pmd_t *pmd_page, unsigned long addr,
unsigned long end)
unsigned long pages = 0, next;
int i = pmd_index(addr);
- for (; i PTRS_PER_PMD; i++, addr = next) {
+ for (; i PTRS_PER_PMD addr end; i++, addr = next) {
unsigned long pte_phys;
pmd_t *pmd = pmd_page + pmd_index(addr);
pte_t *pte;
- if (addr = end)
- break;
-
- next = (addr PMD_MASK) + PMD_SIZE;
+ next = pmd_addr_end(addr, end);
if (!pmd_present(*pmd))
continue;
if (pmd_large(*pmd)) {
- if ((addr ~PMD_MASK) == 0 next = end) {
+ if (IS_ALIGNED(addr, PMD_SIZE)
+ IS_ALIGNED(next, PMD_SIZE)) {
set_pmd(pmd, __pmd(0));
pages++;
continue;
@@ -729,7 +795,8 @@ phys_pmd_remove(pmd_t *pmd_page, unsigned long addr,
unsigned long end)
* so split 2M page to 4K page.
*/
pte = alloc_low_page(pte_phys);
- __split_large_page((pte_t *)pmd, addr, pte);
+ __split_large_page((pte_t *)pmd,
+ (unsigned long)__va(addr), pte);
spin_lock(init_mm.page_table_lock);
pmd_populate_kernel(init_mm, pmd, __va(pte_phys));
@@ -738,7 +805,8 @@ phys_pmd_remove(pmd_t *pmd_page, unsigned long addr,
unsigned long end)
spin_lock(init_mm.page_table_lock);
pte = map_low_page((pte_t *)pmd_page_vaddr(*pmd));
- phys_pte_remove(pte, addr, end);
+ phys_pte_remove(pte, addr, next);
+ free_pte_table(pte, pmd);
unmap_low_page(pte);
spin_unlock(init_mm.page_table_lock);
}
@@ -751,21 +819,19 @@ phys_pud_remove(pud_t *pud_page, unsigned long addr,
unsigned long end)
unsigned long pages = 0, next;
int i = pud_index(addr);
- for (; i PTRS_PER_PUD; i++, addr = next) {
+ for (; i PTRS_PER_PUD addr end; i++, addr = next) {
unsigned long pmd_phys;
pud_t *pud = pud_page + pud_index(addr);
pmd_t *pmd;
- if (addr = end)
- break;
-
- next = (addr PUD_MASK) + PUD_SIZE;
+ next = pud_addr_end(addr, end);
if (!pud_present(*pud))
continue;
