[PATCH] thermal: consistently use int for temperatures
The thermal code uses int, long and unsigned long for temperatures
in different places.
Using an unsigned type limits the thermal framework to positive
temperatures without need. Also several drivers currently will report
temperatures near UINT_MAX for temperatures below 0°C. This will probably
immediately shut the machine down due to overtemperature if started below
0°C.
'long' is 64bit on several architectures. This is not needed since INT_MAX °mC
is above the melting point of all known materials.
Consistently use a plain 'int' for temperatures throughout the thermal code and
the drivers. This only changes the places in the drivers where the temperature
is passed around as pointer, when drivers internally use another type this is
not changed.
Signed-off-by: Sascha Hauer
Cc: Zhang Rui
Cc: Eduardo Valentin
Cc: linux...@vger.kernel.org
Cc: linux-ker...@vger.kernel.org
Cc: Jean Delvare
Cc: Peter Feuerer
Cc: Heiko Stuebner
Cc: Lukasz Majewski
Cc: Stephen Warren
Cc: Thierry Reding
Cc: linux-a...@vger.kernel.org
Cc: platform-driver-...@vger.kernel.org
Cc: linux-arm-ker...@lists.infradead.org
Cc: linux-o...@vger.kernel.org
Cc: linux-samsung-soc@vger.kernel.org
Cc: Guenter Roeck
Cc: Rafael J. Wysocki
Cc: Maxime Ripard
Cc: Darren Hart
Cc: lm-sens...@lm-sensors.org
---
drivers/acpi/thermal.c | 12 +-
drivers/hwmon/lm75.c | 2 +-
drivers/hwmon/ntc_thermistor.c | 2 +-
drivers/hwmon/tmp102.c | 2 +-
drivers/input/touchscreen/sun4i-ts.c | 8 +++
drivers/platform/x86/acerhdf.c | 9
drivers/platform/x86/intel_mid_thermal.c | 9
drivers/power/power_supply_core.c | 2 +-
drivers/thermal/armada_thermal.c | 2 +-
drivers/thermal/db8500_thermal.c | 7 +++---
drivers/thermal/dove_thermal.c | 2 +-
drivers/thermal/fair_share.c | 2 +-
drivers/thermal/gov_bang_bang.c| 5 ++--
drivers/thermal/hisi_thermal.c | 4 ++--
drivers/thermal/imx_thermal.c | 27 +++---
drivers/thermal/int340x_thermal/int3400_thermal.c | 2 +-
.../thermal/int340x_thermal/int340x_thermal_zone.c | 10
.../thermal/int340x_thermal/int340x_thermal_zone.h | 8 +++
.../int340x_thermal/processor_thermal_device.c | 4 ++--
drivers/thermal/intel_quark_dts_thermal.c | 13 +--
drivers/thermal/intel_soc_dts_iosf.c | 8 +++
drivers/thermal/kirkwood_thermal.c | 2 +-
drivers/thermal/of-thermal.c | 14 +--
drivers/thermal/power_allocator.c | 16 ++---
drivers/thermal/qcom-spmi-temp-alarm.c | 2 +-
drivers/thermal/rcar_thermal.c | 7 +++---
drivers/thermal/rockchip_thermal.c | 10
drivers/thermal/samsung/exynos_tmu.c | 23 +-
drivers/thermal/spear_thermal.c| 2 +-
drivers/thermal/st/st_thermal.c| 5 ++--
drivers/thermal/step_wise.c| 4 ++--
drivers/thermal/tegra_soctherm.c | 4 ++--
drivers/thermal/thermal_core.c | 26 ++---
drivers/thermal/thermal_hwmon.c| 10
drivers/thermal/ti-soc-thermal/ti-thermal-common.c | 10
drivers/thermal/x86_pkg_temp_thermal.c | 10
include/linux/thermal.h| 26 +
37 files changed, 148 insertions(+), 163 deletions(-)
diff --git a/drivers/acpi/thermal.c b/drivers/acpi/thermal.c
index 6d4e44e..e66ad25 100644
--- a/drivers/acpi/thermal.c
+++ b/drivers/acpi/thermal.c
@@ -529,8 +529,7 @@ static void acpi_thermal_check(void *data)
/* sys I/F for generic thermal sysfs support */
-static int thermal_get_temp(struct thermal_zone_device *thermal,
- unsigned long *temp)
+static int thermal_get_temp(struct thermal_zone_device *thermal, int *temp)
{
struct acpi_thermal *tz = thermal->devdata;
int result;
@@ -637,7 +636,7 @@ static int thermal_get_trip_type(struct thermal_zone_device
*thermal,
}
static int thermal_get_trip_temp(struct thermal_zone_device *thermal,
-int trip, unsigned long *temp)
+int trip, int *temp)
{
struct acpi_thermal *tz = thermal->devdata;
int i;
@@ -690,7 +689,8 @@ static int thermal_get_trip_temp(struct thermal_zone_device
*thermal,
}
static int thermal_get_crit_temp(struct thermal_zone_device *thermal,
- unsigned long *temperature) {
+ int *temperature)
+{
struct acpi_thermal *tz = thermal->devdata;
if (tz
Re: [PATCH] thermal: consistently use int for temperatures
On Mon, Jul 6, 2015 at 9:19 AM, Sascha Hauer wrote:
> The thermal code uses int, long and unsigned long for temperatures
> in different places.
>
> Using an unsigned type limits the thermal framework to positive
> temperatures without need. Also several drivers currently will report
> temperatures near UINT_MAX for temperatures below 0°C. This will probably
> immediately shut the machine down due to overtemperature if started below
> 0°C.
>
> 'long' is 64bit on several architectures. This is not needed since INT_MAX °mC
> is above the melting point of all known materials.
>
> Consistently use a plain 'int' for temperatures throughout the thermal code
> and
> the drivers. This only changes the places in the drivers where the temperature
> is passed around as pointer, when drivers internally use another type this is
> not changed.
>
> Signed-off-by: Sascha Hauer
> Cc: Zhang Rui
> Cc: Eduardo Valentin
> Cc: linux...@vger.kernel.org
> Cc: linux-ker...@vger.kernel.org
> Cc: Jean Delvare
> Cc: Peter Feuerer
> Cc: Heiko Stuebner
> Cc: Lukasz Majewski
> Cc: Stephen Warren
> Cc: Thierry Reding
> Cc: linux-a...@vger.kernel.org
> Cc: platform-driver-...@vger.kernel.org
> Cc: linux-arm-ker...@lists.infradead.org
> Cc: linux-o...@vger.kernel.org
> Cc: linux-samsung-soc@vger.kernel.org
> Cc: Guenter Roeck
> Cc: Rafael J. Wysocki
> Cc: Maxime Ripard
> Cc: Darren Hart
> Cc: lm-sens...@lm-sensors.org
For rcar-thermal:
Acked-by: Geert Uytterhoeven
> diff --git a/drivers/thermal/rcar_thermal.c b/drivers/thermal/rcar_thermal.c
> index fe4e767..5d4ae7d 100644
> --- a/drivers/thermal/rcar_thermal.c
> +++ b/drivers/thermal/rcar_thermal.c
> @@ -200,8 +200,7 @@ err_out_unlock:
> return ret;
> }
>
> -static int rcar_thermal_get_temp(struct thermal_zone_device *zone,
> -unsigned long *temp)
> +static int rcar_thermal_get_temp(struct thermal_zone_device *zone, int *temp)
> {
> struct rcar_thermal_priv *priv = rcar_zone_to_priv(zone);
>
> @@ -235,7 +234,7 @@ static int rcar_thermal_get_trip_type(struct
> thermal_zone_device *zone,
> }
>
> static int rcar_thermal_get_trip_temp(struct thermal_zone_device *zone,
> - int trip, unsigned long *temp)
> + int trip, int *temp)
> {
> struct rcar_thermal_priv *priv = rcar_zone_to_priv(zone);
> struct device *dev = rcar_priv_to_dev(priv);
> @@ -299,7 +298,7 @@ static void _rcar_thermal_irq_ctrl(struct
> rcar_thermal_priv *priv, int enable)
> static void rcar_thermal_work(struct work_struct *work)
> {
> struct rcar_thermal_priv *priv;
> - unsigned long cctemp, nctemp;
> + int cctemp, nctemp;
>
> priv = container_of(work, struct rcar_thermal_priv, work.work);
>
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] thermal: consistently use int for temperatures
On Mon, 6 Jul 2015 09:19:49 +0200, Sascha Hauer wrote: > The thermal code uses int, long and unsigned long for temperatures > in different places. > > Using an unsigned type limits the thermal framework to positive > temperatures without need. Also several drivers currently will report > temperatures near UINT_MAX for temperatures below 0°C. This will probably > immediately shut the machine down due to overtemperature if started below > 0°C. > > 'long' is 64bit on several architectures. This is not needed since INT_MAX °mC > is above the melting point of all known materials. > > Consistently use a plain 'int' for temperatures throughout the thermal code > and > the drivers. This only changes the places in the drivers where the temperature > is passed around as pointer, when drivers internally use another type this is > not changed. > > Signed-off-by: Sascha Hauer > Cc: Zhang Rui > Cc: Eduardo Valentin > Cc: linux...@vger.kernel.org > Cc: linux-ker...@vger.kernel.org > Cc: Jean Delvare > Cc: Peter Feuerer > Cc: Heiko Stuebner > Cc: Lukasz Majewski > Cc: Stephen Warren > Cc: Thierry Reding > Cc: linux-a...@vger.kernel.org > Cc: platform-driver-...@vger.kernel.org > Cc: linux-arm-ker...@lists.infradead.org > Cc: linux-o...@vger.kernel.org > Cc: linux-samsung-soc@vger.kernel.org > Cc: Guenter Roeck > Cc: Rafael J. Wysocki > Cc: Maxime Ripard > Cc: Darren Hart > Cc: lm-sens...@lm-sensors.org > --- > drivers/acpi/thermal.c | 12 +- > drivers/hwmon/lm75.c | 2 +- > drivers/hwmon/ntc_thermistor.c | 2 +- > drivers/hwmon/tmp102.c | 2 +- > drivers/input/touchscreen/sun4i-ts.c | 8 +++ > drivers/platform/x86/acerhdf.c | 9 > drivers/platform/x86/intel_mid_thermal.c | 9 > drivers/power/power_supply_core.c | 2 +- > drivers/thermal/armada_thermal.c | 2 +- > drivers/thermal/db8500_thermal.c | 7 +++--- > drivers/thermal/dove_thermal.c | 2 +- > drivers/thermal/fair_share.c | 2 +- > drivers/thermal/gov_bang_bang.c| 5 ++-- > drivers/thermal/hisi_thermal.c | 4 ++-- > drivers/thermal/imx_thermal.c | 27 > +++--- > drivers/thermal/int340x_thermal/int3400_thermal.c | 2 +- > .../thermal/int340x_thermal/int340x_thermal_zone.c | 10 > .../thermal/int340x_thermal/int340x_thermal_zone.h | 8 +++ > .../int340x_thermal/processor_thermal_device.c | 4 ++-- > drivers/thermal/intel_quark_dts_thermal.c | 13 +-- > drivers/thermal/intel_soc_dts_iosf.c | 8 +++ > drivers/thermal/kirkwood_thermal.c | 2 +- > drivers/thermal/of-thermal.c | 14 +-- > drivers/thermal/power_allocator.c | 16 ++--- > drivers/thermal/qcom-spmi-temp-alarm.c | 2 +- > drivers/thermal/rcar_thermal.c | 7 +++--- > drivers/thermal/rockchip_thermal.c | 10 > drivers/thermal/samsung/exynos_tmu.c | 23 +- > drivers/thermal/spear_thermal.c| 2 +- > drivers/thermal/st/st_thermal.c| 5 ++-- > drivers/thermal/step_wise.c| 4 ++-- > drivers/thermal/tegra_soctherm.c | 4 ++-- > drivers/thermal/thermal_core.c | 26 ++--- > drivers/thermal/thermal_hwmon.c| 10 > drivers/thermal/ti-soc-thermal/ti-thermal-common.c | 10 > drivers/thermal/x86_pkg_temp_thermal.c | 10 > include/linux/thermal.h| 26 + > 37 files changed, 148 insertions(+), 163 deletions(-) > (...) No objection from me. For the hwmon parts: Reviewed-by: Jean Delvare -- Jean Delvare SUSE L3 Support -- To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] thermal: consistently use int for temperatures
Hi Sascha, > The thermal code uses int, long and unsigned long for temperatures > in different places. > > Using an unsigned type limits the thermal framework to positive > temperatures without need. Also several drivers currently will report > temperatures near UINT_MAX for temperatures below 0°C. This will > probably immediately shut the machine down due to overtemperature if > started below 0°C. > > 'long' is 64bit on several architectures. This is not needed since > INT_MAX °mC is above the melting point of all known materials. > > Consistently use a plain 'int' for temperatures throughout the > thermal code and the drivers. This only changes the places in the > drivers where the temperature is passed around as pointer, when > drivers internally use another type this is not changed. > > Signed-off-by: Sascha Hauer Sascha, thanks for this cleanup work. Reviewed-by: Lukasz Majewski -- Best regards, Lukasz Majewski Samsung R&D Institute Poland (SRPOL) | Linux Platform Group -- To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] thermal: consistently use int for temperatures
On Mon, Jul 06, 2015 at 09:19:49AM +0200, Sascha Hauer wrote: > The thermal code uses int, long and unsigned long for temperatures > in different places. > > Using an unsigned type limits the thermal framework to positive > temperatures without need. Also several drivers currently will report > temperatures near UINT_MAX for temperatures below 0°C. This will probably > immediately shut the machine down due to overtemperature if started below > 0°C. > > 'long' is 64bit on several architectures. This is not needed since INT_MAX °mC > is above the melting point of all known materials. > > Consistently use a plain 'int' for temperatures throughout the thermal code > and > the drivers. This only changes the places in the drivers where the temperature > is passed around as pointer, when drivers internally use another type this is > not changed. > > Signed-off-by: Sascha Hauer ... > drivers/platform/x86/acerhdf.c | 9 > drivers/platform/x86/intel_mid_thermal.c | 9 For these two: Reviewed-by: Darren Hart -- Darren Hart Intel Open Source Technology Center -- To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] thermal: consistently use int for temperatures
Am Montag, 6. Juli 2015, 09:19:49 schrieb Sascha Hauer: > The thermal code uses int, long and unsigned long for temperatures > in different places. > > Using an unsigned type limits the thermal framework to positive > temperatures without need. Also several drivers currently will report > temperatures near UINT_MAX for temperatures below 0°C. This will probably > immediately shut the machine down due to overtemperature if started below > 0°C. > > 'long' is 64bit on several architectures. This is not needed since INT_MAX > °mC is above the melting point of all known materials. > > Consistently use a plain 'int' for temperatures throughout the thermal code > and the drivers. This only changes the places in the drivers where the > temperature is passed around as pointer, when drivers internally use > another type this is not changed. > > Signed-off-by: Sascha Hauer > Cc: Zhang Rui > Cc: Eduardo Valentin > Cc: linux...@vger.kernel.org > Cc: linux-ker...@vger.kernel.org > Cc: Jean Delvare > Cc: Peter Feuerer > Cc: Heiko Stuebner > Cc: Lukasz Majewski > Cc: Stephen Warren > Cc: Thierry Reding > Cc: linux-a...@vger.kernel.org > Cc: platform-driver-...@vger.kernel.org > Cc: linux-arm-ker...@lists.infradead.org > Cc: linux-o...@vger.kernel.org > Cc: linux-samsung-soc@vger.kernel.org > Cc: Guenter Roeck > Cc: Rafael J. Wysocki > Cc: Maxime Ripard > Cc: Darren Hart > Cc: lm-sens...@lm-sensors.org > --- For > drivers/thermal/rockchip_thermal.c | 10 Reviewed-by: Heiko Stuebner -- To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] thermal: consistently use int for temperatures
Sascha Hauer writes: The thermal code uses int, long and unsigned long for temperatures in different places. Using an unsigned type limits the thermal framework to positive temperatures without need. Also several drivers currently will report temperatures near UINT_MAX for temperatures below 0°C. This will probably immediately shut the machine down due to overtemperature if started below 0°C. 'long' is 64bit on several architectures. This is not needed since INT_MAX °mC is above the melting point of all known materials. Consistently use a plain 'int' for temperatures throughout the thermal code and the drivers. This only changes the places in the drivers where the temperature is passed around as pointer, when drivers internally use another type this is not changed. Signed-off-by: Sascha Hauer Cc: Zhang Rui Cc: Eduardo Valentin Cc: linux...@vger.kernel.org Cc: linux-ker...@vger.kernel.org Cc: Jean Delvare Cc: Peter Feuerer Cc: Heiko Stuebner Cc: Lukasz Majewski Cc: Stephen Warren Cc: Thierry Reding Cc: linux-a...@vger.kernel.org Cc: platform-driver-...@vger.kernel.org Cc: linux-arm-ker...@lists.infradead.org Cc: linux-o...@vger.kernel.org Cc: linux-samsung-soc@vger.kernel.org Cc: Guenter Roeck Cc: Rafael J. Wysocki Cc: Maxime Ripard Cc: Darren Hart Cc: lm-sens...@lm-sensors.org --- [...] For: drivers/platform/x86/acerhdf.c | 9 drivers/thermal/gov_bang_bang.c| 5 ++-- Reviewed-by: Peter Feuerer [...] -- --peter; -- To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] thermal: consistently use int for temperatures
Hi Sascha,
Sascha Hauer writes:
> The thermal code uses int, long and unsigned long for temperatures
> in different places.
>
> Using an unsigned type limits the thermal framework to positive
> temperatures without need. Also several drivers currently will report
> temperatures near UINT_MAX for temperatures below 0°C. This will probably
> immediately shut the machine down due to overtemperature if started below
> 0°C.
>
> 'long' is 64bit on several architectures. This is not needed since INT_MAX °mC
> is above the melting point of all known materials.
>
> Consistently use a plain 'int' for temperatures throughout the thermal code
> and
> the drivers. This only changes the places in the drivers where the temperature
> is passed around as pointer, when drivers internally use another type this is
> not changed.
>
> Signed-off-by: Sascha Hauer
Thanks for moving over the thermal sub-system in Linux to consistently
use a single type.
In your patch, you missed migrating over power_allocator governor and
it's associated trace events. It got merged for v4.2.
Could you incorporate something like below in your next version?
Thanks,
Punit
[...]
--->8---
Subject: [PATCH] Use int for temperature in power_allocator governor
---
drivers/thermal/power_allocator.c | 10 --
include/trace/events/thermal_power_allocator.h | 6 +++---
2 files changed, 7 insertions(+), 9 deletions(-)
diff --git a/drivers/thermal/power_allocator.c
b/drivers/thermal/power_allocator.c
index 4672250..1bb7d7f 100644
--- a/drivers/thermal/power_allocator.c
+++ b/drivers/thermal/power_allocator.c
@@ -92,8 +92,7 @@ struct power_allocator_params {
* Return: The power budget for the next period.
*/
static u32 pid_controller(struct thermal_zone_device *tz,
- unsigned long current_temp,
- unsigned long control_temp,
+ int current_temp, int control_temp,
u32 max_allocatable_power)
{
s64 p, i, d, power_range;
@@ -223,8 +222,7 @@ static void divvy_up_power(u32 *req_power, u32 *max_power,
int num_actors,
}
static int allocate_power(struct thermal_zone_device *tz,
- unsigned long current_temp,
- unsigned long control_temp)
+ int current_temp, int control_temp)
{
struct thermal_instance *instance;
struct power_allocator_params *params = tz->governor_data;
@@ -411,7 +409,7 @@ static int power_allocator_bind(struct thermal_zone_device
*tz)
{
int ret;
struct power_allocator_params *params;
- unsigned long switch_on_temp, control_temp;
+ int switch_on_temp, control_temp;
u32 temperature_threshold;
if (!tz->tzp || !tz->tzp->sustainable_power) {
@@ -476,7 +474,7 @@ static void power_allocator_unbind(struct
thermal_zone_device *tz)
static int power_allocator_throttle(struct thermal_zone_device *tz, int trip)
{
int ret;
- unsigned long switch_on_temp, control_temp, current_temp;
+ int switch_on_temp, control_temp, current_temp;
struct power_allocator_params *params = tz->governor_data;
/*
diff --git a/include/trace/events/thermal_power_allocator.h
b/include/trace/events/thermal_power_allocator.h
index 12e1321..5afae8f 100644
--- a/include/trace/events/thermal_power_allocator.h
+++ b/include/trace/events/thermal_power_allocator.h
@@ -11,7 +11,7 @@ TRACE_EVENT(thermal_power_allocator,
u32 total_req_power, u32 *granted_power,
u32 total_granted_power, size_t num_actors,
u32 power_range, u32 max_allocatable_power,
-unsigned long current_temp, s32 delta_temp),
+int current_temp, s32 delta_temp),
TP_ARGS(tz, req_power, total_req_power, granted_power,
total_granted_power, num_actors, power_range,
max_allocatable_power, current_temp, delta_temp),
@@ -24,7 +24,7 @@ TRACE_EVENT(thermal_power_allocator,
__field(size_t,num_actors )
__field(u32, power_range )
__field(u32, max_allocatable_power)
- __field(unsigned long, current_temp )
+ __field(int, current_temp )
__field(s32, delta_temp )
),
TP_fast_assign(
@@ -42,7 +42,7 @@ TRACE_EVENT(thermal_power_allocator,
__entry->delta_temp = delta_temp;
),
- TP_printk("thermal_zone_id=%d req_power={%s} total_req_power=%u
granted_power={%s} total_granted_power=%u power_range=%u
max_allocatable_power=%u current_temperature=%lu delta_temperature=%d",
+ TP_printk("thermal_zone_id=%d req_power={%s} total_req_power=%u
granted_power={%s} total_granted_power=%u power_range=%u
max_allocatable_power=%u current_t
Re: [PATCH] thermal: consistently use int for temperatures
Hi Punit, On Fri, Jul 17, 2015 at 12:14:36PM +0100, Punit Agrawal wrote: > Hi Sascha, > > Sascha Hauer writes: > > > The thermal code uses int, long and unsigned long for temperatures > > in different places. > > > > Using an unsigned type limits the thermal framework to positive > > temperatures without need. Also several drivers currently will report > > temperatures near UINT_MAX for temperatures below 0°C. This will probably > > immediately shut the machine down due to overtemperature if started below > > 0°C. > > > > 'long' is 64bit on several architectures. This is not needed since INT_MAX > > °mC > > is above the melting point of all known materials. > > > > Consistently use a plain 'int' for temperatures throughout the thermal code > > and > > the drivers. This only changes the places in the drivers where the > > temperature > > is passed around as pointer, when drivers internally use another type this > > is > > not changed. > > > > Signed-off-by: Sascha Hauer > > Thanks for moving over the thermal sub-system in Linux to consistently > use a single type. > > In your patch, you missed migrating over power_allocator governor and > it's associated trace events. It got merged for v4.2. > > Could you incorporate something like below in your next version? It seems I have changed drivers/thermal/power_allocator.c but missed include/trace/events/thermal_power_allocator.h. Please check out the v2 patch I just sent. Sascha -- Pengutronix e.K. | | Industrial Linux Solutions | http://www.pengutronix.de/ | Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0| Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917- | -- To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
