[PATCH 1/2] thermal: exynos: Check the range of temperature code
The temperature code should range between 46 and 146.
Signed-off-by: Jonghwan Choi
---
drivers/thermal/exynos_thermal.c | 21 ++---
1 files changed, 14 insertions(+), 7 deletions(-)
diff --git a/drivers/thermal/exynos_thermal.c
b/drivers/thermal/exynos_thermal.c
index 6dd29e4..dc2ad6c 100644
--- a/drivers/thermal/exynos_thermal.c
+++ b/drivers/thermal/exynos_thermal.c
@@ -530,14 +530,21 @@ out:
static int code_to_temp(struct exynos_tmu_data *data, u8 temp_code)
{
struct exynos_tmu_platform_data *pdata = data->pdata;
- int temp;
+ int min, max, temp;
- if (data->soc == SOC_ARCH_EXYNOS4210)
- /* temp_code should range between 75 and 175 */
- if (temp_code < 75 || temp_code > 175) {
- temp = -ENODATA;
- goto out;
- }
+ if (data->soc == SOC_ARCH_EXYNOS4210) {
+ min = 75;
+ max = 175;
+ } else {
+ min = 46;
+ max = 146;
+ }
+
+ /* temp_code should range between min and max */
+ if (temp_code < min || temp_code > max) {
+ temp = -ENODATA;
+ goto out;
+ }
switch (pdata->cal_type) {
case TYPE_TWO_POINT_TRIMMING:
--
1.7.4.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 2/2] thermal: exynos: Add error handling for temperature code
If temperature code is invalid, it should be handled.
Signed-off-by: Jonghwan Choi
---
drivers/thermal/exynos_thermal.c |8 ++--
1 files changed, 6 insertions(+), 2 deletions(-)
diff --git a/drivers/thermal/exynos_thermal.c
b/drivers/thermal/exynos_thermal.c
index dc2ad6c..78c5c08 100644
--- a/drivers/thermal/exynos_thermal.c
+++ b/drivers/thermal/exynos_thermal.c
@@ -346,15 +346,19 @@ static int exynos_get_temp(struct thermal_zone_device
*thermal,
unsigned long *temp)
{
void *data;
+ int tmp;
if (!th_zone->sensor_conf) {
pr_info("Temperature sensor not initialised\n");
return -EINVAL;
}
data = th_zone->sensor_conf->private_data;
- *temp = th_zone->sensor_conf->read_temperature(data);
+ tmp = th_zone->sensor_conf->read_temperature(data);
+ if (tmp < 0)
+ return tmp;
+
/* convert the temperature into millicelsius */
- *temp = *temp * MCELSIUS;
+ *temp = tmp * MCELSIUS;
return 0;
}
--
1.7.4.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 3.8-stable] regulator: core: Log when a device causes a voltage
3.8-stable review patch. If anyone has any objections, please let us know.
--
From: "Russ Dill "
commit 6e45eb12fd1c741d556bf264ee98853b5f3104e5 upstream.
commit dd8004af: 'regulator: core: Log when a device causes a voltage
constraint fail', tried to print out some information about the
check consumer min/max uV fixup, however, it uses a garbage pointer
left over from list_for_each_entry leading to boot messages in the
form:
'[2.079890] : Restricting voltage,
3735899821-4294967295uV'
Because it references regulator->dev, it could potentially read memory from
anywhere causing a panic.
This patch instead uses rdev and the updated min/max uV values.
Signed-off-by: Russ Dill
Signed-off-by: Mark Brown
Signed-off-by: Jonghwan Choi
---
drivers/regulator/core.c |4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/regulator/core.c b/drivers/regulator/core.c
index 2785843..5a0f54a 100644
--- a/drivers/regulator/core.c
+++ b/drivers/regulator/core.c
@@ -200,8 +200,8 @@ static int regulator_check_consumers(struct
regulator_dev *rdev,
}
if (*min_uV > *max_uV) {
- dev_err(regulator->dev, "Restricting voltage, %u-%uuV\n",
- regulator->min_uV, regulator->max_uV);
+ rdev_err(rdev, "Restricting voltage, %u-%uuV\n",
+ *min_uV, *max_uV);
return -EINVAL;
}
--
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 3.8-stable] regulator: core: Log when a device causes a voltage
Dear all. > > >> -- > > >> > > >> From: "Russ Dill " > > >> > > >> commit 6e45eb12fd1c741d556bf264ee98853b5f3104e5 upstream. > > > > > > Wait, no, this is NOT the commit id of this patch, please don't get > this > > > wrong. > > > > > > I've dropped this from my stable mbox, if Russ feels this should go to > > > 3.8-stable, please send me the correct git id of the patch to apply. > > > > 9c7b4e8a8ad2624106fbf690fa97ab9c8c9bfa88 is the proper upstream commit. > > This fixes a potential oops that was added in 3.8-rc4, and fixed > > upstream in 3.9-rc1. I do think it belongs in stable. > -> This is my fault. I will be more careful from now on Thanks. Best regards. > -Original Message- > From: stable-ow...@vger.kernel.org [mailto:stable-ow...@vger.kernel.org] > On Behalf Of Greg KH > Sent: Wednesday, April 03, 2013 5:55 AM > To: Russ Dill > Cc: Jonghwan Choi; linux-kernel@vger.kernel.org; sta...@vger.kernel.org; > 'Mark Brown' > Subject: Re: [PATCH 3.8-stable] regulator: core: Log when a device causes > a voltage > > On Tue, Apr 02, 2013 at 01:39:06PM -0700, Russ Dill wrote: > > On 04/02/2013 01:02 PM, Greg KH wrote: > > > On Tue, Apr 02, 2013 at 06:30:42PM +0900, Jonghwan Choi wrote: > > >> 3.8-stable review patch. If anyone has any objections, please let us > know. > > >> > > >> -- > > >> > > >> From: "Russ Dill " > > >> > > >> commit 6e45eb12fd1c741d556bf264ee98853b5f3104e5 upstream. > > > > > > Wait, no, this is NOT the commit id of this patch, please don't get > this > > > wrong. > > > > > > I've dropped this from my stable mbox, if Russ feels this should go to > > > 3.8-stable, please send me the correct git id of the patch to apply. > > > > 9c7b4e8a8ad2624106fbf690fa97ab9c8c9bfa88 is the proper upstream commit. > > This fixes a potential oops that was added in 3.8-rc4, and fixed > > upstream in 3.9-rc1. I do think it belongs in stable. > > Thanks, I've applied that commit now. > > > Too bad I can't muck up the commit, then I'd owe you a beer. Might help > > that shoulder of yours. > > Yes, that would help it out, but probably not help me catch up with > pending patches to apply :) > > greg k-h > -- > To unsubscribe from this list: send the line "unsubscribe stable" 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/
[PATCH 3.8-stable] thermal: return an error on failure to register thermal
3.8-stable review patch. If anyone has any objections, please let me know. -- From: "Richard Guy Briggs " commit da28d966f6aa942ae836d09729f76a1647932309 upstream. The return code from the registration of the thermal class is used to unallocate resources, but this failure isn't passed back to the caller of thermal_init. Return this failure back to the caller. This bug was introduced in changeset 4cb18728 which overwrote the return code when the variable was re-used to catch the return code of the registration of the genetlink thermal socket family. Signed-off-by: Richard Guy Briggs Signed-off-by: Zhang Rui --- drivers/thermal/thermal_sys.c |1 + 1 file changed, 1 insertion(+) diff --git a/drivers/thermal/thermal_sys.c b/drivers/thermal/thermal_sys.c index 6472e7e..1a19a2f 100644 --- a/drivers/thermal/thermal_sys.c +++ b/drivers/thermal/thermal_sys.c @@ -1875,6 +1875,7 @@ static int __init thermal_init(void) idr_destroy(&thermal_cdev_idr); mutex_destroy(&thermal_idr_lock); mutex_destroy(&thermal_list_lock); + return result; } result = genetlink_init(); return result; -- 1.7.9.5 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 3.8-stable] cpufreq: exynos: Get booting freq value in exynos_cpufreq_init
This patch looks like it should be in the 3.8-stable tree, should we apply
it?
--
From: "Jonghwan Choi "
Boot_freq is for saving booting freq. But exynos_cpufreq_cpu_init
is called in hotplug. If boot_freq is existed in exynos_cpufreq_cpu_init,
boot_freq could be changed.
Signed-off-by: Jonghwan Choi
Signed-off-by: Kukjin Kim
Signed-off-by: Jonghwan Choi
---
drivers/cpufreq/exynos-cpufreq.c |4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/cpufreq/exynos-cpufreq.c
b/drivers/cpufreq/exynos-cpufreq.c
index 7012ea8..41fc550 100644
--- a/drivers/cpufreq/exynos-cpufreq.c
+++ b/drivers/cpufreq/exynos-cpufreq.c
@@ -222,8 +222,6 @@ static int exynos_cpufreq_cpu_init(struct cpufreq_policy
*policy)
cpufreq_frequency_table_get_attr(exynos_info->freq_table,
policy->cpu);
- locking_frequency = exynos_getspeed(0);
-
/* set the transition latency value */
policy->cpuinfo.transition_latency = 10;
@@ -288,6 +286,8 @@ static int __init exynos_cpufreq_init(void)
goto err_vdd_arm;
}
+ locking_frequency = exynos_getspeed(0);
+
register_pm_notifier(&exynos_cpufreq_nb);
if (cpufreq_register_driver(&exynos_driver)) {
--
1.7.9.5
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 3.8-stable] ARM: EXYNOS: Fix crash on soft reset on EXYNOS5440
This patch looks like it should be in the 3.8-stable tree, should we apply
it?
--
From: "Thomas Abraham "
The soft-reset control register is located in the XMU controller space.
Map this controller space before writing to the soft-reset controller
register.
Signed-off-by: Thomas Abraham
Signed-off-by: Girish K S
Signed-off-by: Kukjin
Signed-off-by: Jonghwan Choi
---
arch/arm/mach-exynos/common.c |6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/arch/arm/mach-exynos/common.c b/arch/arm/mach-exynos/common.c
index 1a89824..3b6de7a 100644
--- a/arch/arm/mach-exynos/common.c
+++ b/arch/arm/mach-exynos/common.c
@@ -299,6 +299,7 @@ void exynos4_restart(char mode, const char *cmd)
void exynos5_restart(char mode, const char *cmd)
{
+ struct device_node *np;
u32 val;
void __iomem *addr;
@@ -306,8 +307,9 @@ void exynos5_restart(char mode, const char *cmd)
val = 0x1;
addr = EXYNOS_SWRESET;
} else if (of_machine_is_compatible("samsung,exynos5440")) {
- val = (0x10 << 20) | (0x1 << 16);
- addr = EXYNOS5440_SWRESET;
+ np = of_find_compatible_node(NULL, NULL,
"samsung,exynos5440-clock");
+ addr = of_iomap(np, 0) + 0xcc;
+ val = (0xfff << 20) | (0x1 << 16);
} else {
pr_err("%s: cannot support non-DT\n", __func__);
return;
--
1.7.9.5
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 1/2] thermal: exynos: Fix wrong bit to control tmu core
[0]bit is used to enable/disable tmu core. [1] bit is a reserved bit. Signed-off-by: Jonghwan Choi --- drivers/thermal/exynos_thermal.c |4 ++-- 1 files changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/thermal/exynos_thermal.c b/drivers/thermal/exynos_thermal.c index fd03e85..6ce6667 100644 --- a/drivers/thermal/exynos_thermal.c +++ b/drivers/thermal/exynos_thermal.c @@ -53,8 +53,8 @@ #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_CORE_ON 1 +#define EXYNOS_TMU_CORE_OFF0 #define EXYNOS_TMU_DEF_CODE_TO_TEMP_OFFSET 50 /* Exynos4210 specific registers */ -- 1.7.4.1 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 2/2] therma: exynos: Supports thermal tripping
TMU urgently sends active-high signal (thermal trip) to PMU,
and thermal tripping by hardware logic i.e PMU is performed.
Thermal tripping means that PMU cut off the whole power of SoC
by controlling external voltage regulator.
Signed-off-by: Jonghwan Choi
---
drivers/thermal/exynos_thermal.c |7 ++-
include/linux/platform_data/exynos_thermal.h |4
2 files changed, 10 insertions(+), 1 deletions(-)
diff --git a/drivers/thermal/exynos_thermal.c
b/drivers/thermal/exynos_thermal.c
index 6ce6667..edac601 100644
--- a/drivers/thermal/exynos_thermal.c
+++ b/drivers/thermal/exynos_thermal.c
@@ -53,6 +53,7 @@
#define EXYNOS_TMU_TRIM_TEMP_MASK 0xff
#define EXYNOS_TMU_GAIN_SHIFT 8
#define EXYNOS_TMU_REF_VOLTAGE_SHIFT 24
+#define EXYNOS_TMU_TRIP_EN BIT(12)
#define EXYNOS_TMU_CORE_ON 1
#define EXYNOS_TMU_CORE_OFF0
#define EXYNOS_TMU_DEF_CODE_TO_TEMP_OFFSET 50
@@ -656,6 +657,8 @@ static void exynos_tmu_control(struct platform_device
*pdev, bool on)
if (data->soc == SOC_ARCH_EXYNOS) {
con |= pdata->noise_cancel_mode <<
EXYNOS_TMU_TRIP_MODE_SHIFT;
con |= (EXYNOS_MUX_ADDR_VALUE << EXYNOS_MUX_ADDR_SHIFT);
+ if (pdata->trip_en)
+ con |= EXYNOS_THERMAL_TRIP_EN;
}
if (on) {
@@ -762,10 +765,12 @@ static struct exynos_tmu_platform_data const
exynos_default_tmu_data = {
.trigger_levels[0] = 85,
.trigger_levels[1] = 103,
.trigger_levels[2] = 110,
+ .trigger_levels[3] = 120,
.trigger_level0_en = 1,
.trigger_level1_en = 1,
.trigger_level2_en = 1,
- .trigger_level3_en = 0,
+ .trigger_level3_en = 1,
+ .trip_en = 1,
.gain = 8,
.reference_voltage = 16,
.noise_cancel_mode = 4,
diff --git a/include/linux/platform_data/exynos_thermal.h
b/include/linux/platform_data/exynos_thermal.h
index a7bdb2f..9e44aac 100644
--- a/include/linux/platform_data/exynos_thermal.h
+++ b/include/linux/platform_data/exynos_thermal.h
@@ -79,6 +79,9 @@ struct freq_clip_table {
* @trigger_level3_en:
* 1 = enable trigger_level3 interrupt,
* 0 = disable trigger_level3 interrupt
+ * @trip_en:
+ * 1 = enable thermal tripping
+ * 0 = disable thermal tripping
* @gain: gain of amplifier in the positive-TC generator block
* 0 <= gain <= 15
* @reference_voltage: reference voltage of amplifier
@@ -102,6 +105,7 @@ struct exynos_tmu_platform_data {
bool trigger_level1_en;
bool trigger_level2_en;
bool trigger_level3_en;
+ bool trip_en;
u8 gain;
u8 reference_voltage;
--
1.7.4.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 2/2] therma: exynos: Supports thermal tripping
Thanks.
Let me check.
> -Original Message-
> From: jonghwa3@samsung.com [mailto:jonghwa3@samsung.com]
> Sent: Wednesday, October 31, 2012 2:06 PM
> To: Jonghwan Choi
> Cc: 'open list'; 'Amit Daniel Kachhap'; 'Zhang Rui'; 'Sachin Kamat'
> Subject: Re: [PATCH 2/2] therma: exynos: Supports thermal tripping
>
> On 2012년 10월 30일 14:32, Jonghwan Choi wrote:
> > TMU urgently sends active-high signal (thermal trip) to PMU,
> > and thermal tripping by hardware logic i.e PMU is performed.
> > Thermal tripping means that PMU cut off the whole power of SoC
> > by controlling external voltage regulator.
> >
> > Signed-off-by: Jonghwan Choi
> > ---
> > drivers/thermal/exynos_thermal.c |7 ++-
> > include/linux/platform_data/exynos_thermal.h |4
> > 2 files changed, 10 insertions(+), 1 deletions(-)
> >
> > diff --git a/drivers/thermal/exynos_thermal.c
> > b/drivers/thermal/exynos_thermal.c
> > index 6ce6667..edac601 100644
> > --- a/drivers/thermal/exynos_thermal.c
> > +++ b/drivers/thermal/exynos_thermal.c
> > @@ -53,6 +53,7 @@
> > #define EXYNOS_TMU_TRIM_TEMP_MASK 0xff
> > #define EXYNOS_TMU_GAIN_SHIFT 8
> > #define EXYNOS_TMU_REF_VOLTAGE_SHIFT 24
> > +#define EXYNOS_TMU_TRIP_EN BIT(12)
> > #define EXYNOS_TMU_CORE_ON 1
> > #define EXYNOS_TMU_CORE_OFF0
> > #define EXYNOS_TMU_DEF_CODE_TO_TEMP_OFFSET 50
> > @@ -656,6 +657,8 @@ static void exynos_tmu_control(struct
> platform_device
> > *pdev, bool on)
> > if (data->soc == SOC_ARCH_EXYNOS) {
> > con |= pdata->noise_cancel_mode <<
> > EXYNOS_TMU_TRIP_MODE_SHIFT;
> > con |= (EXYNOS_MUX_ADDR_VALUE << EXYNOS_MUX_ADDR_SHIFT);
> > + if (pdata->trip_en)
> > + con |= EXYNOS_THERMAL_TRIP_EN;
> > }
> >
> > if (on) {
> > @@ -762,10 +765,12 @@ static struct exynos_tmu_platform_data const
> > exynos_default_tmu_data = {
> > .trigger_levels[0] = 85,
> > .trigger_levels[1] = 103,
> > .trigger_levels[2] = 110,
> > + .trigger_levels[3] = 120,
> > .trigger_level0_en = 1,
> > .trigger_level1_en = 1,
> > .trigger_level2_en = 1,
> > - .trigger_level3_en = 0,
> > + .trigger_level3_en = 1,
> > + .trip_en = 1,
> > .gain = 8,
> > .reference_voltage = 16,
> > .noise_cancel_mode = 4,
> > diff --git a/include/linux/platform_data/exynos_thermal.h
> > b/include/linux/platform_data/exynos_thermal.h
> > index a7bdb2f..9e44aac 100644
> > --- a/include/linux/platform_data/exynos_thermal.h
> > +++ b/include/linux/platform_data/exynos_thermal.h
> > @@ -79,6 +79,9 @@ struct freq_clip_table {
> > * @trigger_level3_en:
> > * 1 = enable trigger_level3 interrupt,
> > * 0 = disable trigger_level3 interrupt
> > + * @trip_en:
> > + * 1 = enable thermal tripping
> > + * 0 = disable thermal tripping
> > * @gain: gain of amplifier in the positive-TC generator block
> > * 0 <= gain <= 15
> > * @reference_voltage: reference voltage of amplifier
> > @@ -102,6 +105,7 @@ struct exynos_tmu_platform_data {
> > bool trigger_level1_en;
> > bool trigger_level2_en;
> > bool trigger_level3_en;
> > + bool trip_en;
> I think this variable addition is not necessary. It's enough to use
> trigger_level3_en variable
> to determine hardware thermal tripping enable or not. Since exynos4210
> has different register map from
> other exynos SOC's, trigger level 3 enable is existed different region.
> exynos4210 has it in
> interrupt enable register and others has it in TMU core control register
> (exynos4x12 and exynos5
> doesn't have trigger_level3_en bit in interrupt enable register).
> Thus it's better to use trigger_level3_en variable to enable hardware
> thermal tripping support for compatibility.
>
> Thanks,
> Jonghwa Lee.
> >
> > u8 gain;
> > u8 reference_voltage;
> > --
> > 1.7.4.1
> >
> > --
> > To unsubscribe from this list: send the line "unsubscribe linux-kernel"
> in
> > the body of a message to majord...@vger.kernel.org
> > More majordomo info at http://vger.kernel.org/majordomo-info.html
> > Please read the FAQ at http://www.tux.org/lkml/
> >
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v2 2/2] therma: exynos: Supports thermal tripping
TMU urgently sends active-high signal (thermal trip) to PMU,
and thermal tripping by hardware logic i.e PMU is performed.
Thermal tripping means that PMU cut off the whole power of SoC
by controlling external voltage regulator.
Signed-off-by: Jonghwan Choi
---
drivers/thermal/exynos_thermal.c |4
1 files changed, 4 insertions(+), 0 deletions(-)
diff --git a/drivers/thermal/exynos_thermal.c
b/drivers/thermal/exynos_thermal.c
index 6ce6667..5672e95 100644
--- a/drivers/thermal/exynos_thermal.c
+++ b/drivers/thermal/exynos_thermal.c
@@ -53,6 +53,7 @@
#define EXYNOS_TMU_TRIM_TEMP_MASK 0xff
#define EXYNOS_TMU_GAIN_SHIFT 8
#define EXYNOS_TMU_REF_VOLTAGE_SHIFT 24
+#define EXYNOS_TMU_TRIP_EN BIT(12)
#define EXYNOS_TMU_CORE_ON 1
#define EXYNOS_TMU_CORE_OFF0
#define EXYNOS_TMU_DEF_CODE_TO_TEMP_OFFSET 50
@@ -656,6 +657,9 @@ static void exynos_tmu_control(struct platform_device
*pdev, bool on)
if (data->soc == SOC_ARCH_EXYNOS) {
con |= pdata->noise_cancel_mode <<
EXYNOS_TMU_TRIP_MODE_SHIFT;
con |= (EXYNOS_MUX_ADDR_VALUE << EXYNOS_MUX_ADDR_SHIFT);
+
+ if (pdata->trigger_level3_en)
+ con |= EXYNOS_TMU_TRIP_EN;
}
if (on) {
--
1.7.4.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v2 1/2] thermal: exynos: Fix wrong bit to control tmu core
[0]bit is used to enable/disable tmu core. [1] bit is a reserved bit. Signed-off-by: Jonghwan Choi --- drivers/thermal/exynos_thermal.c |4 ++-- 1 files changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/thermal/exynos_thermal.c b/drivers/thermal/exynos_thermal.c index fd03e85..6ce6667 100644 --- a/drivers/thermal/exynos_thermal.c +++ b/drivers/thermal/exynos_thermal.c @@ -53,8 +53,8 @@ #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_CORE_ON 1 +#define EXYNOS_TMU_CORE_OFF0 #define EXYNOS_TMU_DEF_CODE_TO_TEMP_OFFSET 50 /* Exynos4210 specific registers */ -- 1.7.4.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 RFC] PM/Devfreq: Add Exynos5-bus devfreq driver for Exynos5250.
Hi Abhilash Kesavan.
I compiled in 3.7-rc8
I got a compile error & warning.
Compile error.
CC drivers/devfreq/exynos5_ppmu.o
drivers/devfreq/exynos5_ppmu.c:56:14: error: 'S5P_VA_PPMU_DDR_C' undeclared
here (not in a function)
drivers/devfreq/exynos5_ppmu.c:59:14: error: 'S5P_VA_PPMU_DDR_R1' undeclared
here (not in a function)
drivers/devfreq/exynos5_ppmu.c:62:13: error: 'S5P_VA_PPMU_DDR_L' undeclared
here (not in a function)
drivers/devfreq/exynos5_ppmu.c:65:13: error: 'S5P_VA_PPMU_RIGHT' undeclared
here (not in a function)
drivers/devfreq/exynos5_ppmu.c:68:14: error: 'S5P_VA_PPMU_CPU' undeclared
here (not in a function)
make[2]: *** [drivers/devfreq/exynos5_ppmu.o] Error 1
> + data->devfreq = devfreq_add_device(dev,
> &exynos5_devfreq_int_profile,
> +"simple_ondemand",
> +&exynos5_int_ondemand_data);
drivers/devfreq/exynos5_bus.c: In function 'exynos5_busfreq_int_probe':
drivers/devfreq/exynos5_bus.c:388:9: warning: passing argument 3 of
'devfreq_add_device' from incompatible pointer type [enabled by default]
include/linux/devfreq.h:170:24: note: expected 'struct devfreq_governor
const *' but argument is of type 'char *'
include/linux/devfreq.h
extern struct devfreq *devfreq_add_device(struct device *dev,
struct devfreq_dev_profile *profile,
const struct devfreq_governor *governor,
void *data);
Need change?
> +
> + if (IS_ERR(data->devfreq)) {
> + err = PTR_ERR(data->devfreq);
> + goto err_devfreq_add;
> + }
> +static int exynos5_busfreq_int_target(struct device *dev, unsigned long
> *_freq,
> + u32 flags)
> +{
> + int err = 0;
> + struct platform_device *pdev = container_of(dev, struct
> platform_device,
...
> +
> + err = clk_set_rate(data->int_clk, freq * 1000);
How to change the INT clock? I think you have to change
arch/arm/mach-exynos/clock-exynos5250.c
(If you want to control via clock framework.)
Like this.
static struct clk exynos5_int_clk = {
.name = "int_clk",
.id = -1,
};
static struct clk_ops exynos5_clk_int_ops = {
.get_rate = exynos5_clk_int_get_rate,
.set_rate = exynos5_clk_int_set_rate
};
exynos5_int_clk.ops = &exynos5_clk_int_ops;
> +
> + if (err)
> + goto out;
> +
Thanks~
Best Regards.
> -Original Message-
> From: Abhilash Kesavan [mailto:a.kesa...@samsung.com]
> Sent: Friday, November 30, 2012 5:43 PM
> To: myungjoo@samsung.com; kyungmin.p...@samsung.com; r...@sisk.pl;
> linux-kernel@vger.kernel.org; linux...@vger.kernel.org
> Cc: kgene@samsung.com; jhbird.c...@samsung.com
> Subject: [PATCH RFC] PM/Devfreq: Add Exynos5-bus devfreq driver for
> Exynos5250.
>
> Exynos5-bus device devfreq driver monitors PPMU counters and
> adjusts operating frequencies and voltages with OPP. ASV should
> be used to provide appropriate voltages as per the speed group
> of the SoC rather than using a constant 1.025V.
>
> Signed-off-by: Abhilash Kesavan
> Cc: Jonghwan Choi
> Cc: Kukjin Kim
> ---
> This code is based on Jonghwan Choi's devfreq
> work
> for Exynos5250. This requires corresponding machine specific changes which
> will be posted once the driver is reviewed.
>
> drivers/devfreq/Kconfig| 10 +
> drivers/devfreq/Makefile |1 +
> drivers/devfreq/exynos5_bus.c | 595
>
> drivers/devfreq/exynos5_ppmu.c | 395 ++
> drivers/devfreq/exynos5_ppmu.h | 26 ++
> drivers/devfreq/exynos_ppmu.c | 56
> drivers/devfreq/exynos_ppmu.h | 79 ++
> 7 files changed, 1162 insertions(+), 0 deletions(-)
> create mode 100644 drivers/devfreq/exynos5_bus.c
> create mode 100644 drivers/devfreq/exynos5_ppmu.c
> create mode 100644 drivers/devfreq/exynos5_ppmu.h
> create mode 100644 drivers/devfreq/exynos_ppmu.c
> create mode 100644 drivers/devfreq/exynos_ppmu.h
>
> diff --git a/drivers/devfreq/Kconfig b/drivers/devfreq/Kconfig
> index 0f079be..1560d0d 100644
> --- a/drivers/devfreq/Kconfig
> +++ b/drivers/devfreq/Kconfig
> @@ -78,4 +78,14 @@ config ARM_EXYNOS4_BUS_DEVFREQ
> To operate with optimal voltages, ASV support is required
> (CONFIG_EXYNOS_ASV).
>
> +config ARM_EXYNOS5_BUS_DEVFREQ
> + bool "ARM Exynos5250 Bus DEVFREQ Driver"
> + depends on SOC_EXYNOS5250
> + select ARCH_HAS_OPP
> + select DEVFREQ_GOV_SIMPLE_ONDEMAND
> + help
>
[PATCH] thermal: exynos: Fix wrong name of MODULE_DEVICE_TABLE
exynos4_tmu_driver_ids should be exynos_tmu_driver_ids.
Signed-off-by: Jonghwan Choi
---
drivers/thermal/exynos_thermal.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/thermal/exynos_thermal.c
b/drivers/thermal/exynos_thermal.c
index fd03e85..6dd29e4 100644
--- a/drivers/thermal/exynos_thermal.c
+++ b/drivers/thermal/exynos_thermal.c
@@ -815,7 +815,7 @@ static struct platform_device_id exynos_tmu_driver_ids[]
= {
},
{ },
};
-MODULE_DEVICE_TABLE(platform, exynos4_tmu_driver_ids);
+MODULE_DEVICE_TABLE(platform, exynos_tmu_driver_ids);
static inline struct exynos_tmu_platform_data *exynos_get_driver_data(
struct platform_device *pdev)
--
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: [RFC PATCH] ARM: EXYNOS5: Support Exynos5-bus devfreq driver
Hi Abhilash Kesavan.
> + /* Change Divider - LEX */
> + tmp = __raw_readl(EXYNOS5_CLKDIV_LEX);
> +
> + tmp &= ~(EXYNOS5_CLKDIV_LEX_ATCLK_LEX_MASK |
> + EXYNOS5_CLKDIV_LEX_PCLK_LEX_MASK);
> +
> + tmp |= int_freq[div_index].clk_div_lex;
> +
> + __raw_writel(tmp, EXYNOS5_CLKDIV_LEX);
> +
I knew that only ATCLK_LEX & PCLK_LEX divider value are in CLKDIV_LEX
register. (Others are reserved and value is 0)
So, I think
"
tmp = int_freq[div_index].clk_div_lex;
__raw_writel(tmp, EXYNOS5_CLKDIV_LEX);
"
Is enough.
> + tmp = __raw_readl(EXYNOS5_CLKDIV_LEX);
> +
> + tmp &= ~(EXYNOS5_CLKDIV_LEX_ATCLK_LEX_MASK |
> + EXYNOS5_CLKDIV_LEX_PCLK_LEX_MASK);
-> not need.
> + while (__raw_readl(EXYNOS5_CLKDIV_STAT_LEX) & 0x110)
> + cpu_relax();
> +
> + /* Change Divider - R0X */
> + tmp = __raw_readl(EXYNOS5_CLKDIV_R0X);
> +
> + tmp &= ~EXYNOS5_CLKDIV_R0X_PCLK_R0X_MASK;
> +
> + tmp |= int_freq[div_index].clk_div_r0x;
> +
> + __raw_writel(tmp, EXYNOS5_CLKDIV_R0X);
> +
Same here
> + while (__raw_readl(EXYNOS5_CLKDIV_STAT_R0X) & 0x10)
> + cpu_relax();
> +
> + /* Change Divider - R1X */
> + tmp = __raw_readl(EXYNOS5_CLKDIV_R1X);
> +
> + tmp &= ~EXYNOS5_CLKDIV_R1X_PCLK_R1X_MASK;
> +
> + tmp |= int_freq[div_index].clk_div_r1x;
> +
> + __raw_writel(tmp, EXYNOS5_CLKDIV_R1X);
> +
Same here
> + while (__raw_readl(EXYNOS5_CLKDIV_STAT_R1X) & 0x10)
> + cpu_relax();
How about your opinion?
thanks
> -Original Message-
> From: Abhilash Kesavan [mailto:a.kesa...@samsung.com]
> Sent: Monday, December 10, 2012 9:06 PM
> To: linux-kernel@vger.kernel.org; linux...@vger.kernel.org;
> kgene@samsung.com
> Cc: myungjoo@samsung.com; kyungmin.p...@samsung.com; r...@sisk.pl;
> jhbird.c...@samsung.com; Abhilash Kesavan
> Subject: [RFC PATCH] ARM: EXYNOS5: Support Exynos5-bus devfreq driver
>
> - Setup the INT clock ops to control/vary INT frequency
> - Add mappings initially for the PPMU device
>
> Signed-off-by: Abhilash Kesavan
> ---
> Corresponding devfreq driver support for Exynos5 has been posted at:
> https://patchwork.kernel.org/patch/1823931/
>
> Tested after merging for-rafael branch of
> git://git.kernel.org/pub/scm/linux/kernel/git/mzx/devfreq.git
> with for-next branch of
> git://git.kernel.org/pub/scm/linux/kernel/git/kgene/linux-samsung.git
>
> arch/arm/mach-exynos/clock-exynos5.c | 151
>
> arch/arm/mach-exynos/common.c | 25
> arch/arm/mach-exynos/include/mach/map.h|6 +
> arch/arm/mach-exynos/include/mach/regs-clock.h | 48
> arch/arm/plat-samsung/include/plat/map-s5p.h |6 +
> 5 files changed, 236 insertions(+), 0 deletions(-)
>
> diff --git a/arch/arm/mach-exynos/clock-exynos5.c b/arch/arm/mach-
> exynos/clock-exynos5.c
> index 5c63bc7..f00b259 100644
> --- a/arch/arm/mach-exynos/clock-exynos5.c
> +++ b/arch/arm/mach-exynos/clock-exynos5.c
> @@ -109,6 +109,11 @@ static struct clk exynos5_clk_sclk_usbphy = {
> .rate = 4800,
> };
>
> +/* Virtual Bus INT clock */
> +static struct clk exynos5_int_clk = {
> + .name = "int_clk",
> +};
> +
> static int exynos5_clksrc_mask_top_ctrl(struct clk *clk, int enable)
> {
> return s5p_gatectrl(EXYNOS5_CLKSRC_MASK_TOP, clk, enable);
> @@ -1519,6 +1524,149 @@ static struct clk *exynos5_clks[] __initdata = {
> &clk_fout_cpll,
> &clk_fout_mpll_div2,
> &exynos5_clk_armclk,
> + &exynos5_int_clk,
> +};
> +
> +#define INT_FREQ(f, a0, a1, a2, a3, a4, a5, b0, b1, b2, b3, \
> + c0, c1, d0, e0) \
> + { \
> + .freq = (f) * 100, \
> + .clk_div_top0 = ((a0) << 0 | (a1) << 8 | (a2) << 12 | \
> + (a3) << 16 | (a4) << 20 | (a5) << 28), \
> + .clk_div_top1 = ((b0) << 12 | (b1) << 16 | (b2) << 20 | \
> + (b3) << 24), \
> + .clk_div_lex = ((c0) << 4 | (c1) << 8), \
> + .clk_div_r0x = ((d0) << 4), \
> + .clk_div_r1x = ((e0) << 4), \
> + }
> +
> +static struct {
> + unsigned long freq;
> + u32 clk_div_top0;
> + u32 clk_div_top1;
> + u32 clk_div_lex;
> + u32 clk_div_r0x;
> + u32 clk_div_r1x;
> +} int_freq[] = {
> + /*
> + * values:
> + * freq
> + * clock divider for ACLK66, ACLK166, ACLK200, ACLK266,
> + ACLK333, ACLK300_DISP1
> + * clock divider for ACLK300_GSCL, ACLK400_IOP, ACLK400_ISP,
> ACLK66_PRE
> + * clock divider for PCLK_LEX, ATCLK_LEX
> + * clock divider for ACLK_PR0X
> + * clock divider for ACLK_PR1X
> + */
> + INT_FREQ(266, 1, 1, 3, 2, 0, 0, 0, 1, 1, 5, 1, 0, 1, 1),
> + INT_FREQ(200, 1, 2, 4, 3, 1, 0, 0, 3, 2, 5, 1, 0, 1, 1),
> + INT_FREQ(160, 1, 3, 4, 4, 2, 0, 0, 3, 3, 5, 1, 0, 1, 1),
> + INT_FREQ(133, 1, 3, 5, 5, 2, 1, 1, 4, 4
[PATCH v3 1/2] thermal: exynos: Fix wrong bit to control tmu core
[0]bit is used to enable/disable tmu core. [1] bit is a reserved bit.
Signed-off-by: Jonghwan Choi
---
drivers/thermal/exynos_thermal.c | 16
1 files changed, 12 insertions(+), 4 deletions(-)
diff --git a/drivers/thermal/exynos_thermal.c
b/drivers/thermal/exynos_thermal.c
index 6dd29e4..129e827 100644
--- a/drivers/thermal/exynos_thermal.c
+++ b/drivers/thermal/exynos_thermal.c
@@ -52,9 +52,12 @@
#define EXYNOS_TMU_TRIM_TEMP_MASK 0xff
#define EXYNOS_TMU_GAIN_SHIFT 8
+#define EXYNOS_TMU_GAIN_MASK (0xF << EXYNOS_TMU_GAIN_SHIFT)
#define EXYNOS_TMU_REF_VOLTAGE_SHIFT 24
-#define EXYNOS_TMU_CORE_ON 3
-#define EXYNOS_TMU_CORE_OFF2
+#define EXYNOS_TMU_REF_VOLTAGE_MASK(0x1F <<
EXYNOS_TMU_REF_VOLTAGE_SHIFT)
+#define EXYNOS_TMU_CORE_ON BIT(0)
+#define EXYNOS_TMU_CORE_ON_SHIFT 0
+#define EXYNOS_TMU_CORE_ON_MASK(0x1 <<
EXYNOS_TMU_CORE_ON_SHIFT)
#define EXYNOS_TMU_DEF_CODE_TO_TEMP_OFFSET 50
/* Exynos4210 specific registers */
@@ -85,7 +88,9 @@
#define EXYNOS_TMU_CLEAR_FALL_INT (0x111 << 16)
#define EXYNOS_MUX_ADDR_VALUE 6
#define EXYNOS_MUX_ADDR_SHIFT 20
+#define EXYNOS_MUX_ADDR_MASK (0x7 << EXYNOS_MUX_ADDR_SHIFT)
#define EXYNOS_TMU_TRIP_MODE_SHIFT 13
+#define EXYNOS_TMU_TRIP_MODE_MASK (0x7 << EXYNOS_TMU_TRIP_MODE_SHIFT)
#define EFUSE_MIN_VALUE 40
#define EFUSE_MAX_VALUE 100
@@ -650,10 +655,14 @@ static void exynos_tmu_control(struct platform_device
*pdev, bool on)
mutex_lock(&data->lock);
clk_enable(data->clk);
- con = pdata->reference_voltage << EXYNOS_TMU_REF_VOLTAGE_SHIFT |
+ con = readl(data->base + EXYNOS_TMU_REG_CONTROL);
+ con &= ~(EXYNOS_TMU_REF_VOLTAGE_MASK | EXYNOS_TMU_GAIN_MASK |
+ EXYNOS_TMU_CORE_ON_MASK);
+ con |= pdata->reference_voltage << EXYNOS_TMU_REF_VOLTAGE_SHIFT |
pdata->gain << EXYNOS_TMU_GAIN_SHIFT;
if (data->soc == SOC_ARCH_EXYNOS) {
+ con &= ~(EXYNOS_TMU_TRIP_MODE_MASK | EXYNOS_MUX_ADDR_MASK);
con |= pdata->noise_cancel_mode <<
EXYNOS_TMU_TRIP_MODE_SHIFT;
con |= (EXYNOS_MUX_ADDR_VALUE << EXYNOS_MUX_ADDR_SHIFT);
}
@@ -665,7 +674,6 @@ static void exynos_tmu_control(struct platform_device
*pdev, bool on)
pdata->trigger_level1_en << 4 |
pdata->trigger_level0_en;
} else {
- con |= EXYNOS_TMU_CORE_OFF;
interrupt_en = 0; /* Disable all interrupts */
}
writel(interrupt_en, data->base + EXYNOS_TMU_REG_INTEN);
--
1.7.4.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v3 2/2] therma: exynos: Supports thermal tripping
TMU urgently sends active-high signal (thermal trip) to PMU,
and thermal tripping by hardware logic i.e PMU is performed.
Thermal tripping means that PMU cut off the whole power of SoC
by controlling external voltage regulator.
Signed-off-by: Jonghwan Choi
---
drivers/thermal/exynos_thermal.c | 10 ++
1 files changed, 10 insertions(+), 0 deletions(-)
diff --git a/drivers/thermal/exynos_thermal.c
b/drivers/thermal/exynos_thermal.c
index 129e827..569478d 100644
--- a/drivers/thermal/exynos_thermal.c
+++ b/drivers/thermal/exynos_thermal.c
@@ -58,6 +58,7 @@
#define EXYNOS_TMU_CORE_ON BIT(0)
#define EXYNOS_TMU_CORE_ON_SHIFT 0
#define EXYNOS_TMU_CORE_ON_MASK(0x1 <<
EXYNOS_TMU_CORE_ON_SHIFT)
+#define EXYNOS_TMU_TRIP_EN BIT(12)
#define EXYNOS_TMU_DEF_CODE_TO_TEMP_OFFSET 50
/* Exynos4210 specific registers */
@@ -631,6 +632,12 @@ static int exynos_tmu_initialize(struct platform_device
*pdev)
goto out;
}
rising_threshold |= (threshold_code << 16);
+ threshold_code = temp_to_code(data,
pdata->trigger_levels[3]);
+ if (threshold_code < 0) {
+ ret = threshold_code;
+ goto out;
+ }
+ rising_threshold |= (threshold_code << 24);
writel(rising_threshold,
data->base + EXYNOS_THD_TEMP_RISE);
@@ -665,6 +672,8 @@ static void exynos_tmu_control(struct platform_device
*pdev, bool on)
con &= ~(EXYNOS_TMU_TRIP_MODE_MASK | EXYNOS_MUX_ADDR_MASK);
con |= pdata->noise_cancel_mode <<
EXYNOS_TMU_TRIP_MODE_SHIFT;
con |= (EXYNOS_MUX_ADDR_VALUE << EXYNOS_MUX_ADDR_SHIFT);
+ if (pdata->trigger_levels[3])
+ con |= EXYNOS_TMU_TRIP_EN;
}
if (on) {
@@ -770,6 +779,7 @@ static struct exynos_tmu_platform_data const
exynos_default_tmu_data = {
.trigger_levels[0] = 85,
.trigger_levels[1] = 103,
.trigger_levels[2] = 110,
+ .trigger_levels[3] = 120,
.trigger_level0_en = 1,
.trigger_level1_en = 1,
.trigger_level2_en = 1,
--
1.7.4.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 3.8-stable] esp4: fix error return code in esp_output()
This patch looks like it should be in the 3.8-stable tree, should we apply
it?
--
From: "Wei Yongjun "
commit 06848c10f720cbc20e3b784c0df24930b7304b93 upstream
Fix to return a negative error code from the error handling
case instead of 0, as returned elsewhere in this function.
Signed-off-by: Wei Yongjun
Acked-by: Steffen Klassert
Signed-off-by: David S. Miller
Signed-off-by: Jonghwan Choi
---
net/ipv4/esp4.c |6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/net/ipv4/esp4.c b/net/ipv4/esp4.c
index 3b4f0cd..4cfe34d 100644
--- a/net/ipv4/esp4.c
+++ b/net/ipv4/esp4.c
@@ -139,8 +139,6 @@ static int esp_output(struct xfrm_state *x, struct
sk_buff *skb)
/* skb is pure payload to encrypt */
- err = -ENOMEM;
-
esp = x->data;
aead = esp->aead;
alen = crypto_aead_authsize(aead);
@@ -176,8 +174,10 @@ static int esp_output(struct xfrm_state *x, struct
sk_buff *skb)
}
tmp = esp_alloc_tmp(aead, nfrags + sglists, seqhilen);
- if (!tmp)
+ if (!tmp) {
+ err = -ENOMEM;
goto error;
+ }
seqhi = esp_tmp_seqhi(tmp);
iv = esp_tmp_iv(aead, tmp, seqhilen);
--
1.7.9.5
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 3.8-stable] regmap: irq: call pm_runtime_put in pm_runtime_get_sync
3.8-stable review patch. If anyone has any objections, please let me know.
--
From: "Li Fei "
commit 283189d3be56aa6db6f192bb255df68493cd79ac upstream.
Even in failed case of pm_runtime_get_sync, the usage_count
is incremented. In order to keep the usage_count with correct
value and runtime power management to behave correctly, call
pm_runtime_put(_sync) in such case.
Signed-off-by Liu Chuansheng
Signed-off-by: Li Fei
Signed-off-by: Mark Brown
Signed-off-by: Jonghwan Choi
---
drivers/base/regmap/regmap-irq.c |1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/base/regmap/regmap-irq.c
b/drivers/base/regmap/regmap-irq.c
index 5972ad9..d623eea 100644
--- a/drivers/base/regmap/regmap-irq.c
+++ b/drivers/base/regmap/regmap-irq.c
@@ -167,6 +167,7 @@ static irqreturn_t regmap_irq_thread(int irq, void *d)
if (ret < 0) {
dev_err(map->dev, "IRQ thread failed to resume:
%d\n",
ret);
+ pm_runtime_put(map->dev);
return IRQ_NONE;
}
}
--
1.7.9.5
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 3.8-stable] regulator: fixed regulator_bulk_enable unwinding code
3.8-stable review patch. If anyone has any objections, please let me know.
--
From: "Andrzej Hajda "
commit fbe31057fafebdc2811a7101b8b4a0460f5417d1 upstream.
Unwinding code disables all successfully enabled regulators.
Error is logged for every failed regulator.
Signed-off-by: Andrzej Hajda
Signed-off-by: Kyungmin Park
Signed-off-by: Mark Brown
Signed-off-by: Jonghwan Choi
---
drivers/regulator/core.c | 10 +++---
1 file changed, 7 insertions(+), 3 deletions(-)
diff --git a/drivers/regulator/core.c b/drivers/regulator/core.c
index 5a0f54a..e56185b 100644
--- a/drivers/regulator/core.c
+++ b/drivers/regulator/core.c
@@ -3032,9 +3032,13 @@ int regulator_bulk_enable(int num_consumers,
return 0;
err:
- pr_err("Failed to enable %s: %d\n", consumers[i].supply, ret);
- while (--i >= 0)
- regulator_disable(consumers[i].consumer);
+ for (i = 0; i < num_consumers; i++) {
+ if (consumers[i].ret < 0)
+ pr_err("Failed to enable %s: %d\n",
consumers[i].supply,
+ consumers[i].ret);
+ else
+ regulator_disable(consumers[i].consumer);
+ }
return ret;
}
--
1.7.9.5
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 3.8-stable] perf: Fix error return code
3.8-stable review patch. If anyone has any objections, please let me know. -- From: "Wei Yongjun " commit c481420248c6730246d2a1b1773d5d7007ae0835 upstream. Fix to return -ENOMEM in the allocation error case instead of 0 (if pmu_bus_running == 1), as done elsewhere in this function. Signed-off-by: Wei Yongjun Cc: a.p.zijls...@chello.nl Cc: pau...@samba.org Cc: a...@ghostprotocols.net Link: http://lkml.kernel.org/r/CAPgLHd8j_fWcgqe%3DKLWjpBj%2B%3Do0Pw6Z-SEq%3DNTPU08 c2w1t...@mail.gmail.com [ Tweaked the error code setting placement and the changelog. ] Signed-off-by: Ingo Molnar Signed-off-by: Jonghwan Choi --- kernel/events/core.c |1 + 1 file changed, 1 insertion(+) diff --git a/kernel/events/core.c b/kernel/events/core.c index 7b6646a..f6eba58 100644 --- a/kernel/events/core.c +++ b/kernel/events/core.c @@ -5988,6 +5988,7 @@ skip_type: if (pmu->pmu_cpu_context) goto got_cpu_context; + ret = -ENOMEM; pmu->pmu_cpu_context = alloc_percpu(struct perf_cpu_context); if (!pmu->pmu_cpu_context) goto free_dev; -- 1.7.9.5 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 3.8-stable] ARM: S3C24XX: Correct NR_IRQS definition for s3c2440
3.8-stable review patch. If anyone has any objections, please let me know. -- From: "Sylwester Nawrocki " commit b530f742ac27460d41d35b638ad6aad92044a982 upstream. Due to NR_IRQS being incorrectly defined not all IRQ domains can be registered for S3C2440. It causes following errors on a s3c2440 SoC based board: NR_IRQS:89 S3C2440: IRQ Support irq: clearing pending status 0002 [ cut here ] WARNING: at kernel/irq/irqdomain.c:234 0xc0056ed0() ... irq: could not create irq-domain ... s3c2410-wdt s3c2410-wdt: failed to install irq (-22) s3c2410-wdt: probe of s3c2410-wdt failed with error -22 ... samsung-uart s3c2440-uart.0: cannot get irq 74 Fix this by increasing NR_IRQS to at least (IRQ_S3C2443_AC97 + 1) if CPU_S3C2440 is selected, so the subintc IRQ domain gets properly registered. Signed-off-by: Tomasz Figa Signed-off-by: Sylwester Nawrocki Acked-by: Heiko Stuebner Signed-off-by: Kukjin Kim Signed-off-by: Jonghwan Choi --- arch/arm/mach-s3c24xx/include/mach/irqs.h |4 +--- 1 file changed, 1 insertion(+), 3 deletions(-) diff --git a/arch/arm/mach-s3c24xx/include/mach/irqs.h b/arch/arm/mach-s3c24xx/include/mach/irqs.h index b7a9f4d..1e73f5f 100644 --- a/arch/arm/mach-s3c24xx/include/mach/irqs.h +++ b/arch/arm/mach-s3c24xx/include/mach/irqs.h @@ -188,10 +188,8 @@ #if defined(CONFIG_CPU_S3C2416) #define NR_IRQS (IRQ_S3C2416_I2S1 + 1) -#elif defined(CONFIG_CPU_S3C2443) -#define NR_IRQS (IRQ_S3C2443_AC97+1) #else -#define NR_IRQS (IRQ_S3C2440_AC97+1) +#define NR_IRQS (IRQ_S3C2443_AC97 + 1) #endif /* compatibility define. */ -- 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 3.8-stable] ARM: S3C24XX: Correct NR_IRQS definition for s3c2440
Oh my god~. Maybe I was insane When I send emails, I usually photocopy this part and use it, but I accidently made a mistake. I am so so sorry. Best Regards. Thanks. > -Original Message- > From: stable-ow...@vger.kernel.org [mailto:stable-ow...@vger.kernel.org] > On Behalf Of Greg KH > Sent: Tuesday, April 23, 2013 12:09 PM > To: Jonghwan Choi > Cc: linux-kernel@vger.kernel.org; sta...@vger.kernel.org; 'Sylwester > Nawrocki'; 'Kukjin Kim'; 'Tomasz Figa' > Subject: Re: [PATCH 3.8-stable] ARM: S3C24XX: Correct NR_IRQS definition > for s3c2440 > > On Tue, Apr 23, 2013 at 11:59:13AM +0900, Jonghwan Choi wrote: > > 3.8-stable review patch. If anyone has any objections, please let me > know. > > Why, what are you going to do with this? :) > > I thought you were going to change the wording of your emails, what > happened? > > greg k-h > -- > To unsubscribe from this list: send the line "unsubscribe stable" 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/
[PATCH 3.9-stable] ARM: omap3: clock: fix wrong container_of in clock36xx.c
This patch looks like it should be in the 3.9-stable tree, should we apply
it?
--
From: "Jean-Philippe Francois "
commit a93d8a1cea0899982993e9a93404c6f78b123697 upstream
omap36xx_pwrdn_clk_enable_with_hsdiv_restore expects the parent hw of
the clock to be a clk_hw_omap. However, looking at cclock3xxx_data.c,
all concerned clock have parent defined as clk_divider. Fix the
function to use clk_divider. Tested with 3.9 on dm3730.
Signed-off-by: Jean-Philippe Francois
Cc: NeilBrown
Cc: Mike Turquette
Signed-off-by: Paul Walmsley
Signed-off-by: Jonghwan Choi
---
arch/arm/mach-omap2/clock36xx.c | 18 +-
1 file changed, 9 insertions(+), 9 deletions(-)
diff --git a/arch/arm/mach-omap2/clock36xx.c
b/arch/arm/mach-omap2/clock36xx.c
index 8f3bf4e..bbd6a3f 100644
--- a/arch/arm/mach-omap2/clock36xx.c
+++ b/arch/arm/mach-omap2/clock36xx.c
@@ -20,11 +20,12 @@
#include
#include
+#include
#include
#include "clock.h"
#include "clock36xx.h"
-
+#define to_clk_divider(_hw) container_of(_hw, struct clk_divider, hw)
/**
* omap36xx_pwrdn_clk_enable_with_hsdiv_restore - enable clocks suffering
@@ -39,29 +40,28 @@
*/
int omap36xx_pwrdn_clk_enable_with_hsdiv_restore(struct clk_hw *clk)
{
- struct clk_hw_omap *parent;
+ struct clk_divider *parent;
struct clk_hw *parent_hw;
- u32 dummy_v, orig_v, clksel_shift;
+ u32 dummy_v, orig_v;
int ret;
/* Clear PWRDN bit of HSDIVIDER */
ret = omap2_dflt_clk_enable(clk);
parent_hw = __clk_get_hw(__clk_get_parent(clk->clk));
- parent = to_clk_hw_omap(parent_hw);
+ parent = to_clk_divider(parent_hw);
/* Restore the dividers */
if (!ret) {
- clksel_shift = __ffs(parent->clksel_mask);
- orig_v = __raw_readl(parent->clksel_reg);
+ orig_v = __raw_readl(parent->reg);
dummy_v = orig_v;
/* Write any other value different from the Read value */
- dummy_v ^= (1 << clksel_shift);
- __raw_writel(dummy_v, parent->clksel_reg);
+ dummy_v ^= (1 << parent->shift);
+ __raw_writel(dummy_v, parent->reg);
/* Write the original divider */
- __raw_writel(orig_v, parent->clksel_reg);
+ __raw_writel(orig_v, parent->reg);
}
return ret;
--
1.7.9.5
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 3.9-stable] arm: omap2: fix AM33xx hwmod infos for UART2
This patch looks like it should be in the 3.9-stable tree, should we apply
it?
--
From: "Thomas Petazzoni "
commit 768dc16397fb18c9de209cbcb84d890b8279faa7 upstream
The UART2 hwmod structure is pointing to the EDMA channels of UART1,
which doesn't look right. This patch fixes this by making the UART2
hwmod structure to a new structure that lists the EDMA channels to be
used by the UART2.
Signed-off-by: Thomas Petazzoni
Acked-by: Vaibhav Hiremath
[p...@pwsan.com: updated to apply]
Signed-off-by: Paul Walmsley
Signed-off-by: Jonghwan Choi
---
arch/arm/mach-omap2/omap_hwmod_33xx_data.c |9 -
1 file changed, 8 insertions(+), 1 deletion(-)
diff --git a/arch/arm/mach-omap2/omap_hwmod_33xx_data.c
b/arch/arm/mach-omap2/omap_hwmod_33xx_data.c
index 26eee4a..6a57150 100644
--- a/arch/arm/mach-omap2/omap_hwmod_33xx_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_33xx_data.c
@@ -1979,6 +1979,13 @@ static struct omap_hwmod am33xx_uart1_hwmod = {
},
};
+/* uart2 */
+static struct omap_hwmod_dma_info uart2_edma_reqs[] = {
+ { .name = "tx", .dma_req = 28, },
+ { .name = "rx", .dma_req = 29, },
+ { .dma_req = -1 }
+};
+
static struct omap_hwmod_irq_info am33xx_uart2_irqs[] = {
{ .irq = 73 + OMAP_INTC_START, },
{ .irq = -1 },
@@ -1989,7 +1996,7 @@ static struct omap_hwmod am33xx_uart2_hwmod = {
.class = &uart_class,
.clkdm_name = "l4ls_clkdm",
.mpu_irqs = am33xx_uart2_irqs,
- .sdma_reqs = uart1_edma_reqs,
+ .sdma_reqs = uart2_edma_reqs,
.main_clk = "dpll_per_m2_div4_ck",
.prcm = {
.omap4 = {
--
1.7.9.5
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 3.9-stable] ARM: tegra30: clocks: Fix pciex clock registration
This patch looks like it should be in the 3.9-stable tree, should we apply
it?
--
From: "Jay Agarwal "
commit ff49fad1d9bf2c49f52817b04cde8e4412434637 upstream
Registering pciex as peripheral clock instead of fixed clock
as tegra_perih_reset_assert(deassert) api of this clock api
gives warning and ultimately does not succeed to assert(deassert)
Signed-off-by: Jay Agarwal
Acked-by: Stephen Warren
Signed-off-by: Mike Turquette
Signed-off-by: Jonghwan Choi
---
drivers/clk/tegra/clk-tegra30.c | 11 ++-
1 file changed, 6 insertions(+), 5 deletions(-)
diff --git a/drivers/clk/tegra/clk-tegra30.c
b/drivers/clk/tegra/clk-tegra30.c
index ba6f51b..1f8595b 100644
--- a/drivers/clk/tegra/clk-tegra30.c
+++ b/drivers/clk/tegra/clk-tegra30.c
@@ -1592,6 +1592,12 @@ static void __init tegra30_periph_clk_init(void)
clk_register_clkdev(clk, "afi", "tegra-pcie");
clks[afi] = clk;
+ /* pciex */
+ clk = tegra_clk_register_periph_gate("pciex", "pll_e", 0, clk_base,
0,
+ 74, &periph_u_regs,
periph_clk_enb_refcnt);
+ clk_register_clkdev(clk, "pciex", "tegra-pcie");
+ clks[pciex] = clk;
+
/* kfuse */
clk = tegra_clk_register_periph_gate("kfuse", "clk_m",
TEGRA_PERIPH_ON_APB,
@@ -1710,11 +1716,6 @@ static void __init tegra30_fixed_clk_init(void)
1, 0, &cml_lock);
clk_register_clkdev(clk, "cml1", NULL);
clks[cml1] = clk;
-
- /* pciex */
- clk = clk_register_fixed_rate(NULL, "pciex", "pll_e", 0, 1);
- clk_register_clkdev(clk, "pciex", NULL);
- clks[pciex] = clk;
}
static void __init tegra30_osc_clk_init(void)
--
1.7.9.5
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 3.9-stable] ARM: EXYNOS: fix software reset logic for EXYNOS5440 SOC
This patch looks like it should be in the 3.9-stable tree, should we apply
it?
--
From: "Jungseok Lee "
commit 1ba830c9997214a7fbe4d91cf238793764620e3b upstream
This patch fixes software reset logic. Software reset applies only to
powered-on domains in SOC because software reset to all domains causes
reboot failure.
Signed-off-by: Jungseok Lee
Signed-off-by: Kukjin Kim
Signed-off-by: Jonghwan Choi
---
arch/arm/mach-exynos/common.c |9 -
1 file changed, 8 insertions(+), 1 deletion(-)
diff --git a/arch/arm/mach-exynos/common.c b/arch/arm/mach-exynos/common.c
index d63d399..4d962ec 100644
--- a/arch/arm/mach-exynos/common.c
+++ b/arch/arm/mach-exynos/common.c
@@ -308,9 +308,16 @@ void exynos5_restart(char mode, const char *cmd)
val = 0x1;
addr = EXYNOS_SWRESET;
} else if (of_machine_is_compatible("samsung,exynos5440")) {
+ u32 status;
np = of_find_compatible_node(NULL, NULL,
"samsung,exynos5440-clock");
+
+ addr = of_iomap(np, 0) + 0xbc;
+ status = __raw_readl(addr);
+
addr = of_iomap(np, 0) + 0xcc;
- val = (0xfff << 20) | (0x1 << 16);
+ val = __raw_readl(addr);
+
+ val = (val & 0x) | (status & 0x);
} else {
pr_err("%s: cannot support non-DT\n", __func__);
return;
--
1.7.9.5
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 3.9-stable] ASoC: wm8994: use the correct pointer to get the control
This patch looks like it should be in the 3.9-stable tree, should we apply
it?
--
From: "Vinod Koul "
commit d3134e211e8db7fa833c40b5879fc022693e16c2 upstream
Signed-off-by: Vinod Koul
Signed-off-by: Mark Brown
Signed-off-by: Jonghwan Choi
---
sound/soc/codecs/wm8994.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/sound/soc/codecs/wm8994.c b/sound/soc/codecs/wm8994.c
index 3b269fa..8b769ba 100644
--- a/sound/soc/codecs/wm8994.c
+++ b/sound/soc/codecs/wm8994.c
@@ -1031,7 +1031,7 @@ static int aif1clk_ev(struct snd_soc_dapm_widget *w,
{
struct snd_soc_codec *codec = w->codec;
struct wm8994_priv *wm8994 = snd_soc_codec_get_drvdata(codec);
- struct wm8994 *control = codec->control_data;
+ struct wm8994 *control = wm8994->wm8994;
int mask = WM8994_AIF1DAC1L_ENA | WM8994_AIF1DAC1R_ENA;
int i;
int dac;
--
1.7.9.5
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 3.9-stable] ASoC: wm8994: Fix reporting of accessory removal on
This patch looks like it should be in the 3.9-stable tree, should we apply
it?
--
From: "Mark Brown "
commit 9767a58b8b2a0b153c246fb6306c7d48d51bb379 upstream
During recent refactoring the code to report removal when MICDET reports
an absent microphone was removed, causing problems for systems which rely
solely on the MICDET for this functionality. Restore it.
Signed-off-by: Mark Brown
Signed-off-by: Jonghwan Choi
---
sound/soc/codecs/wm8994.c |5 +
1 file changed, 5 insertions(+)
diff --git a/sound/soc/codecs/wm8994.c b/sound/soc/codecs/wm8994.c
index 8b769ba..f9dc7c0 100644
--- a/sound/soc/codecs/wm8994.c
+++ b/sound/soc/codecs/wm8994.c
@@ -3791,6 +3791,11 @@ static irqreturn_t wm8958_mic_irq(int irq, void
*data)
dev_dbg(codec->dev, "Ignoring removed jack\n");
return IRQ_HANDLED;
}
+ } else if (!(reg & WM8958_MICD_STS)) {
+ snd_soc_jack_report(wm8994->micdet[0].jack, 0,
+ SND_JACK_MECHANICAL | SND_JACK_HEADSET |
+ wm8994->btn_mask);
+ goto out;
}
if (wm8994->mic_detecting)
--
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 3.9-stable] staging:iio:light:tsl2x7x: fix the error handling in tsl2x7x_probe()
Thanks for the kind reply.
Best Regards.~
> -Original Message-
> From: Jonathan Cameron [mailto:ji...@jic23.retrosnub.co.uk]
> Sent: Monday, June 03, 2013 12:13 AM
> To: Jonghwan Choi
> Cc: linux-kernel@vger.kernel.org; sta...@vger.kernel.org; 'Wei Yongjun';
> 'Jonathan Cameron'
> Subject: Re: [PATCH 3.9-stable] staging:iio:light:tsl2x7x: fix the error
> handling in tsl2x7x_probe()
>
> On 05/24/2013 03:42 AM, Jonghwan Choi wrote:
> > This patch looks like it should be in the 3.9-stable tree, should we
> apply
> > it?
> It's a pretty unlikely problem to hit in reality so up to you on whether
> you think it worth picking up. Also note that only the -EINVAL bit
> is actually a fix. The rest of it was some incidental tidying up.
>
> Jonathan
>
> > --
> >
> > From: "Wei Yongjun "
> >
> > commit 3b813798aa7030f1beef638c75f8b0008f737a82 upstream
> >
> > Fix to return -EINVAL in the i2c device found error handling
> > case instead of 0, as done elsewhere in this function.
> > And also correct the fail1 and fail2 lable to do the right thing.
> >
> > Signed-off-by: Wei Yongjun
> > Signed-off-by: Jonathan Cameron
> > Signed-off-by: Jonghwan Choi
> > ---
> > drivers/staging/iio/light/tsl2x7x_core.c |9 +
> > 1 file changed, 5 insertions(+), 4 deletions(-)
> >
> > diff --git a/drivers/staging/iio/light/tsl2x7x_core.c
> > b/drivers/staging/iio/light/tsl2x7x_core.c
> > index a58731e..2d40c03 100644
> > --- a/drivers/staging/iio/light/tsl2x7x_core.c
> > +++ b/drivers/staging/iio/light/tsl2x7x_core.c
> > @@ -1869,6 +1869,7 @@ static int tsl2x7x_probe(struct i2c_client
> *clientp,
> > dev_info(&chip->client->dev,
> > "%s: i2c device found does not match
> > expected id\n",
> > __func__);
> > + ret = -EINVAL;
> > goto fail1;
> > }
> >
> > @@ -1907,7 +1908,7 @@ static int tsl2x7x_probe(struct i2c_client
> *clientp,
> > if (ret) {
> > dev_err(&clientp->dev,
> > "%s: irq request failed", __func__);
> > - goto fail2;
> > + goto fail1;
> > }
> > }
> >
> > @@ -1920,17 +1921,17 @@ static int tsl2x7x_probe(struct i2c_client
> *clientp,
> > if (ret) {
> > dev_err(&clientp->dev,
> > "%s: iio registration failed\n", __func__);
> > - goto fail1;
> > + goto fail2;
> > }
> >
> > dev_info(&clientp->dev, "%s Light sensor found.\n", id->name);
> >
> > return 0;
> >
> > -fail1:
> > +fail2:
> > if (clientp->irq)
> > free_irq(clientp->irq, indio_dev);
> > -fail2:
> > +fail1:
> > iio_device_free(indio_dev);
> >
> > return ret;
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 3.9-stable] jfs: Several bugs in jfs_freeze() and jfs_unfreeze()
This patch looks like it should be in the 3.9-stable tree, should we apply
it?
--
From: "Vahram Martirosyan "
commit e9b376671910d105c5e61103111b96209c729529 upstream
The mentioned functions do not pay attention to the error codes returned
by the functions updateSuper(), lmLogInit() and lmLogShutdown(). It brings
to system crash later when writing to log.
The patch adds corresponding code to check and return the error codes
and to print correct error messages in case of errors.
Found by Linux File System Verification project (linuxtesting.org).
Signed-off-by: Vahram Martirosyan
Reviewed-by: Gu Zheng
Signed-off-by: Dave Kleikamp
Signed-off-by: Jonghwan Choi
---
fs/jfs/super.c | 38 ++
1 file changed, 30 insertions(+), 8 deletions(-)
diff --git a/fs/jfs/super.c b/fs/jfs/super.c
index 1a543be..2502d39 100644
--- a/fs/jfs/super.c
+++ b/fs/jfs/super.c
@@ -611,11 +611,28 @@ static int jfs_freeze(struct super_block *sb)
{
struct jfs_sb_info *sbi = JFS_SBI(sb);
struct jfs_log *log = sbi->log;
+ int rc = 0;
if (!(sb->s_flags & MS_RDONLY)) {
txQuiesce(sb);
- lmLogShutdown(log);
- updateSuper(sb, FM_CLEAN);
+ rc = lmLogShutdown(log);
+ if (rc) {
+ jfs_error(sb, "jfs_freeze: lmLogShutdown failed");
+
+ /* let operations fail rather than hang */
+ txResume(sb);
+
+ return rc;
+ }
+ rc = updateSuper(sb, FM_CLEAN);
+ if (rc) {
+ jfs_err("jfs_freeze: updateSuper failed\n");
+ /*
+* Don't fail here. Everything succeeded except
+* marking the superblock clean, so there's really
+* no harm in leaving it frozen for now.
+*/
+ }
}
return 0;
}
@@ -627,13 +644,18 @@ static int jfs_unfreeze(struct super_block *sb)
int rc = 0;
if (!(sb->s_flags & MS_RDONLY)) {
- updateSuper(sb, FM_MOUNT);
- if ((rc = lmLogInit(log)))
- jfs_err("jfs_unlock failed with return code %d",
rc);
- else
- txResume(sb);
+ rc = updateSuper(sb, FM_MOUNT);
+ if (rc) {
+ jfs_error(sb, "jfs_unfreeze: updateSuper failed");
+ goto out;
+ }
+ rc = lmLogInit(log);
+ if (rc)
+ jfs_error(sb, "jfs_unfreeze: lmLogInit failed");
+out:
+ txResume(sb);
}
- return 0;
+ return rc;
}
static struct dentry *jfs_do_mount(struct file_system_type *fs_type,
--
1.7.9.5
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 3.9-stable] s5p makefiles: don't override other selections on obj-[ym]
This patch looks like it should be in the 3.9-stable tree, should we apply it? -- From: "Mauro Carvalho Chehab " commit 5f63adbb4cb9f952a8daee97f89c8811da5fd68a upstream The $obj-m/$obj-y vars should be adding new modules to build, not overriding it. So, it should never use $obj-y := foo.o instead, it should use: $obj-y += foo.o Failing to do that is very bad, as it will suppress needed modules. Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Jonghwan Choi --- drivers/media/platform/s5p-jpeg/Makefile |2 +- drivers/media/platform/s5p-mfc/Makefile |2 +- 2 files changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/media/platform/s5p-jpeg/Makefile b/drivers/media/platform/s5p-jpeg/Makefile index ddc2900..d18cb5e 100644 --- a/drivers/media/platform/s5p-jpeg/Makefile +++ b/drivers/media/platform/s5p-jpeg/Makefile @@ -1,2 +1,2 @@ s5p-jpeg-objs := jpeg-core.o -obj-$(CONFIG_VIDEO_SAMSUNG_S5P_JPEG) := s5p-jpeg.o +obj-$(CONFIG_VIDEO_SAMSUNG_S5P_JPEG) += s5p-jpeg.o diff --git a/drivers/media/platform/s5p-mfc/Makefile b/drivers/media/platform/s5p-mfc/Makefile index 379008c..15f59b3 100644 --- a/drivers/media/platform/s5p-mfc/Makefile +++ b/drivers/media/platform/s5p-mfc/Makefile @@ -1,4 +1,4 @@ -obj-$(CONFIG_VIDEO_SAMSUNG_S5P_MFC) := s5p-mfc.o +obj-$(CONFIG_VIDEO_SAMSUNG_S5P_MFC) += s5p-mfc.o s5p-mfc-y += s5p_mfc.o s5p_mfc_intr.o s5p-mfc-y += s5p_mfc_dec.o s5p_mfc_enc.o s5p-mfc-y += s5p_mfc_ctrl.o s5p_mfc_pm.o -- 1.7.9.5 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] PCI: fix typo in iov.c
Devic3 should be device. Signed-off-by: Jonghwan Choi --- drivers/pci/iov.c |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/pci/iov.c b/drivers/pci/iov.c index de8ffac..de4034e 100644 --- a/drivers/pci/iov.c +++ b/drivers/pci/iov.c @@ -786,7 +786,7 @@ int pci_sriov_set_totalvfs(struct pci_dev *dev, u16 numvfs) EXPORT_SYMBOL_GPL(pci_sriov_set_totalvfs); /** - * pci_sriov_get_totalvfs -- get total VFs supported on this devic3 + * pci_sriov_get_totalvfs -- get total VFs supported on this device * @dev: the PCI PF device * * For a PCIe device with SRIOV support, return the PCIe -- 1.7.9.5 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 3.9-stable] iwlegacy: fix rate control regression
This patch looks like it should be in the 3.9-stable tree, should we apply
it?
--
From: "Stanislaw Gruszka "
commit a8cf0194b7187fb65dfff28a1c5153d442e3836a upstream
Since driver does not use control.rates[0].count, we have never set that
variable. But currently, after rate control API rewrite, this is required
by mac80211. Otherwise legacy rates control does not work and we transmit
always at 1Mbit/s on pre 11n networks.
Signed-off-by: Stanislaw Gruszka
Signed-off-by: John W. Linville
Signed-off-by: Jonghwan Choi
---
drivers/net/wireless/iwlegacy/3945-rs.c |1 +
drivers/net/wireless/iwlegacy/4965-rs.c |2 +-
2 files changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/net/wireless/iwlegacy/3945-rs.c
b/drivers/net/wireless/iwlegacy/3945-rs.c
index d4fd29a..dde7ff0 100644
--- a/drivers/net/wireless/iwlegacy/3945-rs.c
+++ b/drivers/net/wireless/iwlegacy/3945-rs.c
@@ -816,6 +816,7 @@ out:
rs_sta->last_txrate_idx = idx;
info->control.rates[0].idx = rs_sta->last_txrate_idx;
}
+ info->control.rates[0].count = 1;
D_RATE("leave: %d\n", idx);
}
diff --git a/drivers/net/wireless/iwlegacy/4965-rs.c
b/drivers/net/wireless/iwlegacy/4965-rs.c
index 6c7493c..38fb9e1 100644
--- a/drivers/net/wireless/iwlegacy/4965-rs.c
+++ b/drivers/net/wireless/iwlegacy/4965-rs.c
@@ -2268,7 +2268,7 @@ il4965_rs_get_rate(void *il_r, struct ieee80211_sta
*sta, void *il_sta,
info->control.rates[0].flags = 0;
}
info->control.rates[0].idx = rate_idx;
-
+ info->control.rates[0].count = 1;
}
static void *
--
1.7.9.5
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 3.9-stable] Bluetooth: btmrvl: fix thread stopping race
This patch looks like it should be in the 3.9-stable tree, should we apply
it?
--
From: "Daniel Drake "
commit ea05fea9042620ac3b8ab9a3e5e4d2ed80c89244 upstream
There is currently a race condition in the btmrvl_remove_card() which
is causing hangs on suspend for OLPC. When the race occurs,
kthread_stop() never returns.
The problem is that btmrvl_service_main_thread() calls kthread_should_stop()
and then does a fair number of things before restarting the loop and
sleeping.
If the thread gets stopped after kthread_should_stop() is checked, but
before the sleep happens, the thread will go to sleep and won't necessarily
be woken up.
Move the kthread_should_stop() check into a race-free place.
Signed-off-by: Daniel Drake
Signed-off-by: Gustavo Padovan
Signed-off-by: John W. Linville
Signed-off-by: Jonghwan Choi
---
drivers/bluetooth/btmrvl_main.c |9 -
1 file changed, 4 insertions(+), 5 deletions(-)
diff --git a/drivers/bluetooth/btmrvl_main.c
b/drivers/bluetooth/btmrvl_main.c
index 3a4343b..9a9f518 100644
--- a/drivers/bluetooth/btmrvl_main.c
+++ b/drivers/bluetooth/btmrvl_main.c
@@ -498,6 +498,10 @@ static int btmrvl_service_main_thread(void *data)
add_wait_queue(&thread->wait_q, &wait);
set_current_state(TASK_INTERRUPTIBLE);
+ if (kthread_should_stop()) {
+ BT_DBG("main_thread: break from main thread");
+ break;
+ }
if (adapter->wakeup_tries ||
((!adapter->int_count) &&
@@ -513,11 +517,6 @@ static int btmrvl_service_main_thread(void *data)
BT_DBG("main_thread woke up");
- if (kthread_should_stop()) {
- BT_DBG("main_thread: break from main thread");
- break;
- }
-
spin_lock_irqsave(&priv->driver_lock, flags);
if (adapter->int_count) {
adapter->int_count = 0;
--
1.7.9.5
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 3.9-stable] iwlwifi: fix rate control regression
This patch looks like it should be in the 3.9-stable tree, should we apply it? -- From: "Moshe Benji " commit 622ebe994f6866b8d46ee5d3bcc329ed65d3722d upstream Since driver does not use control.rates[0].count, we have never set that variable. But currently, after rate control API rewrite, this is required by mac80211. Otherwise legacy rates control does not work and we transmit always at 1Mbit/s on pre 11n networks. [same fix as for iwlegacy, thanks Stanislaw!] Signed-off-by: Moshe Benji Reviewed-by: Emmanuel Grumbach Signed-off-by: Johannes Berg Signed-off-by: Jonghwan Choi --- drivers/net/wireless/iwlwifi/dvm/rs.c |2 +- drivers/net/wireless/iwlwifi/mvm/rs.c |1 + 2 files changed, 2 insertions(+), 1 deletion(-) diff --git a/drivers/net/wireless/iwlwifi/dvm/rs.c b/drivers/net/wireless/iwlwifi/dvm/rs.c index abe3042..5de2dbf 100644 --- a/drivers/net/wireless/iwlwifi/dvm/rs.c +++ b/drivers/net/wireless/iwlwifi/dvm/rs.c @@ -2799,7 +2799,7 @@ static void rs_get_rate(void *priv_r, struct ieee80211_sta *sta, void *priv_sta, info->control.rates[0].flags = 0; } info->control.rates[0].idx = rate_idx; - + info->control.rates[0].count = 1; } static void *rs_alloc_sta(void *priv_rate, struct ieee80211_sta *sta, diff --git a/drivers/net/wireless/iwlwifi/mvm/rs.c b/drivers/net/wireless/iwlwifi/mvm/rs.c index 56b636d..fefcbc5 100644 --- a/drivers/net/wireless/iwlwifi/mvm/rs.c +++ b/drivers/net/wireless/iwlwifi/mvm/rs.c @@ -2544,6 +2544,7 @@ static void rs_get_rate(void *mvm_r, struct ieee80211_sta *sta, void *mvm_sta, info->control.rates[0].flags = 0; } info->control.rates[0].idx = rate_idx; + info->control.rates[0].count = 1; } static void *rs_alloc_sta(void *mvm_rate, struct ieee80211_sta *sta, -- 1.7.9.5 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 3.10-stable] ARM: KVM: Fix 64-bit coprocessor handling
This patch looks like it should be in the 3.10-stable tree, should we apply
it?
--
From: "Christoffer Dall "
commit 240e99cbd00aa541b572480e3ea7ecb0d480bc79 upstream
The PAR was exported as CRn == 7 and CRm == 0, but in fact the primary
coprocessor register number was determined by CRm for 64-bit coprocessor
registers as the user space API was modeled after the coprocessor
access instructions (see the ARM ARM rev. C - B3-1445).
However, just changing the CRn to CRm breaks the sorting check when
booting the kernel, because the internal kernel logic always treats CRn
as the primary register number, and it makes the table sorting
impossible to understand for humans.
Alternatively we could change the logic to always have CRn == CRm, but
that becomes unclear in the number of ways we do look up of a coprocessor
register. We could also have a separate 64-bit table but that feels
somewhat over-engineered. Instead, keep CRn the primary representation
of the primary coproc. register number in-kernel and always export the
primary number as CRm as per the existing user space ABI.
Note: The TTBR registers just magically worked because they happened to
follow the CRn(0) regs and were considered CRn(0) in the in-kernel
representation.
Signed-off-by: Christoffer Dall
Signed-off-by: Jonghwan Choi
---
arch/arm/kvm/coproc.c | 26 +++---
arch/arm/kvm/coproc.h |3 +++
arch/arm/kvm/coproc_a15.c |6 +-
3 files changed, 27 insertions(+), 8 deletions(-)
diff --git a/arch/arm/kvm/coproc.c b/arch/arm/kvm/coproc.c
index 4a51990..db9cf69 100644
--- a/arch/arm/kvm/coproc.c
+++ b/arch/arm/kvm/coproc.c
@@ -146,7 +146,11 @@ static bool pm_fake(struct kvm_vcpu *vcpu,
#define access_pmintenclr pm_fake
/* Architected CP15 registers.
- * Important: Must be sorted ascending by CRn, CRM, Op1, Op2
+ * CRn denotes the primary register number, but is copied to the CRm in the
+ * user space API for 64-bit register access in line with the terminology
used
+ * in the ARM ARM.
+ * Important: Must be sorted ascending by CRn, CRM, Op1, Op2 and with
64-bit
+ *registers preceding 32-bit ones.
*/
static const struct coproc_reg cp15_regs[] = {
/* CSSELR: swapped by interrupt.S. */
@@ -154,8 +158,8 @@ static const struct coproc_reg cp15_regs[] = {
NULL, reset_unknown, c0_CSSELR },
/* TTBR0/TTBR1: swapped by interrupt.S. */
- { CRm( 2), Op1( 0), is64, NULL, reset_unknown64, c2_TTBR0 },
- { CRm( 2), Op1( 1), is64, NULL, reset_unknown64, c2_TTBR1 },
+ { CRm64( 2), Op1( 0), is64, NULL, reset_unknown64, c2_TTBR0 },
+ { CRm64( 2), Op1( 1), is64, NULL, reset_unknown64, c2_TTBR1 },
/* TTBCR: swapped by interrupt.S. */
{ CRn( 2), CRm( 0), Op1( 0), Op2( 2), is32,
@@ -182,7 +186,7 @@ static const struct coproc_reg cp15_regs[] = {
NULL, reset_unknown, c6_IFAR },
/* PAR swapped by interrupt.S */
- { CRn( 7), Op1( 0), is64, NULL, reset_unknown64, c7_PAR },
+ { CRm64( 7), Op1( 0), is64, NULL, reset_unknown64, c7_PAR },
/*
* DC{C,I,CI}SW operations:
@@ -399,12 +403,13 @@ static bool index_to_params(u64 id, struct
coproc_params *params)
| KVM_REG_ARM_OPC1_MASK))
return false;
params->is_64bit = true;
- params->CRm = ((id & KVM_REG_ARM_CRM_MASK)
+ /* CRm to CRn: see cp15_to_index for details */
+ params->CRn = ((id & KVM_REG_ARM_CRM_MASK)
>> KVM_REG_ARM_CRM_SHIFT);
params->Op1 = ((id & KVM_REG_ARM_OPC1_MASK)
>> KVM_REG_ARM_OPC1_SHIFT);
params->Op2 = 0;
- params->CRn = 0;
+ params->CRm = 0;
return true;
default:
return false;
@@ -898,7 +903,14 @@ static u64 cp15_to_index(const struct coproc_reg *reg)
if (reg->is_64) {
val |= KVM_REG_SIZE_U64;
val |= (reg->Op1 << KVM_REG_ARM_OPC1_SHIFT);
- val |= (reg->CRm << KVM_REG_ARM_CRM_SHIFT);
+ /*
+* CRn always denotes the primary coproc. reg. nr. for the
+* in-kernel representation, but the user space API uses the
+* CRm for the encoding, because it is modelled after the
+* MRRC/MCRR instructions: see the ARM ARM rev. c page
+* B3-1445
+*/
+ val |= (reg->CRn << KVM_REG_ARM_CRM_SHIFT);
} else {
val |= KVM_REG_SIZE_U32;
val |= (reg->Op1 << KVM_REG_ARM_OPC1_SHIFT);
diff --git a/arch/arm/kvm/coproc.h b/arch/arm/kvm/coproc.h
index b7301d3..0461d5c 100644
--- a/arch/arm/kvm/coproc.h
+++ b/arch/arm/kvm/coproc.h
@@ -135,6 +135,8 @
[PATCH 3.8-stable] bonding: remove sysfs before removing devices
This patch looks like it should be in the 3.8-stable tree, should we apply it? -- From: "Veaceslav Falico " commit 4de79c737b200492195ebc54a887075327e1ec1d upstream We have a race condition if we try to rmmod bonding and simultaneously add a bond master through sysfs. In bonding_exit() we first remove the devices (through rtnl_link_unregister() ) and only after that we remove the sysfs. If we manage to add a device through sysfs after that the devices were removed - we'll end up with that device/sysfs structure and with the module unloaded. Fix this by first removing the sysfs and only after that calling rtnl_link_unregister(). Signed-off-by: Veaceslav Falico Signed-off-by: David S. Miller Signed-off-by: Jonghwan Choi --- drivers/net/bonding/bond_main.c |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/net/bonding/bond_main.c b/drivers/net/bonding/bond_main.c index 27cdf1f..fb6b559 100644 --- a/drivers/net/bonding/bond_main.c +++ b/drivers/net/bonding/bond_main.c @@ -4975,8 +4975,8 @@ static void __exit bonding_exit(void) bond_destroy_debugfs(); - rtnl_link_unregister(&bond_link_ops); unregister_pernet_subsys(&bond_net_ops); + rtnl_link_unregister(&bond_link_ops); #ifdef CONFIG_NET_POLL_CONTROLLER /* -- 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/
[RESEND PATCH 3.8-stable] cpufreq: exynos: Get booting freq value in exynos_cpufreq_init
This patch looks like it should be in the 3.8-stable tree, should we
applyit?
--
From: "Jonghwan Choi "
commit 6e45eb12fd1c741d556bf264ee98853b5f3104e5 upstream
Boot_freq is for saving booting freq. But exynos_cpufreq_cpu_init
is called in hotplug. If boot_freq is existed in exynos_cpufreq_cpu_init,
boot_freq could be changed.
Signed-off-by: Jonghwan Choi
Signed-off-by: Kukjin Kim
Signed-off-by: Jonghwan Choi
---
drivers/cpufreq/exynos-cpufreq.c |4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/cpufreq/exynos-cpufreq.c
b/drivers/cpufreq/exynos-cpufreq.c
index 7012ea8..41fc550 100644
--- a/drivers/cpufreq/exynos-cpufreq.c
+++ b/drivers/cpufreq/exynos-cpufreq.c
@@ -222,8 +222,6 @@ static int exynos_cpufreq_cpu_init(struct cpufreq_policy
*policy)
cpufreq_frequency_table_get_attr(exynos_info->freq_table,
policy->cpu);
- locking_frequency = exynos_getspeed(0);
-
/* set the transition latency value */
policy->cpuinfo.transition_latency = 10;
@@ -288,6 +286,8 @@ static int __init exynos_cpufreq_init(void)
goto err_vdd_arm;
}
+ locking_frequency = exynos_getspeed(0);
+
register_pm_notifier(&exynos_cpufreq_nb);
if (cpufreq_register_driver(&exynos_driver)) {
--
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/
[RESEND PATCH 3.8-stable] ARM: EXYNOS: Fix crash on soft reset on EXYNOS5440
This patch looks like it should be in the 3.8-stable tree, should we apply
it?
--
From: "Thomas Abraham "
commit 60db7e5f9c9a25a7a9b01007e6e3f5a93bc16a3a upstream
The soft-reset control register is located in the XMU controller space.
Map this controller space before writing to the soft-reset controller
register.
Signed-off-by: Thomas Abraham
Signed-off-by: Girish K S
Signed-off-by: Kukjin
Signed-off-by: Jonghwan Choi
---
arch/arm/mach-exynos/common.c |6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/arch/arm/mach-exynos/common.c b/arch/arm/mach-exynos/common.c
index 1a89824..3b6de7a 100644
--- a/arch/arm/mach-exynos/common.c
+++ b/arch/arm/mach-exynos/common.c
@@ -299,6 +299,7 @@ void exynos4_restart(char mode, const char *cmd)
void exynos5_restart(char mode, const char *cmd)
{
+ struct device_node *np;
u32 val;
void __iomem *addr;
@@ -306,8 +307,9 @@ void exynos5_restart(char mode, const char *cmd)
val = 0x1;
addr = EXYNOS_SWRESET;
} else if (of_machine_is_compatible("samsung,exynos5440")) {
- val = (0x10 << 20) | (0x1 << 16);
- addr = EXYNOS5440_SWRESET;
+ np = of_find_compatible_node(NULL, NULL,
"samsung,exynos5440-clock");
+ addr = of_iomap(np, 0) + 0xcc;
+ val = (0xfff << 20) | (0x1 << 16);
} else {
pr_err("%s: cannot support non-DT\n", __func__);
return;
--
1.7.9.5
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 3.8-stable] kernel/audit_tree.c: tree will leak memory when failure occurs in audit_trim_trees()
This patch looks like it should be in the 3.8-stable tree, should we apply it? -- From: "Chen Gang " commit 12b2f117f3bf738c1a00a6f64393f1953a740bd4 upstream audit_trim_trees() calls get_tree(). If a failure occurs we must call put_tree(). [a...@linux-foundation.org: run put_tree() before mutex_lock() for small scalability improvement] Signed-off-by: Chen Gang Cc: Al Viro Cc: Eric Paris Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Jonghwan Choi --- kernel/audit_tree.c |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/kernel/audit_tree.c b/kernel/audit_tree.c index 642a89c..a291aa2 100644 --- a/kernel/audit_tree.c +++ b/kernel/audit_tree.c @@ -617,9 +617,9 @@ void audit_trim_trees(void) } spin_unlock(&hash_lock); trim_marked(tree); - put_tree(tree); drop_collected_mounts(root_mnt); skip_it: + put_tree(tree); mutex_lock(&audit_filter_mutex); } list_del(&cursor); -- 1.7.9.5 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] virtio_blk: Add missing 'static' qualifiers
Add missing 'static' qualifiers
Signed-off-by: Jonghwan Choi
---
drivers/block/virtio_blk.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/block/virtio_blk.c b/drivers/block/virtio_blk.c
index 6472395..5cdf88b 100644
--- a/drivers/block/virtio_blk.c
+++ b/drivers/block/virtio_blk.c
@@ -20,7 +20,7 @@ module_param(use_bio, bool, S_IRUGO);
static int major;
static DEFINE_IDA(vd_index_ida);
-struct workqueue_struct *virtblk_wq;
+static struct workqueue_struct *virtblk_wq;
struct virtio_blk
{
--
1.7.9.5
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 3.9-stable] mmc: dw_mmc: fix fifo access for 64-bit
This patch looks like it should be in the 3.9-stable tree, should we apply
it?
--
From: "Seungwon Jeon "
commit c09fbd7451b797213b3df8bf06b9ec33f954 upstream
mci_writew causes a failure of fifo access for 64-bit.
mci_writeq is correct.
Signed-off-by: Seungwon Jeon
Acked-by: Jaehoon Chung
Signed-off-by: Chris Ball
Signed-off-by: Jonghwan Choi
---
drivers/mmc/host/dw_mmc.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/mmc/host/dw_mmc.c b/drivers/mmc/host/dw_mmc.c
index 9834221..cc8d8de 100644
--- a/drivers/mmc/host/dw_mmc.c
+++ b/drivers/mmc/host/dw_mmc.c
@@ -1353,7 +1353,7 @@ static void dw_mci_push_data64(struct dw_mci *host,
void *buf, int cnt)
buf += len;
cnt -= len;
if (!sg_next(host->sg) || host->part_buf_count == 8) {
- mci_writew(host, DATA(host->data_offset),
+ mci_writeq(host, DATA(host->data_offset),
host->part_buf);
host->part_buf_count = 0;
}
--
1.7.9.5
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH] net/core Fix wrong comments about memcpy_fromiovecend
"Copy iovec from kernel" should be "Copy iovec to kernel" because copy_from_user copies data from userspace. Signed-off-by: Jonghwan Choi --- net/core/iovec.c |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/net/core/iovec.c b/net/core/iovec.c index 7e7aeb0..ba93fd2 100644 --- a/net/core/iovec.c +++ b/net/core/iovec.c @@ -150,7 +150,7 @@ int memcpy_fromiovec(unsigned char *kdata, struct iovec *iov, int len) EXPORT_SYMBOL(memcpy_fromiovec); /* - * Copy iovec from kernel. Returns -EFAULT on error. + * Copy iovec to kernel. Returns -EFAULT on error. */ int memcpy_fromiovecend(unsigned char *kdata, const struct iovec *iov, -- 1.7. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 3.9-stable] drbd: fix memory leak
This patch looks like it should be in the 3.9-stable tree, should we apply it? -- From: "Lars Ellenberg " commit 94ad0a101415978be04945b2787be1e8e8a874db upstream We forgot to free the disk_conf, so for each attach/detach cycle we leaked 336 bytes. Signed-off-by: Philipp Reisner Signed-off-by: Lars Ellenberg Signed-off-by: Jens Axboe Signed-off-by: Jonghwan Choi --- drivers/block/drbd/drbd_main.c |1 + 1 file changed, 1 insertion(+) diff --git a/drivers/block/drbd/drbd_main.c b/drivers/block/drbd/drbd_main.c index e98da67..54d03d4 100644 --- a/drivers/block/drbd/drbd_main.c +++ b/drivers/block/drbd/drbd_main.c @@ -2795,6 +2795,7 @@ void drbd_free_bc(struct drbd_backing_dev *ldev) blkdev_put(ldev->backing_bdev, FMODE_READ | FMODE_WRITE | FMODE_EXCL); blkdev_put(ldev->md_bdev, FMODE_READ | FMODE_WRITE | FMODE_EXCL); + kfree(ldev->disk_conf); kfree(ldev); } -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 3.9-stable] drbd: Fix build error when CONFIG_CRYPTO_HMAC is not set
This patch looks like it should be in the 3.9-stable tree, should we apply
it?
--
From: "Philipp Reisner "
commit ef57f9e6bb9278720c8a5278728f252ab85d7ac6 upstream
Signed-off-by: Philipp Reisner
Signed-off-by: Lars Ellenberg
Signed-off-by: Jens Axboe
Signed-off-by: Jonghwan Choi
---
drivers/block/drbd/drbd_receiver.c |4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/block/drbd/drbd_receiver.c
b/drivers/block/drbd/drbd_receiver.c
index 5105f43..2f5fffd 100644
--- a/drivers/block/drbd/drbd_receiver.c
+++ b/drivers/block/drbd/drbd_receiver.c
@@ -4658,8 +4658,8 @@ static int drbd_do_features(struct drbd_tconn *tconn)
#if !defined(CONFIG_CRYPTO_HMAC) && !defined(CONFIG_CRYPTO_HMAC_MODULE)
static int drbd_do_auth(struct drbd_tconn *tconn)
{
- dev_err(DEV, "This kernel was build without CONFIG_CRYPTO_HMAC.\n");
- dev_err(DEV, "You need to disable 'cram-hmac-alg' in drbd.conf.\n");
+ conn_err(tconn, "This kernel was build without
CONFIG_CRYPTO_HMAC.\n");
+ conn_err(tconn, "You need to disable 'cram-hmac-alg' in
drbd.conf.\n");
return -1;
}
#else
--
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 3.9-stable ]drbd: fix for deadlock when using automatic split-brain-recovery
This patch looks like it should be in the 3.9-stable tree, should we apply
it?
--
From: "Philipp Reisner "
commit 7c689e63a847316c1b2500f86891b0a574ce7e69 upstream
With an automatic after split-brain recovery policy of
"after-sb-1pri call-pri-lost-after-sb",
when trying to drbd_set_role() to R_SECONDARY,
we run into a deadlock.
This was first recognized and supposedly fixed by
2009-06-10 "Fixed a deadlock when using automatic split brain recovery when
both nodes are"
replacing drbd_set_role() with drbd_change_state() in that code-path,
but the first hunk of that patch forgets to remove the drbd_set_role().
We apparently only ever tested the "two primaries" case.
Cc: # 3.9.x: ef57f9e6: drbd: Fix build error
Signed-off-by: Philipp Reisner
Signed-off-by: Lars Ellenberg
Signed-off-by: Jens Axboe
Signed-off-by: Jonghwan Choi
---
drivers/block/drbd/drbd_receiver.c |1 -
1 file changed, 1 deletion(-)
diff --git a/drivers/block/drbd/drbd_receiver.c
b/drivers/block/drbd/drbd_receiver.c
index a9eccfc..5105f43 100644
--- a/drivers/block/drbd/drbd_receiver.c
+++ b/drivers/block/drbd/drbd_receiver.c
@@ -2661,7 +2661,6 @@ static int drbd_asb_recover_1p(struct drbd_conf *mdev)
__must_hold(local)
if (hg == -1 && mdev->state.role == R_PRIMARY) {
enum drbd_state_rv rv2;
- drbd_set_role(mdev, R_SECONDARY, 0);
/* drbd_change_state() does not sleep while in
SS_IN_TRANSIENT_STATE,
* we might be here in C_WF_REPORT_PARAMS which is
transient.
* we do not need to wait for the after state
change work either. */
--
1.7.9.5
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 3.9-stable] ARM: EXYNOS5: Fix kernel dump in AFTR idle mode
This patch looks like it should be in the 3.9-stable tree, should we apply
it?
--
From: "Inderpal Singh "
commit 088584618836b159947bc4ab5011a5cf1f081a62 upstream
The kernel crashes while resuming from AFTR idle mode. It happens
because L2 cache was not going into retention state.
This patch configures the USE_RETENTION bit of ARM_L2_OPTION register
so that it does not depend on MANUAL_L2RSTDISABLE_CONTROL of
ARM_COMMON_OPTION register for L2RSTDISABLE signal.
Signed-off-by: Inderpal Singh
Tested-by: Chander Kashyap
Signed-off-by: Olof Johansson
Signed-off-by: Jonghwan Choi
---
arch/arm/mach-exynos/include/mach/regs-pmu.h |1 +
arch/arm/mach-exynos/pmu.c |5 ++---
2 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/arch/arm/mach-exynos/include/mach/regs-pmu.h
b/arch/arm/mach-exynos/include/mach/regs-pmu.h
index 3f30aa1..57344b7 100644
--- a/arch/arm/mach-exynos/include/mach/regs-pmu.h
+++ b/arch/arm/mach-exynos/include/mach/regs-pmu.h
@@ -344,6 +344,7 @@
#define EXYNOS5_FSYS_ARM_OPTION
S5P_PMUREG(0x2208)
#define EXYNOS5_ISP_ARM_OPTION
S5P_PMUREG(0x2288)
#define EXYNOS5_ARM_COMMON_OPTION
S5P_PMUREG(0x2408)
+#define EXYNOS5_ARM_L2_OPTION
S5P_PMUREG(0x2608)
#define EXYNOS5_TOP_PWR_OPTION
S5P_PMUREG(0x2C48)
#define EXYNOS5_TOP_PWR_SYSMEM_OPTION
S5P_PMUREG(0x2CC8)
#define EXYNOS5_JPEG_MEM_OPTION
S5P_PMUREG(0x2F48)
diff --git a/arch/arm/mach-exynos/pmu.c b/arch/arm/mach-exynos/pmu.c
index daebc1a..97d6885 100644
--- a/arch/arm/mach-exynos/pmu.c
+++ b/arch/arm/mach-exynos/pmu.c
@@ -228,6 +228,7 @@ static struct exynos_pmu_conf exynos5250_pmu_config[] =
{
{ EXYNOS5_DIS_IRQ_ISP_ARM_CENTRAL_SYS_PWR_REG, { 0x0, 0x0, 0x0} },
{ EXYNOS5_ARM_COMMON_SYS_PWR_REG, { 0x0, 0x0, 0x2} },
{ EXYNOS5_ARM_L2_SYS_PWR_REG, { 0x3, 0x3, 0x3} },
+ { EXYNOS5_ARM_L2_OPTION,{ 0x10, 0x10, 0x0 }
},
{ EXYNOS5_CMU_ACLKSTOP_SYS_PWR_REG, { 0x1, 0x0, 0x1} },
{ EXYNOS5_CMU_SCLKSTOP_SYS_PWR_REG, { 0x1, 0x0, 0x1} },
{ EXYNOS5_CMU_RESET_SYS_PWR_REG,{ 0x1, 0x1, 0x0} },
@@ -353,11 +354,9 @@ static void exynos5_init_pmu(void)
/*
* SKIP_DEACTIVATE_ACEACP_IN_PWDN_BITFIELD Enable
-* MANUAL_L2RSTDISABLE_CONTROL_BITFIELD Enable
*/
tmp = __raw_readl(EXYNOS5_ARM_COMMON_OPTION);
- tmp |= (EXYNOS5_MANUAL_L2RSTDISABLE_CONTROL |
- EXYNOS5_SKIP_DEACTIVATE_ACEACP_IN_PWDN);
+ tmp |= EXYNOS5_SKIP_DEACTIVATE_ACEACP_IN_PWDN;
__raw_writel(tmp, EXYNOS5_ARM_COMMON_OPTION);
/*
--
1.7.9.5
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 3.8-stable] ARM: 7692/1: iop3xx: move IOP3XX_PERIPHERAL_VIRT_BASE
This patch looks like it should be in the 3.8-stable tree, should we apply it? -- From: "Aaro Koskinen " commit f5d6a1441a5045824f36ff7c6b6bbae0373472a6 upstream Currently IOP3XX_PERIPHERAL_VIRT_BASE conflicts with PCI_IO_VIRT_BASE: address size PCI_IO_VIRT_BASE0xfee0 0x20 IOP3XX_PERIPHERAL_VIRT_BASE 0xfeffe000 0x2000 Fix by moving IOP3XX_PERIPHERAL_VIRT_BASE below PCI_IO_VIRT_BASE. The patch fixes the following kernel panic with 3.9-rc1 on iop3xx boards: [0.00] Booting Linux on physical CPU 0x0 [0.00] Initializing cgroup subsys cpu [0.00] Linux version 3.9.0-rc1-iop32x (aaro@blackmetal) (gcc version 4.7.2 (GCC) ) #20 PREEMPT Tue Mar 5 16:44:36 EET 2013 [0.00] bootconsole [earlycon0] enabled [0.00] [ cut here ] [0.00] kernel BUG at mm/vmalloc.c:1145! [0.00] Internal error: Oops - BUG: 0 [#1] PREEMPT ARM [0.00] Modules linked in: [0.00] CPU: 0Not tainted (3.9.0-rc1-iop32x #20) [0.00] PC is at vm_area_add_early+0x4c/0x88 [0.00] LR is at add_static_vm_early+0x14/0x68 [0.00] pc : []lr : []psr: 80d3 [0.00] sp : c03ffee4 ip : dfffdf88 fp : c03ffef4 [0.00] r10: 0002 r9 : 00cf r8 : 0653 [0.00] r7 : c040eca8 r6 : c03e2408 r5 : dfffdf60 r4 : 0020 [0.00] r3 : dfffdfd8 r2 : feffe000 r1 : ff00 r0 : dfffdf60 [0.00] Flags: Nzcv IRQs off FIQs off Mode SVC_32 ISA ARM Segment kernel [0.00] Control: 397f Table: a0004000 DAC: 0017 [0.00] Process swapper (pid: 0, stack limit = 0xc03fe1b8) [0.00] Stack: (0xc03ffee4 to 0xc040) [0.00] fee0: 0020 c03fff0c c03ffef8 c03e1c40 c03e7468 0020 fee0 [0.00] ff00: c03fff2c c03fff10 c03e23e4 c03e1c38 feffe000 c0408ee4 ff00 c0408f04 [0.00] ff20: c03fff3c c03fff30 c03e2434 c03e23b4 c03fff84 c03fff40 c03e2c94 c03e2414 [0.00] ff40: c03f8878 c03f6410 000b 1000 0008 c03fff84 c03f6410 [0.00] ff60: c04227e8 c03fffd4 a0008000 c03f8878 69052e30 c02f96eb c03fffbc c03fff88 [0.00] ff80: c03e044c c03e268c 397f c0385130 0001 c03f8874 [0.00] ffa0: dfff a0004000 69052e30 a03f61a0 c034 c03fffc0 c03dd5cc c03e0184 [0.00] ffc0: c03f8878 397d c040601c [0.00] ffe0: c03f8874 c0408674 c038 a0008040 c03dd558 [0.00] Backtrace: [0.00] [] (vm_area_add_early+0x0/0x88) from [] (add_static_vm_early+0x14/0x68) Tested-by: Mikael Pettersson Signed-off-by: Aaro Koskinen Signed-off-by: Russell King Signed-off-by: Jonghwan Choi --- arch/arm/include/asm/hardware/iop3xx.h |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/arch/arm/include/asm/hardware/iop3xx.h b/arch/arm/include/asm/hardware/iop3xx.h index 02fe2fb..ed94b1a 100644 --- a/arch/arm/include/asm/hardware/iop3xx.h +++ b/arch/arm/include/asm/hardware/iop3xx.h @@ -37,7 +37,7 @@ extern int iop3xx_get_init_atu(void); * IOP3XX processor registers */ #define IOP3XX_PERIPHERAL_PHYS_BASE0xe000 -#define IOP3XX_PERIPHERAL_VIRT_BASE0xfeffe000 +#define IOP3XX_PERIPHERAL_VIRT_BASE0xfedfe000 #define IOP3XX_PERIPHERAL_SIZE 0x2000 #define IOP3XX_PERIPHERAL_UPPER_PA (IOP3XX_PERIPHERAL_PHYS_BASE +\ IOP3XX_PERIPHERAL_SIZE - 1) -- 1.7.9.5 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 3.8-stable] ARM: 7699/1: sched_clock: Add more notrace to prevent
This patch looks like it should be in the 3.8-stable tree, should we apply
it?
--
From: "Stephen Boyd "
commit cea15092f098b7018e89f64a5a14bb71955965d5 upstream
cyc_to_sched_clock() is called by sched_clock() and cyc_to_ns()
is called by cyc_to_sched_clock(). I suspect that some compilers
inline both of these functions into sched_clock() and so we've
been getting away without having a notrace marking. It seems that
my compiler isn't inlining cyc_to_sched_clock() though, so I'm
hitting a recursion bug when I enable the function graph tracer,
causing my system to crash. Marking these functions notrace fixes
it. Technically cyc_to_ns() doesn't need the notrace because it's
already marked inline, but let's just add it so that if we ever
remove inline from that function it doesn't blow up.
Signed-off-by: Stephen Boyd
Signed-off-by: Russell King
Signed-off-by: Jonghwan Choi
---
arch/arm/kernel/sched_clock.c |4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/arm/kernel/sched_clock.c b/arch/arm/kernel/sched_clock.c
index bd6f56b..59d2adb 100644
--- a/arch/arm/kernel/sched_clock.c
+++ b/arch/arm/kernel/sched_clock.c
@@ -45,12 +45,12 @@ static u32 notrace jiffy_sched_clock_read(void)
static u32 __read_mostly (*read_sched_clock)(void) =
jiffy_sched_clock_read;
-static inline u64 cyc_to_ns(u64 cyc, u32 mult, u32 shift)
+static inline u64 notrace cyc_to_ns(u64 cyc, u32 mult, u32 shift)
{
return (cyc * mult) >> shift;
}
-static unsigned long long cyc_to_sched_clock(u32 cyc, u32 mask)
+static unsigned long long notrace cyc_to_sched_clock(u32 cyc, u32 mask)
{
u64 epoch_ns;
u32 epoch_cyc;
--
1.7.9.5ml
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 3.8-stable] ARM: 7690/1: mm: fix CONFIG_LPAE typos
This patch looks like it should be in the 3.8-stable tree, should we apply
it?
--
From: "Paul Bolle "
commit 4e1db26a0b42e2b6e27c05d68adcc01709c2eed2 upstream
CONFIG_LPAE doesn't exist: the correct option is CONFIG_ARM_LPAE, so fix
up the two typos under arch/arm/.
The fix to head.S is slightly scary, but this is just for setting up
an early io-mapping for the serial port when running on a big-endian,
LPAE system. Since these systems don't exist in the wild (at least, I
have no access to one outside of kvmtool, which doesn't provide a serial
port suitable for earlyprintk), then we can revisit the code later if it
causes any problems.
Signed-off-by: Paul Bolle
Signed-off-by: Will Deacon
Signed-off-by: Russell King
Signed-off-by: Jonghwan Choi
---
arch/arm/kernel/head.S |2 +-
arch/arm/kernel/setup.c |2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/arm/kernel/head.S b/arch/arm/kernel/head.S
index e0eb9a1..8bac553 100644
--- a/arch/arm/kernel/head.S
+++ b/arch/arm/kernel/head.S
@@ -267,7 +267,7 @@ __create_page_tables:
addne r6, r6, #1 << SECTION_SHIFT
strne r6, [r3]
-#if defined(CONFIG_LPAE) && defined(CONFIG_CPU_ENDIAN_BE8)
+#if defined(CONFIG_ARM_LPAE) && defined(CONFIG_CPU_ENDIAN_BE8)
sub r4, r4, #4 @ Fixup page table pointer
@ for 64-bit descriptors
#endif
diff --git a/arch/arm/kernel/setup.c b/arch/arm/kernel/setup.c
index 3f6cbb2..62ead98 100644
--- a/arch/arm/kernel/setup.c
+++ b/arch/arm/kernel/setup.c
@@ -524,7 +524,7 @@ int __init arm_add_memory(phys_addr_t start, phys_addr_t
size)
size -= start & ~PAGE_MASK;
bank->start = PAGE_ALIGN(start);
-#ifndef CONFIG_LPAE
+#ifndef CONFIG_ARM_LPAE
if (bank->start + size < bank->start) {
printk(KERN_CRIT "Truncating memory at 0x%08llx to fit in "
"32-bit physical address space\n", (long
long)start);
--
1.7.9.5
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 3.8-stable] lib/int_sqrt.c: optimize square root algorithm
This patch looks like it should be in the 3.8-stable tree, should we apply
it?
--
From: "Davidlohr Bueso "
commit 30493cc9dddb68066dcc4878015660fdaa8e0965 upstream
Optimize the current version of the shift-and-subtract (hardware)
algorithm, described by John von Newmann[1] and Guy L Steele.
Iterating 1,000,000 times, perf shows for the current version:
Performance counter stats for './sqrt-curr' (10 runs):
27.170996 task-clock#0.979 CPUs utilized
( +- 3.19% )
3 context-switches #0.103 K/sec
( +- 4.76% )
0 cpu-migrations#0.004 K/sec
( +-100.00% )
104 page-faults #0.004 M/sec
( +- 0.16% )
64,921,199 cycles#2.389 GHz
( +- 0.03% )
28,967,789 stalled-cycles-frontend # 44.62% frontend cycles idle
( +- 0.18% )
stalled-cycles-backend
104,502,623 instructions #1.61 insns per cycle
#0.28 stalled cycles per
insn ( +- 0.00% )
34,088,368 branches # 1254.587 M/sec
( +- 0.00% )
4,901 branch-misses #0.01% of all branches
( +- 1.32% )
0.027763015 seconds time elapsed
( +- 3.22% )
And for the new version:
Performance counter stats for './sqrt-new' (10 runs):
0.496869 task-clock#0.519 CPUs utilized
( +- 2.38% )
0 context-switches #0.000 K/sec
0 cpu-migrations#0.403 K/sec
( +-100.00% )
104 page-faults #0.209 M/sec
( +- 0.15% )
590,760 cycles#1.189 GHz
( +- 2.35% )
395,053 stalled-cycles-frontend # 66.87% frontend cycles idle
( +- 3.67% )
stalled-cycles-backend
398,963 instructions #0.68 insns per cycle
#0.99 stalled cycles per
insn ( +- 0.39% )
70,228 branches # 141.341 M/sec
( +- 0.36% )
3,364 branch-misses #4.79% of all branches
( +- 5.45% )
0.000957440 seconds time elapsed
( +- 2.42% )
Furthermore, this saves space in instruction text:
textdata bss dec hex filename
111 0 0 111 6f lib/int_sqrt-baseline.o
89 0 0 89 59 lib/int_sqrt.o
[1] http://en.wikipedia.org/wiki/First_Draft_of_a_Report_on_the_EDVAC
Signed-off-by: Davidlohr Bueso
Reviewed-by: Jonathan Gonzalez
Tested-by: Jonathan Gonzalez
Signed-off-by: Andrew Morton
Signed-off-by: Linus Torvalds
Signed-off-by: Jonghwan Choi
---
lib/int_sqrt.c | 32 +++-
1 file changed, 19 insertions(+), 13 deletions(-)
diff --git a/lib/int_sqrt.c b/lib/int_sqrt.c
index fc2eeb7..1ef4cc3 100644
--- a/lib/int_sqrt.c
+++ b/lib/int_sqrt.c
@@ -1,3 +1,9 @@
+/*
+ * Copyright (C) 2013 Davidlohr Bueso
+ *
+ * Based on the shift-and-subtract algorithm for computing integer
+ * square root from Guy L. Steele.
+ */
#include
#include
@@ -10,23 +16,23 @@
*/
unsigned long int_sqrt(unsigned long x)
{
- unsigned long op, res, one;
+ unsigned long b, m, y = 0;
- op = x;
- res = 0;
+ if (x <= 1)
+ return x;
- one = 1UL << (BITS_PER_LONG - 2);
- while (one > op)
- one >>= 2;
+ m = 1UL << (BITS_PER_LONG - 2);
+ while (m != 0) {
+ b = y + m;
+ y >>= 1;
- while (one != 0) {
- if (op >= res + one) {
- op = op - (res + one);
- res = res + 2 * one;
+ if (x >= b) {
+ x -= b;
+ y += m;
}
- res /= 2;
- one /= 4;
+ m >>= 2;
}
- return res;
+
+ return y;
}
EXPORT_SYMBOL(int_sqrt);
--
1.7.9.5
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 3.8-stable] net: count hw_addr syncs so that unsync works properly.
This patch looks like it should be in the 3.8-stable tree, should we apply
it?
--
From: "Vlad Yasevich "
commit 4543fbefe6e06a9e40d9f2b28d688393a299f079 upstream
A few drivers use dev_uc_sync/unsync to synchronize the
address lists from master down to slave/lower devices. In
some cases (bond/team) a single address list is synched down
to multiple devices. At the time of unsync, we have a leak
in these lower devices, because "synced" is treated as a
boolean and the address will not be unsynced for anything after
the first device/call.
Treat "synced" as a count (same as refcount) and allow all
unsync calls to work.
Signed-off-by: Vlad Yasevich
Signed-off-by: David S. Miller
Signed-off-by: Jonghwan Choi
---
include/linux/netdevice.h |2 +-
net/core/dev_addr_lists.c |6 +++---
2 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/include/linux/netdevice.h b/include/linux/netdevice.h
index 9ef07d0..0e182f9 100644
--- a/include/linux/netdevice.h
+++ b/include/linux/netdevice.h
@@ -208,9 +208,9 @@ struct netdev_hw_addr {
#define NETDEV_HW_ADDR_T_SLAVE 3
#define NETDEV_HW_ADDR_T_UNICAST 4
#define NETDEV_HW_ADDR_T_MULTICAST 5
- boolsynced;
boolglobal_use;
int refcount;
+ int synced;
struct rcu_head rcu_head;
};
diff --git a/net/core/dev_addr_lists.c b/net/core/dev_addr_lists.c
index b079c7b..7841d87 100644
--- a/net/core/dev_addr_lists.c
+++ b/net/core/dev_addr_lists.c
@@ -38,7 +38,7 @@ static int __hw_addr_create_ex(struct netdev_hw_addr_list
*list,
ha->type = addr_type;
ha->refcount = 1;
ha->global_use = global;
- ha->synced = false;
+ ha->synced = 0;
list_add_tail_rcu(&ha->list, &list->list);
list->count++;
@@ -166,7 +166,7 @@ int __hw_addr_sync(struct netdev_hw_addr_list *to_list,
addr_len, ha->type);
if (err)
break;
- ha->synced = true;
+ ha->synced++;
ha->refcount++;
} else if (ha->refcount == 1) {
__hw_addr_del(to_list, ha->addr, addr_len,
ha->type);
@@ -187,7 +187,7 @@ void __hw_addr_unsync(struct netdev_hw_addr_list
*to_list,
if (ha->synced) {
__hw_addr_del(to_list, ha->addr,
addr_len, ha->type);
- ha->synced = false;
+ ha->synced--;
__hw_addr_del(from_list, ha->addr,
addr_len, ha->type);
}
--
1.7.9.5
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 3.8-stable] GFS2: return error if malloc failed in gfs2_rs_alloc()
This patch looks like it should be in the 3.8-stable tree, should we apply it? -- From: "Wei Yongjun " commit 441362d06be349430d06e37286adce4b90e6ce96 upstream The error code in gfs2_rs_alloc() is set to ENOMEM when error but never be used, instead, gfs2_rs_alloc() always return 0. Fix to return 'error'. Signed-off-by: Wei Yongjun Signed-off-by: Steven Whitehouse Signed-off-by: Jonghwan Choi --- fs/gfs2/rgrp.c |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/fs/gfs2/rgrp.c b/fs/gfs2/rgrp.c index b7eff07..9afba3d6 100644 --- a/fs/gfs2/rgrp.c +++ b/fs/gfs2/rgrp.c @@ -576,7 +576,7 @@ int gfs2_rs_alloc(struct gfs2_inode *ip) RB_CLEAR_NODE(&ip->i_res->rs_node); out: up_write(&ip->i_rw_mutex); - return 0; + return error; } static void dump_rs(struct seq_file *seq, const struct gfs2_blkreserv *rs) -- 1.7.9.5 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 3.8-stable] GFS2: Fix unlock of fcntl locks during withdrawn state
This patch looks like it should be in the 3.8-stable tree, should we apply
it?
--
From: "Steven Whitehouse "
commit c2952d202f710d326ac36a8ea6bd216b20615ec8 upstream
When withdraw occurs, we need to continue to allow unlocks of fcntl
locks to occur, however these will only be local, since the node has
withdrawn from the cluster. This prevents triggering a VFS level
bug trap due to locks remaining when a file is closed.
Signed-off-by: Steven Whitehouse
Signed-off-by: Jonghwan Choi
---
fs/gfs2/file.c |5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/fs/gfs2/file.c b/fs/gfs2/file.c
index 991ab2d..7af426b 100644
--- a/fs/gfs2/file.c
+++ b/fs/gfs2/file.c
@@ -924,8 +924,11 @@ static int gfs2_lock(struct file *file, int cmd, struct
file_lock *fl)
cmd = F_SETLK;
fl->fl_type = F_UNLCK;
}
- if (unlikely(test_bit(SDF_SHUTDOWN, &sdp->sd_flags)))
+ if (unlikely(test_bit(SDF_SHUTDOWN, &sdp->sd_flags))) {
+ if (fl->fl_type == F_UNLCK)
+ posix_lock_file_wait(file, fl);
return -EIO;
+ }
if (IS_GETLK(cmd))
return dlm_posix_get(ls->ls_dlm, ip->i_no_addr, file, fl);
else if (fl->fl_type == F_UNLCK)
--
1.7.9.5
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH] KVM: ARM: Fix wrong address in comment
hyp_hvc vector offset should be 0x14 and hyp_svc vector offset should be 0x8. Signed-off-by: Jonghwan Choi --- arch/arm/kvm/interrupts.S |4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/arch/arm/kvm/interrupts.S b/arch/arm/kvm/interrupts.S index 8ca87ab..a8e0c2d 100644 --- a/arch/arm/kvm/interrupts.S +++ b/arch/arm/kvm/interrupts.S @@ -235,9 +235,9 @@ ENTRY(kvm_call_hyp) * instruction is issued since all traps are disabled when running the host * kernel as per the Hyp-mode initialization at boot time. * - * HVC instructions cause a trap to the vector page + offset 0x18 (see hyp_hvc + * HVC instructions cause a trap to the vector page + offset 0x14 (see hyp_hvc * below) when the HVC instruction is called from SVC mode (i.e. a guest or the - * host kernel) and they cause a trap to the vector page + offset 0xc when HVC + * host kernel) and they cause a trap to the vector page + offset 0x8 when HVC * instructions are called from within Hyp-mode. * * Hyp-ABI: Calling HYP-mode functions from host (in SVC mode): -- 1.7.9.5 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 3.8-stable] mnt: release locks on error path in do_loopback
From: Andrey Vagin
This patch looks like it should be in the 3.8-stable tree, should we apply
it?
--
From: "Andrey Vagin "
commit e9c5d8a562f01b211926d70443378eb14b29a676 upstream
do_loopback calls lock_mount(path) and forget to unlock_mount
if clone_mnt or copy_mnt fails.
[ 77.661566]
[ 77.662939] [ BUG: lock held when returning to user space! ]
[ 77.664104] 3.9.0-rc5+ #17 Not tainted
[ 77.664982]
[ 77.666488] mount/514 is leaving the kernel with locks still held!
[ 77.668027] 2 locks held by mount/514:
[ 77.668817] #0: (&sb->s_type->i_mutex_key#7){+.+.+.}, at:
[] lock_mount+0x32/0xe0
[ 77.671755] #1: (&namespace_sem){+.}, at: []
lock_mount+0x4a/0xe0
Signed-off-by: Andrey Vagin
Signed-off-by: Al Viro
Signed-off-by: Jonghwan Choi
---
fs/namespace.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/fs/namespace.c b/fs/namespace.c
index 5dd7709..4abc8c0 100644
--- a/fs/namespace.c
+++ b/fs/namespace.c
@@ -1713,7 +1713,7 @@ static int do_loopback(struct path *path, const char
*old_name,
if (IS_ERR(mnt)) {
err = PTR_ERR(mnt);
- goto out;
+ goto out2;
}
err = graft_tree(mnt, path);
--
1.7.10.4
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 3.8-stable] gpio: fix wrong checking condition for gpio range
From: Haojian Zhuang
This patch looks like it should be in the 3.8-stable tree, should we apply
it?
--
From: "Haojian Zhuang "
commit ad4e1a7caf937ad395ced585ca85a7d14395dc80 upstream
If index++ calculates from 0, the checking condition of "while
(index++)" fails & it doesn't check any more. It doesn't follow
the loop that used at here.
Replace it by endless loop at here. Then it keeps parsing
"gpio-ranges" property until it ends.
Signed-off-by: Haojian Zhuang
Reviewed-by: Linus Walleij
Signed-off-by: Linus Walleij
Signed-off-by: Jonghwan Choi
---
drivers/gpio/gpiolib-of.c |5 ++---
1 file changed, 2 insertions(+), 3 deletions(-)
diff --git a/drivers/gpio/gpiolib-of.c b/drivers/gpio/gpiolib-of.c
index d542a14..ea537fa 100644
--- a/drivers/gpio/gpiolib-of.c
+++ b/drivers/gpio/gpiolib-of.c
@@ -228,7 +228,7 @@ static void of_gpiochip_add_pin_range(struct gpio_chip
*chip)
if (!np)
return;
- do {
+ for (;; index++) {
ret = of_parse_phandle_with_args(np, "gpio-ranges",
"#gpio-range-cells", index, &pinspec);
if (ret)
@@ -257,8 +257,7 @@ static void of_gpiochip_add_pin_range(struct gpio_chip
*chip)
if (ret)
break;
-
- } while (index++);
+ }
}
#else
--
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 3.8-stable] gpio: fix wrong checking condition for gpio range
Dear Haojian Ahuang. > > This patch looks like it should be in the 3.8-stable tree, should we > apply > > it? > > > > It could be merged into 3.8-stable tree. > Thanks~ Best Regards. > -Original Message- > From: Haojian Zhuang [mailto:haojian.zhu...@linaro.org] > Sent: Sunday, April 14, 2013 12:27 AM > To: Jonghwan Choi > Cc: Linus Walleij; sta...@vger.kernel.org; linux-kernel@vger.kernel.org; > Jonghwan Choi > Subject: Re: [PATCH 3.8-stable] gpio: fix wrong checking condition for > gpio range > > On 13 April 2013 22:46, Jonghwan Choi wrote: > > From: Haojian Zhuang > > > > This patch looks like it should be in the 3.8-stable tree, should we > apply > > it? > > > > It could be merged into 3.8-stable tree. > > Regards > Haojian -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 3.8-stable] sched/debug: Fix sd->*_idx limit range avoiding overflow
From: libin
This patch looks like it should be in the 3.8-stable tree, should we apply
it?
--
From: "libin "
commit fd9b86d37a600488dbd80fe60cca46b822bff1cd upstream
Commit 201c373e8e ("sched/debug: Limit sd->*_idx range on
sysctl") was an incomplete bug fix.
This patch fixes sd->*_idx limit range to [0 ~ CPU_LOAD_IDX_MAX-1]
avoiding array overflow caused by setting sd->*_idx to CPU_LOAD_IDX_MAX
on sysctl.
Signed-off-by: Libin
Cc:
Cc:
Cc: Peter Zijlstra
Link: http://lkml.kernel.org/r/51626610.2040...@huawei.com
Signed-off-by: Ingo Molnar
Signed-off-by: Jonghwan Choi
---
kernel/sched/core.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/kernel/sched/core.c b/kernel/sched/core.c
index 26058d0..112a32a 100644
--- a/kernel/sched/core.c
+++ b/kernel/sched/core.c
@@ -4948,7 +4948,7 @@ static void sd_free_ctl_entry(struct ctl_table **tablep)
}
static int min_load_idx = 0;
-static int max_load_idx = CPU_LOAD_IDX_MAX;
+static int max_load_idx = CPU_LOAD_IDX_MAX-1;
static void
set_table_entry(struct ctl_table *entry,
--
1.7.10.4
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 3.9-stable] ntb: off by one sanity checks
From: Dan Carpenter
This patch looks like it should be in the 3.9-stable tree, should we apply
it?
--
From: "Dan Carpenter "
commit ad3e2751e7c546ae678be1f8d86e898506b42cef upstream
These tests are off by one. If "mw" is equal to NTB_NUM_MW then we
would go beyond the end of the ndev->mw[] array.
Signed-off-by: Dan Carpenter
Signed-off-by: Jon Mason
Signed-off-by: Jonghwan Choi
---
drivers/ntb/ntb_hw.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/ntb/ntb_hw.c b/drivers/ntb/ntb_hw.c
index f802e7c..195cc51 100644
--- a/drivers/ntb/ntb_hw.c
+++ b/drivers/ntb/ntb_hw.c
@@ -345,7 +345,7 @@ int ntb_read_remote_spad(struct ntb_device *ndev, unsigned
int idx, u32 *val)
*/
void __iomem *ntb_get_mw_vbase(struct ntb_device *ndev, unsigned int mw)
{
- if (mw > NTB_NUM_MW)
+ if (mw >= NTB_NUM_MW)
return NULL;
return ndev->mw[mw].vbase;
@@ -362,7 +362,7 @@ void __iomem *ntb_get_mw_vbase(struct ntb_device *ndev,
unsigned int mw)
*/
resource_size_t ntb_get_mw_size(struct ntb_device *ndev, unsigned int mw)
{
- if (mw > NTB_NUM_MW)
+ if (mw >= NTB_NUM_MW)
return 0;
return ndev->mw[mw].bar_sz;
@@ -380,7 +380,7 @@ resource_size_t ntb_get_mw_size(struct ntb_device *ndev,
unsigned int mw)
*/
void ntb_set_mw_addr(struct ntb_device *ndev, unsigned int mw, u64 addr)
{
- if (mw > NTB_NUM_MW)
+ if (mw >= NTB_NUM_MW)
return;
dev_dbg(&ndev->pdev->dev, "Writing addr %Lx to BAR %d\n", addr,
--
1.8.1.2
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 3.9-table] NTB: fix pointer math issues
From: Dan Carpenter This patch looks like it should be in the 3.9-stable tree, should we apply it? -- From: "Dan Carpenter " commit cc0f868d8adef7bdc12cda132654870086d766bc upstream ->remote_rx_info and ->rx_info are struct ntb_rx_info pointers. If we add sizeof(struct ntb_rx_info) then it goes too far. Cc: # 3.9.x: ad3e2751: ntb: off by one Signed-off-by: Dan Carpenter Signed-off-by: Jon Mason Signed-off-by: Jonghwan Choi --- drivers/ntb/ntb_transport.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/ntb/ntb_transport.c b/drivers/ntb/ntb_transport.c index e0bdfd7..676ee16 100644 --- a/drivers/ntb/ntb_transport.c +++ b/drivers/ntb/ntb_transport.c @@ -486,7 +486,7 @@ static void ntb_transport_setup_qp_mw(struct ntb_transport *nt, (qp_num / NTB_NUM_MW * rx_size); rx_size -= sizeof(struct ntb_rx_info); - qp->rx_buff = qp->remote_rx_info + sizeof(struct ntb_rx_info); + qp->rx_buff = qp->remote_rx_info + 1; qp->rx_max_frame = min(transport_mtu, rx_size); qp->rx_max_entry = rx_size / qp->rx_max_frame; qp->rx_index = 0; @@ -780,7 +780,7 @@ static void ntb_transport_init_queue(struct ntb_transport *nt, (qp_num / NTB_NUM_MW * tx_size); tx_size -= sizeof(struct ntb_rx_info); - qp->tx_mw = qp->rx_info + sizeof(struct ntb_rx_info); + qp->tx_mw = qp->rx_info + 1; qp->tx_max_frame = min(transport_mtu, tx_size); qp->tx_max_entry = tx_size / qp->tx_max_frame; qp->tx_index = 0; -- 1.8.1.2 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 3.9-table] NTB: Handle 64bit BAR sizes
From: Jon Mason
This patch looks like it should be in the 3.9-stable tree, should we apply
it?
--
From: "Jon Mason "
commit 113fc505b83b2d16e820ca74fa07f99a34877b1d upstream
64bit BAR sizes are permissible with an NTB device. To support them
various modifications and clean-ups were required, most significantly
using 2 32bit scratch pad registers for each BAR.
Also, modify the driver to allow more than 2 Memory Windows.
Cc: # 3.9.x: ad3e2751: ntb: off by one
Cc: # 3.9.x: cc0f868d: NTB: fix pointer math
Signed-off-by: Jon Mason
Signed-off-by: Jonghwan Choi
---
drivers/ntb/ntb_hw.c| 4 +-
drivers/ntb/ntb_transport.c | 121 ++--
2 files changed, 75 insertions(+), 50 deletions(-)
diff --git a/drivers/ntb/ntb_hw.c b/drivers/ntb/ntb_hw.c
index 195cc51..2dacd19 100644
--- a/drivers/ntb/ntb_hw.c
+++ b/drivers/ntb/ntb_hw.c
@@ -1027,8 +1027,8 @@ static int ntb_pci_probe(struct pci_dev *pdev, const
struct pci_device_id *id)
ndev->mw[i].vbase =
ioremap_wc(pci_resource_start(pdev, MW_TO_BAR(i)),
ndev->mw[i].bar_sz);
- dev_info(&pdev->dev, "MW %d size %d\n", i,
-(u32) pci_resource_len(pdev, MW_TO_BAR(i)));
+ dev_info(&pdev->dev, "MW %d size %llu\n", i,
+pci_resource_len(pdev, MW_TO_BAR(i)));
if (!ndev->mw[i].vbase) {
dev_warn(&pdev->dev, "Cannot remap BAR %d\n",
MW_TO_BAR(i));
diff --git a/drivers/ntb/ntb_transport.c b/drivers/ntb/ntb_transport.c
index 676ee16..2258649 100644
--- a/drivers/ntb/ntb_transport.c
+++ b/drivers/ntb/ntb_transport.c
@@ -58,7 +58,7 @@
#include
#include "ntb_hw.h"
-#define NTB_TRANSPORT_VERSION 2
+#define NTB_TRANSPORT_VERSION 3
static unsigned int transport_mtu = 0x401E;
module_param(transport_mtu, uint, 0644);
@@ -173,10 +173,13 @@ struct ntb_payload_header {
enum {
VERSION = 0,
- MW0_SZ,
- MW1_SZ,
- NUM_QPS,
QP_LINKS,
+ NUM_QPS,
+ NUM_MWS,
+ MW0_SZ_HIGH,
+ MW0_SZ_LOW,
+ MW1_SZ_HIGH,
+ MW1_SZ_LOW,
MAX_SPAD,
};
@@ -526,6 +529,18 @@ static int ntb_set_mw(struct ntb_transport *nt, int
num_mw, unsigned int size)
return 0;
}
+static void ntb_free_mw(struct ntb_transport *nt, int num_mw)
+{
+ struct ntb_transport_mw *mw = &nt->mw[num_mw];
+ struct pci_dev *pdev = ntb_query_pdev(nt->ndev);
+
+ if (!mw->virt_addr)
+ return;
+
+ dma_free_coherent(&pdev->dev, mw->size, mw->virt_addr, mw->dma_addr);
+ mw->virt_addr = NULL;
+}
+
static void ntb_qp_link_cleanup(struct work_struct *work)
{
struct ntb_transport_qp *qp = container_of(work,
@@ -604,25 +619,31 @@ static void ntb_transport_link_work(struct work_struct
*work)
u32 val;
int rc, i;
- /* send the local info */
- rc = ntb_write_remote_spad(ndev, VERSION, NTB_TRANSPORT_VERSION);
- if (rc) {
- dev_err(&pdev->dev, "Error writing %x to remote spad %d\n",
- 0, VERSION);
- goto out;
- }
+ /* send the local info, in the opposite order of the way we read it */
+ for (i = 0; i < NTB_NUM_MW; i++) {
+ rc = ntb_write_remote_spad(ndev, MW0_SZ_HIGH + (i * 2),
+ ntb_get_mw_size(ndev, i) >> 32);
+ if (rc) {
+ dev_err(&pdev->dev, "Error writing %u to remote spad
%d\n",
+ (u32)(ntb_get_mw_size(ndev, i) >> 32),
+ MW0_SZ_HIGH + (i * 2));
+ goto out;
+ }
- rc = ntb_write_remote_spad(ndev, MW0_SZ, ntb_get_mw_size(ndev, 0));
- if (rc) {
- dev_err(&pdev->dev, "Error writing %x to remote spad %d\n",
- (u32) ntb_get_mw_size(ndev, 0), MW0_SZ);
- goto out;
+ rc = ntb_write_remote_spad(ndev, MW0_SZ_LOW + (i * 2),
+ (u32) ntb_get_mw_size(ndev, i));
+ if (rc) {
+ dev_err(&pdev->dev, "Error writing %u to remote spad
%d\n",
+ (u32) ntb_get_mw_size(ndev, i),
+ MW0_SZ_LOW + (i * 2));
+ goto out;
+ }
}
- rc = ntb_write_remote_spad(ndev, MW1_SZ, ntb_get_mw_size(ndev, 1));
+ rc = ntb_write_remote_spad(ndev, NUM_MWS, NTB_NUM_MW);
if (rc) {
dev_err(&pdev->dev, "Error writing %x to remote spad %d\n",
- (u32) ntb_get_mw_size(
[PATCH 3.9-table] NTB: Link toggle memory leak
From: Jon Mason
This patch looks like it should be in the 3.9-stable tree, should we apply
it?
--
From: "Jon Mason "
commit b77b2637b39ecc380bb08992380d7d48452b0872 upstream
Each link-up will allocate a new NTB receive buffer when the NTB
properties are negotiated with the remote system. These allocations did
not check for existing buffers and thus did not free them. Now, the
driver will check for an existing buffer and free it if not of the
correct size, before trying to alloc a new one.
Cc: # 3.9.x: ad3e2751: ntb: off by one
Cc: # 3.9.x: cc0f868d: NTB: fix pointer math
Cc: # 3.9.x: 113fc505: NTB: Handle 64bit BAR
Signed-off-by: Jon Mason
Signed-off-by: Jonghwan Choi
---
drivers/ntb/ntb_transport.c | 32
1 file changed, 20 insertions(+), 12 deletions(-)
diff --git a/drivers/ntb/ntb_transport.c b/drivers/ntb/ntb_transport.c
index 2258649..f5a424d 100644
--- a/drivers/ntb/ntb_transport.c
+++ b/drivers/ntb/ntb_transport.c
@@ -507,17 +507,37 @@ static void ntb_transport_setup_qp_mw(struct
ntb_transport *nt,
qp->tx_pkts = 0;
}
+static void ntb_free_mw(struct ntb_transport *nt, int num_mw)
+{
+ struct ntb_transport_mw *mw = &nt->mw[num_mw];
+ struct pci_dev *pdev = ntb_query_pdev(nt->ndev);
+
+ if (!mw->virt_addr)
+ return;
+
+ dma_free_coherent(&pdev->dev, mw->size, mw->virt_addr, mw->dma_addr);
+ mw->virt_addr = NULL;
+}
+
static int ntb_set_mw(struct ntb_transport *nt, int num_mw, unsigned int size)
{
struct ntb_transport_mw *mw = &nt->mw[num_mw];
struct pci_dev *pdev = ntb_query_pdev(nt->ndev);
+ /* No need to re-setup */
+ if (mw->size == ALIGN(size, 4096))
+ return 0;
+
+ if (mw->size != 0)
+ ntb_free_mw(nt, num_mw);
+
/* Alloc memory for receiving data. Must be 4k aligned */
mw->size = ALIGN(size, 4096);
mw->virt_addr = dma_alloc_coherent(&pdev->dev, mw->size, &mw->dma_addr,
GFP_KERNEL);
if (!mw->virt_addr) {
+ mw->size = 0;
dev_err(&pdev->dev, "Unable to allocate MW buffer of size %d\n",
(int) mw->size);
return -ENOMEM;
@@ -529,18 +549,6 @@ static int ntb_set_mw(struct ntb_transport *nt, int
num_mw, unsigned int size)
return 0;
}
-static void ntb_free_mw(struct ntb_transport *nt, int num_mw)
-{
- struct ntb_transport_mw *mw = &nt->mw[num_mw];
- struct pci_dev *pdev = ntb_query_pdev(nt->ndev);
-
- if (!mw->virt_addr)
- return;
-
- dma_free_coherent(&pdev->dev, mw->size, mw->virt_addr, mw->dma_addr);
- mw->virt_addr = NULL;
-}
-
static void ntb_qp_link_cleanup(struct work_struct *work)
{
struct ntb_transport_qp *qp = container_of(work,
--
1.8.1.2
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 3.9-stable] NTB: reset tx_index on link toggle
From: Jon Mason
This patch looks like it should be in the 3.9-stable tree, should we apply
it?
--
From: "Jon Mason "
commit 90f9e934647e652a69396e18c779215a493271cf upstream
If the NTB link toggles, the driver could stop receiving due to the
tx_index not being set to 0 on the transmitting size on a link-up event.
This is due to the driver expecting the incoming data to start at the
beginning of the receive buffer and not at a random place.
Cc: # 3.9.x: ad3e2751: ntb: off by one
Cc: # 3.9.x: cc0f868d: NTB: fix pointer math
Cc: # 3.9.x: 113fc505: NTB: Handle 64bit BAR
Cc: # 3.9.x: b77b2637: NTB: Link toggle memory
Signed-off-by: Jon Mason
Signed-off-by: Jonghwan Choi
---
drivers/ntb/ntb_transport.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/ntb/ntb_transport.c b/drivers/ntb/ntb_transport.c
index f5a424d..0828124 100644
--- a/drivers/ntb/ntb_transport.c
+++ b/drivers/ntb/ntb_transport.c
@@ -505,6 +505,7 @@ static void ntb_transport_setup_qp_mw(struct ntb_transport
*nt,
qp->rx_pkts = 0;
qp->tx_pkts = 0;
+ qp->tx_index = 0;
}
static void ntb_free_mw(struct ntb_transport *nt, int num_mw)
@@ -819,7 +820,6 @@ static void ntb_transport_init_queue(struct ntb_transport
*nt,
qp->tx_mw = qp->rx_info + 1;
qp->tx_max_frame = min(transport_mtu, tx_size);
qp->tx_max_entry = tx_size / qp->tx_max_frame;
- qp->tx_index = 0;
if (nt->debugfs_dir) {
char debugfs_name[4];
--
1.8.1.2
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 3.9-table] NTB: Correctly handle receive buffers of the minimal size
From: Jon Mason
This patch looks like it should be in the 3.9-stable tree, should we apply
it?
--
From: "Jon Mason "
commit c9d534c8cbaedbb522a1d2cb037c6c394f610317 upstream
The ring logic of the NTB receive buffer/transmit memory window requires
there to be at least 2 payload sized allotments. For the minimal size
case, split the buffer into two and set the transport_mtu to the
appropriate size.
Cc: # 3.9.x: ad3e2751: ntb: off by one
Cc: # 3.9.x: cc0f868d: NTB: fix pointer math
Cc: # 3.9.x: 113fc505: NTB: Handle 64bit BAR
Cc: # 3.9.x: b77b2637: NTB: Link toggle memory
Cc: # 3.9.x: 90f9e934: NTB: reset tx_index on
Signed-off-by: Jon Mason
Signed-off-by: Jonghwan Choi
---
drivers/ntb/ntb_transport.c | 8 +---
1 file changed, 5 insertions(+), 3 deletions(-)
diff --git a/drivers/ntb/ntb_transport.c b/drivers/ntb/ntb_transport.c
index 0828124..a288a26 100644
--- a/drivers/ntb/ntb_transport.c
+++ b/drivers/ntb/ntb_transport.c
@@ -490,11 +490,12 @@ static void ntb_transport_setup_qp_mw(struct
ntb_transport *nt,
rx_size -= sizeof(struct ntb_rx_info);
qp->rx_buff = qp->remote_rx_info + 1;
- qp->rx_max_frame = min(transport_mtu, rx_size);
+ /* Due to housekeeping, there must be atleast 2 buffs */
+ qp->rx_max_frame = min(transport_mtu, rx_size / 2);
qp->rx_max_entry = rx_size / qp->rx_max_frame;
qp->rx_index = 0;
- qp->remote_rx_info->entry = qp->rx_max_entry;
+ qp->remote_rx_info->entry = qp->rx_max_entry - 1;
/* setup the hdr offsets with 0's */
for (i = 0; i < qp->rx_max_entry; i++) {
@@ -818,7 +819,8 @@ static void ntb_transport_init_queue(struct ntb_transport
*nt,
tx_size -= sizeof(struct ntb_rx_info);
qp->tx_mw = qp->rx_info + 1;
- qp->tx_max_frame = min(transport_mtu, tx_size);
+ /* Due to housekeeping, there must be atleast 2 buffs */
+ qp->tx_max_frame = min(transport_mtu, tx_size / 2);
qp->tx_max_entry = tx_size / qp->tx_max_frame;
if (nt->debugfs_dir) {
--
1.8.1.2
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 3.9-stable] NTB: memcpy lockup workaround
From: Jon Mason
This patch looks like it should be in the 3.9-stable tree, should we apply
it?
--
From: "Jon Mason "
commit c336acd3331dcc191a97dbc66a557d47741657c7 upstream
The system will appear to lockup for long periods of time due to the NTB
driver spending too much time in memcpy. Avoid this by reducing the
number of packets that can be serviced on a given interrupt.
Cc: # 3.9.x: ad3e2751: ntb: off by one
Cc: # 3.9.x: cc0f868d: NTB: fix pointer math
Cc: # 3.9.x: 113fc505: NTB: Handle 64bit BAR
Cc: # 3.9.x: b77b2637: NTB: Link toggle memory
Cc: # 3.9.x: 90f9e934: NTB: reset tx_index on
Cc: # 3.9.x: c9d534c8: NTB: Correctly handle receive
Signed-off-by: Jon Mason
Signed-off-by: Jonghwan Choi
---
drivers/ntb/ntb_transport.c | 11 ---
1 file changed, 8 insertions(+), 3 deletions(-)
diff --git a/drivers/ntb/ntb_transport.c b/drivers/ntb/ntb_transport.c
index a288a26..0f66daa 100644
--- a/drivers/ntb/ntb_transport.c
+++ b/drivers/ntb/ntb_transport.c
@@ -1034,11 +1034,16 @@ out:
static void ntb_transport_rx(unsigned long data)
{
struct ntb_transport_qp *qp = (struct ntb_transport_qp *)data;
- int rc;
+ int rc, i;
- do {
+ /* Limit the number of packets processed in a single interrupt to
+* provide fairness to others
+*/
+ for (i = 0; i < qp->rx_max_entry; i++) {
rc = ntb_process_rxc(qp);
- } while (!rc);
+ if (rc)
+ break;
+ }
}
static void ntb_transport_rxc_db(void *data, int db_num)
--
1.8.1.2
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 3.9-stable] ntb_netdev: remove from list on exit
From: Jon Mason This patch looks like it should be in the 3.9-stable tree, should we apply it? -- From: "Jon Mason " commit 904435cf76a9bdd5eb41b1c4e049d5a64f3a8400 upstream The ntb_netdev device is not removed from the global list of devices upon device removal. If the device is re-added, the removal code would find the first instance and try to remove an already removed device. Cc: # 3.9.x: ad3e2751: ntb: off by one Cc: # 3.9.x: cc0f868d: NTB: fix pointer math Cc: # 3.9.x: 113fc505: NTB: Handle 64bit BAR Cc: # 3.9.x: b77b2637: NTB: Link toggle memory Cc: # 3.9.x: 90f9e934: NTB: reset tx_index on Cc: # 3.9.x: c9d534c8: NTB: Correctly handle receive Cc: # 3.9.x: c336acd3: NTB: memcpy lockup workaround Signed-off-by: Jon Mason Signed-off-by: Jonghwan Choi --- drivers/net/ntb_netdev.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/drivers/net/ntb_netdev.c b/drivers/net/ntb_netdev.c index ed947dd..f3cdf64 100644 --- a/drivers/net/ntb_netdev.c +++ b/drivers/net/ntb_netdev.c @@ -375,6 +375,8 @@ static void ntb_netdev_remove(struct pci_dev *pdev) if (dev == NULL) return; + list_del(&dev->list); + ndev = dev->ndev; unregister_netdev(ndev); -- 1.8.1.2 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 3.9-stable] NTB: Multiple NTB client fix
From: Jon Mason
This patch looks like it should be in the 3.9-stable tree, should we apply
it?
--
From: "Jon Mason "
commit 8b19d450ad188d402a183ff4a4d40f31c3916fbf upstream
Fix issue with adding multiple ntb client devices to the ntb virtual
bus. Previously, multiple devices would be added with the same name,
resulting in crashes. To get around this issue, add a unique number to
the device when it is added.
Cc: # 3.9.x: ad3e2751: ntb: off by one
Cc: # 3.9.x: cc0f868d: NTB: fix pointer math
Cc: # 3.9.x: 113fc505: NTB: Handle 64bit BAR
Cc: # 3.9.x: b77b2637: NTB: Link toggle memory
Cc: # 3.9.x: 90f9e934: NTB: reset tx_index on
Cc: # 3.9.x: c9d534c8: NTB: Correctly handle receive
Cc: # 3.9.x: c336acd3: NTB: memcpy lockup workaround
Cc: # 3.9.x: 904435cf: ntb_netdev: remove from list
Signed-off-by: Jon Mason
Signed-off-by: Jonghwan Choi
---
drivers/ntb/ntb_transport.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/drivers/ntb/ntb_transport.c b/drivers/ntb/ntb_transport.c
index 0f66daa..f365b2f 100644
--- a/drivers/ntb/ntb_transport.c
+++ b/drivers/ntb/ntb_transport.c
@@ -300,7 +300,7 @@ int ntb_register_client_dev(char *device_name)
{
struct ntb_transport_client_dev *client_dev;
struct ntb_transport *nt;
- int rc;
+ int rc, i = 0;
if (list_empty(&ntb_transport_list))
return -ENODEV;
@@ -318,7 +318,7 @@ int ntb_register_client_dev(char *device_name)
dev = &client_dev->dev;
/* setup and register client devices */
- dev_set_name(dev, "%s", device_name);
+ dev_set_name(dev, "%s%d", device_name, i);
dev->bus = &ntb_bus_type;
dev->release = ntb_client_release;
dev->parent = &ntb_query_pdev(nt->ndev)->dev;
@@ -330,6 +330,7 @@ int ntb_register_client_dev(char *device_name)
}
list_add_tail(&client_dev->entry, &nt->client_devs);
+ i++;
}
return 0;
--
1.8.1.2
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 3.9-table] NTB: fix pointer math issues
Thanks for your advice. Best Regards. On Sat, May 18, 2013 at 3:00 AM, Dan Carpenter wrote: > On Sat, May 18, 2013 at 11:39:05AM +0900, Jonghwan Choi wrote: >> From: Dan Carpenter >> >> This patch looks like it should be in the 3.9-stable tree, should we apply >> it? >> > > Normally these questions are handled by the subsystem maintainer. > > regards, > dan carpenter -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 3.9-stable] NTB: variable dereferenced before check
This patch looks like it should be in the 3.9-stable tree, should we apply
it?
--
From: "Jon Mason "
commit 186f27ff9f9ec5c110739ced88ce9f8fca053882 upstream
Correct instances of variable dereferencing before checking its value on
the functions exported to the client drivers. Also, add sanity checks
for all exported functions.
Reported-by: Dan Carpenter
Signed-off-by: Jon Mason
Signed-off-by: Jonghwan Choi
---
drivers/ntb/ntb_transport.c | 16 ++--
1 file changed, 14 insertions(+), 2 deletions(-)
diff --git a/drivers/ntb/ntb_transport.c b/drivers/ntb/ntb_transport.c
index e0bdfd7..74c5812 100644
--- a/drivers/ntb/ntb_transport.c
+++ b/drivers/ntb/ntb_transport.c
@@ -1210,12 +1210,14 @@ EXPORT_SYMBOL_GPL(ntb_transport_create_queue);
*/
void ntb_transport_free_queue(struct ntb_transport_qp *qp)
{
- struct pci_dev *pdev = ntb_query_pdev(qp->ndev);
+ struct pci_dev *pdev;
struct ntb_queue_entry *entry;
if (!qp)
return;
+ pdev = ntb_query_pdev(qp->ndev);
+
cancel_delayed_work_sync(&qp->link_work);
ntb_unregister_db_callback(qp->ndev, qp->qp_num);
@@ -1371,12 +1373,13 @@ EXPORT_SYMBOL_GPL(ntb_transport_link_up);
*/
void ntb_transport_link_down(struct ntb_transport_qp *qp)
{
- struct pci_dev *pdev = ntb_query_pdev(qp->ndev);
+ struct pci_dev *pdev;
int rc, val;
if (!qp)
return;
+ pdev = ntb_query_pdev(qp->ndev);
qp->client_ready = NTB_LINK_DOWN;
rc = ntb_read_local_spad(qp->ndev, QP_LINKS, &val);
@@ -1408,6 +1411,9 @@ EXPORT_SYMBOL_GPL(ntb_transport_link_down);
*/
bool ntb_transport_link_query(struct ntb_transport_qp *qp)
{
+ if (!qp)
+ return false;
+
return qp->qp_link == NTB_LINK_UP;
}
EXPORT_SYMBOL_GPL(ntb_transport_link_query);
@@ -1422,6 +1428,9 @@ EXPORT_SYMBOL_GPL(ntb_transport_link_query);
*/
unsigned char ntb_transport_qp_num(struct ntb_transport_qp *qp)
{
+ if (!qp)
+ return 0;
+
return qp->qp_num;
}
EXPORT_SYMBOL_GPL(ntb_transport_qp_num);
@@ -1436,6 +1445,9 @@ EXPORT_SYMBOL_GPL(ntb_transport_qp_num);
*/
unsigned int ntb_transport_max_size(struct ntb_transport_qp *qp)
{
+ if (!qp)
+ return 0;
+
return qp->tx_max_frame - sizeof(struct ntb_payload_header);
}
EXPORT_SYMBOL_GPL(ntb_transport_max_size);
--
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 3.9-stable] NTB: variable dereferenced before check
Jon Mason agrees that this could also be applied to the 3.9
"Yes, please do. I'll respond to each of the patch series, but please apply
them all. Also, one patch was omitted from these, titled
NTB: variable dereferenced before check
Please include that patch in 3.9 stable as well.
"
Thanks.
Best Regards.
> -Original Message-
> From: stable-ow...@vger.kernel.org [mailto:stable-ow...@vger.kernel.org]
> On Behalf Of Jonghwan Choi
> Sent: Monday, May 20, 2013 10:58 AM
> To: 'Jonghwan Choi'; linux-kernel@vger.kernel.org
> Cc: sta...@vger.kernel.org; 'Jon Mason'; c...@samsung.com
> Subject: [PATCH 3.9-stable] NTB: variable dereferenced before check
>
> This patch looks like it should be in the 3.9-stable tree, should we apply
> it?
>
> --
>
> From: "Jon Mason "
>
> commit 186f27ff9f9ec5c110739ced88ce9f8fca053882 upstream
>
> Correct instances of variable dereferencing before checking its value on
> the functions exported to the client drivers. Also, add sanity checks
> for all exported functions.
>
> Reported-by: Dan Carpenter
> Signed-off-by: Jon Mason
> Signed-off-by: Jonghwan Choi
> ---
> drivers/ntb/ntb_transport.c | 16 ++--
> 1 file changed, 14 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/ntb/ntb_transport.c b/drivers/ntb/ntb_transport.c
> index e0bdfd7..74c5812 100644
> --- a/drivers/ntb/ntb_transport.c
> +++ b/drivers/ntb/ntb_transport.c
> @@ -1210,12 +1210,14 @@ EXPORT_SYMBOL_GPL(ntb_transport_create_queue);
> */
> void ntb_transport_free_queue(struct ntb_transport_qp *qp)
> {
> - struct pci_dev *pdev = ntb_query_pdev(qp->ndev);
> + struct pci_dev *pdev;
> struct ntb_queue_entry *entry;
>
> if (!qp)
> return;
>
> + pdev = ntb_query_pdev(qp->ndev);
> +
> cancel_delayed_work_sync(&qp->link_work);
>
> ntb_unregister_db_callback(qp->ndev, qp->qp_num);
> @@ -1371,12 +1373,13 @@ EXPORT_SYMBOL_GPL(ntb_transport_link_up);
> */
> void ntb_transport_link_down(struct ntb_transport_qp *qp)
> {
> - struct pci_dev *pdev = ntb_query_pdev(qp->ndev);
> + struct pci_dev *pdev;
> int rc, val;
>
> if (!qp)
> return;
>
> + pdev = ntb_query_pdev(qp->ndev);
> qp->client_ready = NTB_LINK_DOWN;
>
> rc = ntb_read_local_spad(qp->ndev, QP_LINKS, &val);
> @@ -1408,6 +1411,9 @@ EXPORT_SYMBOL_GPL(ntb_transport_link_down);
> */
> bool ntb_transport_link_query(struct ntb_transport_qp *qp)
> {
> + if (!qp)
> + return false;
> +
> return qp->qp_link == NTB_LINK_UP;
> }
> EXPORT_SYMBOL_GPL(ntb_transport_link_query);
> @@ -1422,6 +1428,9 @@ EXPORT_SYMBOL_GPL(ntb_transport_link_query);
> */
> unsigned char ntb_transport_qp_num(struct ntb_transport_qp *qp)
> {
> + if (!qp)
> + return 0;
> +
> return qp->qp_num;
> }
> EXPORT_SYMBOL_GPL(ntb_transport_qp_num);
> @@ -1436,6 +1445,9 @@ EXPORT_SYMBOL_GPL(ntb_transport_qp_num);
> */
> unsigned int ntb_transport_max_size(struct ntb_transport_qp *qp)
> {
> + if (!qp)
> + return 0;
> +
> return qp->tx_max_frame - sizeof(struct ntb_payload_header);
> }
> EXPORT_SYMBOL_GPL(ntb_transport_max_size);
> --
> 1.7.9.5
>
> --
> To unsubscribe from this list: send the line "unsubscribe stable" 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/
[PATCH 3.9-stable] leds: leds-gpio: reserve gpio before using it.
This patch looks like it should be in the 3.9-stable tree, should we apply it? -- From: "Timo Teras " commit 803d19d57a042e86e9e9b685bbc3f4a0a751040f upstream This reverts commit a99d76f (leds: leds-gpio: use gpio_request_one) and commit 2d7c22f (leds: leds-gpio: set devm_gpio_request_one() flags param correctly) which was a fix of the first one. The conversion to devm_gpio_request in commit e3b1d44c (leds: leds-gpio: use devm_gpio_request_one) is not reverted. The problem is that gpio_cansleep() and gpio_get_value_cansleep() calls can crash if the gpio is not first reserved. Incidentally this same bug existed earlier and was fixed similarly in commit d95cbe61 (leds: Fix potential leds-gpio oops). But the OOPS is real. It happens when GPIOs are provided by module which is not yet loaded. So this fixes the following BUG during my ALIX boot (3.9.2-vanilla): BUG: unable to handle kernel NULL pointer dereference at 004c IP: [] __gpio_cansleep+0xe/0x1a *pde = Oops: [#1] SMP Modules linked in: leds_gpio(+) via_rhine mii cs5535_mfd mfd_core geode_rng rng_core geode_aes isofs nls_utf8 nls_cp437 vfat fat ata_generic pata_amd pata_cs5536 pata_acpi libata ehci_pci ehci_hcd ohci_hcd usb_storage usbcore usb_common sd_mod scsi_mod squashfs loop Pid: 881, comm: modprobe Not tainted 3.9.2 #1-Alpine EIP: 0060:[] EFLAGS: 00010282 CPU: 0 EIP is at __gpio_cansleep+0xe/0x1a EAX: EBX: cf364018 ECX: c132b8b9 EDX: ESI: c13993a4 EDI: c1399370 EBP: cded9dbc ESP: cded9dbc DS: 007b ES: 007b FS: 00d8 GS: 0033 SS: 0068 CR0: 8005003b CR2: 004c CR3: 0f0c4000 CR4: 0090 DR0: DR1: DR2: DR3: DR6: 0ff0 DR7: 0400 Process modprobe (pid: 881, ti=cded8000 task=cf094aa0 task.ti=cded8000) Stack: cded9de0 d09471cb c1399260 cf364014 c1399260 c1399254 d0949014 cded9df4 c118cd59 c1399260 d0949014 d0949014 cded9e08 c118ba47 c1399260 d0949014 c1399294 cded9e1c c118bb75 cded9e24 d0949014 Call Trace: [] gpio_led_probe+0xba/0x203 [leds_gpio] [] platform_drv_probe+0x26/0x48 [] driver_probe_device+0x75/0x15c [] __driver_attach+0x47/0x63 [] bus_for_each_dev+0x3c/0x66 [] driver_attach+0x14/0x16 [] ? driver_probe_device+0x15c/0x15c [] bus_add_driver+0xbd/0x1bc [] ? 0xd08b3fff [] ? 0xd08b3fff [] driver_register+0x74/0xec [] ? 0xd08b3fff [] platform_driver_register+0x38/0x3a [] gpio_led_driver_init+0xd/0x1000 [leds_gpio] [] do_one_initcall+0x6b/0x10f [] ? 0xd08b3fff [] load_module+0x1631/0x1907 [] ? insert_vmalloc_vmlist+0x14/0x43 [] ? __vmalloc_node_range+0x13e/0x15f [] sys_init_module+0x62/0x77 [] syscall_call+0x7/0xb EIP: [] __gpio_cansleep+0xe/0x1a SS:ESP 0068:cded9dbc CR2: 004c ---[ end trace 5308fb20d2514822 ]--- Signed-off-by: Timo Teras Cc: Sachin Kamat Cc: Raphael Assenat Cc: Trent Piepho Cc: Javier Martinez Canillas Cc: Arnaud Patard Cc: Ezequiel Garcia Acked-by: Jingoo Han Signed-off-by: Bryan Wu Signed-off-by: Jonghwan Choi --- drivers/leds/leds-gpio.c |9 + 1 file changed, 5 insertions(+), 4 deletions(-) diff --git a/drivers/leds/leds-gpio.c b/drivers/leds/leds-gpio.c index a0d931b..b02b679 100644 --- a/drivers/leds/leds-gpio.c +++ b/drivers/leds/leds-gpio.c @@ -107,6 +107,10 @@ static int create_gpio_led(const struct gpio_led *template, return 0; } + ret = devm_gpio_request(parent, template->gpio, template->name); + if (ret < 0) + return ret; + led_dat->cdev.name = template->name; led_dat->cdev.default_trigger = template->default_trigger; led_dat->gpio = template->gpio; @@ -126,10 +130,7 @@ static int create_gpio_led(const struct gpio_led *template, if (!template->retain_state_suspended) led_dat->cdev.flags |= LED_CORE_SUSPENDRESUME; - ret = devm_gpio_request_one(parent, template->gpio, - (led_dat->active_low ^ state) ? - GPIOF_OUT_INIT_HIGH : GPIOF_OUT_INIT_LOW, - template->name); + ret = gpio_direction_output(led_dat->gpio, led_dat->active_low ^ state); if (ret < 0) return ret; -- 1.7.9.5 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 3.9-stable] regulator: mc13892: Fix MC13892_SWITCHERS0_SWxHI bit in set_voltage_sel
This patch looks like it should be in the 3.9-stable tree, should we apply
it?
--
From: "Axel Lin "
commit 78040b630f28298e0ecb56bf1bc53c7976314eab upstream
It is necessary to clear MC13892_SWITCHERS0_SWxHI bit when set voltage to
the
voltage range from 110 to 1375000. Leaving MC13892_SWITCHERS0_SWxHI bit
untouched may result in wrong voltage setting.
For example, currently switch voltage from 140 to 130 will set the
voltage to 180 because the HI bit is still set.
Signed-off-by: Axel Lin
Signed-off-by: Mark Brown
Signed-off-by: Jonghwan Choi
---
drivers/regulator/mc13892-regulator.c |6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/regulator/mc13892-regulator.c
b/drivers/regulator/mc13892-regulator.c
index 9891aec..cc76c52 100644
--- a/drivers/regulator/mc13892-regulator.c
+++ b/drivers/regulator/mc13892-regulator.c
@@ -465,13 +465,13 @@ static int mc13892_sw_regulator_set_voltage_sel(struct
regulator_dev *rdev,
*/
if (mc13892_regulators[id].vsel_reg != MC13892_SWITCHERS0) {
+ mask |= MC13892_SWITCHERS0_SWxHI;
+
if (volt > 1375000) {
reg_value -= MC13892_SWxHI_SEL_OFFSET;
reg_value |= MC13892_SWITCHERS0_SWxHI;
- mask |= MC13892_SWITCHERS0_SWxHI;
- } else if (volt < 110) {
+ } else {
reg_value &= ~MC13892_SWITCHERS0_SWxHI;
- mask |= MC13892_SWITCHERS0_SWxHI;
}
}
--
1.7.9.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 3.9-stable] staging/iio/mxs-lradc: fix preenable for multiple
This patch looks like it should be in the 3.9-stable tree, should we apply
it?
--
From: "Michał Mirosław "
commit c80712c793febdf1b13ad0e1c71a051e071b3fd8 upstream
This fixes 'preenable failed: -EINVAL' error when using this driver.
Signed-off-by: Michał Mirosław "
Signed-off-by: Jonathan Cameron
Signed-off-by: Jonghwan Choi
---
drivers/staging/iio/adc/mxs-lradc.c |5 ++---
1 file changed, 2 insertions(+), 3 deletions(-)
diff --git a/drivers/staging/iio/adc/mxs-lradc.c
b/drivers/staging/iio/adc/mxs-lradc.c
index 55a459b..f5e9e55 100644
--- a/drivers/staging/iio/adc/mxs-lradc.c
+++ b/drivers/staging/iio/adc/mxs-lradc.c
@@ -693,7 +693,6 @@ static void mxs_lradc_trigger_remove(struct iio_dev
*iio)
static int mxs_lradc_buffer_preenable(struct iio_dev *iio)
{
struct mxs_lradc *lradc = iio_priv(iio);
- struct iio_buffer *buffer = iio->buffer;
int ret = 0, chan, ofs = 0;
unsigned long enable = 0;
uint32_t ctrl4_set = 0;
@@ -701,7 +700,7 @@ static int mxs_lradc_buffer_preenable(struct iio_dev
*iio)
uint32_t ctrl1_irq = 0;
const uint32_t chan_value = LRADC_CH_ACCUMULATE |
((LRADC_DELAY_TIMER_LOOP - 1) <<
LRADC_CH_NUM_SAMPLES_OFFSET);
- const int len = bitmap_weight(buffer->scan_mask,
LRADC_MAX_TOTAL_CHANS);
+ const int len = bitmap_weight(iio->active_scan_mask,
LRADC_MAX_TOTAL_CHANS);
if (!len)
return -EINVAL;
@@ -728,7 +727,7 @@ static int mxs_lradc_buffer_preenable(struct iio_dev
*iio)
lradc->base + LRADC_CTRL1 + STMP_OFFSET_REG_CLR);
writel(0xff, lradc->base + LRADC_CTRL0 + STMP_OFFSET_REG_CLR);
- for_each_set_bit(chan, buffer->scan_mask, LRADC_MAX_TOTAL_CHANS) {
+ for_each_set_bit(chan, iio->active_scan_mask, LRADC_MAX_TOTAL_CHANS)
{
ctrl4_set |= chan << LRADC_CTRL4_LRADCSELECT_OFFSET(ofs);
ctrl4_clr |= LRADC_CTRL4_LRADCSELECT_MASK(ofs);
ctrl1_irq |= LRADC_CTRL1_LRADC_IRQ_EN(ofs);
--
1.7.9.5
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 3.9-stable] staging:iio:light:tsl2x7x: fix the error handling in tsl2x7x_probe()
This patch looks like it should be in the 3.9-stable tree, should we apply
it?
--
From: "Wei Yongjun "
commit 3b813798aa7030f1beef638c75f8b0008f737a82 upstream
Fix to return -EINVAL in the i2c device found error handling
case instead of 0, as done elsewhere in this function.
And also correct the fail1 and fail2 lable to do the right thing.
Signed-off-by: Wei Yongjun
Signed-off-by: Jonathan Cameron
Signed-off-by: Jonghwan Choi
---
drivers/staging/iio/light/tsl2x7x_core.c |9 +
1 file changed, 5 insertions(+), 4 deletions(-)
diff --git a/drivers/staging/iio/light/tsl2x7x_core.c
b/drivers/staging/iio/light/tsl2x7x_core.c
index a58731e..2d40c03 100644
--- a/drivers/staging/iio/light/tsl2x7x_core.c
+++ b/drivers/staging/iio/light/tsl2x7x_core.c
@@ -1869,6 +1869,7 @@ static int tsl2x7x_probe(struct i2c_client *clientp,
dev_info(&chip->client->dev,
"%s: i2c device found does not match
expected id\n",
__func__);
+ ret = -EINVAL;
goto fail1;
}
@@ -1907,7 +1908,7 @@ static int tsl2x7x_probe(struct i2c_client *clientp,
if (ret) {
dev_err(&clientp->dev,
"%s: irq request failed", __func__);
- goto fail2;
+ goto fail1;
}
}
@@ -1920,17 +1921,17 @@ static int tsl2x7x_probe(struct i2c_client *clientp,
if (ret) {
dev_err(&clientp->dev,
"%s: iio registration failed\n", __func__);
- goto fail1;
+ goto fail2;
}
dev_info(&clientp->dev, "%s Light sensor found.\n", id->name);
return 0;
-fail1:
+fail2:
if (clientp->irq)
free_irq(clientp->irq, indio_dev);
-fail2:
+fail1:
iio_device_free(indio_dev);
return ret;
--
1.7.9.5
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 3.9-stable] NFSv4.1 Fix a pNFS session draining deadlock
This patch looks like it should be in the 3.9-stable tree, should we apply
it?
--
From: "Andy Adamson "
commit 774d5f14ee1ecac55f42a84ff35eb00b896b00b6 upstream
On a CB_RECALL the callback service thread flushes the inode using
filemap_flush prior to scheduling the state manager thread to return the
delegation. When pNFS is used and I/O has not yet gone to the data server
servicing the inode, a LAYOUTGET can preceed the I/O. Unlike the async
filemap_flush call, the LAYOUTGET must proceed to completion.
If the state manager starts to recover data while the inode flush is sending
the LAYOUTGET, a deadlock occurs as the callback service thread holds the
single callback session slot until the flushing is done which blocks the
state
manager thread, and the state manager thread has set the session draining
bit
which puts the inode flush LAYOUTGET RPC to sleep on the forechannel slot
table waitq.
Separate the draining of the back channel from the draining of the fore
channel
by moving the NFS4_SESSION_DRAINING bit from session scope into the fore
and back slot tables. Drain the back channel first allowing the LAYOUTGET
call to proceed (and fail) so the callback service thread frees the callback
slot. Then proceed with draining the forechannel.
Signed-off-by: Andy Adamson
Signed-off-by: Trond Myklebust
Signed-off-by: Jonghwan Choi
---
fs/nfs/callback_proc.c |2 +-
fs/nfs/callback_xdr.c |2 +-
fs/nfs/nfs4proc.c |2 +-
fs/nfs/nfs4session.c |4 ++--
fs/nfs/nfs4session.h | 13 -
fs/nfs/nfs4state.c | 15 +++
6 files changed, 20 insertions(+), 18 deletions(-)
diff --git a/fs/nfs/callback_proc.c b/fs/nfs/callback_proc.c
index 2960512..339bfa3 100644
--- a/fs/nfs/callback_proc.c
+++ b/fs/nfs/callback_proc.c
@@ -414,7 +414,7 @@ __be32 nfs4_callback_sequence(struct cb_sequenceargs
*args,
spin_lock(&tbl->slot_tbl_lock);
/* state manager is resetting the session */
- if (test_bit(NFS4_SESSION_DRAINING,
&clp->cl_session->session_state)) {
+ if (test_bit(NFS4_SLOT_TBL_DRAINING, &tbl->slot_tbl_state)) {
spin_unlock(&tbl->slot_tbl_lock);
status = htonl(NFS4ERR_DELAY);
/* Return NFS4ERR_BADSESSION if we're draining the session
diff --git a/fs/nfs/callback_xdr.c b/fs/nfs/callback_xdr.c
index 59461c9..a35582c 100644
--- a/fs/nfs/callback_xdr.c
+++ b/fs/nfs/callback_xdr.c
@@ -763,7 +763,7 @@ static void nfs4_callback_free_slot(struct nfs4_session
*session)
* A single slot, so highest used slotid is either 0 or -1
*/
tbl->highest_used_slotid = NFS4_NO_SLOT;
- nfs4_session_drain_complete(session, tbl);
+ nfs4_slot_tbl_drain_complete(tbl);
spin_unlock(&tbl->slot_tbl_lock);
}
diff --git a/fs/nfs/nfs4proc.c b/fs/nfs/nfs4proc.c
index 0086401..beb807c 100644
--- a/fs/nfs/nfs4proc.c
+++ b/fs/nfs/nfs4proc.c
@@ -559,7 +559,7 @@ int nfs41_setup_sequence(struct nfs4_session *session,
task->tk_timeout = 0;
spin_lock(&tbl->slot_tbl_lock);
- if (test_bit(NFS4_SESSION_DRAINING, &session->session_state) &&
+ if (test_bit(NFS4_SLOT_TBL_DRAINING, &tbl->slot_tbl_state) &&
!args->sa_privileged) {
/* The state manager will wait until the slot table is empty
*/
dprintk("%s session is draining\n", __func__);
diff --git a/fs/nfs/nfs4session.c b/fs/nfs/nfs4session.c
index ebda5f4..c4e225e 100644
--- a/fs/nfs/nfs4session.c
+++ b/fs/nfs/nfs4session.c
@@ -73,7 +73,7 @@ void nfs4_free_slot(struct nfs4_slot_table *tbl, struct
nfs4_slot *slot)
tbl->highest_used_slotid = new_max;
else {
tbl->highest_used_slotid = NFS4_NO_SLOT;
- nfs4_session_drain_complete(tbl->session, tbl);
+ nfs4_slot_tbl_drain_complete(tbl);
}
}
dprintk("%s: slotid %u highest_used_slotid %d\n", __func__,
@@ -226,7 +226,7 @@ static bool nfs41_assign_slot(struct rpc_task *task,
void *pslot)
struct nfs4_slot *slot = pslot;
struct nfs4_slot_table *tbl = slot->table;
- if (nfs4_session_draining(tbl->session) && !args->sa_privileged)
+ if (nfs4_slot_tbl_draining(tbl) && !args->sa_privileged)
return false;
slot->generation = tbl->generation;
args->sa_slot = slot;
diff --git a/fs/nfs/nfs4session.h b/fs/nfs/nfs4session.h
index 6f3cb39..ff7d9f0 100644
--- a/fs/nfs/nfs4session.h
+++ b/fs/nfs/nfs4session.h
@@ -25,6 +25,10 @@ struct nfs4_slot {
};
/* Sessions */
+enum nfs4_slot_tbl_state {
+ NFS4_SLOT_TBL_DRAINING,
+};
+
#define SLOT_TABLE_SZ DIV_ROUND_UP(NFS4_MAX_SLOT_TABLE, 8*sizeof(long))
struct nfs4_slot_table {
struct nfs4_
[PATCH 3.9-stable] cpufreq / intel_pstate: Add additional supported CPU ID
This patch looks like it should be in the 3.9-stable tree, should we apply
it?
--
From: "Dirk Brandewie "
commit c96d53d600643ee0adfd1cb90814bd9510e62b71 upstream
Add CPU ID for Ivybrigde processor.
Signed-off-by: Dirk Brandewie
Signed-off-by: Rafael J. Wysocki
Signed-off-by: Jonghwan Choi
---
drivers/cpufreq/intel_pstate.c |1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/cpufreq/intel_pstate.c b/drivers/cpufreq/intel_pstate.c
index d8a8c9b..bd9fae6 100644
--- a/drivers/cpufreq/intel_pstate.c
+++ b/drivers/cpufreq/intel_pstate.c
@@ -570,6 +570,7 @@ static void intel_pstate_timer_func(unsigned long
__data)
static const struct x86_cpu_id intel_pstate_cpu_ids[] = {
ICPU(0x2a, default_policy),
ICPU(0x2d, default_policy),
+ ICPU(0x3a, default_policy),
{}
};
MODULE_DEVICE_TABLE(x86cpu, intel_pstate_cpu_ids);
--
1.7.9.5
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 3.9-stable] drm.h: Fix DRM compilation with bare-metal toolchain.'Mark Brown'
This patch looks like it should be in the 3.9-stable tree, should we apply it? -- From: "Paul Sokolovsky " commit b6330548383cf18d608faf1c2dc0c81c60476233 upstream An ifdef in drm.h expects to be compiled with full-fledged Linux toolchain, but it's common to compile kernel with just bare-metal toolchain which doesn't define __linux__. So, also add __KERNEL__ check. [n...@ti.com: port forward to 3.9-rc6 and post to dri devel for feedback as RFC] Signed-off-by: Paul Sokolovsky Signed-off-by: Dave Airlie Signed-off-by: Jonghwan Choi --- include/uapi/drm/drm.h |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/include/uapi/drm/drm.h b/include/uapi/drm/drm.h index 8d1e2bb..73a99e4 100644 --- a/include/uapi/drm/drm.h +++ b/include/uapi/drm/drm.h @@ -36,7 +36,7 @@ #ifndef _DRM_H_ #define _DRM_H_ -#if defined(__linux__) +#if defined(__KERNEL__) || defined(__linux__) #include #include -- 1.7.9.5 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 3.9-stable] This patch fixes the issue that drm_vblank_get() is
This patch looks like it should be in the 3.9-stable tree, should we apply
it?
--
From: "Inki Dae "
commit 20cd2640a295cab46bcd08f4788984ca236fc148 upstream
The issus occurs when next page flip request is tried
if previous page flip event wasn't completed yet and then
dpms became off.
So this patch make sure that page flip event is completed
before dpms goes to off.
Cc: # 3.9.x: b6330548: drm.h: Fix DRM compilation
Signed-off-by: Inki Dae
Signed-off-by: Kyungmin Park
Signed-off-by: Jonghwan Choi
---
drivers/gpu/drm/exynos/exynos_drm_crtc.c | 16
1 file changed, 16 insertions(+)
diff --git a/drivers/gpu/drm/exynos/exynos_drm_crtc.c
b/drivers/gpu/drm/exynos/exynos_drm_crtc.c
index e8894bc..1847f1d 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_crtc.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_crtc.c
@@ -48,6 +48,8 @@ struct exynos_drm_crtc {
unsigned intpipe;
unsigned intdpms;
enum exynos_crtc_mode mode;
+ wait_queue_head_t pending_flip_queue;
+ atomic_tpending_flip;
};
static void exynos_drm_crtc_dpms(struct drm_crtc *crtc, int mode)
@@ -61,6 +63,13 @@ static void exynos_drm_crtc_dpms(struct drm_crtc *crtc,
int mode)
return;
}
+ if (mode > DRM_MODE_DPMS_ON) {
+ /* wait for the completion of page flip. */
+ wait_event(exynos_crtc->pending_flip_queue,
+ atomic_read(&exynos_crtc->pending_flip) ==
0);
+ drm_vblank_off(crtc->dev, exynos_crtc->pipe);
+ }
+
exynos_drm_fn_encoder(crtc, &mode, exynos_drm_encoder_crtc_dpms);
exynos_crtc->dpms = mode;
}
@@ -225,6 +234,7 @@ static int exynos_drm_crtc_page_flip(struct drm_crtc
*crtc,
spin_lock_irq(&dev->event_lock);
list_add_tail(&event->base.link,
&dev_priv->pageflip_event_list);
+ atomic_set(&exynos_crtc->pending_flip, 1);
spin_unlock_irq(&dev->event_lock);
crtc->fb = fb;
@@ -344,6 +354,8 @@ int exynos_drm_crtc_create(struct drm_device *dev,
unsigned int nr)
exynos_crtc->pipe = nr;
exynos_crtc->dpms = DRM_MODE_DPMS_OFF;
+ init_waitqueue_head(&exynos_crtc->pending_flip_queue);
+ atomic_set(&exynos_crtc->pending_flip, 0);
exynos_crtc->plane = exynos_plane_init(dev, 1 << nr, true);
if (!exynos_crtc->plane) {
kfree(exynos_crtc);
@@ -399,6 +411,8 @@ void exynos_drm_crtc_finish_pageflip(struct drm_device
*dev, int crtc)
struct exynos_drm_private *dev_priv = dev->dev_private;
struct drm_pending_vblank_event *e, *t;
struct timeval now;
+ struct drm_crtc *drm_crtc = dev_priv->crtc[crtc];
+ struct exynos_drm_crtc *exynos_crtc = to_exynos_crtc(drm_crtc);
unsigned long flags;
DRM_DEBUG_KMS("%s\n", __FILE__);
@@ -419,6 +433,8 @@ void exynos_drm_crtc_finish_pageflip(struct drm_device
*dev, int crtc)
list_move_tail(&e->base.link,
&e->base.file_priv->event_list);
wake_up_interruptible(&e->base.file_priv->event_wait);
drm_vblank_put(dev, crtc);
+ atomic_set(&exynos_crtc->pending_flip, 0);
+ wake_up(&exynos_crtc->pending_flip_queue);
}
spin_unlock_irqrestore(&dev->event_lock, flags);
--
1.7.9.5
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH] PM / Domains: Fix memory leak on error path in pm_genpd_attach_cpuidle
If pm_genpd_attach_cpudidle failed we leak memory stored in 'cpu_data'.
Signed-off-by: Jonghwan Choi
---
drivers/base/power/domain.c |5 -
1 files changed, 4 insertions(+), 1 deletions(-)
diff --git a/drivers/base/power/domain.c b/drivers/base/power/domain.c
index c22b869..96b71b6 100644
--- a/drivers/base/power/domain.c
+++ b/drivers/base/power/domain.c
@@ -1862,7 +1862,7 @@ int pm_genpd_attach_cpuidle(struct generic_pm_domain
*genpd, int state)
cpuidle_drv = cpuidle_driver_ref();
if (!cpuidle_drv) {
ret = -ENODEV;
- goto out;
+ goto err_drv;
}
if (cpuidle_drv->state_count <= state) {
ret = -EINVAL;
@@ -1884,6 +1884,9 @@ int pm_genpd_attach_cpuidle(struct generic_pm_domain
*genpd, int state)
err:
cpuidle_driver_unref();
+
+ err_drv:
+ kfree(cpu_data);
goto out;
}
--
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 v3 2/2] therma: exynos: Supports thermal tripping
Hi~
> >> data->base + EXYNOS_THD_TEMP_RISE);
> >> @@ -665,6 +672,8 @@ static void exynos_tmu_control(struct
> platform_device
> >> *pdev, bool on)
> >> con &= ~(EXYNOS_TMU_TRIP_MODE_MASK | EXYNOS_MUX_ADDR_MASK);
> >> con |= pdata->noise_cancel_mode <<
> >> EXYNOS_TMU_TRIP_MODE_SHIFT;
> >> con |= (EXYNOS_MUX_ADDR_VALUE << EXYNOS_MUX_ADDR_SHIFT);
> >> + if (pdata->trigger_levels[3])
> >> + con |= EXYNOS_TMU_TRIP_EN;
> >> }
> Why don't you support trigger_level[3] in exynos4210 either? Even though
> 4210 doesn't support
> hardware tripping,
> I think it can be set in same way. I've done it in my local git with
> following codes.
>
As follows, TRIP_EN is applied SOC_ARCH_EXYNOS(for exynos4412 & exynos5250).
(SOC_ARCH_EXYNOS4210 for exynos4210)
if (data->soc == SOC_ARCH_EXYNOS) {
con &= ~(EXYNOS_TMU_TRIP_MODE_MASK | EXYNOS_MUX_ADDR_MASK);
con |= pdata->noise_cancel_mode << EXYNOS_TMU_TRIP_MODE_SHIFT;
con |= (EXYNOS_MUX_ADDR_VALUE << EXYNOS_MUX_ADDR_SHIFT);
if (pdata->trigger_levels[3])
con |= EXYNOS_TMU_TRIP_EN;
}
And. Trigger_level3_en is not stored in INTEN(only level0~level2en)
Especially when temperature exceeds a extremely high threshold temperature
denoted as THRES_LEVEL_RISE3 field of THRESHOLD_TEMP_RISE register, then
Exynos5250 should not be damaged by the hot temperature. In this case, TMU
urgently sends active-high signal (THERM_TRIP) to PMU, and thermal tripping
by hardware logic i.e PMU (Power Management Unit) is performed. (From TMU
document.)
Trigger_leves[3] is only used for THERM_TRIP. Trigger_levels3_en doesn't
effect h/w tripping mode.
So i think trigger_levels[3] is better than trigger_level3_en.
Thanks~~^^
> -Original Message-
> From: jonghwa3@samsung.com [mailto:jonghwa3@samsung.com]
> Sent: Wednesday, November 21, 2012 1:02 PM
> To: Kyungmin Park
> Cc: Jonghwan Choi; jonghwa3.lee; open list; Amit Daniel Kachhap; Zhang Rui;
> Sachin Kamat
> Subject: Re: [PATCH v3 2/2] therma: exynos: Supports thermal tripping
>
> Hi,
> On 2012년 11월 20일 10:40, Kyungmin Park wrote:
> > On 11/20/12, Jonghwan Choi wrote:
> >> TMU urgently sends active-high signal (thermal trip) to PMU,
> >> and thermal tripping by hardware logic i.e PMU is performed.
> >> Thermal tripping means that PMU cut off the whole power of SoC
> >> by controlling external voltage regulator.
> >>
> >> Signed-off-by: Jonghwan Choi
> > Ackedy-by: Kyungmin Park
> >> ---
> >> drivers/thermal/exynos_thermal.c | 10 ++
> >> 1 files changed, 10 insertions(+), 0 deletions(-)
> >>
> >> diff --git a/drivers/thermal/exynos_thermal.c
> >> b/drivers/thermal/exynos_thermal.c
> >> index 129e827..569478d 100644
> >> --- a/drivers/thermal/exynos_thermal.c
> >> +++ b/drivers/thermal/exynos_thermal.c
> >> @@ -58,6 +58,7 @@
> >> #define EXYNOS_TMU_CORE_ON BIT(0)
> >> #define EXYNOS_TMU_CORE_ON_SHIFT 0
> >> #define EXYNOS_TMU_CORE_ON_MASK(0x1 <<
> >> EXYNOS_TMU_CORE_ON_SHIFT)
> >> +#define EXYNOS_TMU_TRIP_EN BIT(12)
> >> #define EXYNOS_TMU_DEF_CODE_TO_TEMP_OFFSET 50
> >>
> >> /* Exynos4210 specific registers */
> >> @@ -631,6 +632,12 @@ static int exynos_tmu_initialize(struct
> >> platform_device
> >> *pdev)
> >> goto out;
> >> }
> >> rising_threshold |= (threshold_code << 16);
> >> + threshold_code = temp_to_code(data,
> >> pdata->trigger_levels[3]);
> >> + if (threshold_code < 0) {
> >> + ret = threshold_code;
> >> + goto out;
> >> + }
> >> + rising_threshold |= (threshold_code << 24);
> >>
> >> writel(rising_threshold,
> >> data->base + EXYNOS_THD_TEMP_RISE);
> >> @@ -665,6 +672,8 @@ static void exynos_tmu_control(struct
> platform_device
> >> *pdev, bool on)
> >> con &= ~(EXYNOS_TMU_TRIP_MODE_MASK | EXYNOS_MUX_ADDR_MASK);
> >> con |= pdata->noise_cancel_mode <<
> >> EXYNOS_TMU_TRIP_MODE_SHIFT;
> >> con |=
[PATCH v4 1/2] thermal: exynos: Fix wrong bit to control tmu core
[0]bit is used to enable/disable tmu core. [1] bit is a reserved bit.
Signed-off-by: Jonghwan Choi
---
drivers/thermal/exynos_thermal.c | 16
1 files changed, 12 insertions(+), 4 deletions(-)
diff --git a/drivers/thermal/exynos_thermal.c
b/drivers/thermal/exynos_thermal.c
index 6dd29e4..129e827 100644
--- a/drivers/thermal/exynos_thermal.c
+++ b/drivers/thermal/exynos_thermal.c
@@ -52,9 +52,12 @@
#define EXYNOS_TMU_TRIM_TEMP_MASK 0xff
#define EXYNOS_TMU_GAIN_SHIFT 8
+#define EXYNOS_TMU_GAIN_MASK (0xF << EXYNOS_TMU_GAIN_SHIFT)
#define EXYNOS_TMU_REF_VOLTAGE_SHIFT 24
-#define EXYNOS_TMU_CORE_ON 3
-#define EXYNOS_TMU_CORE_OFF2
+#define EXYNOS_TMU_REF_VOLTAGE_MASK(0x1F <<
EXYNOS_TMU_REF_VOLTAGE_SHIFT)
+#define EXYNOS_TMU_CORE_ON BIT(0)
+#define EXYNOS_TMU_CORE_ON_SHIFT 0
+#define EXYNOS_TMU_CORE_ON_MASK(0x1 <<
EXYNOS_TMU_CORE_ON_SHIFT)
#define EXYNOS_TMU_DEF_CODE_TO_TEMP_OFFSET 50
/* Exynos4210 specific registers */
@@ -85,7 +88,9 @@
#define EXYNOS_TMU_CLEAR_FALL_INT (0x111 << 16)
#define EXYNOS_MUX_ADDR_VALUE 6
#define EXYNOS_MUX_ADDR_SHIFT 20
+#define EXYNOS_MUX_ADDR_MASK (0x7 << EXYNOS_MUX_ADDR_SHIFT)
#define EXYNOS_TMU_TRIP_MODE_SHIFT 13
+#define EXYNOS_TMU_TRIP_MODE_MASK (0x7 << EXYNOS_TMU_TRIP_MODE_SHIFT)
#define EFUSE_MIN_VALUE 40
#define EFUSE_MAX_VALUE 100
@@ -650,10 +655,14 @@ static void exynos_tmu_control(struct platform_device
*pdev, bool on)
mutex_lock(&data->lock);
clk_enable(data->clk);
- con = pdata->reference_voltage << EXYNOS_TMU_REF_VOLTAGE_SHIFT |
+ con = readl(data->base + EXYNOS_TMU_REG_CONTROL);
+ con &= ~(EXYNOS_TMU_REF_VOLTAGE_MASK | EXYNOS_TMU_GAIN_MASK |
+ EXYNOS_TMU_CORE_ON_MASK);
+ con |= pdata->reference_voltage << EXYNOS_TMU_REF_VOLTAGE_SHIFT |
pdata->gain << EXYNOS_TMU_GAIN_SHIFT;
if (data->soc == SOC_ARCH_EXYNOS) {
+ con &= ~(EXYNOS_TMU_TRIP_MODE_MASK | EXYNOS_MUX_ADDR_MASK);
con |= pdata->noise_cancel_mode <<
EXYNOS_TMU_TRIP_MODE_SHIFT;
con |= (EXYNOS_MUX_ADDR_VALUE << EXYNOS_MUX_ADDR_SHIFT);
}
@@ -665,7 +674,6 @@ static void exynos_tmu_control(struct platform_device
*pdev, bool on)
pdata->trigger_level1_en << 4 |
pdata->trigger_level0_en;
} else {
- con |= EXYNOS_TMU_CORE_OFF;
interrupt_en = 0; /* Disable all interrupts */
}
writel(interrupt_en, data->base + EXYNOS_TMU_REG_INTEN);
--
1.7.4.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v4 2/2] therma: exynos: Supports thermal tripping
TMU urgently sends active-high signal (thermal trip) to PMU,
and thermal tripping by hardware logic i.e PMU is performed.
Thermal tripping means that PMU cut off the whole power of SoC
by controlling external voltage regulator.
Signed-off-by: Jonghwan Choi
---
drivers/thermal/exynos_thermal.c | 21 +
1 files changed, 17 insertions(+), 4 deletions(-)
diff --git a/drivers/thermal/exynos_thermal.c
b/drivers/thermal/exynos_thermal.c
index 129e827..f0ce099 100644
--- a/drivers/thermal/exynos_thermal.c
+++ b/drivers/thermal/exynos_thermal.c
@@ -631,6 +631,12 @@ static int exynos_tmu_initialize(struct platform_device
*pdev)
goto out;
}
rising_threshold |= (threshold_code << 16);
+ threshold_code = temp_to_code(data,
pdata->trigger_levels[3]);
+ if (threshold_code < 0) {
+ ret = threshold_code;
+ goto out;
+ }
+ rising_threshold |= (threshold_code << 24);
writel(rising_threshold,
data->base + EXYNOS_THD_TEMP_RISE);
@@ -669,10 +675,14 @@ static void exynos_tmu_control(struct platform_device
*pdev, bool on)
if (on) {
con |= EXYNOS_TMU_CORE_ON;
- interrupt_en = pdata->trigger_level3_en << 12 |
- pdata->trigger_level2_en << 8 |
+ interrupt_en = pdata->trigger_level2_en << 8 |
pdata->trigger_level1_en << 4 |
pdata->trigger_level0_en;
+
+ if (data->soc == SOC_ARCH_EXYNOS4210)
+ interrupt_en |= pdata->trigger_level3_en << 12;
+ else
+ con |= pdata->trigger_level3_en << 12;
} else {
interrupt_en = 0; /* Disable all interrupts */
}
@@ -770,6 +780,7 @@ static struct exynos_tmu_platform_data const
exynos_default_tmu_data = {
.trigger_levels[0] = 85,
.trigger_levels[1] = 103,
.trigger_levels[2] = 110,
+ .trigger_levels[3] = 120,
.trigger_level0_en = 1,
.trigger_level1_en = 1,
.trigger_level2_en = 1,
@@ -917,8 +928,10 @@ static int __devinit exynos_tmu_probe(struct
platform_device *pdev)
/* Register the sensor with thermal management interface */
(&exynos_sensor_conf)->private_data = data;
exynos_sensor_conf.trip_data.trip_count = pdata->trigger_level0_en +
- pdata->trigger_level1_en + pdata->trigger_level2_en
+
- pdata->trigger_level3_en;
+ pdata->trigger_level1_en + pdata->trigger_level2_en;
+
+ if (data->soc == SOC_ARCH_EXYNOS4210)
+ exynos_sensor_conf.trip_data.trip_count +=
pdata->trigger_level3_en;
for (i = 0; i < exynos_sensor_conf.trip_data.trip_count; i++)
exynos_sensor_conf.trip_data.trip_val[i] =
--
1.7.4.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 1/2] pinctrl: samsung: Fix compile error in pinctrl-exynos5440/samsung.c
error: drivers/pinctrl/pinctrl-exynos5440.o: multiple definition of 'pcfgs'
drivers/pinctrl/pinctrl-samsung.o: previous definition here
Signed-off-by: Jonghwan Choi
---
drivers/pinctrl/pinctrl-samsung.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/pinctrl/pinctrl-samsung.c
b/drivers/pinctrl/pinctrl-samsung.c
index 8f31b65..fc98b38 100644
--- a/drivers/pinctrl/pinctrl-samsung.c
+++ b/drivers/pinctrl/pinctrl-samsung.c
@@ -37,7 +37,7 @@
#define FSUFFIX_LENsizeof(FUNCTION_SUFFIX)
/* list of all possible config options supported */
-struct pin_config {
+static const struct pin_config {
char*prop_cfg;
unsigned intcfg_type;
} pcfgs[] = {
--
1.7.4.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 2/2] pinctrl: exynos5440: Fix compile error in pinctrl-exynos5440/samsung.c
error: drivers/pinctrl/pinctrl-exynos5440.o: multiple definition of 'pcfgs'
drivers/pinctrl/pinctrl-samsung.o: previous definition here
Signed-off-by: Jonghwan Choi
---
drivers/pinctrl/pinctrl-exynos5440.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/pinctrl/pinctrl-exynos5440.c
b/drivers/pinctrl/pinctrl-exynos5440.c
index b8635f6..8a863a3 100644
--- a/drivers/pinctrl/pinctrl-exynos5440.c
+++ b/drivers/pinctrl/pinctrl-exynos5440.c
@@ -117,7 +117,7 @@ struct exynos5440_pinctrl_priv_data {
};
/* list of all possible config options supported */
-struct pin_config {
+static const struct pin_config {
char*prop_cfg;
unsigned intcfg_type;
} pcfgs[] = {
--
1.7.4.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH] regulator: core: Reduce busy-wait looping
Commit 5df529d440("regulator: core: Reduce busy-wait looping")
can also be used in regulator_do_set_voltage.
Signed-off-by: Jonghwan Choi
---
drivers/regulator/core.c | 39 +--
1 file changed, 33 insertions(+), 6 deletions(-)
diff --git a/drivers/regulator/core.c b/drivers/regulator/core.c
index afca1bc..c375bfb 100644
--- a/drivers/regulator/core.c
+++ b/d728099474rivers/regulator/core.c
@@ -2355,12 +2355,39 @@ static int _regulator_do_set_voltage(struct
regulator_dev *rdev,
delay = 0;
}
- /* Insert any necessary delays */
- if (delay >= 1000) {
- mdelay(delay / 1000);
- udelay(delay % 1000);
- } else if (delay) {
- udelay(delay);
+ /*
+* Delay for the requested amount of time as per the
guidelines in:
+*
+* Documentation/timers/timers-howto.txt
+*
+* The assumption here is that regulators will never set the
voltage in
+* atomic context and therefore sleeping functions can be
used.
+*/
+ if (delay) {
+ unsigned int ms = delay / 1000;
+ unsigned int us = delay % 1000;
+
+ if (ms > 0) {
+ /*
+* For small enough values, handle
super-millisecond
+* delays in the usleep_range() call below.
+*/
+ if (ms < 20)
+ us += ms * 1000;
+ else
+ msleep(ms);
+ }
+
+ /*
+* Give the scheduler some room to coalesce with any
other
+* wakeup sources. For delays shorter than 10 us,
don't even
+* bother setting up high-resolution timers and just
busy-
+* loop.
+*/
+ if (us >= 10)
+ usleep_range(us, us + 100);
+ else
+ udelay(us);
}
}
--
1.7.10.4
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 1/4] cpufreq: s5pv210: Consider hibernation in pm notifier
Frequency lock should be considered in suspend/hibernation.
Signed-off-by: Jonghwan Choi
---
drivers/cpufreq/s5pv210-cpufreq.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/cpufreq/s5pv210-cpufreq.c
b/drivers/cpufreq/s5pv210-cpufreq.c
index e3973da..bfbb09e 100644
--- a/drivers/cpufreq/s5pv210-cpufreq.c
+++ b/drivers/cpufreq/s5pv210-cpufreq.c
@@ -526,6 +526,7 @@ static int s5pv210_cpufreq_notifier_event(struct
notifier_block *this,
int ret;
switch (event) {
+ case PM_HIBERNATION_PREPARE:
case PM_SUSPEND_PREPARE:
ret = cpufreq_driver_target(cpufreq_cpu_get(0), SLEEP_FREQ, 0);
if (ret < 0)
@@ -534,6 +535,7 @@ static int s5pv210_cpufreq_notifier_event(struct
notifier_block *this,
/* Disable updation of cpu frequency */
no_cpufreq_access = true;
return NOTIFY_OK;
+ case PM_POST_HIBERNATION:
case PM_POST_RESTORE:
case PM_POST_SUSPEND:
/* Enable updation of cpu frequency */
--
1.8.1.2
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 2/4] cpufreq: exynos: Consider hibernation in pm notifier
Frequency lock should be considered in suspend/hibernation.
Signed-off-by: Jonghwan Choi
---
drivers/cpufreq/exynos-cpufreq.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/cpufreq/exynos-cpufreq.c b/drivers/cpufreq/exynos-cpufreq.c
index f3c2287..cd05b0a 100644
--- a/drivers/cpufreq/exynos-cpufreq.c
+++ b/drivers/cpufreq/exynos-cpufreq.c
@@ -187,6 +187,7 @@ static int exynos_cpufreq_pm_notifier(struct notifier_block
*notifier,
int ret;
switch (pm_event) {
+ case PM_HIBERNATION_PREPARE:
case PM_SUSPEND_PREPARE:
mutex_lock(&cpufreq_lock);
frequency_locked = true;
@@ -198,6 +199,8 @@ static int exynos_cpufreq_pm_notifier(struct notifier_block
*notifier,
break;
+ case PM_POST_HIBERNATION:
+ case PM_POST_RESTORE:
case PM_POST_SUSPEND:
mutex_lock(&cpufreq_lock);
frequency_locked = false;
--
1.8.1.2
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 3/4] PM / devfreq: Consider hibernation in pm notifier
Frequency lock should be considered in suspend/hibernation.
Signed-off-by: Jonghwan Choi
---
drivers/devfreq/exynos/exynos4_bus.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/devfreq/exynos/exynos4_bus.c
b/drivers/devfreq/exynos/exynos4_bus.c
index cede6f7..dd6947e 100644
--- a/drivers/devfreq/exynos/exynos4_bus.c
+++ b/drivers/devfreq/exynos/exynos4_bus.c
@@ -962,6 +962,7 @@ static int exynos4_busfreq_pm_notifier_event(struct
notifier_block *this,
int err = 0;
switch (event) {
+ case PM_HIBERNATION_PREPARE:
case PM_SUSPEND_PREPARE:
/* Set Fastest and Deactivate DVFS */
mutex_lock(&data->lock);
@@ -1005,6 +1006,7 @@ unlock:
if (err)
return err;
return NOTIFY_OK;
+ case PM_POST_HIBERNATION:
case PM_POST_RESTORE:
case PM_POST_SUSPEND:
/* Reactivate */
--
1.8.1.2
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 4/4] PM / devfreq: Consider hibernation in pm notifier
Frequency lock should be considered in suspend/hibernation.
Signed-off-by: Jonghwan Choi
---
drivers/devfreq/exynos/exynos5_bus.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/devfreq/exynos/exynos5_bus.c
b/drivers/devfreq/exynos/exynos5_bus.c
index a60da3c..bd672de0 100644
--- a/drivers/devfreq/exynos/exynos5_bus.c
+++ b/drivers/devfreq/exynos/exynos5_bus.c
@@ -268,6 +268,7 @@ static int exynos5_busfreq_int_pm_notifier_event(struct
notifier_block *this,
int err = 0;
switch (event) {
+ case PM_HIBERNATION_PREPARE:
case PM_SUSPEND_PREPARE:
/* Set Fastest and Deactivate DVFS */
mutex_lock(&data->lock);
@@ -300,6 +301,7 @@ unlock:
if (err)
return NOTIFY_BAD;
return NOTIFY_OK;
+ case PM_POST_HIBERNATION:
case PM_POST_RESTORE:
case PM_POST_SUSPEND:
/* Reactivate */
--
1.8.1.2
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 1/2] cpufreq: s5pv210: Frequency lock should be considered in hibernation also.
The Frequency lock value should be higher or same than the booting frequency,
which is set by the bootloader. To eliminate possible inconsistency
in frequency, we save and restore frequency during suspend & resume
and disable CPUFREQ activity. This should be considered in hibernation also.
Signed-off-by: Jonghwan Choi
---
drivers/cpufreq/s5pv210-cpufreq.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/cpufreq/s5pv210-cpufreq.c
b/drivers/cpufreq/s5pv210-cpufreq.c
index e3973da..bfbb09e 100644
--- a/drivers/cpufreq/s5pv210-cpufreq.c
+++ b/drivers/cpufreq/s5pv210-cpufreq.c
@@ -526,6 +526,7 @@ static int s5pv210_cpufreq_notifier_event(struct
notifier_block *this,
int ret;
switch (event) {
+ case PM_HIBERNATION_PREPARE:
case PM_SUSPEND_PREPARE:
ret = cpufreq_driver_target(cpufreq_cpu_get(0), SLEEP_FREQ, 0);
if (ret < 0)
@@ -534,6 +535,7 @@ static int s5pv210_cpufreq_notifier_event(struct
notifier_block *this,
/* Disable updation of cpu frequency */
no_cpufreq_access = true;
return NOTIFY_OK;
+ case PM_POST_HIBERNATION:
case PM_POST_RESTORE:
case PM_POST_SUSPEND:
/* Enable updation of cpu frequency */
--
1.8.1.2
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 2/2] cpufreq: exynos: Frequency lock should be considered in hibernation also.
The Frequency lock value should be higher or same than the booting frequency,
which is set by the bootloader. To eliminate possible inconsistency
in frequency, we save and restore frequency during suspend & resume
and disable CPUFREQ activity. This should be considered in hibernation also.
Signed-off-by: Jonghwan Choi
---
drivers/cpufreq/exynos-cpufreq.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/cpufreq/exynos-cpufreq.c b/drivers/cpufreq/exynos-cpufreq.c
index f3c2287..cd05b0a 100644
--- a/drivers/cpufreq/exynos-cpufreq.c
+++ b/drivers/cpufreq/exynos-cpufreq.c
@@ -187,6 +187,7 @@ static int exynos_cpufreq_pm_notifier(struct notifier_block
*notifier,
int ret;
switch (pm_event) {
+ case PM_HIBERNATION_PREPARE:
case PM_SUSPEND_PREPARE:
mutex_lock(&cpufreq_lock);
frequency_locked = true;
@@ -198,6 +199,8 @@ static int exynos_cpufreq_pm_notifier(struct notifier_block
*notifier,
break;
+ case PM_POST_HIBERNATION:
+ case PM_POST_RESTORE:
case PM_POST_SUSPEND:
mutex_lock(&cpufreq_lock);
frequency_locked = false;
--
1.8.1.2
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 1/2] PM / OPP: Use list_for_each_entry_reverse instead of list_for_each_entry
Most of the cpufreq table is sorted in descending order.
But when cpufreq table is made from dev_pm_opp_init_cpufreq_table,
it is sorted in ascending order. So in some case to make cpufreq table
with descending order it needs an extra work.
Signed-off-by: Jonghwan Choi
---
drivers/base/power/opp.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/base/power/opp.c b/drivers/base/power/opp.c
index 2553867..8d81a46 100644
--- a/drivers/base/power/opp.c
+++ b/drivers/base/power/opp.c
@@ -649,7 +649,7 @@ int dev_pm_opp_init_cpufreq_table(struct device *dev,
return -ENOMEM;
}
- list_for_each_entry(opp, &dev_opp->opp_list, node) {
+ list_for_each_entry_reverse(opp, &dev_opp->opp_list, node) {
if (opp->available) {
freq_table[i].driver_data = i;
freq_table[i].frequency = opp->rate / 1000;
--
1.7.10.4
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
RE: [PATCH 1/2] PM / OPP: Use list_for_each_entry_reverse instead of list_for_each_entry
Hi~ > > Most of the cpufreq table is sorted in descending order. > > Which part of kernel says that? > -> I couldn't check all. Sorry. > > But when cpufreq table is made from dev_pm_opp_init_cpufreq_table, it > > is sorted in ascending order. So in some case to make cpufreq table > > with descending order it needs an extra work. > > Order of this table shouldn't matter at all in cpufreq layer.. -> You are right. But 5440 cpufreq driver write an index number instead of clk divider value for change DVFS. And our another(will submit) also write an index number for changing DVFS. As you said, order of table shouldn't matter at all in cpufreq layer. Then, could this can be applied? In our case, We want to use index 0 for P0 and index 1 for P1. Thanks Best Ragrds. > -Original Message- > From: viresh.li...@gmail.com [mailto:viresh.li...@gmail.com] On Behalf Of > Viresh Kumar > Sent: Tuesday, April 29, 2014 2:33 PM > To: Jonghwan Choi > Cc: open list; Rafael J. Wysocki; Len Brown > Subject: Re: [PATCH 1/2] PM / OPP: Use list_for_each_entry_reverse instead > of list_for_each_entry > > On Tue, Apr 29, 2014 at 10:54 AM, Jonghwan Choi > wrote: > > Most of the cpufreq table is sorted in descending order. > > Which part of kernel says that? > > > But when cpufreq table is made from dev_pm_opp_init_cpufreq_table, it > > is sorted in ascending order. So in some case to make cpufreq table > > with descending order it needs an extra work. > > Order of this table shouldn't matter at all in cpufreq layer.. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 1/3] PM / OPP: Add support for descending order for cpufreq table
In the frequency table dts file, the frequencies are arranged in
descending order which maps 1 to 1 with other frequency parameter to
be calculated and programmed in some registers.
But the OPP library works by generating the frequencies in ascending
order which breaks the above logic.
So added OPP_TABLE_ORDER_DESCEND flag to consider descending order.
Cc: Amit Daniel Kachhap
Signed-off-by: Jonghwan Choi
---
drivers/base/power/opp.c | 17 -
include/linux/pm_opp.h |7 +--
2 files changed, 21 insertions(+), 3 deletions(-)
diff --git a/drivers/base/power/opp.c b/drivers/base/power/opp.c
index 2553867..ec7d553 100644
--- a/drivers/base/power/opp.c
+++ b/drivers/base/power/opp.c
@@ -18,6 +18,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -597,10 +598,21 @@ int dev_pm_opp_disable(struct device *dev, unsigned
long freq)
EXPORT_SYMBOL_GPL(dev_pm_opp_disable);
#ifdef CONFIG_CPU_FREQ
+
+static int opp_descend_cmp(void *priv, struct list_head *a,
+struct list_head *b)
+{
+struct dev_pm_opp *ra = list_entry(a, struct dev_pm_opp, node);
+struct dev_pm_opp *rb = list_entry(b, struct dev_pm_opp, node);
+
+return rb->rate - ra->rate;
+}
+
/**
* dev_pm_opp_init_cpufreq_table() - create a cpufreq table for a device
* @dev: device for which we do this operation
* @table: Cpufreq table returned back to caller
+ * @flags: OPP_TABLE_ORDER_DESCEND or zero
*
* Generate a cpufreq table for a provided device- this assumes that the
* opp list is already initialized and ready for usage.
@@ -622,7 +634,7 @@ EXPORT_SYMBOL_GPL(dev_pm_opp_disable);
* or in contexts where mutex locking cannot be used.
*/
int dev_pm_opp_init_cpufreq_table(struct device *dev,
- struct cpufreq_frequency_table **table)
+ struct cpufreq_frequency_table **table, unsigned char flags)
{
struct device_opp *dev_opp;
struct dev_pm_opp *opp;
@@ -649,6 +661,9 @@ int dev_pm_opp_init_cpufreq_table(struct device *dev,
return -ENOMEM;
}
+ if (flags & OPP_TABLE_ORDER_DESCEND)
+ list_sort(NULL, &dev_opp->opp_list, opp_descend_cmp);
+
list_for_each_entry(opp, &dev_opp->opp_list, node) {
if (opp->available) {
freq_table[i].driver_data = i;
diff --git a/include/linux/pm_opp.h b/include/linux/pm_opp.h
index 5151b00..cf42770 100644
--- a/include/linux/pm_opp.h
+++ b/include/linux/pm_opp.h
@@ -118,13 +118,16 @@ static inline int of_init_opp_table(struct device
*dev)
#endif
#if defined(CONFIG_CPU_FREQ) && defined(CONFIG_PM_OPP)
+
+#define OPP_TABLE_ORDER_DESCEND(1 << 1)
+
int dev_pm_opp_init_cpufreq_table(struct device *dev,
- struct cpufreq_frequency_table **table);
+ struct cpufreq_frequency_table **table, unsigned char
flags);
void dev_pm_opp_free_cpufreq_table(struct device *dev,
struct cpufreq_frequency_table **table);
#else
static inline int dev_pm_opp_init_cpufreq_table(struct device *dev,
- struct cpufreq_frequency_table **table)
+ struct cpufreq_frequency_table **table, unsigned char flags)
{
return -EINVAL;
}
--
1.7.10.4
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
RE: [PATCH 1/3] PM / OPP: Add support for descending order for cpufreq table
Hi. Viresh Kumar
Your reply is so fast like Usain Bolt.
> So, create three flags:
> OPP_TABLE_ORDER_ASCENDING 0
> OPP_TABLE_ORDER_DESCENDING1
> OPP_TABLE_ORDER_ORIGINAL 2 (And use this for your case.)
-> Actually, I want to use OPP_TABLE_ORDER_DESCENDING.(Not
OPP_TABLE_ORDER_ORIGINAL.)
I think that it is enough to support both descending and ascending ordering
only.
The meaning of "ORIGIANL" Amit, said, when he(and I) writes a frequency in
dts file with ordering(Ascending or Descending). He(and I) want the
frequency to be register according to ordering.(Ascending or Descending).
I concerned that if we use ORIGINAL ordering, opp_find_freq_ceil/foor can be
broken.
(example, 1GH - 500MH - 800MHz - 200MHz - 600MHz)
Thanks~
Best Regars
> -Original Message-
> From: viresh.li...@gmail.com [mailto:viresh.li...@gmail.com] On Behalf Of
> Viresh Kumar
> Sent: Wednesday, April 30, 2014 5:25 PM
> To: Jonghwan Choi; Linux PM list
> Cc: open list; Rafael J. Wysocki; Len Brown; Amit Daniel Kachhap
> Subject: Re: [PATCH 1/3] PM / OPP: Add support for descending order for
> cpufreq table
>
> Hi,
>
> This isn't a very big patchset and this patch is very much required to
> understand other patches and so please cc all people from other list here
> as well..
>
> On Wed, Apr 30, 2014 at 11:58 AM, Jonghwan Choi
> wrote:
> > In the frequency table dts file, the frequencies are arranged in
>
> Improve your logs a bit. Which dts file are you talking about here ?
> How would anybody know that you are talking about exynos here?
>
> Also, you shouldn't mention that here, just tell the kind of requirement
> platforms may have. i.e. people may want to keep the opp list in the same
> order in which it came from DT.
>
> > descending order which maps 1 to 1 with other frequency parameter to
> > be calculated and programmed in some registers.
> > But the OPP library works by generating the frequencies in ascending
> > order which breaks the above logic.
> > So added OPP_TABLE_ORDER_DESCEND flag to consider descending order.
>
> So, create three flags:
> OPP_TABLE_ORDER_ASCENDING 0
> OPP_TABLE_ORDER_DESCENDING1
> OPP_TABLE_ORDER_ORIGINAL 2 (And use this for your case.)
>
> > Cc: Amit Daniel Kachhap
> > Signed-off-by: Jonghwan Choi
> > ---
> > drivers/base/power/opp.c | 17 -
> > include/linux/pm_opp.h |7 +--
> > 2 files changed, 21 insertions(+), 3 deletions(-)
>
> You are changing prototype of a function and so all other files which are
> using this routine will break after this patch and we can't afford it as
> we want git bisect to work properly.
>
> So, fix all platforms here in this patch only, i.e. part of 2/3 and
> complete 3/3 should have been merged into this one.
>
> > diff --git a/drivers/base/power/opp.c b/drivers/base/power/opp.c index
> > 2553867..ec7d553 100644
> > --- a/drivers/base/power/opp.c
> > +++ b/drivers/base/power/opp.c
> > @@ -18,6 +18,7 @@
> > #include
> > #include
> > #include
> > +#include
> > #include
> > #include
> > #include
> > @@ -597,10 +598,21 @@ int dev_pm_opp_disable(struct device *dev,
> > unsigned long freq) EXPORT_SYMBOL_GPL(dev_pm_opp_disable);
> >
> > #ifdef CONFIG_CPU_FREQ
> > +
> > +static int opp_descend_cmp(void *priv, struct list_head *a,
> > +struct list_head *b) {
> > +struct dev_pm_opp *ra = list_entry(a, struct dev_pm_opp, node);
> > +struct dev_pm_opp *rb = list_entry(b, struct dev_pm_opp,
> > +node);
> > +
> > +return rb->rate - ra->rate;
> > +}
> > +
> > /**
> > * dev_pm_opp_init_cpufreq_table() - create a cpufreq table for a
> device
> > * @dev: device for which we do this operation
> > * @table: Cpufreq table returned back to caller
> > + * @flags: OPP_TABLE_ORDER_DESCEND or zero
> > *
> > * Generate a cpufreq table for a provided device- this assumes that
> the
> > * opp list is already initialized and ready for usage.
> > @@ -622,7 +634,7 @@ EXPORT_SYMBOL_GPL(dev_pm_opp_disable);
> > * or in contexts where mutex locking cannot be used.
> > */
> > int dev_pm_opp_init_cpufreq_table(struct device *dev,
> > - struct cpufreq_frequency_table **table)
> > + struct cpufreq_frequency_table **table, unsigned char
> > + flags)
>
> You are targeting the wrong routine. Fix of_init_opp_table() instead and
> things would work automatically then..
>
> And please don't change prototype of dev_pm_opp_add() for now and just
> define __dev_pm_opp_add() which will be called from
> dev_pm_opp_add() and of_init_opp_table() with 'int order' parameter.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] PM / OPP: Add support for descending order for cpufreq table
On 8 May 2014 2:56 PM, Viresh Kumar wrote:
>
> Not necessarily. People may need a multiplier as well or some other
> configuration and so this stuff was left for drivers to implement.
-> In exynos cpufreq driver, if we want to support more frequency, then
we have to describe frequency information in dts file and have to change exynos
cpufreq
driver file also(For adding divider value).
But if dev_pm_opp has a divider value for DVFS,when we want to support more
frequency
we have only to change the dts file.
I think that it is easy to maintain cpufreq driver and very convenient.
(Can be applied to devfreq)
This is a example (exynos4210 doesn't support DT.)
--- a/drivers/base/power/opp.c
+++ b/drivers/base/power/opp.c
@@ -64,6 +64,7 @@ struct dev_pm_opp {
bool available;
unsigned long rate;
unsigned long u_volt;
+ unsigned int ctl[2];
struct device_opp *dev_opp;
struct rcu_head head;
diff --git a/arch/arm/boot/dts/exynos4210.dtsi
b/arch/arm/boot/dts/exynos4210.dtsi
index cacf614..007a411 100644
--- a/arch/arm/boot/dts/exynos4210.dtsi
+++ b/arch/arm/boot/dts/exynos4210.dtsi
@@ -81,6 +81,24 @@
interrupts = <2 2>, <3 2>;
};
+ cpufreq@16 {
+ compatible = "samsung,exynos7842-cpufreq";
+ reg = <0x16 0x1000>;
+ interrupts = <0 57 0>;
+ operating-points = <
+ /* KHzuVclkdiv0 clkdiv1 */
+ 150 110 0x1 0x1
+ 140 1075000 0x3 0x2
+ 130 105 0x3 0x3
+ 120 1025000 0x4 0x4
+ 110 100 0x5 0x5
+ 100 975000 0x6 0x6
+ 90 95 0x7 0x7
+ 80 925000 0x8 0x8
+ >;
+ };
+
+
pinctrl_0: pinctrl@1140 {
compatible = "samsung,exynos4210-pinctrl";
reg = <0x1140 0x1000>;
Thanks
Best Regards.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] PM / OPP: Add support for descending order for cpufreq table
On Thu, May 8, 2014 at 11:00 PM, Viresh Kumar wrote:
> Why? So, as far as I got it your dividers are nothing but 0,1,2...
> i.e.
> Freqs: 400 500 600 700 800
> div: 4 3 2 1 0
>
> right? That's what you are doing in exynos5440. So just add this in your
> probe after doing: dev_pm_opp_init_cpufreq_table
>
> for(i = 0; all-available-freqs; i++)
> dvfs_info->freq_table[i].driver_data = dvfs_info->freq_count - i;
>
> And this will work with changes in dts files.
I am sorry
I couldn’t provide detailed information about this suggestion.
This suggestion is not for exynos5440. This is for exynos4210,
exynos4x12 and exynos5250.
(But this can be applied to exynos5440 also)
I want to make exynos cpufreq driver simple.
There are exynos-cpufreq.c, exynos4210-cpufreq.c exynos4x12-cpufreq.
exynos5250-cpufreq.c for exynos soc.
And exynos4210-cpufreq.c, exynos4x12 and exynos5250-cpufreq. c has a
clk divider table for each frequency.
example) exynos4210-cpufreq.c
static struct apll_freq apll_freq_4210[] = {
/*
* values:
* freq
* clock divider for CORE, COREM0, COREM1, PERIPH, ATB,
PCLK_DBG, APLL, RESERVED
* clock divider for COPY, HPM, RESERVED
* PLL M, P, S
*/
APLL_FREQ(1200, 0, 3, 7, 3, 4, 1, 7, 0, 5, 0, 0, 150, 3, 1),
APLL_FREQ(1000, 0, 3, 7, 3, 4, 1, 7, 0, 4, 0, 0, 250, 6, 1),
APLL_FREQ(800, 0, 3, 7, 3, 3, 1, 7, 0, 3, 0, 0, 200, 6, 1),
APLL_FREQ(500, 0, 3, 7, 3, 3, 1, 7, 0, 3, 0, 0, 250, 6, 2),
APLL_FREQ(200, 0, 1, 3, 1, 3, 1, 0, 0, 3, 0, 0, 200, 6, 3),
};
If we can pass this clk divider value to exynos cpufreq driver through
DT, we can remove most of exynos-cpufreq.c files/codes. And when
new frequency is added/removed or new soc is released, for supporting
dvfs we have only to describe frequency, voltage and divider value in
dts file.
Thanks
Best Regards.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] PM / OPP: Add support for descending order for cpufreq table
On Fri, May 9, 2014 at 6:23 AM, Nishanth Menon wrote: > Have you considered the option of having a clock driver which can > decide the divider (based on dts OR index or whatever)? > > example: you could do clk_set_rate(apll, rate); > and instead of implementing clock divider programmation inside cpufreq > driver, you let corresponding clock driver do it for you. that allows > you to reuse clock driver with various parameters needed for your SoC > variations. IMHO, we are trying to solve a problem meant to be solved > in clock framework instead of within cpufreq. I already considered it. (But it only passes on what cpufreq driver has to do to clock framework. For changing clock rate, if changing operation just divides a rate of parent it can be solved easily But exycpufreq driver is more complicated. Previously, to change frequency, pll value and clk divider value were changed in cpufreq driver. Later someone moved the code which changes pll value to clock framework. In there, pll values are maintained as table per frequency. And if frequency is added/removed, values of pll table should be changed. when we change the pll value through clk_set_rate, internally to find proper pll value, pll table is searched. If proper pll value is found, that value is written into the register) My suggestion is that all these change details should be removed according to adding/removing frequency. I believe that cpufreq driver just writes a specific value per frequency into the register for dvfs(Maybe other work is also needed) If we just describe the specific value per frequency in dts file, the driver will get that information through DT, and use it for DVFS.) Then when a new chip is released(if the chip has the same h/w interface - register map), we only have to do as above. Thanks Best Regards -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
