Re: blk_mq_sched_insert_request: inconsistent {SOFTIRQ-ON-W} -> {IN-SOFTIRQ-W} usage

[Bart Van Assche]

On Fri, 2017-07-28 at 08:25 -0600, Jens Axboe wrote:
> On 07/28/2017 12:19 AM, Michael Ellerman wrote:
> > OK, so the resolution is "fix it in IPR" ?
> 
> I'll leave that to the SCSI crew. But at least one bug is in IPR, if you
> look at the call trace:
> 
> - timer function triggers, runs ipr_reset_timer_done(), which grabs the
>   host lock AND disables interrupts.
> - further down in the call path, ipr_ioa_bringdown_done() uncondtionally
>   enables interrupts:
> 
> spin_unlock_irq(ioa_cfg->host->host_lock);
> scsi_unblock_requests(ioa_cfg->host);
> spin_lock_irq(ioa_cfg->host->host_lock); 
> 
> And the call to scsi_unblock_requests() is the one that ultimately runs
> the queue. The IRQ issue aside here, scsi_unblock_requests() could run
> the queue async, and we could retain the normal sync run otherwise.
> 
> Can you try the below fix? Should be more palatable than the previous
> one. Brian, maybe you can take a look at the IRQ issue mentioned above?
> 
> [ ... ]

Hello Jens,

Are there other block drivers that can call blk_mq_start_hw_queues() from
interrupt context? I'm currently working on converting the skd driver
(drivers/block/skd_main.c) from a single queue block driver into a scsi-mq
driver. The skd driver calls blk_start_queue() from interrupt context. As we
know it is not safe to call blk_mq_start_hw_queues() from interrupt context.
Can you recommend me how I should proceed: should I implement a solution in
the skd driver or should perhaps the blk-mq core be modified?

Thanks,

Bart.

Re: blk_mq_sched_insert_request: inconsistent {SOFTIRQ-ON-W} -> {IN-SOFTIRQ-W} usage

[Bart Van Assche]

On Fri, 2017-07-28 at 08:25 -0600, Jens Axboe wrote:
> On 07/28/2017 12:19 AM, Michael Ellerman wrote:
> > OK, so the resolution is "fix it in IPR" ?
> 
> I'll leave that to the SCSI crew. But at least one bug is in IPR, if you
> look at the call trace:
> 
> - timer function triggers, runs ipr_reset_timer_done(), which grabs the
>   host lock AND disables interrupts.
> - further down in the call path, ipr_ioa_bringdown_done() uncondtionally
>   enables interrupts:
> 
> spin_unlock_irq(ioa_cfg->host->host_lock);
> scsi_unblock_requests(ioa_cfg->host);
> spin_lock_irq(ioa_cfg->host->host_lock); 
> 
> And the call to scsi_unblock_requests() is the one that ultimately runs
> the queue. The IRQ issue aside here, scsi_unblock_requests() could run
> the queue async, and we could retain the normal sync run otherwise.
> 
> Can you try the below fix? Should be more palatable than the previous
> one. Brian, maybe you can take a look at the IRQ issue mentioned above?
> 
> [ ... ]

Hello Jens,

Are there other block drivers that can call blk_mq_start_hw_queues() from
interrupt context? I'm currently working on converting the skd driver
(drivers/block/skd_main.c) from a single queue block driver into a scsi-mq
driver. The skd driver calls blk_start_queue() from interrupt context. As we
know it is not safe to call blk_mq_start_hw_queues() from interrupt context.
Can you recommend me how I should proceed: should I implement a solution in
the skd driver or should perhaps the blk-mq core be modified?

Thanks,

Bart.

[PATCH net-next 4/4] net: dsa: lan9303: MDIO access phy registers directly

[Egil Hjelmeland]

Indirect access (PMI) to phy register only work in I2C mode. In
MDIO mode phy registers must be accessed directly. Introduced
struct lan9303_phy_ops to handle the two modes.

Signed-off-by: Egil Hjelmeland 
---
 drivers/net/dsa/lan9303-core.c | 20 +---
 drivers/net/dsa/lan9303.h  | 11 +++
 drivers/net/dsa/lan9303_i2c.c  |  2 ++
 drivers/net/dsa/lan9303_mdio.c | 21 +
 4 files changed, 47 insertions(+), 7 deletions(-)

diff --git a/drivers/net/dsa/lan9303-core.c b/drivers/net/dsa/lan9303-core.c
index 9427c3b0ced2..9910fc9d5dd6 100644
--- a/drivers/net/dsa/lan9303-core.c
+++ b/drivers/net/dsa/lan9303-core.c
@@ -334,6 +334,12 @@ static int lan9303_indirect_phy_write(struct lan9303 
*chip, int addr,
return ret;
 }
 
+const struct lan9303_phy_ops lan9303_indirect_phy_ops = {
+   .phy_read = lan9303_indirect_phy_read,
+   .phy_write = lan9303_indirect_phy_write,
+};
+EXPORT_SYMBOL(lan9303_indirect_phy_ops);
+
 static int lan9303_switch_wait_for_completion(struct lan9303 *chip)
 {
int ret, i;
@@ -435,7 +441,7 @@ static int lan9303_detect_phy_setup(struct lan9303 *chip)
 * 0x, which means 'phy_addr_sel_strap' is 1 and the IDs are 1-2-3.
 * 0x is returned on MDIO read with no response.
 */
-   reg = lan9303_indirect_phy_read(chip, 3, MII_LAN911X_SPECIAL_MODES);
+   reg = chip->ops->phy_read(chip, 3, MII_LAN911X_SPECIAL_MODES);
if (reg < 0) {
dev_err(chip->dev, "Failed to detect phy config: %d\n", reg);
return reg;
@@ -726,7 +732,7 @@ static int lan9303_phy_read(struct dsa_switch *ds, int phy, 
int regnum)
if (phy > phy_base + 2)
return -ENODEV;
 
-   return lan9303_indirect_phy_read(chip, phy, regnum);
+   return chip->ops->phy_read(chip, phy, regnum);
 }
 
 static int lan9303_phy_write(struct dsa_switch *ds, int phy, int regnum,
@@ -740,7 +746,7 @@ static int lan9303_phy_write(struct dsa_switch *ds, int 
phy, int regnum,
if (phy > phy_base + 2)
return -ENODEV;
 
-   return lan9303_indirect_phy_write(chip, phy, regnum, val);
+   return chip->ops->phy_write(chip, phy, regnum, val);
 }
 
 static int lan9303_port_enable(struct dsa_switch *ds, int port,
@@ -773,13 +779,13 @@ static void lan9303_port_disable(struct dsa_switch *ds, 
int port,
switch (port) {
case 1:
lan9303_disable_packet_processing(chip, LAN9303_PORT_1_OFFSET);
-   lan9303_indirect_phy_write(chip, chip->phy_addr_sel_strap + 1,
-  MII_BMCR, BMCR_PDOWN);
+   lan9303_phy_write(ds, chip->phy_addr_sel_strap + 1,
+ MII_BMCR, BMCR_PDOWN);
break;
case 2:
lan9303_disable_packet_processing(chip, LAN9303_PORT_2_OFFSET);
-   lan9303_indirect_phy_write(chip, chip->phy_addr_sel_strap + 2,
-  MII_BMCR, BMCR_PDOWN);
+   lan9303_phy_write(ds, chip->phy_addr_sel_strap + 2,
+ MII_BMCR, BMCR_PDOWN);
break;
default:
dev_dbg(chip->dev,
diff --git a/drivers/net/dsa/lan9303.h b/drivers/net/dsa/lan9303.h
index d1512dad2d90..4d8be555ff4d 100644
--- a/drivers/net/dsa/lan9303.h
+++ b/drivers/net/dsa/lan9303.h
@@ -2,6 +2,15 @@
 #include 
 #include 
 
+struct lan9303;
+
+struct lan9303_phy_ops {
+   /* PHY 1 and 2 access*/
+   int (*phy_read)(struct lan9303 *chip, int port, int regnum);
+   int (*phy_write)(struct lan9303 *chip, int port,
+int regnum, u16 val);
+};
+
 struct lan9303 {
struct device *dev;
struct regmap *regmap;
@@ -11,9 +20,11 @@ struct lan9303 {
bool phy_addr_sel_strap;
struct dsa_switch *ds;
struct mutex indirect_mutex; /* protect indexed register access */
+   const struct lan9303_phy_ops *ops;
 };
 
 extern const struct regmap_access_table lan9303_register_set;
+extern const struct lan9303_phy_ops lan9303_indirect_phy_ops;
 
 int lan9303_probe(struct lan9303 *chip, struct device_node *np);
 int lan9303_remove(struct lan9303 *chip);
diff --git a/drivers/net/dsa/lan9303_i2c.c b/drivers/net/dsa/lan9303_i2c.c
index ab3ce0da5071..24ec20f7f444 100644
--- a/drivers/net/dsa/lan9303_i2c.c
+++ b/drivers/net/dsa/lan9303_i2c.c
@@ -63,6 +63,8 @@ static int lan9303_i2c_probe(struct i2c_client *client,
i2c_set_clientdata(client, sw_dev);
sw_dev->chip.dev = >dev;
 
+   sw_dev->chip.ops = _indirect_phy_ops;
+
ret = lan9303_probe(_dev->chip, client->dev.of_node);
if (ret != 0)
return ret;
diff --git a/drivers/net/dsa/lan9303_mdio.c b/drivers/net/dsa/lan9303_mdio.c
index 2db7970fc88c..fc16668a487f 100644
--- a/drivers/net/dsa/lan9303_mdio.c
+++ b/drivers/net/dsa/lan9303_mdio.c
@@ -67,6 +67,25 @@ static 

[PATCH net-next 4/4] net: dsa: lan9303: MDIO access phy registers directly

[Egil Hjelmeland]

Indirect access (PMI) to phy register only work in I2C mode. In
MDIO mode phy registers must be accessed directly. Introduced
struct lan9303_phy_ops to handle the two modes.

Signed-off-by: Egil Hjelmeland 
---
 drivers/net/dsa/lan9303-core.c | 20 +---
 drivers/net/dsa/lan9303.h  | 11 +++
 drivers/net/dsa/lan9303_i2c.c  |  2 ++
 drivers/net/dsa/lan9303_mdio.c | 21 +
 4 files changed, 47 insertions(+), 7 deletions(-)

diff --git a/drivers/net/dsa/lan9303-core.c b/drivers/net/dsa/lan9303-core.c
index 9427c3b0ced2..9910fc9d5dd6 100644
--- a/drivers/net/dsa/lan9303-core.c
+++ b/drivers/net/dsa/lan9303-core.c
@@ -334,6 +334,12 @@ static int lan9303_indirect_phy_write(struct lan9303 
*chip, int addr,
return ret;
 }
 
+const struct lan9303_phy_ops lan9303_indirect_phy_ops = {
+   .phy_read = lan9303_indirect_phy_read,
+   .phy_write = lan9303_indirect_phy_write,
+};
+EXPORT_SYMBOL(lan9303_indirect_phy_ops);
+
 static int lan9303_switch_wait_for_completion(struct lan9303 *chip)
 {
int ret, i;
@@ -435,7 +441,7 @@ static int lan9303_detect_phy_setup(struct lan9303 *chip)
 * 0x, which means 'phy_addr_sel_strap' is 1 and the IDs are 1-2-3.
 * 0x is returned on MDIO read with no response.
 */
-   reg = lan9303_indirect_phy_read(chip, 3, MII_LAN911X_SPECIAL_MODES);
+   reg = chip->ops->phy_read(chip, 3, MII_LAN911X_SPECIAL_MODES);
if (reg < 0) {
dev_err(chip->dev, "Failed to detect phy config: %d\n", reg);
return reg;
@@ -726,7 +732,7 @@ static int lan9303_phy_read(struct dsa_switch *ds, int phy, 
int regnum)
if (phy > phy_base + 2)
return -ENODEV;
 
-   return lan9303_indirect_phy_read(chip, phy, regnum);
+   return chip->ops->phy_read(chip, phy, regnum);
 }
 
 static int lan9303_phy_write(struct dsa_switch *ds, int phy, int regnum,
@@ -740,7 +746,7 @@ static int lan9303_phy_write(struct dsa_switch *ds, int 
phy, int regnum,
if (phy > phy_base + 2)
return -ENODEV;
 
-   return lan9303_indirect_phy_write(chip, phy, regnum, val);
+   return chip->ops->phy_write(chip, phy, regnum, val);
 }
 
 static int lan9303_port_enable(struct dsa_switch *ds, int port,
@@ -773,13 +779,13 @@ static void lan9303_port_disable(struct dsa_switch *ds, 
int port,
switch (port) {
case 1:
lan9303_disable_packet_processing(chip, LAN9303_PORT_1_OFFSET);
-   lan9303_indirect_phy_write(chip, chip->phy_addr_sel_strap + 1,
-  MII_BMCR, BMCR_PDOWN);
+   lan9303_phy_write(ds, chip->phy_addr_sel_strap + 1,
+ MII_BMCR, BMCR_PDOWN);
break;
case 2:
lan9303_disable_packet_processing(chip, LAN9303_PORT_2_OFFSET);
-   lan9303_indirect_phy_write(chip, chip->phy_addr_sel_strap + 2,
-  MII_BMCR, BMCR_PDOWN);
+   lan9303_phy_write(ds, chip->phy_addr_sel_strap + 2,
+ MII_BMCR, BMCR_PDOWN);
break;
default:
dev_dbg(chip->dev,
diff --git a/drivers/net/dsa/lan9303.h b/drivers/net/dsa/lan9303.h
index d1512dad2d90..4d8be555ff4d 100644
--- a/drivers/net/dsa/lan9303.h
+++ b/drivers/net/dsa/lan9303.h
@@ -2,6 +2,15 @@
 #include 
 #include 
 
+struct lan9303;
+
+struct lan9303_phy_ops {
+   /* PHY 1 and 2 access*/
+   int (*phy_read)(struct lan9303 *chip, int port, int regnum);
+   int (*phy_write)(struct lan9303 *chip, int port,
+int regnum, u16 val);
+};
+
 struct lan9303 {
struct device *dev;
struct regmap *regmap;
@@ -11,9 +20,11 @@ struct lan9303 {
bool phy_addr_sel_strap;
struct dsa_switch *ds;
struct mutex indirect_mutex; /* protect indexed register access */
+   const struct lan9303_phy_ops *ops;
 };
 
 extern const struct regmap_access_table lan9303_register_set;
+extern const struct lan9303_phy_ops lan9303_indirect_phy_ops;
 
 int lan9303_probe(struct lan9303 *chip, struct device_node *np);
 int lan9303_remove(struct lan9303 *chip);
diff --git a/drivers/net/dsa/lan9303_i2c.c b/drivers/net/dsa/lan9303_i2c.c
index ab3ce0da5071..24ec20f7f444 100644
--- a/drivers/net/dsa/lan9303_i2c.c
+++ b/drivers/net/dsa/lan9303_i2c.c
@@ -63,6 +63,8 @@ static int lan9303_i2c_probe(struct i2c_client *client,
i2c_set_clientdata(client, sw_dev);
sw_dev->chip.dev = >dev;
 
+   sw_dev->chip.ops = _indirect_phy_ops;
+
ret = lan9303_probe(_dev->chip, client->dev.of_node);
if (ret != 0)
return ret;
diff --git a/drivers/net/dsa/lan9303_mdio.c b/drivers/net/dsa/lan9303_mdio.c
index 2db7970fc88c..fc16668a487f 100644
--- a/drivers/net/dsa/lan9303_mdio.c
+++ b/drivers/net/dsa/lan9303_mdio.c
@@ -67,6 +67,25 @@ static int lan9303_mdio_read(void 

[PATCH net-next 3/4] net: dsa: lan9303: Renamed indirect phy access functions

[Egil Hjelmeland]

Preparing for the following fix of MDIO phy access:

Renamed functions that access PHY 1 and 2 indirectly through PMI
registers.

 lan9303_port_phy_reg_wait_for_completion() to
 lan9303_indirect_phy_wait_for_completion()

 lan9303_port_phy_reg_read() to
 lan9303_indirect_phy_read()

 lan9303_port_phy_reg_write() to
 lan9303_indirect_phy_write()

Also changed "val" parameter of lan9303_indirect_phy_write() to u16,
for clarity.

Signed-off-by: Egil Hjelmeland 
---
 drivers/net/dsa/lan9303-core.c | 28 ++--
 1 file changed, 14 insertions(+), 14 deletions(-)

diff --git a/drivers/net/dsa/lan9303-core.c b/drivers/net/dsa/lan9303-core.c
index 96ebeb9bd59a..9427c3b0ced2 100644
--- a/drivers/net/dsa/lan9303-core.c
+++ b/drivers/net/dsa/lan9303-core.c
@@ -248,7 +248,7 @@ static int lan9303_virt_phy_reg_write(struct lan9303 *chip, 
int regnum, u16 val)
return regmap_write(chip->regmap, LAN9303_VIRT_PHY_BASE + regnum, val);
 }
 
-static int lan9303_port_phy_reg_wait_for_completion(struct lan9303 *chip)
+static int lan9303_indirect_phy_wait_for_completion(struct lan9303 *chip)
 {
int ret, i;
u32 reg;
@@ -268,7 +268,7 @@ static int lan9303_port_phy_reg_wait_for_completion(struct 
lan9303 *chip)
return -EIO;
 }
 
-static int lan9303_port_phy_reg_read(struct lan9303 *chip, int addr, int 
regnum)
+static int lan9303_indirect_phy_read(struct lan9303 *chip, int addr, int 
regnum)
 {
int ret;
u32 val;
@@ -278,7 +278,7 @@ static int lan9303_port_phy_reg_read(struct lan9303 *chip, 
int addr, int regnum)
 
mutex_lock(>indirect_mutex);
 
-   ret = lan9303_port_phy_reg_wait_for_completion(chip);
+   ret = lan9303_indirect_phy_wait_for_completion(chip);
if (ret)
goto on_error;
 
@@ -287,7 +287,7 @@ static int lan9303_port_phy_reg_read(struct lan9303 *chip, 
int addr, int regnum)
if (ret)
goto on_error;
 
-   ret = lan9303_port_phy_reg_wait_for_completion(chip);
+   ret = lan9303_indirect_phy_wait_for_completion(chip);
if (ret)
goto on_error;
 
@@ -305,8 +305,8 @@ static int lan9303_port_phy_reg_read(struct lan9303 *chip, 
int addr, int regnum)
return ret;
 }
 
-static int lan9303_phy_reg_write(struct lan9303 *chip, int addr, int regnum,
-unsigned int val)
+static int lan9303_indirect_phy_write(struct lan9303 *chip, int addr,
+ int regnum, u16 val)
 {
int ret;
u32 reg;
@@ -317,7 +317,7 @@ static int lan9303_phy_reg_write(struct lan9303 *chip, int 
addr, int regnum,
 
mutex_lock(>indirect_mutex);
 
-   ret = lan9303_port_phy_reg_wait_for_completion(chip);
+   ret = lan9303_indirect_phy_wait_for_completion(chip);
if (ret)
goto on_error;
 
@@ -435,7 +435,7 @@ static int lan9303_detect_phy_setup(struct lan9303 *chip)
 * 0x, which means 'phy_addr_sel_strap' is 1 and the IDs are 1-2-3.
 * 0x is returned on MDIO read with no response.
 */
-   reg = lan9303_port_phy_reg_read(chip, 3, MII_LAN911X_SPECIAL_MODES);
+   reg = lan9303_indirect_phy_read(chip, 3, MII_LAN911X_SPECIAL_MODES);
if (reg < 0) {
dev_err(chip->dev, "Failed to detect phy config: %d\n", reg);
return reg;
@@ -726,7 +726,7 @@ static int lan9303_phy_read(struct dsa_switch *ds, int phy, 
int regnum)
if (phy > phy_base + 2)
return -ENODEV;
 
-   return lan9303_port_phy_reg_read(chip, phy, regnum);
+   return lan9303_indirect_phy_read(chip, phy, regnum);
 }
 
 static int lan9303_phy_write(struct dsa_switch *ds, int phy, int regnum,
@@ -740,7 +740,7 @@ static int lan9303_phy_write(struct dsa_switch *ds, int 
phy, int regnum,
if (phy > phy_base + 2)
return -ENODEV;
 
-   return lan9303_phy_reg_write(chip, phy, regnum, val);
+   return lan9303_indirect_phy_write(chip, phy, regnum, val);
 }
 
 static int lan9303_port_enable(struct dsa_switch *ds, int port,
@@ -773,13 +773,13 @@ static void lan9303_port_disable(struct dsa_switch *ds, 
int port,
switch (port) {
case 1:
lan9303_disable_packet_processing(chip, LAN9303_PORT_1_OFFSET);
-   lan9303_phy_reg_write(chip, chip->phy_addr_sel_strap + 1,
- MII_BMCR, BMCR_PDOWN);
+   lan9303_indirect_phy_write(chip, chip->phy_addr_sel_strap + 1,
+  MII_BMCR, BMCR_PDOWN);
break;
case 2:
lan9303_disable_packet_processing(chip, LAN9303_PORT_2_OFFSET);
-   lan9303_phy_reg_write(chip, chip->phy_addr_sel_strap + 2,
- MII_BMCR, BMCR_PDOWN);
+   lan9303_indirect_phy_write(chip, chip->phy_addr_sel_strap + 2,
+  MII_BMCR, 

[PATCH net-next 3/4] net: dsa: lan9303: Renamed indirect phy access functions

[Egil Hjelmeland]

Preparing for the following fix of MDIO phy access:

Renamed functions that access PHY 1 and 2 indirectly through PMI
registers.

 lan9303_port_phy_reg_wait_for_completion() to
 lan9303_indirect_phy_wait_for_completion()

 lan9303_port_phy_reg_read() to
 lan9303_indirect_phy_read()

 lan9303_port_phy_reg_write() to
 lan9303_indirect_phy_write()

Also changed "val" parameter of lan9303_indirect_phy_write() to u16,
for clarity.

Signed-off-by: Egil Hjelmeland 
---
 drivers/net/dsa/lan9303-core.c | 28 ++--
 1 file changed, 14 insertions(+), 14 deletions(-)

diff --git a/drivers/net/dsa/lan9303-core.c b/drivers/net/dsa/lan9303-core.c
index 96ebeb9bd59a..9427c3b0ced2 100644
--- a/drivers/net/dsa/lan9303-core.c
+++ b/drivers/net/dsa/lan9303-core.c
@@ -248,7 +248,7 @@ static int lan9303_virt_phy_reg_write(struct lan9303 *chip, 
int regnum, u16 val)
return regmap_write(chip->regmap, LAN9303_VIRT_PHY_BASE + regnum, val);
 }
 
-static int lan9303_port_phy_reg_wait_for_completion(struct lan9303 *chip)
+static int lan9303_indirect_phy_wait_for_completion(struct lan9303 *chip)
 {
int ret, i;
u32 reg;
@@ -268,7 +268,7 @@ static int lan9303_port_phy_reg_wait_for_completion(struct 
lan9303 *chip)
return -EIO;
 }
 
-static int lan9303_port_phy_reg_read(struct lan9303 *chip, int addr, int 
regnum)
+static int lan9303_indirect_phy_read(struct lan9303 *chip, int addr, int 
regnum)
 {
int ret;
u32 val;
@@ -278,7 +278,7 @@ static int lan9303_port_phy_reg_read(struct lan9303 *chip, 
int addr, int regnum)
 
mutex_lock(>indirect_mutex);
 
-   ret = lan9303_port_phy_reg_wait_for_completion(chip);
+   ret = lan9303_indirect_phy_wait_for_completion(chip);
if (ret)
goto on_error;
 
@@ -287,7 +287,7 @@ static int lan9303_port_phy_reg_read(struct lan9303 *chip, 
int addr, int regnum)
if (ret)
goto on_error;
 
-   ret = lan9303_port_phy_reg_wait_for_completion(chip);
+   ret = lan9303_indirect_phy_wait_for_completion(chip);
if (ret)
goto on_error;
 
@@ -305,8 +305,8 @@ static int lan9303_port_phy_reg_read(struct lan9303 *chip, 
int addr, int regnum)
return ret;
 }
 
-static int lan9303_phy_reg_write(struct lan9303 *chip, int addr, int regnum,
-unsigned int val)
+static int lan9303_indirect_phy_write(struct lan9303 *chip, int addr,
+ int regnum, u16 val)
 {
int ret;
u32 reg;
@@ -317,7 +317,7 @@ static int lan9303_phy_reg_write(struct lan9303 *chip, int 
addr, int regnum,
 
mutex_lock(>indirect_mutex);
 
-   ret = lan9303_port_phy_reg_wait_for_completion(chip);
+   ret = lan9303_indirect_phy_wait_for_completion(chip);
if (ret)
goto on_error;
 
@@ -435,7 +435,7 @@ static int lan9303_detect_phy_setup(struct lan9303 *chip)
 * 0x, which means 'phy_addr_sel_strap' is 1 and the IDs are 1-2-3.
 * 0x is returned on MDIO read with no response.
 */
-   reg = lan9303_port_phy_reg_read(chip, 3, MII_LAN911X_SPECIAL_MODES);
+   reg = lan9303_indirect_phy_read(chip, 3, MII_LAN911X_SPECIAL_MODES);
if (reg < 0) {
dev_err(chip->dev, "Failed to detect phy config: %d\n", reg);
return reg;
@@ -726,7 +726,7 @@ static int lan9303_phy_read(struct dsa_switch *ds, int phy, 
int regnum)
if (phy > phy_base + 2)
return -ENODEV;
 
-   return lan9303_port_phy_reg_read(chip, phy, regnum);
+   return lan9303_indirect_phy_read(chip, phy, regnum);
 }
 
 static int lan9303_phy_write(struct dsa_switch *ds, int phy, int regnum,
@@ -740,7 +740,7 @@ static int lan9303_phy_write(struct dsa_switch *ds, int 
phy, int regnum,
if (phy > phy_base + 2)
return -ENODEV;
 
-   return lan9303_phy_reg_write(chip, phy, regnum, val);
+   return lan9303_indirect_phy_write(chip, phy, regnum, val);
 }
 
 static int lan9303_port_enable(struct dsa_switch *ds, int port,
@@ -773,13 +773,13 @@ static void lan9303_port_disable(struct dsa_switch *ds, 
int port,
switch (port) {
case 1:
lan9303_disable_packet_processing(chip, LAN9303_PORT_1_OFFSET);
-   lan9303_phy_reg_write(chip, chip->phy_addr_sel_strap + 1,
- MII_BMCR, BMCR_PDOWN);
+   lan9303_indirect_phy_write(chip, chip->phy_addr_sel_strap + 1,
+  MII_BMCR, BMCR_PDOWN);
break;
case 2:
lan9303_disable_packet_processing(chip, LAN9303_PORT_2_OFFSET);
-   lan9303_phy_reg_write(chip, chip->phy_addr_sel_strap + 2,
- MII_BMCR, BMCR_PDOWN);
+   lan9303_indirect_phy_write(chip, chip->phy_addr_sel_strap + 2,
+  MII_BMCR, BMCR_PDOWN);

Re: [PATCH] xen: avoid deadlock in xenbus

[Boris Ostrovsky]

On 07/28/2017 10:53 AM, Juergen Gross wrote:
> When starting the xenwatch thread a theoretical deadlock situation is
> possible:
>
> xs_init() contains:
>
> task = kthread_run(xenwatch_thread, NULL, "xenwatch");
> if (IS_ERR(task))
> return PTR_ERR(task);
> xenwatch_pid = task->pid;
>
> And xenwatch_thread() does:
>
> mutex_lock(_mutex);
> ...
> event->handle->callback();
> ...
> mutex_unlock(_mutex);
>
> The callback could call unregister_xenbus_watch() which does:
>
> ...
> if (current->pid != xenwatch_pid)
> mutex_lock(_mutex);
> ...
>
> In case a watch is firing before xenwatch_pid could be set and the
> callback of that watch unregisters a watch, then a self-deadlock would
> occur.
>
> Avoid this by setting xenwatch_pid in xenwatch_thread().
>
> Signed-off-by: Juergen Gross 

Reviewed-by: Boris Ostrovsky 

+stable?

Re: [PATCH] xen: avoid deadlock in xenbus

[Boris Ostrovsky]

On 07/28/2017 10:53 AM, Juergen Gross wrote:
> When starting the xenwatch thread a theoretical deadlock situation is
> possible:
>
> xs_init() contains:
>
> task = kthread_run(xenwatch_thread, NULL, "xenwatch");
> if (IS_ERR(task))
> return PTR_ERR(task);
> xenwatch_pid = task->pid;
>
> And xenwatch_thread() does:
>
> mutex_lock(_mutex);
> ...
> event->handle->callback();
> ...
> mutex_unlock(_mutex);
>
> The callback could call unregister_xenbus_watch() which does:
>
> ...
> if (current->pid != xenwatch_pid)
> mutex_lock(_mutex);
> ...
>
> In case a watch is firing before xenwatch_pid could be set and the
> callback of that watch unregisters a watch, then a self-deadlock would
> occur.
>
> Avoid this by setting xenwatch_pid in xenwatch_thread().
>
> Signed-off-by: Juergen Gross 

Reviewed-by: Boris Ostrovsky 

+stable?

[PATCH net-next 1/4] net: dsa: lan9303: Fix lan9303_detect_phy_setup() for MDIO

[Egil Hjelmeland]

Handle that MDIO read with no response return 0x.

Signed-off-by: Egil Hjelmeland 
---
 drivers/net/dsa/lan9303-core.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/net/dsa/lan9303-core.c b/drivers/net/dsa/lan9303-core.c
index cd76e61f1fca..9d0ab77edb4a 100644
--- a/drivers/net/dsa/lan9303-core.c
+++ b/drivers/net/dsa/lan9303-core.c
@@ -427,6 +427,7 @@ static int lan9303_detect_phy_setup(struct lan9303 *chip)
 * Special reg 18 of phy 3 reads as 0x, if 'phy_addr_sel_strap' is 0
 * and the IDs are 0-1-2, else it contains something different from
 * 0x, which means 'phy_addr_sel_strap' is 1 and the IDs are 1-2-3.
+* 0x is returned on MDIO read with no response.
 */
reg = lan9303_port_phy_reg_read(chip, 3, MII_LAN911X_SPECIAL_MODES);
if (reg < 0) {
@@ -434,7 +435,7 @@ static int lan9303_detect_phy_setup(struct lan9303 *chip)
return reg;
}
 
-   if (reg != 0)
+   if ((reg != 0) && (reg != 0x))
chip->phy_addr_sel_strap = 1;
else
chip->phy_addr_sel_strap = 0;
-- 
2.11.0

[PATCH net-next 1/4] net: dsa: lan9303: Fix lan9303_detect_phy_setup() for MDIO

[Egil Hjelmeland]

Handle that MDIO read with no response return 0x.

Signed-off-by: Egil Hjelmeland 
---
 drivers/net/dsa/lan9303-core.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/net/dsa/lan9303-core.c b/drivers/net/dsa/lan9303-core.c
index cd76e61f1fca..9d0ab77edb4a 100644
--- a/drivers/net/dsa/lan9303-core.c
+++ b/drivers/net/dsa/lan9303-core.c
@@ -427,6 +427,7 @@ static int lan9303_detect_phy_setup(struct lan9303 *chip)
 * Special reg 18 of phy 3 reads as 0x, if 'phy_addr_sel_strap' is 0
 * and the IDs are 0-1-2, else it contains something different from
 * 0x, which means 'phy_addr_sel_strap' is 1 and the IDs are 1-2-3.
+* 0x is returned on MDIO read with no response.
 */
reg = lan9303_port_phy_reg_read(chip, 3, MII_LAN911X_SPECIAL_MODES);
if (reg < 0) {
@@ -434,7 +435,7 @@ static int lan9303_detect_phy_setup(struct lan9303 *chip)
return reg;
}
 
-   if (reg != 0)
+   if ((reg != 0) && (reg != 0x))
chip->phy_addr_sel_strap = 1;
else
chip->phy_addr_sel_strap = 0;
-- 
2.11.0

[PATCH net-next 0/4] net: dsa: lan9303: Fix MDIO issues.

[Egil Hjelmeland]

This series fix the MDIO interface for the lan9303 DSA driver.
Bugs found after testing on actual HW.

This series is extracted from the first patch of my first large
series. Significant changes from that version are:
 - use mdiobus_write_nested, mdiobus_read_nested.
 - EXPORT lan9303_indirect_phy_ops

Unfortunately I do not have access to i2c based system for
testing.

Egil Hjelmeland (4):
  net: dsa: lan9303: Fix lan9303_detect_phy_setup() for MDIO
  net: dsa: lan9303: Multiply by 4 to get MDIO register
  net: dsa: lan9303: Renamed indirect phy access functions
  net: dsa: lan9303: MDIO access phy registers directly

 drivers/net/dsa/lan9303-core.c | 43 +++---
 drivers/net/dsa/lan9303.h  | 11 +++
 drivers/net/dsa/lan9303_i2c.c  |  2 ++
 drivers/net/dsa/lan9303_mdio.c | 23 ++
 4 files changed, 64 insertions(+), 15 deletions(-)

-- 
2.11.0

[PATCH net-next 0/4] net: dsa: lan9303: Fix MDIO issues.

[Egil Hjelmeland]

This series fix the MDIO interface for the lan9303 DSA driver.
Bugs found after testing on actual HW.

This series is extracted from the first patch of my first large
series. Significant changes from that version are:
 - use mdiobus_write_nested, mdiobus_read_nested.
 - EXPORT lan9303_indirect_phy_ops

Unfortunately I do not have access to i2c based system for
testing.

Egil Hjelmeland (4):
  net: dsa: lan9303: Fix lan9303_detect_phy_setup() for MDIO
  net: dsa: lan9303: Multiply by 4 to get MDIO register
  net: dsa: lan9303: Renamed indirect phy access functions
  net: dsa: lan9303: MDIO access phy registers directly

 drivers/net/dsa/lan9303-core.c | 43 +++---
 drivers/net/dsa/lan9303.h  | 11 +++
 drivers/net/dsa/lan9303_i2c.c  |  2 ++
 drivers/net/dsa/lan9303_mdio.c | 23 ++
 4 files changed, 64 insertions(+), 15 deletions(-)

-- 
2.11.0

Re: [PATCH] Cipso: cipso_v4_optptr enter infinite loop

[Paul Moore]

On Fri, Jul 28, 2017 at 7:30 AM, Yujuan Qi  wrote:
> From: "yujuan.qi" 
>
> in for(),if((optlen > 0) && (optptr[1] == 0)), enter infinite loop.
>
> Test: receive a packet which the ip length > 20 and the first byte of ip 
> option is 0, produce this issue
>
> Signed-off-by: yujuan.qi 
> ---
>  net/ipv4/cipso_ipv4.c | 2 ++
>  1 file changed, 2 insertions(+)
>
> diff --git a/net/ipv4/cipso_ipv4.c b/net/ipv4/cipso_ipv4.c
> index ae20616..b3d97c7 100644
> --- a/net/ipv4/cipso_ipv4.c
> +++ b/net/ipv4/cipso_ipv4.c
> @@ -1528,6 +1528,8 @@ unsigned char *cipso_v4_optptr(const struct sk_buff 
> *skb)
> taglen = optptr[1];
> optlen -= taglen;
> optptr += taglen;
> +   if (!taglen)
> +   break;
> }
>
> return NULL;

Thanks for catching this and submitting a patch.  Unfortunately
checking taglen/optptr[1] isn't going to help with the NOP and EOL
options as they are single byte options.  I think a for-loop like the
following, or something similar, is probably the better solution:

  for (optlen = iph->ihl*4 - sizeof(struct iphdr); optlen > 0; ) {
 switch (optptr[0]) {
 case IPOPT_CIPSO:
 return optptr;
 case IPOPT_END:
 return NULL;
 case IPOPT_NOOP:
 taglen = 1;
 break;
 default:
 taglen = optptr[1];
 }
 optlen -= taglen;
 optptr += taglen;
  }

-- 
paul moore
security @ redhat

Re: [PATCH] Cipso: cipso_v4_optptr enter infinite loop

[Paul Moore]

On Fri, Jul 28, 2017 at 7:30 AM, Yujuan Qi  wrote:
> From: "yujuan.qi" 
>
> in for(),if((optlen > 0) && (optptr[1] == 0)), enter infinite loop.
>
> Test: receive a packet which the ip length > 20 and the first byte of ip 
> option is 0, produce this issue
>
> Signed-off-by: yujuan.qi 
> ---
>  net/ipv4/cipso_ipv4.c | 2 ++
>  1 file changed, 2 insertions(+)
>
> diff --git a/net/ipv4/cipso_ipv4.c b/net/ipv4/cipso_ipv4.c
> index ae20616..b3d97c7 100644
> --- a/net/ipv4/cipso_ipv4.c
> +++ b/net/ipv4/cipso_ipv4.c
> @@ -1528,6 +1528,8 @@ unsigned char *cipso_v4_optptr(const struct sk_buff 
> *skb)
> taglen = optptr[1];
> optlen -= taglen;
> optptr += taglen;
> +   if (!taglen)
> +   break;
> }
>
> return NULL;

Thanks for catching this and submitting a patch.  Unfortunately
checking taglen/optptr[1] isn't going to help with the NOP and EOL
options as they are single byte options.  I think a for-loop like the
following, or something similar, is probably the better solution:

  for (optlen = iph->ihl*4 - sizeof(struct iphdr); optlen > 0; ) {
 switch (optptr[0]) {
 case IPOPT_CIPSO:
 return optptr;
 case IPOPT_END:
 return NULL;
 case IPOPT_NOOP:
 taglen = 1;
 break;
 default:
 taglen = optptr[1];
 }
 optlen -= taglen;
 optptr += taglen;
  }

-- 
paul moore
security @ redhat

Re: [PATCH 2/3] mm: fix MADV_[FREE|DONTNEED] TLB flush miss problem

[Minchan Kim]

On Fri, Jul 28, 2017 at 09:46:34AM +0100, Mel Gorman wrote:
> On Fri, Jul 28, 2017 at 03:41:51PM +0900, Minchan Kim wrote:
> > Nadav reported parallel MADV_DONTNEED on same range has a stale TLB
> > problem and Mel fixed it[1] and found same problem on MADV_FREE[2].
> > 
> > Quote from Mel Gorman
> > 
> > "The race in question is CPU 0 running madv_free and updating some PTEs
> > while CPU 1 is also running madv_free and looking at the same PTEs.
> > CPU 1 may have writable TLB entries for a page but fail the pte_dirty
> > check (because CPU 0 has updated it already) and potentially fail to flush.
> > Hence, when madv_free on CPU 1 returns, there are still potentially writable
> > TLB entries and the underlying PTE is still present so that a subsequent 
> > write
> > does not necessarily propagate the dirty bit to the underlying PTE any more.
> > Reclaim at some unknown time at the future may then see that the PTE is 
> > still
> > clean and discard the page even though a write has happened in the meantime.
> > I think this is possible but I could have missed some protection in 
> > madv_free
> > that prevents it happening."
> > 
> > This patch aims for solving both problems all at once and is ready for
> > other problem with KSM, MADV_FREE and soft-dirty story[3].
> > 
> > TLB batch API(tlb_[gather|finish]_mmu] uses [set|clear]_tlb_flush_pending
> > and mmu_tlb_flush_pending so that when tlb_finish_mmu is called, we can 
> > catch
> > there are parallel threads going on. In that case, flush TLB to prevent
> > for user to access memory via stale TLB entry although it fail to gather
> > pte entry.
> > 
> > I confiremd this patch works with [4] test program Nadav gave so this patch
> > supersedes "mm: Always flush VMA ranges affected by zap_page_range v2"
> > in current mmotm.
> > 
> > NOTE:
> > This patch modifies arch-specific TLB gathering interface(x86, ia64,
> > s390, sh, um). It seems most of architecture are straightforward but s390
> > need to be careful because tlb_flush_mmu works only if mm->context.flush_mm
> > is set to non-zero which happens only a pte entry really is cleared by
> > ptep_get_and_clear and friends. However, this problem never changes the
> > pte entries but need to flush to prevent memory access from stale tlb.
> > 
> > Any thoughts?
> > 
> 
> The cc list is somewhat . extensive, given the topic. Trim it if
> there is another version.

Most of them are maintainers and mailling list for each architecures
I am changing. I'm not sure what I can trim. As you said it's rather
extensive, I will trim mailing list for each arch but keep maintainers
and linux-arch.

> 
> > index 3f2eb76243e3..8c26961f0503 100644
> > --- a/arch/arm/include/asm/tlb.h
> > +++ b/arch/arm/include/asm/tlb.h
> > @@ -163,13 +163,26 @@ tlb_gather_mmu(struct mmu_gather *tlb, struct 
> > mm_struct *mm, unsigned long start
> >  #ifdef CONFIG_HAVE_RCU_TABLE_FREE
> > tlb->batch = NULL;
> >  #endif
> > +   set_tlb_flush_pending(tlb->mm);
> >  }
> >  
> >  static inline void
> >  tlb_finish_mmu(struct mmu_gather *tlb, unsigned long start, unsigned long 
> > end)
> >  {
> > -   tlb_flush_mmu(tlb);
> > +   /*
> > +* If there are parallel threads are doing PTE changes on same range
> > +* under non-exclusive lock(e.g., mmap_sem read-side) but defer TLB
> > +* flush by batching, a thread has stable TLB entry can fail to flush
> > +* the TLB by observing pte_none|!pte_dirty, for example so flush TLB
> > +* if we detect parallel PTE batching threads.
> > +*/
> > +   if (mm_tlb_flush_pending(tlb->mm, false) > 1) {
> > +   tlb->range_start = start;
> > +   tlb->range_end = end;
> > +   }
> >  
> > +   tlb_flush_mmu(tlb);
> > +   clear_tlb_flush_pending(tlb->mm);
> > /* keep the page table cache within bounds */
> > check_pgt_cache();
> >  
> 
> mm_tlb_flush_pending shouldn't be taking a barrier specific arg. I expect
> this to change in the future and cause a conflict. At least I think in
> this context, it's the conditional barrier stuff.
> 

Yub. I saw your comment to Nadav so I expect you want mm_tlb_flush_pending
be called under pte lock. However, I will use it out of pte lock where
tlb_finish_mmu, however, in that case, atomic op and barrier
to prevent compiler reordering between tlb flush and atomic_read
in mm_tlb_flush_pending are enough to work.

> That aside, it's very unfortunate that the return value of
> mm_tlb_flush_pending really matters. Knowing why 1 is magic there requires
> knowledge of the internals on a per-arch basis which is a bit nuts.
> Consider renaming this to mm_tlb_flush_parallel() to return true if there
> is a nr_pending > 1 with comments explaining why. I don't think any of
> the callers expect a nr_pending of 0 ever. That removes some knowledge of
> the specifics.

Okay. If you are not strong against, I prefer mm_tlb_flush_nested
which returns true if nr_pending > 1.

> 
> The arch-specific changes to tlb_gather_mmu are almost all identical.

Re: [PATCH 2/3] mm: fix MADV_[FREE|DONTNEED] TLB flush miss problem

[Minchan Kim]

On Fri, Jul 28, 2017 at 09:46:34AM +0100, Mel Gorman wrote:
> On Fri, Jul 28, 2017 at 03:41:51PM +0900, Minchan Kim wrote:
> > Nadav reported parallel MADV_DONTNEED on same range has a stale TLB
> > problem and Mel fixed it[1] and found same problem on MADV_FREE[2].
> > 
> > Quote from Mel Gorman
> > 
> > "The race in question is CPU 0 running madv_free and updating some PTEs
> > while CPU 1 is also running madv_free and looking at the same PTEs.
> > CPU 1 may have writable TLB entries for a page but fail the pte_dirty
> > check (because CPU 0 has updated it already) and potentially fail to flush.
> > Hence, when madv_free on CPU 1 returns, there are still potentially writable
> > TLB entries and the underlying PTE is still present so that a subsequent 
> > write
> > does not necessarily propagate the dirty bit to the underlying PTE any more.
> > Reclaim at some unknown time at the future may then see that the PTE is 
> > still
> > clean and discard the page even though a write has happened in the meantime.
> > I think this is possible but I could have missed some protection in 
> > madv_free
> > that prevents it happening."
> > 
> > This patch aims for solving both problems all at once and is ready for
> > other problem with KSM, MADV_FREE and soft-dirty story[3].
> > 
> > TLB batch API(tlb_[gather|finish]_mmu] uses [set|clear]_tlb_flush_pending
> > and mmu_tlb_flush_pending so that when tlb_finish_mmu is called, we can 
> > catch
> > there are parallel threads going on. In that case, flush TLB to prevent
> > for user to access memory via stale TLB entry although it fail to gather
> > pte entry.
> > 
> > I confiremd this patch works with [4] test program Nadav gave so this patch
> > supersedes "mm: Always flush VMA ranges affected by zap_page_range v2"
> > in current mmotm.
> > 
> > NOTE:
> > This patch modifies arch-specific TLB gathering interface(x86, ia64,
> > s390, sh, um). It seems most of architecture are straightforward but s390
> > need to be careful because tlb_flush_mmu works only if mm->context.flush_mm
> > is set to non-zero which happens only a pte entry really is cleared by
> > ptep_get_and_clear and friends. However, this problem never changes the
> > pte entries but need to flush to prevent memory access from stale tlb.
> > 
> > Any thoughts?
> > 
> 
> The cc list is somewhat . extensive, given the topic. Trim it if
> there is another version.

Most of them are maintainers and mailling list for each architecures
I am changing. I'm not sure what I can trim. As you said it's rather
extensive, I will trim mailing list for each arch but keep maintainers
and linux-arch.

> 
> > index 3f2eb76243e3..8c26961f0503 100644
> > --- a/arch/arm/include/asm/tlb.h
> > +++ b/arch/arm/include/asm/tlb.h
> > @@ -163,13 +163,26 @@ tlb_gather_mmu(struct mmu_gather *tlb, struct 
> > mm_struct *mm, unsigned long start
> >  #ifdef CONFIG_HAVE_RCU_TABLE_FREE
> > tlb->batch = NULL;
> >  #endif
> > +   set_tlb_flush_pending(tlb->mm);
> >  }
> >  
> >  static inline void
> >  tlb_finish_mmu(struct mmu_gather *tlb, unsigned long start, unsigned long 
> > end)
> >  {
> > -   tlb_flush_mmu(tlb);
> > +   /*
> > +* If there are parallel threads are doing PTE changes on same range
> > +* under non-exclusive lock(e.g., mmap_sem read-side) but defer TLB
> > +* flush by batching, a thread has stable TLB entry can fail to flush
> > +* the TLB by observing pte_none|!pte_dirty, for example so flush TLB
> > +* if we detect parallel PTE batching threads.
> > +*/
> > +   if (mm_tlb_flush_pending(tlb->mm, false) > 1) {
> > +   tlb->range_start = start;
> > +   tlb->range_end = end;
> > +   }
> >  
> > +   tlb_flush_mmu(tlb);
> > +   clear_tlb_flush_pending(tlb->mm);
> > /* keep the page table cache within bounds */
> > check_pgt_cache();
> >  
> 
> mm_tlb_flush_pending shouldn't be taking a barrier specific arg. I expect
> this to change in the future and cause a conflict. At least I think in
> this context, it's the conditional barrier stuff.
> 

Yub. I saw your comment to Nadav so I expect you want mm_tlb_flush_pending
be called under pte lock. However, I will use it out of pte lock where
tlb_finish_mmu, however, in that case, atomic op and barrier
to prevent compiler reordering between tlb flush and atomic_read
in mm_tlb_flush_pending are enough to work.

> That aside, it's very unfortunate that the return value of
> mm_tlb_flush_pending really matters. Knowing why 1 is magic there requires
> knowledge of the internals on a per-arch basis which is a bit nuts.
> Consider renaming this to mm_tlb_flush_parallel() to return true if there
> is a nr_pending > 1 with comments explaining why. I don't think any of
> the callers expect a nr_pending of 0 ever. That removes some knowledge of
> the specifics.

Okay. If you are not strong against, I prefer mm_tlb_flush_nested
which returns true if nr_pending > 1.

> 
> The arch-specific changes to tlb_gather_mmu are almost all identical.

Re: [PATCH net-next 3/3] tap: XDP support

[Daniel Borkmann]

On 07/28/2017 05:46 AM, Michael S. Tsirkin wrote:

On Fri, Jul 28, 2017 at 11:28:54AM +0800, Jason Wang wrote:

+   old_prog = rtnl_dereference(tun->xdp_prog);
+   if (old_prog)
+   bpf_prog_put(old_prog);
+   rcu_assign_pointer(tun->xdp_prog, prog);

Is this OK?  Could this lead to the program getting freed and then
datapath accessing a stale pointer?  I mean in the scenario where the
process gets pre-empted between the bpf_prog_put() and
rcu_assign_pointer()?


Will call bpf_prog_put() after rcu_assign_pointer().


+1, good catch Jakub.


I suspect you need to sync RCU or something before that.


No, see for example generic_xdp_install().

Re: [PATCH net-next 3/3] tap: XDP support

[Daniel Borkmann]

On 07/28/2017 05:46 AM, Michael S. Tsirkin wrote:

On Fri, Jul 28, 2017 at 11:28:54AM +0800, Jason Wang wrote:

+   old_prog = rtnl_dereference(tun->xdp_prog);
+   if (old_prog)
+   bpf_prog_put(old_prog);
+   rcu_assign_pointer(tun->xdp_prog, prog);

Is this OK?  Could this lead to the program getting freed and then
datapath accessing a stale pointer?  I mean in the scenario where the
process gets pre-empted between the bpf_prog_put() and
rcu_assign_pointer()?


Will call bpf_prog_put() after rcu_assign_pointer().


+1, good catch Jakub.


I suspect you need to sync RCU or something before that.


No, see for example generic_xdp_install().

Re: [PATCH v2 3/3] ASoC: codecs: msm8916-wcd-digital: select DMIC source in CIC filter path

[Srinivas Kandagatla]

On 28/07/17 14:32, Mark Brown wrote:

On Wed, Jul 26, 2017 at 01:48:22AM +0200, srinivas.kandaga...@linaro.org wrote:

From: Srinivas Kandagatla 

This patch fixes a missing selection of DMIC in CIC filter source path.
Without this patch dmic is not functional.


What happens when someone needs this filter connected somewhere else -
shouldn't this be controlled as part of the DAPM routing?

There are only two paths for this, one is DMIC and other is AMIC.

Yes, its possible to add these as dapm routing, i will give it a go in 
next version.


thanks,
srini

Re: [PATCH v2 3/3] ASoC: codecs: msm8916-wcd-digital: select DMIC source in CIC filter path

[Srinivas Kandagatla]

On 28/07/17 14:32, Mark Brown wrote:

On Wed, Jul 26, 2017 at 01:48:22AM +0200, srinivas.kandaga...@linaro.org wrote:

From: Srinivas Kandagatla 

This patch fixes a missing selection of DMIC in CIC filter source path.
Without this patch dmic is not functional.


What happens when someone needs this filter connected somewhere else -
shouldn't this be controlled as part of the DAPM routing?

There are only two paths for this, one is DMIC and other is AMIC.

Yes, its possible to add these as dapm routing, i will give it a go in 
next version.


thanks,
srini

Re: [PATCH] cgroup: add cgroup.stat interface with basic hierarchy stats

[Tejun Heo]

Hello,

On Fri, Jul 28, 2017 at 02:01:55PM +0100, Roman Gushchin wrote:
> > > +   nr_dying_descendants
> > > + Total number of dying descendant cgroups.
> > 
> > Can you please go into more detail on what's going on with dying
> > descendants here?
>
> Sure.
> Don't we plan do describe cgroup/css lifecycle in details
> in a separate section?

We should but it'd still be nice to have a short description here too.

Thanks.

-- 
tejun

Re: [PATCH] cgroup: add cgroup.stat interface with basic hierarchy stats

[Tejun Heo]

Hello,

On Fri, Jul 28, 2017 at 02:01:55PM +0100, Roman Gushchin wrote:
> > > +   nr_dying_descendants
> > > + Total number of dying descendant cgroups.
> > 
> > Can you please go into more detail on what's going on with dying
> > descendants here?
>
> Sure.
> Don't we plan do describe cgroup/css lifecycle in details
> in a separate section?

We should but it'd still be nice to have a short description here too.

Thanks.

-- 
tejun

Re: [RFC PATCH 0/8] EDAC, mce_amd: Add a tracepoint for the decoded error

[Borislav Petkov]

Ok,

here's a working version. It looks pretty straight-forward (to me, at
least) and it does what it is supposed to when I inject an MCE:

# tracer: nop
#
#  _-=> irqs-off
# / _=> need-resched
#| / _---=> hardirq/softirq
#|| / _--=> preempt-depth
#||| / delay
#   TASK-PID   CPU#  TIMESTAMP  FUNCTION
#  | |   |      | |
 kworker/1:2-76[001]    316.852022: mce_record: CPU: 1, MCGc/s: 
100010a/0, MC5: dc0041020f0f, IPID: , ADDR/MISC/SYND: 
56071033//, RIP: 00:<>, 
TSC: 0, PROCESSOR: 2:600f20, TIME: 1501261272, SOCKET: 1, APIC: 1 MC5 Error: AG 
payload array parity error.
cache level: L3/GEN, mem/io: GEN, mem-tx: GEN, part-proc: GEN (timed out)
 kworker/1:2-76[001]    328.372055: mce_record: CPU: 1, MCGc/s: 
100010a/0, MC5: dc0041020f0f, IPID: , ADDR/MISC/SYND: 
56071033//, RIP: 00:<>, 
TSC: 0, PROCESSOR: 2:600f20, TIME: 1501261283, SOCKET: 1, APIC: 1 MC5 Error: AG 
payload array parity error.
cache level: L3/GEN, mem/io: GEN, mem-tx: GEN, part-proc: GEN (timed out)

diff ontop of the current pile:

---
diff --git a/arch/x86/include/asm/mce.h b/arch/x86/include/asm/mce.h
index 181264989db5..ba4c99ace544 100644
--- a/arch/x86/include/asm/mce.h
+++ b/arch/x86/include/asm/mce.h
@@ -146,6 +146,7 @@ struct mca_config {
bool ser;
bool recovery;
bool bios_cmci_threshold;
+   bool has_decoder;
u8 banks;
s8 bootlog;
int tolerant;
@@ -195,7 +196,8 @@ enum mce_notifier_prios {
MCE_PRIO_SRAO   = INT_MAX - 1,
MCE_PRIO_EXTLOG = INT_MAX - 2,
MCE_PRIO_NFIT   = INT_MAX - 3,
-   MCE_PRIO_EDAC   = INT_MAX - 4,
+   MCE_PRIO_DECODER= INT_MAX - 4,
+   MCE_PRIO_EDAC   = INT_MAX - 5,
MCE_PRIO_MCELOG = 1,
MCE_PRIO_LOWEST = 0,
 };
diff --git a/arch/x86/kernel/cpu/mcheck/mce.c b/arch/x86/kernel/cpu/mcheck/mce.c
index 6dde0497efc7..9486a2ca6556 100644
--- a/arch/x86/kernel/cpu/mcheck/mce.c
+++ b/arch/x86/kernel/cpu/mcheck/mce.c
@@ -162,6 +162,9 @@ void mce_register_decode_chain(struct notifier_block *nb)
 
atomic_inc(_notifiers);
 
+   if (nb->priority == MCE_PRIO_DECODER)
+   mca_cfg.has_decoder = true;
+
blocking_notifier_chain_register(_mce_decoder_chain, nb);
 }
 EXPORT_SYMBOL_GPL(mce_register_decode_chain);
@@ -556,7 +559,8 @@ static int mce_first_notifier(struct notifier_block *nb, 
unsigned long val,
return NOTIFY_STOP;
 
/* Emit the trace record: */
-   trace_mce_record(m);
+   if (!mca_cfg.has_decoder)
+   trace_mce_record(m, "");
 
set_bit(0, _need_notify);
 
diff --git a/drivers/edac/mce_amd.c b/drivers/edac/mce_amd.c
index fd4a615200a8..d0b28edd72b8 100644
--- a/drivers/edac/mce_amd.c
+++ b/drivers/edac/mce_amd.c
@@ -7,6 +7,8 @@
 
 #include 
 
+#include 
+
 #include "mce_amd.h"
 
 static struct amd_decoder_ops *fam_ops;
@@ -1082,7 +1084,7 @@ amd_decode_mce(struct notifier_block *nb, unsigned long 
val, void *data)
amd_decode_err_code(m->status & 0x);
 
if (ras_userspace_consumers()) {
-   trace_mce_decode(sb.buffer);
+   trace_mce_record(m, sb.buffer);
} else {
char *l;
 
@@ -1097,7 +1099,7 @@ amd_decode_mce(struct notifier_block *nb, unsigned long 
val, void *data)
 
 static struct notifier_block amd_mce_dec_nb = {
.notifier_call  = amd_decode_mce,
-   .priority   = MCE_PRIO_EDAC,
+   .priority   = MCE_PRIO_DECODER,
 };
 
 static int __init mce_amd_init(void)
diff --git a/include/trace/events/mce.h b/include/trace/events/mce.h
index 70f02149808c..82ff4014fab1 100644
--- a/include/trace/events/mce.h
+++ b/include/trace/events/mce.h
@@ -10,9 +10,9 @@
 
 TRACE_EVENT(mce_record,
 
-   TP_PROTO(struct mce *m),
+   TP_PROTO(struct mce *m, const char *param_str),
 
-   TP_ARGS(m),
+   TP_ARGS(m, param_str),
 
TP_STRUCT__entry(
__field(u64,mcgcap  )
@@ -32,6 +32,7 @@ TRACE_EVENT(mce_record,
__field(u8, cs  )
__field(u8, bank)
__field(u8, cpuvendor   )
+   __string(   str,param_str   )
),
 
TP_fast_assign(
@@ -52,9 +53,10 @@ TRACE_EVENT(mce_record,
__entry->cs = m->cs;
__entry->bank   = m->bank;
__entry->cpuvendor  = m->cpuvendor;
+   __assign_str(str, param_str);
),
 
-   

Re: [RFC PATCH 0/8] EDAC, mce_amd: Add a tracepoint for the decoded error

[Borislav Petkov]

Ok,

here's a working version. It looks pretty straight-forward (to me, at
least) and it does what it is supposed to when I inject an MCE:

# tracer: nop
#
#  _-=> irqs-off
# / _=> need-resched
#| / _---=> hardirq/softirq
#|| / _--=> preempt-depth
#||| / delay
#   TASK-PID   CPU#  TIMESTAMP  FUNCTION
#  | |   |      | |
 kworker/1:2-76[001]    316.852022: mce_record: CPU: 1, MCGc/s: 
100010a/0, MC5: dc0041020f0f, IPID: , ADDR/MISC/SYND: 
56071033//, RIP: 00:<>, 
TSC: 0, PROCESSOR: 2:600f20, TIME: 1501261272, SOCKET: 1, APIC: 1 MC5 Error: AG 
payload array parity error.
cache level: L3/GEN, mem/io: GEN, mem-tx: GEN, part-proc: GEN (timed out)
 kworker/1:2-76[001]    328.372055: mce_record: CPU: 1, MCGc/s: 
100010a/0, MC5: dc0041020f0f, IPID: , ADDR/MISC/SYND: 
56071033//, RIP: 00:<>, 
TSC: 0, PROCESSOR: 2:600f20, TIME: 1501261283, SOCKET: 1, APIC: 1 MC5 Error: AG 
payload array parity error.
cache level: L3/GEN, mem/io: GEN, mem-tx: GEN, part-proc: GEN (timed out)

diff ontop of the current pile:

---
diff --git a/arch/x86/include/asm/mce.h b/arch/x86/include/asm/mce.h
index 181264989db5..ba4c99ace544 100644
--- a/arch/x86/include/asm/mce.h
+++ b/arch/x86/include/asm/mce.h
@@ -146,6 +146,7 @@ struct mca_config {
bool ser;
bool recovery;
bool bios_cmci_threshold;
+   bool has_decoder;
u8 banks;
s8 bootlog;
int tolerant;
@@ -195,7 +196,8 @@ enum mce_notifier_prios {
MCE_PRIO_SRAO   = INT_MAX - 1,
MCE_PRIO_EXTLOG = INT_MAX - 2,
MCE_PRIO_NFIT   = INT_MAX - 3,
-   MCE_PRIO_EDAC   = INT_MAX - 4,
+   MCE_PRIO_DECODER= INT_MAX - 4,
+   MCE_PRIO_EDAC   = INT_MAX - 5,
MCE_PRIO_MCELOG = 1,
MCE_PRIO_LOWEST = 0,
 };
diff --git a/arch/x86/kernel/cpu/mcheck/mce.c b/arch/x86/kernel/cpu/mcheck/mce.c
index 6dde0497efc7..9486a2ca6556 100644
--- a/arch/x86/kernel/cpu/mcheck/mce.c
+++ b/arch/x86/kernel/cpu/mcheck/mce.c
@@ -162,6 +162,9 @@ void mce_register_decode_chain(struct notifier_block *nb)
 
atomic_inc(_notifiers);
 
+   if (nb->priority == MCE_PRIO_DECODER)
+   mca_cfg.has_decoder = true;
+
blocking_notifier_chain_register(_mce_decoder_chain, nb);
 }
 EXPORT_SYMBOL_GPL(mce_register_decode_chain);
@@ -556,7 +559,8 @@ static int mce_first_notifier(struct notifier_block *nb, 
unsigned long val,
return NOTIFY_STOP;
 
/* Emit the trace record: */
-   trace_mce_record(m);
+   if (!mca_cfg.has_decoder)
+   trace_mce_record(m, "");
 
set_bit(0, _need_notify);
 
diff --git a/drivers/edac/mce_amd.c b/drivers/edac/mce_amd.c
index fd4a615200a8..d0b28edd72b8 100644
--- a/drivers/edac/mce_amd.c
+++ b/drivers/edac/mce_amd.c
@@ -7,6 +7,8 @@
 
 #include 
 
+#include 
+
 #include "mce_amd.h"
 
 static struct amd_decoder_ops *fam_ops;
@@ -1082,7 +1084,7 @@ amd_decode_mce(struct notifier_block *nb, unsigned long 
val, void *data)
amd_decode_err_code(m->status & 0x);
 
if (ras_userspace_consumers()) {
-   trace_mce_decode(sb.buffer);
+   trace_mce_record(m, sb.buffer);
} else {
char *l;
 
@@ -1097,7 +1099,7 @@ amd_decode_mce(struct notifier_block *nb, unsigned long 
val, void *data)
 
 static struct notifier_block amd_mce_dec_nb = {
.notifier_call  = amd_decode_mce,
-   .priority   = MCE_PRIO_EDAC,
+   .priority   = MCE_PRIO_DECODER,
 };
 
 static int __init mce_amd_init(void)
diff --git a/include/trace/events/mce.h b/include/trace/events/mce.h
index 70f02149808c..82ff4014fab1 100644
--- a/include/trace/events/mce.h
+++ b/include/trace/events/mce.h
@@ -10,9 +10,9 @@
 
 TRACE_EVENT(mce_record,
 
-   TP_PROTO(struct mce *m),
+   TP_PROTO(struct mce *m, const char *param_str),
 
-   TP_ARGS(m),
+   TP_ARGS(m, param_str),
 
TP_STRUCT__entry(
__field(u64,mcgcap  )
@@ -32,6 +32,7 @@ TRACE_EVENT(mce_record,
__field(u8, cs  )
__field(u8, bank)
__field(u8, cpuvendor   )
+   __string(   str,param_str   )
),
 
TP_fast_assign(
@@ -52,9 +53,10 @@ TRACE_EVENT(mce_record,
__entry->cs = m->cs;
__entry->bank   = m->bank;
__entry->cpuvendor  = m->cpuvendor;
+   __assign_str(str, param_str);
),
 
-   

Re: [PATCH v7] workqueue: Fix edge cases for calc of pool's cpumask

[Tejun Heo]

On Thu, Jul 27, 2017 at 04:27:14PM -0500, Michael Bringmann wrote:
> 
> There is an underlying assumption/trade-off in many layers of the Linux
> system that CPU <-> node mapping is static.  This is despite the presence
> of features like NUMA and 'hotplug' that support the dynamic addition/
> removal of fundamental system resources like CPUs and memory.  PowerPC
> systems, however, do provide extensive features for the dynamic change
> of resources available to a system.
> 
> Currently, there is little or no synchronization protection around the
> updating of the CPU <-> node mapping, and the export/update of this
> information for other layers / modules.  In systems which can change
> this mapping during 'hotplug', like PowerPC, the information is changing
> underneath all layers that might reference it.
> 
> This patch attempts to ensure that a valid, usable cpumask attribute is
> used by the workqueue infrastructure when setting up new resource pools.
> It prevents a crash that has been observed when an 'empty' cpumask is
> passed along to the worker/task scheduling code.  It is intended as an
> intermediate fix until a more fundamental review and correction of the
> issue can be done.
> 
> [With additions to the patch provided by Tejun Hao ]
> 
> Signed-off-by: Michael Bringmann 

Applied to wq/for-4.13-fixes with "fix" replaced with "workaround".

Thanks.

-- 
tejun

Re: [PATCH v7] workqueue: Fix edge cases for calc of pool's cpumask

[Tejun Heo]

On Thu, Jul 27, 2017 at 04:27:14PM -0500, Michael Bringmann wrote:
> 
> There is an underlying assumption/trade-off in many layers of the Linux
> system that CPU <-> node mapping is static.  This is despite the presence
> of features like NUMA and 'hotplug' that support the dynamic addition/
> removal of fundamental system resources like CPUs and memory.  PowerPC
> systems, however, do provide extensive features for the dynamic change
> of resources available to a system.
> 
> Currently, there is little or no synchronization protection around the
> updating of the CPU <-> node mapping, and the export/update of this
> information for other layers / modules.  In systems which can change
> this mapping during 'hotplug', like PowerPC, the information is changing
> underneath all layers that might reference it.
> 
> This patch attempts to ensure that a valid, usable cpumask attribute is
> used by the workqueue infrastructure when setting up new resource pools.
> It prevents a crash that has been observed when an 'empty' cpumask is
> passed along to the worker/task scheduling code.  It is intended as an
> intermediate fix until a more fundamental review and correction of the
> issue can be done.
> 
> [With additions to the patch provided by Tejun Hao ]
> 
> Signed-off-by: Michael Bringmann 

Applied to wq/for-4.13-fixes with "fix" replaced with "workaround".

Thanks.

-- 
tejun

Re: [v3,04/10] ipw2200: constify attribute_group structures

[Kalle Valo]

Kalle Valo  writes:

> Arvind Yadav  wrote:
>
>> attribute_group are not supposed to change at runtime. All functions
>> working with attribute_group provided by  work
>> with const attribute_group. So mark the non-const structs as const.
>> 
>> Signed-off-by: Arvind Yadav 
>
> 4 patches applied to wireless-drivers-next.git, thanks.
>
> 17830147c40a mwifiex: fix spelling mistake: "Insuffient" -> "Insufficient"
> 185ffc194800 ipw2100: don't return positive values to PCI probe on error
> af643fe9bbe0 zd1211rw: fix spelling mistake 'hybernate' -> 'hibernate'
> e66d70b789d1 brcmfmac: constify pci_device_id

Please ignore this mail, I have a bug in my patchwork script.

-- 
Kalle Valo

Re: [v3,04/10] ipw2200: constify attribute_group structures

[Kalle Valo]

Kalle Valo  writes:

> Arvind Yadav  wrote:
>
>> attribute_group are not supposed to change at runtime. All functions
>> working with attribute_group provided by  work
>> with const attribute_group. So mark the non-const structs as const.
>> 
>> Signed-off-by: Arvind Yadav 
>
> 4 patches applied to wireless-drivers-next.git, thanks.
>
> 17830147c40a mwifiex: fix spelling mistake: "Insuffient" -> "Insufficient"
> 185ffc194800 ipw2100: don't return positive values to PCI probe on error
> af643fe9bbe0 zd1211rw: fix spelling mistake 'hybernate' -> 'hibernate'
> e66d70b789d1 brcmfmac: constify pci_device_id

Please ignore this mail, I have a bug in my patchwork script.

-- 
Kalle Valo

Re: wl3501_cs: fix spelling mistake: "Insupported" -> "Unsupported"

[Kalle Valo]

Colin Ian King  wrote:

> From: Colin Ian King 
> 
> Trivial fix to spelling mistake in printk message
> 
> Signed-off-by: Colin Ian King 

Patch applied to wireless-drivers-next.git, thanks.

fcc870d76a2c wl3501_cs: fix spelling mistake: "Insupported" -> "Unsupported"

-- 
https://patchwork.kernel.org/patch/9867579/

https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches

Re: wl3501_cs: fix spelling mistake: "Insupported" -> "Unsupported"

[Kalle Valo]

Colin Ian King  wrote:

> From: Colin Ian King 
> 
> Trivial fix to spelling mistake in printk message
> 
> Signed-off-by: Colin Ian King 

Patch applied to wireless-drivers-next.git, thanks.

fcc870d76a2c wl3501_cs: fix spelling mistake: "Insupported" -> "Unsupported"

-- 
https://patchwork.kernel.org/patch/9867579/

https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches

Re: [v3,04/10] ipw2200: constify attribute_group structures

[Kalle Valo]

Arvind Yadav  wrote:

> attribute_group are not supposed to change at runtime. All functions
> working with attribute_group provided by  work
> with const attribute_group. So mark the non-const structs as const.
> 
> Signed-off-by: Arvind Yadav 

4 patches applied to wireless-drivers-next.git, thanks.

17830147c40a mwifiex: fix spelling mistake: "Insuffient" -> "Insufficient"
185ffc194800 ipw2100: don't return positive values to PCI probe on error
af643fe9bbe0 zd1211rw: fix spelling mistake 'hybernate' -> 'hibernate'
e66d70b789d1 brcmfmac: constify pci_device_id

-- 
https://patchwork.kernel.org/patch/9847373/

https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches

Re: [v3,04/10] ipw2200: constify attribute_group structures

[Kalle Valo]

Arvind Yadav  wrote:

> attribute_group are not supposed to change at runtime. All functions
> working with attribute_group provided by  work
> with const attribute_group. So mark the non-const structs as const.
> 
> Signed-off-by: Arvind Yadav 

4 patches applied to wireless-drivers-next.git, thanks.

17830147c40a mwifiex: fix spelling mistake: "Insuffient" -> "Insufficient"
185ffc194800 ipw2100: don't return positive values to PCI probe on error
af643fe9bbe0 zd1211rw: fix spelling mistake 'hybernate' -> 'hibernate'
e66d70b789d1 brcmfmac: constify pci_device_id

-- 
https://patchwork.kernel.org/patch/9847373/

https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches

Re: [11/11] brcmfmac: constify pci_device_id

[Kalle Valo]

Arvind Yadav  wrote:

> pci_device_id are not supposed to change at runtime. All functions
> working with pci_device_id provided by  work with
> const pci_device_id. So mark the non-const structs as const.
> 
> Signed-off-by: Arvind Yadav 
> Acked-by: Arend van Spriel 

Patch applied to wireless-drivers-next.git, thanks.

e66d70b789d1 brcmfmac: constify pci_device_id

-- 
https://patchwork.kernel.org/patch/9845919/

https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches

Re: [11/11] brcmfmac: constify pci_device_id

[Kalle Valo]

Arvind Yadav  wrote:

> pci_device_id are not supposed to change at runtime. All functions
> working with pci_device_id provided by  work with
> const pci_device_id. So mark the non-const structs as const.
> 
> Signed-off-by: Arvind Yadav 
> Acked-by: Arend van Spriel 

Patch applied to wireless-drivers-next.git, thanks.

e66d70b789d1 brcmfmac: constify pci_device_id

-- 
https://patchwork.kernel.org/patch/9845919/

https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches

Re: zd1211rw: fix spelling mistake 'hybernate' -> 'hibernate'

[Kalle Valo]

Colin Ian King  wrote:

> From: Colin Ian King 
> 
> Trivial fix to spelling mistake in PDEBUG debug message.
> 
> Signed-off-by: Colin Ian King 

Patch applied to wireless-drivers-next.git, thanks.

af643fe9bbe0 zd1211rw: fix spelling mistake 'hybernate' -> 'hibernate'

-- 
https://patchwork.kernel.org/patch/9839689/

https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches

Re: zd1211rw: fix spelling mistake 'hybernate' -> 'hibernate'

[Kalle Valo]

Colin Ian King  wrote:

> From: Colin Ian King 
> 
> Trivial fix to spelling mistake in PDEBUG debug message.
> 
> Signed-off-by: Colin Ian King 

Patch applied to wireless-drivers-next.git, thanks.

af643fe9bbe0 zd1211rw: fix spelling mistake 'hybernate' -> 'hibernate'

-- 
https://patchwork.kernel.org/patch/9839689/

https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches

Re: [PATCH v2 2/2] crypto: engine - Permit to enqueue skcipher request

[Corentin Labbe]

On Fri, Jul 28, 2017 at 09:52:57PM +0800, Herbert Xu wrote:
> On Fri, Jul 14, 2017 at 01:15:36PM +0200, Corentin Labbe wrote:
> > On Fri, Jun 23, 2017 at 02:48:37PM +0800, Herbert Xu wrote:
> > > On Mon, Jun 19, 2017 at 09:55:24AM +0200, Corentin Labbe wrote:
> > > >
> > > > Since there are two different user of "crypto engine + ablkcipher", it 
> > > > will be not easy to convert them in one serie. (I could do it, but I 
> > > > simply could not test it for OMAP (lack of hw))
> > > > And any new user which want to use crypto engine+skcipher (like me with 
> > > > the sun8i-ce driver) are simply stuck.
> > > 
> > > You're right.  We'll need to do this in a backwards-compatible way.  In 
> > > fact
> > > we already do something similar in skcipher.c itself.  Simply look at the
> > > cra_type field and if it matches blkcipher/ablkcipher/givcipher then it's
> > > legacy ablkcipher, otherwise it's skcipher.
> > > 
> > > Also the way crypto_engine looks at the request type in the data-path is
> > > suboptimal.  This should really be built into the cra_type object.  For
> > > example, we can have cra_type->engine->prepare_request which would just
> > > do the right thing.
> > > 
> > 
> > Not sure to have well understand what you want.
> > You want that I switch on cra_type instead of crypto_tfm_alg_type() ?
> 
> No I mean that we should have an engine hooks object registered
> under cra_type so that you simply call
> 
>   cra_type->engine->prepare_request()
> 
> regardless of what type you're using.
> 

I am sorry, I didnt see how to do that.

Re: [PATCH v2 2/2] crypto: engine - Permit to enqueue skcipher request

[Corentin Labbe]

On Fri, Jul 28, 2017 at 09:52:57PM +0800, Herbert Xu wrote:
> On Fri, Jul 14, 2017 at 01:15:36PM +0200, Corentin Labbe wrote:
> > On Fri, Jun 23, 2017 at 02:48:37PM +0800, Herbert Xu wrote:
> > > On Mon, Jun 19, 2017 at 09:55:24AM +0200, Corentin Labbe wrote:
> > > >
> > > > Since there are two different user of "crypto engine + ablkcipher", it 
> > > > will be not easy to convert them in one serie. (I could do it, but I 
> > > > simply could not test it for OMAP (lack of hw))
> > > > And any new user which want to use crypto engine+skcipher (like me with 
> > > > the sun8i-ce driver) are simply stuck.
> > > 
> > > You're right.  We'll need to do this in a backwards-compatible way.  In 
> > > fact
> > > we already do something similar in skcipher.c itself.  Simply look at the
> > > cra_type field and if it matches blkcipher/ablkcipher/givcipher then it's
> > > legacy ablkcipher, otherwise it's skcipher.
> > > 
> > > Also the way crypto_engine looks at the request type in the data-path is
> > > suboptimal.  This should really be built into the cra_type object.  For
> > > example, we can have cra_type->engine->prepare_request which would just
> > > do the right thing.
> > > 
> > 
> > Not sure to have well understand what you want.
> > You want that I switch on cra_type instead of crypto_tfm_alg_type() ?
> 
> No I mean that we should have an engine hooks object registered
> under cra_type so that you simply call
> 
>   cra_type->engine->prepare_request()
> 
> regardless of what type you're using.
> 

I am sorry, I didnt see how to do that.

Re: [PATCH 2/2] printk: Add boottime and real timestamps

[Prarit Bhargava]

On 07/25/2017 09:00 AM, Peter Zijlstra wrote:
> On Tue, Jul 25, 2017 at 08:17:27AM -0400, Prarit Bhargava wrote:
>> diff --git a/lib/Kconfig.debug b/lib/Kconfig.debug
>> index 5b1662ec546f..6cd38a25f8ea 100644
>> --- a/lib/Kconfig.debug
>> +++ b/lib/Kconfig.debug
>> @@ -1,8 +1,8 @@
>>  menu "printk and dmesg options"
>>  
>>  config PRINTK_TIME
>> -int "Show timing information on printks (0-1)"
>> -range 0 1
>> +int "Show timing information on printks (0-3)"
>> +range 0 3
>>  default "0"
>>  depends on PRINTK
>>  help
>> @@ -13,7 +13,8 @@ config PRINTK_TIME
>>The timestamp is always recorded internally, and exported
>>to /dev/kmsg. This flag just specifies if the timestamp should
>>be included, not that the timestamp is recorded. 0 disables the
>> -  timestamp and 1 uses the local clock.
>> +  timestamp and 1 uses the local clock, 2 uses the monotonic clock, and
>> +  3 uses real clock.
>>  
>>The behavior is also controlled by the kernel command line
>>parameter printk.time=1. See 
>> Documentation/admin-guide/kernel-parameters.rst
> 
> 
> choice
>   prompt "printk default clock"
>   default PRIMTK_TIME_DISABLE
>   help
>goes here
> 
>   config PRINTK_TIME_DISABLE
>   bool "Disabled"
>   help
>goes here
> 
>   config PRINTK_TIME_LOCAL
>   bool "local clock"
>   help
>goes here
> 
>   config PRINTK_TIME_MONO
>   bool "CLOCK_MONOTONIC"
>   help
>goes here
> 
>   config PRINTK_TIME_REAL
>   bool "CLOCK_REALTIME"
>   help
>goes here
> 
> endchoice
> 
> config PRINTK_TIME
>   int
>   default 0 if PRINTK_TIME_DISABLE
>   default 1 if PRINTK_TIME_LOCAL
>   default 2 if PRINTK_TIME_MONO
>   default 3 if PRINTK_TIME_REAL
> 
> 

Thanks for the above change.  I can see that makes the code simpler.

> Although I must strongly discourage using REALTIME, DST will make
> untangling your logs an absolute nightmare. I would simply not provide
> it.

I understand your concern, however, I've been in situations where REALTIME
stamping has pointed me in the direction of where a bug was.  Even with the
complicated logs I think it is worthwhile.

P.

Re: [PATCH 2/2] printk: Add boottime and real timestamps

[Prarit Bhargava]

On 07/25/2017 09:00 AM, Peter Zijlstra wrote:
> On Tue, Jul 25, 2017 at 08:17:27AM -0400, Prarit Bhargava wrote:
>> diff --git a/lib/Kconfig.debug b/lib/Kconfig.debug
>> index 5b1662ec546f..6cd38a25f8ea 100644
>> --- a/lib/Kconfig.debug
>> +++ b/lib/Kconfig.debug
>> @@ -1,8 +1,8 @@
>>  menu "printk and dmesg options"
>>  
>>  config PRINTK_TIME
>> -int "Show timing information on printks (0-1)"
>> -range 0 1
>> +int "Show timing information on printks (0-3)"
>> +range 0 3
>>  default "0"
>>  depends on PRINTK
>>  help
>> @@ -13,7 +13,8 @@ config PRINTK_TIME
>>The timestamp is always recorded internally, and exported
>>to /dev/kmsg. This flag just specifies if the timestamp should
>>be included, not that the timestamp is recorded. 0 disables the
>> -  timestamp and 1 uses the local clock.
>> +  timestamp and 1 uses the local clock, 2 uses the monotonic clock, and
>> +  3 uses real clock.
>>  
>>The behavior is also controlled by the kernel command line
>>parameter printk.time=1. See 
>> Documentation/admin-guide/kernel-parameters.rst
> 
> 
> choice
>   prompt "printk default clock"
>   default PRIMTK_TIME_DISABLE
>   help
>goes here
> 
>   config PRINTK_TIME_DISABLE
>   bool "Disabled"
>   help
>goes here
> 
>   config PRINTK_TIME_LOCAL
>   bool "local clock"
>   help
>goes here
> 
>   config PRINTK_TIME_MONO
>   bool "CLOCK_MONOTONIC"
>   help
>goes here
> 
>   config PRINTK_TIME_REAL
>   bool "CLOCK_REALTIME"
>   help
>goes here
> 
> endchoice
> 
> config PRINTK_TIME
>   int
>   default 0 if PRINTK_TIME_DISABLE
>   default 1 if PRINTK_TIME_LOCAL
>   default 2 if PRINTK_TIME_MONO
>   default 3 if PRINTK_TIME_REAL
> 
> 

Thanks for the above change.  I can see that makes the code simpler.

> Although I must strongly discourage using REALTIME, DST will make
> untangling your logs an absolute nightmare. I would simply not provide
> it.

I understand your concern, however, I've been in situations where REALTIME
stamping has pointed me in the direction of where a bug was.  Even with the
complicated logs I think it is worthwhile.

P.

Re: [PATCH 1/3] perf tools: Add callchain to ctf conversion

[Arnaldo Carvalho de Melo]

Em Fri, Jul 28, 2017 at 11:25:50AM +0200, Jiri Olsa escreveu:
> On Thu, Jul 27, 2017 at 02:12:03PM -0400, Geneviève Bastien wrote:
> > The field perf_callchain, if available, is added to the sampling
> > events during the CTF conversion. It is an array of u64 values.
> > The perf_callchain_size field contains the size of the array.
> > 
> > It will allow the analysis of sampling data in trace visualization tools
> > like Trace Compass. Possible analyses with those data: dynamic
> > flamegraphs, correlation with other tracing data like a userspace trace.
> > 
> > Here follows a babeltrace CTF output of a trace with callchain:
> > 
> >  $ babeltrace ./myctftrace
> >  [17:38:45.672760285] (+?.?) cycles:ppp: { cpu_id = 0 }, { perf_ip 
> > = 0x81063EE4, perf_tid = 25841, perf_pid = 25774, perf_period = 1, 
> > perf_callchain_size = 7, perf_callchain = [ [0] = 0xFF80, [1] = 
> > 0x81063EE4, [2] = 0x8100C770, [3] = 0x81006EC6, [4] 
> > = 0x8118245E, [5] = 0x810A9224, [6] = 0x8164A4C6 ] }
> >  [17:38:45.672777672] (+0.17387) cycles:ppp: { cpu_id = 0 }, { perf_ip 
> > = 0x81063EE4, perf_tid = 25841, perf_pid = 25774, perf_period = 1, 
> > perf_callchain_size = 8, perf_callchain = [ [0] = 0xFF80, [1] = 
> > 0x81063EE4, [2] = 0x8100C770, [3] = 0x81006EC6, [4] 
> > = 0x8118245E, [5] = 0x810A9224, [6] = 0x8164A4C6, 
> > [7] = 0x8164ABAD ] }
> >  [17:38:45.672786700] (+0.09028) cycles:ppp: { cpu_id = 0 }, { perf_ip 
> > = 0x81063EE4, perf_tid = 25841, perf_pid = 25774, perf_period = 70, 
> > perf_callchain_size = 3, perf_callchain = [ [0] = 0xFF80, [1] = 
> > 0x81063EE4, [2] = 0x8100C770 ] }
> 
> missing one more hunk (attached) ;-)
> 
> I guess there's no need to resend, Arnaldo could remove it,

yeah, will do

> anyway for patchset:
> 
> Acked-by: Jiri Olsa 

Thanks!

- Arnaldo
 
> Is there already tracecompas change to display callchains and mmaps?
> 
> thanks,
> jirka
> 
> 
> ---
> diff --git a/tools/perf/util/data-convert-bt.c 
> b/tools/perf/util/data-convert-bt.c
> index c47b0943ef88..2346cecb8ea2 100644
> --- a/tools/perf/util/data-convert-bt.c
> +++ b/tools/perf/util/data-convert-bt.c
> @@ -596,7 +596,6 @@ static int add_generic_values(struct ctf_writer *cw,
>*   PERF_SAMPLE_TIME - not needed as we have it in
>*  ctf event header
>*   PERF_SAMPLE_READ - TODO
> -  *   PERF_SAMPLE_CALLCHAIN- TODO
>*   PERF_SAMPLE_RAW  - tracepoint fields are handled separately
>*   PERF_SAMPLE_BRANCH_STACK - TODO
>*   PERF_SAMPLE_REGS_USER- TODO

Re: [PATCH 1/3] perf tools: Add callchain to ctf conversion

[Arnaldo Carvalho de Melo]

Em Fri, Jul 28, 2017 at 11:25:50AM +0200, Jiri Olsa escreveu:
> On Thu, Jul 27, 2017 at 02:12:03PM -0400, Geneviève Bastien wrote:
> > The field perf_callchain, if available, is added to the sampling
> > events during the CTF conversion. It is an array of u64 values.
> > The perf_callchain_size field contains the size of the array.
> > 
> > It will allow the analysis of sampling data in trace visualization tools
> > like Trace Compass. Possible analyses with those data: dynamic
> > flamegraphs, correlation with other tracing data like a userspace trace.
> > 
> > Here follows a babeltrace CTF output of a trace with callchain:
> > 
> >  $ babeltrace ./myctftrace
> >  [17:38:45.672760285] (+?.?) cycles:ppp: { cpu_id = 0 }, { perf_ip 
> > = 0x81063EE4, perf_tid = 25841, perf_pid = 25774, perf_period = 1, 
> > perf_callchain_size = 7, perf_callchain = [ [0] = 0xFF80, [1] = 
> > 0x81063EE4, [2] = 0x8100C770, [3] = 0x81006EC6, [4] 
> > = 0x8118245E, [5] = 0x810A9224, [6] = 0x8164A4C6 ] }
> >  [17:38:45.672777672] (+0.17387) cycles:ppp: { cpu_id = 0 }, { perf_ip 
> > = 0x81063EE4, perf_tid = 25841, perf_pid = 25774, perf_period = 1, 
> > perf_callchain_size = 8, perf_callchain = [ [0] = 0xFF80, [1] = 
> > 0x81063EE4, [2] = 0x8100C770, [3] = 0x81006EC6, [4] 
> > = 0x8118245E, [5] = 0x810A9224, [6] = 0x8164A4C6, 
> > [7] = 0x8164ABAD ] }
> >  [17:38:45.672786700] (+0.09028) cycles:ppp: { cpu_id = 0 }, { perf_ip 
> > = 0x81063EE4, perf_tid = 25841, perf_pid = 25774, perf_period = 70, 
> > perf_callchain_size = 3, perf_callchain = [ [0] = 0xFF80, [1] = 
> > 0x81063EE4, [2] = 0x8100C770 ] }
> 
> missing one more hunk (attached) ;-)
> 
> I guess there's no need to resend, Arnaldo could remove it,

yeah, will do

> anyway for patchset:
> 
> Acked-by: Jiri Olsa 

Thanks!

- Arnaldo
 
> Is there already tracecompas change to display callchains and mmaps?
> 
> thanks,
> jirka
> 
> 
> ---
> diff --git a/tools/perf/util/data-convert-bt.c 
> b/tools/perf/util/data-convert-bt.c
> index c47b0943ef88..2346cecb8ea2 100644
> --- a/tools/perf/util/data-convert-bt.c
> +++ b/tools/perf/util/data-convert-bt.c
> @@ -596,7 +596,6 @@ static int add_generic_values(struct ctf_writer *cw,
>*   PERF_SAMPLE_TIME - not needed as we have it in
>*  ctf event header
>*   PERF_SAMPLE_READ - TODO
> -  *   PERF_SAMPLE_CALLCHAIN- TODO
>*   PERF_SAMPLE_RAW  - tracepoint fields are handled separately
>*   PERF_SAMPLE_BRANCH_STACK - TODO
>*   PERF_SAMPLE_REGS_USER- TODO

Re: Suspend-resume failure on Intel Eagle Lake Core2Duo

[Tomi Sarvela]

On 28/07/17 17:50, Thomas Gleixner wrote:

On Fri, 28 Jul 2017, Tomi Sarvela wrote:

On 28/07/17 17:13, Thomas Gleixner wrote:

On Fri, 28 Jul 2017, Tomi Sarvela wrote:

On 28/07/17 16:15, Thomas Gleixner wrote:

Another question. Is the machine completely dead or not?


Completely dead. Powerled is on, so host isn't shut down.


So that means it does not even power the machine down. That's what I
expected least.


Serial or network if don't give any signs of life.



Patch applies cleanly but still getting the same error:


Sorry for the noise. I'm an idiot trying to do 10 things at once. This time
it actually compiles and links.

If the machine does still not powerdown with this applied, then please redo
the 'platform' test and grab the trace for that one.


This patch fixes the issue. Below is the dmesg from the testrun (sorry for the
spam, we're primarily testing i915 issues).


Can you please retrieve the trace data from:

/sys/kernel/debug/tracing/trace

and provide that. The dmesg does not help much.


Right, here you go.

$ sudo cat /sys/kernel/debug/tracing/trace
# tracer: nop
#
#  _-=> irqs-off
# / _=> need-resched
#| / _---=> hardirq/softirq
#|| / _--=> preempt-depth
#||| / delay
#   TASK-PID   CPU#  TIMESTAMP  FUNCTION
#  | |   |      | |
 rtcwake-1332  [000] d..164.411098: suspend_device_irqs: 
presuspend 0 state 00400600
 rtcwake-1332  [000] d..164.411101: suspend_device_irqs: 
postsuspend 0 state 00400600
 rtcwake-1332  [000] d..164.411102: suspend_device_irqs: 
presuspend 1 state 0003
 rtcwake-1332  [000] d..164.411103: suspend_device_irqs: 
postsuspend 1 state 0003
 rtcwake-1332  [000] d..164.411104: suspend_device_irqs: 
presuspend 2 state 0003
 rtcwake-1332  [000] d..164.411104: suspend_device_irqs: 
postsuspend 2 state 0003
 rtcwake-1332  [000] d..164.411105: suspend_device_irqs: 
presuspend 3 state 0003
 rtcwake-1332  [000] d..164.411106: suspend_device_irqs: 
postsuspend 3 state 0003
 rtcwake-1332  [000] d..164.411107: suspend_device_irqs: 
presuspend 4 state 00031000
 rtcwake-1332  [000] d..164.411107: suspend_device_irqs: 
postsuspend 4 state 00031000
 rtcwake-1332  [000] d..164.411108: suspend_device_irqs: 
presuspend 5 state 0003
 rtcwake-1332  [000] d..164.411108: suspend_device_irqs: 
postsuspend 5 state 0003
 rtcwake-1332  [000] d..164.411109: suspend_device_irqs: 
presuspend 6 state 0003
 rtcwake-1332  [000] d..164.40: suspend_device_irqs: 
postsuspend 6 state 0003
 rtcwake-1332  [000] d..164.40: suspend_device_irqs: 
presuspend 7 state 0003
 rtcwake-1332  [000] d..164.41: suspend_device_irqs: 
postsuspend 7 state 0003
 rtcwake-1332  [000] d..164.42: suspend_device_irqs: 
presuspend 8 state 00401200
 rtcwake-1332  [000] d..164.42: __irq_disable: 
predisable 8 state 00401200
 rtcwake-1332  [000] d..164.43: __irq_disable: 
postdisable 8 state 00411200
 rtcwake-1332  [000] d..164.44: suspend_device_irqs: 
postsuspend 8 state 00411200
 rtcwake-1332  [000] d..164.45: suspend_device_irqs: 
presuspend 9 state 00403300
 rtcwake-1332  [000] d..164.45: __irq_disable: 
predisable 9 state 00403300
 rtcwake-1332  [000] d..164.46: __irq_disable: 
postdisable 9 state 00413300
 rtcwake-1332  [000] d..164.46: suspend_device_irqs: 
postsuspend 9 state 00413300
 rtcwake-1332  [000] d..164.47: suspend_device_irqs: 
presuspend 10 state 0003
 rtcwake-1332  [000] d..164.48: suspend_device_irqs: 
postsuspend 10 state 0003
 rtcwake-1332  [000] d..164.49: suspend_device_irqs: 
presuspend 11 state 0003
 rtcwake-1332  [000] d..164.49: suspend_device_irqs: 
postsuspend 11 state 0003
 rtcwake-1332  [000] d..164.411120: suspend_device_irqs: 
presuspend 12 state 0003
 rtcwake-1332  [000] d..164.411120: suspend_device_irqs: 
postsuspend 12 state 0003
 rtcwake-1332  [000] d..164.411121: suspend_device_irqs: 
presuspend 13 state 0003
 rtcwake-1332  [000] d..164.411122: suspend_device_irqs: 
postsuspend 13 state 0003
 rtcwake-1332  [000] d..164.411122: suspend_device_irqs: 
presuspend 14 state 0003
 rtcwake-1332  [000] d..164.411123: suspend_device_irqs: 
postsuspend 14 state 0003
 rtcwake-1332  [000] d..164.411124: suspend_device_irqs: 
presuspend 15 state 0003
 rtcwake-1332  [000] d..164.411124: suspend_device_irqs: 
postsuspend 15 state 

Re: Suspend-resume failure on Intel Eagle Lake Core2Duo

[Tomi Sarvela]

On 28/07/17 17:50, Thomas Gleixner wrote:

On Fri, 28 Jul 2017, Tomi Sarvela wrote:

On 28/07/17 17:13, Thomas Gleixner wrote:

On Fri, 28 Jul 2017, Tomi Sarvela wrote:

On 28/07/17 16:15, Thomas Gleixner wrote:

Another question. Is the machine completely dead or not?


Completely dead. Powerled is on, so host isn't shut down.


So that means it does not even power the machine down. That's what I
expected least.


Serial or network if don't give any signs of life.



Patch applies cleanly but still getting the same error:


Sorry for the noise. I'm an idiot trying to do 10 things at once. This time
it actually compiles and links.

If the machine does still not powerdown with this applied, then please redo
the 'platform' test and grab the trace for that one.


This patch fixes the issue. Below is the dmesg from the testrun (sorry for the
spam, we're primarily testing i915 issues).


Can you please retrieve the trace data from:

/sys/kernel/debug/tracing/trace

and provide that. The dmesg does not help much.


Right, here you go.

$ sudo cat /sys/kernel/debug/tracing/trace
# tracer: nop
#
#  _-=> irqs-off
# / _=> need-resched
#| / _---=> hardirq/softirq
#|| / _--=> preempt-depth
#||| / delay
#   TASK-PID   CPU#  TIMESTAMP  FUNCTION
#  | |   |      | |
 rtcwake-1332  [000] d..164.411098: suspend_device_irqs: 
presuspend 0 state 00400600
 rtcwake-1332  [000] d..164.411101: suspend_device_irqs: 
postsuspend 0 state 00400600
 rtcwake-1332  [000] d..164.411102: suspend_device_irqs: 
presuspend 1 state 0003
 rtcwake-1332  [000] d..164.411103: suspend_device_irqs: 
postsuspend 1 state 0003
 rtcwake-1332  [000] d..164.411104: suspend_device_irqs: 
presuspend 2 state 0003
 rtcwake-1332  [000] d..164.411104: suspend_device_irqs: 
postsuspend 2 state 0003
 rtcwake-1332  [000] d..164.411105: suspend_device_irqs: 
presuspend 3 state 0003
 rtcwake-1332  [000] d..164.411106: suspend_device_irqs: 
postsuspend 3 state 0003
 rtcwake-1332  [000] d..164.411107: suspend_device_irqs: 
presuspend 4 state 00031000
 rtcwake-1332  [000] d..164.411107: suspend_device_irqs: 
postsuspend 4 state 00031000
 rtcwake-1332  [000] d..164.411108: suspend_device_irqs: 
presuspend 5 state 0003
 rtcwake-1332  [000] d..164.411108: suspend_device_irqs: 
postsuspend 5 state 0003
 rtcwake-1332  [000] d..164.411109: suspend_device_irqs: 
presuspend 6 state 0003
 rtcwake-1332  [000] d..164.40: suspend_device_irqs: 
postsuspend 6 state 0003
 rtcwake-1332  [000] d..164.40: suspend_device_irqs: 
presuspend 7 state 0003
 rtcwake-1332  [000] d..164.41: suspend_device_irqs: 
postsuspend 7 state 0003
 rtcwake-1332  [000] d..164.42: suspend_device_irqs: 
presuspend 8 state 00401200
 rtcwake-1332  [000] d..164.42: __irq_disable: 
predisable 8 state 00401200
 rtcwake-1332  [000] d..164.43: __irq_disable: 
postdisable 8 state 00411200
 rtcwake-1332  [000] d..164.44: suspend_device_irqs: 
postsuspend 8 state 00411200
 rtcwake-1332  [000] d..164.45: suspend_device_irqs: 
presuspend 9 state 00403300
 rtcwake-1332  [000] d..164.45: __irq_disable: 
predisable 9 state 00403300
 rtcwake-1332  [000] d..164.46: __irq_disable: 
postdisable 9 state 00413300
 rtcwake-1332  [000] d..164.46: suspend_device_irqs: 
postsuspend 9 state 00413300
 rtcwake-1332  [000] d..164.47: suspend_device_irqs: 
presuspend 10 state 0003
 rtcwake-1332  [000] d..164.48: suspend_device_irqs: 
postsuspend 10 state 0003
 rtcwake-1332  [000] d..164.49: suspend_device_irqs: 
presuspend 11 state 0003
 rtcwake-1332  [000] d..164.49: suspend_device_irqs: 
postsuspend 11 state 0003
 rtcwake-1332  [000] d..164.411120: suspend_device_irqs: 
presuspend 12 state 0003
 rtcwake-1332  [000] d..164.411120: suspend_device_irqs: 
postsuspend 12 state 0003
 rtcwake-1332  [000] d..164.411121: suspend_device_irqs: 
presuspend 13 state 0003
 rtcwake-1332  [000] d..164.411122: suspend_device_irqs: 
postsuspend 13 state 0003
 rtcwake-1332  [000] d..164.411122: suspend_device_irqs: 
presuspend 14 state 0003
 rtcwake-1332  [000] d..164.411123: suspend_device_irqs: 
postsuspend 14 state 0003
 rtcwake-1332  [000] d..164.411124: suspend_device_irqs: 
presuspend 15 state 0003
 rtcwake-1332  [000] d..164.411124: suspend_device_irqs: 
postsuspend 15 state 

Re: mwifiex: fix spelling mistake: "Insuffient" -> "Insufficient"

[Kalle Valo]

Colin Ian King  wrote:

> From: Colin Ian King 
> 
> Trivial fix to spelling mistake in mwifiex_dbg debug message
> 
> Signed-off-by: Colin Ian King 

Patch applied to wireless-drivers-next.git, thanks.

17830147c40a mwifiex: fix spelling mistake: "Insuffient" -> "Insufficient"

-- 
https://patchwork.kernel.org/patch/9867575/

https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches

Re: mwifiex: fix spelling mistake: "Insuffient" -> "Insufficient"

[Kalle Valo]

Colin Ian King  wrote:

> From: Colin Ian King 
> 
> Trivial fix to spelling mistake in mwifiex_dbg debug message
> 
> Signed-off-by: Colin Ian King 

Patch applied to wireless-drivers-next.git, thanks.

17830147c40a mwifiex: fix spelling mistake: "Insuffient" -> "Insufficient"

-- 
https://patchwork.kernel.org/patch/9867575/

https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches

[PATCH] xen: avoid deadlock in xenbus

[Juergen Gross]

When starting the xenwatch thread a theoretical deadlock situation is
possible:

xs_init() contains:

task = kthread_run(xenwatch_thread, NULL, "xenwatch");
if (IS_ERR(task))
return PTR_ERR(task);
xenwatch_pid = task->pid;

And xenwatch_thread() does:

mutex_lock(_mutex);
...
event->handle->callback();
...
mutex_unlock(_mutex);

The callback could call unregister_xenbus_watch() which does:

...
if (current->pid != xenwatch_pid)
mutex_lock(_mutex);
...

In case a watch is firing before xenwatch_pid could be set and the
callback of that watch unregisters a watch, then a self-deadlock would
occur.

Avoid this by setting xenwatch_pid in xenwatch_thread().

Signed-off-by: Juergen Gross 
---
 drivers/xen/xenbus/xenbus_xs.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/xen/xenbus/xenbus_xs.c b/drivers/xen/xenbus/xenbus_xs.c
index e46080214955..3e59590c7254 100644
--- a/drivers/xen/xenbus/xenbus_xs.c
+++ b/drivers/xen/xenbus/xenbus_xs.c
@@ -857,6 +857,8 @@ static int xenwatch_thread(void *unused)
struct list_head *ent;
struct xs_watch_event *event;
 
+   xenwatch_pid = current->pid;
+
for (;;) {
wait_event_interruptible(watch_events_waitq,
 !list_empty(_events));
@@ -925,7 +927,6 @@ int xs_init(void)
task = kthread_run(xenwatch_thread, NULL, "xenwatch");
if (IS_ERR(task))
return PTR_ERR(task);
-   xenwatch_pid = task->pid;
 
/* shutdown watches for kexec boot */
xs_reset_watches();
-- 
2.12.3

[PATCH] xen: avoid deadlock in xenbus

[Juergen Gross]

When starting the xenwatch thread a theoretical deadlock situation is
possible:

xs_init() contains:

task = kthread_run(xenwatch_thread, NULL, "xenwatch");
if (IS_ERR(task))
return PTR_ERR(task);
xenwatch_pid = task->pid;

And xenwatch_thread() does:

mutex_lock(_mutex);
...
event->handle->callback();
...
mutex_unlock(_mutex);

The callback could call unregister_xenbus_watch() which does:

...
if (current->pid != xenwatch_pid)
mutex_lock(_mutex);
...

In case a watch is firing before xenwatch_pid could be set and the
callback of that watch unregisters a watch, then a self-deadlock would
occur.

Avoid this by setting xenwatch_pid in xenwatch_thread().

Signed-off-by: Juergen Gross 
---
 drivers/xen/xenbus/xenbus_xs.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/xen/xenbus/xenbus_xs.c b/drivers/xen/xenbus/xenbus_xs.c
index e46080214955..3e59590c7254 100644
--- a/drivers/xen/xenbus/xenbus_xs.c
+++ b/drivers/xen/xenbus/xenbus_xs.c
@@ -857,6 +857,8 @@ static int xenwatch_thread(void *unused)
struct list_head *ent;
struct xs_watch_event *event;
 
+   xenwatch_pid = current->pid;
+
for (;;) {
wait_event_interruptible(watch_events_waitq,
 !list_empty(_events));
@@ -925,7 +927,6 @@ int xs_init(void)
task = kthread_run(xenwatch_thread, NULL, "xenwatch");
if (IS_ERR(task))
return PTR_ERR(task);
-   xenwatch_pid = task->pid;
 
/* shutdown watches for kexec boot */
xs_reset_watches();
-- 
2.12.3

[PATCH] hysdn: fix to a race condition in put_log_buffer

[Anton Volkov]

The synchronization type that was used earlier to guard the loop that
deletes unused log buffers may have lead to a situation that prevents 
any thread from going through the loop.


The patch deletes previously used synchronization mechanism and moves
the loop under the spin_lock so the similar cases won't be feasible in
the future.

Found by by Linux Driver Verification project (linuxtesting.org).

Signed-off-by: Anton Volkov 
---
 drivers/isdn/hysdn/hysdn_proclog.c | 27 ---
 1 file changed, 12 insertions(+), 15 deletions(-)

diff --git a/drivers/isdn/hysdn/hysdn_proclog.c 
b/drivers/isdn/hysdn/hysdn_proclog.c

index 7b5fd8fb1761..b152c6ca444b 100644
--- a/drivers/isdn/hysdn/hysdn_proclog.c
+++ b/drivers/isdn/hysdn/hysdn_proclog.c
@@ -44,7 +44,6 @@ struct procdata {
char log_name[15];  /* log filename */
struct log_data *log_head, *log_tail;   /* head and tail for queue */
int if_used;/* open count for interface */
-   int volatile del_lock;  /* lock for delete operations */
unsigned char logtmp[LOG_MAX_LINELEN];
wait_queue_head_t rd_queue;
 };
@@ -102,7 +101,6 @@ put_log_buffer(hysdn_card *card, char *cp)
 {
struct log_data *ib;
struct procdata *pd = card->proclog;
-   int i;
unsigned long flags;

if (!pd)
@@ -126,21 +124,20 @@ put_log_buffer(hysdn_card *card, char *cp)
else
pd->log_tail->next = ib;  /* follows existing messages */
pd->log_tail = ib;   /* new tail */
-   i = pd->del_lock++;  /* get lock state */
-   spin_unlock_irqrestore(>hysdn_lock, flags);

/* delete old entrys */
-   if (!i)
-   while (pd->log_head->next) {
-   if ((pd->log_head->usage_cnt <= 0) &&
-   (pd->log_head->next->usage_cnt <= 0)) {
-   ib = pd->log_head;
-   pd->log_head = pd->log_head->next;
-   kfree(ib);
-   } else
-   break;
-   }   /* pd->log_head->next */
-   pd->del_lock--;  /* release lock level */
+   while (pd->log_head->next) {
+   if ((pd->log_head->usage_cnt <= 0) &&
+   (pd->log_head->next->usage_cnt <= 0)) {
+   ib = pd->log_head;
+   pd->log_head = pd->log_head->next;
+   kfree(ib);
+   } else
+   break;
+   }   /* pd->log_head->next */
+
+   spin_unlock_irqrestore(>hysdn_lock, flags);
+
wake_up_interruptible(&(pd->rd_queue));  /* announce new entry 
*/
 }  /* put_log_buffer */

--
2.11.0

[PATCH] hysdn: fix to a race condition in put_log_buffer

[Anton Volkov]

The synchronization type that was used earlier to guard the loop that
deletes unused log buffers may have lead to a situation that prevents 
any thread from going through the loop.


The patch deletes previously used synchronization mechanism and moves
the loop under the spin_lock so the similar cases won't be feasible in
the future.

Found by by Linux Driver Verification project (linuxtesting.org).

Signed-off-by: Anton Volkov 
---
 drivers/isdn/hysdn/hysdn_proclog.c | 27 ---
 1 file changed, 12 insertions(+), 15 deletions(-)

diff --git a/drivers/isdn/hysdn/hysdn_proclog.c 
b/drivers/isdn/hysdn/hysdn_proclog.c

index 7b5fd8fb1761..b152c6ca444b 100644
--- a/drivers/isdn/hysdn/hysdn_proclog.c
+++ b/drivers/isdn/hysdn/hysdn_proclog.c
@@ -44,7 +44,6 @@ struct procdata {
char log_name[15];  /* log filename */
struct log_data *log_head, *log_tail;   /* head and tail for queue */
int if_used;/* open count for interface */
-   int volatile del_lock;  /* lock for delete operations */
unsigned char logtmp[LOG_MAX_LINELEN];
wait_queue_head_t rd_queue;
 };
@@ -102,7 +101,6 @@ put_log_buffer(hysdn_card *card, char *cp)
 {
struct log_data *ib;
struct procdata *pd = card->proclog;
-   int i;
unsigned long flags;

if (!pd)
@@ -126,21 +124,20 @@ put_log_buffer(hysdn_card *card, char *cp)
else
pd->log_tail->next = ib;  /* follows existing messages */
pd->log_tail = ib;   /* new tail */
-   i = pd->del_lock++;  /* get lock state */
-   spin_unlock_irqrestore(>hysdn_lock, flags);

/* delete old entrys */
-   if (!i)
-   while (pd->log_head->next) {
-   if ((pd->log_head->usage_cnt <= 0) &&
-   (pd->log_head->next->usage_cnt <= 0)) {
-   ib = pd->log_head;
-   pd->log_head = pd->log_head->next;
-   kfree(ib);
-   } else
-   break;
-   }   /* pd->log_head->next */
-   pd->del_lock--;  /* release lock level */
+   while (pd->log_head->next) {
+   if ((pd->log_head->usage_cnt <= 0) &&
+   (pd->log_head->next->usage_cnt <= 0)) {
+   ib = pd->log_head;
+   pd->log_head = pd->log_head->next;
+   kfree(ib);
+   } else
+   break;
+   }   /* pd->log_head->next */
+
+   spin_unlock_irqrestore(>hysdn_lock, flags);
+
wake_up_interruptible(&(pd->rd_queue));  /* announce new entry 
*/
 }  /* put_log_buffer */

--
2.11.0

Re: mwifiex: usb: fix spelling mistake: "aggreataon"-> "aggregation"

[Kalle Valo]

Colin Ian King  wrote:

> From: Colin Ian King 
> 
> Trivial fix to spelling mistake in aggr_ctrl module parameter
> message text.
> 
> Signed-off-by: Colin Ian King 

Patch applied to wireless-drivers-next.git, thanks.

c55971726c40 mwifiex: usb: fix spelling mistake: "aggreataon"-> "aggregation"

-- 
https://patchwork.kernel.org/patch/9860753/

https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches

Re: mwifiex: usb: fix spelling mistake: "aggreataon"-> "aggregation"

[Kalle Valo]

Colin Ian King  wrote:

> From: Colin Ian King 
> 
> Trivial fix to spelling mistake in aggr_ctrl module parameter
> message text.
> 
> Signed-off-by: Colin Ian King 

Patch applied to wireless-drivers-next.git, thanks.

c55971726c40 mwifiex: usb: fix spelling mistake: "aggreataon"-> "aggregation"

-- 
https://patchwork.kernel.org/patch/9860753/

https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches

Re: [PATCH 0/3] net-next: stmmac: support future possible different internal phy mode

[Andrew Lunn]

> It is too late when we know the PHY ID.
> We need to set a syscon for choosing external/internal PHY.
> So we can rely only on DT.

The point is, its not a property of the PHY. It is a syscon or a MAC
property. Having it as a MAC property would be more generic.

   Andrew

Re: [PATCH 0/3] net-next: stmmac: support future possible different internal phy mode

[Andrew Lunn]

> It is too late when we know the PHY ID.
> We need to set a syscon for choosing external/internal PHY.
> So we can rely only on DT.

The point is, its not a property of the PHY. It is a syscon or a MAC
property. Having it as a MAC property would be more generic.

   Andrew

Re: Suspend-resume failure on Intel Eagle Lake Core2Duo

[Thomas Gleixner]

On Fri, 28 Jul 2017, Tomi Sarvela wrote:
> On 28/07/17 17:13, Thomas Gleixner wrote:
> > On Fri, 28 Jul 2017, Tomi Sarvela wrote:
> > > On 28/07/17 16:15, Thomas Gleixner wrote:
> > > > Another question. Is the machine completely dead or not?
> > > 
> > > Completely dead. Powerled is on, so host isn't shut down.
> > 
> > So that means it does not even power the machine down. That's what I
> > expected least.
> > 
> > > Serial or network if don't give any signs of life.
> > 
> > > Patch applies cleanly but still getting the same error:
> > 
> > Sorry for the noise. I'm an idiot trying to do 10 things at once. This time
> > it actually compiles and links.
> > 
> > If the machine does still not powerdown with this applied, then please redo
> > the 'platform' test and grab the trace for that one.
> 
> This patch fixes the issue. Below is the dmesg from the testrun (sorry for the
> spam, we're primarily testing i915 issues).

Can you please retrieve the trace data from:

/sys/kernel/debug/tracing/trace

and provide that. The dmesg does not help much.

Thanks,

tglx

Re: Suspend-resume failure on Intel Eagle Lake Core2Duo

[Thomas Gleixner]

On Fri, 28 Jul 2017, Tomi Sarvela wrote:
> On 28/07/17 17:13, Thomas Gleixner wrote:
> > On Fri, 28 Jul 2017, Tomi Sarvela wrote:
> > > On 28/07/17 16:15, Thomas Gleixner wrote:
> > > > Another question. Is the machine completely dead or not?
> > > 
> > > Completely dead. Powerled is on, so host isn't shut down.
> > 
> > So that means it does not even power the machine down. That's what I
> > expected least.
> > 
> > > Serial or network if don't give any signs of life.
> > 
> > > Patch applies cleanly but still getting the same error:
> > 
> > Sorry for the noise. I'm an idiot trying to do 10 things at once. This time
> > it actually compiles and links.
> > 
> > If the machine does still not powerdown with this applied, then please redo
> > the 'platform' test and grab the trace for that one.
> 
> This patch fixes the issue. Below is the dmesg from the testrun (sorry for the
> spam, we're primarily testing i915 issues).

Can you please retrieve the trace data from:

/sys/kernel/debug/tracing/trace

and provide that. The dmesg does not help much.

Thanks,

tglx

Re: [PATCH] staging: pi433: use div_u64 for 64-bit division

[Marcus Wolf]

Hi Dan,

Thanks for the hint.

I don't get, what went wrong. If I take the mail from my outbox and view it, it
looks nice.

Seems, I really need to look for another mailtool. But for several reasons,
that's not possible at the moment (slow move of 20 domains with someting arround
80 mail adresses and several mailboxes from one provider to another within the
next two monthes).

Sorry for any inconvenience,

Marcus

> Dan Carpenter  hat am 28. Juli 2017 um 16:26
> geschrieben:
>
>
> On Fri, Jul 28, 2017 at 04:21:05PM +0200, Marcus Wolf wrote:
> > Hi Arnd,
> >
> > we already have a patch for this:
> > [PATCH 1/1] staging: pi433: fix problem with division in rf69_set_deviation
> > from 20.07.2017
>
>
> https://patchwork.kernel.org/patch/9855261/
>
> >
> > Maybe I did something wrong, but my first solution was exactly like your
> > proposal. As far as I remeber, I wasn't able to compile it that way.
> > Therefore I
> > made a little bit more complicated fix. If I did something wrong and yours
> > is
> > fine, we should go for yours, because it is a shorter solution.
> >
>
> Your patch doesn't apply for one thing :( Read
> Documentation/process/email-clients.rst It probably would have been Ok
> otherwise.
>
> I'm pretty sure that Arnd's patch is going to be fine.
>
> regards,
> dan carpenter
>
>

Re: [v2] mwifiex: uninit wakeup info in the error handling

[Kalle Valo]

Jeffy Chen  wrote:

> We inited wakeup info at the beginning of mwifiex_add_card, so we need
> to uninit it in the error handling.
> 
> It's much the same as what we did in:
> 36908c4 mwifiex: uninit wakeup info when removing device
> 
> Signed-off-by: Jeffy Chen 
> Reviewed-by: Brian Norris 

Patch applied to wireless-drivers-next.git, thanks.

f101d9649c42 mwifiex: uninit wakeup info in the error handling

-- 
https://patchwork.kernel.org/patch/9827589/

https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches

Re: [PATCH] staging: pi433: use div_u64 for 64-bit division

[Marcus Wolf]

Hi Dan,

Thanks for the hint.

I don't get, what went wrong. If I take the mail from my outbox and view it, it
looks nice.

Seems, I really need to look for another mailtool. But for several reasons,
that's not possible at the moment (slow move of 20 domains with someting arround
80 mail adresses and several mailboxes from one provider to another within the
next two monthes).

Sorry for any inconvenience,

Marcus

> Dan Carpenter  hat am 28. Juli 2017 um 16:26
> geschrieben:
>
>
> On Fri, Jul 28, 2017 at 04:21:05PM +0200, Marcus Wolf wrote:
> > Hi Arnd,
> >
> > we already have a patch for this:
> > [PATCH 1/1] staging: pi433: fix problem with division in rf69_set_deviation
> > from 20.07.2017
>
>
> https://patchwork.kernel.org/patch/9855261/
>
> >
> > Maybe I did something wrong, but my first solution was exactly like your
> > proposal. As far as I remeber, I wasn't able to compile it that way.
> > Therefore I
> > made a little bit more complicated fix. If I did something wrong and yours
> > is
> > fine, we should go for yours, because it is a shorter solution.
> >
>
> Your patch doesn't apply for one thing :( Read
> Documentation/process/email-clients.rst It probably would have been Ok
> otherwise.
>
> I'm pretty sure that Arnd's patch is going to be fine.
>
> regards,
> dan carpenter
>
>

Re: [v2] mwifiex: uninit wakeup info in the error handling

[Kalle Valo]

Jeffy Chen  wrote:

> We inited wakeup info at the beginning of mwifiex_add_card, so we need
> to uninit it in the error handling.
> 
> It's much the same as what we did in:
> 36908c4 mwifiex: uninit wakeup info when removing device
> 
> Signed-off-by: Jeffy Chen 
> Reviewed-by: Brian Norris 

Patch applied to wireless-drivers-next.git, thanks.

f101d9649c42 mwifiex: uninit wakeup info in the error handling

-- 
https://patchwork.kernel.org/patch/9827589/

https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches

Re: [v2,01/20] mwifiex: reunite copy-and-pasted remove/reset code

[Kalle Valo]

Brian Norris  wrote:

> When PCIe FLR code was added, it explicitly copy-and-pasted much of
> mwifiex_remove_card() into mwifiex_shutdown_sw(). This is unnecessary,
> as almost all of the code should be reused.
> 
> Let's reunite what we can for now.
> 
> The only functional changes for now:
> 
>  * call netif_device_detach() in the remove() code path -- this wasn't
>done before, but it really should be a no-op, when the device is
>getting totally unregistered soon anyway
> 
>  * call the ->down_dev() driver callback only after we've finished all
>SW teardown -- this should have no significant effect, since the only
>user (pcie.c) does very minimal work there, and it doesn't matter
>that we reorder this
> 
> Signed-off-by: Brian Norris 

20 patches applied to wireless-drivers-next.git, thanks.

b6658b66d8a6 mwifiex: reunite copy-and-pasted remove/reset code
4b1f5a0d2eeb mwifiex: reset interrupt status across device reset
7dc4a6b5ca94 mwifiex: pcie: don't allow cmd buffer reuse after reset
643acea6297f mwifiex: re-register wiphy across reset
ce32d1d83702 mwifiex: unregister wiphy before freeing resources
6417dba33538 mwifiex: don't short-circuit netdev notifiers on interface deletion
c253a62da9b4 mwifiex: fixup init_channel_scan_gap error case
9557d9f2e62b mwifiex: ensure "disable auto DS" struct is initialized
5e6588b9d4ab mwifiex: fix misnomers in mwifiex_free_lock_list()
f7d7e4b689ca mwifiex: make mwifiex_free_cmd_buffer() return void
fe8d730adaee mwifiex: utilize netif_tx_{wake,stop}_all_queues()
8395fd9b194c mwifiex: don't open-code ARRAY_SIZE()
463df4719084 mwifiex: drop 'add_tail' param from 
mwifiex_insert_cmd_to_pending_q()
605db27f7405 mwifiex: pcie: remove unnecessary masks
87a602126aaf mwifiex: pcie: unify MSI-X / non-MSI-X interrupt process
37680819c6e1 mwifiex: debugfs: allow card_reset() to cancel things
2f47150ab3ef mwifiex: pcie: disable device DMA before unmapping/freeing buffers
43a0c9aea64d mwifiex: pcie: remove unnecessary 'pdev' check
2d98cfd17e92 mwifiex: keep mwifiex_cancel_pending_ioctl() static
0bc03cfd8247 mwifiex: drop num CPU notice

-- 
https://patchwork.kernel.org/patch/9860943/

https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches

Re: [v2,01/20] mwifiex: reunite copy-and-pasted remove/reset code

[Kalle Valo]

Brian Norris  wrote:

> When PCIe FLR code was added, it explicitly copy-and-pasted much of
> mwifiex_remove_card() into mwifiex_shutdown_sw(). This is unnecessary,
> as almost all of the code should be reused.
> 
> Let's reunite what we can for now.
> 
> The only functional changes for now:
> 
>  * call netif_device_detach() in the remove() code path -- this wasn't
>done before, but it really should be a no-op, when the device is
>getting totally unregistered soon anyway
> 
>  * call the ->down_dev() driver callback only after we've finished all
>SW teardown -- this should have no significant effect, since the only
>user (pcie.c) does very minimal work there, and it doesn't matter
>that we reorder this
> 
> Signed-off-by: Brian Norris 

20 patches applied to wireless-drivers-next.git, thanks.

b6658b66d8a6 mwifiex: reunite copy-and-pasted remove/reset code
4b1f5a0d2eeb mwifiex: reset interrupt status across device reset
7dc4a6b5ca94 mwifiex: pcie: don't allow cmd buffer reuse after reset
643acea6297f mwifiex: re-register wiphy across reset
ce32d1d83702 mwifiex: unregister wiphy before freeing resources
6417dba33538 mwifiex: don't short-circuit netdev notifiers on interface deletion
c253a62da9b4 mwifiex: fixup init_channel_scan_gap error case
9557d9f2e62b mwifiex: ensure "disable auto DS" struct is initialized
5e6588b9d4ab mwifiex: fix misnomers in mwifiex_free_lock_list()
f7d7e4b689ca mwifiex: make mwifiex_free_cmd_buffer() return void
fe8d730adaee mwifiex: utilize netif_tx_{wake,stop}_all_queues()
8395fd9b194c mwifiex: don't open-code ARRAY_SIZE()
463df4719084 mwifiex: drop 'add_tail' param from 
mwifiex_insert_cmd_to_pending_q()
605db27f7405 mwifiex: pcie: remove unnecessary masks
87a602126aaf mwifiex: pcie: unify MSI-X / non-MSI-X interrupt process
37680819c6e1 mwifiex: debugfs: allow card_reset() to cancel things
2f47150ab3ef mwifiex: pcie: disable device DMA before unmapping/freeing buffers
43a0c9aea64d mwifiex: pcie: remove unnecessary 'pdev' check
2d98cfd17e92 mwifiex: keep mwifiex_cancel_pending_ioctl() static
0bc03cfd8247 mwifiex: drop num CPU notice

-- 
https://patchwork.kernel.org/patch/9860943/

https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches

Re: Suspend-resume failure on Intel Eagle Lake Core2Duo

[Tomi Sarvela]

On 28/07/17 17:13, Thomas Gleixner wrote:

On Fri, 28 Jul 2017, Tomi Sarvela wrote:

On 28/07/17 16:15, Thomas Gleixner wrote:

Another question. Is the machine completely dead or not?


Completely dead. Powerled is on, so host isn't shut down.


So that means it does not even power the machine down. That's what I
expected least.


Serial or network if don't give any signs of life.



Patch applies cleanly but still getting the same error:


Sorry for the noise. I'm an idiot trying to do 10 things at once. This time
it actually compiles and links.

If the machine does still not powerdown with this applied, then please redo
the 'platform' test and grab the trace for that one.


This patch fixes the issue. Below is the dmesg from the testrun (sorry 
for the spam, we're primarily testing i915 issues).


Tested-by: Tomi Sarvela 

Tomi


[ 1189.061801] [IGT] gem_exec_suspend: executing
[ 1189.071208] Setting dangerous option reset - tainting kernel
[ 1189.071438] [IGT] gem_exec_suspend: starting subtest basic-S3
[ 1189.239034] PM: Syncing filesystems ... done.
[ 1189.245968] PM: Preparing system for sleep (mem)
[ 1189.246209] Freezing user space processes ... (elapsed 0.001 seconds) 
done.

[ 1189.247530] OOM killer disabled.
[ 1189.247531] Freezing remaining freezable tasks ... (elapsed 0.001 
seconds) done.

[ 1189.248690] PM: Suspending system (mem)
[ 1189.248706] Suspending console(s) (use no_console_suspend to debug)
[ 1189.249177] serial 00:03: disabled
[ 1189.250266] sd 0:0:0:0: [sda] Synchronizing SCSI cache
[ 1189.255064] e1000e: EEE TX LPI TIMER: 
[ 1189.256460] [drm:intel_power_well_enable [i915]] enabling always-on
[ 1189.257541] sd 0:0:0:0: [sda] Stopping disk
[ 1189.560357] PM: suspend of devices complete after 311.444 msecs
[ 1189.560653] [drm:intel_power_well_disable [i915]] disabling always-on
[ 1189.572123] PM: late suspend of devices complete after 11.761 msecs
[ 1189.584066] PM: noirq suspend of devices complete after 11.939 msecs
[ 1189.584580] ACPI: Preparing to enter system sleep state S3
[ 1189.586661] PM: Saving platform NVS memory
[ 1189.586686] Disabling non-boot CPUs ...
[ 1189.596350] IRQ 8: no longer affine to CPU1
[ 1189.596356] IRQ 16: no longer affine to CPU1
[ 1189.596367] IRQ 25: no longer affine to CPU1
[ 1189.596369] IRQ 28: no longer affine to CPU1
[ 1189.597397] smpboot: CPU 1 is now offline
[ 1189.597665] ACPI: Low-level resume complete
[ 1189.597665] PM: Restoring platform NVS memory
[ 1189.597665] Suspended for 14.825 seconds
[ 1189.597665] Delta way too big! 18446743991837909721 
ts=18446744056274518328 write stamp = 64436608607

   If you just came from a suspend/resume,
   please switch to the trace global clock:
 echo global > /sys/kernel/debug/tracing/trace_clock
[ 1189.597665] [ cut here ]
[ 1189.597665] WARNING: CPU: 0 PID: 1332 at 
kernel/trace/ring_buffer.c:2647 rb_handle_timestamp.isra.32+0x71/0x80
[ 1189.597665] Modules linked in: snd_hda_codec_realtek i915 
snd_hda_codec_generic snd_hda_intel snd_hda_codec snd_hwdep snd_hda_core 
coretemp snd_pcm e1000e lpc_ich mei_me ptp mei pps_core
[ 1189.597665] CPU: 0 PID: 1332 Comm: rtcwake Tainted: G U 
4.13.0-rc2+ #5
[ 1189.597665] Hardware name: Hewlett-Packard HP Compaq 8000 Elite CMT 
PC/3647h, BIOS 786G7 v01.13 07/20/2011

[ 1189.597665] task: 88010dce9880 task.stack: c90c8000
[ 1189.597665] RIP: 0010:rb_handle_timestamp.isra.32+0x71/0x80
[ 1189.597665] RSP: 0018:c90cbab0 EFLAGS: 00010082
[ 1189.597665] RAX: 00e0 RBX: c90cbad0 RCX: 
0004
[ 1189.597665] RDX: 8004 RSI: 0082 RDI: 

[ 1189.597665] RBP: c90cbac0 R08:  R09: 
00e0
[ 1189.597665] R10: c90cbbe0 R11: 000ebc08 R12: 
880117008890
[ 1189.597665] R13: 8801170088b0 R14: 03e8 R15: 
0005
[ 1189.597665] FS:  7f93d957e700() GS:88011bc0() 
knlGS:

[ 1189.597665] CS:  0010 DS:  ES:  CR0: 80050033
[ 1189.597665] CR2: 00f00255b068 CR3: d9063000 CR4: 
000406f0

[ 1189.597665] Call Trace:
[ 1189.597665]  ring_buffer_lock_reserve+0x1fa/0x350
[ 1189.597665]  trace_vbprintk+0xdc/0x260
[ 1189.597665]  ? __irq_disable+0x1b/0xc0
[ 1189.597665]  __trace_bprintk+0x4a/0x60
[ 1189.597665]  ? preempt_count_add+0x9e/0xb0
[ 1189.597665]  __irq_disable+0x3f/0xc0
[ 1189.597665]  irq_disable+0x17/0x20
[ 1189.597665]  __disable_irq_nosync+0x59/0x70
[ 1189.597665]  disable_hardirq+0x11/0x30
[ 1189.597665]  hpet_msi_resume+0x85/0xd0
[ 1189.597665]  clockevents_tick_resume+0x14/0x20
[ 1189.597665]  tick_resume_local+0x32/0x60
[ 1189.597665]  tick_resume+0x13/0x20
[ 1189.597665]  timekeeping_resume+0x149/0x1a0
[ 1189.597665]  syscore_resume+0x4b/0x190
[ 1189.597665]  ? syscore_resume+0x4b/0x190
[ 1189.597665]  

Re: Suspend-resume failure on Intel Eagle Lake Core2Duo

[Tomi Sarvela]

On 28/07/17 17:13, Thomas Gleixner wrote:

On Fri, 28 Jul 2017, Tomi Sarvela wrote:

On 28/07/17 16:15, Thomas Gleixner wrote:

Another question. Is the machine completely dead or not?


Completely dead. Powerled is on, so host isn't shut down.


So that means it does not even power the machine down. That's what I
expected least.


Serial or network if don't give any signs of life.



Patch applies cleanly but still getting the same error:


Sorry for the noise. I'm an idiot trying to do 10 things at once. This time
it actually compiles and links.

If the machine does still not powerdown with this applied, then please redo
the 'platform' test and grab the trace for that one.


This patch fixes the issue. Below is the dmesg from the testrun (sorry 
for the spam, we're primarily testing i915 issues).


Tested-by: Tomi Sarvela 

Tomi


[ 1189.061801] [IGT] gem_exec_suspend: executing
[ 1189.071208] Setting dangerous option reset - tainting kernel
[ 1189.071438] [IGT] gem_exec_suspend: starting subtest basic-S3
[ 1189.239034] PM: Syncing filesystems ... done.
[ 1189.245968] PM: Preparing system for sleep (mem)
[ 1189.246209] Freezing user space processes ... (elapsed 0.001 seconds) 
done.

[ 1189.247530] OOM killer disabled.
[ 1189.247531] Freezing remaining freezable tasks ... (elapsed 0.001 
seconds) done.

[ 1189.248690] PM: Suspending system (mem)
[ 1189.248706] Suspending console(s) (use no_console_suspend to debug)
[ 1189.249177] serial 00:03: disabled
[ 1189.250266] sd 0:0:0:0: [sda] Synchronizing SCSI cache
[ 1189.255064] e1000e: EEE TX LPI TIMER: 
[ 1189.256460] [drm:intel_power_well_enable [i915]] enabling always-on
[ 1189.257541] sd 0:0:0:0: [sda] Stopping disk
[ 1189.560357] PM: suspend of devices complete after 311.444 msecs
[ 1189.560653] [drm:intel_power_well_disable [i915]] disabling always-on
[ 1189.572123] PM: late suspend of devices complete after 11.761 msecs
[ 1189.584066] PM: noirq suspend of devices complete after 11.939 msecs
[ 1189.584580] ACPI: Preparing to enter system sleep state S3
[ 1189.586661] PM: Saving platform NVS memory
[ 1189.586686] Disabling non-boot CPUs ...
[ 1189.596350] IRQ 8: no longer affine to CPU1
[ 1189.596356] IRQ 16: no longer affine to CPU1
[ 1189.596367] IRQ 25: no longer affine to CPU1
[ 1189.596369] IRQ 28: no longer affine to CPU1
[ 1189.597397] smpboot: CPU 1 is now offline
[ 1189.597665] ACPI: Low-level resume complete
[ 1189.597665] PM: Restoring platform NVS memory
[ 1189.597665] Suspended for 14.825 seconds
[ 1189.597665] Delta way too big! 18446743991837909721 
ts=18446744056274518328 write stamp = 64436608607

   If you just came from a suspend/resume,
   please switch to the trace global clock:
 echo global > /sys/kernel/debug/tracing/trace_clock
[ 1189.597665] [ cut here ]
[ 1189.597665] WARNING: CPU: 0 PID: 1332 at 
kernel/trace/ring_buffer.c:2647 rb_handle_timestamp.isra.32+0x71/0x80
[ 1189.597665] Modules linked in: snd_hda_codec_realtek i915 
snd_hda_codec_generic snd_hda_intel snd_hda_codec snd_hwdep snd_hda_core 
coretemp snd_pcm e1000e lpc_ich mei_me ptp mei pps_core
[ 1189.597665] CPU: 0 PID: 1332 Comm: rtcwake Tainted: G U 
4.13.0-rc2+ #5
[ 1189.597665] Hardware name: Hewlett-Packard HP Compaq 8000 Elite CMT 
PC/3647h, BIOS 786G7 v01.13 07/20/2011

[ 1189.597665] task: 88010dce9880 task.stack: c90c8000
[ 1189.597665] RIP: 0010:rb_handle_timestamp.isra.32+0x71/0x80
[ 1189.597665] RSP: 0018:c90cbab0 EFLAGS: 00010082
[ 1189.597665] RAX: 00e0 RBX: c90cbad0 RCX: 
0004
[ 1189.597665] RDX: 8004 RSI: 0082 RDI: 

[ 1189.597665] RBP: c90cbac0 R08:  R09: 
00e0
[ 1189.597665] R10: c90cbbe0 R11: 000ebc08 R12: 
880117008890
[ 1189.597665] R13: 8801170088b0 R14: 03e8 R15: 
0005
[ 1189.597665] FS:  7f93d957e700() GS:88011bc0() 
knlGS:

[ 1189.597665] CS:  0010 DS:  ES:  CR0: 80050033
[ 1189.597665] CR2: 00f00255b068 CR3: d9063000 CR4: 
000406f0

[ 1189.597665] Call Trace:
[ 1189.597665]  ring_buffer_lock_reserve+0x1fa/0x350
[ 1189.597665]  trace_vbprintk+0xdc/0x260
[ 1189.597665]  ? __irq_disable+0x1b/0xc0
[ 1189.597665]  __trace_bprintk+0x4a/0x60
[ 1189.597665]  ? preempt_count_add+0x9e/0xb0
[ 1189.597665]  __irq_disable+0x3f/0xc0
[ 1189.597665]  irq_disable+0x17/0x20
[ 1189.597665]  __disable_irq_nosync+0x59/0x70
[ 1189.597665]  disable_hardirq+0x11/0x30
[ 1189.597665]  hpet_msi_resume+0x85/0xd0
[ 1189.597665]  clockevents_tick_resume+0x14/0x20
[ 1189.597665]  tick_resume_local+0x32/0x60
[ 1189.597665]  tick_resume+0x13/0x20
[ 1189.597665]  timekeeping_resume+0x149/0x1a0
[ 1189.597665]  syscore_resume+0x4b/0x190
[ 1189.597665]  ? syscore_resume+0x4b/0x190
[ 1189.597665]  suspend_devices_and_enter+0x6b9/0x810
[ 1189.597665]  

[GIT PULL] xen: fixes for 4.13-rc3

[Juergen Gross]

Linus,

Please git pull the following tag:

 git://git.kernel.org/pub/scm/linux/kernel/git/xen/tip.git 
for-linus-4.13b-rc3-tag

xen: fixes for 4.13-rc3

It contains three minor cleanups for xen related drivers.

Thanks.

Juergen

 drivers/xen/events/events_base.c | 13 +++--
 drivers/xen/xen-selfballoon.c|  4 ++--
 drivers/xen/xenfs/super.c|  1 -
 3 files changed, 5 insertions(+), 13 deletions(-)

Gustavo A. R. Silva (1):
  xen: selfballoon: remove unnecessary static in frontswap_selfshrink()

Juergen Gross (1):
  xen: dont fiddle with event channel masking in suspend/resume

Punit Agrawal (1):
  xen: Drop un-informative message during boot

[GIT PULL] xen: fixes for 4.13-rc3

[Juergen Gross]

Linus,

Please git pull the following tag:

 git://git.kernel.org/pub/scm/linux/kernel/git/xen/tip.git 
for-linus-4.13b-rc3-tag

xen: fixes for 4.13-rc3

It contains three minor cleanups for xen related drivers.

Thanks.

Juergen

 drivers/xen/events/events_base.c | 13 +++--
 drivers/xen/xen-selfballoon.c|  4 ++--
 drivers/xen/xenfs/super.c|  1 -
 3 files changed, 5 insertions(+), 13 deletions(-)

Gustavo A. R. Silva (1):
  xen: selfballoon: remove unnecessary static in frontswap_selfshrink()

Juergen Gross (1):
  xen: dont fiddle with event channel masking in suspend/resume

Punit Agrawal (1):
  xen: Drop un-informative message during boot

Re: [PATCH 08/14] ipmi: use atomic_dec_not_zero()

[Corey Minyard]

On 07/28/2017 09:27 AM, Corey Minyard wrote:
I missed this until now, and I see it hasn't been applied yet.  It's 
queued for the next release.




Well, never mind, I see the main update didn't go in.

-corey


Thanks,

-corey

On 01/30/2017 12:47 PM, Fabian Frederick wrote:

instead of atomic_add_unless(value, -1, 0)

Signed-off-by: Fabian Frederick 
---
  drivers/char/ipmi/ipmi_msghandler.c | 2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/char/ipmi/ipmi_msghandler.c 
b/drivers/char/ipmi/ipmi_msghandler.c

index 9f69995..961d677 100644
--- a/drivers/char/ipmi/ipmi_msghandler.c
+++ b/drivers/char/ipmi/ipmi_msghandler.c
@@ -3851,7 +3851,7 @@ static void handle_new_recv_msgs(ipmi_smi_t intf)
   * If the pretimout count is non-zero, decrement one from it and
   * deliver pretimeouts to all the users.
   */
-if (atomic_add_unless(>watchdog_pretimeouts_to_deliver, 
-1, 0)) {

+if (atomic_dec_not_zero(>watchdog_pretimeouts_to_deliver)) {
  ipmi_user_t user;
rcu_read_lock();

Re: [PATCH 08/14] ipmi: use atomic_dec_not_zero()

[Corey Minyard]

On 07/28/2017 09:27 AM, Corey Minyard wrote:
I missed this until now, and I see it hasn't been applied yet.  It's 
queued for the next release.




Well, never mind, I see the main update didn't go in.

-corey


Thanks,

-corey

On 01/30/2017 12:47 PM, Fabian Frederick wrote:

instead of atomic_add_unless(value, -1, 0)

Signed-off-by: Fabian Frederick 
---
  drivers/char/ipmi/ipmi_msghandler.c | 2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/char/ipmi/ipmi_msghandler.c 
b/drivers/char/ipmi/ipmi_msghandler.c

index 9f69995..961d677 100644
--- a/drivers/char/ipmi/ipmi_msghandler.c
+++ b/drivers/char/ipmi/ipmi_msghandler.c
@@ -3851,7 +3851,7 @@ static void handle_new_recv_msgs(ipmi_smi_t intf)
   * If the pretimout count is non-zero, decrement one from it and
   * deliver pretimeouts to all the users.
   */
-if (atomic_add_unless(>watchdog_pretimeouts_to_deliver, 
-1, 0)) {

+if (atomic_dec_not_zero(>watchdog_pretimeouts_to_deliver)) {
  ipmi_user_t user;
rcu_read_lock();

Re: [PATCH v1 4/6] ASoC: codecs: msm8916-wcd-analog: set default micbias voltage to 1.8

[Srinivas Kandagatla]

On 28/07/17 15:01, Mark Brown wrote:

On Fri, Jul 28, 2017 at 02:54:59PM +0100, Srinivas Kandagatla wrote:

On 28/07/17 14:40, Mark Brown wrote:

On Wed, Jul 26, 2017 at 02:35:10AM +0200, srinivas.kandaga...@linaro.org wrote:

From: Srinivas Kandagatla 



This patch sets the default internal micbias voltage to 1.8v. This
default value is required for mbhc buttons to work. Also adds dt
bindings to allow the board level file to specify the required default
micbias value.



What was the default previously?



This was set to 2.7v previously for special headsets which have high
impedance.


So obviously this will break existing users.  That's not OK.


This would not break any exiting users, as this part is applicable for 
only headset detect usecase. I will try to address this in ("PATCH 5/6 
ASoC: codecs: msm8916-wcd-analog: add MBHC support") patch.


The default voltage for most common usecase should be set to 1.8v anyway.

Re: [PATCH v1 4/6] ASoC: codecs: msm8916-wcd-analog: set default micbias voltage to 1.8

[Srinivas Kandagatla]

On 28/07/17 15:01, Mark Brown wrote:

On Fri, Jul 28, 2017 at 02:54:59PM +0100, Srinivas Kandagatla wrote:

On 28/07/17 14:40, Mark Brown wrote:

On Wed, Jul 26, 2017 at 02:35:10AM +0200, srinivas.kandaga...@linaro.org wrote:

From: Srinivas Kandagatla 



This patch sets the default internal micbias voltage to 1.8v. This
default value is required for mbhc buttons to work. Also adds dt
bindings to allow the board level file to specify the required default
micbias value.



What was the default previously?



This was set to 2.7v previously for special headsets which have high
impedance.


So obviously this will break existing users.  That's not OK.


This would not break any exiting users, as this part is applicable for 
only headset detect usecase. I will try to address this in ("PATCH 5/6 
ASoC: codecs: msm8916-wcd-analog: add MBHC support") patch.


The default voltage for most common usecase should be set to 1.8v anyway.

Re: [PATCH 0/3] net-next: stmmac: support future possible different internal phy mode

[Corentin Labbe]

On Fri, Jul 28, 2017 at 04:36:00PM +0200, Andrew Lunn wrote:
> > > I've probably asked this before: Does the internal PHY use a different
> > > PHY ID in registers 2 and 3?
> > > 
> > 
> > yes
> > 
> > reg2: 0x0044
> > reg3: 0X1500

Copy/paste error, its 1400

> 
> So this is not about loading the correct PHY driver. You can already
> do this based on the PHY IDs...
> 
> This is about selecting which PHY to use. Internal or External?   
> 
>  Andrew

It is too late when we know the PHY ID.
We need to set a syscon for choosing external/internal PHY.
So we can rely only on DT.

Re: [PATCH 0/3] net-next: stmmac: support future possible different internal phy mode

[Corentin Labbe]

On Fri, Jul 28, 2017 at 04:36:00PM +0200, Andrew Lunn wrote:
> > > I've probably asked this before: Does the internal PHY use a different
> > > PHY ID in registers 2 and 3?
> > > 
> > 
> > yes
> > 
> > reg2: 0x0044
> > reg3: 0X1500

Copy/paste error, its 1400

> 
> So this is not about loading the correct PHY driver. You can already
> do this based on the PHY IDs...
> 
> This is about selecting which PHY to use. Internal or External?   
> 
>  Andrew

It is too late when we know the PHY ID.
We need to set a syscon for choosing external/internal PHY.
So we can rely only on DT.

[PATCH net] tcp: avoid bogus gcc-7 array-bounds warning

[Arnd Bergmann]

When using CONFIG_UBSAN_SANITIZE_ALL, the TCP code produces a
false-positive warning:

net/ipv4/tcp_output.c: In function 'tcp_connect':
net/ipv4/tcp_output.c:2207:40: error: array subscript is below array bounds 
[-Werror=array-bounds]
   tp->chrono_stat[tp->chrono_type - 1] += now - tp->chrono_start;
^~
net/ipv4/tcp_output.c:2207:40: error: array subscript is below array bounds 
[-Werror=array-bounds]
   tp->chrono_stat[tp->chrono_type - 1] += now - tp->chrono_start;
   ~^

I have opened a gcc bug for this, but distros have already shipped
compilers with this problem, and it's not clear yet whether there is
a way for gcc to avoid the warning. As the problem is related to the
bitfield access, this introduces a temporary variable to store the old
enum value.

I did not notice this warning earlier, since UBSAN is disabled when
building with COMPILE_TEST, and that was always turned on in both
allmodconfig and randconfig tests.

Link: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81601
Signed-off-by: Arnd Bergmann 
---
 net/ipv4/tcp_output.c | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/net/ipv4/tcp_output.c b/net/ipv4/tcp_output.c
index 886d874775df..bb901297a369 100644
--- a/net/ipv4/tcp_output.c
+++ b/net/ipv4/tcp_output.c
@@ -2202,9 +2202,10 @@ static bool tcp_small_queue_check(struct sock *sk, const 
struct sk_buff *skb,
 static void tcp_chrono_set(struct tcp_sock *tp, const enum tcp_chrono new)
 {
const u32 now = tcp_jiffies32;
+   enum tcp_chrono old = tp->chrono_type;
 
-   if (tp->chrono_type > TCP_CHRONO_UNSPEC)
-   tp->chrono_stat[tp->chrono_type - 1] += now - tp->chrono_start;
+   if (old > TCP_CHRONO_UNSPEC)
+   tp->chrono_stat[old - 1] += now - tp->chrono_start;
tp->chrono_start = now;
tp->chrono_type = new;
 }
-- 
2.9.0

[PATCH net] tcp: avoid bogus gcc-7 array-bounds warning

[Arnd Bergmann]

When using CONFIG_UBSAN_SANITIZE_ALL, the TCP code produces a
false-positive warning:

net/ipv4/tcp_output.c: In function 'tcp_connect':
net/ipv4/tcp_output.c:2207:40: error: array subscript is below array bounds 
[-Werror=array-bounds]
   tp->chrono_stat[tp->chrono_type - 1] += now - tp->chrono_start;
^~
net/ipv4/tcp_output.c:2207:40: error: array subscript is below array bounds 
[-Werror=array-bounds]
   tp->chrono_stat[tp->chrono_type - 1] += now - tp->chrono_start;
   ~^

I have opened a gcc bug for this, but distros have already shipped
compilers with this problem, and it's not clear yet whether there is
a way for gcc to avoid the warning. As the problem is related to the
bitfield access, this introduces a temporary variable to store the old
enum value.

I did not notice this warning earlier, since UBSAN is disabled when
building with COMPILE_TEST, and that was always turned on in both
allmodconfig and randconfig tests.

Link: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81601
Signed-off-by: Arnd Bergmann 
---
 net/ipv4/tcp_output.c | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/net/ipv4/tcp_output.c b/net/ipv4/tcp_output.c
index 886d874775df..bb901297a369 100644
--- a/net/ipv4/tcp_output.c
+++ b/net/ipv4/tcp_output.c
@@ -2202,9 +2202,10 @@ static bool tcp_small_queue_check(struct sock *sk, const 
struct sk_buff *skb,
 static void tcp_chrono_set(struct tcp_sock *tp, const enum tcp_chrono new)
 {
const u32 now = tcp_jiffies32;
+   enum tcp_chrono old = tp->chrono_type;
 
-   if (tp->chrono_type > TCP_CHRONO_UNSPEC)
-   tp->chrono_stat[tp->chrono_type - 1] += now - tp->chrono_start;
+   if (old > TCP_CHRONO_UNSPEC)
+   tp->chrono_stat[old - 1] += now - tp->chrono_start;
tp->chrono_start = now;
tp->chrono_type = new;
 }
-- 
2.9.0

Re: [PATCH 0/2] arm64: dts: cleanup Broadcom boards per SoC

[Scott Branden]

Hi Florian,

Could you please pick up PATCH 1/2 of this series below and drop PATCH 2/2 ?


On 17-07-19 10:05 AM, Scott Branden wrote:

Separate Broadcom boards per SoC to assist in cleaner management of boards.
This has already been done for Stingray and is done here for RPI and NS2.

If this is problematic for RPI please let me know and RPI patch can be
dropped from patch series.

Scott Branden (2):
   arm64: dts: move ns2 into northstar2 directory
   arm64: dts: move rpi into rpi directory

  arch/arm64/boot/dts/broadcom/Makefile| 7 +++
  arch/arm64/boot/dts/broadcom/bcm2835-rpi.dtsi| 1 -
  arch/arm64/boot/dts/broadcom/bcm283x-rpi-smsc9514.dtsi   | 1 -
  arch/arm64/boot/dts/broadcom/bcm283x-rpi-usb-host.dtsi   | 1 -
  arch/arm64/boot/dts/broadcom/bcm283x.dtsi| 1 -
  arch/arm64/boot/dts/broadcom/northstar2/Makefile | 6 ++
  arch/arm64/boot/dts/broadcom/{ => northstar2}/ns2-clock.dtsi | 0
  arch/arm64/boot/dts/broadcom/{ => northstar2}/ns2-svk.dts| 0
  arch/arm64/boot/dts/broadcom/{ => northstar2}/ns2-xmc.dts| 0
  arch/arm64/boot/dts/broadcom/{ => northstar2}/ns2.dtsi   | 0
  arch/arm64/boot/dts/broadcom/rpi/Makefile| 5 +
  arch/arm64/boot/dts/broadcom/rpi/bcm2835-rpi.dtsi| 1 +
  arch/arm64/boot/dts/broadcom/{ => rpi}/bcm2837-rpi-3-b.dts   | 0
  arch/arm64/boot/dts/broadcom/{ => rpi}/bcm2837.dtsi  | 0
  arch/arm64/boot/dts/broadcom/rpi/bcm283x-rpi-smsc9514.dtsi   | 1 +
  arch/arm64/boot/dts/broadcom/rpi/bcm283x-rpi-usb-host.dtsi   | 1 +
  arch/arm64/boot/dts/broadcom/rpi/bcm283x.dtsi| 1 +
  17 files changed, 18 insertions(+), 8 deletions(-)
  delete mode 12 arch/arm64/boot/dts/broadcom/bcm2835-rpi.dtsi
  delete mode 12 arch/arm64/boot/dts/broadcom/bcm283x-rpi-smsc9514.dtsi
  delete mode 12 arch/arm64/boot/dts/broadcom/bcm283x-rpi-usb-host.dtsi
  delete mode 12 arch/arm64/boot/dts/broadcom/bcm283x.dtsi
  create mode 100644 arch/arm64/boot/dts/broadcom/northstar2/Makefile
  rename arch/arm64/boot/dts/broadcom/{ => northstar2}/ns2-clock.dtsi (100%)
  rename arch/arm64/boot/dts/broadcom/{ => northstar2}/ns2-svk.dts (100%)
  rename arch/arm64/boot/dts/broadcom/{ => northstar2}/ns2-xmc.dts (100%)
  rename arch/arm64/boot/dts/broadcom/{ => northstar2}/ns2.dtsi (100%)
  create mode 100644 arch/arm64/boot/dts/broadcom/rpi/Makefile
  create mode 12 arch/arm64/boot/dts/broadcom/rpi/bcm2835-rpi.dtsi
  rename arch/arm64/boot/dts/broadcom/{ => rpi}/bcm2837-rpi-3-b.dts (100%)
  rename arch/arm64/boot/dts/broadcom/{ => rpi}/bcm2837.dtsi (100%)
  create mode 12 arch/arm64/boot/dts/broadcom/rpi/bcm283x-rpi-smsc9514.dtsi
  create mode 12 arch/arm64/boot/dts/broadcom/rpi/bcm283x-rpi-usb-host.dtsi
  create mode 12 arch/arm64/boot/dts/broadcom/rpi/bcm283x.dtsi


Thanks,
 Scott

Re: [PATCH 0/2] arm64: dts: cleanup Broadcom boards per SoC

[Scott Branden]

Hi Florian,

Could you please pick up PATCH 1/2 of this series below and drop PATCH 2/2 ?


On 17-07-19 10:05 AM, Scott Branden wrote:

Separate Broadcom boards per SoC to assist in cleaner management of boards.
This has already been done for Stingray and is done here for RPI and NS2.

If this is problematic for RPI please let me know and RPI patch can be
dropped from patch series.

Scott Branden (2):
   arm64: dts: move ns2 into northstar2 directory
   arm64: dts: move rpi into rpi directory

  arch/arm64/boot/dts/broadcom/Makefile| 7 +++
  arch/arm64/boot/dts/broadcom/bcm2835-rpi.dtsi| 1 -
  arch/arm64/boot/dts/broadcom/bcm283x-rpi-smsc9514.dtsi   | 1 -
  arch/arm64/boot/dts/broadcom/bcm283x-rpi-usb-host.dtsi   | 1 -
  arch/arm64/boot/dts/broadcom/bcm283x.dtsi| 1 -
  arch/arm64/boot/dts/broadcom/northstar2/Makefile | 6 ++
  arch/arm64/boot/dts/broadcom/{ => northstar2}/ns2-clock.dtsi | 0
  arch/arm64/boot/dts/broadcom/{ => northstar2}/ns2-svk.dts| 0
  arch/arm64/boot/dts/broadcom/{ => northstar2}/ns2-xmc.dts| 0
  arch/arm64/boot/dts/broadcom/{ => northstar2}/ns2.dtsi   | 0
  arch/arm64/boot/dts/broadcom/rpi/Makefile| 5 +
  arch/arm64/boot/dts/broadcom/rpi/bcm2835-rpi.dtsi| 1 +
  arch/arm64/boot/dts/broadcom/{ => rpi}/bcm2837-rpi-3-b.dts   | 0
  arch/arm64/boot/dts/broadcom/{ => rpi}/bcm2837.dtsi  | 0
  arch/arm64/boot/dts/broadcom/rpi/bcm283x-rpi-smsc9514.dtsi   | 1 +
  arch/arm64/boot/dts/broadcom/rpi/bcm283x-rpi-usb-host.dtsi   | 1 +
  arch/arm64/boot/dts/broadcom/rpi/bcm283x.dtsi| 1 +
  17 files changed, 18 insertions(+), 8 deletions(-)
  delete mode 12 arch/arm64/boot/dts/broadcom/bcm2835-rpi.dtsi
  delete mode 12 arch/arm64/boot/dts/broadcom/bcm283x-rpi-smsc9514.dtsi
  delete mode 12 arch/arm64/boot/dts/broadcom/bcm283x-rpi-usb-host.dtsi
  delete mode 12 arch/arm64/boot/dts/broadcom/bcm283x.dtsi
  create mode 100644 arch/arm64/boot/dts/broadcom/northstar2/Makefile
  rename arch/arm64/boot/dts/broadcom/{ => northstar2}/ns2-clock.dtsi (100%)
  rename arch/arm64/boot/dts/broadcom/{ => northstar2}/ns2-svk.dts (100%)
  rename arch/arm64/boot/dts/broadcom/{ => northstar2}/ns2-xmc.dts (100%)
  rename arch/arm64/boot/dts/broadcom/{ => northstar2}/ns2.dtsi (100%)
  create mode 100644 arch/arm64/boot/dts/broadcom/rpi/Makefile
  create mode 12 arch/arm64/boot/dts/broadcom/rpi/bcm2835-rpi.dtsi
  rename arch/arm64/boot/dts/broadcom/{ => rpi}/bcm2837-rpi-3-b.dts (100%)
  rename arch/arm64/boot/dts/broadcom/{ => rpi}/bcm2837.dtsi (100%)
  create mode 12 arch/arm64/boot/dts/broadcom/rpi/bcm283x-rpi-smsc9514.dtsi
  create mode 12 arch/arm64/boot/dts/broadcom/rpi/bcm283x-rpi-usb-host.dtsi
  create mode 12 arch/arm64/boot/dts/broadcom/rpi/bcm283x.dtsi


Thanks,
 Scott

Re: [PATCH 0/3] net-next: stmmac: support future possible different internal phy mode

[Andrew Lunn]

> > I've probably asked this before: Does the internal PHY use a different
> > PHY ID in registers 2 and 3?
> > 
> 
> yes
> 
> reg2: 0x0044
> reg3: 0X1500

So this is not about loading the correct PHY driver. You can already
do this based on the PHY IDs...

This is about selecting which PHY to use. Internal or External? 

 Andrew

Re: [PATCH 0/3] net-next: stmmac: support future possible different internal phy mode

[Andrew Lunn]

> > I've probably asked this before: Does the internal PHY use a different
> > PHY ID in registers 2 and 3?
> > 
> 
> yes
> 
> reg2: 0x0044
> reg3: 0X1500

So this is not about loading the correct PHY driver. You can already
do this based on the PHY IDs...

This is about selecting which PHY to use. Internal or External? 

 Andrew

Re: [PATCH] HID: wacom: add USB_HID dependency

[Arnd Bergmann]

On Fri, Jul 28, 2017 at 4:24 PM, Jason Gerecke  wrote:
> On Fri, Jul 28, 2017 at 7:18 AM, Arnd Bergmann  wrote:
>> On Fri, Jul 28, 2017 at 4:07 PM, Jason Gerecke  wrote:

>> #ifdef CONFIG_USB_HID
>> extern bool hid_is_using_usb_driver(struct hid_device *hdev)
>> #else
>> static inline bool hid_is_using_usb_driver(struct hid_device *hdev)
>> {
>>return false;
>> }
>> #endif
>>
>> but is it worth it to avoid the dependency?
>>
>>Arnd
>
> I was thinking something more along the lines of the following since
> the idea of per-transport helper functions was dismissed earlier:
>
> #ifdef CONFIG_USB_HID
> if (hid_is_using_ll_driver(wacom->hdev, _hid_driver)) {

I would consider that rather ugly, a driver shouldn't really use
#ifdef like this, but you can hide stuff like this in a header. The method
I proposed also has the advantage of avoiding exporting the
usb_hid_driver object. Drivers shouldn't really need to access this,
and wacom_sys.c is the only remaining user of the export.

  Arnd

Re: [PATCH] HID: wacom: add USB_HID dependency

[Arnd Bergmann]

On Fri, Jul 28, 2017 at 4:24 PM, Jason Gerecke  wrote:
> On Fri, Jul 28, 2017 at 7:18 AM, Arnd Bergmann  wrote:
>> On Fri, Jul 28, 2017 at 4:07 PM, Jason Gerecke  wrote:

>> #ifdef CONFIG_USB_HID
>> extern bool hid_is_using_usb_driver(struct hid_device *hdev)
>> #else
>> static inline bool hid_is_using_usb_driver(struct hid_device *hdev)
>> {
>>return false;
>> }
>> #endif
>>
>> but is it worth it to avoid the dependency?
>>
>>Arnd
>
> I was thinking something more along the lines of the following since
> the idea of per-transport helper functions was dismissed earlier:
>
> #ifdef CONFIG_USB_HID
> if (hid_is_using_ll_driver(wacom->hdev, _hid_driver)) {

I would consider that rather ugly, a driver shouldn't really use
#ifdef like this, but you can hide stuff like this in a header. The method
I proposed also has the advantage of avoiding exporting the
usb_hid_driver object. Drivers shouldn't really need to access this,
and wacom_sys.c is the only remaining user of the export.

  Arnd

[PATCH v5 1/2] platform: Add driver for RAVE Supervisory Processor

[Andrey Smirnov]

Add a driver for RAVE Supervisory Processor, an MCU implementing
varoius bits of housekeeping functionality (watchdoging, backlight
control, LED control, etc) on RAVE family of products by Zodiac
Inflight Innovations.

This driver implementes core MFD/serdev device as well as
communication subroutines necessary for commanding the device.

Cc: linux-kernel@vger.kernel.org
Cc: cphe...@gmail.com
Cc: Lucas Stach 
Cc: Nikita Yushchenko 
Cc: Lee Jones 
Tested-by: Chris Healy 
Reviewed-by: Andy Shevchenko 
Signed-off-by: Andrey Smirnov 
---
 drivers/platform/Kconfig|2 +
 drivers/platform/Makefile   |1 +
 drivers/platform/rave/Kconfig   |   26 +
 drivers/platform/rave/Makefile  |1 +
 drivers/platform/rave/rave-sp.c | 1127 +++
 include/linux/rave-sp.h |   54 ++
 6 files changed, 1211 insertions(+)
 create mode 100644 drivers/platform/rave/Kconfig
 create mode 100644 drivers/platform/rave/Makefile
 create mode 100644 drivers/platform/rave/rave-sp.c
 create mode 100644 include/linux/rave-sp.h

diff --git a/drivers/platform/Kconfig b/drivers/platform/Kconfig
index c11db8bceea1..e6db685bb895 100644
--- a/drivers/platform/Kconfig
+++ b/drivers/platform/Kconfig
@@ -8,3 +8,5 @@ endif
 source "drivers/platform/goldfish/Kconfig"
 
 source "drivers/platform/chrome/Kconfig"
+
+source "drivers/platform/rave/Kconfig"
diff --git a/drivers/platform/Makefile b/drivers/platform/Makefile
index ca2692510733..17bdec5ece0c 100644
--- a/drivers/platform/Makefile
+++ b/drivers/platform/Makefile
@@ -7,3 +7,4 @@ obj-$(CONFIG_MIPS)  += mips/
 obj-$(CONFIG_OLPC) += olpc/
 obj-$(CONFIG_GOLDFISH) += goldfish/
 obj-$(CONFIG_CHROME_PLATFORMS) += chrome/
+obj-y += rave/
diff --git a/drivers/platform/rave/Kconfig b/drivers/platform/rave/Kconfig
new file mode 100644
index ..6fc50ade3871
--- /dev/null
+++ b/drivers/platform/rave/Kconfig
@@ -0,0 +1,26 @@
+#
+# Platform support for Zodiac RAVE hardware
+#
+
+menuconfig RAVE_PLATFORMS
+   bool "Platform support for Zodiac RAVE hardware"
+   depends on SERIAL_DEV_BUS && SERIAL_DEV_CTRL_TTYPORT
+   help
+ Say Y here to get to see options for platform support for
+ various devices present in RAVE hardware. This option alone
+ does not add any kernel code.
+
+ If you say N, all options in this submenu will be skipped
+ and disabled.
+
+if RAVE_PLATFORMS
+
+config RAVE_SP_CORE
+   tristate "RAVE SP MCU core driver"
+   select MFD_CORE
+   select CRC_CCITT
+   help
+ Select this to get support for the Supervisory Processor
+ device found on several devices in RAVE line of hardware.
+
+endif
diff --git a/drivers/platform/rave/Makefile b/drivers/platform/rave/Makefile
new file mode 100644
index ..e4c21ab2d2f5
--- /dev/null
+++ b/drivers/platform/rave/Makefile
@@ -0,0 +1 @@
+obj-$(CONFIG_RAVE_SP_CORE) += rave-sp.o
diff --git a/drivers/platform/rave/rave-sp.c b/drivers/platform/rave/rave-sp.c
new file mode 100644
index ..cd7aac6fcd1a
--- /dev/null
+++ b/drivers/platform/rave/rave-sp.c
@@ -0,0 +1,1127 @@
+/*
+ * Multifunction core driver for Zodiac Inflight Innovations
+ * SP MCU that is connected via dedicated UART port
+ *
+ * Copyright (C) 2017 Zodiac Inflight Innovations
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License as
+ * published by the Free Software Foundation; either version 2 of
+ * the License, or (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, see .
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+/*
+ * UART protocol using following entities:
+ *  - message to MCU => ACK response
+ *  - event from MCU => event ACK
+ *
+ * Frame structure:
+ *
+ * Where:
+ * - STX - is start of transmission character
+ * - ETX - end of transmission
+ * - DATA - payload
+ * - CHECKSUM - checksum calculated on 
+ *
+ * If  or  contain one of control characters, then it is
+ * escaped using  control code. Added  does not participate in
+ * checksum calculation.
+ */
+#define RAVE_SP_STX0x02
+#define RAVE_SP_ETX0x03
+#define RAVE_SP_DLE0x10
+
+#define RAVE_SP_MAX_DATA_SIZE  64
+#define RAVE_SP_CHECKSUM_SIZE  2  /* 

[PATCH v5 2/2] dt-bindings: mfd: Add bindings for ZII RAVE devices

[Andrey Smirnov]

Cc: cphe...@gmail.com
Cc: Lucas Stach 
Cc: Nikita Yushchenko 
Cc: Rob Herring 
Cc: Mark Rutland 
Cc: devicet...@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
Acked-by: Rob Herring 
Acked-for-MFD-by: Lee Jones 
Signed-off-by: Andrey Smirnov 
---
 .../devicetree/bindings/mfd/zii,rave-sp.txt| 39 ++
 1 file changed, 39 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/mfd/zii,rave-sp.txt

diff --git a/Documentation/devicetree/bindings/mfd/zii,rave-sp.txt 
b/Documentation/devicetree/bindings/mfd/zii,rave-sp.txt
new file mode 100644
index ..088eff9ddb78
--- /dev/null
+++ b/Documentation/devicetree/bindings/mfd/zii,rave-sp.txt
@@ -0,0 +1,39 @@
+Zodiac Inflight Innovations RAVE Supervisory Processor
+
+RAVE Supervisory Processor communicates with SoC over UART. It is
+expected that its Device Tree node is specified as a child of a node
+corresponding to UART controller used for communication.
+
+Required parent device properties:
+
+ - compatible: Should be one of:
+   - "zii,rave-sp-niu"
+   - "zii,rave-sp-mezz"
+   - "zii,rave-sp-esb"
+   - "zii,rave-sp-rdu1"
+   - "zii,rave-sp-rdu2"
+
+ - current-speed: Should be set to baud rate SP device is using
+
+RAVE SP consists of the following sub-devices:
+
+Device  Description
+--  ---
+rave-sp-wdt: Watchdog
+rave-sp-nvmem  : Interface to onborad EEPROM
+rave-sp-backlight  : Display backlight
+rave-sp-hwmon  : Interface to onboard hardware sensors
+rave-sp-leds   : Interface to onboard LEDs
+rave-sp-input  : Interface to onboard power button
+
+Example of usage:
+
+   rdu {
+   compatible = "zii,rave-sp-rdu2";
+   current-speed = <100>;
+
+   watchdog {
+   compatible = "zii,rave-sp-watchdog";
+   };
+   };
+
-- 
2.13.3

Re: [PATCH 08/14] ipmi: use atomic_dec_not_zero()

[Corey Minyard]

I missed this until now, and I see it hasn't been applied yet.  It's 
queued for the next release.


Thanks,

-corey

On 01/30/2017 12:47 PM, Fabian Frederick wrote:

instead of atomic_add_unless(value, -1, 0)

Signed-off-by: Fabian Frederick 
---
  drivers/char/ipmi/ipmi_msghandler.c | 2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/char/ipmi/ipmi_msghandler.c 
b/drivers/char/ipmi/ipmi_msghandler.c
index 9f69995..961d677 100644
--- a/drivers/char/ipmi/ipmi_msghandler.c
+++ b/drivers/char/ipmi/ipmi_msghandler.c
@@ -3851,7 +3851,7 @@ static void handle_new_recv_msgs(ipmi_smi_t intf)
 * If the pretimout count is non-zero, decrement one from it and
 * deliver pretimeouts to all the users.
 */
-   if (atomic_add_unless(>watchdog_pretimeouts_to_deliver, -1, 0)) {
+   if (atomic_dec_not_zero(>watchdog_pretimeouts_to_deliver)) {
ipmi_user_t user;
  
  		rcu_read_lock();

[PATCH v5 1/2] platform: Add driver for RAVE Supervisory Processor

[Andrey Smirnov]

Add a driver for RAVE Supervisory Processor, an MCU implementing
varoius bits of housekeeping functionality (watchdoging, backlight
control, LED control, etc) on RAVE family of products by Zodiac
Inflight Innovations.

This driver implementes core MFD/serdev device as well as
communication subroutines necessary for commanding the device.

Cc: linux-kernel@vger.kernel.org
Cc: cphe...@gmail.com
Cc: Lucas Stach 
Cc: Nikita Yushchenko 
Cc: Lee Jones 
Tested-by: Chris Healy 
Reviewed-by: Andy Shevchenko 
Signed-off-by: Andrey Smirnov 
---
 drivers/platform/Kconfig|2 +
 drivers/platform/Makefile   |1 +
 drivers/platform/rave/Kconfig   |   26 +
 drivers/platform/rave/Makefile  |1 +
 drivers/platform/rave/rave-sp.c | 1127 +++
 include/linux/rave-sp.h |   54 ++
 6 files changed, 1211 insertions(+)
 create mode 100644 drivers/platform/rave/Kconfig
 create mode 100644 drivers/platform/rave/Makefile
 create mode 100644 drivers/platform/rave/rave-sp.c
 create mode 100644 include/linux/rave-sp.h

diff --git a/drivers/platform/Kconfig b/drivers/platform/Kconfig
index c11db8bceea1..e6db685bb895 100644
--- a/drivers/platform/Kconfig
+++ b/drivers/platform/Kconfig
@@ -8,3 +8,5 @@ endif
 source "drivers/platform/goldfish/Kconfig"
 
 source "drivers/platform/chrome/Kconfig"
+
+source "drivers/platform/rave/Kconfig"
diff --git a/drivers/platform/Makefile b/drivers/platform/Makefile
index ca2692510733..17bdec5ece0c 100644
--- a/drivers/platform/Makefile
+++ b/drivers/platform/Makefile
@@ -7,3 +7,4 @@ obj-$(CONFIG_MIPS)  += mips/
 obj-$(CONFIG_OLPC) += olpc/
 obj-$(CONFIG_GOLDFISH) += goldfish/
 obj-$(CONFIG_CHROME_PLATFORMS) += chrome/
+obj-y += rave/
diff --git a/drivers/platform/rave/Kconfig b/drivers/platform/rave/Kconfig
new file mode 100644
index ..6fc50ade3871
--- /dev/null
+++ b/drivers/platform/rave/Kconfig
@@ -0,0 +1,26 @@
+#
+# Platform support for Zodiac RAVE hardware
+#
+
+menuconfig RAVE_PLATFORMS
+   bool "Platform support for Zodiac RAVE hardware"
+   depends on SERIAL_DEV_BUS && SERIAL_DEV_CTRL_TTYPORT
+   help
+ Say Y here to get to see options for platform support for
+ various devices present in RAVE hardware. This option alone
+ does not add any kernel code.
+
+ If you say N, all options in this submenu will be skipped
+ and disabled.
+
+if RAVE_PLATFORMS
+
+config RAVE_SP_CORE
+   tristate "RAVE SP MCU core driver"
+   select MFD_CORE
+   select CRC_CCITT
+   help
+ Select this to get support for the Supervisory Processor
+ device found on several devices in RAVE line of hardware.
+
+endif
diff --git a/drivers/platform/rave/Makefile b/drivers/platform/rave/Makefile
new file mode 100644
index ..e4c21ab2d2f5
--- /dev/null
+++ b/drivers/platform/rave/Makefile
@@ -0,0 +1 @@
+obj-$(CONFIG_RAVE_SP_CORE) += rave-sp.o
diff --git a/drivers/platform/rave/rave-sp.c b/drivers/platform/rave/rave-sp.c
new file mode 100644
index ..cd7aac6fcd1a
--- /dev/null
+++ b/drivers/platform/rave/rave-sp.c
@@ -0,0 +1,1127 @@
+/*
+ * Multifunction core driver for Zodiac Inflight Innovations
+ * SP MCU that is connected via dedicated UART port
+ *
+ * Copyright (C) 2017 Zodiac Inflight Innovations
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License as
+ * published by the Free Software Foundation; either version 2 of
+ * the License, or (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, see .
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+/*
+ * UART protocol using following entities:
+ *  - message to MCU => ACK response
+ *  - event from MCU => event ACK
+ *
+ * Frame structure:
+ *
+ * Where:
+ * - STX - is start of transmission character
+ * - ETX - end of transmission
+ * - DATA - payload
+ * - CHECKSUM - checksum calculated on 
+ *
+ * If  or  contain one of control characters, then it is
+ * escaped using  control code. Added  does not participate in
+ * checksum calculation.
+ */
+#define RAVE_SP_STX0x02
+#define RAVE_SP_ETX0x03
+#define RAVE_SP_DLE0x10
+
+#define RAVE_SP_MAX_DATA_SIZE  64
+#define RAVE_SP_CHECKSUM_SIZE  2  /* Worst case scenario on RDU2 */
+/*
+ * We don't store STX, ETX and unescaped bytes, so Rx is only
+ * DATA + CSUM
+ */
+#define RAVE_SP_RX_BUFFER_SIZE   

[PATCH v5 2/2] dt-bindings: mfd: Add bindings for ZII RAVE devices

[Andrey Smirnov]

Cc: cphe...@gmail.com
Cc: Lucas Stach 
Cc: Nikita Yushchenko 
Cc: Rob Herring 
Cc: Mark Rutland 
Cc: devicet...@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
Acked-by: Rob Herring 
Acked-for-MFD-by: Lee Jones 
Signed-off-by: Andrey Smirnov 
---
 .../devicetree/bindings/mfd/zii,rave-sp.txt| 39 ++
 1 file changed, 39 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/mfd/zii,rave-sp.txt

diff --git a/Documentation/devicetree/bindings/mfd/zii,rave-sp.txt 
b/Documentation/devicetree/bindings/mfd/zii,rave-sp.txt
new file mode 100644
index ..088eff9ddb78
--- /dev/null
+++ b/Documentation/devicetree/bindings/mfd/zii,rave-sp.txt
@@ -0,0 +1,39 @@
+Zodiac Inflight Innovations RAVE Supervisory Processor
+
+RAVE Supervisory Processor communicates with SoC over UART. It is
+expected that its Device Tree node is specified as a child of a node
+corresponding to UART controller used for communication.
+
+Required parent device properties:
+
+ - compatible: Should be one of:
+   - "zii,rave-sp-niu"
+   - "zii,rave-sp-mezz"
+   - "zii,rave-sp-esb"
+   - "zii,rave-sp-rdu1"
+   - "zii,rave-sp-rdu2"
+
+ - current-speed: Should be set to baud rate SP device is using
+
+RAVE SP consists of the following sub-devices:
+
+Device  Description
+--  ---
+rave-sp-wdt: Watchdog
+rave-sp-nvmem  : Interface to onborad EEPROM
+rave-sp-backlight  : Display backlight
+rave-sp-hwmon  : Interface to onboard hardware sensors
+rave-sp-leds   : Interface to onboard LEDs
+rave-sp-input  : Interface to onboard power button
+
+Example of usage:
+
+   rdu {
+   compatible = "zii,rave-sp-rdu2";
+   current-speed = <100>;
+
+   watchdog {
+   compatible = "zii,rave-sp-watchdog";
+   };
+   };
+
-- 
2.13.3

Re: [PATCH 08/14] ipmi: use atomic_dec_not_zero()

[Corey Minyard]

I missed this until now, and I see it hasn't been applied yet.  It's 
queued for the next release.


Thanks,

-corey

On 01/30/2017 12:47 PM, Fabian Frederick wrote:

instead of atomic_add_unless(value, -1, 0)

Signed-off-by: Fabian Frederick 
---
  drivers/char/ipmi/ipmi_msghandler.c | 2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/char/ipmi/ipmi_msghandler.c 
b/drivers/char/ipmi/ipmi_msghandler.c
index 9f69995..961d677 100644
--- a/drivers/char/ipmi/ipmi_msghandler.c
+++ b/drivers/char/ipmi/ipmi_msghandler.c
@@ -3851,7 +3851,7 @@ static void handle_new_recv_msgs(ipmi_smi_t intf)
 * If the pretimout count is non-zero, decrement one from it and
 * deliver pretimeouts to all the users.
 */
-   if (atomic_add_unless(>watchdog_pretimeouts_to_deliver, -1, 0)) {
+   if (atomic_dec_not_zero(>watchdog_pretimeouts_to_deliver)) {
ipmi_user_t user;
  
  		rcu_read_lock();

[PATCH v5 0/2] ZII RAVE platform driver

[Andrey Smirnov]

Greg,

I am not sure if you are the right person to send these to, if you are
not, please let me know who would be the appropriate recepient and sorry for 
the noise.

Thanks!


The orginal conver letter text follows:

Hi everyone,

This patch series is v4 of the driver for supervisory processor found
on RAVE series of devices from ZII. Supervisory processor is a PIC
microcontroller connected to various electrical subsystems on RAVE
devices whose firmware implements protocol to command/qery them.

Changes since [v4]:

- Replaced usage of DEVICE_ATTR with DEVICE_ATTR_RW

- Fixed a number of warnings produces by sparse tool

- Incorporated event more feedback from Andy Shevchenko

- Collected Reviewed-by from Andy

Changes since [v3]:

- Re-collected lost Acked-by from Rob

- Incorporated further feedback from Andy Shevchenko

- Dropped useless change (stray newline) to drivers/mfd/Makefile

Changes since [v2]:

- Fixed swapped command codes in rave_sp_common_get_boot_source()
  and rave_sp_common_set_boot_source() revealed by further testing
  of the code

- Incorporated feedback from Andy Shevchenko

Changes since [v1]:

- Updated wording in DT-bindings as per Rob's request.

- Collected Rob's Acked-by for patch 2/2

NOTE:

 * The driver for "zii,rave-sp-watchdog" exists, but I haven't
   submitted it yet, becuase I wanted to make sure that API exposed by
   this MFD is acceptable and doesn't need drastic changes.

 * This driver is dependent on crc_ccitt_false() introduced in
   2da9378d531f8cc6670c7497f20d936b706ab80b in 'linux-next'

Feedback is greatly appreciated!

Thanks,
Andrey Smirnov

[v4] lkml.kernel.org/r/20170725184450.13171-1-andrew.smir...@gmail.com
[v3] lkml.kernel.org/r/20170724150915.4824-1-andrew.smir...@gmail.com
[v2] lkml.kernel.org/r/20170718175604.11735-1-andrew.smir...@gmail.com
[v1] lkml.kernel.org/r/20170710170449.4544-1-andrew.smir...@gmail.com


Andrey Smirnov (2):
  platform: Add driver for RAVE Supervisory Processor
  dt-bindings: mfd: Add bindings for ZII RAVE devices

 .../devicetree/bindings/mfd/zii,rave-sp.txt|   39 +
 drivers/platform/Kconfig   |2 +
 drivers/platform/Makefile  |1 +
 drivers/platform/rave/Kconfig  |   26 +
 drivers/platform/rave/Makefile |1 +
 drivers/platform/rave/rave-sp.c| 1127 
 include/linux/rave-sp.h|   54 +
 7 files changed, 1250 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/mfd/zii,rave-sp.txt
 create mode 100644 drivers/platform/rave/Kconfig
 create mode 100644 drivers/platform/rave/Makefile
 create mode 100644 drivers/platform/rave/rave-sp.c
 create mode 100644 include/linux/rave-sp.h

-- 
2.13.3

[PATCH v5 0/2] ZII RAVE platform driver

[Andrey Smirnov]

Greg,

I am not sure if you are the right person to send these to, if you are
not, please let me know who would be the appropriate recepient and sorry for 
the noise.

Thanks!


The orginal conver letter text follows:

Hi everyone,

This patch series is v4 of the driver for supervisory processor found
on RAVE series of devices from ZII. Supervisory processor is a PIC
microcontroller connected to various electrical subsystems on RAVE
devices whose firmware implements protocol to command/qery them.

Changes since [v4]:

- Replaced usage of DEVICE_ATTR with DEVICE_ATTR_RW

- Fixed a number of warnings produces by sparse tool

- Incorporated event more feedback from Andy Shevchenko

- Collected Reviewed-by from Andy

Changes since [v3]:

- Re-collected lost Acked-by from Rob

- Incorporated further feedback from Andy Shevchenko

- Dropped useless change (stray newline) to drivers/mfd/Makefile

Changes since [v2]:

- Fixed swapped command codes in rave_sp_common_get_boot_source()
  and rave_sp_common_set_boot_source() revealed by further testing
  of the code

- Incorporated feedback from Andy Shevchenko

Changes since [v1]:

- Updated wording in DT-bindings as per Rob's request.

- Collected Rob's Acked-by for patch 2/2

NOTE:

 * The driver for "zii,rave-sp-watchdog" exists, but I haven't
   submitted it yet, becuase I wanted to make sure that API exposed by
   this MFD is acceptable and doesn't need drastic changes.

 * This driver is dependent on crc_ccitt_false() introduced in
   2da9378d531f8cc6670c7497f20d936b706ab80b in 'linux-next'

Feedback is greatly appreciated!

Thanks,
Andrey Smirnov

[v4] lkml.kernel.org/r/20170725184450.13171-1-andrew.smir...@gmail.com
[v3] lkml.kernel.org/r/20170724150915.4824-1-andrew.smir...@gmail.com
[v2] lkml.kernel.org/r/20170718175604.11735-1-andrew.smir...@gmail.com
[v1] lkml.kernel.org/r/20170710170449.4544-1-andrew.smir...@gmail.com


Andrey Smirnov (2):
  platform: Add driver for RAVE Supervisory Processor
  dt-bindings: mfd: Add bindings for ZII RAVE devices

 .../devicetree/bindings/mfd/zii,rave-sp.txt|   39 +
 drivers/platform/Kconfig   |2 +
 drivers/platform/Makefile  |1 +
 drivers/platform/rave/Kconfig  |   26 +
 drivers/platform/rave/Makefile |1 +
 drivers/platform/rave/rave-sp.c| 1127 
 include/linux/rave-sp.h|   54 +
 7 files changed, 1250 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/mfd/zii,rave-sp.txt
 create mode 100644 drivers/platform/rave/Kconfig
 create mode 100644 drivers/platform/rave/Makefile
 create mode 100644 drivers/platform/rave/rave-sp.c
 create mode 100644 include/linux/rave-sp.h

-- 
2.13.3

Re: [PATCH] staging: pi433: use div_u64 for 64-bit division

[Dan Carpenter]

On Fri, Jul 28, 2017 at 04:21:05PM +0200, Marcus Wolf wrote:
> Hi Arnd,
> 
> we already have a patch for this: 
> [PATCH 1/1] staging: pi433: fix problem with division in rf69_set_deviation
>  from 20.07.2017


https://patchwork.kernel.org/patch/9855261/

> 
> Maybe I did something wrong, but my first solution was exactly like your
> proposal. As far as I remeber, I wasn't able to compile it that way. 
> Therefore I
> made a little bit more complicated fix. If I did something wrong and yours is
> fine, we should go for yours, because it is a shorter solution.
> 

Your patch doesn't apply for one thing  :(  Read
Documentation/process/email-clients.rst  It probably would have been Ok
otherwise.

I'm pretty sure that Arnd's patch is going to be fine.

regards,
dan carpenter

Re: [PATCH] staging: pi433: use div_u64 for 64-bit division

[Dan Carpenter]

On Fri, Jul 28, 2017 at 04:21:05PM +0200, Marcus Wolf wrote:
> Hi Arnd,
> 
> we already have a patch for this: 
> [PATCH 1/1] staging: pi433: fix problem with division in rf69_set_deviation
>  from 20.07.2017


https://patchwork.kernel.org/patch/9855261/

> 
> Maybe I did something wrong, but my first solution was exactly like your
> proposal. As far as I remeber, I wasn't able to compile it that way. 
> Therefore I
> made a little bit more complicated fix. If I did something wrong and yours is
> fine, we should go for yours, because it is a shorter solution.
> 

Your patch doesn't apply for one thing  :(  Read
Documentation/process/email-clients.rst  It probably would have been Ok
otherwise.

I'm pretty sure that Arnd's patch is going to be fine.

regards,
dan carpenter

Re: [PATCH] staging: pi433: use div_u64 for 64-bit division

[Arnd Bergmann]

On Fri, Jul 28, 2017 at 4:21 PM, Marcus Wolf
 wrote:
> Hi Arnd,
>
> we already have a patch for this:
> [PATCH 1/1] staging: pi433: fix problem with division in rf69_set_deviation
>  from 20.07.2017
>
> Maybe I did something wrong, but my first solution was exactly like your
> proposal. As far as I remeber, I wasn't able to compile it that way. 
> Therefore I
> made a little bit more complicated fix. If I did something wrong and yours is
> fine, we should go for yours, because it is a shorter solution.

I think the problem with your original patch is that it doesn't work
for 'u64 factor':
do_div() is a bit tricky to work with, and it does not always accept a 64-bit
divisor, while div_u64 will simply convert the divisor to a u32.

You can also make 'factor' a 'u32' and keep using do_div.

Arnd

Re: [PATCH] staging: pi433: use div_u64 for 64-bit division

[Arnd Bergmann]

On Fri, Jul 28, 2017 at 4:21 PM, Marcus Wolf
 wrote:
> Hi Arnd,
>
> we already have a patch for this:
> [PATCH 1/1] staging: pi433: fix problem with division in rf69_set_deviation
>  from 20.07.2017
>
> Maybe I did something wrong, but my first solution was exactly like your
> proposal. As far as I remeber, I wasn't able to compile it that way. 
> Therefore I
> made a little bit more complicated fix. If I did something wrong and yours is
> fine, we should go for yours, because it is a shorter solution.

I think the problem with your original patch is that it doesn't work
for 'u64 factor':
do_div() is a bit tricky to work with, and it does not always accept a 64-bit
divisor, while div_u64 will simply convert the divisor to a u32.

You can also make 'factor' a 'u32' and keep using do_div.

Arnd

Re: blk_mq_sched_insert_request: inconsistent {SOFTIRQ-ON-W} -> {IN-SOFTIRQ-W} usage

[Jens Axboe]

On 07/28/2017 12:19 AM, Michael Ellerman wrote:
> Jens Axboe  writes:
>> On 07/27/2017 08:47 AM, Bart Van Assche wrote:
>>> On Thu, 2017-07-27 at 08:02 -0600, Jens Axboe wrote:
 The bug looks like SCSI running the queue inline from IRQ
 context, that's not a good idea.
> ...
>>>
>>> scsi_run_queue() works fine if no scheduler is configured. Additionally, 
>>> that
>>> code predates the introduction of blk-mq I/O schedulers. I think it is
>>> nontrivial for block driver authors to figure out that a queue has to be run
>>> from process context if a scheduler has been configured that does not 
>>> support
>>> to be run from interrupt context.
>>
>> No it doesn't, you could never run the queue from interrupt context with
>> async == false. So I don't think that's confusing at all, you should
>> always be aware of the context.
>>
>>> How about adding WARN_ON_ONCE(in_interrupt()) to
>>> blk_mq_start_hw_queue() or replacing the above patch by the following:
>>
>> No, I hate having dependencies like that, because they always just catch
>> one of them. Looks like the IPR path that hits this should just offload
>> to a workqueue or similar, you don't have to make any scsi_run_queue()
>> async.
> 
> OK, so the resolution is "fix it in IPR" ?

I'll leave that to the SCSI crew. But at least one bug is in IPR, if you
look at the call trace:

- timer function triggers, runs ipr_reset_timer_done(), which grabs the
  host lock AND disables interrupts.
- further down in the call path, ipr_ioa_bringdown_done() uncondtionally
  enables interrupts:

spin_unlock_irq(ioa_cfg->host->host_lock);
scsi_unblock_requests(ioa_cfg->host);
spin_lock_irq(ioa_cfg->host->host_lock); 

And the call to scsi_unblock_requests() is the one that ultimately runs
the queue. The IRQ issue aside here, scsi_unblock_requests() could run
the queue async, and we could retain the normal sync run otherwise.

Can you try the below fix? Should be more palatable than the previous
one. Brian, maybe you can take a look at the IRQ issue mentioned above?

diff --git a/drivers/scsi/scsi_lib.c b/drivers/scsi/scsi_lib.c
index f6097b89d5d3..dfb89596af81 100644
--- a/drivers/scsi/scsi_lib.c
+++ b/drivers/scsi/scsi_lib.c
@@ -481,13 +481,14 @@ static void scsi_starved_list_run(struct Scsi_Host *shost)
  * Purpose:Select a proper request queue to serve next
  *
  * Arguments:  q   - last request's queue
+ * async   - run queues async, if we need to
  *
  * Returns: Nothing
  *
  * Notes:  The previous command was completely finished, start
  * a new one if possible.
  */
-static void scsi_run_queue(struct request_queue *q)
+static void scsi_run_queue(struct request_queue *q, bool async)
 {
struct scsi_device *sdev = q->queuedata;
 
@@ -497,7 +498,7 @@ static void scsi_run_queue(struct request_queue *q)
scsi_starved_list_run(sdev->host);
 
if (q->mq_ops)
-   blk_mq_run_hw_queues(q, false);
+   blk_mq_run_hw_queues(q, async);
else
blk_run_queue(q);
 }
@@ -509,7 +510,7 @@ void scsi_requeue_run_queue(struct work_struct *work)
 
sdev = container_of(work, struct scsi_device, requeue_work);
q = sdev->request_queue;
-   scsi_run_queue(q);
+   scsi_run_queue(q, false);
 }
 
 /*
@@ -543,17 +544,22 @@ static void scsi_requeue_command(struct request_queue *q, 
struct scsi_cmnd *cmd)
blk_requeue_request(q, req);
spin_unlock_irqrestore(q->queue_lock, flags);
 
-   scsi_run_queue(q);
+   scsi_run_queue(q, true);
 
put_device(>sdev_gendev);
 }
 
-void scsi_run_host_queues(struct Scsi_Host *shost)
+static void __scsi_run_host_queues(struct Scsi_Host *shost, bool async)
 {
struct scsi_device *sdev;
 
shost_for_each_device(sdev, shost)
-   scsi_run_queue(sdev->request_queue);
+   scsi_run_queue(sdev->request_queue, async);
+}
+
+void scsi_run_host_queues(struct Scsi_Host *shost)
+{
+   __scsi_run_host_queues(shost, false);
 }
 
 static void scsi_uninit_cmd(struct scsi_cmnd *cmd)
@@ -671,7 +677,7 @@ static bool scsi_end_request(struct request *req, 
blk_status_t error,
blk_finish_request(req, error);
spin_unlock_irqrestore(q->queue_lock, flags);
 
-   scsi_run_queue(q);
+   scsi_run_queue(q, false);
}
 
put_device(>sdev_gendev);
@@ -2293,7 +2299,7 @@ EXPORT_SYMBOL(scsi_block_requests);
 void scsi_unblock_requests(struct Scsi_Host *shost)
 {
shost->host_self_blocked = 0;
-   scsi_run_host_queues(shost);
+   __scsi_run_host_queues(shost, true);
 }
 EXPORT_SYMBOL(scsi_unblock_requests);
 
@@ -2897,10 +2903,10 @@ scsi_device_quiesce(struct scsi_device *sdev)
if (err)
return err;
 
-   scsi_run_queue(sdev->request_queue);
+   scsi_run_queue(sdev->request_queue, false);
while 

Re: blk_mq_sched_insert_request: inconsistent {SOFTIRQ-ON-W} -> {IN-SOFTIRQ-W} usage

[Jens Axboe]

On 07/28/2017 12:19 AM, Michael Ellerman wrote:
> Jens Axboe  writes:
>> On 07/27/2017 08:47 AM, Bart Van Assche wrote:
>>> On Thu, 2017-07-27 at 08:02 -0600, Jens Axboe wrote:
 The bug looks like SCSI running the queue inline from IRQ
 context, that's not a good idea.
> ...
>>>
>>> scsi_run_queue() works fine if no scheduler is configured. Additionally, 
>>> that
>>> code predates the introduction of blk-mq I/O schedulers. I think it is
>>> nontrivial for block driver authors to figure out that a queue has to be run
>>> from process context if a scheduler has been configured that does not 
>>> support
>>> to be run from interrupt context.
>>
>> No it doesn't, you could never run the queue from interrupt context with
>> async == false. So I don't think that's confusing at all, you should
>> always be aware of the context.
>>
>>> How about adding WARN_ON_ONCE(in_interrupt()) to
>>> blk_mq_start_hw_queue() or replacing the above patch by the following:
>>
>> No, I hate having dependencies like that, because they always just catch
>> one of them. Looks like the IPR path that hits this should just offload
>> to a workqueue or similar, you don't have to make any scsi_run_queue()
>> async.
> 
> OK, so the resolution is "fix it in IPR" ?

I'll leave that to the SCSI crew. But at least one bug is in IPR, if you
look at the call trace:

- timer function triggers, runs ipr_reset_timer_done(), which grabs the
  host lock AND disables interrupts.
- further down in the call path, ipr_ioa_bringdown_done() uncondtionally
  enables interrupts:

spin_unlock_irq(ioa_cfg->host->host_lock);
scsi_unblock_requests(ioa_cfg->host);
spin_lock_irq(ioa_cfg->host->host_lock); 

And the call to scsi_unblock_requests() is the one that ultimately runs
the queue. The IRQ issue aside here, scsi_unblock_requests() could run
the queue async, and we could retain the normal sync run otherwise.

Can you try the below fix? Should be more palatable than the previous
one. Brian, maybe you can take a look at the IRQ issue mentioned above?

diff --git a/drivers/scsi/scsi_lib.c b/drivers/scsi/scsi_lib.c
index f6097b89d5d3..dfb89596af81 100644
--- a/drivers/scsi/scsi_lib.c
+++ b/drivers/scsi/scsi_lib.c
@@ -481,13 +481,14 @@ static void scsi_starved_list_run(struct Scsi_Host *shost)
  * Purpose:Select a proper request queue to serve next
  *
  * Arguments:  q   - last request's queue
+ * async   - run queues async, if we need to
  *
  * Returns: Nothing
  *
  * Notes:  The previous command was completely finished, start
  * a new one if possible.
  */
-static void scsi_run_queue(struct request_queue *q)
+static void scsi_run_queue(struct request_queue *q, bool async)
 {
struct scsi_device *sdev = q->queuedata;
 
@@ -497,7 +498,7 @@ static void scsi_run_queue(struct request_queue *q)
scsi_starved_list_run(sdev->host);
 
if (q->mq_ops)
-   blk_mq_run_hw_queues(q, false);
+   blk_mq_run_hw_queues(q, async);
else
blk_run_queue(q);
 }
@@ -509,7 +510,7 @@ void scsi_requeue_run_queue(struct work_struct *work)
 
sdev = container_of(work, struct scsi_device, requeue_work);
q = sdev->request_queue;
-   scsi_run_queue(q);
+   scsi_run_queue(q, false);
 }
 
 /*
@@ -543,17 +544,22 @@ static void scsi_requeue_command(struct request_queue *q, 
struct scsi_cmnd *cmd)
blk_requeue_request(q, req);
spin_unlock_irqrestore(q->queue_lock, flags);
 
-   scsi_run_queue(q);
+   scsi_run_queue(q, true);
 
put_device(>sdev_gendev);
 }
 
-void scsi_run_host_queues(struct Scsi_Host *shost)
+static void __scsi_run_host_queues(struct Scsi_Host *shost, bool async)
 {
struct scsi_device *sdev;
 
shost_for_each_device(sdev, shost)
-   scsi_run_queue(sdev->request_queue);
+   scsi_run_queue(sdev->request_queue, async);
+}
+
+void scsi_run_host_queues(struct Scsi_Host *shost)
+{
+   __scsi_run_host_queues(shost, false);
 }
 
 static void scsi_uninit_cmd(struct scsi_cmnd *cmd)
@@ -671,7 +677,7 @@ static bool scsi_end_request(struct request *req, 
blk_status_t error,
blk_finish_request(req, error);
spin_unlock_irqrestore(q->queue_lock, flags);
 
-   scsi_run_queue(q);
+   scsi_run_queue(q, false);
}
 
put_device(>sdev_gendev);
@@ -2293,7 +2299,7 @@ EXPORT_SYMBOL(scsi_block_requests);
 void scsi_unblock_requests(struct Scsi_Host *shost)
 {
shost->host_self_blocked = 0;
-   scsi_run_host_queues(shost);
+   __scsi_run_host_queues(shost, true);
 }
 EXPORT_SYMBOL(scsi_unblock_requests);
 
@@ -2897,10 +2903,10 @@ scsi_device_quiesce(struct scsi_device *sdev)
if (err)
return err;
 
-   scsi_run_queue(sdev->request_queue);
+   scsi_run_queue(sdev->request_queue, false);
while 

Re: [PATCH] HID: wacom: add USB_HID dependency

[Jason Gerecke]

On Fri, Jul 28, 2017 at 7:18 AM, Arnd Bergmann  wrote:
> On Fri, Jul 28, 2017 at 4:07 PM, Jason Gerecke  wrote:
>> On July 28, 2017 6:18:00 AM PDT, Arnd Bergmann  wrote:
>>>The driver has gained a compile-time dependency that we should
>>>express in Kconfig to avoid this link error:
>>>
>>
>> Would conditional compilation be an acceptable alternative to adding
>> a dependency? The USB_HID code is only used to check if the driver
>> is working with a USB device. With USB_HID disabled, there's no need
>> for the check so there's no need for the dependency.
>
> I think that should work, e.g. you could replace the hid_is_using_ll_driver
> and 'extern' defintions with a helper per ll-driver like
>
> #ifdef CONFIG_USB_HID
> extern bool hid_is_using_usb_driver(struct hid_device *hdev)
> #else
> static inline bool hid_is_using_usb_driver(struct hid_device *hdev)
> {
>return false;
> }
> #endif
>
> but is it worth it to avoid the dependency?
>
>Arnd

I was thinking something more along the lines of the following since
the idea of per-transport helper functions was dismissed earlier:

#ifdef CONFIG_USB_HID
if (hid_is_using_ll_driver(wacom->hdev, _hid_driver)) {
[...]
}
#endif

Jason

Re: [PATCH] HID: wacom: add USB_HID dependency

[Jason Gerecke]

On Fri, Jul 28, 2017 at 7:18 AM, Arnd Bergmann  wrote:
> On Fri, Jul 28, 2017 at 4:07 PM, Jason Gerecke  wrote:
>> On July 28, 2017 6:18:00 AM PDT, Arnd Bergmann  wrote:
>>>The driver has gained a compile-time dependency that we should
>>>express in Kconfig to avoid this link error:
>>>
>>
>> Would conditional compilation be an acceptable alternative to adding
>> a dependency? The USB_HID code is only used to check if the driver
>> is working with a USB device. With USB_HID disabled, there's no need
>> for the check so there's no need for the dependency.
>
> I think that should work, e.g. you could replace the hid_is_using_ll_driver
> and 'extern' defintions with a helper per ll-driver like
>
> #ifdef CONFIG_USB_HID
> extern bool hid_is_using_usb_driver(struct hid_device *hdev)
> #else
> static inline bool hid_is_using_usb_driver(struct hid_device *hdev)
> {
>return false;
> }
> #endif
>
> but is it worth it to avoid the dependency?
>
>Arnd

I was thinking something more along the lines of the following since
the idea of per-transport helper functions was dismissed earlier:

#ifdef CONFIG_USB_HID
if (hid_is_using_ll_driver(wacom->hdev, _hid_driver)) {
[...]
}
#endif

Jason

Re: [PATCH 0/3] net-next: stmmac: support future possible different internal phy mode

[Corentin Labbe]

On Fri, Jul 28, 2017 at 03:55:44PM +0200, Andrew Lunn wrote:
> On Fri, Jul 28, 2017 at 11:28:15AM +0200, Corentin Labbe wrote:
> > Hello
> > 
> > The current way to find if the phy is internal is to compare DT phy-mode
> > and emac_variant/internal_phy.
> > But it will negate a possible future SoC where an external PHY use the
> > same phy mode than the internal one.
> > 
> > This patchs series adds a new way to find if the PHY is internal, via its
> > compatible.
> 
> http://elixir.free-electrons.com/linux/latest/source/drivers/of/of_mdio.c#L144
> 
> Since you also have "ethernet-phy-ieee802.3-c22", you won't get the
> warning. But still, your device tree gives the wrong idea.
> 
> I've probably asked this before: Does the internal PHY use a different
> PHY ID in registers 2 and 3?
> 

yes

reg2: 0x0044
reg3: 0X1500

Regards

Re: [PATCH 0/3] net-next: stmmac: support future possible different internal phy mode

[Corentin Labbe]

On Fri, Jul 28, 2017 at 03:55:44PM +0200, Andrew Lunn wrote:
> On Fri, Jul 28, 2017 at 11:28:15AM +0200, Corentin Labbe wrote:
> > Hello
> > 
> > The current way to find if the phy is internal is to compare DT phy-mode
> > and emac_variant/internal_phy.
> > But it will negate a possible future SoC where an external PHY use the
> > same phy mode than the internal one.
> > 
> > This patchs series adds a new way to find if the PHY is internal, via its
> > compatible.
> 
> http://elixir.free-electrons.com/linux/latest/source/drivers/of/of_mdio.c#L144
> 
> Since you also have "ethernet-phy-ieee802.3-c22", you won't get the
> warning. But still, your device tree gives the wrong idea.
> 
> I've probably asked this before: Does the internal PHY use a different
> PHY ID in registers 2 and 3?
> 

yes

reg2: 0x0044
reg3: 0X1500

Regards

[PATCH] fs: convert a pile of fsync routines to errseq_t based reporting

[Jeff Layton]

From: Jeff Layton 

This patch converts most of the in-kernel filesystems that do writeback
out of the pagecache to report errors using the errseq_t-based
infrastructure that was recently added. This allows them to report
errors once for each open file description.

Most filesystems have a fairly straightforward fsync operation. They
call filemap_write_and_wait_range to write back all of the data and
wait on it, and then (sometimes) sync out the metadata.

For those filesystems this is a straightforward conversion from calling
filemap_write_and_wait_range in their fsync operation to calling
file_write_and_wait_range.

Signed-off-by: Jeff Layton 
---
 arch/powerpc/platforms/cell/spufs/file.c   | 2 +-
 drivers/staging/lustre/lustre/llite/file.c | 2 +-
 drivers/video/fbdev/core/fb_defio.c| 2 +-
 fs/9p/vfs_file.c   | 4 ++--
 fs/affs/file.c | 2 +-
 fs/afs/write.c | 2 +-
 fs/cifs/file.c | 4 ++--
 fs/exofs/file.c| 2 +-
 fs/f2fs/file.c | 2 +-
 fs/hfs/inode.c | 2 +-
 fs/hfsplus/inode.c | 2 +-
 fs/hostfs/hostfs_kern.c| 2 +-
 fs/hpfs/file.c | 2 +-
 fs/jffs2/file.c| 2 +-
 fs/jfs/file.c  | 2 +-
 fs/ncpfs/file.c| 2 +-
 fs/ntfs/dir.c  | 2 +-
 fs/ntfs/file.c | 2 +-
 fs/ocfs2/file.c| 2 +-
 fs/reiserfs/dir.c  | 2 +-
 fs/reiserfs/file.c | 2 +-
 fs/ubifs/file.c| 2 +-
 22 files changed, 24 insertions(+), 24 deletions(-)

Rolling up all of these conversions into a single patch, as Christoph
Hellwig suggested. Most of these are not tested, but the conversion
here is fairly straightforward.

Any maintainers who object, please let me know and I'll yank that
part out of this patch.

diff --git a/arch/powerpc/platforms/cell/spufs/file.c 
b/arch/powerpc/platforms/cell/spufs/file.c
index ae2f740a82f1..5ffcdeb1eb17 100644
--- a/arch/powerpc/platforms/cell/spufs/file.c
+++ b/arch/powerpc/platforms/cell/spufs/file.c
@@ -1749,7 +1749,7 @@ static int spufs_mfc_flush(struct file *file, fl_owner_t 
id)
 static int spufs_mfc_fsync(struct file *file, loff_t start, loff_t end, int 
datasync)
 {
struct inode *inode = file_inode(file);
-   int err = filemap_write_and_wait_range(inode->i_mapping, start, end);
+   int err = file_write_and_wait_range(file, start, end);
if (!err) {
inode_lock(inode);
err = spufs_mfc_flush(file, NULL);
diff --git a/drivers/staging/lustre/lustre/llite/file.c 
b/drivers/staging/lustre/lustre/llite/file.c
index ab1c85c1ed38..f7d07735ac66 100644
--- a/drivers/staging/lustre/lustre/llite/file.c
+++ b/drivers/staging/lustre/lustre/llite/file.c
@@ -2364,7 +2364,7 @@ int ll_fsync(struct file *file, loff_t start, loff_t end, 
int datasync)
   PFID(ll_inode2fid(inode)), inode);
ll_stats_ops_tally(ll_i2sbi(inode), LPROC_LL_FSYNC, 1);
 
-   rc = filemap_write_and_wait_range(inode->i_mapping, start, end);
+   rc = file_write_and_wait_range(file, start, end);
inode_lock(inode);
 
/* catch async errors that were recorded back when async writeback
diff --git a/drivers/video/fbdev/core/fb_defio.c 
b/drivers/video/fbdev/core/fb_defio.c
index 37f69c061210..487d5e336e1b 100644
--- a/drivers/video/fbdev/core/fb_defio.c
+++ b/drivers/video/fbdev/core/fb_defio.c
@@ -69,7 +69,7 @@ int fb_deferred_io_fsync(struct file *file, loff_t start, 
loff_t end, int datasy
 {
struct fb_info *info = file->private_data;
struct inode *inode = file_inode(file);
-   int err = filemap_write_and_wait_range(inode->i_mapping, start, end);
+   int err = file_write_and_wait_range(file, start, end);
if (err)
return err;
 
diff --git a/fs/9p/vfs_file.c b/fs/9p/vfs_file.c
index 3de3b4a89d89..4802d75b3cf7 100644
--- a/fs/9p/vfs_file.c
+++ b/fs/9p/vfs_file.c
@@ -445,7 +445,7 @@ static int v9fs_file_fsync(struct file *filp, loff_t start, 
loff_t end,
struct p9_wstat wstat;
int retval;
 
-   retval = filemap_write_and_wait_range(inode->i_mapping, start, end);
+   retval = file_write_and_wait_range(filp, start, end);
if (retval)
return retval;
 
@@ -468,7 +468,7 @@ int v9fs_file_fsync_dotl(struct file *filp, loff_t start, 
loff_t end,
struct inode *inode = filp->f_mapping->host;
int retval;
 
-   retval = filemap_write_and_wait_range(inode->i_mapping, start, end);
+   retval = file_write_and_wait_range(filp, start, end);
if (retval)
return retval;
 
diff --git a/fs/affs/file.c 

[PATCH] fs: convert a pile of fsync routines to errseq_t based reporting

[Jeff Layton]

From: Jeff Layton 

This patch converts most of the in-kernel filesystems that do writeback
out of the pagecache to report errors using the errseq_t-based
infrastructure that was recently added. This allows them to report
errors once for each open file description.

Most filesystems have a fairly straightforward fsync operation. They
call filemap_write_and_wait_range to write back all of the data and
wait on it, and then (sometimes) sync out the metadata.

For those filesystems this is a straightforward conversion from calling
filemap_write_and_wait_range in their fsync operation to calling
file_write_and_wait_range.

Signed-off-by: Jeff Layton 
---
 arch/powerpc/platforms/cell/spufs/file.c   | 2 +-
 drivers/staging/lustre/lustre/llite/file.c | 2 +-
 drivers/video/fbdev/core/fb_defio.c| 2 +-
 fs/9p/vfs_file.c   | 4 ++--
 fs/affs/file.c | 2 +-
 fs/afs/write.c | 2 +-
 fs/cifs/file.c | 4 ++--
 fs/exofs/file.c| 2 +-
 fs/f2fs/file.c | 2 +-
 fs/hfs/inode.c | 2 +-
 fs/hfsplus/inode.c | 2 +-
 fs/hostfs/hostfs_kern.c| 2 +-
 fs/hpfs/file.c | 2 +-
 fs/jffs2/file.c| 2 +-
 fs/jfs/file.c  | 2 +-
 fs/ncpfs/file.c| 2 +-
 fs/ntfs/dir.c  | 2 +-
 fs/ntfs/file.c | 2 +-
 fs/ocfs2/file.c| 2 +-
 fs/reiserfs/dir.c  | 2 +-
 fs/reiserfs/file.c | 2 +-
 fs/ubifs/file.c| 2 +-
 22 files changed, 24 insertions(+), 24 deletions(-)

Rolling up all of these conversions into a single patch, as Christoph
Hellwig suggested. Most of these are not tested, but the conversion
here is fairly straightforward.

Any maintainers who object, please let me know and I'll yank that
part out of this patch.

diff --git a/arch/powerpc/platforms/cell/spufs/file.c 
b/arch/powerpc/platforms/cell/spufs/file.c
index ae2f740a82f1..5ffcdeb1eb17 100644
--- a/arch/powerpc/platforms/cell/spufs/file.c
+++ b/arch/powerpc/platforms/cell/spufs/file.c
@@ -1749,7 +1749,7 @@ static int spufs_mfc_flush(struct file *file, fl_owner_t 
id)
 static int spufs_mfc_fsync(struct file *file, loff_t start, loff_t end, int 
datasync)
 {
struct inode *inode = file_inode(file);
-   int err = filemap_write_and_wait_range(inode->i_mapping, start, end);
+   int err = file_write_and_wait_range(file, start, end);
if (!err) {
inode_lock(inode);
err = spufs_mfc_flush(file, NULL);
diff --git a/drivers/staging/lustre/lustre/llite/file.c 
b/drivers/staging/lustre/lustre/llite/file.c
index ab1c85c1ed38..f7d07735ac66 100644
--- a/drivers/staging/lustre/lustre/llite/file.c
+++ b/drivers/staging/lustre/lustre/llite/file.c
@@ -2364,7 +2364,7 @@ int ll_fsync(struct file *file, loff_t start, loff_t end, 
int datasync)
   PFID(ll_inode2fid(inode)), inode);
ll_stats_ops_tally(ll_i2sbi(inode), LPROC_LL_FSYNC, 1);
 
-   rc = filemap_write_and_wait_range(inode->i_mapping, start, end);
+   rc = file_write_and_wait_range(file, start, end);
inode_lock(inode);
 
/* catch async errors that were recorded back when async writeback
diff --git a/drivers/video/fbdev/core/fb_defio.c 
b/drivers/video/fbdev/core/fb_defio.c
index 37f69c061210..487d5e336e1b 100644
--- a/drivers/video/fbdev/core/fb_defio.c
+++ b/drivers/video/fbdev/core/fb_defio.c
@@ -69,7 +69,7 @@ int fb_deferred_io_fsync(struct file *file, loff_t start, 
loff_t end, int datasy
 {
struct fb_info *info = file->private_data;
struct inode *inode = file_inode(file);
-   int err = filemap_write_and_wait_range(inode->i_mapping, start, end);
+   int err = file_write_and_wait_range(file, start, end);
if (err)
return err;
 
diff --git a/fs/9p/vfs_file.c b/fs/9p/vfs_file.c
index 3de3b4a89d89..4802d75b3cf7 100644
--- a/fs/9p/vfs_file.c
+++ b/fs/9p/vfs_file.c
@@ -445,7 +445,7 @@ static int v9fs_file_fsync(struct file *filp, loff_t start, 
loff_t end,
struct p9_wstat wstat;
int retval;
 
-   retval = filemap_write_and_wait_range(inode->i_mapping, start, end);
+   retval = file_write_and_wait_range(filp, start, end);
if (retval)
return retval;
 
@@ -468,7 +468,7 @@ int v9fs_file_fsync_dotl(struct file *filp, loff_t start, 
loff_t end,
struct inode *inode = filp->f_mapping->host;
int retval;
 
-   retval = filemap_write_and_wait_range(inode->i_mapping, start, end);
+   retval = file_write_and_wait_range(filp, start, end);
if (retval)
return retval;
 
diff --git a/fs/affs/file.c b/fs/affs/file.c
index 196ee7f6fdc4..00331810f690