[PATCH v5 0/5] Let the power allocator thermal governor run on any thermal zone
Relax the thermal governor requirements of sustainable_power and at least two trip points so that it can be bound to any thermal zone. Its behavior won't be optimal, it would be the best possible with the data provided. Changes since v4: - Fix crash when a thermal zone with no trip points has no get_trip_point_temp(). Reported by Daniel Kurtz. - s/estimate_controller_constants()/estimate_pid_constants()/g Changes since v3: - Don't hardcode a value for sustainable power and re-estimate the PID controllers every time if no sustainable power is given as suggested by Eduardo Valentin. - power_actor_get_min_power() moved to a patch of its own. Changes since v2: - Typos suggested by Daniel Kurtz Changes since v1: - Let the power allocator governor operate if the thermal zone doesn't have tzp as suggested by Chung-yih Wang Javi Merino (5): thermal: Add a function to get the minimum power thermal: power_allocator: relax the requirement of a sustainable_power in tzp thermal: power_allocator: relax the requirement of two passive trip points thermal: power_allocator: don't require tzp to be present for the thermal zone thermal: power_allocator: exit early if there are no cooling devices Documentation/thermal/power_allocator.txt | 2 +- drivers/thermal/power_allocator.c | 243 ++ drivers/thermal/thermal_core.c| 28 include/linux/thermal.h | 6 + 4 files changed, 214 insertions(+), 65 deletions(-) -- 1.9.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 v5 4/5] thermal: power_allocator: don't require tzp to be present for the thermal zone
Thermal zones created using thermal_zone_device_create() may not have
tzp. As the governor gets its parameters from there, allocate it while
the governor is bound to the thermal zone so that it can operate in it.
In this case, tzp is freed when the thermal zone switches to another
governor.
Cc: Zhang Rui
Cc: Eduardo Valentin
Reviewed-by: Daniel Kurtz
Signed-off-by: Javi Merino
---
While this would be easier to do by just ignoring the thermal zone if
there was no tzp, I think the approach in this patch provides a more
consistent behavior for the system integrator as it doesn't make a
distinction between thermal zones created with tzp and those that don't.
drivers/thermal/power_allocator.c | 32 +++-
1 file changed, 27 insertions(+), 5 deletions(-)
diff --git a/drivers/thermal/power_allocator.c
b/drivers/thermal/power_allocator.c
index 06e954cd81cc..78d589e7e65f 100644
--- a/drivers/thermal/power_allocator.c
+++ b/drivers/thermal/power_allocator.c
@@ -58,6 +58,8 @@ static inline s64 div_frac(s64 x, s64 y)
/**
* struct power_allocator_params - parameters for the power allocator governor
+ * @allocated_tzp: whether we have allocated tzp for this thermal zone and
+ * it needs to be freed on unbind
* @err_integral: accumulated error in the PID controller.
* @prev_err: error in the previous iteration of the PID controller.
* Used to calculate the derivative term.
@@ -70,6 +72,7 @@ static inline s64 div_frac(s64 x, s64 y)
* controlling for.
*/
struct power_allocator_params {
+ bool allocated_tzp;
s64 err_integral;
s32 prev_err;
int trip_switch_on;
@@ -527,8 +530,7 @@ static void allow_maximum_power(struct thermal_zone_device
*tz)
* Initialize the PID controller parameters and bind it to the thermal
* zone.
*
- * Return: 0 on success, -EINVAL if the thermal zone doesn't have tzp or
-ENOMEM
- * if we ran out of memory.
+ * Return: 0 on success, or -ENOMEM if we ran out of memory.
*/
static int power_allocator_bind(struct thermal_zone_device *tz)
{
@@ -536,13 +538,20 @@ static int power_allocator_bind(struct
thermal_zone_device *tz)
struct power_allocator_params *params;
unsigned long control_temp;
- if (!tz->tzp)
- return -EINVAL;
-
params = kzalloc(sizeof(*params), GFP_KERNEL);
if (!params)
return -ENOMEM;
+ if (!tz->tzp) {
+ tz->tzp = kzalloc(sizeof(*tz->tzp), GFP_KERNEL);
+ if (!tz->tzp) {
+ ret = -ENOMEM;
+ goto free_params;
+ }
+
+ params->allocated_tzp = true;
+ }
+
if (!tz->tzp->sustainable_power)
dev_warn(>device, "power_allocator: sustainable_power will
be estimated\n");
@@ -563,11 +572,24 @@ static int power_allocator_bind(struct
thermal_zone_device *tz)
tz->governor_data = params;
return 0;
+
+free_params:
+ kfree(params);
+
+ return ret;
}
static void power_allocator_unbind(struct thermal_zone_device *tz)
{
+ struct power_allocator_params *params = tz->governor_data;
+
dev_dbg(>device, "Unbinding from thermal zone %d\n", tz->id);
+
+ if (params->allocated_tzp) {
+ kfree(tz->tzp);
+ tz->tzp = NULL;
+ }
+
kfree(tz->governor_data);
tz->governor_data = NULL;
}
--
1.9.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 v5 3/5] thermal: power_allocator: relax the requirement of two passive trip points
The power allocator governor currently requires that the thermal zone
has at least two passive trip points. If there aren't, the governor
refuses to bind to the thermal zone.
This commit relaxes that requirement. Now the governor will bind to all
thermal zones regardless of how many trip points they have.
Cc: Zhang Rui
Cc: Eduardo Valentin
Signed-off-by: Javi Merino
---
Documentation/thermal/power_allocator.txt | 2 +-
drivers/thermal/power_allocator.c | 101 +-
2 files changed, 58 insertions(+), 45 deletions(-)
diff --git a/Documentation/thermal/power_allocator.txt
b/Documentation/thermal/power_allocator.txt
index c3797b529991..a1ce2235f121 100644
--- a/Documentation/thermal/power_allocator.txt
+++ b/Documentation/thermal/power_allocator.txt
@@ -4,7 +4,7 @@ Power allocator governor tunables
Trip points
---
-The governor requires the following two passive trip points:
+The governor works optimally with the following two passive trip points:
1. "switch on" trip point: temperature above which the governor
control loop starts operating. This is the first passive trip
diff --git a/drivers/thermal/power_allocator.c
b/drivers/thermal/power_allocator.c
index 7fa6685f9c5b..06e954cd81cc 100644
--- a/drivers/thermal/power_allocator.c
+++ b/drivers/thermal/power_allocator.c
@@ -24,6 +24,8 @@
#include "thermal_core.h"
+#define INVALID_TRIP -1
+
#define FRAC_BITS 10
#define int_to_frac(x) ((x) << FRAC_BITS)
#define frac_to_int(x) ((x) >> FRAC_BITS)
@@ -61,6 +63,8 @@ static inline s64 div_frac(s64 x, s64 y)
* Used to calculate the derivative term.
* @trip_switch_on:first passive trip point of the thermal zone. The
* governor switches on when this trip point is crossed.
+ * If the thermal zone only has one passive trip point,
+ * @trip_switch_on should be INVALID_TRIP.
* @trip_max_desired_temperature: last passive trip point of the thermal
* zone. The temperature we are
* controlling for.
@@ -432,43 +436,66 @@ unlock:
return ret;
}
-static int get_governor_trips(struct thermal_zone_device *tz,
- struct power_allocator_params *params)
+/**
+ * get_governor_trips() - get the number of the two trip points that are key
for this governor
+ * @tz:thermal zone to operate on
+ * @params:pointer to private data for this governor
+ *
+ * The power allocator governor works optimally with two trips points:
+ * a "switch on" trip point and a "maximum desired temperature". These
+ * are defined as the first and last passive trip points.
+ *
+ * If there is only one trip point, then that's considered to be the
+ * "maximum desired temperature" trip point and the governor is always
+ * on. If there are no passive or active trip points, then the
+ * governor won't do anything. In fact, its throttle function
+ * won't be called at all.
+ */
+static void get_governor_trips(struct thermal_zone_device *tz,
+ struct power_allocator_params *params)
{
- int i, ret, last_passive;
+ int i, last_active, last_passive;
bool found_first_passive;
found_first_passive = false;
- last_passive = -1;
- ret = -EINVAL;
+ last_active = INVALID_TRIP;
+ last_passive = INVALID_TRIP;
for (i = 0; i < tz->trips; i++) {
enum thermal_trip_type type;
+ int ret;
ret = tz->ops->get_trip_type(tz, i, );
- if (ret)
- return ret;
+ if (ret) {
+ dev_warn(>device,
+"Failed to get trip point %d type: %d\n", i,
+ret);
+ continue;
+ }
- if (!found_first_passive) {
- if (type == THERMAL_TRIP_PASSIVE) {
+ if (type == THERMAL_TRIP_PASSIVE) {
+ if (!found_first_passive) {
params->trip_switch_on = i;
found_first_passive = true;
+ } else {
+ last_passive = i;
}
- } else if (type == THERMAL_TRIP_PASSIVE) {
- last_passive = i;
+ } else if (type == THERMAL_TRIP_ACTIVE) {
+ last_active = i;
} else {
break;
}
}
- if (last_passive != -1) {
+ if (last_passive != INVALID_TRIP) {
params->trip_max_desired_temperature = last_passive;
- ret = 0;
+ } else if (found_first_passive) {
+ params->trip_max_desired_temperature = params->trip_switch_on;
+ params->trip_switch_on =
[PATCH v5 1/5] thermal: Add a function to get the minimum power
The thermal core already has a function to get the maximum power of a
cooling device: power_actor_get_max_power(). Add a function to get the
minimum power of a cooling device.
Cc: Zhang Rui
Cc: Eduardo Valentin
Signed-off-by: Javi Merino
---
drivers/thermal/thermal_core.c | 28
include/linux/thermal.h| 6 ++
2 files changed, 34 insertions(+)
diff --git a/drivers/thermal/thermal_core.c b/drivers/thermal/thermal_core.c
index 4ca211be4c0f..760204f0b63c 100644
--- a/drivers/thermal/thermal_core.c
+++ b/drivers/thermal/thermal_core.c
@@ -997,6 +997,34 @@ int power_actor_get_max_power(struct
thermal_cooling_device *cdev,
}
/**
+ * power_actor_get_min_power() - get the mainimum power that a cdev can consume
+ * @cdev: pointer to _cooling_device
+ * @tz:a valid thermal zone device pointer
+ * @min_power: pointer in which to store the minimum power
+ *
+ * Calculate the minimum power consumption in milliwatts that the
+ * cooling device can currently consume and store it in @min_power.
+ *
+ * Return: 0 on success, -EINVAL if @cdev doesn't support the
+ * power_actor API or -E* on other error.
+ */
+int power_actor_get_min_power(struct thermal_cooling_device *cdev,
+ struct thermal_zone_device *tz, u32 *min_power)
+{
+ unsigned long max_state;
+ int ret;
+
+ if (!cdev_is_power_actor(cdev))
+ return -EINVAL;
+
+ ret = cdev->ops->get_max_state(cdev, _state);
+ if (ret)
+ return ret;
+
+ return cdev->ops->state2power(cdev, tz, max_state, min_power);
+}
+
+/**
* power_actor_set_power() - limit the maximum power that a cooling device can
consume
* @cdev: pointer to _cooling_device
* @instance: thermal instance to update
diff --git a/include/linux/thermal.h b/include/linux/thermal.h
index 037e9df2f610..f99d934d373a 100644
--- a/include/linux/thermal.h
+++ b/include/linux/thermal.h
@@ -384,6 +384,8 @@ static inline bool cdev_is_power_actor(struct
thermal_cooling_device *cdev)
int power_actor_get_max_power(struct thermal_cooling_device *,
struct thermal_zone_device *tz, u32 *max_power);
+int power_actor_get_min_power(struct thermal_cooling_device *,
+ struct thermal_zone_device *tz, u32 *min_power);
int power_actor_set_power(struct thermal_cooling_device *,
struct thermal_instance *, u32);
struct thermal_zone_device *thermal_zone_device_register(const char *, int,
int,
@@ -419,6 +421,10 @@ static inline bool cdev_is_power_actor(struct
thermal_cooling_device *cdev)
static inline int power_actor_get_max_power(struct thermal_cooling_device
*cdev,
struct thermal_zone_device *tz, u32 *max_power)
{ return 0; }
+static inline int power_actor_get_min_power(struct thermal_cooling_device
*cdev,
+ struct thermal_zone_device *tz,
+ u32 *min_power)
+{ return -ENODEV; }
static inline int power_actor_set_power(struct thermal_cooling_device *cdev,
struct thermal_instance *tz, u32 power)
{ return 0; }
--
1.9.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 0/4] MIPS: ath79: Add USB support on the TL-WR1043ND
On Tuesday 01 September 2015 17:23:10 Alban Bedel wrote: > > this serie add a driver for the USB phy on the ATH79 SoCs and enable the > USB port on the TL-WR1043ND. The phy controller is really trivial as it > only use reset lines. > Is this a common thing to have? If other PHY devices are like this, we could instead add a simple generic PHY driver that just asserts all its reset lines in the order as provided, rather than making this a hardware specific driver that ends up getting copied several times. Arnd -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH v5 5/5] thermal: power_allocator: exit early if there are no cooling devices
Don't waste cycles in the power allocator governor's throttle function
if there are no cooling devices and exit early.
This commit doesn't change any functionality, but should provide better
performance for the odd case of a thermal zone with trip points but
without cooling devices.
Cc: Zhang Rui
Cc: Eduardo Valentin
Signed-off-by: Javi Merino
---
drivers/thermal/power_allocator.c | 5 +
1 file changed, 5 insertions(+)
diff --git a/drivers/thermal/power_allocator.c
b/drivers/thermal/power_allocator.c
index 78d589e7e65f..8a0d801ed29b 100644
--- a/drivers/thermal/power_allocator.c
+++ b/drivers/thermal/power_allocator.c
@@ -346,6 +346,11 @@ static int allocate_power(struct thermal_zone_device *tz,
}
}
+ if (!num_actors) {
+ ret = -ENODEV;
+ goto unlock;
+ }
+
/*
* We need to allocate five arrays of the same size:
* req_power, max_power, granted_power, extra_actor_power and
--
1.9.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 0/6] sched/fair: Compute capacity invariant load/utilization tracking
On Mon, Sep 07, 2015 at 02:42:20PM +0200, Peter Zijlstra wrote:
> I'm of a mind to apply these patches; with two patches on top, which
> I'll post shortly.
---
Subject: sched: Rename scale()
From: Peter Zijlstra
Date: Mon Sep 7 15:05:42 CEST 2015
Rename scale() to cap_scale() to better reflect its purpose, it is
after all not a general purpose scale function, it has
SCHED_CAPACITY_SHIFT hardcoded in it.
Signed-off-by: Peter Zijlstra (Intel)
---
kernel/sched/fair.c | 14 +++---
1 file changed, 7 insertions(+), 7 deletions(-)
--- a/kernel/sched/fair.c
+++ b/kernel/sched/fair.c
@@ -2515,7 +2515,7 @@ static u32 __compute_runnable_contrib(u6
return contrib + runnable_avg_yN_sum[n];
}
-#define scale(v, s) ((v)*(s) >> SCHED_CAPACITY_SHIFT)
+#define cap_scale(v, s) ((v)*(s) >> SCHED_CAPACITY_SHIFT)
/*
* We can represent the historical contribution to runnable average as the
@@ -2588,7 +2588,7 @@ __update_load_avg(u64 now, int cpu, stru
* period and accrue it.
*/
delta_w = 1024 - delta_w;
- scaled_delta_w = scale(delta_w, scale_freq);
+ scaled_delta_w = cap_scale(delta_w, scale_freq);
if (weight) {
sa->load_sum += weight * scaled_delta_w;
if (cfs_rq) {
@@ -2597,7 +2597,7 @@ __update_load_avg(u64 now, int cpu, stru
}
}
if (running)
- sa->util_sum += scale(scaled_delta_w, scale_cpu);
+ sa->util_sum += cap_scale(scaled_delta_w, scale_cpu);
delta -= delta_w;
@@ -2614,25 +2614,25 @@ __update_load_avg(u64 now, int cpu, stru
/* Efficiently calculate \sum (1..n_period) 1024*y^i */
contrib = __compute_runnable_contrib(periods);
- contrib = scale(contrib, scale_freq);
+ contrib = cap_scale(contrib, scale_freq);
if (weight) {
sa->load_sum += weight * contrib;
if (cfs_rq)
cfs_rq->runnable_load_sum += weight * contrib;
}
if (running)
- sa->util_sum += scale(contrib, scale_cpu);
+ sa->util_sum += cap_scale(contrib, scale_cpu);
}
/* Remainder of delta accrued against u_0` */
- scaled_delta = scale(delta, scale_freq);
+ scaled_delta = cap_scale(delta, scale_freq);
if (weight) {
sa->load_sum += weight * scaled_delta;
if (cfs_rq)
cfs_rq->runnable_load_sum += weight * scaled_delta;
}
if (running)
- sa->util_sum += scale(scaled_delta, scale_cpu);
+ sa->util_sum += cap_scale(scaled_delta, scale_cpu);
sa->period_contrib += delta;
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v5 2/5] thermal: power_allocator: relax the requirement of a sustainable_power in tzp
The power allocator governor currently requires that a sustainable power
is passed as part of the thermal zone's thermal zone parameters. If
that parameter is not provided, it doesn't register with the thermal
zone.
While this parameter is strongly recommended for optimal performance, it
doesn't need to be mandatory. Relax the requirement and allow the
governor to bind to thermal zones that don't provide it by estimating it
from the cooling devices' power model.
Cc: Zhang Rui
Cc: Eduardo Valentin
Signed-off-by: Javi Merino
---
drivers/thermal/power_allocator.c | 125 ++
1 file changed, 100 insertions(+), 25 deletions(-)
diff --git a/drivers/thermal/power_allocator.c
b/drivers/thermal/power_allocator.c
index 251676902869..7fa6685f9c5b 100644
--- a/drivers/thermal/power_allocator.c
+++ b/drivers/thermal/power_allocator.c
@@ -73,6 +73,88 @@ struct power_allocator_params {
};
/**
+ * estimate_sustainable_power() - Estimate the sustainable power of a thermal
zone
+ * @tz: thermal zone we are operating in
+ *
+ * For thermal zones that don't provide a sustainable_power in their
+ * thermal_zone_params, estimate one. Calculate it using the minimum
+ * power of all the cooling devices as that gives a valid value that
+ * can give some degree of functionality. For optimal performance of
+ * this governor, provide a sustainable_power in the thermal zone's
+ * thermal_zone_params.
+ */
+static u32 estimate_sustainable_power(struct thermal_zone_device *tz)
+{
+ u32 sustainable_power = 0;
+ struct thermal_instance *instance;
+ struct power_allocator_params *params = tz->governor_data;
+
+ list_for_each_entry(instance, >thermal_instances, tz_node) {
+ struct thermal_cooling_device *cdev = instance->cdev;
+ u32 min_power;
+
+ if (instance->trip != params->trip_max_desired_temperature)
+ continue;
+
+ if (power_actor_get_min_power(cdev, tz, _power))
+ continue;
+
+ sustainable_power += min_power;
+ }
+
+ return sustainable_power;
+}
+
+/**
+ * estimate_pid_constants() - Estimate the constants for the PID controller
+ * @tz:thermal zone for which to estimate the constants
+ * @sustainable_power: sustainable power for the thermal zone
+ * @trip_switch_on:trip point number for the switch on temperature
+ * @control_temp: target temperature for the power allocator governor
+ * @force: whether to force the update of the constants
+ *
+ * This function is used to update the estimation of the PID
+ * controller constants in struct thermal_zone_parameters.
+ * Sustainable power is provided in case it was estimated. The
+ * estimated sustainable_power should not be stored in the
+ * thermal_zone_parameters so it has to be passed explicitly to this
+ * function.
+ *
+ * If @force is not set, the values in the thermal zone's parameters
+ * are preserved if they are not zero. If @force is set, the values
+ * in thermal zone's parameters are overwritten.
+ */
+static void estimate_pid_constants(struct thermal_zone_device *tz,
+ u32 sustainable_power, int trip_switch_on,
+ unsigned long control_temp, bool force)
+{
+ int ret;
+ unsigned long switch_on_temp;
+ u32 temperature_threshold;
+
+ ret = tz->ops->get_trip_temp(tz, trip_switch_on, _on_temp);
+ if (ret)
+ switch_on_temp = 0;
+
+ temperature_threshold = control_temp - switch_on_temp;
+
+ if (!tz->tzp->k_po || force)
+ tz->tzp->k_po = int_to_frac(sustainable_power) /
+ temperature_threshold;
+
+ if (!tz->tzp->k_pu || force)
+ tz->tzp->k_pu = int_to_frac(2 * sustainable_power) /
+ temperature_threshold;
+
+ if (!tz->tzp->k_i || force)
+ tz->tzp->k_i = int_to_frac(10) / 1000;
+ /*
+* The default for k_d and integral_cutoff is 0, so we can
+* leave them as they are.
+*/
+}
+
+/**
* pid_controller() - PID controller
* @tz:thermal zone we are operating in
* @current_temp: the current temperature in millicelsius
@@ -98,10 +180,20 @@ static u32 pid_controller(struct thermal_zone_device *tz,
{
s64 p, i, d, power_range;
s32 err, max_power_frac;
+ u32 sustainable_power;
struct power_allocator_params *params = tz->governor_data;
max_power_frac = int_to_frac(max_allocatable_power);
+ if (tz->tzp->sustainable_power) {
+ sustainable_power = tz->tzp->sustainable_power;
+ } else {
+ sustainable_power = estimate_sustainable_power(tz);
+ estimate_pid_constants(tz, sustainable_power,
+ params->trip_switch_on, control_temp,
+ true);
+
Re: [PATCH 0/6] sched/fair: Compute capacity invariant load/utilization tracking
On Mon, Sep 07, 2015 at 02:42:20PM +0200, Peter Zijlstra wrote:
> I'm of a mind to apply these patches; with two patches on top, which
> I'll post shortly.
---
Subject: sched: Optimize __update_load_avg()
From: Peter Zijlstra
Date: Mon Sep 7 15:09:15 CEST 2015
Prior to this patch; the line:
scaled_delta_w = (delta_w * 1024) >> 10;
which is the result of the default arch_scale_freq_capacity()
function, turns into:
1b03: 49 89 d1mov%rdx,%r9
1b06: 49 c1 e1 0a shl$0xa,%r9
1b0a: 49 c1 e9 0a shr$0xa,%r9
Which is silly; when made unsigned int, GCC recognises this as
pointless ops and fails to emit them (confirmed on 4.9.3 and 5.1.1).
Furthermore, afaict unsigned is actually the correct type for these
fields anyway, as we've explicitly ruled out negative delta's earlier
in this function.
Signed-off-by: Peter Zijlstra (Intel)
---
kernel/sched/fair.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/kernel/sched/fair.c
+++ b/kernel/sched/fair.c
@@ -2551,7 +2551,7 @@ __update_load_avg(u64 now, int cpu, stru
{
u64 delta, scaled_delta, periods;
u32 contrib;
- int delta_w, scaled_delta_w, decayed = 0;
+ unsigned int delta_w, scaled_delta_w, decayed = 0;
unsigned long scale_freq = arch_scale_freq_capacity(NULL, cpu);
unsigned long scale_cpu = arch_scale_cpu_capacity(NULL, cpu);
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC PATCH v1 2/4] irqchip: GICv3: set non-percpu irqs status with _IRQ_MOVE_PCNTXT
On Mon, 7 Sep 2015, Marc Zyngier wrote:
> On 06/09/15 06:56, Jiang Liu wrote:
> > On 2015/9/6 12:23, Yang Yingliang wrote:
> >> Use irq_settings_set_move_pcntxt() helper irqs status with
> >> _IRQ_MOVE_PCNTXT. So that it can do set affinity when calling
> >> irq_set_affinity_locked().
> > Hi Yingliang,
> > We could only set _IRQ_MOVE_PCNTCT flag to enable migrating
> > IRQ in process context if your hardware platform supports atomically
> > change IRQ configuration. Not sure whether that's true for GICv3.
> > If GICv3 doesn't support atomically change irq configuration, this
> > change may cause trouble.
>
> I think it boils down to what exactly "process context" means here. If
> this means "we do not need to mask the interrupt" while moving it, then
> it should be fine (the GIC architecture guarantees that a pending
> interrupt will be migrated).
>
> Is there any other requirement for this flag?
The history of this flag is as follows:
On x86 interrupts can only be safely migrated while the interrupt is
handled. With the introduction of IRQ remapping this requirement
changed. Remapped interrupts can be migrated in any context.
If you look at irq_set_affinity_locked()
if (irq_can_move_pcntxt(data) {
irq_do_set_affinity(data,...)
chip->irq_set_affinity(data,...);
} else {
irqd_set_move_pending(data);
}
So if IRQ_MOVE_PCNTXT is not set, we handle the migration of the
interrupt from next the interrupt. If it's set set_affinity() is
called right away.
All architectures which do not select GENERIC_PENDING_IRQ are using
the direct method.
Thanks,
tglx
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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/6] sched/fair: Convert arch_scale_cpu_capacity() from weak function to #define
On 04/09/15 08:26, Vincent Guittot wrote:
> On 3 September 2015 at 21:58, Dietmar Eggemann
> wrote:
[...]
>>> So you change the way to declare arch_scale_cpu_capacity but i don't
>>> see the update of the arm arch which declare a
>>> arch_scale_cpu_capacity to reflect this change in your series.
>>
>> We were reluctant to do this because this functionality makes only sense
>> for ARCH=arm big.Little systems w/ cortex-a{15|7} cores and only if the
>> clock-frequency property is set in the dts file.
>
> IMO, we should maintain the compatibility of current implementation
> instead of breaking the link and creating a dead code.
> Your proposal below fits the requirement
The only problem with this solution is that now we got a call to
arch_scale_cpu_capacity() in the hotpath whereas before it is only
called in update_cpu_capacity(). An implementation of
scale_cpu_capacity() in arch/arm/kernel/topology.c leads to a function
call in __update_load_avg. I'm in the middle of doing some performance
tests on TC2 w/ and w/o the cpu invariant implementation.
>
>>
>> Are you planning to push for a 'struct cpu_efficiency/clock-frequency
>> property' solution for ARCH=arm64 as well?
>
> I know that there has been some discussions aorund that but i didn't
> follow the thread in details
>
>>
>> I'm asking because for ARCH=arm64 systems today (JUNO, Hi6220) we use the
>> capacity value of the last entry of the capacity_state vector for the cores
>> (e.g. cortex-a{57|53).
>
> This is a struct of the eas feature ? Not sure that we should link the
> definition of the cpu capacity to an internal struct of a feature; DT
> seems a better way to define it.
Yeah, the cpu invariant functionality should not base on EAS. We just
use the short-cut in EAS RFCv5 to get it working on ARM64.
> So if you want to revisit the way, we set the capacity of CPU for arm
> and/or arm64, I'm fully open to the discussion but this should happen
> in another thread than this one which has for only purpose the
> alignment of the arch_scale_cpu_capacity interface declaration with
> arch_scale_freq_capacity one.
Agreed.
>
> So, with the patch below that updates the arm definition of
> arch_scale_cpu_capacity, you can add my Acked-by: Vincent Guittot
> on this patch and the additional one
> below
>
> Regards,
> Vincent
[...]
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] perf report: Fix invalid memory accessing
On 2015/9/7 20:51, Wang Nan wrote:
[SNIP]
Although theoretically CPU_TOPOLOGY feature should always be selected by
'perf record', I did generate a perf.data without that feature. It has
header like this:
# perf report -i ./bad.perf.data --header-only
#
# captured on: Thu Jan 8 09:30:15 2009
# hostname : localhost
# os release : 3.10.49-gd672fc4
# perf version : 4.2.gc9df
# arch : aarch64
# nrcpus online : 8
# nrcpus avail : 8
# total memory : 1850768 kB
# cmdline : /system/bin/perf record -e sync:sync_timeline -e
kgsl:kgsl_register_event -g -a sleep 5
# event : name = sync:sync_timeline, , id = { 1107, 1108, 1109, 1110, ,
1112 }, type = 2, size = 112, config = 0x3e7, { sample_period, sample_freq } =
1, sample_type = IP|TID|TIME|CALLCHAIN|ID|CPU|PERIOD|RAW, read_format = ID,
disabled = 1, inherit = 1, mmap = 1, comm = 1, task = 1, sample_id_all = 1,
exclude_guest = 1, mmap2 = 1, comm_exec = 1
# event : name = kgsl:kgsl_register_event, , id = { 1113, 1114, 1115, 1116,
1117, 1118 }, type = 2, size = 112, config = 0x350, { sample_period,
sample_freq } = 1, sample_type = IP|TID|TIME|CALLCHAIN|ID|CPU|PERIOD|RAW,
read_format = ID, disabled = 1, inherit = 1, sample_id_all = 1, exclude_guest =
1
# pmu mappings: cpu = 4, software = 1, tracepoint = 2
#
#
It should be:
#
# captured on: Thu Jan 8 11:26:41 2009
...
# HEADER_CPU_TOPOLOGY info available, use -I to display
# pmu mappings: cpu = 4, software = 1, tracepoint = 2
#
However, bad perf.data appears randomly. I can't stably reproduce it, so I
guess there might have another invalid memory accessing.
I found the problem.
perf relies on build_cpu_topology() to fetch CPU_TOPOLOGY from sysfs. It
depend on
the existance of
/sys/devices/system/cpu/cpu%d/topology/core_siblings_list
However, CPU can be canceled by hotcpu subsystem. After that the
directory of
/sys/devices/system/cpu/cpu%d/topology is gone, which causes perf's
write_cpu_topology() --> uild_cpu_topology() to fail, result in the
above perf.data.
So I think my patch is required.
Thank you.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] virtio-gpu: fix compilation warnings
On Mi, 2015-09-02 at 12:30 +0300, Mike Rapoport wrote: > Update snprintf format in virtgpu_fence.c and virtgpu_debugfs.c to fix the > following compilation warnings: > > C [M] drivers/gpu/drm/virtio/virtgpu_fence.o > drivers/gpu/drm/virtio/virtgpu_fence.c: In function > ‘virtio_timeline_value_str’ : > drivers/gpu/drm/virtio/virtgpu_fence.c:64:2: warning: format ‘%lu’ expects > argument of type ‘long unsigned int’, but argument 4 has type ‘long long int’ > [-Wformat=] > snprintf(str, size, "%lu", atomic64_read(>drv->last_seq)); > ^ > CC [M] drivers/gpu/drm/virtio/virtgpu_debugfs.o > drivers/gpu/drm/virtio/virtgpu_debugfs.c: In function > ‘virtio_gpu_debugfs_irq_info’: > drivers/gpu/drm/virtio/virtgpu_debugfs.c:39:6: warning: format ‘%ld’ expects > argument of type ‘long int’, but argument 3 has type ‘long long int’ > [-Wformat=] > vgdev->fence_drv.sync_seq); Doesn't fly. I assume this removes the warnings for 32bit builds, but with the patch applied I get warnings on 64bit builds ... cheers, Gerd -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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] zram: fix possible use after free in zcomp_create()
On (09/07/15 13:53), Luis Henriques wrote:
> > On (09/07/15 11:33), Luis Henriques wrote:
> > > zcomp_create() verifies the success of zcomp_strm_{multi,siggle}_create()
> > > through comp->stream, which can potentially be pointing to memory that was
> > > freed if these functions returned an error.
> > >
> >
> > good catch.
> >
> > we probably better start checking the zcomp_strm_multi_create()/
> > zcomp_strm_single_create() status in zcomp_create(); that's much
> > more obvious and that's why we return it in the first place.
> >
> > what do you think?
> >
>
> Yep, that's probably a better solution.
>
> Acked-by: Luis Henriques
>
Oh, thanks. I don't mind if you will re-submit it; I just did minor
changes to our fix. Or I can handle it. I'm OK with either way. Btw,
did you hit that problem or you reviewed the code?
-ss
> Cheers,
> --
> Luís
>
> > ---
> >
> > drivers/block/zram/zcomp.c | 7 ---
> > 1 file changed, 4 insertions(+), 3 deletions(-)
> >
> > diff --git a/drivers/block/zram/zcomp.c b/drivers/block/zram/zcomp.c
> > index 3456d5a..16bbc8c 100644
> > --- a/drivers/block/zram/zcomp.c
> > +++ b/drivers/block/zram/zcomp.c
> > @@ -360,6 +360,7 @@ struct zcomp *zcomp_create(const char *compress, int
> > max_strm)
> > {
> > struct zcomp *comp;
> > struct zcomp_backend *backend;
> > + int ret;
> >
> > backend = find_backend(compress);
> > if (!backend)
> > @@ -371,10 +372,10 @@ struct zcomp *zcomp_create(const char *compress, int
> > max_strm)
> >
> > comp->backend = backend;
> > if (max_strm > 1)
> > - zcomp_strm_multi_create(comp, max_strm);
> > + ret = zcomp_strm_multi_create(comp, max_strm);
> > else
> > - zcomp_strm_single_create(comp);
> > - if (!comp->stream) {
> > + ret = zcomp_strm_single_create(comp);
> > + if (ret != 0) {
> > kfree(comp);
> > return ERR_PTR(-ENOMEM);
> > }
> >
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] Remove #ifdef CONFIG_64BIT from all asm-generic/fcntl.h
On Mon, 07 Sep 2015 06:16:37 PDT (-0700), a...@arndb.de wrote: > On Tuesday 01 September 2015 17:10:10 Palmer Dabbelt wrote: >> From: Palmer Dabbelt >> >> When working on the RISC-V port I noticed that F_SETLK64 was being >> defined on our 64-bit platform, despite our port being so new that >> we've only ever had the 64-bit file ops. Since there's not compat >> layer for these, this causes fcntl to bail out. >> >> It turns out that one of the ways in with F_SETLK64 was being defined >> (there's some more in glibc, but that's a whole different story... :)) >> is the result of CONFIG_64BIT showing up in this user-visible header. >> confirms this isn't sane, so I replaced it >> with a __BITS_PER_LONG check. >> >> I went ahead and grep'd for any more of these (with >> headers_install_all), and this was the only one I found. >> >> Signed-off-by: Palmer Dabbelt >> Reviewed-by: Andrew Waterman >> Reviewed-by: Albert Ou > > Looks good to me. Are you planning to submit the RISC-V port upstream > any time soon? If so, just keep the patch in your tree and add my > > Acked-by: Arnd Bergmann The RISC-V stuff is still a few months off, that's why I submitted this upstream stand-alone. The supervisor specification isn't 100% set in stone yet, and we're waiting on that before upstreaming anything significant. > However, I did see a lot of similar bugs now that you point me to it: > > $ grep -r \\\ obj-tmp/usr/include/asm-generic/fcntl.h:#ifndef CONFIG_64BIT > obj-tmp/usr/include/asm-generic/mman-common.h:#ifdef > CONFIG_MMAP_ALLOW_UNINITIALIZED > obj-tmp/usr/include/asm-generic/unistd.h:#ifdef CONFIG_MMU > obj-tmp/usr/include/asm-generic/unistd.h:#endif /* CONFIG_MMU */ > obj-tmp/usr/include/linux/atmdev.h:#ifdef CONFIG_COMPAT > obj-tmp/usr/include/linux/elfcore.h:#ifdef CONFIG_BINFMT_ELF_FDPIC > obj-tmp/usr/include/linux/eventpoll.h:#ifdef CONFIG_PM_SLEEP > obj-tmp/usr/include/linux/fb.h:#ifdef CONFIG_FB_BACKLIGHT > obj-tmp/usr/include/linux/flat.h:#ifdef CONFIG_BINFMT_SHARED_FLAT > obj-tmp/usr/include/linux/hw_breakpoint.h:#ifdef > CONFIG_HAVE_MIXED_BREAKPOINTS_REGS > obj-tmp/usr/include/linux/pktcdvd.h:#if defined(CONFIG_CDROM_PKTCDVD_WCACHE) > obj-tmp/usr/include/linux/raw.h:#define MAX_RAW_MINORS CONFIG_MAX_RAW_DEVS > obj-tmp/usr/include/asm/ptrace.h:#ifdef CONFIG_CPU_ENDIAN_BE8 > > These all have the same problem, and we should fix them, as well as > (probably) adding an automated check to scripts/headers_install.sh. Well, I was going to go fix them all and ran a very similar grep, but I think I got a lot of false-positives. If I understand correctly, it's allowed to have CONFIG_* when guarded by __KERNEL__ in user-visible headers? Now that I've written that, I realize it'd be pretty easy to just use cpp to drop everything inside __KERNEL__ and then look for CONFIG_*. If you want, I can try to do that, fix what triggers the check, and re-submit everything together? -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] btrfs: memset cur_trans->delayed_refs to zero
On Mon, Sep 07, 2015 at 02:24:20PM +0200, David Sterba wrote: > On Sun, Sep 06, 2015 at 12:25:27PM +, Alexandru Moise wrote: > > Use memset() to null out the btrfs_delayed_ref_root of > > btrfs_transaction instead of setting all the members to 0 by hand. > > > > Signed-off-by: Alexandru Moise <00moses.alexande...@gmail.com> > > --- > > fs/btrfs/transaction.c | 10 +- > > 1 file changed, 1 insertion(+), 9 deletions(-) > > > > diff --git a/fs/btrfs/transaction.c b/fs/btrfs/transaction.c > > index 8f259b3..faccc1b 100644 > > --- a/fs/btrfs/transaction.c > > +++ b/fs/btrfs/transaction.c > > @@ -224,15 +224,7 @@ loop: > > cur_trans->start_time = get_seconds(); > > cur_trans->dirty_bg_run = 0; > > > > - cur_trans->delayed_refs.href_root = RB_ROOT; > > - cur_trans->delayed_refs.dirty_extent_root = RB_ROOT; > > - atomic_set(_trans->delayed_refs.num_entries, 0); > > Please keep these. Even if it means duplicated setting to 0, it's using > the correct constructor, should it ever change (RB_ROOT) or does some > extra work (atomic_set). Sure, I'll send off another patch right away. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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] btrfs: memset cur_trans->delayed_refs to zero
Use memset() to null out the btrfs_delayed_ref_root of btrfs_transaction instead of setting all the members to 0 by hand. Signed-off-by: Alexandru Moise <00moses.alexande...@gmail.com> --- fs/btrfs/transaction.c | 12 ++-- 1 file changed, 6 insertions(+), 6 deletions(-) diff --git a/fs/btrfs/transaction.c b/fs/btrfs/transaction.c index 8f259b3..0581fb4 100644 --- a/fs/btrfs/transaction.c +++ b/fs/btrfs/transaction.c @@ -224,15 +224,15 @@ loop: cur_trans->start_time = get_seconds(); cur_trans->dirty_bg_run = 0; + memset(_trans->delayed_refs, 0, sizeof(cur_trans->delayed_refs)); + + /* +* For now RB_ROOT means set to NULL but this could change in +* the future +*/ cur_trans->delayed_refs.href_root = RB_ROOT; cur_trans->delayed_refs.dirty_extent_root = RB_ROOT; atomic_set(_trans->delayed_refs.num_entries, 0); - cur_trans->delayed_refs.num_heads_ready = 0; - cur_trans->delayed_refs.pending_csums = 0; - cur_trans->delayed_refs.num_heads = 0; - cur_trans->delayed_refs.flushing = 0; - cur_trans->delayed_refs.run_delayed_start = 0; - cur_trans->delayed_refs.qgroup_to_skip = 0; /* * although the tree mod log is per file system and not per transaction, -- 1.9.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] ath6kl: remove redundant null pointer check on send_pkt
From: Colin Ian King The check for send_pkt being NULL is redundant before the call to htc_reclaim_txctrl_buf, therefore it should be removed. This was detected by static analysis by cppcheck. Signed-off-by: Colin Ian King --- drivers/net/wireless/ath/ath6kl/htc_mbox.c | 4 +--- 1 file changed, 1 insertion(+), 3 deletions(-) diff --git a/drivers/net/wireless/ath/ath6kl/htc_mbox.c b/drivers/net/wireless/ath/ath6kl/htc_mbox.c index e481f14..fffb65b 100644 --- a/drivers/net/wireless/ath/ath6kl/htc_mbox.c +++ b/drivers/net/wireless/ath/ath6kl/htc_mbox.c @@ -1085,9 +1085,7 @@ static int htc_setup_tx_complete(struct htc_target *target) send_pkt->completion = NULL; ath6kl_htc_tx_prep_pkt(send_pkt, 0, 0, 0); status = ath6kl_htc_tx_issue(target, send_pkt); - - if (send_pkt != NULL) - htc_reclaim_txctrl_buf(target, send_pkt); + htc_reclaim_txctrl_buf(target, send_pkt); return status; } -- 2.5.0 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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] fput: don't abuse task_work_add() too much
On 09/07, Oleg Nesterov wrote:
>
> Oh, I disagree. But I guess I can't convince you/Eric/Linus, so I have
> to shut up.
>
>
> Damn. But I can't relax ;) Al, Linus, could you comment the patch below?
>
> Not for inclusion, lacks the changelog/testing, fput() can be simplified.
> But as you can see it is simple. With this patch task_work_add(fput)
> will be called only once by (say) do_exit() path. ->fput_list does not
> need any serialization / atomic ops / etc. Probably we also need to move
> cond_resched() from task_work_run() to fput() after this patch.
>
> Again, it is not that I think this actually makes sense, but since you
> dislike these 275ms...
>
> What do you think?
Yes, task_struct->fput_list is ugly. We can avoid it, but then we need
another ->next pointer in struct file. Perhaps we can reuse ->f_version?
This way the change looks really simple and not too bad to me. Although
I am not sure you will agree.
Oleg.
---
diff --git a/fs/file_table.c b/fs/file_table.c
index 294174d..c34b666 100644
--- a/fs/file_table.c
+++ b/fs/file_table.c
@@ -241,7 +241,15 @@ static void delayed_fput(struct work_struct *unused)
static void fput(struct callback_head *work)
{
- __fput(container_of(work, struct file, f_u.fu_rcuhead));
+ struct file *file = container_of(work, struct file, f_u.fu_rcuhead);
+ struct file *next;
+
+ do {
+ next = file->f_next_put;
+ __fput(file);
+ file = next;
+
+ } while (file);
}
/*
@@ -267,9 +275,21 @@ void fput(struct file *file)
struct task_struct *task = current;
if (likely(!in_interrupt() && !(task->flags & PF_KTHREAD))) {
+ struct callback_head *work =
READ_ONCE(task->task_works);
+ struct file *prev;
+
+ if (work && work->func == fput) {
+ prev = container_of(work, struct file,
f_u.fu_rcuhead);
+ file->f_next_put = prev->f_next_put;
+ prev->f_next_put = file;
+ return;
+ }
+
init_task_work(>f_u.fu_rcuhead, fput);
- if (!task_work_add(task, >f_u.fu_rcuhead, true))
+ if (!task_work_add(task, >f_u.fu_rcuhead, true)) {
+ file->f_next_put = NULL;
return;
+ }
/*
* After this task has run exit_task_work(),
* task_work_add() will fail. Fall through to delayed
diff --git a/include/linux/fs.h b/include/linux/fs.h
index 0774487..9381527 100644
--- a/include/linux/fs.h
+++ b/include/linux/fs.h
@@ -849,7 +849,10 @@ struct file {
const struct cred *f_cred;
struct file_ra_statef_ra;
- u64 f_version;
+ union {
+ u64 f_version;
+ struct file *f_next_put;
+ };
#ifdef CONFIG_SECURITY
void*f_security;
#endif
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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 v6 2/2] devicetree: Add documentation for UPISEMI us5182d ALS and Proximity sensor
Thanks for your feedback, some comments inline.
On 31.08.2015 18:38, Rob Herring wrote:
On Thu, Aug 27, 2015 at 3:23 PM, Jonathan Cameron wrote:
On 20/08/15 11:12, Adriana Reus wrote:
Added entries in i2c/vendor-prefixes for the us5182d als and proximity sensor.
Also added a documentation file for this sensor's properties.
Signed-off-by: Adriana Reus
This isn't that trivial so I'd like some device tree maintainer
input if possible.
It seems fairly reasonable to me. Would other ALS or proximity sensors
need similar properties?
The "glass-coef" is intended to compensate for the material (glass) that
may be covering the sensor if it's integrated in a phone, tablet etc. I
chose 1000 as resolution for this scaling factor (i'll add a more
detailed description). So possibly similar properties could be used for
other als sensors as well.
The last 3 tuning parameters are specific to this particular sensor.
For now I've backed out the driver from my tree (given timing we have
loads of time to sort this out!)
Anyhow, anyone device tree related able to take a look at this.
Adriana, btw these should be cc'd to the device tree maintainers in
the first place (now added).
Jonathan
---
.../devicetree/bindings/iio/light/us5182d.txt | 23 ++
.../devicetree/bindings/vendor-prefixes.txt| 1 +
2 files changed, 24 insertions(+)
create mode 100644 Documentation/devicetree/bindings/iio/light/us5182d.txt
diff --git a/Documentation/devicetree/bindings/iio/light/us5182d.txt
b/Documentation/devicetree/bindings/iio/light/us5182d.txt
new file mode 100644
index 000..7785c56
--- /dev/null
+++ b/Documentation/devicetree/bindings/iio/light/us5182d.txt
@@ -0,0 +1,23 @@
+* UPISEMI us5182d I2C ALS and Proximity sensor
+
+Required properties:
+- compatible: must be "upisemi,usd5182"
+- reg: the I2C address of the device
+
+Optional properties:
Do you expect certain defaults if not present? Some description of how
all these values are determined would be useful.
Yes, if not present they will fall back to default values - the values
in the example.
- the glass-coef one is 1000 by default - so no glass compensation by
default (lux = lux * 1000/1000)
- the others were determined experimentally - by fine tuning starting
from the default values in those registers).
+- upisemi,glass-coef: glass attenuation factor
+- upisemi,dark-ths: array of thresholds (adc counts) corresponding to every
scale
What is the size of the array and valid range of values?
Be specific this is 16-bit property.
Ok, I'll add this info in a following patch set.
+- upisemi,upper-dark-gain: tuning factor(4 int and 4 fractional bits - Q4.4)
applied when light > threshold
+- upisemi,lower-dark-gain: tuning factor(4 int and 4 fractional bits - Q4.4)
applied when light < threshold
Be specific this is an 8-bit property.
ok
+
+Example:
+
+usd5182@39 {
+compatible = "upisemi,usd5182";
+reg = <0x39>;
+upisemi,glass-coef = < 1000 >;
+upisemi,dark-ths = /bits/ 16 <170 200 512 512 800 2000 4000
8000>;
+upisemi,upper-dark-gain = /bits/ 8 <0x00>;
+upisemi,lower-dark-gain = /bits/ 8 <0x16>;
+};
+
diff --git a/Documentation/devicetree/bindings/vendor-prefixes.txt
b/Documentation/devicetree/bindings/vendor-prefixes.txt
index d444757..5b40bab 100644
--- a/Documentation/devicetree/bindings/vendor-prefixes.txt
+++ b/Documentation/devicetree/bindings/vendor-prefixes.txt
@@ -211,6 +211,7 @@ toshiba Toshiba Corporation
toumaz Toumaz
tplink TP-LINK Technologies Co., Ltd.
trulyTruly Semiconductors Limited
+upisemi uPI Semiconductor Corp.
usi Universal Scientific Industrial Co., Ltd.
v3 V3 Semiconductor
varisciteVariscite Ltd.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] btrfs: memset cur_trans->delayed_refs to zero
So, updated patches should mention that in the subject eg: [PATCH v2] btrfs: memset cur_trans->delayed_refs to zero On Mon, Sep 07, 2015 at 04:45:02PM +0300, Alexandru Moise wrote: > Use memset() to null out the btrfs_delayed_ref_root of > btrfs_transaction instead of setting all the members to 0 by hand. > > Signed-off-by: Alexandru Moise <00moses.alexande...@gmail.com> > --- And in this section (ie. after the first ---) put a brief description of the changes. > fs/btrfs/transaction.c | 12 ++-- > 1 file changed, 6 insertions(+), 6 deletions(-) > > diff --git a/fs/btrfs/transaction.c b/fs/btrfs/transaction.c > index 8f259b3..0581fb4 100644 > --- a/fs/btrfs/transaction.c > +++ b/fs/btrfs/transaction.c > @@ -224,15 +224,15 @@ loop: > cur_trans->start_time = get_seconds(); > cur_trans->dirty_bg_run = 0; > > + memset(_trans->delayed_refs, 0, sizeof(cur_trans->delayed_refs)); > + > + /* > + * For now RB_ROOT means set to NULL but this could change in > + * the future > + */ I don't think such comment necessary, the code is clear enough without it. > cur_trans->delayed_refs.href_root = RB_ROOT; > cur_trans->delayed_refs.dirty_extent_root = RB_ROOT; . -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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] sched: fix lose fair sleeper bonus in switch_to_fair()
Please always Cc at least the person who wrote the lines you modify.
On Mon, Sep 07, 2015 at 05:45:20PM +0800, Wanpeng Li wrote:
> The sleeper task will be normalized when moved from fair_sched_class, in
> order that vruntime will be adjusted either the task is running or sleeping
> when moved back. The nomalization in switch_to_fair for sleep task will
> result in lose fair sleeper bonus in place_entity() once the vruntime -
> cfs_rq->min_vruntime is big when moved from fair_sched_class.
>
> This patch fix it by adjusting vruntime just during migrating as original
> codes since the vruntime of the task has usually NOT been normalized in
> this case.
Sorry, I cannot follow that at all. Maybe its me being sleep deprived,
but could you try that again?
> Signed-off-by: Wanpeng Li
> ---
> kernel/sched/fair.c | 11 +++
> 1 files changed, 7 insertions(+), 4 deletions(-)
>
> diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c
> index d26d3b7..eb9aa35 100644
> --- a/kernel/sched/fair.c
> +++ b/kernel/sched/fair.c
> @@ -8005,9 +8005,6 @@ static void attach_task_cfs_rq(struct task_struct *p)
>
> /* Synchronize task with its cfs_rq */
> attach_entity_load_avg(cfs_rq, se);
> -
> - if (!vruntime_normalized(p))
> - se->vruntime += cfs_rq->min_vruntime;
> }
>
> static void switched_from_fair(struct rq *rq, struct task_struct *p)
> @@ -8066,14 +8063,20 @@ void init_cfs_rq(struct cfs_rq *cfs_rq)
> #ifdef CONFIG_FAIR_GROUP_SCHED
> static void task_move_group_fair(struct task_struct *p)
> {
> + struct sched_entity *se = >se;
> + struct cfs_rq *cfs_rq = cfs_rq_of(se);
> +
> detach_task_cfs_rq(p);
> set_task_rq(p, task_cpu(p));
>
> #ifdef CONFIG_SMP
> /* Tell se's cfs_rq has been changed -- migrated */
> - p->se.avg.last_update_time = 0;
> + se->avg.last_update_time = 0;
> #endif
> attach_task_cfs_rq(p);
> +
> + if (!vruntime_normalized(p))
> + se->vruntime += cfs_rq->min_vruntime;
> }
>
> void free_fair_sched_group(struct task_group *tg)
> --
> 1.7.1
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH V2] arm64: add kc_offset_to_vaddr and kc_vaddr_to_offset macro
On Sep 6, 2015, at 1:04 PM, yalin wang wrote: Hello Yalin, > This patch add kc_offset_to_vaddr() and kc_vaddr_to_offset(), > the default version doesn't work on arm64, because arm64 kernel address > is below the PAGE_OFFSET, like module address and vmemmap address are > all below PAGE_OFFSET address. > > Signed-off-by: yalin wang > --- > arch/arm64/include/asm/memory.h | 1 + > arch/arm64/include/asm/pgtable.h | 2 ++ > 2 files changed, 3 insertions(+) > > diff --git a/arch/arm64/include/asm/memory.h b/arch/arm64/include/asm/memory.h > index f800d45..2d09fe8 100644 > --- a/arch/arm64/include/asm/memory.h > +++ b/arch/arm64/include/asm/memory.h > @@ -55,6 +55,7 @@ > #define PCI_IO_START (PCI_IO_END - PCI_IO_SIZE) > #define FIXADDR_TOP (PCI_IO_START - SZ_2M) > #define TASK_SIZE_64 (UL(1) << VA_BITS) > +#define __VIRTUAL_MASK ((1UL << VA_BITS) - 1) According to Catalin's comment, [1], it might need to be rewritten using VA_START in the KASan patches, [2], after this merge window. [1] https://lkml.org/lkml/2015/9/4/529 [2] git://github.com/aryabinin/linux.git kasan/arm64v5 Best Regards Jungseok Lee-- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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] input: fix data race __ps2_command
The data race happens on ps2dev->cmdcnt and ps2dev->cmdbuf contents. __ps2_command reads that data concurrently with the interrupt handler. As the result, for example, if a response arrives just after the timeout, __ps2_command can copy out garbage from ps2dev->cmdbuf but then see that ps2dev->cmdcnt is 0 and return success. Stop the interrupt handler with serio_pause_rx() before reading the results. The data race was found with KernelThreadSanitizer (KTSAN). Signed-off-by: Dmitry Vyukov --- drivers/input/serio/libps2.c | 6 -- 1 file changed, 4 insertions(+), 2 deletions(-) diff --git a/drivers/input/serio/libps2.c b/drivers/input/serio/libps2.c index 7551699..8f93336 100644 --- a/drivers/input/serio/libps2.c +++ b/drivers/input/serio/libps2.c @@ -234,17 +234,19 @@ int __ps2_command(struct ps2dev *ps2dev, unsigned char *param, int command) !(ps2dev->flags & PS2_FLAG_CMD), timeout); } + serio_pause_rx(ps2dev->serio); if (param) for (i = 0; i < receive; i++) param[i] = ps2dev->cmdbuf[(receive - 1) - i]; if (ps2dev->cmdcnt && (command != PS2_CMD_RESET_BAT || ps2dev->cmdcnt != 1)) - goto out; - + goto out_paused; rc = 0; + goto out_paused; out: serio_pause_rx(ps2dev->serio); +out_paused: ps2dev->flags = 0; serio_continue_rx(ps2dev->serio); -- 2.5.0.457.gab17608 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Potential data race in psmouse_interrupt
I've mailed a separate patch that does serio_pause_rx before reading
out data ("input: fix data race __ps2_command").
On Sat, Sep 5, 2015 at 3:21 PM, Dmitry Vyukov wrote:
> On Fri, Sep 4, 2015 at 10:27 PM, Dmitry Torokhov
> wrote:
>> On Fri, Sep 4, 2015 at 12:32 PM, Dmitry Vyukov wrote:
>>> On Fri, Sep 4, 2015 at 6:56 PM, Dmitry Torokhov
>>> wrote:
On Tue, Sep 1, 2015 at 11:46 AM, Dmitry Vyukov wrote:
> On Fri, Aug 28, 2015 at 8:32 PM, Dmitry Torokhov
> wrote:
>> On Fri, Aug 28, 2015 at 11:08 AM, Dmitry Vyukov
>> wrote:
>>> On Fri, Aug 28, 2015 at 7:51 PM, Dmitry Torokhov
>>> wrote:
On Fri, Aug 28, 2015 at 10:34 AM, Dmitry Vyukov
wrote:
> Hello,
>
> I am looking at this code in __ps2_command again:
>
> /*
> * The reset command takes a long time to execute.
> */
> timeout = msecs_to_jiffies(command == PS2_CMD_RESET_BAT ? 4000 : 500);
>
> timeout = wait_event_timeout(ps2dev->wait,
> !(READ_ONCE(ps2dev->flags) & PS2_FLAG_CMD1), timeout);
>
> if (smp_load_acquire(>cmdcnt) &&
> !(smp_load_acquire(>flags) & PS2_FLAG_CMD1)) {
> timeout = ps2_adjust_timeout(ps2dev, command, timeout);
> wait_event_timeout(ps2dev->wait,
> !(smp_load_acquire(>flags) &
> PS2_FLAG_CMD), timeout);
> }
>
> if (param)
> for (i = 0; i < receive; i++)
> param[i] = ps2dev->cmdbuf[(receive - 1) - i];
>
>
> Here are two moments I don't understand:
> 1. The last parameter of ps2_adjust_timeout is timeout in jiffies (it
> is compared against 100ms). However, timeout is assigned to result of
> wait_event_timeout, which returns 0 or 1. This does not make sense to
> me. What am I missing?
The fact that wait_event_timeout can return value greater than one:
* Returns:
* 0 if the @condition evaluated to %false after the @timeout elapsed,
* 1 if the @condition evaluated to %true after the @timeout elapsed,
* or the remaining jiffies (at least 1) if the @condition evaluated
^
>>>
>>>
>>> OK, makes sense now!
>>>
> 2. This code pays great attention to timeouts, but in the end I don't
> see how it handles timeouts. That is, if a timeout is happened, we
> still copyout (garbage) from cmdbuf. What am I missing here?
Once upon a time wait_event() did not return positive value when
timeout expired and then condition satisfied. So we just examine the
final state (psmpouse->cmdcnt should be 0 if command actually
succeeded) and even if we copy in garbage nobody should care since
we'll return error in this case.
>>>
>>>
>>> I see.
>>> But the cmdcnt is re-read after copying out response. So it is
>>> possible that we read garbage response, but then read cmdcnt==0 and
>>> return OK to caller.
>>
>> That assumes that we actually timed out, and while we were copying the
>> data the response finally came.
>
> Right.
>
>>>
>>> So far I have something along the following lines to fix data races in
>>> libps2.c
>>
>> I don't know, maybe we should simply move call to
>> serio_pause_rx(ps2dev->serio) higher, before we check ps2dev->cmdcnt,
>> and move copying of the buffer down, after checking cmdcnt.
>
> I don't know about serio_pause_rx, but copying of response should be
> done after checking cmdcnt.
It will stop the interrupt handler from running while we are examining
the cmdcnt and copy out the data, thus removing the race.
> Also you need to use smp_store_release/smp_load_acquire cmdcnt and
> flags when they have dependent data. And READ_ONCE/WRITE_ONCE on
> shared state otherwise is highly desirable.
>
>>> diff --git a/drivers/input/serio/libps2.c b/drivers/input/serio/libps2.c
>>> index 7551699..51c747f 100644
>>> --- a/drivers/input/serio/libps2.c
>>> +++ b/drivers/input/serio/libps2.c
>>> @@ -43,7 +43,7 @@ int ps2_sendbyte(struct ps2dev *ps2dev, unsigned
>>> char byte, int timeout)
>>>
>>> if (serio_write(ps2dev->serio, byte) == 0)
>>> wait_event_timeout(ps2dev->wait,
>>> - !(ps2dev->flags & PS2_FLAG_ACK),
>>> + !(READ_ONCE(ps2dev->flags) &
>>> PS2_FLAG_ACK),
>>> msecs_to_jiffies(timeout));
>>>
>>> serio_pause_rx(ps2dev->serio);
>>> @@ -187,6 +187,7 @@ int __ps2_command(struct ps2dev *ps2dev, unsigned
>>> char *param, int command)
>>> int receive
RE: [PATCH] x86, arm64, acpi: Handle lapic/x2apic entries in MADT
From: Tomasz Nowicki [mailto:tomasz.nowi...@linaro.org] Sent: Tuesday, September 1, 2015 3:37 PM > On 01.09.2015 14:07, Anaczkowski, Lukasz wrote: >> From: Tomasz Nowicki [mailto:tomasz.nowi...@linaro.org] >> Sent: Tuesday, September 1, 2015 10:03 AM >>> To fix this, each LAPIC/X2APIC entry from MADT table needs to be handled at the same time when processing it, thus adding acpi_subtable_proc structure which stores () ACPI table id () handler that processes table () counter how many items has been processed and passing it to acpi_table_parse_entries(). >> >>> Why can't you leave the parsing code as is and create ApicId sorted list >>> while parsing LAPIC/X2APIC? You could call acpi_register_lapic() after >>> all... Do I miss something ? >> >> Just to make sure I understand correctly - you suggest to replace >> calls to acpi_register_lapic() with a code that builds an APIC ID list while >> parsing LAPIC/X2APIC, and after parsing is done, go thru the list and call >> acpi_register_lapic() on each APIC ID, correct? >> > > Yes, does it work for you? Hi Tomasz, sorry for late response, I was distracted by other things. So, I see two options to build the list: (a) use APIC ID as the table index (b) always append APIC ID to the end of table, in the order that BIOS lists them Also, my goal is to end up with enumeration like this (assuming there's 72 cores, 4 hyper threads each, total 288 logical CPUs): APIC ID ->Logical ID 0 -> 0 1 -> 72 2 -> 144 3 -> 216 4 -> 1 5 -> 73 6 -> 145 7 -> 217 8 -> 2 ... 284 -> 71 285 -> 143 286 -> 215 287 -> 287 Note that n,n+1,n+2,n+3 APIC IDs share same physical core, while being separated by core count in logical listing (e.g. 0,72,144,216 share same physical core). Now, ACPI spec specifies how APIC IDs should be listed: (1) Boot processor is listed first (2) For multi-threaded processors, BIOS should list the first logical processor of each of the individual multi-threaded processors in MADT before listing any of the second logical processors. (3) APIC IDs < 0xFF should be listed in APIC subtable, APIC IDs >= 0xFF should be listed in X2APIC subtable Keeping in mind above, BIOS lists APIC IDs as: APIC (0,4,8, .., 252) X2APIC (256,260,264, .. 284) APIC (1,5,9,...,253) X2API (257,261,265, 285) etc so in the end (2) rule is followed. So, when (a) indexing is selected, mapping will be like: APIC ID -> Logical ID 0 ->0 1 ->1 2 ->2 3 ->3 ... 287 ->287 If (b) indexing is selected, mapping is like: APIC ID ->Logical ID 0 -> 0 1 -> 63 2 -> 126 3 -> 189 4 -> 1 5 -> 64 ... 284-> 256 285-> 266 286-> 276 287-> 286 Why? Because first APIC entries will be in the list (since this is the first parser to run), and just then X2APIC entries will be in the list. So, long story short, unless you see other simple option on how to build the list of APIC IDs, I'm sorry to say that this approach will not work. Cheers, Lukasz -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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 0/6] kselftest improvement and cleanup
This is my second attempt for improving the kselftest for arm/arm64 architecture. Eventually, we hope we could build(in an cross compile environment) and run all the kselftest cases automatically(successful of courses). The first version is here[1]. In this series, I try to make all the testcases compiling and installation successful. The status of these series patches as follows: c 9fae100 selftests: breakpoints: fix installing error on the architecture except x86 c a7d0f07 selftests: check before install a 7824b26 selftests: rename jump label to static_keys a f93be76 selftests: only compile userfaultfd for x86 and powperpc 8ec8722 selftests: mqueue: allow extra cflags d5babcb selftests: mqueue: simpification the Makefile e2fe790 selftests: change install command to rsync 2becd5b selftests: exec: simpification the Makefile "c" means committed by Shuah Khan "a" means acked by Shuah Khan [1] http://www.spinics.net/lists/kernel/msg2056987.html Bamvor Jian Zhang (6): selftests: rename jump label to static_keys selftests: only compile userfaultfd for x86 and powperpc selftests: mqueue: allow extra cflags selftests: mqueue: simpification the Makefile selftests: change install command to rsync selftests: exec: simpification the Makefile tools/testing/selftests/Makefile| 2 +- tools/testing/selftests/exec/Makefile | 4 +--- tools/testing/selftests/ftrace/Makefile | 2 +- tools/testing/selftests/lib.mk | 11 --- tools/testing/selftests/mqueue/Makefile | 7 +++ tools/testing/selftests/vm/Makefile | 12 6 files changed, 22 insertions(+), 16 deletions(-) -- 2.1.4 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH v2 2/6] selftests: only compile userfaultfd for x86 and powperpc
Check it before compiling to avoid the failure of building and installation. Signed-off-by: Bamvor Jian Zhang --- tools/testing/selftests/vm/Makefile | 12 1 file changed, 12 insertions(+) diff --git a/tools/testing/selftests/vm/Makefile b/tools/testing/selftests/vm/Makefile index 1dacac8..925a82d 100644 --- a/tools/testing/selftests/vm/Makefile +++ b/tools/testing/selftests/vm/Makefile @@ -1,5 +1,15 @@ # Makefile for vm selftests +uname_M := $(shell uname -m 2>/dev/null || echo not) +ARCH ?= $(shell echo $(uname_M) | sed -e s/i.86/i386/ -e s/ppc.*/powerpc/) + +ifeq ($(ARCH),powerpc) +support_userfaultfd = yes +endif +ifeq ($(ARCH),x86) +support_userfaultfd = yes +endif + CFLAGS = -Wall -I ../../../../usr/include $(EXTRA_CFLAGS) BINARIES = compaction_test BINARIES += hugepage-mmap @@ -9,7 +19,9 @@ BINARIES += mlock2-tests BINARIES += on-fault-limit BINARIES += thuge-gen BINARIES += transhuge-stress +ifdef support_userfaultfd BINARIES += userfaultfd +endif all: $(BINARIES) %: %.c -- 2.1.4 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH v2 3/6] selftests: mqueue: allow extra cflags
change from = to += in order to pass the proper headers and librareis (popt.h and libpopt.so) in order to build successful in cross compiling. Suggested-by: Michael Ellermani Signed-off-by: Bamvor Jian Zhang --- tools/testing/selftests/mqueue/Makefile | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/tools/testing/selftests/mqueue/Makefile b/tools/testing/selftests/mqueue/Makefile index 0e3b41e..ca8327f 100644 --- a/tools/testing/selftests/mqueue/Makefile +++ b/tools/testing/selftests/mqueue/Makefile @@ -1,4 +1,4 @@ -CFLAGS = -O2 +CFLAGS += -O2 all: $(CC) $(CFLAGS) mq_open_tests.c -o mq_open_tests -lrt -- 2.1.4 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH v2 4/6] selftests: mqueue: simpification the Makefile
Suggested-by: Michael Ellermani Signed-off-by: Bamvor Jian Zhang --- tools/testing/selftests/mqueue/Makefile | 5 ++--- 1 file changed, 2 insertions(+), 3 deletions(-) diff --git a/tools/testing/selftests/mqueue/Makefile b/tools/testing/selftests/mqueue/Makefile index ca8327f..9f51aaa 100644 --- a/tools/testing/selftests/mqueue/Makefile +++ b/tools/testing/selftests/mqueue/Makefile @@ -1,8 +1,7 @@ CFLAGS += -O2 +LDLIBS = -lrt -lpthread -lpopt -all: - $(CC) $(CFLAGS) mq_open_tests.c -o mq_open_tests -lrt - $(CC) $(CFLAGS) -o mq_perf_tests mq_perf_tests.c -lrt -lpthread -lpopt +all: mq_open_tests mq_perf_tests include ../lib.mk -- 2.1.4 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH v2 1/6] selftests: rename jump label to static_keys
commit "2bf9e0a locking/static_keys: Provide a selftest" rename jump_label directory to static_keys. Signed-off-by: Bamvor Jian Zhang --- tools/testing/selftests/Makefile | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/tools/testing/selftests/Makefile b/tools/testing/selftests/Makefile index ac40ec9..8922c21 100644 --- a/tools/testing/selftests/Makefile +++ b/tools/testing/selftests/Makefile @@ -17,12 +17,12 @@ TARGETS += powerpc TARGETS += ptrace TARGETS += seccomp TARGETS += size +TARGETS += static_keys TARGETS += sysctl ifneq (1, $(quicktest)) TARGETS += timers endif TARGETS += user -TARGETS += jumplabel TARGETS += vm TARGETS += x86 TARGETS += zram -- 2.1.4 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH v2 6/6] selftests: exec: simpification the Makefile
With the previous patch, the installation method change from install
to rsync. There is not no need to create subdir during test, the
default RUN_TESTS is enough.
This patch implicitly revert commit 84cbd9e4 ("selftests/exec: do not
install subdir as it is already created").
Suggested-by: Michael Ellerman
Signed-off-by: Bamvor Jian Zhang
---
tools/testing/selftests/exec/Makefile | 4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
diff --git a/tools/testing/selftests/exec/Makefile
b/tools/testing/selftests/exec/Makefile
index 6b76bfd..4e400eb 100644
--- a/tools/testing/selftests/exec/Makefile
+++ b/tools/testing/selftests/exec/Makefile
@@ -1,6 +1,6 @@
CFLAGS = -Wall
BINARIES = execveat
-DEPS = execveat.symlink execveat.denatured script
+DEPS = execveat.symlink execveat.denatured script subdir
all: $(BINARIES) $(DEPS)
subdir:
@@ -22,7 +22,5 @@ TEST_FILES := $(DEPS)
include ../lib.mk
-override EMIT_TESTS := echo "mkdir -p subdir; (./execveat && echo \"selftests:
execveat [PASS]\") || echo \"selftests: execveat [FAIL]\""
-
clean:
rm -rf $(BINARIES) $(DEPS) subdir.moved execveat.moved x*
--
2.1.4
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v2 5/6] selftests: change install command to rsync
The command of install could not handle the special files in exec
testcases, change the default rule to rsync to fix this.
The result of installation is unchanged after this commit.
Suggested-by: Michael Ellerman
Signed-off-by: Bamvor Jian Zhang
---
tools/testing/selftests/ftrace/Makefile | 2 +-
tools/testing/selftests/lib.mk | 11 ---
2 files changed, 5 insertions(+), 8 deletions(-)
diff --git a/tools/testing/selftests/ftrace/Makefile
b/tools/testing/selftests/ftrace/Makefile
index 0acbeca..4e6ed13 100644
--- a/tools/testing/selftests/ftrace/Makefile
+++ b/tools/testing/selftests/ftrace/Makefile
@@ -1,7 +1,7 @@
all:
TEST_PROGS := ftracetest
-TEST_DIRS := test.d/
+TEST_DIRS := test.d
include ../lib.mk
diff --git a/tools/testing/selftests/lib.mk b/tools/testing/selftests/lib.mk
index 97f1c67..50a93f5 100644
--- a/tools/testing/selftests/lib.mk
+++ b/tools/testing/selftests/lib.mk
@@ -12,13 +12,10 @@ run_tests: all
$(RUN_TESTS)
define INSTALL_RULE
- @if [ "X$(TEST_PROGS)$(TEST_PROGS_EXTENDED)$(TEST_FILES)" != "X" ];
then\
- mkdir -p $(INSTALL_PATH);
\
- for TEST_DIR in $(TEST_DIRS); do
\
- cp -r $$TEST_DIR $(INSTALL_PATH);
\
- done;
\
- echo "install -t $(INSTALL_PATH) $(TEST_PROGS)
$(TEST_PROGS_EXTENDED) $(TEST_FILES)"; \
- install -t $(INSTALL_PATH) $(TEST_PROGS) $(TEST_PROGS_EXTENDED)
$(TEST_FILES); \
+ @if [ "X$(TEST_PROGS)$(TEST_PROGS_EXTENDED)$(TEST_FILES)" != "X" ];
then\
+ mkdir -p ${INSTALL_PATH};
\
+ echo "rsync -a $(TEST_DIRS) $(TEST_PROGS)
$(TEST_PROGS_EXTENDED) $(TEST_FILES) $(INSTALL_PATH)/"; \
+ rsync -a $(TEST_DIRS) $(TEST_PROGS) $(TEST_PROGS_EXTENDED)
$(TEST_FILES) $(INSTALL_PATH)/; \
fi
endef
--
2.1.4
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v2 0/2] leds: leds-ipaq-micro: Use resource managed functions and fix coding style.
Hi, Based on the suggestion from Jaeck, the orginal patch is split into two, one patch fixes the coding style issues, and the other uses resource managed function, devm_led_classdev_register. Muhammad Falak R Wani (2): leds: leds-ipaq-micro: Use devm_led_classdev_register leds: leds-ipaq-micro: Fix coding style issues drivers/leds/leds-ipaq-micro.c | 47 ++ 1 file changed, 20 insertions(+), 27 deletions(-) -- 1.9.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: [V9fs-developer] [PATCH] 9p: trans_fd, initialize recv fcall properly if not set
I thought the nature of trans_fd would have prevented any sort of true zero copy, but I suppose one less is always welcome :) -eric On Sun, Sep 6, 2015 at 1:55 AM, Dominique Martinet wrote: > Eric Van Hensbergen wrote on Sat, Sep 05, 2015: >> On Thu, Sep 3, 2015 at 4:38 AM, Dominique Martinet >> wrote: >> > To be honest, I think it might be better to just bail out if we get in >> > this switch (m->req->rc == NULL after p9_tag_lookup) and not try to >> > allocate more, because if we get there it's likely a race condition and >> > silently re-allocating will end up in more troubles than trying to >> > recover is worth. >> > Thoughts ? >> > >> >> Hmmm...trying to rattle my brain and remember why I put it in there >> back in 2008. >> It might have just been over-defensive programming -- or more likely it just >> pre-dated all the zero copy infrastructure which pretty much guaranteed we >> had >> an rc allocated and what is there is vestigial. I'm happy to accept a >> patch which >> makes this an assert, or perhaps just resets the connection because something >> has gone horribly wrong (similar to the ENOMEM path that is there now). > > Yeah, it looks like the safety comes from the zero-copy stuff that came > much later. > Let's go with resetting the connection then. Hmm. EIO is a bit too > generic so would be good to avoid that if possible, but can't think of > anything better... > > > Speaking of zero-copy, I believe it should be fairly straight-forward to > implement for trans_fd now I've actually looked at it, since we do the > payload read after a p9_tag_lookup, would just need m->req to point to a > zc buffer. Write is similar, if there's a zc buffer just send it after > the header. > The cost is a couple more pointers in req and an extra if in both > workers, that seems pretty reasonable. > > Well, I'm not using trans_fd much here (and unfortunately zero-copy > isn't possible at all given the transport protocol for RDMA, at least > for recv), but if anyone cares it probably could be done without too > much hassle for the fd workers. > > -- > Dominique -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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] leds: leds-ipaq-micro: Fix coding style issues
Spaces at the starting of a line are removed, indentation
using tab, instead of space. Also, warnings related to
line width of more than 80 characters is also taken care of.
Two warnings have been left alone to aid better readability.
Signed-off-by: Muhammad Falak R Wani
---
drivers/leds/leds-ipaq-micro.c | 38 +++---
1 file changed, 19 insertions(+), 19 deletions(-)
diff --git a/drivers/leds/leds-ipaq-micro.c b/drivers/leds/leds-ipaq-micro.c
index 1206215..86716ea 100644
--- a/drivers/leds/leds-ipaq-micro.c
+++ b/drivers/leds/leds-ipaq-micro.c
@@ -16,9 +16,9 @@
#define LED_YELLOW 0x00
#define LED_GREEN 0x01
-#define LED_EN (1 << 4)/* LED ON/OFF 0:off, 1:on
*/
-#define LED_AUTOSTOP(1 << 5)/* LED ON/OFF auto stop set 0:disable,
1:enable */
-#define LED_ALWAYS (1 << 6)/* LED Interrupt Mask 0:No mask,
1:mask */
+#define LED_EN (1 << 4) /* LED ON/OFF 0:off, 1:on */
+#define LED_AUTOSTOP (1 << 5) /* LED ON/OFF auto stop set 0:disable,1:enable*/
+#define LED_ALWAYS(1 << 6) /* LED Interrupt Mask 0:No mask, 1:mask */
static void micro_leds_brightness_set(struct led_classdev *led_cdev,
enum led_brightness value)
@@ -27,14 +27,14 @@ static void micro_leds_brightness_set(struct led_classdev
*led_cdev,
/*
* In this message:
* Byte 0 = LED color: 0 = yellow, 1 = green
-* yellow LED is always ~30 blinks per minute
+*yellow LED is always ~30 blinks per minute
* Byte 1 = duration (flags?) appears to be ignored
* Byte 2 = green ontime in 1/10 sec (deciseconds)
-* 1 = 1/10 second
-* 0 = 256/10 second
+*1 = 1/10 second
+*0 = 256/10 second
* Byte 3 = green offtime in 1/10 sec (deciseconds)
-* 1 = 1/10 second
-* 0 = 256/10 seconds
+*1 = 1/10 second
+*0 = 256/10 seconds
*/
struct ipaq_micro_msg msg = {
.id = MSG_NOTIFY_LED,
@@ -64,14 +64,14 @@ static int micro_leds_blink_set(struct led_classdev
*led_cdev,
/*
* In this message:
* Byte 0 = LED color: 0 = yellow, 1 = green
-* yellow LED is always ~30 blinks per minute
+*yellow LED is always ~30 blinks per minute
* Byte 1 = duration (flags?) appears to be ignored
* Byte 2 = green ontime in 1/10 sec (deciseconds)
-* 1 = 1/10 second
-* 0 = 256/10 second
+*1 = 1/10 second
+*0 = 256/10 second
* Byte 3 = green offtime in 1/10 sec (deciseconds)
-* 1 = 1/10 second
-* 0 = 256/10 seconds
+*1 = 1/10 second
+*0 = 256/10 seconds
*/
struct ipaq_micro_msg msg = {
.id = MSG_NOTIFY_LED,
@@ -79,14 +79,14 @@ static int micro_leds_blink_set(struct led_classdev
*led_cdev,
};
msg.tx_data[0] = LED_GREEN;
-if (*delay_on > IPAQ_LED_MAX_DUTY ||
+ if (*delay_on > IPAQ_LED_MAX_DUTY ||
*delay_off > IPAQ_LED_MAX_DUTY)
-return -EINVAL;
+ return -EINVAL;
-if (*delay_on == 0 && *delay_off == 0) {
-*delay_on = 100;
-*delay_off = 100;
-}
+ if (*delay_on == 0 && *delay_off == 0) {
+ *delay_on = 100;
+ *delay_off = 100;
+ }
msg.tx_data[1] = 0;
if (*delay_on >= IPAQ_LED_MAX_DUTY)
--
1.9.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] leds: leds-ipaq-micro: Use devm_led_classdev_register
Use of resource-managed function devm_led_classdev_register
instead of led_classdev_register is preferred, consequently
remove redundant function micro_leds_remove.
Signed-off-by: Muhammad Falak R Wani
---
drivers/leds/leds-ipaq-micro.c | 9 +
1 file changed, 1 insertion(+), 8 deletions(-)
diff --git a/drivers/leds/leds-ipaq-micro.c b/drivers/leds/leds-ipaq-micro.c
index 3776f51..1206215 100644
--- a/drivers/leds/leds-ipaq-micro.c
+++ b/drivers/leds/leds-ipaq-micro.c
@@ -111,7 +111,7 @@ static int micro_leds_probe(struct platform_device *pdev)
{
int ret;
- ret = led_classdev_register(>dev, _led);
+ ret = devm_led_classdev_register(>dev, _led);
if (ret) {
dev_err(>dev, "registering led failed: %d\n", ret);
return ret;
@@ -121,18 +121,11 @@ static int micro_leds_probe(struct platform_device *pdev)
return 0;
}
-static int micro_leds_remove(struct platform_device *pdev)
-{
- led_classdev_unregister(_led);
- return 0;
-}
-
static struct platform_driver micro_leds_device_driver = {
.driver = {
.name= "ipaq-micro-leds",
},
.probe = micro_leds_probe,
- .remove = micro_leds_remove,
};
module_platform_driver(micro_leds_device_driver);
--
1.9.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 4/5] [media] uvcvideo: create pad links after subdev registration
Hello,
On 09/03/2015 06:00 PM, Javier Martinez Canillas wrote:
> The uvc driver creates the pads links before the media entity is
> registered with the media device. This doesn't work now that obj
> IDs are used to create links so the media_device has to be set.
>
> Move entities registration logic before pads links creation.
>
> Signed-off-by: Javier Martinez Canillas
> ---
>
> drivers/media/usb/uvc/uvc_entity.c | 16
> 1 file changed, 12 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/media/usb/uvc/uvc_entity.c
> b/drivers/media/usb/uvc/uvc_entity.c
> index 429e428ccd93..9dde1f86cc4b 100644
> --- a/drivers/media/usb/uvc/uvc_entity.c
> +++ b/drivers/media/usb/uvc/uvc_entity.c
> @@ -37,6 +37,10 @@ static int uvc_mc_register_entity(struct uvc_video_chain
> *chain,
> if (sink == NULL)
> return 0;
>
> + ret = v4l2_device_register_subdev(>dev->vdev, >subdev);
Testing this patch on an Exynos Chromebook that has a built-in USB camera, I
noticed that v4l2_device_register_subdev() was wrongly called for UVC entities
with UVC_ENTITY_TYPE() == UVC_TT_STREAMING.
So I have the following [0] v2 patch. This patch was tested on an Exynos5800
Peach Pi Chromebook using qv4l2 to test video capture and the output of the
media-ctl -p command was compared with and without the MC next gen patches
to verify that was identical in both cases.
The media-ctl -p output is: http://hastebin.com/enalitofoz.coffee
And the mc_next_gen -e -i -I -l output is http://hastebin.com/umevuragaq.pas
Normally I would just resend the complete series but since there are so many
in-flight patches, I preferred to only re-send this patch one in this thread.
Best regards,
--
Javier Martinez Canillas
Open Source Group
Samsung Research America
[0]:
>From 8be356e77eeefdc5c0738dd429205f3398c5b76c Mon Sep 17 00:00:00 2001
From: Javier Martinez Canillas
Date: Thu, 3 Sep 2015 13:46:06 +0200
Subject: [PATCH v2 4/5] [media] uvcvideo: create pad links after subdev
registration
The uvc driver creates the pads links before the media entity is
registered with the media device. This doesn't work now that obj
IDs are used to create links so the media_device has to be set.
Move entities registration logic before pads links creation.
Signed-off-by: Javier Martinez Canillas
---
Changes since v1:
- Don't try to register a UVC entity subdev for type UVC_TT_STREAMING.
drivers/media/usb/uvc/uvc_entity.c | 23 +++
1 file changed, 19 insertions(+), 4 deletions(-)
diff --git a/drivers/media/usb/uvc/uvc_entity.c
b/drivers/media/usb/uvc/uvc_entity.c
index 429e428ccd93..7f82b65b238e 100644
--- a/drivers/media/usb/uvc/uvc_entity.c
+++ b/drivers/media/usb/uvc/uvc_entity.c
@@ -26,6 +26,15 @@
static int uvc_mc_register_entity(struct uvc_video_chain *chain,
struct uvc_entity *entity)
{
+ if (UVC_ENTITY_TYPE(entity) == UVC_TT_STREAMING)
+ return 0;
+
+ return v4l2_device_register_subdev(>dev->vdev, >subdev);
+}
+
+static int uvc_mc_create_pads_links(struct uvc_video_chain *chain,
+ struct uvc_entity *entity)
+{
const u32 flags = MEDIA_LNK_FL_ENABLED | MEDIA_LNK_FL_IMMUTABLE;
struct media_entity *sink;
unsigned int i;
@@ -62,10 +71,7 @@ static int uvc_mc_register_entity(struct uvc_video_chain
*chain,
return ret;
}
- if (UVC_ENTITY_TYPE(entity) == UVC_TT_STREAMING)
- return 0;
-
- return v4l2_device_register_subdev(>dev->vdev, >subdev);
+ return 0;
}
static struct v4l2_subdev_ops uvc_subdev_ops = {
@@ -124,5 +130,14 @@ int uvc_mc_register_entities(struct uvc_video_chain *chain)
}
}
+ list_for_each_entry(entity, >entities, chain) {
+ ret = uvc_mc_create_pads_links(chain, entity);
+ if (ret < 0) {
+ uvc_printk(KERN_INFO, "Failed to create pads links for "
+ "entity %u\n", entity->id);
+ return ret;
+ }
+ }
+
return 0;
}
--
2.4.3
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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 2/3] arm64: Introduce IRQ stack
On Sep 5, 2015, at 2:12 AM, Alexnader Kuleshov wrote: > Hello Jungseok, Hello Alexnader, > On 09-04-15, Jungseok Lee wrote: >> +config IRQ_STACK >> +bool "Use separate kernel stack when handling interrupts" >> +depends on ARM64_4K_PAGES >> +help >> + Say Y here if you want to use separate kernel stack to handle both >> + hard and soft interrupts. As reduceing memory footprint regarding >> + kernel stack, it benefits low memory platforms. > > s/reduceing/reducing Thanks for pointing out the typo. I will update the help message in the next version. Best Regards Jungseok Lee -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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] zram: fix possible use after free in zcomp_create()
On Mon, Sep 07, 2015 at 10:33:32PM +0900, Sergey Senozhatsky wrote:
> On (09/07/15 13:53), Luis Henriques wrote:
> > > On (09/07/15 11:33), Luis Henriques wrote:
> > > > zcomp_create() verifies the success of
> > > > zcomp_strm_{multi,siggle}_create()
> > > > through comp->stream, which can potentially be pointing to memory that
> > > > was
> > > > freed if these functions returned an error.
> > > >
> > >
> > > good catch.
> > >
> > > we probably better start checking the zcomp_strm_multi_create()/
> > > zcomp_strm_single_create() status in zcomp_create(); that's much
> > > more obvious and that's why we return it in the first place.
> > >
> > > what do you think?
> > >
> >
> > Yep, that's probably a better solution.
> >
> > Acked-by: Luis Henriques
> >
>
> Oh, thanks. I don't mind if you will re-submit it; I just did minor
> changes to our fix. Or I can handle it. I'm OK with either way.
Ok, I'll be sending v2 in a minute.
>Btw, did you hit that problem or you reviewed the code?
>
I've found this while looking at the code (I wouldn't really call it a
"code review"... :-))
Cheers,
--
Luís
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] char: remove unused variable res to clean up build warning
From: Colin Ian King
Commit f368ed6088ae9 ("char: make misc_deregister a void function")
did not remove unused variable res and now we get a build warning:
drivers/rtc/rtc-ds1374.c: In function 'ds1374_remove':
drivers/rtc/rtc-ds1374.c:667:6: warning: unused variable 'res'
[-Wunused-variable]
int res;
simply remove this unused variable.
Signed-off-by: Colin Ian King
---
drivers/rtc/rtc-ds1374.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/drivers/rtc/rtc-ds1374.c b/drivers/rtc/rtc-ds1374.c
index 72c9333..36b1b84 100644
--- a/drivers/rtc/rtc-ds1374.c
+++ b/drivers/rtc/rtc-ds1374.c
@@ -663,9 +663,8 @@ static int ds1374_probe(struct i2c_client *client,
static int ds1374_remove(struct i2c_client *client)
{
struct ds1374 *ds1374 = i2c_get_clientdata(client);
-#ifdef CONFIG_RTC_DRV_DS1374_WDT
- int res;
+#ifdef CONFIG_RTC_DRV_DS1374_WDT
misc_deregister(_miscdev);
ds1374_miscdev.parent = NULL;
unregister_reboot_notifier(_wdt_notifier);
--
2.5.0
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] zram: fix possible use after free in zcomp_create()
zcomp_create() verifies the success of zcomp_strm_{multi,siggle}_create()
through comp->stream, which can potentially be pointing to memory that was
freed if these functions returned an error.
Fixes: beca3ec71fe5 ("zram: add multi stream functionality")
Cc: sta...@vger.kernel.org
Signed-off-by: Luis Henriques
---
Changes since v1:
* Check zcomp_strm_{multi,siggle}_create() return code instead
comp->stream (suggested by Sergey)
drivers/block/zram/zcomp.c | 7 ---
1 file changed, 4 insertions(+), 3 deletions(-)
diff --git a/drivers/block/zram/zcomp.c b/drivers/block/zram/zcomp.c
index 965d1afb0eaa..8d2cdfd307db 100644
--- a/drivers/block/zram/zcomp.c
+++ b/drivers/block/zram/zcomp.c
@@ -336,6 +336,7 @@ struct zcomp *zcomp_create(const char *compress, int
max_strm)
{
struct zcomp *comp;
struct zcomp_backend *backend;
+ int ret;
backend = find_backend(compress);
if (!backend)
@@ -347,10 +348,10 @@ struct zcomp *zcomp_create(const char *compress, int
max_strm)
comp->backend = backend;
if (max_strm > 1)
- zcomp_strm_multi_create(comp, max_strm);
+ ret = zcomp_strm_multi_create(comp, max_strm);
else
- zcomp_strm_single_create(comp);
- if (!comp->stream) {
+ ret = zcomp_strm_single_create(comp);
+ if (ret) {
kfree(comp);
return ERR_PTR(-ENOMEM);
}
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] [s390]: Use .rept directive to store/load fpu registers
On Tue, Sep 01, 2015 at 09:51:32AM +0200, Christian Borntraeger wrote: > Am 28.08.2015 um 15:49 schrieb Alexander Kuleshov: > > arch/s390/kernel/swsusp.S | 49 > > --- > > 1 file changed, 17 insertions(+), 32 deletions(-) > > > > diff --git a/arch/s390/kernel/swsusp.S b/arch/s390/kernel/swsusp.S > > index ca62946..8011e14 100644 > > --- a/arch/s390/kernel/swsusp.S > > +++ b/arch/s390/kernel/swsusp.S > > @@ -48,22 +48,15 @@ ENTRY(swsusp_arch_suspend) > > /* Store registers */ > > mvc 0x318(4,%r1),__SF_EMPTY(%r15) /* move prefix to lowcore */ > > stfpc 0x31c(%r1) /* store fpu control */ > > - std 0,0x200(%r1)/* store f0 */ > > - std 1,0x208(%r1)/* store f1 */ > > - std 2,0x210(%r1)/* store f2 */ > > - std 3,0x218(%r1)/* store f3 */ > > - std 4,0x220(%r1)/* store f4 */ > > - std 5,0x228(%r1)/* store f5 */ > > - std 6,0x230(%r1)/* store f6 */ > > - std 7,0x238(%r1)/* store f7 */ > > - std 8,0x240(%r1)/* store f8 */ > > - std 9,0x248(%r1)/* store f9 */ > > - std 10,0x250(%r1) /* store f10 */ > > - std 11,0x258(%r1) /* store f11 */ > > - std 12,0x260(%r1) /* store f12 */ > > - std 13,0x268(%r1) /* store f13 */ > > - std 14,0x270(%r1) /* store f14 */ > > - std 15,0x278(%r1) /* store f15 */ > > + > > + /* store f0..f15 floating point registers */ > > + .set i, 0 > > + .set f, 0x200 > > + .rept 16 > > + std i, f(%r1) > > + .set i, (i+1) > > + .set f, (f+0x8) > > + .endr > > I personally find the existing code easier to read, especially as it matches > the > assembler output and I can directly where the slots are, (e.g. f11 is 0x258) Yes, I agree with Christian. Let's keep the code as it is. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] leds:lp55xx: Correct Kconfig dependency for f/w user helper
Hi Takashi,
Thanks for chasing this.
Milo, could you express your opinion?
On 09/07/2015 02:25 PM, Takashi Iwai wrote:
The commit [b67893206fc0: leds:lp55xx: fix firmware loading error]
tries to address the firmware file handling with user helper, but it
sets a wrong Kconfig CONFIG_FW_LOADER_USER_HELPER_FALLBACK. Since the
wrong option was enabled, the system got a regression -- it suffers
from the unexpected long delays for non-present firmware files.
This patch corrects the Kconfig dependency to the right one,
CONFIG_FW_LOADER_USER_HELPER. This doesn't change the fallback
behavior but only enables UMH when needed.
Bugzilla: https://bugzilla.opensuse.org/show_bug.cgi?id=944661
Fixes: b67893206fc0 ('leds:lp55xx: fix firmware loading error')
Cc: # v4.2+
Signed-off-by: Takashi Iwai
---
drivers/leds/Kconfig | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/leds/Kconfig b/drivers/leds/Kconfig
index 70f4255ff291..2ba52bc2e174 100644
--- a/drivers/leds/Kconfig
+++ b/drivers/leds/Kconfig
@@ -229,7 +229,7 @@ config LEDS_LP55XX_COMMON
tristate "Common Driver for TI/National LP5521/5523/55231/5562/8501"
depends on LEDS_LP5521 || LEDS_LP5523 || LEDS_LP5562 || LEDS_LP8501
select FW_LOADER
- select FW_LOADER_USER_HELPER_FALLBACK
+ select FW_LOADER_USER_HELPER
help
This option supports common operations for LP5521/5523/55231/5562/8501
devices.
--
Best Regards,
Jacek Anaszewski
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] powerpc32: memcpy: only use dcbz once cache is enabled
memcpy() uses instruction dcbz to speed up copy by not wasting time
loading cache line with data that will be overwritten.
Some platform like mpc52xx do no have cache active at startup and
can therefore not use memcpy(). Allthough no part of the code
explicitly uses memcpy(), GCC makes calls to it.
This patch modifies memcpy() such that at startup, the 'dcbz'
instruction is replaced by 'dcbt' which is harmless if cache is not
enabled, and which helps a bit (allthough not as much as dcbz) if
cache is already enabled.
Once the initial MMU is setup, in machine_init() we patch memcpy()
by replacing the temporary 'dcbt' by 'dcbz'
Reported-by: Michal Sojka
Signed-off-by: Christophe Leroy
---
@Michal, can you please test it ?
arch/powerpc/kernel/setup_32.c | 12
arch/powerpc/lib/copy_32.S | 11 ++-
2 files changed, 22 insertions(+), 1 deletion(-)
diff --git a/arch/powerpc/kernel/setup_32.c b/arch/powerpc/kernel/setup_32.c
index 07831ed..93715f3 100644
--- a/arch/powerpc/kernel/setup_32.c
+++ b/arch/powerpc/kernel/setup_32.c
@@ -39,6 +39,7 @@
#include
#include
#include
+#include
#define DBG(fmt...)
@@ -108,6 +109,15 @@ notrace unsigned long __init early_init(unsigned long
dt_ptr)
return KERNELBASE + offset;
}
+extern unsigned int ppc32_memcpy_dcbz;
+notrace void __init patch_memcpy(void)
+{
+ unsigned int instr = ppc32_memcpy_dcbz;
+
+ instr &= 0x001ff800; /* keep only RA and RB */
+ instr |= 0x7c0007ec; /* dcbz */
+ patch_instruction(_memcpy_dcbz, instr);
+}
/*
* Find out what kind of machine we're on and save any data we need
@@ -122,6 +132,8 @@ notrace void __init machine_init(u64 dt_ptr)
/* Enable early debugging if any specified (see udbg.h) */
udbg_early_init();
+ patch_memcpy();
+
/* Do some early initialization based on the flat device tree */
early_init_devtree(__va(dt_ptr));
diff --git a/arch/powerpc/lib/copy_32.S b/arch/powerpc/lib/copy_32.S
index 2ef50c6..05b3096 100644
--- a/arch/powerpc/lib/copy_32.S
+++ b/arch/powerpc/lib/copy_32.S
@@ -172,7 +172,16 @@ _GLOBAL(memcpy)
mtctr r0
beq 63f
53:
- dcbzr11,r6
+ /*
+* During early init, cache might not be active yet, so dcbz cannot be
+* used. We put dcbt instead of dcbz. If cache is not active, it's just
+* like a not. If cache is active, at least it prefetchs the line to be
+* overwritten.
+* Will be replaced by dcbz in machine_init()
+*/
+_GLOBAL(ppc32_memcpy_dcbz)
+ dcbtr11,r6
+
COPY_16_BYTES
#if L1_CACHE_BYTES >= 32
COPY_16_BYTES
--
2.1.0
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] btrfs: memset cur_trans->delayed_refs to zero
On Mon, Sep 07, 2015 at 04:01:22PM +0200, David Sterba wrote: > So, updated patches should mention that in the subject eg: > > [PATCH v2] btrfs: memset cur_trans->delayed_refs to zero > > On Mon, Sep 07, 2015 at 04:45:02PM +0300, Alexandru Moise wrote: > > Use memset() to null out the btrfs_delayed_ref_root of > > btrfs_transaction instead of setting all the members to 0 by hand. > > > > Signed-off-by: Alexandru Moise <00moses.alexande...@gmail.com> > > --- > > And in this section (ie. after the first ---) put a brief description of > the changes. Will do. > > > fs/btrfs/transaction.c | 12 ++-- > > 1 file changed, 6 insertions(+), 6 deletions(-) > > > > diff --git a/fs/btrfs/transaction.c b/fs/btrfs/transaction.c > > index 8f259b3..0581fb4 100644 > > --- a/fs/btrfs/transaction.c > > +++ b/fs/btrfs/transaction.c > > @@ -224,15 +224,15 @@ loop: > > cur_trans->start_time = get_seconds(); > > cur_trans->dirty_bg_run = 0; > > > > + memset(_trans->delayed_refs, 0, sizeof(cur_trans->delayed_refs)); > > + > > + /* > > +* For now RB_ROOT means set to NULL but this could change in > > +* the future > > +*/ > > I don't think such comment necessary, the code is clear enough without > it. > > > cur_trans->delayed_refs.href_root = RB_ROOT; > > cur_trans->delayed_refs.dirty_extent_root = RB_ROOT; > > . Alright I can agree to that, thanks. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] btrfs: memset cur_trans->delayed_refs to zero
Use memset() to null out the btrfs_delayed_ref_root of btrfs_transaction instead of setting all the members to 0 by hand. Signed-off-by: Alexandru Moise <00moses.alexande...@gmail.com> --- Rather than setting each member of ->delayed_refs by hand we should adhere to the practice of using memset() calls to fill those memory locations with zeroes. We make an exception however for the rb_root and atomic_t variable to make room for change in future delayed_refs implementations. fs/btrfs/transaction.c | 8 ++-- 1 file changed, 2 insertions(+), 6 deletions(-) diff --git a/fs/btrfs/transaction.c b/fs/btrfs/transaction.c index 8f259b3..e4f7dcb 100644 --- a/fs/btrfs/transaction.c +++ b/fs/btrfs/transaction.c @@ -224,15 +224,11 @@ loop: cur_trans->start_time = get_seconds(); cur_trans->dirty_bg_run = 0; + memset(_trans->delayed_refs, 0, sizeof(cur_trans->delayed_refs)); + cur_trans->delayed_refs.href_root = RB_ROOT; cur_trans->delayed_refs.dirty_extent_root = RB_ROOT; atomic_set(_trans->delayed_refs.num_entries, 0); - cur_trans->delayed_refs.num_heads_ready = 0; - cur_trans->delayed_refs.pending_csums = 0; - cur_trans->delayed_refs.num_heads = 0; - cur_trans->delayed_refs.flushing = 0; - cur_trans->delayed_refs.run_delayed_start = 0; - cur_trans->delayed_refs.qgroup_to_skip = 0; /* * although the tree mod log is per file system and not per transaction, -- 1.9.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/4] hv: kvp: use wrapper to propate state
The .state is used by several threads of execution.
Propagate the state to make changes visible. Also propagate context
change in kvp_on_msg.
Signed-off-by: Olaf Hering
---
drivers/hv/hv_kvp.c | 38 +-
1 file changed, 21 insertions(+), 17 deletions(-)
diff --git a/drivers/hv/hv_kvp.c b/drivers/hv/hv_kvp.c
index 74c38a9..f421691 100644
--- a/drivers/hv/hv_kvp.c
+++ b/drivers/hv/hv_kvp.c
@@ -61,7 +61,7 @@
*/
static struct {
- int state; /* hvutil_device_state */
+ enum hvutil_device_state state;
int recv_len; /* number of bytes received. */
struct hv_kvp_msg *kvp_msg; /* current message */
struct vmbus_channel *recv_channel; /* chn we got the request */
@@ -74,6 +74,9 @@ static struct {
*/
static int dm_reg_value;
+#define kvp_get_state() hvutil_device_get_state(_transaction.state)
+#define kvp_set_state(s) hvutil_device_set_state(_transaction.state, s)
+
static void kvp_send_key(struct work_struct *dummy);
@@ -122,8 +125,8 @@ static void kvp_timeout_func(struct work_struct *dummy)
kvp_respond_to_host(NULL, HV_E_FAIL);
/* Transaction is finished, reset the state. */
- if (kvp_transaction.state > HVUTIL_READY)
- kvp_transaction.state = HVUTIL_READY;
+ if (kvp_get_state() > HVUTIL_READY)
+ kvp_set_state(HVUTIL_READY);
hv_poll_channel(kvp_transaction.kvp_context,
hv_kvp_onchannelcallback);
@@ -153,7 +156,7 @@ static int kvp_handle_handshake(struct hv_kvp_msg *msg)
pr_debug("KVP: userspace daemon ver. %d registered\n",
KVP_OP_REGISTER);
kvp_register(dm_reg_value);
- kvp_transaction.state = HVUTIL_READY;
+ kvp_set_state(HVUTIL_READY);
return 0;
}
@@ -177,15 +180,15 @@ static int kvp_on_msg(void *msg, int len)
* with the daemon; handle that first.
*/
- if (kvp_transaction.state < HVUTIL_READY) {
+ if (kvp_get_state() < HVUTIL_READY) {
return kvp_handle_handshake(message);
}
/* We didn't send anything to userspace so the reply is spurious */
- if (kvp_transaction.state < HVUTIL_USERSPACE_REQ)
+ if (kvp_get_state() < HVUTIL_USERSPACE_REQ)
return -EINVAL;
- kvp_transaction.state = HVUTIL_USERSPACE_RECV;
+ kvp_set_state(HVUTIL_USERSPACE_RECV);
/*
* Based on the version of the daemon, we propagate errors from the
@@ -218,7 +221,7 @@ static int kvp_on_msg(void *msg, int len)
*/
if (cancel_delayed_work_sync(_timeout_work)) {
kvp_respond_to_host(message, error);
- kvp_transaction.state = HVUTIL_READY;
+ kvp_set_state(HVUTIL_READY);
hv_poll_channel(kvp_transaction.kvp_context,
hv_kvp_onchannelcallback);
}
@@ -349,7 +352,7 @@ kvp_send_key(struct work_struct *dummy)
int rc;
/* The transaction state is wrong. */
- if (kvp_transaction.state != HVUTIL_HOSTMSG_RECEIVED)
+ if (kvp_get_state() != HVUTIL_HOSTMSG_RECEIVED)
return;
message = kzalloc(sizeof(*message), GFP_KERNEL);
@@ -442,13 +445,13 @@ kvp_send_key(struct work_struct *dummy)
break;
}
- kvp_transaction.state = HVUTIL_USERSPACE_REQ;
+ kvp_set_state(HVUTIL_USERSPACE_REQ);
rc = hvutil_transport_send(hvt, message, sizeof(*message));
if (rc) {
pr_debug("KVP: failed to communicate to the daemon: %d\n", rc);
if (cancel_delayed_work_sync(_timeout_work)) {
kvp_respond_to_host(message, HV_E_FAIL);
- kvp_transaction.state = HVUTIL_READY;
+ kvp_set_state(HVUTIL_READY);
}
}
@@ -596,12 +599,13 @@ void hv_kvp_onchannelcallback(void *context)
int util_fw_version;
int kvp_srv_version;
- if (kvp_transaction.state > HVUTIL_READY) {
+ if (kvp_get_state() > HVUTIL_READY) {
/*
* We will defer processing this callback once
* the current transaction is complete.
*/
kvp_transaction.kvp_context = context;
+ wmb();
return;
}
kvp_transaction.kvp_context = NULL;
@@ -651,12 +655,12 @@ void hv_kvp_onchannelcallback(void *context)
kvp_transaction.recv_req_id = requestid;
kvp_transaction.kvp_msg = kvp_msg;
- if (kvp_transaction.state < HVUTIL_READY) {
+ if (kvp_get_state() < HVUTIL_READY) {
/* Userspace is not registered yet */
kvp_respond_to_host(NULL, HV_E_FAIL);
return;
}
-
[PATCH 4/4] hv: vss: use wrapper to propate state
The .state is used by several threads of execution.
Propagate the state to make changes visible. Also propagate context
change in vss_on_msg.
Signed-off-by: Olaf Hering
---
drivers/hv/hv_snapshot.c | 37 -
1 file changed, 20 insertions(+), 17 deletions(-)
diff --git a/drivers/hv/hv_snapshot.c b/drivers/hv/hv_snapshot.c
index 815405f..f3cb822 100644
--- a/drivers/hv/hv_snapshot.c
+++ b/drivers/hv/hv_snapshot.c
@@ -48,7 +48,7 @@
*/
static struct {
- int state; /* hvutil_device_state */
+ enum hvutil_device_state state;
int recv_len; /* number of bytes received. */
struct vmbus_channel *recv_channel; /* chn we got the request */
u64 recv_req_id; /* request ID. */
@@ -64,6 +64,9 @@ static void vss_respond_to_host(int error);
*/
static int dm_reg_value;
+#define vss_get_state() hvutil_device_get_state(_transaction.state)
+#define vss_set_state(s) hvutil_device_set_state(_transaction.state, s)
+
static const char vss_devname[] = "vmbus/hv_vss";
static __u8 *recv_buffer;
static struct hvutil_transport *hvt;
@@ -87,8 +90,8 @@ static void vss_timeout_func(struct work_struct *dummy)
vss_respond_to_host(HV_E_FAIL);
/* Transaction is finished, reset the state. */
- if (vss_transaction.state > HVUTIL_READY)
- vss_transaction.state = HVUTIL_READY;
+ if (vss_get_state() > HVUTIL_READY)
+ vss_set_state(HVUTIL_READY);
hv_poll_channel(vss_transaction.vss_context,
hv_vss_onchannelcallback);
@@ -112,7 +115,7 @@ static int vss_handle_handshake(struct hv_vss_msg *vss_msg)
default:
return -EINVAL;
}
- vss_transaction.state = HVUTIL_READY;
+ vss_set_state(HVUTIL_READY);
pr_debug("VSS: userspace daemon ver. %d registered\n", dm_reg_value);
return 0;
}
@@ -130,15 +133,15 @@ static int vss_on_msg(void *msg, int len)
* Don't process registration messages if we're in the middle
* of a transaction processing.
*/
- if (vss_transaction.state > HVUTIL_READY)
+ if (vss_get_state() > HVUTIL_READY)
return -EINVAL;
return vss_handle_handshake(vss_msg);
- } else if (vss_transaction.state == HVUTIL_USERSPACE_REQ) {
- vss_transaction.state = HVUTIL_USERSPACE_RECV;
+ } else if (vss_get_state() == HVUTIL_USERSPACE_REQ) {
+ vss_set_state(HVUTIL_USERSPACE_RECV);
if (cancel_delayed_work_sync(_timeout_work)) {
vss_respond_to_host(vss_msg->error);
/* Transaction is finished, reset the state. */
- vss_transaction.state = HVUTIL_READY;
+ vss_set_state(HVUTIL_READY);
hv_poll_channel(vss_transaction.vss_context,
hv_vss_onchannelcallback);
}
@@ -158,7 +161,7 @@ static void vss_send_op(struct work_struct *dummy)
struct hv_vss_msg *vss_msg;
/* The transaction state is wrong. */
- if (vss_transaction.state != HVUTIL_HOSTMSG_RECEIVED)
+ if (vss_get_state() != HVUTIL_HOSTMSG_RECEIVED)
return;
vss_msg = kzalloc(sizeof(*vss_msg), GFP_KERNEL);
@@ -167,13 +170,13 @@ static void vss_send_op(struct work_struct *dummy)
vss_msg->vss_hdr.operation = op;
- vss_transaction.state = HVUTIL_USERSPACE_REQ;
+ vss_set_state(HVUTIL_USERSPACE_REQ);
rc = hvutil_transport_send(hvt, vss_msg, sizeof(*vss_msg));
if (rc) {
pr_warn("VSS: failed to communicate to the daemon: %d\n", rc);
if (cancel_delayed_work_sync(_timeout_work)) {
vss_respond_to_host(HV_E_FAIL);
- vss_transaction.state = HVUTIL_READY;
+ vss_set_state(HVUTIL_READY);
}
}
@@ -238,7 +241,7 @@ void hv_vss_onchannelcallback(void *context)
struct icmsg_hdr *icmsghdrp;
struct icmsg_negotiate *negop = NULL;
- if (vss_transaction.state > HVUTIL_READY) {
+ if (vss_get_state() > HVUTIL_READY) {
/*
* We will defer processing this callback once
* the current transaction is complete.
@@ -288,12 +291,12 @@ void hv_vss_onchannelcallback(void *context)
*/
case VSS_OP_FREEZE:
case VSS_OP_THAW:
- if (vss_transaction.state < HVUTIL_READY) {
+ if (vss_get_state() < HVUTIL_READY) {
/* Userspace is not registered yet */
vss_respond_to_host(HV_E_FAIL);
return;
}
-
[PATCH 1/4] hv: add helpers to handle hv_util device state
The callbacks in kvp, vss and fcopy code are called the main thread and
also from interrupt context. If a state change is done by the main
thread it is not immediately seen by the interrupt. As a result the
state machine gets out of sync.
Force propagation of state changes via get/set helpers with a memory barrier.
Signed-off-by: Olaf Hering
---
drivers/hv/hyperv_vmbus.h | 12
1 file changed, 12 insertions(+)
diff --git a/drivers/hv/hyperv_vmbus.h b/drivers/hv/hyperv_vmbus.h
index 3d70e36..6c03925 100644
--- a/drivers/hv/hyperv_vmbus.h
+++ b/drivers/hv/hyperv_vmbus.h
@@ -780,4 +780,16 @@ enum hvutil_device_state {
HVUTIL_DEVICE_DYING, /* driver unload is in progress */
};
+static inline void hvutil_device_set_state(enum hvutil_device_state *p, enum
hvutil_device_state s)
+{
+ *p = s;
+ wmb();
+}
+
+static inline enum hvutil_device_state hvutil_device_get_state(enum
hvutil_device_state *p)
+{
+ rmb();
+ return *p;
+}
+
#endif /* _HYPERV_VMBUS_H */
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 0/4] hv: utils: propagate state to interrupt thread
The Copy-VMFile cmdlet on the host may fail because the guest fcopy driver state machine gets out of sync. This happens because the ->state and ->context variables are accessed by the main thread and from interrupt context. If an interrupt happens between fcopy_respond_to_host and hv_poll_channel in fcopy_write, then hv_fcopy_onchannelcallback called from that interrupt sees still state HVUTIL_USERSPACE_RECV. It updates the context, but fcopy_write will not notice that update and hv_poll_channel gets called with an empty context. As a result hv_fcopy_daemon gets no more data. After a timeout Copy-VMFile fails with timeout. In my initial testing for a fix I put a "mb()" after the last .state change in fcopy_write. But this series implementes read/write memory barriers as needed. Let me know if this is overdoing things. Olaf Olaf Hering (4): hv: add helpers to handle hv_util device state hv: fcopy: use wrapper to propate state hv: kvp: use wrapper to propate state hv: vss: use wrapper to propate state drivers/hv/hv_fcopy.c | 36 drivers/hv/hv_kvp.c | 38 +- drivers/hv/hv_snapshot.c | 37 - drivers/hv/hyperv_vmbus.h | 12 4 files changed, 73 insertions(+), 50 deletions(-) -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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 00/14] perf tools: Fix gaps propagating maps
Hi
Here is V2 of "Fix gaps propagating maps" that fixes some problems
revealed by to d988d5ee6478 ("perf evlist: Open event on evsel cpus and
threads")
Changes in V2:
Split into multiple patches
Add evsel->own_cpus to identify evsels with their own cpu map
And consequently don't need to unpropagate
perf tools: Fix perf_evlist__splice_list_tail not setting evlist
New patch
perf tools: Fix task exit test setting maps
New patch
perf tools: Fix software clock events test setting maps
New patch
Adrian Hunter (14):
perf tools: Simplify perf_evlist__propagate_maps logic
perf tools: Simplify perf_evlist__set_maps logic
perf tools: Remove redundant validation from perf_evlist__propagate_maps
perf tools: Add evlist->has_user_cpus
perf tools: Fix perf_evlist__splice_list_tail not setting evlist
perf tools: Fix missing thread_map__put in perf_evlist__propagate_maps
perf tools: Add evsel->own_cpus
perf tools: Make perf_evlist__set_maps() more resilient
perf tools: Make perf_evlist__create_maps() use perf_evlist__set_maps()
perf tools: Factor out a function to propagate maps for a single evsel
perf tools: Fix perf_evlist__add() not propagating maps
perf tools: Fix perf_evlist__create_syswide_maps() not propagating maps
perf tools: Fix task exit test setting maps
perf tools: Fix software clock events test setting maps
tools/perf/tests/sw-clock.c| 22 +--
tools/perf/tests/task-exit.c | 22 +--
tools/perf/util/evlist.c | 134 +++--
tools/perf/util/evlist.h | 4 +-
tools/perf/util/evsel.c| 1 +
tools/perf/util/evsel.h| 1 +
tools/perf/util/parse-events.c | 7 +--
7 files changed, 119 insertions(+), 72 deletions(-)
Regards
Adrian
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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 01/14] perf tools: Simplify perf_evlist__propagate_maps logic
If evsel->cpus is to be reassigned then the current value
must be "put", which works even if it is NULL. Simplify
the current logic by moving the "put" next to the assignment.
Signed-off-by: Adrian Hunter
---
tools/perf/util/evlist.c | 5 ++---
1 file changed, 2 insertions(+), 3 deletions(-)
diff --git a/tools/perf/util/evlist.c b/tools/perf/util/evlist.c
index d51a5200c8af..95e07ea3904c 100644
--- a/tools/perf/util/evlist.c
+++ b/tools/perf/util/evlist.c
@@ -1113,11 +1113,10 @@ static int perf_evlist__propagate_maps(struct
perf_evlist *evlist,
* We already have cpus for evsel (via PMU sysfs) so
* keep it, if there's no target cpu list defined.
*/
- if (evsel->cpus && has_user_cpus)
+ if (!evsel->cpus || has_user_cpus) {
cpu_map__put(evsel->cpus);
-
- if (!evsel->cpus || has_user_cpus)
evsel->cpus = cpu_map__get(evlist->cpus);
+ }
evsel->threads = thread_map__get(evlist->threads);
--
1.9.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 02/14] perf tools: Simplify perf_evlist__set_maps logic
Don't need to check for NULL when "putting" evlist->maps and
evlist->threads because the "put" functions already do that.
Signed-off-by: Adrian Hunter
---
tools/perf/util/evlist.c | 8 ++--
1 file changed, 2 insertions(+), 6 deletions(-)
diff --git a/tools/perf/util/evlist.c b/tools/perf/util/evlist.c
index 95e07ea3904c..9cb9296cc4f8 100644
--- a/tools/perf/util/evlist.c
+++ b/tools/perf/util/evlist.c
@@ -1156,14 +1156,10 @@ int perf_evlist__set_maps(struct perf_evlist *evlist,
struct cpu_map *cpus,
struct thread_map *threads)
{
- if (evlist->cpus)
- cpu_map__put(evlist->cpus);
-
+ cpu_map__put(evlist->cpus);
evlist->cpus = cpus;
- if (evlist->threads)
- thread_map__put(evlist->threads);
-
+ thread_map__put(evlist->threads);
evlist->threads = threads;
return perf_evlist__propagate_maps(evlist, false);
--
1.9.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 14/14] perf tools: Fix software clock events test setting maps
The test titled "Test software clock events have valid period values"
was setting cpu/thread maps directly. Make it use the proper
function perf_evlist__set_maps() especially now that it also
propagates the maps.
Signed-off-by: Adrian Hunter
---
tools/perf/tests/sw-clock.c | 22 ++
1 file changed, 18 insertions(+), 4 deletions(-)
diff --git a/tools/perf/tests/sw-clock.c b/tools/perf/tests/sw-clock.c
index 1aa21c90731b..f17ed784d756 100644
--- a/tools/perf/tests/sw-clock.c
+++ b/tools/perf/tests/sw-clock.c
@@ -34,6 +34,8 @@ static int __test__sw_clock_freq(enum perf_sw_ids clock_id)
.disabled = 1,
.freq = 1,
};
+ struct cpu_map *cpus;
+ struct thread_map *threads;
attr.sample_freq = 500;
@@ -50,14 +52,23 @@ static int __test__sw_clock_freq(enum perf_sw_ids clock_id)
}
perf_evlist__add(evlist, evsel);
- evlist->cpus = cpu_map__dummy_new();
- evlist->threads = thread_map__new_by_tid(getpid());
- if (!evlist->cpus || !evlist->threads) {
+ cpus = cpu_map__dummy_new();
+ threads = thread_map__new_by_tid(getpid());
+ if (!cpus || !threads) {
err = -ENOMEM;
pr_debug("Not enough memory to create thread/cpu maps\n");
- goto out_delete_evlist;
+ goto out_free_maps;
+ }
+
+ err = perf_evlist__set_maps(evlist, cpus, threads);
+ if (err) {
+ pr_debug("Failed to set thread/cpu maps\n");
+ goto out_free_maps;
}
+ cpus= NULL;
+ threads = NULL;
+
if (perf_evlist__open(evlist)) {
const char *knob =
"/proc/sys/kernel/perf_event_max_sample_rate";
@@ -107,6 +118,9 @@ next_event:
err = -1;
}
+out_free_maps:
+ cpu_map__put(cpus);
+ thread_map__put(threads);
out_delete_evlist:
perf_evlist__delete(evlist);
return err;
--
1.9.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 11/14] perf tools: Fix perf_evlist__add() not propagating maps
If evsels are added after maps are created, then they won't
have any maps propagated to them. Fix that.
Signed-off-by: Adrian Hunter
---
tools/perf/util/evlist.c | 56 +---
1 file changed, 29 insertions(+), 27 deletions(-)
diff --git a/tools/perf/util/evlist.c b/tools/perf/util/evlist.c
index cddd5f25aa23..e0a32e63825d 100644
--- a/tools/perf/util/evlist.c
+++ b/tools/perf/util/evlist.c
@@ -124,6 +124,33 @@ void perf_evlist__delete(struct perf_evlist *evlist)
free(evlist);
}
+static void __perf_evlist__propagate_maps(struct perf_evlist *evlist,
+ struct perf_evsel *evsel)
+{
+ /*
+* We already have cpus for evsel (via PMU sysfs) so
+* keep it, if there's no target cpu list defined.
+*/
+ if (!evsel->own_cpus || evlist->has_user_cpus) {
+ cpu_map__put(evsel->cpus);
+ evsel->cpus = cpu_map__get(evlist->cpus);
+ } else if (evsel->cpus != evsel->own_cpus) {
+ cpu_map__put(evsel->cpus);
+ evsel->cpus = cpu_map__get(evsel->own_cpus);
+ }
+
+ thread_map__put(evsel->threads);
+ evsel->threads = thread_map__get(evlist->threads);
+}
+
+static void perf_evlist__propagate_maps(struct perf_evlist *evlist)
+{
+ struct perf_evsel *evsel;
+
+ evlist__for_each(evlist, evsel)
+ __perf_evlist__propagate_maps(evlist, evsel);
+}
+
void perf_evlist__add(struct perf_evlist *evlist, struct perf_evsel *entry)
{
entry->evlist = evlist;
@@ -133,6 +160,8 @@ void perf_evlist__add(struct perf_evlist *evlist, struct
perf_evsel *entry)
if (!evlist->nr_entries++)
perf_evlist__set_id_pos(evlist);
+
+ __perf_evlist__propagate_maps(evlist, entry);
}
void perf_evlist__splice_list_tail(struct perf_evlist *evlist,
@@ -1102,33 +1131,6 @@ int perf_evlist__mmap(struct perf_evlist *evlist,
unsigned int pages,
return perf_evlist__mmap_ex(evlist, pages, overwrite, 0, false);
}
-static void __perf_evlist__propagate_maps(struct perf_evlist *evlist,
- struct perf_evsel *evsel)
-{
- /*
-* We already have cpus for evsel (via PMU sysfs) so
-* keep it, if there's no target cpu list defined.
-*/
- if (!evsel->own_cpus || evlist->has_user_cpus) {
- cpu_map__put(evsel->cpus);
- evsel->cpus = cpu_map__get(evlist->cpus);
- } else if (evsel->cpus != evsel->own_cpus) {
- cpu_map__put(evsel->cpus);
- evsel->cpus = cpu_map__get(evsel->own_cpus);
- }
-
- thread_map__put(evsel->threads);
- evsel->threads = thread_map__get(evlist->threads);
-}
-
-static void perf_evlist__propagate_maps(struct perf_evlist *evlist)
-{
- struct perf_evsel *evsel;
-
- evlist__for_each(evlist, evsel)
- __perf_evlist__propagate_maps(evlist, evsel);
-}
-
int perf_evlist__create_maps(struct perf_evlist *evlist, struct target *target)
{
struct cpu_map *cpus;
--
1.9.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 09/14] perf tools: Make perf_evlist__create_maps() use perf_evlist__set_maps()
Since there is a function to set maps, perf_evlist__create_maps()
should use it.
Signed-off-by: Adrian Hunter
---
tools/perf/util/evlist.c | 21 ++---
1 file changed, 10 insertions(+), 11 deletions(-)
diff --git a/tools/perf/util/evlist.c b/tools/perf/util/evlist.c
index 606fc6e63ec0..093ea73d863c 100644
--- a/tools/perf/util/evlist.c
+++ b/tools/perf/util/evlist.c
@@ -1126,29 +1126,28 @@ static void perf_evlist__propagate_maps(struct
perf_evlist *evlist)
int perf_evlist__create_maps(struct perf_evlist *evlist, struct target *target)
{
- evlist->threads = thread_map__new_str(target->pid, target->tid,
- target->uid);
+ struct cpu_map *cpus;
+ struct thread_map *threads;
- if (evlist->threads == NULL)
+ threads = thread_map__new_str(target->pid, target->tid, target->uid);
+
+ if (!threads)
return -1;
if (target__uses_dummy_map(target))
- evlist->cpus = cpu_map__dummy_new();
+ cpus = cpu_map__dummy_new();
else
- evlist->cpus = cpu_map__new(target->cpu_list);
+ cpus = cpu_map__new(target->cpu_list);
- if (evlist->cpus == NULL)
+ if (!cpus)
goto out_delete_threads;
evlist->has_user_cpus = !!target->cpu_list;
- perf_evlist__propagate_maps(evlist);
-
- return 0;
+ return perf_evlist__set_maps(evlist, cpus, threads);
out_delete_threads:
- thread_map__put(evlist->threads);
- evlist->threads = NULL;
+ thread_map__put(threads);
return -1;
}
--
1.9.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 08/14] perf tools: Make perf_evlist__set_maps() more resilient
Make perf_evlist__set_maps() more resilient by allowing for the
possibility that one or another of the maps isn't being changed
and therefore should not be "put".
Signed-off-by: Adrian Hunter
---
tools/perf/util/evlist.c | 19 +++
1 file changed, 15 insertions(+), 4 deletions(-)
diff --git a/tools/perf/util/evlist.c b/tools/perf/util/evlist.c
index 6764e0eff849..606fc6e63ec0 100644
--- a/tools/perf/util/evlist.c
+++ b/tools/perf/util/evlist.c
@@ -1156,11 +1156,22 @@ int perf_evlist__set_maps(struct perf_evlist *evlist,
struct cpu_map *cpus,
struct thread_map *threads)
{
- cpu_map__put(evlist->cpus);
- evlist->cpus = cpus;
+ /*
+* Allow for the possibility that one or another of the maps isn't being
+* changed i.e. don't put it. Note we are assuming the maps that are
+* being applied are brand new and evlist is taking ownership of the
+* original reference count of 1. If that is not the case it is up to
+* the caller to increase the reference count.
+*/
+ if (cpus != evlist->cpus) {
+ cpu_map__put(evlist->cpus);
+ evlist->cpus = cpus;
+ }
- thread_map__put(evlist->threads);
- evlist->threads = threads;
+ if (threads != evlist->threads) {
+ thread_map__put(evlist->threads);
+ evlist->threads = threads;
+ }
perf_evlist__propagate_maps(evlist);
--
1.9.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 12/14] perf tools: Fix perf_evlist__create_syswide_maps() not propagating maps
Fix it by making it call perf_evlist__set_maps() instead of
setting the maps itself.
Signed-off-by: Adrian Hunter
---
tools/perf/util/evlist.c | 22 +-
1 file changed, 13 insertions(+), 9 deletions(-)
diff --git a/tools/perf/util/evlist.c b/tools/perf/util/evlist.c
index e0a32e63825d..fc2ac60d92f0 100644
--- a/tools/perf/util/evlist.c
+++ b/tools/perf/util/evlist.c
@@ -1401,6 +1401,8 @@ void perf_evlist__close(struct perf_evlist *evlist)
static int perf_evlist__create_syswide_maps(struct perf_evlist *evlist)
{
+ struct cpu_map*cpus;
+ struct thread_map *threads;
int err = -ENOMEM;
/*
@@ -1412,20 +1414,22 @@ static int perf_evlist__create_syswide_maps(struct
perf_evlist *evlist)
* error, and we may not want to do that fallback to a
* default cpu identity map :-\
*/
- evlist->cpus = cpu_map__new(NULL);
- if (evlist->cpus == NULL)
+ cpus = cpu_map__new(NULL);
+ if (!cpus)
goto out;
- evlist->threads = thread_map__new_dummy();
- if (evlist->threads == NULL)
- goto out_free_cpus;
+ threads = thread_map__new_dummy();
+ if (!threads)
+ goto out_put;
- err = 0;
+ err = perf_evlist__set_maps(evlist, cpus, threads);
+ if (err)
+ goto out_put;
out:
return err;
-out_free_cpus:
- cpu_map__put(evlist->cpus);
- evlist->cpus = NULL;
+out_put:
+ cpu_map__put(cpus);
+ thread_map__put(threads);
goto out;
}
--
1.9.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 10/14] perf tools: Factor out a function to propagate maps for a single evsel
Subsequent fixes will need a function that just propagates maps
for a single evsel so factor it out.
Signed-off-by: Adrian Hunter
---
tools/perf/util/evlist.c | 37 +
1 file changed, 21 insertions(+), 16 deletions(-)
diff --git a/tools/perf/util/evlist.c b/tools/perf/util/evlist.c
index 093ea73d863c..cddd5f25aa23 100644
--- a/tools/perf/util/evlist.c
+++ b/tools/perf/util/evlist.c
@@ -1102,26 +1102,31 @@ int perf_evlist__mmap(struct perf_evlist *evlist,
unsigned int pages,
return perf_evlist__mmap_ex(evlist, pages, overwrite, 0, false);
}
+static void __perf_evlist__propagate_maps(struct perf_evlist *evlist,
+ struct perf_evsel *evsel)
+{
+ /*
+* We already have cpus for evsel (via PMU sysfs) so
+* keep it, if there's no target cpu list defined.
+*/
+ if (!evsel->own_cpus || evlist->has_user_cpus) {
+ cpu_map__put(evsel->cpus);
+ evsel->cpus = cpu_map__get(evlist->cpus);
+ } else if (evsel->cpus != evsel->own_cpus) {
+ cpu_map__put(evsel->cpus);
+ evsel->cpus = cpu_map__get(evsel->own_cpus);
+ }
+
+ thread_map__put(evsel->threads);
+ evsel->threads = thread_map__get(evlist->threads);
+}
+
static void perf_evlist__propagate_maps(struct perf_evlist *evlist)
{
struct perf_evsel *evsel;
- evlist__for_each(evlist, evsel) {
- /*
-* We already have cpus for evsel (via PMU sysfs) so
-* keep it, if there's no target cpu list defined.
-*/
- if (!evsel->own_cpus || evlist->has_user_cpus) {
- cpu_map__put(evsel->cpus);
- evsel->cpus = cpu_map__get(evlist->cpus);
- } else if (evsel->cpus != evsel->own_cpus) {
- cpu_map__put(evsel->cpus);
- evsel->cpus = cpu_map__get(evsel->own_cpus);
- }
-
- thread_map__put(evsel->threads);
- evsel->threads = thread_map__get(evlist->threads);
- }
+ evlist__for_each(evlist, evsel)
+ __perf_evlist__propagate_maps(evlist, evsel);
}
int perf_evlist__create_maps(struct perf_evlist *evlist, struct target *target)
--
1.9.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 13/14] perf tools: Fix task exit test setting maps
The test titled "Test number of exit event of a simple workload"
was setting cpu/thread maps directly. Make it use the proper
function perf_evlist__set_maps() especially now that it also
propagates the maps.
Signed-off-by: Adrian Hunter
---
tools/perf/tests/task-exit.c | 22 ++
1 file changed, 18 insertions(+), 4 deletions(-)
diff --git a/tools/perf/tests/task-exit.c b/tools/perf/tests/task-exit.c
index 3a8fedef83bc..bd73003e012e 100644
--- a/tools/perf/tests/task-exit.c
+++ b/tools/perf/tests/task-exit.c
@@ -43,6 +43,8 @@ int test__task_exit(void)
};
const char *argv[] = { "true", NULL };
char sbuf[STRERR_BUFSIZE];
+ struct cpu_map *cpus;
+ struct thread_map *threads;
signal(SIGCHLD, sig_handler);
@@ -58,14 +60,23 @@ int test__task_exit(void)
* perf_evlist__prepare_workload we'll fill in the only thread
* we're monitoring, the one forked there.
*/
- evlist->cpus = cpu_map__dummy_new();
- evlist->threads = thread_map__new_by_tid(-1);
- if (!evlist->cpus || !evlist->threads) {
+ cpus = cpu_map__dummy_new();
+ threads = thread_map__new_by_tid(-1);
+ if (!cpus || !threads) {
err = -ENOMEM;
pr_debug("Not enough memory to create thread/cpu maps\n");
- goto out_delete_evlist;
+ goto out_free_maps;
+ }
+
+ err = perf_evlist__set_maps(evlist, cpus, threads);
+ if (err) {
+ pr_debug("Failed to set thread/cpu maps\n");
+ goto out_free_maps;
}
+ cpus= NULL;
+ threads = NULL;
+
err = perf_evlist__prepare_workload(evlist, , argv, false,
workload_exec_failed_signal);
if (err < 0) {
@@ -114,6 +125,9 @@ retry:
err = -1;
}
+out_free_maps:
+ cpu_map__put(cpus);
+ thread_map__put(threads);
out_delete_evlist:
perf_evlist__delete(evlist);
return err;
--
1.9.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 03/14] perf tools: Remove redundant validation from perf_evlist__propagate_maps
The validation checks that the values that were just assigned, got
assigned i.e. the error can't ever happen. Subsequent patches will
call this code in places where errors are not being returned.
Changing those code paths to return this non-existent error is
counter-productive, so just remove it.
Signed-off-by: Adrian Hunter
---
tools/perf/util/evlist.c | 18 --
1 file changed, 8 insertions(+), 10 deletions(-)
diff --git a/tools/perf/util/evlist.c b/tools/perf/util/evlist.c
index 9cb9296cc4f8..840d5210be72 100644
--- a/tools/perf/util/evlist.c
+++ b/tools/perf/util/evlist.c
@@ -1103,8 +1103,8 @@ int perf_evlist__mmap(struct perf_evlist *evlist,
unsigned int pages,
return perf_evlist__mmap_ex(evlist, pages, overwrite, 0, false);
}
-static int perf_evlist__propagate_maps(struct perf_evlist *evlist,
- bool has_user_cpus)
+static void perf_evlist__propagate_maps(struct perf_evlist *evlist,
+ bool has_user_cpus)
{
struct perf_evsel *evsel;
@@ -1119,13 +1119,7 @@ static int perf_evlist__propagate_maps(struct
perf_evlist *evlist,
}
evsel->threads = thread_map__get(evlist->threads);
-
- if ((evlist->cpus && !evsel->cpus) ||
- (evlist->threads && !evsel->threads))
- return -ENOMEM;
}
-
- return 0;
}
int perf_evlist__create_maps(struct perf_evlist *evlist, struct target *target)
@@ -1144,7 +1138,9 @@ int perf_evlist__create_maps(struct perf_evlist *evlist,
struct target *target)
if (evlist->cpus == NULL)
goto out_delete_threads;
- return perf_evlist__propagate_maps(evlist, !!target->cpu_list);
+ perf_evlist__propagate_maps(evlist, !!target->cpu_list);
+
+ return 0;
out_delete_threads:
thread_map__put(evlist->threads);
@@ -1162,7 +1158,9 @@ int perf_evlist__set_maps(struct perf_evlist *evlist,
thread_map__put(evlist->threads);
evlist->threads = threads;
- return perf_evlist__propagate_maps(evlist, false);
+ perf_evlist__propagate_maps(evlist, false);
+
+ return 0;
}
int perf_evlist__apply_filters(struct perf_evlist *evlist, struct perf_evsel
**err_evsel)
--
1.9.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 06/14] perf tools: Fix missing thread_map__put in perf_evlist__propagate_maps
perf_evlist__propagate_maps() incorrectly assumes evsel->threads is NULL before reassigning it, but it won't be NULL when perf_evlist__set_maps() is used to set different (or NULL) maps. Thus thread_map__put must be used, which works even if evsel->threads is NULL. Signed-off-by: Adrian Hunter --- tools/perf/util/evlist.c | 1 + 1 file changed, 1 insertion(+) diff --git a/tools/perf/util/evlist.c b/tools/perf/util/evlist.c index 018b488d4c75..c959c42080e3 100644 --- a/tools/perf/util/evlist.c +++ b/tools/perf/util/evlist.c @@ -1116,6 +1116,7 @@ static void perf_evlist__propagate_maps(struct perf_evlist *evlist) evsel->cpus = cpu_map__get(evlist->cpus); } + thread_map__put(evsel->threads); evsel->threads = thread_map__get(evlist->threads); } } -- 1.9.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 0/3] Implement IRQ stack on ARM64
On 04/09/15 15:23, Jungseok Lee wrote: > ARM64 kernel allocates 16KB kernel stack when creating a process. In case > of low memory platforms with tough workloads on userland, this order-2 > allocation request reaches to memory pressure and performance degradation > simultaenously since VM page allocator falls into slowpath frequently, > which triggers page reclaim and compaction. > > I believe that one of the best solutions is to reduce kernel stack size. > According to the following data from stack tracer with some fixes, [1], > a separate IRQ stack would greatly help to decrease a kernel stack depth. > Hi Jungseok Lee, I was working on a similar patch for irq stack, (patch as a follow up email). I suggest we work together on a single implementation. I think the only major difference is that you're using sp_el0 as a temporary register to store a copy of the stack-pointer to find struct thread_info, whereas I was copying it between stacks (ends up as 2x ldp/stps), which keeps the change restricted to irq_stack setup code. We should get some feedback as to which approach is preferred. Thanks, James Morse -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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 04/14] perf tools: Add evlist->has_user_cpus
Subsequent patches will need to call perf_evlist__propagate_maps
without reference to a "target". Add evlist->has_user_cpus to
record whether the user has specified which cpus to target
(and therefore whether that list of cpus should override the
default settings for a selected event i.e. the cpu maps should
be propagated)
Signed-off-by: Adrian Hunter
---
tools/perf/util/evlist.c | 11 ++-
tools/perf/util/evlist.h | 1 +
2 files changed, 7 insertions(+), 5 deletions(-)
diff --git a/tools/perf/util/evlist.c b/tools/perf/util/evlist.c
index 840d5210be72..8bedf5cf366e 100644
--- a/tools/perf/util/evlist.c
+++ b/tools/perf/util/evlist.c
@@ -1103,8 +1103,7 @@ int perf_evlist__mmap(struct perf_evlist *evlist,
unsigned int pages,
return perf_evlist__mmap_ex(evlist, pages, overwrite, 0, false);
}
-static void perf_evlist__propagate_maps(struct perf_evlist *evlist,
- bool has_user_cpus)
+static void perf_evlist__propagate_maps(struct perf_evlist *evlist)
{
struct perf_evsel *evsel;
@@ -1113,7 +1112,7 @@ static void perf_evlist__propagate_maps(struct
perf_evlist *evlist,
* We already have cpus for evsel (via PMU sysfs) so
* keep it, if there's no target cpu list defined.
*/
- if (!evsel->cpus || has_user_cpus) {
+ if (!evsel->cpus || evlist->has_user_cpus) {
cpu_map__put(evsel->cpus);
evsel->cpus = cpu_map__get(evlist->cpus);
}
@@ -1138,7 +1137,9 @@ int perf_evlist__create_maps(struct perf_evlist *evlist,
struct target *target)
if (evlist->cpus == NULL)
goto out_delete_threads;
- perf_evlist__propagate_maps(evlist, !!target->cpu_list);
+ evlist->has_user_cpus = !!target->cpu_list;
+
+ perf_evlist__propagate_maps(evlist);
return 0;
@@ -1158,7 +1159,7 @@ int perf_evlist__set_maps(struct perf_evlist *evlist,
thread_map__put(evlist->threads);
evlist->threads = threads;
- perf_evlist__propagate_maps(evlist, false);
+ perf_evlist__propagate_maps(evlist);
return 0;
}
diff --git a/tools/perf/util/evlist.h b/tools/perf/util/evlist.h
index b39a6198f4ac..2dd5715dfef6 100644
--- a/tools/perf/util/evlist.h
+++ b/tools/perf/util/evlist.h
@@ -42,6 +42,7 @@ struct perf_evlist {
int nr_mmaps;
bool overwrite;
bool enabled;
+ bool has_user_cpus;
size_t mmap_len;
int id_pos;
int is_pos;
--
1.9.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/4] hv: fcopy: use wrapper to propate state
The .state is used by several threads of execution.
Propagate the state to make changes visible. Also propagate context
change in hv_fcopy_onchannelcallback.
Without this change fcopy may hang at random points.
Signed-off-by: Olaf Hering
---
drivers/hv/hv_fcopy.c | 36
1 file changed, 20 insertions(+), 16 deletions(-)
diff --git a/drivers/hv/hv_fcopy.c b/drivers/hv/hv_fcopy.c
index db4b887..47d9c34 100644
--- a/drivers/hv/hv_fcopy.c
+++ b/drivers/hv/hv_fcopy.c
@@ -46,7 +46,7 @@
*/
static struct {
- int state; /* hvutil_device_state */
+ enum hvutil_device_state state;
int recv_len; /* number of bytes received. */
struct hv_fcopy_hdr *fcopy_msg; /* current message */
struct vmbus_channel *recv_channel; /* chn we got the request */
@@ -67,6 +67,9 @@ static struct hvutil_transport *hvt;
*/
static int dm_reg_value;
+#define fcopy_get_state() hvutil_device_get_state(_transaction.state)
+#define fcopy_set_state(s) hvutil_device_set_state(_transaction.state, s)
+
static void fcopy_timeout_func(struct work_struct *dummy)
{
/*
@@ -76,8 +79,8 @@ static void fcopy_timeout_func(struct work_struct *dummy)
fcopy_respond_to_host(HV_E_FAIL);
/* Transaction is finished, reset the state. */
- if (fcopy_transaction.state > HVUTIL_READY)
- fcopy_transaction.state = HVUTIL_READY;
+ if (fcopy_get_state() > HVUTIL_READY)
+ fcopy_set_state(HVUTIL_READY);
hv_poll_channel(fcopy_transaction.fcopy_context,
hv_fcopy_onchannelcallback);
@@ -108,7 +111,7 @@ static int fcopy_handle_handshake(u32 version)
return -EINVAL;
}
pr_debug("FCP: userspace daemon ver. %d registered\n", version);
- fcopy_transaction.state = HVUTIL_READY;
+ fcopy_set_state(HVUTIL_READY);
hv_poll_channel(fcopy_transaction.fcopy_context,
hv_fcopy_onchannelcallback);
return 0;
@@ -162,13 +165,13 @@ static void fcopy_send_data(struct work_struct *dummy)
break;
}
- fcopy_transaction.state = HVUTIL_USERSPACE_REQ;
+ fcopy_set_state(HVUTIL_USERSPACE_REQ);
rc = hvutil_transport_send(hvt, out_src, out_len);
if (rc) {
pr_debug("FCP: failed to communicate to the daemon: %d\n", rc);
if (cancel_delayed_work_sync(_timeout_work)) {
fcopy_respond_to_host(HV_E_FAIL);
- fcopy_transaction.state = HVUTIL_READY;
+ fcopy_set_state(HVUTIL_READY);
}
}
kfree(smsg_out);
@@ -227,12 +230,13 @@ void hv_fcopy_onchannelcallback(void *context)
int util_fw_version;
int fcopy_srv_version;
- if (fcopy_transaction.state > HVUTIL_READY) {
+ if (fcopy_get_state() > HVUTIL_READY) {
/*
* We will defer processing this callback once
* the current transaction is complete.
*/
fcopy_transaction.fcopy_context = context;
+ wmb();
return;
}
fcopy_transaction.fcopy_context = NULL;
@@ -264,12 +268,12 @@ void hv_fcopy_onchannelcallback(void *context)
fcopy_transaction.recv_req_id = requestid;
fcopy_transaction.fcopy_msg = fcopy_msg;
- if (fcopy_transaction.state < HVUTIL_READY) {
+ if (fcopy_get_state() < HVUTIL_READY) {
/* Userspace is not registered yet */
fcopy_respond_to_host(HV_E_FAIL);
return;
}
- fcopy_transaction.state = HVUTIL_HOSTMSG_RECEIVED;
+ fcopy_set_state(HVUTIL_HOSTMSG_RECEIVED);
/*
* Send the information to the user-level daemon.
@@ -291,10 +295,10 @@ static int fcopy_on_msg(void *msg, int len)
if (len != sizeof(int))
return -EINVAL;
- if (fcopy_transaction.state == HVUTIL_DEVICE_INIT)
+ if (fcopy_get_state() == HVUTIL_DEVICE_INIT)
return fcopy_handle_handshake(*val);
- if (fcopy_transaction.state != HVUTIL_USERSPACE_REQ)
+ if (fcopy_get_state() != HVUTIL_USERSPACE_REQ)
return -EINVAL;
/*
@@ -302,9 +306,9 @@ static int fcopy_on_msg(void *msg, int len)
* to the host. But first, cancel the timeout.
*/
if (cancel_delayed_work_sync(_timeout_work)) {
- fcopy_transaction.state = HVUTIL_USERSPACE_RECV;
+ fcopy_set_state(HVUTIL_USERSPACE_RECV);
fcopy_respond_to_host(*val);
- fcopy_transaction.state = HVUTIL_READY;
+ fcopy_set_state(HVUTIL_READY);
hv_poll_channel(fcopy_transaction.fcopy_context,
hv_fcopy_onchannelcallback);
}
@@ -317,7 +321,7 @@
[PATCH V2 05/14] perf tools: Fix perf_evlist__splice_list_tail not setting evlist
Commit d49e46950772 ("perf evsel: Add a backpointer to the evlist
a evsel is in") updated perf_evlist__add() but not
perf_evlist__splice_list_tail().
This illustrates that it is better if perf_evlist__splice_list_tail()
calls perf_evlist__add() instead of duplicating the logic, so do that.
This will also simplify a subsequent fix for propagating maps.
Signed-off-by: Adrian Hunter
---
tools/perf/util/evlist.c | 15 +++
tools/perf/util/evlist.h | 3 +--
tools/perf/util/parse-events.c | 3 +--
3 files changed, 9 insertions(+), 12 deletions(-)
diff --git a/tools/perf/util/evlist.c b/tools/perf/util/evlist.c
index 8bedf5cf366e..018b488d4c75 100644
--- a/tools/perf/util/evlist.c
+++ b/tools/perf/util/evlist.c
@@ -136,15 +136,14 @@ void perf_evlist__add(struct perf_evlist *evlist, struct
perf_evsel *entry)
}
void perf_evlist__splice_list_tail(struct perf_evlist *evlist,
- struct list_head *list,
- int nr_entries)
+ struct list_head *list)
{
- bool set_id_pos = !evlist->nr_entries;
+ struct perf_evsel *evsel, *temp;
- list_splice_tail(list, >entries);
- evlist->nr_entries += nr_entries;
- if (set_id_pos)
- perf_evlist__set_id_pos(evlist);
+ __evlist__for_each_safe(list, temp, evsel) {
+ list_del_init(>node);
+ perf_evlist__add(evlist, evsel);
+ }
}
void __perf_evlist__set_leader(struct list_head *list)
@@ -210,7 +209,7 @@ static int perf_evlist__add_attrs(struct perf_evlist
*evlist,
list_add_tail(>node, );
}
- perf_evlist__splice_list_tail(evlist, , nr_attrs);
+ perf_evlist__splice_list_tail(evlist, );
return 0;
diff --git a/tools/perf/util/evlist.h b/tools/perf/util/evlist.h
index 2dd5715dfef6..3c6ec625d70a 100644
--- a/tools/perf/util/evlist.h
+++ b/tools/perf/util/evlist.h
@@ -180,8 +180,7 @@ bool perf_evlist__valid_sample_id_all(struct perf_evlist
*evlist);
bool perf_evlist__valid_read_format(struct perf_evlist *evlist);
void perf_evlist__splice_list_tail(struct perf_evlist *evlist,
- struct list_head *list,
- int nr_entries);
+ struct list_head *list);
static inline struct perf_evsel *perf_evlist__first(struct perf_evlist *evlist)
{
diff --git a/tools/perf/util/parse-events.c b/tools/perf/util/parse-events.c
index d826e6f515db..7e8ae21906e2 100644
--- a/tools/perf/util/parse-events.c
+++ b/tools/perf/util/parse-events.c
@@ -1140,10 +1140,9 @@ int parse_events(struct perf_evlist *evlist, const char
*str,
ret = parse_events__scanner(str, , PE_START_EVENTS);
perf_pmu__parse_cleanup();
if (!ret) {
- int entries = data.idx - evlist->nr_entries;
struct perf_evsel *last;
- perf_evlist__splice_list_tail(evlist, , entries);
+ perf_evlist__splice_list_tail(evlist, );
evlist->nr_groups += data.nr_groups;
last = perf_evlist__last(evlist);
last->cmdline_group_boundary = true;
--
1.9.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 07/14] perf tools: Add evsel->own_cpus
perf_evlist__propagate_maps() cannot easily tell if an evsel
has its own cpu map. To make that simpler, keep a copy of
the PMU cpu map and adjust the propagation logic accordingly.
Signed-off-by: Adrian Hunter
---
tools/perf/util/evlist.c | 5 -
tools/perf/util/evsel.c| 1 +
tools/perf/util/evsel.h| 1 +
tools/perf/util/parse-events.c | 4 ++--
4 files changed, 8 insertions(+), 3 deletions(-)
diff --git a/tools/perf/util/evlist.c b/tools/perf/util/evlist.c
index c959c42080e3..6764e0eff849 100644
--- a/tools/perf/util/evlist.c
+++ b/tools/perf/util/evlist.c
@@ -,9 +,12 @@ static void perf_evlist__propagate_maps(struct
perf_evlist *evlist)
* We already have cpus for evsel (via PMU sysfs) so
* keep it, if there's no target cpu list defined.
*/
- if (!evsel->cpus || evlist->has_user_cpus) {
+ if (!evsel->own_cpus || evlist->has_user_cpus) {
cpu_map__put(evsel->cpus);
evsel->cpus = cpu_map__get(evlist->cpus);
+ } else if (evsel->cpus != evsel->own_cpus) {
+ cpu_map__put(evsel->cpus);
+ evsel->cpus = cpu_map__get(evsel->own_cpus);
}
thread_map__put(evsel->threads);
diff --git a/tools/perf/util/evsel.c b/tools/perf/util/evsel.c
index c53f79123b37..5410483d5219 100644
--- a/tools/perf/util/evsel.c
+++ b/tools/perf/util/evsel.c
@@ -1033,6 +1033,7 @@ void perf_evsel__exit(struct perf_evsel *evsel)
perf_evsel__free_config_terms(evsel);
close_cgroup(evsel->cgrp);
cpu_map__put(evsel->cpus);
+ cpu_map__put(evsel->own_cpus);
thread_map__put(evsel->threads);
zfree(>group_name);
zfree(>name);
diff --git a/tools/perf/util/evsel.h b/tools/perf/util/evsel.h
index 298e6bbca200..ef8925f7211a 100644
--- a/tools/perf/util/evsel.h
+++ b/tools/perf/util/evsel.h
@@ -98,6 +98,7 @@ struct perf_evsel {
struct cgroup_sel *cgrp;
void*handler;
struct cpu_map *cpus;
+ struct cpu_map *own_cpus;
struct thread_map *threads;
unsigned intsample_size;
int id_pos;
diff --git a/tools/perf/util/parse-events.c b/tools/perf/util/parse-events.c
index 7e8ae21906e2..21ed6ee63da9 100644
--- a/tools/perf/util/parse-events.c
+++ b/tools/perf/util/parse-events.c
@@ -287,8 +287,8 @@ __add_event(struct list_head *list, int *idx,
if (!evsel)
return NULL;
- if (cpus)
- evsel->cpus = cpu_map__get(cpus);
+ evsel->cpus = cpu_map__get(cpus);
+ evsel->own_cpus = cpu_map__get(cpus);
if (name)
evsel->name = strdup(name);
--
1.9.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] tile: fix build failure
When building with allmodconfig the build was failing with the error: arch/tile/kernel/usb.c:70:1: warning: data definition has no type or storage class [enabled by default] arch/tile/kernel/usb.c:70:1: error: type defaults to 'int' in declaration of 'arch_initcall' [-Werror=implicit-int] arch/tile/kernel/usb.c:70:1: warning: parameter names (without types) in function declaration [enabled by default] arch/tile/kernel/usb.c:63:19: warning: 'tilegx_usb_init' defined but not used [-Wunused-function] Include linux/module.h to resolve the build failure. Signed-off-by: Sudip Mukherjee --- arch/tile/kernel/usb.c | 1 + 1 file changed, 1 insertion(+) diff --git a/arch/tile/kernel/usb.c b/arch/tile/kernel/usb.c index f0da5a2..9f1e05e 100644 --- a/arch/tile/kernel/usb.c +++ b/arch/tile/kernel/usb.c @@ -22,6 +22,7 @@ #include #include #include +#include #include static u64 ehci_dmamask = DMA_BIT_MASK(32); -- 1.9.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 v5 0/9] Goodix touchscreen enhancements
Add several enhancements to the Goodix touchscreen driver. This version adds runtime power management and includes some cleanup. Thanks, Irina Changes in v5: - add some more style cleanup (reorder includes, use error instead of ret for return values) - add runtime power management patch Changes in v4: - use dmi quirk to determine the order of irq and reset pins - use actual config length depending on device - add sysfs interface to dump config - initialize esd timeout from ACPI/DT propery Changes in v3: - dropped the first 3 patches that got merged - handle -EPROBE_DEFER and -ENOENT for gpio pins - skip functionality depending on the gpio pins if the pins are not properly initialized from ACPI/DT (reset, write config, power management, ESD) - dropped #ifdef CONFIG_PM_SLEEP and annotated with __maybe_unused instead - use sysfs property to set ESD timeout instead of ACPI/DT property - use request_firmware_nowait to read configuration firmware and use defaults if firmware is not found - use ACPI IDs to determine the order of the GPIO pins in the ACPI tables (interrupt pin first or reset pin first) Changes in v2: - use request_firmware instead of ACPI/DT property for config - dropped "input: goodix: add ACPI IDs for GT911 and GT9271" patch - add ACPI DSDT excerpt in commit message where necessary - add comments for suspend/resume sleep values - dropped the checkpatch fixes that did not make sense - added Bastien's ack to the first patch Irina Tirdea (9): Input: goodix - sort includes alphabetically Input: goodix - use actual config length for each device type Input: goodix - reset device at init Input: goodix - write configuration data to device Input: goodix - add power management support Input: goodix - use goodix_i2c_write_u8 instead of i2c_master_send Input: goodix - add support for ESD Input: goodix - add sysfs interface to dump config Input: goodix - add runtime power management support .../bindings/input/touchscreen/goodix.txt | 11 + drivers/input/touchscreen/goodix.c | 709 +++-- 2 files changed, 679 insertions(+), 41 deletions(-) -- 1.9.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 v5 1/9] Input: goodix - sort includes alphabetically
Signed-off-by: Irina Tirdea
---
drivers/input/touchscreen/goodix.c | 12 ++--
1 file changed, 6 insertions(+), 6 deletions(-)
diff --git a/drivers/input/touchscreen/goodix.c
b/drivers/input/touchscreen/goodix.c
index e36162b..6ae28c5 100644
--- a/drivers/input/touchscreen/goodix.c
+++ b/drivers/input/touchscreen/goodix.c
@@ -14,18 +14,18 @@
* Software Foundation; version 2 of the License.
*/
-#include
+#include
+#include
#include
#include
#include
#include
-#include
-#include
-#include
#include
-#include
-#include
+#include
+#include
+#include
#include
+#include
#include
struct goodix_ts_data {
--
1.9.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 v5 3/9] Input: goodix - reset device at init
After power on, it is recommended that the driver resets the device.
The reset procedure timing is described in the datasheet and is used
at device init (before writing device configuration) and
for power management. It is a sequence of setting the interrupt
and reset pins high/low at specific timing intervals. This procedure
also includes setting the slave address to the one specified in the
ACPI/device tree.
This is based on Goodix datasheets for GT911 and GT9271 and on Goodix
driver gt9xx.c for Android (publicly available in Android kernel
trees for various devices).
For reset the driver needs to control the interrupt and
reset gpio pins (configured through ACPI/device tree). For devices
that do not have the gpio pins declared, the functionality depending
on these pins will not be available, but the device can still be used
with basic functionality.
Signed-off-by: Octavian Purdila
Signed-off-by: Irina Tirdea
---
.../bindings/input/touchscreen/goodix.txt | 5 +
drivers/input/touchscreen/goodix.c | 136 +
2 files changed, 141 insertions(+)
diff --git a/Documentation/devicetree/bindings/input/touchscreen/goodix.txt
b/Documentation/devicetree/bindings/input/touchscreen/goodix.txt
index 8ba98ee..c0715f8 100644
--- a/Documentation/devicetree/bindings/input/touchscreen/goodix.txt
+++ b/Documentation/devicetree/bindings/input/touchscreen/goodix.txt
@@ -12,6 +12,8 @@ Required properties:
- reg : I2C address of the chip. Should be 0x5d or 0x14
- interrupt-parent: Interrupt controller to which the chip is connected
- interrupts : Interrupt to which the chip is connected
+ - gpios : GPIOS the chip is connected to: first one is the
+ interrupt gpio and second one the reset gpio.
Example:
@@ -23,6 +25,9 @@ Example:
reg = <0x5d>;
interrupt-parent = <>;
interrupts = <0 0>;
+
+ gpios = < 0 0>, /* INT */
+ < 1 0>; /* RST */
};
/* ... */
diff --git a/drivers/input/touchscreen/goodix.c
b/drivers/input/touchscreen/goodix.c
index 7be6eab..8edfc06 100644
--- a/drivers/input/touchscreen/goodix.c
+++ b/drivers/input/touchscreen/goodix.c
@@ -17,6 +17,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -37,6 +38,8 @@ struct goodix_ts_data {
unsigned int int_trigger_type;
bool rotated_screen;
int cfg_len;
+ struct gpio_desc *gpiod_int;
+ struct gpio_desc *gpiod_rst;
};
#define GOODIX_MAX_HEIGHT 4096
@@ -89,6 +92,30 @@ static const struct dmi_system_id rotated_screen[] = {
{}
};
+/*
+ * ACPI table specifies gpio pins in this order: first rst pin and
+ * then interrupt pin.
+ */
+static const struct dmi_system_id goodix_rst_pin_first[] = {
+#if defined(CONFIG_DMI) && defined(CONFIG_X86)
+ {
+ .ident = "WinBook TW100",
+ .matches = {
+ DMI_MATCH(DMI_SYS_VENDOR, "WinBook"),
+ DMI_MATCH(DMI_PRODUCT_NAME, "TW100")
+ }
+ },
+ {
+ .ident = "WinBook TW700",
+ .matches = {
+ DMI_MATCH(DMI_SYS_VENDOR, "WinBook"),
+ DMI_MATCH(DMI_PRODUCT_NAME, "TW700")
+ },
+ },
+#endif
+ {}
+};
+
/**
* goodix_i2c_read - read data from a register of the i2c slave device.
*
@@ -237,6 +264,102 @@ static irqreturn_t goodix_ts_irq_handler(int irq, void
*dev_id)
return IRQ_HANDLED;
}
+static int goodix_int_sync(struct goodix_ts_data *ts)
+{
+ int error;
+
+ error = gpiod_direction_output(ts->gpiod_int, 0);
+ if (error)
+ return error;
+ msleep(50); /* T5: 50ms */
+
+ return gpiod_direction_input(ts->gpiod_int);
+}
+
+/**
+ * goodix_reset - Reset device during power on
+ *
+ * @ts: goodix_ts_data pointer
+ */
+static int goodix_reset(struct goodix_ts_data *ts)
+{
+ int error;
+
+ /* begin select I2C slave addr */
+ error = gpiod_direction_output(ts->gpiod_rst, 0);
+ if (error)
+ return error;
+ msleep(20); /* T2: > 10ms */
+ /* HIGH: 0x28/0x29, LOW: 0xBA/0xBB */
+ error = gpiod_direction_output(ts->gpiod_int, ts->client->addr == 0x14);
+ if (error)
+ return error;
+ usleep_range(100, 2000);/* T3: > 100us */
+ error = gpiod_direction_output(ts->gpiod_rst, 1);
+ if (error)
+ return error;
+ usleep_range(6000, 1); /* T4: > 5ms */
+ /* end select I2C slave addr */
+ error = gpiod_direction_input(ts->gpiod_rst);
+ if (error)
+ return error;
+ return goodix_int_sync(ts);
+}
+
+/**
+ *
Re: [PATCH v4 1/3] mtd: nand: increase ready wait timeout and report timeouts
Hi Ezequiel,
Thanks for reviewing the series.
On 06/09/2015 21:37, Ezequiel Garcia wrote:
> On 27 Jul 02:50 PM, Alex Smith wrote:
>> If nand_wait_ready() times out, this is silently ignored, and its
>> caller will then proceed to read from/write to the chip before it is
>> ready. This can potentially result in corruption with no indication as
>> to why.
>>
>> While a 20ms timeout seems like it should be plenty enough, certain
>> behaviour can cause it to timeout much earlier than expected. The
>> situation which prompted this change was that CPU 0, which is
>> responsible for updating jiffies, was holding interrupts disabled
>> for a fairly long time while writing to the console during a printk,
>> causing several jiffies updates to be delayed. If CPU 1 happens to
>> enter the timeout loop in nand_wait_ready() just before CPU 0 re-
>> enables interrupts and updates jiffies, CPU 1 will immediately time
>> out when the delayed jiffies updates are made. The result of this is
>> that nand_wait_ready() actually waits less time than the NAND chip
>> would normally take to be ready, and then read_page() proceeds to
>> read out bad data from the chip.
>>
>> The situation described above may seem unlikely, but in fact it can be
>> reproduced almost every boot on the MIPS Creator Ci20.
>>
>
> Not only unlikely but scary :) BTW, can't find SMP patches for Ci20,
> are you sure this behavior will apply once SMP is upstreamed?
Certainly made for fun debugging ;)
SMP support only exists in our 3.18 branch [1] at the moment, which was where
this problem was encountered. Support should be upstreamed at some point, and I
would guess that this behaviour could still happen then (even though it's a
really obscure edge case that we were somehow managing to almost always hit on
boot).
[1] https://github.com/MIPS/CI20_linux
>
>> Debugging this was made more difficult by the misleading comment above
>> nand_wait_ready() stating "The timeout is caught later" - no timeout
>> was ever reported, leading me away from the real source of the problem.
>>
>> Therefore, this patch increases the timeout to 200ms. This should be
>> enough to cover cases where jiffies updates get delayed. Additionally,
>> add a pr_warn() when a timeout does occur so that it is easier to
>> pinpoint any problems in future caused by the chip not becoming ready.
>>
>> Signed-off-by: Alex Smith
>> Cc: Zubair Lutfullah Kakakhel
>> Cc: David Woodhouse
>> Cc: Brian Norris
>> Cc: linux-...@lists.infradead.org
>> Cc: linux-kernel@vger.kernel.org
>> ---
>> v3 -> v4:
>> - New patch to fix issue encountered in external Ci20 3.18 kernel
>>branch which also applies upstream.
>> ---
>> drivers/mtd/nand/nand_base.c | 15 ---
>> 1 file changed, 12 insertions(+), 3 deletions(-)
>>
>> diff --git a/drivers/mtd/nand/nand_base.c b/drivers/mtd/nand/nand_base.c
>> index ceb68ca8277a..a0dab3414f16 100644
>> --- a/drivers/mtd/nand/nand_base.c
>> +++ b/drivers/mtd/nand/nand_base.c
>> @@ -543,23 +543,32 @@ static void panic_nand_wait_ready(struct mtd_info
>> *mtd, unsigned long timeo)
>> }
>> }
>>
>> -/* Wait for the ready pin, after a command. The timeout is caught later. */
>> +/**
>> + * nand_wait_ready - [GENERIC] Wait for the ready pin after commands.
>> + * @mtd: MTD device structure
>> + *
>> + * Wait for the ready pin after a command, and warn if a timeout occurs.
>> + */
>> void nand_wait_ready(struct mtd_info *mtd)
>> {
>> struct nand_chip *chip = mtd->priv;
>> -unsigned long timeo = jiffies + msecs_to_jiffies(20);
>> +unsigned long timeo = jiffies + msecs_to_jiffies(200);
>>
>> /* 400ms timeout */
>> if (in_interrupt() || oops_in_progress)
>> return panic_nand_wait_ready(mtd, 400);
>>
>> led_trigger_event(nand_led_trigger, LED_FULL);
>> +
>
> Spurious change here.
Removed.
>
>> /* Wait until command is processed or timeout occurs */
>> do {
>> if (chip->dev_ready(mtd))
>> -break;
>> +goto out;
>> touch_softlockup_watchdog();
>> } while (time_before(jiffies, timeo));
>> +
>> +pr_warn("timeout while waiting for chip to become ready\n");
>> +out:
>> led_trigger_event(nand_led_trigger, LED_OFF);
>> }
>
> This change looks reasonable, a timeout value should be large enough
> to be confident the operation has _really_ timed out. On non-error
> path, this change shouldn't make any difference.
>
> And the warning is probably helpful too, so:
>
> Reviewed-by: Ezequiel Garcia
Great, thanks.
Alex
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v5 5/9] Input: goodix - add power management support
Implement suspend/resume for goodix driver.
The suspend and resume process uses the gpio pins.
If the device ACPI/DT information does not declare gpio pins,
suspend/resume will not be available for these devices.
This is based on Goodix datasheets for GT911 and GT9271
and on Goodix driver gt9xx.c for Android (publicly available
in Android kernel trees for various devices).
Signed-off-by: Octavian Purdila
Signed-off-by: Irina Tirdea
---
drivers/input/touchscreen/goodix.c | 94 --
1 file changed, 89 insertions(+), 5 deletions(-)
diff --git a/drivers/input/touchscreen/goodix.c
b/drivers/input/touchscreen/goodix.c
index 9cf16ff7..3d4a004 100644
--- a/drivers/input/touchscreen/goodix.c
+++ b/drivers/input/touchscreen/goodix.c
@@ -44,6 +44,7 @@ struct goodix_ts_data {
u16 id;
u16 version;
char *cfg_name;
+ unsigned long irq_flags;
};
#define GOODIX_MAX_HEIGHT 4096
@@ -57,6 +58,9 @@ struct goodix_ts_data {
#define GOODIX_CONFIG_967_LENGTH 228
/* Register defines */
+#define GOODIX_REG_COMMAND 0x8040
+#define GOODIX_CMD_SCREEN_OFF 0x05
+
#define GOODIX_READ_COOR_ADDR 0x814E
#define GOODIX_REG_CONFIG_DATA 0x8047
#define GOODIX_REG_ID 0x8140
@@ -182,6 +186,11 @@ static int goodix_i2c_write(struct i2c_client *client, u16
reg, const u8 *buf,
return ret < 0 ? ret : (ret != 1 ? -EIO : 0);
}
+static int goodix_i2c_write_u8(struct i2c_client *client, u16 reg, u8 value)
+{
+ return goodix_i2c_write(client, reg, , sizeof(value));
+}
+
static int goodix_get_cfg_len(u16 id)
{
switch (id) {
@@ -301,6 +310,18 @@ static irqreturn_t goodix_ts_irq_handler(int irq, void
*dev_id)
return IRQ_HANDLED;
}
+static void goodix_free_irq(struct goodix_ts_data *ts)
+{
+ devm_free_irq(>client->dev, ts->client->irq, ts);
+}
+
+static int goodix_request_irq(struct goodix_ts_data *ts)
+{
+ return devm_request_threaded_irq(>client->dev, ts->client->irq,
+NULL, goodix_ts_irq_handler,
+ts->irq_flags, ts->client->name, ts);
+}
+
/**
* goodix_check_cfg - Checks if config fw is valid
*
@@ -617,7 +638,6 @@ static int goodix_request_input_dev(struct goodix_ts_data
*ts)
static int goodix_configure_dev(struct goodix_ts_data *ts)
{
int error;
- unsigned long irq_flags;
goodix_read_config(ts);
@@ -625,10 +645,8 @@ static int goodix_configure_dev(struct goodix_ts_data *ts)
if (error)
return error;
- irq_flags = goodix_irq_flags[ts->int_trigger_type] | IRQF_ONESHOT;
- error = devm_request_threaded_irq(>client->dev, ts->client->irq,
- NULL, goodix_ts_irq_handler,
- irq_flags, ts->client->name, ts);
+ ts->irq_flags = goodix_irq_flags[ts->int_trigger_type] | IRQF_ONESHOT;
+ error = goodix_request_irq(ts);
if (error) {
dev_err(>client->dev, "request IRQ failed: %d\n", error);
return error;
@@ -732,6 +750,71 @@ static int goodix_ts_probe(struct i2c_client *client,
return goodix_configure_dev(ts);
}
+static int __maybe_unused goodix_suspend(struct device *dev)
+{
+ struct i2c_client *client = to_i2c_client(dev);
+ struct goodix_ts_data *ts = i2c_get_clientdata(client);
+ int error;
+
+ /* We need gpio pins to suspend/resume */
+ if (!ts->gpiod_int || !ts->gpiod_rst)
+ return 0;
+
+ /* Free IRQ as IRQ pin is used as output in the suspend sequence */
+ goodix_free_irq(ts);
+ /* Output LOW on the INT pin for 5 ms */
+ error = gpiod_direction_output(ts->gpiod_int, 0);
+ if (error) {
+ goodix_request_irq(ts);
+ return error;
+ }
+ usleep_range(5000, 6000);
+
+ error = goodix_i2c_write_u8(ts->client, GOODIX_REG_COMMAND,
+ GOODIX_CMD_SCREEN_OFF);
+ if (error) {
+ dev_err(>client->dev, "Screen off command failed\n");
+ gpiod_direction_input(ts->gpiod_int);
+ goodix_request_irq(ts);
+ return -EAGAIN;
+ }
+
+ /*
+* The datasheet specifies that the interval between sending screen-off
+* command and wake-up should be longer than 58 ms. To avoid waking up
+* sooner, delay 58ms here.
+*/
+ msleep(58);
+ return 0;
+}
+
+static int __maybe_unused goodix_resume(struct device *dev)
+{
+ struct i2c_client *client = to_i2c_client(dev);
+ struct goodix_ts_data *ts = i2c_get_clientdata(client);
+ int error;
+
+ if (!ts->gpiod_int || !ts->gpiod_rst)
+ return 0;
+
+ /*
+* Exit sleep mode by outputting HIGH level to INT pin
+* for 2ms~5ms.
+*/
+ error =
[PATCH v5 9/9] Input: goodix - add runtime power management support
Add support for runtime power management so that the device is
turned off when not used (when the userspace holds no open
handles of the input device). The device uses autosuspend with a
default delay of 2 seconds, so the device will suspend if no
handles to it are open for 2 seconds.
The runtime management support is only available if the gpio pins
are properly initialized from ACPI/DT.
Signed-off-by: Irina Tirdea
---
drivers/input/touchscreen/goodix.c | 57 +++---
1 file changed, 53 insertions(+), 4 deletions(-)
diff --git a/drivers/input/touchscreen/goodix.c
b/drivers/input/touchscreen/goodix.c
index 3179767..34c0183 100644
--- a/drivers/input/touchscreen/goodix.c
+++ b/drivers/input/touchscreen/goodix.c
@@ -27,6 +27,7 @@
#include
#include
#include
+#include
#include
#include
@@ -75,6 +76,8 @@ struct goodix_ts_data {
#define MAX_CONTACTS_LOC 5
#define TRIGGER_LOC6
+#define GOODIX_AUTOSUSPEND_DELAY_MS2000
+
static const unsigned long goodix_irq_flags[] = {
IRQ_TYPE_EDGE_RISING,
IRQ_TYPE_EDGE_FALLING,
@@ -566,6 +569,27 @@ static const struct attribute_group goodix_attr_group = {
.attrs = goodix_attrs,
};
+static int goodix_open(struct input_dev *input_dev)
+{
+ struct goodix_ts_data *ts = input_get_drvdata(input_dev);
+ int error;
+
+ error = pm_runtime_get_sync(>client->dev);
+ if (error < 0) {
+ pm_runtime_put_noidle(>client->dev);
+ return error;
+ }
+ return 0;
+}
+
+static void goodix_close(struct input_dev *input_dev)
+{
+ struct goodix_ts_data *ts = input_get_drvdata(input_dev);
+
+ pm_runtime_mark_last_busy(>client->dev);
+ pm_runtime_put_autosuspend(>client->dev);
+}
+
/**
* goodix_get_gpio_config - Get GPIO config from ACPI/DT
*
@@ -751,6 +775,9 @@ static int goodix_request_input_dev(struct goodix_ts_data
*ts)
ts->input_dev->id.vendor = 0x0416;
ts->input_dev->id.product = ts->id;
ts->input_dev->id.version = ts->version;
+ ts->input_dev->open = goodix_open;
+ ts->input_dev->close = goodix_close;
+ input_set_drvdata(ts->input_dev, ts);
error = input_register_device(ts->input_dev);
if (error) {
@@ -798,7 +825,8 @@ static int goodix_configure_dev(struct goodix_ts_data *ts)
* @ts: our goodix_ts_data pointer
*
* request_firmware_wait callback that finishes
- * initialization of the device.
+ * initialization of the device. This will only be called
+ * when ts->gpiod_int and ts->gpiod_rst are properly initialized.
*/
static void goodix_config_cb(const struct firmware *cfg, void *ctx)
{
@@ -811,7 +839,21 @@ static void goodix_config_cb(const struct firmware *cfg,
void *ctx)
if (error)
goto err_release_cfg;
}
- goodix_configure_dev(ts);
+ error = goodix_configure_dev(ts);
+ if (error)
+ goto err_release_cfg;
+
+ error = pm_runtime_set_active(>client->dev);
+ if (error) {
+ dev_err(>client->dev, "failed to set active: %d\n", error);
+ goto err_release_cfg;
+ }
+ /* input_dev is a child of client->dev, ignore it for runtime pm */
+ pm_suspend_ignore_children(>client->dev, true);
+ pm_runtime_enable(>client->dev);
+ pm_runtime_set_autosuspend_delay(>client->dev,
+GOODIX_AUTOSUSPEND_DELAY_MS);
+ pm_runtime_use_autosuspend(>client->dev);
err_release_cfg:
release_firmware(cfg);
@@ -915,8 +957,12 @@ static int goodix_ts_remove(struct i2c_client *client)
{
struct goodix_ts_data *ts = i2c_get_clientdata(client);
- if (ts->gpiod_int && ts->gpiod_rst)
+ if (ts->gpiod_int && ts->gpiod_rst) {
+ pm_runtime_disable(>dev);
+ pm_runtime_set_suspended(>dev);
+ pm_runtime_put_noidle(>dev);
sysfs_remove_group(>dev.kobj, _attr_group);
+ }
goodix_disable_esd(ts);
kfree(ts->cfg_name);
return 0;
@@ -990,7 +1036,10 @@ static int __maybe_unused goodix_resume(struct device
*dev)
return goodix_enable_esd(ts);
}
-static SIMPLE_DEV_PM_OPS(goodix_pm_ops, goodix_suspend, goodix_resume);
+static const struct dev_pm_ops goodix_pm_ops = {
+ SET_SYSTEM_SLEEP_PM_OPS(goodix_suspend, goodix_resume)
+ SET_RUNTIME_PM_OPS(goodix_suspend, goodix_resume, NULL)
+};
static const struct i2c_device_id goodix_ts_id[] = {
{ "GDIX1001:00", 0 },
--
1.9.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] arm64: kernel: Use a separate stack for irq interrupts.
Having to handle interrupts on top of an existing kernel stack means the
kernel stack must be large enough to accomodate both the maximum kernel
usage, and the maximum irq handler usage. Switching to a different stack
when processing irqs allows us to make the stack size smaller.
Maximum kernel stack usage (running ltp and generating usb+ethernet
interrupts) was 7256 bytes. With this patch, the same workload gives
a maximum stack usage of 5816 bytes.
Signed-off-by: James Morse
---
arch/arm64/include/asm/irq.h | 12 +
arch/arm64/include/asm/thread_info.h | 8 --
arch/arm64/kernel/entry.S| 33 ---
arch/arm64/kernel/irq.c | 52
arch/arm64/kernel/smp.c | 4 +++
arch/arm64/kernel/stacktrace.c | 4 ++-
6 files changed, 107 insertions(+), 6 deletions(-)
diff --git a/arch/arm64/include/asm/irq.h b/arch/arm64/include/asm/irq.h
index bbb251b14746..050d4196c736 100644
--- a/arch/arm64/include/asm/irq.h
+++ b/arch/arm64/include/asm/irq.h
@@ -2,14 +2,20 @@
#define __ASM_IRQ_H
#include
+#include
#include
+#include
+
+DECLARE_PER_CPU(unsigned long, irq_sp);
struct pt_regs;
extern void migrate_irqs(void);
extern void set_handle_irq(void (*handle_irq)(struct pt_regs *));
+extern int alloc_irq_stack(unsigned int cpu);
+
static inline void acpi_irq_init(void)
{
/*
@@ -21,4 +27,10 @@ static inline void acpi_irq_init(void)
}
#define acpi_irq_init acpi_irq_init
+static inline bool is_irq_stack(unsigned long sp)
+{
+ struct thread_info *ti = get_thread_info(sp);
+ return (get_thread_info(per_cpu(irq_sp, ti->cpu)) == ti);
+}
+
#endif
diff --git a/arch/arm64/include/asm/thread_info.h
b/arch/arm64/include/asm/thread_info.h
index dcd06d18a42a..b906254fc400 100644
--- a/arch/arm64/include/asm/thread_info.h
+++ b/arch/arm64/include/asm/thread_info.h
@@ -69,12 +69,16 @@ register unsigned long current_stack_pointer asm ("sp");
/*
* how to get the thread information struct from C
*/
+static inline struct thread_info *get_thread_info(unsigned long sp)
+{
+ return (struct thread_info *)(sp & ~(THREAD_SIZE - 1));
+}
+
static inline struct thread_info *current_thread_info(void)
__attribute_const__;
static inline struct thread_info *current_thread_info(void)
{
- return (struct thread_info *)
- (current_stack_pointer & ~(THREAD_SIZE - 1));
+ return get_thread_info(current_stack_pointer);
}
#define thread_saved_pc(tsk) \
diff --git a/arch/arm64/kernel/entry.S b/arch/arm64/kernel/entry.S
index e16351819fed..d42371f3f5a1 100644
--- a/arch/arm64/kernel/entry.S
+++ b/arch/arm64/kernel/entry.S
@@ -190,10 +190,37 @@ tsk .reqx28 // current thread_info
* Interrupt handling.
*/
.macro irq_handler
- adrpx1, handle_arch_irq
- ldr x1, [x1, #:lo12:handle_arch_irq]
- mov x0, sp
+ mrs x21, tpidr_el1
+ adr_l x20, irq_sp
+ add x20, x20, x21
+
+ ldr x21, [x20]
+ mov x20, sp
+
+ mov x0, x21
+ mov x1, x20
+ bl irq_copy_thread_info
+
+ /* test for recursive use of irq_sp */
+ cbz w0, 1f
+ mrs x30, elr_el1
+ mov sp, x21
+
+ /*
+* Create a fake stack frame to bump unwind_frame() onto the original
+* stack. This relies on x29 not being clobbered by kernel_entry().
+*/
+ pushx29, x30
+
+1: ldr_l x1, handle_arch_irq
+ mov x0, x20
blr x1
+
+ mov x0, x20
+ mov x1, x21
+ bl irq_copy_thread_info
+ mov sp, x20
+
.endm
.text
diff --git a/arch/arm64/kernel/irq.c b/arch/arm64/kernel/irq.c
index 463fa2e7e34c..10b57a006da8 100644
--- a/arch/arm64/kernel/irq.c
+++ b/arch/arm64/kernel/irq.c
@@ -26,11 +26,14 @@
#include
#include
#include
+#include
#include
#include
unsigned long irq_err_count;
+DEFINE_PER_CPU(unsigned long, irq_sp) = 0;
+
int arch_show_interrupts(struct seq_file *p, int prec)
{
#ifdef CONFIG_SMP
@@ -55,6 +58,10 @@ void __init init_IRQ(void)
irqchip_init();
if (!handle_arch_irq)
panic("No interrupt controller found.");
+
+ /* Allocate an irq stack for the boot cpu */
+ if (alloc_irq_stack(smp_processor_id()))
+ panic("Failed to allocate irq stack for boot cpu.");
}
#ifdef CONFIG_HOTPLUG_CPU
@@ -117,3 +124,48 @@ void migrate_irqs(void)
local_irq_restore(flags);
}
#endif /* CONFIG_HOTPLUG_CPU */
+
+/* Allocate an irq_stack for a cpu that is about to be brought up. */
+int alloc_irq_stack(unsigned int cpu)
+{
+ struct page *irq_stack_page;
+ union thread_union *irq_stack;
+
+ /* reuse stack allocated previously */
+ if (per_cpu(irq_sp, cpu))
+ return 0;
+
+ irq_stack_page = alloc_kmem_pages(THREADINFO_GFP,
[PATCH v5 7/9] Input: goodix - add support for ESD
Add ESD (Electrostatic Discharge) protection mechanism.
The driver enables ESD protection in HW and checks a register
to determine if ESD occurred. If ESD is signalled by the HW,
the driver will reset the device.
The ESD poll time (in ms) can be set through the sysfs property
esd_timeout. If it is set to 0, ESD protection is disabled.
Recommended value is 2000 ms. The initial value for ESD timeout
can be set through esd-recovery-timeout-ms ACPI/DT property.
If there is no such property defined, ESD protection is disabled.
For ACPI 5.1, the property can be specified using _DSD properties:
Device (STAC)
{
Name (_HID, "GDIX1001")
...
Name (_DSD, Package ()
{
ToUUID("daffd814-6eba-4d8c-8a91-bc9bbf4aa301"),
Package ()
{
Package (2) { "esd-recovery-timeout-ms", Package(1) { 2000 }},
...
}
})
}
The ESD protection mechanism is only available if the gpio pins
are properly initialized from ACPI/DT.
This is based on Goodix datasheets for GT911 and GT9271 and on Goodix
driver gt9xx.c for Android (publicly available in Android kernel
trees for various devices).
Signed-off-by: Irina Tirdea
---
.../bindings/input/touchscreen/goodix.txt | 6 +
drivers/input/touchscreen/goodix.c | 174 -
2 files changed, 173 insertions(+), 7 deletions(-)
diff --git a/Documentation/devicetree/bindings/input/touchscreen/goodix.txt
b/Documentation/devicetree/bindings/input/touchscreen/goodix.txt
index c0715f8..5891ad1 100644
--- a/Documentation/devicetree/bindings/input/touchscreen/goodix.txt
+++ b/Documentation/devicetree/bindings/input/touchscreen/goodix.txt
@@ -14,6 +14,12 @@ Required properties:
- interrupts : Interrupt to which the chip is connected
- gpios : GPIOS the chip is connected to: first one is the
interrupt gpio and second one the reset gpio.
+Optional properties:
+
+ - esd-recovery-timeout-ms : ESD poll time (in milli seconds) for the driver to
+check if ESD occurred and in that case reset the
+device. ESD is disabled if this property is not set
+or is set to 0.
Example:
diff --git a/drivers/input/touchscreen/goodix.c
b/drivers/input/touchscreen/goodix.c
index 03f3968..33a7b81 100644
--- a/drivers/input/touchscreen/goodix.c
+++ b/drivers/input/touchscreen/goodix.c
@@ -45,8 +45,12 @@ struct goodix_ts_data {
u16 version;
char *cfg_name;
unsigned long irq_flags;
+ atomic_t esd_timeout;
+ struct delayed_work esd_work;
};
+#define GOODIX_DEVICE_ESD_TIMEOUT_PROPERTY "esd-recovery-timeout-ms"
+
#define GOODIX_MAX_HEIGHT 4096
#define GOODIX_MAX_WIDTH 4096
#define GOODIX_INT_TRIGGER 1
@@ -60,6 +64,8 @@ struct goodix_ts_data {
/* Register defines */
#define GOODIX_REG_COMMAND 0x8040
#define GOODIX_CMD_SCREEN_OFF 0x05
+#define GOODIX_CMD_ESD_ENABLED 0xAA
+#define GOODIX_REG_ESD_CHECK 0x8041
#define GOODIX_READ_COOR_ADDR 0x814E
#define GOODIX_REG_CONFIG_DATA 0x8047
@@ -426,6 +432,117 @@ static int goodix_reset(struct goodix_ts_data *ts)
return goodix_int_sync(ts);
}
+static void goodix_disable_esd(struct goodix_ts_data *ts)
+{
+ if (!atomic_read(>esd_timeout))
+ return;
+ cancel_delayed_work_sync(>esd_work);
+}
+
+static int goodix_enable_esd(struct goodix_ts_data *ts)
+{
+ int error, esd_timeout;
+
+ esd_timeout = atomic_read(>esd_timeout);
+ if (!esd_timeout)
+ return 0;
+
+ error = goodix_i2c_write_u8(ts->client, GOODIX_REG_ESD_CHECK,
+ GOODIX_CMD_ESD_ENABLED);
+ if (error) {
+ dev_err(>client->dev, "Failed to enable ESD: %d\n", error);
+ return error;
+ }
+
+ schedule_delayed_work(>esd_work, round_jiffies_relative(
+ msecs_to_jiffies(esd_timeout)));
+ return 0;
+}
+
+static void goodix_esd_work(struct work_struct *work)
+{
+ struct goodix_ts_data *ts = container_of(work, struct goodix_ts_data,
+esd_work.work);
+ int retries = 3, error;
+ u8 esd_data[2];
+ const struct firmware *cfg = NULL;
+
+ while (--retries) {
+ error = goodix_i2c_read(ts->client, GOODIX_REG_COMMAND,
+ esd_data, sizeof(esd_data));
+ if (error)
+ continue;
+ if (esd_data[0] != GOODIX_CMD_ESD_ENABLED &&
+ esd_data[1] == GOODIX_CMD_ESD_ENABLED) {
+ /* feed the watchdog */
+ goodix_i2c_write_u8(ts->client,
+ GOODIX_REG_COMMAND,
+
[PATCH v5 8/9] Input: goodix - add sysfs interface to dump config
Goodix devices have a configuration information register area that
specify various parameters for the device. The configuration information
has a specific format described in the Goodix datasheet. It includes X/Y
resolution, maximum supported touch points, interrupt flags, various
sesitivity factors and settings for advanced features (like gesture
recognition).
Export a sysfs interface that would allow reading the configuration
information. The default device configuration can be used as a starting
point for creating a valid configuration firmware used by the device at
init time to update its configuration.
This sysfs interface will be exported only if the gpio pins are properly
initialized from ACPI/DT.
Signed-off-by: Irina Tirdea
---
drivers/input/touchscreen/goodix.c | 23 +++
1 file changed, 23 insertions(+)
diff --git a/drivers/input/touchscreen/goodix.c
b/drivers/input/touchscreen/goodix.c
index 33a7b81..3179767 100644
--- a/drivers/input/touchscreen/goodix.c
+++ b/drivers/input/touchscreen/goodix.c
@@ -530,12 +530,35 @@ static ssize_t goodix_esd_timeout_store(struct device
*dev,
return count;
}
+static ssize_t goodix_dump_config_show(struct device *dev,
+ struct device_attribute *attr, char *buf)
+{
+ struct goodix_ts_data *ts = dev_get_drvdata(dev);
+ u8 config[GOODIX_CONFIG_MAX_LENGTH];
+ int error, count = 0, i;
+
+ error = goodix_i2c_read(ts->client, GOODIX_REG_CONFIG_DATA,
+ config, ts->cfg_len);
+ if (error) {
+ dev_warn(>client->dev,
+"Error reading config (%d)\n", error);
+ return error;
+ }
+
+ for (i = 0; i < ts->cfg_len; i++)
+ count += scnprintf(buf + count, PAGE_SIZE - count, "%02x ",
+ config[i]);
+ return count;
+}
+
/* ESD timeout in ms. Default disabled (0). Recommended 2000 ms. */
static DEVICE_ATTR(esd_timeout, S_IRUGO | S_IWUSR, goodix_esd_timeout_show,
goodix_esd_timeout_store);
+static DEVICE_ATTR(dump_config, S_IRUGO, goodix_dump_config_show, NULL);
static struct attribute *goodix_attrs[] = {
_attr_esd_timeout.attr,
+ _attr_dump_config.attr,
NULL
};
--
1.9.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 v5 6/9] Input: goodix - use goodix_i2c_write_u8 instead of i2c_master_send
Use goodix_i2c_write_u8 instead of i2c_master_send to simplify code.
Signed-off-by: Irina Tirdea
---
drivers/input/touchscreen/goodix.c | 7 +--
1 file changed, 1 insertion(+), 6 deletions(-)
diff --git a/drivers/input/touchscreen/goodix.c
b/drivers/input/touchscreen/goodix.c
index 3d4a004..03f3968 100644
--- a/drivers/input/touchscreen/goodix.c
+++ b/drivers/input/touchscreen/goodix.c
@@ -295,16 +295,11 @@ static void goodix_process_events(struct goodix_ts_data
*ts)
*/
static irqreturn_t goodix_ts_irq_handler(int irq, void *dev_id)
{
- static const u8 end_cmd[] = {
- GOODIX_READ_COOR_ADDR >> 8,
- GOODIX_READ_COOR_ADDR & 0xff,
- 0
- };
struct goodix_ts_data *ts = dev_id;
goodix_process_events(ts);
- if (i2c_master_send(ts->client, end_cmd, sizeof(end_cmd)) < 0)
+ if (goodix_i2c_write_u8(ts->client, GOODIX_READ_COOR_ADDR, 0) < 0)
dev_err(>client->dev, "I2C write end_cmd error\n");
return IRQ_HANDLED;
--
1.9.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 v5 2/9] Input: goodix - use actual config length for each device type
Each of the Goodix devices supported by this driver has a fixed size for
the configuration information registers. The size varies depending on the
device and is specified in the datasheet.
Use the proper configuration length as specified in the datasheet for
each device model, so we do not read more than the actual size of the
configuration registers.
Signed-off-by: Irina Tirdea
---
drivers/input/touchscreen/goodix.c | 25 +++--
1 file changed, 23 insertions(+), 2 deletions(-)
diff --git a/drivers/input/touchscreen/goodix.c
b/drivers/input/touchscreen/goodix.c
index 6ae28c5..7be6eab 100644
--- a/drivers/input/touchscreen/goodix.c
+++ b/drivers/input/touchscreen/goodix.c
@@ -36,6 +36,7 @@ struct goodix_ts_data {
unsigned int max_touch_num;
unsigned int int_trigger_type;
bool rotated_screen;
+ int cfg_len;
};
#define GOODIX_MAX_HEIGHT 4096
@@ -45,6 +46,8 @@ struct goodix_ts_data {
#define GOODIX_MAX_CONTACTS10
#define GOODIX_CONFIG_MAX_LENGTH 240
+#define GOODIX_CONFIG_911_LENGTH 186
+#define GOODIX_CONFIG_967_LENGTH 228
/* Register defines */
#define GOODIX_READ_COOR_ADDR 0x814E
@@ -115,6 +118,23 @@ static int goodix_i2c_read(struct i2c_client *client,
return ret < 0 ? ret : (ret != ARRAY_SIZE(msgs) ? -EIO : 0);
}
+static int goodix_get_cfg_len(u16 id)
+{
+ switch (id) {
+ case 911:
+ case 9271:
+ case 9110:
+ case 927:
+ case 928:
+ return GOODIX_CONFIG_911_LENGTH;
+ case 912:
+ case 967:
+ return GOODIX_CONFIG_967_LENGTH;
+ default:
+ return GOODIX_CONFIG_MAX_LENGTH;
+ }
+}
+
static int goodix_ts_read_input_report(struct goodix_ts_data *ts, u8 *data)
{
int touch_num;
@@ -230,8 +250,7 @@ static void goodix_read_config(struct goodix_ts_data *ts)
int error;
error = goodix_i2c_read(ts->client, GOODIX_REG_CONFIG_DATA,
- config,
- GOODIX_CONFIG_MAX_LENGTH);
+ config, ts->cfg_len);
if (error) {
dev_warn(>client->dev,
"Error reading config (%d), using defaults\n",
@@ -398,6 +417,8 @@ static int goodix_ts_probe(struct i2c_client *client,
return error;
}
+ ts->cfg_len = goodix_get_cfg_len(id_info);
+
goodix_read_config(ts);
error = goodix_request_input_dev(ts, version_info, id_info);
--
1.9.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 v5 4/9] Input: goodix - write configuration data to device
Goodix devices can be configured by writing custom data to the device at
init. The configuration data is read with request_firmware from
"goodix__cfg.bin", where is the product id read from the device
(e.g.: goodix_911_cfg.bin for Goodix GT911, goodix_9271_cfg.bin for
GT9271).
The configuration information has a specific format described in the Goodix
datasheet. It includes X/Y resolution, maximum supported touch points,
interrupt flags, various sesitivity factors and settings for advanced
features (like gesture recognition).
Before writing the firmware, it is necessary to reset the device. If
the device ACPI/DT information does not declare gpio pins (needed for
reset), writing the firmware will not be available for these devices.
This is based on Goodix datasheets for GT911 and GT9271 and on Goodix
driver gt9xx.c for Android (publicly available in Android kernel
trees for various devices).
Signed-off-by: Octavian Purdila
Signed-off-by: Irina Tirdea
---
drivers/input/touchscreen/goodix.c | 225 +++--
1 file changed, 192 insertions(+), 33 deletions(-)
diff --git a/drivers/input/touchscreen/goodix.c
b/drivers/input/touchscreen/goodix.c
index 8edfc06..9cf16ff7 100644
--- a/drivers/input/touchscreen/goodix.c
+++ b/drivers/input/touchscreen/goodix.c
@@ -17,6 +17,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -40,6 +41,9 @@ struct goodix_ts_data {
int cfg_len;
struct gpio_desc *gpiod_int;
struct gpio_desc *gpiod_rst;
+ u16 id;
+ u16 version;
+ char *cfg_name;
};
#define GOODIX_MAX_HEIGHT 4096
@@ -145,6 +149,39 @@ static int goodix_i2c_read(struct i2c_client *client,
return ret < 0 ? ret : (ret != ARRAY_SIZE(msgs) ? -EIO : 0);
}
+/**
+ * goodix_i2c_write - write data to a register of the i2c slave device.
+ *
+ * @client: i2c device.
+ * @reg: the register to write to.
+ * @buf: raw data buffer to write.
+ * @len: length of the buffer to write
+ */
+static int goodix_i2c_write(struct i2c_client *client, u16 reg, const u8 *buf,
+ unsigned len)
+{
+ u8 *addr_buf;
+ struct i2c_msg msg;
+ int ret;
+
+ addr_buf = kmalloc(len + 2, GFP_KERNEL);
+ if (!addr_buf)
+ return -ENOMEM;
+
+ addr_buf[0] = reg >> 8;
+ addr_buf[1] = reg & 0xFF;
+ memcpy(_buf[2], buf, len);
+
+ msg.flags = 0;
+ msg.addr = client->addr;
+ msg.buf = addr_buf;
+ msg.len = len + 2;
+
+ ret = i2c_transfer(client->adapter, , 1);
+ kfree(addr_buf);
+ return ret < 0 ? ret : (ret != 1 ? -EIO : 0);
+}
+
static int goodix_get_cfg_len(u16 id)
{
switch (id) {
@@ -264,6 +301,73 @@ static irqreturn_t goodix_ts_irq_handler(int irq, void
*dev_id)
return IRQ_HANDLED;
}
+/**
+ * goodix_check_cfg - Checks if config fw is valid
+ *
+ * @ts: goodix_ts_data pointer
+ * @cfg: firmware config data
+ */
+static int goodix_check_cfg(struct goodix_ts_data *ts,
+ const struct firmware *cfg)
+{
+ int i, raw_cfg_len;
+ u8 check_sum = 0;
+
+ if (cfg->size > GOODIX_CONFIG_MAX_LENGTH) {
+ dev_err(>client->dev,
+ "The length of the config fw is not correct");
+ return -EINVAL;
+ }
+
+ raw_cfg_len = cfg->size - 2;
+ for (i = 0; i < raw_cfg_len; i++)
+ check_sum += cfg->data[i];
+ check_sum = (~check_sum) + 1;
+ if (check_sum != cfg->data[raw_cfg_len]) {
+ dev_err(>client->dev,
+ "The checksum of the config fw is not correct");
+ return -EINVAL;
+ }
+
+ if (cfg->data[raw_cfg_len + 1] != 1) {
+ dev_err(>client->dev,
+ "Config fw must have Config_Fresh register set");
+ return -EINVAL;
+ }
+
+ return 0;
+}
+
+/**
+ * goodix_send_cfg - Write fw config to device
+ *
+ * @ts: goodix_ts_data pointer
+ * @cfg: config firmware to write to device
+ */
+static int goodix_send_cfg(struct goodix_ts_data *ts,
+ const struct firmware *cfg)
+{
+ int error;
+
+ error = goodix_check_cfg(ts, cfg);
+ if (error)
+ return error;
+
+ error = goodix_i2c_write(ts->client, GOODIX_REG_CONFIG_DATA, cfg->data,
+cfg->size);
+ if (error) {
+ dev_err(>client->dev, "Failed to write config data: %d",
+ error);
+ return error;
+ }
+ dev_dbg(>client->dev, "Config sent successfully.");
+
+ /* Let the firmware reconfigure itself, so sleep for 10ms */
+ usleep_range(1, 11000);
+
+ return 0;
+}
+
static int goodix_int_sync(struct goodix_ts_data *ts)
{
int error;
@@ -406,30 +510,29 @@ static void goodix_read_config(struct goodix_ts_data *ts)
/**
* goodix_read_version - Read
Re: [PATCH 0/6] sched/fair: Compute capacity invariant load/utilization tracking
On 07/09/15 13:42, Peter Zijlstra wrote:
> On Mon, Aug 31, 2015 at 11:24:49AM +0200, Peter Zijlstra wrote:
>
>> A quick run here gives:
>>
>> IVB-EP (2*20*2):
>
> As noted by someone; that should be 2*10*2, for a total of 40 cpus in
> this machine.
>
>>
>> perf stat --null --repeat 10 -- perf bench sched messaging -g 50 -l 5000
>>
>> Before: After:
>> 5.484170711 ( +- 0.74% )5.590001145 ( +- 0.45% )
>>
>> Which is an almost 2% slowdown :/
>>
>> I've yet to look at what happens.
>
> OK, so it appears this is link order nonsense. When I compared profiles
> between the series, the one function that had significant change was
> skb_release_data(), which doesn't make much sense.
>
> If I do a 'make clean' in front of each build, I get a repeatable
> improvement with this patch set (although how much of that is due to the
> patches itself or just because of code movement is as yet undetermined).
>
> I'm of a mind to apply these patches; with two patches on top, which
> I'll post shortly.
>
-- >8 --
From: Dietmar Eggemann
Date: Mon, 7 Sep 2015 14:57:22 +0100
Subject: [PATCH] sched/fair: Defer calling scaling functions
Do not call the scaling functions in case time goes backwards or the
last update of the sched_avg structure has happened less than 1024ns
ago.
Signed-off-by: Dietmar Eggemann
---
kernel/sched/fair.c | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c
index d6ca8d987a63..3445d2fb38f4 100644
--- a/kernel/sched/fair.c
+++ b/kernel/sched/fair.c
@@ -2552,8 +2552,7 @@ __update_load_avg(u64 now, int cpu, struct sched_avg *sa,
u64 delta, scaled_delta, periods;
u32 contrib;
unsigned int delta_w, scaled_delta_w, decayed = 0;
- unsigned long scale_freq = arch_scale_freq_capacity(NULL, cpu);
- unsigned long scale_cpu = arch_scale_cpu_capacity(NULL, cpu);
+ unsigned long scale_freq, scale_cpu;
delta = now - sa->last_update_time;
/*
@@ -2574,6 +2573,9 @@ __update_load_avg(u64 now, int cpu, struct sched_avg *sa,
return 0;
sa->last_update_time = now;
+ scale_freq = arch_scale_freq_capacity(NULL, cpu);
+ scale_cpu = arch_scale_cpu_capacity(NULL, cpu);
+
/* delta_w is the amount already accumulated against our next period */
delta_w = sa->period_contrib;
if (delta + delta_w >= 1024) {
--
1.9.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/
similar files: fusbh200-hcd.c and fotg210-hcd.c
I executed a clone detection tool* on drivers source code and I found that the files drivers/usb/host/fusbh200-hcd.c and drivers/usb/host/fotg210-hcd.c are very similar. The main difference between the two files are replacing the string 'USBH20' by 'OTG21' and some white space fixes. Some changes are being applied to only one of the files, such as the commit f848a88d223cafa43cb318839a1171b498cf5ec8 that changes fotg210-hcd.c but not fusbh200-hcd.c. Should these files be consolidated? And if so how? Thank you, Peter * https://github.com/petersenna/ccfinderx-core -- Peter -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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 2/3] arm64: Introduce IRQ stack
On 04/09/15 15:23, Jungseok Lee wrote:
> Currently, kernel context and interrupts are handled using a single
> kernel stack navigated by sp_el1. This forces many systems to use
> 16KB stack, not 8KB one. Low memory platforms naturally suffer from
> both memory pressure and performance degradation simultaneously as
> VM page allocator falls into slowpath frequently.
>
> This patch, thus, solves the problem as introducing a separate percpu
> IRQ stack to handle both hard and soft interrupts with two ground rules:
>
> - Utilize sp_el0 in EL1 context, which is not used currently
> - Do *not* complicate current_thread_info calculation
>
> struct thread_info can be tracked easily using sp_el0, not sp_el1 when
> this feature is enabled.
>
> Signed-off-by: Jungseok Lee
> ---
> arch/arm64/Kconfig.debug | 10 ++
> arch/arm64/include/asm/irq.h | 8 ++
> arch/arm64/include/asm/thread_info.h | 11 ++
> arch/arm64/kernel/asm-offsets.c | 8 ++
> arch/arm64/kernel/entry.S| 83 +++-
> arch/arm64/kernel/head.S | 7 ++
> arch/arm64/kernel/irq.c | 18
> 7 files changed, 142 insertions(+), 3 deletions(-)
>
> diff --git a/arch/arm64/Kconfig.debug b/arch/arm64/Kconfig.debug
> index d6285ef..e16d91f 100644
> --- a/arch/arm64/Kconfig.debug
> +++ b/arch/arm64/Kconfig.debug
> @@ -18,6 +18,16 @@ config ARM64_PTDUMP
> kernel.
> If in doubt, say "N"
>
> +config IRQ_STACK
> + bool "Use separate kernel stack when handling interrupts"
> + depends on ARM64_4K_PAGES
> + help
> + Say Y here if you want to use separate kernel stack to handle both
> + hard and soft interrupts. As reduceing memory footprint regarding
> + kernel stack, it benefits low memory platforms.
> +
> + If in doubt, say N.
> +
I don't think it is necessary to have a debug-only Kconfig option for this.
Reducing memory use is good for everyone!
This would let you get rid of all the #ifdefs
> config STRICT_DEVMEM
> bool "Filter access to /dev/mem"
> depends on MMU
> diff --git a/arch/arm64/include/asm/thread_info.h
> b/arch/arm64/include/asm/thread_info.h
> index dcd06d1..5345a67 100644
> --- a/arch/arm64/include/asm/thread_info.h
> +++ b/arch/arm64/include/asm/thread_info.h
> @@ -71,11 +71,22 @@ register unsigned long current_stack_pointer asm ("sp");
> */
> static inline struct thread_info *current_thread_info(void)
> __attribute_const__;
>
> +#ifndef CONFIG_IRQ_STACK
> static inline struct thread_info *current_thread_info(void)
> {
> return (struct thread_info *)
> (current_stack_pointer & ~(THREAD_SIZE - 1));
> }
> +#else
> +static inline struct thread_info *current_thread_info(void)
> +{
> + unsigned long sp_el0;
> +
> + asm volatile("mrs %0, sp_el0" : "=r" (sp_el0));
> +
> + return (struct thread_info *)(sp_el0 & ~(THREAD_SIZE - 1));
> +}
> +#endif
Because sp_el0 is only used as a stack value to find struct thread_info,
you could just store the struct thread_info pointer in sp_el0, and save the
masking on each read of the value.
>
> #define thread_saved_pc(tsk) \
> ((unsigned long)(tsk->thread.cpu_context.pc))
> diff --git a/arch/arm64/kernel/entry.S b/arch/arm64/kernel/entry.S
> index d23ca0d..f1fdfa9 100644
> --- a/arch/arm64/kernel/entry.S
> +++ b/arch/arm64/kernel/entry.S
> @@ -88,7 +88,11 @@
>
> .if \el == 0
> mrs x21, sp_el0
> +#ifndef CONFIG_IRQ_STACK
> get_thread_info tsk // Ensure MDSCR_EL1.SS is clear,
> +#else
> + get_thread_info \el, tsk
> +#endif
> ldr x19, [tsk, #TI_FLAGS] // since we can unmask debug
> disable_step_tsk x19, x20 // exceptions when scheduling.
> .endif
> @@ -168,11 +172,56 @@
> eret// return to kernel
> .endm
>
> +#ifndef CONFIG_IRQ_STACK
> .macro get_thread_info, rd
> mov \rd, sp
> - and \rd, \rd, #~(THREAD_SIZE - 1) // top of stack
> + and \rd, \rd, #~(THREAD_SIZE - 1) // bottom of stack
> + .endm
> +#else
> + .macro get_thread_info, el, rd
> + .if \el == 0
> + mov \rd, sp
> + .else
> + mrs \rd, sp_el0
> + .endif
> + and \rd, \rd, #~(THREAD_SIZE - 1) // bottom of thread stack
> + .endm
> +
> + .macro get_irq_stack
> + get_thread_info 1, tsk
> + ldr w22, [tsk, #TI_CPU]
> + adr_l x21, irq_stacks
> + mov x23, #IRQ_STACK_SIZE
> + maddx21, x22, x23, x21
> .endm
Using per_cpu variables would save the multiply here.
You then wouldn't need IRQ_STACK_SIZE.
>
> + .macro irq_stack_entry
> + get_irq_stack
> + ldr w23, [x21, #IRQ_COUNT]
> + cbnzw23, 1f
> + mov x23, sp
> + str x23, [x21, #IRQ_THREAD_SP]
> + ldr x23, [x21, #IRQ_STACK]
> + mov sp, x23
> + mov x23, xzr
> +1: add w23,
Re: [RFC PATCH 1/3] arm64: entry: Remove unnecessary calculation for S_SP in EL1h
On 04/09/15 15:23, Jungseok Lee wrote: > Under EL1h, S_SP data is not seen in kernel_exit. Thus, x21 calculation > is not needed in kernel_entry. Currently, S_SP information is vaild only > when sp_el0 is used. > > Signed-off-by: Jungseok Lee > diff --git a/arch/arm64/kernel/entry.S b/arch/arm64/kernel/entry.S > index e163518..d23ca0d 100644 > --- a/arch/arm64/kernel/entry.S > +++ b/arch/arm64/kernel/entry.S > @@ -91,8 +91,6 @@ > get_thread_info tsk // Ensure MDSCR_EL1.SS is clear, > ldr x19, [tsk, #TI_FLAGS] // since we can unmask debug > disable_step_tsk x19, x20 // exceptions when scheduling. > - .else > - add x21, sp, #S_FRAME_SIZE > .endif > mrs x22, elr_el1 > mrs x23, spsr_el1 > This sp value gets written to the struct pt_regs that is built on the stack, and passed to the fault handlers, see 'el1_sp_pc' in kernel/entry.S, which goes on to call do_sp_pc_abort() which prints this value out. (Other fault handlers may make decisions based on this value). It should be present and correct. Thanks, James -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v4 3/3] mtd: nand: jz4780: driver for NAND devices on JZ4780 SoCs
Hi,
On 06/09/2015 22:21, Ezequiel Garcia wrote:
> On 27 Jul 03:21 PM, Alex Smith wrote:
>> Add a driver for NAND devices connected to the NEMC on JZ4780 SoCs, as
>> well as the hardware BCH controller. DMA is not currently implemented.
>>
>> While older 47xx SoCs also have a BCH controller, they are incompatible
>> with the one in the 4780 due to differing register/bit positions, which
>> would make implementing a common driver for them quite messy.
>>
>
> If the difference is only in register/bit positions, a common driver
> might be fairly simple. See drivers/i2c/busses/i2c-mv64xxx.c,
> which supports two different register layouts.
I've just gone back and looked at the older SoCs and it doesn't seem as though
this commit message really applies to the JZ4740, which is the only other
Ingenic SoC currently supported upstream. The 4740 doesn't have a BCH
controller at all and the NAND interface is fairly different. I think this
driver could potentially be reused if support for the JZ4770 makes it upstream,
for now though a separate driver is certainly needed for the 4780.
>> +return 0;
>> +}
>> +
>> +static const struct of_device_id jz4780_bch_dt_match[] = {
>> +{ .compatible = "ingenic,jz4780-bch" },
>> +{},
>> +};
>> +MODULE_DEVICE_TABLE(of, jz4780_bch_dt_match);
>> +
>> +static struct platform_driver jz4780_bch_driver = {
>> +.probe = jz4780_bch_probe,
>
> Why no remove?
Is it needed? Everything should be cleaned up due to the use of devm functions.
>> +static int jz4780_nand_init_chips(struct jz4780_nand *nand, struct device
>> *dev)
>> +{
>> +struct jz4780_nand_chip *chip;
>> +const __be32 *prop;
>> +u64 addr, size;
>> +int i = 0;
>> +
>> +/*
>> + * Iterate over each bank assigned to this device and request resources.
>> + * The bank numbers may not be consecutive, but nand_scan_ident()
>> + * expects chip numbers to be, so fill out a consecutive array of chips
>> + * which map chip number to actual bank number.
>> + */
>> +while ((prop = of_get_address(dev->of_node, i, , NULL))) {
>> +chip = >chips[i];
>> +chip->bank = of_read_number(prop, 1);
>> +
>> +jz4780_nemc_set_type(nand->dev, chip->bank,
>> + JZ4780_NEMC_BANK_NAND);
>> +
>> +addr = of_translate_address(dev->of_node, prop);
>
> Are you sure you must translate the address yourself?
> Isn't this handled by the OF magic behing the ranges property
> in the NEMC DT node?
I think the reasoning behind doing this was because I already have to get the
address property here in order to get the bank number out of it.
You're right though that I can just do "platform_get_resource(pdev, i)" and
avoid doing the translation again, so I have changed it to do that.
I've fixed the rest of your comments as well.
Thanks,
Alex
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2 2/2] leds: leds-ipaq-micro: Fix coding style issues
Hi Muhammad,
On 09/07/2015 04:13 PM, Muhammad Falak R Wani wrote:
Spaces at the starting of a line are removed, indentation
using tab, instead of space. Also, warnings related to
line width of more than 80 characters is also taken care of.
Two warnings have been left alone to aid better readability.
Signed-off-by: Muhammad Falak R Wani
---
drivers/leds/leds-ipaq-micro.c | 38 +++---
1 file changed, 19 insertions(+), 19 deletions(-)
diff --git a/drivers/leds/leds-ipaq-micro.c b/drivers/leds/leds-ipaq-micro.c
index 1206215..86716ea 100644
--- a/drivers/leds/leds-ipaq-micro.c
+++ b/drivers/leds/leds-ipaq-micro.c
@@ -16,9 +16,9 @@
#define LED_YELLOW0x00
#define LED_GREEN 0x01
-#define LED_EN (1 << 4)/* LED ON/OFF 0:off, 1:on
*/
-#define LED_AUTOSTOP(1 << 5)/* LED ON/OFF auto stop set 0:disable,
1:enable */
-#define LED_ALWAYS (1 << 6)/* LED Interrupt Mask 0:No mask,
1:mask */
+#define LED_EN (1 << 4) /* LED ON/OFF 0:off, 1:on*/
+#define LED_AUTOSTOP (1 << 5) /* LED ON/OFF auto stop set 0:disable,1:enable*/
+#define LED_ALWAYS(1 << 6) /* LED Interrupt Mask 0:No mask, 1:mask*/
Please keep comments ending in the same column.
static void micro_leds_brightness_set(struct led_classdev *led_cdev,
enum led_brightness value)
@@ -27,14 +27,14 @@ static void micro_leds_brightness_set(struct led_classdev
*led_cdev,
/*
* In this message:
* Byte 0 = LED color: 0 = yellow, 1 = green
-* yellow LED is always ~30 blinks per minute
+*yellow LED is always ~30 blinks per minute
* Byte 1 = duration (flags?) appears to be ignored
* Byte 2 = green ontime in 1/10 sec (deciseconds)
-* 1 = 1/10 second
-* 0 = 256/10 second
+*1 = 1/10 second
+*0 = 256/10 second
* Byte 3 = green offtime in 1/10 sec (deciseconds)
-* 1 = 1/10 second
-* 0 = 256/10 seconds
+*1 = 1/10 second
+*0 = 256/10 seconds
*/
struct ipaq_micro_msg msg = {
.id = MSG_NOTIFY_LED,
@@ -64,14 +64,14 @@ static int micro_leds_blink_set(struct led_classdev
*led_cdev,
/*
* In this message:
* Byte 0 = LED color: 0 = yellow, 1 = green
-* yellow LED is always ~30 blinks per minute
+*yellow LED is always ~30 blinks per minute
* Byte 1 = duration (flags?) appears to be ignored
* Byte 2 = green ontime in 1/10 sec (deciseconds)
-* 1 = 1/10 second
-* 0 = 256/10 second
+*1 = 1/10 second
+*0 = 256/10 second
* Byte 3 = green offtime in 1/10 sec (deciseconds)
-* 1 = 1/10 second
-* 0 = 256/10 seconds
+*1 = 1/10 second
+*0 = 256/10 seconds
*/
This looks worse after applying the patch. Why actually did you change
it? AFAICS checkpatch.pl doesn't complain here.
struct ipaq_micro_msg msg = {
.id = MSG_NOTIFY_LED,
@@ -79,14 +79,14 @@ static int micro_leds_blink_set(struct led_classdev
*led_cdev,
};
msg.tx_data[0] = LED_GREEN;
-if (*delay_on > IPAQ_LED_MAX_DUTY ||
+ if (*delay_on > IPAQ_LED_MAX_DUTY ||
*delay_off > IPAQ_LED_MAX_DUTY)
-return -EINVAL;
+ return -EINVAL;
-if (*delay_on == 0 && *delay_off == 0) {
-*delay_on = 100;
-*delay_off = 100;
-}
+ if (*delay_on == 0 && *delay_off == 0) {
+ *delay_on = 100;
+ *delay_off = 100;
+ }
msg.tx_data[1] = 0;
if (*delay_on >= IPAQ_LED_MAX_DUTY)
--
Best Regards,
Jacek Anaszewski
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v4 0/3] mtd: nand: jz4780: Add NAND and BCH drivers
On 06/09/2015 21:38, Ezequiel Garcia wrote:
> On 27 Jul 02:50 PM, Alex Smith wrote:
>> Hi,
>>
>> This series adds support for the BCH controller and NAND devices on
>> the Ingenic JZ4780 SoC.
>>
>> Tested on the MIPS Creator Ci20 board. All dependencies are now in
>> mainline so it should be possible to compile test now.
>>
>> This version of the series has been rebased on 4.2-rc4, and also adds
>> an additional patch to fix an issue that was encountered in the
>> external Ci20 3.18 kernel branch.
>>
>> Review and feedback welcome.
>>
>
> The NEMC driver seems to be upstream. Any chance you submit devicetree
> changes as well for Ci20 (so we can actually test this)?
Sure, can do. The pinctrl driver is not yet upstream (needs some work) which is
why I didn't add the DT changes initially, but at least if you boot the board
from the NAND then U-Boot should have left everything in a state usable by the
kernel.
Thanks,
Alex
>
>> Thanks,
>> Alex
>>
>> Alex Smith (3):
>> mtd: nand: increase ready wait timeout and report timeouts
>> dt-bindings: binding for jz4780-{nand,bch}
>> mtd: nand: jz4780: driver for NAND devices on JZ4780 SoCs
>>
>> .../bindings/mtd/ingenic,jz4780-nand.txt | 57
>> drivers/mtd/nand/Kconfig | 7 +
>> drivers/mtd/nand/Makefile | 1 +
>> drivers/mtd/nand/jz4780_bch.c | 354 +++
>> drivers/mtd/nand/jz4780_bch.h | 42 +++
>> drivers/mtd/nand/jz4780_nand.c | 376
>> +
>> drivers/mtd/nand/nand_base.c | 15 +-
>> 7 files changed, 849 insertions(+), 3 deletions(-)
>> create mode 100644
>> Documentation/devicetree/bindings/mtd/ingenic,jz4780-nand.txt
>> create mode 100644 drivers/mtd/nand/jz4780_bch.c
>> create mode 100644 drivers/mtd/nand/jz4780_bch.h
>> create mode 100644 drivers/mtd/nand/jz4780_nand.c
>>
>> --
>> 2.4.6
>>
>>
>> __
>> Linux MTD discussion mailing list
>> http://lists.infradead.org/mailman/listinfo/linux-mtd/
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] powerpc32: memcpy: only use dcbz once cache is enabled
On Mon, Sep 07 2015, Christophe Leroy wrote: > memcpy() uses instruction dcbz to speed up copy by not wasting time > loading cache line with data that will be overwritten. > Some platform like mpc52xx do no have cache active at startup and > can therefore not use memcpy(). Allthough no part of the code > explicitly uses memcpy(), GCC makes calls to it. > > This patch modifies memcpy() such that at startup, the 'dcbz' > instruction is replaced by 'dcbt' which is harmless if cache is not > enabled, and which helps a bit (allthough not as much as dcbz) if > cache is already enabled. > > Once the initial MMU is setup, in machine_init() we patch memcpy() > by replacing the temporary 'dcbt' by 'dcbz' > > Reported-by: Michal Sojka > Signed-off-by: Christophe Leroy > --- > @Michal, can you please test it ? Yes, it works. Tested-by: Michal Sojka -Michal -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC PATCH v1 2/4] irqchip: GICv3: set non-percpu irqs status with _IRQ_MOVE_PCNTXT
Hi Thomas,
On 07/09/15 14:24, Thomas Gleixner wrote:
> On Mon, 7 Sep 2015, Marc Zyngier wrote:
>> On 06/09/15 06:56, Jiang Liu wrote:
>>> On 2015/9/6 12:23, Yang Yingliang wrote:
Use irq_settings_set_move_pcntxt() helper irqs status with
_IRQ_MOVE_PCNTXT. So that it can do set affinity when calling
irq_set_affinity_locked().
>>> Hi Yingliang,
>>> We could only set _IRQ_MOVE_PCNTCT flag to enable migrating
>>> IRQ in process context if your hardware platform supports atomically
>>> change IRQ configuration. Not sure whether that's true for GICv3.
>>> If GICv3 doesn't support atomically change irq configuration, this
>>> change may cause trouble.
>>
>> I think it boils down to what exactly "process context" means here. If
>> this means "we do not need to mask the interrupt" while moving it, then
>> it should be fine (the GIC architecture guarantees that a pending
>> interrupt will be migrated).
>>
>> Is there any other requirement for this flag?
>
> The history of this flag is as follows:
>
> On x86 interrupts can only be safely migrated while the interrupt is
> handled.
Woa! That's creative! :-) I suppose this doesn't work very well with CPU
hotplug though...
> With the introduction of IRQ remapping this requirement
> changed. Remapped interrupts can be migrated in any context.
>
> If you look at irq_set_affinity_locked()
>
>if (irq_can_move_pcntxt(data) {
> irq_do_set_affinity(data,...)
> chip->irq_set_affinity(data,...);
>} else {
> irqd_set_move_pending(data);
>}
>
> So if IRQ_MOVE_PCNTXT is not set, we handle the migration of the
> interrupt from next the interrupt. If it's set set_affinity() is
> called right away.
OK, that is now starting to make more sense.
> All architectures which do not select GENERIC_PENDING_IRQ are using
> the direct method.
Right. On ARM, only the direct method makes sense so far (we have no
constraint such as the one you describe above).
So I wonder why we bother introducing the IRQ_MOVE_PCNTXT flag on ARM at
all. Is that just because migration.c is only compiled when
GENERIC_PENDING_IRQ is set?
Thanks,
M.
--
Jazz is not dead. It just smells funny...
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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 1/3] arm64: entry: Remove unnecessary calculation for S_SP in EL1h
On Fri, Sep 04, 2015 at 03:23:05PM +0100, Jungseok Lee wrote: > Under EL1h, S_SP data is not seen in kernel_exit. Thus, x21 calculation > is not needed in kernel_entry. Currently, S_SP information is vaild only > when sp_el0 is used. I don't think this is true. The generic BUG implementation will grab the saved SP from the pt_regs, and with this change we'll report whatever happened to be in x21 instead. > Signed-off-by: Jungseok Lee > --- > arch/arm64/kernel/entry.S | 2 -- > 1 file changed, 2 deletions(-) > > diff --git a/arch/arm64/kernel/entry.S b/arch/arm64/kernel/entry.S > index e163518..d23ca0d 100644 > --- a/arch/arm64/kernel/entry.S > +++ b/arch/arm64/kernel/entry.S > @@ -91,8 +91,6 @@ > get_thread_info tsk // Ensure MDSCR_EL1.SS is clear, > ldr x19, [tsk, #TI_FLAGS] // since we can unmask debug > disable_step_tsk x19, x20 // exceptions when scheduling. > - .else > - add x21, sp, #S_FRAME_SIZE > .endif > mrs x22, elr_el1 > mrs x23, spsr_el1 Immediately after this we do: stp lr, x21, [sp, #S_LR] To store the LR and SP to the pt_regs which bug_handler would use. Am I missing smoething? Thanks, Mark. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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] rcu: Show the real fqs_state
On Fri 2015-09-04 16:24:22, Paul E. McKenney wrote:
> On Fri, Sep 04, 2015 at 02:11:29PM +0200, Petr Mladek wrote:
> > The value of "fqs_state" in struct rcu_state is always RCU_GP_IDLE.
> >
> > The real state is stored in a local variable in rcu_gp_kthread().
> > It is modified by rcu_gp_fqs() via parameter and return value.
> > But the actual value is never stored to rsp->fqs_state.
> >
> > The result is that print_one_rcu_state() does not show the real
> > state.
> >
> > This code has been added 3 years ago by the commit 4cdfc175c25c89ee
> > ("rcu: Move quiescent-state forcing into kthread"). I guess that it
> > was an overlook or optimization.
> >
> > Anyway, the value seems to be manipulated only by the thread, except
> > for shoving the status. I do not see any risk in updating it directly
> > in the struct.
> >
> > Signed-off-by: Petr Mladek
>
> Good catch, but how about the following fix instead?
>
> Thanx, Paul
>
>
>
> rcu: Finish folding ->fqs_state into ->gp_state
>
> Commit commit 4cdfc175c25c89ee ("rcu: Move quiescent-state forcing
> into kthread") started the process of folding the old ->fqs_state
> into ->gp_state, but did not complete it. This situation does not
> cause any malfunction, but can result in extremely confusing trace
> output. This commit completes this task of eliminating ->fqs_state
> in favor of ->gp_state.
It makes sense but it breaks dynticks handling in rcu_gp_fqs(), see
below.
>
> Reported-by: Petr Mladek
> Signed-off-by: Paul E. McKenney
>
> diff --git a/kernel/rcu/tree.c b/kernel/rcu/tree.c
> index 69ab7ce2cf7b..04234936d897 100644
> --- a/kernel/rcu/tree.c
> +++ b/kernel/rcu/tree.c
> @@ -1949,16 +1949,15 @@ static bool rcu_gp_fqs_check_wake(struct rcu_state
> *rsp, int *gfp)
> /*
> * Do one round of quiescent-state forcing.
> */
> -static int rcu_gp_fqs(struct rcu_state *rsp, int fqs_state_in)
> +static void rcu_gp_fqs(struct rcu_state *rsp)
> {
> - int fqs_state = fqs_state_in;
> bool isidle = false;
> unsigned long maxj;
> struct rcu_node *rnp = rcu_get_root(rsp);
>
> WRITE_ONCE(rsp->gp_activity, jiffies);
> rsp->n_force_qs++;
> - if (fqs_state == RCU_SAVE_DYNTICK) {
> + if (rsp->gp_state == RCU_SAVE_DYNTICK) {
This will never happen because rcu_gp_kthread() modifies rsp->gp_state
many times. The last value before calling rcu_gp_fqs() is
RCU_GP_DOING_FQS.
I think about passing this information via a separate bool.
[...]
> diff --git a/kernel/rcu/tree.h b/kernel/rcu/tree.h
> index d5f58e717c8b..9faad70a8246 100644
> --- a/kernel/rcu/tree.h
> +++ b/kernel/rcu/tree.h
> @@ -417,12 +417,11 @@ struct rcu_data {
> struct rcu_state *rsp;
> };
>
> -/* Values for fqs_state field in struct rcu_state. */
> +/* Values for gp_state field in struct rcu_state. */
> #define RCU_GP_IDLE 0 /* No grace period in progress. */
This value seems to be used instead of the new RCU_GP_WAIT_INIT.
> #define RCU_GP_INIT 1 /* Grace period being
> #initialized. */
This value is unused.
> #define RCU_SAVE_DYNTICK 2 /* Need to scan dyntick
> #state. */
This one is not longer preserved when merged with the other state.
> #define RCU_FORCE_QS 3 /* Need to force quiescent
> #state. */
The meaning of this one is strange. If I get it correctly,
it is set after the state was forced. But the comment suggests
that it is before.
By other words, these states seems to get obsoleted by
/* Values for rcu_state structure's gp_flags field. */
#define RCU_GP_WAIT_INIT 0 /* Initial state. */
#define RCU_GP_WAIT_GPS 1 /* Wait for grace-period start. */
#define RCU_GP_DONE_GPS 2 /* Wait done for grace-period start. */
#define RCU_GP_WAIT_FQS 3 /* Wait for force-quiescent-state time. */
#define RCU_GP_DOING_FQS 4 /* Wait done for force-quiescent-state time. */
#define RCU_GP_CLEANUP 5 /* Grace-period cleanup started. */
#define RCU_GP_CLEANED 6 /* Grace-period cleanup complete. */
Please, find below your commit updated with my ideas:
+ used bool save_dyntick instead of RCU_SAVE_DYNTICK
and RCU_FORCE_QS states
+ rename RCU_GP_WAIT_INIT -> RCU_GP_IDLE
+ remove all the obsolete states
I am sorry if I handled "Signed-off-by" flags a wrong way. It is
basically your patch with few small updates from me. I am not sure
what is the right process in this case. Feel free to use Reviewed-by
instead of Signed-off-by with my name.
Well, I guess that this is not the final state ;-)
>From 61a1bf6659f4f4c0c4021f185bc156f8c83f9ea5 Mon Sep 17 00:00:00 2001
From: "Paul E. McKenney"
Date: Fri, 4 Sep 2015 16:24:22 -0700
Subject: [PATCH] rcu: Finish folding ->fqs_state into ->gp_state
Commit commit 4cdfc175c25c89ee ("rcu: Move
Re: [PATCH v2 1/2] leds: leds-ipaq-micro: Use devm_led_classdev_register
On 09/07/2015 04:13 PM, Muhammad Falak R Wani wrote: Use of resource-managed function devm_led_classdev_register instead of led_classdev_register is preferred, consequently remove redundant function micro_leds_remove. Signed-off-by: Muhammad Falak R Wani --- drivers/leds/leds-ipaq-micro.c | 9 + 1 file changed, 1 insertion(+), 8 deletions(-) Merged, thanks. -- Best Regards, Jacek Anaszewski -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC PATCH v1 2/4] irqchip: GICv3: set non-percpu irqs status with _IRQ_MOVE_PCNTXT
On Mon, 7 Sep 2015, Marc Zyngier wrote: > On 07/09/15 14:24, Thomas Gleixner wrote: > > The history of this flag is as follows: > > > > On x86 interrupts can only be safely migrated while the interrupt is > > handled. > > Woa! That's creative! :-) I suppose this doesn't work very well with CPU > hotplug though... Go figure > So I wonder why we bother introducing the IRQ_MOVE_PCNTXT flag on ARM at > all. Is that just because migration.c is only compiled when > GENERIC_PENDING_IRQ is set? Looks like. We can distangle that, if this code needs to be reusable. Thanks, tglx -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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] powerpc32: memcpy: only use dcbz once cache is enabled
From: Christophe Leroy > Sent: 07 September 2015 15:25 ... > diff --git a/arch/powerpc/lib/copy_32.S b/arch/powerpc/lib/copy_32.S > index 2ef50c6..05b3096 100644 > --- a/arch/powerpc/lib/copy_32.S > +++ b/arch/powerpc/lib/copy_32.S > @@ -172,7 +172,16 @@ _GLOBAL(memcpy) > mtctr r0 > beq 63f > 53: > - dcbzr11,r6 > + /* > + * During early init, cache might not be active yet, so dcbz cannot be > + * used. We put dcbt instead of dcbz. If cache is not active, it's just > + * like a not. If cache is active, at least it prefetchs the line to be ^^^ nop ?? David > + * overwritten. > + * Will be replaced by dcbz in machine_init() > + */ > +_GLOBAL(ppc32_memcpy_dcbz) > + dcbtr11,r6 > + > COPY_16_BYTES > #if L1_CACHE_BYTES >= 32 > COPY_16_BYTES > -- > 2.1.0
[PATCH v2] 9p: trans_fd, bail out if recv fcall if missing
req->rc is pre-allocated early on with p9_tag_alloc and shouldn't be missing
Signed-off-by: Dominique Martinet
---
net/9p/trans_fd.c | 13 ++---
1 file changed, 6 insertions(+), 7 deletions(-)
Feel free to adapt error code/message if you can think of something better.
diff --git a/net/9p/trans_fd.c b/net/9p/trans_fd.c
index a270dcc..a6d89c0 100644
--- a/net/9p/trans_fd.c
+++ b/net/9p/trans_fd.c
@@ -356,13 +356,12 @@ static void p9_read_work(struct work_struct *work)
}
if (m->req->rc == NULL) {
- m->req->rc = kmalloc(sizeof(struct p9_fcall) +
- m->client->msize, GFP_NOFS);
- if (!m->req->rc) {
- m->req = NULL;
- err = -ENOMEM;
- goto error;
- }
+ p9_debug(P9_DEBUG_ERROR,
+"No recv fcall for tag %d (req %p),
disconnecting!\n",
+m->rc.tag, m->req);
+ m->req = NULL;
+ err = -EIO;
+ goto error;
}
m->rc.sdata = (char *)m->req->rc + sizeof(struct p9_fcall);
memcpy(m->rc.sdata, m->tmp_buf, m->rc.capacity);
--
1.8.3.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/
similar files amd vs radeon
I executed a clone detection tool* on drivers source code and I found that there are similar files between drivers/gpu/drm/amd/ and drivers/gpu/drm/radeon, but also inside each of theses folders. Some examples: drivers/gpu/drm/amd/amdgpu/dce_v11_0.c,drivers/gpu/drm/amd/amdgpu/dce_v10_0.c drivers/gpu/drm/amd/amdgpu/ci_dpm.c,drivers/gpu/drm/radeon/ci_dpm.c drivers/gpu/drm/radeon/kv_dpm.c,drivers/gpu/drm/amd/amdgpu/kv_dpm.c I use meld for seeing the differences and similarities. More results from the tool at: http://pastebin.com/iX3fhifG (The number on the first field is the number of probable cloned lines of code). Should these files be consolidated? And if so how? Thank you, Peter * https://github.com/petersenna/ccfinderx-core -- Peter -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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 v8 2/2] ARM: imx: support suspend states on imx7D
On Fri, Jul 31, 2015 at 04:33:59PM -0500, Shenwei Wang wrote: > IMX7D contains a new version of GPC IP block (GPCv2). It has two > major functions: power management and wakeup source management. > > GPCv2 provides low power mode control for Cortex-A7 and Cortex-M4 > domains. And it can support WAIT, STOP, and DSM(Deep Sleep Mode) modes. > After configuring the GPCv2 module, the platform can enter into a > selected mode either automatically triggered by ARM WFI instruction or > manually by software. The system will exit the low power states > by the predefined wakeup sources which are managed by the gpcv2 > irqchip driver. > > This patch adds a new suspend driver to manage the power states on IMX7D. > It currently supports "SUSPEND_STANDBY" and "SUSPEND_MEM" states. > > Signed-off-by: Shenwei Wang > Signed-off-by: Anson Huang Please stop sending patches to my Linaro mailbox, and use shawn...@kernel.org instead. You should already get that if you ever run ./scripts/get_maintainer.pl on the patch. Also please always copy ker...@pengutronix.de for i.MX platform patches like this. > --- > arch/arm/mach-imx/Kconfig| 1 + > arch/arm/mach-imx/Makefile | 2 + > arch/arm/mach-imx/common.h | 4 + > arch/arm/mach-imx/pm-imx7.c | 917 > +++ > arch/arm/mach-imx/suspend-imx7.S | 529 ++ > 5 files changed, 1453 insertions(+) 1453 lines addition to kernel only for i.MX7D suspend support. Yes, this is the way we support suspend on i.MX6, but that's enough, and we have to stop this somewhere. I would ask you to take Sudeep's comment and adopt PSCI for i.MX7D power management. Shawn [1] https://lkml.org/lkml/2015/8/26/554 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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] rcu: Fix up timeouts for forcing the quiescent state
On Fri 2015-09-04 16:49:46, Paul E. McKenney wrote:
> On Fri, Sep 04, 2015 at 02:11:30PM +0200, Petr Mladek wrote:
> > The deadline to force the quiescent state (jiffies_force_qs) is currently
> > updated only when the previous timeout passed. But the timeout used for
> > wait_event() is always the entire original timeout. This is strange.
>
> They tell me that kthreads aren't supposed to every catch signals,
> hence the WARN_ON() in the early-exit case stray-signal case.
Yup, I have investigated this recently. All signals are really blocked
for kthreads by default. There are few threads that use signals but
they explicitly enable it by allow_signal().
> In the case where we were awakened with an explicit force-quiescent-state
> request, we do the scan, and then wait the full time for the next scan.
> So the point of the delay is to space out the scans, not to fit a
> pre-determined schedule.
>
> The reason we get awakened with an explicit force-quiescent-state
> request is that a given CPU just got inundated with RCU callbacks
> or that rcutorture wants to hammer this code path.
>
> So I am not seeing this as anything in need of fixing.
>
> Am I missing something subtle here?
There is the commit 88d6df612cc3c99f5 ("rcu: Prevent spurious-wakeup
DoS attack on rcu_gp_kthread()"). It suggests that the spurious
wakeups are possible.
I would consider this patch as a fix/clean up of this Dos attack fix.
Huh, I forgot to mention it in the commit message.
To be honest, I personally do not know how to trigger the spurious
wakeup in the current state of the code. I am trying to convert
the kthread into the kthread worker API and there I got the spurious
wakeups but this is another story.
Thanks a lot for reviewing.
Best Regards,
Petr
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[GIT PULL] regmap updates for v4.3
The following changes since commit 64291f7db5bd8150a74ad2036f1037e6a0428df2: Linux 4.2 (2015-08-30 11:34:09 -0700) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/broonie/regmap.git tags/regmap-v4.3 for you to fetch changes up to 072502a67c9164625288cca17704808e6c06273f: Merge remote-tracking branches 'regmap/topic/lockdep' and 'regmap/topic/seq-delay' into regmap-next (2015-09-04 17:22:10 +0100) regmap: Changes for v4.3 This has been a busy release for regmap. By far the biggest set of changes here are those from Markus Pargmann which implement support for block transfers in smbus devices. This required quite a bit of refactoring but leaves us better able to handle odd restrictions that controllers may have and with better performance on smbus. Other new features include: - Fix interactions with lockdep for nested regmaps (eg, when a device using regmap is connected to a bus where the bus controller has a separate regmap). Lockdep's default class identification is too crude to work without help. - Support for must write bitfield operations, useful for operations which require writing a bit to trigger them from Kuniori Morimoto. - Support for delaying during register patch application from Nariman Poushin. - Support for overriding cache state via the debugfs implementation from Richard Fitzgerald. Axel Lin (1): regmap: debugfs: Fix misuse of IS_ENABLED Kuninori Morimoto (3): regmap: add force_write option on _regmap_update_bits() regmap: add regmap_write_bits() regmap: add regmap_fields_force_write() Lars-Peter Clausen (1): regmap: Add better support for devices without readback support Mark Brown (9): regmap: Silence warning on invalid zero length read Merge branches 'fix/raw', 'topic/core', 'topic/i2c', 'topic/raw' and 'topic/doc' of git://git.kernel.org/.../broonie/regmap into regmap-smbus-block regmap: Support bulk reads for devices without raw formatting Merge branch 'topic/smbus-block' of git://git.kernel.org/.../broonie/regmap into regmap-core Merge remote-tracking branch 'regmap/fix/core' into regmap-linus Merge remote-tracking branch 'regmap/fix/raw' into regmap-linus Merge remote-tracking branch 'regmap/topic/core' into regmap-next Merge remote-tracking branches 'regmap/topic/debugfs' and 'regmap/topic/force-update' into regmap-next Merge remote-tracking branches 'regmap/topic/lockdep' and 'regmap/topic/seq-delay' into regmap-next Markus Pargmann (11): regmap: Fix integertypes for register address and value regmap: Fix regmap_can_raw_write check regmap: regmap_raw_read return error on !bus->read regmap: Fix regmap_bulk_write for bus writes regmap: Split use_single_rw internally into use_single_read/write regmap: No multi_write support if bus->write does not exist regmap: Add missing comments about struct regmap_bus regmap: Introduce max_raw_read/write for regmap_bulk_read/write regmap: regmap max_raw_read/write getter functions regmap: Add raw_write/read checks for max_raw_write/read sizes regmap-i2c: Add smbus i2c block support Nariman Poushin (2): regmap: Use reg_sequence for multi_reg_write / register_patch regmap: Apply optional delay in multi_reg_write/register_patch Nicolas Boichat (4): mfd: vexpress: Add parentheses around bridge->ops->regmap_init call thermal: sti: Add parentheses around bridge->ops->regmap_init call regmap: Use different lockdep class for each regmap init call regmap: Move documentation to regmap.h Richard Fitzgerald (2): debugfs: Export bool read/write functions regmap: debugfs: Allow writes to cache state settings Sergey SENOZHATSKY (1): regmap: fix a NULL pointer dereference in __regmap_init Stephen Boyd (1): regulator: core: Print at debug level on debugfs creation failure Xiubo Li (1): regmap: fix typos in regmap.c drivers/base/regmap/internal.h | 12 +- drivers/base/regmap/regcache.c | 2 +- drivers/base/regmap/regmap-ac97.c| 41 ++-- drivers/base/regmap/regmap-debugfs.c | 99 - drivers/base/regmap/regmap-i2c.c | 90 +--- drivers/base/regmap/regmap-irq.c | 4 +- drivers/base/regmap/regmap-mmio.c| 52 ++--- drivers/base/regmap/regmap-spi.c | 41 ++-- drivers/base/regmap/regmap-spmi.c| 78 +++ drivers/base/regmap/regmap.c | 368 + drivers/bus/vexpress-config.c| 2 +- drivers/gpu/drm/i2c/adv7511.c| 2 +- drivers/input/misc/drv260x.c | 6 +- drivers/input/misc/drv2665.c | 2 +- drivers/input/misc/drv2667.c | 4 +- drivers/mfd/arizona-core.c | 2 +- drivers/mfd/twl6040.c
