Re: [Cocci] [PATCH 4/4] coccicheck: add indexing enhancement options

[Wolfram Sang]

> It's not as efficient as glimpse because the query language is simpler.  

Interesting, what is missing compared to glimpse?

> So more filtering has to be done at the ocaml level.  But it's probably 
> fine in most cases.

For me, it has two advantages over glimpse:

a) it is in the debian package repository
b) the same database can be used with the code browser 'seascope'
   which can do nice things by feeding ctags on the fly with data
   from id-utils.

Mileages vary, of course, just wanted to mention it to give pointers.



signature.asc
Description: PGP signature

Re: [Cocci] [PATCH 4/4] coccicheck: add indexing enhancement options

[Wolfram Sang]

> It's not as efficient as glimpse because the query language is simpler.  

Interesting, what is missing compared to glimpse?

> So more filtering has to be done at the ocaml level.  But it's probably 
> fine in most cases.

For me, it has two advantages over glimpse:

a) it is in the debian package repository
b) the same database can be used with the code browser 'seascope'
   which can do nice things by feeding ctags on the fly with data
   from id-utils.

Mileages vary, of course, just wanted to mention it to give pointers.



signature.asc
Description: PGP signature

[PATCH] gpio: add Intel WhiskeyCove GPIO driver

[Bin Gao]

This patch introduces a separate GPIO driver for Intel WhiskeyCove PMIC.
This driver is based on gpio-crystalcove.c.

Signed-off-by: Ajay Thomas 
Signed-off-by: Bin Gao 
---
 drivers/gpio/Kconfig  |  13 ++
 drivers/gpio/Makefile |   1 +
 drivers/gpio/gpio-wcove.c | 402 ++
 3 files changed, 416 insertions(+)
 create mode 100644 drivers/gpio/gpio-wcove.c

diff --git a/drivers/gpio/Kconfig b/drivers/gpio/Kconfig
index 48da857..0bb6893 100644
--- a/drivers/gpio/Kconfig
+++ b/drivers/gpio/Kconfig
@@ -805,6 +805,19 @@ config GPIO_CRYSTAL_COVE
  This driver can also be built as a module. If so, the module will be
  called gpio-crystalcove.
 
+config GPIO_WHISKEY_COVE
+   tristate "GPIO support for Whiskey Cove PMIC"
+   depends on INTEL_SOC_PMIC
+   select GPIOLIB_IRQCHIP
+   help
+ Support for GPIO pins on Whiskey Cove PMIC.
+
+ Say Yes if you have a Intel SoC based tablet with Whsikey Cove PMIC
+ inside.
+
+ This driver can also be built as a module. If so, the module will be
+ called gpio-wcove.
+
 config GPIO_CS5535
tristate "AMD CS5535/CS5536 GPIO support"
depends on MFD_CS5535
diff --git a/drivers/gpio/Makefile b/drivers/gpio/Makefile
index 991598e..fff6914 100644
--- a/drivers/gpio/Makefile
+++ b/drivers/gpio/Makefile
@@ -34,6 +34,7 @@ obj-$(CONFIG_GPIO_BT8XX)  += gpio-bt8xx.o
 obj-$(CONFIG_GPIO_CLPS711X)+= gpio-clps711x.o
 obj-$(CONFIG_GPIO_CS5535)  += gpio-cs5535.o
 obj-$(CONFIG_GPIO_CRYSTAL_COVE)+= gpio-crystalcove.o
+obj-$(CONFIG_GPIO_WHISKEY_COVE)+= gpio-wcove.o
 obj-$(CONFIG_GPIO_DA9052)  += gpio-da9052.o
 obj-$(CONFIG_GPIO_DA9055)  += gpio-da9055.o
 obj-$(CONFIG_GPIO_DAVINCI) += gpio-davinci.o
diff --git a/drivers/gpio/gpio-wcove.c b/drivers/gpio/gpio-wcove.c
new file mode 100644
index 000..20d83e3
--- /dev/null
+++ b/drivers/gpio/gpio-wcove.c
@@ -0,0 +1,402 @@
+/*
+ * gpio-wcove.c - Intel Whiskey Cove GPIO Driver
+ *
+ * This driver is written based on gpio-crystalcove.c
+ *
+ * Copyright (C) 2015 Intel Corporation. All rights reserved.
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License version
+ * 2 as published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#define WCOVE_GPIO_NUM 13
+#define WCOVE_VGPIO_NUM94
+
+#define UPDATE_IRQ_TYPEBIT(0)
+#define UPDATE_IRQ_MASKBIT(1)
+
+#define GPIOIRQ0   0x4e0b
+#define GPIOIRQ1   0x4e0c
+#define MGPIOIRQ0  0x4e19
+#define MGPIOIRQ1  0x4e1a
+#define GPIO0P0CTLO0x4e44
+#define GPIO0P0CTLI0x4e51
+#define GPIO1P0CTLO0x4e4b
+#define GPIO1P0CTLI0x4e58
+#define GPIO2P0CTLO0x4e4f
+#define GPIO2P0CTLI0x4e5c
+
+#define CTLI_INTCNT_DIS(0)
+#define CTLI_INTCNT_NE (1 << 1)
+#define CTLI_INTCNT_PE (2 << 1)
+#define CTLI_INTCNT_BE (3 << 1)
+
+#define CTLO_DIR_IN(0)
+#define CTLO_DIR_OUT   (1 << 5)
+
+#define CTLO_DRV_CMOS  (0)
+#define CTLO_DRV_OD(1 << 4)
+
+#define CTLO_DRV_REN   (1 << 3)
+
+#define CTLO_RVAL_2KDW (0)
+#define CTLO_RVAL_2KUP (1 << 1)
+#define CTLO_RVAL_50KDW(2 << 1)
+#define CTLO_RVAL_50KUP(3 << 1)
+
+#define CTLO_INPUT_SET (CTLO_DRV_CMOS | CTLO_DRV_REN | CTLO_RVAL_2KUP)
+#define CTLO_OUTPUT_SET(CTLO_DIR_OUT | CTLO_INPUT_SET)
+
+enum ctrl_register {
+   CTRL_IN,
+   CTRL_OUT,
+};
+
+/*
+ * struct wcove_gpio - Whiskey Cove GPIO controller
+ * @buslock: for bus lock/sync and unlock.
+ * @chip: the abstract gpio_chip structure.
+ * @regmap: the regmap from the parent device.
+ * @update: pending IRQ setting update, to be written to the chip upon unlock.
+ * @intcnt_value: the Interrupt Detect value to be written.
+ * @set_irq_mask: true if the IRQ mask needs to be set, false to clear.
+ */
+struct wcove_gpio {
+   struct mutex buslock; /* irq_bus_lock */
+   struct gpio_chip chip;
+   struct regmap *regmap;
+   struct regmap_irq_chip_data *regmap_irq_chip;
+   int update;
+   int intcnt_value;
+   bool set_irq_mask;
+};
+
+static inline struct wcove_gpio *to_wg(struct gpio_chip *gc)
+{
+   return container_of(gc, struct wcove_gpio, chip);
+}
+
+static inline int to_reg(int gpio, enum ctrl_register reg_type)
+{
+   int reg;
+
+   if (reg_type == CTRL_IN) {
+

[PATCH] gpio: add Intel WhiskeyCove GPIO driver

[Bin Gao]

This patch introduces a separate GPIO driver for Intel WhiskeyCove PMIC.
This driver is based on gpio-crystalcove.c.

Signed-off-by: Ajay Thomas 
Signed-off-by: Bin Gao 
---
 drivers/gpio/Kconfig  |  13 ++
 drivers/gpio/Makefile |   1 +
 drivers/gpio/gpio-wcove.c | 402 ++
 3 files changed, 416 insertions(+)
 create mode 100644 drivers/gpio/gpio-wcove.c

diff --git a/drivers/gpio/Kconfig b/drivers/gpio/Kconfig
index 48da857..0bb6893 100644
--- a/drivers/gpio/Kconfig
+++ b/drivers/gpio/Kconfig
@@ -805,6 +805,19 @@ config GPIO_CRYSTAL_COVE
  This driver can also be built as a module. If so, the module will be
  called gpio-crystalcove.
 
+config GPIO_WHISKEY_COVE
+   tristate "GPIO support for Whiskey Cove PMIC"
+   depends on INTEL_SOC_PMIC
+   select GPIOLIB_IRQCHIP
+   help
+ Support for GPIO pins on Whiskey Cove PMIC.
+
+ Say Yes if you have a Intel SoC based tablet with Whsikey Cove PMIC
+ inside.
+
+ This driver can also be built as a module. If so, the module will be
+ called gpio-wcove.
+
 config GPIO_CS5535
tristate "AMD CS5535/CS5536 GPIO support"
depends on MFD_CS5535
diff --git a/drivers/gpio/Makefile b/drivers/gpio/Makefile
index 991598e..fff6914 100644
--- a/drivers/gpio/Makefile
+++ b/drivers/gpio/Makefile
@@ -34,6 +34,7 @@ obj-$(CONFIG_GPIO_BT8XX)  += gpio-bt8xx.o
 obj-$(CONFIG_GPIO_CLPS711X)+= gpio-clps711x.o
 obj-$(CONFIG_GPIO_CS5535)  += gpio-cs5535.o
 obj-$(CONFIG_GPIO_CRYSTAL_COVE)+= gpio-crystalcove.o
+obj-$(CONFIG_GPIO_WHISKEY_COVE)+= gpio-wcove.o
 obj-$(CONFIG_GPIO_DA9052)  += gpio-da9052.o
 obj-$(CONFIG_GPIO_DA9055)  += gpio-da9055.o
 obj-$(CONFIG_GPIO_DAVINCI) += gpio-davinci.o
diff --git a/drivers/gpio/gpio-wcove.c b/drivers/gpio/gpio-wcove.c
new file mode 100644
index 000..20d83e3
--- /dev/null
+++ b/drivers/gpio/gpio-wcove.c
@@ -0,0 +1,402 @@
+/*
+ * gpio-wcove.c - Intel Whiskey Cove GPIO Driver
+ *
+ * This driver is written based on gpio-crystalcove.c
+ *
+ * Copyright (C) 2015 Intel Corporation. All rights reserved.
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License version
+ * 2 as published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#define WCOVE_GPIO_NUM 13
+#define WCOVE_VGPIO_NUM94
+
+#define UPDATE_IRQ_TYPEBIT(0)
+#define UPDATE_IRQ_MASKBIT(1)
+
+#define GPIOIRQ0   0x4e0b
+#define GPIOIRQ1   0x4e0c
+#define MGPIOIRQ0  0x4e19
+#define MGPIOIRQ1  0x4e1a
+#define GPIO0P0CTLO0x4e44
+#define GPIO0P0CTLI0x4e51
+#define GPIO1P0CTLO0x4e4b
+#define GPIO1P0CTLI0x4e58
+#define GPIO2P0CTLO0x4e4f
+#define GPIO2P0CTLI0x4e5c
+
+#define CTLI_INTCNT_DIS(0)
+#define CTLI_INTCNT_NE (1 << 1)
+#define CTLI_INTCNT_PE (2 << 1)
+#define CTLI_INTCNT_BE (3 << 1)
+
+#define CTLO_DIR_IN(0)
+#define CTLO_DIR_OUT   (1 << 5)
+
+#define CTLO_DRV_CMOS  (0)
+#define CTLO_DRV_OD(1 << 4)
+
+#define CTLO_DRV_REN   (1 << 3)
+
+#define CTLO_RVAL_2KDW (0)
+#define CTLO_RVAL_2KUP (1 << 1)
+#define CTLO_RVAL_50KDW(2 << 1)
+#define CTLO_RVAL_50KUP(3 << 1)
+
+#define CTLO_INPUT_SET (CTLO_DRV_CMOS | CTLO_DRV_REN | CTLO_RVAL_2KUP)
+#define CTLO_OUTPUT_SET(CTLO_DIR_OUT | CTLO_INPUT_SET)
+
+enum ctrl_register {
+   CTRL_IN,
+   CTRL_OUT,
+};
+
+/*
+ * struct wcove_gpio - Whiskey Cove GPIO controller
+ * @buslock: for bus lock/sync and unlock.
+ * @chip: the abstract gpio_chip structure.
+ * @regmap: the regmap from the parent device.
+ * @update: pending IRQ setting update, to be written to the chip upon unlock.
+ * @intcnt_value: the Interrupt Detect value to be written.
+ * @set_irq_mask: true if the IRQ mask needs to be set, false to clear.
+ */
+struct wcove_gpio {
+   struct mutex buslock; /* irq_bus_lock */
+   struct gpio_chip chip;
+   struct regmap *regmap;
+   struct regmap_irq_chip_data *regmap_irq_chip;
+   int update;
+   int intcnt_value;
+   bool set_irq_mask;
+};
+
+static inline struct wcove_gpio *to_wg(struct gpio_chip *gc)
+{
+   return container_of(gc, struct wcove_gpio, chip);
+}
+
+static inline int to_reg(int gpio, enum ctrl_register reg_type)
+{
+   int reg;
+
+   if (reg_type == CTRL_IN) {
+   if (gpio < 7)
+   reg = GPIO0P0CTLI + 

Re: [Cocci] [PATCH 2/4] coccicheck: enable paramap support

[Julia Lawall]

On Sat, 11 Jun 2016, SF Markus Elfring wrote:

> > Also enable the load balancing to be dynamic, so that
> > if a thread finishes early we keep feeding it.
> 
> Is this functionality influenced by the parameter "chunksize"?

Yes, without chunksize the distribution of work to processes is static.

julia

Re: [Cocci] [PATCH 2/4] coccicheck: enable paramap support

[Julia Lawall]

On Sat, 11 Jun 2016, SF Markus Elfring wrote:

> > Also enable the load balancing to be dynamic, so that
> > if a thread finishes early we keep feeding it.
> 
> Is this functionality influenced by the parameter "chunksize"?

Yes, without chunksize the distribution of work to processes is static.

julia

Re: [Cocci] [PATCH 4/4] coccicheck: add indexing enhancement options

[SF Markus Elfring]

> in practice though this seems to not perform better than
> regular grep however its expected to help with some use cases
> so we use that if you have no other indexing options in place
> available.

Would you like to fix a typo in this paragraph?

Regards,
Markus

Re: [Cocci] [PATCH 4/4] coccicheck: add indexing enhancement options

[SF Markus Elfring]

> in practice though this seems to not perform better than
> regular grep however its expected to help with some use cases
> so we use that if you have no other indexing options in place
> available.

Would you like to fix a typo in this paragraph?

Regards,
Markus

Re: [Cocci] [PATCH 4/4] coccicheck: add indexing enhancement options

[Julia Lawall]

On Sat, 11 Jun 2016, Wolfram Sang wrote:

> 
> > real16m11.692s
> > user127m50.388s
> > sys 0m2.168s
> 
> That's better but not a magnitude, I wonder.

I think that it is because the filtering that Coccinelle does already 
works pretty well, and there are quite a lot of files (7514) that contain 
kfree.

julia

Re: [Cocci] [PATCH 4/4] coccicheck: add indexing enhancement options

[Julia Lawall]

On Sat, 11 Jun 2016, Wolfram Sang wrote:

> 
> > real16m11.692s
> > user127m50.388s
> > sys 0m2.168s
> 
> That's better but not a magnitude, I wonder.

I think that it is because the filtering that Coccinelle does already 
works pretty well, and there are quite a lot of files (7514) that contain 
kfree.

julia

Re: [PATCH] RDS: IB: Remove deprecated create_workqueue

[David Miller]

From: Bhaktipriya Shridhar 
Date: Wed, 8 Jun 2016 01:03:45 +0530

> alloc_workqueue replaces deprecated create_workqueue().
> 
> Since the driver is infiniband which can be used as block device and the
> workqueue seems involved in regular operation of the device, so a
> dedicated workqueue has been used  with WQ_MEM_RECLAIM set to guarantee
> forward progress under memory pressure.
> Since there are only a fixed number of work items, explicit concurrency
> limit is unnecessary here.
> 
> Signed-off-by: Bhaktipriya Shridhar 

Applied, thanks.

Re: [Cocci] [PATCH 2/4] coccicheck: enable paramap support

[SF Markus Elfring]

> Also enable the load balancing to be dynamic, so that
> if a thread finishes early we keep feeding it.

Is this functionality influenced by the parameter "chunksize"?

Regards,
Markus

Re: [PATCH] RDS: IB: Remove deprecated create_workqueue

[David Miller]

From: Bhaktipriya Shridhar 
Date: Wed, 8 Jun 2016 01:03:45 +0530

> alloc_workqueue replaces deprecated create_workqueue().
> 
> Since the driver is infiniband which can be used as block device and the
> workqueue seems involved in regular operation of the device, so a
> dedicated workqueue has been used  with WQ_MEM_RECLAIM set to guarantee
> forward progress under memory pressure.
> Since there are only a fixed number of work items, explicit concurrency
> limit is unnecessary here.
> 
> Signed-off-by: Bhaktipriya Shridhar 

Applied, thanks.

Re: [Cocci] [PATCH 2/4] coccicheck: enable paramap support

[SF Markus Elfring]

> Also enable the load balancing to be dynamic, so that
> if a thread finishes early we keep feeding it.

Is this functionality influenced by the parameter "chunksize"?

Regards,
Markus

Re: [PATCH v6] r8152: Add support for setting pass through MAC address on RTL8153-AD

[David Miller]

From: Mario Limonciello 
Date: Tue,  7 Jun 2016 13:22:37 -0500

> The RTL8153-AD supports a persistent system specific MAC address.
> This means a device plugged into two different systems with host side
> support will show different (but persistent) MAC addresses.
> 
> This information for the system's persistent MAC address is burned in when
> the system HW is built and available under \_SB.AMAC in the DSDT at runtime.
> 
> This technology is currently implemented in the Dell TB15 and WD15 Type-C
> docks.  More information is available here:
> http://www.dell.com/support/article/us/en/04/SLN301147
> 
> Signed-off-by: Mario Limonciello 
> ---
> Changes from v5:
>  * Correct return value if hex2bin succesful but invalid ether addr

Have things calmed down enough now that I can apply this?

Let's see some ACKs.

Re: [PATCH v6] r8152: Add support for setting pass through MAC address on RTL8153-AD

[David Miller]

From: Mario Limonciello 
Date: Tue,  7 Jun 2016 13:22:37 -0500

> The RTL8153-AD supports a persistent system specific MAC address.
> This means a device plugged into two different systems with host side
> support will show different (but persistent) MAC addresses.
> 
> This information for the system's persistent MAC address is burned in when
> the system HW is built and available under \_SB.AMAC in the DSDT at runtime.
> 
> This technology is currently implemented in the Dell TB15 and WD15 Type-C
> docks.  More information is available here:
> http://www.dell.com/support/article/us/en/04/SLN301147
> 
> Signed-off-by: Mario Limonciello 
> ---
> Changes from v5:
>  * Correct return value if hex2bin succesful but invalid ether addr

Have things calmed down enough now that I can apply this?

Let's see some ACKs.

Re: [PATCH v2 1/2] net: ethernet: ti: cpsw: remove rx_descs property

[David Miller]

From: Ivan Khoronzhuk 
Date: Tue,  7 Jun 2016 16:59:35 +0300

>   if (!cpsw_common_res_usage_state(priv)) {
> + int buf_num;
>   struct cpsw_priv *priv_sl0 = cpsw_get_slave_priv(priv, 0);
>  

Please always order local variable declarations from longest to shortest
line.

Re: [PATCH v2 1/2] net: ethernet: ti: cpsw: remove rx_descs property

[David Miller]

From: Ivan Khoronzhuk 
Date: Tue,  7 Jun 2016 16:59:35 +0300

>   if (!cpsw_common_res_usage_state(priv)) {
> + int buf_num;
>   struct cpsw_priv *priv_sl0 = cpsw_get_slave_priv(priv, 0);
>  

Please always order local variable declarations from longest to shortest
line.

Re: [PATCH 0/6] eBPF JIT for PPC64

[David Miller]

From: "Naveen N. Rao" 
Date: Tue,  7 Jun 2016 19:02:17 +0530

> Please note that patch [2] is a pre-requisite for this patchset, and is
> not yet upstream.
 ...
> [1] http://thread.gmane.org/gmane.linux.kernel/2188694
> [2] http://thread.gmane.org/gmane.linux.ports.ppc.embedded/96514

Because of #2 I don't think I can take this directly into the networking
tree, right?

Therefore, how would you like this to be merged?

Re: [PATCH 0/6] eBPF JIT for PPC64

[David Miller]

From: "Naveen N. Rao" 
Date: Tue,  7 Jun 2016 19:02:17 +0530

> Please note that patch [2] is a pre-requisite for this patchset, and is
> not yet upstream.
 ...
> [1] http://thread.gmane.org/gmane.linux.kernel/2188694
> [2] http://thread.gmane.org/gmane.linux.ports.ppc.embedded/96514

Because of #2 I don't think I can take this directly into the networking
tree, right?

Therefore, how would you like this to be merged?

Re: [Cocci] [PATCH 4/4] coccicheck: add indexing enhancement options

[Wolfram Sang]

> real16m11.692s
> user127m50.388s
> sys 0m2.168s

That's better but not a magnitude, I wonder.



signature.asc
Description: PGP signature

Re: [Cocci] [PATCH 4/4] coccicheck: add indexing enhancement options

[Wolfram Sang]

> real16m11.692s
> user127m50.388s
> sys 0m2.168s

That's better but not a magnitude, I wonder.



signature.asc
Description: PGP signature

Re: [Cocci] [PATCH 0/4] scripts/coccicheck: add paramap and indexing options

[SF Markus Elfring]

> we should be able to also take advantage of with coccicheck,
> the most important one is paramap support.

Do OCaml developers prefer to refer to the software "Parmap" here?
https://rdicosmo.github.io/parmap/

Regards,
Markus

Re: [Cocci] [PATCH 0/4] scripts/coccicheck: add paramap and indexing options

[SF Markus Elfring]

> we should be able to also take advantage of with coccicheck,
> the most important one is paramap support.

Do OCaml developers prefer to refer to the software "Parmap" here?
https://rdicosmo.github.io/parmap/

Regards,
Markus

[PATCH v3] Input: synaptics-rmi4: Support regulator supplies

[Bjorn Andersson]

From: Bjorn Andersson 

Support the two supplies - vdd and vio - to make it possible to control
power to the Synaptics chip.

Signed-off-by: Bjorn Andersson 
Signed-off-by: Bjorn Andersson 
---
 .../devicetree/bindings/input/rmi4/rmi_i2c.txt |  9 +
 drivers/input/rmi4/rmi_i2c.c   | 41 ++
 2 files changed, 50 insertions(+)

diff --git a/Documentation/devicetree/bindings/input/rmi4/rmi_i2c.txt 
b/Documentation/devicetree/bindings/input/rmi4/rmi_i2c.txt
index 95fa715c6046..ec908b91fd90 100644
--- a/Documentation/devicetree/bindings/input/rmi4/rmi_i2c.txt
+++ b/Documentation/devicetree/bindings/input/rmi4/rmi_i2c.txt
@@ -22,6 +22,15 @@ See 
Documentation/devicetree/bindings/interrupt-controller/interrupts.txt
 - syna,reset-delay-ms: The number of milliseconds to wait after resetting the
device.
 
+- syna,startup-delay-ms: The number of milliseconds to wait after powering on
+the device.
+
+- vdd-supply: VDD power supply.
+See ../regulator/regulator.txt
+
+- vio-supply: VIO power supply
+See ../regulator/regulator.txt
+
 Function Parameters:
 Parameters specific to RMI functions are contained in child nodes of the rmi 
device
  node. Documentation for the parameters of each function can be found in:
diff --git a/drivers/input/rmi4/rmi_i2c.c b/drivers/input/rmi4/rmi_i2c.c
index a96a326b53bd..71dc6cdde8ac 100644
--- a/drivers/input/rmi4/rmi_i2c.c
+++ b/drivers/input/rmi4/rmi_i2c.c
@@ -11,6 +11,8 @@
 #include 
 #include 
 #include 
+#include 
+#include 
 #include "rmi_driver.h"
 
 #define BUFFER_SIZE_INCREMENT 32
@@ -37,6 +39,9 @@ struct rmi_i2c_xport {
 
u8 *tx_buf;
size_t tx_buf_size;
+
+   struct regulator_bulk_data supplies[2];
+   u32 startup_delay;
 };
 
 #define RMI_PAGE_SELECT_REGISTER 0xff
@@ -246,6 +251,24 @@ static int rmi_i2c_probe(struct i2c_client *client,
return -ENODEV;
}
 
+   rmi_i2c->supplies[0].supply = "vdd";
+   rmi_i2c->supplies[1].supply = "vio";
+   retval = devm_regulator_bulk_get(>dev,
+ARRAY_SIZE(rmi_i2c->supplies),
+rmi_i2c->supplies);
+   if (retval < 0)
+   return retval;
+
+   retval = regulator_bulk_enable(ARRAY_SIZE(rmi_i2c->supplies),
+  rmi_i2c->supplies);
+   if (retval < 0)
+   return retval;
+
+   of_property_read_u32(client->dev.of_node, "syna,startup-delay-ms",
+_i2c->startup_delay);
+
+   msleep(rmi_i2c->startup_delay);
+
rmi_i2c->client = client;
mutex_init(_i2c->page_mutex);
 
@@ -286,6 +309,7 @@ static int rmi_i2c_remove(struct i2c_client *client)
struct rmi_i2c_xport *rmi_i2c = i2c_get_clientdata(client);
 
rmi_unregister_transport_device(_i2c->xport);
+   regulator_bulk_disable(ARRAY_SIZE(rmi_i2c->supplies), 
rmi_i2c->supplies);
 
return 0;
 }
@@ -308,6 +332,9 @@ static int rmi_i2c_suspend(struct device *dev)
dev_warn(dev, "Failed to enable irq for wake: %d\n",
ret);
}
+
+   regulator_bulk_disable(ARRAY_SIZE(rmi_i2c->supplies), 
rmi_i2c->supplies);
+
return ret;
 }
 
@@ -317,6 +344,12 @@ static int rmi_i2c_resume(struct device *dev)
struct rmi_i2c_xport *rmi_i2c = i2c_get_clientdata(client);
int ret;
 
+   ret = regulator_bulk_enable(ARRAY_SIZE(rmi_i2c->supplies), 
rmi_i2c->supplies);
+   if (ret)
+   return ret;
+
+   msleep(rmi_i2c->startup_delay);
+
enable_irq(rmi_i2c->irq);
if (device_may_wakeup(>dev)) {
ret = disable_irq_wake(rmi_i2c->irq);
@@ -346,6 +379,8 @@ static int rmi_i2c_runtime_suspend(struct device *dev)
 
disable_irq(rmi_i2c->irq);
 
+   regulator_bulk_disable(ARRAY_SIZE(rmi_i2c->supplies), 
rmi_i2c->supplies);
+
return 0;
 }
 
@@ -355,6 +390,12 @@ static int rmi_i2c_runtime_resume(struct device *dev)
struct rmi_i2c_xport *rmi_i2c = i2c_get_clientdata(client);
int ret;
 
+   ret = regulator_bulk_enable(ARRAY_SIZE(rmi_i2c->supplies), 
rmi_i2c->supplies);
+   if (ret)
+   return ret;
+
+   msleep(rmi_i2c->startup_delay);
+
enable_irq(rmi_i2c->irq);
 
ret = rmi_driver_resume(rmi_i2c->xport.rmi_dev);
-- 
2.5.0

Re: [Cocci] [PATCH 4/4] coccicheck: add indexing enhancement options

[Julia Lawall]

On Fri, 10 Jun 2016, Wolfram Sang wrote:

> > AFAICT coccinelle does not have integration support for id-utils though.
> 
> I used it just today ;) -- "--use-idutils ./ID"
> 
> ID was generated with simple 'mkid -s'.

Coccinelle includes a script scripts/idutils_index.sh

This does mkid -i C --output .id-utils.index *

julia

Re: [Cocci] [PATCH 4/4] coccicheck: add indexing enhancement options

[Julia Lawall]

On Fri, 10 Jun 2016, Wolfram Sang wrote:

> > AFAICT coccinelle does not have integration support for id-utils though.
> 
> I used it just today ;) -- "--use-idutils ./ID"
> 
> ID was generated with simple 'mkid -s'.

Coccinelle includes a script scripts/idutils_index.sh

This does mkid -i C --output .id-utils.index *

julia

[PATCH v3] Input: synaptics-rmi4: Support regulator supplies

[Bjorn Andersson]

From: Bjorn Andersson 

Support the two supplies - vdd and vio - to make it possible to control
power to the Synaptics chip.

Signed-off-by: Bjorn Andersson 
Signed-off-by: Bjorn Andersson 
---
 .../devicetree/bindings/input/rmi4/rmi_i2c.txt |  9 +
 drivers/input/rmi4/rmi_i2c.c   | 41 ++
 2 files changed, 50 insertions(+)

diff --git a/Documentation/devicetree/bindings/input/rmi4/rmi_i2c.txt 
b/Documentation/devicetree/bindings/input/rmi4/rmi_i2c.txt
index 95fa715c6046..ec908b91fd90 100644
--- a/Documentation/devicetree/bindings/input/rmi4/rmi_i2c.txt
+++ b/Documentation/devicetree/bindings/input/rmi4/rmi_i2c.txt
@@ -22,6 +22,15 @@ See 
Documentation/devicetree/bindings/interrupt-controller/interrupts.txt
 - syna,reset-delay-ms: The number of milliseconds to wait after resetting the
device.
 
+- syna,startup-delay-ms: The number of milliseconds to wait after powering on
+the device.
+
+- vdd-supply: VDD power supply.
+See ../regulator/regulator.txt
+
+- vio-supply: VIO power supply
+See ../regulator/regulator.txt
+
 Function Parameters:
 Parameters specific to RMI functions are contained in child nodes of the rmi 
device
  node. Documentation for the parameters of each function can be found in:
diff --git a/drivers/input/rmi4/rmi_i2c.c b/drivers/input/rmi4/rmi_i2c.c
index a96a326b53bd..71dc6cdde8ac 100644
--- a/drivers/input/rmi4/rmi_i2c.c
+++ b/drivers/input/rmi4/rmi_i2c.c
@@ -11,6 +11,8 @@
 #include 
 #include 
 #include 
+#include 
+#include 
 #include "rmi_driver.h"
 
 #define BUFFER_SIZE_INCREMENT 32
@@ -37,6 +39,9 @@ struct rmi_i2c_xport {
 
u8 *tx_buf;
size_t tx_buf_size;
+
+   struct regulator_bulk_data supplies[2];
+   u32 startup_delay;
 };
 
 #define RMI_PAGE_SELECT_REGISTER 0xff
@@ -246,6 +251,24 @@ static int rmi_i2c_probe(struct i2c_client *client,
return -ENODEV;
}
 
+   rmi_i2c->supplies[0].supply = "vdd";
+   rmi_i2c->supplies[1].supply = "vio";
+   retval = devm_regulator_bulk_get(>dev,
+ARRAY_SIZE(rmi_i2c->supplies),
+rmi_i2c->supplies);
+   if (retval < 0)
+   return retval;
+
+   retval = regulator_bulk_enable(ARRAY_SIZE(rmi_i2c->supplies),
+  rmi_i2c->supplies);
+   if (retval < 0)
+   return retval;
+
+   of_property_read_u32(client->dev.of_node, "syna,startup-delay-ms",
+_i2c->startup_delay);
+
+   msleep(rmi_i2c->startup_delay);
+
rmi_i2c->client = client;
mutex_init(_i2c->page_mutex);
 
@@ -286,6 +309,7 @@ static int rmi_i2c_remove(struct i2c_client *client)
struct rmi_i2c_xport *rmi_i2c = i2c_get_clientdata(client);
 
rmi_unregister_transport_device(_i2c->xport);
+   regulator_bulk_disable(ARRAY_SIZE(rmi_i2c->supplies), 
rmi_i2c->supplies);
 
return 0;
 }
@@ -308,6 +332,9 @@ static int rmi_i2c_suspend(struct device *dev)
dev_warn(dev, "Failed to enable irq for wake: %d\n",
ret);
}
+
+   regulator_bulk_disable(ARRAY_SIZE(rmi_i2c->supplies), 
rmi_i2c->supplies);
+
return ret;
 }
 
@@ -317,6 +344,12 @@ static int rmi_i2c_resume(struct device *dev)
struct rmi_i2c_xport *rmi_i2c = i2c_get_clientdata(client);
int ret;
 
+   ret = regulator_bulk_enable(ARRAY_SIZE(rmi_i2c->supplies), 
rmi_i2c->supplies);
+   if (ret)
+   return ret;
+
+   msleep(rmi_i2c->startup_delay);
+
enable_irq(rmi_i2c->irq);
if (device_may_wakeup(>dev)) {
ret = disable_irq_wake(rmi_i2c->irq);
@@ -346,6 +379,8 @@ static int rmi_i2c_runtime_suspend(struct device *dev)
 
disable_irq(rmi_i2c->irq);
 
+   regulator_bulk_disable(ARRAY_SIZE(rmi_i2c->supplies), 
rmi_i2c->supplies);
+
return 0;
 }
 
@@ -355,6 +390,12 @@ static int rmi_i2c_runtime_resume(struct device *dev)
struct rmi_i2c_xport *rmi_i2c = i2c_get_clientdata(client);
int ret;
 
+   ret = regulator_bulk_enable(ARRAY_SIZE(rmi_i2c->supplies), 
rmi_i2c->supplies);
+   if (ret)
+   return ret;
+
+   msleep(rmi_i2c->startup_delay);
+
enable_irq(rmi_i2c->irq);
 
ret = rmi_driver_resume(rmi_i2c->xport.rmi_dev);
-- 
2.5.0

QUICK LOAN OFFER

[International Loan Firm]

Do you need a personal loan or a business loan? our offer is the best and 
reliable offer for you. duration period: 1 to 25 years get your loan approved 
within 3 days contact us now for more information: 
internationalloan...@gmail.com

---
This email has been checked for viruses by Avast antivirus software.
https://www.avast.com/antivirus

QUICK LOAN OFFER

[International Loan Firm]

Do you need a personal loan or a business loan? our offer is the best and 
reliable offer for you. duration period: 1 to 25 years get your loan approved 
within 3 days contact us now for more information: 
internationalloan...@gmail.com

---
This email has been checked for viruses by Avast antivirus software.
https://www.avast.com/antivirus

Re: [Cocci] [PATCH 4/4] coccicheck: add indexing enhancement options

[Julia Lawall]

On Sat, 11 Jun 2016, Luis R. Rodriguez wrote:

> On Fri, Jun 10, 2016 at 11:51:26PM +0200, Wolfram Sang wrote:
> > > AFAICT coccinelle does not have integration support for id-utils though.
> > 
> > I used it just today ;) -- "--use-idutils ./ID"
> > 
> > ID was generated with simple 'mkid -s'.
> > 
> 
> Sweet, testing that now.

It's not as efficient as glimpse because the query language is simpler.  
So more filtering has to be done at the ocaml level.  But it's probably 
fine in most cases.

julia

Re: [Cocci] [PATCH 4/4] coccicheck: add indexing enhancement options

[Julia Lawall]

On Sat, 11 Jun 2016, Luis R. Rodriguez wrote:

> On Fri, Jun 10, 2016 at 11:51:26PM +0200, Wolfram Sang wrote:
> > > AFAICT coccinelle does not have integration support for id-utils though.
> > 
> > I used it just today ;) -- "--use-idutils ./ID"
> > 
> > ID was generated with simple 'mkid -s'.
> > 
> 
> Sweet, testing that now.

It's not as efficient as glimpse because the query language is simpler.  
So more filtering has to be done at the ocaml level.  But it's probably 
fine in most cases.

julia

Re: [Cocci] [PATCH 4/4] coccicheck: add indexing enhancement options

[Julia Lawall]

On Fri, 10 Jun 2016, Luis R. Rodriguez wrote:

> On Fri, Jun 10, 2016 at 11:43:57PM +0200, Wolfram Sang wrote:
> > > > Well, slightly better.
> > > 
> > > No, it should be much better.  You would have to look at the standard 
> > 
> > I use id-utils regularly and it is indeed at least a magnitude better.
> > The indexing often pays off already with the first coccinelle run for
> > me. Highly recommended.
> 
> AFAICT coccinelle does not have integration support for id-utils though.

Yes it does, for years.

julia

Re: [Cocci] [PATCH 4/4] coccicheck: add indexing enhancement options

[Julia Lawall]

On Fri, 10 Jun 2016, Luis R. Rodriguez wrote:

> On Fri, Jun 10, 2016 at 11:43:57PM +0200, Wolfram Sang wrote:
> > > > Well, slightly better.
> > > 
> > > No, it should be much better.  You would have to look at the standard 
> > 
> > I use id-utils regularly and it is indeed at least a magnitude better.
> > The indexing often pays off already with the first coccinelle run for
> > me. Highly recommended.
> 
> AFAICT coccinelle does not have integration support for id-utils though.

Yes it does, for years.

julia

Re: [PATCH] net: phy: smsc: reintroduced unconditional soft reset

[David Miller]

From: Manfred Schlaegl 
Date: Mon, 6 Jun 2016 10:47:47 +0200

> We detected some problems using the smsc lan8720a in combination with
> i.MX28 and tracked this down to commit 21009686662f ("net: phy: smsc: move
> smsc_phy_config_init reset part in a soft_reset function")
> With 2100968666 the generic soft reset is replaced by a specific function
> which handles power down state correctly. But additionally the soft reset
> itself got conditional and is therefore also only performed if the phy is
> in power down state.
> 
> This patch keeps the conditional wake up from power down, but
> re-introduces the unconditional soft reset using the generic soft reset
> function.
> It was tested on linux-4.1.25 and linux-4.7.0-rc2.
> 
> Signed-off-by: Manfred Schlaegl 

Applied.

Re: [PATCH] net: phy: smsc: reintroduced unconditional soft reset

[David Miller]

From: Manfred Schlaegl 
Date: Mon, 6 Jun 2016 10:47:47 +0200

> We detected some problems using the smsc lan8720a in combination with
> i.MX28 and tracked this down to commit 21009686662f ("net: phy: smsc: move
> smsc_phy_config_init reset part in a soft_reset function")
> With 2100968666 the generic soft reset is replaced by a specific function
> which handles power down state correctly. But additionally the soft reset
> itself got conditional and is therefore also only performed if the phy is
> in power down state.
> 
> This patch keeps the conditional wake up from power down, but
> re-introduces the unconditional soft reset using the generic soft reset
> function.
> It was tested on linux-4.1.25 and linux-4.7.0-rc2.
> 
> Signed-off-by: Manfred Schlaegl 

Applied.

Re: [PULL] lkdtm update (next)

[Greg KH]

On Fri, Jun 10, 2016 at 05:38:06PM -0700, Kees Cook wrote:
> On Fri, Jun 10, 2016 at 5:00 PM, Greg KH  wrote:
> > On Fri, Jun 10, 2016 at 04:02:44PM -0700, Kees Cook wrote:
> >> Hi,
> >>
> >> Please pull these lkdtm changes for next.
> >
> > These are all for 4.8-rc1 inclusion, right?  Not bugfixes for 4.7-final?
> 
> Yes, that's correct. Thanks!

Great, now pulled, thanks.

greg k-h

Re: [PULL] lkdtm update (next)

[Greg KH]

On Fri, Jun 10, 2016 at 05:38:06PM -0700, Kees Cook wrote:
> On Fri, Jun 10, 2016 at 5:00 PM, Greg KH  wrote:
> > On Fri, Jun 10, 2016 at 04:02:44PM -0700, Kees Cook wrote:
> >> Hi,
> >>
> >> Please pull these lkdtm changes for next.
> >
> > These are all for 4.8-rc1 inclusion, right?  Not bugfixes for 4.7-final?
> 
> Yes, that's correct. Thanks!

Great, now pulled, thanks.

greg k-h

Re: [PATCH 01/21] fs: Replace CURRENT_TIME_SEC with current_fs_time()

[Deepa Dinamani]

On Fri, Jun 10, 2016 at 3:21 PM, Arnd Bergmann  wrote:
> On Wednesday, June 8, 2016 10:04:45 PM CEST Deepa Dinamani wrote:
>> CURRENT_TIME_SEC is not y2038 safe. current_fs_time() will
>> be transitioned to use 64 bit time along with vfs in a
>> separate patch.
>> There is no plan to transistion CURRENT_TIME_SEC to use
>> y2038 safe time interfaces.
>>
>> current_fs_time() will also be extended to use superblock
>> range checking parameters when range checking is introduced.
>>
>> This works because alloc_super() fills in the the s_time_gran
>> in super block to NSEC_PER_SEC.
>>
>> Also note that filesystem specific times like the birthtime,
>> creation time that were using same interfaces to obtain time
>> retain same logistics.
>>
>> Signed-off-by: Deepa Dinamani 
>
> one question:
>
> In an earlier version, you had a small optimization to
> use ktime_get_real_seconds() instead of current_kernel_time()
> when the granularity is seconds.
>
> Do you still plan to send that one, or did you decide we don't
> need it?

I was actually planning to use get_seconds() instead of current_kernel_time().
And, transition both along with vfs to y2038 safe apis.
Difference between ktime_get_real_seconds() and current_kernel_time64()
is not much because they both require sequence counter.

It didn't make sense to me to optimize current_fs_time() for seconds
only, and not optimize for 1ns granularity also.
I plan to make changes to the function depending on how we end up
using timespec_trunc()
after the addition of range checking.

Thanks for the guidance on inclusion of reviewers. I'll follow this
approach when I post v2 of the series.

-Deepa

Re: [PATCH 01/21] fs: Replace CURRENT_TIME_SEC with current_fs_time()

[Deepa Dinamani]

On Fri, Jun 10, 2016 at 3:21 PM, Arnd Bergmann  wrote:
> On Wednesday, June 8, 2016 10:04:45 PM CEST Deepa Dinamani wrote:
>> CURRENT_TIME_SEC is not y2038 safe. current_fs_time() will
>> be transitioned to use 64 bit time along with vfs in a
>> separate patch.
>> There is no plan to transistion CURRENT_TIME_SEC to use
>> y2038 safe time interfaces.
>>
>> current_fs_time() will also be extended to use superblock
>> range checking parameters when range checking is introduced.
>>
>> This works because alloc_super() fills in the the s_time_gran
>> in super block to NSEC_PER_SEC.
>>
>> Also note that filesystem specific times like the birthtime,
>> creation time that were using same interfaces to obtain time
>> retain same logistics.
>>
>> Signed-off-by: Deepa Dinamani 
>
> one question:
>
> In an earlier version, you had a small optimization to
> use ktime_get_real_seconds() instead of current_kernel_time()
> when the granularity is seconds.
>
> Do you still plan to send that one, or did you decide we don't
> need it?

I was actually planning to use get_seconds() instead of current_kernel_time().
And, transition both along with vfs to y2038 safe apis.
Difference between ktime_get_real_seconds() and current_kernel_time64()
is not much because they both require sequence counter.

It didn't make sense to me to optimize current_fs_time() for seconds
only, and not optimize for 1ns granularity also.
I plan to make changes to the function depending on how we end up
using timespec_trunc()
after the addition of range checking.

Thanks for the guidance on inclusion of reviewers. I'll follow this
approach when I post v2 of the series.

-Deepa

[PATCH] firmware: qcom: scm: Expose PAS command 10 as reset-controller

[Bjorn Andersson]

PAS command 10 is used to assert and deassert the MSS reset via
TrustZone, expose this as a reset-controller to follow the non-secure
case where GCC exposes this control.

Signed-off-by: Bjorn Andersson 
---
 .../devicetree/bindings/firmware/qcom,scm.txt  |  6 
 drivers/firmware/qcom_scm-32.c | 13 +
 drivers/firmware/qcom_scm-64.c | 17 +++
 drivers/firmware/qcom_scm.c| 34 ++
 drivers/firmware/qcom_scm.h|  2 ++
 5 files changed, 72 insertions(+)

diff --git a/Documentation/devicetree/bindings/firmware/qcom,scm.txt 
b/Documentation/devicetree/bindings/firmware/qcom,scm.txt
index 3b4436e56865..f1ae9d3871f5 100644
--- a/Documentation/devicetree/bindings/firmware/qcom,scm.txt
+++ b/Documentation/devicetree/bindings/firmware/qcom,scm.txt
@@ -17,6 +17,11 @@ Required properties:
 - clock-names: Must contain "core" for the core clock, "iface" for the 
interface
   clock and "bus" for the bus clock per the requirements of the compatible.
 
+Optional properties:
+- #reset-cells: must be 1, if specified. Specifies that the scm implements a
+  reset controller exposing the modem subsystem reset as a single reset, at
+  index 0.
+
 Example for MSM8916:
 
firmware {
@@ -24,5 +29,6 @@ Example for MSM8916:
compatible = "qcom,scm";
clocks = < GCC_CRYPTO_CLK> , < 
GCC_CRYPTO_AXI_CLK>, < GCC_CRYPTO_AHB_CLK>;
clock-names = "core", "bus", "iface";
+   #reset-cells = <1>;
};
};
diff --git a/drivers/firmware/qcom_scm-32.c b/drivers/firmware/qcom_scm-32.c
index 5e00aa400c4a..41d56013f6fc 100644
--- a/drivers/firmware/qcom_scm-32.c
+++ b/drivers/firmware/qcom_scm-32.c
@@ -513,3 +513,16 @@ int __qcom_scm_pas_shutdown(struct device *dev, u32 
peripheral)
 
return ret ? : le32_to_cpu(out);
 }
+
+int __qcom_scm_pas_mss_reset(struct device *dev, bool reset)
+{
+   __le32 out;
+   __le32 in = cpu_to_le32(reset);
+   int ret;
+
+   ret = qcom_scm_call(dev, QCOM_SCM_SVC_PIL, QCOM_SCM_PAS_MSS_RESET,
+   , sizeof(in),
+   , sizeof(out));
+
+   return ret ? : le32_to_cpu(out);
+}
diff --git a/drivers/firmware/qcom_scm-64.c b/drivers/firmware/qcom_scm-64.c
index 496badd49fe8..e720100f2cb1 100644
--- a/drivers/firmware/qcom_scm-64.c
+++ b/drivers/firmware/qcom_scm-64.c
@@ -342,3 +342,20 @@ int __qcom_scm_pas_shutdown(struct device *dev, u32 
peripheral)
 
return ret ? : scm_ret;
 }
+
+int __qcom_scm_pas_mss_reset(struct device *dev, bool reset)
+{
+   struct qcom_scm_desc desc = {0};
+   u32 scm_ret;
+   int ret;
+
+   desc.args[0] = reset;
+   desc.args[1] = 0;
+   desc.arginfo = QCOM_SCM_ARGS(2);
+
+   ret = qcom_scm_call(dev, QCOM_SCM_SVC_PIL, QCOM_SCM_PAS_MSS_RESET,
+   );
+   scm_ret = desc.res.a1;
+
+   return ret ? : scm_ret;
+}
diff --git a/drivers/firmware/qcom_scm.c b/drivers/firmware/qcom_scm.c
index 79bb0b00577e..b0119535c0fb 100644
--- a/drivers/firmware/qcom_scm.c
+++ b/drivers/firmware/qcom_scm.c
@@ -21,6 +21,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include "qcom_scm.h"
 
@@ -29,6 +30,7 @@ struct qcom_scm {
struct clk *core_clk;
struct clk *iface_clk;
struct clk *bus_clk;
+   struct reset_controller_dev reset;
 };
 
 static struct qcom_scm *__scm;
@@ -283,6 +285,33 @@ int qcom_scm_pas_shutdown(u32 peripheral)
 }
 EXPORT_SYMBOL(qcom_scm_pas_shutdown);
 
+static int qcom_scm_pas_reset_assert(struct reset_controller_dev *rcdev,
+unsigned long idx)
+{
+   struct qcom_scm *scm = container_of(rcdev, struct qcom_scm, reset);
+
+   if (idx != 0)
+   return -EINVAL;
+
+   return __qcom_scm_pas_mss_reset(scm->dev, 1);
+}
+
+static int qcom_scm_pas_reset_deassert(struct reset_controller_dev *rcdev,
+  unsigned long idx)
+{
+   struct qcom_scm *scm = container_of(rcdev, struct qcom_scm, reset);
+
+   if (idx != 0)
+   return -EINVAL;
+
+   return __qcom_scm_pas_mss_reset(scm->dev, 0);
+}
+
+static struct reset_control_ops qcom_scm_pas_reset_ops = {
+   .assert = qcom_scm_pas_reset_assert,
+   .deassert = qcom_scm_pas_reset_deassert,
+};
+
 static int qcom_scm_probe(struct platform_device *pdev)
 {
struct qcom_scm *scm;
@@ -317,6 +346,11 @@ static int qcom_scm_probe(struct platform_device *pdev)
}
}
 
+   scm->reset.ops = _scm_pas_reset_ops;
+   scm->reset.nr_resets = 1;
+   scm->reset.of_node = pdev->dev.of_node;
+   reset_controller_register(>reset);
+
/* vote for max clk rate for highest performance */
ret = clk_set_rate(scm->core_clk, INT_MAX);
if (ret)
diff --git 

[PATCH] firmware: qcom: scm: Expose PAS command 10 as reset-controller

[Bjorn Andersson]

PAS command 10 is used to assert and deassert the MSS reset via
TrustZone, expose this as a reset-controller to follow the non-secure
case where GCC exposes this control.

Signed-off-by: Bjorn Andersson 
---
 .../devicetree/bindings/firmware/qcom,scm.txt  |  6 
 drivers/firmware/qcom_scm-32.c | 13 +
 drivers/firmware/qcom_scm-64.c | 17 +++
 drivers/firmware/qcom_scm.c| 34 ++
 drivers/firmware/qcom_scm.h|  2 ++
 5 files changed, 72 insertions(+)

diff --git a/Documentation/devicetree/bindings/firmware/qcom,scm.txt 
b/Documentation/devicetree/bindings/firmware/qcom,scm.txt
index 3b4436e56865..f1ae9d3871f5 100644
--- a/Documentation/devicetree/bindings/firmware/qcom,scm.txt
+++ b/Documentation/devicetree/bindings/firmware/qcom,scm.txt
@@ -17,6 +17,11 @@ Required properties:
 - clock-names: Must contain "core" for the core clock, "iface" for the 
interface
   clock and "bus" for the bus clock per the requirements of the compatible.
 
+Optional properties:
+- #reset-cells: must be 1, if specified. Specifies that the scm implements a
+  reset controller exposing the modem subsystem reset as a single reset, at
+  index 0.
+
 Example for MSM8916:
 
firmware {
@@ -24,5 +29,6 @@ Example for MSM8916:
compatible = "qcom,scm";
clocks = < GCC_CRYPTO_CLK> , < 
GCC_CRYPTO_AXI_CLK>, < GCC_CRYPTO_AHB_CLK>;
clock-names = "core", "bus", "iface";
+   #reset-cells = <1>;
};
};
diff --git a/drivers/firmware/qcom_scm-32.c b/drivers/firmware/qcom_scm-32.c
index 5e00aa400c4a..41d56013f6fc 100644
--- a/drivers/firmware/qcom_scm-32.c
+++ b/drivers/firmware/qcom_scm-32.c
@@ -513,3 +513,16 @@ int __qcom_scm_pas_shutdown(struct device *dev, u32 
peripheral)
 
return ret ? : le32_to_cpu(out);
 }
+
+int __qcom_scm_pas_mss_reset(struct device *dev, bool reset)
+{
+   __le32 out;
+   __le32 in = cpu_to_le32(reset);
+   int ret;
+
+   ret = qcom_scm_call(dev, QCOM_SCM_SVC_PIL, QCOM_SCM_PAS_MSS_RESET,
+   , sizeof(in),
+   , sizeof(out));
+
+   return ret ? : le32_to_cpu(out);
+}
diff --git a/drivers/firmware/qcom_scm-64.c b/drivers/firmware/qcom_scm-64.c
index 496badd49fe8..e720100f2cb1 100644
--- a/drivers/firmware/qcom_scm-64.c
+++ b/drivers/firmware/qcom_scm-64.c
@@ -342,3 +342,20 @@ int __qcom_scm_pas_shutdown(struct device *dev, u32 
peripheral)
 
return ret ? : scm_ret;
 }
+
+int __qcom_scm_pas_mss_reset(struct device *dev, bool reset)
+{
+   struct qcom_scm_desc desc = {0};
+   u32 scm_ret;
+   int ret;
+
+   desc.args[0] = reset;
+   desc.args[1] = 0;
+   desc.arginfo = QCOM_SCM_ARGS(2);
+
+   ret = qcom_scm_call(dev, QCOM_SCM_SVC_PIL, QCOM_SCM_PAS_MSS_RESET,
+   );
+   scm_ret = desc.res.a1;
+
+   return ret ? : scm_ret;
+}
diff --git a/drivers/firmware/qcom_scm.c b/drivers/firmware/qcom_scm.c
index 79bb0b00577e..b0119535c0fb 100644
--- a/drivers/firmware/qcom_scm.c
+++ b/drivers/firmware/qcom_scm.c
@@ -21,6 +21,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include "qcom_scm.h"
 
@@ -29,6 +30,7 @@ struct qcom_scm {
struct clk *core_clk;
struct clk *iface_clk;
struct clk *bus_clk;
+   struct reset_controller_dev reset;
 };
 
 static struct qcom_scm *__scm;
@@ -283,6 +285,33 @@ int qcom_scm_pas_shutdown(u32 peripheral)
 }
 EXPORT_SYMBOL(qcom_scm_pas_shutdown);
 
+static int qcom_scm_pas_reset_assert(struct reset_controller_dev *rcdev,
+unsigned long idx)
+{
+   struct qcom_scm *scm = container_of(rcdev, struct qcom_scm, reset);
+
+   if (idx != 0)
+   return -EINVAL;
+
+   return __qcom_scm_pas_mss_reset(scm->dev, 1);
+}
+
+static int qcom_scm_pas_reset_deassert(struct reset_controller_dev *rcdev,
+  unsigned long idx)
+{
+   struct qcom_scm *scm = container_of(rcdev, struct qcom_scm, reset);
+
+   if (idx != 0)
+   return -EINVAL;
+
+   return __qcom_scm_pas_mss_reset(scm->dev, 0);
+}
+
+static struct reset_control_ops qcom_scm_pas_reset_ops = {
+   .assert = qcom_scm_pas_reset_assert,
+   .deassert = qcom_scm_pas_reset_deassert,
+};
+
 static int qcom_scm_probe(struct platform_device *pdev)
 {
struct qcom_scm *scm;
@@ -317,6 +346,11 @@ static int qcom_scm_probe(struct platform_device *pdev)
}
}
 
+   scm->reset.ops = _scm_pas_reset_ops;
+   scm->reset.nr_resets = 1;
+   scm->reset.of_node = pdev->dev.of_node;
+   reset_controller_register(>reset);
+
/* vote for max clk rate for highest performance */
ret = clk_set_rate(scm->core_clk, INT_MAX);
if (ret)
diff --git a/drivers/firmware/qcom_scm.h 

[PATCH] ARM: zx: Fix devm_ioremap_resource error detection code

[Amitoj Kaur Chawla]

Remove unnecessary error handling after the call to
platform_get_resource and fix error handling for devm_ioremap_resource

The Coccinelle semantic patch that was used to help find this is as
follows:
@@
expression e,e1;
statement S;
@@

*e = devm_ioremap_resource(...);
if (!e1) S

Signed-off-by: Amitoj Kaur Chawla 
---
 arch/arm/mach-zx/zx296702-pm-domain.c | 11 ++-
 1 file changed, 2 insertions(+), 9 deletions(-)

diff --git a/arch/arm/mach-zx/zx296702-pm-domain.c 
b/arch/arm/mach-zx/zx296702-pm-domain.c
index e08574d..17f778b 100644
--- a/arch/arm/mach-zx/zx296702-pm-domain.c
+++ b/arch/arm/mach-zx/zx296702-pm-domain.c
@@ -163,16 +163,9 @@ static int zx296702_pd_probe(struct platform_device *pdev)
genpd_data->num_domains = ARRAY_SIZE(zx296702_pm_domains);
 
res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
-   if (!res) {
-   dev_err(>dev, "no memory resource defined\n");
-   return -ENODEV;
-   }
-
pcubase = devm_ioremap_resource(>dev, res);
-   if (!pcubase) {
-   dev_err(>dev, "ioremap fail.\n");
-   return -EIO;
-   }
+   if (IS_ERR(pcubase))
+   return PTR_ERR(pcubase);
 
for (i = 0; i < ARRAY_SIZE(zx296702_pm_domains); ++i)
pm_genpd_init(zx296702_pm_domains[i], NULL, false);
-- 
1.9.1

[PATCH] ARM: zx: Fix devm_ioremap_resource error detection code

[Amitoj Kaur Chawla]

Remove unnecessary error handling after the call to
platform_get_resource and fix error handling for devm_ioremap_resource

The Coccinelle semantic patch that was used to help find this is as
follows:
@@
expression e,e1;
statement S;
@@

*e = devm_ioremap_resource(...);
if (!e1) S

Signed-off-by: Amitoj Kaur Chawla 
---
 arch/arm/mach-zx/zx296702-pm-domain.c | 11 ++-
 1 file changed, 2 insertions(+), 9 deletions(-)

diff --git a/arch/arm/mach-zx/zx296702-pm-domain.c 
b/arch/arm/mach-zx/zx296702-pm-domain.c
index e08574d..17f778b 100644
--- a/arch/arm/mach-zx/zx296702-pm-domain.c
+++ b/arch/arm/mach-zx/zx296702-pm-domain.c
@@ -163,16 +163,9 @@ static int zx296702_pd_probe(struct platform_device *pdev)
genpd_data->num_domains = ARRAY_SIZE(zx296702_pm_domains);
 
res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
-   if (!res) {
-   dev_err(>dev, "no memory resource defined\n");
-   return -ENODEV;
-   }
-
pcubase = devm_ioremap_resource(>dev, res);
-   if (!pcubase) {
-   dev_err(>dev, "ioremap fail.\n");
-   return -EIO;
-   }
+   if (IS_ERR(pcubase))
+   return PTR_ERR(pcubase);
 
for (i = 0; i < ARRAY_SIZE(zx296702_pm_domains); ++i)
pm_genpd_init(zx296702_pm_domains[i], NULL, false);
-- 
1.9.1

[PATCH] pinctrl: xway: Change structure initialisation to c99 style

[Amitoj Kaur Chawla]

Replace the in order struct initialisation style with explicit field
style.

The Coccinelle semantic patch used to make this change is as follows:

@decl@
identifier i1,fld;
type T;
field list[n] fs;
@@

struct i1 {
 fs
 T fld;
 ...};

@@
identifier decl.i1,i2,decl.fld;
expression e;
position bad.p, bad.fix;
@@

struct i1 i2@p = { ...,
+ .fld = e
- e@fix
 ,...};

Signed-off-by: Amitoj Kaur Chawla 
---
 drivers/pinctrl/pinctrl-xway.c | 72 --
 1 file changed, 48 insertions(+), 24 deletions(-)

diff --git a/drivers/pinctrl/pinctrl-xway.c b/drivers/pinctrl/pinctrl-xway.c
index a13f2b6..dac88a2 100644
--- a/drivers/pinctrl/pinctrl-xway.c
+++ b/drivers/pinctrl/pinctrl-xway.c
@@ -1616,50 +1616,74 @@ struct pinctrl_xway_soc {
 
 /* xway xr9 series (DEPRECATED: Use XWAY xRX100/xRX200 Family) */
 static struct pinctrl_xway_soc xr9_pinctrl = {
-   XR9_MAX_PIN, xway_mfp,
-   xway_grps, ARRAY_SIZE(xway_grps),
-   xrx_funcs, ARRAY_SIZE(xrx_funcs),
-   xway_exin_pin_map, 6
+   .pin_count = XR9_MAX_PIN,
+   .mfp = xway_mfp,
+   .grps = xway_grps,
+   .num_grps = ARRAY_SIZE(xway_grps),
+   .funcs = xrx_funcs,
+   .num_funcs = ARRAY_SIZE(xrx_funcs),
+   .exin = xway_exin_pin_map,
+   .num_exin = 6
 };
 
 /* XWAY AMAZON Family */
 static struct pinctrl_xway_soc ase_pinctrl = {
-   ASE_MAX_PIN, ase_mfp,
-   ase_grps, ARRAY_SIZE(ase_grps),
-   ase_funcs, ARRAY_SIZE(ase_funcs),
-   ase_exin_pin_map, 3
+   .pin_count = ASE_MAX_PIN,
+   .mfp = ase_mfp,
+   .grps = ase_grps,
+   .num_grps = ARRAY_SIZE(ase_grps),
+   .funcs = ase_funcs,
+   .num_funcs = ARRAY_SIZE(ase_funcs),
+   .exin = ase_exin_pin_map,
+   .num_exin = 3
 };
 
 /* XWAY DANUBE Family */
 static struct pinctrl_xway_soc danube_pinctrl = {
-   DANUBE_MAX_PIN, danube_mfp,
-   danube_grps, ARRAY_SIZE(danube_grps),
-   danube_funcs, ARRAY_SIZE(danube_funcs),
-   danube_exin_pin_map, 3
+   .pin_count = DANUBE_MAX_PIN,
+   .mfp = danube_mfp,
+   .grps = danube_grps,
+   .num_grps = ARRAY_SIZE(danube_grps),
+   .funcs = danube_funcs,
+   .num_funcs = ARRAY_SIZE(danube_funcs),
+   .exin = danube_exin_pin_map,
+   .num-exin = 3
 };
 
 /* XWAY xRX100 Family */
 static struct pinctrl_xway_soc xrx100_pinctrl = {
-   XRX100_MAX_PIN, xrx100_mfp,
-   xrx100_grps, ARRAY_SIZE(xrx100_grps),
-   xrx100_funcs, ARRAY_SIZE(xrx100_funcs),
-   xrx100_exin_pin_map, 6
+   .pin_count = XRX100_MAX_PIN,
+   .mfp = xrx100_mfp,
+   .grps = xrx100_grps,
+   .num_grps = ARRAY_SIZE(xrx100_grps),
+   .funcs = xrx100_funcs,
+   .num_funcs = ARRAY_SIZE(xrx100_funcs),
+   .exin = xrx100_exin_pin_map,
+   .num_exin = 6
 };
 
 /* XWAY xRX200 Family */
 static struct pinctrl_xway_soc xrx200_pinctrl = {
-   XRX200_MAX_PIN, xrx200_mfp,
-   xrx200_grps, ARRAY_SIZE(xrx200_grps),
-   xrx200_funcs, ARRAY_SIZE(xrx200_funcs),
-   xrx200_exin_pin_map, 6
+   .pin_count = XRX200_MAX_PIN,
+   .mfp = xrx200_mfp,
+   .grps = xrx200_grps,
+   .num_grps = ARRAY_SIZE(xrx200_grps),
+   .funcs = xrx200_funcs,
+   .num_funcs = ARRAY_SIZE(xrx200_funcs),
+   .exin = xrx200_exin_pin_map,
+   .num_exin = 6
 };
 
 /* XWAY xRX300 Family */
 static struct pinctrl_xway_soc xrx300_pinctrl = {
-   XRX300_MAX_PIN, xrx300_mfp,
-   xrx300_grps, ARRAY_SIZE(xrx300_grps),
-   xrx300_funcs, ARRAY_SIZE(xrx300_funcs),
-   xrx300_exin_pin_map, 5
+   .pin_count = XRX300_MAX_PIN,
+   .mfp = xrx300_mfp,
+   .grps = xrx300_grps,
+   .num_grps = ARRAY_SIZE(xrx300_grps),
+   .funcs = xrx300_funcs,
+   .num_funcs = ARRAY_SIZE(xrx300_funcs),
+   .exin = xrx300_exin_pin_map,
+   .num_exin = 5
 };
 
 static struct pinctrl_gpio_range xway_gpio_range = {
-- 
1.9.1

[PATCH] pinctrl: xway: Change structure initialisation to c99 style

[Amitoj Kaur Chawla]

Replace the in order struct initialisation style with explicit field
style.

The Coccinelle semantic patch used to make this change is as follows:

@decl@
identifier i1,fld;
type T;
field list[n] fs;
@@

struct i1 {
 fs
 T fld;
 ...};

@@
identifier decl.i1,i2,decl.fld;
expression e;
position bad.p, bad.fix;
@@

struct i1 i2@p = { ...,
+ .fld = e
- e@fix
 ,...};

Signed-off-by: Amitoj Kaur Chawla 
---
 drivers/pinctrl/pinctrl-xway.c | 72 --
 1 file changed, 48 insertions(+), 24 deletions(-)

diff --git a/drivers/pinctrl/pinctrl-xway.c b/drivers/pinctrl/pinctrl-xway.c
index a13f2b6..dac88a2 100644
--- a/drivers/pinctrl/pinctrl-xway.c
+++ b/drivers/pinctrl/pinctrl-xway.c
@@ -1616,50 +1616,74 @@ struct pinctrl_xway_soc {
 
 /* xway xr9 series (DEPRECATED: Use XWAY xRX100/xRX200 Family) */
 static struct pinctrl_xway_soc xr9_pinctrl = {
-   XR9_MAX_PIN, xway_mfp,
-   xway_grps, ARRAY_SIZE(xway_grps),
-   xrx_funcs, ARRAY_SIZE(xrx_funcs),
-   xway_exin_pin_map, 6
+   .pin_count = XR9_MAX_PIN,
+   .mfp = xway_mfp,
+   .grps = xway_grps,
+   .num_grps = ARRAY_SIZE(xway_grps),
+   .funcs = xrx_funcs,
+   .num_funcs = ARRAY_SIZE(xrx_funcs),
+   .exin = xway_exin_pin_map,
+   .num_exin = 6
 };
 
 /* XWAY AMAZON Family */
 static struct pinctrl_xway_soc ase_pinctrl = {
-   ASE_MAX_PIN, ase_mfp,
-   ase_grps, ARRAY_SIZE(ase_grps),
-   ase_funcs, ARRAY_SIZE(ase_funcs),
-   ase_exin_pin_map, 3
+   .pin_count = ASE_MAX_PIN,
+   .mfp = ase_mfp,
+   .grps = ase_grps,
+   .num_grps = ARRAY_SIZE(ase_grps),
+   .funcs = ase_funcs,
+   .num_funcs = ARRAY_SIZE(ase_funcs),
+   .exin = ase_exin_pin_map,
+   .num_exin = 3
 };
 
 /* XWAY DANUBE Family */
 static struct pinctrl_xway_soc danube_pinctrl = {
-   DANUBE_MAX_PIN, danube_mfp,
-   danube_grps, ARRAY_SIZE(danube_grps),
-   danube_funcs, ARRAY_SIZE(danube_funcs),
-   danube_exin_pin_map, 3
+   .pin_count = DANUBE_MAX_PIN,
+   .mfp = danube_mfp,
+   .grps = danube_grps,
+   .num_grps = ARRAY_SIZE(danube_grps),
+   .funcs = danube_funcs,
+   .num_funcs = ARRAY_SIZE(danube_funcs),
+   .exin = danube_exin_pin_map,
+   .num-exin = 3
 };
 
 /* XWAY xRX100 Family */
 static struct pinctrl_xway_soc xrx100_pinctrl = {
-   XRX100_MAX_PIN, xrx100_mfp,
-   xrx100_grps, ARRAY_SIZE(xrx100_grps),
-   xrx100_funcs, ARRAY_SIZE(xrx100_funcs),
-   xrx100_exin_pin_map, 6
+   .pin_count = XRX100_MAX_PIN,
+   .mfp = xrx100_mfp,
+   .grps = xrx100_grps,
+   .num_grps = ARRAY_SIZE(xrx100_grps),
+   .funcs = xrx100_funcs,
+   .num_funcs = ARRAY_SIZE(xrx100_funcs),
+   .exin = xrx100_exin_pin_map,
+   .num_exin = 6
 };
 
 /* XWAY xRX200 Family */
 static struct pinctrl_xway_soc xrx200_pinctrl = {
-   XRX200_MAX_PIN, xrx200_mfp,
-   xrx200_grps, ARRAY_SIZE(xrx200_grps),
-   xrx200_funcs, ARRAY_SIZE(xrx200_funcs),
-   xrx200_exin_pin_map, 6
+   .pin_count = XRX200_MAX_PIN,
+   .mfp = xrx200_mfp,
+   .grps = xrx200_grps,
+   .num_grps = ARRAY_SIZE(xrx200_grps),
+   .funcs = xrx200_funcs,
+   .num_funcs = ARRAY_SIZE(xrx200_funcs),
+   .exin = xrx200_exin_pin_map,
+   .num_exin = 6
 };
 
 /* XWAY xRX300 Family */
 static struct pinctrl_xway_soc xrx300_pinctrl = {
-   XRX300_MAX_PIN, xrx300_mfp,
-   xrx300_grps, ARRAY_SIZE(xrx300_grps),
-   xrx300_funcs, ARRAY_SIZE(xrx300_funcs),
-   xrx300_exin_pin_map, 5
+   .pin_count = XRX300_MAX_PIN,
+   .mfp = xrx300_mfp,
+   .grps = xrx300_grps,
+   .num_grps = ARRAY_SIZE(xrx300_grps),
+   .funcs = xrx300_funcs,
+   .num_funcs = ARRAY_SIZE(xrx300_funcs),
+   .exin = xrx300_exin_pin_map,
+   .num_exin = 5
 };
 
 static struct pinctrl_gpio_range xway_gpio_range = {
-- 
1.9.1

Re: [PATCH 1/2] liblockdep: Fix compile errors

[Sasha Levin]

On 06/09/2016 09:34 AM, Vishal Thanki wrote:
> dfaaf3fa0: (Use __jhash_mix() for iterate_chain_key())
> Fixed by adding jhash.h with minimal stuff required

Can we, instead of copying it over, include jhash.h directly
(just like we do for hash.h)?


Thanks,
Sasha

Re: [PATCH 1/2] liblockdep: Fix compile errors

[Sasha Levin]

On 06/09/2016 09:34 AM, Vishal Thanki wrote:
> dfaaf3fa0: (Use __jhash_mix() for iterate_chain_key())
> Fixed by adding jhash.h with minimal stuff required

Can we, instead of copying it over, include jhash.h directly
(just like we do for hash.h)?


Thanks,
Sasha

RE: [PATCH v4 09/29] staging: unisys: visorinput: remove unnecessary locking

[Sell, Timothy C]

> > > > From: Thomas Gleixner [mailto:t...@linutronix.de]
> > > >
> > > > I think I asked this before, but I might have missed the answer.
> > > >
> > > > Why is this a rw_sempahore? It's never taken with down_read and
> > looking
> > > > at the usage sites it's simply a mutex, right?
> > >
> > > If the semaphore --> mutex change would have been as simple as it
> > sounds,
> > > we would have had NO problem including it with the next version (v3) of
> > this
> > > patchset.  But unfortunately, this change uncovered a latent defect,
> which
> > > necessitated yet another patch.  (I know... hard to believe that
> something
> > > this simple would do that, but it did.)  Rather than further complicating
> > this
> > > patchset, we thought it would be better to address the visorinput issues
> > via a
> > > separate follow-on patchset.
> >
> > That makes me curious. What's the issue? Functional is the mutex the
> same
> > thing as the r/w semaphore when the latter is only taken down_write and
> > locked
> > and released by the same thread, which is the case as far as I can tell.
> >
> 
> The issue: using it uninitialized ().
> 
> A semaphore appears to let you get away with it, but a mutex does NOT.
> We had to shuffle some things around to get this right.  If you're
> interested in a preview, you can find a patch in github at
> https://github.com/davidker/unisys/commit/039e6e517b4a17e2d135a9df85
> cc1e24a39c2670.
> The second bullet in that commit comment describes the scenario
> where we were attempting to access the lock in visorinput_open()
> before we had actually initialized it:
> 
>   * we canNOT get into visorinput_open() until the device
>   structure is totally  initialized, by delaying the
>   input_register_device() until the end of device initialization
> 
> I.e., before this patch, we WERE getting into visorinput_open()
> during the call to input_register_device() that was done before
> device initialization was complete, which was BEFORE we initialized
> the semaphore.
> 
> There is a 2nd follow-on patch that actually does the simple
> semaphore --> mutex conversion at
> https://github.com/davidker/unisys/commit/6f57ed62ae206c23c58ce4a016
> b08e15639ce9af.
> 
> > > Is that acceptable for you?
> >
> > Please fix it before moving the drivers out of staging.
> 
> Absolutely.  We will probably push that patchset (containing the
> 2 github patches referenced above) within the next few days,
> even if this visorbus patchset hasn't moved.
> 

The 2 patches referenced above (which include the bug fix, and the change
from semaphore to mutex) are included as patches #27 and #28 in the
patchset just submitted by David Kershner:

[PATCH RESEND 00/28] staging: unisys: fix visorbus & visorinput issues 
raised by tglx

Thanks.

Tim Sell

RE: [PATCH v4 09/29] staging: unisys: visorinput: remove unnecessary locking

[Sell, Timothy C]

> > > > From: Thomas Gleixner [mailto:t...@linutronix.de]
> > > >
> > > > I think I asked this before, but I might have missed the answer.
> > > >
> > > > Why is this a rw_sempahore? It's never taken with down_read and
> > looking
> > > > at the usage sites it's simply a mutex, right?
> > >
> > > If the semaphore --> mutex change would have been as simple as it
> > sounds,
> > > we would have had NO problem including it with the next version (v3) of
> > this
> > > patchset.  But unfortunately, this change uncovered a latent defect,
> which
> > > necessitated yet another patch.  (I know... hard to believe that
> something
> > > this simple would do that, but it did.)  Rather than further complicating
> > this
> > > patchset, we thought it would be better to address the visorinput issues
> > via a
> > > separate follow-on patchset.
> >
> > That makes me curious. What's the issue? Functional is the mutex the
> same
> > thing as the r/w semaphore when the latter is only taken down_write and
> > locked
> > and released by the same thread, which is the case as far as I can tell.
> >
> 
> The issue: using it uninitialized ().
> 
> A semaphore appears to let you get away with it, but a mutex does NOT.
> We had to shuffle some things around to get this right.  If you're
> interested in a preview, you can find a patch in github at
> https://github.com/davidker/unisys/commit/039e6e517b4a17e2d135a9df85
> cc1e24a39c2670.
> The second bullet in that commit comment describes the scenario
> where we were attempting to access the lock in visorinput_open()
> before we had actually initialized it:
> 
>   * we canNOT get into visorinput_open() until the device
>   structure is totally  initialized, by delaying the
>   input_register_device() until the end of device initialization
> 
> I.e., before this patch, we WERE getting into visorinput_open()
> during the call to input_register_device() that was done before
> device initialization was complete, which was BEFORE we initialized
> the semaphore.
> 
> There is a 2nd follow-on patch that actually does the simple
> semaphore --> mutex conversion at
> https://github.com/davidker/unisys/commit/6f57ed62ae206c23c58ce4a016
> b08e15639ce9af.
> 
> > > Is that acceptable for you?
> >
> > Please fix it before moving the drivers out of staging.
> 
> Absolutely.  We will probably push that patchset (containing the
> 2 github patches referenced above) within the next few days,
> even if this visorbus patchset hasn't moved.
> 

The 2 patches referenced above (which include the bug fix, and the change
from semaphore to mutex) are included as patches #27 and #28 in the
patchset just submitted by David Kershner:

[PATCH RESEND 00/28] staging: unisys: fix visorbus & visorinput issues 
raised by tglx

Thanks.

Tim Sell

[PATCH 3/3] drivers: Add visorbus to the drivers/virt directory

[David Kershner]

visorbus is currently located at drivers/staging/visorbus,
this patch moves it to drivers/virt.

Signed-off-by: David Kershner 
Reviewed-by: Tim Sell 
---
 drivers/staging/unisys/Kconfig| 3 +--
 drivers/staging/unisys/Makefile   | 1 -
 drivers/virt/Kconfig  | 2 ++
 drivers/virt/Makefile | 1 +
 drivers/{staging/unisys => virt}/visorbus/Kconfig | 0
 drivers/{staging/unisys => virt}/visorbus/Makefile| 0
 drivers/{staging/unisys => virt}/visorbus/controlvmchannel.h  | 0
 drivers/{staging/unisys => virt}/visorbus/controlvmcompletionstatus.h | 0
 drivers/{staging/unisys => virt}/visorbus/iovmcall_gnuc.h | 0
 drivers/{staging/unisys => virt}/visorbus/vbuschannel.h   | 0
 drivers/{staging/unisys => virt}/visorbus/vbusdeviceinfo.h| 0
 drivers/{staging/unisys => virt}/visorbus/vbushelper.h| 0
 drivers/{staging/unisys => virt}/visorbus/visorbus_main.c | 0
 drivers/{staging/unisys => virt}/visorbus/visorbus_private.h  | 0
 drivers/{staging/unisys => virt}/visorbus/visorchannel.c  | 0
 drivers/{staging/unisys => virt}/visorbus/visorchipset.c  | 0
 drivers/{staging/unisys => virt}/visorbus/vmcallinterface.h   | 0
 17 files changed, 4 insertions(+), 3 deletions(-)
 rename drivers/{staging/unisys => virt}/visorbus/Kconfig (100%)
 rename drivers/{staging/unisys => virt}/visorbus/Makefile (100%)
 rename drivers/{staging/unisys => virt}/visorbus/controlvmchannel.h (100%)
 rename drivers/{staging/unisys => virt}/visorbus/controlvmcompletionstatus.h 
(100%)
 rename drivers/{staging/unisys => virt}/visorbus/iovmcall_gnuc.h (100%)
 rename drivers/{staging/unisys => virt}/visorbus/vbuschannel.h (100%)
 rename drivers/{staging/unisys => virt}/visorbus/vbusdeviceinfo.h (100%)
 rename drivers/{staging/unisys => virt}/visorbus/vbushelper.h (100%)
 rename drivers/{staging/unisys => virt}/visorbus/visorbus_main.c (100%)
 rename drivers/{staging/unisys => virt}/visorbus/visorbus_private.h (100%)
 rename drivers/{staging/unisys => virt}/visorbus/visorchannel.c (100%)
 rename drivers/{staging/unisys => virt}/visorbus/visorchipset.c (100%)
 rename drivers/{staging/unisys => virt}/visorbus/vmcallinterface.h (100%)

diff --git a/drivers/staging/unisys/Kconfig b/drivers/staging/unisys/Kconfig
index 4f1f5e6..dab09a9 100644
--- a/drivers/staging/unisys/Kconfig
+++ b/drivers/staging/unisys/Kconfig
@@ -3,7 +3,7 @@
 #
 menuconfig UNISYSSPAR
bool "Unisys SPAR driver support"
-   depends on X86_64 && !UML
+   depends on X86_64 && !UML && VIRT_DRIVERS
select PCI
select ACPI
---help---
@@ -11,7 +11,6 @@ menuconfig UNISYSSPAR
 
 if UNISYSSPAR
 
-source "drivers/staging/unisys/visorbus/Kconfig"
 source "drivers/staging/unisys/visornic/Kconfig"
 source "drivers/staging/unisys/visorinput/Kconfig"
 source "drivers/staging/unisys/visorhba/Kconfig"
diff --git a/drivers/staging/unisys/Makefile b/drivers/staging/unisys/Makefile
index 20eb098..e45f44b 100644
--- a/drivers/staging/unisys/Makefile
+++ b/drivers/staging/unisys/Makefile
@@ -1,7 +1,6 @@
 #
 # Makefile for Unisys SPAR drivers
 #
-obj-$(CONFIG_UNISYS_VISORBUS)  += visorbus/
 obj-$(CONFIG_UNISYS_VISORNIC)  += visornic/
 obj-$(CONFIG_UNISYS_VISORINPUT)+= visorinput/
 obj-$(CONFIG_UNISYS_VISORHBA)  += visorhba/
diff --git a/drivers/virt/Kconfig b/drivers/virt/Kconfig
index 99ebdde..0c60896 100644
--- a/drivers/virt/Kconfig
+++ b/drivers/virt/Kconfig
@@ -30,4 +30,6 @@ config FSL_HV_MANAGER
   4) A kernel interface for receiving callbacks when a managed
 partition shuts down.
 
+source "drivers/virt/visorbus/Kconfig"
 endif
+
diff --git a/drivers/virt/Makefile b/drivers/virt/Makefile
index c47f04d..44aebd2 100644
--- a/drivers/virt/Makefile
+++ b/drivers/virt/Makefile
@@ -3,3 +3,4 @@
 #
 
 obj-$(CONFIG_FSL_HV_MANAGER)   += fsl_hypervisor.o
+obj-$(CONFIG_UNISYS_VISORBUS)  += visorbus/
diff --git a/drivers/staging/unisys/visorbus/Kconfig 
b/drivers/virt/visorbus/Kconfig
similarity index 100%
rename from drivers/staging/unisys/visorbus/Kconfig
rename to drivers/virt/visorbus/Kconfig
diff --git a/drivers/staging/unisys/visorbus/Makefile 
b/drivers/virt/visorbus/Makefile
similarity index 100%
rename from drivers/staging/unisys/visorbus/Makefile
rename to drivers/virt/visorbus/Makefile
diff --git a/drivers/staging/unisys/visorbus/controlvmchannel.h 
b/drivers/virt/visorbus/controlvmchannel.h
similarity index 100%
rename from drivers/staging/unisys/visorbus/controlvmchannel.h
rename to drivers/virt/visorbus/controlvmchannel.h
diff --git a/drivers/staging/unisys/visorbus/controlvmcompletionstatus.h 

[PATCH 1/3] include: linux: visorbus: Add visorbus to include/linux directory

[David Kershner]

Update include/linux to include the s-Par associated common include
header files needed for the s-Par visorbus.

Since we have now moved the include directories over to
include/linux/visorbus this patch makes all of the visor
drivers visorbus, visorinput, visornic, and visorhba use
the new include folders.

Signed-off-by: David Kershner 
Reviewed-by: Tim Sell 
---
 drivers/staging/unisys/MAINTAINERS| 2 +-
 drivers/staging/unisys/visorbus/Makefile  | 2 --
 drivers/staging/unisys/visorbus/controlvmchannel.h| 2 +-
 drivers/staging/unisys/visorbus/vbuschannel.h | 3 ++-
 drivers/staging/unisys/visorbus/visorbus_main.c   | 6 +++---
 drivers/staging/unisys/visorbus/visorchannel.c| 4 ++--
 drivers/staging/unisys/visorbus/visorchipset.c| 8 
 drivers/staging/unisys/visorbus/vmcallinterface.h | 5 ++---
 drivers/staging/unisys/visorhba/Makefile  | 2 --
 drivers/staging/unisys/visorhba/visorhba_main.c   | 5 ++---
 drivers/staging/unisys/visorinput/Makefile| 2 --
 drivers/staging/unisys/visorinput/visorinput.c| 6 +++---
 drivers/staging/unisys/visornic/Makefile  | 2 --
 drivers/staging/unisys/visornic/visornic_main.c   | 5 ++---
 .../staging/unisys/include => include/linux/visorbus}/channel.h   | 0
 .../unisys/include => include/linux/visorbus}/channel_guid.h  | 0
 .../unisys/include => include/linux/visorbus}/diagchannel.h   | 0
 .../unisys/include => include/linux/visorbus}/guestlinuxdebug.h   | 0
 .../staging/unisys/include => include/linux/visorbus}/iochannel.h | 0
 .../staging/unisys/include => include/linux/visorbus}/version.h   | 0
 .../staging/unisys/include => include/linux/visorbus}/visorbus.h  | 0
 21 files changed, 22 insertions(+), 32 deletions(-)
 rename {drivers/staging/unisys/include => include/linux/visorbus}/channel.h 
(100%)
 rename {drivers/staging/unisys/include => 
include/linux/visorbus}/channel_guid.h (100%)
 rename {drivers/staging/unisys/include => 
include/linux/visorbus}/diagchannel.h (100%)
 rename {drivers/staging/unisys/include => 
include/linux/visorbus}/guestlinuxdebug.h (100%)
 rename {drivers/staging/unisys/include => include/linux/visorbus}/iochannel.h 
(100%)
 rename {drivers/staging/unisys/include => include/linux/visorbus}/version.h 
(100%)
 rename {drivers/staging/unisys/include => include/linux/visorbus}/visorbus.h 
(100%)

diff --git a/drivers/staging/unisys/MAINTAINERS 
b/drivers/staging/unisys/MAINTAINERS
index 1f0425b..146a8c3 100644
--- a/drivers/staging/unisys/MAINTAINERS
+++ b/drivers/staging/unisys/MAINTAINERS
@@ -1,5 +1,5 @@
 Unisys s-Par drivers
 M: David Kershner 
 S: Maintained
-F: Documentation/s-Par/overview.txt
+F: Documentation/visorbus.txt
 F: drivers/staging/unisys/
diff --git a/drivers/staging/unisys/visorbus/Makefile 
b/drivers/staging/unisys/visorbus/Makefile
index f3730d8..7f328cc 100644
--- a/drivers/staging/unisys/visorbus/Makefile
+++ b/drivers/staging/unisys/visorbus/Makefile
@@ -7,5 +7,3 @@ obj-$(CONFIG_UNISYS_VISORBUS)   += visorbus.o
 visorbus-y := visorbus_main.o
 visorbus-y += visorchannel.o
 visorbus-y += visorchipset.o
-
-ccflags-y += -Idrivers/staging/unisys/include
diff --git a/drivers/staging/unisys/visorbus/controlvmchannel.h 
b/drivers/staging/unisys/visorbus/controlvmchannel.h
index 03e36fb..0a0e221 100644
--- a/drivers/staging/unisys/visorbus/controlvmchannel.h
+++ b/drivers/staging/unisys/visorbus/controlvmchannel.h
@@ -16,7 +16,7 @@
 #define __CONTROLVMCHANNEL_H__
 
 #include 
-#include "channel.h"
+#include 
 
 /* {2B3C2D10-7EF5-4ad8-B966-3448B7386B3D} */
 #define SPAR_CONTROLVM_CHANNEL_PROTOCOL_UUID   \
diff --git a/drivers/staging/unisys/visorbus/vbuschannel.h 
b/drivers/staging/unisys/visorbus/vbuschannel.h
index 90fa12e..3e0388d 100644
--- a/drivers/staging/unisys/visorbus/vbuschannel.h
+++ b/drivers/staging/unisys/visorbus/vbuschannel.h
@@ -23,8 +23,9 @@
  *  the client devices and client drivers for the server end to see.
  */
 #include 
+#include 
+
 #include "vbusdeviceinfo.h"
-#include "channel.h"
 
 /* {193b331b-c58f-11da-95a9-00e08161165f} */
 #define SPAR_VBUS_CHANNEL_PROTOCOL_UUID \
diff --git a/drivers/staging/unisys/visorbus/visorbus_main.c 
b/drivers/staging/unisys/visorbus/visorbus_main.c
index 293532f..2af051c 100644
--- a/drivers/staging/unisys/visorbus/visorbus_main.c
+++ b/drivers/staging/unisys/visorbus/visorbus_main.c
@@ -16,11 +16,11 @@
 
 #include 
 
-#include "visorbus.h"
+#include 
+#include 
+#include 
 #include "visorbus_private.h"
-#include "version.h"
 #include "vbuschannel.h"
-#include "guestlinuxdebug.h"
 #include "vmcallinterface.h"
 
 #define MYDRVNAME "visorbus"
diff --git 

[PATCH 3/3] drivers: Add visorbus to the drivers/virt directory

[David Kershner]

visorbus is currently located at drivers/staging/visorbus,
this patch moves it to drivers/virt.

Signed-off-by: David Kershner 
Reviewed-by: Tim Sell 
---
 drivers/staging/unisys/Kconfig| 3 +--
 drivers/staging/unisys/Makefile   | 1 -
 drivers/virt/Kconfig  | 2 ++
 drivers/virt/Makefile | 1 +
 drivers/{staging/unisys => virt}/visorbus/Kconfig | 0
 drivers/{staging/unisys => virt}/visorbus/Makefile| 0
 drivers/{staging/unisys => virt}/visorbus/controlvmchannel.h  | 0
 drivers/{staging/unisys => virt}/visorbus/controlvmcompletionstatus.h | 0
 drivers/{staging/unisys => virt}/visorbus/iovmcall_gnuc.h | 0
 drivers/{staging/unisys => virt}/visorbus/vbuschannel.h   | 0
 drivers/{staging/unisys => virt}/visorbus/vbusdeviceinfo.h| 0
 drivers/{staging/unisys => virt}/visorbus/vbushelper.h| 0
 drivers/{staging/unisys => virt}/visorbus/visorbus_main.c | 0
 drivers/{staging/unisys => virt}/visorbus/visorbus_private.h  | 0
 drivers/{staging/unisys => virt}/visorbus/visorchannel.c  | 0
 drivers/{staging/unisys => virt}/visorbus/visorchipset.c  | 0
 drivers/{staging/unisys => virt}/visorbus/vmcallinterface.h   | 0
 17 files changed, 4 insertions(+), 3 deletions(-)
 rename drivers/{staging/unisys => virt}/visorbus/Kconfig (100%)
 rename drivers/{staging/unisys => virt}/visorbus/Makefile (100%)
 rename drivers/{staging/unisys => virt}/visorbus/controlvmchannel.h (100%)
 rename drivers/{staging/unisys => virt}/visorbus/controlvmcompletionstatus.h 
(100%)
 rename drivers/{staging/unisys => virt}/visorbus/iovmcall_gnuc.h (100%)
 rename drivers/{staging/unisys => virt}/visorbus/vbuschannel.h (100%)
 rename drivers/{staging/unisys => virt}/visorbus/vbusdeviceinfo.h (100%)
 rename drivers/{staging/unisys => virt}/visorbus/vbushelper.h (100%)
 rename drivers/{staging/unisys => virt}/visorbus/visorbus_main.c (100%)
 rename drivers/{staging/unisys => virt}/visorbus/visorbus_private.h (100%)
 rename drivers/{staging/unisys => virt}/visorbus/visorchannel.c (100%)
 rename drivers/{staging/unisys => virt}/visorbus/visorchipset.c (100%)
 rename drivers/{staging/unisys => virt}/visorbus/vmcallinterface.h (100%)

diff --git a/drivers/staging/unisys/Kconfig b/drivers/staging/unisys/Kconfig
index 4f1f5e6..dab09a9 100644
--- a/drivers/staging/unisys/Kconfig
+++ b/drivers/staging/unisys/Kconfig
@@ -3,7 +3,7 @@
 #
 menuconfig UNISYSSPAR
bool "Unisys SPAR driver support"
-   depends on X86_64 && !UML
+   depends on X86_64 && !UML && VIRT_DRIVERS
select PCI
select ACPI
---help---
@@ -11,7 +11,6 @@ menuconfig UNISYSSPAR
 
 if UNISYSSPAR
 
-source "drivers/staging/unisys/visorbus/Kconfig"
 source "drivers/staging/unisys/visornic/Kconfig"
 source "drivers/staging/unisys/visorinput/Kconfig"
 source "drivers/staging/unisys/visorhba/Kconfig"
diff --git a/drivers/staging/unisys/Makefile b/drivers/staging/unisys/Makefile
index 20eb098..e45f44b 100644
--- a/drivers/staging/unisys/Makefile
+++ b/drivers/staging/unisys/Makefile
@@ -1,7 +1,6 @@
 #
 # Makefile for Unisys SPAR drivers
 #
-obj-$(CONFIG_UNISYS_VISORBUS)  += visorbus/
 obj-$(CONFIG_UNISYS_VISORNIC)  += visornic/
 obj-$(CONFIG_UNISYS_VISORINPUT)+= visorinput/
 obj-$(CONFIG_UNISYS_VISORHBA)  += visorhba/
diff --git a/drivers/virt/Kconfig b/drivers/virt/Kconfig
index 99ebdde..0c60896 100644
--- a/drivers/virt/Kconfig
+++ b/drivers/virt/Kconfig
@@ -30,4 +30,6 @@ config FSL_HV_MANAGER
   4) A kernel interface for receiving callbacks when a managed
 partition shuts down.
 
+source "drivers/virt/visorbus/Kconfig"
 endif
+
diff --git a/drivers/virt/Makefile b/drivers/virt/Makefile
index c47f04d..44aebd2 100644
--- a/drivers/virt/Makefile
+++ b/drivers/virt/Makefile
@@ -3,3 +3,4 @@
 #
 
 obj-$(CONFIG_FSL_HV_MANAGER)   += fsl_hypervisor.o
+obj-$(CONFIG_UNISYS_VISORBUS)  += visorbus/
diff --git a/drivers/staging/unisys/visorbus/Kconfig 
b/drivers/virt/visorbus/Kconfig
similarity index 100%
rename from drivers/staging/unisys/visorbus/Kconfig
rename to drivers/virt/visorbus/Kconfig
diff --git a/drivers/staging/unisys/visorbus/Makefile 
b/drivers/virt/visorbus/Makefile
similarity index 100%
rename from drivers/staging/unisys/visorbus/Makefile
rename to drivers/virt/visorbus/Makefile
diff --git a/drivers/staging/unisys/visorbus/controlvmchannel.h 
b/drivers/virt/visorbus/controlvmchannel.h
similarity index 100%
rename from drivers/staging/unisys/visorbus/controlvmchannel.h
rename to drivers/virt/visorbus/controlvmchannel.h
diff --git a/drivers/staging/unisys/visorbus/controlvmcompletionstatus.h 
b/drivers/virt/visorbus/controlvmcompletionstatus.h
similarity index 100%
rename from 

[PATCH 1/3] include: linux: visorbus: Add visorbus to include/linux directory

[David Kershner]

Update include/linux to include the s-Par associated common include
header files needed for the s-Par visorbus.

Since we have now moved the include directories over to
include/linux/visorbus this patch makes all of the visor
drivers visorbus, visorinput, visornic, and visorhba use
the new include folders.

Signed-off-by: David Kershner 
Reviewed-by: Tim Sell 
---
 drivers/staging/unisys/MAINTAINERS| 2 +-
 drivers/staging/unisys/visorbus/Makefile  | 2 --
 drivers/staging/unisys/visorbus/controlvmchannel.h| 2 +-
 drivers/staging/unisys/visorbus/vbuschannel.h | 3 ++-
 drivers/staging/unisys/visorbus/visorbus_main.c   | 6 +++---
 drivers/staging/unisys/visorbus/visorchannel.c| 4 ++--
 drivers/staging/unisys/visorbus/visorchipset.c| 8 
 drivers/staging/unisys/visorbus/vmcallinterface.h | 5 ++---
 drivers/staging/unisys/visorhba/Makefile  | 2 --
 drivers/staging/unisys/visorhba/visorhba_main.c   | 5 ++---
 drivers/staging/unisys/visorinput/Makefile| 2 --
 drivers/staging/unisys/visorinput/visorinput.c| 6 +++---
 drivers/staging/unisys/visornic/Makefile  | 2 --
 drivers/staging/unisys/visornic/visornic_main.c   | 5 ++---
 .../staging/unisys/include => include/linux/visorbus}/channel.h   | 0
 .../unisys/include => include/linux/visorbus}/channel_guid.h  | 0
 .../unisys/include => include/linux/visorbus}/diagchannel.h   | 0
 .../unisys/include => include/linux/visorbus}/guestlinuxdebug.h   | 0
 .../staging/unisys/include => include/linux/visorbus}/iochannel.h | 0
 .../staging/unisys/include => include/linux/visorbus}/version.h   | 0
 .../staging/unisys/include => include/linux/visorbus}/visorbus.h  | 0
 21 files changed, 22 insertions(+), 32 deletions(-)
 rename {drivers/staging/unisys/include => include/linux/visorbus}/channel.h 
(100%)
 rename {drivers/staging/unisys/include => 
include/linux/visorbus}/channel_guid.h (100%)
 rename {drivers/staging/unisys/include => 
include/linux/visorbus}/diagchannel.h (100%)
 rename {drivers/staging/unisys/include => 
include/linux/visorbus}/guestlinuxdebug.h (100%)
 rename {drivers/staging/unisys/include => include/linux/visorbus}/iochannel.h 
(100%)
 rename {drivers/staging/unisys/include => include/linux/visorbus}/version.h 
(100%)
 rename {drivers/staging/unisys/include => include/linux/visorbus}/visorbus.h 
(100%)

diff --git a/drivers/staging/unisys/MAINTAINERS 
b/drivers/staging/unisys/MAINTAINERS
index 1f0425b..146a8c3 100644
--- a/drivers/staging/unisys/MAINTAINERS
+++ b/drivers/staging/unisys/MAINTAINERS
@@ -1,5 +1,5 @@
 Unisys s-Par drivers
 M: David Kershner 
 S: Maintained
-F: Documentation/s-Par/overview.txt
+F: Documentation/visorbus.txt
 F: drivers/staging/unisys/
diff --git a/drivers/staging/unisys/visorbus/Makefile 
b/drivers/staging/unisys/visorbus/Makefile
index f3730d8..7f328cc 100644
--- a/drivers/staging/unisys/visorbus/Makefile
+++ b/drivers/staging/unisys/visorbus/Makefile
@@ -7,5 +7,3 @@ obj-$(CONFIG_UNISYS_VISORBUS)   += visorbus.o
 visorbus-y := visorbus_main.o
 visorbus-y += visorchannel.o
 visorbus-y += visorchipset.o
-
-ccflags-y += -Idrivers/staging/unisys/include
diff --git a/drivers/staging/unisys/visorbus/controlvmchannel.h 
b/drivers/staging/unisys/visorbus/controlvmchannel.h
index 03e36fb..0a0e221 100644
--- a/drivers/staging/unisys/visorbus/controlvmchannel.h
+++ b/drivers/staging/unisys/visorbus/controlvmchannel.h
@@ -16,7 +16,7 @@
 #define __CONTROLVMCHANNEL_H__
 
 #include 
-#include "channel.h"
+#include 
 
 /* {2B3C2D10-7EF5-4ad8-B966-3448B7386B3D} */
 #define SPAR_CONTROLVM_CHANNEL_PROTOCOL_UUID   \
diff --git a/drivers/staging/unisys/visorbus/vbuschannel.h 
b/drivers/staging/unisys/visorbus/vbuschannel.h
index 90fa12e..3e0388d 100644
--- a/drivers/staging/unisys/visorbus/vbuschannel.h
+++ b/drivers/staging/unisys/visorbus/vbuschannel.h
@@ -23,8 +23,9 @@
  *  the client devices and client drivers for the server end to see.
  */
 #include 
+#include 
+
 #include "vbusdeviceinfo.h"
-#include "channel.h"
 
 /* {193b331b-c58f-11da-95a9-00e08161165f} */
 #define SPAR_VBUS_CHANNEL_PROTOCOL_UUID \
diff --git a/drivers/staging/unisys/visorbus/visorbus_main.c 
b/drivers/staging/unisys/visorbus/visorbus_main.c
index 293532f..2af051c 100644
--- a/drivers/staging/unisys/visorbus/visorbus_main.c
+++ b/drivers/staging/unisys/visorbus/visorbus_main.c
@@ -16,11 +16,11 @@
 
 #include 
 
-#include "visorbus.h"
+#include 
+#include 
+#include 
 #include "visorbus_private.h"
-#include "version.h"
 #include "vbuschannel.h"
-#include "guestlinuxdebug.h"
 #include "vmcallinterface.h"
 
 #define MYDRVNAME "visorbus"
diff --git a/drivers/staging/unisys/visorbus/visorchannel.c 
b/drivers/staging/unisys/visorbus/visorchannel.c
index 

[PATCH 2/3] Documentation: Move visorbus documentation from staging to Documentation/

[David Kershner]

This patch simple does a git mv of the
drivers/staging/unisys/Documentation directory to Documentation. Renames
overview.txt to visorbus.txt and renames sysfs-platform-visorchipset to
the correct name sysfs-bus-visorbus.

Signed-off-by: David Kershner 
Reviewed-by: Tim Sell 
---
 .../ABI/stable/sysfs-bus-visorbus | 0
 .../unisys/Documentation/overview.txt => Documentation/visorbus.txt   | 0
 2 files changed, 0 insertions(+), 0 deletions(-)
 rename drivers/staging/unisys/Documentation/ABI/sysfs-platform-visorchipset => 
Documentation/ABI/stable/sysfs-bus-visorbus (100%)
 rename drivers/staging/unisys/Documentation/overview.txt => 
Documentation/visorbus.txt (100%)

diff --git 
a/drivers/staging/unisys/Documentation/ABI/sysfs-platform-visorchipset 
b/Documentation/ABI/stable/sysfs-bus-visorbus
similarity index 100%
rename from drivers/staging/unisys/Documentation/ABI/sysfs-platform-visorchipset
rename to Documentation/ABI/stable/sysfs-bus-visorbus
diff --git a/drivers/staging/unisys/Documentation/overview.txt 
b/Documentation/visorbus.txt
similarity index 100%
rename from drivers/staging/unisys/Documentation/overview.txt
rename to Documentation/visorbus.txt
-- 
1.9.1

[PATCH 2/3] Documentation: Move visorbus documentation from staging to Documentation/

[David Kershner]

This patch simple does a git mv of the
drivers/staging/unisys/Documentation directory to Documentation. Renames
overview.txt to visorbus.txt and renames sysfs-platform-visorchipset to
the correct name sysfs-bus-visorbus.

Signed-off-by: David Kershner 
Reviewed-by: Tim Sell 
---
 .../ABI/stable/sysfs-bus-visorbus | 0
 .../unisys/Documentation/overview.txt => Documentation/visorbus.txt   | 0
 2 files changed, 0 insertions(+), 0 deletions(-)
 rename drivers/staging/unisys/Documentation/ABI/sysfs-platform-visorchipset => 
Documentation/ABI/stable/sysfs-bus-visorbus (100%)
 rename drivers/staging/unisys/Documentation/overview.txt => 
Documentation/visorbus.txt (100%)

diff --git 
a/drivers/staging/unisys/Documentation/ABI/sysfs-platform-visorchipset 
b/Documentation/ABI/stable/sysfs-bus-visorbus
similarity index 100%
rename from drivers/staging/unisys/Documentation/ABI/sysfs-platform-visorchipset
rename to Documentation/ABI/stable/sysfs-bus-visorbus
diff --git a/drivers/staging/unisys/Documentation/overview.txt 
b/Documentation/visorbus.txt
similarity index 100%
rename from drivers/staging/unisys/Documentation/overview.txt
rename to Documentation/visorbus.txt
-- 
1.9.1

[PATCH 0/3] move visorbus out of staging to drivers/virt/visorbus

[David Kershner]

This patchset is dependent on the previously-submitted patchset:

staging: unisys: fix visorbus & visorinput issues raised by tglx

This patchset moves drivers/staging/unisys/include to
include/linux/visorbus, and moves drivers/staging/unisys/visorbus to
drivers/virt/visorbus.

This patchset comprises the last 3 patches of the previously-submitted
patchset (but retracted):

[PATCH v4 00/29] Fixed issues raised by tglx,
 then move visorbus to drivers/virt


David Kershner (3):
  include: linux: visorbus: Add visorbus to include/linux directory
  Documentation: Move visorbus documentation from staging to
Documentation/
  drivers: Add visorbus to the drivers/virt directory

 .../ABI/stable/sysfs-bus-visorbus |  0
 .../Documentation/overview.txt => Documentation/visorbus.txt  |  0
 drivers/staging/unisys/Kconfig|  3 +--
 drivers/staging/unisys/MAINTAINERS|  2 +-
 drivers/staging/unisys/Makefile   |  1 -
 drivers/staging/unisys/visorbus/Makefile  | 11 ---
 drivers/staging/unisys/visorhba/Makefile  |  2 --
 drivers/staging/unisys/visorhba/visorhba_main.c   |  5 ++---
 drivers/staging/unisys/visorinput/Makefile|  2 --
 drivers/staging/unisys/visorinput/visorinput.c|  6 +++---
 drivers/staging/unisys/visornic/Makefile  |  2 --
 drivers/staging/unisys/visornic/visornic_main.c   |  5 ++---
 drivers/virt/Kconfig  |  2 ++
 drivers/virt/Makefile |  1 +
 drivers/{staging/unisys => virt}/visorbus/Kconfig |  0
 drivers/virt/visorbus/Makefile|  9 +
 drivers/{staging/unisys => virt}/visorbus/controlvmchannel.h  |  2 +-
 .../unisys => virt}/visorbus/controlvmcompletionstatus.h  |  0
 drivers/{staging/unisys => virt}/visorbus/iovmcall_gnuc.h |  0
 drivers/{staging/unisys => virt}/visorbus/vbuschannel.h   |  3 ++-
 drivers/{staging/unisys => virt}/visorbus/vbusdeviceinfo.h|  0
 drivers/{staging/unisys => virt}/visorbus/vbushelper.h|  0
 drivers/{staging/unisys => virt}/visorbus/visorbus_main.c |  6 +++---
 drivers/{staging/unisys => virt}/visorbus/visorbus_private.h  |  0
 drivers/{staging/unisys => virt}/visorbus/visorchannel.c  |  4 ++--
 drivers/{staging/unisys => virt}/visorbus/visorchipset.c  |  8 
 drivers/{staging/unisys => virt}/visorbus/vmcallinterface.h   |  5 ++---
 .../unisys/include => include/linux/visorbus}/channel.h   |  0
 .../unisys/include => include/linux/visorbus}/channel_guid.h  |  0
 .../unisys/include => include/linux/visorbus}/diagchannel.h   |  0
 .../include => include/linux/visorbus}/guestlinuxdebug.h  |  0
 .../unisys/include => include/linux/visorbus}/iochannel.h |  0
 .../unisys/include => include/linux/visorbus}/version.h   |  0
 .../unisys/include => include/linux/visorbus}/visorbus.h  |  0
 34 files changed, 35 insertions(+), 44 deletions(-)
 rename drivers/staging/unisys/Documentation/ABI/sysfs-platform-visorchipset => 
Documentation/ABI/stable/sysfs-bus-visorbus (100%)
 rename drivers/staging/unisys/Documentation/overview.txt => 
Documentation/visorbus.txt (100%)
 delete mode 100644 drivers/staging/unisys/visorbus/Makefile
 rename drivers/{staging/unisys => virt}/visorbus/Kconfig (100%)
 create mode 100644 drivers/virt/visorbus/Makefile
 rename drivers/{staging/unisys => virt}/visorbus/controlvmchannel.h (99%)
 rename drivers/{staging/unisys => virt}/visorbus/controlvmcompletionstatus.h 
(100%)
 rename drivers/{staging/unisys => virt}/visorbus/iovmcall_gnuc.h (100%)
 rename drivers/{staging/unisys => virt}/visorbus/vbuschannel.h (99%)
 rename drivers/{staging/unisys => virt}/visorbus/vbusdeviceinfo.h (100%)
 rename drivers/{staging/unisys => virt}/visorbus/vbushelper.h (100%)
 rename drivers/{staging/unisys => virt}/visorbus/visorbus_main.c (99%)
 rename drivers/{staging/unisys => virt}/visorbus/visorbus_private.h (100%)
 rename drivers/{staging/unisys => virt}/visorbus/visorchannel.c (99%)
 rename drivers/{staging/unisys => virt}/visorbus/visorchipset.c (99%)
 rename drivers/{staging/unisys => virt}/visorbus/vmcallinterface.h (98%)
 rename {drivers/staging/unisys/include => include/linux/visorbus}/channel.h 
(100%)
 rename {drivers/staging/unisys/include => 
include/linux/visorbus}/channel_guid.h (100%)
 rename {drivers/staging/unisys/include => 
include/linux/visorbus}/diagchannel.h (100%)
 rename {drivers/staging/unisys/include => 
include/linux/visorbus}/guestlinuxdebug.h (100%)
 rename {drivers/staging/unisys/include => include/linux/visorbus}/iochannel.h 
(100%)
 rename {drivers/staging/unisys/include => include/linux/visorbus}/version.h 
(100%)
 rename {drivers/staging/unisys/include => 

[PATCH 0/3] move visorbus out of staging to drivers/virt/visorbus

[David Kershner]

This patchset is dependent on the previously-submitted patchset:

staging: unisys: fix visorbus & visorinput issues raised by tglx

This patchset moves drivers/staging/unisys/include to
include/linux/visorbus, and moves drivers/staging/unisys/visorbus to
drivers/virt/visorbus.

This patchset comprises the last 3 patches of the previously-submitted
patchset (but retracted):

[PATCH v4 00/29] Fixed issues raised by tglx,
 then move visorbus to drivers/virt


David Kershner (3):
  include: linux: visorbus: Add visorbus to include/linux directory
  Documentation: Move visorbus documentation from staging to
Documentation/
  drivers: Add visorbus to the drivers/virt directory

 .../ABI/stable/sysfs-bus-visorbus |  0
 .../Documentation/overview.txt => Documentation/visorbus.txt  |  0
 drivers/staging/unisys/Kconfig|  3 +--
 drivers/staging/unisys/MAINTAINERS|  2 +-
 drivers/staging/unisys/Makefile   |  1 -
 drivers/staging/unisys/visorbus/Makefile  | 11 ---
 drivers/staging/unisys/visorhba/Makefile  |  2 --
 drivers/staging/unisys/visorhba/visorhba_main.c   |  5 ++---
 drivers/staging/unisys/visorinput/Makefile|  2 --
 drivers/staging/unisys/visorinput/visorinput.c|  6 +++---
 drivers/staging/unisys/visornic/Makefile  |  2 --
 drivers/staging/unisys/visornic/visornic_main.c   |  5 ++---
 drivers/virt/Kconfig  |  2 ++
 drivers/virt/Makefile |  1 +
 drivers/{staging/unisys => virt}/visorbus/Kconfig |  0
 drivers/virt/visorbus/Makefile|  9 +
 drivers/{staging/unisys => virt}/visorbus/controlvmchannel.h  |  2 +-
 .../unisys => virt}/visorbus/controlvmcompletionstatus.h  |  0
 drivers/{staging/unisys => virt}/visorbus/iovmcall_gnuc.h |  0
 drivers/{staging/unisys => virt}/visorbus/vbuschannel.h   |  3 ++-
 drivers/{staging/unisys => virt}/visorbus/vbusdeviceinfo.h|  0
 drivers/{staging/unisys => virt}/visorbus/vbushelper.h|  0
 drivers/{staging/unisys => virt}/visorbus/visorbus_main.c |  6 +++---
 drivers/{staging/unisys => virt}/visorbus/visorbus_private.h  |  0
 drivers/{staging/unisys => virt}/visorbus/visorchannel.c  |  4 ++--
 drivers/{staging/unisys => virt}/visorbus/visorchipset.c  |  8 
 drivers/{staging/unisys => virt}/visorbus/vmcallinterface.h   |  5 ++---
 .../unisys/include => include/linux/visorbus}/channel.h   |  0
 .../unisys/include => include/linux/visorbus}/channel_guid.h  |  0
 .../unisys/include => include/linux/visorbus}/diagchannel.h   |  0
 .../include => include/linux/visorbus}/guestlinuxdebug.h  |  0
 .../unisys/include => include/linux/visorbus}/iochannel.h |  0
 .../unisys/include => include/linux/visorbus}/version.h   |  0
 .../unisys/include => include/linux/visorbus}/visorbus.h  |  0
 34 files changed, 35 insertions(+), 44 deletions(-)
 rename drivers/staging/unisys/Documentation/ABI/sysfs-platform-visorchipset => 
Documentation/ABI/stable/sysfs-bus-visorbus (100%)
 rename drivers/staging/unisys/Documentation/overview.txt => 
Documentation/visorbus.txt (100%)
 delete mode 100644 drivers/staging/unisys/visorbus/Makefile
 rename drivers/{staging/unisys => virt}/visorbus/Kconfig (100%)
 create mode 100644 drivers/virt/visorbus/Makefile
 rename drivers/{staging/unisys => virt}/visorbus/controlvmchannel.h (99%)
 rename drivers/{staging/unisys => virt}/visorbus/controlvmcompletionstatus.h 
(100%)
 rename drivers/{staging/unisys => virt}/visorbus/iovmcall_gnuc.h (100%)
 rename drivers/{staging/unisys => virt}/visorbus/vbuschannel.h (99%)
 rename drivers/{staging/unisys => virt}/visorbus/vbusdeviceinfo.h (100%)
 rename drivers/{staging/unisys => virt}/visorbus/vbushelper.h (100%)
 rename drivers/{staging/unisys => virt}/visorbus/visorbus_main.c (99%)
 rename drivers/{staging/unisys => virt}/visorbus/visorbus_private.h (100%)
 rename drivers/{staging/unisys => virt}/visorbus/visorchannel.c (99%)
 rename drivers/{staging/unisys => virt}/visorbus/visorchipset.c (99%)
 rename drivers/{staging/unisys => virt}/visorbus/vmcallinterface.h (98%)
 rename {drivers/staging/unisys/include => include/linux/visorbus}/channel.h 
(100%)
 rename {drivers/staging/unisys/include => 
include/linux/visorbus}/channel_guid.h (100%)
 rename {drivers/staging/unisys/include => 
include/linux/visorbus}/diagchannel.h (100%)
 rename {drivers/staging/unisys/include => 
include/linux/visorbus}/guestlinuxdebug.h (100%)
 rename {drivers/staging/unisys/include => include/linux/visorbus}/iochannel.h 
(100%)
 rename {drivers/staging/unisys/include => include/linux/visorbus}/version.h 
(100%)
 rename {drivers/staging/unisys/include => 

Re: [PATCH 7/8] ntb_pingpong: Add a debugfs file to get the ping count

[Allen Hubbe]

On Fri, Jun 10, 2016 at 6:54 PM, Logan Gunthorpe  wrote:
> This commit adds a debugfs 'count' file to ntb_pingpong. This is so
> testing with ntb_pingpong can be automated beyond just checking the
> logs for pong messages.
>
> The count file returns a number which increments every pong. The
> counter can be cleared by writing a zero.
>
> Signed-off-by: Logan Gunthorpe 
> ---
>  drivers/ntb/test/ntb_pingpong.c | 68 
> -
>  1 file changed, 67 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/ntb/test/ntb_pingpong.c b/drivers/ntb/test/ntb_pingpong.c
> index fe16005..34bbf5a 100644
> --- a/drivers/ntb/test/ntb_pingpong.c
> +++ b/drivers/ntb/test/ntb_pingpong.c
> @@ -61,6 +61,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>
>  #include 
>
> @@ -96,8 +97,13 @@ struct pp_ctx {
> spinlock_t  db_lock;
> struct timer_list   db_timer;
> unsigned long   db_delay;
> +   struct dentry   *debugfs_node_dir;
> +   struct dentry   *debugfs_count;
> +   atomic_tcount;
>  };
>
> +static struct dentry *pp_debugfs_dir;
> +
>  static void pp_ping(unsigned long ctx)
>  {
> struct pp_ctx *pp = (void *)ctx;
> @@ -171,10 +177,38 @@ static void pp_db_event(void *ctx, int vec)
> dev_dbg(>ntb->dev,
> "Pong vec %d bits %#llx\n",
> vec, db_bits);
> +   atomic_inc(>count);
> }
> spin_unlock_irqrestore(>db_lock, irqflags);
>  }
>
> +static int pp_debugfs_setup(struct pp_ctx *pp)
> +{
> +   struct pci_dev *pdev = pp->ntb->pdev;
> +
> +   if (!debugfs_initialized())
> +   return -ENODEV;
> +
> +   if (!pp_debugfs_dir) {
> +   pp_debugfs_dir = debugfs_create_dir(KBUILD_MODNAME, NULL);

The pp_debugfs_dir is already initialized by the module init function.
If it doesn't exist here, I think we should just return instead of
trying again.  It's also worth noting, though it is probably no harm,
the code here does not check debugfs_initialized().

> +   if (!pp_debugfs_dir)
> +   return -ENODEV;
> +   }
> +
> +   pp->debugfs_node_dir = debugfs_create_dir(pci_name(pdev),
> + pp_debugfs_dir);
> +   if (!pp->debugfs_node_dir)
> +   return -ENODEV;
> +
> +   pp->debugfs_count = debugfs_create_atomic_t("count", S_IRUSR | 
> S_IWUSR,
> +   pp->debugfs_node_dir,
> +   >count);
> +   if (!pp->debugfs_count)
> +   return -ENODEV;
> +
> +   return 0;
> +}
> +
>  static const struct ntb_ctx_ops pp_ops = {
> .link_event = pp_link_event,
> .db_event = pp_db_event,
> @@ -210,6 +244,7 @@ static int pp_probe(struct ntb_client *client,
>
> pp->ntb = ntb;
> pp->db_bits = 0;
> +   atomic_set(>count, 0);
> spin_lock_init(>db_lock);
> setup_timer(>db_timer, pp_ping, (unsigned long)pp);
> pp->db_delay = msecs_to_jiffies(delay_ms);
> @@ -218,6 +253,10 @@ static int pp_probe(struct ntb_client *client,
> if (rc)
> goto err_ctx;
>
> +   rc = pp_debugfs_setup(pp);
> +   if (rc)
> +   goto err_ctx;
> +
> ntb_link_enable(ntb, NTB_SPEED_AUTO, NTB_WIDTH_AUTO);
> ntb_link_event(ntb);
>
> @@ -234,6 +273,8 @@ static void pp_remove(struct ntb_client *client,
>  {
> struct pp_ctx *pp = ntb->ctx;
>
> +   debugfs_remove_recursive(pp->debugfs_node_dir);
> +
> ntb_clear_ctx(ntb);
> del_timer_sync(>db_timer);
> ntb_link_disable(ntb);
> @@ -247,4 +288,29 @@ static struct ntb_client pp_client = {
> .remove = pp_remove,
> },
>  };
> -module_ntb_client(pp_client);
> +
> +static int __init tool_init(void)

This should be pp_init() not tool_init().

> +{
> +   int rc;
> +
> +   if (debugfs_initialized())
> +   pp_debugfs_dir = debugfs_create_dir(KBUILD_MODNAME, NULL);
> +
> +   rc = ntb_register_client(_client);
> +   if (rc)
> +   goto err_client;
> +
> +   return 0;
> +
> +err_client:
> +   debugfs_remove_recursive(pp_debugfs_dir);
> +   return rc;
> +}
> +module_init(tool_init);
> +
> +static void __exit tool_exit(void)
> +{
> +   ntb_unregister_client(_client);
> +   debugfs_remove_recursive(pp_debugfs_dir);
> +}
> +module_exit(tool_exit);

Re: [PATCH 7/8] ntb_pingpong: Add a debugfs file to get the ping count

[Allen Hubbe]

On Fri, Jun 10, 2016 at 6:54 PM, Logan Gunthorpe  wrote:
> This commit adds a debugfs 'count' file to ntb_pingpong. This is so
> testing with ntb_pingpong can be automated beyond just checking the
> logs for pong messages.
>
> The count file returns a number which increments every pong. The
> counter can be cleared by writing a zero.
>
> Signed-off-by: Logan Gunthorpe 
> ---
>  drivers/ntb/test/ntb_pingpong.c | 68 
> -
>  1 file changed, 67 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/ntb/test/ntb_pingpong.c b/drivers/ntb/test/ntb_pingpong.c
> index fe16005..34bbf5a 100644
> --- a/drivers/ntb/test/ntb_pingpong.c
> +++ b/drivers/ntb/test/ntb_pingpong.c
> @@ -61,6 +61,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>
>  #include 
>
> @@ -96,8 +97,13 @@ struct pp_ctx {
> spinlock_t  db_lock;
> struct timer_list   db_timer;
> unsigned long   db_delay;
> +   struct dentry   *debugfs_node_dir;
> +   struct dentry   *debugfs_count;
> +   atomic_tcount;
>  };
>
> +static struct dentry *pp_debugfs_dir;
> +
>  static void pp_ping(unsigned long ctx)
>  {
> struct pp_ctx *pp = (void *)ctx;
> @@ -171,10 +177,38 @@ static void pp_db_event(void *ctx, int vec)
> dev_dbg(>ntb->dev,
> "Pong vec %d bits %#llx\n",
> vec, db_bits);
> +   atomic_inc(>count);
> }
> spin_unlock_irqrestore(>db_lock, irqflags);
>  }
>
> +static int pp_debugfs_setup(struct pp_ctx *pp)
> +{
> +   struct pci_dev *pdev = pp->ntb->pdev;
> +
> +   if (!debugfs_initialized())
> +   return -ENODEV;
> +
> +   if (!pp_debugfs_dir) {
> +   pp_debugfs_dir = debugfs_create_dir(KBUILD_MODNAME, NULL);

The pp_debugfs_dir is already initialized by the module init function.
If it doesn't exist here, I think we should just return instead of
trying again.  It's also worth noting, though it is probably no harm,
the code here does not check debugfs_initialized().

> +   if (!pp_debugfs_dir)
> +   return -ENODEV;
> +   }
> +
> +   pp->debugfs_node_dir = debugfs_create_dir(pci_name(pdev),
> + pp_debugfs_dir);
> +   if (!pp->debugfs_node_dir)
> +   return -ENODEV;
> +
> +   pp->debugfs_count = debugfs_create_atomic_t("count", S_IRUSR | 
> S_IWUSR,
> +   pp->debugfs_node_dir,
> +   >count);
> +   if (!pp->debugfs_count)
> +   return -ENODEV;
> +
> +   return 0;
> +}
> +
>  static const struct ntb_ctx_ops pp_ops = {
> .link_event = pp_link_event,
> .db_event = pp_db_event,
> @@ -210,6 +244,7 @@ static int pp_probe(struct ntb_client *client,
>
> pp->ntb = ntb;
> pp->db_bits = 0;
> +   atomic_set(>count, 0);
> spin_lock_init(>db_lock);
> setup_timer(>db_timer, pp_ping, (unsigned long)pp);
> pp->db_delay = msecs_to_jiffies(delay_ms);
> @@ -218,6 +253,10 @@ static int pp_probe(struct ntb_client *client,
> if (rc)
> goto err_ctx;
>
> +   rc = pp_debugfs_setup(pp);
> +   if (rc)
> +   goto err_ctx;
> +
> ntb_link_enable(ntb, NTB_SPEED_AUTO, NTB_WIDTH_AUTO);
> ntb_link_event(ntb);
>
> @@ -234,6 +273,8 @@ static void pp_remove(struct ntb_client *client,
>  {
> struct pp_ctx *pp = ntb->ctx;
>
> +   debugfs_remove_recursive(pp->debugfs_node_dir);
> +
> ntb_clear_ctx(ntb);
> del_timer_sync(>db_timer);
> ntb_link_disable(ntb);
> @@ -247,4 +288,29 @@ static struct ntb_client pp_client = {
> .remove = pp_remove,
> },
>  };
> -module_ntb_client(pp_client);
> +
> +static int __init tool_init(void)

This should be pp_init() not tool_init().

> +{
> +   int rc;
> +
> +   if (debugfs_initialized())
> +   pp_debugfs_dir = debugfs_create_dir(KBUILD_MODNAME, NULL);
> +
> +   rc = ntb_register_client(_client);
> +   if (rc)
> +   goto err_client;
> +
> +   return 0;
> +
> +err_client:
> +   debugfs_remove_recursive(pp_debugfs_dir);
> +   return rc;
> +}
> +module_init(tool_init);
> +
> +static void __exit tool_exit(void)
> +{
> +   ntb_unregister_client(_client);
> +   debugfs_remove_recursive(pp_debugfs_dir);
> +}
> +module_exit(tool_exit);

Re: [PATCH 5/8] ntb_tool: BUG: Ensure the buffer size is large enough to return all spads

[Allen Hubbe]

On Fri, Jun 10, 2016 at 6:54 PM, Logan Gunthorpe  wrote:
> On hardware with 32 scratchpad registers the spad field in ntb tool
> could chop off the end. The maximum buffer size is increased from
> 256 to 15 times the number or scratchpads.
>
> Signed-off-by: Logan Gunthorpe 

It could be marginally better if there was an explanation to accompany
the magic number 15, but it's not a big deal.  One might guess it has
something to do with the expected length of the formatted string.

Acked-by: Allen Hubbe 

> ---
>  drivers/ntb/test/ntb_tool.c | 5 +++--
>  1 file changed, 3 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/ntb/test/ntb_tool.c b/drivers/ntb/test/ntb_tool.c
> index 4c01057..954e1d5 100644
> --- a/drivers/ntb/test/ntb_tool.c
> +++ b/drivers/ntb/test/ntb_tool.c
> @@ -368,7 +368,9 @@ static ssize_t tool_spadfn_read(struct tool_ctx *tc, char 
> __user *ubuf,
> if (!spad_read_fn)
> return -EINVAL;
>
> -   buf_size = min_t(size_t, size, 0x100);
> +   spad_count = ntb_spad_count(tc->ntb);
> +
> +   buf_size = min_t(size_t, size, spad_count * 15);
>
> buf = kmalloc(buf_size, GFP_KERNEL);
> if (!buf)
> @@ -376,7 +378,6 @@ static ssize_t tool_spadfn_read(struct tool_ctx *tc, char 
> __user *ubuf,
>
> pos = 0;
>
> -   spad_count = ntb_spad_count(tc->ntb);
> for (i = 0; i < spad_count; ++i) {
> pos += scnprintf(buf + pos, buf_size - pos, "%d\t%#x\n",
>  i, spad_read_fn(tc->ntb, i));
> --
> 2.1.4
>
> --
> You received this message because you are subscribed to the Google Groups 
> "linux-ntb" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to linux-ntb+unsubscr...@googlegroups.com.
> To post to this group, send email to linux-...@googlegroups.com.
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/linux-ntb/d9488f2c946644c2b1258a78929d3543747283ec.1465598632.git.logang%40deltatee.com.
> For more options, visit https://groups.google.com/d/optout.

Re: [PATCH 5/8] ntb_tool: BUG: Ensure the buffer size is large enough to return all spads

[Allen Hubbe]

On Fri, Jun 10, 2016 at 6:54 PM, Logan Gunthorpe  wrote:
> On hardware with 32 scratchpad registers the spad field in ntb tool
> could chop off the end. The maximum buffer size is increased from
> 256 to 15 times the number or scratchpads.
>
> Signed-off-by: Logan Gunthorpe 

It could be marginally better if there was an explanation to accompany
the magic number 15, but it's not a big deal.  One might guess it has
something to do with the expected length of the formatted string.

Acked-by: Allen Hubbe 

> ---
>  drivers/ntb/test/ntb_tool.c | 5 +++--
>  1 file changed, 3 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/ntb/test/ntb_tool.c b/drivers/ntb/test/ntb_tool.c
> index 4c01057..954e1d5 100644
> --- a/drivers/ntb/test/ntb_tool.c
> +++ b/drivers/ntb/test/ntb_tool.c
> @@ -368,7 +368,9 @@ static ssize_t tool_spadfn_read(struct tool_ctx *tc, char 
> __user *ubuf,
> if (!spad_read_fn)
> return -EINVAL;
>
> -   buf_size = min_t(size_t, size, 0x100);
> +   spad_count = ntb_spad_count(tc->ntb);
> +
> +   buf_size = min_t(size_t, size, spad_count * 15);
>
> buf = kmalloc(buf_size, GFP_KERNEL);
> if (!buf)
> @@ -376,7 +378,6 @@ static ssize_t tool_spadfn_read(struct tool_ctx *tc, char 
> __user *ubuf,
>
> pos = 0;
>
> -   spad_count = ntb_spad_count(tc->ntb);
> for (i = 0; i < spad_count; ++i) {
> pos += scnprintf(buf + pos, buf_size - pos, "%d\t%#x\n",
>  i, spad_read_fn(tc->ntb, i));
> --
> 2.1.4
>
> --
> You received this message because you are subscribed to the Google Groups 
> "linux-ntb" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to linux-ntb+unsubscr...@googlegroups.com.
> To post to this group, send email to linux-...@googlegroups.com.
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/linux-ntb/d9488f2c946644c2b1258a78929d3543747283ec.1465598632.git.logang%40deltatee.com.
> For more options, visit https://groups.google.com/d/optout.

Re: [PATCH 6/8] ntb_tool: Add link status file to debugfs

[Allen Hubbe]

On Fri, Jun 10, 2016 at 6:54 PM, Logan Gunthorpe  wrote:
> In order to more successfully script with ntb_tool it's useful to
> have a link file to check the link status so that the script
> doesn't use the other files until the link is up.
>
> This commit adds a 'link' file to the debugfs directory which reads
> 0 or 1 depending on the link status. For scripting convenience, writing
> will block until the link is up (discarding anything that was written).
>
> Signed-off-by: Logan Gunthorpe 
> ---
>  drivers/ntb/test/ntb_tool.c | 45 
> +
>  1 file changed, 45 insertions(+)
>
> diff --git a/drivers/ntb/test/ntb_tool.c b/drivers/ntb/test/ntb_tool.c
> index 954e1d5..116352e 100644
> --- a/drivers/ntb/test/ntb_tool.c
> +++ b/drivers/ntb/test/ntb_tool.c
> @@ -59,6 +59,12 @@
>   *
>   * Eg: check if clearing the doorbell mask generates an interrupt.
>   *
> + * # Check the link status
> + * root@self# cat $DBG_DIR/link
> + *
> + * # Block until the link is up
> + * root@self# echo > $DBG_DIR/link

I think a file to get and set the link status is a good idea, but the
way it is done as proposed here is not in a similar style to other
ntb_tool operations.  Other operations simply read a register and
format the value, or scan a value and write a register.  Similarly, I
think the link status could be done in the same way: use the read file
operation to get the current status with ntb_link_is_up(), and use the
file write operation to enable or disable the link with
ntb_link_enable() and ntb_link_disable().

Waiting for link status is an interesting concept, too.  Really, one
might be interested in a change in link status, whether up or down.
What about a link event file that supports write to arm the event, and
read to block for the event.  Consider an implementation based on
.  It would be used in combination with the link
status file, above, as follows.

1: Write 1 to the event file.  This arms the event.
  - The event will be disarmed by the next tool_link_event().

2: The application may read the link status file if it is interested
in waiting for a particular event.

3. The application may wait for an event by reading the event file
  - The application will wait as long as the event is still armed.
  - If the event was disarmed before waiting, the application will not block.

4. The application should read the link status again.

In any case, I think it would be more expected and natural to block
while reading a file versus writing it.

> + *
>   * # Set the doorbell mask
>   * root@self# echo 's 1' > $DBG_DIR/mask
>   *
> @@ -127,6 +133,7 @@ struct tool_ctx {
> struct work_struct link_cleanup;
> bool link_is_up;
> struct delayed_work link_work;
> +   wait_queue_head_t link_wq;
> int mw_count;
> struct tool_mw mws[MAX_MWS];
>  };
> @@ -237,6 +244,7 @@ static void tool_link_work(struct work_struct *work)
> "Error setting up memory windows: %d\n", rc);
>
> tc->link_is_up = true;
> +   wake_up(>link_wq);
>  }
>
>  static void tool_link_cleanup(struct work_struct *work)
> @@ -573,6 +581,39 @@ static TOOL_FOPS_RDWR(tool_peer_spad_fops,
>   tool_peer_spad_read,
>   tool_peer_spad_write);
>
> +static ssize_t tool_link_read(struct file *filep, char __user *ubuf,
> + size_t size, loff_t *offp)
> +{
> +   struct tool_ctx *tc = filep->private_data;
> +   char *buf;
> +   ssize_t pos, rc;
> +
> +   buf = kmalloc(64, GFP_KERNEL);
> +   if (!buf)
> +   return -ENOMEM;
> +
> +   pos = scnprintf(buf, 64, "%d\n", tc->link_is_up);
> +   rc = simple_read_from_buffer(ubuf, size, offp, buf, pos);
> +
> +   kfree(buf);
> +
> +   return rc;
> +}
> +
> +static ssize_t tool_link_write(struct file *filep, const char __user *ubuf,
> +  size_t size, loff_t *offp)
> +{
> +   struct tool_ctx *tc = filep->private_data;
> +
> +   if (wait_event_interruptible(tc->link_wq, tc->link_is_up))
> +   return -ERESTART;
> +
> +   return size;
> +}
> +
> +static TOOL_FOPS_RDWR(tool_link_fops,
> + tool_link_read,
> + tool_link_write);
>
>  static ssize_t tool_mw_read(struct file *filep, char __user *ubuf,
> size_t size, loff_t *offp)
> @@ -708,6 +749,9 @@ static void tool_setup_dbgfs(struct tool_ctx *tc)
> debugfs_create_file("peer_spad", S_IRUSR | S_IWUSR, tc->dbgfs,
> tc, _peer_spad_fops);
>
> +   debugfs_create_file("link", S_IRUSR | S_IWUSR, tc->dbgfs,
> +   tc, _link_fops);
> +
> mw_count = min(ntb_mw_count(tc->ntb), MAX_MWS);
> for (i = 0; i < mw_count; i++) {
> char buf[30];
> @@ -741,6 +785,7 @@ static int tool_probe(struct ntb_client *self, struct 
> ntb_dev 

Re: [PATCH 6/8] ntb_tool: Add link status file to debugfs

[Allen Hubbe]

On Fri, Jun 10, 2016 at 6:54 PM, Logan Gunthorpe  wrote:
> In order to more successfully script with ntb_tool it's useful to
> have a link file to check the link status so that the script
> doesn't use the other files until the link is up.
>
> This commit adds a 'link' file to the debugfs directory which reads
> 0 or 1 depending on the link status. For scripting convenience, writing
> will block until the link is up (discarding anything that was written).
>
> Signed-off-by: Logan Gunthorpe 
> ---
>  drivers/ntb/test/ntb_tool.c | 45 
> +
>  1 file changed, 45 insertions(+)
>
> diff --git a/drivers/ntb/test/ntb_tool.c b/drivers/ntb/test/ntb_tool.c
> index 954e1d5..116352e 100644
> --- a/drivers/ntb/test/ntb_tool.c
> +++ b/drivers/ntb/test/ntb_tool.c
> @@ -59,6 +59,12 @@
>   *
>   * Eg: check if clearing the doorbell mask generates an interrupt.
>   *
> + * # Check the link status
> + * root@self# cat $DBG_DIR/link
> + *
> + * # Block until the link is up
> + * root@self# echo > $DBG_DIR/link

I think a file to get and set the link status is a good idea, but the
way it is done as proposed here is not in a similar style to other
ntb_tool operations.  Other operations simply read a register and
format the value, or scan a value and write a register.  Similarly, I
think the link status could be done in the same way: use the read file
operation to get the current status with ntb_link_is_up(), and use the
file write operation to enable or disable the link with
ntb_link_enable() and ntb_link_disable().

Waiting for link status is an interesting concept, too.  Really, one
might be interested in a change in link status, whether up or down.
What about a link event file that supports write to arm the event, and
read to block for the event.  Consider an implementation based on
.  It would be used in combination with the link
status file, above, as follows.

1: Write 1 to the event file.  This arms the event.
  - The event will be disarmed by the next tool_link_event().

2: The application may read the link status file if it is interested
in waiting for a particular event.

3. The application may wait for an event by reading the event file
  - The application will wait as long as the event is still armed.
  - If the event was disarmed before waiting, the application will not block.

4. The application should read the link status again.

In any case, I think it would be more expected and natural to block
while reading a file versus writing it.

> + *
>   * # Set the doorbell mask
>   * root@self# echo 's 1' > $DBG_DIR/mask
>   *
> @@ -127,6 +133,7 @@ struct tool_ctx {
> struct work_struct link_cleanup;
> bool link_is_up;
> struct delayed_work link_work;
> +   wait_queue_head_t link_wq;
> int mw_count;
> struct tool_mw mws[MAX_MWS];
>  };
> @@ -237,6 +244,7 @@ static void tool_link_work(struct work_struct *work)
> "Error setting up memory windows: %d\n", rc);
>
> tc->link_is_up = true;
> +   wake_up(>link_wq);
>  }
>
>  static void tool_link_cleanup(struct work_struct *work)
> @@ -573,6 +581,39 @@ static TOOL_FOPS_RDWR(tool_peer_spad_fops,
>   tool_peer_spad_read,
>   tool_peer_spad_write);
>
> +static ssize_t tool_link_read(struct file *filep, char __user *ubuf,
> + size_t size, loff_t *offp)
> +{
> +   struct tool_ctx *tc = filep->private_data;
> +   char *buf;
> +   ssize_t pos, rc;
> +
> +   buf = kmalloc(64, GFP_KERNEL);
> +   if (!buf)
> +   return -ENOMEM;
> +
> +   pos = scnprintf(buf, 64, "%d\n", tc->link_is_up);
> +   rc = simple_read_from_buffer(ubuf, size, offp, buf, pos);
> +
> +   kfree(buf);
> +
> +   return rc;
> +}
> +
> +static ssize_t tool_link_write(struct file *filep, const char __user *ubuf,
> +  size_t size, loff_t *offp)
> +{
> +   struct tool_ctx *tc = filep->private_data;
> +
> +   if (wait_event_interruptible(tc->link_wq, tc->link_is_up))
> +   return -ERESTART;
> +
> +   return size;
> +}
> +
> +static TOOL_FOPS_RDWR(tool_link_fops,
> + tool_link_read,
> + tool_link_write);
>
>  static ssize_t tool_mw_read(struct file *filep, char __user *ubuf,
> size_t size, loff_t *offp)
> @@ -708,6 +749,9 @@ static void tool_setup_dbgfs(struct tool_ctx *tc)
> debugfs_create_file("peer_spad", S_IRUSR | S_IWUSR, tc->dbgfs,
> tc, _peer_spad_fops);
>
> +   debugfs_create_file("link", S_IRUSR | S_IWUSR, tc->dbgfs,
> +   tc, _link_fops);
> +
> mw_count = min(ntb_mw_count(tc->ntb), MAX_MWS);
> for (i = 0; i < mw_count; i++) {
> char buf[30];
> @@ -741,6 +785,7 @@ static int tool_probe(struct ntb_client *self, struct 
> ntb_dev *ntb)
> }
>
> tc->ntb = 

Re: [PATCH 47/48] PWM: atmel-tcb: switch to new binding

[kbuild test robot]

Hi,

[auto build test WARNING on at91/at91-next]
[also build test WARNING on v4.7-rc2 next-20160609]
[if your patch is applied to the wrong git tree, please drop us a note to help 
improve the system]

url:
https://github.com/0day-ci/linux/commits/Alexandre-Belloni/ARM-at91-rework-Atmel-TCB-drivers/20160611-062134
base:   https://git.kernel.org/pub/scm/linux/kernel/git/nferre/linux-at91.git 
at91-next
config: x86_64-allmodconfig (attached as .config)
compiler: gcc-6 (Debian 6.1.1-1) 6.1.1 20160430
reproduce:
# save the attached .config to linux build tree
make ARCH=x86_64 

All warnings (new ones prefixed by >>):

   drivers/pwm/pwm-atmel-tcb.c: In function 'atmel_tcb_pwm_probe':
>> drivers/pwm/pwm-atmel-tcb.c:418:18: warning: cast from pointer to integer of 
>> different size [-Wpointer-to-int-cast]
 tcbpwm->width = (int)match->data;
 ^

vim +418 drivers/pwm/pwm-atmel-tcb.c

   402  dev_err(>dev, "failed to allocate memory\n");
   403  goto err_slow_clk;
   404  }
   405  
   406  tcbpwm->chip.dev = >dev;
   407  tcbpwm->chip.ops = _tcb_pwm_ops;
   408  tcbpwm->chip.of_xlate = of_pwm_xlate_with_flags;
   409  tcbpwm->chip.of_pwm_n_cells = 3;
   410  tcbpwm->chip.base = -1;
   411  tcbpwm->chip.npwm = NPWM;
   412  tcbpwm->channel = channel;
   413  tcbpwm->regmap = regmap;
   414  tcbpwm->clk = clk;
   415  tcbpwm->slow_clk = slow_clk;
   416  
   417  match = of_match_node(atmel_tcb_dt_ids, np->parent);
 > 418  tcbpwm->width = (int)match->data;
   419  
   420  err = clk_prepare_enable(slow_clk);
   421  if (err)
   422  goto err_slow_clk;
   423  
   424  spin_lock_init(>lock);
   425  
   426  err = pwmchip_add(>chip);

---
0-DAY kernel test infrastructureOpen Source Technology Center
https://lists.01.org/pipermail/kbuild-all   Intel Corporation


.config.gz
Description: Binary data

Re: [PATCH 47/48] PWM: atmel-tcb: switch to new binding

[kbuild test robot]

Hi,

[auto build test WARNING on at91/at91-next]
[also build test WARNING on v4.7-rc2 next-20160609]
[if your patch is applied to the wrong git tree, please drop us a note to help 
improve the system]

url:
https://github.com/0day-ci/linux/commits/Alexandre-Belloni/ARM-at91-rework-Atmel-TCB-drivers/20160611-062134
base:   https://git.kernel.org/pub/scm/linux/kernel/git/nferre/linux-at91.git 
at91-next
config: x86_64-allmodconfig (attached as .config)
compiler: gcc-6 (Debian 6.1.1-1) 6.1.1 20160430
reproduce:
# save the attached .config to linux build tree
make ARCH=x86_64 

All warnings (new ones prefixed by >>):

   drivers/pwm/pwm-atmel-tcb.c: In function 'atmel_tcb_pwm_probe':
>> drivers/pwm/pwm-atmel-tcb.c:418:18: warning: cast from pointer to integer of 
>> different size [-Wpointer-to-int-cast]
 tcbpwm->width = (int)match->data;
 ^

vim +418 drivers/pwm/pwm-atmel-tcb.c

   402  dev_err(>dev, "failed to allocate memory\n");
   403  goto err_slow_clk;
   404  }
   405  
   406  tcbpwm->chip.dev = >dev;
   407  tcbpwm->chip.ops = _tcb_pwm_ops;
   408  tcbpwm->chip.of_xlate = of_pwm_xlate_with_flags;
   409  tcbpwm->chip.of_pwm_n_cells = 3;
   410  tcbpwm->chip.base = -1;
   411  tcbpwm->chip.npwm = NPWM;
   412  tcbpwm->channel = channel;
   413  tcbpwm->regmap = regmap;
   414  tcbpwm->clk = clk;
   415  tcbpwm->slow_clk = slow_clk;
   416  
   417  match = of_match_node(atmel_tcb_dt_ids, np->parent);
 > 418  tcbpwm->width = (int)match->data;
   419  
   420  err = clk_prepare_enable(slow_clk);
   421  if (err)
   422  goto err_slow_clk;
   423  
   424  spin_lock_init(>lock);
   425  
   426  err = pwmchip_add(>chip);

---
0-DAY kernel test infrastructureOpen Source Technology Center
https://lists.01.org/pipermail/kbuild-all   Intel Corporation


.config.gz
Description: Binary data

Re: [PATCH 1/4] mtd: introduce the mtd_pairing_scheme concept

[Brian Norris]

Hi,

On Mon, Apr 25, 2016 at 12:01:18PM +0200, Boris Brezillon wrote:
> MLC and TLC NAND devices are using NAND cells exposing more than one bit,
> but instead of attaching all the bits in a given cell to a single NAND
> page, each bit is usually attached to a different page. This concept is
> called 'page pairing', and has significant impacts on the flash storage
> usage.
> The main problem showed by these devices is that interrupting a page
> program operation may not only corrupt the page we are programming
> but also the page it is paired with, hence the need to expose to MTD
> users the pairing scheme information.
> 
> The pairing APIs allows one to query pairing information attached to a
> given page (here called wunit), or the other way around (the wunit
> pointed by pairing information).

Why the "write unit" terminology? Is a write unit ever different from a
page?

> It also provides several helpers to help the conversion between absolute
> offsets and wunits, and query the number of pairing groups.
> 
> Signed-off-by: Boris Brezillon 
> ---
>  drivers/mtd/mtdcore.c   | 62 +++
>  drivers/mtd/mtdpart.c   |  1 +
>  include/linux/mtd/mtd.h | 64 
> +
>  3 files changed, 127 insertions(+)
> 
> diff --git a/drivers/mtd/mtdcore.c b/drivers/mtd/mtdcore.c
> index e3936b8..315adc0 100644
> --- a/drivers/mtd/mtdcore.c
> +++ b/drivers/mtd/mtdcore.c
> @@ -376,6 +376,68 @@ static int mtd_reboot_notifier(struct notifier_block *n, 
> unsigned long state,
>  }
>  
>  /**
> + *   mtd_wunit_to_pairing_info - get pairing information of a wunit
> + *   @mtd: pointer to new MTD device info structure
> + *   @wunit: the write unit we are interrested in
> + *   @info: pairing information struct
> + *
> + *   Retrieve pairing information associated to the wunit.
> + *   This is mainly useful when dealing with MLC/TLC NANDs where pages
> + *   can be paired together, and where programming a page may influence
> + *   the page it is paired with.
> + *   The notion of page is replaced by the term wunit (write-unit).
> + */
> +void mtd_wunit_to_pairing_info(struct mtd_info *mtd, int wunit,
> +struct mtd_pairing_info *info)
> +{
> + if (!mtd->pairing || !mtd->pairing->get_info) {
> + info->group = 0;
> + info->pair = wunit;
> + } else {
> + mtd->pairing->get_info(mtd, wunit, info);
> + }
> +}
> +EXPORT_SYMBOL_GPL(mtd_wunit_to_pairing_info);
> +
> +/**
> + *   mtd_wunit_to_pairing_info - get wunit from pairing information
> + *   @mtd: pointer to new MTD device info structure
> + *   @info: pairing information struct
> + *
> + *   Return a positive number representing the wunit associated to the
> + *   info struct, or a negative error code.
> + */
> +int mtd_pairing_info_to_wunit(struct mtd_info *mtd,
> +   const struct mtd_pairing_info *info)
> +{
> + if (!mtd->pairing || !mtd->pairing->get_info) {
> + if (info->group)
> + return -EINVAL;
> +
> + return info->pair;
> + }
> +
> + return mtd->pairing->get_wunit(mtd, info);
> +}
> +EXPORT_SYMBOL_GPL(mtd_pairing_info_to_wunit);
> +
> +/**
> + *   mtd_pairing_groups_per_eb - get the number of pairing groups per erase
> + *   block
> + *   @mtd: pointer to new MTD device info structure
> + *
> + *   Return the number of pairing groups per erase block.
> + */
> +int mtd_pairing_groups_per_eb(struct mtd_info *mtd)
> +{
> + if (!mtd->pairing || !mtd->pairing->ngroups)
> + return 1;
> +
> + return mtd->pairing->ngroups;
> +}
> +EXPORT_SYMBOL_GPL(mtd_pairing_groups_per_eb);
> +
> +/**
>   *   add_mtd_device - register an MTD device
>   *   @mtd: pointer to new MTD device info structure
>   *
> diff --git a/drivers/mtd/mtdpart.c b/drivers/mtd/mtdpart.c
> index 1f13e32..e32a0ac 100644
> --- a/drivers/mtd/mtdpart.c
> +++ b/drivers/mtd/mtdpart.c
> @@ -397,6 +397,7 @@ static struct mtd_part *allocate_partition(struct 
> mtd_info *master,
>   slave->mtd.oobsize = master->oobsize;
>   slave->mtd.oobavail = master->oobavail;
>   slave->mtd.subpage_sft = master->subpage_sft;
> + slave->mtd.pairing = master->pairing;
>  
>   slave->mtd.name = name;
>   slave->mtd.owner = master->owner;
> diff --git a/include/linux/mtd/mtd.h b/include/linux/mtd/mtd.h
> index 29a1706..4961092 100644
> --- a/include/linux/mtd/mtd.h
> +++ b/include/linux/mtd/mtd.h
> @@ -127,6 +127,36 @@ struct mtd_ooblayout_ops {
>   struct mtd_oob_region *oobfree);
>  };
>  
> +/**
> + * struct mtd_pairing_info - Page pairing information
> + *
> + * @pair: represent the pair index in the paired pages table.For example, if

Needs a space after the period.

> + * page 0 and page 2 are paired together they form the first pair.

This example doesn't help. What would 

Re: [PATCH 1/4] mtd: introduce the mtd_pairing_scheme concept

[Brian Norris]

Hi,

On Mon, Apr 25, 2016 at 12:01:18PM +0200, Boris Brezillon wrote:
> MLC and TLC NAND devices are using NAND cells exposing more than one bit,
> but instead of attaching all the bits in a given cell to a single NAND
> page, each bit is usually attached to a different page. This concept is
> called 'page pairing', and has significant impacts on the flash storage
> usage.
> The main problem showed by these devices is that interrupting a page
> program operation may not only corrupt the page we are programming
> but also the page it is paired with, hence the need to expose to MTD
> users the pairing scheme information.
> 
> The pairing APIs allows one to query pairing information attached to a
> given page (here called wunit), or the other way around (the wunit
> pointed by pairing information).

Why the "write unit" terminology? Is a write unit ever different from a
page?

> It also provides several helpers to help the conversion between absolute
> offsets and wunits, and query the number of pairing groups.
> 
> Signed-off-by: Boris Brezillon 
> ---
>  drivers/mtd/mtdcore.c   | 62 +++
>  drivers/mtd/mtdpart.c   |  1 +
>  include/linux/mtd/mtd.h | 64 
> +
>  3 files changed, 127 insertions(+)
> 
> diff --git a/drivers/mtd/mtdcore.c b/drivers/mtd/mtdcore.c
> index e3936b8..315adc0 100644
> --- a/drivers/mtd/mtdcore.c
> +++ b/drivers/mtd/mtdcore.c
> @@ -376,6 +376,68 @@ static int mtd_reboot_notifier(struct notifier_block *n, 
> unsigned long state,
>  }
>  
>  /**
> + *   mtd_wunit_to_pairing_info - get pairing information of a wunit
> + *   @mtd: pointer to new MTD device info structure
> + *   @wunit: the write unit we are interrested in
> + *   @info: pairing information struct
> + *
> + *   Retrieve pairing information associated to the wunit.
> + *   This is mainly useful when dealing with MLC/TLC NANDs where pages
> + *   can be paired together, and where programming a page may influence
> + *   the page it is paired with.
> + *   The notion of page is replaced by the term wunit (write-unit).
> + */
> +void mtd_wunit_to_pairing_info(struct mtd_info *mtd, int wunit,
> +struct mtd_pairing_info *info)
> +{
> + if (!mtd->pairing || !mtd->pairing->get_info) {
> + info->group = 0;
> + info->pair = wunit;
> + } else {
> + mtd->pairing->get_info(mtd, wunit, info);
> + }
> +}
> +EXPORT_SYMBOL_GPL(mtd_wunit_to_pairing_info);
> +
> +/**
> + *   mtd_wunit_to_pairing_info - get wunit from pairing information
> + *   @mtd: pointer to new MTD device info structure
> + *   @info: pairing information struct
> + *
> + *   Return a positive number representing the wunit associated to the
> + *   info struct, or a negative error code.
> + */
> +int mtd_pairing_info_to_wunit(struct mtd_info *mtd,
> +   const struct mtd_pairing_info *info)
> +{
> + if (!mtd->pairing || !mtd->pairing->get_info) {
> + if (info->group)
> + return -EINVAL;
> +
> + return info->pair;
> + }
> +
> + return mtd->pairing->get_wunit(mtd, info);
> +}
> +EXPORT_SYMBOL_GPL(mtd_pairing_info_to_wunit);
> +
> +/**
> + *   mtd_pairing_groups_per_eb - get the number of pairing groups per erase
> + *   block
> + *   @mtd: pointer to new MTD device info structure
> + *
> + *   Return the number of pairing groups per erase block.
> + */
> +int mtd_pairing_groups_per_eb(struct mtd_info *mtd)
> +{
> + if (!mtd->pairing || !mtd->pairing->ngroups)
> + return 1;
> +
> + return mtd->pairing->ngroups;
> +}
> +EXPORT_SYMBOL_GPL(mtd_pairing_groups_per_eb);
> +
> +/**
>   *   add_mtd_device - register an MTD device
>   *   @mtd: pointer to new MTD device info structure
>   *
> diff --git a/drivers/mtd/mtdpart.c b/drivers/mtd/mtdpart.c
> index 1f13e32..e32a0ac 100644
> --- a/drivers/mtd/mtdpart.c
> +++ b/drivers/mtd/mtdpart.c
> @@ -397,6 +397,7 @@ static struct mtd_part *allocate_partition(struct 
> mtd_info *master,
>   slave->mtd.oobsize = master->oobsize;
>   slave->mtd.oobavail = master->oobavail;
>   slave->mtd.subpage_sft = master->subpage_sft;
> + slave->mtd.pairing = master->pairing;
>  
>   slave->mtd.name = name;
>   slave->mtd.owner = master->owner;
> diff --git a/include/linux/mtd/mtd.h b/include/linux/mtd/mtd.h
> index 29a1706..4961092 100644
> --- a/include/linux/mtd/mtd.h
> +++ b/include/linux/mtd/mtd.h
> @@ -127,6 +127,36 @@ struct mtd_ooblayout_ops {
>   struct mtd_oob_region *oobfree);
>  };
>  
> +/**
> + * struct mtd_pairing_info - Page pairing information
> + *
> + * @pair: represent the pair index in the paired pages table.For example, if

Needs a space after the period.

> + * page 0 and page 2 are paired together they form the first pair.

This example doesn't help. What would the value of @pair be in this
case? 

Re: [PATCH 0/4] mtd: add support for pairing scheme description

[Brian Norris]

Hi Boris,

I've mostly just reviewed the cover and first patch for now, since that
sets up the rest. A few questions and comments. I hope to review some
more and have more to say later this weekend.

On Mon, Apr 25, 2016 at 12:01:17PM +0200, Boris Brezillon wrote:
> Hi,
> 
> This series is the first step towards reliable MLC/TLC NAND support.
> Those patches allows the NAND layer to expose page pairing information
> to MTD users.

Have you surveyed many types of NAND to get a representative sampling of
what kind of pairing schemes are out there? Do you think you've covered
the possibilities well enough in your API? I have a few comments on the
patches to this effect. I honestly don't know the answer to these
questions, because AFAIR, this is rarely well documented in datasheets.

> The plan is to teach UBI about those constraints and let UBI code take
> the appropriate precautions when dealing with those multi-level cells
> NANDs. The way we'll handle this "paired pages" constraint will be
> described soon in a series adapting the UBI layer, so stay tune ;).
> 
> Note that this implementation only allows page pairing scheme description
> when the NAND has a full-id entry in the nand_ids table.
> This should be addressed in some way for ONFI and JEDEC NANDs, though
> I'm not sure how to handle this yet.

Do ONFI or JEDEC parameter pages even provide this kind of info? The
ONFI spec doesn't mention paired pages.

Brian

> Best Regards,
> 
> Boris
> 
> Boris Brezillon (4):
>   mtd: introduce the mtd_pairing_scheme concept
>   mtd: nand: implement two pairing scheme
>   mtd: nand: add a pairing field to nand_flash_dev
>   mtd: nand: H27UCG8T2ATR: point to the correct pairing scheme
> implementation
> 
>  drivers/mtd/mtdcore.c| 62 
>  drivers/mtd/mtdpart.c|  1 +
>  drivers/mtd/nand/nand_base.c | 97 
> 
>  drivers/mtd/nand/nand_ids.c  |  2 +-
>  include/linux/mtd/mtd.h  | 64 +
>  include/linux/mtd/nand.h |  5 +++
>  6 files changed, 230 insertions(+), 1 deletion(-)
> 
> -- 
> 2.7.4
> 

Re: [PATCH 0/4] mtd: add support for pairing scheme description

[Brian Norris]

Hi Boris,

I've mostly just reviewed the cover and first patch for now, since that
sets up the rest. A few questions and comments. I hope to review some
more and have more to say later this weekend.

On Mon, Apr 25, 2016 at 12:01:17PM +0200, Boris Brezillon wrote:
> Hi,
> 
> This series is the first step towards reliable MLC/TLC NAND support.
> Those patches allows the NAND layer to expose page pairing information
> to MTD users.

Have you surveyed many types of NAND to get a representative sampling of
what kind of pairing schemes are out there? Do you think you've covered
the possibilities well enough in your API? I have a few comments on the
patches to this effect. I honestly don't know the answer to these
questions, because AFAIR, this is rarely well documented in datasheets.

> The plan is to teach UBI about those constraints and let UBI code take
> the appropriate precautions when dealing with those multi-level cells
> NANDs. The way we'll handle this "paired pages" constraint will be
> described soon in a series adapting the UBI layer, so stay tune ;).
> 
> Note that this implementation only allows page pairing scheme description
> when the NAND has a full-id entry in the nand_ids table.
> This should be addressed in some way for ONFI and JEDEC NANDs, though
> I'm not sure how to handle this yet.

Do ONFI or JEDEC parameter pages even provide this kind of info? The
ONFI spec doesn't mention paired pages.

Brian

> Best Regards,
> 
> Boris
> 
> Boris Brezillon (4):
>   mtd: introduce the mtd_pairing_scheme concept
>   mtd: nand: implement two pairing scheme
>   mtd: nand: add a pairing field to nand_flash_dev
>   mtd: nand: H27UCG8T2ATR: point to the correct pairing scheme
> implementation
> 
>  drivers/mtd/mtdcore.c| 62 
>  drivers/mtd/mtdpart.c|  1 +
>  drivers/mtd/nand/nand_base.c | 97 
> 
>  drivers/mtd/nand/nand_ids.c  |  2 +-
>  include/linux/mtd/mtd.h  | 64 +
>  include/linux/mtd/nand.h |  5 +++
>  6 files changed, 230 insertions(+), 1 deletion(-)
> 
> -- 
> 2.7.4
> 

Re: [PATCH 4/4] Revert "powerpc/fsl: Move fsl_guts.h out of arch/powerpc"

[Scott Wood]

On Thu, 2016-06-02 at 11:01 +0200, Arnd Bergmann wrote:
> On Wednesday, June 1, 2016 8:24:20 PM CEST Scott Wood wrote:
> > On Mon, 2016-05-30 at 15:18 +0200, Arnd Bergmann wrote:
> > > All users of this driver are PowerPC specific and the header file
> > > has no business in the global include/linux/ hierarchy, so move
> > > it back before anyone starts using it on ARM.
> > > 
> > > This reverts commit 948486544713492f00ac8a9572909101ea892cb0.
> > > 
> > > Signed-off-by: Arnd Bergmann 
> > > ---
> > > This part of the series is not required for the eSDHC quirk,
> > > but it restores the asm/fsl_guts.h header so it doesn't accidentally
> > > get abused for this in the future. I found two drivers outside of
> > > arch/powerpc that already accessed the registers directly, but the
> > > functions look fairly contained, and can be easily hidden in an
> > > #ifdef CONFIG_PPC
> > 
> > NACK
> > 
> > Besides adding ifdef pollution for no good reason, this register block is
> > used
> > on some ARM chips as well.  Why is it a problem if "anyone starts using it
> > on
> > ARM"?
> 
> It's just not a good interface when it's defined as "this is the layout of
> a register area that any driver can ioremap() if they can figure out the
> device node".

That's why I want to move accesses into one guts driver.

>  It's not uncommon to have register areas like that, but
> normally you have at the minimum a 'syscon' device to handle locking
> between drivers accessing the same registers and to avoid having to map
> the same area multiple times.

syscon requires device tree changes.

I don't see read-modify-write operations in regmap -- how does locking around
an individual, inherently-atomic load or store help?

> If we need to use 'guts' registers on ARM, we can find a way to abstract
> them properly for the given use cases, using a syscon or a driver with
> exported functions, but just making a PowerPC platform specific header
> global to all Linux drivers by putting it into include/linux doesn't seem
> right.

Again, it's not PowerPC-specific!  It started that way but then the same
register block got put onto some ARM chips.

It's not global to "all Linux drivers", just the ones that choose to include
an fsl-specific header.

If and when all uses of guts are moved into the guts driver, the header can be
moved into drivers/soc/fsl.

> Note that the header file uses a structure definition rather than the more
> common macros with register offsets, which is fine for a driver that has
> its own registers and abstracts them, but it doesn't really work with
> the regmap interface, so if we want to use it with syscon, it also needs to
> be rewritten.

We don't want to use it with syscon.  If we did, the solution wouldn't be to
move the header back to arch/powerpc, but to convert the struct into offsets.

-Scott

Re: [PATCH 4/4] Revert "powerpc/fsl: Move fsl_guts.h out of arch/powerpc"

[Scott Wood]

On Thu, 2016-06-02 at 11:01 +0200, Arnd Bergmann wrote:
> On Wednesday, June 1, 2016 8:24:20 PM CEST Scott Wood wrote:
> > On Mon, 2016-05-30 at 15:18 +0200, Arnd Bergmann wrote:
> > > All users of this driver are PowerPC specific and the header file
> > > has no business in the global include/linux/ hierarchy, so move
> > > it back before anyone starts using it on ARM.
> > > 
> > > This reverts commit 948486544713492f00ac8a9572909101ea892cb0.
> > > 
> > > Signed-off-by: Arnd Bergmann 
> > > ---
> > > This part of the series is not required for the eSDHC quirk,
> > > but it restores the asm/fsl_guts.h header so it doesn't accidentally
> > > get abused for this in the future. I found two drivers outside of
> > > arch/powerpc that already accessed the registers directly, but the
> > > functions look fairly contained, and can be easily hidden in an
> > > #ifdef CONFIG_PPC
> > 
> > NACK
> > 
> > Besides adding ifdef pollution for no good reason, this register block is
> > used
> > on some ARM chips as well.  Why is it a problem if "anyone starts using it
> > on
> > ARM"?
> 
> It's just not a good interface when it's defined as "this is the layout of
> a register area that any driver can ioremap() if they can figure out the
> device node".

That's why I want to move accesses into one guts driver.

>  It's not uncommon to have register areas like that, but
> normally you have at the minimum a 'syscon' device to handle locking
> between drivers accessing the same registers and to avoid having to map
> the same area multiple times.

syscon requires device tree changes.

I don't see read-modify-write operations in regmap -- how does locking around
an individual, inherently-atomic load or store help?

> If we need to use 'guts' registers on ARM, we can find a way to abstract
> them properly for the given use cases, using a syscon or a driver with
> exported functions, but just making a PowerPC platform specific header
> global to all Linux drivers by putting it into include/linux doesn't seem
> right.

Again, it's not PowerPC-specific!  It started that way but then the same
register block got put onto some ARM chips.

It's not global to "all Linux drivers", just the ones that choose to include
an fsl-specific header.

If and when all uses of guts are moved into the guts driver, the header can be
moved into drivers/soc/fsl.

> Note that the header file uses a structure definition rather than the more
> common macros with register offsets, which is fine for a driver that has
> its own registers and abstracts them, but it doesn't really work with
> the regmap interface, so if we want to use it with syscon, it also needs to
> be rewritten.

We don't want to use it with syscon.  If we did, the solution wouldn't be to
move the header back to arch/powerpc, but to convert the struct into offsets.

-Scott

Re: [PATCH 3/4] mmc: sdhci-of-esdhc: fix host version for T4240-R1.0-R2.0

[Scott Wood]

On Thu, 2016-06-02 at 10:52 +0200, Arnd Bergmann wrote:
> On Wednesday, June 1, 2016 8:11:14 PM CEST Scott Wood wrote:
> > > +#define T4240_HOST_VER ((VENDOR_V_23 << SDHCI_VENDOR_VER_SHIFT) |
> > > SDHCI_SPEC_200)
> > > +static const struct soc_device_attribute esdhc_t4240_quirk = {
> > > + /* T4240 revision < 0x20 uses vendor version 23, SDHCI version 200
> > > */
> > > + { .soc_id = "T4*(0x824000)", .revision = "0x[01]?",
> > > +   .data = (void *)(uintptr_t)(T4240_HOST_VER) },
> > 
> > Why should this code need to care that the string begins with "T4"?  This
> > creates dual maintenance if that were to change.  It's also broken because
> > T4240 has compatible = "fsl,t4240-device-config", "fsl,qoriq-device-config
> > -2.0" and thus with these patches it would incorrectly show up as "P
> > series
> > (0x824000)".  The compatible string of this node was never meant to be a
> > key
> > for choosing a string to describe the system to userspace.
> 
> This is an artifact of not knowing the specific SoC name, and we can change
> that by looking up the name from the SVR value in the soc_device driver.

...or we could keep it simple and just match the number.

> > 0x824000 is a magic number which should be represented symbolically.
> 
> Sure, feel free to change the format of the soc_device string in any
> name,

That's not what I was asking for...  The match should be numeric but the
knowledge of what the number is should come from a symbolic #define.

> > If T4240 is affected, then so are the reduced-core variants T4160 and
> > T4080,
> > but 0x824000 doesn't match them (Yangbo's patch had the same problem). 
> >  And
> > please don't respond with "0x824*"
> > 
> > You also didn't strip out the E bit of SVR which indicates encryption
> > capability and nothing else (Yangbo's patch did not have this problem
> > because
> > it used SVR_SOC_VER).
> 
> Ok, that should be easy enough to fix in the soc_device driver.

No, because the soc_device driver doesn't know whether the consumer of the ID
cares about the E bit.

> > What happens if the revision condition is more complicated, such as <=
> > 0x20
> > with 0x21 being fine?  Multiple quirk entries where before we had as
> > simple
> > comparison?
> 
> I guess yes. I would really hope that there is no need to use this interface
> pervasively, it's really just to work around the cases where there is no
> way to pass the information in DT otherwise.

How does putting it in the DT work when you have multiple versions of the same
SoC, some of which have the bug and some which don't?

> > I fail to see how this approach is an improvement (much less one that
> > needs to
> > hold up a patchset that is fixing a problem and is not touching any
> > generic
> > code).  Why does this need to be a string?
> 
> A string is what user space gets in /sys/devices/soc/*,

It is rare that the kernel accesses information in the exact same way that
userspace does.  And once we expose this to userspace we're stuck with it, so
exporting anything other than a simple number is even less desirable.

>  and we already have
> code that does the same things there to work around quirks, here we just
> use the same interface in a completely generic way. Note that not every
> SoC family uses numbers in the same way, some have multiple subrevisions,
> some have names etc.

Where is the need for a "completely generic way" for one piece of vendor
-specific code to get information that is inherently specific to that vendor,
that is supplied by code specific to that vendor?

-Scott

Re: [PATCH 3/4] mmc: sdhci-of-esdhc: fix host version for T4240-R1.0-R2.0

[Scott Wood]

On Thu, 2016-06-02 at 10:52 +0200, Arnd Bergmann wrote:
> On Wednesday, June 1, 2016 8:11:14 PM CEST Scott Wood wrote:
> > > +#define T4240_HOST_VER ((VENDOR_V_23 << SDHCI_VENDOR_VER_SHIFT) |
> > > SDHCI_SPEC_200)
> > > +static const struct soc_device_attribute esdhc_t4240_quirk = {
> > > + /* T4240 revision < 0x20 uses vendor version 23, SDHCI version 200
> > > */
> > > + { .soc_id = "T4*(0x824000)", .revision = "0x[01]?",
> > > +   .data = (void *)(uintptr_t)(T4240_HOST_VER) },
> > 
> > Why should this code need to care that the string begins with "T4"?  This
> > creates dual maintenance if that were to change.  It's also broken because
> > T4240 has compatible = "fsl,t4240-device-config", "fsl,qoriq-device-config
> > -2.0" and thus with these patches it would incorrectly show up as "P
> > series
> > (0x824000)".  The compatible string of this node was never meant to be a
> > key
> > for choosing a string to describe the system to userspace.
> 
> This is an artifact of not knowing the specific SoC name, and we can change
> that by looking up the name from the SVR value in the soc_device driver.

...or we could keep it simple and just match the number.

> > 0x824000 is a magic number which should be represented symbolically.
> 
> Sure, feel free to change the format of the soc_device string in any
> name,

That's not what I was asking for...  The match should be numeric but the
knowledge of what the number is should come from a symbolic #define.

> > If T4240 is affected, then so are the reduced-core variants T4160 and
> > T4080,
> > but 0x824000 doesn't match them (Yangbo's patch had the same problem). 
> >  And
> > please don't respond with "0x824*"
> > 
> > You also didn't strip out the E bit of SVR which indicates encryption
> > capability and nothing else (Yangbo's patch did not have this problem
> > because
> > it used SVR_SOC_VER).
> 
> Ok, that should be easy enough to fix in the soc_device driver.

No, because the soc_device driver doesn't know whether the consumer of the ID
cares about the E bit.

> > What happens if the revision condition is more complicated, such as <=
> > 0x20
> > with 0x21 being fine?  Multiple quirk entries where before we had as
> > simple
> > comparison?
> 
> I guess yes. I would really hope that there is no need to use this interface
> pervasively, it's really just to work around the cases where there is no
> way to pass the information in DT otherwise.

How does putting it in the DT work when you have multiple versions of the same
SoC, some of which have the bug and some which don't?

> > I fail to see how this approach is an improvement (much less one that
> > needs to
> > hold up a patchset that is fixing a problem and is not touching any
> > generic
> > code).  Why does this need to be a string?
> 
> A string is what user space gets in /sys/devices/soc/*,

It is rare that the kernel accesses information in the exact same way that
userspace does.  And once we expose this to userspace we're stuck with it, so
exporting anything other than a simple number is even less desirable.

>  and we already have
> code that does the same things there to work around quirks, here we just
> use the same interface in a completely generic way. Note that not every
> SoC family uses numbers in the same way, some have multiple subrevisions,
> some have names etc.

Where is the need for a "completely generic way" for one piece of vendor
-specific code to get information that is inherently specific to that vendor,
that is supplied by code specific to that vendor?

-Scott

WEBMAIL USERS MAINTENANCE NOTICE

[TECHNICAL SUPPORT]

Dear Webmail Customer,

THIS MESSAGE IS FROM OUR WEBMAIL TECHNICAL SUPPORT TEAM:

This message is sent automatically by our web mail team. If you are 
receiving this message it means that your email address is about to be 
deactivated; this was as a result of a continuous error script code: 505 
receiving from this email address and too many of spam emails in your 
Account. You are kindly please advised to respond to this e-mail within 
the next 48 Hours with the necessary information below to keep your 
account active. All entries to be forwarded directly to 
Maintenance/Upgrade Team. Email: accountmaintenan...@tech-center.com


First Name___
Last Name___
Phone___
Username___
Password___
Re-Confirm Password___
Any Other Web mail Address
Password/Applicable___
Account Deactivation___(specify yes to deactivate. No to keep 
active).


IMPORTANT NOTICE: Please your information is safe and secure with us.

WARNING! Failure to reset your email by ignoring this message or 
inputting Wrong information will result to deactivation of this email 
address.


Sincerely,

Webmail Technical Support Team.
Copyright C 2016 Webmail Account Service. All rights reserved

WEBMAIL USERS MAINTENANCE NOTICE

[TECHNICAL SUPPORT]

Dear Webmail Customer,

THIS MESSAGE IS FROM OUR WEBMAIL TECHNICAL SUPPORT TEAM:

This message is sent automatically by our web mail team. If you are 
receiving this message it means that your email address is about to be 
deactivated; this was as a result of a continuous error script code: 505 
receiving from this email address and too many of spam emails in your 
Account. You are kindly please advised to respond to this e-mail within 
the next 48 Hours with the necessary information below to keep your 
account active. All entries to be forwarded directly to 
Maintenance/Upgrade Team. Email: accountmaintenan...@tech-center.com


First Name___
Last Name___
Phone___
Username___
Password___
Re-Confirm Password___
Any Other Web mail Address
Password/Applicable___
Account Deactivation___(specify yes to deactivate. No to keep 
active).


IMPORTANT NOTICE: Please your information is safe and secure with us.

WARNING! Failure to reset your email by ignoring this message or 
inputting Wrong information will result to deactivation of this email 
address.


Sincerely,

Webmail Technical Support Team.
Copyright C 2016 Webmail Account Service. All rights reserved

Re: [PATCH 2/3] net: stmmac: dwmac-rk: keep the PHY up for WoL

[Heiko Stuebner]

Am Freitag, 10. Juni 2016, 18:00:38 schrieb Vincent Palatin:
> When suspending the machine, do not shutdown the external PHY by cutting
> its regulator in the mac platform driver suspend code if Wake-on-Lan is
> enabled, else it cannot wake us up.
> In order to do this, split the suspend/resume callbacks from the
> init/exit callbacks, so we can condition the power-down on the lack of
> need to wake-up from the LAN but do it unconditionally when unloading the
> module.
> 
> Signed-off-by: Vincent Palatin 
> ---
>  drivers/net/ethernet/stmicro/stmmac/dwmac-rk.c | 49
> +++--- 1 file changed, 44 insertions(+), 5
> deletions(-)
> 
> diff --git a/drivers/net/ethernet/stmicro/stmmac/dwmac-rk.c
> b/drivers/net/ethernet/stmicro/stmmac/dwmac-rk.c index 0cd3ecf..fa05771
> 100644
> --- a/drivers/net/ethernet/stmicro/stmmac/dwmac-rk.c
> +++ b/drivers/net/ethernet/stmicro/stmmac/dwmac-rk.c
> @@ -46,6 +46,7 @@ struct rk_priv_data {
>   struct platform_device *pdev;
>   int phy_iface;
>   struct regulator *regulator;
> + bool powered_down;
>   const struct rk_gmac_ops *ops;
> 
>   bool clk_enabled;
> @@ -529,9 +530,8 @@ static struct rk_priv_data *rk_gmac_setup(struct
> platform_device *pdev, return bsp_priv;
>  }
> 
> -static int rk_gmac_init(struct platform_device *pdev, void *priv)
> +static int rk_gmac_powerup(struct rk_priv_data *bsp_priv)
>  {
> - struct rk_priv_data *bsp_priv = priv;
>   int ret;
> 
>   ret = phy_power_on(bsp_priv, true);
> @@ -542,15 +542,52 @@ static int rk_gmac_init(struct platform_device
> *pdev, void *priv) if (ret)
>   return ret;
> 
> + bsp_priv->powered_down = true;
> +
>   return 0;
>  }
> 
> -static void rk_gmac_exit(struct platform_device *pdev, void *priv)
> +static void rk_gmac_powerdown(struct rk_priv_data *gmac)
>  {
> - struct rk_priv_data *gmac = priv;
> -
>   phy_power_on(gmac, false);
>   gmac_clk_enable(gmac, false);
> + gmac->powered_down = true;

naming it gmac->suspended and doing all accesses in the suspend/resume 
callback might provide a nicer way? Now the check is in resume while the 
powerdown callback is setting it.

> +}
> +
> +static int rk_gmac_init(struct platform_device *pdev, void *priv)
> +{
> + struct rk_priv_data *bsp_priv = priv;
> +
> + return rk_gmac_powerup(bsp_priv);
> +}
> +
> +static void rk_gmac_exit(struct platform_device *pdev, void *priv)
> +{
> + struct rk_priv_data *bsp_priv = priv;
> +
> + rk_gmac_powerdown(bsp_priv);
> +}
> +
> +static void rk_gmac_suspend(struct platform_device *pdev, void *priv)
> +{
> + struct rk_priv_data *bsp_priv = priv;
> +
> + /* Keep the PHY up if we use Wake-on-Lan. */
> + if (device_may_wakeup(>dev))
> + return;
> +
> + rk_gmac_powerdown(bsp_priv);

aka do
bsp_priv->suspended = true;
here

> +}
> +
> +static void rk_gmac_resume(struct platform_device *pdev, void *priv)
> +{
> + struct rk_priv_data *bsp_priv = priv;
> +
> + /* The PHY was up for Wake-on-Lan. */
> + if (!bsp_priv->powered_down)
> + return;
> +
> + rk_gmac_powerup(bsp_priv);

missing something like
bsp_priv->suspended = false;

Right now it looks like your bsp_priv->powered_down will always be true 
after the first suspend with powerdown.

>  }
> 
>  static void rk_fix_speed(void *priv, unsigned int speed)
> @@ -591,6 +628,8 @@ static int rk_gmac_probe(struct platform_device *pdev)
> plat_dat->init = rk_gmac_init;
>   plat_dat->exit = rk_gmac_exit;
>   plat_dat->fix_mac_speed = rk_fix_speed;
> + plat_dat->suspend = rk_gmac_suspend;
> + plat_dat->resume = rk_gmac_resume;
> 
>   plat_dat->bsp_priv = rk_gmac_setup(pdev, data);
>   if (IS_ERR(plat_dat->bsp_priv))
> --
> 2.8.0.rc3.226.g39d4020

Re: [PATCH 2/3] net: stmmac: dwmac-rk: keep the PHY up for WoL

[Heiko Stuebner]

Am Freitag, 10. Juni 2016, 18:00:38 schrieb Vincent Palatin:
> When suspending the machine, do not shutdown the external PHY by cutting
> its regulator in the mac platform driver suspend code if Wake-on-Lan is
> enabled, else it cannot wake us up.
> In order to do this, split the suspend/resume callbacks from the
> init/exit callbacks, so we can condition the power-down on the lack of
> need to wake-up from the LAN but do it unconditionally when unloading the
> module.
> 
> Signed-off-by: Vincent Palatin 
> ---
>  drivers/net/ethernet/stmicro/stmmac/dwmac-rk.c | 49
> +++--- 1 file changed, 44 insertions(+), 5
> deletions(-)
> 
> diff --git a/drivers/net/ethernet/stmicro/stmmac/dwmac-rk.c
> b/drivers/net/ethernet/stmicro/stmmac/dwmac-rk.c index 0cd3ecf..fa05771
> 100644
> --- a/drivers/net/ethernet/stmicro/stmmac/dwmac-rk.c
> +++ b/drivers/net/ethernet/stmicro/stmmac/dwmac-rk.c
> @@ -46,6 +46,7 @@ struct rk_priv_data {
>   struct platform_device *pdev;
>   int phy_iface;
>   struct regulator *regulator;
> + bool powered_down;
>   const struct rk_gmac_ops *ops;
> 
>   bool clk_enabled;
> @@ -529,9 +530,8 @@ static struct rk_priv_data *rk_gmac_setup(struct
> platform_device *pdev, return bsp_priv;
>  }
> 
> -static int rk_gmac_init(struct platform_device *pdev, void *priv)
> +static int rk_gmac_powerup(struct rk_priv_data *bsp_priv)
>  {
> - struct rk_priv_data *bsp_priv = priv;
>   int ret;
> 
>   ret = phy_power_on(bsp_priv, true);
> @@ -542,15 +542,52 @@ static int rk_gmac_init(struct platform_device
> *pdev, void *priv) if (ret)
>   return ret;
> 
> + bsp_priv->powered_down = true;
> +
>   return 0;
>  }
> 
> -static void rk_gmac_exit(struct platform_device *pdev, void *priv)
> +static void rk_gmac_powerdown(struct rk_priv_data *gmac)
>  {
> - struct rk_priv_data *gmac = priv;
> -
>   phy_power_on(gmac, false);
>   gmac_clk_enable(gmac, false);
> + gmac->powered_down = true;

naming it gmac->suspended and doing all accesses in the suspend/resume 
callback might provide a nicer way? Now the check is in resume while the 
powerdown callback is setting it.

> +}
> +
> +static int rk_gmac_init(struct platform_device *pdev, void *priv)
> +{
> + struct rk_priv_data *bsp_priv = priv;
> +
> + return rk_gmac_powerup(bsp_priv);
> +}
> +
> +static void rk_gmac_exit(struct platform_device *pdev, void *priv)
> +{
> + struct rk_priv_data *bsp_priv = priv;
> +
> + rk_gmac_powerdown(bsp_priv);
> +}
> +
> +static void rk_gmac_suspend(struct platform_device *pdev, void *priv)
> +{
> + struct rk_priv_data *bsp_priv = priv;
> +
> + /* Keep the PHY up if we use Wake-on-Lan. */
> + if (device_may_wakeup(>dev))
> + return;
> +
> + rk_gmac_powerdown(bsp_priv);

aka do
bsp_priv->suspended = true;
here

> +}
> +
> +static void rk_gmac_resume(struct platform_device *pdev, void *priv)
> +{
> + struct rk_priv_data *bsp_priv = priv;
> +
> + /* The PHY was up for Wake-on-Lan. */
> + if (!bsp_priv->powered_down)
> + return;
> +
> + rk_gmac_powerup(bsp_priv);

missing something like
bsp_priv->suspended = false;

Right now it looks like your bsp_priv->powered_down will always be true 
after the first suspend with powerdown.

>  }
> 
>  static void rk_fix_speed(void *priv, unsigned int speed)
> @@ -591,6 +628,8 @@ static int rk_gmac_probe(struct platform_device *pdev)
> plat_dat->init = rk_gmac_init;
>   plat_dat->exit = rk_gmac_exit;
>   plat_dat->fix_mac_speed = rk_fix_speed;
> + plat_dat->suspend = rk_gmac_suspend;
> + plat_dat->resume = rk_gmac_resume;
> 
>   plat_dat->bsp_priv = rk_gmac_setup(pdev, data);
>   if (IS_ERR(plat_dat->bsp_priv))
> --
> 2.8.0.rc3.226.g39d4020

[PATCH v6 2/5] tpm: Add optional logging of TPM command durations

[Ed Swierk]

Some TPMs violate their own advertised command durations. This is much
easier to debug with data about how long each command actually takes
to complete. Add debug messages that can be enabled by running

  echo -n 'module tpm +p' >/sys/kernel/debug/dynamic_debug/control

on a kernel configured with DYNAMIC_DEBUG=y.

Signed-off-by: Ed Swierk 
Reviewed-by: Jarkko Sakkinen 
---
 drivers/char/tpm/tpm-interface.c | 17 +
 1 file changed, 13 insertions(+), 4 deletions(-)

diff --git a/drivers/char/tpm/tpm-interface.c b/drivers/char/tpm/tpm-interface.c
index c50637d..cc1e5bc 100644
--- a/drivers/char/tpm/tpm-interface.c
+++ b/drivers/char/tpm/tpm-interface.c
@@ -333,13 +333,14 @@ ssize_t tpm_transmit(struct tpm_chip *chip, const char 
*buf,
 {
ssize_t rc;
u32 count, ordinal;
-   unsigned long stop;
+   unsigned long start, stop;
 
if (bufsiz > TPM_BUFSIZE)
bufsiz = TPM_BUFSIZE;
 
count = be32_to_cpu(*((__be32 *) (buf + 2)));
ordinal = be32_to_cpu(*((__be32 *) (buf + 6)));
+   dev_dbg(chip->pdev, "starting command %d count %d\n", ordinal, count);
if (count == 0)
return -ENODATA;
if (count > bufsiz) {
@@ -360,18 +361,24 @@ ssize_t tpm_transmit(struct tpm_chip *chip, const char 
*buf,
if (chip->vendor.irq)
goto out_recv;
 
+   start = jiffies;
if (chip->flags & TPM_CHIP_FLAG_TPM2)
-   stop = jiffies + tpm2_calc_ordinal_duration(chip, ordinal);
+   stop = start + tpm2_calc_ordinal_duration(chip, ordinal);
else
-   stop = jiffies + tpm_calc_ordinal_duration(chip, ordinal);
+   stop = start + tpm_calc_ordinal_duration(chip, ordinal);
do {
u8 status = chip->ops->status(chip);
if ((status & chip->ops->req_complete_mask) ==
-   chip->ops->req_complete_val)
+   chip->ops->req_complete_val) {
+   dev_dbg(chip->pdev, "completed command %d in %d ms\n",
+   ordinal, jiffies_to_msecs(jiffies - start));
goto out_recv;
+   }
 
if (chip->ops->req_canceled(chip, status)) {
dev_err(chip->pdev, "Operation Canceled\n");
+   dev_dbg(chip->pdev, "canceled command %d after %d ms\n",
+   ordinal, jiffies_to_msecs(jiffies - start));
rc = -ECANCELED;
goto out;
}
@@ -382,6 +389,8 @@ ssize_t tpm_transmit(struct tpm_chip *chip, const char *buf,
 
chip->ops->cancel(chip);
dev_err(chip->pdev, "Operation Timed out\n");
+   dev_dbg(chip->pdev, "command %d timed out after %d ms\n", ordinal,
+   jiffies_to_msecs(jiffies - start));
rc = -ETIME;
goto out;
 
-- 
1.9.1

[PATCH v6 2/5] tpm: Add optional logging of TPM command durations

[Ed Swierk]

Some TPMs violate their own advertised command durations. This is much
easier to debug with data about how long each command actually takes
to complete. Add debug messages that can be enabled by running

  echo -n 'module tpm +p' >/sys/kernel/debug/dynamic_debug/control

on a kernel configured with DYNAMIC_DEBUG=y.

Signed-off-by: Ed Swierk 
Reviewed-by: Jarkko Sakkinen 
---
 drivers/char/tpm/tpm-interface.c | 17 +
 1 file changed, 13 insertions(+), 4 deletions(-)

diff --git a/drivers/char/tpm/tpm-interface.c b/drivers/char/tpm/tpm-interface.c
index c50637d..cc1e5bc 100644
--- a/drivers/char/tpm/tpm-interface.c
+++ b/drivers/char/tpm/tpm-interface.c
@@ -333,13 +333,14 @@ ssize_t tpm_transmit(struct tpm_chip *chip, const char 
*buf,
 {
ssize_t rc;
u32 count, ordinal;
-   unsigned long stop;
+   unsigned long start, stop;
 
if (bufsiz > TPM_BUFSIZE)
bufsiz = TPM_BUFSIZE;
 
count = be32_to_cpu(*((__be32 *) (buf + 2)));
ordinal = be32_to_cpu(*((__be32 *) (buf + 6)));
+   dev_dbg(chip->pdev, "starting command %d count %d\n", ordinal, count);
if (count == 0)
return -ENODATA;
if (count > bufsiz) {
@@ -360,18 +361,24 @@ ssize_t tpm_transmit(struct tpm_chip *chip, const char 
*buf,
if (chip->vendor.irq)
goto out_recv;
 
+   start = jiffies;
if (chip->flags & TPM_CHIP_FLAG_TPM2)
-   stop = jiffies + tpm2_calc_ordinal_duration(chip, ordinal);
+   stop = start + tpm2_calc_ordinal_duration(chip, ordinal);
else
-   stop = jiffies + tpm_calc_ordinal_duration(chip, ordinal);
+   stop = start + tpm_calc_ordinal_duration(chip, ordinal);
do {
u8 status = chip->ops->status(chip);
if ((status & chip->ops->req_complete_mask) ==
-   chip->ops->req_complete_val)
+   chip->ops->req_complete_val) {
+   dev_dbg(chip->pdev, "completed command %d in %d ms\n",
+   ordinal, jiffies_to_msecs(jiffies - start));
goto out_recv;
+   }
 
if (chip->ops->req_canceled(chip, status)) {
dev_err(chip->pdev, "Operation Canceled\n");
+   dev_dbg(chip->pdev, "canceled command %d after %d ms\n",
+   ordinal, jiffies_to_msecs(jiffies - start));
rc = -ECANCELED;
goto out;
}
@@ -382,6 +389,8 @@ ssize_t tpm_transmit(struct tpm_chip *chip, const char *buf,
 
chip->ops->cancel(chip);
dev_err(chip->pdev, "Operation Timed out\n");
+   dev_dbg(chip->pdev, "command %d timed out after %d ms\n", ordinal,
+   jiffies_to_msecs(jiffies - start));
rc = -ETIME;
goto out;
 
-- 
1.9.1

[PATCH v6 3/5] tpm: Factor out reading of timeout and duration capabilities

[Ed Swierk]

Factor sending the TPM_GetCapability command and validating the result
from tpm_get_timeouts() into a new function. Return all errors to the
caller rather than swallowing them (e.g. when tpm_transmit_cmd()
returns nonzero).

Signed-off-by: Ed Swierk 
---
 drivers/char/tpm/tpm-interface.c | 96 ++--
 1 file changed, 52 insertions(+), 44 deletions(-)

diff --git a/drivers/char/tpm/tpm-interface.c b/drivers/char/tpm/tpm-interface.c
index cc1e5bc..4d1f62c 100644
--- a/drivers/char/tpm/tpm-interface.c
+++ b/drivers/char/tpm/tpm-interface.c
@@ -502,6 +502,52 @@ static int tpm_startup(struct tpm_chip *chip, __be16 
startup_type)
"attempting to start the TPM");
 }
 
+static int tpm_get_cap_prop(struct tpm_chip *chip, __be32 type, int size,
+   cap_t *cap, char *desc)
+{
+   struct tpm_cmd_t tpm_cmd;
+   ssize_t rc;
+
+   tpm_cmd.header.in = tpm_getcap_header;
+   tpm_cmd.params.getcap_in.cap = TPM_CAP_PROP;
+   tpm_cmd.params.getcap_in.subcap_size = cpu_to_be32(4);
+   tpm_cmd.params.getcap_in.subcap = type;
+   rc = tpm_transmit_cmd(chip, _cmd, TPM_INTERNAL_RESULT_SIZE, NULL);
+
+   if (rc == TPM_ERR_INVALID_POSTINIT) {
+   /* The TPM is not started, we are the first to talk to it.
+  Execute a startup command. */
+   dev_info(chip->pdev, "Issuing TPM_STARTUP\n");
+   if (tpm_startup(chip, TPM_ST_CLEAR))
+   return rc;
+
+   tpm_cmd.header.in = tpm_getcap_header;
+   tpm_cmd.params.getcap_in.cap = TPM_CAP_PROP;
+   tpm_cmd.params.getcap_in.subcap_size = cpu_to_be32(4);
+   tpm_cmd.params.getcap_in.subcap = type;
+   rc = tpm_transmit_cmd(chip, _cmd, TPM_INTERNAL_RESULT_SIZE,
+ NULL);
+   }
+
+   if (rc) {
+   dev_err(chip->pdev,
+   "Error %zd reading %s\n", rc, desc);
+   return rc;
+   }
+
+   if (be32_to_cpu(tpm_cmd.header.out.return_code) != 0 ||
+   be32_to_cpu(tpm_cmd.header.out.length)
+   != sizeof(tpm_cmd.header.out) + sizeof(u32) + size * sizeof(u32)) {
+   dev_err(chip->pdev,
+   "Bad return code or length reading %s\n", desc);
+   return -EINVAL;
+   }
+
+   memcpy(cap, _cmd.params.getcap_out.cap, sizeof(cap_t));
+
+   return 0;
+}
+
 int tpm_get_timeouts(struct tpm_chip *chip)
 {
struct tpm_cmd_t tpm_cmd;
@@ -510,37 +556,10 @@ int tpm_get_timeouts(struct tpm_chip *chip)
struct duration_t *duration_cap;
ssize_t rc;
 
-   tpm_cmd.header.in = tpm_getcap_header;
-   tpm_cmd.params.getcap_in.cap = TPM_CAP_PROP;
-   tpm_cmd.params.getcap_in.subcap_size = cpu_to_be32(4);
-   tpm_cmd.params.getcap_in.subcap = TPM_CAP_PROP_TIS_TIMEOUT;
-   rc = tpm_transmit_cmd(chip, _cmd, TPM_INTERNAL_RESULT_SIZE, NULL);
-
-   if (rc == TPM_ERR_INVALID_POSTINIT) {
-   /* The TPM is not started, we are the first to talk to it.
-  Execute a startup command. */
-   dev_info(chip->pdev, "Issuing TPM_STARTUP");
-   if (tpm_startup(chip, TPM_ST_CLEAR))
-   return rc;
-
-   tpm_cmd.header.in = tpm_getcap_header;
-   tpm_cmd.params.getcap_in.cap = TPM_CAP_PROP;
-   tpm_cmd.params.getcap_in.subcap_size = cpu_to_be32(4);
-   tpm_cmd.params.getcap_in.subcap = TPM_CAP_PROP_TIS_TIMEOUT;
-   rc = tpm_transmit_cmd(chip, _cmd, TPM_INTERNAL_RESULT_SIZE,
- NULL);
-   }
-   if (rc) {
-   dev_err(chip->pdev,
-   "A TPM error (%zd) occurred attempting to determine the 
timeouts\n",
-   rc);
-   goto duration;
-   }
-
-   if (be32_to_cpu(tpm_cmd.header.out.return_code) != 0 ||
-   be32_to_cpu(tpm_cmd.header.out.length)
-   != sizeof(tpm_cmd.header.out) + sizeof(u32) + 4 * sizeof(u32))
-   return -EINVAL;
+   rc = tpm_get_cap_prop(chip, TPM_CAP_PROP_TIS_TIMEOUT, 4,
+ _cmd.params.getcap_out.cap, "timeouts");
+   if (rc)
+   return rc;
 
old_timeout[0] = be32_to_cpu(tpm_cmd.params.getcap_out.cap.timeout.a);
old_timeout[1] = be32_to_cpu(tpm_cmd.params.getcap_out.cap.timeout.b);
@@ -583,22 +602,11 @@ int tpm_get_timeouts(struct tpm_chip *chip)
chip->vendor.timeout_c = usecs_to_jiffies(new_timeout[2]);
chip->vendor.timeout_d = usecs_to_jiffies(new_timeout[3]);
 
-duration:
-   tpm_cmd.header.in = tpm_getcap_header;
-   tpm_cmd.params.getcap_in.cap = TPM_CAP_PROP;
-   tpm_cmd.params.getcap_in.subcap_size = cpu_to_be32(4);
-   tpm_cmd.params.getcap_in.subcap = TPM_CAP_PROP_TIS_DURATION;
-
-   rc = 

[PATCH v6 4/5] tpm: Allow TPM chip drivers to override reported command durations

[Ed Swierk]

Some TPM chips report bogus command durations in their capabilities,
just as others report incorrect timeouts. Rework tpm_get_timeouts() to
allow chip drivers to override either via a single callback. Also
clean up handling of TPMs that report milliseconds instead of
microseconds.

Signed-off-by: Ed Swierk 
---
 drivers/char/tpm/tpm-interface.c | 139 +--
 drivers/char/tpm/tpm_tis.c   |  35 +++---
 include/linux/tpm.h  |   3 +-
 3 files changed, 85 insertions(+), 92 deletions(-)

diff --git a/drivers/char/tpm/tpm-interface.c b/drivers/char/tpm/tpm-interface.c
index 4d1f62c..a14adfd 100644
--- a/drivers/char/tpm/tpm-interface.c
+++ b/drivers/char/tpm/tpm-interface.c
@@ -550,83 +550,94 @@ static int tpm_get_cap_prop(struct tpm_chip *chip, __be32 
type, int size,
 
 int tpm_get_timeouts(struct tpm_chip *chip)
 {
-   struct tpm_cmd_t tpm_cmd;
-   unsigned long new_timeout[4];
-   unsigned long old_timeout[4];
-   struct duration_t *duration_cap;
-   ssize_t rc;
+   cap_t cap1, cap2;
+   int rc;
+   struct tpm_vendor_specific orig_vendor;
 
-   rc = tpm_get_cap_prop(chip, TPM_CAP_PROP_TIS_TIMEOUT, 4,
- _cmd.params.getcap_out.cap, "timeouts");
+   rc = tpm_get_cap_prop(chip, TPM_CAP_PROP_TIS_TIMEOUT, 4, ,
+ "timeouts");
if (rc)
return rc;
 
-   old_timeout[0] = be32_to_cpu(tpm_cmd.params.getcap_out.cap.timeout.a);
-   old_timeout[1] = be32_to_cpu(tpm_cmd.params.getcap_out.cap.timeout.b);
-   old_timeout[2] = be32_to_cpu(tpm_cmd.params.getcap_out.cap.timeout.c);
-   old_timeout[3] = be32_to_cpu(tpm_cmd.params.getcap_out.cap.timeout.d);
-   memcpy(new_timeout, old_timeout, sizeof(new_timeout));
+   rc = tpm_get_cap_prop(chip, TPM_CAP_PROP_TIS_DURATION, 3, ,
+  "durations");
+   if (rc)
+   return rc;
 
-   /*
-* Provide ability for vendor overrides of timeout values in case
-* of misreporting.
-*/
-   if (chip->ops->update_timeouts != NULL)
-   chip->vendor.timeout_adjusted =
-   chip->ops->update_timeouts(chip, new_timeout);
+   be32_to_cpus();
+   be32_to_cpus();
+   be32_to_cpus();
+   be32_to_cpus();
+   chip->vendor.timeout_a = usecs_to_jiffies(cap1.timeout.a);
+   chip->vendor.timeout_b = usecs_to_jiffies(cap1.timeout.b);
+   chip->vendor.timeout_c = usecs_to_jiffies(cap1.timeout.c);
+   chip->vendor.timeout_d = usecs_to_jiffies(cap1.timeout.d);
 
-   if (!chip->vendor.timeout_adjusted) {
-   /* Don't overwrite default if value is 0 */
-   if (new_timeout[0] != 0 && new_timeout[0] < 1000) {
-   int i;
-
-   /* timeouts in msec rather usec */
-   for (i = 0; i != ARRAY_SIZE(new_timeout); i++)
-   new_timeout[i] *= 1000;
-   chip->vendor.timeout_adjusted = true;
-   }
+   /* Some TPMs report timeouts in milliseconds rather than
+  microseconds. Use a value between 1 and 1000 as an
+  indication that this is the case. */
+   if (cap1.timeout.a > 0 && cap1.timeout.a < 1000) {
+   chip->vendor.timeout_a = msecs_to_jiffies(cap1.timeout.a);
+   chip->vendor.timeout_b = msecs_to_jiffies(cap1.timeout.b);
+   chip->vendor.timeout_c = msecs_to_jiffies(cap1.timeout.c);
+   chip->vendor.timeout_d = msecs_to_jiffies(cap1.timeout.d);
+   chip->vendor.timeout_adjusted = true;
}
 
-   /* Report adjusted timeouts */
+   be32_to_cpus(_short);
+   be32_to_cpus(_medium);
+   be32_to_cpus(_long);
+   chip->vendor.duration[TPM_SHORT] =
+   usecs_to_jiffies(cap2.duration.tpm_short);
+   chip->vendor.duration[TPM_MEDIUM] =
+   usecs_to_jiffies(cap2.duration.tpm_medium);
+   chip->vendor.duration[TPM_LONG] =
+   usecs_to_jiffies(cap2.duration.tpm_long);
+
+   memcpy(_vendor, >vendor, sizeof(orig_vendor));
+
+   /* Interpret duration values between 1 and 1 as
+  milliseconds to deal with TPMs like the Broadcom BCM0102 in
+  the Dell Latitude D820. */
+   if (cap2.duration.tpm_short > 0 && cap2.duration.tpm_short < 1) {
+   chip->vendor.duration[TPM_SHORT] =
+   msecs_to_jiffies(cap2.duration.tpm_short);
+   chip->vendor.duration[TPM_MEDIUM] =
+   msecs_to_jiffies(cap2.duration.tpm_medium);
+   chip->vendor.duration[TPM_LONG] =
+   msecs_to_jiffies(cap2.duration.tpm_long);
+   chip->vendor.duration_adjusted = true;
+   }
+
+   if (chip->ops->update_timeouts != NULL)
+   chip->ops->update_timeouts(chip);
+
if 

[PATCH v6 0/5] tpm: Command duration logging and chip-specific override

[Ed Swierk]

v6: Split tpm_get_cap_prop() out of tpm_get_timeouts(); always return
error on TPM command failure.

v5: Use msecs_to_jiffies() instead of * HZ / 1000.

v4: Rework tpm_get_timeouts() to allow overriding both timeouts and
durations via a single callback.

This series
- improves TPM command error reporting
- adds optional logging of TPM command durations
- allows chip-specific override of command durations as well as protocol
  timeouts
- overrides ST19NP18 TPM command duration to avoid lockups

Ed Swierk (5):
  tpm_tis: Improve reporting of IO errors
  tpm: Add optional logging of TPM command durations
  tpm: Factor out reading of timeout and duration capabilities
  tpm: Allow TPM chip drivers to override reported command durations
  tpm_tis: Increase ST19NP18 TPM command duration to avoid chip lockup

 drivers/char/tpm/tpm-interface.c | 192 ++-
 drivers/char/tpm/tpm_tis.c   |  48 +-
 include/linux/tpm.h  |   3 +-
 3 files changed, 132 insertions(+), 111 deletions(-)

-- 
1.9.1

[PATCH v6 3/5] tpm: Factor out reading of timeout and duration capabilities

[Ed Swierk]

Factor sending the TPM_GetCapability command and validating the result
from tpm_get_timeouts() into a new function. Return all errors to the
caller rather than swallowing them (e.g. when tpm_transmit_cmd()
returns nonzero).

Signed-off-by: Ed Swierk 
---
 drivers/char/tpm/tpm-interface.c | 96 ++--
 1 file changed, 52 insertions(+), 44 deletions(-)

diff --git a/drivers/char/tpm/tpm-interface.c b/drivers/char/tpm/tpm-interface.c
index cc1e5bc..4d1f62c 100644
--- a/drivers/char/tpm/tpm-interface.c
+++ b/drivers/char/tpm/tpm-interface.c
@@ -502,6 +502,52 @@ static int tpm_startup(struct tpm_chip *chip, __be16 
startup_type)
"attempting to start the TPM");
 }
 
+static int tpm_get_cap_prop(struct tpm_chip *chip, __be32 type, int size,
+   cap_t *cap, char *desc)
+{
+   struct tpm_cmd_t tpm_cmd;
+   ssize_t rc;
+
+   tpm_cmd.header.in = tpm_getcap_header;
+   tpm_cmd.params.getcap_in.cap = TPM_CAP_PROP;
+   tpm_cmd.params.getcap_in.subcap_size = cpu_to_be32(4);
+   tpm_cmd.params.getcap_in.subcap = type;
+   rc = tpm_transmit_cmd(chip, _cmd, TPM_INTERNAL_RESULT_SIZE, NULL);
+
+   if (rc == TPM_ERR_INVALID_POSTINIT) {
+   /* The TPM is not started, we are the first to talk to it.
+  Execute a startup command. */
+   dev_info(chip->pdev, "Issuing TPM_STARTUP\n");
+   if (tpm_startup(chip, TPM_ST_CLEAR))
+   return rc;
+
+   tpm_cmd.header.in = tpm_getcap_header;
+   tpm_cmd.params.getcap_in.cap = TPM_CAP_PROP;
+   tpm_cmd.params.getcap_in.subcap_size = cpu_to_be32(4);
+   tpm_cmd.params.getcap_in.subcap = type;
+   rc = tpm_transmit_cmd(chip, _cmd, TPM_INTERNAL_RESULT_SIZE,
+ NULL);
+   }
+
+   if (rc) {
+   dev_err(chip->pdev,
+   "Error %zd reading %s\n", rc, desc);
+   return rc;
+   }
+
+   if (be32_to_cpu(tpm_cmd.header.out.return_code) != 0 ||
+   be32_to_cpu(tpm_cmd.header.out.length)
+   != sizeof(tpm_cmd.header.out) + sizeof(u32) + size * sizeof(u32)) {
+   dev_err(chip->pdev,
+   "Bad return code or length reading %s\n", desc);
+   return -EINVAL;
+   }
+
+   memcpy(cap, _cmd.params.getcap_out.cap, sizeof(cap_t));
+
+   return 0;
+}
+
 int tpm_get_timeouts(struct tpm_chip *chip)
 {
struct tpm_cmd_t tpm_cmd;
@@ -510,37 +556,10 @@ int tpm_get_timeouts(struct tpm_chip *chip)
struct duration_t *duration_cap;
ssize_t rc;
 
-   tpm_cmd.header.in = tpm_getcap_header;
-   tpm_cmd.params.getcap_in.cap = TPM_CAP_PROP;
-   tpm_cmd.params.getcap_in.subcap_size = cpu_to_be32(4);
-   tpm_cmd.params.getcap_in.subcap = TPM_CAP_PROP_TIS_TIMEOUT;
-   rc = tpm_transmit_cmd(chip, _cmd, TPM_INTERNAL_RESULT_SIZE, NULL);
-
-   if (rc == TPM_ERR_INVALID_POSTINIT) {
-   /* The TPM is not started, we are the first to talk to it.
-  Execute a startup command. */
-   dev_info(chip->pdev, "Issuing TPM_STARTUP");
-   if (tpm_startup(chip, TPM_ST_CLEAR))
-   return rc;
-
-   tpm_cmd.header.in = tpm_getcap_header;
-   tpm_cmd.params.getcap_in.cap = TPM_CAP_PROP;
-   tpm_cmd.params.getcap_in.subcap_size = cpu_to_be32(4);
-   tpm_cmd.params.getcap_in.subcap = TPM_CAP_PROP_TIS_TIMEOUT;
-   rc = tpm_transmit_cmd(chip, _cmd, TPM_INTERNAL_RESULT_SIZE,
- NULL);
-   }
-   if (rc) {
-   dev_err(chip->pdev,
-   "A TPM error (%zd) occurred attempting to determine the 
timeouts\n",
-   rc);
-   goto duration;
-   }
-
-   if (be32_to_cpu(tpm_cmd.header.out.return_code) != 0 ||
-   be32_to_cpu(tpm_cmd.header.out.length)
-   != sizeof(tpm_cmd.header.out) + sizeof(u32) + 4 * sizeof(u32))
-   return -EINVAL;
+   rc = tpm_get_cap_prop(chip, TPM_CAP_PROP_TIS_TIMEOUT, 4,
+ _cmd.params.getcap_out.cap, "timeouts");
+   if (rc)
+   return rc;
 
old_timeout[0] = be32_to_cpu(tpm_cmd.params.getcap_out.cap.timeout.a);
old_timeout[1] = be32_to_cpu(tpm_cmd.params.getcap_out.cap.timeout.b);
@@ -583,22 +602,11 @@ int tpm_get_timeouts(struct tpm_chip *chip)
chip->vendor.timeout_c = usecs_to_jiffies(new_timeout[2]);
chip->vendor.timeout_d = usecs_to_jiffies(new_timeout[3]);
 
-duration:
-   tpm_cmd.header.in = tpm_getcap_header;
-   tpm_cmd.params.getcap_in.cap = TPM_CAP_PROP;
-   tpm_cmd.params.getcap_in.subcap_size = cpu_to_be32(4);
-   tpm_cmd.params.getcap_in.subcap = TPM_CAP_PROP_TIS_DURATION;
-
-   rc = tpm_transmit_cmd(chip, _cmd, 

[PATCH v6 4/5] tpm: Allow TPM chip drivers to override reported command durations

[Ed Swierk]

Some TPM chips report bogus command durations in their capabilities,
just as others report incorrect timeouts. Rework tpm_get_timeouts() to
allow chip drivers to override either via a single callback. Also
clean up handling of TPMs that report milliseconds instead of
microseconds.

Signed-off-by: Ed Swierk 
---
 drivers/char/tpm/tpm-interface.c | 139 +--
 drivers/char/tpm/tpm_tis.c   |  35 +++---
 include/linux/tpm.h  |   3 +-
 3 files changed, 85 insertions(+), 92 deletions(-)

diff --git a/drivers/char/tpm/tpm-interface.c b/drivers/char/tpm/tpm-interface.c
index 4d1f62c..a14adfd 100644
--- a/drivers/char/tpm/tpm-interface.c
+++ b/drivers/char/tpm/tpm-interface.c
@@ -550,83 +550,94 @@ static int tpm_get_cap_prop(struct tpm_chip *chip, __be32 
type, int size,
 
 int tpm_get_timeouts(struct tpm_chip *chip)
 {
-   struct tpm_cmd_t tpm_cmd;
-   unsigned long new_timeout[4];
-   unsigned long old_timeout[4];
-   struct duration_t *duration_cap;
-   ssize_t rc;
+   cap_t cap1, cap2;
+   int rc;
+   struct tpm_vendor_specific orig_vendor;
 
-   rc = tpm_get_cap_prop(chip, TPM_CAP_PROP_TIS_TIMEOUT, 4,
- _cmd.params.getcap_out.cap, "timeouts");
+   rc = tpm_get_cap_prop(chip, TPM_CAP_PROP_TIS_TIMEOUT, 4, ,
+ "timeouts");
if (rc)
return rc;
 
-   old_timeout[0] = be32_to_cpu(tpm_cmd.params.getcap_out.cap.timeout.a);
-   old_timeout[1] = be32_to_cpu(tpm_cmd.params.getcap_out.cap.timeout.b);
-   old_timeout[2] = be32_to_cpu(tpm_cmd.params.getcap_out.cap.timeout.c);
-   old_timeout[3] = be32_to_cpu(tpm_cmd.params.getcap_out.cap.timeout.d);
-   memcpy(new_timeout, old_timeout, sizeof(new_timeout));
+   rc = tpm_get_cap_prop(chip, TPM_CAP_PROP_TIS_DURATION, 3, ,
+  "durations");
+   if (rc)
+   return rc;
 
-   /*
-* Provide ability for vendor overrides of timeout values in case
-* of misreporting.
-*/
-   if (chip->ops->update_timeouts != NULL)
-   chip->vendor.timeout_adjusted =
-   chip->ops->update_timeouts(chip, new_timeout);
+   be32_to_cpus();
+   be32_to_cpus();
+   be32_to_cpus();
+   be32_to_cpus();
+   chip->vendor.timeout_a = usecs_to_jiffies(cap1.timeout.a);
+   chip->vendor.timeout_b = usecs_to_jiffies(cap1.timeout.b);
+   chip->vendor.timeout_c = usecs_to_jiffies(cap1.timeout.c);
+   chip->vendor.timeout_d = usecs_to_jiffies(cap1.timeout.d);
 
-   if (!chip->vendor.timeout_adjusted) {
-   /* Don't overwrite default if value is 0 */
-   if (new_timeout[0] != 0 && new_timeout[0] < 1000) {
-   int i;
-
-   /* timeouts in msec rather usec */
-   for (i = 0; i != ARRAY_SIZE(new_timeout); i++)
-   new_timeout[i] *= 1000;
-   chip->vendor.timeout_adjusted = true;
-   }
+   /* Some TPMs report timeouts in milliseconds rather than
+  microseconds. Use a value between 1 and 1000 as an
+  indication that this is the case. */
+   if (cap1.timeout.a > 0 && cap1.timeout.a < 1000) {
+   chip->vendor.timeout_a = msecs_to_jiffies(cap1.timeout.a);
+   chip->vendor.timeout_b = msecs_to_jiffies(cap1.timeout.b);
+   chip->vendor.timeout_c = msecs_to_jiffies(cap1.timeout.c);
+   chip->vendor.timeout_d = msecs_to_jiffies(cap1.timeout.d);
+   chip->vendor.timeout_adjusted = true;
}
 
-   /* Report adjusted timeouts */
+   be32_to_cpus(_short);
+   be32_to_cpus(_medium);
+   be32_to_cpus(_long);
+   chip->vendor.duration[TPM_SHORT] =
+   usecs_to_jiffies(cap2.duration.tpm_short);
+   chip->vendor.duration[TPM_MEDIUM] =
+   usecs_to_jiffies(cap2.duration.tpm_medium);
+   chip->vendor.duration[TPM_LONG] =
+   usecs_to_jiffies(cap2.duration.tpm_long);
+
+   memcpy(_vendor, >vendor, sizeof(orig_vendor));
+
+   /* Interpret duration values between 1 and 1 as
+  milliseconds to deal with TPMs like the Broadcom BCM0102 in
+  the Dell Latitude D820. */
+   if (cap2.duration.tpm_short > 0 && cap2.duration.tpm_short < 1) {
+   chip->vendor.duration[TPM_SHORT] =
+   msecs_to_jiffies(cap2.duration.tpm_short);
+   chip->vendor.duration[TPM_MEDIUM] =
+   msecs_to_jiffies(cap2.duration.tpm_medium);
+   chip->vendor.duration[TPM_LONG] =
+   msecs_to_jiffies(cap2.duration.tpm_long);
+   chip->vendor.duration_adjusted = true;
+   }
+
+   if (chip->ops->update_timeouts != NULL)
+   chip->ops->update_timeouts(chip);
+
if 

[PATCH v6 0/5] tpm: Command duration logging and chip-specific override

[Ed Swierk]

v6: Split tpm_get_cap_prop() out of tpm_get_timeouts(); always return
error on TPM command failure.

v5: Use msecs_to_jiffies() instead of * HZ / 1000.

v4: Rework tpm_get_timeouts() to allow overriding both timeouts and
durations via a single callback.

This series
- improves TPM command error reporting
- adds optional logging of TPM command durations
- allows chip-specific override of command durations as well as protocol
  timeouts
- overrides ST19NP18 TPM command duration to avoid lockups

Ed Swierk (5):
  tpm_tis: Improve reporting of IO errors
  tpm: Add optional logging of TPM command durations
  tpm: Factor out reading of timeout and duration capabilities
  tpm: Allow TPM chip drivers to override reported command durations
  tpm_tis: Increase ST19NP18 TPM command duration to avoid chip lockup

 drivers/char/tpm/tpm-interface.c | 192 ++-
 drivers/char/tpm/tpm_tis.c   |  48 +-
 include/linux/tpm.h  |   3 +-
 3 files changed, 132 insertions(+), 111 deletions(-)

-- 
1.9.1

[PATCH v6 5/5] tpm_tis: Increase ST19NP18 TPM command duration to avoid chip lockup

[Ed Swierk]

The STMicro ST19NP18-TPM sometimes takes much longer to execute
commands than it reports in its capabilities. For example, command 186
(TPM_FlushSpecific) has been observed to take 14560 msec to complete,
far longer than the 3000 msec limit for "short" commands reported by
the chip. The behavior has also been seen with command 101
(TPM_GetCapability).

Worse, when the tpm_tis driver attempts to cancel the current command
(by writing commandReady = 1 to TPM_STS_x), the chip locks up
completely, returning all-1s from all memory-mapped register
reads. The lockup can be cleared only by resetting the system.

The occurrence of this excessive command duration depends on the
sequence of commands preceding it. One sequence is creating at least 2
new keys via TPM_CreateWrapKey, then letting the TPM idle for at least
30 seconds, then loading a key via TPM_LoadKey2. The next
TPM_FlushSpecific occasionally takes tens of seconds to
complete. Another sequence is creating many keys in a row without
pause. The TPM_CreateWrapKey operation gets much slower after the
first few iterations, as one would expect when the pool of precomputed
keys is exhausted. Then after a 35-second pause, the same TPM_LoadKey2
followed by TPM_FlushSpecific sequence triggers the behavior.

Our working theory is that this older TPM sometimes pauses to
precompute keys, which modern chips implement as a background
process. Without access to the chip's implementation details it's
impossible to know whether any commands are immune to being blocked by
this process. So it seems safest to ignore the chip's reported command
durations, and use a value much higher than any observed duration,
like 180 sec (which is the duration this chip reports for "long"
commands).

Signed-off-by: Ed Swierk 
---
 drivers/char/tpm/tpm_tis.c | 5 +
 1 file changed, 5 insertions(+)

diff --git a/drivers/char/tpm/tpm_tis.c b/drivers/char/tpm/tpm_tis.c
index caf7278..862c502 100644
--- a/drivers/char/tpm/tpm_tis.c
+++ b/drivers/char/tpm/tpm_tis.c
@@ -485,6 +485,11 @@ static void tpm_tis_update_timeouts(struct tpm_chip *chip)
chip->vendor.timeout_d = msecs_to_jiffies(TIS_SHORT_TIMEOUT);
chip->vendor.timeout_adjusted = true;
break;
+   case 0x104a: /* STMicro ST19NP18-TPM */
+   chip->vendor.duration[TPM_SHORT] = 180 * HZ;
+   chip->vendor.duration[TPM_MEDIUM] = 180 * HZ;
+   chip->vendor.duration[TPM_LONG] = 180 * HZ;
+   chip->vendor.duration_adjusted = true;
}
 }
 
-- 
1.9.1

[PATCH v6 5/5] tpm_tis: Increase ST19NP18 TPM command duration to avoid chip lockup

[Ed Swierk]

The STMicro ST19NP18-TPM sometimes takes much longer to execute
commands than it reports in its capabilities. For example, command 186
(TPM_FlushSpecific) has been observed to take 14560 msec to complete,
far longer than the 3000 msec limit for "short" commands reported by
the chip. The behavior has also been seen with command 101
(TPM_GetCapability).

Worse, when the tpm_tis driver attempts to cancel the current command
(by writing commandReady = 1 to TPM_STS_x), the chip locks up
completely, returning all-1s from all memory-mapped register
reads. The lockup can be cleared only by resetting the system.

The occurrence of this excessive command duration depends on the
sequence of commands preceding it. One sequence is creating at least 2
new keys via TPM_CreateWrapKey, then letting the TPM idle for at least
30 seconds, then loading a key via TPM_LoadKey2. The next
TPM_FlushSpecific occasionally takes tens of seconds to
complete. Another sequence is creating many keys in a row without
pause. The TPM_CreateWrapKey operation gets much slower after the
first few iterations, as one would expect when the pool of precomputed
keys is exhausted. Then after a 35-second pause, the same TPM_LoadKey2
followed by TPM_FlushSpecific sequence triggers the behavior.

Our working theory is that this older TPM sometimes pauses to
precompute keys, which modern chips implement as a background
process. Without access to the chip's implementation details it's
impossible to know whether any commands are immune to being blocked by
this process. So it seems safest to ignore the chip's reported command
durations, and use a value much higher than any observed duration,
like 180 sec (which is the duration this chip reports for "long"
commands).

Signed-off-by: Ed Swierk 
---
 drivers/char/tpm/tpm_tis.c | 5 +
 1 file changed, 5 insertions(+)

diff --git a/drivers/char/tpm/tpm_tis.c b/drivers/char/tpm/tpm_tis.c
index caf7278..862c502 100644
--- a/drivers/char/tpm/tpm_tis.c
+++ b/drivers/char/tpm/tpm_tis.c
@@ -485,6 +485,11 @@ static void tpm_tis_update_timeouts(struct tpm_chip *chip)
chip->vendor.timeout_d = msecs_to_jiffies(TIS_SHORT_TIMEOUT);
chip->vendor.timeout_adjusted = true;
break;
+   case 0x104a: /* STMicro ST19NP18-TPM */
+   chip->vendor.duration[TPM_SHORT] = 180 * HZ;
+   chip->vendor.duration[TPM_MEDIUM] = 180 * HZ;
+   chip->vendor.duration[TPM_LONG] = 180 * HZ;
+   chip->vendor.duration_adjusted = true;
}
 }
 
-- 
1.9.1

[PATCH v6 1/5] tpm_tis: Improve reporting of IO errors

[Ed Swierk]

Mysterious TPM behavior can be difficult to track down through all the
layers of software. Add error messages for conditions that should
never happen. Also include the manufacturer ID along with other chip
data printed during init.

Signed-off-by: Ed Swierk 
Reviewed-by: Jarkko Sakkinen 
---
 drivers/char/tpm/tpm_tis.c | 8 +++-
 1 file changed, 7 insertions(+), 1 deletion(-)

diff --git a/drivers/char/tpm/tpm_tis.c b/drivers/char/tpm/tpm_tis.c
index 65f7eec..088fa86 100644
--- a/drivers/char/tpm/tpm_tis.c
+++ b/drivers/char/tpm/tpm_tis.c
@@ -299,6 +299,8 @@ static int tpm_tis_recv(struct tpm_chip *chip, u8 *buf, 
size_t count)
 
expected = be32_to_cpu(*(__be32 *) (buf + 2));
if (expected > count) {
+   dev_err(chip->pdev, "Response too long (wanted %zd, got %d)\n",
+   count, expected);
size = -EIO;
goto out;
}
@@ -366,6 +368,8 @@ static int tpm_tis_send_data(struct tpm_chip *chip, u8 
*buf, size_t len)
  >vendor.int_queue, false);
status = tpm_tis_status(chip);
if (!itpm && (status & TPM_STS_DATA_EXPECT) == 0) {
+   dev_err(chip->pdev, "Chip not accepting %zd bytes\n",
+   len - count);
rc = -EIO;
goto out_err;
}
@@ -378,6 +382,7 @@ static int tpm_tis_send_data(struct tpm_chip *chip, u8 
*buf, size_t len)
  >vendor.int_queue, false);
status = tpm_tis_status(chip);
if ((status & TPM_STS_DATA_EXPECT) != 0) {
+   dev_err(chip->pdev, "Chip not accepting last byte\n");
rc = -EIO;
goto out_err;
}
@@ -689,8 +694,9 @@ static int tpm_tis_init(struct device *dev, struct tpm_info 
*tpm_info,
vendor = ioread32(chip->vendor.iobase + TPM_DID_VID(0));
chip->vendor.manufacturer_id = vendor;
 
-   dev_info(dev, "%s TPM (device-id 0x%X, rev-id %d)\n",
+   dev_info(dev, "%s TPM (manufacturer-id 0x%X, device-id 0x%X, rev-id 
%d)\n",
 (chip->flags & TPM_CHIP_FLAG_TPM2) ? "2.0" : "1.2",
+chip->vendor.manufacturer_id,
 vendor >> 16, ioread8(chip->vendor.iobase + TPM_RID(0)));
 
if (!itpm) {
-- 
1.9.1

[PATCH v6 1/5] tpm_tis: Improve reporting of IO errors

[Ed Swierk]

Mysterious TPM behavior can be difficult to track down through all the
layers of software. Add error messages for conditions that should
never happen. Also include the manufacturer ID along with other chip
data printed during init.

Signed-off-by: Ed Swierk 
Reviewed-by: Jarkko Sakkinen 
---
 drivers/char/tpm/tpm_tis.c | 8 +++-
 1 file changed, 7 insertions(+), 1 deletion(-)

diff --git a/drivers/char/tpm/tpm_tis.c b/drivers/char/tpm/tpm_tis.c
index 65f7eec..088fa86 100644
--- a/drivers/char/tpm/tpm_tis.c
+++ b/drivers/char/tpm/tpm_tis.c
@@ -299,6 +299,8 @@ static int tpm_tis_recv(struct tpm_chip *chip, u8 *buf, 
size_t count)
 
expected = be32_to_cpu(*(__be32 *) (buf + 2));
if (expected > count) {
+   dev_err(chip->pdev, "Response too long (wanted %zd, got %d)\n",
+   count, expected);
size = -EIO;
goto out;
}
@@ -366,6 +368,8 @@ static int tpm_tis_send_data(struct tpm_chip *chip, u8 
*buf, size_t len)
  >vendor.int_queue, false);
status = tpm_tis_status(chip);
if (!itpm && (status & TPM_STS_DATA_EXPECT) == 0) {
+   dev_err(chip->pdev, "Chip not accepting %zd bytes\n",
+   len - count);
rc = -EIO;
goto out_err;
}
@@ -378,6 +382,7 @@ static int tpm_tis_send_data(struct tpm_chip *chip, u8 
*buf, size_t len)
  >vendor.int_queue, false);
status = tpm_tis_status(chip);
if ((status & TPM_STS_DATA_EXPECT) != 0) {
+   dev_err(chip->pdev, "Chip not accepting last byte\n");
rc = -EIO;
goto out_err;
}
@@ -689,8 +694,9 @@ static int tpm_tis_init(struct device *dev, struct tpm_info 
*tpm_info,
vendor = ioread32(chip->vendor.iobase + TPM_DID_VID(0));
chip->vendor.manufacturer_id = vendor;
 
-   dev_info(dev, "%s TPM (device-id 0x%X, rev-id %d)\n",
+   dev_info(dev, "%s TPM (manufacturer-id 0x%X, device-id 0x%X, rev-id 
%d)\n",
 (chip->flags & TPM_CHIP_FLAG_TPM2) ? "2.0" : "1.2",
+chip->vendor.manufacturer_id,
 vendor >> 16, ioread8(chip->vendor.iobase + TPM_RID(0)));
 
if (!itpm) {
-- 
1.9.1

Re: [lustre-devel] [PATCH 11/21] drivers: staging: lustre: Replace CURRENT_TIME with current_fs_time()

[Andreas Dilger]

On Jun 10, 2016, at 6:36 PM, James Simmons  wrote:
> 
> 
>> CURRENT_TIME macro is not appropriate for filesystems as it
>> doesn't use the right granularity for filesystem timestamps.
>> Use current_fs_time() instead.
>> 
>> This is also in preparation for the patch that transitions
>> vfs timestamps to use 64 bit time and hence make them
>> y2038 safe. As part of the effort current_fs_time() will be
>> extended to do range checks. Hence, it is necessary for all
>> file system timestamps to use current_fs_time().
>> 
>> Also change format string for prints so that these are valid
>> when vfs is transitioned to use 64 bit timestamps.
> 
> Acked-by: James Simmons 

Actually, Linus NAK'd the base patch so there isn't any point in this
one landing.

Cheers, Andreas

>> Signed-off-by: Deepa Dinamani 
>> Cc: Greg Kroah-Hartman 
>> Cc: lustre-de...@lists.lustre.org
>> ---
>> drivers/staging/lustre/lustre/llite/llite_lib.c | 17 
>> +
>> drivers/staging/lustre/lustre/llite/namei.c |  4 ++--
>> drivers/staging/lustre/lustre/mdc/mdc_reint.c   |  6 +++---
>> .../staging/lustre/lustre/obdclass/linux/linux-obdo.c   |  6 +++---
>> drivers/staging/lustre/lustre/obdclass/obdo.c   |  6 +++---
>> drivers/staging/lustre/lustre/osc/osc_io.c  |  2 +-
>> 6 files changed, 21 insertions(+), 20 deletions(-)
>> 
>> diff --git a/drivers/staging/lustre/lustre/llite/llite_lib.c 
>> b/drivers/staging/lustre/lustre/llite/llite_lib.c
>> index 96c7e9f..919748f 100644
>> --- a/drivers/staging/lustre/lustre/llite/llite_lib.c
>> +++ b/drivers/staging/lustre/lustre/llite/llite_lib.c
>> @@ -1219,6 +1219,7 @@ static int ll_setattr_done_writing(struct inode *inode,
>> int ll_setattr_raw(struct dentry *dentry, struct iattr *attr, bool 
>> hsm_import)
>> {
>>  struct inode *inode = d_inode(dentry);
>> +struct super_block *sb = inode->i_sb;
>>  struct ll_inode_info *lli = ll_i2info(inode);
>>  struct md_op_data *op_data = NULL;
>>  struct md_open_data *mod = NULL;
>> @@ -1258,23 +1259,23 @@ int ll_setattr_raw(struct dentry *dentry, struct 
>> iattr *attr, bool hsm_import)
>> 
>>  /* We mark all of the fields "set" so MDS/OST does not re-set them */
>>  if (attr->ia_valid & ATTR_CTIME) {
>> -attr->ia_ctime = CURRENT_TIME;
>> +attr->ia_ctime = current_fs_time(sb);
>>  attr->ia_valid |= ATTR_CTIME_SET;
>>  }
>>  if (!(attr->ia_valid & ATTR_ATIME_SET) &&
>>  (attr->ia_valid & ATTR_ATIME)) {
>> -attr->ia_atime = CURRENT_TIME;
>> +attr->ia_atime = current_fs_time(sb);
>>  attr->ia_valid |= ATTR_ATIME_SET;
>>  }
>>  if (!(attr->ia_valid & ATTR_MTIME_SET) &&
>>  (attr->ia_valid & ATTR_MTIME)) {
>> -attr->ia_mtime = CURRENT_TIME;
>> +attr->ia_mtime = current_fs_time(sb);
>>  attr->ia_valid |= ATTR_MTIME_SET;
>>  }
>> 
>>  if (attr->ia_valid & (ATTR_MTIME | ATTR_CTIME))
>> -CDEBUG(D_INODE, "setting mtime %lu, ctime %lu, now = %llu\n",
>> -   LTIME_S(attr->ia_mtime), LTIME_S(attr->ia_ctime),
>> +CDEBUG(D_INODE, "setting mtime %llu, ctime %llu, now = %llu\n",
>> +   (long long)LTIME_S(attr->ia_mtime), (long 
>> long)LTIME_S(attr->ia_ctime),
>> (s64)ktime_get_real_seconds());
>> 
>>  /* We always do an MDS RPC, even if we're only changing the size;
>> @@ -1564,9 +1565,9 @@ void ll_update_inode(struct inode *inode, struct 
>> lustre_md *md)
>>  }
>>  if (body->valid & OBD_MD_FLMTIME) {
>>  if (body->mtime > LTIME_S(inode->i_mtime)) {
>> -CDEBUG(D_INODE, "setting ino %lu mtime from %lu to 
>> %llu\n",
>> -   inode->i_ino, LTIME_S(inode->i_mtime),
>> -   body->mtime);
>> +CDEBUG(D_INODE, "setting ino %lu mtime from %llu to 
>> %llu\n",
>> +   inode->i_ino, (unsigned long 
>> long)LTIME_S(inode->i_mtime),
>> +   (unsigned long long)body->mtime);
>>  LTIME_S(inode->i_mtime) = body->mtime;
>>  }
>>  lli->lli_mtime = body->mtime;
>> diff --git a/drivers/staging/lustre/lustre/llite/namei.c 
>> b/drivers/staging/lustre/lustre/llite/namei.c
>> index 5eba0eb..48ed1ce 100644
>> --- a/drivers/staging/lustre/lustre/llite/namei.c
>> +++ b/drivers/staging/lustre/lustre/llite/namei.c
>> @@ -731,8 +731,8 @@ static void ll_update_times(struct ptlrpc_request 
>> *request,
>>  LASSERT(body);
>>  if (body->valid & OBD_MD_FLMTIME &&
>>  body->mtime > LTIME_S(inode->i_mtime)) {
>> -CDEBUG(D_INODE, "setting fid "DFID" mtime from %lu to %llu\n",
>> -   PFID(ll_inode2fid(inode)), LTIME_S(inode->i_mtime),
>> +CDEBUG(D_INODE, 

Re: [lustre-devel] [PATCH 11/21] drivers: staging: lustre: Replace CURRENT_TIME with current_fs_time()

[Andreas Dilger]

On Jun 10, 2016, at 6:36 PM, James Simmons  wrote:
> 
> 
>> CURRENT_TIME macro is not appropriate for filesystems as it
>> doesn't use the right granularity for filesystem timestamps.
>> Use current_fs_time() instead.
>> 
>> This is also in preparation for the patch that transitions
>> vfs timestamps to use 64 bit time and hence make them
>> y2038 safe. As part of the effort current_fs_time() will be
>> extended to do range checks. Hence, it is necessary for all
>> file system timestamps to use current_fs_time().
>> 
>> Also change format string for prints so that these are valid
>> when vfs is transitioned to use 64 bit timestamps.
> 
> Acked-by: James Simmons 

Actually, Linus NAK'd the base patch so there isn't any point in this
one landing.

Cheers, Andreas

>> Signed-off-by: Deepa Dinamani 
>> Cc: Greg Kroah-Hartman 
>> Cc: lustre-de...@lists.lustre.org
>> ---
>> drivers/staging/lustre/lustre/llite/llite_lib.c | 17 
>> +
>> drivers/staging/lustre/lustre/llite/namei.c |  4 ++--
>> drivers/staging/lustre/lustre/mdc/mdc_reint.c   |  6 +++---
>> .../staging/lustre/lustre/obdclass/linux/linux-obdo.c   |  6 +++---
>> drivers/staging/lustre/lustre/obdclass/obdo.c   |  6 +++---
>> drivers/staging/lustre/lustre/osc/osc_io.c  |  2 +-
>> 6 files changed, 21 insertions(+), 20 deletions(-)
>> 
>> diff --git a/drivers/staging/lustre/lustre/llite/llite_lib.c 
>> b/drivers/staging/lustre/lustre/llite/llite_lib.c
>> index 96c7e9f..919748f 100644
>> --- a/drivers/staging/lustre/lustre/llite/llite_lib.c
>> +++ b/drivers/staging/lustre/lustre/llite/llite_lib.c
>> @@ -1219,6 +1219,7 @@ static int ll_setattr_done_writing(struct inode *inode,
>> int ll_setattr_raw(struct dentry *dentry, struct iattr *attr, bool 
>> hsm_import)
>> {
>>  struct inode *inode = d_inode(dentry);
>> +struct super_block *sb = inode->i_sb;
>>  struct ll_inode_info *lli = ll_i2info(inode);
>>  struct md_op_data *op_data = NULL;
>>  struct md_open_data *mod = NULL;
>> @@ -1258,23 +1259,23 @@ int ll_setattr_raw(struct dentry *dentry, struct 
>> iattr *attr, bool hsm_import)
>> 
>>  /* We mark all of the fields "set" so MDS/OST does not re-set them */
>>  if (attr->ia_valid & ATTR_CTIME) {
>> -attr->ia_ctime = CURRENT_TIME;
>> +attr->ia_ctime = current_fs_time(sb);
>>  attr->ia_valid |= ATTR_CTIME_SET;
>>  }
>>  if (!(attr->ia_valid & ATTR_ATIME_SET) &&
>>  (attr->ia_valid & ATTR_ATIME)) {
>> -attr->ia_atime = CURRENT_TIME;
>> +attr->ia_atime = current_fs_time(sb);
>>  attr->ia_valid |= ATTR_ATIME_SET;
>>  }
>>  if (!(attr->ia_valid & ATTR_MTIME_SET) &&
>>  (attr->ia_valid & ATTR_MTIME)) {
>> -attr->ia_mtime = CURRENT_TIME;
>> +attr->ia_mtime = current_fs_time(sb);
>>  attr->ia_valid |= ATTR_MTIME_SET;
>>  }
>> 
>>  if (attr->ia_valid & (ATTR_MTIME | ATTR_CTIME))
>> -CDEBUG(D_INODE, "setting mtime %lu, ctime %lu, now = %llu\n",
>> -   LTIME_S(attr->ia_mtime), LTIME_S(attr->ia_ctime),
>> +CDEBUG(D_INODE, "setting mtime %llu, ctime %llu, now = %llu\n",
>> +   (long long)LTIME_S(attr->ia_mtime), (long 
>> long)LTIME_S(attr->ia_ctime),
>> (s64)ktime_get_real_seconds());
>> 
>>  /* We always do an MDS RPC, even if we're only changing the size;
>> @@ -1564,9 +1565,9 @@ void ll_update_inode(struct inode *inode, struct 
>> lustre_md *md)
>>  }
>>  if (body->valid & OBD_MD_FLMTIME) {
>>  if (body->mtime > LTIME_S(inode->i_mtime)) {
>> -CDEBUG(D_INODE, "setting ino %lu mtime from %lu to 
>> %llu\n",
>> -   inode->i_ino, LTIME_S(inode->i_mtime),
>> -   body->mtime);
>> +CDEBUG(D_INODE, "setting ino %lu mtime from %llu to 
>> %llu\n",
>> +   inode->i_ino, (unsigned long 
>> long)LTIME_S(inode->i_mtime),
>> +   (unsigned long long)body->mtime);
>>  LTIME_S(inode->i_mtime) = body->mtime;
>>  }
>>  lli->lli_mtime = body->mtime;
>> diff --git a/drivers/staging/lustre/lustre/llite/namei.c 
>> b/drivers/staging/lustre/lustre/llite/namei.c
>> index 5eba0eb..48ed1ce 100644
>> --- a/drivers/staging/lustre/lustre/llite/namei.c
>> +++ b/drivers/staging/lustre/lustre/llite/namei.c
>> @@ -731,8 +731,8 @@ static void ll_update_times(struct ptlrpc_request 
>> *request,
>>  LASSERT(body);
>>  if (body->valid & OBD_MD_FLMTIME &&
>>  body->mtime > LTIME_S(inode->i_mtime)) {
>> -CDEBUG(D_INODE, "setting fid "DFID" mtime from %lu to %llu\n",
>> -   PFID(ll_inode2fid(inode)), LTIME_S(inode->i_mtime),
>> +CDEBUG(D_INODE, "setting fid "DFID" mtime from %llu to %llu\n",
>> +   PFID(ll_inode2fid(inode)), 

Re: [PATCH v5 3/4] tpm: Allow TPM chip drivers to override reported command durations

[Ed Swierk]

On Fri, Jun 10, 2016 at 12:42 PM, Jarkko Sakkinen
 wrote:
> On Fri, Jun 10, 2016 at 10:34:15AM -0700, Ed Swierk wrote:
>> On Fri, Jun 10, 2016 at 5:19 AM, Jarkko Sakkinen
>>  wrote:
>> > On Wed, Jun 08, 2016 at 04:00:17PM -0700, Ed Swierk wrote:
>> >> Some TPM chips report bogus command durations in their capabilities,
>> >> just as others report incorrect timeouts. Rework tpm_get_timeouts()
>> >> to allow chip drivers to override either via a single callback.
>> >> Also clean up handling of TPMs that report milliseconds instead of
>> >> microseconds.
>> >>
>> >> Signed-off-by: Ed Swierk 
>> >> ---
>> >>  drivers/char/tpm/tpm-interface.c | 177 
>> >> +--
>> >>  drivers/char/tpm/tpm_tis.c   |  35 ++--
>> >>  include/linux/tpm.h  |   3 +-
>> >>  3 files changed, 106 insertions(+), 109 deletions(-)
>> >>
>> >> diff --git a/drivers/char/tpm/tpm-interface.c 
>> >> b/drivers/char/tpm/tpm-interface.c
>> >> index cc1e5bc..b8a08bb 100644
>> >> --- a/drivers/char/tpm/tpm-interface.c
>> >> +++ b/drivers/char/tpm/tpm-interface.c
>> >> @@ -502,123 +502,138 @@ static int tpm_startup(struct tpm_chip *chip, 
>> >> __be16 startup_type)
>> >>   "attempting to start the TPM");
>> >>  }
>> >>
>> >> -int tpm_get_timeouts(struct tpm_chip *chip)
>> >> +static int tpm_get_cap_prop(struct tpm_chip *chip, __be32 type, int size,
>> >> + cap_t *cap, char *desc)
>> >>  {
>> >>   struct tpm_cmd_t tpm_cmd;
>> >> - unsigned long new_timeout[4];
>> >> - unsigned long old_timeout[4];
>> >> - struct duration_t *duration_cap;
>> >>   ssize_t rc;
>> >>
>> >>   tpm_cmd.header.in = tpm_getcap_header;
>> >>   tpm_cmd.params.getcap_in.cap = TPM_CAP_PROP;
>> >>   tpm_cmd.params.getcap_in.subcap_size = cpu_to_be32(4);
>> >> - tpm_cmd.params.getcap_in.subcap = TPM_CAP_PROP_TIS_TIMEOUT;
>> >> + tpm_cmd.params.getcap_in.subcap = type;
>> >>   rc = tpm_transmit_cmd(chip, _cmd, TPM_INTERNAL_RESULT_SIZE, 
>> >> NULL);
>> >>
>> >>   if (rc == TPM_ERR_INVALID_POSTINIT) {
>> >>   /* The TPM is not started, we are the first to talk to it.
>> >>  Execute a startup command. */
>> >> - dev_info(chip->pdev, "Issuing TPM_STARTUP");
>> >> + dev_info(chip->pdev, "Issuing TPM_STARTUP\n");
>> >>   if (tpm_startup(chip, TPM_ST_CLEAR))
>> >>   return rc;
>> >>
>> >>   tpm_cmd.header.in = tpm_getcap_header;
>> >>   tpm_cmd.params.getcap_in.cap = TPM_CAP_PROP;
>> >>   tpm_cmd.params.getcap_in.subcap_size = cpu_to_be32(4);
>> >> - tpm_cmd.params.getcap_in.subcap = TPM_CAP_PROP_TIS_TIMEOUT;
>> >> + tpm_cmd.params.getcap_in.subcap = type;
>> >>   rc = tpm_transmit_cmd(chip, _cmd, 
>> >> TPM_INTERNAL_RESULT_SIZE,
>> >> NULL);
>> >>   }
>> >> +
>> >>   if (rc) {
>> >>   dev_err(chip->pdev,
>> >> - "A TPM error (%zd) occurred attempting to determine 
>> >> the timeouts\n",
>> >> - rc);
>> >> - goto duration;
>> >> + "Error %zd reading %s\n", rc, desc);
>> >> + return -EINVAL;
>> >>   }
>> >>
>> >>   if (be32_to_cpu(tpm_cmd.header.out.return_code) != 0 ||
>> >>   be32_to_cpu(tpm_cmd.header.out.length)
>> >> - != sizeof(tpm_cmd.header.out) + sizeof(u32) + 4 * sizeof(u32))
>> >> + != sizeof(tpm_cmd.header.out) + sizeof(u32) + size * 
>> >> sizeof(u32)) {
>> >> + dev_err(chip->pdev,
>> >> + "Bad return code or length reading %s\n", desc);
>> >>   return -EINVAL;
>> >> -
>> >> - old_timeout[0] = 
>> >> be32_to_cpu(tpm_cmd.params.getcap_out.cap.timeout.a);
>> >> - old_timeout[1] = 
>> >> be32_to_cpu(tpm_cmd.params.getcap_out.cap.timeout.b);
>> >> - old_timeout[2] = 
>> >> be32_to_cpu(tpm_cmd.params.getcap_out.cap.timeout.c);
>> >> - old_timeout[3] = 
>> >> be32_to_cpu(tpm_cmd.params.getcap_out.cap.timeout.d);
>> >> - memcpy(new_timeout, old_timeout, sizeof(new_timeout));
>> >> -
>> >> - /*
>> >> -  * Provide ability for vendor overrides of timeout values in case
>> >> -  * of misreporting.
>> >> -  */
>> >> - if (chip->ops->update_timeouts != NULL)
>> >> - chip->vendor.timeout_adjusted =
>> >> - chip->ops->update_timeouts(chip, new_timeout);
>> >> -
>> >> - if (!chip->vendor.timeout_adjusted) {
>> >> - /* Don't overwrite default if value is 0 */
>> >> - if (new_timeout[0] != 0 && new_timeout[0] < 1000) {
>> >> - int i;
>> >> -
>> >> - /* timeouts in msec rather usec */
>> >> - for (i = 0; i != ARRAY_SIZE(new_timeout); 

Re: [PATCH v5 3/4] tpm: Allow TPM chip drivers to override reported command durations

[Ed Swierk]

On Fri, Jun 10, 2016 at 12:42 PM, Jarkko Sakkinen
 wrote:
> On Fri, Jun 10, 2016 at 10:34:15AM -0700, Ed Swierk wrote:
>> On Fri, Jun 10, 2016 at 5:19 AM, Jarkko Sakkinen
>>  wrote:
>> > On Wed, Jun 08, 2016 at 04:00:17PM -0700, Ed Swierk wrote:
>> >> Some TPM chips report bogus command durations in their capabilities,
>> >> just as others report incorrect timeouts. Rework tpm_get_timeouts()
>> >> to allow chip drivers to override either via a single callback.
>> >> Also clean up handling of TPMs that report milliseconds instead of
>> >> microseconds.
>> >>
>> >> Signed-off-by: Ed Swierk 
>> >> ---
>> >>  drivers/char/tpm/tpm-interface.c | 177 
>> >> +--
>> >>  drivers/char/tpm/tpm_tis.c   |  35 ++--
>> >>  include/linux/tpm.h  |   3 +-
>> >>  3 files changed, 106 insertions(+), 109 deletions(-)
>> >>
>> >> diff --git a/drivers/char/tpm/tpm-interface.c 
>> >> b/drivers/char/tpm/tpm-interface.c
>> >> index cc1e5bc..b8a08bb 100644
>> >> --- a/drivers/char/tpm/tpm-interface.c
>> >> +++ b/drivers/char/tpm/tpm-interface.c
>> >> @@ -502,123 +502,138 @@ static int tpm_startup(struct tpm_chip *chip, 
>> >> __be16 startup_type)
>> >>   "attempting to start the TPM");
>> >>  }
>> >>
>> >> -int tpm_get_timeouts(struct tpm_chip *chip)
>> >> +static int tpm_get_cap_prop(struct tpm_chip *chip, __be32 type, int size,
>> >> + cap_t *cap, char *desc)
>> >>  {
>> >>   struct tpm_cmd_t tpm_cmd;
>> >> - unsigned long new_timeout[4];
>> >> - unsigned long old_timeout[4];
>> >> - struct duration_t *duration_cap;
>> >>   ssize_t rc;
>> >>
>> >>   tpm_cmd.header.in = tpm_getcap_header;
>> >>   tpm_cmd.params.getcap_in.cap = TPM_CAP_PROP;
>> >>   tpm_cmd.params.getcap_in.subcap_size = cpu_to_be32(4);
>> >> - tpm_cmd.params.getcap_in.subcap = TPM_CAP_PROP_TIS_TIMEOUT;
>> >> + tpm_cmd.params.getcap_in.subcap = type;
>> >>   rc = tpm_transmit_cmd(chip, _cmd, TPM_INTERNAL_RESULT_SIZE, 
>> >> NULL);
>> >>
>> >>   if (rc == TPM_ERR_INVALID_POSTINIT) {
>> >>   /* The TPM is not started, we are the first to talk to it.
>> >>  Execute a startup command. */
>> >> - dev_info(chip->pdev, "Issuing TPM_STARTUP");
>> >> + dev_info(chip->pdev, "Issuing TPM_STARTUP\n");
>> >>   if (tpm_startup(chip, TPM_ST_CLEAR))
>> >>   return rc;
>> >>
>> >>   tpm_cmd.header.in = tpm_getcap_header;
>> >>   tpm_cmd.params.getcap_in.cap = TPM_CAP_PROP;
>> >>   tpm_cmd.params.getcap_in.subcap_size = cpu_to_be32(4);
>> >> - tpm_cmd.params.getcap_in.subcap = TPM_CAP_PROP_TIS_TIMEOUT;
>> >> + tpm_cmd.params.getcap_in.subcap = type;
>> >>   rc = tpm_transmit_cmd(chip, _cmd, 
>> >> TPM_INTERNAL_RESULT_SIZE,
>> >> NULL);
>> >>   }
>> >> +
>> >>   if (rc) {
>> >>   dev_err(chip->pdev,
>> >> - "A TPM error (%zd) occurred attempting to determine 
>> >> the timeouts\n",
>> >> - rc);
>> >> - goto duration;
>> >> + "Error %zd reading %s\n", rc, desc);
>> >> + return -EINVAL;
>> >>   }
>> >>
>> >>   if (be32_to_cpu(tpm_cmd.header.out.return_code) != 0 ||
>> >>   be32_to_cpu(tpm_cmd.header.out.length)
>> >> - != sizeof(tpm_cmd.header.out) + sizeof(u32) + 4 * sizeof(u32))
>> >> + != sizeof(tpm_cmd.header.out) + sizeof(u32) + size * 
>> >> sizeof(u32)) {
>> >> + dev_err(chip->pdev,
>> >> + "Bad return code or length reading %s\n", desc);
>> >>   return -EINVAL;
>> >> -
>> >> - old_timeout[0] = 
>> >> be32_to_cpu(tpm_cmd.params.getcap_out.cap.timeout.a);
>> >> - old_timeout[1] = 
>> >> be32_to_cpu(tpm_cmd.params.getcap_out.cap.timeout.b);
>> >> - old_timeout[2] = 
>> >> be32_to_cpu(tpm_cmd.params.getcap_out.cap.timeout.c);
>> >> - old_timeout[3] = 
>> >> be32_to_cpu(tpm_cmd.params.getcap_out.cap.timeout.d);
>> >> - memcpy(new_timeout, old_timeout, sizeof(new_timeout));
>> >> -
>> >> - /*
>> >> -  * Provide ability for vendor overrides of timeout values in case
>> >> -  * of misreporting.
>> >> -  */
>> >> - if (chip->ops->update_timeouts != NULL)
>> >> - chip->vendor.timeout_adjusted =
>> >> - chip->ops->update_timeouts(chip, new_timeout);
>> >> -
>> >> - if (!chip->vendor.timeout_adjusted) {
>> >> - /* Don't overwrite default if value is 0 */
>> >> - if (new_timeout[0] != 0 && new_timeout[0] < 1000) {
>> >> - int i;
>> >> -
>> >> - /* timeouts in msec rather usec */
>> >> - for (i = 0; i != ARRAY_SIZE(new_timeout); i++)
>> >> - new_timeout[i] *= 1000;
>> >> - 

Re: [PATCH 2/4] soc: fsl: add GUTS driver for QorIQ platforms

[Scott Wood]

On Thu, 2016-06-02 at 10:43 +0200, Arnd Bergmann wrote:
> On Wednesday, June 1, 2016 8:47:22 PM CEST Scott Wood wrote:
> > On Mon, 2016-05-30 at 15:15 +0200, Arnd Bergmann wrote:
> > > diff --git a/drivers/soc/fsl/guts.c b/drivers/soc/fsl/guts.c
> > > new file mode 100644
> > > index ..2f30698f5bcf
> > > --- /dev/null
> > > +++ b/drivers/soc/fsl/guts.c
> > > @@ -0,0 +1,130 @@
> > > +/*
> > > + * Freescale QorIQ Platforms GUTS Driver
> > > + *
> > > + * Copyright (C) 2016 Freescale Semiconductor, Inc.
> > > + *
> > > + * This program is free software; you can redistribute it and/or modify
> > > + * it under the terms of the GNU General Public License as published by
> > > + * the Free Software Foundation; either version 2 of the License, or
> > > + * (at your option) any later version.
> > > + */
> > > +
> > > +#include 
> > > +#include 
> > > +#include 
> > > +#include 
> > > +#include 
> > > +#include 
> > > +#include 
> > > +
> > > +#define GUTS_PVR 0x0a0
> > > +#define GUTS_SVR 0x0a4
> > > +
> > > +struct guts {
> > > + void __iomem *regs;
> > 
> > We already have a struct to define guts.  Why are you not using it?  Why
> > do
> > you consider using it to be "abuse"?  What if we want to move more guts
> > functionality into this driver?
> 
> This structure was in the original patch, I left it in there, only
> removed the inclusion of the powerpc header file, which seemed to
> be misplaced.

I'm not refering "struct guts".  I'm referring to changing
"struct ccsr_guts __iomem *regs" into "void __iomem *regs".

And it's not a powerpc header file.

> > > +/*
> > > + * Table for matching compatible strings, for device tree
> > > + * guts node, for Freescale QorIQ SOCs.
> > > + */
> > > +static const struct of_device_id fsl_guts_of_match[] = {
> > > + /* For T4 & B4 Series SOCs */
> > > + { .compatible = "fsl,qoriq-device-config-1.0", .data = "T4/B4
> > > series" },
> > [snip]
> > > + { .compatible = "fsl,qoriq-device-config-2.0", .data = "P
> > > series"
> > 
> > As noted in my comment on patch 3/4, these descriptions are reversed.
> > 
> > They're also incomplete.  t2080 has device config 2.0.  t1040 is described
> > as
> > 2.0 though it should probably be 2.1 (or better, drop the generic
> > compatible
> > altogether).
> 
> Ok. Ideally I think we'd even look up the specific SoC names from the
> SVC rather than the compatible string. I just didn't have a good list
> for those to put in the driver.

The list is in arch/powerpc/include/asm/mpc85xx.h but I don't know why we need
to convert it to a string in the first place.

> 
> > > + /*
> > > +  * syscon devices default to little-endian, but on powerpc we
> > > have
> > > +  * existing device trees with big-endian maps and an absent
> > > endianess
> > > +  * "big-property"
> > > +  */
> > > + if (!IS_ENABLED(CONFIG_POWERPC) &&
> > > + !of_property_read_bool(dev->of_node, "big-endian"))
> > > + guts->little_endian = true;
> > 
> > This is not a syscon device (Yangbo's patch to add a guts node on ls2080
> > is
> > the only guts node that says "syscon", and that was a leftover from
> > earlier
> > revisions and should probably be removed).  Even if it were, where is it
> > documented that syscon defaults to little-endian?
> 
> Documentation/devicetree/bindings/regmap/regmap.txt
> 
> We had a little screwup here, basically regmap (and by consequence, syscon)
> always defaulted to little-endian way before that was documented, so it's
> too late to change it, 

What causes a device node to fall under the jurisdiction of regmap.txt? 
 Again, these nodes do not claim "syscon" compatibility.

> although I agree it would have made sense to document
> regmap to default to big-endian on powerpc.

Please don't.  It's enough of a mess as is; no need to start throwing in
architecture ifdefs.

> > Documentation/devicetree/bindings/common-properties.txt says that the
> > individual binding specifies the default.  The default for this node
> > should be
> > big-endian because that's what existed before there was a need to describe
> > the
> > endianness.  And we need an update to the guts binding to specify that.
> 
> Good point. This proably means that specifying both the "guts" and "syscon"
> compatible strings implies having to also specify the endianess explicitly
> both ways, because otherwise we break one of the two bindings.

Yes, but the node should only specify "guts".

> 
> > > +
> > > + guts->regs = devm_ioremap_resource(dev, 0);
> > > + if (!guts->regs) {
> > > + ret = -ENOMEM;
> > > + kfree(guts);
> > > + goto out;
> > > + }
> > > +
> > > + fsl_guts_init(dev, guts);
> > > + ret = 0;
> > > +out:
> > > + return ret;
> > > +}
> > > +
> > > +static struct platform_driver fsl_soc_guts = {
> > > + .probe = fsl_guts_probe,
> > > + .driver.of_match_table = fsl_guts_of_match,
> > > +};
> > > +
> > > +module_platform_driver(fsl_soc_guts);
> > 
> > Again, this means that the information is not available during early boot,
> 

Re: [PATCH 2/4] soc: fsl: add GUTS driver for QorIQ platforms

[Scott Wood]

On Thu, 2016-06-02 at 10:43 +0200, Arnd Bergmann wrote:
> On Wednesday, June 1, 2016 8:47:22 PM CEST Scott Wood wrote:
> > On Mon, 2016-05-30 at 15:15 +0200, Arnd Bergmann wrote:
> > > diff --git a/drivers/soc/fsl/guts.c b/drivers/soc/fsl/guts.c
> > > new file mode 100644
> > > index ..2f30698f5bcf
> > > --- /dev/null
> > > +++ b/drivers/soc/fsl/guts.c
> > > @@ -0,0 +1,130 @@
> > > +/*
> > > + * Freescale QorIQ Platforms GUTS Driver
> > > + *
> > > + * Copyright (C) 2016 Freescale Semiconductor, Inc.
> > > + *
> > > + * This program is free software; you can redistribute it and/or modify
> > > + * it under the terms of the GNU General Public License as published by
> > > + * the Free Software Foundation; either version 2 of the License, or
> > > + * (at your option) any later version.
> > > + */
> > > +
> > > +#include 
> > > +#include 
> > > +#include 
> > > +#include 
> > > +#include 
> > > +#include 
> > > +#include 
> > > +
> > > +#define GUTS_PVR 0x0a0
> > > +#define GUTS_SVR 0x0a4
> > > +
> > > +struct guts {
> > > + void __iomem *regs;
> > 
> > We already have a struct to define guts.  Why are you not using it?  Why
> > do
> > you consider using it to be "abuse"?  What if we want to move more guts
> > functionality into this driver?
> 
> This structure was in the original patch, I left it in there, only
> removed the inclusion of the powerpc header file, which seemed to
> be misplaced.

I'm not refering "struct guts".  I'm referring to changing
"struct ccsr_guts __iomem *regs" into "void __iomem *regs".

And it's not a powerpc header file.

> > > +/*
> > > + * Table for matching compatible strings, for device tree
> > > + * guts node, for Freescale QorIQ SOCs.
> > > + */
> > > +static const struct of_device_id fsl_guts_of_match[] = {
> > > + /* For T4 & B4 Series SOCs */
> > > + { .compatible = "fsl,qoriq-device-config-1.0", .data = "T4/B4
> > > series" },
> > [snip]
> > > + { .compatible = "fsl,qoriq-device-config-2.0", .data = "P
> > > series"
> > 
> > As noted in my comment on patch 3/4, these descriptions are reversed.
> > 
> > They're also incomplete.  t2080 has device config 2.0.  t1040 is described
> > as
> > 2.0 though it should probably be 2.1 (or better, drop the generic
> > compatible
> > altogether).
> 
> Ok. Ideally I think we'd even look up the specific SoC names from the
> SVC rather than the compatible string. I just didn't have a good list
> for those to put in the driver.

The list is in arch/powerpc/include/asm/mpc85xx.h but I don't know why we need
to convert it to a string in the first place.

> 
> > > + /*
> > > +  * syscon devices default to little-endian, but on powerpc we
> > > have
> > > +  * existing device trees with big-endian maps and an absent
> > > endianess
> > > +  * "big-property"
> > > +  */
> > > + if (!IS_ENABLED(CONFIG_POWERPC) &&
> > > + !of_property_read_bool(dev->of_node, "big-endian"))
> > > + guts->little_endian = true;
> > 
> > This is not a syscon device (Yangbo's patch to add a guts node on ls2080
> > is
> > the only guts node that says "syscon", and that was a leftover from
> > earlier
> > revisions and should probably be removed).  Even if it were, where is it
> > documented that syscon defaults to little-endian?
> 
> Documentation/devicetree/bindings/regmap/regmap.txt
> 
> We had a little screwup here, basically regmap (and by consequence, syscon)
> always defaulted to little-endian way before that was documented, so it's
> too late to change it, 

What causes a device node to fall under the jurisdiction of regmap.txt? 
 Again, these nodes do not claim "syscon" compatibility.

> although I agree it would have made sense to document
> regmap to default to big-endian on powerpc.

Please don't.  It's enough of a mess as is; no need to start throwing in
architecture ifdefs.

> > Documentation/devicetree/bindings/common-properties.txt says that the
> > individual binding specifies the default.  The default for this node
> > should be
> > big-endian because that's what existed before there was a need to describe
> > the
> > endianness.  And we need an update to the guts binding to specify that.
> 
> Good point. This proably means that specifying both the "guts" and "syscon"
> compatible strings implies having to also specify the endianess explicitly
> both ways, because otherwise we break one of the two bindings.

Yes, but the node should only specify "guts".

> 
> > > +
> > > + guts->regs = devm_ioremap_resource(dev, 0);
> > > + if (!guts->regs) {
> > > + ret = -ENOMEM;
> > > + kfree(guts);
> > > + goto out;
> > > + }
> > > +
> > > + fsl_guts_init(dev, guts);
> > > + ret = 0;
> > > +out:
> > > + return ret;
> > > +}
> > > +
> > > +static struct platform_driver fsl_soc_guts = {
> > > + .probe = fsl_guts_probe,
> > > + .driver.of_match_table = fsl_guts_of_match,
> > > +};
> > > +
> > > +module_platform_driver(fsl_soc_guts);
> > 
> > Again, this means that the information is not available during early boot,
> 

Re: [PATCH V2] block: correctly fallback for zeroout

[Martin K. Petersen]

> "Shaohua" == Shaohua Li  writes:

Shaohua,

>> What does the extra io_err buy us? Just have this function return an
>> error. And then in blkdev_issue_discard if you get -EOPNOTSUPP you
>> special case it there.

Shaohua> The __blkdev_issue_discard returns -EOPNOTSUPP if disk doesn't
Shaohua> support discard.  in that case, blkdev_issue_discard doesn't
Shaohua> return 0. blkdev_issue_discard only returns 0 if IO error is
Shaohua> -EOPNOTSUPP.

Oh, I see. The sanity checks are now in __blkdev_issue_discard() so
there is no way to distinguish between -EOPNOTSUPP and the other
-EOPNOTSUPP. *sigh*

I am OK with your patch as a stable fix but this really needs to be
fixed up properly.

-- 
Martin K. Petersen  Oracle Linux Engineering

Re: [PATCH V2] block: correctly fallback for zeroout

[Martin K. Petersen]

> "Shaohua" == Shaohua Li  writes:

Shaohua,

>> What does the extra io_err buy us? Just have this function return an
>> error. And then in blkdev_issue_discard if you get -EOPNOTSUPP you
>> special case it there.

Shaohua> The __blkdev_issue_discard returns -EOPNOTSUPP if disk doesn't
Shaohua> support discard.  in that case, blkdev_issue_discard doesn't
Shaohua> return 0. blkdev_issue_discard only returns 0 if IO error is
Shaohua> -EOPNOTSUPP.

Oh, I see. The sanity checks are now in __blkdev_issue_discard() so
there is no way to distinguish between -EOPNOTSUPP and the other
-EOPNOTSUPP. *sigh*

I am OK with your patch as a stable fix but this really needs to be
fixed up properly.

-- 
Martin K. Petersen  Oracle Linux Engineering

Re: [PATCH] autofs4: Fix endless loop in autofs4_write

[Ian Kent]

On Sat, 2016-06-11 at 09:09 +0800, Ian Kent wrote:
> On Fri, 2016-06-10 at 19:07 +0200, Laurent Dufour wrote:
> > The 'commit e9a7c2f1a548 ("autofs4: coding style fixes")' removed the
> > check done on the __vfs_write()'s returned value in autofs4_write().
> > This may lead to a spinning process which can't catch any signal.
> 
> Yeah, sorry my bad.

Actually Andrei Vagin has already sent this patch to me some time ago and I'm
working to send it to Andrew Morton (along with several others).

There have been a couple of hold ups on this, sorry about that.

> 
> > 
> > Call stack showed in xmon could be :
> > [c003a76c7500] c030df74 __vfs_write+0x134/0x1c0
> > (unreliable)
> > [c003a76c75a0] d52a35d4 autofs4_notify_daemon+0x174/0x3f0
> > [autofs4]
> > [c003a76c7780] d52a3fa0 autofs4_wait+0x750/0xa10 [autofs4]
> > [c003a76c78b0] d52a24d8 autofs4_mount_wait+0x78/0x140
> > [autofs4]
> > [c003a76c7930] d52a2f48 autofs4_d_automount+0x1d8/0x370
> > [autofs4]
> > [c003a76c79c0] c03221e4 follow_managed+0x204/0x3a0
> > [c003a76c7a20] c0322c10 lookup_fast+0x220/0x420
> > [c003a76c7a90] c032324c walk_component+0x5c/0x3e0
> > [c003a76c7b00] c0323794 link_path_walk+0x1c4/0x5f0
> > [c003a76c7b90] c0324b00 path_openat+0xf0/0x1620
> > [c003a76c7c90] c0327f6c do_filp_open+0xfc/0x170
> > [c003a76c7dc0] c030d06c do_sys_open+0x1bc/0x2e0
> > [c003a76c7e30] c0009260 system_call+0x38/0x108
> > --- Exception: c01 (System Call) at 3fffa38a0988
> > 
> > Cc: Ian Kent 
> > Cc: aut...@vger.kernel.org
> > Cc: linux-kernel@vger.kernel.org
> > Cc: sta...@vger.kernel.org
> > Reviewed-by: Greg Kurz 
> > Signed-off-by: Laurent Dufour 
> > Fixes: e9a7c2f1a548 ("autofs4: coding style fixes")
> > ---
> >  fs/autofs4/waitq.c | 7 ---
> >  1 file changed, 4 insertions(+), 3 deletions(-)
> > 
> > diff --git a/fs/autofs4/waitq.c b/fs/autofs4/waitq.c
> > index 0146d911f468..106d94139281 100644
> > --- a/fs/autofs4/waitq.c
> > +++ b/fs/autofs4/waitq.c
> > @@ -66,11 +66,12 @@ static int autofs4_write(struct autofs_sb_info *sbi,
> > set_fs(KERNEL_DS);
> >  
> > mutex_lock(>pipe_mutex);
> > -   wr = __vfs_write(file, data, bytes, >f_pos);
> > -   while (bytes && wr) {
> 
> Right but why not just wr >= 0 here.
> 
> I guess this patch probably saves a few bytes.
> 
> I'll add it to the series.
>  
> > +   while (bytes) {
> > +   wr = __vfs_write(file, data, bytes, >f_pos);
> > +   if (wr < 0)
> > +   break;
> > data += wr;
> > bytes -= wr;
> > -   wr = __vfs_write(file, data, bytes, >f_pos);
> > }
> > mutex_unlock(>pipe_mutex);
> >  
> 
> 
> --
> To unsubscribe from this list: send the line "unsubscribe autofs" in

Re: [PATCH] autofs4: Fix endless loop in autofs4_write

[Ian Kent]

On Sat, 2016-06-11 at 09:09 +0800, Ian Kent wrote:
> On Fri, 2016-06-10 at 19:07 +0200, Laurent Dufour wrote:
> > The 'commit e9a7c2f1a548 ("autofs4: coding style fixes")' removed the
> > check done on the __vfs_write()'s returned value in autofs4_write().
> > This may lead to a spinning process which can't catch any signal.
> 
> Yeah, sorry my bad.

Actually Andrei Vagin has already sent this patch to me some time ago and I'm
working to send it to Andrew Morton (along with several others).

There have been a couple of hold ups on this, sorry about that.

> 
> > 
> > Call stack showed in xmon could be :
> > [c003a76c7500] c030df74 __vfs_write+0x134/0x1c0
> > (unreliable)
> > [c003a76c75a0] d52a35d4 autofs4_notify_daemon+0x174/0x3f0
> > [autofs4]
> > [c003a76c7780] d52a3fa0 autofs4_wait+0x750/0xa10 [autofs4]
> > [c003a76c78b0] d52a24d8 autofs4_mount_wait+0x78/0x140
> > [autofs4]
> > [c003a76c7930] d52a2f48 autofs4_d_automount+0x1d8/0x370
> > [autofs4]
> > [c003a76c79c0] c03221e4 follow_managed+0x204/0x3a0
> > [c003a76c7a20] c0322c10 lookup_fast+0x220/0x420
> > [c003a76c7a90] c032324c walk_component+0x5c/0x3e0
> > [c003a76c7b00] c0323794 link_path_walk+0x1c4/0x5f0
> > [c003a76c7b90] c0324b00 path_openat+0xf0/0x1620
> > [c003a76c7c90] c0327f6c do_filp_open+0xfc/0x170
> > [c003a76c7dc0] c030d06c do_sys_open+0x1bc/0x2e0
> > [c003a76c7e30] c0009260 system_call+0x38/0x108
> > --- Exception: c01 (System Call) at 3fffa38a0988
> > 
> > Cc: Ian Kent 
> > Cc: aut...@vger.kernel.org
> > Cc: linux-kernel@vger.kernel.org
> > Cc: sta...@vger.kernel.org
> > Reviewed-by: Greg Kurz 
> > Signed-off-by: Laurent Dufour 
> > Fixes: e9a7c2f1a548 ("autofs4: coding style fixes")
> > ---
> >  fs/autofs4/waitq.c | 7 ---
> >  1 file changed, 4 insertions(+), 3 deletions(-)
> > 
> > diff --git a/fs/autofs4/waitq.c b/fs/autofs4/waitq.c
> > index 0146d911f468..106d94139281 100644
> > --- a/fs/autofs4/waitq.c
> > +++ b/fs/autofs4/waitq.c
> > @@ -66,11 +66,12 @@ static int autofs4_write(struct autofs_sb_info *sbi,
> > set_fs(KERNEL_DS);
> >  
> > mutex_lock(>pipe_mutex);
> > -   wr = __vfs_write(file, data, bytes, >f_pos);
> > -   while (bytes && wr) {
> 
> Right but why not just wr >= 0 here.
> 
> I guess this patch probably saves a few bytes.
> 
> I'll add it to the series.
>  
> > +   while (bytes) {
> > +   wr = __vfs_write(file, data, bytes, >f_pos);
> > +   if (wr < 0)
> > +   break;
> > data += wr;
> > bytes -= wr;
> > -   wr = __vfs_write(file, data, bytes, >f_pos);
> > }
> > mutex_unlock(>pipe_mutex);
> >  
> 
> 
> --
> To unsubscribe from this list: send the line "unsubscribe autofs" in