[PATCH v5 2/2] leds: lm3692x: Introduce LM3692x dual string driver

[Dan Murphy]

Introducing the LM3692x Dual-String white LED driver.

Data sheet is located
http://www.ti.com/lit/ds/snvsa29/snvsa29.pdf

Signed-off-by: Dan Murphy 
---
v5 - Added OF dependency in Kconfig, added extra fault flag read to ensure that
if a fault exists and it is not a artifact, fixed LED class label to be derived
from either the DT child "label" node or create a label based on 
parent_node_name:led color:trigger, removed ifdef for CONFIG_OF and removed
of_match_ptr - https://patchwork.kernel.org/patch/10081073/

v4 - Converted to devm led class register, changed MODULE_LICENSE to GPL v2, 
set the led name based on child node name or label entry, removed fault and
returned read_buf for fault checking, added mutex_destroy to remove function,
and removed LED_FULL - https://patchwork.kernel.org/patch/10060109/
v3 - Add missing Makefile and Kconfig from v1 and v2 - 
https://patchwork.kernel.org/patch/10060075/
v2 - Added data sheet link, fixed linuxdoc format, returned on failure in init
routine, return on fault_check failure, updated brightness calculation and
fixed capitalization issue - https://patchwork.kernel.org/patch/10056675/

 drivers/leds/Kconfig|   7 +
 drivers/leds/Makefile   |   1 +
 drivers/leds/leds-lm3692x.c | 396 
 3 files changed, 404 insertions(+)
 create mode 100644 drivers/leds/leds-lm3692x.c

diff --git a/drivers/leds/Kconfig b/drivers/leds/Kconfig
index 318a28fd58fe..1d215b39cefd 100644
--- a/drivers/leds/Kconfig
+++ b/drivers/leds/Kconfig
@@ -137,6 +137,13 @@ config LEDS_LM3642
  converter plus 1.5A constant current driver for a high-current
  white LED.
 
+config LEDS_LM3692X
+   tristate "LED support for LM3692x Chips"
+   depends on LEDS_CLASS && I2C && OF
+   select REGMAP_I2C
+   help
+ This option enables support for the TI LM3692x family
+ of white LED string drivers used for backlighting.
 
 config LEDS_LOCOMO
tristate "LED Support for Locomo device"
diff --git a/drivers/leds/Makefile b/drivers/leds/Makefile
index a2a6b5a4f86d..987884a5b9a5 100644
--- a/drivers/leds/Makefile
+++ b/drivers/leds/Makefile
@@ -74,6 +74,7 @@ obj-$(CONFIG_LEDS_PM8058) += leds-pm8058.o
 obj-$(CONFIG_LEDS_MLXCPLD) += leds-mlxcpld.o
 obj-$(CONFIG_LEDS_NIC78BX) += leds-nic78bx.o
 obj-$(CONFIG_LEDS_MT6323)  += leds-mt6323.o
+obj-$(CONFIG_LEDS_LM3692X) += leds-lm3692x.o
 
 # LED SPI Drivers
 obj-$(CONFIG_LEDS_DAC124S085)  += leds-dac124s085.o
diff --git a/drivers/leds/leds-lm3692x.c b/drivers/leds/leds-lm3692x.c
new file mode 100644
index ..70c974e06bd7
--- /dev/null
+++ b/drivers/leds/leds-lm3692x.c
@@ -0,0 +1,396 @@
+/*
+ * TI lm3692x LED Driver
+ *
+ * Copyright (C) 2017 Texas Instruments
+ *
+ * Author: Dan Murphy 
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License
+ * version 2 as published by the Free Software Foundation.
+ *
+ * Data sheet is located
+ * http://www.ti.com/lit/ds/snvsa29/snvsa29.pdf
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#define LM3692X_REV0x0
+#define LM3692X_RESET  0x1
+#define LM3692X_EN 0x10
+#define LM3692X_BRT_CTRL   0x11
+#define LM3692X_PWM_CTRL   0x12
+#define LM3692X_BOOST_CTRL 0x13
+#define LM3692X_AUTO_FREQ_HI   0x15
+#define LM3692X_AUTO_FREQ_LO   0x16
+#define LM3692X_BL_ADJ_THRESH  0x17
+#define LM3692X_BRT_LSB0x18
+#define LM3692X_BRT_MSB0x19
+#define LM3692X_FAULT_CTRL 0x1e
+#define LM3692X_FAULT_FLAGS0x1f
+
+#define LM3692X_SW_RESET   BIT(0)
+#define LM3692X_DEVICE_EN  BIT(0)
+#define LM3692X_LED1_ENBIT(1)
+#define LM3692X_LED2_ENBIT(2)
+
+/* Brightness Control Bits */
+#define LM3692X_BL_ADJ_POL BIT(0)
+#define LM3692X_RAMP_RATE_125us0x00
+#define LM3692X_RAMP_RATE_250usBIT(1)
+#define LM3692X_RAMP_RATE_500us BIT(2)
+#define LM3692X_RAMP_RATE_1ms  (BIT(1) | BIT(2))
+#define LM3692X_RAMP_RATE_2ms  BIT(3)
+#define LM3692X_RAMP_RATE_4ms  (BIT(3) | BIT(1))
+#define LM3692X_RAMP_RATE_8ms  (BIT(2) | BIT(3))
+#define LM3692X_RAMP_RATE_16ms (BIT(1) | BIT(2) | BIT(3))
+#define LM3692X_RAMP_ENBIT(4)
+#define LM3692X_BRHT_MODE_REG  0x00
+#define LM3692X_BRHT_MODE_PWM  BIT(5)
+#define LM3692X_BRHT_MODE_MULTI_RAMP BIT(6)
+#define LM3692X_BRHT_MODE_RAMP_MULTI (BIT(5) | BIT(6))
+#define LM3692X_MAP_MODE_EXP   BIT(7)
+
+/* PWM Register Bits */
+#define LM3692X_PWM_FILTER_100 BIT(0)
+#define LM3692X_PWM_FILTER_150 BIT(1)
+#define LM3692X_PWM_FILTER_200 (BIT(0) | BIT(1))
+#define LM3692X_PWM_HYSTER_1LSB BIT(2)
+#define LM3692X_PWM_HYSTER_2LSBBIT(3)
+#define LM3692X_PWM_HYSTER_3LSB (BIT(3) | BIT(2))
+#define LM3692X_PWM_HYSTER_4LSB BIT(4)
+#define LM3692X_PWM_HY

[PATCH v5 1/2] dt: bindings: lm3692x: Add bindings for lm3692x LED driver

[Dan Murphy]

This adds the devicetree bindings for the LM3692x
I2C LED string driver.

Acked-by: Pavel Machek 
Signed-off-by: Dan Murphy 
---

v5 - No Changes - https://patchwork.kernel.org/patch/10081071/

v4 - Fix example node, added trigger entry, removed ambiguous x for compatible 
and
added common.txt pointer for label - https://patchwork.kernel.org/patch/10060107
v3 - No changes
v2 - No changes - https://patchwork.kernel.org/patch/10056677/

 .../devicetree/bindings/leds/leds-lm3692x.txt  | 39 ++
 1 file changed, 39 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/leds/leds-lm3692x.txt

diff --git a/Documentation/devicetree/bindings/leds/leds-lm3692x.txt 
b/Documentation/devicetree/bindings/leds/leds-lm3692x.txt
new file mode 100644
index ..c259cde2226f
--- /dev/null
+++ b/Documentation/devicetree/bindings/leds/leds-lm3692x.txt
@@ -0,0 +1,39 @@
+* Texas Instruments - LM3692x Highly Efficient White LED Driver
+
+The LM3692x is an ultra-compact, highly efficient,
+white-LED driver designed for LCD display backlighting.
+
+The main difference between the LM36922 and LM36923 is the number of
+LED strings it supports.  The LM36922 supports two strings while the LM36923
+supports three strings.
+
+Required properties:
+   - compatible:
+   "ti,lm36922"
+   "ti,lm36923"
+   - reg :  I2C slave address
+
+Optional properties:
+   - label : see Documentation/devicetree/bindings/leds/common.txt
+   - enable-gpios : gpio pin to enable/disable the device.
+   - vled-supply : LED supply
+   - linux,default-trigger : (optional)
+  see Documentation/devicetree/bindings/leds/common.txt
+
+Example:
+
+lm3692x@36 {
+   compatible = "ti,lm3692x";
+   reg = <0x36>;
+
+   enable-gpios = <&gpio1 28 GPIO_ACTIVE_HIGH>;
+   vled-supply = <&vbatt>;
+
+   backlight: backlight@0 {
+   label = "backlight_cluster";
+   linux,default-trigger = "backlight";
+   };
+}
+
+For more product information please see the link below:
+http://www.ti.com/lit/ds/snvsa29/snvsa29.pdf
-- 
2.15.0.124.g7668cbc60

Re: [PATCH v4 2/2] leds: lm3692x: Introduce LM3692x dual string driver

[Dan Murphy]

Jacek

Thanks for the review

On 11/29/2017 03:52 PM, Jacek Anaszewski wrote:
> Hi Dan,
> 
> Thanks for the update.
> 
> On 11/28/2017 09:40 PM, Dan Murphy wrote:
>> Introducing the LM3692x Dual-String white LED driver.
>>
>> Data sheet is located
>> http://www.ti.com/lit/ds/snvsa29/snvsa29.pdf
>>
>> Signed-off-by: Dan Murphy 
>> ---
>> v4 - Converted to devm led class register, changed MODULE_LICENSE to GPL v2, 
>> set the led name based on child node name or label entry, removed fault and
>> returned read_buf for fault checking, added mutex_destroy to remove function,
>> and removed LED_FULL - https://patchwork.kernel.org/patch/10060109/
>>
>> v3 - Add missing Makefile and Kconfig from v1 and v2 - 
>> https://patchwork.kernel.org/patch/10060075/
>> v2 - Added data sheet link, fixed linuxdoc format, returned on failure in 
>> init
>> routine, return on fault_check failure, updated brightness calculation and
>> fixed capitalization issue - https://patchwork.kernel.org/patch/10056675/
>>
>>  drivers/leds/Kconfig|   7 +
>>  drivers/leds/Makefile   |   1 +
>>  drivers/leds/leds-lm3692x.c | 382 
>> 
>>  3 files changed, 390 insertions(+)
>>  create mode 100644 drivers/leds/leds-lm3692x.c
>>
>> diff --git a/drivers/leds/Kconfig b/drivers/leds/Kconfig
>> index 318a28fd58fe..c0583f1bc8ea 100644
>> --- a/drivers/leds/Kconfig
>> +++ b/drivers/leds/Kconfig
>> @@ -137,6 +137,13 @@ config LEDS_LM3642
>>converter plus 1.5A constant current driver for a high-current
>>white LED.
>>  
>> +config LEDS_LM3692X
>> +tristate "LED support for LM3692x Chips"
>> +depends on LEDS_CLASS && I2C
>> +select REGMAP_I2C
>> +help
>> +  This option enables support for the TI LM3692x family
>> +  of white LED string drivers used for backlighting.
>>  
>>  config LEDS_LOCOMO
>>  tristate "LED Support for Locomo device"
>> diff --git a/drivers/leds/Makefile b/drivers/leds/Makefile
>> index a2a6b5a4f86d..987884a5b9a5 100644
>> --- a/drivers/leds/Makefile
>> +++ b/drivers/leds/Makefile
>> @@ -74,6 +74,7 @@ obj-$(CONFIG_LEDS_PM8058)  += leds-pm8058.o
>>  obj-$(CONFIG_LEDS_MLXCPLD)  += leds-mlxcpld.o
>>  obj-$(CONFIG_LEDS_NIC78BX)  += leds-nic78bx.o
>>  obj-$(CONFIG_LEDS_MT6323)   += leds-mt6323.o
>> +obj-$(CONFIG_LEDS_LM3692X)  += leds-lm3692x.o
>>  
>>  # LED SPI Drivers
>>  obj-$(CONFIG_LEDS_DAC124S085)   += leds-dac124s085.o
>> diff --git a/drivers/leds/leds-lm3692x.c b/drivers/leds/leds-lm3692x.c
>> new file mode 100644
>> index ..fcf0573fb985
>> --- /dev/null
>> +++ b/drivers/leds/leds-lm3692x.c
>> @@ -0,0 +1,382 @@
>> +/*
>> + * TI lm3692x LED Driver
>> + *
>> + * Copyright (C) 2017 Texas Instruments
>> + *
>> + * Author: Dan Murphy 
>> + *
>> + * This program is free software; you can redistribute it and/or
>> + * modify it under the terms of the GNU General Public License
>> + * version 2 as published by the Free Software Foundation.
>> + *
>> + * Data sheet is located
>> + * http://www.ti.com/lit/ds/snvsa29/snvsa29.pdf
>> + */
>> +
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +
>> +#define LM3692X_REV 0x0
>> +#define LM3692X_RESET   0x1
>> +#define LM3692X_EN  0x10
>> +#define LM3692X_BRT_CTRL0x11
>> +#define LM3692X_PWM_CTRL0x12
>> +#define LM3692X_BOOST_CTRL  0x13
>> +#define LM3692X_AUTO_FREQ_HI0x15
>> +#define LM3692X_AUTO_FREQ_LO0x16
>> +#define LM3692X_BL_ADJ_THRESH   0x17
>> +#define LM3692X_BRT_LSB 0x18
>> +#define LM3692X_BRT_MSB 0x19
>> +#define LM3692X_FAULT_CTRL  0x1e
>> +#define LM3692X_FAULT_FLAGS 0x1f
>> +
>> +#define LM3692X_SW_RESETBIT(0)
>> +#define LM3692X_DEVICE_EN   BIT(0)
>> +#define LM3692X_LED1_EN BIT(1)
>> +#define LM3692X_LED2_EN BIT(2)
>> +
>> +/* Brightness Control Bits */
>> +#define LM3692X_BL_ADJ_POL  BIT(0)
>> +#define LM3692X_RAMP_RATE_125us 0x00
>> +#define LM3692X_RAMP_RATE_250us BIT(1)
>> +#define LM3692X_RAMP_RATE_500us BIT(2)
>> +#define LM3692X_RAMP_RATE_1ms   (BIT(1) | BIT(2))
>> +#define LM3692X_RAMP_RATE_2ms   BIT(3)
>> +#define LM3692X_RAMP_RATE_4ms   (BIT(3) | BIT(1))
>> +#define LM3692X_RAMP_RATE_8ms   (BIT(2) | BIT(3))
>> +#define LM3692X_RAMP_RATE_16ms  (BIT(1) | BIT(2) | BIT(3))
>> +#define LM3692X_RAMP_EN BIT(4)
>> +#define LM3692X_BRHT_MODE_REG   0x00
>> +#define LM3692X_BRHT_MODE_PWM   BIT(5)
>> +#define LM3692X_BRHT_MODE_MULTI_RAMP BIT(6)
>> +#define LM3692X_BRHT_MODE_RAMP_MULTI (BIT(5) | BIT(6))
>> +#define LM3692X_MAP_MODE_EXPBIT(7)
>> +
>> +/* PWM Register Bits */
>> +#define LM3692X_PWM_FILTER_100  BIT(0)
>> +#define LM3692X_PWM_FILTER_150  BIT(1)
>> +#define LM3692X_PWM_FILTER_200  (BIT(0) | BIT(1))
>> +#define LM3692X_PWM_HYSTER_1LSB

Re: [PATCH v8 07/13] slimbus: Add support for 'clock-pause' feature

[Philippe Ombredanne]

On Thu, Nov 30, 2017 at 6:41 PM,   wrote:
[]
> diff --git a/drivers/slimbus/sched.c b/drivers/slimbus/sched.c
> new file mode 100644
> index ..74300f1a6898
> --- /dev/null
> +++ b/drivers/slimbus/sched.c
> @@ -0,0 +1,128 @@
> +/* Copyright (c) 2011-2016, The Linux Foundation. All rights reserved.
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License version 2 and
> + * only version 2 as published by the Free Software Foundation.
> + *
> + * This program is distributed in the hope that it will be useful,
> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
> + * GNU General Public License for more details.

Could it make sense to use the new SPDX ids here? e.g.

> +// SPDX-License-Identifier: GPL-2.0
> +// Copyright (c) 2011-2016, The Linux Foundation

This neat and cleaner, is it?
See tglx doc posted as patches and Linus comments for a rationale on
the comment styles.
--
Cordially
Philippe Ombredanne

Re: [PATCH v4 01/12] perf util: Create rblist__reset() function

[Arnaldo Carvalho de Melo]

Em Thu, Nov 30, 2017 at 07:56:31PM +0800, Jin Yao escreveu:
> Currently we have a rblist__delete() which is used to delete a rblist.
> While rblist__delete() will free the pointer of rblist at the end.
> 
> It's inconvenience for user to delete a rblist which is not allocated
> by something like malloc(). For example, the rblist is defined in a
> data structure.

> This patch creates a new function rblist__reset() which function is
> similar as rblist__delete() but it will not free the rblist.

So, we've been using, mostly consistently:

int foo__init(struct foo *foo)
{
foo->a = 1;
foo->b = malloc(10);
if (foo->b == NULL)
return -1;
return 0;
}

struct foo *foo__new(parameters)
{
struct foo *foo = zalloc(sizeof(*foo));

if (foo && foo__init(foo))
goto out_delete;

return foo;
out_delete:
foo__delete(foo);
return NULL);
}

void foo__exit(struct foo *foo)
{
zfree(&foo->b);
}

void foo__delete(struct foo *foo)
{
if (!foo)
return;

foo__exit(foo);
free(foo);
}

So, please use delete+exit and new+init, i.e. replace 'reset' with
'exit' and 'free' with 'delete' (I saw this case in another patch), for
us to try and make all this more consistent, ok?

Thanks,

- Arnaldo
 
> Signed-off-by: Jin Yao 
> ---
>  tools/perf/util/rblist.c | 24 +---
>  tools/perf/util/rblist.h |  1 +
>  2 files changed, 18 insertions(+), 7 deletions(-)
> 
> diff --git a/tools/perf/util/rblist.c b/tools/perf/util/rblist.c
> index 0dfe27d..eafa663 100644
> --- a/tools/perf/util/rblist.c
> +++ b/tools/perf/util/rblist.c
> @@ -101,20 +101,30 @@ void rblist__init(struct rblist *rblist)
>   return;
>  }
>  
> +static void remove_nodes(struct rblist *rblist)
> +{
> + struct rb_node *pos, *next = rb_first(&rblist->entries);
> +
> + while (next) {
> + pos = next;
> + next = rb_next(pos);
> + rblist__remove_node(rblist, pos);
> + }
> +}
> +
>  void rblist__delete(struct rblist *rblist)
>  {
>   if (rblist != NULL) {
> - struct rb_node *pos, *next = rb_first(&rblist->entries);
> -
> - while (next) {
> - pos = next;
> - next = rb_next(pos);
> - rblist__remove_node(rblist, pos);
> - }
> + remove_nodes(rblist);
>   free(rblist);
>   }
>  }
>  
> +void rblist__reset(struct rblist *rblist)
> +{
> + remove_nodes(rblist);
> +}
> +
>  struct rb_node *rblist__entry(const struct rblist *rblist, unsigned int idx)
>  {
>   struct rb_node *node;
> diff --git a/tools/perf/util/rblist.h b/tools/perf/util/rblist.h
> index 4c8638a..048c285 100644
> --- a/tools/perf/util/rblist.h
> +++ b/tools/perf/util/rblist.h
> @@ -35,6 +35,7 @@ void rblist__remove_node(struct rblist *rblist, struct 
> rb_node *rb_node);
>  struct rb_node *rblist__find(struct rblist *rblist, const void *entry);
>  struct rb_node *rblist__findnew(struct rblist *rblist, const void *entry);
>  struct rb_node *rblist__entry(const struct rblist *rblist, unsigned int idx);
> +void rblist__reset(struct rblist *rblist);
>  
>  static inline bool rblist__empty(const struct rblist *rblist)
>  {
> -- 
> 2.7.4

Re: [PATCH] rxrpc: Neaten logging macros and add KERN_DEBUG logging level

[David Howells]

Joe Perches  wrote:

> There is no listed rxrpc maintainer.

There's a script in the kernel called get_maintainer.pl which you might find
of use:

warthog>./scripts/get_maintainer.pl net/rxrpc/
"David S. Miller"  (maintainer:NETWORKING 
[GENERAL],commit_signer:23/74=31%)
David Howells  
(commit_signer:64/74=86%,authored:60/74=81%)
net...@vger.kernel.org (open list:NETWORKING [GENERAL])
linux-kernel@vger.kernel.org (open list)

It would seem a good idea to cc me, as the one with the largest "authored"
also.

David

Re: [PATCH RFC 2/2] mm, hugetlb: do not rely on overcommit limit during migration

[Mike Kravetz]

On 11/29/2017 11:57 PM, Michal Hocko wrote:
> On Wed 29-11-17 11:52:53, Mike Kravetz wrote:
>> On 11/29/2017 01:22 AM, Michal Hocko wrote:
>>> What about this on top. I haven't tested this yet though.
>>
>> Yes, this would work.
>>
>> However, I think a simple modification to your previous free_huge_page
>> changes would make this unnecessary.  I was confused in your previous
>> patch because you decremented the per-node surplus page count, but not
>> the global count.  I think it would have been correct (and made this
>> patch unnecessary) if you decremented the global counter there as well.
> 
> We cannot really increment the global counter because the over number of
> surplus pages during migration doesn't increase.

I was not suggesting we increment the global surplus count.  Rather,
your previous patch should have decremented the global surplus count in
free_huge_page.  Something like:

@@ -1283,7 +1283,13 @@ void free_huge_page(struct page *page)
if (restore_reserve)
h->resv_huge_pages++;
 
-   if (h->surplus_huge_pages_node[nid]) {
+   if (PageHugeTemporary(page)) {
+   list_del(&page->lru);
+   ClearPageHugeTemporary(page);
+   update_and_free_page(h, page);
+   if (h->surplus_huge_pages_node[nid])
+   h->surplus_huge_pages--;
+   h->surplus_huge_pages_node[nid]--;
+   }
+   } else if (h->surplus_huge_pages_node[nid]) {
/* remove the page from active list */
list_del(&page->lru);
update_and_free_page(h, page);

When we allocate one of these 'PageHugeTemporary' pages, we only increment
the global and node specific nr_huge_pages counters.  To me, this makes all
the huge page counters be the same as if there were simply one additional
pre-allocated huge page.  This 'extra' (PageHugeTemporary) page will go
away when free_huge_page is called.  So, my thought is that it is not
necessary to transfer per-node counts from the original to target node.
Of course, I may be missing something.

When thinking about transfering per-node counts as is done in your latest
patch, I took another look at all the per-node counts.  This may show my
ignorance of huge page migration, but do we need to handle the case where
the page being migrated is 'free'?  Is that possible?  If so, there will
be a count for free_huge_pages_node and the page will be on the per node
hugepage_freelists that must be handled

-- 
Mike Kravetz

[PATCH 2/2] bnxt_en: Add ETH_RESET_AP support

[Scott Branden]

Add ETH_RESET_AP support handling to reset the internal
Application Processor(s) of the SmartNIC card.

Signed-off-by: Scott Branden 
---
 drivers/net/ethernet/broadcom/bnxt/bnxt_ethtool.c | 11 +++
 drivers/net/ethernet/broadcom/bnxt/bnxt_ethtool.h |  1 +
 2 files changed, 12 insertions(+)

diff --git a/drivers/net/ethernet/broadcom/bnxt/bnxt_ethtool.c 
b/drivers/net/ethernet/broadcom/bnxt/bnxt_ethtool.c
index 7ce1d4b..fc2c483 100644
--- a/drivers/net/ethernet/broadcom/bnxt/bnxt_ethtool.c
+++ b/drivers/net/ethernet/broadcom/bnxt/bnxt_ethtool.c
@@ -1376,6 +1376,9 @@ static int bnxt_firmware_reset(struct net_device *dev,
req.embedded_proc_type = FW_RESET_REQ_EMBEDDED_PROC_TYPE_CHIP;
req.selfrst_status = FW_RESET_REQ_SELFRST_STATUS_SELFRSTASAP;
break;
+   case BNXT_FW_RESET_AP:
+   req.embedded_proc_type = FW_RESET_REQ_EMBEDDED_PROC_TYPE_AP;
+   break;
default:
return -EINVAL;
}
@@ -2522,6 +2525,14 @@ static int bnxt_reset(struct net_device *dev, u32 *flags)
rc = bnxt_firmware_reset(dev, BNXT_FW_RESET_CHIP);
if (!rc)
netdev_info(dev, "Reset request successful. Reload 
driver to complete reset\n");
+   } else if (*flags == ETH_RESET_AP) {
+   /* This feature is not supported in older firmware versions */
+   if (bp->hwrm_spec_code < 0x10803)
+   return -EOPNOTSUPP;
+
+   rc = bnxt_firmware_reset(dev, BNXT_FW_RESET_AP);
+   if (!rc)
+   netdev_info(dev, "Reset Application Processor request 
successful.\n");
} else {
rc = -EINVAL;
}
diff --git a/drivers/net/ethernet/broadcom/bnxt/bnxt_ethtool.h 
b/drivers/net/ethernet/broadcom/bnxt/bnxt_ethtool.h
index ff601b4..836ef68 100644
--- a/drivers/net/ethernet/broadcom/bnxt/bnxt_ethtool.h
+++ b/drivers/net/ethernet/broadcom/bnxt/bnxt_ethtool.h
@@ -34,6 +34,7 @@ struct bnxt_led_cfg {
 #define BNXT_LED_DFLT_ENABLES(x)   \
cpu_to_le32(BNXT_LED_DFLT_ENA << (BNXT_LED_DFLT_ENA_SHIFT * (x)))
 
+#define BNXT_FW_RESET_AP   0xfffe
 #define BNXT_FW_RESET_CHIP 0x
 
 extern const struct ethtool_ops bnxt_ethtool_ops;
-- 
2.5.0

[PATCH 1/2] net: ethtool: add support for reset of AP inside NIC interface.

[Scott Branden]

Add ETH_RESET_AP to reset the application processor(s) inside the NIC
interface.

Current ETH_RESET_MGMT supports a management processor inside this NIC.
This is typically used for remote NIC management purposes.

Application processors exist inside some SmartNICs to run various
applications inside the NIC processor - be it a simple algorithm without
an OS to as complex as hosting multiple VMs.

Signed-off-by: Scott Branden 
Reviewed-by: Andrew Lunn 
---
 include/uapi/linux/ethtool.h | 1 +
 1 file changed, 1 insertion(+)

diff --git a/include/uapi/linux/ethtool.h b/include/uapi/linux/ethtool.h
index ac71559..44a0b67 100644
--- a/include/uapi/linux/ethtool.h
+++ b/include/uapi/linux/ethtool.h
@@ -1686,6 +1686,7 @@ enum ethtool_reset_flags {
ETH_RESET_PHY   = 1 << 6,   /* Transceiver/PHY */
ETH_RESET_RAM   = 1 << 7,   /* RAM shared between
 * multiple components */
+   ETH_RESET_AP= 1 << 8,   /* Application processor */
 
ETH_RESET_DEDICATED = 0x,   /* All components dedicated to
 * this interface */
-- 
2.5.0

[PATCH 0/2] net: ethtool: add support for ETH_RESET_AP

[Scott Branden]

Add support to reset appplication processors inside SmartNICs by
defining new ETH_RESET_AP bit.

And use new ETH_RESET_AP bit in bnxt ethernet driver.

Scott Branden (2):
  net: ethtool: add support for reset of AP inside NIC interface.
  bnxt_en: Add ETH_RESET_AP support

 drivers/net/ethernet/broadcom/bnxt/bnxt_ethtool.c | 11 +++
 drivers/net/ethernet/broadcom/bnxt/bnxt_ethtool.h |  1 +
 include/uapi/linux/ethtool.h  |  1 +
 3 files changed, 13 insertions(+)

-- 
2.5.0

Re: BUG: KASAN: slab-out-of-bounds in perf_callchain_user+0x494/0x530

[Arnaldo Carvalho de Melo]

Em Thu, Nov 30, 2017 at 09:20:26AM +0100, Peter Zijlstra escreveu:
> On Thu, Nov 30, 2017 at 10:32:19AM +0800, Fengguang Wu wrote:
> > Hello,
> > 
> > FYI this happens in mainline kernel 4.15.0-rc1.
> > It looks like a new regression and hard to bisect.
> > 
> > It occurs in 1 out of 57 boots.
> > 
> > [   10.009610] chown (367) used greatest stack depth: 26944 bytes left
> > Kernel tests: Boot OK!
> > [   30.357729] trinity-main uses obsolete (PF_INET,SOCK_PACKET)
> > [   31.301433] sock: process `trinity-main' is using obsolete setsockopt 
> > SO_BSDCOMPAT
> > [   31.310289] 
> > ==
> > [   31.311490] BUG: KASAN: slab-out-of-bounds in 
> > perf_callchain_user+0x494/0x530:
> > perf_callchain_store at 
> > include/linux/perf_event.h:1128
> >  (inlined by) 
> > perf_callchain_user at arch/x86/events/core.c:2485
> 
> I don't think we recently changed anything here...
> 
> But I do have vague memories of something being off here; I never quite
> could penetrate the max_stack / contexts_maxed stuff, and istr acme was
> going to have a peek.
 
Sure, but I saw some backward ring buffer stuff in there as well, no?
IIRC that came after the max-stack code, Adding Wang to the CC list.

- Arnaldo

Re: [PATCH v18 06/10] virtio_ring: add a new API, virtqueue_add_one_desc

[Michael S. Tsirkin]

On Wed, Nov 29, 2017 at 09:55:22PM +0800, Wei Wang wrote:
> Current virtqueue_add API implementation is based on the scatterlist
> struct, which uses kaddr. This is inadequate to all the use case of
> vring. For example:
> - Some usages don't use IOMMU, in this case the user can directly pass
>   in a physical address in hand, instead of going through the sg
>   implementation (e.g. the VIRTIO_BALLOON_F_SG feature)
> - Sometimes, a guest physical page may not have a kaddr (e.g. high
>   memory) but need to use vring (e.g. the VIRTIO_BALLOON_F_FREE_PAGE_VQ
>   feature)
> 
> The new API virtqueue_add_one_desc enables the caller to assign a vring
> desc with a physical address and len. Also, factor out the common code
> with virtqueue_add in vring_set_avail.
> 
> Signed-off-by: Wei Wang 
> Cc: Michael S. Tsirkin 

You previously managed without this patch, and it's preferable
IMHO since this patchset is already too big.

I don't really understand what is wrong with virtio_add_sgs + sg_set_page.
I don't think is assumes a kaddr.

> ---
>  drivers/virtio/virtio_ring.c | 94 
> +++-
>  include/linux/virtio.h   |  6 +++
>  2 files changed, 81 insertions(+), 19 deletions(-)
> 
> diff --git a/drivers/virtio/virtio_ring.c b/drivers/virtio/virtio_ring.c
> index eb30f3e..0b87123 100644
> --- a/drivers/virtio/virtio_ring.c
> +++ b/drivers/virtio/virtio_ring.c
> @@ -257,6 +257,79 @@ static struct vring_desc *alloc_indirect(struct 
> virtqueue *_vq,
>   return desc;
>  }
>  
> +static void vring_set_avail(struct virtqueue *_vq,
> + unsigned int i)
> +{
> + struct vring_virtqueue *vq = to_vvq(_vq);
> + unsigned int avail;
> +
> + avail = vq->avail_idx_shadow & (vq->vring.num - 1);
> + vq->vring.avail->ring[avail] = cpu_to_virtio16(_vq->vdev, i);
> +
> + /*
> +  * Descriptors and available array need to be set before we expose the
> +  * new available array entries.
> +  */
> + virtio_wmb(vq->weak_barriers);
> + vq->avail_idx_shadow++;
> + vq->vring.avail->idx = cpu_to_virtio16(_vq->vdev,
> +vq->avail_idx_shadow);
> + vq->num_added++;
> +
> + pr_debug("Added buffer head %i to %p\n", i, vq);
> +
> + /*
> +  * This is very unlikely, but theoretically possible.  Kick
> +  * just in case.
> +  */
> + if (unlikely(vq->num_added == (1 << 16) - 1))
> + virtqueue_kick(_vq);
> +}
> +
> +int virtqueue_add_one_desc(struct virtqueue *_vq,
> +uint64_t addr,
> +uint32_t len,
> +bool in_desc,
> +void *data)
> +{
> + struct vring_virtqueue *vq = to_vvq(_vq);
> + struct vring_desc *desc;
> + unsigned int i;
> +
> + START_USE(vq);
> + BUG_ON(data == NULL);
> +
> + if (unlikely(vq->broken)) {
> + END_USE(vq);
> + return -EIO;
> + }
> +
> + if (_vq->num_free < 1) {
> + END_USE(vq);
> + return -ENOSPC;
> + }
> +
> + i = vq->free_head;
> + desc = &vq->vring.desc[i];
> + desc->addr = cpu_to_virtio64(_vq->vdev, addr);
> + desc->len = cpu_to_virtio32(_vq->vdev, len);
> + if (in_desc)
> + desc->flags = cpu_to_virtio16(_vq->vdev, VRING_DESC_F_WRITE);
> + else
> + desc->flags = 0;
> + vq->desc_state[i].data = data;
> + vq->desc_state[i].indir_desc = NULL;
> + vq->free_head = virtio16_to_cpu(_vq->vdev, vq->vring.desc[i].next);
> + _vq->num_free--;
> +
> + vring_set_avail(_vq, i);
> +
> + END_USE(vq);
> +
> + return 0;
> +}
> +EXPORT_SYMBOL_GPL(virtqueue_add_one_desc);
> +
>  static inline int virtqueue_add(struct virtqueue *_vq,
>   struct scatterlist *sgs[],
>   unsigned int total_sg,
> @@ -269,7 +342,7 @@ static inline int virtqueue_add(struct virtqueue *_vq,
>   struct vring_virtqueue *vq = to_vvq(_vq);
>   struct scatterlist *sg;
>   struct vring_desc *desc;
> - unsigned int i, n, avail, descs_used, uninitialized_var(prev), err_idx;
> + unsigned int i, n, descs_used, uninitialized_var(prev), err_idx;
>   int head;
>   bool indirect;
>  
> @@ -395,26 +468,9 @@ static inline int virtqueue_add(struct virtqueue *_vq,
>   else
>   vq->desc_state[head].indir_desc = ctx;
>  
> - /* Put entry in available array (but don't update avail->idx until they
> -  * do sync). */
> - avail = vq->avail_idx_shadow & (vq->vring.num - 1);
> - vq->vring.avail->ring[avail] = cpu_to_virtio16(_vq->vdev, head);
> -
> - /* Descriptors and available array need to be set before we expose the
> -  * new available array entries. */
> - virtio_wmb(vq->weak_barriers);
> - vq->avail_idx_shadow++;
> - vq->vring.avail->idx = cpu_to_virtio16(_vq->vdev, vq->avail_idx_shadow);
> - vq->num_added++;
> -
>

Re: [PATCH 4/5] MIPS: Execute any partial write of the last register with PTRACE_SETREGSET

[Maciej W. Rozycki]

Hi Dave,

> > linux-mips-nt-prfpreg-count.diff
> > Index: linux-sfr-test/arch/mips/kernel/ptrace.c
> > ===
> > --- linux-sfr-test.orig/arch/mips/kernel/ptrace.c   2017-11-21 
> > 22:12:00.0 +
> > +++ linux-sfr-test/arch/mips/kernel/ptrace.c2017-11-21 
> > 22:13:13.47197 +
> > @@ -484,7 +484,7 @@ static int fpr_set_msa(struct task_struc
> > int err;
> >  
> > BUILD_BUG_ON(sizeof(fpr_val) != sizeof(elf_fpreg_t));
> > -   for (i = 0; i < NUM_FPU_REGS && *count >= sizeof(elf_fpreg_t); i++) {
> > +   for (i = 0; i < NUM_FPU_REGS && *count > 0; i++) {
> > 
> > err = user_regset_copyin(pos, count, kbuf, ubuf,
> >  &fpr_val, i * sizeof(elf_fpreg_t),
> >  (i + 1) * sizeof(elf_fpreg_t));
> 
> But mips*_regsets[REGSET_FPR].size == sizeof(elf_fpreg_t),
> linux/kernel/regset.c:ptrace_regset() polices
> iov_len % regset->size == 0, and each user_regset_copyout() call here
> transfers sizeof(elf_fpreg_t) bytes, decrementing *count by that
> amount unless something goest wrong in which case we return.

 Good point, I missed that check.

 I don't think however that re-enforcing in arch code, especially in such 
a subtle way, a constraint that has already been enforced upstream in 
generic code is a good idea, because if we ever decide to relax the 
constraint, then all the arch code will have to be carefully reviewed.

> If we can't end up with that, then this patch doesn't change ABI-
> observable behaviour, unless I've missed something.

 Right, in which case there is no need to backport this change if it is 
given a go-ahead.

> If we can end up with that somehow, then this patch reintroduces the
> issue d614fd58a283 aims to fix, whereby fpr_val can contain
> uninitialised kernel stack which userspace can then obtain via
> PTRACE_GETREGSET.

 That wasn't actually clarified in the referred commit's description, 
which it should in the first place, and I wasn't able to track down any 
review of your change as submitted, which would be the potential second 
source of such support information.  The description isn't even correct, 
as it states that if a short buffer is supplied, then the old values held 
in thread's registers are preserved, which clearly isn't correct as 
individual registers do get written from the beginning of the regset up to 
the point no more data is available to fill a whole register.

 You are of course right about the (partially) uninitialised variable, and 
I think there are two ways to address it:

1. By preinitialising it, i.e.:

for (i = 0; i < NUM_FPU_REGS && *count > 0; i++) {
fpr_val = get_fpr64(&target->thread.fpu.fpr[i], 0);
err = user_regset_copyin(pos, count, kbuf, ubuf,
 &fpr_val, i * sizeof(elf_fpreg_t),
 (i + 1) * sizeof(elf_fpreg_t));
if (err)
return err;
set_fpr64(&target->thread.fpu.fpr[i], 0, fpr_val);
}

   but that would be an overkill given that we assert that `count' is a 
   multiple of `sizeof(elf_fpreg_t)'.

2. Actually assert what we rely on having been enforced by generic code, 
   i.e.:

BUG_ON(*count % sizeof(elf_fpreg_t));
for (i = 0; i < NUM_FPU_REGS && *count > 0; i++) {
err = user_regset_copyin(pos, count, kbuf, ubuf,
 &fpr_val, i * sizeof(elf_fpreg_t),
 (i + 1) * sizeof(elf_fpreg_t));
if (err)
return err;
set_fpr64(&target->thread.fpu.fpr[i], 0, fpr_val);
}

   so that a discrepancy between generic code and the arch handler is 
   caught should it happen.

 Thoughts?

  Maciej

Re: [PATCH 00/11] fs: use freeze_fs on suspend/hibernate

[Luis R. Rodriguez]

On Thu, Nov 30, 2017 at 05:01:13PM +, Bart Van Assche wrote:
> It's great to see that you are making progress with this work :-) However,
> what's not clear to me is what your (long-term) plan is for freezing
> filesystems that e.g. exist on top of a md RAID1 block device?

The original approach of doing a full swing kill on kthread freezing helpers
in one shot was too much. We must therefore approach this turtle style and
carefully. This patch series currently only addresses filesystems which
have a freeze_fs() callback implemented, that's it. The rest of the kernel
needs more work.

So this work is far as I've gotten so far.

Note, it does *not* remove the kthread freezing API calls on any other drivers,
as such that should still work.

> The md resync
> thread must be stopped before a system is frozen. Today the md driver uses
> the kthread freezing mechanism for that purpose. Do you have a plan for
> handling the more complicated scenarios, e.g. a filesystem that exists on top
> of an md device where the md device uses one or more files as backing store
> and with the loop driver between the md device and the files?

Nope not yet. It seems you have given this some thought though so you're 
help here is greatly appreciated. In fact the way we should see the long
term 'kill kthread freezing' effort should be a collaborative one. I've
never touched md, so folks more familiar with md should give this some
thought.

Can for instance md register_pm_notifier() and register_syscore_ops()
and do handy work to pause some work to replace kthread freezing?
Note that I believe a pm notifier is needed in case syscore_suspend()
is not called, say on a suspend fail.

> How about filesystems implemented in user space using the FUSE driver?

Not sure, someone more familiar with FUSE drivers should chime in. Right
now all this does is leverage filesystems which *do* implement freeze_fs()
only, and removes the kthread freezing calls after that. That's all. It
should not affect any other filesystems

Likewise consider filesystems that implement freeze_super() instead (like gfs2)
which don't hold sb->s_umount -- see commit 48b6bca6b7b8309 ("fs: add
freeze_super/thaw_super fs hooks"). If its desirable to address those as well,
it would seem a pair of non-locking iters somehow are needed. More work to
be done.

This all needs to be considered for the future as well.

> Patch 6/11 of this series freezes user space processes before freezing
> filesystems. Will that work for FUSE filesystems?

It doesn't add new code which should negatively affect FUSE drivers.
Long term if we wanted to address FUSE, it may require other work.

In the future then fs_suspend_freeze() may need to work for different
types of filesystems. Right now only filesystems which implement freeze_fs()
are addressed.

  Luis

Re: [PATCH 2/2] bnxt_en: Add ETH_RESET_AP support

[Michael Chan]

On Thu, Nov 30, 2017 at 11:36 AM, Scott Branden
 wrote:
> Add ETH_RESET_AP support handling to reset the internal
> Application Processor(s) of the SmartNIC card.
>
> Signed-off-by: Scott Branden 

Acked-by: Michael Chan 

Re: [PATCH] rxrpc: Neaten logging macros and add KERN_DEBUG logging level

[Joe Perches]

On Thu, 2017-11-30 at 19:34 +, David Howells wrote:
> Joe Perches  wrote:
> 
> > There is no listed rxrpc maintainer.
> 
> There's a script in the kernel called get_maintainer.pl which you might find
> of use:

Yeah, I've heard of it.  I also wrote it btw.

>   warthog>./scripts/get_maintainer.pl net/rxrpc/
>   "David S. Miller"  (maintainer:NETWORKING 
> [GENERAL],commit_signer:23/74=31%)
>   David Howells  
> (commit_signer:64/74=86%,authored:60/74=81%)
>   net...@vger.kernel.org (open list:NETWORKING [GENERAL])
>   linux-kernel@vger.kernel.org (open list)

The script I use to send patches does not cc
patch authors as, based on my history
sending patches, most to many of them do not
want to see patches.

> It would seem a good idea to cc me, as the one with the largest "authored"
> also.

Perhaps a better idea would be to have an
rxrpc section in the MAINTAINERS file.

cheers, Joe

Re: [PATCH v3] doc: add maintainer book

[Tobin C. Harding]

On Thu, Nov 30, 2017 at 09:06:21AM -0200, Mauro Carvalho Chehab wrote:
> Em Thu, 30 Nov 2017 21:47:44 +1100
> "Tobin C. Harding"  escreveu:
> 
> > On Thu, Nov 30, 2017 at 07:01:19AM -0200, Mauro Carvalho Chehab wrote:
> > > Em Thu, 30 Nov 2017 12:55:07 +1100
> > > "Tobin C. Harding"  escreveu:
> 
> 
> > > > +So, by way of an example, Greg gives; a pull request with 
> > > > miscellaneous  
> > > 
> > > Nitpick: there's an extra ";" character above:
> > >   gives; -> gives  
> > 
> > Ha ha, I thought for ages how to word this bit. The irony of grammar
> > corrections from a non-native speaker is not lost on me :)
> 
> :-)
> 
> Well, if that serves as a consolation, I had to go to a dictionary to
> understand "By way of":
> 
>   https://www.collinsdictionary.com/dictionary/english/by-way-of
> 
> As that was a new expression for me :-)
> 
> Anyway, AFAIKT, English and Portuguese (and probably Spanish) have 
> similar rules with regards to commas and semicolons.

Oh cool, I didn't know that. Eu fallo um pouco Portugese muito no
esrever bem. I never learned to spell in Portuguese.

> > Perhaps:
> > 
> >  By way of an example Greg gives, a pull request with miscellaneous
> > 
> > I'll take any nitpicks you have Mauro, striving for perfection here. Thanks.
> 
> Yeah, that looks a way better on my eyes.

thanks,
Tobin.

Re: [pcpu] BUG: KASAN: use-after-scope in pcpu_setup_first_chunk+0x1e3b/0x29e2

[Kees Cook]

On Thu, Nov 30, 2017 at 11:22 AM, Dennis Zhou  wrote:
> Hi Dmitry and Kees,
>
> On Thu, Nov 30, 2017 at 10:10:41AM -0800, Kees Cook wrote:
>> > Are we sure that structleak plugin is not at fault? If yes, then we
>> > need to report this to https://gcc.gnu.org/bugzilla/ with instructions
>> > on how to build/use the plugin.
>
> I believe this is an issue with the structleak plugin and not gcc. The
> bug does not show up if you compile without
> GCC_PLUGIN_STRUCTLEAK_BYREF_ALL.
>
> It seems to be caused by the initializer not respecting the ASAN_MARK
> calls. Therefore, if an inlined function gets called from a for loop,
> the initializer code gets invoked bugging in the second iteration. Below
> is the tree dump for the structleak plugin from the reproducer in the
> previous email. In bb 2 of INIT_LIST_HEAD, the __u = {} is before the
> unpoison call. This is inlined in bb 3 of main.

Ah-ha, okay. Thanks for the close examination. Ard, is this something
you have a few moment to take a look at?

-Kees

>
>>
>> I thought from earlier in this thread that the bug just changed
>> locations depending on the plugin. Does the issue still exist with the
>> plugin disabled?
>>
>
> The bug changing locations was me just verifying it was not an issue
> with percpu memory. I manually unrolled the for loop to show that the
> percpu bug disappears, but manifests later on. The issue does not exist
> with the BY_REF_ALL config.
>
> Thanks,
> Dennis
>
> 
>
> ;; Function __write_once_size (__write_once_size, funcdef_no=2, 
> decl_uid=3117, cgraph_uid=2, symbol_order=2)
>
> __attribute__((always_inline))
> __write_once_size (volatile void * p, void * res, int size)
> {
>   unsigned char _1;
>   short unsigned int _2;
>   unsigned int _3;
>   long unsigned int _4;
>   long unsigned int _5;
>
>[0.00%]:
>   switch (size_7(D))  [0.00%], case 1:  [0.00%], case 2: 
>  [0.00%], case 4:  [0.00%], case 8:  [0.00%]>
>
>  [0.00%]:
>   _1 = MEM[(__u8 *)res_9(D)];
>   MEM[(volatile __u8 *)p_10(D)] ={v} _1;
>   goto ; [0.00%]
>
>  [0.00%]:
>   _2 = MEM[(__u16 *)res_9(D)];
>   MEM[(volatile __u16 *)p_10(D)] ={v} _2;
>   goto ; [0.00%]
>
>  [0.00%]:
>   _3 = MEM[(__u32 *)res_9(D)];
>   MEM[(volatile __u32 *)p_10(D)] ={v} _3;
>   goto ; [0.00%]
>
>  [0.00%]:
>   _4 = MEM[(__u64 *)res_9(D)];
>   MEM[(volatile __u64 *)p_10(D)] ={v} _4;
>   goto ; [0.00%]
>
>  [0.00%]:
>   _5 = (long unsigned int) size_7(D);
>   __builtin_memcpy (p_10(D), res_9(D), _5);
>
>[0.00%]:
>   return;
>
> }
>
>
>
> ;; Function INIT_LIST_HEAD (INIT_LIST_HEAD, funcdef_no=3, decl_uid=3129, 
> cgraph_uid=3, symbol_order=3)
>
>
> Symbols to be put in SSA form
> { D.3149 }
> Incremental SSA update started at block: 0
> Number of blocks in CFG: 9
> Number of blocks to update: 8 ( 89%)
>
>
> __attribute__((always_inline))
> INIT_LIST_HEAD (struct list_head * list)
> {
>   volatile void * p;
>   void * res;
>   int size;
>   union
>   {
> struct list_head * __val;
> char __c[1];
>   } __u;
>   struct list_head * D.3135;
>   struct list_head * * _1;
>   struct list_head * _7;
>   unsigned char _13;
>   short unsigned int _14;
>   unsigned int _15;
>   long unsigned int _16;
>   long unsigned int _17;
>
>[0.00%]:
>   __u = {};
>   ASAN_MARK (UNPOISON, &__u, 8);
>   __u.__val = list_4(D);
>   _1 = &list_4(D)->next;
>   p_10 = _1;
>   res_11 = &__u.__c;
>   size_12 = 8;
>   switch (size_12)  [0.00%], case 1:  [0.00%], case 2:  
> [0.00%], case 4:  [0.00%], case 8:  [0.00%]>
>
>  [0.00%]:
>   _13 = MEM[(__u8 *)res_11];
>   MEM[(volatile __u8 *)p_10] ={v} _13;
>   goto ; [0.00%]
>
>  [0.00%]:
>   _14 = MEM[(__u16 *)res_11];
>   MEM[(volatile __u16 *)p_10] ={v} _14;
>   goto ; [0.00%]
>
>  [0.00%]:
>   _15 = MEM[(__u32 *)res_11];
>   MEM[(volatile __u32 *)p_10] ={v} _15;
>   goto ; [0.00%]
>
>  [0.00%]:
>   _16 = MEM[(__u64 *)res_11];
>   MEM[(volatile __u64 *)p_10] ={v} _16;
>   goto ; [0.00%]
>
>  [0.00%]:
>   _17 = (long unsigned int) size_12;
>   __builtin_memcpy (p_10, res_11, _17);
>
>[0.00%]:
>   _7 = __u.__val;
>   ASAN_MARK (POISON, &__u, 8);
>   list_4(D)->prev = list_4(D);
>   return;
>
> }
>
>
>
> ;; Function main (main, funcdef_no=4, decl_uid=3138, cgraph_uid=4, 
> symbol_order=4)
>
>
> Symbols to be put in SSA form
> { D.3150 }
> Incremental SSA update started at block: 0
> Number of blocks in CFG: 13
> Number of blocks to update: 12 ( 92%)
>
>
> main (int argc, char * * argv)
> {
>   struct list_head * D.3165;
>   union
>   {
> struct list_head * __val;
> char __c[1];
>   } __u;
>   int size;
>   void * res;
>   volatile void * p;
>   struct list_head * list;
>   int i;
>   struct list_head * p;
>   int D.3146;
>   long unsigned int _1;
>   long unsigned int _2;
>   struct list_head * _3;
>   int _11;
>   struct list_head * * _15;
>   unsigned char _19;
>   short unsigned int _20;
>   unsigned int _21;
>   long unsigned int _22;
>   long unsigned int _23;
>   struct list_head * _24;
>
>[0.00%]:
>   __u = {};
>   p_8 = malloc (160);

Re: [RFC] Rebasing the IDR

[Daniel Vetter]

Adding dri-devel, I think a pile of those are in drm.

On Thu, Nov 30, 2017 at 6:36 PM, Matthew Wilcox  wrote:
> About 40 of the approximately 180 users of the IDR in the kernel are
> "1-based" instead of "0-based".  That is, they never want to have ID 0
> allocated; they want to see IDs allocated between 1 and N.  Usually, that's
> expressed like this:
>
> /* Get the user-visible handle using idr. */
> ret = idr_alloc(&file_priv->object_idr, obj, 1, 0, GFP_KERNEL);
>
> The current implementation of this grieves me.  You see, we mark each
> node of the radix tree according to whether it has any free entries
> or not, and entry 0 is always free!  If we've already allocated 10,000
> entries from this IDR, and see this call, we'll walk all the way down
> the left side of the tree looking for entry 1, get to the bottom,
> see that entries 1-63 are allocated, then walk up to the next level,
> see that 64-4095 are allocated, walk up to the next level, see that
> 8192-12287 has a free entry, and then start walking down again.
>
> It'd be somewhere around two to three times quicker to know not to
> look down the left hand side of the tree, see that 1-8191 are used and
> start looking in the range 8192-12287.  I considered a function like
> idr_reserve(idr, N) to reserve the first N entries (we have at least one
> consumer in the tree that is 2-based, not 1-based), but that struck me
> as inelegant.  We also have the cool optimisation that if there's only
> one element in the radix tree at offset 0, then we don't even need
> to allocate a node to store it, we just store it right in the head.
> And that optimisation was never available to the 1-based users.
>
> I've come up with this solution instead, idr_base.  It's free in terms
> of memory consumption on 64-bit as it fits in the gap at the end of the
> struct idr.  Essentially, we just subtract off idr_base when looking
> up the ID, and add it back on when reporting the ID.  We need to do some
> saturating arithmetic in idr_get_next(), because starting a walk at 4
> billion or negative 8 quintillion doesn't work out terribly well.
>
> It does require the user to call idr_init_base() instead of idr_init().
> That should be a relatively small conversion effort.  Opinions?  Feedback?
> Better test cases for the test-suite (ahem)?

Just quick context on why we do this: We need to marshal/demarshal
NULL in a ton of our ioctls, mapping that to 0 is natural.

And yes I very much like this, and totally fine with trading an
idr_init_base when we can nuke the explicit index ranges at every
alloc side instead. So if you give me an idr_alloc function that
doesn't take a range as icing, that would be great.

Cheers, Daniel

>
> diff --git a/include/linux/idr.h b/include/linux/idr.h
> index 91d27a9bcdf4..a657b1f925f8 100644
> --- a/include/linux/idr.h
> +++ b/include/linux/idr.h
> @@ -18,6 +18,7 @@
>
>  struct idr {
> struct radix_tree_root  idr_rt;
> +   unsigned intidr_base;
> unsigned intidr_next;
>  };
>
> @@ -30,9 +31,10 @@ struct idr {
>  /* Set the IDR flag and the IDR_FREE tag */
>  #define IDR_RT_MARKER  ((__force gfp_t)(3 << __GFP_BITS_SHIFT))
>
> -#define IDR_INIT   \
> -{  \
> -   .idr_rt = RADIX_TREE_INIT(IDR_RT_MARKER)\
> +#define IDR_INIT { \
> +   .idr_rt = RADIX_TREE_INIT(IDR_RT_MARKER),   \
> +   .idr_base = 0,  \
> +   .idr_next = 0,  \
>  }
>  #define DEFINE_IDR(name)   struct idr name = IDR_INIT
>
> @@ -123,12 +125,20 @@ static inline int __must_check idr_alloc_u32(struct idr 
> *idr, void *ptr,
>
>  static inline void *idr_remove(struct idr *idr, unsigned long id)
>  {
> -   return radix_tree_delete_item(&idr->idr_rt, id, NULL);
> +   return radix_tree_delete_item(&idr->idr_rt, id - idr->idr_base, NULL);
>  }
>
>  static inline void idr_init(struct idr *idr)
>  {
> INIT_RADIX_TREE(&idr->idr_rt, IDR_RT_MARKER);
> +   idr->idr_base = 0;
> +   idr->idr_next = 0;
> +}
> +
> +static inline void idr_init_base(struct idr *idr, int base)
> +{
> +   INIT_RADIX_TREE(&idr->idr_rt, IDR_RT_MARKER);
> +   idr->idr_base = base;
> idr->idr_next = 0;
>  }
>
> @@ -163,7 +173,7 @@ static inline void idr_preload_end(void)
>   */
>  static inline void *idr_find(const struct idr *idr, unsigned long id)
>  {
> -   return radix_tree_lookup(&idr->idr_rt, id);
> +   return radix_tree_lookup(&idr->idr_rt, id - idr->idr_base);
>  }
>
>  /**
> diff --git a/lib/idr.c b/lib/idr.c
> index 1aaeb5a8c426..a1d3531bd62f 100644
> --- a/lib/idr.c
> +++ b/lib/idr.c
> @@ -33,21 +33,22 @@ int idr_alloc_ul(struct idr *idr, void *ptr, unsigned 
> long *nextid

Re: [PATCH 1/2] x86/stacktrace: do not fail when regs on stack for ORC

[Josh Poimboeuf]

On Thu, Nov 30, 2017 at 09:03:24AM +0100, Jiri Slaby wrote:
> save_stack_trace_reliable now returns "non reliable" when there are
> kernel pt_regs on stack. This means an interrupt or exception happened.
> Somewhere down the route. It is a problem for frame pointer unwinder,
> because the frame might now have been set up yet when the irq happened,
> so it might fail to unwind from the interrupted function.
> 
> With ORC, this is not a problem, as ORC has out-of-band data. We can
> find ORC data even for the IP in interrupted function and always unwind
> one level up.
> 
> So introduce `unwind_regs_reliable' which decides if this is an issue
> for the currently selected unwinder at all and change the code
> accordingly.

Thanks.  I'm thinking there a few ways we can simplify things.  (Most of
these are actually issues with the existing code.)

- Currently we check to make sure that there's no frame *after* the user
  space regs.  I think there's no way that could ever happen and the
  check is overkill.

- We should probably remove the STACKTRACE_DUMP_ONCE() warnings.  There
  are some known places where a stack trace will fail, particularly with
  generated code.  I wish we had a DEBUG_WARN_ON() macro which used
  pr_debug(), but oh well.  At least the livepatch code has some helpful
  pr_warn()s, those are probably good enough.

- The unwind->error checks are superfluous.  The only errors we need to
  check for are (a) whether the FP unwinder encountered a kernel irq and
  b) whether we reached the final user regs frame.  So I think
  unwind->error can be removed altogether.

So with those changes in mind, how about something like this (plus
comments)?

for (unwind_start(&state, task, NULL, NULL); !unwind_done(&state);
 unwind_next_frame(&state)) {

regs = unwind_get_entry_regs(&state);
if (regs) {
if (user_mode(regs))
goto success;

if (IS_ENABLED(CONFIG_FRAME_POINTER))
return -EINVAL;
}

addr = unwind_get_return_address(&state);
if (!addr)
return -EINVAL;

if (save_stack_address(trace, addr, false))
return -EINVAL;
}

return -EINVAL;

success:
if (trace->nr_entries < trace->max_entries)
trace->entries[trace->nr_entries++] = ULONG_MAX;

return 0;

After these changes I believe we can enable
CONFIG_HAVE_RELIABLE_STACKTRACE for ORC.

Also, when you post the next version, please cc the live patching
mailing list, since this is directly relevant to livepatch.

Thanks!

-- 
Josh

Re: [PATCH v2 01/18] dt-bindings: panel: lvds: Document power-supply property

[Rob Herring]

On Thu, Nov 30, 2017 at 9:30 AM, Maxime Ripard
 wrote:
> Hi Rob,
>
> On Tue, Nov 28, 2017 at 11:48:47AM -0600, Rob Herring wrote:
>> Please CC DT list.
>>
>> On Mon, Nov 27, 2017 at 9:41 AM, Maxime Ripard
>>  wrote:
>> > The power-supply property is used by a vast majority of panels, including
>> > panel-simple. Let's document it as a common property
>> >
>> > Signed-off-by: Maxime Ripard 
>> > ---
>> >  Documentation/devicetree/bindings/display/panel/panel-common.txt | 6 
>> > ++
>> >  Documentation/devicetree/bindings/display/panel/panel-lvds.txt   | 1 +
>> >  2 files changed, 7 insertions(+)
>> >
>> > diff --git 
>> > a/Documentation/devicetree/bindings/display/panel/panel-common.txt 
>> > b/Documentation/devicetree/bindings/display/panel/panel-common.txt
>> > index ec52c472c845..125ea68052af 100644
>> > --- a/Documentation/devicetree/bindings/display/panel/panel-common.txt
>> > +++ b/Documentation/devicetree/bindings/display/panel/panel-common.txt
>> > @@ -78,6 +78,12 @@ used for panels that implement compatible control 
>> > signals.
>> >while active. Active high reset signals can be supported by inverting 
>> > the
>> >GPIO specifier polarity flag.
>> >
>> > +Power
>> > +-
>> > +
>> > +- power-supply: many display panels need an additional power supply in
>> > +  order to be fully powered-up. For such panels, power-supply contains
>> > +  a phandle to the regulator powering the panel.
>> >
>> >  Backlight
>> >  -
>> > diff --git 
>> > a/Documentation/devicetree/bindings/display/panel/panel-lvds.txt 
>> > b/Documentation/devicetree/bindings/display/panel/panel-lvds.txt
>> > index b938269f841e..250850a2150b 100644
>> > --- a/Documentation/devicetree/bindings/display/panel/panel-lvds.txt
>> > +++ b/Documentation/devicetree/bindings/display/panel/panel-lvds.txt
>> > @@ -32,6 +32,7 @@ Optional properties:
>> >  - label: See panel-common.txt.
>> >  - gpios: See panel-common.txt.
>> >  - backlight: See panel-common.txt.
>> > +- power-supply: See panel-common.txt.
>>
>> simple-panel.txt should do the same.
>
> I'll make simple-panel do that then
>
>> Really, I'd like to see panel-common.txt and simple-panel.txt merged
>> and simple-panel.txt removed altogether. But there are a lot of
>> references back to simple-panel.txt. A given panel still needs to say
>> what common properties it uses or doesn't use. Omitting a property
>> like power-supply is ambiguous and can either mean "I only have 1
>> supply" or "I haven't thought about supplies yet there are more than
>> 1".
>
> While I agree with you here, and in general, power-supply should be
> mandatory, do you expect me to fix all the panel bindings as part of
> this serie?

No, certainly not.

Rob

Re: [PATCH RFC 2/2] mm, hugetlb: do not rely on overcommit limit during migration

[Michal Hocko]

On Thu 30-11-17 11:35:11, Mike Kravetz wrote:
> On 11/29/2017 11:57 PM, Michal Hocko wrote:
> > On Wed 29-11-17 11:52:53, Mike Kravetz wrote:
> >> On 11/29/2017 01:22 AM, Michal Hocko wrote:
> >>> What about this on top. I haven't tested this yet though.
> >>
> >> Yes, this would work.
> >>
> >> However, I think a simple modification to your previous free_huge_page
> >> changes would make this unnecessary.  I was confused in your previous
> >> patch because you decremented the per-node surplus page count, but not
> >> the global count.  I think it would have been correct (and made this
> >> patch unnecessary) if you decremented the global counter there as well.
> > 
> > We cannot really increment the global counter because the over number of
> > surplus pages during migration doesn't increase.
> 
> I was not suggesting we increment the global surplus count.  Rather,
> your previous patch should have decremented the global surplus count in
> free_huge_page.  Something like:

sorry I meant to say decrement. The point is that overal suprlus count
doesn't change after the migration. The only thing that _might_ change
is the per node distribution of surplus pages. That is why I think we
should handle that during the migration.

> @@ -1283,7 +1283,13 @@ void free_huge_page(struct page *page)
>   if (restore_reserve)
>   h->resv_huge_pages++;
>  
> - if (h->surplus_huge_pages_node[nid]) {
> + if (PageHugeTemporary(page)) {
> + list_del(&page->lru);
> + ClearPageHugeTemporary(page);
> + update_and_free_page(h, page);
> + if (h->surplus_huge_pages_node[nid])
> + h->surplus_huge_pages--;
> + h->surplus_huge_pages_node[nid]--;
> + }
> + } else if (h->surplus_huge_pages_node[nid]) {
>   /* remove the page from active list */
>   list_del(&page->lru);
>   update_and_free_page(h, page);
> 
> When we allocate one of these 'PageHugeTemporary' pages, we only increment
> the global and node specific nr_huge_pages counters.  To me, this makes all
> the huge page counters be the same as if there were simply one additional
> pre-allocated huge page.  This 'extra' (PageHugeTemporary) page will go
> away when free_huge_page is called.  So, my thought is that it is not
> necessary to transfer per-node counts from the original to target node.
> Of course, I may be missing something.

The thing is that we do not know whether the original page is surplus
until the deallocation time.

> When thinking about transfering per-node counts as is done in your latest
> patch, I took another look at all the per-node counts.  This may show my
> ignorance of huge page migration, but do we need to handle the case where
> the page being migrated is 'free'?  Is that possible?  If so, there will
> be a count for free_huge_pages_node and the page will be on the per node
> hugepage_freelists that must be handled

I do not understand. What do you mean by free? Sitting on the pool? I do
not think we ever try to migrate those. They simply do not have any
state to migrate. We could very well just allocate fresh pages on the
remote node and dissolve free ones. I am not sure we do that during the
memory hotplug to preserve the pool size and I am too tired to check
that now. This would be a different topic I guess.
-- 
Michal Hocko
SUSE Labs

Re: [pcpu] BUG: KASAN: use-after-scope in pcpu_setup_first_chunk+0x1e3b/0x29e2

[Ard Biesheuvel]

On 30 November 2017 at 19:56, Kees Cook  wrote:
> On Thu, Nov 30, 2017 at 11:22 AM, Dennis Zhou  wrote:
>> Hi Dmitry and Kees,
>>
>> On Thu, Nov 30, 2017 at 10:10:41AM -0800, Kees Cook wrote:
>>> > Are we sure that structleak plugin is not at fault? If yes, then we
>>> > need to report this to https://gcc.gnu.org/bugzilla/ with instructions
>>> > on how to build/use the plugin.
>>
>> I believe this is an issue with the structleak plugin and not gcc. The
>> bug does not show up if you compile without
>> GCC_PLUGIN_STRUCTLEAK_BYREF_ALL.
>>
>> It seems to be caused by the initializer not respecting the ASAN_MARK
>> calls. Therefore, if an inlined function gets called from a for loop,
>> the initializer code gets invoked bugging in the second iteration. Below
>> is the tree dump for the structleak plugin from the reproducer in the
>> previous email. In bb 2 of INIT_LIST_HEAD, the __u = {} is before the
>> unpoison call. This is inlined in bb 3 of main.
>
> Ah-ha, okay. Thanks for the close examination. Ard, is this something
> you have a few moment to take a look at?
>

I must admit that I am a bit out of my depth here. Also, I am quite
sure this is a pre-existing issue with the plugin which is triggered
more easily because it affects many more initializers.

Re: [PATCH 1/2] x86/stacktrace: do not fail when regs on stack for ORC

[Josh Poimboeuf]

On Thu, Nov 30, 2017 at 01:57:10PM -0600, Josh Poimboeuf wrote:
> On Thu, Nov 30, 2017 at 09:03:24AM +0100, Jiri Slaby wrote:
> > save_stack_trace_reliable now returns "non reliable" when there are
> > kernel pt_regs on stack. This means an interrupt or exception happened.
> > Somewhere down the route. It is a problem for frame pointer unwinder,
> > because the frame might now have been set up yet when the irq happened,
> > so it might fail to unwind from the interrupted function.
> > 
> > With ORC, this is not a problem, as ORC has out-of-band data. We can
> > find ORC data even for the IP in interrupted function and always unwind
> > one level up.
> > 
> > So introduce `unwind_regs_reliable' which decides if this is an issue
> > for the currently selected unwinder at all and change the code
> > accordingly.
> 
> Thanks.  I'm thinking there a few ways we can simplify things.  (Most of
> these are actually issues with the existing code.)
> 
> - Currently we check to make sure that there's no frame *after* the user
>   space regs.  I think there's no way that could ever happen and the
>   check is overkill.
> 
> - We should probably remove the STACKTRACE_DUMP_ONCE() warnings.  There
>   are some known places where a stack trace will fail, particularly with
>   generated code.  I wish we had a DEBUG_WARN_ON() macro which used
>   pr_debug(), but oh well.  At least the livepatch code has some helpful
>   pr_warn()s, those are probably good enough.
^^^
meant to say pr_debug()s.

Also adding the live patching mailing list as an FYI.

> 
> - The unwind->error checks are superfluous.  The only errors we need to
>   check for are (a) whether the FP unwinder encountered a kernel irq and
>   b) whether we reached the final user regs frame.  So I think
>   unwind->error can be removed altogether.
> 
> So with those changes in mind, how about something like this (plus
> comments)?
> 
>   for (unwind_start(&state, task, NULL, NULL); !unwind_done(&state);
>unwind_next_frame(&state)) {
> 
>   regs = unwind_get_entry_regs(&state);
>   if (regs) {
>   if (user_mode(regs))
>   goto success;
> 
>   if (IS_ENABLED(CONFIG_FRAME_POINTER))
>   return -EINVAL;
>   }
> 
>   addr = unwind_get_return_address(&state);
>   if (!addr)
>   return -EINVAL;
> 
>   if (save_stack_address(trace, addr, false))
>   return -EINVAL;
>   }
> 
>   return -EINVAL;
> 
> success:
>   if (trace->nr_entries < trace->max_entries)
>   trace->entries[trace->nr_entries++] = ULONG_MAX;
> 
>   return 0;
> 
> After these changes I believe we can enable
> CONFIG_HAVE_RELIABLE_STACKTRACE for ORC.
> 
> Also, when you post the next version, please cc the live patching
> mailing list, since this is directly relevant to livepatch.
> 
> Thanks!

-- 
Josh

Re: [PATCH v3 5/6] ARM: ep93xx: ts72xx: cosmetic: Add some description to ts72xx code

[Alexander Sverdlin]

Hello Hartley!

On Thu, 30 Nov 2017 17:23:02 +
Hartley Sweeten  wrote:

> > +/**
> > +***
> > + * IO map
> > + 
> > +***
> > +**/
> 
> There is also something funny with the patch. The lines above appear to be 
> getting split incorrectly.

That's definitely not the case, I can apply the patch to 4.14 just fine and
there is no funny wrapping. But you are right about the rest, it should be
re-based.

-- 
Alexander Sverdlin.

Re: [PATCH 15/24] x86/mm: Allow flushing for future ASID switches

[Peter Zijlstra]

On Thu, Nov 30, 2017 at 10:48:56AM -0800, Andy Lutomirski wrote:
> Should it be 
> tlb_flush_shared_nonglobals_if_kernel_and_user_pagetables_are_separate()?

Its effectively invpcid_flush_all_other() or something like that. Of
course, its not invpcid based, so we should not name it such.

flush_asid_other() ?

> The whole idea that we can get away with ambiguous functions like
> __flush_tlb() seems to be much less true with KAISER.  I think we
> should maybe start getting rid of overly vague functions like this.

There is a lot of cleanup to be done for sure. I had to actually draw
pictures to untangle this stuff.

[PATCH] drm/nouveau/mmu: fix odd_ptr_err.cocci warnings

[Christoph Böhmwalder]

The kbuild test bot complained about a new coccinelle warning nearby,
which sparked a discussion about the assignment to 'memory' inside of
the conditional expression.  See Link below for the original post.

Fix the assignment to silence the coccinelle warning and also make the
code look a little nicer.

Link: https://lists.freedesktop.org/archives/nouveau/2017-November/029242.html
Signed-off-by: Christoph Böhmwalder 
---
 drm/nouveau/nvkm/subdev/mmu/uvmm.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drm/nouveau/nvkm/subdev/mmu/uvmm.c 
b/drm/nouveau/nvkm/subdev/mmu/uvmm.c
index fa81d0c1..37b201b9 100644
--- a/drm/nouveau/nvkm/subdev/mmu/uvmm.c
+++ b/drm/nouveau/nvkm/subdev/mmu/uvmm.c
@@ -106,7 +106,8 @@ nvkm_uvmm_mthd_map(struct nvkm_uvmm *uvmm, void *argv, u32 
argc)
} else
return ret;
 
-   if (IS_ERR((memory = nvkm_umem_search(client, handle {
+   memory = nvkm_umem_search(client, handle);
+   if (IS_ERR(memory)) {
VMM_DEBUG(vmm, "memory %016llx %ld\n", handle, PTR_ERR(memory));
return PTR_ERR(memory);
}
-- 
2.13.6

Re: [PATCH 0/5] PCI: Add support to the Cadence PCIe controller

[Cyrille Pitchen]

Le 30/11/2017 à 19:45, Cyrille Pitchen a écrit :
> Hi all,
> 
> Le 30/11/2017 à 19:18, Lorenzo Pieralisi a écrit :
>> On Thu, Nov 30, 2017 at 12:43:20PM +0530, Kishon Vijay Abraham I wrote:
>>
>> [...]
>>
> For linux-next, I applied this series on top of Kishon's patch
> ("PCI: endpoint: Use EPC's device in 
> dma_alloc_coherent/dma_free_coherent")
> otherwise dma_alloc_coherent() fails when called by pci_epf_alloc_space().
>
> Also, I patched drivers/Makefile rather than drivers/pci/Makefile to make
> the drivers/pci/cadence/pcie-cadence-ep.o linked after
>>>
>>> The reason to patch drivers/Makefile should be because pcie-cadence-ep has 
>>> to
>>> be compiled even when CONFIG_PCI is not enabled. CONFIG_PCI enables host
>>> specific features and ENDPOINT shouldn't depend on CONFIG_PCI.
> drivers/pci/endpoint/*.o objects, otherwise the built-in pci-cadence-ep
> driver would be probed before the PCI endpoint framework would have been
> initialized, which results in a kernel crash.

 Nice :( - isn't there a way to improve this (ie probe deferral or
 registering the EPF bus earlier) ?

> I guess this is the reason why the "pci/dwc" line was also put in
> drivers/Makefile, right after the "pci/endpoint" line.

 Or probably the other way around - see commit 5e8cb4033807

 @Kishon, thoughts ?
>>>
>>> Lorenzo, ordering Makefile is one way to initialize EP core before
>>
>> Makefile ordering is fragile, I do not like relying on it.
>>
>>> other drivers. the other way is to have PCI EP core have a different
>>> initcall level..  subsys_initcall??
>>
>> Yes, registering the bus at eg postcore_initcall() as PCI does should do
>> (if that's the problem this is solving) but still, the code must not
>> crash if the ordering is not correct, we have to fix this regardless.
>>
>> I would appreciate if Cyrille can debug the cause of the kernel crash
>> so that we can fix it in the longer term.
>>
> 
> I had the crash kernel few weeks ago hence I have to test again to confirm
> but if I remember correctly it was a NULL pointer dereferencing crash:
> 
> cdns_pcie_ep_probe()
> |
> +--> devm_pci_epc_create()
>  |
>  +--> __devm_pci_ep_create()
>   |
>   +--> __pci_epc_create()
>  |
>  +--> pci_ep_cfs_add_epc_group()
>   |
>   | /*
>   |  * Here controllers_group is still NULL because
>   |  * pci_ep_cfs_init() has not been called yet.
>   |  */
>   +--> configfs_register_group(controllers_group, ...)
>|
>+--> link_group()
> /* Dereferencing NULL pointer */
> 
> Best regards,
> 
> Cyrille
>

I know it's far from perfect but what do you think or something like that:

---8<---
diff --git a/drivers/Makefile b/drivers/Makefile
index 27bdd98784d9..9757199b9a65 100644
--- a/drivers/Makefile
+++ b/drivers/Makefile
@@ -16,11 +16,7 @@ obj-$(CONFIG_PINCTRL)+= pinctrl/
 obj-$(CONFIG_GPIOLIB)  += gpio/
 obj-y  += pwm/
 
-obj-$(CONFIG_PCI)  += pci/
-obj-$(CONFIG_PCI_ENDPOINT) += pci/endpoint/
-obj-$(CONFIG_PCI_CADENCE)  += pci/cadence/
-# PCI dwc controller drivers
-obj-y  += pci/dwc/
+obj-y  += pci/
 
 obj-$(CONFIG_PARISC)   += parisc/
 obj-$(CONFIG_RAPIDIO)  += rapidio/
diff --git a/drivers/pci/Makefile b/drivers/pci/Makefile
index 3d5e047f0a32..4e57fe4499ce 100644
--- a/drivers/pci/Makefile
+++ b/drivers/pci/Makefile
@@ -3,6 +3,7 @@
 # Makefile for the PCI bus specific drivers.
 #
 
+ifdef CONFIG_PCI
 obj-y  += access.o bus.o probe.o host-bridge.o remove.o pci.o \
pci-driver.o search.o pci-sysfs.o rom.o setup-res.o \
irq.o vpd.o setup-bus.o vc.o mmap.o setup-irq.o
@@ -54,3 +55,9 @@ ccflags-$(CONFIG_PCI_DEBUG) := -DDEBUG
 # PCI host controller drivers
 obj-y += host/
 obj-y += switch/
+endif
+
+obj-$(CONFIG_PCI_ENDPOINT) += endpoint/
+obj-$(CONFIG_PCI_CADENCE)  += cadence/
+# PCI dwc controller drivers
+obj-y  += dwc/
---8<---

I admit it doesn't solve the ordering issue but at least it cleans some mess
in drivers/Makefile. 

I agree with Lorenzo, we should avoid as much as we could to rely on the
link order.

However I faced another issue: code from pcie-cadence.c is used by both
pcie-cadence-host.c and pcie-cadence-ep.c so I had to find a way to compile
this shared file if at least one of the host and EPC driver was selected.

That's why I put source files in the cadence sub-directory and used the
single cadence/Makefile to regroup all the compilation rules, instead of
splitting them be

Re: [PATCH RFC 2/2] mm, hugetlb: do not rely on overcommit limit during migration

[Michal Hocko]

On Thu 30-11-17 20:57:43, Michal Hocko wrote:
> On Thu 30-11-17 11:35:11, Mike Kravetz wrote:
> > On 11/29/2017 11:57 PM, Michal Hocko wrote:
> > > On Wed 29-11-17 11:52:53, Mike Kravetz wrote:
> > >> On 11/29/2017 01:22 AM, Michal Hocko wrote:
> > >>> What about this on top. I haven't tested this yet though.
> > >>
> > >> Yes, this would work.
> > >>
> > >> However, I think a simple modification to your previous free_huge_page
> > >> changes would make this unnecessary.  I was confused in your previous
> > >> patch because you decremented the per-node surplus page count, but not
> > >> the global count.  I think it would have been correct (and made this
> > >> patch unnecessary) if you decremented the global counter there as well.
> > > 
> > > We cannot really increment the global counter because the over number of
> > > surplus pages during migration doesn't increase.
> > 
> > I was not suggesting we increment the global surplus count.  Rather,
> > your previous patch should have decremented the global surplus count in
> > free_huge_page.  Something like:
> 
> sorry I meant to say decrement. The point is that overal suprlus count
> doesn't change after the migration. The only thing that _might_ change
> is the per node distribution of surplus pages. That is why I think we
> should handle that during the migration.

Let me clarify. The migration context is the only place where we have
both the old and new page so this sounds like the only place to know
that we need to transfer the per-node surplus state.
-- 
Michal Hocko
SUSE Labs

[PATCH 7/8] ARM: dts: imx7s: add usb hsic phy domain

[tyler]

From: Tyler Baker 

The GPCv2 driver should control the MIPI, PCIe,
and USB HSIC PHY regulators. Add the USB HSIC
power domain to the GPC node.

Signed-off-by: Tyler Baker 
---
 arch/arm/boot/dts/imx7s.dtsi | 6 ++
 1 file changed, 6 insertions(+)

diff --git a/arch/arm/boot/dts/imx7s.dtsi b/arch/arm/boot/dts/imx7s.dtsi
index 151ab34..9626a3e 100644
--- a/arch/arm/boot/dts/imx7s.dtsi
+++ b/arch/arm/boot/dts/imx7s.dtsi
@@ -602,6 +602,12 @@
reg = 
;
power-supply = <®_1p0d>;
};
+   pgc_usb_hsic_phy: 
pgc-usb-hsic-phy-domain {
+   #power-domain-cells = <0>;
+
+   reg = 
;
+   power-supply = <®_1p2>;
+   };
};
};
};
-- 
2.9.3

[PATCH 0/8] ARM: dts: introduce Compulab IoT Gateway

[tyler]

From: Tyler Baker 

The Compulab IoT Gateway is based on an NXP i.MX7D, dual core
Cortex-A7 clocking at 1GHz. It supports up to 2GB of DDR3,
and 32GB of eMMC flash. Onboard, there are two gigabit
ethernet controllers, 4 x USB2, RS485, and CAN.

It uses the same SoM as the cl-som-imx7, but includes a baseboard 
with additional I/O.

Compulab has provided patches for this platform based on v4.1. 
I've used these patches as reference to get things working on tip.

The entire series is based on v4.15-rc1.

Tyler Baker (8):
  ARM: dts: imx7d-sbc-iot: add initial iot gateway dts
  ARM: dts: imx7: build imx7d-sbc-iot-imx7 dtb
  ARM: dts: imx7d-cl-som: add nodes for usbh, and usbotg2
  ARM: dts: imx7s: add dma support
  ARM: dts: imx7s: add node and supplies for vdd1p2
  ARM: dts: imx7d-sbc-iot: enable PCIe peripheral
  ARM: dts: imx7s: add usb hsic phy domain
  PCIe: imx6: imx7d: add support for phy refclk source

 arch/arm/boot/dts/Makefile   |   1 +
 arch/arm/boot/dts/imx7d-cl-som-imx7.dts  |  36 -
 arch/arm/boot/dts/imx7d-sbc-iot-imx7.dts | 252 +++
 arch/arm/boot/dts/imx7s.dtsi |  29 +++-
 drivers/pci/dwc/pci-imx6.c   |   8 +-
 5 files changed, 316 insertions(+), 10 deletions(-)
 create mode 100644 arch/arm/boot/dts/imx7d-sbc-iot-imx7.dts

-- 
2.9.3

[PATCH v1] PCI: Remove PCI_REASSIGN_ALL_RSRC use on arm and arm64

[Bjorn Helgaas]

From: Bjorn Helgaas 

On arm, PCI_REASSIGN_ALL_RSRC is used only in pcibios_assign_all_busses(),
which helps decide whether to reconfigure bridge bus numbers.  It has
nothing to do with BAR assignments.  On arm64 and powerpc,
pcibios_assign_all_busses() tests PCI_REASSIGN_ALL_BUS, which makes more
sense.

Align arm with arm64 and powerpc, so they all use PCI_REASSIGN_ALL_BUS for
pcibios_assign_all_busses().

Remove PCI_REASSIGN_ALL_RSRC from the Tegra, Versatile, and R-Car drivers.
These drivers are used only on arm or arm64, where PCI_REASSIGN_ALL_RSRC is
not used after this change, so removing it should have no effect.

No functional change intended.

Signed-off-by: Bjorn Helgaas 
---
 arch/arm/include/asm/pci.h   |5 +
 arch/arm/kernel/bios32.c |2 +-
 drivers/pci/host/pci-tegra.c |2 +-
 drivers/pci/host/pci-versatile.c |2 +-
 drivers/pci/host/pcie-rcar.c |2 +-
 5 files changed, 5 insertions(+), 8 deletions(-)

diff --git a/arch/arm/include/asm/pci.h b/arch/arm/include/asm/pci.h
index 960d9dc4f380..1f0de808d111 100644
--- a/arch/arm/include/asm/pci.h
+++ b/arch/arm/include/asm/pci.h
@@ -10,10 +10,7 @@ extern unsigned long pcibios_min_io;
 extern unsigned long pcibios_min_mem;
 #define PCIBIOS_MIN_MEM pcibios_min_mem
 
-static inline int pcibios_assign_all_busses(void)
-{
-   return pci_has_flag(PCI_REASSIGN_ALL_RSRC);
-}
+#define pcibios_assign_all_busses()pci_has_flag(PCI_REASSIGN_ALL_BUS)
 
 #ifdef CONFIG_PCI_DOMAINS
 static inline int pci_proc_domain(struct pci_bus *bus)
diff --git a/arch/arm/kernel/bios32.c b/arch/arm/kernel/bios32.c
index 0cd0aefb3a8f..ed46ca69813d 100644
--- a/arch/arm/kernel/bios32.c
+++ b/arch/arm/kernel/bios32.c
@@ -527,7 +527,7 @@ void pci_common_init_dev(struct device *parent, struct 
hw_pci *hw)
struct pci_sys_data *sys;
LIST_HEAD(head);
 
-   pci_add_flags(PCI_REASSIGN_ALL_RSRC);
+   pci_add_flags(PCI_REASSIGN_ALL_BUS);
if (hw->preinit)
hw->preinit();
pcibios_init_hw(parent, hw, &head);
diff --git a/drivers/pci/host/pci-tegra.c b/drivers/pci/host/pci-tegra.c
index f9d3960dc39f..ee193767f77b 100644
--- a/drivers/pci/host/pci-tegra.c
+++ b/drivers/pci/host/pci-tegra.c
@@ -2382,7 +2382,7 @@ static int tegra_pcie_probe(struct platform_device *pdev)
 
tegra_pcie_enable_ports(pcie);
 
-   pci_add_flags(PCI_REASSIGN_ALL_RSRC | PCI_REASSIGN_ALL_BUS);
+   pci_add_flags(PCI_REASSIGN_ALL_BUS);
host->busnr = pcie->busn.start;
host->dev.parent = &pdev->dev;
host->ops = &tegra_pcie_ops;
diff --git a/drivers/pci/host/pci-versatile.c b/drivers/pci/host/pci-versatile.c
index d417acab0ecf..2a2dfcd68e86 100644
--- a/drivers/pci/host/pci-versatile.c
+++ b/drivers/pci/host/pci-versatile.c
@@ -202,7 +202,7 @@ static int versatile_pci_probe(struct platform_device *pdev)
writel(0, versatile_cfg_base[0] + PCI_INTERRUPT_LINE);
 
pci_add_flags(PCI_ENABLE_PROC_DOMAINS);
-   pci_add_flags(PCI_REASSIGN_ALL_BUS | PCI_REASSIGN_ALL_RSRC);
+   pci_add_flags(PCI_REASSIGN_ALL_BUS);
 
list_splice_init(&pci_res, &bridge->windows);
bridge->dev.parent = dev;
diff --git a/drivers/pci/host/pcie-rcar.c b/drivers/pci/host/pcie-rcar.c
index 12796eccb2be..03fabb0552ae 100644
--- a/drivers/pci/host/pcie-rcar.c
+++ b/drivers/pci/host/pcie-rcar.c
@@ -459,7 +459,7 @@ static int rcar_pcie_enable(struct rcar_pcie *pcie)
 
rcar_pcie_setup(&bridge->windows, pcie);
 
-   pci_add_flags(PCI_REASSIGN_ALL_RSRC | PCI_REASSIGN_ALL_BUS);
+   pci_add_flags(PCI_REASSIGN_ALL_BUS);
 
bridge->dev.parent = dev;
bridge->sysdata = pcie;

[PATCH 8/8] PCIe: imx6: imx7d: add support for phy refclk source

[tyler]

From: Tyler Baker 

In the i.MX7D the PCIe PHY can use either externel oscillator or
internal PLL as a reference clock source.
Add support for the PHY Reference Clock source including
device tree property phy-ref-clk.
External oscillator is used as a default reference clock source.

Signed-off-by: Tyler Baker 
Signed-off-by: Ilya Ledvich 
---
 drivers/pci/dwc/pci-imx6.c | 8 +++-
 1 file changed, 7 insertions(+), 1 deletion(-)

diff --git a/drivers/pci/dwc/pci-imx6.c b/drivers/pci/dwc/pci-imx6.c
index b734835..e935db4 100644
--- a/drivers/pci/dwc/pci-imx6.c
+++ b/drivers/pci/dwc/pci-imx6.c
@@ -45,6 +45,7 @@ enum imx6_pcie_variants {
 struct imx6_pcie {
struct dw_pcie  *pci;
int reset_gpio;
+   u32 phy_refclk;
boolgpio_active_high;
struct clk  *pcie_bus;
struct clk  *pcie_phy;
@@ -474,7 +475,7 @@ static void imx6_pcie_init_phy(struct imx6_pcie *imx6_pcie)
switch (imx6_pcie->variant) {
case IMX7D:
regmap_update_bits(imx6_pcie->iomuxc_gpr, IOMUXC_GPR12,
-  IMX7D_GPR12_PCIE_PHY_REFCLK_SEL, 0);
+  BIT(5), imx6_pcie->phy_refclk ? BIT(5) : 0);
break;
case IMX6SX:
regmap_update_bits(imx6_pcie->iomuxc_gpr, IOMUXC_GPR12,
@@ -733,6 +734,11 @@ static int imx6_pcie_probe(struct platform_device *pdev)
if (IS_ERR(pci->dbi_base))
return PTR_ERR(pci->dbi_base);
 
+   /* Fetch PHY Reference Clock */
+   if (of_property_read_u32(node, "phy-ref-clk", &imx6_pcie->phy_refclk))
+   imx6_pcie->phy_refclk = 0;
+   pr_info("%s: phy_refclk = %d\n", __func__, imx6_pcie->phy_refclk);
+
/* Fetch GPIOs */
imx6_pcie->reset_gpio = of_get_named_gpio(node, "reset-gpio", 0);
imx6_pcie->gpio_active_high = of_property_read_bool(node,
-- 
2.9.3

[PATCH 3/8] ARM: dts: imx7d-cl-som: add nodes for usbh, and usbotg2

[tyler]

From: Tyler Baker 

Add device tree nodes for the USB hub, and USB OTG. i2c2 on this
platform supports low state retention power state so lets use it.

Signed-off-by: Tyler Baker 
---
 arch/arm/boot/dts/imx7d-cl-som-imx7.dts | 36 +
 1 file changed, 28 insertions(+), 8 deletions(-)

diff --git a/arch/arm/boot/dts/imx7d-cl-som-imx7.dts 
b/arch/arm/boot/dts/imx7d-cl-som-imx7.dts
index ae45af1..a9f690b 100644
--- a/arch/arm/boot/dts/imx7d-cl-som-imx7.dts
+++ b/arch/arm/boot/dts/imx7d-cl-som-imx7.dts
@@ -30,6 +30,16 @@
gpio = <&gpio1 5 GPIO_ACTIVE_HIGH>;
enable-active-high;
};
+
+   reg_usbh_nreset: regulator@4 {
+   compatible = "regulator-fixed";
+   regulator-name = "usb_host_nreset";
+   regulator-min-microvolt = <330>;
+   regulator-max-microvolt = <330>;
+   gpio = <&pca9555 6 GPIO_ACTIVE_HIGH>;
+   enable-active-high;
+   regulator-always-on;
+   };
 };
 
 &cpu0 {
@@ -199,6 +209,16 @@
status = "okay";
 };
 
+&usbotg2 {
+   dr_mode = "host";
+   status = "okay";
+};
+
+&usbh {
+   vbus-supply = <®_usbh_nreset>;
+   status = "okay";
+};
+
 &usdhc3 {
pinctrl-names = "default";
pinctrl-0 = <&pinctrl_usdhc3>;
@@ -247,13 +267,6 @@
>;
};
 
-   pinctrl_i2c2: i2c2grp {
-   fsl,pins = <
-   MX7D_PAD_I2C2_SDA__I2C2_SDA 0x407f
-   MX7D_PAD_I2C2_SCL__I2C2_SCL 0x407f
-   >;
-   };
-
pinctrl_uart1: uart1grp {
fsl,pins = <
MX7D_PAD_UART1_TX_DATA__UART1_DCE_TX0x79
@@ -284,4 +297,11 @@
MX7D_PAD_LPSR_GPIO1_IO05__GPIO1_IO5 0x14 /* OTG 
PWREN */
>;
};
-};
\ No newline at end of file
+
+   pinctrl_i2c2: i2c2grp {
+   fsl,pins = <
+   MX7D_PAD_LPSR_GPIO1_IO07__I2C2_SDA  
0x400f
+   MX7D_PAD_LPSR_GPIO1_IO06__I2C2_SCL  
0x400f
+   >;
+   };
+};
-- 
2.9.3

[PATCH 6/8] ARM: dts: imx7d-sbc-iot: enable PCIe peripheral

[tyler]

From: Tyler Baker 

Add a PCIe device tree node to enable PCIe support.

Signed-off-by: Tyler Baker 
---
 arch/arm/boot/dts/imx7d-sbc-iot-imx7.dts | 14 ++
 1 file changed, 14 insertions(+)

diff --git a/arch/arm/boot/dts/imx7d-sbc-iot-imx7.dts 
b/arch/arm/boot/dts/imx7d-sbc-iot-imx7.dts
index 50dfdd3..7b21366 100644
--- a/arch/arm/boot/dts/imx7d-sbc-iot-imx7.dts
+++ b/arch/arm/boot/dts/imx7d-sbc-iot-imx7.dts
@@ -127,6 +127,12 @@
>;
};
 
+   pinctrl_pcie: pciegrp {
+   fsl,pins = <
+   MX7D_PAD_EPDC_BDR1__GPIO2_IO29  0x34 /* PCIe 
RST */
+   >;
+   };
+
pinctrl_uart2: uart2grp {
fsl,pins = <
MX7D_PAD_LCD_ENABLE__UART2_DCE_TX   0x79 /* P7-12 */
@@ -201,6 +207,14 @@
};
 };
 
+&pcie {
+   pinctrl-names = "default";
+   pinctrl-0 = <&pinctrl_pcie>;
+   reset-gpio = <&gpio2 29 GPIO_ACTIVE_LOW>;
+   phy-ref-clk = <1>;
+   status = "okay";
+};
+
 &uart2 {
pinctrl-names = "default";
pinctrl-0 = <&pinctrl_uart2>;
-- 
2.9.3

[PATCH 4/8] ARM: dts: imx7s: add dma support

[tyler]

From: Tyler Baker 

Enable dma on all SPI and UART interfaces.

Signed-off-by: Tyler Baker 
---
 arch/arm/boot/dts/imx7s.dtsi | 6 ++
 1 file changed, 6 insertions(+)

diff --git a/arch/arm/boot/dts/imx7s.dtsi b/arch/arm/boot/dts/imx7s.dtsi
index 82ad26e..7b85659 100644
--- a/arch/arm/boot/dts/imx7s.dtsi
+++ b/arch/arm/boot/dts/imx7s.dtsi
@@ -700,6 +700,8 @@
clocks = <&clks IMX7D_ECSPI1_ROOT_CLK>,
<&clks IMX7D_ECSPI1_ROOT_CLK>;
clock-names = "ipg", "per";
+   dmas = <&sdma 0 7 1>, <&sdma 1 7 2>;
+   dma-names = "rx", "tx";
status = "disabled";
};
 
@@ -712,6 +714,8 @@
clocks = <&clks IMX7D_ECSPI2_ROOT_CLK>,
<&clks IMX7D_ECSPI2_ROOT_CLK>;
clock-names = "ipg", "per";
+   dmas = <&sdma 2 7 1>, <&sdma 3 7 2>;
+   dma-names = "rx", "tx";
status = "disabled";
};
 
@@ -724,6 +728,8 @@
clocks = <&clks IMX7D_ECSPI3_ROOT_CLK>,
<&clks IMX7D_ECSPI3_ROOT_CLK>;
clock-names = "ipg", "per";
+   dmas = <&sdma 4 7 1>, <&sdma 5 7 2>;
+   dma-names = "rx", "tx";
status = "disabled";
};
 
-- 
2.9.3

Re: [PATCH v7 1/5] add infrastructure for tagging functions as error injectable

[Josef Bacik]

On Wed, Nov 29, 2017 at 05:59:39PM +0100, Daniel Borkmann wrote:
> On 11/28/2017 09:02 PM, Josef Bacik wrote:
> > On Tue, Nov 28, 2017 at 11:58:41AM -0700, Jonathan Corbet wrote:
> >> On Wed, 22 Nov 2017 16:23:30 -0500
> >> Josef Bacik  wrote:
> >>> From: Josef Bacik 
> >>>
> >>> Using BPF we can override kprob'ed functions and return arbitrary
> >>> values.  Obviously this can be a bit unsafe, so make this feature opt-in
> >>> for functions.  Simply tag a function with KPROBE_ERROR_INJECT_SYMBOL in
> >>> order to give BPF access to that function for error injection purposes.
> >>>
> >>> Signed-off-by: Josef Bacik 
> >>> Acked-by: Ingo Molnar 
> >>> ---
> >>>  arch/x86/include/asm/asm.h|   6 ++
> >>>  include/asm-generic/vmlinux.lds.h |  10 +++
> >>>  include/linux/bpf.h   |  11 +++
> >>>  include/linux/kprobes.h   |   1 +
> >>>  include/linux/module.h|   5 ++
> >>>  kernel/kprobes.c  | 163 
> >>> ++
> >>>  kernel/module.c   |   6 +-
> >>>  7 files changed, 201 insertions(+), 1 deletion(-)
> >>>
> >>> diff --git a/arch/x86/include/asm/asm.h b/arch/x86/include/asm/asm.h
> >>> index b0dc91f4bedc..340f4cc43255 100644
> >>> --- a/arch/x86/include/asm/asm.h
> >>> +++ b/arch/x86/include/asm/asm.h
> >>> @@ -85,6 +85,12 @@
> >>>   _ASM_PTR (entry);   \
> >>>   .popsection
> >>>  
> >>> +# define _ASM_KPROBE_ERROR_INJECT(entry) \
> >>> + .pushsection "_kprobe_error_inject_list","aw" ; \
> >>> + _ASM_ALIGN ;\
> >>> + _ASM_PTR (entry);   \
> >>> + .popseciton
> >>
> >> So this stuff is not my area of greatest expertise, but I do have to wonder
> >> how ".popseciton" can work ... ?
> > 
> > Well fuck, do you want me to send a increment Daniel/Alexei or resend this 
> > patch
> > fixed?  Thanks,
> 
> Sorry for late reply, please rebase + respin the whole series with
> this fixed. There were also few typos in the cover letter / commit
> messages that would be good to get fixed along the way.
> 
> Also, could you debug why this wasn't caught at compile/runtime during
> testing?
> 

Sat down to figure out what was wrong here, and realized I'm just an idiot.  I
was copying the no kprobe stuff, and my grepping did not uncover what
_ASM_NOKPROBE() was used for, so I assumed it was some auto generated magic and
just copied what it did to cover my bases.  Sat down to figure it out and it is
actually called in some assembly files (which is why cscope didn't find it).  So
we don't need _ASM_KPROBE_ERROR_INJECT at all.  I'll drop it and respin and send
it along.  Thanks,

Josef

[PATCH 2/8] ARM: dts: imx7: build imx7d-sbc-iot-imx7 dtb

[tyler]

From: Tyler Baker 

Build the imx7d-sbc-iot-imx7 device tree blob.

Signed-off-by: Tyler Baker 
---
 arch/arm/boot/dts/Makefile | 1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
index d0381e9..0334137 100644
--- a/arch/arm/boot/dts/Makefile
+++ b/arch/arm/boot/dts/Makefile
@@ -515,6 +515,7 @@ dtb-$(CONFIG_SOC_IMX7D) += \
imx7d-nitrogen7.dtb \
imx7d-pico.dtb \
imx7d-sbc-imx7.dtb \
+   imx7d-sbc-iot-imx7.dtb \
imx7d-sdb.dtb \
imx7d-sdb-sht11.dtb \
imx7s-colibri-eval-v3.dtb \
-- 
2.9.3

[PATCH 5/8] ARM: dts: imx7s: add node and supplies for vdd1p2

[tyler]

From: Tyler Baker 

Add the regulator nodes and supplies for vdd1p2. This regulator is
used to power the GPC and USB HSIC PHY.

Signed-off-by: Tyler Baker 
---
 arch/arm/boot/dts/imx7s.dtsi | 17 -
 1 file changed, 16 insertions(+), 1 deletion(-)

diff --git a/arch/arm/boot/dts/imx7s.dtsi b/arch/arm/boot/dts/imx7s.dtsi
index 7b85659..151ab34 100644
--- a/arch/arm/boot/dts/imx7s.dtsi
+++ b/arch/arm/boot/dts/imx7s.dtsi
@@ -522,6 +522,20 @@
anatop-max-voltage = <120>;
anatop-enable-bit = <0>;
};
+
+   reg_1p2: regulator-vdd1p2@220 {
+   compatible = "fsl,anatop-regulator";
+   regulator-name = "vdd1p2";
+   regulator-min-microvolt = <110>;
+   regulator-max-microvolt = <130>;
+   anatop-reg-offset = <0x220>;
+   anatop-vol-bit-shift = <8>;
+   anatop-vol-bit-width = <5>;
+   anatop-min-bit-val = <8>;
+   anatop-min-voltage = <110>;
+   anatop-max-voltage = <130>;
+   anatop-enable-bit = <0>;
+   };
};
 
snvs: snvs@3037 {
@@ -578,7 +592,7 @@
#interrupt-cells = <3>;
interrupt-parent = <&intc>;
#power-domain-cells = <1>;
-
+   vcc-supply = <®_1p2>;
pgc {
#address-cells = <1>;
#size-cells = <0>;
@@ -961,6 +975,7 @@
compatible = "usb-nop-xceiv";
clocks = <&clks IMX7D_USB_HSIC_ROOT_CLK>;
clock-names = "main_clk";
+   vcc-supply = <®_1p2>;
};
 
usdhc1: usdhc@30b4 {
-- 
2.9.3

[PATCH 1/8] ARM: dts: imx7d-sbc-iot: add initial iot gateway dts

[tyler]

From: Tyler Baker 

The Compulab IoT Gateway is based on an NXP i.MX7D, dual core
Cortex-A7 clocking at 1GHz. It supports up to 2GB of DDR3,
and 32GB of eMMC flash. Onboard, there are two gigabit
ethernet controllers, 4 x USB2, RS485, and CAN.

This platform is based on the imx7d-cl-som-imx7 module but
includes a baseboard with additional peripherals
which is what this device tree is meant to describe.

This work has been derrived from the Compulab Linux sources
based on v4.1.

Signed-off-by: Tyler Baker 
Signed-off-by: Ilya Ledvich 
---
 arch/arm/boot/dts/imx7d-sbc-iot-imx7.dts | 238 +++
 1 file changed, 238 insertions(+)
 create mode 100644 arch/arm/boot/dts/imx7d-sbc-iot-imx7.dts

diff --git a/arch/arm/boot/dts/imx7d-sbc-iot-imx7.dts 
b/arch/arm/boot/dts/imx7d-sbc-iot-imx7.dts
new file mode 100644
index 000..50dfdd3
--- /dev/null
+++ b/arch/arm/boot/dts/imx7d-sbc-iot-imx7.dts
@@ -0,0 +1,238 @@
+/*
+ * Support for CompuLab SBC-IOT-iMX7 Single Board Computer
+ *
+ * Copyright (C) 2017 CompuLab Ltd. - http://www.compulab.co.il/
+ * Author: Ilya Ledvich 
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+
+#include "imx7d-cl-som-imx7.dts"
+
+/ {
+   model = "CompuLab SBC-IOT-iMX7";
+   compatible = "compulab,sbc-iot-imx7", "compulab,cl-som-imx7", 
"fsl,imx7d";
+
+   aliases {
+   lcdif = &lcdif;
+   };
+};
+
+&ecspi3 {
+   fsl,spi-num-chipselects = <1>;
+   pinctrl-names = "default";
+   pinctrl-0 = <&pinctrl_ecspi3 &pinctrl_ecspi3_cs>;
+   cs-gpios = <&gpio4 11 0>;
+   status = "okay";
+};
+
+&i2c3 {
+   clock-frequency = <10>;
+   pinctrl-names = "default";
+   pinctrl-0 = <&pinctrl_i2c3>;
+   status = "okay";
+};
+
+&i2c4 {
+   clock-frequency = <10>;
+   pinctrl-names = "default";
+   pinctrl-0 = <&pinctrl_i2c4>;
+   status = "okay";
+
+   eeprom_iot@54 {
+   compatible = "atmel,24c08";
+   reg = <0x54>;
+   pagesize = <16>;
+   };
+
+   dvicape@39 {
+   compatible = "sil164_simple";
+   reg = <0x39>;
+   };
+};
+
+&iomuxc {
+   pinctrl_xpen: xpengrp {
+   fsl,pins = <
+   MX7D_PAD_LCD_DATA13__GPIO3_IO18 0x34 /* P7-4 - 
gpio82 */
+   MX7D_PAD_LCD_DATA12__GPIO3_IO17 0x34 /* P7-5 - 
gpio81 */
+   >;
+   };
+
+   pinctrl_ecspi3: ecspi3grp {
+   fsl,pins = <
+   MX7D_PAD_I2C1_SDA__ECSPI3_MOSI  0xf /* P7-8 */
+   MX7D_PAD_I2C1_SCL__ECSPI3_MISO  0xf /* P7-7 */
+   MX7D_PAD_I2C2_SCL__ECSPI3_SCLK  0xf /* P7-6 */
+   >;
+   };
+
+   pinctrl_ecspi3_cs: ecspi3_cs_grp {
+   fsl,pins = <
+   MX7D_PAD_I2C2_SDA__GPIO4_IO11   0x34 /* P7-9 */
+   >;
+   };
+
+   pinctrl_i2c3: i2c3grp {
+   fsl,pins = <
+   MX7D_PAD_GPIO1_IO09__I2C3_SDA   0x400f /* 
P7-3 */
+   MX7D_PAD_GPIO1_IO08__I2C3_SCL   0x400f /* 
P7-2 */
+   >;
+   };
+
+   pinctrl_i2c4: i2c4grp {
+   fsl,pins = <
+   MX7D_PAD_GPIO1_IO11__I2C4_SDA   0x400f
+   MX7D_PAD_GPIO1_IO10__I2C4_SCL   0x400f
+   >;
+   };
+
+   pinctrl_lcdif_dat: lcdifdatgrp {
+   fsl,pins = <
+   MX7D_PAD_LCD_DATA00__LCD_DATA0  0x79
+   MX7D_PAD_LCD_DATA01__LCD_DATA1  0x79
+   MX7D_PAD_LCD_DATA02__LCD_DATA2  0x79
+   MX7D_PAD_LCD_DATA03__LCD_DATA3  0x79
+   MX7D_PAD_EPDC_DATA04__LCD_DATA4 0x79
+   MX7D_PAD_EPDC_DATA05__LCD_DATA5 0x79
+   MX7D_PAD_EPDC_DATA06__LCD_DATA6 0x79
+   MX7D_PAD_EPDC_DATA07__LCD_DATA7 0x79
+   MX7D_PAD_EPDC_DATA08__LCD_DATA8 0x79
+   MX7D_PAD_EPDC_DATA09__LCD_DATA9 0x79
+   MX7D_PAD_EPDC_DATA10__LCD_DATA100x79
+   MX7D_PAD_EPDC_DATA11__LCD_DATA110x79
+   MX7D_PAD_EPDC_DATA12__LCD_DATA120x79
+   MX7D_PAD_EPDC_DATA13__LCD_DATA130x79
+   MX7D_PAD_EPDC_DATA14__LCD_DATA140x79
+   MX7D_PAD_EPDC_DATA15__LCD_DATA150x79
+   MX7D_PAD_LCD_DATA16__LCD_DATA16 0x79
+   MX7D_PAD_LCD_DATA17__LCD_DATA17 0x79
+   MX7D_PAD_LCD_DATA18__LCD_DATA18 0x79
+ 

Re: [PATCH v2 10/23] firmware: add helper to copy built-in data to pre-alloc buffer

[Luis R. Rodriguez]

On Wed, Nov 29, 2017 at 11:17:15AM +0100, Greg KH wrote:
> On Mon, Nov 20, 2017 at 10:23:56AM -0800, Luis R. Rodriguez wrote:
> > This makes it clearer that the parameters passed are only used for
> > the preallocated buffer option, ie, when a caller uses:
> > 
> > request_firmware_into_buf()
> > 
> > Otherwise this code won't run. We flip the logic just so the actual
> > prellocated buf code is not indented.
> > 
> > Signed-off-by: Luis R. Rodriguez 
> > ---
> >  drivers/base/firmware_class.c | 11 +--
> >  1 file changed, 9 insertions(+), 2 deletions(-)
> > 
> > diff --git a/drivers/base/firmware_class.c b/drivers/base/firmware_class.c
> > index 4f64410fe7e6..aba3f2cbe2f4 100644
> > --- a/drivers/base/firmware_class.c
> > +++ b/drivers/base/firmware_class.c
> > @@ -146,6 +146,14 @@ static struct firmware_cache fw_cache;
> >  extern struct builtin_fw __start_builtin_fw[];
> >  extern struct builtin_fw __end_builtin_fw[];
> >  
> > +static void fw_copy_to_prealloc_buf(struct firmware *fw,
> > +   void *buf, size_t size)
> > +{
> > +   if (!buf || size < fw->size)
> > +   return;
> 
> Shouldn't this return an error?

No, its a no-op when these are not set, and its actually *why* I created
the function. The parameters are *only* useful for the prealloc buf fw
calls. Keeping track of all this while reading the code is actually not
easy and this should make it clearer.

> 
> > +   memcpy(buf, fw->data, fw->size);
> 
> I'll take this, but it feels really odd...

Thanks.

  Luis

[PATCH] sched/isolation: Make NO_HZ_FULL select CPU_ISOLATION

[Paul E. McKenney]

Commit 5c4991e24c69 ("sched/isolation: Split out new
CONFIG_CPU_ISOLATION=y config from CONFIG_NO_HZ_FULL") can result in RCU
CPU stall warnings when running rcutorture with CONFIG_NO_HZ_FULL_ALL=y
and CONFIG_CPU_ISOLATION=n.  These warnings are caused by RCU's
grace-period kthreads sleeping for a few jiffies, but never being
awakened:

[  116.353432] rcu_preempt kthread starved for 9974 jiffies! g4294967208
+c4294967207 f0x0 RCU_GP_WAIT_FQS(3) ->state=0x402 ->cpu=0
[  116.355517] rcu_preempt I 7464 8  2 0x8000
[  116.356543] Call Trace:
[  116.357008]  __schedule+0x493/0x620
[  116.357682]  schedule+0x24/0x40
[  116.358291]  schedule_timeout+0x330/0x3b0
[  116.359024]  ? preempt_count_sub+0xea/0x140
[  116.359806]  ? collect_expired_timers+0xb0/0xb0
[  116.360660]  rcu_gp_kthread+0x6bf/0xef0

This commit therefore makes NO_HZ_FULL select CPU_ISOLATION, which
prevents this behavior and seems like it was the original intention in
any case.

Fixes: 5c4991e24c69 ("sched/isolation: Split out new CONFIG_CPU_ISOLATION=y 
config from CONFIG_NO_HZ_FULL")

Link: https://lkml.kernel.org/r/20171126084203.GE21779@yexl-desktop
Reported-by: kernel test robot 
Signed-off-by: Paul E. McKenney 
Cc: Frederic Weisbecker 
Cc: Thomas Gleixner 
Cc: Chris Metcalf 
Cc: Christoph Lameter 
Cc: Linus Torvalds 
Cc: Luiz Capitulino 
Cc: Mike Galbraith 
Cc: Peter Zijlstra 
Cc: Rik van Riel 
Cc: Wanpeng Li 
Cc: Ingo Molnar 
Cc: John Stultz 

diff --git a/kernel/time/Kconfig b/kernel/time/Kconfig
index e776fc8cc1df..f6b5f19223d6 100644
--- a/kernel/time/Kconfig
+++ b/kernel/time/Kconfig
@@ -95,6 +95,7 @@ config NO_HZ_FULL
select RCU_NOCB_CPU
select VIRT_CPU_ACCOUNTING_GEN
select IRQ_WORK
+   select CPU_ISOLATION
help
 Adaptively try to shutdown the tick whenever possible, even when
 the CPU is running tasks. Typically this requires running a single

Re: [patches] Re: [PATCH 08/10] RISC-V: Set __ARCH_WANT_RENAMEAT to pick up generic version

[Olof Johansson]

On Thu, Nov 30, 2017 at 10:38 AM, Palmer Dabbelt  wrote:
> On Thu, 30 Nov 2017 10:30:32 PST (-0800), Christoph Hellwig wrote:
>>
>> On Wed, Nov 29, 2017 at 05:55:19PM -0800, Olof Johansson wrote:
>>>
>>> In file included from ../lib/audit.c:8:0:
>>> ../include/asm-generic/audit_dir_write.h:30:1: error: '__NR_renameat'
>>> undeclared here (not in a function); did you mean '__NR_renameat2'?
>>
>>
>>
>> I think the audit code should be fixed instead to not expect
>> __NR_renameat, gіven that it's not in the asm-generic default set.

Fair enough.

> For some reason I thought we'd decided to keep renameat in our port despite
> it no longer being in the default list so we could maintain some backwards
> compatibility, but after looking through my email it looks like I was wrong
> about that.
>
> I'm just going to drop this patch for now.  I haven't tried it, but I think
> this might just do the trick?

Seems reasonable to me.


>
> diff --git a/include/asm-generic/audit_dir_write.h
> b/include/asm-generic/audit_dir_write.h
> index da09fb986459..dd5a9dd7a102 100644
> --- a/include/asm-generic/audit_dir_write.h
> +++ b/include/asm-generic/audit_dir_write.h
> @@ -27,7 +27,9 @@ __NR_mknod,
> __NR_mkdirat,
> __NR_mknodat,
> __NR_unlinkat,
> +#ifdef __NR_renameat
> __NR_renameat,
> +#endif
> __NR_linkat,
> __NR_symlinkat,
> #endif

Re: [PATCH] riscv/ftrace: Add basic support

[Steven Rostedt]

On Thu, 30 Nov 2017 16:53:35 +0800
Alan Kao  wrote:

> This patch contains basic ftrace support for RV64I platform.
> Specifically, function tracer (HAVE_FUNCTION_TRACER), function graph
> tracer (HAVE_FUNCTION_GRAPH_TRACER), and a frame pointer test
> (HAVE_FUNCTION_GRAPH_FP_TEST) are implemented following the
> instructions in Documentation/trace/ftrace-design.txt.

Hmm, that document is somewhat out of date. Hopefully it was good
enough. I'm going to need some time to update it.

> 
> Note that the functions in both ftrace.c and setup.c should not be
> hooked with the compiler's -pg option: to prevent infinite self-
> referencing for the former, and to ignore early setup stuff for the latter.

I'm curious to what is in setup.c that ftrace uses.

> 
> Signed-off-by: Alan Kao 
> ---
>  arch/riscv/Kconfig  |   8 +++
>  arch/riscv/include/asm/Kbuild   |   1 -
>  arch/riscv/include/asm/ftrace.h |  23 +++
>  arch/riscv/kernel/Makefile  |   7 ++
>  arch/riscv/kernel/ftrace.c  |  56 
>  arch/riscv/kernel/mcount.S  | 139 
> 
>  6 files changed, 233 insertions(+), 1 deletion(-)
>  create mode 100644 arch/riscv/include/asm/ftrace.h
>  create mode 100644 arch/riscv/kernel/ftrace.c
>  create mode 100644 arch/riscv/kernel/mcount.S
> 
> diff --git a/arch/riscv/Kconfig b/arch/riscv/Kconfig
> index 2e15e85c8f7e..07c3df0919b7 100644
> --- a/arch/riscv/Kconfig
> +++ b/arch/riscv/Kconfig
> @@ -60,6 +60,12 @@ config PAGE_OFFSET
>  config STACKTRACE_SUPPORT
>   def_bool y
>  
> +config TRACE_IRQFLAGS_SUPPORT
> + def_bool y
> +
> +config LOCKDEP_SUPPORT
> + def_bool y

Hmm, not sure the above is needed for function tracing.

> +
>  config RWSEM_GENERIC_SPINLOCK
>   def_bool y
>  
> @@ -112,6 +118,8 @@ config ARCH_RV64I
>   bool "RV64I"
>   select CPU_SUPPORTS_64BIT_KERNEL
>   select 64BIT
> + select HAVE_FUNCTION_TRACER
> + select HAVE_FUNCTION_GRAPH_TRACER
>  
>  endchoice
>  
> diff --git a/arch/riscv/include/asm/Kbuild b/arch/riscv/include/asm/Kbuild
> index 18158be62a2b..680301bfbc4b 100644
> --- a/arch/riscv/include/asm/Kbuild
> +++ b/arch/riscv/include/asm/Kbuild
> @@ -12,7 +12,6 @@ generic-y += errno.h
>  generic-y += exec.h
>  generic-y += fb.h
>  generic-y += fcntl.h
> -generic-y += ftrace.h
>  generic-y += futex.h
>  generic-y += hardirq.h
>  generic-y += hash.h
> diff --git a/arch/riscv/include/asm/ftrace.h b/arch/riscv/include/asm/ftrace.h
> new file mode 100644
> index ..38beadb07ad5
> --- /dev/null
> +++ b/arch/riscv/include/asm/ftrace.h
> @@ -0,0 +1,23 @@
> +/*
> + * Copyright (C) 2017 Andes Technology Corporation
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License version 2 as
> + * published by the Free Software Foundation.
> + *
> + * This program is distributed in the hope that it will be useful,
> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
> + * GNU General Public License for more details.
> + *
> + * You should have received a copy of the GNU General Public License
> + * along with this program.  If not, see .
> + */
> +
> +/*
> + * The graph frame test is not possible if CONFIG_FRAME_POINTER is not 
> enabled.
> + * Check arch/riscv/kernel/mcount.S for detail.
> + */
> +#if defined(CONFIG_FUNCTION_GRAPH_TRACER) && defined(CONFIG_FRAME_POINTER)
> +#define HAVE_FUNCTION_GRAPH_FP_TEST
> +#endif
> diff --git a/arch/riscv/kernel/Makefile b/arch/riscv/kernel/Makefile
> index ab8baf7bd142..15941f3b8363 100644
> --- a/arch/riscv/kernel/Makefile
> +++ b/arch/riscv/kernel/Makefile
> @@ -2,6 +2,11 @@
>  # Makefile for the RISC-V Linux kernel
>  #
>  
> +#ifdef CONFIG_FTRACE
> +CFLAGS_REMOVE_ftrace.o = -pg
> +CFLAGS_REMOVE_setup.o = -pg
> +#endif
> +
>  extra-y += head.o
>  extra-y += vmlinux.lds
>  
> @@ -29,5 +34,7 @@ CFLAGS_setup.o := -mcmodel=medany
>  obj-$(CONFIG_SMP)+= smpboot.o
>  obj-$(CONFIG_SMP)+= smp.o
>  obj-$(CONFIG_MODULES)+= module.o
> +obj-$(CONFIG_FUNCTION_TRACER)+= mcount.o
> +obj-$(CONFIG_FUNCTION_GRAPH_TRACER)  += ftrace.o
>  
>  clean:
> diff --git a/arch/riscv/kernel/ftrace.c b/arch/riscv/kernel/ftrace.c
> new file mode 100644
> index ..e425c8f3f1cd
> --- /dev/null
> +++ b/arch/riscv/kernel/ftrace.c
> @@ -0,0 +1,56 @@
> +/*
> + * arch/riscv/kernel/ftrace.c
> + *
> + * Copyright (C) 2013 Linaro Limited
> + * Author: AKASHI Takahiro 
> + * Copyright (C) 2017 Andes Technology Corporation
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License version 2 as
> + * published by the Free Software Foundation.
> + *
> + * This program is distributed in the hope that it will be useful,
> + * but WITHOUT ANY WARRANTY; without ev

Re: [PATCH] dt-bindings: pinctrl: uniphier: add UniPhier pinctrl binding

[Rob Herring]

On Tue, Nov 28, 2017 at 9:44 PM, Masahiro Yamada
 wrote:
> Hi Rob,
>
>
> 2017-11-29 0:27 GMT+09:00 Rob Herring :
>> On Tue, Nov 28, 2017 at 04:49:45PM +0900, Masahiro Yamada wrote:
>>> The driver has been in the tree for a while, but its binding document
>>> is missing.  Hence, here it is.
>>>
>>> Signed-off-by: Masahiro Yamada 
>>> ---
>>>
>>>  .../pinctrl/socionext,uniphier-pinctrl.txt | 27 
>>> ++
>>>  MAINTAINERS|  1 +
>>>  2 files changed, 28 insertions(+)
>>>  create mode 100644 
>>> Documentation/devicetree/bindings/pinctrl/socionext,uniphier-pinctrl.txt
>>>
>>> diff --git 
>>> a/Documentation/devicetree/bindings/pinctrl/socionext,uniphier-pinctrl.txt 
>>> b/Documentation/devicetree/bindings/pinctrl/socionext,uniphier-pinctrl.txt
>>> new file mode 100644
>>> index 000..8173b12
>>> --- /dev/null
>>> +++ 
>>> b/Documentation/devicetree/bindings/pinctrl/socionext,uniphier-pinctrl.txt
>>> @@ -0,0 +1,27 @@
>>> +UniPhier SoCs pin controller
>>> +
>>> +Required properties:
>>> +- compatible: should be one of the following:
>>> +"socionext,uniphier-ld4-pinctrl"  - for LD4 SoC
>>> +"socionext,uniphier-pro4-pinctrl" - for Pro4 SoC
>>> +"socionext,uniphier-sld8-pinctrl" - for sLD8 SoC
>>> +"socionext,uniphier-pro5-pinctrl" - for Pro5 SoC
>>> +"socionext,uniphier-pxs2-pinctrl" - for PXs2 SoC
>>> +"socionext,uniphier-ld6b-pinctrl" - for LD6b SoC
>>> +"socionext,uniphier-ld11-pinctrl" - for LD11 SoC
>>> +"socionext,uniphier-ld20-pinctrl" - for LD20 SoC
>>> +"socionext,uniphier-pxs3-pinctrl" - for PXs3 SoC
>>> +
>>> +Note:
>>> +The UniPhier pinctrl should be a subnode of a "syscon" compatible node.
>>> +
>>> +Example:
>>> + soc-glue@5f80 {
>>> + compatible = "socionext,uniphier-pro4-soc-glue",
>>> +  "simple-mfd", "syscon";
>>> + reg = <0x5f80 0x2000>;
>>> +
>>> + pinctrl: pinctrl {
>>> + compatible = "socionext,uniphier-pro4-pinctrl";
>>
>> There's not a contiguous register range that can be put here?
>
>
> Right.
>
> I saw SATA PHY registers are inserted among the pinctrl registers.

Okay,

Acked-by: Rob Herring 

> Hardware engineers often make crazy design.

If there's 2 ways to do things, they will find a 3rd way.

Rob

Re: [PATCH v2 16/23] test_firmware: enable custom fallback testing on limited kernel configs

[Luis R. Rodriguez]

On Wed, Nov 29, 2017 at 11:22:35AM +0100, Greg KH wrote:
> On Mon, Nov 20, 2017 at 10:24:02AM -0800, Luis R. Rodriguez wrote:
> > When a kernel is not built with:
> > 
> > CONFIG_HAS_FW_LOADER_USER_HELPER_FALLBACK=y
> > 
> > We don't currently enable testing fw_fallback.sh. For kernels that
> > still enable the fallback mechanism, its possible to use the async
> > request firmware API call request_firmware_nowait() using the custom
> > interface to use the fallback mechanism, so we should be able to test
> > this but we currently cannot.
> > 
> > We can enable testing without CONFIG_HAS_FW_LOADER_USER_HELPER_FALLBACK=y
> > by relying on /proc/config.gz (CONFIG_IKCONFIG_PROC), if present. If you
> > don't have this we'll have no option but to rely on old heuristics for now.
> > 
> > Signed-off-by: Luis R. Rodriguez 
> > ---
> >  tools/testing/selftests/firmware/config |  4 +++
> >  tools/testing/selftests/firmware/fw_fallback.sh | 45 
> > -
> >  2 files changed, 48 insertions(+), 1 deletion(-)
> > 
> > diff --git a/tools/testing/selftests/firmware/config 
> > b/tools/testing/selftests/firmware/config
> > index c8137f70e291..bf634dda0720 100644
> > --- a/tools/testing/selftests/firmware/config
> > +++ b/tools/testing/selftests/firmware/config
> > @@ -1 +1,5 @@
> >  CONFIG_TEST_FIRMWARE=y
> > +CONFIG_FW_LOADER=y
> > +CONFIG_FW_LOADER_USER_HELPER=y
> > +CONFIG_IKCONFIG=y
> > +CONFIG_IKCONFIG_PROC=y
> > diff --git a/tools/testing/selftests/firmware/fw_fallback.sh 
> > b/tools/testing/selftests/firmware/fw_fallback.sh
> > index 722cad91df74..a42e437363d9 100755
> > --- a/tools/testing/selftests/firmware/fw_fallback.sh
> > +++ b/tools/testing/selftests/firmware/fw_fallback.sh
> > @@ -6,7 +6,46 @@
> >  # won't find so that we can do the load ourself manually.
> >  set -e
> >  
> > +PROC_CONFIG="/proc/config.gz"
> > +TEST_DIR=$(dirname $0)
> > +
> >  modprobe test_firmware
> > +if [ ! -f $PROC_CONFIG ]; then
> > +   if modprobe configs 2>/dev/null; then
> > +   echo "Loaded configs module"
> > +   if [ ! -f $PROC_CONFIG ]; then
> > +   echo "You must have the following enabled in your 
> > kernel:" >&2
> > +   cat $TEST_DIR/config >&2
> > +   echo "Resorting to old heuristics" >&2
> > +   fi
> > +   else
> > +   echo "Failed to load configs module, using old heuristics" >&2
> > +   fi
> > +fi
> > +
> > +kconfig_has()
> > +{
> > +   if [ -f $PROC_CONFIG ]; then
> > +   if zgrep -q $1 $PROC_CONFIG 2>/dev/null; then
> > +   echo "yes"
> > +   else
> > +   echo "no"
> > +   fi
> > +   else
> > +   # We currently don't have easy heuristics to infer this
> > +   # so best we can do is just try to use the kernel assuming
> > +   # you had enabled it. This matches the old behaviour.
> > +   if [ "$1" = "CONFIG_FW_LOADER_USER_HELPER_FALLBACK=y" ]; then
> > +   echo "yes"
> > +   elif [ "$1" = "CONFIG_FW_LOADER_USER_HELPER=y" ]; then
> > +   if [ -d /sys/class/firmware/ ]; then
> > +   echo yes
> > +   else
> > +   echo no
> > +   fi
> > +   fi
> > +   fi
> > +}
> 
> Shouldn't these functions be part of the kselftest core so that all
> tests can take advantage of them instead of having to hand-roll them for
> every individual test?

At a first glance it would seem to be nice.

Note that in our case we'd still need a way to work without 
CONFIG_IKCONFIG_PROC,
hence that big else condition, to ensure it works for kernels without
CONFIG_IKCONFIG_PROC set, so we'd still end up with our own fw_kconfig_has(),
and if we had a generic helper it'd look very similar... something like:

fw_kconfig_has()
{
if [ has_proc_config ]; then
echo $(kconfig_has("$1"))
else
# We currently don't have easy heuristics to infer this
# so best we can do is just try to use the kernel assuming
# you had enabled it. This matches the old behaviour.
if [ "$1" = "CONFIG_FW_LOADER_USER_HELPER_FALLBACK=y" ]; then
echo "yes"
elif [ "$1" = "CONFIG_FW_LOADER_USER_HELPER=y" ]; then
if [ -d /sys/class/firmware/ ]; then
echo yes
else
echo no
fi
fi
fi
}

Not sure if there is a big gain then for now.

Shuah, what do you think? Is it worth it? Do we have a generic bash library we
can use?  If not, if I add one, so that other scripts can source it, where
should I add it?

> And is there no way at runtime to tell what the options are and just
> not run that type of test?

For CONFIG_FW_LOADER_USER_HELPER=y yes, its handled in that else condition.

For CONFI

Re: [patches] [PATCH 3/4] RISC-V: Flush I$ when making a dirty page executable

[Olof Johansson]

Hi,

On Mon, Nov 20, 2017 at 10:57 AM, Palmer Dabbelt  wrote:
> From: Andrew Waterman 
>
> The RISC-V ISA allows for instruction caches that are not coherent WRT
> stores, even on a single hart.  As a result, we need to explicitly flush
> the instruction cache whenever marking a dirty page as executable in
> order to preserve the correct system behavior.
>
> Local instruction caches aren't that scary (our implementations actually
> flush the cache, but RISC-V is defined to allow higher-performance
> implementations to exist), but RISC-V defines no way to perform an
> instruction cache shootdown.  When explicitly asked to do so we can
> shoot down remote instruction caches via an IPI, but this is a bit on
> the slow side.
>
> Instead of requiring an IPI to all harts whenever marking a page as
> executable, we simply flush the currently running harts.  In order to
> maintain correct behavior, we additionally mark every other hart as
> needing a deferred instruction cache which will be taken before anything
> runs on it.
>
> Signed-off-by: Andrew Waterman 
> Signed-off-by: Palmer Dabbelt 
> ---
>  arch/riscv/include/asm/cacheflush.h  | 24 ---
>  arch/riscv/include/asm/mmu.h |  4 +++
>  arch/riscv/include/asm/mmu_context.h | 44 +++
>  arch/riscv/include/asm/pgtable.h | 58 
> 
>  arch/riscv/include/asm/tlbflush.h|  2 ++
>  arch/riscv/kernel/smp.c  | 48 +
>  arch/riscv/mm/Makefile   |  2 ++
>  arch/riscv/mm/cacheflush.c   | 23 ++
>  8 files changed, 175 insertions(+), 30 deletions(-)
>  create mode 100644 arch/riscv/mm/cacheflush.c

[...]

> diff --git a/arch/riscv/mm/Makefile b/arch/riscv/mm/Makefile
> index 81f7d9ce6d88..786b5fdec0fd 100644
> --- a/arch/riscv/mm/Makefile
> +++ b/arch/riscv/mm/Makefile
> @@ -2,3 +2,5 @@ obj-y += init.o
>  obj-y += fault.o
>  obj-y += extable.o
>  obj-y += ioremap.o
> +obj-y += dma.o
> +obj-y += cacheflush.o

Looks like dma.c didn't make it into this patch (and didn't already
exist), so builds fail with:

 make[3]: *** No rule to make target 'arch/riscv/mm/dma.o', needed by
'arch/riscv/mm/built-in.o'.


-Olof

Re: [PATCH 07/11] xfs: remove not needed freezing calls

[Rafael J. Wysocki]

On Thu, Nov 30, 2017 at 5:21 PM, Jan Kara  wrote:
> On Wed 29-11-17 15:23:52, Luis R. Rodriguez wrote:
>> This removes superflous freezer calls as they are no longer needed
>> as the VFS now performs filesystem freezing/thaw if the filesystem has
>> support for it.
>>
>> The following Coccinelle rule was used as follows:
>>
>> spatch --sp-file fs-freeze-cleanup.cocci --in-place fs/$FS/
>
> I think your rule misses WQ_FREEZABLE flag for workqueues? That would be
> also good to get rid of...

We need that one (or equivalent) for the runtime PM workqueue at least.

Thanks,
Rafael

Re: [PATCH] KVM: x86: inject exceptions produced by x86_decode_insn

[Eduardo Habkost]

On Wed, Nov 29, 2017 at 04:42:16PM -0200, Eduardo Habkost wrote:
> On Wed, Nov 29, 2017 at 12:44:42PM +0100, Paolo Bonzini wrote:
> > On 29/11/2017 12:44, Eduardo Habkost wrote:
> > > On Mon, Nov 13, 2017 at 09:32:09AM +0100, Paolo Bonzini wrote:
> > >> On 13/11/2017 08:15, Wanpeng Li wrote:
> > >>> 2017-11-10 17:49 GMT+08:00 Paolo Bonzini :
> >  Sometimes, a processor might execute an instruction while another
> >  processor is updating the page tables for that instruction's code page,
> >  but before the TLB shootdown completes.  The interesting case happens
> >  if the page is in the TLB.
> > 
> >  In general, the processor will succeed in executing the instruction and
> >  nothing bad happens.  However, what if the instruction is an MMIO 
> >  access?
> >  If *that* happens, KVM invokes the emulator, and the emulator gets the
> >  updated page tables.  If the update side had marked the code page as 
> >  non
> >  present, the page table walk then will fail and so will 
> >  x86_decode_insn.
> > 
> >  Unfortunately, even though kvm_fetch_guest_virt is correctly returning
> >  X86EMUL_PROPAGATE_FAULT, x86_decode_insn's caller treats the failure as
> >  a fatal error if the instruction cannot simply be reexecuted (as is the
> >  case for MMIO).  And this in fact happened sometimes when rebooting
> >  Windows 2012r2 guests.  Just checking ctxt->have_exception and 
> >  injecting
> >  the exception if true is enough to fix the case.
> > >>>
> > >>> I found the only place which can set ctxt->have_exception is in the
> > >>> function x86_emulate_insn(), and x86_decode_insn() will not set
> > >>> ctxt->have_exception even if kvm_fetch_guest_virt() returns
> > >>> X86_EMUL_PROPAGATE_FAULT.
> > >>
> > >> Hmm, you're right.  Looks like Yanan has been (un)lucky when trying out
> > >> this patch! :(
> > >>
> > >> Yanan, can you double check that you can reproduce the issue with an
> > >> unpatched kernel?  I will work on a kvm-unit-tests testcsae
> > > 
> > > We don't have a kvm-unit-tests reproducer for this yet, right?
> > > 
> > > I'm considering trying to write one, but I don't want to
> > > duplicate work.
> > 
> > No, I haven't written one yet.
> 
> The reproducer (not a full test case) is quite simple, see patch below.
> 
> Now, I've noticed something interesting when running the
> reproducer:

There's something else that makes the bug hard to reproduce: as
soon as I set RSP to a valid address in inregs before calling
trap_emulator(), the bug is not reproducible anymore.

But if I keep RSP=0, I won't be able to validate the bug fix
because I won't be able to configure a working #PF handler.

This alone makes the bug not reproducible anymore:

diff --git a/x86/emulator.c b/x86/emulator.c
index 72cb035..a7e61ff 100644
--- a/x86/emulator.c
+++ b/x86/emulator.c
@@ -1104,6 +1104,8 @@ static void test_illegal_movbe(void)

 static void test_fetch_failure(void *mem, void *alt_insn_page)
 {
+   void *stack = alloc_page();
+   inregs = (struct regs){ .rsp = (u64)stack+1024 };
trap_emulator(mem, NULL, NULL);
 }


This is what I see:

When we don't have a stack (inregs.rsp=0),
reexecute_instruction() is preventing the emulation failure from
happening on the I/O instruction VM exits, and KVM keeps entering
the VM in a loop (getting thousands of I/O instruction VM exits)
until we finally get an EPT misconfig VM exit on GVA
0xfff8.

When we set up inregs.rsp, reexecute_instruction() also prevents
the emulation from failing on the I/O instruction VM exits, but
instead of a EPT misconfig VM exit, we get EPT violation VM exit
after a few thousand iterations, and the page fault is delivered
to the VCPU.

I don't know why KVM loops so many times on I/O instruction VM
exits before finally getting an emulation failure (or finally
delivering a page fault, if a stack is available), but this might
explain why the bug is so hard to reproduce under normal
circumstances.



> 
> If the test_fetch_failure() call happens before we touch
> pci-testdev through *mem (like in the patch below), we get an
> emulation failure like the one Yanan saw:
> 
>   $ /usr/bin/qemu-system-x86_64 -nodefaults -device pc-testdev -device 
> isa-debug-exit,iobase=0xf4,iosize=0x4 -vnc none -serial stdio -device 
> pci-testdev -machine accel=kvm -kernel ./x86/emulator.flat # -initrd 
> /tmp/tmp.RCPjppRp8i
>   enabling apic
>   paging enabled
>   cr0 = 80010011
>   cr3 = 45e000
>   cr4 = 20
>   KVM internal error. Suberror: 1
>   emulation failure
>   RAX= RBX= RCX= 
> RDX=
>   RSI= RDI= RBP= 
> RSP=
>   R8 = R9 = R10= 
> R11=
>   R12= R13= R14= 
> R15=
>   RIP=c08a RFL=00010002 [---] 

Re: [PATCH v2 19/23] firmware: add debug facility to emulate forcing sysfs fallback

[Luis R. Rodriguez]

On Wed, Nov 29, 2017 at 11:28:04AM +0100, Greg KH wrote:
> On Mon, Nov 20, 2017 at 10:24:05AM -0800, Luis R. Rodriguez wrote:
> > diff --git a/drivers/base/firmware_debug.c b/drivers/base/firmware_debug.c
> > new file mode 100644
> > index ..f2817eb6f480
> > --- /dev/null
> > +++ b/drivers/base/firmware_debug.c
> > @@ -0,0 +1,34 @@
> > +// SPDX-License-Identifier: GPL-2.0
> > +/* Firmware dubugging interface */
> > +#define pr_fmt(fmt) KBUILD_MODNAME ": " fmt
> > +
> > +#include 
> > +#include "firmware_debug.h"
> > +
> > +struct firmware_debug fw_debug;
> > +
> > +static struct dentry *debugfs_firmware;
> > +
> > +int __init register_fw_debugfs(void)
> > +{
> > +   debugfs_firmware = debugfs_create_dir("firmware", NULL);
> > +   if (!debugfs_firmware)
> > +   return -ENOMEM;
> 
> You never need to check the return value of a debugfs call, you should
> not care about it, nor do anything different in your code.  The value
> returned can always be passed back into any other debugfs call when
> needed.

Neat, so all uses as in the above are wrong eh?

> > +
> > +   if (!debugfs_create_bool("force_sysfs_fallback", S_IRUSR | S_IWUSR,
> > +debugfs_firmware,
> > +&fw_debug.force_sysfs_fallback))
> 
> Same here, you don't care.

OK!

> 
> > +   goto err_out;
> > +
> > +   return 0;
> > +err_out:
> > +   debugfs_remove_recursive(debugfs_firmware);
> 
> You didn't create any files, why recursive?
> Anyway, not needed.

Wouldn't this take care of removing the two bool files I add in one shot later?

> > +   debugfs_firmware = NULL;
> > +   return -ENOMEM;
> > +}
> > +
> > +void unregister_fw_debugfs(void)
> > +{
> > +   debugfs_remove_recursive(debugfs_firmware);
> > +   debugfs_firmware = NULL;
> 
> Why set this to NULL?

OK, will avoid.

> > diff --git a/drivers/base/firmware_loader.c b/drivers/base/firmware_loader.c
> > index 43b97a8137f7..b2b52ba9f245 100644
> > --- a/drivers/base/firmware_loader.c
> > +++ b/drivers/base/firmware_loader.c
> > @@ -36,6 +36,7 @@
> >  #include 
> >  
> >  #include "base.h"
> > +#include "firmware_debug.h"
> >  
> >  MODULE_AUTHOR("Manuel Estrada Sainz");
> >  MODULE_DESCRIPTION("Multi purpose firmware loading support");
> > @@ -1158,6 +1159,9 @@ static bool fw_force_sysfs_fallback(unsigned int 
> > opt_flags)
> >  #else
> >  static bool fw_force_sysfs_fallback(unsigned int opt_flags)
> >  {
> > +   if (fw_debug_force_sysfs_fallback())
> > +   return true;
> > +
> > if (!(opt_flags & FW_OPT_USERHELPER))
> > return false;
> > return true;
> > @@ -1913,10 +1917,14 @@ static int __init firmware_class_init(void)
> > /* No need to unfold these on exit */
> > fw_cache_init();
> >  
> > -   ret = register_fw_pm_ops();
> > +   ret = register_fw_debugfs();
> > if (ret)
> > return ret;
> 
> Again you don't care about the state of debugfs.  Did you test this on a
> system without CONFIG_DEBUGFS enabled?

Hrm, nope. Will fix it up. Thanks for the review.

  Luis

Re: [PATCH] list_lru: Prefetch neighboring list entries before acquiring lock

[Dave Chinner]

On Thu, Nov 30, 2017 at 08:54:04AM -0500, Waiman Long wrote:
> On 11/29/2017 07:42 PM, Dave Chinner wrote:
> > On Wed, Nov 29, 2017 at 01:53:19PM -0800, Andrew Morton wrote:
> >> On Wed, 29 Nov 2017 09:17:34 -0500 Waiman Long  wrote:
> >>
> >>> The list_lru_del() function removes the given item from the LRU list.
> >>> The operation looks simple, but it involves writing into the cachelines
> >>> of the two neighboring list entries in order to get the deletion done.
> >>> That can take a while if the cachelines aren't there yet, thus
> >>> prolonging the lock hold time.
> >>>
> >>> To reduce the lock hold time, the cachelines of the two neighboring
> >>> list entries are now prefetched before acquiring the list_lru_node's
> >>> lock.
> >>>
> >>> Using a multi-threaded test program that created a large number
> >>> of dentries and then killed them, the execution time was reduced
> >>> from 38.5s to 36.6s after applying the patch on a 2-socket 36-core
> >>> 72-thread x86-64 system.
> >> Patch looks good.
> >>
> >> Can someone (Dave?) please explain why list_lru_del() supports deletion
> >> of an already list_empty(item)?
> >> This seems a rather dangerous thing to
> >> encourage.  Use cases I can think of are:
> >>
> >> a) item is already reliably deleted, so why the heck was the caller
> >>calling list_lru_del() and 
> > Higher level operations can race. e.g. caller looks up an object,
> > finds it on the LRU, takes a reference. Then calls list_lru_del()
> > to remove it from the LRU. It blocks 'cause it can't get the list
> > lock as
> >
> > ... Meanwhile, the list shrinker is running, sees the object on the
> > LRU list, sees it has a valid reference count, does lazy LRU cleanup
> > by runnning list_lru_isolate() on the object which removes it from
> > the LRU list. Eventually it drops the list lock, and 
> >
> > ... the original thread gets the lock in list_lru_del() and sees the
> > object has already been removed from the LRU
> >
> > IOWs, this sort of boilerplate code is potentially dangerous if
> > list_lru_del() can't handle items that have already been removed
> > from the list:
> >
> > if (!list_empty(&obj->lru))
> > list_lru_del(&obj->lru);
> >
> > Because this:
> >
> > if (!list_empty(&obj->lru))
> > 
> > 
> > list_lru_del(&obj->lru);
> > 
> >
> > Would result in bad things happening
> >
> > And, from that perspective, the racy shortcut in the proposed patch
> > is wrong, too. Prefetch is fine, but in general shortcutting list
> > empty checks outside the internal lock isn't.
> 
> For the record, I add one more list_empty() check at the beginning of
> list_lru_del() in the patch for 2 purpose:
> 1. it allows the code to bail out early.

Which is what I said was wrong. You haven't addressed why you think
it's safe to add racy specualtive checks to this code in your quest
for speed.

Also, I'm curious about is how much of the gain is from the
prefetching, and how much of the gain is from avoiding the lock
altogether by the early bailout...

> 2. It make sure the cacheline of the list_head entry itself is loaded.
> 
> Other than that, I only add a likely() qualifier to the existing
> list_empty() check within the lock critical region.

Yup, but in many cases programmers get the static branch prediction
hints are wrong. In this case, you are supposing that nobody ever
calls list_lru_del() on objects that aren't on the lru. That's not
true - inodes that are being evicted may never have been on the LRU
at all, but we still call through list_lru_del() so it can determine
the LRU state correctly (e.g. cache cold rm -rf workloads)

IOWs, I'm pretty sure even just adding static branch prediction
hints here is wrong

Cheers,

Dave.
-- 
Dave Chinner
da...@fromorbit.com

Re: [PATCH v13 0/7] cgroup-aware OOM killer

[Andrew Morton]

On Thu, 30 Nov 2017 15:28:17 + Roman Gushchin  wrote:

> This patchset makes the OOM killer cgroup-aware.

Thanks, I'll grab these.

There has been controversy over this patchset, to say the least.  I
can't say that I followed it closely!  Could those who still have
reservations please summarise their concerns and hopefully suggest a
way forward?

Re: [PATCH 2/2] kvm: x86: fix KVM_XEN_HVM_CONFIG ioctl

[Kees Cook]

On Thu, Oct 26, 2017 at 6:45 AM, Paolo Bonzini  wrote:
> This ioctl is obsolete (it was used by Xenner as far as I know) but
> still let's not break it gratuitously...  Its handler is copying
> directly into struct kvm.  Go through a bounce buffer instead, with
> the added benefit that we can actually do something useful with the
> flags argument---the previous code was exiting with -EINVAL but still
> doing the copy.
>
> This technically is a userspace ABI breakage, but since no one should be
> using the ioctl, it's a good occasion to see if someone actually
> complains.
>
> Cc: kernel-harden...@lists.openwall.com
> Cc: Kees Cook 
> Cc: Radim Krčmář 
> Signed-off-by: Paolo Bonzini 
> ---
>  arch/x86/kvm/x86.c | 7 ---
>  1 file changed, 4 insertions(+), 3 deletions(-)
>
> diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c
> index 272320eb328c..f32fbfb833b3 100644
> --- a/arch/x86/kvm/x86.c
> +++ b/arch/x86/kvm/x86.c
> @@ -4187,13 +4187,14 @@ long kvm_arch_vm_ioctl(struct file *filp,
> mutex_unlock(&kvm->lock);
> break;
> case KVM_XEN_HVM_CONFIG: {
> +   struct kvm_xen_hvm_config xhc;
> r = -EFAULT;
> -   if (copy_from_user(&kvm->arch.xen_hvm_config, argp,
> -  sizeof(struct kvm_xen_hvm_config)))
> +   if (copy_from_user(&xhc, argp, sizeof(xhc)))
> goto out;
> r = -EINVAL;
> -   if (kvm->arch.xen_hvm_config.flags)
> +   if (xhc.flags)
> goto out;
> +   memcpy(&kvm->arch.xen_hvm_config, &xhc, sizeof(xhc));
> r = 0;
> break;
> }
> --
> 2.14.2
>

Hi Paolo,

Since this didn't make it via my usercopy tree, do you want to take it
via KVM? It is a stand-alone fix, AIUI.

Thanks,

-Kees

-- 
Kees Cook
Pixel Security

Re: BUG: sleeping function called from invalid context at arch/x86/mm/fault.c:LINE

[Eric Biggers]

On Thu, Nov 30, 2017 at 11:55:00AM -0800, syzbot wrote:
> Call Trace:
>  __dump_stack lib/dump_stack.c:17 [inline]
>  dump_stack+0x194/0x257 lib/dump_stack.c:53
>  ___might_sleep+0x2b2/0x470 kernel/sched/core.c:6060
>  __might_sleep+0x95/0x190 kernel/sched/core.c:6013
>  __do_page_fault+0x350/0xc90 arch/x86/mm/fault.c:1372
>  do_page_fault+0xee/0x720 arch/x86/mm/fault.c:1504
>  page_fault+0x22/0x30 arch/x86/entry/entry_64.S:1094
> RIP: 0010:virt_to_cache mm/slab.c:400 [inline]
> RIP: 0010:kfree+0xb2/0x250 mm/slab.c:3802
> RSP: 0018:8801cc82f780 EFLAGS: 00010046
> RAX:  RBX: 8801cc82f948 RCX: 
> RDX: ea0007320bc0 RSI:  RDI: 8801cc82f948
> RBP: 8801cc82f7a0 R08: ed003a54e4dc R09: 
> R10: 0001 R11: ed003a54e4db R12: 0286
> R13:  R14: 8801cc82f948 R15: 8801cc82f8b0
>  blkcipher_walk_done+0x72b/0xde0 crypto/blkcipher.c:139
>  encrypt+0x50a/0xaf0 crypto/salsa20_generic.c:208
>  skcipher_crypt_blkcipher crypto/skcipher.c:622 [inline]
>  skcipher_decrypt_blkcipher+0x213/0x310 crypto/skcipher.c:640
>  crypto_skcipher_decrypt include/crypto/skcipher.h:463 [inline]
>  _skcipher_recvmsg crypto/algif_skcipher.c:144 [inline]
>  skcipher_recvmsg+0xa54/0xf20 crypto/algif_skcipher.c:165
>  sock_recvmsg_nosec net/socket.c:805 [inline]
>  sock_recvmsg+0xc9/0x110 net/socket.c:812
>  ___sys_recvmsg+0x29b/0x630 net/socket.c:2207
>  __sys_recvmsg+0xe2/0x210 net/socket.c:2252
>  SYSC_recvmsg net/socket.c:2264 [inline]
>  SyS_recvmsg+0x2d/0x50 net/socket.c:2259
>  entry_SYSCALL_64_fastpath+0x1f/0x96

Yet another duplicate of the Salsa20 bug:

#syz dup: WARNING: suspicious RCU usage (3)

Looks like this one was incorrectly attributed to x86 rather than crypto?

kfree() is being called with preempt_count corrupted *and* with an uninitialized
pointer, so it can cause quite a few different problems...

Eric

Re: [PATCH] list_lru: Prefetch neighboring list entries before acquiring lock

[Andrew Morton]

On Thu, 30 Nov 2017 08:54:04 -0500 Waiman Long  wrote:

> > And, from that perspective, the racy shortcut in the proposed patch
> > is wrong, too. Prefetch is fine, but in general shortcutting list
> > empty checks outside the internal lock isn't.
> 
> For the record, I add one more list_empty() check at the beginning of
> list_lru_del() in the patch for 2 purpose:
> 1. it allows the code to bail out early.
> 2. It make sure the cacheline of the list_head entry itself is loaded.
> 
> Other than that, I only add a likely() qualifier to the existing
> list_empty() check within the lock critical region.

But it sounds like Dave thinks that unlocked check should be removed?

How does this adendum look?

From: Andrew Morton 
Subject: list_lru-prefetch-neighboring-list-entries-before-acquiring-lock-fix

include prefetch.h, remove unlocked list_empty() test, per Dave

Cc: Dave Chinner 
Cc: Johannes Weiner 
Cc: Vladimir Davydov 
Cc: Waiman Long 
Signed-off-by: Andrew Morton 
---

 mm/list_lru.c |5 ++---
 1 file changed, 2 insertions(+), 3 deletions(-)

diff -puN 
mm/list_lru.c~list_lru-prefetch-neighboring-list-entries-before-acquiring-lock-fix
 mm/list_lru.c
--- 
a/mm/list_lru.c~list_lru-prefetch-neighboring-list-entries-before-acquiring-lock-fix
+++ a/mm/list_lru.c
@@ -8,6 +8,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -135,13 +136,11 @@ bool list_lru_del(struct list_lru *lru,
/*
 * Prefetch the neighboring list entries to reduce lock hold time.
 */
-   if (unlikely(list_empty(item)))
-   return false;
prefetchw(item->prev);
prefetchw(item->next);
 
spin_lock(&nlru->lock);
-   if (likely(!list_empty(item))) {
+   if (!list_empty(item)) {
l = list_lru_from_kmem(nlru, item);
list_del_init(item);
l->nr_items--;
_

Re: [PATCH] list_lru: Prefetch neighboring list entries before acquiring lock

[Waiman Long]

On 11/30/2017 03:47 PM, Andrew Morton wrote:
> On Thu, 30 Nov 2017 08:54:04 -0500 Waiman Long  wrote:
>
>>> And, from that perspective, the racy shortcut in the proposed patch
>>> is wrong, too. Prefetch is fine, but in general shortcutting list
>>> empty checks outside the internal lock isn't.
>> For the record, I add one more list_empty() check at the beginning of
>> list_lru_del() in the patch for 2 purpose:
>> 1. it allows the code to bail out early.
>> 2. It make sure the cacheline of the list_head entry itself is loaded.
>>
>> Other than that, I only add a likely() qualifier to the existing
>> list_empty() check within the lock critical region.
> But it sounds like Dave thinks that unlocked check should be removed?
>
> How does this adendum look?
>
> From: Andrew Morton 
> Subject: list_lru-prefetch-neighboring-list-entries-before-acquiring-lock-fix
>
> include prefetch.h, remove unlocked list_empty() test, per Dave
>
> Cc: Dave Chinner 
> Cc: Johannes Weiner 
> Cc: Vladimir Davydov 
> Cc: Waiman Long 
> Signed-off-by: Andrew Morton 
> ---
>
>  mm/list_lru.c |5 ++---
>  1 file changed, 2 insertions(+), 3 deletions(-)
>
> diff -puN 
> mm/list_lru.c~list_lru-prefetch-neighboring-list-entries-before-acquiring-lock-fix
>  mm/list_lru.c
> --- 
> a/mm/list_lru.c~list_lru-prefetch-neighboring-list-entries-before-acquiring-lock-fix
> +++ a/mm/list_lru.c
> @@ -8,6 +8,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  #include 
>  #include 
>  #include 
> @@ -135,13 +136,11 @@ bool list_lru_del(struct list_lru *lru,
>   /*
>* Prefetch the neighboring list entries to reduce lock hold time.
>*/
> - if (unlikely(list_empty(item)))
> - return false;
>   prefetchw(item->prev);
>   prefetchw(item->next);
>  
>   spin_lock(&nlru->lock);
> - if (likely(!list_empty(item))) {
> + if (!list_empty(item)) {
>   l = list_lru_from_kmem(nlru, item);
>   list_del_init(item);
>   l->nr_items--;
> _
>
Yes, that look good to me.

Thanks for fixing that.

Cheers,
Longman

Re: [PATCH v2 1/2] cros_ec: Split cros_ec_devs module

[Guenter Roeck]

On Mon, Nov 20, 2017 at 8:15 AM, Thierry Escande
 wrote:
> This patch splits the cros_ec_devs module in two parts with a
> cros_ec_dev module responsible for handling MFD devices registration and
> a cros_ec_ctl module responsible for handling the various user-space
> interfaces.
>
> For consistency purpose, the driver name for the cros_ec_dev module is
> now cros-ec-dev instead of cros-ec-ctl.
>
> In the next commit, the new cros_ec_dev module will be moved to the MFD
> subtree so mfd_add_devices() calls are not done from outside MFD.
>
> Signed-off-by: Thierry Escande 

Tested-by: Guenter Roeck 

> ---
>  drivers/mfd/cros_ec.c  | 4 ++--
>  drivers/platform/chrome/Kconfig| 4 
>  drivers/platform/chrome/Makefile   | 8 
>  drivers/platform/chrome/cros_ec_debugfs.c  | 2 ++
>  drivers/platform/chrome/cros_ec_dev.c  | 7 +--
>  drivers/platform/chrome/cros_ec_lightbar.c | 4 
>  drivers/platform/chrome/cros_ec_sysfs.c| 3 +++
>  drivers/platform/chrome/cros_ec_vbc.c  | 1 +
>  8 files changed, 25 insertions(+), 8 deletions(-)
>
> diff --git a/drivers/mfd/cros_ec.c b/drivers/mfd/cros_ec.c
> index b0ca5a4c..d610241 100644
> --- a/drivers/mfd/cros_ec.c
> +++ b/drivers/mfd/cros_ec.c
> @@ -40,13 +40,13 @@ static struct cros_ec_platform pd_p = {
>  };
>
>  static const struct mfd_cell ec_cell = {
> -   .name = "cros-ec-ctl",
> +   .name = "cros-ec-dev",
> .platform_data = &ec_p,
> .pdata_size = sizeof(ec_p),
>  };
>
>  static const struct mfd_cell ec_pd_cell = {
> -   .name = "cros-ec-ctl",
> +   .name = "cros-ec-dev",
> .platform_data = &pd_p,
> .pdata_size = sizeof(pd_p),
>  };
> diff --git a/drivers/platform/chrome/Kconfig b/drivers/platform/chrome/Kconfig
> index 0ad6e29..bffc892 100644
> --- a/drivers/platform/chrome/Kconfig
> +++ b/drivers/platform/chrome/Kconfig
> @@ -41,12 +41,16 @@ config CHROMEOS_PSTORE
>  config CROS_EC_CHARDEV
>  tristate "Chrome OS Embedded Controller userspace device interface"
>  depends on MFD_CROS_EC
> +select CROS_EC_CTL
>  ---help---
>This driver adds support to talk with the ChromeOS EC from 
> userspace.
>
>If you have a supported Chromebook, choose Y or M here.
>The module will be called cros_ec_dev.
>
> +config CROS_EC_CTL
> +tristate
> +
>  config CROS_EC_LPC
>  tristate "ChromeOS Embedded Controller (LPC)"
>  depends on MFD_CROS_EC && ACPI && (X86 || COMPILE_TEST)
> diff --git a/drivers/platform/chrome/Makefile 
> b/drivers/platform/chrome/Makefile
> index a077b1f..bc239ec 100644
> --- a/drivers/platform/chrome/Makefile
> +++ b/drivers/platform/chrome/Makefile
> @@ -2,10 +2,10 @@
>
>  obj-$(CONFIG_CHROMEOS_LAPTOP)  += chromeos_laptop.o
>  obj-$(CONFIG_CHROMEOS_PSTORE)  += chromeos_pstore.o
> -cros_ec_devs-objs  := cros_ec_dev.o cros_ec_sysfs.o \
> -  cros_ec_lightbar.o cros_ec_vbc.o \
> -  cros_ec_debugfs.o
> -obj-$(CONFIG_CROS_EC_CHARDEV)  += cros_ec_devs.o
> +cros_ec_ctl-objs   := cros_ec_sysfs.o cros_ec_lightbar.o 
> \
> +  cros_ec_vbc.o cros_ec_debugfs.o
> +obj-$(CONFIG_CROS_EC_CTL)  += cros_ec_ctl.o
> +obj-$(CONFIG_CROS_EC_CHARDEV)  += cros_ec_dev.o
>  cros_ec_lpcs-objs  := cros_ec_lpc.o cros_ec_lpc_reg.o
>  cros_ec_lpcs-$(CONFIG_CROS_EC_LPC_MEC) += cros_ec_lpc_mec.o
>  obj-$(CONFIG_CROS_EC_LPC)  += cros_ec_lpcs.o
> diff --git a/drivers/platform/chrome/cros_ec_debugfs.c 
> b/drivers/platform/chrome/cros_ec_debugfs.c
> index 4cc66f4..d0b8ce0 100644
> --- a/drivers/platform/chrome/cros_ec_debugfs.c
> +++ b/drivers/platform/chrome/cros_ec_debugfs.c
> @@ -390,6 +390,7 @@ int cros_ec_debugfs_init(struct cros_ec_dev *ec)
> debugfs_remove_recursive(debug_info->dir);
> return ret;
>  }
> +EXPORT_SYMBOL(cros_ec_debugfs_init);
>
>  void cros_ec_debugfs_remove(struct cros_ec_dev *ec)
>  {
> @@ -399,3 +400,4 @@ void cros_ec_debugfs_remove(struct cros_ec_dev *ec)
> debugfs_remove_recursive(ec->debug_info->dir);
> cros_ec_cleanup_console_log(ec->debug_info);
>  }
> +EXPORT_SYMBOL(cros_ec_debugfs_remove);
> diff --git a/drivers/platform/chrome/cros_ec_dev.c 
> b/drivers/platform/chrome/cros_ec_dev.c
> index cf6c4f0..daf0ffd 100644
> --- a/drivers/platform/chrome/cros_ec_dev.c
> +++ b/drivers/platform/chrome/cros_ec_dev.c
> @@ -28,6 +28,8 @@
>  #include "cros_ec_debugfs.h"
>  #include "cros_ec_dev.h"
>
> +#define DRV_NAME "cros-ec-dev"
> +
>  /* Device variables */
>  #define CROS_MAX_DEV 128
>  static int ec_major;
> @@ -461,7 +463,7 @@ static int ec_device_remove(struct platform_device *pdev)
>  }
>
>  static const struct platform_device_id cros_ec_id[] = {
> -   { "cros-ec-ctl", 0 },
> +   { DRV_NAME, 0 },
>

Re: [PATCH v2 2/2] cros_ec: Move cros_ec_dev module to drivers/mfd

[Guenter Roeck]

On Mon, Nov 20, 2017 at 8:15 AM, Thierry Escande
 wrote:
> The cros_ec_dev module is responsible for registering the MFD devices
> attached to the ChromeOS EC. This patch moves this module to drivers/mfd
> so calls to mfd_add_devices() are not done from outside the MFD subtree
> anymore.
>
> Signed-off-by: Thierry Escande 

Tested-by: Guenter Roeck 

> ---
>  drivers/mfd/Kconfig|  10 +
>  drivers/mfd/Makefile   |   1 +
>  drivers/mfd/cros_ec_dev.c  | 552 
>  drivers/mfd/cros_ec_dev.h  |  52 +++
>  drivers/platform/chrome/Kconfig|  10 -
>  drivers/platform/chrome/Makefile   |   1 -
>  drivers/platform/chrome/cros_ec_debugfs.c  |   3 -
>  drivers/platform/chrome/cros_ec_debugfs.h  |  27 --
>  drivers/platform/chrome/cros_ec_dev.c  | 553 
> -
>  drivers/platform/chrome/cros_ec_dev.h  |  52 ---
>  drivers/platform/chrome/cros_ec_lightbar.c |   2 -
>  drivers/platform/chrome/cros_ec_sysfs.c|   2 -
>  include/linux/mfd/cros_ec.h|   4 +
>  13 files changed, 619 insertions(+), 650 deletions(-)
>  create mode 100644 drivers/mfd/cros_ec_dev.c
>  create mode 100644 drivers/mfd/cros_ec_dev.h
>  delete mode 100644 drivers/platform/chrome/cros_ec_debugfs.h
>  delete mode 100644 drivers/platform/chrome/cros_ec_dev.c
>  delete mode 100644 drivers/platform/chrome/cros_ec_dev.h
>
> diff --git a/drivers/mfd/Kconfig b/drivers/mfd/Kconfig
> index 1d20a80..538a2ae 100644
> --- a/drivers/mfd/Kconfig
> +++ b/drivers/mfd/Kconfig
> @@ -222,6 +222,16 @@ config MFD_CROS_EC_SPI
>   response time cannot be guaranteed, we support ignoring
>   'pre-amble' bytes before the response actually starts.
>
> +config MFD_CROS_EC_CHARDEV
> +tristate "Chrome OS Embedded Controller userspace device interface"
> +depends on MFD_CROS_EC
> +select CROS_EC_CTL
> +---help---
> +  This driver adds support to talk with the ChromeOS EC from 
> userspace.
> +
> +  If you have a supported Chromebook, choose Y or M here.
> +  The module will be called cros_ec_dev.
> +
>  config MFD_ASIC3
> bool "Compaq ASIC3"
> depends on GPIOLIB && ARM
> diff --git a/drivers/mfd/Makefile b/drivers/mfd/Makefile
> index d9474ad..fcd8af8 100644
> --- a/drivers/mfd/Makefile
> +++ b/drivers/mfd/Makefile
> @@ -17,6 +17,7 @@ cros_ec_core-$(CONFIG_ACPI)   += cros_ec_acpi_gpe.o
>  obj-$(CONFIG_MFD_CROS_EC)  += cros_ec_core.o
>  obj-$(CONFIG_MFD_CROS_EC_I2C)  += cros_ec_i2c.o
>  obj-$(CONFIG_MFD_CROS_EC_SPI)  += cros_ec_spi.o
> +obj-$(CONFIG_MFD_CROS_EC_CHARDEV) += cros_ec_dev.o
>  obj-$(CONFIG_MFD_EXYNOS_LPASS) += exynos-lpass.o
>
>  rtsx_pci-objs  := rtsx_pcr.o rts5209.o rts5229.o rtl8411.o 
> rts5227.o rts5249.o
> diff --git a/drivers/mfd/cros_ec_dev.c b/drivers/mfd/cros_ec_dev.c
> new file mode 100644
> index 000..e4fafdd
> --- /dev/null
> +++ b/drivers/mfd/cros_ec_dev.c
> @@ -0,0 +1,552 @@
> +/*
> + * cros_ec_dev - expose the Chrome OS Embedded Controller to user-space
> + *
> + * Copyright (C) 2014 Google, Inc.
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License as published by
> + * the Free Software Foundation; either version 2 of the License, or
> + * (at your option) any later version.
> + *
> + * 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 "cros_ec_dev.h"
> +
> +#define DRV_NAME "cros-ec-dev"
> +
> +/* Device variables */
> +#define CROS_MAX_DEV 128
> +static int ec_major;
> +
> +static const struct attribute_group *cros_ec_groups[] = {
> +   &cros_ec_attr_group,
> +   &cros_ec_lightbar_attr_group,
> +   &cros_ec_vbc_attr_group,
> +   NULL,
> +};
> +
> +static struct class cros_class = {
> +   .owner  = THIS_MODULE,
> +   .name   = "chromeos",
> +   .dev_groups = cros_ec_groups,
> +};
> +
> +/* Basic communication */
> +static int ec_get_version(struct cros_ec_dev *ec, char *str, int maxlen)
> +{
> +   struct ec_response_get_version *resp;
> +   static const char * const current_image_name[] = {
> +   "unknown", "read-only", "read-write", "invalid",
> +   };
> +   struct cros_ec_command *msg;
> +   int ret;
> +
> +   msg = kmalloc(sizeof(*msg) + sizeof(*resp), GFP_KERNEL);
> +   if (!msg)
> +   return -ENOMEM;
> +
> +   msg->versi

Re: waitqueue lockdep annotation

[Andrew Morton]

On Thu, 30 Nov 2017 06:20:35 -0800 Christoph Hellwig  wrote:

> Hi all,
> 
> this series adds a strategic lockdep_assert_held to __wake_up_common
> to ensure callers really do hold the wait_queue_head lock when calling
> the unlocked wake_up variants.  It turns out epoll did not do this
> for a fairly common path (hit all the time by systemd during bootup),
> so the second patch fixed this instance as well.

What are the runtime effects of the epoll bug?

[PATCH] KEYS: reject NULL restriction string when type is specified

[Eric Biggers]

From: Eric Biggers 

keyctl_restrict_keyring() allows through a NULL restriction when the
"type" is non-NULL, which causes a NULL pointer dereference in
asymmetric_lookup_restriction() when it calls strcmp() on the
restriction string.

But no key types actually use a "NULL restriction" to mean anything, so
update keyctl_restrict_keyring() to reject it with EINVAL.

Reported-by: syzbot 
Fixes: 97d3aa0f3134 ("KEYS: Add a lookup_restriction function for the 
asymmetric key type")
Cc:  # v4.12+
Signed-off-by: Eric Biggers 
---
 security/keys/keyctl.c | 24 ++--
 1 file changed, 10 insertions(+), 14 deletions(-)

diff --git a/security/keys/keyctl.c b/security/keys/keyctl.c
index 76d22f726ae4..1ffe60bb2845 100644
--- a/security/keys/keyctl.c
+++ b/security/keys/keyctl.c
@@ -1588,9 +1588,8 @@ long keyctl_session_to_parent(void)
  * The caller must have Setattr permission to change keyring restrictions.
  *
  * The requested type name may be a NULL pointer to reject all attempts
- * to link to the keyring. If _type is non-NULL, _restriction can be
- * NULL or a pointer to a string describing the restriction. If _type is
- * NULL, _restriction must also be NULL.
+ * to link to the keyring.  In this case, _restriction must also be NULL.
+ * Otherwise, both _type and _restriction must be non-NULL.
  *
  * Returns 0 if successful.
  */
@@ -1598,7 +1597,6 @@ long keyctl_restrict_keyring(key_serial_t id, const char 
__user *_type,
 const char __user *_restriction)
 {
key_ref_t key_ref;
-   bool link_reject = !_type;
char type[32];
char *restriction = NULL;
long ret;
@@ -1607,31 +1605,29 @@ long keyctl_restrict_keyring(key_serial_t id, const 
char __user *_type,
if (IS_ERR(key_ref))
return PTR_ERR(key_ref);
 
+   ret = -EINVAL;
if (_type) {
-   ret = key_get_type_from_user(type, _type, sizeof(type));
-   if (ret < 0)
+   if (!_restriction)
goto error;
-   }
 
-   if (_restriction) {
-   if (!_type) {
-   ret = -EINVAL;
+   ret = key_get_type_from_user(type, _type, sizeof(type));
+   if (ret < 0)
goto error;
-   }
 
restriction = strndup_user(_restriction, PAGE_SIZE);
if (IS_ERR(restriction)) {
ret = PTR_ERR(restriction);
goto error;
}
+   } else {
+   if (_restriction)
+   goto error;
}
 
-   ret = keyring_restrict(key_ref, link_reject ? NULL : type, restriction);
+   ret = keyring_restrict(key_ref, _type ? type : NULL, restriction);
kfree(restriction);
-
 error:
key_ref_put(key_ref);
-
return ret;
 }
 
-- 
2.15.0.531.g2ccb3012c9-goog

Re: [PATCH 00/11] fs: use freeze_fs on suspend/hibernate

[Bart Van Assche]

On Thu, 2017-11-30 at 20:42 +0100, Luis R. Rodriguez wrote:
> On Thu, Nov 30, 2017 at 05:01:13PM +, Bart Van Assche wrote:
> > The md resync
> > thread must be stopped before a system is frozen. Today the md driver uses
> > the kthread freezing mechanism for that purpose. Do you have a plan for
> > handling the more complicated scenarios, e.g. a filesystem that exists on 
> > top
> > of an md device where the md device uses one or more files as backing store
> > and with the loop driver between the md device and the files?
> 
> Nope not yet. It seems you have given this some thought though so you're 
> help here is greatly appreciated. In fact the way we should see the long
> term 'kill kthread freezing' effort should be a collaborative one. I've
> never touched md, so folks more familiar with md should give this some
> thought.
> 
> Can for instance md register_pm_notifier() and register_syscore_ops()
> and do handy work to pause some work to replace kthread freezing?
> Note that I believe a pm notifier is needed in case syscore_suspend()
> is not called, say on a suspend fail.

Sorry but I don't think that a solution can be based on a notifier mechanism.
Freezing has to happen in the order in which drivers and filesystems have
been stacked (filesystem > md device > filesystem for the above example).
Since the order in which notifiers are called is related to the order in
which notifiers have been registered I don't think that a solution for the
example I described can be based on notifiers. What I think we need is a
mechanism for traversing the storage stack that includes block drivers and
an equivalent of freeze_fs() for block drivers. Freezing should occur by
calling the freeze_fs() methods for each storage layer starting at the top of
the storage stack and proceeding towards the bottom.

Bart.

Re: [PATCH] list_lru: Prefetch neighboring list entries before acquiring lock

[Waiman Long]

On 11/30/2017 03:38 PM, Dave Chinner wrote:
> On Thu, Nov 30, 2017 at 08:54:04AM -0500, Waiman Long wrote:
>>
>> For the record, I add one more list_empty() check at the beginning of
>> list_lru_del() in the patch for 2 purpose:
>> 1. it allows the code to bail out early.
> Which is what I said was wrong. You haven't addressed why you think
> it's safe to add racy specualtive checks to this code in your quest
> for speed.
>
> Also, I'm curious about is how much of the gain is from the
> prefetching, and how much of the gain is from avoiding the lock
> altogether by the early bailout...

The early bailout doesn't improve the test at all. In the case of
dentries, there is a flag that indicates that the dentry is in the LRU
list. So list_lru_del is only called when it is in the LRU list.

>> 2. It make sure the cacheline of the list_head entry itself is loaded.
>>
>> Other than that, I only add a likely() qualifier to the existing
>> list_empty() check within the lock critical region.
> Yup, but in many cases programmers get the static branch prediction
> hints are wrong. In this case, you are supposing that nobody ever
> calls list_lru_del() on objects that aren't on the lru. That's not
> true - inodes that are being evicted may never have been on the LRU
> at all, but we still call through list_lru_del() so it can determine
> the LRU state correctly (e.g. cache cold rm -rf workloads)
>
> IOWs, I'm pretty sure even just adding static branch prediction
> hints here is wrong

In the case of dentries, the static branch is right. However it may not
be true for other users of list_lru, so I am OK to take them out. Thanks
for the explanation.

Cheers,
Longman

[PATCH] NFS: allow name_to_handle_at() to work for Amazon EFS.

[NeilBrown]

Amazon EFS provides an NFSv4.1 filesystem which appears to use
(close to) full length (128 byte) file handles.
This causes the handle reported by name_to_handle_at() to exceed
MAX_HANDLE_SZ, resulting in
  EOVERFLOW if 128 bytes were requested, or
  EINVAL if the size reported by the previous call was requested.

To fix this, increase MAX_HANDLE_SIZE a little, and add a BUILD_BUG
so that this sort of inconsistent error reporting won't happen again.

Link: https://github.com/systemd/systemd/issues/7082#issuecomment-347380436
Signed-off-by: NeilBrown 
---

Sorry for the scatter-gun To: list.  This is really more of a VFS patch
than an NFS patch and sending patches in either direction has been a bit
hit-and-miss lately, so I'm hoping Andrew will take it unless someone
else objects or beats him to it...

Thanks,
NeilBrown

 fs/nfs/export.c  | 2 ++
 include/linux/exportfs.h | 7 +--
 2 files changed, 7 insertions(+), 2 deletions(-)

diff --git a/fs/nfs/export.c b/fs/nfs/export.c
index 83fd09fc8f77..23b2fc3ab2bb 100644
--- a/fs/nfs/export.c
+++ b/fs/nfs/export.c
@@ -39,6 +39,8 @@ nfs_encode_fh(struct inode *inode, __u32 *p, int *max_len, 
struct inode *parent)
size_t fh_size = offsetof(struct nfs_fh, data) + server_fh->size;
int len = EMBED_FH_OFF + XDR_QUADLEN(fh_size);
 
+   BUILD_BUG_ON_MSG(EMBED_FH_OFF + NFS_MAXFHSIZE > MAX_HANDLE_SZ,
+   "MAX_HANDLE_SZ is too small");
dprintk("%s: max fh len %d inode %p parent %p",
__func__, *max_len, inode, parent);
 
diff --git a/include/linux/exportfs.h b/include/linux/exportfs.h
index 0d3037419bc7..e7ab1b071c5e 100644
--- a/include/linux/exportfs.h
+++ b/include/linux/exportfs.h
@@ -11,8 +11,11 @@ struct iomap;
 struct super_block;
 struct vfsmount;
 
-/* limit the handle size to NFSv4 handle size now */
-#define MAX_HANDLE_SZ 128
+/* Must be larger than NFSv4 file handle, but small
+ * enough for an on-stack allocation. overlayfs doesn't
+ * want this too close to 255.
+ */
+#define MAX_HANDLE_SZ 200
 
 /*
  * The fileid_type identifies how the file within the filesystem is encoded.
-- 
2.14.0.rc0.dirty



signature.asc
Description: PGP signature

Re: Creating cyclecounter and lock member in timecounter structure [ Was Re: [RFC 1/4] drm/i915/perf: Add support to correlate GPU timestamp with system time]

[Saeed Mahameed]

On Mon, Nov 27, 2017 at 2:05 AM, Sagar Arun Kamble
 wrote:
>
>
> On 11/24/2017 7:01 PM, Thomas Gleixner wrote:
>>
>> On Fri, 24 Nov 2017, Sagar Arun Kamble wrote:
>>>
>>> On 11/24/2017 12:29 AM, Thomas Gleixner wrote:

 On Thu, 23 Nov 2017, Sagar Arun Kamble wrote:
>
> We needed inputs on possible optimization that can be done to
> timecounter/cyclecounter structures/usage.
> This mail is in response to review of patch
> https://patchwork.freedesktop.org/patch/188448/.
>
> As Chris's observation below, about dozen of timecounter users in the
> kernel
> have below structures
> defined individually:
>
> spinlock_t lock;
> struct cyclecounter cc;
> struct timecounter tc;
>
> Can we move lock and cc to tc? That way it will be convenient.
> Also it will allow unifying the locking/overflow watchdog handling
> across
> all
> drivers.

 Looks like none of the timecounter usage sites has a real need to
 separate
 timecounter and cyclecounter.
>>>
>>> Yes. Will share patch for this change.
>>>
 The lock is a different question. The locking of the various drivers
 differs and I have no idea how you want to handle that. Just sticking
 the
 lock into the datastructure and then not making use of it in the
 timercounter code and leave it to the callsites does not make sense.
>>>
>>> Most of the locks are held around timecounter_read. In some instances it
>>> is held when cyclecounter is updated standalone or is updated along with
>>> timecounter calls.  Was thinking if we move the lock in timecounter
>>> functions, drivers just have to do locking around its operations on
>>> cyclecounter. But then another problem I see is there are variation of
>>> locking calls like lock_irqsave, lock_bh, write_lock_irqsave (some using
>>> rwlock_t). Should this all locking be left to driver only then?
>>
>> You could have the lock in the struct and protect the inner workings in
>> the
>> related core functions.
>>
>> That might remove locking requirements from some of the callers and the
>> others still have their own thing around it.
>
>
> For drivers having static/fixed cyclecounter, we can rely only on lock
> inside timecounter.
> Most of the network drivers update cyclecounter at runtime and they will
> have to rely on two locks if
> we add one to timecounter. This may not be efficient for them. Also the lock
> in timecounter has to be less restrictive (may be seqlock) I guess.
>
> Cc'd Mellanox list for inputs on this.
>
> I have started feeling that the current approach of drivers managing the
> locks is the right one so better leave the
> lock out of timecounter.
>

I agree here,

In mlx5 we rely on our own read/write lock to serialize access to
mlx5_clock struct (mlx5 timecounter and cyclecounter).
the access is not as simple as
lock()
call time_counter_API
unlock()

Sometimes we also explicitly update/adjust timecycles counters with
mlx5 specific calculations after we read the timecounter all inside
our lock.
e.g.
@mlx5_ptp_adjfreq()

write_lock_irqsave(&clock->lock, flags);
timecounter_read(&clock->tc);
clock->cycles.mult = neg_adj ? clock->nominal_c_mult - diff :
   clock->nominal_c_mult + diff;
write_unlock_irqrestore(&clock->lock, flags);

So i don't think it will be a simple task to have a generic thread
safe timecounter API, without the need to specifically adjust it for
all driver use-cases.
Also as said above, in runtime it is not obvious in which context the
timecounter will be accessed irq/soft irq/user.

let's keep it as is, and let the driver decide which locking scheme is
most suitable for it.

Thanks,
Saeed.

>> Thanks,
>>
>> tglx
>
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 00/11] fs: use freeze_fs on suspend/hibernate

[Dave Chinner]

On Thu, Nov 30, 2017 at 08:53:52PM +, Bart Van Assche wrote:
> On Thu, 2017-11-30 at 20:42 +0100, Luis R. Rodriguez wrote:
> > On Thu, Nov 30, 2017 at 05:01:13PM +, Bart Van Assche wrote:
> > > The md resync
> > > thread must be stopped before a system is frozen. Today the md driver uses
> > > the kthread freezing mechanism for that purpose. Do you have a plan for
> > > handling the more complicated scenarios, e.g. a filesystem that exists on 
> > > top
> > > of an md device where the md device uses one or more files as backing 
> > > store
> > > and with the loop driver between the md device and the files?
> > 
> > Nope not yet. It seems you have given this some thought though so you're 
> > help here is greatly appreciated. In fact the way we should see the long
> > term 'kill kthread freezing' effort should be a collaborative one. I've
> > never touched md, so folks more familiar with md should give this some
> > thought.
> > 
> > Can for instance md register_pm_notifier() and register_syscore_ops()
> > and do handy work to pause some work to replace kthread freezing?
> > Note that I believe a pm notifier is needed in case syscore_suspend()
> > is not called, say on a suspend fail.
> 
> Sorry but I don't think that a solution can be based on a notifier mechanism.
> Freezing has to happen in the order in which drivers and filesystems have
> been stacked (filesystem > md device > filesystem for the above example).

Yup, we need top down stack freezing. We get that at the filesystem
layer by the reverse order superblock iteration - that freezes newer
mounts before older mounts, so things like filesystems on loopback
freeze before the lower filesystem that hosts the loopback image.

I think what we need is the opposite of the "freeze_bdev()" interface.
That allows a block device to freeze the superblock on the block
device. i.e. when the block device needs to quiesce (e.g. for a
snapshot to be taken) it locks the filesystem and waits for it to
quiesce, then does what it needs to and unlocks the filesystem.

ISTM that you're asking for the opposite of this - a call that
allows the superblock to quiesce the underlying block device into a
known, unchanging state.  This would allow MD/dm to suspend whatever
on-going maintenance operations it has in progress until the
filesystem says "we need you to start again" when it gets a thaw
call

Cheers,

Dave.
-- 
Dave Chinner
da...@fromorbit.com

Re: [RFC] Rebasing the IDR

[Matthew Wilcox]

On Thu, Nov 30, 2017 at 08:56:43PM +0100, Daniel Vetter wrote:
> Adding dri-devel, I think a pile of those are in drm.

Yeah, quite a lot!  This is a good thing; means you didn't invent your
own custom ID allocator.

> On Thu, Nov 30, 2017 at 6:36 PM, Matthew Wilcox  wrote:
> > About 40 of the approximately 180 users of the IDR in the kernel are
> > "1-based" instead of "0-based".  That is, they never want to have ID 0
> > allocated; they want to see IDs allocated between 1 and N.  Usually, that's
> > expressed like this:
> >
> > /* Get the user-visible handle using idr. */
> > ret = idr_alloc(&file_priv->object_idr, obj, 1, 0, GFP_KERNEL);
> >

> Just quick context on why we do this: We need to marshal/demarshal
> NULL in a ton of our ioctls, mapping that to 0 is natural.

Yep.  You could actually store NULL at IDR index 0; the IDR distinguishes
between an allocated NULL and an unallocated entry.

> And yes I very much like this, and totally fine with trading an
> idr_init_base when we can nuke the explicit index ranges at every
> alloc side instead. So if you give me an idr_alloc function that
> doesn't take a range as icing, that would be great.

I think the API is definitely bad at making the easy things easy ... I'd
call the current idr_alloc() idr_alloc_range().  But I don't want to change
200+ call sites, so I'll settle for a new name.

ret = idr_get(&file_priv->object_idr, obj, GFP_KERNEL);

I have another new API in the works for after the xarray lands and we can
simplify the locking --

int __must_check idr_alloc_u32(struct idr *idr, void *ptr,
unsigned int *nextid, unsigned int max, gfp_t gfp)

The trick is that we store to nextid before inserting the ptr into the
xarray, so this will enable more users to dispense with their own locking
(or avoid awful i-looked-up-this-object-but-it's-not-initialised-so-
pretend-i-didn't-see-it dances).

(There's also an idr_alloc_ul for completeness, but I think this is
actually a bad idea; the radix tree gets pretty unwieldy at large sparse
indices and I don't want to encourage people to go outside unsigned int).

Re: [PATCH] mtd: nand: gpmi: replace _manual_ swap with swap macro

[Boris Brezillon]

On Fri, 3 Nov 2017 15:31:47 -0500
"Gustavo A. R. Silva"  wrote:

> Make use of the swap macro and remove unnecessary variables swap.
> This makes the code easier to read and maintain.
> 
> This code was detected with the help of Coccinelle.

Applied.

Thanks,

Boris

> 
> Signed-off-by: Gustavo A. R. Silva 
> ---
>  drivers/mtd/nand/gpmi-nand/gpmi-nand.c | 16 
>  1 file changed, 4 insertions(+), 12 deletions(-)
> 
> diff --git a/drivers/mtd/nand/gpmi-nand/gpmi-nand.c 
> b/drivers/mtd/nand/gpmi-nand/gpmi-nand.c
> index 50f8d4a..9e365d4 100644
> --- a/drivers/mtd/nand/gpmi-nand/gpmi-nand.c
> +++ b/drivers/mtd/nand/gpmi-nand/gpmi-nand.c
> @@ -1487,12 +1487,8 @@ static int gpmi_ecc_read_page_raw(struct mtd_info *mtd,
>* See the layout description for a detailed explanation on why this
>* is needed.
>*/
> - if (this->swap_block_mark) {
> - u8 swap = tmp_buf[0];
> -
> - tmp_buf[0] = tmp_buf[mtd->writesize];
> - tmp_buf[mtd->writesize] = swap;
> - }
> + if (this->swap_block_mark)
> + swap(tmp_buf[0], tmp_buf[mtd->writesize]);
>  
>   /*
>* Copy the metadata section into the oob buffer (this section is
> @@ -1615,12 +1611,8 @@ static int gpmi_ecc_write_page_raw(struct mtd_info 
> *mtd,
>* See the layout description for a detailed explanation on why this
>* is needed.
>*/
> - if (this->swap_block_mark) {
> - u8 swap = tmp_buf[0];
> -
> - tmp_buf[0] = tmp_buf[mtd->writesize];
> - tmp_buf[mtd->writesize] = swap;
> - }
> + if (this->swap_block_mark)
> + swap(tmp_buf[0], tmp_buf[mtd->writesize]);
>  
>   chip->write_buf(mtd, tmp_buf, mtd->writesize + mtd->oobsize);
>  

Re: [PATCH resend] mm/page_alloc: fix comment is __get_free_pages

[Andrew Morton]

On Thu, 30 Nov 2017 07:53:35 +0100 Michal Hocko  wrote:

> > mm...  So we have a caller which hopes to be getting highmem pages but
> > isn't.  Caller then proceeds to pointlessly kmap the page and wonders
> > why it isn't getting as much memory as it would like on 32-bit systems,
> > etc.
> 
> How he can kmap the page when he gets a _virtual_ address?

doh.

> > I do think we should help ferret out such bogosity.  A WARN_ON_ONCE
> > would suffice.
> 
> This function has always been about lowmem pages. I seriously doubt we
> have anybody confused and asking for a highmem page in the kernel. I
> haven't checked that but it would already blow up as VM_BUG_ON tends to
> be enabled on many setups.

OK.  But silently accepting __GFP_HIGHMEM is a bit weird - callers
shouldn't be doing that in the first place.

I wonder what happens if we just remove the WARN_ON and pass any
__GFP_HIGHMEM straight through.  The caller gets a weird address from
page_to_virt(highmem page) and usually goes splat?  Good enough
treatment for something which never happens anyway?

Re: [PATCH v2 2/2] ARM: dts: at91: disable the nxp,se97b SMBUS timeout on the TSE-850

[Guenter Roeck]

On Thu, Nov 30, 2017 at 07:46:09PM +0100, Peter Rosin wrote:
> On 2017-11-30 18:26, Alexandre Belloni wrote:
> > On 30/11/2017 at 09:16:38 -0800, Guenter Roeck wrote:
> >> On Wed, Nov 29, 2017 at 09:56:29PM +0100, Alexandre Belloni wrote:
> >>> On 29/11/2017 at 12:53:11 -0800, Guenter Roeck wrote:
>  On Mon, Nov 27, 2017 at 05:31:01PM +0100, Peter Rosin wrote:
> > The I2C adapter driver is sometimes slow, causing the SCL line to
> > be stuck low for more than the stipulated SMBUS timeout of 25-35 ms.
> > This causes the client device to give up which in turn causes silent
> > corruption of data. So, disable the SMBUS timeout in the client device.
> >
> > Signed-off-by: Peter Rosin 
> 
>  Acked-by: Guenter Roeck 
> 
>  I assume this will be sent upstream through an arm tree.
> 
> >>>
> >>> Yes, I'm applying it right now.
> >>>
> >> Are you going to apply the patch for 4.15, or queue it up for 4.16 ?
> >> I have been arguing with myself if this is a feature or a bug fix.
> >> So far I queued the driver change up for 4.16, but I am open to
> >> applying it to 4.15. Any thoughts ?
> >>
> > 
> > I was wondering that myself. I'm open to have it as a fix in 4.15. Or
> > maybe Peter can send the series to stable if he needs it in 4.14.
> > 
> > Peter, what do you think/want?
> 
> TL;DR Either way is fine.
> 
> I think it's a bugfix; it fixes real problems where the application
> misbehave due to faulty content when reading from an eeprom. I'm
> expecting to make a new release for the hw in question RSN and these
> are the only local patches. So, it would be nice if they made it to
> 4.14.x before my release happens. However, it's not like it's difficult
> to rebase the patches should that backport not happen or take too long.
> 
Good enough for me. I'll send it as a fix for v4.15, with Cc: stable.

Guenter

> The badness started to happen much more frequently due to some timing
> difference affecting the i2c bus driver, but in theory it's a problem
> that has been there from the start. I have just not noticed it before...
> 
> Cheers,
> Peter
> --
> To unsubscribe from this list: send the line "unsubscribe linux-hwmon" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] hwmon: (max31785) Add OF device ID table

[Guenter Roeck]

On Thu, Nov 30, 2017 at 07:12:57PM +0100, Javier Martinez Canillas wrote:
> The driver doesn't have a struct of_device_id table but supported devices
> are registered via Device Trees. This is working on the assumption that a
> I2C device registered via OF will always match a legacy I2C device ID and
> that the MODALIAS reported will always be of the form i2c:.
> 
> But this could change in the future so the correct approach is to have an
> OF device ID table if the devices are registered via OF.
> 
> Before this patch:
> 
> $ modinfo drivers/hwmon/pmbus/max31785.ko | grep alias
> alias:  i2c:max31785a
> alias:  i2c:max31785
> 
> After this patch:
> 
> $ modinfo drivers/hwmon/pmbus/max31785.ko | grep alias
> alias:  i2c:max31785a
> alias:  i2c:max31785
> alias:  of:N*T*Cmaxim,max31785aC*
> alias:  of:N*T*Cmaxim,max31785a
> alias:  of:N*T*Cmaxim,max31785C*
> alias:  of:N*T*Cmaxim,max31785
> 
> Signed-off-by: Javier Martinez Canillas 

Applied.

Thanks,
Guenter

> ---
> 
>  drivers/hwmon/pmbus/max31785.c | 9 +
>  1 file changed, 9 insertions(+)
> 
> diff --git a/drivers/hwmon/pmbus/max31785.c b/drivers/hwmon/pmbus/max31785.c
> index 9313849d5160..4666b5e95159 100644
> --- a/drivers/hwmon/pmbus/max31785.c
> +++ b/drivers/hwmon/pmbus/max31785.c
> @@ -100,9 +100,18 @@ static const struct i2c_device_id max31785_id[] = {
>  
>  MODULE_DEVICE_TABLE(i2c, max31785_id);
>  
> +static const struct of_device_id max31785_of_match[] = {
> + { .compatible = "maxim,max31785" },
> + { .compatible = "maxim,max31785a" },
> + { },
> +};
> +
> +MODULE_DEVICE_TABLE(of, max31785_of_match);
> +
>  static struct i2c_driver max31785_driver = {
>   .driver = {
>   .name = "max31785",
> + .of_match_table = max31785_of_match,
>   },
>   .probe = max31785_probe,
>   .remove = pmbus_do_remove,
> -- 
> 2.14.3
> 

Re: [PATCH] block, bfq: remove batches of confusing ifdefs

[Jens Axboe]

On 11/28/2017 02:37 AM, Paolo Valente wrote:
> Commit a33801e8b473 ("block, bfq: move debug blkio stats behind
> CONFIG_DEBUG_BLK_CGROUP") introduced two batches of confusing ifdefs:
> one reported in [1], plus a similar one in another function. This
> commit removes both batches, in the way suggested in [1].

Some comments below.

> +static inline void bfq_update_dispatch_stats(struct request *rq,
> +  spinlock_t *queue_lock,
> +  struct bfq_queue *in_serv_queue,
> +  bool idle_timer_disabled)
> +{

Don't pass in the queue lock. The normal convention is to pass in the
queue, thus making this:

static void bfq_update_dispatch_stats(struct request_queue *q,
  struct request *rq,
  struct bfq_queue *in_serv_queue,
  bool idle_timer_disabled)

which also gets rid of the inline. In general, never inline anything.
The compiler should figure it out for you. This function is way too big
to inline, plus the cost of what it's doing completely dwarfes function
call overhead.


>
> + struct bfq_queue *bfqq = rq ? RQ_BFQQ(rq) : NULL;
>  
> -#if defined(CONFIG_BFQ_GROUP_IOSCHED) && defined(CONFIG_DEBUG_BLK_CGROUP)
> - bfqq = rq ? RQ_BFQQ(rq) : NULL;
>   if (!idle_timer_disabled && !bfqq)
> - return rq;
> + return;
>  
>   /*
>* rq and bfqq are guaranteed to exist until this function
> @@ -3732,7 +3713,7 @@ static struct request *bfq_dispatch_request(struct 
> blk_mq_hw_ctx *hctx)
>* In addition, the following queue lock guarantees that
>* bfqq_group(bfqq) exists as well.
>*/
> - spin_lock_irq(hctx->queue->queue_lock);
> + spin_lock_irq(queue_lock);
>   if (idle_timer_disabled)
>   /*
>* Since the idle timer has been disabled,
> @@ -3751,9 +3732,37 @@ static struct request *bfq_dispatch_request(struct 
> blk_mq_hw_ctx *hctx)
>   bfqg_stats_set_start_empty_time(bfqg);
>   bfqg_stats_update_io_remove(bfqg, rq->cmd_flags);
>   }
> - spin_unlock_irq(hctx->queue->queue_lock);
> + spin_unlock_irq(queue_lock);
> +}
> +#else
> +static inline void bfq_update_dispatch_stats(struct request *rq,
> +  spinlock_t *queue_lock,
> +  struct bfq_queue *in_serv_queue,
> +  bool idle_timer_disabled) {}
>  #endif
>  
> +static struct request *bfq_dispatch_request(struct blk_mq_hw_ctx *hctx)
> +{
> + struct bfq_data *bfqd = hctx->queue->elevator->elevator_data;
> + struct request *rq;
> + struct bfq_queue *in_serv_queue;
> + bool waiting_rq, idle_timer_disabled;
> +
> + spin_lock_irq(&bfqd->lock);
> +
> + in_serv_queue = bfqd->in_service_queue;
> + waiting_rq = in_serv_queue && bfq_bfqq_wait_request(in_serv_queue);
> +
> + rq = __bfq_dispatch_request(hctx);
> +
> + idle_timer_disabled =
> + waiting_rq && !bfq_bfqq_wait_request(in_serv_queue);
> +
> + spin_unlock_irq(&bfqd->lock);
> +
> + bfq_update_dispatch_stats(rq, hctx->queue->queue_lock, in_serv_queue,
> +   idle_timer_disabled);
> +
>   return rq;
>  }
>  
> @@ -4276,16 +4285,46 @@ static bool __bfq_insert_request(struct bfq_data 
> *bfqd, struct request *rq)
>   return idle_timer_disabled;
>  }
>  
> +#if defined(CONFIG_BFQ_GROUP_IOSCHED) && defined(CONFIG_DEBUG_BLK_CGROUP)
> +static inline void bfq_update_insert_stats(struct bfq_queue *bfqq,
> +spinlock_t *queue_lock,
> +bool idle_timer_disabled,
> +unsigned int cmd_flags)
> +{
> + if (!bfqq)
> + return;
> +
> + /*
> +  * bfqq still exists, because it can disappear only after
> +  * either it is merged with another queue, or the process it
> +  * is associated with exits. But both actions must be taken by
> +  * the same process currently executing this flow of
> +  * instructions.
> +  *
> +  * In addition, the following queue lock guarantees that
> +  * bfqq_group(bfqq) exists as well.
> +  */
> + spin_lock_irq(queue_lock);
> + bfqg_stats_update_io_add(bfqq_group(bfqq), bfqq, cmd_flags);
> + if (idle_timer_disabled)
> + bfqg_stats_update_idle_time(bfqq_group(bfqq));
> + spin_unlock_irq(queue_lock);
> +}
> +#else
> +static inline void bfq_update_insert_stats(struct bfq_queue *bfqq,
> +spinlock_t *queue_lock,
> +bool idle_timer_disabled,
> +unsigned int cmd_flags) {}
> +#endif

Ditto here, kill the inlines.

In general though, good improvem

[PATCH] net: ethernet: ixp4xx_eth: Use dma_pool_zalloc

[Vasyl Gomonovych]

Replacing dma_pool_alloc and memset with a single call to dma_pool_zalloc

Signed-off-by: Vasyl Gomonovych 
---
 drivers/net/ethernet/xscale/ixp4xx_eth.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/drivers/net/ethernet/xscale/ixp4xx_eth.c 
b/drivers/net/ethernet/xscale/ixp4xx_eth.c
index aee55c03def0..02f7f3e3da8d 100644
--- a/drivers/net/ethernet/xscale/ixp4xx_eth.c
+++ b/drivers/net/ethernet/xscale/ixp4xx_eth.c
@@ -1108,10 +1108,10 @@ static int init_queues(struct port *port)
return -ENOMEM;
}
 
-   if (!(port->desc_tab = dma_pool_alloc(dma_pool, GFP_KERNEL,
- &port->desc_tab_phys)))
+   port->desc_tab = dma_pool_zalloc(dma_pool, GFP_KERNEL,
+&port->desc_tab_phys);
+   if (!port->desc_tab)
return -ENOMEM;
-   memset(port->desc_tab, 0, POOL_ALLOC_SIZE);
memset(port->rx_buff_tab, 0, sizeof(port->rx_buff_tab)); /* tables */
memset(port->tx_buff_tab, 0, sizeof(port->tx_buff_tab));
 
-- 
1.9.1

[PATCH v2] NTB: Rename NTB messaging API methods

[Serge Semin]

There is a common methods signature form used over all the NTB API
like functions naming scheme, arguments names and order, etc.
Recently added NTB messaging API IO callbacks were named a bit
different so should be renamed to be in compliance with the rest
of the API.

Signed-off-by: Serge Semin 
---
 drivers/ntb/hw/idt/ntb_hw_idt.c | 27 ---
 include/linux/ntb.h | 34 --
 2 files changed, 28 insertions(+), 33 deletions(-)

diff --git a/drivers/ntb/hw/idt/ntb_hw_idt.c b/drivers/ntb/hw/idt/ntb_hw_idt.c
index 0cd79f367f7c..6fb87c0f0d97 100644
--- a/drivers/ntb/hw/idt/ntb_hw_idt.c
+++ b/drivers/ntb/hw/idt/ntb_hw_idt.c
@@ -1744,20 +1744,19 @@ static int idt_ntb_msg_clear_mask(struct ntb_dev *ntb, 
u64 mask_bits)
  * idt_ntb_msg_read() - read message register with specified index
  * (NTB API callback)
  * @ntb:   NTB device context.
- * @midx:  Message register index
  * @pidx:  OUT - Port index of peer device a message retrieved from
- * @msg:   OUT - Data
+ * @midx:  Message register index
  *
  * Read data from the specified message register and source register.
  *
- * Return: zero on success, negative error if invalid argument passed.
+ * Return: inbound message register value.
  */
-static int idt_ntb_msg_read(struct ntb_dev *ntb, int midx, int *pidx, u32 *msg)
+static u32 idt_ntb_msg_read(struct ntb_dev *ntb, int *pidx, int midx)
 {
struct idt_ntb_dev *ndev = to_ndev_ntb(ntb);
 
if (midx < 0 || IDT_MSG_CNT <= midx)
-   return -EINVAL;
+   return (u32)-1;
 
/* Retrieve source port index of the message */
if (pidx != NULL) {
@@ -1772,18 +1771,15 @@ static int idt_ntb_msg_read(struct ntb_dev *ntb, int 
midx, int *pidx, u32 *msg)
}
 
/* Retrieve data of the corresponding message register */
-   if (msg != NULL)
-   *msg = idt_nt_read(ndev, ntdata_tbl.msgs[midx].in);
-
-   return 0;
+   return idt_nt_read(ndev, ntdata_tbl.msgs[midx].in);
 }
 
 /*
- * idt_ntb_msg_write() - write data to the specified message register
- *  (NTB API callback)
+ * idt_ntb_peer_msg_write() - write data to the specified message register
+ *   (NTB API callback)
  * @ntb:   NTB device context.
- * @midx:  Message register index
  * @pidx:  Port index of peer device a message being sent to
+ * @midx:  Message register index
  * @msg:   Data to send
  *
  * Just try to send data to a peer. Message status register should be
@@ -1791,7 +1787,8 @@ static int idt_ntb_msg_read(struct ntb_dev *ntb, int 
midx, int *pidx, u32 *msg)
  *
  * Return: zero on success, negative error if invalid argument passed.
  */
-static int idt_ntb_msg_write(struct ntb_dev *ntb, int midx, int pidx, u32 msg)
+static int idt_ntb_peer_msg_write(struct ntb_dev *ntb, int pidx, int midx,
+ u32 msg)
 {
struct idt_ntb_dev *ndev = to_ndev_ntb(ntb);
unsigned long irqflags;
@@ -2058,7 +2055,7 @@ static const struct ntb_dev_ops idt_ntb_ops = {
.msg_set_mask   = idt_ntb_msg_set_mask,
.msg_clear_mask = idt_ntb_msg_clear_mask,
.msg_read   = idt_ntb_msg_read,
-   .msg_write  = idt_ntb_msg_write
+   .peer_msg_write = idt_ntb_peer_msg_write
 };
 
 /*
@@ -2269,7 +2266,7 @@ static ssize_t idt_dbgfs_info_read(struct file *filp, 
char __user *ubuf,
 "Message data:\n");
for (idx = 0; idx < IDT_MSG_CNT; idx++) {
int src;
-   (void)idt_ntb_msg_read(&ndev->ntb, idx, &src, &data);
+   data = idt_ntb_msg_read(&ndev->ntb, &src, idx);
off += scnprintf(strbuf + off, size - off,
"\t%hhu. 0x%08x from peer %hhu (Port %hhu)\n",
idx, data, src, ndev->peers[src].port);
diff --git a/include/linux/ntb.h b/include/linux/ntb.h
index c308964777eb..c1646f2c6344 100644
--- a/include/linux/ntb.h
+++ b/include/linux/ntb.h
@@ -250,7 +250,7 @@ static inline int ntb_ctx_ops_is_valid(const struct 
ntb_ctx_ops *ops)
  * @msg_set_mask:  See ntb_msg_set_mask().
  * @msg_clear_mask:See ntb_msg_clear_mask().
  * @msg_read:  See ntb_msg_read().
- * @msg_write: See ntb_msg_write().
+ * @peer_msg_write:See ntb_peer_msg_write().
  */
 struct ntb_dev_ops {
int (*port_number)(struct ntb_dev *ntb);
@@ -321,8 +321,8 @@ struct ntb_dev_ops {
int (*msg_clear_sts)(struct ntb_dev *ntb, u64 sts_bits);
int (*msg_set_mask)(struct ntb_dev *ntb, u64 mask_bits);
int (*msg_clear_mask)(struct ntb_dev *ntb, u64 mask_bits);
-   int (*msg_read)(struct ntb_dev *ntb, int midx, int *pidx, u32 *msg);
-   int (*msg_write)(struct ntb_dev *ntb, int midx, int pidx, u32 msg);
+   u32 (*msg_read)(struct ntb_dev *ntb, int *pidx, int midx);
+   int (*peer_msg_wr

Re: [PATCH AUTOSEL for 3.18 16/16] EDAC, i5000, i5400: Fix use of MTR_DRAM_WIDTH macro

[alexander . levin]

On Wed, Nov 29, 2017 at 08:34:30PM -0500, Jérémy Lefaure wrote:
>On Wed, 29 Nov 2017 17:22:22 +
>alexander.le...@verizon.com wrote:
>
>> From: Jérémy Lefaure 
>>
>> [ Upstream commit e61555c29c28a4a3b6ba6207f4a0883ee236004d ]
>>
>> The MTR_DRAM_WIDTH macro returns the data width. It is sometimes used
>> as if it returned a boolean true if the width if 8. Fix the tests where
>> MTR_DRAM_WIDTH is misused.
>>
>> Signed-off-by: Jérémy Lefaure 
>> Cc: linux-edac 
>> Link: 
>> https://urldefense.proofpoint.com/v2/url?u=http-3A__lkml.kernel.org_r_20170309011809.8340-2D1-2Djeremy.lefaure-40lse.epita.fr&d=DwIFaQ&c=udBTRvFvXC5Dhqg7UHpJlPps3mZ3LRxpb6__0PomBTQ&r=bUtaaC9mlBij4OjEG_D-KPul_335azYzfC4Rjgomobo&m=4TjC-mjd8VhY5QwakbfRNaavseTL9EjNAamdg2F3LVk&s=A9D_GzYRdnb8lLzbBJnHwOFg4fTkGFZ_91MSxIRVMlg&e=
>> Signed-off-by: Borislav Petkov 
>> Signed-off-by: Sasha Levin 
>>
>Hi Sasha,
>I noticed that you want to backport this commit to 3.18, 4.4 and 4.9.
>Is there any reason for not backporting it to 4.1 ?

No reason, I just scripted it this way to address Greg's trees. It'll
go in 4.1.

>Also, I don't know if you saw my other patch on those files, upstream
>commit a8c8261425649d ("EDAC, i5000, i5400: Fix definition of NRECMEMB
>register"). Maybe it should be backported to stable too ?

Sure, I'll include it in 4.9/4.4/3.18 as well, thanks!

-- 

Thanks,
Sasha

[PATCH v2] NTB: ntb_pp: Add full multi-port NTB API support

[Serge Semin]

NTB API has been updated to support multi-port devices like IDT
89HPESx series or Microsemi Switchtec. Message registers
functionality has also been added to new API. In order to keep
the new hardware and corresponding capabilities well tested, NTB
pingpong driver is accordingly altered.

Signed-off-by: Serge Semin 
---

Changelog v1:
- Add Multi-port API support
- Ping-pong now works like cyclic ping around all the peers

Changelog v2:
- Remove driver Author/Description/Version macros

 drivers/ntb/test/ntb_pingpong.c | 450 +---
 1 file changed, 286 insertions(+), 164 deletions(-)

diff --git a/drivers/ntb/test/ntb_pingpong.c b/drivers/ntb/test/ntb_pingpong.c
index 3f5a92bae6f8..3e4a35a856cc 100644
--- a/drivers/ntb/test/ntb_pingpong.c
+++ b/drivers/ntb/test/ntb_pingpong.c
@@ -1,10 +1,11 @@
 /*
- * This file is provided under a dual BSD/GPLv2 license.  When using or
+ *   This file is provided under a dual BSD/GPLv2 license.  When using or
  *   redistributing this file, you may do so under either license.
  *
  *   GPL LICENSE SUMMARY
  *
  *   Copyright (C) 2015 EMC Corporation. All Rights Reserved.
+ *   Copyright (C) 2017 T-Platforms. All Rights Reserved.
  *
  *   This program is free software; you can redistribute it and/or modify
  *   it under the terms of version 2 of the GNU General Public License as
@@ -18,6 +19,7 @@
  *   BSD LICENSE
  *
  *   Copyright (C) 2015 EMC Corporation. All Rights Reserved.
+ *   Copyright (C) 2017 T-Platforms. All Rights Reserved.
  *
  *   Redistribution and use in source and binary forms, with or without
  *   modification, are permitted provided that the following conditions
@@ -49,34 +51,46 @@
  *
  * Contact Information:
  * Allen Hubbe 
+ * Serge Semin , 
  */
 
-/* Note: load this module with option 'dyndbg=+p' */
+/*
+ * How to use this tool, by example.
+ *
+ * Assuming $DBG_DIR is something like:
+ * '/sys/kernel/debug/ntb_perf/:00:03.0'
+ * Suppose aside from local device there is at least one remote device
+ * connected to NTB with index 0.
+ *-
+ * Eg: install driver with specified delay between doorbell event and response
+ *
+ * root@self# insmod ntb_pingpong.ko delay_ms=1000
+ *-
+ * Eg: get number of ping-pong cycles performed
+ *
+ * root@self# cat $DBG_DIR/count
+ */
 
 #include 
 #include 
 #include 
+#include 
+#include 
 
-#include 
 #include 
 #include 
-#include 
+#include 
 #include 
 
 #include 
 
-#define DRIVER_NAME"ntb_pingpong"
-#define DRIVER_DESCRIPTION "PCIe NTB Simple Pingpong Client"
-
-#define DRIVER_LICENSE "Dual BSD/GPL"
-#define DRIVER_VERSION "1.0"
-#define DRIVER_RELDATE "24 March 2015"
-#define DRIVER_AUTHOR  "Allen Hubbe "
+#define DRIVER_NAME"ntb_pingpong"
+#define DRIVER_VERSION "2.0"
 
-MODULE_LICENSE(DRIVER_LICENSE);
+MODULE_LICENSE("Dual BSD/GPL");
 MODULE_VERSION(DRIVER_VERSION);
-MODULE_AUTHOR(DRIVER_AUTHOR);
-MODULE_DESCRIPTION(DRIVER_DESCRIPTION);
+MODULE_AUTHOR("Allen Hubbe ");
+MODULE_DESCRIPTION("PCIe NTB Simple Pingpong Client");
 
 static unsigned int unsafe;
 module_param(unsafe, uint, 0644);
@@ -86,237 +100,345 @@ static unsigned int delay_ms = 1000;
 module_param(delay_ms, uint, 0644);
 MODULE_PARM_DESC(delay_ms, "Milliseconds to delay the response to peer");
 
-static unsigned long db_init = 0x7;
-module_param(db_init, ulong, 0644);
-MODULE_PARM_DESC(db_init, "Initial doorbell bits to ring on the peer");
-
-/* Only two-ports NTB devices are supported */
-#define PIDX   NTB_DEF_PEER_IDX
-
 struct pp_ctx {
-   struct ntb_dev  *ntb;
-   u64 db_bits;
-   /* synchronize access to db_bits by ping and pong */
-   spinlock_t  db_lock;
-   struct timer_list   db_timer;
-   unsigned long   db_delay;
-   struct dentry   *debugfs_node_dir;
-   struct dentry   *debugfs_count;
-   atomic_tcount;
+   struct ntb_dev *ntb;
+   struct hrtimer timer;
+   u64 in_db;
+   u64 out_db;
+   int out_pidx;
+   u64 nmask;
+   u64 pmask;
+   atomic_t count;
+   spinlock_t lock;
+   struct dentry *dbgfs_dir;
 };
+#define to_pp_timer(__timer) \
+   container_of(__timer, struct pp_ctx, timer)
 
-static struct dentry *pp_debugfs_dir;
+static struct dentry *pp_dbgfs_topdir;
 
-static void pp_ping(struct timer_list *t)
+static int pp_find_next_peer(struct pp_ctx *pp)
 {
-   struct pp_ctx *pp = from_timer(pp, t, db_timer);
-   unsigned long irqflags;
-   u64 db_bits, db_mask;
-   u32 spad_rd, spad_wr;
+   u64 link, out_db;
+   int pidx;
+
+   link = ntb_link_is_up(pp->ntb, NULL, NU

Re: [PATCH] mtd: nand: denali_pci: add missing MODULE_DESCRIPTION/AUTHOR/LICENSE

[Boris Brezillon]

On Mon, 20 Nov 2017 12:57:13 -0800
Jesse Chan  wrote:

> This change resolves a new compile-time warning
> when built as a loadable module:
> 
> WARNING: modpost: missing MODULE_LICENSE() in drivers/mtd/nand/denali_pci.o
> see include/linux/module.h for more information
> 
> This adds the license as "GPL v2", which matches the header of the file.
> 
> MODULE_DESCRIPTION and MODULE_AUTHOR are also added.
> 

Applied.

Thanks,

Boris

> Signed-off-by: Jesse Chan 
> ---
>  drivers/mtd/nand/denali_pci.c | 4 
>  1 file changed, 4 insertions(+)
> 
> diff --git a/drivers/mtd/nand/denali_pci.c b/drivers/mtd/nand/denali_pci.c
> index 81370c79aa48..7ad0db65a6fa 100644
> --- a/drivers/mtd/nand/denali_pci.c
> +++ b/drivers/mtd/nand/denali_pci.c
> @@ -124,3 +124,7 @@ static struct pci_driver denali_pci_driver = {
>  };
>  
>  module_pci_driver(denali_pci_driver);
> +
> +MODULE_DESCRIPTION("PCI driver for Denali NAND controller");
> +MODULE_AUTHOR("Intel Corporation and its suppliers");
> +MODULE_LICENSE("GPL v2");

Re: [PATCH AUTOSEL for 4.9 04/52] x86/selftests: Add clobbers for int80 on x86_64

[alexander . levin]

On Wed, Nov 29, 2017 at 05:42:25PM +, Dmitry Safonov wrote:
>Hi Sasha,
>
>I would object including this to stable tree:
>1. It's selftest fixup
>2. I have never saw selftests failing because of it (but it's possible)
>I saw this in CRIU (Checkpoint Restore In Userspace) project
>triggering, so I've fixed the selftests, mostly for documentation
>reasons - as people in userspace can reuse this code and think
>it's good and will just work after copy-paste (which is not the case).
>
>So, this patch doesn't look urgent to include it in -stable kernel.

Hey Dmitry,

We try to backport selftest patches as stable material to allow a
"complete" selftest to run on stable kernels.

-- 

Thanks,
Sasha

[PATCH v2] NTB: ntb_tool: Add full multi-port NTB API support

[Serge Semin]

NTB API has been updated to support multi-port devices like IDT
89HPESx series or Microsemi Switchtec. Message registers
functionality has also been added to new API. In order to keep
the new hardware and corresponding capabilities well tested, NTB
tool driver is accordingly altered.

Signed-off-by: Serge Semin 
---

Changelog v1:
- Alter interface in compliance with multi-port API
- Move Message/MW/Port/Link settings to a specific directory

Changelog v2:
- Remove driver Author/Description/License macros
- Return error if ntb_mw_get_align called while link is down
- Add db_valid_mask DebugFS file
- Add msg_inbits/msg_outbits DebugFS files

 drivers/ntb/test/ntb_tool.c | 1805 +--
 1 file changed, 1228 insertions(+), 577 deletions(-)

diff --git a/drivers/ntb/test/ntb_tool.c b/drivers/ntb/test/ntb_tool.c
index 91526a986caa..e3fbc5944679 100644
--- a/drivers/ntb/test/ntb_tool.c
+++ b/drivers/ntb/test/ntb_tool.c
@@ -5,6 +5,7 @@
  *   GPL LICENSE SUMMARY
  *
  *   Copyright (C) 2015 EMC Corporation. All Rights Reserved.
+ *   Copyright (C) 2017 T-Platforms All Rights Reserved.
  *
  *   This program is free software; you can redistribute it and/or modify
  *   it under the terms of version 2 of the GNU General Public License as
@@ -18,6 +19,7 @@
  *   BSD LICENSE
  *
  *   Copyright (C) 2015 EMC Corporation. All Rights Reserved.
+ *   Copyright (C) 2017 T-Platforms All Rights Reserved.
  *
  *   Redistribution and use in source and binary forms, with or without
  *   modification, are permitted provided that the following conditions
@@ -49,6 +51,7 @@
  *
  * Contact Information:
  * Allen Hubbe 
+ * Serge Semin , 
  */
 
 /*
@@ -56,42 +59,125 @@
  *
  * Assuming $DBG_DIR is something like:
  * '/sys/kernel/debug/ntb_tool/:00:03.0'
+ * Suppose aside from local device there is at least one remote device
+ * connected to NTB with index 0.
+ *-
+ * Eg: check local/peer device information.
  *
- * Eg: check if clearing the doorbell mask generates an interrupt.
+ * # Get local device port number
+ * root@self# cat $DBG_DIR/port
  *
- * # Check the link status
- * root@self# cat $DBG_DIR/link
+ * # Check local device functionality
+ * root@self# ls $DBG_DIR
+ * dbmsg1  msg_sts peer4/port
+ * db_event  msg2  peer0/  peer5/spad0
+ * db_mask   msg3  peer1/  peer_db   spad1
+ * link  msg_event peer2/  peer_db_mask  spad2
+ * msg0  msg_mask  peer3/  peer_spad spad3
+ * # As one can see it supports:
+ * # 1) four inbound message registers
+ * # 2) four inbound scratchpads
+ * # 3) up to six peer devices
  *
- * # Block until the link is up
- * root@self# echo Y > $DBG_DIR/link_event
+ * # Check peer device port number
+ * root@self# cat $DBG_DIR/peer0/port
  *
- * # Set the doorbell mask
- * root@self# echo 's 1' > $DBG_DIR/mask
+ * # Check peer device(s) functionality to be used
+ * root@self# ls $DBG_DIR/peer0
+ * link mw_trans0   mw_trans6port
+ * link_event   mw_trans1   mw_trans7spad0
+ * msg0 mw_trans2   peer_mw_trans0   spad1
+ * msg1 mw_trans3   peer_mw_trans1   spad2
+ * msg2 mw_trans4   peer_mw_trans2   spad3
+ * msg3 mw_trans5   peer_mw_trans3
+ * # As one can see we got:
+ * # 1) four outbound message registers
+ * # 2) four outbound scratchpads
+ * # 3) eight inbound memory windows
+ * # 4) four outbound memory windows
+ *-
+ * Eg: NTB link tests
  *
- * # Ring the doorbell from the peer
+ * # Set local link up/down
+ * root@self# echo Y > $DBG_DIR/link
+ * root@self# echo N > $DBG_DIR/link
+ *
+ * # Check if link with peer device is up/down:
+ * root@self# cat $DBG_DIR/peer0/link
+ *
+ * # Block until the link is up/down
+ * root@self# echo Y > $DBG_DIR/peer0/link_event
+ * root@self# echo N > $DBG_DIR/peer0/link_event
+ *-
+ * Eg: Doorbell registers tests (some functionality might be absent)
+ *
+ * # Set/clear/get local doorbell
+ * root@self# echo 's 1' > $DBG_DIR/db
+ * root@self# echo 'c 1' > $DBG_DIR/db
+ * root@self# cat  $DBG_DIR/db
+ *
+ * # Set/clear/get local doorbell mask
+ * root@self# echo 's 1' > $DBG_DIR/db_mask
+ * root@self# echo 'c 1' > $DBG_DIR/db_mask
+ * root@self# cat $DBG_DIR/db_mask
+ *
+ * # Ring/clear/get peer doorbell
  * root@peer# echo 's 1' > $DBG_DIR/peer_db
+ * root@peer# echo 'c 1' > $DBG_DIR/peer_db
+ * root@peer# cat $DBG_DIR/peer_db
+ *
+ * # Set/clear/get peer doorbell mask
+ * root@self# echo 's 1' > $DBG_DIR/peer_db_mask
+ * root@self# echo 'c 1' > $DBG_DIR/peer_db_mask
+ * root@self# cat $DBG_DIR/peer_db_mask
+ *
+ * # Block until local doorbell is set with specified value
+ * root@self# ec

Re: [PATCH v4 2/8] MIPS: Octeon: Enable LMTDMA/LMTST operations.

[James Hogan]

On Tue, Nov 28, 2017 at 04:55:34PM -0800, David Daney wrote:
> From: Carlos Munoz 
> 
> LMTDMA/LMTST operations move data between cores and I/O devices:
> 
> * LMTST operations can send an address and a variable length
>   (up to 128 bytes) of data to an I/O device.
> * LMTDMA operations can send an address and a variable length
>   (up to 128) of data to the I/O device and then return a
>   variable length (up to 128 bytes) response from the IOI device.

Should that be "I/O"?

> 
> Signed-off-by: Carlos Munoz 
> Signed-off-by: Steven J. Hill 
> Signed-off-by: David Daney 
> ---
>  arch/mips/cavium-octeon/setup.c   |  6 ++
>  arch/mips/include/asm/octeon/octeon.h | 12 ++--
>  2 files changed, 16 insertions(+), 2 deletions(-)
> 
> diff --git a/arch/mips/cavium-octeon/setup.c b/arch/mips/cavium-octeon/setup.c
> index a8034d0dcade..99e6a68bc652 100644
> --- a/arch/mips/cavium-octeon/setup.c
> +++ b/arch/mips/cavium-octeon/setup.c
> @@ -609,6 +609,12 @@ void octeon_user_io_init(void)
>  #else
>   cvmmemctl.s.cvmsegenak = 0;
>  #endif
> + if (OCTEON_IS_OCTEON3()) {
> + /* Enable LMTDMA */
> + cvmmemctl.s.lmtena = 1;
> + /* Scratch line to use for LMT operation */
> + cvmmemctl.s.lmtline = 2;

Out of curiosity, is there significance to the value 2 and associated
virtual address 0x8100, or is it pretty arbitrary?

> + }
>   /* R/W If set, CVMSEG is available for loads/stores in
>* supervisor mode. */
>   cvmmemctl.s.cvmsegenas = 0;
> diff --git a/arch/mips/include/asm/octeon/octeon.h 
> b/arch/mips/include/asm/octeon/octeon.h
> index c99c4b6a79f4..92a17d67c1fa 100644
> --- a/arch/mips/include/asm/octeon/octeon.h
> +++ b/arch/mips/include/asm/octeon/octeon.h
> @@ -179,7 +179,15 @@ union octeon_cvmemctl {
>   /* RO 1 = BIST fail, 0 = BIST pass */
>   __BITFIELD_FIELD(uint64_t wbfbist:1,
>   /* Reserved */
> - __BITFIELD_FIELD(uint64_t reserved:17,
> + __BITFIELD_FIELD(uint64_t reserved_52_57:6,
> + /* When set, LMTDMA/LMTST operations are permitted */
> + __BITFIELD_FIELD(uint64_t lmtena:1,
> + /* Selects the CVMSEG LM cacheline used by LMTDMA
> +  * LMTST and wide atomic store operations.
> +  */
> + __BITFIELD_FIELD(uint64_t lmtline:6,
> + /* Reserved */
> + __BITFIELD_FIELD(uint64_t reserved_41_44:4,
>   /* OCTEON II - TLB replacement policy: 0 = bitmask LRU; 1 = NLU.
>* This field selects between the TLB replacement policies:
>* bitmask LRU or NLU. Bitmask LRU maintains a mask of
> @@ -275,7 +283,7 @@ union octeon_cvmemctl {
>   /* R/W Size of local memory in cache blocks, 54 (6912
>* bytes) is max legal value. */
>   __BITFIELD_FIELD(uint64_t lmemsz:6,
> - ;)
> + ;
>   } s;
>  };

Regardless, the patch looks good to me.

Reviewed-by: James Hogan 

Cheers
James


signature.asc
Description: Digital signature

Re: [PATCH RFC 2/2] arm64: allwinner: a64: Add Brava Keller initial support

[Philippe Ombredanne]

Jagan,

On Thu, Nov 30, 2017 at 7:42 PM, Jagan Teki  wrote:
[]
> diff --git a/arch/arm64/boot/dts/allwinner/sun50i-a64-brava-keller.dts 
> b/arch/arm64/boot/dts/allwinner/sun50i-a64-brava-keller.dts
> new file mode 100644
> index 000..f5303a3
> --- /dev/null
> +++ b/arch/arm64/boot/dts/allwinner/sun50i-a64-brava-keller.dts
> @@ -0,0 +1,244 @@
> +/*
> + * Copyright (C) 2017 Jagan Teki 
> + *
> + * This file is dual-licensed: you can use it either under the terms
> + * of the GPL or the X11 license, at your option. Note that this dual
> + * licensing only applies to this file, and not this project as a
> + * whole.
> + *
> + *  a) This library 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 library 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.
> + *
> + * Or, alternatively,
> + *
> + *  b) Permission is hereby granted, free of charge, to any person
> + * obtaining a copy of this software and associated documentation
> + * files (the "Software"), to deal in the Software without
> + * restriction, including without limitation the rights to use,
> + * copy, modify, merge, publish, distribute, sublicense, and/or
> + * sell copies of the Software, and to permit persons to whom the
> + * Software is furnished to do so, subject to the following
> + * conditions:
> + *
> + * The above copyright notice and this permission notice shall be
> + * included in all copies or substantial portions of the Software.
> + *
> + * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
> + * EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES
> + * OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
> + * NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT
> + * HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY,
> + * WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
> + * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR
> + * OTHER DEALINGS IN THE SOFTWARE.
> + */

Rather than this long boilerplate, you might want to use the SPDX ids,
as started by Greg and documented by Thomas.
Noe that Linus wants the // comment style for the license line, and
since there is only two line left here I suggest using it for both
lines.
You can check also the recent doc patch posted by Thomas (tglx) and
comments from Linus and Greg.

So I guess you could use this:

> +// Copyright (C) 2017 Jagan Teki 
> +// SPDX-License-Indentifier: (GPL-2.0+ OR MIT)

NB: what you call X11 is has the MIT license id in the SPDX license list.

So you could replace 32 lines by only two lines :) it'[s neat right?

And this would also help as we have tagged already ~15K files, so it
would help to use this for new files so the amount of cleanup work
still left does not increase. Thank you for your kind consideration!

-- 
Cordially
Philippe Ombredanne

Re: [PATCH v2 00/10] trace-cmd: Refactoring trace_record()

[Steven Rostedt]

On Thu, 30 Nov 2017 15:19:47 +0200
"Vladislav Valtchev (VMware)"  wrote:

> The following series of patches is a refactoring of trace_record() trying to
> reduce as much as possible its complexity but, at the same time, without 
> making
> risky changes. All the patches are relatively small and potentially no-brainer
> steps towards the final shape of the code.
> 
> The rationale for this effort is to make the code much easier to maintain.
> 
> Vladislav Valtchev (VMware) (10):
>   trace-cmd: Extract parse_record_options() from trace_record()
>   trace-cmd: Replacing cmd flags w/ a trace_cmd enum
>   trace-cmd: Extracting record_trace()
>   trace-cmd: Rename trace_profile() to do_trace_profile()
>   trace-cmd: Making start,extract,stream,profile separate funcs
>   trace-cmd: Extr. profile-specific code from record_trace
>   trace-cmd: Mov init_common_record_context in parse_record_options
>   trace-cmd: Introducing get_trace_cmd_type()
>   trace-cmd: Extract finalize_record_trace()
>   trace-cmd: Fork record_trace() for the extract case

Hi Vlad,

I applied and pushed all the patches in this series.

Thanks!

-- Steve

> 
>  trace-cmd.c |   8 +-
>  trace-local.h   |  10 +-
>  trace-profile.c |   2 +-
>  trace-read.c|   2 +-
>  trace-record.c  | 640 
> +---
>  5 files changed, 390 insertions(+), 272 deletions(-)
> 

[PATCH v2] NTB: ntb_perf: Add full multi-port NTB API support

[Serge Semin]

NTB API has been updated to support multi-port devices like IDT
89HPESx series or Microsemi Switchtec. Message registers
functionality has also been added to new API. In order to keep
the new hardware and corresponding capabilities well tested, NTB
performance driver is accordingly altered.

Signed-off-by: Serge Semin 
---

Changelog v1:
- Alter interface in compliance with multi-port API
- Create Scratchpads and Message compliant NTB link init process
- Simplify memcpy and DMA-based tests process
- Limit DebugFS access methods to prevent the driver failure

Changelog v2:
- Remove driver Author/Description/License macros
- Replace magic numbers with macros
- Fix global index calc error for devices with highest port index
- Fix invalid scratchpad selection in send_msg algorithm
- Fix bytes order translation in message recv method
- Use local global index to select an inbound MW
- Add commands send/recv/exec debug prints
- Call ntb_mw_get_align when link is supposed to be up

 drivers/ntb/test/ntb_perf.c | 1826 +--
 1 file changed, 1222 insertions(+), 604 deletions(-)

diff --git a/drivers/ntb/test/ntb_perf.c b/drivers/ntb/test/ntb_perf.c
index 427112cf101a..5ca5cc6f9687 100644
--- a/drivers/ntb/test/ntb_perf.c
+++ b/drivers/ntb/test/ntb_perf.c
@@ -5,6 +5,7 @@
  *   GPL LICENSE SUMMARY
  *
  *   Copyright(c) 2015 Intel Corporation. All rights reserved.
+ *   Copyright(c) 2017 T-Platforms. All Rights Reserved.
  *
  *   This program is free software; you can redistribute it and/or modify
  *   it under the terms of version 2 of the GNU General Public License as
@@ -13,6 +14,7 @@
  *   BSD LICENSE
  *
  *   Copyright(c) 2015 Intel Corporation. All rights reserved.
+ *   Copyright(c) 2017 T-Platforms. All Rights Reserved.
  *
  *   Redistribution and use in source and binary forms, with or without
  *   modification, are permitted provided that the following conditions
@@ -40,860 +42,1476 @@
  *   (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE
  *   OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
  *
- *   PCIe NTB Perf Linux driver
+ * PCIe NTB Perf Linux driver
+ *
+ * Contact Information:
+ * Dave Jiang 
+ * Serge Semin , 
+ */
+
+/*
+ * How to use this tool, by example.
+ *
+ * Assuming $DBG_DIR is something like:
+ * '/sys/kernel/debug/ntb_perf/:00:03.0'
+ * Suppose aside from local device there is at least one remote device
+ * connected to NTB with index 0.
+ *-
+ * Eg: install driver with specified chunk/total orders and dma-enabled flag
+ *
+ * root@self# insmod ntb_perf.ko chunk_order=19 total_order=28 use_dma
+ *-
+ * Eg: check NTB ports (index) and MW mapping information
+ *
+ * root@self# cat $DBG_DIR/info
+ *-
+ * Eg: start performance test with peer (index 0) and get the test metrics
+ *
+ * root@self# echo 0 > $DBG_DIR/run
+ * root@self# cat $DBG_DIR/run
  */
 
 #include 
 #include 
 #include 
-#include 
-#include 
-#include 
+#include 
+#include 
 #include 
+#include 
 #include 
+#include 
 #include 
-#include 
-#include 
-#include 
 #include 
 #include 
+#include 
+#include 
+#include 
 #include 
-#include 
 
 #define DRIVER_NAME"ntb_perf"
-#define DRIVER_DESCRIPTION "PCIe NTB Performance Measurement Tool"
-
-#define DRIVER_LICENSE "Dual BSD/GPL"
-#define DRIVER_VERSION "1.0"
-#define DRIVER_AUTHOR  "Dave Jiang "
-
-#define PERF_LINK_DOWN_TIMEOUT 10
-#define PERF_VERSION   0x0001
-#define MAX_THREADS32
-#define MAX_TEST_SIZE  SZ_1M
-#define MAX_SRCS   32
-#define DMA_OUT_RESOURCE_TOmsecs_to_jiffies(50)
-#define DMA_RETRIES20
-#define SZ_4G  (1ULL << 32)
-#define MAX_SEG_ORDER  20 /* no larger than 1M for kmalloc buffer */
-#define PIDX   NTB_DEF_PEER_IDX
-
-MODULE_LICENSE(DRIVER_LICENSE);
+#define DRIVER_VERSION "2.0"
+
+MODULE_LICENSE("Dual BSD/GPL");
 MODULE_VERSION(DRIVER_VERSION);
-MODULE_AUTHOR(DRIVER_AUTHOR);
-MODULE_DESCRIPTION(DRIVER_DESCRIPTION);
+MODULE_AUTHOR("Dave Jiang ");
+MODULE_DESCRIPTION("PCIe NTB Performance Measurement Tool");
 
-static struct dentry *perf_debugfs_dir;
+#define MAX_THREADS_CNT32
+#define DEF_THREADS_CNT1
+#define MAX_CHUNK_SIZE SZ_1M
+#define MAX_CHUNK_ORDER20 /* no larger than 1M */
+
+#define DMA_TRIES  100
+#define DMA_MDELAY 10
+
+#define MSG_TRIES  500
+#define MSG_UDELAY_LOW 1000
+#define MSG_UDELAY_HIGH2000
 
 static unsigned long max_mw_size;
 module_param(max_mw_size, ulong, 0644);
-MODULE_PARM_DESC(max_mw_size, "Limit size of large memory windows");
+MODULE_PARM_DESC(max_mw_size

Re: waitqueue lockdep annotation

[Jason Baron]

On 11/30/2017 03:50 PM, Andrew Morton wrote:
> On Thu, 30 Nov 2017 06:20:35 -0800 Christoph Hellwig  wrote:
> 
>> Hi all,
>>
>> this series adds a strategic lockdep_assert_held to __wake_up_common
>> to ensure callers really do hold the wait_queue_head lock when calling
>> the unlocked wake_up variants.  It turns out epoll did not do this
>> for a fairly common path (hit all the time by systemd during bootup),
>> so the second patch fixed this instance as well.
> 
> What are the runtime effects of the epoll bug?
> 

I don't think there is a bug here. The 'wake_up_locked()' calls in epoll
are being protected by the ep->lock, not the wait_queue_head lock. So
arguably the 'annotation' is wrong, but I don't think there is a bug
beyond that.

Thanks,

-Jason

Re: [PATCH] mtd: nand: denali: rename misleading dma_buf to tmp_buf

[Boris Brezillon]

On Thu, 23 Nov 2017 22:32:28 +0900
Masahiro Yamada  wrote:

> The "dma_buf" is not used for a DMA bounce buffer, but for arranging
> the transferred data for the syndrome page layout.  In fact, it is
> used in the PIO mode as well, so "dma_buf" is a misleading name.
> Rename it to "tmp_buf".

Applied.

Thanks,

Boris

> 
> Signed-off-by: Masahiro Yamada 
> ---
> 
>  drivers/mtd/nand/denali.c | 34 +-
>  1 file changed, 17 insertions(+), 17 deletions(-)
> 
> diff --git a/drivers/mtd/nand/denali.c b/drivers/mtd/nand/denali.c
> index 5124f8a..34008a0 100644
> --- a/drivers/mtd/nand/denali.c
> +++ b/drivers/mtd/nand/denali.c
> @@ -710,12 +710,12 @@ static int denali_read_page_raw(struct mtd_info *mtd, 
> struct nand_chip *chip,
>   int ecc_steps = chip->ecc.steps;
>   int ecc_size = chip->ecc.size;
>   int ecc_bytes = chip->ecc.bytes;
> - void *dma_buf = denali->buf;
> + void *tmp_buf = denali->buf;
>   int oob_skip = denali->oob_skip_bytes;
>   size_t size = writesize + oobsize;
>   int ret, i, pos, len;
>  
> - ret = denali_data_xfer(denali, dma_buf, size, page, 1, 0);
> + ret = denali_data_xfer(denali, tmp_buf, size, page, 1, 0);
>   if (ret)
>   return ret;
>  
> @@ -730,11 +730,11 @@ static int denali_read_page_raw(struct mtd_info *mtd, 
> struct nand_chip *chip,
>   else if (pos + len > writesize)
>   len = writesize - pos;
>  
> - memcpy(buf, dma_buf + pos, len);
> + memcpy(buf, tmp_buf + pos, len);
>   buf += len;
>   if (len < ecc_size) {
>   len = ecc_size - len;
> - memcpy(buf, dma_buf + writesize + oob_skip,
> + memcpy(buf, tmp_buf + writesize + oob_skip,
>  len);
>   buf += len;
>   }
> @@ -745,7 +745,7 @@ static int denali_read_page_raw(struct mtd_info *mtd, 
> struct nand_chip *chip,
>   uint8_t *oob = chip->oob_poi;
>  
>   /* BBM at the beginning of the OOB area */
> - memcpy(oob, dma_buf + writesize, oob_skip);
> + memcpy(oob, tmp_buf + writesize, oob_skip);
>   oob += oob_skip;
>  
>   /* OOB ECC */
> @@ -758,11 +758,11 @@ static int denali_read_page_raw(struct mtd_info *mtd, 
> struct nand_chip *chip,
>   else if (pos + len > writesize)
>   len = writesize - pos;
>  
> - memcpy(oob, dma_buf + pos, len);
> + memcpy(oob, tmp_buf + pos, len);
>   oob += len;
>   if (len < ecc_bytes) {
>   len = ecc_bytes - len;
> - memcpy(oob, dma_buf + writesize + oob_skip,
> + memcpy(oob, tmp_buf + writesize + oob_skip,
>  len);
>   oob += len;
>   }
> @@ -770,7 +770,7 @@ static int denali_read_page_raw(struct mtd_info *mtd, 
> struct nand_chip *chip,
>  
>   /* OOB free */
>   len = oobsize - (oob - chip->oob_poi);
> - memcpy(oob, dma_buf + size - len, len);
> + memcpy(oob, tmp_buf + size - len, len);
>   }
>  
>   return 0;
> @@ -841,7 +841,7 @@ static int denali_write_page_raw(struct mtd_info *mtd, 
> struct nand_chip *chip,
>   int ecc_steps = chip->ecc.steps;
>   int ecc_size = chip->ecc.size;
>   int ecc_bytes = chip->ecc.bytes;
> - void *dma_buf = denali->buf;
> + void *tmp_buf = denali->buf;
>   int oob_skip = denali->oob_skip_bytes;
>   size_t size = writesize + oobsize;
>   int i, pos, len;
> @@ -851,7 +851,7 @@ static int denali_write_page_raw(struct mtd_info *mtd, 
> struct nand_chip *chip,
>* This simplifies the logic.
>*/
>   if (!buf || !oob_required)
> - memset(dma_buf, 0xff, size);
> + memset(tmp_buf, 0xff, size);
>  
>   /* Arrange the buffer for syndrome payload/ecc layout */
>   if (buf) {
> @@ -864,11 +864,11 @@ static int denali_write_page_raw(struct mtd_info *mtd, 
> struct nand_chip *chip,
>   else if (pos + len > writesize)
>   len = writesize - pos;
>  
> - memcpy(dma_buf + pos, buf, len);
> + memcpy(tmp_buf + pos, buf, len);
>   buf += len;
>   if (len < ecc_size) {
>   len = ecc_size - len;
> - memcpy(dma_buf + writesize + oob_skip, buf,
> + memcpy(tmp_buf + writesize + oob_skip, buf,
>  len);
>   buf += len;
>   }
>

[PATCH] NTB: Fix UB/bug in ntb_mw_get_align()

[Serge Semin]

Simple (1 << pidx) operation causes undefined behaviour when
pidx >= 32. It must be casted to u64 to match the actual return
value of ntb_link_is_up() method, so to have all the possible
peer indexes covered and to get rid of undefined behaviour.
Additionally there are special macros in "linux/bitops.h" to perform
the bit-set-shift operations, so it's recommended to have them used
for proper bit setting.

Signed-off-by: Serge Semin 
---
 include/linux/ntb.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/include/linux/ntb.h b/include/linux/ntb.h
index c1646f2c6344..488e586fb76c 100644
--- a/include/linux/ntb.h
+++ b/include/linux/ntb.h
@@ -764,7 +764,7 @@ static inline int ntb_mw_get_align(struct ntb_dev *ntb, int 
pidx, int widx,
   resource_size_t *size_align,
   resource_size_t *size_max)
 {
-   if (!(ntb_link_is_up(ntb, NULL, NULL) & (1 << pidx)))
+   if (!(ntb_link_is_up(ntb, NULL, NULL) & BIT_ULL(pidx)))
return -ENOTCONN;
 
return ntb->ops->mw_get_align(ntb, pidx, widx, addr_align, size_align,
-- 
2.12.0

[PATCH] NTB: Set dma mask and dma coherent mask to NTB devices

[Serge Semin]

The dma_mask and dma_coherent_mask fields of the NTB struct device
weren't initialized in hardware drivers. In fact it should be done
instead of PCIe interface usage, since NTB clients are supposed to
use NTB API and left unaware of real hardware implementation.
In addition to that ntb_device_register() method shouldn't clear
the passed ntb_dev structure, since it dma_mask is initialized
by hardware drivers.

Signed-off-by: Serge Semin 
---
 drivers/ntb/hw/amd/ntb_hw_amd.c | 4 
 drivers/ntb/hw/idt/ntb_hw_idt.c | 8 +++-
 drivers/ntb/hw/intel/ntb_hw_intel.c | 4 
 drivers/ntb/ntb.c   | 1 -
 4 files changed, 15 insertions(+), 2 deletions(-)

diff --git a/drivers/ntb/hw/amd/ntb_hw_amd.c b/drivers/ntb/hw/amd/ntb_hw_amd.c
index f0788aae05c9..3cfa46876239 100644
--- a/drivers/ntb/hw/amd/ntb_hw_amd.c
+++ b/drivers/ntb/hw/amd/ntb_hw_amd.c
@@ -1020,6 +1020,10 @@ static int amd_ntb_init_pci(struct amd_ntb_dev *ndev,
goto err_dma_mask;
dev_warn(&pdev->dev, "Cannot DMA consistent highmem\n");
}
+   rc = dma_coerce_mask_and_coherent(&ndev->ntb.dev,
+ dma_get_mask(&pdev->dev));
+   if (rc)
+   goto err_dma_mask;
 
ndev->self_mmio = pci_iomap(pdev, 0, 0);
if (!ndev->self_mmio) {
diff --git a/drivers/ntb/hw/idt/ntb_hw_idt.c b/drivers/ntb/hw/idt/ntb_hw_idt.c
index 6fb87c0f0d97..d87dbd4bc82c 100644
--- a/drivers/ntb/hw/idt/ntb_hw_idt.c
+++ b/drivers/ntb/hw/idt/ntb_hw_idt.c
@@ -2426,7 +2426,7 @@ static int idt_init_pci(struct idt_ntb_dev *ndev)
struct pci_dev *pdev = ndev->ntb.pdev;
int ret;
 
-   /* Initialize the bit mask of DMA */
+   /* Initialize the bit mask of PCI/NTB DMA */
ret = pci_set_dma_mask(pdev, DMA_BIT_MASK(64));
if (ret != 0) {
ret = pci_set_dma_mask(pdev, DMA_BIT_MASK(32));
@@ -2447,6 +2447,12 @@ static int idt_init_pci(struct idt_ntb_dev *ndev)
dev_warn(&pdev->dev,
"Cannot set consistent DMA highmem bit mask\n");
}
+   ret = dma_coerce_mask_and_coherent(&ndev->ntb.dev,
+  dma_get_mask(&pdev->dev));
+   if (ret != 0) {
+   dev_err(&pdev->dev, "Failed to set NTB device DMA bit mask\n");
+   return ret;
+   }
 
/*
 * Enable the device advanced error reporting. It's not critical to
diff --git a/drivers/ntb/hw/intel/ntb_hw_intel.c 
b/drivers/ntb/hw/intel/ntb_hw_intel.c
index 4de074a86073..ea6c82f8655f 100644
--- a/drivers/ntb/hw/intel/ntb_hw_intel.c
+++ b/drivers/ntb/hw/intel/ntb_hw_intel.c
@@ -2586,6 +2586,10 @@ static int intel_ntb_init_pci(struct intel_ntb_dev 
*ndev, struct pci_dev *pdev)
goto err_dma_mask;
dev_warn(&pdev->dev, "Cannot DMA consistent highmem\n");
}
+   rc = dma_coerce_mask_and_coherent(&ndev->ntb.dev,
+ dma_get_mask(&pdev->dev));
+   if (rc)
+   goto err_dma_mask;
 
ndev->self_mmio = pci_iomap(pdev, 0, 0);
if (!ndev->self_mmio) {
diff --git a/drivers/ntb/ntb.c b/drivers/ntb/ntb.c
index 03b80d89b980..79e50a5f8902 100644
--- a/drivers/ntb/ntb.c
+++ b/drivers/ntb/ntb.c
@@ -112,7 +112,6 @@ int ntb_register_device(struct ntb_dev *ntb)
 
init_completion(&ntb->released);
 
-   memset(&ntb->dev, 0, sizeof(ntb->dev));
ntb->dev.bus = &ntb_bus;
ntb->dev.parent = &ntb->pdev->dev;
ntb->dev.release = ntb_dev_release;
-- 
2.12.0

Re: [PATCH] mtd: nand: remove unnecessary extern from driver headers

[Boris Brezillon]

On Thu, 23 Nov 2017 22:18:43 +0900
Masahiro Yamada  wrote:

> 'extern' is not necessary for function declarations.
> 
> scripts/checkpatch.pl with --strict option reports the following:
> 
>   CHECK: extern prototypes should be avoided in .h files

Applied.

Thanks,

Boris

> 
> Signed-off-by: Masahiro Yamada 
> ---
> 
>  drivers/mtd/nand/denali.h  |  4 +--
>  drivers/mtd/nand/gpmi-nand/gpmi-nand.h | 46 
> +-
>  drivers/mtd/nand/sm_common.h   |  2 +-
>  3 files changed, 26 insertions(+), 26 deletions(-)
> 
> diff --git a/drivers/mtd/nand/denali.h b/drivers/mtd/nand/denali.h
> index 2911066..9ad33d2 100644
> --- a/drivers/mtd/nand/denali.h
> +++ b/drivers/mtd/nand/denali.h
> @@ -329,7 +329,7 @@ struct denali_nand_info {
>  #define DENALI_CAP_DMA_64BIT BIT(1)
>  
>  int denali_calc_ecc_bytes(int step_size, int strength);
> -extern int denali_init(struct denali_nand_info *denali);
> -extern void denali_remove(struct denali_nand_info *denali);
> +int denali_init(struct denali_nand_info *denali);
> +void denali_remove(struct denali_nand_info *denali);
>  
>  #endif /* __DENALI_H__ */
> diff --git a/drivers/mtd/nand/gpmi-nand/gpmi-nand.h 
> b/drivers/mtd/nand/gpmi-nand/gpmi-nand.h
> index a45e4ce..06c1f99 100644
> --- a/drivers/mtd/nand/gpmi-nand/gpmi-nand.h
> +++ b/drivers/mtd/nand/gpmi-nand/gpmi-nand.h
> @@ -268,31 +268,31 @@ struct timing_threshold {
>  };
>  
>  /* Common Services */
> -extern int common_nfc_set_geometry(struct gpmi_nand_data *);
> -extern struct dma_chan *get_dma_chan(struct gpmi_nand_data *);
> -extern void prepare_data_dma(struct gpmi_nand_data *,
> - enum dma_data_direction dr);
> -extern int start_dma_without_bch_irq(struct gpmi_nand_data *,
> - struct dma_async_tx_descriptor *);
> -extern int start_dma_with_bch_irq(struct gpmi_nand_data *,
> - struct dma_async_tx_descriptor *);
> +int common_nfc_set_geometry(struct gpmi_nand_data *);
> +struct dma_chan *get_dma_chan(struct gpmi_nand_data *);
> +void prepare_data_dma(struct gpmi_nand_data *,
> +   enum dma_data_direction dr);
> +int start_dma_without_bch_irq(struct gpmi_nand_data *,
> +   struct dma_async_tx_descriptor *);
> +int start_dma_with_bch_irq(struct gpmi_nand_data *,
> +struct dma_async_tx_descriptor *);
>  
>  /* GPMI-NAND helper function library */
> -extern int gpmi_init(struct gpmi_nand_data *);
> -extern int gpmi_extra_init(struct gpmi_nand_data *);
> -extern void gpmi_clear_bch(struct gpmi_nand_data *);
> -extern void gpmi_dump_info(struct gpmi_nand_data *);
> -extern int bch_set_geometry(struct gpmi_nand_data *);
> -extern int gpmi_is_ready(struct gpmi_nand_data *, unsigned chip);
> -extern int gpmi_send_command(struct gpmi_nand_data *);
> -extern void gpmi_begin(struct gpmi_nand_data *);
> -extern void gpmi_end(struct gpmi_nand_data *);
> -extern int gpmi_read_data(struct gpmi_nand_data *);
> -extern int gpmi_send_data(struct gpmi_nand_data *);
> -extern int gpmi_send_page(struct gpmi_nand_data *,
> - dma_addr_t payload, dma_addr_t auxiliary);
> -extern int gpmi_read_page(struct gpmi_nand_data *,
> - dma_addr_t payload, dma_addr_t auxiliary);
> +int gpmi_init(struct gpmi_nand_data *);
> +int gpmi_extra_init(struct gpmi_nand_data *);
> +void gpmi_clear_bch(struct gpmi_nand_data *);
> +void gpmi_dump_info(struct gpmi_nand_data *);
> +int bch_set_geometry(struct gpmi_nand_data *);
> +int gpmi_is_ready(struct gpmi_nand_data *, unsigned chip);
> +int gpmi_send_command(struct gpmi_nand_data *);
> +void gpmi_begin(struct gpmi_nand_data *);
> +void gpmi_end(struct gpmi_nand_data *);
> +int gpmi_read_data(struct gpmi_nand_data *);
> +int gpmi_send_data(struct gpmi_nand_data *);
> +int gpmi_send_page(struct gpmi_nand_data *,
> +dma_addr_t payload, dma_addr_t auxiliary);
> +int gpmi_read_page(struct gpmi_nand_data *,
> +dma_addr_t payload, dma_addr_t auxiliary);
>  
>  void gpmi_copy_bits(u8 *dst, size_t dst_bit_off,
>   const u8 *src, size_t src_bit_off,
> diff --git a/drivers/mtd/nand/sm_common.h b/drivers/mtd/nand/sm_common.h
> index d3e028e..1581671 100644
> --- a/drivers/mtd/nand/sm_common.h
> +++ b/drivers/mtd/nand/sm_common.h
> @@ -36,7 +36,7 @@ struct sm_oob {
>  #define SM_SMALL_OOB_SIZE8
>  
>  
> -extern int sm_register_device(struct mtd_info *mtd, int smartmedia);
> +int sm_register_device(struct mtd_info *mtd, int smartmedia);
>  
>  
>  static inline int sm_sector_valid(struct sm_oob *oob)

[PATCH] staging: pi433: pi433_if.c Fix SET_CHECKED style issues

[Nguyen Phan Quang Minh]

Fix checkpatch warning and add result holder variable to reduce overhead
since the macro is called on functions.

Signed-off-by: Nguyen Phan Quang Minh 
---
Since SET_CHECKED has a return statement, I'm very tempted to straight
up remove it and do the checking inline. But the macro is used a lot
(~60 times), I think it might hurt the readability of the code.

 drivers/staging/pi433/pi433_if.c | 9 ++---
 1 file changed, 6 insertions(+), 3 deletions(-)

diff --git a/drivers/staging/pi433/pi433_if.c b/drivers/staging/pi433/pi433_if.c
index 3404cb9722c9..77ab2986b985 100644
--- a/drivers/staging/pi433/pi433_if.c
+++ b/drivers/staging/pi433/pi433_if.c
@@ -122,9 +122,12 @@ struct pi433_instance {
 /*-*/
 
 /* macro for checked access of registers of radio module */
-#define SET_CHECKED(retval) \
-   if (retval < 0) \
-   return retval;
+#define SET_CHECKED(func)  \
+   do {\
+   int retval = func;  \
+   if (retval < 0) \
+   return retval;  \
+   } while (0)
 
 /*-*/
 
-- 
2.15.1

Re: [PATCH v5 2/2] leds: lm3692x: Introduce LM3692x dual string driver

[Jacek Anaszewski]

Dan,

Thanks for addressing my remarks. LED class device name
composition stills needs some tweaking, though.

Please refer below to the piece of code in question.

On 11/30/2017 08:22 PM, Dan Murphy wrote:
> Introducing the LM3692x Dual-String white LED driver.
> 
> Data sheet is located
> http://www.ti.com/lit/ds/snvsa29/snvsa29.pdf
> 
> Signed-off-by: Dan Murphy 
> ---
> v5 - Added OF dependency in Kconfig, added extra fault flag read to ensure 
> that
> if a fault exists and it is not a artifact, fixed LED class label to be 
> derived
> from either the DT child "label" node or create a label based on 
> parent_node_name:led color:trigger, removed ifdef for CONFIG_OF and removed
> of_match_ptr - https://patchwork.kernel.org/patch/10081073/
> 
> v4 - Converted to devm led class register, changed MODULE_LICENSE to GPL v2, 
> set the led name based on child node name or label entry, removed fault and
> returned read_buf for fault checking, added mutex_destroy to remove function,
> and removed LED_FULL - https://patchwork.kernel.org/patch/10060109/
> v3 - Add missing Makefile and Kconfig from v1 and v2 - 
> https://patchwork.kernel.org/patch/10060075/
> v2 - Added data sheet link, fixed linuxdoc format, returned on failure in init
> routine, return on fault_check failure, updated brightness calculation and
> fixed capitalization issue - https://patchwork.kernel.org/patch/10056675/
> 
>  drivers/leds/Kconfig|   7 +
>  drivers/leds/Makefile   |   1 +
>  drivers/leds/leds-lm3692x.c | 396 
> 
>  3 files changed, 404 insertions(+)
>  create mode 100644 drivers/leds/leds-lm3692x.c
> 
> diff --git a/drivers/leds/Kconfig b/drivers/leds/Kconfig
> index 318a28fd58fe..1d215b39cefd 100644
> --- a/drivers/leds/Kconfig
> +++ b/drivers/leds/Kconfig
> @@ -137,6 +137,13 @@ config LEDS_LM3642
> converter plus 1.5A constant current driver for a high-current
> white LED.
>  
> +config LEDS_LM3692X
> + tristate "LED support for LM3692x Chips"
> + depends on LEDS_CLASS && I2C && OF
> + select REGMAP_I2C
> + help
> +   This option enables support for the TI LM3692x family
> +   of white LED string drivers used for backlighting.
>  
>  config LEDS_LOCOMO
>   tristate "LED Support for Locomo device"
> diff --git a/drivers/leds/Makefile b/drivers/leds/Makefile
> index a2a6b5a4f86d..987884a5b9a5 100644
> --- a/drivers/leds/Makefile
> +++ b/drivers/leds/Makefile
> @@ -74,6 +74,7 @@ obj-$(CONFIG_LEDS_PM8058)   += leds-pm8058.o
>  obj-$(CONFIG_LEDS_MLXCPLD)   += leds-mlxcpld.o
>  obj-$(CONFIG_LEDS_NIC78BX)   += leds-nic78bx.o
>  obj-$(CONFIG_LEDS_MT6323)+= leds-mt6323.o
> +obj-$(CONFIG_LEDS_LM3692X)   += leds-lm3692x.o
>  
>  # LED SPI Drivers
>  obj-$(CONFIG_LEDS_DAC124S085)+= leds-dac124s085.o
> diff --git a/drivers/leds/leds-lm3692x.c b/drivers/leds/leds-lm3692x.c
> new file mode 100644
> index ..70c974e06bd7
> --- /dev/null
> +++ b/drivers/leds/leds-lm3692x.c
> @@ -0,0 +1,396 @@
> +/*
> + * TI lm3692x LED Driver
> + *
> + * Copyright (C) 2017 Texas Instruments
> + *
> + * Author: Dan Murphy 
> + *
> + * This program is free software; you can redistribute it and/or
> + * modify it under the terms of the GNU General Public License
> + * version 2 as published by the Free Software Foundation.
> + *
> + * Data sheet is located
> + * http://www.ti.com/lit/ds/snvsa29/snvsa29.pdf
> + */
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +#define LM3692X_REV  0x0
> +#define LM3692X_RESET0x1
> +#define LM3692X_EN   0x10
> +#define LM3692X_BRT_CTRL 0x11
> +#define LM3692X_PWM_CTRL 0x12
> +#define LM3692X_BOOST_CTRL   0x13
> +#define LM3692X_AUTO_FREQ_HI 0x15
> +#define LM3692X_AUTO_FREQ_LO 0x16
> +#define LM3692X_BL_ADJ_THRESH0x17
> +#define LM3692X_BRT_LSB  0x18
> +#define LM3692X_BRT_MSB  0x19
> +#define LM3692X_FAULT_CTRL   0x1e
> +#define LM3692X_FAULT_FLAGS  0x1f
> +
> +#define LM3692X_SW_RESET BIT(0)
> +#define LM3692X_DEVICE_ENBIT(0)
> +#define LM3692X_LED1_EN  BIT(1)
> +#define LM3692X_LED2_EN  BIT(2)
> +
> +/* Brightness Control Bits */
> +#define LM3692X_BL_ADJ_POL   BIT(0)
> +#define LM3692X_RAMP_RATE_125us  0x00
> +#define LM3692X_RAMP_RATE_250us  BIT(1)
> +#define LM3692X_RAMP_RATE_500us BIT(2)
> +#define LM3692X_RAMP_RATE_1ms(BIT(1) | BIT(2))
> +#define LM3692X_RAMP_RATE_2msBIT(3)
> +#define LM3692X_RAMP_RATE_4ms(BIT(3) | BIT(1))
> +#define LM3692X_RAMP_RATE_8ms(BIT(2) | BIT(3))
> +#define LM3692X_RAMP_RATE_16ms   (BIT(1) | BIT(2) | BIT(3))
> +#define LM3692X_RAMP_EN  BIT(4)
> +#define LM3692X_BRHT_MODE_REG0x00
> +#define LM3692X_BRHT_MODE_PWMBIT(5)
> +#define LM3692X_BRHT_MODE_MULTI_RAM

Re: [PATCH v2 16/23] test_firmware: enable custom fallback testing on limited kernel configs

[Shuah Khan]

On 11/30/2017 01:31 PM, Luis R. Rodriguez wrote:
> On Wed, Nov 29, 2017 at 11:22:35AM +0100, Greg KH wrote:
>> On Mon, Nov 20, 2017 at 10:24:02AM -0800, Luis R. Rodriguez wrote:
>>> When a kernel is not built with:
>>>
>>> CONFIG_HAS_FW_LOADER_USER_HELPER_FALLBACK=y
>>>
>>> We don't currently enable testing fw_fallback.sh. For kernels that
>>> still enable the fallback mechanism, its possible to use the async
>>> request firmware API call request_firmware_nowait() using the custom
>>> interface to use the fallback mechanism, so we should be able to test
>>> this but we currently cannot.
>>>
>>> We can enable testing without CONFIG_HAS_FW_LOADER_USER_HELPER_FALLBACK=y
>>> by relying on /proc/config.gz (CONFIG_IKCONFIG_PROC), if present. If you
>>> don't have this we'll have no option but to rely on old heuristics for now.
>>>
>>> Signed-off-by: Luis R. Rodriguez 
>>> ---
>>>  tools/testing/selftests/firmware/config |  4 +++
>>>  tools/testing/selftests/firmware/fw_fallback.sh | 45 
>>> -
>>>  2 files changed, 48 insertions(+), 1 deletion(-)
>>>
>>> diff --git a/tools/testing/selftests/firmware/config 
>>> b/tools/testing/selftests/firmware/config
>>> index c8137f70e291..bf634dda0720 100644
>>> --- a/tools/testing/selftests/firmware/config
>>> +++ b/tools/testing/selftests/firmware/config
>>> @@ -1 +1,5 @@
>>>  CONFIG_TEST_FIRMWARE=y
>>> +CONFIG_FW_LOADER=y
>>> +CONFIG_FW_LOADER_USER_HELPER=y
>>> +CONFIG_IKCONFIG=y
>>> +CONFIG_IKCONFIG_PROC=y
>>> diff --git a/tools/testing/selftests/firmware/fw_fallback.sh 
>>> b/tools/testing/selftests/firmware/fw_fallback.sh
>>> index 722cad91df74..a42e437363d9 100755
>>> --- a/tools/testing/selftests/firmware/fw_fallback.sh
>>> +++ b/tools/testing/selftests/firmware/fw_fallback.sh
>>> @@ -6,7 +6,46 @@
>>>  # won't find so that we can do the load ourself manually.
>>>  set -e
>>>  
>>> +PROC_CONFIG="/proc/config.gz"
>>> +TEST_DIR=$(dirname $0)
>>> +
>>>  modprobe test_firmware
>>> +if [ ! -f $PROC_CONFIG ]; then
>>> +   if modprobe configs 2>/dev/null; then
>>> +   echo "Loaded configs module"
>>> +   if [ ! -f $PROC_CONFIG ]; then
>>> +   echo "You must have the following enabled in your 
>>> kernel:" >&2
>>> +   cat $TEST_DIR/config >&2
>>> +   echo "Resorting to old heuristics" >&2
>>> +   fi
>>> +   else
>>> +   echo "Failed to load configs module, using old heuristics" >&2
>>> +   fi
>>> +fi
>>> +
>>> +kconfig_has()
>>> +{
>>> +   if [ -f $PROC_CONFIG ]; then
>>> +   if zgrep -q $1 $PROC_CONFIG 2>/dev/null; then
>>> +   echo "yes"
>>> +   else
>>> +   echo "no"
>>> +   fi
>>> +   else
>>> +   # We currently don't have easy heuristics to infer this
>>> +   # so best we can do is just try to use the kernel assuming
>>> +   # you had enabled it. This matches the old behaviour.
>>> +   if [ "$1" = "CONFIG_FW_LOADER_USER_HELPER_FALLBACK=y" ]; then
>>> +   echo "yes"
>>> +   elif [ "$1" = "CONFIG_FW_LOADER_USER_HELPER=y" ]; then
>>> +   if [ -d /sys/class/firmware/ ]; then
>>> +   echo yes
>>> +   else
>>> +   echo no
>>> +   fi
>>> +   fi
>>> +   fi
>>> +}
>>
>> Shouldn't these functions be part of the kselftest core so that all
>> tests can take advantage of them instead of having to hand-roll them for
>> every individual test?
> 
> At a first glance it would seem to be nice.
> 
> Note that in our case we'd still need a way to work without 
> CONFIG_IKCONFIG_PROC,
> hence that big else condition, to ensure it works for kernels without
> CONFIG_IKCONFIG_PROC set, so we'd still end up with our own fw_kconfig_has(),
> and if we had a generic helper it'd look very similar... something like:
> 
> fw_kconfig_has()
> {
>   if [ has_proc_config ]; then
>   echo $(kconfig_has("$1"))
>   else
>   # We currently don't have easy heuristics to infer this
>   # so best we can do is just try to use the kernel assuming
>   # you had enabled it. This matches the old behaviour.
>   if [ "$1" = "CONFIG_FW_LOADER_USER_HELPER_FALLBACK=y" ]; then
>   echo "yes"
>   elif [ "$1" = "CONFIG_FW_LOADER_USER_HELPER=y" ]; then
>   if [ -d /sys/class/firmware/ ]; then
>   echo yes
>   else
>   echo no
>   fi
>   fi
>   fi
> }
> 
> Not sure if there is a big gain then for now.
> 
> Shuah, what do you think? Is it worth it? Do we have a generic bash library we
> can use?  If not, if I add one, so that other scripts can source it, where
> should I add it?

There is no generic script right now. It depends on whether or not a
generic script will help. Can it

[PATCH] NTB: ntb_hw_idt: Set NTB_TOPO_SWITCH topology

[Serge Semin]

Since Switchtec patch there has been a new topology added to
the NTB API. It's called NTB_TOPO_SWITCH and dedicated for
PCIe switch chips. Even though topo field isn't used within the
IDT driver much, lets set it for the sake of unification.

Signed-off-by: Serge Semin 
Acked-by: Serge Semin 
---
 drivers/ntb/hw/idt/ntb_hw_idt.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/ntb/hw/idt/ntb_hw_idt.c b/drivers/ntb/hw/idt/ntb_hw_idt.c
index d87dbd4bc82c..27fdd14e0dca 100644
--- a/drivers/ntb/hw/idt/ntb_hw_idt.c
+++ b/drivers/ntb/hw/idt/ntb_hw_idt.c
@@ -2070,7 +2070,7 @@ static int idt_register_device(struct idt_ntb_dev *ndev)
 
/* Initialize the rest of NTB device structure and register it */
ndev->ntb.ops = &idt_ntb_ops;
-   ndev->ntb.topo = NTB_TOPO_PRI;
+   ndev->ntb.topo = NTB_TOPO_SWITCH;
 
ret = ntb_register_device(&ndev->ntb);
if (ret != 0) {
-- 
2.12.0

[PATCH 02/08] NTB: ntb_test: Add ntb_tool port tests

[Serge Semin]

Multi-port interface is now available in ntb_tool driver. According
to the new NTB API, there might be more than two devices connected over
NTB. It means each device can have multiple freely enumerated ports.
Each port got index assigned by NTB hardware driver. This test is
performed to determine the local and peer ports as well as their indexes.

Signed-off-by: Serge Semin 
---
 tools/testing/selftests/ntb/ntb_test.sh | 52 +
 1 file changed, 52 insertions(+)

diff --git a/tools/testing/selftests/ntb/ntb_test.sh 
b/tools/testing/selftests/ntb/ntb_test.sh
index a8647ad891eb..541ba70ad640 100755
--- a/tools/testing/selftests/ntb/ntb_test.sh
+++ b/tools/testing/selftests/ntb/ntb_test.sh
@@ -127,6 +127,56 @@ function write_file()
fi
 }
 
+function check_file()
+{
+   split_remote $1
+
+   if [[ "$REMOTE" != "" ]]; then
+   ssh "$REMOTE" "[[ -e ${VPATH} ]]"
+   else
+   [[ -e ${VPATH} ]]
+   fi
+}
+
+function find_pidx()
+{
+   PORT=$1
+   PPATH=$2
+
+   for ((i = 0; i < 64; i++)); do
+   PEER_DIR="$PPATH/peer$i"
+
+   check_file ${PEER_DIR} || break
+
+   PEER_PORT=$(read_file "${PEER_DIR}/port")
+   if [[ ${PORT} -eq $PEER_PORT ]]; then
+   echo $i
+   return 0
+   fi
+   done
+
+   return 1
+}
+
+function port_test()
+{
+   LOC=$1
+   REM=$2
+
+   echo "Running port tests on: $(basename $LOC) / $(basename $REM)"
+
+   LOCAL_PORT=$(read_file "$LOC/port")
+   REMOTE_PORT=$(read_file "$REM/port")
+
+   LOCAL_PIDX=$(find_pidx ${REMOTE_PORT} "$LOC")
+   REMOTE_PIDX=$(find_pidx ${LOCAL_PORT} "$REM")
+
+   echo "Local port ${LOCAL_PORT} with index ${REMOTE_PIDX} on remote host"
+   echo "Peer port ${REMOTE_PORT} with index ${LOCAL_PIDX} on local host"
+
+   echo "  Passed"
+}
+
 function link_test()
 {
LOC=$1
@@ -327,6 +377,8 @@ function ntb_tool_tests()
 
_modprobe ntb_tool
 
+   port_test "$LOCAL_TOOL" "$REMOTE_TOOL"
+
write_file "Y" "$LOCAL_TOOL/link_event"
write_file "Y" "$REMOTE_TOOL/link_event"
 
-- 
2.12.0

[PATCH v2 0/2] iio: hx711: add buffered trigger support

[Andreas Klinger]

changes in v2:
- in Kconfig it's needed to select IIO_BUFFER and IIO_TRIGGERED_BUFFER to
  compile cleanly with buffered triggers

This small patch series adds:
- support for buffered triggers
- fixes a bug in the reset functionality

Andreas Klinger (2):
  iio: hx711: add triggered buffer support
  iio: hx711: fix bug in reset functionality

 drivers/iio/adc/Kconfig |   2 +
 drivers/iio/adc/hx711.c | 119 ++--
 2 files changed, 96 insertions(+), 25 deletions(-)

-- 
2.1.4


-- 

[PATCH 04/08] NTB: ntb_test: Update ntb_tool DB tests

[Serge Semin]

DB interface of ntb_tool driver hasn't been changed much, but
db_valid_mask DebugFS file has still been added. In this case
it's much better to test all valid DB bits instead of using
the predefined mask, which may be incorrect in general.

Signed-off-by: Serge Semin 
---
 tools/testing/selftests/ntb/ntb_test.sh | 29 ++---
 1 file changed, 18 insertions(+), 11 deletions(-)

diff --git a/tools/testing/selftests/ntb/ntb_test.sh 
b/tools/testing/selftests/ntb/ntb_test.sh
index 247458c6d8dc..3d43885ea4b5 100755
--- a/tools/testing/selftests/ntb/ntb_test.sh
+++ b/tools/testing/selftests/ntb/ntb_test.sh
@@ -18,7 +18,6 @@ LIST_DEVS=FALSE
 
 DEBUGFS=${DEBUGFS-/sys/kernel/debug}
 
-DB_BITMASK=0x7FFF
 PERF_RUN_ORDER=32
 MAX_MW_SIZE=0
 RUN_DMA_TESTS=
@@ -39,7 +38,6 @@ function show_help()
echo "be highly recommended."
echo
echo "Options:"
-   echo "  -b BITMASK  doorbell clear bitmask for ntb_tool"
echo "  -C  don't cleanup ntb modules on exit"
echo "  -d  run dma tests"
echo "  -h  show this help message"
@@ -56,7 +54,6 @@ function parse_args()
OPTIND=0
while getopts "b:Cdhlm:r:p:w:" opt; do
case "$opt" in
-   b)  DB_BITMASK=${OPTARG} ;;
C)  DONT_CLEANUP=1 ;;
d)  RUN_DMA_TESTS=1 ;;
h)  show_help; exit 0 ;;
@@ -215,21 +212,30 @@ function doorbell_test()
 
echo "Running db tests on: $(basename $LOC) / $(basename $REM)"
 
-   write_file "c $DB_BITMASK" "$REM/db"
+   DB_VALID_MASK=$(read_file "$LOC/db_valid_mask")
 
-   for ((i=1; i <= 8; i++)); do
-   let DB=$(read_file "$REM/db") || true
-   if [[ "$DB" != "$EXP" ]]; then
+   write_file "c $DB_VALID_MASK" "$REM/db"
+
+   for ((i = 0; i < 64; i++)); do
+   DB=$(read_file "$REM/db")
+   if [[ "$DB" -ne "$EXP" ]]; then
echo "Doorbell doesn't match expected value $EXP " \
 "in $REM/db" >&2
exit -1
fi
 
-   let "MASK=1 << ($i-1)" || true
-   let "EXP=$EXP | $MASK" || true
+   let "MASK = (1 << $i) & $DB_VALID_MASK" || true
+   let "EXP = $EXP | $MASK" || true
+
write_file "s $MASK" "$LOC/peer_db"
done
 
+   write_file "c $DB_VALID_MASK" "$REM/db_mask"
+   write_file $DB_VALID_MASK "$REM/db_event"
+   write_file "s $DB_VALID_MASK" "$REM/db_mask"
+
+   write_file "c $DB_VALID_MASK" "$REM/db"
+
echo "  Passed"
 }
 
@@ -393,14 +399,15 @@ function ntb_tool_tests()
write_file "Y" "$LOCAL_PEER_TOOL/link_event"
write_file "Y" "$REMOTE_PEER_TOOL/link_event"
 
+   doorbell_test "$LOCAL_TOOL" "$REMOTE_TOOL"
+   doorbell_test "$REMOTE_TOOL" "$LOCAL_TOOL"
+
for PEER_TRANS in $(ls "$LOCAL_TOOL"/peer_trans*); do
PT=$(basename $PEER_TRANS)
write_file $MW_SIZE "$LOCAL_TOOL/$PT"
write_file $MW_SIZE "$REMOTE_TOOL/$PT"
done
 
-   doorbell_test "$LOCAL_TOOL" "$REMOTE_TOOL"
-   doorbell_test "$REMOTE_TOOL" "$LOCAL_TOOL"
scratchpad_test "$LOCAL_TOOL" "$REMOTE_TOOL"
scratchpad_test "$REMOTE_TOOL" "$LOCAL_TOOL"
 
-- 
2.12.0

[PATCH 06/08] NTB: ntb_test: Add ntb_tool Message tests

[Serge Semin]

Messages NTB API is now available. ntb_tool driver has been altered
to perform messages send and receive operation. The test of messages
read/write to/from peer device has been added to the script.

Signed-off-by: Serge Semin 
---
 tools/testing/selftests/ntb/ntb_test.sh | 37 +
 1 file changed, 37 insertions(+)

diff --git a/tools/testing/selftests/ntb/ntb_test.sh 
b/tools/testing/selftests/ntb/ntb_test.sh
index d37c974902e5..36f6a444c0d9 100755
--- a/tools/testing/selftests/ntb/ntb_test.sh
+++ b/tools/testing/selftests/ntb/ntb_test.sh
@@ -282,6 +282,40 @@ function scratchpad_test()
echo "  Passed"
 }
 
+function message_test()
+{
+   LOC=$1
+   REM=$2
+
+   echo "Running msg tests on: $(subdirname $LOC) / $(subdirname $REM)"
+
+   CNT=$(get_files_count "msg" "$LOC")
+
+   if [[ $CNT -eq 0 ]]; then
+   echo "  Unsupported"
+   return
+   fi
+
+   MSG_OUTBITS_MASK=$(read_file "$LOC/../msg_inbits")
+   MSG_INBITS_MASK=$(read_file "$REM/../msg_inbits")
+
+   write_file "c $MSG_OUTBITS_MASK" "$LOC/../msg_sts"
+   write_file "c $MSG_INBITS_MASK" "$REM/../msg_sts"
+
+   for ((i = 0; i < $CNT; i++)); do
+   VAL=$RANDOM
+   write_file "$VAL" "$LOC/msg$i"
+   RVAL=$(read_file "$REM/../msg$i")
+
+   if [[ "$VAL" -ne "${RVAL%%<-*}" ]]; then
+   echo "Message $i value $RVAL doesn't match $VAL" >&2
+   exit -1
+   fi
+   done
+
+   echo "  Passed"
+}
+
 function write_mw()
 {
split_remote $2
@@ -414,6 +448,9 @@ function ntb_tool_tests()
scratchpad_test "$LOCAL_PEER_TOOL" "$REMOTE_PEER_TOOL"
scratchpad_test "$REMOTE_PEER_TOOL" "$LOCAL_PEER_TOOL"
 
+   message_test "$LOCAL_PEER_TOOL" "$REMOTE_PEER_TOOL"
+   message_test "$REMOTE_PEER_TOOL" "$LOCAL_PEER_TOOL"
+
for PEER_TRANS in $(ls "$LOCAL_TOOL"/peer_trans*); do
PT=$(basename $PEER_TRANS)
write_file $MW_SIZE "$LOCAL_TOOL/$PT"
-- 
2.12.0

[PATCH 08/08] NTB: ntb_test: Update ntb_perf tests

[Serge Semin]

ntb_perf driver has been also updated so to have the multi-port
interface support. User now must specify what peer port is going
to be used to perform the test.

Signed-off-by: Serge Semin 
---
 tools/testing/selftests/ntb/ntb_test.sh | 13 +++--
 1 file changed, 7 insertions(+), 6 deletions(-)

diff --git a/tools/testing/selftests/ntb/ntb_test.sh 
b/tools/testing/selftests/ntb/ntb_test.sh
index 88c8ceb20607..b91497d1291f 100755
--- a/tools/testing/selftests/ntb/ntb_test.sh
+++ b/tools/testing/selftests/ntb/ntb_test.sh
@@ -39,15 +39,16 @@ function show_help()
echo
echo "Options:"
echo "  -C  don't cleanup ntb modules on exit"
-   echo "  -d  run dma tests"
echo "  -h  show this help message"
echo "  -l  list available local and remote PCI ids"
echo "  -r REMOTE_HOST  specify the remote's hostname to connect"
echo "  to for the test (using ssh)"
echo "  -m MW_SIZE  memory window size for ntb_tool"
echo "  (default: $MW_SIZE)"
-   echo "  -p NUM  ntb_perf run order (default: $PERF_RUN_ORDER)"
-   echo "  -w max_mw_size  maxmium memory window size"
+   echo "  -d  run dma tests for ntb_perf"
+   echo "  -p ORDERtotal data order for ntb_perf"
+   echo "  (default: $PERF_RUN_ORDER)"
+   echo "  -w MAX_MW_SIZE  maxmium memory window size for ntb_perf"
echo
 }
 
@@ -460,17 +461,17 @@ function perf_test()
WITH="without"
fi
 
-   _modprobe ntb_perf run_order=$PERF_RUN_ORDER \
+   _modprobe ntb_perf total_order=$PERF_RUN_ORDER \
max_mw_size=$MAX_MW_SIZE use_dma=$USE_DMA
 
echo "Running local perf test $WITH DMA"
-   write_file "" "$LOCAL_PERF/run"
+   write_file "$LOCAL_PIDX" "$LOCAL_PERF/run"
echo -n "  "
read_file "$LOCAL_PERF/run"
echo "  Passed"
 
echo "Running remote perf test $WITH DMA"
-   write_file "" "$REMOTE_PERF/run"
+   write_file "$REMOTE_PIDX" "$REMOTE_PERF/run"
echo -n "  "
read_file "$REMOTE_PERF/run"
echo "  Passed"
-- 
2.12.0

[PATCH v2 1/2] iio: hx711: add triggered buffer support

[Andreas Klinger]

Add buffer to device data struct and add trigger function

Data format is quite simple:
  voltage - channel 0   32 Bit
  voltage - channel 1   32 Bit
  timestamp 64 Bit

Using both channels at the same time is working quite slow because of
changing the channel which needs a dummy read.

Signed-off-by: Andreas Klinger 
---
 drivers/iio/adc/Kconfig |   2 +
 drivers/iio/adc/hx711.c | 106 
 2 files changed, 90 insertions(+), 18 deletions(-)

diff --git a/drivers/iio/adc/Kconfig b/drivers/iio/adc/Kconfig
index af4fc1279409..a83642e517d5 100644
--- a/drivers/iio/adc/Kconfig
+++ b/drivers/iio/adc/Kconfig
@@ -316,6 +316,8 @@ config HI8435
 config HX711
tristate "AVIA HX711 ADC for weight cells"
depends on GPIOLIB
+   select IIO_BUFFER
+   select IIO_TRIGGERED_BUFFER
help
  If you say yes here you get support for AVIA HX711 ADC which is used
  for weigh cells
diff --git a/drivers/iio/adc/hx711.c b/drivers/iio/adc/hx711.c
index d10b9f13d557..d773fd69a76d 100644
--- a/drivers/iio/adc/hx711.c
+++ b/drivers/iio/adc/hx711.c
@@ -24,6 +24,9 @@
 #include 
 #include 
 #include 
+#include 
+#include 
+#include 
 #include 
 #include 
 
@@ -89,6 +92,11 @@ struct hx711_data {
int gain_set;   /* gain set on device */
int gain_chan_a;/* gain for channel A */
struct mutexlock;
+   /*
+* triggered buffer
+* 2x32-bit channel + 2x32-bit timestamp
+*/
+   u32 buffer[4];
 };
 
 static int hx711_cycle(struct hx711_data *hx711_data)
@@ -236,34 +244,43 @@ static int hx711_set_gain_for_channel(struct hx711_data 
*hx711_data, int chan)
return 0;
 }
 
+static int hx711_reset_read(struct hx711_data *hx711_data, int chan)
+{
+   int ret;
+   int val;
+
+   /*
+* hx711_reset() must be called from here
+* because it could be calling hx711_read() by itself
+*/
+   if (hx711_reset(hx711_data)) {
+   mutex_unlock(&hx711_data->lock);
+   dev_err(hx711_data->dev, "reset failed!");
+   return -EIO;
+   }
+
+   ret = hx711_set_gain_for_channel(hx711_data, chan);
+   if (ret < 0) {
+   mutex_unlock(&hx711_data->lock);
+   return ret;
+   }
+
+   val = hx711_read(hx711_data);
+
+   return val;
+}
+
 static int hx711_read_raw(struct iio_dev *indio_dev,
const struct iio_chan_spec *chan,
int *val, int *val2, long mask)
 {
struct hx711_data *hx711_data = iio_priv(indio_dev);
-   int ret;
 
switch (mask) {
case IIO_CHAN_INFO_RAW:
mutex_lock(&hx711_data->lock);
 
-   /*
-* hx711_reset() must be called from here
-* because it could be calling hx711_read() by itself
-*/
-   if (hx711_reset(hx711_data)) {
-   mutex_unlock(&hx711_data->lock);
-   dev_err(hx711_data->dev, "reset failed!");
-   return -EIO;
-   }
-
-   ret = hx711_set_gain_for_channel(hx711_data, chan->channel);
-   if (ret < 0) {
-   mutex_unlock(&hx711_data->lock);
-   return ret;
-   }
-
-   *val = hx711_read(hx711_data);
+   *val = hx711_reset_read(hx711_data, chan->channel);
 
mutex_unlock(&hx711_data->lock);
 
@@ -339,6 +356,35 @@ static int hx711_write_raw_get_fmt(struct iio_dev 
*indio_dev,
return IIO_VAL_INT_PLUS_NANO;
 }
 
+static irqreturn_t hx711_trigger(int irq, void *p)
+{
+   struct iio_poll_func *pf = p;
+   struct iio_dev *indio_dev = pf->indio_dev;
+   struct hx711_data *hx711_data = iio_priv(indio_dev);
+   int i;
+
+   mutex_lock(&hx711_data->lock);
+
+   memset(hx711_data->buffer, 0, sizeof(hx711_data->buffer));
+
+   for (i = 0; i < indio_dev->masklength; i++) {
+   if (!test_bit(i, indio_dev->active_scan_mask))
+   continue;
+
+   hx711_data->buffer[i] = hx711_reset_read(hx711_data,
+   indio_dev->channels[i].channel);
+   }
+
+   iio_push_to_buffers_with_timestamp(indio_dev, hx711_data->buffer,
+   pf->timestamp);
+
+   mutex_unlock(&hx711_data->lock);
+
+   iio_trigger_notify_done(indio_dev->trig);
+
+   return IRQ_HANDLED;
+}
+
 static ssize_t hx711_scale_available_show(struct device *dev,
struct device_attribute *attr,
char *buf)
@@ -387,6 +433,14 @@ static const struct iio_chan_spec hx711_chan_spec[] = {
.indexed = 1,
.info_mask_separate = BIT(IIO_CHAN

[PATCH 07/08] NTB: ntb_test: Update ntb_tool MW tests

[Serge Semin]

There are devices (like IDT PCIe switches), which outbound MWs xlat address
is setup on peer side. In this case local side is supposed to allocate
a memory buffer and somehow deliver the xlat DMA address to peer so one
could set the outbound MW up. The MW test is altered so to support both
previous Intel/AMD and new IDT-like devices.

Signed-off-by: Serge Semin 
---
 tools/testing/selftests/ntb/ntb_test.sh | 89 +
 1 file changed, 68 insertions(+), 21 deletions(-)

diff --git a/tools/testing/selftests/ntb/ntb_test.sh 
b/tools/testing/selftests/ntb/ntb_test.sh
index 36f6a444c0d9..88c8ceb20607 100755
--- a/tools/testing/selftests/ntb/ntb_test.sh
+++ b/tools/testing/selftests/ntb/ntb_test.sh
@@ -43,7 +43,9 @@ function show_help()
echo "  -h  show this help message"
echo "  -l  list available local and remote PCI ids"
echo "  -r REMOTE_HOST  specify the remote's hostname to connect"
-echo "  to for the test (using ssh)"
+   echo "  to for the test (using ssh)"
+   echo "  -m MW_SIZE  memory window size for ntb_tool"
+   echo "  (default: $MW_SIZE)"
echo "  -p NUM  ntb_perf run order (default: $PERF_RUN_ORDER)"
echo "  -w max_mw_size  maxmium memory window size"
echo
@@ -316,6 +318,32 @@ function message_test()
echo "  Passed"
 }
 
+function get_number()
+{
+   KEY=$1
+
+   sed -n "s/^\(${KEY}\)[ \t]*\(0x[0-9a-fA-F]*\)\(\[p\]\)\?$/\2/p"
+}
+
+function mw_alloc()
+{
+   IDX=$1
+   LOC=$2
+   REM=$3
+
+   write_file $MW_SIZE "$LOC/mw_trans$IDX"
+
+   INB_MW=$(read_file "$LOC/mw_trans$IDX")
+   MW_ALIGNED_SIZE=$(echo "$INB_MW" | get_number "Window Size")
+   MW_DMA_ADDR=$(echo "$INB_MW" | get_number "DMA Address")
+
+   write_file "$MW_DMA_ADDR:$(($MW_ALIGNED_SIZE))" "$REM/peer_mw_trans$IDX"
+
+   if [[ $MW_SIZE -ne $MW_ALIGNED_SIZE ]]; then
+   echo "MW $IDX size aligned to $MW_ALIGNED_SIZE"
+   fi
+}
+
 function write_mw()
 {
split_remote $2
@@ -328,17 +356,15 @@ function write_mw()
fi
 }
 
-function mw_test()
+function mw_check()
 {
IDX=$1
LOC=$2
REM=$3
 
-   echo "Running $IDX tests on: $(basename $LOC) / $(basename $REM)"
-
-   write_mw "$LOC/$IDX"
+   write_mw "$LOC/mw$IDX"
 
-   split_remote "$LOC/$IDX"
+   split_remote "$LOC/mw$IDX"
if [[ "$REMOTE" == "" ]]; then
A=$VPATH
else
@@ -346,7 +372,7 @@ function mw_test()
ssh "$REMOTE" cat "$VPATH" > "$A"
fi
 
-   split_remote "$REM/peer_$IDX"
+   split_remote "$REM/peer_mw$IDX"
if [[ "$REMOTE" == "" ]]; then
B=$VPATH
else
@@ -354,7 +380,7 @@ function mw_test()
ssh "$REMOTE" cat "$VPATH" > "$B"
fi
 
-   cmp -n $MW_SIZE "$A" "$B"
+   cmp -n $MW_ALIGNED_SIZE "$A" "$B"
if [[ $? != 0 ]]; then
echo "Memory window $MW did not match!" >&2
fi
@@ -366,8 +392,39 @@ function mw_test()
if [[ "$B" == "/tmp/*" ]]; then
rm "$B"
fi
+}
+
+function mw_free()
+{
+   IDX=$1
+   LOC=$2
+   REM=$3
+
+   write_file "$MW_DMA_ADDR:0" "$REM/peer_mw_trans$IDX"
+
+   write_file 0 "$LOC/mw_trans$IDX"
+}
+
+function mw_test()
+{
+   LOC=$1
+   REM=$2
+
+   CNT=$(get_files_count "mw_trans" "$LOC")
+
+   for ((i = 0; i < $CNT; i++)); do
+   echo "Running mw$i tests on: $(subdirname $LOC) / " \
+"$(subdirname $REM)"
+
+   mw_alloc $i $LOC $REM
+
+   mw_check $i $LOC $REM
+
+   mw_free $i $LOC  $REM
+
+   echo "  Passed"
+   done
 
-   echo "  Passed"
 }
 
 function pingpong_test()
@@ -451,18 +508,8 @@ function ntb_tool_tests()
message_test "$LOCAL_PEER_TOOL" "$REMOTE_PEER_TOOL"
message_test "$REMOTE_PEER_TOOL" "$LOCAL_PEER_TOOL"
 
-   for PEER_TRANS in $(ls "$LOCAL_TOOL"/peer_trans*); do
-   PT=$(basename $PEER_TRANS)
-   write_file $MW_SIZE "$LOCAL_TOOL/$PT"
-   write_file $MW_SIZE "$REMOTE_TOOL/$PT"
-   done
-
-   for MW in $(ls "$LOCAL_TOOL"/mw*); do
-   MW=$(basename $MW)
-
-   mw_test $MW "$LOCAL_TOOL" "$REMOTE_TOOL"
-   mw_test $MW "$REMOTE_TOOL" "$LOCAL_TOOL"
-   done
+   mw_test "$LOCAL_PEER_TOOL" "$REMOTE_PEER_TOOL"
+   mw_test "$REMOTE_PEER_TOOL" "$LOCAL_PEER_TOOL"
 
_modprobe -r ntb_tool
 }
-- 
2.12.0

[PATCH 05/08] NTB: ntb_test: Update ntb_tool Scratchpad tests

[Serge Semin]

Scratchpad NTB API has changed so has the ntb_tool driver. Outbound
Scratchpad DebugFS files have been moved to peer specific directories.
Each scratchpad is now available via separate file. The test code
has been accordingly altered.

Signed-off-by: Serge Semin 
---
 tools/testing/selftests/ntb/ntb_test.sh | 43 -
 1 file changed, 26 insertions(+), 17 deletions(-)

diff --git a/tools/testing/selftests/ntb/ntb_test.sh 
b/tools/testing/selftests/ntb/ntb_test.sh
index 3d43885ea4b5..d37c974902e5 100755
--- a/tools/testing/selftests/ntb/ntb_test.sh
+++ b/tools/testing/selftests/ntb/ntb_test.sh
@@ -239,35 +239,44 @@ function doorbell_test()
echo "  Passed"
 }
 
-function read_spad()
+function get_files_count()
 {
-   VPATH=$1
-   IDX=$2
+   NAME=$1
+   LOC=$2
+
+   split_remote $LOC
 
-   ROW=($(read_file "$VPATH" | grep -e "^$IDX"))
-   let VAL=${ROW[1]} || true
-   echo $VAL
+   if [[ "$REMOTE" == "" ]]; then
+   echo $(ls -1 "$LOC"/${NAME}* 2>/dev/null | wc -l)
+   else
+   echo $(ssh "$REMOTE" "ls -1 \"$VPATH\"/${NAME}* | \
+  wc -l" 2> /dev/null)
+   fi
 }
 
 function scratchpad_test()
 {
LOC=$1
REM=$2
-   CNT=$(read_file "$LOC/spad" | wc -l)
 
-   echo "Running spad tests on: $(basename $LOC) / $(basename $REM)"
+   echo "Running spad tests on: $(subdirname $LOC) / $(subdirname $REM)"
+
+   CNT=$(get_files_count "spad" "$LOC")
+
+   if [[ $CNT -eq 0 ]]; then
+   echo "  Unsupported"
+   return
+   fi
 
for ((i = 0; i < $CNT; i++)); do
VAL=$RANDOM
-   write_file "$i $VAL" "$LOC/peer_spad"
-   RVAL=$(read_spad "$REM/spad" $i)
+   write_file "$VAL" "$LOC/spad$i"
+   RVAL=$(read_file "$REM/../spad$i")
 
-   if [[ "$VAL" != "$RVAL" ]]; then
-   echo "Scratchpad doesn't match expected value $VAL " \
-"in $REM/spad, got $RVAL" >&2
+   if [[ "$VAL" -ne "$RVAL" ]]; then
+   echo "Scratchpad $i value $RVAL doesn't match $VAL" >&2
exit -1
fi
-
done
 
echo "  Passed"
@@ -402,15 +411,15 @@ function ntb_tool_tests()
doorbell_test "$LOCAL_TOOL" "$REMOTE_TOOL"
doorbell_test "$REMOTE_TOOL" "$LOCAL_TOOL"
 
+   scratchpad_test "$LOCAL_PEER_TOOL" "$REMOTE_PEER_TOOL"
+   scratchpad_test "$REMOTE_PEER_TOOL" "$LOCAL_PEER_TOOL"
+
for PEER_TRANS in $(ls "$LOCAL_TOOL"/peer_trans*); do
PT=$(basename $PEER_TRANS)
write_file $MW_SIZE "$LOCAL_TOOL/$PT"
write_file $MW_SIZE "$REMOTE_TOOL/$PT"
done
 
-   scratchpad_test "$LOCAL_TOOL" "$REMOTE_TOOL"
-   scratchpad_test "$REMOTE_TOOL" "$LOCAL_TOOL"
-
for MW in $(ls "$LOCAL_TOOL"/mw*); do
MW=$(basename $MW)
 
-- 
2.12.0

[PATCH v2 2/2] iio: hx711: fix bug in reset functionality

[Andreas Klinger]

return value in hx711_reset() should indicate status of dout
otherwise the calling function is reporting an error als false positive

wait up to 1 second until the device is in normal state
by changing the channel on every trigger event it turned out that the
former 100 ms are not enough for waiting until the device is in normal mode

Signed-off-by: Andreas Klinger 
---
 drivers/iio/adc/hx711.c | 13 ++---
 1 file changed, 6 insertions(+), 7 deletions(-)

diff --git a/drivers/iio/adc/hx711.c b/drivers/iio/adc/hx711.c
index d773fd69a76d..eabd2e66aca3 100644
--- a/drivers/iio/adc/hx711.c
+++ b/drivers/iio/adc/hx711.c
@@ -153,15 +153,16 @@ static int hx711_wait_for_ready(struct hx711_data 
*hx711_data)
int i, val;
 
/*
-* a maximum reset cycle time of 56 ms was measured.
-* we round it up to 100 ms
+* in some rare cases the reset takes quite a long time
+* especially when the channel is changed.
+* Allow up to one second for it
 */
for (i = 0; i < 100; i++) {
val = gpiod_get_value(hx711_data->gpiod_dout);
if (!val)
break;
-   /* sleep at least 1 ms */
-   msleep(1);
+   /* sleep at least 10 ms */
+   msleep(10);
}
if (val)
return -EIO;
@@ -203,9 +204,7 @@ static int hx711_reset(struct hx711_data *hx711_data)
 * after a dummy read we need to wait vor readiness
 * for not mixing gain pulses with the clock
 */
-   ret = hx711_wait_for_ready(hx711_data);
-   if (ret)
-   return ret;
+   val = hx711_wait_for_ready(hx711_data);
}
 
return val;
-- 
2.1.4


--