Re: [PATCH] ARM: dts: imx5: Add dts files for USB armory.

[Peter Chen]

On Mon, Apr 27, 2015 at 03:37:08PM +0200, Andrej Rosano wrote:
 Hi Shawn,
 
 On Mon, Apr 27, 2015 at 07:57:48PM +0800, Shawn Guo wrote:
  +Peter
  
  On Fri, Mar 27, 2015 at 01:23:00PM -0700, Vagrant Cascadian wrote:
   Add support for the USB armory board by Inverse Path. This board
   features a Freescale iMX53 SoC, 512MB RAM, and USB OTG operating in
   either peripheral or host mode, and 5 GPIO pins.
   
   One .dtb is generated for operating in peripheral mode, and one is
   generated for operating in host mode.
  
  Vagrant,
  
  Does that mean this board can work in peripheral or host mode but can
  switch between them at run-time?
 
 The board can switch between host and peripheral mode without any
 hardware modification, but it need to reboot itself to pick up the
 corresponding dtb file. I am not sure if there is possible using the
 devicetree overlay feature to switch between the two modes runtime.
 

Not a good way, it is just one board with two different usb cables.

Current chipidea usb driver supports role switch function well, if you
have a gpio or id pin for it.

Peter

 Andrej
 
  
  Shawn
  
   
   Signed-off-by: Vagrant Cascadian vagr...@debian.org
   Cc: Andrej Rosano and...@inversepath.com
   Cc: Rob Herring robh...@kernel.org
   Cc: Pawel Moll pawel.m...@arm.com
   Cc: Mark Rutland mark.rutl...@arm.com
   Cc: Ian Campbell ijc+devicet...@hellion.org.uk
   Cc: Kumar Gala ga...@codeaurora.org
   Cc: Russell King li...@arm.linux.org.uk
   Cc: Shawn Guo shawn@linaro.org
   Cc: Sascha Hauer ker...@pengutronix.de
   Cc: devicet...@vger.kernel.org
   Cc: linux-arm-ker...@lists.infradead.org
   Cc: linux-kernel@vger.kernel.org
   ---
arch/arm/boot/dts/Makefile  |   2 +
arch/arm/boot/dts/imx53-usbarmory-host_mode.dts |  17 +++
arch/arm/boot/dts/imx53-usbarmory.dts   |  13 ++
arch/arm/boot/dts/imx53-usbarmory.dtsi  | 183 
   
4 files changed, 215 insertions(+)
create mode 100644 arch/arm/boot/dts/imx53-usbarmory-host_mode.dts
create mode 100644 arch/arm/boot/dts/imx53-usbarmory.dts
create mode 100644 arch/arm/boot/dts/imx53-usbarmory.dtsi
   
   diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
   index a1c776b..bd2258b 100644
   --- a/arch/arm/boot/dts/Makefile
   +++ b/arch/arm/boot/dts/Makefile
   @@ -244,6 +244,8 @@ dtb-$(CONFIG_SOC_IMX53) += \
 imx53-smd.dtb \
 imx53-tx53-x03x.dtb \
 imx53-tx53-x13x.dtb \
   + imx53-usbarmory.dtb \
   + imx53-usbarmory-host_mode.dtb \
 imx53-voipac-bsb.dtb
dtb-$(CONFIG_SOC_IMX6Q) += \
 imx6dl-aristainetos_4.dtb \
   diff --git a/arch/arm/boot/dts/imx53-usbarmory-host_mode.dts 
   b/arch/arm/boot/dts/imx53-usbarmory-host_mode.dts
   new file mode 100644
   index 000..a94cb1d
   --- /dev/null
   +++ b/arch/arm/boot/dts/imx53-usbarmory-host_mode.dts
   @@ -0,0 +1,17 @@
   +/*
   + * Copyright 2015 Inverse Path, S.r.l.
   + *
   + * The code contained herein is licensed under the GNU General Public
   + * License. You may obtain a copy of the GNU General Public License
   + * Version 2 or later at the following locations:
   + *
   + * http://www.opensource.org/licenses/gpl-license.html
   + * http://www.gnu.org/copyleft/gpl.html
   + */
   +
   +/dts-v1/;
   +#include imx53-usbarmory.dtsi
   +
   +usbotg {
   + dr_mode = host;
   +};
   diff --git a/arch/arm/boot/dts/imx53-usbarmory.dts 
   b/arch/arm/boot/dts/imx53-usbarmory.dts
   new file mode 100644
   index 000..c86a4d8
   --- /dev/null
   +++ b/arch/arm/boot/dts/imx53-usbarmory.dts
   @@ -0,0 +1,13 @@
   +/*
   + * Copyright 2015 Inverse Path, S.r.l.
   + *
   + * The code contained herein is licensed under the GNU General Public
   + * License. You may obtain a copy of the GNU General Public License
   + * Version 2 or later at the following locations:
   + *
   + * http://www.opensource.org/licenses/gpl-license.html
   + * http://www.gnu.org/copyleft/gpl.html
   + */
   +
   +/dts-v1/;
   +#include imx53-usbarmory.dtsi
   diff --git a/arch/arm/boot/dts/imx53-usbarmory.dtsi 
   b/arch/arm/boot/dts/imx53-usbarmory.dtsi
   new file mode 100644
   index 000..b4a9052
   --- /dev/null
   +++ b/arch/arm/boot/dts/imx53-usbarmory.dtsi
   @@ -0,0 +1,183 @@
   +/*
   + * Copyright 2015 Inverse Path, S.r.l.
   + *
   + * The code contained herein is licensed under the GNU General Public
   + * License. You may obtain a copy of the GNU General Public License
   + * Version 2 or later at the following locations:
   + *
   + * http://www.opensource.org/licenses/gpl-license.html
   + * http://www.gnu.org/copyleft/gpl.html
   + */
   +
   +#include imx53.dtsi
   +
   +/ {
   + model = Inverse Path USB armory;
   + compatible = inversepath,imx53-usbarmory, fsl,imx53;
   +};
   +
   +/ {
   + chosen {
   + stdout-path = uart1;
   + };
   +
   + memory {
   + reg = 0x7000 0x2000;
   + };
   +
   + leds {
   + compatible = gpio-leds;
   +

[PATCH 01/13] thermal: consistently use int for temperatures

[Sascha Hauer]

The thermal code uses int, long and unsigned long for temperatures
in different places. Using an unsigned type limits the thermal framework
to positive temperatures without need. 'long' is 64bit on several
architectures which is not needed. Consistently use a plain 'int'
for temperatures.

Signed-off-by: Sascha Hauer s.ha...@pengutronix.de
---
 drivers/acpi/thermal.c | 12 +-
 drivers/hwmon/lm75.c   |  2 +-
 drivers/hwmon/ntc_thermistor.c |  2 +-
 drivers/hwmon/tmp102.c |  2 +-
 drivers/input/touchscreen/sun4i-ts.c   |  8 +++
 drivers/platform/x86/acerhdf.c |  9 
 drivers/power/power_supply_core.c  |  2 +-
 drivers/thermal/armada_thermal.c   |  2 +-
 drivers/thermal/db8500_thermal.c   |  7 +++---
 drivers/thermal/dove_thermal.c |  2 +-
 drivers/thermal/fair_share.c   |  2 +-
 drivers/thermal/gov_bang_bang.c|  5 ++--
 drivers/thermal/imx_thermal.c  | 27 +++---
 .../thermal/int340x_thermal/int340x_thermal_zone.c | 10 
 .../thermal/int340x_thermal/int340x_thermal_zone.h |  8 +++
 drivers/thermal/intel_soc_dts_thermal.c|  7 +++---
 drivers/thermal/of-thermal.c   | 14 +--
 drivers/thermal/rcar_thermal.c |  7 +++---
 drivers/thermal/rockchip_thermal.c | 10 
 drivers/thermal/samsung/exynos_tmu.c   | 19 ---
 drivers/thermal/spear_thermal.c|  2 +-
 drivers/thermal/st/st_thermal.c|  5 ++--
 drivers/thermal/step_wise.c|  4 ++--
 drivers/thermal/tegra_soctherm.c   |  4 ++--
 drivers/thermal/thermal_core.c | 26 ++---
 drivers/thermal/thermal_hwmon.c| 10 
 drivers/thermal/ti-soc-thermal/ti-thermal-common.c | 10 
 drivers/thermal/x86_pkg_temp_thermal.c | 10 
 include/linux/thermal.h| 26 +
 29 files changed, 120 insertions(+), 134 deletions(-)

diff --git a/drivers/acpi/thermal.c b/drivers/acpi/thermal.c
index d24fa19..68bff60 100644
--- a/drivers/acpi/thermal.c
+++ b/drivers/acpi/thermal.c
@@ -529,8 +529,7 @@ static void acpi_thermal_check(void *data)
 
 /* sys I/F for generic thermal sysfs support */
 
-static int thermal_get_temp(struct thermal_zone_device *thermal,
-   unsigned long *temp)
+static int thermal_get_temp(struct thermal_zone_device *thermal, int *temp)
 {
struct acpi_thermal *tz = thermal-devdata;
int result;
@@ -637,7 +636,7 @@ static int thermal_get_trip_type(struct thermal_zone_device 
*thermal,
 }
 
 static int thermal_get_trip_temp(struct thermal_zone_device *thermal,
-int trip, unsigned long *temp)
+int trip, int *temp)
 {
struct acpi_thermal *tz = thermal-devdata;
int i;
@@ -690,7 +689,8 @@ static int thermal_get_trip_temp(struct thermal_zone_device 
*thermal,
 }
 
 static int thermal_get_crit_temp(struct thermal_zone_device *thermal,
-   unsigned long *temperature) {
+   int *temperature)
+{
struct acpi_thermal *tz = thermal-devdata;
 
if (tz-trips.critical.flags.valid) {
@@ -713,8 +713,8 @@ static int thermal_get_trend(struct thermal_zone_device 
*thermal,
return -EINVAL;
 
if (type == THERMAL_TRIP_ACTIVE) {
-   unsigned long trip_temp;
-   unsigned long temp = DECI_KELVIN_TO_MILLICELSIUS_WITH_OFFSET(
+   int trip_temp;
+   int temp = DECI_KELVIN_TO_MILLICELSIUS_WITH_OFFSET(
tz-temperature, tz-kelvin_offset);
if (thermal_get_trip_temp(thermal, trip, trip_temp))
return -EINVAL;
diff --git a/drivers/hwmon/lm75.c b/drivers/hwmon/lm75.c
index fe41d5a..e4e57bb 100644
--- a/drivers/hwmon/lm75.c
+++ b/drivers/hwmon/lm75.c
@@ -104,7 +104,7 @@ static inline long lm75_reg_to_mc(s16 temp, u8 resolution)
 
 /* sysfs attributes for hwmon */
 
-static int lm75_read_temp(void *dev, long *temp)
+static int lm75_read_temp(void *dev, int *temp)
 {
struct lm75_data *data = lm75_update_device(dev);
 
diff --git a/drivers/hwmon/ntc_thermistor.c b/drivers/hwmon/ntc_thermistor.c
index 112e4d4..9f085df 100644
--- a/drivers/hwmon/ntc_thermistor.c
+++ b/drivers/hwmon/ntc_thermistor.c
@@ -430,7 +430,7 @@ static int ntc_thermistor_get_ohm(struct ntc_data *data)
return -EINVAL;
 }
 
-static int ntc_read_temp(void *dev, long *temp)
+static int ntc_read_temp(void *dev, int *temp)
 {
struct ntc_data *data = dev_get_drvdata(dev);

[PATCH 12/13] thermal: thermal: Add support for hardware-tracked trip points

[Sascha Hauer]

This adds support for hardware-tracked trip points to the device tree
thermal sensor framework.

The framework supports an arbitrary number of trip points. Whenever
the current temperature is updated, the trip points immediately
below and above the current temperature are found. A .set_trips
callback is then called with the temperatures. If there is no trip
point above or below the current temperature, the passed trip
temperature will be ULONG_MAX or 0 respectively. In this callback,
the driver should program the hardware such that it is notified
when either of these trip points are triggered. When a trip point
is triggered, the driver should call `thermal_zone_device_update'
for the respective thermal zone. This will cause the trip points
to be updated again.

If .set_trips is not implemented, the framework behaves as before.

This patch is based on an earlier version from Mikko Perttunen
mikko.perttu...@kapsi.fi

Signed-off-by: Sascha Hauer s.ha...@pengutronix.de
---
 drivers/thermal/thermal_core.c | 42 ++
 include/linux/thermal.h|  3 +++
 2 files changed, 45 insertions(+)

diff --git a/drivers/thermal/thermal_core.c b/drivers/thermal/thermal_core.c
index 420c702..4e1aaab 100644
--- a/drivers/thermal/thermal_core.c
+++ b/drivers/thermal/thermal_core.c
@@ -453,6 +453,45 @@ int thermal_zone_get_temp(struct thermal_zone_device *tz, 
int *temp)
 }
 EXPORT_SYMBOL_GPL(thermal_zone_get_temp);
 
+static void thermal_zone_set_trips(struct thermal_zone_device *tz)
+{
+   int low = -INT_MAX;
+   int high = INT_MAX;
+   int trip_temp, hysteresis;
+   int temp = tz-temperature;
+   int i;
+
+   if (!tz-ops-set_trips)
+   return;
+
+   /* No need to change trip points */
+   if (temp  tz-prev_low_trip  temp  tz-prev_high_trip)
+   return;
+
+   for (i = 0; i  tz-trips; i++) {
+   unsigned long trip_low;
+
+   tz-ops-get_trip_temp(tz, i, trip_temp);
+   tz-ops-get_trip_hyst(tz, i, hysteresis);
+
+   trip_low = trip_temp - hysteresis;
+
+   if (trip_low  temp  trip_low  low)
+   low = trip_low;
+
+   if (trip_temp  temp  trip_temp  high)
+   high = trip_temp;
+   }
+
+   tz-prev_low_trip = low;
+   tz-prev_high_trip = high;
+
+   dev_dbg(tz-device, new temperature boundaries: %d  x  %d\n,
+   low, high);
+
+   tz-ops-set_trips(tz, low, high);
+}
+
 void thermal_zone_device_update(struct thermal_zone_device *tz)
 {
int temp, ret, count;
@@ -473,6 +512,7 @@ void thermal_zone_device_update(struct thermal_zone_device 
*tz)
mutex_lock(tz-lock);
tz-last_temperature = tz-temperature;
tz-temperature = temp;
+   thermal_zone_set_trips(tz);
mutex_unlock(tz-lock);
 
trace_thermal_temperature(tz);
@@ -1494,6 +1534,8 @@ struct thermal_zone_device 
*thermal_zone_device_register(const char *type,
tz-trips = trips;
tz-passive_delay = passive_delay;
tz-polling_delay = polling_delay;
+   tz-prev_low_trip = INT_MAX;
+   tz-prev_high_trip = -INT_MAX;
 
dev_set_name(tz-device, thermal_zone%d, tz-id);
result = device_register(tz-device);
diff --git a/include/linux/thermal.h b/include/linux/thermal.h
index 07bd5e8..aef6e13 100644
--- a/include/linux/thermal.h
+++ b/include/linux/thermal.h
@@ -87,6 +87,7 @@ struct thermal_zone_device_ops {
int (*unbind) (struct thermal_zone_device *,
   struct thermal_cooling_device *);
int (*get_temp) (struct thermal_zone_device *, int *);
+   int (*set_trips) (struct thermal_zone_device *, int, int);
int (*get_mode) (struct thermal_zone_device *,
 enum thermal_device_mode *);
int (*set_mode) (struct thermal_zone_device *,
@@ -180,6 +181,8 @@ struct thermal_zone_device {
int last_temperature;
int emul_temperature;
int passive;
+   int prev_low_trip;
+   int prev_high_trip;
unsigned int forced_passive;
const struct thermal_zone_device_ops *ops;
const struct thermal_zone_params *tzp;
-- 
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 13/13] thermal: of: implement .set_trips for device tree thermal zones

[Sascha Hauer]

Signed-off-by: Sascha Hauer s.ha...@pengutronix.de
---
 drivers/thermal/of-thermal.c | 12 
 include/linux/thermal.h  |  3 +++
 2 files changed, 15 insertions(+)

diff --git a/drivers/thermal/of-thermal.c b/drivers/thermal/of-thermal.c
index bd3185e..f8dd847 100644
--- a/drivers/thermal/of-thermal.c
+++ b/drivers/thermal/of-thermal.c
@@ -97,6 +97,17 @@ static int of_thermal_get_temp(struct thermal_zone_device 
*tz,
return data-ops-get_temp(data-sensor_data, temp);
 }
 
+static int of_thermal_set_trips(struct thermal_zone_device *tz,
+  int low, int high)
+{
+   struct __thermal_zone *data = tz-devdata;
+
+   if (!data-ops || !data-ops-set_trips)
+   return -ENOSYS;
+
+   return data-ops-set_trips(data-sensor_data, low, high);
+}
+
 /**
  * of_thermal_get_ntrips - function to export number of available trip
  *points.
@@ -367,6 +378,7 @@ static int of_thermal_get_crit_temp(struct 
thermal_zone_device *tz,
 
 static const struct thermal_zone_device_ops of_thermal_ops = {
.get_temp = of_thermal_get_temp,
+   .set_trips = of_thermal_set_trips,
.get_trend = of_thermal_get_trend,
.set_emul_temp = of_thermal_set_emul_temp,
 
diff --git a/include/linux/thermal.h b/include/linux/thermal.h
index aef6e13..b751f6b 100644
--- a/include/linux/thermal.h
+++ b/include/linux/thermal.h
@@ -267,12 +267,15 @@ struct thermal_genl_event {
  *
  * Optional:
  * @get_trend: a pointer to a function that reads the sensor temperature trend.
+ * @set_trips: a pointer to a function that sets a temperature window which 
shall
+ * trigger an interrupt when it is left.
  * @set_emul_temp: a pointer to a function that sets sensor emulated
  *temperature.
  */
 struct thermal_zone_of_device_ops {
int (*get_temp)(void *, int *);
int (*get_trend)(void *, int, enum thermal_trend *);
+   int (*set_trips)(void *, int, int);
int (*set_emul_temp)(void *, int);
 };
 
-- 
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 03/13] thermal: trivial: Add missing whitespace in message

[Sascha Hauer]

Commas should be followed by a whitespace.

Signed-off-by: Sascha Hauer s.ha...@pengutronix.de
---
 drivers/thermal/thermal_core.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/thermal/thermal_core.c b/drivers/thermal/thermal_core.c
index 244784f..cecebac 100644
--- a/drivers/thermal/thermal_core.c
+++ b/drivers/thermal/thermal_core.c
@@ -378,7 +378,7 @@ static void handle_critical_trips(struct 
thermal_zone_device *tz,
 
if (trip_type == THERMAL_TRIP_CRITICAL) {
dev_emerg(tz-device,
- critical temperature reached(%d C),shutting down\n,
+ critical temperature reached(%d C), shutting down\n,
  tz-temperature / 1000);
orderly_poweroff(true);
}
-- 
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 10/13] thermal: of: always set sensor related callbacks

[Sascha Hauer]

Now that the thermal core treats -ENOSYS like the callbacks were
not present at all we no longer have to overwrite the ops during
runtime but instead can always set them and return -ENOSYS if no
sensor is registered.

Signed-off-by: Sascha Hauer s.ha...@pengutronix.de
---
 drivers/thermal/of-thermal.c | 33 +
 1 file changed, 13 insertions(+), 20 deletions(-)

diff --git a/drivers/thermal/of-thermal.c b/drivers/thermal/of-thermal.c
index c84404d..b9c35bd 100644
--- a/drivers/thermal/of-thermal.c
+++ b/drivers/thermal/of-thermal.c
@@ -91,7 +91,7 @@ static int of_thermal_get_temp(struct thermal_zone_device *tz,
 {
struct __thermal_zone *data = tz-devdata;
 
-   if (!data-ops-get_temp)
+   if (!data-ops)
return -EINVAL;
 
return data-ops-get_temp(data-sensor_data, temp);
@@ -178,7 +178,7 @@ static int of_thermal_set_emul_temp(struct 
thermal_zone_device *tz,
struct __thermal_zone *data = tz-devdata;
 
if (!data-ops || !data-ops-set_emul_temp)
-   return -EINVAL;
+   return -ENOSYS;
 
return data-ops-set_emul_temp(data-sensor_data, temp);
 }
@@ -189,8 +189,8 @@ static int of_thermal_get_trend(struct thermal_zone_device 
*tz, int trip,
struct __thermal_zone *data = tz-devdata;
int r;
 
-   if (!data-ops-get_trend)
-   return -EINVAL;
+   if (!data-ops || !data-ops-get_trend)
+   return -ENOSYS;
 
r = data-ops-get_trend(data-sensor_data, trip, trend);
if (r)
@@ -366,6 +366,10 @@ static int of_thermal_get_crit_temp(struct 
thermal_zone_device *tz,
 }
 
 static struct thermal_zone_device_ops of_thermal_ops = {
+   .get_temp = of_thermal_get_temp,
+   .get_trend = of_thermal_get_trend,
+   .set_emul_temp = of_thermal_set_emul_temp,
+
.get_mode = of_thermal_get_mode,
.set_mode = of_thermal_set_mode,
 
@@ -399,13 +403,13 @@ thermal_zone_of_add_sensor(struct device_node *zone,
if (!ops)
return ERR_PTR(-EINVAL);
 
+   if (!ops-get_temp)
+   return ERR_PTR(-EINVAL);
+
mutex_lock(tzd-lock);
tz-ops = ops;
tz-sensor_data = data;
 
-   tzd-ops-get_temp = of_thermal_get_temp;
-   tzd-ops-get_trend = of_thermal_get_trend;
-   tzd-ops-set_emul_temp = of_thermal_set_emul_temp;
mutex_unlock(tzd-lock);
 
return tzd;
@@ -535,9 +539,6 @@ void thermal_zone_of_sensor_unregister(struct device *dev,
return;
 
mutex_lock(tzd-lock);
-   tzd-ops-get_temp = NULL;
-   tzd-ops-get_trend = NULL;
-   tzd-ops-set_emul_temp = NULL;
 
tz-ops = NULL;
tz-sensor_data = NULL;
@@ -845,7 +846,6 @@ int __init of_parse_thermal_zones(void)
 {
struct device_node *np, *child;
struct __thermal_zone *tz;
-   struct thermal_zone_device_ops *ops;
 
np = of_find_node_by_name(NULL, thermal-zones);
if (!np) {
@@ -869,29 +869,22 @@ int __init of_parse_thermal_zones(void)
continue;
}
 
-   ops = kmemdup(of_thermal_ops, sizeof(*ops), GFP_KERNEL);
-   if (!ops)
-   goto exit_free;
-
tzp = kzalloc(sizeof(*tzp), GFP_KERNEL);
-   if (!tzp) {
-   kfree(ops);
+   if (!tzp)
goto exit_free;
-   }
 
/* No hwmon because there might be hwmon drivers registering */
tzp-no_hwmon = true;
 
zone = thermal_zone_device_register(child-name, tz-ntrips,
0, tz,
-   ops, tzp,
+   of_thermal_ops, tzp,
tz-passive_delay,
tz-polling_delay);
if (IS_ERR(zone)) {
pr_err(Failed to build %s zone %ld\n, child-name,
   PTR_ERR(zone));
kfree(tzp);
-   kfree(ops);
of_thermal_free_zone(tz);
/* attempting to build remaining zones still */
}
-- 
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 09/13] thermal: Allow sensor ops to fail with -ENOSYS

[Sascha Hauer]

The thermal core uses the existence of the .get_temp, .get_trend and
.set_emul_temp to detect whether this operation exists and should be
used or whether it should be emulated in software. This makes problems
for of-thermal which has to modify the struct thermal_zone_device_ops
during runtime whenever a sensor is registered or unregistered.

Let the core test for -ENOSYS from these callbacks and treat it like
if the callbacks were not present.

This allows of-thermal to always set the sensor related callbacks and
to make struct thermal_zone_device_ops const again.

Signed-off-by: Sascha Hauer s.ha...@pengutronix.de
---
 drivers/thermal/thermal_core.c | 24 +---
 1 file changed, 17 insertions(+), 7 deletions(-)

diff --git a/drivers/thermal/thermal_core.c b/drivers/thermal/thermal_core.c
index 81ebc24..0f3d26c 100644
--- a/drivers/thermal/thermal_core.c
+++ b/drivers/thermal/thermal_core.c
@@ -413,13 +413,16 @@ static void handle_thermal_trip(struct 
thermal_zone_device *tz, int trip)
  */
 int thermal_zone_get_temp(struct thermal_zone_device *tz, int *temp)
 {
-   int ret = -EINVAL;
+   int ret;
int count;
int crit_temp = INT_MAX;
enum thermal_trip_type type;
 
-   if (!tz || IS_ERR(tz) || !tz-ops-get_temp)
-   goto exit;
+   if (!tz || IS_ERR(tz))
+   return -EINVAL;
+
+   if (!tz-ops-get_temp)
+   return -ENOSYS;
 
mutex_lock(tz-lock);
 
@@ -445,7 +448,7 @@ int thermal_zone_get_temp(struct thermal_zone_device *tz, 
int *temp)
}
 
mutex_unlock(tz-lock);
-exit:
+
return ret;
 }
 EXPORT_SYMBOL_GPL(thermal_zone_get_temp);
@@ -454,10 +457,11 @@ void thermal_zone_device_update(struct 
thermal_zone_device *tz)
 {
int temp, ret, count;
 
-   if (!tz-ops-get_temp)
+   ret = thermal_zone_get_temp(tz, temp);
+
+   if (ret == -ENOSYS)
return;
 
-   ret = thermal_zone_get_temp(tz, temp);
if (ret) {
if (ret != -EAGAIN)
dev_warn(tz-device,
@@ -783,10 +787,16 @@ emul_temp_store(struct device *dev, struct 
device_attribute *attr,
if (kstrtoul(buf, 10, temperature))
return -EINVAL;
 
-   if (!tz-ops-set_emul_temp) {
+   if (tz-ops-set_emul_temp)
+   ret = tz-ops-set_emul_temp(tz, temperature);
+   else
+   ret = -ENOSYS;
+
+   if (ret == -ENOSYS) {
mutex_lock(tz-lock);
tz-emul_temperature = temperature;
mutex_unlock(tz-lock);
+   ret = 0;
} else {
ret = tz-ops-set_emul_temp(tz, temperature);
}
-- 
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 v6 3/3] I2C: mediatek: Add driver for MediaTek MT8173 I2C controller

[Eddie Huang]

Add mediatek MT8173 I2C controller driver. Compare to I2C controller
of earlier mediatek SoC, MT8173 fix write-then-read limitation, and
also increase message size to 64kb.

Signed-off-by: Xudong Chen xudong.c...@mediatek.com
Signed-off-by: Liguo Zhang liguo.zh...@mediatek.com
Signed-off-by: Eddie Huang eddie.hu...@mediatek.com
---
 drivers/i2c/busses/i2c-mt65xx.c | 106 +---
 1 file changed, 77 insertions(+), 29 deletions(-)

diff --git a/drivers/i2c/busses/i2c-mt65xx.c b/drivers/i2c/busses/i2c-mt65xx.c
index 2ecf0d1..c501421 100644
--- a/drivers/i2c/busses/i2c-mt65xx.c
+++ b/drivers/i2c/busses/i2c-mt65xx.c
@@ -33,10 +33,13 @@
 #include linux/clk.h
 #include linux/completion.h
 
+#define I2C_RS_TRANSFER(1  4)
 #define I2C_HS_NACKERR (1  2)
 #define I2C_ACKERR (1  1)
 #define I2C_TRANSAC_COMP   (1  0)
 #define I2C_TRANSAC_START  (1  0)
+#define I2C_RS_MUL_CNFG(1  15)
+#define I2C_RS_MUL_TRIG(1  14)
 #define I2C_TIMING_STEP_DIV_MASK   (0x3f  0)
 #define I2C_TIMING_SAMPLE_COUNT_MASK   (0x7  0)
 #define I2C_TIMING_SAMPLE_DIV_MASK (0x7  8)
@@ -67,6 +70,9 @@
 #define MAX_MSG_NUM_MT6577 1
 #define MAX_DMA_TRANS_SIZE_MT6577  255
 #define MAX_WRRD_TRANS_SIZE_MT6577 31
+#define MAX_MSG_NUM_MT8173 65535
+#define MAX_DMA_TRANS_SIZE_MT8173  65535
+#define MAX_WRRD_TRANS_SIZE_MT8173 65535
 #define MAX_SAMPLE_CNT_DIV 8
 #define MAX_STEP_CNT_DIV   64
 #define MAX_HS_STEP_CNT_DIV8
@@ -139,6 +145,7 @@ struct mtk_i2c_compatible {
const struct i2c_adapter_quirks *quirks;
unsigned char pmic_i2c;
unsigned char dcm;
+   unsigned char auto_restart;
 };
 
 struct mtk_i2c {
@@ -172,24 +179,42 @@ static const struct i2c_adapter_quirks mt6577_i2c_quirks 
= {
.max_comb_2nd_msg_len = MAX_WRRD_TRANS_SIZE_MT6577,
 };
 
+static const struct i2c_adapter_quirks mt8173_i2c_quirks = {
+   .max_num_msgs = MAX_MSG_NUM_MT8173,
+   .max_write_len = MAX_DMA_TRANS_SIZE_MT8173,
+   .max_read_len = MAX_DMA_TRANS_SIZE_MT8173,
+   .max_comb_1st_msg_len = MAX_DMA_TRANS_SIZE_MT8173,
+   .max_comb_2nd_msg_len = MAX_WRRD_TRANS_SIZE_MT8173,
+};
+
 static const struct mtk_i2c_compatible mt6577_compat = {
.quirks = mt6577_i2c_quirks,
.pmic_i2c = 0,
.dcm = 1,
+   .auto_restart = 0,
 };
 
 static const struct mtk_i2c_compatible mt6589_compat = {
.quirks = mt6577_i2c_quirks,
.pmic_i2c = 1,
.dcm = 0,
+   .auto_restart = 0,
+};
+
+static const struct mtk_i2c_compatible mt8173_compat = {
+   .quirks = mt8173_i2c_quirks,
+   .pmic_i2c = 0,
+   .dcm = 1,
+   .auto_restart = 1,
 };
 
 static const struct of_device_id mtk_i2c_of_match[] = {
{ .compatible = mediatek,mt6577-i2c, .data = (void *)mt6577_compat },
{ .compatible = mediatek,mt6589-i2c, .data = (void *)mt6589_compat },
+   { .compatible = mediatek,mt8173-i2c, .data = (void *)mt8173_compat },
{}
 };
-MODULE_DEVICE_TABLE(of, mtk_i2c_match);
+MODULE_DEVICE_TABLE(of, mtk_i2c_of_match);
 
 static inline void mtk_i2c_writew(u16 value, struct mtk_i2c *i2c, u8 offset)
 {
@@ -343,9 +368,11 @@ static int mtk_i2c_set_speed(struct mtk_i2c *i2c, unsigned 
int clk_src_in_hz)
return 0;
 }
 
-static int mtk_i2c_do_transfer(struct mtk_i2c *i2c, struct i2c_msg *msgs)
+static int mtk_i2c_do_transfer(struct mtk_i2c *i2c, struct i2c_msg *msgs,
+   int num, int left_num)
 {
u16 addr_reg;
+   u16 start_reg;
u16 control_reg;
dma_addr_t rpaddr = 0;
dma_addr_t wpaddr = 0;
@@ -361,6 +388,8 @@ static int mtk_i2c_do_transfer(struct mtk_i2c *i2c, struct 
i2c_msg *msgs)
control_reg |= I2C_CONTROL_RS;
if (i2c-op == I2C_MASTER_WRRD)
control_reg |= I2C_CONTROL_DIR_CHANGE | I2C_CONTROL_RS;
+   if (left_num = 1)
+   control_reg |= I2C_CONTROL_RS;
mtk_i2c_writew(control_reg, i2c, OFFSET_CONTROL);
 
/* set start condition */
@@ -375,13 +404,13 @@ static int mtk_i2c_do_transfer(struct mtk_i2c *i2c, 
struct i2c_msg *msgs)
mtk_i2c_writew(addr_reg, i2c, OFFSET_SLAVE_ADDR);
 
/* Clear interrupt status */
-   mtk_i2c_writew(I2C_HS_NACKERR | I2C_ACKERR | I2C_TRANSAC_COMP,
-   i2c, OFFSET_INTR_STAT);
+   mtk_i2c_writew(I2C_RS_TRANSFER | I2C_HS_NACKERR | I2C_ACKERR
+   | I2C_TRANSAC_COMP, i2c, OFFSET_INTR_STAT);
mtk_i2c_writew(I2C_FIFO_ADDR_CLR, i2c, OFFSET_FIFO_ADDR_CLR);
 
/* Enable interrupt */
-   mtk_i2c_writew(I2C_HS_NACKERR | I2C_ACKERR | I2C_TRANSAC_COMP,
-   i2c, OFFSET_INTR_MASK);
+   mtk_i2c_writew(I2C_RS_TRANSFER | I2C_HS_NACKERR | I2C_ACKERR
+   | I2C_TRANSAC_COMP, i2c, 

[PATCH v2] Thermal cleanups and hardware trip points

[Sascha Hauer]

This series adds support for hardware trip points. It picks up earlier
work from Mikko Perttunen. Mikko implemented hardware trip points as part
of the device tree support. It was suggested back then to move the
functionality to the thermal core instead of putting more code into the
device tree support. This series does exactly that.

The majority of the patches are cleanups and fixes. Only the last two
patches actually implement the hardware trip points.

Note that the hardware trip points are not very well tested currently
and I still have no ready-to-post driver using them. However, Brian
Norris showed interest in these patches, so I am including the patches
in this series nevertheless.

All comments welcome

Changes since v1:
- Use int instead of unsigned long consistently for temperatures
- Instead of misfixing the emulation code add a comment how the
  code is meant
- Add doc entry for .set_trips callback
- initialize prev_low_trip/prev_high_trip properly
- get tz-lock before calling thermal_zone_set_trips()

--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@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 v6 2/3] I2C: mediatek: Add driver for MediaTek I2C controller

[Eddie Huang]

From: Xudong Chen xudong.c...@mediatek.com

The mediatek SoCs have I2C controller that handle I2C transfer.
This patch include common I2C bus driver.
This driver is compatible with I2C controller on mt65xx/mt81xx.

Signed-off-by: Xudong Chen xudong.c...@mediatek.com
Signed-off-by: Liguo Zhang liguo.zh...@mediatek.com
Signed-off-by: Eddie Huang eddie.hu...@mediatek.com
---
 drivers/i2c/busses/Kconfig  |   9 +
 drivers/i2c/busses/Makefile |   1 +
 drivers/i2c/busses/i2c-mt65xx.c | 700 
 3 files changed, 710 insertions(+)
 create mode 100644 drivers/i2c/busses/i2c-mt65xx.c

diff --git a/drivers/i2c/busses/Kconfig b/drivers/i2c/busses/Kconfig
index 2255af2..14c7266 100644
--- a/drivers/i2c/busses/Kconfig
+++ b/drivers/i2c/busses/Kconfig
@@ -620,6 +620,15 @@ config I2C_MPC
  This driver can also be built as a module.  If so, the module
  will be called i2c-mpc.
 
+config I2C_MT65XX
+   tristate MediaTek I2C adapter
+   depends on ARCH_MEDIATEK || COMPILE_TEST
+   help
+ This selects the MediaTek(R) Integrated Inter Circuit bus driver
+ for MT65xx and MT81xx.
+ If you want to use MediaTek(R) I2C interface, say Y or M here.
+ If unsure, say N.
+
 config I2C_MV64XXX
tristate Marvell mv64xxx I2C Controller
depends on MV64X60 || PLAT_ORION || ARCH_SUNXI
diff --git a/drivers/i2c/busses/Makefile b/drivers/i2c/busses/Makefile
index cdf941d..abbf422 100644
--- a/drivers/i2c/busses/Makefile
+++ b/drivers/i2c/busses/Makefile
@@ -60,6 +60,7 @@ obj-$(CONFIG_I2C_JZ4780)  += i2c-jz4780.o
 obj-$(CONFIG_I2C_KEMPLD)   += i2c-kempld.o
 obj-$(CONFIG_I2C_MESON)+= i2c-meson.o
 obj-$(CONFIG_I2C_MPC)  += i2c-mpc.o
+obj-$(CONFIG_I2C_MT65XX)   += i2c-mt65xx.o
 obj-$(CONFIG_I2C_MV64XXX)  += i2c-mv64xxx.o
 obj-$(CONFIG_I2C_MXS)  += i2c-mxs.o
 obj-$(CONFIG_I2C_NOMADIK)  += i2c-nomadik.o
diff --git a/drivers/i2c/busses/i2c-mt65xx.c b/drivers/i2c/busses/i2c-mt65xx.c
new file mode 100644
index 000..2ecf0d1
--- /dev/null
+++ b/drivers/i2c/busses/i2c-mt65xx.c
@@ -0,0 +1,700 @@
+/*
+ * Copyright (c) 2014 MediaTek Inc.
+ * Author: Xudong.chen xudong.c...@mediatek.com
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ */
+
+#include linux/kernel.h
+#include linux/module.h
+#include linux/slab.h
+#include linux/i2c.h
+#include linux/init.h
+#include linux/interrupt.h
+#include linux/sched.h
+#include linux/delay.h
+#include linux/errno.h
+#include linux/err.h
+#include linux/device.h
+#include linux/platform_device.h
+#include linux/mm.h
+#include linux/dma-mapping.h
+#include linux/scatterlist.h
+#include linux/io.h
+#include linux/of_address.h
+#include linux/of_irq.h
+#include linux/clk.h
+#include linux/completion.h
+
+#define I2C_HS_NACKERR (1  2)
+#define I2C_ACKERR (1  1)
+#define I2C_TRANSAC_COMP   (1  0)
+#define I2C_TRANSAC_START  (1  0)
+#define I2C_TIMING_STEP_DIV_MASK   (0x3f  0)
+#define I2C_TIMING_SAMPLE_COUNT_MASK   (0x7  0)
+#define I2C_TIMING_SAMPLE_DIV_MASK (0x7  8)
+#define I2C_TIMING_DATA_READ_MASK  (0x7  12)
+#define I2C_DCM_DISABLE0x
+#define I2C_IO_CONFIG_OPEN_DRAIN   0x0003
+#define I2C_IO_CONFIG_PUSH_PULL0x
+#define I2C_SOFT_RST   0x0001
+#define I2C_FIFO_ADDR_CLR  0x0001
+#define I2C_DELAY_LEN  0x0002
+#define I2C_ST_START_CON   0x8001
+#define I2C_FS_START_CON   0x1800
+#define I2C_TIME_CLR_VALUE 0x
+#define I2C_TIME_DEFAULT_VALUE 0x0003
+#define I2C_FS_TIME_INIT_VALUE 0x1303
+#define I2C_WRRD_TRANAC_VALUE  0x0002
+#define I2C_RD_TRANAC_VALUE0x0001
+
+#define I2C_DMA_CON_TX 0x
+#define I2C_DMA_CON_RX 0x0001
+#define I2C_DMA_START_EN   0x0001
+#define I2C_DMA_INT_FLAG_NONE  0x
+#define I2C_DMA_CLR_FLAG   0x
+
+#define I2C_DEFAUT_SPEED   10  /* hz */
+#define MAX_FS_MODE_SPEED  40
+#define MAX_HS_MODE_SPEED  340
+#define MAX_MSG_NUM_MT6577 1
+#define MAX_DMA_TRANS_SIZE_MT6577  255
+#define MAX_WRRD_TRANS_SIZE_MT6577 31
+#define MAX_SAMPLE_CNT_DIV 8
+#define MAX_STEP_CNT_DIV   64
+#define MAX_HS_STEP_CNT_DIV8
+
+#define I2C_CONTROL_RS  (0x1  1)
+#define I2C_CONTROL_DMA_EN  (0x1  2)
+#define 

[PATCH v6 0/3] ARM: mediatek: Add driver for Mediatek I2C

[Eddie Huang]

This series is for Mediatek SoCs I2C controller common bus driver.

Earlier MTK SoC ((for example, MT6589, MT8135)) I2C HW has some limitationes.
New generation SoC like MT8173 fix following limitations:

1. Only support one i2c_msg number. One exception is WRRD (write then read)
mode. WRRD can have two i2c_msg numbers.

2. Mediatek I2C controller support WRRD(write then read) mode, in WRRD
mode the Repeat Start will be issued between 2 messages.
In this driver if 2 messages is first write then read, the driver will
combine 2 messages using Write-Read mode so the RS will be issued between
the 2 messages.

3. The max transfer data length is 255 in one message. In WRRD mode, the
max data length of second msg is 31.

MT8135 and MT6589 can control I2C pins on PMIC(MT6397) by setting the i2c
registers in MT8135 side. In this case, driver should set OFFSET_PATH_DIR
bit first, the operation on other registers are still the same.
For now MT6589/MT8135 support this, MT6577/MT6595/MT8127 do not support.
For example, If want to use I2C4/5/6 pins on MT8135 just need to enable
the pinmux, else if want to use I2C pins on PMIC(MT6397) need to add
mediatek,have-pmic property in the .dts file of each platform.

This driver is based on 4.1-rc1.

Change in v6:
1. Update binding document not use default clock-frequency as example.
2. Add mtk_i2c_compatible struct and pass hardware capabilities
   through of_device_id
3. Remove some hardware setting in mtk_i2c_do_transfer to mtk_i2c_init_hw
   so just init one time.
4. Correct mtk_i2c_parse_dt don't set default clock bug.

Change in v5:
Apply new i2c_adapter_quirks patch [2]. Change to use dam_map_single to map
dma buffer. Add spinlock to fix race condition. Check of_property_read_u32
return value. Remove I2C_FUNC_10BIT_ADDR capability due to driver not implement.
Add MT8173 I2C driver.

Change in v4:
Modify to support i2c_adapter_quirks base on Wolfram's patch [1].
Remove check transfer size and WRRD combine code. Instead, fill quirk
property and let i2c_check_for_quirks to do the filter.

[1] 
http://lists.infradead.org/pipermail/linux-arm-kernel/2015-January/314804.html
[2] 
http://lists.infradead.org/pipermail/linux-arm-kernel/2015-February/325744.html

Eddie Huang (1):
  I2C: mediatek: Add driver for MediaTek MT8173 I2C controller

Xudong Chen (2):
  dt-bindings: Add I2C bindings for mt65xx/mt81xx.
  I2C: mediatek: Add driver for MediaTek I2C controller

 .../devicetree/bindings/i2c/i2c-mt6577.txt |  41 ++
 drivers/i2c/busses/Kconfig |   9 +
 drivers/i2c/busses/Makefile|   1 +
 drivers/i2c/busses/i2c-mt65xx.c| 748 +
 4 files changed, 799 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/i2c/i2c-mt6577.txt
 create mode 100644 drivers/i2c/busses/i2c-mt65xx.c

--
1.8.1.1.dirty

--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@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 v6 1/3] dt-bindings: Add I2C bindings for mt65xx/mt81xx.

[Eddie Huang]

From: Xudong Chen xudong.c...@mediatek.com

Add devicetree bindings for Mediatek Soc I2C driver.

Signed-off-by: Xudong Chen xudong.c...@mediatek.com
Signed-off-by: Eddie Huang eddie.hu...@mediatek.com
---
 .../devicetree/bindings/i2c/i2c-mt6577.txt | 41 ++
 1 file changed, 41 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/i2c/i2c-mt6577.txt

diff --git a/Documentation/devicetree/bindings/i2c/i2c-mt6577.txt 
b/Documentation/devicetree/bindings/i2c/i2c-mt6577.txt
new file mode 100644
index 000..0ce6fa3
--- /dev/null
+++ b/Documentation/devicetree/bindings/i2c/i2c-mt6577.txt
@@ -0,0 +1,41 @@
+* Mediatek's I2C controller
+
+The Mediatek's I2C controller is used to interface with I2C devices.
+
+Required properties:
+  - compatible: value should be either of the following.
+  (a) mediatek,mt6577-i2c, for i2c compatible with mt6577 i2c.
+  (b) mediatek,mt6589-i2c, for i2c compatible with mt6589 i2c.
+  (c) mediatek,mt8127-i2c, for i2c compatible with mt8127 i2c.
+  (d) mediatek,mt8135-i2c, for i2c compatible with mt8135 i2c.
+  (e) mediatek,mt8173-i2c, for i2c compatible with mt8173 i2c.
+  - reg: physical base address of the controller and dma base, length of memory
+mapped region.
+  - interrupts: interrupt number to the cpu.
+  - clock-div: the fixed value for frequency divider of clock source in i2c
+module. Each IC may be different.
+  - clocks: clock name from clock manager
+  - clock-names: Must include main and dma, if enable have-pmic need 
include
+pmic extra.
+
+Optional properties:
+  - clock-frequency: Frequency in Hz of the bus when transfer, the default 
value
+is 10.
+  - mediatek,have-pmic: platform can control i2c form special pmic side.
+Only mt6589 and mt8135 support this feature.
+  - mediatek,use-push-pull: IO config use push-pull mode.
+
+Example:
+
+   i2c0: i2c@1100d000 {
+   compatible = mediatek,mt6577-i2c;
+   reg = 0x1100d000 0x70,
+ 0x11000300 0x80;
+   interrupts = GIC_SPI 44 IRQ_TYPE_LEVEL_LOW;
+   clock-frequency = 40;
+   mediatek,have-pmic;
+   clock-div = 16;
+   clocks = i2c0_ck, ap_dma_ck;
+   clock-names = main, dma;
+   };
+
-- 
1.8.1.1.dirty

--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@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 01/11] coresight-etm4x: Adding CoreSight ETM4x driver

[Ivan T. Ivanov]

On Mon, 2015-04-27 at 09:48 -0600, Mathieu Poirier wrote:
 On 24 April 2015 at 09:41, Ivan T. Ivanov iiva...@mm-sol.com wrote:
  On Wed, 2015-04-22 at 16:40 -0600, Mathieu Poirier wrote:
  
   +static struct amba_id etm4_ids[] = {
   +   {   /* ETM 4.0 - Hi6220 board */
   +   .id = 0x0003b95d,
   +   .mask   = 0x0003,
   +   .data   = ETM 4.0,
   +   },
   +   {   /* ETM 4.0 - Juno board */
   +   .id = 0x000bb95e,
   +   .mask   = 0x000b,
  
  Mask looks suspicious.
 
 Can you please expand the suspicious part ?

Well, 'b' part of the mask. I have to admit that
I don't know how this is mapped on this platform.

Regards,
Ivan
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH 2/2] i2c / ACPI: Assign IRQ for devices that have GpioInt automatically

[Mika Westerberg]

Following what DT already does. If the device does not have ACPI Interrupt
resource but instead it has one or more GpioInt resources listed below it,
we take the first GpioInt resource, convert it to suitable Linux IRQ number
and pass it to the driver instead.

This makes drivers simpler because the don't need to care about GPIOs at
all if only thing they need is interrupt.

Signed-off-by: Mika Westerberg mika.westerb...@linux.intel.com
---
 drivers/i2c/i2c-core.c | 9 +++--
 1 file changed, 7 insertions(+), 2 deletions(-)

diff --git a/drivers/i2c/i2c-core.c b/drivers/i2c/i2c-core.c
index 987c124432c5..01ef731281e2 100644
--- a/drivers/i2c/i2c-core.c
+++ b/drivers/i2c/i2c-core.c
@@ -632,8 +632,13 @@ static int i2c_device_probe(struct device *dev)
if (!client)
return 0;
 
-   if (!client-irq  dev-of_node) {
-   int irq = of_irq_get(dev-of_node, 0);
+   if (client-irq = 0) {
+   int irq = -ENOENT;
+
+   if (dev-of_node)
+   irq = of_irq_get(dev-of_node, 0);
+   else if (ACPI_COMPANION(dev))
+   irq = acpi_dev_gpio_irq_get(ACPI_COMPANION(dev), 0);
 
if (irq == -EPROBE_DEFER)
return irq;
-- 
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 v7 14/23] IB/Verbs: Reform rest part in IB-core cma

[Michael Wang]

Use raw management helpers to reform rest part in IB-core cma.

Cc: Hal Rosenstock h...@dev.mellanox.co.il
Cc: Steve Wise sw...@opengridcomputing.com
Cc: Tom Talpey t...@talpey.com
Cc: Jason Gunthorpe jguntho...@obsidianresearch.com
Cc: Doug Ledford dledf...@redhat.com
Cc: Ira Weiny ira.we...@intel.com
Cc: Sean Hefty sean.he...@intel.com
Signed-off-by: Michael Wang yun.w...@profitbricks.com
---
 drivers/infiniband/core/cma.c | 20 +---
 1 file changed, 9 insertions(+), 11 deletions(-)

diff --git a/drivers/infiniband/core/cma.c b/drivers/infiniband/core/cma.c
index 3fb3458..d43f492f 100644
--- a/drivers/infiniband/core/cma.c
+++ b/drivers/infiniband/core/cma.c
@@ -447,10 +447,10 @@ static int cma_resolve_ib_dev(struct rdma_id_private 
*id_priv)
pkey = ntohs(addr-sib_pkey);
 
list_for_each_entry(cur_dev, dev_list, list) {
-   if (rdma_node_get_transport(cur_dev-device-node_type) != 
RDMA_TRANSPORT_IB)
-   continue;
-
for (p = 1; p = cur_dev-device-phys_port_cnt; ++p) {
+   if (!rdma_ib_or_iboe(cur_dev-device, p))
+   continue;
+
if (ib_find_cached_pkey(cur_dev-device, p, pkey, 
index))
continue;
 
@@ -645,10 +645,9 @@ static int cma_modify_qp_rtr(struct rdma_id_private 
*id_priv,
if (ret)
goto out;
 
-   if (rdma_node_get_transport(id_priv-cma_dev-device-node_type)
-   == RDMA_TRANSPORT_IB 
-   rdma_port_get_link_layer(id_priv-id.device, id_priv-id.port_num)
-   == IB_LINK_LAYER_ETHERNET) {
+   BUG_ON(id_priv-cma_dev-device != id_priv-id.device);
+
+   if (rdma_protocol_iboe(id_priv-id.device, id_priv-id.port_num)) {
ret = rdma_addr_find_smac_by_sgid(sgid, qp_attr.smac, NULL);
 
if (ret)
@@ -712,11 +711,10 @@ static int cma_ib_init_qp_attr(struct rdma_id_private 
*id_priv,
int ret;
u16 pkey;
 
-   if (rdma_port_get_link_layer(id_priv-id.device, id_priv-id.port_num) 
==
-   IB_LINK_LAYER_INFINIBAND)
-   pkey = ib_addr_get_pkey(dev_addr);
-   else
+   if (rdma_protocol_iboe(id_priv-id.device, id_priv-id.port_num))
pkey = 0x;
+   else
+   pkey = ib_addr_get_pkey(dev_addr);
 
ret = ib_find_cached_pkey(id_priv-id.device, id_priv-id.port_num,
  pkey, qp_attr-pkey_index);
-- 
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/

[PATCH v7 10/23] IB/Verbs: Reform cm related part in IB-core cma/ucm

[Michael Wang]

Use raw management helpers to reform cm related part in IB-core cma/ucm.

Few checks focus on the device cm type rather than the port capability,
directly pass port 1 works currently, but can't support mixing cm type
device in future.

Cc: Hal Rosenstock h...@dev.mellanox.co.il
Cc: Steve Wise sw...@opengridcomputing.com
Cc: Tom Talpey t...@talpey.com
Cc: Jason Gunthorpe jguntho...@obsidianresearch.com
Cc: Doug Ledford dledf...@redhat.com
Cc: Ira Weiny ira.we...@intel.com
Cc: Sean Hefty sean.he...@intel.com
Signed-off-by: Michael Wang yun.w...@profitbricks.com
---
 drivers/infiniband/core/cma.c | 81 +--
 drivers/infiniband/core/ucm.c |  3 +-
 2 files changed, 26 insertions(+), 58 deletions(-)

diff --git a/drivers/infiniband/core/cma.c b/drivers/infiniband/core/cma.c
index d570030..8a07e89 100644
--- a/drivers/infiniband/core/cma.c
+++ b/drivers/infiniband/core/cma.c
@@ -735,8 +735,7 @@ int rdma_init_qp_attr(struct rdma_cm_id *id, struct 
ib_qp_attr *qp_attr,
int ret = 0;
 
id_priv = container_of(id, struct rdma_id_private, id);
-   switch (rdma_node_get_transport(id_priv-id.device-node_type)) {
-   case RDMA_TRANSPORT_IB:
+   if (rdma_ib_or_iboe(id-device, id-port_num)) {
if (!id_priv-cm_id.ib || (id_priv-id.qp_type == IB_QPT_UD))
ret = cma_ib_init_qp_attr(id_priv, qp_attr, 
qp_attr_mask);
else
@@ -745,19 +744,15 @@ int rdma_init_qp_attr(struct rdma_cm_id *id, struct 
ib_qp_attr *qp_attr,
 
if (qp_attr-qp_state == IB_QPS_RTR)
qp_attr-rq_psn = id_priv-seq_num;
-   break;
-   case RDMA_TRANSPORT_IWARP:
+   } else if (rdma_protocol_iwarp(id-device, id-port_num)) {
if (!id_priv-cm_id.iw) {
qp_attr-qp_access_flags = 0;
*qp_attr_mask = IB_QP_STATE | IB_QP_ACCESS_FLAGS;
} else
ret = iw_cm_init_qp_attr(id_priv-cm_id.iw, qp_attr,
 qp_attr_mask);
-   break;
-   default:
+   } else
ret = -ENOSYS;
-   break;
-   }
 
return ret;
 }
@@ -1037,17 +1032,12 @@ void rdma_destroy_id(struct rdma_cm_id *id)
mutex_unlock(id_priv-handler_mutex);
 
if (id_priv-cma_dev) {
-   switch (rdma_node_get_transport(id_priv-id.device-node_type)) 
{
-   case RDMA_TRANSPORT_IB:
+   if (rdma_ib_or_iboe(id_priv-id.device, 1)) {
if (id_priv-cm_id.ib)
ib_destroy_cm_id(id_priv-cm_id.ib);
-   break;
-   case RDMA_TRANSPORT_IWARP:
+   } else if (rdma_protocol_iwarp(id_priv-id.device, 1)) {
if (id_priv-cm_id.iw)
iw_destroy_cm_id(id_priv-cm_id.iw);
-   break;
-   default:
-   break;
}
cma_leave_mc_groups(id_priv);
cma_release_dev(id_priv);
@@ -1626,7 +1616,7 @@ static void cma_listen_on_dev(struct rdma_id_private 
*id_priv,
int ret;
 
if (cma_family(id_priv) == AF_IB 
-   rdma_node_get_transport(cma_dev-device-node_type) != 
RDMA_TRANSPORT_IB)
+   !rdma_ib_or_iboe(cma_dev-device, 1))
return;
 
id = rdma_create_id(cma_listen_handler, id_priv, id_priv-id.ps,
@@ -2028,7 +2018,7 @@ static int cma_bind_loopback(struct rdma_id_private 
*id_priv)
mutex_lock(lock);
list_for_each_entry(cur_dev, dev_list, list) {
if (cma_family(id_priv) == AF_IB 
-   rdma_node_get_transport(cur_dev-device-node_type) != 
RDMA_TRANSPORT_IB)
+   !rdma_ib_or_iboe(cur_dev-device, 1))
continue;
 
if (!cma_dev)
@@ -2060,7 +2050,7 @@ port_found:
goto out;
 
id_priv-id.route.addr.dev_addr.dev_type =
-   (rdma_port_get_link_layer(cma_dev-device, p) == 
IB_LINK_LAYER_INFINIBAND) ?
+   (rdma_protocol_ib(cma_dev-device, p)) ?
ARPHRD_INFINIBAND : ARPHRD_ETHER;
 
rdma_addr_set_sgid(id_priv-id.route.addr.dev_addr, gid);
@@ -2537,18 +2527,15 @@ int rdma_listen(struct rdma_cm_id *id, int backlog)
 
id_priv-backlog = backlog;
if (id-device) {
-   switch (rdma_node_get_transport(id-device-node_type)) {
-   case RDMA_TRANSPORT_IB:
+   if (rdma_ib_or_iboe(id-device, 1)) {
ret = cma_ib_listen(id_priv);
if (ret)
goto err;
-   break;
-   case RDMA_TRANSPORT_IWARP:
+   } else if (rdma_protocol_iwarp(id-device, 1)) {
ret = cma_iw_listen(id_priv, backlog);
if (ret)
  

[PATCH v7 03/23] IB/Verbs: Reform IB-core mad/agent/user_mad

[Michael Wang]

Use raw management helpers to reform IB-core mad/agent/user_mad.

Cc: Hal Rosenstock h...@dev.mellanox.co.il
Cc: Steve Wise sw...@opengridcomputing.com
Cc: Tom Talpey t...@talpey.com
Cc: Jason Gunthorpe jguntho...@obsidianresearch.com
Cc: Doug Ledford dledf...@redhat.com
Cc: Ira Weiny ira.we...@intel.com
Cc: Sean Hefty sean.he...@intel.com
Signed-off-by: Michael Wang yun.w...@profitbricks.com
---
 drivers/infiniband/core/agent.c|  2 +-
 drivers/infiniband/core/mad.c  | 43 +++---
 drivers/infiniband/core/user_mad.c | 26 ---
 3 files changed, 41 insertions(+), 30 deletions(-)

diff --git a/drivers/infiniband/core/agent.c b/drivers/infiniband/core/agent.c
index f6d2961..89d4fbc 100644
--- a/drivers/infiniband/core/agent.c
+++ b/drivers/infiniband/core/agent.c
@@ -156,7 +156,7 @@ int ib_agent_port_open(struct ib_device *device, int 
port_num)
goto error1;
}
 
-   if (rdma_port_get_link_layer(device, port_num) == 
IB_LINK_LAYER_INFINIBAND) {
+   if (rdma_protocol_ib(device, port_num)) {
/* Obtain send only MAD agent for SMI QP */
port_priv-agent[0] = ib_register_mad_agent(device, port_num,
IB_QPT_SMI, NULL, 0,
diff --git a/drivers/infiniband/core/mad.c b/drivers/infiniband/core/mad.c
index 74c30f4..507eb67 100644
--- a/drivers/infiniband/core/mad.c
+++ b/drivers/infiniband/core/mad.c
@@ -2938,7 +2938,7 @@ static int ib_mad_port_open(struct ib_device *device,
init_mad_qp(port_priv, port_priv-qp_info[1]);
 
cq_size = mad_sendq_size + mad_recvq_size;
-   has_smi = rdma_port_get_link_layer(device, port_num) == 
IB_LINK_LAYER_INFINIBAND;
+   has_smi = rdma_protocol_ib(device, port_num);
if (has_smi)
cq_size *= 2;
 
@@ -3057,9 +3057,6 @@ static void ib_mad_init_device(struct ib_device *device)
 {
int start, end, i;
 
-   if (rdma_node_get_transport(device-node_type) != RDMA_TRANSPORT_IB)
-   return;
-
if (device-node_type == RDMA_NODE_IB_SWITCH) {
start = 0;
end   = 0;
@@ -3069,6 +3066,9 @@ static void ib_mad_init_device(struct ib_device *device)
}
 
for (i = start; i = end; i++) {
+   if (!rdma_ib_or_iboe(device, i))
+   continue;
+
if (ib_mad_port_open(device, i)) {
dev_err(device-dev, Couldn't open port %d\n, i);
goto error;
@@ -3086,40 +3086,39 @@ error_agent:
dev_err(device-dev, Couldn't close port %d\n, i);
 
 error:
-   i--;
+   while (--i = start) {
+   if (!rdma_ib_or_iboe(device, i))
+   continue;
 
-   while (i = start) {
if (ib_agent_port_close(device, i))
dev_err(device-dev,
Couldn't close port %d for agents\n, i);
if (ib_mad_port_close(device, i))
dev_err(device-dev, Couldn't close port %d\n, i);
-   i--;
}
 }
 
 static void ib_mad_remove_device(struct ib_device *device)
 {
-   int i, num_ports, cur_port;
-
-   if (rdma_node_get_transport(device-node_type) != RDMA_TRANSPORT_IB)
-   return;
+   int start, end, i;
 
if (device-node_type == RDMA_NODE_IB_SWITCH) {
-   num_ports = 1;
-   cur_port = 0;
+   start = 0;
+   end   = 0;
} else {
-   num_ports = device-phys_port_cnt;
-   cur_port = 1;
+   start = 1;
+   end   = device-phys_port_cnt;
}
-   for (i = 0; i  num_ports; i++, cur_port++) {
-   if (ib_agent_port_close(device, cur_port))
+
+   for (i = start; i = end; i++) {
+   if (!rdma_ib_or_iboe(device, i))
+   continue;
+
+   if (ib_agent_port_close(device, i))
dev_err(device-dev,
-   Couldn't close port %d for agents\n,
-   cur_port);
-   if (ib_mad_port_close(device, cur_port))
-   dev_err(device-dev, Couldn't close port %d\n,
-   cur_port);
+   Couldn't close port %d for agents\n, i);
+   if (ib_mad_port_close(device, i))
+   dev_err(device-dev, Couldn't close port %d\n, i);
}
 }
 
diff --git a/drivers/infiniband/core/user_mad.c 
b/drivers/infiniband/core/user_mad.c
index 928cdd2..aa8b334 100644
--- a/drivers/infiniband/core/user_mad.c
+++ b/drivers/infiniband/core/user_mad.c
@@ -1273,9 +1273,7 @@ static void ib_umad_add_one(struct ib_device *device)
 {
struct ib_umad_device *umad_dev;
int s, e, i;
-
-   if (rdma_node_get_transport(device-node_type) != RDMA_TRANSPORT_IB)
-   

Re: [PATCH v9 2/3] watchdog: add watchdog_cpumask sysctl to assist nohz

[Don Zickus]

cc'ing Andrew

On Mon, Apr 27, 2015 at 04:27:16PM -0400, Chris Metcalf wrote:
 I've been out on vacation the last ten days, but picking this up
 again now.
 
 I'll wait a bit before putting out a v10, and also address Uli's additional
 emails.  Meanwhile, who is the right person to eventually pick up this 
 patchset
 and push it up to Linus?  Frederic, Don, Thomas, akpm?  v9 is here:

I usually resubmit watchdog changes with my signoff to Andrew.  But would
just my ACK be ok, Andrew?

Cheers,
Don

 
 https://lkml.org/lkml/2015/4/17/697
 
 And I haven't heard any feedback on my fix to /proc/self/stat etc. to
 avoid showing the PARKED threads in R state (patch 3/3 from that series).
 
 Thanks for any guidance.
 
 
 On 04/22/2015 11:21 AM, Don Zickus wrote:
 On Wed, Apr 22, 2015 at 07:02:31AM -0400, Ulrich Obergfell wrote:
 Chris,
 
 in https://lkml.org/lkml/2015/4/17/616 you stated:
 
+ alloc_cpumask_var(watchdog_cpumask_for_smpboot, GFP_KERNEL);

 alloc_cpumask_var could fail?
 
Good catch; if I get a failure I'll just return early without trying to
start the watchdog, since clearly things are too memory-constrained
to enable that functionality anyway.
 
 Let's assume that (in spite of the memory constraints) the kernel would 
 still
 be able to make progress and get to a point where the system will be usable.
 In this corner case, the following code would leave a NULL pointer behind in
 watchdog_cpumask and in watchdog_cpumask_bits which could subsequently lead
 to a crash.
 
   void __init lockup_detector_init(void)
   {
   set_sample_period();
 +if (!alloc_cpumask_var(watchdog_cpumask, GFP_KERNEL)) {
 +pr_err(Failed to allocate cpumask for watchdog);
 +return;
 +}
 +watchdog_cpumask_bits = cpumask_bits(watchdog_cpumask);
 
 For example, proc_watchdog_cpumask() and the change that your patch 
 introduces
 in watchdog_enable_all_cpus() are not protected against a possible NULL 
 pointer.
 I think the code needs to be made safer.
 Or we could just statically allocate it
 
 static DECLARE_BITMAP(watchdog_cpumask, NR_CPUS) __read_mostly;
 
 Cheers,
 Don
 
 I think Don's suggestion is best here.  It's too intrusive to try to check
 for the out-of-memory condition everywhere in the code, just to guard
 against the possibility that a system that is already out of memory while
 starting the watchdog still has users trying to fiddle with the
 /proc/sys/kernel/watchdog* knobs.
 
 The diff against v9 is just this (plus changing watchdog_cpumask to
 watchdog_cpumask in a bunch of places):
 
 diff --git a/kernel/watchdog.c b/kernel/watchdog.c
 index 8875717b6616..ec742f38c90d 100644
 --- a/kernel/watchdog.c
 +++ b/kernel/watchdog.c
 @@ -57,8 +57,8 @@ int __read_mostly sysctl_softlockup_all_cpu_backtrace;
  #else
  #define sysctl_softlockup_all_cpu_backtrace 0
  #endif
 -static cpumask_var_t watchdog_cpumask;
 -unsigned long *watchdog_cpumask_bits;
 +static struct cpumask __read_mostly;
 +unsigned long *watchdog_cpumask_bits = cpumask_bits(watchdog_cpumask);
  /* Helper for online, unparked cpus. */
  #define for_each_watchdog_cpu(cpu) \
 @@ -913,12 +913,6 @@ void __init lockup_detector_init(void)
  {
 set_sample_period();
 -   if (!alloc_cpumask_var(watchdog_cpumask, GFP_KERNEL)) {
 -   pr_err(Failed to allocate cpumask for watchdog);
 -   return;
 -   }
 -   watchdog_cpumask_bits = cpumask_bits(watchdog_cpumask);
 -
  #ifdef CONFIG_NO_HZ_FULL
 if (!cpumask_empty(tick_nohz_full_mask))
 pr_info(Disabling watchdog on nohz_full cores by default\n);
 
 That said, presumably we need to schedule a cage match between Frederic and 
 Don
 to decide on whether it's best to statically allocate cpumasks or not :-)
 
 https://lkml.org/lkml/2015/4/16/416
 
 My sense is that in this case it's appropriate, since it's much harder to
 manage the failure case, whereas in the earlier discussion for
 smpboot_update_cpumask_percpu_thread() it made sense to just give up and
 return a quick ENOMEM.  Also, in this case we have no locking issues.
 -- 
 Chris Metcalf, EZChip Semiconductor
 http://www.ezchip.com
 
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH v7 02/23] IB/Verbs: Implement raw management helpers

[Michael Wang]

Add raw helpers:
rdma_protocol_ib
rdma_protocol_iboe
rdma_protocol_iwarp
rdma_ib_or_iboe
To help us detect which technology the port supported.

Cc: Hal Rosenstock h...@dev.mellanox.co.il
Cc: Steve Wise sw...@opengridcomputing.com
Cc: Tom Talpey t...@talpey.com
Cc: Jason Gunthorpe jguntho...@obsidianresearch.com
Cc: Doug Ledford dledf...@redhat.com
Cc: Ira Weiny ira.we...@intel.com
Cc: Sean Hefty sean.he...@intel.com
Signed-off-by: Michael Wang yun.w...@profitbricks.com
---
 include/rdma/ib_verbs.h | 22 ++
 1 file changed, 22 insertions(+)

diff --git a/include/rdma/ib_verbs.h b/include/rdma/ib_verbs.h
index 080f204..acdba60 100644
--- a/include/rdma/ib_verbs.h
+++ b/include/rdma/ib_verbs.h
@@ -1752,6 +1752,28 @@ int ib_query_port(struct ib_device *device,
 enum rdma_link_layer rdma_port_get_link_layer(struct ib_device *device,
   u8 port_num);
 
+static inline int rdma_protocol_ib(struct ib_device *device, u8 port_num)
+{
+   return device-query_protocol(device, port_num) == RDMA_PROTOCOL_IB;
+}
+
+static inline int rdma_protocol_iboe(struct ib_device *device, u8 port_num)
+{
+   return device-query_protocol(device, port_num) == RDMA_PROTOCOL_IBOE;
+}
+
+static inline int rdma_protocol_iwarp(struct ib_device *device, u8 port_num)
+{
+   return device-query_protocol(device, port_num) == RDMA_PROTOCOL_IWARP;
+}
+
+static inline int rdma_ib_or_iboe(struct ib_device *device, u8 port_num)
+{
+   enum rdma_protocol_type pt = device-query_protocol(device, port_num);
+
+   return (pt == RDMA_PROTOCOL_IB || pt == RDMA_PROTOCOL_IBOE);
+}
+
 int ib_query_gid(struct ib_device *device,
 u8 port_num, int index, union ib_gid *gid);
 
-- 
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/

overlayfs: upperdir and workdir on same mount but different btrfs subvolume

[Michael Göhler]

Hi,

think I found a small issue in overlayfs (kernel 4.0.0).

If I mount an overlay and specify two different subvolumes from the same 
btrfs

mount point, I don't get the expected:
overlayfs: workdir and upperdir must reside under the same mount

But any write operation on files from lowerdir fails with:
Invalid cross-device link

--
Michael Göhler
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@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] block: loop: avoiding too many pending per work I/O

[Ming Lei]

If there are too many pending per work I/O, too many
high priority work thread can be generated so that
system performance can be effected.

This patch limits the max pending per work I/O as 16,
and will fackback to single queue mode when the max
number is reached.

This patch fixes Fedora 22 live booting performance
regression when it is booted from squashfs over dm
based on loop, and looks the following reasons are
related with the problem:

- not like other filesyststems(such as ext4), squashfs
is a bit special, and I observed that increasing I/O jobs
to access file in squashfs only improve I/O performance a
little, but it can make big difference for ext4

- nested loop: both squashfs.img and ext3fs.img are mounted
as loop block, and ext3fs.img is inside the squashfs

- during booting, lots of tasks may run concurrently

Fixes: b5dd2f6047ca108001328aac0e8588edd15f1778
Cc: sta...@vger.kernel.org (v4.0)
Reported-by: Justin M. Forbes jfor...@fedoraproject.org
Tested-by: Justin M. Forbes jfor...@fedoraproject.org
Signed-off-by: Ming Lei ming@canonical.com
---
 drivers/block/loop.c | 19 +--
 drivers/block/loop.h |  2 ++
 2 files changed, 19 insertions(+), 2 deletions(-)

diff --git a/drivers/block/loop.c b/drivers/block/loop.c
index d7173cb..4db0301 100644
--- a/drivers/block/loop.c
+++ b/drivers/block/loop.c
@@ -1425,13 +1425,24 @@ static int loop_queue_rq(struct blk_mq_hw_ctx *hctx,
const struct blk_mq_queue_data *bd)
 {
struct loop_cmd *cmd = blk_mq_rq_to_pdu(bd-rq);
+   struct loop_device *lo = cmd-rq-q-queuedata;
+   bool single_queue = !!(cmd-rq-cmd_flags  REQ_WRITE);
+
+   /*
+* Fallback to single queue mode if the pending per work
+* I/O number reaches 32, otherwise too many high priority
+* worker thread may effect system performance as reported
+* in fedora live booting from squashfs over loop.
+*/
+   if (atomic_read(lo-pending_per_work_io) = 32)
+   single_queue = true;
 
blk_mq_start_request(bd-rq);
 
-   if (cmd-rq-cmd_flags  REQ_WRITE) {
-   struct loop_device *lo = cmd-rq-q-queuedata;
+   if (single_queue) {
bool need_sched = true;
 
+   cmd-per_work_io = false;
spin_lock_irq(lo-lo_lock);
if (lo-write_started)
need_sched = false;
@@ -1443,6 +1454,8 @@ static int loop_queue_rq(struct blk_mq_hw_ctx *hctx,
if (need_sched)
queue_work(loop_wq, lo-write_work);
} else {
+   cmd-per_work_io = true;
+   atomic_inc(lo-pending_per_work_io);
queue_work(loop_wq, cmd-read_work);
}
 
@@ -1467,6 +1480,8 @@ static void loop_handle_cmd(struct loop_cmd *cmd)
if (ret)
cmd-rq-errors = -EIO;
blk_mq_complete_request(cmd-rq);
+   if (cmd-per_work_io)
+   atomic_dec(lo-pending_per_work_io);
 }
 
 static void loop_queue_write_work(struct work_struct *work)
diff --git a/drivers/block/loop.h b/drivers/block/loop.h
index 301c27f..eb855f5 100644
--- a/drivers/block/loop.h
+++ b/drivers/block/loop.h
@@ -57,6 +57,7 @@ struct loop_device {
struct list_headwrite_cmd_head;
struct work_struct  write_work;
boolwrite_started;
+   atomic_tpending_per_work_io;
int lo_state;
struct mutexlo_ctl_mutex;
 
@@ -68,6 +69,7 @@ struct loop_device {
 struct loop_cmd {
struct work_struct read_work;
struct request *rq;
+   bool per_work_io;
struct list_head list;
 };
 
-- 
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 v6 1/3] nand: pl353: Add basic driver for arm pl353 smc nand interface

[Ben Shelton]

Hi Punnaiah,

On 04/13, Punnaiah Choudary Kalluri wrote:
 Add driver for arm pl353 static memory controller nand interface with
 HW ECC support. This controller is used in xilinx zynq soc for interfacing
 the nand flash memory.
 
 Signed-off-by: Punnaiah Choudary Kalluri punn...@xilinx.com

[...]

 +
 +static int pl353_nand_init_timing(struct device *dev, int mode)
 +{
 + const struct nand_sdr_timings *time;
 + u32 t_rc, t_wc, t_rea, t_wp, t_clr, t_ar, t_rr;
 + ulong clkrate;
 +
 + time = onfi_async_timing_mode_to_sdr_timings(mode);
 + if (IS_ERR(time))
 + return PTR_ERR(time);
 +
 + clkrate = pl353_smc_get_clkrate(dev);
 + t_rc  = get_cyc_from_ns(clkrate, time-tRC_min / 1000);
 + t_wc  = get_cyc_from_ns(clkrate, time-tWC_min / 1000);
 + t_rea = get_cyc_from_ns(clkrate, time-tREA_max / 1000);
 + t_wp  = get_cyc_from_ns(clkrate, time-tWP_min / 1000);
 + t_clr = get_cyc_from_ns(clkrate, time-tCLR_min / 1000);
 + t_ar  = get_cyc_from_ns(clkrate, time-tAR_min / 1000);
 + t_rr  = get_cyc_from_ns(clkrate, time-tRR_min / 1000);

I tested this patch set in conjunction with your PL353 SMC patch set.

Our first stage bootloader sets the SMC memclk rate to 166.6 MHz, which leads
this code to calculate a t_rc and t_wc of 17 cycles for ONFI mode 0.  As I
mentioned in my response to your SMC patch, this overflows the 4-bit-wide
register fields in the SMC that hold these values.

Could we somehow set it up so the NAND and SMC drivers work together to adjust
the memclk rate, if necessary, to achieve the desired timings?  Or is there a
better way to handle this?

 +
 + pl353_smc_set_cycles(dev, t_rc, t_wc, t_rea, t_wp, t_clr, t_ar, t_rr);
 +
 + return 0;
 +}

Thanks,
Ben
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@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/9] mm: improve OOM mechanism v2

[Tetsuo Handa]

Michal Hocko wrote:
 On Tue 28-04-15 19:34:47, Tetsuo Handa wrote:
 [...]
  [PATCH 8/9] makes the speed of allocating __GFP_FS pages extremely slow (5
  seconds / page) because out_of_memory() serialized by the oom_lock sleeps 
  for
  5 seconds before returning true when the OOM victim got stuck. This 
  throttling
  also slows down !__GFP_FS allocations when there is a thread doing a 
  __GFP_FS
  allocation, for __alloc_pages_may_oom() is serialized by the oom_lock
  regardless of gfp_mask.
 
 This is indeed unnecessary.
 
  How long will the OOM victim is blocked when the
  allocating task needs to allocate e.g. 1000 !__GFP_FS pages before allowing
  the OOM victim waiting at mutex_lock(inode-i_mutex) to continue? It will 
  be
  a too-long-to-wait stall which is effectively a deadlock for users. I think
  we should not sleep with the oom_lock held.
 
 I do not see why sleeping with oom_lock would be a problem. It simply
 doesn't make much sense to try to trigger OOM killer when there is/are
 OOM victims still exiting.

Because thread A's memory allocation is deferred by threads B, C, D...'s memory
allocation which are holding (or waiting for) the oom_lock when the OOM victim
is waiting for thread A's allocation. I think that a memory allocator which
allocates at average 5 seconds is considered as unusable. If we sleep without
the oom_lock held, the memory allocator can allocate at average
(5 / number_of_allocating_threads) seconds. Sleeping with the oom_lock held
can effectively prevent thread A from making progress.

  By the way, I came up with an idea (incomplete patch on top of patches up to
  7/9 is shown below) while trying to avoid sleeping with the oom_lock held.
  This patch is meant for
  
(1) blocking_notifier_call_chain(oom_notify_list) is called after
the OOM killer is disabled in order to increase possibility of
memory allocation to succeed.
 
 How do you guarantee that the notifier doesn't wake up any process and
 break the oom_disable guarantee?

I thought oom_notify_list wakes up only kernel threads. OK, that's the reason
we don't call oom_notify_list after the OOM killer is disabled?

 
(2) oom_kill_process() can determine when to kill next OOM victim.
  
(3) oom_scan_process_thread() can take TIF_MEMDIE timeout into
account when choosing an OOM victim.
 
 You have heard my opinions about this and I do not plan to repeat them
 here again.

Yes, I've heard your opinions. But neither ALLOC_NO_WATERMARKS nor WMARK_OOM
is a perfect measure for avoiding deadlock. We want to solve Without any
extra measures the above situation will result in a deadlock problem.
When WMARK_OOM failed to avoid the deadlock, and we don't want to go to
ALLOC_NO_WATERMARKS, I think somehow choosing and killing more victims is
the only possible measure. Maybe choosing next OOM victim upon reaching
WMARK_OOM?
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@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] xen/xenbus: Update xenbus event channel on resume

[Boris Ostrovsky]

After a resume the hypervisor/tools may change xenbus event
channel number. We should re-query it.

Signed-off-by: Boris Ostrovsky boris.ostrov...@oracle.com
---
 drivers/xen/xenbus/xenbus_probe.c |   28 
 1 files changed, 28 insertions(+), 0 deletions(-)

diff --git a/drivers/xen/xenbus/xenbus_probe.c 
b/drivers/xen/xenbus/xenbus_probe.c
index 564b315..31737a4 100644
--- a/drivers/xen/xenbus/xenbus_probe.c
+++ b/drivers/xen/xenbus/xenbus_probe.c
@@ -57,6 +57,7 @@
 #include xen/xen.h
 #include xen/xenbus.h
 #include xen/events.h
+#include xen/xen-ops.h
 #include xen/page.h
 
 #include xen/hvm.h
@@ -735,6 +736,30 @@ static int __init xenstored_local_init(void)
return err;
 }
 
+static int xenbus_resume_cb(struct notifier_block *nb,
+   unsigned long action, void *data)
+{
+   int err = 0;
+
+   if (xen_hvm_domain()) {
+   uint64_t v;
+
+   err = hvm_get_parameter(HVM_PARAM_STORE_EVTCHN, v);
+   if (!err  v)
+   xen_store_evtchn = v;
+   else
+   pr_warn(Cannot update xenstore event channel: %d\n,
+   err);
+   } else
+   xen_store_evtchn = xen_start_info-store_evtchn;
+
+   return err;
+}
+
+static struct notifier_block xenbus_resume_nb = {
+   .notifier_call = xenbus_resume_cb,
+};
+
 static int __init xenbus_init(void)
 {
int err = 0;
@@ -793,6 +818,9 @@ static int __init xenbus_init(void)
goto out_error;
}
 
+   if (!xen_initial_domain())
+   xen_resume_notifier_register(xenbus_resume_nb);
+
 #ifdef CONFIG_XEN_COMPAT_XENFS
/*
 * Create xenfs mountpoint in /proc for compatibility with
-- 
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/

[PATCH 3/4] xen/console: Update console event channel on resume

[Boris Ostrovsky]

After a resume the hypervisor/tools may change console event
channel number. We should re-query it.

Signed-off-by: Boris Ostrovsky boris.ostrov...@oracle.com
---
 drivers/tty/hvc/hvc_xen.c |   18 +-
 1 files changed, 17 insertions(+), 1 deletions(-)

diff --git a/drivers/tty/hvc/hvc_xen.c b/drivers/tty/hvc/hvc_xen.c
index 5eb80bd..d5fedc0 100644
--- a/drivers/tty/hvc/hvc_xen.c
+++ b/drivers/tty/hvc/hvc_xen.c
@@ -299,11 +299,27 @@ static int xen_initial_domain_console_init(void)
return 0;
 }
 
+static void xen_console_update_evtchn(struct xencons_info *info)
+{
+   if (xen_hvm_domain()) {
+   uint64_t v;
+   int err;
+
+   err = hvm_get_parameter(HVM_PARAM_CONSOLE_EVTCHN, v);
+   if (!err  v)
+   info-evtchn = v;
+   } else
+   info-evtchn = xen_start_info-console.domU.evtchn;
+}
+
 void xen_console_resume(void)
 {
struct xencons_info *info = vtermno_to_xencons(HVC_COOKIE);
-   if (info != NULL  info-irq)
+   if (info != NULL  info-irq) {
+   if (!xen_initial_domain())
+   xen_console_update_evtchn(info);
rebind_evtchn_irq(info-evtchn, info-irq);
+   }
 }
 
 static void xencons_disconnect_backend(struct xencons_info *info)
-- 
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/

[PATCH 4/4] xen/events: Set irq_info-evtchn before binding the channel to CPU in __startup_pirq()

[Boris Ostrovsky]

.. because bind_evtchn_to_cpu(evtchn, cpu) will map evtchn to
'info' and pass 'info' down to xen_evtchn_port_bind_to_cpu().

Signed-off-by: Boris Ostrovsky boris.ostrov...@oracle.com
Tested-by: Annie Li annie...@oracle.com
---
 drivers/xen/events/events_base.c |2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/drivers/xen/events/events_base.c b/drivers/xen/events/events_base.c
index 70fba97..f81d322 100644
--- a/drivers/xen/events/events_base.c
+++ b/drivers/xen/events/events_base.c
@@ -529,8 +529,8 @@ static unsigned int __startup_pirq(unsigned int irq)
if (rc)
goto err;
 
-   bind_evtchn_to_cpu(evtchn, 0);
info-evtchn = evtchn;
+   bind_evtchn_to_cpu(evtchn, 0);
 
rc = xen_evtchn_port_setup(info);
if (rc)
-- 
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/

[PATCH 0/4] A few event channel-related fixes

[Boris Ostrovsky]

Fixes for issues that we discovered during live migration when source and
target systems have different event channel assignments for guests.

Boris Ostrovsky (4):
  xen/events: Clear cpu_evtchn_mask before resuming
  xen/xenbus: Update xenbus event channel on resume
  xen/console: Update console event channel on resume
  xen/events: Set irq_info-evtchn before binding the channel to CPU in
__startup_pirq()

 drivers/tty/hvc/hvc_xen.c |   19 ++-
 drivers/xen/events/events_2l.c|   10 ++
 drivers/xen/events/events_base.c  |2 +-
 drivers/xen/xenbus/xenbus_comms.c |1 +
 drivers/xen/xenbus/xenbus_probe.c |   28 
 5 files changed, 58 insertions(+), 2 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/

Re: [PATCH v2 1/2] x86: introduce kaslr_offset()

[Jiri Kosina]

On Tue, 28 Apr 2015, Jiri Kosina wrote:

 Offset that has been chosen for kaslr during kernel decompression can be 
 easily computed as a difference between _text and __START_KERNEL. We are 
 already making use of this in dump_kernel_offset() notifier and in 
 arch_crash_save_vmcoreinfo().
 
 Introduce kaslr_offset() that makes this computation instead of 
 hard-coding it, so that other kernel code (such as live patching) can make 
 use of it. Also convert existing users to make use of it.
 
 Signed-off-by: Jiri Kosina jkos...@suse.cz
 ---
 
 It'd be great to potentially have Ack from x86 guys for this patch so that 
 I could take it through livepatching.git with the depending 2/2 patch. 
 Thanks.
 
 v1 - v2: convert arch_crash_save_vmcoreinfo(), as spotted by Josh 
 Poimboeuf.

FWIW this patch is equivalent transofrmation without any effects on the 
resulting code:

$ diff -u vmlinux.old.asm vmlinux.new.asm
--- vmlinux.old.asm 2015-04-28 17:55:19.520983368 +0200
+++ vmlinux.new.asm 2015-04-28 17:55:24.141206072 +0200
@@ -1,5 +1,5 @@
 
-vmlinux.old: file format elf64-x86-64
+vmlinux.new: file format elf64-x86-64
 
 
 Disassembly of section .text:
$

-- 
Jiri Kosina
SUSE Labs
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@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 01/10] block: make generic_make_request handle arbitrarily sized bios

[Keith Busch]

On Tue, 28 Apr 2015, Christoph Hellwig wrote:

This seems to lack support for QUEUE_FLAG_SG_GAPS to work around
the retarded PPR format in the NVMe driver.


Might strong words, sir! I'm missing the context here, but I'll say PRP
is much more efficient for h/w to process over SGL, and the requirement
comes from that h/w rather than the driver.
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Should mmap MAP_LOCKED fail if mm_poppulate fails?

[Linus Torvalds]

On Tue, Apr 28, 2015 at 5:11 AM, Michal Hocko mho...@suse.cz wrote:

 The first patch is dumb and straightforward. It should be safe as is and
 also good without the follow up 2 patches which try to handle potential
 allocation failures in the do_munmap path more gracefully. As we still
 do not fail small allocations even the first patch could be simplified
 a bit and the retry loop replaced by a BUG_ON right away.

I think the BUG_ON() is a bad idea in the first place, and is in fact
a good reason to ignore the patch series entirely.

What is the point of that BUG_ON()?

Hell, people add too many of those things. There is *no* excuse for
killing the kernel for things like this (and in certain setups,
BUG_ON() *will* cause the machine to be rebooted). None. It's
completely inexcusable.

Thinking like this must go. BUG_ON() is for things where our internal
data structures are so corrupted that we don't know what to do, and
there's no way to continue. Not for I want to sprinkle these things
around and this should not happen.

I also think that the whole complex do_munmap_nofail() is broken to
begin with, along with the crazy !fatal_signal_pending() thing.
There is absolutely no excuse for any of this.

Your code is also fundamentally buggy in that it tries to do unmap()
after it has dropped all locks, and things went wrong. So you may nto
be unmapping some other threads data.

There is no way in hell any of these patches can ever be applied.

There's a reason we don't handle populate failures - it's exactly
because we've dropped the locks etc. After dropping the locks, we
*cannot* clean up any more, because there's no way to know whather
we're cleaning up the right thing.  You'd have to hold the write lock
over the whole populate, which has serious problems of its own.

So NAK on this series. I think just documenting the man-page might be
better. I don't think MAP_LOCKED is sanely fixable.

We might improve on MAP_LOCKED by having a heuristic up-front
(*before* actually doing any mmap) to verify that it's *likely* that
it will work. So we could return ENOMEM early if it looks like the
user would hit the resource limits, for example. That wouldn't be any
guarantee (another process might eat up the resource limit anyway),
and in fact it might be overly eager to fail (maybe the
mmap(MAP_LOCKED ends up unmapping an older locked mapping and we deny
it too eagerly), but it would probably work well enough in practice.

That, together with a warning in the man-page about mmap(MAP_LOCKED)
not being able to return I only locked part of the mapping, if you
want full error handling you need to do mmap()+mlock() and check the
two errors separately.

Hmm? But I really dislike your patch-series as-is.

   Linus

  Linus

   Linus
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v10 0/9] ASoC: tda998x: add a codec to the HDMI transmitter

[Jean-Francois Moine]

On Mon, 27 Apr 2015 20:25:02 +0200
Jean-Francois Moine  wrote:

> Using i2s and s/pdif at the same time with the simple card asks for a
> patch as the one I submitted in february 2014 (ASoC: simple-card: DT
> fix and multi DAI links extension).

Sorry, the patch was "ASoC: simple-card: Add multi-CODEC support"
submitted in january 2015:

http://mailman.alsa-project.org/pipermail/alsa-devel/2015-January/085855.html

-- 
Ken ar c'hentañ | ** Breizh ha Linux atav! **
Jef |   http://moinejf.free.fr/
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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: Build regressions/improvements in v4.1-rc1

[Geert Uytterhoeven]

On Tue, Apr 28, 2015 at 6:39 AM, Rusty Russell  wrote:
>>>   + /home/kisskb/slave/src/arch/mips/cavium-octeon/smp.c: error: passing 
>>> argument 2 of 'cpumask_clear_cpu' discards 'volatile' qualifier from 
>>> pointer target type [-Werror]:  => 242:2
>>>   + /home/kisskb/slave/src/arch/mips/kernel/process.c: error: passing 
>>> argument 2 of 'cpumask_test_cpu' discards 'volatile' qualifier from pointer 
>>> target type [-Werror]:  => 52:2
>>>   + /home/kisskb/slave/src/arch/mips/kernel/smp.c: error: passing argument 
>>> 2 of 'cpumask_set_cpu' discards 'volatile' qualifier from pointer target 
>>> type [-Werror]:  => 149:2, 211:2
>>>   + /home/kisskb/slave/src/arch/mips/kernel/smp.c: error: passing argument 
>>> 2 of 'cpumask_test_cpu' discards 'volatile' qualifier from pointer target 
>>> type [-Werror]:  => 221:2

> and related warnings due to lack of -Werror on

>> tilegx_defconfig
>
> Can't see that one with a simple grep: can you post warning?

/home/kisskb/slave/src/arch/tile/kernel/setup.c: In function 'zone_sizes_init':
/home/kisskb/slave/src/arch/tile/kernel/setup.c:777:3: warning:
passing argument 2 of 'cpumask_test_cpu' from incompatible pointer
type [enabled by default]
/home/kisskb/slave/src/include/linux/cpumask.h:294:19: note: expected
'const struct cpumask *' but argument is of type 'struct nodemask_t *'

Gr{oetje,eeting}s,

Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 1/3] x86, ACPI: Constify irq_domain_ops

[Pavel Machek]

On Mon 2015-04-27 21:48:07, Krzysztof Kozlowski wrote:
> The irq_domain_ops are not modified by the driver and the irqdomain core
> code accepts pointer to a const data.
> 
> Signed-off-by: Krzysztof Kozlowski 

Acked-by: Pavel Machek 

-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) 
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v2] drm: fix a memleak on mutex failure path

[Jani Nikula]

On Mon, 27 Apr 2015, gr...@linuxhacker.ru wrote:
> From: Oleg Drokin 
>
> Need to free just allocated ctx allocation if we cannot
> get our config mutex.
>
> This one has been flagged by kbuild bot all the way back in August,
> but somehow nobody picked it up:
> https://lists.01.org/pipermail/kbuild/2014-August/001691.html
>
> In addition there is another failure path that leaks the same
> ctx reference that is fixed.
>
> Found with smatch.
>
> Signed-off-by: Oleg Drokin 
> CC: Daniel Vetter 

Reviewed-by: Jani Nikula 


> ---
>  drivers/gpu/drm/drm_modeset_lock.c | 8 ++--
>  1 file changed, 6 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_modeset_lock.c 
> b/drivers/gpu/drm/drm_modeset_lock.c
> index 51cc47d..c0a5cd8 100644
> --- a/drivers/gpu/drm/drm_modeset_lock.c
> +++ b/drivers/gpu/drm/drm_modeset_lock.c
> @@ -80,8 +80,10 @@ int __drm_modeset_lock_all(struct drm_device *dev,
>   return -ENOMEM;
>  
>   if (trylock) {
> - if (!mutex_trylock(>mutex))
> - return -EBUSY;
> + if (!mutex_trylock(>mutex)) {
> + ret = -EBUSY;
> + goto out;
> + }
>   } else {
>   mutex_lock(>mutex);
>   }
> @@ -114,6 +116,8 @@ fail:
>   goto retry;
>   }
>  
> +out:
> + kfree(ctx);
>   return ret;
>  }
>  EXPORT_SYMBOL(__drm_modeset_lock_all);
> -- 
> 2.1.0
>

-- 
Jani Nikula, Intel Open Source Technology Center
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v2] Revert "usb: host: ehci-msm: Use devm_ioremap_resource instead of devm_ioremap"

[Vivek Gautam]

Hi,

--
From: "Alan Stern" 
Sent: Monday, April 27, 2015 8:14 PM
To: "Ivan T. Ivanov" 
Cc: "Greg Kroah-Hartman" ; 
; ; 
; "Vivek Gautam" 
Subject: Re: [PATCH v2] Revert "usb: host: ehci-msm: Use 
devm_ioremap_resource instead of devm_ioremap"



On Mon, 27 Apr 2015, Ivan T. Ivanov wrote:


This reverts commit 70843f623b58 ("usb: host: ehci-msm: Use
devm_ioremap_resource instead of devm_ioremap") and commit
e507bf577e5a ("host: ehci-msm: remove duplicate check on resource"),
because msm_otg and this driver are using same address space to
access AHB mode and USB command registers.

Cc: Vivek Gautam 
Signed-off-by: Ivan T. Ivanov 
---

Changes since v0:

* Add note to patch description that also commit e507bf577e5a is 
reverted.


Ok,

Acked-by: Vivek Gautam 



 drivers/usb/host/ehci-msm.c | 13 ++---
 1 file changed, 10 insertions(+), 3 deletions(-)

diff --git a/drivers/usb/host/ehci-msm.c b/drivers/usb/host/ehci-msm.c
index 9db74ca..275c92e 100644
--- a/drivers/usb/host/ehci-msm.c
+++ b/drivers/usb/host/ehci-msm.c
@@ -88,13 +88,20 @@ static int ehci_msm_probe(struct platform_device 
*pdev)

 }

 res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
- hcd->regs = devm_ioremap_resource(>dev, res);
- if (IS_ERR(hcd->regs)) {
- ret = PTR_ERR(hcd->regs);
+ if (!res) {
+ dev_err(>dev, "Unable to get memory resource\n");
+ ret = -ENODEV;
 goto put_hcd;
 }
+
 hcd->rsrc_start = res->start;
 hcd->rsrc_len = resource_size(res);
+ hcd->regs = devm_ioremap(>dev, hcd->rsrc_start, hcd->rsrc_len);
+ if (!hcd->regs) {
+ dev_err(>dev, "ioremap failed\n");
+ ret = -ENOMEM;
+ goto put_hcd;
+ }

 /*
 * OTG driver takes care of PHY initialization, clock management,
--
1.9.1


Acked-by: Alan Stern 


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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/4] mailbox: add support for System Control and Power Interface(SCPI) protocol

[Paul Bolle]

Just one nit: a license mismatch.

On Mon, 2015-04-27 at 12:40 +0100, Sudeep Holla wrote:
> --- /dev/null
> +++ b/drivers/mailbox/scpi_protocol.c

> + * This program is free software; you can redistribute it and/or modify it
> + * under the terms and conditions of the GNU General Public License,
> + * version 2, as published by the Free Software Foundation.
> + *
> + * This program is distributed in the hope it will be useful, but WITHOUT
> + * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
> + * FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License for
> + * more details.
> + *
> + * You should have received a copy of the GNU General Public License along
> + * with this program. If not, see .

This states the license is GPL v2.

> +MODULE_LICENSE("GPL");

And, according to include/linux/module.h, this states the license is GPL
v2 or later. So I think either the comment at the top of this file or
the license ident used in the MODULE_LICENSE() macro should be changed.

Likewise for 2/4 and 4/4.

Thanks,


Paul Bolle

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH v3 0/3] Add Mediatek SoC RTC driver

[Eddie Huang]

RTC is one submodule of Mediatek MT6397 PMIC chip[1]. This series
support RTC driver that work with Mediatek SoC like MT8135, MT8173.
It implements second counter and also provide alarm function.

This series base on 4.1-rc1, Test ok on MT8173 platform.

[1] https://lkml.org/lkml/2015/1/23/325

Change in v3:
1. Replace magic number in mt6397-core.c
2. Add comment for some equation and write trigger.
3. Use regmap_bulk_read and regmap_bulk_write to avoid muliple regmap_read
   and regmap_write
4. Replace devm_request_threaded_irq with request_threaded_irq and add
   irq_dispose_mapping
5. Fix Tomasz Figa review comment.

Change in v2:
1. Move RTC address and interrupt to mt6397-core.c, and register
   these resource in mfd_cell.
   
http://lists.infradead.org/pipermail/linux-arm-kernel/2015-February/323239.html
2. Remove dt-binding document due to register resouce in mfd_cell, not from
   device tree.
3. Update MAINTAINER file to add Mediatek RTC mainainter.
4. Add prefix mtk_ to some internal functions.
5. Fix racy condition
6. Check return value of regmap_read and regmap_write
7. Remove some unnecessary register readback, clear, then write.
8. Add disable alarm in mtk_rtc_set_alarm function
9. Fix Uwe Kleine-König review comment

Eddie Huang (2):
  mfd: provide RTC resource in MT6397 MFD
  MAINTAINERS: add Mediatek RTC driver

Tianping Fang (1):
  rtc: mediatek: Add MT6397 RTC driver

 MAINTAINERS   |   7 +
 drivers/mfd/mt6397-core.c |  18 +++
 drivers/rtc/Kconfig   |  10 ++
 drivers/rtc/Makefile  |   1 +
 drivers/rtc/rtc-mt6397.c  | 388 ++
 5 files changed, 424 insertions(+)
 create mode 100644 drivers/rtc/rtc-mt6397.c

--
1.8.1.1.dirty

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH v3 1/3] mfd: provide RTC resource in MT6397 MFD

[Eddie Huang]

Provide MT6397 RTC interrupt, base address, and register in
MT6397 MFD.

Signed-off-by: Eddie Huang 
---
 drivers/mfd/mt6397-core.c | 18 ++
 1 file changed, 18 insertions(+)

diff --git a/drivers/mfd/mt6397-core.c b/drivers/mfd/mt6397-core.c
index 09bc780..08cfbd1 100644
--- a/drivers/mfd/mt6397-core.c
+++ b/drivers/mfd/mt6397-core.c
@@ -21,9 +21,27 @@
 #include 
 #include 
 
+#define MT6397_RTC_BASE0xe000
+#define MT6397_RTC_SIZE0x3e
+
+static const struct resource mt6397_rtc_resources[] = {
+   {
+   .start = MT6397_RTC_BASE,
+   .end   = MT6397_RTC_BASE + MT6397_RTC_SIZE,
+   .flags  = IORESOURCE_MEM,
+   },
+   {
+   .start = MT6397_IRQ_RTC,
+   .end   = MT6397_IRQ_RTC,
+   .flags  = IORESOURCE_IRQ,
+   },
+};
+
 static const struct mfd_cell mt6397_devs[] = {
{
.name = "mt6397-rtc",
+   .num_resources = ARRAY_SIZE(mt6397_rtc_resources),
+   .resources = mt6397_rtc_resources,
.of_compatible = "mediatek,mt6397-rtc",
}, {
.name = "mt6397-regulator",
-- 
1.8.1.1.dirty

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH v3 3/3] MAINTAINERS: add Mediatek RTC driver

[Eddie Huang]

Add Mediatek RTC driver to maintainer entry.

Signed-off-by: Eddie Huang 
---
 MAINTAINERS | 7 +++
 1 file changed, 7 insertions(+)

diff --git a/MAINTAINERS b/MAINTAINERS
index 2e5bbc0..eb80610 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -1223,6 +1223,13 @@ W:   http://www.digriz.org.uk/ts78xx/kernel
 S: Maintained
 F: arch/arm/mach-orion5x/ts78xx-*
 
+ARM/Mediatek RTC DRIVER
+M: Eddie Huang 
+L: linux-arm-ker...@lists.infradead.org (moderated for non-subscribers)
+L: linux-media...@lists.infradead.org (moderated for non-subscribers)
+S: Maintained
+F: drivers/rtc/rtc-mt*
+
 ARM/Mediatek SoC support
 M: Matthias Brugger 
 L: linux-arm-ker...@lists.infradead.org (moderated for non-subscribers)
-- 
1.8.1.1.dirty

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH v3 2/3] rtc: mediatek: Add MT6397 RTC driver

[Eddie Huang]

From: Tianping Fang 

Add Mediatek MT6397 RTC driver

Signed-off-by: Tianping Fang 
Signed-off-by: Eddie Huang 
---
 drivers/rtc/Kconfig  |  10 ++
 drivers/rtc/Makefile |   1 +
 drivers/rtc/rtc-mt6397.c | 388 +++
 3 files changed, 399 insertions(+)
 create mode 100644 drivers/rtc/rtc-mt6397.c

diff --git a/drivers/rtc/Kconfig b/drivers/rtc/Kconfig
index 6149ae0..9608fcb 100644
--- a/drivers/rtc/Kconfig
+++ b/drivers/rtc/Kconfig
@@ -1520,6 +1520,16 @@ config RTC_DRV_MOXART
   This driver can also be built as a module. If so, the module
   will be called rtc-moxart
 
+config RTC_DRV_MT6397
+   tristate "Mediatek Real Time Clock driver"
+   depends on MFD_MT6397 || COMPILE_TEST
+   help
+ This selects the Mediatek(R) RTC driver. RTC is part of Mediatek
+ MT6397 PMIC. You should enable MT6397 PMIC MFD before select
+ Mediatek(R) RTC driver.
+
+ If you want to use Mediatek(R) RTC interface, select Y or M here.
+
 config RTC_DRV_XGENE
tristate "APM X-Gene RTC"
depends on HAS_IOMEM
diff --git a/drivers/rtc/Makefile b/drivers/rtc/Makefile
index c31731c..6ba0ce2 100644
--- a/drivers/rtc/Makefile
+++ b/drivers/rtc/Makefile
@@ -154,3 +154,4 @@ obj-$(CONFIG_RTC_DRV_X1205) += rtc-x1205.o
 obj-$(CONFIG_RTC_DRV_XGENE)+= rtc-xgene.o
 obj-$(CONFIG_RTC_DRV_SIRFSOC)  += rtc-sirfsoc.o
 obj-$(CONFIG_RTC_DRV_MOXART)   += rtc-moxart.o
+obj-$(CONFIG_RTC_DRV_MT6397)   += rtc-mt6397.o
diff --git a/drivers/rtc/rtc-mt6397.c b/drivers/rtc/rtc-mt6397.c
new file mode 100644
index 000..0d96d02
--- /dev/null
+++ b/drivers/rtc/rtc-mt6397.c
@@ -0,0 +1,388 @@
+/*
+* Copyright (c) 2014-2015 MediaTek Inc.
+* Author: Tianping.Fang 
+*
+* This program is free software; you can redistribute it and/or modify
+* it under the terms of the GNU General Public License version 2 as
+* published by the Free Software Foundation.
+*
+* This program is distributed in the hope that it will be useful,
+* but WITHOUT ANY WARRANTY; without even the implied warranty of
+* MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+* GNU General Public License for more details.
+*/
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#define RTC_BBPU   0x
+#define RTC_BBPU_CBUSY BIT(6)
+
+#define RTC_WRTGR  0x003c
+
+#define RTC_IRQ_STA0x0002
+#define RTC_IRQ_STA_AL BIT(0)
+#define RTC_IRQ_STA_LP BIT(3)
+
+#define RTC_IRQ_EN 0x0004
+#define RTC_IRQ_EN_AL  BIT(0)
+#define RTC_IRQ_EN_ONESHOT BIT(2)
+#define RTC_IRQ_EN_LP  BIT(3)
+#define RTC_IRQ_EN_ONESHOT_AL  (RTC_IRQ_EN_ONESHOT | RTC_IRQ_EN_AL)
+
+#define RTC_AL_MASK0x0008
+#define RTC_AL_MASK_DOWBIT(4)
+
+#define RTC_TC_SEC 0x000a
+/* Min, Hour, Dom... register offset to RTC_TC_SEC */
+#define RTC_OFFSET_SEC 0
+#define RTC_OFFSET_MIN 1
+#define RTC_OFFSET_HOUR2
+#define RTC_OFFSET_DOM 3
+#define RTC_OFFSET_DOW 4
+#define RTC_OFFSET_MTH 5
+#define RTC_OFFSET_YEAR6
+#define RTC_OFFSET_COUNT   7
+
+#define RTC_AL_SEC 0x0018
+
+#define RTC_PDN2   0x002e
+#define RTC_PDN2_PWRON_ALARM   BIT(4)
+
+#define RTC_MIN_YEAR   1968
+#define RTC_BASE_YEAR  1900
+#define RTC_NUM_YEARS  128
+#define RTC_MIN_YEAR_OFFSET(RTC_MIN_YEAR - RTC_BASE_YEAR)
+
+struct mt6397_rtc {
+   struct device   *dev;
+   struct rtc_device   *rtc_dev;
+   struct mutexlock;
+   struct regmap   *regmap;
+   int irq;
+   u32 addr_base;
+};
+
+static int mtk_rtc_write_trigger(struct mt6397_rtc *rtc)
+{
+   unsigned long timeout = jiffies + HZ;
+   int ret;
+   u32 data;
+
+   ret = regmap_write(rtc->regmap, rtc->addr_base + RTC_WRTGR, 1);
+   if (ret < 0)
+   return ret;
+
+   do {
+   cpu_relax();
+   ret = regmap_read(rtc->regmap, rtc->addr_base + RTC_BBPU,
+   );
+   if (ret < 0)
+   goto exit;
+   } while ((data & RTC_BBPU_CBUSY) && time_after(timeout, jiffies));
+
+exit:
+   return ret;
+}
+
+static irqreturn_t mtk_rtc_irq_handler_thread(int irq, void *data)
+{
+   struct mt6397_rtc *rtc = data;
+   u32 irqsta, irqen;
+   int ret;
+
+   ret = regmap_read(rtc->regmap, rtc->addr_base + RTC_IRQ_STA, );
+   if ((ret >= 0) && (irqsta & RTC_IRQ_STA_AL)) {
+   rtc_update_irq(rtc->rtc_dev, 1, RTC_IRQF | RTC_AF);
+   irqen = irqsta & ~RTC_IRQ_EN_AL;
+   mutex_lock(>lock);
+   if (regmap_write(rtc->regmap, rtc->addr_base + RTC_IRQ_EN,
+irqen) < 0)
+   

Re: [PATCH RFC v2 0/5] Multi-queue support for xen-blkfront and xen-blkback

[Christoph Hellwig]

What happened to this patchset?
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 5/6] toshiba_bluetooth: Change BT status message to debug

[Bjørn Mork]

Azael Avalos  writes:

> The function toshiba_bluetooth_status s currently printing the status
> of the device whenever it is queried, but since the introduction of
> the rfkill poll code, this value will get printed everytime the poll
> occurs.
>
> This patch changes the level of the printed message from info to
> debug, and also adds a few more debug messages printing the
> killswitch, plug and power status of the device as well.
>
> Signed-off-by: Azael Avalos 
> ---
>  drivers/platform/x86/toshiba_bluetooth.c | 6 +-
>  1 file changed, 5 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/platform/x86/toshiba_bluetooth.c 
> b/drivers/platform/x86/toshiba_bluetooth.c
> index 9867ccd..93b9688 100644
> --- a/drivers/platform/x86/toshiba_bluetooth.c
> +++ b/drivers/platform/x86/toshiba_bluetooth.c
> @@ -99,7 +99,7 @@ static int toshiba_bluetooth_status(acpi_handle handle)
>   return -ENXIO;
>   }
>  
> - pr_info("Bluetooth status %llu\n", status);
> + pr_debug("Bluetooth status %llu\n", status);
>  
>   return status;
>  }
> @@ -157,6 +157,10 @@ static int toshiba_bluetooth_sync_status(struct 
> toshiba_bluetooth_dev *bt_dev)
>   bt_dev->plugged = (status & BT_PLUGGED_MASK) ? true : false;
>   bt_dev->powered = (status & BT_POWER_MASK) ? true : false;
>  
> + pr_debug("killswitch %d\n", bt_dev->killswitch);
> + pr_debug("plugged %d\n", bt_dev->plugged);
> + pr_debug("powered %d\n", bt_dev->powered);


Those are terribly generic messages.  I don't think I would have guessed
which device was trying to tell me "powered 1" if I found it in the
logs...

How about using e.g dev_dbg() to get a bit more context here?

You might also want to put all three into a single call, so that they
make a single dynamic debug entry when dynamic debugging is enabled.

And looking at toshiba_bluetooth_status() I see that all callers have a
device. How about propagating the device to be able to use the dev_*
printk's there as well?  Let the device identify itself instead of
having to guess.


Bjørn
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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 5/5] GHES: Make NMI handler have a single reader

[Borislav Petkov]

On Tue, Apr 28, 2015 at 02:24:16AM +, Zheng, Lv wrote:
> > > #APP
> > > # 177 "./arch/x86/include/asm/atomic.h" 1
> > >   .pushsection .smp_locks,"a"
> > > .balign 4
> > > .long 671f - .
> > > .popsection
> > > 671:
> > >   lock; cmpxchgl %edx,ghes_in_nmi(%rip)   # D.37056, MEM[(volatile u32 
> > > *)_in_nmi]
> > > # 0 "" 2
> > > #NO_APP
> > >
> > > And you need to atomic_dec() so that another reader can enter, i.e. how
> > > the exclusion primitive works.
> > >
> > > Or did you have something else in mind?
> > 
> > My mistake.
> > I mean cmpxchg() and xchg() (or atomic_cmpxchg() and atomic_xchg()) pair 
> > here, so nothing can be reduced.
> 
> Let me correct, it should be atomic_cmpxchg() and atomic_set() here as you 
> only need to switch between 0 and 1.
> Sorry for the noise.

I still don't understand what you want from me here. You need to go into
more detail.

-- 
Regards/Gruss,
Boris.

ECO tip #101: Trim your mails when you reply.
--
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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 10/10] perf tools: Move TUI-specific fields out of map_symbol

[Namhyung Kim]

Hi Arnaldo,

On Mon, Apr 27, 2015 at 02:20:36PM -0300, Arnaldo Carvalho de Melo wrote:
> Em Wed, Apr 22, 2015 at 04:18:21PM +0900, Namhyung Kim escreveu:
> 
> > @@ -139,24 +139,19 @@ static char tree__folded_sign(bool unfolded)
> > return unfolded ? '-' : '+';
> >  }
> >  
> > -static char map_symbol__folded(const struct map_symbol *ms)
> > -{
> > -   return ms->has_children ? tree__folded_sign(ms->unfolded) : ' ';
> > -}
> > -
> 
> So what is wrong with renaming the above function to
> hist_entry__folded() instead of open coding it multiple times? Applied
> all the other patches, thanks,

Please see below..

The struct map_symbol__folded() was called from hist_entry__folded()
and callchain_list__folded().  I just removed map_symbol__folded()
since it does not contain the info anymore and open coded it just for
the two callers.  The real callers of these functions are not touched.

> 
> >  static char hist_entry__folded(const struct hist_entry *he)
> >  {
> > -   return map_symbol__folded(>ms);
> > +   return he->has_children ? tree__folded_sign(he->unfolded) : ' ';
> >  }
> >  
> >  static char callchain_list__folded(const struct callchain_list *cl)
> >  {
> > -   return map_symbol__folded(>ms);
> > +   return cl->has_children ? tree__folded_sign(cl->unfolded) : ' ';
> >  }

Here.

Thanks,
Namhyung


> >  
> > -static void map_symbol__set_folding(struct map_symbol *ms, bool unfold)
> > +static void callchain_list__set_folding(struct callchain_list *cl, bool 
> > unfold)
> >  {
> > -   ms->unfolded = unfold ? ms->has_children : false;
> > +   cl->unfolded = unfold ? cl->has_children : false;
> >  }
> >  
> >  static int callchain_node__count_rows_rb_tree(struct callchain_node *node)
> > @@ -192,7 +187,7 @@ static int callchain_node__count_rows(struct 
> > callchain_node *node)
> >  
> > list_for_each_entry(chain, >val, list) {
> > ++n;
> > -   unfolded = chain->ms.unfolded;
> > +   unfolded = chain->unfolded;
> > }
> >  
> > if (unfolded)
> > @@ -214,15 +209,15 @@ static int callchain__count_rows(struct rb_root 
> > *chain)
> > return n;
> >  }
> >  
> > -static bool map_symbol__toggle_fold(struct map_symbol *ms)
> > +static bool hist_entry__toggle_fold(struct hist_entry *he)
> >  {
> > -   if (!ms)
> > +   if (!he)
> > return false;
> >  
> > -   if (!ms->has_children)
> > +   if (!he->has_children)
> > return false;
> >  
> > -   ms->unfolded = !ms->unfolded;
> > +   he->unfolded = !he->unfolded;
> > return true;
> >  }
> >  
> > @@ -238,10 +233,10 @@ static void 
> > callchain_node__init_have_children_rb_tree(struct callchain_node *no
> > list_for_each_entry(chain, >val, list) {
> > if (first) {
> > first = false;
> > -   chain->ms.has_children = chain->list.next != 
> > >val ||
> > +   chain->has_children = chain->list.next != 
> > >val ||
> >  
> > !RB_EMPTY_ROOT(>rb_root);
> > } else
> > -   chain->ms.has_children = chain->list.next == 
> > >val &&
> > +   chain->has_children = chain->list.next == 
> > >val &&
> >  
> > !RB_EMPTY_ROOT(>rb_root);
> > }
> >  
> > @@ -255,11 +250,11 @@ static void callchain_node__init_have_children(struct 
> > callchain_node *node,
> > struct callchain_list *chain;
> >  
> > chain = list_entry(node->val.next, struct callchain_list, list);
> > -   chain->ms.has_children = has_sibling;
> > +   chain->has_children = has_sibling;
> >  
> > if (!list_empty(>val)) {
> > chain = list_entry(node->val.prev, struct callchain_list, list);
> > -   chain->ms.has_children = !RB_EMPTY_ROOT(>rb_root);
> > +   chain->has_children = !RB_EMPTY_ROOT(>rb_root);
> > }
> >  
> > callchain_node__init_have_children_rb_tree(node);
> > @@ -279,7 +274,7 @@ static void callchain__init_have_children(struct 
> > rb_root *root)
> >  static void hist_entry__init_have_children(struct hist_entry *he)
> >  {
> > if (!he->init_have_children) {
> > -   he->ms.has_children = !RB_EMPTY_ROOT(>sorted_chain);
> > +   he->has_children = !RB_EMPTY_ROOT(>sorted_chain);
> > callchain__init_have_children(>sorted_chain);
> > he->init_have_children = true;
> > }
> > @@ -287,14 +282,14 @@ static void hist_entry__init_have_children(struct 
> > hist_entry *he)
> >  
> >  static bool hist_browser__toggle_fold(struct hist_browser *browser)
> >  {
> > -   if (map_symbol__toggle_fold(browser->selection)) {
> > +   if (hist_entry__toggle_fold(browser->he_selection)) {
> > struct hist_entry *he = browser->he_selection;
> >  
> > hist_entry__init_have_children(he);
> > browser->b.nr_entries -= he->nr_rows;
> > 

Re: [PATCH 0/3] Introduce SET_NOIRQ_SYSTEM_SLEEP_PM_OPS and use it

[Ulf Hansson]

On 27 April 2015 at 20:24,   wrote:
> From: Grygorii Strashko 
>
> While working on suspend-to-disk functionality on TI dra7-evm (DRA7xx SoC)
> i've found that the most common problem I have to dial with is absence
> of corresponding PM callbacks in drivers and, in particular, noirq callbacks.
> So, I've fixed one driver first
> commit 6248015d6867 "ARM: omap-device: add missed callback for 
> suspend-to-disk"
> but then found another one which need to be fixed too (omap_l3_noc.c).
> At this moment I decided to make my life easier and added new macro
> SET_NOIRQ_SYSTEM_SLEEP_PM_OPS using the same approach as for the existing
> SET_SYSTEM_SLEEP_PM_OPS macro.
>
> SET_NOIRQ_SYSTEM_SLEEP_PM_OPS: defined for CONFIG_PM_SLEEP and
> assigns ->suspend_noirq, ->freeze_noirq and ->poweroff_noirq to the same
> function. Vice versa happens for ->resume_noirq, ->thaw_noirq and
> ->restore_noirq.
>
> Further two patches reuse this newly introduced macro.
>
> SET_NOIRQ_SYSTEM_SLEEP_PM_OPS, defined for CONFIG_PM_SLEEP, will
> point ->suspend_noirq, ->freeze_noirq and ->poweroff_noirq to the same
> function. Vice versa happens for ->resume_noirq, ->thaw_noirq and
> ->restore_noirq.
>
> Cc: Tony Lindgren 
> Cc: Nishanth Menon 
> Cc: Kevin Hilman 
> Cc: Santosh Shilimkar 
>
> Grygorii Strashko (3):
>   PM / Sleep: Add macro to define common noirq system PM callbacks
>   bus: omap_l3_noc: add missed callbacks for suspend-to-disk
>   ARM: omap-device: use SET_NOIRQ_SYSTEM_SLEEP_PM_OPS
>
>  arch/arm/mach-omap2/omap_device.c |  7 ++-
>  drivers/bus/omap_l3_noc.c |  4 ++--
>  include/linux/pm.h| 12 
>  3 files changed, 16 insertions(+), 7 deletions(-)
>
> --
> 1.9.1
>

For the patchset.

Reviewed-by: Ulf Hansson 

Kind regards
Uffe
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[RFC PATCH] iommu: add ARM short descriptor page table allocator.

[Yong Wu]

This patch is for ARM Short Descriptor Format.It has 2-levels
pagetable and the allocator supports 4K/64K/1M/16M.

Signed-off-by: Yong Wu 
---
 drivers/iommu/Kconfig|   7 +
 drivers/iommu/Makefile   |   1 +
 drivers/iommu/io-pgtable-arm-short.c | 489 +++
 drivers/iommu/io-pgtable.c   |   4 +
 drivers/iommu/io-pgtable.h   |   6 +
 5 files changed, 507 insertions(+)
 create mode 100644 drivers/iommu/io-pgtable-arm-short.c

diff --git a/drivers/iommu/Kconfig b/drivers/iommu/Kconfig
index baa0d97..8e50e73 100644
--- a/drivers/iommu/Kconfig
+++ b/drivers/iommu/Kconfig
@@ -38,6 +38,13 @@ config IOMMU_IO_PGTABLE_LPAE_SELFTEST
 
  If unsure, say N here.
 
+config IOMMU_IO_PGTABLE_SHORT
+   bool "ARMv7/v8 Short Descriptor Format"
+   select IOMMU_IO_PGTABLE
+   help
+ Enable support for the ARM Short descriptor pagetable format.
+ It has 2-levels pagetable and The allocator supports 4K/64K/1M/16M.
+
 endmenu
 
 config IOMMU_IOVA
diff --git a/drivers/iommu/Makefile b/drivers/iommu/Makefile
index 080ffab..815b3c8 100644
--- a/drivers/iommu/Makefile
+++ b/drivers/iommu/Makefile
@@ -3,6 +3,7 @@ obj-$(CONFIG_IOMMU_API) += iommu-traces.o
 obj-$(CONFIG_IOMMU_API) += iommu-sysfs.o
 obj-$(CONFIG_IOMMU_IO_PGTABLE) += io-pgtable.o
 obj-$(CONFIG_IOMMU_IO_PGTABLE_LPAE) += io-pgtable-arm.o
+obj-$(CONFIG_IOMMU_IO_PGTABLE_SHORT) += io-pgtable-arm-short.o
 obj-$(CONFIG_IOMMU_IOVA) += iova.o
 obj-$(CONFIG_OF_IOMMU) += of_iommu.o
 obj-$(CONFIG_MSM_IOMMU) += msm_iommu.o msm_iommu_dev.o
diff --git a/drivers/iommu/io-pgtable-arm-short.c 
b/drivers/iommu/io-pgtable-arm-short.c
new file mode 100644
index 000..8d723ec
--- /dev/null
+++ b/drivers/iommu/io-pgtable-arm-short.c
@@ -0,0 +1,489 @@
+/*
+ * Copyright (c) 2014-2015 MediaTek Inc.
+ * Author: Yong Wu 
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ */
+#define pr_fmt(fmt)"arm-short-desc io-pgtable: "fmt
+
+#include 
+#include 
+#include 
+#include 
+
+#include "io-pgtable.h"
+
+typedef u32 arm_short_iopte;
+
+struct arm_short_io_pgtable {
+   struct io_pgtable   iop;
+   struct kmem_cache   *ptekmem;
+   size_t  pgd_size;
+   void*pgd;
+};
+
+#define io_pgtable_short_to_data(x)\
+   container_of((x), struct arm_short_io_pgtable, iop)
+
+#define io_pgtable_ops_to_pgtable(x)   \
+   container_of((x), struct io_pgtable, ops)
+
+#define io_pgtable_short_ops_to_data(x)\
+   io_pgtable_short_to_data(io_pgtable_ops_to_pgtable(x))
+
+#define ARM_SHORT_MAX_ADDR_BITS32
+
+#define ARM_SHORT_PGDIR_SHIFT  20
+#define ARM_SHORT_PAGE_SHIFT   12
+#define ARM_SHORT_PTRS_PER_PTE 256
+#define ARM_SHORT_BYTES_PER_PTE1024
+
+/* 1 level pagetable */
+#define ARM_SHORT_F_PGD_TYPE_PAGE  (0x1)
+#define ARM_SHORT_F_PGD_TYPE_PAGE_MSK  (0x3)
+#define ARM_SHORT_F_PGD_TYPE_SECTION   (0x2)
+#define ARM_SHORT_F_PGD_TYPE_SUPERSECTION  (0x2 | (1 << 18))
+#define ARM_SHORT_F_PGD_TYPE_SECTION_MSK   (0x3 | (1 << 18))
+#define ARM_SHORT_F_PGD_TYPE_IS_PAGE(pgd)  (((pgd) & 0x3) == 1)
+#define ARM_SHORT_F_PGD_TYPE_IS_SECTION(pgd)   \
+   (((pgd) & ARM_SHORT_F_PGD_TYPE_SECTION_MSK) \
+   == ARM_SHORT_F_PGD_TYPE_SECTION)
+#define ARM_SHORT_F_PGD_TYPE_IS_SUPERSECTION(pgd)  \
+   (((pgd) & ARM_SHORT_F_PGD_TYPE_SECTION_MSK) \
+   == ARM_SHORT_F_PGD_TYPE_SUPERSECTION)
+
+#define ARM_SHORT_F_PGD_B_BIT  BIT(2)
+#define ARM_SHORT_F_PGD_C_BIT  BIT(3)
+#define ARM_SHORT_F_PGD_IMPLE_BIT  BIT(9)
+#define ARM_SHORT_F_PGD_S_BIT  BIT(16)
+#define ARM_SHORT_F_PGD_NG_BIT BIT(17)
+#define ARM_SHORT_F_PGD_NS_BIT_PAGEBIT(3)
+#define ARM_SHORT_F_PGD_NS_BIT_SECTION BIT(19)
+
+#define ARM_SHORT_F_PGD_PA_PAGETABLE_MSK   0xfc00
+#define ARM_SHORT_F_PGD_PA_SECTION_MSK 0xfff0
+#define ARM_SHORT_F_PGD_PA_SUPERSECTION_MSK0xff00
+
+/* 2 level pagetable */
+#define ARM_SHORT_F_PTE_TYPE_GET(val)  ((val) & 0x3)
+#define ARM_SHORT_F_PTE_TYPE_LARGE BIT(0)
+#define ARM_SHORT_F_PTE_TYPE_SMALL BIT(1)
+#define ARM_SHORT_F_PTE_B_BIT  BIT(2)
+#define ARM_SHORT_F_PTE_C_BIT  BIT(3)
+#define ARM_SHORT_F_PTE_IMPLE_BIT  

Re: [PATCH v4] extcon-axp288: Add axp288 extcon driver support

[Paul Bolle]

Only a license nit.

On Tue, 2015-04-28 at 04:02 +0530, Ramakrishna Pallala wrote:
> --- /dev/null
> +++ b/drivers/extcon/extcon-axp288.c

> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License as published by
> + * the Free Software Foundation; either version 2 of the License, or
> + * (at your option) any later version.
> + *
> + * This program is distributed in the hope that it will be useful,
> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
> + * GNU General Public License for more details.

This states the license is GPL v2 or later.

> +MODULE_LICENSE("GPL v2");

And, according to include/linux/module.h, this states the license is
(just) GPL v2. So I think that either the comment at the top of this
file or the ident used in the MODULE_LICENSE() macro should be changed.

Thanks,


Paul Bolle

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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 01/13] thermal: Make temperatures consistently unsigned long

[Sascha Hauer]

On Mon, Apr 27, 2015 at 10:36:08PM +0200, Pavel Machek wrote:
> On Thu 2015-03-26 16:53:48, Sascha Hauer wrote:
> > The thermal framework uses int, long and unsigned long for temperatures
> > in millicelsius. The majority of functions uses unsigned long, so change
> > the remaining functions to use this type aswell.
> 
> Maybe millicelsius_t should be introduced, so that readers immediately know
> what type it is? Some parts of kernel also use decicelsius and decikelvin, 
> IIRC (ACPI).

I have no strong opinion on this. I'll send out the next version without
typedef for now. Since in my patch I identified most places which need a
type change anyway it might be a good opportunity to change to a typedef
if we want to. Any other opinions on this?

> 
>   Pavel
> 
> > if (trip_type == THERMAL_TRIP_CRITICAL) {
> > dev_emerg(>device,
> > - "critical temperature reached(%d C),shutting down\n",
> > + "critical temperature reached(%lu C),shutting down\n",
> 
> space after , ?

Turns out that in the new version of this series I don't have to modify
this line anymore. Made this a separate patch.

Sascha

-- 
Pengutronix e.K.   | |
Industrial Linux Solutions | http://www.pengutronix.de/  |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0|
Amtsgericht Hildesheim, HRA 2686   | Fax:   +49-5121-206917- |
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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 3/3] mm: support active anti-fragmentation algorithm

[Joonsoo Kim]

On Mon, Apr 27, 2015 at 09:29:23AM +0100, Mel Gorman wrote:
> On Mon, Apr 27, 2015 at 04:23:41PM +0900, Joonsoo Kim wrote:
> > We already have antifragmentation policy in page allocator. It works well
> > when system memory is sufficient, but, it doesn't works well when system
> > memory isn't sufficient because memory is already highly fragmented and
> > fallback/steal mechanism cannot get whole pageblock. If there is severe
> > unmovable allocation requestor like zram, problem could get worse.
> > 
> > CPU: 8
> > RAM: 512 MB with zram swap
> > WORKLOAD: kernel build with -j12
> > OPTION: page owner is enabled to measure fragmentation
> > After finishing the build, check fragmentation by 'cat /proc/pagetypeinfo'
> > 
> > * Before
> > Number of blocks type (movable)
> > DMA32: 207
> > 
> > Number of mixed blocks (movable)
> > DMA32: 111.2
> > 
> > Mixed blocks means that there is one or more allocated page for
> > unmovable/reclaimable allocation in movable pageblock. Results shows that
> > more than half of movable pageblock is tainted by other migratetype
> > allocation.
> > 
> > To mitigate this fragmentation, this patch implements active
> > anti-fragmentation algorithm. Idea is really simple. When some
> > unmovable/reclaimable steal happens from movable pageblock, we try to
> > migrate out other pages that can be migratable in this pageblock are and
> > use these generated freepage for further allocation request of
> > corresponding migratetype.
> > 
> > Once unmovable allocation taints movable pageblock, it cannot easily
> > recover. Instead of praying that it gets restored, making it unmovable
> > pageblock as much as possible and using it further unmovable request
> > would be more reasonable approach.
> > 
> > Below is result of this idea.
> > 
> > * After
> > Number of blocks type (movable)
> > DMA32: 208.2
> > 
> > Number of mixed blocks (movable)
> > DMA32: 55.8
> > 
> > Result shows that non-mixed block increase by 59% in this case.
> > 
> > Signed-off-by: Joonsoo Kim 
> 
> I haven't read the patch in detail but there were a few reasons why
> active avoidance was not implemented originally.

Thanks for really good comment. I can understand why it is in current
form from your comment and what I should consider.

> 
> 1. If pages in the target block were reclaimed then it potentially
>increased stall latency in the future when they had to be refaulted
>again. A prototype that used lumpy reclaim originally suffered extreme
>stalls and was ultimately abandoned. The alternative at the time was
>to increase min_free_kbytes by default as it had a similar effect with
>much less disruption

Reclaim is not used by this patchset.

> 2. If the pages in the target block were migrated then there was
>compaction overhead with no guarantee of success. Again, there were
>concerns about stalls. This was not deferred to an external thread
>because if the fragmenting process did not stall then it could simply
>cause more fragmentation-related damage while the thread executes. It

Yes, this patch uses migration for active fragmentation avoidance.
But, I'm not sure why external thread approach could simply cause more
fragmentation-related damage. It cannot possibly follow-up allocation
speed of fragmenting process, but, even in this case, fragmentation
would be lower compared to do nothing approach.

>becomes very unpredictable. While migration is in progress, processes
>also potentially stall if they reference the targetted pages.

I should admit that if processes reference the targetted pages, they
would stall and there is compaction overhead with no guarantee of
success. But, this fragmentation avoidance is really needed for low
memory system, because, in that system, fragmentation could be really high
so even order 2 allocation suffers from fragmentation. File pages are
excessively reclaimed to make order 2 page. I think that this reclaim
overhead is worse than above overhead causing by this fragmentation
avoidance algorithm.

> 3. Further on 2, the migration itself potentially triggers more fallback
>events while pages are isolated for the migration.
> 
> 4. Migrating pages to another node is a bad idea. It requires a NUMA
>machine at the very least but more importantly it could violate memory
>policies. If the page was mapped then the VMA could be checked but if the
>pages were unmapped then the kernel potentially violates memory policies

I agree. Migrating pages to another node is not intended behaviour.
I will fix it.

> At the time it was implemented, fragmentation avoidance was primarily
> concerned about allocating hugetlbfs pages and later THP. Failing either
> was not a functional failure that users would care about but large stalls
> due to active fragmentation avoidance would disrupt workloads badly.

I see. But, my attempt of this patchset is kind of functional failure.
If unmovable pages are mixed to movable pages in movable pageblock,

Re: [PATCH v3 1/3] mfd: provide RTC resource in MT6397 MFD

[Uwe Kleine-König]

Hello,

On Tue, Apr 28, 2015 at 03:35:54PM +0800, Eddie Huang wrote:
> Provide MT6397 RTC interrupt, base address, and register in
> MT6397 MFD.
> 
> Signed-off-by: Eddie Huang 
> ---
>  drivers/mfd/mt6397-core.c | 18 ++
>  1 file changed, 18 insertions(+)
> 
> diff --git a/drivers/mfd/mt6397-core.c b/drivers/mfd/mt6397-core.c
> index 09bc780..08cfbd1 100644
> --- a/drivers/mfd/mt6397-core.c
> +++ b/drivers/mfd/mt6397-core.c
> @@ -21,9 +21,27 @@
>  #include 
>  #include 
>  
> +#define MT6397_RTC_BASE  0xe000
> +#define MT6397_RTC_SIZE  0x3e
> +
> +static const struct resource mt6397_rtc_resources[] = {
> + {
> + .start = MT6397_RTC_BASE,
> + .end   = MT6397_RTC_BASE + MT6397_RTC_SIZE,
> + .flags  = IORESOURCE_MEM,
It's definitly a matter of taste if you align the rhs here, but if you
do, do it consitently. That is, either make sure that all equal signs
are in a single column (at least per struct resource), or use a single
space between variable name and =.

If you want to hear my personal preference: I always use a single space.
As if you have to add
.somelongvariablename = somevalue

you have to touch all other lines, too, which is ugly.

Best regards
Uwe

-- 
Pengutronix e.K.   | Uwe Kleine-König|
Industrial Linux Solutions | http://www.pengutronix.de/  |
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH RFC v2 0/5] Multi-queue support for xen-blkfront and xen-blkback

[Arianna Avanzini]

Hello Christoph,

Il 28/04/2015 09:36, Christoph Hellwig ha scritto:

What happened to this patchset?



It was passed on to Bob Liu, who published a follow-up patchset here: 
https://lkml.org/lkml/2015/2/15/46


Thanks,
Arianna

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] usb: gadget: composite: enable BESL support

[Du, Changbin]

>From a6615937bcd9234e6d6bb817c3701fce44d0a84d Mon Sep 17 00:00:00 2001
From: Felipe Balbi 
Date: Tue, 30 Sep 2014 16:08:03 -0500
Subject: [PATCH] usb: gadget: composite: enable BESL support

According to USB 2.0 ECN Errata for Link Power
Management (USB2-LPM-Errata-final.pdf), BESL
must be enabled if LPM is enabled.

This helps with USB30CV TD 9.21 LPM L1
Suspend Resume Test.

Cc:  # 3.14
Signed-off-by: Felipe Balbi 
Signed-off-by: Du, Changbin 
---
Hi,

This patch was introduced on v3.18. However the issue fixed already existed on
v3.14 and v3.14 is a long term support version.

So propose to backport it over there as well.

Du, Changbin
---
 drivers/usb/gadget/composite.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/usb/gadget/composite.c b/drivers/usb/gadget/composite.c
index a8c18df..f6a51fd 100644
--- a/drivers/usb/gadget/composite.c
+++ b/drivers/usb/gadget/composite.c
@@ -560,7 +560,7 @@ static int bos_desc(struct usb_composite_dev *cdev)
usb_ext->bLength = USB_DT_USB_EXT_CAP_SIZE;
usb_ext->bDescriptorType = USB_DT_DEVICE_CAPABILITY;
usb_ext->bDevCapabilityType = USB_CAP_TYPE_EXT;
-   usb_ext->bmAttributes = cpu_to_le32(USB_LPM_SUPPORT);
+   usb_ext->bmAttributes = cpu_to_le32(USB_LPM_SUPPORT | USB_BESL_SUPPORT);
 
/*
 * The Superspeed USB Capability descriptor shall be implemented by all
-- 
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 v4] extcon-axp288: Add axp288 extcon driver support

[Pallala, Ramakrishna]

> 
> Only a license nit.
> 
> On Tue, 2015-04-28 at 04:02 +0530, Ramakrishna Pallala wrote:
> > --- /dev/null
> > +++ b/drivers/extcon/extcon-axp288.c
> 
> > + * This program is free software; you can redistribute it and/or
> > + modify
> > + * it under the terms of the GNU General Public License as published
> > + by
> > + * the Free Software Foundation; either version 2 of the License, or
> > + * (at your option) any later version.
> > + *
> > + * This program is distributed in the hope that it will be useful,
> > + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> > + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
> > + * GNU General Public License for more details.
> 
> This states the license is GPL v2 or later.
> 
> > +MODULE_LICENSE("GPL v2");
> 
> And, according to include/linux/module.h, this states the license is
> (just) GPL v2. So I think that either the comment at the top of this file or 
> the
> ident used in the MODULE_LICENSE() macro should be changed.

Ok I will fix it.

Thanks,
Ram
N�r��yb�X��ǧv�^�)޺{.n�+{zX����ܨ}���Ơz�:+v���zZ+��+zf���h���~i���z��w���?�&�)ߢf��^jǫy�m��@A�a���
0��h���i

Re: [PATCH v9 13/17] h8300: configs

[Yoshinori Sato]

At Mon, 27 Apr 2015 20:27:21 -0700,
Guenter Roeck wrote:
> 
> On Mon, Apr 27, 2015 at 02:35:20PM +0900, Yoshinori Sato wrote:
> > h8300h-sim_defconfig: H8/300H simulator config.
> > h8s-sim_defconfig:H8S simulator config.
> > edosk2674_defconfig:  EDOSK2674R evalution board config.
> 
> Did that get lost ?
> 
> Guenter

Oh, Sorry.
It my mistake.

I will added next.

> > 
> > Signed-off-by: Yoshinori Sato 
> > ---
> >  arch/h8300/configs/h8300h-sim_defconfig | 53 
> > +
> >  arch/h8300/configs/h8s-sim_defconfig| 53 
> > +
> >  2 files changed, 106 insertions(+)
> >  create mode 100644 arch/h8300/configs/h8300h-sim_defconfig
> >  create mode 100644 arch/h8300/configs/h8s-sim_defconfig
> > 
> > diff --git a/arch/h8300/configs/h8300h-sim_defconfig 
> > b/arch/h8300/configs/h8300h-sim_defconfig
> > new file mode 100644
> > index 000..bad1a1e
> > --- /dev/null
> > +++ b/arch/h8300/configs/h8300h-sim_defconfig
> > @@ -0,0 +1,53 @@
> > +# CONFIG_LOCALVERSION_AUTO is not set
> > +# CONFIG_USELIB is not set
> > +# CONFIG_INIT_FALLBACK is not set
> > +CONFIG_CC_OPTIMIZE_FOR_SIZE=y
> > +# CONFIG_UID16 is not set
> > +# CONFIG_SYSFS_SYSCALL is not set
> > +# CONFIG_KALLSYMS is not set
> > +# CONFIG_BASE_FULL is not set
> > +# CONFIG_FUTEX is not set
> > +# CONFIG_EPOLL is not set
> > +# CONFIG_SIGNALFD is not set
> > +# CONFIG_TIMERFD is not set
> > +# CONFIG_EVENTFD is not set
> > +# CONFIG_AIO is not set
> > +# CONFIG_ADVISE_SYSCALLS is not set
> > +CONFIG_EMBEDDED=y
> > +# CONFIG_VM_EVENT_COUNTERS is not set
> > +# CONFIG_COMPAT_BRK is not set
> > +CONFIG_SLOB=y
> > +# CONFIG_BLOCK is not set
> > +CONFIG_H8300H_SIM=y
> > +CONFIG_CPU_CLOCK=2000
> > +CONFIG_RAMSIZE=0x20
> > +# CONFIG_BINFMT_SCRIPT is not set
> > +CONFIG_BINFMT_FLAT=y
> > +# CONFIG_COREDUMP is not set
> > +# CONFIG_UEVENT_HELPER is not set
> > +# CONFIG_STANDALONE is not set
> > +# CONFIG_PREVENT_FIRMWARE_BUILD is not set
> > +# CONFIG_FW_LOADER is not set
> > +# CONFIG_ALLOW_DEV_COREDUMP is not set
> > +# CONFIG_INPUT is not set
> > +# CONFIG_SERIO is not set
> > +# CONFIG_VT is not set
> > +# CONFIG_UNIX98_PTYS is not set
> > +# CONFIG_LEGACY_PTYS is not set
> > +# CONFIG_DEVKMEM is not set
> > +CONFIG_SERIAL_SH_SCI=y
> > +CONFIG_SERIAL_SH_SCI_CONSOLE=y
> > +# CONFIG_HW_RANDOM is not set
> > +# CONFIG_HWMON is not set
> > +# CONFIG_USB_SUPPORT is not set
> > +# CONFIG_IOMMU_SUPPORT is not set
> > +# CONFIG_FILE_LOCKING is not set
> > +# CONFIG_DNOTIFY is not set
> > +# CONFIG_INOTIFY_USER is not set
> > +# CONFIG_PROC_FS is not set
> > +# CONFIG_SYSFS is not set
> > +# CONFIG_MISC_FILESYSTEMS is not set
> > +CONFIG_DEBUG_INFO=y
> > +# CONFIG_ENABLE_WARN_DEPRECATED is not set
> > +# CONFIG_ENABLE_MUST_CHECK is not set
> > +# CONFIG_CRC32 is not set
> > diff --git a/arch/h8300/configs/h8s-sim_defconfig 
> > b/arch/h8300/configs/h8s-sim_defconfig
> > new file mode 100644
> > index 000..025cdd8
> > --- /dev/null
> > +++ b/arch/h8300/configs/h8s-sim_defconfig
> > @@ -0,0 +1,53 @@
> > +# CONFIG_LOCALVERSION_AUTO is not set
> > +# CONFIG_USELIB is not set
> > +# CONFIG_INIT_FALLBACK is not set
> > +CONFIG_CC_OPTIMIZE_FOR_SIZE=y
> > +# CONFIG_UID16 is not set
> > +# CONFIG_SYSFS_SYSCALL is not set
> > +# CONFIG_KALLSYMS is not set
> > +# CONFIG_BASE_FULL is not set
> > +# CONFIG_FUTEX is not set
> > +# CONFIG_EPOLL is not set
> > +# CONFIG_SIGNALFD is not set
> > +# CONFIG_TIMERFD is not set
> > +# CONFIG_EVENTFD is not set
> > +# CONFIG_AIO is not set
> > +# CONFIG_ADVISE_SYSCALLS is not set
> > +CONFIG_EMBEDDED=y
> > +# CONFIG_VM_EVENT_COUNTERS is not set
> > +# CONFIG_COMPAT_BRK is not set
> > +CONFIG_SLOB=y
> > +# CONFIG_BLOCK is not set
> > +CONFIG_H8S_SIM=y
> > +CONFIG_CPU_CLOCK=
> > +CONFIG_RAMSIZE=0x20
> > +# CONFIG_BINFMT_SCRIPT is not set
> > +CONFIG_BINFMT_FLAT=y
> > +# CONFIG_COREDUMP is not set
> > +# CONFIG_UEVENT_HELPER is not set
> > +# CONFIG_STANDALONE is not set
> > +# CONFIG_PREVENT_FIRMWARE_BUILD is not set
> > +# CONFIG_FW_LOADER is not set
> > +# CONFIG_ALLOW_DEV_COREDUMP is not set
> > +# CONFIG_INPUT is not set
> > +# CONFIG_SERIO is not set
> > +# CONFIG_VT is not set
> > +# CONFIG_UNIX98_PTYS is not set
> > +# CONFIG_LEGACY_PTYS is not set
> > +# CONFIG_DEVKMEM is not set
> > +CONFIG_SERIAL_SH_SCI=y
> > +CONFIG_SERIAL_SH_SCI_CONSOLE=y
> > +# CONFIG_HW_RANDOM is not set
> > +# CONFIG_HWMON is not set
> > +# CONFIG_USB_SUPPORT is not set
> > +# CONFIG_IOMMU_SUPPORT is not set
> > +# CONFIG_FILE_LOCKING is not set
> > +# CONFIG_DNOTIFY is not set
> > +# CONFIG_INOTIFY_USER is not set
> > +# CONFIG_PROC_FS is not set
> > +# CONFIG_SYSFS is not set
> > +# CONFIG_MISC_FILESYSTEMS is not set
> > +CONFIG_DEBUG_INFO=y
> > +# CONFIG_ENABLE_WARN_DEPRECATED is not set
> > +# CONFIG_ENABLE_MUST_CHECK is not set
> > +# CONFIG_CRC32 is not set
> > -- 
> > 2.1.4
> > 
> > --
> > To unsubscribe from this list: send the line "unsubscribe linux-kernel" 

[PATCH v5] extcon-axp288: Add axp288 extcon driver support

[Ramakrishna Pallala]

This patch adds the extcon support for AXP288 PMIC which
has the BC1.2 charger detection capability. Additionally
it also adds the USB mux switching support b/w SOC and PMIC
based on GPIO control.

Signed-off-by: Ramakrishna Pallala 
---
 drivers/extcon/Kconfig |7 +
 drivers/extcon/Makefile|1 +
 drivers/extcon/extcon-axp288.c |  399 
 include/linux/mfd/axp20x.h |9 +
 4 files changed, 416 insertions(+)
 create mode 100644 drivers/extcon/extcon-axp288.c

diff --git a/drivers/extcon/Kconfig b/drivers/extcon/Kconfig
index fdc0bf0..2305edc 100644
--- a/drivers/extcon/Kconfig
+++ b/drivers/extcon/Kconfig
@@ -28,6 +28,13 @@ config EXTCON_ARIZONA
  with Wolfson Arizona devices. These are audio CODECs with
  advanced audio accessory detection support.
 
+config EXTCON_AXP288
+   tristate "X-Power AXP288 EXTCON support"
+   depends on MFD_AXP20X && USB_PHY
+   help
+ Say Y here to enable support for USB peripheral detection
+ and USB MUX switching by X-Power AXP288 PMIC.
+
 config EXTCON_GPIO
tristate "GPIO extcon support"
depends on GPIOLIB
diff --git a/drivers/extcon/Makefile b/drivers/extcon/Makefile
index 9204114..ba787d0 100644
--- a/drivers/extcon/Makefile
+++ b/drivers/extcon/Makefile
@@ -5,6 +5,7 @@
 obj-$(CONFIG_EXTCON)   += extcon.o
 obj-$(CONFIG_EXTCON_ADC_JACK)  += extcon-adc-jack.o
 obj-$(CONFIG_EXTCON_ARIZONA)   += extcon-arizona.o
+obj-$(CONFIG_EXTCON_AXP288)+= extcon-axp288.o
 obj-$(CONFIG_EXTCON_GPIO)  += extcon-gpio.o
 obj-$(CONFIG_EXTCON_MAX14577)  += extcon-max14577.o
 obj-$(CONFIG_EXTCON_MAX77693)  += extcon-max77693.o
diff --git a/drivers/extcon/extcon-axp288.c b/drivers/extcon/extcon-axp288.c
new file mode 100644
index 000..91d764c
--- /dev/null
+++ b/drivers/extcon/extcon-axp288.c
@@ -0,0 +1,399 @@
+/*
+ * extcon-axp288.c - X-Power AXP288 PMIC extcon cable detection driver
+ *
+ * Copyright (C) 2014 Intel Corporation
+ * Author: Ramakrishna Pallala 
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+/* Power source status register */
+#define PS_STAT_VBUS_TRIGGER   BIT(0)
+#define PS_STAT_BAT_CHRG_DIR   BIT(2)
+#define PS_STAT_VBUS_ABOVE_VHOLD   BIT(3)
+#define PS_STAT_VBUS_VALID BIT(4)
+#define PS_STAT_VBUS_PRESENT   BIT(5)
+
+/* BC module global register */
+#define BC_GLOBAL_RUN  BIT(0)
+#define BC_GLOBAL_DET_STAT BIT(2)
+#define BC_GLOBAL_DBP_TOUT BIT(3)
+#define BC_GLOBAL_VLGC_COM_SEL BIT(4)
+#define BC_GLOBAL_DCD_TOUT_MASK(BIT(6)|BIT(5))
+#define BC_GLOBAL_DCD_TOUT_300MS   0
+#define BC_GLOBAL_DCD_TOUT_100MS   1
+#define BC_GLOBAL_DCD_TOUT_500MS   2
+#define BC_GLOBAL_DCD_TOUT_900MS   3
+#define BC_GLOBAL_DCD_DET_SEL  BIT(7)
+
+/* BC module vbus control and status register */
+#define VBUS_CNTL_DPDM_PD_EN   BIT(4)
+#define VBUS_CNTL_DPDM_FD_EN   BIT(5)
+#define VBUS_CNTL_FIRST_PO_STATBIT(6)
+
+/* BC USB status register */
+#define USB_STAT_BUS_STAT_MASK (BIT(3)|BIT(2)|BIT(1)|BIT(0))
+#define USB_STAT_BUS_STAT_SHIFT0
+#define USB_STAT_BUS_STAT_ATHD 0
+#define USB_STAT_BUS_STAT_CONN 1
+#define USB_STAT_BUS_STAT_SUSP 2
+#define USB_STAT_BUS_STAT_CONF 3
+#define USB_STAT_USB_SS_MODE   BIT(4)
+#define USB_STAT_DEAD_BAT_DET  BIT(6)
+#define USB_STAT_DBP_UNCFG BIT(7)
+
+/* BC detect status register */
+#define DET_STAT_MASK  (BIT(7)|BIT(6)|BIT(5))
+#define DET_STAT_SHIFT 5
+#define DET_STAT_SDP   1
+#define DET_STAT_CDP   2
+#define DET_STAT_DCP   3
+
+/* IRQ enable-1 register */
+#define PWRSRC_IRQ_CFG_MASK(BIT(4)|BIT(3)|BIT(2))
+
+/* IRQ enable-6 register */
+#define BC12_IRQ_CFG_MASK  BIT(1)
+
+enum axp288_extcon_reg {
+   AXP288_PS_STAT_REG  = 0x00,
+   AXP288_PS_BOOT_REASON_REG   = 0x02,
+   AXP288_BC_GLOBAL_REG= 0x2c,
+   AXP288_BC_VBUS_CNTL_REG = 0x2d,
+   AXP288_BC_USB_STAT_REG  = 0x2e,
+   AXP288_BC_DET_STAT_REG  = 0x2f,
+   AXP288_PWRSRC_IRQ_CFG_REG   = 0x40,
+   AXP288_BC12_IRQ_CFG_REG = 0x45,
+};
+
+enum axp288_mux_select {
+   

Re: [PATCH 1/2] firmware: dmi_scan: Simplified displayed version

[Jean Delvare]

Hi Ivan,

On Mon, 27 Apr 2015 19:10:05 +0300, subscivan wrote:
> On 21.04.15 15:45, Jean Delvare wrote:
> > The trailing .x adds no information for the reader, and if anyone
> > tries to parse that line, this is more work as they have 3 different
> > formats to handle instead of 2. Plus, this makes backporting fixes
> > harder.
> >
> > Signed-off-by: Jean Delvare 
> > Fixes: 95be58df74a5 ("firmware: dmi_scan: Use full dmi version for SMBIOS3")
> > Cc: Ivan Khoronzhuk 
> > ---
> > It doesn't actually "fix" the mentioned commit, as there is no bug, but
> > if anyone backports dmi-related commits, picking this one will make
> > his/her life easier.
> >
> >   drivers/firmware/dmi_scan.c |5 ++---
> >   1 file changed, 2 insertions(+), 3 deletions(-)
> >
> > --- linux-4.0.orig/drivers/firmware/dmi_scan.c  2015-04-17 
> > 10:35:56.959512401 +0200
> > +++ linux-4.0/drivers/firmware/dmi_scan.c   2015-04-17 10:38:02.090156803 
> > +0200
> > @@ -506,9 +506,8 @@ static int __init dmi_present(const u8 *
> > if (dmi_walk_early(dmi_decode) == 0) {
> > if (smbios_ver) {
> > dmi_ver = smbios_ver;
> > -   pr_info("SMBIOS %d.%d%s present.\n",
> > -   dmi_ver >> 8, dmi_ver & 0xFF,
> > -   (dmi_ver < 0x0300) ? "" : ".x");
> > +   pr_info("SMBIOS %d.%d present.\n",
> > +  dmi_ver >> 8, dmi_ver & 0xFF);
> > } else {
> > dmi_ver = (buf[14] & 0xF0) << 4 |
> >(buf[14] & 0x0F);
> >
> >
> 
> The main idea here was that dmi version after 3 is in format x.x.x
> And after v3 it's expected to see such format. But in case if (I hope that
> will never happen) firmware has 32 bit version of SMBIOS3 the table doesn't

Oh, it will happen. Given that the v3 entry point format is
incompatible with the v2 entry point format, I expect (at least x86)
vendors to provide both whenever possible for several years to come, for
compatibility reasons. Our code scanning the memory for SMBIOS entry
points will pick the first one it finds (both in the kernel and in
dmidecode). I hope that vendors will be smart enough to place the v3
entry point first, but I expect to be disappointed by some.

> have fields to hold revision number, that's why, to warn user about trimming
> of revision the .x was added. IMHO the 3.2.x is more informative then 3.2
> 3.2 can be wrongly interpreted as 3.2.0. If script (or else) needs to see
> version in usual way, it can parse tables recently exposed.

I don't think so. 3.2.x and 3.2 mean exactly the same, none if more
informative than the other. For example if I say "openSUSE 13.2 is
based on kernel 3.16", that doesn't mean exactly kernel version 3.16.0.
Same here.

> But if you insist on 3.2, maybe it be good to warn user in some way like
> printing pr_info("SMBIOS doc revision cannot be accessible");

That would be replacing a bit of over-engineering with another. No,
thanks.

The doc revision number has been omitted so far because the
specification made no room to carry it. People and tools are used to
that. And to be honest I'm surprised they added it in v3. The revision
number is not so interesting IMHO, I never missed it in dmidecode.
Thankfully the additions to the specification are incremental and
almost always backward compatible so we seldom need to make decoding
decisions based on the version. Whenever a significant change happens,
at least the minor version number should be incremented. Bumps of the
doc revision should only translate to new enumerated values and maybe
new fields, all of which can be implemented unconditionally.

I suspect that they added a field for the doc revision number in the v3
entry point simply to avoid a mistake that has happened a couple times
in the past where vendors would attempt to encode the minor version
_and_ the doc revision in the minor version byte. When the SMBIOS 2.3.1
specification was released, a number of vendors encoded the version as
2.31 instead of 2.3. This was the first time the doc revision number
was used AFAIK and apparently some vendors failed to understand how to
handle it. Maybe the DMTF took note back then that, if the entry point
format ever changed, they should include a separate field for the doc
revision number to clear the confusion.

But what I do expect now is the opposite: the doc revision number
doesn't really matter, so I wouldn't be surprised if in the future some
vendors don't set it or forget to bump it on BIOS update. So we can
report it where available but I don't plan to make any use of it.

Anyway, my point here is: let's keep things simple and just report what
is encoded in the entry point. If it's a v3 entry point, the doc
revision is there, print it; if it's a v2 entry point, it's not, don't
print it. Easy as that.

-- 
Jean Delvare
SUSE L3 Support

Re: [PATCH] kconfig: add tinfo library if it exists to lxdialog linking flags

[Paul Bolle]

On Mon, 2015-04-27 at 12:00 +, sylvain.bertr...@gmail.com wrote:
> The pkg-config file I use is straight from the ncurses distribution with the
> lastest "rollup" patch.
> 
> Either it's a fedora specific modification, either a genuine ncurses patch
> released after the lastest "rollup" patch.

(If I read ftp://invisible-island.net/ncurses/5.9/README correctly, a
rollup is the patch that should be applied on top of the latest ncurses
release in order to get a development snapshot.)

What version of ncurses are you actually using?

> As far I understand it, from an application point of view, "standard" ncurses
> programming, in the case where tinfo lib is outside of ncurses lib, involves
> linking to libncurses library only. libtinfo linking would be required only in
> some special features are used, which seems to be the case with lxdialog.

On my Fedora 20 box linking to libtinfo is only necessary if you're
linking an application that's using libncurses statically.

> Please correct me if I'm wrong.

I have no idea.

Perhaps - and I'm speculating here - some features got moved from
ncurses(w) to tinfo. Anyhow, over here linking to tinfo is unneeded but
doesn't break mconf as far as I noticed. But, personally, I'd like to
know what triggered the issue you ran into before considering this
patch.


Paul Bolle

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] cpufreq: powernv: Register for OCC related opal_message notification

[Shilpasri G Bhat]

Hi Viresh,

On 04/28/2015 12:18 PM, Viresh Kumar wrote:
> On 28 April 2015 at 11:53, Shilpasri G Bhat
>  wrote:
> 
>> Changes from v1:
>> - Add macros to define OCC_RESET, OCC_LOAD and OCC_THROTTLE
>> - Define a structure to store chip id, chip mask which has bits set
>>   for cpus present in the chip, throttled state and a work_struct.
>> - Modify powernv_cpufreq_throttle_check() to be called via smp_call()
> 
> Why ? I might have missed it but there should be some reasoning behind
> what you are changing.

My bad I haven't added explicit comment to state reason behind this change.

I modified the definition of *throttle_check() to match the function definition
to be called via smp_call() instead of adding an additional wrapper around
*throttle_check().

OCC is a chip entity and any local throttle state changes should be associated
to cpus belonging to that chip. The *throttle_check() will read the core
register PMSR to verify throttling. All the cores in a chip will have the same
throttled state as they are managed by a the same OCC in that chip.

smp_call() is required to ensure *throttle_check() is called on a cpu belonging
to the chip for which we have received throttled/unthrottled notification. We
could be handling throttled/unthrottled notification of 'chip1' in 'chip2' so do
an smp_call() on 'chip1'.

We are irq_disabled in powernv_cpufreq_occ_msg() the notification handler.
Thus the use of kworker to do an smp_call and restore policy->cur.

OCC_RESET is global event it affects frequency of all chips. Pmax capping is
local event, it affects the frequency of a chip.

> 
>> - On Pmax throttling/unthrottling update 'chip.throttled' and not the
>>   global 'throttled' as Pmax capping is local to the chip.
>> - Remove the condition which checks if local pstate is less than Pmin
>>   while checking for Psafe frequency. When OCC becomes active after
>>   reset we update 'thottled' to false and when the cpufreq governor
>>   initiates a pstate change, the local pstate will be in Psafe and we
>>   will be reporting a false positive when we are not throttled.
>> - Schedule a kworker on receiving throttling/unthrottling OCC message
>>   for that chip and schedule on all chips after receiving active.
>> - After an OCC reset all the cpus will be in Psafe frequency. So call
>>   target() and restore the frequency to policy->cur after OCC_ACTIVE
>>   and Pmax unthrottling
>> - Taken care of Viresh and Preeti's comments.
> 
> That's a lot. I am not an expert here and so really can't comment on
> the internals of ppc. But, is it patch solving a single problem ? I don't
> know, I somehow got the impression that it can be split into multiple
> (smaller & review-able) patches. Only if it makes sense. Your call.

All the changes introduced in this patch is centered around opal_message
notification handler powernv_cpufreq_occ_msg(). I can split it into multiple
patches but it all will be relevant only to solve the above problem.

> 
>> diff --git a/drivers/cpufreq/powernv-cpufreq.c 
>> b/drivers/cpufreq/powernv-cpufreq.c
> 
>> +void powernv_cpufreq_work_fn(struct work_struct *work)
>> +{
>> +   struct chip *c = container_of(work, struct chip, throttle);
>> +   unsigned int cpu;
>> +
>> +   smp_call_function_any(>mask,
>> + powernv_cpufreq_throttle_check, NULL, 0);
>> +
>> +   for_each_cpu(cpu, >mask) {
> 
> for_each_online_cpu ?

I want to iterate on all the cpus in a chip stored in 'struct chip.mask'.
If you were intending me to avoid 'if(!cpu_online(cpu))' then will the 
following do:

for_each_cpu_and(cpu, >mask, cpu_online_mask)

> 
>> +   int index;
>> +   struct cpufreq_frequency_table *freq_table;
>> +   struct cpufreq_policy cpu_policy;
> 
> Name it policy.

Okay.

> 
>> +
>> +   if (!cpu_online(cpu))
>> +   continue;
> 
> And you can kill this..
> 
>> +   cpufreq_get_policy(_policy, cpu);
>> +   freq_table = cpufreq_frequency_get_table(cpu_policy.cpu);
> 
> Just do, policy->freq_table.

Okay.

> 
> 
>> +static int powernv_cpufreq_occ_msg(struct notifier_block *nb,
>> +  unsigned long msg_type, void *msg)
>> +{
> 
>> +   if (reason && reason <= 5)
>> +   pr_info("OCC: Chip %d Pmax reduced due to %s\n",
>> +   (int)chip_id, throttle_reason[reason]);
>> +   else
>> +   pr_info("OCC: Chip %d %s\n", (int)chip_id,
>> +   throttle_reason[reason]);
> 
> Blank line here. They are better for readability after blocks and loops.

Yes will do.

> 
>> +   for (i = 0; i < nr_chips; i++)
>> +   if (chips[i].id == (int)chip_id)
> 
> Why isn't .id 64 bit ?

I guess 6 bits are sufficient to store chip id given that max number of chips
can be 256. I don't have good reason for defining .id 32 bit.

Yeah 64-bit .id 

Re: [PATCH] ARM: dts: imx5: Add dts files for USB armory.

[Peter Chen]

On Mon, Apr 27, 2015 at 03:37:08PM +0200, Andrej Rosano wrote:
> Hi Shawn,
> 
> On Mon, Apr 27, 2015 at 07:57:48PM +0800, Shawn Guo wrote:
> > +Peter
> > 
> > On Fri, Mar 27, 2015 at 01:23:00PM -0700, Vagrant Cascadian wrote:
> > > Add support for the USB armory board by Inverse Path. This board
> > > features a Freescale iMX53 SoC, 512MB RAM, and USB OTG operating in
> > > either peripheral or host mode, and 5 GPIO pins.
> > > 
> > > One .dtb is generated for operating in peripheral mode, and one is
> > > generated for operating in host mode.
> > 
> > Vagrant,
> > 
> > Does that mean this board can work in peripheral or host mode but can
> > switch between them at run-time?
> 
> The board can switch between host and peripheral mode without any
> hardware modification, but it need to reboot itself to pick up the
> corresponding dtb file. I am not sure if there is possible using the
> devicetree overlay feature to switch between the two modes runtime.
> 

Not a good way, it is just one board with two different usb cables.

Current chipidea usb driver supports role switch function well, if you
have a gpio or id pin for it.

Peter

> Andrej
> 
> > 
> > Shawn
> > 
> > > 
> > > Signed-off-by: Vagrant Cascadian 
> > > Cc: Andrej Rosano 
> > > Cc: Rob Herring 
> > > Cc: Pawel Moll 
> > > Cc: Mark Rutland 
> > > Cc: Ian Campbell 
> > > Cc: Kumar Gala 
> > > Cc: Russell King 
> > > Cc: Shawn Guo 
> > > Cc: Sascha Hauer 
> > > Cc: devicet...@vger.kernel.org
> > > Cc: linux-arm-ker...@lists.infradead.org
> > > Cc: linux-kernel@vger.kernel.org
> > > ---
> > >  arch/arm/boot/dts/Makefile  |   2 +
> > >  arch/arm/boot/dts/imx53-usbarmory-host_mode.dts |  17 +++
> > >  arch/arm/boot/dts/imx53-usbarmory.dts   |  13 ++
> > >  arch/arm/boot/dts/imx53-usbarmory.dtsi  | 183 
> > > 
> > >  4 files changed, 215 insertions(+)
> > >  create mode 100644 arch/arm/boot/dts/imx53-usbarmory-host_mode.dts
> > >  create mode 100644 arch/arm/boot/dts/imx53-usbarmory.dts
> > >  create mode 100644 arch/arm/boot/dts/imx53-usbarmory.dtsi
> > > 
> > > diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
> > > index a1c776b..bd2258b 100644
> > > --- a/arch/arm/boot/dts/Makefile
> > > +++ b/arch/arm/boot/dts/Makefile
> > > @@ -244,6 +244,8 @@ dtb-$(CONFIG_SOC_IMX53) += \
> > >   imx53-smd.dtb \
> > >   imx53-tx53-x03x.dtb \
> > >   imx53-tx53-x13x.dtb \
> > > + imx53-usbarmory.dtb \
> > > + imx53-usbarmory-host_mode.dtb \
> > >   imx53-voipac-bsb.dtb
> > >  dtb-$(CONFIG_SOC_IMX6Q) += \
> > >   imx6dl-aristainetos_4.dtb \
> > > diff --git a/arch/arm/boot/dts/imx53-usbarmory-host_mode.dts 
> > > b/arch/arm/boot/dts/imx53-usbarmory-host_mode.dts
> > > new file mode 100644
> > > index 000..a94cb1d
> > > --- /dev/null
> > > +++ b/arch/arm/boot/dts/imx53-usbarmory-host_mode.dts
> > > @@ -0,0 +1,17 @@
> > > +/*
> > > + * Copyright 2015 Inverse Path, S.r.l.
> > > + *
> > > + * The code contained herein is licensed under the GNU General Public
> > > + * License. You may obtain a copy of the GNU General Public License
> > > + * Version 2 or later at the following locations:
> > > + *
> > > + * http://www.opensource.org/licenses/gpl-license.html
> > > + * http://www.gnu.org/copyleft/gpl.html
> > > + */
> > > +
> > > +/dts-v1/;
> > > +#include "imx53-usbarmory.dtsi"
> > > +
> > > + {
> > > + dr_mode = "host";
> > > +};
> > > diff --git a/arch/arm/boot/dts/imx53-usbarmory.dts 
> > > b/arch/arm/boot/dts/imx53-usbarmory.dts
> > > new file mode 100644
> > > index 000..c86a4d8
> > > --- /dev/null
> > > +++ b/arch/arm/boot/dts/imx53-usbarmory.dts
> > > @@ -0,0 +1,13 @@
> > > +/*
> > > + * Copyright 2015 Inverse Path, S.r.l.
> > > + *
> > > + * The code contained herein is licensed under the GNU General Public
> > > + * License. You may obtain a copy of the GNU General Public License
> > > + * Version 2 or later at the following locations:
> > > + *
> > > + * http://www.opensource.org/licenses/gpl-license.html
> > > + * http://www.gnu.org/copyleft/gpl.html
> > > + */
> > > +
> > > +/dts-v1/;
> > > +#include "imx53-usbarmory.dtsi"
> > > diff --git a/arch/arm/boot/dts/imx53-usbarmory.dtsi 
> > > b/arch/arm/boot/dts/imx53-usbarmory.dtsi
> > > new file mode 100644
> > > index 000..b4a9052
> > > --- /dev/null
> > > +++ b/arch/arm/boot/dts/imx53-usbarmory.dtsi
> > > @@ -0,0 +1,183 @@
> > > +/*
> > > + * Copyright 2015 Inverse Path, S.r.l.
> > > + *
> > > + * The code contained herein is licensed under the GNU General Public
> > > + * License. You may obtain a copy of the GNU General Public License
> > > + * Version 2 or later at the following locations:
> > > + *
> > > + * http://www.opensource.org/licenses/gpl-license.html
> > > + * http://www.gnu.org/copyleft/gpl.html
> > > + */
> > > +
> > > +#include "imx53.dtsi"
> > > +
> > > +/ {
> > > + model = "Inverse Path USB armory";
> > > + compatible = "inversepath,imx53-usbarmory", "fsl,imx53";
> > > +};
> > > +
> > > +/ {
> > > + 

Re: [PATCH 1/1] drivers/usb/chipidea/debuc.c: avoid out of bound read

[Peter Chen]

On Mon, Apr 27, 2015 at 08:25:12PM +0200, Heinrich Schuchardt wrote:
> On 22.04.2015 03:26, Peter Chen wrote:
> > On Tue, Apr 21, 2015 at 09:25:41PM +0200, Heinrich Schuchardt wrote:
> >> Hello Peter,
> >>
> >> thanks for reviewing.
> >>
> >> On 21.04.2015 03:32, Peter Chen wrote:
> >>> On Fri, Apr 17, 2015 at 08:04:13AM +0200, Heinrich Schuchardt wrote:
>  A string written by the user may not be zero terminated.
> 
>  sscanf may read memory beyond the buffer if no zero byte
>  is found.
> 
>  Signed-off-by: Heinrich Schuchardt 
>  ---
>   drivers/usb/chipidea/debug.c | 6 +-
>   1 file changed, 5 insertions(+), 1 deletion(-)
> 
>  diff --git a/drivers/usb/chipidea/debug.c b/drivers/usb/chipidea/debug.c
>  index dfb05ed..ef08af3 100644
>  --- a/drivers/usb/chipidea/debug.c
>  +++ b/drivers/usb/chipidea/debug.c
>  @@ -88,9 +88,13 @@ static ssize_t ci_port_test_write(struct file *file, 
>  const char __user *ubuf,
>   char buf[32];
>   int ret;
>   
>  -if (copy_from_user(buf, ubuf, min_t(size_t, sizeof(buf) - 1, 
>  count)))
>  +count = min_t(size_t, sizeof(buf) - 1, count);
>  +if (copy_from_user(buf, ubuf, count))
>   return -EFAULT;
> >>>
> >>> Any reasons to change above?
> >>
> >> Otherwise we would have two lines with the term
> >> min_t(size_t, sizeof(buf) - 1, count).
> > 
> > Sorry, two lines of min_t(..)? Why I can't find it?
> 
> Hello Peter,
> 
> in my patch I write:
> 
> count = min_t(size_t, sizeof(buf) - 1, count);
> if (copy_from_user(buf, ubuf, count))
>   return -EFAULT;
> 
> /* sscanf requires a zero terminated string */
> buf[count] = 0;
> 
> Without the first part of the change I would have had to write:
> 
> if (copy_from_user(buf, ubuf, min_t(size_t, sizeof(buf) - 1, count)))
>   return -EFAULT;
> 
> /* sscanf requires a zero terminated string */
> buf[min_t(size_t, sizeof(buf) - 1, count)] = 0;
> 
> We should do the same calculation
> "min_t(size_t, sizeof(buf) - 1, count)"
> only once in the coding.

Oh, yeah. 
Send your v2 with '\0' change, thanks.

Peter

> 
> Best regards
> 
> Heinrich
> 
> 
> > 
> > 
> >>
> >> This would make the code harder to read.
> >>
>   
>  +/* sscanf requires a zero terminated string */
>  +buf[count] = 0;
>  +
> >>>
> >>> I prefer using '\0'
> >>
> >> If you confirm the rest of the patch is ok, I will send an updated patch.
> >>
> >> Best regards
> >>
> >> Heinrich
> >>
> >>>
>   if (sscanf(buf, "%u", ) != 1)
>   return -EINVAL;
>   
> >>
> > 
> 

-- 

Best Regards,
Peter Chen
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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 07/13] thermal: inline only once used function

[Sascha Hauer]

Inline update_temperature into its only caller to make the code
more readable.

Signed-off-by: Sascha Hauer 
---
 drivers/thermal/thermal_core.c | 17 +
 1 file changed, 5 insertions(+), 12 deletions(-)

diff --git a/drivers/thermal/thermal_core.c b/drivers/thermal/thermal_core.c
index ffe09186..81ebc24 100644
--- a/drivers/thermal/thermal_core.c
+++ b/drivers/thermal/thermal_core.c
@@ -450,9 +450,12 @@ exit:
 }
 EXPORT_SYMBOL_GPL(thermal_zone_get_temp);
 
-static void update_temperature(struct thermal_zone_device *tz)
+void thermal_zone_device_update(struct thermal_zone_device *tz)
 {
-   int temp, ret;
+   int temp, ret, count;
+
+   if (!tz->ops->get_temp)
+   return;
 
ret = thermal_zone_get_temp(tz, );
if (ret) {
@@ -471,16 +474,6 @@ static void update_temperature(struct thermal_zone_device 
*tz)
trace_thermal_temperature(tz);
dev_dbg(>device, "last_temperature=%d, current_temperature=%d\n",
tz->last_temperature, tz->temperature);
-}
-
-void thermal_zone_device_update(struct thermal_zone_device *tz)
-{
-   int count;
-
-   if (!tz->ops->get_temp)
-   return;
-
-   update_temperature(tz);
 
for (count = 0; count < tz->trips; count++)
handle_thermal_trip(tz, count);
-- 
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 01/13] thermal: consistently use int for temperatures

[Sascha Hauer]

The thermal code uses int, long and unsigned long for temperatures
in different places. Using an unsigned type limits the thermal framework
to positive temperatures without need. 'long' is 64bit on several
architectures which is not needed. Consistently use a plain 'int'
for temperatures.

Signed-off-by: Sascha Hauer 
---
 drivers/acpi/thermal.c | 12 +-
 drivers/hwmon/lm75.c   |  2 +-
 drivers/hwmon/ntc_thermistor.c |  2 +-
 drivers/hwmon/tmp102.c |  2 +-
 drivers/input/touchscreen/sun4i-ts.c   |  8 +++
 drivers/platform/x86/acerhdf.c |  9 
 drivers/power/power_supply_core.c  |  2 +-
 drivers/thermal/armada_thermal.c   |  2 +-
 drivers/thermal/db8500_thermal.c   |  7 +++---
 drivers/thermal/dove_thermal.c |  2 +-
 drivers/thermal/fair_share.c   |  2 +-
 drivers/thermal/gov_bang_bang.c|  5 ++--
 drivers/thermal/imx_thermal.c  | 27 +++---
 .../thermal/int340x_thermal/int340x_thermal_zone.c | 10 
 .../thermal/int340x_thermal/int340x_thermal_zone.h |  8 +++
 drivers/thermal/intel_soc_dts_thermal.c|  7 +++---
 drivers/thermal/of-thermal.c   | 14 +--
 drivers/thermal/rcar_thermal.c |  7 +++---
 drivers/thermal/rockchip_thermal.c | 10 
 drivers/thermal/samsung/exynos_tmu.c   | 19 ---
 drivers/thermal/spear_thermal.c|  2 +-
 drivers/thermal/st/st_thermal.c|  5 ++--
 drivers/thermal/step_wise.c|  4 ++--
 drivers/thermal/tegra_soctherm.c   |  4 ++--
 drivers/thermal/thermal_core.c | 26 ++---
 drivers/thermal/thermal_hwmon.c| 10 
 drivers/thermal/ti-soc-thermal/ti-thermal-common.c | 10 
 drivers/thermal/x86_pkg_temp_thermal.c | 10 
 include/linux/thermal.h| 26 +
 29 files changed, 120 insertions(+), 134 deletions(-)

diff --git a/drivers/acpi/thermal.c b/drivers/acpi/thermal.c
index d24fa19..68bff60 100644
--- a/drivers/acpi/thermal.c
+++ b/drivers/acpi/thermal.c
@@ -529,8 +529,7 @@ static void acpi_thermal_check(void *data)
 
 /* sys I/F for generic thermal sysfs support */
 
-static int thermal_get_temp(struct thermal_zone_device *thermal,
-   unsigned long *temp)
+static int thermal_get_temp(struct thermal_zone_device *thermal, int *temp)
 {
struct acpi_thermal *tz = thermal->devdata;
int result;
@@ -637,7 +636,7 @@ static int thermal_get_trip_type(struct thermal_zone_device 
*thermal,
 }
 
 static int thermal_get_trip_temp(struct thermal_zone_device *thermal,
-int trip, unsigned long *temp)
+int trip, int *temp)
 {
struct acpi_thermal *tz = thermal->devdata;
int i;
@@ -690,7 +689,8 @@ static int thermal_get_trip_temp(struct thermal_zone_device 
*thermal,
 }
 
 static int thermal_get_crit_temp(struct thermal_zone_device *thermal,
-   unsigned long *temperature) {
+   int *temperature)
+{
struct acpi_thermal *tz = thermal->devdata;
 
if (tz->trips.critical.flags.valid) {
@@ -713,8 +713,8 @@ static int thermal_get_trend(struct thermal_zone_device 
*thermal,
return -EINVAL;
 
if (type == THERMAL_TRIP_ACTIVE) {
-   unsigned long trip_temp;
-   unsigned long temp = DECI_KELVIN_TO_MILLICELSIUS_WITH_OFFSET(
+   int trip_temp;
+   int temp = DECI_KELVIN_TO_MILLICELSIUS_WITH_OFFSET(
tz->temperature, tz->kelvin_offset);
if (thermal_get_trip_temp(thermal, trip, _temp))
return -EINVAL;
diff --git a/drivers/hwmon/lm75.c b/drivers/hwmon/lm75.c
index fe41d5a..e4e57bb 100644
--- a/drivers/hwmon/lm75.c
+++ b/drivers/hwmon/lm75.c
@@ -104,7 +104,7 @@ static inline long lm75_reg_to_mc(s16 temp, u8 resolution)
 
 /* sysfs attributes for hwmon */
 
-static int lm75_read_temp(void *dev, long *temp)
+static int lm75_read_temp(void *dev, int *temp)
 {
struct lm75_data *data = lm75_update_device(dev);
 
diff --git a/drivers/hwmon/ntc_thermistor.c b/drivers/hwmon/ntc_thermistor.c
index 112e4d4..9f085df 100644
--- a/drivers/hwmon/ntc_thermistor.c
+++ b/drivers/hwmon/ntc_thermistor.c
@@ -430,7 +430,7 @@ static int ntc_thermistor_get_ohm(struct ntc_data *data)
return -EINVAL;
 }
 
-static int ntc_read_temp(void *dev, long *temp)
+static int ntc_read_temp(void *dev, int *temp)
 {
struct ntc_data *data = dev_get_drvdata(dev);
int ohm;
diff --git 

[PATCH 12/13] thermal: thermal: Add support for hardware-tracked trip points

[Sascha Hauer]

This adds support for hardware-tracked trip points to the device tree
thermal sensor framework.

The framework supports an arbitrary number of trip points. Whenever
the current temperature is updated, the trip points immediately
below and above the current temperature are found. A .set_trips
callback is then called with the temperatures. If there is no trip
point above or below the current temperature, the passed trip
temperature will be ULONG_MAX or 0 respectively. In this callback,
the driver should program the hardware such that it is notified
when either of these trip points are triggered. When a trip point
is triggered, the driver should call `thermal_zone_device_update'
for the respective thermal zone. This will cause the trip points
to be updated again.

If .set_trips is not implemented, the framework behaves as before.

This patch is based on an earlier version from Mikko Perttunen


Signed-off-by: Sascha Hauer 
---
 drivers/thermal/thermal_core.c | 42 ++
 include/linux/thermal.h|  3 +++
 2 files changed, 45 insertions(+)

diff --git a/drivers/thermal/thermal_core.c b/drivers/thermal/thermal_core.c
index 420c702..4e1aaab 100644
--- a/drivers/thermal/thermal_core.c
+++ b/drivers/thermal/thermal_core.c
@@ -453,6 +453,45 @@ int thermal_zone_get_temp(struct thermal_zone_device *tz, 
int *temp)
 }
 EXPORT_SYMBOL_GPL(thermal_zone_get_temp);
 
+static void thermal_zone_set_trips(struct thermal_zone_device *tz)
+{
+   int low = -INT_MAX;
+   int high = INT_MAX;
+   int trip_temp, hysteresis;
+   int temp = tz->temperature;
+   int i;
+
+   if (!tz->ops->set_trips)
+   return;
+
+   /* No need to change trip points */
+   if (temp > tz->prev_low_trip && temp < tz->prev_high_trip)
+   return;
+
+   for (i = 0; i < tz->trips; i++) {
+   unsigned long trip_low;
+
+   tz->ops->get_trip_temp(tz, i, _temp);
+   tz->ops->get_trip_hyst(tz, i, );
+
+   trip_low = trip_temp - hysteresis;
+
+   if (trip_low < temp && trip_low > low)
+   low = trip_low;
+
+   if (trip_temp > temp && trip_temp < high)
+   high = trip_temp;
+   }
+
+   tz->prev_low_trip = low;
+   tz->prev_high_trip = high;
+
+   dev_dbg(>device, "new temperature boundaries: %d < x < %d\n",
+   low, high);
+
+   tz->ops->set_trips(tz, low, high);
+}
+
 void thermal_zone_device_update(struct thermal_zone_device *tz)
 {
int temp, ret, count;
@@ -473,6 +512,7 @@ void thermal_zone_device_update(struct thermal_zone_device 
*tz)
mutex_lock(>lock);
tz->last_temperature = tz->temperature;
tz->temperature = temp;
+   thermal_zone_set_trips(tz);
mutex_unlock(>lock);
 
trace_thermal_temperature(tz);
@@ -1494,6 +1534,8 @@ struct thermal_zone_device 
*thermal_zone_device_register(const char *type,
tz->trips = trips;
tz->passive_delay = passive_delay;
tz->polling_delay = polling_delay;
+   tz->prev_low_trip = INT_MAX;
+   tz->prev_high_trip = -INT_MAX;
 
dev_set_name(>device, "thermal_zone%d", tz->id);
result = device_register(>device);
diff --git a/include/linux/thermal.h b/include/linux/thermal.h
index 07bd5e8..aef6e13 100644
--- a/include/linux/thermal.h
+++ b/include/linux/thermal.h
@@ -87,6 +87,7 @@ struct thermal_zone_device_ops {
int (*unbind) (struct thermal_zone_device *,
   struct thermal_cooling_device *);
int (*get_temp) (struct thermal_zone_device *, int *);
+   int (*set_trips) (struct thermal_zone_device *, int, int);
int (*get_mode) (struct thermal_zone_device *,
 enum thermal_device_mode *);
int (*set_mode) (struct thermal_zone_device *,
@@ -180,6 +181,8 @@ struct thermal_zone_device {
int last_temperature;
int emul_temperature;
int passive;
+   int prev_low_trip;
+   int prev_high_trip;
unsigned int forced_passive;
const struct thermal_zone_device_ops *ops;
const struct thermal_zone_params *tzp;
-- 
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 13/13] thermal: of: implement .set_trips for device tree thermal zones

[Sascha Hauer]

Signed-off-by: Sascha Hauer 
---
 drivers/thermal/of-thermal.c | 12 
 include/linux/thermal.h  |  3 +++
 2 files changed, 15 insertions(+)

diff --git a/drivers/thermal/of-thermal.c b/drivers/thermal/of-thermal.c
index bd3185e..f8dd847 100644
--- a/drivers/thermal/of-thermal.c
+++ b/drivers/thermal/of-thermal.c
@@ -97,6 +97,17 @@ static int of_thermal_get_temp(struct thermal_zone_device 
*tz,
return data->ops->get_temp(data->sensor_data, temp);
 }
 
+static int of_thermal_set_trips(struct thermal_zone_device *tz,
+  int low, int high)
+{
+   struct __thermal_zone *data = tz->devdata;
+
+   if (!data->ops || !data->ops->set_trips)
+   return -ENOSYS;
+
+   return data->ops->set_trips(data->sensor_data, low, high);
+}
+
 /**
  * of_thermal_get_ntrips - function to export number of available trip
  *points.
@@ -367,6 +378,7 @@ static int of_thermal_get_crit_temp(struct 
thermal_zone_device *tz,
 
 static const struct thermal_zone_device_ops of_thermal_ops = {
.get_temp = of_thermal_get_temp,
+   .set_trips = of_thermal_set_trips,
.get_trend = of_thermal_get_trend,
.set_emul_temp = of_thermal_set_emul_temp,
 
diff --git a/include/linux/thermal.h b/include/linux/thermal.h
index aef6e13..b751f6b 100644
--- a/include/linux/thermal.h
+++ b/include/linux/thermal.h
@@ -267,12 +267,15 @@ struct thermal_genl_event {
  *
  * Optional:
  * @get_trend: a pointer to a function that reads the sensor temperature trend.
+ * @set_trips: a pointer to a function that sets a temperature window which 
shall
+ * trigger an interrupt when it is left.
  * @set_emul_temp: a pointer to a function that sets sensor emulated
  *temperature.
  */
 struct thermal_zone_of_device_ops {
int (*get_temp)(void *, int *);
int (*get_trend)(void *, int, enum thermal_trend *);
+   int (*set_trips)(void *, int, int);
int (*set_emul_temp)(void *, int);
 };
 
-- 
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 06/13] thermal: Add comment explaining test for critical temperature

[Sascha Hauer]

The code testing if a temperature should be emulated or not is
not obvious. Add a comment explaining why this test is done.

Signed-off-by: Sascha Hauer 
---
 drivers/thermal/thermal_core.c | 5 +
 1 file changed, 5 insertions(+)

diff --git a/drivers/thermal/thermal_core.c b/drivers/thermal/thermal_core.c
index 4633964..ffe09186 100644
--- a/drivers/thermal/thermal_core.c
+++ b/drivers/thermal/thermal_core.c
@@ -435,6 +435,11 @@ int thermal_zone_get_temp(struct thermal_zone_device *tz, 
int *temp)
}
}
 
+   /*
+* Only allow emulating a temperature when the real temperature
+* is below the critical temperature so that the emulation code
+* cannot hide critical conditions.
+*/
if (!ret && *temp < crit_temp)
*temp = tz->emul_temperature;
}
-- 
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 04/13] thermal: remove useless call to thermal_zone_device_set_polling

[Sascha Hauer]

When the thermal zone has no get_temp callback then 
thermal_zone_device_register()
calls thermal_zone_device_set_polling() with a polling delay of 0. This
only cancels the poll_queue. Since the poll_queue hasn't been scheduled this
is a no-op. Remove it.

Signed-off-by: Sascha Hauer 
Acked-by: Eduardo Valentin 
---
 drivers/thermal/thermal_core.c | 3 ---
 1 file changed, 3 deletions(-)

diff --git a/drivers/thermal/thermal_core.c b/drivers/thermal/thermal_core.c
index cecebac..ad1d3c9 100644
--- a/drivers/thermal/thermal_core.c
+++ b/drivers/thermal/thermal_core.c
@@ -1571,9 +1571,6 @@ struct thermal_zone_device 
*thermal_zone_device_register(const char *type,
 
INIT_DELAYED_WORK(&(tz->poll_queue), thermal_zone_device_check);
 
-   if (!tz->ops->get_temp)
-   thermal_zone_device_set_polling(tz, 0);
-
thermal_zone_device_update(tz);
 
return tz;
-- 
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 kernel] commit 4fbdf9cb ("lpfc: Fix for lun discovery issue with saturn adapter.")

[Alexey Kardashevskiy]

This reverts 4fbdf9cb is breaks LPFC on POWER7 machine, big endian kernel.

This is the hardware used for verification:
0005:01:00.0 Fibre Channel [0c04]: Emulex Corporation Saturn-X: LightPulse 
Fibre Channel Host Adapter [10df:f100] (rev 03)
0005:01:00.1 Fibre Channel [0c04]: Emulex Corporation Saturn-X: LightPulse 
Fibre Channel Host Adapter [10df:f100] (rev 03)

Signed-off-by: Alexey Kardashevskiy 
---
 drivers/scsi/lpfc/lpfc_scsi.c | 41 +
 1 file changed, 21 insertions(+), 20 deletions(-)

diff --git a/drivers/scsi/lpfc/lpfc_scsi.c b/drivers/scsi/lpfc/lpfc_scsi.c
index cb73cf9..c140f99 100644
--- a/drivers/scsi/lpfc/lpfc_scsi.c
+++ b/drivers/scsi/lpfc/lpfc_scsi.c
@@ -1130,25 +1130,6 @@ lpfc_release_scsi_buf(struct lpfc_hba *phba, struct 
lpfc_scsi_buf *psb)
 }
 
 /**
- * lpfc_fcpcmd_to_iocb - copy the fcp_cmd data into the IOCB
- * @data: A pointer to the immediate command data portion of the IOCB.
- * @fcp_cmnd: The FCP Command that is provided by the SCSI layer.
- *
- * The routine copies the entire FCP command from @fcp_cmnd to @data while
- * byte swapping the data to big endian format for transmission on the wire.
- **/
-static void
-lpfc_fcpcmd_to_iocb(uint8_t *data, struct fcp_cmnd *fcp_cmnd)
-{
-   int i, j;
-
-   for (i = 0, j = 0; i < sizeof(struct fcp_cmnd);
-i += sizeof(uint32_t), j++) {
-   ((uint32_t *)data)[j] = cpu_to_be32(((uint32_t *)fcp_cmnd)[j]);
-   }
-}
-
-/**
  * lpfc_scsi_prep_dma_buf_s3 - DMA mapping for scsi buffer to SLI3 IF spec
  * @phba: The Hba for which this call is being executed.
  * @lpfc_cmd: The scsi buffer which is going to be mapped.
@@ -1283,7 +1264,6 @@ lpfc_scsi_prep_dma_buf_s3(struct lpfc_hba *phba, struct 
lpfc_scsi_buf *lpfc_cmd)
 * we need to set word 4 of IOCB here
 */
iocb_cmd->un.fcpi.fcpi_parm = scsi_bufflen(scsi_cmnd);
-   lpfc_fcpcmd_to_iocb(iocb_cmd->unsli3.fcp_ext.icd, fcp_cmnd);
return 0;
 }
 
@@ -4147,6 +4127,24 @@ lpfc_scsi_cmd_iocb_cmpl(struct lpfc_hba *phba, struct 
lpfc_iocbq *pIocbIn,
 }
 
 /**
+ * lpfc_fcpcmd_to_iocb - copy the fcp_cmd data into the IOCB
+ * @data: A pointer to the immediate command data portion of the IOCB.
+ * @fcp_cmnd: The FCP Command that is provided by the SCSI layer.
+ *
+ * The routine copies the entire FCP command from @fcp_cmnd to @data while
+ * byte swapping the data to big endian format for transmission on the wire.
+ **/
+static void
+lpfc_fcpcmd_to_iocb(uint8_t *data, struct fcp_cmnd *fcp_cmnd)
+{
+   int i, j;
+   for (i = 0, j = 0; i < sizeof(struct fcp_cmnd);
+i += sizeof(uint32_t), j++) {
+   ((uint32_t *)data)[j] = cpu_to_be32(((uint32_t *)fcp_cmnd)[j]);
+   }
+}
+
+/**
  * lpfc_scsi_prep_cmnd - Wrapper func for convert scsi cmnd to FCP info unit
  * @vport: The virtual port for which this call is being executed.
  * @lpfc_cmd: The scsi command which needs to send.
@@ -4225,6 +4223,9 @@ lpfc_scsi_prep_cmnd(struct lpfc_vport *vport, struct 
lpfc_scsi_buf *lpfc_cmd,
fcp_cmnd->fcpCntl3 = 0;
phba->fc4ControlRequests++;
}
+   if (phba->sli_rev == 3 &&
+   !(phba->sli3_options & LPFC_SLI3_BG_ENABLED))
+   lpfc_fcpcmd_to_iocb(iocb_cmd->unsli3.fcp_ext.icd, fcp_cmnd);
/*
 * Finish initializing those IOCB fields that are independent
 * of the scsi_cmnd request_buffer
-- 
2.0.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 02/13] mm: meminit: Move page initialization into a separate function.

[Mel Gorman]

On Mon, Apr 27, 2015 at 03:46:33PM -0700, Andrew Morton wrote:
> On Thu, 23 Apr 2015 11:33:05 +0100 Mel Gorman  wrote:
> 
> > From: Robin Holt 
> 
> : : host cuda-allmx.sgi.com[192.48.157.12] said: 550 cuda_nsu 
> 5.1.1
> :: Recipient address rejected: User unknown in virtual alias
> :table (in reply to RCPT TO command)
> 
> Has Robin moved, or is SGI mail busted?

Robin has moved and I do not have an updated address for him. The
address used in the patches was the one he posted the patches with.

-- 
Mel Gorman
SUSE Labs
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH 05/13] thermal: Use IS_ENABLED instead of #ifdef

[Sascha Hauer]

Use IS_ENABLED(CONFIG_THERMAL_EMULATION) to make the code more readable
and to get rid of the addtional #ifdef around the variable definitions
in thermal_zone_get_temp().

Signed-off-by: Sascha Hauer 
---
 drivers/thermal/thermal_core.c | 43 ++
 1 file changed, 18 insertions(+), 25 deletions(-)

diff --git a/drivers/thermal/thermal_core.c b/drivers/thermal/thermal_core.c
index ad1d3c9..4633964 100644
--- a/drivers/thermal/thermal_core.c
+++ b/drivers/thermal/thermal_core.c
@@ -414,11 +414,9 @@ static void handle_thermal_trip(struct thermal_zone_device 
*tz, int trip)
 int thermal_zone_get_temp(struct thermal_zone_device *tz, int *temp)
 {
int ret = -EINVAL;
-#ifdef CONFIG_THERMAL_EMULATION
int count;
int crit_temp = INT_MAX;
enum thermal_trip_type type;
-#endif
 
if (!tz || IS_ERR(tz) || !tz->ops->get_temp)
goto exit;
@@ -426,25 +424,21 @@ int thermal_zone_get_temp(struct thermal_zone_device *tz, 
int *temp)
mutex_lock(>lock);
 
ret = tz->ops->get_temp(tz, temp);
-#ifdef CONFIG_THERMAL_EMULATION
-   if (!tz->emul_temperature)
-   goto skip_emul;
-
-   for (count = 0; count < tz->trips; count++) {
-   ret = tz->ops->get_trip_type(tz, count, );
-   if (!ret && type == THERMAL_TRIP_CRITICAL) {
-   ret = tz->ops->get_trip_temp(tz, count, _temp);
-   break;
+
+   if (IS_ENABLED(CONFIG_THERMAL_EMULATION) && tz->emul_temperature) {
+   for (count = 0; count < tz->trips; count++) {
+   ret = tz->ops->get_trip_type(tz, count, );
+   if (!ret && type == THERMAL_TRIP_CRITICAL) {
+   ret = tz->ops->get_trip_temp(tz, count,
+   _temp);
+   break;
+   }
}
-   }
 
-   if (ret)
-   goto skip_emul;
+   if (!ret && *temp < crit_temp)
+   *temp = tz->emul_temperature;
+   }
 
-   if (*temp < crit_temp)
-   *temp = tz->emul_temperature;
-skip_emul:
-#endif
mutex_unlock(>lock);
 exit:
return ret;
@@ -780,7 +774,6 @@ policy_show(struct device *dev, struct device_attribute 
*devattr, char *buf)
return sprintf(buf, "%s\n", tz->governor->name);
 }
 
-#ifdef CONFIG_THERMAL_EMULATION
 static ssize_t
 emul_temp_store(struct device *dev, struct device_attribute *attr,
 const char *buf, size_t count)
@@ -806,7 +799,6 @@ emul_temp_store(struct device *dev, struct device_attribute 
*attr,
return ret ? ret : count;
 }
 static DEVICE_ATTR(emul_temp, S_IWUSR, NULL, emul_temp_store);
-#endif/*CONFIG_THERMAL_EMULATION*/
 
 static DEVICE_ATTR(type, 0444, type_show, NULL);
 static DEVICE_ATTR(temp, 0444, temp_show, NULL);
@@ -1536,11 +1528,12 @@ struct thermal_zone_device 
*thermal_zone_device_register(const char *type,
goto unregister;
}
 
-#ifdef CONFIG_THERMAL_EMULATION
-   result = device_create_file(>device, _attr_emul_temp);
-   if (result)
-   goto unregister;
-#endif
+   if (IS_ENABLED(CONFIG_THERMAL_EMULATION)) {
+   result = device_create_file(>device, _attr_emul_temp);
+   if (result)
+   goto unregister;
+   }
+
/* Create policy attribute */
result = device_create_file(>device, _attr_policy);
if (result)
-- 
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/

Re: [PATCH] ARM: gic: Document Power and Clock Domain optional properties

[Geert Uytterhoeven]

Hi Mark,

On Mon, Apr 27, 2015 at 7:15 PM, Mark Rutland  wrote:
> On Mon, Apr 27, 2015 at 05:43:13PM +0100, Geert Uytterhoeven wrote:
>> On Mon, Apr 27, 2015 at 5:54 PM, Mark Rutland  wrote:
>> > On Mon, Apr 27, 2015 at 04:00:11PM +0100, Geert Uytterhoeven wrote:
>> >> On some SoCs, the GIC may be part of a PM Domain (hardware Power and/or
>> >> Clock Domain).  Document the related optional DT properties.
>> >>
>> >> Note: As the current GIC driver doesn't support Runtime PM yet, PM
>> >> Domain constraints must be handled elsewhere in e.g. platform code.
>> >
>> > I'm worried that without a current user these properties aren't going to
>> > see any testing...
>>
>> Still, DT is supposed to describe the hardware. Even if the driver doesn't
>> use the description.
>
> I appreciate that...
>
>> >> Signed-off-by: Geert Uytterhoeven 
>> >> ---
>> >> To preserve DT stability, we would like to add these properties to the
>> >> affected shmobile dtsi files.
>> >
>> > ... which means that they could be wrong, and will get in the way of
>> > stability rather than aiding it.
>>
>> We do know the GIC is part of the power domain, and has a controllable
>> clock (on the affected SoCs).
>
> ... my concern is that the data we place into the DT will be untested
> given that we don't have software relying on it. If said data is not
> correct, it is harmful to have, especially for such fundamental
> properties.

Your statement challenges the viability of Stable DT Requirements, as we
can thus never write a DTS until the full software implementation has been
completed ;-)

We do know switching off that clock disables the GIC, as per documentation
(and experimentation: lock up), and have used the same strategy with
other Renesas interrupt controllers (renesas,intc-irqpin and renesas,irqc).

>> > I'm also concerned that the carving up of clock inputs, power domains,
>> > and other physical details is implementation-specific. I imagine that
>> > pretty much every user that will care about this is using GIC-400, so
>> > could we make this specific to GIC-400?
>>
>> I have no idea which GIC version is being used.
>
> This is unfortunate.
>
>> This is for Renesas R-Mobile APE6 (r8a73a4) and various R-Car Gen2.
>> According to the DTS, they're compatible with "arm,cortex-a15-gic" and
>> "arm,cortex-a7-gic", and work with that value.
>
> Who put the DT together in the first place?

Magnus (added to CC).

> If it's a multi-cluster SoC then we know that we're not using any
> built-in distributor...

R-Mobile APE6 has 2 clusters (4xCA15 and 4xCA7).
R-Car Gen2 has 1 or 2 clusters (2/4xCA15 and/or 2/4xCA7).

>> >> On Thu, Mar 26, 2015 at 11:39 AM, Marc Zyngier  
>> >> wrote:
>> >> > On 25/03/15 21:19, Geert Uytterhoeven wrote:
>> >> >> I would like to add the clock and GIC dependency on the clock in the 
>> >> >> DTS now,
>> >> >> for reasons of DTS stability. But that means I need a temporary 
>> >> >> workaround
>> >> >> to avoid the clock from being disabled, until the GIC driver handles 
>> >> >> this.
>> >> >>
>> >> >> I don't expect a fix for the GIC code to just show up magically. I 
>> >> >> just wanted
>> >> >> you to be aware of the problem. GIC is not the only problematic module 
>> >> >> here,
>> >> >> there are others, cfr. the last slide of [2].
>> >> >
>> >> > As long as there is an agreement from the DT people on the presence of
>> >> > that extra property in the GIC node, I'm happy with that. I'd like it to
>> >> > be documented though.
>> >>
>> >> Full thread at
>> >> http://lists.infradead.org/pipermail/linux-arm-kernel/2015-March/331876.html
>> >>
>> >>  Documentation/devicetree/bindings/arm/gic.txt | 8 
>> >>  1 file changed, 8 insertions(+)
>> >>
>> >> diff --git a/Documentation/devicetree/bindings/arm/gic.txt 
>> >> b/Documentation/devicetree/bindings/arm/gic.txt
>> >> index 2da059a4790cb3c6..b21113b35f085f27 100644
>> >> --- a/Documentation/devicetree/bindings/arm/gic.txt
>> >> +++ b/Documentation/devicetree/bindings/arm/gic.txt
>> >> @@ -58,6 +58,14 @@ Optional
>> >>regions, used when the GIC doesn't have banked registers. The offset is
>> >>cpu-offset * cpu-nr.
>> >>
>> >> +- power-domains : A phandle and PM domain specifier as defined by 
>> >> bindings of
>> >> +   the power controller specified by phandle, used when the 
>> >> GIC
>> >> +   is part of a Power or Clock Domain.
>> >
>> > I imagine that it's possible for the distributor and CPU interfaces to
>> > be in separate power domains in some implementaitons.
>>
>> Possibly (then we're gonna need subnodes, each with their own
>> power-domains properties?).
>
> Potentially for such implementations, yes. To the best of my knowledge a
> GIC-400 is a single block, which is one reason why it would be nice to
> focus on that particular implementation if that's applicable.
>
>> > Which components of the GIC does the apply to? The whole thing? Just the
>> > GICD?
>>
>> Unfortunately that's not documented...
>
> That 

[PATCH 02/13] thermal: trivial: fix typo in comment

[Sascha Hauer]

Signed-off-by: Sascha Hauer 
Acked-by: Eduardo Valentin 
---
 drivers/thermal/thermal_core.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/thermal/thermal_core.c b/drivers/thermal/thermal_core.c
index 62cc82a..244784f 100644
--- a/drivers/thermal/thermal_core.c
+++ b/drivers/thermal/thermal_core.c
@@ -402,7 +402,7 @@ static void handle_thermal_trip(struct thermal_zone_device 
*tz, int trip)
 }
 
 /**
- * thermal_zone_get_temp() - returns its the temperature of thermal zone
+ * thermal_zone_get_temp() - returns the temperature of a thermal zone
  * @tz: a valid pointer to a struct thermal_zone_device
  * @temp: a valid pointer to where to store the resulting temperature.
  *
-- 
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 11/13] thermal: Make struct thermal_zone_device_ops const

[Sascha Hauer]

Now that the of thermal support no longer changes the
thermal_zone_device_ops it can be const again.

Signed-off-by: Sascha Hauer 
---
 Documentation/thermal/sysfs-api.txt| 2 +-
 drivers/acpi/thermal.c | 2 +-
 drivers/platform/x86/acerhdf.c | 2 +-
 drivers/platform/x86/intel_mid_thermal.c   | 2 +-
 drivers/power/power_supply_core.c  | 2 +-
 drivers/thermal/armada_thermal.c   | 2 +-
 drivers/thermal/db8500_thermal.c   | 2 +-
 drivers/thermal/dove_thermal.c | 2 +-
 drivers/thermal/imx_thermal.c  | 2 +-
 drivers/thermal/int340x_thermal/int3400_thermal.c  | 2 +-
 drivers/thermal/int340x_thermal/int340x_thermal_zone.c | 2 +-
 drivers/thermal/intel_soc_dts_thermal.c| 2 +-
 drivers/thermal/kirkwood_thermal.c | 2 +-
 drivers/thermal/of-thermal.c   | 2 +-
 drivers/thermal/rcar_thermal.c | 2 +-
 drivers/thermal/spear_thermal.c| 2 +-
 drivers/thermal/st/st_thermal.c| 2 +-
 drivers/thermal/thermal_core.c | 2 +-
 drivers/thermal/ti-soc-thermal/ti-thermal-common.c | 2 +-
 drivers/thermal/x86_pkg_temp_thermal.c | 2 +-
 include/linux/thermal.h| 6 +++---
 21 files changed, 23 insertions(+), 23 deletions(-)

diff --git a/Documentation/thermal/sysfs-api.txt 
b/Documentation/thermal/sysfs-api.txt
index 87519cb..bb346a2 100644
--- a/Documentation/thermal/sysfs-api.txt
+++ b/Documentation/thermal/sysfs-api.txt
@@ -33,7 +33,7 @@ temperature) and throttle appropriate devices.
 1.1 thermal zone device interface
 1.1.1 struct thermal_zone_device *thermal_zone_device_register(char *type,
int trips, int mask, void *devdata,
-   struct thermal_zone_device_ops *ops,
+   const struct thermal_zone_device_ops *ops,
const struct thermal_zone_params *tzp,
int passive_delay, int polling_delay))
 
diff --git a/drivers/acpi/thermal.c b/drivers/acpi/thermal.c
index 68bff60..6b11462 100644
--- a/drivers/acpi/thermal.c
+++ b/drivers/acpi/thermal.c
@@ -869,7 +869,7 @@ acpi_thermal_unbind_cooling_device(struct 
thermal_zone_device *thermal,
return acpi_thermal_cooling_device_cb(thermal, cdev, false);
 }
 
-static struct thermal_zone_device_ops acpi_thermal_zone_ops = {
+static const struct thermal_zone_device_ops acpi_thermal_zone_ops = {
.bind = acpi_thermal_bind_cooling_device,
.unbind = acpi_thermal_unbind_cooling_device,
.get_temp = thermal_get_temp,
diff --git a/drivers/platform/x86/acerhdf.c b/drivers/platform/x86/acerhdf.c
index f2ce63c..bae9ca0 100644
--- a/drivers/platform/x86/acerhdf.c
+++ b/drivers/platform/x86/acerhdf.c
@@ -482,7 +482,7 @@ static int acerhdf_get_crit_temp(struct thermal_zone_device 
*thermal,
 }
 
 /* bind callback functions to thermalzone */
-static struct thermal_zone_device_ops acerhdf_dev_ops = {
+static const struct thermal_zone_device_ops acerhdf_dev_ops = {
.bind = acerhdf_bind,
.unbind = acerhdf_unbind,
.get_temp = acerhdf_get_ec_temp,
diff --git a/drivers/platform/x86/intel_mid_thermal.c 
b/drivers/platform/x86/intel_mid_thermal.c
index 0944e83..069d36b 100644
--- a/drivers/platform/x86/intel_mid_thermal.c
+++ b/drivers/platform/x86/intel_mid_thermal.c
@@ -460,7 +460,7 @@ static int read_curr_temp(struct thermal_zone_device *tzd, 
unsigned long *temp)
 }
 
 /* Can't be const */
-static struct thermal_zone_device_ops tzd_ops = {
+static const struct thermal_zone_device_ops tzd_ops = {
.get_temp = read_curr_temp,
 };
 
diff --git a/drivers/power/power_supply_core.c 
b/drivers/power/power_supply_core.c
index 87e2fd1..878cb4e 100644
--- a/drivers/power/power_supply_core.c
+++ b/drivers/power/power_supply_core.c
@@ -509,7 +509,7 @@ static int power_supply_read_temp(struct 
thermal_zone_device *tzd,
return ret;
 }
 
-static struct thermal_zone_device_ops psy_tzd_ops = {
+static const struct thermal_zone_device_ops psy_tzd_ops = {
.get_temp = power_supply_read_temp,
 };
 
diff --git a/drivers/thermal/armada_thermal.c b/drivers/thermal/armada_thermal.c
index 6feb25d..8d9c689 100644
--- a/drivers/thermal/armada_thermal.c
+++ b/drivers/thermal/armada_thermal.c
@@ -183,7 +183,7 @@ static int armada_get_temp(struct thermal_zone_device 
*thermal,
return 0;
 }
 
-static struct thermal_zone_device_ops ops = {
+static const struct thermal_zone_device_ops ops = {
.get_temp = armada_get_temp,
 };
 
diff --git a/drivers/thermal/db8500_thermal.c b/drivers/thermal/db8500_thermal.c
index b3eca71..38d6aab9 100644
--- a/drivers/thermal/db8500_thermal.c
+++ b/drivers/thermal/db8500_thermal.c
@@ -210,7 +210,7 @@ static int db8500_sys_get_crit_temp(struct 

[PATCH 08/13] thermal: streamline get_trend callbacks

[Sascha Hauer]

The .get_trend callback in struct thermal_zone_device_ops has the prototype:

int (*get_trend) (struct thermal_zone_device *, int,
  enum thermal_trend *);

whereas the .get_trend callback in struct thermal_zone_of_device_ops has:

int (*get_trend)(void *, long *);

Streamline both prototypes and add the trip argument to the OF callback
aswell and use enum thermal_trend * instead of an integer pointer.

While the OF prototype may be the better one, this should be decided at
framework level and not on OF level.

Signed-off-by: Sascha Hauer 
---
 drivers/thermal/of-thermal.c   | 11 +-
 drivers/thermal/ti-soc-thermal/ti-thermal-common.c | 25 +++---
 include/linux/thermal.h|  2 +-
 3 files changed, 10 insertions(+), 28 deletions(-)

diff --git a/drivers/thermal/of-thermal.c b/drivers/thermal/of-thermal.c
index 03839df..c84404d 100644
--- a/drivers/thermal/of-thermal.c
+++ b/drivers/thermal/of-thermal.c
@@ -187,24 +187,15 @@ static int of_thermal_get_trend(struct 
thermal_zone_device *tz, int trip,
enum thermal_trend *trend)
 {
struct __thermal_zone *data = tz->devdata;
-   long dev_trend;
int r;
 
if (!data->ops->get_trend)
return -EINVAL;
 
-   r = data->ops->get_trend(data->sensor_data, _trend);
+   r = data->ops->get_trend(data->sensor_data, trip, trend);
if (r)
return r;
 
-   /* TODO: These intervals might have some thresholds, but in core code */
-   if (dev_trend > 0)
-   *trend = THERMAL_TREND_RAISING;
-   else if (dev_trend < 0)
-   *trend = THERMAL_TREND_DROPPING;
-   else
-   *trend = THERMAL_TREND_STABLE;
-
return 0;
 }
 
diff --git a/drivers/thermal/ti-soc-thermal/ti-thermal-common.c 
b/drivers/thermal/ti-soc-thermal/ti-thermal-common.c
index d3a42bf..ade78eb 100644
--- a/drivers/thermal/ti-soc-thermal/ti-thermal-common.c
+++ b/drivers/thermal/ti-soc-thermal/ti-thermal-common.c
@@ -238,7 +238,7 @@ static int ti_thermal_get_trip_temp(struct 
thermal_zone_device *thermal,
return 0;
 }
 
-static int __ti_thermal_get_trend(void *p, long *trend)
+static int __ti_thermal_get_trend(void *p, int trip, enum thermal_trend *trend)
 {
struct ti_thermal_data *data = p;
struct ti_bandgap *bgp;
@@ -251,22 +251,6 @@ static int __ti_thermal_get_trend(void *p, long *trend)
if (ret)
return ret;
 
-   *trend = tr;
-
-   return 0;
-}
-
-/* Get the temperature trend callback functions for thermal zone */
-static int ti_thermal_get_trend(struct thermal_zone_device *thermal,
-   int trip, enum thermal_trend *trend)
-{
-   int ret;
-   long tr;
-
-   ret = __ti_thermal_get_trend(thermal->devdata, );
-   if (ret)
-   return ret;
-
if (tr > 0)
*trend = THERMAL_TREND_RAISING;
else if (tr < 0)
@@ -277,6 +261,13 @@ static int ti_thermal_get_trend(struct thermal_zone_device 
*thermal,
return 0;
 }
 
+/* Get the temperature trend callback functions for thermal zone */
+static int ti_thermal_get_trend(struct thermal_zone_device *thermal,
+   int trip, enum thermal_trend *trend)
+{
+   return __ti_thermal_get_trend(thermal->devdata, trip, trend);
+}
+
 /* Get critical temperature callback functions for thermal zone */
 static int ti_thermal_get_crit_temp(struct thermal_zone_device *thermal,
int *temp)
diff --git a/include/linux/thermal.h b/include/linux/thermal.h
index e9f2863..5c6a589 100644
--- a/include/linux/thermal.h
+++ b/include/linux/thermal.h
@@ -269,7 +269,7 @@ struct thermal_genl_event {
  */
 struct thermal_zone_of_device_ops {
int (*get_temp)(void *, int *);
-   int (*get_trend)(void *, long *);
+   int (*get_trend)(void *, int, enum thermal_trend *);
int (*set_emul_temp)(void *, int);
 };
 
-- 
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 10/13] thermal: of: always set sensor related callbacks

[Sascha Hauer]

Now that the thermal core treats -ENOSYS like the callbacks were
not present at all we no longer have to overwrite the ops during
runtime but instead can always set them and return -ENOSYS if no
sensor is registered.

Signed-off-by: Sascha Hauer 
---
 drivers/thermal/of-thermal.c | 33 +
 1 file changed, 13 insertions(+), 20 deletions(-)

diff --git a/drivers/thermal/of-thermal.c b/drivers/thermal/of-thermal.c
index c84404d..b9c35bd 100644
--- a/drivers/thermal/of-thermal.c
+++ b/drivers/thermal/of-thermal.c
@@ -91,7 +91,7 @@ static int of_thermal_get_temp(struct thermal_zone_device *tz,
 {
struct __thermal_zone *data = tz->devdata;
 
-   if (!data->ops->get_temp)
+   if (!data->ops)
return -EINVAL;
 
return data->ops->get_temp(data->sensor_data, temp);
@@ -178,7 +178,7 @@ static int of_thermal_set_emul_temp(struct 
thermal_zone_device *tz,
struct __thermal_zone *data = tz->devdata;
 
if (!data->ops || !data->ops->set_emul_temp)
-   return -EINVAL;
+   return -ENOSYS;
 
return data->ops->set_emul_temp(data->sensor_data, temp);
 }
@@ -189,8 +189,8 @@ static int of_thermal_get_trend(struct thermal_zone_device 
*tz, int trip,
struct __thermal_zone *data = tz->devdata;
int r;
 
-   if (!data->ops->get_trend)
-   return -EINVAL;
+   if (!data->ops || !data->ops->get_trend)
+   return -ENOSYS;
 
r = data->ops->get_trend(data->sensor_data, trip, trend);
if (r)
@@ -366,6 +366,10 @@ static int of_thermal_get_crit_temp(struct 
thermal_zone_device *tz,
 }
 
 static struct thermal_zone_device_ops of_thermal_ops = {
+   .get_temp = of_thermal_get_temp,
+   .get_trend = of_thermal_get_trend,
+   .set_emul_temp = of_thermal_set_emul_temp,
+
.get_mode = of_thermal_get_mode,
.set_mode = of_thermal_set_mode,
 
@@ -399,13 +403,13 @@ thermal_zone_of_add_sensor(struct device_node *zone,
if (!ops)
return ERR_PTR(-EINVAL);
 
+   if (!ops->get_temp)
+   return ERR_PTR(-EINVAL);
+
mutex_lock(>lock);
tz->ops = ops;
tz->sensor_data = data;
 
-   tzd->ops->get_temp = of_thermal_get_temp;
-   tzd->ops->get_trend = of_thermal_get_trend;
-   tzd->ops->set_emul_temp = of_thermal_set_emul_temp;
mutex_unlock(>lock);
 
return tzd;
@@ -535,9 +539,6 @@ void thermal_zone_of_sensor_unregister(struct device *dev,
return;
 
mutex_lock(>lock);
-   tzd->ops->get_temp = NULL;
-   tzd->ops->get_trend = NULL;
-   tzd->ops->set_emul_temp = NULL;
 
tz->ops = NULL;
tz->sensor_data = NULL;
@@ -845,7 +846,6 @@ int __init of_parse_thermal_zones(void)
 {
struct device_node *np, *child;
struct __thermal_zone *tz;
-   struct thermal_zone_device_ops *ops;
 
np = of_find_node_by_name(NULL, "thermal-zones");
if (!np) {
@@ -869,29 +869,22 @@ int __init of_parse_thermal_zones(void)
continue;
}
 
-   ops = kmemdup(_thermal_ops, sizeof(*ops), GFP_KERNEL);
-   if (!ops)
-   goto exit_free;
-
tzp = kzalloc(sizeof(*tzp), GFP_KERNEL);
-   if (!tzp) {
-   kfree(ops);
+   if (!tzp)
goto exit_free;
-   }
 
/* No hwmon because there might be hwmon drivers registering */
tzp->no_hwmon = true;
 
zone = thermal_zone_device_register(child->name, tz->ntrips,
0, tz,
-   ops, tzp,
+   _thermal_ops, tzp,
tz->passive_delay,
tz->polling_delay);
if (IS_ERR(zone)) {
pr_err("Failed to build %s zone %ld\n", child->name,
   PTR_ERR(zone));
kfree(tzp);
-   kfree(ops);
of_thermal_free_zone(tz);
/* attempting to build remaining zones still */
}
-- 
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 03/13] thermal: trivial: Add missing whitespace in message

[Sascha Hauer]

Commas should be followed by a whitespace.

Signed-off-by: Sascha Hauer 
---
 drivers/thermal/thermal_core.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/thermal/thermal_core.c b/drivers/thermal/thermal_core.c
index 244784f..cecebac 100644
--- a/drivers/thermal/thermal_core.c
+++ b/drivers/thermal/thermal_core.c
@@ -378,7 +378,7 @@ static void handle_critical_trips(struct 
thermal_zone_device *tz,
 
if (trip_type == THERMAL_TRIP_CRITICAL) {
dev_emerg(>device,
- "critical temperature reached(%d C),shutting down\n",
+ "critical temperature reached(%d C), shutting down\n",
  tz->temperature / 1000);
orderly_poweroff(true);
}
-- 
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 09/13] thermal: Allow sensor ops to fail with -ENOSYS

[Sascha Hauer]

The thermal core uses the existence of the .get_temp, .get_trend and
.set_emul_temp to detect whether this operation exists and should be
used or whether it should be emulated in software. This makes problems
for of-thermal which has to modify the struct thermal_zone_device_ops
during runtime whenever a sensor is registered or unregistered.

Let the core test for -ENOSYS from these callbacks and treat it like
if the callbacks were not present.

This allows of-thermal to always set the sensor related callbacks and
to make struct thermal_zone_device_ops const again.

Signed-off-by: Sascha Hauer 
---
 drivers/thermal/thermal_core.c | 24 +---
 1 file changed, 17 insertions(+), 7 deletions(-)

diff --git a/drivers/thermal/thermal_core.c b/drivers/thermal/thermal_core.c
index 81ebc24..0f3d26c 100644
--- a/drivers/thermal/thermal_core.c
+++ b/drivers/thermal/thermal_core.c
@@ -413,13 +413,16 @@ static void handle_thermal_trip(struct 
thermal_zone_device *tz, int trip)
  */
 int thermal_zone_get_temp(struct thermal_zone_device *tz, int *temp)
 {
-   int ret = -EINVAL;
+   int ret;
int count;
int crit_temp = INT_MAX;
enum thermal_trip_type type;
 
-   if (!tz || IS_ERR(tz) || !tz->ops->get_temp)
-   goto exit;
+   if (!tz || IS_ERR(tz))
+   return -EINVAL;
+
+   if (!tz->ops->get_temp)
+   return -ENOSYS;
 
mutex_lock(>lock);
 
@@ -445,7 +448,7 @@ int thermal_zone_get_temp(struct thermal_zone_device *tz, 
int *temp)
}
 
mutex_unlock(>lock);
-exit:
+
return ret;
 }
 EXPORT_SYMBOL_GPL(thermal_zone_get_temp);
@@ -454,10 +457,11 @@ void thermal_zone_device_update(struct 
thermal_zone_device *tz)
 {
int temp, ret, count;
 
-   if (!tz->ops->get_temp)
+   ret = thermal_zone_get_temp(tz, );
+
+   if (ret == -ENOSYS)
return;
 
-   ret = thermal_zone_get_temp(tz, );
if (ret) {
if (ret != -EAGAIN)
dev_warn(>device,
@@ -783,10 +787,16 @@ emul_temp_store(struct device *dev, struct 
device_attribute *attr,
if (kstrtoul(buf, 10, ))
return -EINVAL;
 
-   if (!tz->ops->set_emul_temp) {
+   if (tz->ops->set_emul_temp)
+   ret = tz->ops->set_emul_temp(tz, temperature);
+   else
+   ret = -ENOSYS;
+
+   if (ret == -ENOSYS) {
mutex_lock(>lock);
tz->emul_temperature = temperature;
mutex_unlock(>lock);
+   ret = 0;
} else {
ret = tz->ops->set_emul_temp(tz, temperature);
}
-- 
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 v6 1/3] dt-bindings: Add I2C bindings for mt65xx/mt81xx.

[Eddie Huang]

From: Xudong Chen 

Add devicetree bindings for Mediatek Soc I2C driver.

Signed-off-by: Xudong Chen 
Signed-off-by: Eddie Huang 
---
 .../devicetree/bindings/i2c/i2c-mt6577.txt | 41 ++
 1 file changed, 41 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/i2c/i2c-mt6577.txt

diff --git a/Documentation/devicetree/bindings/i2c/i2c-mt6577.txt 
b/Documentation/devicetree/bindings/i2c/i2c-mt6577.txt
new file mode 100644
index 000..0ce6fa3
--- /dev/null
+++ b/Documentation/devicetree/bindings/i2c/i2c-mt6577.txt
@@ -0,0 +1,41 @@
+* Mediatek's I2C controller
+
+The Mediatek's I2C controller is used to interface with I2C devices.
+
+Required properties:
+  - compatible: value should be either of the following.
+  (a) "mediatek,mt6577-i2c", for i2c compatible with mt6577 i2c.
+  (b) "mediatek,mt6589-i2c", for i2c compatible with mt6589 i2c.
+  (c) "mediatek,mt8127-i2c", for i2c compatible with mt8127 i2c.
+  (d) "mediatek,mt8135-i2c", for i2c compatible with mt8135 i2c.
+  (e) "mediatek,mt8173-i2c", for i2c compatible with mt8173 i2c.
+  - reg: physical base address of the controller and dma base, length of memory
+mapped region.
+  - interrupts: interrupt number to the cpu.
+  - clock-div: the fixed value for frequency divider of clock source in i2c
+module. Each IC may be different.
+  - clocks: clock name from clock manager
+  - clock-names: Must include "main" and "dma", if enable have-pmic need 
include
+"pmic" extra.
+
+Optional properties:
+  - clock-frequency: Frequency in Hz of the bus when transfer, the default 
value
+is 10.
+  - mediatek,have-pmic: platform can control i2c form special pmic side.
+Only mt6589 and mt8135 support this feature.
+  - mediatek,use-push-pull: IO config use push-pull mode.
+
+Example:
+
+   i2c0: i2c@1100d000 {
+   compatible = "mediatek,mt6577-i2c";
+   reg = <0x1100d000 0x70>,
+ <0x11000300 0x80>;
+   interrupts = ;
+   clock-frequency = <40>;
+   mediatek,have-pmic;
+   clock-div = <16>;
+   clocks = <_ck>, <_dma_ck>;
+   clock-names = "main", "dma";
+   };
+
-- 
1.8.1.1.dirty

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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 01/11] coresight-etm4x: Adding CoreSight ETM4x driver

[Ivan T. Ivanov]

On Mon, 2015-04-27 at 09:48 -0600, Mathieu Poirier wrote:
> On 24 April 2015 at 09:41, Ivan T. Ivanov  wrote:
> > On Wed, 2015-04-22 at 16:40 -0600, Mathieu Poirier wrote:
> > 
> > > +static struct amba_id etm4_ids[] = {
> > > +   {   /* ETM 4.0 - Hi6220 board */
> > > +   .id = 0x0003b95d,
> > > +   .mask   = 0x0003,
> > > +   .data   = "ETM 4.0",
> > > +   },
> > > +   {   /* ETM 4.0 - Juno board */
> > > +   .id = 0x000bb95e,
> > > +   .mask   = 0x000b,
> > 
> > Mask looks suspicious.
> 
> Can you please expand the "suspicious" part ?

Well, 'b' part of the mask. I have to admit that
I don't know how this is mapped on this platform.

Regards,
Ivan
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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 v6 3/3] I2C: mediatek: Add driver for MediaTek MT8173 I2C controller

[Eddie Huang]

Add mediatek MT8173 I2C controller driver. Compare to I2C controller
of earlier mediatek SoC, MT8173 fix write-then-read limitation, and
also increase message size to 64kb.

Signed-off-by: Xudong Chen 
Signed-off-by: Liguo Zhang 
Signed-off-by: Eddie Huang 
---
 drivers/i2c/busses/i2c-mt65xx.c | 106 +---
 1 file changed, 77 insertions(+), 29 deletions(-)

diff --git a/drivers/i2c/busses/i2c-mt65xx.c b/drivers/i2c/busses/i2c-mt65xx.c
index 2ecf0d1..c501421 100644
--- a/drivers/i2c/busses/i2c-mt65xx.c
+++ b/drivers/i2c/busses/i2c-mt65xx.c
@@ -33,10 +33,13 @@
 #include 
 #include 
 
+#define I2C_RS_TRANSFER(1 << 4)
 #define I2C_HS_NACKERR (1 << 2)
 #define I2C_ACKERR (1 << 1)
 #define I2C_TRANSAC_COMP   (1 << 0)
 #define I2C_TRANSAC_START  (1 << 0)
+#define I2C_RS_MUL_CNFG(1 << 15)
+#define I2C_RS_MUL_TRIG(1 << 14)
 #define I2C_TIMING_STEP_DIV_MASK   (0x3f << 0)
 #define I2C_TIMING_SAMPLE_COUNT_MASK   (0x7 << 0)
 #define I2C_TIMING_SAMPLE_DIV_MASK (0x7 << 8)
@@ -67,6 +70,9 @@
 #define MAX_MSG_NUM_MT6577 1
 #define MAX_DMA_TRANS_SIZE_MT6577  255
 #define MAX_WRRD_TRANS_SIZE_MT6577 31
+#define MAX_MSG_NUM_MT8173 65535
+#define MAX_DMA_TRANS_SIZE_MT8173  65535
+#define MAX_WRRD_TRANS_SIZE_MT8173 65535
 #define MAX_SAMPLE_CNT_DIV 8
 #define MAX_STEP_CNT_DIV   64
 #define MAX_HS_STEP_CNT_DIV8
@@ -139,6 +145,7 @@ struct mtk_i2c_compatible {
const struct i2c_adapter_quirks *quirks;
unsigned char pmic_i2c;
unsigned char dcm;
+   unsigned char auto_restart;
 };
 
 struct mtk_i2c {
@@ -172,24 +179,42 @@ static const struct i2c_adapter_quirks mt6577_i2c_quirks 
= {
.max_comb_2nd_msg_len = MAX_WRRD_TRANS_SIZE_MT6577,
 };
 
+static const struct i2c_adapter_quirks mt8173_i2c_quirks = {
+   .max_num_msgs = MAX_MSG_NUM_MT8173,
+   .max_write_len = MAX_DMA_TRANS_SIZE_MT8173,
+   .max_read_len = MAX_DMA_TRANS_SIZE_MT8173,
+   .max_comb_1st_msg_len = MAX_DMA_TRANS_SIZE_MT8173,
+   .max_comb_2nd_msg_len = MAX_WRRD_TRANS_SIZE_MT8173,
+};
+
 static const struct mtk_i2c_compatible mt6577_compat = {
.quirks = _i2c_quirks,
.pmic_i2c = 0,
.dcm = 1,
+   .auto_restart = 0,
 };
 
 static const struct mtk_i2c_compatible mt6589_compat = {
.quirks = _i2c_quirks,
.pmic_i2c = 1,
.dcm = 0,
+   .auto_restart = 0,
+};
+
+static const struct mtk_i2c_compatible mt8173_compat = {
+   .quirks = _i2c_quirks,
+   .pmic_i2c = 0,
+   .dcm = 1,
+   .auto_restart = 1,
 };
 
 static const struct of_device_id mtk_i2c_of_match[] = {
{ .compatible = "mediatek,mt6577-i2c", .data = (void *)_compat },
{ .compatible = "mediatek,mt6589-i2c", .data = (void *)_compat },
+   { .compatible = "mediatek,mt8173-i2c", .data = (void *)_compat },
{}
 };
-MODULE_DEVICE_TABLE(of, mtk_i2c_match);
+MODULE_DEVICE_TABLE(of, mtk_i2c_of_match);
 
 static inline void mtk_i2c_writew(u16 value, struct mtk_i2c *i2c, u8 offset)
 {
@@ -343,9 +368,11 @@ static int mtk_i2c_set_speed(struct mtk_i2c *i2c, unsigned 
int clk_src_in_hz)
return 0;
 }
 
-static int mtk_i2c_do_transfer(struct mtk_i2c *i2c, struct i2c_msg *msgs)
+static int mtk_i2c_do_transfer(struct mtk_i2c *i2c, struct i2c_msg *msgs,
+   int num, int left_num)
 {
u16 addr_reg;
+   u16 start_reg;
u16 control_reg;
dma_addr_t rpaddr = 0;
dma_addr_t wpaddr = 0;
@@ -361,6 +388,8 @@ static int mtk_i2c_do_transfer(struct mtk_i2c *i2c, struct 
i2c_msg *msgs)
control_reg |= I2C_CONTROL_RS;
if (i2c->op == I2C_MASTER_WRRD)
control_reg |= I2C_CONTROL_DIR_CHANGE | I2C_CONTROL_RS;
+   if (left_num >= 1)
+   control_reg |= I2C_CONTROL_RS;
mtk_i2c_writew(control_reg, i2c, OFFSET_CONTROL);
 
/* set start condition */
@@ -375,13 +404,13 @@ static int mtk_i2c_do_transfer(struct mtk_i2c *i2c, 
struct i2c_msg *msgs)
mtk_i2c_writew(addr_reg, i2c, OFFSET_SLAVE_ADDR);
 
/* Clear interrupt status */
-   mtk_i2c_writew(I2C_HS_NACKERR | I2C_ACKERR | I2C_TRANSAC_COMP,
-   i2c, OFFSET_INTR_STAT);
+   mtk_i2c_writew(I2C_RS_TRANSFER | I2C_HS_NACKERR | I2C_ACKERR
+   | I2C_TRANSAC_COMP, i2c, OFFSET_INTR_STAT);
mtk_i2c_writew(I2C_FIFO_ADDR_CLR, i2c, OFFSET_FIFO_ADDR_CLR);
 
/* Enable interrupt */
-   mtk_i2c_writew(I2C_HS_NACKERR | I2C_ACKERR | I2C_TRANSAC_COMP,
-   i2c, OFFSET_INTR_MASK);
+   mtk_i2c_writew(I2C_RS_TRANSFER | I2C_HS_NACKERR | I2C_ACKERR
+   | I2C_TRANSAC_COMP, i2c, OFFSET_INTR_MASK);
 
/* Set transfer and transaction len */
if (i2c->op == I2C_MASTER_WRRD) {
@@ -390,7 

[PATCH v2] Thermal cleanups and hardware trip points

[Sascha Hauer]

This series adds support for hardware trip points. It picks up earlier
work from Mikko Perttunen. Mikko implemented hardware trip points as part
of the device tree support. It was suggested back then to move the
functionality to the thermal core instead of putting more code into the
device tree support. This series does exactly that.

The majority of the patches are cleanups and fixes. Only the last two
patches actually implement the hardware trip points.

Note that the hardware trip points are not very well tested currently
and I still have no ready-to-post driver using them. However, Brian
Norris showed interest in these patches, so I am including the patches
in this series nevertheless.

All comments welcome

Changes since v1:
- Use int instead of unsigned long consistently for temperatures
- Instead of misfixing the emulation code add a comment how the
  code is meant
- Add doc entry for .set_trips callback
- initialize prev_low_trip/prev_high_trip properly
- get tz->lock before calling thermal_zone_set_trips()

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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 v6 2/3] I2C: mediatek: Add driver for MediaTek I2C controller

[Eddie Huang]

From: Xudong Chen 

The mediatek SoCs have I2C controller that handle I2C transfer.
This patch include common I2C bus driver.
This driver is compatible with I2C controller on mt65xx/mt81xx.

Signed-off-by: Xudong Chen 
Signed-off-by: Liguo Zhang 
Signed-off-by: Eddie Huang 
---
 drivers/i2c/busses/Kconfig  |   9 +
 drivers/i2c/busses/Makefile |   1 +
 drivers/i2c/busses/i2c-mt65xx.c | 700 
 3 files changed, 710 insertions(+)
 create mode 100644 drivers/i2c/busses/i2c-mt65xx.c

diff --git a/drivers/i2c/busses/Kconfig b/drivers/i2c/busses/Kconfig
index 2255af2..14c7266 100644
--- a/drivers/i2c/busses/Kconfig
+++ b/drivers/i2c/busses/Kconfig
@@ -620,6 +620,15 @@ config I2C_MPC
  This driver can also be built as a module.  If so, the module
  will be called i2c-mpc.
 
+config I2C_MT65XX
+   tristate "MediaTek I2C adapter"
+   depends on ARCH_MEDIATEK || COMPILE_TEST
+   help
+ This selects the MediaTek(R) Integrated Inter Circuit bus driver
+ for MT65xx and MT81xx.
+ If you want to use MediaTek(R) I2C interface, say Y or M here.
+ If unsure, say N.
+
 config I2C_MV64XXX
tristate "Marvell mv64xxx I2C Controller"
depends on MV64X60 || PLAT_ORION || ARCH_SUNXI
diff --git a/drivers/i2c/busses/Makefile b/drivers/i2c/busses/Makefile
index cdf941d..abbf422 100644
--- a/drivers/i2c/busses/Makefile
+++ b/drivers/i2c/busses/Makefile
@@ -60,6 +60,7 @@ obj-$(CONFIG_I2C_JZ4780)  += i2c-jz4780.o
 obj-$(CONFIG_I2C_KEMPLD)   += i2c-kempld.o
 obj-$(CONFIG_I2C_MESON)+= i2c-meson.o
 obj-$(CONFIG_I2C_MPC)  += i2c-mpc.o
+obj-$(CONFIG_I2C_MT65XX)   += i2c-mt65xx.o
 obj-$(CONFIG_I2C_MV64XXX)  += i2c-mv64xxx.o
 obj-$(CONFIG_I2C_MXS)  += i2c-mxs.o
 obj-$(CONFIG_I2C_NOMADIK)  += i2c-nomadik.o
diff --git a/drivers/i2c/busses/i2c-mt65xx.c b/drivers/i2c/busses/i2c-mt65xx.c
new file mode 100644
index 000..2ecf0d1
--- /dev/null
+++ b/drivers/i2c/busses/i2c-mt65xx.c
@@ -0,0 +1,700 @@
+/*
+ * Copyright (c) 2014 MediaTek Inc.
+ * Author: Xudong.chen 
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#define I2C_HS_NACKERR (1 << 2)
+#define I2C_ACKERR (1 << 1)
+#define I2C_TRANSAC_COMP   (1 << 0)
+#define I2C_TRANSAC_START  (1 << 0)
+#define I2C_TIMING_STEP_DIV_MASK   (0x3f << 0)
+#define I2C_TIMING_SAMPLE_COUNT_MASK   (0x7 << 0)
+#define I2C_TIMING_SAMPLE_DIV_MASK (0x7 << 8)
+#define I2C_TIMING_DATA_READ_MASK  (0x7 << 12)
+#define I2C_DCM_DISABLE0x
+#define I2C_IO_CONFIG_OPEN_DRAIN   0x0003
+#define I2C_IO_CONFIG_PUSH_PULL0x
+#define I2C_SOFT_RST   0x0001
+#define I2C_FIFO_ADDR_CLR  0x0001
+#define I2C_DELAY_LEN  0x0002
+#define I2C_ST_START_CON   0x8001
+#define I2C_FS_START_CON   0x1800
+#define I2C_TIME_CLR_VALUE 0x
+#define I2C_TIME_DEFAULT_VALUE 0x0003
+#define I2C_FS_TIME_INIT_VALUE 0x1303
+#define I2C_WRRD_TRANAC_VALUE  0x0002
+#define I2C_RD_TRANAC_VALUE0x0001
+
+#define I2C_DMA_CON_TX 0x
+#define I2C_DMA_CON_RX 0x0001
+#define I2C_DMA_START_EN   0x0001
+#define I2C_DMA_INT_FLAG_NONE  0x
+#define I2C_DMA_CLR_FLAG   0x
+
+#define I2C_DEFAUT_SPEED   10  /* hz */
+#define MAX_FS_MODE_SPEED  40
+#define MAX_HS_MODE_SPEED  340
+#define MAX_MSG_NUM_MT6577 1
+#define MAX_DMA_TRANS_SIZE_MT6577  255
+#define MAX_WRRD_TRANS_SIZE_MT6577 31
+#define MAX_SAMPLE_CNT_DIV 8
+#define MAX_STEP_CNT_DIV   64
+#define MAX_HS_STEP_CNT_DIV8
+
+#define I2C_CONTROL_RS  (0x1 << 1)
+#define I2C_CONTROL_DMA_EN  (0x1 << 2)
+#define I2C_CONTROL_CLK_EXT_EN  (0x1 << 3)
+#define I2C_CONTROL_DIR_CHANGE  (0x1 << 4)
+#define I2C_CONTROL_ACKERR_DET_EN   (0x1 << 5)
+#define I2C_CONTROL_TRANSFER_LEN_CHANGE (0x1 << 6)
+#define I2C_CONTROL_WRAPPER (0x1 << 0)
+
+#define I2C_DRV_NAME   "mt-i2c"
+
+enum DMA_REGS_OFFSET {
+   OFFSET_INT_FLAG = 0x0,
+   OFFSET_INT_EN = 0x04,
+   OFFSET_EN = 

[PATCH v6 0/3] ARM: mediatek: Add driver for Mediatek I2C

[Eddie Huang]

This series is for Mediatek SoCs I2C controller common bus driver.

Earlier MTK SoC ((for example, MT6589, MT8135)) I2C HW has some limitationes.
New generation SoC like MT8173 fix following limitations:

1. Only support one i2c_msg number. One exception is WRRD (write then read)
mode. WRRD can have two i2c_msg numbers.

2. Mediatek I2C controller support WRRD(write then read) mode, in WRRD
mode the Repeat Start will be issued between 2 messages.
In this driver if 2 messages is first write then read, the driver will
combine 2 messages using Write-Read mode so the RS will be issued between
the 2 messages.

3. The max transfer data length is 255 in one message. In WRRD mode, the
max data length of second msg is 31.

MT8135 and MT6589 can control I2C pins on PMIC(MT6397) by setting the i2c
registers in MT8135 side. In this case, driver should set OFFSET_PATH_DIR
bit first, the operation on other registers are still the same.
For now MT6589/MT8135 support this, MT6577/MT6595/MT8127 do not support.
For example, If want to use I2C4/5/6 pins on MT8135 just need to enable
the pinmux, else if want to use I2C pins on PMIC(MT6397) need to add
"mediatek,have-pmic" property in the .dts file of each platform.

This driver is based on 4.1-rc1.

Change in v6:
1. Update binding document not use default clock-frequency as example.
2. Add mtk_i2c_compatible struct and pass hardware capabilities
   through of_device_id
3. Remove some hardware setting in mtk_i2c_do_transfer to mtk_i2c_init_hw
   so just init one time.
4. Correct mtk_i2c_parse_dt don't set default clock bug.

Change in v5:
Apply new i2c_adapter_quirks patch [2]. Change to use dam_map_single to map
dma buffer. Add spinlock to fix race condition. Check of_property_read_u32
return value. Remove I2C_FUNC_10BIT_ADDR capability due to driver not implement.
Add MT8173 I2C driver.

Change in v4:
Modify to support i2c_adapter_quirks base on Wolfram's patch [1].
Remove check transfer size and WRRD combine code. Instead, fill quirk
property and let i2c_check_for_quirks to do the filter.

[1] 
http://lists.infradead.org/pipermail/linux-arm-kernel/2015-January/314804.html
[2] 
http://lists.infradead.org/pipermail/linux-arm-kernel/2015-February/325744.html

Eddie Huang (1):
  I2C: mediatek: Add driver for MediaTek MT8173 I2C controller

Xudong Chen (2):
  dt-bindings: Add I2C bindings for mt65xx/mt81xx.
  I2C: mediatek: Add driver for MediaTek I2C controller

 .../devicetree/bindings/i2c/i2c-mt6577.txt |  41 ++
 drivers/i2c/busses/Kconfig |   9 +
 drivers/i2c/busses/Makefile|   1 +
 drivers/i2c/busses/i2c-mt65xx.c| 748 +
 4 files changed, 799 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/i2c/i2c-mt6577.txt
 create mode 100644 drivers/i2c/busses/i2c-mt65xx.c

--
1.8.1.1.dirty

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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: NFC: CONFIG_NFC_DEBUG not defined

[Valentin Rothberg]

Hi Clément,

thanks for your answer.

On Tue, Apr 28, 2015 at 10:23 AM, Clément Perrochaud
 wrote:
> On Mon, Apr 27, 2015 at 9:03 AM, Valentin Rothberg wrote:
>> Hi Clément,
>>
>> your commit dece45855a8b ("NFC: nxp-nci: Add support for NXP NCI
>> chips") adds the Makefile drivers/nfc/nxp-nci/Makefile with the
>> following line:
>>
>> +ccflags-$(CONFIG_NFC_DEBUG) := -DDEBUG
>>
>> The Kconfig option NFC_DEBUG is not defined so the line turns out to
>> be a nop.  There is another reference in drivers/nfc/Makefile.  Is
>> there a patch queued somewhere to add the option?
>>
>> I found this issue with ./scripts/checkkconfigsymbols.py by diffing
>> v4.0 and v4.1-rc1.
>
> Hi Valentin,
>
> I only included this line because it was present in the upper-level
> Makefile drivers/nfc/Makefile . As far as I know, there is no plan to
> add this option to the configuration.
>
> What would the most sensible solution to this issue be ? Add the NFC
> Debug feature to the configuration ? Remove it altogether ?

DEBUG is not used in any of the files in drivers/nfc/ so I think we
can safely remove the two lines from the Makefiles.  Do you want me to
prepare a patch?

Kind regards,
 Valentin

> Regards,
>
> --
> Clément Perrochaud
>
> Eff'Innov Technologies
> Caen, Aix-En-Provence, Grenoble
>
> Eff'Innov Technologies
> Campus EffiScience
> 2, Esplanade Anton Philips
> 14460 Colombelles, FRANCE
>
> http://www.effinnov.com
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v6 3/3] I2C: mediatek: Add driver for MediaTek MT8173 I2C controller

[Marc Kleine-Budde]

On 04/28/2015 10:31 AM, Eddie Huang wrote:
> Add mediatek MT8173 I2C controller driver. Compare to I2C controller
> of earlier mediatek SoC, MT8173 fix write-then-read limitation, and
> also increase message size to 64kb.
> 
> Signed-off-by: Xudong Chen 
> Signed-off-by: Liguo Zhang 
> Signed-off-by: Eddie Huang 
> ---
>  drivers/i2c/busses/i2c-mt65xx.c | 106 
> +---
>  1 file changed, 77 insertions(+), 29 deletions(-)
> 
> diff --git a/drivers/i2c/busses/i2c-mt65xx.c b/drivers/i2c/busses/i2c-mt65xx.c
> index 2ecf0d1..c501421 100644
> --- a/drivers/i2c/busses/i2c-mt65xx.c
> +++ b/drivers/i2c/busses/i2c-mt65xx.c
[...]

>  static const struct of_device_id mtk_i2c_of_match[] = {
>   { .compatible = "mediatek,mt6577-i2c", .data = (void *)_compat },
>   { .compatible = "mediatek,mt6589-i2c", .data = (void *)_compat },
> + { .compatible = "mediatek,mt8173-i2c", .data = (void *)_compat },
>   {}
>  };
> -MODULE_DEVICE_TABLE(of, mtk_i2c_match);
> +MODULE_DEVICE_TABLE(of, mtk_i2c_of_match);

This should go into the previous patch, as 2/3 will probably not compile
without this change.

Marc

-- 
Pengutronix e.K.  | Marc Kleine-Budde   |
Industrial Linux Solutions| Phone: +49-231-2826-924 |
Vertretung West/Dortmund  | Fax:   +49-5121-206917- |
Amtsgericht Hildesheim, HRA 2686  | http://www.pengutronix.de   |



signature.asc
Description: OpenPGP digital signature

Re: [PATCH 1/2] package: Makefile: ensure $MAKE can use jobserver

[Riku Voipio]

On 24 April 2015 at 21:25, Chris J Arges  wrote:
> When using make deb-pkg, builddeb is called without proper MAKEFLAGS due to 
> the
> script being invoked without '+'. This results in the following message when
> building:
> warning: jobserver unavailable: using -j1. Add `+' to parent make rule
>
> Add the '+' so the make operations can be parallelized.

Looks good, and works fine in my tests.

Reviewed-by: Riku Voipio 

> Signed-off-by: Chris J Arges 
> ---
>  scripts/package/Makefile | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/scripts/package/Makefile b/scripts/package/Makefile
> index 99ca6e7..0dbfae7 100644
> --- a/scripts/package/Makefile
> +++ b/scripts/package/Makefile
> @@ -88,7 +88,7 @@ quiet_cmd_builddeb = BUILDDEB
>
>  deb-pkg: FORCE
> $(MAKE) KBUILD_SRC=
> -   $(call cmd,builddeb)
> +   +$(call cmd,builddeb)
>
>  clean-dirs += $(objtree)/debian/
>
> --
> 1.9.1
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kbuild" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 0/4] extcon: Modify the name of unused external connector

[Chanwoo Choi]

On Tue, Apr 28, 2015 at 12:43 PM, Krzysztof Kozlowski
 wrote:
> On 27.04.2015 21:31, Chanwoo Choi wrote:
>>
>> This patchset alter the unused name of external connector (jig/dock/MHL)
>> as
>> following. The name of jig cable and dock device include the non-standard
>> H/W
>> information. On user-space side, this information are not necessary. The
>> extcon
>> core will support the other method to inform the specific H/W information
>> to
>> kernel device driver and framework. For example, extcon core have the plan
>> to add
>> the notifier chain for USB ID/VBUS pin state. If extcon consumer (kernel
>> device
>> driver and framework) use the notifer chain for USB ID/VBUS, they can get
>> the
>> state of both JIG and USB when JIG-USB-ON cable is attached.
>>
>> And last patch removes the unused 'num_cables' filed on extcon-adc-jack.c.
>>
>> 1. jig cable name
>> - JIG-USB-ON   -->|
>> - JIG-USB-OFF  -->|
>> - JIG-UART-ON  -->|
>> - JIG-UART-OFF -->|--> JIG
>>
>> 2. dock device name
>> - Dock-Smart   -->|
>> - Dock-Desk-->|
>> - Dock-Audio   -->|
>> - Dock-Card-->|--> DOCK
>>
>> 3. MHL-TA cable name
>> - MHL-TA -> TA
>
>
> Hi,
>
> That makes sense but isn't such change a break of interface with user-space?
> The user-space may expect Dock-xxx for Dock.

I guess it's possible. But, the "Dock-{Smart|Desk|Audio}" device name are not
standard. Their name are only used for Samsung Galaxy S3 (releaesd 3.0
kernel) and it is not for mainline kernel.

So, I want to make the standard cable name for mainline kernel and user-space.
The extcon driver will send the event of 'dock' device with specific
external connector which is connected to 'dock' device.

For example, Dock-Smart means the Dock device with MHL cable. When
Dock-Smart is attached, extcon driver will send the two external
connector state of
both 'DOCK' and 'MHL'. So, the user-space process will detect the kind of dock
by catching both 'DOCK' and 'MHL' uevent.

Thanks,
Chanwoo Choi
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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/4] mailbox: add support for System Control and Power Interface(SCPI) protocol

[Sudeep Holla]

On 28/04/15 08:36, Paul Bolle wrote:

Just one nit: a license mismatch.

On Mon, 2015-04-27 at 12:40 +0100, Sudeep Holla wrote:

--- /dev/null
+++ b/drivers/mailbox/scpi_protocol.c



+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms and conditions of the GNU General Public License,
+ * version 2, as published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope it will be useful, but WITHOUT
+ * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
+ * FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License for
+ * more details.
+ *
+ * You should have received a copy of the GNU General Public License along
+ * with this program. If not, see .


This states the license is GPL v2.


+MODULE_LICENSE("GPL");


And, according to include/linux/module.h, this states the license is GPL
v2 or later. So I think either the comment at the top of this file or
the license ident used in the MODULE_LICENSE() macro should be changed.

Likewise for 2/4 and 4/4.


Thanks for pointing this out. Will fix in the next version.

Regards,
Sudeep
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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 06/10] KVM: arm64: guest debug, add SW break point support

[Alex Bennée]

Peter Maydell  writes:

> On 27 April 2015 at 21:04, Christoffer Dall  
> wrote:
>> On Thu, Apr 23, 2015 at 03:26:53PM +0100, Alex Bennée wrote:
>>>
>>> Christoffer Dall  writes:
>>>
>>> > On Tue, Mar 31, 2015 at 04:08:04PM +0100, Alex Bennée wrote:
>>> >> + * just need to report the PC and the HSR values to userspace.
>>> >> + * Userspace may decide to re-inject the exception and deliver it to
>>> >> + * the guest if it wasn't for the host to deal with.
>>> >
>>> > now I'm confused - does userspace setup the guest to receive an
>>> > exception or does it tell KVM to emulate an exception for the guest or
>>> > do we execute the breakpoint without trapping the debug exception?
>>>
>>> I've made it all go through userspace as we may have to translate the
>>> hypervisor visible exception code to what the guest was expecting to see.
>>>
>>
>> ok, so I think you should re-phrase something like:
>>
>> "Userspace may decide that this exception is caused by the guest using
>> debugging itself, and may in that case emulate the guest debug exception
>> in userspace before resuming KVM."
>>
>> But does that really work?  Given that we don't support KVM-TCG
>> migration, this sounds a little strange.  Did we test it?
>
> The QEMU patches have a TODO note at the point where you'd want
> to do this... Design-wise you can do the reinjection in the
> kernel or in userspace (ppc QEMU does this in userspace, for
> instance) because it's pretty much just setting registers to fake
> up the exception-entry into EL1. Code-wise QEMU's ARM code isn't
> set up to do it right now, but it shouldn't be too difficult to
> persuade the TCG exception-entry code to work for this case too.
>
> Does the kernel already have a conveniently implemented "inject
> exception into guest" lump of code? If so it might be less effort
> to do it that way round, maybe.

So you pointed out we can't just re-inject the exceptions we get as we
need to map from things like ESR_ELx_EC_WATCHPT_LOW to
ESR_ELx_EC_WATCHPT_CUR before re-injection.

Of course if it is as simple as modifying the ESR_EL1 register and
returning +ve in the handle_exit path then I can do that but I assumed
if any other wrangling needs doing it should be done in userspace.

>
> -- PMM

-- 
Alex Bennée
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] x86: mce: kexec: switch MCE handler for kexec/kdump

[Baoquan He]

On 04/10/15 at 12:49am, Naoya Horiguchi wrote:
> On Thu, Apr 09, 2015 at 09:05:51PM +0200, Borislav Petkov wrote:
> > On Thu, Apr 09, 2015 at 06:22:02PM +, Luck, Tony wrote:
> > > > Why? Those CPUs are offlined and num_online_cpus() in mce_start() should
> > > > account for that, no?
> > > >
> > > > And if those are offlined, they're very very unlikely to trigger an MCE
> > > > as they're idle and not executing code.
> > > 
> > > Let's step back a few feet and look at the big picture.  There are three 
> > > main classes of machine check
> > > that we might see while trying to run kdump - an remember that all 
> > > machine checks are currently
> > > broadcast, so all cpus whether online or offline will see them
> > > 
> > > 1) Fatal
> > > We have to crash - lose the dump.  Having a new machine check handler 
> > > will make things a bit easier
> > > to see what happened because we won't have any synchronization failed 
> > > messages from the offline
> > > cpus.
> > 
> > But this should not be a problem if kdump path keeps cpu_online_mask
> > uptodate. I'm looking at kdump_nmi_callback() or crash_nmi_callback() or
> > so. Those should clear cpu_online_mask and then mce_start() will work
> > fine on the crashing CPU.
> > 
> > IMHO, of course.
> 
> Sorry, I misread you. With clearing cpu_online_mask in shootdown (not done
> yet,) raising tolerance should work without timeout message.
> So I think you are right.

Hi Naoya,

Thanks for great efforts you have made on this issue.

I am trying to catch up, and have read mails in this thread.
Please also add me to CC list when you post a new version. I would like to
review it.

Thanks
Baoquan

> 
> > > 2) Execution path recoverable (SRAR in SDM parlance).
> > > Also going to be fatal (kdump is all running in ring0, and we can't 
> > > recover from errors in ring 0). Cleaner
> > > messages as above. Potentially in the future we might be able to make the 
> > > kdump machine check handler
> > > actually recover by just skipping a page - if the location of the error 
> > > was in the old kernel image.
> > > 
> > > 3) Non-execution path recoverable (SRAO in SDM)
> > > We ought to be able to keep kdump running if this happens - the "AO" 
> > > stands for "action optional",
> > > so we are going to choose to not take an action. Wherever the error was, 
> > > it won't affect correctness
> > > of execution of the current context.
> > 
> > Those could be simply made to go to dmesg during kdump, i.e. decouple
> > any MCE consumers. And we do that now anyway, i.e. box without mcelog or
> > some other ras daemon running.
> > 
> > So we could reuse the normal handler - we just need to do some tweaking
> > first... AFAICT, of course. I believe in that endeavor, the devil will
> > be in the detail.
> 
> OK, I'll try this approach with updating cpu_online_mask.
> 
> Thanks,
> Naoya Horiguchi--
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v6 3/3] I2C: mediatek: Add driver for MediaTek MT8173 I2C controller

[Eddie Huang]

Hi Marc,

On Tue, 2015-04-28 at 10:36 +0200, Marc Kleine-Budde wrote:
> On 04/28/2015 10:31 AM, Eddie Huang wrote:
> > Add mediatek MT8173 I2C controller driver. Compare to I2C controller
> > of earlier mediatek SoC, MT8173 fix write-then-read limitation, and
> > also increase message size to 64kb.
> > 
> > Signed-off-by: Xudong Chen 
> > Signed-off-by: Liguo Zhang 
> > Signed-off-by: Eddie Huang 
> > ---
> >  drivers/i2c/busses/i2c-mt65xx.c | 106 
> > +---
> >  1 file changed, 77 insertions(+), 29 deletions(-)
> > 
> > diff --git a/drivers/i2c/busses/i2c-mt65xx.c 
> > b/drivers/i2c/busses/i2c-mt65xx.c
> > index 2ecf0d1..c501421 100644
> > --- a/drivers/i2c/busses/i2c-mt65xx.c
> > +++ b/drivers/i2c/busses/i2c-mt65xx.c
> [...]
> 
> >  static const struct of_device_id mtk_i2c_of_match[] = {
> > { .compatible = "mediatek,mt6577-i2c", .data = (void *)_compat },
> > { .compatible = "mediatek,mt6589-i2c", .data = (void *)_compat },
> > +   { .compatible = "mediatek,mt8173-i2c", .data = (void *)_compat },
> > {}
> >  };
> > -MODULE_DEVICE_TABLE(of, mtk_i2c_match);
> > +MODULE_DEVICE_TABLE(of, mtk_i2c_of_match);
> 
> This should go into the previous patch, as 2/3 will probably not compile
> without this change.
> 
That's right, my mistake, should be in 2/3. 

Eddie



--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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]Add support for DS28AE00 sequence to w1-therm

[Geert Uytterhoeven]

On Mon, Apr 27, 2015 at 8:43 PM, Evgeniy Polyakov  wrote:
> 27.04.2015, 16:32, "Matt Campbell" :
>> This patch provides support for the DS28AE00 digital thermometer.
>
> Greg, please pull it into you tree, everything looks good to me

Except that the component name seems to be misspelled in all but two
places?

http://www.maximintegrated.com/en/pst/run.mvp?q=DS28AE00

SEARCH RESULTS
[empty]
Did you mean: DS28EA00

Gr{oetje,eeting}s,

Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] tick-broadcast: Fix the printing of broadcast masks

[Preeti U Murthy]

Today the number of bits of the broadcast masks that is output into
/proc/timer_list is sizeof(unsigned long). This means that on machines
with larger number of CPUs, the bitmasks of CPUs beyond this range do
not appear.

Fix this by using bitmap printing through "%*pb" instead, so as to
output the broadcast masks for the range of nr_cpu_ids into
/proc/timer_list.

Signed-off-by: Preeti U Murthy 
---

 kernel/time/timer_list.c |8 
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/kernel/time/timer_list.c b/kernel/time/timer_list.c
index c82b03c..1afc726 100644
--- a/kernel/time/timer_list.c
+++ b/kernel/time/timer_list.c
@@ -269,11 +269,11 @@ static void timer_list_show_tickdevices_header(struct 
seq_file *m)
 {
 #ifdef CONFIG_GENERIC_CLOCKEVENTS_BROADCAST
print_tickdevice(m, tick_get_broadcast_device(), -1);
-   SEQ_printf(m, "tick_broadcast_mask: %08lx\n",
-  cpumask_bits(tick_get_broadcast_mask())[0]);
+   SEQ_printf(m, "tick_broadcast_mask: %*pb\n",
+  cpumask_pr_args(tick_get_broadcast_mask()));
 #ifdef CONFIG_TICK_ONESHOT
-   SEQ_printf(m, "tick_broadcast_oneshot_mask: %08lx\n",
-  cpumask_bits(tick_get_broadcast_oneshot_mask())[0]);
+   SEQ_printf(m, "tick_broadcast_oneshot_mask: %*pb\n",
+  cpumask_pr_args(tick_get_broadcast_oneshot_mask()));
 #endif
SEQ_printf(m, "\n");
 #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 0/4] ARM64: add SCPI mailbox protocol, clock and CPUFreq support

[Sudeep Holla]

Hi Tixy,

On 27/04/15 19:11, Jon Medhurst (Tixy) wrote:

On Mon, 2015-04-27 at 12:40 +0100, Sudeep Holla wrote:

Hi,

This patch series adds support for:
1. SCPI(System Control and Power Interface) mailbox protocol
   driver.


Is there a public document with the final protocol specification?
I have spotted an inconsistency between driver and a draft doc I have
but before commenting on things like that it would be good to have the
final version of the document instead.



Thanks for having a look at the driver. I am already chasing this up
with the concerned team to check when will this be made public. IIUC you
do have a non-confidential (preliminary)version of document. So you can
comment on the inconsistency you have observed and I can check if it's
issue with the code or the document.

Regards,
Sudeep
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH] perf: probe: avoid segfault if passed with ''.

[Wang Nan]

Since parse_perf_probe_point() deals with a user passed argument, we
should not assume it to be a valid string.

Without this patch, if pass '' to perf probe, a segfault raises:

 $ perf probe -a ''
 Segmentation fault

This patch checks argument of parse_perf_probe_point() before
string processing.

After this patch:

 $ perf probe -a ''

  usage: perf probe [] 'PROBEDEF' ['PROBEDEF' ...]
 or: perf probe [] --add 'PROBEDEF' [--add 'PROBEDEF' ...]
 ...

Signed-off-by: Wang Nan 
---
 tools/perf/util/probe-event.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/tools/perf/util/probe-event.c b/tools/perf/util/probe-event.c
index d8bb616..d05b77c 100644
--- a/tools/perf/util/probe-event.c
+++ b/tools/perf/util/probe-event.c
@@ -1084,6 +1084,8 @@ static int parse_perf_probe_point(char *arg, struct 
perf_probe_event *pev)
 *
 * TODO:Group name support
 */
+   if (!arg)
+   return -EINVAL;
 
ptr = strpbrk(arg, ";=@+%");
if (ptr && *ptr == '=') {   /* Event name */
-- 
1.8.3.4

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v2 2/2] cpufreq: powernv: Register for OCC related opal_message notification

[Viresh Kumar]

On 28 April 2015 at 13:48, Shilpasri G Bhat
 wrote:
> My bad I haven't added explicit comment to state reason behind this change.
>
> I modified the definition of *throttle_check() to match the function 
> definition
> to be called via smp_call() instead of adding an additional wrapper around
> *throttle_check().
>
> OCC is a chip entity and any local throttle state changes should be associated
> to cpus belonging to that chip. The *throttle_check() will read the core
> register PMSR to verify throttling. All the cores in a chip will have the same
> throttled state as they are managed by a the same OCC in that chip.
>
> smp_call() is required to ensure *throttle_check() is called on a cpu 
> belonging
> to the chip for which we have received throttled/unthrottled notification. We
> could be handling throttled/unthrottled notification of 'chip1' in 'chip2' so 
> do
> an smp_call() on 'chip1'.

Okay. Lets talk about the code that is already present in mainline. Isn't that
suffering from this issue ? If yes, then you need to bugfix that separately.

> We are irq_disabled in powernv_cpufreq_occ_msg() the notification handler.
> Thus the use of kworker to do an smp_call and restore policy->cur.
>
> OCC_RESET is global event it affects frequency of all chips. Pmax capping is
> local event, it affects the frequency of a chip.
>

>> That's a lot. I am not an expert here and so really can't comment on
>> the internals of ppc. But, is it patch solving a single problem ? I don't
>> know, I somehow got the impression that it can be split into multiple
>> (smaller & review-able) patches. Only if it makes sense. Your call.
>
> All the changes introduced in this patch is centered around opal_message
> notification handler powernv_cpufreq_occ_msg(). I can split it into multiple
> patches but it all will be relevant only to solve the above problem.

And that's what I meant here. Yes, this all is solving a central problem, but
a patch must be divided into separate, independently working, entities.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] firmware: dmi_scan: Simplified displayed version

[subscivan]

On 28.04.15 11:15, Jean Delvare wrote:

Hi Ivan,

On Mon, 27 Apr 2015 19:10:05 +0300, subscivan wrote:

On 21.04.15 15:45, Jean Delvare wrote:

The trailing .x adds no information for the reader, and if anyone
tries to parse that line, this is more work as they have 3 different
formats to handle instead of 2. Plus, this makes backporting fixes
harder.

Signed-off-by: Jean Delvare 
Fixes: 95be58df74a5 ("firmware: dmi_scan: Use full dmi version for SMBIOS3")
Cc: Ivan Khoronzhuk 
---
It doesn't actually "fix" the mentioned commit, as there is no bug, but
if anyone backports dmi-related commits, picking this one will make
his/her life easier.

   drivers/firmware/dmi_scan.c |5 ++---
   1 file changed, 2 insertions(+), 3 deletions(-)

--- linux-4.0.orig/drivers/firmware/dmi_scan.c  2015-04-17 10:35:56.959512401 
+0200
+++ linux-4.0/drivers/firmware/dmi_scan.c   2015-04-17 10:38:02.090156803 
+0200
@@ -506,9 +506,8 @@ static int __init dmi_present(const u8 *
if (dmi_walk_early(dmi_decode) == 0) {
if (smbios_ver) {
dmi_ver = smbios_ver;
-   pr_info("SMBIOS %d.%d%s present.\n",
-   dmi_ver >> 8, dmi_ver & 0xFF,
-   (dmi_ver < 0x0300) ? "" : ".x");
+   pr_info("SMBIOS %d.%d present.\n",
+  dmi_ver >> 8, dmi_ver & 0xFF);
} else {
dmi_ver = (buf[14] & 0xF0) << 4 |
   (buf[14] & 0x0F);



The main idea here was that dmi version after 3 is in format x.x.x
And after v3 it's expected to see such format. But in case if (I hope that
will never happen) firmware has 32 bit version of SMBIOS3 the table doesn't

Oh, it will happen. Given that the v3 entry point format is
incompatible with the v2 entry point format, I expect (at least x86)
vendors to provide both whenever possible for several years to come, for
compatibility reasons. Our code scanning the memory for SMBIOS entry
points will pick the first one it finds (both in the kernel and in
dmidecode). I hope that vendors will be smart enough to place the v3
entry point first, but I expect to be disappointed by some.


have fields to hold revision number, that's why, to warn user about trimming
of revision the .x was added. IMHO the 3.2.x is more informative then 3.2
3.2 can be wrongly interpreted as 3.2.0. If script (or else) needs to see
version in usual way, it can parse tables recently exposed.

I don't think so. 3.2.x and 3.2 mean exactly the same, none if more
informative than the other. For example if I say "openSUSE 13.2 is
based on kernel 3.16", that doesn't mean exactly kernel version 3.16.0.
Same here.


But if you insist on 3.2, maybe it be good to warn user in some way like
printing pr_info("SMBIOS doc revision cannot be accessible");

That would be replacing a bit of over-engineering with another. No,
thanks.

The doc revision number has been omitted so far because the
specification made no room to carry it. People and tools are used to
that. And to be honest I'm surprised they added it in v3. The revision
number is not so interesting IMHO, I never missed it in dmidecode.
Thankfully the additions to the specification are incremental and
almost always backward compatible so we seldom need to make decoding
decisions based on the version. Whenever a significant change happens,
at least the minor version number should be incremented. Bumps of the
doc revision should only translate to new enumerated values and maybe
new fields, all of which can be implemented unconditionally.

I suspect that they added a field for the doc revision number in the v3
entry point simply to avoid a mistake that has happened a couple times
in the past where vendors would attempt to encode the minor version
_and_ the doc revision in the minor version byte. When the SMBIOS 2.3.1
specification was released, a number of vendors encoded the version as
2.31 instead of 2.3. This was the first time the doc revision number
was used AFAIK and apparently some vendors failed to understand how to
handle it. Maybe the DMTF took note back then that, if the entry point
format ever changed, they should include a separate field for the doc
revision number to clear the confusion.

But what I do expect now is the opposite: the doc revision number
doesn't really matter, so I wouldn't be surprised if in the future some
vendors don't set it or forget to bump it on BIOS update. So we can
report it where available but I don't plan to make any use of it.

Anyway, my point here is: let's keep things simple and just report what
is encoded in the entry point. If it's a v3 entry point, the doc
revision is there, print it; if it's a v2 entry point, it's not, don't
print it. Easy as that.



Sorry, but you probably meant if it's a 64-bit version of v3
print it, if it's a 32-bit v3 

Re: [PATCH v9 07/17] h8300: miscellaneous functions

[Yoshinori Sato]

At Mon, 27 Apr 2015 10:57:10 +0200,
Arnd Bergmann wrote:
> 
> On Monday 27 April 2015 14:35:14 Yoshinori Sato wrote:
> > +void dma_sync_single_for_device(struct device *dev, dma_addr_t handle,
> > +   size_t size, enum dma_data_direction dir)
> > +{
> > +}
> > +EXPORT_SYMBOL(dma_sync_single_for_device);
> > +
> > +void dma_sync_sg_for_device(struct device *dev, struct scatterlist *sg,
> > +   int nents, enum dma_data_direction dir)
> > +{
> > +   int i;
> > +
> > +   for (i = 0; i < nents; sg++, i++)
> > +   dma_sync_single_for_device(dev, sg->dma_address,
> > +  sg->length, dir);
> > +}
> > +EXPORT_SYMBOL(dma_sync_sg_for_device);
> > +
> > +dma_addr_t dma_map_single(struct device *dev, void *addr, size_t size,
> > + enum dma_data_direction dir)
> > +{
> > +   dma_addr_t handle = virt_to_bus(addr);
> > +
> > +   dma_sync_single_for_device(dev, handle, size, dir);
> > +   return handle;
> > +}
> > +EXPORT_SYMBOL(dma_map_single);
> 
> 
> As this all doesn't do anything, and your dma-mapping.h header explains
> that the architecture is cache-coherent, just remove these functions,
> and replace them with empty 'static inline' helpers in that header.
> 
>   Arnd
> 

OK.
This DMA support part too old.
I will rewriting.
Thanks.

-- 
Yoshinori Sato

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v10 0/10] iommu/vt-d: Fix intel vt-d faults in kdump kernel

[Baoquan He]

On 04/24/15 at 04:49pm, Dave Young wrote:
> On 04/24/15 at 04:35pm, Baoquan He wrote:
> > On 04/24/15 at 04:25pm, Dave Young wrote:
> > > Hi, Baoquan
> > > 
> > > > I support this patchset.
> > > > 
> > > > We should not fear oldmem since reserved crashkernel region is similar.
> > > > No one can guarantee that any crazy code won't step into crashkernel
> > > > region just because 1st kernel says it's reversed for kdump kernel. Here
> > > > the root table and context tables are also not built to allow legal code
> > > > to danamge. Both of them has the risk to be corrupted, for trying our
> > > > best to get a dumped vmcore the risk is worth being taken.
> > > 
> > > old mem is mapped in 1st kernel so compare with the reserved crashkernel
> > > they are more likely to be corrupted. they are totally different. 
> > 
> > Could you tell how and why they are different? Wrong code will choose
> > root tables and context tables to danamge when they totally lose
> > control?
> 
> iommu will map io address to system ram, right? not to reserved ram, but
> yes I'm assuming the page table is right, but I was worrying they are 
> corrupted
> while kernel panic is happening.

OK, I think we may need to think more about the old context tables
reuse. Currently dmar faults will cause error or warning message,
occasionally will cause system with iommu hang in kdump kernel. I don't
know what will happen if old root tables or context tables are corrupted
by evil code. For kdump kernel which use the similar mechanism there's a
verification. When load kdump kernel into reserved crashkernel region a
sha256 sum is calculated, then verify it when jump into kdump kernel
after panic. If corrupted context tables will bring worse result, then
we need consider giving it up and change back to the old way and try
to dump though there's error message.

Hi Zhenhua,

I don't know what's your plan about verification whether old root tables
or old context tables are corrupted. Or have you experimented that what
will happen if old tables are corrupted on purpose.

I am fine if you just put this in a TODO list since that's truly in a
rare case. But it maybe necessary to tell it in patch log.

Thanks
Baoquan

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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 0/3] leds: blink resolution improvements

[Jacek Anaszewski]

Hi Stas,

Have you tested it? I tried it with Samsung M0 board and
my leds-aat1290 driver. It didn't work well. And for small delay
intervals it will not have a chance to work reliably with all drivers,
especially the ones which use mutex in their brightness_set op,
since mutex can sleep.

I am afraid that we have to stay with what we have currently.

On 04/27/2015 07:08 PM, Stas Sergeev wrote:

Hello.

The following patches improve the precision of led
timer trigger and add the delay unit control.
That allows to make PWM brightness control with timer
trigger.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/




--
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 v2] builddeb: parallelize debug module installation

[Riku Voipio]

On 27 April 2015 at 19:43, Chris J Arges  wrote:
> When building the dbg package, we use a large 'for module in $(find' loop that
> can be easily parallelized by using 'find | xargs'. This patch modifies this
> loop to use the later paradigm.
>
> In addition, ensure we add '-n1 -P0' to xargs to run as many processes as
> possible.
>
> Signed-off-by: Chris J Arges 
> ---
>  scripts/package/builddeb | 15 ---
>  1 file changed, 8 insertions(+), 7 deletions(-)
>
> diff --git a/scripts/package/builddeb b/scripts/package/builddeb
> index 88dbf23..538f829 100755
> --- a/scripts/package/builddeb
> +++ b/scripts/package/builddeb
> @@ -152,16 +152,17 @@ if grep -q '^CONFIG_MODULES=y' $KCONFIG_CONFIG ; then
> rmdir "$tmpdir/lib/modules/$version"
> fi
> if [ -n "$BUILD_DEBUG" ] ; then
> -   for module in $(find $tmpdir/lib/modules/ -name *.ko -printf 
> '%P\n'); do
> -   module=lib/modules/$module
> -   mkdir -p $(dirname $dbg_dir/usr/lib/debug/$module)
> +   find $tmpdir/lib/modules/ -name *.ko -printf '%P\n' | xargs 
> -n1 -P0 -I {} sh -c '

I would go with -P`getconf _NPROCESSORS_ONLN`. There can be thousands
of modules (allmodconfig will make 4500).

> +   mkdir -p $(dirname 
> '"$dbg_dir"'/usr/lib/debug/lib/modules/$1);'"
> # only keep debug symbols in the debug file
> -   $OBJCOPY --only-keep-debug $tmpdir/$module 
> $dbg_dir/usr/lib/debug/$module
> +   $OBJCOPY --only-keep-debug $tmpdir/lib/modules/{} \
> +   $dbg_dir/usr/lib/debug/lib/modules/{};
> # strip original module from debug symbols
> -   $OBJCOPY --strip-debug $tmpdir/$module
> +   $OBJCOPY --strip-debug $tmpdir/lib/modules/{};
> # then add a link to those
> -   $OBJCOPY 
> --add-gnu-debuglink=$dbg_dir/usr/lib/debug/$module $tmpdir/$module
> -   done
> +   $OBJCOPY 
> --add-gnu-debuglink=$dbg_dir/usr/lib/debug/lib/modules/{} \
> +   $tmpdir/lib/modules/{};
> +   " -- {}
> fi
>  fi
>
> --
> 1.9.1
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kbuild" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/