[PATCH V1] regulator: da9211: fix unmatched of_node and add gpio control

[James Ban]

This is a patch for fixing unmatched of_node and adding gpio control.

Signed-off-by: James Ban 
---

This patch is relative to linux-next repository tag next-20150113.

Changes in V1:
- fix unmatched of_node.
- add gpio control for buck eanble/disable.

 .../devicetree/bindings/regulator/da9211.txt   |   24 +-
 drivers/regulator/da9211-regulator.c   |   49 ++--
 drivers/regulator/da9211-regulator.h   |1 +
 include/linux/regulator/da9211.h   |9 
 4 files changed, 79 insertions(+), 4 deletions(-)

diff --git a/Documentation/devicetree/bindings/regulator/da9211.txt 
b/Documentation/devicetree/bindings/regulator/da9211.txt
index 240019a..b53a246 100644
--- a/Documentation/devicetree/bindings/regulator/da9211.txt
+++ b/Documentation/devicetree/bindings/regulator/da9211.txt
@@ -11,6 +11,12 @@ Required properties:
   BUCKA and BUCKB.
 
 Optional properties:
+- bucka-uses-gpio: BUCKA can be controlled by gpio.
+- bucka-enable-platform-gpio: platform gpio for control of BUCKA.
+- bucka-enable-init-state: initial state of gpio for BUCKA
+- buckb-uses-gpio: BUCKB can be controlled by gpio.
+- buckb-enable-platform-gpio: platform gpio for control of BUCKB.
+- buckb-enable-init-state: initial state of gpio for BUCKB
 - Any optional property defined in regulator.txt
 
 Example 1) DA9211
@@ -20,6 +26,14 @@ Example 1) DA9211
reg = <0x68>;
interrupts = <3 27>;
 
+   bucka-uses-gpio;
+   bucka-enable-platform-gpio = <&gpio 27 0>;
+   bucka-enable-init-state = <0>;
+
+   buckb-uses-gpio;
+   buckb-enable-platform-gpio = <&gpio 17 0>;
+   buckb-enable-init-state = <0>;
+
regulators {
BUCKA {
regulator-name = "VBUCKA";
@@ -38,12 +52,20 @@ Example 1) DA9211
};
};
 
-Example 2) DA92113
+Example 2) DA9213
pmic: da9213@68 {
compatible = "dlg,da9213";
reg = <0x68>;
interrupts = <3 27>;
 
+   bucka-uses-gpio;
+   bucka-enable-platform-gpio = <&gpio 27 0>;
+   bucka-enable-init-state = <0>;
+
+   buckb-uses-gpio;
+   buckb-enable-platform-gpio = <&gpio 17 0>;
+   buckb-enable-init-state = <0>;
+
regulators {
BUCKA {
regulator-name = "VBUCKA";
diff --git a/drivers/regulator/da9211-regulator.c 
b/drivers/regulator/da9211-regulator.c
index c78d210..2d9a38a 100644
--- a/drivers/regulator/da9211-regulator.c
+++ b/drivers/regulator/da9211-regulator.c
@@ -24,6 +24,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include "da9211-regulator.h"
@@ -248,7 +249,7 @@ static struct da9211_pdata *da9211_parse_regulators_dt(
 {
struct da9211_pdata *pdata;
struct device_node *node;
-   int i, num, n;
+   int i, num, n, gpio;
 
node = of_get_child_by_name(dev->of_node, "regulators");
if (!node) {
@@ -276,10 +277,42 @@ static struct da9211_pdata *da9211_parse_regulators_dt(
continue;
 
pdata->init_data[n] = da9211_matches[i].init_data;
-
+   pdata->reg_node[n] = da9211_matches[i].of_node;
n++;
}
 
+   if (of_get_property(dev->of_node, "bucka-uses-gpio", NULL)) {
+   gpio = of_get_named_gpio(dev->of_node,
+   "bucka-enable-platform-gpio", 0);
+   if (!gpio_is_valid(gpio)) {
+   dev_err(dev, "invalid gpio: %d\n", gpio);
+   return ERR_PTR(-EINVAL);
+   }
+   pdata->buck_data[0].gpio_ren = gpio;
+
+   if (of_property_read_u32(dev->of_node,
+   "bucka-enable-init-state",
+   &pdata->buck_data[0].ena_init_state)) {
+   pdata->buck_data[0].ena_init_state = 0;
+   }
+   }
+
+   if (of_get_property(dev->of_node, "buckb-uses-gpio", NULL)) {
+   gpio = of_get_named_gpio(dev->of_node,
+   "buckb-enable-platform-gpio", 0);
+   if (!gpio_is_valid(gpio)) {
+   dev_err(dev, "invalid gpio: %d\n", gpio);
+   return ERR_PTR(-EINVAL);
+   }
+   pdata->buck_data[1].gpio_ren = gpio;
+
+   if (of_property_read_u32(dev->of_node,
+   "buckb-enable-init-state",
+   &pdata->buck_data[1].ena_init_state)) {
+   pdata->buck_data[1].ena_init_state = 0;
+   }
+   }
+
return pdata;
 }
 #else
@@ -364,7 +397,17 @@ static int da9211_regulator_init(struct da9211 *chip)
config.dev = chip->dev;

[PATCH v2] hwmon: (ina2xx) Add ina231 compatible string

[Kevin Hilman]

From: Kevin Hilman 

Add support for "ina231" as compatible string, and update
Documentation and Kconfig accordingly.

Tested with the Exynos5422-based odroid-xu3 board which has on-board
INA231 sensors.

Signed-off-by: Kevin Hilman 
---
 Documentation/hwmon/ina2xx | 9 +
 drivers/hwmon/Kconfig  | 4 ++--
 drivers/hwmon/ina2xx.c | 1 +
 3 files changed, 12 insertions(+), 2 deletions(-)

diff --git a/Documentation/hwmon/ina2xx b/Documentation/hwmon/ina2xx
index 4223c2d3b508..c2f838f65ee4 100644
--- a/Documentation/hwmon/ina2xx
+++ b/Documentation/hwmon/ina2xx
@@ -26,6 +26,12 @@ Supported chips:
 Datasheet: Publicly available at the Texas Instruments website
http://www.ti.com/
 
+  * Texas Instruments INA231
+Prefix: 'ina231'
+Addresses: I2C 0x40 - 0x4f
+Datasheet: Publicly available at the Texas Instruments website
+   http://www.ti.com/
+
 Author: Lothar Felten 
 
 Description
@@ -44,6 +50,9 @@ The INA226 monitors both a shunt voltage drop and bus supply 
voltage.
 The INA230 is a high or low side current shunt and power monitor with an I2C
 interface. The INA230 monitors both a shunt voltage drop and bus supply 
voltage.
 
+The INA231 is a high or low side current shunt and power monitor with an I2C
+interface. The INA230 monitors both a shunt voltage drop and bus supply 
voltage.
+
 The shunt value in micro-ohms can be set via platform data or device tree.
 Please refer to the Documentation/devicetree/bindings/i2c/ina2xx.txt for 
bindings
 if the device tree is used.
diff --git a/drivers/hwmon/Kconfig b/drivers/hwmon/Kconfig
index 6529c09c46f0..408fb6f5f055 100644
--- a/drivers/hwmon/Kconfig
+++ b/drivers/hwmon/Kconfig
@@ -1420,8 +1420,8 @@ config SENSORS_INA2XX
tristate "Texas Instruments INA219 and compatibles"
depends on I2C
help
- If you say yes here you get support for INA219, INA220, INA226, and
- INA230 power monitor chips.
+ If you say yes here you get support for INA219, INA220, INA226,
+ INA230, and INA231 power monitor chips.
 
  The INA2xx driver is configured for the default configuration of
  the part as described in the datasheet.
diff --git a/drivers/hwmon/ina2xx.c b/drivers/hwmon/ina2xx.c
index e01feba909c3..8c4a29bd2eaf 100644
--- a/drivers/hwmon/ina2xx.c
+++ b/drivers/hwmon/ina2xx.c
@@ -287,6 +287,7 @@ static const struct i2c_device_id ina2xx_id[] = {
{ "ina220", ina219 },
{ "ina226", ina226 },
{ "ina230", ina226 },
+   { "ina231", ina226 },
{ }
 };
 MODULE_DEVICE_TABLE(i2c, ina2xx_id);
-- 
2.1.3

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

Re: [PATCH] hwmon: (ina2xx) Add ina231 compatible string

[Kevin Hilman]

Guenter Roeck  writes:

> On Wed, Jan 14, 2015 at 03:57:32PM -0800, Kevin Hilman wrote:
>> From: Kevin Hilman 
>> 
>> Add support for "ina231" as compatible string.
>> 
>> Tested with the Exynos5422-based odroid-xu3 board which has on-board
>> INA231 sensors.
>> 
>> Signed-off-by: Kevin Hilman 
>
> Hi Kevin,
>
> can you also update Documentation/hwmon/ina2xx and 
> Documentation/hwmon/Kconfig ?
>

Sure... coming right up.

Kevin

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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: mach-versatile: core: Remove unused function

[Olof Johansson]

On Wed, Jan 14, 2015 at 12:53:07PM +0100, Linus Walleij wrote:
> On Sat, Jan 3, 2015 at 5:52 PM, Rickard Strandqvist
>  wrote:
> 
> > Remove the function versatile_leds_event() that is not used anywhere.
> >
> > This was partially found by using a static code analysis program called 
> > cppcheck.
> >
> > Signed-off-by: Rickard Strandqvist 
> 
> Reviewed-by: Linus Walleij 
> 
> That's right, the code was made redundant in
> commit e031cd513ec2ff661465dc1198220075719e72d1
> "ARM: mach-realview and mach-versatile: retire custom LED code"
> 
> ARM SoC folks: I suggest you apply this patch directly to your cleanup
> branch.

Thanks, applied with a minor tweak to the patch subject.


-Olof
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] workqueue: update numa affinity info at node hotplug

[Lai Jiangshan]

On 01/14/2015 09:57 PM, Tejun Heo wrote:
> Hello, Lai.
> 
> On Wed, Jan 14, 2015 at 10:47:16AM +0800, Lai Jiangshan wrote:
>>> Even if that involves slightly more code, that's the right thing to do at 
>>> this point.
>>
>> Right, but in currently, the workqueue will be the only user, and I don't 
>> known
>> asking who to do it, so I may keep it in the workqueue.c.
> 
> The problem is that working around this in workqueue effectively hides
> what needs to be actively looked upon and decided.  It curently isn't
> currently defined even when such mappings can change or for which
> cpus?  Are all offline cpus up for grabs or just !present ones?  These
> are questions which can only be answered / determined from NUMA side
> and the sooner we deal with this properly the better.

So the solution_B totally keeps away from this spaghetti.

> 
>>> It'd be
>>> awesome if somebody more familiar with the numa side can chime in and
>>> explain why this mapping change can't be avoided.
>>
>> I'm also looking for someone answer it.
> 
> Exactly, whoever is requiring NUMA node remapping should explain and
> justify that and how the model to handle it can only be determined
> from that.
> 
> Thanks.
> 

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

Re: [PATCH] ARM: multi_v7_defconfig: Enable Hip01 platform

[Olof Johansson]

On Wed, Jan 14, 2015 at 07:02:04AM +, Wang Long wrote:
> Enable Hip01 platform support for multi_v7_defconfig.
> 
> Signed-off-by: Wang Long 
> ---
>  arch/arm/configs/multi_v7_defconfig | 1 +
>  1 file changed, 1 insertion(+)

Applied, thanks.


-Olof
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] powerpc: powernv: winkle: Restore LPCR with LPCR_PECE1 cleared

[Michael Ellerman]

On Wed, 2015-01-14 at 16:43 +0530, Shreyas B. Prabhu wrote:
> LPCR_PECE1 bit controls whether decrementer interrupts are allowed to
> cause exit from power-saving mode. While waking up from winkle, restoring
> LPCR with LPCR_PECE1 set (i.e Decrementer interrupts allowed) can cause
> issue in the following scenario:
> 
> - All the threads in a core are offlined. The core enters deep winkle.
> - Spurious interrupt wakes up a thread in the core. Here LPCR is restored
>   with LPCR_PECE1 bit set.
> - Since it was a spurious interrupt on a offline thread, the thread clears
>   the interrupt and goes back to winkle.
> - Here before the thread executes winkle and puts the core into deep winkle,
>   if a decrementer interrupt occurs on any of the sibling threads in the core
>   that thread wakes up. 
> - Since in offline loop we are flushing interrupt only in case of external
>   interrupt, the decrementer interrupt does not get flushed. So at this stage
>   the thread is stuck in this is loop of waking up at 0x100 due to decrementer
>   interrupt, not flushing the interrupt as only external interrupts get 
> flushed,
>   entering winkle, waking up at 0x100 again.
> 
> Fix this by programming PORE to restore LPCR with LPCR_PECE1 bit 
> cleared when waking up from winkle.

That sounds good.

But this makes the third place where we clear LPCR_PECE1, in addition to:

static int fastsleep_loop(struct cpuidle_device *dev,
struct cpuidle_driver *drv,
int index)
{
...

new_lpcr = old_lpcr;
/* Do not exit powersave upon decrementer as we've setup the timer
 * offload.
 */
new_lpcr &= ~LPCR_PECE1;

mtspr(SPRN_LPCR, new_lpcr);

And:

static void pnv_smp_cpu_kill_self(void)
{
...

/* We don't want to take decrementer interrupts while we are offline,
 * so clear LPCR:PECE1. We keep PECE2 enabled.
 */
mtspr(SPRN_LPCR, mfspr(SPRN_LPCR) & ~(u64)LPCR_PECE1);


So perhaps we can capture that logic in one place somehow?

cheers


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] Input: touchscreen-iproc: Add Broadcom iProc touchscreen driver

[Florian Fainelli]

On 19/12/14 15:03, Jonathan Richardson wrote:
> On 14-12-19 02:26 PM, Joe Perches wrote:
>> On Fri, 2014-12-19 at 14:17 -0800, Jonathan Richardson wrote:
>>> Add initial version of the Broadcom touchscreen driver.
>>
>> more trivia:
>>
>>> diff --git a/drivers/input/touchscreen/bcm_iproc_tsc.c 
>>> b/drivers/input/touchscreen/bcm_iproc_tsc.c
>> []
>>> +static int get_tsc_config(struct device_node *np, struct iproc_ts_priv 
>>> *priv)
>>> +{
>>> +   u32 val;
>> []
>>> +   if (of_property_read_u32(np, "debounce_timeout", &val) >= 0) {
>>> +   if (val < 0 || val > 255) {
>>> +   dev_err(dev, "debounce_timeout must be [0-255]\n");
>>> +   return -EINVAL;
>>> +   }
>>> +   priv->cfg_params.debounce_timeout = val;

BTW, common practice for DT properties is to use a dash instead of an
underscore for multi-worded properties.

>>
>> Doesn't the compiler generate a warning message
>> about an impossible "unsigned < 0" test for all
>> of these "val < 0" uses?
>>
> 
> Actually no it doesn't. The gcc output shows that neither -Wtype-limits
> nor -Wextra are used to compile that file. I assume this is because
> there would be just too many warnings.
> 
> 
>>> +   }
>>> +
>>> +   if (of_property_read_u32(np, "settling_timeout", &val) >= 0) {
>>> +   if (val < 0 || val > 11) {
>> []
>>> +   if (of_property_read_u32(np, "touch_timeout", &val) >= 0) {
>>> +   if (val < 0 || val > 255) {
>> []
>>> +   if (of_property_read_u32(np, "average_data", &val) >= 0) {
>>> +   if (val < 0 || val > 8) {
>> []
>>> +   if (of_property_read_u32(np, "fifo_threshold", &val) >= 0) {
>>> +   if (val < 0 || val > 31) {
>>
>>
> 
> 
> ___
> linux-arm-kernel mailing list
> linux-arm-ker...@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
> 


-- 
Florian
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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: [PATCHv2 2/2] spi: orion: Add multiple chip select support to spi-orion

[Ken Wilson]

On 15/01/15 06:06, Mark Brown wrote:

On Mon, Jan 12, 2015 at 01:14:00PM +1000, Ken Wilson wrote:


+- num-cs : The total number of chip selects used by this platform.
+   If unset, this defaults to 1.

So, this is intended to be the number of hardware chip selects that can
be configured but the first commit mentioned GPIOs as an option too so
we should at least say that this is specifically the controller
supported ones.  However...


+#define ORION_SPI_CS_MASK  0x1C
+#define ORION_SPI_CS_SHIFT 2
+#define ORION_SPI_CS(cs)   ((cs << ORION_SPI_CS_SHIFT) & \
+   ORION_SPI_CS_MASK)

...given that we have a fixed bitfield here which we know and doesn't
appear to depend on configuration do we even need this to be
configurable - given that we're going to need an explicit node for any
slave can't we just accept any sane chip select for a slave without
extending the binding?
The different implementations that use this driver (Marvell Kirkwood, 
Armada 370/375) all
have a different number of supported chip selects, that fit into this 
bit mask. There are also
multiple SPI controllers on each SoC which support different numbers of 
chip selects.
For example, on the Armada 375, SPI0 supports 3 chip selects, while SPI1 
only has 1.


I agree that we could support any sane chip select for a slave, since 
the slave addresses do need

to be explicitly defined. I'm happy with whatever your preference is.

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

[PATCH v2] ARM: dts: exynos5422-odroidxu3: add on-board INA231 sensors

[Kevin Hilman]

From: Kevin Hilman 

The odroid-xu3 has 4 INA231 current sensors on board which can be
accessed from the Linux via the hwmon interface.

There is one sensor for each of these power rails:

- A15 cluster: VDD_ARM
- A7 cluster: VDD_KFC
- GPU: VDD_G3D
- memory: VDD_MEM

In addition to adding the sensors, LDO26 from the PMIC needs to be
enabled because it's powering these sensor.

Cc: Javier Martinez Canillas 
Cc: Sjoerd Simons 
Signed-off-by: Kevin Hilman 
---
v2: use "ti,ina231" as compatible string.

Applies on top of "ARM: dts: Add dts file for odroid XU3 board" from Sjoerd 
Simons.

 arch/arm/boot/dts/exynos5422-odroidxu3.dts | 39 ++
 1 file changed, 39 insertions(+)

diff --git a/arch/arm/boot/dts/exynos5422-odroidxu3.dts 
b/arch/arm/boot/dts/exynos5422-odroidxu3.dts
index c29123c0734d..50353d023225 100644
--- a/arch/arm/boot/dts/exynos5422-odroidxu3.dts
+++ b/arch/arm/boot/dts/exynos5422-odroidxu3.dts
@@ -174,6 +174,13 @@
regulator-always-on;
};
 
+   ldo26_reg: LDO26 {
+   regulator-name = "vdd_ldo26";
+   regulator-min-microvolt = <300>;
+   regulator-max-microvolt = <300>;
+   regulator-always-on;
+   };
+
buck1_reg: BUCK1 {
regulator-name = "vdd_mif";
regulator-min-microvolt = <80>;
@@ -257,6 +264,38 @@
};
};
 
+   i2c_0: i2c@12C6 {
+   status = "okay";
+
+   /* A15 cluster: VDD_ARM */
+   ina231@40 {
+   compatible = "ti,ina231";
+   reg = <0x40>;
+   shunt-resistor = <1>;
+   };
+
+   /* memory: VDD_MEM */
+   ina231@41 {
+   compatible = "ti,ina231";
+   reg = <0x41>;
+   shunt-resistor = <1>;
+   };
+
+   /* GPU: VDD_G3D */
+   ina231@44 {
+   compatible = "ti,ina231";
+   reg = <0x44>;
+   shunt-resistor = <1>;
+   };
+
+   /* A7 cluster: VDD_KFC */
+   ina231@45 {
+   compatible = "ti,ina231";
+   reg = <0x45>;
+   shunt-resistor = <1>;
+   };
+   };
+
i2c_2: i2c@12C8 {
samsung,i2c-sda-delay = <100>;
samsung,i2c-max-bus-freq = <66000>;
-- 
2.1.3

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

[PATCHv2] ixgbe: Re-enable relaxed ordering as part of init/restart sequence for non-DCA config

[Sowmini Varadhan]

Relaxed ordering is disabled by default at driver initialization
and re-enabled when DCA is used. The reason it is disabled  was
due to an issue on some chipsets (see comments in ixgbe_update_tx_dca()).
But when DCA is not used, RO needs to be re-enabled, else we have
a serialization bottleneck on platforms like SPARC.

This patch eliminates the bottleneck for ixgbe when DCA is not configured.

Signed-off-by: Sowmini Varadhan 
Cc: Emil Tantilov 

---
v2: incoroporate comments from Emil Tantilov

 drivers/net/ethernet/intel/ixgbe/ixgbe_82598.c  |   23 +++
 drivers/net/ethernet/intel/ixgbe/ixgbe_common.c |   20 
 drivers/net/ethernet/intel/ixgbe/ixgbe_common.h |1 +
 drivers/net/ethernet/intel/ixgbe/ixgbe_main.c   |   11 +++
 drivers/net/ethernet/intel/ixgbe/ixgbe_type.h   |1 +
 drivers/net/ethernet/intel/ixgbe/ixgbe_x540.c   |1 +
 6 files changed, 57 insertions(+), 0 deletions(-)

diff --git a/drivers/net/ethernet/intel/ixgbe/ixgbe_82598.c 
b/drivers/net/ethernet/intel/ixgbe/ixgbe_82598.c
index c5c97b4..0c78b5a 100644
--- a/drivers/net/ethernet/intel/ixgbe/ixgbe_82598.c
+++ b/drivers/net/ethernet/intel/ixgbe/ixgbe_82598.c
@@ -1154,6 +1154,28 @@ static void ixgbe_set_rxpba_82598(struct ixgbe_hw *hw, 
int num_pb,
IXGBE_WRITE_REG(hw, IXGBE_TXPBSIZE(i), IXGBE_TXPBSIZE_40KB);
 }
 
+static void ixgbe_enable_relaxed_ordering_82598(struct ixgbe_hw *hw)
+{
+   u32 regval;
+   u32 i;
+
+   /* Enable relaxed ordering */
+   for (i = 0; ((i < hw->mac.max_tx_queues) &&
+(i < IXGBE_DCA_MAX_QUEUES_82598)); i++) {
+   regval = IXGBE_READ_REG(hw, IXGBE_DCA_TXCTRL(i));
+   regval |= IXGBE_DCA_TXCTRL_DESC_WRO_EN;
+   IXGBE_WRITE_REG(hw, IXGBE_DCA_TXCTRL(i), regval);
+   }
+
+   for (i = 0; ((i < hw->mac.max_rx_queues) &&
+(i < IXGBE_DCA_MAX_QUEUES_82598)); i++) {
+   regval = IXGBE_READ_REG(hw, IXGBE_DCA_RXCTRL(i));
+   regval |= IXGBE_DCA_RXCTRL_DATA_WRO_EN |
+ IXGBE_DCA_RXCTRL_HEAD_WRO_EN;
+   IXGBE_WRITE_REG(hw, IXGBE_DCA_RXCTRL(i), regval);
+   }
+}
+
 static struct ixgbe_mac_operations mac_ops_82598 = {
.init_hw= &ixgbe_init_hw_generic,
.reset_hw   = &ixgbe_reset_hw_82598,
@@ -1161,6 +1183,7 @@ static struct ixgbe_mac_operations mac_ops_82598 = {
.clear_hw_cntrs = &ixgbe_clear_hw_cntrs_generic,
.get_media_type = &ixgbe_get_media_type_82598,
.enable_rx_dma  = &ixgbe_enable_rx_dma_generic,
+   .enable_relaxed_ordering = &ixgbe_enable_relaxed_ordering_82598,
.get_mac_addr   = &ixgbe_get_mac_addr_generic,
.stop_adapter   = &ixgbe_stop_adapter_generic,
.get_bus_info   = &ixgbe_get_bus_info_generic,
diff --git a/drivers/net/ethernet/intel/ixgbe/ixgbe_common.c 
b/drivers/net/ethernet/intel/ixgbe/ixgbe_common.c
index 9c66bab..4453d92 100644
--- a/drivers/net/ethernet/intel/ixgbe/ixgbe_common.c
+++ b/drivers/net/ethernet/intel/ixgbe/ixgbe_common.c
@@ -338,6 +338,26 @@ s32 ixgbe_start_hw_gen2(struct ixgbe_hw *hw)
return 0;
 }
 
+void ixgbe_enable_relaxed_ordering(struct ixgbe_hw *hw)
+{
+   u32 i;
+   u32 regval;
+
+   /* Enable relaxed ordering */
+   for (i = 0; i < hw->mac.max_tx_queues; i++) {
+   regval = IXGBE_READ_REG(hw, IXGBE_DCA_TXCTRL_82599(i));
+   regval |= IXGBE_DCA_TXCTRL_DESC_WRO_EN;
+   IXGBE_WRITE_REG(hw, IXGBE_DCA_TXCTRL_82599(i), regval);
+   }
+
+   for (i = 0; i < hw->mac.max_rx_queues; i++) {
+   regval = IXGBE_READ_REG(hw, IXGBE_DCA_RXCTRL(i));
+   regval |= (IXGBE_DCA_RXCTRL_DATA_WRO_EN |
+   IXGBE_DCA_RXCTRL_HEAD_WRO_EN);
+   IXGBE_WRITE_REG(hw, IXGBE_DCA_RXCTRL(i), regval);
+   }
+}
+
 /**
  *  ixgbe_init_hw_generic - Generic hardware initialization
  *  @hw: pointer to hardware structure
diff --git a/drivers/net/ethernet/intel/ixgbe/ixgbe_common.h 
b/drivers/net/ethernet/intel/ixgbe/ixgbe_common.h
index 8cfadcb..c399c18 100644
--- a/drivers/net/ethernet/intel/ixgbe/ixgbe_common.h
+++ b/drivers/net/ethernet/intel/ixgbe/ixgbe_common.h
@@ -37,6 +37,7 @@ s32 ixgbe_init_ops_generic(struct ixgbe_hw *hw);
 s32 ixgbe_init_hw_generic(struct ixgbe_hw *hw);
 s32 ixgbe_start_hw_generic(struct ixgbe_hw *hw);
 s32 ixgbe_start_hw_gen2(struct ixgbe_hw *hw);
+void ixgbe_enable_relaxed_ordering(struct ixgbe_hw *hw);
 s32 ixgbe_clear_hw_cntrs_generic(struct ixgbe_hw *hw);
 s32 ixgbe_read_pba_string_generic(struct ixgbe_hw *hw, u8 *pba_num,
  u32 pba_num_size);
diff --git a/drivers/net/ethernet/intel/ixgbe/ixgbe_main.c 
b/drivers/net/ethernet/intel/ixgbe/ixgbe_main.c
index 2ed2c7d..dec815b 100644
--- a/drivers/net/ethernet/intel/ixgbe/ixgbe_main.c
+++ b/drivers/net/ethernet/intel/ixgbe

Re: [PATCH v2 1/2] Input: touchscreen-iproc: Add Broadcom iProc touchscreen driver

[Dmitry Torokhov]

Hi Jonathan,

On Fri, Dec 19, 2014 at 02:17:49PM -0800, Jonathan Richardson wrote:
> + if (of_property_read_u32(np, "scanning_period", &val) >= 0) {
> + if (val < 1 || val > 256) {
> + dev_err(dev, "scanning_period must be [1-256]\n");
> + return -EINVAL;
> + }
> + priv->cfg_params.scanning_period = val;
> + }
> +
> + if (of_property_read_u32(np, "debounce_timeout", &val) >= 0) {
> + if (val < 0 || val > 255) {
> + dev_err(dev, "debounce_timeout must be [0-255]\n");
> + return -EINVAL;
> + }
> + priv->cfg_params.debounce_timeout = val;
> + }
> +
> + if (of_property_read_u32(np, "settling_timeout", &val) >= 0) {
> + if (val < 0 || val > 11) {
> + dev_err(dev, "settling_timeout must be [0-11]\n");
> + return -EINVAL;
> + }
> + priv->cfg_params.settling_timeout = val;
> + }
> +
> + if (of_property_read_u32(np, "touch_timeout", &val) >= 0) {
> + if (val < 0 || val > 255) {
> + dev_err(dev, "touch_timeout must be [0-255]\n");
> + return -EINVAL;
> + }
> + priv->cfg_params.touch_timeout = val;
> + }
> +
> + if (of_property_read_u32(np, "average_data", &val) >= 0) {
> + if (val < 0 || val > 8) {
> + dev_err(dev, "average_data must be [0-8]\n");
> + return -EINVAL;
> + }
> + priv->cfg_params.average_data = val;
> + }
> +
> + if (of_property_read_u32(np, "fifo_threshold", &val) >= 0) {
> + if (val < 0 || val > 31) {
> + dev_err(dev, "fifo_threshold must be [0-31]\n");
> + return -EINVAL;
> + }
> + priv->cfg_params.fifo_threshold = val;
> + }

I think these are dveice specific and thus should have "brcm," prefix.

> +
> + priv->ts_rotation = TS_ROTATION_0;
> + if (of_property_read_u32(np, "ts-rotation", &val) >= 0) {
> + priv->ts_rotation = val;
> + dev_dbg(dev, "ts rotation [%d] degrees\n",
> + 90 * priv->ts_rotation);
> + }

This I am not quite sure about - if we want rotation or swap+invert. You
are CCed on another email (tsc2007) that talks about need of generic
touchscreen transforms in input core/of bindings.

Thanks.

-- 
Dmitry
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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/3] power: rt5033_battery: Add RT5033 Fuel gauge device driver

[Sebastian Reichel]

Hi,

On Fri, Jan 09, 2015 at 05:45:11PM +0900, Beomho Seo wrote:
> This patch adds device driver of Richtek PMIC.
> The driver support battery fuel gange. Fuel gauge calculates and determines 
> the
> battery state of charge(SOC) according to battery open circuit voltage(OCV).
> Also, this driver provides battery average voltage, voltage and bettery 
> present
> property.

Thanks, applied:

http://git.infradead.org/battery-2.6.git/commit/3cfb56d7ff013762a17b6a1b78bb3b0e4a6a6588

-- Sebastian


signature.asc
Description: Digital signature

Re: [PATCH 1/3] input: tsc2007: Add pre-calibration, flipping and rotation

[Dmitry Torokhov]

On Sat, Jan 10, 2015 at 03:15:39PM +0100, Belisko Marek wrote:
> Ping for input maintainer. DT changes was acked. Thanks.
> 
> On Tue, Sep 30, 2014 at 10:17 PM, Marek Belisko  wrote:
> > This patch adds new parameters that allow to address typical hardware
> > design differences: touch screens may be wired or oriented differently
> > (portrait or landscape). And usually the active area of the touch is a
> > little larger than the active area of the LCD. This results in the touch
> > coordinates that have some significant deviation from LCD coordinates.
> > Usually this is addressed in user space by a calibration tool (e.g. tslib
> > or xinput-calibrator) but some systems don't have these tools or require
> > that the screen is already roughly calibrated (e.g. Replicant) to operate
> > the device until a better calibration can be done. And, some systems
> > react very strangely if the touch event stream reports coordinates
> > outside of the active area.
> >
> > This makes it necessry to be able to configure:
> > 1. swapping x and y wires (coordinate values)
> > 2. flipping of x (left - right) or y (top - bottom) or even both
> > 3. define an active area so that an uncalibrated screen already
> > roughly matches the LCD to be useful.
> > 4. clip reported coordinates to the active area.
> >
> > If none of the new parameters is defined (in DT) or set in a board file,
> > the driver behaves the same as without this patch.
> >
> > Author (1&2): H. Nikolaus Schaller 
> > Author (3&4): Paul Kocialkowski 
> >
> > Signed-off-by: H. Nikolaus Schaller 

OK, I was hesitant of adding these as normally we have tslib to perform
the conversion, but maybe it is time to allow it in the kernel and
standardize users. However, this seems like a general issue and we
should:

1. Perform conversion in input core rather than individual drivers. I
think we should allocate a new bitmaps for some transformations and have
the code do X/Y flip/clip of the coordinates.

2. Standardize on bindings. We already have of-touchscreen.c doing
rudimentary parsing, we shoudl look into extending it rather than
creating myriad of driver-specific bindings.

Also, do we need swap and flip or do we simply need rotation (like the
proposed Broadcom iproc driver has)?

Thanks.

-- 
Dmitry
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] hwmon: (ina2xx) Add ina231 compatible string

[Guenter Roeck]

On Wed, Jan 14, 2015 at 03:57:32PM -0800, Kevin Hilman wrote:
> From: Kevin Hilman 
> 
> Add support for "ina231" as compatible string.
> 
> Tested with the Exynos5422-based odroid-xu3 board which has on-board
> INA231 sensors.
> 
> Signed-off-by: Kevin Hilman 

Hi Kevin,

can you also update Documentation/hwmon/ina2xx and Documentation/hwmon/Kconfig ?

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

Re: [PATCH 2/2] drm/msm/mdp5: Add hardware cursor support

[Daniel Vetter]

On Tue, Jan 13, 2015 at 05:18:04PM -0500, Stephane Viau wrote:
> From: Beeresh Gopal 
>
> This patch implements the hardware accelarated cursor
> support for MDP5 platforms.
>
> Signed-off-by: Beeresh Gopal 
> Signed-off-by: Wentao Xu 
> Signed-off-by: Stephane Viau 

Imo implementing legacy cursor support instead of with universal planes
makes no sense. Especially since msm is converted to atomic already, and
you can't move the cursor with atomic when it's legacy only. See the
cursor argument for the drm_crtc_init_with_planes function and how it's
used in e.g. i915.

Cheers, Daniel

> ---
>  drivers/gpu/drm/msm/mdp/mdp5/mdp5_crtc.c | 164 
> +++
>  1 file changed, 164 insertions(+)
>
> diff --git a/drivers/gpu/drm/msm/mdp/mdp5/mdp5_crtc.c 
> b/drivers/gpu/drm/msm/mdp/mdp5/mdp5_crtc.c
> index f021f96..2021f09 100644
> --- a/drivers/gpu/drm/msm/mdp/mdp5/mdp5_crtc.c
> +++ b/drivers/gpu/drm/msm/mdp/mdp5/mdp5_crtc.c
> @@ -24,6 +24,9 @@
>  #include "drm_crtc_helper.h"
>  #include "drm_flip_work.h"
>
> +#define CURSOR_WIDTH 64
> +#define CURSOR_HEIGHT 64
> +
>  #define SSPP_MAX (SSPP_RGB3 + 1) /* TODO: Add SSPP_MAX in mdp5.xml.h */
>
>  struct mdp5_crtc {
> @@ -47,8 +50,21 @@ struct mdp5_crtc {
>  #define PENDING_FLIP   0x2
>   atomic_t pending;
>
> + /* for unref'ing cursor bo's after scanout completes: */
> + struct drm_flip_work unref_cursor_work;
> +
>   struct mdp_irq vblank;
>   struct mdp_irq err;
> +
> + struct {
> + /* protect REG_MDP5_LM_CURSOR* registers and cursor scanout_bo*/
> + spinlock_t lock;
> +
> + /* current cursor being scanned out: */
> + struct drm_gem_object *scanout_bo;
> + uint32_t width;
> + uint32_t height;
> + } cursor;
>  };
>  #define to_mdp5_crtc(x) container_of(x, struct mdp5_crtc, base)
>
> @@ -129,11 +145,22 @@ static void complete_flip(struct drm_crtc *crtc, struct 
> drm_file *file)
>   }
>  }
>
> +static void unref_cursor_worker(struct drm_flip_work *work, void *val)
> +{
> + struct mdp5_crtc *mdp5_crtc =
> + container_of(work, struct mdp5_crtc, unref_cursor_work);
> + struct mdp5_kms *mdp5_kms = get_kms(&mdp5_crtc->base);
> +
> + msm_gem_put_iova(val, mdp5_kms->id);
> + drm_gem_object_unreference_unlocked(val);
> +}
> +
>  static void mdp5_crtc_destroy(struct drm_crtc *crtc)
>  {
>   struct mdp5_crtc *mdp5_crtc = to_mdp5_crtc(crtc);
>
>   drm_crtc_cleanup(crtc);
> + drm_flip_work_cleanup(&mdp5_crtc->unref_cursor_work);
>
>   kfree(mdp5_crtc);
>  }
> @@ -384,6 +411,132 @@ static int mdp5_crtc_set_property(struct drm_crtc *crtc,
>   return -EINVAL;
>  }
>
> +static int mdp5_crtc_cursor_set(struct drm_crtc *crtc,
> + struct drm_file *file, uint32_t handle,
> + uint32_t width, uint32_t height)
> +{
> + struct mdp5_crtc *mdp5_crtc = to_mdp5_crtc(crtc);
> + struct drm_device *dev = crtc->dev;
> + struct mdp5_kms *mdp5_kms = get_kms(crtc);
> + struct drm_gem_object *cursor_bo, *old_bo;
> + uint32_t blendcfg, cursor_addr, stride;
> + int ret, bpp, lm;
> + unsigned int depth;
> + enum mdp5_cursor_alpha cur_alpha = CURSOR_ALPHA_PER_PIXEL;
> + uint32_t flush_mask = mdp_ctl_flush_mask_cursor(0);
> + unsigned long flags;
> +
> + if ((width > CURSOR_WIDTH) || (height > CURSOR_HEIGHT)) {
> + dev_err(dev->dev, "bad cursor size: %dx%d\n", width, height);
> + return -EINVAL;
> + }
> +
> + if (NULL == mdp5_crtc->ctl)
> + return -EINVAL;
> +
> + if (!handle) {
> + DBG("Cursor off");
> + return mdp5_ctl_set_cursor(mdp5_crtc->ctl, false);
> + }
> +
> + cursor_bo = drm_gem_object_lookup(dev, file, handle);
> + if (!cursor_bo)
> + return -ENOENT;
> +
> + ret = msm_gem_get_iova(cursor_bo, mdp5_kms->id, &cursor_addr);
> + if (ret)
> + return -EINVAL;
> +
> + lm = mdp5_crtc->lm;
> + drm_fb_get_bpp_depth(DRM_FORMAT_ARGB, &depth, &bpp);
> + stride = width * (bpp >> 3);
> +
> + spin_lock_irqsave(&mdp5_crtc->cursor.lock, flags);
> + old_bo = mdp5_crtc->cursor.scanout_bo;
> +
> + mdp5_write(mdp5_kms, REG_MDP5_LM_CURSOR_STRIDE(lm), stride);
> + mdp5_write(mdp5_kms, REG_MDP5_LM_CURSOR_FORMAT(lm),
> + MDP5_LM_CURSOR_FORMAT_FORMAT(CURSOR_FMT_ARGB));
> + mdp5_write(mdp5_kms, REG_MDP5_LM_CURSOR_IMG_SIZE(lm),
> + MDP5_LM_CURSOR_IMG_SIZE_SRC_H(height) |
> + MDP5_LM_CURSOR_IMG_SIZE_SRC_W(width));
> + mdp5_write(mdp5_kms, REG_MDP5_LM_CURSOR_SIZE(lm),
> + MDP5_LM_CURSOR_SIZE_ROI_H(height) |
> + MDP5_LM_CURSOR_SIZE_ROI_W(width));
> + mdp5_write(mdp5_kms, REG_MDP5_LM_CURSOR_BASE_ADDR(lm), cursor_addr);
> +
> +
> + blendcfg = MDP5_LM_CURSOR_BLEND_CONFIG_BLEND_EN;
> + blendcfg |= MDP5_LM_CURSOR_BLEND_CONFIG_BLEND_TRANSP_EN;
> + blendcfg |= MDP5_LM_CURSOR_BLEND_CONFIG_BLEND_ALPHA_SEL(cur_alpha);
> + mdp5_write(mdp5_kms, REG_MDP5_LM_CURSOR_BLEND_CONFIG(lm), blendcfg);
> +
> + mdp5_crtc->cursor.scanout_bo = cursor_bo;
> + mdp5_crtc->cursor.width = width;
> + mdp5_crtc->cursor.height = height;
> + spin_unlock_irqrestore(&mdp5_crtc->cursor.lock, flags);
> +
> + ret = mdp5_ctl_set_cursor(mdp5_crtc->ctl, true);
> + if (ret)
> + goto end;
> +
> + flush_mask |= mdp5_ctl_get_flush(mdp5_crtc->ctl

Re: [PATCH RESEND 00/13] ltc2952 modernization and new functionality

[Sebastian Reichel]

Hi,

On Wed, Jan 14, 2015 at 09:15:33AM +0100, Frans Klaver wrote:
> Here's a resend of an earlier cleanup and improvement series for
> the ltc2952 driver.
> 
> This series implements devm_* usage, reduction of globals, some
> cleanup and finally makes the input trigger optional.
> 
> From the changes to the previous submissions I did not include
> renaming kill to poweroff. The name poweroff is already used a
> lot. Besides that, the control is referred to as kill in the
> ltc2952 datasheet.

Thanks for the cleanup, applied:

http://git.infradead.org/battery-2.6.git/commit/d84ba07c27fafca3cc77b25a1e204383a4b5af91

-- Sebastian


signature.asc
Description: Digital signature

Re: [PATCH 3.18 000/150] 3.18.3-stable review

[Guenter Roeck]

On Tue, Jan 13, 2015 at 11:21:11PM -0800, Greg Kroah-Hartman wrote:
> This is the start of the stable review cycle for the 3.18.3 release.
> There are 150 patches in this series, all will be posted as a response
> to this one.  If anyone has any issues with these being applied, please
> let me know.
> 
> Responses should be made by Fri Jan 16 07:20:24 UTC 2015.
> Anything received after that time might be too late.
> 
Build results:
total: 133 pass: 133 fail: 0
Qemu tests:
total: 30 pass: 30 fail: 0

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

Re: [PATCH 3.10 00/44] 3.10.65-stable review

[Guenter Roeck]

On Tue, Jan 13, 2015 at 11:23:21PM -0800, Greg Kroah-Hartman wrote:
> This is the start of the stable review cycle for the 3.10.65 release.
> There are 44 patches in this series, all will be posted as a response
> to this one.  If anyone has any issues with these being applied, please
> let me know.
> 
> Responses should be made by Fri Jan 16 07:22:13 UTC 2015.
> Anything received after that time might be too late.
> 

Build results:
total: 137 pass: 137 fail: 0
Qemu tests:
total: 27 pass: 27 fail: 0

Guenter
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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/4] perf tools: Add link argument to dso__find_symbol_by_name()

[David Ahern]

On 1/14/15 5:23 PM, Namhyung Kim wrote:

On Wed, Jan 14, 2015 at 09:36:34AM -0700, David Ahern wrote:

+   /* return first symbol that has same name (if any) */
+   for (n = rb_prev(n); n; n = rb_prev(n)) {
+   struct symbol_name_rb_node *tmp;
+
+   tmp = rb_entry(n, struct symbol_name_rb_node, rb_node);
+   if (strcmp(tmp->sym.name, s->sym.name))


strcmp() == 0?


No, at this point the 's' points to the first symbol that has same
name.  And if it finds another symbol (tmp) that has same name, it
updates the s to point to the tmp and continues.  Otherwise it returns
with the existing symbol (s).


I squinted a bit harder at your v3 and realized that. Was not obvious 
based on the first reading of the loop.


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

linux-next: manual merge of the renesas tree with the arm-soc tree

[Stephen Rothwell]

Hi Simon,

Today's linux-next merge of the renesas tree got a conflict in
arch/arm/boot/dts/Makefile between commit cb612390e546 ("ARM: dts: Only
build dtb if associated Arch and/or SoC is enabled") from the arm-soc
tree and commits 9ccba8abd0a7 ("ARM: shmobile: kzm9g: Build DTS for
Multiplatform") and 93c9f0228a3d ("ARM: shmobile: kzm9g-reference:
Remove board C code and DT file") from the renesas tree.

I fixed it up (see below) and can carry the fix as necessary (no action
is required).

-- 
Cheers,
Stephen Rothwells...@canb.auug.org.au

diff --cc arch/arm/boot/dts/Makefile
index 95fed8145ac9,be6e2607da88..
--- a/arch/arm/boot/dts/Makefile
+++ b/arch/arm/boot/dts/Makefile
@@@ -466,10 -411,8 +466,9 @@@ dtb-$(CONFIG_ARCH_SHMOBILE_LEGACY) += 
r8a7778-bockw-reference.dtb \
r8a7779-marzen.dtb \
sh7372-mackerel.dtb \
-   sh73a0-kzm9g.dtb \
-   sh73a0-kzm9g-reference.dtb
+   sh73a0-kzm9g.dtb
 -dtb-$(CONFIG_ARCH_SHMOBILE_MULTI) += emev2-kzm9d.dtb \
 +dtb-$(CONFIG_ARCH_SHMOBILE_MULTI) += \
 +  emev2-kzm9d.dtb \
r7s72100-genmai.dtb \
r8a73a4-ape6evm.dtb \
r8a7740-armadillo800eva.dtb \
@@@ -477,9 -420,9 +476,10 @@@
r8a7790-lager.dtb \
r8a7791-henninger.dtb \
r8a7791-koelsch.dtb \
-   r8a7794-alt.dtb
+   r8a7794-alt.dtb \
+   sh73a0-kzm9g.dtb
 -dtb-$(CONFIG_ARCH_SOCFPGA) += socfpga_arria5_socdk.dtb \
 +dtb-$(CONFIG_ARCH_SOCFPGA) += \
 +  socfpga_arria5_socdk.dtb \
socfpga_arria10_socdk.dtb \
socfpga_cyclone5_socdk.dtb \
socfpga_cyclone5_sockit.dtb \


pgpDOtnspDJQN.pgp
Description: OpenPGP digital signature

Re: [PATCH 3.18 126/150] Revert "Input: atmel_mxt_ts - use deep sleep mode when stopped"

[Greg Kroah-Hartman]

On Wed, Jan 14, 2015 at 03:00:02PM -0800, Dmitry Torokhov wrote:
> Hi Greg,
> 
> On Tue, Jan 13, 2015 at 11:23:17PM -0800, Greg Kroah-Hartman wrote:
> > 3.18-stable review patch.  If anyone has any objections, please let me know.
> > 
> > --
> > 
> > From: Linus Torvalds 
> > 
> > commit 7f4054836d811c650c51f9c93088f8ebd61b0020 upstream.
> > 
> > This reverts commit 9d469d033d135d80742a4e39e6bbb4519dd5eee1.
> > 
> > It breaks the Chromebook Pixel touchpad (and touchscreen).
> > 
> > Reported-by: Dirk Hohndel 
> > Bisected-by: Linus Torvalds 
> > Cc: Nick Dyer 
> > Cc: Benson Leung 
> > Cc: Yufeng Shen 
> > Cc: Dmitry Torokhov 
> > Signed-off-by: Linus Torvalds 
> > Signed-off-by: Greg Kroah-Hartman 
> 
> I'd rather we did not apply this to stable just yet - the patch does not
> fix Dirk's Pixel and Linus's still flaky and I have another patch I'm
> waiting on them to try out.

Thanks for letting me know, it's now dropped.

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

Re: [PATCH 3.14 00/77] 3.14.29-stable review

[Greg Kroah-Hartman]

On Wed, Jan 14, 2015 at 10:05:50AM -0800, Guenter Roeck wrote:
> On Wed, Jan 14, 2015 at 05:48:54PM +0100, Jiri Slaby wrote:
> > On 01/14/2015, 05:37 PM, Guenter Roeck wrote:
> > > On Tue, Jan 13, 2015 at 11:22:40PM -0800, Greg Kroah-Hartman wrote:
> > >> This is the start of the stable review cycle for the 3.14.29 release.
> > >> There are 77 patches in this series, all will be posted as a response
> > >> to this one.  If anyone has any issues with these being applied, please
> > >> let me know.
> > >>
> > >> Responses should be made by Fri Jan 16 07:22:07 UTC 2015.
> > >> Anything received after that time might be too late.
> > >>
> > > There are several powerpc build failures.
> > > 
> > > Building powerpc:defconfig ... failed
> > > Building powerpc:allmodconfig ... failed
> > > Building powerpc:cell_defconfig ... failed
> > > Building powerpc:maple_defconfig ... failed
> > > 
> > > arch/powerpc/kernel/head_64.o: In function `machine_check_handle_early':
> > > (.text+0x918c): undefined reference to `.power7_enter_nap_mode'
> > 
> > Dots from functions were removed only in commit b1576fec7f4 (powerpc: No
> > need to use dot symbols when branching to a function).
> > 
> > The backport of commit 8117ac6a6c2 (powerpc/powernv: Switch off MMU
> > before entering nap/sleep/rvwinkle mode) should redefine
> > power7_enter_nap_mode with dots IMO.
> > 
> Yes, something like that, or drop that commit for the time being.
> Reverting it fixes the problem.

Thanks, I've dropped this patch for now because of this.

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

Re: [PATCH 3.18 000/150] 3.18.3-stable review

[Greg Kroah-Hartman]

On Wed, Jan 14, 2015 at 03:48:24PM -0700, Shuah Khan wrote:
> On 01/14/2015 12:21 AM, Greg Kroah-Hartman wrote:
> > This is the start of the stable review cycle for the 3.18.3 release.
> > There are 150 patches in this series, all will be posted as a response
> > to this one.  If anyone has any issues with these being applied, please
> > let me know.
> > 
> > Responses should be made by Fri Jan 16 07:20:24 UTC 2015.
> > Anything received after that time might be too late.
> > 
> > The whole patch series can be found in one patch at:
> > kernel.org/pub/linux/kernel/v3.0/stable-review/patch-3.18.3-rc1.gz
> > and the diffstat can be found below.
> > 
> > thanks,
> > 
> > greg k-h
> > 
> 
> Compiled and booted on my test system. No dmesg regressions.

Thanks for testing all of these and letting me know.

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

Re: [GIT PULL] USB patches

[Greg KH]

On Wed, Jan 14, 2015 at 11:48:39AM -0600, Felipe Balbi wrote:
> Hi Greg,
> 
> Alright, 3 more fixes for v3.19-rc and my queue is finally clean.
> 
> All three fixes are rather obvious, two of them just took longer
> to sort out all the stable rules details and I ended up having
> to fix all that, otherwise we would miss the time frame.
> 
> Please condiser merging to your greg/usb-linus branch.
> 
> cheers
> 
> The following changes since commit 5fb694f96e7c19e66b1c55124b98812e32e3efa5:
> 
>   usb: gadget: udc: atmel: fix possible oops when unloading module 
> (2015-01-09 18:15:11 -0600)
> 
> are available in the git repository at:
> 
>   git://git.kernel.org/pub/scm/linux/kernel/git/balbi/usb.git 
> tags/fixes-for-v3.19-rc6

Pulled and pushed out, thanks.

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

Re: [PATCH v2 2/4] perf tools: Add link argument to dso__find_symbol_by_name()

[Namhyung Kim]

On Wed, Jan 14, 2015 at 09:36:34AM -0700, David Ahern wrote:
> On 1/14/15 4:18 AM, Namhyung Kim wrote:
> >@@ -414,10 +414,24 @@ static struct symbol *symbols__find_by_name(struct 
> >rb_root *symbols,
> > else if (cmp > 0)
> > n = n->rb_right;
> > else
> >-return &s->sym;
> >+break;
> > }
> >
> >-return NULL;
> >+if (n == NULL)
> >+return NULL;
> >+
> >+/* return first symbol that has same name (if any) */
> >+for (n = rb_prev(n); n; n = rb_prev(n)) {
> >+struct symbol_name_rb_node *tmp;
> >+
> >+tmp = rb_entry(n, struct symbol_name_rb_node, rb_node);
> >+if (strcmp(tmp->sym.name, s->sym.name))
> 
> strcmp() == 0?

No, at this point the 's' points to the first symbol that has same
name.  And if it finds another symbol (tmp) that has same name, it
updates the s to point to the tmp and continues.  Otherwise it returns
with the existing symbol (s).

Thanks,
Namhyung


> 
> >+break;
> >+
> >+s = tmp;
> >+}
> >+
> >+return &s->sym;
> >  }
> >
> >  struct symbol *dso__find_symbol(struct dso *dso,
> 
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majord...@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: [RFC PATCH 0/5] Second attempt at contained helper execution

[Ian Kent]

On Wed, 2015-01-14 at 17:10 -0500, J. Bruce Fields wrote:
> > On Wed, Jan 14, 2015 at 05:32:22PM +0800, Ian Kent wrote:
> > > There are other difficulties to tackle as well, such as how to decide
> > > if contained helper execution is needed. For example, if a mount has
> > > been propagated to a container or bound into the container tree (such
> > > as with the --volume option of "docker run") the root init namespace
> > > may need to be used and not the container namespace.
> 
> I think you have to go through each of the existing upcall examples and
> decide what's needed for each.
> 
> At least for the nfsv4 idmapper I would've thought the namespace the
> mount was done in would be the right choice, hence my previous question.

Probably but you don't necessarily know what namespace the mount was
done in. It may have been propagated from another namespace or (although
I don't think it works yet) bound from another container using the
volumes-from docker option.

At least I believe that's a problem and I agree that, once a suitable
method of running helpers is found each case will need to be looked at.

Ian


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

Re: [PATCH v3 4/4] pinctrl: qcom: Add support for reset for apq8064

[Stephen Boyd]

On 01/14/2015 03:54 PM, Timur Tabi wrote:
> On Wed, Jan 14, 2015 at 5:44 PM, Stephen Boyd  wrote:
>> I think so. Can you send a patch? Plus it would be nice to move i = 0 in
>> the for loop at the same time.
> Sadly, Qualcomm policy makes that very cumbersome for me.  I won't be
> able to send a patch any time soon.
>

Hm... we'll have to figure out that part. Anyway here's the patch.

---8<
From: Stephen Boyd 
Subject: [PATCH] pinctrl: qcom: Don't iterate past end of function array

Timur reports that this code crashes if nfunctions is 0. Fix the
loop iteration to only consider valid elements of the functions
array.

Reported-by: Timur Tabi 
Cc: Pramod Gurav 
Cc: Bjorn Andersson 
Cc: Ivan T. Ivanov 
Cc: Andy Gross 
Fixes: 327455817a92 "pinctrl: qcom: Add support for reset for apq8064"
Signed-off-by: Stephen Boyd 
---
 drivers/pinctrl/qcom/pinctrl-msm.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/pinctrl/qcom/pinctrl-msm.c 
b/drivers/pinctrl/qcom/pinctrl-msm.c
index e730935fa457..ed7017df065d 100644
--- a/drivers/pinctrl/qcom/pinctrl-msm.c
+++ b/drivers/pinctrl/qcom/pinctrl-msm.c
@@ -865,10 +865,10 @@ static int msm_ps_hold_restart(struct notifier_block *nb, 
unsigned long action,
 
 static void msm_pinctrl_setup_pm_reset(struct msm_pinctrl *pctrl)
 {
-   int i = 0;
+   int i;
const struct msm_function *func = pctrl->soc->functions;
 
-   for (; i <= pctrl->soc->nfunctions; i++)
+   for (i = 0; i < pctrl->soc->nfunctions; i++)
if (!strcmp(func[i].name, "ps_hold")) {
pctrl->restart_nb.notifier_call = msm_ps_hold_restart;
pctrl->restart_nb.priority = 128;

-- 
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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/4] perf tools: Fix segfault for symbol annotation on TUI

[Namhyung Kim]

Hi Arnaldo and David,

On Wed, Jan 14, 2015 at 06:08:52PM -0300, Arnaldo Carvalho de Melo wrote:
> Em Wed, Jan 14, 2015 at 07:57:49AM -0700, David Ahern escreveu:
> > On 1/14/15 4:18 AM, Namhyung Kim wrote:
> > 
> > >@@ -129,8 +124,7 @@ static inline struct sym_hist 
> > >*annotation__histogram(struct annotation *notes, i
> > >
> > >  static inline struct annotation *symbol__annotation(struct symbol *sym)
> > >  {
> > >-  struct sannotation *a = container_of(sym, struct sannotation, symbol);
> > >-  return &a->annotation;
> > >+  return (void *)sym - symbol_conf.priv_size;
> > 
> > symbol__priv(sym);
> 
> Amended, thanks.

Oh, I missed that.  Thanks to both of you!
Namhyung
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] MAINTAINERS: update brcmstb entries

[Brian Norris]

Since I found this in my inbox during garbage collection...

On Tue, Nov 4, 2014 at 3:23 PM, Florian Fainelli  wrote:
> On 11/04/2014 02:56 PM, Grant Likely wrote:
>> On Tue, Nov 4, 2014 at 10:48 PM, Florian Fainelli  
>> wrote:
>>> On 11/04/2014 12:45 PM, Olof Johansson wrote:
 On Tue, Oct 28, 2014 at 11:44:54AM -0700, Florian Fainelli wrote:
> Remove Marc Carino from the brcmstb maintainers list and add Gregory
> Fong and myself as new maintainers for the brcmstb platform.
>
> Signed-off-by: Florian Fainelli 
> ---
>  MAINTAINERS | 3 ++-
>  1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/MAINTAINERS b/MAINTAINERS
> index dab92a78d1d5..33a8b31e03f0 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -2093,8 +2093,9 @@ F: arch/arm/mach-bcm/bcm63xx.c
>  F:  arch/arm/include/debug/bcm63xx.S
>
>  BROADCOM BCM7XXX ARM ARCHITECTURE
> -M:  Marc Carino 
>  M:  Brian Norris 
> +M:  Gregory Fong 
> +M:  Florian Fainelli 

 You're removing Marc here, but I don't see an ack from him, nor has
 he been cc:d on the patch. It's common practice for people to agree to
 being removed. Can you please make sure we get an ack from him on this,
 maybe by reposting and cc:ing him?
>>>
>>> Marc is no longer with Broadcom, do you still want him to ack this?
>>
>> Yes, absolutely. Maintainership is entrusted to an individual, not
>> their employer. We've had many situations where someone has continued
>> to maintain a platform even after changing employment. So, yes, there
>> needs to be an ack from Marc.
>
> He is CC'd, now. Marc, please Ack this if you are okay with the change.

Can we add a "Not-nacked-by" tag and proceed? Marc is obviously not
involved here any more. I figure removing expired maintainers should
be a little easier than removing SCOTUS judges.

Brian
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] perf symbols: Ignore mapping symbols on aarch64

[Russell King - ARM Linux]

On Wed, Jan 14, 2015 at 10:38:38AM -0800, Victor Kamensky wrote:
> >From fed6caab410ddcaf487ff23a3908eca129e50b89 Mon Sep 17 00:00:00 2001
> From: Victor Kamensky 
> Date: Wed, 14 Jan 2015 07:42:41 -0800
> Subject: [PATCH 3/3] perf symbols: improve abi compliance in arm mapping
>  symbols handling
> 
> Both Arm and Aarch64 ELF ABI allow mapping symbols be in from
> either "$d" or "$d.". But current code that handles mapping
> symbols only deals with the first, dollar character and a single
> letter, case.
> 
> The patch adds handling of the second case with period
> followed by any characters.
> 
> Suggested-by: Will Deacon 
> Signed-off-by: Victor Kamensky 

I wonder if it would make more sense to re-use the "is_arm_mapping_symbol"
thing which we have in kernel/module.c and scripts/kallsyms.c - it
seems silly to re-invent code which we already have to detect these
symbols.

-- 
FTTC broadband for 0.8mile line: currently at 10.5Mbps down 400kbps up
according to speedtest.net.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] ixgbe: Re-enable relaxed ordering as part of init/restart sequence for non-DCA config

[Tantilov, Emil S]

>-Original Message-
>From: Sowmini Varadhan [mailto:sowmini.varad...@oracle.com] 
>Relaxed ordering is disabled by default at driver initialization
>and re-enabled when DCA is used. The reason it is disabled  was
>due to an issue on some chipsets (see comments in ixgbe_update_tx_dca()).
>But when DCA is not used, RO needs to be re-enabled, else we have
>a serialization bottleneck on platforms like SPARC.
>
>This patch eliminates the bottleneck for ixgbe when DCA is not configured.
>
>Signed-off-by: Sowmini Varadhan 
>Cc: Emil Tantilov 
>---
> drivers/net/ethernet/intel/ixgbe/ixgbe_82598.c  |1 +
> drivers/net/ethernet/intel/ixgbe/ixgbe_common.c |   20 
> drivers/net/ethernet/intel/ixgbe/ixgbe_common.h |1 +
> drivers/net/ethernet/intel/ixgbe/ixgbe_main.c   |   11 +++
> drivers/net/ethernet/intel/ixgbe/ixgbe_type.h   |1 +
> drivers/net/ethernet/intel/ixgbe/ixgbe_x540.c   |1 +
> 6 files changed, 35 insertions(+), 0 deletions(-)
>
>diff --git a/drivers/net/ethernet/intel/ixgbe/ixgbe_82598.c 
>b/drivers/net/ethernet/intel/ixgbe/ixgbe_82598.c
>index c5c97b4..85c7a28 100644
>--- a/drivers/net/ethernet/intel/ixgbe/ixgbe_82598.c
>+++ b/drivers/net/ethernet/intel/ixgbe/ixgbe_82598.c
>@@ -1161,6 +1161,7 @@ static struct ixgbe_mac_operations mac_ops_82598 = {
>   .clear_hw_cntrs = &ixgbe_clear_hw_cntrs_generic,
>   .get_media_type = &ixgbe_get_media_type_82598,
>   .enable_rx_dma  = &ixgbe_enable_rx_dma_generic,
>+  .enable_relaxed_ordering = &ixgbe_enable_relaxed_ordering,

The IXGBE_DCA_TXCTRL register for 82598 is at a different offset. Also there is 
a limit of 16 registers. The function we have in our code for 82598 is as 
follows:

/**
 *  ixgbe_enable_relaxed_ordering_82598 - enable relaxed ordering
 *  @hw: pointer to hardware structure
 *
 **/
void ixgbe_enable_relaxed_ordering_82598(struct ixgbe_hw *hw)
{
u32 regval;
u32 i;

/* Enable relaxed ordering */
for (i = 0; ((i < hw->mac.max_tx_queues) &&
 (i < IXGBE_DCA_MAX_QUEUES_82598)); i++) {
regval = IXGBE_READ_REG(hw, IXGBE_DCA_TXCTRL(i));
regval |= IXGBE_DCA_TXCTRL_DESC_WRO_EN;
IXGBE_WRITE_REG(hw, IXGBE_DCA_TXCTRL(i), regval);
}

for (i = 0; ((i < hw->mac.max_rx_queues) &&
 (i < IXGBE_DCA_MAX_QUEUES_82598)); i++) {
regval = IXGBE_READ_REG(hw, IXGBE_DCA_RXCTRL(i));
regval |= IXGBE_DCA_RXCTRL_DATA_WRO_EN |
  IXGBE_DCA_RXCTRL_HEAD_WRO_EN;
IXGBE_WRITE_REG(hw, IXGBE_DCA_RXCTRL(i), regval);
}
}

Thanks,
Emil
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] hwmon: (ina2xx) Add ina231 compatible string

[Kevin Hilman]

From: Kevin Hilman 

Add support for "ina231" as compatible string.

Tested with the Exynos5422-based odroid-xu3 board which has on-board
INA231 sensors.

Signed-off-by: Kevin Hilman 
---
 drivers/hwmon/ina2xx.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/hwmon/ina2xx.c b/drivers/hwmon/ina2xx.c
index e01feba909c3..8c4a29bd2eaf 100644
--- a/drivers/hwmon/ina2xx.c
+++ b/drivers/hwmon/ina2xx.c
@@ -287,6 +287,7 @@ static const struct i2c_device_id ina2xx_id[] = {
{ "ina220", ina219 },
{ "ina226", ina226 },
{ "ina230", ina226 },
+   { "ina231", ina226 },
{ }
 };
 MODULE_DEVICE_TABLE(i2c, ina2xx_id);
-- 
2.1.3

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

Re: [RESEND PATCH v3] clocksource: exynos_mct: Add the support for Exynos 64bit SoC

[Chanwoo Choi]

Hi Kukjin,

On 01/15/2015 01:02 AM, Daniel Lezcano wrote:
> On 01/14/2015 04:51 PM, Kukjin Kim wrote:
>> On 01/14/15 14:33, Chanwoo Choi wrote:
>>
>> Hi,
>>
>> + Doug, Olof
>>
>>> This patch adds the support for Exynos 64bit SoC. The delay_timer is only 
>>> used
>>> for Exynos 32bit SoC.
>>>
>> Yes, the Exynos MCT(Multi-Core Timer) is 64bit timer and it is available
>> on 64bit exynos SoC such as exynos7. But basically ARMv8 architecture is
>> including ARM ARCH timer (ARM Generic Timer) and exynos7 also has
>> implemented it and additionally its access is faster than using memory
>> mapped register called SFR for MCT...so Doug submitted patch to use MCT
>> on 32bit exynos SoCs before.

I know arch_timer. As you comment, ARCH timer would be used for system timer 
for ARMv8.
But, Exynos5433/Exynos7 (ARMv8) include MCT (Multi-Core Timer) IP. I checked it 
on
Exynos5433/EXynos7 User-manaual and tested it.

I think that exynos_mct.c should support the Exynos 64-bit SoC
because Exynos5433/Exynos7 include already MCT (Multi-Core Timer) IP.

Also, I have a problem to verify ARCH timer on Exynos SoC. Exynos User-manual 
never includes
the detailed information about for ARCH timer(e.g, clock for ARCH timer). I 
knew that
I can get the document of ARCH timer for ARM official site but I think it is 
insufficient
to implement ARCH timer on Exynos SoC. 

Best Regards,
Chanwoo Choi

>>
>> I know using MCT on 64bit exynos is usefulness for Power Management and
>> I need to talk to relevant guys in office again. If anything, I'll let
>> you know.
> 
> I will wait for your answer before digging more the patch.
> 
> Thanks
>   -- Daniel
> 
>>> Cc: Daniel Lezcano 
>>> Cc: Thomas Gleixner 
>>> Cc: Kukjin Kim 
>>> Cc: Mark Rutland 
>>> Signed-off-by: Chanwoo Choi 
>>> ---
>>> This patch set is tested on 64-bit Exynos SoC. I send only this patch from
>>> following patchst[1].
>>> [1] https://lkml.org/lkml/2014/12/2/134
>>>
>>> Changes from v2:
>>> - None
>>> Changes from v1:
>>> - Use CONFIG_ARM instead of CONFIG_ARM64
>>>
>>>   drivers/clocksource/Kconfig  | 1 -
>>>   drivers/clocksource/exynos_mct.c | 4 
>>>   2 files changed, 4 insertions(+), 1 deletion(-)
>>>
>>> diff --git a/drivers/clocksource/Kconfig b/drivers/clocksource/Kconfig
>>> index fc01ec2..be38119 100644
>>> --- a/drivers/clocksource/Kconfig
>>> +++ b/drivers/clocksource/Kconfig
>>> @@ -135,7 +135,6 @@ config CLKSRC_METAG_GENERIC
>>>
>>>   config CLKSRC_EXYNOS_MCT
>>>   def_bool y if ARCH_EXYNOS
>>> -depends on !ARM64
>>>   help
>>> Support for Multi Core Timer controller on Exynos SoCs.
>>>
>>> diff --git a/drivers/clocksource/exynos_mct.c 
>>> b/drivers/clocksource/exynos_mct.c
>>> index 9403061..b840ea1 100644
>>> --- a/drivers/clocksource/exynos_mct.c
>>> +++ b/drivers/clocksource/exynos_mct.c
>>> @@ -223,6 +223,7 @@ static u64 notrace exynos4_read_sched_clock(void)
>>>   return exynos4_read_count_32();
>>>   }
>>>
>>> +#if defined(CONFIG_ARM)
>>>   static struct delay_timer exynos4_delay_timer;
>>>
>>>   static cycles_t exynos4_read_current_timer(void)
>>> @@ -231,14 +232,17 @@ static cycles_t exynos4_read_current_timer(void)
>>>"cycles_t needs to move to 32-bit for ARM64 usage");
>>>   return exynos4_read_count_32();
>>>   }
>>> +#endif
>>>
>>>   static void __init exynos4_clocksource_init(void)
>>>   {
>>>   exynos4_mct_frc_start();
>>>
>>> +#if defined(CONFIG_ARM)
>>>   exynos4_delay_timer.read_current_timer = &exynos4_read_current_timer;
>>>   exynos4_delay_timer.freq = clk_rate;
>>>   register_current_timer_delay(&exynos4_delay_timer);
>>> +#endif
>>>
>>>   if (clocksource_register_hz(&mct_frc, clk_rate))
>>>   panic("%s: can't register clocksource\n", mct_frc.name);
> 
> 

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

Re: [PATCH v3 4/4] pinctrl: qcom: Add support for reset for apq8064

[Timur Tabi]

On Wed, Jan 14, 2015 at 5:44 PM, Stephen Boyd  wrote:
>
> I think so. Can you send a patch? Plus it would be nice to move i = 0 in
> the for loop at the same time.

Sadly, Qualcomm policy makes that very cumbersome for me.  I won't be
able to send a patch any time soon.

-- 
Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] procfs: Add /proc//mapped_files

[Rasmus Villemoes]

On Wed, Jan 14 2015, Andrew Morton  wrote:

> On Wed, 14 Jan 2015 13:03:26 -0800 Calvin Owens  wrote:
>> 
>> If I understand the current behavior, the "[stack]" marker will get put
>> next to *any* mapping that encompasses the current value in the task's
>> %sp, regardless of how the mapping was created or ucontext stuff. If
>> you use flags on the VMA structs things could potentially be marked as
>> stacks even though %sp points somewhere else.
>> 
>> It's probable that nobody cares (you'd obviously have to be doing crazy
>> things to be pointing %sp at arbitrary places), but that's why I was
>> hesitant to mess with it.
>
> Fixing the N^2 search would of course be much better than adding a new
> proc file to sidestep it.
>
> Could we do something like refreshing the new vma.vm_flags:VM_IS_STACK
> on each thread at the time when /proc/PID/maps is opened?  So do a walk
> of the threads, use each thread's sp to hunt down the thread's stack's
> vma, then set VM_IS_STACK and fill in the new vma.stack_tid field?

So this would be roughly #tasks*log(#vmas) + #vmas. Sounds
good. Especially since all the work will be done by the reader, so
there's no extra bookkeeping to do in sys_clone etc. Concurrent readers
could influence what each other end up seeing, but most of the time the
update will be idempotent, and the information may be stale anyway by
the time the reader has a chance to process it.

> There are still several flags unused in vma.vm_flags btw.
>
> I'm not sure that we can repurpose vm_pgoff (or vm_private_data) for
> this: a badly behaved thread could make its sp point at a random vma
> then trick the kernel into scribbling on that vma's vm_proff?

Well, we could still check vm_file for being NULL before writing to
vm_pgoff/vm_stack_tid. 

> Adding a new field to the vma wouldn't kill us, I guess.  That would
> remove the need for a VM_IS_STACK.

Either way, it seems that that decision can be changed later.

Rasmus
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] perf probe: Fix probing kretprobes

[Namhyung Kim]

The commit dfef99cd0b2c ("perf probe: Use ref_reloc_sym based address
instead of the symbol name") converts kprobes to use ref_reloc_sym
(i.e. _stext) and offset instead of using symbol's name directly.  So
on my system, adding do_fork ends up with like below:

  $ sudo perf probe -v --add do_fork%return
  probe-definition(0): do_fork%return
  symbol:do_fork file:(null) line:0 offset:0 return:1 lazy:(null)
  0 arguments
  Looking at the vmlinux_path (7 entries long)
  Using /lib/modules/3.17.6-1-ARCH/build/vmlinux for symbols
  Could not open debuginfo. Try to use symbols.
  Opening /sys/kernel/debug/tracing/kprobe_events write=1
  Added new event:
  Writing event: r:probe/do_fork _stext+456136
  Failed to write event: Invalid argument
  Error: Failed to add events. Reason: Operation not permitted (Code: -1)

As you can see, the do_fork was translated to _stext+456136.  This was
because to support (local) symbols that have same name.  But the
problem is that kretprobe requires to be inserted at function start
point so it simply checks whether it's called with offset 0.  And if
not, it'll return with -EINVAL.  You can see it with dmesg.

  $ dmesg | tail -1
[125621.764103] Return probe must be used without offset.

So we need to use the symbol name instead of ref_reloc_sym in case of
return probes.

Reported-by: Jiri Olsa 
Tested-by: Jiri Olsa 
Cc: Masami Hiramatsu 
Signed-off-by: Namhyung Kim 
---
 tools/perf/util/probe-event.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/tools/perf/util/probe-event.c b/tools/perf/util/probe-event.c
index 3cfad9c74faf..8fcb19b0e74f 100644
--- a/tools/perf/util/probe-event.c
+++ b/tools/perf/util/probe-event.c
@@ -446,7 +446,7 @@ static int post_process_probe_trace_events(struct 
probe_trace_event *tevs,
}
 
for (i = 0; i < ntevs; i++) {
-   if (tevs[i].point.address) {
+   if (tevs[i].point.address && !tevs[i].point.retprobe) {
tmp = strdup(reloc_sym->name);
if (!tmp)
return -ENOMEM;
@@ -2254,7 +2254,7 @@ static int find_probe_trace_events_from_map(struct 
perf_probe_event *pev,
goto out;
}
 
-   if (!pev->uprobes) {
+   if (!pev->uprobes && !pp->retprobe) {
kmap = map__kmap(map);
reloc_sym = kmap->ref_reloc_sym;
if (!reloc_sym) {
-- 
2.2.1

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

[PATCH v3 2/3] perf probe: Do not rely on map__load() filter to find symbols

[Namhyung Kim]

The find_probe_trace_events_from_map() searches matching symbol from a
map (so from a backing dso).  For uprobes, it'll create a new map (and
dso) and loads it using a filter.  It's a little bit inefficient in that
it'll read out the symbol table everytime but works well anyway.

For kprobes however, it'll reuse existing kernel map which might be
loaded before.  In this case map__load() just returns with no result.
It makes kprobes always failed to find symbol even if it exists in the
map (dso).

To fix it, use map__find_symbol_by_name_from() instead.  It'll load a
map with full symbols and sorts them by name.  It needs to search sibing
nodes since there can be multiple (local) symbols with same name.

Cc: Masami Hiramatsu 
Signed-off-by: Namhyung Kim 
---
 tools/perf/util/probe-event.c | 31 ++-
 1 file changed, 14 insertions(+), 17 deletions(-)

diff --git a/tools/perf/util/probe-event.c b/tools/perf/util/probe-event.c
index 94a717bf007d..3cfad9c74faf 100644
--- a/tools/perf/util/probe-event.c
+++ b/tools/perf/util/probe-event.c
@@ -2193,18 +2193,17 @@ static int __add_probe_trace_events(struct 
perf_probe_event *pev,
return ret;
 }
 
-static char *looking_function_name;
-static int num_matched_functions;
-
-static int probe_function_filter(struct map *map __maybe_unused,
- struct symbol *sym)
+static int find_probe_functions(struct map *map, char *name)
 {
-   if ((sym->binding == STB_GLOBAL || sym->binding == STB_LOCAL) &&
-   strcmp(looking_function_name, sym->name) == 0) {
-   num_matched_functions++;
-   return 0;
+   struct symbol *sym = NULL;
+   int found = 0;
+
+   while ((sym = map__find_symbol_by_name_from(map, name, NULL, sym))) {
+   if (sym->binding == STB_GLOBAL || sym->binding == STB_LOCAL)
+   found++;
}
-   return 1;
+
+   return found;
 }
 
 #define strdup_or_goto(str, label) \
@@ -2221,11 +2220,11 @@ static int find_probe_trace_events_from_map(struct 
perf_probe_event *pev,
struct map *map = NULL;
struct kmap *kmap = NULL;
struct ref_reloc_sym *reloc_sym = NULL;
-   struct symbol *sym;
-   struct rb_node *nd;
+   struct symbol *sym = NULL;
struct probe_trace_event *tev;
struct perf_probe_point *pp = &pev->point;
struct probe_trace_point *tp;
+   int num_matched_functions;
int ret, i;
 
/* Init maps of given executable or kernel */
@@ -2242,10 +2241,8 @@ static int find_probe_trace_events_from_map(struct 
perf_probe_event *pev,
 * Load matched symbols: Since the different local symbols may have
 * same name but different addresses, this lists all the symbols.
 */
-   num_matched_functions = 0;
-   looking_function_name = pp->function;
-   ret = map__load(map, probe_function_filter);
-   if (ret || num_matched_functions == 0) {
+   num_matched_functions = find_probe_functions(map, pp->function);
+   if (num_matched_functions == 0) {
pr_err("Failed to find symbol %s in %s\n", pp->function,
target ? : "kernel");
ret = -ENOENT;
@@ -2275,7 +2272,7 @@ static int find_probe_trace_events_from_map(struct 
perf_probe_event *pev,
}
 
ret = 0;
-   map__for_each_symbol(map, sym, nd) {
+   while ((sym = map__find_symbol_by_name_from(map, pp->function, NULL, 
sym))) {
tev = (*tevs) + ret;
tp = &tev->point;
if (ret == num_matched_functions) {
-- 
2.2.1

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

[PATCH v3 1/3] perf tools: Add from argument to dso__find_symbol_by_name()

[Namhyung Kim]

When a dso contains multiple symbols which have same name, current
dso__find_symbol_by_name() only finds an one of them and there's no way
to get the all symbols without going through the rbtree.

So add the new 'from' argument to dso__find_symbol_by_name() to remember
current symbol position and returns next symbol if it provided.  For the
first call the from should be NULL and the returned symbol should be
used as from to the next call.  It will return NULL if there's no symbol
that has given name anymore.

Signed-off-by: Namhyung Kim 
---
 tools/perf/util/map.c| 13 ++---
 tools/perf/util/map.h|  3 +++
 tools/perf/util/symbol.c | 41 -
 tools/perf/util/symbol.h |  2 +-
 4 files changed, 50 insertions(+), 9 deletions(-)

diff --git a/tools/perf/util/map.c b/tools/perf/util/map.c
index 62ca9f2607d5..01e2696ca8b5 100644
--- a/tools/perf/util/map.c
+++ b/tools/perf/util/map.c
@@ -301,8 +301,9 @@ struct symbol *map__find_symbol(struct map *map, u64 addr,
return dso__find_symbol(map->dso, map->type, addr);
 }
 
-struct symbol *map__find_symbol_by_name(struct map *map, const char *name,
-   symbol_filter_t filter)
+struct symbol *map__find_symbol_by_name_from(struct map *map, const char *name,
+symbol_filter_t filter,
+struct symbol *from)
 {
if (map__load(map, filter) < 0)
return NULL;
@@ -310,7 +311,13 @@ struct symbol *map__find_symbol_by_name(struct map *map, 
const char *name,
if (!dso__sorted_by_name(map->dso, map->type))
dso__sort_by_name(map->dso, map->type);
 
-   return dso__find_symbol_by_name(map->dso, map->type, name);
+   return dso__find_symbol_by_name(map->dso, map->type, name, from);
+}
+
+struct symbol *map__find_symbol_by_name(struct map *map, const char *name,
+   symbol_filter_t filter)
+{
+   return map__find_symbol_by_name_from(map, name, filter, NULL);
 }
 
 struct map *map__clone(struct map *map)
diff --git a/tools/perf/util/map.h b/tools/perf/util/map.h
index 6951a9d42339..69acc58e6f9a 100644
--- a/tools/perf/util/map.h
+++ b/tools/perf/util/map.h
@@ -138,6 +138,9 @@ struct symbol *map__find_symbol(struct map *map,
u64 addr, symbol_filter_t filter);
 struct symbol *map__find_symbol_by_name(struct map *map, const char *name,
symbol_filter_t filter);
+struct symbol *map__find_symbol_by_name_from(struct map *map, const char *name,
+symbol_filter_t filter,
+struct symbol *from);
 void map__fixup_start(struct map *map);
 void map__fixup_end(struct map *map);
 
diff --git a/tools/perf/util/symbol.c b/tools/perf/util/symbol.c
index c24c5b83156c..e5800497ca61 100644
--- a/tools/perf/util/symbol.c
+++ b/tools/perf/util/symbol.c
@@ -396,6 +396,7 @@ static struct symbol *symbols__find_by_name(struct rb_root 
*symbols,
const char *name)
 {
struct rb_node *n;
+   struct symbol_name_rb_node *s;
 
if (symbols == NULL)
return NULL;
@@ -403,7 +404,6 @@ static struct symbol *symbols__find_by_name(struct rb_root 
*symbols,
n = symbols->rb_node;
 
while (n) {
-   struct symbol_name_rb_node *s;
int cmp;
 
s = rb_entry(n, struct symbol_name_rb_node, rb_node);
@@ -414,10 +414,24 @@ static struct symbol *symbols__find_by_name(struct 
rb_root *symbols,
else if (cmp > 0)
n = n->rb_right;
else
-   return &s->sym;
+   break;
}
 
-   return NULL;
+   if (n == NULL)
+   return NULL;
+
+   /* return first symbol that has same name (if any) */
+   for (n = rb_prev(n); n; n = rb_prev(n)) {
+   struct symbol_name_rb_node *tmp;
+
+   tmp = rb_entry(n, struct symbol_name_rb_node, rb_node);
+   if (strcmp(tmp->sym.name, s->sym.name))
+   break;
+
+   s = tmp;
+   }
+
+   return &s->sym;
 }
 
 struct symbol *dso__find_symbol(struct dso *dso,
@@ -436,10 +450,27 @@ struct symbol *dso__next_symbol(struct symbol *sym)
return symbols__next(sym);
 }
 
+/*
+ * When @from is NULL, returns first symbol that matched with @name.
+ * Otherwise, returns next symbol after @from in case some (local) symbols
+ * have same name, or NULL.
+ */
 struct symbol *dso__find_symbol_by_name(struct dso *dso, enum map_type type,
-   const char *name)
+   const char *name, struct symbol *from)
 {
-   return symbols__find_by_name(&dso->symbol_names[type], name);
+   struct rb_node *n;
+   

Re: [PATCH v3 4/4] pinctrl: qcom: Add support for reset for apq8064

[Stephen Boyd]

On 01/14/2015 03:38 PM, Timur Tabi wrote:
> On Fri, Aug 29, 2014 at 9:30 AM, Pramod Gurav
>  wrote:
>> +static void msm_pinctrl_setup_pm_reset(struct msm_pinctrl *pctrl)
>> +{
>> +   int i = 0;
>> +   const struct msm_function *func = pctrl->soc->functions;
>> +
>> +   for (; i <= pctrl->soc->nfunctions; i++)
> Shouldn't this be
>
> i < pctrl->soc->nfunctions
>
> As it stands, if nfunctions == 0, this function crashes.
>

I think so. Can you send a patch? Plus it would be nice to move i = 0 in
the for loop at the same time.

-- 
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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: fs: locks: WARNING: CPU: 16 PID: 4296 at fs/locks.c:236 locks_free_lock_context+0x10d/0x240()

[Sasha Levin]

On 01/14/2015 09:27 AM, Jeff Layton wrote:
> On Tue, 13 Jan 2015 17:50:45 -0500
> Sasha Levin  wrote:
> 
>> On 01/13/2015 04:44 PM, Jeff Layton wrote:
>>> On Tue, 13 Jan 2015 00:11:37 -0500
>>> Sasha Levin  wrote:
>>>
 Hey Jeff,

 While fuzzing with trinity inside a KVM tools guest running the latest 
 -next
 kernel, I've stumbled on the following spew:

 [  887.078606] WARNING: CPU: 16 PID: 4296 at fs/locks.c:236 
 locks_free_lock_context+0x10d/0x240()
 [  887.079703] Modules linked in:
 [  887.080288] CPU: 16 PID: 4296 Comm: trinity-c273 Not tainted 
 3.19.0-rc4-next-20150112-sasha-00053-g23c147e02e-dirty #1710
 [  887.082229]     
 8804c9f4f8e8
 [  887.083773]  9154e0a6  8804cad98000 
 8804c9f4f938
 [  887.085280]  8140a4d0 0001 81bf0d2d 
 8804c9f4f988
 [  887.086792] Call Trace:
 [  887.087320] dump_stack (lib/dump_stack.c:52)
 [  887.088247] warn_slowpath_common (kernel/panic.c:447)
 [  887.089342] ? locks_free_lock_context (fs/locks.c:236 (discriminator 3))
 [  887.090514] warn_slowpath_null (kernel/panic.c:481)
 [  887.091629] locks_free_lock_context (fs/locks.c:236 (discriminator 3))
 [  887.092782] __destroy_inode (fs/inode.c:243)
 [  887.093817] destroy_inode (fs/inode.c:268)
 [  887.094833] evict (fs/inode.c:574)
 [  887.095808] iput (fs/inode.c:1503)
 [  887.096687] __dentry_kill (fs/dcache.c:323 fs/dcache.c:508)
 [  887.097683] ? _raw_spin_trylock (kernel/locking/spinlock.c:136)
 [  887.098733] ? dput (fs/dcache.c:545 fs/dcache.c:648)
 [  887.099672] dput (fs/dcache.c:649)
 [  887.100552] __fput (fs/file_table.c:227)
>>>
>>> So, looking at this a bit more...
>>>
>>> It's clear that we're at the dput in __fput at this point. Much earlier
>>> in __fput, we call locks_remove_file to remove all of the locks that
>>> are associated with the file description.
>>>
>>> Evidently though, something didn't go right there. The two most likely
>>> scenarios to my mind are:
>>>
>>> A) a lock raced onto the list somehow after that point. That seems
>>> unlikely since presumably the fcheck should have failed at that point.
>>>
>>> ...or...
>>>
>>> B) the CPU that called locks_remove_file mistakenly thought that
>>> inode->i_flctx was NULL when it really wasn't (stale cache, perhaps?).
>>> That would make it skip trying to remove any flock locks.
>>>
>>> B seems more likely to me, and if it's the case then that would seem to
>>> imply that we need some memory barriers (or maybe some ACCESS_ONCE
>>> calls) in these codepaths. I'll have to sit down and work through it to
>>> see what makes the most sense.
>>>
>>> If your debugging seems to jive with this, then one thing that might be
>>> interesting would be to comment out these two lines in
>>> locks_remove_flock:
>>>
>>> if (!file_inode(filp)->i_flctx)
>>> return;
>>>
>>> ...and see if it's still reproducible. That's obviously not a real fix
>>> for this problem, but it might help prove whether the above suspicion
>>> is correct.
>>
>> Removing those two lines makes the issue go away.
>>
>> I'm guessing that figuring out which filesystem we were abusing isn't
>> interesting anymore...
>>
> 
> Sigh. I've been trying to reproduce this today. I've set up two
> different KVM guests on two different hosts, and run trinity on both,
> and I can't seem to get this warning to pop.
> 
> Could you share what trinity command-line options you're using? Any
> other special setup I should be considering to reproduce it?
> 
> I was hoping to get it to reproduce so I could test out potential
> memory barrier fixes...

I don't think there's anything special about my setup here that can
trigger that, specially if it's not dependant on a filesystem in use.

I'm running trinity with: ./trinity -xsched_setattr -xsetpriority
-xunshare -xreboot -xshutdown -xnfsservctl -xclock_nanosleep -xuselib
-xperf_event_open -m --quiet --dangerous -C 400 -l off

If that doesn't end up helping, I'd be happy to test out fixes here,
it usually reproduces quickly.


Thanks,
Sasha
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] task_mmu: Add user-space support for resetting mm->hiwater_rss (peak RSS)

[Kirill A. Shutemov]

On Wed, Jan 14, 2015 at 03:22:25PM +, Petr Cermak wrote:
> On Wed, Jan 07, 2015 at 07:24:52PM +0200, Kirill A. Shutemov wrote:
> > And how it's not an ABI break?
> I don't think this is an ABI break because the current behaviour is not
> changed unless you write "5" to /proc/pid/clear_refs. If you do, you are
> explicitly requesting the new functionality.
> 
> > We have never-lowering VmHWM for 9+ years. How can you know that nobody
> > expects this behaviour?
> This is why we sent an RFC [1] several weeks ago. We expect this to be
> used mainly by performance-related tools (e.g. profilers) and from the
> comments in the code [2] VmHWM seems to be a best-effort counter. If this
> is strictly a no-go, I can only think of the following two alternatives:
> 
>   1. Add an extra resettable field to /proc/pid/status (e.g.
>  resettable_hiwater_rss). While this doesn't violate the current
>  definition of VmHWM, it adds an extra line to /proc/pid/status,
>  which I think is a much bigger issue.
>   2. Introduce a new proc fs file to task_mmu (e.g.
>  /proc/pid/profiler_stats), but this feels like overengineering.

BTW, we have memory.max_usage_in_byte in memory cgroup. And it's resetable.
Wouldn't it be enough for your profiling use-case?

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

Re: [PATCH v3 4/4] pinctrl: qcom: Add support for reset for apq8064

[Timur Tabi]

On Fri, Aug 29, 2014 at 9:30 AM, Pramod Gurav
 wrote:
>
> +static void msm_pinctrl_setup_pm_reset(struct msm_pinctrl *pctrl)
> +{
> +   int i = 0;
> +   const struct msm_function *func = pctrl->soc->functions;
> +
> +   for (; i <= pctrl->soc->nfunctions; i++)

Shouldn't this be

i < pctrl->soc->nfunctions

As it stands, if nfunctions == 0, this function crashes.

-- 
Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] task_mmu: Add user-space support for resetting mm->hiwater_rss (peak RSS)

[Kirill A. Shutemov]

On Wed, Jan 14, 2015 at 03:22:25PM +, Petr Cermak wrote:
> On Wed, Jan 07, 2015 at 07:24:52PM +0200, Kirill A. Shutemov wrote:
> > And how it's not an ABI break?
> I don't think this is an ABI break because the current behaviour is not
> changed unless you write "5" to /proc/pid/clear_refs. If you do, you are
> explicitly requesting the new functionality.

I'm not sure if it should be considered ABI break or not. Just asking.

I would like to hear opinion from other people.
 
> > We have never-lowering VmHWM for 9+ years. How can you know that nobody
> > expects this behaviour?
> This is why we sent an RFC [1] several weeks ago. We expect this to be
> used mainly by performance-related tools (e.g. profilers) and from the
> comments in the code [2] VmHWM seems to be a best-effort counter. If this
> is strictly a no-go, I can only think of the following two alternatives:
> 
>   1. Add an extra resettable field to /proc/pid/status (e.g.
>  resettable_hiwater_rss). While this doesn't violate the current
>  definition of VmHWM, it adds an extra line to /proc/pid/status,
>  which I think is a much bigger issue.

I don't think extra line is bigger issue. Sane applications would look for
a key, not line number. We do add lines there. I've posted patch which
adds one more just today ;)

>   2. Introduce a new proc fs file to task_mmu (e.g.
>  /proc/pid/profiler_stats), but this feels like overengineering.
> 
> > And why do you reset hiwater_rss, but not hiwater_vm?
> This is a good point. Should we reset both using the same flag, or
> introduce a new one ("6")?
> 
> [1] lkml.iu.edu/hypermail/linux/kernel/1412.1/01877.html
> [2] task_mmu.c:32: "... such snapshots can always be inconsistent."
-- 
 Kirill A. Shutemov
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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 -mm] vmscan: move reclaim_state handling to shrink_slab

[Andrew Morton]

On Wed, 14 Jan 2015 16:55:36 +0300 Vladimir Davydov  
wrote:

> current->reclaim_state is only used to count the number of slab pages
> reclaimed by shrink_slab(). So instead of initializing it before we are
> going to call try_to_free_pages() or shrink_zone(), let's set in
> directly in shrink_slab().
> 
> This patch also makes shrink_slab() return the number of reclaimed slab
> pages (obtained from reclaim_state) instead of the number of reclaimed
> objects, because the latter is not of much use - it was only checked by
> drop_slab() to decide whether it should continue reclaim or abort. The
> number of reclaimed pages is more appropriate, because it also can be
> used by shrink_zone() to accumulate scan_control->nr_reclaimed.

Not sure that this is a good change.  If shrink_slab() managed to free
some objects but didn't free any pages then that's a good sign that
additional calls to shrink_slab() *will* free some pages.  With this
change, drop_slab_node() can give up too early.

The general philosophy throughout here is: "pass it nr_to_scan, it
returns nr_scanned/nr_freed".  Switching the return value to
nr_pages_freed kinda breaks that paradigm.

> Note that after this patch try_to_free_mem_cgroup_pages() will count not
> only reclaimed user pages, but also slab pages, which is expected,
> because it can reclaim kmem from kmem-active sub cgroups.
> 
>  mm/page_alloc.c |4 ---
>  mm/vmscan.c |   73 
> ---
>  2 files changed, 27 insertions(+), 50 deletions(-)

That's nice though.


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

samsung-laptop: enable better lid handling

[Julijonas Kikutis]

Hello,

I sent the patch  to linux-kernel,
platform-driver-x86, and to the maintainer of samsung-laptop a month ago
and have not received any response. Any response would be welcome.

I have some additional thoughts about the patch. I don't know whether it
is a good idea to introduce a whitelist of laptops that the special
command applies to like I did, or would it be better to enable that
command for every laptop that reports having that command. I also
thought that maybe the maintainer of the module has some more Samsung
laptops to test.

Moreover, I was asked about the unavailability of this module which
exposes some abilities of the laptop otherwise missing (e.g. the battery
saving mode, SABI access for this lid handling issue, some LED
functionality for other laptops) in UEFI mode. Unfortunately, I could
not help about that. I see that he has asked about that himself
 but got no reply. I would be also
interested in the state of this issue.

Thank you.

Julijonas

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] usb: dwc2: call dwc2_is_controller_alive() under spinlock

[Paul Zimmerman]

> From: Felipe Balbi [mailto:ba...@ti.com]
> Sent: Wednesday, January 14, 2015 2:50 PM
> 
> On Wed, Jan 14, 2015 at 10:45:26PM +, Paul Zimmerman wrote:
> > > From: Felipe Balbi [mailto:ba...@ti.com]
> > > Sent: Wednesday, January 14, 2015 2:40 PM
> > >
> > > On Wed, Jan 14, 2015 at 10:28:54PM +, Paul Zimmerman wrote:
> > > > > From: Felipe Balbi [mailto:ba...@ti.com]
> > > > > Sent: Wednesday, January 14, 2015 1:46 PM
> > > > >
> > > > > On Wed, Jan 14, 2015 at 04:41:23PM -0500, Alan Stern wrote:
> > > > > > > > > This is really, really odd. Register accesses are atomic, so 
> > > > > > > > > the lock
> > > > > > > > > isn't really doing anything. Besides, you're calling
> > > > > > > > > dwc2_is_controller_alive() from within the IRQ handler, so 
> > > > > > > > > IRQs are
> > > > > > > > > already disabled.
> > > > > > > >
> > > > > > > > Spinlocks sometimes do more than you think.  For instance, here 
> > > > > > > > the
> > > > > > > > lock prevents the register access from happening while some 
> > > > > > > > other CPU
> > > > > > > > is holding the lock.  If a silicon quirk causes the register 
> > > > > > > > access to
> > > > > > > > interfere with other activities, this could be important.
> > > > > > >
> > > > > > > readl() (which is used by dwc2_is_controller_alive()) adds a 
> > > > > > > memory
> > > > > > > barrier to the register accesses, that should force all register
> > > > > > > accesses the be correctly ordered.
> > > > > >
> > > > > > Memory barriers will order accesses that are all made on the same 
> > > > > > CPU
> > > > > > with respect to each other.  They do not order these accesses 
> > > > > > against
> > > > > > accesses made from another CPU -- that's why we have spinlocks.  :-)
> > > > >
> > > > > a fair point :-) The register is still read-only, so that shouldn't
> > > > > matter either :-)
> > > > >
> > > > > > >  I fail to see how a silicon quirk
> > > > > > > could cause this and if, indeed, it does, I'd be more comfortable 
> > > > > > > with a
> > > > > > > proper STARS tickect number from synopsys :-s
> > > > > >
> > > > > > Maybe accessing this register somehow resets something else.  I 
> > > > > > don't
> > > > > > know.  It seems unlikely, but at least it explains how adding a
> > > > > > spinlock could fix the problem.
> > > > >
> > > > > I would really need Paul (or someone at Synopsys) to confirm this
> > > > > somehow. Maybe it has something to do with how the register is
> > > > > implemented, dunno.
> > > > >
> > > > > Paul, do you have any idea what could cause this ? Could the HW into
> > > > > some weird state if we read GSNPSID at random locations or when data 
> > > > > is
> > > > > being transferred, or anything like that ?
> > > >
> > > > Only thing I can think of is that there is some silicon bug in Robert's
> > > > platform. But I am not aware of any STARs that mention accesses to the
> > > > GSNPSID register as being problematic.
> > > >
> > > > Funny thing is, this code has been basically the same since at least
> > > > November 2013. So I think some other recent change must have modified
> > > > the timing of the register accesses, or something like that. But that's
> > > > just handwaving, really.
> > >
> > > Alright, I'll apply this patch but for 3.20 with a stable tag as I have
> > > already sent my last pull request to Greg. Unless someone has a really
> > > big complaint about doing things as such.
> >
> > It should go to 3.19-rc shouldn't it? It's a fix, and Robert's platform
> > is broken without it, IIUC.
> 
> It can also be categorized as "has-never-worked-before" before the code
> has been like this forever. Since we don't really have a git bisect
> result pointing to a commit that went in v3.19 merge window, I'm not
> sure how I can convince myself that this absolutely needs to be in
> v3.19.
> 
> At a minimum, I need a proper bisection with a proper commit being
> blamed (even if it's a commit from months ago). From my point of view,
> debugging of this "regression" has not been finalized and we're just
> "assuming" it's caused by GSNPSID because moving that inside the
> spin_lock seems to fix the problem.

On further investigation, I was wrong about "this code has been
basically the same since at least November 2013". Prior to commit
db8178c33db "usb: dwc2: Update common interrupt handler to call gadget
interrupt handler" from November 2014, the gadget interrupt handler
did not read from the GSNPSID register.

So likely the bug in Robert's hardware has been there all along, and
that commit just caused it to manifest itself.

-- 
Paul

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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/6] ARM: at91: pm: rework cpu detection

[Jean-Christophe PLAGNIOL-VILLARD]

> On Jan 15, 2015, at 4:21 AM, Boris Brezillon 
>  wrote:
> 
> Hi Jean-Christophe,
> 
> On Wed, 14 Jan 2015 20:14:12 +0100
> Jean-Christophe PLAGNIOL-VILLARD  wrote:
> 
>> On 22:23 Mon 12 Jan , Alexandre Belloni wrote:
>>> Store SoC differences in a struct to remove cpu_is_* usage.
>>> 
>>> Signed-off-by: Alexandre Belloni 
>>> ---
>>> arch/arm/mach-at91/pm.c | 54 
>>> ++---
>>> 1 file changed, 33 insertions(+), 21 deletions(-)
>>> 
>>> diff --git a/arch/arm/mach-at91/pm.c b/arch/arm/mach-at91/pm.c
>>> index 9b15169a1c62..79aa793d1f00 100644
>>> --- a/arch/arm/mach-at91/pm.c
>>> +++ b/arch/arm/mach-at91/pm.c
>>> @@ -17,6 +17,7 @@
>>> #include 
>>> #include 
>>> #include 
>>> +#include 
>>> #include 
>>> #include 
>>> #include 
>>> @@ -32,6 +33,11 @@
>>> #include "generic.h"
>>> #include "pm.h"
>>> 
>>> +static struct {
>>> +   unsigned long uhp_udp_mask;
>>> +   int memctrl;
>>> +} at91_pm_data;
>>> +
>>> static void (*at91_pm_standby)(void);
>>> 
>>> static int at91_pm_valid_state(suspend_state_t state)
>>> @@ -71,17 +77,9 @@ static int at91_pm_verify_clocks(void)
>>> scsr = at91_pmc_read(AT91_PMC_SCSR);
>>> 
>>> /* USB must not be using PLLB */
>>> -   if (cpu_is_at91rm9200()) {
>>> -   if ((scsr & (AT91RM9200_PMC_UHP | AT91RM9200_PMC_UDP)) != 0) {
>>> -   pr_err("AT91: PM - Suspend-to-RAM with USB still 
>>> active\n");
>>> -   return 0;
>>> -   }
>>> -   } else if (cpu_is_at91sam9260() || cpu_is_at91sam9261() || 
>>> cpu_is_at91sam9263()
>>> -   || cpu_is_at91sam9g20() || cpu_is_at91sam9g10()) {
>>> -   if ((scsr & (AT91SAM926x_PMC_UHP | AT91SAM926x_PMC_UDP)) != 0) {
>>> -   pr_err("AT91: PM - Suspend-to-RAM with USB still 
>>> active\n");
>>> -   return 0;
>>> -   }
>>> +   if ((scsr & at91_pm_data.uhp_udp_mask) != 0) {
>>> +   pr_err("AT91: PM - Suspend-to-RAM with USB still active\n");
>>> +   return 0;
>>> }
>>> 
>>> /* PCK0..PCK3 must be disabled, or configured to use clk32k */
>>> @@ -149,18 +147,13 @@ static int at91_pm_enter(suspend_state_t state)
>>>  * turning off the main oscillator; reverse on wakeup.
>>>  */
>>> if (slow_clock) {
>>> -   int memctrl = AT91_MEMCTRL_SDRAMC;
>>> -
>>> -   if (cpu_is_at91rm9200())
>>> -   memctrl = AT91_MEMCTRL_MC;
>>> -   else if (cpu_is_at91sam9g45())
>>> -   memctrl = AT91_MEMCTRL_DDRSDR;
>>> #ifdef CONFIG_AT91_SLOW_CLOCK
>>> /* copy slow_clock handler to SRAM, and call it 
>>> */
>>> memcpy(slow_clock, at91_slow_clock, 
>>> at91_slow_clock_sz);
>>> #endif
>>> slow_clock(at91_pmc_base, at91_ramc_base[0],
>>> -  at91_ramc_base[1], memctrl);
>>> +  at91_ramc_base[1],
>>> +  at91_pm_data.memctrl);
>>> break;
>>> } else {
>>> pr_info("AT91: PM - no slow clock mode enabled 
>>> ...\n");
>>> @@ -237,10 +230,29 @@ static int __init at91_pm_init(void)
>>> 
>>> pr_info("AT91: Power Management%s\n", (slow_clock ? " (with slow clock 
>>> mode)" : ""));
>>> 
>>> -   /* AT91RM9200 SDRAM low-power mode cannot be used with self-refresh. */
>>> -   if (cpu_is_at91rm9200())
>>> +   at91_pm_data.memctrl = AT91_MEMCTRL_SDRAMC;
>>> +
>>> +   if (of_machine_is_compatible("atmel,at91rm9200")) {
>>> +   /*
>>> +* AT91RM9200 SDRAM low-power mode cannot be used with
>>> +* self-refresh.
>>> +*/
>>> at91_ramc_write(0, AT91RM9200_SDRAMC_LPR, 0);
>>> -   
>>> +
>>> +   at91_pm_data.uhp_udp_mask = AT91RM9200_PMC_UHP |
>>> +   AT91RM9200_PMC_UDP;
>>> +   at91_pm_data.memctrl = AT91_MEMCTRL_MC;
>>> +   } else if (of_machine_is_compatible("atmel,at91sam9260") ||
>>> +  of_machine_is_compatible("atmel,at91sam9g20") ||
>>> +  of_machine_is_compatible("atmel,at91sam9261") ||
>>> +  of_machine_is_compatible("atmel,at91sam9g10") ||
>>> +  of_machine_is_compatible("atmel,at91sam9263")) {
>> nack here
>> 
>> you switch for runtime information from the SOC register store in ram to DT
>> 
>> DT is great but I do prefer to rely on the SoC register here as the whole was
>> also to check that the is correct
> 
> Well, cpu_is_xxx macros are defined in a mach specific header, and we're
> currently trying to enable multi platform support. 

Yes does not mean we can not move this, use the REAL hardware detected cpu is 
better
as you can check that the DT is valid for this SoC and also have fixup for a 

Re: [PATCH] ARM: clk: add clk-asm9260 driver

[Mike Turquette]

Quoting Oleksij Rempel (2015-01-08 00:59:27)
> diff --git a/drivers/clk/clk-asm9260.c b/drivers/clk/clk-asm9260.c
> new file mode 100644
> index 000..6b1c220
> --- /dev/null
> +++ b/drivers/clk/clk-asm9260.c



> +static const char *clk_names[] = {
> +   [REFCLK]= "oscillator",
> +   [SYSPLL]= "pll",
> +   [I2S0_MCLK] = "i2s0_mclk",
> +   [I2S1_MCLK] = "i2s1_mclk",
> +   [RTC_OSC]   = "rtc_osc",
> +   [USB_PLL]   = "usb_pll",
> +};

Why keep this list of names? Only clk_names[REFCLK] is used below and it
is overwritten by the name supplied by DT.



> +static void __init asm9260_acc_init(struct device_node *np)
> +{
> +   struct clk *clk;
> +   u32 rate;
> +   int n;
> +   u32 accuracy = 0;
> +
> +   base = of_io_request_and_map(np, 0, np->name);
> +   if (!base)
> +   panic("%s: unable to map resource", np->name);
> +
> +   /* register pll */
> +   rate = (ioread32(base + HW_SYSPLLCTRL) & 0x) * 100;
> +
> +   clk_names[REFCLK] = of_clk_get_parent_name(np, 0);
> +   accuracy = clk_get_accuracy(__clk_lookup(clk_names[REFCLK]));
> +   clk = clk_register_fixed_rate_with_accuracy(NULL, clk_names[SYSPLL],
> +   clk_names[REFCLK], 0, rate, accuracy);

This is different. Why do the PLLs inherit REFCLKs accuracy? Please see
__clk_recalc_accuracies in drivers/clk/clk.c if you haven't already. We
propagate accuracy through the clock tree already.

> +
> +   if (IS_ERR(clk))
> +   panic("%s: can't register REFCLK. Check DT!", np->name);
> +
> +   for (n = 0; n < ARRAY_SIZE(asm9260_mux_clks); n++) {
> +   const struct asm9260_mux_clock *mc = &asm9260_mux_clks[n];
> +
> +   mc->parent_names[0] = clk_names[REFCLK];
> +   clk = clk_register_mux_table(NULL, mc->name, mc->parent_names,
> +   mc->num_parents, mc->flags, base + mc->offset,
> +   0, mc->mask, 0, mc->table, &asm9260_clk_lock);
> +   }
> +
> +   /* clock mux gate cells */
> +   for (n = 0; n < ARRAY_SIZE(asm9260_mux_gates); n++) {
> +   const struct asm9260_gate_data *gd = &asm9260_mux_gates[n];
> +
> +   clk = clk_register_gate(NULL, gd->name,
> +   gd->parent_name, gd->flags | CLK_SET_RATE_PARENT,
> +   base + gd->reg, gd->bit_idx, 0, &asm9260_clk_lock);
> +   }
> +
> +   /* clock div cells */
> +   for (n = 0; n < ARRAY_SIZE(asm9260_div_clks); n++) {
> +   const struct asm9260_div_clk *dc = &asm9260_div_clks[n];
> +
> +   clks[dc->idx] = clk_register_divider(NULL, dc->name,
> +   dc->parent_name, CLK_SET_RATE_PARENT,
> +   base + dc->reg, 0, 8, CLK_DIVIDER_ONE_BASED,
> +   &asm9260_clk_lock);
> +   }
> +
> +   /* clock ahb gate cells */
> +   for (n = 0; n < ARRAY_SIZE(asm9260_ahb_gates); n++) {
> +   const struct asm9260_gate_data *gd = &asm9260_ahb_gates[n];
> +
> +   clks[gd->idx] = clk_register_gate(NULL, gd->name,
> +   gd->parent_name, gd->flags, base + gd->reg,
> +   gd->bit_idx, 0, &asm9260_clk_lock);
> +   }
> +
> +   /* check for errors on leaf clocks */
> +   for (n = 0; n < MAX_CLKS; n++) {
> +   if (!IS_ERR(clks[n]))
> +   continue;
> +
> +   pr_err("%s: Unable to register leaf clock %d\n",
> +   np->full_name, n);
> +   goto fail;
> +   }
> +
> +   /* register clk-provider */
> +   clk_data.clks = clks;
> +   clk_data.clk_num = MAX_CLKS;
> +   of_clk_add_provider(np, of_clk_src_onecell_get, &clk_data);
> +   return;
> +fail:
> +   iounmap(base);
> +}
> +CLK_OF_DECLARE(asm9260_acc, "alphascale,asm9260-clock-controller",
> +   asm9260_acc_init);

Where is the DT binding definition for this clock provider?

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

[LSF/MM TOPIC] userfaultfd

[Andrea Arcangeli]

Hello,

I would like to attend this year (2015) LSF/MM summit. I'm
particularly interested about the MM track, in order to get help in
finalizing the userfaultfd feature I've been working on lately.

An overview on the userfaultfd feature can be read here:

   http://lwn.net/Articles/615086/

In essence the userfault feature could be imagined as an optimal
implementation for userland driven on demand paging similar to
PROT_NONE+SIGSEGV.

userfaultfd is fundamentally allowing to manage memory at the
pagetable level by delivering the page fault notification to userland
to handle it with proper userfaultfd commands that mangle the address
space, without involving heavyweight structures like vmas (in fact the
userfaultfd runtime load never takes the mmap_sem for writing, just
like its kernel counterpart wouldn't). The number of vmas is limited
too so they're not suitable if there are too many scattered faults and
the address space is not limited. userfaultfd allows all userfaults to
happen in parallel from different threads and it relies on userland to
use atomic copy or move commands to resolve the userfaults.

By adding more featured commands to the userfaultfd protocol (spoken
on the fd, like the basic atomic copy command that is needed to
resolve the userfault) in the future we can also mark regions readonly
and trap only wrprotect faults (or both wrprotect and non present
faults simultaneously).

Different userfaultfd can already be used independently by multiple
librarians and the main application within the same process.

The userfaultfd once opened, can also be passed using unix domain
sockets to a manager process (use case 5) below wants to do this), so the
same manager process could handle the userfaults of a multitude of
different process without them being aware about what is going on
(well of course unless they later try to use the userfaultfd themself
on the same region the manager is already tracking, which is a corner
case the relevancy of which should be discussed).

There was interest from multiple users, hope I'm not forgetting some:

1) KVM postcopy live migration (one form of cloud memory
   externalization). KVM postcopy live migration is the primary driver
   of this work:
   http://blog.zhaw.ch/icclab/setting-up-post-copy-live-migration-in-openstack/
   )

2) KVM postcopy live snapshotting (allowing to limit/throttle the
   memory usage, unlike fork would).

3) KVM userfaults on shared memory (currently only anonymous memory
   is handled by the userfaultfd but there's nothing that prevents to
   extend it and allow to register a tmpfs region in the userfaultfd
   and fire an userfault if the tmpfs page is not present)

4) alternate mechanism to notify web browsers or apps on embedded
   devices that volatile pages have been reclaimed. This basically
   avoids the need to run a syscall before the app can access with the
   CPU the virtual regions marked volatile. This also requires point 3)
   to be fulfilled, as volatile pages happily apply to tmpfs.

5) postcopy live migration of binaries inside linux containers
   (provided there is a userfaultfd command [not an external syscall
   like the original implementation] that allows to copy memory
   atomically in the userfaultfd "mm" and not in the manager "mm",
   hence the main reason the external syscalls are going away, and in
   turn MADV_USERFAULT fd-less is going away as well).

6) qemu linux-user binary emulation was also briefly interested about
   the wrprotection fault notification for non-x86 archs. In this
   context the userfaultfd ""might"" (not sure) be useful to JIT
   emulation to efficiently protect the translated regions by only
   wrprotecting the page table without having to split or merge vmas
   (the risk of running out of vmas isn't there for this use case as
   the translated cache is probably limited in size and not heavily
   scattered).

7) distributed shared memory that could allow simultaneous mapping of
   regions marked readonly and collapse them on the first exclusive
   write. I'm mentioning it as a corollary, because I'm not aware of
   anybody who is planning to use it that way (still I'd like that
   this will be possible too just in case it finds its way later on).

The currently planned API (as hinted above) is already different to
the first version of the code posted a couple of months ago, thanks to
the valuable feedback received by the community so far.

As usual suggestions will be welcome, thanks!
Andrea
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 3.18 126/150] Revert "Input: atmel_mxt_ts - use deep sleep mode when stopped"

[Dmitry Torokhov]

Hi Greg,

On Tue, Jan 13, 2015 at 11:23:17PM -0800, Greg Kroah-Hartman wrote:
> 3.18-stable review patch.  If anyone has any objections, please let me know.
> 
> --
> 
> From: Linus Torvalds 
> 
> commit 7f4054836d811c650c51f9c93088f8ebd61b0020 upstream.
> 
> This reverts commit 9d469d033d135d80742a4e39e6bbb4519dd5eee1.
> 
> It breaks the Chromebook Pixel touchpad (and touchscreen).
> 
> Reported-by: Dirk Hohndel 
> Bisected-by: Linus Torvalds 
> Cc: Nick Dyer 
> Cc: Benson Leung 
> Cc: Yufeng Shen 
> Cc: Dmitry Torokhov 
> Signed-off-by: Linus Torvalds 
> Signed-off-by: Greg Kroah-Hartman 

I'd rather we did not apply this to stable just yet - the patch does not
fix Dirk's Pixel and Linus's still flaky and I have another patch I'm
waiting on them to try out.

Thanks.

> 
> ---
>  drivers/input/touchscreen/atmel_mxt_ts.c |   99 
> ---
>  1 file changed, 26 insertions(+), 73 deletions(-)
> 
> --- a/drivers/input/touchscreen/atmel_mxt_ts.c
> +++ b/drivers/input/touchscreen/atmel_mxt_ts.c
> @@ -99,13 +99,9 @@
>  #define MXT_T6_STATUS_COMSERR(1 << 2)
>  
>  /* MXT_GEN_POWER_T7 field */
> -struct t7_config {
> - u8 idle;
> - u8 active;
> -} __packed;
> -
> -#define MXT_POWER_CFG_RUN0
> -#define MXT_POWER_CFG_DEEPSLEEP  1
> +#define MXT_POWER_IDLEACQINT 0
> +#define MXT_POWER_ACTVACQINT 1
> +#define MXT_POWER_ACTV2IDLETO2
>  
>  /* MXT_GEN_ACQUIRE_T8 field */
>  #define MXT_ACQUIRE_CHRGTIME 0
> @@ -117,6 +113,7 @@ struct t7_config {
>  #define MXT_ACQUIRE_ATCHCALSTHR  7
>  
>  /* MXT_TOUCH_MULTI_T9 field */
> +#define MXT_TOUCH_CTRL   0
>  #define MXT_T9_ORIENT9
>  #define MXT_T9_RANGE 18
>  
> @@ -256,7 +253,6 @@ struct mxt_data {
>   bool update_input;
>   u8 last_message_count;
>   u8 num_touchids;
> - struct t7_config t7_cfg;
>  
>   /* Cached parameters from object table */
>   u16 T5_address;
> @@ -672,6 +668,20 @@ static void mxt_proc_t6_messages(struct
>   data->t6_status = status;
>  }
>  
> +static int mxt_write_object(struct mxt_data *data,
> +  u8 type, u8 offset, u8 val)
> +{
> + struct mxt_object *object;
> + u16 reg;
> +
> + object = mxt_get_object(data, type);
> + if (!object || offset >= mxt_obj_size(object))
> + return -EINVAL;
> +
> + reg = object->start_address;
> + return mxt_write_reg(data->client, reg + offset, val);
> +}
> +
>  static void mxt_input_button(struct mxt_data *data, u8 *message)
>  {
>   struct input_dev *input = data->input_dev;
> @@ -1742,60 +1752,6 @@ err_free_object_table:
>   return error;
>  }
>  
> -static int mxt_set_t7_power_cfg(struct mxt_data *data, u8 sleep)
> -{
> - struct device *dev = &data->client->dev;
> - int error;
> - struct t7_config *new_config;
> - struct t7_config deepsleep = { .active = 0, .idle = 0 };
> -
> - if (sleep == MXT_POWER_CFG_DEEPSLEEP)
> - new_config = &deepsleep;
> - else
> - new_config = &data->t7_cfg;
> -
> - error = __mxt_write_reg(data->client, data->T7_address,
> - sizeof(data->t7_cfg), new_config);
> - if (error)
> - return error;
> -
> - dev_dbg(dev, "Set T7 ACTV:%d IDLE:%d\n",
> - new_config->active, new_config->idle);
> -
> - return 0;
> -}
> -
> -static int mxt_init_t7_power_cfg(struct mxt_data *data)
> -{
> - struct device *dev = &data->client->dev;
> - int error;
> - bool retry = false;
> -
> -recheck:
> - error = __mxt_read_reg(data->client, data->T7_address,
> - sizeof(data->t7_cfg), &data->t7_cfg);
> - if (error)
> - return error;
> -
> - if (data->t7_cfg.active == 0 || data->t7_cfg.idle == 0) {
> - if (!retry) {
> - dev_dbg(dev, "T7 cfg zero, resetting\n");
> - mxt_soft_reset(data);
> - retry = true;
> - goto recheck;
> - } else {
> - dev_dbg(dev, "T7 cfg zero after reset, overriding\n");
> - data->t7_cfg.active = 20;
> - data->t7_cfg.idle = 100;
> - return mxt_set_t7_power_cfg(data, MXT_POWER_CFG_RUN);
> - }
> - }
> -
> - dev_dbg(dev, "Initialized power cfg: ACTV %d, IDLE %d\n",
> - data->t7_cfg.active, data->t7_cfg.idle);
> - return 0;
> -}
> -
>  static int mxt_configure_objects(struct mxt_data *data,
>const struct firmware *cfg)
>  {
> @@ -1809,12 +1765,6 @@ static int mxt_configure_objects(struct
>   dev_warn(dev, "Error %d updating config\n", error);
>   }
>  
> - error = mxt_init_t7_power_cfg(data);
> - if (error) {
> - dev_err(dev, "Failed to initialize power cfg\n");
> - return error;
> - }
> -
>   e

Re: [PATCH] RTC: RK808: fix the rtc time reading issue

[Doug Anderson]

Andrew,

On Wed, Jan 14, 2015 at 2:53 PM, Andrew Morton
 wrote:
> On Wed, 14 Jan 2015 11:44:02 -0800 Sonny Rao  wrote:
>
>> On Wed, Jan 14, 2015 at 10:36 AM, Doug Anderson  
>> wrote:
>> > Sonny,
>> >
>> >> Chris, it looks like you swapped the set and the clear of this bit,
>> >> and you're relying on the fact that the i2c transaction takes a
>> >> certain amount of time after the RTC_GET_TIME BIT is set.   I'm not
>> >> sure how long it actually takes, but why not just put in a usleep()
>> >> for the minimum wait time?
>> >
>> > I think we are safe.
>> >
>> > At 400kHz (the max speed of this part) each bit can be transferred no
>> > faster than 2.5us.  In order to do a valid i2c transaction we need to
>> > _at least_ write the address of the device and the data onto the bus,
>> > which is 16 bits.  16 * 2.5us = 40us.  That's above the 31.25us
>> >
>> > Personally I think what Chris has is fine, with the comment.
>>
>> Ok, I'm fine with that if we're sure it's slow enough.  Comment
>> explaining would certainly help.
>
> Thanks, all.  I did this:
>
> --- a/drivers/rtc/rtc-rk808.c~rtc-rk808-fix-the-rtc-time-reading-issue-fix
> +++ a/drivers/rtc/rtc-rk808.c
> @@ -73,10 +73,11 @@ static int rk808_rtc_readtime(struct dev
> return ret;
> }
>
> -   /* After we set the GET_TIME bit, the rtc time couldn't be read
> -* immediately, we should wait up to 31.25 us, about one cycle of
> +   /*
> +* After we set the GET_TIME bit, the rtc time can't be read
> +* immediately. So we should wait up to 31.25 us, about one cycle of
>  * 32khz. If we clear the GET_TIME bit here, the time of i2c transfer
> -* certainly more than 31.25us.
> +* certainly more than 31.25us: 16 * 2.5us at 400kHz bus frequency.
>  */
> ret = regmap_update_bits(rk808->regmap, RK808_RTC_CTRL_REG,
>  BIT_RTC_CTRL_REG_RTC_GET_TIME,

Looks great to me, thanks.

-Doug
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] arch: arm: mach-davinci: cdce949.c: Remove unused function

[Rickard Strandqvist]

2015-01-14 11:22 GMT+01:00 Sekhar Nori :
> Hi Rickard,
>
> On Sunday 07 December 2014 04:32 AM, Rickard Strandqvist wrote:
>> Remove the function cdce_set_rate() that is not used anywhere.
>>
>> This was partially found by using a static code analysis program called 
>> cppcheck.
>>
>> Signed-off-by: Rickard Strandqvist 
>> ---
>>  arch/arm/mach-davinci/cdce949.c  |   37 
>> --
>>  arch/arm/mach-davinci/include/mach/cdce949.h |2 --
>>  2 files changed, 39 deletions(-)
>>
>> diff --git a/arch/arm/mach-davinci/cdce949.c 
>> b/arch/arm/mach-davinci/cdce949.c
>> index abafb92..bccac4a 100644
>> --- a/arch/arm/mach-davinci/cdce949.c
>> +++ b/arch/arm/mach-davinci/cdce949.c
>> @@ -212,43 +212,6 @@ static struct cdce_output output_list[] = {
>>   [5] = { cdce_y5_freqs, ARRAY_SIZE(cdce_y5_freqs) },
>>  };
>>
>> -int cdce_set_rate(struct clk *clk, unsigned long rate)
>
> Without this function, this driver is of no use. I can see that CDCE949
> support has remained unused for long time. I would rather see the entire
> support including cdce949.c and cdce949.h and their references removed.
>
> Thanks,
> Sekhar
>

Hi

Sure, sounds nice :)
I see if I have time to fix it this weekend.

Kind regards
Rickard Strandqvist
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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/5] irqchip: add dumb demultiplexer implementation

[Boris Brezillon]

Hi Rob,

On Wed, 14 Jan 2015 16:24:32 -0600
Rob Herring  wrote:

> On Wed, Jan 14, 2015 at 4:36 AM, Thomas Gleixner  wrote:
> > On Tue, 13 Jan 2015, Rob Herring wrote:
> >> On Tue, Jan 13, 2015 at 12:46 PM, Boris Brezillon
> >>  wrote:
> >> > Some interrupt controllers are multiplexing several peripheral IRQs on
> >> > a single interrupt line.
> >> > While this is not a problem for most IRQs (as long as all peripherals
> >> > request the interrupt with IRQF_SHARED flag set), multiplexing timers and
> >> > other type of peripherals will generate a WARNING (mixing IRQF_NO_SUSPEND
> >> > and !IRQF_NO_SUSPEND is prohibited).
> >> >
> >> > Create a dumb irq demultiplexer which simply forwards interrupts to all
> >> > peripherals (exactly what's happening with IRQ_SHARED) but keep a unique
> >> > irq number for each peripheral, thus preventing the IRQF_NO_SUSPEND
> >> > and !IRQF_NO_SUSPEND mix on a given interrupt.
> >>
> >> This really seems like a work-around for how IRQF_SHARED works. It
> >
> > It's a workaround for a short coming of IRQF_SHARED.
> >
> > IRQF_SHARED has a massive short coming versus suspend and wakeup
> > interrupts. If one of the demultiplexed interrupts is a valid wakeup
> > source then we have no sane way to express this with IRQF_SHARED
> > simply because the drivers need to be aware whether they run on stupid
> > or well designed hardware.
> 
> Unfortunately, the drivers will still have to know this. They cannot
> assume that they can call disable_irq and their device irq state does
> not matter.
> 
> Perhaps we need a debug feature such that disable_irq/enable_irq are
> nops with IRQF_SHARED?
> 
> >> seems like what is really desired is just per handler disabling. It is
> >
> > So you want a magic API like disable/enable_irq_action()?
> >
> > Certainly not.
> 
> Agreed.
> 
> > You'd open just another can of worms which will bring us abuse and
> > hard to debug problems because driver writers think it's a good idea
> > to use it for random purposes.
> >
> > Aside of that it would add another conditional into the interrupt
> > delivery hotpath which is not desired either.
> >
> >> fragile in that devices can deadlock the system if the drivers don't
> >> disable the interrupt source before calling disable_irq. But unlike
> >
> > Any misdesigned driver can do that for you.
> >
> >> IRQF_SHARED, there is nothing explicit in the driver indicating it is
> >> designed to work properly with a shared interrupt line.
> >
> > IRQF_SHARED is a pretty bad indicator. Look at all the drivers which
> > slap this flag onto request_irq() and have no single line of code
> > which makes sure that the driver would ever work on a shared line.
> >
> > If it's just for annotational purposes, we can add a new IRQF flag,
> > which is required to request such a interrupt line.
> >
> >> I see no reason to accept this into DT either. We already can support
> >> shared lines and modeling an OR gate as an interrupt controller is
> >> pointless.
> >
> > It's absolutely not pointless.
> >
> > All attempts to work around that have resulted in horrible bandaids so
> > far. That's why I guided Boris to implement this dummy demultiplexing
> > mechanism. It solves the problem at hand nicely without adding nasty
> > hackarounds into the suspend/resume code and inflicting platform
> > knowledge on multi-platform device drivers.
> 
> This change will break on old kernels with a new dtb. Would you be
> happy if a BIOS update required a new kernel? Fixing this for any
> platform requires a dtb update which may not be possible on some
> platforms. I don't have a problem with this breakage for 1 platform
> and the at91 guys may not care, but we'd ultimately be changing how
> all shared irqs are specified for all DT. Maybe we decide that this is
> how we want to describe things, but that needs much wider discussion
> and agreement.

I tried really hard on finding a DT representation that would not break
the DT ABI, but didn't find any easy solution.
How about keeping all platforms with the shared irq pattern, except for
those that really have an irq line shared by a timer and several other
devices (not sure yet, but at91 seems to be the only impacted platform
so far).

> 
> > If you have a proper solution for the problem at hand which
> >
> >- avoids the demux dummy
> >
> >- works straight forward with suspend/resume/wakeup
> >
> >- does not add horrible new APIs
> >
> >- does not add conditionals to the interrupt hotpath
> >
> >- does not inflict platform knowledge about interrupt chip details
> >  on drivers
> >
> > then I'm happy to take it.
> >
> > But as long as you can't come up with anything sane, the demux dummy
> > is the best solution for this problem we've seen so far.
> 
> What if during suspend you move all actions w/o IRQF_NO_SUSPEND to a
> suspended action list? This would leave only the actions with
> IRQF_NO_SUSPEND set in the active action list. The cost would be a
> pointer in irq_desc an

Re: [PATCH] RTC: RK808: fix the rtc time reading issue

[Andrew Morton]

On Wed, 14 Jan 2015 11:44:02 -0800 Sonny Rao  wrote:

> On Wed, Jan 14, 2015 at 10:36 AM, Doug Anderson  wrote:
> > Sonny,
> >
> >> Chris, it looks like you swapped the set and the clear of this bit,
> >> and you're relying on the fact that the i2c transaction takes a
> >> certain amount of time after the RTC_GET_TIME BIT is set.   I'm not
> >> sure how long it actually takes, but why not just put in a usleep()
> >> for the minimum wait time?
> >
> > I think we are safe.
> >
> > At 400kHz (the max speed of this part) each bit can be transferred no
> > faster than 2.5us.  In order to do a valid i2c transaction we need to
> > _at least_ write the address of the device and the data onto the bus,
> > which is 16 bits.  16 * 2.5us = 40us.  That's above the 31.25us
> >
> > Personally I think what Chris has is fine, with the comment.
> 
> Ok, I'm fine with that if we're sure it's slow enough.  Comment
> explaining would certainly help.

Thanks, all.  I did this:

--- a/drivers/rtc/rtc-rk808.c~rtc-rk808-fix-the-rtc-time-reading-issue-fix
+++ a/drivers/rtc/rtc-rk808.c
@@ -73,10 +73,11 @@ static int rk808_rtc_readtime(struct dev
return ret;
}
 
-   /* After we set the GET_TIME bit, the rtc time couldn't be read
-* immediately, we should wait up to 31.25 us, about one cycle of
+   /*
+* After we set the GET_TIME bit, the rtc time can't be read
+* immediately. So we should wait up to 31.25 us, about one cycle of
 * 32khz. If we clear the GET_TIME bit here, the time of i2c transfer
-* certainly more than 31.25us.
+* certainly more than 31.25us: 16 * 2.5us at 400kHz bus frequency.
 */
ret = regmap_update_bits(rk808->regmap, RK808_RTC_CTRL_REG,
 BIT_RTC_CTRL_REG_RTC_GET_TIME,
_

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] usb: dwc2: call dwc2_is_controller_alive() under spinlock

[Felipe Balbi]

Hi,

On Wed, Jan 14, 2015 at 10:45:26PM +, Paul Zimmerman wrote:
> > From: Felipe Balbi [mailto:ba...@ti.com]
> > Sent: Wednesday, January 14, 2015 2:40 PM
> > 
> > On Wed, Jan 14, 2015 at 10:28:54PM +, Paul Zimmerman wrote:
> > > > From: Felipe Balbi [mailto:ba...@ti.com]
> > > > Sent: Wednesday, January 14, 2015 1:46 PM
> > > >
> > > > On Wed, Jan 14, 2015 at 04:41:23PM -0500, Alan Stern wrote:
> > > > > > > > This is really, really odd. Register accesses are atomic, so 
> > > > > > > > the lock
> > > > > > > > isn't really doing anything. Besides, you're calling
> > > > > > > > dwc2_is_controller_alive() from within the IRQ handler, so IRQs 
> > > > > > > > are
> > > > > > > > already disabled.
> > > > > > >
> > > > > > > Spinlocks sometimes do more than you think.  For instance, here 
> > > > > > > the
> > > > > > > lock prevents the register access from happening while some other 
> > > > > > > CPU
> > > > > > > is holding the lock.  If a silicon quirk causes the register 
> > > > > > > access to
> > > > > > > interfere with other activities, this could be important.
> > > > > >
> > > > > > readl() (which is used by dwc2_is_controller_alive()) adds a memory
> > > > > > barrier to the register accesses, that should force all register
> > > > > > accesses the be correctly ordered.
> > > > >
> > > > > Memory barriers will order accesses that are all made on the same CPU
> > > > > with respect to each other.  They do not order these accesses against
> > > > > accesses made from another CPU -- that's why we have spinlocks.  :-)
> > > >
> > > > a fair point :-) The register is still read-only, so that shouldn't
> > > > matter either :-)
> > > >
> > > > > >  I fail to see how a silicon quirk
> > > > > > could cause this and if, indeed, it does, I'd be more comfortable 
> > > > > > with a
> > > > > > proper STARS tickect number from synopsys :-s
> > > > >
> > > > > Maybe accessing this register somehow resets something else.  I don't
> > > > > know.  It seems unlikely, but at least it explains how adding a
> > > > > spinlock could fix the problem.
> > > >
> > > > I would really need Paul (or someone at Synopsys) to confirm this
> > > > somehow. Maybe it has something to do with how the register is
> > > > implemented, dunno.
> > > >
> > > > Paul, do you have any idea what could cause this ? Could the HW into
> > > > some weird state if we read GSNPSID at random locations or when data is
> > > > being transferred, or anything like that ?
> > >
> > > Only thing I can think of is that there is some silicon bug in Robert's
> > > platform. But I am not aware of any STARs that mention accesses to the
> > > GSNPSID register as being problematic.
> > >
> > > Funny thing is, this code has been basically the same since at least
> > > November 2013. So I think some other recent change must have modified
> > > the timing of the register accesses, or something like that. But that's
> > > just handwaving, really.
> > 
> > Alright, I'll apply this patch but for 3.20 with a stable tag as I have
> > already sent my last pull request to Greg. Unless someone has a really
> > big complaint about doing things as such.
> 
> It should go to 3.19-rc shouldn't it? It's a fix, and Robert's platform
> is broken without it, IIUC.

It can also be categorized as "has-never-worked-before" before the code
has been like this forever. Since we don't really have a git bisect
result pointing to a commit that went in v3.19 merge window, I'm not
sure how I can convince myself that this absolutely needs to be in
v3.19.

At a minimum, I need a proper bisection with a proper commit being
blamed (even if it's a commit from months ago). From my point of view,
debugging of this "regression" has not been finalized and we're just
"assuming" it's caused by GSNPSID because moving that inside the
spin_lock seems to fix the problem.

-- 
balbi


signature.asc
Description: Digital signature

question regarding -D flag in perf stat

[Aravind Gopalakrishnan]

Hi all,

I had a question regarding the intention of the -D flag after looking at 
perf stat numbers of the following workload:


main(){

int a=5, b=6;

int i;

#pragma omp for schedule(dynamic)

for (i=0; i<1000; i++){

b=b+a;

}

return 0;

}

_Stats without delay:_

# perf stat -e cycles,instructions,cpu-clock,task-clock ../../test/a.out

Performance counter stats for '../../test/a.out':

   203,581,363,567 cycles #1.500 GHz

 7,563,983,198 instructions #0.04  insns per cycle

 135721.617844 cpu-clock (msec)

 135721.600586 task-clock (msec) # *5.985 CPUs utilized*

  22.678577620 seconds time elapsed (run time)

_Stats with delay of 10 seconds:_

# perf stat -D 1 -e cycles,instructions,cpu-clock,task-clock 
../../test/a.out


b=363264281

Performance counter stats for '../../test/a.out':

   112,134,813,161 cycles #1.500 GHz

 4,461,136,761 instructions #0.04  insns per cycle

  74757.386789 cpu-clock (msec)

  74757.317781 task-clock (msec) # *3.324 CPUs utilized*

22.490237094 seconds time elapsed**(run time)*(delay time is not 
excluded here)*


The issue is that CPU utilization is calculated as 
task-clock/total-runtime which in the case of no delay is fine.
But for the delay case, the total run time should exclude the delay 
time. Right?
(and as a consequence, utilization would be calculated exclusive of the 
delay time which would give us CPU utilization only for the period 
during which perf actually collects info)


Or is this the way -D flag is intended to work?

Thanks for the clarifications,
-Aravind.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] x86: entry_64.S: always allocate complete "struct pt_regs"

[Denys Vlasenko]

On Wed, Jan 14, 2015 at 11:41 PM, Borislav Petkov  wrote:
> On Wed, Jan 14, 2015 at 02:29:39PM -0800, Andy Lutomirski wrote:
>> I need to go through Linus' and everyone else's comments on that to
>> figure out what to do first.
>
> Right, we want to take it slow and be conservative here - entry_XX.S is
> not a joke.

No problem - I just wanted you to know what I have in the pipeline.

There are four more optimization patches on top of this patchset,
I'm not posting those because I see they will definitely collide
with some of Andy's patches.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] acpica: utpredef: Remove some unused functions

[Rickard Strandqvist]

2015-01-14 9:55 GMT+01:00 Zheng, Lv :
> Hi, Rickard
>
> The functions below seem already marked by "ACPI_ASL_COMPILER || 
> ACPI_HELP_APP".
> How did you detect them as used functions?
>
> Thanks
> -Lv
>
>
>> -Original Message-
>> From: Rickard Strandqvist [mailto:rickard_strandqv...@spectrumdigital.se]
>> Sent: Sunday, January 04, 2015 11:23 PM
>> To: Moore, Robert; Zheng, Lv
>> Cc: Rickard Strandqvist; Wysocki, Rafael J; Len Brown; 
>> linux-a...@vger.kernel.org; de...@acpica.org; linux-kernel@vger.kernel.org
>> Subject: [PATCH] acpica: utpredef: Remove some unused functions
>>
>> Removes some functions that are not used anywhere:
>> acpi_ut_get_resource_bit_width() acpi_ut_display_predefined_method() 
>> acpi_ut_match_resource_name()
>>
>> This was partially found by using a static code analysis program called 
>> cppcheck.
>>
>> Signed-off-by: Rickard Strandqvist 
>> ---
>>  drivers/acpi/acpica/acutils.h  |9 ---
>>  drivers/acpi/acpica/utpredef.c |  134 
>> 
>>  2 files changed, 143 deletions(-)
>>
>> diff --git a/drivers/acpi/acpica/acutils.h b/drivers/acpi/acpica/acutils.h
>> index 486d342..9b3fab1 100644
>> --- a/drivers/acpi/acpica/acutils.h
>> +++ b/drivers/acpi/acpica/acutils.h
>> @@ -502,17 +502,8 @@ const union acpi_predefined_info 
>> *acpi_ut_get_next_predefined_method(const union
>>
>>  const union acpi_predefined_info *acpi_ut_match_predefined_method(char 
>> *name);
>>
>> -const union acpi_predefined_info *acpi_ut_match_resource_name(char *name);
>> -
>> -void
>> -acpi_ut_display_predefined_method(char *buffer,
>> -   const union acpi_predefined_info *this_name,
>> -   u8 multi_line);
>> -
>>  void acpi_ut_get_expected_return_types(char *buffer, u32 expected_btypes);
>>
>> -u32 acpi_ut_get_resource_bit_width(char *buffer, u16 types);
>> -
>>  /*
>>   * utstate - Generic state creation/cache routines
>>   */
>> diff --git a/drivers/acpi/acpica/utpredef.c b/drivers/acpi/acpica/utpredef.c
>> index db30caf..f1ff33c 100644
>> --- a/drivers/acpi/acpica/utpredef.c
>> +++ b/drivers/acpi/acpica/utpredef.c
>> @@ -209,105 +209,6 @@ static const char *ut_resource_type_names[] = {
>>
>>  
>> /***
>>   *
>> - * FUNCTION:acpi_ut_match_resource_name
>> - *
>> - * PARAMETERS:  name- Name to find
>> - *
>> - * RETURN:  Pointer to entry in the resource table. NULL indicates not
>> - *  found.
>> - *
>> - * DESCRIPTION: Check an object name against the predefined resource
>> - *  descriptor object list.
>> - *
>> - 
>> **/
>> -
>> -const union acpi_predefined_info *acpi_ut_match_resource_name(char *name)
>> -{
>> - const union acpi_predefined_info *this_name;
>> -
>> - /* Quick check for a predefined name, first character must be 
>> underscore */
>> -
>> - if (name[0] != '_') {
>> - return (NULL);
>> - }
>> -
>> - /* Search info table for a predefined method/object name */
>> -
>> - this_name = acpi_gbl_resource_names;
>> - while (this_name->info.name[0]) {
>> - if (ACPI_COMPARE_NAME(name, this_name->info.name)) {
>> - return (this_name);
>> - }
>> -
>> - this_name++;
>> - }
>> -
>> - return (NULL);  /* Not found */
>> -}
>> -
>> -/***
>> - *
>> - * FUNCTION:acpi_ut_display_predefined_method
>> - *
>> - * PARAMETERS:  buffer  - Scratch buffer for this function
>> - *  this_name   - Entry in the predefined method/name 
>> table
>> - *  multi_line  - TRUE if output should be on >1 line
>> - *
>> - * RETURN:  None
>> - *
>> - * DESCRIPTION: Display information about a predefined method. Number and
>> - *  type of the input arguments, and expected type(s) for the
>> - *  return value, if any.
>> - *
>> - 
>> **/
>> -
>> -void
>> -acpi_ut_display_predefined_method(char *buffer,
>> -   const union acpi_predefined_info *this_name,
>> -   u8 multi_line)
>> -{
>> - u32 arg_count;
>> -
>> - /*
>> -  * Get the argument count and the string buffer
>> -  * containing all argument types
>> -  */
>> - arg_count = acpi_ut_get_argument_types(buffer,
>> -this_name->info.argument_list);
>> -
>> - if (multi_line) {
>> - printf("  ");
>> - }
>> -
>> - printf("%4.4sRequires %s%u argument%s",
>> -this_name->info.name,
>> -(this_name->info.argument_list & ARG_COUNT_IS_MINIMUM) ?
>> -"(at least) " : "

Re: [PATCH 3.14 00/77] 3.14.29-stable review

[Shuah Khan]

On 01/14/2015 12:22 AM, Greg Kroah-Hartman wrote:
> This is the start of the stable review cycle for the 3.14.29 release.
> There are 77 patches in this series, all will be posted as a response
> to this one.  If anyone has any issues with these being applied, please
> let me know.
> 
> Responses should be made by Fri Jan 16 07:22:07 UTC 2015.
> Anything received after that time might be too late.
> 
> The whole patch series can be found in one patch at:
>   kernel.org/pub/linux/kernel/v3.0/stable-review/patch-3.14.29-rc1.gz
> and the diffstat can be found below.
> 
> thanks,
> 
> greg k-h
> 

Compiled and booted on my test system. No dmesg regressions.

thanks,
-- Shuah

-- 
Shuah Khan
Sr. Linux Kernel Developer
Open Source Innovation Group
Samsung Research America (Silicon Valley)
shua...@osg.samsung.com | (970) 217-8978
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 3.10 00/44] 3.10.65-stable review

[Shuah Khan]

On 01/14/2015 12:23 AM, Greg Kroah-Hartman wrote:
> This is the start of the stable review cycle for the 3.10.65 release.
> There are 44 patches in this series, all will be posted as a response
> to this one.  If anyone has any issues with these being applied, please
> let me know.
> 
> Responses should be made by Fri Jan 16 07:22:13 UTC 2015.
> Anything received after that time might be too late.
> 
> The whole patch series can be found in one patch at:
>   kernel.org/pub/linux/kernel/v3.0/stable-review/patch-3.10.65-rc1.gz
> and the diffstat can be found below.
> 
> thanks,
> 
> greg k-h
> 

Compiled and booted on my test system. No dmesg regressions.

thanks,
-- Shuah


-- 
Shuah Khan
Sr. Linux Kernel Developer
Open Source Innovation Group
Samsung Research America (Silicon Valley)
shua...@osg.samsung.com | (970) 217-8978
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 3.18 000/150] 3.18.3-stable review

[Shuah Khan]

On 01/14/2015 12:21 AM, Greg Kroah-Hartman wrote:
> This is the start of the stable review cycle for the 3.18.3 release.
> There are 150 patches in this series, all will be posted as a response
> to this one.  If anyone has any issues with these being applied, please
> let me know.
> 
> Responses should be made by Fri Jan 16 07:20:24 UTC 2015.
> Anything received after that time might be too late.
> 
> The whole patch series can be found in one patch at:
>   kernel.org/pub/linux/kernel/v3.0/stable-review/patch-3.18.3-rc1.gz
> and the diffstat can be found below.
> 
> thanks,
> 
> greg k-h
> 

Compiled and booted on my test system. No dmesg regressions.

thanks,
-- Shuah


-- 
Shuah Khan
Sr. Linux Kernel Developer
Open Source Innovation Group
Samsung Research America (Silicon Valley)
shua...@osg.samsung.com | (970) 217-8978
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] usb: dwc2: call dwc2_is_controller_alive() under spinlock

[Paul Zimmerman]

> From: Felipe Balbi [mailto:ba...@ti.com]
> Sent: Wednesday, January 14, 2015 2:40 PM
> 
> On Wed, Jan 14, 2015 at 10:28:54PM +, Paul Zimmerman wrote:
> > > From: Felipe Balbi [mailto:ba...@ti.com]
> > > Sent: Wednesday, January 14, 2015 1:46 PM
> > >
> > > On Wed, Jan 14, 2015 at 04:41:23PM -0500, Alan Stern wrote:
> > > > > > > This is really, really odd. Register accesses are atomic, so the 
> > > > > > > lock
> > > > > > > isn't really doing anything. Besides, you're calling
> > > > > > > dwc2_is_controller_alive() from within the IRQ handler, so IRQs 
> > > > > > > are
> > > > > > > already disabled.
> > > > > >
> > > > > > Spinlocks sometimes do more than you think.  For instance, here the
> > > > > > lock prevents the register access from happening while some other 
> > > > > > CPU
> > > > > > is holding the lock.  If a silicon quirk causes the register access 
> > > > > > to
> > > > > > interfere with other activities, this could be important.
> > > > >
> > > > > readl() (which is used by dwc2_is_controller_alive()) adds a memory
> > > > > barrier to the register accesses, that should force all register
> > > > > accesses the be correctly ordered.
> > > >
> > > > Memory barriers will order accesses that are all made on the same CPU
> > > > with respect to each other.  They do not order these accesses against
> > > > accesses made from another CPU -- that's why we have spinlocks.  :-)
> > >
> > > a fair point :-) The register is still read-only, so that shouldn't
> > > matter either :-)
> > >
> > > > >  I fail to see how a silicon quirk
> > > > > could cause this and if, indeed, it does, I'd be more comfortable 
> > > > > with a
> > > > > proper STARS tickect number from synopsys :-s
> > > >
> > > > Maybe accessing this register somehow resets something else.  I don't
> > > > know.  It seems unlikely, but at least it explains how adding a
> > > > spinlock could fix the problem.
> > >
> > > I would really need Paul (or someone at Synopsys) to confirm this
> > > somehow. Maybe it has something to do with how the register is
> > > implemented, dunno.
> > >
> > > Paul, do you have any idea what could cause this ? Could the HW into
> > > some weird state if we read GSNPSID at random locations or when data is
> > > being transferred, or anything like that ?
> >
> > Only thing I can think of is that there is some silicon bug in Robert's
> > platform. But I am not aware of any STARs that mention accesses to the
> > GSNPSID register as being problematic.
> >
> > Funny thing is, this code has been basically the same since at least
> > November 2013. So I think some other recent change must have modified
> > the timing of the register accesses, or something like that. But that's
> > just handwaving, really.
> 
> Alright, I'll apply this patch but for 3.20 with a stable tag as I have
> already sent my last pull request to Greg. Unless someone has a really
> big complaint about doing things as such.

It should go to 3.19-rc shouldn't it? It's a fix, and Robert's platform
is broken without it, IIUC.

-- 
Paul

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] procfs: Add /proc//mapped_files

[Andrew Morton]

On Wed, 14 Jan 2015 13:03:26 -0800 Calvin Owens  wrote:

> > Well, only when combined with checking vm_file for being NULL. One would
> > also need to ensure that vm_pgoff is 0 for any non-stack,
> > non-file-backed VMA. At which point it is somewhat ugly. 
> > 
> > > One problem with caching the value on clone like this though is that
> > > the stack could change due to a setcontext, but AFAICT we don't care
> > > about that for the process stack either.
> > 
> > If it is important, I guess one could update the info when a task calls
> > setcontext.
> 
> If I understand the current behavior, the "[stack]" marker will get put
> next to *any* mapping that encompasses the current value in the task's
> %sp, regardless of how the mapping was created or ucontext stuff. If
> you use flags on the VMA structs things could potentially be marked as
> stacks even though %sp points somewhere else.
> 
> It's probable that nobody cares (you'd obviously have to be doing crazy
> things to be pointing %sp at arbitrary places), but that's why I was
> hesitant to mess with it.

Fixing the N^2 search would of course be much better than adding a new
proc file to sidestep it.

Could we do something like refreshing the new vma.vm_flags:VM_IS_STACK
on each thread at the time when /proc/PID/maps is opened?  So do a walk
of the threads, use each thread's sp to hunt down the thread's stack's
vma, then set VM_IS_STACK and fill in the new vma.stack_tid field?

There are still several flags unused in vma.vm_flags btw.

I'm not sure that we can repurpose vm_pgoff (or vm_private_data) for
this: a badly behaved thread could make its sp point at a random vma
then trick the kernel into scribbling on that vma's vm_proff?  Adding a
new field to the vma wouldn't kill us, I guess.  That would remove the
need for a VM_IS_STACK.


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] procfs: Add /proc//mapped_files

[Kirill A. Shutemov]

On Tue, Jan 13, 2015 at 04:20:29PM -0800, Calvin Owens wrote:
> Commit b76437579d1344b6 ("procfs: mark thread stack correctly in
> proc//maps") introduced logic to mark thread stacks with the
> "[stack:%d]" marker in /proc//maps.
> 
> This causes reading /proc//maps to take O(N^2) time, where N is
> the number of threads sharing an address space, since each line of
> output requires iterating over the VMA list looking for ranges that
> correspond to the stack pointer in any task's register set. When
> dealing with highly-threaded Java applications, reading this file can
> take hours and trigger softlockup dumps.
> 
> Eliminating the "[stack:%d]" marker is not a viable option since it's
> been there for some time, and I don't see a way to do the stack check
> more efficiently that wouldn't end up making the whole thing really
> ugly.

Can we find stack for threads once on seq_operations::start() and avoid
for_each_thread() on seq_operations::show() for each stack vma?

-- 
 Kirill A. Shutemov
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] usb: dwc2: call dwc2_is_controller_alive() under spinlock

[Felipe Balbi]

On Wed, Jan 14, 2015 at 04:39:41PM -0600, Felipe Balbi wrote:
> On Wed, Jan 14, 2015 at 10:28:54PM +, Paul Zimmerman wrote:
> > > From: Felipe Balbi [mailto:ba...@ti.com]
> > > Sent: Wednesday, January 14, 2015 1:46 PM
> > > 
> > > On Wed, Jan 14, 2015 at 04:41:23PM -0500, Alan Stern wrote:
> > > > > > > This is really, really odd. Register accesses are atomic, so the 
> > > > > > > lock
> > > > > > > isn't really doing anything. Besides, you're calling
> > > > > > > dwc2_is_controller_alive() from within the IRQ handler, so IRQs 
> > > > > > > are
> > > > > > > already disabled.
> > > > > >
> > > > > > Spinlocks sometimes do more than you think.  For instance, here the
> > > > > > lock prevents the register access from happening while some other 
> > > > > > CPU
> > > > > > is holding the lock.  If a silicon quirk causes the register access 
> > > > > > to
> > > > > > interfere with other activities, this could be important.
> > > > >
> > > > > readl() (which is used by dwc2_is_controller_alive()) adds a memory
> > > > > barrier to the register accesses, that should force all register
> > > > > accesses the be correctly ordered.
> > > >
> > > > Memory barriers will order accesses that are all made on the same CPU
> > > > with respect to each other.  They do not order these accesses against
> > > > accesses made from another CPU -- that's why we have spinlocks.  :-)
> > > 
> > > a fair point :-) The register is still read-only, so that shouldn't
> > > matter either :-)
> > > 
> > > > >  I fail to see how a silicon quirk
> > > > > could cause this and if, indeed, it does, I'd be more comfortable 
> > > > > with a
> > > > > proper STARS tickect number from synopsys :-s
> > > >
> > > > Maybe accessing this register somehow resets something else.  I don't
> > > > know.  It seems unlikely, but at least it explains how adding a
> > > > spinlock could fix the problem.
> > > 
> > > I would really need Paul (or someone at Synopsys) to confirm this
> > > somehow. Maybe it has something to do with how the register is
> > > implemented, dunno.
> > > 
> > > Paul, do you have any idea what could cause this ? Could the HW into
> > > some weird state if we read GSNPSID at random locations or when data is
> > > being transferred, or anything like that ?
> > 
> > Only thing I can think of is that there is some silicon bug in Robert's
> > platform. But I am not aware of any STARs that mention accesses to the
> > GSNPSID register as being problematic.
> > 
> > Funny thing is, this code has been basically the same since at least
> > November 2013. So I think some other recent change must have modified
> > the timing of the register accesses, or something like that. But that's
> > just handwaving, really.
> 
> Alright, I'll apply this patch but for 3.20 with a stable tag as I have
> already sent my last pull request to Greg. Unless someone has a really
> big complaint about doing things as such.

But of course, I need a better changelog :-)

-- 
balbi


signature.asc
Description: Digital signature

Re: [PATCH 01/11] x86: entry_64.S: always allocate complete "struct pt_regs"

[Borislav Petkov]

On Wed, Jan 14, 2015 at 02:29:39PM -0800, Andy Lutomirski wrote:
> I need to go through Linus' and everyone else's comments on that to
> figure out what to do first.

Right, we want to take it slow and be conservative here - entry_XX.S is
not a joke.

-- 
Regards/Gruss,
Boris.

Sent from a fat crate under my desk. Formatting is fine.
--
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] usb: dwc2: call dwc2_is_controller_alive() under spinlock

[Felipe Balbi]

On Wed, Jan 14, 2015 at 10:28:54PM +, Paul Zimmerman wrote:
> > From: Felipe Balbi [mailto:ba...@ti.com]
> > Sent: Wednesday, January 14, 2015 1:46 PM
> > 
> > On Wed, Jan 14, 2015 at 04:41:23PM -0500, Alan Stern wrote:
> > > > > > This is really, really odd. Register accesses are atomic, so the 
> > > > > > lock
> > > > > > isn't really doing anything. Besides, you're calling
> > > > > > dwc2_is_controller_alive() from within the IRQ handler, so IRQs are
> > > > > > already disabled.
> > > > >
> > > > > Spinlocks sometimes do more than you think.  For instance, here the
> > > > > lock prevents the register access from happening while some other CPU
> > > > > is holding the lock.  If a silicon quirk causes the register access to
> > > > > interfere with other activities, this could be important.
> > > >
> > > > readl() (which is used by dwc2_is_controller_alive()) adds a memory
> > > > barrier to the register accesses, that should force all register
> > > > accesses the be correctly ordered.
> > >
> > > Memory barriers will order accesses that are all made on the same CPU
> > > with respect to each other.  They do not order these accesses against
> > > accesses made from another CPU -- that's why we have spinlocks.  :-)
> > 
> > a fair point :-) The register is still read-only, so that shouldn't
> > matter either :-)
> > 
> > > >  I fail to see how a silicon quirk
> > > > could cause this and if, indeed, it does, I'd be more comfortable with a
> > > > proper STARS tickect number from synopsys :-s
> > >
> > > Maybe accessing this register somehow resets something else.  I don't
> > > know.  It seems unlikely, but at least it explains how adding a
> > > spinlock could fix the problem.
> > 
> > I would really need Paul (or someone at Synopsys) to confirm this
> > somehow. Maybe it has something to do with how the register is
> > implemented, dunno.
> > 
> > Paul, do you have any idea what could cause this ? Could the HW into
> > some weird state if we read GSNPSID at random locations or when data is
> > being transferred, or anything like that ?
> 
> Only thing I can think of is that there is some silicon bug in Robert's
> platform. But I am not aware of any STARs that mention accesses to the
> GSNPSID register as being problematic.
> 
> Funny thing is, this code has been basically the same since at least
> November 2013. So I think some other recent change must have modified
> the timing of the register accesses, or something like that. But that's
> just handwaving, really.

Alright, I'll apply this patch but for 3.20 with a stable tag as I have
already sent my last pull request to Greg. Unless someone has a really
big complaint about doing things as such.

-- 
balbi


signature.asc
Description: Digital signature

Re: [PATCH 01/11] x86: entry_64.S: always allocate complete "struct pt_regs"

[Andy Lutomirski]

On Wed, Jan 14, 2015 at 2:17 PM, Denys Vlasenko
 wrote:
> On Wed, Jan 14, 2015 at 10:48 PM, Denys Vlasenko  wrote:
>> Macros which manipulate "struct pt_regs" on stack are reworked:
>> ALLOC_PT_GPREGS_ON_STACK allocates the structure.
>> SAVE_C_REGS saves to it those registers which are clobbered by C code.
>> SAVE_EXTRA_REGS saves to it all other registers.
>> Corresponding RESTORE_* and REMOVE_PT_GPREGS_FROM_STACK macros reverse it.
>
> Andy,
>
> Please note that this patch set also needs the previously posted patch:
>
> [PATCH 3/4] x86: open-code register save/restore in trace_hardirqs thunks
>
> which is not present in your tree - otherwise arch/x86/lib/thunk_64.S
> will not compile (no SAVE_ARGS anymore).

I need to go through Linus' and everyone else's comments on that to
figure out what to do first.

--Andy

>
> --
> vda



-- 
Andy Lutomirski
AMA Capital Management, LLC
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] usb: dwc2: call dwc2_is_controller_alive() under spinlock

[Paul Zimmerman]

> From: Felipe Balbi [mailto:ba...@ti.com]
> Sent: Wednesday, January 14, 2015 1:46 PM
> 
> On Wed, Jan 14, 2015 at 04:41:23PM -0500, Alan Stern wrote:
> > > > > This is really, really odd. Register accesses are atomic, so the lock
> > > > > isn't really doing anything. Besides, you're calling
> > > > > dwc2_is_controller_alive() from within the IRQ handler, so IRQs are
> > > > > already disabled.
> > > >
> > > > Spinlocks sometimes do more than you think.  For instance, here the
> > > > lock prevents the register access from happening while some other CPU
> > > > is holding the lock.  If a silicon quirk causes the register access to
> > > > interfere with other activities, this could be important.
> > >
> > > readl() (which is used by dwc2_is_controller_alive()) adds a memory
> > > barrier to the register accesses, that should force all register
> > > accesses the be correctly ordered.
> >
> > Memory barriers will order accesses that are all made on the same CPU
> > with respect to each other.  They do not order these accesses against
> > accesses made from another CPU -- that's why we have spinlocks.  :-)
> 
> a fair point :-) The register is still read-only, so that shouldn't
> matter either :-)
> 
> > >  I fail to see how a silicon quirk
> > > could cause this and if, indeed, it does, I'd be more comfortable with a
> > > proper STARS tickect number from synopsys :-s
> >
> > Maybe accessing this register somehow resets something else.  I don't
> > know.  It seems unlikely, but at least it explains how adding a
> > spinlock could fix the problem.
> 
> I would really need Paul (or someone at Synopsys) to confirm this
> somehow. Maybe it has something to do with how the register is
> implemented, dunno.
> 
> Paul, do you have any idea what could cause this ? Could the HW into
> some weird state if we read GSNPSID at random locations or when data is
> being transferred, or anything like that ?

Only thing I can think of is that there is some silicon bug in Robert's
platform. But I am not aware of any STARs that mention accesses to the
GSNPSID register as being problematic.

Funny thing is, this code has been basically the same since at least
November 2013. So I think some other recent change must have modified
the timing of the register accesses, or something like that. But that's
just handwaving, really.

-- 
Paul

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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/5] irqchip: add dumb demultiplexer implementation

[Rob Herring]

On Wed, Jan 14, 2015 at 4:36 AM, Thomas Gleixner  wrote:
> On Tue, 13 Jan 2015, Rob Herring wrote:
>> On Tue, Jan 13, 2015 at 12:46 PM, Boris Brezillon
>>  wrote:
>> > Some interrupt controllers are multiplexing several peripheral IRQs on
>> > a single interrupt line.
>> > While this is not a problem for most IRQs (as long as all peripherals
>> > request the interrupt with IRQF_SHARED flag set), multiplexing timers and
>> > other type of peripherals will generate a WARNING (mixing IRQF_NO_SUSPEND
>> > and !IRQF_NO_SUSPEND is prohibited).
>> >
>> > Create a dumb irq demultiplexer which simply forwards interrupts to all
>> > peripherals (exactly what's happening with IRQ_SHARED) but keep a unique
>> > irq number for each peripheral, thus preventing the IRQF_NO_SUSPEND
>> > and !IRQF_NO_SUSPEND mix on a given interrupt.
>>
>> This really seems like a work-around for how IRQF_SHARED works. It
>
> It's a workaround for a short coming of IRQF_SHARED.
>
> IRQF_SHARED has a massive short coming versus suspend and wakeup
> interrupts. If one of the demultiplexed interrupts is a valid wakeup
> source then we have no sane way to express this with IRQF_SHARED
> simply because the drivers need to be aware whether they run on stupid
> or well designed hardware.

Unfortunately, the drivers will still have to know this. They cannot
assume that they can call disable_irq and their device irq state does
not matter.

Perhaps we need a debug feature such that disable_irq/enable_irq are
nops with IRQF_SHARED?

>> seems like what is really desired is just per handler disabling. It is
>
> So you want a magic API like disable/enable_irq_action()?
>
> Certainly not.

Agreed.

> You'd open just another can of worms which will bring us abuse and
> hard to debug problems because driver writers think it's a good idea
> to use it for random purposes.
>
> Aside of that it would add another conditional into the interrupt
> delivery hotpath which is not desired either.
>
>> fragile in that devices can deadlock the system if the drivers don't
>> disable the interrupt source before calling disable_irq. But unlike
>
> Any misdesigned driver can do that for you.
>
>> IRQF_SHARED, there is nothing explicit in the driver indicating it is
>> designed to work properly with a shared interrupt line.
>
> IRQF_SHARED is a pretty bad indicator. Look at all the drivers which
> slap this flag onto request_irq() and have no single line of code
> which makes sure that the driver would ever work on a shared line.
>
> If it's just for annotational purposes, we can add a new IRQF flag,
> which is required to request such a interrupt line.
>
>> I see no reason to accept this into DT either. We already can support
>> shared lines and modeling an OR gate as an interrupt controller is
>> pointless.
>
> It's absolutely not pointless.
>
> All attempts to work around that have resulted in horrible bandaids so
> far. That's why I guided Boris to implement this dummy demultiplexing
> mechanism. It solves the problem at hand nicely without adding nasty
> hackarounds into the suspend/resume code and inflicting platform
> knowledge on multi-platform device drivers.

This change will break on old kernels with a new dtb. Would you be
happy if a BIOS update required a new kernel? Fixing this for any
platform requires a dtb update which may not be possible on some
platforms. I don't have a problem with this breakage for 1 platform
and the at91 guys may not care, but we'd ultimately be changing how
all shared irqs are specified for all DT. Maybe we decide that this is
how we want to describe things, but that needs much wider discussion
and agreement.

> If you have a proper solution for the problem at hand which
>
>- avoids the demux dummy
>
>- works straight forward with suspend/resume/wakeup
>
>- does not add horrible new APIs
>
>- does not add conditionals to the interrupt hotpath
>
>- does not inflict platform knowledge about interrupt chip details
>  on drivers
>
> then I'm happy to take it.
>
> But as long as you can't come up with anything sane, the demux dummy
> is the best solution for this problem we've seen so far.

What if during suspend you move all actions w/o IRQF_NO_SUSPEND to a
suspended action list? This would leave only the actions with
IRQF_NO_SUSPEND set in the active action list. The cost would be a
pointer in irq_desc and moving the actions during suspend and resume.

There are probably ways to do this demux irqchip without a DT change.
Since we can't just move Linux irq numbers to different irq_chips
during request_irq, we would have to parse the DT up front to find all
shared interrupts and create a demux irqchip for them. That wouldn't
be very efficient, but is straight-forward. Then we'd have to handle
the translation into Linux irq numbers correctly which is probably the
more difficult part.

Rob
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
M

Re: [PATCH 2/2] clk: exynos-audss: Fix memory leak on driver unbind or probe failure

[Mike Turquette]

Quoting Stephen Boyd (2015-01-08 13:23:13)
> On 01/05/2015 01:52 AM, Krzysztof Kozlowski wrote:
> > The memory allocated by basic clock divider/gate/mux (struct clk_gate,
> > clk_divider and clk_mux) was leaking. During driver unbind or probe
> > failure the driver only unregistered the clocks.
> >
> > Use clk_unregister_{gate,divider,mux} to release all resources.
> >
> > Signed-off-by: Krzysztof Kozlowski 
> >
> 
> Reviewed-by: Stephen Boyd 

I've applied both patches to clk-next. Krzysztof, let me know if you
would prefer to take the audss patch through the samsung clock branch
instead (to include it in a later pull request).

Regards,
Mike

> 
> -- 
> Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
> a Linux Foundation Collaborative Project
> 
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH v4 1/3] i2c: iProc: define Broadcom iProc I2C binding

[Ray Jui]

Document the I2C device tree binding for Broadcom iProc family of
SoCs

Signed-off-by: Ray Jui 
Reviewed-by: Scott Branden 
---
 .../devicetree/bindings/i2c/brcm,iproc-i2c.txt |   37 
 1 file changed, 37 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/i2c/brcm,iproc-i2c.txt

diff --git a/Documentation/devicetree/bindings/i2c/brcm,iproc-i2c.txt 
b/Documentation/devicetree/bindings/i2c/brcm,iproc-i2c.txt
new file mode 100644
index 000..81f982c
--- /dev/null
+++ b/Documentation/devicetree/bindings/i2c/brcm,iproc-i2c.txt
@@ -0,0 +1,37 @@
+Broadcom iProc I2C controller
+
+Required properties:
+
+- compatible:
+Must be "brcm,iproc-i2c"
+
+- reg:
+Define the base and range of the I/O address space that contain the iProc
+I2C controller registers
+
+- interrupts:
+Should contain the I2C interrupt
+
+- clock-frequency:
+This is the I2C bus clock. Need to be either 10 or 40
+
+- #address-cells:
+Always 1 (for I2C addresses)
+
+- #size-cells:
+Always 0
+
+Example:
+   i2c0: i2c@18008000 {
+   compatible = "brcm,iproc-i2c";
+   reg = <0x18008000 0x100>;
+   #address-cells = <1>;
+   #size-cells = <0>;
+   interrupts = ;
+   clock-frequency = <10>;
+
+   codec: wm8750@1a {
+   compatible = "wlf,wm8750";
+   reg = <0x1a>;
+   };
+   };
-- 
1.7.9.5

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

[PATCH v4 2/3] i2c: iproc: Add Broadcom iProc I2C Driver

[Ray Jui]

Add initial support to the Broadcom iProc I2C controller found in the
iProc family of SoCs.

The iProc I2C controller has separate internal TX and RX FIFOs, each has
a size of 64 bytes. The iProc I2C controller supports two bus speeds
including standard mode (100kHz) and fast mode (400kHz)

Signed-off-by: Ray Jui 
Reviewed-by: Scott Branden 
---
 drivers/i2c/busses/Kconfig |   10 +
 drivers/i2c/busses/Makefile|1 +
 drivers/i2c/busses/i2c-bcm-iproc.c |  503 
 3 files changed, 514 insertions(+)
 create mode 100644 drivers/i2c/busses/i2c-bcm-iproc.c

diff --git a/drivers/i2c/busses/Kconfig b/drivers/i2c/busses/Kconfig
index 31e8308..af76d23 100644
--- a/drivers/i2c/busses/Kconfig
+++ b/drivers/i2c/busses/Kconfig
@@ -372,6 +372,16 @@ config I2C_BCM2835
  This support is also available as a module.  If so, the module
  will be called i2c-bcm2835.
 
+config I2C_BCM_IPROC
+   tristate "Broadcom iProc I2C controller"
+   depends on ARCH_BCM_IPROC || COMPILE_TEST
+   default ARCH_BCM_IPROC
+   help
+ If you say yes to this option, support will be included for the
+ Broadcom iProc I2C controller.
+
+ If you don't know what to do here, say N.
+
 config I2C_BCM_KONA
tristate "BCM Kona I2C adapter"
depends on ARCH_BCM_MOBILE
diff --git a/drivers/i2c/busses/Makefile b/drivers/i2c/busses/Makefile
index 56388f6..d93b509 100644
--- a/drivers/i2c/busses/Makefile
+++ b/drivers/i2c/busses/Makefile
@@ -33,6 +33,7 @@ obj-$(CONFIG_I2C_AT91)+= i2c-at91.o
 obj-$(CONFIG_I2C_AU1550)   += i2c-au1550.o
 obj-$(CONFIG_I2C_AXXIA)+= i2c-axxia.o
 obj-$(CONFIG_I2C_BCM2835)  += i2c-bcm2835.o
+obj-$(CONFIG_I2C_BCM_IPROC)+= i2c-bcm-iproc.o
 obj-$(CONFIG_I2C_BLACKFIN_TWI) += i2c-bfin-twi.o
 obj-$(CONFIG_I2C_CADENCE)  += i2c-cadence.o
 obj-$(CONFIG_I2C_CBUS_GPIO)+= i2c-cbus-gpio.o
diff --git a/drivers/i2c/busses/i2c-bcm-iproc.c 
b/drivers/i2c/busses/i2c-bcm-iproc.c
new file mode 100644
index 000..7d9ed4e
--- /dev/null
+++ b/drivers/i2c/busses/i2c-bcm-iproc.c
@@ -0,0 +1,503 @@
+/*
+ * Copyright (C) 2014 Broadcom Corporation
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License as
+ * published by the Free Software Foundation version 2.
+ *
+ * This program is distributed "as is" WITHOUT ANY WARRANTY of any
+ * kind, whether express or implied; 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 CFG_OFFSET   0x00
+#define CFG_RESET_SHIFT  31
+#define CFG_EN_SHIFT 30
+#define CFG_M_RETRY_CNT_SHIFT16
+#define CFG_M_RETRY_CNT_MASK 0x0f
+
+#define TIM_CFG_OFFSET   0x04
+#define TIME_CFG_MODE_400_SHIFT  31
+
+#define M_FIFO_CTRL_OFFSET   0x0c
+#define M_FIFO_RX_FLUSH_SHIFT31
+#define M_FIFO_TX_FLUSH_SHIFT30
+#define M_FIFO_RX_CNT_SHIFT  16
+#define M_FIFO_RX_CNT_MASK   0x7f
+#define M_FIFO_RX_THLD_SHIFT 8
+#define M_FIFO_RX_THLD_MASK  0x3f
+
+#define M_CMD_OFFSET 0x30
+#define M_CMD_START_BUSY_SHIFT   31
+#define M_CMD_STATUS_SHIFT   25
+#define M_CMD_STATUS_MASK0x07
+#define M_CMD_STATUS_SUCCESS 0x0
+#define M_CMD_STATUS_LOST_ARB0x1
+#define M_CMD_STATUS_NACK_ADDR   0x2
+#define M_CMD_STATUS_NACK_DATA   0x3
+#define M_CMD_STATUS_TIMEOUT 0x4
+#define M_CMD_PROTOCOL_SHIFT 9
+#define M_CMD_PROTOCOL_MASK  0xf
+#define M_CMD_PROTOCOL_BLK_WR0x7
+#define M_CMD_PROTOCOL_BLK_RD0x8
+#define M_CMD_PEC_SHIFT  8
+#define M_CMD_RD_CNT_SHIFT   0
+#define M_CMD_RD_CNT_MASK0xff
+
+#define IE_OFFSET0x38
+#define IE_M_RX_FIFO_FULL_SHIFT  31
+#define IE_M_RX_THLD_SHIFT   30
+#define IE_M_START_BUSY_SHIFT28
+
+#define IS_OFFSET0x3c
+#define IS_M_RX_FIFO_FULL_SHIFT  31
+#define IS_M_RX_THLD_SHIFT   30
+#define IS_M_START_BUSY_SHIFT28
+
+#define M_TX_OFFSET  0x40
+#define M_TX_WR_STATUS_SHIFT 31
+#define M_TX_DATA_SHIFT  0
+#define M_TX_DATA_MASK   0xff
+
+#define M_RX_OFFSET  0x44
+#define M_RX_STATUS_SHIFT30
+#define M_RX_STATUS_MASK 0x03
+#define M_RX_PEC_ERR_SHIFT   29
+#define M_RX_DATA_SHIFT  0
+#define M_RX_DATA_MASK   0xff
+
+#define I2C_TIMEOUT_MESC 100
+#define M_TX_RX_FIFO_SIZE64
+
+enum bus_speed_index {
+   I2C_SPD_100K = 0,
+   I2C_SPD_400K,
+};
+
+struct bcm_iproc_i2c_dev {
+

[PATCH v4 0/3] Add I2C support to Broadcom iProc

[Ray Jui]

This patchset contains the initial I2C support for Broadcom iProc family of
SoCs.

The iProc I2C controller has separate internal TX and RX FIFOs, each has a
size of 64 bytes. The iProc I2C controller supports two bus speeds including
standard mode (100 kHz) and fast mode (400 kHz)

Changes from v3:
 - Add config dependency to COMPILE_TEST to allow the driver to be build tested
   by other platforms
 - Improve CPU utilization efficiency in the loop of waiting for bus to idle
 - Add more comment in the driver to clarify the way how the "start busy"
   interrupt is triggered from the I2C controller
 - Fix inconsistent coding style and format
 - Improve the bus speed validation logic in the driver
 - Add code to free the interrupt line in driver's remove function. Also
   change to use non-devm API to request the interrupt line
 - Other miscellaneous improvements and fixes

Changes from v2:
 - Have the I2C driver default to y so it does not need to be selected from
   ARCH_BCM_IPROC. This also helps to get rid of one patch. The driver still
   depends on ARCH_BCM_IPROC
 - Get rid of redundant check on resource returned by platform_get_resource

Changes from v1:
 - Fix function argument parenthesis
 - Get rid of redundant driver owner field

Ray Jui (3):
  i2c: iProc: define Broadcom iProc I2C binding
  i2c: iproc: Add Broadcom iProc I2C Driver
  ARM: dts: add I2C device nodes for Broadcom Cygnus

 .../devicetree/bindings/i2c/brcm,iproc-i2c.txt |   37 ++
 arch/arm/boot/dts/bcm-cygnus.dtsi  |   20 +
 drivers/i2c/busses/Kconfig |   10 +
 drivers/i2c/busses/Makefile|1 +
 drivers/i2c/busses/i2c-bcm-iproc.c |  503 
 5 files changed, 571 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/i2c/brcm,iproc-i2c.txt
 create mode 100644 drivers/i2c/busses/i2c-bcm-iproc.c

-- 
1.7.9.5

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

[PATCH v4 3/3] ARM: dts: add I2C device nodes for Broadcom Cygnus

[Ray Jui]

Add I2C device nodes and its properties in bcm-cygnus.dtsi but keep
them disabled there. Individual I2C devices can be enabled in board
specific dts file when I2C slave devices are enabled in the future

Signed-off-by: Ray Jui 
Reviewed-by: Scott Branden 
---
 arch/arm/boot/dts/bcm-cygnus.dtsi |   20 
 1 file changed, 20 insertions(+)

diff --git a/arch/arm/boot/dts/bcm-cygnus.dtsi 
b/arch/arm/boot/dts/bcm-cygnus.dtsi
index 5126f9e..f7d6c1d 100644
--- a/arch/arm/boot/dts/bcm-cygnus.dtsi
+++ b/arch/arm/boot/dts/bcm-cygnus.dtsi
@@ -70,6 +70,26 @@
};
};
 
+   i2c0: i2c@18008000 {
+   compatible = "brcm,iproc-i2c";
+   reg = <0x18008000 0x100>;
+   #address-cells = <1>;
+   #size-cells = <0>;
+   interrupts = ;
+   clock-frequency = <10>;
+   status = "disabled";
+   };
+
+   i2c1: i2c@1800b000 {
+   compatible = "brcm,iproc-i2c";
+   reg = <0x1800b000 0x100>;
+   #address-cells = <1>;
+   #size-cells = <0>;
+   interrupts = ;
+   clock-frequency = <10>;
+   status = "disabled";
+   };
+
uart0: serial@1802 {
compatible = "snps,dw-apb-uart";
reg = <0x1802 0x100>;
-- 
1.7.9.5

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

[PATCH v2 1/2] fixup! net/macb: Adding comments to various #defs to make interpretation easier

[Xander Huff]

Put #define comments into a single line.

Signed-off-by: Xander Huff 
---
 drivers/net/ethernet/cadence/macb.h | 107 +---
 1 file changed, 26 insertions(+), 81 deletions(-)

diff --git a/drivers/net/ethernet/cadence/macb.h 
b/drivers/net/ethernet/cadence/macb.h
index 378b218..d7b93d0 100644
--- a/drivers/net/ethernet/cadence/macb.h
+++ b/drivers/net/ethernet/cadence/macb.h
@@ -275,9 +275,7 @@
 #define MACB_THALT_SIZE1
 #define MACB_NCR_TPF_OFFSET11 /* Transmit pause frame */
 #define MACB_NCR_TPF_SIZE  1
-#define MACB_TZQ_OFFSET12 /* Transmit zero 
quantum
-   * pause frame
-   */
+#define MACB_TZQ_OFFSET12 /* Transmit zero 
quantum pause frame */
 #define MACB_TZQ_SIZE  1
 
 /* Bitfields in NCFGR */
@@ -299,9 +297,7 @@
 #define MACB_UNI_SIZE  1
 #define MACB_BIG_OFFSET8 /* Receive 1536 byte 
frames */
 #define MACB_BIG_SIZE  1
-#define MACB_EAE_OFFSET9 /* External address 
match
-  * enable
-  */
+#define MACB_EAE_OFFSET9 /* External address 
match enable */
 #define MACB_EAE_SIZE  1
 #define MACB_CLK_OFFSET10
 #define MACB_CLK_SIZE  2
@@ -313,9 +309,7 @@
 #define MACB_RM9200_RMII_SIZE  1  /* AT91RM9200 only */
 #define MACB_RBOF_OFFSET   14 /* Receive buffer offset */
 #define MACB_RBOF_SIZE 2
-#define MACB_RLCE_OFFSET   16 /* Length field error frame
-   * discard
-   */
+#define MACB_RLCE_OFFSET   16 /* Length field error frame 
discard */
 #define MACB_RLCE_SIZE 1
 #define MACB_DRFCS_OFFSET  17 /* FCS remove */
 #define MACB_DRFCS_SIZE1
@@ -335,41 +329,22 @@
 #define GEM_RXCOEN_SIZE1
 
 /* Constants for data bus width. */
-#define GEM_DBW32  0 /* 32 bit AMBA AHB data bus
-  * width
-  */
-#define GEM_DBW64  1 /* 64 bit AMBA AHB data bus
-  * width
-  */
-#define GEM_DBW128 2 /* 128 bit AMBA AHB data bus
-  * width
-  */
+#define GEM_DBW32  0 /* 32 bit AMBA AHB data bus 
width */
+#define GEM_DBW64  1 /* 64 bit AMBA AHB data bus 
width */
+#define GEM_DBW128 2 /* 128 bit AMBA AHB data bus 
width */
 
 /* Bitfields in DMACFG. */
-#define GEM_FBLDO_OFFSET   0 /* AHB fixed burst length for
-  * DMA data operations
-  */
+#define GEM_FBLDO_OFFSET   0 /* AHB fixed burst length for 
DMA data operations */
 #define GEM_FBLDO_SIZE 5
-#define GEM_ENDIA_OFFSET   7 /* AHB endian swap mode enable
-  * for packet data accesses
-  */
+#define GEM_ENDIA_OFFSET   7 /* AHB endian swap mode 
enable for packet data accesses */
 #define GEM_ENDIA_SIZE 1
-#define GEM_RXBMS_OFFSET   8 /* Receiver packet buffer
-  * memory size select
-  */
+#define GEM_RXBMS_OFFSET   8 /* Receiver packet buffer 
memory size select */
 #define GEM_RXBMS_SIZE 2
-#define GEM_TXPBMS_OFFSET  10 /* Transmitter packet buffer
-   * memory size select
-   */
+#define GEM_TXPBMS_OFFSET  10 /* Transmitter packet buffer 
memory size select */
 #define GEM_TXPBMS_SIZE1
-#define GEM_TXCOEN_OFFSET  11 /* Transmitter IP, TCP and
-   * UDP checksum generation
-   * o

[PATCH v2 2/2] fixup! net/macb: improved ethtool statistics support

[Xander Huff]

Add spaces around arithmetic operators.
Make a separate gem_ethtool_ops for the new statistics functions.
Adjust new block comments to match the existing comments in macb.h.

Signed-off-by: Xander Huff 
---
 drivers/net/ethernet/cadence/macb.c |  25 +++--
 drivers/net/ethernet/cadence/macb.h | 203 +---
 2 files changed, 68 insertions(+), 160 deletions(-)

diff --git a/drivers/net/ethernet/cadence/macb.c 
b/drivers/net/ethernet/cadence/macb.c
index dd8c202..f60f8f8 100644
--- a/drivers/net/ethernet/cadence/macb.c
+++ b/drivers/net/ethernet/cadence/macb.c
@@ -1832,15 +1832,15 @@ static void gem_update_stats(struct macb *bp)
 
for (i = 0; i < GEM_STATS_LEN; ++i, ++p) {
u32 offset = gem_statistics[i].offset;
-   u64 val = __raw_readl(bp->regs+offset);
+   u64 val = __raw_readl(bp->regs + offset);
 
bp->ethtool_stats[i] += val;
*p += val;
 
if (offset == GEM_OCTTXL || offset == GEM_OCTRXL) {
/* Add GEM_OCTTXH, GEM_OCTRXH */
-   val = __raw_readl(bp->regs+offset+4);
-   bp->ethtool_stats[i] += ((u64)val)<<32;
+   val = __raw_readl(bp->regs+offset + 4);
+   bp->ethtool_stats[i] += ((u64)val) << 32;
*(++p) += val;
}
}
@@ -1891,7 +1891,7 @@ static void gem_get_ethtool_stats(struct net_device *dev,
 
bp = netdev_priv(dev);
gem_update_stats(bp);
-   memcpy(data, &bp->ethtool_stats, sizeof(u64)*GEM_STATS_LEN);
+   memcpy(data, &bp->ethtool_stats, sizeof(u64) * GEM_STATS_LEN);
 }
 
 static int gem_get_sset_count(struct net_device *dev, int sset)
@@ -2032,11 +2032,21 @@ const struct ethtool_ops macb_ethtool_ops = {
.get_regs   = macb_get_regs,
.get_link   = ethtool_op_get_link,
.get_ts_info= ethtool_op_get_ts_info,
+};
+EXPORT_SYMBOL_GPL(macb_ethtool_ops);
+
+const struct ethtool_ops gem_ethtool_ops = {
+   .get_settings   = macb_get_settings,
+   .set_settings   = macb_set_settings,
+   .get_regs_len   = macb_get_regs_len,
+   .get_regs   = macb_get_regs,
+   .get_link   = ethtool_op_get_link,
+   .get_ts_info= ethtool_op_get_ts_info,
.get_ethtool_stats  = gem_get_ethtool_stats,
.get_strings= gem_get_ethtool_strings,
.get_sset_count = gem_get_sset_count,
 };
-EXPORT_SYMBOL_GPL(macb_ethtool_ops);
+EXPORT_SYMBOL_GPL(gem_ethtool_ops);
 
 int macb_ioctl(struct net_device *dev, struct ifreq *rq, int cmd)
 {
@@ -2325,7 +2335,10 @@ static int __init macb_probe(struct platform_device 
*pdev)
 
dev->netdev_ops = &macb_netdev_ops;
netif_napi_add(dev, &bp->napi, macb_poll, 64);
-   dev->ethtool_ops = &macb_ethtool_ops;
+   if (macb_is_gem(bp))
+   dev->ethtool_ops = &gem_ethtool_ops;
+   else
+   dev->ethtool_ops = &macb_ethtool_ops;
 
dev->base_addr = regs->start;
 
diff --git a/drivers/net/ethernet/cadence/macb.h 
b/drivers/net/ethernet/cadence/macb.h
index d7b93d0..2ea5355 100644
--- a/drivers/net/ethernet/cadence/macb.h
+++ b/drivers/net/ethernet/cadence/macb.h
@@ -82,159 +82,52 @@
 #define GEM_SA4B   0x00A0 /* Specific4 Bottom */
 #define GEM_SA4T   0x00A4 /* Specific4 Top */
 #define GEM_OTX0x0100 /* Octets 
transmitted */
-#define GEM_OCTTXL 0x0100 /* Octets transmitted
-   * [31:0]
-   */
-#define GEM_OCTTXH 0x0104 /* Octets transmitted
-   * [47:32]
-   */
-#define GEM_TXCNT  0x0108 /* Error-free Frames
-   * Transmitted counter
-   */
-#define GEM_TXBCCNT0x010c /* Error-free Broadcast
-   * Frames counter
-   */
-#define GEM_TXMCCNT0x0110 /* Error-free Multicast
-   * Frames counter
-   */
-#define GEM_TXPAUSECNT 0x0114 /* Pause Frames
-   * Transmitted Counter
-   */
-#define GEM_TX64CNT0x0118 /* Error-free 64 byte
-   * Frames 

Re: [PULL] uaccess: fix sparse warning on get/put_user for bitwise types

[Arnd Bergmann]

On Wednesday 14 January 2015 19:36:18 Michael S. Tsirkin wrote:
> As you asked, here's a pull request.
> This has been in linux-next apparently with no ill effects.
> 
> The following changes since commit 99975cc6ada0d5f2675e83abecae05aba5f437d2:
> 
>   vhost/net: length miscalculation (2015-01-07 12:22:00 +0200)
> 
> are available in the git repository at:
> 
>   git://git.kernel.org/pub/scm/linux/kernel/git/mst/vhost.git 
> tags/uaccess_for_upstream
> 
> for you to fetch changes up to 0795cb1b46e7938ed679ccd48f933e75272b30e3:
> 

Pulled into my asm-generic now, thanks!

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

Re: [PATCH 01/11] x86: entry_64.S: always allocate complete "struct pt_regs"

[Denys Vlasenko]

On Wed, Jan 14, 2015 at 10:48 PM, Denys Vlasenko  wrote:
> Macros which manipulate "struct pt_regs" on stack are reworked:
> ALLOC_PT_GPREGS_ON_STACK allocates the structure.
> SAVE_C_REGS saves to it those registers which are clobbered by C code.
> SAVE_EXTRA_REGS saves to it all other registers.
> Corresponding RESTORE_* and REMOVE_PT_GPREGS_FROM_STACK macros reverse it.

Andy,

Please note that this patch set also needs the previously posted patch:

[PATCH 3/4] x86: open-code register save/restore in trace_hardirqs thunks

which is not present in your tree - otherwise arch/x86/lib/thunk_64.S
will not compile (no SAVE_ARGS anymore).

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

Re: [RFC PATCH 0/2] clk: rockchip: leave npll for DCLK_VOP0(HDMI) only

[Mike Turquette]

Quoting Heiko Stübner (2015-01-08 14:30:01)
> Hi Kever,
> 
> Am Montag, 17. November 2014, 22:55:36 schrieb Kever Yang:
> > To support all kinds of frequency requirement for HDMI on rk3288,
> > we need a PLL that can change rate at run time.
> > 
> > There are some discussion before at [0], I think we can just leave
> > the npll for HDMI(DCLK_VOP0) used to make it simple.
> > 
> > Comments are welcome.
> 
> I think I said it in private somewhere already, but just so it's also 
> available publically:
> 
> I don't think customizing/limiting the clock usage like this will fly, 
> especially as this would require each and every rk3288 board to use vop0 for 
> hdmi and vop1 for other stuff.
> 
> With the new rk3288 Firefly devboard this concern already becomes reality. 
> There a vga converter is connected to VOP0, which leaves only vop1 for hdmi 
> if 
> one wants to support the vga connection.
> 
> 
> From our discussion about this problem I remember that the missing clock 
> frequencies only affected more esotheric screen resolutions, so personally 
> I'm 
> not this much concerned an would like to wait till we find a better solution 
> to 
> the problem.

Ack. We shouldn't have to limit the possible hardware configurations in
software just to keep things simple. This points to a deficiency in the
clock framework. This is a common concern: how to change a clock
frequency for one user without exploding all of the other users.

Do you think Tomeu's constraints API[0] might be a step in the right
direction for you?

[0] 
http://lkml.kernel.org/r/<1421071809-17402-3-git-send-email-tomeu.viz...@collabora.com>

Regards,
Mike

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

[GIT] Networking

[David Miller]

1) Don't use uninitialized data in IPVS, from Dan Carpenter.

2) conntrack race fixes from Pablo Neira Ayuso.

3) Fix TX hangs with i40e, from Jesse Brandeburg.

4) Fix budget return from poll calls in dnet and alx, from Eric Dumazet.

5) Fix bugus "if (unlikely(x) < 0)" test in AF_PACKET, from Christoph   
   Jaeger.

6) Fix bug introduced by conversion to list_head in TIPC retransmit
   code, from Jon Paul Maloy.

7) Don't use GFP_NOIO under spinlock in USB kaweth driver, from Alexey
   Khoroshilov.

8) Fix bridge build with INET disabled, from Arnd Bergmann.

9) Fix netlink array overrun for PROBE attributes in openvswitch,
   from Thomas Graf.

10) Don't hold spinlock across synchronize_irq() in tg3 driver, from
Prashant Sreedharan.

Please pull, thanks a lot.

The following changes since commit bdec41963890f8ed9ad89f8b418959ab3cdc2aa3:

  Merge git://git.kernel.org/pub/scm/linux/kernel/git/davem/net (2015-01-06 
17:48:14 -0800)

are available in the git repository at:


  git://git.kernel.org/pub/scm/linux/kernel/git/davem/net.git master

for you to fetch changes up to c637dbcedf31ce1dd813a461de406f45aa7a3d38:

  Merge branch 'tg3-net' (2015-01-14 17:05:55 -0500)



Alexandre Belloni (1):
  net/at91_ether: prepare and unprepare clock

Alexey Khoroshilov (1):
  usb/kaweth: use GFP_ATOMIC under spin_lock in usb_start_wait_urb()

Ani Sinha (1):
  update ip-sysctl.txt documentation (v2)

Anjali Singhai (2):
  i40e: Fix Rx checksum error counter
  i40e: Fix bug with TCP over IPv6 over VXLAN

Arik Nemtsov (1):
  iwlwifi: pcie: correctly define 7265-D cfg

Arnd Bergmann (1):
  bridge: only provide proxy ARP when CONFIG_INET is enabled

B Viswanath (1):
  net: Corrected the comment describing the ndo operations to reflect the 
actual prototype for couple of operations

Benjamin Poirier (1):
  netdevice: Add missing parentheses in macro

Christoph Jaeger (1):
  packet: bail out of packet_snd() if L2 header creation fails

Dan Carpenter (1):
  ipvs: uninitialized data with IP_VS_IPV6

David S. Miller (4):
  Merge branch 'master' of git://git.kernel.org/.../jkirsher/net
  Merge git://git.kernel.org/.../pablo/nf
  Merge tag 'wireless-drivers-for-davem-2015-01-09' of 
git://git.kernel.org/.../kvalo/wireless-drivers
  Merge branch 'tg3-net'

David Spinadel (2):
  iwlwifi: mvm: add a flag to enable match found notification
  iwlwifi: mvm: scan dwell time corrections

David Vrabel (1):
  xen-netfront: use different locks for Rx and Tx stats

Emmanuel Grumbach (2):
  iwlwifi: 7000: fix reported firmware name for 7265D
  iwlwifi: bump firmware API for mvm devices to 12

Eric Dumazet (2):
  net: dnet: fix dnet_poll()
  alx: fix alx_poll()

Eyal Shapira (2):
  iwlwifi: mvm: fix Rx with both chains
  iwlwifi: mvm: fix out of bounds access to tid_to_mac80211_ac

Giel van Schijndel (1):
  isdn: fix NUL (\0 or \x00) specification in string

Hariprasad Shenai (2):
  cxgb4vf: Initialize mdio_addr before using it
  cxgb4vf: Fix queue allocation for 40G adapter

Hubert Feurstein (1):
  net: fec: fix NULL pointer dereference in fec_enet_timeout_work

Jean-Francois Remy (1):
  neighbour: fix base_reachable_time(_ms) not effective immediatly when 
changed

Jesse Brandeburg (1):
  i40e: fix un-necessary Tx hangs

Jiri Pirko (1):
  team: avoid possible underflow of count_pending value for notify_peers 
and mcast_rejoin

Jon Paul Maloy (1):
  tipc: fix bug in broadcast retransmit code

Kalle Valo (1):
  Merge tag 'iwlwifi-for-kalle-2015-01-05' of 
https://git.kernel.org/.../iwlwifi/iwlwifi-fixes

Larry Finger (1):
  rtlwifi: Fix error when accessing unmapped memory in skb

Mugunthan V N (1):
  drivers: net: cpsw: fix multicast flush in dual emac mode

Nobuhiro Iwamatsu (2):
  sh-eth: Set fdr_value of R-Car SoCs
  sh_eth: Fix access to TRSCER register

Pablo Neira Ayuso (5):
  Merge tag 'ipvs2-for-v3.19' of https://git.kernel.org/.../horms/ipvs-next 
into ipvs-next
  netfilter: conntrack: fix race between confirmation and flush
  netfilter: nfnetlink: validate nfnetlink header from batch
  netfilter: nfnetlink: relax strict multicast group check from netlink_bind
  netfilter: nf_tables: fix flush ruleset chain dependencies

Prashant Sreedharan (3):
  tg3: tg3_timer() should grab tp->lock before checking for tp->irq_sync
  tg3: tg3_reset_task() needs to use rtnl_lock to synchronize
  tg3: Release tp->lock before invoking synchronize_irq()

Stefan Agner (1):
  net: fec: fix MDIO bus assignement for dual fec SoC's

Thomas Falcon (1):
  MAINTAINERS: add me as ibmveth maintainer

Thomas Graf (1):
  openvswitch: packet messages need their own probe attribtue

Vasu Dev (1):
  i40e: adds FCoE configure option

leroy christophe (1):
  netfilter: nf_tables: fix port natting in litt

Re: [PATCH 1/6] ARM: at91: pm: rework cpu detection

[Arnd Bergmann]

On Wednesday 14 January 2015 22:07:34 Alexandre Belloni wrote:
> Hi,
> 
> (Adding Arnd in Cc)
> 
> On 15/01/2015 at 04:37:14 +0800, Jean-Christophe PLAGNIOL-VILLARD wrote :
> > >>> -   /* AT91RM9200 SDRAM low-power mode cannot be used with 
> > >>> self-refresh. */
> > >>> -   if (cpu_is_at91rm9200())
> > >>> +   at91_pm_data.memctrl = AT91_MEMCTRL_SDRAMC;
> > >>> +
> > >>> +   if (of_machine_is_compatible("atmel,at91rm9200")) {
> > >>> +   /*
> > >>> +* AT91RM9200 SDRAM low-power mode cannot be used with
> > >>> +* self-refresh.
> > >>> +*/
> > >>> at91_ramc_write(0, AT91RM9200_SDRAMC_LPR, 0);
> > >>> -   
> > >>> +
> > >>> +   at91_pm_data.uhp_udp_mask = AT91RM9200_PMC_UHP |
> > >>> +   AT91RM9200_PMC_UDP;
> > >>> +   at91_pm_data.memctrl = AT91_MEMCTRL_MC;
> > >>> +   } else if (of_machine_is_compatible("atmel,at91sam9260") ||
> > >>> +  of_machine_is_compatible("atmel,at91sam9g20") ||
> > >>> +  of_machine_is_compatible("atmel,at91sam9261") ||
> > >>> +  of_machine_is_compatible("atmel,at91sam9g10") ||
> > >>> +  of_machine_is_compatible("atmel,at91sam9263")) {
> > >> nack here
> > >> 
> > >> you switch for runtime information from the SOC register store in ram to 
> > >> DT
> > >> 
> > >> DT is great but I do prefer to rely on the SoC register here as the 
> > >> whole was
> > >> also to check that the is correct
> > > 
> > > Well, cpu_is_xxx macros are defined in a mach specific header, and we're
> > > currently trying to enable multi platform support. 
> > 
> > Yes does not mean we can not move this, use the REAL hardware detected cpu 
> > is better
> > as you can check that the DT is valid for this SoC and also have fixup for 
> > a specific
> > SoC version without having to have x DT per SoC

We should definitely be able to confine the SoC detection to at91sam9 though,
because in the three other cases (rm9200, sama5d3, sama5d4), we already have
separate machine descriptors and don't need to do any detection.

> > >> wihich is way slower
> > > 
> > > Hmm, this SoC detection has been move from the suspend path (where, as
> > > you stated, speed is a real concern) to the pm init function (which is
> > > only called once at startup), and I doubt the boot time penalty will
> > > even be noticeable…
> > 
> > except if your table is boot as quick as possible avoid useless string 
> > compare is always a good choice
> > 
> > IIRC we had in the past RFC to have the drivers compatible compare switch 
> > to HASH
> > for this purpose too
> > 
> 
> Following a discussion with Arnd, the whole SoC detection will be remove
> which will be completely faster than mapping the dbgu registers.
> 
> Also, the of_machine_is_compatible are supposed to be removed soon,
> waiting for the pm code to be reworked. What is done here is to allow us
> to go forward with switching to multiplatform and cleaning up the
> mach-at91 directory.
> 
> I have follow up patches coming up and they already remove some of the
> of_machine_is_compatible.

As you have already confined the of_machine_is_compatible() checks
to one top-level function, and we have found that this function
should not be an unconditional arch_initcall, I think the easiest
way forward is to split at91_pm_init into multiple functions,
one per case you need to handle, and then use a machine_descriptor
with a list of compatible strings to match it.

I think that just means we need an extra machine descriptor to
handle the at91sam9g45, but that will get folded again over time.

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

Re: [PATCH] ksoftirqd: Enable IRQs and call cond_resched() before poking RCU

[Paul E. McKenney]

On Tue, Jan 13, 2015 at 01:16:18PM -0800, Calvin Owens wrote:
> While debugging an issue with excessive softirq usage, I encountered the
> following note in commit 3e339b5dae24a706 ("softirq: Use hotplug thread
> infrastructure"):
> 
> [ paulmck: Call rcu_note_context_switch() with interrupts enabled. ]
> 
> ...but despite this note, the patch still calls RCU with IRQs disabled.
> 
> This seemingly innocuous change caused a significant regression in softirq
> CPU usage on the sending side of a large TCP transfer (~1 GB/s): when
> introducing 0.01% packet loss, the softirq usage would jump to around 25%,
> spiking as high as 50%. Before the change, the usage would never exceed 5%.
> 
> Moving the call to rcu_note_context_switch() after the cond_sched() call,
> as it was originally before the hotplug patch, completely eliminated this
> problem.
> 
> Signed-off-by: Calvin Owens 
> Cc: sta...@vger.kernel.org

Applied, thank you!  I deleted the "cpu" arguments from the calls to
rcu_note_context_switch() below in order for the patch to apply.

I the put the patch following that on top, as Thomas suggested.

Thanx, Paul

> ---
> This version includes the "cpu" argument to rcu_note_context_switch() in
> order to apply cleanly to stable kernels. It will need to be removed to
> apply to 3.18+ and 3.19 (upstream commit 38200cf2 removed the argument).
> 
>  kernel/softirq.c | 6 +-
>  1 file changed, 5 insertions(+), 1 deletion(-)
> 
> diff --git a/kernel/softirq.c b/kernel/softirq.c
> index 501baa9..9e787d8 100644
> --- a/kernel/softirq.c
> +++ b/kernel/softirq.c
> @@ -656,9 +656,13 @@ static void run_ksoftirqd(unsigned int cpu)
>* in the task stack here.
>*/
>   __do_softirq();
> - rcu_note_context_switch(cpu);
>   local_irq_enable();
>   cond_resched();
> +
> + preempt_disable();
> + rcu_note_context_switch(cpu);
> + preempt_enable();
> +
>   return;
>   }
>   local_irq_enable();
> -- 
> 2.1.1



ksoftirqd: Use new cond_resched_rcu_qs() function

Simplify run_ksoftirqd() by using the new cond_resched_rcu_qs() function
that conditionally reschedules, but unconditionally supplies an RCU
quiescent state.  This commit is separate from the previous commit by
Calvin Owens because Calvin's approach can be backported, while this
commit cannot be.  The reason that this commit cannot be backported is
that cond_resched_rcu_qs() does not always provide the needed quiescent
state in earlier kernels.

Signed-off-by: Paul E. McKenney 

diff --git a/kernel/softirq.c b/kernel/softirq.c
index c497fcdf0d1e..8cdb98847c7b 100644
--- a/kernel/softirq.c
+++ b/kernel/softirq.c
@@ -657,12 +657,7 @@ static void run_ksoftirqd(unsigned int cpu)
 */
__do_softirq();
local_irq_enable();
-   cond_resched();
-
-   preempt_disable();
-   rcu_note_context_switch();
-   preempt_enable();
-
+   cond_resched_rcu_qs();
return;
}
local_irq_enable();

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] Use dwfl_report_elf() instead of offline

[Sukadev Bhattiprolu]

>From 8e6fb4c58d0d9f4798c191d840e32084b1217cc3 Mon Sep 17 00:00:00 2001
From: Sukadev Bhattiprolu 
Date: Fri, 21 Nov 2014 20:33:53 -0500
Subject: [PATCH 1/1] Use dwfl_report_elf() instead of offline.

dwfl_report_offline() works only when libraries are prelinked.

Replace dwfl_report_offline() with dwfl_report_elf() so we correctly
extract debug info even from libraries that are not prelinked.

Reported-by: Jiri Olsa 
Signed-off-by: Sukadev Bhattiprolu 
---
 tools/perf/arch/powerpc/util/skip-callchain-idx.c | 19 +++
 1 file changed, 11 insertions(+), 8 deletions(-)

diff --git a/tools/perf/arch/powerpc/util/skip-callchain-idx.c 
b/tools/perf/arch/powerpc/util/skip-callchain-idx.c
index 3bb50ea..0c370f8 100644
--- a/tools/perf/arch/powerpc/util/skip-callchain-idx.c
+++ b/tools/perf/arch/powerpc/util/skip-callchain-idx.c
@@ -103,7 +103,7 @@ static Dwarf_Frame *get_eh_frame(Dwfl_Module *mod, 
Dwarf_Addr pc)
return NULL;
}
 
-   result = dwarf_cfi_addrframe(cfi, pc, &frame);
+   result = dwarf_cfi_addrframe(cfi, pc-bias, &frame);
if (result) {
pr_debug("%s(): %s\n", __func__, dwfl_errmsg(-1));
return NULL;
@@ -128,7 +128,7 @@ static Dwarf_Frame *get_dwarf_frame(Dwfl_Module *mod, 
Dwarf_Addr pc)
return NULL;
}
 
-   result = dwarf_cfi_addrframe(cfi, pc, &frame);
+   result = dwarf_cfi_addrframe(cfi, pc-bias, &frame);
if (result) {
pr_debug("%s(): %s\n", __func__, dwfl_errmsg(-1));
return NULL;
@@ -145,7 +145,7 @@ static Dwarf_Frame *get_dwarf_frame(Dwfl_Module *mod, 
Dwarf_Addr pc)
  * yet used)
  * -1 in case of errors
  */
-static int check_return_addr(struct dso *dso, Dwarf_Addr pc)
+static int check_return_addr(struct dso *dso, u64 map_start, Dwarf_Addr pc)
 {
int rc = -1;
Dwfl*dwfl;
@@ -155,6 +155,7 @@ static int check_return_addr(struct dso *dso, Dwarf_Addr pc)
Dwarf_Addr  start = pc;
Dwarf_Addr  end = pc;
boolsignalp;
+   const char  *exec_file = dso->long_name;
 
dwfl = dso->dwfl;
 
@@ -165,8 +166,10 @@ static int check_return_addr(struct dso *dso, Dwarf_Addr 
pc)
return -1;
}
 
-   if (dwfl_report_offline(dwfl, "", dso->long_name, -1) == NULL) {
-   pr_debug("dwfl_report_offline() failed %s\n",
+   mod = dwfl_report_elf(dwfl, exec_file, exec_file, -1,
+   map_start, false);
+   if (!mod) {
+   pr_debug("dwfl_report_elf() failed %s\n",
dwarf_errmsg(-1));
/*
 * We normally cache the DWARF debug info and never
@@ -256,10 +259,10 @@ int arch_skip_callchain_idx(struct thread *thread, struct 
ip_callchain *chain)
return skip_slot;
}
 
-   rc = check_return_addr(dso, ip);
+   rc = check_return_addr(dso, al.map->start, ip);
 
-   pr_debug("DSO %s, nr %" PRIx64 ", ip 0x%" PRIx64 "rc %d\n",
-   dso->long_name, chain->nr, ip, rc);
+   pr_debug("[DSO %s, sym %s, ip 0x%" PRIx64 "] rc %d\n",
+   dso->long_name, al.sym->name, ip, rc);
 
if (rc == 0) {
/*
-- 
1.8.3.1

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

Re: [RFC PATCH 0/5] Second attempt at contained helper execution

[J. Bruce Fields]

> On Wed, Jan 14, 2015 at 05:32:22PM +0800, Ian Kent wrote:
> > There are other difficulties to tackle as well, such as how to decide
> > if contained helper execution is needed. For example, if a mount has
> > been propagated to a container or bound into the container tree (such
> > as with the --volume option of "docker run") the root init namespace
> > may need to be used and not the container namespace.

I think you have to go through each of the existing upcall examples and
decide what's needed for each.

At least for the nfsv4 idmapper I would've thought the namespace the
mount was done in would be the right choice, hence my previous question.

--b.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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/2] Minimal FAPLL clock support for dm816x

[Mike Turquette]

Quoting Tony Lindgren (2015-01-13 14:51:26)
> Hi all,
> 
> Here's a minimal support for the FAPLL (Flying Adder PLL) on dm816x
> which is a omap variant.

Tony,

Patches look fine to me. I'll give it a few days for Paul or Tero to
comment if they have any concerns.

Also, "flying adder pll" is a pretty badass pll name.

Regards,
Mike

> 
> Regards,
> 
> Tony
> 
> 
> Tony Lindgren (2):
>   clk: ti: Add support for FAPLL on dm816x
>   clk: ti: Initialize clocks for dm816x
> 
>  .../devicetree/bindings/clock/ti/fapll.txt |  33 ++
>  drivers/clk/ti/Makefile|   1 +
>  drivers/clk/ti/clk-3xxx.c  |   8 +-
>  drivers/clk/ti/clk-816x.c  |  53 +++
>  drivers/clk/ti/fapll.c | 410 
> +
>  5 files changed, 498 insertions(+), 7 deletions(-)
>  create mode 100644 Documentation/devicetree/bindings/clock/ti/fapll.txt
>  create mode 100644 drivers/clk/ti/clk-816x.c
>  create mode 100644 drivers/clk/ti/fapll.c
> 
> -- 
> 2.1.4
> 
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [GIT PULL] please pull file-locking related bugfix for v3.19 (and v3.18 stable)

[Jeff Layton]

On Thu, 15 Jan 2015 10:40:25 +1300
Linus Torvalds  wrote:

> On Thu, Jan 15, 2015 at 1:46 AM, Jeff Layton  wrote:
> >
> >   git://git.samba.org/jlayton/linux.git 
> > 52d304eb4eaced9ad04b64ba7cd6ceb5153bbf18
> 
> Ugh. What are you doing?
> 
> Don't send me raw hex numbers of the commit. There's a tag there, and
> it has the name tags/locks-3.19-1, and has your signature on it and
> everything. Sending me the raw hex of the commit object misses that,
> and looks horrible too.
> 
> What kind of odd/broken script do you use?
> 
>Linus

Ugh, sorry about that. I'm not sure what happened. For some reason
git-request-pull didn't seem to notice the tag. Once I added it as the
"end" arg on the command line, it picked it up. I don't recall ever
having to do that before.

In any case, let's try that again...



The following changes since commit 971780b701946be0d6e34b4abf6eec1ab05ec0c8:

  Merge tag 'gpio-v3.19-3' of 
git://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-gpio (2015-01-13 
15:29:42 +1300)

are available in the git repository at:

  git://git.samba.org/jlayton/linux.git tags/locks-v3.19-1

for you to fetch changes up to 52d304eb4eaced9ad04b64ba7cd6ceb5153bbf18:

  locks: fix NULL-deref in generic_delete_lease (2015-01-13 07:00:55 -0500)


File-locking related bugfix for v3.19 (and v3.18-stable)

Just a simple bugfix for a regression that I introduced into v3.18 with
the internal lease API overhaul -- mea culpa. Kudos to Linda and Neil
for tracking this down and fixing it.

NeilBrown (1):
  locks: fix NULL-deref in generic_delete_lease

 fs/locks.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

-- 
Jeff Layton 
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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: [GIT PULL] qcom SoC changes for v3.18

[Andy Gross]

On Wed, Oct 15, 2014 at 10:18:30AM +0200, Kumar Gala wrote:
> 
> On Oct 1, 2014, at 4:41 PM, Arnd Bergmann  wrote:
> 
> > On Monday 22 September 2014, Kumar Gala wrote:
> >> The following changes since commit 
> >> 7d1311b93e58ed55f3a31cc8f94c4b8fe988a2b9:
> >> 
> >>  Linux 3.17-rc1 (2014-08-16 10:40:26 -0600)
> >> 
> >> are available in the git repository at:
> >> 
> >>  git://git.kernel.org/pub/scm/linux/kernel/git/galak/linux-qcom.git 
> >> tags/qcom-soc-for-3.18
> >> 
> >> for you to fetch changes up to 525fbb55947177cdae507b0d292f43c2c9a75a47:
> >> 
> >>  ARM: qcom: Move scm-boot files to drivers/soc and include/soc (2014-09-18 
> >> 18:14:01 -0500)
> >> 
> >> 
> >> Qualcomm ARM Based SoC Updates for v3.18
> >> 
> >> * Moved scm support into drivers/soc/qcom (allows for use by drivers)
> >> * Various bug fixes and minor feature additions to scm code
> >> * Added big-endian support to debug MSM uart
> > 
> > Pulled it into next/late now. This means we're not sending it together with 
> > the
> > other pull requests to Linus. We'll see how things go during the first week
> > and may or may not send it in the second week of the merge window depending
> > on that.
> > 
> > Arnd
> 
> Any update if you guys will end up sending this to linus for 3.18 or not?

Where are we on this set of changes?  Have they been queued up again?

-- 
Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project

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

Re: [RFC PATCH 0/5] Second attempt at contained helper execution

[J. Bruce Fields]

On Wed, Jan 14, 2015 at 05:32:22PM +0800, Ian Kent wrote:
> This series is a further attempt to find how (or even an acceptable
> way) to execute a usermode helper in a contained environment.
> 
> Being an attempt to find how to do this no testing has been done and
> won't be until a suitable approach can be agreed on, if at all.
> 
> >From previous discussion seperation between the caller and the
> execution environment is required for security reasons.
> 
> It was suggested that a thread be created for each mount and be used
> as the basis for the execution environment. There are a number of
> problems with this, not the least of which is scaling to a large
> numbers of mounts, and there may not be a mount corresponding the the
> needed callback

Remind me what example you're thinking of here?

--b.

> which amounts to creating the process from the context
> of the caller which we don't want to do.
> 
> But now, when a usermode helper is executed the root init namespace is
> used and has proven to be adequate. So perhaps it will also be adequate
> to use the same approach for contained execution by using the container
> init namespace as the basis for the execution.
> 
> That's essentially all this series attempts to do.
> 
> There are other difficulties to tackle as well, such as how to decide
> if contained helper execution is needed. For example, if a mount has
> been propagated to a container or bound into the container tree (such
> as with the --volume option of "docker run") the root init namespace
> may need to be used and not the container namespace.
> 
> There's also the rather resource heavy method that is used here to
> enter the target namespace which probably needs work but is out of
> scope for this series if in fact this approach is even acceptable.
> 
> Comments please?
> 
> ---
> 
> Ian Kent (5):
>   nsproxy - refactor setns()
>   kmod - rename call_usermodehelper() flags parameter
>   kmod - teach call_usermodehelper() to use a namespace
>   KEYS - rename call_usermodehelper_keys() flags parameter
>   KEYS: exec request-key within the requesting task's init namespace
> 
> 
>  include/linux/kmod.h|   21 ++-
>  include/linux/nsproxy.h |1 
>  kernel/kmod.c   |  135 
> +++
>  kernel/nsproxy.c|   21 ---
>  security/keys/request_key.c |   51 ++--
>  5 files changed, 201 insertions(+), 28 deletions(-)
> 
> --
> Ian
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] fixup! net/macb: Adding comments to various #defs to make interpretation easier

[David Miller]

From: Xander Huff 
Date: Wed, 14 Jan 2015 15:18:34 -0600

> On 1/14/2015 3:09 PM, David Miller wrote:
>>
>> As I mentioned, this won't do.
>>
>> I've already applied your original patches to net-next, therefore you
>> will
>> have to submit fixups relative to that.
>>
> These fixup commits are relative to an updated net-next, specifically
> "237de6e Merge branch 'hip04'".
> 
> Do you need them relative to (what I'm seeing is the latest) "2733135
> Merge branch 'vxlan_rco'"?

Why don't you make your subject lines and commit messages just say what
they are doing, rather than just saying "fix this other change"?
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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/11] x86: entry_64.S: rename save_paranoid to paranoid_entry, no code changes

[Denys Vlasenko]

This patch does a lot of cleanup in comments and formatting,
but it does not change any code.

Rename save_paranoid to paranoid_entry: this makes naming
similar to its "non-paranoid" sibling, error_entry,
and to its counterpart, paranoid_exit.

Use the same CFI annotation atop paranoid_entry and error_entry.

Fix irregular indentation of assembler operands.

Add/fix comments on top of paranoid_entry and error_entry.
Remove stale comment about "oldrax".
Make comments about "no swapgs" flag in ebx more prominent.
Deindent wrongly indented top-level comment atop paranoid_exit.
Indent wrongly deindented comment inside error_entry.

Signed-off-by: Denys Vlasenko 
CC: Linus Torvalds 
CC: Oleg Nesterov 
CC: Borislav Petkov 
CC: "H. Peter Anvin" 
CC: Andy Lutomirski 
CC: Frederic Weisbecker 
CC: X86 ML 
CC: Alexei Starovoitov 
CC: Will Drewry 
CC: Kees Cook 
CC: linux-kernel@vger.kernel.org
---
 arch/x86/kernel/entry_64.S | 104 +++--
 1 file changed, 54 insertions(+), 50 deletions(-)

diff --git a/arch/x86/kernel/entry_64.S b/arch/x86/kernel/entry_64.S
index d72e46e..aacfa2c 100644
--- a/arch/x86/kernel/entry_64.S
+++ b/arch/x86/kernel/entry_64.S
@@ -968,10 +968,11 @@ ENTRY(\sym)
testl $3, CS(%rsp)  /* If coming from userspace, switch */
jnz 1f  /* stacks. */
.endif
-   call save_paranoid
+   call paranoid_entry
.else
call error_entry
.endif
+   /* returned flag: ebx=0: need swapgs on exit, ebx=1: don't need it */
 
DEFAULT_FRAME 0
 
@@ -1002,10 +1003,11 @@ ENTRY(\sym)
addq $EXCEPTION_STKSZ, INIT_TSS_IST(\shift_ist)
.endif
 
+   /* these procedures expect "no swapgs" flag in ebx */
.if \paranoid
-   jmp paranoid_exit   /* %ebx: no swapgs flag */
+   jmp paranoid_exit
.else
-   jmp error_exit  /* %ebx: no swapgs flag */
+   jmp error_exit
.endif
 
.if \paranoid == 1
@@ -1240,8 +1242,13 @@ idtentry async_page_fault do_async_page_fault 
has_error_code=1
 idtentry machine_check has_error_code=0 paranoid=1 
do_sym=*machine_check_vector(%rip)
 #endif
 
-ENTRY(save_paranoid)
-   XCPT_FRAME 1 RDI+8
+/*
+ * Save all registers in pt_regs, and switch gs if needed.
+ * Use slow, but surefire "are we in kernel?" check.
+ * Return: ebx=0: need swapgs on exit, ebx=1: otherwise
+ */
+ENTRY(paranoid_entry)
+   XCPT_FRAME 1 15*8
cld
SAVE_C_REGS 8
SAVE_EXTRA_REGS 8
@@ -1254,20 +1261,19 @@ ENTRY(save_paranoid)
xorl %ebx,%ebx
 1: ret
CFI_ENDPROC
-END(save_paranoid)
+END(paranoid_entry)
 
-   /*
-* "Paranoid" exit path from exception stack.  This is invoked
-* only on return from non-NMI IST interrupts that came
-* from kernel space.
-*
-* We may be returning to very strange contexts (e.g. very early
-* in syscall entry), so checking for preemption here would
-* be complicated.  Fortunately, we there's no good reason
-* to try to handle preemption here.
-*/
-
-   /* ebx: no swapgs flag */
+/*
+ * "Paranoid" exit path from exception stack.  This is invoked
+ * only on return from non-NMI IST interrupts that came
+ * from kernel space.
+ *
+ * We may be returning to very strange contexts (e.g. very early
+ * in syscall entry), so checking for preemption here would
+ * be complicated.  Fortunately, we there's no good reason
+ * to try to handle preemption here.
+ */
+/* On entry, ebx is "no swapgs" flag (1: don't need swapgs, 0: need it) */
 ENTRY(paranoid_exit)
DEFAULT_FRAME
DISABLE_INTERRUPTS(CLBR_NONE)
@@ -1288,18 +1294,16 @@ paranoid_restore1:
 END(paranoid_exit)
 
 /*
- * Exception entry point. This expects an error code/orig_rax on the stack.
- * returns in "no swapgs flag" in %ebx.
+ * Save all registers in pt_regs, and switch gs if needed.
+ * Return: ebx=0: need swapgs on exit, ebx=1: otherwise
  */
 ENTRY(error_entry)
-   XCPT_FRAME
-   CFI_ADJUST_CFA_OFFSET 15*8
-   /* oldrax contains error code */
+   XCPT_FRAME 1 15*8
cld
SAVE_C_REGS 8
SAVE_EXTRA_REGS 8
-   xorl %ebx,%ebx
-   testl $3,CS+8(%rsp)
+   xorl%ebx,%ebx
+   testl   $3,CS+8(%rsp)
je error_kernelspace
 error_swapgs:
SWAPGS
@@ -1307,42 +1311,42 @@ error_sti:
TRACE_IRQS_OFF
ret
 
-/*
- * There are two places in the kernel that can potentially fault with
- * usergs. Handle them here.  B stepping K8s sometimes report a
- * truncated RIP for IRET exceptions returning to compat mode. Check
- * for these here too.
- */
+   /*
+* There are two places in the kernel that can potentially fault with
+* usergs. Handle them here.  B stepping K8s sometimes report a
+* truncated RIP for IRET exceptions returning to compat mode. Check
+* for these here too.
+*/
 error_ke

Re: [PATCH] nfsd: nfs4state: Remove unused function

[J. Bruce Fields]

On Tue, Jan 13, 2015 at 09:57:24PM +0100, Rickard Strandqvist wrote:
> Remove the function renew_client() that is not used anywhere.
> 
> This was partially found by using a static code analysis program called 
> cppcheck.

Huh.  OK, queueing up for 3.20.--b.

> 
> Signed-off-by: Rickard Strandqvist 
> ---
>  fs/nfsd/nfs4state.c |   10 --
>  1 file changed, 10 deletions(-)
> 
> diff --git a/fs/nfsd/nfs4state.c b/fs/nfsd/nfs4state.c
> index e9c3afe..5d63c5c 100644
> --- a/fs/nfsd/nfs4state.c
> +++ b/fs/nfsd/nfs4state.c
> @@ -150,16 +150,6 @@ renew_client_locked(struct nfs4_client *clp)
>   clp->cl_time = get_seconds();
>  }
>  
> -static inline void
> -renew_client(struct nfs4_client *clp)
> -{
> - struct nfsd_net *nn = net_generic(clp->net, nfsd_net_id);
> -
> - spin_lock(&nn->client_lock);
> - renew_client_locked(clp);
> - spin_unlock(&nn->client_lock);
> -}
> -
>  static void put_client_renew_locked(struct nfs4_client *clp)
>  {
>   struct nfsd_net *nn = net_generic(clp->net, nfsd_net_id);
> -- 
> 1.7.10.4
> 
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH 06/11] x86: entry_64.S: move save_paranoid and ret_from_fork closer to their users

[Denys Vlasenko]

For some odd reason, these two functions are at the very top of the file.
save_paranoid's caller is approximately in the middle of it, move it there.
Move ret_from_fork to be right after fork/exec helpers.

Signed-off-by: Denys Vlasenko 
CC: Linus Torvalds 
CC: Oleg Nesterov 
CC: Borislav Petkov 
CC: "H. Peter Anvin" 
CC: Andy Lutomirski 
CC: Frederic Weisbecker 
CC: X86 ML 
CC: Alexei Starovoitov 
CC: Will Drewry 
CC: Kees Cook 
CC: linux-kernel@vger.kernel.org
---
 arch/x86/kernel/entry_64.S | 106 ++---
 1 file changed, 53 insertions(+), 53 deletions(-)

diff --git a/arch/x86/kernel/entry_64.S b/arch/x86/kernel/entry_64.S
index 3498274..d72e46e 100644
--- a/arch/x86/kernel/entry_64.S
+++ b/arch/x86/kernel/entry_64.S
@@ -201,59 +201,6 @@ ENDPROC(native_usergs_sysret64)
CFI_REL_OFFSET r15, R15+\offset
.endm
 
-ENTRY(save_paranoid)
-   XCPT_FRAME 1 RDI+8
-   cld
-   SAVE_C_REGS 8
-   SAVE_EXTRA_REGS 8
-   movl $1,%ebx
-   movl $MSR_GS_BASE,%ecx
-   rdmsr
-   testl %edx,%edx
-   js 1f   /* negative -> in kernel */
-   SWAPGS
-   xorl %ebx,%ebx
-1: ret
-   CFI_ENDPROC
-END(save_paranoid)
-
-/*
- * A newly forked process directly context switches into this address.
- *
- * rdi: prev task we switched from
- */
-ENTRY(ret_from_fork)
-   DEFAULT_FRAME
-
-   LOCK ; btr $TIF_FORK,TI_flags(%r8)
-
-   pushq_cfi $0x0002
-   popfq_cfi   # reset kernel eflags
-
-   call schedule_tail  # rdi: 'prev' task parameter
-
-   GET_THREAD_INFO(%rcx)
-
-   RESTORE_EXTRA_REGS
-
-   testl $3, CS(%rsp)  # from kernel_thread?
-   jz   1f
-
-   testl $_TIF_IA32, TI_flags(%rcx)# 32-bit compat task needs IRET
-   jnz  int_ret_from_sys_call
-
-   RESTORE_TOP_OF_STACK %rdi
-   jmp ret_from_sys_call   # go to the SYSRET fastpath
-
-1:
-   movq %rbp, %rdi
-   call *%rbx
-   movl $0, RAX(%rsp)
-   RESTORE_EXTRA_REGS
-   jmp int_ret_from_sys_call
-   CFI_ENDPROC
-END(ret_from_fork)
-
 /*
  * 64bit SYSCALL instruction entry. Up to 6 arguments in registers.
  *
@@ -623,6 +570,43 @@ END(stub_x32_execveat)
 #endif
 
 /*
+ * A newly forked process directly context switches into this address.
+ *
+ * rdi: prev task we switched from
+ */
+ENTRY(ret_from_fork)
+   DEFAULT_FRAME
+
+   LOCK ; btr $TIF_FORK,TI_flags(%r8)
+
+   pushq_cfi $0x0002
+   popfq_cfi   # reset kernel eflags
+
+   call schedule_tail  # rdi: 'prev' task parameter
+
+   GET_THREAD_INFO(%rcx)
+
+   RESTORE_EXTRA_REGS
+
+   testl $3, CS(%rsp)  # from kernel_thread?
+   jz   1f
+
+   testl $_TIF_IA32, TI_flags(%rcx)# 32-bit compat task needs IRET
+   jnz  int_ret_from_sys_call
+
+   RESTORE_TOP_OF_STACK %rdi
+   jmp ret_from_sys_call   # go to the SYSRET fastpath
+
+1:
+   movq %rbp, %rdi
+   call *%rbx
+   movl $0, RAX(%rsp)
+   RESTORE_EXTRA_REGS
+   jmp int_ret_from_sys_call
+   CFI_ENDPROC
+END(ret_from_fork)
+
+/*
  * Build the entry stubs and pointer table with some assembler magic.
  * We pack 7 stubs into a single 32-byte chunk, which will fit in a
  * single cache line on all modern x86 implementations.
@@ -1256,6 +1240,22 @@ idtentry async_page_fault do_async_page_fault 
has_error_code=1
 idtentry machine_check has_error_code=0 paranoid=1 
do_sym=*machine_check_vector(%rip)
 #endif
 
+ENTRY(save_paranoid)
+   XCPT_FRAME 1 RDI+8
+   cld
+   SAVE_C_REGS 8
+   SAVE_EXTRA_REGS 8
+   movl $1,%ebx
+   movl $MSR_GS_BASE,%ecx
+   rdmsr
+   testl %edx,%edx
+   js 1f   /* negative -> in kernel */
+   SWAPGS
+   xorl %ebx,%ebx
+1: ret
+   CFI_ENDPROC
+END(save_paranoid)
+
/*
 * "Paranoid" exit path from exception stack.  This is invoked
 * only on return from non-NMI IST interrupts that came
-- 
1.8.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/11] x86: get rid of KERNEL_STACK_OFFSET

[Denys Vlasenko]

PER_CPU_VAR(kernel_stack) was set up in a way where it points
five stack slots below the top of stack.

Presumably, it was done to avoid one "sub $5*8,%rsp"
in syscall/sysenter code paths, where iret frame needs to be
created by hand.

Ironically, none of them benefit from this optimization,
since all of them need to allocate additional data on stack
(struct pt_regs), so they still have to perform subtraction.
And ia32_sysenter_target even needs to *undo* this optimization:
it constructs iret stack with pushes instead of movs,
so it needs to start right at the top.

This patch eliminates KERNEL_STACK_OFFSET.
PER_CPU_VAR(kernel_stack) now points directly to top of stack.
pt_regs allocations are adjusted to allocate iret frame as well.

Semi-mysterious expressions THREAD_INFO(%rsp,RIP) - "why RIP??"
are now replaced by more logical THREAD_INFO(%rsp,SIZEOF_PTREGS) -
"rsp is SIZEOF_PTREGS bytes below the top, calculate
thread_info's address using that information"

Net result in code is that one instruction is eliminated,
and constants in several others have changed.

Signed-off-by: Denys Vlasenko 
CC: Linus Torvalds 
CC: Oleg Nesterov 
CC: Borislav Petkov 
CC: "H. Peter Anvin" 
CC: Andy Lutomirski 
CC: Frederic Weisbecker 
CC: X86 ML 
CC: Alexei Starovoitov 
CC: Will Drewry 
CC: Kees Cook 
CC: linux-kernel@vger.kernel.org
---
 arch/x86/ia32/ia32entry.S  | 35 +--
 arch/x86/include/asm/calling.h |  2 ++
 arch/x86/include/asm/thread_info.h |  8 +++-
 arch/x86/kernel/cpu/common.c   |  2 +-
 arch/x86/kernel/entry_64.S |  9 -
 arch/x86/kernel/process_32.c   |  3 +--
 arch/x86/kernel/process_64.c   |  3 +--
 arch/x86/kernel/smpboot.c  |  3 +--
 arch/x86/xen/smp.c |  3 +--
 9 files changed, 31 insertions(+), 37 deletions(-)

diff --git a/arch/x86/ia32/ia32entry.S b/arch/x86/ia32/ia32entry.S
index 366f633..ed58fe1 100644
--- a/arch/x86/ia32/ia32entry.S
+++ b/arch/x86/ia32/ia32entry.S
@@ -125,7 +125,6 @@ ENTRY(ia32_sysenter_target)
CFI_REGISTERrsp,rbp
SWAPGS_UNSAFE_STACK
movqPER_CPU_VAR(kernel_stack), %rsp
-   addq$(KERNEL_STACK_OFFSET),%rsp
/*
 * No need to follow this irqs on/off section: the syscall
 * disabled irqs, here we enable it straight after entry:
@@ -139,7 +138,7 @@ ENTRY(ia32_sysenter_target)
CFI_REL_OFFSET rsp,0
pushfq_cfi
/*CFI_REL_OFFSET rflags,0*/
-   movl
TI_sysenter_return+THREAD_INFO(%rsp,3*8-KERNEL_STACK_OFFSET),%r10d
+   movlTI_sysenter_return+THREAD_INFO(%rsp,3*8),%r10d
CFI_REGISTER rip,r10
pushq_cfi $__USER32_CS
/*CFI_REL_OFFSET cs,0*/
@@ -171,8 +170,8 @@ ENTRY(ia32_sysenter_target)
jnz sysenter_fix_flags
 sysenter_flags_fixed:
 
-   orl $TS_COMPAT,TI_status+THREAD_INFO(%rsp,RIP)
-   testl   $_TIF_WORK_SYSCALL_ENTRY,TI_flags+THREAD_INFO(%rsp,RIP)
+   orl $TS_COMPAT,TI_status+THREAD_INFO(%rsp,SIZEOF_PTREGS)
+   testl   
$_TIF_WORK_SYSCALL_ENTRY,TI_flags+THREAD_INFO(%rsp,SIZEOF_PTREGS)
CFI_REMEMBER_STATE
jnz  sysenter_tracesys
cmpq$(IA32_NR_syscalls-1),%rax
@@ -184,10 +183,10 @@ sysenter_dispatch:
movq%rax,RAX(%rsp)
DISABLE_INTERRUPTS(CLBR_NONE)
TRACE_IRQS_OFF
-   testl   $_TIF_ALLWORK_MASK,TI_flags+THREAD_INFO(%rsp,RIP)
+   testl   $_TIF_ALLWORK_MASK,TI_flags+THREAD_INFO(%rsp,SIZEOF_PTREGS)
jnz sysexit_audit
 sysexit_from_sys_call:
-   andl$~TS_COMPAT,TI_status+THREAD_INFO(%rsp,RIP)
+   andl$~TS_COMPAT,TI_status+THREAD_INFO(%rsp,SIZEOF_PTREGS)
/* clear IF, that popfq doesn't enable interrupts early */
andl$~0x200,EFLAGS(%rsp)
movlRIP(%rsp),%edx  /* User %eip */
@@ -232,7 +231,7 @@ sysexit_from_sys_call:
.endm
 
.macro auditsys_exit exit
-   testl $(_TIF_ALLWORK_MASK & 
~_TIF_SYSCALL_AUDIT),TI_flags+THREAD_INFO(%rsp,RIP)
+   testl $(_TIF_ALLWORK_MASK & 
~_TIF_SYSCALL_AUDIT),TI_flags+THREAD_INFO(%rsp,SIZEOF_PTREGS)
jnz ia32_ret_from_sys_call
TRACE_IRQS_ON
ENABLE_INTERRUPTS(CLBR_NONE)
@@ -247,7 +246,7 @@ sysexit_from_sys_call:
movl $(_TIF_ALLWORK_MASK & ~_TIF_SYSCALL_AUDIT),%edi
DISABLE_INTERRUPTS(CLBR_NONE)
TRACE_IRQS_OFF
-   testl %edi,TI_flags+THREAD_INFO(%rsp,RIP)
+   testl %edi,TI_flags+THREAD_INFO(%rsp,SIZEOF_PTREGS)
jz \exit
CLEAR_RREGS
jmp int_with_check
@@ -269,7 +268,7 @@ sysenter_fix_flags:
 
 sysenter_tracesys:
 #ifdef CONFIG_AUDITSYSCALL
-   testl   $(_TIF_WORK_SYSCALL_ENTRY & 
~_TIF_SYSCALL_AUDIT),TI_flags+THREAD_INFO(%rsp,RIP)
+   testl   $(_TIF_WORK_SYSCALL_ENTRY & 
~_TIF_SYSCALL_AUDIT),TI_flags+THREAD_INFO(%rsp,SIZEOF_PTREGS)
jz  sysenter_auditsys
 #endif
SAVE_EXTRA_REGS
@@ -318,7 +317,7 @@ ENDPROC(ia32_sysenter_target)
 ENTRY(ia32_cstar_target)
CFI_STARTPROC3

[PATCH 10/11] x86: ia32entry.S: fold IA32_ARG_FIXUP macro into its callers

[Denys Vlasenko]

Use of a small macro - one with conditional expansion - does more harm
than good. It obfuscates code, with minimal code reuse.

For example, because of obfuscation it's not obvious that
in ia32_sysenter_target, we can optimize loading of r9 -
currently it is loaded with a detour through ebp.

This patch folds IA32_ARG_FIXUP macro into its callers.

No code changes.

Signed-off-by: Denys Vlasenko 
CC: Linus Torvalds 
CC: Oleg Nesterov 
CC: Borislav Petkov 
CC: "H. Peter Anvin" 
CC: Andy Lutomirski 
CC: Frederic Weisbecker 
CC: X86 ML 
CC: Alexei Starovoitov 
CC: Will Drewry 
CC: Kees Cook 
CC: linux-kernel@vger.kernel.org
---
 arch/x86/ia32/ia32entry.S | 32 ++--
 1 file changed, 18 insertions(+), 14 deletions(-)

diff --git a/arch/x86/ia32/ia32entry.S b/arch/x86/ia32/ia32entry.S
index ed58fe1..55b785c 100644
--- a/arch/x86/ia32/ia32entry.S
+++ b/arch/x86/ia32/ia32entry.S
@@ -30,17 +30,6 @@
 
.section .entry.text, "ax"
 
-   .macro IA32_ARG_FIXUP noebp=0
-   movl%edi,%r8d
-   .if \noebp
-   .else
-   movl%ebp,%r9d
-   .endif
-   xchg%ecx,%esi
-   movl%ebx,%edi
-   movl%edx,%edx   /* zero extension */
-   .endm 
-
/* clobbers %rax */
.macro  CLEAR_RREGS _r9=rax
xorl%eax,%eax
@@ -177,7 +166,12 @@ sysenter_flags_fixed:
cmpq$(IA32_NR_syscalls-1),%rax
ja  ia32_badsys
 sysenter_do_call:
-   IA32_ARG_FIXUP
+   /* 32bit syscall -> 64bit C ABI argument conversion */
+   movl%edi,%r8d   /* arg5 */
+   movl%ebp,%r9d   /* arg6 */
+   xchg%ecx,%esi   /* rsi:arg2, rcx:arg4 */
+   movl%ebx,%edi   /* arg1 */
+   movl%edx,%edx   /* arg3 (zero extension) */
 sysenter_dispatch:
call*ia32_sys_call_table(,%rax,8)
movq%rax,RAX(%rsp)
@@ -359,7 +353,12 @@ ENTRY(ia32_cstar_target)
cmpq $IA32_NR_syscalls-1,%rax
ja  ia32_badsys
 cstar_do_call:
-   IA32_ARG_FIXUP 1
+   /* 32bit syscall -> 64bit C ABI argument conversion */
+   movl%edi,%r8d   /* arg5 */
+   /* r9 already loaded */ /* arg6 */
+   xchg%ecx,%esi   /* rsi:arg2, rcx:arg4 */
+   movl%ebx,%edi   /* arg1 */
+   movl%edx,%edx   /* arg3 (zero extension) */
 cstar_dispatch:
call *ia32_sys_call_table(,%rax,8)
movq %rax,RAX(%rsp)
@@ -476,7 +475,12 @@ ENTRY(ia32_syscall)
cmpq $(IA32_NR_syscalls-1),%rax
ja ia32_badsys
 ia32_do_call:
-   IA32_ARG_FIXUP
+   /* 32bit syscall -> 64bit C ABI argument conversion */
+   movl %edi,%r8d  /* arg5 */
+   movl %ebp,%r9d  /* arg6 */
+   xchg %ecx,%esi  /* rsi:arg2, rcx:arg4 */
+   movl %ebx,%edi  /* arg1 */
+   movl %edx,%edx  /* arg3 (zero extension) */
call *ia32_sys_call_table(,%rax,8) # xxx: rip relative
 ia32_sysret:
movq %rax,RAX(%rsp)
-- 
1.8.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/11] x86: entry_64.S: use more understandable constants

[Denys Vlasenko]

Constants such as SS+8 or SS+8-RIP are mysterious.
In most cases, SS+8 is just meant to be SIZEOF_PTREGS,
SS+8-RIP is RIP's offset in iret frame.

This patch changes some of these constants to be less mysterious.
No code changes (verified with objdump).

Signed-off-by: Denys Vlasenko 
CC: Linus Torvalds 
CC: Oleg Nesterov 
CC: Borislav Petkov 
CC: "H. Peter Anvin" 
CC: Andy Lutomirski 
CC: Frederic Weisbecker 
CC: X86 ML 
CC: Alexei Starovoitov 
CC: Will Drewry 
CC: Kees Cook 
CC: linux-kernel@vger.kernel.org
---
 arch/x86/kernel/entry_64.S | 28 
 1 file changed, 16 insertions(+), 12 deletions(-)

diff --git a/arch/x86/kernel/entry_64.S b/arch/x86/kernel/entry_64.S
index 279af0e..d84c7c7 100644
--- a/arch/x86/kernel/entry_64.S
+++ b/arch/x86/kernel/entry_64.S
@@ -163,12 +163,12 @@ ENDPROC(native_usergs_sysret64)
  * initial frame state for interrupts (and exceptions without error code)
  */
.macro INTR_FRAME start=1 offset=0
-   EMPTY_FRAME \start, SS+8+\offset-RIP
-   /*CFI_REL_OFFSET ss, SS+\offset-RIP*/
-   CFI_REL_OFFSET rsp, RSP+\offset-RIP
-   /*CFI_REL_OFFSET rflags, EFLAGS+\offset-RIP*/
-   /*CFI_REL_OFFSET cs, CS+\offset-RIP*/
-   CFI_REL_OFFSET rip, RIP+\offset-RIP
+   EMPTY_FRAME \start, 5*8+\offset
+   /*CFI_REL_OFFSET ss, 4*8+\offset*/
+   CFI_REL_OFFSET rsp, 3*8+\offset
+   /*CFI_REL_OFFSET rflags, 2*8+\offset*/
+   /*CFI_REL_OFFSET cs, 1*8+\offset*/
+   CFI_REL_OFFSET rip, 0*8+\offset
.endm
 
 /*
@@ -176,7 +176,7 @@ ENDPROC(native_usergs_sysret64)
  * with vector already pushed)
  */
.macro XCPT_FRAME start=1 offset=0
-   INTR_FRAME \start, RIP+\offset-ORIG_RAX
+   INTR_FRAME \start, 1*8+\offset
.endm
 
 /*
@@ -685,10 +685,14 @@ END(interrupt)
cmovzq PER_CPU_VAR(irq_stack_ptr),%rsp
CFI_DEF_CFA_REGISTERrsi
pushq %rsi
+   /*
+* For debugger:
+* "CFA (Current Frame Address) is the value on stack + offset"
+*/
CFI_ESCAPE  0x0f /* DW_CFA_def_cfa_expression */, 6, \
-   0x77 /* DW_OP_breg7 */, 0, \
+   0x77 /* DW_OP_breg7 (rsp) */, 0, \
0x06 /* DW_OP_deref */, \
-   0x08 /* DW_OP_const1u */, SS+8-RBP, \
+   0x08 /* DW_OP_const1u */, SIZEOF_PTREGS-RBP, \
0x22 /* DW_OP_plus */
/* We entered an interrupt context - irqs are off: */
TRACE_IRQS_OFF
@@ -714,7 +718,7 @@ ret_from_intr:
 
/* Restore saved previous stack */
popq %rsi
-   CFI_DEF_CFA rsi,SS+8-RBP/* reg/off reset after def_cfa_expr */
+   CFI_DEF_CFA rsi,SIZEOF_PTREGS-RBP /* reg/off reset after def_cfa_expr */
/* return code expects complete pt_regs - adjust rsp accordingly: */
leaq -RBP(%rsi), %rsp
CFI_DEF_CFA_REGISTERrsp
@@ -1525,7 +1529,7 @@ first_nmi:
.rept 5
pushq_cfi 11*8(%rsp)
.endr
-   CFI_DEF_CFA_OFFSET SS+8-RIP
+   CFI_DEF_CFA_OFFSET 5*8
 
/* Everything up to here is safe from nested NMIs */
 
@@ -1553,7 +1557,7 @@ repeat_nmi:
pushq_cfi -6*8(%rsp)
.endr
subq $(5*8), %rsp
-   CFI_DEF_CFA_OFFSET SS+8-RIP
+   CFI_DEF_CFA_OFFSET 5*8
 end_repeat_nmi:
 
/*
-- 
1.8.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 05/11] x86: add comments about various syscall instructions, no code changes

[Denys Vlasenko]

SYSCALL/SYSRET and SYSENTER/SYSEXIT have weird semantics.
Moreover, they differ in 32- and 64-bit mode.
What is saved? What is not? Is rsp set? Are interrupts disabled?
People tend to not remember these details well enough.

This patch adds comments which explain in detail
what registers are modified by each of these instructions.
The comments are placed immediately before corresponding
entry and exit points.

Signed-off-by: Denys Vlasenko 
CC: Linus Torvalds 
CC: Oleg Nesterov 
CC: Borislav Petkov 
CC: "H. Peter Anvin" 
CC: Andy Lutomirski 
CC: Frederic Weisbecker 
CC: X86 ML 
CC: Alexei Starovoitov 
CC: Will Drewry 
CC: Kees Cook 
CC: linux-kernel@vger.kernel.org
---
 arch/x86/ia32/ia32entry.S  | 133 -
 arch/x86/kernel/entry_64.S |  32 ++-
 2 files changed, 102 insertions(+), 63 deletions(-)

diff --git a/arch/x86/ia32/ia32entry.S b/arch/x86/ia32/ia32entry.S
index 9f4c877..366f633 100644
--- a/arch/x86/ia32/ia32entry.S
+++ b/arch/x86/ia32/ia32entry.S
@@ -99,22 +99,25 @@ ENDPROC(native_irq_enable_sysexit)
 /*
  * 32bit SYSENTER instruction entry.
  *
+ * SYSENTER loads ss, rsp, cs, and rip from previously programmed MSRs.
+ * IF and VM in rflags are cleared (IOW: interrupts are off).
+ * SYSENTER does not save anything on the stack,
+ * and does not save old rip (!!!) and rflags.
+ *
  * Arguments:
- * %eaxSystem call number.
- * %ebx Arg1
- * %ecx Arg2
- * %edx Arg3
- * %esi Arg4
- * %edi Arg5
- * %ebp user stack
- * 0(%ebp) Arg6
- * 
- * Interrupts off.
- * 
+ * eax  system call number
+ * ebx  arg1
+ * ecx  arg2
+ * edx  arg3
+ * esi  arg4
+ * edi  arg5
+ * ebp  user stack
+ * 0(%ebp) arg6
+ *
  * This is purely a fast path. For anything complicated we use the int 0x80
- * path below. Set up a complete hardware stack frame to share code
+ * path below. We set up a complete hardware stack frame to share code
  * with the int 0x80 path.
- */
+ */
 ENTRY(ia32_sysenter_target)
CFI_STARTPROC32 simple
CFI_SIGNAL_FRAME
@@ -128,6 +131,7 @@ ENTRY(ia32_sysenter_target)
 * disabled irqs, here we enable it straight after entry:
 */
ENABLE_INTERRUPTS(CLBR_NONE)
+   /* Construct iret frame (ss,rsp,rflags,cs,rip) */
movl%ebp,%ebp   /* zero extension */
pushq_cfi $__USER32_DS
/*CFI_REL_OFFSET ss,0*/
@@ -140,14 +144,19 @@ ENTRY(ia32_sysenter_target)
pushq_cfi $__USER32_CS
/*CFI_REL_OFFSET cs,0*/
movl%eax, %eax
+   /* Store thread_info->sysenter_return in rip stack slot */
pushq_cfi %r10
CFI_REL_OFFSET rip,0
+   /* Store orig_ax */
pushq_cfi %rax
+   /* Construct the rest of "struct pt_regs" */
cld
ALLOC_PT_GPREGS_ON_STACK
SAVE_C_REGS_EXCEPT_R891011
-   /* no need to do an access_ok check here because rbp has been
-  32bit zero extended */ 
+   /*
+* no need to do an access_ok check here because rbp has been
+* 32bit zero extended
+*/
ASM_STAC
 1: movl(%rbp),%ebp
_ASM_EXTABLE(1b,ia32_badarg)
@@ -184,6 +193,7 @@ sysexit_from_sys_call:
movlRIP(%rsp),%edx  /* User %eip */
CFI_REGISTER rip,rdx
RESTORE_RSI_RDI
+   /* pop everything except ss,rsp,rflags slots */
REMOVE_PT_GPREGS_FROM_STACK 3*8
xorq%r8,%r8
xorq%r9,%r9
@@ -194,6 +204,10 @@ sysexit_from_sys_call:
popq_cfi %rcx   /* User %esp */
CFI_REGISTER rsp,rcx
TRACE_IRQS_ON
+   /*
+* 32bit SYSEXIT restores eip from edx, esp from ecx.
+* cs and ss are loaded from MSRs.
+*/
ENABLE_INTERRUPTS_SYSEXIT32
 
CFI_RESTORE_STATE
@@ -274,23 +288,33 @@ ENDPROC(ia32_sysenter_target)
 /*
  * 32bit SYSCALL instruction entry.
  *
+ * 32bit SYSCALL saves rip to rcx, clears rflags.RF, then saves rflags to r11,
+ * then loads new ss, cs, and rip from previously programmed MSRs.
+ * rflags gets masked by a value from another MSR (so CLD and CLAC
+ * are not needed). SYSCALL does not save anything on the stack
+ * and does not change rsp.
+ *
+ * Note: rflags saving+masking-with-MSR happens only in Long mode
+ * (in legacy 32bit mode, IF, RF and VM bits are cleared and that's it).
+ * Don't get confused: rflags saving+masking depends on Long Mode Active bit
+ * (EFER.LMA=1), NOT on bitness of userspace where SYSCALL executes
+ * or target CS descriptor's L bit (SYSCALL does not read segment descriptors).
+ *
  * Arguments:
- * %eaxSystem call number.
- * %ebx Arg1
- * %ecx return EIP 
- * %edx Arg3
- * %esi Arg4
- * %edi Arg5
- * %ebp Arg2[note: not saved in the stack frame, should not be touched]
- * %esp user stack 
- * 0(%esp) Arg6
- * 
- * Interrupts off.
- * 
+ * eax  system call number
+ * ecx  return address
+ * ebx  arg1
+ * ebp  arg2   (note: not saved in the stack frame, should not be touched)

[PATCH 03/11] x86: mass removal of ARGOFFSET

[Denys Vlasenko]

ARGOFFSET is zero now, removing it changes no code.
A few macros lost "offset" parameter, since it is always zero now too.

Signed-off-by: Denys Vlasenko 
CC: Linus Torvalds 
CC: Oleg Nesterov 
CC: Borislav Petkov 
CC: "H. Peter Anvin" 
CC: Andy Lutomirski 
CC: Frederic Weisbecker 
CC: X86 ML 
CC: Alexei Starovoitov 
CC: Will Drewry 
CC: Kees Cook 
CC: linux-kernel@vger.kernel.org
---
 arch/x86/ia32/ia32entry.S  | 142 -
 arch/x86/include/asm/calling.h |   2 -
 arch/x86/kernel/entry_64.S |  64 +--
 3 files changed, 103 insertions(+), 105 deletions(-)

diff --git a/arch/x86/ia32/ia32entry.S b/arch/x86/ia32/ia32entry.S
index f4bed49..e99f8a5 100644
--- a/arch/x86/ia32/ia32entry.S
+++ b/arch/x86/ia32/ia32entry.S
@@ -41,13 +41,13 @@
movl%edx,%edx   /* zero extension */
.endm 
 
-   /* clobbers %eax */ 
-   .macro  CLEAR_RREGS offset=0, _r9=rax
+   /* clobbers %rax */
+   .macro  CLEAR_RREGS _r9=rax
xorl%eax,%eax
-   movq%rax,\offset+R11(%rsp)
-   movq%rax,\offset+R10(%rsp)
-   movq%\_r9,\offset+R9(%rsp)
-   movq%rax,\offset+R8(%rsp)
+   movq%rax,R11(%rsp)
+   movq%rax,R10(%rsp)
+   movq%\_r9,R9(%rsp)
+   movq%rax,R8(%rsp)
.endm
 
/*
@@ -60,14 +60,14 @@
 * If it's -1 to make us punt the syscall, then (u32)-1 is still
 * an appropriately invalid value.
 */
-   .macro LOAD_ARGS32 offset, _r9=0
+   .macro LOAD_ARGS32 _r9=0
.if \_r9
-   movl \offset+R9(%rsp),%r9d
+   movl R9(%rsp),%r9d
.endif
-   movl \offset+RCX(%rsp),%ecx
-   movl \offset+RDX(%rsp),%edx
-   movl \offset+RSI(%rsp),%esi
-   movl \offset+RDI(%rsp),%edi
+   movl RCX(%rsp),%ecx
+   movl RDX(%rsp),%edx
+   movl RSI(%rsp),%esi
+   movl RDI(%rsp),%edi
movl %eax,%eax  /* zero extension */
.endm

@@ -158,12 +158,12 @@ ENTRY(ia32_sysenter_target)
 * ourselves.  To save a few cycles, we can check whether
 * NT was set instead of doing an unconditional popfq.
 */
-   testl $X86_EFLAGS_NT,EFLAGS-ARGOFFSET(%rsp)
+   testl $X86_EFLAGS_NT,EFLAGS(%rsp)
jnz sysenter_fix_flags
 sysenter_flags_fixed:
 
-   orl $TS_COMPAT,TI_status+THREAD_INFO(%rsp,RIP-ARGOFFSET)
-   testl   
$_TIF_WORK_SYSCALL_ENTRY,TI_flags+THREAD_INFO(%rsp,RIP-ARGOFFSET)
+   orl $TS_COMPAT,TI_status+THREAD_INFO(%rsp,RIP)
+   testl   $_TIF_WORK_SYSCALL_ENTRY,TI_flags+THREAD_INFO(%rsp,RIP)
CFI_REMEMBER_STATE
jnz  sysenter_tracesys
cmpq$(IA32_NR_syscalls-1),%rax
@@ -172,16 +172,16 @@ sysenter_do_call:
IA32_ARG_FIXUP
 sysenter_dispatch:
call*ia32_sys_call_table(,%rax,8)
-   movq%rax,RAX-ARGOFFSET(%rsp)
+   movq%rax,RAX(%rsp)
DISABLE_INTERRUPTS(CLBR_NONE)
TRACE_IRQS_OFF
-   testl   $_TIF_ALLWORK_MASK,TI_flags+THREAD_INFO(%rsp,RIP-ARGOFFSET)
+   testl   $_TIF_ALLWORK_MASK,TI_flags+THREAD_INFO(%rsp,RIP)
jnz sysexit_audit
 sysexit_from_sys_call:
-   andl$~TS_COMPAT,TI_status+THREAD_INFO(%rsp,RIP-ARGOFFSET)
+   andl$~TS_COMPAT,TI_status+THREAD_INFO(%rsp,RIP)
/* clear IF, that popfq doesn't enable interrupts early */
-   andl$~0x200,EFLAGS-ARGOFFSET(%rsp)
-   movlRIP-ARGOFFSET(%rsp),%edx/* User %eip */
+   andl$~0x200,EFLAGS(%rsp)
+   movlRIP(%rsp),%edx  /* User %eip */
CFI_REGISTER rip,rdx
RESTORE_RSI_RDI
REMOVE_PT_GPREGS_FROM_STACK 3*8
@@ -207,18 +207,18 @@ sysexit_from_sys_call:
movl %ebx,%esi  /* 2nd arg: 1st syscall arg */
movl %eax,%edi  /* 1st arg: syscall number */
call __audit_syscall_entry
-   movl RAX-ARGOFFSET(%rsp),%eax   /* reload syscall number */
+   movl RAX(%rsp),%eax /* reload syscall number */
cmpq $(IA32_NR_syscalls-1),%rax
ja ia32_badsys
movl %ebx,%edi  /* reload 1st syscall arg */
-   movl RCX-ARGOFFSET(%rsp),%esi   /* reload 2nd syscall arg */
-   movl RDX-ARGOFFSET(%rsp),%edx   /* reload 3rd syscall arg */
-   movl RSI-ARGOFFSET(%rsp),%ecx   /* reload 4th syscall arg */
-   movl RDI-ARGOFFSET(%rsp),%r8d   /* reload 5th syscall arg */
+   movl RCX(%rsp),%esi /* reload 2nd syscall arg */
+   movl RDX(%rsp),%edx /* reload 3rd syscall arg */
+   movl RSI(%rsp),%ecx /* reload 4th syscall arg */
+   movl RDI(%rsp),%r8d /* reload 5th syscall arg */
.endm
 
.macro auditsys_exit exit
-   testl $(_TIF_ALLWORK_MASK & 
~_TIF_SYSCALL_AUDIT),TI_flags+THREAD_INFO(%rsp,RIP-ARGOFFSET)
+   testl $(_TIF_ALLWORK_MASK & 
~_TIF_SYSCALL_AUDIT),TI_flags+THREAD_INFO(%rsp,RIP)
jnz ia32_ret_from_sys_call
TRACE_IRQS_ON
ENABLE_I

[PATCH 08/11] x86: entry_64.S: fold test_in_nmi macro into its only user

[Denys Vlasenko]

No code changes.

Signed-off-by: Denys Vlasenko 
CC: Linus Torvalds 
CC: Oleg Nesterov 
CC: Borislav Petkov 
CC: "H. Peter Anvin" 
CC: Andy Lutomirski 
CC: Frederic Weisbecker 
CC: X86 ML 
CC: Alexei Starovoitov 
CC: Will Drewry 
CC: Kees Cook 
CC: linux-kernel@vger.kernel.org
---
 arch/x86/kernel/entry_64.S | 24 +---
 1 file changed, 9 insertions(+), 15 deletions(-)

diff --git a/arch/x86/kernel/entry_64.S b/arch/x86/kernel/entry_64.S
index aacfa2c..71036fe 100644
--- a/arch/x86/kernel/entry_64.S
+++ b/arch/x86/kernel/entry_64.S
@@ -1365,19 +1365,7 @@ ENTRY(error_exit)
CFI_ENDPROC
 END(error_exit)
 
-/*
- * Test if a given stack is an NMI stack or not.
- */
-   .macro test_in_nmi reg stack nmi_ret normal_ret
-   cmpq %\reg, \stack
-   ja \normal_ret
-   subq $EXCEPTION_STKSZ, %\reg
-   cmpq %\reg, \stack
-   jb \normal_ret
-   jmp \nmi_ret
-   .endm
-
-   /* runs on exception stack */
+/* Runs on exception stack */
 ENTRY(nmi)
INTR_FRAME
PARAVIRT_ADJUST_EXCEPTION_FRAME
@@ -1438,8 +1426,14 @@ ENTRY(nmi)
 * We check the variable because the first NMI could be in a
 * breakpoint routine using a breakpoint stack.
 */
-   lea 6*8(%rsp), %rdx
-   test_in_nmi rdx, 4*8(%rsp), nested_nmi, first_nmi
+   lea 6*8(%rsp), %rdx
+   cmpq%rdx, 4*8(%rsp)
+   ja  first_nmi
+   subq$EXCEPTION_STKSZ, %rdx
+   cmpq%rdx, 4*8(%rsp)
+   jb  first_nmi
+   jmp nested_nmi
+
CFI_REMEMBER_STATE
 
 nested_nmi:
-- 
1.8.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/