Re: [PATCH v9 04/11] arm64: kexec_file: allocate memory walking through memblock list

[AKASHI Takahiro]

James,

On Tue, May 01, 2018 at 06:46:09PM +0100, James Morse wrote:
> Hi Akashi,
> 
> On 25/04/18 07:26, AKASHI Takahiro wrote:
> > We need to prevent firmware-reserved memory regions, particularly EFI
> > memory map as well as ACPI tables, from being corrupted by loading
> > kernel/initrd (or other kexec buffers). We also want to support memory
> > allocation in top-down manner in addition to default bottom-up.
> > So let's have arm64 specific arch_kexec_walk_mem() which will search
> > for available memory ranges in usable memblock list,
> > i.e. !NOMAP & !reserved, 
> 
> > instead of system resource tree.
> 
> Didn't we try to fix the system-resource-tree in order to fix regular-kexec to
> be safe in the EFI-memory-map/ACPI-tables case?
> 
> It would be good to avoid having two ways of doing this, and I would like to
> avoid having extra arch code...

I know what you mean.
/proc/iomem or system resource is, in my opinion, not the best place to
describe memory usage of kernel but rather to describe *physical* hardware
layout. As we are still discussing about "reserved" memory, I don't want
to depend on it.
Along with memblock list, we will have more accurate control over memory
usage.

> 
> > diff --git a/arch/arm64/kernel/machine_kexec_file.c 
> > b/arch/arm64/kernel/machine_kexec_file.c
> > new file mode 100644
> > index ..f9ebf54ca247
> > --- /dev/null
> > +++ b/arch/arm64/kernel/machine_kexec_file.c
> > @@ -0,0 +1,57 @@
> > +// SPDX-License-Identifier: GPL-2.0
> > +/*
> > + * kexec_file for arm64
> > + *
> > + * Copyright (C) 2018 Linaro Limited
> > + * Author: AKASHI Takahiro 
> > + *
> 
> > + * Most code is derived from arm64 port of kexec-tools
> 
> How does kexec-tools walk memblock?

Will remove this comment from this patch.
Obviously, this comment is for the rest of the code which will be
added to succeeding patches (patch #5 and #7).


> 
> > + */
> > +
> > +#define pr_fmt(fmt) "kexec_file: " fmt
> > +
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +
> > +int arch_kexec_walk_mem(struct kexec_buf *kbuf,
> > +   int (*func)(struct resource *, void *))
> > +{
> > +   phys_addr_t start, end;
> > +   struct resource res;
> > +   u64 i;
> > +   int ret = 0;
> > +
> > +   if (kbuf->image->type == KEXEC_TYPE_CRASH)
> > +   return func(_res, kbuf);
> > +
> > +   if (kbuf->top_down)
> > +   for_each_mem_range_rev(i, , ,
> > +   NUMA_NO_NODE, MEMBLOCK_NONE,
> > +   , , NULL) {
> 
> for_each_free_mem_range_reverse() is a more readable version of this helper.

OK. I used to use my own limited list of reserved memory instead of
memblock.reserved here to exclude verbose ranges.


> > +   if (!memblock_is_map_memory(start))
> > +   continue;
> 
> Passing MEMBLOCK_NONE means this walk will never find MEMBLOCK_NOMAP memory.

Sure, I confirmed it.

> 
> > +   res.start = start;
> > +   res.end = end;
> > +   ret = func(, kbuf);
> > +   if (ret)
> > +   break;
> > +   }
> > +   else
> > +   for_each_mem_range(i, , ,
> > +   NUMA_NO_NODE, MEMBLOCK_NONE,
> > +   , , NULL) {
> 
> for_each_free_mem_range()?

OK.

> > +   if (!memblock_is_map_memory(start))
> > +   continue;
> > +
> > +   res.start = start;
> > +   res.end = end;
> > +   ret = func(, kbuf);
> > +   if (ret)
> > +   break;
> > +   }
> > +
> > +   return ret;
> > +}
> > 
> 
> With these changes, what we have is almost:
> arch/powerpc/kernel/machine_kexec_file_64.c::arch_kexec_walk_mem() !
> (the difference being powerpc doesn't yet support crash-kernels here)
> 
> If the argument is walking memblock gives a better answer than the stringy
> walk_system_ram_res() thing, is there any mileage in moving this code into
> kexec_file.c, and using it if !IS_ENABLED(CONFIG_ARCH_DISCARD_MEMBLOCK)?
> 
> This would save arm64/powerpc having near-identical implementations.
> 32bit arm keeps memblock if it has kexec, so it may be useful there too if
> kexec_file_load() support is added.

Thanks. I've forgot ppc.

-Takahiro AKASHI


> 
> Thanks,
> 
> James

Re: [PATCH v9 04/11] arm64: kexec_file: allocate memory walking through memblock list

[AKASHI Takahiro]

James,

On Tue, May 01, 2018 at 06:46:09PM +0100, James Morse wrote:
> Hi Akashi,
> 
> On 25/04/18 07:26, AKASHI Takahiro wrote:
> > We need to prevent firmware-reserved memory regions, particularly EFI
> > memory map as well as ACPI tables, from being corrupted by loading
> > kernel/initrd (or other kexec buffers). We also want to support memory
> > allocation in top-down manner in addition to default bottom-up.
> > So let's have arm64 specific arch_kexec_walk_mem() which will search
> > for available memory ranges in usable memblock list,
> > i.e. !NOMAP & !reserved, 
> 
> > instead of system resource tree.
> 
> Didn't we try to fix the system-resource-tree in order to fix regular-kexec to
> be safe in the EFI-memory-map/ACPI-tables case?
> 
> It would be good to avoid having two ways of doing this, and I would like to
> avoid having extra arch code...

I know what you mean.
/proc/iomem or system resource is, in my opinion, not the best place to
describe memory usage of kernel but rather to describe *physical* hardware
layout. As we are still discussing about "reserved" memory, I don't want
to depend on it.
Along with memblock list, we will have more accurate control over memory
usage.

> 
> > diff --git a/arch/arm64/kernel/machine_kexec_file.c 
> > b/arch/arm64/kernel/machine_kexec_file.c
> > new file mode 100644
> > index ..f9ebf54ca247
> > --- /dev/null
> > +++ b/arch/arm64/kernel/machine_kexec_file.c
> > @@ -0,0 +1,57 @@
> > +// SPDX-License-Identifier: GPL-2.0
> > +/*
> > + * kexec_file for arm64
> > + *
> > + * Copyright (C) 2018 Linaro Limited
> > + * Author: AKASHI Takahiro 
> > + *
> 
> > + * Most code is derived from arm64 port of kexec-tools
> 
> How does kexec-tools walk memblock?

Will remove this comment from this patch.
Obviously, this comment is for the rest of the code which will be
added to succeeding patches (patch #5 and #7).


> 
> > + */
> > +
> > +#define pr_fmt(fmt) "kexec_file: " fmt
> > +
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +
> > +int arch_kexec_walk_mem(struct kexec_buf *kbuf,
> > +   int (*func)(struct resource *, void *))
> > +{
> > +   phys_addr_t start, end;
> > +   struct resource res;
> > +   u64 i;
> > +   int ret = 0;
> > +
> > +   if (kbuf->image->type == KEXEC_TYPE_CRASH)
> > +   return func(_res, kbuf);
> > +
> > +   if (kbuf->top_down)
> > +   for_each_mem_range_rev(i, , ,
> > +   NUMA_NO_NODE, MEMBLOCK_NONE,
> > +   , , NULL) {
> 
> for_each_free_mem_range_reverse() is a more readable version of this helper.

OK. I used to use my own limited list of reserved memory instead of
memblock.reserved here to exclude verbose ranges.


> > +   if (!memblock_is_map_memory(start))
> > +   continue;
> 
> Passing MEMBLOCK_NONE means this walk will never find MEMBLOCK_NOMAP memory.

Sure, I confirmed it.

> 
> > +   res.start = start;
> > +   res.end = end;
> > +   ret = func(, kbuf);
> > +   if (ret)
> > +   break;
> > +   }
> > +   else
> > +   for_each_mem_range(i, , ,
> > +   NUMA_NO_NODE, MEMBLOCK_NONE,
> > +   , , NULL) {
> 
> for_each_free_mem_range()?

OK.

> > +   if (!memblock_is_map_memory(start))
> > +   continue;
> > +
> > +   res.start = start;
> > +   res.end = end;
> > +   ret = func(, kbuf);
> > +   if (ret)
> > +   break;
> > +   }
> > +
> > +   return ret;
> > +}
> > 
> 
> With these changes, what we have is almost:
> arch/powerpc/kernel/machine_kexec_file_64.c::arch_kexec_walk_mem() !
> (the difference being powerpc doesn't yet support crash-kernels here)
> 
> If the argument is walking memblock gives a better answer than the stringy
> walk_system_ram_res() thing, is there any mileage in moving this code into
> kexec_file.c, and using it if !IS_ENABLED(CONFIG_ARCH_DISCARD_MEMBLOCK)?
> 
> This would save arm64/powerpc having near-identical implementations.
> 32bit arm keeps memblock if it has kexec, so it may be useful there too if
> kexec_file_load() support is added.

Thanks. I've forgot ppc.

-Takahiro AKASHI


> 
> Thanks,
> 
> James

Re: [PATCH V2 1/5] backlight: qcom-wled: Rename pm8941-wled.c to qcom-wled.c

[kgunda]

Hi Jingoo Han,
Thanks for the response.

Thanks,
Kiran
On 2018-05-04 21:25, Jingoo Han wrote:

On Thursday, May 3, 2018 6:12 AM, Kiran Gunda wrote:

If you really want someone to review your patch, please add more 
detailed

explanations.

1. Please add 0th patch.
I have already added the 0th patch (cover letter). Following is the 
subject for the same.

forwarding the same to you.
[PATCH V2 0/5] backlight: qcom-wled: Support for QCOM wled driver


2. Please add what the difference is between V1 and V2 patches.

Already added the difference between V1 and V2 in the cover letter (0th 
patch).
Please let me know if you are looking for any other info. Following is 
the difference

added between v1 and v2.



changes from v1:
Fixed the commit message for
backlight: qcom-wled: Rename pm8941-wled.c to qcom-wled.c

If you cannot understand what I am saying, just ask another person who 
have

an experience to send patches to Linux mailing-list.

Best regards,
Jingoo Han



pm8941-wled.c driver is supporting the WLED peripheral
on pm8941. Rename it to qcom-wled.c so that it can support
WLED on multiple PMICs.

Signed-off-by: Kiran Gunda 
---
 .../bindings/leds/backlight/{pm8941-wled.txt => qcom-wled.txt}| 2 
+-

 drivers/video/backlight/Kconfig   | 8


 drivers/video/backlight/Makefile  | 2 
+-

 drivers/video/backlight/{pm8941-wled.c => qcom-wled.c}| 0
 4 files changed, 6 insertions(+), 6 deletions(-)
 rename 
Documentation/devicetree/bindings/leds/backlight/{pm8941-wled.txt

=> qcom-wled.txt} (95%)
 rename drivers/video/backlight/{pm8941-wled.c => qcom-wled.c} (100%)

diff --git a/Documentation/devicetree/bindings/leds/backlight/pm8941-
wled.txt 
b/Documentation/devicetree/bindings/leds/backlight/qcom-wled.txt

similarity index 95%
rename from Documentation/devicetree/bindings/leds/backlight/pm8941-
wled.txt
rename to 
Documentation/devicetree/bindings/leds/backlight/qcom-wled.txt

index e5b294d..fb39e32 100644
--- a/Documentation/devicetree/bindings/leds/backlight/pm8941-wled.txt
+++ b/Documentation/devicetree/bindings/leds/backlight/qcom-wled.txt
@@ -1,4 +1,4 @@
-Binding for Qualcomm PM8941 WLED driver
+Binding for Qualcomm Technologies, Inc. WLED driver

 Required properties:
 - compatible: should be "qcom,pm8941-wled"
diff --git a/drivers/video/backlight/Kconfig
b/drivers/video/backlight/Kconfig
index 4e1d2ad..8c095e3 100644
--- a/drivers/video/backlight/Kconfig
+++ b/drivers/video/backlight/Kconfig
@@ -299,12 +299,12 @@ config BACKLIGHT_TOSA
  If you have an Sharp SL-6000 Zaurus say Y to enable a driver
  for its backlight

-config BACKLIGHT_PM8941_WLED
-   tristate "Qualcomm PM8941 WLED Driver"
+config BACKLIGHT_QCOM_WLED
+   tristate "Qualcomm PMIC WLED Driver"
select REGMAP
help
- If you have the Qualcomm PM8941, say Y to enable a driver for the
- WLED block.
+ If you have the Qualcomm PMIC, say Y to enable a driver for the
+ WLED block. Currently it supports PM8941 and PMI8998.

 config BACKLIGHT_SAHARA
tristate "Tabletkiosk Sahara Touch-iT Backlight Driver"
diff --git a/drivers/video/backlight/Makefile
b/drivers/video/backlight/Makefile
index 5e28f01..6fd76ef 100644
--- a/drivers/video/backlight/Makefile
+++ b/drivers/video/backlight/Makefile
@@ -49,8 +49,8 @@ obj-$(CONFIG_BACKLIGHT_OMAP1) +=

omap1_bl.o

 obj-$(CONFIG_BACKLIGHT_OT200)  += ot200_bl.o
 obj-$(CONFIG_BACKLIGHT_PANDORA)+= pandora_bl.o
 obj-$(CONFIG_BACKLIGHT_PCF50633)   += pcf50633-backlight.o
-obj-$(CONFIG_BACKLIGHT_PM8941_WLED)+= pm8941-wled.o
 obj-$(CONFIG_BACKLIGHT_PWM)+= pwm_bl.o
+obj-$(CONFIG_BACKLIGHT_QCOM_WLED)  += qcom-wled.o
 obj-$(CONFIG_BACKLIGHT_SAHARA) += kb3886_bl.o
 obj-$(CONFIG_BACKLIGHT_SKY81452)   += sky81452-backlight.o
 obj-$(CONFIG_BACKLIGHT_TOSA)   += tosa_bl.o
diff --git a/drivers/video/backlight/pm8941-wled.c
b/drivers/video/backlight/qcom-wled.c
similarity index 100%
rename from drivers/video/backlight/pm8941-wled.c
rename to drivers/video/backlight/qcom-wled.c
--
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora 
Forum,

 a Linux Foundation Collaborative Project

Re: [PATCH V2 1/5] backlight: qcom-wled: Rename pm8941-wled.c to qcom-wled.c

[kgunda]

Hi Jingoo Han,
Thanks for the response.

Thanks,
Kiran
On 2018-05-04 21:25, Jingoo Han wrote:

On Thursday, May 3, 2018 6:12 AM, Kiran Gunda wrote:

If you really want someone to review your patch, please add more 
detailed

explanations.

1. Please add 0th patch.
I have already added the 0th patch (cover letter). Following is the 
subject for the same.

forwarding the same to you.
[PATCH V2 0/5] backlight: qcom-wled: Support for QCOM wled driver


2. Please add what the difference is between V1 and V2 patches.

Already added the difference between V1 and V2 in the cover letter (0th 
patch).
Please let me know if you are looking for any other info. Following is 
the difference

added between v1 and v2.



changes from v1:
Fixed the commit message for
backlight: qcom-wled: Rename pm8941-wled.c to qcom-wled.c

If you cannot understand what I am saying, just ask another person who 
have

an experience to send patches to Linux mailing-list.

Best regards,
Jingoo Han



pm8941-wled.c driver is supporting the WLED peripheral
on pm8941. Rename it to qcom-wled.c so that it can support
WLED on multiple PMICs.

Signed-off-by: Kiran Gunda 
---
 .../bindings/leds/backlight/{pm8941-wled.txt => qcom-wled.txt}| 2 
+-

 drivers/video/backlight/Kconfig   | 8


 drivers/video/backlight/Makefile  | 2 
+-

 drivers/video/backlight/{pm8941-wled.c => qcom-wled.c}| 0
 4 files changed, 6 insertions(+), 6 deletions(-)
 rename 
Documentation/devicetree/bindings/leds/backlight/{pm8941-wled.txt

=> qcom-wled.txt} (95%)
 rename drivers/video/backlight/{pm8941-wled.c => qcom-wled.c} (100%)

diff --git a/Documentation/devicetree/bindings/leds/backlight/pm8941-
wled.txt 
b/Documentation/devicetree/bindings/leds/backlight/qcom-wled.txt

similarity index 95%
rename from Documentation/devicetree/bindings/leds/backlight/pm8941-
wled.txt
rename to 
Documentation/devicetree/bindings/leds/backlight/qcom-wled.txt

index e5b294d..fb39e32 100644
--- a/Documentation/devicetree/bindings/leds/backlight/pm8941-wled.txt
+++ b/Documentation/devicetree/bindings/leds/backlight/qcom-wled.txt
@@ -1,4 +1,4 @@
-Binding for Qualcomm PM8941 WLED driver
+Binding for Qualcomm Technologies, Inc. WLED driver

 Required properties:
 - compatible: should be "qcom,pm8941-wled"
diff --git a/drivers/video/backlight/Kconfig
b/drivers/video/backlight/Kconfig
index 4e1d2ad..8c095e3 100644
--- a/drivers/video/backlight/Kconfig
+++ b/drivers/video/backlight/Kconfig
@@ -299,12 +299,12 @@ config BACKLIGHT_TOSA
  If you have an Sharp SL-6000 Zaurus say Y to enable a driver
  for its backlight

-config BACKLIGHT_PM8941_WLED
-   tristate "Qualcomm PM8941 WLED Driver"
+config BACKLIGHT_QCOM_WLED
+   tristate "Qualcomm PMIC WLED Driver"
select REGMAP
help
- If you have the Qualcomm PM8941, say Y to enable a driver for the
- WLED block.
+ If you have the Qualcomm PMIC, say Y to enable a driver for the
+ WLED block. Currently it supports PM8941 and PMI8998.

 config BACKLIGHT_SAHARA
tristate "Tabletkiosk Sahara Touch-iT Backlight Driver"
diff --git a/drivers/video/backlight/Makefile
b/drivers/video/backlight/Makefile
index 5e28f01..6fd76ef 100644
--- a/drivers/video/backlight/Makefile
+++ b/drivers/video/backlight/Makefile
@@ -49,8 +49,8 @@ obj-$(CONFIG_BACKLIGHT_OMAP1) +=

omap1_bl.o

 obj-$(CONFIG_BACKLIGHT_OT200)  += ot200_bl.o
 obj-$(CONFIG_BACKLIGHT_PANDORA)+= pandora_bl.o
 obj-$(CONFIG_BACKLIGHT_PCF50633)   += pcf50633-backlight.o
-obj-$(CONFIG_BACKLIGHT_PM8941_WLED)+= pm8941-wled.o
 obj-$(CONFIG_BACKLIGHT_PWM)+= pwm_bl.o
+obj-$(CONFIG_BACKLIGHT_QCOM_WLED)  += qcom-wled.o
 obj-$(CONFIG_BACKLIGHT_SAHARA) += kb3886_bl.o
 obj-$(CONFIG_BACKLIGHT_SKY81452)   += sky81452-backlight.o
 obj-$(CONFIG_BACKLIGHT_TOSA)   += tosa_bl.o
diff --git a/drivers/video/backlight/pm8941-wled.c
b/drivers/video/backlight/qcom-wled.c
similarity index 100%
rename from drivers/video/backlight/pm8941-wled.c
rename to drivers/video/backlight/qcom-wled.c
--
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora 
Forum,

 a Linux Foundation Collaborative Project

Re: [PATCH BUGFIX] block, bfq: postpone rq preparation to insert or merge

[Mike Galbraith]

On Sun, 2018-05-06 at 09:42 +0200, Paolo Valente wrote:
> 
> diff --git a/block/bfq-mq-iosched.c b/block/bfq-mq-iosched.c
> index 118f319af7c0..6662efe29b69 100644
> --- a/block/bfq-mq-iosched.c
> +++ b/block/bfq-mq-iosched.c
> @@ -525,8 +525,13 @@ static void bfq_limit_depth(unsigned int op, struct 
> blk_mq_alloc_data *data)
> if (unlikely(bfqd->sb_shift != bt->sb.shift))
> bfq_update_depths(bfqd, bt);
>  
> +#if 0
> data->shallow_depth =
> bfqd->word_depths[!!bfqd->wr_busy_queues][op_is_sync(op)];
^

Q: why doesn't the top of this function look like so?

---
 block/bfq-iosched.c |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

--- a/block/bfq-iosched.c
+++ b/block/bfq-iosched.c
@@ -539,7 +539,7 @@ static void bfq_limit_depth(unsigned int
struct bfq_data *bfqd = data->q->elevator->elevator_data;
struct sbitmap_queue *bt;
 
-   if (op_is_sync(op) && !op_is_write(op))
+   if (!op_is_write(op))
return;
 
if (data->flags & BLK_MQ_REQ_RESERVED) {

It looks a bit odd that these elements exist...

+   /*
+    * no more than 75% of tags for sync writes (25% extra tags
+    * w.r.t. async I/O, to prevent async I/O from starving sync
+    * writes)
+    */
+   bfqd->word_depths[0][1] = max(((1U>2, 1U);

+   /* no more than ~37% of tags for sync writes (~20% extra tags) */
+   bfqd->word_depths[1][1] = max(((1U>4, 1U);

...yet we index via and log a guaranteed zero.

-Mike

Re: [PATCH BUGFIX] block, bfq: postpone rq preparation to insert or merge

[Mike Galbraith]

On Sun, 2018-05-06 at 09:42 +0200, Paolo Valente wrote:
> 
> diff --git a/block/bfq-mq-iosched.c b/block/bfq-mq-iosched.c
> index 118f319af7c0..6662efe29b69 100644
> --- a/block/bfq-mq-iosched.c
> +++ b/block/bfq-mq-iosched.c
> @@ -525,8 +525,13 @@ static void bfq_limit_depth(unsigned int op, struct 
> blk_mq_alloc_data *data)
> if (unlikely(bfqd->sb_shift != bt->sb.shift))
> bfq_update_depths(bfqd, bt);
>  
> +#if 0
> data->shallow_depth =
> bfqd->word_depths[!!bfqd->wr_busy_queues][op_is_sync(op)];
^

Q: why doesn't the top of this function look like so?

---
 block/bfq-iosched.c |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

--- a/block/bfq-iosched.c
+++ b/block/bfq-iosched.c
@@ -539,7 +539,7 @@ static void bfq_limit_depth(unsigned int
struct bfq_data *bfqd = data->q->elevator->elevator_data;
struct sbitmap_queue *bt;
 
-   if (op_is_sync(op) && !op_is_write(op))
+   if (!op_is_write(op))
return;
 
if (data->flags & BLK_MQ_REQ_RESERVED) {

It looks a bit odd that these elements exist...

+   /*
+    * no more than 75% of tags for sync writes (25% extra tags
+    * w.r.t. async I/O, to prevent async I/O from starving sync
+    * writes)
+    */
+   bfqd->word_depths[0][1] = max(((1U>2, 1U);

+   /* no more than ~37% of tags for sync writes (~20% extra tags) */
+   bfqd->word_depths[1][1] = max(((1U>4, 1U);

...yet we index via and log a guaranteed zero.

-Mike

Re: [PATCH 3/3] staging: wilc1000: Remove unnecessary array index check

[Ajay Singh]

On Sun, 6 May 2018 00:33:33 -0700
Nathan Chancellor  wrote:

> This statment triggers GCC's -Wtype-limit since key_index is an
> unsigned integer so it cannot be less than zero.
> 
> Signed-off-by: Nathan Chancellor 

Reviewed-by: Ajay Singh 

> ---
>  drivers/staging/wilc1000/wilc_wfi_cfgoperations.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/staging/wilc1000/wilc_wfi_cfgoperations.c
> b/drivers/staging/wilc1000/wilc_wfi_cfgoperations.c index
> b499fb987395..e0015ca6c21a 100644 ---
> a/drivers/staging/wilc1000/wilc_wfi_cfgoperations.c +++
> b/drivers/staging/wilc1000/wilc_wfi_cfgoperations.c @@ -1054,7
> +1054,7 @@ static int del_key(struct wiphy *wiphy, struct net_device
> *netdev, } }
>  
> - if (key_index >= 0 && key_index <= 3 &&
> priv->wep_key_len[key_index]) {
> + if (key_index <= 3 && priv->wep_key_len[key_index]) {
>   memset(priv->wep_key[key_index], 0,
>  priv->wep_key_len[key_index]);
>   priv->wep_key_len[key_index] = 0;

Re: [PATCH 3/3] staging: wilc1000: Remove unnecessary array index check

[Ajay Singh]

On Sun, 6 May 2018 00:33:33 -0700
Nathan Chancellor  wrote:

> This statment triggers GCC's -Wtype-limit since key_index is an
> unsigned integer so it cannot be less than zero.
> 
> Signed-off-by: Nathan Chancellor 

Reviewed-by: Ajay Singh 

> ---
>  drivers/staging/wilc1000/wilc_wfi_cfgoperations.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/staging/wilc1000/wilc_wfi_cfgoperations.c
> b/drivers/staging/wilc1000/wilc_wfi_cfgoperations.c index
> b499fb987395..e0015ca6c21a 100644 ---
> a/drivers/staging/wilc1000/wilc_wfi_cfgoperations.c +++
> b/drivers/staging/wilc1000/wilc_wfi_cfgoperations.c @@ -1054,7
> +1054,7 @@ static int del_key(struct wiphy *wiphy, struct net_device
> *netdev, } }
>  
> - if (key_index >= 0 && key_index <= 3 &&
> priv->wep_key_len[key_index]) {
> + if (key_index <= 3 && priv->wep_key_len[key_index]) {
>   memset(priv->wep_key[key_index], 0,
>  priv->wep_key_len[key_index]);
>   priv->wep_key_len[key_index] = 0;

Re: [PATCH 2/3] staging: wilc1000: Remove useless function

[Ajay Singh]

On Sun, 6 May 2018 00:33:32 -0700
Nathan Chancellor  wrote:

> GCC warns that 'wid' is unused in wilc_remove_key and it's correct;
> the variable is only local. Get rid of the function (since it just
> returns zero) and shuffle the remaining code into one if statement.
> 
> Signed-off-by: Nathan Chancellor 

Reviewed-by: Ajay Singh 

> ---
>  drivers/staging/wilc1000/host_interface.c | 12 
>  drivers/staging/wilc1000/host_interface.h |  1 -
>  drivers/staging/wilc1000/wilc_wfi_cfgoperations.c | 14 +-
>  3 files changed, 5 insertions(+), 22 deletions(-)
> 
> diff --git a/drivers/staging/wilc1000/host_interface.c
> b/drivers/staging/wilc1000/host_interface.c index
> 3fd4c8e62da6..b5f3829e9903 100644 ---
> a/drivers/staging/wilc1000/host_interface.c +++
> b/drivers/staging/wilc1000/host_interface.c @@ -2606,18 +2606,6 @@
> static void timer_connect_cb(struct timer_list *t)
> wilc_enqueue_cmd(); }
>  
> -s32 wilc_remove_key(struct host_if_drv *hif_drv, const u8 *sta_addr)
> -{
> - struct wid wid;
> -
> - wid.id = (u16)WID_REMOVE_KEY;
> - wid.type = WID_STR;
> - wid.val = (s8 *)sta_addr;
> - wid.size = 6;
> -
> - return 0;
> -}
> -
>  int wilc_remove_wep_key(struct wilc_vif *vif, u8 index)
>  {
>   int result = 0;
> diff --git a/drivers/staging/wilc1000/host_interface.h
> b/drivers/staging/wilc1000/host_interface.h index
> 7a26f341e0ba..08b3ba7df8b4 100644 ---
> a/drivers/staging/wilc1000/host_interface.h +++
> b/drivers/staging/wilc1000/host_interface.h @@ -303,7 +303,6 @@
> struct add_sta_param { };
>  
>  struct wilc_vif;
> -s32 wilc_remove_key(struct host_if_drv *hif_drv, const u8 *sta_addr);
>  int wilc_remove_wep_key(struct wilc_vif *vif, u8 index);
>  int wilc_set_wep_default_keyid(struct wilc_vif *vif, u8 index);
>  int wilc_add_wep_key_bss_sta(struct wilc_vif *vif, const u8 *key, u8
> len, diff --git a/drivers/staging/wilc1000/wilc_wfi_cfgoperations.c
> b/drivers/staging/wilc1000/wilc_wfi_cfgoperations.c index
> 76b4afaef423..b499fb987395 100644 ---
> a/drivers/staging/wilc1000/wilc_wfi_cfgoperations.c +++
> b/drivers/staging/wilc1000/wilc_wfi_cfgoperations.c @@ -1054,15
> +1054,11 @@ static int del_key(struct wiphy *wiphy, struct net_device
> *netdev, } }
>  
> - if (key_index >= 0 && key_index <= 3) {
> - if (priv->wep_key_len[key_index]) {
> - memset(priv->wep_key[key_index], 0,
> -priv->wep_key_len[key_index]);
> - priv->wep_key_len[key_index] = 0;
> - wilc_remove_wep_key(vif, key_index);
> - }
> - } else {
> - wilc_remove_key(priv->hif_drv, mac_addr);
> + if (key_index >= 0 && key_index <= 3 &&
> priv->wep_key_len[key_index]) {
> + memset(priv->wep_key[key_index], 0,
> +priv->wep_key_len[key_index]);
> + priv->wep_key_len[key_index] = 0;
> + wilc_remove_wep_key(vif, key_index);
>   }
>  
>   return 0;

Re: [PATCH 2/3] staging: wilc1000: Remove useless function

[Ajay Singh]

On Sun, 6 May 2018 00:33:32 -0700
Nathan Chancellor  wrote:

> GCC warns that 'wid' is unused in wilc_remove_key and it's correct;
> the variable is only local. Get rid of the function (since it just
> returns zero) and shuffle the remaining code into one if statement.
> 
> Signed-off-by: Nathan Chancellor 

Reviewed-by: Ajay Singh 

> ---
>  drivers/staging/wilc1000/host_interface.c | 12 
>  drivers/staging/wilc1000/host_interface.h |  1 -
>  drivers/staging/wilc1000/wilc_wfi_cfgoperations.c | 14 +-
>  3 files changed, 5 insertions(+), 22 deletions(-)
> 
> diff --git a/drivers/staging/wilc1000/host_interface.c
> b/drivers/staging/wilc1000/host_interface.c index
> 3fd4c8e62da6..b5f3829e9903 100644 ---
> a/drivers/staging/wilc1000/host_interface.c +++
> b/drivers/staging/wilc1000/host_interface.c @@ -2606,18 +2606,6 @@
> static void timer_connect_cb(struct timer_list *t)
> wilc_enqueue_cmd(); }
>  
> -s32 wilc_remove_key(struct host_if_drv *hif_drv, const u8 *sta_addr)
> -{
> - struct wid wid;
> -
> - wid.id = (u16)WID_REMOVE_KEY;
> - wid.type = WID_STR;
> - wid.val = (s8 *)sta_addr;
> - wid.size = 6;
> -
> - return 0;
> -}
> -
>  int wilc_remove_wep_key(struct wilc_vif *vif, u8 index)
>  {
>   int result = 0;
> diff --git a/drivers/staging/wilc1000/host_interface.h
> b/drivers/staging/wilc1000/host_interface.h index
> 7a26f341e0ba..08b3ba7df8b4 100644 ---
> a/drivers/staging/wilc1000/host_interface.h +++
> b/drivers/staging/wilc1000/host_interface.h @@ -303,7 +303,6 @@
> struct add_sta_param { };
>  
>  struct wilc_vif;
> -s32 wilc_remove_key(struct host_if_drv *hif_drv, const u8 *sta_addr);
>  int wilc_remove_wep_key(struct wilc_vif *vif, u8 index);
>  int wilc_set_wep_default_keyid(struct wilc_vif *vif, u8 index);
>  int wilc_add_wep_key_bss_sta(struct wilc_vif *vif, const u8 *key, u8
> len, diff --git a/drivers/staging/wilc1000/wilc_wfi_cfgoperations.c
> b/drivers/staging/wilc1000/wilc_wfi_cfgoperations.c index
> 76b4afaef423..b499fb987395 100644 ---
> a/drivers/staging/wilc1000/wilc_wfi_cfgoperations.c +++
> b/drivers/staging/wilc1000/wilc_wfi_cfgoperations.c @@ -1054,15
> +1054,11 @@ static int del_key(struct wiphy *wiphy, struct net_device
> *netdev, } }
>  
> - if (key_index >= 0 && key_index <= 3) {
> - if (priv->wep_key_len[key_index]) {
> - memset(priv->wep_key[key_index], 0,
> -priv->wep_key_len[key_index]);
> - priv->wep_key_len[key_index] = 0;
> - wilc_remove_wep_key(vif, key_index);
> - }
> - } else {
> - wilc_remove_key(priv->hif_drv, mac_addr);
> + if (key_index >= 0 && key_index <= 3 &&
> priv->wep_key_len[key_index]) {
> + memset(priv->wep_key[key_index], 0,
> +priv->wep_key_len[key_index]);
> + priv->wep_key_len[key_index] = 0;
> + wilc_remove_wep_key(vif, key_index);
>   }
>  
>   return 0;

Re: [PATCH 1/3] staging: wilc1000: Remove unused variables

[Ajay Singh]

Thank you for the patch series.

On Sun, 6 May 2018 00:33:31 -0700
Nathan Chancellor  wrote:

> GCC warns these variables are all set but never used so remove them.
> 
> Signed-off-by: Nathan Chancellor 

Reviewed-by: Ajay Singh 

> ---
>  drivers/staging/wilc1000/host_interface.c | 12 
>  drivers/staging/wilc1000/wilc_wfi_cfgoperations.c |  6 --
>  2 files changed, 18 deletions(-)
> 
> diff --git a/drivers/staging/wilc1000/host_interface.c
> b/drivers/staging/wilc1000/host_interface.c index
> 28edd904b33a..3fd4c8e62da6 100644 ---
> a/drivers/staging/wilc1000/host_interface.c +++
> b/drivers/staging/wilc1000/host_interface.c @@ -1432,13 +1432,7 @@
> static s32 handle_rcvd_gnrl_async_info(struct wilc_vif *vif, {
>   s32 result = 0;
>   u8 msg_type = 0;
> - u8 msg_id = 0;
> - u16 msg_len = 0;
> - u16 wid_id = (u16)WID_NIL;
> - u8 wid_len  = 0;
>   u8 mac_status;
> - u8 mac_status_reason_code;
> - u8 mac_status_additional_info;
>   struct host_if_drv *hif_drv = vif->hif_drv;
>  
>   if (!rcvd_info->buffer) {
> @@ -1472,13 +1466,7 @@ static s32 handle_rcvd_gnrl_async_info(struct
> wilc_vif *vif, return -EFAULT;
>   }
>  
> - msg_id = rcvd_info->buffer[1];
> - msg_len = MAKE_WORD16(rcvd_info->buffer[2],
> rcvd_info->buffer[3]);
> - wid_id = MAKE_WORD16(rcvd_info->buffer[4],
> rcvd_info->buffer[5]);
> - wid_len = rcvd_info->buffer[6];
>   mac_status  = rcvd_info->buffer[7];
> - mac_status_reason_code = rcvd_info->buffer[8];
> - mac_status_additional_info = rcvd_info->buffer[9];
>   if (hif_drv->hif_state == HOST_IF_WAITING_CONN_RESP)
> { host_int_parse_assoc_resp_info(vif, mac_status);
>   } else if ((mac_status == MAC_STATUS_DISCONNECTED) &&
> diff --git a/drivers/staging/wilc1000/wilc_wfi_cfgoperations.c
> b/drivers/staging/wilc1000/wilc_wfi_cfgoperations.c index
> 8be3c4c57579..76b4afaef423 100644 ---
> a/drivers/staging/wilc1000/wilc_wfi_cfgoperations.c +++
> b/drivers/staging/wilc1000/wilc_wfi_cfgoperations.c @@ -917,12
> +917,10 @@ static int add_key(struct wiphy *wiphy, struct net_device
> *netdev, u8 key_index, const u8 *tx_mic = NULL; u8 mode = NO_ENCRYPT;
>   u8 op_mode;
> - struct wilc *wl;
>   struct wilc_vif *vif;
>  
>   priv = wiphy_priv(wiphy);
>   vif = netdev_priv(netdev);
> - wl = vif->wilc;
>  
>   switch (params->cipher) {
>   case WLAN_CIPHER_SUITE_WEP40:
> @@ -1885,12 +1883,10 @@ static int start_ap(struct wiphy *wiphy,
> struct net_device *dev, struct cfg80211_ap_settings *settings)
>  {
>   struct cfg80211_beacon_data *beacon = >beacon;
> - struct wilc_priv *priv;
>   s32 ret = 0;
>   struct wilc *wl;
>   struct wilc_vif *vif;
>  
> - priv = wiphy_priv(wiphy);
>   vif = netdev_priv(dev);
>   wl = vif->wilc;
>  
> @@ -2016,14 +2012,12 @@ static int change_station(struct wiphy
> *wiphy, struct net_device *dev, const u8 *mac, struct
> station_parameters *params) {
>   s32 ret = 0;
> - struct wilc_priv *priv;
>   struct add_sta_param sta_params = { {0} };
>   struct wilc_vif *vif;
>  
>   if (!wiphy)
>   return -EFAULT;
>  
> - priv = wiphy_priv(wiphy);
>   vif = netdev_priv(dev);
>  
>   if (vif->iftype == AP_MODE || vif->iftype == GO_MODE) {

Re: [PATCH 1/3] staging: wilc1000: Remove unused variables

[Ajay Singh]

Thank you for the patch series.

On Sun, 6 May 2018 00:33:31 -0700
Nathan Chancellor  wrote:

> GCC warns these variables are all set but never used so remove them.
> 
> Signed-off-by: Nathan Chancellor 

Reviewed-by: Ajay Singh 

> ---
>  drivers/staging/wilc1000/host_interface.c | 12 
>  drivers/staging/wilc1000/wilc_wfi_cfgoperations.c |  6 --
>  2 files changed, 18 deletions(-)
> 
> diff --git a/drivers/staging/wilc1000/host_interface.c
> b/drivers/staging/wilc1000/host_interface.c index
> 28edd904b33a..3fd4c8e62da6 100644 ---
> a/drivers/staging/wilc1000/host_interface.c +++
> b/drivers/staging/wilc1000/host_interface.c @@ -1432,13 +1432,7 @@
> static s32 handle_rcvd_gnrl_async_info(struct wilc_vif *vif, {
>   s32 result = 0;
>   u8 msg_type = 0;
> - u8 msg_id = 0;
> - u16 msg_len = 0;
> - u16 wid_id = (u16)WID_NIL;
> - u8 wid_len  = 0;
>   u8 mac_status;
> - u8 mac_status_reason_code;
> - u8 mac_status_additional_info;
>   struct host_if_drv *hif_drv = vif->hif_drv;
>  
>   if (!rcvd_info->buffer) {
> @@ -1472,13 +1466,7 @@ static s32 handle_rcvd_gnrl_async_info(struct
> wilc_vif *vif, return -EFAULT;
>   }
>  
> - msg_id = rcvd_info->buffer[1];
> - msg_len = MAKE_WORD16(rcvd_info->buffer[2],
> rcvd_info->buffer[3]);
> - wid_id = MAKE_WORD16(rcvd_info->buffer[4],
> rcvd_info->buffer[5]);
> - wid_len = rcvd_info->buffer[6];
>   mac_status  = rcvd_info->buffer[7];
> - mac_status_reason_code = rcvd_info->buffer[8];
> - mac_status_additional_info = rcvd_info->buffer[9];
>   if (hif_drv->hif_state == HOST_IF_WAITING_CONN_RESP)
> { host_int_parse_assoc_resp_info(vif, mac_status);
>   } else if ((mac_status == MAC_STATUS_DISCONNECTED) &&
> diff --git a/drivers/staging/wilc1000/wilc_wfi_cfgoperations.c
> b/drivers/staging/wilc1000/wilc_wfi_cfgoperations.c index
> 8be3c4c57579..76b4afaef423 100644 ---
> a/drivers/staging/wilc1000/wilc_wfi_cfgoperations.c +++
> b/drivers/staging/wilc1000/wilc_wfi_cfgoperations.c @@ -917,12
> +917,10 @@ static int add_key(struct wiphy *wiphy, struct net_device
> *netdev, u8 key_index, const u8 *tx_mic = NULL; u8 mode = NO_ENCRYPT;
>   u8 op_mode;
> - struct wilc *wl;
>   struct wilc_vif *vif;
>  
>   priv = wiphy_priv(wiphy);
>   vif = netdev_priv(netdev);
> - wl = vif->wilc;
>  
>   switch (params->cipher) {
>   case WLAN_CIPHER_SUITE_WEP40:
> @@ -1885,12 +1883,10 @@ static int start_ap(struct wiphy *wiphy,
> struct net_device *dev, struct cfg80211_ap_settings *settings)
>  {
>   struct cfg80211_beacon_data *beacon = >beacon;
> - struct wilc_priv *priv;
>   s32 ret = 0;
>   struct wilc *wl;
>   struct wilc_vif *vif;
>  
> - priv = wiphy_priv(wiphy);
>   vif = netdev_priv(dev);
>   wl = vif->wilc;
>  
> @@ -2016,14 +2012,12 @@ static int change_station(struct wiphy
> *wiphy, struct net_device *dev, const u8 *mac, struct
> station_parameters *params) {
>   s32 ret = 0;
> - struct wilc_priv *priv;
>   struct add_sta_param sta_params = { {0} };
>   struct wilc_vif *vif;
>  
>   if (!wiphy)
>   return -EFAULT;
>  
> - priv = wiphy_priv(wiphy);
>   vif = netdev_priv(dev);
>  
>   if (vif->iftype == AP_MODE || vif->iftype == GO_MODE) {

Re: [PATCH] clocksource/drivers/sprd: Fix Kconfig dependency

[Daniel Lezcano]

On Thu, May 03, 2018 at 08:27:32PM +0800, Chunyan Zhang wrote:
> SPRD arch doesn't select SPRD_TIMER, so this config would not
> appear even if ARCH_SPRD is set and COMPILE_TEST is not.
> 
> Fix the Kconfig selection rule by letting the SPRD arch to select.

Instead of changing this Kconfig, please fix the arch's Kconfig by selecting
SPRD_TIMER.



-- 

  Linaro.org │ Open source software for ARM SoCs

Follow Linaro:   Facebook |
 Twitter |
 Blog

Re: [PATCH] clocksource/drivers/sprd: Fix Kconfig dependency

[Daniel Lezcano]

On Thu, May 03, 2018 at 08:27:32PM +0800, Chunyan Zhang wrote:
> SPRD arch doesn't select SPRD_TIMER, so this config would not
> appear even if ARCH_SPRD is set and COMPILE_TEST is not.
> 
> Fix the Kconfig selection rule by letting the SPRD arch to select.

Instead of changing this Kconfig, please fix the arch's Kconfig by selecting
SPRD_TIMER.



-- 

  Linaro.org │ Open source software for ARM SoCs

Follow Linaro:   Facebook |
 Twitter |
 Blog

linux-next: Tree for May 7

[Stephen Rothwell]

Hi all,

Changes since 20180504:

The net-next tree gained a conflict against the net tree.

The tip tree gained conflicts against the bpf-next tree.

Non-merge commits (relative to Linus' tree): 4139
 3963 files changed, 164135 insertions(+), 75455 deletions(-)



I have created today's linux-next tree at
git://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git
(patches at http://www.kernel.org/pub/linux/kernel/next/ ).  If you
are tracking the linux-next tree using git, you should not use "git pull"
to do so as that will try to merge the new linux-next release with the
old one.  You should use "git fetch" and checkout or reset to the new
master.

You can see which trees have been included by looking in the Next/Trees
file in the source.  There are also quilt-import.log and merge.log
files in the Next directory.  Between each merge, the tree was built
with a ppc64_defconfig for powerpc, an allmodconfig for x86_64, a
multi_v7_defconfig for arm and a native build of tools/perf. After
the final fixups (if any), I do an x86_64 modules_install followed by
builds for x86_64 allnoconfig, powerpc allnoconfig (32 and 64 bit),
ppc44x_defconfig, allyesconfig and pseries_le_defconfig and i386, sparc
and sparc64 defconfig. And finally, a simple boot test of the powerpc
pseries_le_defconfig kernel in qemu (with and without kvm enabled).

Below is a summary of the state of the merge.

I am currently merging 257 trees (counting Linus' and 44 trees of bug
fix patches pending for the current merge release).

Stats about the size of the tree over time can be seen at
http://neuling.org/linux-next-size.html .

Status of my local build tests will be at
http://kisskb.ellerman.id.au/linux-next .  If maintainers want to give
advice about cross compilers/configs that work, we are always open to add
more builds.

Thanks to Randy Dunlap for doing many randconfig builds.  And to Paul
Gortmaker for triage and bug fixes.

-- 
Cheers,
Stephen Rothwell

$ git checkout master
$ git reset --hard stable
Merging origin/master (701e39d05119 Merge tag 'for-linus' of 
git://git.kernel.org/pub/scm/virt/kvm/kvm)
Merging fixes/master (147a89bc71e7 Merge tag 'kconfig-v4.17' of 
git://git.kernel.org/pub/scm/linux/kernel/git/masahiroy/linux-kbuild)
Merging kbuild-current/fixes (0da7e4326114 genksyms: fix typo in 
parse.tab.{c,h} generation rules)
Merging arc-current/for-curr (661e50bc8532 Linux 4.16-rc4)
Merging arm-current/fixes (30cfae461581 ARM: replace unnecessary perl with sed 
and the shell $(( )) operator)
Merging arm64-fixes/for-next/fixes (3789c122d0a0 arm64: avoid instrumenting 
atomic_ll_sc.o)
Merging m68k-current/for-linus (ecd685580c8f m68k/mac: Remove bogus "FIXME" 
comment)
Merging powerpc-fixes/fixes (b2d7ecbe3556 powerpc/kvm/booke: Fix altivec 
related build break)
Merging sparc/master (fff75eb2a08c Merge tag 'errseq-v4.17' of 
git://git.kernel.org/pub/scm/linux/kernel/git/jlayton/linux)
Merging fscrypt-current/for-stable (ae64f9bd1d36 Linux 4.15-rc2)
Merging net/master (2ba5622fba85 Merge 
git://git.kernel.org/pub/scm/linux/kernel/git/bpf/bpf)
Merging bpf/master (d0f1a451e33d bpf: use array_index_nospec in find_prog_type)
Merging ipsec/master (b4331a681822 vti6: Change minimum MTU to IPV4_MIN_MTU, 
vti6 can carry IPv4 too)
Merging netfilter/master (2f99aa31cd7a netfilter: nf_tables: skip 
synchronize_rcu if transaction log is empty)
Merging ipvs/master (765cca91b895 netfilter: conntrack: include kmemleak.h for 
kmemleak_not_leak())
Merging wireless-drivers/master (a8d7aa17bbc9 dccp: fix tasklet usage)
Merging mac80211/master (2f0605a697f4 nl80211: Free connkeys on external 
authentication failure)
Merging rdma-fixes/for-rc (9aa169213d11 RDMA/cma: Do not query GID during QP 
state transition to RTR)
Merging sound-current/for-linus (f13876e2c33a ALSA: pcm: Check PCM state at 
xfern compat ioctl)
Merging pci-current/for-linus (0cf22d6b317c PCI: Add "PCIe" to 
pcie_print_link_status() messages)
Merging driver-core.current/driver-core-linus (6da6c0db5316 Linux v4.17-rc3)
Merging tty.current/tty-linus (6da6c0db5316 Linux v4.17-rc3)
Merging usb.current/usb-linus (6844dc42722c Merge tag 'usb-serial-4.17-rc4' of 
https://git.kernel.org/pub/scm/linux/kernel/git/johan/usb-serial into usb-linus)
Merging usb-gadget-fixes/fixes (ed769520727e usb: gadget: composite Allow for 
larger configuration descriptors)
Merging usb-serial-fixes/usb-linus (4842ed5bfcb9 USB: serial: visor: handle 
potential invalid device configuration)
Merging usb-chipidea-fixes/ci-for-usb-stable (964728f9f407 USB: chipidea: msm: 
fix ulpi-node lookup)
Merging phy/fixes (60cc43fc8884 Linux 4.17-rc1)
Merging staging.current/staging-linus (6da6c0db5316 Linux v4.17-rc3)
Merging char-misc.current/char-misc-linus (6da6c0db5316 Linux v4.17-rc3)
Merging input-current/for-linus (f6eeb9e54857 Input: atmel_mxt_ts - add missing 
compatible strings to OF device table)
Merging crypto-current/master 

linux-next: Tree for May 7

[Stephen Rothwell]

Hi all,

Changes since 20180504:

The net-next tree gained a conflict against the net tree.

The tip tree gained conflicts against the bpf-next tree.

Non-merge commits (relative to Linus' tree): 4139
 3963 files changed, 164135 insertions(+), 75455 deletions(-)



I have created today's linux-next tree at
git://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git
(patches at http://www.kernel.org/pub/linux/kernel/next/ ).  If you
are tracking the linux-next tree using git, you should not use "git pull"
to do so as that will try to merge the new linux-next release with the
old one.  You should use "git fetch" and checkout or reset to the new
master.

You can see which trees have been included by looking in the Next/Trees
file in the source.  There are also quilt-import.log and merge.log
files in the Next directory.  Between each merge, the tree was built
with a ppc64_defconfig for powerpc, an allmodconfig for x86_64, a
multi_v7_defconfig for arm and a native build of tools/perf. After
the final fixups (if any), I do an x86_64 modules_install followed by
builds for x86_64 allnoconfig, powerpc allnoconfig (32 and 64 bit),
ppc44x_defconfig, allyesconfig and pseries_le_defconfig and i386, sparc
and sparc64 defconfig. And finally, a simple boot test of the powerpc
pseries_le_defconfig kernel in qemu (with and without kvm enabled).

Below is a summary of the state of the merge.

I am currently merging 257 trees (counting Linus' and 44 trees of bug
fix patches pending for the current merge release).

Stats about the size of the tree over time can be seen at
http://neuling.org/linux-next-size.html .

Status of my local build tests will be at
http://kisskb.ellerman.id.au/linux-next .  If maintainers want to give
advice about cross compilers/configs that work, we are always open to add
more builds.

Thanks to Randy Dunlap for doing many randconfig builds.  And to Paul
Gortmaker for triage and bug fixes.

-- 
Cheers,
Stephen Rothwell

$ git checkout master
$ git reset --hard stable
Merging origin/master (701e39d05119 Merge tag 'for-linus' of 
git://git.kernel.org/pub/scm/virt/kvm/kvm)
Merging fixes/master (147a89bc71e7 Merge tag 'kconfig-v4.17' of 
git://git.kernel.org/pub/scm/linux/kernel/git/masahiroy/linux-kbuild)
Merging kbuild-current/fixes (0da7e4326114 genksyms: fix typo in 
parse.tab.{c,h} generation rules)
Merging arc-current/for-curr (661e50bc8532 Linux 4.16-rc4)
Merging arm-current/fixes (30cfae461581 ARM: replace unnecessary perl with sed 
and the shell $(( )) operator)
Merging arm64-fixes/for-next/fixes (3789c122d0a0 arm64: avoid instrumenting 
atomic_ll_sc.o)
Merging m68k-current/for-linus (ecd685580c8f m68k/mac: Remove bogus "FIXME" 
comment)
Merging powerpc-fixes/fixes (b2d7ecbe3556 powerpc/kvm/booke: Fix altivec 
related build break)
Merging sparc/master (fff75eb2a08c Merge tag 'errseq-v4.17' of 
git://git.kernel.org/pub/scm/linux/kernel/git/jlayton/linux)
Merging fscrypt-current/for-stable (ae64f9bd1d36 Linux 4.15-rc2)
Merging net/master (2ba5622fba85 Merge 
git://git.kernel.org/pub/scm/linux/kernel/git/bpf/bpf)
Merging bpf/master (d0f1a451e33d bpf: use array_index_nospec in find_prog_type)
Merging ipsec/master (b4331a681822 vti6: Change minimum MTU to IPV4_MIN_MTU, 
vti6 can carry IPv4 too)
Merging netfilter/master (2f99aa31cd7a netfilter: nf_tables: skip 
synchronize_rcu if transaction log is empty)
Merging ipvs/master (765cca91b895 netfilter: conntrack: include kmemleak.h for 
kmemleak_not_leak())
Merging wireless-drivers/master (a8d7aa17bbc9 dccp: fix tasklet usage)
Merging mac80211/master (2f0605a697f4 nl80211: Free connkeys on external 
authentication failure)
Merging rdma-fixes/for-rc (9aa169213d11 RDMA/cma: Do not query GID during QP 
state transition to RTR)
Merging sound-current/for-linus (f13876e2c33a ALSA: pcm: Check PCM state at 
xfern compat ioctl)
Merging pci-current/for-linus (0cf22d6b317c PCI: Add "PCIe" to 
pcie_print_link_status() messages)
Merging driver-core.current/driver-core-linus (6da6c0db5316 Linux v4.17-rc3)
Merging tty.current/tty-linus (6da6c0db5316 Linux v4.17-rc3)
Merging usb.current/usb-linus (6844dc42722c Merge tag 'usb-serial-4.17-rc4' of 
https://git.kernel.org/pub/scm/linux/kernel/git/johan/usb-serial into usb-linus)
Merging usb-gadget-fixes/fixes (ed769520727e usb: gadget: composite Allow for 
larger configuration descriptors)
Merging usb-serial-fixes/usb-linus (4842ed5bfcb9 USB: serial: visor: handle 
potential invalid device configuration)
Merging usb-chipidea-fixes/ci-for-usb-stable (964728f9f407 USB: chipidea: msm: 
fix ulpi-node lookup)
Merging phy/fixes (60cc43fc8884 Linux 4.17-rc1)
Merging staging.current/staging-linus (6da6c0db5316 Linux v4.17-rc3)
Merging char-misc.current/char-misc-linus (6da6c0db5316 Linux v4.17-rc3)
Merging input-current/for-linus (f6eeb9e54857 Input: atmel_mxt_ts - add missing 
compatible strings to OF device table)
Merging crypto-current/master 

Re: [PATCH v9 03/11] arm64: kexec_file: invoke the kernel without purgatory

[AKASHI Takahiro]

On Tue, May 01, 2018 at 06:46:06PM +0100, James Morse wrote:
> Hi Akashi,
> 
> On 25/04/18 07:26, AKASHI Takahiro wrote:
> > On arm64, purugatory would do almosty nothing. So just invoke secondary
> > kernel directy by jumping into its entry code.
> 
> (Nits: purgatory, almost, directly)

Oops, I think I ran spell before ...

> 
> > While, in this case, cpu_soft_restart() must be called with dtb address
> > in the fifth argument, the behavior still stays compatible with kexec_load
> > case as long as the argument is null.
> 
> 
> > diff --git a/arch/arm64/kernel/cpu-reset.S b/arch/arm64/kernel/cpu-reset.S
> > index 8021b46c9743..391df91328ac 100644
> > --- a/arch/arm64/kernel/cpu-reset.S
> > +++ b/arch/arm64/kernel/cpu-reset.S
> > @@ -24,9 +24,9 @@
> >   *
> >   * @el2_switch: Flag to indicate a swich to EL2 is needed.
> 
> (Nit: switch)

ditto

> >   * @entry: Location to jump to for soft reset.
> > - * arg0: First argument passed to @entry.
> > - * arg1: Second argument passed to @entry.
> > - * arg2: Third argument passed to @entry.
> > + * arg0: First argument passed to @entry. (relocation list)
> > + * arg1: Second argument passed to @entry.(physcal kernel entry)
> 
> (Nit: physical)

ditto
> 
> > + * arg2: Third argument passed to @entry. (physical dtb address)
> >   *
> >   * Put the CPU into the same state as it would be if it had been reset, and
> >   * branch to what would be the reset vector. It must be executed with the
> > diff --git a/arch/arm64/kernel/machine_kexec.c 
> > b/arch/arm64/kernel/machine_kexec.c
> > index f76ea92dff91..f7dbba00be10 100644
> > --- a/arch/arm64/kernel/machine_kexec.c
> > +++ b/arch/arm64/kernel/machine_kexec.c
> > @@ -205,10 +205,17 @@ void machine_kexec(struct kimage *kimage)
> >  * uses physical addressing to relocate the new image to its final
> >  * position and transfers control to the image entry point when the
> >  * relocation is complete.
> > +* In case of kexec_file_load syscall, we directly start the kernel,
> > +* skipping purgatory.
> 
> We're not really skipping purgatory, purgatory doesn't exist! For regular 
> kexec
> the image/payload we run is up to kexec-tools. For kexec_file_load its a
> kernel-image. Purgatory is a kexec-tools-ism.

You are right, but in general, purgatory is expected to exist by
generic kexec code and does exist on all architectures,  kexec_load()
or kexec_file_load(), except arm64's kexec_file_load case.
So it would be nice to have some explicit notes here.

> 
> > cpu_soft_restart(kimage != kexec_crash_image,
> > -   reboot_code_buffer_phys, kimage->head, kimage->start, 0);
> > +   reboot_code_buffer_phys, kimage->head, kimage->start,
> > +#ifdef CONFIG_KEXEC_FILE
> > +   kimage->purgatory_info.purgatory_buf ?
> > +   0 : kimage->arch.dtb_mem);
> > +#else
> > +   0);
> > +#endif
> 
> Where does kimage->arch.dtb_mem come from? This patch won't build until patch 
> 8
> adds the config option, which is going to make bisecting any kexec 
> side-effects
> tricky.

CONFIG_KEXEC_FILE is also used in patch #4, #5 and #6.
I don't know how we can fix this as the implementation is divided
into several patches.
(So bisecting doesn't work anyway.)

> purgatory_buf seems to only be set in kexec_purgatory_setup_kbuf(), called 
> from
> kexec_load_purgatory(), which we don't use. How does this get a value?
> 
> Would it be better to always use kimage->arch.dtb_mem, and ensure that is 0 
> for
> regular kexec (as we can't know where the dtb is)? (image_arg may then be a
> better name).

The problem is arch.dtb_mem is currently defined only if CONFIG_KEXEC_FILE.
So I would like to
- merge this patch with patch#8
- change the condition
#ifdef CONFIG_KEXEC_FILE
kimage->file_mode ? kimage->arch.dtb_mem : 0);
#else
0);
#endif

Thanks,
-Takahiro AKASHI

> 
> Thanks,
> 
> James

Re: [PATCH v9 03/11] arm64: kexec_file: invoke the kernel without purgatory

[AKASHI Takahiro]

On Tue, May 01, 2018 at 06:46:06PM +0100, James Morse wrote:
> Hi Akashi,
> 
> On 25/04/18 07:26, AKASHI Takahiro wrote:
> > On arm64, purugatory would do almosty nothing. So just invoke secondary
> > kernel directy by jumping into its entry code.
> 
> (Nits: purgatory, almost, directly)

Oops, I think I ran spell before ...

> 
> > While, in this case, cpu_soft_restart() must be called with dtb address
> > in the fifth argument, the behavior still stays compatible with kexec_load
> > case as long as the argument is null.
> 
> 
> > diff --git a/arch/arm64/kernel/cpu-reset.S b/arch/arm64/kernel/cpu-reset.S
> > index 8021b46c9743..391df91328ac 100644
> > --- a/arch/arm64/kernel/cpu-reset.S
> > +++ b/arch/arm64/kernel/cpu-reset.S
> > @@ -24,9 +24,9 @@
> >   *
> >   * @el2_switch: Flag to indicate a swich to EL2 is needed.
> 
> (Nit: switch)

ditto

> >   * @entry: Location to jump to for soft reset.
> > - * arg0: First argument passed to @entry.
> > - * arg1: Second argument passed to @entry.
> > - * arg2: Third argument passed to @entry.
> > + * arg0: First argument passed to @entry. (relocation list)
> > + * arg1: Second argument passed to @entry.(physcal kernel entry)
> 
> (Nit: physical)

ditto
> 
> > + * arg2: Third argument passed to @entry. (physical dtb address)
> >   *
> >   * Put the CPU into the same state as it would be if it had been reset, and
> >   * branch to what would be the reset vector. It must be executed with the
> > diff --git a/arch/arm64/kernel/machine_kexec.c 
> > b/arch/arm64/kernel/machine_kexec.c
> > index f76ea92dff91..f7dbba00be10 100644
> > --- a/arch/arm64/kernel/machine_kexec.c
> > +++ b/arch/arm64/kernel/machine_kexec.c
> > @@ -205,10 +205,17 @@ void machine_kexec(struct kimage *kimage)
> >  * uses physical addressing to relocate the new image to its final
> >  * position and transfers control to the image entry point when the
> >  * relocation is complete.
> > +* In case of kexec_file_load syscall, we directly start the kernel,
> > +* skipping purgatory.
> 
> We're not really skipping purgatory, purgatory doesn't exist! For regular 
> kexec
> the image/payload we run is up to kexec-tools. For kexec_file_load its a
> kernel-image. Purgatory is a kexec-tools-ism.

You are right, but in general, purgatory is expected to exist by
generic kexec code and does exist on all architectures,  kexec_load()
or kexec_file_load(), except arm64's kexec_file_load case.
So it would be nice to have some explicit notes here.

> 
> > cpu_soft_restart(kimage != kexec_crash_image,
> > -   reboot_code_buffer_phys, kimage->head, kimage->start, 0);
> > +   reboot_code_buffer_phys, kimage->head, kimage->start,
> > +#ifdef CONFIG_KEXEC_FILE
> > +   kimage->purgatory_info.purgatory_buf ?
> > +   0 : kimage->arch.dtb_mem);
> > +#else
> > +   0);
> > +#endif
> 
> Where does kimage->arch.dtb_mem come from? This patch won't build until patch 
> 8
> adds the config option, which is going to make bisecting any kexec 
> side-effects
> tricky.

CONFIG_KEXEC_FILE is also used in patch #4, #5 and #6.
I don't know how we can fix this as the implementation is divided
into several patches.
(So bisecting doesn't work anyway.)

> purgatory_buf seems to only be set in kexec_purgatory_setup_kbuf(), called 
> from
> kexec_load_purgatory(), which we don't use. How does this get a value?
> 
> Would it be better to always use kimage->arch.dtb_mem, and ensure that is 0 
> for
> regular kexec (as we can't know where the dtb is)? (image_arg may then be a
> better name).

The problem is arch.dtb_mem is currently defined only if CONFIG_KEXEC_FILE.
So I would like to
- merge this patch with patch#8
- change the condition
#ifdef CONFIG_KEXEC_FILE
kimage->file_mode ? kimage->arch.dtb_mem : 0);
#else
0);
#endif

Thanks,
-Takahiro AKASHI

> 
> Thanks,
> 
> James

Re: [PATCH] scsi: sg: fix a missing-check bug

[Douglas Gilbert]

On 2018-05-05 11:21 PM, Wenwen Wang wrote:

In sg_write(), the opcode of the command is firstly copied from the
userspace pointer 'buf' and saved to the kernel variable 'opcode', using
the __get_user() function. The size of the command, i.e., 'cmd_size' is
then calculated based on the 'opcode'. After that, the whole command,
including the opcode, is copied again from 'buf' using the
__copy_from_user() function and saved to 'cmnd'. Finally, the function
  sg_common_write() is invoked to process 'cmnd'. Given that the 'buf'
pointer resides in userspace, a malicious userspace process can race to
change the opcode of the command between the two copies. That means, the
opcode indicated by the variable 'opcode' could be different from the
opcode in 'cmnd'. This can cause inconsistent data in 'cmnd' and
potential logical errors in the function sg_common_write(), as it needs to
work on 'cmnd'.

This patch reuses the opcode obtained in the first copy and only copies the
remaining part of the command from userspace.

Signed-off-by: Wenwen Wang 
---
  drivers/scsi/sg.c | 3 ++-
  1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/scsi/sg.c b/drivers/scsi/sg.c
index c198b963..0ad8106 100644
--- a/drivers/scsi/sg.c
+++ b/drivers/scsi/sg.c
@@ -657,7 +657,8 @@ sg_write(struct file *filp, const char __user *buf, size_t 
count, loff_t * ppos)
hp->flags = input_size;  /* structure abuse ... */
hp->pack_id = old_hdr.pack_id;
hp->usr_ptr = NULL;
-   if (__copy_from_user(cmnd, buf, cmd_size))
+   cmnd[0] = opcode;
+   if (__copy_from_user(cmnd + 1, buf + 1, cmd_size - 1))
return -EFAULT;
/*
 * SG_DXFER_TO_FROM_DEV is functionally equivalent to SG_DXFER_FROM_DEV,



That is in the deprecated "v2" part of the sg driver (for around 15 years).
There are lots more interesting races with that interface than that one
described above. My guess is that all system calls would be susceptible
to playing around with a buffer being passed to or from the OS by a thread
other than the one doing the system call, during that call. Surely no Unix
like OS gives any security guarantees to a thread being attacked by a
malevolent thread in the same process!

My question is did this actually cause to program to fail; or is it something
that a sanity checker flagged?

Also wouldn't it be better just to return an error such as EINVAL if
opcode != command[0]  ?

Doug Gilbert

Re: [PATCH] scsi: sg: fix a missing-check bug

[Douglas Gilbert]

On 2018-05-05 11:21 PM, Wenwen Wang wrote:

In sg_write(), the opcode of the command is firstly copied from the
userspace pointer 'buf' and saved to the kernel variable 'opcode', using
the __get_user() function. The size of the command, i.e., 'cmd_size' is
then calculated based on the 'opcode'. After that, the whole command,
including the opcode, is copied again from 'buf' using the
__copy_from_user() function and saved to 'cmnd'. Finally, the function
  sg_common_write() is invoked to process 'cmnd'. Given that the 'buf'
pointer resides in userspace, a malicious userspace process can race to
change the opcode of the command between the two copies. That means, the
opcode indicated by the variable 'opcode' could be different from the
opcode in 'cmnd'. This can cause inconsistent data in 'cmnd' and
potential logical errors in the function sg_common_write(), as it needs to
work on 'cmnd'.

This patch reuses the opcode obtained in the first copy and only copies the
remaining part of the command from userspace.

Signed-off-by: Wenwen Wang 
---
  drivers/scsi/sg.c | 3 ++-
  1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/scsi/sg.c b/drivers/scsi/sg.c
index c198b963..0ad8106 100644
--- a/drivers/scsi/sg.c
+++ b/drivers/scsi/sg.c
@@ -657,7 +657,8 @@ sg_write(struct file *filp, const char __user *buf, size_t 
count, loff_t * ppos)
hp->flags = input_size;  /* structure abuse ... */
hp->pack_id = old_hdr.pack_id;
hp->usr_ptr = NULL;
-   if (__copy_from_user(cmnd, buf, cmd_size))
+   cmnd[0] = opcode;
+   if (__copy_from_user(cmnd + 1, buf + 1, cmd_size - 1))
return -EFAULT;
/*
 * SG_DXFER_TO_FROM_DEV is functionally equivalent to SG_DXFER_FROM_DEV,



That is in the deprecated "v2" part of the sg driver (for around 15 years).
There are lots more interesting races with that interface than that one
described above. My guess is that all system calls would be susceptible
to playing around with a buffer being passed to or from the OS by a thread
other than the one doing the system call, during that call. Surely no Unix
like OS gives any security guarantees to a thread being attacked by a
malevolent thread in the same process!

My question is did this actually cause to program to fail; or is it something
that a sanity checker flagged?

Also wouldn't it be better just to return an error such as EINVAL if
opcode != command[0]  ?

Doug Gilbert

Re: [greybus-dev] [PATCH] staging: greybus: Remove unused local variable

[Viresh Kumar]

On 05-05-18, 23:50, Nathan Chancellor wrote:
> Fixes the following W=1 warning: variable ‘intf_id’ set but
> not used [-Wunused-but-set-variable]
> 
> Signed-off-by: Nathan Chancellor 
> ---
>  drivers/staging/greybus/svc.c | 3 ---
>  1 file changed, 3 deletions(-)
> 
> diff --git a/drivers/staging/greybus/svc.c b/drivers/staging/greybus/svc.c
> index a874fed761a1..a2bb7e1a3db3 100644
> --- a/drivers/staging/greybus/svc.c
> +++ b/drivers/staging/greybus/svc.c
> @@ -1137,7 +1137,6 @@ static int gb_svc_intf_reset_recv(struct gb_operation 
> *op)
>   struct gb_svc *svc = gb_connection_get_data(op->connection);
>   struct gb_message *request = op->request;
>   struct gb_svc_intf_reset_request *reset;
> - u8 intf_id;
>  
>   if (request->payload_size < sizeof(*reset)) {
>   dev_warn(>dev, "short reset request received (%zu < 
> %zu)\n",
> @@ -1146,8 +1145,6 @@ static int gb_svc_intf_reset_recv(struct gb_operation 
> *op)
>   }
>   reset = request->payload;
>  
> - intf_id = reset->intf_id;
> -
>   /* FIXME Reset the interface here */
>  
>   return 0;

Don't you get a new error after removing this, i.e "reset set but unused" ? Or
the sizeof() operation on that suppresses those warnings ..

Acked-by: Viresh Kumar 

-- 
viresh

Re: [greybus-dev] [PATCH] staging: greybus: Remove unused local variable

[Viresh Kumar]

On 05-05-18, 23:50, Nathan Chancellor wrote:
> Fixes the following W=1 warning: variable ‘intf_id’ set but
> not used [-Wunused-but-set-variable]
> 
> Signed-off-by: Nathan Chancellor 
> ---
>  drivers/staging/greybus/svc.c | 3 ---
>  1 file changed, 3 deletions(-)
> 
> diff --git a/drivers/staging/greybus/svc.c b/drivers/staging/greybus/svc.c
> index a874fed761a1..a2bb7e1a3db3 100644
> --- a/drivers/staging/greybus/svc.c
> +++ b/drivers/staging/greybus/svc.c
> @@ -1137,7 +1137,6 @@ static int gb_svc_intf_reset_recv(struct gb_operation 
> *op)
>   struct gb_svc *svc = gb_connection_get_data(op->connection);
>   struct gb_message *request = op->request;
>   struct gb_svc_intf_reset_request *reset;
> - u8 intf_id;
>  
>   if (request->payload_size < sizeof(*reset)) {
>   dev_warn(>dev, "short reset request received (%zu < 
> %zu)\n",
> @@ -1146,8 +1145,6 @@ static int gb_svc_intf_reset_recv(struct gb_operation 
> *op)
>   }
>   reset = request->payload;
>  
> - intf_id = reset->intf_id;
> -
>   /* FIXME Reset the interface here */
>  
>   return 0;

Don't you get a new error after removing this, i.e "reset set but unused" ? Or
the sizeof() operation on that suppresses those warnings ..

Acked-by: Viresh Kumar 

-- 
viresh

Re: [PATCH 04/24] selftests: cpufreq: return Kselftest Skip code for skipped tests

[Viresh Kumar]

On 04-05-18, 19:13, Shuah Khan (Samsung OSG) wrote:
> When cpufreq test is skipped because of unmet dependencies and/or
> unsupported configuration, it exits with error which is treated as
> a fail by the Kselftest framework. This leads to false negative
> result even when the test could not be run.
> 
> Change it to return kselftest skip code when a test gets skipped to
> clearly report that the test could not be run.
> 
> Kselftest framework SKIP code is 4 and the framework prints appropriate
> messages to indicate that the test is skipped.
> 
> Signed-off-by: Shuah Khan (Samsung OSG) 
> ---
>  tools/testing/selftests/cpufreq/main.sh | 5 -
>  1 file changed, 4 insertions(+), 1 deletion(-)
> 
> diff --git a/tools/testing/selftests/cpufreq/main.sh 
> b/tools/testing/selftests/cpufreq/main.sh
> index d83922de9d89..31f8c9a76c5f 100755
> --- a/tools/testing/selftests/cpufreq/main.sh
> +++ b/tools/testing/selftests/cpufreq/main.sh
> @@ -13,6 +13,9 @@ SYSFS=
>  CPUROOT=
>  CPUFREQROOT=
>  
> +# Kselftest framework requirement - SKIP code is 4.
> +ksft_skip=4
> +
>  helpme()
>  {
>   printf "Usage: $0 [-h] [-todg args]
> @@ -38,7 +41,7 @@ prerequisite()
>  
>   if [ $UID != 0 ]; then
>   echo $msg must be run as root >&2
> - exit 2
> + exit $ksft_skip
>   fi
>  
>   taskset -p 01 $$

Acked-by: Viresh Kumar 

-- 
viresh

Re: [PATCH 04/24] selftests: cpufreq: return Kselftest Skip code for skipped tests

[Viresh Kumar]

On 04-05-18, 19:13, Shuah Khan (Samsung OSG) wrote:
> When cpufreq test is skipped because of unmet dependencies and/or
> unsupported configuration, it exits with error which is treated as
> a fail by the Kselftest framework. This leads to false negative
> result even when the test could not be run.
> 
> Change it to return kselftest skip code when a test gets skipped to
> clearly report that the test could not be run.
> 
> Kselftest framework SKIP code is 4 and the framework prints appropriate
> messages to indicate that the test is skipped.
> 
> Signed-off-by: Shuah Khan (Samsung OSG) 
> ---
>  tools/testing/selftests/cpufreq/main.sh | 5 -
>  1 file changed, 4 insertions(+), 1 deletion(-)
> 
> diff --git a/tools/testing/selftests/cpufreq/main.sh 
> b/tools/testing/selftests/cpufreq/main.sh
> index d83922de9d89..31f8c9a76c5f 100755
> --- a/tools/testing/selftests/cpufreq/main.sh
> +++ b/tools/testing/selftests/cpufreq/main.sh
> @@ -13,6 +13,9 @@ SYSFS=
>  CPUROOT=
>  CPUFREQROOT=
>  
> +# Kselftest framework requirement - SKIP code is 4.
> +ksft_skip=4
> +
>  helpme()
>  {
>   printf "Usage: $0 [-h] [-todg args]
> @@ -38,7 +41,7 @@ prerequisite()
>  
>   if [ $UID != 0 ]; then
>   echo $msg must be run as root >&2
> - exit 2
> + exit $ksft_skip
>   fi
>  
>   taskset -p 01 $$

Acked-by: Viresh Kumar 

-- 
viresh

Re: Kernel build with gcc 8 a lot of warnings

[Josh Poimboeuf]

On Sat, May 05, 2018 at 09:21:12PM +0200, damian wrote:
> Helllo together,
> 
> Hello everybody,
> 
> is something special to note when kernel build with gcc 8? I receive various 
> warnings from the objtool:
> With GCC 7 works all fine.
> 
> kernel/cgroup/cgroup.o: warning: objtool: parse_cgroup_root_flags()+0x40: 
> sibling call from callable instruction with modified stack frame
> kernel/cgroup/cgroup.o: warning: objtool: cgroup_addrm_files()+0x2a3: sibling 
> call from callable instruction with modified stack frame
> kernel/cgroup/cgroup.o: warning: objtool: 
> cgroup_apply_control_enable()+0x20b: sibling call from callable instruction 
> with modified stack frame
> kernel/cgroup/cgroup.o: warning: objtool: rebind_subsystems()+0x296: sibling 
> call from callable instruction with modified stack frame
> kernel/cgroup/cgroup.o: warning: objtool: cgroup_sk_alloc_disable()+0x10: 
> sibling call from callable instruction with modified stack frame
> kernel/cgroup/cgroup.o: warning: objtool: 
> parse_cgroup_root_flags.cold.45()+0xa: call without frame pointer save/setup
> kernel/cgroup/cgroup.o: warning: objtool: cgroup_addrm_files.cold.46()+0x17: 
> call without frame pointer save/setup
> kernel/cgroup/cgroup.o: warning: objtool: 
> cgroup_apply_control_enable.cold.47()+0x24: call without frame pointer 
> save/setup
> kernel/cgroup/cgroup.o: warning: objtool: rebind_subsystems.cold.48()+0x10: 
> call without frame pointer save/setup
> kernel/cgroup/cgroup.o: warning: objtool: 
> cgroup_sk_alloc_disable.cold.49()+0x7: call without frame pointer save/setup
>   CC  kernel/cgroup/stat.o
>   CC [M]  arch/x86/kvm/../../../virt/kvm/kvm_main.o
> arch/x86/kernel/acpi/boot.o: warning: objtool: acpi_register_lapic()+0x10: 
> sibling call from callable instruction with modified stack frame
> arch/x86/kernel/acpi/boot.o: warning: objtool: acpi_map_cpu()+0x2c: sibling 
> call from callable instruction with modified stack frame
> arch/x86/kernel/acpi/boot.o: warning: objtool: 
> acpi_register_lapic.cold.6()+0x7: call without frame pointer save/setup
> arch/x86/kernel/acpi/boot.o: warning: objtool: acpi_map_cpu.cold.7()+0x7: 
> call without frame pointer save/setup

Thanks, this is a known issue with GCC 8 that I haven't gotten a chance
to fix yet.  They're related to the fact that GCC 8 is splitting out
'unlikely' code into 'cold' subfunctions in .text.unlikely.

I've got some old patches that fix it.  Now that GCC 8 is out, I'll need
get the patches dusted off and cleaned up for merging.

-- 
Josh

Re: Kernel build with gcc 8 a lot of warnings

[Josh Poimboeuf]

On Sat, May 05, 2018 at 09:21:12PM +0200, damian wrote:
> Helllo together,
> 
> Hello everybody,
> 
> is something special to note when kernel build with gcc 8? I receive various 
> warnings from the objtool:
> With GCC 7 works all fine.
> 
> kernel/cgroup/cgroup.o: warning: objtool: parse_cgroup_root_flags()+0x40: 
> sibling call from callable instruction with modified stack frame
> kernel/cgroup/cgroup.o: warning: objtool: cgroup_addrm_files()+0x2a3: sibling 
> call from callable instruction with modified stack frame
> kernel/cgroup/cgroup.o: warning: objtool: 
> cgroup_apply_control_enable()+0x20b: sibling call from callable instruction 
> with modified stack frame
> kernel/cgroup/cgroup.o: warning: objtool: rebind_subsystems()+0x296: sibling 
> call from callable instruction with modified stack frame
> kernel/cgroup/cgroup.o: warning: objtool: cgroup_sk_alloc_disable()+0x10: 
> sibling call from callable instruction with modified stack frame
> kernel/cgroup/cgroup.o: warning: objtool: 
> parse_cgroup_root_flags.cold.45()+0xa: call without frame pointer save/setup
> kernel/cgroup/cgroup.o: warning: objtool: cgroup_addrm_files.cold.46()+0x17: 
> call without frame pointer save/setup
> kernel/cgroup/cgroup.o: warning: objtool: 
> cgroup_apply_control_enable.cold.47()+0x24: call without frame pointer 
> save/setup
> kernel/cgroup/cgroup.o: warning: objtool: rebind_subsystems.cold.48()+0x10: 
> call without frame pointer save/setup
> kernel/cgroup/cgroup.o: warning: objtool: 
> cgroup_sk_alloc_disable.cold.49()+0x7: call without frame pointer save/setup
>   CC  kernel/cgroup/stat.o
>   CC [M]  arch/x86/kvm/../../../virt/kvm/kvm_main.o
> arch/x86/kernel/acpi/boot.o: warning: objtool: acpi_register_lapic()+0x10: 
> sibling call from callable instruction with modified stack frame
> arch/x86/kernel/acpi/boot.o: warning: objtool: acpi_map_cpu()+0x2c: sibling 
> call from callable instruction with modified stack frame
> arch/x86/kernel/acpi/boot.o: warning: objtool: 
> acpi_register_lapic.cold.6()+0x7: call without frame pointer save/setup
> arch/x86/kernel/acpi/boot.o: warning: objtool: acpi_map_cpu.cold.7()+0x7: 
> call without frame pointer save/setup

Thanks, this is a known issue with GCC 8 that I haven't gotten a chance
to fix yet.  They're related to the fact that GCC 8 is splitting out
'unlikely' code into 'cold' subfunctions in .text.unlikely.

I've got some old patches that fix it.  Now that GCC 8 is out, I'll need
get the patches dusted off and cleaned up for merging.

-- 
Josh

Re: moving affs + RDB partition support to staging?

[jdow]

On 20180506 01:52, John Paul Adrian Glaubitz wrote:

On 04/27/2018 03:26 AM, jdow wrote:

And before I forget there are two features of the RDBs that I heartily 
recommend never implementing on Linux. They were good ideas at the time; but, 
times
changed. The RDBs are capable of storing a filesystem driver and some drive 
init code for the plugin disk driver card. That is giving malware authors 
entirely
goo easy a shot at owning a machine. Martin S., I would strongly suggest that 
going forward those two capabilities be removed from the RDB readers in AmigaOS
as well as Linux OS.


I assume removing the feature for AmigaOS isn't really possible since we don't 
have
the source code for that, do we?

Also, if I remember correctly, Mac partitions can store filesystem drivers as 
well
and its actually a feature being used in MacOS. parted received a patch some 
time
ago to fix the correct handling for storing the filesystem driver in the 
partition
table.

I would be generally against removing these features as I don't think the 
security
risk is relevant for the majority of users. The Amiga is a hobbyist machine 
these
days and AmigaOS has certainly way more on than way to be compromised through
vulnerabilities.

Adrian


You do not necessarily have the source for the device drivers. However the 
DriveInit code and the filesystem code get executed by the OS initialization 
code. The objection I have to the concept is that it's invisible to the user. 
The Linux filesystem code is either compiled into the kernel or is available in 
the libraries where it can be monitored at several levels from source code on 
up. Within AmigaDOS it can be monitored fairly easily by an AV tool - in theory. 
Alas, this is trying to lock the barn door after the barn has burned to the 
ground with a clever enough piece of malware. At least AmigaDOS AV tools should 
be expected to examine DriveInit and filesystem images on disk in the RDBs for 
malware modifications to those blocks. This is a burden Linux should not be 
forced to bear. So loading filesystems from RDBs instead of the more usual and 
accepted Linux practices should be disabled. And at least a portion of this 
discussion is Linux related. That's why I mentioned disabling the feature. While 
I cannot see much money in AmigaDOS related malware I can see it in Linux 
malware. And there's no real "glory" in launching malware on AmigaDOS. It's too 
easy a problem last I knew. "Whoopie, you have just proven you can ride a 
tricycle. Can't you do better?" (One could argue that AmigaDOS 1.0 was 
self-inflicted malware foisted on marvelous hardware for the era.)


{^_^}   Joanne Dow

Re: moving affs + RDB partition support to staging?

[jdow]

On 20180506 01:52, John Paul Adrian Glaubitz wrote:

On 04/27/2018 03:26 AM, jdow wrote:

And before I forget there are two features of the RDBs that I heartily 
recommend never implementing on Linux. They were good ideas at the time; but, 
times
changed. The RDBs are capable of storing a filesystem driver and some drive 
init code for the plugin disk driver card. That is giving malware authors 
entirely
goo easy a shot at owning a machine. Martin S., I would strongly suggest that 
going forward those two capabilities be removed from the RDB readers in AmigaOS
as well as Linux OS.


I assume removing the feature for AmigaOS isn't really possible since we don't 
have
the source code for that, do we?

Also, if I remember correctly, Mac partitions can store filesystem drivers as 
well
and its actually a feature being used in MacOS. parted received a patch some 
time
ago to fix the correct handling for storing the filesystem driver in the 
partition
table.

I would be generally against removing these features as I don't think the 
security
risk is relevant for the majority of users. The Amiga is a hobbyist machine 
these
days and AmigaOS has certainly way more on than way to be compromised through
vulnerabilities.

Adrian


You do not necessarily have the source for the device drivers. However the 
DriveInit code and the filesystem code get executed by the OS initialization 
code. The objection I have to the concept is that it's invisible to the user. 
The Linux filesystem code is either compiled into the kernel or is available in 
the libraries where it can be monitored at several levels from source code on 
up. Within AmigaDOS it can be monitored fairly easily by an AV tool - in theory. 
Alas, this is trying to lock the barn door after the barn has burned to the 
ground with a clever enough piece of malware. At least AmigaDOS AV tools should 
be expected to examine DriveInit and filesystem images on disk in the RDBs for 
malware modifications to those blocks. This is a burden Linux should not be 
forced to bear. So loading filesystems from RDBs instead of the more usual and 
accepted Linux practices should be disabled. And at least a portion of this 
discussion is Linux related. That's why I mentioned disabling the feature. While 
I cannot see much money in AmigaDOS related malware I can see it in Linux 
malware. And there's no real "glory" in launching malware on AmigaDOS. It's too 
easy a problem last I knew. "Whoopie, you have just proven you can ride a 
tricycle. Can't you do better?" (One could argue that AmigaDOS 1.0 was 
self-inflicted malware foisted on marvelous hardware for the era.)


{^_^}   Joanne Dow

[PATCH v2 7/7] platform/x86: mlx-platform: Add mlxreg-io platform driver activation

[Vadim Pasternak]

Add mlxreg-io platform driver activation. Access driver uses the same
regmap infrastructure as others Mellanox platform drivers.
Specific registers description for default platform data configuration are
added to mlx-platform. There are the registers for resets control, reset
causes monitoring, programmable devices version reading and mux select
control. This platform data is passed to mlxreg-io driver. Also some
default values for the register are set at initialization time through
the regmap infrastructure, which are necessary for moving write protection
from the general purpose registers, which are used by mlxreg-io for
write access.

Signed-off-by: Vadim Pasternak 
---
 drivers/platform/x86/mlx-platform.c | 159 +++-
 1 file changed, 157 insertions(+), 2 deletions(-)

diff --git a/drivers/platform/x86/mlx-platform.c 
b/drivers/platform/x86/mlx-platform.c
index a0fd9aa..87ddd3a 100644
--- a/drivers/platform/x86/mlx-platform.c
+++ b/drivers/platform/x86/mlx-platform.c
@@ -47,11 +47,18 @@
 /* LPC bus IO offsets */
 #define MLXPLAT_CPLD_LPC_I2C_BASE_ADRR 0x2000
 #define MLXPLAT_CPLD_LPC_REG_BASE_ADRR 0x2500
+#define MLXPLAT_CPLD_LPC_REG_CPLD1_VER_OFFSET  0x00
+#define MLXPLAT_CPLD_LPC_REG_CPLD2_VER_OFFSET  0x01
+#define MLXPLAT_CPLD_LPC_REG_RESET_CAUSE_OFFSET0x1d
 #define MLXPLAT_CPLD_LPC_REG_LED1_OFFSET   0x20
 #define MLXPLAT_CPLD_LPC_REG_LED2_OFFSET   0x21
 #define MLXPLAT_CPLD_LPC_REG_LED3_OFFSET   0x22
 #define MLXPLAT_CPLD_LPC_REG_LED4_OFFSET   0x23
 #define MLXPLAT_CPLD_LPC_REG_LED5_OFFSET   0x24
+#define MLXPLAT_CPLD_LPC_REG_GP1_OFFSET0x30
+#define MLXPLAT_CPLD_LPC_REG_WP1_OFFSET0x31
+#define MLXPLAT_CPLD_LPC_REG_GP2_OFFSET0x32
+#define MLXPLAT_CPLD_LPC_REG_WP2_OFFSET0x33
 #define MLXPLAT_CPLD_LPC_REG_AGGR_OFFSET   0x3a
 #define MLXPLAT_CPLD_LPC_REG_AGGR_MASK_OFFSET  0x3b
 #define MLXPLAT_CPLD_LPC_REG_AGGRLO_OFFSET 0x40
@@ -122,12 +129,14 @@
  * @pdev_mux - array of mux platform devices
  * @pdev_hotplug - hotplug platform devices
  * @pdev_led - led platform devices
+ * @pdev_io_regs - register access platform devices
  */
 struct mlxplat_priv {
struct platform_device *pdev_i2c;
struct platform_device *pdev_mux[MLXPLAT_CPLD_LPC_MUX_DEVS];
struct platform_device *pdev_hotplug;
struct platform_device *pdev_led;
+   struct platform_device *pdev_io_regs;
 };
 
 /* Regions for LPC I2C controller and LPC base register space */
@@ -813,6 +822,98 @@ static struct mlxreg_core_platform_data 
mlxplat_default_ng_led_data = {
.counter = ARRAY_SIZE(mlxplat_mlxcpld_default_ng_led_data),
 };
 
+/* Platform register access default */
+static struct mlxreg_core_data mlxplat_mlxcpld_default_regs_io_data[] = {
+   {
+   .label = "cpld1_version",
+   .reg = MLXPLAT_CPLD_LPC_REG_CPLD1_VER_OFFSET,
+   .bit = GENMASK(7, 0),
+   .mode = 0444,
+   },
+   {
+   .label = "cpld2_version",
+   .reg = MLXPLAT_CPLD_LPC_REG_CPLD2_VER_OFFSET,
+   .bit = GENMASK(7, 0),
+   .mode = 0444,
+   },
+   {
+   .label = "cause_long_pb",
+   .reg = MLXPLAT_CPLD_LPC_REG_RESET_CAUSE_OFFSET,
+   .mask = GENMASK(7, 0) & ~BIT(0),
+   .mode = 0444,
+   },
+   {
+   .label = "cause_short_pb",
+   .reg = MLXPLAT_CPLD_LPC_REG_RESET_CAUSE_OFFSET,
+   .mask = GENMASK(7, 0) & ~BIT(1),
+   .mode = 0444,
+   },
+   {
+   .label = "cause_aux_pwr_or_ref",
+   .reg = MLXPLAT_CPLD_LPC_REG_RESET_CAUSE_OFFSET,
+   .mask = GENMASK(7, 0) & ~BIT(2),
+   .mode = 0444,
+   },
+   {
+   .label = "cause_main_pwr_fail",
+   .reg = MLXPLAT_CPLD_LPC_REG_RESET_CAUSE_OFFSET,
+   .mask = GENMASK(7, 0) & ~BIT(3),
+   .mode = 0444,
+   },
+   {
+   .label = "cause_sw_reset",
+   .reg = MLXPLAT_CPLD_LPC_REG_RESET_CAUSE_OFFSET,
+   .mask = GENMASK(7, 0) & ~BIT(4),
+   .mode = 0444,
+   },
+   {
+   .label = "cause_fw_reset",
+   .reg = MLXPLAT_CPLD_LPC_REG_RESET_CAUSE_OFFSET,
+   .mask = GENMASK(7, 0) & ~BIT(5),
+   .mode = 0444,
+   },
+   {
+   .label = "cause_hotswap_or_wd",
+   .reg = MLXPLAT_CPLD_LPC_REG_RESET_CAUSE_OFFSET,
+   .mask = GENMASK(7, 0) & ~BIT(6),
+   .mode = 0444,
+   },
+   {
+   .label = "cause_asic_thermal",
+   .reg = MLXPLAT_CPLD_LPC_REG_RESET_CAUSE_OFFSET,
+   .mask = GENMASK(7, 0) & ~BIT(7),
+   .mode = 0444,
+   },
+   {
+   .label = "psu1_on",
+   .reg = 

[PATCH v2 7/7] platform/x86: mlx-platform: Add mlxreg-io platform driver activation

[Vadim Pasternak]

Add mlxreg-io platform driver activation. Access driver uses the same
regmap infrastructure as others Mellanox platform drivers.
Specific registers description for default platform data configuration are
added to mlx-platform. There are the registers for resets control, reset
causes monitoring, programmable devices version reading and mux select
control. This platform data is passed to mlxreg-io driver. Also some
default values for the register are set at initialization time through
the regmap infrastructure, which are necessary for moving write protection
from the general purpose registers, which are used by mlxreg-io for
write access.

Signed-off-by: Vadim Pasternak 
---
 drivers/platform/x86/mlx-platform.c | 159 +++-
 1 file changed, 157 insertions(+), 2 deletions(-)

diff --git a/drivers/platform/x86/mlx-platform.c 
b/drivers/platform/x86/mlx-platform.c
index a0fd9aa..87ddd3a 100644
--- a/drivers/platform/x86/mlx-platform.c
+++ b/drivers/platform/x86/mlx-platform.c
@@ -47,11 +47,18 @@
 /* LPC bus IO offsets */
 #define MLXPLAT_CPLD_LPC_I2C_BASE_ADRR 0x2000
 #define MLXPLAT_CPLD_LPC_REG_BASE_ADRR 0x2500
+#define MLXPLAT_CPLD_LPC_REG_CPLD1_VER_OFFSET  0x00
+#define MLXPLAT_CPLD_LPC_REG_CPLD2_VER_OFFSET  0x01
+#define MLXPLAT_CPLD_LPC_REG_RESET_CAUSE_OFFSET0x1d
 #define MLXPLAT_CPLD_LPC_REG_LED1_OFFSET   0x20
 #define MLXPLAT_CPLD_LPC_REG_LED2_OFFSET   0x21
 #define MLXPLAT_CPLD_LPC_REG_LED3_OFFSET   0x22
 #define MLXPLAT_CPLD_LPC_REG_LED4_OFFSET   0x23
 #define MLXPLAT_CPLD_LPC_REG_LED5_OFFSET   0x24
+#define MLXPLAT_CPLD_LPC_REG_GP1_OFFSET0x30
+#define MLXPLAT_CPLD_LPC_REG_WP1_OFFSET0x31
+#define MLXPLAT_CPLD_LPC_REG_GP2_OFFSET0x32
+#define MLXPLAT_CPLD_LPC_REG_WP2_OFFSET0x33
 #define MLXPLAT_CPLD_LPC_REG_AGGR_OFFSET   0x3a
 #define MLXPLAT_CPLD_LPC_REG_AGGR_MASK_OFFSET  0x3b
 #define MLXPLAT_CPLD_LPC_REG_AGGRLO_OFFSET 0x40
@@ -122,12 +129,14 @@
  * @pdev_mux - array of mux platform devices
  * @pdev_hotplug - hotplug platform devices
  * @pdev_led - led platform devices
+ * @pdev_io_regs - register access platform devices
  */
 struct mlxplat_priv {
struct platform_device *pdev_i2c;
struct platform_device *pdev_mux[MLXPLAT_CPLD_LPC_MUX_DEVS];
struct platform_device *pdev_hotplug;
struct platform_device *pdev_led;
+   struct platform_device *pdev_io_regs;
 };
 
 /* Regions for LPC I2C controller and LPC base register space */
@@ -813,6 +822,98 @@ static struct mlxreg_core_platform_data 
mlxplat_default_ng_led_data = {
.counter = ARRAY_SIZE(mlxplat_mlxcpld_default_ng_led_data),
 };
 
+/* Platform register access default */
+static struct mlxreg_core_data mlxplat_mlxcpld_default_regs_io_data[] = {
+   {
+   .label = "cpld1_version",
+   .reg = MLXPLAT_CPLD_LPC_REG_CPLD1_VER_OFFSET,
+   .bit = GENMASK(7, 0),
+   .mode = 0444,
+   },
+   {
+   .label = "cpld2_version",
+   .reg = MLXPLAT_CPLD_LPC_REG_CPLD2_VER_OFFSET,
+   .bit = GENMASK(7, 0),
+   .mode = 0444,
+   },
+   {
+   .label = "cause_long_pb",
+   .reg = MLXPLAT_CPLD_LPC_REG_RESET_CAUSE_OFFSET,
+   .mask = GENMASK(7, 0) & ~BIT(0),
+   .mode = 0444,
+   },
+   {
+   .label = "cause_short_pb",
+   .reg = MLXPLAT_CPLD_LPC_REG_RESET_CAUSE_OFFSET,
+   .mask = GENMASK(7, 0) & ~BIT(1),
+   .mode = 0444,
+   },
+   {
+   .label = "cause_aux_pwr_or_ref",
+   .reg = MLXPLAT_CPLD_LPC_REG_RESET_CAUSE_OFFSET,
+   .mask = GENMASK(7, 0) & ~BIT(2),
+   .mode = 0444,
+   },
+   {
+   .label = "cause_main_pwr_fail",
+   .reg = MLXPLAT_CPLD_LPC_REG_RESET_CAUSE_OFFSET,
+   .mask = GENMASK(7, 0) & ~BIT(3),
+   .mode = 0444,
+   },
+   {
+   .label = "cause_sw_reset",
+   .reg = MLXPLAT_CPLD_LPC_REG_RESET_CAUSE_OFFSET,
+   .mask = GENMASK(7, 0) & ~BIT(4),
+   .mode = 0444,
+   },
+   {
+   .label = "cause_fw_reset",
+   .reg = MLXPLAT_CPLD_LPC_REG_RESET_CAUSE_OFFSET,
+   .mask = GENMASK(7, 0) & ~BIT(5),
+   .mode = 0444,
+   },
+   {
+   .label = "cause_hotswap_or_wd",
+   .reg = MLXPLAT_CPLD_LPC_REG_RESET_CAUSE_OFFSET,
+   .mask = GENMASK(7, 0) & ~BIT(6),
+   .mode = 0444,
+   },
+   {
+   .label = "cause_asic_thermal",
+   .reg = MLXPLAT_CPLD_LPC_REG_RESET_CAUSE_OFFSET,
+   .mask = GENMASK(7, 0) & ~BIT(7),
+   .mode = 0444,
+   },
+   {
+   .label = "psu1_on",
+   .reg = 

[PATCH v2 4/7] platform: mellanox: add new ODM system types to mlx-platform

[Vadim Pasternak]

Add new ODM system types, matched according to DMI_BOARD_NAME. The
supported ODM Ids are: VMOD0001, VMOD0002, VMOD0003, VMOD0004, VMOD0005.
Patch does not introduce new systems, but allows to ODM companies to set
DMI_BOARD_VENDOR and DMI_PRODUCT_NAME on their own. It assumes that ODM
company can't change DMI_BOARD_NAME.

Signed-off-by: Vadim Pasternak 
---
v1->v2:
 Comments pointed out by Darren:
 - Modify commit message;
---
 drivers/platform/x86/mlx-platform.c | 30 ++
 1 file changed, 30 insertions(+)

diff --git a/drivers/platform/x86/mlx-platform.c 
b/drivers/platform/x86/mlx-platform.c
index 7a0bd24..912f844 100644
--- a/drivers/platform/x86/mlx-platform.c
+++ b/drivers/platform/x86/mlx-platform.c
@@ -844,6 +844,36 @@ static const struct dmi_system_id mlxplat_dmi_table[] 
__initconst = {
DMI_MATCH(DMI_PRODUCT_NAME, "SN34"),
},
},
+   {
+   .callback = mlxplat_dmi_default_matched,
+   .matches = {
+   DMI_MATCH(DMI_BOARD_NAME, "VMOD0001"),
+   },
+   },
+   {
+   .callback = mlxplat_dmi_msn21xx_matched,
+   .matches = {
+   DMI_MATCH(DMI_BOARD_NAME, "VMOD0002"),
+   },
+   },
+   {
+   .callback = mlxplat_dmi_msn274x_matched,
+   .matches = {
+   DMI_MATCH(DMI_BOARD_NAME, "VMOD0003"),
+   },
+   },
+   {
+   .callback = mlxplat_dmi_msn201x_matched,
+   .matches = {
+   DMI_MATCH(DMI_BOARD_NAME, "VMOD0004"),
+   },
+   },
+   {
+   .callback = mlxplat_dmi_qmb7xx_matched,
+   .matches = {
+   DMI_MATCH(DMI_BOARD_NAME, "VMOD0005"),
+   },
+   },
{ }
 };
 
-- 
2.1.4

[PATCH v2 5/7] platform/x86: mlx-platform: Add LED platform driver activation

[Vadim Pasternak]

Add LED platform driver activation from mlx-platform. This LED driver uses
the same regmap infrastructure as others Mellanox platform drivers, so LED
specific registers description is added.

System LED configuration depends on system type. To support all the
relevant types per system type LED descriptions are defined for passing
to LED platform driver.

Signed-off-by: Vadim Pasternak 
v1->v2:
 Fixes added by Vadim:
 - Remove inline functions from mlxreg.h file;
---
 drivers/platform/x86/mlx-platform.c | 259 +++-
 1 file changed, 258 insertions(+), 1 deletion(-)

diff --git a/drivers/platform/x86/mlx-platform.c 
b/drivers/platform/x86/mlx-platform.c
index 912f844..a0fd9aa 100644
--- a/drivers/platform/x86/mlx-platform.c
+++ b/drivers/platform/x86/mlx-platform.c
@@ -47,6 +47,11 @@
 /* LPC bus IO offsets */
 #define MLXPLAT_CPLD_LPC_I2C_BASE_ADRR 0x2000
 #define MLXPLAT_CPLD_LPC_REG_BASE_ADRR 0x2500
+#define MLXPLAT_CPLD_LPC_REG_LED1_OFFSET   0x20
+#define MLXPLAT_CPLD_LPC_REG_LED2_OFFSET   0x21
+#define MLXPLAT_CPLD_LPC_REG_LED3_OFFSET   0x22
+#define MLXPLAT_CPLD_LPC_REG_LED4_OFFSET   0x23
+#define MLXPLAT_CPLD_LPC_REG_LED5_OFFSET   0x24
 #define MLXPLAT_CPLD_LPC_REG_AGGR_OFFSET   0x3a
 #define MLXPLAT_CPLD_LPC_REG_AGGR_MASK_OFFSET  0x3b
 #define MLXPLAT_CPLD_LPC_REG_AGGRLO_OFFSET 0x40
@@ -84,6 +89,8 @@
 #define MLXPLAT_CPLD_PWR_MASK  GENMASK(1, 0)
 #define MLXPLAT_CPLD_FAN_MASK  GENMASK(3, 0)
 #define MLXPLAT_CPLD_FAN_NG_MASK   GENMASK(5, 0)
+#define MLXPLAT_CPLD_LED_LO_NIBBLE_MASKGENMASK(7, 4)
+#define MLXPLAT_CPLD_LED_HI_NIBBLE_MASKGENMASK(3, 0)
 
 /* Default I2C parent bus number */
 #define MLXPLAT_CPLD_PHYS_ADAPTER_DEF_NR   1
@@ -114,11 +121,13 @@
  * @pdev_i2c - i2c controller platform device
  * @pdev_mux - array of mux platform devices
  * @pdev_hotplug - hotplug platform devices
+ * @pdev_led - led platform devices
  */
 struct mlxplat_priv {
struct platform_device *pdev_i2c;
struct platform_device *pdev_mux[MLXPLAT_CPLD_LPC_MUX_DEVS];
struct platform_device *pdev_hotplug;
+   struct platform_device *pdev_led;
 };
 
 /* Regions for LPC I2C controller and LPC base register space */
@@ -592,9 +601,227 @@ struct mlxreg_core_hotplug_platform_data 
mlxplat_mlxcpld_default_ng_data = {
.mask_low = MLXPLAT_CPLD_LOW_AGGR_MASK_LOW,
 };
 
+/* Platform led default data */
+static struct mlxreg_core_data mlxplat_mlxcpld_default_led_data[] = {
+   {
+   .label = "status:green",
+   .reg = MLXPLAT_CPLD_LPC_REG_LED1_OFFSET,
+   .mask = MLXPLAT_CPLD_LED_LO_NIBBLE_MASK,
+   },
+   {
+   .label = "status:red",
+   .reg = MLXPLAT_CPLD_LPC_REG_LED1_OFFSET,
+   .mask = MLXPLAT_CPLD_LED_LO_NIBBLE_MASK
+   },
+   {
+   .label = "psu:green",
+   .reg = MLXPLAT_CPLD_LPC_REG_LED1_OFFSET,
+   .mask = MLXPLAT_CPLD_LED_HI_NIBBLE_MASK,
+   },
+   {
+   .label = "psu:red",
+   .reg = MLXPLAT_CPLD_LPC_REG_LED1_OFFSET,
+   .mask = MLXPLAT_CPLD_LED_HI_NIBBLE_MASK,
+   },
+   {
+   .label = "fan1:green",
+   .reg = MLXPLAT_CPLD_LPC_REG_LED2_OFFSET,
+   .mask = MLXPLAT_CPLD_LED_LO_NIBBLE_MASK,
+   },
+   {
+   .label = "fan1:red",
+   .reg = MLXPLAT_CPLD_LPC_REG_LED2_OFFSET,
+   .mask = MLXPLAT_CPLD_LED_LO_NIBBLE_MASK,
+   },
+   {
+   .label = "fan2:green",
+   .reg = MLXPLAT_CPLD_LPC_REG_LED2_OFFSET,
+   .mask = MLXPLAT_CPLD_LED_HI_NIBBLE_MASK,
+   },
+   {
+   .label = "fan2:red",
+   .reg = MLXPLAT_CPLD_LPC_REG_LED2_OFFSET,
+   .mask = MLXPLAT_CPLD_LED_HI_NIBBLE_MASK,
+   },
+   {
+   .label = "fan3:green",
+   .reg = MLXPLAT_CPLD_LPC_REG_LED3_OFFSET,
+   .mask = MLXPLAT_CPLD_LED_LO_NIBBLE_MASK,
+   },
+   {
+   .label = "fan3:red",
+   .reg = MLXPLAT_CPLD_LPC_REG_LED3_OFFSET,
+   .mask = MLXPLAT_CPLD_LED_LO_NIBBLE_MASK,
+   },
+   {
+   .label = "fan4:green",
+   .reg = MLXPLAT_CPLD_LPC_REG_LED3_OFFSET,
+   .mask = MLXPLAT_CPLD_LED_HI_NIBBLE_MASK,
+   },
+   {
+   .label = "fan4:red",
+   .reg = MLXPLAT_CPLD_LPC_REG_LED3_OFFSET,
+   .mask = MLXPLAT_CPLD_LED_HI_NIBBLE_MASK,
+   },
+};
+
+static struct mlxreg_core_platform_data mlxplat_default_led_data = {
+   .data = mlxplat_mlxcpld_default_led_data,
+   .counter = ARRAY_SIZE(mlxplat_mlxcpld_default_led_data),
+};
+
+/* Platform led MSN21xx system family data */
+static struct mlxreg_core_data mlxplat_mlxcpld_msn21xx_led_data[] = {
+   {
+   .label = 

[PATCH v2 4/7] platform: mellanox: add new ODM system types to mlx-platform

[Vadim Pasternak]

Add new ODM system types, matched according to DMI_BOARD_NAME. The
supported ODM Ids are: VMOD0001, VMOD0002, VMOD0003, VMOD0004, VMOD0005.
Patch does not introduce new systems, but allows to ODM companies to set
DMI_BOARD_VENDOR and DMI_PRODUCT_NAME on their own. It assumes that ODM
company can't change DMI_BOARD_NAME.

Signed-off-by: Vadim Pasternak 
---
v1->v2:
 Comments pointed out by Darren:
 - Modify commit message;
---
 drivers/platform/x86/mlx-platform.c | 30 ++
 1 file changed, 30 insertions(+)

diff --git a/drivers/platform/x86/mlx-platform.c 
b/drivers/platform/x86/mlx-platform.c
index 7a0bd24..912f844 100644
--- a/drivers/platform/x86/mlx-platform.c
+++ b/drivers/platform/x86/mlx-platform.c
@@ -844,6 +844,36 @@ static const struct dmi_system_id mlxplat_dmi_table[] 
__initconst = {
DMI_MATCH(DMI_PRODUCT_NAME, "SN34"),
},
},
+   {
+   .callback = mlxplat_dmi_default_matched,
+   .matches = {
+   DMI_MATCH(DMI_BOARD_NAME, "VMOD0001"),
+   },
+   },
+   {
+   .callback = mlxplat_dmi_msn21xx_matched,
+   .matches = {
+   DMI_MATCH(DMI_BOARD_NAME, "VMOD0002"),
+   },
+   },
+   {
+   .callback = mlxplat_dmi_msn274x_matched,
+   .matches = {
+   DMI_MATCH(DMI_BOARD_NAME, "VMOD0003"),
+   },
+   },
+   {
+   .callback = mlxplat_dmi_msn201x_matched,
+   .matches = {
+   DMI_MATCH(DMI_BOARD_NAME, "VMOD0004"),
+   },
+   },
+   {
+   .callback = mlxplat_dmi_qmb7xx_matched,
+   .matches = {
+   DMI_MATCH(DMI_BOARD_NAME, "VMOD0005"),
+   },
+   },
{ }
 };
 
-- 
2.1.4

[PATCH v2 5/7] platform/x86: mlx-platform: Add LED platform driver activation

[Vadim Pasternak]

Add LED platform driver activation from mlx-platform. This LED driver uses
the same regmap infrastructure as others Mellanox platform drivers, so LED
specific registers description is added.

System LED configuration depends on system type. To support all the
relevant types per system type LED descriptions are defined for passing
to LED platform driver.

Signed-off-by: Vadim Pasternak 
v1->v2:
 Fixes added by Vadim:
 - Remove inline functions from mlxreg.h file;
---
 drivers/platform/x86/mlx-platform.c | 259 +++-
 1 file changed, 258 insertions(+), 1 deletion(-)

diff --git a/drivers/platform/x86/mlx-platform.c 
b/drivers/platform/x86/mlx-platform.c
index 912f844..a0fd9aa 100644
--- a/drivers/platform/x86/mlx-platform.c
+++ b/drivers/platform/x86/mlx-platform.c
@@ -47,6 +47,11 @@
 /* LPC bus IO offsets */
 #define MLXPLAT_CPLD_LPC_I2C_BASE_ADRR 0x2000
 #define MLXPLAT_CPLD_LPC_REG_BASE_ADRR 0x2500
+#define MLXPLAT_CPLD_LPC_REG_LED1_OFFSET   0x20
+#define MLXPLAT_CPLD_LPC_REG_LED2_OFFSET   0x21
+#define MLXPLAT_CPLD_LPC_REG_LED3_OFFSET   0x22
+#define MLXPLAT_CPLD_LPC_REG_LED4_OFFSET   0x23
+#define MLXPLAT_CPLD_LPC_REG_LED5_OFFSET   0x24
 #define MLXPLAT_CPLD_LPC_REG_AGGR_OFFSET   0x3a
 #define MLXPLAT_CPLD_LPC_REG_AGGR_MASK_OFFSET  0x3b
 #define MLXPLAT_CPLD_LPC_REG_AGGRLO_OFFSET 0x40
@@ -84,6 +89,8 @@
 #define MLXPLAT_CPLD_PWR_MASK  GENMASK(1, 0)
 #define MLXPLAT_CPLD_FAN_MASK  GENMASK(3, 0)
 #define MLXPLAT_CPLD_FAN_NG_MASK   GENMASK(5, 0)
+#define MLXPLAT_CPLD_LED_LO_NIBBLE_MASKGENMASK(7, 4)
+#define MLXPLAT_CPLD_LED_HI_NIBBLE_MASKGENMASK(3, 0)
 
 /* Default I2C parent bus number */
 #define MLXPLAT_CPLD_PHYS_ADAPTER_DEF_NR   1
@@ -114,11 +121,13 @@
  * @pdev_i2c - i2c controller platform device
  * @pdev_mux - array of mux platform devices
  * @pdev_hotplug - hotplug platform devices
+ * @pdev_led - led platform devices
  */
 struct mlxplat_priv {
struct platform_device *pdev_i2c;
struct platform_device *pdev_mux[MLXPLAT_CPLD_LPC_MUX_DEVS];
struct platform_device *pdev_hotplug;
+   struct platform_device *pdev_led;
 };
 
 /* Regions for LPC I2C controller and LPC base register space */
@@ -592,9 +601,227 @@ struct mlxreg_core_hotplug_platform_data 
mlxplat_mlxcpld_default_ng_data = {
.mask_low = MLXPLAT_CPLD_LOW_AGGR_MASK_LOW,
 };
 
+/* Platform led default data */
+static struct mlxreg_core_data mlxplat_mlxcpld_default_led_data[] = {
+   {
+   .label = "status:green",
+   .reg = MLXPLAT_CPLD_LPC_REG_LED1_OFFSET,
+   .mask = MLXPLAT_CPLD_LED_LO_NIBBLE_MASK,
+   },
+   {
+   .label = "status:red",
+   .reg = MLXPLAT_CPLD_LPC_REG_LED1_OFFSET,
+   .mask = MLXPLAT_CPLD_LED_LO_NIBBLE_MASK
+   },
+   {
+   .label = "psu:green",
+   .reg = MLXPLAT_CPLD_LPC_REG_LED1_OFFSET,
+   .mask = MLXPLAT_CPLD_LED_HI_NIBBLE_MASK,
+   },
+   {
+   .label = "psu:red",
+   .reg = MLXPLAT_CPLD_LPC_REG_LED1_OFFSET,
+   .mask = MLXPLAT_CPLD_LED_HI_NIBBLE_MASK,
+   },
+   {
+   .label = "fan1:green",
+   .reg = MLXPLAT_CPLD_LPC_REG_LED2_OFFSET,
+   .mask = MLXPLAT_CPLD_LED_LO_NIBBLE_MASK,
+   },
+   {
+   .label = "fan1:red",
+   .reg = MLXPLAT_CPLD_LPC_REG_LED2_OFFSET,
+   .mask = MLXPLAT_CPLD_LED_LO_NIBBLE_MASK,
+   },
+   {
+   .label = "fan2:green",
+   .reg = MLXPLAT_CPLD_LPC_REG_LED2_OFFSET,
+   .mask = MLXPLAT_CPLD_LED_HI_NIBBLE_MASK,
+   },
+   {
+   .label = "fan2:red",
+   .reg = MLXPLAT_CPLD_LPC_REG_LED2_OFFSET,
+   .mask = MLXPLAT_CPLD_LED_HI_NIBBLE_MASK,
+   },
+   {
+   .label = "fan3:green",
+   .reg = MLXPLAT_CPLD_LPC_REG_LED3_OFFSET,
+   .mask = MLXPLAT_CPLD_LED_LO_NIBBLE_MASK,
+   },
+   {
+   .label = "fan3:red",
+   .reg = MLXPLAT_CPLD_LPC_REG_LED3_OFFSET,
+   .mask = MLXPLAT_CPLD_LED_LO_NIBBLE_MASK,
+   },
+   {
+   .label = "fan4:green",
+   .reg = MLXPLAT_CPLD_LPC_REG_LED3_OFFSET,
+   .mask = MLXPLAT_CPLD_LED_HI_NIBBLE_MASK,
+   },
+   {
+   .label = "fan4:red",
+   .reg = MLXPLAT_CPLD_LPC_REG_LED3_OFFSET,
+   .mask = MLXPLAT_CPLD_LED_HI_NIBBLE_MASK,
+   },
+};
+
+static struct mlxreg_core_platform_data mlxplat_default_led_data = {
+   .data = mlxplat_mlxcpld_default_led_data,
+   .counter = ARRAY_SIZE(mlxplat_mlxcpld_default_led_data),
+};
+
+/* Platform led MSN21xx system family data */
+static struct mlxreg_core_data mlxplat_mlxcpld_msn21xx_led_data[] = {
+   {
+   .label = "status:green",
+ 

[PATCH v2 6/7] platform/mellanox: Introduce support for Mellanox register access driver

[Vadim Pasternak]

Introduce new Mellanox platform driver to allow access to Mellanox
programmable device register space trough sysfs interface.
The driver purpose is to provide sysfs interface for user space for the
registers essential for system control and monitoring.
The sets of registers for sysfs access are supposed to be defined per
system type bases and include the registers related to system resets
operation, system reset causes monitoring and some kinds of mux selection.

Signed-off-by: Vadim Pasternak 
---
v1->v2:
 Changed added by Vadim:
 - Change ---help--- to help in Kconfig, according to new requirements;
---
 drivers/platform/mellanox/Kconfig |  11 ++
 drivers/platform/mellanox/Makefile|   1 +
 drivers/platform/mellanox/mlxreg-io.c | 221 ++
 3 files changed, 233 insertions(+)
 create mode 100644 drivers/platform/mellanox/mlxreg-io.c

diff --git a/drivers/platform/mellanox/Kconfig 
b/drivers/platform/mellanox/Kconfig
index 591bccd..ddfae9fc 100644
--- a/drivers/platform/mellanox/Kconfig
+++ b/drivers/platform/mellanox/Kconfig
@@ -23,4 +23,15 @@ config MLXREG_HOTPLUG
  This driver handles hot-plug events for the power suppliers, power
  cables and fans on the wide range Mellanox IB and Ethernet systems.
 
+config MLXREG_IO
+   tristate "Mellanox platform register access driver support"
+   depends on REGMAP
+   depends on HWMON
+   help
+ This driver allows access to Mellanox programmable device register
+ space trough sysfs interface. The sets of registers for sysfs access
+ are defined per system type bases and includes the registers related
+ to system resets operation, system reset causes monitoring and some
+ kinds of mux selection.
+
 endif # MELLANOX_PLATFORM
diff --git a/drivers/platform/mellanox/Makefile 
b/drivers/platform/mellanox/Makefile
index 7c8385e..57074d9c 100644
--- a/drivers/platform/mellanox/Makefile
+++ b/drivers/platform/mellanox/Makefile
@@ -4,3 +4,4 @@
 # Mellanox Platform-Specific Drivers
 #
 obj-$(CONFIG_MLXREG_HOTPLUG)   += mlxreg-hotplug.o
+obj-$(CONFIG_MLXREG_IO) += mlxreg-io.o
diff --git a/drivers/platform/mellanox/mlxreg-io.c 
b/drivers/platform/mellanox/mlxreg-io.c
new file mode 100644
index 000..f573b65
--- /dev/null
+++ b/drivers/platform/mellanox/mlxreg-io.c
@@ -0,0 +1,221 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * Mellanox register access driver
+ *
+ * Copyright (C) 2018 Mellanox Technologies
+ * Copyright (C) 2018 Vadim Pasternak 
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+/* Attribute parameters. */
+#define MLXREG_IO_ATT_SIZE 10
+#define MLXREG_IO_ATT_NUM  48
+
+/**
+ * struct mlxreg_io_priv_data - driver's private data:
+ *
+ * @pdev: platform device;
+ * @pdata: platform data;
+ * @hwmon: hwmon device;
+ * @mlxreg_io_attr: sysfs attributes array;
+ * @mlxreg_io_dev_attr: sysfs sensor device attribute array;
+ * @group: sysfs attribute group;
+ * @groups: list of sysfs attribute group for hwmon registration;
+ */
+struct mlxreg_io_priv_data {
+   struct platform_device *pdev;
+   struct mlxreg_core_platform_data *pdata;
+   struct device *hwmon;
+   struct attribute *mlxreg_io_attr[MLXREG_IO_ATT_NUM + 1];
+   struct sensor_device_attribute mlxreg_io_dev_attr[MLXREG_IO_ATT_NUM];
+   struct attribute_group group;
+   const struct attribute_group *groups[2];
+};
+
+static ssize_t
+mlxreg_io_attr_show(struct device *dev, struct device_attribute *attr,
+   char *buf)
+{
+   struct mlxreg_io_priv_data *priv = dev_get_drvdata(dev);
+   int index = to_sensor_dev_attr(attr)->index;
+   struct mlxreg_core_data *data = priv->pdata->data + index;
+   u32 regval = 0;
+   int ret;
+
+   ret = regmap_read(priv->pdata->regmap, data->reg, );
+   if (ret)
+   goto access_error;
+
+   if (!data->bit)
+   regval = !!(regval & ~data->mask);
+
+   return sprintf(buf, "%u\n", regval);
+
+access_error:
+   return ret;
+}
+
+static ssize_t
+mlxreg_io_attr_store(struct device *dev, struct device_attribute *attr,
+const char *buf, size_t len)
+{
+   struct mlxreg_io_priv_data *priv = dev_get_drvdata(dev);
+   int index = to_sensor_dev_attr(attr)->index;
+   struct mlxreg_core_data *data = priv->pdata->data + index;
+   u32 val, regval;
+   int ret;
+
+   ret = kstrtou32(buf, MLXREG_IO_ATT_SIZE, );
+   if (ret)
+   return ret;
+
+   ret = regmap_read(priv->pdata->regmap, data->reg, );
+   if (ret)
+   goto access_error;
+
+   regval &= data->mask;
+
+   val = !!val;
+   if (val)
+   regval |= ~data->mask;
+   else
+   regval &= data->mask;
+
+   ret = regmap_write(priv->pdata->regmap, data->reg, regval);
+   if (ret)
+  

[PATCH v2 3/7] platform/mellanox: mlxreg-hotplug: add extra cycle for hotplug work queue

[Vadim Pasternak]

Add extra cycle for hotplug work queue to handle the case when a signal is
It adds missed logic for signal acknowledge, by adding an extra run for
received, but no specific signal assertion is detected. Such case
theoretically can happen for example in case several units are removed or
inserted at the same time. In this situation acknowledge for some signal
can be missed at signal top aggreagation status level. The extra run will
allow to handler to acknowledge the missed signal.

The interrupt handling flow performs the next steps:
(1)
Enter mlxreg_hotplug_work_handler due to signal assertion.
Aggregation status register is changed for example from 0xff to 0xfd
(event signal group related to bit 1).
(2)
Mask aggregation interrupts, read aggregation status register and save it
(0xfd) in aggr_cache, then traverse down to handle signal from groups
related to the changed bit.
(3)
Read and mask group related signal.
Acknowledge and unmask group related signal (acknowledge should clear
aggregation status register from 0xfd back to 0xff).
(4)
Re-schedule work queue for the immediate execution.
(5)
Enter mlxreg_hotplug_work_handler due to re-scheduling.
Aggregation status is changed from previous 0xfd to 0xff.
Go over steps (2) - (5) and in case no new signal assertion
is detected - unmask aggregation interrupts.

The possible race could happen in case new signal from the same group is
asserted after step (3) and prior step (5). In such case aggregation
status will change back from 0xff to 0xfd and the value read from the
aggregation status register will be the same as a value saved in
aggr_cache. As a result the handler will not traverse down and signal
will stay unhandled.

Example of faulty flow:
The signal routing flow is as following (f.e. for of FANi removing):
 - FAN status and event registers related bit is changed;
 -- intermediate aggregation status register is changed;
 --- top aggregation status register is changed;
  interrupt routed to CPU and interrupt handler is invoked.

When interrupt handler is invoked it follows the next simple logic (f.e
FAN3 is removed):
 (a1) mask top aggregation interrupt mask register;
 (a2) read top aggregation interrupt status register and test to which
  underling group belongs a signal (FANs in this case and is changed
  from 0xff to 0xfb and 0xfb is saved as a last status value);
   (b1) mask FANs interrupt mask register;
   (b2) read FANs status register and test which FAN has been changed
FAN3 in this example);
 (c1) perform relevant action;
  <--- (FAN2 is removed at this point)
   (b3) clear FANs interrupt event register to acknowledge FAN3 signal;
   (b4) unmask FANs interrupt mask register
 (a3) unmask top aggregation interrupt mask register;

 An interrupt handler is invoked, since FAN2 interrupt is not acknowledge.
 It should set top aggregation interrupt status register bit 6 (0xfb).
 In step (a2)
 (a2) read top aggregation interrupt and comparing it with saved value
  does not show change (same 0xfb) and after (a2) execution jumps to
  (a3) and signal leaved unhandled

The fix will enforce handler to traverse down in case the signal is
received, but signal assertion is not detected.

Fixes: 07b89c2b2a5e ("platform/x86: Introduce support for Mellanox hotplug 
driver")
Signed-off-by: Vadim Pasternak 
---
V1->v2:
 Comments pointed out by Darren:
 - Modify commit message;
 - Remove redundant check of aggr_asserted;
 - Change bug fix reference from 1f976f6978bf, which just relocated driver
   to 07b89c2b2a5e, which was initial driver commit.
---
 drivers/platform/mellanox/mlxreg-hotplug.c | 48 +++---
 1 file changed, 31 insertions(+), 17 deletions(-)

diff --git a/drivers/platform/mellanox/mlxreg-hotplug.c 
b/drivers/platform/mellanox/mlxreg-hotplug.c
index b56953a..922913b 100644
--- a/drivers/platform/mellanox/mlxreg-hotplug.c
+++ b/drivers/platform/mellanox/mlxreg-hotplug.c
@@ -55,6 +55,7 @@
 #define MLXREG_HOTPLUG_RST_CNTR3
 
 #define MLXREG_HOTPLUG_ATTRS_MAX   24
+#define MLXREG_HOTPLUG_NOT_ASSERT  3
 
 /**
  * struct mlxreg_hotplug_priv_data - platform private data:
@@ -74,6 +75,7 @@
  * @mask: top aggregation interrupt common mask;
  * @aggr_cache: last value of aggregation register status;
  * @after_probe: flag indication probing completion;
+ * @not_asserted: number of entries in workqueue with no signal assertion;
  */
 struct mlxreg_hotplug_priv_data {
int irq;
@@ -93,6 +95,7 @@ struct mlxreg_hotplug_priv_data {
u32 mask;
u32 aggr_cache;
bool after_probe;
+   u8 not_asserted;
 };
 
 static int mlxreg_hotplug_device_create(struct mlxreg_hotplug_priv_data *priv,
@@ -410,6 +413,18 @@ static void mlxreg_hotplug_work_handler(struct work_struct 
*work)
aggr_asserted = priv->aggr_cache ^ regval;
priv->aggr_cache = regval;
 
+   /*
+* Handler is invoked, but no 

[PATCH v2 6/7] platform/mellanox: Introduce support for Mellanox register access driver

[Vadim Pasternak]

Introduce new Mellanox platform driver to allow access to Mellanox
programmable device register space trough sysfs interface.
The driver purpose is to provide sysfs interface for user space for the
registers essential for system control and monitoring.
The sets of registers for sysfs access are supposed to be defined per
system type bases and include the registers related to system resets
operation, system reset causes monitoring and some kinds of mux selection.

Signed-off-by: Vadim Pasternak 
---
v1->v2:
 Changed added by Vadim:
 - Change ---help--- to help in Kconfig, according to new requirements;
---
 drivers/platform/mellanox/Kconfig |  11 ++
 drivers/platform/mellanox/Makefile|   1 +
 drivers/platform/mellanox/mlxreg-io.c | 221 ++
 3 files changed, 233 insertions(+)
 create mode 100644 drivers/platform/mellanox/mlxreg-io.c

diff --git a/drivers/platform/mellanox/Kconfig 
b/drivers/platform/mellanox/Kconfig
index 591bccd..ddfae9fc 100644
--- a/drivers/platform/mellanox/Kconfig
+++ b/drivers/platform/mellanox/Kconfig
@@ -23,4 +23,15 @@ config MLXREG_HOTPLUG
  This driver handles hot-plug events for the power suppliers, power
  cables and fans on the wide range Mellanox IB and Ethernet systems.
 
+config MLXREG_IO
+   tristate "Mellanox platform register access driver support"
+   depends on REGMAP
+   depends on HWMON
+   help
+ This driver allows access to Mellanox programmable device register
+ space trough sysfs interface. The sets of registers for sysfs access
+ are defined per system type bases and includes the registers related
+ to system resets operation, system reset causes monitoring and some
+ kinds of mux selection.
+
 endif # MELLANOX_PLATFORM
diff --git a/drivers/platform/mellanox/Makefile 
b/drivers/platform/mellanox/Makefile
index 7c8385e..57074d9c 100644
--- a/drivers/platform/mellanox/Makefile
+++ b/drivers/platform/mellanox/Makefile
@@ -4,3 +4,4 @@
 # Mellanox Platform-Specific Drivers
 #
 obj-$(CONFIG_MLXREG_HOTPLUG)   += mlxreg-hotplug.o
+obj-$(CONFIG_MLXREG_IO) += mlxreg-io.o
diff --git a/drivers/platform/mellanox/mlxreg-io.c 
b/drivers/platform/mellanox/mlxreg-io.c
new file mode 100644
index 000..f573b65
--- /dev/null
+++ b/drivers/platform/mellanox/mlxreg-io.c
@@ -0,0 +1,221 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * Mellanox register access driver
+ *
+ * Copyright (C) 2018 Mellanox Technologies
+ * Copyright (C) 2018 Vadim Pasternak 
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+/* Attribute parameters. */
+#define MLXREG_IO_ATT_SIZE 10
+#define MLXREG_IO_ATT_NUM  48
+
+/**
+ * struct mlxreg_io_priv_data - driver's private data:
+ *
+ * @pdev: platform device;
+ * @pdata: platform data;
+ * @hwmon: hwmon device;
+ * @mlxreg_io_attr: sysfs attributes array;
+ * @mlxreg_io_dev_attr: sysfs sensor device attribute array;
+ * @group: sysfs attribute group;
+ * @groups: list of sysfs attribute group for hwmon registration;
+ */
+struct mlxreg_io_priv_data {
+   struct platform_device *pdev;
+   struct mlxreg_core_platform_data *pdata;
+   struct device *hwmon;
+   struct attribute *mlxreg_io_attr[MLXREG_IO_ATT_NUM + 1];
+   struct sensor_device_attribute mlxreg_io_dev_attr[MLXREG_IO_ATT_NUM];
+   struct attribute_group group;
+   const struct attribute_group *groups[2];
+};
+
+static ssize_t
+mlxreg_io_attr_show(struct device *dev, struct device_attribute *attr,
+   char *buf)
+{
+   struct mlxreg_io_priv_data *priv = dev_get_drvdata(dev);
+   int index = to_sensor_dev_attr(attr)->index;
+   struct mlxreg_core_data *data = priv->pdata->data + index;
+   u32 regval = 0;
+   int ret;
+
+   ret = regmap_read(priv->pdata->regmap, data->reg, );
+   if (ret)
+   goto access_error;
+
+   if (!data->bit)
+   regval = !!(regval & ~data->mask);
+
+   return sprintf(buf, "%u\n", regval);
+
+access_error:
+   return ret;
+}
+
+static ssize_t
+mlxreg_io_attr_store(struct device *dev, struct device_attribute *attr,
+const char *buf, size_t len)
+{
+   struct mlxreg_io_priv_data *priv = dev_get_drvdata(dev);
+   int index = to_sensor_dev_attr(attr)->index;
+   struct mlxreg_core_data *data = priv->pdata->data + index;
+   u32 val, regval;
+   int ret;
+
+   ret = kstrtou32(buf, MLXREG_IO_ATT_SIZE, );
+   if (ret)
+   return ret;
+
+   ret = regmap_read(priv->pdata->regmap, data->reg, );
+   if (ret)
+   goto access_error;
+
+   regval &= data->mask;
+
+   val = !!val;
+   if (val)
+   regval |= ~data->mask;
+   else
+   regval &= data->mask;
+
+   ret = regmap_write(priv->pdata->regmap, data->reg, regval);
+   if (ret)
+   goto access_error;
+
+   return len;

[PATCH v2 3/7] platform/mellanox: mlxreg-hotplug: add extra cycle for hotplug work queue

[Vadim Pasternak]

Add extra cycle for hotplug work queue to handle the case when a signal is
It adds missed logic for signal acknowledge, by adding an extra run for
received, but no specific signal assertion is detected. Such case
theoretically can happen for example in case several units are removed or
inserted at the same time. In this situation acknowledge for some signal
can be missed at signal top aggreagation status level. The extra run will
allow to handler to acknowledge the missed signal.

The interrupt handling flow performs the next steps:
(1)
Enter mlxreg_hotplug_work_handler due to signal assertion.
Aggregation status register is changed for example from 0xff to 0xfd
(event signal group related to bit 1).
(2)
Mask aggregation interrupts, read aggregation status register and save it
(0xfd) in aggr_cache, then traverse down to handle signal from groups
related to the changed bit.
(3)
Read and mask group related signal.
Acknowledge and unmask group related signal (acknowledge should clear
aggregation status register from 0xfd back to 0xff).
(4)
Re-schedule work queue for the immediate execution.
(5)
Enter mlxreg_hotplug_work_handler due to re-scheduling.
Aggregation status is changed from previous 0xfd to 0xff.
Go over steps (2) - (5) and in case no new signal assertion
is detected - unmask aggregation interrupts.

The possible race could happen in case new signal from the same group is
asserted after step (3) and prior step (5). In such case aggregation
status will change back from 0xff to 0xfd and the value read from the
aggregation status register will be the same as a value saved in
aggr_cache. As a result the handler will not traverse down and signal
will stay unhandled.

Example of faulty flow:
The signal routing flow is as following (f.e. for of FANi removing):
 - FAN status and event registers related bit is changed;
 -- intermediate aggregation status register is changed;
 --- top aggregation status register is changed;
  interrupt routed to CPU and interrupt handler is invoked.

When interrupt handler is invoked it follows the next simple logic (f.e
FAN3 is removed):
 (a1) mask top aggregation interrupt mask register;
 (a2) read top aggregation interrupt status register and test to which
  underling group belongs a signal (FANs in this case and is changed
  from 0xff to 0xfb and 0xfb is saved as a last status value);
   (b1) mask FANs interrupt mask register;
   (b2) read FANs status register and test which FAN has been changed
FAN3 in this example);
 (c1) perform relevant action;
  <--- (FAN2 is removed at this point)
   (b3) clear FANs interrupt event register to acknowledge FAN3 signal;
   (b4) unmask FANs interrupt mask register
 (a3) unmask top aggregation interrupt mask register;

 An interrupt handler is invoked, since FAN2 interrupt is not acknowledge.
 It should set top aggregation interrupt status register bit 6 (0xfb).
 In step (a2)
 (a2) read top aggregation interrupt and comparing it with saved value
  does not show change (same 0xfb) and after (a2) execution jumps to
  (a3) and signal leaved unhandled

The fix will enforce handler to traverse down in case the signal is
received, but signal assertion is not detected.

Fixes: 07b89c2b2a5e ("platform/x86: Introduce support for Mellanox hotplug 
driver")
Signed-off-by: Vadim Pasternak 
---
V1->v2:
 Comments pointed out by Darren:
 - Modify commit message;
 - Remove redundant check of aggr_asserted;
 - Change bug fix reference from 1f976f6978bf, which just relocated driver
   to 07b89c2b2a5e, which was initial driver commit.
---
 drivers/platform/mellanox/mlxreg-hotplug.c | 48 +++---
 1 file changed, 31 insertions(+), 17 deletions(-)

diff --git a/drivers/platform/mellanox/mlxreg-hotplug.c 
b/drivers/platform/mellanox/mlxreg-hotplug.c
index b56953a..922913b 100644
--- a/drivers/platform/mellanox/mlxreg-hotplug.c
+++ b/drivers/platform/mellanox/mlxreg-hotplug.c
@@ -55,6 +55,7 @@
 #define MLXREG_HOTPLUG_RST_CNTR3
 
 #define MLXREG_HOTPLUG_ATTRS_MAX   24
+#define MLXREG_HOTPLUG_NOT_ASSERT  3
 
 /**
  * struct mlxreg_hotplug_priv_data - platform private data:
@@ -74,6 +75,7 @@
  * @mask: top aggregation interrupt common mask;
  * @aggr_cache: last value of aggregation register status;
  * @after_probe: flag indication probing completion;
+ * @not_asserted: number of entries in workqueue with no signal assertion;
  */
 struct mlxreg_hotplug_priv_data {
int irq;
@@ -93,6 +95,7 @@ struct mlxreg_hotplug_priv_data {
u32 mask;
u32 aggr_cache;
bool after_probe;
+   u8 not_asserted;
 };
 
 static int mlxreg_hotplug_device_create(struct mlxreg_hotplug_priv_data *priv,
@@ -410,6 +413,18 @@ static void mlxreg_hotplug_work_handler(struct work_struct 
*work)
aggr_asserted = priv->aggr_cache ^ regval;
priv->aggr_cache = regval;
 
+   /*
+* Handler is invoked, but no assertion is detected 

Re: Proof-of-concept: better(?) page-table manipulation API

[Andy Lutomirski]

On Tue, Apr 24, 2018 at 8:44 AM Kirill A. Shutemov <
kirill.shute...@linux.intel.com> wrote:

> Hi everybody,

> I've proposed to talk about page able manipulation API on the LSF/MM'2018,
> so I need something material to talk about.


I gave it a quick read.  I like the concept a lot, and I have a few
comments.

> +/*
> + * How manu bottom level we account to mm->pgtables_bytes
> + */
> +#define PT_ACCOUNT_LVLS 3
> +
> +struct pt_ptr {
> +   unsigned long *ptr;
> +   int lvl;
> +};
> +

I think you've inherited something that I consider to be a defect in the
old code: you're conflating page *tables* with page table *entries*.  Your
'struct pt_ptr' sounds like a pointer to an entire page table, but AFAICT
you're using it to point to a specific entry within a table.  I think that
both the new core code and the code that uses it would be clearer and less
error prone if you made the distinction explicit.  I can think of two clean
ways to do it:

1. Add a struct pt_entry_ptr, and make it so that get_ptv(), etc take a
pt_entry_ptr instead of a pt_ptr.  Add a helper to find a pt_entry_ptr
given a pt_ptr and either an index or an address.

2. Don't allow pointers to page table entries at all.  Instead, get_ptv()
would take an address or an index parameter.

Also, what does lvl == 0 mean?  Is it the top or the bottom?  I think a
comment would be helpful.

> +/*
> + * When walking page tables, get the address of the next boundary,
> + * or the end address of the range if that comes earlier.  Although no
> + * vma end wraps to 0, rounded up __boundary may wrap to 0 throughout.
> + */

I read this comment twice, and I still don't get it.  Can you clarify what
this function does and why you would use it?

> +/* Operations on page table pointers */
> +
> +/* Initialize ptp_t with pointer to top page table level. */
> +static inline ptp_t ptp_init(struct mm_struct *mm)
> +{
> +   struct pt_ptr ptp ={
> +   .ptr = (unsigned long *)mm->pgd,
> +   .lvl = PT_TOP_LEVEL,
> +   };
> +
> +   return ptp;
> +}
> +

On some architectures, there are multiple page table roots.  For example,
ARM64 has a root for the kernel half of the address space and a root for
the user half (at least -- I don't fully understand it).  x86 PAE sort-of
has four roots.  Would it make sense to expose this in the API for real?
For example, ptp_init(mm) could be replaced with ptp_init(mm, addr).  This
would make it a bit cleaner to handle an separate user and kernel tables.
  (As it stands, what is supposed to happen on ARM if you do
ptp_init(something that isn't init_mm) and then walk it to look for a
kernel address?)

Also, ptp_init() seems oddly named for me.  ptp_get_root_for_mm(),
perhaps?  There could also be ptp_get_kernel_root() to get the root for the
init_mm's tables.

> +static inline void ptp_walk(ptp_t *ptp, unsigned long addr)
> +{
> +   ptp->ptr = (unsigned long *)ptp_page_vaddr(ptp);
> +   ptp->ptr += __pt_index(addr, --ptp->lvl);
> +}

Can you add a comment that says what this function does?  Why does it not
change the level?

> +
> +static void ptp_free(struct mm_struct *mm, ptv_t ptv)
> +{
> +   if (ptv.lvl < PT_SPLIT_LOCK_LVLS)
> +   ptlock_free(pfn_to_page(ptv_pfn(ptv)));
> +}
> +

As it stands, this is a function that seems easy easy to misuse given the
confusion between page tables and page table entries.


Finally, a general comment.  Actually fully implementing this the way
you've done it seems like a giant mess given that you need to support all
architectures.  But couldn't you implement the new API as a wrapper around
the old API so you automatically get all architectures?

Re: Proof-of-concept: better(?) page-table manipulation API

[Andy Lutomirski]

On Tue, Apr 24, 2018 at 8:44 AM Kirill A. Shutemov <
kirill.shute...@linux.intel.com> wrote:

> Hi everybody,

> I've proposed to talk about page able manipulation API on the LSF/MM'2018,
> so I need something material to talk about.


I gave it a quick read.  I like the concept a lot, and I have a few
comments.

> +/*
> + * How manu bottom level we account to mm->pgtables_bytes
> + */
> +#define PT_ACCOUNT_LVLS 3
> +
> +struct pt_ptr {
> +   unsigned long *ptr;
> +   int lvl;
> +};
> +

I think you've inherited something that I consider to be a defect in the
old code: you're conflating page *tables* with page table *entries*.  Your
'struct pt_ptr' sounds like a pointer to an entire page table, but AFAICT
you're using it to point to a specific entry within a table.  I think that
both the new core code and the code that uses it would be clearer and less
error prone if you made the distinction explicit.  I can think of two clean
ways to do it:

1. Add a struct pt_entry_ptr, and make it so that get_ptv(), etc take a
pt_entry_ptr instead of a pt_ptr.  Add a helper to find a pt_entry_ptr
given a pt_ptr and either an index or an address.

2. Don't allow pointers to page table entries at all.  Instead, get_ptv()
would take an address or an index parameter.

Also, what does lvl == 0 mean?  Is it the top or the bottom?  I think a
comment would be helpful.

> +/*
> + * When walking page tables, get the address of the next boundary,
> + * or the end address of the range if that comes earlier.  Although no
> + * vma end wraps to 0, rounded up __boundary may wrap to 0 throughout.
> + */

I read this comment twice, and I still don't get it.  Can you clarify what
this function does and why you would use it?

> +/* Operations on page table pointers */
> +
> +/* Initialize ptp_t with pointer to top page table level. */
> +static inline ptp_t ptp_init(struct mm_struct *mm)
> +{
> +   struct pt_ptr ptp ={
> +   .ptr = (unsigned long *)mm->pgd,
> +   .lvl = PT_TOP_LEVEL,
> +   };
> +
> +   return ptp;
> +}
> +

On some architectures, there are multiple page table roots.  For example,
ARM64 has a root for the kernel half of the address space and a root for
the user half (at least -- I don't fully understand it).  x86 PAE sort-of
has four roots.  Would it make sense to expose this in the API for real?
For example, ptp_init(mm) could be replaced with ptp_init(mm, addr).  This
would make it a bit cleaner to handle an separate user and kernel tables.
  (As it stands, what is supposed to happen on ARM if you do
ptp_init(something that isn't init_mm) and then walk it to look for a
kernel address?)

Also, ptp_init() seems oddly named for me.  ptp_get_root_for_mm(),
perhaps?  There could also be ptp_get_kernel_root() to get the root for the
init_mm's tables.

> +static inline void ptp_walk(ptp_t *ptp, unsigned long addr)
> +{
> +   ptp->ptr = (unsigned long *)ptp_page_vaddr(ptp);
> +   ptp->ptr += __pt_index(addr, --ptp->lvl);
> +}

Can you add a comment that says what this function does?  Why does it not
change the level?

> +
> +static void ptp_free(struct mm_struct *mm, ptv_t ptv)
> +{
> +   if (ptv.lvl < PT_SPLIT_LOCK_LVLS)
> +   ptlock_free(pfn_to_page(ptv_pfn(ptv)));
> +}
> +

As it stands, this is a function that seems easy easy to misuse given the
confusion between page tables and page table entries.


Finally, a general comment.  Actually fully implementing this the way
you've done it seems like a giant mess given that you need to support all
architectures.  But couldn't you implement the new API as a wrapper around
the old API so you automatically get all architectures?

Re: [PATCH v3] ASoC: da7219: read fmw property to get mclk for non-dts systems

[Agrawal, Akshu]

On 5/4/2018 2:45 PM, Adam Thomson wrote:
> On 03 May 2018 08:59, Akshu Agrawal wrote:
> 
>> Non-dts based systems can use ACPI DSDT to pass on the mclk
>> to da7219.
>> This enables da7219 mclk to be linked to system clock.
>> Enable/Disable of the mclk is already handled in the codec so
>> platform drivers don't have to explicitly do handling of mclk.
>>
>> Signed-off-by: Akshu Agrawal 
>> ---
>> v2: Fixed kbuild error
>> v3: Add corresponding clk_put for clk_get
>>  include/sound/da7219.h|  2 ++
>>  sound/soc/codecs/da7219.c | 10 +-
>>  2 files changed, 11 insertions(+), 1 deletion(-)
>>
>> diff --git a/include/sound/da7219.h b/include/sound/da7219.h
>> index 1bfcb16..df7ddf4 100644
>> --- a/include/sound/da7219.h
>> +++ b/include/sound/da7219.h
>> @@ -38,6 +38,8 @@ struct da7219_pdata {
>>
>>  const char *dai_clks_name;
>>
>> +const char *mclk_name;
>> +
>>  /* Mic */
>>  enum da7219_micbias_voltage micbias_lvl;
>>  enum da7219_mic_amp_in_sel mic_amp_in_sel;
>> diff --git a/sound/soc/codecs/da7219.c b/sound/soc/codecs/da7219.c
>> index 980a6a8..ecd46fc 100644
>> --- a/sound/soc/codecs/da7219.c
>> +++ b/sound/soc/codecs/da7219.c
>> @@ -1624,6 +1624,8 @@ static struct da7219_pdata *da7219_fw_to_pdata(struct
>> snd_soc_component *compone
>>  dev_warn(dev, "Using default clk name: %s\n",
>>   pdata->dai_clks_name);
>>
>> +device_property_read_string(dev, "dlg,mclk-name", >mclk_name);
>> +
> 
> Personally am still not keen on this. To me the use of a device_property_*
> function suggests the same property resides in both DT and ACPI, but here 
> we're
> only using this for the ACPI case. DT has no want or need for this. I still 
> feel
> we should look at something more generic in the clock framework, although I do
> agree with Mark that this should be properly specced.
> 

I am not an expert in field of ACPI, IMO forming a Spec and changing
ACPI to have DT like clock framework is good to have but a bigger change
which should be taken up later.

The current code of handling of mclk in the driver is usable only by DT.
The device_property (though ACPI specific) makes this code, a common
code for DT and ACPI based devices.

https://www.kernel.org/doc/Documentation/acpi/DSD-properties-rules.txt
"Still, for the sake of code re-use, it may make sense to provide as
much of the configuration data as possible in the form of device
properties and complement that with an ACPI-specific mechanism suitable
for the use case at hand.."

Thanks,
Akshu

Re: [PATCH v3] ASoC: da7219: read fmw property to get mclk for non-dts systems

[Agrawal, Akshu]

On 5/4/2018 2:45 PM, Adam Thomson wrote:
> On 03 May 2018 08:59, Akshu Agrawal wrote:
> 
>> Non-dts based systems can use ACPI DSDT to pass on the mclk
>> to da7219.
>> This enables da7219 mclk to be linked to system clock.
>> Enable/Disable of the mclk is already handled in the codec so
>> platform drivers don't have to explicitly do handling of mclk.
>>
>> Signed-off-by: Akshu Agrawal 
>> ---
>> v2: Fixed kbuild error
>> v3: Add corresponding clk_put for clk_get
>>  include/sound/da7219.h|  2 ++
>>  sound/soc/codecs/da7219.c | 10 +-
>>  2 files changed, 11 insertions(+), 1 deletion(-)
>>
>> diff --git a/include/sound/da7219.h b/include/sound/da7219.h
>> index 1bfcb16..df7ddf4 100644
>> --- a/include/sound/da7219.h
>> +++ b/include/sound/da7219.h
>> @@ -38,6 +38,8 @@ struct da7219_pdata {
>>
>>  const char *dai_clks_name;
>>
>> +const char *mclk_name;
>> +
>>  /* Mic */
>>  enum da7219_micbias_voltage micbias_lvl;
>>  enum da7219_mic_amp_in_sel mic_amp_in_sel;
>> diff --git a/sound/soc/codecs/da7219.c b/sound/soc/codecs/da7219.c
>> index 980a6a8..ecd46fc 100644
>> --- a/sound/soc/codecs/da7219.c
>> +++ b/sound/soc/codecs/da7219.c
>> @@ -1624,6 +1624,8 @@ static struct da7219_pdata *da7219_fw_to_pdata(struct
>> snd_soc_component *compone
>>  dev_warn(dev, "Using default clk name: %s\n",
>>   pdata->dai_clks_name);
>>
>> +device_property_read_string(dev, "dlg,mclk-name", >mclk_name);
>> +
> 
> Personally am still not keen on this. To me the use of a device_property_*
> function suggests the same property resides in both DT and ACPI, but here 
> we're
> only using this for the ACPI case. DT has no want or need for this. I still 
> feel
> we should look at something more generic in the clock framework, although I do
> agree with Mark that this should be properly specced.
> 

I am not an expert in field of ACPI, IMO forming a Spec and changing
ACPI to have DT like clock framework is good to have but a bigger change
which should be taken up later.

The current code of handling of mclk in the driver is usable only by DT.
The device_property (though ACPI specific) makes this code, a common
code for DT and ACPI based devices.

https://www.kernel.org/doc/Documentation/acpi/DSD-properties-rules.txt
"Still, for the sake of code re-use, it may make sense to provide as
much of the configuration data as possible in the form of device
properties and complement that with an ACPI-specific mechanism suitable
for the use case at hand.."

Thanks,
Akshu

Re: [PATCH v9 02/11] kexec_file: make kexec_image_post_load_cleanup_default() global

[AKASHI Takahiro]

On Tue, May 01, 2018 at 06:46:04PM +0100, James Morse wrote:
> Hi Akashi,
> 
> On 25/04/18 07:26, AKASHI Takahiro wrote:
> > Change this function from static to global so that arm64 can implement
> > its own arch_kimage_file_post_load_cleanup() later using
> > kexec_image_post_load_cleanup_default().
> 
> Do we need to call kexec_image_post_load_cleanup_default()? All it does is 
> call
> the image-type fops->cleanup(), which you don't implement in this series.
> 
> Is this just-in-case someone adds cleanup() later and is surprised only the
> arch-level helper is called?

Yes, we want not to miss two possibilities:
- some common clean-up code is added to kexec_image_post_load_cleanup_default()
- some format(i.e. Image)-specific clean-up code is added to fops->cleanup()

-Takahiro AKASHI

> 
> 
> Thanks,
> 
> James

Re: [PATCH v9 02/11] kexec_file: make kexec_image_post_load_cleanup_default() global

[AKASHI Takahiro]

On Tue, May 01, 2018 at 06:46:04PM +0100, James Morse wrote:
> Hi Akashi,
> 
> On 25/04/18 07:26, AKASHI Takahiro wrote:
> > Change this function from static to global so that arm64 can implement
> > its own arch_kimage_file_post_load_cleanup() later using
> > kexec_image_post_load_cleanup_default().
> 
> Do we need to call kexec_image_post_load_cleanup_default()? All it does is 
> call
> the image-type fops->cleanup(), which you don't implement in this series.
> 
> Is this just-in-case someone adds cleanup() later and is surprised only the
> arch-level helper is called?

Yes, we want not to miss two possibilities:
- some common clean-up code is added to kexec_image_post_load_cleanup_default()
- some format(i.e. Image)-specific clean-up code is added to fops->cleanup()

-Takahiro AKASHI

> 
> 
> Thanks,
> 
> James

Re: linux-next: manual merge of the tip tree with the bpf-next tree

[Stephen Rothwell]

Hi all,

On Mon, 7 May 2018 12:09:09 +1000 Stephen Rothwell  
wrote:
>
> Today's linux-next merge of the tip tree got a conflict in:
> 
>   arch/x86/net/bpf_jit_comp.c
> 
> between commit:
> 
>   e782bdcf58c5 ("bpf, x64: remove ld_abs/ld_ind")
> 
> from the bpf-next tree and commit:
> 
>   5f26c50143f5 ("x86/bpf: Clean up non-standard comments, to make the code 
> more readable")
> 
> from the tip tree.
> 
> I fixed it up (the former commit removed some code modified by the latter,
> so I just removed it) and can carry the fix as necessary. This is now
> fixed as far as linux-next is concerned, but any non trivial conflicts
> should be mentioned to your upstream maintainer when your tree is
> submitted for merging.  You may also want to consider cooperating with
> the maintainer of the conflicting tree to minimise any particularly
> complex conflicts.

Actually the tip tree commit has been added to the bpf-next tree as a
different commit, so dropping it from the tip tree will clean this up.

-- 
Cheers,
Stephen Rothwell


pgpUyPYFCBZVk.pgp
Description: OpenPGP digital signature

Re: linux-next: manual merge of the tip tree with the bpf-next tree

[Stephen Rothwell]

Hi all,

On Mon, 7 May 2018 12:09:09 +1000 Stephen Rothwell  
wrote:
>
> Today's linux-next merge of the tip tree got a conflict in:
> 
>   arch/x86/net/bpf_jit_comp.c
> 
> between commit:
> 
>   e782bdcf58c5 ("bpf, x64: remove ld_abs/ld_ind")
> 
> from the bpf-next tree and commit:
> 
>   5f26c50143f5 ("x86/bpf: Clean up non-standard comments, to make the code 
> more readable")
> 
> from the tip tree.
> 
> I fixed it up (the former commit removed some code modified by the latter,
> so I just removed it) and can carry the fix as necessary. This is now
> fixed as far as linux-next is concerned, but any non trivial conflicts
> should be mentioned to your upstream maintainer when your tree is
> submitted for merging.  You may also want to consider cooperating with
> the maintainer of the conflicting tree to minimise any particularly
> complex conflicts.

Actually the tip tree commit has been added to the bpf-next tree as a
different commit, so dropping it from the tip tree will clean this up.

-- 
Cheers,
Stephen Rothwell


pgpUyPYFCBZVk.pgp
Description: OpenPGP digital signature

Re: [PATCH] x86/vdso: remove unused file

[Andy Lutomirski]

On Fri, May 4, 2018 at 10:59 AM Jann Horn  wrote:

> commit da861e18eccc ("x86, vdso: Get rid of the fake section mechanism")
> left this file behind; nothing is using it anymore.

Acked-by: Andy Lutomirski 

Re: [PATCH] x86/vdso: remove unused file

[Andy Lutomirski]

On Fri, May 4, 2018 at 10:59 AM Jann Horn  wrote:

> commit da861e18eccc ("x86, vdso: Get rid of the fake section mechanism")
> left this file behind; nothing is using it anymore.

Acked-by: Andy Lutomirski 

Re: [PATCH v2 01/14] mtd: rawnand: helper function for setting up ECC parameters

[Masahiro Yamada]

2018-05-03 21:20 GMT+09:00 Abhishek Sahu :
> commit 2c8f8afa7f92 ("mtd: nand: add generic helpers to check,
> match, maximize ECC settings") provides generic helpers which
> drivers can use for setting up ECC parameters.
>
> Since same board can have different ECC strength nand chips so
> following is the logic for setting up ECC strength and ECC step
> size, which can be used by most of the drivers.
>
> 1. If both ECC step size and ECC strength are already set
>(usually by DT) then just check whether this setting
>is supported by NAND controller.
> 2. If NAND_ECC_MAXIMIZE is set, then select maximum ECC strength
>supported by NAND controller.
> 3. Otherwise, try to match the ECC step size and ECC strength closest
>to the chip's requirement. If available OOB size can't fit the chip
>requirement then select maximum ECC strength which can be fit with
>available OOB size with warning.
>
> This patch introduces nand_ecc_param_setup function which calls the
> required helper functions for the above logic. The drivers can use
> this single function instead of calling the 3 helper functions
> individually.
>
> CC: Masahiro Yamada 
> Signed-off-by: Abhishek Sahu 
> ---
> * Changes from v1:
>
>   NEW PATCH
>
>  drivers/mtd/nand/raw/nand_base.c | 42 
> 
>  include/linux/mtd/rawnand.h  |  3 +++
>  2 files changed, 45 insertions(+)
>
> diff --git a/drivers/mtd/nand/raw/nand_base.c 
> b/drivers/mtd/nand/raw/nand_base.c
> index 72f3a89..dd7a984 100644
> --- a/drivers/mtd/nand/raw/nand_base.c
> +++ b/drivers/mtd/nand/raw/nand_base.c
> @@ -6249,6 +6249,48 @@ int nand_maximize_ecc(struct nand_chip *chip,
>  }
>  EXPORT_SYMBOL_GPL(nand_maximize_ecc);
>
> +/**
> + * nand_ecc_param_setup - Set the ECC strength and ECC step size
> + * @chip: nand chip info structure
> + * @caps: ECC engine caps info structure
> + * @oobavail: OOB size that the ECC engine can use
> + *
> + * Choose the ECC strength according to following logic
> + *
> + * 1. If both ECC step size and ECC strength are already set (usually by DT)
> + *then check if it is supported by this controller.
> + * 2. If NAND_ECC_MAXIMIZE is set, then select maximum ECC strength.
> + * 3. Otherwise, try to match the ECC step size and ECC strength closest
> + *to the chip's requirement. If available OOB size can't fit the chip
> + *requirement then fallback to the maximum ECC step size and ECC strength
> + *and print the warning.
> + *
> + * On success, the chosen ECC settings are set.
> + */
> +int nand_ecc_param_setup(struct nand_chip *chip,
> +const struct nand_ecc_caps *caps, int oobavail)
> +{
> +   int ret;
> +
> +   if (chip->ecc.size && chip->ecc.strength)
> +   return nand_check_ecc_caps(chip, caps, oobavail);
> +
> +   if (chip->ecc.options & NAND_ECC_MAXIMIZE)
> +   return nand_maximize_ecc(chip, caps, oobavail);
> +
> +   if (!nand_match_ecc_req(chip, caps, oobavail))
> +   return 0;
> +
> +   ret = nand_maximize_ecc(chip, caps, oobavail);


Why two calls for nand_maximize_ecc()?

My code is simpler, and does not display
false-positive warning.


> +   if (!ret)
> +   pr_warn("ECC (step, strength) = (%d, %d) not supported on 
> this controller. Fallback to (%d, %d)\n",
> +   chip->ecc_step_ds, chip->ecc_strength_ds,
> +   chip->ecc.size, chip->ecc.strength);


This is annoying.

{ecc_step_ds, ecc_strength_ds} are not provided by Non-ONFi devices.

So,
  ECC (step, strength) = (0, 0) not supported on this controller.

will be always displayed.


The strength will be checked by nand_ecc_strength_good() anyway.






> +
> +   return ret;
> +}
> +EXPORT_SYMBOL_GPL(nand_ecc_param_setup);



-- 
Best Regards
Masahiro Yamada

Re: [PATCH v2 01/14] mtd: rawnand: helper function for setting up ECC parameters

[Masahiro Yamada]

2018-05-03 21:20 GMT+09:00 Abhishek Sahu :
> commit 2c8f8afa7f92 ("mtd: nand: add generic helpers to check,
> match, maximize ECC settings") provides generic helpers which
> drivers can use for setting up ECC parameters.
>
> Since same board can have different ECC strength nand chips so
> following is the logic for setting up ECC strength and ECC step
> size, which can be used by most of the drivers.
>
> 1. If both ECC step size and ECC strength are already set
>(usually by DT) then just check whether this setting
>is supported by NAND controller.
> 2. If NAND_ECC_MAXIMIZE is set, then select maximum ECC strength
>supported by NAND controller.
> 3. Otherwise, try to match the ECC step size and ECC strength closest
>to the chip's requirement. If available OOB size can't fit the chip
>requirement then select maximum ECC strength which can be fit with
>available OOB size with warning.
>
> This patch introduces nand_ecc_param_setup function which calls the
> required helper functions for the above logic. The drivers can use
> this single function instead of calling the 3 helper functions
> individually.
>
> CC: Masahiro Yamada 
> Signed-off-by: Abhishek Sahu 
> ---
> * Changes from v1:
>
>   NEW PATCH
>
>  drivers/mtd/nand/raw/nand_base.c | 42 
> 
>  include/linux/mtd/rawnand.h  |  3 +++
>  2 files changed, 45 insertions(+)
>
> diff --git a/drivers/mtd/nand/raw/nand_base.c 
> b/drivers/mtd/nand/raw/nand_base.c
> index 72f3a89..dd7a984 100644
> --- a/drivers/mtd/nand/raw/nand_base.c
> +++ b/drivers/mtd/nand/raw/nand_base.c
> @@ -6249,6 +6249,48 @@ int nand_maximize_ecc(struct nand_chip *chip,
>  }
>  EXPORT_SYMBOL_GPL(nand_maximize_ecc);
>
> +/**
> + * nand_ecc_param_setup - Set the ECC strength and ECC step size
> + * @chip: nand chip info structure
> + * @caps: ECC engine caps info structure
> + * @oobavail: OOB size that the ECC engine can use
> + *
> + * Choose the ECC strength according to following logic
> + *
> + * 1. If both ECC step size and ECC strength are already set (usually by DT)
> + *then check if it is supported by this controller.
> + * 2. If NAND_ECC_MAXIMIZE is set, then select maximum ECC strength.
> + * 3. Otherwise, try to match the ECC step size and ECC strength closest
> + *to the chip's requirement. If available OOB size can't fit the chip
> + *requirement then fallback to the maximum ECC step size and ECC strength
> + *and print the warning.
> + *
> + * On success, the chosen ECC settings are set.
> + */
> +int nand_ecc_param_setup(struct nand_chip *chip,
> +const struct nand_ecc_caps *caps, int oobavail)
> +{
> +   int ret;
> +
> +   if (chip->ecc.size && chip->ecc.strength)
> +   return nand_check_ecc_caps(chip, caps, oobavail);
> +
> +   if (chip->ecc.options & NAND_ECC_MAXIMIZE)
> +   return nand_maximize_ecc(chip, caps, oobavail);
> +
> +   if (!nand_match_ecc_req(chip, caps, oobavail))
> +   return 0;
> +
> +   ret = nand_maximize_ecc(chip, caps, oobavail);


Why two calls for nand_maximize_ecc()?

My code is simpler, and does not display
false-positive warning.


> +   if (!ret)
> +   pr_warn("ECC (step, strength) = (%d, %d) not supported on 
> this controller. Fallback to (%d, %d)\n",
> +   chip->ecc_step_ds, chip->ecc_strength_ds,
> +   chip->ecc.size, chip->ecc.strength);


This is annoying.

{ecc_step_ds, ecc_strength_ds} are not provided by Non-ONFi devices.

So,
  ECC (step, strength) = (0, 0) not supported on this controller.

will be always displayed.


The strength will be checked by nand_ecc_strength_good() anyway.






> +
> +   return ret;
> +}
> +EXPORT_SYMBOL_GPL(nand_ecc_param_setup);



-- 
Best Regards
Masahiro Yamada

[PATCH v2 03/13] drm/kms/mode/exynos-dsi: using helper func drm_display_mode_to_videomode for calculating timing parameters

[Satendra Singh Thakur]

To avoid duplicate logic for the same

Signed-off-by: Satendra Singh Thakur 
Acked-by: Madhur Verma 
Cc: Hemanshu Srivastava 
---

 v2: Removed Mr Robin from reviewed-by field

 drivers/gpu/drm/exynos/exynos_drm_dsi.c | 13 ++---
 1 file changed, 2 insertions(+), 11 deletions(-)

diff --git a/drivers/gpu/drm/exynos/exynos_drm_dsi.c 
b/drivers/gpu/drm/exynos/exynos_drm_dsi.c
index 7904ffa..7fe84fd 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_dsi.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_dsi.c
@@ -1490,17 +1490,8 @@ static void exynos_dsi_mode_set(struct drm_encoder 
*encoder,
struct drm_display_mode *adjusted_mode)
 {
struct exynos_dsi *dsi = encoder_to_dsi(encoder);
-   struct videomode *vm = >vm;
-   struct drm_display_mode *m = adjusted_mode;
-
-   vm->hactive = m->hdisplay;
-   vm->vactive = m->vdisplay;
-   vm->vfront_porch = m->vsync_start - m->vdisplay;
-   vm->vback_porch = m->vtotal - m->vsync_end;
-   vm->vsync_len = m->vsync_end - m->vsync_start;
-   vm->hfront_porch = m->hsync_start - m->hdisplay;
-   vm->hback_porch = m->htotal - m->hsync_end;
-   vm->hsync_len = m->hsync_end - m->hsync_start;
+
+   drm_display_mode_to_videomode(adjusted_mode, >vm);
 }
 
 static const struct drm_encoder_helper_funcs exynos_dsi_encoder_helper_funcs = 
{
-- 
2.7.4

[PATCH v2 03/13] drm/kms/mode/exynos-dsi: using helper func drm_display_mode_to_videomode for calculating timing parameters

[Satendra Singh Thakur]

To avoid duplicate logic for the same

Signed-off-by: Satendra Singh Thakur 
Acked-by: Madhur Verma 
Cc: Hemanshu Srivastava 
---

 v2: Removed Mr Robin from reviewed-by field

 drivers/gpu/drm/exynos/exynos_drm_dsi.c | 13 ++---
 1 file changed, 2 insertions(+), 11 deletions(-)

diff --git a/drivers/gpu/drm/exynos/exynos_drm_dsi.c 
b/drivers/gpu/drm/exynos/exynos_drm_dsi.c
index 7904ffa..7fe84fd 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_dsi.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_dsi.c
@@ -1490,17 +1490,8 @@ static void exynos_dsi_mode_set(struct drm_encoder 
*encoder,
struct drm_display_mode *adjusted_mode)
 {
struct exynos_dsi *dsi = encoder_to_dsi(encoder);
-   struct videomode *vm = >vm;
-   struct drm_display_mode *m = adjusted_mode;
-
-   vm->hactive = m->hdisplay;
-   vm->vactive = m->vdisplay;
-   vm->vfront_porch = m->vsync_start - m->vdisplay;
-   vm->vback_porch = m->vtotal - m->vsync_end;
-   vm->vsync_len = m->vsync_end - m->vsync_start;
-   vm->hfront_porch = m->hsync_start - m->hdisplay;
-   vm->hback_porch = m->htotal - m->hsync_end;
-   vm->hsync_len = m->hsync_end - m->hsync_start;
+
+   drm_display_mode_to_videomode(adjusted_mode, >vm);
 }
 
 static const struct drm_encoder_helper_funcs exynos_dsi_encoder_helper_funcs = 
{
-- 
2.7.4

[PATCH v2] drm/kms/mode: added a new helper for calculating videomode from crtc's display mode

[Satendra Singh Thakur]

1.
-Added a new helper drm_display_mode_crtc_to_videomode
-This helper calculates mode parameters like
--horizontal front_porch, back_porch, sync length
--vertical front_porch, back_porch, sync length
-using crtc fields of struct drm_display_mode
-It uses following fields of crtc mode
--horizontal sync start/end, active and total length
--vertical sync start/end, active and total length
2.
-Most of the driver use user-supplied mode for calculating videomode
-However, few drivers use HW (crtc) mode for calculating videomode
-This helper will be useful for such drivers
3.
-Currently following drivers will be using this new helper
-arm hdlcd
-atmel hlcdc
-exynos 5433 decon
-exynos7 decon
-exynos fimd
4.
-This change reduces several redundant lines of code for many drivers

Acked-by: Liviu Dudau 
Signed-off-by: Satendra Singh Thakur 
Acked-by: Madhur Verma 
Cc: Hemanshu Srivastava 
---

 v2: Removed Mr Jani from Reviewed-by field

 drivers/gpu/drm/arm/hdlcd_crtc.c   | 10 ++
 drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_crtc.c |  9 ++---
 drivers/gpu/drm/drm_modes.c| 19 +++
 drivers/gpu/drm/exynos/exynos5433_drm_decon.c  | 22 ++
 drivers/gpu/drm/exynos/exynos7_drm_decon.c | 23 ++-
 drivers/gpu/drm/exynos/exynos_drm_fimd.c   | 22 +-
 include/drm/drm_modes.h|  2 ++
 7 files changed, 54 insertions(+), 53 deletions(-)

diff --git a/drivers/gpu/drm/arm/hdlcd_crtc.c b/drivers/gpu/drm/arm/hdlcd_crtc.c
index cf5cbd6..5cec264 100644
--- a/drivers/gpu/drm/arm/hdlcd_crtc.c
+++ b/drivers/gpu/drm/arm/hdlcd_crtc.c
@@ -127,16 +127,10 @@ static void hdlcd_crtc_mode_set_nofb(struct drm_crtc 
*crtc)
 {
struct hdlcd_drm_private *hdlcd = crtc_to_hdlcd_priv(crtc);
struct drm_display_mode *m = >state->adjusted_mode;
-   struct videomode vm;
+   struct videomode vm = {};
unsigned int polarities, err;
 
-   vm.vfront_porch = m->crtc_vsync_start - m->crtc_vdisplay;
-   vm.vback_porch = m->crtc_vtotal - m->crtc_vsync_end;
-   vm.vsync_len = m->crtc_vsync_end - m->crtc_vsync_start;
-   vm.hfront_porch = m->crtc_hsync_start - m->crtc_hdisplay;
-   vm.hback_porch = m->crtc_htotal - m->crtc_hsync_end;
-   vm.hsync_len = m->crtc_hsync_end - m->crtc_hsync_start;
-
+   drm_display_mode_crtc_to_videomode(m, );
polarities = HDLCD_POLARITY_DATAEN | HDLCD_POLARITY_DATA;
 
if (m->flags & DRM_MODE_FLAG_PHSYNC)
diff --git a/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_crtc.c 
b/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_crtc.c
index d732810..fb298b8 100644
--- a/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_crtc.c
+++ b/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_crtc.c
@@ -76,17 +76,12 @@ static void atmel_hlcdc_crtc_mode_set_nofb(struct drm_crtc 
*c)
struct drm_display_mode *adj = >state->adjusted_mode;
struct atmel_hlcdc_crtc_state *state;
unsigned long mode_rate;
-   struct videomode vm;
+   struct videomode vm = {};
unsigned long prate;
unsigned int cfg;
int div;
 
-   vm.vfront_porch = adj->crtc_vsync_start - adj->crtc_vdisplay;
-   vm.vback_porch = adj->crtc_vtotal - adj->crtc_vsync_end;
-   vm.vsync_len = adj->crtc_vsync_end - adj->crtc_vsync_start;
-   vm.hfront_porch = adj->crtc_hsync_start - adj->crtc_hdisplay;
-   vm.hback_porch = adj->crtc_htotal - adj->crtc_hsync_end;
-   vm.hsync_len = adj->crtc_hsync_end - adj->crtc_hsync_start;
+   drm_display_mode_crtc_to_videomode(adj, );
 
regmap_write(regmap, ATMEL_HLCDC_CFG(1),
 (vm.hsync_len - 1) | ((vm.vsync_len - 1) << 16));
diff --git a/drivers/gpu/drm/drm_modes.c b/drivers/gpu/drm/drm_modes.c
index e82b61e..328f771 100644
--- a/drivers/gpu/drm/drm_modes.c
+++ b/drivers/gpu/drm/drm_modes.c
@@ -654,6 +654,25 @@ void drm_display_mode_to_videomode(const struct 
drm_display_mode *dmode,
vm->flags |= DISPLAY_FLAGS_DOUBLECLK;
 }
 EXPORT_SYMBOL_GPL(drm_display_mode_to_videomode);
+/**
+ * drm_display_mode_crtc_to_videomode - fill in @vm using crtc fields of @dmode
+ * @dmode: drm_display_mode structure to use as source
+ * @vm: videomode structure to use as destination
+ *
+ * Fills out @vm using the crtc display mode specified in @dmode.
+ */
+void drm_display_mode_crtc_to_videomode(const struct drm_display_mode *dmode,
+  struct videomode *vm)
+{
+   vm->hfront_porch = dmode->crtc_hsync_start - dmode->crtc_hdisplay;
+   vm->hsync_len = dmode->crtc_hsync_end - dmode->crtc_hsync_start;
+   vm->hback_porch = dmode->crtc_htotal - dmode->crtc_hsync_end;
+   vm->vfront_porch = dmode->crtc_vsync_start - dmode->crtc_vdisplay;
+   vm->vsync_len = dmode->crtc_vsync_end - dmode->crtc_vsync_start;
+   vm->vback_porch = 

[PATCH v2] drm/kms/mode: added a new helper for calculating videomode from crtc's display mode

[Satendra Singh Thakur]

1.
-Added a new helper drm_display_mode_crtc_to_videomode
-This helper calculates mode parameters like
--horizontal front_porch, back_porch, sync length
--vertical front_porch, back_porch, sync length
-using crtc fields of struct drm_display_mode
-It uses following fields of crtc mode
--horizontal sync start/end, active and total length
--vertical sync start/end, active and total length
2.
-Most of the driver use user-supplied mode for calculating videomode
-However, few drivers use HW (crtc) mode for calculating videomode
-This helper will be useful for such drivers
3.
-Currently following drivers will be using this new helper
-arm hdlcd
-atmel hlcdc
-exynos 5433 decon
-exynos7 decon
-exynos fimd
4.
-This change reduces several redundant lines of code for many drivers

Acked-by: Liviu Dudau 
Signed-off-by: Satendra Singh Thakur 
Acked-by: Madhur Verma 
Cc: Hemanshu Srivastava 
---

 v2: Removed Mr Jani from Reviewed-by field

 drivers/gpu/drm/arm/hdlcd_crtc.c   | 10 ++
 drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_crtc.c |  9 ++---
 drivers/gpu/drm/drm_modes.c| 19 +++
 drivers/gpu/drm/exynos/exynos5433_drm_decon.c  | 22 ++
 drivers/gpu/drm/exynos/exynos7_drm_decon.c | 23 ++-
 drivers/gpu/drm/exynos/exynos_drm_fimd.c   | 22 +-
 include/drm/drm_modes.h|  2 ++
 7 files changed, 54 insertions(+), 53 deletions(-)

diff --git a/drivers/gpu/drm/arm/hdlcd_crtc.c b/drivers/gpu/drm/arm/hdlcd_crtc.c
index cf5cbd6..5cec264 100644
--- a/drivers/gpu/drm/arm/hdlcd_crtc.c
+++ b/drivers/gpu/drm/arm/hdlcd_crtc.c
@@ -127,16 +127,10 @@ static void hdlcd_crtc_mode_set_nofb(struct drm_crtc 
*crtc)
 {
struct hdlcd_drm_private *hdlcd = crtc_to_hdlcd_priv(crtc);
struct drm_display_mode *m = >state->adjusted_mode;
-   struct videomode vm;
+   struct videomode vm = {};
unsigned int polarities, err;
 
-   vm.vfront_porch = m->crtc_vsync_start - m->crtc_vdisplay;
-   vm.vback_porch = m->crtc_vtotal - m->crtc_vsync_end;
-   vm.vsync_len = m->crtc_vsync_end - m->crtc_vsync_start;
-   vm.hfront_porch = m->crtc_hsync_start - m->crtc_hdisplay;
-   vm.hback_porch = m->crtc_htotal - m->crtc_hsync_end;
-   vm.hsync_len = m->crtc_hsync_end - m->crtc_hsync_start;
-
+   drm_display_mode_crtc_to_videomode(m, );
polarities = HDLCD_POLARITY_DATAEN | HDLCD_POLARITY_DATA;
 
if (m->flags & DRM_MODE_FLAG_PHSYNC)
diff --git a/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_crtc.c 
b/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_crtc.c
index d732810..fb298b8 100644
--- a/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_crtc.c
+++ b/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_crtc.c
@@ -76,17 +76,12 @@ static void atmel_hlcdc_crtc_mode_set_nofb(struct drm_crtc 
*c)
struct drm_display_mode *adj = >state->adjusted_mode;
struct atmel_hlcdc_crtc_state *state;
unsigned long mode_rate;
-   struct videomode vm;
+   struct videomode vm = {};
unsigned long prate;
unsigned int cfg;
int div;
 
-   vm.vfront_porch = adj->crtc_vsync_start - adj->crtc_vdisplay;
-   vm.vback_porch = adj->crtc_vtotal - adj->crtc_vsync_end;
-   vm.vsync_len = adj->crtc_vsync_end - adj->crtc_vsync_start;
-   vm.hfront_porch = adj->crtc_hsync_start - adj->crtc_hdisplay;
-   vm.hback_porch = adj->crtc_htotal - adj->crtc_hsync_end;
-   vm.hsync_len = adj->crtc_hsync_end - adj->crtc_hsync_start;
+   drm_display_mode_crtc_to_videomode(adj, );
 
regmap_write(regmap, ATMEL_HLCDC_CFG(1),
 (vm.hsync_len - 1) | ((vm.vsync_len - 1) << 16));
diff --git a/drivers/gpu/drm/drm_modes.c b/drivers/gpu/drm/drm_modes.c
index e82b61e..328f771 100644
--- a/drivers/gpu/drm/drm_modes.c
+++ b/drivers/gpu/drm/drm_modes.c
@@ -654,6 +654,25 @@ void drm_display_mode_to_videomode(const struct 
drm_display_mode *dmode,
vm->flags |= DISPLAY_FLAGS_DOUBLECLK;
 }
 EXPORT_SYMBOL_GPL(drm_display_mode_to_videomode);
+/**
+ * drm_display_mode_crtc_to_videomode - fill in @vm using crtc fields of @dmode
+ * @dmode: drm_display_mode structure to use as source
+ * @vm: videomode structure to use as destination
+ *
+ * Fills out @vm using the crtc display mode specified in @dmode.
+ */
+void drm_display_mode_crtc_to_videomode(const struct drm_display_mode *dmode,
+  struct videomode *vm)
+{
+   vm->hfront_porch = dmode->crtc_hsync_start - dmode->crtc_hdisplay;
+   vm->hsync_len = dmode->crtc_hsync_end - dmode->crtc_hsync_start;
+   vm->hback_porch = dmode->crtc_htotal - dmode->crtc_hsync_end;
+   vm->vfront_porch = dmode->crtc_vsync_start - dmode->crtc_vdisplay;
+   vm->vsync_len = dmode->crtc_vsync_end - dmode->crtc_vsync_start;
+   vm->vback_porch = dmode->crtc_vtotal - dmode->crtc_vsync_end;
+
+}
+EXPORT_SYMBOL_GPL(drm_display_mode_crtc_to_videomode);
 
 

Re: [PATCH BUGFIX] block, bfq: postpone rq preparation to insert or merge

[Mike Galbraith]

On Mon, 2018-05-07 at 04:43 +0200, Mike Galbraith wrote:
> On Sun, 2018-05-06 at 09:42 +0200, Paolo Valente wrote:
> > 
> > I've attached a compressed patch (to avoid possible corruption from my
> > mailer).  I'm little confident, but no pain, no gain, right?
> > 
> > If possible, apply this patch on top of the fix I proposed in this
> > thread, just to eliminate possible further noise. Finally, the
> > patch content follows.
> > 
> > Hoping for a stroke of luck,
> 
> FWIW, box didn't survive the first full build of the morning.

Nor the second.

-Mike

Re: [PATCH BUGFIX] block, bfq: postpone rq preparation to insert or merge

[Mike Galbraith]

On Mon, 2018-05-07 at 04:43 +0200, Mike Galbraith wrote:
> On Sun, 2018-05-06 at 09:42 +0200, Paolo Valente wrote:
> > 
> > I've attached a compressed patch (to avoid possible corruption from my
> > mailer).  I'm little confident, but no pain, no gain, right?
> > 
> > If possible, apply this patch on top of the fix I proposed in this
> > thread, just to eliminate possible further noise. Finally, the
> > patch content follows.
> > 
> > Hoping for a stroke of luck,
> 
> FWIW, box didn't survive the first full build of the morning.

Nor the second.

-Mike

Re: [PATCH] VFIO: Fix Documentation

[dongbo (E)]

Hi, Alex.

On 2018/5/1 2:38, Alex Williamson wrote:
> On Fri, 20 Apr 2018 18:07:27 +0800
> "dongbo (E)"  wrote:
> 
>> From: Dong Bo 
>>
>> Signed-off-by: Dong Bo 
>> ---
> 
> Hi Dong Bo,
> 
> The patch is corrupted, please resend and also include a commit log,
> something as simple as "Update vfio_add_group_dev description to match
> the current API" would be fine.  Thanks,
> 
> Alex
> 
Sorry for the corrupted patch. I've resent one and added the commit log
you suggested. Hope it would apply. Thanks.

Best Regards,
Dong Bo

>>  Documentation/vfio.txt | 5 ++---
>>  1 file changed, 2 insertions(+), 3 deletions(-)
>>
>> diff --git a/Documentation/vfio.txt b/Documentation/vfio.txt
>> index ef6a511..f1a4d3c 100644
>> --- a/Documentation/vfio.txt
>> +++ b/Documentation/vfio.txt
>> @@ -252,15 +252,14 @@ into VFIO core.  When devices are bound and unbound to 
>> the driver,
>>  the driver should call vfio_add_group_dev() and vfio_del_group_dev()
>>  respectively::
>>  -   extern int vfio_add_group_dev(struct iommu_group *iommu_group,
>> -  struct device *dev,
>> +extern int vfio_add_group_dev(struct device *dev,
>>const struct vfio_device_ops *ops,
>>void *device_data);
>>  extern void *vfio_del_group_dev(struct device *dev);
>>   vfio_add_group_dev() indicates to the core to begin tracking the
>> -specified iommu_group and register the specified dev as owned by
>> +iommu_group of the specified dev and register the dev as owned by
>>  a VFIO bus driver.  The driver provides an ops structure for callbacks
>>  similar to a file operations structure::
>>  -- 1.9.1
>>
>>
>> .
>>
>>
> 
> 
> .
> 

Re: [PATCH] VFIO: Fix Documentation

[dongbo (E)]

Hi, Alex.

On 2018/5/1 2:38, Alex Williamson wrote:
> On Fri, 20 Apr 2018 18:07:27 +0800
> "dongbo (E)"  wrote:
> 
>> From: Dong Bo 
>>
>> Signed-off-by: Dong Bo 
>> ---
> 
> Hi Dong Bo,
> 
> The patch is corrupted, please resend and also include a commit log,
> something as simple as "Update vfio_add_group_dev description to match
> the current API" would be fine.  Thanks,
> 
> Alex
> 
Sorry for the corrupted patch. I've resent one and added the commit log
you suggested. Hope it would apply. Thanks.

Best Regards,
Dong Bo

>>  Documentation/vfio.txt | 5 ++---
>>  1 file changed, 2 insertions(+), 3 deletions(-)
>>
>> diff --git a/Documentation/vfio.txt b/Documentation/vfio.txt
>> index ef6a511..f1a4d3c 100644
>> --- a/Documentation/vfio.txt
>> +++ b/Documentation/vfio.txt
>> @@ -252,15 +252,14 @@ into VFIO core.  When devices are bound and unbound to 
>> the driver,
>>  the driver should call vfio_add_group_dev() and vfio_del_group_dev()
>>  respectively::
>>  -   extern int vfio_add_group_dev(struct iommu_group *iommu_group,
>> -  struct device *dev,
>> +extern int vfio_add_group_dev(struct device *dev,
>>const struct vfio_device_ops *ops,
>>void *device_data);
>>  extern void *vfio_del_group_dev(struct device *dev);
>>   vfio_add_group_dev() indicates to the core to begin tracking the
>> -specified iommu_group and register the specified dev as owned by
>> +iommu_group of the specified dev and register the dev as owned by
>>  a VFIO bus driver.  The driver provides an ops structure for callbacks
>>  similar to a file operations structure::
>>  -- 1.9.1
>>
>>
>> .
>>
>>
> 
> 
> .
> 

Re: [RFC PATCH 3/3] arcnet: com20020: Add ethtool support

[Tobin C. Harding]

On Sat, May 05, 2018 at 11:35:29PM +0200, Andrea Greco wrote:
> From: Andrea Greco 
> 
> Setup ethtols for export com20020 diag register
> 
> Signed-off-by: Andrea Greco 
> ---
>  drivers/net/arcnet/com20020-isa.c|  1 +
>  drivers/net/arcnet/com20020-membus.c |  1 +
>  drivers/net/arcnet/com20020.c| 29 +
>  drivers/net/arcnet/com20020.h|  1 +
>  drivers/net/arcnet/com20020_cs.c |  1 +
>  include/uapi/linux/if_arcnet.h   |  6 ++
>  6 files changed, 39 insertions(+)
> 
> diff --git a/drivers/net/arcnet/com20020-isa.c 
> b/drivers/net/arcnet/com20020-isa.c
> index 38fa60ddaf2e..44ab6dcccb58 100644
> --- a/drivers/net/arcnet/com20020-isa.c
> +++ b/drivers/net/arcnet/com20020-isa.c
> @@ -154,6 +154,7 @@ static int __init com20020_init(void)
>   dev->dev_addr[0] = node;
>  
>   dev->netdev_ops = _netdev_ops;
> + dev->ethtool_ops = _ethtool_ops;
>  
>   lp = netdev_priv(dev);
>   lp->backplane = backplane;
> diff --git a/drivers/net/arcnet/com20020-membus.c 
> b/drivers/net/arcnet/com20020-membus.c
> index 6e4a2f3a84f7..9eead734a3cf 100644
> --- a/drivers/net/arcnet/com20020-membus.c
> +++ b/drivers/net/arcnet/com20020-membus.c
> @@ -91,6 +91,7 @@ static int com20020_probe(struct platform_device *pdev)
>  
>   dev = alloc_arcdev(NULL);// Let autoassign name arc%d
>   dev->netdev_ops = _netdev_ops;
> + dev->ethtool_ops = _ethtool_ops;
>   lp = netdev_priv(dev);
>  
>   lp->card_flags = ARC_CAN_10MBIT;/* pretend all of them can 10Mbit */
> diff --git a/drivers/net/arcnet/com20020.c b/drivers/net/arcnet/com20020.c
> index abd32ed8ec9b..2089b45e81c8 100644
> --- a/drivers/net/arcnet/com20020.c
> +++ b/drivers/net/arcnet/com20020.c
> @@ -201,6 +201,34 @@ const struct net_device_ops com20020_netdev_ops = {
>   .ndo_set_rx_mode = com20020_set_mc_list,
>  };
>  
> +static int com20020_ethtool_regs_len(struct net_device *netdev)
> +{
> + return sizeof(struct com20020_ethtool_regs);
> +}
> +
> +static void com20020_ethtool_regs_read(struct net_device *dev,
> +struct ethtool_regs *regs, void *p)
> +{
> + struct arcnet_local *lp;
> + struct com20020_ethtool_regs *com_reg;
> +
> + lp = netdev_priv(dev);
> + memset(p, 0, sizeof(struct com20020_ethtool_regs));

perhaps:

struct arcnet_local *lp = netdev_priv(dev);
struct com20020_ethtool_regs *com_reg = p;

memset(com_reg, 0, sizeof(*com_reg));

> +
> + regs->version = 1;

Should this function really have a side effect?  If so, perhaps it could
be commented.

> +
> + com_reg = p;
> +
> + com_reg->status = lp->hw.status(dev) & 0xFF;
> + com_reg->diag_register = (lp->hw.status(dev) >> 8) & 0xFF;
> + com_reg->reconf_count = lp->num_recons;
> +}
> +
> +const struct ethtool_ops com20020_ethtool_ops = {
> + .get_regs = com20020_ethtool_regs_read,
> + .get_regs_len  = com20020_ethtool_regs_len,
> +};
> +

Hope this helps,
Tobin.

Re: [RFC PATCH 3/3] arcnet: com20020: Add ethtool support

[Tobin C. Harding]

On Sat, May 05, 2018 at 11:35:29PM +0200, Andrea Greco wrote:
> From: Andrea Greco 
> 
> Setup ethtols for export com20020 diag register
> 
> Signed-off-by: Andrea Greco 
> ---
>  drivers/net/arcnet/com20020-isa.c|  1 +
>  drivers/net/arcnet/com20020-membus.c |  1 +
>  drivers/net/arcnet/com20020.c| 29 +
>  drivers/net/arcnet/com20020.h|  1 +
>  drivers/net/arcnet/com20020_cs.c |  1 +
>  include/uapi/linux/if_arcnet.h   |  6 ++
>  6 files changed, 39 insertions(+)
> 
> diff --git a/drivers/net/arcnet/com20020-isa.c 
> b/drivers/net/arcnet/com20020-isa.c
> index 38fa60ddaf2e..44ab6dcccb58 100644
> --- a/drivers/net/arcnet/com20020-isa.c
> +++ b/drivers/net/arcnet/com20020-isa.c
> @@ -154,6 +154,7 @@ static int __init com20020_init(void)
>   dev->dev_addr[0] = node;
>  
>   dev->netdev_ops = _netdev_ops;
> + dev->ethtool_ops = _ethtool_ops;
>  
>   lp = netdev_priv(dev);
>   lp->backplane = backplane;
> diff --git a/drivers/net/arcnet/com20020-membus.c 
> b/drivers/net/arcnet/com20020-membus.c
> index 6e4a2f3a84f7..9eead734a3cf 100644
> --- a/drivers/net/arcnet/com20020-membus.c
> +++ b/drivers/net/arcnet/com20020-membus.c
> @@ -91,6 +91,7 @@ static int com20020_probe(struct platform_device *pdev)
>  
>   dev = alloc_arcdev(NULL);// Let autoassign name arc%d
>   dev->netdev_ops = _netdev_ops;
> + dev->ethtool_ops = _ethtool_ops;
>   lp = netdev_priv(dev);
>  
>   lp->card_flags = ARC_CAN_10MBIT;/* pretend all of them can 10Mbit */
> diff --git a/drivers/net/arcnet/com20020.c b/drivers/net/arcnet/com20020.c
> index abd32ed8ec9b..2089b45e81c8 100644
> --- a/drivers/net/arcnet/com20020.c
> +++ b/drivers/net/arcnet/com20020.c
> @@ -201,6 +201,34 @@ const struct net_device_ops com20020_netdev_ops = {
>   .ndo_set_rx_mode = com20020_set_mc_list,
>  };
>  
> +static int com20020_ethtool_regs_len(struct net_device *netdev)
> +{
> + return sizeof(struct com20020_ethtool_regs);
> +}
> +
> +static void com20020_ethtool_regs_read(struct net_device *dev,
> +struct ethtool_regs *regs, void *p)
> +{
> + struct arcnet_local *lp;
> + struct com20020_ethtool_regs *com_reg;
> +
> + lp = netdev_priv(dev);
> + memset(p, 0, sizeof(struct com20020_ethtool_regs));

perhaps:

struct arcnet_local *lp = netdev_priv(dev);
struct com20020_ethtool_regs *com_reg = p;

memset(com_reg, 0, sizeof(*com_reg));

> +
> + regs->version = 1;

Should this function really have a side effect?  If so, perhaps it could
be commented.

> +
> + com_reg = p;
> +
> + com_reg->status = lp->hw.status(dev) & 0xFF;
> + com_reg->diag_register = (lp->hw.status(dev) >> 8) & 0xFF;
> + com_reg->reconf_count = lp->num_recons;
> +}
> +
> +const struct ethtool_ops com20020_ethtool_ops = {
> + .get_regs = com20020_ethtool_regs_read,
> + .get_regs_len  = com20020_ethtool_regs_len,
> +};
> +

Hope this helps,
Tobin.

Linux 4.17-rc4

[Linus Torvalds]

Hmm. Things look fairly normal.

Two thirds of the  4.17-rc4 patch is drivers, which sounds about right.
Media, networking, rdma, input, nvme, usb. A little bit of everything, in
other words.

There's the usual architecture suspects, and some othe rcore updates too
(mainly networking, but some filesystem fixes too).

Go out and test. The shortlog below gives you an overview of the exact
details if you care,

   Linus

---

Agustin Vega-Frias (1):
   irqchip/qcom: Fix check for spurious interrupts

Alan Stern (1):
   USB: Accept bulk endpoints with 1024-byte maxpacket

Alexandre Belloni (1):
   net: phy: allow scanning busses with missing phys

Anders Roxell (1):
   selftests: net: add in_netns.sh TEST_GEN_PROGS_EXTENDED

Anthoine Bourgeois (1):
   KVM: x86: remove APIC Timer periodic/oneshot spikes

Arend Van Spriel (1):
   brcmfmac: fix firmware request processing if nvram load fails

Ariel Levkovich (2):
   IB/uverbs: Prevent reregistration of DM_MR to regular MR
   IB/uverbs: Fix kernel crash during MR deregistration flow

Arnaud Pouliquen (1):
   remoteproc: fix crashed parameter logic on stop call

Arnd Bergmann (5):
   clk: cs2000: mark resume function as __maybe_unused
   hexagon: add memset_io() helper
   hexagon: export csum_partial_copy_nocheck
   iommu/amd: Hide unused iommu_table_lock
   iommu: rockchip: fix building without CONFIG_OF

Artur Petrosyan (1):
   usb: dwc2: WA for Full speed ISOC IN in DDMA mode.

Arvind Yadav (1):
   sparc: vio: use put_device() instead of kfree()

Baolin Wang (1):
   parisc: time: Convert read_persistent_clock() to
read_persistent_clock64()

Bharat Potnuri (1):
   iw_cxgb4: Atomically flush per QP HW CQEs

Bin Liu (2):
   usb: musb: host: fix potential NULL pointer dereference
   usb: musb: trace: fix NULL pointer dereference in musb_g_tx()

Bjørn Mork (1):
   qmi_wwan: do not steal interfaces from class drivers

Boris Brezillon (1):
   drm/vc4: Make sure vc4_bo_{inc,dec}_usecnt() calls are balanced

Bryant G Ly (1):
   scsi: target: Fix fortify_panic kernel exception

Changbin Du (1):
   iommu/vt-d: fix shift-out-of-bounds in bug checking

Chen LinX (1):
   ftrace: Have set_graph_* files have normal file modes

Chengguang Xu (1):
   nvme: fix potential memory leak in option parsing

Chris Mi (1):
   net/mlx5: Properly deal with flow counters when deleting rules

Christophe JAILLET (1):
   Input: synaptics-rmi4 - fix an unchecked out of memory error path

Colin Ian King (8):
   scsi: isci: Fix infinite loop in while loop
   RDMA/iwpm: fix memory leak on map_info
   net: systemport: fix spelling mistake: "asymetric" -> "asymmetric"
   qed: fix spelling mistake: "checksumed" -> "checksummed"
   net: ethernet: ucc: fix spelling mistake: "tx-late-collsion" ->
"tx-late-collision"
   net/mlx4: fix spelling mistake: "failedi" -> "failed"
   net/mlx5e: fix spelling mistake: "loobpack" -> "loopback"
   qed: fix spelling mistake: "offloded" -> "offloaded"

Coly Li (6):
   bcache: store disk name in struct cache and struct cached_dev
   bcache: set CACHE_SET_IO_DISABLE in bch_cached_dev_error()
   bcache: count backing device I/O error for writeback I/O
   bcache: add wait_for_kthread_stop() in bch_allocator_thread()
   bcache: set dc->io_disable to true in conditional_stop_bcache_device()
   bcache: use pr_info() to inform duplicated CACHE_SET_IO_DISABLE set

Dag Moxnes (1):
   rds: ib: Fix missing call to rds_ib_dev_put in rds_ib_setup_qp

Daniel Borkmann (2):
   bpf, x64: fix memleak when not converging after image
   bpf, x64: fix memleak when not converging on calls

Danit Goldberg (1):
   IB/mlx5: Use unlimited rate when static rate is not supported

Darrick J. Wong (3):
   xfs: prevent creating negative-sized file via INSERT_RANGE
   xfs: don't fail when converting shortform attr to long form during
ATTR_REPLACE
   xfs: cap the length of deduplication requests

Dave Watson (1):
   net/tls: Don't recursively call push_record during tls_write_space
callbacks

Dmitry Torokhov (1):
   Input: leds - fix out of bound access

Edward Cree (2):
   sfc: Use filter index rather than ID for rps_flow_id table
   sfc: fix ARFS expiry check on EF10

Eric Dumazet (6):
   ipv6: fix uninit-value in ip6_multipath_l3_keys()
   tcp: fix TCP_REPAIR_QUEUE bound checking
   net_sched: fq: take care of throttled flows before reuse
   rds: do not leak kernel memory to user land
   tcp: restore autocorking
   dccp: fix tasklet usage

Eric Sandeen (2):
   xfs: enhance dinode verifier
   xfs: set format back to extents if xfs_bmap_extents_to_btree

Filipe Manana (1):
   Btrfs: send, fix missing truncate for inode with prealloc extent past
eof

Florian Fainelli (1):
   net: systemport: Correclty disambiguate driver instances

From: 

Linux 4.17-rc4

[Linus Torvalds]

Hmm. Things look fairly normal.

Two thirds of the  4.17-rc4 patch is drivers, which sounds about right.
Media, networking, rdma, input, nvme, usb. A little bit of everything, in
other words.

There's the usual architecture suspects, and some othe rcore updates too
(mainly networking, but some filesystem fixes too).

Go out and test. The shortlog below gives you an overview of the exact
details if you care,

   Linus

---

Agustin Vega-Frias (1):
   irqchip/qcom: Fix check for spurious interrupts

Alan Stern (1):
   USB: Accept bulk endpoints with 1024-byte maxpacket

Alexandre Belloni (1):
   net: phy: allow scanning busses with missing phys

Anders Roxell (1):
   selftests: net: add in_netns.sh TEST_GEN_PROGS_EXTENDED

Anthoine Bourgeois (1):
   KVM: x86: remove APIC Timer periodic/oneshot spikes

Arend Van Spriel (1):
   brcmfmac: fix firmware request processing if nvram load fails

Ariel Levkovich (2):
   IB/uverbs: Prevent reregistration of DM_MR to regular MR
   IB/uverbs: Fix kernel crash during MR deregistration flow

Arnaud Pouliquen (1):
   remoteproc: fix crashed parameter logic on stop call

Arnd Bergmann (5):
   clk: cs2000: mark resume function as __maybe_unused
   hexagon: add memset_io() helper
   hexagon: export csum_partial_copy_nocheck
   iommu/amd: Hide unused iommu_table_lock
   iommu: rockchip: fix building without CONFIG_OF

Artur Petrosyan (1):
   usb: dwc2: WA for Full speed ISOC IN in DDMA mode.

Arvind Yadav (1):
   sparc: vio: use put_device() instead of kfree()

Baolin Wang (1):
   parisc: time: Convert read_persistent_clock() to
read_persistent_clock64()

Bharat Potnuri (1):
   iw_cxgb4: Atomically flush per QP HW CQEs

Bin Liu (2):
   usb: musb: host: fix potential NULL pointer dereference
   usb: musb: trace: fix NULL pointer dereference in musb_g_tx()

Bjørn Mork (1):
   qmi_wwan: do not steal interfaces from class drivers

Boris Brezillon (1):
   drm/vc4: Make sure vc4_bo_{inc,dec}_usecnt() calls are balanced

Bryant G Ly (1):
   scsi: target: Fix fortify_panic kernel exception

Changbin Du (1):
   iommu/vt-d: fix shift-out-of-bounds in bug checking

Chen LinX (1):
   ftrace: Have set_graph_* files have normal file modes

Chengguang Xu (1):
   nvme: fix potential memory leak in option parsing

Chris Mi (1):
   net/mlx5: Properly deal with flow counters when deleting rules

Christophe JAILLET (1):
   Input: synaptics-rmi4 - fix an unchecked out of memory error path

Colin Ian King (8):
   scsi: isci: Fix infinite loop in while loop
   RDMA/iwpm: fix memory leak on map_info
   net: systemport: fix spelling mistake: "asymetric" -> "asymmetric"
   qed: fix spelling mistake: "checksumed" -> "checksummed"
   net: ethernet: ucc: fix spelling mistake: "tx-late-collsion" ->
"tx-late-collision"
   net/mlx4: fix spelling mistake: "failedi" -> "failed"
   net/mlx5e: fix spelling mistake: "loobpack" -> "loopback"
   qed: fix spelling mistake: "offloded" -> "offloaded"

Coly Li (6):
   bcache: store disk name in struct cache and struct cached_dev
   bcache: set CACHE_SET_IO_DISABLE in bch_cached_dev_error()
   bcache: count backing device I/O error for writeback I/O
   bcache: add wait_for_kthread_stop() in bch_allocator_thread()
   bcache: set dc->io_disable to true in conditional_stop_bcache_device()
   bcache: use pr_info() to inform duplicated CACHE_SET_IO_DISABLE set

Dag Moxnes (1):
   rds: ib: Fix missing call to rds_ib_dev_put in rds_ib_setup_qp

Daniel Borkmann (2):
   bpf, x64: fix memleak when not converging after image
   bpf, x64: fix memleak when not converging on calls

Danit Goldberg (1):
   IB/mlx5: Use unlimited rate when static rate is not supported

Darrick J. Wong (3):
   xfs: prevent creating negative-sized file via INSERT_RANGE
   xfs: don't fail when converting shortform attr to long form during
ATTR_REPLACE
   xfs: cap the length of deduplication requests

Dave Watson (1):
   net/tls: Don't recursively call push_record during tls_write_space
callbacks

Dmitry Torokhov (1):
   Input: leds - fix out of bound access

Edward Cree (2):
   sfc: Use filter index rather than ID for rps_flow_id table
   sfc: fix ARFS expiry check on EF10

Eric Dumazet (6):
   ipv6: fix uninit-value in ip6_multipath_l3_keys()
   tcp: fix TCP_REPAIR_QUEUE bound checking
   net_sched: fq: take care of throttled flows before reuse
   rds: do not leak kernel memory to user land
   tcp: restore autocorking
   dccp: fix tasklet usage

Eric Sandeen (2):
   xfs: enhance dinode verifier
   xfs: set format back to extents if xfs_bmap_extents_to_btree

Filipe Manana (1):
   Btrfs: send, fix missing truncate for inode with prealloc extent past
eof

Florian Fainelli (1):
   net: systemport: Correclty disambiguate driver instances

From: 

[PATCH] vfio: fix documentation

[dongbo (E)]

From: Dong Bo 

Update vfio_add_group_dev description to match the current API.

Signed-off-by: Dong Bo 
---
 Documentation/vfio.txt | 5 ++---
 1 file changed, 2 insertions(+), 3 deletions(-)

diff --git a/Documentation/vfio.txt b/Documentation/vfio.txt
index ef6a511..f1a4d3c 100644
--- a/Documentation/vfio.txt
+++ b/Documentation/vfio.txt
@@ -252,15 +252,14 @@ into VFIO core.  When devices are bound and unbound to 
the driver,
 the driver should call vfio_add_group_dev() and vfio_del_group_dev()
 respectively::

-   extern int vfio_add_group_dev(struct iommu_group *iommu_group,
- struct device *dev,
+   extern int vfio_add_group_dev(struct device *dev,
  const struct vfio_device_ops *ops,
  void *device_data);

extern void *vfio_del_group_dev(struct device *dev);

 vfio_add_group_dev() indicates to the core to begin tracking the
-specified iommu_group and register the specified dev as owned by
+iommu_group of the specified dev and register the dev as owned by
 a VFIO bus driver.  The driver provides an ops structure for callbacks
 similar to a file operations structure::

-- 
1.9.1


.

[PATCH] vfio: fix documentation

[dongbo (E)]

From: Dong Bo 

Update vfio_add_group_dev description to match the current API.

Signed-off-by: Dong Bo 
---
 Documentation/vfio.txt | 5 ++---
 1 file changed, 2 insertions(+), 3 deletions(-)

diff --git a/Documentation/vfio.txt b/Documentation/vfio.txt
index ef6a511..f1a4d3c 100644
--- a/Documentation/vfio.txt
+++ b/Documentation/vfio.txt
@@ -252,15 +252,14 @@ into VFIO core.  When devices are bound and unbound to 
the driver,
 the driver should call vfio_add_group_dev() and vfio_del_group_dev()
 respectively::

-   extern int vfio_add_group_dev(struct iommu_group *iommu_group,
- struct device *dev,
+   extern int vfio_add_group_dev(struct device *dev,
  const struct vfio_device_ops *ops,
  void *device_data);

extern void *vfio_del_group_dev(struct device *dev);

 vfio_add_group_dev() indicates to the core to begin tracking the
-specified iommu_group and register the specified dev as owned by
+iommu_group of the specified dev and register the dev as owned by
 a VFIO bus driver.  The driver provides an ops structure for callbacks
 similar to a file operations structure::

-- 
1.9.1


.

Re: [PATCH v3 6/9] ALSA: hda/ca0132: add alt_select_in/out for R3Di + SBZ

[Takashi Sakamoto]

Hi,

On May 6 2018 04:03, Connor McAdams wrote:

Add functions ca0132_alt_select_out and ca0132_alt_select_in for
switching outputs and inputs for r3di and sbz. Also, add enumerated
controls for selecting output and input source.

Signed-off-by: Connor McAdams 
---
  sound/pci/hda/patch_ca0132.c | 597 +--
  1 file changed, 572 insertions(+), 25 deletions(-)

diff --git a/sound/pci/hda/patch_ca0132.c b/sound/pci/hda/patch_ca0132.c
index bb0feaa..36cc2a1 100644
--- a/sound/pci/hda/patch_ca0132.c
+++ b/sound/pci/hda/patch_ca0132.c
@@ -480,6 +494,49 @@ static struct ct_voicefx_preset ca0132_voicefx_presets[] = 
{
}
  };
  
+/* DSP command sequences for ca0132_alt_select_out */

+#define ALT_OUT_SET_MAX_COMMANDS 9 /* Max number of commands in sequence */
+struct ca0132_alt_out_set {
+   char *name; /*preset name*/
+   unsigned char commands;
+   unsigned int mids[ALT_OUT_SET_MAX_COMMANDS];
+   unsigned int reqs[ALT_OUT_SET_MAX_COMMANDS];
+   unsigned int vals[ALT_OUT_SET_MAX_COMMANDS];
+};
+
+static struct ca0132_alt_out_set alt_out_presets[] = {
+   { .name = "Line Out",
+ .commands = 7,
+ .mids = { 0x96, 0x96, 0x96, 0x8F,
+   0x96, 0x96, 0x96 },
+ .reqs = { 0x19, 0x17, 0x18, 0x01,
+   0x1F, 0x15, 0x3A },
+ .vals = { 0x3F00, 0x42A0, 0x,
+   0x, 0x, 0x,
+   0x }
+   },
+   { .name = "Headphone",
+ .commands = 7,
+ .mids = { 0x96, 0x96, 0x96, 0x8F,
+   0x96, 0x96, 0x96 },
+ .reqs = { 0x19, 0x17, 0x18, 0x01,
+   0x1F, 0x15, 0x3A },
+ .vals = { 0x3F00, 0x42A0, 0x,
+   0x, 0x, 0x,
+   0x }
+   },
+   { .name = "Surround",
+ .commands = 8,
+ .mids = { 0x96, 0x8F, 0x96, 0x96,
+   0x96, 0x96, 0x96, 0x96 },
+ .reqs = { 0x18, 0x01, 0x1F, 0x15,
+   0x3A, 0x1A, 0x1B, 0x1C },
+ .vals = { 0x, 0x, 0x,
+   0x, 0x, 0x,
+   0x, 0x }
+   }
+};
+


It's better to add 'const' qualifier.


Regards

Takashi Sakamoto

Re: [PATCH v3 6/9] ALSA: hda/ca0132: add alt_select_in/out for R3Di + SBZ

[Takashi Sakamoto]

Hi,

On May 6 2018 04:03, Connor McAdams wrote:

Add functions ca0132_alt_select_out and ca0132_alt_select_in for
switching outputs and inputs for r3di and sbz. Also, add enumerated
controls for selecting output and input source.

Signed-off-by: Connor McAdams 
---
  sound/pci/hda/patch_ca0132.c | 597 +--
  1 file changed, 572 insertions(+), 25 deletions(-)

diff --git a/sound/pci/hda/patch_ca0132.c b/sound/pci/hda/patch_ca0132.c
index bb0feaa..36cc2a1 100644
--- a/sound/pci/hda/patch_ca0132.c
+++ b/sound/pci/hda/patch_ca0132.c
@@ -480,6 +494,49 @@ static struct ct_voicefx_preset ca0132_voicefx_presets[] = 
{
}
  };
  
+/* DSP command sequences for ca0132_alt_select_out */

+#define ALT_OUT_SET_MAX_COMMANDS 9 /* Max number of commands in sequence */
+struct ca0132_alt_out_set {
+   char *name; /*preset name*/
+   unsigned char commands;
+   unsigned int mids[ALT_OUT_SET_MAX_COMMANDS];
+   unsigned int reqs[ALT_OUT_SET_MAX_COMMANDS];
+   unsigned int vals[ALT_OUT_SET_MAX_COMMANDS];
+};
+
+static struct ca0132_alt_out_set alt_out_presets[] = {
+   { .name = "Line Out",
+ .commands = 7,
+ .mids = { 0x96, 0x96, 0x96, 0x8F,
+   0x96, 0x96, 0x96 },
+ .reqs = { 0x19, 0x17, 0x18, 0x01,
+   0x1F, 0x15, 0x3A },
+ .vals = { 0x3F00, 0x42A0, 0x,
+   0x, 0x, 0x,
+   0x }
+   },
+   { .name = "Headphone",
+ .commands = 7,
+ .mids = { 0x96, 0x96, 0x96, 0x8F,
+   0x96, 0x96, 0x96 },
+ .reqs = { 0x19, 0x17, 0x18, 0x01,
+   0x1F, 0x15, 0x3A },
+ .vals = { 0x3F00, 0x42A0, 0x,
+   0x, 0x, 0x,
+   0x }
+   },
+   { .name = "Surround",
+ .commands = 8,
+ .mids = { 0x96, 0x8F, 0x96, 0x96,
+   0x96, 0x96, 0x96, 0x96 },
+ .reqs = { 0x18, 0x01, 0x1F, 0x15,
+   0x3A, 0x1A, 0x1B, 0x1C },
+ .vals = { 0x, 0x, 0x,
+   0x, 0x, 0x,
+   0x, 0x }
+   }
+};
+


It's better to add 'const' qualifier.


Regards

Takashi Sakamoto

Re: [RFC PATCH 2/3] arcnet: com20020: Fixup missing SLOWARB bit

[Tobin C. Harding]

On Sat, May 05, 2018 at 11:37:54PM +0200, Andrea Greco wrote:
> From: Andrea Greco 
> 
> If com20020 clock is major of 40Mhz SLOWARB bit is requested.
> 
> Signed-off-by: Andrea Greco 
> ---
>  drivers/net/arcnet/com20020.c | 4 
>  1 file changed, 4 insertions(+)
> 
> diff --git a/drivers/net/arcnet/com20020.c b/drivers/net/arcnet/com20020.c
> index f09ea77dd6a8..abd32ed8ec9b 100644
> --- a/drivers/net/arcnet/com20020.c
> +++ b/drivers/net/arcnet/com20020.c
> @@ -102,6 +102,10 @@ int com20020_check(struct net_device *dev)
>   lp->setup = lp->clockm ? 0 : (lp->clockp << 1);
>   lp->setup2 = (lp->clockm << 4) | 8;
>  
> + // If clock is major of 40Mhz, SLOWARB bit must be set

/* C89 style comments please :) */


Hope this helps,
Tobin.

Re: [RFC PATCH 2/3] arcnet: com20020: Fixup missing SLOWARB bit

[Tobin C. Harding]

On Sat, May 05, 2018 at 11:37:54PM +0200, Andrea Greco wrote:
> From: Andrea Greco 
> 
> If com20020 clock is major of 40Mhz SLOWARB bit is requested.
> 
> Signed-off-by: Andrea Greco 
> ---
>  drivers/net/arcnet/com20020.c | 4 
>  1 file changed, 4 insertions(+)
> 
> diff --git a/drivers/net/arcnet/com20020.c b/drivers/net/arcnet/com20020.c
> index f09ea77dd6a8..abd32ed8ec9b 100644
> --- a/drivers/net/arcnet/com20020.c
> +++ b/drivers/net/arcnet/com20020.c
> @@ -102,6 +102,10 @@ int com20020_check(struct net_device *dev)
>   lp->setup = lp->clockm ? 0 : (lp->clockp << 1);
>   lp->setup2 = (lp->clockm << 4) | 8;
>  
> + // If clock is major of 40Mhz, SLOWARB bit must be set

/* C89 style comments please :) */


Hope this helps,
Tobin.

Re: [RFC PATCH 1/3] arcnet: com20020: Add memory map of com20020

[Tobin C. Harding]

On Sat, May 05, 2018 at 11:34:45PM +0200, Andrea Greco wrote:
> From: Andrea Greco 

Hi Andrea,

Here are some (mostly stylistic) suggestions to help you get your driver merged.

> Add support for com20022I/com20020, memory mapped chip version.
> Support bus: Intel 80xx and Motorola 68xx.
> Bus size: Only 8 bit bus size is supported.
> Added related device tree bindings
> 
> Signed-off-by: Andrea Greco 
> ---
>  .../devicetree/bindings/net/smsc-com20020.txt  |  23 +++
>  drivers/net/arcnet/Kconfig |  12 +-
>  drivers/net/arcnet/Makefile|   1 +
>  drivers/net/arcnet/arcdevice.h |  27 ++-
>  drivers/net/arcnet/com20020-membus.c   | 191 
> +
>  drivers/net/arcnet/com20020.c  |   9 +-
>  6 files changed, 253 insertions(+), 10 deletions(-)
>  create mode 100644 Documentation/devicetree/bindings/net/smsc-com20020.txt
>  create mode 100644 drivers/net/arcnet/com20020-membus.c
> 
> diff --git a/Documentation/devicetree/bindings/net/smsc-com20020.txt 
> b/Documentation/devicetree/bindings/net/smsc-com20020.txt
> new file mode 100644
> index ..39c5b19c55af
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/net/smsc-com20020.txt
> @@ -0,0 +1,23 @@
> +SMSC com20020, com20022I
> +
> +timeout: Arcnet timeout, checkout datashet
> +clockp: Clock Prescaler, checkout datashet
> +clockm: Clock multiplier, checkout datasheet
> +
> +phy-reset-gpios: Chip reset ppin
> +phy-irq-gpios: Chip irq pin
> +
> +com20020_A@0 {
> +compatible = "smsc,com20020";
> +
> + timeout = <0x3>;
> + backplane = <0x0>;
> +
> + clockp = <0x0>;
> + clockm = <0x3>;
> +
> + phy-reset-gpios = < 21 GPIO_ACTIVE_LOW>;
> + phy-irq-gpios = < 10 GPIO_ACTIVE_LOW>;
> +
> + status = "okay";
> +};
> diff --git a/drivers/net/arcnet/Kconfig b/drivers/net/arcnet/Kconfig
> index 39bd16f3f86d..d39faf45be1e 100644
> --- a/drivers/net/arcnet/Kconfig
> +++ b/drivers/net/arcnet/Kconfig
> @@ -3,7 +3,7 @@
>  #
>  
>  menuconfig ARCNET
> - depends on NETDEVICES && (ISA || PCI || PCMCIA)
> + depends on NETDEVICES
>   tristate "ARCnet support"
>   ---help---
> If you have a network card of this type, say Y and check out the
> @@ -129,5 +129,15 @@ config ARCNET_COM20020_CS
>  
> To compile this driver as a module, choose M here: the module will be
> called com20020_cs.  If unsure, say N.
> +config ARCNET_COM20020_MEMORY_BUS
> + bool "Support for COM20020 on external memory"
> + depends on ARCNET_COM20020 && !(ARCNET_COM20020_PCI || 
> ARCNET_COM20020_ISA || ARCNET_COM20020_CS)
> + help
> +   Say Y here if on your custom board mount com20020 or friends.
> +
> +   Com20022I support arcnet bus 10Mbitps.
> +   This driver support only 8bit

This driver only supports 8bit bus size.

>  , and DMA is not supported is attached 
> on your board at external interface bus.

This bit does not make sense, sorry.

> +   Supported bus Intel80xx / Motorola 68xx.
> +   This driver not work with other com20020 module: PCI or PCMCIA 
> compiled as [M].

I'm not sure exactly what you want to say here, perhaps:

  This driver does not work with other com20020 modules compiled
  as PCI or PCMCIA [M].
>  
>  endif # ARCNET
> diff --git a/drivers/net/arcnet/Makefile b/drivers/net/arcnet/Makefile
> index 53525e8ea130..19425c1e06f4 100644
> --- a/drivers/net/arcnet/Makefile
> +++ b/drivers/net/arcnet/Makefile
> @@ -14,3 +14,4 @@ obj-$(CONFIG_ARCNET_COM20020) += com20020.o
>  obj-$(CONFIG_ARCNET_COM20020_ISA) += com20020-isa.o
>  obj-$(CONFIG_ARCNET_COM20020_PCI) += com20020-pci.o
>  obj-$(CONFIG_ARCNET_COM20020_CS) += com20020_cs.o
> +obj-$(CONFIG_ARCNET_COM20020_MEMORY_BUS) += com20020-membus.o
> diff --git a/drivers/net/arcnet/arcdevice.h b/drivers/net/arcnet/arcdevice.h
> index d09b2b46ab63..16c608269cca 100644
> --- a/drivers/net/arcnet/arcdevice.h
> +++ b/drivers/net/arcnet/arcdevice.h
> @@ -201,7 +201,7 @@ struct ArcProto {
>   void (*rx)(struct net_device *dev, int bufnum,
>  struct archdr *pkthdr, int length);
>   int (*build_header)(struct sk_buff *skb, struct net_device *dev,
> - unsigned short ethproto, uint8_t daddr);
> + unsigned short ethproto, uint8_t daddr);

  + unsigned short ethproto, uint8_t daddr);

Please use Linux coding style style, parameters continuing on separate
line are aligned with opening parenthesis.

>   /* these functions return '1' if the skb can now be freed */
>   int (*prepare_tx)(struct net_device *dev, struct archdr *pkt,
> @@ -326,9 +326,9 @@ struct arcnet_local {
>   void (*recontrigger) (struct net_device * dev, int enable);
>  
>   void (*copy_to_card)(struct net_device *dev, int bufnum,
> -  

Re: [RFC PATCH 1/3] arcnet: com20020: Add memory map of com20020

[Tobin C. Harding]

On Sat, May 05, 2018 at 11:34:45PM +0200, Andrea Greco wrote:
> From: Andrea Greco 

Hi Andrea,

Here are some (mostly stylistic) suggestions to help you get your driver merged.

> Add support for com20022I/com20020, memory mapped chip version.
> Support bus: Intel 80xx and Motorola 68xx.
> Bus size: Only 8 bit bus size is supported.
> Added related device tree bindings
> 
> Signed-off-by: Andrea Greco 
> ---
>  .../devicetree/bindings/net/smsc-com20020.txt  |  23 +++
>  drivers/net/arcnet/Kconfig |  12 +-
>  drivers/net/arcnet/Makefile|   1 +
>  drivers/net/arcnet/arcdevice.h |  27 ++-
>  drivers/net/arcnet/com20020-membus.c   | 191 
> +
>  drivers/net/arcnet/com20020.c  |   9 +-
>  6 files changed, 253 insertions(+), 10 deletions(-)
>  create mode 100644 Documentation/devicetree/bindings/net/smsc-com20020.txt
>  create mode 100644 drivers/net/arcnet/com20020-membus.c
> 
> diff --git a/Documentation/devicetree/bindings/net/smsc-com20020.txt 
> b/Documentation/devicetree/bindings/net/smsc-com20020.txt
> new file mode 100644
> index ..39c5b19c55af
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/net/smsc-com20020.txt
> @@ -0,0 +1,23 @@
> +SMSC com20020, com20022I
> +
> +timeout: Arcnet timeout, checkout datashet
> +clockp: Clock Prescaler, checkout datashet
> +clockm: Clock multiplier, checkout datasheet
> +
> +phy-reset-gpios: Chip reset ppin
> +phy-irq-gpios: Chip irq pin
> +
> +com20020_A@0 {
> +compatible = "smsc,com20020";
> +
> + timeout = <0x3>;
> + backplane = <0x0>;
> +
> + clockp = <0x0>;
> + clockm = <0x3>;
> +
> + phy-reset-gpios = < 21 GPIO_ACTIVE_LOW>;
> + phy-irq-gpios = < 10 GPIO_ACTIVE_LOW>;
> +
> + status = "okay";
> +};
> diff --git a/drivers/net/arcnet/Kconfig b/drivers/net/arcnet/Kconfig
> index 39bd16f3f86d..d39faf45be1e 100644
> --- a/drivers/net/arcnet/Kconfig
> +++ b/drivers/net/arcnet/Kconfig
> @@ -3,7 +3,7 @@
>  #
>  
>  menuconfig ARCNET
> - depends on NETDEVICES && (ISA || PCI || PCMCIA)
> + depends on NETDEVICES
>   tristate "ARCnet support"
>   ---help---
> If you have a network card of this type, say Y and check out the
> @@ -129,5 +129,15 @@ config ARCNET_COM20020_CS
>  
> To compile this driver as a module, choose M here: the module will be
> called com20020_cs.  If unsure, say N.
> +config ARCNET_COM20020_MEMORY_BUS
> + bool "Support for COM20020 on external memory"
> + depends on ARCNET_COM20020 && !(ARCNET_COM20020_PCI || 
> ARCNET_COM20020_ISA || ARCNET_COM20020_CS)
> + help
> +   Say Y here if on your custom board mount com20020 or friends.
> +
> +   Com20022I support arcnet bus 10Mbitps.
> +   This driver support only 8bit

This driver only supports 8bit bus size.

>  , and DMA is not supported is attached 
> on your board at external interface bus.

This bit does not make sense, sorry.

> +   Supported bus Intel80xx / Motorola 68xx.
> +   This driver not work with other com20020 module: PCI or PCMCIA 
> compiled as [M].

I'm not sure exactly what you want to say here, perhaps:

  This driver does not work with other com20020 modules compiled
  as PCI or PCMCIA [M].
>  
>  endif # ARCNET
> diff --git a/drivers/net/arcnet/Makefile b/drivers/net/arcnet/Makefile
> index 53525e8ea130..19425c1e06f4 100644
> --- a/drivers/net/arcnet/Makefile
> +++ b/drivers/net/arcnet/Makefile
> @@ -14,3 +14,4 @@ obj-$(CONFIG_ARCNET_COM20020) += com20020.o
>  obj-$(CONFIG_ARCNET_COM20020_ISA) += com20020-isa.o
>  obj-$(CONFIG_ARCNET_COM20020_PCI) += com20020-pci.o
>  obj-$(CONFIG_ARCNET_COM20020_CS) += com20020_cs.o
> +obj-$(CONFIG_ARCNET_COM20020_MEMORY_BUS) += com20020-membus.o
> diff --git a/drivers/net/arcnet/arcdevice.h b/drivers/net/arcnet/arcdevice.h
> index d09b2b46ab63..16c608269cca 100644
> --- a/drivers/net/arcnet/arcdevice.h
> +++ b/drivers/net/arcnet/arcdevice.h
> @@ -201,7 +201,7 @@ struct ArcProto {
>   void (*rx)(struct net_device *dev, int bufnum,
>  struct archdr *pkthdr, int length);
>   int (*build_header)(struct sk_buff *skb, struct net_device *dev,
> - unsigned short ethproto, uint8_t daddr);
> + unsigned short ethproto, uint8_t daddr);

  + unsigned short ethproto, uint8_t daddr);

Please use Linux coding style style, parameters continuing on separate
line are aligned with opening parenthesis.

>   /* these functions return '1' if the skb can now be freed */
>   int (*prepare_tx)(struct net_device *dev, struct archdr *pkt,
> @@ -326,9 +326,9 @@ struct arcnet_local {
>   void (*recontrigger) (struct net_device * dev, int enable);
>  
>   void (*copy_to_card)(struct net_device *dev, int bufnum,
> -  int offset, 

Re: [PATCH 1/2] kdump/x86: crashkernel=X try to reserve below 896M first then below 4G and MAXMEM

[Dave Young]

On 04/27/18 at 05:14pm, Dave Young wrote:
> Hi,
>  
> This is a resend of below patches:
> http://lists.infradead.org/pipermail/kexec/2017-October/019569.html
>  
> I dropped the original patch 1 since Baoquan is not happy with it.
> For patch 2 (the 1st patch in this series), there is some improvement
> comment from Baoquan to create some generic memblock iteration function.
> But nobody has time to work on it for the time being.  According to
> offline discussion with him.  That can be done in the future if someone
> is interested.  We can go with the current kdump only fixes.
>  
> Other than above,  the patches are just same.

Hi Andrew, do you have concerns about the patches?  It has been used for
long time in Red Hat kernel, since people do not object them, could you
pick them if no other concerns?

Thanks
Dave

Re: [PATCH 1/2] kdump/x86: crashkernel=X try to reserve below 896M first then below 4G and MAXMEM

[Dave Young]

On 04/27/18 at 05:14pm, Dave Young wrote:
> Hi,
>  
> This is a resend of below patches:
> http://lists.infradead.org/pipermail/kexec/2017-October/019569.html
>  
> I dropped the original patch 1 since Baoquan is not happy with it.
> For patch 2 (the 1st patch in this series), there is some improvement
> comment from Baoquan to create some generic memblock iteration function.
> But nobody has time to work on it for the time being.  According to
> offline discussion with him.  That can be done in the future if someone
> is interested.  We can go with the current kdump only fixes.
>  
> Other than above,  the patches are just same.

Hi Andrew, do you have concerns about the patches?  It has been used for
long time in Red Hat kernel, since people do not object them, could you
pick them if no other concerns?

Thanks
Dave

RE: [PATCH] Documentation: block: cmdline-partition.txt fixes and additions

[Caizhiyong]

> -Original Message-
> From: Randy Dunlap [mailto:rdun...@infradead.org]
> Sent: Monday, May 07, 2018 2:50 AM
> To: linux-bl...@vger.kernel.org; axboe 
> Cc: LKML ; Caizhiyong
> ; Andrew Morton ;
> linux-...@vger.kernel.org; Jonathan Corbet 
> Subject: [PATCH] Documentation: block: cmdline-partition.txt fixes and
> additions
> 
> From: Randy Dunlap 
> 
> Make the description of the kernel command line option "blkdevparts"
> a bit more flowing and readable.
> 
> Fix a few typos.
> Add the optional  and  suffixes.
> Note that size can be "-" to indicate all of the remaining space.
> 
> Signed-off-by: Randy Dunlap 
> Cc: Cai Zhiyong 
> ---
> Should the "ro" and "lk" flags options be described?

thank you for fix typos.
The "ro" and "lk" feature are not implemented in block devices. could you 
implement them?

>  Documentation/block/cmdline-partition.txt |   21 +---
>  1 file changed, 14 insertions(+), 7 deletions(-)
> 
> --- linux-next-20180504.orig/Documentation/block/cmdline-partition.txt
> +++ linux-next-20180504/Documentation/block/cmdline-partition.txt
> @@ -1,7 +1,9 @@
>  Embedded device command line partition parsing
> 
> ==
> ===
> 
> -Support for reading the block device partition table from the command line.
> +The "blkdevparts" command line option adds support for reading the
> +block device partition table from the kernel command line.
> +
>  It is typically used for fixed block (eMMC) embedded devices.
>  It has no MBR, so saves storage space. Bootloader can be easily accessed
>  by absolute address of data on the block device.
> @@ -14,22 +16,27 @@ blkdevparts=[;]
>   := [@](part-name)
> 
>  
> -block device disk name, embedded device used fixed block device,
> -it's disk name also fixed. such as: mmcblk0, mmcblk1, mmcblk0boot0.
> +block device disk name. Embedded device uses fixed block device.
> +Its disk name is also fixed, such as: mmcblk0, mmcblk1, mmcblk0boot0.
> 
>  
>  partition size, in bytes, such as: 512, 1m, 1G.
> +size may contain an optional suffix of (upper or lower case):
> +  K, M, G, T, P, E.
> +"-" is used to denote all remaining space.
> 
>  
>  partition start address, in bytes.
> +offset may contain an optional suffix of (upper or lower case):
> +  K, M, G, T, P, E.
> 
>  (part-name)
> -partition name, kernel send uevent with "PARTNAME". application can
> create
> -a link to block device partition with the name "PARTNAME".
> -user space application can access partition by partition name.
> +partition name. Kernel sends uevent with "PARTNAME". Application can
> +create a link to block device partition with the name "PARTNAME".
> +User space application can access partition by partition name.
> 
>  Example:
> -eMMC disk name is "mmcblk0" and "mmcblk0boot0"
> +eMMC disk names are "mmcblk0" and "mmcblk0boot0".
> 
>bootargs:
>  'blkdevparts=mmcblk0:1G(data0),1G(data1),-;mmcblk0boot0:1m(boot),-
> (kernel)'

RE: [PATCH] Documentation: block: cmdline-partition.txt fixes and additions

[Caizhiyong]

> -Original Message-
> From: Randy Dunlap [mailto:rdun...@infradead.org]
> Sent: Monday, May 07, 2018 2:50 AM
> To: linux-bl...@vger.kernel.org; axboe 
> Cc: LKML ; Caizhiyong
> ; Andrew Morton ;
> linux-...@vger.kernel.org; Jonathan Corbet 
> Subject: [PATCH] Documentation: block: cmdline-partition.txt fixes and
> additions
> 
> From: Randy Dunlap 
> 
> Make the description of the kernel command line option "blkdevparts"
> a bit more flowing and readable.
> 
> Fix a few typos.
> Add the optional  and  suffixes.
> Note that size can be "-" to indicate all of the remaining space.
> 
> Signed-off-by: Randy Dunlap 
> Cc: Cai Zhiyong 
> ---
> Should the "ro" and "lk" flags options be described?

thank you for fix typos.
The "ro" and "lk" feature are not implemented in block devices. could you 
implement them?

>  Documentation/block/cmdline-partition.txt |   21 +---
>  1 file changed, 14 insertions(+), 7 deletions(-)
> 
> --- linux-next-20180504.orig/Documentation/block/cmdline-partition.txt
> +++ linux-next-20180504/Documentation/block/cmdline-partition.txt
> @@ -1,7 +1,9 @@
>  Embedded device command line partition parsing
> 
> ==
> ===
> 
> -Support for reading the block device partition table from the command line.
> +The "blkdevparts" command line option adds support for reading the
> +block device partition table from the kernel command line.
> +
>  It is typically used for fixed block (eMMC) embedded devices.
>  It has no MBR, so saves storage space. Bootloader can be easily accessed
>  by absolute address of data on the block device.
> @@ -14,22 +16,27 @@ blkdevparts=[;]
>   := [@](part-name)
> 
>  
> -block device disk name, embedded device used fixed block device,
> -it's disk name also fixed. such as: mmcblk0, mmcblk1, mmcblk0boot0.
> +block device disk name. Embedded device uses fixed block device.
> +Its disk name is also fixed, such as: mmcblk0, mmcblk1, mmcblk0boot0.
> 
>  
>  partition size, in bytes, such as: 512, 1m, 1G.
> +size may contain an optional suffix of (upper or lower case):
> +  K, M, G, T, P, E.
> +"-" is used to denote all remaining space.
> 
>  
>  partition start address, in bytes.
> +offset may contain an optional suffix of (upper or lower case):
> +  K, M, G, T, P, E.
> 
>  (part-name)
> -partition name, kernel send uevent with "PARTNAME". application can
> create
> -a link to block device partition with the name "PARTNAME".
> -user space application can access partition by partition name.
> +partition name. Kernel sends uevent with "PARTNAME". Application can
> +create a link to block device partition with the name "PARTNAME".
> +User space application can access partition by partition name.
> 
>  Example:
> -eMMC disk name is "mmcblk0" and "mmcblk0boot0"
> +eMMC disk names are "mmcblk0" and "mmcblk0boot0".
> 
>bootargs:
>  'blkdevparts=mmcblk0:1G(data0),1G(data1),-;mmcblk0boot0:1m(boot),-
> (kernel)'

Re: [PATCH BUGFIX] block, bfq: postpone rq preparation to insert or merge

[Mike Galbraith]

On Sun, 2018-05-06 at 09:42 +0200, Paolo Valente wrote:
> 
> I've attached a compressed patch (to avoid possible corruption from my
> mailer).  I'm little confident, but no pain, no gain, right?
> 
> If possible, apply this patch on top of the fix I proposed in this
> thread, just to eliminate possible further noise. Finally, the
> patch content follows.
> 
> Hoping for a stroke of luck,

FWIW, box didn't survive the first full build of the morning.

> Paolo
> 
> diff --git a/block/bfq-mq-iosched.c b/block/bfq-mq-iosched.c
> index 118f319af7c0..6662efe29b69 100644
> --- a/block/bfq-mq-iosched.c
> +++ b/block/bfq-mq-iosched.c

That doesn't exist in master, so I applied it like so.

---
 block/bfq-iosched.c |4 
 1 file changed, 4 insertions(+)

--- a/block/bfq-iosched.c
+++ b/block/bfq-iosched.c
@@ -554,8 +554,12 @@ static void bfq_limit_depth(unsigned int
if (unlikely(bfqd->sb_shift != bt->sb.shift))
bfq_update_depths(bfqd, bt);
 
+#if 0
data->shallow_depth =
bfqd->word_depths[!!bfqd->wr_busy_queues][op_is_sync(op)];
+#else
+   data->shallow_depth = 1;
+#endif
 
bfq_log(bfqd, "[%s] wr_busy %d sync %d depth %u",
__func__, bfqd->wr_busy_queues, op_is_sync(op),

Re: [PATCH BUGFIX] block, bfq: postpone rq preparation to insert or merge

[Mike Galbraith]

On Sun, 2018-05-06 at 09:42 +0200, Paolo Valente wrote:
> 
> I've attached a compressed patch (to avoid possible corruption from my
> mailer).  I'm little confident, but no pain, no gain, right?
> 
> If possible, apply this patch on top of the fix I proposed in this
> thread, just to eliminate possible further noise. Finally, the
> patch content follows.
> 
> Hoping for a stroke of luck,

FWIW, box didn't survive the first full build of the morning.

> Paolo
> 
> diff --git a/block/bfq-mq-iosched.c b/block/bfq-mq-iosched.c
> index 118f319af7c0..6662efe29b69 100644
> --- a/block/bfq-mq-iosched.c
> +++ b/block/bfq-mq-iosched.c

That doesn't exist in master, so I applied it like so.

---
 block/bfq-iosched.c |4 
 1 file changed, 4 insertions(+)

--- a/block/bfq-iosched.c
+++ b/block/bfq-iosched.c
@@ -554,8 +554,12 @@ static void bfq_limit_depth(unsigned int
if (unlikely(bfqd->sb_shift != bt->sb.shift))
bfq_update_depths(bfqd, bt);
 
+#if 0
data->shallow_depth =
bfqd->word_depths[!!bfqd->wr_busy_queues][op_is_sync(op)];
+#else
+   data->shallow_depth = 1;
+#endif
 
bfq_log(bfqd, "[%s] wr_busy %d sync %d depth %u",
__func__, bfqd->wr_busy_queues, op_is_sync(op),

Re: [PATCH 1/6] powerpc/syscalls: Switch trivial cases to SYSCALL_DEFINE

[Michael Ellerman]

"Naveen N. Rao"  writes:

> Michael Ellerman wrote:
>> From: Al Viro 
>> 
>> Signed-off-by: Al Viro 
>> ---
>>  arch/powerpc/kernel/pci_32.c   | 6 +++---
>>  arch/powerpc/kernel/pci_64.c   | 4 ++--
>>  arch/powerpc/mm/subpage-prot.c | 4 +++-
>>  arch/powerpc/platforms/cell/spu_syscalls.c | 3 ++-
>>  4 files changed, 10 insertions(+), 7 deletions(-)
>> 
>
> I suppose we can also do this for switch_endian?

Yeah. It'd nice to have an automated test that every syscall is
available via FTRACE_SYSCALLS, I just haven't got around to writing one.

cheers

> diff --git a/arch/powerpc/kernel/syscalls.c b/arch/powerpc/kernel/syscalls.c
> index 466216506eb2..290265f2700c 100644
> --- a/arch/powerpc/kernel/syscalls.c
> +++ b/arch/powerpc/kernel/syscalls.c
> @@ -123,7 +123,7 @@ long ppc_fadvise64_64(int fd, int advice, u32 
> offset_high, u32 offset_low,
>(u64)len_high << 32 | len_low, advice);
>  }
>  
> -long sys_switch_endian(void)
> +SYSCALL_DEFINE0(switch_endian)
>  {
>   struct thread_info *ti;
>
>
> - Naveen

Re: [PATCH 1/6] powerpc/syscalls: Switch trivial cases to SYSCALL_DEFINE

[Michael Ellerman]

"Naveen N. Rao"  writes:

> Michael Ellerman wrote:
>> From: Al Viro 
>> 
>> Signed-off-by: Al Viro 
>> ---
>>  arch/powerpc/kernel/pci_32.c   | 6 +++---
>>  arch/powerpc/kernel/pci_64.c   | 4 ++--
>>  arch/powerpc/mm/subpage-prot.c | 4 +++-
>>  arch/powerpc/platforms/cell/spu_syscalls.c | 3 ++-
>>  4 files changed, 10 insertions(+), 7 deletions(-)
>> 
>
> I suppose we can also do this for switch_endian?

Yeah. It'd nice to have an automated test that every syscall is
available via FTRACE_SYSCALLS, I just haven't got around to writing one.

cheers

> diff --git a/arch/powerpc/kernel/syscalls.c b/arch/powerpc/kernel/syscalls.c
> index 466216506eb2..290265f2700c 100644
> --- a/arch/powerpc/kernel/syscalls.c
> +++ b/arch/powerpc/kernel/syscalls.c
> @@ -123,7 +123,7 @@ long ppc_fadvise64_64(int fd, int advice, u32 
> offset_high, u32 offset_low,
>(u64)len_high << 32 | len_low, advice);
>  }
>  
> -long sys_switch_endian(void)
> +SYSCALL_DEFINE0(switch_endian)
>  {
>   struct thread_info *ti;
>
>
> - Naveen

Re: moving affs + RDB partition support to staging?

[Michael Schmitz]

Al,

I don't think there is USB sticks with affs on them as yet. There
isn't even USB host controller support for Amiga hardware (yet).

Last I tried USB on m68k (Atari, 060 accelerator) the desktop
experience was such that I'd rather not repeat that in a hurry (and
that was a simple FAT USB stick).

I see your point regarding the immense practical joke value on any
desktop PC ... my work desktop has the affs module present. Happy to
try this out if someone can provide a sample disk image suitable for
USB flash media.

Cheers,

  Michael


On Mon, May 7, 2018 at 2:15 PM, Al Viro  wrote:
> On Sun, May 06, 2018 at 10:32:47PM +0100, Al Viro wrote:
>> On Sun, May 06, 2018 at 09:46:23PM +0100, Al Viro wrote:
>>
>> > I'm fixing that pile of crap (along with the NFS exports
>> > one and, hopefully, rename mess as well).  HOWEVER, I am not going
>> > to take over the damn thing - David has violated the 11th
>> > commandment (Thou Shalt Never Volunteer), so he gets to joy of
>> > learning that codebase and taking care of it from now on.
>>
>>   Same scenario on link(2) ends up with
>> * ST_LINKFILE created, inserted into the link chain and left around,
>> without being present in any hash chain
>> * target becoming positive hashed dentry, as if link(2) has succeeded,
>> so dcache lookups will be finding it (for a while)
>> * unlink(2) on source will have very interesting effects, what with
>> the attempts to move ST_FILE entry into the directory presumed to
>> contain ST_LINKFILE one, removing ST_LINKFILE from it at the same time.
>
> Oh, lovely...  Looks like that thing wants the hash chains sorted by
> block number.  affs_insert_hash() doesn't give a toss - it always
> adds to the very end of chain.
>
> Maintaining that requirement (and I can understand the rationale -
> they don't want too many back-and-forth seeks on directory lookups)
> is going to be great fun on rename(), especially for the case when
> the target of rename happens to be a primary name for a file with
> additional hardlinks.
>
> I think I see how to deal with that sanely, but... ouch.
>
> Incidentally, we'd better verify that hash chains are not looped - as it
> is, there's no checks whatsoever, and it *will* happily loop if you
> feed it an image with such braindamage.  I really hope that no fan of
> desktop experience has set the things up for e.g. USB sticks with
> that on them being recognized and automounted on insertion...
> --
> To unsubscribe from this list: send the line "unsubscribe linux-m68k" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: moving affs + RDB partition support to staging?

[Michael Schmitz]

Al,

I don't think there is USB sticks with affs on them as yet. There
isn't even USB host controller support for Amiga hardware (yet).

Last I tried USB on m68k (Atari, 060 accelerator) the desktop
experience was such that I'd rather not repeat that in a hurry (and
that was a simple FAT USB stick).

I see your point regarding the immense practical joke value on any
desktop PC ... my work desktop has the affs module present. Happy to
try this out if someone can provide a sample disk image suitable for
USB flash media.

Cheers,

  Michael


On Mon, May 7, 2018 at 2:15 PM, Al Viro  wrote:
> On Sun, May 06, 2018 at 10:32:47PM +0100, Al Viro wrote:
>> On Sun, May 06, 2018 at 09:46:23PM +0100, Al Viro wrote:
>>
>> > I'm fixing that pile of crap (along with the NFS exports
>> > one and, hopefully, rename mess as well).  HOWEVER, I am not going
>> > to take over the damn thing - David has violated the 11th
>> > commandment (Thou Shalt Never Volunteer), so he gets to joy of
>> > learning that codebase and taking care of it from now on.
>>
>>   Same scenario on link(2) ends up with
>> * ST_LINKFILE created, inserted into the link chain and left around,
>> without being present in any hash chain
>> * target becoming positive hashed dentry, as if link(2) has succeeded,
>> so dcache lookups will be finding it (for a while)
>> * unlink(2) on source will have very interesting effects, what with
>> the attempts to move ST_FILE entry into the directory presumed to
>> contain ST_LINKFILE one, removing ST_LINKFILE from it at the same time.
>
> Oh, lovely...  Looks like that thing wants the hash chains sorted by
> block number.  affs_insert_hash() doesn't give a toss - it always
> adds to the very end of chain.
>
> Maintaining that requirement (and I can understand the rationale -
> they don't want too many back-and-forth seeks on directory lookups)
> is going to be great fun on rename(), especially for the case when
> the target of rename happens to be a primary name for a file with
> additional hardlinks.
>
> I think I see how to deal with that sanely, but... ouch.
>
> Incidentally, we'd better verify that hash chains are not looped - as it
> is, there's no checks whatsoever, and it *will* happily loop if you
> feed it an image with such braindamage.  I really hope that no fan of
> desktop experience has set the things up for e.g. USB sticks with
> that on them being recognized and automounted on insertion...
> --
> To unsubscribe from this list: send the line "unsubscribe linux-m68k" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

RE: [PATCH v3] block: add verifier for cmdline partition

[Caizhiyong]

>  /*
>   * Purpose: allocate cmdline partitions.
>   * Returns:
> @@ -93,6 +158,7 @@ int cmdline_partition(struct parsed_partitions *state)
>   disk_size = get_capacity(state->bdev->bd_disk) << 9;
> 
>   cmdline_parts_set(parts, disk_size, 1, add_part, (void *)state);
> + cmdline_parts_verifier(1, (void *)state);

cmdline_parts_verifier(1, state); 

> 
>   strlcat(state->pp_buf, "\n", PAGE_SIZE);
> 
> --
> 1.8.5.6.2.g3d8a54e.dirty

RE: [PATCH v3] block: add verifier for cmdline partition

[Caizhiyong]

>  /*
>   * Purpose: allocate cmdline partitions.
>   * Returns:
> @@ -93,6 +158,7 @@ int cmdline_partition(struct parsed_partitions *state)
>   disk_size = get_capacity(state->bdev->bd_disk) << 9;
> 
>   cmdline_parts_set(parts, disk_size, 1, add_part, (void *)state);
> + cmdline_parts_verifier(1, (void *)state);

cmdline_parts_verifier(1, state); 

> 
>   strlcat(state->pp_buf, "\n", PAGE_SIZE);
> 
> --
> 1.8.5.6.2.g3d8a54e.dirty

Re: [PATCH v3 5/9] ALSA: hda/ca0132: add/change helper functions for R3Di and SBZ

[Takashi Sakamoto]

Hi,

On May 6 2018 04:03, Connor McAdams wrote:

Edit core functions to support the Sound Blaster Z and Recon3Di for
startup and loading of the DSP, as well as setting effects.

Signed-off-by: Connor McAdams 
---
  sound/pci/hda/patch_ca0132.c | 1064 --
  1 file changed, 1018 insertions(+), 46 deletions(-)


In my opinion, this patch is too large. This patch can be split into
several parts:

 * Changes for signature of 'dspio_scp()' to get 'src_id'
  * dspio_scp()
  * dspio_set_param()
  * dspio_set_uint_param()
  * dspio_alloc_dma_chan()
  * dspio_free_dma_chan()
 * Changes for SBZ only
 * Changes for R3Di only

Could you please prepare for these three patches from this large patch 
in your next chance? Especially, you can describe enough information to 
the latter two patches as patch comment.



Thanks

Takashi Sakamoto

Re: [PATCH v3 5/9] ALSA: hda/ca0132: add/change helper functions for R3Di and SBZ

[Takashi Sakamoto]

Hi,

On May 6 2018 04:03, Connor McAdams wrote:

Edit core functions to support the Sound Blaster Z and Recon3Di for
startup and loading of the DSP, as well as setting effects.

Signed-off-by: Connor McAdams 
---
  sound/pci/hda/patch_ca0132.c | 1064 --
  1 file changed, 1018 insertions(+), 46 deletions(-)


In my opinion, this patch is too large. This patch can be split into
several parts:

 * Changes for signature of 'dspio_scp()' to get 'src_id'
  * dspio_scp()
  * dspio_set_param()
  * dspio_set_uint_param()
  * dspio_alloc_dma_chan()
  * dspio_free_dma_chan()
 * Changes for SBZ only
 * Changes for R3Di only

Could you please prepare for these three patches from this large patch 
in your next chance? Especially, you can describe enough information to 
the latter two patches as patch comment.



Thanks

Takashi Sakamoto

[PATCH] pinctrl: mvebu: use correct MPP sel value for dev pins

[Chris Packham]

The "dev" function is selected with the value 0x4 not 0x01.

Fixes: commit d7ae8f8dee7f ("pinctrl: mvebu: pinctrl driver for 98DX3236 SoC")
Signed-off-by: Chris Packham 
---
 drivers/pinctrl/mvebu/pinctrl-armada-xp.c | 20 ++--
 1 file changed, 10 insertions(+), 10 deletions(-)

diff --git a/drivers/pinctrl/mvebu/pinctrl-armada-xp.c 
b/drivers/pinctrl/mvebu/pinctrl-armada-xp.c
index 28b199796fae..5e828468e43d 100644
--- a/drivers/pinctrl/mvebu/pinctrl-armada-xp.c
+++ b/drivers/pinctrl/mvebu/pinctrl-armada-xp.c
@@ -437,34 +437,34 @@ static struct mvebu_mpp_mode mv98dx3236_mpp_modes[] = {
 MPP_VAR_FUNCTION(0x4, "dev", "we0", V_98DX3236_PLUS)),
MPP_MODE(21,
 MPP_VAR_FUNCTION(0x0, "gpo", NULL,  V_98DX3236_PLUS),
-MPP_VAR_FUNCTION(0x1, "dev", "ad0", V_98DX3236_PLUS)),
+MPP_VAR_FUNCTION(0x4, "dev", "ad0", V_98DX3236_PLUS)),
MPP_MODE(22,
 MPP_VAR_FUNCTION(0x0, "gpo", NULL,  V_98DX3236_PLUS),
-MPP_VAR_FUNCTION(0x1, "dev", "ad1", V_98DX3236_PLUS)),
+MPP_VAR_FUNCTION(0x4, "dev", "ad1", V_98DX3236_PLUS)),
MPP_MODE(23,
 MPP_VAR_FUNCTION(0x0, "gpo", NULL,  V_98DX3236_PLUS),
-MPP_VAR_FUNCTION(0x1, "dev", "ad2", V_98DX3236_PLUS)),
+MPP_VAR_FUNCTION(0x4, "dev", "ad2", V_98DX3236_PLUS)),
MPP_MODE(24,
 MPP_VAR_FUNCTION(0x0, "gpo", NULL,  V_98DX3236_PLUS),
-MPP_VAR_FUNCTION(0x1, "dev", "ad3", V_98DX3236_PLUS)),
+MPP_VAR_FUNCTION(0x4, "dev", "ad3", V_98DX3236_PLUS)),
MPP_MODE(25,
 MPP_VAR_FUNCTION(0x0, "gpo", NULL,  V_98DX3236_PLUS),
-MPP_VAR_FUNCTION(0x1, "dev", "ad4", V_98DX3236_PLUS)),
+MPP_VAR_FUNCTION(0x4, "dev", "ad4", V_98DX3236_PLUS)),
MPP_MODE(26,
 MPP_VAR_FUNCTION(0x0, "gpo", NULL,  V_98DX3236_PLUS),
-MPP_VAR_FUNCTION(0x1, "dev", "ad5", V_98DX3236_PLUS)),
+MPP_VAR_FUNCTION(0x4, "dev", "ad5", V_98DX3236_PLUS)),
MPP_MODE(27,
 MPP_VAR_FUNCTION(0x0, "gpo", NULL,  V_98DX3236_PLUS),
-MPP_VAR_FUNCTION(0x1, "dev", "ad6", V_98DX3236_PLUS)),
+MPP_VAR_FUNCTION(0x4, "dev", "ad6", V_98DX3236_PLUS)),
MPP_MODE(28,
 MPP_VAR_FUNCTION(0x0, "gpo", NULL,  V_98DX3236_PLUS),
-MPP_VAR_FUNCTION(0x1, "dev", "ad7", V_98DX3236_PLUS)),
+MPP_VAR_FUNCTION(0x4, "dev", "ad7", V_98DX3236_PLUS)),
MPP_MODE(29,
 MPP_VAR_FUNCTION(0x0, "gpo", NULL,  V_98DX3236_PLUS),
-MPP_VAR_FUNCTION(0x1, "dev", "a0",  V_98DX3236_PLUS)),
+MPP_VAR_FUNCTION(0x4, "dev", "a0",  V_98DX3236_PLUS)),
MPP_MODE(30,
 MPP_VAR_FUNCTION(0x0, "gpo", NULL,  V_98DX3236_PLUS),
-MPP_VAR_FUNCTION(0x1, "dev", "a1",  V_98DX3236_PLUS)),
+MPP_VAR_FUNCTION(0x4, "dev", "a1",  V_98DX3236_PLUS)),
MPP_MODE(31,
 MPP_VAR_FUNCTION(0x0, "gpio", NULL, V_98DX3236_PLUS),
 MPP_VAR_FUNCTION(0x1, "slv_smi", "mdc", V_98DX3236_PLUS),
-- 
2.17.0

[PATCH] pinctrl: mvebu: use correct MPP sel value for dev pins

[Chris Packham]

The "dev" function is selected with the value 0x4 not 0x01.

Fixes: commit d7ae8f8dee7f ("pinctrl: mvebu: pinctrl driver for 98DX3236 SoC")
Signed-off-by: Chris Packham 
---
 drivers/pinctrl/mvebu/pinctrl-armada-xp.c | 20 ++--
 1 file changed, 10 insertions(+), 10 deletions(-)

diff --git a/drivers/pinctrl/mvebu/pinctrl-armada-xp.c 
b/drivers/pinctrl/mvebu/pinctrl-armada-xp.c
index 28b199796fae..5e828468e43d 100644
--- a/drivers/pinctrl/mvebu/pinctrl-armada-xp.c
+++ b/drivers/pinctrl/mvebu/pinctrl-armada-xp.c
@@ -437,34 +437,34 @@ static struct mvebu_mpp_mode mv98dx3236_mpp_modes[] = {
 MPP_VAR_FUNCTION(0x4, "dev", "we0", V_98DX3236_PLUS)),
MPP_MODE(21,
 MPP_VAR_FUNCTION(0x0, "gpo", NULL,  V_98DX3236_PLUS),
-MPP_VAR_FUNCTION(0x1, "dev", "ad0", V_98DX3236_PLUS)),
+MPP_VAR_FUNCTION(0x4, "dev", "ad0", V_98DX3236_PLUS)),
MPP_MODE(22,
 MPP_VAR_FUNCTION(0x0, "gpo", NULL,  V_98DX3236_PLUS),
-MPP_VAR_FUNCTION(0x1, "dev", "ad1", V_98DX3236_PLUS)),
+MPP_VAR_FUNCTION(0x4, "dev", "ad1", V_98DX3236_PLUS)),
MPP_MODE(23,
 MPP_VAR_FUNCTION(0x0, "gpo", NULL,  V_98DX3236_PLUS),
-MPP_VAR_FUNCTION(0x1, "dev", "ad2", V_98DX3236_PLUS)),
+MPP_VAR_FUNCTION(0x4, "dev", "ad2", V_98DX3236_PLUS)),
MPP_MODE(24,
 MPP_VAR_FUNCTION(0x0, "gpo", NULL,  V_98DX3236_PLUS),
-MPP_VAR_FUNCTION(0x1, "dev", "ad3", V_98DX3236_PLUS)),
+MPP_VAR_FUNCTION(0x4, "dev", "ad3", V_98DX3236_PLUS)),
MPP_MODE(25,
 MPP_VAR_FUNCTION(0x0, "gpo", NULL,  V_98DX3236_PLUS),
-MPP_VAR_FUNCTION(0x1, "dev", "ad4", V_98DX3236_PLUS)),
+MPP_VAR_FUNCTION(0x4, "dev", "ad4", V_98DX3236_PLUS)),
MPP_MODE(26,
 MPP_VAR_FUNCTION(0x0, "gpo", NULL,  V_98DX3236_PLUS),
-MPP_VAR_FUNCTION(0x1, "dev", "ad5", V_98DX3236_PLUS)),
+MPP_VAR_FUNCTION(0x4, "dev", "ad5", V_98DX3236_PLUS)),
MPP_MODE(27,
 MPP_VAR_FUNCTION(0x0, "gpo", NULL,  V_98DX3236_PLUS),
-MPP_VAR_FUNCTION(0x1, "dev", "ad6", V_98DX3236_PLUS)),
+MPP_VAR_FUNCTION(0x4, "dev", "ad6", V_98DX3236_PLUS)),
MPP_MODE(28,
 MPP_VAR_FUNCTION(0x0, "gpo", NULL,  V_98DX3236_PLUS),
-MPP_VAR_FUNCTION(0x1, "dev", "ad7", V_98DX3236_PLUS)),
+MPP_VAR_FUNCTION(0x4, "dev", "ad7", V_98DX3236_PLUS)),
MPP_MODE(29,
 MPP_VAR_FUNCTION(0x0, "gpo", NULL,  V_98DX3236_PLUS),
-MPP_VAR_FUNCTION(0x1, "dev", "a0",  V_98DX3236_PLUS)),
+MPP_VAR_FUNCTION(0x4, "dev", "a0",  V_98DX3236_PLUS)),
MPP_MODE(30,
 MPP_VAR_FUNCTION(0x0, "gpo", NULL,  V_98DX3236_PLUS),
-MPP_VAR_FUNCTION(0x1, "dev", "a1",  V_98DX3236_PLUS)),
+MPP_VAR_FUNCTION(0x4, "dev", "a1",  V_98DX3236_PLUS)),
MPP_MODE(31,
 MPP_VAR_FUNCTION(0x0, "gpio", NULL, V_98DX3236_PLUS),
 MPP_VAR_FUNCTION(0x1, "slv_smi", "mdc", V_98DX3236_PLUS),
-- 
2.17.0

Re: [PATCH] iio: humidity: hts221: Fix sensor reads after resume

[Shrirang Bagul]

On Sun, 2018-05-06 at 17:19 +0100, Jonathan Cameron wrote:
> On Mon, 30 Apr 2018 12:25:46 +0800
> Shrirang Bagul  wrote:
> 
> > CTRL1 register (ODR & BDU settings) gets reset after system comes back
> > from suspend, causing subsequent reads from the sensor to fail.
> > 
> > This patch restores the CTRL1 register after resume.
> > 
> > Based on:
> > git://git.kernel.org/pub/scm/linux/kernel/git/jic23/iio.git 
> > iio-fixes-for-4.14b
> > 
> > Since 4.17.rc1, this driver uses REGMAP; I'll send a separate patch to
> > address this issue.
> > 
> > Cc: sta...@vger.kernel.org
> > Fixes: ffebe74b7c95 (iio: humidity: hts221: avoid useless ODR 
> > reconfiguration)
> 
> Looks like part of the problem was introduced in that patch, part well 
> predated
> it (BDU).
> 
> > Signed-off-by: Shrirang Bagul 
> 
> As you way, this needs to be a bit different to take into account
> the change to regmap.  We'll need to have that upstream before we look
> at a back port.  One element inline surprises me and needs further
> explanation.
I have sent a patch based on iio-for-4.17b [1], Lorenzo and I are still 
discussing our findings. It's not just the CTRL1 reg, but also the 
AV_CONF(0x10) reg.
which loses it's contents coming out of suspend.

[1] https://marc.info/?l=linux-iio=152534455701742=2
> 
> 
> > ---
> >  drivers/iio/humidity/hts221_core.c | 12 
> >  1 file changed, 8 insertions(+), 4 deletions(-)
> > 
> > diff --git a/drivers/iio/humidity/hts221_core.c 
> > b/drivers/iio/humidity/hts221_core.c
> > index 32524a8dc66f..fed2da64fa3b 100644
> > --- a/drivers/iio/humidity/hts221_core.c
> > +++ b/drivers/iio/humidity/hts221_core.c
> > @@ -674,11 +674,15 @@ static int __maybe_unused hts221_resume(struct device 
> > *dev)
> > struct hts221_hw *hw = iio_priv(iio_dev);
> > int err = 0;
> >  
> > -   if (hw->enabled)
> > -   err = hts221_write_with_mask(hw, HTS221_REG_CNTRL1_ADDR,
> > -HTS221_ENABLE_MASK, true);
> 
> Why drop the enable setting?  Seems that we want to do this 'as well',
> if the device was previous enabled.
Yes, will cover this in v2.
> 
> > +   err = hts221_write_with_mask(hw, HTS221_REG_CNTRL1_ADDR,
> > +HTS221_BDU_MASK, 1);
> > +   if (err < 0)
> > +   goto fail_err;
> >  
> > -   return err;
> > +   err = hts221_update_odr(hw, hw->odr);
> > +
> > +fail_err:
> > +   return err < 0 ? err : 0;
> >  }
> >  
> >  const struct dev_pm_ops hts221_pm_ops = {
> 
> 

signature.asc
Description: This is a digitally signed message part

Re: [PATCH] iio: humidity: hts221: Fix sensor reads after resume

[Shrirang Bagul]

On Sun, 2018-05-06 at 17:19 +0100, Jonathan Cameron wrote:
> On Mon, 30 Apr 2018 12:25:46 +0800
> Shrirang Bagul  wrote:
> 
> > CTRL1 register (ODR & BDU settings) gets reset after system comes back
> > from suspend, causing subsequent reads from the sensor to fail.
> > 
> > This patch restores the CTRL1 register after resume.
> > 
> > Based on:
> > git://git.kernel.org/pub/scm/linux/kernel/git/jic23/iio.git 
> > iio-fixes-for-4.14b
> > 
> > Since 4.17.rc1, this driver uses REGMAP; I'll send a separate patch to
> > address this issue.
> > 
> > Cc: sta...@vger.kernel.org
> > Fixes: ffebe74b7c95 (iio: humidity: hts221: avoid useless ODR 
> > reconfiguration)
> 
> Looks like part of the problem was introduced in that patch, part well 
> predated
> it (BDU).
> 
> > Signed-off-by: Shrirang Bagul 
> 
> As you way, this needs to be a bit different to take into account
> the change to regmap.  We'll need to have that upstream before we look
> at a back port.  One element inline surprises me and needs further
> explanation.
I have sent a patch based on iio-for-4.17b [1], Lorenzo and I are still 
discussing our findings. It's not just the CTRL1 reg, but also the 
AV_CONF(0x10) reg.
which loses it's contents coming out of suspend.

[1] https://marc.info/?l=linux-iio=152534455701742=2
> 
> 
> > ---
> >  drivers/iio/humidity/hts221_core.c | 12 
> >  1 file changed, 8 insertions(+), 4 deletions(-)
> > 
> > diff --git a/drivers/iio/humidity/hts221_core.c 
> > b/drivers/iio/humidity/hts221_core.c
> > index 32524a8dc66f..fed2da64fa3b 100644
> > --- a/drivers/iio/humidity/hts221_core.c
> > +++ b/drivers/iio/humidity/hts221_core.c
> > @@ -674,11 +674,15 @@ static int __maybe_unused hts221_resume(struct device 
> > *dev)
> > struct hts221_hw *hw = iio_priv(iio_dev);
> > int err = 0;
> >  
> > -   if (hw->enabled)
> > -   err = hts221_write_with_mask(hw, HTS221_REG_CNTRL1_ADDR,
> > -HTS221_ENABLE_MASK, true);
> 
> Why drop the enable setting?  Seems that we want to do this 'as well',
> if the device was previous enabled.
Yes, will cover this in v2.
> 
> > +   err = hts221_write_with_mask(hw, HTS221_REG_CNTRL1_ADDR,
> > +HTS221_BDU_MASK, 1);
> > +   if (err < 0)
> > +   goto fail_err;
> >  
> > -   return err;
> > +   err = hts221_update_odr(hw, hw->odr);
> > +
> > +fail_err:
> > +   return err < 0 ? err : 0;
> >  }
> >  
> >  const struct dev_pm_ops hts221_pm_ops = {
> 
> 

signature.asc
Description: This is a digitally signed message part

[PATCH v2] f2fs-tools: fix to match with the start_sector

[Yunlong Song]

f2fs-tools uses ioctl BLKSSZGET to get sector_size, however, this ioctl
will return a value which may be larger than 512 (according to the value
of q->limits.logical_block_size), then this will be inconsistent with
the start_sector, since start_sector is got from ioctl HDIO_GETGEO and
is always in 512 size unit for a sector. To fix this problem, just
change the sector_size to the default value when computing with
start_sector. And fix sectors_per_blk as well.

Signed-off-by: Yunlong Song 
---
 fsck/resize.c  |  4 ++--
 mkfs/f2fs_format.c | 12 ++--
 2 files changed, 8 insertions(+), 8 deletions(-)

diff --git a/fsck/resize.c b/fsck/resize.c
index d285dd7..ada2155 100644
--- a/fsck/resize.c
+++ b/fsck/resize.c
@@ -27,10 +27,10 @@ static int get_new_sb(struct f2fs_super_block *sb)
 
zone_size_bytes = segment_size_bytes * segs_per_zone;
zone_align_start_offset =
-   (c.start_sector * c.sector_size +
+   (c.start_sector * DEFAULT_SECTOR_SIZE +
2 * F2FS_BLKSIZE + zone_size_bytes - 1) /
zone_size_bytes * zone_size_bytes -
-   c.start_sector * c.sector_size;
+   c.start_sector * DEFAULT_SECTOR_SIZE;
 
set_sb(segment_count, (c.target_sectors * c.sector_size -
zone_align_start_offset) / segment_size_bytes /
diff --git a/mkfs/f2fs_format.c b/mkfs/f2fs_format.c
index 0a99a77..ced5fea 100644
--- a/mkfs/f2fs_format.c
+++ b/mkfs/f2fs_format.c
@@ -212,18 +212,18 @@ static int f2fs_prepare_super_block(void)
set_sb(block_count, c.total_sectors >> log_sectors_per_block);
 
zone_align_start_offset =
-   (c.start_sector * c.sector_size +
+   (c.start_sector * DEFAULT_SECTOR_SIZE +
2 * F2FS_BLKSIZE + zone_size_bytes - 1) /
zone_size_bytes * zone_size_bytes -
-   c.start_sector * c.sector_size;
+   c.start_sector * DEFAULT_SECTOR_SIZE;
 
-   if (c.start_sector % c.sectors_per_blk) {
+   if (c.start_sector % DEFAULT_SECTORS_PER_BLOCK) {
MSG(1, "\t%s: Align start sector number to the page unit\n",
c.zoned_mode ? "FAIL" : "WARN");
MSG(1, "\ti.e., start sector: %d, ofs:%d (sects/page: %d)\n",
c.start_sector,
-   c.start_sector % c.sectors_per_blk,
-   c.sectors_per_blk);
+   c.start_sector % DEFAULT_SECTORS_PER_BLOCK,
+   DEFAULT_SECTORS_PER_BLOCK);
if (c.zoned_mode)
return -1;
}
@@ -235,7 +235,7 @@ static int f2fs_prepare_super_block(void)
get_sb(segment0_blkaddr));
 
if (c.zoned_mode && (get_sb(segment0_blkaddr) + c.start_sector /
-   c.sectors_per_blk) % c.zone_blocks) {
+   DEFAULT_SECTORS_PER_BLOCK) % 
c.zone_blocks) {
MSG(1, "\tError: Unaligned segment0 block address %u\n",
get_sb(segment0_blkaddr));
return -1;
-- 
1.8.5.2

[PATCH v2] f2fs-tools: fix to match with the start_sector

[Yunlong Song]

f2fs-tools uses ioctl BLKSSZGET to get sector_size, however, this ioctl
will return a value which may be larger than 512 (according to the value
of q->limits.logical_block_size), then this will be inconsistent with
the start_sector, since start_sector is got from ioctl HDIO_GETGEO and
is always in 512 size unit for a sector. To fix this problem, just
change the sector_size to the default value when computing with
start_sector. And fix sectors_per_blk as well.

Signed-off-by: Yunlong Song 
---
 fsck/resize.c  |  4 ++--
 mkfs/f2fs_format.c | 12 ++--
 2 files changed, 8 insertions(+), 8 deletions(-)

diff --git a/fsck/resize.c b/fsck/resize.c
index d285dd7..ada2155 100644
--- a/fsck/resize.c
+++ b/fsck/resize.c
@@ -27,10 +27,10 @@ static int get_new_sb(struct f2fs_super_block *sb)
 
zone_size_bytes = segment_size_bytes * segs_per_zone;
zone_align_start_offset =
-   (c.start_sector * c.sector_size +
+   (c.start_sector * DEFAULT_SECTOR_SIZE +
2 * F2FS_BLKSIZE + zone_size_bytes - 1) /
zone_size_bytes * zone_size_bytes -
-   c.start_sector * c.sector_size;
+   c.start_sector * DEFAULT_SECTOR_SIZE;
 
set_sb(segment_count, (c.target_sectors * c.sector_size -
zone_align_start_offset) / segment_size_bytes /
diff --git a/mkfs/f2fs_format.c b/mkfs/f2fs_format.c
index 0a99a77..ced5fea 100644
--- a/mkfs/f2fs_format.c
+++ b/mkfs/f2fs_format.c
@@ -212,18 +212,18 @@ static int f2fs_prepare_super_block(void)
set_sb(block_count, c.total_sectors >> log_sectors_per_block);
 
zone_align_start_offset =
-   (c.start_sector * c.sector_size +
+   (c.start_sector * DEFAULT_SECTOR_SIZE +
2 * F2FS_BLKSIZE + zone_size_bytes - 1) /
zone_size_bytes * zone_size_bytes -
-   c.start_sector * c.sector_size;
+   c.start_sector * DEFAULT_SECTOR_SIZE;
 
-   if (c.start_sector % c.sectors_per_blk) {
+   if (c.start_sector % DEFAULT_SECTORS_PER_BLOCK) {
MSG(1, "\t%s: Align start sector number to the page unit\n",
c.zoned_mode ? "FAIL" : "WARN");
MSG(1, "\ti.e., start sector: %d, ofs:%d (sects/page: %d)\n",
c.start_sector,
-   c.start_sector % c.sectors_per_blk,
-   c.sectors_per_blk);
+   c.start_sector % DEFAULT_SECTORS_PER_BLOCK,
+   DEFAULT_SECTORS_PER_BLOCK);
if (c.zoned_mode)
return -1;
}
@@ -235,7 +235,7 @@ static int f2fs_prepare_super_block(void)
get_sb(segment0_blkaddr));
 
if (c.zoned_mode && (get_sb(segment0_blkaddr) + c.start_sector /
-   c.sectors_per_blk) % c.zone_blocks) {
+   DEFAULT_SECTORS_PER_BLOCK) % 
c.zone_blocks) {
MSG(1, "\tError: Unaligned segment0 block address %u\n",
get_sb(segment0_blkaddr));
return -1;
-- 
1.8.5.2

Re: moving affs + RDB partition support to staging?

[Al Viro]

On Sun, May 06, 2018 at 10:32:47PM +0100, Al Viro wrote:
> On Sun, May 06, 2018 at 09:46:23PM +0100, Al Viro wrote:
> 
> > I'm fixing that pile of crap (along with the NFS exports
> > one and, hopefully, rename mess as well).  HOWEVER, I am not going
> > to take over the damn thing - David has violated the 11th
> > commandment (Thou Shalt Never Volunteer), so he gets to joy of
> > learning that codebase and taking care of it from now on.
> 
>   Same scenario on link(2) ends up with
> * ST_LINKFILE created, inserted into the link chain and left around,
> without being present in any hash chain
> * target becoming positive hashed dentry, as if link(2) has succeeded,
> so dcache lookups will be finding it (for a while)
> * unlink(2) on source will have very interesting effects, what with
> the attempts to move ST_FILE entry into the directory presumed to
> contain ST_LINKFILE one, removing ST_LINKFILE from it at the same time.

Oh, lovely...  Looks like that thing wants the hash chains sorted by
block number.  affs_insert_hash() doesn't give a toss - it always
adds to the very end of chain.

Maintaining that requirement (and I can understand the rationale -
they don't want too many back-and-forth seeks on directory lookups)
is going to be great fun on rename(), especially for the case when
the target of rename happens to be a primary name for a file with
additional hardlinks.

I think I see how to deal with that sanely, but... ouch.

Incidentally, we'd better verify that hash chains are not looped - as it
is, there's no checks whatsoever, and it *will* happily loop if you
feed it an image with such braindamage.  I really hope that no fan of
desktop experience has set the things up for e.g. USB sticks with
that on them being recognized and automounted on insertion...

Re: moving affs + RDB partition support to staging?

[Al Viro]

On Sun, May 06, 2018 at 10:32:47PM +0100, Al Viro wrote:
> On Sun, May 06, 2018 at 09:46:23PM +0100, Al Viro wrote:
> 
> > I'm fixing that pile of crap (along with the NFS exports
> > one and, hopefully, rename mess as well).  HOWEVER, I am not going
> > to take over the damn thing - David has violated the 11th
> > commandment (Thou Shalt Never Volunteer), so he gets to joy of
> > learning that codebase and taking care of it from now on.
> 
>   Same scenario on link(2) ends up with
> * ST_LINKFILE created, inserted into the link chain and left around,
> without being present in any hash chain
> * target becoming positive hashed dentry, as if link(2) has succeeded,
> so dcache lookups will be finding it (for a while)
> * unlink(2) on source will have very interesting effects, what with
> the attempts to move ST_FILE entry into the directory presumed to
> contain ST_LINKFILE one, removing ST_LINKFILE from it at the same time.

Oh, lovely...  Looks like that thing wants the hash chains sorted by
block number.  affs_insert_hash() doesn't give a toss - it always
adds to the very end of chain.

Maintaining that requirement (and I can understand the rationale -
they don't want too many back-and-forth seeks on directory lookups)
is going to be great fun on rename(), especially for the case when
the target of rename happens to be a primary name for a file with
additional hardlinks.

I think I see how to deal with that sanely, but... ouch.

Incidentally, we'd better verify that hash chains are not looped - as it
is, there's no checks whatsoever, and it *will* happily loop if you
feed it an image with such braindamage.  I really hope that no fan of
desktop experience has set the things up for e.g. USB sticks with
that on them being recognized and automounted on insertion...

linux-next: manual merge of the tip tree with the bpf-next tree

[Stephen Rothwell]

Hi all,

Today's linux-next merge of the tip tree got a conflict in:

  arch/x86/net/bpf_jit_comp.c

between commit:

  e782bdcf58c5 ("bpf, x64: remove ld_abs/ld_ind")

from the bpf-next tree and commit:

  5f26c50143f5 ("x86/bpf: Clean up non-standard comments, to make the code more 
readable")

from the tip tree.

I fixed it up (the former commit removed some code modified by the latter,
so I just removed it) and can carry the fix as necessary. This is now
fixed as far as linux-next is concerned, but any non trivial conflicts
should be mentioned to your upstream maintainer when your tree is
submitted for merging.  You may also want to consider cooperating with
the maintainer of the conflicting tree to minimise any particularly
complex conflicts.

-- 
Cheers,
Stephen Rothwell


pgp1ZI18qZ2OF.pgp
Description: OpenPGP digital signature

linux-next: manual merge of the tip tree with the bpf-next tree

[Stephen Rothwell]

Hi all,

Today's linux-next merge of the tip tree got a conflict in:

  arch/x86/net/bpf_jit_comp.c

between commit:

  e782bdcf58c5 ("bpf, x64: remove ld_abs/ld_ind")

from the bpf-next tree and commit:

  5f26c50143f5 ("x86/bpf: Clean up non-standard comments, to make the code more 
readable")

from the tip tree.

I fixed it up (the former commit removed some code modified by the latter,
so I just removed it) and can carry the fix as necessary. This is now
fixed as far as linux-next is concerned, but any non trivial conflicts
should be mentioned to your upstream maintainer when your tree is
submitted for merging.  You may also want to consider cooperating with
the maintainer of the conflicting tree to minimise any particularly
complex conflicts.

-- 
Cheers,
Stephen Rothwell


pgp1ZI18qZ2OF.pgp
Description: OpenPGP digital signature

[PATCH-next] scsi: libsas: dynamically allocate and free ata host

[Jason Yan]

Now the ata host for libsas is embedded in domain_device, and the ->kref
member is not initialized. Afer we add ata transport class,
ata_host_get() will be called when adding transport ATA port and a
warning will be triggered as below:

refcount_t: increment on 0; use-after-free.
WARNING: CPU: 2 PID: 103 at lib/refcount.c:153 refcount_inc+0x40/0x48
..
Call trace:
 refcount_inc+0x40/0x48
 ata_host_get+0x10/0x18
 ata_tport_add+0x40/0x120
 ata_sas_tport_add+0xc/0x14
 sas_ata_init+0x7c/0xc8
 sas_discover_domain+0x380/0x53c
 process_one_work+0x12c/0x288
 worker_thread+0x58/0x3f0
 kthread+0xfc/0x128
 ret_from_fork+0x10/0x18

And also when removing transport ATA port ata_host_put() will be called
and another similar warning will be triggered. If the refcount decreased
to zero, the ata host will be freed. But this ata host is only part of
domain_device, it cannot be freed directly.

So we have to change this embedded static ata host to a dynamically
allocated ata host and initialize the ->kref member. To use
ata_host_get() and ata_host_put() in libsas, we need to move the
declaration of these functions to the public libata.h.

Fixes: b6240a4df018 ("scsi: libsas: add transport class for ATA devices")
Signed-off-by: Jason Yan 
CC: John Garry 
---
 drivers/ata/libata-core.c  |  1 +
 drivers/ata/libata.h   |  2 --
 drivers/scsi/libsas/sas_ata.c  | 40 +-
 drivers/scsi/libsas/sas_discover.c |  2 ++
 include/linux/libata.h |  2 ++
 include/scsi/libsas.h  |  2 +-
 6 files changed, 32 insertions(+), 17 deletions(-)

diff --git a/drivers/ata/libata-core.c b/drivers/ata/libata-core.c
index 68596bd4cf06..33c2dfbbc02d 100644
--- a/drivers/ata/libata-core.c
+++ b/drivers/ata/libata-core.c
@@ -6424,6 +6424,7 @@ void ata_host_init(struct ata_host *host, struct device 
*dev,
host->n_tags = ATA_MAX_QUEUE - 1;
host->dev = dev;
host->ops = ops;
+   kref_init(>kref);
 }
 
 void __ata_port_probe(struct ata_port *ap)
diff --git a/drivers/ata/libata.h b/drivers/ata/libata.h
index 9e21c49cf6be..f953cb4bb1ba 100644
--- a/drivers/ata/libata.h
+++ b/drivers/ata/libata.h
@@ -100,8 +100,6 @@ extern int ata_port_probe(struct ata_port *ap);
 extern void __ata_port_probe(struct ata_port *ap);
 extern unsigned int ata_read_log_page(struct ata_device *dev, u8 log,
  u8 page, void *buf, unsigned int sectors);
-extern void ata_host_get(struct ata_host *host);
-extern void ata_host_put(struct ata_host *host);
 
 #define to_ata_port(d) container_of(d, struct ata_port, tdev)
 
diff --git a/drivers/scsi/libsas/sas_ata.c b/drivers/scsi/libsas/sas_ata.c
index ff1d612f6fb9..41cdda7a926b 100644
--- a/drivers/scsi/libsas/sas_ata.c
+++ b/drivers/scsi/libsas/sas_ata.c
@@ -557,34 +557,46 @@ int sas_ata_init(struct domain_device *found_dev)
 {
struct sas_ha_struct *ha = found_dev->port->ha;
struct Scsi_Host *shost = ha->core.shost;
+   struct ata_host *ata_host;
struct ata_port *ap;
int rc;
 
-   ata_host_init(_dev->sata_dev.ata_host, ha->dev, _sata_ops);
-   ap = ata_sas_port_alloc(_dev->sata_dev.ata_host,
-   _port_info,
-   shost);
+   ata_host = kzalloc(sizeof(*ata_host), GFP_KERNEL);
+   if (!ata_host)  {
+   SAS_DPRINTK("ata host alloc failed.\n");
+   return -ENOMEM;
+   }
+
+   ata_host_init(ata_host, ha->dev, _sata_ops);
+
+   ap = ata_sas_port_alloc(ata_host, _port_info, shost);
if (!ap) {
SAS_DPRINTK("ata_sas_port_alloc failed.\n");
-   return -ENODEV;
+   rc = -ENODEV;
+   goto free_host;
}
 
ap->private_data = found_dev;
ap->cbl = ATA_CBL_SATA;
ap->scsi_host = shost;
rc = ata_sas_port_init(ap);
-   if (rc) {
-   ata_sas_port_destroy(ap);
-   return rc;
-   }
-   rc = ata_sas_tport_add(found_dev->sata_dev.ata_host.dev, ap);
-   if (rc) {
-   ata_sas_port_destroy(ap);
-   return rc;
-   }
+   if (rc)
+   goto destroy_port;
+
+   rc = ata_sas_tport_add(ata_host->dev, ap);
+   if (rc)
+   goto destroy_port;
+
+   found_dev->sata_dev.ata_host = ata_host;
found_dev->sata_dev.ap = ap;
 
return 0;
+
+destroy_port:
+   ata_sas_port_destroy(ap);
+free_host:
+   ata_host_put(ata_host);
+   return rc;
 }
 
 void sas_ata_task_abort(struct sas_task *task)
diff --git a/drivers/scsi/libsas/sas_discover.c 
b/drivers/scsi/libsas/sas_discover.c
index 1ffca28fe6a8..0148ae62a52a 100644
--- a/drivers/scsi/libsas/sas_discover.c
+++ b/drivers/scsi/libsas/sas_discover.c
@@ -316,6 +316,8 @@ void sas_free_device(struct kref *kref)
if (dev_is_sata(dev) && dev->sata_dev.ap) {

[PATCH-next] scsi: libsas: dynamically allocate and free ata host

[Jason Yan]

Now the ata host for libsas is embedded in domain_device, and the ->kref
member is not initialized. Afer we add ata transport class,
ata_host_get() will be called when adding transport ATA port and a
warning will be triggered as below:

refcount_t: increment on 0; use-after-free.
WARNING: CPU: 2 PID: 103 at lib/refcount.c:153 refcount_inc+0x40/0x48
..
Call trace:
 refcount_inc+0x40/0x48
 ata_host_get+0x10/0x18
 ata_tport_add+0x40/0x120
 ata_sas_tport_add+0xc/0x14
 sas_ata_init+0x7c/0xc8
 sas_discover_domain+0x380/0x53c
 process_one_work+0x12c/0x288
 worker_thread+0x58/0x3f0
 kthread+0xfc/0x128
 ret_from_fork+0x10/0x18

And also when removing transport ATA port ata_host_put() will be called
and another similar warning will be triggered. If the refcount decreased
to zero, the ata host will be freed. But this ata host is only part of
domain_device, it cannot be freed directly.

So we have to change this embedded static ata host to a dynamically
allocated ata host and initialize the ->kref member. To use
ata_host_get() and ata_host_put() in libsas, we need to move the
declaration of these functions to the public libata.h.

Fixes: b6240a4df018 ("scsi: libsas: add transport class for ATA devices")
Signed-off-by: Jason Yan 
CC: John Garry 
---
 drivers/ata/libata-core.c  |  1 +
 drivers/ata/libata.h   |  2 --
 drivers/scsi/libsas/sas_ata.c  | 40 +-
 drivers/scsi/libsas/sas_discover.c |  2 ++
 include/linux/libata.h |  2 ++
 include/scsi/libsas.h  |  2 +-
 6 files changed, 32 insertions(+), 17 deletions(-)

diff --git a/drivers/ata/libata-core.c b/drivers/ata/libata-core.c
index 68596bd4cf06..33c2dfbbc02d 100644
--- a/drivers/ata/libata-core.c
+++ b/drivers/ata/libata-core.c
@@ -6424,6 +6424,7 @@ void ata_host_init(struct ata_host *host, struct device 
*dev,
host->n_tags = ATA_MAX_QUEUE - 1;
host->dev = dev;
host->ops = ops;
+   kref_init(>kref);
 }
 
 void __ata_port_probe(struct ata_port *ap)
diff --git a/drivers/ata/libata.h b/drivers/ata/libata.h
index 9e21c49cf6be..f953cb4bb1ba 100644
--- a/drivers/ata/libata.h
+++ b/drivers/ata/libata.h
@@ -100,8 +100,6 @@ extern int ata_port_probe(struct ata_port *ap);
 extern void __ata_port_probe(struct ata_port *ap);
 extern unsigned int ata_read_log_page(struct ata_device *dev, u8 log,
  u8 page, void *buf, unsigned int sectors);
-extern void ata_host_get(struct ata_host *host);
-extern void ata_host_put(struct ata_host *host);
 
 #define to_ata_port(d) container_of(d, struct ata_port, tdev)
 
diff --git a/drivers/scsi/libsas/sas_ata.c b/drivers/scsi/libsas/sas_ata.c
index ff1d612f6fb9..41cdda7a926b 100644
--- a/drivers/scsi/libsas/sas_ata.c
+++ b/drivers/scsi/libsas/sas_ata.c
@@ -557,34 +557,46 @@ int sas_ata_init(struct domain_device *found_dev)
 {
struct sas_ha_struct *ha = found_dev->port->ha;
struct Scsi_Host *shost = ha->core.shost;
+   struct ata_host *ata_host;
struct ata_port *ap;
int rc;
 
-   ata_host_init(_dev->sata_dev.ata_host, ha->dev, _sata_ops);
-   ap = ata_sas_port_alloc(_dev->sata_dev.ata_host,
-   _port_info,
-   shost);
+   ata_host = kzalloc(sizeof(*ata_host), GFP_KERNEL);
+   if (!ata_host)  {
+   SAS_DPRINTK("ata host alloc failed.\n");
+   return -ENOMEM;
+   }
+
+   ata_host_init(ata_host, ha->dev, _sata_ops);
+
+   ap = ata_sas_port_alloc(ata_host, _port_info, shost);
if (!ap) {
SAS_DPRINTK("ata_sas_port_alloc failed.\n");
-   return -ENODEV;
+   rc = -ENODEV;
+   goto free_host;
}
 
ap->private_data = found_dev;
ap->cbl = ATA_CBL_SATA;
ap->scsi_host = shost;
rc = ata_sas_port_init(ap);
-   if (rc) {
-   ata_sas_port_destroy(ap);
-   return rc;
-   }
-   rc = ata_sas_tport_add(found_dev->sata_dev.ata_host.dev, ap);
-   if (rc) {
-   ata_sas_port_destroy(ap);
-   return rc;
-   }
+   if (rc)
+   goto destroy_port;
+
+   rc = ata_sas_tport_add(ata_host->dev, ap);
+   if (rc)
+   goto destroy_port;
+
+   found_dev->sata_dev.ata_host = ata_host;
found_dev->sata_dev.ap = ap;
 
return 0;
+
+destroy_port:
+   ata_sas_port_destroy(ap);
+free_host:
+   ata_host_put(ata_host);
+   return rc;
 }
 
 void sas_ata_task_abort(struct sas_task *task)
diff --git a/drivers/scsi/libsas/sas_discover.c 
b/drivers/scsi/libsas/sas_discover.c
index 1ffca28fe6a8..0148ae62a52a 100644
--- a/drivers/scsi/libsas/sas_discover.c
+++ b/drivers/scsi/libsas/sas_discover.c
@@ -316,6 +316,8 @@ void sas_free_device(struct kref *kref)
if (dev_is_sata(dev) && dev->sata_dev.ap) {
ata_sas_tport_delete(dev->sata_dev.ap);

Re: [PATCH] isdn: eicon: fix a missing-check bug

[YU Bo]

Hello,
I am just notice your subject line.There are missing something i think
On Sat, May 05, 2018 at 02:32:46PM -0500, Wenwen Wang wrote:

In divasmain.c, the function divas_write() firstly invokes the function
diva_xdi_open_adapter() to open the adapter that matches with the adapter
number provided by the user, and then invokes the function diva_xdi_write()
to perform the write operation using the matched adapter. The two functions
diva_xdi_open_adapter() and diva_xdi_write() are located in diva.c.

In diva_xdi_open_adapter(), the user command is copied to the object 'msg'
from the userspace pointer 'src' through the function pointer 'cp_fn',
which eventually calls copy_from_user() to do the copy. Then, the adapter
number 'msg.adapter' is used to find out a matched adapter from the
'adapter_queue'. A matched adapter will be returned if it is found.
Otherwise, NULL is returned to indicate the failure of the verification on
the adapter number.

As mentioned above, if a matched adapter is returned, the function
diva_xdi_write() is invoked to perform the write operation. In this
function, the user command is copied once again from the userspace pointer
'src', which is the same as the 'src' pointer in diva_xdi_open_adapter() as
both of them are from the 'buf' pointer in divas_write(). Similarly, the
copy is achieved through the function pointer 'cp_fn', which finally calls
copy_from_user(). After the successful copy, the corresponding command
processing handler of the matched adapter is invoked to perform the write
operation.

It is obvious that there are two copies here from userspace, one is in
diva_xdi_open_adapter(), and one is in diva_xdi_write(). Plus, both of
these two copies share the same source userspace pointer, i.e., the 'buf'
pointer in divas_write(). Given that a malicious userspace process can race
to change the content pointed by the 'buf' pointer, this can pose potential
security issues. For example, in the first copy, the user provides a valid
adapter number to pass the verification process and a valid adapter can be
found. Then the user can modify the adapter number to an invalid number.
This way, the user can bypass the verification process of the adapter
number and inject inconsistent data.

To avoid such issues, this patch adds a check after the second copy in the
function diva_xdi_write(). If the adapter number is not equal to the one
obtained in the first copy, (-4) will be returned to divas_write(), which
will then return an error code -EINVAL.

Signed-off-by: Wenwen Wang 
---
drivers/isdn/hardware/eicon/diva.c  | 6 +-
drivers/isdn/hardware/eicon/divasmain.c | 3 +++
2 files changed, 8 insertions(+), 1 deletion(-)

diff --git a/drivers/isdn/hardware/eicon/diva.c 
b/drivers/isdn/hardware/eicon/diva.c
index 944a7f3..46cbf76 100644
--- a/drivers/isdn/hardware/eicon/diva.c
+++ b/drivers/isdn/hardware/eicon/diva.c
@@ -440,6 +440,7 @@ diva_xdi_write(void *adapter, void *os_handle, const void 
__user *src,
   int length, divas_xdi_copy_from_user_fn_t cp_fn)
{
diva_os_xdi_adapter_t *a = (diva_os_xdi_adapter_t *) adapter;
+   diva_xdi_um_cfg_cmd_t *p;
void *data;

if (a->xdi_mbox.status & DIVA_XDI_MBOX_BUSY) {
@@ -461,7 +462,10 @@ diva_xdi_write(void *adapter, void *os_handle, const void 
__user *src,

length = (*cp_fn) (os_handle, data, src, length);
if (length > 0) {
-   if ((*(a->interface.cmd_proc))
+   p = (diva_xdi_um_cfg_cmd_t *) data;
+   if (a->controller != (int)p->adapter) {
+   length = -4;
+   } else if ((*(a->interface.cmd_proc))
(a, (diva_xdi_um_cfg_cmd_t *) data, length)) {
length = -3;
}
diff --git a/drivers/isdn/hardware/eicon/divasmain.c 
b/drivers/isdn/hardware/eicon/divasmain.c
index b9980e8..a03c658 100644
--- a/drivers/isdn/hardware/eicon/divasmain.c
+++ b/drivers/isdn/hardware/eicon/divasmain.c
@@ -614,6 +614,9 @@ static ssize_t divas_write(struct file *file, const char 
__user *buf,
case -3:
ret = -ENXIO;
break;
+   case -4:
+   ret = -EINVAL;
+   break;
}
DBG_TRC(("write: ret %d", ret));
return (ret);
--
2.7.4

Re: [PATCH] isdn: eicon: fix a missing-check bug

[YU Bo]

Hello,
I am just notice your subject line.There are missing something i think
On Sat, May 05, 2018 at 02:32:46PM -0500, Wenwen Wang wrote:

In divasmain.c, the function divas_write() firstly invokes the function
diva_xdi_open_adapter() to open the adapter that matches with the adapter
number provided by the user, and then invokes the function diva_xdi_write()
to perform the write operation using the matched adapter. The two functions
diva_xdi_open_adapter() and diva_xdi_write() are located in diva.c.

In diva_xdi_open_adapter(), the user command is copied to the object 'msg'
from the userspace pointer 'src' through the function pointer 'cp_fn',
which eventually calls copy_from_user() to do the copy. Then, the adapter
number 'msg.adapter' is used to find out a matched adapter from the
'adapter_queue'. A matched adapter will be returned if it is found.
Otherwise, NULL is returned to indicate the failure of the verification on
the adapter number.

As mentioned above, if a matched adapter is returned, the function
diva_xdi_write() is invoked to perform the write operation. In this
function, the user command is copied once again from the userspace pointer
'src', which is the same as the 'src' pointer in diva_xdi_open_adapter() as
both of them are from the 'buf' pointer in divas_write(). Similarly, the
copy is achieved through the function pointer 'cp_fn', which finally calls
copy_from_user(). After the successful copy, the corresponding command
processing handler of the matched adapter is invoked to perform the write
operation.

It is obvious that there are two copies here from userspace, one is in
diva_xdi_open_adapter(), and one is in diva_xdi_write(). Plus, both of
these two copies share the same source userspace pointer, i.e., the 'buf'
pointer in divas_write(). Given that a malicious userspace process can race
to change the content pointed by the 'buf' pointer, this can pose potential
security issues. For example, in the first copy, the user provides a valid
adapter number to pass the verification process and a valid adapter can be
found. Then the user can modify the adapter number to an invalid number.
This way, the user can bypass the verification process of the adapter
number and inject inconsistent data.

To avoid such issues, this patch adds a check after the second copy in the
function diva_xdi_write(). If the adapter number is not equal to the one
obtained in the first copy, (-4) will be returned to divas_write(), which
will then return an error code -EINVAL.

Signed-off-by: Wenwen Wang 
---
drivers/isdn/hardware/eicon/diva.c  | 6 +-
drivers/isdn/hardware/eicon/divasmain.c | 3 +++
2 files changed, 8 insertions(+), 1 deletion(-)

diff --git a/drivers/isdn/hardware/eicon/diva.c 
b/drivers/isdn/hardware/eicon/diva.c
index 944a7f3..46cbf76 100644
--- a/drivers/isdn/hardware/eicon/diva.c
+++ b/drivers/isdn/hardware/eicon/diva.c
@@ -440,6 +440,7 @@ diva_xdi_write(void *adapter, void *os_handle, const void 
__user *src,
   int length, divas_xdi_copy_from_user_fn_t cp_fn)
{
diva_os_xdi_adapter_t *a = (diva_os_xdi_adapter_t *) adapter;
+   diva_xdi_um_cfg_cmd_t *p;
void *data;

if (a->xdi_mbox.status & DIVA_XDI_MBOX_BUSY) {
@@ -461,7 +462,10 @@ diva_xdi_write(void *adapter, void *os_handle, const void 
__user *src,

length = (*cp_fn) (os_handle, data, src, length);
if (length > 0) {
-   if ((*(a->interface.cmd_proc))
+   p = (diva_xdi_um_cfg_cmd_t *) data;
+   if (a->controller != (int)p->adapter) {
+   length = -4;
+   } else if ((*(a->interface.cmd_proc))
(a, (diva_xdi_um_cfg_cmd_t *) data, length)) {
length = -3;
}
diff --git a/drivers/isdn/hardware/eicon/divasmain.c 
b/drivers/isdn/hardware/eicon/divasmain.c
index b9980e8..a03c658 100644
--- a/drivers/isdn/hardware/eicon/divasmain.c
+++ b/drivers/isdn/hardware/eicon/divasmain.c
@@ -614,6 +614,9 @@ static ssize_t divas_write(struct file *file, const char 
__user *buf,
case -3:
ret = -ENXIO;
break;
+   case -4:
+   ret = -EINVAL;
+   break;
}
DBG_TRC(("write: ret %d", ret));
return (ret);
--
2.7.4

Re: [J-core] [PATCH v5 00/22] sh: LANDISK and R2Dplus convert to device tree

[Yoshinori Sato]

On Thu, 03 May 2018 19:07:38 +0900,
John Paul Adrian Glaubitz wrote:
> 
> [1  ]
> Hi Rich!
> 
> On 05/03/2018 04:33 AM, Rich Felker wrote:
> > I found the U-Boot stuff here:
> > 
> > https://ja.osdn.net/users/ysato/pf/uboot/wiki/FrontPage
> > 
> > but I'm not sure how to install it yet. Will try to figure it out.
> 
> Interesting. It seems the HDL-160U uses u-boot instead of lilo which
> is used on my USL-5P. Both are based on the LANDISK platform though.
> I wonder whether it is possible to convert the USL-5P to use u-boot
> instead of the very limited lilo.
> 
> As for the kernel configuration, for USL-5P, I had to use the kernel
> configuration attached to this mail. One important configuration setting
> is CONFIG_SH_PCLK_FREQ which has to be set to "3325" otherwise
> the kernel won't boot properly.
> 
> I still have my USL-5P ready to be set up for testing a new kernel
> image with the device tree patches merged. Although I still don't
> know how to enable the internal (pseudo) IDE controller.
> 
> @Yoshinori:
> 
> Did the HDL-160U LANDISK device you have use u-boot by default or
> did you convert it from lilo?

Yes.
Replace sh-lilo's second stage with u-boot.
With this method it is unnecessary to rewrite Flash for boot.

> Adrian
> 
> -- 
>  .''`.  John Paul Adrian Glaubitz
> : :' :  Debian Developer - glaub...@debian.org
> `. `'   Freie Universitaet Berlin - glaub...@physik.fu-berlin.de
>   `-GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913
> [2 config-usl-5p-4.8.12.txt ]
> #
> # Automatically generated file; DO NOT EDIT.
> # Linux/sh 4.8.12 Kernel Configuration
> #
> CONFIG_SUPERH=y
> CONFIG_SUPERH32=y
> # CONFIG_SUPERH64 is not set
> CONFIG_ARCH_DEFCONFIG="arch/sh/configs/shx3_defconfig"
> CONFIG_RWSEM_GENERIC_SPINLOCK=y
> CONFIG_GENERIC_BUG=y
> CONFIG_GENERIC_HWEIGHT=y
> # CONFIG_ARCH_SUSPEND_POSSIBLE is not set
> CONFIG_ARCH_HIBERNATION_POSSIBLE=y
> CONFIG_SYS_SUPPORTS_HUGETLBFS=y
> CONFIG_SYS_SUPPORTS_PCI=y
> CONFIG_STACKTRACE_SUPPORT=y
> CONFIG_LOCKDEP_SUPPORT=y
> # CONFIG_ARCH_HAS_ILOG2_U32 is not set
> # CONFIG_ARCH_HAS_ILOG2_U64 is not set
> # CONFIG_NO_IOPORT_MAP is not set
> CONFIG_DMA_NONCOHERENT=y
> CONFIG_NEED_DMA_MAP_STATE=y
> CONFIG_NEED_SG_DMA_LENGTH=y
> CONFIG_PGTABLE_LEVELS=2
> CONFIG_DEFCONFIG_LIST="/lib/modules/$UNAME_RELEASE/.config"
> CONFIG_CONSTRUCTORS=y
> CONFIG_IRQ_WORK=y
> 
> #
> # General setup
> #
> CONFIG_BROKEN_ON_SMP=y
> CONFIG_INIT_ENV_ARG_LIMIT=32
> CONFIG_CROSS_COMPILE=""
> # CONFIG_COMPILE_TEST is not set
> CONFIG_LOCALVERSION=""
> CONFIG_LOCALVERSION_AUTO=y
> CONFIG_HAVE_KERNEL_GZIP=y
> CONFIG_HAVE_KERNEL_BZIP2=y
> CONFIG_HAVE_KERNEL_LZMA=y
> CONFIG_HAVE_KERNEL_XZ=y
> CONFIG_HAVE_KERNEL_LZO=y
> CONFIG_KERNEL_GZIP=y
> # CONFIG_KERNEL_BZIP2 is not set
> # CONFIG_KERNEL_LZMA is not set
> # CONFIG_KERNEL_XZ is not set
> # CONFIG_KERNEL_LZO is not set
> CONFIG_DEFAULT_HOSTNAME="(none)"
> CONFIG_SWAP=y
> CONFIG_SYSVIPC=y
> CONFIG_SYSVIPC_SYSCTL=y
> CONFIG_POSIX_MQUEUE=y
> CONFIG_POSIX_MQUEUE_SYSCTL=y
> CONFIG_CROSS_MEMORY_ATTACH=y
> CONFIG_FHANDLE=y
> CONFIG_USELIB=y
> CONFIG_AUDIT=y
> CONFIG_HAVE_ARCH_AUDITSYSCALL=y
> CONFIG_AUDITSYSCALL=y
> CONFIG_AUDIT_WATCH=y
> CONFIG_AUDIT_TREE=y
> 
> #
> # IRQ subsystem
> #
> CONFIG_MAY_HAVE_SPARSE_IRQ=y
> CONFIG_GENERIC_IRQ_SHOW=y
> CONFIG_IRQ_DOMAIN=y
> # CONFIG_IRQ_DOMAIN_DEBUG is not set
> CONFIG_IRQ_FORCED_THREADING=y
> CONFIG_SPARSE_IRQ=y
> CONFIG_GENERIC_CLOCKEVENTS=y
> 
> #
> # Timers subsystem
> #
> CONFIG_TICK_ONESHOT=y
> CONFIG_NO_HZ_COMMON=y
> # CONFIG_HZ_PERIODIC is not set
> CONFIG_NO_HZ_IDLE=y
> CONFIG_NO_HZ=y
> CONFIG_HIGH_RES_TIMERS=y
> 
> #
> # CPU/Task time and stats accounting
> #
> CONFIG_TICK_CPU_ACCOUNTING=y
> CONFIG_BSD_PROCESS_ACCT=y
> # CONFIG_BSD_PROCESS_ACCT_V3 is not set
> # CONFIG_TASKSTATS is not set
> 
> #
> # RCU Subsystem
> #
> CONFIG_PREEMPT_RCU=y
> # CONFIG_RCU_EXPERT is not set
> CONFIG_SRCU=y
> # CONFIG_TASKS_RCU is not set
> CONFIG_RCU_STALL_COMMON=y
> # CONFIG_TREE_RCU_TRACE is not set
> # CONFIG_RCU_EXPEDITE_BOOT is not set
> CONFIG_BUILD_BIN2C=y
> CONFIG_IKCONFIG=y
> CONFIG_IKCONFIG_PROC=y
> CONFIG_LOG_BUF_SHIFT=16
> CONFIG_NMI_LOG_BUF_SHIFT=13
> CONFIG_GENERIC_SCHED_CLOCK=y
> CONFIG_CGROUPS=y
> # CONFIG_MEMCG is not set
> # CONFIG_BLK_CGROUP is not set
> CONFIG_CGROUP_SCHED=y
> CONFIG_FAIR_GROUP_SCHED=y
> # CONFIG_CFS_BANDWIDTH is not set
> # CONFIG_RT_GROUP_SCHED is not set
> # CONFIG_CGROUP_PIDS is not set
> CONFIG_CGROUP_FREEZER=y
> # CONFIG_CGROUP_HUGETLB is not set
> CONFIG_CPUSETS=y
> CONFIG_PROC_PID_CPUSET=y
> CONFIG_CGROUP_DEVICE=y
> CONFIG_CGROUP_CPUACCT=y
> CONFIG_CGROUP_PERF=y
> # CONFIG_CGROUP_DEBUG is not set
> # CONFIG_CHECKPOINT_RESTORE is not set
> # CONFIG_NAMESPACES is not set
> # CONFIG_SCHED_AUTOGROUP is not set
> # CONFIG_SYSFS_DEPRECATED is not set
> # CONFIG_RELAY is not set
> # CONFIG_BLK_DEV_INITRD is not set
> CONFIG_CC_OPTIMIZE_FOR_PERFORMANCE=y
> # CONFIG_CC_OPTIMIZE_FOR_SIZE is not set
> CONFIG_SYSCTL=y
> CONFIG_ANON_INODES=y
> 

Re: [J-core] [PATCH v5 00/22] sh: LANDISK and R2Dplus convert to device tree

[Yoshinori Sato]

On Thu, 03 May 2018 19:07:38 +0900,
John Paul Adrian Glaubitz wrote:
> 
> [1  ]
> Hi Rich!
> 
> On 05/03/2018 04:33 AM, Rich Felker wrote:
> > I found the U-Boot stuff here:
> > 
> > https://ja.osdn.net/users/ysato/pf/uboot/wiki/FrontPage
> > 
> > but I'm not sure how to install it yet. Will try to figure it out.
> 
> Interesting. It seems the HDL-160U uses u-boot instead of lilo which
> is used on my USL-5P. Both are based on the LANDISK platform though.
> I wonder whether it is possible to convert the USL-5P to use u-boot
> instead of the very limited lilo.
> 
> As for the kernel configuration, for USL-5P, I had to use the kernel
> configuration attached to this mail. One important configuration setting
> is CONFIG_SH_PCLK_FREQ which has to be set to "3325" otherwise
> the kernel won't boot properly.
> 
> I still have my USL-5P ready to be set up for testing a new kernel
> image with the device tree patches merged. Although I still don't
> know how to enable the internal (pseudo) IDE controller.
> 
> @Yoshinori:
> 
> Did the HDL-160U LANDISK device you have use u-boot by default or
> did you convert it from lilo?

Yes.
Replace sh-lilo's second stage with u-boot.
With this method it is unnecessary to rewrite Flash for boot.

> Adrian
> 
> -- 
>  .''`.  John Paul Adrian Glaubitz
> : :' :  Debian Developer - glaub...@debian.org
> `. `'   Freie Universitaet Berlin - glaub...@physik.fu-berlin.de
>   `-GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913
> [2 config-usl-5p-4.8.12.txt ]
> #
> # Automatically generated file; DO NOT EDIT.
> # Linux/sh 4.8.12 Kernel Configuration
> #
> CONFIG_SUPERH=y
> CONFIG_SUPERH32=y
> # CONFIG_SUPERH64 is not set
> CONFIG_ARCH_DEFCONFIG="arch/sh/configs/shx3_defconfig"
> CONFIG_RWSEM_GENERIC_SPINLOCK=y
> CONFIG_GENERIC_BUG=y
> CONFIG_GENERIC_HWEIGHT=y
> # CONFIG_ARCH_SUSPEND_POSSIBLE is not set
> CONFIG_ARCH_HIBERNATION_POSSIBLE=y
> CONFIG_SYS_SUPPORTS_HUGETLBFS=y
> CONFIG_SYS_SUPPORTS_PCI=y
> CONFIG_STACKTRACE_SUPPORT=y
> CONFIG_LOCKDEP_SUPPORT=y
> # CONFIG_ARCH_HAS_ILOG2_U32 is not set
> # CONFIG_ARCH_HAS_ILOG2_U64 is not set
> # CONFIG_NO_IOPORT_MAP is not set
> CONFIG_DMA_NONCOHERENT=y
> CONFIG_NEED_DMA_MAP_STATE=y
> CONFIG_NEED_SG_DMA_LENGTH=y
> CONFIG_PGTABLE_LEVELS=2
> CONFIG_DEFCONFIG_LIST="/lib/modules/$UNAME_RELEASE/.config"
> CONFIG_CONSTRUCTORS=y
> CONFIG_IRQ_WORK=y
> 
> #
> # General setup
> #
> CONFIG_BROKEN_ON_SMP=y
> CONFIG_INIT_ENV_ARG_LIMIT=32
> CONFIG_CROSS_COMPILE=""
> # CONFIG_COMPILE_TEST is not set
> CONFIG_LOCALVERSION=""
> CONFIG_LOCALVERSION_AUTO=y
> CONFIG_HAVE_KERNEL_GZIP=y
> CONFIG_HAVE_KERNEL_BZIP2=y
> CONFIG_HAVE_KERNEL_LZMA=y
> CONFIG_HAVE_KERNEL_XZ=y
> CONFIG_HAVE_KERNEL_LZO=y
> CONFIG_KERNEL_GZIP=y
> # CONFIG_KERNEL_BZIP2 is not set
> # CONFIG_KERNEL_LZMA is not set
> # CONFIG_KERNEL_XZ is not set
> # CONFIG_KERNEL_LZO is not set
> CONFIG_DEFAULT_HOSTNAME="(none)"
> CONFIG_SWAP=y
> CONFIG_SYSVIPC=y
> CONFIG_SYSVIPC_SYSCTL=y
> CONFIG_POSIX_MQUEUE=y
> CONFIG_POSIX_MQUEUE_SYSCTL=y
> CONFIG_CROSS_MEMORY_ATTACH=y
> CONFIG_FHANDLE=y
> CONFIG_USELIB=y
> CONFIG_AUDIT=y
> CONFIG_HAVE_ARCH_AUDITSYSCALL=y
> CONFIG_AUDITSYSCALL=y
> CONFIG_AUDIT_WATCH=y
> CONFIG_AUDIT_TREE=y
> 
> #
> # IRQ subsystem
> #
> CONFIG_MAY_HAVE_SPARSE_IRQ=y
> CONFIG_GENERIC_IRQ_SHOW=y
> CONFIG_IRQ_DOMAIN=y
> # CONFIG_IRQ_DOMAIN_DEBUG is not set
> CONFIG_IRQ_FORCED_THREADING=y
> CONFIG_SPARSE_IRQ=y
> CONFIG_GENERIC_CLOCKEVENTS=y
> 
> #
> # Timers subsystem
> #
> CONFIG_TICK_ONESHOT=y
> CONFIG_NO_HZ_COMMON=y
> # CONFIG_HZ_PERIODIC is not set
> CONFIG_NO_HZ_IDLE=y
> CONFIG_NO_HZ=y
> CONFIG_HIGH_RES_TIMERS=y
> 
> #
> # CPU/Task time and stats accounting
> #
> CONFIG_TICK_CPU_ACCOUNTING=y
> CONFIG_BSD_PROCESS_ACCT=y
> # CONFIG_BSD_PROCESS_ACCT_V3 is not set
> # CONFIG_TASKSTATS is not set
> 
> #
> # RCU Subsystem
> #
> CONFIG_PREEMPT_RCU=y
> # CONFIG_RCU_EXPERT is not set
> CONFIG_SRCU=y
> # CONFIG_TASKS_RCU is not set
> CONFIG_RCU_STALL_COMMON=y
> # CONFIG_TREE_RCU_TRACE is not set
> # CONFIG_RCU_EXPEDITE_BOOT is not set
> CONFIG_BUILD_BIN2C=y
> CONFIG_IKCONFIG=y
> CONFIG_IKCONFIG_PROC=y
> CONFIG_LOG_BUF_SHIFT=16
> CONFIG_NMI_LOG_BUF_SHIFT=13
> CONFIG_GENERIC_SCHED_CLOCK=y
> CONFIG_CGROUPS=y
> # CONFIG_MEMCG is not set
> # CONFIG_BLK_CGROUP is not set
> CONFIG_CGROUP_SCHED=y
> CONFIG_FAIR_GROUP_SCHED=y
> # CONFIG_CFS_BANDWIDTH is not set
> # CONFIG_RT_GROUP_SCHED is not set
> # CONFIG_CGROUP_PIDS is not set
> CONFIG_CGROUP_FREEZER=y
> # CONFIG_CGROUP_HUGETLB is not set
> CONFIG_CPUSETS=y
> CONFIG_PROC_PID_CPUSET=y
> CONFIG_CGROUP_DEVICE=y
> CONFIG_CGROUP_CPUACCT=y
> CONFIG_CGROUP_PERF=y
> # CONFIG_CGROUP_DEBUG is not set
> # CONFIG_CHECKPOINT_RESTORE is not set
> # CONFIG_NAMESPACES is not set
> # CONFIG_SCHED_AUTOGROUP is not set
> # CONFIG_SYSFS_DEPRECATED is not set
> # CONFIG_RELAY is not set
> # CONFIG_BLK_DEV_INITRD is not set
> CONFIG_CC_OPTIMIZE_FOR_PERFORMANCE=y
> # CONFIG_CC_OPTIMIZE_FOR_SIZE is not set
> CONFIG_SYSCTL=y
> CONFIG_ANON_INODES=y
>